第3章危害事件定义

3. 危害事件定义：三要素与描述规范

好，咱们进入第三个关键环节——危害事件定义。

说实话，我见过太多HARA分析做到一半，大家吵起来的场景。吵什么呢？就是危害事件到底该怎么写。有人写“刹车失灵”，有人写“车辆失控”，还有人写“驾驶员受伤”。这些都对，但都不完整。

为什么？因为危害事件必须说清楚三件事：什么危害、在什么场景下、系统处于什么状态。缺一个，后面的安全机制设计就没法落地。

3.1 危害事件三要素

我个人习惯把危害事件拆成三个维度来看：

要素	含义	举例
危害	对人员造成的直接伤害	人员受伤、人员死亡
运行场景	车辆在什么环境下运行	高速公路上、雨雪天气、夜间
系统状态	系统处于什么工作模式	ACC激活、自动紧急制动介入

这三者缺一不可。我举个例子你就明白了：

只有危害：“车辆非预期加速”——那是在停车场还是高速上？后果天差地别。
只有场景：“高速公路上”——系统是正常巡航还是正在变道？危害程度完全不同。
只有系统状态：“ACC激活”——但前方有没有车？车速多少？这些都不清楚。

所以，一个完整的危害事件应该是这样的：

正确示例：

“在高速公路上以120km/h巡航时（运行场景），ACC系统因传感器故障导致非预期加速（系统状态），造成车辆追尾，导致人员受伤（危害）。”

你看，这样写出来，安全工程师一看就知道：哦，我需要针对传感器故障设计诊断机制，还要考虑高速场景下的响应时间。

3.2 危害事件描述规范

我在项目中踩过不少坑，后来总结出一套描述规范。说白了，就是“谁 + 在哪儿 + 干什么 + 出了什么事 + 后果如何”。

具体来说，我建议按这个模板来写：

【危害事件描述模板】
在 [运行场景] 下，[系统/功能] 因 [故障/失效模式] 导致 [系统状态异常]，
造成 [具体事故类型]，最终导致 [人员伤害后果]。

举个例子：

模板应用示例：

“在城市交叉路口（运行场景），AEB系统因雷达信号丢失（故障模式）导致自动紧急制动功能未激活（系统状态异常），造成车辆与横穿行人碰撞（事故类型），导致行人重伤（伤害后果）。”

嗯，这里要注意几个细节：

运行场景要具体：别只写“道路上”，要写“城市道路”、“高速公路”、“停车场”等。场景越具体，安全机制设计越有针对性。
系统状态要可观测：别写“系统异常”，要写“系统未响应”、“系统输出错误值”等。这样测试时才能验证。
危害要量化：能写“重伤”就别写“受伤”，能写“死亡”就别写“事故”。ASIL等级评定需要这个。

3.3 常见错误示例

我审过上百份HARA报告，发现新手最容易犯这几个错误。来，咱们一个个看：

错误一：危害事件写成了功能失效

❌ “转向系统失效”

✅ “在高速公路上变道时，转向系统因电机故障导致转向助力丧失，造成车辆偏离车道与邻车碰撞，导致人员受伤”

为什么错？“转向系统失效”只是功能失效，不是危害事件。危害事件必须包含后果——对人有伤害才算危害。

错误二：遗漏运行场景

❌ “制动系统非预期制动导致人员受伤”

✅ “在高速公路上以100km/h行驶时，制动系统因传感器误触发导致非预期制动，造成后车追尾，导致人员受伤”

为什么错？没有场景，你没法判断这个危害的严重度。同样是非预期制动，在停车场和高速上，后果差好几个等级。

错误三：危害描述太笼统

❌ “车辆失控导致事故”

✅ “在湿滑路面上以60km/h转弯时，ESC系统因轮速传感器故障导致车辆侧滑，造成车辆撞击护栏，导致驾驶员受伤”

为什么错？“车辆失控”太模糊了。是转向失控？制动失控？还是动力失控？每种失控对应的安全机制完全不同。

我曾经在一个项目里，看到团队写了30多个“车辆失控”的危害事件。你想想看，这怎么设计安全机制？根本没法下手。后来我让他们全部重写，按三要素拆开，结果发现有一半其实是重复的，真正需要关注的只有十几个。

3.4 我的个人经验

最后分享一个我自己的习惯。每次写完危害事件，我都会问自己三个问题：

这个事件能测试吗？——如果测试工程师看了不知道怎么造场景，那说明描述不够具体。
这个事件能追溯到安全目标吗？——每个危害事件都应该对应一个安全目标，如果对应不上，说明写偏了。
这个事件能指导安全机制设计吗？——如果看完危害事件，脑子里还是不知道要设计什么机制，那说明三要素没写全。

说白了，危害事件定义是整个HARA分析的基石。基石歪了，后面盖的楼都得塌。所以，多花点时间把这一步做扎实，后面会省很多事。

总结一下：

危害事件 = 危害 + 运行场景 + 系统状态
描述模板：在[场景]下，[系统]因[故障]导致[状态异常]，造成[事故]，导致[伤害]
常见错误：写成功效失效、遗漏场景、描述笼统