第2章 危害识别入门：危害的定义、来源与方法论
各位同学，欢迎来到HARA分析实战课程的第二讲。
上一章我们聊了功能安全的基本概念。今天，咱们正式进入核心——危害识别。
说实话，我见过不少工程师，一上来就急着做风险等级判定。结果呢？危害都没找全，后面的分析全是空中楼阁。所以，这一章咱们把基础打牢。
2.1 危害的定义：到底什么是“危害”？
先问大家一个问题：什么算危害？
ISO 26262里给的定义很严谨——危害是指由系统故障行为导致的、对人员造成的潜在伤害源。
嗯，这句话有点绕。我换个说法：危害 = 系统出了不该出的问题 + 这个问题可能伤到人。
举个例子：
- 刹车踩下去没反应？这是故障。
- 刹车踩下去没反应，导致车停不住、撞了人？这就是危害。
你看，故障和危害的区别就在这里。故障是“系统内部的事”，危害是“系统对外界造成的后果”。
核心要点：
- 危害必须涉及人员伤害（死亡、受伤、健康损害）
- 危害必须源于系统的故障行为
- 危害是潜在的，不是已经发生的
我个人习惯把危害分成三类：
| 危害类型 | 典型例子 |
|---|---|
| 物理伤害 | 碰撞、挤压、切割 |
| 生理伤害 | 电击、灼伤、辐射 |
| 健康损害 | 有毒气体泄漏、长期暴露 |
2.2 危害的来源：三个“罪魁祸首”
危害不会凭空冒出来。我总结下来，危害主要来自三个方向：
2.2.1 系统故障
说白了，就是设计或制造上的缺陷。比如：
- 软件逻辑写错了（比如某个条件判断反了）
- 硬件电路设计有bug（比如上拉电阻选小了）
- 系统架构不合理（比如冗余不够）
我在项目中遇到过一件事：某款ADAS系统的感知算法，在雨天把路面积水误判成了障碍物，结果系统突然急刹车。这就是典型的系统故障导致的危害。
2.2.2 随机硬件故障
这个跟设计没关系，是硬件本身的老化、磨损、随机失效。比如：
- 芯片内部某个晶体管突然短路
- 焊点因为振动开裂
- 电容老化导致电压不稳
你想想看，这些故障你没法完全避免。我们能做的，是通过诊断覆盖率、安全机制来检测或容忍它们。
避坑指南：我曾经犯过一个错误——把随机硬件故障当成系统故障来处理。结果安全机制设计得过于保守，成本翻了一倍。后来才明白：系统故障靠流程和评审来预防，随机硬件故障靠诊断和冗余来应对。两者思路完全不同。
2.2.3 环境因素
这个好理解——外部环境“捣乱”。比如：
- 电磁干扰（EMI）导致传感器误报
- 极端温度让电池性能下降
- 湿气导致电路板漏电
嗯，这里要注意：环境因素本身不是故障，但它诱发了故障。所以做HARA时，一定要考虑“在什么场景下系统会出问题”。
2.3 危害识别的方法论：怎么把危害“挖”出来？
方法很多，我挑三个最常用的讲。
2.3.1 头脑风暴法
最原始，但也最有效。拉上系统、软件、硬件、测试、安全工程师，关起门来聊。
- 每个人从自己的角度提“如果……会怎样？”
- 不批评、不打断、先记录
- 最后归类整理
我建议：头脑风暴时一定要有“场景感”。别光想“系统会出什么故障”，要想“在什么驾驶场景下，这个故障会变成危害”。
2.3.2 检查表法
用现成的检查表来“照单抓药”。比如：
| 检查项 | 典型问题 |
|---|---|
| 动力系统 | 非预期加速？动力丢失？ |
| 制动系统 | 制动失效？制动意外触发？ |
| 转向系统 | 转向卡滞？转向反向？ |
| 人机交互 | 信息误显示？报警遗漏？ |
这个方法的好处是不容易遗漏。但坏处是——太死板，容易漏掉新场景。
2.3.3 功能导向法
我个人最喜欢这个方法。思路是：先列出系统的所有功能，然后对每个功能问“如果这个功能出错了会怎样？”
举个例子：
- 功能：自动紧急制动（AEB）
- 故障1：该制动时不制动 → 危害：追尾
- 故障2：不该制动时制动 → 危害：后车追尾
- 故障3：制动力不足 → 危害：碰撞速度未降低
你看，这样一梳理，危害就清晰多了。
重要提醒：危害识别不是一次性的工作。项目进展过程中，需求变了、设计改了、甚至标准更新了，都要重新审视危害清单。我见过一个项目，前期做了很漂亮的HARA，结果中期改了传感器方案，没人更新危害分析……最后测试阶段才发现漏了一个关键危害。嗯，那场面，挺惨的。
2.4 小结
这一章我们聊了三件事：
- 危害的定义——系统故障行为导致的潜在伤害源
- 危害的来源——系统故障、随机硬件故障、环境因素
- 危害识别的方法——头脑风暴、检查表、功能导向法
下一章，咱们会深入讲危害分析与风险评估（HARA）的完整流程。到时候，我会拿一个真实案例，带大家一步步走一遍。
记住一句话：危害找不全，后面的安全分析全是白费功夫。所以，这一章的内容，值得你反复琢磨。
好，今天就到这里。有问题随时找我。