ISO 26262-9(2018)ASIL 分析细化:分解规则 / 共存 / DFA / 安全分析

这一节先把“8 种允许的分解组合(5.4.9)”的判断维度收拢到同一视图里，后面的表格用于横向比较各选项的边界。

括号里是 SG 的初始 ASIL——B(D) 表示"这个分支按 ASIL B 开发,但它 trace 回去的 SG 是 ASIL D"。即使是 QM(D),也比 QM 严:文档要求保留、change control 比纯 QM 严。

这一节先把“三种 ASIL D 分解的工程取舍”的判断维度收拢到同一视图里，后面的表格用于横向比较各选项的边界。

实务:最常见是 C(D) + A(D) —— 主控 + 简单监控的非对称组合。B(D) + B(D) 用于真双冗余(转向、刹车主驱)。

5.4.3 强调:两个分支必须 sufficiently independent——独立性不够时分解无效,两个分支都按 D 开发(没有降级)。

DFA(Clause 7)就是给独立性论证用的——找"共因失效"和"级联失效",论证不存在或被缓解。没 DFA 的 ASIL decomposition 是审计大坑。

最常见的分解形式:初始 ASIL D 的"主功能 + 安全机制"组合分解——

• 主功能拿低 ASIL(因为故障由 SM 检测兜底)
• 安全机制拿高 ASIL(因为它的失效直接违反 SG)

例:扭矩控制 ASIL D → 主算法 QM(D) + 扭矩监控 SM ASIL D(D)。意味着主算法 QM 开发 + SM ASIL D 开发——大部分工作量在 SM,主算法用现成 motor control 代码就行。

但这种分解很难——SM 必须能在 FTTI 内独立检测主算法所有故障。简单 watchdog 不行(只检 hang),要做 plausibility check + redundant computation。

可以多次分解。例:ASIL D → C(D) + A(D),C(D) 再分 → B(D) + A(D)(注意:保留括号是初始 SG 的 ASIL)。这样最终有 3 个分支:B(D) + A(D) + A(D)。

实务上重复分解少见(每次分解都要新独立性论证),但理论上允许。

核心要求:同一个 element 内有不同 ASIL 的 sub-element 共存时,低 ASIL 子元件想保持低 ASIL,必须证 freedom from interference。否则——所有共存子元件继承"最高 ASIL"。

例:一个 MCU 上同时跑:

• ASIL D 扭矩控制
• ASIL B 仪表盘亮灯逻辑
• QM 数据采集 logger

如果 freedom from interference(时间 / 空间 / 信息隔离)论证充分(MPU + AUTOSAR OS 时间预算),三块各按各 ASIL 开发。否则,QM 的 logger 也得按 ASIL D 开发。

低 ASIL 不能 violate 高 ASIL 的安全要求——文字看似宽松,实务上要求为每条高 ASIL 安全要求做一次 freedom from interference 论证(对每个低 ASIL 子元件)。审计员经常质问:"你的 logger 在 stack overflow 时会不会写到扭矩控制的内存?"

工程实操:没 MPU 的 MCU 等于强制混合按高 ASIL 开发 —— 这是 iso26262-part6-software 提到的"无 MPU 混合 ASIL 痛"。

这一节先把“两类 dependent failure”的判断维度收拢到同一视图里，后面的表格用于横向比较各选项的边界。

Independence(完全独立)要求两类都没有;Freedom from Interference(免干扰)只要求没有 cascading(单向 — 高 ASIL 不被低 ASIL 污染)。

ASIL decomposition 要 independence;Coexistence 只要 freedom from interference。

DFA 评估必须考虑(也是 audit checklist):

1. 随机硬件失效(共用时钟 / test logic / 内部 LDO 同时挂)
2. 开发缺陷(需求 / 设计 / 实现 / 新技术)
3. 制造缺陷(过程 / 流程 / 培训 / 控制计划)
4. 安装缺陷
5. 维修与服务缺陷
6. 应力(温度 / 振动 / EMC)
7. 环境(湿度 / 海拔 / 老化)
8. 共用资源(电源 / 时钟 / 内存 / 总线)

每条源都要在 DFA 报告里要么"否定存在"要么"给出缓解 SM"。

Annex C 给 DFA 框架:

1. 识别 coupling factors(耦合因子)— 共同的设计 / 工艺 / 元件 / 接口 / 物理位置
2. 找 root cause(根因)— 与 coupling factor 关联的可能事件
3. 判定可信度(plausibility)— 该 root cause 能否真发生
4. 设计缓解措施——隔离 / 多样性 / 检测 / 时间错开

实操:DFA 报告每个 coupling factor 一行,每行配一个 measure。常用 measure 表:

MCU + SBC 配对就是典型的"异工艺 + 独立电源域 + 物理隔离"组合——详见 MCU + SBC ASIL D 集成。

软件 FMEA(SW FMEA)比硬件 FMEA 难——硬件失效模式可枚举(短路 / 开路 / 漂移),软件失效模式不可枚举。常用法:

• 按软件 architectural element 分(每个模块视为一个 component)
• 按 failure 关键词列(wrong execution / data corruption / wrong control flow / deadlock)
• 按数据流接口列(每个接口可能 wrong data / wrong timing / no data)

FTA 从 SG 违反开始,向下推:"哪些 fault 组合能导致 SG 违反?"。每个分支用 AND/OR 门连接。最终 cut set(最小割集)给出"几条独立路径上的 fault 同时出现才能违反 SG"——这就是 ASIL decomposition 的物理基础。

工程模板:用商用 FTA 工具(Isograph、Reliasoft、ALD等),输入元件 FIT + 周期诊断 → 自动算 PMHF。