2. ctrlX AUTOMATION平台架构解析

要理解 ctrlX AUTOMATION 如何把生产现场的数据送到 MES，必须先看清它的分层结构。很多工程师第一次接触 ctrlX 时，会把它当成"一台更开放的 PLC"，结果在数据集成时反复踩坑：不知道该把采集逻辑放在 ctrlX CORE 里，还是放在边缘设备上；不知道 ctrlX Data Layer 到底是一个通信协议，还是一个数据中枢。本节把平台拆成五个关键角色——ctrlX CORE、ctrlX OS、ctrlX Data Layer、ctrlX App 与边缘设备，逐一说明它们在数据集成中的职责边界与协作方式。

一、从硬件到应用：五层职责的总体关系

ctrlX AUTOMATION 的架构可以理解为"硬件承载系统、系统提供数据中枢、中枢连接应用、应用扩展能力、边缘设备承担汇聚与上送"的层次关系。ctrlX CORE 是运行控制逻辑的硬件平台，通常是一台紧凑型工业控制器，负责实时控制、运动控制以及现场 I/O 交互；ctrlX OS 是运行在 CORE 之上的实时操作系统，提供确定性调度、安全机制和统一的运行时环境；ctrlX Data Layer 是 OS 内部的数据中枢，把控制器内部所有可访问的数据点抽象成统一的路径化节点；ctrlX App 是运行在 OS 上的应用包，可以是厂商提供的功能，也可以是用户自己开发的采集、转换、上送程序；边缘设备则位于控制器与上层 MES 之间，承担协议转换、数据缓存、批量上送和断线续传等职责。

这五者的关系不是简单的上下堆叠，而是"控制域"与"信息域"的衔接。ctrlX CORE、ctrlX OS 和 ctrlX Data Layer 构成控制域的核心，保证实时性和确定性；ctrlX App 是跨越两个域的桥梁，它运行在控制域内，却面向信息域做数据处理；边缘设备则完全属于信息域，负责把数据可靠地送到 MES。理解这条边界，是后续做数据集成设计的前提。

二、ctrlX CORE 与 ctrlX OS：控制域的底座

ctrlX CORE 是整套架构的硬件基础。它通常以紧凑型控制器形态出现，内置多核处理器，支持 EtherCAT、PROFINET、EtherNet/IP 等现场总线，直接连接伺服驱动、远程 I/O 和传感器。在数据集成视角下，CORE 的核心价值在于"数据源头"——所有现场信号最终都汇聚到它这里，成为后续可被访问的数据点。

ctrlX OS 则是运行在 CORE 之上的实时操作系统。它基于 Linux 内核并做了实时性增强，提供确定性的任务调度、内存保护和进程隔离。对数据集成而言，OS 的意义在于"稳定性"：它保证采集 App 不会因为某个任务阻塞而丢失数据，也保证实时控制任务不会被数据上送任务干扰。实际项目中，建议把实时控制任务和数据采集任务分配到不同的 CPU 核上，通过 OS 提供的核绑定能力隔离负载，避免采集频率过高时影响控制周期。

三、ctrlX Data Layer：数据集成的中枢

ctrlX Data Layer 是整个平台最容易被误解的组件。它不是简单的通信协议，而是一个运行在 ctrlX OS 内部的数据中枢，把控制器内所有可访问的数据——PLC 变量、运动控制状态、I/O 信号、App 内部参数——统一抽象成路径化的节点。每个节点有一个类似文件路径的地址，例如 /plc/app/Application/sym/PLC_PRG/MyVar 表示 PLC 程序中 PLC_PRG 程序段下的 MyVar 变量；/motion/axis1/actualPosition 表示 1 号轴的实际位置。

Data Layer 提供三种关键能力：一是统一访问接口，无论底层是 PLC 变量还是驱动参数，上层 App 都用同一套 API 读写；二是发布/订阅机制，App 可以订阅某个节点，当值变化时自动收到通知，而不需要轮询；三是跨进程通信，不同 App 之间通过 Data Layer 交换数据，无需关心对方运行在哪个进程。在数据集成中，Data Layer 就是"数据总线"——采集 App 从它读取数据，转换 App 向它写入结果，上送 App 从它订阅变化。

四、ctrlX App：跨越控制域与信息域的桥梁

ctrlX App 是运行在 ctrlX OS 上的应用包，采用容器化或原生方式部署。它既是控制域的一部分（运行在 CORE 上、能直接访问 Data Layer），又面向信息域（做数据预处理、协议转换、上送准备）。常见的 App 包括 Data Layer App（提供 Data Layer 的 REST/WebSocket 接口）、OPC UA Server App（把 Data Layer 节点暴露为 OPC UA 地址空间）、以及用户用 SDK 开发的自定义采集 App。

在数据集成中，App 的职责是"预处理"。例如，一个典型的采集 App 会订阅 Data Layer 中的 20 个节点，按 100 ms 周期读取，做单位换算和量程校验，然后打包成 JSON 结构，通过 MQTT 发给边缘设备。这里的关键设计点是：不要在 App 里做复杂的业务逻辑，也不要让它直接连 MES 数据库。App 应该只做"采集—轻量转换—转发"，把缓存、重传、协议适配交给边缘设备。

五、边缘设备：可靠上送的最后一公里

边缘设备位于控制器与 MES 之间，是信息域的入口。它不参与实时控制，但承担着数据集成中最容易出问题的环节：网络抖动、MES 接口不稳定、数据量突增。边缘设备的核心能力包括协议转换（把 MQTT 转成 MES 需要的 REST 或数据库写入）、本地缓存（网络中断时把数据存到本地磁盘）、断线续传（恢复后按时间顺序补送）、批量上送（按 1 s 或 5 s 批量提交，降低 MES 压力）以及时间戳对齐（统一使用 UTC 或工厂本地时间）。

一个常见的误区是把边缘设备当成"透明网关"，只做协议转换而不做缓存。实际生产中，MES 侧维护窗口、网络切换、数据库锁表都会导致短时不可用，如果没有本地缓存，这段时间的数据就会永久丢失。建议在边缘设备上配置至少 24 小时的数据缓存容量，并设置缓存水位告警——当缓存超过 80% 时触发提示，避免磁盘写满后新数据被丢弃。

六、五层协作的典型数据路径

把五层串起来看，一条完整的数据路径是这样的：现场传感器信号进入 ctrlX CORE 的 I/O 模块，PLC 程序处理后写入变量；ctrlX OS 调度 PLC 任务和采集 App 任务；采集 App 通过 ctrlX Data Layer 的订阅接口拿到变量值，做单位换算后打包；打包后的数据通过 MQTT 或 OPC UA 发给边缘设备；边缘设备缓存、批量组织后，通过 MES 提供的接口写入数据库或消息队列。整条路径中，Data Layer 是"数据可见性"的边界——只有进入 Data Layer 的数据，才能被 App 访问；边缘设备是"数据可靠性"的边界——只有经过它缓存的数据，才能保证不丢。