3、危害识别（Hazard Identification）：系统级危害的识别方法与头脑风暴技巧
好，咱们进入HARA分析中最关键的一步——危害识别。
说实话，很多工程师觉得这一步就是开个会，大家坐在一起 brainstorm 一下，把能想到的故障都列出来就完事了。嗯，我以前也这么干过，结果呢？项目后期发现漏了好几个关键危害，被迫返工，那滋味可不好受。
危害识别不是瞎猜，它是有章可循的。今天我就把我在多个项目里摸爬滚打总结出来的方法，掰开了揉碎了讲给你听。
3.1 什么是系统级危害？
先搞清楚概念。系统级危害，指的是在整车层面，由于系统功能异常或失效，导致的人员伤害或财产损失。
注意关键词：「整车层面」。你设计的是转向系统，但危害不是「转向电机卡死」，而是「车辆无法转向导致碰撞」。前者是故障，后者才是危害。
我见过不少新手，把故障和危害混为一谈。比如写「ECU死机」——这是故障，不是危害。危害应该是「ECU死机导致制动灯不亮，引发后车追尾」。明白了吗？
核心原则：危害必须描述「什么功能失效 → 导致什么后果 → 对谁造成伤害」。
3.2 危害识别的输入条件
动手之前，先准备好弹药。我个人习惯，至少需要以下三样东西：
- 功能清单：系统有哪些功能？每个功能的正常行为和异常行为是什么？
- 系统边界图：系统与外部环境、其他系统的交互接口。说白了，谁给谁发了什么信号，谁又依赖谁。
- 运行场景与操作模式：车辆在什么工况下运行？高速、低速、停车、充电？驾驶员在做什么操作？
有一次我在做ADAS项目，团队漏掉了「隧道内GPS信号丢失」这个场景，结果危害识别时根本没考虑到定位失效的风险。后来测试发现了，才补上。所以，场景清单一定要拉全。
3.3 头脑风暴的正确打开方式
很多人觉得头脑风暴就是「大家随便说」。其实不是。我建议按以下流程走：
3.3.1 组建跨职能团队
别只拉功能安全工程师。你需要：
- 系统工程师（最懂功能）
- 硬件工程师（知道哪些器件会坏）
- 软件工程师（了解逻辑漏洞）
- 测试工程师（见过各种奇葩故障）
- 安全专家（从事故中提炼经验）
我记得有一次，硬件工程师随口说了一句「这个电源芯片有过压保护，但恢复时间不确定」，结果就引出了一个「电源恢复期间MCU误动作」的危害。你看，一个人想破头也想不到。
3.3.2 使用结构化引导方法
光靠发散思维效率太低。我常用的结构化方法有：
| 方法 | 说明 | 适用场景 |
|---|---|---|
| 功能失效分析 | 对每个功能，问「如果这个功能失效了会怎样？」 | 所有系统 |
| 接口失效分析 | 对每个系统接口，问「如果这个信号错了/丢了/延迟了会怎样？」 | 通信密集型系统 |
| 场景驱动法 | 列出所有运行场景，逐个分析每个场景下的失效后果 | 自动驾驶、ADAS |
| 历史事故复盘 | 从已知的事故数据库（如NHTSA、ISO 26262案例库）中提取类似危害 | 成熟系统 |
你想想看，如果只用一种方法，很容易漏掉。我一般先用功能失效分析打底，再用场景驱动法查漏补缺。
3.3.3 引导问题的设计
头脑风暴时，主持人要会提问。别问「还有什么危害吗？」这种开放式问题，太虚了。要问具体的：
- 「如果这个传感器输出值比真实值大20%，会怎样？」
- 「如果这条CAN总线连续丢包3秒，会怎样？」
- 「如果驾驶员在高速上突然关闭了系统，会怎样？」
我曾经带过一个团队，大家一开始很沉默。后来我换了个问法：「假设你是黑客，你想让这个系统出人命，你会怎么攻击它？」好家伙，一下子炸开了锅，半小时列了20多个危害。
3.4 危害识别的输出
头脑风暴结束后，你需要整理出危害清单。每个危害至少包含：
- 危害ID：唯一编号
- 危害描述：清晰、无歧义
- 相关功能：哪个功能失效导致的
- 运行场景：在什么情况下发生
- 潜在后果：对人员、车辆、环境的影响
小技巧：我习惯在危害描述里加上「导致」两个字。比如「制动助力失效导致制动距离增加，引发碰撞」。这样能强迫你把因果关系写清楚。
3.5 避坑指南
我曾经踩过的坑，你千万别再踩：
- 别把危害写得太笼统：比如「系统失效导致事故」——这等于没写。要具体到「什么失效、什么场景、什么后果」。
- 别忽略组合失效：两个独立故障同时发生，可能产生新的危害。比如「传感器A失效 + 传感器B也失效」，这种组合危害很容易被漏掉。
- 别只考虑单一故障：ISO 26262要求考虑单点故障，但实际项目中，多点故障也时有发生。至少要在头脑风暴时提一下。
- 别让一个人写所有危害：我见过一个项目，安全工程师自己闷头写了三天，结果评审时被系统工程师怼得体无完肤。一定要团队协作。
3.6 实战案例：电动助力转向系统（EPS）的危害识别
光说不练假把式。咱们拿EPS系统举个例子。
假设功能是「根据方向盘转角，提供助力扭矩」。我们开始头脑风暴：
- 功能失效分析：如果助力扭矩突然消失 → 方向盘变重 → 驾驶员无法转向 → 碰撞
- 接口失效分析：如果转角传感器信号丢失 → 助力扭矩计算错误 → 方向盘自动转向 → 车辆偏离车道
- 场景驱动法：在高速上，如果EPS误判车速 → 提供过大助力 → 方向盘过于灵敏 → 驾驶员误操作
- 历史事故复盘：曾经有案例，EPS控制器的电源线松动 → 助力时有时无 → 驾驶员恐慌
你看，同一个系统，用不同方法能挖出不同角度的危害。这就是结构化思维的价值。
3.7 小结
危害识别是整个HARA的基石。这一步做扎实了，后面的安全目标定义、ASIL等级评定才有意义。
我个人建议，每次做完危害识别，留出半天时间做一次「反向验证」——假设你列出的危害都不存在，再想想有没有遗漏。这招虽然笨，但很管用。
下一章，咱们聊聊如何把这些危害转化成安全目标。到时候你会发现，危害识别做得越细，安全目标定义就越轻松。