Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

2.14 ASIL分解——降级但不变弱

免疫隐喻：分布式免疫——不把鸡蛋放在一个篮子里

人体的免疫防御从来不是单一机制。皮肤是第一道物理屏障，如果它被突破，固有免疫系统中的巨噬细胞和补体蛋白立即响应。如果病原体依然突破了这层防线，适应性免疫系统就会被激活：树突状细胞提取抗原，呈递给T细胞，T细胞激活B细胞产生特异性抗体。这三层防御各自独立运作，共用同一份“安全目标“（防御外来病原体），但任何一层失效都不会导致整体免疫崩溃。

这就是ASIL分解的核心哲学。一个ASIL D的安全目标，按照ISO 26262的要求，单点故障度量（SPFM）要≥99%，潜伏故障度量（LFM）要≥90%，随机硬件失效概率度量（PMHF）要小于10 FIT。要实现这些指标，你需要在硬件上投入大量冗余和诊断：双核锁步处理器、ECC内存、电源监控、看门狗、完整的BIST……成本高昂，设计复杂。

但你有没有想过另一种思路？不把ASIL D塞进一颗芯片里，而是让两颗独立的芯片各自承担ASIL B，共同达成ASIL D的安全水平。这就是ASIL分解：把一个“难“的安全问题，拆成两个“容易“的安全问题。容易，但不脆弱。就像免疫系统的分层防御：任何一层被突破，其他层依然在守卫。

场景：转向ECU的双MCU架构

下午三点，你在设计评审室的白板上画了两个方框。

左边方框：“主控MCU（Infineon TC3xx）”。右边方框：“安全监控MCU（TI Hercules TMS570）”。中间画了一道粗粗的隔离线。你的目标是：ASIL D级别的转向助力安全。

你面对的问题是这样的：如果只有一颗MCU，要达到ASIL D，你需要双核锁步、ECC、MBIST、LBIST、电源监控、外部看门狗、冗余传感器通道……物料成本、PCB面积、软件复杂度全线飙升。但如果你把功能拆分：主控MCU负责正常的转向助力控制逻辑，安全监控MCU负责独立校验主控是否正常工作：每一颗芯片只需要做到ASIL B。两颗ASIL B的芯片通过充分独立的架构组合在一起，达到ASIL D的安全完整性。

你在白板上写下：ASIL D = ASIL B(D) + ASIL B(D)。

括号里的“（D）“是关键。它表示这个要素承载的是原始ASIL D的安全目标，但通过分解，它自身的开发要求降到了ASIL B。括号表示“血统”。这个要素是从ASIL D分解而来的，不是天然就是B。

你的同事从对面抬起头：“为什么要搞这么复杂？一颗ASIL D的芯片不好吗？”

你说：“一颗ASIL D的芯片当然好，但ASIL D的MCU选择比ASIL B少得多，而且贵得多。两颗ASIL B MCU的选择范围广，供应链安全更好，而且这个架构天然提供了物理冗余。如果一颗MCU被EMI打穿，另一颗还能检测到并触发安全状态。”

“那为什么不在同一颗芯片里做两个软件分区？那样成本更低。”

你拿起红笔，在板子上打了个叉：“这就是今天要讲的第一个陷阱。”

分解方案：三种合法的降级路径

ISO 26262-9 Clause 5定义了ASIL分解的正规语法。对于ASIL D，你可以降级为：

方案一：C(D) + A(D) 主要素降为ASIL C，辅助要素降为ASIL A。这是“强弱搭档“：主力承担大部分安全责任，辅助做关键检查。适合主控MCU能力较强、监控MCU只需做简单诊断的场景。

方案二：B(D) + B(D) 两个要素都降为ASIL B。这是“双胞胎方案“：两个同等能力的芯片互相监督。这是最常见的架构，也是转向ECU的典型选型。

方案三：D(D) + QM(D) 一个要素保持ASIL D，另一个要素降为QM（Quality Managed，无安全要求）。这听起来矛盾。如果辅助要素是QM，将来它失效了，主ASIL D要素必须能独立维持安全。这种方案适用于“辅助功能可有可无，不影响安全“的场景，比如安全关断路径的主开关是ASIL D，辅助的软启动电路是QM：软启动电路坏了，最多是不能平滑启动，但主开关依然能可靠关断。

对于ASIL C的分解：

  • B(C) + A(C) ： 一个降为B，一个降为A
  • C(C) + QM(C) ： 一个保持C，一个降为QM

对于ASIL B的分解：

  • A(B) + A(B) ： 两个都降为A
  • B(B) + QM(B) ： 一个保持B，一个降为QM

你在白板上画出了这个降级树，然后用力在“硬件指标不变“上画了个圈。

黄金法则之一：硬件指标不随分解而降低

这是ASIL分解中最容易犯错的规则。你把ASIL D分解成B(D)+B(D)，开发流程要求（Part 2, 3, 4, 5, 6, 8, 9中与系统性失效相关的活动）可以按降级后的ASIL执行：主控MCU按ASIL B做软件开发和测试，监控MCU也按ASIL B做软件开发和测试。但是，硬件架构度量（SPFM、LFM）和随机硬件失效概率评估（PMHF）仍然必须满足原始ASIL D的目标值。

这意味着什么？即使你的两颗MCU各自按ASIL B开发，整体硬件的SPFM仍然要≥99%，PMHF仍然要<10 FIT。你不能因为做了分解，就在硬件安全机制上偷工减料。你可以用更简单的软件流程，但不能用更差的硬件诊断覆盖。

这是ISO 26262的一项深刻洞察：硬件随机失效是物理现象，不会因为你的分解而减少。 两颗ASIL B芯片的晶体管总数比一颗ASIL D芯片更多，潜在失效模式更多。你必须用足够的硬件安全机制把这些失效控制住：ECC、锁步、BIST、电源监控一样都不能少。ASIL分解降低的是“开发系统性错误的概率“，不是“硬件随机失效的概率“。

黄金法则之二：充分独立性——分解的生命线

你把ASIL D拆成B(D)+B(D)，现在要回答一个致命问题：你怎么保证这两个B(D)不会同时失效？

如果两颗MCU共享同一个电源轨，而电源轨的过压瞬态同时烧毁了两颗芯片，你的分解就完全失效：一个共因失效（Common Cause Failure, CCF）瞬间打穿了你的全部冗余。这就是为什么ISO 26262-9对ASIL分解提出了严苛的独立性要求：

  1. 必须有依存性失效分析（DFA，Dependent Failure Analysis）证明不存在可信的依存性失效。DFA是分解的前置条件，不是可选动作。你必须在架构设计阶段就进行DFA，识别所有耦合因素：共享电源、共享时钟、共享PCB基板、相同的芯片型号、相同的开发工具链。然后逐一分析它们是否会导致共因失效或级联失效。

  2. 如果DFA无法排除某些耦合因素，你必须将共因失效视为原始ASIL等级的单点故障来处理。比如两颗MCU共享同一路电源，而电源失效会影响两者。那就要在电源设计上投入与ASIL D匹配的冗余和安全机制（双路独立电源、电源监控、欠压保护等）。

  3. 同构冗余不能简单地作为ASIL降级的依据。这是ISO 26262-9第5.4.6条的关键陈述：“The use of homogeneous redundant elements is, without further measure, not sufficient to reduce the ASIL because the same systematic fault could cause a common cause failure of the redundant elements.”（同构冗余要素的使用，在没有进一步措施的情况下，不足以降低ASIL，因为相同的系统性故障可能导致冗余要素的共因失效。）

翻译成人话：两颗相同型号的MCU跑相同的代码。这不叫ASIL分解，这叫“同一个bug跑两份“。如果主控MCU的固件有一个系统性缺陷（比如在特定时序下会除以零），监控MCU跑着相同的代码，它会在同样的条件下触发同样的bug。两个都挂了，ASIL D变成了“两个同时失效的B“。

异构是ASIL分解的最佳实践。 主控用Infineon TC3xx，监控用TI Hercules TMS570。不同的指令集（TriCore vs ARM Cortex-R），不同的编译器（Tasking vs TI CCS），不同的开发团队。系统性缺陷在两者之间同时出现的概率趋近于零。即使一方有bug，另一方依然能独立检测到异常并触发安全状态。

黄金法则之三：集成活动在分解前的ASIL执行

ISO 26262-9 Clause 5.4.5规定：集成活动（Integration activities）必须在分解前的ASIL等级执行。 也就是说，虽然主控MCU和监控MCU各自按B(D)开发，但当它们集成在一起形成完整的转向ECU系统时，集成测试、集成验证、整车集成。这些活动必须回到ASIL D来执行。

这是ASIL分解中最容易被忽略的一条。你把两个ASIL B的东西拼在一起，它们的接口、时序、协调逻辑。这些东西本身构成了一个新的复杂度层级。两颗芯片通过SPI通信：SPI的电气特性、时序抖动、协议异常、仲裁失败。这些是ASIL B开发覆盖不到的场景。你必须以ASIL D的严谨度来验证整个集成体的行为。

在你的转向ECU架构中，这表现为：

  • 主控MCU和监控MCU之间的SPI通信必须有端到端保护（E2E Profile 1，CRC+SQC）
  • 监控MCU对主控MCU的“心跳检查“必须在ASIL D的时限要求内完成（即故障容错时间间隔FTTI内）
  • 两个MCU之间的“握手失败“处理逻辑必须按ASIL D验证：不能有死锁、不能有活锁、不能有静默失效
  • 整车级别的安全验证（故障注入测试、长期测试、用户测试）必须覆盖这个集成体，不能只测单个MCU

场景回响：白板上的红圈

回到下午的评审室。你在白板上画完最后一笔。你的同事盯着那四个圈，沉默了一会儿，然后说：“所以ASIL分解不是免费的午餐。”

对。ASIL分解不是免费的午餐。它是一笔交易：你用两套ASIL B的开发流程替代一套ASIL D的开发流程，但你付出的代价是：

  1. 硬件指标不能降：该有的安全机制还得有
  2. 必须证明充分独立：DFA是硬门槛
  3. 集成活动回到原始ASIL：拼起来的时候必须更严格
  4. 不能用同构冗余糊弄：异构才是正道

“值得吗？”

“当ASIL D的MCU只有两三家供应商、交货期52周、单价200美元的时候，两颗ASIL B MCU：选择面宽、交货快、单价加起来才80美元：即使加上DFA和异构设计的额外成本，总体还是划算的。而且架构本身获得了物理冗余。这是单芯片方案天然不具备的优势。”

你把白板拍下来，存进项目的架构决策记录（ADR）里。这个决策的每一条理由：技术、成本、供应链、安全性：都记录在案。安全设计不是一个纯技术问题，它是在约束条件下寻找最优解。ASIL分解是这个最优解工具箱里的一把利器：锋利，但必须谨慎使用。

本篇小结

  1. 三种降级方案：C(D)+A(D)、B(D)+B(D)、D(D)+QM(D)
  2. 硬件指标不随分解降低
  3. 充分独立性是分解的生命线：DFA必须证明无共因，同构冗余不能作为降级理由
  4. 集成活动回到分解前的ASIL执行

【下集预告】： ASIL分解说“两颗独立MCU各做B(D)“，但你怎么证明它们真的独立？如果共享同一路电源，一个过压脉冲同时打穿两颗芯片，你的分解方案就碎了。下一节把两个工具装进你的工具箱：FTA从安全目标出发向下追溯故障树，DFA从耦合因素出发横向检查所有“独立假设“是否成立。两者互补，缺一不可。