4. 工业设备数据采集与ThingWorx Edge

在ThingWorx预测维护系统中，边缘层承担着“把现场设备信号变成可用数据”的第一道工程任务。它既要面对PLC、CNC、传感器、仪表等异构设备，又要处理协议差异、网络不稳定、数据量大和实时性要求高等问题。ThingWorx Edge正是为这一层设计的运行框架：它运行在靠近设备的边缘网关或工控机上，通过Edge SDK扩展自定义协议与业务逻辑，通过内置连接器接入OPC UA、Modbus、MQTT等主流工业协议，并在本地完成数据清洗、聚合、缓存与转发，最终把结构化数据送入ThingWorx平台。

一、Edge SDK：把“不会说的设备”接进来

ThingWorx Edge本身提供了一套基于Java的Edge SDK，用于开发自定义的Edge Thing、协议驱动和边缘服务。它的核心价值在于：当现场存在私有协议、老旧串口设备或非标数据格式时，不必等待平台内置连接器，而是通过SDK编写一个可部署到边缘的扩展包。

一个典型的Edge SDK扩展包含三部分：Thing定义（描述设备属性、服务、事件）、协议解析逻辑（读取字节流、解析帧、校验）、生命周期管理（启动、轮询、断线重连、停止）。例如，某台老式注塑机通过RS-485输出自定义二进制帧，帧头为0xAA55，随后是设备号、温度、压力、状态字和CRC16。开发者可以在SDK中实现一个CustomSerialThing，在start()中打开串口，在轮询周期内读取完整帧，解析后写入ThingWorx属性，并触发DataChange事件。

// 示例：自定义帧解析核心逻辑（示意）
byte[] frame = readFrame();          // 读取完整帧
if (frame[0] != (byte)0xAA || frame[1] != 0x55) return;
int deviceId = frame[2] & 0xFF;
float temperature = ByteBuffer.wrap(frame, 3, 4).order(ByteOrder.LITTLE_ENDIAN).getFloat();
float pressure    = ByteBuffer.wrap(frame, 7, 4).order(ByteOrder.LITTLE_ENDIAN).getFloat();
int status        = frame[11] & 0xFF;
if (!checkCRC16(frame)) return;      // CRC校验失败则丢弃
setProperty("Temperature", temperature);
setProperty("Pressure", pressure);
setProperty("Status", status);

这段逻辑的关键点在于：先校验再解析，避免脏数据进入平台；按小端序读取浮点数，因为许多工控设备采用小端；属性命名与平台Thing模板保持一致，否则后续绑定会失败。SDK扩展开发完成后，打包为.zip或.jar，通过Edge管理界面或远程部署通道下发到网关。

二、工业协议接入：OPC UA、Modbus、MQTT的分工

ThingWorx Edge内置了多种工业协议连接器，实际项目中最常用的是OPC UA、Modbus和MQTT。它们并不是互相替代，而是各自覆盖不同的设备层级和通信场景。

• OPC UA：面向PLC、DCS、SCADA等具备信息模型的高端设备。它支持浏览地址空间、订阅变量、读取历史数据，语义丰富，适合采集结构化程度高的设备数据。接入时通常需要配置Endpoint URL、安全策略（None/Sign&Encrypt）、用户证书和节点ID。
• Modbus TCP/RTU：面向仪表、变频器、电表、老式PLC等。它简单、通用，但只有寄存器地址和数据类型，没有语义。接入时需要配置从站地址、功能码、起始寄存器、寄存器数量和数据类型（如INT16、FLOAT32、BCD）。
• MQTT：面向已经具备网络能力的智能传感器、网关或边缘节点。它采用发布/订阅模型，适合低带宽、高并发场景。ThingWorx Edge既可以作为MQTT客户端订阅设备主题，也可以作为MQTT服务端接收设备上报。

在一个典型的车间里，可能同时存在三种协议：西门子S7-1500通过OPC UA上传产线状态，电表通过Modbus RTU上传电流电压，振动传感器通过MQTT上报高频采样。ThingWorx Edge可以在同一个边缘实例中并行运行多个连接器，统一转换为ThingWorx的Thing属性。

三、边缘数据预处理：在本地把数据“变干净”

边缘预处理不是可选项，而是保证平台数据质量的关键。现场数据常见问题包括：寄存器值跳变、单位不统一、重复上报、瞬时尖峰、断网丢数。ThingWorx Edge允许在数据进入平台之前执行本地处理，常用手段有以下几类。

1. 清洗与校验。对超出物理量程的值直接丢弃或标记为无效。例如温度传感器量程为-20~150℃，若读到9999，说明传感器断线或寄存器异常，应写入Quality=Bad而不是直接上传。

2. 单位换算与标定。Modbus寄存器常以整数存储，需要按比例换算。例如电流寄存器值Raw=1234，比例系数0.01，则实际电流为12.34 A。压力传感器若为4~20mA对应0~1.6MPa，则需按线性公式换算。

3. 滑动平均与降噪。对振动、温度等高频信号，可在边缘做窗口平均。例如每100ms采样一次，取最近10个点的平均值再上传，既降低平台压力，又保留趋势。

4. 变化上报与死区。只有当数值变化超过死区阈值时才上传。例如温度死区设为0.5℃，若上次上传为72.3℃，本次为72.6℃，则不上传；达到72.8℃才上传。这能显著减少无效流量。

5. 断网缓存与补传。Edge网关本地维护一个环形缓存或SQLite队列。当MQTT/HTTPS连接中断时，数据先写入本地；恢复后按时间顺序补传，并带上原始时间戳，避免平台侧时间错乱。

四、远程部署：让边缘节点可管、可升级、可回滚

当现场有几十甚至上百个Edge网关时，逐台登录配置是不现实的。ThingWorx Edge支持通过平台侧远程管理边缘节点，典型能力包括：远程下发Thing配置、部署Edge SDK扩展包、修改连接器参数、重启边缘服务、查看运行日志和连接状态。

实际部署时，建议按以下顺序推进：

1. 建立边缘节点身份：为每个网关分配唯一名称和证书，平台侧创建对应的RemoteThing，确保双向认证。
2. 下发基础配置：包括平台URL、应用密钥、心跳周期、缓存大小、日志级别。
3. 部署协议连接器：按设备清单配置OPC UA Endpoint、Modbus从站与寄存器表、MQTT主题与QoS。
4. 部署SDK扩展包：将自定义协议解析包上传到平台，再推送到目标网关，观察扩展是否加载成功。
5. 验证数据链路：在平台侧查看Thing属性是否按预期更新，检查时间戳、Quality和数值范围。
6. 灰度升级与回滚：先在一台网关上验证新版本，确认无误后再批量推送；保留上一版本包，便于异常时回滚。

判断远程部署是否成功的依据不是“页面显示已下发”，而是：网关日志中出现扩展加载成功记录、平台侧对应Thing属性在预期周期内更新、断网恢复后缓存数据能够补传、且没有出现重复时间戳或Quality异常。只有这些条件同时满足，才说明边缘数据采集链路真正闭环。

综合来看，ThingWorx Edge在预测维护系统中扮演的是“数据入口+本地智能”的角色。Edge SDK解决非标设备接入，OPC UA/Modbus/MQTT覆盖主流协议，边缘预处理保证数据质量，远程部署保证规模化可运维。四者配合，才能让后续的平台建模、告警和预测分析建立在可信的数据基础之上。