3. ASIL分解的典型模式

好，咱们直接进入正题。ASIL分解这事儿，说白了就是把一个高安全等级的需求，拆成几个低等级的需求，分别交给不同的东西去实现。你想想看，一个ASIL D的系统，如果非要让一个零件扛下所有，那设计成本得多高？

我个人习惯，拿到一个安全目标后，第一件事就是看能不能做分解。能分解，后面就好办多了。下面这三种模式，是ISO 26262里明明白白写着的，也是我这些年用得最多的。

3.1 ASIL D → ASIL C(D) + ASIL B(D)

这是最经典的分解模式。一个ASIL D的要求，拆成一个ASIL C和一个ASIL B。注意看括号里的(D)，它表示这两个子元素合在一起，仍然要满足ASIL D的完整性要求。

我在做EPS（电动助力转向）项目时，就遇到过这个场景。转向管柱扭矩传感器的安全目标是ASIL D。我跟架构师商量了一下，决定这么拆：

• 主传感器路径：ASIL C(D) —— 负责主扭矩计算和故障检测
• 冗余监控路径：ASIL B(D) —— 负责交叉校验和看门狗

两条路径独立开发，但最终在系统层面，它们合起来必须达到ASIL D的残余风险水平。嗯，这里要注意，不是简单地把C和B加起来就等于D，而是通过架构上的独立性，让两个通道的随机硬件失效率满足D的要求。

3.2 ASIL C → ASIL B(C) + ASIL A(C)

ASIL C的分解，在实际项目中也很常见。比如一个制动系统的轮速传感器，原始安全等级是ASIL C。我建议这么拆：

• 主处理单元：ASIL B(C) —— 执行核心算法和故障响应
• 诊断监控单元：ASIL A(C) —— 执行周期性自检和合理性检查

为什么这么分？因为ASIL A的开发成本低啊。你想想看，ASIL A对流程的要求宽松很多，工具链也便宜。把监控部分放在ASIL A上，能省不少钱。

3.3 ASIL B → ASIL A(B) + ASIL A(B)

ASIL B分解成两个ASIL A，这个模式最轻量。两个通道都是ASIL A，但合起来要满足ASIL B的完整性。

我记得有个车身控制模块的项目，车窗防夹功能的安全目标是ASIL B。我们当时用了两个独立的霍尔传感器，每个传感器通道按ASIL A(B)开发。两个通道的信号做“与”逻辑判断，只要一个通道报故障，系统就停止关窗。

原始等级	分解模式	典型应用场景	我见过的坑
ASIL D	C(D) + B(D)	EPS扭矩传感器、线控制动	两个通道共用PCB layout，导致共因失效
ASIL C	B(C) + A(C)	轮速传感器、加速度计	ASIL A通道的覆盖率不够，合起来不达标
ASIL B	A(B) + A(B)	车窗防夹、门锁控制	两个通道的故障模式重叠，冗余失效

3.4 分解的核心逻辑：独立性

上面三种模式，看着是数字游戏，其实核心就四个字：相互独立。没有独立性，分解就是一张废纸。

我一般用下面这张图来跟团队讲清楚分解的逻辑：

你看这张图，从上到下，原始等级分解成两个子元素，每个子元素有自己的安全等级，最后组合起来要能覆盖原始等级的要求。中间那个“分解原则”框，是我特别强调的——功能冗余和相互独立，缺一不可。

3.5 分解后的验证要点

分解完了，不是万事大吉。你得验证两个东西：

1. 独立性验证：两个通道之间有没有共享的硬件、软件、数据？有没有共因失效的可能性？
2. 覆盖率验证：两个通道合起来，能不能覆盖原始ASIL等级要求的故障覆盖率？

我建议在安全案例里，专门开一节“分解合理性论证”，把上面两个验证的结果写清楚。否则审核员一问，你支支吾吾说不清楚，那就麻烦了。