3、风险评估矩阵：严重度等级、发生概率等级、风险可接受准则
好，咱们接着聊风险评估矩阵。这东西说白了，就是一张把「后果多严重」和「发生多频繁」组合起来的表格。我刚开始做飞控那会儿，觉得这玩意儿就是个形式主义，填个表交差完事。后来有一次，一个不起眼的「轻微」风险，差点让试飞员弹射跳伞……嗯，从那以后，我再也不敢小看这张表了。
3.1 严重度等级——到底有多疼？
严重度，就是故障发生后，对飞机、人员、任务造成的伤害程度。我个人习惯把它分成四个等级，这样既够用，又不会太细碎。
| 等级 | 描述 | 后果示例 |
|---|---|---|
| Ⅰ（灾难性） | 机毁人亡 | 飞控完全失控，飞机坠毁 |
| Ⅱ（危险的） | 严重受伤或飞机严重损坏 | 舵面卡死，飞行员需紧急迫降 |
| Ⅲ（主要的） | 人员轻伤或飞机轻度损坏 | 传感器漂移，自动驾驶断开 |
| Ⅳ（轻微的） | 不影响安全，但影响任务 | 某个指示灯不亮，但功能正常 |
我的经验： 定级时别光看「最坏情况」。我曾经见过一个团队，把所有故障都定成「灾难性」，结果评审时被专家怼得哑口无言。你得结合飞行阶段、环境条件来综合判断。比如，同样一个传感器失效，在地面滑行时是「轻微」，在起飞爬升时可能就是「危险」。
3.2 发生概率等级——它到底会不会来？
概率这东西，说实话，飞控系统里很难精确量化。你想想看，一个软件bug，你怎么算它的概率？所以，我们通常用定性的描述来替代。
我常用的分级是这样的：
- 频繁（Frequent）：很可能发生，比如每飞行小时发生一次以上。
- 可能（Probable）：会发生几次，比如每100飞行小时发生一次。
- 偶然（Occasional）：有时会发生，比如每1000飞行小时发生一次。
- 极少（Remote）：不太可能发生，但理论上存在。
- 不可能（Improbable）：几乎不会发生，但别写「绝对不会」。
避坑指南： 我曾经犯过一个错——把「极少」和「不可能」混为一谈。结果适航审查时，局方问我：「你这个『不可能』的概率依据是什么？」我当场就懵了。记住，DO-178C里对「不可能」有严格的定义，需要定量分析来支撑，不是拍脑袋就能写的。
3.3 风险可接受准则——什么能忍，什么不能忍？
有了严重度和概率，咱们就能画矩阵了。说白了，就是把两个维度组合起来，看看哪些风险是「绿灯」，哪些是「红灯」。
我一般用3×3的矩阵，简单明了：
| 严重度\概率 | 频繁 | 可能 | 偶然 | 极少 | 不可能 |
|---|---|---|---|---|---|
| Ⅰ（灾难性） | 不可接受 | 不可接受 | 不可接受 | 需评审 | 可接受 |
| Ⅱ（危险的） | 不可接受 | 不可接受 | 需评审 | 可接受 | 可接受 |
| Ⅲ（主要的） | 不可接受 | 需评审 | 可接受 | 可接受 | 可接受 |
| Ⅳ（轻微的） | 需评审 | 可接受 | 可接受 | 可接受 | 可接受 |
核心原则： 灾难性风险，哪怕概率再低，也得「需评审」甚至「不可接受」。这是底线，没得商量。我见过有人为了赶进度，把「灾难性+极少」直接标成「可接受」，结果被安全评审会直接打回。记住，安全不是儿戏。
3.4 知识体系结构图
下面这张图，是我自己梳理的风险评估核心逻辑。你看一眼，基本就能把整个流程串起来。
3.5 实际应用中的小技巧
最后，分享几个我在项目中踩过的坑，希望能帮你少走弯路：
- 别把矩阵当终点：矩阵只是筛选工具，不是最终结论。对于「需评审」的风险，你得继续做FTA、FMEA等深入分析。
- 概率别拍脑袋：我见过有人写「不可能」，结果问起来就说「我觉得不会发生」。这不行。你得有数据支撑，比如历史故障数据、相似系统的经验数据。
- 严重度要动态看：同一个故障，在不同飞行阶段、不同环境条件下，严重度可能完全不同。我建议你在矩阵里加一列「适用条件」。
- 评审要留记录：每次风险评审的结论、依据、参会人员，都得记下来。这不仅是合规要求，更是以后出了问题追根溯源的关键。
我的习惯： 每次做完风险评估，我都会把「不可接受」和「需评审」的风险项单独列出来，贴在工位上。每天看一眼，提醒自己还有哪些「定时炸弹」没拆掉。这招虽然土，但真的管用。
好了，关于风险评估矩阵，咱们就聊到这儿。记住，这张表不是用来应付审查的，它是你保护飞行员、保护飞机、保护自己的第一道防线。认真对待它，它也会认真对待你。
公众号:蓝海资料掘金营，微信deep3321