4. 故障注入验证计划与需求分解

故障注入验证不是“找几个故障试试系统会不会坏”，而是一项由安全需求驱动的、可追溯的符合性活动。它的起点不是测试台架，而是系统安全需求、FHA/SSA 的输出以及适航审定基础（Certification Basis）。本节要解决的核心问题是：如何把这些上游安全成果分解为一份可执行的故障注入验证计划，明确注入范围、成功准则、通过/失败判据，并建立与系统验证矩阵的追溯关系。

一、上游输入：故障注入需求的三个来源

故障注入验证计划的第一份工作，是把上游安全成果“翻译”成注入需求。三个来源各有分工：

• 系统安全需求：来自系统级安全需求文档，通常以“当发生某失效时，系统应在某时间内进入某安全状态”的形式给出。它规定了注入的目标失效与期望响应，是判据的直接来源。
• FHA（功能危害评估）输出：给出功能失效状态、失效条件、飞行阶段与危害等级（如 Catastrophic / Hazardous / Major / Minor / No Safety Effect）。它决定了注入的优先级与覆盖深度——灾难级失效必须注入，且需覆盖最恶劣的飞行阶段组合。
• SSA（系统安全评估）输出：给出 FTA（故障树）、FMEA/FMES、共因分析（CCA）结果，明确了哪些失效组合、哪些冗余通道、哪些监控器（Monitor）参与安全目标。它决定了注入的具体对象与组合方式。

适航审定基础则提供“必须满足的条款”，例如 CCAR/FAR 25.1309、25.1322（告警）、25.1353（电气）、25.671（飞控）等，以及相应的咨询通告（如 AC 25.1309-1A）和专用条件。审定基础决定了验证的接受方法：是试验、分析、还是两者结合，以及是否允许用故障注入试验替代部分分析。

二、需求分解：从安全目标到注入用例

需求分解的本质是建立一条“安全目标 → 安全需求 → 系统需求 → 注入用例”的链路。以某型电传飞控系统的“俯仰率监控器”为例，其安全需求为：当俯仰率信号与惯性参考不一致超过阈值并持续 200 ms 时，系统应在 100 ms 内降级至备用通道并点亮 MASTER CAUTION。分解过程如下：

1. 识别安全目标：防止俯仰率信号错误导致非指令俯仰运动（危害等级 Hazardous）。
2. 提取可注入的失效模式：传感器漂移、信号卡滞、总线数据丢失、监控器阈值偏移、通道切换逻辑失效。
3. 确定注入点：传感器输出端、总线接口、监控器输入、通道切换执行端。
4. 定义观测点：降级标志位、MASTER CAUTION 离散量、通道状态字、总线报文时间戳。
5. 形成注入用例：每个用例包含失效模式、注入位置、注入时机（飞行阶段）、持续时间、期望响应与判据。

分解后的用例必须能反向追溯到安全需求编号，否则该用例在验证矩阵中就是“孤儿用例”，审定审查时会被质疑其必要性。

三、注入范围与成功准则

注入范围由 FHA/SSA 的危害等级和覆盖要求共同决定。工程上常用“危害等级—注入深度”对应关系：灾难级失效需覆盖单点失效、组合失效及共因失效；危险级需覆盖单点与关键组合；重大级可抽样覆盖。范围还应明确不注入什么——例如已由相似性分析或服役历史证明的失效，可申请豁免并记录理由。

成功准则必须可观测、可量化。它通常包含三要素：响应正确性（是否进入预定安全状态）、响应时间（是否在需求规定的时间内）、告警正确性（告警级别、内容、时机是否符合 25.1322）。例如上述俯仰率监控器用例的成功准则为：降级标志位在 100 ms 内置位、MASTER CAUTION 在 150 ms 内点亮、无虚假告警、备用通道接管后俯仰率偏差小于 0.5°/s。

四、通过/失败判据与验证矩阵追溯

判据是成功准则的“判定规则”，必须避免模糊表述。推荐采用“阈值 + 容差 + 采样窗口”的形式。例如“降级时间 ≤ 100 ms”应写成“从注入触发沿到降级标志位置位沿的时间差 ≤ 100 ms，采样率 1 kHz，连续 3 次试验均满足”。失败判据则包括：超时、未降级、误降级、告警缺失、告警级别错误、通道切换后系统不可用等。

与系统验证矩阵的追溯关系，是验证计划能否通过审定的关键。矩阵中每一行对应一条安全需求，列包括：需求编号、FHA 危害等级、SSA 来源（FTA 底事件/FMEA 条目）、注入用例编号、注入点、观测点、判据、试验状态、符合性结论。这样，审查方可以沿“需求—用例—结果”链路逐级核查，也能快速识别覆盖缺口。

五、计划编写中的常见问题与处理

第一类问题是“判据不可测”。例如写成“系统应正确响应”，审查时无法判定。处理方法是把“正确”拆成可观测的离散量、总线字或时间戳，并规定采样率与容差。第二类问题是“注入点与观测点不匹配”，例如在传感器输出端注入，却在显示器上观测，中间经过多级处理，无法定位失效传播路径。应尽量在靠近失效源的接口注入，并在信号链的关键节点设置观测点。第三类问题是“追溯断裂”，即用例无法对应到具体安全需求或 SSA 条目。处理方法是建立需求—用例双向矩阵，并在计划评审时逐条核对。

六、与系统验证矩阵的接口

系统验证矩阵是故障注入验证计划的“总账”。矩阵中应至少包含以下列：安全需求编号、FHA 危害等级、SSA 来源、注入用例编号、注入点、观测点、判据、试验方法（台架/铁鸟/飞行试验）、试验状态、符合性结论、备注。故障注入验证计划负责提供“注入用例编号—注入点—观测点—判据”这几列的内容，系统验证矩阵负责汇总并给出最终符合性结论。两者通过需求编号和用例编号双向关联，形成可审查的闭环。

当注入试验失败时，不能简单标记“失败”了事。应记录失败现象、复现条件、初步原因分析，并判断是系统设计缺陷、试验配置错误还是判据设置不当。若是设计缺陷，需触发问题报告并跟踪至归零；若是判据问题，需修订验证计划并重新评审。只有把失败处理流程也纳入计划，故障注入验证才真正具备工程闭环能力。

综上，故障注入验证计划的编写，本质是把上游安全成果转化为可执行、可观测、可追溯的注入用例集合。范围由危害等级决定，准则由安全需求决定，判据由工程可测性决定，追溯由验证矩阵保证。四者缺一不可，才能支撑适航审定中的符合性论证。