4. 工业数据采集与ThingWorx连接
设备状态监测的第一步，是把分散在车间里的设备数据稳定、准确地送进ThingWorx。ThingWorx本身并不直接“读懂”PLC、仪表或数控机床，它依赖一层工业连接能力完成协议适配、地址解析和数据规范化。ThingWorx Industrial Connectivity（简称IC，基于Kepware技术）正是承担这一角色的核心组件，它把OPC UA、Modbus、MQTT等不同协议的数据统一成ThingWorx可消费的数据源，再通过数据流（Data Shape与Stream）进入平台。
一、先分清四类协议各自的位置
很多初学者会把OPC UA、MQTT、Modbus混为一谈，其实它们在采集链路中扮演不同角色：
- Modbus（RTU/TCP）：面向现场设备的底层轮询协议，直接读取寄存器。适合PLC、电表、变频器等提供寄存器地址的设备，是“设备侧”协议。
- OPC UA：带信息模型的工业通信标准，既能读地址也能读语义化节点（如“电机1.温度”），支持订阅与安全通道，是“采集层到平台层”的主流协议。
- MQTT：轻量级发布/订阅消息协议，适合带宽受限或需要主动上报的场景，常用于网关到云端的传输。
- ThingWorx Industrial Connectivity：协议转换与通道管理中枢，向下连接各类设备驱动，向上以OPC UA Server或REST方式向ThingWorx暴露数据。
典型链路是：现场设备 →（Modbus/OPC UA）→ IC通道 →（OPC UA/内部接口）→ ThingWorx数据源 → 数据流 → 物模型属性。理解这条链路，才能判断问题出在哪一段。
二、在IC中建立通道与标签
以一台支持Modbus TCP的PLC为例，采集“电机温度”和“运行状态”两个量。操作路径是：新建Channel → 选择Modbus TCP/IP Ethernet驱动 → 填写PLC的IP与端口（默认502）→ 在Channel下新建Device → 在Device下新建Tag。
Tag的关键字段是地址与数据类型。假设温度存放在保持寄存器40001，对应Modbus地址偏移为0，数据类型为16位有符号整数，缩放因子0.1，则配置为：
Tag Name: Motor1_Temp
Address: 40001
Data Type: Word (16-bit)
Scaling: Raw * 0.1 → 单位 ℃
Scan Rate: 1000 ms运行状态可读线圈00001，数据类型Boolean，扫描周期500 ms。配置完成后，IC的Tag Quality应显示“Good”，若为“Bad”，优先检查IP连通性、端口占用和从站地址（Unit ID）。这一步是后续所有工作的前提，标签质量不佳，平台侧再正确也无意义。
三、把IC数据接入ThingWorx
IC内置OPC UA Server，ThingWorx通过“Industrial Connections”或Remote Thing方式连接。在ThingWorx Composer中新建一个Remote Thing，指定IC的OPC UA端点（如opc.tcp://192.168.1.50:49320），然后为Thing添加属性，属性名与IC标签建立绑定。绑定后，ThingWorx会按IC的扫描节奏接收数值变化。
这里有一个容易忽略的点：ThingWorx属性不会自动保存历史。若要做趋势和健康评估，必须为Thing配置ValueStream，并指定DataShape。DataShape定义字段结构，例如：
DataShape: DS_MotorStatus
Fields:
ts DATETIME
temp NUMBER
running BOOLEAN
quality STRINGValueStream选择“Stream”类型并关联该DataShape，属性更新时写入一条记录。这样，温度序列和运行状态就形成了可查询的时序数据，为后续阈值判断和健康评分提供输入。
四、MQTT接入的补充路径
对于已经具备边缘网关、以MQTT上报的设备，可让网关直接发布到ThingWorx支持的MQTT Broker，再由ThingWorx的MQTT订阅或IC的MQTT Client驱动接入。主题设计建议按“厂区/产线/设备/测点”分层，例如：
factoryA/line1/motor1/temp
factoryA/line1/motor1/vibration
factoryA/line1/motor1/status消息体用JSON承载数值与时间戳，ThingWorx侧解析后映射到对应Thing属性。相比轮询，MQTT更适合变化不频繁但要求及时上报的场景，但要注意QoS等级与断线重连策略，避免数据丢失或重复。
五、数据流配置的检查要点
数据流不是“配完就好”，需要验证三件事：一是时效性，属性更新时间与设备实际变化的时间差是否在可接受范围（通常轮询场景下不超过2个扫描周期）；二是完整性，断线恢复后是否有数据缺口，必要时在网关侧做本地缓存补传；三是一致性，同一测点在IC、ThingWorx属性、ValueStream三处的数值和单位是否统一。把这三项确认清楚，采集链路才算真正打通，后续的状态监测与健康评估才有可靠的数据基础。