第2章：危害分析与风险评估（HARA）
好，咱们进入正题。HARA，全称是Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：
- 这玩意儿会出啥事？
- 出了事有多严重？
- 我们该怎么防？
我在做第一个量产项目时，对HARA的理解还很浅。觉得不就是填个表嘛。后来出了个不大不小的bug，差点导致项目延期。嗯，从那以后，我再也不敢轻视HARA了。
2.1 HARA方法论概述
HARA不是拍脑袋想出来的。它有一套标准流程，ISO 26262里写得清清楚楚。我个人习惯把它拆成五步：
- 功能定义：搞清楚这个ECU是干嘛的。
- 危害识别：找出可能出问题的地方。
- 场景分析：在什么情况下会出问题？
- ASIL等级确定：评估风险有多高。
- 安全目标定义：定下我们要达到的安全要求。
你想想看，这五步就像盖楼打地基。地基没打好，后面全是空中楼阁。
核心原则：HARA必须在项目早期完成。我见过不少团队，代码都写了一半了才想起来做HARA。结果呢？推倒重来，成本翻倍。
2.2 危害识别
危害识别，就是找出系统可能出现的故障模式。比如：
- 传感器信号丢失
- 执行器卡死
- 通信超时
- 软件跑飞
这里有个坑，我踩过。很多人只关注功能故障，忽略了非功能故障。比如电源纹波过大、温度过高导致的性能下降。这些也要考虑进去。
我的小技巧：做危害识别时，拉上硬件、软件、测试的人一起头脑风暴。一个人想，总有盲区。三个人想，基本能覆盖90%。
2.3 场景分析
场景分析，说白了就是「在什么情况下，这个危害会变成事故？」
举个例子：
- 危害：刹车踏板信号丢失
- 场景A：高速公路上，前车急刹。这时候信号丢失，后果很严重。
- 场景B：停车场里，车速5km/h。信号丢失，顶多吓一跳。
你看，同一个危害，不同场景下风险等级完全不同。所以场景分析必须做细。
我记得有个项目，团队只分析了「正常驾驶」场景。结果呢？忽略了「低温启动」场景。冬天一到，问题全暴露了。嗯，那段时间加班加得...不提了。
2.4 ASIL等级确定
ASIL，全称是Automotive Safety Integrity Level。分四个等级：A、B、C、D。D是最严格的。
确定ASIL等级，主要看三个因素：
| 因素 | 说明 | 等级 |
|---|---|---|
| 严重度（S） | 事故造成的伤害程度 | S0（无伤害）~ S3（致命） |
| 暴露率（E） | 场景发生的概率 | E0（几乎不）~ E4（非常高） |
| 可控性（C） | 驾驶员能否避免事故 | C0（完全可控）~ C3（不可控） |
ASIL等级 = 严重度 × 暴露率 × 可控性。具体查表就行，ISO 26262里有。
注意：ASIL等级不是越高越好。ASIL D意味着开发成本翻倍。我见过有人把所有功能都定成ASIL D，结果项目预算直接爆炸。合理分配，才是正道。
2.5 安全目标定义
安全目标，就是针对每个危害，定下我们要达到的安全要求。
举个例子：
- 危害：刹车踏板信号丢失
- ASIL等级：C
- 安全目标：当刹车踏板信号丢失时，系统必须在100ms内检测到，并进入安全状态（比如启用备用传感器）。
安全目标要满足SMART原则：
- S（Specific）：具体明确
- M（Measurable）：可量化
- A（Achievable）：可实现
- R（Relevant）：相关
- T（Time-bound）：有时间限制
我曾经犯过一个错：安全目标写得太模糊。比如「系统要足够安全」。什么叫足够？没法验证。后来我学乖了，每个安全目标都带上具体数字。比如「故障检测时间不超过50ms」。
2.6 实战经验总结
最后，分享几点我的实战经验：
- HARA不是一次性的。项目过程中，需求变了，HARA也要跟着更新。
- 文档要写清楚。别以为记在脑子里就行。三个月后，你自己都忘了当初为啥这么定。
- 评审很重要。拉上不同角色的人一起评审，能发现很多盲区。
一句话总结：HARA做得好，后面开发顺风顺水。HARA做得差，后面全是坑。我见过太多项目，前期省了HARA的时间，后期十倍百倍地还回去。
好了，这一章就到这里。下一章咱们聊聊「功能安全需求开发」，看看怎么把安全目标落地成具体的技术方案。