3. 软件配置管理计划：配置项识别、基线定义、变更控制流程

说到安全气囊系统的配置管理，我得先跟你掏心窝子说一句：这玩意儿要是没管好，出事了可不是闹着玩的。我入行那会儿，亲眼见过一个项目因为配置项漏了，导致两版固件混用，台架上气囊直接误爆。嗯，从那以后，我对配置管理就特别较真。

今天咱们就聊聊配置管理计划里的三个核心：配置项识别、基线定义、变更控制流程。说白了，就是搞清楚「管什么」、「定什么标准」、「怎么改才不乱」。

3.1 配置项识别：你得知道管什么

配置项（Configuration Item, CI），就是你要纳入版本管理的所有东西。我个人习惯把安全气囊系统的配置项分成四大类：

类别	典型配置项	说明
源代码	主控芯片的C代码、ASM汇编、模型代码	包括算法、诊断、通信模块
配置文件	传感器标定参数、点火阈值表、CAN矩阵	不同车型的差异化配置
文档	需求规格书、设计文档、测试报告	每个版本必须配套
工具链	编译器版本、链接脚本、烧录工具	保证可复现构建

识别配置项时，我建议你遵循一个原则：凡是影响最终产品行为的，都要管。你想想看，一个标定参数写错了，气囊可能该爆时不爆，不该爆时乱爆。这比代码bug还隐蔽。

3.2 基线定义：给版本打上「锚点」

基线（Baseline），说白了就是一个经过正式评审、后续变更必须走流程的「快照」。在安全气囊项目中，我通常会定义三类基线：

• 功能基线：系统需求冻结时的状态。这时候所有功能需求都评审通过了，后续改需求必须走变更控制。
• 分配基线：软件需求分配到具体模块时的状态。比如「碰撞检测算法模块需求v1.0」冻结。
• 产品基线：通过全部测试、准备量产的版本。这是最严格的基线，改一个bit都要走完整变更流程。

基线的命名规则也很重要。我推荐用这种格式：AB_V1.2.3_Baseline_20250315。其中AB代表Airbag，V1.2.3是语义化版本，后面是基线建立日期。这样一看就知道是什么项目、什么版本、什么时候冻结的。

3.3 变更控制流程：改，但不能乱改

变更控制流程，是配置管理的核心。没有流程，基线就是摆设。我见过最糟糕的情况是：开发人员觉得「改个小参数没事」，直接改了代码就提交，结果导致整个系统的点火时序错乱。

一个标准的变更控制流程，应该包含以下步骤：

1. 提交变更请求：填写变更申请单，说明变更原因、影响范围、风险等级。
2. 变更评估：由配置控制委员会（CCB）评估。安全气囊系统的变更，必须包括功能安全工程师的评审。
3. 变更批准/拒绝：CCB做出决策。如果是紧急安全修复，可以走快速通道。
4. 变更实施：在受控环境中修改代码或配置。
5. 验证与确认：修改后的版本必须通过回归测试，特别是安全相关的测试用例。
6. 变更发布：更新基线，通知所有相关人员。

这里我贴一个实际项目中用的变更申请单模板，你可以参考：

变更请求单编号：CR-2025-0032
项目名称：XX平台安全气囊控制器
申请日期：2025-03-15
申请人：张三

变更描述：
将正面碰撞点火阈值从 12g 调整为 14g，以适配新车型的整车碰撞波形。

变更原因：
新车型整车刚度增加，原阈值导致误点火风险升高。

影响范围：
- 正面碰撞检测算法模块
- 标定参数配置文件
- 相关测试用例（需更新）

风险等级：中
（低：不影响安全；中：可能影响性能；高：直接影响安全）

CCB评审意见：
需进行至少3轮台架碰撞测试验证，通过后方可批准。
批准人：李四（功能安全经理）
日期：2025-03-16

你可能会问：「这么严格的流程，会不会拖慢开发进度？」会，但值得。安全气囊系统是生命攸关的部件，一次错误的变更可能导致无法挽回的后果。我个人的建议是：日常开发用分支管理，频繁提交；只有基线变更才走完整流程。这样既保证了灵活性，又守住了安全底线。

最后总结一下：配置项识别要全面，基线定义要清晰，变更控制要严格。这三件事做好了，你的版本管理就成功了一大半。下一章咱们聊聊版本号的命名规范和发布策略，到时候我会分享一个我踩过的坑——版本号乱编导致的「固件混淆事故」。