多车型版本管控体系

版本一多，「我这台车刷的到底是什么」就成了每天最高频的问题。我的解法很笨但有效： BSP 大包、CI 小包、MCU 包全部进一张版本矩阵，每次 MR 必须附 proto 变更说明，跨域接口维护一张 600 行的版本对照表——表先于人，任何版本都能三分钟内反查到打包产物。

接口迭代初版 → v2.7

对照表规模600 行

平台跨度XOS530–620

背景

SR2.0 测试期同时要管多条线的版本：车型上跨 E38b、E29 高配 XPU 和中配平台，系统上跨 XOS560、570、580 一直到 620 多个平台版本；产物上又分 BSP 大包（平台基线）、CI 小包（SOC 基于 RC 分支 + 待测试 MR 出包）、MCU 包三类。与此同时，行车感知「最后一公里」功能要在 CDU（座舱域）和 XPU（智驾域）之间走 SomeIP + proto 交换数据，接口从 2025 年 5 月初版开始持续演进。

问题

1. 版本组合爆炸：车型 × 平台版本 × 包类型，任何一个维度对不上，台架刷出来的就不是要测的东西。
2. 协议变更无追溯：每个 MR 都可能动 proto，没说清变了什么，联调就是猜谜。
3. 跨域接口演进快：CDU↔XPU 接口半年内改了十几次，proto 文件名都发生过互换，通道号对不上就直接通信失败。
4. ROM 黑盒：车上只有一个 ROM 版本号字符串，出问题想反查里面的 apk 和依赖库版本，没有固定路径。

方案

版本矩阵：三类产物全量登记

flowchart TD
    subgraph Car["车型维度"]
        E38B["E38b 高配 XPU"]
        E29["E29 高配 XPU"]
        MID["中配平台"]
    end
    subgraph Pkg["产物维度"]
        BSP["BSP 大包<br>平台基线"]
        CI["CI 小包<br>RC分支 + 待测MR"]
        MCU["MCU 包"]
    end
    REC["版本管控记录表<br>日期 / base分支 / build号<br>mapping / proto变更说明"]
    E38B --> BSP
    E29 --> BSP
    MID --> BSP
    Car -.每日取当天 SOC 小包.-> CI
    Pkg --> REC

管控记录表的每一条小包记录固定带这些字段：日期、base 分支（如 dev_e38a_xos5100_int_9.3.5-...-rc16）、build_type、build 号、mapping（如 1114,sr）、包下载路径、详细修改说明、备注。proto 变更说明是必填项——比如 2 月 9 日那条记录就完整贴了 XOS620 新增靠边停车信号的协议 diff：SDOverallMsg 新增 pullover_msg 字段，附 PulloverStatus、PulloverLane 枚举和 Point2f 结构体定义，外加一条「Point2f 从 sensor_fusion 移到 base_struct.proto」的结构调整。任何人拿到包就知道协议面变了什么。

BSP 大包单独一张表，从 2024 年 12 月的 XOS550 一路记到 2025 年 7 月的 XOS580，每条带 PDK 版本和构建时间戳。表格本身也见证了规模：原表行数打到上限，只能开续表接着追加。

跨域接口的版本对照表

CDU↔XPU 的 EXNGP 接口走 SomeIP（Service ID 0x4010），治理手段是一张按日期列展开的版本对照表：

sequenceDiagram
    participant C as CDU（座舱域）
    participant X as XPU（智驾域）
    Note over C,X: SomeIP Service ID 0x4010
    C->>X: CDCU_XPU_NAVI_ROUTING_INFO（0x0012）导航 v2 全量
    C->>X: CDCU_XPU_EXNGP_INFO（0x0023）EXNGP 用户操作
    X->>C: XPU_CDCU_EXNGP_INFO（0x8023）轨迹/定位/卡片/状态灯
    X->>C: XPU_CDCU_EXNGP_INTERNAL_MAP_DATA（0x8024）内部路全览图

表的每一列是一个日期的 proto 集合快照（proto_driving_0523.zip、proto_driving_0617.zip……），行是 Event ID、功能描述、通道号、proto 文件名。这张表抓到过真问题：0617 到 0703 两个快照之间，exngp_cdu_xpu_msg_info.proto 和 exngp_xpu_cdu_msg_info.proto 两个方向的文件名发生过互换——不看表直接拿新文件对老通道，就是一次通信事故。变更履历从 20250523 初版（车位到车位 2.0、建图灯、园区内部路、内部路全览）记到 v2.7（新增可激活卡片），中间经过 V1.2 需求补充、V1.3 车位偏泊与标签、V1.4 同步 SlotInfo/DoorWayInfo、V1.7 VPD 协议、V1.9 楼层垫片、V2.1 ArrowPointType 与上客区、V2.3 收藏车位、v2.6 全览箭头类型，累计 10+ 次迭代，每次都有日期、类型（R/M）、变更说明和变更人。

消息结构上也在演进中保持了扩展性：ExngpXpuCduInfoMsg 拆成 header + payload 两段，payload 用 oneof 承载 9 类业务（内部路状态灯、地图简要列表、自车位姿、导航轨迹、行中面板、UserId 请求、出入口经纬度等），新增业务只加 oneof 分支不动主干。

ROM 版本号反查三步法

flowchart LR
    A["ROM 版本号<br>V5.9.0.6810_20250827..."] --> B["第一步：内部打包平台<br>按日期 + 应用名查 apk 版本"]
    B --> C["第二步：内部 Maven 仓库<br>拼接路径定位产物目录"]
    C --> D["第三步：读依赖清单<br>ldsDependency.txt 反查库版本"]
    D --> E["例：lib_napa5<br>5.9.0_..._Release-USER"]

车上看到的 ROM 版本号形如 XMARTM7ZHF30E5_V5.9.0.6810_20250827014627.4_REV01_USERDEBUG_Alpha，反查路径固定三步：

1. 查 apk 版本：在内部打包平台按日期 + 应用名检索（5.0 时代应用名是 xpSubreality，6.0 是 envirodrive），得到形如 V5.9.0_20250826190100_Release 的 apk 版本号。
2. 定位 Maven 产物：内部 Maven 仓库按「应用名/版本号」拼路径，直达该次打包的产物目录，里面的 Release-public.ldsDependency.txt 是全量依赖清单。
3. 反查依赖库：以 3D 库为例，从清单拿到 com.xiaopeng.lib:lib_napa5:5.9.0_20250826190100_Release-USER，再拼库的产物地址，能看到 aar（272M）、buildInfo.txt 等文件，版本完全落地。

关键实现

记录字段即检查清单。 小包记录的 base/build/mapping 三件套不是形式主义：base 决定平台基线，build 号能回 Jenkins 那次构建，mapping 标明这次包改了哪几个仓（sr、sensor_fusion……）。台架报问题先对这三个字段，一半以上的「版本刷错了」在这一步就现形。

每日取当天 SOC 小包是纪律不是建议。 记录表明确写了「每日请取当天的 SOC 小包」——CI 小包生命期短，跨天取包等于引入一个不在矩阵里的版本，测出来的问题没法归档。

通道号一旦分配不改语义。 0x0012 导航 v2、0x0023 用户操作、0x8023 交互数据、0x8024 内部路全览，这些 Event ID 在 10+ 次迭代里保持稳定，变的只是 proto 内容。通道号稳定 + 内容可追溯，老版本车和新版本台架才能混着联调。

HMI 点检工具同步迭代。 版本管控不只是包，工具链也登记在同一张表里：sr_checker 支持命令行交互、单点/组合信号触发，祛掉了 docker 环境依赖，修过 sr_service 的 someip 服务异常——工具版本和软件版本放一起管，台架环境才可复现。

指标

指标	数值
行车接口迭代	20250523 初版 → v2.7，10+ 次变更全部留痕
版本对照表	600 行，5 个 proto 集合快照逐日对比
版本矩阵	XOS530–XOS620 多平台 × E38b/E29/中配多车型 × 3 类产物
管控表规模	原表行数达上限，开续表继续追加
ROM 反查	固定 3 步，版本号 → apk → 依赖库全链路落地

复盘

1. 版本管控的本质是把「记忆」外包给表格。 人的记忆在第三个并行版本时就开始出错，表不会。字段定死（base/build/mapping/proto 变更说明），填表成本固定，收益随版本数线性增长。
2. proto 文件名也会是事故源。 方向性文件名互换这种事，只有逐日期的快照对比表能暴露；靠 git log 跨仓库对文件名，效率低一个量级。
3. 反查路径要写成 SOP 而不是口口相传。 ROM 三步法固化之后，任何人拿到版本号都能自己查到底，版本问题的响应从「找懂的人」变成「按表操作」。
4. 这套管控和 Crash 分类治理体系、监控上报链路 是同一条稳定性战线：管控管「版本是什么」，监控和治理管「版本跑得怎么样」。