3、危害识别方法：功能失效分析，系统边界定义，运行场景与运行模式识别
好，咱们进入正题。危害识别，说白了就是回答三个问题：什么东西会坏？坏在哪儿？什么时候坏？ 这三个问题搞不清楚，后面的安全目标全是空中楼阁。我见过不少项目，HARA 做得像走过场，结果测试阶段发现一堆漏掉的危害，那才叫一个头疼。
3.1 功能失效分析：从“正常”到“不正常”的推演
功能失效分析，不是让你天马行空乱想。它是有套路的。我个人习惯，先列出系统的所有功能，然后逐个问：这个功能如果没了，或者乱来，会怎样？
举个例子，线控制动系统。它的核心功能是“响应制动踏板信号，产生制动力”。那失效模式有哪些？
- 功能丧失：踩了刹车，没反应。这是最直接的。
- 功能过度：轻轻一点，直接抱死。我在项目中遇到过，某次台架测试时，由于软件滤波参数设错了，导致信号放大，差点把台架上的轮胎磨平。
- 功能误报：没踩刹车，它自己刹了。这在高速上非常危险。
- 功能延迟：踩下去半秒才有反应。你想想看，紧急情况下这半秒意味着什么。
核心原则：每个功能至少分析四种失效模式——丧失、过度、误报、延迟。别偷懒，这四板斧能覆盖90%以上的危害。
为什么强调这个？因为很多新手工程师只盯着“功能丧失”看，觉得只要刹车能刹住就行。但实际项目中，“不该动的时候动了”往往比“该动的时候不动”更致命。
3.2 系统边界定义：你的地盘你做主，但别越界
系统边界，就是划清楚“哪些归我管，哪些归别人管”。这步做不好，后面责任全乱套。
我建议用一张表格来定义边界。比如针对“电子稳定程序（ESP）”系统：
| 边界类型 | 包含内容 | 不包含内容（外部接口） |
|---|---|---|
| 物理边界 | ECU、液压单元、轮速传感器、横摆角速度传感器 | 制动管路、制动液、制动卡钳（属于液压制动系统） |
| 功能边界 | 制动力分配、防抱死、牵引力控制、车辆稳定性控制 | 转向控制（属于转向系统）、动力总成控制（属于发动机/电机系统） |
| 信息边界 | 轮速信号、横摆角速度信号、方向盘转角信号 | GPS信号、摄像头信号（属于ADAS系统） |
嗯，这里要注意。边界定义不是越细越好，而是要能支撑后续的危害分析。我曾经在一个项目中，把边界定义到了每个电阻电容，结果分析时发现根本用不上，白白浪费了两周时间。
个人经验：边界定义到“可独立分析的功能模块”即可。比如“轮速传感器模块”是一个边界，“ECU电源管理模块”是另一个边界。别拆到芯片引脚级别，那是硬件设计的事。
3.3 运行场景与运行模式识别：在什么情况下会出事？
这是HARA里最考验经验的一步。同样的失效，在不同场景下，危害等级天差地别。
举个例子，转向助力失效：
- 场景A：车辆静止，原地打方向。危害等级：低。顶多就是费点力气。
- 场景B：高速行驶，120km/h，需要紧急变道。危害等级：极高。没有助力，驾驶员根本掰不动方向盘。
你看，同一个失效，场景不同，结果完全不同。所以，运行场景必须覆盖“最坏情况”。
我个人习惯，把运行场景拆成三个维度来识别：
- 车辆状态：静止、低速、中速、高速、倒车、驻车。
- 环境条件：干燥路面、湿滑路面、冰雪路面、夜间、隧道、弯道。
- 驾驶员行为：正常驾驶、紧急制动、急转弯、巡航、泊车。
至于运行模式，那就更直接了。底盘系统常见的模式有：
- 正常模式：所有功能在线，舒适性优先。
- 运动模式：转向变重，悬架变硬，响应更激进。
- 越野模式：ESP部分关闭，允许车轮打滑。
- 故障模式：某个子系统失效，系统进入降级状态。
避坑指南：我曾经在分析一个线控转向项目时，漏掉了“车辆在冰雪路面、高速行驶、且处于运动模式”这个组合场景。结果在后续的FMEDA中，发现一个共因失效在这个场景下会导致完全失去转向能力。幸亏发现得早，否则后果不堪设想。所以，场景组合别怕多，就怕漏。
最后，总结一下。危害识别不是一次性工作。随着项目推进，你会发现新的场景、新的边界、新的失效模式。所以，保持迭代，保持警惕。这是我在底盘安全领域摸爬滚打这么多年，最深的体会。