
不少厂里决定从组态王换成 Web 组态,起点往往只是一句「浏览器能打开就行」。开工才发现:变量命名带着十年的拼音缩写,按钮脚本里藏着没人记得的下发逻辑,报警阈值搬过去了滞环没搬。本文不讲「一键迁移」,而是给一套能落到表格上的方法:先判断该不该迁,再盘点四张资产表、做概念映射、按五步推进,最后附工作量估算表、割接回退方案和五个高频失败点。
先判断:这次迁移该不该做
传统 C/S 组态本身并不脆弱,服役十几年仍在跑的组态王工程很多。真正的驱动力通常只有三个:需要浏览器或手机访问、需要嵌入 MES 或企业门户、旧画面本来就要改造。一条都不占,收益大概率撑不起投入。
按下面四步走一遍:
- 列缺口:旧系统缺什么——远程访问、Web 嵌入、移动端、多站点汇总还是统一账号。
- 看更便宜的解法:只缺远程访问时,Web 发布模块或受控远程桌面的成本可能远低于整体迁移。
- 估剩余寿命:计划服役期短于迁移周期的项目先不动。
- 圈出不可迁的部分:联锁、PID 回路留在 PLC 和本地安全系统。
迁移前盘点:四张资产表
| 资产 | 要盘什么 | 迁移用途 | 常见漏项 |
|---|---|---|---|
| 画面 | 数量、层级、共用模板、跳转关系 | 决定重建顺序与复用方式 | 隐藏的弹窗与临时画面 |
| 变量 | 名称、类型、单位、量程、读写属性 | 建立新变量字典,避免重名 | 隐式赋值与中间计算量 |
| 脚本与命令 | 按钮脚本、画面脚本、定时任务 | 区分「可配置」与「必须写 JS」 | 画面加载时的初始化逻辑 |
| 报警与报表 | 报警点、阈值、滞环、延时、报表口径 | 还原告警语义而不只是搬数字 | 确认方式与通知人清单 |
最容易漏的是隐式逻辑:某个变量在画面加载时被赋了初值,某个按钮点击后顺手改了另一个图元的颜色。让熟悉旧项目的值班员带人走一遍完整操作流程,边看边记,比翻工程文件有效得多。
概念映射:按语义对,不按名字对
| 组态王里的东西 | Web 组态里的对应物 | 注意点 |
|---|---|---|
| 变量 / 寄存器 | dataId 变量绑定 | 类型、单位、量程要一起迁 |
| 图元 / 动画 | SVG 图元 + 属性状态切换 | 动画改成配置,不再靠脚本轮询 |
| 按钮脚本 | 触发 × 行为编排 | 先看能否用配置替代代码 |
| 画面跳转 | 打开 / 关闭 / 返回画面行为 | 层级关系要重新设计 |
| 报警阈值 | 值域进入离开 + 滞环 + 延时 | 只搬阈值会导致频繁抖动 |
| 历史曲线 | 历史曲线 / 趋势报表 | 核对查询口径与采样周期 |
| 报表 | 报表组件与数据导出 | 口径、时区、统计粒度逐项核对 |
| 用户与权限 | 角色 + 画面权限 + 操作审计 | 旧系统的班组概念要重新建模 |
映射原则:旧系统里一个「启动」按钮常同时做了下发、改色、写日志三件事,在新系统里应拆成三个行为,而不是硬塞进一段脚本。
这里也藏着迁移最实在的长期收益:传统 SCADA 工程多为专有二进制格式(WinCC Classic 混合二进制,iFIX、CIMPLICITY 同样专有),无法 Git diff;Web 组态工程以 JSON 保存,可 diff、可回滚、可审计,画面改动终于能进版本库。
五步迁移流程
- 建变量字典。 按「设备.测点.属性」重新命名,旧名留在备注。字典必须在画图前定稿,否则联调阶段会陷入重命名泥潭。
- 画面分级。 分成总览、工艺段、设备详情、参数设置四类,先迁总览和只读详情,带控制的下发画面放到联调阶段。
- 重建画面。 用 2D 组态 拖拽重建,内置 3200+ 工业图元,常见设备无需从零画。先把点位、状态、跳转跑通,再调视觉。
- 联调数据。 历史趋势走 HTTP,实时值走 WebSocket,边缘侧走 MQTT,ricon 支持 20+ 主流协议。每个变量至少验证「正常值、越限值、断线恢复」三种状态。
- 分批割接。 新旧并行且两边先只读,确认数据一致后再切控制权限,每批只切一个工艺段。
五个常见失败点
失败点一:变量名直接照搬
旧变量名带着拼音缩写和序号,照搬之后新画面同样难维护。更麻烦的是重名和类型不一致——联调时才发现同一个变量在两张画面里含义不同。
失败点二:把脚本逐行翻译
旧脚本里大量代码其实是在补组态软件的能力缺口:手写闪烁、拼字符串、定时轮询。这些在 Web 组态里多数能用触发和行为配置完成,逐行翻译等于把旧包袱原样搬过来。
失败点三:画面一比一复刻
旧画面是按旧屏幕比例和旧操作习惯设计的,直接复刻只会得到一张「能看但不好用」的画面。迁移是重新设计信息层级的唯一机会。
失败点四:报警只搬阈值,不搬滞环
温度在阈值附近抖动时,没有滞环的报警会反复进入和解除,值班员很快会学着忽略它。迁移时要同时记录触发值、解除值、延时和确认方式。
失败点五:一次性全量切换
全量切换把数据问题、权限问题、操作习惯问题堆在同一天爆发,现场根本定位不了。按工艺段分批,每批保留旧系统只读入口和回退脚本。
工作量估算与割接回退
| 阶段 | 主要工作 | 估算依据 | 常见偏差 |
|---|---|---|---|
| 盘点 | 四张资产表 | 画面数、变量数、脚本数 | 低估隐式逻辑 |
| 重建 | 画面与图元 | 画面复杂度、图元复用率 | 低估视觉调整 |
| 联调 | 三通道与报警 | 变量数、接口数量 | 低估后端配合 |
| 割接 | 演练、切换、回退 | 工艺段数量、班次 | 低估现场协调 |
按「画面数 × 复杂度系数 + 变量联调 + 割接批次」拆开算,别用一个总人天拍脑袋。行业里流传的「直接升级」基本是营销话术:脚本、报警数据库、历史库链接这三样几乎必然重做,预算里必须单独留出来。
割接前确认三件事:新系统能独立查询历史数据、控制指令有回执和超时、值班员完成过一次演练。割接时保留旧系统只读运行,至少覆盖一个完整班次。回退不是「再切回去」那么简单——提前备好旧系统的启动介质、账号和网络配置,并确认回退后数据不会重复写入。
常见问题
传统组态的历史数据能一起迁吗?
能,但通常不是搬数据库文件。更稳的做法是按时间范围导出为中间表,再按新变量字典重新映射。迁移前先确认采样周期、时区和质量码,否则曲线会对不上。
旧画面里的自定义图元怎么办?
能导出为 SVG 的优先转 SVG,用 在线工具 整理图层和动画;导不出来的按外观重画,顺便统一线宽、配色和状态样式。
迁移期间两边数据会不一致吗?
并行阶段一定有时间差,尤其是轮询通道。两边先只读,取同一时刻的变量值比对,一致后再开放控制。不要用「看起来差不多」当验收标准。
一定要一次全量迁移吗?
不建议。按工艺段或产线分批,单批范围控制在值班员一个班次能熟悉的程度,批次之间留观察期。
迁移能省多少人天?
取决于旧工程资料的完整度和画面复用率。ricon 侧项目平均缩短 70% 实施周期,主要来自图元复用、JSON 工程可版本化和免装客户端,不包括资料缺失导致的盘点返工。
下一步:先迁一条产线
别先写一份 200 页的迁移方案。挑最典型的工艺段,把最难的十个点位先跑通,用试点结果反推全量计划。可以直接用 免费版 在在线编辑器里建一个只读画面,授权口径参考 定价页。
本文系统阐述传统组态向Web组态迁移的实操方法,涵盖迁移必要性判断、四类资产盘点、语义级概念映射、五步标准化流程(建变量字典、画面分级、重建、联调、分批割接),并重点剖析五个高频失败点:变量名照搬、脚本逐行翻译、画面一比一复刻、报警滞环缺失、全量切换。同时提供工作量估算模型、历史数据迁移策略及分批回退方案,强调Web组态在可版本化(JSON工程)、协议兼容(MQTT/WebSocket/HTTP)和工业图元复用方面的技术优势。

403

被折叠的 条评论
为什么被折叠?



