1. 安全目标概述：什么是安全目标？它在ISO 26262中的位置与作用

各位工程师朋友，咱们今天开始聊安全目标。说实话，这个概念是整个ISO 26262的基石。你想想看，没有安全目标，后面的功能安全开发就没了方向。

我刚开始接触功能安全时，也犯过迷糊。总觉得安全目标就是“别出事故”这种大而化之的说法。后来在项目里吃过亏，才明白——安全目标必须具体、可验证、能落地。

1.1 什么是安全目标？

安全目标（Safety Goal, SG），说白了就是：针对某个危害事件，定义的最高层级安全要求。它回答一个核心问题：“系统出了什么故障，会导致什么后果？我们要把风险降到多低？”

举个例子。我在做电动助力转向项目时，定义过这样一个安全目标：

你看，这个目标很具体——有数值、有时间、有可验证的手段。不是空话。

安全目标有几个关键特征：

• 最高层级：它位于安全要求的最顶层，往下才分解出功能安全要求、技术安全要求、软硬件安全要求。
• 面向危害：每个安全目标都对应一个或多个危害事件（Hazardous Event）。
• 包含ASIL等级：每个安全目标都分配了一个ASIL等级（A、B、C、D或QM）。
• 可验证：必须能通过测试或分析来确认是否满足。

1.2 安全目标在ISO 26262中的位置

ISO 26262把安全生命周期分成了几个阶段。安全目标出现在概念阶段的末尾，是概念阶段输出的核心成果之一。

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

从这张图你能看到，安全目标处于一个承上启下的关键位置。上面连着HARA，下面接着功能安全概念。我习惯把它叫做“安全开发的锚点”。

1.3 安全目标的核心作用

安全目标在ISO 26262中到底起什么作用？我总结了四点：

作用维度	具体说明	我的经验
1. 风险量化	把模糊的“危险”转化为可度量的安全要求	没有量化，评审时大家各说各话，根本没法达成一致
2. 设计输入	为功能安全概念、技术安全概念提供顶层约束	我见过一个项目，安全目标没定清楚，后面架构改了三次
3. 验证基准	作为安全确认（Safety Validation）的通过标准	测试报告里必须逐条对照安全目标，缺一不可
4. 责任边界	明确系统、子系统、组件之间的安全责任划分	供应商扯皮时，安全目标就是最硬的依据

1.4 安全目标与ASIL等级的关系

每个安全目标都带一个ASIL等级。这个等级来自HARA中对三个参数的评估：

• S（Severity）：危害的严重度
• E（Exposure）：暴露概率
• C（Controllability）：驾驶员可控性

ASIL等级从低到高依次是：QM → ASIL A → ASIL B → ASIL C → ASIL D。

举个例子。我在做线控制动项目时，遇到过这样一个场景：

你看，ASIL D意味着这个安全目标需要最高等级的功能安全开发流程来保证。从设计、验证到生产，每一步都有严格要求。

1.5 安全目标的典型结构

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

要素	说明	示例
ID	唯一标识符	SG-01
危害事件引用	关联到HARA中的具体危害	HZ-03: 非预期加速
安全状态描述	系统在故障下应进入什么状态	进入跛行模式，限速30km/h
容错时间间隔	从故障发生到进入安全状态的最大时间	FTTI ≤ 500ms
ASIL等级	从HARA继承的ASIL	ASIL C
验证准则	如何确认该目标已达成	通过故障注入测试验证

1.6 安全目标的常见误区

这些年评审过不少安全目标，发现几个典型问题：

1. 太笼统：“系统应保证安全”——这种话等于没说。安全目标必须具体到可测试。
2. 混淆了目标和方案：有人把“采用双冗余架构”写进安全目标。记住，安全目标只描述“要达成什么”，不描述“怎么实现”。
3. 遗漏了安全状态：只说了“故障时怎么办”，没说“正常时怎么退出安全状态”。
4. ASIL等级分配不合理：要么过度分配（把QM的活硬提到ASIL D），要么分配不足（该ASIL D的给了ASIL B）。

嗯，这里要注意——安全目标不是写出来就完事了。它需要在项目全生命周期里被维护。需求变了、架构改了、新的危害发现了，安全目标都要跟着更新。

1.7 小结

安全目标，说白了就是功能安全开发的“宪法”。它把HARA分析出来的风险，转化为可执行、可验证的顶层要求。后面的所有安全活动——功能安全概念、技术安全概念、软硬件设计、测试验证——都要围绕它展开。

我个人习惯，在项目初期花足够多的时间把安全目标定义清楚。磨刀不误砍柴工，这个阶段多花一天，后面可能省下一周甚至一个月的返工时间。