一、HARA概述：什么是HARA？它在ISO 26262中的位置，与功能安全的关系
各位工程师朋友，大家好。我是你们这门课的老朋友。今天咱们正式进入BMS功能安全实战的第一讲——HARA。
说实话，我见过不少同行，一上来就埋头写安全目标、算ASIL等级，结果写到一半发现场景没定义清楚，回头又去补HARA。嗯，这种弯路我年轻时也走过。所以咱们今天就把HARA这个地基打牢。
1.1 什么是HARA？
HARA，全称是Hazard Analysis and Risk Assessment，中文叫“危害分析与风险评估”。
说白了，就是回答三个问题：
- 车会不会出事儿？（识别危害）
- 出事儿有多严重？（评估风险）
- 我们该多认真地对待它？（确定ASIL等级）
我个人习惯把HARA比作“体检”。你想想看，一个BMS系统，如果连自己可能怎么坏、坏了会怎样都不清楚，那就像一个人从不体检，直接上马拉松——太危险了。
核心定义：HARA是ISO 26262-3:2018第7章中定义的系统性方法，用于识别车辆在运行场景中因功能异常引发的危害，并评估其风险等级。
1.2 HARA在ISO 26262中的位置
ISO 26262标准分12个部分，HARA出现在第3部分（概念阶段）。它的位置非常关键——在项目定义和安全生命周期启动之后，紧接着就是HARA。
我画个简单的流程给你看：
| 阶段 | 活动 | 输出 |
|---|---|---|
| 3-5 | 项目定义 | 系统边界、功能清单 |
| 3-6 | 安全生命周期启动 | 安全计划 |
| 3-7 | HARA | 危害清单、ASIL等级、安全目标 |
| 3-8 | 功能安全概念 | 安全机制、FSR |
你看，HARA就像一个分水岭。前面是“我们要做什么”，后面是“我们怎么做才能安全”。没有HARA，后面的安全设计就是无源之水。
我的经验：我在做BMS项目时，经常发现有些团队把HARA当成“一次性任务”，做完就扔一边。其实HARA应该是一个活文档——随着系统设计变更、场景增加，HARA需要持续更新。我曾经有一个项目，因为新增了一个快充场景，导致原有的安全目标不适用，不得不重新做部分HARA。嗯，从那以后，我每次开设计变更评审会，都会问一句：“HARA需要更新吗？”
1.3 HARA与功能安全的关系
这个问题，我换个角度给你讲。
功能安全的核心目标是：当系统发生故障时，不会对人的生命造成不可接受的风险。
那怎么知道“不可接受”的边界在哪里？
答案就是HARA。
HARA是功能安全的起点，也是标尺。
- 起点：没有HARA，你就不知道要防什么。
- 标尺：HARA给出的ASIL等级，决定了你后续设计、验证、测试的严格程度。
举个例子。BMS里有一个常见危害：电池过充。
通过HARA分析，我们可能会得出：
- 危害事件：车辆在高速行驶中，BMS失效导致电池过充，引发热失控。
- 严重度（S）：S3（危及生命）
- 暴露率（E）：E4（每次驾驶都可能发生）
- 可控性（C）：C2（驾驶员一般无法控制）
- ASIL等级：ASIL D
你看，这个ASIL D就是标尺。它告诉我们：针对过充，你必须用最高等级的安全机制——比如冗余的电压采样、独立的硬件保护路径、甚至熔断器。
避坑指南：我曾经见过一个团队，把过充的ASIL定成了B，理由是“我们有BMS软件保护”。这是典型的错误！HARA评估的是危害本身的固有风险，而不是你现有设计能防住多少。记住：先评估风险，再设计安全机制。顺序不能乱。
1.4 为什么BMS系统特别需要HARA？
你想想看，BMS管的是几百伏的高压电池，能量巨大。一旦失控，热失控、起火、爆炸，都不是闹着玩的。
而且BMS的故障模式特别多：
- 电压采样不准
- 电流传感器漂移
- 温度检测延迟
- 绝缘监测失效
- 通信中断
- ……
每个故障都可能引发不同的危害。没有HARA，你根本理不清优先级。
我个人习惯，在BMS项目启动的第一周，就拉着系统、硬件、软件、测试的负责人，开一个HARA工作坊。大家一起过场景、定ASIL。虽然一开始会吵得面红耳赤，但吵完之后，大家对安全目标的理解就统一了。后面做设计、写代码、跑测试，效率反而更高。
1.5 小结
好了，咱们今天把HARA的“是什么、在哪、有什么用”讲清楚了。
记住三句话：
- HARA是功能安全的“体检报告”——告诉你哪里危险、多危险。
- HARA在ISO 26262的概念阶段——是后续所有安全活动的输入。
- HARA的输出是安全目标和ASIL等级——决定了你设计的“用力程度”。
下一讲，咱们会深入HARA的具体步骤：场景分析、危害识别、风险评估。我会拿BMS的真实案例，一步步带你走一遍。
咱们下节课见。