1. 课程导入与全景认知

在航空航天领域，飞行控制系统、导航系统、动力系统与能源系统一旦在真实飞行中出现异常，代价往往不可逆。因此，工程上不会把"系统能否应对故障"这个问题留到试飞阶段才回答，而是尽可能早地在实验室里，用硬件在环（Hardware-in-the-Loop，HIL）的方式把真实控制器接入仿真环境，人为制造故障，观察系统是否按预期降级、告警、切换或安全中止。这套"人为制造异常并验证系统响应"的方法体系，就是本课程要讲的HIL故障注入与异常验证。

一、什么是HIL故障注入与异常验证

HIL是一种半实物仿真测试形态：被测对象是真实的机载硬件（如飞控计算机、导航计算机、作动器控制单元、电源管理单元），而它"感知"到的飞机、大气、发动机、电网、传感器信号，全部由实时仿真机通过IO接口和总线模拟产生。真实硬件在闭环中运行，其输出又反馈给仿真模型，形成与真实飞行等价的信号回路。

故障注入（Fault Injection）是在这个闭环中，按预定策略主动改变信号、总线报文、供电条件或硬件连接，使被测系统进入异常工况。异常验证（Anomaly Verification）则是判断系统在异常下的行为是否满足设计预期——是否在规定时间内检测到故障、是否给出正确告警、是否切换到备份通道、是否进入安全模式、是否保持在允许的包线内。

需要强调的是，故障注入不是"随便把线拔掉看会怎样"，而是有明确故障模型、注入位置、注入时机、持续时间和判据的受控实验。一次有效的注入，必须能回答三个问题：注入了什么故障、系统在什么时刻以什么方式响应、这个响应是否可接受。

二、为什么必须做：价值与工程意义

故障注入与异常验证的价值，集中体现在四个方面。

• 安全性验证：验证关键系统在单点故障、组合故障下仍能维持安全飞行或安全中止，是适航符合性验证的重要证据来源。
• 覆盖度提升：真实试飞难以复现传感器漂移、总线丢帧、电源瞬断、执行机构卡滞等故障，HIL可以精确、可重复地制造这些工况。
• 早期暴露缺陷：在硬件尚未装机、飞机尚未首飞时，就能发现监控逻辑漏洞、余度切换错误、时序竞争等问题，修复成本远低于试飞阶段。
• 可重复与可回归：同一故障用例可在软件版本迭代后反复执行，形成回归基线，防止修改引入新问题。

三、典型被测对象与故障关注点

航空航天HIL故障注入的对象通常围绕几类关键系统展开，每类系统的故障关注点差异明显。

以飞控为例，一个典型的注入场景是：在平飞配平状态下，向某一余度通道的大气数据总线注入"空速信号缓慢漂移"故障，漂移速率设为每秒0.5 m/s，持续20 s。观察飞控计算机是否在漂移超过阈值后触发比较监控、是否隔离该通道、是否由三余度降级为双余度并保持姿态稳定。这里的0.5 m/s和20 s属于教学示例参数，实际取值需依据系统监控门限和适航要求确定。

四、全流程概览

从工程实施角度看，一次完整的HIL故障注入与异常验证，通常经历以下环节：明确验证目标与安全边界 → 建立故障模型并选择注入位置 → 搭建/配置HIL闭环环境 → 设计故障用例（故障类型、幅值、时机、持续时间、判据） → 执行注入并采集数据 → 分析系统响应并判定通过/失败 → 记录问题、回归验证。这个链条中，故障模型与判据设计是最容易被低估、却最决定验证有效性的环节。

下图给出本节的全景认知视图：左侧是四类典型被测对象，中间是HIL闭环与故障注入通道，右侧是异常验证的判据与结果去向，底部贯穿全流程环节。

五、几个容易混淆的边界

第一，故障注入不等于破坏性试验。多数注入是在信号层、总线层或供电层完成的，被测硬件本身通常不被物理损坏；真正涉及硬件损伤的注入（如真实短路）需要单独评估风险并做防护。

第二，HIL不等于纯软件仿真。纯软件仿真（SIL）中控制器也是模型，无法暴露真实硬件的时序、驱动能力、总线仲裁和供电特性问题；HIL的价值恰恰在于"真实硬件在环"。

第三，异常验证不等于功能测试。功能测试回答"正常输入下系统是否做对"，异常验证回答"异常输入下系统是否不失控"。两者判据不同，前者看功能正确性，后者看安全性与容错能力。

六、本课程的学习路径

后续内容将沿着"对象—故障模型—注入实现—验证判据—问题定位"的主线展开：先分别深入飞控、导航、动力、能源等对象的故障机理与注入点，再讲信号级、总线级、供电级和硬件级注入的具体实现方式，然后进入用例设计、数据判读与典型异常案例复盘。学完本课程，你应当能够独立设计一份可执行的HIL故障注入用例，并在注入后依据采集数据判断系统响应是否满足预期。

作为入门练习，可以先思考一个问题：如果要在HIL环境中验证"飞控计算机在某一路大气数据总线失效后能否在200 ms内完成通道隔离并保持姿态稳定"，你需要确定哪些注入参数、采集哪些信号、用什么判据来判定通过？这个问题的答案，将贯穿本课程的核心方法。