3. 设备数据集成基础

在 ctrlX AUTOMATION 的体系里，设备数据集成并不是“把 PLC 变量读出来”这么简单。它要解决的是一个完整链路问题：现场设备产生什么数据、这些数据以什么语义被表达、通过什么通道被采集、在什么时间尺度上被消费，以及当数据缺失或延迟时系统如何应对。理解这条链路，是后续使用 ctrlX Data Layer、ctrlX CORE 应用与各类连接器的基础。

一、什么是设备数据集成

设备数据集成（Device Data Integration）指把来自控制器、驱动器、I/O 模块、传感器、智能电表、机器人控制器等异构数据源的信息，统一采集、规范化并交付给上层应用（如边缘计算、MES、SCADA、云端分析）的过程。它的核心不是“连接”，而是“让数据在正确的时间、以正确的语义、到达正确的位置”。

在 ctrlX AUTOMATION 中，这一过程通常围绕 ctrlX Data Layer 展开。Data Layer 是一个基于路径寻址的数据空间，每个数据点都有唯一路径（如 plc/app/Application/sym/PLC_PRG/Counter），并带有数据类型、访问权限、时间戳等元信息。设备数据集成就是把物理设备的数据映射到这个数据空间中，再由上层按需订阅或读取。

二、数据流模型：从现场到应用

一个典型的数据流模型可以抽象为四层：现场层 → 采集层 → 数据层 → 应用层。现场层是真实设备与信号；采集层负责协议转换与轮询/订阅；数据层是 ctrlX Data Layer 提供的统一命名空间；应用层是消费数据的程序、看板或算法。

以一台通过 EtherCAT 连接的伺服驱动器为例：驱动器的实际位置、速度、电流等参数由 ctrlX CORE 的实时任务周期读取，写入 Data Layer 的对应路径；上层应用通过 REST、WebSocket 或 SDK 订阅这些路径。数据在每一层都可能被加工：采集层做单位换算，数据层做权限与命名规范，应用层做聚合与告警判断。

三、实时性要求：不同场景的时间尺度

“实时”在设备数据集成中不是一个绝对概念，而是一组分层的时间要求。同一台设备的数据，可能同时被不同消费者以完全不同的时间尺度使用：

• 硬实时（微秒至毫秒级）：运动控制环路、安全联锁。这类数据通常不经过 Data Layer 的通用路径，而由实时任务直接处理，周期可低至 250 µs～1 ms。
• 软实时（毫秒至数十毫秒级）：PLC 逻辑状态、过程变量监控。典型 PLC 任务周期为 1～10 ms，Data Layer 订阅延迟通常在毫秒级。
• 准实时（百毫秒至秒级）：设备状态看板、OEE 统计。允许 100 ms～1 s 的延迟，可用轮询或低频订阅。
• 非实时（分钟至小时级）：历史趋势、报表、预测性维护模型训练。可批量上传或定时归档。

判断一个集成方案是否合理，关键看它是否匹配了最严格消费者的时间要求。如果看板只需要 1 s 刷新，却用 1 ms 周期去订阅全部变量，会造成不必要的 CPU 与网络负载；反之，若安全联锁依赖 Data Layer 的异步通知，则可能引入不可接受的延迟。

四、常见挑战与应对思路

实际项目中，设备数据集成常遇到以下几类问题：

1. 语义不一致。同一物理量在不同设备中可能用不同单位、不同数据类型甚至不同符号约定。例如温度有的用 0.1 ℃ 整数，有的用浮点摄氏度。应对方式是在采集层建立映射表，统一到 Data Layer 的规范路径与单位，并在路径命名中体现物理含义。

2. 时间同步。多设备数据若时间戳不同步，聚合分析会失真。ctrlX CORE 支持 NTP/PTP 同步，采集时应尽量使用设备侧或控制器侧的统一时基，而不是各应用各自打时间戳。

3. 数据量与带宽。高频信号全量上传会压垮网络。合理做法是边缘侧做降采样、死区压缩或仅上传变化量。例如位置信号可设置 0.01 mm 死区，只有变化超过阈值才发布。

4. 断连与缓存。网络中断时数据不能丢。Data Layer 可配合本地缓存或边缘存储，在恢复后补传，并在数据中标记“补传”状态，避免上层误判为实时数据。

5. 权限与安全。并非所有应用都应读写所有路径。应在 Data Layer 层面配置访问控制，区分只读、读写、订阅权限，防止误写导致设备异常。

五、一个可参考的集成检查表

下面这份检查表可用于评估一个设备数据集成方案是否完整。字段和判断依据均围绕 ctrlX AUTOMATION 的实际集成工作设计，可直接用于方案评审或实施前自查。