工业PLC数据采集上云全链路实战：协议选型、边缘网关与MQTT通道设计

工业现场的数据采集这件事说简单也简单说复杂能让人掉一把头发。我做了七八年PLC相关的项目从最早拿着笔记本蹲在配电柜旁边改梯形图到后来给几十条产线做集中监控踩过的坑基本能写一本小册子。这两年最明显的变化是甲方不再满足于中控室能看到数据就行而是要求把设备运行状态、产量、能耗、报警这些信息推到云端让手机能看、让MES能调、让老板在外地也能刷到实时曲线。这个需求听起来就是把数据传上去五个字但真正落地的时候从PLC到云端这条链路上每一段都有它自己的脾气。这篇内容我想把工业PLC数据采集上云这件事从头到尾拆一遍。不是那种PPT式的架构图讲解而是把协议选型、边缘网关配置、数据上云的通道设计、现场调试时那些文档里不会写的细节都摊开来说。适合正在做设备联网改造的电气工程师、做工业物联网项目的开发者也适合刚接触这块、想搞清楚数据到底怎么从PLC跑到云上的入门朋友。读完你至少能明白为什么不能直接把PLC连公网、Modbus和OPC UA到底该选哪个、边缘计算网关在里面扮演什么角色、以及数据上云之后怎么保证它不丢不乱。1. 先搞清楚数据从哪来PLC侧的数据可采集范围很多人一上来就问用什么网关其实更该先问的是我到底要采什么数据。PLC里能拿到的数据分好几类采集方式和难度完全不同搞混了后面全是返工。1.1 PLC内部寄存器的分类与含义以常见的三菱FX系列和西门子S7-200 SMART为例PLC内部的数据大致分这几个区输入输出点X/Y、I/Q、内部继电器M、数据寄存器D、VW、定时器计数器T/C。这些区域的物理含义差别很大。输入输出点反映的是实时电平状态采它主要是为了看设备启停、阀门开关这类开关量数据寄存器存的是数值比如温度、压力、产量计数这类是模拟量或累计量。这里有个特别容易踩的坑数据寄存器的断电保持属性。FX3U的D0到D8默认断电不保持设备一断电数据就归零。如果你采的是产量累计值结果每次停电后云端数据从零开始甲方能追着你问三天。解决办法是在PLC参数设置里把需要保持的寄存器范围改成断电保持区或者干脆在程序里做累计值掉电保护。这个细节在方案设计阶段就得确认别等上线了才发现。1.2 开关量、模拟量与累计量的采集差异开关量采集最简单读一个位就行但它对时序敏感。比如一个气缸动作只有200毫秒你网关的采集周期是1秒那这个动作大概率被漏掉。所以采开关量不能只看当前状态最好在PLC侧做边沿检测或者用高速计数器记录动作次数网关读计数值而不是读状态位。模拟量采集的核心是量程换算和滤波。PLC里读到的往往是一个0到27648的整数西门子或者0到4000的原始值三菱需要按传感器量程线性映射成实际工程值。这个换算放在PLC里做还是网关里做是个需要权衡的问题。放PLC里做网关只管读结果逻辑清晰但占用PLC运算资源放网关里做PLC负担轻但网关侧要维护每个点位的换算公式点位一多容易乱。我的习惯是关键工艺参数在PLC里换算好辅助监测点在网关侧换算这样既保证核心数据准确又不给PLC添太多负担。累计量最麻烦的是溢出和清零。16位寄存器最大32767一个产量计数很快就溢出了。要么用32位双字要么在PLC里做溢出进位逻辑。云端接收的时候还要判断这个值突然变小了是设备清零了还是寄存器溢出了处理不好报表上的产量曲线会出现莫名其妙的断崖。1.3 不同品牌PLC的数据访问方式三菱的MC协议、西门子的S7协议、欧姆龙的FINS、汇川的Modbus TCP每家都有自己的通信协议。做数据采集最怕的就是现场PLC品牌五花八门。我做过一个厂区改造项目一条线上同时有西门子、三菱、台达、汇川四种PLC如果每个品牌单独写一套采集程序维护成本高得吓人。这时候OPC UA的价值就体现出来了。它本质上是一个统一的数据访问标准不管底层是什么PLC只要有一个OPC UA Server把数据暴露出来上层采集程序就用同一套接口去读。但现实是很多老型号PLC本身不支持OPC UA需要额外的软件或者网关来做协议转换。所以选型的时候要算清楚是买支持多协议的网关硬件还是在工控机上跑一个协议转换软件成本和稳定性要一起考虑。2. 协议选型Modbus、OPC UA到底怎么选协议这块是方案设计里最容易争论的部分。有人张口就是OPC UA是趋势必须上也有人觉得Modbus用了二十年了稳定得很。我的观点是没有最好的协议只有最适合当前场景的协议。下面把几个主流选项掰开说。2.1 Modbus RTU/TCP的适用边界Modbus最大的优点是简单、普及、便宜。几乎所有的PLC、仪表、变频器都支持Modbus随便一个几十块钱的模块就能跑。它的数据模型也简单就是寄存器地址加功能码读保持寄存器、读输入寄存器、写线圈几个功能码走天下。但Modbus的局限也很明显。第一它是主从轮询机制一个主站轮着问各个从站从站多了轮询周期就长。我见过一个项目挂了三十多个从站轮询一圈要好几秒实时性根本谈不上。第二Modbus没有数据类型的概念它只知道寄存器里是16位数据至于这16位是整数、浮点数还是两个字节拼起来的全靠你自己约定。第三它没有完善的安全机制谁都能读写所以绝对不能把Modbus TCP直接暴露在公网上。Modbus适合什么场景设备数量不多、实时性要求不高、预算有限的场合。比如一个小型泵站五六个仪表采集周期几秒钟一次Modbus RTU走RS485总线稳定又省钱。2.2 OPC UA的信息模型优势OPC UA和Modbus不是一个层面的东西。Modbus解决的是怎么读到数据OPC UA解决的是数据是什么、怎么组织、怎么安全地传。它自带信息模型每个变量都有名字、类型、单位、描述客户端连上来一看就知道这个节点是1号反应釜温度单位是摄氏度而不是对着一个40001地址猜。OPC UA的另一个优势是订阅机制。Modbus是主站主动轮询OPC UA是客户端订阅数据变化了服务端主动推送。这在采集大量点位的时候效率高很多不用一遍遍问变了吗变了吗。但OPC UA的部署成本比Modbus高。老设备要加OPC UA Server要么换支持OPC UA的新PLC要么在中间加一层转换。而且OPC UA的配置比Modbus复杂得多证书、安全策略、端点配置每一项都能卡住新手。我的建议是新建项目、点位多、有跨系统集成需求的优先考虑OPC UA老设备改造、点位少、只做简单监测的Modbus够用。2.3 协议转换网关的选型逻辑现实项目里协议转换几乎是绕不开的。PLC只支持Modbus云端只认MQTT中间就得有个网关做转换。选网关的时候我一般看这几个维度维度关注点常见坑协议支持下行支持哪些PLC协议上行支持哪些云协议标称支持但实际固件版本不支持点位容量最大采集点位数、标签数点位一多轮询变慢实时性下降边缘计算能力是否支持脚本、公式换算、报警判断脚本语言难用调试困难断网续传网络中断时数据本地缓存多久缓存容量小断网时间长就丢数据配置方式网页配置、软件配置还是命令行配置界面反人类现场调试痛苦这里重点说断网续传。工业现场网络抖动是常态尤其是用无线传输的时候。网关如果没有本地缓存网络一断数据就丢了恢复后云端出现一段空白。好的网关应该支持断网时把数据存到本地存储网络恢复后自动补传。这个功能在验收的时候一定要测方法很简单拔掉网线等几分钟再插上看云端数据有没有断档。3. 边缘计算网关数据上云前的最后一道加工边缘计算这个词被炒得很热但落到工业数据采集场景里它干的其实就是一件事在数据离开现场之前把它处理成云端想要的样子。别把它想得太玄乎。3.1 边缘网关的核心职责拆解一个典型的边缘网关在数据链路里承担这些工作协议转换把PLC协议转成云协议、数据预处理换算、滤波、去重、本地存储断网缓存、报警判断本地先判断异常减少无效上云、安全隔离PLC在内网网关做边界。为什么要在边缘做这些而不是全丢给云端三个原因。第一实时性。有些报警需要毫秒级响应数据传到云端再判断再传回来黄花菜都凉了。第二带宽成本。一条产线几百个点位每秒都往云端推原始数据流量费能吓死人。边缘先做变化检测只推变化的数据流量能降一个数量级。第三可靠性。云端和现场之间的网络不可靠边缘网关要能在断网时独立运行保证现场监控不中断。3.2 数据预处理换算、滤波与变化检测数据预处理里最实用的是变化检测。PLC里很多数据是缓慢变化的比如温度可能几分钟才变0.1度。如果每秒都推一次99%的数据是重复的。边缘网关可以设置一个死区deadband只有变化超过阈值才上报。这个阈值怎么定看工艺要求。温度监测精度要求0.5度的死区设0.2度要求1度的死区设0.5度。设太小流量降不下来设太大曲线会失真。滤波是另一个常用处理。模拟量信号容易受干扰读上来的值会跳。简单的做法是滑动平均取最近N次的平均值。但滑动平均会引入延迟N越大越平滑但响应越慢。对于需要快速响应的参数可以用中值滤波取最近几次的中位数既能去掉毛刺又不明显延迟。3.3 断网续传与本地缓存的实现要点断网续传的实现逻辑不复杂网关维护一个本地队列正常时数据一边上云一边入队收到云端确认后出队断网时数据只入队不出队网络恢复后按顺序补传。关键在于队列的持久化。如果队列只在内存里网关一断电就全没了。所以要用本地存储做持久化SD卡或者eMMC都行。这里有个细节补传的数据要带原始时间戳。有些网关补传的时候用的是当前时间结果云端收到的数据时间全乱了曲线画出来是错的。配置的时候一定要确认网关支持带时间戳上报而且时间戳是数据产生的时间不是发送的时间。4. 上云通道设计MQTT、HTTP还是私有协议数据从边缘网关到云端走什么通道这个选择直接影响系统的稳定性和成本。4.1 MQTT的发布订阅模型为什么适合工业场景MQTT是我在工业上云项目里用得最多的协议。它的发布订阅模型天然适合多设备、多主题、一对多的场景。一条产线的数据发布到factory/line1/device1/data这个主题云端、MES、看板系统都可以订阅这个主题互不干扰。设备不需要知道谁在消费它的数据只管往主题上发就行。MQTT的另一个好处是轻量。协议头最小只有2个字节在窄带网络下也能跑。而且它支持QoS等级QoS 0是发了不管QoS 1是至少送达一次QoS 2是恰好送达一次。工业数据一般用QoS 1保证不丢偶尔重复可以在云端去重。但MQTT也有要注意的地方。心跳和遗嘱机制要配好。心跳间隔太短设备频繁发心跳浪费流量太长云端判断设备离线不及时。一般设30到60秒比较合适。遗嘱消息Last Will用来在设备异常断开时通知云端这个一定要配否则设备掉线了云端还以为它在正常运行。4.2 数据格式设计JSON还是二进制数据格式这块JSON可读性好、调试方便但体积大。一个包含时间戳和几个点位的JSON报文动辄两三百字节。二进制格式紧凑同样数据可能只要几十字节但调试的时候得对着协议文档一个字节一个字节地解痛苦。我的做法是调试阶段用JSON正式运行如果流量压力大再考虑二进制。大部分工业场景其实流量没那么紧张一条产线几百个点位变化检测之后每秒也就几十条报文JSON完全扛得住。除非是几千个点位的高频采集才需要上二进制或者压缩。数据格式设计还有个原则字段命名要自解释。别用v1、v2这种名字用temperature、pressure、motor_status。云端解析的人不用查文档就知道什么意思。时间戳统一用UTC毫秒数别用本地时间字符串跨时区会出乱子。4.3 云端接入层的安全设计安全这块必须单独说。PLC和边缘网关绝对不能直接暴露在公网。正确的做法是网关通过MQTT over TLS连到云端的接入服务器用双向证书认证。云端接入层做设备鉴权只有注册过的设备才能发布数据。网络架构上现场侧PLC和网关在同一个内网网关通过防火墙或者专线连到云端。如果现场只有普通宽带至少要用TLS加密别裸奔。我见过一个项目为了省事网关直接做了端口映射到公网结果被扫描到PLC被人乱写寄存器产线停了半天。这种教训一次就够了。5. 现场调试实录那些文档里不会写的问题方案设计得再漂亮现场调试才是见真章的时候。这部分我挑几个印象深刻的坑把排查过程完整还原出来。5.1 采集周期与PLC扫描周期的冲突有个项目采三菱FX3U的数据网关设的采集周期是200毫秒结果发现读上来的数据偶尔会跳变同一个寄存器这次读是100下次读是0再下次又是100。查了半天发现是网关的采集周期和PLC的扫描周期打架了。PLC的扫描周期是几毫秒到几十毫秒程序在每个扫描周期里更新寄存器。网关通过串口读数据的时候如果正好读到PLC更新寄存器的中间状态就可能读到不完整的值。尤其是32位数据分两个16位寄存器读中间被PLC程序改了拼出来的数就是错的。解决办法有两个一是在PLC程序里把要采集的数据集中到一个连续的区域并且用一次性赋值的方式更新减少中间状态二是网关侧对读到的数据做合理性判断比如连续两次读到的值差异超过量程的50%就丢弃这次读数等下次。我一般两个都做双保险。5.2 无线传输下的数据丢包排查另一个项目用4G无线传数据现场调试的时候发现云端数据时有时无。排查思路是这样的先看网关的发送日志确认数据有没有发出去再看云端接入日志确认有没有收到最后对比两边的时间戳看丢的是哪一段。查下来发现是信号强度波动导致的。现场在车间角落4G信号时好时坏。网关的MQTT客户端在信号弱的时候连接断开但重连逻辑写得不好断了之后要等好几分钟才重连。这段时间的数据虽然在本地缓存了但补传的时候又因为QoS设置问题丢了一部分。改进措施把MQTT的心跳间隔调短让网关更快感知到断线重连逻辑改成指数退避第一次断线1秒后重连第二次2秒第三次4秒避免频繁重连把模块搞死QoS从0改成1保证至少送达一次。改完之后数据完整率从80%多提到了99%以上。5.3 时间戳错乱导致的曲线异常这个坑最隐蔽。云端画出来的温度曲线白天正常到了晚上就变成一条直线第二天早上又恢复正常。一开始怀疑是传感器问题换了传感器还是这样。后来把原始数据拉出来看发现晚上的数据时间戳全是同一个值。原因是网关的NTP对时出了问题。网关默认从网络获取时间但现场网络晚上会做维护重启网关拿不到时间就用了本地RTC而RTC电池没电了时间停在了一个固定值。所有晚上产生的数据都带同一个错误时间戳云端按时间排序就成了一堆重叠的点。解决很简单给网关配一个可靠的NTP服务器并且开启RTC电池低电量告警。另外云端接入层加一个时间戳合理性校验如果收到的时间戳和服务器时间差超过一定范围就打标记而不是直接入库。6. 数据上云之后存储、展示与告警的衔接数据到了云端不是终点怎么存、怎么用才是甲方真正关心的。6.1 时序数据库的选型与写入优化工业数据是典型的时序数据带时间戳、写多读少、按时间范围查询。用关系型数据库存不是不行但数据量一大性能就崩。时序数据库TSDB专门为这种场景设计写入吞吐高、压缩比好、按时间分区查询快。选型上开源的有InfluxDB、TDengine、TimescaleDB云厂商也都有托管服务。我的经验是中小规模项目用TDengine或者InfluxDB就够了数据量特别大或者要求高可用的考虑云托管。写入的时候注意批量写别一条一条插攒够一批比如100条或者1秒批量提交写入效率能差好几倍。6.2 实时看板与历史报表的数据组织看板要的是实时性报表要的是完整性这两个需求对数据链路的要求不一样。看板可以容忍偶尔丢一两个点但延迟要低报表不能丢数据但可以等。所以我在设计的时候会把实时通道和历史通道分开实时数据走一条轻量通道直接推给看板历史数据走另一条通道保证完整入库。看板的数据组织也有讲究。别把所有点位都堆在一个页面上按设备、按工序分组每组只显示关键参数。工业现场的操作工不需要看几十个曲线他只需要知道当前设备正不正常、产量到没到、有没有报警。6.3 报警规则的边缘与云端分工报警判断放在边缘还是云端前面提过一句这里展开说。安全相关的、需要快速响应的报警放边缘比如设备过载、温度超限边缘网关直接判断并输出到现场声光报警同时上报云端。统计分析类的、需要跨设备关联的报警放云端比如这条线连续两小时产量低于阈值这种需要汇总多个设备的数据才能判断。两边都要有但职责要分清。边缘报警保证现场安全云端报警做管理分析。最怕的是两边都判断同一件事结果一个报了一个没报操作工不知道该信谁。7. 几个容易被忽略的工程细节最后这部分是我这些年攒下来的一些零碎经验每一条都是踩过坑才记住的。网关的供电。现场取电经常是跟PLC共用一个24V电源如果PLC电源容量不够网关一工作电压就往下掉导致网关反复重启。选网关的时候看清楚功耗留足余量最好单独供电。网线的走线。工业现场电磁干扰大网线跟动力线走在一起通信质量直线下降。网线要走单独的线槽跟变频器、伺服驱动器保持距离。如果实在避不开用屏蔽网线屏蔽层单端接地。IP地址规划。改造项目最容易出IP冲突。PLC、网关、触摸屏、摄像头每个设备都要IP。改造前先把现有IP摸清楚做个表新设备分配的时候避开。我习惯把PLC放在一个网段网关和IT设备放另一个网段中间用路由隔开减少冲突。固件版本。网关和PLC的固件版本不匹配会出现各种莫名其妙的通信问题。项目开始前把固件版本统一确认一遍该升级的升级该降级的降级。别等调试的时候才发现那时候改起来麻烦。文档和标签。现场接线、IP分配、点位对照表这些文档一定要做而且要做两份一份电子版存档一份打印出来贴在现场。我见过太多项目调试的人一走后面来的人对着柜子一脸懵。标签也要打清楚哪根线是哪个设备的别用临时线这种词临时线最后都变成了永久线。这套从PLC到云端的链路说到底就是把数据从设备里安全、完整、及时地搬到需要它的地方。每一段都有成熟的技术和产品难的是把它们组合起来并且针对具体现场做适配。我个人的体会是方案设计阶段多花一天想清楚数据流向和异常处理现场调试就能少熬三个通宵。