RK3588 + openEuler + RTOS + EtherCAT：能否做出一套开放的软 PLC 与工业上位机？
状态：技术探索 / 论坛讨论稿
资料核验日期：2026-08-28
结论边界：本文描述候选架构和验证计划，不代表已经达到生产可用、功能安全认证或可替代商业 PLC。文中性能目标均为待验证目标，不是实测结果。
本文主要回答三个问题：这套软硬件组合能否构成软 PLC 实验平台、OpenPLC 等运行时分别适合做什么，以及上位机与实时控制应如何分层。适合工业控制、嵌入式 Linux、EtherCAT 和设备软件开发者阅读。
一、先说结论
RK3588、openEuler、RTOS 和 EtherCAT 可以组成一条值得验证的工业控制技术路线，但不能把它们简单理解为“在目标硬件平台上安装 OpenPLC”。具体工业板卡、网卡和散热方案仍需在 PoC 开始前冻结。
更准确的目标，是构建一台同时具备以下能力的开放工业控制计算机：
- openEuler 负责设备管理、工程部署、日志、HMI、数据采集和远程运维；
- Linux 实时线程或 RTOS 负责有时间约束的 PLC 扫描与 EtherCAT 周期通信；
- IEC 61131-3 或 IEC 61499 运行时负责执行控制逻辑；
- EtherCAT 主站负责驱动远程 I/O、伺服和其他从站；
- 上位机通过版本化接口读取状态、下发工程和展示趋势，但不进入确定性控制回路。
因此，真正需要回答的不是“OpenPLC 能不能安装”，而是：
在固定的 RK3588 板卡、网卡、内核、运行时和 EtherCAT 从站组合上，整个控制周期能否长期、可重复地守住时限，并在异常时进入可解释的状态？
二、“上位机”“软 PLC”和“运行时”不是同一个东西
工业软件中常把几个概念混在一起。为了讨论清楚，可以把系统拆成五层：
| 层次 | 主要职责 | 候选项目 |
|---|---|---|
| 工程与编程环境 | 编写、编译、部署 PLC 程序 | OpenPLC Editor/工具链、Beremiz IDE、Eclipse 4diac IDE、自研 Studio |
| PLC 运行时 | 周期或事件驱动地执行控制逻辑 | OpenPLC Runtime、Beremiz Runtime、4diac FORTE、自研轻量运行时 |
| 现场总线主站 | PDO/SDO、状态机、DC、从站管理 | SOEM、IgH EtherCAT Master、商业主站栈 |
| HMI/SCADA 上位机 | 画面、报警、趋势、配方、报表 | 待复核的开源 HMI/SCADA、自研 Web/Qt/.NET HMI；Grafana 仅作趋势与观测候选 |
| 系统管理面 | 镜像升级、工程版本、日志、诊断、CIM/云边协同 | openEuler 服务、自研管理平台 |
图 1：系统不是“一个 OpenPLC”，而是工程工具、控制运行时、现场总线、上位机和系统管理共同组成的分层平台。
OpenPLC 主要覆盖“编程工具 + PLC Runtime”，它本身不能替代 EtherCAT 主站的实时工程、完整 HMI/SCADA，也不能自动解决 RK3588 的网卡、中断、DMA 和尾延迟问题。
三、推荐的第一阶段架构：先用 Linux 建立可证伪基线
第一阶段不建议立即把控制循环搬进 RTOS。更短、更容易定位问题的路径是：
RK3588
└─ openEuler + PREEMPT_RT
├─ 管理面：Web/HMI、工程部署、日志、CIM、升级
├─ PLC Runtime：IEC 程序扫描线程
├─ 共享过程映像：输入快照、输出提交、时间戳、序号
└─ EtherCAT Master：实时周期执行上下文 + 独立 PCIe 网卡
└─ EtherCAT I/O / 伺服 / 编码器
PLC 扫描与 EtherCAT 周期执行上下文宜绑定经过实测的专用 CPU，并配置实时调度优先级；普通网络、日志、数据库和界面服务放在其他 CPU 上。RK3588 同时包含 Cortex-A76 与 Cortex-A55，应记录核型、CPU governor、频率、温度、IRQ affinity、housekeeping/RCU 归属以及网卡中断拓扑。本 PoC 的周期路径优先避免文件写入、DNS、数据库访问、同步日志、动态内存分配、模型推理及未经最坏时延验证的锁等待。
Linux 的 PREEMPT_RT 能减少大量不可抢占路径，并通过线程化中断、优先级继承等机制改善实时响应，但它不提供脱离硬件和驱动条件的固定最坏时延保证。Linux 内核文档解释了其调度与锁机制。这里的候选应准确写成“openEuler Embedded + 经 CONFIG_PREEMPT_RT、内核版本和目标 BSP 核验的实时内核（必要时自行构建）”；不能从“openEuler 支持 RK3588”直接推导目标镜像已经启用并验证 PREEMPT_RT。
四、第二阶段架构：openEuler + UniProton 双系统
如果 Linux 单系统在压力、温升或故障场景下无法守住预先登记的目标周期，可以再研究 openEuler MICA + UniProton 的 bare-metal 混合部署。若需求是更强的故障隔离，则应另行评估分区虚拟化或 Hypervisor，以及它们在目标板和目标 RTOS 上的实际支持，不能预设 MICA + UniProton 已经提供强隔离。
Linux / openEuler 域 RTOS / UniProton 域
┌────────────────────┐ ┌────────────────────┐
│ HMI、日志、工程管理 │ 版本化消息 │ PLC 扫描 │
│ CIM、升级、诊断 API │◄──────────────►│ EtherCAT 周期 │
│ 非实时网络服务 │ RPMsg/共享内存 │ 看门狗与超时处置 │
└────────────────────┘ └─────────┬──────────┘
│
独占 EtherCAT NIC
openEuler 25.03 关键特性说明将 MICA 描述为多 OS 部署框架，并列出 RK3588 上 openEuler Embedded 与 UniProton 的 bare-metal 混合部署支持。该资料同时区分 bare-metal 与分区虚拟化：MICA 本身不等于隔离机制，“文档声明支持”也不等于本文已完成目标板或 EtherCAT 控制链验证。仍需逐项证明：
- RTOS 对目标板 GIC、定时器、缓存和看门狗的支持；
- PCIe 或 GMAC 能否由 RTOS 独占；
- NIC 的中断、DMA 和 IOMMU 路径是否正确；
- Linux 与 RTOS 之间通信的最大延迟和故障语义；
- Linux 管理域重启时，RTOS 控制域如何保持或安全停机。
对于每周期闭环的架构，EtherCAT NIC 和实时控制循环通常放在同一个 OS 域更简单。如果网卡由 Linux 控制、PLC 循环位于 RTOS，每周期跨域通信会增加时延预算和失效模式。跨域方案并非不可行，但必须测量 IPC 最坏执行时间，并定义序号、时间戳、双缓冲、陈旧数据策略、超时和安全状态。
图 2：先验证 Linux 单系统；只有基线不达标时才进入 RTOS 混合部署。MICA 是部署框架，不自动提供强隔离。
常用缩写
| 缩写 | 含义 |
|---|---|
| NIC / IRQ | 网络接口控制器 / 中断请求 |
| DMA / IOMMU | 直接内存访问 / 输入输出内存管理单元 |
| IPC / RPMsg | 进程或系统间通信 / Remote Processor Messaging |
| PDO / SDO | EtherCAT 周期过程数据对象 / 非周期服务数据对象 |
| DC / WKC | EtherCAT 分布式时钟 / 工作计数器 |
本文中的 CIM 仅指设备数据采集、标准化、缓冲与上报等制造集成管理能力，不表示已经具备或可以替代完整的工厂 CIM、EAP 或 MES。
五、哪些 PLC 工程与运行时可以考虑？
1. OpenPLC：适合快速验证，但不能直接锁定为产品基线
OpenPLC 的价值在于 IEC 61131-3 使用习惯、完整源代码以及可扩展硬件层。它适合回答“ST/LD 程序能否在 RK3588 上完成输入—逻辑—输出闭环”。
但需要注意：OpenPLC Runtime v3 官方仓库已归档并进入 EOL，官方说明它已被 v4 取代。v3 即使包含 EtherCAT 安装入口，也只适合作为历史对照，不宜成为新产品长期基线。
OpenPLC Runtime v4 官方仓库已经声明提供 ARM64 构建，采用 Editor 与 headless Runtime 分离、REST/HTTPS 管理和 C/C++ Runtime 核心；其当前许可证为 MIT，而 v3 为 GPLv3。这些是上游声明，不是 openEuler + RK3588 + EtherCAT 实时链的实测结论。采用 v4 前仍应重新核验：
- 官方 ARM64 构建在具体 openEuler 版本和 RK3588 BSP 上的兼容性；
- IEC 61131-3 语言和任务模型；
- EtherCAT PDO 与内部过程映像的接缝；
- 扫描周期、在线变更、持久变量和异常恢复；
- Web 管理服务是否与实时线程充分隔离；
- 锁定版本后的许可证、发布方式和安全维护状态。
结论：OpenPLC 可以进入 PoC 候选，但“可以运行”不能直接推导为“可以承担实时 EtherCAT 软 PLC”。
2. Beremiz：值得加入 IEC 61131-3 对照组
Beremiz是面向机器自动化的开源 IEC 61131-3 工具链，使用 PLCopen XML，并通过 MatIEC 等生成链将 IEC 程序转换为 C。评估时不能把它视为单一许可证的整体：IDE/CLI、Python reference runtime 与面向小型目标的 C++ runtime 是不同组件，许可证和分发影响需要按锁定版本分别复核。它适合验证标准工程模型、跨目标部署以及将 PLC 变量连接到外部总线或监控系统。
对这条路线而言，Beremiz 的意义不是“肯定优于 OpenPLC”，而是提供第二套 IEC 61131-3 实现，避免架构被单一运行时的私有格式和生命周期锁死。它同样需要为 EtherCAT、openEuler ARM64 和实时任务模型做集成与实测。
3. Eclipse 4diac FORTE：适合分布式控制研究，但标准不同
Eclipse 4diac FORTE是 Eclipse Foundation 托管项目中的 IEC 61499 Runtime，官方列出 Linux、FreeRTOS、Zephyr 等目标，并称其为 real-time capable。它采用 IEC 61499 的事件/数据功能块模型并支持在线重配置，但不能由该模型直接推导整个目标系统具有硬实时或确定性。
它适合探索分布式设备、边缘控制和 RTOS 可移植性，但不能当作 OpenPLC 的无缝替代：OpenPLC/Beremiz 面向 IEC 61131-3 的传统 PLC 工程语义，4diac 面向 IEC 61499。两者的程序模型、调度方式和工程人员使用习惯不同。
4. 自研运行时：最后选择，而不是第一选择
RK3588 性能充足，很容易诱导团队从扫描循环、变量表和 ST 编译器开始自研。但完整 PLC Runtime 还涉及任务调度、在线变更、持久变量、诊断、调试、版本兼容、异常恢复和工程工具链。
更合理的方式是先定义中立接口：
- 变量字典；
- 输入/输出过程映像；
- 周期任务配置；
- 程序包与版本清单；
- 状态、故障和诊断模型；
- 部署、启动、停止与回滚协议。
然后让 OpenPLC、Beremiz 或 4diac 分别接入同一套实验框架。只有现有运行时明确无法满足关键要求时，再决定自研哪些最小组件。
六、EtherCAT 主站怎么选？
开源方案可先比较 SOEM 与 IgH EtherCAT Master：
| 维度 | SOEM | IgH EtherCAT Master |
|---|---|---|
| 形态 | C 用户态库 | Linux 内核模块与用户态接口 |
| 优点 | 接入快、便于理解协议和定制 | 更贴近 Linux 实时主站的工程结构 |
| 代价 | 库提供协议及状态/恢复原语；应用负责周期调度和产品级故障策略 | 主站核心位于 Linux 内核；与内核版本、NIC 驱动和发行版升级耦合较深 |
| 推荐用途 | 第一轮连通与快速 PoC | 同硬件条件下的实时工程化对照 |
选择不能只看“能扫描到从站”。至少要比较：
- 1 ms 周期下的最大完成时间和 deadline miss；
- PDO、SDO、Distributed Clocks 和 Working Counter；
- 从站掉线、拓扑不符和恢复行为；
- 内核/NIC 支持与长期维护成本；
- 锁定版本后的许可证和交付义务。
两者的周期执行模型也不同：SOEM 通常由用户态实时应用线程驱动；IgH 的主站核心位于 Linux 内核，实时应用通过接口执行 receive/process/queue/send。架构图中的“实时周期执行上下文”因此不是同一个具体线程模型。IgH 1.6 官方文档应作为实现时的版本化依据。
板载千兆网口可以用于连通性实验，但不应自动视为合格 EtherCAT 口。本 PoC 的实时主基线优先采用通过 PCIe 连接、Linux 驱动成熟、IRQ 和节能/中断合并参数可测可控的独立网卡；USB 网卡不作为第一轮实时基线。应先固定 openEuler 内核和 IgH 版本，再根据 IgH 设备驱动支持信息反选 NIC。若只能采用 generic packet-socket 路径，应与 native driver 分开记录并测试尾延迟。EEE、中断合并、GRO/LRO/TSO/GSO、CPU idle 和频率策略不应一律关闭，而应形成开关测试矩阵，以目标驱动和实测结果为准。
七、上位机可以怎么做？
如果“上位机”指可视化、诊断、配方和设备管理，它应运行在 openEuler/Linux 域，而不是 RTOS 实时域。
可考虑三种形态：
方案 A：Web 上位机
- 后端：C++、Rust、Go、Java 或 Python 的非实时管理服务；这些语言候选不进入 EtherCAT 周期执行上下文；
- 前端：React/Vue；
- 数据接口：OPC UA、MQTT、Modbus TCP 或只读共享内存快照代理；
- 适合：设备状态、报警、趋势、工程部署、维护日志和远程诊断。
优点是跨平台、更新方便；缺点是浏览器和 Web 服务绝不能承担实时联锁。
方案 B：Qt/.NET 本地工站软件
- Qt/C++ 适合 Linux 原生工业界面；
- .NET 可用于跨平台业务逻辑，也适合已有 C# 工站技术栈；
- 与实时域通过明确的 IPC、OPC UA 或过程映像代理通信。
适合机器视觉、运动参数、手动调试、配方和设备维护，但急停、安全门和安全扭矩关闭仍应由独立安全链处理。
方案 C：现成 HMI/SCADA 作为验证工具
PoC 阶段可用经维护状态、安全和许可证复核的开源 HMI/SCADA 显示 Modbus、OPC UA 或 MQTT 数据；Grafana 只作为趋势与观测工具。它们适合验证数据链，不承担实时联锁，也不应因此被认定为最终产品架构。
八、建议的 PoC 路线
图 3：实时性需要逐层验证；只看平均值或分位数，不能证明完整 EtherCAT 控制链满足 deadline。
P0：冻结实验对象
固定 RK3588 板卡、散热、openEuler 镜像、内核 commit/config、BSP/DTB、NIC、EtherCAT 从站、主站和 PLC Runtime 版本。确认 CONFIG_PREEMPT_RT、CPU/IRQ 拓扑及回滚镜像。所有结论绑定具体版本，禁止写“最新版”。
P1：Linux 实时基线
比较普通内核和 PREEMPT_RT，在空载、CPU/内存/网络压力及持续温升下，用 cyclictest/osnoise 测量调度唤醒延迟。预先登记 deadline、测试时长、样本量和允许的 miss 数，保留完整样本、P99/P99.9、最大值及最大值发生时的负载和温度。分位数不能代替 deadline miss。
P2：EtherCAT 主站对照
用同一硬件分别验证 SOEM 与 IgH：从站状态机、PDO、SDO、WKC、DC、故障恢复，以及主站 send→receive 的总线往返时间和 DC 相位误差。1 ms 和 500 μs 只是示例实验档位，不是产品指标；应根据从站数量、PDO 数据量和控制负载登记正式目标，只有较宽松档位稳定后才进入更短周期实验。
P3：IEC 控制闭环
接入最小 PLC 程序：输入去抖、互锁、状态机和输出。候选先通过构建、许可证、过程映像接口和任务模型 Gate，再选择至少两套可行运行时做同条件比较。除 PLC 执行时间外，还应测量“输入采样→过程映像→PLC 逻辑→输出提交”的端到端完成时间。
P4：上位机与故障测试
增加只读 HMI、报警和趋势；注入拔线、从站掉电、日志洪泛、管理服务重启、CPU 压力和主站进程异常，检查检测、输出处置、恢复和审计记录。
P5：条件触发 RTOS
只有 Linux 基线无法满足预先登记的实时目标时，才进入 MICA + UniProton bare-metal 混合部署实验；强隔离需求另走分区虚拟化/Hypervisor 评估。先验证启动、IRQ、定时器、共享内存、NIC 独占、DMA/IOMMU 和缓存一致性，再决定是否迁移控制周期。
IgH 是 Linux 内核方案，不能直接迁入 UniProton。RTOS 路径是独立移植工作包，需要选择或移植适用的 EtherCAT Master（候选可能是 SOEM），实现目标 NIC 驱动和 OS 抽象层，并以“RTOS 具备目标网卡、DMA、中断和 EtherCAT 栈闭环”为 go/no-go 门槛。
九、对这条路线的技术预判
下面是工程判断，不是已经验证的事实：
[技术预测]RK3588 的算力可能不是主要瓶颈。 真正的难点更可能集中在 NIC、驱动、中断、DMA、缓存、温控和故障恢复；仍需实测确认。[实验建议]1 ms 可作为第一轮示例档位。 最终目标应由拓扑和应用负载决定；在没有目标硬件数据前宣传 250 μs 或“微秒级实时”没有工程意义。[技术预测]Linux 单系统可能足以完成第一版软 PLC 实验。 RTOS 的价值可能包括更清晰的资源归属和故障边界，但 bare-metal 混合部署不等于强隔离。[设计原则]运行时不应预设唯一答案。 OpenPLC 适合快速认知和 PoC，Beremiz 适合 IEC 61131-3 对照，4diac 适合 IEC 61499 与分布式控制研究。[设计原则]值得优先验证中立工程模型。 如果变量字典、过程映像、任务配置和部署协议独立于运行时，未来更换 OpenPLC、Beremiz 或自研 Runtime 的成本可能降低。[设计原则]上位机和实时控制应明确分层。 Web、AI、数据库和远程运维应消费实时域输出的快照，不进入 EtherCAT 周期执行上下文。[产品假设]最早形成用户价值的切入点可能不是“替代 PLC”。 开放实验平台、教学与研发台架、跨品牌工程生成、设备数据互联和可复现测试工具链值得社区共同验证。
十、哪些结论现在还不能说？
在完成实机测试前，不能宣称：
- 已达到工业级实时；
- 可替代硬 PLC；
- 已兼容某一品牌全部 EtherCAT 从站；
- 可用于功能安全回路；
- 可长期 24×7 稳定运行；
- OpenPLC、Beremiz 或 4diac 中某一个已经是最终产品基线。
更诚实的公开表述是：
我们正在基于 RK3588、openEuler、实时 Linux/RTOS 和 EtherCAT，验证一套开放软 PLC 与工业上位机架构。当前重点是建立可重复的周期、总线、故障恢复和运行时对照实验，而不是提前承诺生产替代能力。
十一、参考资料与证据边界
| 来源 | 支持的正文观点 | 仍需实测或复核 |
|---|---|---|
| openEuler Embedded 文档 | openEuler Embedded 与 UniProton 文档入口 | 目标板镜像、BSP 和实时内核配置 |
| openEuler 25.03：MICA 与 UniProton | MICA 部署模型、RK3588 bare-metal 混合部署声明 | EtherCAT、目标 NIC、时延和隔离效果 |
| Linux PREEMPT_RT 原理 | 实时抢占、线程化中断和锁机制 | RK3588 最坏时延与压力表现 |
| EtherCAT Technology Group 技术说明 | EtherCAT、PDO/SDO 与 Distributed Clocks 基础 | 具体主站、从站和周期性能 |
| SOEM 官方仓库 | 用户态 C 主站库及上游代码/许可证 | openEuler、NIC、RTOS 移植与产品级恢复策略 |
| IgH 官方仓库与 1.6 文档 | Linux 内核主站架构与应用接口 | 目标内核/NIC 驱动路径及升级成本 |
| OpenPLC Runtime v3 / v4 | v3 EOL；v4 架构、ARM64 声明和当前许可证 | RK3588 + openEuler + EtherCAT 实时闭环 |
| Beremiz 官方仓库 | IEC 61131-3 工具链及组件结构 | 各组件锁定版本、许可证和 EtherCAT 集成 |
| Eclipse 4diac FORTE | IEC 61499、目标 OS 与 real-time capable 声明 | 目标硬件确定性和 EtherCAT 接入 |
欢迎提供可复核的实测信息：你在 RK3588/ARM64 平台上使用过哪款 EtherCAT NIC，采用什么内核、主站和从站拓扑，连续测试了多长时间，观察到的最大周期或 deadline miss 是多少？