服务器读取PLC的数据格式化，本质上是将PLC侧以位、字节、字、双字为单位的裸数据，按照既定的协议规则解析并转换为服务器业务系统能识别的结构化数据（如JSON、时序数据或关系型表），核心动作包括字节序转换、数据类型映射和点位地址登记三项。
为什么服务器读到的PLC数据需要格式化
PLC的内部存储以寄存器和数据块为基本单位，CPU在循环扫描中不断刷新这些存储区，服务器通过以太网抓取到的原始报文，是一连串无符号的十六进制字节，例如一个温度值，在PLC里可能是整数（INT）、实数（REAL）或双整数（DINT），报文里则表现为4个字节（如41 20 00 00），若不做格式化，服务器会把这4个字节当成一个普通的16位或32位整数来读，结果可能是天文数字，也可能是0x41200000这种完全没法用的十六进制码。
行业共识认为,数据格式化的本质不是改变PLC内部的存储方式，而是在服务器端建立一套“翻译规则”，告诉服务器：从哪个地址取数据、取几个字节、数据是什么类型、高字节在前还是低字节在前，这套规则在组态软件里叫“变量映射表”，在工业物联网平台里叫“数据字典”。
服务器读取PLC数据的三种格式化方案
协议解析层直接格式化（网关/边缘网关）
适用场景：PLC型号老旧、种类杂乱，服务器侧需要统一数据出口。操作路径：物理链路（PLC网口/串口 → 网关）→ 网关内配置设备驱动 → 填写寄存器地址与数据类型 → 网关输出标准MQTT/Modbus TCP报文。
- 在网关网页后台的“设备管理”页面，添加设备时选择PLC品牌（西门子S7-200 SMART、三菱FX5U、欧姆龙CP1H等）。
- 配置点位时,数据类型下拉框中的
16位无符号、32位浮点、字符串，就是格式化的核心选项，选错类型，数据必然乱码。 - 网关将PLC的站号、寄存器区、偏移地址统一映射成JSON格式的Key-Value键值对，服务器侧HTTP请求直接拿到
{"temperature": 25.6}，无需再做第二次解析。
这一方案对服务器的算力要求最低,格式化工作在靠近设备的一端就完成了，PLC数据怎么传送到服务器的问题，多数成熟项目通过这种方式解决，尤其适合现场有几十台不同品牌PLC的改造场景。
通信中间件实时抓取并格式化（软件层面）
适用场景：PLC已经接入车间交换机网络，服务器上运行着SCADA或自定义采集程序。核心步骤：通过Modbus TCP或S7协议与PLC建立会话，按功能码读取保持寄存器区或数据块，然后在代码里做字节序调整。
以Modbus TCP协议为例，服务器发送读取请求报文（含事务标识符、单元标识符、起始寄存器地址、寄存器数量），PLC返回的响应报文中，每个寄存器固定为2个字节，若PLC侧是32位浮点数，则会占用连续两个寄存器共4个字节，此时存在两种字节排列顺序：
| 数据类型 | 寄存器地址偏移 | 报文字节顺序（大端） | 格式化后值 |
|---|---|---|---|
| INT（16位有符号） | MW0 | F1 2C |
-3780 |
| REAL（32位浮点） | MD2 | 42 F6 E6 66 |
4 |
| DINT（32位有符号） | MD10 | 00 01 86 A0 |
100000 |
实操细节：服务器代码读取到42 F6 E6 66后，不能直接按int32解析，而应先判断PLC的字节序，西门子S7系列PLC默认大端模式（高字节在前），三菱PLC的浮点数默认则需交换字序（低16位在前），行业内调试时最常遇到的“数据差好几个数量级”或“数字巨大无比”，八成是字节序没对齐，字符串类型（如设备型号）在PLC内多为ASCII码，格式化时需要按字节截取，并去除末尾的空格填充符。
OPC UA/数据库直连方式
适用场景：需要服务器定期批量读取点位，并且PLC侧配置了OPC UA服务器（西门子S7-1500、S7-1200固件4.0以上均支持），OPC UA的信息模型天然含有数据类型定义，服务器端通过OPC UA客户端浏览节点时，直接读取Value属性的类型和值，无需手动指定字节序，这一方式在服务器读取PLC的数据格式化工作中最省力，但需要PLC编程软件额外勾选“允许OPC UA访问”选项，并配置用户证书。
格式化的标准步骤拆解
第一步：创建PLC点位明细表
在Excel中罗列所有要采集的数据点,至少包含三列：中文描述（如1号炉出水温度）、PLC地址（如DB10.DBD2）、数据类型（REAL）
，注意西门子DB数据块的寻址方式，DBD2表示从第2个字节起始的32位数据，且地址必须按类型对齐（REAL需要4字节对齐，不能从奇数字节开始读）。
第二步：服务器端建立数据字典
在写采集程序之前,先把点位明细表导入数据库或配置文件，建议在采集程序里做类型白名单校验只允许bool, int16, uint16, int32, uint32, float32, float64, string这8种类型通过，避免PLC侧地址被意外修改后导致服务器解析崩溃。
第三步：处理数据质量戳
PLC在CPU停止运行或程序未启动时,保持寄存器里的值可能是上一次的残余值，也可能是垃圾数，服务器格式化时，需检查PLC的CPU运行状态位（如S7协议中的Object Dictionary状态字），当状态字显示STOP时，应当给该点位打上“坏质量”标记，而不是把错误数据写入数据库。
第四步：单位换算与工程量转换
传感器采集到的原始值往往是“0-27648”的整数（西门子模拟量输入模块的量程），服务器端需要通过线性变换公式计算工程量：工程量 = 原始值 / 27648 × 量程上限，例如4-20mA电流信号对应0-100℃温度，原始值13824对应的温度就是50℃，这一步虽属后处理，但在多数项目里被归入格式化环节，因为若不转换，业务系统读到的依旧是“看不懂”的数字。
服务器读取PLC数据格式化的选型建议
- 单台PLC、数据量小于100点：直接用Modbus TCP轮询，写一段Python脚本或使用Node-RED，格式化逻辑放在内存里，避免重型中间件带来的额外延时。
- 中大型产线、多品牌PLC混合：选择支持协议转换的工业网关，关注其是否内置西门子、三菱、罗克韦尔等主流驱动，以及是否支持在WEB界面导出Excel点位表批量导入，网关价格在几百元到数千元之间，取决于网口数量和协议授权。
- 需要联动MES/ERP系统：采集完成后，格式化的数据必须按时间戳+点位ID+值的三元组结构写入时序数据库（如InfluxDB、TDengine），否则后续做数据分析和报表仍需二次清洗。
服务器读取PLC数据格式转换工具的选型对比：
| 维度 | 边缘网关 | SCADA软件 | 自研采集服务 |
|---|---|---|---|
| 实施周期 |
5-2天 | 2-5天 | 5-10天 |
| 服务器占用 | 极低 | 中等 | 依赖性能 |
| 灵活性 | 高 | 中 | 最高 |
| 对点位数量变化 | 需逐条增加 | 图形化方便 | 需改配置 |
据工信部公开数据显示,国内工业互联网平台接入的工业设备中，超过半数仍采用传统现场总线或以太网协议直接采集，尚未采用统一的数据格式规范，这意味着多数现场的PLC数据格式化问题，远未到算法层面，仍停留在协议解析和字节序处理的初级环节，从技术演进的角度看，OPC UA over TSN正在成为新一代数据互操作标准，未来三到五年，服务器读取PLC数据时，大概率会在协议栈中直接获得带语义的类型标注，但这并不改变我们当前依然需要通过映射、偏移和类型转换来完成格式化的现实。
Q&A：关于PLC数据格式化的高频疑问
问：PLC数据怎么传送到服务器比较稳定，是选网口还是串口？
答：网口优先，串口（RS485）传输距离有限，且大部分串口服务器的数据处理能力较弱，多字节数据拼接容易出错，网口采集可走标准TCP/IP协议栈，通信稳定性更高，若PLC仅有串口，则需使用带协议解析能力的串口服务器，并在配置界面明确填入寄存器地址的数据类型和字节顺序。
问：服务器读取PLC数据格式转换工具里，选“大端”还是“小端”依据是什么？
答：依据PLC品牌和型号，西门子S7系列、罗克韦尔AB系列默认大端（高字节在低地址）；三菱FX/Q系列默认小端（低字节在低地址）；施耐德Modicon既有大端也有小端选项，需查阅PLC的用户手册中“数据存储格式”章节，改完字节序后重启通信，用PLC编程软件的在线监视值做比对即可确认。
问：PLC数据格式化后写入数据库，用什么数据表结构最方便后续分析？
答：建议单点单值时序表，表结构包含三列：timestamp（毫秒时间戳）、point_id（点位编码，如BOILER_TEMP_01）、value（浮点数），不要为每个点位单独建列，因为PLC点位数量可能随时增减，新增点位若需改动表结构，代价较高，按时间加点位ID存储，查询时直接用WHERE point_id = ? AND timestamp BETWEEN ? AND ?即可，也方便对接主流可视化看板工具。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/696467.html
