1. 课程导入与体系总览
在汽车电子软件开发中，AUTOSAR 已经成为主流的分层软件架构标准。它把应用层软件、运行时环境（RTE）和基础软件（BSW）清晰分离，使不同供应商、不同团队开发的软件组件能够按统一接口集成。但随之而来的问题是：一个 ECU 项目往往包含数百条需求、几十个软件组件、多个配置变体，以及来自 OEM、Tier1、内部测试团队的多种交付物。如果没有一套贯穿始终的追溯与交付体系，项目很容易陷入“需求改了没人知道、代码改了追溯不到、交付时说不清版本”的混乱状态。
ETAS 作为 AUTOSAR 工具链的重要供应商，其工具生态（如 ISOLAR-AB、RTA 系列、INCA 等）覆盖了从需求导入、软件组件设计、BSW 配置、代码生成到测试验证的完整链路。本课程要讨论的，不是某一个工具按钮怎么点，而是如何在这条链路上建立需求可追溯、变更可控制、交付可验证的工程体系。换句话说，我们关注的是“体系”而非“单点操作”。
学习目标
完成本课程后，读者应当能够达到以下三个层次的目标。第一，概念层：理解需求追溯、交付基线、变体管理、追溯矩阵等核心概念在 AUTOSAR 项目中的具体含义，而不是停留在抽象定义。第二，方法层：掌握从需求标识、分配到实现、再到验证的追溯链路设计方法，能够为一个中等规模 ECU 项目规划追溯结构。第三，工具层：了解 ETAS 工具链中与追溯和交付相关的功能入口、数据格式和典型工作流，能够在实际项目中定位并操作关键环节。
核心概念：追溯与交付不是两件事
很多团队把“需求追溯”和“交付管理”当成两个独立活动：追溯由系统工程师维护一张 Excel 表，交付由配置管理员打包发布。这种割裂正是问题的根源。在 AUTOSAR 项目中，追溯和交付本质上是同一件事的两个侧面——追溯回答“这个交付物为什么存在、它满足了什么、它被什么验证了”，交付回答“这个追溯链在某个时间点上被冻结成了什么版本”。
具体来说，一条完整的追溯链通常包含以下节点：原始需求（OEM 需求或系统需求）→ 软件需求 → 软件组件（SWC）或 BSW 模块 → 配置参数 → 生成代码 → 测试用例 → 测试结果。每个节点都需要有唯一标识，节点之间的连接关系需要被记录，而交付基线则是这条链在某个时刻的快照。
关键区分：追溯关系是“活的”，它随项目进展不断更新；交付基线是“死的”，它一旦冻结就不再改变。没有活的追溯，交付基线只是一堆无法解释的文件；没有交付基线，追溯关系永远处于“最新状态”，无法回答“三个月前交付给客户的那版软件到底对应哪些需求”。
整体框架：四层追溯与三类交付
结合 AUTOSAR 分层架构和 ETAS 工具链的实际使用方式，我们可以把整个体系归纳为“四层追溯、三类交付”。四层追溯分别是：需求层追溯、架构层追溯、实现层追溯和验证层追溯。三类交付分别是：软件组件交付、ECU 集成交付和测试验证交付。
需求层追溯关注原始需求到软件需求的分解与分配；架构层追溯关注软件需求到 SWC、端口、接口和 BSW 模块的映射；实现层追溯关注架构元素到具体配置参数、生成代码和编译产物的关联；验证层追溯关注测试用例、测试结果与需求、实现之间的双向覆盖。三类交付则分别对应不同粒度的冻结对象：SWC 交付通常以 ARXML 和源代码包形式提供，ECU 集成交付以完整工程配置和可执行文件形式提供，测试验证交付以测试报告和覆盖率数据形式提供。
工程价值：为什么值得投入
建立这套体系需要额外投入：定义标识规则、维护追溯关系、管理基线版本。这些工作不会直接产生功能代码，但它们的回报体现在项目风险控制上。一个典型的场景是：OEM 在项目中期提出某条安全需求变更，如果追溯链完整，团队可以在几小时内定位到受影响的 SWC、BSW 配置参数、测试用例和已交付基线，评估变更工作量；如果追溯链缺失，同样的评估可能需要数天，而且容易遗漏。
另一个价值体现在功能安全合规上。ISO 26262 对需求追溯有明确要求，ASIL 等级越高，追溯的完整性和双向覆盖要求越严格。ETAS 工具链中的追溯功能可以帮助团队生成符合审核要求的追溯矩阵，减少人工整理文档的时间。