2. 功能安全与ISO 26262基础
好，咱们进入第二章。HARA，全称 Hazard Analysis and Risk Assessment，中文叫危害分析与风险评估。这玩意儿是整个功能安全开发的起点，也是决定你后续工作量大小的关键一步。
我见过不少团队，上来就急着写安全目标，结果写到一半发现场景没覆盖全，又回头补HARA，那叫一个痛苦。所以，咱们先把HARA的底子打扎实。
2.1 HARA的基本流程
HARA说白了就三步：识别危害 → 分析场景 → 评估风险。但每一步里面都有不少坑。
我个人习惯把流程拆成下面这张图，你们先看个全貌：
你看，这流程不是线性的。做完风险评估，如果发现ASIL等级太高或者太低，你可能得回头调整场景定义，甚至重新审视危害识别是否遗漏。迭代，是HARA的常态。
2.2 危害识别
危害识别，就是找出系统在功能异常时，可能对人员造成伤害的那些情况。
注意，我说的是“功能异常”，不是“系统故障”。你想想看，一个功能本身设计没问题，但用户误操作或者环境干扰导致它不正常工作，这也算危害。
2.2.1 危害识别的输入
做危害识别之前，你得先搞清楚几件事：
- 系统边界：哪些东西归你管，哪些不归你管？
- 功能清单：系统到底有哪些功能？每个功能是干啥的？
- 已知失效模式：比如传感器短路、通信超时、执行器卡滞。
我记得有一次，一个团队做线控制动系统的HARA，他们只考虑了“制动失效”这一个危害。我说，你们漏了“非预期制动”啊——车好好开着，突然自己刹停了，这危害不比刹不住小。所以，危害识别一定要正反两面都看。
2.2.2 常见的危害类型
我给大家列个表，这是我在项目里常用的分类：
| 危害类别 | 典型示例 | 后果 |
|---|---|---|
| 非预期功能激活 | 车辆无故加速、雨刮自动启动 | 碰撞、视线受阻 |
| 功能丧失 | 制动助力消失、转向助力消失 | 无法减速、无法转向 |
| 功能输出错误 | 显示车速比实际快20km/h | 驾驶员误判 |
| 功能延迟 | AEB制动指令延迟500ms | 追尾 |
2.3 场景分析
危害识别完了，接下来就是场景分析。这一步很多人觉得简单，其实最容易翻车。
场景分析要回答三个问题：
- 什么时候这个危害会发生？（运行场景）
- 在什么环境下发生？（环境条件）
- 驾驶员/用户当时在干嘛？（操作状态）
2.3.1 运行场景
运行场景包括车辆的状态和周围环境。比如：
- 车辆状态：静止、低速行驶、高速巡航、倒车、泊车
- 道路类型：城市道路、高速公路、乡村小路、停车场
- 环境条件：白天/黑夜、晴天/雨雪/雾、干燥/湿滑/结冰
我曾经在一个项目中，客户坚持认为“高速公路上不会有人突然横穿马路”，所以没把“行人横穿”纳入场景。结果呢？功能安全审核员直接给了个严重不符合项。你想想看，高速公路虽然概率低，但一旦发生就是致命事故。所以，场景分析要覆盖合理可预见的 misuse。
2.3.2 场景组合矩阵
实际项目中，我们通常用矩阵来组合场景。拿“非预期加速”这个危害举例：
| 车辆状态 | 道路类型 | 环境条件 | 场景描述 |
|---|---|---|---|
| 静止 | 停车场 | 白天、干燥 | 车辆在停车场静止，非预期加速撞向前方车辆或行人 |
| 低速行驶 | 城市道路 | 夜间、湿滑 | 车辆在拥堵路段低速跟车，非预期加速追尾前车 |
| 高速巡航 | 高速公路 | 白天、干燥 | 车辆以120km/h巡航，非预期加速导致失控 |
| 倒车 | 停车场 | 夜间、干燥 | 车辆倒车出库，非预期加速撞向后方行人 |
2.4 危害事件与安全状态
场景分析完成后，你要把“危害 + 场景”组合成一个完整的危害事件。比如：
“车辆在高速公路上以120km/h巡航时，由于驱动系统故障导致非预期加速，造成车辆失控的风险。”
然后，针对每个危害事件，你要定义安全状态。安全状态就是系统在检测到故障后，应该进入的、能避免或减轻危害的状态。
举个例子：
- 危害：非预期加速
- 安全状态：切断驱动扭矩，同时保持制动助力可用，让驾驶员能安全减速停车
这里有个细节：安全状态不是“直接断电”那么简单。你想想看，如果高速上直接切断动力，方向盘助力可能也没了，那更危险。所以，安全状态的设计要综合考虑整车安全。
2.5 小结
好了，这一章的内容就这些。HARA的核心就是：识别危害 → 分析场景 → 评估风险。每一步都有它的门道，尤其是场景分析，千万别偷懒。