第一讲：HARA基础概念
什么是HARA？
HARA，全称是Hazard Analysis and Risk Assessment。中文叫「危害分析与风险评估」。说白了，就是一套系统性的方法，用来找出汽车电子系统里可能存在的危险，再评估这些危险到底有多严重。
我经常跟团队里的新人说：HARA不是做不做的问题，而是怎么做的问题。为什么？因为ISO 26262明确要求，所有功能安全相关的开发活动，第一步就是做HARA。
嗯，这里要注意一点：HARA不是一次性工作。我在项目中遇到过好几次，需求变了、架构改了，结果之前的HARA分析就得重新来过。所以别想着「做完一次就完事」，它是个持续迭代的过程。
HARA的核心三要素
做HARA分析，你始终要盯着三个东西：
- 危害（Hazard）：系统在某种场景下可能导致的伤害事件。比如刹车突然失灵、转向助力丢失。
- 暴露概率（Exposure）：这个危险场景发生的可能性有多大？是天天遇到，还是十年碰一次？
- 可控性（Controllability）：驾驶员在危险发生时，能不能通过操作避免伤害？
这三个要素组合起来，就决定了你的安全目标定多高。你想想看，一个危险场景如果天天发生，驾驶员又完全控制不了，那这个系统的安全等级肯定是最高的。
为什么需要HARA？
这个问题我经常被问到。有人觉得HARA就是走个过场，为了过认证。其实不是。
第一，HARA帮你找到「不知道的危险」。 我记得刚入行时，参与一个线控制动项目。我们觉得系统设计得很完美，结果HARA一分析，发现某个故障模式下，制动液会泄漏到电机控制器里。这个场景我们之前完全没想到。
第二，HARA决定了你的安全目标。 没有HARA，你就不知道系统应该做到什么安全等级。ASIL A、B、C、D，差一个等级，开发成本可能差好几倍。
第三，HARA是沟通工具。 我习惯把HARA分析结果贴在项目会议室里。系统工程师、软件工程师、测试工程师，大家一看就明白：哪些功能是「碰不得」的，哪些场景是「必须防」的。
一句话总结：没有HARA，你的功能安全就是「盲人摸象」。有了HARA，你才知道大象长什么样，哪里该摸，哪里该躲。
HARA在ISO 26262中的位置
ISO 26262把开发流程分成了几个阶段。HARA出现在哪里？我直接给你画个图：
| 阶段 | 活动 | 输出 |
|---|---|---|
| 概念阶段 | 定义系统、HARA分析 | 安全目标、ASIL等级 |
| 系统设计 | 安全架构设计 | 技术安全概念 |
| 硬件/软件开发 | 详细设计、实现 | 安全机制 |
| 测试验证 | 安全确认 | 验证报告 |
看到了吧？HARA是概念阶段的核心产出。它直接决定了后续所有安全活动的「天花板」。你HARA做得好，后面的设计、测试就有明确方向。做得不好，后面全是瞎忙活。
我曾经接手过一个项目，前面的团队HARA做得特别粗糙，安全目标写得很模糊。结果到了测试阶段，大家吵成一团：这个故障到底算不算安全目标覆盖？那个场景到底要不要测？最后不得不回头重做HARA，浪费了两个月。
HARA的输入和输出
做HARA之前，你需要准备好：
- 系统功能描述（这个系统是干什么的）
- 运行场景分析（车会在什么环境下用）
- 故障模式清单（系统可能出什么毛病）
做完HARA之后，你会得到：
- 安全目标（Safety Goal）：比如「制动系统在单点故障下，仍能提供50%的制动力」
- ASIL等级：A、B、C、D，或者QM（质量管理级）
- 安全状态：系统出问题后，应该进入什么状态？降级？关断？
我的小技巧：做HARA时，我习惯用Excel表格记录每个危害场景。列清楚：危害描述、运行场景、暴露概率、可控性、严重度、ASIL等级、安全目标。这样后续评审、追溯都方便。
避坑指南
我曾经踩过的坑：
- 别把「系统故障」和「危害」混为一谈。故障是原因，危害是结果。比如「传感器失效」是故障，「车速显示错误导致追尾」才是危害。
- 别忽略「非正常使用场景」。比如驾驶员误操作、极端天气、电磁干扰。这些场景往往暴露概率不高，但一旦发生，后果很严重。
- 别把ASIL等级定得太高。我见过有人把所有功能都定成ASIL D，结果开发成本爆炸，项目直接黄了。合理评估，该高就高，该低就低。
小结
HARA是功能安全的「地基」。地基没打好，上面盖的房子再漂亮也没用。我个人习惯，每个新项目启动时，第一件事就是拉着系统工程师、安全工程师、测试工程师，一起做HARA头脑风暴。花一周时间把危害场景过一遍，后面至少省一个月返工时间。
下一讲，我会详细讲HARA的具体步骤：怎么识别危害？怎么评估ASIL？怎么制定安全目标？到时候我会拿一个实际项目案例来拆解，保证你听完就能上手。