4、功能安全概念(FSC)：功能安全概念定义、安全状态设计、故障容错时间间隔、安全机制分配

好，我们进入功能安全开发中最核心的一环——功能安全概念，简称FSC。

说实话，很多工程师把FSC当成一个文档任务，觉得就是写写画画。但我告诉你，FSC是整个安全开发的灵魂。你后面所有的技术决策，都从这里来。

4.1 功能安全概念到底在定义什么？

功能安全概念，说白了就是回答三个问题：

• 系统出错了怎么办？
• 怎么让系统进入安全状态？
• 在多长时间内必须完成？

我个人习惯，在拿到Item Definition（项目定义）和HARA（危害分析与风险评估）报告后，先不急着写文档。我会在白板上画一张大图，把所有的安全目标（Safety Goal）列出来，然后一个个往下拆。

举个例子，你有一个安全目标是：“防止车辆非预期加速”。那FSC就要定义：当检测到油门踏板信号异常时，系统应该做什么？是限制扭矩？还是直接切断动力？

4.2 安全状态设计——你得知道“往哪跑”

安全状态，就是系统在发生故障后，要进入的那个“相对安全”的状态。

注意我说的“相对安全”。没有绝对的安全，只有可接受的风险。

我在项目中遇到过这样一个案例：一个线控制动系统，它的安全状态是什么？

• 方案A：完全切断制动助力，让驾驶员用纯机械力踩。
• 方案B：保持当前制动力，不再响应新请求。
• 方案C：以最大制动力紧急制动。

你选哪个？

嗯，这里要注意，安全状态不是拍脑袋定的。它取决于你分析出的危害等级和系统能力。对于制动系统，通常我们会选择“降级模式”——保留部分功能，同时给驾驶员明确的警示。

常见的几种安全状态：

• 关闭/断电：最粗暴的方式，适用于非关键功能。
• 降级模式：保留核心功能，关闭非必要功能。
• 故障容错模式：使用冗余通道继续工作。
• 紧急操作模式：比如自动驾驶系统要求驾驶员立即接管。

4.3 故障容错时间间隔（FTTI）——和时间赛跑

FTTI，全称Fault Tolerant Time Interval。这个概念很多人理解有偏差。

它不是说“系统能撑多久不坏”，而是说“从故障发生到系统进入安全状态，最多能花多长时间”。

为什么会这么重要？

你想想看，一个刹车系统如果检测到故障，但花了3秒钟才进入安全状态，这3秒钟里车可能已经撞上了。所以FTTI必须小于危害发生的时间。

我给大家一个实际项目中的例子：

安全目标	FTTI要求	说明
防止非预期加速	≤ 100ms	从检测到故障到限制扭矩
防止转向失控	≤ 200ms	从检测到故障到切换到冗余通道
防止电池过充	≤ 500ms	从检测到故障到切断充电回路

FTTI的分解通常包括：

1. 故障检测时间（FDT）
2. 故障反应时间（FRT）
3. 系统执行时间（SET）

这三部分加起来，必须小于FTTI。

4.4 安全机制分配——把任务分下去

安全机制，就是用来检测故障、防止违反安全目标的具体手段。

分配安全机制，说白了就是回答：“谁来干活？”

常见的分配方式：

• 硬件安全机制：比如看门狗、电压监控、冗余传感器。
• 软件安全机制：比如数据校验、程序流监控、自检程序。
• 系统级安全机制：比如故障诊断、降级策略、故障存储。

我个人习惯，在分配安全机制时，会画一个矩阵表：

安全目标	故障类型	安全机制	分配对象	ASIL等级
SG-01: 防止非预期加速	油门踏板信号卡滞	信号合理性检查 + 冗余传感器对比	软件模块A + 硬件模块B	ASIL D
SG-02: 防止转向失控	电机驱动失效	电流监控 + 冗余驱动通道	硬件模块C	ASIL C
SG-03: 防止电池过充	电压采样偏差	周期性自检 + 交叉校验	软件模块D	ASIL B

最后，我想强调一点：FSC不是写完了就完事的。它需要和系统架构设计、硬件设计、软件设计反复迭代。我见过太多项目，FSC写得漂漂亮亮，结果到了实现阶段发现根本做不了。为什么？因为没考虑硬件资源限制，没考虑软件实时性。

所以，做FSC的时候，多和硬件工程师、软件工程师聊一聊。听听他们的反馈，调整你的分配方案。这才是真正的“从零搭建”。

好，这一节就到这里。下一节我们讲技术安全概念（TSC），看看怎么把FSC里的需求，进一步细化到具体的技术实现上。