2. 功能安全基础

各位好，欢迎来到第二章。上一章我们聊了功能安全的基本概念和ISO26262的总体框架。这一章，我们要深入功能安全管理的核心——安全生命周期、HARA和安全目标。说白了，这三件事决定了你的项目从哪开始、怎么识别风险、以及最终要达成什么安全指标。

我个人习惯，接手一个新项目，第一件事不是看代码，而是先看安全计划。没有清晰的安全生命周期定义，后面所有的开发活动都可能白费力气。你想想看，如果连哪个阶段该做什么事都没搞清楚，怎么保证最终的产品是安全的？

2.1 安全生命周期模型

安全生命周期，不是简单的“需求-设计-编码-测试”这种V模型。它是ISO26262专门为功能安全定义的一套活动序列。我把它理解成一张“安全路线图”。

这张图告诉你：什么时候该做HARA？什么时候该定义安全目标？什么时候该做安全确认？每一步都有明确的输入和输出。

ISO26262把安全生命周期分成几个主要阶段：

• 概念阶段：定义项目、做HARA、定义安全目标。
• 产品开发阶段：系统级、硬件级、软件级的安全设计与验证。
• 生产与运行阶段：确保批量生产的产品依然满足安全要求。
• 退役阶段：产品生命周期结束时的安全处理。

这里有个常见的误区。很多人以为安全生命周期只跟开发有关。其实不是。我在项目中遇到过，一个已经量产两年的ECU，因为产线上某个工艺参数漂移，导致安全机制失效。这就是生产阶段的安全活动没做到位。所以，安全生命周期是贯穿始终的。

下面这张图，是我自己总结的安全生命周期核心流程。它把概念阶段、产品开发、生产运行串在了一起。

2.2 危害分析与风险评估 (HARA)

HARA，全称 Hazard Analysis and Risk Assessment。这是功能安全里最核心、也最容易被做“虚”的一步。

HARA的目标是什么？说白了，就是找出你的系统在“不正常”的情况下，会不会对人造成伤害。比如，刹车系统在需要制动时突然失效，这就是一个危害事件。

ISO26262要求HARA必须考虑三个维度：

维度	英文	说明
严重度 (S)	Severity	伤害有多严重？轻伤、重伤、还是致命？
暴露率 (E)	Exposure	这种危险情况发生的概率有多大？
可控性 (C)	Controllability	驾驶员或相关人员能否避免伤害？

这三个维度组合起来，就得到了一个ASIL等级（Automotive Safety Integrity Level，汽车安全完整性等级）。ASIL从A到D，D是最严格的。

HARA的具体步骤，我一般这样走：

1. 功能定义：明确系统要实现什么功能。
2. 危害识别：分析功能失效会导致什么危害。
3. 场景分析：在什么运行场景下，危害会变成事故？
4. 风险评级：给每个危害事件打上S、E、C的分数。
5. ASIL确定：查表得到最终的ASIL等级。

举个例子。一个电动助力转向系统，如果“助力突然丢失”这个危害事件：

• 严重度S：高速行驶时可能造成严重事故，S=3（重伤）。
• 暴露率E：每次开车都可能遇到，E=4（高暴露）。
• 可控性C：驾驶员可以靠蛮力转向，但很困难，C=2（一般可控）。

查ISO26262的表格，S=3, E=4, C=2，最终ASIL等级是D。这意味着你需要最严格的安全措施来防止助力丢失。

2.3 安全目标定义

HARA做完之后，你手里会有一堆危害事件和对应的ASIL等级。接下来要做的，就是把这些危害事件，转化成“安全目标”。

安全目标，是系统级的安全要求。它描述的是“系统应该避免什么”，而不是“系统应该做什么”。

比如，针对上面转向助力丢失的例子，安全目标可以定义为：

安全目标有几个关键属性：

• 每个安全目标必须对应一个或多个危害事件。不能凭空捏造。
• 每个安全目标必须有明确的ASIL等级。这个等级继承自它所覆盖的危害事件中的最高ASIL。
• 安全目标必须是可验证的。你需要在系统、硬件、软件层面证明它被满足了。

我建议，在定义安全目标时，最好用“防止……发生”或“避免……”这样的句式。这样能清晰地表达出“安全”的边界在哪里。

另外，安全目标不是写出来就完事了。它需要被分解到系统架构、硬件设计、软件实现中。这个过程叫做“安全需求分配”。我们会在后面的章节详细讲。