2. 危害分析与风险评估（HARA）
好，咱们进入第二个章节。HARA，全称是 Hazard Analysis and Risk Assessment。这名字听着挺唬人，说白了就是一件事：找出系统可能出什么幺蛾子，然后评估这个幺蛾子到底有多严重。
我个人习惯把 HARA 看作是功能安全设计的“地基”。地基没打好，后面盖多高的楼都悬。我在项目里见过不少团队，急着写安全需求，结果 HARA 做得马马虎虎，最后评审时被问得哑口无言。嗯，咱们今天就把这块地基夯实了。
2.1 HARA 的目的：我们为什么要做这个？
你可能会问：“我直接写代码、画电路板不行吗？干嘛非得先做这个分析？”
原因很简单：不分析，你就不知道危险在哪。不知道危险在哪，你设计的安全机制要么过度，要么不足。过度了浪费成本，不足了……那就是安全隐患。
HARA 的核心目的有三个：
- 识别危害：找出系统在运行过程中，哪些故障或事件可能导致人员受伤。
- 评估风险：判断这些危害发生的概率和严重程度。
- 确定安全目标：为每个危害设定一个“必须达到的安全等级”，也就是 ASIL 等级。
说白了，HARA 就是回答三个问题：
“会出什么事？”
“这事有多糟？”
“我们得做到多好才能避免？”
重要提醒：HARA 不是一次性的工作。系统设计变了、使用场景变了，都得重新审视 HARA。我见过一个项目，因为没及时更新 HARA，导致后期安全目标跟实际系统对不上，返工成本极高。
2.2 危害识别方法：怎么找到那些“坑”？
危害识别，听起来像大海捞针。但其实有套路可循。常用的方法有几种，我挑最实用的讲。
2.2.1 头脑风暴与经验法
这方法最直接。把系统工程师、硬件工程师、软件工程师、测试工程师叫到一个屋子里，对着系统架构图，一个一个功能点去问：“如果这个功能失效了，会怎样？”
我在项目中遇到过，有一次讨论转向系统，一个刚入职的工程师问：“如果方向盘打左，车轮却往右转呢？”全场安静了三秒，然后大家意识到，这确实是个严重的危害。你看，有时候新人反而能跳出思维定势。
2.2.2 基于场景的分析
这个方法更系统。你得先定义系统的运行场景和运行模式。
举个例子，一个电动汽车的加速系统：
- 场景：高速公路上行驶、市区拥堵路段、地下车库停车。
- 模式：正常驾驶模式、巡航模式、倒车模式。
然后针对每个场景+模式的组合，去分析可能出现的危害。比如“高速公路上行驶 + 正常驾驶模式”下，如果加速踏板信号丢失，车辆突然减速，后车追尾怎么办？
2.2.3 功能失效分析
这个方法从系统功能出发，列出每个功能可能出现的失效行为。常见的失效类型包括：
- 功能丧失：该有的功能没了。比如刹车踩下去没反应。
- 功能异常：功能有了，但不对。比如刹车踩一点，却抱死了。
- 功能非预期：不该有的功能出现了。比如没踩油门，车自己加速。
我个人习惯用一张表格来记录这些分析结果，清晰明了。
| 功能 | 失效类型 | 危害描述 | 潜在后果 |
|---|---|---|---|
| 加速控制 | 功能异常（非预期加速） | 车辆在红灯前自动加速 | 碰撞行人或车辆 |
| 制动控制 | 功能丧失（无制动） | 驾驶员踩刹车但车辆不减速 | 追尾或无法停车 |
| 转向控制 | 功能异常（反向转向） | 方向盘左打，车轮右转 | 车辆失控，驶离车道 |
小技巧：做危害识别时，别只盯着“最坏情况”。有时候中等严重程度的危害，发生频率却很高，综合风险反而更大。我曾经就吃过这个亏，只关注了“高速失控”，忽略了“低速误加速”这种常见场景。
2.3 风险评估矩阵：给危害“打分”
危害找到了，接下来要评估风险。ISO 26262 里用的是风险评估矩阵，主要看三个维度：
- S（Severity）：严重度。伤害有多重？轻伤、重伤、还是致命？
- E（Exposure）：暴露概率。这个危险场景出现的频率高不高？
- C（Controllability）：可控性。驾驶员或其他人员能不能控制住局面？
这三个维度组合起来，就决定了 ASIL 等级（A、B、C、D）。D 是最严格的，A 相对宽松。如果三个维度都很低，那就是 QM（质量管理级），不需要按功能安全流程走。
2.3.1 严重度（S）怎么定？
严重度分四级：
- S0：无伤害
- S1：轻伤（比如擦伤、轻微扭伤）
- S2：重伤（比如骨折、内出血）
- S3：致命或危及生命
这里要注意，严重度评估的是伤害本身，不是故障本身。比如“刹车失灵”这个故障，如果发生在高速上，可能 S3；如果发生在停车场，可能 S2。
2.3.2 暴露概率（E）怎么定？
暴露概率分四级：
- E0：几乎不可能
- E1：很少发生（比如每年几次）
- E2：偶尔发生（比如每月几次）
- E3：频繁发生（比如每天都会遇到）
举个例子，“车辆在高速公路上以120km/h行驶”这个场景，对于经常跑高速的人来说，E3；对于只在市区开车的用户，可能 E1 甚至 E0。
2.3.3 可控性（C）怎么定？
可控性也分四级：
- C0：完全可控
- C1：简单可控（大多数驾驶员能应对）
- C2：一般可控（部分驾驶员能应对）
- C3：难以控制（几乎无法避免伤害）
这里有个坑，我提醒一下：不要高估驾驶员的能力。我曾经评估一个“突然失去动力”的危害，觉得驾驶员能滑行到路边，给了 C1。后来实际测试发现，在车流密集的路段，驾驶员根本来不及反应，直接就被追尾了。所以，可控性评估要保守一点。
2.3.4 查表定 ASIL
有了 S、E、C 的值，就可以查 ISO 26262 里的标准矩阵表了。我直接给你一个简化版：
| S | E | C1 | C2 | C3 |
|---|---|---|---|---|
| S1 | E1 | QM | QM | ASIL A |
| S1 | E2 | QM | ASIL A | ASIL B |
| S1 | E3 | ASIL A | ASIL B | ASIL B |
| S2 | E1 | QM | ASIL A | ASIL B |
| S2 | E2 | ASIL A | ASIL B | ASIL C |
| S2 | E3 | ASIL B | ASIL C | ASIL C |
| S3 | E1 | ASIL A | ASIL B | ASIL C |
| S3 | E2 | ASIL B | ASIL C | ASIL D |
| S3 | E3 | ASIL C | ASIL D | ASIL D |
你看，S3 + E3 + C3 就是 ASIL D，最严格。S1 + E1 + C1 就是 QM，基本不用管。
注意：这个矩阵只是简化版。实际项目中，每个公司可能会有自己的细化规则。但核心逻辑不变：越严重、越常见、越难控制，安全等级就越高。
2.4 一个小例子：电动窗的 HARA
光讲理论太枯燥，咱们来个简单的例子——电动窗防夹功能。
假设一个电动窗，在上升过程中如果检测到阻力，应该停止并下降。如果这个功能失效了，会怎样？
咱们做一下 HARA：
- 危害：车窗上升时夹住乘客（比如小孩的手臂）。
- 场景：乘客将手臂伸出窗外，然后操作车窗上升。
- S（严重度）：夹伤可能导致骨折或组织损伤，算 S2（重伤）。
- E（暴露概率）：乘客把手臂伸出窗外的情况，不算特别频繁，但也不罕见，给 E2。
- C（可控性）：一旦被夹住，乘客自己很难挣脱，其他人也不一定能及时反应，给 C2。
查表：S2 + E2 + C2 = ASIL B。
所以，这个防夹功能需要按照 ASIL B 的要求来设计。这意味着要有足够的诊断覆盖率和安全机制，比如双通道检测、定期自检等。
你看，一个看似简单的功能，经过 HARA 分析，就能明确它的安全等级。这就是 HARA 的价值所在。
我的经验：做 HARA 时，一定要让不同背景的人参与。硬件工程师能看到电路层面的风险，软件工程师能想到逻辑漏洞，系统工程师能把握整体场景。一个人闭门造车，很容易漏掉关键危害。
好了，这一章就到这里。HARA 是功能安全的起点，也是最重要的一步。下一章，咱们聊聊怎么把 HARA 的结果转化成具体的安全目标。到时候见。