3. OTA与版本治理核心术语体系

在NVIDIA DRIVE平台的OTA与版本治理工作中，术语混乱是导致沟通成本高、发布事故频发的首要原因。同一个词在不同团队口中含义不同，例如“镜像”在底层驱动团队指分区级二进制镜像，在应用团队却可能指容器镜像；“回滚”有人理解为重新刷写旧版本，有人理解为切换分区。因此，本节先把这套术语体系一次性讲清楚，并给出它们之间的真实关系。

一、从最小单元到可交付整体：固件、软件包、镜像

固件（Firmware）指运行在MCU、传感器、摄像头模组、网关等嵌入式控制器上的底层程序，通常与具体硬件强绑定，升级频率低、风险高。在DRIVE平台中，固件可能存在于Orin SoC的引导链、车载以太网交换机、ISP或电源管理芯片中。固件升级往往需要专用刷写通道，且一旦失败可能导致器件不可启动，因此固件通常不参与高频OTA。

软件包（Software Package）是版本治理的基本交付单元，通常以deb、rpm、容器镜像tar或自定义包格式存在。一个软件包包含元数据（名称、版本、依赖、校验和）与内容（可执行文件、库、配置）。在DRIVE平台上，一个典型的软件包可能是drive-tflite-runtime_1.2.3_arm64.deb，其版本号遵循语义化版本主版本.次版本.修订号。软件包是差分与全量更新的操作对象。

镜像（Image）是分区或存储介质的完整二进制快照，例如system.img、boot.img、rootfs.img。镜像可以整体写入分区，也可以被挂载后查看内容。镜像与软件包的关系是“打包层级”关系：多个软件包按规则组合、解压、安装后，再经文件系统制作工具生成一个镜像。理解这一层级，才能理解为什么“更新一个包”和“更新一个镜像”在耗时、风险、回滚粒度上完全不同。

二、全量与差分：不是二选一，而是按场景组合

全量更新指把目标版本的完整镜像或完整软件包传输到车端并写入。它的优点是逻辑简单、不依赖当前版本状态，缺点是传输体积大。例如一个完整的rootfs.img可能达到2～4 GB，在4G网络下耗时较长。差分更新只传输新旧版本之间的差异数据，车端再通过差分算法（如bsdiff、hdiffpatch）将旧版本与差分包合并生成新版本。差分包可能只有几十MB，显著节省带宽。

但差分更新有一个硬约束：差分包必须与车端当前版本精确匹配。如果车端当前是v2.3.0，而差分包是基于v2.3.1生成的，合并就会失败或产生错误结果。因此版本治理系统必须维护“当前版本—目标版本—差分包”的映射表。实际工程中通常采用组合策略：小版本迭代用差分，跨大版本或首次刷写用全量。

三、A/B分区、回滚与启动切换

A/B分区是在存储介质上保留两套可启动分区（Slot A与Slot B）。车辆正常运行时使用其中一个槽位（active），OTA时把新版本写入另一个槽位（standby），写入并校验通过后，通过bootloader切换启动标志，下次启动进入新槽位。如果新版本启动失败或自检不通过，bootloader可以自动切回原槽位，这就是回滚。

回滚的粒度取决于更新粒度：如果更新的是软件包，回滚可以只回退该包；如果更新的是镜像，回滚就是整个分区切换。A/B分区的代价是需要双倍存储空间，在DRIVE平台上通常通过分区规划来平衡。回滚不是“重新下载旧版本”，而是“切回已经存在的旧槽位”，因此速度快、可靠性高。

四、灰度、金丝雀与版本基线

灰度发布指新版本不一次性推送给全部车辆，而是按比例逐步扩大范围。例如第一批1%车辆，观察24小时无异常后扩大到10%，再到50%，最后全量。金丝雀发布是灰度的一种更严格形式，通常先选极少量“金丝雀”车辆（如内部测试车或特定区域车辆），这些车辆承担最高风险，用于最早暴露问题。两者的核心区别在于：金丝雀更强调“先导验证”，灰度更强调“逐步放量”。

版本基线（Version Baseline）是一组经过验证、相互兼容的软件包与固件版本的集合，是发布和回滚的参照点。例如某车型的基线可能是：drive-os 2.3.1 + tflite-runtime 1.2.3 + camera-fw 4.1.0。任何OTA都必须明确“从哪个基线到哪个基线”，差分包也基于基线生成。没有基线，差分更新和回滚都失去依据。

五、一个可执行的版本治理检查清单

在实际项目中，可以用下面这份清单快速核对术语是否被正确使用。它不是管理模板，而是工程沟通中的对齐工具：