可追溯性是什么？为什么ISO 26262强制要求？
官方要求
ISO 26262-8:2018第6章专门规定了安全需求的管理要求。标准明确指出：
功能安全评估师应考虑需求管理（包括双向可追溯性）是否得到充分实施。
简单说：审核员必查！可追溯性是功能安全评估的"必答题"，不是"选做题"。
什么是"双向追溯"？
ISO 26262要求的是双向可追溯性（Bidirectional Traceability） ：
| 追溯方向 | 大白话 | 回答的问题 |
|---|---|---|
| ➡️ 正向追溯 | "从上往下查" | "这个安全目标，被哪些需求实现了？被哪些测试验证了？" |
| ⬅️ 反向追溯 | "从下往上查" | "这个测试用例，是为了验证哪个安全目标？" |
双向追溯的价值：正向追溯确保"没有需求被遗漏"，反向追溯确保"没有多余的测试"------每个测试都有明确的"为什么"。
为什么可追溯性这么重要？
-
证明"需求被实现了"
：不只是"我们做了"，而是"我们有证据证明我们做了"
-
变更影响分析
：当某个需求变了，能快速找到所有受影响的代码和测试
-
认证证据
：安全档案（Safety Case）的核心组成部分
安全需求的"家族树"：从SG到SSR的完整链条
ISO 26262中有一条清晰的安全需求链条：
这条链条就是可追溯性的"骨架" 。每一个层级的需求，都必须能追溯到它的"父级"和"子级"。
需求层级速查表：
| 层级 | 缩写 | 全称 | 谁负责 | 输出物 |
|---|---|---|---|---|
| 1 | SG | 安全目标 | 系统工程师 | 安全目标清单 |
| 2 | FSR | 功能安全需求 | 系统工程师 | 功能安全概念（FSC） |
| 3 | TSR | 技术安全需求 | 系统架构师 | 技术安全概念（TSC） |
| 4 | HSR | 硬件安全需求 | 硬件工程师 | 硬件安全需求规范 |
| 4 | SSR | 软件安全需求 | 软件工程师 | 软件安全需求规范 |
追溯矩阵（RTM）：可追溯性的"成绩单"
什么是追溯矩阵？
RTM（Requirements Traceability Matrix，需求追溯矩阵） 是一个表格，用来展示每条需求与对应的实现工件（如设计文档、代码模块、测试用例）之间的映射关系。
💡 RTM是审核员第一个会翻的东西。它就像一张"地图"，让审核员能快速找到"某个需求对应的测试在哪里"。
一个标准的追溯矩阵长什么样？
以ACC控制器的软件安全需求（SSR）为例：
| SSR ID | SSR描述 | ASIL | 关联设计 | 关联代码 | 测试用例 | 测试结果 |
|---|---|---|---|---|---|---|
| SSR-01 | 跟车距离计算应在200ms内完成 | D | 架构文档v2.3 §3.2 | calc_distance.c | TC-001~010 | ✅ PASS |
| SSR-02 | 计算结果应进行合理性校验 | D | 架构文档v2.3 §4.1 | validation.c | TC-011~020 | ✅ PASS |
| SSR-03 | 计算超时应触发安全状态 | D | 架构文档v2.3 §5.3 | watchdog.c | TC-021~030 | ✅ PASS |
| SSR-04 | 程序流监控应检测执行顺序 | D | 架构文档v2.3 §6.2 | flow_monitor.c | TC-031~040 | ✅ PASS |
RTM的核心要素：每个需求必须有唯一ID、关联的ASIL等级、对应的设计/代码/测试、以及测试结果。
正向追溯 vs 反向追溯
正向追溯（Forward Traceability） ：从需求查到测试
"SG-01（防止非预期急刹车）→ FSR-01 → SSR-01 → TC-001~010 → 全部PASS ✅"
反向追溯（Backward Traceability） ：从测试查到需求
"TC-005（边界值测试）→ SSR-01 → FSR-01 → SG-01"
审核员会随机抽查：随便指一个测试用例，问"这个测试是为了验证哪个安全目标？"------如果你答不上来，追溯性就有问题
实战：ACC控制器完整追溯链构建
把以上所有内容整合起来，用ACC控制器完整走一遍从SG到测试的追溯链构建。
Step 1：建立需求层级
| 层级 | ID | 内容 | ASIL |
|---|---|---|---|
| 🎯 SG | SG-01 | 防止ACC在非必要情况下输出超过阈值的减速度请求 | D |
| 📋 FSR | FSR-01 | 控制器应正确计算安全跟车距离，响应时间<300ms | D |
| 🔧 TSR | TSR-02-01 | 控制器应选用ASIL-D等级的MCU | D |
| 🔧 TSR | TSR-02-02 | 控制器应运行在QNX安全操作系统上 | D |
| 🔧 TSR | TSR-02-03 | 安全跟车距离计算应使用双路冗余算法 | D |
| 💻 SSR | SSR-01 | 跟车距离计算应在200ms内完成 | D |
| 💻 SSR | SSR-02 | 计算结果应进行合理性校验 | D |
Step 2：建立追溯矩阵（RTM）
| 安全目标 | FSR | TSR | SSR | 设计文档 | 代码文件 | 测试用例 | 结果 |
|---|---|---|---|---|---|---|---|
| SG-01 | FSR-01 | TSR-02-03 | SSR-01 | Arch_v2.3 §3.2 | calc_distance.c | TC-001~010 | ✅ |
| SG-01 | FSR-01 | TSR-02-03 | SSR-02 | Arch_v2.3 §4.1 | validation.c | TC-011~020 | ✅ |
| SG-01 | FSR-01 | TSR-02-02 | SSR-03 | Arch_v2.3 §5.3 | watchdog.c | TC-021~030 | ✅ |
Step 3：验证追溯完整性
| 检查项 | 状态 | 说明 |
|---|---|---|
| 每个SG都有对应的FSR？ | ✅ | SG-01 → FSR-01 |
| 每个FSR都有对应的TSR？ | ✅ | FSR-01 → TSR-02-01/02/03 |
| 每个TSR都有对应的SSR/HSR？ | ✅ | TSR-02-03 → SSR-01/02 |
| 每个SSR都有对应的测试用例？ | ✅ | SSR-01 → TC-001~010 |
| 每个测试用例都有结果？ | ✅ | 全部PASS |
💡 这就是审核员要看的"证据链" ------从SG到测试结果，每一步都是完整的、可追溯的。
可追溯性管理的"武器库"：工具与实践
手动方式：Excel/Word
适用场景：小项目、需求数量<100
优点：成本低、上手快
缺点：需求一多就失控、变更管理困难
专业需求管理工具
| 工具 | 特点 | 适用场景 |
|---|---|---|
| DOORS | IBM出品，功能安全行业标准 | 大型项目、多团队协作 |
| Polarion | Siemens出品，Web端，与ALM集成 | 中大型项目 |
| Jama Connect | 云原生，支持实时协作 | 敏捷开发+功能安全 |
| Codebeamer | PTC出品，与测试工具深度集成 | 端到端追溯 |
💡 工具选型原则 ：需求数量超过100个，强烈建议使用专业工具------Excel会在追溯矩阵变得庞大时彻底失控。
自动化追溯的"终极形态"
现代功能安全开发中，可追溯性管理正在走向全自动化：
-
CI/CD集成
：代码提交时自动校验需求ID格式
-
自动追溯检查
：Jenkins Pipeline中自动验证"需求→设计→代码→测试"链条的完整性
-
自动化证据包
：脚本自动拉取各类数据源，组装成符合ISO 26262要求的结构化安全证据包
可追溯性管理中容易踩的"坑"
坑1：只有单向追溯
❌ 只做了"需求→测试"的正向追溯
✅ ISO 26262要求双向追溯------既能从需求查到测试，也能从测试查到需求
坑2：追溯矩阵和实际开发脱节
❌ 矩阵是矩阵，代码是代码，两者对不上
✅ 追溯矩阵必须随着开发同步更新------需求变了，矩阵要跟着变
坑3：需求没有唯一ID
❌ "这个需求就是那个'刹车'的需求"
✅ 每条安全需求必须有全局唯一的ID------SG-01、FSR-01、SSR-01......
坑4：忘了追溯ASIL等级
❌ 只追溯了需求内容，没追溯ASIL等级
✅ ASIL等级必须随需求传递------SG的ASIL-D→FSR的ASIL-D→SSR的ASIL-D
🧠 本期重点回顾
| 核心概念 | 核心要点 |
|---|---|
| 📖 可追溯性定义 | 双向跟踪安全需求从产生到验证的完整生命周期 |
| 🔗 追溯链条 | SG → FSR → TSR → HSR/SSR → 测试用例 |
| ➡️ 正向追溯 | 从安全目标查到所有相关的测试用例 |
| ⬅️ 反向追溯 | 从测试用例反查到它对应的安全目标 |
| 📋 RTM（追溯矩阵） | 展示需求与设计、代码、测试之间映射关系的表格 |
| 🛠️ 工具 | DOORS、Polarion、Jama、Codebeamer |
| ⚠️ 审核必查 | 双向追溯、唯一ID、ASIL等级传递 |