3. 危害分析与风险评估（HARA）
好，咱们进入功能安全开发里最核心的一步——HARA。说实话，我见过不少项目，前期设计做得挺漂亮，一到HARA就开始糊弄。结果呢？后期改得想哭。HARA做扎实了，后面的安全目标、安全需求才有根。
3.1 HARA方法论：到底在干什么？
HARA，全称 Hazard Analysis and Risk Assessment。说白了，就是回答三个问题：
- 系统会不会出危险？（危害识别）
- 出了危险后果多严重？（风险评估）
- 怎么防止它出危险？（安全目标）
我个人习惯把HARA比作「排雷」。你想想看，EPS系统直接控制方向盘，一旦出问题，可能就是车毁人亡。所以这个环节，我从来不敢省时间。
核心原则：HARA不是一次性的工作。随着设计深入，你会发现新的危害，或者原来的评估太保守/太乐观。迭代是常态。
3.2 危害识别：把「鬼」都找出来
这一步的目标是：找出所有可能的系统级危害。注意，是系统级，不是元器件级。比如「电机失控」是系统级危害，「MOSFET短路」是元器件级失效。
常用的方法有：
- 头脑风暴：拉上系统、软件、硬件、测试的人一起过一遍功能清单。
- 检查表法：基于过往项目经验，列出常见危害模式。
- FMEA（失效模式与影响分析）：从功能出发，逐项分析失效后的影响。
我记得有一次做EPS的HARA，团队里一个年轻工程师说：「方向盘突然反向助力，这算不算危害？」我说：「当然算！而且这是最危险的之一。」你想想看，高速上你往左打，车往右转，那画面太美我不敢看。
避坑指南：我曾经见过一个项目，危害识别只做了「助力丢失」和「助力过大」，结果漏掉了「非预期助力方向」。后来在实车测试中差点出事。所以，一定要把「方向」和「幅度」两个维度都考虑进去。
3.3 风险评估：量化你的恐惧
找到危害之后，得给它「打分」。ISO 26262 给了三个维度：
| 参数 | 含义 | 等级范围 |
|---|---|---|
| S（Severity） | 伤害的严重程度 | S0（无伤害）~ S3（致命） |
| E（Exposure） | 暴露在危险场景中的概率 | E0（几乎不）~ E4（非常高） |
| C（Controllability） | 驾驶员能否控制住局面 | C0（可控）~ C3（几乎不可控） |
然后根据 S、E、C 的组合，查表得到 ASIL（汽车安全完整性等级），从 A（最低）到 D（最高），还有 QM（无需安全措施）。
举个例子：
- 危害：高速行驶中EPS突然失去助力。
- S评估：失去助力后驾驶员需要更大力量转向，可能无法避障 → S2（严重伤害）。
- E评估：高速行驶是常见工况 → E4（非常高）。
- C评估：有经验的驾驶员可以稳住方向，但普通人可能慌乱 → C2（一般可控）。
- 结果：查表得 ASIL C。
注意：ASIL等级不是越高越好。ASIL D 意味着开发成本翻倍甚至更多。我见过有人为了省事，把所有危害都定成 ASIL D，结果项目预算直接爆炸。合理评估，精准打击。
3.4 安全目标定义：给设计定规矩
有了ASIL等级，接下来就是定义安全目标（Safety Goal）。安全目标是一条顶层的安全要求，它告诉设计团队：「这个危害，你必须用这个等级的措施去防止。」
格式一般是：
SG-XX：[危害描述] 应被防止，达到 [ASIL等级]。
例如：
SG-01：EPS非预期反向助力应被防止，达到 ASIL D。
SG-02：EPS助力完全丢失应被防止，达到 ASIL C。每个安全目标还要定义 FTTI（故障容错时间间隔）。说白了就是：从故障发生到系统进入安全状态，最多能容忍多久。
比如：
- 非预期反向助力：FTTI ≤ 100ms（因为人反应不过来）
- 助力丢失：FTTI ≤ 500ms（因为驾驶员需要时间接管）
嗯，这里要注意：FTTI 不是拍脑袋定的。我一般会结合 人因工程数据 和 实车测试 来定。定得太短，硬件实现不了；定得太长，安全不达标。
我的经验：安全目标写完后，一定要让系统架构师和软件架构师一起评审。我曾经写过一条「EPS应防止非预期助力」，结果架构师问我：「非预期助力包括哪些？方向反了算不算？幅度过大算不算？」一句话问得我哑口无言。所以，安全目标要具体，可验证。
3.5 一个完整的HARA示例（EPS系统）
为了让你更直观，我列一个我实际项目中用过的简化版HARA表格：
| 危害ID | 危害描述 | 运行场景 | S | E | C | ASIL | 安全目标 |
|---|---|---|---|---|---|---|---|
| H-01 | 非预期反向助力 | 高速直行 | 3 | 3 | 3 | D | SG-01：防止非预期反向助力，ASIL D，FTTI≤100ms |
| H-02 | 助力完全丢失 | 低速泊车 | 2 | 4 | 2 | C | SG-02：防止助力完全丢失，ASIL C，FTTI≤500ms |
| H-03 | 助力过大（超出驾驶员预期） | 弯道行驶 | 2 | 3 | 2 | B | SG-03：限制最大助力输出，ASIL B，FTTI≤200ms |
你看，同一个EPS系统，不同场景、不同危害，ASIL等级完全不同。这就是HARA的价值——把有限的开发资源，用在最危险的地方。
小技巧：做HARA时，我习惯用「场景卡片」法。每张卡片写一个运行场景（比如「高速直行」「低速泊车」「冰雪路面」），然后针对每个场景分析危害。这样不容易漏，也方便评审时讨论。
3.6 总结一下
HARA做得好不好，直接决定了功能安全开发的成败。我个人觉得，这步花再多时间都值得。你想想看，如果安全目标定错了，后面所有的设计、验证、测试，都是在错误的方向上狂奔。
最后送大家一句话：HARA不是文档，是思考过程。别为了过审而做，要为了安全而做。