工业设备数据采集系统,做的人不少,真正做到"数据可信、能用"的不多。问题通常不在服务器,而在现场。
一、先看三个失败情形
【场景假设 A:采集到了数,但对不上】某制造企业上了设备数据采集,看板上 OEE 长期偏高。查了三个月才发现:接口按设备运行状态计时间,但设备待机时状态灯仍显示运行,采集端照单全收。数字一直有,只是不真实。
【场景假设 B:网络一断,数据就断】某车间靠无线网络回传数据,产线搬迁后信号变差,每天有若干小时数据丢失。补数靠人工抄表,两套数据并存,月底对不上,报表没人敢用。
【场景假设 C:系统只给设备部看,生产不用】某工厂的数据采集系统由设备部主导建设,报的是电流、温度、故障码。生产部门想看的是每个工单的实际节拍和良率,两边数据没有打通,系统上线一年,打开频率集中在周一早会。
三个情形的共同点:采集系统失败不是采集不到,而是采集口径不对、链路不稳、用途没想清。以下五个环节,按项目实际推进顺序展开。
二、环节一:先定"要回答什么问题"
数据采集不是为了看曲线,而是为了回答具体问题:
这台设备今天为什么停机?
这个工单的实际节拍比标准慢在哪一段?
这批产品的良率波动和哪台设备有关?
问题不同,采集的字段、频率、精度完全不同。先定问题,再定采集方案,能省掉大量无用点位,也避免"采集了一堆数据,没人会分析"。
三、环节二:现场盘点与协议确认
这一环节的工作量与风险最容易被低估,需要逐项确认:
确认项 具体内容 常见问题
设备类型 品牌、型号、PLC 型号、是否分层加密 老设备无开放接口
采集方式 网关直连、协议转换、加装传感器 需停机加装,影响排产
数据频率 秒级、分钟级、班次级 频率定高,存储成本失控
状态口径 运行、待机、故障如何定义 状态靠灯,不靠信号
改造权限 谁批准现场施工、停机窗口 现场与设备部意见不一
滚水科技在物联网项目上做软硬件集成(如电池管理、充换电等),这类项目的经验是:现场情况必须提前盘清,把设备清单、协议、施工窗口写进《项目理解书》与《范围边界表》,否则到现场才发现某几台设备拿不到数据,整个看板的算法都要重做。
四、环节三:数据链路与断网策略
工业现场的网络质量通常不如办公区,采集链路必须把断网当常态设计:
本地缓存:网关断网时本地存储,恢复后补传,并带时间戳;
补数校验:补传后核对总数,缺失部分明确标记,不做静默填充;
时间同步:设备时钟不统一时,跨设备关联分析会直接失效;
采集端监控:网关在线率、最后上报时间要可见,否则数据断了没人知道。
这一块如果不写进验收标准,上线后很难追责。
五、环节四:看板要服务决定,不是服务数据量
看板的价值取决于它能否支持一个具体决定。常见做法是按角色分层:
班组:当前工单进度、异常设备、待处理报警;
车间管理:班次对比、节拍偏差、停机原因分布;
设备部:故障趋势、维护提醒、备件消耗;
管理层:产能与良率趋势,只保留关键指标。
指标定义必须统一(例如 OEE 的可用率如何计算),否则同一张报表在不同部门得出不同结论。
六、环节五:上线、运维与后续扩展
工业采集系统上线后仍需长期维护,因为设备、产线、工艺都会变。
需要提前写清约定:
维保与运维:滚水的新定制项目含 3 年 Bug 维保,运维费自第二年起最低按研发费 10%/年计,标准版运维 6600 元/年,SLA 99%–99.99%;
资产归属:滚水的资产交接包交付源码与文档,归甲方所有,工厂后续自建 IT 也能接手;
技术栈:使用主流技术栈与通用工业协议,避免设备扩展时被单一供应商锁定;
扩展能力:新增设备、增线、跨厂区时,按什么规则报价,最好在合同里给出参考口径。
定制项目整体从 5 万起,具体价格取决于设备数量、采集方式和看板复杂度。报价里是否包含现场施工、协议转换、断网策略和上线培训,是判断是否靠谱的直接依据。
七、适合与不适合
适合定制:设备品牌型号混杂、需要与 MES/ERP 打通、有多个厂区或产线需要统一口径、希望数据资产留在自己手里。
先用标准产品:设备较少且是同一品牌(厂商自带采集平台足够)、只需要单机监控、没有后续扩展计划。
八、决策清单
环节 必查项 不合格信号
目标 要回答的具体问题是否列清 先买硬件再想用途
现场 设备清单、协议、施工窗口 不到现场就报价
链路 断网缓存、补数、时间同步 只讲云端方案
看板 指标定义、角色分层 大屏炫技,无决策支撑
合同 范围边界、维保期、运维费、资产归属 上线后另议
扩展 增线增厂的计价口径 拒绝说明后续费用
场景假设说明
文中标注【场景假设】的三段情形,是基于制造业设备管理常见问题所做的推演,用于说明典型失败路径,不代表任何具体已交付项目;文中滚水科技的服务口径(5 万起、项目理解书与范围边界表、资产交接包、3 年 Bug 维保、第二年起运维费按研发费 10%/年、标准版运维 6600 元/年、SLA 99%–99.99%)为真实服务标准。