4. 技术安全概念（TSC）：技术安全需求的细化、系统架构设计中的安全分解、安全机制的实现策略
好，我们进入第四章。技术安全概念，简称TSC。说实话，这是整个功能安全开发中最「落地」的一环。前面我们搞了危害分析，定了安全目标，也写了功能安全需求。但那些东西，说白了还是「要什么」。TSC要回答的是「怎么做」。
我个人习惯把TSC看作一座桥。桥的一头是抽象的安全需求，另一头是具体的硬件软件实现。桥搭不好，后面全白干。我见过太多项目，安全需求写得漂漂亮亮，一到实现就发现根本没法落地。嗯，这就是TSC没做透。
4.1 技术安全需求的细化
技术安全需求，简称TSR。它是从功能安全需求（FSR）细化来的。怎么细化？说白了，就是把「系统要做什么」翻译成「技术模块要做什么」。
举个例子。FSR说：「车辆在行驶中，TCU必须检测到非预期的挡位切换，并在100ms内进入安全状态。」
这个需求到了TSC层面，就要拆成：
- TSR-01：TCU主芯片每10ms读取一次挡位传感器信号
- TSR-02：TCU主芯片将当前挡位与目标挡位进行一致性校验
- TSR-03：若校验不一致，TCU在50ms内输出安全状态指令（强制N挡）
- TSR-04：安全状态指令通过独立硬件路径传输至执行器
你看，每个TSR都对应一个具体的技术动作。我在项目中遇到过一种情况：FSR写得没问题，但TSR写得太笼统，比如「系统应具备故障检测能力」。这种需求等于没写。你想想看，检测什么故障？用什么方法检测？检测周期多长？这些不写清楚，开发人员根本没法干活。
关键原则：每个TSR必须满足SMART原则——具体的、可测量的、可实现的、相关的、有时限的。尤其是「可测量」和「有时限」，这两条最容易漏。
4.2 系统架构设计中的安全分解
TSR写好了，接下来要把它分配到系统架构里去。这就是安全分解。说白了，就是把一个安全需求拆到不同的硬件或软件模块上，让它们共同承担。
为什么要做安全分解？因为有时候单个模块的可靠度不够。比如ASIL D的需求，单个芯片的失效率可能达不到要求。那就得用两个芯片，每个承担一部分，加起来满足要求。
安全分解的核心依据是ISO 26262-9的第5章。它允许你把一个ASIL D的需求，分解成两个ASIL B(D)的需求。注意这个写法——括号里的D表示「来源需求是D级」，前面的B表示「每个模块按B级开发」。两个B级模块组合起来，整体达到D级。
我举个例子。TCU的「防止非预期加速」这个安全目标，ASIL C。我们可以做这样的分解：
| 模块 | 分配的安全需求 | ASIL等级 |
|---|---|---|
| 主控芯片（MCU） | 执行加速请求的合理性校验 | ASIL B(C) |
| 监控芯片（SBC） | 独立监控油门信号，超阈值时切断执行器电源 | ASIL B(C) |
这样，两个ASIL B的模块，通过冗余和多样性，共同实现了ASIL C的安全目标。我记得有一次做TCU项目，客户要求所有安全相关功能都做到ASIL D。但当时选的主芯片最高只支持ASIL B。怎么办？就是靠安全分解。主芯片做ASIL B(D)，再加一个独立的ASIL B(D)监控芯片，两个一起上，问题就解决了。
小技巧：做安全分解时，尽量让两个模块采用不同的实现方式。比如一个用软件校验，一个用硬件比较器。这叫「多样性冗余」，能有效避免共因失效。我吃过这个亏——两个模块用了同一款芯片，结果一个批次缺陷导致两个同时失效，教训深刻。
4.3 安全机制的实现策略
安全机制，就是具体用来检测故障、控制故障、或者让系统进入安全状态的那些技术手段。TSC阶段要明确每个安全机制怎么实现。
常见的TCU安全机制包括：
- 故障检测机制：比如看门狗、内存校验（ECC）、程序流监控（PFC）
- 故障响应机制：比如安全状态切换、降级模式、故障存储
- 故障避免机制：比如硬件冗余、多样化设计、物理隔离
我建议在TSC阶段，每个安全机制都要明确三件事：
- 检测什么故障（比如：MCU死锁、传感器短路、通信超时）
- 用什么方法检测（比如：窗口看门狗、CRC校验、回读比较）
- 检测到后怎么办（比如：进入安全状态、记录故障码、点亮故障灯）
举个例子。TCU的「防止挡位误切换」安全机制，可以这样写：
安全机制ID：SM_GEAR_01
关联TSR：TSR-03
检测对象：挡位执行器位置反馈异常
检测方法：每20ms读取位置传感器，与目标挡位比较
容错时间间隔：100ms
故障响应：立即切断执行器电源，强制进入N挡，存储DTC
安全状态：N挡锁定，等待维修
你看，这样写出来，硬件工程师知道要加什么传感器，软件工程师知道要写什么逻辑，测试工程师知道要测什么场景。清清楚楚。
注意：安全机制的实现策略一定要考虑「诊断覆盖率」。不是说你加了个看门狗就万事大吉了。看门狗能检测死锁，但检测不了时序漂移。我曾经在一个项目里，看门狗喂狗正常，但程序逻辑已经跑偏了——因为中断优先级配置错了，高优先级中断把安全任务饿死了。后来我们加了程序流监控（PFC），才把这个坑填上。
最后说一句。TSC的输出，最终要形成一份技术安全概念文档。这份文档是后续硬件安全需求、软件安全需求的输入。文档写得好不好，直接决定了开发阶段会不会返工。我个人习惯，TSC文档写完以后，一定要拉上硬件、软件、测试三方一起评审。别自己闷头写，写完了发现实现不了，那就尴尬了。
好，这一章就到这里。下一章我们讲硬件层面的安全设计，包括硬件架构度量、随机硬件失效的评估方法。到时候我会分享一些实际项目中的计算案例，挺有意思的。