ISO 26262 ASIL 分解三个最常被理解错的规则技术独立性、硬件度量、5.4.4先说结论ASIL 分解要求的独立性是技术独立5.4.3“不同团队开发”只是组织独立不构成分解依据。分解不影响硬件架构度量与随机硬件失效评估5.4.5硬件这侧目标值按分解前的 ASIL 不变。每个分解后的安全需求必须独自满足初始安全需求5.4.4“两个加起来勉强顶一个”不成立。任何分解方案不得出现两个 QMASIL B 只能 A(B)A(B) 或 B(B)QM(B)5.4.10。背景D 拆成 BB为什么吸引人ASIL D 意味着全线最高一档硬件架构度量、软件结构覆盖率、文档、流程、确认措施。按 Part 9 的 5.4.10ASIL D 允许三种分解分解方案说明C(D) A(D)一路按 C一路按 AB(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.5ASIL 分解不影响硬件架构度量的评估也不影响随机硬件失效的评估。即D 拆成 BB 后SPFM / LFM / PMHF 仍按初始 ASIL 的目标值评估。降的是系统性失效这一侧的开发严格度随机硬件失效那一侧原地不动。相关联的两条6.4.7 NOTEPart 5能控制故障但不满足 FTTI 的安全机制既不能计入第 8/9 章度量也不能用于 ASIL 分解。10.4.2 NOTEPart 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任何分解不得出现两个 QMASIL 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有没有出现两个 QM5.4.10技术独立性有没有 DFA 支撑共用电源/时钟/工具链评估过吗5.4.3硬件架构度量与随机硬件失效目标是否仍按分解前 ASIL5.4.5被分解元素的集成计划是否按分解前 ASIL 安排Part 5, 10.4.2参考ISO 26262-9:2018 §5.4.3、§5.4.4、§5.4.5、§5.4.10ISO 26262-5:2018 §6.4.7 NOTE、§10.4.2 NOTE条款号按 ISO 26262:2018 系列标注。北极星笔记分享 ISO 26262 功能安全条款解读、工程案例与学习笔记。