4. 系统级安全设计：功能安全概念（FSC）、技术安全概念（TSC）、系统架构设计
系统级安全设计，说白了就是回答三个问题：“要保什么？”、“怎么保？”、“谁来保？”。
我个人习惯把这一阶段叫做“安全设计的骨架搭建期”。骨架歪了，后面填再多的肉也白搭。很多项目到了硬件测试阶段才发现安全机制漏了，回头一查，根因都在系统级概念没理清。
4.1 功能安全概念（FSC）—— 定义“要保什么”
FSC 的输入是 Hazard Analysis 的结果，也就是我们上一章聊过的 ASIL 等级和安全目标（SG）。它的输出，是一组功能安全需求（FSR）。
核心原则：FSC 只关心“功能层面要做什么”，不关心“用硬件还是软件实现”。
比如：“当车速超过 120km/h 时，系统必须在 100ms 内发出报警”。这就是一个典型的 FSR。至于报警是用蜂鸣器还是屏幕闪烁，那是 TSC 的事。
我在项目中遇到过一种常见错误：工程师在写 FSC 时就开始想“我用双核锁步来实现”，结果把技术方案写进了功能需求里。这会导致后续变更时牵一发动全身。记住，FSC 阶段要保持技术中立。
FSC 的典型输出清单
| 输出项 | 说明 | 示例 |
|---|---|---|
| 功能安全需求（FSR） | 每个安全目标分解为若干 FSR | FSR-01: 检测到转向扭矩传感器失效时，在 50ms 内进入降级模式 |
| 安全状态定义 | 系统进入安全模式后的行为 | 安全状态：EPS 输出扭矩归零，点亮故障灯 |
| 容错时间间隔（FTTI） | 从故障发生到危害发生的最长时间 | FTTI ≤ 100ms |
| 功能安全概念文档 | 描述安全机制在功能层的分配 | FSR 分配到“感知-决策-执行”各环节 |
我的小技巧：写 FSR 时，每个需求都问自己一句：“如果这条需求删了，安全目标还能达成吗？” 如果答案是“能”，那这条需求就是冗余的，可以砍掉。
4.2 技术安全概念（TSC）—— 把“怎么保”落地
TSC 是把 FSC 翻译成技术语言。说白了，就是告诉硬件工程师和软件工程师：“你们各自要做什么”。
举个例子：FSC 说“检测到传感器失效后进入安全状态”。TSC 就要细化成：
- 硬件：使用两个独立的 ADC 通道采集传感器信号，做交叉比较。
- 软件：每 10ms 运行一次比较算法，若偏差超过 5%，则触发安全路径。
- 系统：安全路径通过独立看门狗切断执行器供电。
嗯，这里要注意：TSC 不是把 FSC 抄一遍，而是增加技术细节。我见过最离谱的 TSC 文档，就是把 FSR 的“检测到故障”改成了“MCU 检测到故障”，这等于没写。
TSC 的关键要素
| 要素 | 描述 | 避坑指南 |
|---|---|---|
| 安全机制 | 具体的技术手段 | 不要只写“冗余”，要写“双通道交叉比较，每通道独立供电” |
| 故障检测覆盖率 | 该机制能检测多少比例的故障 | 我曾经见过标称 99% 覆盖率的机制，实际只覆盖了 60% 的故障模式 |
| 诊断时间间隔 | 多久跑一次诊断 | 必须小于 FTTI 减去系统响应时间 |
| 安全机制独立性 | 避免共因失效 | 两个看门狗不能共用同一个时钟源 |
曾经踩过的坑：有一次做 EPS 项目，TSC 里写了“主芯片和监控芯片通过 SPI 通信”。结果评审时发现，SPI 的时钟线如果短路到电源，两个芯片同时失效。这就是典型的共因失效没考虑。后来改成了“通过独立的 GPIO 握手 + 窗口看门狗”才通过评审。
4.3 系统架构设计 —— 安全架构的三种经典模式
系统架构设计，就是把 TSC 里的安全机制分配到具体的硬件模块和软件模块里。你想想看，架构设计其实就三种套路：
- 1oo1（单通道）：一个通道干活，靠自检保证安全。成本低，但诊断覆盖率要求极高。
- 1oo2（双通道互检）：两个通道同时运行，互相比较。安全等级高，但容易误报警。
- 2oo2（双通道表决）：两个通道都同意才能输出。容错能力强，但复杂度翻倍。
我个人最常用的是 1oo2 架构。为什么？因为它在安全性和成本之间平衡得最好。但要注意，1oo2 架构的比较器本身必须是安全的。我曾经见过一个项目，两个通道都正常，但比较器坏了，结果系统一直报故障——这就是典型的“比较器成了单点故障”。
系统架构设计流程图
4.4 实战中的三个关键检查点
做了这么多年功能安全，我总结出三个每次评审必查的点：
- FSR 和 TSC 的追溯性：每个 FSR 必须至少对应一个 TSC，每个 TSC 必须能回溯到 FSR。我曾经用 Excel 做追溯矩阵，后来改用 DOORS 了，但原理一样——不能有孤儿需求。
- 安全机制的独立性：两个安全机制不能共享同一个失效模式。比如，两个看门狗不能共用同一个晶振。你想想看，晶振坏了两个狗都废了。
- 诊断时间 vs FTTI：诊断间隔 + 系统响应时间 必须小于 FTTI。我见过一个项目，FTTI 是 100ms，诊断间隔设了 80ms，系统响应要 50ms，加起来 130ms，超了。这种低级错误在评审时会被直接打回。
一句话总结：FSC 定目标，TSC 定方法，架构设计定分工。三者缺一不可，顺序不能乱。
嗯，系统级安全设计这块，其实最考验的是系统思维。不要只盯着自己的模块，要从整车层面看问题。我见过太多工程师把安全设计做成了“点状防护”——这里加个看门狗，那里加个 ECC，但整体架构是散的。真正好的系统级设计，是让每个安全机制像齿轮一样咬合在一起，一个失效了，另一个能无缝顶上。