SPL.2 产品发布聚焦向目标客户交付产品，交付对象可以是软件二进制、ECU 样件、OTA 软件包，同时需要配套对应的交付文档。不少研发团队的认知停留在，编译出软件包就算完成发布。实际量产项目当中，产品发布是一套完整流程，要确定发布内容、组装发布包、生成发布文档、执行发布批准、完成对外交付。这套流程同时要承接 ASPICE、ISO26262、ISO/SAE21434 的要求，安全相关的交付物、版本声明、残余风险说明都需要纳入管控。

产品发布落地常见的合规短板。发布包内容没有明确定义，软件、参数文件、标定数据、配套工具混杂，缺少发布内容清单。发布批准流程缺失，测试、功能安全、网络安全没有完成确认就对外交付。Release Note 内容简单，只写版本号，缺少变更摘要、已知问题、残余风险、支持周期说明。发布包没有绑定对应的 ASPICE 项目基线，交付出去的二进制，无法反向关联需求、测试报告。安全相关交付文档没有同步给到客户，残余风险说明、网络安全注意事项遗漏。交付之后没有留存完整的交付证据，ASPICE 评估时无法证明发布流程按要求执行。

SPL.2 不是单纯的打包动作，从发布内容定义到批准、交付全链路，都需要留下可审计证据，同时兼顾功能安全、网络安全的交付诉求。

发布策划阶段，明确本次发布包含的全部内容，软件镜像、标定参数、配置文件、配套工具，同时定义发布准则，把测试闭环、安全评审结论纳入发布准入条件。编写 Release Note，写明版本变更内容、修复缺陷、已知未修复问题、残余安全风险、该版本的技术支持周期。

组装发布包，全部内容来自配置管理管控下的基线，不混入不受管控的临时文件。完成发布前各项确认，除功能测试结论之外，安全相关版本需要完成功能安全、网络安全评审，执行 SPL.2 发布批准，留存批准记录。

对外交付的时候，发布包、Release Note、安全相关交付文档成套给到客户，完整留存交付证据。每一份对外发布包和 ASPICE 内部项目基线建立绑定关系，后续评估审核，可以依据发布版本回溯对应的需求、测试、变更全套产物。如果客户反馈版本问题，可以快速定位到内部完整过程资产。

内部预审环节，调取历史版本的发布包、发布批准记录、Release Note，核对发布准入条件，检查安全相关交付文档是否完整。

产品发布的价值不只是输出二进制文件，还要保证交付物完整、批准流程到位、全套证据可追溯。落实 SPL.2 各项实践，同时满足 ASPICE 评估、ISO26262、ISO/SAE21434 的量产交付审核要求。