RK3588 + CODESYS Industrial Soft PLC Design Guide

An RK3588 + CODESYS industrial controller can combine PLC logic, HMI, protocol conversion and edge-AI inference on one ARM platform. That consolidation is attractive for machine builders developing AGVs, inspection stations, battery systems, robot auxiliaries and compact production equipment. It can reduce the number of separate computers in a cabinet and create a common data path from field I/O to local analytics.

It is not, however, a drop-in replacement for every conventional PLC. The RK3588 is an application processor, while a production controller also depends on the Linux BSP, real-time configuration, CODESYS runtime and license, I/O isolation, fieldbus hardware, watchdog strategy, thermal design and lifecycle support. The useful engineering question is therefore not simply “Can CODESYS run on RK3588?” but which control jobs the complete platform can execute deterministically and how that capability is proven.

This guide separates SoC capability from board-level implementation and licensed software support. It also explains what procurement teams should request before treating an RK3588 CODESYS board as an industrial PLC rather than a capable development computer.

What the integrated architecture actually contains #

Rockchip specifies the RK3588 as an eight-core processor with four Cortex-A76 and four Cortex-A55 CPU cores, a Mali-G610 GPU and an NPU rated up to 6 TOPS under the vendor's stated conditions. Those blocks create useful headroom for Linux services, visualization and supported inference workloads. They do not by themselves provide isolated digital I/O, deterministic fieldbus timing or a safety-certified control chain.

CODESYS offers an IEC 61131-3-compliant Control for Linux ARM SL runtime for ARMv7 and ARMv8 devices running supported Debian-based Linux configurations. Its official product material lists EtherCAT Master, CANopen, Modbus TCP/Serial, EtherNet/IP and other fieldbus functions. Compatibility at that product-family level is the starting point—not evidence that an arbitrary RK3588 carrier, kernel and network interface have already been validated as a specific production controller.

The architecture works best when responsibilities are intentionally separated:

• The PLC task domain runs IEC control logic, state machines, interlocks and equipment sequencing.
• The real-time communication domain exchanges process data through EtherCAT, CAN/CAN-FD gateways, Modbus or other qualified interfaces.
• The Linux application domain handles HMI, databases, logs, remote maintenance and protocol services.
• The NPU/vision domain performs supported inference workloads and passes bounded results—not uncontrolled timing dependencies—into the PLC application.
• An independent safety and shutdown path handles functions whose risk assessment cannot rely on a general-purpose Linux application processor.

That separation is more important than the marketing phrase “PLC + AI on one chip.” Consolidation should reduce hardware only where isolation, failure behavior and timing remain understandable.

Why RK3588 is attractive for a soft PLC #

CPU headroom for mixed workloads #

The heterogeneous CPU cluster provides substantially more application headroom than a small MCU-class controller. A design can reserve CPU affinity for control tasks while leaving other cores for HMI, data collection, OPC UA services or maintenance tools. In practice, scheduling policy, interrupt routing, kernel configuration and thermal throttling determine whether that headroom becomes stable latency.

CODESYS notes that IEC applications in its standard Linux runtime have platform-specific restrictions, including execution bound to one CPU core in some current product configurations. Buyers should therefore ask for actual task-load and jitter measurements rather than assuming that eight CPU cores automatically accelerate one PLC task.

NPU for local vision and anomaly detection #

The RK3588 NPU can be valuable when the controller also performs image classification, defect screening, object presence checks or equipment-condition inference. A practical pattern is to keep inference asynchronous: the AI service publishes a result with a timestamp, confidence and validity flag; the PLC applies deterministic rules to decide what the machine may do.

Peak TOPS is not a control-cycle guarantee. Model conversion, supported operators, quantization, memory bandwidth, camera pipeline, runtime version and cooling all affect real throughput. An acceptance test should use the intended model and worst-case concurrent PLC/HMI traffic.

Rich carrier-board integration #

RK3588 modules can expose PCIe, USB, Ethernet, UART, SPI, I²C and other resources, while individual carrier boards may add RS-485 transceivers, isolated CAN interfaces, M.2 connectivity, GPIO or industrial power inputs. The SoC data sheet describes silicon resources; the carrier schematic defines what the finished controller actually offers.

At production scale, the compute module is only one layer of the product. Memory density, eMMC grade, PMIC revision, connector plating, PCB revision and thermal interface material must remain controlled across batches.

CODESYS compatibility: what is supported and what must be proven #

Runtime and IEC engineering workflow #

CODESYS Control for Linux ARM SL is presented by CODESYS as an IEC 61131-3-compliant SoftPLC for Linux/ARM industrial controllers. The official requirements specify ARMv7/ARMv8 and supported Debian-based Linux environments, along with runtime libraries, SSH-based deployment and licensing conditions. The CODESYS Device Reader tool is specifically recommended to determine which features are supported by a target device.

This supports a technically defensible statement: an RK3588 ARMv8 Linux platform can be a candidate for CODESYS Control for Linux ARM SL when its OS and device features meet the runtime requirements. It does not support saying every RK3588 board is “natively CODESYS certified” unless the board vendor can provide that exact certification or compatibility record.

The engineering team should freeze at least these software items:

EtherCAT is a system result, not a connector label #

CODESYS lists EtherCAT Master support for its Linux ARM runtime, and its EtherCAT documentation describes Linux operation through network interfaces. That establishes software capability. Deterministic cycle time still depends on the selected Ethernet controller, driver path, kernel latency, task scheduling, distributed-clock configuration, slave topology and competing network traffic.

Before using “supports EtherCAT real-time motion control” in a production specification, require a test report that states:

1. CODESYS runtime, EtherCAT package, kernel and BSP versions. 2. Exact Ethernet MAC/PHY and port used for the EtherCAT segment. 3. Number and type of slaves, process-image size and distributed-clock mode. 4. Requested cycle time, observed jitter, maximum latency and test duration. 5. CPU, NPU, HMI, storage and network loads active during the worst-case test. 6. Fault behavior for cable loss, slave dropout, task overrun and watchdog expiry.

A successful bench demo at an unspecified cycle time is useful evidence of connectivity, but it is not qualification for synchronized multi-axis motion.

CAN-FD and RS-485 need board-level confirmation #

Marketing often combines “RK3588,” “multiple CAN-FD” and “RS-485” in one line. The number of exposed channels, galvanic isolation, termination, surge protection and connector pinout are carrier-board properties. Some channels may be delivered through external controllers or USB/PCIe bridges rather than direct SoC peripherals.

For each port, request the transceiver model, isolation rating, termination scheme, ESD/surge test basis, supported baud rate and Linux driver. For CANopen under CODESYS, also confirm whether the interface is visible through the supported SocketCAN path and whether the intended manager/device license is included.

Real-time control, AI and safety boundaries #

Do not let AI inference own the hard control loop #

An NPU inference job can share memory bandwidth, thermal budget and software services with control workloads. Even when average performance looks comfortable, model initialization, image bursts or driver recovery can create latency tails. Keep safety interlocks and tightly bounded motion loops independent from inference completion.

A robust division is:

• AI identifies an object, defect or operating condition.
• The result carries a timestamp, quality value and timeout.
• PLC logic checks freshness and machine state.
• A deterministic motion or safety subsystem executes the permitted action.

This structure allows AI to improve the machine without silently becoming an unqualified safety controller.

Soft PLC does not mean safety PLC #

CODESYS compatibility and IEC 61131-3 programming do not automatically provide SIL, PL or a certified safety function. Emergency stop, guard monitoring, safe torque off and other risk-reduction measures must follow the machine's safety analysis and use suitable certified components and architectures.

The RK3588 controller may supervise, visualize or diagnose a safety system, but that is different from claiming it implements the safety function. Procurement documents should keep “industrial,” “real-time,” “functional safety” and “safety certified” as separate, evidence-based attributes.

Hardware design requirements beyond the processor #

Power, isolation and protection #

An industrial controller commonly starts from 12 V or 24 V cabinet power, not a laboratory USB supply. The input stage may need reverse-polarity protection, surge and EFT immunity, filtering, hold-up behavior and isolated rails. The attached board shows a modular DC/DC supply approach, but its markings alone do not establish the complete controller's compliance.

Ask for the input range under load, brownout threshold, restart behavior and protection test reports. If field I/O shares ground with the compute domain, identify exactly where isolation is and is not provided.

Thermal and storage endurance #

Sustained PLC, visualization and NPU workloads can keep the SoC, memory and PMIC active simultaneously. Validate the design inside the intended enclosure and cabinet temperature, not only on an open bench. Record CPU/NPU throttling, memory temperature, storage temperature and control-cycle jitter during soak testing.

eMMC is also a maintenance item. Logging, databases and container-like application updates can create write amplification. Confirm capacity, endurance expectations, partition strategy, read-only root options, log rotation and recovery from interrupted updates.

Watchdogs and recoverability #

A production controller should include an independent hardware watchdog, controlled output state during boot, power-fail handling and a known recovery image. The watchdog must be tested against actual deadlock and overload scenarios; simply listing a watchdog IC or Linux service is not enough.

At multi-unit scale, failures that stay hidden in a single development sample become easier to identify. A useful burn-in record ties serial number, board revision, firmware checksum, memory/storage configuration, temperature, port tests and failure disposition together. Powering units is only the starting condition; the test report must show what was measured.

Application fit: where the architecture works well #

The architecture is less convincing for a very small machine that needs only a few deterministic I/O points, or for a safety-critical controller where a certified PLC already meets the need with lower qualification effort. Consolidation should be justified by system value, not processor specifications alone.

Procurement checklist for an RK3588 CODESYS controller #

Treat “RK3588 + CODESYS” as a configurable system rather than a single part number. Before releasing an order, confirm:

• Exact compute module and carrier revisions: PCB revision, connector, RK3588/RK3588S identity, RAM, eMMC and PMIC.
• CODESYS entitlement: runtime product, license class, fieldbus/SoftMotion options, activation method and recovery procedure.
• Released software image: Linux distribution, kernel, BSP, device tree, NPU runtime and image checksum.
• EtherCAT evidence: tested port, slave topology, cycle time, jitter and worst-case concurrent load.
• Industrial interfaces: isolated or non-isolated CAN/CAN-FD, RS-485, Ethernet and digital I/O with transceiver details.
• Operating environment: validated temperature, input-voltage range, vibration, EMC and enclosure conditions.
• Thermal solution: heatsink/fan/interface material, throttling thresholds and replacement policy.
• Lifecycle control: notification process for memory, eMMC, PMIC, PCB, BSP and CODESYS version changes.
• Production test: serial-number traceability, port test coverage, burn-in conditions and acceptance record.
• Support ownership: who fixes the BSP, fieldbus, runtime, HMI and AI stack when a combined workload fails?

For an RFQ, include expected annual quantity, pilot quantity, RAM/eMMC configuration, required ports, input power, temperature range, CODESYS and fieldbus options, target EtherCAT cycle, AI model/camera workload and destination. That information is more useful than asking for a generic “industrial RK3588 board price.”

Conclusion #

RK3588 can be a strong compute foundation for a CODESYS-based industrial soft PLC, especially when a machine needs PLC logic, visualization, connectivity and edge AI in one platform. CODESYS officially supports Linux/ARM SoftPLC deployments and offers the fieldbus building blocks needed for this architecture.

The finished controller is credible only after the board, BSP, runtime license, EtherCAT path, real-time configuration, thermal behavior and failure handling are validated together. The correct procurement decision is therefore not “RK3588 versus PLC” in the abstract. It is whether a specific, revision-controlled RK3588 controller has enough evidence to replace the separate devices in the intended machine without weakening determinism, serviceability or safety boundaries.

Official references #

• Rockchip RK3588 product page
• Rockchip RK3588 brief datasheet download page
• CODESYS Control for Linux ARM SL product page and requirements
• CODESYS Control for Linux ARM SL product data sheet
• CODESYS Control supported device platforms
• CODESYS EtherCAT Master SL product data sheet