第4章 功能安全概念（FC）：功能安全目标定义、功能安全概念设计、安全机制分配

好，咱们进入功能安全概念这个核心环节。说实话，很多工程师容易把这一步和系统设计混在一起。我个人习惯是这么区分的：功能安全概念回答的是“做什么”，系统设计回答的是“怎么做”。你想想看，如果连要保护什么都说不清楚，后面的设计肯定要翻车。

4.1 功能安全目标定义

功能安全目标，说白了就是从危害分析里提炼出来的“安全底线”。我在项目里见过有人直接把HARA里的危害事件抄过来当安全目标，这其实不对。危害事件描述的是“什么场景下出了什么事”，而安全目标描述的是“要避免什么后果”。

举个例子：

• 危害事件：车辆在高速行驶时，转向系统非预期助力丧失，导致驾驶员无法控制车辆。
• 功能安全目标：转向系统应避免非预期助力丧失，或在助力丧失时确保车辆仍可安全减速停车。

你看，安全目标里要明确“避免什么”和“允许什么”。这里有个关键点——每个安全目标必须对应一个ASIL等级。这个等级直接从HARA里继承过来，不能自己拍脑袋定。

嗯，这里要注意：一个危害事件可能衍生出多个安全目标。比如“非预期加速”这个危害，你可能需要同时定义“避免非预期加速”和“确保制动优先”两个目标。我在做EPS项目时就踩过这个坑，只定义了一个目标，结果评审时被安全专家怼回来了。

4.2 功能安全概念设计

功能安全概念，就是把安全目标转化成系统层面的安全要求。我个人习惯用“谁来做、做什么、做到什么程度”这个框架来思考。

具体来说，功能安全概念要包含：

1. 故障探测机制：怎么发现故障？比如信号合理性检查、看门狗、冗余比较。
2. 故障响应机制：发现故障后怎么办？比如降级、关断、切换到备份。
3. 故障容错机制：即使有故障，系统还能维持安全功能吗？比如三取二架构。
4. 安全状态定义：系统最终要进入什么状态？比如“零扭矩输出”、“紧急制动”。
5. 故障容错时间间隔（FTTI）：从故障发生到进入安全状态，最多能容忍多久？

功能安全概念设计时，我建议用安全概念图来梳理。不用画得太复杂，关键是理清楚：

• 输入信号从哪里来？
• 安全机制在哪里执行？
• 执行器怎么响应？
• 故障怎么被检测和上报？

举个例子，一个简单的电子油门安全概念：

安全目标：避免非预期加速（ASIL C）
安全概念：
1. 传感器层：两个位置传感器（主+冗余），信号交叉比较
2. 控制层：ECU内部自检 + 看门狗监控
3. 执行层：电机驱动电路带电流监测
4. 响应：检测到故障后，500ms内进入“限制扭矩”模式
5. 安全状态：油门踏板信号被忽略，输出零扭矩

4.3 安全机制分配

安全机制分配，就是把功能安全概念里的“谁来做”具体化。说白了，你要决定每个安全机制放在哪个层级：系统级、硬件级、还是软件级？

我一般按这个优先级来分配：

层级	典型安全机制	适用场景
系统级	冗余架构、故障降级、安全状态切换	ASIL C/D，需要高诊断覆盖率
硬件级	硬件自检、看门狗、电压/电流监测	ASIL B/C，硬件可独立实现
软件级	数据校验、程序流监控、逻辑自检	ASIL A/B，软件灵活性高

分配的时候有个原则：能硬件做的尽量硬件做。为什么？因为硬件响应快、确定性高。我见过一个项目，把关键安全机制全放在软件里，结果软件跑飞了，安全机制也跟着失效了。嗯，这就是典型的“监守自盗”。

安全机制分配完成后，要输出一个安全机制分配表。这个表是后续硬件和软件设计的输入，也是安全评审的重要依据。格式大概这样：

安全机制ID	描述	分配层级	实现方式	诊断覆盖率	关联安全目标
SM_001	传感器信号交叉比较	硬件	两个独立ADC通道	99%	FC_SG_001
SM_002	看门狗监控	硬件	外部独立看门狗	95%	FC_SG_001
SM_003	程序流监控	软件	逻辑时间戳检查	90%	FC_SG_002

最后说一句，功能安全概念不是一次成型的。我习惯先做一版粗的，然后和系统架构师、硬件工程师、软件工程师一起评审，迭代个两三轮才能定下来。你想想看，如果安全概念本身就有漏洞，后面做得再精细也是白搭。

好，这一章就到这里。下一章咱们聊聊技术安全概念（TSC），看看怎么把功能安全概念落地到具体的技术实现上。