4. 功能安全概念（FSC）：安全目标定义、功能安全需求导出、安全机制分配
好，我们进入功能安全概念阶段。说白了，FSC 就是把上一章做的 HARA 分析结果，转化成实实在在的工程要求。我个人习惯把这一步叫做「从危险到需求的翻译过程」。你想想看，HARA 告诉你「这里会出问题」，FSC 就要告诉你「怎么解决这个问题」。
4.1 安全目标定义：给危险画红线
安全目标（Safety Goal, SG）是什么？就是最高层级的安全要求。它回答一个核心问题：系统必须避免什么？
我在项目中遇到过不少新手，上来就写「系统要安全」。这太模糊了。安全目标必须具体到某个危险事件。举个例子：
正确写法：「避免因车速显示错误导致驾驶员误判，造成碰撞。」
错误写法：「仪表显示要准确。」
每个安全目标都要继承 HARA 中的 ASIL 等级。比如上面那个例子，如果 HARA 分析出来是 ASIL B，那这个 SG 的 ASIL 就是 B。嗯，这里要注意：安全目标的数量不宜过多。我见过一个项目写了 40 多个 SG，结果评审时大家全懵了。一般来说，一个中等复杂度的智能座舱系统，10-15 个 SG 比较合理。
安全目标的典型结构包括：
- SG ID：唯一编号，比如 SG-01
- 描述：一句话说清楚要避免什么
- ASIL 等级：从 HARA 继承
- 关联的危险事件：对应 HARA 中的哪个 Hazard
- 安全状态：系统触发安全机制后进入的状态
| SG ID | 描述 | ASIL | 安全状态 |
|---|---|---|---|
| SG-01 | 避免车速显示值高于实际值 10% 以上 | B | 显示降级为「---」，提示驾驶员 |
| SG-02 | 避免倒车影像延迟超过 200ms | A | 黑屏并显示「摄像头故障」 |
| SG-03 | 避免驾驶员分心监测系统误报警导致驾驶员分心 | C | 关闭报警，记录故障 |
我的经验：写 SG 时一定要拉上系统架构师一起评审。我曾经自己闷头写了 20 个 SG，结果架构师一看，说其中 5 个在架构层面根本不可能独立实现，最后合并了。早沟通，少返工。
4.2 功能安全需求导出：把目标拆成任务
安全目标定好了，接下来就是导出功能安全需求（Functional Safety Requirements, FSR）。这一步说白了就是：为了实现这个 SG，系统需要做什么？
每个 SG 可以导出多个 FSR。我习惯用「自上而下」的方法：先想系统层面要做什么，再往下拆到子系统、组件。举个例子，对于 SG-01（避免车速显示错误）：
- FSR-01.1：车速传感器信号必须在 10ms 内被 ECU 读取（ASIL B）
- FSR-01.2：ECU 必须对车速信号进行合理性检查，偏差超过 5% 时触发故障（ASIL B）
- FSR-01.3：显示驱动芯片必须在收到错误信号后 50ms 内切换至安全状态（ASIL B）
你看，每个 FSR 都继承了 SG 的 ASIL 等级。但这里有个坑：FSR 的 ASIL 可以比 SG 低吗？ 理论上可以，但需要充分论证。比如某个 FSR 只负责监控，不参与控制，那它的 ASIL 可以降级。不过我个人建议，除非有非常明确的分解理由，否则保持继承关系最安全。
避坑指南：我曾经在一个项目中，把 FSR 写得像软件需求一样细，比如「变量 X 的值必须在 0-100 之间」。结果开发团队说这根本不是功能安全需求，这是软件实现细节。FSR 应该停留在系统功能层面，不要过早陷入实现细节。
导出 FSR 时，我常用的模板是：
FSR-ID: FSR-01.1
描述: 系统必须能在 10ms 内检测到车速传感器信号丢失
ASIL: B
来源: SG-01
验证方法: 测试 + 时序分析
安全机制: 看门狗定时器 + 信号超时检测4.3 安全机制分配：谁来干活？
安全机制（Safety Mechanism）就是具体的技术手段。FSR 告诉你「要做什么」，安全机制告诉你「怎么做」。分配安全机制时，我一般遵循三个原则：
- 独立性原则：安全机制不能依赖它要保护的功能。比如你不能用同一个软件模块既做显示又做显示错误检测。
- 多样性原则：对于高 ASIL（C/D）的需求，尽量用不同的技术手段实现冗余。比如硬件看门狗 + 软件自检。
- 及时性原则：安全机制必须在故障容忍时间间隔（FTTI）内完成检测和响应。
常见的智能座舱安全机制包括：
| 安全机制 | 适用场景 | 典型 ASIL |
|---|---|---|
| 看门狗定时器 | 检测软件跑飞或死锁 | B/C |
| CRC 校验 | 检测数据传输错误 | A/B |
| 双核锁步 | 检测 CPU 硬件故障 | C/D |
| 合理性检查 | 检测传感器信号异常 | B |
| 故障注入测试 | 验证安全机制有效性 | 所有等级 |
分配时，我会画一个矩阵：左边是 FSR，上面是候选安全机制，交叉处打勾。这样一眼就能看出哪个 FSR 还没有被覆盖。嗯，这个矩阵在功能安全评审时特别好用，评审专家一看就明白你的思路。
举个例子：对于 FSR-01.2（车速信号合理性检查），我分配了两种安全机制：
- 机制 A：软件层面，比较车速信号与轮速信号的差值，超过阈值则报错
- 机制 B：硬件层面，用独立的 ADC 通道采样同一传感器，做交叉验证
机制 A 覆盖了传感器漂移，机制 B 覆盖了 ADC 通道故障。两者互补，ASIL B 的要求就满足了。
4.4 一个完整的 FSC 示例
最后，我拿一个智能座舱中常见的「驾驶员分心监测」功能，给你看看完整的 FSC 长什么样：
- SG-03：避免驾驶员分心监测系统误报警导致驾驶员分心（ASIL C）
- FSR-03.1：系统必须在 100ms 内检测到摄像头遮挡或污损（ASIL C）
- FSR-03.2：系统必须在检测到故障后 200ms 内停止报警输出（ASIL C）
- FSR-03.3：系统必须记录故障日志，供售后分析（ASIL A，可降级）
安全机制分配：
| FSR | 安全机制 | 说明 |
|---|---|---|
| FSR-03.1 | 摄像头自检 + 帧率监控 | 每帧检查图像质量，帧率低于 15fps 则报错 |
| FSR-03.2 | 独立看门狗 + 报警输出使能信号 | 看门狗超时则强制切断报警输出 |
| FSR-03.3 | 非易失性存储器 + 日志循环覆盖 | 故障码写入 EEPROM，最多保存 100 条 |
我的习惯：FSC 文档写完后，我会做一次「纸上测试」。就是模拟一个故障，然后沿着 FSR 和安全机制走一遍，看能不能在 FTTI 内到达安全状态。这一步能发现很多逻辑漏洞。我曾经用这个方法发现了一个时序问题——安全机制检测到了故障，但响应路径上有个 500ms 的软件延时，差点超了 FTTI。
好了，FSC 的核心内容就是这些。记住一句话：安全目标是「不做什么」，功能安全需求是「要做什么」，安全机制是「怎么做」。下一章我们讲技术安全概念（TSC），到时候会把这些需求进一步细化到硬件和软件层面。