3. 危害分析与风险评估（HARA）
好，咱们进入预期功能安全里最核心的一步——HARA。说实话，很多工程师觉得HARA就是填表格、走流程。但我个人经验告诉我，HARA做得好不好，直接决定了整个项目的安全基线稳不稳。
HARA的全称是Hazard Analysis and Risk Assessment。翻译过来就是“危害分析与风险评估”。它的目标很明确：找出系统在预期功能下可能出现的危害，然后评估这些危害的风险等级，最后定出安全目标。
你想想看，一辆自动驾驶车在高速上突然误刹车，后果是什么？这就是HARA要管的事。
3.1 HARA方法论
HARA不是拍脑袋想出来的。它有一套成熟的方法论。我个人习惯把它拆成三步走：
- 场景分析：先搞清楚系统在什么场景下运行。比如城市道路、高速公路、夜间、雨天等等。
- 危害识别：针对每个场景，分析系统功能失效会带来什么危害。比如“感知系统漏检行人”就是一个危害。
- 风险评估：评估每个危害的严重度、暴露概率和可控性，最后算出ASIL等级。
我在项目中遇到过一种情况：团队只关注了常见的驾驶场景，忽略了“施工路段”这种边缘场景。结果后期测试时才发现，系统在施工路段的误判率极高。嗯，这里要注意——场景的覆盖面一定要广。
核心原则： HARA不是一次性的工作。随着系统设计迭代，HARA也要跟着更新。我建议每个里程碑节点都重新审视一遍。
下面这张图是我自己总结的HARA核心流程，你可以对照着看：
3.2 ASIL等级确定
ASIL是Automotive Safety Integrity Level的缩写。说白了就是给每个危害定个“危险等级”。ISO 26262定义了四个等级：ASIL A、B、C、D。D是最严格的，A相对宽松。还有一个QM（Quality Management），表示不需要额外安全措施。
ASIL等级由三个参数决定：
| 参数 | 含义 | 等级范围 |
|---|---|---|
| S（Severity） | 危害发生时，对人员的伤害严重度 | S0~S3 |
| E（Exposure） | 危害场景发生的概率 | E0~E4 |
| C（Controllability） | 驾驶员或其他人员控制危害的能力 | C0~C3 |
举个例子。我在做AEB（自动紧急制动）项目时，分析了一个危害：“车辆在高速行驶时，AEB误触发导致急刹车”。
- S评估：高速急刹车可能导致后车追尾，严重度我给S2（可能致命）
- E评估：误触发概率不高，但场景常见，我给E3
- C评估：驾驶员很难在瞬间反应并纠正，我给C2
查表后，这个危害的ASIL等级是C。嗯，这个等级意味着需要相当严格的安全措施。
个人经验： 我建议在评估E（暴露概率）时，不要只看单一场景。要把场景组合起来看。比如“雨天+夜间+施工路段”这种组合场景，虽然每个单独概率低，但组合后可能并不罕见。
3.3 安全目标定义
安全目标是什么？说白了就是一句话：“系统必须避免某某危害发生”。但这句话不能太笼统，得有具体的ASIL等级和验收标准。
安全目标的格式我一般这样写：
安全目标ID：SG_001
描述：系统必须避免在车速>60km/h时，因感知漏检导致与前方静止车辆碰撞。
ASIL等级：C
验收标准：在标准测试场景下，误漏检率<10^-8/h
关联危害：HZ_003（感知漏检导致碰撞）
我曾经犯过一个错误：安全目标写得太模糊。比如“系统必须安全”。这种目标没法验证，也没法设计。后来我学乖了，每个安全目标都要有明确的量化指标。
安全目标有几个关键点：
- 可验证性：目标必须能通过测试或分析来验证。比如“误刹车率小于X次/小时”就是可验证的。
- 可追溯性：每个安全目标都要能追溯到具体的危害和场景。不能凭空冒出来。
- 独立性：每个安全目标只针对一个危害。不要一个目标管多个危害，那样会乱。
避坑指南： 我曾经见过一个团队，把安全目标定义成了功能需求。比如“系统必须能在100ms内识别行人”。这其实是功能需求，不是安全目标。安全目标关注的是“避免危害”，而不是“实现功能”。这两个要分清楚。
最后说一句，HARA的输出文档一定要维护好。我习惯用版本控制工具管理HARA表格，每次更新都记录变更原因。这样审计的时候，你能说清楚每个决策是怎么来的。
好了，HARA这部分就讲到这里。记住，HARA不是走过场，它是整个安全设计的基石。你花在HARA上的时间，后期都会在测试和验证阶段省回来。