3. 安全目标定义：安全目标的来源、ASIL等级确定、安全目标的编写规范
好，咱们进入第三个核心话题——安全目标定义。
说实话，我见过不少项目，HARA做得漂漂亮亮，一到写安全目标就开始放飞自我。有人写得太笼统，比如“系统要安全”；有人写得太具体，直接写成了软件需求。这两种都不对。
安全目标到底是什么？说白了，它就是一条“底线”。这条底线告诉你：当某个危险事件发生时，系统必须做到什么，才能避免人员受伤。
3.1 安全目标的来源
安全目标不是拍脑袋想出来的。它的唯一来源，就是我们上一章讲的HARA（危害分析与风险评估）。
具体来说，每个危险事件，经过HARA分析后，都会对应一个安全目标。我个人的习惯是：一个危险事件，至少产出一个安全目标。有时候多个危险事件可以合并成一个安全目标，但前提是它们的“安全状态”完全一致。
举个例子：
假设HARA分析发现，电动助力转向系统在高速行驶时，如果“非预期转向助力丢失”，会导致车辆偏离车道，造成严重事故。
那么对应的安全目标就是：
“避免在高速行驶时发生非预期转向助力丢失”
你看，这个目标直接来源于那个具体的危险事件。它没有说“转向系统要可靠”，而是精准地指向了那个危险场景。
我的经验：
我在做ADAS项目时，曾经遇到一个情况：HARA分析出了20多个危险事件，但最后只写了8个安全目标。为什么？因为有些危险事件的“安全状态”是一样的，比如都是“进入降级模式并报警”。这种情况下，合并是合理的。
但要注意——不要为了凑数而合并。如果两个危险事件的ASIL等级不同，或者安全状态不同，那就必须分开写。
3.2 ASIL等级确定
安全目标写好了，接下来要给它定个“级别”——也就是ASIL等级。
ASIL等级怎么来的？嗯，它直接继承自HARA中对应危险事件的ASIL等级。HARA里评估了Severity（严重度）、Exposure（暴露概率）、Controllability（可控性），三者组合就得到了ASIL等级。
这里有个关键点：安全目标的ASIL等级，决定了后续所有安全活动的“力度”。
| ASIL等级 | 要求严格程度 | 典型应用场景 |
|---|---|---|
| ASIL D | 最高 | 制动、转向等安全关键系统 |
| ASIL C | 高 | 动力系统相关 |
| ASIL B | 中等 | 车身控制、部分ADAS功能 |
| ASIL A | 低 | 非关键功能，如车窗防夹 |
| QM | 仅需质量管理 | 信息娱乐、导航等 |
避坑指南：
我曾经见过一个项目，HARA分析出来的ASIL等级是B，但写安全目标时，有人觉得“这个功能很重要”，擅自把ASIL等级提到了D。
这是大忌！ASIL等级必须严格基于HARA分析结果，不能凭感觉“升级”或“降级”。如果你觉得HARA分析有问题，那就回去重新做HARA，而不是在安全目标这里改等级。
另外，还有一个常见问题：ASIL分解。有时候一个安全目标的ASIL等级很高，比如ASIL D，但我们可以把它分解成两个独立的安全目标，每个目标承担一部分责任，比如一个ASIL C，另一个ASIL C。这样整体上仍然满足ASIL D的要求。
但要注意——分解后的每个安全目标，必须相互独立，不能有共因失效。嗯，这个我们后面讲ASIL分解时会详细说。
3.3 安全目标的编写规范
好，到了最实操的部分——怎么写安全目标？
我总结了四个字：准、简、独、可。
- 准：准确描述危险事件，不要模糊。比如“避免非预期加速”，而不是“加速要安全”。
- 简：一句话说清楚，不要写成长篇大论。一般控制在20-30字以内。
- 独：每个安全目标只对应一个危险事件或一组高度相关的危险事件。不要“一锅烩”。
- 可：可验证。也就是说，后续的测试用例能够明确判断这个目标是否达成。
标准格式示例：
安全目标编号：SG-001
描述：避免在车速超过30km/h时发生非预期制动介入
ASIL等级：ASIL C
安全状态：车辆进入跛行模式，同时点亮制动系统故障灯
来源危险事件：HARA-ID-015（非预期制动介入导致追尾）我个人习惯，每个安全目标都要包含以下要素：
- 唯一编号：方便追溯，比如SG-001、SG-002。
- 描述：一句话，包含触发条件+危险行为+后果。
- ASIL等级：直接写，不要写范围。
- 安全状态：这是关键！安全目标必须明确“当危险发生时，系统应该进入什么状态”。
- 来源：指向HARA中的具体危险事件ID。
一个小技巧：
写安全目标时，试着用“如果...那么...”的句式来检查。
比如：“如果发生非预期制动介入，那么系统必须在100ms内检测到故障，并进入跛行模式，同时点亮故障灯。”
如果这个“那么”后面的内容写不出来，说明你的安全目标还不够具体。
最后，再强调一点：安全目标不是一成不变的。随着项目推进，你可能会发现新的危险场景，或者原来的安全目标写得不够好。这时候，不要怕改。但每次修改，都要走变更管理流程，并且更新所有相关的文档。
嗯，我记得有一次，一个项目都到测试阶段了，才发现某个安全目标写得有歧义——它说“避免系统失效”，但没说明是“永久失效”还是“间歇性失效”。结果测试团队和开发团队吵了半天。最后我们花了一周时间重新评审和修改。从那以后，我每次写安全目标，都会多问自己一句：“这句话，别人看了会不会有歧义？”
好，安全目标定义就讲到这里。下一章，我们聊聊安全状态设计——也就是当危险真的发生时，系统该怎么“体面地退场”。