2. 航电系统失效模式与安全性需求
冗余架构解决的是“失效之后还能不能继续工作”的问题，而安全性需求回答的是“哪些失效必须被防住、防到什么程度”。在航电系统中，这两者通过失效模式分析、故障树和安全性指标形成闭环：先识别功能失效的类别与后果，再推导出定量的安全性目标，最后把这些目标分配到具体的冗余通道、监控逻辑和隔离机制上。本节围绕功能失效分类、失效模式与影响分析（FMEA）、故障树分析（FTA）以及安全性评估指标与派生需求四条主线展开。
一、功能失效分类：先分清“坏成什么样”
航电功能失效不能只用“坏了”来描述。工程上通常按后果严重程度和失效表现形态两个维度分类。按后果严重程度，可对应到适航常用的等级：灾难性（Catastrophic）、危险性（Hazardous）、较大（Major）、较小（Minor）、无安全影响（No Safety Effect）。例如，飞行控制律完全丧失属于灾难性，而单个显示器画面闪烁通常只算较小。
按失效表现形态，更贴近冗余设计的需要，可分为：
- 显性失效（主动失效）：失效立即被察觉，如通道输出饱和、总线报错、电源掉电。这类失效容易被监控捕获，隔离相对直接。
- 潜伏失效（被动失效）：失效后系统仍“看起来正常”，如备用通道悄悄失去供电但未被检测。潜伏失效是冗余架构最大的敌人，必须靠周期性自检（PBIT/CBIT）把它暴露出来。
- 共因失效：同一原因同时击穿多个冗余通道，如共用电源、共用时钟、同一软件缺陷、同一安装区域的振动或温度。共因失效直接破坏冗余的独立性假设。
- 级联失效：一个通道失效后引发相邻通道过载或误动作，如短路拉低共享总线。
分类的意义在于：显性失效靠比较与监控，潜伏失效靠自检覆盖率，共因失效靠物理与逻辑隔离。三类失效对应三种不同的设计手段，不能混为一谈。
二、失效模式与影响分析（FMEA）
FMEA 是自下而上的归纳方法：从每个部件或功能的最小单元出发，列出其可能的失效模式，分析对上一层功能乃至整机的影响，并给出检测手段和严重度。对航电系统，FMEA 通常以“功能—部件—失效模式—局部影响—上层影响—最终影响—检测方法—严重度”为字段组织。
以某型大气数据计算机（ADC）的一个通道为例，可建立如下分析条目（示例参数，用于说明方法）：
| 失效模式 | 局部影响 | 上层影响 | 检测方法 | 严重度 |
|---|---|---|---|---|
| 静压传感器漂移 | 高度输出缓慢偏差 | 高度显示与自动驾驶高度保持偏差 | 与惯导/大气数据比对，交叉通道比较 | 较大 |
| 通道输出卡死 | 输出恒定值 | 该通道数据不可信 | 输出范围检查、通道间比较 | 危险性 |
| 供电丢失 | 通道停止工作 | 剩余通道承担全部功能 | 电源监控、心跳信号 | 较大 |
| 软件死循环 | 无更新输出 | 通道失效但可能不被立即发现 | 看门狗、周期刷新监控 | 危险性 |
FMEA 的关键输出不是表格本身，而是“哪些失效模式必须被监控覆盖”。凡是严重度达到较大及以上的失效模式，都应有一条明确的检测路径；否则该失效就属于潜伏失效，必须通过提高自检覆盖率或增加交叉比较来弥补。
三、故障树分析（FTA）
FTA 是自上而下的演绎方法：从顶事件（如“失去全部自动驾驶功能”）出发，用与门、或门逐层分解到基本事件，找出导致顶事件的最小割集。与 FMEA 互补，FTA 更擅长处理多故障组合和共因失效。
下图给出一个简化的故障树示例：顶事件为“失去全部自动驾驶功能”，其下分解为“三个通道全部失效”与“共因失效”两条路径。图中同时标出或门、与门以及基本事件，便于理解最小割集的形成。
从图中可以看出，三通道全失效需要三个独立事件同时发生，概率是三者之积，通常极低；而共因失效割集只有一个基本事件，其概率直接决定顶事件概率下限。因此，FTA 的真正价值在于暴露“单点共因”路径，并据此提出隔离要求，例如为三个通道配置独立电源、独立时钟、独立软件分区。
四、安全性评估指标与派生需求
安全性指标把定性分析转化为可验证的定量目标。适航实践中常用的指标包括：
- 失效概率目标：灾难性失效 ≤ 10⁻⁹/飞行小时，危险性 ≤ 10⁻⁷/飞行小时，较大 ≤ 10⁻⁵/飞行小时（示例量级，具体以适用规章为准）。
- 失效影响概率：某失效模式导致顶事件的概率，用于把整机目标分解到部件。
- 自检覆盖率：潜伏失效被周期性检测到的比例，直接影响潜伏失效的暴露时间。
- 共因失效因子 β：描述冗余通道因共因同时失效的比例，β 越小，冗余越有效。
派生需求就是把上述指标翻译成设计约束。例如，若顶事件目标为 10⁻⁹/飞行小时，三通道独立失效贡献约 10⁻¹²，则共因路径必须控制在 10⁻⁹ 量级以内，由此派生出：三通道电源独立、时钟独立、软件不同分区或不同实现、安装区域物理隔离、共因失效因子 β 不超过 10⁻² 等具体要求。这些要求再落到具体的冗余架构、监控逻辑和隔离机制上，形成“安全性目标—派生需求—架构实现—验证证据”的完整链条。