DCS 迁移:切换那天到底会出什么问题

2026-09-08

问生产经理担心迁移的什么,他会说新控制器。问一个真正做过迁移的人,他会说切换后第十八个小时的那个凌晨。

换控制器是大家都懂的部分。厂家有迁移工具,逻辑能转换,画面能搬过去。吃掉工期的,是迁移碰到但并不拥有的一切:2004 年敷设的电缆、某年夏天一次波动时有人改过的整定参数、一个放了太久以至于被当成正常操作的联锁旁路。

四种失效方式

失效方式怎么表现通常什么时候发现
现场接线和图纸不一致回路测不通;端子和编组表对不上回路测试时,最糟糕的时间点
没有记录的组态只存在于老控制器里的联锁和旁路开车后装置表现和以前不一样的时候
历史数据位号变了报表、看板和合规数据提取悄悄断掉几周后,有人跑月报的时候
没有回退方案第三个小时的一个缺陷变成非计划停车第三个小时

这些都不稀奇。四个都便宜得可以预防,昂贵得不该被发现。

报价之前先勘察接线

迁移前最有用的一件事,是核实现场接线和图纸一致。不是抽查,是核实。跑了十五年的装置,百分之几的不一致率是正常的,而两千个端子的百分之几就是六十个问题,不在这里发现就会在调试时碰上。

如果编组柜保留,勘察结果决定了进度表是否现实。如果编组柜更换,勘察结果告诉你现场电缆够不够长。

决定哪些继承、哪些重建

迁移是你能得到的修正错误的最便宜机会,也是引入只在异常工况才暴露的故障的最容易方式。两句话都对,所以这个决定必须明确做出,而不是留给做转换的人随手处理。

原样继承有意重建
控制逻辑与联锁——转换后逐行与源文件核对操作画面——按当前标准重建,让操作员在场
整定参数——它们代表多年的装置经验从来没做过合理化的报警限值和优先级
历史数据位号——让现有报表继续工作本来就不一致的命名
联锁旁路——但每一个都记录并指定责任人,不是悄悄复制任何没人能解释原始用途的东西

最后一行是尴尬的那一行。每套老系统里都有没人能说清的逻辑。原样搬过去不安全,删掉也不安全。可行的做法是列清单,每一项拿到书面的工程决定,把清单带进切换文件包。

切换文件包

四份文件,在任何人碰端子之前定下来。

文件必须包含什么
切换步骤逐小时,每一步有具名负责人,明确装置交给新系统的那个时间点
回退方案回退什么、谁做、按什么顺序、最晚在哪个小时之前还能回退。事前写好,不临场发挥
回路测试登记表每个回路在新系统上签认通过,装置才交给它
影子期开车后老系统保持可恢复多久,谁决定何时退役

一家拿不出书面回退方案的承包商,没有想过出问题的那一天。这不是文书上的挑剔——这是关于这个项目会怎么被执行的最清晰的信号。

分步还是一次到位

本能是一次停车全做完,因为看起来更便宜。有时候确实是。但比较的不是成本对成本,而是成本对风险敞口。

方式适合主要风险
一次切换能承受一次长时间计划停车的装置一切押在一个窗口上
分装置分步停车时间短的连续生产装置两套系统并存几个月,两者之间的接口必须能工作
并行运行可用性要求高,有场地成本最高;得有地方放第二套系统

连续生产装置通常适合分步路线,这也是最需要一个称职集成商的路线,因为新老系统之间的接口是真正的工程工作,不是组态。

该问投标方什么

四个问题,把做过的人和读过的人分开:

问题好的回答听起来像什么
你们怎么核实现场接线?一份带抽样比例或 100% 承诺的勘察范围,附价格
你们的回退方案是什么?一个描述清楚的步骤和决策截止时间,不是”我们恢复备份”
没有记录的逻辑怎么处理?一份登记表、一次工程评审、每项一个书面决定
切换时谁在现场?具名的工程师,而且是做了组态和 FAT 的那几位

相关:控制系统迁移工程、FAT 与调试

hi~ 说说你的需求,工程师会尽快回复你