3. 危害分析与风险评估（HARA）：从场景到ASIL的实战路径

HARA，全称 Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：车在什么情况下会出危险？这个危险有多严重？我们得花多大力气去防？

我刚入行那会儿，觉得HARA就是填表格。后来在某个量产项目里，因为场景定义漏了一个“夜间逆光”工况，导致摄像头识别率在实车测试时直接崩了。嗯，从那以后，我再也不敢小看HARA了。

3.1 HARA方法论：ISO 26262的“风险三要素”

ISO 26262第三部分明确要求：所有功能安全相关项，必须先做HARA。它的核心逻辑是——

风险 = 危害严重性（Severity） × 暴露概率（Exposure） × 可控性（Controllability）

这三个维度，最终拼出一个ASIL等级（A、B、C、D）。D最高，A最低，QM表示“质量管理即可”。

我个人习惯把HARA分成四步走：

1. 定义运行场景 —— 车在哪儿开？什么环境？什么工况？
2. 识别危害事件 —— 系统失效后，会导致什么危险？
3. 评定S、E、C参数 —— 每个危害事件打分。
4. 确定ASIL等级 —— 查ISO 26262-3:2018 Table 1。

你想想看，这四步里最容易出问题的，其实是第一步。场景定义不全，后面全是白搭。

3.2 运行场景定义：别让“漏场景”成为你的噩梦

运行场景，就是你的AI座舱在什么情况下会“干活”。ISO 26262里叫“Operating Situation”。

我建议从三个维度去切：

维度	典型场景举例	常见遗漏点
环境	白天/夜晚、晴天/雨/雪/雾、隧道/地库	逆光、低照度、雨滴遮挡
道路	高速/城市/乡村、直道/弯道/坡道	施工路段、无车道线道路
车辆状态	静止/低速/巡航、变道/转弯/倒车	系统启动瞬间、OTA升级中

举个例子。AI座舱里的“疲劳监测”功能，如果只定义了“驾驶员正常驾驶”场景，那万一驾驶员戴着墨镜、或者侧脸跟后排说话呢？这些场景漏了，ASIL等级再高也白搭。

3.3 危害事件识别：从“功能失效”到“人身伤害”

危害事件，不是“系统坏了”，而是“系统坏了之后，人受伤了”。

比如：

• 功能失效： 驾驶员监控摄像头死机。
• 危害事件： 驾驶员疲劳未被检测，车辆未报警，导致追尾。

这里有个关键点：危害事件必须包含“场景”和“后果”。ISO 26262里叫“Hazardous Event”。

我一般用“If…Then…”句式来写：

If [功能失效] occurs in [运行场景],
Then [危害后果] may happen, leading to [伤害类型].

举个例子：

If 语音唤醒功能误触发 in 高速巡航场景,
Then 驾驶员注意力被分散, 导致车辆偏离车道, 引发碰撞.

我曾经在一个项目里，发现团队把“误触发”和“不响应”写成了同一个危害事件。这是不对的。误触发和不响应，场景不同，后果不同，ASIL等级也可能不同。

3.4 ASIL等级评定实例：手把手带你走一遍

好，理论说完了。咱们来走一个真实案例。

案例：AI座舱手势控制功能

功能描述：驾驶员通过手势（比如挥手）控制音量、接听电话等。

我们挑一个危害事件来评：

危害事件： 手势误识别（把“接听电话”识别成“挂断电话”）发生在高速驾驶场景，导致驾驶员情绪波动，分心操作，引发碰撞。

现在开始打分：

Step 1: 评定严重性（S）

看后果：碰撞可能导致重伤甚至死亡。查ISO 26262标准：

• S0: 无伤害
• S1: 轻伤（99%存活）
• S2: 重伤（90%存活）
• S3: 致命（10%存活）

这个案例里，高速碰撞后果严重，我评 S2。

Step 2: 评定暴露概率（E）

看场景：高速驾驶场景，平均每天可能遇到1-2次。查标准：

• E1: 极低（一年几次）
• E2: 低（一个月几次）
• E3: 中（一周几次）
• E4: 高（几乎每次驾驶）

高速场景不算特别频繁，但也不算罕见。我评 E3。

Step 3: 评定可控性（C）

看驾驶员能否避免事故：误识别后，驾驶员有1-2秒反应时间。老司机可能能稳住，新手可能慌。查标准：

• C1: 可控（>99%驾驶员能避免）
• C2: 一般可控（90%-99%能避免）
• C3: 难控（<90%能避免）

我个人觉得，这个场景下，大部分驾驶员能反应过来，但有一定风险。评 C2。

Step 4: 查表得ASIL

ISO 26262-3:2018 Table 1：

S	E	C1	C2	C3
S2	E3	ASIL A	ASIL B	ASIL C

查表结果：S2 + E3 + C2 = ASIL B。

你想想看，如果当初场景定义漏了“高速”这个场景，你可能只评了个ASIL A，那安全机制就不够，实车测试时可能就出事了。

3.5 HARA核心流程总览

下面这张图，是我自己总结的HARA全流程。每次做新项目，我都会贴一张在工位上。

这张图我建议你保存下来。每次做HARA，按这个流程走一遍，基本不会漏。

3.6 避坑总结：HARA常见的三个坑

最后，分享三个我踩过的坑：

• 坑一：场景定义太理想化。 我曾经只定义了“标准驾驶场景”，结果实车测试时，在隧道里信号丢失，系统直接崩了。隧道场景，你考虑了吗？
• 坑二：S/E/C打分凭感觉。 同一个危害事件，不同工程师打分可能差两级。我建议团队先对齐标准，最好有历史项目数据做参考。
• 坑三：危害事件写得太笼统。 比如“系统失效导致事故”，这种描述没法评ASIL。一定要写清楚：什么失效 + 什么场景 + 什么后果。