2.15 DFA与FTA——深入故障的根系
免疫隐喻：追溯病因——从症状到病原体
当你的身体发烧、咳嗽、乏力，你坐在医生面前。有经验的医生不会直接给你退烧药。她要做的是鉴别诊断。发烧可能是细菌感染，也可能是病毒感染，可能是自身免疫性疾病，甚至可能是肿瘤。医生从症状（顶事件）出发，列出所有可能的病因（中间事件），排除了感冒和肺炎（剪枝），最终定位到链球菌感染（基本事件）。这就是FTA：故障树分析。
与此同时，医生还要考虑一个更深层的问题：为什么你的免疫系统没有挡住链球菌？是因为你同时在服用免疫抑制剂？是因为天气骤冷使黏膜屏障受损？是因为年龄增长导致免疫功能衰退？这些因素不是病原体本身，但它们是耦合因素。它们让本来不致命的缺陷组合在一起成了致命组合。这就是DFA：依存性失效分析。
FTA问的是“什么会导致安全目标违反“。DFA问的是“为什么看起来独立的东西会一起失效“。两者互为补充，共同构成了安全分析的“根系“。当你在功能安全中无法回答“根因是什么“时，你没有安全论证，你只有猜测。
场景：转向系统失效的故障树
你在安全分析办公室里，面前的墙从天花板到地板是一整块白板。你手里拿着记号笔，正在画一棵倒置的树。
树的顶端，你写下顶事件：“转向系统丧失助力：SG-001”（Safety Goal 001）。这是HARA（危害分析与风险评估）的产物：转向助力丧失在高速行驶时可能导致ASIL D级别的危害。你的任务是：从这棵树的顶端开始，向下追溯每一个可能导致顶事件的故障路径，直到你找到不能再分解的“基本事件“为止。
第一层：OR门下的直接原因
你在顶事件下方画了一个粗体的OR门。转向助力丧失的直接原因可能有三个：
- MCU系统失效
- 电源系统失效
- 电机驱动系统失效
这三个中间事件用OR门连接：只要任何一个发生，顶事件就成立。这是你分析的第一层展开。每一个中间事件都代表一个需要进一步分析的子系统。
第二层：MCU系统失效的展开
你在“MCU系统失效“下方继续画OR门。MCU系统失效的可能原因：
- 主控MCU失效
- 安全监控MCU失效
- MCU间通信（SPI）失效
- 共用外围（晶振、复位电路）失效
注意最后一个：“共用外围失效”。这已经在暗示依存性了，但你先按OR逻辑继续展开。
第二层：电源系统失效的展开
- 主电源轨（12V）失效
- DC-DC转换器失效
- 电源监控/管理IC失效
- 去耦电容老化导致纹波超标
第二层：电机驱动系统失效的展开
- 三相桥驱动失效
- 相电流传感器失效
- 功率MOSFET过热关断
- 母线电压跌落
第三层：展开“安全监控MCU失效“：AND门出现
你继续展开“安全监控MCU失效“。因为监控MCU本身设计有冗余保护机制。你需要在它内部画出是什么样的组合会导致监控MCU在需要它的时候无法发现主控的故障。
你在“安全监控MCU失效“下方画了一个AND门：
主核计算错误（bit-flip）锁步比较器未能检测到bit-flip看门狗未能检测到锁步比较器的失效
这三个子事件用AND门连接。这是一个关键节点：只有当三者同时失效时，监控MCU才会在需要时无法发挥作用。AND门描述了冗余的保护：锁步比较器可以检测到bit-flip，看门狗可以检测到锁步比较器的失效。只有三层保护同时被打穿，监控MCU才会失效。
每一条到达顶事件的路径都是一个割集（Cut Set）。如果路径中有AND门，割集包含多个基本事件。如果只有OR门，割集就是一个单点。**最小割集（Minimal Cut Set）**是指不能再简化的割集：拿掉其中任何一个基本事件，顶事件就不再成立。
你在白板上逐层展开，直到每个分支都抵达基本事件：不能或不应进一步分解的底层故障。基本事件可能是：
- MOSFET封装焊点疲劳断裂（物理失效，概率可由FIT数据推算）
- 晶振起振失败（制造缺陷）
- MCU寄存器bit-flip（单粒子翻转，概率由宇宙射线通量和芯片面积推算）
- 电源IC输出过压（元件老化）
一棵完整的故障树画满了一整面墙。OR门构成了树的主干：单点故障直接向上传播。AND门是树的“安全网“：只有在多重冗余同时失效时，故障才会向上传播。
FTA的方法论：定性分析与定量分析
FTA有两种分析模式，服务于不同的安全论证阶段。
定性FTA关注的是逻辑结构。通过分析最小割集，你可以回答以下问题：
- 哪些单点故障可以直接导致安全目标违反？（这是最危险的：单点故障必须消除或控制到足够低的概率。）
- 哪些故障组合（AND门下的多事件割集）才会导致违反？（这些是潜在故障：必须证明每个事件都有足够的诊断覆盖来暴露它们。）
- 是否存在“意外的“最小割集。那些在架构设计时没有预料到的故障路径？（如果存在，你需要修改设计或增加安全机制。）
定性FTA帮助你理解故障的逻辑路径。它不关心概率。它只关心“会不会“。如果定性FTA揭示出任何单点故障能直达顶事件，而这个单点故障又没有经过任何安全机制的覆盖。这是一个必须在设计层面解决的缺陷，不能用概率论证来搪塞。
定量FTA引入了概率。每个基本事件被分配一个失效率（Failure Rate），通常表示为FIT（Failures In Time，每十亿小时失效次数）。对于AND门连接的多个基本事件，顶事件的失效率是各基本事件失效率的乘积（假设独立）。对于OR门，顶事件的失效率是各基本事件失效率之和（在低概率近似下）。
举个例子：如果监控MCU的bit-flip概率是100 FIT（10⁻⁷/h），锁步比较器失效概率是10 FIT（10⁻⁸/h），看门狗失效概率是10 FIT（10⁻⁸/h），那么这三个事件同时发生的概率（AND门输出的顶事件概率）约为：
- 100×10⁻⁹ × 10×10⁻⁹ × 10×10⁻⁹ = 10⁻²³ /h ： 完全可忽略。
但如果锁步比较器和看门狗共享同一个时钟源，而这个时钟源的失效概率是100 FIT（10⁻⁷/h），那么当时钟失效时，锁步比较器和看门狗会同时失效：AND门变成了只有两个独立事件（bit-flip和时钟失效），概率骤升为：
- 100 FIT × 100 FIT ≈ 10⁻¹⁴ /h ： 仍然很低，但比之前高了10亿倍。
这就是为什么DFA必须与FTA配合使用：FTA假设基本事件是独立的，但DFA验证这个假设是否成立。 如果DFA发现了耦合因素，FTA的定量计算结果可能严重低估实际风险。
定量FTA的适用范围有一个关键限制：它只处理随机硬件失效，不处理系统性失效。 你没有FIT数据可以描述一个软件bug的概率：bug不是随机的，它是确定性地存在于代码中的。如果代码在某个特定输入下一定会除以零，那失效率不是“低概率“，而是“条件触发时100%发生“。定量FTA不能给系统性错误赋予概率。这是ISO 26262-9第8章明确的约束。系统性失效必须通过流程（Part 2, 3, 4, 5, 6, 8）来控制，而不是通过概率计算来“稀释“。
DFA的方法论：共因失效与级联失效
FTA从上往下看，DFA从耦合因素往两边看。
**共因失效（Common Cause Failure, CCF）**是指单一事件导致多个要素同时失效。一个经典的例子：两颗冗余的MCU共享同一个外部看门狗芯片：看门狗芯片失效，两颗MCU都失去了监控，系统对二者的失效同时失明。另一个例子：两个传感器共享同一个电源轨：电源轨的过压瞬态同时烧毁两个传感器。
**级联失效（Cascading Failure）**是指一个要素的失效传播到另一个要素，导致后者也失效。比如：功率MOSFET短路导致大电流，大电流导致PCB铜皮烧断，PCB铜皮烧断导致MCU掉电。这不是“一个原因同时打两个“，而是“一个失效引发多米诺效应“。
ISO 26262-9 Clause 7要求你在架构层面系统性地识别和评估依存性失效。你不是凭空猜想。你对照**耦合因素分类（Annex C）**逐项检查：
1. 共享资源（Shared Resource）：电源、时钟、复位、PCB基板、散热器、连接器……任何被多个安全相关要素共享的物理资源都是潜在的耦合因素。你在FTA里假设MCU和监控器是独立的。但如果它们共享同一个12V转3.3V DC-DC转换器，这个转换器就是共因失效的候选者。
2. 共享信息输入（Shared Information Input）：两个安全要素依赖同一个传感器信号或同一个CAN报文。如果传感器故障输出一个“看起来正常但实际错误“的值，两个要素都会被误导。这就是为什么关键信号需要冗余传感器或多样性（不同测量原理）来打破共享信息输入的耦合。
3. 环境抗扰性不足（Insufficient Environmental Immunity）：如果两个要素对环境应力（温度、振动、EMI、湿度）的耐受能力相似，环境应力可能同时击穿两者。你的MCU选型表里写着“工作温度-40~125°C“：但如果实际环境温度可能超过125°C，所有芯片都会出问题。EMI是最阴险的环境应力：一个强电磁脉冲可以同时翻转两颗MCU的寄存器，无论它们的架构有多独立。
4. 系统性耦合（Systematic Coupling）：相同的设计错误、相同的开发工具缺陷、相同的生产流程问题。同构冗余：两颗相同型号的MCU运行相同的固件：是系统性耦合的教科书案例。相同的编译器bug会在两套代码中产生相同的错误输出。这就是为什么ISO 26262明确拒绝以同构冗余作为ASIL降级的充分理由。
5. 同类型元件（Identical Type Components）：两个相同型号的电解电容，相同的电解液配方。如果配方有系统性缺陷（比如某批次电解液纯度不足），两个电容会在相近的时间点失效。这既是系统性耦合（同批次缺陷），也是物理耦合（相同的失效机理）。解药是多样性：用不同型号、不同供应商、甚至不同类型的元件（钽电容替代电解电容）。
6. 通信（Communication）：两个要素之间的通信链路本身就是耦合源。SPI、I2C、CAN：任何通信协议都可能出现故障模式（位翻转、帧丢失、超时），而通信故障会同时影响发送方和接收方。这就是为什么安全相关的通信必须使用端到端保护（E2E）：CRC检测数据损坏，序列计数器（SQC）检测帧丢失或重放，超时检测通信中断。E2E保护打破了通信链路的耦合效应。
7. 非预期接口（Unintended Interface）：两个设计上不应该有交互关系的要素之间意外产生的物理交互。PCB走线间的串扰（crosstalk）、芯片内部电源域的噪声耦合、散热器导致的热传导。这些在设计文档中不存在、但在物理世界真实存在的“接口“是最危险的耦合因素。因为它们不会被常规分析发现。
你在白板旁边另开一块区域，用不同颜色的记号笔标注每个耦合因素的DFA评估结果。电源轨：已评估：双路独立DC-DC，加输入过压保护，独立性确认通过。时钟：已评估：两颗MCU各用独立晶振，独立PLL，独立性确认通过。通信（SPI）：已评估：启用E2E Profile 1，CRC+SQC+超时保护。系统性耦合：已评估：MCU异构（Infineon+TI），编译器异构，开发团队独立。共享信息输入：发现问题：两个MCU都通过同一路CAN接收方向盘转角传感器数据。如果传感器输出漂移，两个MCU都会被误导。
你在这个发现旁边画了个红色感叹号。这是DFA的典型产出：发现了一个被FTA遗漏的耦合因素。解决方案：增加第二路转角传感器（不同供应商、不同测量原理：比如霍尔效应+磁阻），让两个MCU各读一路，交叉校验。
DFA与FTA在ASIL分解中的联动
你现在可以把DFA和FTA放在一起看了。你在上一篇中做了ASIL分解：把ASIL D拆成B(D)+B(D)。当时你承诺要“证明充分独立性“：DFA就是兑现这个承诺的工具。FTA则是验证“分解后的架构是否依然满足安全目标“的工具。
流程是这样的：
- FTA建立故障的逻辑模型：从安全目标违反出发，向下推导所有可能的故障路径。这是安全概念的逻辑验证。
- ASIL分解确定了冗余架构：哪些要素独立工作，协同达成安全目标。
- DFA验证冗余是否真独立：逐项检查耦合因素分类，确保没有共因或级联使冗余失效。
- 修正FTA。如果在DFA中发现了耦合，必须在FTA中反映。比如共享电源的耦合因素被DFA识别但无法消除，那必须在FTA中增加一个“共享电源失效“的共同父节点，把所有依赖该电源的要素置于其下。
- 定量FTA评估残存风险：基于修正后的故障树（包含DFA识别的耦合因素），计算PMHF是否满足目标。
这个闭环揭示了安全分析的迭代本质：架构设计→FTA→DFA→发现耦合→修改架构或FTA→重新验证：直到所有假设都被确认、所有残留风险都可接受。
本篇小结
- FTA从安全目标出发，OR门展开单点故障路径，AND门描绘冗余保护的逻辑屏障，最小割集揭示安全目标违反的充要条件
- DFA通过7类耦合因素（共享资源、共享信息输入、环境抗扰性、系统性耦合、同类型元件、通信、非预期接口）逐项排查，揭示“独立“假设的脆弱性
- FTA+DFA构成闭环：FTA建模→ASIL分解→DFA验证→修正FTA→定量评估→迭代收敛
【下集预告】： FTA和DFA帮你理清了所有故障路径和耦合因素，但最致命的故障可能根本就不在你的故障树上——它藏在焊接点里，要跑够15000公里才会显露成间歇性断路。下一节把镜头从设计室拉到产线和公路上：EOL测试为什么要故意注入故障？现场监控的72小时上报链路怎么建？一台车从SOP到报废，安全为什么不是交钥匙工程？