2. Studio 5000项目文件结构解析

在版本治理中，最容易出问题的往往不是“改了什么”，而是“改在了哪一层”。Studio 5000 的工程对象并不是平铺存放的，而是按 .ACD 文件 → 控制器组织器 → 程序 → 例程 → 标签/指令 的层级嵌套组织。理解这套结构，才能判断一次修改会影响哪些对象、需要同步哪些版本、回滚时应该恢复到什么粒度。

一、.ACD 文件：整体容器与版本边界

.ACD 是 Studio 5000 的项目归档文件，它把控制器属性、任务、程序、例程、标签数据库、Add-On 自定义指令（AOI）、用户自定义数据类型（UDT）、I/O 配置、安全对象等全部封装在一个二进制容器中。对版本治理而言，.ACD 是最小可交付、可归档、可回滚的完整单元——它没有“部分保存”的概念，任何一次保存都会生成一个新的整体状态。

因此，.ACD 的敏感度是最高的：只要文件被保存，无论改动多小，整个文件的哈希都会变化。实践中不建议用文件大小或修改时间判断“是否真的改了逻辑”，而应结合 Logix Designer 的工程对比工具或第三方版本工具，比较内部对象差异。同时要注意：.ACD 与固件版本、Studio 5000 版本存在兼容约束，例如用 V33 打开并保存过的项目，通常无法再用 V32 直接打开，这本身就是一次不可逆的版本跃迁。

二、控制器组织器：任务与执行结构的骨架

控制器组织器（Controller Organizer）是工程对象的树形视图，它反映的是运行时的执行结构，而不只是文件目录。其核心层级为：控制器 → 任务（Task）→ 程序（Program）→ 例程（Routine）。任务分为连续任务、周期任务和事件任务；周期任务带优先级和周期时间，事件任务由特定触发条件驱动。

这一层的敏感度体现在执行语义上：修改任务类型、周期、优先级，或调整程序在任务中的归属，会直接改变扫描行为与实时性，属于高风险变更。相对而言，仅重命名程序或调整组织顺序，对运行逻辑影响较小，但会影响交叉引用和文档一致性。版本治理中应把任务与程序结构视为“接口层”，任何变动都要在变更记录中单独标注。

三、程序、例程与标签：逻辑与数据的实际载体

程序是逻辑分组单位，内部包含例程和程序级标签。例程是真正承载代码的对象，支持梯形图（RLL）、功能块图（FBD）、顺序功能图（SFC）、结构化文本（ST）等语言。一个程序通常有一个主例程，其余为例程或子例程，通过 JSR 调用。

标签系统分为控制器级标签和程序级标签。控制器级标签全局可见，可被多个程序访问；程序级标签只在所属程序内可见。标签还区分基本数据类型、结构体（UDT）和数组。这里有一个对版本治理非常关键的规律：越是被广泛引用的对象，敏感度越高。修改一个控制器级标签的数据类型或名称，可能同时影响数十个例程和 HMI 引用；而修改某个程序内部的局部标签，影响范围通常局限在该程序内。

四、Add-On 自定义指令：封装带来的高敏感度

AOI 是把一段逻辑连同参数、局部标签封装成的可复用指令，在例程中像内置指令一样调用。它的价值在于复用与一致性，但也是版本治理中的“隐形炸弹”：一个 AOI 可能被几十处调用，修改其内部逻辑或参数定义，会同时改变所有调用点的行为。更麻烦的是，AOI 有独立的定义版本，当项目中存在多个同名不同版本的 AOI 时，需要明确当前使用的是哪一个定义。

因此，对 AOI 的变更应遵循“先评估调用点、再修改定义、后验证全部调用”的顺序。建议在变更记录中记录 AOI 名称、定义版本、调用位置清单和修改前后的参数签名。若 AOI 参数列表发生变化，所有调用点都需要重新校验，否则可能出现参数错位。

五、敏感度分级与变更影响判断

把上述对象按版本敏感度归纳，可以得到一个实用的判断框架：

六、实操：用差异对比定位变更层级

假设现场反馈“某台设备启动逻辑变了”，但不确定改在哪一层。可按以下方式定位：

1. 先用 Studio 5000 的工程对比功能，将当前 .ACD 与基线版本比较，确认差异集中在哪个程序或例程。
2. 若差异出现在例程逻辑，进一步查看该例程引用的控制器级标签和 AOI 是否也有变化。
3. 若 AOI 定义有变化，导出其调用点清单，逐一确认参数是否仍然匹配。
4. 若任务或程序结构有变化，检查周期任务时间是否被改动，必要时用任务监视功能观察实际扫描时间。

理解这套层级结构后，后续的版本命名、分支策略、回滚粒度和变更评审，都可以围绕“对象层级 + 敏感度”来设计，而不是把所有修改都当成同一类事件处理。