4、功能安全概念( FSC )：功能安全概念定义、安全状态、安全机制初步分配
好，我们进入第4章。前面我们把危害分析和风险评估（HARA）做完了，ASIL等级也定下来了。那下一步干什么？说白了，就是要把那些「安全目标」翻译成具体的技术语言——这就是功能安全概念（FSC）。
我个人习惯把FSC叫做「承上启下」的一层。上面接着安全目标，下面接着技术安全概念（TSC）。你FSC写得糊里糊涂，后面TSC和硬件软件设计肯定要翻车。我在项目里见过太多次了，安全目标写得漂漂亮亮，一到FSC就开始「差不多先生」，最后测试阶段发现安全机制根本覆盖不了——那才叫一个头两个大。
4.1 功能安全概念到底在定义什么？
先别急着看标准条文。咱们用大白话捋一遍：
- 安全目标：告诉你「要避免什么坏事发生」
- 功能安全概念：告诉你「怎么靠系统功能来避免那件坏事」
举个例子。安全目标是：「踩刹车时，刹车灯必须在200ms内点亮，避免追尾。」那FSC就要回答：谁来检测刹车踏板信号？谁来控制灯？如果检测到故障怎么办？
核心三要素：
- 安全状态（Safe State）—— 出问题后系统应该待在什么状态？
- 故障容错时间间隔（FTTI）—— 从故障发生到进入安全状态，最多能等多久？
- 安全机制（Safety Mechanism）—— 用什么手段检测故障、触发安全状态？
嗯，这里要注意：FSC不涉及具体硬件选型或软件算法。它只定义「功能层面的策略」。比如「用冗余传感器检测油门卡滞」是FSC层面的描述；「用两颗霍尔传感器+SPI通信+看门狗定时器」那是TSC的事。
4.2 安全状态：不是只有「断电」这一条路
很多工程师一提到安全状态，第一反应就是「切断电源」。我刚开始做EPS（电动助力转向）项目时也这么想，结果被功能安全评审专家怼了回来——你想想看，高速上突然切断转向助力，驾驶员会怎样？
安全状态其实分好几种：
| 安全状态类型 | 典型场景 | 说明 |
|---|---|---|
| 降级模式 | EPS助力降低50% | 系统还能工作，但性能受限 |
| 故障静默 | ECU停止输出PWM | 完全切断执行器驱动 |
| 维持当前状态 | 制动踏板位置保持 | 不改变输出，等待驾驶员干预 |
| 紧急操作模式 | 自动紧急制动介入 | 系统主动接管，避免危险 |
我曾经在一个VCU项目中踩过坑：安全目标要求「电池过温时切断高压」，我们直接设计成断开主继电器。结果测试发现，断开瞬间的母线电压尖峰把IGBT模块打穿了。后来改成「先降功率→再断开预充→最后断开主继电器」的三步安全状态——这才是合理的。
避坑指南：
我曾经见过一个团队，把所有安全目标的安全状态都写成「系统下电」。结果评审时被问到：「如果下电过程中通信丢失，你怎么保证下电指令被执行？」——答不上来。安全状态一定要定义到可验证的层级，比如「输出电压<5V」「电机扭矩<0.5Nm」这种可测量的条件。
4.3 安全机制初步分配：谁来做？做什么？
安全机制分配，就是把安全目标拆解到具体的系统功能上。我习惯用一张表来梳理：
| 安全目标ID | ASIL | 检测机制 | 响应机制 | 安全状态 | FTTI |
|---|---|---|---|---|---|
| SG-01 | ASIL D | 扭矩传感器自检 | 切断助力 | 降级50% | 100ms |
| SG-02 | ASIL B | 看门狗超时检测 | 复位MCU | 故障静默 | 500ms |
| SG-03 | ASIL C | CAN心跳丢失检测 | 进入安全状态 | 维持当前扭矩 | 200ms |
这里有个关键点：ASIL等级决定了安全机制的独立性要求。ASIL D的安全机制，通常需要独立于功能实现的硬件或软件。比如你用一个MCU做控制，另一个MCU做监控——这叫「1oo2架构」。ASIL B的话，可能软件层面的多样性就够用了。
我个人建议，在FSC阶段不要纠结于具体实现。你只需要回答三个问题：
- 检测：故障怎么被感知？（传感器自检？通信超时？逻辑自洽？）
- 决策：检测到故障后，谁来决定进入哪个安全状态？（硬件逻辑？软件状态机？）
- 执行：安全状态怎么被激活？（切断电源？降级输出？报警提示？）
4.4 FSC的输出物长什么样？
FSC的交付物，通常是一份功能安全概念文档。里面至少包含：
- 每个安全目标对应的FSC描述
- 安全状态定义及进入/退出条件
- FTTI分配
- 安全机制初步分配表
- 系统架构的初步安全相关约束
我见过最糟糕的FSC文档，就是把安全目标复制粘贴了一遍，然后加了一句「通过软件实现」。这种文档在评审会上会被直接打回。好的FSC文档，应该让一个没参与过HARA的工程师读完后，能清楚知道「这个系统在什么故障下、做什么反应、达到什么状态」。
小技巧：
写FSC时，试着用「如果……那么……」的句式来检查完整性。比如：「如果扭矩传感器自检失败，那么系统在100ms内将助力降至50%，同时点亮仪表故障灯。」——这样写，每个环节都清晰可追溯。
4.5 一张图看懂FSC的核心逻辑
下面这张图，是我在项目里经常用来跟团队对齐思路的。它把FSC的三个核心要素串在了一起：
你看，从安全目标出发，经过检测、决策、最终到达安全状态——这就是FSC的骨架。每个环节都要定义清楚，不能有模糊地带。
4.6 一个完整的FSC示例（EPS系统）
咱们拿电动助力转向系统举个例子，把上面讲的串起来：
安全目标：防止非预期的转向助力输出，避免车辆失控。（ASIL D）
FSC描述：
- 检测机制：主扭矩传感器与冗余扭矩传感器交叉比较，偏差超过5%时触发故障。
- 决策逻辑：由独立监控芯片（SBC）读取故障标志，判断是否进入安全状态。
- 安全状态：切断助力电机PWM输出，同时保持机械转向通路可用（降级为纯机械转向）。
- FTTI：从故障发生到助力完全切断，不超过100ms。
- 退出条件：系统重新上电且自检通过后，方可恢复助力。
关键点：
ASIL D要求检测机制和决策逻辑之间要有独立性。这里主传感器和冗余传感器是独立的物理通道，监控芯片也是独立的硬件——这就是「独立性」在FSC层面的体现。
好了，FSC的内容就讲到这里。记住一句话：FSC写得好不好，直接决定了后面TSC和硬件软件设计的坑多不多。别急着往下走，先把每个安全目标的FSC链路捋清楚，该定义的参数一个都不能少。