1. 课程导入与治理全景

在工业自动化领域，ctrlX AUTOMATION 并不是一套"装好就不动"的静态系统。它由 ctrlX CORE 控制器、ctrlX OS 操作系统、各类 ctrlX AUTOMATION App、工程工具（如 ctrlX WORKS）以及现场设备共同构成，任何一个环节的版本变化，都可能沿着"应用—运行时—固件—现场"这条链路向下传导。版本与变更治理要解决的，正是"谁在什么时候、把什么改成了什么、改完之后系统是否仍然可控"这一根本问题。本课程的目标，是让学员建立一套可落地的治理方法，而不是停留在"记得备份"这种口号层面。

五个核心术语：先统一语言，再谈治理

治理的第一障碍往往不是技术，而是术语混用。本课程统一使用以下五个概念：

• 版本（Version）：某个可交付对象在某一时刻的确定标识，例如 ctrlX OS 的 2.6.0、某个 App 的 1.4.2、PLC 工程的 V1.7。版本号本身只是标签，真正重要的是它对应的内容快照。
• 变更（Change）：从一个版本迁移到另一个版本的动作及其全部影响，包括升级、降级、参数调整、配置修改、App 增删。变更是有意图、有记录、可追溯的行为。
• 基线（Baseline）：经过验证、被正式批准、可作为后续对比与回退参照的一组版本组合。基线不是"最新"，而是"已知可用"。
• 发布（Release）：把某个基线正式交付到目标环境（产线、客户现场、测试台）并对外声明其状态的过程。
• 回滚（Rollback）：当变更未达预期时，把系统恢复到上一个已知可用基线的受控操作。回滚能力必须在变更前就具备，而不是出事后再想办法。

这五个术语构成一条闭环：版本是对象，变更是动作，基线是锚点，发布是交付，回滚是保险。缺少任何一个，治理链条都会断裂。

治理边界：管什么，不管什么

治理边界不清，会导致两种典型失败：要么管得过宽，把业务逻辑、工艺配方也纳入版本治理，造成流程臃肿；要么管得过窄，只记录固件版本，忽略了 App 依赖与配置差异，导致"版本号一样但行为不一样"。

本课程建议的边界是：纳入治理的对象包括 ctrlX OS 版本、ctrlX CORE 固件、已安装 App 及其版本、App 之间的依赖关系、关键系统配置（网络、用户权限、证书）、PLC 工程与库版本、以及现场设备的通信参数。不纳入治理的对象包括工艺配方数值、HMI 画面文案、临时调试参数——这些属于业务数据，应由业务系统管理，但它们的"变更入口"仍需被记录。

端到端治理框架：从需求到运维的六段链路

把治理落到工程实践中，可以拆成六个连续阶段，每个阶段都有明确的输入、输出与判断依据。下图展示了这条链路以及各阶段之间的反馈关系：

这条链路的关键在于"反馈"：运维阶段发现的版本漂移或异常，会触发新的变更请求，回到第②或第④阶段；而回滚则直接回到基线仓库。治理不是单向流水线，而是一个带反馈的闭环。

一个具体的治理场景：App 升级引发的连锁反应

假设某产线当前基线为：ctrlX OS 2.6.0、ctrlX CORE 固件 1.10.0、运动控制 App 1.4.2、PLC 工程 V1.7。现在需要把运动控制 App 升级到 1.5.0 以使用新的插补功能。

如果只做"升级 App"这一个动作，可能出现的后果是：新 App 依赖 ctrlX OS 2.8.0 以上的某个运行时接口，而当前系统仍是 2.6.0，升级后 App 无法启动；或者新 App 改变了默认的通信周期，导致 PLC 工程的扫描周期与运动控制不同步，出现位置偏差。这两种情况都不是"App 本身有问题"，而是版本组合出了问题。

正确的做法是：在测试台上先建立候选基线，把 OS、固件、App、PLC 工程作为一个整体进行验证。验证通过后，记录下这个组合的完整清单，再发布到现场。如果现场运行 48 小时后出现位置偏差告警，则依据基线清单回滚到 1.4.2 组合，而不是在现场逐个排查。

本课程的学习目标

学完本课程，学员应能够：

1. 用统一术语描述 ctrlX AUTOMATION 环境中的版本、变更、基线、发布与回滚；
2. 根据实际场景划定治理边界，判断哪些对象需要纳入版本治理；
3. 建立并维护一份可执行的基线清单，包含版本、配置与依赖关系；
4. 在变更前评估影响范围，在变更后依据明确指标判断是否达成目标；
5. 在变更失败时，按预定路径完成回滚，并记录回滚原因与结果；
6. 识别版本漂移、依赖冲突、配置不一致等典型风险，并采取预防措施。