普通人如何用一万元构建AI工作流：投资策略与实战心得
2026/8/25 6:15:50
第一部分：TSR怎么写才算规范？
TSR的三大核心特性
一个规范的TSR，必须具备以下三个核心特性：
| 特性 | 大白话 | 示例 |
|---|---|---|
| ✅可测试性 | “能被验证”——能通过测试或审查来证明它实现了 | “响应时间<300ms”可测；“系统足够快”不可测 |
| ✅技术具体化 | “明确实现方式”——不是抽象的功能描述，而是具体的技术参数 | “用77GHz毫米波雷达” vs “用雷达” |
| ✅覆盖完整性 | “全部覆盖”——所有FSR都要有对应的TSR | 每个FSR至少有一条TSR与之关联 |
TSR是工程师能直接干活的需求文档，不是“理想”，是“方案”。
一个好的TSR长什么样？
根据ISO 26262的要求和行业实践，一个完整的TSR至少应包含以下七个核心要素：
| 要素 | 问的问题 | 示例 |
|---|---|---|
| 🆔唯一标识符 | “这条需求叫什么名字？” | TSR-01-01 |
| 📝需求描述 | “具体要做什么？” | “雷达应选用77GHz频段，探测距离≥200m” |
| 🎯ASIL等级 | “安全等级是多少？” | ASIL-D |
| 🔗来源追溯 | “从哪条FSR来的？” | 关联FSR-01 |
| 🛡️安全机制 | “出问题了怎么处理？” | “通信超时50ms触发报警” |
| 🏗️分配对象 | “谁来负责实现？” | 雷达硬件 / 雷达软件 / 二者共同 |
| ✅验证方法 | “怎么证明它实现了？” | 测试 / 审查 / 分析 |
可追溯性是功能安全评审的必查项！每个TSR都要能追溯到对应的FSR。
❌ 好TSR vs 坏TSR
| 类型 | 写法 | 问题在哪？ |
|---|---|---|
| ❌ 坏TSR | “雷达要可靠” | 太模糊。“可靠”是什么意思？没法测 |
| ❌ 坏TSR | “软件不能有bug” | 这是废话，不是需求。所有软件都不想有bug |
| ✅ 好TSR | “雷达应在-40℃~85℃全温度范围内满足测距精度±2m，ASIL-D” | 具体、可测、有边界条件 |
写TSR的核心原则：用**“在[条件]下，[谁]应[做什么]，达到[量化指标]，ASIL [X]”** 的句式。
第二部分：TSR怎么分配？
FSR是“功能层面”的需求，TSR是“技术层面”的需求。但TSR最终要落实到具体的硬件和软件上，这就涉及到一个关键问题——分配（Allocation）。
分配的核心原则
根据ISO 26262的要求，TSR分配遵循以下核心原则：
1️⃣每个TSR必须分配给至少一个系统架构要素（硬件组件或软件组件）
2️⃣每个架构要素必须实现分配给它的最高ASIL等级的TSR
如果一个硬件组件同时收到了ASIL-D和ASIL-B的TSR，整个组件必须按照ASIL-D的等级来开发。因为“低等级”的部分出问题了，一样会影响到“高等级”的部分。
3️⃣不同ASIL等级的要素之间，必须保证“免于干涉（Freedom from Interference）”
大白话：ASIL-D的代码和QM的代码不能互相干扰。通常通过内存分区、时间隔离、通信隔离等手段实现。
🗺️ 怎么判断TSR该分给硬件还是软件？
这是一个非常实际的问题。行业里常用的判断标准是：
| 分配给谁 | 判断标准 | 示例 |
|---|---|---|
| ⚡硬件 | 涉及物理实现、芯片选型、电路设计、电气参数 | “选用77GHz毫米波雷达”“工作温度-40℃~85℃” |
| 💻软件 | 涉及算法逻辑、数据处理、通信协议、状态管理 | “实现双路冗余算法”“50ms周期发送数据” |
| 🔗二者共同 | 需要软硬件协同配合 | “雷达探测精度±2m”——硬件选型+软件温度补偿算法 |
分配原则：硬件决定“能不能做到”，软件决定“怎么做到位”。
TSR分配示例（ACC系统）
| TSR ID | 需求描述 | ASIL | 分配给谁 |
|---|---|---|---|
| TSR-01-01 | 选用77GHz毫米波雷达，探测距离≥200m | D | 雷达硬件 |
| TSR-01-02 | 全温度范围内测距精度±2m | D | 雷达硬件+软件（硬件选型+温度补偿算法） |
| TSR-01-03 | 上电时执行自检（BIST） | 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-02-04 | 计算超时>300ms触发报警 | D | 控制器软件 |
| TSR-03-01 | 制动执行器支持减速度限制功能 | D | 执行器硬件 |
| TSR-03-02 | 监控实际减速度，超限时切断指令 | D | 执行器软件 |
关键洞察：同一个FSR（比如“雷达应能正确检测前方目标”），会被拆分成硬件TSR（选什么雷达）和软件TSR（怎么处理数据）——两者协同工作，缺一不可。
第三部分：ASIL等级在分配时的“坑”
场景一：一个组件收到不同ASIL等级的需求
问题：一个MCU既要跑ASIL-D的刹车控制算法，又要跑QM的空调控制逻辑。怎么办？
答案：整个MCU必须按照ASIL-D来开发。
ISO 26262规定：如果一个要素被分配了多个不同ASIL等级的需求，该要素必须满足其中最高的ASIL等级。
为什么呢？
因为硬件是“共享资源”——QM的代码跑在同一个CPU上，如果QM的代码出问题了（比如内存越界），可能把ASIL-D的代码也搞崩了。
解决方案：
- 硬件隔离：用两个独立的MCU——一个跑ASIL-D的安全功能，一个跑QM的非安全功能
- 软件隔离：在同一个MCU上通过内存保护单元（MPU）或Hypervisor实现分区隔离
场景二：ASIL分解——把“一个D”拆成“两个B”
还记得第5期我们提到的ASIL分解吗？
ASIL-D = ASIL-B(D) + ASIL-B(D)
什么时候用？
当你觉得“直接做ASIL-D太贵了、太难了”，可以考虑把需求拆成两个相互独立的低等级需求，由两个独立的组件分别实现。
前提条件：
- 独立性：两个组件必须充分独立——不能共用同一个电源、同一个时钟、同一个传感器
- 证据：必须通过相关失效分析（DFA）证明它们确实独立
示例：
| 原始需求 | 分解后 |
|---|---|
| 制动系统需在100ms内响应（ASIL-D） | ① 主制动通道响应时间<100ms（ASIL-B） ② 备用制动通道响应时间<100ms（ASIL-B） ③ 两个通道相互独立（通过DFA证明） |
ASIL分解可以在安全生命周期的多个阶段进行——功能安全概念阶段、系统设计阶段、硬件设计阶段、软件设计阶段都可以。
场景三：安全机制本身也可能失效
这是一个容易被忽视的“坑”。
安全机制本身也可能出故障。如果你针对一个ASIL-D的TSR设计了安全机制A，但安全机制A本身失效了，就会变成潜伏故障（Latent Fault）——平时看不出来，一旦主功能出问题它就帮不上忙了。
解决方案：对安全机制A再加一层监控——这就是“安全机制的安全机制”。
一般来讲，考虑到成本和复杂度，安全机制不超过两层。ISO 26262认为三点及以上故障就可以视为安全故障，否则会出现无穷嵌套。
第四部分：TSR分配全景图
把以上内容串起来，TSR从产生到分配的完整流程是这样的：
关键节点：TSR分配完成后，HSI（软硬件接口规范）就可以定义了——这是硬件团队和软件团队“分头干活”的分界线。
TSR编写与分配中常见的“坑”
坑1：TSR写得像FSR
❌ “系统应能检测前方障碍物” → 这是FSR，不是TSR
✅ “雷达应在50ms内通过CAN-FD发送目标距离数据，精度±2m” → 这才是TSR
FSR是“要什么”，TSR是“怎么做”。
坑2：TSR没有关联安全机制
❌ 只写了“用77GHz雷达”，没写“雷达坏了怎么办”
✅ 写了“用77GHz雷达” + “上电自检” + “通信超时监控” + “数据合理性检查”
每个TSR都应该配套安全机制。
坑3：分配时忘了考虑ASIL兼容性
❌ 把ASIL-D和QM的需求分给同一个MCU，但没做隔离
✅ 要么用两个独立的MCU，要么通过MPU/Hypervisor做分区隔离
坑4：没有建立可追溯性
❌ TSR和FSR之间没有关联，审核员问“这个TSR从哪来的？”答不上来
✅ 建立SG → FSR → TSR → 测试用例的完整追溯链