3、危害分析与风险评估(HARA)：HARA方法论、危害识别、风险分类与ASIL确定
好，咱们进入功能安全里最核心、也最考验经验的一步——HARA。
说实话，HARA做得好不好，直接决定了你后续所有工作的方向。方向错了，后面再努力也是白搭。我见过不少项目，因为HARA阶段没做透，到了测试阶段才发现ASIL等级定低了，那叫一个痛苦。
3.1 HARA到底是什么？
HARA，全称Hazard Analysis and Risk Assessment。翻译过来就是危害分析与风险评估。
它的目标很明确：找出系统在故障状态下可能造成的危害，然后评估这个危害有多严重，最后给每个危害定一个安全等级——也就是ASIL。
我个人习惯把HARA比作「体检」。你想想看，体检不是为了治病，而是为了提前发现风险。HARA也一样，它是在设计阶段就把潜在的危险揪出来。
核心要点：HARA不是一次性的工作。随着设计深入，你可能发现新的危害，或者原有危害的等级需要调整。所以，HARA文档要持续维护。
3.2 危害识别——你得先知道敌人长什么样
危害识别是HARA的第一步。说白了，就是问自己一个问题：这个系统如果出了故障，会怎样伤害人？
这里有个常见的误区：很多人只盯着电子故障。其实机械故障、软件逻辑错误、甚至人为误操作，都可能引发危害。
我记得有一次做EPS（电动助力转向）项目，团队一开始只考虑了电机短路、传感器失效这些电气故障。结果我追问了一句：「如果转向管柱机械卡滞呢？」大家才意识到，机械故障同样会导致转向助力丢失。
危害识别常用的方法：
- 头脑风暴：拉上系统、硬件、软件、测试、甚至售后的人一起聊。不同视角能发现盲区。
- 检查表法：基于过往项目的经验，整理一份常见危害清单。新手团队特别推荐用这个。
- FMEA（失效模式与影响分析）：从每个组件的失效模式出发，推导可能引发的危害。
我的小技巧：做危害识别时，别只盯着「最坏情况」。中等程度的危害往往更容易被忽略，但实际发生频率可能更高。
3.3 风险分类——三个维度定生死
识别出危害之后，就要给每个危害「打分」了。ISO 26262用了三个维度来评估风险：
| 维度 | 英文 | 含义 | 等级范围 |
|---|---|---|---|
| 严重度 | Severity (S) | 危害发生时，对人员造成的伤害程度 | S0 ~ S3 |
| 暴露概率 | Exposure (E) | 人员处于危险场景中的频率 | E0 ~ E4 |
| 可控性 | Controllability (C) | 驾驶员或相关人员能否避免危害 | C0 ~ C3 |
为什么会这样分？你想想看，一个危害即使很严重（比如刹车失灵），但如果它几乎不可能发生（E0），或者驾驶员总能反应过来（C0），那它的风险等级其实不高。
反过来，一个看似不严重的危害（比如仪表盘显示错误），如果驾驶员完全无法控制（C3），而且经常暴露（E4），那它的风险等级反而可能很高。
举个例子：
- 场景：车辆在高速公路上行驶时，突然失去动力。
- S：可能导致追尾或失控，严重伤害甚至死亡 → S3
- E：高速公路行驶是常见场景 → E4
- C：驾驶员可以滑行到路边，有一定可控性 → C2
避坑指南：我曾经见过一个团队，把「可控性」评估得过于乐观。他们觉得「驾驶员总能踩刹车」，所以给了C1。但实际测试发现，在紧急情况下，普通驾驶员的反应时间远高于预期。所以，评估可控性时，请以「普通驾驶员」为基准，而不是赛车手。
3.4 ASIL确定——从风险到等级
有了S、E、C三个维度的等级，就可以查表确定ASIL了。
| 严重度 (S) | 暴露概率 (E) | 可控性 (C) | ASIL等级 |
|---|---|---|---|
| S1 | E1 | C1 | QM |
| S2 | E2 | C2 | ASIL A |
| S3 | E3 | C2 | ASIL B |
| S3 | E4 | C2 | ASIL C |
| S3 | E4 | C3 | ASIL D |
注意，这个表只是简化版。实际ISO 26262里有一张完整的矩阵表，涵盖了所有S、E、C的组合。
ASIL从低到高分别是：QM（无需安全措施）、ASIL A、ASIL B、ASIL C、ASIL D。ASIL D是最严格的，比如刹车、转向这类安全关键系统。
重要提醒：ASIL等级不是越高越好。等级越高，开发成本、验证工作量都成倍增加。我见过一个项目，把雨刮器控制也定成了ASIL B，结果团队为了满足要求，花了大量时间做冗余设计，最后发现完全没必要。合理分配ASIL，才是高手。
3.5 我的HARA实战经验
最后，分享几个我在项目中积累的实操建议：
- 别一个人闷头做。HARA一定要多部门评审。我习惯的做法是：先由系统工程师起草，然后拉上硬件、软件、测试、质量一起过一遍。每个人都能发现盲区。
- 场景要具体。不要写「车辆行驶中」，要写「车辆以120km/h在高速公路上行驶，前方有弯道」。场景越具体，评估越准确。
- 文档要可追溯。每个危害都要能追溯到具体的功能或组件。这样后续做安全措施时，才能有的放矢。
- 别怕修改。HARA不是一锤子买卖。随着设计细化，你可能会发现新的危害，或者原有评估不合理。大胆改，但要记录变更原因。
嗯，HARA这部分内容就到这里。说白了，它就是功能安全的「地基」。地基打牢了，后面的安全需求、安全架构、测试验证才能站得住脚。