TSR是一堆技术需求条目，TSC是把这些需求组织成一套完整的系统安全方案------包括系统架构长什么样、安全机制怎么部署、软硬件怎么分工、接口怎么定义。
TSC到底是什么？
ISO 26262对技术安全概念（TSC）没有给出一个"一句话定义"，但行业实践对它有一个共识：
TSC = 技术安全需求（TSR）+ 系统安全架构 + 安全机制 + 软硬件接口（HSI）的"打包文件"
简单说：TSC是系统阶段围绕TSR开发的工作内容汇总，形成的系统化工作输出结果。
如果把FSC比作"产品说明书"------"这个产品要做什么、有什么功能、要防止什么风险"；
那么TSC就是"施工蓝图"------"这个产品具体怎么造、用什么材料、各部件怎么配合、出问题了怎么修"。
TSC和FSC的核心区别
| 对比维度 | FSC（功能安全概念） | TSC（技术安全概念） |
|---|---|---|
| 所属阶段 | 概念阶段（Part 3） | 系统阶段（Part 4） |
| 核心内容 | SG + FSR | TSR + 系统安全架构 + HSI |
| 组织方式 | 按安全目标（SG） 组织 | 按系统组件/功能集合组织 |
| 抽象层级 | "要什么" | "怎么做" |
| 后续输入 | 导出TSR | 分配给硬件和软件 |
一句话总结：FSC按"目标"组织，TSC按"组件"组织。因为TSC最终要分配到硬件和软件去实现，按组件组织更方便分工。
TSC的核心组成部分
一个完整的TSC应该包含以下四大核心内容：
1️⃣ 技术安全需求（TSR）清单
上期我们已经完成了从FSR到TSR的转化，这一步是TSC的"原材料"。
2️⃣ 系统安全架构（System Safety Architecture）
这是TSC的核心骨架 。系统架构的作用是描述相关项的组成、相互作用和约束 。而在TSC中，我们还需要把安全机制融入系统架构，形成系统安全架构。
一个最简单的系统架构包含三个部分：传感器 → 控制器 → 执行器。系统安全架构就是在这三个部分以及它们之间的通信中，嵌入安全机制。
3️⃣ 安全机制（Safety Mechanism）部署
安全机制是TSC的灵魂。它回答的问题是："系统出故障了，怎么发现、怎么处理？"
4️⃣ 软硬件接口（HSI）规范
HSI是TSC的接口说明书。它定义了硬件和软件之间怎么配合、怎么通信。没有HSI，硬件团队和软件团队各干各的，最后集成的时候必然"打架"。
HSI是系统开发的最后一个开发工件 ，也是硬件和软件并行开发的起点。它需要在硬件和软件团队之间架起一座"沟通的桥梁"。
系统安全架构：把安全机制"嵌入"系统
系统安全架构是TSC中最核心、最"烧脑"的部分。它的本质是：在原有的系统架构上，叠加一层"安全防护网" 。
不含安全机制的系统架构长什么样？
一个最简单的系统架构是这样的：
就这么简单------传感器采集信号 → 控制器处理决策 → 执行器执行动作。
问题来了：如果传感器坏了怎么办？控制器算错了怎么办？执行器失灵了怎么办？
答案 ：在架构里嵌入安全机制。
常见的安全机制有哪些？
系统级别的安全机制主要围绕传感器、控制器、执行器、通信四个环节展开：
| 环节 | 常见安全机制 | 大白话 |
|---|---|---|
| 📡 传感器 | 硬件冗余、信号合理性检查 | "用两个传感器，互相验证" |
| 🧠 控制器 | 在线诊断、比较器、多数投票器 | "自己检查自己，多个核心对比结果" |
| ⚡ 执行器 | 执行器硬件冗余、控制信号质量检测 | "两个执行器，一个坏了另一个顶上" |
| 🔗 通信 | 冗余发送、CRC校验、时间监控、问答机制 | "多发一次、加校验码、超时就报警" |
这些安全机制从三个角度来保障安全：
- 冗余：多一套备份，坏了也不怕
- 多样性：用不同的技术手段实现同一功能，避免"同一种故障把两个备份都干掉"
- 监控：持续检查系统是否正常，发现问题及时报警
安全机制怎么融入架构？
以ACC系统为例，融入安全机制后的系统安全架构长这样：
这个架构体现了几个关键安全机制：
- 传感器冗余：双雷达+摄像头，三路信号互相验证
- 控制器监控：主MCU干活，监控MCU独立盯着，发现异常立即介入
- 执行器冗余：主执行器失效，备份执行器接管
- 输出限幅：无论控制器怎么算，执行器输出的减速度不能超过安全阈值
软硬件接口（HSI）：硬件和软件的"握手协议"
HSI是TSC中最容易出问题的部分。它定义了硬件和软件之间的技术依赖关系，是硬件团队和软件团队各干各的"分界线"。
HSI为什么重要？
想象一下这个场景：
硬件团队 ："我们设计好了，芯片是A型号，内存映射是这样的，中断号是这些......"
软件团队："啊？你用的中断号跟我预期的不一样啊！代码全白写了！"
这就是没有HSI的后果。HSI的核心价值是在硬件和软件开发开始之前，就把接口定死------硬件团队按照HSI设计硬件，软件团队按照HSI写代码，最后集成的时候才能"严丝合缝"。
HSI应该包含哪些内容？
根据ISO 26262和行业实践，一个完整的HSI规范应包含以下内容：
| 类别 | 具体内容 | 大白话 |
|---|---|---|
| 硬件设备的工作模式 | 默认模式、初始化模式、测试模式、高级模式 | "芯片在什么状态下工作" |
| 配置参数 | 增益控制、带通频率、时钟分频器 | "芯片的参数怎么调" |
| 内存映射 | 各功能模块在内存中的地址分配 | "数据存在哪里" |
| 寄存器定义 | 各寄存器的地址、位定义、读写属性 | "怎么通过寄存器控制芯片" |
| 定时器配置 | 定时器周期、中断频率 | "多久中断一次" |
| 中断分配 | 各中断源的优先级、中断向量 | "哪个中断先处理" |
| I/O端口分配 | 各I/O引脚的功能定义 | "哪个引脚接什么" |
| 共享/专用硬件资源 | 哪些资源是共享的、哪些是专用的 | "CPU、内存、DMA怎么分配" |
| 独立性保障 | 确保不同安全等级模块之间的隔离 | "ASIL-D和QM的代码不能互相干扰" |
HSI的核心原则 ：HSI必须在硬件和软件开发开始之前完成定义。它是两个团队并行工作的"契约"。
实战：ACC系统的TSC编写
咱们拿ACC系统，完整走一遍TSC的编写过程。
Step 1：回顾TSR清单（上期的产出）
| ID | 技术安全需求 | ASIL | 分配给谁 |
|---|---|---|---|
| TSR-01-01 | 选用77GHz毫米波雷达，探测距离≥200m | D | 雷达硬件 |
| TSR-01-02 | 雷达探测精度在全温度范围内满足±2m | D | 雷达硬件+软件 |
| TSR-01-03 | 雷达应在上电时执行自检 | D | 雷达固件 |
| TSR-01-04 | 雷达数据应每50ms通过CAN-FD发送 | D | 雷达软件 |
| TSR-02-01 | 控制器应选用ASIL-D等级的MCU | D | 控制器硬件 |
| TSR-02-02 | 控制器应运行在QNX安全操作系统上 | D | 控制器软件 |
| TSR-02-03 | 安全跟车距离计算应使用双路冗余算法 | D | 控制器软件 |
| TSR-03-01 | 制动执行器应支持减速度限制功能 | D | 制动执行器硬件 |
| TSR-03-02 | 执行器应监控实际减速度，超限时切断制动指令 | D | 制动执行器软件 |
Step 2：设计系统安全架构
基于TSR，设计ACC的系统安全架构：
Step 3：定义HSI（软硬件接口）
以雷达模块的HSI为例：
| HSI项 | 定义内容 |
|---|---|
| 通信接口 | CAN-FD，波特率2Mbps |
| 数据周期 | 50ms，超时50ms触发报警 |
| 数据格式 | 目标距离（uint16，单位0.1m）、相对速度（int16，单位0.01m/s）、目标角度（int8，单位0.1°） |
| 自检接口 | 上电后100ms内完成自检，通过CAN-FD发送自检状态（0=正常，1=故障） |
| 供电要求 | 12V±10%，功耗<5W |
| 温度范围 | -40℃~85℃ |
Step 4：编写TSC文档
Step 5：建立可追溯性
在TSC中，必须建立完整的可追溯性：
在功能安全评审中，审核员会要求你证明"每个安全目标都被实现了"。可追溯性矩阵就是你的"证据链"------从SG一路追溯到具体的硬件引脚和软件代码行。
TSC开发中容易踩的"坑"
坑1：TSC和FSC混为一谈
❌ 把FSC的内容直接复制到TSC里
✅ TSC按组件 组织，FSC按安全目标组织。两者结构不同，内容不同，不能混用。
坑2：只有TSR，没有架构
❌ 文档里堆了一堆TSR，但没有系统架构图
✅ TSC的核心是系统安全架构。TSR只是"零件"，架构才是"整机"。
坑3：没有定义HSI
❌ 硬件和软件各干各的，最后集成时发现接口对不上
✅ HSI是硬件和软件并行开发的起点，必须在开发开始前定义好。
坑4：没有可追溯性
❌ 审核员问"这个TSR是怎么来的？"回答不上来
✅ 建立SG ↔ FSR ↔ TSR的完整追溯链，这是功能安全评审的必查项。