1. 课程导入

在汽车电子、工业控制、医疗设备等安全相关领域,功能安全(Functional Safety)的核心目标是:当系统发生随机硬件失效或系统性失效时,系统能够进入安全状态,避免对人员、环境或设备造成不可接受的风险。ISO 26262、IEC 61508 等标准用 ASIL 或 SIL 等级来量化这种风险控制能力,而诊断覆盖率(Diagnostic Coverage,DC)正是连接"失效机理"与"安全目标"的关键桥梁。

很多工程师第一次接触 DC 时会误以为它只是一个"打分的百分比",实际上 DC 描述的是:在某个硬件失效模式下,诊断机制能够检测并响应该失效的概率。它直接参与硬件架构度量(Hardware Architectural Metrics)中的单点故障度量(SPFM)和潜伏故障度量(LFM)计算,进而决定一个安全目标能否被满足。换句话说,DC 不是可选的加分项,而是功能安全论证链条中不可缺失的一环。

核心关系:安全目标 → 安全机制 → 诊断覆盖率 → SPFM/LFM → ASIL 达成。DC 是安全机制有效性的量化表达,也是硬件随机失效可控性的直接证据。

1.1 为什么诊断覆盖率决定功能安全的成败

功能安全要求系统在发生故障时仍能维持安全状态,而"能否及时发现故障"取决于诊断机制。若一个 MCU 的时钟监控、看门狗、锁步核、ECC、CRC 等安全机制覆盖不足,即使架构设计再合理,随机硬件失效仍可能潜伏并最终导致危险事件。DC 正是把这些安全机制的检测能力转化为可计算、可审计、可验证的数值。

从工程角度看,DC 影响三个层面:

  • 安全论证层面:DC 是 FMEDA(失效模式、影响及诊断分析)的输出,直接决定 SPFM 与 LFM 是否达标。
  • 架构设计层面:DC 目标倒推安全机制选型,例如是否需要锁步核、是否需要双通道比较、是否需要端到端保护。
  • 验证确认层面:DC 声称值必须通过故障注入、诊断测试或分析证据来支撑,否则只是纸面数字。

1.2 整体知识框架

本课程围绕"从标准要求到工程落地"的主线展开,整体知识框架可分为五个层次:标准与概念层、失效与诊断建模层、DC 计算与 FMEDA 层、安全机制实现层、验证与复盘层。下图展示了这五个层次之间的数据流与依赖关系,帮助你在后续章节中建立全局视角。

功能安全诊断覆盖率知识框架 ① 标准与概念层 ISO 26262 / IEC 61508 · ASIL/SIL · 安全目标 · 安全状态 · 随机硬件失效 ② 失效与诊断建模层 失效模式 · 失效率 λ · 危险失效 · 安全机制 · 诊断覆盖因子 ③ DC 计算与 FMEDA 层 FMEDA 表格 · DC 赋值 · SPFM · LFM · 残余失效率 · 硬件架构度量 ④ 安全机制实现层 锁步核 · ECC · CRC · 看门狗 · 时钟监控 · 电压监控 · 端到端保护 ⑤ 验证与复盘层 故障注入 · 诊断测试 · 证据链 · 审计 · 偏差复盘 · 持续改进 验证反馈驱动设计迭代

1.3 方法流程:从安全目标到 DC 落地

工程实践中,DC 的落地通常遵循以下流程。该流程不是一次性动作,而是与硬件设计、软件诊断、测试验证并行迭代的过程。

  1. 确定安全目标与 ASIL 等级:由危害分析与风险评估(HARA)输出,明确每个安全目标的 ASIL。
  2. 分解安全需求到硬件元素:识别与安全目标相关的硬件部件及其失效模式。
  3. 建立 FMEDA 表格:列出每个失效模式的失效率、失效分布、是否危险、是否可诊断。
  4. 为每个失效模式分配 DC 值:依据安全机制的实际检测能力,给出诊断覆盖因子。
  5. 计算 SPFM 与 LFM:判断是否满足目标 ASIL 的架构度量要求。
  6. 迭代优化:若未达标,增加或增强安全机制,重新计算 DC。
  7. 验证与证据固化:通过故障注入、诊断测试或分析报告支撑 DC 声称值。

下面是一个简化的 FMEDA 片段示例,展示 DC 如何参与计算:

失效模式            λ( FIT )   危险?   DC      残余危险失效率
SRAM 位翻转          50        是     0.90    5.0
时钟漂移             20        是     0.99    0.2
CPU 寄存器卡滞       30        是     0.60    12.0
电源电压异常         15        是     0.95    0.75

可以看到,DC 越高,残余危险失效率越低。若某失效模式 DC 偏低,就需要通过增加诊断机制或改进架构来提升。

1.4 案例场景:DC 不足导致的架构返工

某域控制器项目在概念阶段声称满足 ASIL D,但在 FMEDA 评审时发现:CPU 内核的寄存器卡滞失效模式仅依赖软件周期性自检,DC 仅约 60%,导致 SPFM 无法达到 ASIL D 要求的 99%。项目被迫在硬件后期增加锁步核与硬件比较逻辑,将 DC 提升至 99% 以上,但代价是芯片面积增加、功耗上升、项目延期数月。

常见误区:把 DC 当作"设计完成后再填的数字"。实际上 DC 必须在架构设计早期就参与权衡,否则后期返工成本极高。另一个误区是只关注高失效率项,忽略低失效率但 DC 极低的失效模式,后者同样可能拖垮整体 SPFM。

1.5 工程价值与学习目标

掌握诊断覆盖率工程方法,能够帮助团队在以下方面获得实际收益:

维度 没有 DC 工程能力 具备 DC 工程能力
安全论证 无法量化证明安全目标达成 用 FMEDA 与 DC 形成完整证据链
架构设计 安全机制选型凭经验 按 DC 目标倒推机制配置
成本控制 后期返工、过度设计 早期权衡,避免浪费
验证效率 测试无重点、覆盖不清 针对低 DC 项重点注入验证
审核通过率 评审反复、难以闭环 数据完整、可审计、可追溯

本课程的学习目标如下:

  • 理解功能安全标准中 DC 的定义、作用与计算逻辑。
  • 掌握 FMEDA 的建立方法与 DC 赋值准则。
  • 能够根据 ASIL 目标反推安全机制与 DC 要求。
  • 掌握 SPFM、LFM 的计算与达标判断方法。
  • 能够设计故障注入与诊断测试来验证 DC 声称值。
  • 具备复盘 DC 偏差、持续改进安全架构的能力。
学习建议:每学完一章,尝试用本章方法对自己熟悉的 ECU 或芯片做一次简化 FMEDA,哪怕只覆盖 5 个失效模式,也能快速建立 DC 的工程直觉。

功能安全不是纸面合规,而是用可量化、可验证的工程手段控制风险。诊断覆盖率正是这套手段中最具操作性的抓手。接下来的章节将逐步展开从标准要求到 FMEDA 实操、从安全机制到验证证据的完整路径。