4. 安全概念设计：功能安全概念（FSC）、技术安全概念（TSC）、安全机制设计
好，咱们进入安全概念设计这个核心环节。说实话，很多工程师觉得这块就是写文档、画框图，没什么技术含量。但我得说句实话——安全概念设计的好坏，直接决定了你后续所有工作的成败。我在项目里见过太多因为概念设计阶段偷懒，结果后期改得死去活来的案例。
安全概念设计，说白了就是回答三个问题：系统要做什么来保证安全？具体怎么实现？实现不了怎么办？ 这三个问题分别对应功能安全概念（FSC）、技术安全概念（TSC）和安全机制设计。
4.1 功能安全概念（FSC）—— 安全需求的顶层设计
功能安全概念，我习惯叫它「安全需求的顶层设计」。它回答的是：系统在功能层面需要做什么来避免或控制危害。
FSC 的输入是什么？是上一章我们做的危害分析和风险评估（HARA）结果。每个危害事件都对应一个安全目标（Safety Goal），而 FSC 就是把这些安全目标分解成更具体的功能安全需求。
举个例子。我在做自动驾驶项目时，有一个安全目标是：「车辆在行驶过程中，不得因感知系统故障导致与前方障碍物碰撞，ASIL D」。这个目标很宏观，怎么落地？FSC 就要把它分解成几条功能安全需求：
- FSR-01：当主感知系统失效时，系统应在 200ms 内切换到冗余感知系统
- FSR-02：系统应持续监控感知系统的健康状态，故障检测覆盖率 ≥ 99%
- FSR-03：当感知系统完全失效时，系统应执行最小风险策略（MRM），在 3 秒内安全停车
你看，这些需求都是功能层面的，不涉及具体用什么传感器、什么芯片。这就是 FSC 的特点——只描述「做什么」，不描述「怎么做」。
关键点：FSC 中的每个需求都要继承安全目标的 ASIL 等级。比如上面 FSR-01 继承 ASIL D，FSR-02 可能因为故障检测本身有冗余设计，可以降级到 ASIL B。这个降级需要有理有据，不能拍脑袋。
FSC 的输出是一份功能安全需求规范，通常包含：
- 安全目标到功能安全需求的追溯矩阵
- 每个需求的 ASIL 等级、故障容错时间间隔（FTTI）
- 安全状态的定义（比如：停车、降级运行、紧急制动）
- 功能冗余和降级策略
4.2 技术安全概念（TSC）—— 把需求变成技术方案
有了 FSC，接下来就是 TSC。TSC 是把功能安全需求映射到具体的技术实现上。说白了，就是回答「怎么做」的问题。
我个人的习惯是，做 TSC 时先画一张系统架构图，把所有的功能模块、通信链路、传感器、执行器都标出来。然后在图上标注每个模块的安全相关属性。
还是拿刚才的例子。FSR-01 要求「200ms 内切换到冗余感知系统」，TSC 就要设计：
- 主感知系统用摄像头 + 毫米波雷达
- 冗余感知系统用激光雷达 + 超声波
- 切换逻辑由安全控制器（Safety MCU）实现
- 通信采用 CAN FD，保证 100ms 内完成状态同步
你看，这里就具体到用什么传感器、用什么总线了。TSC 的输出是技术安全需求（TSR），每个 TSR 都要能追溯到对应的 FSR。
我的经验：做 TSC 时最容易犯的错误是「过度设计」。我曾经有个项目，为了满足 ASIL D 的要求，给一个简单的温度传感器做了三重冗余。后来发现根本没必要，因为温度传感器的故障模式很单一，双冗余加诊断就够了。所以，安全设计要恰到好处，不是越冗余越好。
TSC 还需要定义系统的安全架构模式。常见的模式有：
| 架构模式 | 描述 | 适用场景 |
|---|---|---|
| 1oo1 | 单通道，无冗余 | ASIL A/B，故障后果不严重 |
| 1oo2 | 双通道，任一通道可用即可 | ASIL C/D，高可用性要求 |
| 2oo2 | 双通道，两个通道都需一致输出 | ASIL D，高安全性要求 |
| 2oo3 | 三通道，多数表决 | 航空航天、高铁等极高安全场景 |
嗯，这里要注意：架构模式的选择不是越高越好。2oo2 虽然安全性高，但可用性差——一个通道故障整个系统就停了。1oo2 可用性好，但安全性相对低一些。要根据实际需求权衡。
4.3 安全机制设计 —— 把概念落地成代码和硬件
安全机制，就是具体实现安全需求的手段。它是 TSC 的进一步细化，直接对应到软件函数、硬件电路、诊断逻辑。
常见的安机制有哪些？我列几个典型的：
- 故障检测机制：比如看门狗、CRC 校验、内存 ECC、传感器合理性检查
- 故障响应机制：比如安全状态切换、降级运行、紧急停机
- 故障避免机制：比如多样化设计（用不同算法实现同一功能）、物理隔离
- 故障容错机制：比如冗余切换、数据重传、状态保持
我举个例子，看门狗（Watchdog）是最常见的安全机制。但你真的会用吗？
我曾经遇到一个项目，看门狗超时时间设了 500ms，但系统正常运行时最长的任务周期是 600ms。结果呢？系统每隔几分钟就复位一次。这就是典型的「安全机制设计不合理」。
正确的做法是：先分析系统的最大无响应时间（Max Response Time），然后设置看门狗超时时间 = 最大无响应时间 × 安全系数（通常 1.5~2 倍）。同时，看门狗喂狗的位置要选在关键任务执行完毕后，而不是随便找个循环里喂一下。
避坑指南：我曾经见过一个团队，为了满足 ASIL D 的故障覆盖率要求，给每个软件模块都加了 ECC 校验。结果代码体积膨胀了 3 倍，运行效率下降 40%。后来我们重新做了故障模式分析，发现只有内存和通信链路需要 ECC，其他模块用 CRC 就够了。安全机制不是越多越好，要精准打击。
安全机制设计还有一个重要原则——独立性。安全机制不能依赖它正在监控的对象。比如，你用同一个 CPU 既运行主功能又运行安全监控，那 CPU 挂了怎么办？正确的做法是用独立的硬件（比如 Safety MCU）来做监控。
4.4 从 FSC 到 TSC 到安全机制 —— 一条完整的追溯链
这三个概念不是孤立的，它们是一条完整的追溯链：
安全目标 → FSC（功能安全需求） → TSC（技术安全需求） → 安全机制（具体实现）
每个环节都要能双向追溯。什么意思？就是：
- 从安全目标出发，能找到所有相关的 FSC、TSC、安全机制
- 从任何一个安全机制出发，也能追溯到它满足哪个安全目标
这个追溯链是安全认证的核心证据。审核员最喜欢干的事就是：随便挑一个安全机制，让你往上追溯三层。追溯不上来？不好意思，认证不通过。
我建议大家在项目一开始就用工具（比如 DOORS、Polarion 或者简单的 Excel）建立这个追溯矩阵。别等到最后再补，那会补到你怀疑人生。
4.5 知识体系总览
下面这张图是我自己总结的，把 FSC、TSC、安全机制的关系画清楚了。你一看就明白：
这张图的核心逻辑就是：从上到下逐层细化，从下到上逐层追溯。做安全设计时，你要能从上往下走，也能从下往上走。审核员会从任意一点切入，你要能接得住。
好了，安全概念设计这块就讲到这里。记住一句话：好的安全设计是设计出来的，不是测试出来的。概念阶段多花点时间，后面能省十倍的时间。
公众号:蓝海资料掘金营，微信deep3321