ISO 26262 ASIL 分解三个最常被理解错的规则：技术独立性、硬件度量、5.4.4
先说结论
- ASIL 分解要求的独立性是技术独立（5.4.3），“不同团队开发”只是组织独立，不构成分解依据。
- 分解不影响硬件架构度量与随机硬件失效评估（5.4.5），硬件这侧目标值按分解前的 ASIL 不变。
- 每个分解后的安全需求必须独自满足初始安全需求（5.4.4），“两个加起来勉强顶一个”不成立。
- 任何分解方案不得出现两个 QM；ASIL B 只能 A(B)+A(B) 或 B(B)+QM(B)（5.4.10）。
背景：D 拆成 B+B，为什么吸引人
ASIL D 意味着全线最高一档：硬件架构度量、软件结构覆盖率、文档、流程、确认措施。按 Part 9 的 5.4.10，ASIL D 允许三种分解：
| 分解方案 | 说明 |
|---|---|
| C(D) + A(D) | 一路按 C，一路按 A |
| B(D) + B(D) | 两路各按 B，最常见的选法 |
| D(D) + QM(D) | 一路按 D，一路降为 QM |
选 B(D)+B(D) 后，软件开发严格度明显下降——这是它吸引人的原因，也是问题开始的地方。
规则一：技术独立，不是组织独立
判据（5.4.3）：相关失效分析（DFA）没有发现会导致违反初始安全需求的可信原因，或者每个已识别的原因都按初始安全需求的 ASIL 由适当的安全措施控制住。
标准自带的反例（5.4.3）：两片完全相同的微控制器，运行完全相同的软件，构成同构冗余，声称可分解为 B(D)+B(D) ——不成立。一个系统性失效（例如软件共有的缺陷）会同时干掉两路。
常见误判：把“不同团队、不同代码库、每周同步会”当成独立性证据。这些是组织措施，DFA 关心的是共用电源、共用时钟源、共用工具链这类共因。
*图 1 · 依据 ISO 26262-9:2018 §5.4.3
规则二：硬件的账一点不少
5.4.5：ASIL 分解不影响硬件架构度量的评估，也不影响随机硬件失效的评估。
即：D 拆成 B+B 后，SPFM / LFM / PMHF 仍按初始 ASIL 的目标值评估。降的是系统性失效这一侧的开发严格度，随机硬件失效那一侧原地不动。
相关联的两条：
- 6.4.7 NOTE（Part 5）：能控制故障但不满足 FTTI 的安全机制，既不能计入第 8/9 章度量，也不能用于 ASIL 分解。
- 10.4.2 NOTE（Part 5）：分解后元素的集成及后续活动仍按分解前的 ASIL 执行。
*图 2 · 依据 ISO 26262-9:2018 §5.4.5
规则三：每条分解需求必须独自顶住（5.4.4）
标准自带的反例：ASIL D 需求拆成“简单看门狗的 D(D) 需求 + 该 ECU 微处理器的 QM(D) 需求”——不可接受。简单看门狗覆盖不了微处理器在 ASIL D 下应覆盖的失效模式。
推论：分解不是靠“另一路兜底”。每一条分解后的需求，单独看都必须满足初始安全需求。
配套硬约束（5.4.10）：任何分解不得出现两个 QM；ASIL B 只能拆成 A(B)+A(B) 或 B(B)+QM(B)。QM(B)+QM(B) 直接不符合标准。
*图 3 · 依据 ISO 26262-9:2018 §5.4.4 / §5.4.10
落地检查清单
拿到一份 ASIL 分解方案时，按顺序问五个问题：
- 每条分解后的需求，单独能否满足初始安全需求？（5.4.4）
- 有没有出现两个 QM？（5.4.10）
- 技术独立性有没有 DFA 支撑？共用电源/时钟/工具链评估过吗？（5.4.3）
- 硬件架构度量与随机硬件失效目标，是否仍按分解前 ASIL？（5.4.5）
- 被分解元素的集成计划，是否按分解前 ASIL 安排？（Part 5, 10.4.2）
参考
- ISO 26262-9:2018 §5.4.3、§5.4.4、§5.4.5、§5.4.10
- ISO 26262-5:2018 §6.4.7 NOTE、§10.4.2 NOTE
条款号按 ISO 26262:2018 系列标注。
北极星笔记｜分享 ISO 26262 功能安全条款解读、工程案例与学习笔记。
