3. 危害分析与风险评估：功能危害分析（FHA）、初步系统安全评估（PSSA）
好，咱们进入正题。这一章要聊的，是飞控系统安全设计的“地基”——危害分析与风险评估。说白了，就是回答三个问题：“会出什么事？”、“后果多严重？”、“怎么防？”。
我个人习惯，在项目启动阶段，第一件事不是画架构图，而是拉上系统、软件、硬件、甚至试飞员，一起做FHA。为什么？因为后面所有的安全设计，都要从这里找依据。你想想看，如果连“可能摔飞机”的场景都没识别全，后面的PSSA、SSA做得再漂亮，也是空中楼阁。
3.1 功能危害分析（FHA）
FHA，全称Functional Hazard Assessment。它的目标很单纯：识别每个功能失效后，会带来什么危害。
我记得在某型无人机项目中，我们做FHA时，把“飞控计算机掉电”这个失效模式列了出来。当时有人觉得“掉电了飞控肯定失效，这还用分析？”但深入一挖，发现事情没那么简单——掉电后，舵面是卡死还是回中？回中速度多快？这直接决定了飞机是飘降还是直接进入不可控状态。你看，细节都在FHA里。
3.1.1 FHA的输入与输出
| 项目 | 内容 |
|---|---|
| 输入 | 功能清单、系统架构初稿、运行场景（起飞、巡航、着陆、应急） |
| 输出 | 危害清单、严重度等级、安全目标（Safety Objectives） |
FHA的输出，最核心的就是安全目标。比如：“当空速管堵塞时，必须通过备用传感器在2秒内切换至备份模式，且不能导致俯仰失控。” 这就是一条安全目标。它不告诉你具体怎么实现，但告诉你“必须做到什么”。
3.1.2 严重度等级划分
在航空领域，我们通常用SIL（Safety Integrity Level）或者更直接的灾难性、危险、重大、轻微来分级。我习惯用下面这个表，简单粗暴：
| 等级 | 定义 | 举例（飞控系统） |
|---|---|---|
| 灾难性 | 飞机坠毁、多人死亡 | 飞控计算机完全失控，导致飞机进入不可恢复的俯冲 |
| 危险 | 严重受伤、飞机严重损坏 | 舵面卡死，但飞行员通过手动配平勉强着陆 |
| 重大 | 乘客不适、系统降级 | 自动驾驶断开，需要人工接管 |
| 轻微 | 无安全影响，但需维护 | 某个传感器数据跳变，但被表决逻辑滤除 |
3.2 初步系统安全评估（PSSA）
FHA做完，我们手里有了一堆“安全目标”。接下来，PSSA就要上场了。它的任务是：针对每个安全目标，设计出系统架构层面的应对方案。
说白了，FHA是“提出问题”，PSSA是“给出架构级答案”。
3.2.1 PSSA的核心方法
PSSA最常用的方法是故障树分析（FTA）和依赖图。我个人偏爱FTA，因为它能直观地展示“顶事件”是怎么由底层故障组合而成的。
举个例子：顶事件是“飞控计算机失效导致失控”。我们往下分解：
- 主计算机失效
- 备份计算机失效
- 交叉通道数据链路失效
你看，只要这三个同时发生，顶事件就成立。那我们的架构设计就要保证：这三个事件不能同时发生。比如，主备计算机用不同的电源、不同的软件版本、甚至不同的处理器架构。
3.2.2 PSSA的输出
PSSA完成后，你会得到：
- 架构安全要求：比如“必须采用双余度飞控计算机”、“交叉通道比较周期不超过10ms”。
- 故障检测与容错策略：比如“当主通道心跳丢失时，备份通道在50ms内接管”。
- 分配至软硬件的安全需求：比如“空速管加热控制器的失效率必须低于10^-7/飞行小时”。
这些输出，会直接指导后续的详细设计。所以，PSSA做得越细，后面返工越少。
3.3 知识体系与核心逻辑
下面这张图，是我自己总结的FHA与PSSA的关系。你可以把它当作本章的“思维导图”：
3.4 实战中的几点提醒
嗯，到这里，FHA和PSSA的理论框架基本讲完了。但我想再啰嗦几句实战中的体会：
- FHA不要一个人做。 我建议至少拉上系统工程师、软件负责人、硬件负责人、还有测试代表。不同视角能发现不同问题。
- PSSA的故障树要“剪枝”。 别把树画得太深，否则分析工作量会爆炸。一般剪到“可分配至单一软硬件模块”的层级就够了。
- 文档要可追溯。 每个安全目标，都要能追溯到PSSA中的具体故障树分支。否则，审查时你会被问得哑口无言。