4. 功能安全概念（FSC）：安全目标定义、功能安全需求导出、安全机制分配
好，咱们进入功能安全概念阶段。说白了，这就是把上一章做的HARA分析结果，真正落地成可执行的安全方案。
我个人习惯把FSC看作一座桥——桥的一头是危害分析和风险评估，另一头是技术安全需求。桥本身要回答三个问题：我们要防什么？怎么防？谁来防？
核心逻辑链：
危害事件 → 安全目标(SG) → 功能安全需求(FSR) → 安全机制分配 → 安全机制(SM)
4.1 安全目标定义——从危害到目标的转化
安全目标是什么？一句话：为每个危害事件定义的、最高层级的安全要求。
每个安全目标都对应一个危害事件，并且要继承它的ASIL等级。举个例子：
| 危害事件 | 安全目标 | ASIL |
|---|---|---|
| EPS非预期转向导致车辆偏离车道 | EPS系统应防止非预期的转向角度输出 | ASIL D |
| 制动助力失效导致制动距离增加 | 制动助力系统应在失效时提供可接受的助力 | ASIL C |
| ACC误加速导致追尾 | ACC系统应防止非预期的正加速度 | ASIL B |
写安全目标时，有几个坑我踩过：
- 目标太宽泛——比如“系统要安全”，这等于没说。要具体到“防止什么失效、在什么条件下”。
- ASIL等级不对——安全目标的ASIL必须和危害事件的ASIL一致，不能随意降级。
- 忽略了安全状态——每个安全目标都要明确：失效发生时，系统应该进入什么安全状态？
我的经验：安全目标的数量一般控制在5~15个。太少说明分析粒度不够，太多说明HARA阶段把危害拆得太碎了。我曾经在一个项目里搞出30多个安全目标，结果评审时被怼得体无完肤——太多目标反而让后续的验证工作失控。
4.2 功能安全需求导出——把目标翻译成需求
安全目标定好了，下一步就是导出功能安全需求。这一步的核心是：把“要防什么”翻译成“系统应该做什么/不做什么”。
我一般用这个模板来写FSR：
FSR-XXX: [系统/功能] 应 [动作/行为] 当 [条件/事件] 发生时，以达到 [安全目标引用]。
ASIL: [等级]
安全状态: [描述]
FTTI: [容错时间间隔]
举个例子，从上面EPS的安全目标导出FSR：
- FSR-001：EPS控制器应检测转向角度传感器的合理性故障，当检测到故障时，应在100ms内进入降级模式，限制最大转向助力为50%。
ASIL: D | 安全状态: 降级助力模式 | FTTI: 100ms - FSR-002：EPS控制器应监控扭矩传感器的信号偏差，当偏差超过±5%时，应触发故障响应。
ASIL: D | 安全状态: 降级助力模式 | FTTI: 50ms
这里要注意几个关键属性：
| 属性 | 说明 | 常见错误 |
|---|---|---|
| ASIL等级 | 继承自安全目标，不能降低 | 随意降级，以为“检测逻辑简单就降级” |
| FTTI | 从失效发生到危害发生的时间窗口 | 不写FTTI，导致后续验证没有时间基准 |
| 安全状态 | 系统进入的降级或关闭模式 | 只写“进入安全状态”，不描述具体行为 |
| 故障检测时间 | 从故障发生到被检测到的时间 | 检测时间大于FTTI，等于白检测 |
避坑指南：我曾经在一个项目中，FSR写了“系统应检测传感器故障”，但没有定义检测时间。结果测试时发现，检测算法跑完需要200ms，而FTTI只有150ms。这等于安全机制还没生效，危害已经发生了。所以，每个FSR都要明确时间约束。
4.3 安全机制分配——谁来做？怎么做？
FSR定义好了，接下来要分配安全机制。安全机制就是具体的技术手段，用来检测、避免或控制故障。
我习惯把安全机制分成三类：
- 检测机制：发现故障（如看门狗、CRC校验、信号范围检查）
- 响应机制：故障后的动作（如降级模式、关闭输出、切换到冗余通道）
- 避免机制：从设计上防止故障发生（如冗余设计、物理隔离）
分配安全机制时，要回答三个问题：
- 谁来检测？——是软件自检、硬件监控，还是外部看门狗？
- 检测到什么程度？——覆盖率多少？能覆盖哪些故障模式？
- 检测到之后怎么办？——进入什么安全状态？需要多长时间？
举个例子，还是EPS系统：
| FSR | 安全机制 | 分配对象 | 覆盖率 |
|---|---|---|---|
| FSR-001: 检测转向角度传感器故障 | SM-001: 传感器信号合理性检查（范围+变化率） | EPS软件模块 | 90% |
| FSR-002: 监控扭矩传感器偏差 | SM-002: 双扭矩传感器交叉比较 | 硬件冗余+软件比较 | 99% |
| FSR-003: 故障后进入降级模式 | SM-003: 限制助力输出+点亮故障灯 | EPS软件+仪表盘 | — |
分配时有个原则：一个安全目标可以由多个安全机制共同覆盖，但每个安全机制都要明确它的ASIL能力。如果一个安全机制本身达不到目标ASIL，就需要组合多个机制来满足。
我的习惯：我会在FSC阶段画一张安全机制分配矩阵图，横轴是安全目标，纵轴是安全机制，交叉点标注覆盖关系和ASIL等级。这样评审时一目了然，也方便后续做安全分析（比如FMEA、FTA）。
4.4 FSC知识结构总览
下面这张图是我自己总结的FSC核心逻辑，每次做项目都会拿出来对照：
4.5 常见问题与避坑
做FSC这么多年，有几个问题反复出现：
- 安全目标和功能安全需求混淆——安全目标是“防什么”，功能安全需求是“怎么做”。我见过有人把“系统应检测传感器故障”写成安全目标，这其实是FSR。
- 安全机制分配不考虑独立性——如果一个安全机制和被监控的功能运行在同一个软件模块里，那它可能无法独立检测故障。我曾经在一个项目里，把看门狗和主功能放在同一个MCU上，结果评审时被指出：如果MCU挂了，看门狗也挂了，等于没检测。
- 忽略FTTI的级联关系——多个安全机制串联时，总检测时间要小于FTTI。比如传感器检测用了50ms，逻辑判断用了30ms，执行响应用了40ms，加起来120ms，如果FTTI是100ms，那就超了。
避坑指南：我曾经在一个ADAS项目中，安全机制分配时只考虑了单一故障，没考虑多故障同时发生的情况。结果FMEA分析发现，两个独立的传感器同时漂移时，现有的安全机制检测不到。后来不得不增加一个冗余的校验机制。所以，分配安全机制时，至少要做一次FMEA来验证覆盖率。
好了，FSC阶段的核心内容就是这些。记住一句话：安全目标要准，功能安全需求要细，安全机制分配要实。这三步走扎实了，后面的技术安全概念才能站得住脚。