汽车功能安全的“独立性“要求：为什么两个系统“都好“不等于“一起好“

一个看似悖论的工程问题

有一道功能安全领域经典的思考题：

假设你有两个检测传感器，每个传感器单独的可靠性都是99%，你用它们做冗余方案（任一个检测到故障就触发保护）。那么这个冗余系统的整体可靠性是多少？

很多人的第一反应是：比99%更高，接近99.99%（两者同时失效的概率是0.01%×0.01%=0.0001%）。

但这个答案的前提是：两个传感器的失效彼此独立。如果两个传感器安装在同一个位置、使用同一电源、经历同一环境，当某个环境因素导致一个传感器失效时，大概率同一因素也会导致另一个传感器失效。在这种情况下，"冗余"提供的保护可能远比你想象的少。

这就是ISO 26262在功能安全分析中重点关注的"独立性（Independence）"问题，具体体现为“相关失效分析（DFA，Dependent Failure Analysis）”的要求。

相关失效的两种类型

ISO 26262将相关失效分为两大类：

共因失效（CCF，Common Cause Failure）

多个系统因为同一个根本原因同时失效。上面例子中的两个传感器共享电源，就是一种典型的共因失效场景。

在车规MCU的应用中，共因失效的典型来源：

• 共享电源：两个冗余控制器使用同一路电源，电源故障导致两者同时失效
• 共享时钟：锁步双核的两个核心共享一个时钟树，时钟故障影响两个核心
• 共享冷却：多个ECU安装在同一个散热器上，散热失效导致所有ECU同时过温

级联失效（Cascading Failure）

一个组件的失效导致了另一个组件的失效。比如：电源电压失调→控制器重置→控制输出错误→执行器损坏→机械故障。每一步失效都是前一步的直接结果，形成一个因果链。

DFA在车规MCU开发中的具体要求

ISO 26262 Part 9专门定义了相关失效分析（DFA）的方法和要求。对于ASIL-C和ASIL-D的系统，DFA是必须执行的安全分析活动。

DFA的分析目标：识别所有可能导致相关失效的"共因"，评估其对安全目标的影响，并确保：

1. 对于ASIL-D系统，每个单点故障都有覆盖措施、
2. 对于ASIL分解方案，两个独立通道之间不存在未被覆盖的共因失效
3. 所有潜伏故障都能在MFTTI内被检测到

MCU层面的DFA考量：

当一颗MCU通过ASIL分解支持两个独立的ASIL-B通道时，DFA需要分析：

• 芯片内部的独立性：两个ASIL-B通道在MCU内部是否有共享的硬件资源，这些共享资源是否是相关失效的来源
• 封装级别的共因：同一封装内的两颗Die（如MCU+Safety Companion），它们之间是否有共用的封装内部连接，热应力是否会同时影响两颗Die
• 外部故障注入路径：通过I/O引脚注入的电磁干扰（ESD、Burst）是否可以同时影响两个独立通道

独立性的量化：ISO 26262的要求

ISO 26262对独立性有定性要求但也提供了一些量化指导。

对于ASIL-D的ASIL分解（D→B+B），ISO 26262要求证明两个B通道之间的相关失效率足够低，以至于相关失效不会显著降低分解方案达到D级的等效安全性。

这个"足够低"在实践中通常通过以下方式证明：

设计措施的有效性论证：列举所有可能的共因，说明采取了哪些设计措施来削减共因影响，并论证这些措施的有效性。

残余共因失效率估计：对于无法完全消除的共因，估计该共因导致两个通道同时失效的概率，并论证这个概率在可接受范围内。

独立性评估矩阵：有些安全认证机构要求提交结构化的独立性评估矩阵，逐项列举所有可能的共享资源和外部影响，及其独立性证明。

一个需要特别关注的场景：ASIL分解与芯片复用

在实际项目中，有一个常见的设计模式值得特别讨论：使用同一型号MCU的两颗芯片，实现ASIL-D→ASIL-B+ASIL-B的分解。

表面上看，两颗物理上独立的MCU，似乎可以实现充分的独立性。但DFA分析可能揭示：

系统设计缺陷（Systematic Fault）：如果两颗MCU运行的是同一份软件代码，这份代码中的一个系统性bug，会同时影响两颗MCU——因为系统性缺陷的来源是相同的设计，而不是随机的制造缺陷。

ISO 26262对此有明确规定：ASIL分解只能有效降低随机硬件失效（Random Hardware Failure）的影响，对于系统性失效（Systematic Failure），不能仅靠硬件冗余来实现ASIL分解。要实现有效的软件层面ASIL分解，两个通道必须使用不同设计（Diverse Design）——不同算法实现、不同团队开发，甚至不同编程语言，以保证两者不共享系统性失效的根因。

这个要求在工程上代价很高，这也是为什么高ASIL等级系统的开发成本居高不下的原因之一。

对MCU设计的启示

对于RISC-V车规MCU的设计者来说，上述分析给出了一些值得深思的设计方向：

在片上实现真正独立的安全岛（Safety Island）：安全岛有独立的电源域、独立的时钟域、独立的内存，与主处理器子系统在物理上具有最大程度的独立性。这使得Safety Island可以在主处理器发生系统性故障时，仍然独立地检测故障并切换到安全状态。

透明度支持DFA文档化：芯片供应商在安全手册中，应明确列出芯片内部的共享资源，以及已采取的隔离措施，为系统集成商的DFA提供可靠的输入。这种文档透明度，是专业车规芯片供应商与普通消费级芯片供应商的重要差别之一。

结语

独立性分析是功能安全系统设计中最考验系统思维的工作之一。它要求工程师打破"模块思维"——不能只看单个组件好不好，而要审视整个系统的失效相关性。两个各自ASIL-B的组件，如果共享了关键资源，加在一起不一定能等效于ASIL-D。

这个道理看起来简单，但在复杂的多组件系统中认真执行，需要系统性的分析方法和丰富的工程经验。理解DFA的要求，是汽车电子工程师从"会做功能安全分析"到"真正理解功能安全思维"的重要跨越。