2. 功能安全标准基础：ISO 26262 核心概念与ASIL分解
好，咱们进入正题。ISO 26262，这名字你肯定听过。但说实话，我刚入行那会儿，觉得这玩意儿就是一本天书。全是术语，什么ASIL、HARA、安全目标，看得人头皮发麻。
后来做项目做多了，我才慢慢悟出来——ISO 26262 说白了，就是一套“如何把车规级电子系统的风险，降到可以接受的程度”的方法论。它不是教你写代码，而是教你如何思考安全。
2.1 核心概念：从“危险”到“安全”的链条
我个人习惯，把ISO 26262的核心逻辑拆成一条链：
- 危害 (Hazard)：车出了什么状况？比如车道保持突然失效，车跑偏了。
- 风险 (Risk)：这个危害在什么场景下发生？比如在高速上，旁边有大货车。
- 安全目标 (Safety Goal)：我们要避免什么？比如“避免车辆非预期偏离车道”。
- 功能安全要求 (FSR)：系统该怎么做？比如“系统必须在100ms内检测到驾驶员脱离方向盘”。
- 技术安全要求 (TSR)：软硬件该怎么实现？比如“摄像头帧率必须≥30fps”。
你看，这就是一条从“问题”到“方案”的推导链。我在做LKA项目时，最怕的就是这条链断了。比如安全目标定得太模糊，后面所有设计都会跑偏。
核心要点：安全目标必须可验证、可测试。不能写“系统要足够安全”，要写“系统在驾驶员无干预时，横向偏差不得超过0.3米”。
2.2 ASIL：风险等级怎么定？
ASIL，全称是Automotive Safety Integrity Level。你想想看，一个功能失效了，后果有多严重？ASIL就是用来量化这个“严重程度”的。
它由三个参数决定：
- 严重度 (Severity, S)：伤人吗？伤多狠？S0（无伤害）到S3（致命）。
- 暴露率 (Exposure, E)：这个危险场景常见吗？E0（几乎不）到E4（非常常见）。
- 可控性 (Controllability, C)：驾驶员能救回来吗？C0（完全可控）到C3（几乎不可控）。
然后查表，得出ASIL等级：
| 严重度 (S) | 暴露率 (E) | 可控性 (C) | ASIL等级 |
|---|---|---|---|
| S2 | E3 | C2 | ASIL B |
| S3 | E4 | C3 | ASIL D |
| S1 | E2 | C1 | ASIL A |
嗯，这里要注意：ASIL D是最高的，要求最严苛。比如刹车系统，通常是ASIL D。而车道保持，我见过很多项目定的是ASIL B或C。为什么？因为驾驶员还能接管，可控性相对好一些。
我的经验：别一上来就定ASIL D。那意味着你要做大量冗余设计，成本翻倍。先做HARA（危害分析与风险评估），实事求是地定级。我曾经见过一个项目，把车窗升降定成ASIL D，纯粹是拍脑袋。
2.3 ASIL分解：把大石头敲碎
好，现在你定了一个ASIL C的安全目标。但问题来了——你只有一个摄像头，一个控制器。单点故障怎么办？
这时候就需要ASIL分解。说白了，就是把一个高等级的安全要求，拆成两个或多个低等级的要求，然后通过冗余或独立设计来实现。
举个例子：
假设安全目标是“车道保持功能必须达到ASIL C”。
你可以这么分解：
- 路径A：主控制器 + 主摄像头 → 承担ASIL B
- 路径B：冗余控制器 + 冗余摄像头 → 承担ASIL A
两条路径加起来，通过“相互监控”或“降级策略”，整体达到ASIL C。
为什么能这么干？因为ISO 26262允许你通过独立性来降低单条路径的要求。两条路径不能有共因失效（比如同一个电源、同一个时钟）。
避坑指南：我曾经犯过一个错。我把ASIL C分解成两个ASIL B，但两条路径用了同一个软件库。结果FMEA一分析，发现一个bug能同时搞死两条路径。嗯，那分解就白做了。记住：独立性是分解的前提。
2.4 分解的数学逻辑
ASIL分解不是随便拆的。它有严格的代数规则：
- ASIL D = ASIL B(D) + ASIL B(D) 或 ASIL C(D) + ASIL A(D)
- ASIL C = ASIL B(C) + ASIL A(C) 或 ASIL A(C) + ASIL A(C) + ASIL A(C)
- ASIL B = ASIL A(B) + ASIL A(B)
括号里的字母表示原始等级。你看，分解后每个子项都要带个括号，标明它“出身”于哪个等级。这是为了追溯。
我个人习惯，在系统架构文档里，用一张表来记录分解关系：
| 安全目标 | 原始ASIL | 分解路径 | 子项ASIL | 独立性要求 |
|---|---|---|---|---|
| 避免非预期车道偏离 | ASIL C | 主路径 | ASIL B(C) | 独立电源、独立通信 |
| 监控路径 | ASIL A(C) | 独立传感器、独立算法 |
你想想看，有了这张表，评审的时候大家一目了然。谁负责哪条路径，清清楚楚。
2.5 实战中的ASIL分解策略
在LKA项目中，我常用的分解策略有三种：
- 功能冗余：两个不同的算法同时计算，结果交叉校验。比如一个基于视觉，一个基于高精地图。
- 监控与响应：主路径做控制，监控路径只做“看门狗”。一旦发现异常，直接降级或报警。
- 时间冗余：同一个功能在不同时间窗口内重复执行，但要求硬件能容忍延迟。
我个人比较推荐第二种。为什么？因为监控路径通常只需要检测故障，不需要高精度控制，所以可以用更低成本的硬件。我在一个量产项目里，就用一个低成本的MCU做监控，主路径用高性能SoC。成本控制得很好。
关键提醒：ASIL分解不是终点。分解完后，你还要做安全分析（比如FMEA、FTA），证明分解后的架构确实能覆盖所有故障模式。别偷懒，这一步省不了。
2.6 小结
ISO 26262的核心，就是让你系统化地管理风险。ASIL分解，则是让你在成本和安全性之间找到平衡。别把它当成负担，它其实是你的设计指南。
下一章，我会带你走一遍HARA的全流程。到时候咱们拿一个真实的LKA场景来练手。嗯，那才是真正有意思的部分。