4. 危害分析与风险评估（HARA）
HARA，说白了就是功能安全里最核心的那道坎。你想想看，如果连风险都找不准，后面的安全措施全是白搭。我个人习惯把HARA看作一次「系统级体检」——把每个可能的故障场景都翻出来，看看它到底有多危险。
4.1 HARA方法论：从场景到目标
HARA不是拍脑袋想出来的。它有一套标准流程，我把它拆成三步走：
- 场景识别：列出车辆所有可能的运行场景。比如高速巡航、城市拥堵、倒车入库。
- 危害识别：针对每个场景，找出系统失效后会导致什么危害。比如刹车失灵、转向卡死。
- 风险评估：用矩阵给每个危害打分，确定它的严重度（S）、暴露率（E）、可控性（C）。
嗯，这里要注意：场景不能只写「正常行驶」。我见过不少团队漏掉极端场景，比如「湿滑路面下坡时突然爆胎」。这种场景虽然概率低，但一旦发生，后果很严重。
核心原则：HARA必须覆盖全生命周期。从生产、使用到报废，每个阶段都要考虑。我曾经审核过一个项目，他们只分析了驾驶模式，结果维修模式下的高压触电风险完全没覆盖——这要是出了事，审核直接不通过。
4.2 危害识别：别漏掉「隐形杀手」
危害识别是HARA里最考验经验的环节。我刚开始做这行时，总觉得把功能失效列出来就够了。后来发现，真正的坑往往藏在「非功能失效」里。
举个例子：一个ADAS摄像头，如果因为镜头脏污导致误识别，这算不算危害？算！而且这种危害很难通过传统FMEA发现。我个人习惯在危害识别时，拉一个跨部门会议——系统、软件、硬件、测试的人全叫上。为什么？因为不同视角能看到不同风险。
我的小技巧：用「STPA」（系统理论过程分析）作为补充。传统HARA偏重组件失效，STPA能帮你找出「控制逻辑错误」导致的危害。比如ACC系统在隧道出口突然急刹车，这种问题用STPA更容易抓到。
危害识别清单通常包括：
- 意外加速/减速
- 转向失控
- 制动失效
- 高压电击
- 热失控（电池）
- 通信中断导致误动作
我曾经审核过一个线控转向项目，团队只列了「转向电机失效」和「传感器故障」。我追问了一句：「如果方向盘角度信号因为电磁干扰跳变呢？」他们愣住了。后来补测，果然发现了这个问题。
4.3 风险评估矩阵：打分不是拍脑袋
风险评估矩阵，说白了就是给每个危害定个「危险等级」。ISO 26262里用三个维度：
| 参数 | 等级 | 说明 |
|---|---|---|
| S（严重度） | S0~S3 | S3代表致命伤害，比如高速碰撞 |
| E（暴露率） | E0~E4 | E4代表几乎每次驾驶都会遇到，比如倒车 |
| C（可控性） | C0~C3 | C3代表驾驶员几乎无法控制，比如爆胎 |
打分的时候，我见过最典型的错误是「凭感觉」。比如有人觉得「高速爆胎」很可怕，直接给S3、E4、C3。但实际分析时，爆胎的暴露率其实很低（E2），而且有经验的驾驶员可以部分控制（C2）。
避坑指南：我曾经审核一个项目，他们把「电池热失控」的严重度全打了S3。但仔细一看，有些场景是停车充电时发生，车内没人，严重度其实只有S1。记住：同一个危害在不同场景下，S/E/C值可能完全不同。必须按场景逐一打分。
最终，根据S、E、C的组合，查表得到ASIL等级（A、B、C、D）。QM表示无需安全措施，ASIL D是最严格的。
4.4 安全目标定义：把风险翻译成要求
安全目标，就是把HARA的结果变成一句句「必须做到的事」。比如：
- 「制动系统必须能在150ms内响应驾驶员踩踏板动作」
- 「电池管理系统必须防止单体电压超过4.2V」
- 「转向系统在失去电源后，必须保持最后的位置至少3秒」
写安全目标时，我有个习惯：每个目标只对应一个危害。别想着一个目标覆盖所有问题。比如「防止意外加速」和「防止意外减速」是两个不同的危害，必须分开写目标。
关键点：安全目标要可验证。你想想看，如果目标写成「系统要足够安全」，那怎么测试？正确的写法是：「当车速超过30km/h时，制动助力失效后，驾驶员踩下制动踏板的力不得超过150N」。这样测试工程师才能设计用例。
另外，安全目标必须分配ASIL等级。比如一个ASIL D的目标，后续所有开发活动都要按ASIL D的要求来——包括硬件失效率、软件独立性、测试覆盖率等。
嗯，最后说一句：HARA不是一次性的工作。项目过程中如果设计变了、场景变了，必须重新做HARA。我见过一个团队，中期改了传感器布局，但没更新HARA，结果审核时被开了严重不符合项。
我的经验总结：HARA做得好不好，直接决定后续安全开发的成本。一个ASIL D的目标，开发成本可能是ASIL B的3倍。所以，别为了省事把风险打高了，也别为了省钱把风险打低了。实事求是，才是审核专家最看重的。