2. 危害识别：如何识别车辆级危害？功能故障与危害的关系
好，咱们进入正题。危害识别这一步，说白了就是回答一个问题：这辆车如果出了毛病，会怎么伤害人？
我刚开始做HARA的时候，总觉得这步很简单。不就是把功能列出来，然后想想它坏了会怎样吗？后来发现，没那么简单。你想想看，一个功能故障可能引发多种危害，而同一个危害也可能由不同的故障导致。这里面的门道，咱们今天好好捋一捋。
2.1 什么是车辆级危害？
车辆级危害，指的是在整车层面，由于某个功能发生故障，导致车辆出现危险状态，最终可能对人员造成伤害的场景。
注意关键词：整车层面。我们不是在分析某个芯片坏了会怎样，也不是分析某段代码跑飞了会怎样。我们要看的是，这些底层的问题最终在车辆行驶中表现为什么样的危险行为。
举个例子：
- 不是「制动踏板位置传感器失效」—— 这是系统级故障
- 而是「车辆在行驶中无法按驾驶员意图减速」—— 这是车辆级危害
我个人习惯把车辆级危害归纳为几大类，这样分析时不容易遗漏：
| 危害类别 | 典型表现 | 示例 |
|---|---|---|
| 非预期加速 | 车辆自行加速，或加速超出驾驶员预期 | 自适应巡航系统误判前车距离，突然急加速 |
| 非预期减速 | 车辆自行制动，或制动不足 | 自动紧急制动系统在无危险时误触发 |
| 非预期转向 | 车辆偏离预期行驶轨迹 | 车道保持系统在弯道中错误地反向打方向 |
| 非预期动力中断 | 行驶中突然失去动力 | 电池管理系统误判故障，切断高压输出 |
| 信息误导 | 向驾驶员提供错误的关键信息 | 剩余续航里程显示100km，实际只有20km |
核心要点：车辆级危害必须描述为「车辆在某个场景下表现出的危险行为」，而不是「某个零件坏了」。这是新手最容易犯的错误。
2.2 功能故障与危害的关系
这里有个关键问题：功能故障和危害之间，到底是什么关系？
我打个比方你就明白了。功能故障是「病因」，危害是「症状」。同一个病因可能表现出不同的症状，而同一个症状也可能由不同的病因引起。
具体来说，它们之间的关系可以用一个模型来描述：
功能故障 → 系统行为异常 → 车辆危险状态 → 危害事件
咱们拆开来看：
- 功能故障：某个功能没有按设计意图执行。比如「自动紧急制动功能失效」。
- 系统行为异常：故障导致系统表现出非预期的行为。比如「车辆在需要制动时没有制动」。
- 车辆危险状态：系统异常行为在特定场景下形成的危险局面。比如「车辆以当前速度无法避免与前车碰撞」。
- 危害事件：危险状态最终导致人员受伤。比如「追尾前车，导致乘员受伤」。
我在项目中遇到过这样的情况：团队花了两周时间分析「转向灯控制模块失效」这个故障，但始终无法确定危害等级。为什么？因为他们一直在讨论「转向灯不亮」这个故障本身，而没有把它放到具体场景中去。
后来我引导他们思考：转向灯不亮，在什么场景下会真正造成伤害？
- 白天、直行、车流稀少 → 几乎无危害
- 夜间、变道、后方有高速来车 → 严重危害
你看，同一个故障，在不同场景下，危害程度天差地别。所以，危害识别必须结合运行场景。
我的经验：做危害识别时，手里一定要拿着运行场景清单。每分析一个功能故障，就问自己三个问题：
- 这个故障在什么场景下会发生？
- 发生之后，车辆会表现出什么危险行为？
- 这个危险行为最终可能伤到谁？怎么伤？
2.3 危害识别的具体方法
好了，理论讲完了，咱们来点实操的。危害识别到底怎么做？我一般用三步法：
第一步：列出所有功能及其故障模式
先把你分析范围内的所有功能列出来。然后对每个功能，思考它可能以什么方式失效。
常用的故障模式包括：
- 功能丧失（该做的不做）
- 功能误触发（不该做的做了）
- 功能执行错误（做了但做错了）
- 功能时序错误（做早了或做晚了）
- 功能输出超出范围（给的太多或太少）
第二步：分析每个故障导致的车辆级危害
这一步需要把故障模式放到具体的运行场景中，推导出车辆的危险行为。
举个例子，咱们分析「自适应巡航系统」的「功能丧失」故障：
| 故障模式 | 运行场景 | 车辆危险行为 | 车辆级危害 |
|---|---|---|---|
| ACC功能丧失（无法减速） | 高速公路上，前车减速 | 车辆未按预期减速，持续接近前车 | 与前车发生追尾碰撞 |
| ACC功能丧失（无法加速） | 高速公路上，汇入主路 | 车辆无法加速至设定速度，与后方来车速度差过大 | 与后方来车发生侧碰 |
| ACC误触发加速 | 城市拥堵路段，前车静止 | 车辆突然加速撞向前车 | 与前车发生追尾碰撞 |
注意：同一个故障模式，在不同场景下可能产生完全不同的危害。所以一定要把场景描述清楚。我曾经见过一份HARA报告，危害描述写的是「车辆失控」，这种描述太笼统了，根本无法用于后续的安全目标定义。
第三步：确认危害的完整性
这一步容易被忽略，但很重要。你需要确认：
- 是否覆盖了所有相关的运行场景？
- 是否考虑了所有可能受影响的人员（驾驶员、乘客、行人、其他车辆乘员）？
- 是否考虑了不同的危害类型（碰撞、碾压、火灾、电击等）？
我个人习惯在完成初稿后，找一位没参与分析的同事做一次「红队审查」。让他从完全不同的角度来挑战你的分析结果。很多时候，旁观者清，他能发现你遗漏的场景或危害。
2.4 常见误区与避坑指南
做危害识别这么多年，我见过太多人踩坑。这里分享几个最常见的：
误区一：把系统级故障当作车辆级危害
比如写「制动踏板传感器失效」作为危害。这不是危害，这是故障原因。正确的写法应该是「车辆在需要制动时无法提供足够的制动力」。
误区二：危害描述过于笼统
比如写「车辆失控」。失控是什么？是加速失控？转向失控？还是制动失控？不同的失控类型，安全目标和安全措施完全不同。
误区三：遗漏非碰撞类危害
很多人只关注碰撞，忽略了其他类型的危害。比如电动车的高压电击、电池热失控导致的火灾、自动驾驶模式下驾驶员被锁在车外等。
避坑指南：我曾经在一个项目中，团队花了大量时间分析碰撞类危害，结果忽略了「充电过程中电池过热起火」这个危害。后来客户审核时被一票否决，整个HARA重做。从那以后，我每次都会专门列一个「非碰撞危害清单」来查漏补缺。
2.5 小结
危害识别是整个HARA的基石。这一步做不好，后面的安全目标、功能安全概念都是空中楼阁。
记住几个关键点：
- 车辆级危害必须描述为整车层面的危险行为
- 功能故障和危害之间是多对多的关系
- 危害识别必须结合具体的运行场景
- 不要遗漏非碰撞类危害
下一章，咱们聊聊如何对识别出的危害进行严重度评估。那一步也有很多坑等着你。