1. 课程导入与部署全景

在工业自动化现场，工程师最熟悉的动作是把 PLC 程序下载到控制器，然后观察 I/O 灯是否按预期闪烁。但当业务需求变成“在设备侧实时分析振动频谱”“把视觉检测结果推送到 MES”“让产线控制器直接调用 AI 推理服务”时，传统 PLC 的算力与软件生态就显得捉襟见肘。ctrlX AUTOMATION 给出的答案，是在控制层之上引入一个开放、容器化的边缘计算平台：ctrlX CORE。本课程要解决的核心问题就是——如何把应用可靠地部署到这台边缘设备上，并让它与现场控制、云端服务形成闭环。

学习目标与核心概念

学完本课程，你应当能够独立完成以下任务：识别 ctrlX CORE 上可部署的应用形态；使用 ctrlX WORKS 或 Web 界面完成应用安装、配置与启动；通过 App Builder 或 Docker 方式打包自定义应用；利用 Data Layer 与现场 PLC、I/O 交换数据；对部署后的应用进行日志查看、状态监控与故障回退。这些能力最终指向一个目标：让边缘应用像 PLC 程序一样可管理、可复现、可维护。

先厘清几个容易混淆的概念。ctrlX CORE 是运行 Linux 的工业边缘控制器，它同时提供实时控制运行时（如 ctrlX PLC）和非实时应用运行环境（容器、Snap 包）。ctrlX WORKS 是工程组态工具，负责设备发现、应用管理、PLC 编程和 Data Layer 配置。ctrlX Data Layer 是平台内的统一数据总线，任何应用、PLC 变量、I/O 点都可以映射为带路径的节点，例如 plc/app/Application/sym/PLC_PRG/counter。App Builder 则是把自定义代码打包成 ctrlX 可识别应用格式的构建工具。理解这四者的关系，是后续所有部署操作的基础。

典型场景：边缘应用到底解决什么问题

场景一，设备侧实时质量分析。某包装线需要在 10 ms 周期内采集伺服电流波形，做 FFT 后判断刀具磨损。传统做法是把原始数据上传云端，延迟和带宽都不允许。部署到 ctrlX CORE 后，容器内运行 Python 分析脚本，通过 Data Layer 以 1 ms 周期读取电流节点，分析结果写回 plc/app/Application/sym/PLC_PRG/tool_wear，PLC 直接触发报警。

场景二，协议转换与数据上云。现场有 Modbus RTU 电表、EtherCAT 伺服和 OPC UA 机床。在 ctrlX CORE 上部署 Node-RED 或自定义网关应用，把三类数据统一为 MQTT 主题发布到工厂 broker。部署的关键不是写协议代码，而是配置 Data Layer 节点映射和容器网络模式。

场景三，AI 推理服务下沉。视觉相机通过 GigE 把图像传给 ctrlX CORE，容器内运行 ONNX Runtime 做缺陷分类，推理结果通过 Data Layer 触发分拣气缸。这里部署的难点在于容器需要访问相机网口，必须使用 host 网络模式或配置 macvlan。

端到端部署全景

无论哪种场景，部署流程都可以归纳为一条从开发机到现场设备的链路。下面这张图展示了 ctrlX AUTOMATION 边缘应用部署的完整信号与数据流：左侧是开发与构建环境，中间是 ctrlX CORE 内部的应用运行与数据交换结构，右侧是现场设备与云端。图中同时标出了关键接口和典型参数。

图中左侧的开发环境负责产出可部署的安装包，中间 ctrlX CORE 内部划分为应用运行环境、Data Layer 数据总线和系统服务三层，右侧现场设备与云端通过标准协议消费数据。整条链路的关键在于：应用不是孤立运行的，它必须通过 Data Layer 与 PLC 变量、现场总线节点建立映射关系，才能形成“采集—处理—反馈”的闭环。

部署前的关键决策

在动手安装之前，有几个决策会直接影响后续所有操作。第一，应用形态选择：如果只是运行一个 Python 脚本，用 Snap 包最轻量；如果需要复杂依赖或 GPU 加速，用 Docker 容器更合适；如果逻辑本身属于控制范畴，直接写在 ctrlX PLC 里反而更简单。第二，网络模式选择：容器默认使用 bridge 网络，无法直接访问 EtherCAT 网口；若应用需要抓取实时以太网帧，必须改为 host 模式或 macvlan。第三，Data Layer 节点规划：提前确定应用读写哪些节点、周期是多少、数据类型是否匹配，避免部署后才发现节点路径写错或类型冲突。

部署流程的四个阶段

端到端部署可以拆成四个阶段，每个阶段都有明确的输入、操作和验证点。

阶段一：构建。在开发机上编写应用代码，创建 Dockerfile 或 snapcraft.yaml。以 Docker 为例，基础镜像建议使用 ctrlX 官方提供的 ctrlx-docker-base，它已经包含 Data Layer 客户端库。构建命令为 docker build -t myapp:1.0.0 .，产物是一个本地镜像。验证方式是 docker run 启动后检查日志是否正常输出。

阶段二：打包。将镜像导出为 ctrlX 可识别的格式。通常使用 App Builder 的 ctrlx-app-builder 工具，执行 app-builder build --name myapp --version 1.0.0，生成 myapp_1.0.0.snap 或 myapp_1.0.0.tar。打包时会自动生成 manifest 文件，声明应用需要的 Data Layer 权限和网络端口。

阶段三：安装与配置。通过 ctrlX WORKS 连接目标 CORE，进入“应用管理”界面，上传安装包。安装完成后，在“Data Layer 配置”中把应用声明的节点与实际 PLC 变量或现场总线节点绑定。例如把 app/vibration/result 绑定到 PLC 的 PLC_PRG.alarm 变量。配置完成后启动应用，观察状态指示灯是否变为绿色。

阶段四：验证与回退。验证分三层：应用日志无报错、Data Layer 节点值按预期变化、PLC 侧收到正确信号。如果异常，ctrlX CORE 支持一键回退到上一版本，回退操作在应用管理界面完成，耗时通常在 10 秒以内。

常见误区与排障入口

初学者最容易踩的坑有三个。其一，把 Data Layer 节点路径当成文件路径，写成 /plc/app/... 带前导斜杠，实际 ctrlX 的节点路径不带前导斜杠。其二，容器使用 bridge 网络却试图访问 EtherCAT 从站，结果始终超时，正确做法是启动时加 --network host。其三，应用版本号与 manifest 不一致，导致安装被拒绝，打包时务必保证 --version 与代码内声明一致。