3. 危害分析与风险评估(HARA)
好，咱们进入HUD系统功能安全设计里最核心的一步——HARA。说实话，很多工程师觉得HARA就是填表格、走流程。但我做了这么多年，可以负责任地告诉你：HARA做得好不好，直接决定了你后续所有安全机制的成败。
3.1 HARA方法论：不只是填表
HARA的全称是Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：
- 什么东西会坏？（危害识别）
- 坏了会怎样？（场景分析）
- 后果多严重？（风险评级）
我个人习惯把HARA分成四步走：
- 功能定义——搞清楚HUD到底要干什么
- 危害识别——找出所有可能出错的点
- 场景分析——结合驾驶场景看后果
- 风险评定——定出ASIL等级
嗯，这里要注意：很多人一上来就跳进细节，结果漏掉了最基础的功能边界。我在项目中遇到过，有个团队把HUD的亮度调节功能分析得特别细，却忘了考虑「显示内容完全卡死」这种场景——这才是真正要命的。
3.2 HUD系统特定危害识别
HUD和普通车载屏幕不一样。它投射的信息直接叠加在驾驶员的视野里。你想想看，如果信息错了或者延迟了，驾驶员会怎么反应？
我总结了几类HUD特有的危害：
| 危害类别 | 具体表现 | 典型场景 |
|---|---|---|
| 信息错误 | 车速显示偏差、导航箭头指错方向 | 高速上显示限速120，实际限速80 |
| 信息延迟 | 前车碰撞预警晚显示2秒 | 市区跟车，预警来了已经撞上 |
| 信息遮挡 | HUD图像遮挡了路面的行人 | 夜间行驶，HUD亮度太高看不清路 |
| 信息闪烁 | 图像频繁闪烁或抖动 | 驾驶员分心，误判距离 |
| 系统死机 | HUD画面卡死在前一帧 | 隧道内卡死，显示错误车速 |
关键点：HUD的危害往往不是「完全不工作」，而是「工作得不准确」。后者更难检测，也更危险。
为什么会这样？因为驾驶员对HUD有信任依赖。一旦HUD给出了错误信息，驾驶员可能会做出错误决策。我曾经参与过一个项目，HUD的导航箭头因为软件bug延迟了500ms，结果在复杂路口，驾驶员按照旧箭头转了弯——差点出事。
3.3 风险等级评定
风险评定用三个参数：
- S（Severity）——严重度，0~3级
- E（Exposure）——暴露概率，0~4级
- C（Controllability）——可控性，0~3级
然后查表得出ASIL等级（A、B、C、D）或QM。
我举个例子，咱们分析一下「HUD车速显示比实际快20km/h」这个危害：
| 参数 | 评级 | 理由 |
|---|---|---|
| S | 2 | 可能导致追尾或超速，有受伤风险 |
| E | 3 | 每次开车都会用到车速显示 |
| C | 2 | 驾驶员可以通过仪表盘对比，但需要时间 |
查表得到ASIL B。嗯，这个等级意味着你需要做中等强度的功能安全开发。
我的经验：对于HUD系统，E值往往偏高——因为HUD是持续工作的。而C值有时会被低估。我曾经见过一个案例，评估人员觉得「驾驶员可以看仪表盘」，但实际驾驶中，谁会一边开车一边对比两个车速？所以C值我建议保守一点。
3.4 避坑指南
做HARA时，有几个坑我踩过，分享给你：
坑1：忽略组合危害
HUD的某个故障可能和ADAS的故障同时发生。比如HUD显示错误的车距预警，同时AEB又失效了——这种组合场景要单独分析。
坑2：场景覆盖不全
别只分析晴天直路。夜间、雨天、隧道、强光、雪地——每个场景下危害的严重度可能完全不同。
坑3：过度依赖历史数据
HUD是新技术，历史故障数据少。别因为「没出过事」就降低评级。我建议用FMEA的方法做前瞻性分析。
3.5 实战建议
最后，给你几个实操建议：
- 团队要跨部门——系统、软件、硬件、测试、安全工程师一起做HARA。一个人想不全。
- 文档要可追溯——每个危害都要能追溯到具体功能和安全目标。别写完了就扔一边。
- 评审要较真——HARA评审时，多问几个「如果...会怎样？」。我曾经在评审会上被问住过，但那次发现了一个之前完全没考虑到的危害。
好了，HARA这部分就讲到这里。下一章咱们聊聊怎么根据HARA的结果，设计具体的安全机制。记住，HARA不是终点，是起点。