第二章 危害识别方法论：功能故障与危害的关系、系统边界定义、运行场景与模式分析
各位工程师朋友，欢迎来到HARA分析实战的第二章。上一章我们聊了HARA的基本概念，说白了就是搞清楚「什么东西会要人命」。这一章我们深入一点，讲讲怎么系统性地把危害找出来。
我个人习惯把危害识别比作「排雷」。你不可能拿着探雷器满场乱跑，得先知道雷区在哪、雷长什么样、什么时候会踩上去。这就是我们这章要解决的问题。
2.1 功能故障与危害的关系
很多新手容易把「功能故障」和「危害」混为一谈。我刚开始做HARA时也犯过这个错。其实它们的关系很简单：功能故障是原因，危害是后果。
举个例子：
- 功能故障：制动系统突然失效，踩刹车没反应
- 危害：车辆无法减速，导致追尾或碰撞行人
你看，故障是「系统内部出问题了」，危害是「对外界造成伤害了」。中间还隔着一个关键因素——运行场景。同样的故障，在不同场景下危害程度天差地别。
关键公式：
危害 = 功能故障 + 运行场景 + 人员行为
缺任何一个，都不构成完整的危害分析。
我在项目中遇到过这样一个案例：某款电动车的电池管理系统（BMS）有个故障——SOC估算偏差超过10%。在普通城市道路上，这顶多让车主提前充电，没什么大问题。但如果在高速上，SOC突然从30%跳到5%，司机一慌可能急刹车，后果就严重了。
所以，识别危害时别只盯着故障本身。你得问自己：这个故障在什么情况下会伤人？
2.2 系统边界定义
做HARA之前，第一件事就是画边界。边界不清，分析就是一团浆糊。
我建议用「黑盒思维」来定义系统边界。什么意思？就是先别管内部怎么实现的，只关注：
- 输入是什么？（传感器信号、用户操作、网络数据）
- 输出是什么？（执行器动作、显示信息、通信报文）
- 和谁交互？（其他ECU、驾驶员、环境）
举个例子，一个自适应巡航系统（ACC）的边界定义：
| 边界类型 | 具体内容 |
|---|---|
| 物理边界 | ACC控制器、雷达传感器、制动执行器、人机交互界面 |
| 功能边界 | 车速控制、跟车距离保持、目标选择、驾驶员接管请求 |
| 通信边界 | CAN总线接收车速/转向信号、发送制动/加速请求 |
| 环境边界 | 工作温度-40°C~85°C、雨雾天气、隧道、弯道 |
小技巧：画边界时，我习惯用一张A4纸，左边写「系统包含什么」，右边写「系统不包含什么」。这样能避免分析范围无限扩大。比如ACC不包含「驾驶员疲劳监测」，那就别把疲劳驾驶的危害算到ACC头上。
边界定义还有个重要作用——明确责任。我曾经参与一个项目，制动系统和转向系统之间的交互边界没划清楚，结果HARA分析时两边互相推诿，最后发现有个危害谁都没覆盖到。嗯，从那以后我每次做HARA，第一件事就是拉着相关团队把边界敲死。
2.3 运行场景与模式分析
危害识别最怕什么？最怕漏场景。你想想看，一个功能在99%的场景下都安全，但偏偏在某个极端场景下出问题，那这1%就是致命伤。
运行场景分析，我把它拆成三个维度：
2.3.1 场景要素
- 道路环境：高速、城市、乡村、隧道、桥梁、停车场
- 天气条件：晴天、雨天、雪天、雾天、夜间
- 交通状况：畅通、拥堵、混合交通、行人密集
- 车辆状态：静止、低速、高速、转弯、上下坡
- 驾驶员行为：正常驾驶、分心、疲劳、紧急操作
别小看这些要素。我见过一个案例：某自动紧急制动（AEB）系统在干燥路面上表现完美，但一下雨就频繁误触发。为什么？因为场景分析时漏了「湿滑路面」这个要素。
2.3.2 运行模式
每个系统都有不同的工作模式。拿ACC来说：
- 待机模式：系统开启但未激活，驾驶员完全控制
- 激活模式：系统控制车速和跟车距离
- 超驰模式：驾驶员踩油门或刹车，系统暂时让出控制权
- 故障模式：系统检测到异常，降级或退出
每个模式下的危害都不一样。比如在待机模式下，ACC误激活可能导致意外加速；在激活模式下，ACC突然退出可能导致追尾。
避坑指南：我曾经在分析一个线控转向系统时，只考虑了「正常转向模式」和「故障降级模式」，漏掉了「手动/自动切换模式」。结果在切换过程中，方向盘突然失去助力，差点造成事故。所以，模式切换瞬间往往是危害高发区，一定要重点分析。
2.3.3 场景组合方法
场景要素这么多，怎么组合才不漏？我推荐用场景矩阵：
// 场景矩阵示例（ACC系统）
场景ID | 道路 | 天气 | 交通 | 车速 | 驾驶员
S01 | 高速 | 晴 | 畅通 | 120km/h| 正常
S02 | 高速 | 雨 | 畅通 | 100km/h| 正常
S03 | 城市 | 晴 | 拥堵 | 30km/h | 分心
S04 | 隧道 | 晴 | 混合 | 60km/h | 正常
S05 | 弯道 | 雪 | 稀疏 | 40km/h | 紧张
...每个场景至少覆盖一个「极端条件」。比如高速+雨天、城市+行人密集、隧道+信号遮挡。我个人习惯先列出10-15个典型场景，再从中筛选出最危险的5-8个做详细分析。
为什么这么做？因为HARA不是越细越好。你分析100个场景，每个都蜻蜓点水，不如深挖10个关键场景。记住：危害识别的目标是找到「最坏情况」，不是穷举所有可能。
2.4 实战：从故障到危害的完整链路
最后，我带你走一遍完整的分析流程。假设我们分析的是「电动尾门系统」：
- 定义边界：尾门控制器、电机、位置传感器、防夹传感器、开关按钮
- 识别功能故障：防夹功能失效、电机过速、位置传感器漂移
- 选择运行场景：地下车库（空间狭小）、雨天（地面湿滑）、儿童在场
- 分析危害：尾门关闭时夹伤儿童、尾门意外打开导致物品掉落砸人
- 确定危害等级：根据严重度、暴露率、可控性打分
你看，每一步都环环相扣。漏掉任何一环，分析结果都可能出问题。
好了，这一章就到这里。下一章我们讲危害的严重度、暴露率和可控性评估——也就是怎么给危害「打分」。到时候我会分享一些实际项目中的打分技巧，保证让你少走弯路。