1. HARA基础概念：什么是HARA？为什么需要HARA？HARA在功能安全中的位置
大家好，我是你们这趟功能安全之旅的向导。
咱们开门见山，今天聊HARA。很多刚入行的朋友一听到这个词就头大，觉得是个高大上的理论。其实没那么玄乎。说白了，HARA就是一套系统化的方法，用来回答三个问题：系统哪里会出问题？出问题后果多严重？我们该怎么应对？
1.1 什么是HARA？
HARA，全称是Hazard Analysis and Risk Assessment，中文叫危害分析与风险评估。
我个人的理解，它就像给系统做一次全面的「体检」。不是简单的查查有没有故障，而是要看：如果某个部件坏了，会不会导致人受伤？
举个例子。你想想看，一辆车的刹车系统如果失灵了，后果是什么？可能是追尾，可能是撞人。HARA要做的，就是把这种「失灵」的场景找出来，然后评估它有多危险。
HARA的核心输出是三个东西：
- 危害事件：什么情况下会出事？比如「高速行驶中刹车突然失效」。
- 危害等级：这事有多严重？用ASIL等级来量化（A、B、C、D，D最危险）。
- 安全目标：我们要达到什么安全状态？比如「刹车失效时，车辆必须在2秒内自动减速到安全速度」。
重点来了：HARA不是一次性的工作。它贯穿整个开发周期。你设计变了，HARA就要跟着更新。我见过不少项目，前期HARA做得漂漂亮亮，后期改了几版设计，HARA却纹丝不动——这是大忌。
1.2 为什么需要HARA？
这个问题，我当年刚入行时也问过师傅。师傅反问我：「你开车上路，要不要先看看路况？」
道理是一样的。没有HARA，你就是在闭着眼睛做安全设计。
具体来说，HARA有三大作用：
- 识别风险源头：系统里哪些功能可能出问题？是传感器坏了？还是软件逻辑错了？HARA帮你把潜在的风险点一个个揪出来。
- 确定安全等级：不是所有风险都需要同等对待。一个车窗升降失灵，和一个刹车失灵，安全等级天差地别。HARA用ASIL帮你区分轻重缓急。
- 指导安全设计：知道风险在哪、有多严重，你才知道该花多少精力去防护。ASIL D的系统，你可能需要双冗余设计；ASIL A的系统，也许加个监控就够了。
我的一个小经验：刚开始做HARA时，容易陷入「过度分析」的陷阱。把所有可能的风险都列出来，结果发现根本做不完。我建议先聚焦在最严重、最可能发生的几种场景上。剩下的，可以在后续迭代中逐步完善。
1.3 HARA在功能安全中的位置
咱们把功能安全的整个流程想象成盖房子：
| 阶段 | 对应活动 | HARA的角色 |
|---|---|---|
| 概念阶段 | 定义系统、识别功能 | 还没开始，先画图纸 |
| HARA阶段 | 分析危害、评估风险 | 确定地基要挖多深 |
| 系统设计 | 制定安全架构 | 根据地基深度设计承重墙 |
| 硬件/软件开发 | 实现安全机制 | 按图纸施工 |
| 测试验证 | 确认安全目标达成 | 验收房子是否牢固 |
你看，HARA处在概念阶段和系统设计阶段之间。它承上启下：
- 承上：把「系统要做什么」转化为「系统不能出什么错」。
- 启下：为后续的安全设计提供明确的输入——每个安全目标对应什么ASIL等级，需要什么样的安全机制。
避坑指南：我曾经在一个项目中，团队把HARA做成了「文档作业」。大家花了两周时间，写了一份厚厚的HARA报告，然后束之高阁。后续设计完全没参考它。结果呢？测试阶段发现安全机制不够，返工成本翻了三倍。
记住：HARA不是用来应付审核的，它是用来指导设计的。每一页分析，都应该能在后续的代码或硬件中找到对应的实现。
1.4 一个简单的HARA示例
光说不练假把式。咱们拿一个最简单的系统来走一遍HARA流程：电动座椅调节。
假设这个座椅有前后移动功能。我们分析一下：
- 功能：用户按下按钮，座椅向前或向后移动。
- 危害：座椅意外移动（比如按钮卡住，或者控制器故障）。
- 场景：驾驶员正在开车，座椅突然向前移动，导致驾驶员被挤压，无法正常操作刹车和油门。
- 风险评估：
- 严重度（S）：可能导致碰撞，严重受伤 → S3
- 暴露率（E）：每次开车都可能发生 → E4
- 可控性（C）：驾驶员很难在紧急情况下控制座椅 → C3
- ASIL等级：S3 + E4 + C3 → ASIL C
- 安全目标：防止座椅在车辆行驶中意外移动。ASIL C。
你看，就这么几步，一个清晰的安全需求就出来了。后续设计时，你就知道要给座椅控制器加一个「车速信号」作为互锁条件——车速超过5km/h时，禁止座椅电动调节。
总结一下：HARA不是理论，是工具。它帮你把模糊的「安全」概念，变成具体的、可量化的、可执行的设计要求。掌握了它，你才算真正入了功能安全的门。
下一章，咱们聊聊HARA的具体步骤和常用方法。到时候我会拿一个更复杂的系统——比如线控制动——来演示。敬请期待。