1. 从一台注塑机的数据孤岛说起去年帮一家做精密注塑的客户做数字化改造车间里12台注塑机品牌横跨三菱、西门子、台达、汇川最老的一台2008年出厂还在用RS232串口往外吐数据。老板拍着桌子问我我就想知道每台机器现在到底在不在跑、跑了多少模、温度有没有超标怎么就这么难这个场景几乎是我做工业数据采集这些年遇到最多的需求原型。PLC数据实时采集这件事听起来是个技术活实际上它是一条完整的链路工程从设备侧的物理接口到协议层的对话规则再到边缘侧的数据清洗最后到平台侧的存储与呈现。任何一环掉链子你在办公室大屏上看到的就是一堆假数据或者干脆没数据。这篇内容我打算把这条链路从头到尾拆一遍。不管你是刚入行的自动化工程师还是被老板赶鸭子上架要做设备联网的IT人员或者正在选毕业设计题目的学生看完之后应该能自己搭出一套能跑通的采集系统。我会重点讲清楚三件事设备怎么接进来、数据怎么传出去、平台怎么落下来。中间那些年我踩过的坑、调试到凌晨三点的排查思路也会一并写进去。提示全文涉及的协议、工具、配置方法均为通用工业实践具体项目请以设备手册和现场实际情况为准。2. 设备接入层先搞清楚你的PLC在说什么话2.1 物理接口决定了你第一步该插哪根线很多人一上来就问用什么协议其实应该先看物理层。PLC能对外通信的物理接口无非这么几种RS232、RS485、以太网口RJ45、USB主要用于编程、以及部分高端机型的光纤接口。接口类型直接决定了你能用什么样的采集硬件。RS232是全双工点对点通信传输距离理论上15米实际超过10米就开始不稳定。我遇到过一台老式三菱FX系列编程口是RS422和RS232类似但差分信号客户非要拉一根20米的线到中控室结果数据丢包率超过30%。后来换成RS485转以太网的串口服务器放在设备旁边问题立刻解决。RS485是半双工总线可以挂多台设备传输距离1200米。这是车间里最常见的现场总线物理层。但要注意RS485是总线不是星型必须手拉手串联不能从中间分叉。我见过一个项目施工队图省事从主线中间引了三根分支线出来接三台设备结果通信时好时坏查了两天才发现是拓扑结构错了。以太网口现在越来越普遍西门子S7-1200/1500、汇川AM系列、倍福TwinCAT3都标配。以太网的好处是带宽大、距离远加交换机就行、可以同时跑多个协议。但要注意IP地址规划车间里设备多了之后IP冲突是家常便饭。物理接口典型PLC型号最大距离拓扑结构采集硬件RS232三菱FX2N、西门子S7-20015m点对点串口服务器/工控机串口RS485台达DVP、信捷XC1200m总线手拉手串口服务器/485转以太网以太网西门子S7-1200、汇川AM100m可加交换机星型直接接入/工业交换机USB各品牌编程口5m点对点仅用于编程不适合长期采集2.2 协议选型Modbus、OPC UA还是厂商私有协议物理层通了之后就要解决说什么话的问题。PLC领域最常见的三种协议是Modbus、OPC UA和厂商私有协议。Modbus RTU/TCP是工业界的普通话。它简单、开放、几乎所有PLC都支持。Modbus RTU跑在串口上Modbus TCP跑在以太网上。它的数据模型很朴素线圈Coil、离散输入Discrete Input、保持寄存器Holding Register、输入寄存器Input Register。每个寄存器16位读一个32位浮点数需要拼两个寄存器。我刚开始做采集的时候觉得Modbus太简单了后来才发现简单有简单的好处。有一次客户临时要加一台第三方温控仪表我查了手册找到它的Modbus地址表十分钟就接进来了。如果换成私有协议光找协议文档就得半天。但Modbus也有硬伤。它没有数据类型定义你读上来的两个寄存器到底是浮点数、整数还是两个独立的开关量全靠你自己知道。而且它没有时间戳采集上来的数据什么时候产生的取决于你的采集程序什么时候读的。对于实时性要求高的场景这是个隐患。OPC UA是新一代的工业通信标准。它自带数据类型、时间戳、质量码支持复杂结构体还有完善的安全机制。西门子S7-1200/1500、倍福TwinCAT3、汇川AM系列都原生支持OPC UA。用OPC UA采集的好处是你不用再猜数据类型服务器会告诉你这个变量是Float还是Int16。但OPC UA的配置比Modbus复杂得多。证书交换、安全策略、端点配置每一步都可能卡住。我见过一个项目工程师在TwinCAT3里配好了OPC UA服务器客户端死活连不上最后发现是防火墙把4840端口挡了。所以用OPC UA之前先把网络策略理清楚。厂商私有协议是最后的选择。三菱的MC协议、西门子的S7协议、欧姆龙的FINS协议这些协议效率高、功能全但绑定品牌。如果你的车间全是西门子用S7协议直接读DB块是最方便的。但如果混着三菱和西门子就得写两套采集程序。注意选择协议时不要只看技术先进性要看现场设备支持什么、你的团队熟悉什么。我见过太多项目为了用OPC UA而用OPC UA结果调试时间比用Modbus多了三倍。2.3 采集硬件串口服务器、边缘网关还是工控机物理接口和协议确定之后你需要一个硬件来翻译和转发数据。常见的选择有三种串口服务器、边缘网关、工控机。串口服务器是最轻量的方案。它把RS232/RS485信号转成以太网信号你的采集程序通过网络就能读到串口数据。价格便宜通常几百块配置也简单。但功能单一只能做透传不能做数据清洗和协议转换。边缘网关是现在的主流选择。它通常有多个串口和网口支持Modbus、OPC UA、MQTT等多种协议可以在本地做数据预处理、断线缓存、边缘计算。华为、研华、映翰通都有这类产品。价格从一两千到上万不等。我一般推荐客户用边缘网关因为它把很多脏活累活都干了你的平台侧只需要接收标准化的数据。工控机是最灵活的方案。你可以在上面跑任何采集软件Python、C#、Node.js都行。但工控机需要维护操作系统会崩、硬盘会坏、风扇会积灰。如果现场环境恶劣工控机的故障率会明显高于边缘网关。方案成本灵活性维护难度适用场景串口服务器低低低少量设备、简单透传边缘网关中中低多设备、需要协议转换和边缘处理工控机高高高复杂逻辑、需要本地存储和计算我个人的经验是设备数量少于5台、协议单一用串口服务器就够了设备数量多、协议混杂、需要断线续传上边缘网关如果需要在本地跑AI推理或者复杂业务逻辑再考虑工控机。3. 数据传输层从车间到机房的那段路3.1 采集频率不是越高越好很多人第一次做采集恨不得每10毫秒读一次数据。结果发现网络堵了、PLC响应变慢了、数据库写爆了。采集频率的设定要基于实际需求。对于设备运行状态运行/停止/故障1秒一次足够了。对于温度、压力这类模拟量如果只是做监控展示1秒到5秒一次都行。对于需要做PID调节或者高速计数的场景才需要100毫秒甚至更快的频率。我做过一个冷库监控项目客户要求温度数据每5秒采集一次。我一开始设了1秒结果发现冷库温度变化很慢1秒和5秒的数据曲线几乎没区别但数据库写入量大了5倍。后来改成5秒系统负载立刻降下来了。还有一个坑是突发采集。有些工程师为了捕捉设备故障瞬间的数据把采集频率设得很高但平时又不需要。这时候可以用变化触发的方式平时低频采集当某个变量超过阈值时自动提高频率。边缘网关通常支持这种逻辑。3.2 断线缓存车间网络比你想象的脆弱车间里的网络环境远比办公室恶劣。电磁干扰、设备启停、施工挖断网线任何一件事都能让你的数据链路中断。如果没有断线缓存这段时间的数据就永久丢失了。断线缓存的原理很简单采集程序在本地维护一个队列数据先写入队列再发送到平台。如果发送失败数据留在队列里等网络恢复后继续发送。队列的大小决定了你能缓存多长时间的数据。我一般建议客户至少缓存4小时的数据。按每台设备每秒1条数据、每条数据200字节计算4小时就是2.88MB。对于边缘网关来说这点存储空间完全不是问题。但断线缓存有个陷阱时间戳。如果采集程序在本地给数据打时间戳网络恢复后上传的数据时间戳是准确的。但如果时间戳是平台侧收到数据时才打的那缓存期间的数据时间戳就全错了。所以一定要在采集侧打时间戳。提示断线缓存的数据在上传时要注意顺序先缓存的数据要先上传。有些MQTT客户端默认是后进先出会导致数据乱序。3.3 MQTT还是HTTP传输协议的选择逻辑数据从边缘到平台常用的传输协议有MQTT、HTTP、WebSocket以及工业场景特有的OPC UA over TCP。MQTT是物联网场景最常用的协议。它是发布/订阅模型轻量、省流量、支持断线重连和QoS服务质量等级。QoS 0是最多一次可能丢数据QoS 1是至少一次可能重复QoS 2是恰好一次开销最大。对于设备状态数据QoS 1通常就够了平台侧做去重即可。HTTP是请求/响应模型实现简单但实时性差。你需要定时轮询而且每次请求都要建立连接除非用长连接。对于低频采集的场景HTTP够用对于高频实时采集MQTT更合适。WebSocket适合需要双向通信的场景比如平台下发指令给设备。但WebSocket的连接保持需要心跳机制网络不稳定时容易断。我一般推荐MQTT因为它在工业物联网场景下最成熟。但要注意MQTT Broker的部署位置。如果Broker在云端车间网络中断时数据就传不出去如果Broker在本地又增加了运维成本。折中方案是用边缘网关自带的MQTT Broker平台侧通过桥接的方式订阅。协议实时性开销断线重连适用场景MQTT高低支持高频采集、多设备HTTP低中需自己实现低频采集、简单集成WebSocket高中需心跳双向通信、指令下发OPC UA高高支持工业设备直连、复杂数据类型3.4 数据格式JSON、Protobuf还是自定义二进制数据传什么格式直接影响传输效率和平台侧的解析难度。JSON是最通用的格式可读性好几乎所有语言都支持解析。但它的体积大一个简单的温度值可能要几十个字节。对于高频采集JSON的带宽开销不可忽视。Protobuf是Google的二进制序列化格式体积小、解析快但需要预先定义schema。如果数据结构经常变维护schema是个麻烦事。自定义二进制格式效率最高但可读性差调试困难。我一般只在极端带宽受限的场景下才用。我的建议是如果采集频率低于1Hz用JSON就够了如果高于1Hz考虑Protobuf如果带宽极其受限比如用4G流量卡再考虑自定义二进制。4. 平台落地层数据存下来之后怎么用4.1 时序数据库选型InfluxDB、TDengine还是TimescaleDBPLC采集上来的数据是典型的时序数据带时间戳、写多读少、按时间范围查询。用MySQL存时序数据不是不行但性能会随着数据量增长急剧下降。InfluxDB是最知名的时序数据库生态好、文档全、支持类SQL查询语言。但它的集群版是商业版开源版只支持单机。对于中小规模项目单机InfluxDB完全够用。TDengine是国产时序数据库性能强悍支持集群对工业场景做了很多优化。它的超级表概念很适合设备数据建模。我最近几个项目都在用TDengine写入速度确实比InfluxDB快不少。TimescaleDB是基于PostgreSQL的时序数据库扩展最大的好处是你可以用SQL查询时序数据学习成本低。如果你的团队已经熟悉PostgreSQLTimescaleDB是个平滑的选择。数据库写入性能查询语言集群支持学习成本InfluxDB高Flux/InfluxQL商业版中TDengine极高SQL开源支持低TimescaleDB高SQL开源支持低选型时不要只看性能指标要考虑团队的技术栈。如果团队都是Java背景TDengine的JDBC驱动很成熟如果团队熟悉PostgreSQLTimescaleDB更顺手。4.2 数据建模设备、测点、数据三级结构时序数据建模的核心是回答谁、什么时候、什么值这三个问题。我一般用三级结构设备Device、测点Metric、数据点Data Point。设备是物理设备的抽象比如1号注塑机。测点是设备上的某个可测量属性比如料筒温度、注射压力、运行状态。数据点是某个测点在某个时刻的值。在TDengine里可以用超级表来建模CREATE STABLE device_metrics ( ts TIMESTAMP, value DOUBLE, quality TINYINT ) TAGS ( device_id BINARY(32), metric_name BINARY(64), unit BINARY(16) );这样每台设备的每个测点都是一张子表查询时可以用超级表做聚合也可以查单台设备的历史数据。注意测点命名要有规范。我见过一个项目测点名有中文、有英文、有拼音还有temp1、temp2这种无意义命名。后来做报表时光整理测点名就花了一周。4.3 实时告警阈值判断、变化率判断和组合条件数据存下来之后最有价值的应用就是告警。PLC采集场景下的告警通常有三类阈值告警、变化率告警、组合条件告警。阈值告警最简单温度超过80度就报警。但要注意死区设置否则温度在阈值附近波动时会疯狂报警。我一般设置2%的死区比如阈值80度死区1.6度温度降到78.4度以下才解除告警。变化率告警是看数据的变化速度。比如温度在1分钟内上升超过10度即使没到阈值也报警。这种告警能提前发现异常趋势。组合条件告警是多个条件的逻辑组合。比如设备运行中 AND 温度超过阈值 AND 持续30秒才触发告警。这能有效减少误报。告警的触发和恢复要成对处理。我见过一个系统告警触发后没有恢复机制结果告警列表越积越多操作工干脆不看了。告警恢复的条件通常比触发条件宽松一些比如触发是80度恢复是75度。4.4 可视化从大屏到手机端的数据呈现数据最终要给人看。车间大屏、办公室看板、手机App不同场景对可视化的要求不同。车间大屏通常用组态软件或者Web大屏展示设备状态、产量、告警。关键是字体要大、颜色要醒目、刷新要快。我一般用ECharts或者DataV做Web大屏配合WebSocket实现实时刷新。办公室看板更关注趋势和对比比如日产量趋势、设备OEE对比。这类看板可以用Grafana快速搭建它支持多种数据源图表类型丰富。手机端适合看告警和关键指标。可以用微信小程序或者钉钉机器人推送告警信息。我做过一个项目把告警推送到钉钉群操作工在手机上就能看到哪台设备出了问题响应速度快了很多。5. 那些调试到凌晨的坑5.1 西门子S7-200 SMART搜索不到CPU这是西门子S7-200 SMART用户最常遇到的问题。STEP7 Micro/WIN SMART软件连接PLC后搜索不到CPU但通过添加IP地址可以连接上。原因通常是网络配置问题。S7-200 SMART的默认IP是192.168.2.1如果你的电脑不在这个网段搜索功能就找不到它。解决方法有两种一是把电脑IP改成192.168.2.x网段二是用添加CPU的方式直接输入IP地址。还有一个隐藏原因是防火墙。Windows防火墙有时候会挡住搜索用的广播包。我一般建议客户在调试时临时关闭防火墙调试完再开。5.2 汇川AM763无法识别本地IO模块汇川AM763是CODESYS平台的PLC本地IO模块通过背板总线连接。如果无法识别先检查模块是否插紧然后看CODESYS里的设备树配置是否正确。我遇到过一次模块插紧了、配置也对但就是识别不到。后来发现是固件版本不匹配。AM763的固件版本和IO模块的固件版本有兼容性要求升级PLC固件后问题解决。5.3 三菱FX3U的D0-D8断电不保持三菱FX3U的D0到D8是普通寄存器默认断电不保持。如果你需要这些寄存器的值在断电后保留需要在PLC参数里设置断电保持范围。这个坑很隐蔽因为程序逻辑没问题仿真也没问题但实际断电重启后数据就丢了。我建议在项目初期就把需要保持的寄存器规划好统一设置保持范围。5.4 Modbus读上来的浮点数是乱码Modbus寄存器是16位的读32位浮点数需要拼两个寄存器。但问题来了哪个是高位、哪个是低位这就是字节序问题。不同厂商的字节序可能不同。有的用大端ABCD有的用小端DCBA还有的用混合序CDAB、BADC。我一般先用已知值测试比如写入25.5看读上来是什么然后调整字节序。import struct def modbus_regs_to_float(regs, byte_order): # regs是两个16位寄存器 # 大端, 小端 bytes_data struct.pack(HH, regs[0], regs[1]) if byte_order : bytes_data bytes_data[::-1] return struct.unpack(f, bytes_data)[0]5.5 OPC UA连接超时但Ping得通OPC UA默认端口是4840。如果Ping得通但连不上先检查防火墙是否放行了4840端口。然后检查OPC UA服务器的安全策略有些服务器默认只允许加密连接你需要导入证书。还有一个常见原因是端点URL配置错误。OPC UA的端点URL必须和服务器证书里的域名一致否则会报证书错误。如果服务器证书里写的是主机名你用IP连接就会失败。6. 一套能跑通的最小系统长什么样说了这么多最后给一个能直接抄作业的最小系统配置。假设你有3台设备一台西门子S7-1200以太网、一台台达DVPRS485、一台三菱FX3URS422。硬件清单边缘网关一台支持Modbus RTU/TCP、OPC UA、MQTTRS485转RS422转换器一个如果网关没有RS422口工业交换机一台24V电源一个软件配置网关采集程序Modbus RTU读台达DVPModbus TCP读西门子S7-1200MC协议读三菱FX3U数据格式JSON传输协议MQTTQoS 1断线缓存4小时平台侧EMQX作为MQTT BrokerTDengine存储数据Grafana展示这套配置的成本大概在3000-5000元不含平台服务器能支撑10台以内的设备采集。如果设备数量增加只需要增加网关或者升级网关型号。我在实际项目里用这套架构跑过半年稳定性没问题。唯一要注意的是网关的散热车间温度高的时候网关会降频。后来加了个小风扇问题解决。采集频率我一般设1秒对于大多数设备监控场景够用了。如果客户要求更高频率我会先问清楚用途很多时候他们只是觉得越快越好实际并不需要。最后说一个经验做PLC数据采集现场调试的时间永远比写代码的时间长。线接错了、IP配错了、协议对不上这些事在办公室想破头也想不出来到现场一看就明白。所以我的习惯是代码写个大概就去现场边调边改比在办公室憋大招效率高得多。