3. 故障注入验证的适航与安全标准约束

故障注入验证不是一项可以随意设计、随意裁剪的测试活动。在航空航天领域，它受到一整套适航与安全标准的约束，这些标准决定了“为什么做、做到什么程度、由谁来做、留下什么证据”。如果忽略这些约束，即使注入结果看起来令人满意，也无法作为适航审查或安全评估的有效证据。本节围绕 DO-178C、DO-254、DO-160、ARP4754A、ARP4761 以及 ECSS-Q-ST-30-02C，梳理它们对故障注入验证的具体要求，并明确验证目标、独立性、覆盖率和证据文档四个维度的合规边界。

各标准在故障注入验证中的定位

这些标准并非同一层级，而是分布在“系统—软硬件—环境—安全性”不同层面。ARP4754A 面向民用飞机与系统研制过程，规定系统级安全性评估与验证活动；ARP4761 提供安全性评估方法，包括 FHA、PSSA、SSA 以及故障树分析、共因分析等，是确定故障注入对象和判据的重要来源。DO-178C 针对机载软件，DO-254 针对机载复杂电子硬件，二者规定生命周期过程与验证目标，其中对鲁棒性验证、异常处理、覆盖率的条款直接约束故障注入。DO-160 面向机载设备环境条件与试验程序，规定温度、振动、电源、电磁兼容等环境试验，故障注入若涉及环境应力下的行为验证，需与其试验条件协调。ECSS-Q-ST-30-02C 是欧空局航天产品保证标准中的故障容错要求，强调故障检测、隔离与恢复，适用于航天器相关系统的故障注入验证。

验证目标的确定：从安全性需求到注入用例

故障注入验证的目标不能由测试人员凭经验随意设定，而应追溯到安全性评估的输出。ARP4761 中的 FHA 识别出失效状态及其类别，PSSA 进一步分配安全性需求到系统架构和软硬件项，SSA 则验证这些需求是否被满足。故障注入正是 SSA 阶段验证故障容错机制有效性的手段之一。例如，某飞控系统在 PSSA 中确定“舵面位置传感器单点失效不得导致灾难性后果”，并分配了“传感器信号比较与表决”这一安全性需求。对应的故障注入目标就是：注入传感器信号偏差或丢失故障，验证表决逻辑能否在限定时间内检测并隔离，系统是否降级到安全状态。

DO-178C 对软件鲁棒性验证的要求，进一步细化了注入目标。标准要求验证软件在异常输入、异常时序和资源异常条件下的行为。因此，软件级故障注入目标通常包括：非法输入值、接口数据超范围、任务超时、内存分配失败、中断风暴等。DO-254 则要求对硬件设计中的故障模式进行验证，例如寄存器位翻转、时钟丢失、总线错误等。ECSS-Q-ST-30-02C 强调故障检测、隔离与恢复的完整链条，注入目标需覆盖检测覆盖率、隔离正确性和恢复时间。

独立性要求：谁来做，做到什么程度

DO-178C 和 DO-254 都明确要求验证活动具备独立性。独立性不是形式上的“换个人签字”，而是要求验证人员不参与被验证对象的开发，且验证结果不受开发方影响。对于故障注入验证，独立性体现在：注入用例的设计应基于安全性需求和接口规范，而非开发人员提供的内部实现细节；注入执行和结果判定应由独立验证人员完成；对异常结果的处置不能由开发方单方面决定。

在实际项目中，独立性通常分为三个层次。第一层是“独立测试人员”，即由不同于开发者的测试工程师执行注入；第二层是“独立验证团队”，团队不隶属于开发组织；第三层是“独立审查”，由适航审查方或第三方评估机构对验证过程和证据进行审查。对于 A 级软件，DO-178C 要求验证独立性达到最高程度，故障注入的用例设计、执行和结果评估都应有独立人员参与。对于 ECSS 项目，独立性要求通常体现在产品保证组织的监督和评审中。

覆盖率：从需求覆盖到故障模式覆盖

覆盖率是故障注入验证中最容易被误解的指标。DO-178C 的覆盖率要求分为需求覆盖和结构覆盖。需求覆盖要求每个软件需求都有验证用例，故障注入用例应覆盖与安全性相关的需求，尤其是异常处理和故障容错需求。结构覆盖包括语句覆盖、判定覆盖、MC/DC 等，对于 A 级软件，MC/DC 是强制要求。故障注入验证虽然不直接等同于结构覆盖测试，但注入用例应能触发与故障处理相关的判定分支，否则无法证明故障处理逻辑被有效执行。

DO-254 对硬件验证的覆盖率要求包括设计元素覆盖和故障模式覆盖。故障模式覆盖要求验证所有已识别的硬件故障模式是否被检测或容错。ECSS-Q-ST-30-02C 则强调故障检测覆盖率、故障隔离覆盖率和恢复覆盖率。在实际操作中，覆盖率通常以矩阵形式管理：每一行是一个安全性需求或故障模式，每一列是对应的注入用例、执行结果和证据编号。覆盖率不是越高越好，而是要求“每个安全性相关项都有对应验证”，未覆盖项必须有明确的理由和风险评估。

证据文档：合规的最终落脚点

所有标准最终都要求形成可审查的证据。故障注入验证的证据文档不是简单的测试记录，而是一套可追溯的证据链。DO-178C 要求验证证据包括验证计划、验证用例、验证结果和验证总结，且每个结果应能追溯到需求和目标。DO-254 要求硬件验证计划、验证环境和验证结果。ARP4754A 要求系统验证计划与安全性评估报告关联。ECSS-Q-ST-30-02C 要求故障容错验证报告，包含故障注入条件、预期响应、实际响应和偏差分析。

在实际操作中，一份合规的故障注入验证记录通常包含以下字段：注入用例编号、对应安全性需求编号、故障模式描述、注入位置与方式、注入参数、预期系统响应、实际响应、判定结果、执行人员与日期、证据文件编号。对于未通过项，还需记录偏差报告、原因分析和纠正措施。这些字段不是形式主义，而是审查方判断验证是否充分、独立性是否满足、覆盖率是否完整的主要依据。

合规边界的实际把握

综合来看，这些标准对故障注入验证的约束可以归纳为四条边界。第一，目标边界：注入目标必须来自安全性评估和需求，不能随意扩展或缩减。第二，独立性边界：验证人员、用例设计和结果判定应独立于开发，A 级项目要求最高。第三，覆盖率边界：安全性相关需求和故障模式必须全覆盖，未覆盖项需有风险评估和审查方认可。第四，证据边界：所有注入活动必须形成可追溯、可审查、与构型一致的文档记录。

在实际项目中，建议在故障注入验证策划阶段就建立“标准—需求—用例—证据”的映射关系。例如，用一张追溯矩阵把 DO-178C 的鲁棒性验证目标、ARP4761 的 FTA 底事件、ECSS 的故障检测需求分别映射到具体注入用例和证据编号。这样在审查时，可以快速证明每个标准要求都有对应的验证活动，而不是在审查前临时补文档。故障注入验证的价值不仅在于发现设计缺陷，更在于为适航和安全评估提供可信、完整、独立的证据。