DFA七因子分析法：硬件冗余架构中的相关失效识别与防范

本文整理自SASETECH社区《DFA分析技术分享》直播，主讲人是威睿电动的BMS功能安全&信息安全负责人蒋凌燕老师——具有丰富的汽车动力域以及多个量产项目落地开发经验。曾参与BMS功能安全国标编写，帮助公司取得ASIL C的产品认证证书。
 

本文涵盖硬件安全需求拆解、DFA七因子分析法、矩阵筛选步骤，以及实战案例，文末精选问答也值得细读哦！
 

在功能安全开发中，冗余设计是提升硬件安全等级的常用手段。但认证机构最常质疑的问题之一就是你的冗余，真的独立吗？ISO 26262第一章节中定义的分析方法——DFA，正是用来回答这个问题的。

 

一、硬件安全需求从哪来

硬件安全需求在标准里分了七大类：

安全机制需求的细化

故障容忍度的细化

电气保护要求

供应失效的要求

非功能性要求

随机硬件失效度量指标

生产制造相关要求

每条安全需求应包含：电气特性（采集范围、精度）、时间属性、ASIL等级分解、上游追溯性，以及验证准则和验证手段。

架构设计必须同时包含安全功能和非安全功能。

很多公司只把安全功能设计进去，非安全功能全部舍掉——实际上，非安全功能同样可能影响安全功能，割裂分析会漏掉一半的耦合路径。

二、冗余设计是否真的保险

看一个常见误区：

两个模块A和B做了冗余设计，表面上看任一个失效了另一个还在工作。但若A和B共用同一个电源C——电源一旦失效，两者同时失效，冗余设计失效。DFA要回答的核心问题：冗余设计是否真的独立？

相关失效分两类：

级联失效（CascadingFailure）：A故障直接引起B故障，如A感冒传给了B，B也无法工作。

共因失效（CommonCauseFailure）：A和B因外部共同因素同时失效，如高温天气导致A和B同时中暑——高温就是那个共同原因。

 

三、DFA在开发流程中的位置

DFA嵌入在系统开发的迭代循环里。系统阶段做FMEA时会同步做DFA，基于现有架构梳理模块间的级联和共因关系；分析出结果后，识别需要增加的安全机制，反馈到系统/硬件需求；需求更新后架构随之调整，再进入新一轮分析。

FTA的底事件应作为DFA的输入。FTA可以识别安全机制与预期功能共同引起的安全目标违背，但还需要DFA分析安全机制与预期功能耦合的原因和解决方法，这也是为什么FTA的输出能做为DFA输入的原因。

四、三类必须做DFA的情况

第一种：级联传递（低ASIL等级→高ASIL等级）

信号从低ASIL等级模块传递到高等级模块时，该信号实际上达不到高等级的安全要求，必须做级联分析。还有一种隐蔽情况：A和B没有直接传递关系，但A通过C间接影响了B——A失效拉低了信号，导致C也无法把信号传给B，这种间接影响同样需要分析。

第二种：ASIL等级分解中的共因

ASIL分解有两个前提：冗余且独立。做了分解但存在共用资源（如共用电源），独立性就不成立，分解失效。所以做分解时，必须先检查分解对象之间是否存在共用资源。

第三种：安全机制自身的有效性

安全机制是否会在某情况下本身也失效？A模块（安全机制）监控B模块（预期功能），但共用同一个电源C——电源欠压时，B已不在正常态，A的监控功能也已丢失，安全机制在边界条件下失效。

五、七因子分析法

筛选出需要分析的顶事件后，按七类DFI因子逐一分析每个顶事件是否存在耦合失效。将功能按矩阵排列（纵轴横轴均为功能清单），两两排查：

①公用资源：两个模块共用同一电源/内核/通讯线——共用资源一旦失效，两个模块同时受影响。

②相同类型组件：两个模块选用了完全相同的器件（同一厂家、同一型号），设计原理、生产工艺、检测方法一致，一损俱损。

③通讯接口：CAN/LIN/SPI等通讯链路本身出问题，会同时影响依赖这条链路的多个模块。

④共享信息输入：A同时向B和C传递信号（如模拟量数据），B和C都对A产生依赖，一旦A失效，B和C的数据同时出错。

⑤环境因素：EMC干扰可能同时作用于物理上靠近的多个模块，是容易被忽略的共因来源。

⑥非接口耦合：架构中看不出明显接口，但两模块通过隐形功能耦合。最典型的例子是共享内存——一个模块内存泄漏，另一个模块就无法使用。这个失效路径在架构图上完全看不出来，必须把MCU内部模块梳理出来才能识别。

⑦系统性耦合：开发工具缺陷（如原理图→PCB导出网络表时丢失连接）、流程文档错误、人员经验等人因因素。

六、完整分析步骤

Step1—梳理功能清单：ID、名称、ASIL等级、功能描述

Step2—功能清单按矩阵排列，两两分析，筛选需要分析的顶事件

Step3—按七类DFI因子逐一分析每个顶事件，识别失效模式和影响

Step4—基于分析结果导出安全机制

Step5—将安全机制反补到架构，更新需求，迭代优化

实战案例：某架构中两个模拟量输入做了冗余设计，满足冗余前提，但进一步分析发现两者共用同一电源——电源一旦失效，两个通道同时失效，共因成立，分解无效。

另一个典型案例：MCU内部A和B模块都调用了同一功能处理单元，架构图上无直接连线，但实际存在隐性耦合，是典型的非接口耦合，漏识别率极高。

安全机制≠措施：安全机制是可以通过硬件/软件实现的具体要求（如PMIC监控输出电压，过压/欠压时断开输出进入安全状态）；措施还包含流程性要求（开发工具满足ISO26262、EMC设计规范、DVPV验证等），不属于机制。

 

七、精选问答

1. DFA和FTA是什么关系？

答：FTA与DFA互补。FTA主要识别共同事件引起的安全目标违背，DFA在此基础上分析级联，以及安全机制与预期功能之间的耦合失效。FTA底事件应作为DFA输入，两者结果合并才是完整的系统安全分析。。

 

2. 架构图细化程度怎么把握？

答：不建议将单一器件（如电阻、电容）在架构图中逐一体现，会干扰分析；建议将滤波、EMC等整合为功能框处理，分析注意力留给模块间的耦合关系。

 

3. 复杂系统怎么做DFA？

答：分层分析。把子系统当作一个模块纳入上级系统，每层做两两筛选，层内再做细节分析。100个模块平铺分析工作量是1万项，分层后大幅降低。

 

DFA不是可选的附加项，而是验证冗余设计是否真正有效的必要手段。在实际项目中，很多看似满足要求的架构问题，都是通过DFA分析才被发现——尤其是共用资源、非接口耦合这类隐蔽风险，靠人工审查很难识别。

建议在系统架构基本稳定后，尽早开展DFA分析，而不是等到硬件详细设计甚至认证阶段才补做，那时候返工成本会非常高。

 

审核编辑 黄宇