2. ST Stellar量产软件工程概览
ST Stellar（Stellar Integration Platform）是面向整车电子电气架构的集成与量产软件平台，其核心价值在于把分散在多个ECU、多个供应商、多个开发阶段的软件资产，收敛为可交付、可追溯、可复现的量产软件包。理解量产软件工程，首先要区分“开发软件”与“量产软件”的差异：前者关注功能实现与验证，后者关注在既定硬件状态、标定数据、诊断规范、网络安全策略和法规要求下，能够被稳定刷写、批量生产、售后维护并持续升级的完整软件集合。
量产软件的构成
从工程视角看，ST Stellar量产软件通常由以下层次构成：
- 底层固件与驱动：MCU/SoC的启动代码、时钟与电源管理、通信驱动（CAN/CAN FD、LIN、以太网）、存储驱动（Flash/EEPROM）等，决定软件能否在目标硬件上运行。
- 基础软件（BSW）与中间件：AUTOSAR CP/AP栈、诊断栈（UDS/OBD）、网络管理、标定接口（XCP）、安全模块（HSM/SecOC）等，提供标准化服务。
- 应用层软件：车身控制、动力、底盘、座舱等具体功能逻辑，通常以模型生成代码或手写代码形式存在。
- 标定与配置数据：参数集、变体编码、VIN/配置字、诊断描述文件（CDD/ODX）等，决定同一软件在不同车型配置下的行为。
- 刷写与引导数据：Bootloader、Flash驱动、刷写脚本、签名与校验信息，是量产和售后升级的入口。
这些内容并非简单叠加，而是通过版本基线、依赖关系和配置管理形成“软件包”。一个可量产软件包必须明确：包含哪些二进制、对应哪个硬件版本、使用哪套标定数据、依赖哪些诊断数据库、签名与加密状态如何。
交付物与交付形态
量产交付物不只是可执行文件。典型交付物包括：
| 交付物 | 内容说明 | 典型用途 |
|---|---|---|
| 软件包（SW Package） | HEX/S19/BIN、标定数据、Bootloader、刷写脚本 | 产线刷写、售后升级 |
| 版本说明与发布说明 | 版本号、变更点、已知问题、兼容性矩阵 | 变更评审、问题追溯 |
| 诊断数据库 | CDD/ODX/PDX、DTC列表、例程与IO控制定义 | 诊断仪配置、产线EOL测试 |
| 标定数据包 | A2L、DCM、PAR、CDFX等 | 标定、变体管理 |
| 安全与合规材料 | 签名证书、哈希清单、SBOM、网络安全档案 | 法规准入、审计 |
| 刷写规范与工具配置 | 刷写时序、波特率、超时、重试策略 | 产线与售后工具集成 |
交付形态上，量产软件通常以“基线+变体”的方式管理。基线保证核心功能一致，变体通过配置字、标定数据或条件编译区分车型、区域和配置。交付时必须保证变体之间的差异可枚举、可验证，避免“同版本不同行为”导致产线误刷或售后误判。
生命周期与版本治理
量产软件生命周期并非从SOP开始，而是从需求冻结、架构设计、A样/B样/C样、PPAP到SOP，再到售后OTA和EOL。每个阶段都有不同的软件状态和准入条件。工程上常用“软件版本树”表达：
- 开发版本：频繁迭代，允许未完成功能，但必须有明确的基线标签。
- 验证版本：功能冻结，进入HIL/SIL/实车验证，缺陷收敛。
- 量产候选版本：通过PPAP、产线试刷、EOL测试，具备量产条件。
- 量产版本：正式发布，进入受控状态，任何变更需走变更评审。
- 售后版本：针对OTA或召回，需兼容已售车辆硬件状态。
版本治理的关键是“可追溯”和“可复现”。可追溯要求每个二进制都能回溯到源码提交、编译工具链、标定数据和签名记录；可复现要求相同输入能生成相同输出，包括编译环境、依赖库版本和构建脚本。实践中，CI流水线应自动生成版本号、构建清单和哈希值，并与PLM/ALM系统关联。
与整车开发流程的衔接
ST Stellar量产软件不是孤立存在的，它必须与整车开发流程（如GVDP、APQP）对齐。衔接点主要体现在：
- 节点对齐：软件冻结节点与整车样车节点、产线试生产节点一致，避免软件滞后导致产线停线。
- 配置对齐：整车配置字、VIN规则、变体编码必须与软件变体一一对应，产线刷写时自动匹配。
- 诊断对齐：EOL测试项、DTC清除策略、例程控制必须与诊断数据库同步发布。
- 安全对齐：网络安全准入、签名策略、密钥管理需与整车信息安全流程衔接。
- 变更对齐：任何软件变更需评估对整车功能、法规和产线的影响，走ECR/ECO流程。
工程实践中的关键控制点
为了让量产软件真正可交付，建议在CI与版本治理中落实以下控制点：
- 单一可信源：所有二进制、标定、诊断文件统一存入制品库，禁止从个人电脑直接取件。
- 自动构建与签名：每次发布由CI自动编译、打包、签名、生成哈希，减少人工干预。
- 版本命名规范：采用“项目_硬件版本_软件基线_变体_日期”结构，便于检索和比对。
- 发布门禁：未通过静态检查、单元测试、HIL冒烟测试的版本不得进入量产候选。
- 刷写验证：在产线试刷工位验证刷写时间、重试次数、失败恢复和EOL诊断通过率。
- 变更影响分析：任何变更需列出受影响的ECU、变体、诊断项和法规项。
下面用一张关系图概括ST Stellar量产软件从构成到交付、再到与整车流程衔接的核心关系。图中左侧是软件构成要素，中间是交付物与版本治理，右侧是整车开发流程的衔接点，箭头表示输入、约束和反馈关系。
这张图强调了一个核心事实：量产软件工程不是“把代码编译出来”就结束，而是要把软件构成、交付物、版本治理和整车流程串成一条可追溯的链路。左侧的每一类软件资产，最终都要以中间交付物的形式被管理；中间的版本治理能力，又必须与右侧整车开发节点、配置、诊断、安全和变更流程对齐。只有这条链路闭合，ST Stellar量产软件才能在产线、售后和OTA场景中稳定运行。
因此，在CI与版本治理实践中，建议把“软件包完整性检查”作为发布门禁的一部分：检查二进制、标定、诊断、签名、版本说明是否齐全，检查变体与配置字是否匹配，检查刷写脚本是否经过产线验证。只有这些条件同时满足，软件版本才具备进入量产候选的资格。