3. 危害识别：系统级危害的识别方法
危害识别，说白了就是回答一个问题：“这辆车在什么情况下会出大事？”
我刚开始做功能安全那会儿，总觉得这步很简单——不就是把能想到的故障列出来吗？后来在一个线控制动项目上吃了亏，才明白：你漏掉的那个危害，往往就是最致命的那一个。
今天咱们就聊聊，怎么系统地把危害找出来。我习惯把方法分成两类：头脑风暴法和检查表法。两者不冲突，反而应该搭配着用。
3.1 头脑风暴法：让团队“吵”出危害
头脑风暴不是一群人瞎聊。它有一套规矩，我总结成四个字：广、深、记、判。
| 阶段 | 做什么 | 我的经验 |
|---|---|---|
| 广 | 先发散，不设限。任何“如果……会怎样”都记下来 | 别急着否定，哪怕听起来很蠢的想法，也可能引出真问题 |
| 深 | 针对每个场景追问“然后呢？”直到触达系统边界 | 我习惯追问至少3层，很多危害藏在第二层之后 |
| 记 | 指定专人记录，不遗漏任何一条 | 录音+白板拍照，回头整理时经常发现遗漏 |
| 判 | 会后筛选、归类、合并重复项 | 当场不评判，否则发散效果会大打折扣 |
我的小技巧： 每次头脑风暴前，我会先给团队看一段“事故场景视频”或“危险驾驶片段”。这能快速把大家拉进同一个语境里，避免天马行空到跟系统无关的方向。
3.2 检查表法：用清单堵住漏洞
头脑风暴靠创意，检查表靠经验。说白了，就是把前人踩过的坑整理成清单，一条一条过。
我参与过几个OEM的项目，每家都有自己的检查表。但核心维度差不多，我整理了一个通用版：
| 检查维度 | 典型问题示例 | 关注点 |
|---|---|---|
| 功能异常 | 该加速时没加速？该刹车时没刹车？ | 功能缺失/错误/非预期激活 |
| 信号故障 | 传感器数据跳变？通信中断？ | 信号卡死/超时/乱序/超范围 |
| 外部环境 | 雨雪天、隧道、强光、电磁干扰 | 环境因素对感知和执行的干扰 |
| 人为误用 | 驾驶员误操作、维修人员接错线 | 可预见的误用场景 |
| 系统交互 | 多个功能同时激活时冲突？ | 功能间耦合与资源竞争 |
注意： 检查表不是万能的。它只能覆盖已知风险，对于全新架构或创新功能，必须结合头脑风暴。我曾经在一个L3级自动驾驶项目上，检查表只覆盖了60%的危害，剩下40%全靠头脑风暴补上。
3.3 两种方法怎么搭配？
我推荐一个“三明治”流程：
- 先用检查表快速过一遍，把已知危害先列出来，给团队建立基线。
- 再用头脑风暴深挖，针对检查表没覆盖的“灰色地带”重点讨论。
- 最后用检查表复查，确保头脑风暴产出的新危害，没有遗漏已知维度。
这样做的好处是：既有广度，又有深度。
3.4 危害识别实战：以电动助力转向系统为例
咱们拿一个具体的系统练练手——电动助力转向系统（EPS）。
假设场景：车辆以80km/h在高速上行驶，驾驶员需要轻微修正方向。
我带着团队做过一次，下面是部分产出：
| 编号 | 危害描述 | 运行场景 | 识别方法 |
|---|---|---|---|
| H-01 | 转向助力突然丧失，驾驶员需用大力气转动方向盘 | 高速行驶、弯道 | 检查表（功能异常） |
| H-02 | 转向助力非预期增大，导致方向盘突然打偏 | 高速直线行驶 | 头脑风暴 |
| H-03 | 转向角度传感器信号卡死，系统误判驾驶员意图 | 连续弯道 | 检查表（信号故障） |
| H-04 | 电机控制器过热，输出扭矩波动 | 长时间爬坡+高温天气 | 头脑风暴 |
| H-05 | CAN总线通信延迟，转向指令响应滞后 | 高负载工况（多ECU同时通信） | 检查表（系统交互） |
关键点： 同一个危害可能对应多个运行场景。比如“转向助力丧失”，在高速和低速场景下的后果完全不同。所以危害识别时，一定要绑定场景，否则后续ASIL等级评估会失准。
3.5 危害描述的“三要素”
很多新手写危害描述，要么太笼统（“系统故障”），要么太技术（“MOSFET短路”）。我建议用这个模板：
“在[运行场景]下，由于[故障原因]，导致[系统行为]，从而引发[车辆级危害]。”
举个例子：
- ❌ 错误写法：EPS故障
- ✅ 正确写法：在高速直线行驶时，由于扭矩传感器信号异常，导致EPS输出非预期助力，从而引发车辆非预期转向。
你看，这样写，后续做安全目标推导时，因果关系一目了然。
3.6 知识结构图：危害识别全景
下面这张图，是我每次培训必画的。它把整个危害识别的逻辑串起来了：
3.7 避坑指南
最后，分享几个我踩过的坑：
- 别把“故障”当“危害”。故障是内部原因，危害是车辆级后果。比如“传感器短路”是故障，“车辆非预期加速”才是危害。
- 别忽略“复合场景”。比如“高速+雨天+隧道出口”，单一场景下可能无害，组合起来就是致命风险。
- 别只做一次。危害识别不是一次性活动。系统设计变更、新增功能、甚至法规更新，都可能引入新危害。我建议每个项目至少做三轮：概念阶段、系统设计阶段、详细设计阶段。
我的习惯： 每次危害识别会议结束后，我会把清单打印出来贴在工位上。接下来一周，每天路过时扫一眼，经常能发现遗漏的场景。这个方法帮我补过至少3个关键危害。
嗯，危害识别就聊到这儿。记住一句话：找全危害，安全目标才立得住。