3. ASIL分解原则：数学基础与约束条件

ASIL分解，说白了就是“风险分摊”。你想想看，一个ASIL D的功能，如果让一个团队独立完成，压力太大了。我个人的习惯是，只要项目允许，我都会优先考虑分解。为什么？因为分解之后，每个子系统的开发成本、验证难度都会显著下降。

但分解不是随便切一刀。它有严格的数学规则、约束条件，还有最关键的——冗余与独立性要求。这一章，我们把这些硬骨头啃下来。

3.1 ASIL分解的数学基础

ISO 26262里给出了一个非常简洁的公式：

ASIL x = ASIL y + ASIL z

这个公式的意思是：一个ASIL x等级的安全目标，可以分解为两个（或更多）独立的子安全要求，分别分配ASIL y和ASIL z。只要y和z的“组合”能够覆盖x的风险。

具体怎么组合？看这张表：

原始ASIL	分解方案1	分解方案2	分解方案3
ASIL D	ASIL C + ASIL A	ASIL B + ASIL B	ASIL D + ASIL A（QM）
ASIL C	ASIL B + ASIL A	ASIL C + QM	—
ASIL B	ASIL A + ASIL A	ASIL B + QM	—
ASIL A	ASIL A + QM	—	—

举个例子。一个ASIL D的刹车控制功能，我可以分解成：

• 路径1（主控）：ASIL C
• 路径2（监控）：ASIL A

这样，主控路径只需要按ASIL C开发，监控路径按ASIL A开发。两个加起来，仍然满足ASIL D的要求。

3.2 分解的约束条件

这里我要强调一个我踩过的坑。有一次，我把一个ASIL D的功能分解成ASIL C + ASIL A，结果评审的时候被安全专家怼了。为什么？因为我没有满足“独立性”要求。

分解必须满足以下约束：

1. 冗余性：分解后的每个部分，必须能独立完成安全目标。不能出现“缺了A，B就干不了活”的情况。
2. 独立性：各部分之间不能有“共因失效”。比如，两个子系统共用同一个电源、同一个传感器、同一段代码库，那就不叫独立。
3. 覆盖性：分解后的ASIL组合，必须能覆盖原始ASIL的所有风险。不能出现“漏掉某个故障模式”的情况。
4. 可追溯性：从安全目标到分解后的子要求，必须有一条清晰的追溯链。评审的时候，人家会一条一条对。

3.3 冗余与独立性要求

冗余和独立性，是ASIL分解的“灵魂”。没有冗余，分解就是空谈；没有独立性，冗余就是摆设。

3.4 冗余架构的常见形式

我见过最多的冗余架构有两种：

• 1oo2（一取二）：两个通道都工作，只要一个通道输出正确，系统就安全。常用于ASIL D的刹车、转向等。
• 2oo2（二取二）：两个通道必须一致，系统才输出。常用于ASIL C的监控功能。

你想想看，1oo2和2oo2对独立性的要求完全不同。1oo2允许两个通道有差异，但2oo2要求两个通道必须“同步”。

3.5 独立性怎么保证？

独立性不是嘴上说说，得有具体措施。我列几个常见的：

维度	要求	常见实现
硬件	不同电源、不同时钟、不同IO	双MCU、独立看门狗
软件	不同算法、不同编译器、不同开发团队	冗余编码、多样化实现
时序	不同时间窗口、不同触发条件	交错采样、异步处理
数据	不同存储区域、不同校验方式	ECC、CRC、双缓冲区

3.6 ASIL分解的完整流程

下面这张图，是我自己总结的ASIL分解决策流程。每次做新项目，我都会拿出来对照一遍。

这个流程我用了很多年。每次评审，只要按这个流程走一遍，基本不会出大问题。

3.7 一个完整的分解案例

最后，我分享一个实际案例。某项目需要实现ASIL D的“线控制动”功能。我们是这样分解的：

• 安全目标：制动响应时间 < 200ms，失效率 < 10⁻⁹/h（ASIL D）
• 分解方案：ASIL C（主控路径）+ ASIL A（监控路径）
• 冗余实现：
  • 主控路径：MCU1 + 独立电源 + 独立传感器
  • 监控路径：MCU2 + 独立电源 + 独立传感器
  • 两个MCU之间通过SPI通信，但互不依赖
• 独立性验证：
  • 共因失效分析（CCF）：两个MCU不同批次、不同封装
  • 故障注入测试：分别注入单点故障，验证另一条路径仍能工作

嗯，这一章的内容就到这里。ASIL分解不是万能的，但用好了，确实能大幅降低开发难度。记住：分解的核心是冗余，冗余的核心是独立性。这两条守住了，分解就成功了一大半。