3. HARA分析实战：以LKA为例进行危害分析与风险评估
好，咱们进入正题。HARA，全称是 Hazard Analysis and Risk Assessment，中文叫危害分析与风险评估。说白了，就是回答三个问题：
- 这功能出问题了，会出什么事？
- 这事儿有多严重？
- 我们得做到多安全才能接受？
我个人习惯，做HARA之前，先别急着翻标准。先拿张白纸，把LKA的功能场景画出来。你想想看，LKA在高速上跑，在市区里跑，在弯道上跑，场景不一样，危害也不一样。
3.1 第一步：定义功能与场景
我们先明确LKA的核心功能：
功能描述： 当车辆无意识偏离车道时，系统通过主动转向干预，将车辆引导回车道中心。
嗯，这里要注意，是“无意识偏离”。如果驾驶员打了转向灯，那系统就不该干预。这个边界条件，在HARA里要写清楚。
我建议把场景分成三类：
- 高速场景： 车速 > 80 km/h，车道线清晰，交通流稳定
- 城市场景： 车速 30-60 km/h，车道线可能模糊，有行人、非机动车
- 弯道场景： 曲率半径 < 250m，视野受限
为什么要分场景？因为同一个故障，在不同场景下，后果天差地别。我在项目中遇到过，一个LKA的扭矩输出故障，在高速上差点让车撞上护栏，但在市区低速时，驾驶员一把就能拉回来。
3.2 第二步：识别危害事件
接下来，我们要找出“什么情况下LKA会变成杀手”。
常见的危害事件包括：
- 误激活： 驾驶员没想变道，LKA突然打方向
- 失效： 该转向时不转向，车辆偏离车道
- 过度干预： 转向力矩过大，驾驶员无法修正
- 错误方向： 本该向左转，结果向右转了
我举个例子。有一次，我们测试车在高速上，LKA突然把方向盘往右打了一下。驾驶员吓了一跳，赶紧抢方向盘。后来查出来，是摄像头把路面的阴影误识别成了车道线。这就是典型的“误激活”。
3.3 第三步：评估风险等级（ASIL等级）
ISO 26262 给了我们三个维度来评估风险：
| 参数 | 含义 | 等级 |
|---|---|---|
| S (Severity) | 危害的严重程度 | S0, S1, S2, S3 |
| E (Exposure) | 场景发生的概率 | E0, E1, E2, E3, E4 |
| C (Controllability) | 驾驶员能否控制 | C0, C1, C2, C3 |
然后根据这三个参数，查表得到ASIL等级：
| S | E | C | ASIL |
|---|---|---|---|
| S2 | E3 | C2 | ASIL B |
| S3 | E3 | C2 | ASIL C |
| S3 | E4 | C3 | ASIL D |
我个人的经验是，S（严重度） 是最容易扯皮的。你觉得撞护栏是S2还是S3？我的建议是，拿实际的事故数据说话。比如，高速上偏离车道导致的对撞事故，死亡率很高，那S3没跑。
3.4 第四步：LKA的HARA实例
好，我们拿一个具体的场景来走一遍流程。
场景： 高速公路上，车速120 km/h，车道线清晰，驾驶员双手轻扶方向盘。
危害事件： LKA因软件故障，在直道上突然施加50Nm的转向力矩，导致车辆突然向右变道。
评估过程：
- S（严重度）： 突然变道可能导致与相邻车道车辆碰撞，高速碰撞死亡率高 → S3
- E（暴露率）： 高速场景很常见，几乎每次开车都会遇到 → E4
- C（可控性）： 驾驶员在120km/h下，突然被抢方向盘，反应时间很短。大部分驾驶员无法在1秒内稳定控制车辆 → C3
查表：S3 + E4 + C3 = ASIL D
你可能会问，是不是所有LKA的故障都是ASIL D？不是的。比如，在市区低速场景下，同样的故障，S可能降到S2，C可能降到C2，最终可能是ASIL B。所以，场景很重要。
3.5 第五步：定义安全目标
有了ASIL等级，我们就要定义安全目标了。安全目标说白了就是：“系统不能做什么”。
以刚才的ASIL D危害为例，安全目标可以写成：
SG-01: LKA系统在未检测到驾驶员意图时，不得施加超过10Nm的转向力矩。
- ASIL: D
- 验证方法: 故障注入测试 + 软件静态分析
- 接受准则: 在1000次随机故障注入中，无一次超过阈值嗯，这里要注意，安全目标要写得可验证。你不能写“系统要安全”，那是废话。要写“力矩不超过10Nm”、“响应时间小于100ms”这种能测的东西。
我在项目中见过最坑的安全目标，写的是“系统应避免危险”。你告诉我，这怎么测？没法测。所以，安全目标一定要量化。
3.6 第六步：从安全目标到功能安全需求
安全目标是顶层的，接下来要分解成功能安全需求。比如：
- FSR-01: 转向扭矩监控模块必须独立于主控制模块运行（ASIL D）
- FSR-02: 当检测到扭矩超过阈值时，系统必须在50ms内进入安全状态（ASIL D）
- FSR-03: 安全状态为：切断转向助力，并发出声音报警（ASIL D）
这些需求，最终会落到软件架构、硬件架构、甚至系统架构上。比如FSR-01，你可能需要两个不同的MCU来跑监控和主控，或者用锁步核来实现。
3.7 总结与常见误区
好，我们快速总结一下HARA的要点：
- 场景要全： 高速、低速、弯道、直道、白天、黑夜、雨雪，一个都不能少
- 危害要具体： 别写“系统故障”，要写“误激活导致车辆突然变道”
- 等级要客观： 别为了省事故意降低ASIL等级，最后吃亏的是自己
- 安全目标要可测： 写清楚阈值、时间、条件
最后，说一个我踩过的坑。有一次，我们做LKA的HARA，把“驾驶员始终手握方向盘”作为默认假设。结果呢？实际用户就是会放手。后来出了事故，追责的时候，这个假设被质疑了。从那以后，我所有的HARA都假设驾驶员可能在任何时候分心。
嗯，HARA这东西，说白了就是“把最坏的情况想清楚”。你越想得周全，后面开发就越顺利。否则，等到测试阶段才发现问题，改起来成本就高了。
下一章，我们会讲怎么把这些安全目标落地到系统架构里。到时候见。