2. 危害分析与风险评估（HARA）基础
各位工程师朋友，咱们今天聊聊HARA。说实话，我刚入行那会儿，觉得HARA就是个走形式的文档工作。直到有一次，我负责的一个EPS项目在测试阶段发现了转向助力异常中断——嗯，从那以后，我再也不敢小看HARA了。
2.1 HARA到底是什么？
HARA，全称Hazard Analysis and Risk Assessment，中文叫危害分析与风险评估。说白了，就是回答三个问题：
- 系统会不会出问题？——识别危害事件
- 出问题后果多严重？——评估风险等级
- 需要多严格地保护？——确定ASIL等级
我个人习惯把HARA比作“安全体检”。就像人需要定期体检来发现潜在健康风险，汽车电子系统也需要HARA来找出功能安全方面的“病灶”。
核心定义：HARA是ISO 26262第3部分（概念阶段）的核心活动，用于识别系统的危害事件，并评估其风险等级，从而为后续安全目标的制定提供依据。
2.2 HARA在功能安全中的位置
HARA不是孤立存在的。它在整个功能安全开发流程中扮演着“承上启下”的角色。我画了张图，你看完就明白了。
从这张图你能看到，HARA处于项目定义和安全目标之间。它把“系统要做什么”翻译成“系统不能出什么错”。我记得有个项目，项目经理催着要跳过HARA直接写安全目标，被我拦住了。为什么？因为没有HARA，你根本不知道哪些风险需要重点防护。
2.3 HARA的输入
做HARA之前，你得准备好几样东西。我列个表，你对照着检查一下。
| 输入项 | 内容说明 | 来源 |
|---|---|---|
| 项目定义 | 系统边界、功能列表、运行模式、环境条件 | 系统需求文档 |
| 功能架构 | 系统功能分解、信号流、接口定义 | 系统架构设计 |
| 运行场景 | 驾驶场景、道路类型、天气条件、交通状况 | 使用场景分析 |
| 法规要求 | ISO 26262、GB/T 34590、客户安全需求 | 法规库、客户输入 |
| 历史数据 | 同类系统故障记录、召回数据、事故报告 | 质量部门、售后数据 |
我的经验：项目定义阶段最容易犯的错是“边界划得太窄”。我曾经遇到一个项目，只考虑了正常驾驶场景，忽略了维修模式下的危害——结果在HARA评审时被安全审计员打回来重做。所以，输入阶段多花点时间，后面能省很多麻烦。
2.4 HARA的输出
HARA做完后，你会得到一套完整的输出物。这些是后续所有安全活动的“宪法”。
- 危害事件清单——系统可能出现的所有危害情况
- 风险等级评估——每个危害事件的S、E、C参数
- ASIL等级——从QM到ASIL D的等级分配
- 安全目标——每个危害事件对应的安全要求
- HARA报告——完整的分析文档
这里我特别想强调一下安全目标。安全目标不是随便写的，它必须满足几个条件：
- 可验证——能不能通过测试或分析来确认？
- 可追溯——能不能追溯到具体的危害事件？
- 无歧义——不同工程师读完后理解一致
避坑指南：我曾经见过一个安全目标写成“系统应足够安全”。这种表述在HARA评审时直接被否决。安全目标必须具体，比如“当车速超过30km/h时，制动助力失效的概率应低于10^-8每小时”。
2.5 HARA的常见误区
做了这么多年HARA，我总结了几条新手容易踩的坑：
| 误区 | 错误表现 | 正确做法 |
|---|---|---|
| 范围过窄 | 只考虑正常驾驶，忽略故障模式 | 覆盖所有运行模式和故障场景 |
| ASIL分配过高 | 所有危害都定ASIL D | 基于实际风险合理分配 |
| 忽略组合危害 | 只分析单一故障 | 考虑多个故障同时发生的情况 |
| 文档不完整 | 缺少分析过程记录 | 保留所有分析依据和决策理由 |
嗯，说到ASIL分配过高，我想起一个真实案例。有个团队做线控制动系统，把所有危害都定成了ASIL D。结果开发成本翻了三倍，周期拉长半年。后来重新做HARA，发现大部分场景其实ASIL B就够了。所以，HARA不是越严格越好，而是要“恰到好处”。
2.6 小结
HARA是功能安全的基石。它把模糊的安全需求变成具体的、可量化的目标。你想想看，如果没有HARA，你怎么知道系统需要多高的安全等级？怎么证明你的设计是充分的？
我个人建议，每次做HARA时，都问自己三个问题：
- 我有没有漏掉某个危害场景？
- 我的风险等级评估是否合理？
- 安全目标能不能被验证？