3. 故障注入方法论与标准

在 Bosch ADAS 项目中,故障注入不是“随便往 CAN 总线上发几帧错误报文”的调试手段,而是一套有标准依据、有分类方法、有推导链条的工程活动。它的核心目标有两个:一是验证安全机制在故障发生时是否按设计生效,二是暴露那些在正常测试中永远无法触发的失效路径。要理解这套方法论,必须先把两个标准的分工讲清楚。

ISO 26262 与 ISO 21448:两类不同的“不安全”

ISO 26262 关注的是 E/E 系统本身的功能安全(Functional Safety),即由随机硬件失效或系统性失效导致的危害。它要求对每个安全目标做 ASIL 定级,并通过安全机制(如看门狗、双核锁步、CRC 校验、冗余传感器)把风险降到可接受水平。故障注入在 26262 语境下,主要验证的是这些安全机制的诊断覆盖率(DC)和故障响应时间是否达标。

ISO 21448 关注的是预期功能安全(SOTIF),即系统本身没有故障、所有部件都正常工作,但由于感知能力局限、算法边界或场景理解不足,仍然可能产生危害。典型例子是摄像头把白色货车车厢误判为天空,或毫米波雷达把井盖回波当成静止车辆。SOTIF 的故障注入更偏向“性能局限注入”和“场景扰动注入”,而不是硬件失效注入。

两者在注入用例设计上的差异可以概括为:26262 注入的是“部件坏了会怎样”,21448 注入的是“部件没坏但看不准会怎样”。一个完整的 ADAS 安全验证计划,必须同时覆盖这两条线。

故障注入的分类维度

工程上常用的分类方式有四种,它们决定了注入工具的选择和用例的粒度:

  • 按注入对象:硬件层(传感器供电拉偏、CAN 收发器短路)、信号层(雷达目标距离跳变、摄像头曝光异常)、软件层(函数返回值篡改、任务超时)、数据层(感知输出框丢失、跟踪 ID 跳变)。
  • 按注入时机:静态注入(上电前设置故障)、动态注入(运行中触发)、边界注入(在功能切换瞬间触发)。
  • 按故障持续时间:瞬态(单帧或毫秒级)、间歇(周期性出现)、永久(持续到复位)。
  • 按可控性:完全可控(如通过调试接口改写变量)、半可控(如通过环境模拟器影响传感器)、不可控(只能观测,如真实道路上的逆光)。

在 Bosch 的工程实践中,最常用的是“信号层 + 动态 + 瞬态”组合,因为它最接近真实故障的传播路径,又能在台架上稳定复现。

FMEA 与 FTA:从失效模式到注入用例

故障注入用例不能拍脑袋写,必须从 FMEA(失效模式与影响分析)和 FTA(故障树分析)中推导出来。FMEA 是自下而上的:先列出每个部件的失效模式,再分析其局部影响和系统影响。FTA 是自上而下的:从顶事件(如“AEB 误触发”)出发,逐层分解到基本事件。

以 AEB 前向雷达为例,FMEA 中一条典型记录是:雷达目标距离输出值卡滞在上一帧。局部影响是“距离信息不更新”,系统影响是“AEB 可能对已消失的目标继续制动”。这条 FMEA 直接导出一个注入用例:在雷达目标距离稳定跟踪时,强制冻结距离输出 500 ms,观察 AEB 是否在目标消失后仍保持制动请求。

FTA 则帮助确定注入的优先级。如果顶事件“AEB 误触发”的故障树中,某个基本事件的底概率较高且安全机制覆盖不足,那么针对该事件的注入用例就应该优先执行、重复执行。

注入用例设计的结构化方法

一个可执行的注入用例,至少应包含以下字段:用例编号、关联安全目标、关联 FMEA/FTA 条目、注入对象、注入信号或变量、注入值或扰动方式、触发条件、持续时间、预期安全机制响应、观测点、通过判据。下面给出一个可直接参考的用例模板示例(参数为教学假设值,非实测结果):

用例编号: FI-AEB-RAD-007
关联安全目标: SG-AEB-02 (避免对消失目标持续制动)
关联FMEA: RAD-FM-012 距离输出卡滞
注入对象: 前向雷达目标距离信号
注入方式: 在目标稳定跟踪200ms后,冻结距离输出为当前值
触发条件: 车速>30km/h,目标距离<40m,AEB处于待机
持续时间: 500ms
预期响应: AEB在300ms内退出制动请求,仪表报“传感器性能下降”
观测点: CAN_AEB_Req, CAN_Radar_Status, 仪表告警
通过判据: 制动请求在350ms内撤销,且无碰撞风险

这个模板的关键在于“预期响应”和“通过判据”必须可量化。如果只写“系统应正确处理”,用例就无法自动判定通过与否。

从标准到注入的完整链路

把上述内容串起来,就形成了本节最值得可视化的核心关系:标准要求驱动安全目标,安全目标驱动 FMEA/FTA 分析,分析结果导出注入用例,用例执行后反馈诊断覆盖率,再反过来修正安全机制设计。这个闭环不是线性流程,而是一个带反馈的验证环。

标准 → 分析 → 注入 → 反馈 的验证闭环 ISO 26262 功能安全 · 硬件/系统失效 ISO 21448 预期功能安全 · 性能局限 安全目标 / ASIL SG-AEB-02 等 FMEA(自下而上) 部件失效模式 → 局部影响 → 系统影响 例:RAD-FM-012 距离输出卡滞 FTA(自上而下) 顶事件 → 中间事件 → 基本事件 例:AEB 误触发故障树 注入用例设计 注入对象 · 注入值 · 触发条件 · 持续时间 · 预期响应 · 通过判据 例:FI-AEB-RAD-007 冻结距离输出 500ms 台架/实车执行 观测 CAN 信号 记录响应时间 诊断覆盖率反馈 闭环核心:用例执行结果 → 修正 DC 估计 → 调整安全机制或补充注入用例

图中左侧两条标准线分别对应 26262 和 21448,它们共同导出安全目标;中间 FMEA 和 FTA 从两个方向逼近失效路径;下方注入用例层把分析结果转化为可执行、可判定的测试条目;右侧执行层负责观测和记录;虚线反馈回路表示诊断覆盖率结果会反过来修正安全机制设计或补充新的注入用例。这个闭环每转一圈,安全论证的置信度就提高一层。

在实际项目中,建议把 FMEA/FTA 条目编号直接写入注入用例的“关联分析”字段,这样当分析更新时,可以快速定位哪些用例需要同步修改,避免用例与分析脱节。

最后需要强调:故障注入的通过判据必须与安全目标对齐,而不是与“系统有没有报错”对齐。一个安全机制正确响应了故障,但仪表没有报警,用例仍然应该判为通过;反之,系统报了错但制动请求没有按时撤销,用例必须判为失败。判据的严格程度,直接决定了这套方法论能否真正支撑 ISO 26262 和 ISO 21448 的安全论证。