1. 航空嵌入式软件故障注入测试导论
航空嵌入式软件与普通消费电子软件最大的差别，不在于代码规模，而在于它一旦失效，后果往往直接指向飞行安全。飞控计算机、发动机控制单元（FADEC）、大气数据惯性基准、座舱显示与告警系统，这些设备中的软件长期运行在强实时、强约束、强耦合的环境中，输入来自传感器总线，输出直接驱动执行机构或告警逻辑。因此，适航审定并不满足于"软件在正常条件下能跑通"，而是要求证明软件在异常输入、硬件退化、通信中断、时序抖动等条件下，仍能进入并维持安全状态。故障注入测试，正是为这一证明过程提供证据的核心手段之一。
课程目标与定位
本课程面向航空嵌入式软件测试工程师、适航符合性验证人员以及系统安全评估人员，目标是让学习者能够独立设计、执行并判读一次有工程意义的故障注入测试。具体而言，课程结束后应具备以下能力：理解故障注入在 DO-178C 及 ARP4754A 体系中的位置；能够根据 FHA、FMEA、FTA 的输出确定注入对象与注入点；能够选择硬件注入、软件插桩、总线仿真或环境模拟等不同注入方式；能够设计覆盖安全需求的测试用例并记录可追溯证据；能够区分"检测到故障""正确响应""未产生危险输出"三类判据；能够将测试结果整理为适航审查可接受的符合性数据。
需要强调的是，故障注入不是"制造麻烦"，而是"受控地制造已知异常，以观察系统是否按设计预期响应"。它与常规功能测试的根本区别在于：功能测试验证"正常输入下输出正确"，故障注入验证"异常条件下安全逻辑有效"。两者共同构成软件验证的完整证据链。
故障注入在适航符合性验证中的位置
在民用航空领域，软件适航符合性验证主要依据 DO-178C《机载系统和设备合格审定中的软件考虑》。该标准将软件生命周期过程分为计划、开发、验证和配置管理，其中验证过程要求通过评审、分析和测试三种手段获取证据。故障注入测试属于"测试"手段中面向鲁棒性与安全需求的部分，通常与需求覆盖分析、结构覆盖分析配合使用。
从系统层面看，故障注入的输入来自安全性评估过程。ARP4754A 要求通过功能危害评估（FHA）识别功能失效状态及其等级，再通过故障树分析（FTA）或失效模式与影响分析（FMEA）向下分解到软硬件层级。当某个失效状态的严重度达到"灾难性"或"危险性"时，必须证明相应的安全需求已被实现并验证。故障注入测试就是对这些安全需求的直接验证活动。
下图展示了从安全性评估到故障注入证据的完整链路，以及各环节之间的输入输出关系。
图中链路说明了一个关键原则：故障注入测试不是孤立活动，它的每一个注入点都应能追溯到某条安全需求，每一个测试结果都应能回填到符合性矩阵中。缺少这条追溯链，测试即使执行了，也无法作为适航证据使用。
典型航空软件失效案例与测试需求来源
回顾航空史，多起事故与软件在异常条件下的行为直接相关。以下案例虽已广为人知，但从故障注入视角重新审视，能清晰看出测试需求是如何产生的。
| 案例 | 失效表现 | 暴露的测试需求 |
|---|---|---|
| A320 电传飞控早期事件（1988） | 迎角传感器结冰导致数据跳变，飞控计算机按错误数据配平，飞机进入危险姿态 | 传感器数据合理性检查、多源表决逻辑、故障检测后的降级策略必须被注入验证 |
| B737 MAX MCAS 相关事故（2018–2019） | 单一天迎角输入触发配平指令，且未在异常时充分限制权限 | 单点故障输入下的功能权限限制、告警逻辑、飞行员可干预性需专项注入测试 |
| Ariane 5 首飞失败（1996） | 惯性基准软件将 64 位浮点转为 16 位整数时溢出，触发自检并关机 | 边界值、溢出、类型转换异常必须作为注入用例，且需验证异常处理路径 |
| 某型发动机 FADEC 通信中断事件 | ARINC 429 总线间歇性丢帧，控制律未及时进入备份通道 | 总线故障注入、超时检测、通道切换时序需覆盖 |
这些案例共同指向一个结论：航空软件的安全需求，大量来自"异常条件下的行为约束"，而非正常功能本身。因此，故障注入的测试需求主要来源于四个方向。
- 安全性评估输出：FHA 中严重度为灾难性或危险性的失效状态，经 FTA 分解后形成的安全需求，是注入测试的首要来源。例如"当迎角数据无效时，飞控应在 100 ms 内停止配平并告警"。
- 接口与通信规范：ARINC 429、ARINC 653、CAN、AFDX 等总线协议中定义的错误帧、超时、校验失败、分区超时等异常场景，需通过注入验证接收端处理逻辑。
- 硬件失效模式：传感器漂移、卡死、断线、电源瞬断、存储器位翻转等，需在软件层面注入等效异常，观察检测与响应。
- 适航条款与标准要求：DO-178C 对鲁棒性验证的要求、DO-160 环境试验中的电磁干扰与电源异常、以及审定当局发布的专用条件，都会转化为具体注入用例。