工厂设备联网改造中数据采集方案的设计思路与实践
在工厂设备联网改造项目中，数据采集方案的设计直接决定了后续MES、SCADA等上层系统的数据可用性。很多项目在初期追求"能通就行"，结果上线三个月后被迫返工——协议不匹配、采样频率不足、点位命名混乱等问题集中爆发。一套可落地的数据采集方案，需要在现场层、边缘层和平台层之间找到平衡点。
一、先摸清现场设备的"家底"
改造前最容易被跳过的一步，恰恰是最关键的：盘点现有设备的通信能力。工厂里的设备大致分三类——
- 原生支持以太网通信：如较新的PLC、CNC、机器人控制器，通常自带Profinet、EtherNet/IP或Modbus TCP接口，接入相对简单。
- 仅支持串口通信：大量老旧设备通过RS-232/485输出Modbus RTU或私有协议，需要协议网关做转换。
- 无通信接口：只能通过I/O信号、仪表读数甚至人工录入获取数据，这类设备往往是最难啃的骨头。
盘点的颗粒度要细到每台设备的型号、固件版本、可用端口类型和协议栈。同样标称"支持Modbus"的设备，不同厂家对寄存器地址的定义可能完全不同，这些细节在方案设计阶段不确认，调试阶段就要成倍地还回来。
二、采集架构的分层设计
现场层：PLC控制柜内的数据汇聚
对于以PLC为核心的产线，PLC控制柜天然是数据汇聚节点。一种常见做法是在控制柜内加装边缘网关，通过柜内交换机与PLC的编程口或通信模块对接，直接读取DB块或寄存器数据。这样做的优势是布线短、干扰小，且不占用PLC的对外通信口。
需要注意的是，读取频率要与PLC扫描周期匹配。如果扫描周期是10ms，而网关以100ms轮询，虽然不会丢数据，但会遗漏两次扫描之间的瞬态变化。对于需要捕捉峰值或报警信号的场景，建议通过PLC程序主动推送而非网关被动轮询。
边缘层：协议转换与数据预处理
边缘层承担协议归一化和数据清洗的职责。典型配置包括协议转换网关、边缘计算盒子或工控机。这一层要解决的问题包括：
- 将Modbus RTU、CANopen、私有串口协议统一转换为MQTT或OPC UA。
- 对模拟量做工程单位换算和滤波处理，避免把原始AD值直接抛给上层。
- 设置断线缓存机制，网络恢复后补传数据，防止因网络抖动造成数据空洞。
三、点位规划与命名规范
数据采集方案中有一个容易被低估的工作量：点位表设计。一个中等规模的车间，采集点位动辄上千。如果命名没有规则，后期在SCADA画面上找某个温度值就像大海捞针。
建议采用层级化命名：车间-产线-设备-部件-参数。例如"焊接车间-A线-机器人1-焊枪-电流设定值"。同时为每个点位记录数据类型、量程、单位、采集频率和报警阈值。这份点位表就是后续所有系统对接的唯一数据字典。
四、一个实际改造案例
天津某汽车零部件工厂的机加工车间，有12台不同年代的加工中心。其中4台新设备支持OPC UA，5台老设备仅有RS-232口，3台完全无通信能力。方案的思路是：新设备通过OPC UA直连边缘网关；老设备用串口服务器转Modbus TCP后接入；无通信能力的3台设备通过加装电流互感器和振动传感器间接判断运行状态。整个系统上线后，设备综合效率（OEE）的计算从人工统计变为自动生成，数据延迟控制在2秒以内。
工厂设备联网改造中的数据采集，核心不是选最贵的硬件，而是把现场设备的通信能力、生产节奏对数据实时性的要求、以及上层系统的数据消费方式三者对齐。PLC控制柜内的边缘接入、合理的协议转换架构、规范的点位管理，是让工业自动化数据真正产生价值的三个支点。
