3. 概念阶段：HARA、安全目标与功能安全概念
概念阶段，说白了就是回答三个问题：系统会不会出事？出了事有多严重？我们怎么防止它出事？
我个人习惯把这一阶段叫做「打地基」。地基没打好，后面所有工作都是空中楼阁。我见过太多项目，HARA 做得马马虎虎，结果到了后期才发现安全目标定得太宽泛，功能安全概念根本落不了地。嗯，那时候再回头改，成本可就大了去了。
3.1 危害分析与风险评估（HARA）
HARA 是整个功能安全流程的起点。它的目标很明确：找出系统所有可能的危害，并评估每个危害的风险等级。
你想想看，一辆车在路上跑，可能出什么故障？转向失灵、刹车失效、加速不受控……这些都属于危害。但危害本身不等于风险。风险 = 危害的严重度 × 发生概率 × 可控性。
ISO 26262 把这三个维度量化成了三个参数：
| 参数 | 全称 | 等级范围 | 含义 |
|---|---|---|---|
| S | Severity（严重度） | S0 ~ S3 | 对人员伤害的严重程度 |
| E | Exposure（暴露概率） | E0 ~ E4 | 危害场景发生的频率 |
| C | Controllability（可控性） | C0 ~ C3 | 驾驶员或其他人员避免伤害的能力 |
这三个参数组合起来，就得到了 ASIL（汽车安全完整性等级）。ASIL 分为 A、B、C、D 四个等级，D 是最严格的。如果三个参数都是最低，那就是 QM（质量管理级），不需要按功能安全流程开发。
ASIL 等级判定表（简化版）
ASIL = f(S, E, C)。举个例子：
- S3 + E4 + C3 → ASIL D（最严格）
- S2 + E3 + C2 → ASIL B
- S1 + E2 + C1 → ASIL A
- S0 或 E0 或 C0 → QM
我在项目中遇到过一件事：一个转向系统的 HARA，团队把某个场景的 E 值定成了 E3，结果评审时发现实际使用中那个场景几乎不会发生。最后改成了 E2，ASIL 从 D 降到了 C，省了不少开发成本。所以 HARA 不是走过场，每个参数都要有数据支撑。
3.2 安全目标定义
HARA 做完之后，每个危害都会对应一个或多个 安全目标（Safety Goal）。安全目标是一句顶层的安全要求，它描述的是「系统不能做什么」或者「系统必须做什么」。
举个例子：
- 危害：车辆在高速行驶时突然非预期加速。
- 安全目标：车辆应防止非预期的加速，ASIL D。
安全目标有几个关键属性：
- 每个安全目标必须有一个唯一的 ID，方便追溯。
- 必须指定 ASIL 等级，这个等级决定了后续开发流程的严格程度。
- 必须定义安全状态，也就是系统在检测到故障后应该进入什么状态。
- 必须定义容错时间间隔（FTTI），从故障发生到系统进入安全状态的最大允许时间。
我的经验：安全目标不要写得太具体，也不要太抽象。太具体会限制设计自由度，太抽象又没法验证。我一般会遵循「一句话原则」——安全目标用一句话能说清楚，那就是好的。
3.3 功能安全概念
安全目标定义好了，接下来就是 功能安全概念（Functional Safety Concept, FSC）。FSC 是把安全目标分解成具体的功能安全要求，分配给系统的各个组成部分。
说白了，安全目标是「做什么」，功能安全概念是「怎么做」。
FSC 包含以下几个核心要素：
- 故障检测机制：怎么发现故障？比如传感器自检、信号合理性检查。
- 故障响应机制：发现故障后怎么办？比如降级模式、紧急停车。
- 安全机制分配：这些机制由哪个硬件或软件模块实现？
- 安全状态定义：系统进入什么状态才算安全？
- 冗余与容错策略：是否需要双通道？是否需要投票机制？
我曾经在一个项目中，安全目标是「防止非预期加速」，ASIL D。我们设计的 FSC 是这样的：
- 主控制器和监控控制器双通道设计，两个通道互相校验。
- 如果两个通道的扭矩指令偏差超过阈值，系统立即进入安全状态——切断动力输出。
- 安全状态定义为「零扭矩输出」，FTTI 为 100ms。
这个方案听起来简单，但落地时遇到了不少坑。比如两个通道的时钟不同步，导致偏差阈值经常误触发。后来我们加了同步机制，才把问题解决。
避坑指南：我曾经见过一个团队，FSC 写得天花乱坠，但到了系统设计阶段发现根本实现不了。为什么？因为他们没有考虑硬件资源的限制。比如要求 10ms 内完成故障检测，但选用的 MCU 根本跑不了那么快。所以 FSC 一定要和系统架构师、硬件工程师一起评审，确保可落地。
3.4 概念阶段的知识体系
下面这张图是我自己整理的，把概念阶段的核心逻辑串起来了。你一看就明白：
这张图从左到右看，就是概念阶段的完整流程。每一步的输出都是下一步的输入，环环相扣。我建议你在实际项目中，也画一张类似的图，贴在团队的白板上，大家每天看一眼，思路就清晰了。
3.5 概念阶段的常见误区
做了这么多年功能安全，我总结了几条概念阶段的常见坑：
- HARA 做得太粗：只分析了正常驾驶场景，忽略了维修、充电、拖车等非正常场景。
- 安全目标写成了功能要求：比如「系统应能在 100ms 内切断动力」，这是功能要求，不是安全目标。安全目标应该是「防止非预期加速」。
- FSC 不考虑系统边界：只写了系统内部怎么做，没考虑和外部系统（比如 CAN 总线、其他 ECU）的交互。
- ASIL 等级随意定：没有数据支撑，全靠拍脑袋。结果要么过度设计浪费成本，要么设计不足留下隐患。
我的建议：概念阶段一定要做评审。HARA 评审、安全目标评审、FSC 评审，一个都不能少。评审时拉上系统工程师、硬件工程师、软件工程师、测试工程师，甚至项目经理。不同视角能发现很多你一个人看不到的问题。
嗯，概念阶段的内容就这些。记住一句话：概念阶段花的时间越多，后面阶段踩的坑越少。 我见过太多项目，概念阶段赶进度，结果到了系统集成阶段才发现安全目标有漏洞，那时候改起来，成本至少是概念阶段的 10 倍。