3. 版本治理的基线策略

在Stateflow量产项目中，模型不是一次性交付物，而是随需求变更、缺陷修复、标定适配持续演进的活体资产。如果没有清晰的基线策略，团队很快会陷入“谁手里的模型才是对的”这种版本漂移困境。基线策略的核心，是把模型演进过程中的关键节点固化为可追溯、可复现、可比较的参照点，让功能开发、集成发布与紧急修复三条线各有所依。

三类基线的定位与关系

功能基线、发布基线与补丁基线并非三个独立仓库，而是同一模型谱系上不同粒度的“快照标签”。功能基线面向开发团队，记录某个功能特性完成并通过单元验证时的模型状态；发布基线面向集成与测试，记录一组功能基线合并、通过集成测试并具备上车条件的完整模型状态；补丁基线面向量产维护，记录在已发布基线上仅针对特定缺陷或标定需求所做的最小变更集合。

三者的关系可以用“功能基线向上汇聚、发布基线向下派生、补丁基线横向分叉”来概括。功能基线是发布基线的输入，发布基线是补丁基线的父节点。补丁基线必须明确声明其父发布基线，否则补丁将无法判断是否已包含在后续发布中，这正是版本漂移最常见的源头。

功能基线：以特性为单位的可验证快照

功能基线的建立时机，通常在一个功能特性的Stateflow逻辑完成、通过模型在环测试且代码生成检查无阻断项之后。此时模型处于“功能正确但尚未与其他功能集成”的状态。建立功能基线时，需要记录以下信息：功能名称与需求编号、模型文件路径与版本号、依赖的库模型版本、测试用例通过率、代码生成配置摘要。

例如，某车门控制功能完成后的功能基线可标记为 FB_DoorCtrl_v1.2，其元数据中记录需求编号 REQ-BCM-0457，关联测试用例 TC-Door-001~018 全部通过，代码生成目标为 ert.tlc，优化等级为 -O2。这些信息不必全部塞进模型文件名，但必须与标签一一对应地存入版本管理系统的标签注释或外部基线登记表中。

功能基线允许后续被合并、重构甚至部分废弃，但它一旦建立就不应被修改。如果功能逻辑需要调整，应建立新的功能基线版本，而不是在原标签上覆盖。这是防止版本漂移的第一道闸门。

发布基线：集成冻结与上车准入

发布基线是量产交付的核心参照。当一组功能基线经过集成、通过SIL/HIL测试、满足标定接口要求后，即可建立发布基线。发布基线的关键特征是“冻结”：模型结构、状态机转移条件、数据字典条目、代码生成配置均不再接受直接修改。任何后续变更必须走补丁流程。

建立发布基线时，建议执行一次完整的基线审计，检查以下项目：所有功能基线是否已合并且无冲突；模型引用是否全部解析到已基线化的库版本；Stateflow中的状态、转移、数据对象是否与需求追踪矩阵一致；代码生成报告中的RAM/ROM占用是否在预算内；是否存在未解决的静态检查告警。

发布基线的标签命名应包含项目代号、版本号和日期，例如 RB_BCM_2024Q3_v2.1.0。该标签一旦创建，在版本管理系统中应设置为受保护标签，普通开发人员无权限移动或删除。发布基线对应的模型快照，是后续所有补丁基线的唯一合法父节点。

补丁基线：最小变更与父基线绑定

补丁基线用于量产后的缺陷修复或标定适配。它的核心原则是“最小变更”：只修改与缺陷直接相关的状态、转移或数据对象，不引入重构、不升级库版本、不调整无关参数。补丁基线的建立流程通常如下：从指定发布基线拉出补丁分支；在分支上完成修复并记录变更说明；通过针对性的回归测试；建立补丁基线标签，标签中必须包含父发布基线编号。

例如，某发布基线 RB_BCM_2024Q3_v2.1.0 发现车门解锁状态在特定条件下未正确迁移，修复后建立补丁基线 PB_RB_BCM_2024Q3_v2.1.0_p1。该标签的注释中应写明：父基线为 RB_BCM_2024Q3_v2.1.0，修复内容为“修正Unlock状态在车速信号抖动时的误迁移”，关联缺陷编号 BUG-2311，回归测试用例 TC-Door-007, TC-Door-012 通过。

补丁基线建立后，必须同步更新发布基线的补丁登记表。后续若基于同一发布基线建立新的发布基线，集成负责人应检查所有补丁基线是否已被吸收。如果补丁未被吸收，则新发布基线将丢失该修复，造成版本漂移。因此，补丁登记表不是可选项，而是发布基线的必要附属产物。

基线策略的落地要点

要让三类基线真正发挥作用，需要把基线操作嵌入日常工具链，而不是依赖人工记忆。在版本管理系统中，功能基线、发布基线、补丁基线应使用不同的标签前缀，并通过权限控制区分可移动与不可移动标签。在持续集成流水线中，每次建立发布基线应自动触发一次完整构建与测试，并将结果归档到基线记录中。在需求管理工具中，发布基线应关联到具体的软件版本号，补丁基线应关联到缺陷单或变更请求。

总结来说，功能基线管“特性对不对”，发布基线管“集成能不能上车”，补丁基线管“修复有没有丢”。三者通过明确的父子关系和标签纪律串联起来，才能让Stateflow模型在长达数年的量产维护周期中保持可追溯、可复现，避免版本漂移带来的集成灾难。