4、技术安全概念（TSC）与系统架构设计：技术安全需求分解、系统架构设计原则、冗余与多样性

好，我们进入第4章。技术安全概念，简称TSC。很多工程师觉得TSC就是写文档，画几个框图，把安全需求往架构里一塞就完事了。说实话，我早年也这么干过，结果项目后期发现安全机制根本跑不通，或者跟功能逻辑打架，那叫一个痛苦。

TSC的核心是什么？说白了，就是把上一阶段的安全目标和技术安全需求，翻译成系统架构里实实在在的硬件和软件模块。它不是一张挂在墙上的蓝图，而是指导你“怎么布线、怎么选芯片、怎么分配任务”的施工图。

4.1 技术安全需求分解：从“要什么”到“怎么做”

技术安全需求（TSR）是从功能安全概念里细化出来的。但TSR往往还是偏“需求语言”，比如“系统必须在100ms内检测到传感器故障”。TSC要做的，就是把这个需求分解成具体的实现方案。

我习惯把分解过程分成三步：

1. 识别相关项：哪些硬件、软件、通信链路会参与这个安全功能？
2. 分配责任：每个组件承担什么安全角色？检测、响应、还是降级？
3. 定义接口：组件之间怎么交互？信号怎么传递？时序怎么保证？

举个例子。我之前做EPS（电动助力转向）项目时，有一条TSR是“转向扭矩传感器故障必须在20ms内被检测并进入安全状态”。分解到TSC后，我们是这样做的：

• 传感器端：采用双路冗余霍尔传感器，输出两路独立信号。
• 采集端：主核和监控核各采一路，交叉校验。
• 诊断端：每路信号都做范围检查、变化率检查、自检信号检查。
• 响应端：一旦校验不一致，立即切断助力，保留基础机械转向。

你看，一个需求分解下来，每个模块的职责都清清楚楚。这就是TSC的价值。

4.2 系统架构设计原则：安全不是贴上去的

很多团队喜欢在架构设计完成后，再“加”安全机制。比如发现某个信号可能出错，就加个CRC校验。这种做法，我称之为“打补丁式安全”。

真正的安全架构，应该从设计之初就把安全考虑进去。这里有三个我反复强调的原则：

原则	说明	我的经验
分层隔离	安全功能与非安全功能要物理或逻辑隔离	曾经有个项目，安全核和非安全核共用同一个DMA通道，结果非安全核的异常DMA请求把安全核的数据冲乱了。后来强制分通道，问题解决。
确定性行为	系统在故障下的行为必须是可预测的	我最怕听到“应该会进入安全状态”这种话。必须明确：哪个故障触发哪个动作，动作的时序是什么，超时了怎么办。
最小化复杂度	安全路径上的逻辑越简单越好	复杂的状态机、多级嵌套的条件判断，都是安全验证的噩梦。能用硬件实现的，就别用软件绕。

4.3 冗余与多样性：安全架构的两大支柱

冗余和多样性，是应对系统性故障和随机硬件故障最有效的手段。但很多人把这两个概念搞混了。

• 冗余：用多个相同的通道做同样的事。比如两个相同的MCU同时计算同一个结果。
• 多样性：用不同的方式实现同一个功能。比如一个用硬件比较器，一个用软件算法。

冗余对付的是随机硬件故障（一个坏了，另一个顶上）。多样性对付的是系统性故障（设计缺陷、软件bug）。

我参与过一个ADAS项目，要求ASIL D。我们最终采用了“双核锁步 + 软件多样性”的方案：

• 硬件层：两个相同的CPU核锁步运行，时钟和输出实时比较。
• 软件层：两个团队分别用C语言和Model-Based代码生成，实现同一个算法。

为什么这么做？因为锁步能检测硬件瞬时故障，但两个核跑同样的软件，如果软件有bug，两个核会一起错。加上软件多样性，就能覆盖软件设计缺陷。

4.4 知识体系：TSC与系统架构设计全景

下面这张图，是我自己总结的TSC与系统架构设计的核心逻辑。你可以把它当作一个检查清单。

这张图把TSC的落地过程分成了三个步骤。每一步都有明确的输入和输出。我个人习惯在项目启动时，就把这张图贴在白板上，团队每天对照着看，确保没有遗漏。

4.5 避坑指南：我踩过的几个坑

最后，分享几个我亲身经历过的教训，希望能帮你少走弯路。

• 坑一：冗余通道之间的共因失效。我曾经设计过双路冗余电源，结果两路电源的PCB走线在同一个区域，一个螺丝刀掉下去，两路全短路。后来强制要求物理隔离，走线间距至少5mm。
• 坑二：多样性带来的验证成本。软件多样性听起来很美，但两个团队、两套工具链、两套测试用例，成本直接翻倍。如果项目预算有限，建议优先考虑硬件多样性（比如不同型号的传感器）。
• 坑三：忽略安全机制的时序。有个项目，安全检测逻辑跑在RTOS的任务里，结果任务被高优先级任务抢占，检测周期从10ms变成了100ms。后来我们把安全检测放在定时器中断里，优先级最高，问题解决。

嗯，这一章的内容就到这里。记住，TSC是连接“安全需求”和“具体实现”的桥梁。桥搭得稳，后面的路才好走。