车间里二十几台西门子S7-1200和三菱FX系列PLC数据还在靠人工抄表老板要上云看设备利用率设备科老师傅觉得两三百米长的Modbus线一根根拉过去根本不现实。这是去年我接手的一个真实改造项目。从PLC到云端听起来就是“采集—上传—展示”三步但实际坑全藏在协议转换、网络拓扑、断网续传、云端数据模型这些细节里。这篇文章就把我做过的这套工业PLC数据采集上云方案完整拆开从现场设备层一路讲到云端应用层适合准备自己做数据采集系统、或者正在选型物联网网关的工程师参考。1. 需求分析与整体架构1.1 传统数据采集的困局制造业工厂的设备数据采集本质上解决的是三件事设备状态透明化、生产异常及时告警、能耗和效率的量化分析。但传统方式的问题也很明显——很多老设备根本没有上位机系统PLC的程序里虽然有完整的设备状态和产量数据却只存在CPU的内存里没有任何外部接口去读。即便有部分设备接了触摸屏或者WinCC上位机也只是本地监控数据出不了车间。更麻烦的是协议这一层。西门子走S7协议三菱走MC协议或者专用串口协议AB走EtherNet/IP老设备还有Modbus RTU和Modbus TCP混合着用。每个协议的寄存器地址、字节序、数据格式都不一样逐个去翻手册写驱动工作量非常大。所以我一开始给客户做方案时就确定了“边缘网关统一采集”的思路而不是用上位机软件去挨个轮询。整体架构分四层现场设备层、边缘采集层、网络传输层、云端应用层。设备层就是各类PLC、传感器和变频器边缘采集层用工业网关去适配各种PLC协议传输层通过4G或者工厂有线网络把数据推到云端云端做设备管理、数据存储和可视化大屏。这样分层的好处是每层独立演进哪一层要加设备或者换网络都不影响其他部分。1.2 如何选择适合自己的架构模式架构模式不是只有“PLC直连云平台”这一种。结合我经手的项目常见的就三种。第一种是“PLC 4G DTU 云平台”。适合点位少、单台设备、采集频率要求不高的场景。用DTU的串口接PLC编程口或者Modbus口把数据打包走运营商网络发到云平台。优点是成本低、实施快一天就能搞定缺点是只解决了“数据能上来”没办法做边缘计算也不支持复杂的逻辑处理。第二种是“PLC 工业边缘网关 云平台”。这是我推荐的主流方案。网关同时支持多个PLC协议还能本地跑Node-RED或者Python脚本做数据清洗、温漂补偿、连续故障判断。断网的时候本地缓存网络恢复之后自动补传。适合一个车间几十台设备的场景。第三种是“PLC SCADA 云端数据库”。如果现场已经上了SCADA系统比如WinCC、组态王那就没必要在网关层重复采集直接让SCADA把数据通过API转发到云端。这种模式适合已有成熟上位机、只想补一个云端历史库的场景但要注意SCADA软件本身的上行是单向推送还是双向读写会影响后期远程控制功能的实现。我自己做项目偏爱第二种因为它的容错性最好。边缘网关相当于在设备面前加了一个“翻译缓冲”既挡住了现场复杂的网络波动也让云端架构变得简单。2. 现场设备层与PLC协议适配2.1 主流PLC通信协议速记协议适配是数据采集的第一个坎。以我最近做的西门子S7-1200为例本身支持S7协议、Modbus TCP和PROFINET。采集时最方便的是S7协议因为它能直接访问DB块数据不需要在PLC里写额外的通信程序。但S7协议分版本S7-300/400的老协议和S7-1200/1500的优化DB块访问方式不同如果用网关采S7-1200的DB块必须在DB属性里勾掉“优化的块访问”否则网关读到的基本全是0。三菱PLC这边FX系列用的是CC-Link和编程口协议Q系列支持MC协议3E帧/4E帧。MC协议最大坑是寄存器地址换算比如D100在MC协议3E帧里对应的地址是十六进制的0x0064但很多网关配置页里要填十进制100搞混了能让你抓狂一整天。Modbus协议相对简单但地址映射表也得逐一核对特别是Modbus的40001地址区和PLC内部保持寄存器不是一一对应的要查PLC手册里的映射表。OPC UA是这几年很热的方向它好在自带信息模型不用关心PLC内部寄存器到底怎么组织的直接读“温度”“转速”这些带语义的节点。但OPC UA对PLC型号有要求老设备要加OPC UA网关。如果项目涉及多品牌PLC联网我建议能走OPC UA的尽量走不能走的再降级到Modbus TCP和S7。2.2 物理链路怎么选串口、以太网还是无线物理链路的优先级很明确有以太网口的PLC优先走以太网没有的才考虑串口和无线。我用过一个四口的工业网关同时接两台PLC一台S7-1200通过LAN口直连一台老款三菱FX3U没有网口只能用RS422编程口转RS485再接网关的串口端。这里很容易踩的坑是FX3U编程口默认不是标准Modbus而是三菱编程口协议。网关的串口参数必须设置成和PLC编程口一致波特率通常是9600数据位7位偶校验这个参数如果前任工程师改过最好是接上编程线在GX Works2里确认一遍不然光靠猜能折腾一晚上。对于几十台设备分布在多个车间的情况我会在每台设备旁边放一个“小网关”或者“协议转换模块”先把PLC协议转成Modbus TCP再通过工业交换机组网汇聚到车间里的核心采集网关。这样做的好处是减少了主采集网关的串口压力也让每台设备的故障隔离变得容易。简单说就是别贪大一台网关别接超过20台设备CPU跑得动、网络中断影响面也小。另外要说一下无线方案。433MHz LoRa和4G DTU在工厂里各有各的适用场景。如果只是几个点位分散在园区不同角落用4G DTU最省事如果是同一个车间内部没有网线条件LoRa模块配合网关可以做到低延迟的无线采集。但要注意LoRa受金属机床遮挡影响明显模块天线一定要引到设备外面实测两台机床中间隔一台加工中心直线距离30米信号强度直接从-60dBm掉到-95dBm差点没把我坑死。3. 边缘网关选型与数据采集配置3.1 边缘网关到底该选什么配置很多第一次做采集项目的人会问“是不是用树莓派就行”。树莓派做开发验证确实方便但是工业现场要考虑宽温、防尘、稳定供电、看门狗树莓派加个工业外壳临时跑可以长期真不行。我选网关时主要看几个硬指标处理器平台、串口数量、是否支持4G模块、协议库覆盖面。以我常用的方案来说处理器用ARM Cortex-A53双核或者四核内存512MB以上这样跑Node-RED和Python脚本都不会卡。串口至少2-4路最好带隔离因为现场串口设备电源不干净的时候隔离能少烧几个模块。4G模块要能插标准SIM卡支持全网通。协议库方面就看你手里的PLC品牌如果主要做西门子和三菱想想整个国内做网关的厂商基本都能覆盖如果涉及倍福、贝加莱这种偏门PLC得先问清楚是否有官方驱动别听“后续再适配”这种话。每一家厂商的配置界面不太一样但核心概念差不多先创建设备填IP地址和端口再选择协议最后填采集点表。点表是重点我习惯先在Excel里维护一份点位清单包括设备名称、寄存器地址、数据类型、缩放系数、采集周期。例如温度传感器通过PLC采集数值在内部是word类型实际温度是数值乘以0.1那就把寄存器地址、数据类型、缩放系数三列填清楚回头在网关里批量导入能省半天工夫。3.2 点位采集周期与PLC扫描周期怎么协调这里最容易犯的错误是采集周期设得太快。有人觉得采集越快越好把S7-1200的DB数据每100毫秒读一次结果网关CPU长时间高负载PLC的通信负载也上去了反而影响设备工艺控制。合理的做法是区分数据类别设备开停状态、报警信号用秒级采集1-2秒足够温度、压力这种变化慢的过程量用5-10秒电机的电流、转速这种需要看趋势的用1-5秒有些需要精确计算产量的计数器其实也不需要毫秒级把计数数据采集到边缘端再本地做增量计算就好。边缘节点上的缓存策略也很有讲究。我通常会在网关本地存一份最近7天的历史数据存储介质用SD卡或者本地SQLite数据库。这样即使云平台断连现场数据也不会丢。网关内置的存储空间不需要太大因为后续可以定期清理。云端数据库才是最终所有的历史数据存放处。还有一点PLC内部有扫描周期的概念OB1循环扫描的时间越短CPU对通信请求的响应就越快。如果PLC程序里有大段的运算或者通信指令网关读寄存器时偶尔会超时。我在项目里建议客户把数据交换用的DB块独立建一个OB以固定的100ms周期去更新这样采集端读的是稳定的内存映像而不是直接读正在被程序实时改写的地址能避免不少偶发错误。4. 上行协议与云端接入4.1 为什么上云大多采用MQTT而不是HTTP工业上行的数据协议主流选择是MQTT、HTTP和Modbus TCP网关透传。我最推荐MQTT因为它是发布订阅模式天然适合大量设备上报的场景。MQTT的QoS等级设置也是关键采集上云的核心数据建议用QoS1保证消息至少送达一次状态类、日志类数据用QoS0就好省流量不阻塞。MQTT里有个容易被忽略但很实用的特性是遗嘱消息Last Will and Testament。设备断线时云平台能立刻收到遗嘱标记把设备状态改成离线。这个对做设备管理特别有用我遇到过无遗嘱配置的设备网关都断电了平台上还显示在线早上过去看大屏才发现设备离线报警根本失效了后来补配遗嘱才恢复正常。加密和鉴权也要重视不加密的MQTT消息在局域网里裸奔抓个包就能看到设备数据和账号密码。推荐至少要上TLS加密设备端证书和账号分开管理。客户如果希望后续对接自己的ERP系统还可以在云端加一层“消息桥接”把MQTT流量转发到Kafka或者RocketMQ方便下游系统消费。4.2 云端的设备模型与主题规划设备上云的第一步不是写代码而是设计Topic和物模型。Topic规划得好不好直接影响后续设备管理、告警逻辑和数据处理。我一般推荐一个设备一条主题按层级分好设备类型和设备ID例如factory/site/line/device/type/deviceId这样云端可以用通配符订阅整条产线也可以单独订阅某台设备。物模型就是定义设备有哪些属性、事件和服务。比如一台注塑机属性可能包括工作状态枚举待机/运行/报警、当前模次整数、料温浮点数事件有“脱模故障”“温度超限”服务有“远程启停”。把数据模型定清楚云端程序写起来就顺畅了。在很多项目里设备数据的量级看起来不大几百台设备每秒几百条消息但时间长了之后存储和查询的压力很大。我的做法是最近3个月的原始采样数据放时序数据库比如TDengine或InfluxDB一天的原始数据量几十GB也扛得住统计报表、设备效率这些整合数据放MySQL用于业务端展示。这样既保证了细节溯源又不让业务查询卡成蜗牛。4.3 REST API网关和微服务如何配合云端平台如果只接自己一个项目用简单的MQTT服务端加Web服务就够了。但要做成通用平台建议加一层API网关把设备接入、告警推送、用户权限这些能力拆成微服务。比如“设备接入服务”负责处理MQTT消息“告警服务”负责根据阈值规则触发告警“通知服务”负责发短信/微信/邮件“数据服务”负责时序数据的读写。我这里想强调一个从实际项目里学到的教训设备的唯一性标识必须统一。有些设备用MAC地址有些用SIM卡的ICCID有些用用户自定义的设备编号云端如果没做好映射后面做设备维度统计就会各种对不上。我建议网关在上行消息里固定带上“工厂编号-产线编号-设备编号”的三段式字符串作为设备ID云端只认这个ID。网关侧做好配置读写后续设备换卡、换网关只改网关里的设备ID配置即可云端建筑模型不用改。5. 实操记录从接线到云端大屏的完整链路5.1 现场网关接入PLC的接线与参数配置实录下面贴一段我最近做项目的过程供大家参考。场景是某汽车零部件厂现场有20多台西门子S7-200 SMART PLC没有网口版本但有RS485口和10台S7-1200有网口。网关选用四串口工业物联网网关4个网口加4个串口。第一步把S7-1200的以太网口接到网关的LAN口。网关的LAN口默认IP段通常需要和PLC在同一段网。S7-1200出厂IP是192.168.0.1网关LAN口设成192.168.0.2掩码255.255.255.0。第二步打开网关管理界面选择“西门子S7协议”填入PLC IP地址192.168.0.1端口默认102TSAP参数保持默认。第三步在点表配置里添加需要读取的DB块地址。例如读取DB1.DBD0浮点数设置数据类型为float采集周期1秒。S7-200 SMART的RS485口接网关串口端走Modbus RTU协议。但注意S7-200 SMART作Modbus从站需要先在PLC程序里调用Modbus Slave库分配好保持寄存器起始地址和个数。网关侧波特率、数据位、停止位、校验方式必须和PLC侧完全一致。我这次设置的参数是9600、8、1、无校验。S7-200 SMART的Modbus地址映射V区地址和Modbus地址不是直通的要参考手册里的映射表比如VB1000对应Modbus地址40001。配置完成后先在网关的“调试工具”里手动读一次点表看返回数值是否正常。我习惯把温度、压力、产量几个关键点位单独放到自定义变量里便于后续做告警和联动。这一步排错效率远高于等数据推到云端再回头排查。5.2 PLC程序侧需要配合做哪些工作很多网关都能“免编程采集”但完全不碰PLC程序的项目其实很少。至少两类情况需要改PLC程序一是需要PLC把数据整理到固定地址。比如某台老设备PLC里温度换算逻辑很复杂包含了热电偶冷端补偿和线阻修正我不想在网关里复现整套算法就让PLC在指定DB块里先算好数值网关只读结果。二是需要PLC帮忙做简单的本地连锁比如云端脚本判断出设备异常后网关输出DO信号PLC用这个信号去切停设备。这些控制指令的交互也建议通过PLC里的特定M区或者DB块保持避免通信竞争。我在三菱FX3U的项目里直接在PLC程序里通过MOV指令将D100-D120作为上传缓冲区每分钟用定时器刷新一次。这样网关轮询的永远是PLC内存里的稳定区域不受扫描周期波动影响。这个做法写进很多项目的SOP里之后几乎没有再遇到数据跳变的问题。5.3 云端部署与数据展示的完整步骤云端的部署推荐用Docker Compose形式把所有服务写进一个编排文件里一台2核4G的轻量云服务器就能跑起来。基础组件包括EMQXMQTT服务器、TDengine时序数据库、Node-RED轻量流处理、Grafana看板展示。首先启动EMQX创建设备认证插件。然后把网关侧的上行地址指向云服务器的1883端口测试正式环境用8883走TLS。接着在Node-RED里用MQTT输入节点订阅设备主题把JSON payload解析后写入TDengine的超级表。这套链路如果都是现成组件的话一天能搭完。真正耗时的是物模型设计和看板定制。我一般先让客户提供一个Excel的点位表包括哪些点位需要展示哪些点位需要历史曲线哪些需要参与告警。这些梳理清楚之后再根据点位表在Grafana里配置面板。展示层不要太花哨实用就好我常用几个图表设备状态总览饼图/仪表盘、关键参数实时曲线时间序列图、当日产量统计柱状图、报警TOP10排行表。6. 常见问题与排查技巧实录6.1 网关读不到PLC数据的排查套路我遇到过很多次“云端页面上一片空白网关日志不断报错”的情况。排查顺序基本是先看网关能否ping通PLC再到网关调试工具里手动读单个点位然后看PLC侧的程序是否处于RUN状态最后查串口参数。有一次设备老师傅说“昨天还能读今天全没了”我远程一看PLC程序被改过DB块偏移了地址原来读到的DB1.DBD4变成DB1.DBD8数据全错位。这也是为什么我强烈建议网关的点表配置要通过版本管理每次改动记录要留档。6.2 离线模拟调试时的PLC仿真器问题很多人喜欢在开发阶段用S7-PLCSIM Advanced模拟PLC来测试采集链路省得蹲在车间里调设备。但这个模拟器有几个隐藏问题S7-PLCSIM Advanced V5.0创建的PLC实例启动不了、没有报错信息是常见问题之一。通常是因为本地网卡的虚拟网卡选项没开或者防火墙阻止了PLCSIM的通信。解决办法是先以管理员身份启动PLCSIM然后在网络适配器里确认“Siemens PLCSIM Virtual Ethernet Adapter”已启用最后换用本机地址127.0.0.1去通信实测不少问题就这么解决了。6.3 数据丢包与实时性优化网关采集周期很快、数据量大的时候经常出现云端曲线“断断续续”的情况。首先看上行带宽一台4G DTU如果同时推送几十个点位500ms一次上行带宽是不够的。我的建议是边缘端做聚合网关先把30秒的数据打包成一条JSON消息再一次性推送到云端这样带宽占用能降低90%。云端解析也简单拆开后按时间戳写入时序数据库。还有一次排查到数据曲线周期性地跳变发现是网关NTP同步时间不准导致本地时间戳和云端时间戳差了十几分钟。后来在网关和云端都配置了NTP服务器并规定所有消息时间戳统一以网关时间为准问题就不复现了。这里提醒一下一定要在采集链路建立初期就统一时间基准否则后期做数据分析时跨设备对齐会非常痛苦。6.4 从“能用”到“好用”的三点经验最后分享三点我个人的经验。第一现场层面的断网续传是底线功能采购网关时一定要实测拔掉网线10分钟网关本地缓存了多少条消息恢复网络之后能不能完整补上。有次供应商说支持断网续传实际缓存只有128条按2秒一条计算断网四分钟就开始丢数据了。这种测试要在项目验收前做别等到上线以后再发现。第二云端的数据模型要预留扩展字段。设备会换点位会加工况名称会变如果数据表设计得很死每次小改动都要动库表结构。我在TDengine的表结构里都会留一列JSON类型的ext字段把暂时用不到的附加属性放进去这样灵活很多。第三从设备层的PLC到云端平台的完整链路严格来说永远没有100%完美的方案。我在每个项目里都会和客户提前对齐几个问题数据采集的口径瞬时值还是平均值、历史数据保留周期一年还是永久、远程控制要不要做。这些看似琐碎的决策其实决定了架构的每一步设计和每一分钱花在哪里。这套架构做下来核心不是技术而是把“设备-网络-平台”当作一个整体来考虑。PLC侧把数据整理好网关侧把协议差异消化掉云端把设备模型和存储设计好一条稳定可靠的数据链路自然就能跑起来。以后有项目需要从零搭建PLC数据采集上云照这个思路走一遍至少能在选型阶段少走不少弯路。