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

好，我们进入技术安全概念（TSC）这一章。说实话，这是整个功能安全设计里最「烧脑」也最「落地」的环节。前面我们搞定了危害分析和安全目标，也定好了功能安全需求（FSR）。但FSR说到底还是「要做什么」，而TSC要回答的是「怎么做」。

我个人习惯把TSC比作「施工蓝图」。你想想看，光说「这栋楼要抗震」是不够的，你得告诉我钢筋怎么扎、混凝土标号多少、梁柱怎么布置。TSC就是干这个的。

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

技术安全需求（TSR）是从功能安全需求（FSR）分解下来的。怎么分解？核心思路就一条：把FSR分配给具体的硬件或软件元素。

举个例子。FSR说：「当车速超过120km/h时，系统必须在100ms内发出报警。」那TSR怎么分解？

• TSR-1（传感器）：轮速传感器采样周期 ≤ 10ms，精度 ±1%
• TSR-2（软件）：车速计算模块执行周期 ≤ 20ms，输出延迟 ≤ 5ms
• TSR-3（执行器）：蜂鸣器响应时间 ≤ 30ms，声压级 ≥ 85dB
• TSR-4（诊断）：传感器故障自检周期 ≤ 50ms，故障覆盖率 ≥ 99%

你看，一个FSR拆成了四个TSR，每个都对应具体的物理或逻辑单元。这里有个坑——分解必须完整。我曾经在一个项目中，FSR要求「检测到碰撞后0.5秒内触发气囊」，结果TSR只分解了加速度传感器的采样要求，忘了考虑气囊点火电路的驱动延迟。嗯，后来测试时发现实际触发时间到了0.7秒。这就是分解遗漏的后果。

4.2 系统架构设计：安全不是「加」出来的，是「设计」出来的

很多人以为功能安全就是最后加个监控模块、加个看门狗。大错特错。安全架构必须从系统设计的第一天就融入进去。

系统架构设计要回答三个问题：

1. 功能怎么分配？——哪个模块干什么活
2. 安全怎么保障？——故障来了怎么办
3. 独立性怎么保证？——一个模块坏了别连累另一个

我参与过一个ADAS项目，架构设计时把「车道保持」和「自适应巡航」放在同一个MCU上。结果评审时安全专家直接拍桌子：「如果MCU挂了，两个功能同时失效，ASIL D怎么满足？」最后不得不改成双MCU架构，一个跑功能，一个跑安全监控。

常见的架构模式有几种：

架构模式	适用场景	优点	缺点
单通道+诊断	ASIL A/B	成本低、简单	单点故障风险高
双通道冗余	ASIL C/D	高可靠性	成本翻倍、同步复杂
异构冗余	共因失效敏感场景	抗共因失效	开发难度大
监控架构	ASIL B/C	平衡成本与安全	监控本身也要安全

4.3 冗余与多样性策略：两条腿走路，但别是同一条裤子

冗余和多样性是功能安全的两大法宝。但很多人搞混了它们。

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

为什么要多样性？因为冗余只能防随机硬件故障，防不了系统性故障。举个例子，两个相同的MCU跑相同的软件，如果软件有个bug，两个通道会同时出错——冗余就失效了。这就是为什么ASIL D要求「多样性」。

我做过一个制动控制项目，要求ASIL D。我们用了双MCU架构，但两个MCU型号不同（一个Infineon，一个NXP），编译器也不同（一个用GCC，一个用Tasking）。甚至算法实现方式也不同——一个用查表法，一个用插值法。测试时发现，查表法在边界条件下有精度损失，而插值法没有。这就是多样性带来的好处。

常见的冗余策略：

• 1oo1（1取1）：单通道，适合ASIL A
• 1oo2（1取2）：双通道，任一通道都能独立工作，适合ASIL D
• 2oo2（2取2）：双通道，两个都同意才输出，适合安全关断场景
• 2oo3（2取3）：三取二，航空常用，汽车里偶尔用

多样性策略要具体看：

• 硬件多样性：不同型号的芯片、不同的外围电路
• 软件多样性：不同的算法、不同的编程语言、不同的开发团队
• 时序多样性：不同的采样时刻、不同的计算周期
• 数据多样性：不同的数据源、不同的校验方式

嗯，这里要注意——多样性不是越多越好。多样性会增加开发成本、测试工作量，还可能引入新的接口问题。我建议只在「共因失效可能导致安全目标违反」的关键路径上使用多样性。

最后说一句，TSC设计完成后，一定要做安全分析验证。常用的方法有FMEA（失效模式与影响分析）和FTA（故障树分析）。我习惯先做FTA，从顶层的安全目标往下推，看哪些故障会导致目标违反；然后针对这些故障做FMEA，看现有的冗余和多样性策略能不能覆盖。如果覆盖不了，就回头改TSC。

好了，这一章就到这里。下一章我们讲「硬件安全需求与硬件架构指标」，那是真正开始算数字的地方了。