4. PLCnext运行时与Linux底层认知

PLCnext Control 与普通 PLC 最大的区别，在于它并不是“一块跑梯形图的控制器”，而是一台运行着 Linux 的工业计算机，上面叠加了实时运行时、容器引擎和工程框架。要真正用好它，必须把“AREL 运行时—Linux 分区—Docker/App 容器—SSH 维护”这条自下而上的链条看清楚。本节按“从内核到应用”的顺序展开，重点讲清各层职责、边界和实际操作入口。

一、AREL 运行时：实时任务与 Linux 的共存方式

AREL（Automation Runtime Environment Linux）是 PLCnext 的实时运行时，它并不是一个独立操作系统，而是运行在 Linux 内核之上的实时扩展层。其核心机制是：Linux 内核通过 PREEMPT_RT 补丁获得硬实时能力，AREL 在此之上提供 IEC 61131-3 任务调度、过程映像、I/O 访问和组件通信。可以把它理解为“Linux 负责通用计算与外设，AREL 负责确定性控制”。

AREL 内部按任务优先级组织执行：最高优先级是循环任务（如 1 ms 周期），其次是事件任务和系统任务，最低是后台任务。每个任务有独立的周期、优先级和看门狗。工程中常见的 MainTask 默认周期为 10 ms，优先级 1；如果把它改成 1 ms，需要同时确认 CPU 占用率不超过约 70%，否则会触发看门狗导致控制器进入安全状态。判断依据可以直接看 Web 界面 Diagnostics → Runtime 中的任务负载曲线，或通过 Arp.System.Runtime 服务读取 TaskLoad 值。

需要特别注意的是：AREL 与 Linux 共享 CPU 和内存，但实时任务拥有调度优先权。因此，在 Linux 侧跑一个占满 CPU 的脚本，会直接挤压实时任务的余量。这也是后面 Docker 容器必须限制资源的原因。

二、Linux 系统分区：哪些能写、哪些不能写

PLCnext 的 eMMC 被划分为多个分区，理解分区是避免“改坏系统”的前提。典型布局如下：

根文件系统只读是刻意设计：防止意外修改导致系统无法启动。因此，任何“改系统”的操作都必须落在可写分区。例如要放一个自定义启动脚本，应放在 /opt/plcnext/user/ 下，而不是 /etc/。如果确实需要修改系统文件，正确做法是通过 overlay 机制或制作自定义固件，而不是直接 chmod 根分区。

三、Docker 与 App 容器：把应用装进“盒子”

PLCnext 内置 Docker 引擎，用于运行 App 容器。这里的 App 通常指用 C++、Python、Node.js 等编写的非实时应用，例如数据采集、协议转换、Web 服务。容器与 AREL 的关系是：容器运行在 Linux 用户空间，通过 Arp 接口或共享内存与实时任务交换数据，但本身不参与实时调度。

一个典型的容器化 App 包含三部分：镜像（image）、容器（container）和卷（volume）。镜像由 Dockerfile 构建，容器是镜像的运行实例，卷用于持久化数据。PLCnext 推荐把容器数据卷映射到 /opt/plcnext/user/ 下，这样升级固件时数据不会丢失。

# 示例：查看当前运行的容器
docker ps
# 输出示例
CONTAINER ID   IMAGE                    STATUS         NAMES
a1b2c3d4e5f6   myapp:1.0                Up 2 hours     myapp

# 查看容器资源占用
docker stats --no-stream
# 输出示例
CONTAINER ID   CPU %   MEM USAGE / LIMIT
a1b2c3d4e5f6   3.2%    45MiB / 256MiB

资源限制是容器化 App 的关键。建议在 docker run 时显式指定 --cpus 和 --memory，例如 --cpus="0.5" --memory="256m"，防止某个 App 异常时拖垮实时任务。判断容器是否健康，可以看 docker ps 的 STATUS 是否为 Up，以及 docker logs 中是否有持续报错。

四、SSH 系统级配置与维护

SSH 是进入 PLCnext Linux 层的标准入口。默认端口 22，用户名 admin，首次登录密码在控制器正面标签或 Web 界面 Security 页可查。登录后即可执行 Linux 命令、管理容器、查看日志。

常用维护操作包括：

• df -h：查看各分区使用率，重点关注 /opt/plcnext 和 /var，超过 85% 应清理日志或容器卷。
• top 或 htop：查看 CPU 和内存占用，确认实时任务余量。
• journalctl -u plcnext：查看系统服务日志，定位启动失败原因。
• systemctl status docker：确认 Docker 服务是否正常运行。
• arp-system-info：查看固件版本、序列号、运行时状态。

一个实际排障场景：控制器上电后 App 容器未启动。排查顺序是：先 systemctl status docker 确认 Docker 服务；再 docker ps -a 看容器是否处于 Exited；然后 docker logs <容器名> 看退出原因；最后检查 /opt/plcnext/user/ 下卷目录权限是否为 admin 可读写。多数情况下是卷权限或端口冲突导致。

五、四层关系总览

把上述内容串起来，PLCnext 的软件栈可以概括为：Linux 内核提供硬件抽象和实时补丁；AREL 在实时域内调度 IEC 任务；Docker 在非实时域内运行 App 容器；SSH 是贯穿所有层的维护通道。四者共享同一套 CPU、内存和存储资源，因此任何一层的异常都会影响其他层。理解这张关系图，是后续做多协议网关配置、性能调优和故障定位的基础。

掌握这四层关系后，后续配置多协议网关时就能明确：协议栈放在容器里，实时数据交换通过 AREL 接口，持久化配置写入用户分区，所有维护动作通过 SSH 完成。这是 PLCnext 工程化使用的基本心智模型。