4. 功能安全概念(FSR)：安全目标定义、功能安全需求导出、安全机制分配
好，咱们进入功能安全概念阶段。说白了，FSR 就是把前面 Hazard Analysis 的结果，翻译成工程团队能看懂、能执行的具体要求。
我个人习惯把这一步叫做「从危险到需求的桥梁」。你想想看，HARA 分析完了，我们得到一堆 ASIL 等级和危险事件。但这些东西怎么变成工程师能写进代码、画进原理图的东西？嗯，这就是 FSR 要解决的问题。
4.1 安全目标定义：从危险到目标的转化
安全目标，英文叫 Safety Goal，简称 SG。它是对每个危险事件提出的顶层安全要求。
定义安全目标时，我一般遵循三个原则：
- 每个危险事件至少对应一个安全目标。但一个安全目标可以覆盖多个危险事件。
- 安全目标要描述「避免什么」，而不是「做什么」。比如「避免显示错误的车速信息」，而不是「车速显示要正确」。
- 安全目标要包含 ASIL 等级。这个等级直接继承自 HARA 分析结果。
举个例子：
假设 HARA 分析发现：HUD 显示的车速比实际车速高 20km/h，导致驾驶员误判，引发追尾风险。ASIL 等级为 B。
那么安全目标可以定义为：
SG-01: 避免 HUD 显示的车速信息与实际车速偏差超过 5km/h [ASIL B]
我在项目中遇到过一个问题：安全目标写得太笼统。比如「避免显示错误信息」，这等于没说。错误信息有很多种——亮度错误、位置错误、内容错误。每个错误的风险等级可能完全不同。所以，安全目标一定要具体到「什么信息、什么偏差、什么后果」。
4.2 功能安全需求导出：把目标拆成可执行的任务
安全目标定义好了，接下来就是导出功能安全需求，也就是 Functional Safety Requirement，简称 FSR。
FSR 是安全目标的细化。一个安全目标通常会拆成多个 FSR。每个 FSR 要描述：
- 什么条件下（比如车速 > 30km/h）
- 什么行为（比如检测到车速信号异常）
- 什么响应（比如切换到默认安全车速显示）
- 什么时间要求（比如 100ms 内完成切换）
我常用的导出方法是「5W1H」法：
| 要素 | 说明 | 示例 |
|---|---|---|
| What | 要做什么 | 检测车速信号有效性 |
| When | 什么时候做 | 每次接收到 CAN 车速报文时 |
| Where | 在哪个模块做 | HUD 主控 MCU |
| Who | 谁负责 | 软件团队 |
| Why | 为什么需要 | 避免显示错误车速 |
| How | 怎么做 | CRC 校验 + 超时检测 |
拿刚才的 SG-01 举例，可以导出以下 FSR：
FSR-01: HUD 系统应每 20ms 校验一次 CAN 总线上的车速信号 CRC [ASIL B]
FSR-02: 若连续 3 次 CRC 校验失败，HUD 应在 100ms 内切换至默认安全车速显示 [ASIL B]
FSR-03: 默认安全车速显示值应为 0 km/h，并伴有闪烁警告图标 [ASIL B]
FSR-04: 车速信号源切换（如从 CAN 切换到备用信号）应在 50ms 内完成 [ASIL B]
我的经验：FSR 不要写得太细，细到具体寄存器或 API 调用。那是技术安全需求（TSR）的事。FSR 要保持在「系统级」和「功能级」，让不同团队（硬件、软件、光学）都能理解。
4.3 安全机制分配：谁来做、怎么做
安全机制，就是用来检测故障、防止违反安全目标的具体手段。分配安全机制时，我习惯问自己三个问题：
- 这个故障能被检测到吗？——如果不能，那就要考虑故障容错设计。
- 检测到之后怎么办？——进入安全状态，还是降级运行？
- 谁来执行？——硬件、软件，还是两者配合？
常见的 HUD 安全机制分类：
| 安全机制类型 | 示例 | 分配对象 |
|---|---|---|
| 检测机制 | CRC 校验、超时检测、回读校验 | 软件 |
| 响应机制 | 切换到安全状态、显示警告 | 软件 + 硬件 |
| 容错机制 | 双通道冗余、看门狗 | 硬件 |
| 诊断机制 | 开机自检、周期性自检 | 软件 |
举个例子，针对 FSR-02（CRC 校验失败后的响应），我们可以分配以下安全机制：
SM-01: 软件 CRC 校验模块 [ASIL B, 软件实现]
- 检测对象: CAN 车速信号
- 检测方法: 每帧报文计算 CRC 并与发送端对比
- 覆盖故障: 数据传输错误、位翻转
SM-02: 安全状态切换模块 [ASIL B, 软件 + 硬件]
- 触发条件: 连续 3 次 CRC 失败
- 执行动作: 清除显示缓冲区，写入默认安全值
- 硬件支持: 独立电源域保证切换不受主电源干扰
SM-03: 看门狗定时器 [ASIL B, 硬件]
- 监控对象: 主控 MCU 运行状态
- 超时动作: 硬件复位，强制进入安全状态
我曾经踩过一个坑：安全机制分配时，只考虑了「检测」和「响应」，忽略了「诊断」。结果有一次 CRC 校验模块本身出了故障，但没有任何机制能检测到「检测模块失效」这件事。后来我学乖了，每个安全机制都要配一个「自检机制」——说白了，就是「检查检查的人」。
4.4 一个完整的 FSR 示例（HUD 亮度异常）
咱们来个完整的例子，把前面讲的串起来。
场景：HUD 亮度异常升高，夜间行驶时导致驾驶员眩目，引发事故风险。HARA 分析 ASIL 等级为 A。
安全目标：
SG-02: 避免 HUD 显示亮度超过环境光自适应亮度的 120% [ASIL A]功能安全需求：
FSR-05: HUD 应每 100ms 读取一次环境光传感器数据 [ASIL A]
FSR-06: HUD 应每 100ms 计算一次目标亮度值，并与当前亮度对比 [ASIL A]
FSR-07: 若当前亮度超过目标亮度 20%，HUD 应在 200ms 内将亮度降低至目标值 [ASIL A]
FSR-08: 环境光传感器故障时，HUD 应切换至预设的安全亮度（50% 最大亮度）[ASIL A]安全机制分配：
SM-04: 环境光传感器有效性检测 [ASIL A, 软件]
- 检测方法: 传感器自检状态位 + 数值范围检查（0-100000 lux）
- 故障响应: 标记传感器故障标志位
SM-05: 亮度闭环控制 [ASIL A, 软件 + 硬件]
- 控制逻辑: PID 控制器，目标亮度与实际亮度偏差 < 5%
- 硬件支持: PWM 调光电路，分辨率 10bit
SM-06: 亮度超限保护 [ASIL A, 硬件]
- 检测对象: 实际输出亮度
- 保护动作: 硬件比较器检测到亮度超过阈值，直接切断 PWM 输出
- 恢复条件: 系统复位我个人习惯：每个安全机制分配完后，一定要做一次「覆盖度检查」。拿一张表，左边列所有可能的故障模式，右边列对应的安全机制。如果有故障模式找不到对应的安全机制，那就是遗漏了。这个习惯帮我避免了好几次设计返工。
好了，FSR 阶段的核心内容就是这些。说白了，就是「定义目标 → 拆成需求 → 分配机制」三步走。下一章咱们会讲技术安全概念（TSR），那是把 FSR 进一步细化到具体的技术实现层面。到时候见。