物联网硬件功能安全分析：从电路失效到FMEDA失效率计算实战-开发者社区

简介：面向新能源汽车、物联网及嵌入式领域的硬件工程师，内容系统梳理了ISO26262中危害分析与风险评估（HARA）、故障模式及效应分析（FMEA）、故障树分析（FTA）、故障模式效应及诊断度分析（FMEDA）、软件故障模式及效应分析（SWFMEA）和相关性分析（DFA）等安全分析方法，并结合电路系统、模电单片机等实际场景，说明如何识别危害事件、评定ASIL等级、分析故障原因与效应、量化硬件失效率以及排查共因与级联失效，为硬件功能安全开发与认证提供可直接对照的流程参考。资源共1个doc文档，大小约1.79MB，内容以文字配图表形式展开，涵盖各方法的概念、步骤、典型表格和关键指标（如严重度、发生率、检测度及单点与潜伏故障度量），便于工程师按需查阅。目前已有143人学习下载，适合从事新能源汽车、物联网控制及嵌入式系统开发的硬件人员、功能安全工程师，也适合想系统入门ISO26262安全分析的技术管理者阅读。

1. 功能安全里硬件工程师做安全分析，第一步是承认电路都会失效

一个典型的物联网设备事故复盘往往从软件开始：主控没进中断、通信超时没处理、状态机跑飞。但真正把设备钉在“不能安全停机”十字架上的，常是一个硬件细节——继电器常闭触点拉不回来、驱动 MOS 管直通、ADC 采样电阻漂移导致阈值判断翻转。功能安全语境下的安全分析，就是硬件工程师在原理图阶段就开始回答“电路坏成什么样会出危险”的一套方法。

我习惯把安全分析看成一次系统性的“假设电路失效”工程：先圈出安全相关回路，再用 FMEA/FMEDA 把每个元器件的失效模式、诊断覆盖率、失效率量化出来，最后把结论整理成能过审核的文档。物联网产品绕不开模电采样、单片机最小系统、无线通信链路这三块电路，也恰恰是这三块最容易出现“单点失效直接夺走安全状态”的地方。

2. 先圈安全相关电路：物联网硬件安全分析的边界划法

2.1 从设备功能清单里拆出“安全功能”

做功能安全不回回需要把整个物联网设备做成 SIL 等级设备，绝大多数产品里只有少数功能与安全强相关。比如一个远程抄表设备，计量数据上报不是安全功能；而一个智能燃气紧急切断阀，“断电自动关阀”“通信超时关阀”才是安全功能。

我一般先写一份安全需求表格，逐条列出安全功能、安全状态、危险的失效行为。这张表是后面电路分析的唯一依据。

功能名称	危险失效行为	安全状态	安全完整性等级目标
远程紧急切断	收到指令后阀体未关闭	执行器断电并机械回位	SIL2
本地超温保护	温度越限后加热回路仍在供电	断开加热供电回路	SIL2
通信超时保护	网络中断后维持危险输出	输出安全关断信号	SIL1

注意，安全状态不能只写在软件里。如果断电后执行器因电路保持而不回到安全位置，那“执行器断电”这个安全状态就名存实亡。所以安全分析的第一步，是把这些带“安全状态”的功能，对应到原理图里的具体节点。

2.2 物料清单是安全分析的核心输入，比原理图更先被审查

硬件工程师做电路分析时容易直接盯原理图，但功能安全审核方普遍先看物料清单。原因是物料清单能体现元器件类型、厂家、封装、降额情况，而这些直接决定失效模式和失效率。

我会把物料清单复制到安全分析工作表里，按安全功能逐网络筛选，标记出“与安全回路有关”的位号。物料清单里至少要有这几列：位号、器件名称、规格、工作应力参数、安全相关项标记。有些器件看起来与安全无关，比如模电采样电路里的滤波电容，如果它短路导致 ADC 采样值被拉高，就可能把真实的超温信号掩盖掉。

提示：只分析安全相关物料，不代表其他物料不重要。而是要把有限的精力放在“失效后能产生危险后果”的器件上，控制工作量。

2.3 用故障树反推最小割集，把分析范围收敛到若干网络

圈完安全相关器件后，我不急着逐器件做 FMEA，而是先用故障树确认失效路径。以“阀体未按指令关闭”为例，顶层事件往下拆，会得到类似“控制信号丢失”“执行器驱动失效”“执行器供电异常”“反馈误判为已关闭”这几条分支。

找出最小割集后，电路分析的目标就不再是整板原理图，而是少数几条具体链路：单片机引脚到驱动管栅极的这段网络、驱动管漏极到电磁阀线圈的电源路径、反馈采样电阻到 ADC 输入的通道。这样既避免“为分析而分析”的填表式劳动，也让后面的 FMEDA 计算更聚焦。

故障树可以作为手工表记录，思路是不断追问“这个事件成立需要哪些子事件同时发生”。如果某个最小割集里只有一个事件，那是一个未被诊断的单点失效，在 SIL2 级别的安全分析里通常不可接受。

3. 模电与单片机电路 FMEDA：失效模式、诊断覆盖率、失效率一次算清

3.1 模拟前端电路常见失效模式和安全机制

物联网设备的模电部分集中在电源、采样、驱动三条路径。电源路径常见失效有 LDO 输出漂移、滤波电容短路或开路、电压跌落时复位不稳；采样路径常见失效有分压电阻漂移、运算放大器输出饱和、开关切换引入的毛刺；驱动路径常见失效有 MOS 管直通、继电器触点粘连、续流二极管短路。

对硬件工程师来说，模电失效的判断难点在于“参数漂移”。功能安全分析不能只考虑开路短路这两种极端失效，还要考虑漂移导致阈值失效。比如热敏电阻分压采样，如果上拉电阻阻值漂移超过 ±5%，超温阈值就可能在错误温度触发，甚至失效后完全检测不到超温。

电路环节	典型失效模式	可用的安全机制	对安全分析的作用
电源监测	电压跌落、过压	独立电压监测芯片	提供诊断信号进入安全状态
温度采样	电阻漂移、ADC 偏移	双通道采样交叉比较	降低共因失效影响
驱动输出	输出管直通	串联反馈回路检测	诊断执行器是否真实动作

这些安全机制的共同点是：不能复用发生失效的同一个硬件电路做自身检测。比如拿同一个 ADC 的另一个通道去检测采样电阻漂移，其实是低效的，因为基准源和通道切换逻辑共用后会引入共因失效。

3.2 单片机最小系统在安全分析中的定位

单片机是物联网设备里最复杂的器件，但安全分析不把它当作“可编程万能部件”。我一般把单片机最小系统拆成几个处理对象：CPU 内核与寄存器、Flash 程序存储、RAM 数据存储、时钟与复位、GPIO 与外设。这些部件都有各自的主要失效模式。

这里必须提到 SIL2 场景下 Flash 的诊断机制。因为常见物联网单片机程序放在片内 Flash，Flash 位翻转或读出错误会导致程序跑飞或跳转错误。功能安全里常采用的 Flash 诊断机制包括：运行时对 Flash 做 CRC 校验，在启动阶段和周期运行阶段分别计算关键代码区校验值；假如芯片支持双 Bank 冗余存取，可以对关键函数做双备份；还可以在链接脚本中划分安全相关代码区，只对这部分做高频校验。选择哪种机制，取决于单片机的算力、Flash 访问速度和诊断测试时间。

硬件工程师在这些诊断机制中能决定的参数包括：CRC 校验周期、校验失败后的安全状态入口地址、看门狗溢出时间与时钟独立程度。比如看门狗必须工作在独立时钟源上，否则主时钟停振时看门狗也失去计数能力，单片机系统会一直维持错误输出而不复位。这是嵌入式技术里被反复强调但现场最容易忽略的点。

3.3 用脚本把 FMEDA 算成可复现的工程产物

FMEDA 计算失效率和诊断覆盖率时，用 Excel 也能算，但每次更新时间长且容易改错公式。我更常把它转成一段简洁的 Python 脚本，把每个安全相关器件的行为都放进代码里，计算安全失效分数 SFF 和残余危险失效率 PFH。

# 计算安全相关硬件回路的 SFF 与残余危险失效率 # 失效率单位：FIT，1 FIT = 1e-9 / 小时 # 每条记录字段：器件名称, 总失效率, 危险失效占比, 电路占比, 诊断覆盖率 DC entries = [ ("驱动管栅极电阻", 300, 0.8, 1.0, 0.90), # 开路导致驱动失效 ("驱动管输出级", 500, 0.7, 1.0, 0.99), # 直通是危险失效 ("采样分压电阻", 200, 0.5, 0.8, 0.90), # 漂移掩盖真实信号 ("单片机关断指令路径", 800, 0.6, 1.0, 0.95), # 软件路径算入硬件失效率 ] lambda_total = 0.0 lambda_safe = 0.0 lambda_danger_detected = 0.0 lambda_du = 0.0 # 未被诊断的危险失效 for name, fit, frac_hazard, ratio, dc in entries: lam = fit * 1e-9 * ratio # 该器件对整体失效率的贡献 lam_hazard = lam * frac_hazard # 危险失效部分 lam_safe += lam * (1 - frac_hazard) lambda_danger_detected += lam_hazard * dc lambda_du += lam_hazard * (1 - dc) # 残余危险失效 lambda_total += lam sff = (lambda_safe + lambda_danger_detected) / lambda_total pfh = lambda_du # 每小时平均失效概率，低要求模式常用 print(f"总失效率: {lambda_total:.3g}/h") print(f"安全失效分数 SFF: {sff:.1%}") print(f"残余危险失效率 PFH: {pfh:.3g}/h")

这段代码的核心逻辑是把每个器件的总失效率，按危险失效占比和诊断覆盖率拆成三部分：安全失效、可诊断的危险失效、不可诊断的危险失效。SFF 越高，说明危险失效中能被诊断出来的比例越大；PFH 则是整个安全回路残余的未检出危险失效概率，需要对照标准给定的 SIL 等级目标值去判定是否满足。

实际使用时要特别注意“电路占比”这个参数。它表示该器件在安全功能回路中承担安全相关功能的比例。比如一个电阻同时被普通调试电路和安全采样电路复用，就不能给它 100% 的占比，否则会低估整个回路的失效率。这个数字靠硬件工程师结合原理图和故障树来确定，而不是随便填一个经验值。

4. 物联网通信链路的安全回路：不要把无线信道当成可靠导线

4.1 无线通信安全分析的核心是“通信丢失后能不能进安全状态”

物联网产品里，通信链路通常是安全功能的上游。远程指令通过无线网络下达，本地单片机执行。功能安全分析里，无线链路不是一根直观的信号线，它的失效模式更复杂：数据延迟、数据重复、丢帧、网络切换导致指令丢失、对端设备被重新注册到其他平台等。

我见过很多硬件工程师把通信协议里的 CRC 校验当做安全机制，但功能安全安全分析里要求的不是“错包校验”，而是“未收到合法数据时，控制系统仍能进入安全状态”。因此需要设计一个超时判定机制：在 N 秒内没有收到带正确当前计数器的有效帧，就立即执行安全关断。

为便于计算，把通信链路抽象成“通信完整性检测”模块。它的诊断覆盖率取决于：报文是否带序号或时间戳、校验字段长度、超时窗口设置、错误包计数器溢出后的动作。把这些参数写进硬件安全分析表，比把精力花在信号强度的讨论上有意义得多。

4.2 物联网模组、接口电路和电源域对安全失效率的影响

物联网模组本身的失效率并不完全等同于通信链路失效率。硬件工程师要关注的是模组供电、复位逻辑、电平转换接口这三处与安全回路的交界面。比如 4G/NB-IoT 模组在掉网重搜时会拉大峰值电流，如果其供电路径和单片机安全关断回路共用同一个稳压源，可能造成单片机复位，从而延迟安全指令执行。

射频部分对模拟电路的干扰也要纳入分析。物联网模组发射时的高频能量耦合到 ADC 采样线，可能让采样值出现周期性偏移。对于安全相关采样回路，我一般建议 PCB 布局上把模组天线区域与采样网络拉开物理距离，并在安全分析文档里记录这种布局约束，否则后续硬件改板时很可能被忽略。

通信链路部件	失效模式	与安全回路的关系	建议诊断手段
模组供电	耦合跌落	影响单片机稳定运行	独立电源监控、瞬态跌落复位
电平转换接口	IO 口锁死	阻塞本地安全指令	周期性回读、串行诊断命令
无线通信数据	延迟、丢失	无法触发安全关断	需求时间戳、超时看门狗
天线匹配	反射功率异常	导致通信频繁中断	上报链路状态并进入安全状态

这里要特别提醒：不能把无源物联网设备默认排除在安全分析之外。无源设备靠环境取能，能量波动导致的逻辑复位是常态。如果安全功能需要连续判断多帧数据且不能断电，那无源方案本身可能不能满足 SIL 要求。硬件工程师在选型阶段就应把能量收集稳定性作为一个安全参数来评估。

4.3 硬件工程师要设好诊断测试时间和安全状态确认的参数

安全机制设计出来以后，硬件工程师需要确定三个参数：诊断测试时间、安全容错时间、安全状态确认时间。诊断测试时间指从故障发生到诊断功能把它识别出来的最大时间；安全容错时间指从故障发生到危险事件产生前最晚的动作时间；安全状态确认时间指进入安全状态并完成回读验证所需的时间。

这三个参数不是硬件单独定的，必须结合受控设备的物理特性。比如一台电机驱动设备，从软件发出关断指令到电机完全停止可能需要近百毫秒，安全状态确认时间就不能只看继电器动作时间，要把这个动态过程算进去。把参数列成下表，便于在安全分析评审时直接对照。

参数	含义	影响因素
诊断测试时间	周期性检测潜在失效的时间间隔	传感器响应、通信周期
安全容错时间	从故障发生到危险后果的时间	设备惯性、执行器动作速度
安全状态确认时间	确认安全状态实际到达的时间	检测回路、反馈传感器延迟

这些参数直接决定看门狗溢出时间、CRC 校验周期、通信超时窗口如何设置。单片机处理能力越强，诊断测试时间可以压得越短，但代价是软件复杂度上升。硬件工程师的任务是找到能通过失效率计算的平衡点，而不是把每个周期都设成最小值。