3、概念阶段：项目定义、安全生命周期启动、危害分析与风险评估（HARA）、安全目标定义
好，咱们进入概念阶段。这是整个功能安全开发的起点，也是我经常跟团队强调的「地基」阶段。你想想看，如果地基没打好，后面盖多高的楼都悬。我个人习惯把概念阶段拆成四个核心动作：项目定义、安全生命周期启动、HARA、安全目标定义。咱们一个一个来过。
3.1 项目定义——搞清楚你到底在做什么
项目定义，说白了就是回答三个问题：
- 这个系统是干什么的？
- 它装在什么车上？
- 它跟谁打交道？
嗯，听起来简单，但我在项目中遇到过好几次，团队上来就写安全目标，结果连系统边界都没画清楚。最后HARA做到一半，发现漏了一个外部接口，整个重来。那叫一个酸爽。
项目定义要包含的内容，我列个清单：
- 系统名称和版本——别小看这个，版本号乱写后面追溯会疯掉
- 系统功能描述——用自然语言说清楚它做什么
- 系统边界——哪些是系统内的，哪些是系统外的
- 外部接口——传感器、执行器、通信总线、人机交互
- 运行模式——正常模式、故障模式、维护模式等
- 法规和标准要求——比如GB/T、ECE R79这些
3.2 安全生命周期启动——不是走形式，是真启动
安全生命周期启动，很多人觉得就是开个kick-off会议，签个字就完了。其实不是。启动的真正意义是：让整个团队知道，从这一刻起，所有开发活动都要考虑安全。
我记得有一次，项目启动会开完了，但软件团队压根没参加。结果他们按老习惯写代码，写到一半才发现ASIL等级要求，不得不返工。嗯，从那以后，我坚持安全启动会必须拉上所有相关方——硬件、软件、系统、测试、生产，一个都不能少。
安全生命周期启动要输出的东西：
- 安全计划——整个项目的安全活动时间表
- 安全角色和职责——谁是安全经理，谁是评审员，谁做验证
- 安全案例框架——你打算怎么证明系统是安全的
- 剪裁理由——如果某些活动不适用，要写清楚为什么不适用
3.3 危害分析与风险评估（HARA）——最烧脑的部分
HARA，全称Hazard Analysis and Risk Assessment。这是概念阶段最核心、也最烧脑的工作。为什么？因为你要凭空想象出所有可能出问题的情况，还要给每个情况定一个安全等级。
HARA的标准流程，我一般分五步走：
- 场景分析——列出所有可能的运行场景。比如高速巡航、城市拥堵、雨天、夜间、隧道……
- 识别危害——系统功能失效会导致什么危害？比如刹车失灵、转向卡死、误加速
- 评估风险——对每个危害，评估三个参数：严重度(S)、暴露概率(E)、可控性(C)
- 确定ASIL等级——根据S、E、C查表得到ASIL A/B/C/D或QM
- 定义安全目标——为每个危害制定一个安全目标，防止或减轻危害
这里我特别想说说评估风险这一步。很多人觉得S、E、C打分很主观，确实有主观成分。但我的经验是，只要团队讨论充分，打分结果通常八九不离十。我曾经在一个项目里，两个工程师对同一个危害的严重度打分差了两级，后来一聊才发现，一个人想的是低速场景，另一个人想的是高速场景。你看，场景定义清楚，分歧就没了。
ASIL等级查表规则，我直接给个表格：
| 严重度(S) | 暴露概率(E) | 可控性(C) | ASIL等级 |
|---|---|---|---|
| S1（轻伤） | E1（极低） | C1（易控） | QM |
| S2（重伤） | E2（低） | C2（一般） | ASIL A |
| S3（致命） | E3（中） | C3（难控） | ASIL B |
| S3（致命） | E4（高） | C3（难控） | ASIL C |
| S3（致命） | E4（高） | C3（难控） | ASIL D |
注意，这个表是简化版。实际查表要参考ISO 26262-3:2018的Table 1到Table 4。但核心逻辑就是：越严重、越常见、越难控制，等级越高。
3.4 安全目标定义——把危害翻译成要求
安全目标，就是把HARA里识别出的每个危害，翻译成一条可验证的安全要求。举个例子：
- 危害：车辆在高速行驶时，制动系统意外失效，导致无法减速
- 安全目标：制动系统在检测到主回路失效时，必须在200ms内激活冗余制动回路，确保车辆仍能减速停车
安全目标要满足几个条件：
- 可验证——你能设计测试用例来证明它实现了
- 无歧义——不同的人读它，理解应该一致
- 可追溯——能追溯到HARA里的具体危害
- 有ASIL等级——继承自HARA的分析结果
我习惯在安全目标后面加一个「安全状态」和「故障容错时间间隔」。比如：
安全目标：SG-001 制动冗余激活
ASIL等级：ASIL D
安全状态：车辆安全减速至停车
故障容错时间间隔：≤ 200ms
为什么要加这两个？因为后面做系统设计时，硬件和软件团队需要知道：出故障后，系统必须在多长时间内进入安全状态。没有这个时间约束，设计就没法落地。
3.5 概念阶段的输出物清单
最后，我整理一下概念阶段要产出的东西。方便你对照检查：
- 项目定义文档（含系统上下文图）
- 安全计划（含安全生命周期活动表）
- HARA分析报告（含场景、危害、S/E/C评估、ASIL等级）
- 安全目标列表（含安全状态和故障容错时间间隔）
- 安全案例框架（初步版本）
嗯，概念阶段的内容就这些。说白了，这个阶段的核心就是想清楚、写清楚、对齐清楚。后面所有的开发工作，都是基于这个阶段的结果展开的。所以，别急，慢慢来，把地基打扎实了。
下一章，咱们进入系统层面，聊聊系统级安全设计。到时候会讲到安全架构、安全机制、以及怎么把安全目标分解到子系统。敬请期待。