📚 课程目录第4章 FSC与TSC概念解析

4. FSC与TSC概念解析

系统级安全设计，说白了就是回答三个问题：什么东西会坏？坏了会怎样？怎么让它不坏或者坏了也不出事？ 我个人习惯把这一阶段叫做“搭骨架”——骨架搭歪了，后面细节做得再好也白搭。

咱们直接进入正题。电驱控制器的系统级安全设计，我一般拆成四个步骤来走：架构分解、安全相关项定义、冗余与多样性设计、故障响应策略。每一步都有坑，我一个个说。

拿到一个电驱控制器，你不能直接说“我要做功能安全”。你得先把它拆开。拆到什么程度？拆到你能看清楚每个子功能是怎么协作的。

我习惯用功能层级分解法。先画顶层功能，再逐层往下拆。比如电驱控制器的顶层功能是“将电池直流电转换为电机所需交流电并控制扭矩输出”。往下拆，就是三大块：

嗯，这里要注意。分解的时候，千万别只按硬件模块拆。你得把功能和行为也拆进去。比如“扭矩控制”这个功能，它跨越了控制单元和功率变换单元——MCU算扭矩指令，驱动电路执行开关动作。如果你只按硬件拆，安全分析就会漏掉跨模块的故障路径。

  核心原则：架构分解的颗粒度，要以能识别出所有安全相关故障模式为准。拆得太粗，分析不彻底；拆得太细，工作量爆炸。我个人经验是拆到“每个子功能都有明确的输入输出和故障模式”这个程度就够了。

架构拆完了，接下来要圈出安全相关项。什么是安全相关项？就是那些一旦失效，就会导致违背安全目标的硬件或软件组件。

我举个例子。电驱控制器有个安全目标是“防止非预期的扭矩输出”。那哪些东西跟这个目标相关？

扭矩指令路径：从CAN接收扭矩请求 → MCU解析 → 电流环计算 → PWM生成 → 驱动电路 → IGBT开关。这一整条链路，每一个环节都是安全相关项。
扭矩反馈路径：旋变传感器 → 解码芯片 → MCU角度计算 → 电流采样 → 电流环闭环。反馈路径坏了，控制就会跑偏，所以也是安全相关项。
监控路径：看门狗、电压监控、温度监控。这些是“救火队”，它们失效了，故障就没人管了。

我曾经在一个项目里犯过错误——只把“执行器”列为安全相关项，忽略了“传感器”。结果呢？旋变信号线虚焊，扭矩反馈突然跳变，控制器直接输出一个反向扭矩。幸好台架上测试，没出大事。从那以后，我定了一条死规矩：所有参与安全目标实现的信号路径，全部列为安全相关项。

安全相关项定义好了，接下来就是怎么保护它们。冗余和多样性，是功能安全的两大法宝。

冗余，就是备份。一个坏了，另一个顶上。多样性，就是备份跟原件不一样——防止共因失效。你想想看，如果两个通道用同一款芯片、同一版软件、同一个电源，那一个设计缺陷就能同时干掉两个通道。多样性就是为了避免这种情况。

在电驱控制器里，我常用的冗余设计有几种：

多样性设计呢？我举一个实际案例。之前做的一个项目，扭矩监控模块用了两套算法：一套是基于模型的扭矩估算（用电流和角度算扭矩），另一套是基于查表的扭矩映射（用电流指令查表）。两套算法独立开发，用的数学方法不同，连代码都是不同工程师写的。这样就算其中一套算法有bug，另一套也能兜底。

我的经验：多样性设计不要只盯着硬件。软件多样性同样重要——不同算法、不同编程语言、不同开发团队，都能降低共因失效风险。当然，成本会高一些，但安全等级要求高的时候，这笔钱不能省。

冗余和多样性是“防患于未然”。但万一还是出故障了呢？这时候就需要故障响应策略。说白了，就是故障发生后的“剧本”——谁先动、怎么动、动到什么程度。

我一般把故障响应分成三个等级：

这里有个关键点：故障响应的时间窗口。不同的故障，容忍的时间不一样。比如过流，你可能只有几微秒的反应时间，软件根本来不及处理，必须靠硬件快速关断。而温度过高，你有几秒钟甚至几分钟，软件降额就够了。

避坑指南：我曾经犯过一个错误——把所有故障响应都交给软件处理。结果有一次过流故障，软件还没来得及响应，IGBT就炸了。后来我学乖了：时间窗口小于1ms的故障，必须用硬件直接响应；时间窗口大于10ms的，可以交给软件处理；中间的，软硬件协同。

下面这张图是我常用的故障响应策略框架，你可以参考一下：

最后说一句。故障响应策略不是写完了就完事的。你得验证它。怎么验证？故障注入测试。我习惯在HIL台架上做故障注入——模拟传感器短路、CAN断线、电源跌落、看门狗超时……看看系统是不是按你写的剧本走。如果发现响应时间超了，或者响应动作错了，那就得回头改设计。

嗯，系统级安全设计这块，说白了就是“想清楚、拆清楚、防清楚、应清楚”。架构分解让你知道有什么，安全相关项定义让你知道什么重要，冗余与多样性让你知道怎么防，故障响应策略让你知道怎么救。四步走完，骨架就搭起来了。