2. 控制原型模型的生命周期
控制原型模型并不是“建完就结束”的一次性产物。它从需求被提出开始，经过建模、仿真、代码生成、测试、部署，最终走向退役，每个阶段都会产生新的版本，也会对版本治理提出不同的诉求。理解这条生命周期主线，是后续设计版本管理策略、分支模型和基线规则的前提。
需要先明确一个基本判断：控制原型模型的生命周期不是简单的线性流水线，而是带有反馈回路的迭代过程。仿真结果可能推翻建模假设，测试失败可能要求重新生成代码，部署后的现场数据又可能触发需求变更。因此，版本治理必须同时支持“向前推进”和“向后回溯”两种动作。
阶段一：需求——版本治理的起点
需求阶段的核心产物是控制需求规格，通常包括功能需求、性能指标、接口约束和安全边界。例如某电机控制原型的需求可能写成：转速阶跃响应上升时间不超过 80 ms，超调量小于 5%，采样周期 1 ms，支持 CAN 与上位机双通道标定。这些数字不是装饰，它们会直接决定后续模型的采样时间、求解器步长和代码生成配置。
需求阶段的版本治理诉求是可追溯。每一条需求都应有唯一标识（如 REQ-MOT-001），并记录其来源、变更原因和影响范围。当需求从“上升时间 80 ms”改为“60 ms”时，治理系统应能回答：哪些模型、哪些测试用例、哪些标定参数会受影响。如果需求只存在于文档中而没有纳入版本管理，后续所有阶段的追溯都会断裂。
阶段二：建模——结构版本与参数版本分离
建模阶段把需求转化为可执行的控制结构。以转速闭环为例，模型通常包含被控对象、控制器、传感器与执行器接口、标定参数表。这里有一个容易被忽视的治理要点：结构版本和参数版本应当分离管理。控制结构（如 PID 形式、前馈通道、滤波环节）的变更属于模型版本；而 Kp、Ki、Kd、滤波系数等数值的调整属于参数版本。二者混在一起，会导致“只是调了个参数”却产生大量无意义的结构差异。
建模阶段还应确定模型的接口契约：输入输出端口名称、数据类型、单位、采样时间。这些契约一旦被下游代码生成和测试引用，就应视为稳定接口，变更需要走评审流程。
阶段三：仿真——验证假设并固化基线
仿真阶段用模型在虚拟环境中验证控制策略。典型做法是运行阶跃、斜坡、正弦扫频和扰动抑制等工况，观察上升时间、超调、稳态误差和相位裕度。仿真通过后，应把“模型 + 参数 + 工况配置 + 结果”打包成一个仿真基线。基线不是最新版本，而是经过确认、可作为后续对比参照的版本。
仿真阶段的治理诉求是可复现。同一个基线，换一台机器、换一个求解器版本，结果应当一致或差异可解释。因此需要记录求解器类型、步长、容差、随机种子等元数据。否则当测试阶段出现不一致时，无法判断是模型问题还是仿真环境问题。
阶段四：代码生成——从模型到可执行产物
代码生成把模型转换为 C 代码或目标代码。这一阶段的关键治理对象是生成配置：目标编译器、优化等级、数据类型映射、函数接口风格、是否启用内联。同一模型在不同配置下会生成不同代码，因此“模型版本”和“代码版本”必须建立明确对应关系。
建议在生成产物中嵌入版本标识，例如在生成代码头部写入模型名、模型版本、生成时间、配置摘要。这样部署后一旦出现问题，可以从运行代码反查回模型版本，而不是靠人工记忆。
阶段五：测试——多层级验证与缺陷回流
测试阶段通常分为模型在环（MIL）、软件在环（SIL）、处理器在环（PIL）和硬件在环（HIL）。每一层验证的目标不同：MIL 验证控制逻辑，SIL 验证生成代码与模型等价，PIL 验证目标处理器上的数值行为，HIL 验证与真实被控对象的实时交互。
测试阶段的治理诉求是缺陷可回流。当 HIL 测试发现超调超标时，缺陷应能关联到具体需求、模型版本、代码版本和测试用例，并决定修复发生在哪一层。如果缺陷在代码层修复而没有回改模型，下一次代码生成会再次引入同样问题，这就是典型的版本治理失效。
阶段六：部署与退役——现场版本与历史归档
部署阶段把验证通过的代码刷写到控制器。此时应记录部署清单：控制器编号、代码版本、标定参数版本、部署时间、操作人。现场标定会继续产生参数版本，这些版本应能独立回滚，而不必重新生成代码。
退役阶段不是简单删除。退役意味着该版本不再维护，但仍需保留可追溯记录：退役原因、替代版本、最后部署范围。对于安全相关控制原型，退役记录往往是审计和事故分析的必要材料。
贯穿全生命周期的三条治理主线
把上述阶段放在一起看，可以提炼出三条贯穿始终的治理主线。
第一条是标识主线。需求 ID、模型版本号、代码版本号、测试用例 ID、部署批次号之间必须能建立双向链接。缺少任何一环，追溯就会断链。实践中常用“需求—模型—代码—测试”四列映射表来维护这种关系，每次变更同步更新。
第二条是基线主线。不是每个版本都值得成为基线，但每个关键节点都应有基线：需求冻结基线、仿真确认基线、代码发布基线、部署放行基线。基线的作用是提供稳定的比较参照，避免“和上周那个版本比”这种模糊表述。
第三条是变更主线。变更本身不可怕，可怕的是变更没有记录、没有评审、没有影响分析。一个可操作的规则是：任何影响接口、安全边界或标定语义的变更，都必须触发影响分析并更新追溯表；纯参数调整可以走轻量流程，但仍需记录版本。
最后需要强调，生命周期阶段的划分是理解工具，不是僵化的组织边界。实际项目中，建模和仿真往往交替进行，测试和代码生成也可能小步快跑。版本治理的价值，正是在这种迭代和交叉中，保证每一个被采用的版本都有据可查、有路可回、有责可追。