CODESYS Runtime as a Managed Payload
The CODESYS Tech Talk gave us our first public platform to explain how EmberNet works with the CODESYS ecosystem specifically: CODESYS Runtime deploys as a managed container payload on EmberRTOS. Your existing CODESYS project, I/O configuration, and SFC or ladder logic load into the Runtime container without modification. The EmberRTOS layer handles the OS, security posture, and hardware abstraction, while CODESYS handles what it always has: the PLC runtime and your application logic.
The core architectural point is the separation of concerns. In a traditional setup, CODESYS Runtime sits on a general-purpose operating system that can be SSH'd into, patched inconsistently across a fleet, and modified by anyone with access. On EmberRTOS, the OS layer is immutable at runtime. The CODESYS Runtime container runs above that layer, isolated from the OS. Updates to the Runtime are delivered as container image replacements, rolled out through EmberCORE with staged deployment and automatic rollback if the new image fails health checks.
Fleet management is where the combination becomes practically useful. If you are running CODESYS Runtime across 50 nodes on a plant floor, managing updates manually is not viable. Through EmberCORE, you define a group policy that pins all nodes in a given zone to a specific CODESYS Runtime image version. When you qualify a new Runtime version, you promote it to the group, EmberCORE stages the rollout, and any node that fails to pass post-update health checks automatically reverts. The running CODESYS application on a failed node resumes on the previous Runtime version without manual intervention.
Zero-trust networking applies to the CODESYS layer as well. EmberFLUX enforces a default-deny posture at the OS level. CODESYS Runtime can communicate over OPC-UA, Modbus, and MQTT as configured in your application, but those connections are governed by the same policy engine that controls all other node traffic. Remote access for CODESYS application debugging uses an outbound-initiated maintenance tunnel that closes automatically when the session ends. No open inbound ports. No persistent VPN into the plant network.
Common Questions
Does CODESYS Runtime on EmberRTOS support real-time cycle times?
Yes. EmberRTOS is built on a real-time kernel with deterministic scheduling. CODESYS Runtime runs in a container with CPU and memory reservations that isolate it from other workloads on the same node. Real-time cycle times are maintained regardless of other containerized payloads running alongside it.
Can I run multiple CODESYS Runtime instances on one node?
Yes. Each Runtime instance runs in its own container with its own resource allocation and I/O configuration. EmberCORE treats each container as an independently managed payload. You can update, restart, or roll back one instance without affecting the others.
What happens to my running CODESYS application during an OS update?
EmberRTOS handles OS updates as atomic image replacements with a reboot. During the update window, payloads are stopped, the OS image is replaced, and payloads restart on the new OS. The CODESYS application state is preserved in persistent storage that survives the update. Recovery time depends on your hardware and application startup time, typically under 60 seconds from reboot to running application.