4. 变更管理流程与MBSE融合

在传统系统工程中，变更管理往往以文档为中心：变更申请单、影响分析报告、审批记录、更改通知单、验证记录分别存放在不同工具中，彼此靠人工引用建立联系。当系统模型成为工程数据的核心载体后，变更管理必须与模型元素建立可追溯的绑定关系——每一次变更不再只是“改一份文档”，而是“改一组模型元素及其关联关系”。本节围绕变更请求、变更评估、变更批准、变更实施、变更验证、变更关闭六个阶段，说明如何把变更流程“挂”到模型上，使流程状态与模型状态保持一致。

一、变更请求：从模型元素发起，而非从文档发起

变更请求（Change Request, CR）的起点应当是可定位的模型元素。在MBSE环境中，一个合格的CR至少应包含：受影响的模型元素标识（如需求ID、功能ID、接口ID、状态机ID）、变更类型（新增/修改/删除/重构）、变更理由（需求变更、缺陷修复、接口不匹配、验证失败等）、提出人与提出时间。与文档式CR不同，模型化CR的关键在于“元素级定位”：不是笼统地说“修改电源管理需求”，而是精确到 REQ-PWR-014 及其关联的 FUNC-PWR-MODE 与 IF-PWR-CMD。

例如某无人机飞控项目提出CR-2024-017：因续航指标从45分钟提升至60分钟，需修改电池管理需求。该CR在模型中绑定三个元素：需求 REQ-BAT-003（容量阈值）、功能 FUNC-BAT-BALANCE（均衡策略）、接口 IF-BAT-TELEM（遥测字段）。这种绑定使后续评估可以直接沿模型关系遍历，而不必人工翻查文档。

二、变更评估：沿模型关系做影响传播

评估阶段的核心问题是“改一个元素，会牵动多少东西”。在MBSE中，这可以转化为一次关系遍历：从CR绑定的元素出发，沿 satisfy、derive、allocate、refine、verify 等关系向外扩展，得到受影响元素集合。评估内容通常包括：技术影响（功能、接口、状态是否需同步修改）、验证影响（哪些测试用例需重跑或新增）、成本与进度影响、风险等级。

以CR-2024-017为例，遍历结果可能显示：REQ-BAT-003 被 TC-BAT-011 验证，FUNC-BAT-BALANCE 被 FUNC-PWR-MODE 调用，IF-BAT-TELEM 被地面站 SUB-GCS-02 消费。因此影响面包括1条需求、1个功能、1个接口、1个测试用例和1个地面站子系统。评估结论应明确“必须同步修改”与“仅需确认”两类，避免过度扩散。

三、变更批准：CCB决策与模型基线冻结

变更批准由变更控制委员会（CCB）执行，决策依据是评估阶段输出的影响报告。在MBSE融合场景中，批准动作应产生两个可追溯结果：一是CR状态从“Under Review”变为“Approved”，二是对当前模型基线打一个“影响分析快照”标签。这个快照不是完整备份，而是记录CR绑定元素及其关系遍历结果，便于后续对比“批准时认为的影响面”与“实施后实际改动面”是否一致。

CCB决策通常有三种结果：批准、驳回、退回补充评估。退回时，CR状态回到“Under Review”，但应保留上一轮评估记录，形成评估历史。批准后，模型进入“变更实施”分支，原基线保持只读，避免实施过程中的中间状态污染已发布基线。

四、变更实施：在模型分支上完成元素级修改

实施阶段建议在模型分支（branch）上进行，而非直接修改主干。以CR-2024-017为例，实施操作包括：将 REQ-BAT-003 的容量阈值从“≥45min”改为“≥60min”；在 FUNC-BAT-BALANCE 中增加“低电量主动均衡”子功能；扩展 IF-BAT-TELEM 的遥测字段，新增 cellVoltageDelta；同步更新 TC-BAT-011 的预期结果。每一步修改都应记录“修改前值—修改后值—修改人—时间戳”，并与CR编号关联。

实施完成后，分支上应生成一份“实际改动清单”，与批准时的“影响分析快照”做差异比对。若实际改动超出批准范围，必须触发新的评估，而不是默认接受。这是MBSE变更管理与传统文档变更管理最显著的差异之一：模型关系使“超范围改动”可以被自动检测。

五、变更验证：验证证据与模型元素绑定

验证阶段要回答两个问题：修改后的模型元素是否满足新需求？修改是否引入了未预期的副作用？前者通过重跑 TC-BAT-011 等测试用例完成，后者通过回归测试和关系一致性检查完成。在MBSE中，验证证据（测试结果、仿真曲线、评审记录）应直接挂接到被验证的模型元素上，而不是单独存放在测试管理工具中。

例如，TC-BAT-011 重跑后输出续航仿真曲线，该曲线作为验证证据绑定到 REQ-BAT-003 的 verify 关系上。若验证通过，CR状态变为“Verified”；若失败，则退回“Implemented”并记录失败原因。验证阶段还应检查接口一致性：IF-BAT-TELEM 新增字段后，地面站 SUB-GCS-02 的解析逻辑是否已同步更新，否则会出现“模型通过、系统不通”的典型问题。

六、变更关闭：基线更新与经验归档

变更关闭不是简单地把状态改为“Closed”，而是完成三件事：第一，将实施分支合并回主干，生成新的模型基线（如v1.3），并记录基线差异；第二，归档CR全生命周期数据，包括请求、评估、批准、实施、验证各阶段的记录与证据；第三，提取可复用的经验，例如“本次影响传播路径中遗漏了地面站子系统，下次评估应增加消费端检查”。

关闭后，CR编号应保持可检索，且与新旧基线建立双向链接。这样当后续出现类似变更时，可以快速调取历史案例，判断影响面是否被完整覆盖。对于未通过验证而被驳回的CR，也应关闭并记录驳回原因，避免同一问题反复提出。

七、六阶段与模型元素的对应关系

需要强调的是，六个阶段并非总是线性推进。评估后可能退回请求补充信息，批准后可能因实施超范围而重新评估，验证失败后可能退回实施。因此在实际工具配置中，状态机应允许这些回退路径，而不是强制单向流转。模型化表达的价值正在于：无论流程如何回退，元素级绑定关系始终保留，影响分析可以随时基于最新状态重新计算。