第4章：危害分析与风险评估（HARA）流程
好，咱们进入正题。HARA，全称 Hazard Analysis and Risk Assessment，中文叫危害分析与风险评估。这玩意儿是ISO 26262里最核心的环节之一。说白了，它就是回答一个问题：这车到底安不安全？
我刚开始做功能安全那会儿，觉得HARA就是个填表走流程的活儿。后来踩过坑才明白——HARA做不好，后面全白干。你想想看，ASIL等级定错了，整个架构都得推倒重来。那成本，啧啧...
4.1 HARA的输入：你得先准备好这些
做HARA之前，你得手里有料。我个人习惯，先拉一个输入清单，逐项核对。少了哪一项，后面都可能出问题。
| 输入项 | 说明 | 来源 |
|---|---|---|
| 系统定义文档 | 域控制器的功能、接口、边界 | 系统架构师 |
| 功能清单 | 所有需要分析的功能列表 | 需求文档 |
| 运行场景描述 | 车辆在什么工况下运行 | OEM或Tier1 |
| 已知危害库 | 行业积累的典型危害 | 经验/标准 |
嗯，这里要注意：系统定义文档必须是最新版本。我曾经遇到过，拿着旧版文档做HARA，结果功能都变了，白分析了一周。那叫一个郁闷。
4.2 HARA的输出：你要交出什么
HARA做完，你得拿出三样东西：
- 危害清单：所有识别出的危害事件
- ASIL等级：每个危害对应的安全等级（QM, ASIL A/B/C/D）
- 安全目标：每个危害对应的顶层安全要求
这三样东西，是后续所有安全工作的基础。你想想看，安全目标定错了，后面的安全机制、测试用例全得跟着错。所以HARA这一步，宁可慢，不可错。
核心要点：HARA的输出质量，直接决定了整个功能安全开发的成败。我见过太多项目，HARA草草了事，结果到了测试阶段才发现ASIL等级定低了，整个架构重做。那酸爽...
4.3 核心步骤：一步一步来
HARA的核心步骤，我习惯分成四步走。每一步都有坑，我一个个说。
步骤一：功能定义与场景分析
先搞清楚你的域控制器要干什么。比如，ACC自适应巡航功能，你得知道它什么时候激活、什么时候退出、在什么路况下工作。
我个人习惯，先画一个功能框图，把输入、输出、控制逻辑标清楚。然后列出所有可能的运行场景：
- 高速公路 vs 城市道路
- 晴天 vs 雨天 vs 雪天
- 白天 vs 夜晚
- 正常驾驶 vs 紧急情况
为什么要做场景分析？因为同一个功能，在不同场景下，危害的严重程度可能完全不同。举个例子，ACC在高速上失效，和在地库里失效，后果能一样吗？
步骤二：危害识别
这一步，说白了就是头脑风暴。把所有可能出问题的地方都列出来。我常用的方法是：
- 从功能出发，问「如果这个功能失效了，会发生什么？」
- 从系统出发，问「如果这个传感器坏了，会怎样？」
- 从环境出发，问「如果遇到极端天气，系统会怎么反应？」
举个例子，对于自动驾驶域控制器的「自动紧急制动（AEB）」功能：
- 危害1：AEB误触发——车辆突然急刹车，后车追尾
- 危害2：AEB不触发——前方有障碍物，但车没刹住
- 危害3：AEB部分失效——只刹了一边，车辆跑偏
避坑指南：我曾经犯过一个错误——只考虑了「功能失效」的危害，忽略了「功能误用」的危害。比如，AEB在不需要的时候突然刹车，这其实比不刹车更危险。所以，失效和误用都要考虑。
步骤三：风险评估
这一步，就是给每个危害定ASIL等级。ISO 26262给了三个参数：
- S（Severity）：严重度，分S0-S3
- E（Exposure）：暴露概率，分E0-E4
- C（Controllability）：可控性，分C0-C3
ASIL等级 = f(S, E, C)。具体怎么查表，标准里写得很清楚，我就不啰嗦了。但我要强调一点：这三个参数的评估，一定要基于实际数据，不能拍脑袋。
我记得有一次，团队里一个工程师给某个危害定了S3（最高严重度），理由是「万一撞死人怎么办？」。我说，你冷静一下，这个危害是在低速泊车场景下发生的，车速不超过5km/h，最多刮蹭，S1就顶天了。所以，评估要客观，不要情绪化。
| 参数 | 等级 | 典型场景 |
|---|---|---|
| S（严重度） | S0-S3 | S0:无伤害, S1:轻伤, S2:重伤, S3:致命 |
| E（暴露概率） | E0-E4 | E0:几乎不暴露, E4:每次驾驶都暴露 |
| C（可控性） | C0-C3 | C0:完全可控, C3:几乎不可控 |
步骤四：制定安全目标
最后一步，把每个危害转化成安全目标。安全目标要满足两个条件：
- 可验证：能通过测试或分析来确认是否满足
- 可追溯：能追溯到具体的危害
举个例子：
- 危害：AEB在高速上不触发，导致追尾
- 安全目标：AEB功能在车速>30km/h时，对前方静止障碍物的制动响应时间<200ms，且ASIL等级为D
嗯，这里要注意：一个危害可以对应多个安全目标，反过来也一样。但最好是一对一，这样好管理。
警告：安全目标不要写得太笼统。比如「系统要安全」这种话，说了等于没说。安全目标必须具体、可量化、可测试。我见过最离谱的安全目标：「系统不能出问题」。你告诉我，这怎么验证？
4.4 我的实战经验总结
做了这么多年HARA，我总结了几条铁律：
- HARA不是一次性工作。系统设计变了，HARA就要跟着更新。我见过一个项目，HARA做完就扔那了，结果架构改了三轮，HARA还是最初版本。那安全目标还有什么意义？
- 多找几个人一起做。一个人做HARA，容易陷入思维盲区。我习惯拉上系统工程师、软件工程师、测试工程师，大家一起头脑风暴。不同视角，能发现更多问题。
- 文档要写清楚。每个危害的评估依据、每个参数的取值理由，都要写明白。不然审核的时候，人家问你「为什么这个危害是S2不是S1？」，你答不上来就尴尬了。
好了，HARA的流程就讲到这里。下一章，咱们聊聊安全目标怎么分解到具体的技术安全需求。那一步，才是真正开始干活的时候。