ASIL 分解(ASIL Decomposition)

ASIL D 工程比 ASIL B 贵 5-10×——在 MCU 选型、工具链(certified compiler)、verification 强度、文档密度上都成倍上涨。但 OEM 给的安全目标常常就是 ASIL D。ASIL 分解是把"系统级 ASIL D"在两个独立路径上分担,各路降到 ASIL B,大幅减成本——前提是两路真独立。

ISO 26262-9:2018 §5.4.9(配 Figure 2)给出合法的 ASIL 分解方案——D 族 3 种 + C 族 2 种共 5 种,任何分解都要落在标准方案里,否则不合规(2018 版正文并无 Table 1/3,老引用是 2011 版习惯,勘正 2026-07-10)。

ASIL B(D) 是 ISO 26262 的特殊标记 —— B 是这一路开发的实际 ASIL,(D) 是 inherited(继承的)系统级 ASIL。两个含义都重要:

最容易踩的坑:开发时按 ASIL B 跑工具链没问题,但 DFA / 独立性论证仍要按 ASIL D 严格度——否则两路共因失效让分解失效,系统降回 ASIL B。

ASIL 分解的合法性完全建立在两路独立——独立性破坏时,分解 illusion 立刻碎。ISO 26262 列了 4 类必须独立的方面:

把分解从概念变成可执行走 4 步——每步缺失或错误都让分解失效。

ASIL 分解失败集中在 5 个反模式——这 5 个共同特征是"看起来合法但实际共因没消除",让 ASIL D 系统实际只是 ASIL B 保护。

ASIL 分解的完整操作包含 4 步:识别候选需求 → 提议分解组合 → DFA 独立性论证 → 追踪 ASIL B(D) 分配。本节以 48V EPS(电动助力转向)ASIL D → B(D)+B(D) 分解为对象,走完全部 4 步,并在每步给出「什么会让分解失效」的工程理由。

ASIL 分解的 gotcha 大多在「看起来分解了但实际没有」的模式——DFA 跑了但漏了真正的共因。以下 7 条是从真实审计中总结的高频错误。

Gotcha-1: 同 SBC 供电「独立」双 MCU。工程师的两颗 MCU 用不同 PCB 区域、不同电源 pin,自认为「硬件独立」。DFA 复查后发现:两路都由同一颗 TLF35584 SBC 供电,SBC 是单点故障。真实案例:SBC 内部 LDO 出现短路(BOM 不一致导致降额失败),两颗 MCU 同时掉电,B+B「分解」失效,系统实际只有 QM 级保护。修法:监控 MCU 改用独立路径供电(独立 LDO 或独立 SBC),在 DFA 电源独立性检查表中明确标注每路的 power rail 来源,追溯到 PCB 物理铜皮和连接器。

Gotcha-2: 同 CAN 消息两路都订阅。两路 MCU 用来自同一 ECU(如 VCU)的同一帧 CAN 消息做算法输入(车速、加速度踏板信号)。VCU CAN node 故障时,两路同时丢失/错误接收。根本问题:数据源独立性被破坏。缓解方案有三:① 两路订阅物理上不同的传感器(如 Resolver + Hall 双传感器方案);② 若只有一路信号,在每路 MCU 上独立加 E2E 保护(不同 CRC 多项式),并且在 Safety Case 中登记「CAN 源单一为已知 CCF,通过 E2E+独立超时检测降低风险」;③ 最强方案:监控路不依赖 CAN,用独立物理信号(如 PWM 轮速脉冲)。

Gotcha-3: 锁步 MCU 当 B+B 分解。项目方选用 TC397 AURIX 锁步 MCU,声称「两个 CPU Core 构成 B(D)+B(D) 分解」。根本错误:锁步是单 ASIL D 元素的内部诊断机制(两 Core 执行相同代码、比较输出,检测 transient/random fault),不是 ASIL 分解。两 Core 共享 die、共时钟、共电源,本质是一个硬件单元。锁步的 SPFM/LFM 是 ASIL D 单元的失效覆盖度,不能拆开算 B+B 的独立两路。若想分解,主监必须是不同物理器件(不同封装)。

Gotcha-4: A(D) 路按 ASIL A 跑 DV 测试。D = A(D) + C(D) 分解,A(D) 路工程师看到自己负责的是「ASIL A」,用 ASIL A 的测试覆盖率跑 DV(statement coverage,不做 MC/DC,不做故障注入)。错误:(D) 括号在 DV 阶段意味着「与 C(D) 路的集成测试必须按 ASIL D 严格度」——联合验证要覆盖 D 级要求(含故障注入覆盖 ASIL D SPFM 目标)。每路单独测试按各自 ASIL(A 或 C),但系统集成测试不能简化为 A 级,否则 DFA 中的 CCF 缓解措施(需要系统级故障注入验证)根本没有覆盖到。

Gotcha-5: 变更后 DFA 未更新。M8 ECO:主控 MCU 因供货问题从 TC275 更换为 TC277(同平台但不同封装/supply variant)。工程师认为「只是封装变了,功能一样」,未更新 DFA。真实风险:TC277 与 TC275 的 PMIC 兼容性不同,更换后 TLF35584 的电流输出裕量降低,导致冷启动期间 SBC 过流——之前 CCF-1 已经「缓解」的结论在新硬件上失效。规则:任何 safety-relevant element 的变更(MCU、电源 IC、连接器、PCB stack-up)都必须触发 DFA 影响分析(change management checklist 中加 DFA-revisit 为 mandatory gate)。

Gotcha-6: 规范独立性只靠「分开 team」。DFA 声称:「我们两个 team 独立写了两个 Safety Requirements Specification(SRS),满足规范独立性」。审计发现:两个 SRS 都来自同一个上级 TSR 文档,TSR 本身没有经过独立 review。TSR 里有一个转矩限值写错(阈值单位混淆,mN·m 写成 N·m)——两个 SRS 都继承了该错误,两路 MCU 都按错误阈值实现。结论:规范独立不是「写两份文档」,而是「文档的错误不共传播」。最低要求:TSR 本身由独立人员做交叉 review,review 结论进 Safety Case;理想:监控路 SRS 由不同背景 engineer 从 SG 重新推导,而非从 TSR 复制。

Gotcha-7: 独立性证据只有纸面 DFA,缺运行态验证。DFA 报告写了「两路无硬件共因」,但未包含故障注入测试(将一路 MCU 主动断电/注入 stuck-at fault,验证另一路确实能检测并触发 STO)。实质:纸面 DFA 是假设,运行态故障注入才是地面真相。若监控 MCU 的 torque compare 窗口设置错误(阈值用了 mN·m 单位但实际阈值是 N·m,放宽了 100×),在正常运行中两路一起工作时绝不会发现,直到故障注入测试才能揭露。ISO 26262-9:2018 用 Clause 5 定义分解、Clause 7 的 DFA 提供「充分独立」的证据——独立性声明必须有对应验证活动(含故障注入)作为 evidence,否则分解在 Clause 7 层面根本不成立。

分解的判据不是二值的,几类边界工况会改变结论。以下 3 条是实务里最常引发争论的边界。

Corner-1: 工具链统一 vs 规范独立要求。Tier1 为了成本效率,主控和监控共用同一 IDE(Vector DaVinci + TASKING),同一版本控制系统(Git Monorepo),甚至同一 AUTOSAR BSW(EB tresos 双许可证)。表面上「两路独立」,实际上 IDE 本身的 bug(配置丢失、代码生成错误)是共因。结论:工具链是否算「共因」取决于 ISO 26262-8:2018 Clause 11(软件工具置信度)。TCL 由 Tool Impact(TI1 无影响 / TI2 可能引入或漏检错误)× Tool error Detection(TD1 高 / TD2 中 / TD3 低,能否检出或防止工具错误)推出 TCL1–TCL3:TI1 → TCL1(无需鉴定);TI2 时 TCL 随 TD 变差而升高,TCL2/TCL3 的工具需 qualification(增加使用信心、评估开发流程、验证、或按安全标准开发)。判据是:若共用工具达 TCL1(错误要么不影响安全功能、要么必被检出),共用可接受;若工具落在 TCL2/TCL3 且缺独立检出手段,共用同一版本就是 coupling factor,须版本/工具链分离或补独立验证。

Corner-2: ASIL D 系统降级为 ASIL C 后分解策略变化。项目中期,HARA 复审后某 SG 从 ASIL D 降到 ASIL C(E 重新评估降了一级)。原有 B(D)+B(D) 架构此时可简化为 ASIL B(C)+ASIL A(C),理论上节省监控路一档开发成本。实战建议:不要为降一档而重构——已有 B(D)+B(D) 架构在 ASIL C 场景下等价或超满足,重构引入的变更风险(DFA 重跑、认证重做)远大于节省的开发成本。这是「ASIL 过设计」的正面案例:设计选档略高于需求,变更稳定后才优化。

Corner-3: 供应链风险下的独立性(同 fab 两颗不同 MCU)。主监 MCU 来自不同品牌(Infineon + Cypress),但两者都在台积电 40nm 制程加工。fab 级别的工艺系统缺陷(如某批次 40nm 栅氧化层问题)理论上可同时影响两路。ISO 26262 的处理:制程级系统缺陷属 systematic failure,不在 FMEDA 随机失效范围,标准把它交由 DFA 定性排查 + 在 SEooC 的 AoU 中声明「不同 die / 不同设计的同 fab 共因不在本 DFA 范围内」,由 OEM 系统集成方承担这一已知 residual risk。需说明:ISO 26262 并不强制不同 fab——对最高关键项(如制动、转向),个别 OEM 出于商务要求主监使用不同晶圆厂的 die 以彻底消除 fab 共因,这非标准条款,会显著增加供应链管理成本,需 OEM 商务决策。

• standard · standard_iso26262_part9 — ISO 26262 Part 9 ASIL Analyses