3、危害识别与风险分析：HAZOP方法、FMEA方法、FTA方法、风险矩阵与可接受准则
各位同学，咱们今天聊点硬核的。ATO系统要上线，第一步不是写代码，而是把可能出事的场景全挖出来。说白了，就是「找茬」——用系统化的方法，把系统里里外外可能藏着的危险点都翻个底朝天。
我个人习惯，做安全认证时，最怕的就是「我以为没问题」。你想想看，ATO系统一旦出故障，列车可能闯红灯、可能超速、可能车门没对齐就启动。所以，危害识别和风险分析，是整个安全认证流程的基石。今天咱们就掰开揉碎，把HAZOP、FMEA、FTA这几个主流方法，以及风险矩阵怎么用，一次性讲透。
3.1 HAZOP方法：系统级的「头脑风暴」
HAZOP，全称是 Hazard and Operability Study。我最早接触它是在一个信号联锁项目里，当时觉得这方法太啰嗦了，后来才发现——啰嗦才是它的价值。
核心思路是什么？
它把系统拆成一个个「节点」，然后对每个节点施加「引导词」。比如：
- 无（No）：信号没给出来？
- 多（More）：速度指令比实际限速高？
- 少（Less）：制动率不足？
- 反向（Reverse）：列车倒溜？
- 异常（Other than）：非预期的操作模式？
举个例子。在ATO的「速度测量」节点上，我们问：
- 「如果速度传感器无信号，会怎样？」
- 「如果速度值比实际多20%，会怎样？」
- 「如果两个传感器读数不一致，会怎样？」
每个问题都要记录：原因、后果、现有防护措施、建议措施。
重要提示：HAZOP不是一个人能干的活。我建议至少召集5个人：系统工程师、软件工程师、测试工程师、安全工程师、运营代表。大家坐在一起，对着图纸和功能描述，一条一条过。我曾经见过一个项目，因为没叫运营代表，漏掉了「司机误操作紧急制动复位」这个场景，后来在测试中差点出事。
我的小技巧：做HAZOP时，准备一块大白板。每讨论一个节点，就把引导词写在白板上，打勾表示已分析。这样不会漏项，而且大家都能看到进度。
3.2 FMEA方法：组件级的「故障模式排查」
FMEA，Failure Mode and Effects Analysis。如果说HAZOP是「从系统功能往下看」，那FMEA就是「从元器件往上看」。
怎么做？
列出每个组件的每个故障模式，然后分析它对上一级的影响。比如：
| 组件 | 故障模式 | 局部影响 | 系统影响 | 严重度 | 检测手段 |
|---|---|---|---|---|---|
| 速度传感器A | 输出卡死 | 速度值不变 | ATO可能误判列车静止 | 高 | 与传感器B交叉比较 |
| 制动继电器 | 触点粘连 | 制动指令无法撤销 | 列车无法牵引 | 中 | 回读触点状态 |
| 通信板卡 | 数据位翻转 | CRC校验失败 | 通信中断，紧急制动 | 低 | 冗余通道+超时机制 |
嗯，这里要注意。FMEA的表格看起来简单，但真正做起来很考验经验。我刚开始做FMEA时，总喜欢把「严重度」打得很高，觉得这样安全。后来被评审专家怼了：「如果所有故障都是高严重度，那你的系统根本没法用。」
关键点：严重度要结合运营场景来定。比如「通信中断导致紧急制动」，虽然影响大，但属于安全侧故障，严重度反而可以定为「中」。而「速度显示偏低导致超速」，这才是真正的「高」。
避坑指南：我曾经在一个项目里，FMEA做了200多条，结果发现有一半的故障模式根本不可能发生——因为设计上已经用了冗余和自检。所以，做FMEA之前，一定要先搞清楚系统的「固有防护措施」。别把时间浪费在不可能的场景上。
3.3 FTA方法：从事故倒推的「逻辑树」
FTA，Fault Tree Analysis。这个方法跟前面两个正好相反——它是从顶事件（事故）出发，往下找原因。
比如顶事件是「列车越过红灯」。我们问：什么情况会导致这个？
- 要么是「制动系统失效」
- 要么是「速度控制失效」
- 要么是「信号系统误判」
然后每个分支继续往下拆。比如「制动系统失效」又可以分为：
- 「制动指令未发出」
- 「制动指令发出但执行机构卡死」
- 「制动缸压力不足」
这样一层层拆下去，直到拆到基本事件（比如「继电器线圈断路」）。
FTA的好处是什么？
它能帮你算出顶事件发生的概率。只要你知道每个基本事件的失效率，就能用逻辑门（与门、或门）往上算。这在安全完整性等级（SIL）的定量分析中非常有用。
重要提示：FTA的「与门」和「或门」千万别搞混。与门表示所有条件同时发生才会导致上一级事件，概率是相乘；或门表示任意一个条件发生就会导致上一级事件，概率是相加（近似）。我见过有人把冗余系统的两个通道画成或门，结果算出来的失效率比实际高了一个数量级。
我的经验：FTA图不要画得太复杂。一般控制在3-4层就够了。太深了，基本事件的失效率数据根本拿不到，算出来也是白算。而且，评审的时候没人愿意看一张A0纸都画不下的树。
3.4 风险矩阵与可接受准则
好了，危害也识别了，故障模式也分析了，树也画了。然后呢？
然后就是判断——哪些风险可以接受，哪些必须处理。
风险矩阵长什么样？
横轴是「严重度」，纵轴是「发生概率」。比如：
| 概率\严重度 | 轻微 | 中等 | 严重 | 灾难性 |
|---|---|---|---|---|
| 频繁 | 不可接受 | 不可接受 | 不可接受 | 不可接受 |
| 可能 | 可接受 | 不可接受 | 不可接受 | 不可接受 |
| 偶尔 | 可接受 | 可接受 | 不可接受 | 不可接受 |
| 极少 | 可接受 | 可接受 | 可接受 | 不可接受 |
| 不可能 | 可接受 | 可接受 | 可接受 | 可接受 |
你看，左上角是绿色（可接受），右下角是红色（不可接受）。中间那条线，就是「可接受准则」。
可接受准则怎么定？
这不是拍脑袋定的。通常要参考：
- 国家标准（比如EN 50126、IEC 61508）
- 业主的运营要求
- 历史事故数据
- 社会公众的可接受程度
我个人习惯，在项目启动阶段就跟业主把这条线画清楚。否则到了评审阶段，你说「这个风险可接受」，业主说「不行，必须加防护」，那就尴尬了。
避坑指南：我曾经遇到一个项目，风险矩阵的「严重度」定义写得太模糊。比如「列车碰撞」和「乘客轻微擦伤」都算「严重」。结果评审时大家吵了一个小时，就为了争论一个故障到底算「中等」还是「严重」。后来我们重新定义了严重度等级，每个等级都配了具体的场景描述，才解决了这个问题。
最后，总结一下。危害识别与风险分析，不是一次性工作。随着设计深入，你会发现新的危害，也会发现原来的防护措施不够。所以，我建议每完成一个设计迭代，就回头更新一次HAZOP和FMEA。别嫌麻烦，安全这东西，就怕「差不多」。
好了，这一章就到这里。下一章咱们聊聊「安全需求规格」怎么写——那可是把今天分析出来的风险，变成具体设计要求的桥梁。