3. BSP交付物定义与配置管理

BSP（Board Support Package，板级支持包）交付不是把一堆文件打包发给客户就结束，而是一次“可追溯、可复现、可验证”的工程交付。航电计算平台的BSP通常包含引导加载程序、板级初始化代码、设备驱动、操作系统适配层、构建脚本以及配套文档。如果交付物边界不清、版本命名混乱、基线没有固化，后续维护阶段就会出现“客户手里的二进制和源码对不上”“同一个版本号在不同项目里内容不同”这类难以排查的问题。本节围绕交付物清单、版本命名规则、配置管理工具与基线建立方法展开。

一、交付物清单：四类对象，各有验收口径

BSP交付物可以归纳为源码、二进制、文档、测试报告四类，但每一类都需要明确“交付什么、以什么形态交付、验收依据是什么”。

• 源码：包括BSP自身源码、必要的补丁（patch）、第三方开源组件及其许可证文件、构建脚本（Makefile、CMakeLists、Kconfig等）。源码交付的关键是“可构建”——客户拿到源码后，按文档说明能独立编译出与二进制一致的镜像。因此源码包中应包含构建依赖说明、工具链版本要求、编译命令示例。
• 二进制：包括引导镜像（如BootROM、U-Boot镜像）、内核镜像、设备树二进制（DTB）、根文件系统镜像、驱动模块（.ko）以及烧录工具。二进制必须附带校验值（如SHA-256）和烧录地址、启动参数等元信息，否则客户无法判断镜像是否完整、该烧到哪块存储。
• 文档：至少包含BSP发布说明（Release Notes）、硬件适配说明、编译与烧录指南、驱动接口说明、已知问题列表。发布说明中要写清支持的硬件版本、软件版本、变更内容和不兼容项。
• 测试报告：记录测试环境、测试项、测试结果和结论。航电场景下通常关注启动时间、驱动功能、中断响应、内存占用、长时间运行稳定性等。测试报告不是“跑过就行”，而要能回答“在什么条件下、测了什么、结果是否满足指标”。

下面这张图给出四类交付物之间的对应关系：源码经构建产生二进制，文档描述两者，测试报告验证二进制与源码的一致性。

二、版本命名规则：让每个交付物“自报家门”

版本命名规则的目标是：看到文件名或版本号，就能判断它属于哪个产品、哪个硬件版本、哪个软件阶段、是否可发布。航电BSP推荐采用“产品代号-硬件版本-软件版本-构建类型-构建号”的结构，例如：

ACU-BSP_V2.1.0_HW3.2_RC2_build20240612
│        │      │      │    │
│        │      │      │    └─ 构建日期/流水号
│        │      │      └────── 构建类型：RC(候选发布)/GA(正式发布)/DEBUG
│        │      └───────────── 软件语义版本：主.次.修订
│        └──────────────────── 硬件版本：适配的板卡版本
└───────────────────────────── 产品代号

语义版本中，主版本号变化表示不兼容的接口或架构调整；次版本号变化表示新增功能且向后兼容；修订号变化表示缺陷修复。构建类型用于区分内部调试版本和可交付版本，只有GA版本才允许进入正式基线。构建号建议使用日期加流水号，避免同一日期多次构建时无法区分。

三、配置管理工具：把交付物管起来

配置管理的核心是“受控”。源码使用Git管理，二进制和文档使用制品库（如Nexus、Artifactory）或带版本标签的发布目录管理。Git中应通过标签（tag）标记每次发布，标签名与版本命名规则一致，例如 ACU-BSP_V2.1.0_HW3.2_GA。二进制不建议直接提交到Git仓库，而应存入制品库，并在发布说明中记录其对应的Git提交哈希和制品库路径。

配置管理还需要维护一份配置项清单，记录每个配置项的标识、名称、版本、存放位置、负责人和状态。这样在客户反馈问题时，可以快速定位到对应的源码提交、二进制制品和测试报告。

四、基线建立方法：从“一堆文件”到“一个受控集合”

基线是经过评审和确认、后续变更必须走审批流程的配置项集合。建立基线通常按以下过程进行：

1. 确定基线范围：明确本次基线包含哪些配置项，例如BSP源码、二进制镜像、发布说明、测试报告。范围一旦确定，不在本次基线内的内容不得混入。
2. 冻结配置项：对源码打标签，对二进制计算校验值并入库，对文档和测试报告确认最终版本。冻结后任何修改都需要变更申请。
3. 一致性核对：用源码重新构建一次，确认生成的二进制与交付二进制一致（可通过比对校验值或关键段哈希）。这一步是基线可信的关键。
4. 评审与批准：由配置管理员、开发负责人、测试负责人共同评审，确认交付物齐全、版本正确、测试通过，然后批准基线。
5. 记录与发布：在配置管理系统中记录基线编号、建立日期、包含的配置项版本和审批记录，并通知相关方。

基线建立后，若需修改，应走变更控制流程：提出变更申请、评估影响、审批、实施、验证、更新基线。这样做的目的是保证任何时候都能回答“客户现场运行的版本对应哪份源码、哪份测试报告”。

综合来看，BSP交付物定义解决“交什么”，版本命名规则解决“怎么标识”，配置管理工具解决“放在哪、怎么管”，基线建立解决“什么时候冻结、如何受控”。四者配合，才能让航电计算平台的BSP交付在后续维护中保持可追溯、可复现、可验证。