4. 技术安全概念（TSC）设计：从需求到架构的落地

好，咱们进入第四讲。前面我们聊了危害分析与风险评估（HARA），也定了功能安全概念（FSC）。那都是“做什么”层面的东西。到了技术安全概念（TSC），说白了就是“怎么做”。

我个人习惯把TSC看作一座桥。桥的一头是功能安全需求（FSR），另一头是具体的硬件和软件实现。没有这座桥，你的安全机制很可能飘在空中，落不了地。

4.1 技术安全概念的定义

技术安全概念，英文叫Technical Safety Concept，简称TSC。它回答一个核心问题：系统怎么用技术手段来实现功能安全需求？

TSC的输入是功能安全概念（FSC）输出的功能安全需求（FSR），输出则是技术安全需求（TSR）和系统架构设计。你可以把它理解成一份“技术实现说明书”。

我在项目中遇到过不少团队，FSR写得漂漂亮亮，一到TSC就卡壳。为什么？因为FSR是功能级的，比如“当检测到转向扭矩传感器失效时，系统应在100ms内进入安全状态”。但TSC要回答：用什么传感器？检测阈值是多少？诊断覆盖率够不够？安全状态怎么进入？这些才是技术细节。

4.2 技术安全需求（TSR）的导出

TSR是从FSR分解出来的。一个FSR可能对应多个TSR。举个例子：

FSR编号	FSR内容	对应TSR编号	TSR内容
FSR-01	当转向扭矩传感器失效时，系统应在100ms内进入安全状态	TSR-01.1	扭矩传感器应具备自诊断功能，诊断覆盖率≥90%
		TSR-01.2	控制器应在传感器故障发生后50ms内检测到故障
		TSR-01.3	安全状态为“转向助力降级至50%”，执行时间≤100ms

你看，一个FSR拆成了三个TSR，分别对应传感器、控制器、执行器。这就是分解的过程。

TSR的导出步骤，我一般这么走：

1. 分析FSR：搞清楚每个FSR要检测什么故障、响应什么动作。
2. 识别系统元素：传感器、控制器、执行器、通信链路，哪些元素参与这个安全功能？
3. 分配安全机制：每个元素需要什么安全机制？检测、响应、容错、降级？
4. 量化指标：诊断覆盖率、故障检测时间、故障响应时间、安全状态定义。
5. 写TSR：每个TSR要可验证、可测试、可追溯。

4.3 系统架构设计与安全机制细化

有了TSR，接下来就是画架构图了。系统架构设计是TSC的骨架，安全机制是血肉。

我见过很多工程师一上来就画框图，画完发现安全机制没地方放。正确的做法是：先想安全机制，再画架构。

常见的系统架构模式有几种：

• 单通道架构：一个通道完成所有功能，安全机制靠诊断实现。适合ASIL A/B。
• 双通道架构：两个独立通道，互为备份或交叉比较。适合ASIL C/D。
• 主从架构：主通道负责功能，从通道负责监控。适合ASIL B/C。
• 对称冗余架构：两个完全相同的通道，输出比较。适合ASIL D。

安全机制细化，说白了就是给每个系统元素“上保险”。常见的保险有：

安全机制	适用元素	典型实现
自诊断	传感器、控制器	CRC校验、RAM测试、时钟监控
比较器	双通道输出	软件比较、硬件比较器
看门狗	控制器	内部看门狗、外部看门狗
故障响应	执行器	安全状态切换、降级模式
通信监控	通信链路	超时检测、序列号、CRC

下面这张图展示了TSC设计的核心流程，从FSR到TSR再到架构和安全机制：

4.4 实战中的几个关键点

说了这么多理论，我分享几个实战中容易踩的坑：

• TSR写得太笼统：比如“系统应检测传感器故障”。怎么检测？检测时间？覆盖率？这些不写清楚，后续设计没法做。
• 架构和安全机制脱节：架构图画得漂亮，但安全机制没地方放。比如双通道架构，两个通道之间怎么同步？怎么比较？这些要在架构里体现。
• 忽略共因失效：两个通道都用同一个电源，电源一挂两个都挂。这叫共因失效，要在TSC里考虑。
• 安全状态定义模糊：“进入安全状态”太笼统。是断电？是降级？是报警？要具体到可执行的程度。

最后说一句，TSC设计不是一次性的。随着系统设计的深入，你会发现有些TSR需要调整，有些安全机制需要补充。迭代是正常的，别怕改。