1. 课程导入与治理框架
在三菱iQ-F系列PLC的实际工程中，程序版本混乱是导致现场故障、返工和停机的高频原因之一。很多项目在调试阶段会经历数十次程序修改，如果没有一套明确的版本与变更治理机制，最终会出现"现场运行的程序与工程师电脑里的程序不一致""不知道谁在什么时候改了哪一段""改完之后没有记录，出问题无法回溯"等典型问题。本课程的目标，就是围绕iQ-F这一具体平台，建立一套从需求提出到程序归档的完整治理闭环。
一、为什么iQ-F需要专门的版本治理
iQ-F（FX5U/FX5UC等）使用GX Works3作为编程与维护工具，工程以.gx3工程文件的形式存在，内部包含程序块、参数、软元件注释、标签、安全密码等信息。与单纯的文本代码不同，iQ-F工程具有几个特点，使得版本管理不能简单套用软件行业的Git流程：
- 工程是二进制复合体：程序、参数、注释、标签混在一个工程文件里，无法像文本那样逐行diff，只能依赖工具导出对照或人工比对。
- 现场与离线双轨：PLC内部保存的是"运行版本"，工程师电脑里保存的是"编辑版本"，两者可能不一致，必须显式比对。
- 修改往往发生在现场：调试期间经常直接在连接PLC的状态下在线修改并写入，容易绕过评审环节。
- 安全与权限绑定：iQ-F支持工程密码、块密码、CPU访问密码，版本治理必须与权限管理协同，否则归档文件可能无法被后续人员打开。
因此，iQ-F的版本治理不是"多存几个文件"，而是要解决可识别、可追溯、可还原、可授权四个核心诉求。
二、治理框架的整体结构
本课程采用的治理框架可以概括为"一条主线、四个角色、五个控制点"。主线是从需求到归档的闭环；四个角色分别是需求提出方、程序开发者、审核者、现场维护者；五个控制点贯穿整个生命周期，分别是需求登记、变更申请、修改实施、验证确认、归档发布。下图展示了这一框架的整体关系。
三、五个控制点的具体含义
需求登记是闭环的起点。任何一次程序修改，无论来自工艺调整、设备改造还是现场故障处理，都应先形成一条可识别的需求记录。记录内容至少包括：需求来源、期望功能、涉及设备、期望完成时间、验收方式。对于iQ-F项目，建议在需求登记时就明确涉及的是哪个程序块（如主轴控制块、报警处理块），因为iQ-F的程序按块组织，块是后续变更影响评估的最小单元。
变更申请解决"改不改、改多少"的问题。审核者需要评估三件事：一是影响范围，即本次修改会触及哪些程序块、哪些参数、是否影响安全回路；二是风险等级，涉及安全、联锁、急停逻辑的修改应定为高风险，必须经过仿真或离线验证；三是回退方案，即如果修改后现场异常，如何快速恢复到上一版本。iQ-F支持将工程导出为CSV格式的软元件注释和程序清单，审核时可借助导出文件做对照。
修改实施是开发者使用GX Works3进行编辑的阶段。这里的关键约束是：修改必须在受控的工程副本上进行，不允许直接在线修改后立即写入PLC。推荐做法是先从归档库取出当前基线版本，另存为带版本号的新工程，再在新工程上修改。修改过程中应同步更新程序块头部的注释，写明修改人、日期、变更内容摘要。
验证确认是闭环中最容易被忽视的环节。iQ-F提供了仿真功能，可以在不连接实际PLC的情况下验证逻辑；对于涉及通信、定位、模拟量的修改，则需要在实验平台或停机窗口进行在线验证。验证的核心动作是"比对"：将修改后的程序与基线版本比对，确认只有预期内的差异；将PLC内运行程序与工程文件比对，确认写入一致。GX Works3的"程序对照"功能可以辅助完成这一工作。
归档发布是闭环的收口。归档不是简单复制文件，而是要形成"版本包"：工程文件、变更记录单、验证结论、适用的PLC型号与固件版本、必要的密码说明。版本号建议采用"主版本.次版本.修订号"的形式，例如V2.1.3，其中主版本对应重大功能变更，次版本对应功能调整，修订号对应缺陷修复。归档后应通知现场维护者更新备份，并在设备档案中登记。
四、治理闭环的运转要点
上述五个控制点不是一次性走完就结束，而是循环运转。每一次现场故障处理、每一次工艺优化，都会触发新一轮循环。要让闭环真正转起来，需要把握三个要点：
- 基线唯一：任一时刻，必须有一个被明确认定为"当前有效"的基线版本，所有变更都从基线出发，避免多版本并行导致混乱。
- 记录同步：程序改到哪里，记录就写到哪里。变更记录单与工程文件必须同版本号、同日期、同责任人，不能出现"程序改了但记录没改"的情况。
- 权限受控：iQ-F的工程密码和CPU访问密码应与角色对应。开发者拥有编辑权限，审核者拥有查看与批准权限，现场维护者只拥有写入和备份权限，避免越权修改。