3. 量产项目配置基线建立

在Vector DaVinci的量产交付流程中，配置基线（Configuration Baseline）是贯穿开发、集成、测试与生产各阶段的核心锚点。它并非简单地把工程目录打包压缩，而是对一组经过验证的配置参数、生成代码、描述文件及其依赖关系进行冻结，并赋予唯一可追溯标识的受控集合。没有基线，任何一次参数修改都可能让"已验证"状态失效，量产一致性也就无从谈起。

一、基线的构成对象与冻结边界

一个可交付的DaVinci配置基线，通常由以下对象共同构成：DaVinci Configurator工程文件（.dpa）、各模块配置参数集（如CanIf、Com、Dcm、Dem、EcuC、Os等）、生成的ECU抽象层与MCAL配置代码、ARXML描述文件、以及对应的编译脚本与版本说明。冻结边界需要明确：哪些文件进入基线、哪些属于本地临时产物（如编译中间文件、日志、缓存）必须排除。

实践中建议以"可重新生成"为判断准则：凡是能由工程文件与参数集重新生成的产物，可以只记录其生成版本号而不必全部入库；而参数集本身、依赖的MCAL版本、编译器版本、DaVinci版本必须作为基线元数据固定下来。这样既控制基线体积，又保证可复现性。

二、版本命名规则的设计

版本命名是基线可追溯性的第一道保障。推荐采用"项目_ECU_配置类型_语义版本_日期"的结构，例如：PROJ_ECU1_CFG_V2.3.0_20250612。其中语义版本遵循主版本.次版本.修订号：主版本在架构级变更（如新增CAN通道、更换MCAL大版本）时递增；次版本在参数集功能调整（如新增DTC、修改Com信号布局）时递增；修订号仅用于修正性变更（如注释、非功能性参数微调）。

日期后缀用于区分同版本号的多次构建，但需注意：一旦基线冻结，同版本号不应出现两个不同内容的包。若发现冻结后仍需修改，必须升版本号而非覆盖。命名中避免使用空格、中文和特殊字符，确保在Windows、Linux及CI工具链中均可安全解析。

三、参数集冻结的实际操作

在DaVinci Configurator中冻结参数集，核心动作是"锁定工程状态并导出可复现包"。具体操作路径如下：

1. 在Configurator中完成所有参数修改后，执行Project → Verify Configuration，确保无跨模块引用错误、无未解析的ECUC引用。
2. 执行Project → Generate，生成BSW/RTE代码，并确认编译通过。此时记录生成日志中的模块版本号。
3. 使用File → Export → Configuration Package导出配置包，选择包含.dpa、参数集和ARXML的完整导出，排除临时文件。
4. 对导出包计算SHA-256哈希，写入基线元数据文件baseline_meta.json，字段包括：基线ID、版本号、创建时间、创建人、DaVinci版本、MCAL版本、编译器版本、哈希值。
5. 将配置包与元数据一并提交至受控仓库，打上Git tag（如cfg-v2.3.0），并设置为只读保护。

四、基线归档策略与目录组织

归档不是简单堆叠文件，而是按"可检索、可复现、可审计"原则组织。推荐目录结构如下：

PROJ_ECU1_CFG_V2.3.0_20250612/
├── config/          # .dpa 工程与模块参数集
├── generated/       # 生成的BSW/RTE代码
├── arxml/           # ECU提取与系统描述文件
├── doc/             # 版本说明、变更记录、已知限制
└── meta/            # baseline_meta.json、哈希文件、签名

归档存储建议采用两级策略：一级为PDM/PLM系统，用于正式交付与审计追溯；二级为Git LFS或制品仓库，用于开发团队快速拉取与CI集成。两者通过基线ID和哈希值关联，确保内容一致。对于量产项目，基线包应设置只读权限，任何修改必须通过变更请求（CR）流程，生成新版本基线而非就地修改。

五、常见问题与判断依据

实际项目中，基线建立常遇到三类问题：一是参数集未完全导出，导致重新生成时代码不一致；二是工具链版本未记录，换机器后生成结果漂移；三是归档目录混入本地临时文件，导致基线体积膨胀且难以审计。判断基线是否可交付，可检查三个条件：哈希可验证、工具链版本可查、重新生成结果一致。三者缺一，基线即不可用于量产交付。