1. 课程导入与版本治理全景
在施耐德电气自动化项目中，一个看似普通的控制柜背后，往往同时存在多个"版本"：PLC 程序有 V1.2 和 V1.3，HMI 画面有现场调试版和最终交付版，库文件有厂商标准库和项目自定义库，甚至同一台设备的 Control Expert 工程文件在不同工程师电脑上各存一份。当现场出现故障需要回溯"到底哪一版程序在运行"时，如果没有人能立刻回答，版本治理的缺失就已经造成了实际风险。
本节要建立的，不是一套抽象的管理口号，而是一张能落到具体文件、具体设备、具体责任人身上的版本资产地图。我们先明确对象，再讨论目标与挑战，最后给出可操作的资产盘点方法。
一、版本治理管的是什么
施耐德自动化项目的版本资产，按载体可分为四类，它们各自有独立的版本节奏，却又必须保持协同：
- 项目工程文件：EcoStruxure Control Expert（原 Unity Pro）的
.sta、.stu、.xtu工程，Machine Expert 的.project，以及配套的变量表、硬件配置（如 M580、M340、M241 的 CPU 与模块组态）。 - PLC 运行程序：下载到 CPU 中的可执行逻辑，其版本与工程文件不一定一致——现场可能被在线修改过而未回存。
- HMI/SCADA 画面：EcoStruxure Operator Terminal Expert、Vijeo Designer 的工程，以及上位机 iFIX、Citect 的画面与脚本。
- 库与复用资产：DFB（派生功能块）、EFB、自定义 UDT、设备驱动模板、通信配置片段。库一旦被多个项目引用，其版本变更会横向影响所有引用方。
版本治理的定义可以概括为：对上述资产在时间轴上的每一次有效变更进行标识、记录、受控发布与可追溯回溯，使"当前生效版本"始终唯一且可验证。它区别于简单的文件备份——备份只保证"有副本"，治理保证"知道哪份是权威版本、为什么变成现在这样"。
二、目标与核心挑战
治理目标通常落在四个可检验的维度上：唯一性（任一时刻每个资产只有一个受控版本）、可追溯性（能回答谁、何时、为何修改）、可复现性（能由受控版本重建出与现场一致的运行状态）、协同性（多人多专业并行时不互相覆盖）。
而实际挑战恰恰来自施耐德工具链的特点。Control Expert 工程文件是二进制复合结构，无法像文本代码那样做行级 diff，两人同时改一个 .sta 只能靠人工比对或导出 XEF 交换格式；Machine Expert 基于 CODESYS 生态，工程内嵌大量编译产物，文件体积大、合并困难；HMI 画面工程常与 PLC 变量表强耦合，变量改名会同时打断两侧引用。更隐蔽的是"在线修改"：工程师在调试时直接在线改一段逻辑并下载，未回存工程文件，导致工程文件与 CPU 实际程序出现分叉，这种分叉在数月后几乎无法凭记忆还原。
三、版本资产地图
把上述对象、版本节奏与协同关系画成一张图，比逐条罗列更容易看清依赖方向。下图以一台典型 M580 + 触摸屏的单机设备为例，展示四类资产如何从工程文件流向现场运行体，以及库文件如何横向影响多个项目。
图中三条关键关系值得注意：库文件通过"引用"进入工程文件，一旦库升级，所有引用它的项目都需要评估影响；工程文件通过"变量映射"驱动 HMI 画面，变量改名会同时打断两侧；工程文件通过"下载"进入 CPU，但下载是单向的，CPU 内的在线修改不会自动回流到工程文件，这正是版本分叉的根源。
四、从资产地图到可执行盘点
理解地图之后，第一步不是立刻上工具，而是做一次版本资产盘点。以下清单可直接用于项目启动或接手存量项目时填写，字段只保留与版本治理直接相关的项：
| 资产类别 | 具体对象 | 当前版本标识 | 存放位置 | 责任人 | 与现场是否一致 |
|---|---|---|---|---|---|
| 工程文件 | Line1_Main.sta | V1.3 / 2024-06-12 | 服务器 \Projects\Line1 | 张工 | 待核对 |
| PLC 程序 | M580 CPU 内程序 | 上传后比对 | 现场 CPU | 调试组 | 未知 |
| HMI 画面 | Line1_HMI.vdz | V1.2 | 服务器 \Projects\Line1\HMI | 李工 | 是 |
| 库文件 | Motor_DFB 库 | V2.0 | 库服务器 \Library | 王工 | — |
盘点中最关键的一列是"与现场是否一致"。核对方法很直接：用 Control Expert 连接 CPU，执行"上传"或"比较"功能，将 CPU 内程序与工程文件比对；若存在差异，说明现场被在线修改过，必须决定是以现场为准回存，还是以工程文件为准重新下载。这个判断不能靠猜，必须由工艺与调试负责人共同确认。