4. 功能安全概念（FSC）：安全目标定义、功能安全需求导出、安全机制分配
好，我们进入功能安全概念阶段。说白了，FSC 就是把上一章做的 Hazard Analysis 结果，翻译成工程团队能看懂、能执行的技术语言。
我个人习惯把 FSC 比作「翻译器」——左边是危害分析输出的 ASIL 等级和危险事件，右边是系统工程师要写的需求文档。中间要完成三件事：定安全目标、导功能安全需求、分安全机制。
核心逻辑： 危害 → 安全目标（SG） → 功能安全需求（FSR） → 安全机制分配。每一步都是细化与落地。
4.1 安全目标（Safety Goal）定义
安全目标是顶层安全要求。它直接对应每个危害事件，描述「系统要避免什么」。注意，安全目标不描述「怎么做」，只描述「要达成什么状态」。我在项目中见过不少工程师把安全目标写成技术方案，这是典型的错误。
举个例子，电驱系统最常见的危害：
- 危害： 电机意外输出扭矩
- 安全目标： 避免非预期的电机扭矩输出（ASIL C）
再比如：
- 危害： 高压母线过压导致绝缘击穿
- 安全目标： 避免高压系统过压（ASIL B）
安全目标有几个关键属性：
| 属性 | 说明 | 示例 |
|---|---|---|
| ID | 唯一编号，便于追溯 | SG-01 |
| 描述 | 清晰、无歧义的安全状态 | 避免非预期扭矩输出 |
| ASIL | 继承自危害分析 | ASIL C |
| 安全状态 | 系统进入何种安全模式 | 主动短路、关断高压 |
| FTTI | 故障容错时间间隔 | ≤ 100 ms |
我的经验： 安全目标的数量一般控制在 5~15 个。太多说明危害分析粒度太细，太少说明遗漏了关键场景。我曾经在一个项目里只写了 3 个安全目标，评审时被安全经理直接打回——因为「非预期加速」和「非预期减速」其实是两个不同的安全目标。
4.2 功能安全需求（FSR）导出
安全目标定好了，下一步是导出功能安全需求。FSR 是安全目标的细化，它开始描述「系统需要具备什么能力」来避免或控制危害。
我习惯用「分解法」来做这件事：
- 检测需求： 系统如何发现故障？
- 响应需求： 发现故障后做什么？
- 容错需求： 故障存在时系统如何保持安全？
- 降级需求： 如果无法完全容错，如何降级？
举个例子，针对安全目标「避免非预期扭矩输出」，可以导出以下 FSR：
- FSR-01： 系统应能检测扭矩指令与反馈偏差超过阈值（ASIL C）
- FSR-02： 检测到偏差后，应在 50ms 内关断 PWM 输出（ASIL C）
- FSR-03： 关断后系统应进入主动短路状态（ASIL C）
- FSR-04： 主动短路状态下，母线电压应保持在安全范围内（ASIL B）
你想想看，FSR 和安全目标之间是多对一的关系。一个安全目标通常会导出 3~8 个 FSR。太少说明需求粒度不够，评审时容易被挑战。
避坑指南： 我曾经在一个项目中，FSR 写得过于具体，直接写了「使用旋变传感器检测转子位置」。这其实是技术方案，不是需求。正确的写法是「系统应能检测转子位置，精度满足扭矩控制要求」。至于用什么传感器，那是后面设计阶段的事。
4.3 安全机制分配
FSR 写完后，就要开始分配安全机制了。安全机制是具体的技术手段，用来实现 FSR。这一步是 FSC 中最考验经验的环节。
常见的电驱系统安全机制包括：
| 安全机制 | 适用场景 | 典型实现 |
|---|---|---|
| 监控比较器 | 扭矩指令与反馈偏差 | 硬件比较器 + 软件监控 |
| 看门狗 | 程序跑飞检测 | 外部看门狗 IC |
| 主动短路 | 逆变器故障保护 | 下桥臂全部导通 |
| 冗余采样 | 传感器故障检测 | 双路 ADC 采样 |
| 互锁逻辑 | 防止上下桥臂直通 | 硬件死区时间 |
分配安全机制时，我一般遵循几个原则：
- 独立性： 安全机制不能和被监控的功能共用同一资源。比如，不能用同一个 CPU 核既跑控制算法又跑监控。
- 多样性： 尽量用不同的技术手段实现冗余。比如，软件监控 + 硬件比较器。
- 覆盖率： 安全机制要能覆盖目标故障模式。比如，针对传感器短路故障，冗余采样能覆盖，但单一采样不行。
关键点： 安全机制分配后，要形成「安全机制矩阵」，明确每个安全机制覆盖哪些 FSR、检测哪些故障、响应时间是多少。这是 FSC 阶段最重要的交付物之一。
4.4 FSC 阶段的知识体系
下面这张图总结了 FSC 阶段的核心逻辑：
4.5 实战中的常见问题
嗯，这里我要多说几句。FSC 阶段最容易出问题的几个地方：
- 安全目标太抽象： 比如「保证系统安全」这种话，评审时会被直接打回。安全目标必须可验证、可测试。
- FSR 遗漏降级场景： 很多团队只写了「检测故障→关断」，但没写「关断后系统怎么恢复」。我曾经在一个项目中，安全机制触发后系统直接锁死，客户的车只能拖回服务站——这显然不合理。
- 安全机制分配不考虑成本： 不是所有安全机制都要用最高等级的冗余。对于 ASIL B 的需求，用软件监控就够了；对于 ASIL D，才需要硬件冗余。
我的建议： FSC 阶段一定要做「安全机制可行性分析」。每个安全机制都要回答三个问题：能不能检测到目标故障？响应时间够不够？会不会引入新的危害？这三个问题答不上来，就不要往下走。
好了，FSC 阶段的内容就这些。记住，安全目标、功能安全需求、安全机制分配，这三步是环环相扣的。前面没做好，后面设计阶段全是坑。