An IIoT project does not become robust simply because a PLC is connected to the cloud. The architecture must preserve deterministic control, isolate external dependencies, and define what happens when the network is unavailable.
Separate control from information flow
A useful reference model is:
Sensors / Actuators
↓
CODESYS PLC: deterministic control and local alarms
↓
Edge Layer: buffering, protocol conversion, filtering
↓
Cloud: storage, dashboards, analytics, fleet comparison
The PLC should remain capable of performing its essential control function when the edge or cloud connection is interrupted. Cloud connectivity should enhance visibility and optimization, not become an unplanned dependency for basic machine safety.
What belongs in each layer?
| Layer | Appropriate responsibility |
|---|---|
| PLC | Control loops, interlocks, local state, immediate alarms |
| Edge | Buffering, normalization, protocol conversion, local forwarding |
| Cloud | Long-term storage, dashboards, cross-site analytics, reporting |
The boundary is not absolute, but it is a useful design test. If a function must work within a few milliseconds, it probably belongs closer to the controller. If it compares months of data across multiple sites, it probably belongs in the cloud.
Design for disconnection
Network failures are normal operating conditions in industrial systems. Define behavior for:
- Broker or API unavailable
- DNS or certificate failure
- Slow response and timeout
- Edge storage full
- Duplicate messages after reconnect
- Data older than the acceptable freshness window
A practical edge buffer can store unsent telemetry with a timestamp and sequence number. After reconnect, the system can resend data in order or apply a documented drop policy.
Security boundaries
Before enabling external connectivity, document:
- Which network zone contains the PLC
- Which device is allowed to initiate outbound connections
- Which ports and destinations are required
- How certificates and credentials are stored and rotated
- Which data may leave the site
- Which commands, if any, may return from IT systems to OT
Telemetry upload and remote control should not be treated as the same risk. A read-only outbound data path is usually easier to review than a path that permits external writes into the machine.
Commissioning in stages
A low-risk implementation sequence is:
- Validate sensor values and local PLC alarms.
- Validate the local HMI and historical trend.
- Add an edge collector with read-only access.
- Test MQTT or REST transmission with synthetic data.
- Confirm cloud timestamps, quality, and missing-data handling.
- Run a controlled network-disconnection test.
- Expand to additional assets after the PoC acceptance criteria are met.
This sequence separates field measurement problems from network and cloud problems. It also produces evidence for operations and cybersecurity reviews.
The architecture review checklist
- Can the machine operate safely without the cloud?
- Are timestamps and quality states preserved end to end?
- Is there a defined buffer and retry policy?
- Are commands separated from telemetry?
- Are certificates, credentials, and firewall rules documented?
- Can operators identify stale data?
- Is the design repeatable for the next line or site?
Conclusion
CODESYS can serve as a capable edge controller when its responsibilities are clearly defined. A successful IIoT architecture keeps deterministic control local, uses the edge for reliable data movement, and uses the cloud for broader insight. The result is easier to operate, secure, and scale.
This five-part series is based on the themes of the CODESYS V3 Advanced System Architecture & IIoT training program: runtime optimization, modular design, industrial communication, REST, MQTT, and cloud connectivity.