从电路原理图到ASIL C：硬件功能安全定量分析实战指南

1. 项目概述：从一张原理图到功能安全量化评估

上周和一位做功能安全的朋友聊起硬件设计中的安全分析，他提到很多工程师一看到ISO 26262标准里那些复杂的公式和表格就头疼，总觉得这是系统工程师或安全经理的活儿，离具体的电路设计很远。其实不然，标准里给出的示例恰恰是为了把抽象的要求，落到一个个具体的电阻、电容和晶体管上。正好，最近有位同行周岩将ISO 26262-5中的一个经典硬件电路定量分析示例做了汉化和梳理，我觉得这个例子特别有代表性。它就像一份“解剖报告”，用一张相对简单的车速监控电路原理图，清晰地展示了如何一步步计算出整个系统的失效率，并最终判断其是否满足ASIL C等级的要求。

这个例子的核心价值在于，它提供了一个可复现的“计算模板”。无论你是负责电路设计的硬件工程师，还是进行安全分析的软件或系统工程师，都能通过这个模板理解：功能安全不是空中楼阁，而是由每一个元器件的失效率、每一个安全机制的诊断覆盖率，像搭积木一样构建起来的。它解决了从“定性要求”（比如“系统必须可靠”）到“定量证明”（比如“系统每小时失效概率低于10^-7”）的关键跨越。如果你正在接触汽车电子、工业控制或其他高可靠性领域的设计，并且对如何将功能安全标准落地到实际电路感到困惑，那么跟着这个例子走一遍，你会获得一个非常扎实的起点。

2. 核心思路拆解：定量安全分析的“三步法”

在深入计算细节之前，我们得先搞清楚做这件事的整体逻辑。ISO 26262对硬件的定量分析，核心目标是评估随机硬件失效对安全目标造成的风险是否足够低。整个分析过程可以提炼为一个清晰的“三步法”：定义安全场景、识别失效模式、量化计算与评估。这个例子完美地演绎了这个流程。

2.1 第一步：定义安全目标与安全机制

一切分析始于安全目标（Safety Goal）。在这个例子里，安全目标SG2非常明确：当车速超过100 km/h时，必须确保一个名为I61的阀门处于开路（即断开）状态。这个目标被定义为ASIL C等级，这意味着它对安全性的要求很高，相应的硬件架构度量指标也必须更严格。为什么是开路？因为在这个假设的安全场景下，阀门闭合可能意味着危险，比如导致不必要的制动或动力中断，因此在高速时需要强制断开。

有了目标，就要设计防御措施，也就是安全机制（Safety Mechanism）。例子中提到了三个：

• SM2（冗余信号采集）：使用两个车速传感器I1和I2。这解决了信号源本身的单点故障问题。如果一个传感器坏了，另一个还能提供数据。
• SM3（输出监控）：MCU通过ADC2通道持续监测控制阀门I61的晶体管T61的输出端电压。这确保了MCU发出的“开路”指令是否被正确执行。如果T61失效短路，ADC2就能检测到异常电压。
• SM4（控制器健康监测）：MCU内部自检加外部看门狗。这是为了防止MCU本身“跑飞”或死机，导致整个控制逻辑失效。

这些安全机制不是随意添加的，每一个都是为了覆盖特定的失效模式。例如，SM2覆盖传感器失效，SM3覆盖功率开关失效，SM4覆盖控制器失效。在设计电路时，我们就应该带着这样的思维：这个元件可能怎么坏？坏了之后用什么机制来发现并处理？

2.2 第二步：失效分类与FMEA/FTA思维

硬件失效在分析时被分为两大类：单点故障和残余故障、潜在多点故障。这是理解整个计算框架的关键。

• 单点故障：指任何一个硬件元件的随机失效，如果直接导致安全目标违背，并且没有安全机制能检测到它，那就是“单点故障”。如果有安全机制能检测到，那么这部分被覆盖的失效，其风险就被降低了；没被覆盖的部分，则称为“残余故障”。计算时，我们需要找出每一个元件，每一种失效模式，在没有其他元件同时失效的假设下，其残余风险是多少。
• 潜在多点故障：指两个或多个独立元件的失效组合在一起，才会导致安全目标违背，并且这些失效中至少有一个是潜伏的（即没有被安全机制检测到或告知驾驶员）。这通常需要更复杂的共因失效分析（比如Beta因子模型），但这个例子做了简化，假设在双重故障组合下，安全机制（SM2）和报警灯（L1）能提供100%的覆盖率。

这里就隐含了FMEA（失效模式与影响分析）的思维。我们需要对原理图中的每一个元件（电阻、MCU、晶体管等）进行梳理：它有哪些失效模式（开路、短路、参数漂移）？每种模式发生的概率（失效率）占比是多少？这就是后续计算的基础数据。

2.3 第三步：量化计算与指标评估

这是最“数学”的一步，但有了Excel工具和清晰的流程，它就变成了体力活。核心是使用元器件的“失效率”（单位通常是FIT，1 FIT = 10^-9/小时）和“诊断覆盖率”这两个关键参数。

• 失效率：通常来自行业标准手册，如SN 29500、IEC 62380，或元器件供应商提供的可靠性数据。它表示元器件在单位时间内发生失效的概率。
• 诊断覆盖率：指安全机制能够检测出该失效模式的比例。比如，一个电阻开路失效，可能被后续的电压检测电路发现，如果这个电路能发现90%的这种开路情况，那么诊断覆盖率就是90%。ISO 26262-5的附录中提供了一些典型安全机制的诊断覆盖率推荐值。

计算过程就是“分解-计算-汇总”：

1. 分解：将每个元件的总失效率，按失效模式比例拆分（例如，电阻R11：总失效率2 FIT，其中开路占90%即1.8 FIT，短路占10%即0.2 FIT）。
2. 计算：针对每种失效模式，评估其是否被安全机制覆盖。计算“残余失效率” = 该模式失效率 × (1 - 诊断覆盖率)。
3. 汇总：将所有单点/残余故障的失效率相加，得到总的“单点故障度量”值；将所有潜在多点故障的失效率相加，得到“潜在故障度量”值。
4. 评估：将计算出的值与标准要求（ASIL C要求单点故障度量≥97%，潜在故障度量≥80%）进行对比，判断是否达标。

注意：很多工程师容易混淆“失效率”和“失效概率”。我们这里计算的是失效率的累加，其量纲仍然是FIT（每小时）。在最终评估时，这个累加值本身并不是概率，而是用来计算“单点故障度量”（SPFM）和“潜在故障度量”（LFM）的中间变量。SPFM和LFM才是百分比形式的指标。

3. 电路原理与安全机制深度解析

现在，让我们回到那张原理图本身，看看每一个部分是如何为实现安全目标而工作的。理解电路功能是进行准确失效分析的前提。

3.1 车速信号采集链（I1, I2 -> MCU）

电路通过两个独立的车速传感器I1和I2采集信号。这本身就是安全机制SM2（冗余设计）的体现。在硬件连接上，传感器信号可能经过调理电路（如滤波、放大）后，送入MCU的两个独立ADC通道或数字输入口。

• 设计考量：为什么用两个传感器？不仅仅是为了冗余。在汽车行业，这常用于实现“合理性检查”。例如，两个信号在正常情况下应该高度一致，如果差值超过某个阈值，MCU就可以判断至少有一个传感器故障。这就是在SM2基础上实现的软件安全机制。
• 失效影响分析：如果只有一个传感器（比如I1）的输入回路上的一个电阻R11发生开路，会导致该路信号丢失或异常。但由于有I2这条冗余路径，MCU仍然能获得车速信息。然而，这里的关键是，MCU的软件逻辑必须能够处理这种“单路信号失效”的情况，并可能触发降级模式或报警。在定量分析中，SM2对这类开路失效的诊断覆盖率（例子中给出99%）就体现了这种检测能力。

3.2 阀门驱动与监控回路（MCU -> T61 -> I61 -> ADC2）

这是执行安全动作的关键路径。MCU根据车速逻辑判断，控制一个晶体管T61（可能是MOSFET或BJT）来驱动阀门I61（可能是一个电磁阀）。ASIL C的安全目标要求这条路径高度可靠。

• T61的作用与失效模式：T61作为功率开关，其失效模式主要是两种：开路（无法导通）和短路（无法关断）。对于安全目标“高速时I61开路”而言：
  • T61开路失效：这反而是“安全”的！因为T61无法导通，I61自然就没有电流，处于开路状态。这种失效不会违背安全目标，在安全分析中通常被归类为“安全失效”。
  • T61短路失效：这是危险的！如果T61短路，无论MCU输出什么信号，电流都可能持续流过I61，导致其无法在高速时开路，直接违背安全目标。因此，针对T61的短路失效，必须要有强大的安全机制来应对。
• ADC2监控（SM3）的价值：ADC2持续监测T61输出端（可能是I61的线圈一端）的电压。当MCU命令T61关断（输出低电平）时，如果ADC2检测到该点电压仍为高（或存在电压），则很可能意味着T61发生了短路失效，或者与电源发生了意外的短路。此时，MCU可以立即采取更高层级的应对措施，例如点亮报警灯L1（SM4的一部分），并可能通过其他冗余路径或备份系统来尝试强制断开I61（如果设计中有的话）。ADC2对这个监控点的诊断覆盖率，直接决定了有多少比例的T61短路失效能被及时发现和处理。

3.3 控制器健康守护（SM4：自检与看门狗）

MCU是整个系统的大脑，它的失效是系统性的。SM4是一个组合机制：

• 内部自检：包括上电自检、周期性的RAM/ROM校验、CPU内核测试（如逻辑BIST）、外设功能检查等。这些自检能发现MCU内部的部分随机硬件故障。
• 外部看门狗：这是一个独立的硬件电路（可能是一颗专用的看门狗芯片，或另一个简单MCU）。主MCU需要定期向其“喂狗”。如果主MCU程序跑飞或死循环导致无法按时喂狗，看门狗电路将产生复位信号，强制重启MCU。这能有效从某些软件故障或CPU锁死状态中恢复。

实操心得：在设计看门狗电路时，一个常见的“坑”是看门狗芯片本身的失效。如果看门狗失效且无法被检测，它就变成了一个“单点故障点”。因此，高级的设计有时会采用“窗口看门狗”或“双向看门狗”机制，甚至用两颗MCU互相监控，以覆盖看门狗本身的失效。在定量分析中，看门狗芯片的失效率也需要被计入，并评估其诊断覆盖率（可能通过主MCU周期性读取看门狗状态寄存器来实现）。

4. 定量计算过程逐步拆解

理解了原理和安全机制，我们就可以打开那个“神秘的”Excel表格，看看每一行数字到底是怎么来的。我们以文档中提到的电阻R11为例，进行超详细的拆解。

4.1 基础数据准备：失效率与失效模式分布

首先，我们需要每个元器件的基础可靠性数据。这些数据通常来源于：

1. 行业通用标准：如西门子SN 29500、法国UTE C 80-811。
2. 元器件供应商提供的可靠性报告。
3. 经验数据库或公司内部的历史数据。

对于电阻R11，我们假设从数据库中查到其基础失效率λ_R11 = 2 FIT。注意，这个失效率通常是在额定应力（如温度、电压、功率）下的值。如果实际工作应力更高，可能需要用应力模型（如Arrhenius模型）进行修正，这里例子做了简化。

接着，我们需要知道这个电阻各种失效模式的比例。对于无源器件如电阻，主要失效模式就是“开路”和“短路”（或参数漂移超出范围，常归为“短路”类）。例子中给出：开路占90%，短路占10%。这个比例数据也来自历史统计或标准。

于是，我们得到：

• R11开路失效率 λ_open = 2 FIT × 90% =1.8 FIT
• R11短路失效率 λ_short = 2 FIT × 10% =0.2 FIT

4.2 单点故障残余失效率计算

现在分析，如果只有R11自己坏了，会发生什么，以及安全机制能多大程度应对。

• 场景A：R11发生开路失效（1.8 FIT）

  • 影响：导致车速传感器I1的信号无法正确送入MCU，该路信号失效。
  • 安全机制：SM2（冗余设计，有I2信号）。MCU通过比较两路信号或检测信号丢失，可以诊断出此故障。
  • 诊断覆盖率：例子中给出DC(SM2) = 99%。这意味着99%的此类开路故障能被SM2检测到。
  • 残余风险：那剩下的1%检测不出来的情况，就是残余风险。其失效率为：λ_open_residual = 1.8 FIT × (1 - 99%) = 1.8 FIT × 1% =0.018 FIT。这个0.018 FIT就是R11开路失效对“单点故障度量”的贡献值。

• 场景B：R11发生短路失效（0.2 FIT）

  • 影响：可能导致I1信号异常（如被拉高或拉低），产生错误的车速值。
  • 安全机制：同样依靠SM2。两路信号不一致，MCU可判断有故障。
  • 诊断覆盖率：同样假设为99%。
  • 残余风险：λ_short_residual = 0.2 FIT × (1 - 99%) = 0.2 FIT × 1% =0.002 FIT。

所以，对于电阻R11，在单点故障分析中，其总的残余失效率贡献就是 0.018 FIT + 0.002 FIT =0.020 FIT。

4.3 潜在多点故障失效率计算

潜在多点故障分析更复杂，它考虑的是两个或以上独立失效同时发生，且其中一个未被检测到的情况。例子中对R11的分析做了简化处理。

它分析的组合是：“R11开路” 且 “其他某个元件也发生特定失效”。在这种情况下，系统可能面临更复杂的故障组合。例子假设，当这种双重故障发生时，系统除了SM2，还可以通过报警灯L1警示驾驶员（这是一种“故障缓解”或“降级”机制），综合诊断覆盖率达到了100%。

因此，计算结果是：λ_open_multi = 1.8 FIT × (1 - 100%) =0 FIT。同理，短路模式也是0 FIT。

重要提示：这种将双重故障覆盖率设为100%的做法在实际项目中需要谨慎论证。通常，潜在多点故障的分析需要借助故障树分析（FTA）来识别哪些失效组合是危险的，并评估其共因失效（CCF）的可能性。ISO 26262推荐使用β因子模型来量化CCF。例子中的简化是为了突出核心计算流程。

4.4 全局汇总与指标计算

对原理图中的每一个元器件（R11, R12, C1, MCU, T61, L1, 看门狗芯片等），都重复上述4.1~4.3步骤。我们需要为每个元件准备：

1. 总失效率 (λ)
2. 失效模式分布（开路%，短路%，其他%...）
3. 针对每种失效模式，哪些安全机制有效（SM2, SM3, SM4...）
4. 这些安全机制对该失效模式的诊断覆盖率（DC）。

在Excel中建立如下表格进行计算汇总：

最后，计算两个核心硬件架构度量指标：

1. 单点故障度量（SPFM）:SPFM = 1 - (∑λ_residual / ∑λ_total)它反映了安全机制对单点故障的覆盖能力。ASIL C要求SPFM ≥ 97%。

2. 潜在故障度量（LFM）:LFM = 1 - (∑λ_multi / ∑λ_total)它反映了安全机制对潜在多点故障的覆盖能力。ASIL C要求LFM ≥ 80%。

例子中给出的结果表，就是完成了所有行列计算后，得到的∑λ_residual和∑λ_multi，并代入公式计算出了SPFM和LFM，最后与标准要求对比，得出结论。

5. 实操要点与常见问题排查

将理论计算落地到实际项目，会遇到很多表格和标准里没写的细节问题。这里分享一些关键的实操要点和避坑指南。

5.1 数据来源与处理：失效率不是猜的

• 痛点：最大的挑战往往是获取可靠的失效率数据。特别是新型号芯片、复杂可编程器件（如FPGA、SoC），供应商可能不提供或数据不完整。
• 解决方案：
  1. 优先采用行业标准：对于电阻、电容、电感、二极管、晶体管等通用元件，SN 29500或IEC 62380是公认的权威来源。这些标准考虑了温度、电压、电流应力等因素，给出了计算模型。
  2. 善用供应商数据：向元器件供应商索要可靠性报告，特别是AEC-Q100（车规芯片）认证的器件，通常会有FIT数据。注意确认其置信水平（如60%置信度）和测试条件。
  3. 分解法处理复杂器件：对于MCU、复杂ASIC，可以将其分解为“内核逻辑”、“存储器”、“I/O单元”、“时钟模块”等子块，分别查找或估算失效率，再相加。一些EDA工具（如Reliability软件）内置了这样的模型库。
  4. 建立内部数据库：对于常用器件，将确认过的失效率数据整理成内部数据库，可以极大提升后续项目的分析效率。

5.2 诊断覆盖率的确定：最需要工程判断的地方

诊断覆盖率（DC）的取值直接影响结果，但它往往不是精确数字，而是基于设计分析和测试验证的工程判断。

• 参考标准附录：ISO 26262-5的附录D提供了各种典型安全机制的推荐诊断覆盖率范围。例如，“双通道比较（带周期性测试）”的DC可能高达99%，而简单的“信息冗余（如奇偶校验）”可能只有60-90%。这是最重要的参考依据。
• 基于设计分析：你需要论证你的安全机制为什么能达到某个覆盖率。例如，ADC2监控T61输出电压：监控电路本身的故障率是多少？ADC的采样精度和频率是否足以捕捉到异常？软件诊断算法的检测阈值和响应时间是否合理？这些分析构成了DC取值的支撑。
• 测试与验证：通过故障注入测试，在实际硬件中模拟元器件失效（如通过飞线将T61的D-S短路），观察安全机制是否能100%地检测并响应。测试结果可以用于修正或确认之前分析的DC值。

5.3 工具使用与流程管理

手动用Excel计算对于小型电路可行，但对于包含上百个元件的复杂ECU，极易出错且难以维护。

• 推荐使用专业工具：市面上有专门的功能安全分析工具（如Medini analyze, Ansys medini analyze等）。它们可以与电路设计（如Cadence）或系统设计（如SysML）工具联动，自动导入元器件清单和失效模式库，并引导你完成FMEA、FTA和定量分析，自动生成报告。这不仅能提高准确性，还能保证分析过程的可追溯性——这是功能安全审核的重点。
• 流程融入设计周期：硬件定量分析不应是设计完成后的“补作业”，而应融入设计迭代中。在架构设计阶段就进行初步分析，可以指导安全机制的分配；在详细设计阶段更新分析，可以验证设计是否达标；在测试验证阶段，用测试结果反哺修正分析模型。

5.4 典型问题排查清单

在实际操作中，经常遇到计算结果不达标的情况。以下是一个排查思路：

5.5 报告与证据链

功能安全评估最终需要向客户或认证机构提供证据。你的定量分析报告不应只是一堆数字和表格，而应是一个完整的证据链，包括：

1. 分析范围定义：明确分析的是哪个硬件部件，对应哪个安全目标。
2. 使用的标准与数据来源：列明失效率数据出自SN 29500第X版、供应商Y的可靠性报告等。
3. 假设与前提：清晰记录所有工程假设，如环境温度、电压应力、诊断覆盖率的论证依据。
4. 详细计算过程：提供可追溯的Excel表格或工具生成的报告，展示从原始数据到最终结果的每一步。
5. 结论与改进措施：明确给出SPFM/LFM是否达标的结论。如果未达标，应列出已采取或计划采取的改进措施（如设计变更、增加测试等）。

这个过程虽然繁琐，但它是将“我们认为它安全”转变为“我们证明它安全”的关键一步。当你亲手完成一次从原理图到量化指标的全过程分析后，你对功能安全的理解，就不再停留在纸面标准，而是深入到了每一个电阻和晶体管的选择与布局之中。