第3章危害分析与风险评估（HARA）

3. 危害分析与风险评估（HARA）：HARA方法论、场景定义与危害识别、风险等级评定（ASIL与SOTIF等级）

各位工程师朋友，咱们今天聊聊HARA。说实话，HARA这个词在功能安全圈里，几乎天天挂在嘴边。但真正能把它做透、做落地的人，其实不多。

我个人的习惯是，把HARA看作整个预期功能安全开发的“地基”。地基没打牢，后面盖再高的楼，心里都不踏实。你想想看，如果连系统在什么场景下会出什么危险都没搞清楚，那后续的安全措施、验证测试，不就成了无的放矢吗？

好，咱们直接进入正题。HARA的核心就三件事：场景定义、危害识别、风险评级。咱们一个一个来拆。

很多团队刚开始做HARA，容易陷入一个误区：几个人围在一起，凭经验“拍脑袋”想几个危险场景，然后就开始定ASIL等级。嗯，这里要注意，这种做法在简单系统上可能蒙混过关，但遇到复杂的自动驾驶系统，绝对会漏掉关键场景。

我建议采用“场景-功能-失效”的三层结构化分析方法。说白了，就是先定义系统会在什么场景下运行，再分析这些场景下系统要实现什么功能，最后才看功能失效会带来什么危害。

举个例子，一个自动紧急制动（AEB）系统：

这样一层层剥开，逻辑就清晰多了。我在项目中遇到过，有些团队直接跳到“失效”层面，结果讨论了半天，发现大家说的根本不是同一个场景，白白浪费了时间。

我的小技巧：做HARA之前，先花半天时间把系统的运行设计域（ODD）定义清楚。ODD越清晰，HARA的边界就越明确，后续的评审也会顺畅很多。

场景定义是HARA里最容易被低估的一步。很多人觉得场景嘛，不就是“白天、晴天、直路”吗？其实远不止这些。

我个人习惯把场景拆成静态场景和动态场景两个维度：

维度	要素	举例
静态场景	道路结构、基础设施、环境条件	高速公路、隧道、雨雪天气、夜间无照明
动态场景	自车状态、交通参与者行为、交互关系	自车速度、前车切入、行人横穿、V2V通信延迟

为什么要分这么细？因为同一个危害，在不同场景下的严重程度可能天差地别。比如“制动失效”这个危害，在空旷的直路上可能只是小剐蹭，但在繁忙的十字路口，可能就是致命事故。

我曾经在一个项目中，因为忽略了“隧道出口处的强光切换”这个场景，导致摄像头在出隧道瞬间出现短暂盲区，差点酿成事故。从那以后，我对场景定义的颗粒度要求就变得非常苛刻。

危害识别，说白了就是找出系统在哪些情况下会“不听话”。但这里的“不听话”不是指硬件坏了，而是指系统在自身设计范围内，因为感知、决策或执行的局限性，产生了不安全的行为。

我常用的方法是HAZOP（危险与可操作性分析）的变体，结合系统的功能架构来逐层扫描。具体来说，就是针对每个功能模块，问几个关键问题：

举个例子，一个L2级车道保持系统：

你看，这个危害不是硬件故障，而是感知算法在特定场景下的局限性。这就是预期功能安全要管的事。

避坑指南：我曾经见过一个团队，把“传感器被泥巴遮挡”也当作预期功能安全的危害来分析。其实这属于功能安全（硬件随机失效）的范畴。一定要分清“系统能力不足”和“系统部件损坏”，否则HARA会变得又臭又长，还没重点。

风险等级评定，是HARA的最终输出。这里有两个体系需要搞清楚：ASIL（汽车安全完整性等级）和SOTIF等级。

ASIL大家比较熟悉，它基于三个参数：严重度（S）、暴露概率（E）、可控性（C）。最终组合成QM、ASIL A、B、C、D四个等级。ASIL D最高，要求最严苛。

但SOTIF等级呢？它其实是对ASIL的一个补充。因为ASIL主要针对系统故障，而SOTIF要管的是系统在无故障情况下的功能不足。SOTIF等级通常用AC（接受准则）来表示，分为：

我个人的经验是，对于L3级以上的自动驾驶系统，SOTIF等级的评定往往比ASIL更关键。因为很多危险场景，系统本身并没有坏，只是“不够聪明”。

举个例子，一个自动变道系统：

你看，同一个功能，两种视角，缺一不可。

为了让大家更直观地理解HARA的整体逻辑，我画了一张图。这张图是我自己项目里常用的框架，你可以直接拿去用。

这张图的核心思想是：HARA不是一次性的活动，而是一个迭代的过程。随着系统设计的深入，你可能会发现新的场景、新的危害，需要回过头来重新评估风险等级。别怕麻烦，这是正常的。

  总结一下：HARA做得好不好，直接决定了后续安全开发的成败。我的建议是，宁可前期多花时间把场景定义透、危害识别全，也不要后期在测试阶段才发现漏了关键场景。到那时候，改设计的成本可就高了去了。