老 SCADA 跑不动了，但新平台能读懂我们的设备吗？

判断时关注的线索

• 现有自动化设备协议清单已形成但不完整
• 数据采集频率和延迟要求已被生产端提出
• 边缘计算需求与 MES/ERP 接口标准未对齐
• 供应商的工业协议支持深度尚未用实测验证

典型场景。 本文用于解释一种常见工作处境，不代表真实客户、真实对话或已经发生的结果。

从一个熟悉的工作瞬间开始

生产总监在群里转发了一条消息：“老 SCADA 的维护合同快到期了，供应商也不愿续签。” 群内很快涌入了七八条推荐，有人提某国际大厂，有人推开源方案，还有人建议直接上云。消息刷得飞快，第二天没人能说清楚：推荐的平台到底能不能读懂我们产线上那几种 PLC？边缘端的数据清洗逻辑谁来负责？MES 对接的接口标准是现成的还是要重新开发？

你不是在做一个采购决定，而是在处理一个信息碎片：它可能是一个真正的项目引擎，也可能只是一个被过度讨论的噪音。区别在于：有没有人把设备协议、采集需求和接口责任写成可核实的条目。

一个任务至少需要什么

在把推荐转给 IT 部门之前，先确认四项信息是否已经有人收集过：

• 现有自动化设备协议清单。不只是 PLC 型号，还包括变频器、传感器、仪表和第三方子系统的通信协议与版本。清单不需要完美，但至少覆盖主要产线。
• 数据采集频率和延迟要求。不同场景对实时性要求差异很大：设备状态监测可能容忍秒级延迟，而安全联锁则需要毫秒级响应。没有这个区分，所有方案都是空谈。
• 边缘计算需求与 MES/ERP 的接口标准。多少数据在边缘处理、多少上云？已有的 MES 或 ERP 接口是标准 REST 还是定制中间件？这些决定了架构边界。
• 供应商的工业协议支持深度与长期维护承诺。声称“支持 Modbus”和真正理解某个具体品牌 PLC 的寄存器映射是两回事。要求供应商在真实设备上证明，而不仅仅是翻产品手册。

接着写明负责人和下一条核实问题。这样即使当天没有答案，团队也知道明天应该查什么。

为什么概念验证必须排在签约前面

工业 IoT 平台的销售周期很容易被压缩成“先签框架协议、再慢慢对接”。但协议兼容性不会因为签了字就变好。一条产线的接口验证失败，足以让整个项目的工期翻倍。

正确顺序是：选择最有代表性的一条产线 — 不是最简单的，而是接口最复杂、对生产影响最大的 — 让候选供应商在限定时间内完成端到端数据采集演示。从设备层到可视化界面，每一步都要有可观测的结果。只有当这条产线的数据质量、延迟和稳定性都达标，才算通过第一关。

工具应该放在流程的哪个位置

工具适合帮助团队持续发现相关讨论、合并重复线索并保留原文语境；它不应该替人确认设备协议兼容性、判断安全架构是否合规或做出最终选型决定。先有判断清单，再考虑自动收集。

常见问题

问：平台选型需要技术团队全部参与吗？

不需要。先由一位负责人列出设备协议清单和采集需求，再邀技术成员逐项核实。全团队一开始就卷入，容易变成无止境的功能比较会。

问：是否应该先让供应商做全量演示？

不建议。先在有代表性的产线上跑概念验证，验证协议兼容性和数据质量后再扩大范围。全量演示在没有明确验证标准之前，只会制造更多噪音。

下一次不要只转发截图

至少补上原始语境、负责人和下一条核实问题。一个可追踪的任务远比一个被淹没的截图有价值。关于怎样判断一个群是否值得持续关注，可阅读群活跃度与信号价值，并参考相关案例。

常见问题

平台选型需要技术团队全部参与吗？

不需要。先由一位负责人列出设备协议清单和采集需求，再邀技术成员逐项核实。

是否应该先让供应商做全量演示？

不建议。先在有代表性的产线上跑概念验证，验证协议兼容性和数据质量后再扩大范围。