4. PLCnext固件与运行时版本管理

PLCnext 控制器在量产交付阶段最容易被忽视、却最容易在客户现场引发批量问题的，不是应用程序逻辑，而是固件与运行时版本的一致性。同一型号的 AXC F 2152，出厂固件可能是 2023.0 LTS，也可能是 2023.6，而应用工程可能基于某个特定版本的 PLCnext Runtime、EtherCAT 主站固件和 GSD 文件开发。如果交付时版本漂移，轻则功能异常，重则设备无法启动。因此，本章围绕四个核心动作展开：锁定、补丁、兼容性判断、升级与回滚。

一、固件版本锁定：从“能跑”到“可复现”

固件版本锁定不是简单记录一个版本号，而是把控制器固件、PLCnext Runtime、实时内核、通信协议栈（如 PROFINET、EtherCAT、Modbus）以及设备描述文件（GSDML、ESI）作为一个整体进行冻结。推荐在项目立项阶段就建立一份《版本基线表》，至少包含以下字段：控制器型号、硬件版本（HW Revision）、固件版本（Firmware）、Runtime 版本、实时补丁号、GSD/ESI 版本、工程编译版本、锁定日期、责任人。

例如某包装机项目锁定基线为：AXC F 2152，HW 03，Firmware 2023.0.3 LTS，Runtime 2023.0 LTS，EtherCAT 主站固件 1.2.1，ESI 文件版本 V1.8，工程编译版本 v1.4.2。量产时所有设备必须与该基线一致，任何一项不同都视为“版本偏离”，需要走变更评审。

二、运行时补丁策略：区分安全补丁与功能补丁

PLCnext Runtime 的补丁通常分为三类：安全补丁（修复 CVE 漏洞）、缺陷补丁（修复已知 Bug）、功能补丁（新增特性或接口）。量产阶段建议采用“安全补丁优先、功能补丁冻结”的策略：安全补丁在评估影响范围后尽快纳入基线；功能补丁除非客户明确需求，否则不进入量产版本。

补丁验证应至少覆盖：控制器启动时间、Runtime 服务状态、EtherCAT/PROFINET 通信稳定性、OPC UA 连接、Web 访问、SD 卡读写、掉电恢复。建议在实验室搭建一台“影子控制器”，先刷补丁并运行 72 小时压力测试，再决定是否推广到产线。

三、版本兼容性矩阵：把“能不能一起用”变成可查表

兼容性矩阵是版本管理的核心工具。它把固件、Runtime、工程编译版本、GSD/ESI、上位机软件（如 PLCnext Engineer）之间的匹配关系固化成一张表。下面给出一个示例矩阵（数据为教学示例，非实测结果）：

矩阵的使用方法是：交付前逐台核对实际版本，与矩阵中“推荐量产基线”行比对。若某台设备落在“需重新验证”或“不兼容”行，必须拦截并处理，不能放行。

四、升级与回滚方案：先能回，再敢升

升级前必须确认三件事：备份当前固件与工程、确认目标版本在兼容矩阵中、准备回滚介质。PLCnext 控制器通常支持通过 Web 界面、SD 卡或 PLCnext Engineer 进行固件更新。推荐流程如下：

1. 导出当前工程与配置，记录当前固件、Runtime、ESI 版本。
2. 将目标固件包放入 SD 卡指定目录，或通过 Web 界面上传。
3. 进入维护模式，执行固件更新，等待控制器自动重启。
4. 重启后检查 Runtime 服务、通信状态、I/O 映射、OPC UA 连接。
5. 若任一关键项异常，立即执行回滚：插入备份 SD 卡或通过 Web 界面恢复旧固件。

回滚方案的关键是回滚介质必须与当前量产基线一致，并且回滚后要重新验证通信与 I/O。建议在产线保留至少一张“黄金 SD 卡”，内含锁定基线固件与工程，作为最后一道保险。

五、量产交付中的版本核对清单

为了让版本管理真正落地，建议在出厂检验环节增加一张《版本核对单》，每台设备填写并签字。核对项包括：控制器铭牌型号与 HW 版本、Web 界面显示的固件版本、Runtime 版本、EtherCAT/PROFINET 固件版本、工程编译版本、ESI/GSD 版本、是否与基线一致、核对人、日期。任何一项不一致，设备不得进入包装环节。

总结来说，PLCnext 固件与运行时版本管理的本质是把不确定性挡在产线之外。锁定基线让版本可复现，补丁策略让安全与稳定平衡，兼容矩阵让判断有依据，升级回滚让变更可控。四者形成闭环，才能支撑量产交付的长期一致性。