2. PLC软件工程基础
在进入 Git 工程实践之前，必须先建立对 PLC 软件工程的基本认知。很多工程师习惯把 PLC 程序看作“一个项目文件”，但在实际工程中，一个可运行的 PLC 项目往往由硬件组态、程序块、符号表、变量定义、通信配置、HMI 画面、驱动参数和文档等多个部分组成。理解这些组成，是后续进行版本管理、差异比较和团队协作的前提。
一、PLC 项目的组成结构
以典型的西门子 TIA Portal 项目为例，一个完整的 PLC 工程通常包含以下层次：
- 设备与网络组态：CPU 型号、机架、分布式 IO、交换机、驱动器和通信接口的拓扑与参数。
- 程序块：组织块 OB、功能块 FB、功能 FC、数据块 DB，以及中断、循环、启动等执行逻辑。
- 变量与符号：PLC 变量表、用户自定义数据类型 UDT、常量、系统常量与符号名映射。
- 工艺与运动对象：轴、凸轮、PID 回路、高速计数、运动控制工艺对象及其参数。
- HMI/SCADA 画面：画面、报警、趋势、用户权限、配方和脚本。
- 项目文档与配置：硬件手册、IO 清单、通信地址表、版本说明和调试记录。
这些内容在开发环境中通常以“项目树”的形式组织，但在文件系统层面，它们可能被拆分为多个文件、数据库或压缩包。理解“项目树 ≠ 单个文件”这一点，对后续版本管理非常关键。
二、软件版本的概念
PLC 软件版本并不只是“V1.0、V2.0”这样的编号，它至少包含三个层面：
- 项目版本：整个 PLC 工程在某一时刻的完整快照，包含硬件、程序、HMI 和配置。
- 程序块版本：单个 OB、FB、FC 或 DB 的修改历史，例如某个电机控制 FB 从 V1.2 升级到 V1.3。
- 固件与库版本：CPU 固件、通信模块固件、全局库和第三方库的版本，它们会直接影响程序兼容性。
在传统开发中，工程师常用“项目名_日期_修改人”来命名备份文件，例如：
Line3_MotorCtrl_20240612_zhang_v2.zip
Line3_MotorCtrl_20240618_li_final_final.zip
Line3_MotorCtrl_20240620_li_final_ok.zip这种命名方式看似清晰，实际上无法回答“改了什么”“为什么改”“哪个版本对应现场设备”等关键问题。版本管理的核心，是让每一次变更都有记录、可比较、可回溯。
三、为什么 PLC 项目必须做版本管理
PLC 项目具有几个显著特点：现场调试周期长、多人协作频繁、硬件与软件强耦合、停机成本高。因此，版本管理的必要性体现在以下场景：
- 现场回退：新程序上线后出现异常，需要快速回到上一个稳定版本。
- 责任追溯：某次修改导致联锁失效，需要定位是谁、在什么时候、改了哪个块。
- 多人协作：电气、工艺、HMI 和调试人员同时修改不同对象，需要合并与冲突处理。
- 多设备复用：同一套程序要适配多条产线，需要分支管理和参数化差异。
- 审计与交付：客户要求提供完整的版本变更记录和最终交付基线。
常见误区：把“压缩包备份”当成版本管理。压缩包只能保存结果，不能记录差异、不能分支、不能合并，也无法与调试记录关联。真正的版本管理需要版本库、提交记录、差异比较和分支策略。
四、常见 PLC 开发环境与文件类型
不同品牌 PLC 的开发环境和文件组织方式差异很大，这直接影响 Git 的使用方式。下表列出常见环境及其典型文件类型：
| 开发环境 | 典型项目文件/目录 | 版本管理关注点 |
|---|---|---|
| 西门子 TIA Portal | .ap19 / .ap20 项目目录、.zap 归档、.scl、.db、.awl 源文件 | 项目目录为二进制数据库，建议导出源文件后纳入 Git |
| 西门子 STEP 7 Classic | .s7p、.scl、.stl、.db、.awl | 源文件可文本化，适合差异比较 |
| 罗克韦尔 Studio 5000 | .ACD、.L5X、.L5K | L5X/L5K 为可读导出格式，适合版本控制 |
| 三菱 GX Works | .gxw、.gxw2、.csv 注释文件 | 项目文件多为二进制，需配合导出功能 |
| 欧姆龙 Sysmac Studio | .smc、.smc2、.csv 变量表 | 变量表与程序分离，注意同步提交 |
| CODESYS / TwinCAT | .project、.tsproj、.xml、.st、.scl | 工程文件为 XML/文本，天然适合 Git |
从版本管理角度看，文件类型可以分为三类：
- 文本型：如 .scl、.st、.xml、.csv、.L5X，可直接 diff，适合 Git 管理。
- 二进制型：如 .ap19、.ACD、.gxw，Git 只能记录“变了”，无法显示“改了什么”。
- 混合型：项目目录中既有数据库文件，也有可导出的源文件，需要制定导出与提交规范。
实践建议：对于二进制项目文件，采用“导出源文件 + 提交源文件 + 归档项目包”的双轨策略。源文件用于差异比较和代码评审，项目包用于现场恢复和完整交付。
五、案例：一次典型的版本混乱复盘
某包装线项目在调试阶段由三名工程师轮流修改程序。现场出现“启动后输送带不动作”的问题，排查时发现：
- 工程师 A 在周一修改了 OB1 中的启动逻辑，但未记录。
- 工程师 B 在周三用旧版本覆盖了部分 FB，导致联锁条件丢失。
- 工程师 C 在周五上传了 HMI 画面，但 PLC 程序仍是周三的版本。
- 现场共有 7 个压缩包，命名相似，无法判断哪个是当前稳定版本。
最终通过逐块比对和现场试运行，花费了约 6 小时才恢复。如果使用 Git，可以快速查看提交历史、定位变更块，并通过分支回退到稳定版本。这个案例说明：版本管理不是“额外工作”，而是降低停机风险和沟通成本的基础设施。
六、本节要点清单
- PLC 项目由硬件组态、程序块、变量、工艺对象、HMI、通信和文档等多类对象组成。
- 版本不仅是编号，还包括项目版本、程序块版本和固件/库版本。
- 版本管理的核心价值是回退、追溯、协作、复用和交付审计。
- 不同开发环境的文件类型差异很大，文本型适合直接 Git 管理，二进制型需要导出策略。
- 压缩包备份不等于版本管理，必须建立提交、比较、分支和基线规范。