1. 工业现场数据采集的整体设计思路1.1 为什么这件事值得认真做在工厂里待过的人都有一个共同感受设备在跑但数据在睡。一台数控机床每天产生几千条运行参数一台变频器每秒钟都在输出电流、电压、频率但这些数据绝大多数时候只是闪一下屏幕就消失了没有人把它们攒起来。等到设备突然停机、产品批量报废、客户投诉交期延误的时候大家才开始翻记录、查原因结果发现什么也没留下。PLC数据实时采集要解决的就是这个问题。它的核心目标很朴素把PLC里那些反映设备和产线运行状态的寄存器值持续、稳定、准确地搬到上层平台里让这些数据能被存储、被分析、被展示、被用来做判断。听起来简单但真正落地的时候涉及设备接入、协议适配、数据传输、平台对接、异常处理等一连串环节每个环节都有坑。这套方案适合谁看如果你是自动化工程师想从写梯形图扩展到做数据层的事情如果你是IT或数字化部门的开发被派去工厂对接设备但不太懂PLC如果你是项目负责人需要评估数据采集方案的可行性和工作量那这篇内容应该能帮你把整条链路理清楚。1.2 三种主流技术路线的取舍做PLC数据采集绕不开协议选型。目前工业现场最常见的是三条路Modbus、OPC UA、以及各家PLC的私有协议或专用驱动。Modbus是最老牌、最通用的。它简单、轻量、几乎所有的PLC和仪表都支持。Modbus RTU走串口Modbus TCP走网口。优点是实现成本低随便一个网关或者几行代码就能读缺点是数据类型表达弱只有寄存器概念没有语义信息而且没有内置的安全机制。对于只需要读几十个寄存器值的场景Modbus完全够用。OPC UA是这几年明显在上升的路线。它最大的优势是自带信息模型每个变量有名字、有类型、有语义不是冷冰冰的地址。而且它跨平台、有加密和认证机制适合和上层MES、SCADA、云平台对接。西门子S7-1200/1500、倍福TwinCAT、汇川部分型号都原生支持OPC UA。缺点是配置相对复杂对网络质量有一定要求老设备基本不支持。第三条路是用PLC厂商自己的协议或驱动比如西门子的S7协议、三菱的MC协议、欧姆龙的FINS、汇川的Modbus扩展等。这类方式往往能拿到最全的数据读取效率也高但绑定特定品牌换一个PLC就得换一套代码。我个人的建议是新项目优先考虑OPC UA老设备改造用Modbus混合品牌场景用网关做协议转换。不要一上来就追求“统一协议”先把数据拿到手比什么都重要。1.3 数据从PLC到平台的完整链路整条链路可以拆成四段现场设备层、采集层、传输层、平台层。现场设备层就是PLC、传感器、变频器、数控机床这些。采集层是真正去“读”数据的部分可能是一台工控机、一个边缘网关、或者PLC自带的通信模块。传输层负责把采集到的数据送到目的地可以走厂内局域网、也可以走无线。平台层是最终落地的位置可能是本地服务器上的数据库也可能是云端的物联网平台。每一层的选择都会影响后面的实现方式。比如采集层如果用工控机那你可以跑Python、Node.js、或者组态软件如果用边缘网关那通常只能用网关厂商提供的配置工具。传输层如果走厂内网络延迟低但范围有限如果走无线部署灵活但稳定性要额外考虑。平台层如果只是本地存库那用MySQL、PostgreSQL、时序数据库都行如果要上云那还得考虑消息队列和API对接。提示不要跳过需求确认直接选型。先搞清楚要采多少点位、采集频率多高、数据要存多久、有没有实时告警需求这些答案会直接决定后面的技术选型。2. 设备接入与协议适配的核心细节2.1 先搞清楚你要读什么很多人一上来就问“怎么读PLC”但更重要的问题是“读什么”。PLC里的数据大致分几类状态量设备运行、停止、故障、模拟量温度、压力、电流、计数量产量、运行时长、参数设定值配方、阈值。不同类型的数据采集频率和精度要求完全不同。状态量通常变化不频繁1秒读一次甚至5秒读一次都够用。模拟量如果是做实时监控可能需要100毫秒到1秒的采集周期。计数量一般累积值读慢一点没关系但要注意断电保持的问题。参数设定值往往只在变更时需要记录不需要高频轮询。我见过不少项目一开始没区分数据类型统一按100毫秒轮询所有点位结果通信负载很高PLC的通信资源被占满反而影响了正常控制逻辑。所以第一步一定是整理点位表标注每个点的地址、类型、采集频率、是否告警。2.2 Modbus读取的实操要点Modbus是最常见的入门方式。以Modbus TCP为例PLC通常作为服务器采集端作为客户端发起请求。你需要知道几个关键参数IP地址、端口默认502、从站地址单元标识符、寄存器地址和功能码。功能码主要有几个01读线圈、02读离散输入、03读保持寄存器、04读输入寄存器。实际项目里用得最多的是03和04。寄存器地址在不同PLC里的表示方式不一样有的从0开始有的从1开始有的用40001这种格式。这个一定要查对应PLC的通信手册不能凭感觉。读取的时候要注意一次请求的寄存器数量限制。Modbus协议本身允许一次读125个寄存器但很多PLC实际支持的数量更少常见的是一次读几十个。如果点位很多要分批读取并且控制好请求间隔避免把PLC的通信口打满。from pymodbus.client import ModbusTcpClient import time client ModbusTcpClient(192.168.1.10, port502) client.connect() while True: # 读取保持寄存器从地址0开始读10个 result client.read_holding_registers(address0, count10, slave1) if not result.isError(): print(result.registers) else: print(读取失败) time.sleep(1)这段代码是最基础的轮询方式。实际项目里还要加异常重试、连接保活、数据解析等逻辑。比如读上来的寄存器是16位整数但实际值可能是32位浮点数需要把两个寄存器拼起来再转换。2.3 OPC UA接入的关键配置OPC UA的接入流程和Modbus差别很大。它不是直接读地址而是先浏览服务器的地址空间找到对应的节点然后订阅或读取。节点有NodeId通常是一串类似ns3;sDB1.Temperature的字符串。用Python的opcua库或者open62541都可以做客户端。关键步骤是连接服务器、浏览节点、创建订阅、设置采样间隔、处理数据变更通知。订阅模式比轮询模式效率高很多因为服务器只在数据变化时推送不需要客户端反复请求。from opcua import Client client Client(opc.tcp://192.168.1.20:4840) client.connect() # 获取节点 node client.get_node(ns3;sDB1.Temperature) value node.get_value() print(value) client.disconnect()OPC UA的配置里安全策略和用户认证是两个容易出问题的地方。很多PLC默认允许匿名连接但生产环境应该配置用户名密码和加密证书。如果连接不上先检查安全策略是否匹配再看端口是否开放。2.4 多品牌混合场景的处理工厂里往往不止一种PLC。西门子、三菱、欧姆龙、汇川、台达混着用是常态。这种情况下有两种思路一种是用支持多协议的采集软件或网关统一配置另一种是每种PLC写一个采集模块最后汇总。前者的代表是各种工业网关和组态软件配置化操作上手快但灵活性受限于厂商支持的范围。后者开发量大但可控性强适合点位多、逻辑复杂的场景。我自己的经验是如果品牌不超过三种、点位不超过500个用网关方案性价比最高。如果品牌多、点位上千、还有特殊的数据处理需求那就老老实实自己写采集服务用不同的库分别对接。3. 数据传输与平台落地的实现过程3.1 传输方式的选择数据从采集端到平台走什么通道取决于现场条件和平台位置。如果平台在厂内机房走有线局域网是最稳的。延迟低、带宽大、不受信号干扰。如果设备分散在车间各处拉网线成本高可以考虑工业WiFi或者4G/5G模块。无线方案部署快但要考虑信号覆盖和丢包问题关键数据最好有本地缓存和断点续传。传输协议方面MQTT是目前物联网场景用得最多的。它轻量、支持发布订阅、有QoS等级保证。采集端作为发布者把数据发到Broker平台作为订阅者接收。HTTP适合低频、批量上报的场景实时性不如MQTT。数据库直连适合平台和采集端在同一网络的情况但耦合度高不推荐跨网络使用。3.2 数据格式的设计传输的数据格式直接影响平台端的解析效率。常见的有JSON、CSV、自定义二进制。JSON可读性好、扩展方便是首选。但JSON的体积比二进制大如果点位多、频率高要考虑压缩或者改用更紧凑的格式。一个典型的数据包结构大概是这样{ deviceId: CNC-001, timestamp: 1718000000000, tags: [ {name: spindle_speed, value: 3200, quality: good}, {name: temperature, value: 45.6, quality: good}, {name: run_status, value: 1, quality: good} ] }deviceId标识设备timestamp是采集时间tags里是具体的点位。quality字段很重要用来标记数据是否有效。如果通信失败或者数值超范围quality设为bad平台端就不会把脏数据当成真实值处理。3.3 平台端的数据落地数据到了平台接下来是存储和处理。如果只是做展示和简单查询关系型数据库够用。但工业数据是典型的时间序列数据写入频率高、查询按时间范围用专门的时序数据库如InfluxDB、TDengine性能会好很多。存储策略上要考虑数据保留周期。原始数据不可能无限期保存通常原始数据保留几个月聚合后的数据如分钟均值、小时均值保留更久。这样既满足分析需求又控制存储成本。平台端还需要做几件事数据校验过滤异常值、单位换算把PLC里的整数转成实际工程值、告警判断超过阈值触发通知。这些逻辑可以放在采集端做也可以放在平台端做。我的建议是简单的阈值判断放在采集端复杂的分析放在平台端。3.4 一个完整的采集服务示例把前面的内容串起来一个最小可用的采集服务大概包含这些模块配置加载、PLC连接管理、数据采集、数据缓存、数据上报、日志记录。import json import time import paho.mqtt.client as mqtt from pymodbus.client import ModbusTcpClient # 配置 PLC_IP 192.168.1.10 MQTT_BROKER 192.168.1.100 DEVICE_ID CNC-001 # 初始化 plc ModbusTcpClient(PLC_IP, port502) plc.connect() mqtt_client mqtt.Client() mqtt_client.connect(MQTT_BROKER, 1883) while True: try: result plc.read_holding_registers(address0, count10, slave1) if not result.isError(): payload { deviceId: DEVICE_ID, timestamp: int(time.time() * 1000), tags: [ {name: spindle_speed, value: result.registers[0], quality: good}, {name: temperature, value: result.registers[1] / 10.0, quality: good} ] } mqtt_client.publish(ffactory/{DEVICE_ID}/data, json.dumps(payload)) except Exception as e: print(f采集异常: {e}) time.sleep(1)这个例子很简陋但把核心流程跑通了。实际项目里还要加断线重连、本地缓存、多设备管理、配置热加载、运行日志等。4. 常见问题与排查技巧实录4.1 通信连不上的排查顺序PLC采集最常见的问题就是连不上。排查要按顺序来不要跳步。先确认物理层网线插好了吗指示灯亮吗IP地址能ping通吗如果ping不通检查IP是否在同一网段、防火墙是否拦截。再确认协议层端口对吗Modbus默认502OPC UA默认4840但很多项目会改。从站地址对吗有的PLC默认是1有的不是。寄存器地址对吗不同PLC的地址偏移规则不一样。最后确认权限层有些PLC需要开启通信权限有些需要配置连接数限制。如果之前能连后来连不上检查是不是连接数满了或者PLC被重置过。4.2 数据读上来不对怎么办数据读到了但值不对通常有几个原因。一是数据类型解析错误比如把有符号数当成无符号数读或者高低字节顺序反了。二是地址偏移错了读到了相邻的寄存器。三是缩放系数没加PLC里存的是整数实际值需要除以10或者100。排查方法很简单找一个已知值去对照。比如让PLC输出一个固定值看读上来是多少反推解析逻辑。字节顺序问题在跨品牌通信时特别常见西门子和三菱的字节序就不一样。4.3 采集频率与PLC负载的平衡采集频率不是越高越好。PLC的通信资源有限如果采集请求太频繁可能影响控制程序的扫描周期。我见过一个项目采集端每50毫秒读一次结果PLC的通信负载到了80%以上控制逻辑开始出现抖动。合理的做法是关键模拟量1秒一次状态量5秒一次计数量10秒一次。如果确实需要更高频率考虑用PLC主动推送OPC UA订阅而不是客户端轮询。4.4 网络中断后的数据补传网络不可能永远稳定。采集端要有本地缓存能力网络断了先把数据存本地恢复了再补传。缓存可以用SQLite或者本地文件注意控制缓存大小避免把磁盘写满。补传的时候要带上原始时间戳不能补传时用当前时间否则平台端的时间序列就乱了。另外补传要有速率控制不要一恢复就疯狂发送把平台打挂。4.5 常见问题速查表问题现象可能原因排查方法连接超时IP/端口错误、防火墙拦截ping测试、telnet端口读取返回异常码地址越界、功能码不支持查PLC通信手册、减少读取数量数据值明显不对数据类型解析错误、字节序问题用已知值对照、检查解析代码采集一段时间后断开连接数满、PLC通信资源耗尽检查连接管理、降低采集频率数据有跳变通信干扰、寄存器被复用检查布线、确认地址唯一性平台收不到数据MQTT主题不匹配、Broker配置错误用MQTT客户端工具订阅测试注意排查问题时一定要有日志。采集端记录每次请求和响应平台端记录每条数据的接收时间。没有日志的排查就是盲人摸象。5. 从能用到好用几个实战经验5.1 配置化比硬编码重要第一个项目往往怎么写快怎么来地址写死在代码里。但设备一多、点位一改代码就要重编译重部署非常痛苦。从第二个项目开始我就坚持把设备信息、点位地址、采集频率全部放到配置文件里代码只负责读配置和执行。这样新增设备只需要改配置不用动代码。配置文件可以用YAML或者JSON结构清晰也方便版本管理。每个设备一个配置块包含连接信息、点位列表、上报主题。5.2 异常处理要区分对待不是所有异常都需要重连。读取超时可以重试连接断开需要重连数据解析错误应该记录并跳过。如果把所有异常都当成致命错误处理采集服务会频繁重启反而更不稳定。我的做法是分三级可恢复异常超时、单次读取失败记录日志后继续连接级异常断开、拒绝连接触发重连配置级异常地址错误、协议不支持告警并停止该设备的采集。5.3 时间同步不能忽视采集端和平台端的时间如果不一致数据分析时会对不上。采集端最好定期和NTP服务器同步时间数据包里的时间戳用采集端的本地时间不要用平台接收时间。因为网络延迟会导致接收时间晚于实际采集时间对于高频数据这个偏差不能忽略。5.4 先跑通再优化我见过太多项目卡在选型阶段纠结用哪个协议、哪个数据库、哪个云平台结果几个月过去了还没开始采集。正确的做法是先用一个最简单的方式把数据从PLC读到一台电脑上哪怕是用串口助手手动读先确认链路是通的。然后再逐步替换成正式方案优化性能和稳定性。数据采集这件事能跑起来比跑得漂亮重要得多。先把数据拿到手后面有的是机会优化。