民用飞机系统安全性设计与评估技术

System Safety Design & Assessment for Civil Aircraft

教学讲义 · 基于 CCAR-25.1309 / SAE ARP4754A / ARP4761

第1章 绪论基础

本章在讲什么？ 一架现代民航客机有数百万个零件、上百个系统，任何一个失效都可能酿成灾难。如何系统化地保证"飞机足够安全"？这就是"系统安全性"这门学科要回答的问题。本章为整本书铺路，先把一系列绕不开的术语、为什么需要这门学科、它从何而来又走向何方，讲清楚。

1.1 为什么需要"系统安全性"？

早期的飞机设计依赖"试飞-坠机-改进"的经验循环，安全性靠事后吸取教训。但现代民机有以下特征：

  • 系统极度复杂：一架 C919 拥有约 100 个系统，数千万行机载软件代码，单靠经验已无法预测所有失效组合；
  • 失效后果极严重：一次空难可造成数百人死亡，公众与监管对安全的容忍度趋近于零；
  • 必须事前证明：飞机要拿到型号合格证（TC），必须在首飞之前用分析手段证明其足够安全，而不能"飞起来再说"。

因此发展出了一整套"用工程化方法、在设计阶段就预测并消除危险"的学科——这就是"民机系统安全性设计与评估"。

1.2 必须掌握的基本概念

这些术语在后续每一章都会反复出现，含义务必准确：

术语含义解释
故障 Fault 部件处于"不正常"状态，但不一定立刻表现出来。例如电阻漂移、传感器零点偏移。它是失效的原因。
失效 Failure 系统/部件丧失了规定的功能。例如"液压泵不再产生压力"。它是故障的表现。
失效状态 Failure Condition 把一个或多个失效放回"飞机正在飞行"这个真实场景中所产生的后果。例如"巡航中双发停车"。它强调的是对飞机和乘员的影响，而不是单个部件坏了。
危险 Hazard 潜在的伤害源。可以来自系统内部（设计错误），也可以来自外部（鸟撞、雷击）。
风险 Risk "事情发生的可能性 × 一旦发生有多严重"。安全性工程的目标就是把风险控制在可接受水平。
安全性 Safety 免于不可接受风险的状态。注意：绝对安全不存在，安全是一个"足够低的风险"概念。

1.3 失效状态的五个等级——全书的基准刻度

适航规章用一把"尺子"衡量后果严重程度，把所有失效状态划分到五个等级，并对每一等级规定了允许出现的最大概率。这是安全性设计中的"金科玉律"：越严重的后果，发生概率必须越低。

等级对飞机/乘员的影响定性目标定量目标（每飞行小时）
灾难的
Catastrophic		阻止飞机继续安全飞行和着陆，通常意味着机毁人亡极不可能\(< 10^{-9}\)
危险的
Hazardous		显著降低飞机或机组的能力，少数乘员严重受伤或死亡极微小可能\(< 10^{-7}\)
较大的
Major		显著降低安全裕度或工作能力，乘员不适微小可能\(< 10^{-5}\)
较小的
Minor		稍微增加机组工作负担，不显著影响安全可能\(< 10^{-3}\)
无安全影响
NSE		对飞行安全无影响—无要求
💡 直观理解 \(10^{-9}\) 是什么概念 每飞行小时小于 \(10^{-9}\)，意味着每十亿飞行小时才允许出现一次。如果全球民机机队一年总共飞 1 亿小时，那么这种灾难性失效平均要"等十年"才会发生一次——这就是安全的工程化目标。

1.4 学科的发展脉络

系统安全性学科经历了三个阶段的演进：

  • 经验阶段（1950 年代以前）：靠飞行事故反推改进，没有系统化方法；
  • 可靠性阶段（1960~1980 年代）：引入故障率、MTBF 等指标，但只关注单个部件好不好，不关注"一坏会怎样"；
  • 系统安全性阶段（1980 年代至今）：以 ARP4754/ARP4761 为代表，从飞机功能出发自顶向下分析、自底向上验证，把安全性变成可证明、可追溯的工程过程。

当前趋势：基于模型的安全性分析（MBSA）、与网络安全的融合、面向新构型（如电动飞机、eVTOL）的方法扩展。

第2章 规章、咨询通告与工业标准了解

本章在讲什么？ 民机安全性不是工程师"觉得安全"就行，必须满足法律。本章梳理"做安全性工作要听谁的"——包括强制性的适航规章（必须做）、咨询通告（推荐怎么做）和工业标准（业界公认的具体方法）。三者构成一个由"要求"到"方法"的完整体系。

2.1 我国适航法规的四级体系

从顶到底依次约束力递减、具体性递增：

① 法律
《中华人民共和国民用航空法》——最高层，规定民航活动总框架
② 行政法规
《民用航空器适航管理条例》——国务院发布，建立适航审定制度
③ 规章 CCAR
由民航局发布，例如 CCAR-25《运输类飞机适航标准》——具有强制力
④ 咨询通告 AC
提供"可接受的符合性方法"（AMC），不强制但实际上是"标准答案"

2.2 母条款 25.1309——一切的源头

整本教材的核心法律依据就是 CCAR/FAR 25.1309。它对系统安全性提出了两条根本要求：

⚖️ 25.1309 的核心要求 1. 任何妨碍飞机继续安全飞行和着陆的失效状态，发生的可能性必须是"极不可能的"（即 \(< 10^{-9}\)/FH）；
2. 任何降低飞机能力或机组应对能力的失效状态，发生的可能性必须是"不可能的"。
并且必须用分析方法证明上述要求得到了满足，必要时辅以试验。

这看似简短，却给整个行业指明了方向——不是"飞得多了证明安全"，而是"在设计图纸上就要算出来安全"。后续所有 FHA、PSSA、SSA、FTA 等技术，本质上都是在回答一个问题："我怎么向局方证明我满足了 25.1309？"

2.3 配套的工业标准——告诉你"具体怎么做"

规章只说"要安全"，不说"具体步骤"。具体步骤由 SAE 和 RTCA 这样的国际标准化组织制定：

标准编号名称解决什么问题
SAE ARP4754A民用飞机和系统研制指南规定整机/系统级研制流程，怎样确认和验证需求，怎样做研制保证
SAE ARP4761安全性评估过程指南规定 FHA、PSSA、SSA、CCA 等所有安全性技术的具体方法——本书的主要参考
RTCA DO-178C机载软件适航软件的研制保证
RTCA DO-254机载电子硬件适航复杂电子硬件的研制保证
三者关系一句话：CCAR-25 是法律，AC25.1309 解释怎么满足，ARP4754A/4761 提供工程操作手册。

第3章 飞机系统安全性设计与评估体系核心

本章在讲什么？ 前两章告诉你"为什么"和"听谁的"，本章告诉你"整体怎么干"。它把飞机研制全过程中的所有安全性活动串成一条主线，形成一个 "V 字形"的工程框架——左侧从飞机级一路向下分配需求，右侧从部件级一路向上验证符合性。

3.1 安全性工作的总体规划

安全性工作不是某个阶段单独完成的"附加任务"，而是与飞机研制同步开展、持续迭代的活动。其总体规划遵循以下原则：

  • 早介入：从概念阶段就开始，而不是等到样机出来再补；
  • 全覆盖：从飞机级 → 系统级 → 子系统级 → 部件级，逐层落实；
  • 双向闭环：自顶向下分配需求（设计驱动），自底向上验证符合（证据回传）。

3.2 评估过程的"V 字模型"

这是全书最重要的一张图，请务必记住：

AFHA
飞机级功能危险性评估
SFHA
系统级功能危险性评估
PSSA
初步系统安全性评估
SSA
系统安全性评估

用一句话理解每一步：

  • FHA："如果这个功能坏了会怎样？"——识别危险、分类后果
  • PSSA："我设想的架构能不能满足这些后果对应的概率目标？"——分配需求
  • SSA："最终设计真的达到那些目标了吗？"——验证符合

3.3 安全性需求的四个动作：目标 → 分配 → 确认 → 验证

这是安全性工程中最容易混淆的四个词，请仔细区分：

动作含义示例
目标飞机层面要达到什么概率/严重度水平"双发停车"必须 \(< 10^{-9}\)/FH
分配把整机目标自顶向下分解到系统、子系统、部件每台发动机自身的失效概率应 \(< 10^{-5}\)/FH
确认 Validation检查这个需求"定得对不对"——是否完整、是否正确有没有漏掉某种使用场景？分类有没有偏低？
验证 Verification检查这个需求"做到了没有"——设计是否满足用 FTA/试验证明实际概率确实 \(< 10^{-5}\)
🎯 一句话区分确认与验证 确认 = "需求对不对？"    验证 = "设计行不行？"

3.4 研制保证等级 DAL——给"严谨程度"打分

除了概率指标，对于复杂的硬件和软件，还需要用"研制过程的严谨程度"来防止设计错误。这个严谨程度就是 DAL（Development Assurance Level），按对应失效状态严重度分为五级：

DAL 等级对应失效状态研制要求强度
ACatastrophic最严格——评审、测试、覆盖率全部最高
BHazardous非常严格
CMajor严格
DMinor一般
ENSE无特殊要求

为什么需要 DAL？因为概率分析只能覆盖"随机硬件失效"，而软件 bug、设计错误这种"系统性错误"是没有概率的——只能靠过程严谨度来防止。

第4章 功能危险性评估 FHA核心

本章在讲什么？ FHA（Functional Hazard Assessment）是整个安全性评估流程的第一步，它要回答一个简单却重要的问题："如果这个功能没了，飞机会怎样？" 它不关心具体怎么实现，只关心"功能丢了多严重"。FHA 的输出，将成为后续所有工作的基础。

4.1 FHA 要做什么

FHA 的核心任务有四步：

  1. 识别功能：把飞机/系统的所有功能列清楚；
  2. 识别失效状态：每个功能可能怎样"坏"——完全丢失、误动作、部分丢失、延迟……
  3. 分析影响：每种失效状态在不同飞行阶段下对飞机和乘员意味着什么；
  4. 分类定级：依据后果严重度，定为 Catastrophic / Hazardous / Major / Minor / NSE。

关键点在于：FHA 是"功能驱动"而非"设备驱动"。在 FHA 阶段，工程师还不知道这个功能将由哪台计算机、哪根管路实现——他们只问"功能本身丢了行不行"。

4.2 FHA 的两个层次：AFHA 与 SFHA

FHA 不是只做一遍，而是分两个层级：

类型对象开展时机典型功能
AFHA
飞机级		飞机功能概念设计阶段"提供升力"、"控制飞行轨迹"、"为乘员提供可生存环境"
SFHA
系统级		各系统的功能系统功能定义后"提供刹车力"、"显示空速"、"维持座舱压力"

AFHA 的结果会"分解"到各系统，成为各个 SFHA 的输入。两者构成一个"飞机 → 系统"的两层漏斗。

4.3 失效状态的四种典型类型

对每个功能，至少要考虑这四种失效模式，否则容易遗漏：

  • 功能丧失（Loss）：功能完全没了，例如刹车完全失效
  • 误动作（Malfunction）：功能输出了错误的值，例如显示错误的空速
  • 非指令动作（Inadvertent）：没让它动它动了，例如自动收起落架
  • 延迟动作：动作发生但太晚，例如刹车响应慢于预期
⚠️ 易错点 "误动作"往往比"功能丧失"更危险！例如显示丢失，飞行员知道仪表坏了；而显示错误，飞行员可能据此做出致命决策。FHA 必须把这两种情况分开评估。

4.4 FHA 报告应包含什么

  1. 分析对象与边界
  2. 功能清单
  3. 每个功能的失效状态及其在各飞行阶段的影响
  4. 失效状态的分类等级及对应概率目标
  5. 分类的依据、假设和保守度
  6. 派生的安全性需求（对下游设计的输入）
📌 工程示例 功能：起落架放下与锁定
失效状态：在着陆阶段无法将起落架放下并锁定
影响：飞机无法以正常构型着陆，可能机腹擦地，导致人员伤亡
分类：Catastrophic
概率目标：\(< 10^{-9}\)/FH
派生需求：起落架系统应具备主放与应急放的独立通道

第5章 初步系统安全性评估 PSSA核心

本章在讲什么？ FHA 告诉我们"目标是什么"，PSSA 则要回答"我设想的这个系统架构，到底能不能达成这些目标？" 它在系统设计早期、用初步的故障树等工具，反复试算和迭代架构，直到分析结果显示能满足 FHA 提出的全部安全性目标为止。可以把它理解为"用算笔账的方式给架构方案做体检"。

5.1 PSSA 的作用与目的

PSSA 在飞机研制的初步设计阶段开展，主要做三件事：

  1. 校核架构可行性：验证候选架构能不能满足 FHA 的目标，如果不能就反过来改架构（增加冗余、增加监控等）；
  2. 导出下层安全性需求：把整机/系统级的概率目标，分配到具体的子系统、部件、接口；
  3. 分配 DAL 等级：给每个软硬件项目确定研制保证等级。

PSSA 的精髓在于"迭代"——它不是一锤子买卖，而是和系统架构设计来回拉锯，直到方案能"算得过去"。

5.2 PSSA 的输入与输出

输入输出
① FHA 的失效状态及其分类
② 候选系统架构
③ 部件初步可靠性数据
④ 上一级 PSSA 分配下来的需求 		① 初步故障树（FTA）
② 子系统/部件层级的安全性需求
③ 软硬件 DAL 分配
④ 独立性、隔离、冗余要求
⑤ 派生需求（设计约束）

5.3 PSSA 的典型分析过程

取一个失效状态
建立故障树
向下分配概率
识别派生需求
迭代架构

5.4 工程示例：机轮刹车系统的概率分配

FHA 给出"全部刹车功能丧失"的目标：

\[ P_{\text{loss of all braking}} \le 10^{-9}\,/\text{FH} \]

假设设计采用两个独立通道，且二者共因可忽略，则在 PSSA 阶段可建立简化故障树（顶事件 = 通道1失效 AND 通道2失效），按"与门"概率乘法分配：

\[ P_{\text{channel}} \approx \sqrt{10^{-9}} \approx 3.16 \times 10^{-5}\,/\text{FH} \]

这个 \(3.16 \times 10^{-5}\) 就成为每个通道的可靠性指标——下游设计师必须把单通道的失效概率做到这个水平之内。如果发现做不到，就必须改架构，比如改成三通道。

💡 PSSA 的本质 PSSA 就像"项目预算"——飞机有总预算（FHA 目标），PSSA 把预算切给各部门（子系统），让大家"按预算花钱"。如果某个部门怎么都花不够，就得重新分预算或者改方案。

第6章 系统安全性评估 SSA核心

本章在讲什么？ 如果说 PSSA 是"开工前算预算"，那么 SSA（System Safety Assessment）就是"竣工后查账本"。它在系统设计基本完成后开展，用真实的设计数据和成熟的失效率，最终证明"我们这套系统真的满足了所有安全性需求"——这是给适航局方提交的最终证据。

6.1 SSA 的本质：从"目标"到"证据"

SSA 与 PSSA 在方法上相似（都用 FTA、FMEA 等工具），但性质完全不同：

对比项PSSA（初步）SSA（最终）
开展时机设计早期，架构未冻结设计完成、试验完成后
用什么数据估计值、目标值、相似机型经验真实试验数据、成熟可靠性数据
目的导出需求、迭代架构证明需求得到满足
方向自顶向下分配自底向上汇总验证
面向谁内部设计师适航局方审定

6.2 SSA 过程的主要工作

  1. 更新故障树：用最终设计数据重新计算每个顶事件的概率；
  2. 汇总 FMEA / FMES：把所有部件的故障模式分析结果整合，证明没有遗漏的"单点故障"；
  3. 开展共因分析（CCA）：包括特定风险分析、共模分析、区域安全分析，证明"独立通道真的独立"；
  4. 编制符合性矩阵：把每条安全性需求都对应到具体的证据上；
  5. 形成 SSA 报告：作为飞机型号合格审定的核心文件之一。

6.3 SSA 的输出

  • 最终故障树及定量概率分析结果
  • FMEA / FMES 汇总表
  • 共因分析报告（CCA = PRA + ZSA + CMA）
  • 对所有 FHA 失效状态的"需求 → 证据"映射表
  • 剩余风险说明与可接受性论证
⚠️ 容易搞混的地方 PSSA 和 SSA 不是"两份文档"，而是"同一份评估的两个时间点"。PSSA 边设计边算、边算边改；SSA 在设计完成后定稿。两者的故障树结构往往非常相似，但所有数据都从"假设值"换成了"真实值"。

第7章 安全性概率计算分析工具核心

本章在讲什么？ 前面几章一直在说"算概率"，怎么算？本章介绍三种最核心的定量分析工具：故障树分析（FTA）、相关图分析（DD）、马尔可夫分析。它们各有所长，组合使用可以覆盖绝大多数民机系统的安全性建模需求。

7.1 故障树分析 FTA——最常用的工具

FTA 是一种自顶向下、演绎式的分析方法。从一个不希望发生的"顶事件"出发（例如"双发停车"），用逻辑门一层层向下展开，找到所有可能导致它的基本事件组合。

核心元素

  • 顶事件：要避免的失效状态，通常来自 FHA
  • 基本事件：不再展开的最底层故障，通常是部件的随机故障
  • 与门 AND：所有输入事件同时发生，输出才发生（用于建模冗余）
  • 或门 OR：任一输入事件发生，输出就发生（用于建模单点链路）

概率计算公式

独立基本事件经过与门，输出概率为各事件概率乘积：

\[ P_{\text{AND}} = \prod_{i=1}^{n} P_i \]

独立事件经过或门，当各 \(P_i\) 较小时（通常 \(< 0.1\)），可近似为求和：

\[ P_{\text{OR}} \approx \sum_{i=1}^{n} P_i \]

关键概念：最小割集

割集是能让顶事件发生的基本事件组合；最小割集是其中"再去掉任何一个就不成立"的最简组合。最小割集的"阶数"（包含的事件数）非常重要：

  • 1 阶割集：单点故障——这是设计禁忌，必须消除；
  • 2 阶割集：需要两个事件同时发生才能导致顶事件——通常是冗余设计的产物；
  • 更高阶：安全性更好，但也意味着更高的成本和复杂度。

7.2 相关图分析（Dependence Diagram）

相关图本质上是 FTA 的"对偶"表示——它用"成功路径"而非"失效路径"来表达系统结构，类似可靠性框图。它和 FTA 在数学上等价，但在某些情况下（例如系统天然以"通路"形式描述时）更直观。

7.3 马尔可夫分析——处理时序与修复

FTA 有一个隐含假设：所有事件相互独立、不考虑时间。但有些问题它处理不了：

  • 系统有"状态切换"，比如主用→备用→失效
  • 故障可以被修复，故障率与修复率交织
  • 事件之间存在时序依赖——A 必须先于 B

这时就需要马尔可夫模型。它把系统建模为一组"状态"，状态之间用"转移率"连接。任意时刻 \(t\) 的状态概率向量 \(\mathbf{P}(t)\) 满足微分方程：

\[ \frac{d\mathbf{P}(t)}{dt} = \mathbf{P}(t)\,\mathbf{Q} \]

其中 \(\mathbf{Q}\) 是转移率矩阵，对角元素为离开该状态的总速率（取负），非对角元素为状态间的转移率（如故障率 \(\lambda\) 或修复率 \(\mu\)）。

🔧 工程实践中的搭配使用 FTA 处理整体逻辑和大架构；马尔可夫 处理某个带修复或带状态切换的子系统；最后把马尔可夫算出的"等效失效概率"作为基本事件喂给 FTA。这种"FTA + Markov"组合是民机安全性建模的标准做法。

第8章 故障模式及影响分析 FMEA / FMES核心

本章在讲什么？ FTA 是"自顶向下"问"什么会导致这个后果？"，FMEA 则是"自底向上"问"这个部件坏了，会引发什么后果？" 二者方向相反、互为补充。FMEA 是发现"漏掉的失效模式"、确认"没有未识别的单点故障"的最有效手段。

8.1 FMEA 与 FMES 是什么关系

缩写全称作用
FMEAFailure Mode and Effects Analysis对每个部件的每个故障模式逐一分析其影响
FMESFailure Mode and Effects Summary把 FMEA 中"影响相同"的故障模式合并，作为 FTA 的基本事件输入

简言之：FMEA 是细账，FMES 是把细账按"对系统影响"汇总后的总账。

8.2 FMEA 的基本原则

  • 单一故障假设：每次只假设一个部件的一个故障模式发生（多重故障由 FTA 处理）；
  • 穷尽故障模式：每个部件可能的全部故障模式都要考虑，例如电阻的"开路、短路、漂移"三种；
  • 逐级影响：故障影响要分"本级、上一级、最终"三个层次描述。

8.3 FMEA 的分析步骤

  1. 确定分析层级：分析做到部件级还是 LRU 级
  2. 列出部件清单并编码（建立追溯关系）
  3. 识别故障模式：每个部件可能怎么坏
  4. 分析故障原因：磨损、老化、过载、设计缺陷……
  5. 逐级评估影响：本级影响 → 上一级影响 → 飞机级最终影响
  6. 识别检测手段：是否有 BIT、监控、机组指示
  7. 提出补偿措施：冗余、降级模式、机组程序
  8. 记录失效率数据来源：MIL-HDBK-217、FMD-2016、217Plus 等

8.4 FMEA 表格的典型字段

字段说明
部件编号 / 名称追溯标识
功能该部件承担什么功能
故障模式怎么坏的
故障原因为什么坏
本级影响对本部件的影响
上一级影响对子系统/系统的影响
最终影响对飞机/乘员的影响
检测手段能否被检测到
补偿措施冗余、应急程序等
故障率来源数据
严重度对应 FHA 等级
🔄 FTA 与 FMEA 互为补充 FTA 容易遗漏底层故障，FMEA 容易看不到组合后果。两者必须配合：用 FTA 算概率、找架构问题，用 FMEA 验证"没有底层故障被漏掉"。任何安全性评估都不能只做其中一个。

第9章 特定风险分析 PRA了解

本章在讲什么？ 前面分析的失效都是"系统内部坏了"。但飞机还要面对来自外部的、能一次性破坏多个系统的事件——比如发动机叶片飞出来打到油箱，或者鸟撞穿透挡风玻璃。这类事件叫"特定风险（Particular Risk）"，必须单独评估，因为它会让原本"独立"的冗余通道同时失效。

9.1 什么是特定风险

特定风险是指独立于飞机系统失效而存在的外部事件，但它一旦发生，会对飞机多个部位/系统产生共同影响。常见特定风险包括：

  • 发动机非包容性转子失效（UERF, Uncontained Engine Rotor Failure）
  • 机轮及轮胎失效（爆胎碎片击伤周围结构与系统）
  • 鸟撞
  • 雷击
  • HIRF（高强度辐射场）
  • 冰雹、积冰
  • 火灾、液体泄漏

9.2 以发动机非包容性转子失效为例

发动机转子（风扇、压气机、涡轮）以极高转速旋转，一旦叶片或轮盘破裂飞出，能击穿机身、油箱、液压管路、控制电缆。分析步骤大致为：

  1. 定义碎片大小与扩散角（局方有规定的"1/3 圆盘碎片"和"小碎片"模型）；
  2. 从每台发动机出发，画出碎片可能击中的"散布锥"区域；
  3. 识别落入散布锥的所有关键设备/线路；
  4. 分析这些设备同时被击中后，飞机能否继续安全飞行；
  5. 必要时调整设备布置或加装防护板。

9.3 鸟撞与轮胎爆破分析

类似地，鸟撞分析关注挡风玻璃、机翼前缘、发动机进气道等部位是否能承受规定能量的鸟体撞击；轮胎爆破分析关注高速滑跑/起飞时爆破碎片对机轮舱周围结构的影响。这些分析都属于"外部事件 → 多系统共影响"的研究。

第10章 区域安全性分析 ZSA了解

本章在讲什么？ 前面所有分析基本上都是在"系统/功能"维度，但"安装"本身也可能成为隐患——比如两根本应隔离的液压管走得太近，一根破了另一根也跟着受损。ZSA（Zonal Safety Analysis）就是按飞机的物理区域逐一巡检，确保没有这种"安装级隐患"。

10.1 ZSA 的核心思想

ZSA 把飞机按物理区域划分（例如机鼻舱、电子设备舱、机翼前缘、发动机吊舱、起落架舱等），对每个区域内安装的所有设备、线路、管路进行"邻居关系"检查。

10.2 主要检查内容

  • 隔离与保护：液压管路与电缆、燃油管路与点火源是否充分分离；
  • 泄漏路径：液压油/燃油如果泄漏，会不会流到电气接线盒或高温部件上；
  • 磨损与振动：管路、线束在振动环境中是否会与结构件相互磨损；
  • 火灾扩散：一处起火能否被防火墙阻隔；
  • 维修可达性：是否易导致维护错误（例如装反、漏装）。

10.3 ZSA 的输入与输出

输入：飞机三维数模、安装图、各系统设备清单、相邻设备间隙数据。
输出：每个区域的检查清单与不符合项，以及对应的设计改进建议。

ZSA 是"图纸级"的检查，它依赖于详细的安装设计已经完成，因此通常在 SSA 阶段开展。

第11章 共模分析 CMA了解

本章在讲什么？ 冗余设计的前提是"各通道相互独立"。但如果两个通道用了同一个软件、同一批次的硬件、放在同一个机舱里，那么"独立"就只是名义上的——一个软件 bug 可能让两个通道同时崩溃。共模分析（Common Mode Analysis）就是识别这些"假独立"的工作。

11.1 共模故障是什么

共模故障（Common Mode Failure, CMF）指由共同原因引起的、使多个理应独立的部件同时失效的事件。它直接破坏冗余的有效性——FTA 中 \(P_{\text{AND}} = P_1 \times P_2\) 的乘法假设建立在独立性之上，而共模会让这个假设崩塌。

11.2 共模故障的常见来源

  • 共同设计错误：相同的软件或硬件设计 bug；
  • 共同制造缺陷：来自同一批次的部件存在相同瑕疵；
  • 共同环境影响：高温、振动、EMI、湿气同时作用于多个部件；
  • 共同维护错误：同一名维护人员对所有冗余通道犯了同样错误；
  • 共同电源/信号源：冗余通道共用上游电源或时钟。

11.3 共模分析要做什么

  1. 识别系统中所有"声明独立"的通道；
  2. 对每对独立通道，列出它们之间所有可能的共同点（设计、硬件、软件、安装、环境、维护、电源…）；
  3. 判断这些共同点是否会导致同时失效；
  4. 对存在共模风险的部分提出隔离/差异化措施（如硬件不同型号、软件不同算法、物理隔离、不同维护人员）。

共模分析与特定风险分析（PRA）、区域安全性分析（ZSA）合称共因分析（CCA, Common Cause Analysis），是 SSA 的必备组成部分。

第12章 与系统安全性相关的其他内容概览

本章在讲什么？ 安全性评估的产物不仅仅是分析报告，它还会向外延伸出几项必须随飞机一起交付的工程文件——告诉机务"必须做哪些维护"、告诉航空公司"哪些设备坏了还能放行"、告诉电气工程师"线束本身也是个系统"。本章把这些"外延产物"集中介绍。

12.1 候选审定维修要求 CMR

CMR（Candidate Certification Maintenance Requirements）是指：通过安全性分析识别出的、必须强制执行的维修任务。如果不做这些任务，飞机的安全性就无法维持。

典型场景：某个故障是"潜在故障"（即不做维护就无法被发现），如果不定期检查，它会和另一个故障组合形成灾难性后果。这种检查任务就必须固化为 CMR，写入飞机维护方案。

12.2 主最低设备清单 MMEL

MMEL（Master Minimum Equipment List）规定：飞机上哪些设备失效后，仍允许飞机放行起飞，以及在什么条件下放行。它是航空公司日常运行不可或缺的依据。

MMEL 的制定来自安全性评估的结果：只有那些"在该设备失效情况下仍能保持可接受安全水平"的项目，才能进入 MMEL。

12.3 电气线路互联系统 EWIS

EWIS（Electrical Wiring Interconnection System）把飞机上所有电气线路、连接器、绑扎件视为一个独立系统，对它单独开展安全性分析。原因是历史上多起空难（如 TWA800、瑞士航空 111）都源于线束老化、磨损、绝缘失效引发的火灾，而传统分析中线束往往被忽视。

EWIS 分析关注：线束老化、磨损、污染、过热、电弧故障的概率与影响，以及防火与隔离要求。

第13章 安全性工作管理与规划概览

本章在讲什么？ 前面 12 章都在讲"怎么做技术"，本章讲"怎么管这件事"。再好的技术，如果组织混乱、节点滞后、文件缺失，最终也无法形成可向局方提交的合规证据。安全性工程本质上是一场大规模、长周期、多专业协同的项目管理实践。

13.1 安全性工作管理的要素

  • 组织：成立独立的安全性工作组，与设计、试验、制造、客服各部门接口；
  • 计划：制定《安全性工作计划 SPP》，明确范围、方法、节点、资源；
  • 评审：在每个研制阶段（PDR/CDR/TRR/TC）开展安全性评审；
  • 变更控制：任何设计变更都要回溯评估其对安全性分析的影响；
  • 风险管理：识别、跟踪、闭环所有"安全性相关问题项 SCI"。

13.2 安全性文件体系

典型的安全性文件包括：

  • 安全性工作计划（SPP）
  • FHA 报告（AFHA + SFHA）
  • PSSA 报告
  • SSA 报告
  • CCA 报告（PRA + ZSA + CMA）
  • FMEA / FMES 表
  • CMR 清单
  • MMEL 提案
  • 符合性矩阵（Compliance Matrix）

13.3 安全性活动与型号研制节点的对应

研制阶段关键安全性活动
概念阶段启动 AFHA
初步设计 (PDR)完成 AFHA、启动 SFHA、开展 PSSA 初稿
详细设计 (CDR)SFHA 完成、PSSA 完成、启动 SSA
试验试飞SSA 数据更新、CCA 完成、CMR/MMEL 提案
型号合格审定 (TC)SSA 终版、符合性矩阵交付局方
持续适航跟踪在役故障、闭环改进
⚠️ 一个朴素而重要的观点 安全性不是设计完成后再补的"作业"，必须从概念阶段就开始、与设计并行迭代。否则到了 SSA 阶段才发现架构不满足目标，整个系统返工的代价是天文数字。

📖 全书脉络与学习建议

本书虽然章节众多，但本质上围绕一条主线和一组工具展开：

主线（必须掌握）

FHA
识别危险
PSSA
分配需求
SSA
验证符合

支撑工具（必须熟练）

  • FTA：自顶向下，找原因
  • FMEA：自底向上，看后果
  • Markov：处理时序与修复
  • CCA（PRA/ZSA/CMA）：处理共因与外部威胁

建议学习顺序

  1. 第 1~3 章打基础：术语、规章、整体框架——必须先吃透；
  2. 第 4~6 章抓主线：FHA → PSSA → SSA 是"灵魂三部曲"；
  3. 第 7、8 章练工具：FTA 和 FMEA 必须能动手算；
  4. 第 9~12 章补专题：CCA 三件套和 EWIS、CMR、MMEL；
  5. 第 13 章学管理：理解技术之外的工程组织与文件体系。
学完本书后，你应当能够回答：给我一个新的飞机系统，我能不能从头到尾走完一遍 FHA→PSSA→SSA，并向局方提交符合 25.1309 的证据？