在HIL（硬件在环）台架上做故障注入，是功能安全验证绕不开的一步。车载控制器的软件里有相当大比例代码用于故障诊断与安全保护：检测异常、确认故障、进入降级或安全状态、记录故障码。这些安全机制在"一切正常"的台架上几乎无法验证——你很难让一个真实传感器恰好断线、恰好对地短路，也很难安全地复现过流、过温、通信中断。HIL的价值在于：在虚拟世界里精确、可重复、安全地制造故障，然后观察控制器是否按设计在规定时间内识别并响应。
本文按工程落地顺序，讲清楚HIL故障注入的类型、FIU故障注入单元的工作原理、故障矩阵怎么设计，以及如何支撑ISO 26262安全机制验证。
HIL故障注入的四种类型
按故障作用的层面，HIL可注入的故障大致分为四类：
| 故障层级 | 典型故障 | 注入方式 |
|---|---|---|
| 电气/引脚级 | 开路（断线）、对电源/地短路、引脚间短接、接触电阻增大、间歇接触不良 | FIU硬件通道 |
| 传感器/信号级 | 信号丢失/卡死/超量程/跳变、冗余信号不一致、零漂噪声异常 | 模型或报文层 |
| 总线/通信级 | 报文丢失/超时、周期抖动、错误帧、Bus-Off、校验和错误 | 总线仿真层 |
| 电源与系统级 | 电压跌落、欠压/过压、上下电异常、快速掉电复位、联动故障 | 程控电源+场景编排 |
一个实用原则：能用模型/报文层注入的故障优先在软件层做（迭代快、成本低），只有必须验证真实电气路径的故障（断线、物理短地/短电）才占用FIU硬件通道。功率级故障需要在功率回路中实现，成本与风险更高，一般只用于关键确认。
FIU故障注入单元如何工作
引脚级电气故障由专门的故障注入单元（Fault Injection Unit, FIU）完成。FIU以可编程开关矩阵（继电器或电子开关）串接在仿真通道与被测控制器引脚之间，在上位机控制下把某一路切换为：
- 开路（断开信号线）
- 接到电源（short to battery）
- 接到地（short to GND）
- 与其他引脚短接
切换时序可精确控制，支持间歇性接触不良等动态故障。选型时重点看三个指标：FIU通道数、支持的故障模式（开路/短地/短电/互短）、切换速度与带载能力。
以一条传感器信号线的故障矩阵配置为例，配置项可以这样组织：
fault_case:id:FC-0321target:pedal_position_sensor_1# 故障对象：油门位置传感器1mode:short_to_gnd# 故障模式：对地短路trigger_condition:# 触发工况engine_speed_rpm:3000vehicle_mode:drivetiming:# 注入时序inject_at_s:12.5duration_ms:800recovery:auto# 故障恢复方式expected_response:# 预期安全机制detect_within_ms:50dtc:P2122fallback_state:torque_derate故障矩阵与用例设计
故障测试要避免"想到哪测到哪"，建议以失效分析为基础形成故障矩阵，系统枚举并管理覆盖度。矩阵每一行是一个故障场景：
| 要素 | 说明 |
|---|---|
| 故障对象 | 哪个引脚/传感器/报文/电源 |
| 故障模式 | 开路/短地/短电/丢失/越界/超时等 |
| 触发工况 | 什么转速、转矩、车速、模式下注入（含稳态与瞬态） |
| 注入时序与持续 | 何时注入、持续多久、是否间歇、何时恢复 |
| 预期安全机制 | 多长时间内检测、确认、置什么DTC、进入什么状态 |
| 预期最终状态 | 降额/限扭/安全停机/恢复条件与恢复行为 |
| 判定与证据 | 通过判据、需要记录的波形/报文/日志 |
矩阵来源建议与FMEA/FTA、安全目标和诊断需求文档双向追溯：每个被识别的相关失效都应有对应用例，每条用例都能回溯到安全需求。同一故障还要覆盖"发生—持续—恢复"全过程，以及多故障组合的关键场景——真实风险往往出在瞬态和组合工况（比如高负载瞬间传感器丢失），只测单点稳态故障是不够的。
支撑ISO 26262安全机制验证
ISO 26262要求针对安全目标分解出的安全机制进行确认，证明其在故障发生时有效，且故障探测和故障反应时间满足要求。HIL在其中承担"可重复执行的验证平台"角色：
- 需求追溯：安全需求→安全机制→故障注入用例一一对应，形成覆盖矩阵；
- 故障反应时间测量：HIL可精确给出"故障注入时刻"和"控制器进入安全状态时刻"，量化FRTI/FHTI是否在允许时间内；
- 降级与恢复验证：验证限扭、安全状态、故障确认去抖、故障恢复策略；
- 边界与组合：在不同工况和故障组合下重复执行，验证机制稳健；
- 回归与独立性：软件变更后重跑，证明安全机制未被破坏。
故障用例数量大、每个软件版本都要重跑，手动执行不现实。成熟做法是把故障矩阵参数化、脚本化，由测试管理软件自动完成：设置工况→注入故障→采集控制器状态/总线/波形→与预期比对→输出带时间戳的报告。这样每次回归都能自动生成可追溯的证据包（用例、版本、结果、波形、故障码），直接服务于功能安全评审和审核。
以宏控天工（Macrosoftsys）的HIL平台为例，其台架标配故障注入单元与信号级故障仿真，支持CAN/CAN FD总线故障、电源与传感器故障注入，并可按通道和故障模式扩展；配合SimCore仿真测试平台的用例管理、自动化执行与报告生成能力，可以把上述"故障矩阵—用例—证据包"的流程在台架上闭环跑起来。若正在规划功能安全验证，可提供控制器安全需求或故障清单，协助评估FIU通道配置与故障矩阵搭建方式（可通过官网或私信沟通）。
常见问题（FAQ）
Q1：故障注入和普通测试有什么区别？
A：普通测试验证"正常输入→预期输出"，故障注入验证"异常输入→安全响应"。它制造传感器断线、短路、信号丢失、总线故障等异常，检验控制器的诊断与安全保护机制是否在规定时间内正确动作。
Q2：FIU通道要配多少才够？
A：取决于被测控制器的引脚数量和需要验证的电气故障范围。信号级故障（值异常、丢失、跳变）可以在模型/报文层注入，不占用FIU通道；只有需要验证真实电气路径的断线、物理短地/短电才需要FIU硬件通道。建议结合故障矩阵统计需要电气注入的引脚数再定。
Q3：故障注入能证明功能安全合规吗？
A：不能单独证明。HIL故障注入是功能安全验证手段之一，提供强有力的测试证据（故障反应时间、降级行为、恢复行为），但不替代安全分析、设计与流程本身的合规。合规需要安全流程、安全分析文档、需求追溯与测试证据共同支撑。
Q4：故障用例太多跑不完怎么办？
A：两个方向：一是按风险优先级排序（FMEA/FTA识别的高风险失效优先），二是自动化——把故障矩阵参数化、脚本化，由测试管理软件自动批量执行并生成证据包，回归成本大幅下降。
