RK3588 + CODESYS 工业控制器能在单个 ARM 平台上同时运行 PLC 逻辑、HMI、协议转换和边缘 AI 推理。对开发 AGV、检测站、电池系统、机器人辅助设备和紧凑型生产设备的机器制造商来说,这种整合很有吸引力:既能减少控制柜内的独立计算机数量,又能打通一条从现场 I/O 到本地分析的统一数据通路。

但它并不能直接替换所有传统 PLC。RK3588 是应用处理器,而一台量产控制器还取决于 Linux BSP、实时配置、CODESYS 运行时及许可证、I/O 隔离、现场总线硬件、看门狗策略、热设计和生命周期支持。所以真正值得关注的工程问题不是“CODESYS 能不能在 RK3588 上跑?”,而是整套平台能确定性地完成哪些控制任务,以及如何证明这一点。

本指南把 SoC 能力与板级实现、授权软件支持分开讨论,并说明采购团队在把 RK3588 CODESYS 板当作工业 PLC(而不是一台性能不错的开发计算机)之前,应当要求供应商提供哪些资料。

集成架构实际包含什么 #

Rockchip 将 RK3588 定义为八核处理器,含四个 Cortex-A76 和四个 Cortex-A55 CPU 核心、一个 Mali-G610 GPU,以及按厂商所述条件最高 6 TOPS 的 NPU。这些模块为 Linux 服务、可视化和受支持的推理负载留出了可用的余量,但它们本身并不提供隔离数字 I/O、确定性现场总线时序或通过安全认证的控制链路。

CODESYS 提供符合 IEC 61131-3 的 Control for Linux ARM SL 运行时,适用于运行受支持 Debian 系 Linux 配置的 ARMv7 和 ARMv8 设备。其官方产品资料列出了 EtherCAT Master、CANopen、Modbus TCP/Serial、EtherNet/IP 等现场总线功能。这一产品系列层面的兼容性只是起点,并不能说明任意 RK3588 载板、内核和网络接口已经作为特定生产型控制器通过验证。

RK3588 CODESYS 工业软 PLC 架构,从现场 I/O 到边缘 AI
Original LimChip architecture showing separated control, fieldbus, Linux and edge-AI paths

有意分离各项职责时,这种架构效果最好:

  • PLC 任务域运行 IEC 控制逻辑、状态机、互锁和设备时序。
  • 实时通信域通过 EtherCAT、CAN/CAN-FD 网关、Modbus 或其他合格接口交换过程数据。
  • Linux 应用域负责 HMI、数据库、日志、远程维护和协议服务。
  • NPU/视觉域执行受支持的推理任务,并将结果以有界方式传给 PLC 应用,而不是引入不受控的时序依赖。
  • 独立的安全与关断路径用于处理那些风险评估无法依赖通用 Linux 应用处理器的功能。

这种分离比“一颗芯片上的 PLC + AI”这类营销说法更重要。只有在隔离、故障行为和时序仍然可理解的前提下,整合才应减少硬件。

RK3588 用于软 PLC 的优势 #

混合负载下的 CPU 余量 #

异构 CPU 集群提供的应用余量远高于小型 MCU 级控制器。设计时可以为控制任务保留 CPU 亲和性,把其他核心留给 HMI、数据采集、OPC UA 服务或维护工具。但实际能否把这些余量转化为稳定的延迟,取决于调度策略、中断路由、内核配置和热降频。

CODESYS 指出,其标准 Linux 运行时中的 IEC 应用存在平台特定限制,在某些当前产品配置中,执行会被绑定到单个 CPU 核心。因此,买家应要求提供实际的任务负载和抖动测量数据,而不是想当然地认为八个 CPU 核心就能自动加速一个 PLC 任务。

用于本地视觉和异常检测的 NPU #

当控制器还需承担图像分类、缺陷筛查、物体存在检测或设备状态推断时,RK3588 NPU 就能派上用场。一种实用做法是让推理保持异步:AI 服务发布结果,附带时间戳、置信度和有效性标志;PLC 则依据确定性规则决定机器可以执行哪些动作。

峰值 TOPS 并不等于控制周期的保证。模型转换、算子支持、量化、内存带宽、摄像头流水线、运行时版本和散热都会影响实际吞吐量。验收测试应使用实际要部署的模型,并模拟最坏情况下的 PLC/HMI 并发流量。

丰富的载板集成 #

RK3588 模块可引出 PCIe、USB、以太网、UART、SPI、I²C 等资源,而不同载板还可能增加 RS-485 收发器、隔离 CAN 接口、M.2 连接、GPIO 或工业电源输入。SoC 数据手册描述的是芯片本身具备的资源;载板原理图才决定了成品控制器实际提供哪些接口。

用户提供的 RK3588 系统级模块生产板,按原样发布
User-supplied RK3588-class module production photo with the existing watermark retained

量产阶段,计算模块只是产品中的一层。内存密度、eMMC 等级、PMIC 版本、连接器镀层、PCB 版本和导热界面材料都必须在各批次间保持一致。

CODESYS 兼容性:哪些支持,哪些还需验证 #

运行时与 IEC 工程流程 #

CODESYS 将 CODESYS Control for Linux ARM SL 定位为面向 Linux/ARM 工业控制器、符合 IEC 61131-3 的 SoftPLC。官方要求中明确了 ARMv7/ARMv8 架构和受支持的 Debian 系 Linux 环境,以及运行时库、基于 SSH 的部署方式和许可条件。要确定目标设备支持哪些功能,官方特别推荐使用 CODESYS Device Reader 工具。

由此可以得出一个有技术依据的说法:只要 RK3588 ARMv8 Linux 平台的 OS 和设备特性满足运行时要求,它就可以作为 CODESYS Control for Linux ARM SL 的候选平台。但不能据此说每块 RK3588 板都“原生通过 CODESYS 认证”,除非板卡供应商能提供对应的认证或兼容性记录。

工程团队至少应冻结以下软件项:

软件项生产问题
CODESYS Development System发布的项目是由哪个版本和设备描述创建的?
CODESYS Control 运行时安装了哪个产品、版本、许可证类别和已激活选项?
Linux 发行版是否在供应商测试范围内,发布的是哪个镜像校验和?
内核和实时配置验证了哪种 PREEMPT/RT 策略、CPU 亲和性和中断设置?
BSP 和设备树谁维护 Ethernet、CAN、串口、GPIO、看门狗和 NPU 驱动?
现场总线软件包包含哪些主站/适配器和许可证授权?
恢复路径现场设备能否在没有工厂访问权限的情况下恢复已批准的镜像和许可证?

EtherCAT 是系统级结果,不是连接器标签 #

CODESYS 为其 Linux ARM 运行时列出了 EtherCAT Master 支持,其 EtherCAT 文档也说明了如何通过网络接口在 Linux 上运行。这只能说明软件具备相应能力。确定性循环时间仍取决于所选的 Ethernet 控制器、驱动路径、内核延迟、任务调度、分布式时钟配置、从站拓扑以及竞争性网络流量。

在生产规格中使用“支持 EtherCAT 实时运动控制”之前,应要求提供一份测试报告,其中说明:

  1. CODESYS 运行时、EtherCAT 软件包、内核和 BSP 版本。
  2. EtherCAT 网段所用的具体 Ethernet MAC/PHY 和端口。
  3. 从站数量和类型、过程映像大小以及分布式时钟模式。
  4. 请求的循环时间、实测抖动、最大延迟和测试持续时间。
  5. 最坏情况测试期间 CPU、NPU、HMI、存储和网络的负载情况。
  6. 线缆断开、从站掉线、任务超时和看门狗超时时的故障行为。

在未指定循环时间的情况下,台架演示成功只能说明通信能通,不能作为同步多轴运动的验证依据。

CAN-FD 和 RS-485 需在板级确认 #

宣传资料常把“RK3588”“多路 CAN-FD”和“RS-485”写在同一行。但实际引出多少路通道、是否电气隔离、终端匹配、浪涌保护以及连接器引脚定义,都取决于载板设计。有些通道并非 SoC 直接引出,而是通过外部控制器或 USB/PCIe 桥接实现。

针对每个端口,需索取收发器型号、隔离等级、终端匹配方案、ESD/浪涌测试依据、支持的波特率以及 Linux 驱动。若在 CODESYS 下使用 CANopen,还需确认该接口能否通过受支持的 SocketCAN 路径访问,以及是否包含所需的管理器/设备许可证。

实时控制、AI 与安全边界 #

硬控制回路不能交给 AI 推理 #

NPU 推理任务会与控制负载争抢内存带宽、散热余量和软件服务。即便平均性能看起来够用,模型初始化、图像突发或驱动恢复仍可能造成延迟长尾。安全联锁和严格受限的运动回路应独立于推理完成情况运行。

稳妥的分工方式是:

  • AI 负责识别物体、缺陷或运行状态。
  • 结果附带时间戳、质量值和超时。
  • PLC 逻辑检查数据新鲜度和机器状态。
  • 由确定性运动或安全子系统执行允许的动作。

这样,AI 可以改进机器,而不会在不知不觉中变成一个不合格的安全控制器。

软 PLC 不等于安全 PLC #

兼容 CODESYS、使用 IEC 61131-3 编程,并不自动意味着具备 SIL、PL 或经过认证的安全功能。急停、防护门监控、安全转矩关断等风险降低措施,必须依据机器的安全分析来实施,并采用合适的认证组件和架构。

RK3588 控制器可以监督、可视化或诊断安全系统,但这与声称它实现安全功能是两回事。采购文件中,“工业级”“实时”“功能安全”和“安全认证”应作为各自独立、有据可查的属性分别列出。

处理器之外的硬件设计要求 #

电源、隔离与保护 #

用户提供的 RK3588 工业控制器板,原样发布
User-supplied RK3588 controller-board photo with existing labels retained

工业控制器通常由机柜内的 12 V 或 24 V 电源供电,而不是实验室的 USB 电源。输入级可能需要反极性保护、浪涌和 EFT 抗扰度、滤波、掉电保持以及隔离电源轨。所附板卡展示了一种模块化 DC/DC 供电方案,但仅凭板上的标记无法证明整个控制器已通过合规认证。

应要求供应商提供负载下的输入范围、欠压阈值、重启行为和保护测试报告。如果现场 I/O 与计算域共地,需明确指出哪些部分做了隔离、哪些部分没有。

散热与存储耐久性 #

PLC、可视化和 NPU 负载持续运行时,SoC、内存和 PMIC 可能同时处于工作状态。应在实际外壳和机柜温度下验证设计,而不能只在开放式台架上测试。老化测试期间需记录 CPU/NPU 降频、内存温度、存储温度和控制周期抖动。

eMMC 同样属于维护项。日志记录、数据库以及类容器化的应用更新都可能造成写入放大。需确认容量、耐久性预期、分区策略、只读根文件系统选项、日志轮转机制,以及更新中断后的恢复能力。

看门狗与可恢复性 #

生产控制器应具备独立硬件看门狗、启动期间输出状态可控、掉电处理机制以及已知的恢复镜像。看门狗必须针对实际死锁和过载场景做测试;只列出一颗看门狗 IC 或一个 Linux 服务是不够的。

用户提供的工业控制器老化设置,原样发布
User-supplied multi-unit controller test photo with the existing watermark retained

设备数量一多,在单台开发样机上不易暴露的故障就更容易被发现。一份有用的老化记录应把序列号、板卡版本、固件校验和、内存/存储配置、温度、端口测试和故障处置关联起来。通电只是起始条件;测试报告必须写明实际测了哪些项目。

应用适配性:该架构在哪些场景表现良好 #

应用RK3588 + CODESYS 为何适用主要设计验证问题
视觉检测工位PLC 时序控制、HMI 和本地 NPU 推理集成在一个控制器中推理负载是否会改变控制延迟或热特性?
AGV/AMR 辅助控制以太网/CAN 集成、导航服务和机器逻辑哪个安全控制器和电机控制回路保持独立?
包装或装配单元CODESYS 逻辑加 EtherCAT I/O 和丰富的可视化是否在完整从站拓扑下验证了周期抖动?
电池/储能柜协议网关、数据记录、HMI 和监控电源、隔离和 EMC 是否针对柜体环境设计?
机器人外围控制器视觉、夹爪/夹具逻辑和连接性高带宽伺服控制是本地执行,还是委托给合格的驱动器?

如果一台小型设备只需要少量确定性 I/O 点,或者安全关键型控制器已有经过认证的 PLC 能满足需求、设计验证工作量更低,那这套架构就不太有说服力。是否整合,要看系统价值,不能只看处理器规格。

RK3588 CODESYS 控制器的采购清单 #

“RK3588 + CODESYS”是一套可配置的系统,而不是单一料号。下单前请确认:

  • 计算模块和载板的确切版本: PCB 版本、连接器、RK3588/RK3588S 型号、RAM、eMMC 和 PMIC。
  • CODESYS 授权: 运行时产品、许可证类别、现场总线/SoftMotion 选项、激活方式和恢复流程。
  • 已发布的软件镜像: Linux 发行版、内核、BSP、设备树、NPU 运行时和镜像校验和。
  • EtherCAT 验证数据: 已测试端口、从站拓扑、周期时间、抖动以及最坏情况下的并发负载。
  • 工业接口: 隔离或非隔离 CAN/CAN-FD、RS-485、以太网和数字 I/O,并附收发器详细信息。
  • 运行环境: 已验证的温度、输入电压范围、振动、EMC 和外壳条件。
  • 散热方案: 散热器/风扇/界面材料、降频阈值和更换策略。
  • 生命周期控制: 内存、eMMC、PMIC、PCB、BSP 和 CODESYS 版本变更的通知流程。
  • 生产测试: 序列号可追溯性、端口测试覆盖范围、老化条件和验收记录。
  • 支持归属: 当组合工作负载出现故障时,由谁修复 BSP、现场总线、运行时、HMI 和 AI 栈?

询价时请提供预计年用量、试产数量、RAM/eMMC 配置、所需端口、输入电源、温度范围、CODESYS 和现场总线选项、目标 EtherCAT 周期、AI 模型/摄像头工作负载以及目的地。这些信息比笼统地问一句“工业 RK3588 板卡多少钱”有用得多。

结论 #

对于基于 CODESYS 的工业软 PLC,RK3588 可以成为强有力的计算基础,尤其当一台机器需要把 PLC 逻辑、可视化、连接和边缘 AI 集成在一个平台上时。CODESYS 官方支持 Linux/ARM SoftPLC 部署,并提供了该架构所需的现场总线构建模块。

只有板卡、BSP、运行时许可证、EtherCAT 路径、实时配置、热行为和故障处理一起经过验证,成品控制器才可信。因此,正确的采购决策并不是抽象地比较“RK3588 还是 PLC”,而是看某个特定的、受版本控制的 RK3588 控制器是否有足够证据,在不削弱确定性、可维护性或安全边界的前提下,替代目标机器中的分立设备。

官方参考 #

最终设计决策请以原厂数据手册及获批准的工程资料为准。