4、危害分析与风险评估（HARA）：基于ISO 26262的HARA方法论
好，咱们进入功能安全里最核心、也是最磨人的一个环节——危害分析与风险评估，也就是HARA。很多刚入行的朋友觉得HARA就是填填表格，走个过场。我告诉你，这想法很危险。HARA做不好，后面所有的安全机制设计都是空中楼阁。
说白了，HARA要回答三个问题：车子哪里会出问题？出问题会多严重？我们得花多大力气去防？ 第三个问题的答案，就是ASIL等级。
4.1 HARA到底在干什么？
我个人习惯把HARA比作「排雷」。你想想看，一辆车上千个功能，每个功能都可能因为电子电气系统的故障而跑偏。HARA就是把这些「雷」一个个标出来，然后评估每个雷爆炸后的杀伤力。
ISO 26262第三部分明确要求：在概念阶段，必须完成HARA。它的输出直接决定了后续系统、硬件、软件开发的「安全目标」和「ASIL等级」。嗯，这里要注意，HARA不是一次性的。设计变了，或者你发现了新的运行场景，就得回头重新评估。
4.2 HARA的三步走
我在项目里通常把HARA拆成三步，这样团队执行起来不容易乱。
第一步：场景分析与危害识别
这一步最考验经验。你得想象车辆在各种场景下，功能如果失效会怎样。比如：
- 正常运行场景：高速巡航、市区跟车、倒车入库
- 故障场景：传感器突然掉线、执行器卡死、通信延迟
- 环境场景：雨雪天、隧道、夜间、地库
我曾经在一个项目中，团队只考虑了「直道行驶」的场景，结果漏掉了「弯道中加速」的工况。后来评审时被安全专家一顿批——弯道中动力系统误加速，危害等级直接拉满。
识别危害时，要问自己：这个功能失效，会不会导致人员受伤？ 比如：
- 刹车助力失效 → 制动距离变长 → 可能追尾
- 转向助力丢失 → 方向盘变重 → 可能偏离车道
- 电池管理系统误报 → 突然切断动力 → 后车追尾
第二步：危害事件评估与ASIL定级
这一步是HARA的「算分」环节。ISO 26262给了三个维度：
| 参数 | 含义 | 等级 |
|---|---|---|
| S（Severity） | 危害的严重度 | S0（无伤害）~ S3（致命） |
| E（Exposure） | 场景发生的概率 | E0（几乎不）~ E4（非常高） |
| C（Controllability） | 驾驶员能否控制 | C0（可控）~ C3（不可控） |
然后查表得出ASIL等级：
| S | E | C | ASIL |
|---|---|---|---|
| S3 | E4 | C3 | ASIL D |
| S2 | E3 | C2 | ASIL B |
| S1 | E2 | C1 | ASIL A |
| S0 或 E0 或 C0 | 任意 | QM | |
第三步：制定安全目标
有了ASIL等级，就得写安全目标了。安全目标是一句「顶层要求」，告诉系统设计者：你要防止这个危害发生。
举个例子：
- 危害事件： 车辆在高速行驶时，非预期的动力中断导致后车追尾
- 安全目标： 防止车辆在行驶中非预期地失去驱动力（ASIL C）
安全目标要写得清晰、可验证。别写「系统要可靠」这种废话。要写「当车速大于30km/h时，动力中断的持续时间不得超过200ms」。
4.3 一个完整的HARA示例
咱们拿「电动尾门」功能来练练手。这个功能看似简单，但HARA做不好也会出大事。
功能描述： 驾驶员按下按钮，尾门自动打开或关闭。
危害识别：
- 尾门在关闭过程中，如果防夹功能失效，可能夹到人
- 尾门在行驶中意外打开，物品掉落或遮挡后视镜
评估其中一个危害事件：
| 危害事件 | 车辆行驶中，尾门意外打开，物品掉落导致后车避让发生事故 |
| S | S2（严重伤害，如骨折） |
| E | E3（中等概率，每次行驶都可能发生） |
| C | C2（驾驶员可通过减速、靠边停车控制，但有一定难度） |
| ASIL | 查表得 ASIL B |
安全目标： 防止车辆行驶中尾门意外打开（ASIL B）
4.4 我的一些实操建议
- HARA一定要拉上系统工程师、硬件工程师、软件工程师一起做。 一个人闭门造车，很容易漏场景。我记得有一次，软件工程师提醒我：「这个电机堵转后，软件会报错并自动复位，复位瞬间可能会误动作。」这个场景我们之前完全没考虑到。
- 用工具管理HARA结果。 别用Excel，版本一多就乱。推荐用ReqIF或专门的HARA工具（如PREEvision、Medini Analyze）。
- HARA文档要可追溯。 每个危害事件都要能追溯到对应的安全目标，每个安全目标都要能追溯到后面的功能安全需求。这是审核员最喜欢查的地方。