3、危害分析与风险评估（HARA）：从零搭建你的安全防线

好，咱们进入正题。HARA，全称是 Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：车会不会出问题？出问题有多严重？我们该怎么定目标？

我个人习惯把HARA比作「排雷」。你想想看，一辆车上有上百个ECU，每个都可能藏着隐患。不做HARA就开干，那跟闭着眼睛排雷没啥区别。我在项目中遇到过，有些团队上来就写安全目标，结果写到一半发现场景没定义清楚，又回头重来。嗯，这其实挺浪费时间的。

3.1 HARA方法论：核心就三步

HARA的方法论，ISO 26262里讲得很清楚。但我用大白话给你拆解一下，其实就是三步走：

1. 场景定义：车在什么情况下跑？
2. 危害识别：哪个功能出问题会惹祸？
3. 风险评估：这个祸有多大？该定多高的安全等级？

这三步环环相扣。你漏掉任何一步，后面的安全目标就可能跑偏。我曾经见过一个项目，场景定义只考虑了高速路况，结果在城市拥堵场景下，系统误触发导致追尾。你说冤不冤？

3.2 运行场景定义：别小看这一步

运行场景，就是你的ECU在什么「环境」下干活。很多人觉得这很简单，不就是开车嘛。其实不然。

我一般把场景拆成三个维度：

• 车辆状态：静止、低速、高速、倒车、转弯……
• 环境条件：白天/黑夜、晴天/雨天/雪天、隧道/开阔路……
• 人为因素：驾驶员注意力集中、分心、疲劳……

举个例子。你做一个自动紧急制动（AEB）系统。场景不能只写「前方有障碍物」。你得细化：

• 场景A：高速上，前车急刹，路面干燥，驾驶员注意力集中。
• 场景B：城市道路，行人突然横穿，路面湿滑，驾驶员正在看手机。
• 场景C：隧道内，光线突变，前车静止，驾驶员疲劳。

你看，同一个功能，不同场景下风险等级完全不同。我建议你做一个场景矩阵，把各种组合列出来。别嫌麻烦，这一步省了，后面全是坑。

3.3 危害事件识别：找到那个「万一」

危害事件，就是功能失效后，具体会发生什么不好的事。这里要注意，不是所有失效都叫危害。只有那些直接导致人身伤害的，才算。

我习惯用「失效模式 + 后果」的方式来识别。比如：

功能	失效模式	危害事件
电子助力转向	无助力输出	驾驶员无法转向，车辆偏离车道，碰撞
制动系统	非预期制动	车辆突然减速，后车追尾
油门控制	非预期加速	车辆失控，冲入路口

这里有个容易犯的错：把「系统故障」当成危害事件。比如「ECU死机」不是危害事件，「ECU死机导致制动失效，车辆无法减速」才是。记住，危害事件一定要落到对人的伤害上。

3.4 安全目标定义：给系统画条红线

安全目标，就是针对每个危害事件，你要系统做到什么程度。它是ASIL等级的直接输出。

安全目标的写法有讲究。我总结了一个公式：

「当[触发条件]时，系统应[行为]，以避免[危害事件]。」

举个例子：

• 危害事件：非预期加速导致车辆失控碰撞。
• 安全目标：当检测到非预期加速时，系统应在100ms内切断动力输出，并将车辆减速至安全速度，以避免碰撞。

你看，这个目标里包含了：

• 触发条件（非预期加速）
• 行为（切断动力、减速）
• 时间要求（100ms）
• 最终目的（避免碰撞）

安全目标不能太模糊。比如「系统应安全」这种话，说了等于没说。我建议每个安全目标都要有可验证的指标。比如「响应时间不超过100ms」、「故障容错率达到99.9%」。

3.5 我的实战经验：HARA最容易翻车的三个地方

做了这么多年HARA，我踩过不少坑。挑三个最常见的跟你说说：

1. 场景定义太理想化：只考虑「正常驾驶」，忽略了「极端工况」。比如高温、低温、电磁干扰。这些场景下，电子元件的失效率会显著上升。
2. 危害事件遗漏：只关注了主要功能，忽略了辅助功能。比如一个车窗控制器，你只考虑了升降功能，但没考虑防夹功能失效导致的夹伤风险。
3. 安全目标不可测试：写了一个「系统应足够安全」的目标，结果测试时发现没法验证。我建议每个安全目标都反问一句：「这个目标，我能在台架上测出来吗？」

嗯，说到这，我想起一个项目。当时我们做ADAS系统的HARA，场景定义里漏了「隧道出口强光」这个场景。结果实车测试时，系统在隧道出口误触发了一次紧急制动。还好是测试场地，不然后果不堪设想。从那以后，我每次做HARA都会专门拉一个「边界场景」清单。

好了，HARA的核心内容就这些。下一章我们聊聊怎么把这些安全目标落地到系统架构里。到时候见。