系统级开发（Part 4）是连接概念阶段和软硬件开发的“桥梁”。Part 4的核心任务是把顶层的功能安全概念转化为系统级的设计和技术需求——这是把“安全概念”变成“工程方案”的第一步。
系统级开发（Part 4）在整个V模型里是什么位置？
ISO 26262 Part 4（系统级产品开发）处于V模型的正中间——它是连接概念阶段（Part 3）和软硬件开发（Part 5/6）的“枢纽”。
Part 4在V模型的左侧接收来自概念阶段的FSR，经过系统设计转化为TSR，然后分别分配给硬件和软件去实现。等硬件和软件开发完成后，再在V模型的右侧进行系统集成测试和安全确认。
💡 简单说就是：Part 4 = 分任务——把FSR拆成硬件能做的和软件能做的，明确分工。
从FSR到TSR：到底“转化”了什么？
先搞清楚：FSR和TSR到底有什么区别？
网上有个特别形象的比喻：
FSR像是甲方：“我需要实现XX功能”
TSR像是乙方：“功能应该怎么做来实现XX”
| 对比维度 | FSR（功能安全需求） | TSR（技术安全需求） |
|---|---|---|
| 抽象层级 | 功能层面 | 技术层面 |
| 回答的问题 | “要做什么？” | “具体怎么做？” |
| 关注点 | 逻辑功能 | 技术实现细节 |
| 后续输入 | 导出TSR | 分配给硬件/软件 |
核心区别：FSR关注“项目定义和车辆级功能的要求”，而TSR聚焦于“系统级的实现细节”。
转化的本质：把“逻辑需求”变成“技术参数”
所谓FSR技术化的安全需求，就是基于系统架构中组件分配得到的FSR，根据该组件内部以及对外的依赖关系和限制条件，将FSR定义的逻辑功能需求进行技术性转化和体现。
大白话翻译就是：
FSR：“你要能检测到前方障碍物” 🎯
TSR：“用77GHz毫米波雷达，探测距离≥200m，角度精度±0.5°，通过CAN-FD发送数据” 🔧
一个重要的规则
每个FSR至少应该有一条与之关联的TSR。
如果一个FSR没有对应的TSR，说明它还没落地——还停留在“想法”阶段。
TSR的核心组成部分：安全机制
TSR不是“一条一条干巴巴的技术参数”。根据ISO 26262，TSR中一个非常重要的组成部分是“安全机制（Safety Mechanism）”。
什么是安全机制？
安全机制是一系列措施，用于探测、显示和控制故障，确保系统在出现故障时能够以一种安全的方式响应。
简单说就是三件事：
安全机制要覆盖哪些方面？
根据ISO 26262-4:2018，TSR中定义的安全机制应包含以下几个方面：
| 安全机制类别 | 大白话 | 示例 |
|---|---|---|
| 🔍故障探测 | “怎么发现出问题了？” | 看门狗定时器、ECC校验、电压监测 |
| 🚦故障指示 | “发现了问题怎么通知？” | 点亮故障灯、发送诊断报文 |
| 🛡️故障控制 | “发现了问题怎么处理？” | 切换到冗余通道、进入安全状态、限制功率输出 |
| 🔄系统自身监控 | “系统自己怎么检查自己？” | 自检程序（BIST）、心跳监测 |
安全机制是TSR的“灵魂”——没有安全机制的TSR，就像只有“要安全”的口号没有具体措施。
从FSR到TSR：实战转化四步法
结合行业实践，从FSR到TSR的转化通常遵循以下四个步骤：
Step 1：分析FSR，识别“预期功能”
问：这个FSR到底要系统“做什么”？
以ACC系统的一个FSR为例：
FSR-01：雷达传感器应能正确检测前方目标，距离误差≤±2m（ASIL-D）
这个FSR的“预期功能”是：“周期性地检测前方目标距离，并确保精度在±2m以内”。
Step 2：确定技术实现方案
问：用什么技术手段来实现这个功能？
针对FSR-01，技术方案可能是：
- 选用77GHz毫米波雷达
- 探测距离：≥200m
- 角度精度：±0.5°
- 数据接口：CAN-FD
- 数据周期：≤50ms
Step 3：设计安全机制
问：如果这个技术方案出问题了，怎么发现、怎么处理？
针对FSR-01，安全机制可能包括：
- 自检机制：雷达上电时自检，检测硬件是否正常
- 合理性检查：检测到的目标距离是否在合理范围内（比如>250m或<0m就是异常）
- 通信监控：CAN-FD通信超时检测，超时50ms触发报警
- 冗余校验：与摄像头数据进行交叉验证
Step 4：编写TSR并分配至架构
问：把这个TSR写成规范的需求，并指定由谁来实现？
最终，FSR-01会被转化为多条TSR，分别分配给不同的架构要素：
| TSR ID | 技术安全需求 | 安全机制 | 分配给谁 | ASIL |
|---|---|---|---|---|
| TSR-01-01 | 雷达应选用77GHz频段，探测距离≥200m | — | 雷达硬件 | D |
| TSR-01-02 | 雷达应在上电时执行自检，检测硬件状态 | 上电自检（BIST） | 雷达固件 | D |
| TSR-01-03 | 雷达应每50ms通过CAN-FD发送目标数据 | 通信超时监控 | 雷达软件+通信 | D |
| TSR-01-04 | 系统应校验雷达数据的合理性，异常时触发报警 | 合理性检查 | 域控制器 | D |
技术安全概念（TSC）：把TSR“打包”成方案
就像概念阶段产出FSC（功能安全概念）一样，系统阶段的核心产出物是TSC（技术安全概念）。
TSC是什么？
TSC是系统阶段围绕TSR开发的工作内容汇总，形成的系统化工作输出结果。它把所有的TSR、安全机制、系统安全架构打包成一个完整的方案。
TSC和FSC有什么区别？
| 对比维度 | FSC（功能安全概念） | TSC（技术安全概念） |
|---|---|---|
| 所属阶段 | 概念阶段（Part 3） | 系统阶段（Part 4） |
| 核心内容 | SG + FSR | TSR + 安全机制 |
| 组织方式 | 按安全目标（SG）组织 | 按系统组件/功能集合组织 |
| 抽象层级 | 功能层面 | 技术层面 |
💡 FSC是“按目标组织”，TSC是“按组件组织”——因为TSR最终要分配给具体的硬件和软件去实现。
TSC应该包含哪些内容？
根据ISO 26262 Part 4，一个完整的TSC应包含：
- ✅ 技术安全需求（TSR）清单
- ✅ 安全机制（Safety Mechanism）设计
- ✅ 系统安全架构（System Safety Architecture）
- ✅ TSR分配至系统架构（谁负责什么）
- ✅ 软硬件接口（HSI）规范
实战：ACC系统从FSR到TSR的转化
我们拿上一期定义的FSR，完整走一遍从FSR到TSR的转化。
回顾：ACC系统的FSR清单
| ID | 功能安全需求 | ASIL |
|---|---|---|
| FSR-01 | 雷达传感器应能正确检测前方目标，距离误差≤±2m | D |
| FSR-02 | 控制器应正确计算安全跟车距离，响应时间<300ms | D |
| FSR-03 | 执行器应限制最大减速度不超过X m/s² | D |
| FSR-04 | 系统应监控CAN通信，检测到异常时在50ms内进入安全状态 | D |
Step 1：对FSR-01进行转化
FSR-01：雷达传感器应能正确检测前方目标，距离误差≤±2m（ASIL-D）
| 转化的TSR | 安全机制 | 分配给谁 |
|---|---|---|
| TSR-01-01：选用77GHz毫米波雷达，探测距离≥200m | — | 雷达硬件 |
| TSR-01-02：雷达探测精度应在全温度范围内（-40℃~85℃）满足±2m | 温度补偿算法 | 雷达硬件+软件 |
| TSR-01-03：雷达应在上电时执行自检 | 上电自检（BIST） | 雷达固件 |
| TSR-01-04：雷达数据应每50ms通过CAN-FD发送 | 通信超时监控（50ms超时报警） | 雷达软件 |
Step 2：对FSR-02进行转化
FSR-02：控制器应正确计算安全跟车距离，响应时间<300ms（ASIL-D）
| 转化的TSR | 安全机制 | 分配给谁 |
|---|---|---|
| TSR-02-01：控制器应选用ASIL-D等级的MCU | — | 控制器硬件 |
| TSR-02-02：控制器应运行在QNX安全操作系统上 | 内存分区隔离 | 控制器软件 |
| TSR-02-03：安全跟车距离计算应使用双路冗余算法 | 双路结果对比校验 | 控制器软件 |
| TSR-02-04：计算超时检测，>300ms触发报警 | 超时监控 | 控制器软件 |
Step 3：对FSR-03进行转化
FSR-03：执行器应限制最大减速度不超过X m/s²（ASIL-D）
| 转化的TSR | 安全机制 | 分配给谁 |
|---|---|---|
| TSR-03-01：制动执行器应支持减速度限制功能 | — | 制动执行器硬件 |
| TSR-03-02：减速度限制值应在系统初始化时从安全参数区读取 | 参数完整性校验（CRC） | 制动执行器软件 |
| TSR-03-03：执行器应监控实际减速度，超限时100ms内切断制动指令 | 实际值监控+超限关断 | 制动执行器软件 |
系统级开发中容易踩的“坑”
坑1：跳过FSR直接写TSR
❌ 不分析FSR，直接拍脑袋写技术需求
✅ 先理解FSR的“预期功能”，再推导TSR
坑2：TSR没有关联安全机制
❌ 只写了技术参数（“用77GHz雷达”），没写“出问题了怎么办”
✅ 每个TSR都要配套安全机制（自检、监控、降级、关断）
坑3：TSC按FSR组织而非按组件
❌ 按照FSR的编号一条一条罗列TSR
✅ 按照系统组件（雷达、控制器、执行器）组织TSR
因为TSR最终要分配给人（硬件团队、软件团队）去实现，按组件组织更方便分工。
