1. 课程导入与迁移工程认知
在制造业现场，很多产线并不是“设计得不好”，而是“跑得太久”。当一条产线的控制核心仍是早期PLC-5、SLC 500或早期ControlLogix平台时，设备本身可能仍然稳定，但备件、软件、通信、诊断与合规能力会逐渐成为瓶颈。升级到ControlLogix（或同代Logix平台）并不是简单换一块CPU，而是一次涉及硬件替换、程序迁移、通信重构、I/O映射、HMI/SCADA适配、停机窗口与验证策略的系统工程。本课程的第一节，先不急于打开编程软件，而是把“为什么迁、迁到什么程度、边界在哪里、风险怎么控”讲清楚。只有认知对齐，后续的迁移才不会变成“边做边猜”。
一、典型动因：不是所有旧系统都必须马上换
旧产线升级的动因通常来自六个方面，现场很少只占一个：
- 备件与生命周期风险：PLC-5、SLC 500、1747/1771系列I/O、早期PanelView等已进入或接近停产阶段，二手备件价格波动大、质量不可控。一旦关键模块故障，停机时间可能从“小时级”变成“天级”。
- 软件与工具链落后：旧版RSLogix 5/500、RSNetWorx、老式DH+、RIO、ControlNet网络配置工具在新操作系统上兼容性差，工程师电脑升级后可能无法连接。
- 通信与数据孤岛：旧网络多为DH+、RIO、ControlNet，难以直接对接现代MES、OPC UA、EtherNet/IP、数据库与边缘网关，生产数据无法实时采集。
- 诊断与可维护性不足：旧程序缺少结构化标签、注释混乱、报警信息粗糙，故障排查依赖老师傅经验，人员更替后维护成本陡增。
- 产能与工艺调整：产线需要提速、增加配方、增加追溯、增加安全联锁或兼容新设备，旧CPU扫描周期、内存、指令集已接近极限。
- 合规与安全要求：安全回路、审计追踪、网络安全分区、远程访问控制等要求，旧平台难以满足。
判断是否“必须迁”，不能只看设备年限。更实用的判断是：关键备件是否还能在24小时内获得？程序是否还能被现有工程师读懂并修改？通信是否还能满足未来3～5年的数据需求？如果三个问题中有两个答案是否定的，升级就应进入规划。
二、迁移目标：从“能跑”到“可维护、可扩展、可验证”
迁移目标要分层，不能只写“换成ControlLogix”。建议分为四层：
- 功能等价层：原有逻辑、联锁、时序、配方、报警、HMI操作方式保持一致，确保迁移后产线能按原节拍生产。
- 硬件与网络层：CPU、I/O、通信模块、网络拓扑、IP规划、机架布局完成替换或重构，满足备件与通信要求。
- 程序与数据层：梯形图/功能块逻辑完成转换，标签命名规范化，注释、报警文本、配方结构可读可查，关键数据可被上位系统采集。
- 验证与交付层：形成可复现的测试用例、I/O点检表、联锁验证记录、停机切换方案与回退方案，确保迁移结果可被验证和交接。
这里要特别强调：“功能等价”不等于“程序照抄”。旧程序中的跳转、间接寻址、老式定时器/计数器、DH+通信指令，在ControlLogix中往往需要重构。迁移目标应允许在保持外部行为一致的前提下，对内部结构做合理化改进。
三、项目边界：先画清“迁什么、不迁什么”
项目边界是迁移工程最容易失控的地方。建议在启动前用一张“边界清单”明确：
- 控制范围：只迁主控PLC，还是连安全PLC、远程I/O、变频器、伺服、机器人接口一起迁？
- 网络范围：只换控制层网络，还是同时改造设备层、信息层？旧DH+设备是否需要网关过渡？
- HMI/SCADA范围：PanelView是否更换？上位机画面、报警、历史数据、配方是否同步迁移？
- 电气与柜体范围：是否利用原有柜体、端子、继电器、电源？新CPU和I/O模块的尺寸、供电、散热是否匹配？
- 停机与生产范围：是单机停机、整线停机还是分阶段切换？是否允许并行运行？
- 责任范围：程序迁移、硬件安装、网络配置、HMI修改、验证签核分别由谁负责？
边界不清的典型后果是：以为只换CPU，结果发现HMI通信协议不兼容；以为只改程序，结果发现旧I/O模块无法被新CPU直接识别；以为周末停机就能完成，结果联锁验证花了三天。边界清单不是形式，而是后续排期、报价和风险控制的依据。
四、风险清单：把“可能出事”提前变成“有对策”
旧产线迁移的风险具有明显的“现场性”。下面给出一份可直接参考的风险清单示例，字段包括风险项、触发条件、影响、预防措施与应急措施。表中参数为教学示例，实际项目需按现场情况调整。
| 风险项 | 触发条件 | 影响 | 预防措施 | 应急措施 |
|---|---|---|---|---|
| 程序逻辑遗漏 | 旧程序存在未注释的跳转、间接寻址或子程序 | 迁移后部分动作不执行或误动作 | 迁移前做全程序交叉引用与逻辑清单 | 保留旧CPU热备，按清单逐项回查 |
| I/O映射错误 | 旧机架/槽号与新ControlLogix机架不一致 | 输入输出错位，设备误动 | 建立旧新I/O对照表，逐点核对 | 强制点检，先空载测试再带载 |
| 通信不兼容 | 旧DH+、RIO设备无法直接接入EtherNet/IP | 远程站失联，产线局部停机 | 提前确认网关型号与协议转换能力 | 临时保留旧网络，分阶段切换 |
| 停机窗口不足 | 联锁验证、HMI联调耗时超出计划 | 产线无法按时恢复，影响交付 | 离线预调试，现场只做接线与验证 | 准备回退方案，旧系统可快速恢复 |
| 备件与供货延迟 | 新模块交期长或旧备件已停产 | 改造中断，工期顺延 | 提前锁定关键模块库存 | 调整迁移顺序，先做非关键区域 |
| 安全联锁失效 | 安全回路被误短接或程序未验证 | 人身或设备安全事故 | 安全功能独立验证，禁止跳过 | 立即停机，按安全规程复位 |
五、用一张图看清迁移工程的整体关系
下面这张SVG把本节的核心认知压缩为一张“迁移工程认知图”：左侧是典型动因，中间是迁移目标与边界，右侧是风险控制与验证闭环。图中对象均为本节真实讨论的工程要素，便于在后续章节中反复对照。
六、从认知到行动：启动前必须确认的几件事
在真正开始迁移前，建议完成以下动作，它们直接决定后续章节的推进质量：
- 收集旧系统资料：CPU型号、机架配置、I/O模块清单、网络拓扑、程序备份、HMI工程、电气图纸、历史故障记录。缺少程序备份的旧系统，迁移难度会成倍增加。
- 做一次现场核对：图纸与实物是否一致？I/O点是否被临时改动？通信线是否被改接？这些“现场真相”比图纸更重要。
- 确定迁移策略：是“整体切换”还是“分阶段切换”？是“程序转换”还是“重新编写”？是“保留旧网络过渡”还是“一次性替换”？策略不同，风险和工期差异很大。
- 建立基线：记录当前产线的节拍、关键工艺参数、报警清单、联锁关系。迁移后要用这些基线做对比验证，而不是凭感觉判断“好像没问题”。
- 明确回退条件：什么情况下必须回退到旧系统？回退需要多长时间？旧CPU和程序是否保持可用？回退方案必须在停机前演练或至少确认可行。