2. 安全目标定义：什么是安全目标、安全目标的来源（HARA）、安全目标的编写规范

好，我们正式开始聊安全目标。很多刚入行的工程师问我，安全目标到底是什么？我打个比方你就明白了——安全目标就像是整车的「安全底线」。它告诉你：这辆车在遇到某种危险时，绝对不能出什么事。

举个例子。你开车时突然刹车失灵，这时候系统必须做什么？必须保证车辆能安全停下来，不能撞人。这个「必须」就是安全目标。说白了，它就是一条红线，谁都不能踩过去。

2.1 什么是安全目标

安全目标（Safety Goal）是 ISO 26262 里的核心概念。它定义的是：当系统发生某个危害事件时，需要满足的最高层级安全要求。

我习惯这么理解——安全目标就是「顶层安全需求」。它不关心你怎么实现，只关心你必须达到什么结果。比如：

• 正确示例：「车辆在行驶中，必须避免非预期的加速」
• 错误示例：「软件要检测油门踏板信号，如果超过阈值就限制扭矩」

看出区别了吗？第一个说的是「要避免什么后果」，第二个说的是「怎么实现」。安全目标只关心后果，不关心实现。这个边界一定要清楚。

2.2 安全目标的来源：HARA

安全目标不是拍脑袋想出来的。它的唯一来源是 HARA（Hazard Analysis and Risk Assessment，危害分析与风险评估）。

我记得刚做第一个项目时，项目经理问我：「安全目标从哪来？」我说：「从需求文档里提炼啊。」他当场就笑了。后来我才明白，HARA 才是正根。没有 HARA，你写的安全目标就是无源之水。

HARA 的流程大致是这样的：

1. 场景分析：列出车辆所有可能的运行场景（高速、城市、停车、充电等）
2. 功能故障识别：分析每个场景下，系统功能如果失效会怎样
3. 危害事件定义：把功能故障和场景组合起来，形成具体的危害事件
4. 风险评估：评估每个危害事件的严重度（S）、暴露率（E）、可控性（C）
5. ASIL 等级确定：根据 S/E/C 查表得到 ASIL 等级（QM / A / B / C / D）
6. 安全目标导出：每个危害事件对应一个或多个安全目标

我画了一张图，帮你理清这个关系：

2.3 安全目标的编写规范

安全目标怎么写？这不是随便写两句就行的。ISO 26262 虽然没有给出严格的模板，但行业里已经形成了共识。我总结了一套我自己一直在用的规范，分享给你。

2.3.1 命名规则

每个安全目标必须有一个唯一的 ID。我习惯用这种格式：

SG_<系统缩写>_<序号>
示例：SG_BMS_001、SG_ESP_012

系统缩写要统一，不能今天写 BMS，明天写 Battery。项目一开始就要定好缩写表。

2.3.2 内容结构

一个完整的安全目标，应该包含以下要素：

要素	说明	示例
ID	唯一标识符	SG_BMS_001
标题	一句话概括	避免电池过充导致热失控
描述	详细说明安全要求	在车辆充电或行驶过程中，BMS 必须防止电池单体电压超过 4.25V，以避免热失控
ASIL	从 HARA 继承的等级	ASIL C
安全状态	达到安全目标时的系统状态	断开高压继电器，进入安全放电模式
来源	对应的危害事件 ID	HZ_BMS_003

2.3.3 编写原则

我总结了 5 条原则，你写安全目标时对照着检查：

1. 只说「什么」，不说「怎么」——不要出现「软件检测」「硬件冗余」这类实现细节
2. 可验证——每个安全目标必须能通过测试或分析来确认是否满足
3. 与危害一一对应——每个危害事件至少有一个安全目标覆盖
4. 明确安全状态——必须说清楚「系统应该处于什么状态才算安全」
5. ASIL 等级正确——不能随意升降，必须与 HARA 结果一致

2.3.4 常见错误示例

给你看几个我评审时经常见到的错误写法：

错误写法	问题	正确写法
软件必须在 100ms 内检测到故障	包含了实现方式（软件）	系统必须在 100ms 内进入安全状态
避免车辆失控	太模糊，不可验证	避免车辆在行驶中非预期的横向偏移超过 0.5m
ASIL D 要求，必须使用双核锁步	这是架构方案，不是安全目标	避免转向系统在行驶中完全失效

2.4 安全目标与功能安全概念的关系

安全目标写完之后，下一步就是把它细化成功能安全概念（FSC）。但这里我要强调一点：安全目标是 FSC 的输入，不是 FSC 本身。

我习惯这么看：

• 安全目标：顶层安全要求，关注「要避免什么」
• 功能安全概念：如何通过系统功能来实现安全目标，关注「要做什么」
• 技术安全概念：具体的技术实现方案，关注「怎么做」

这三层是逐层细化的关系。安全目标在最上面，它不关心下面怎么实现。但下面每一层都必须能追溯到上面的安全目标。