RTA's Blog
The Risks of Using Your PLC as a RESTful Device (and When to Use a Gateway Instead)
Mar
A programmable controller is a very sophisticated and flexible device. It is very good at scanning I/O and solving logic. It is often a poor and risky choice for tasks such as data logging, RESTful interfaces and ASCII communications. Avoid using it in any of these applications except under very strict conditions.
The Challenges of Direct PLC-to-REST Communication
A control engineer, using Siemens PLCs in the medical industry, described the problems he is having moving data from a RESTful device directly into his Siemens PLC I/O table. He was frustrated by configuration issues, diagnostics and insufficient response time.
He is limited by the devices required for this application. The required I/O devices are RESTful and cannot be changed. His task is to move and process I/O data from these devices in the PLC.
Why Shouldn’t PLCs be Used in RESTful Applications?
PLCs are optimized to scan I/O and solve logic at fixed rates. Every other task is secondary. One of the engineer’s frustrations is the PLC’s response time. He tested response time by using a PC and Python application to communicate with the RESTful device. Over 1000 reads per second were achieved with the Python application, while only about 4 reads per second were achieved with the PLC.
In this application, the PLC must:
- Perform an HTTP Get to move a long status message from the field device
- Parse that message
- Act upon the data received. (Note: hardwired digital I/O is used for critical data interlocking.)
Three Reasons PLCs are Poor RESTful Clients
While a PLC can do all three tasks, it is only good at one: acting on the data it receives. Here’s why a PLC struggles to be a reliable RESTful client:
- Issuing HTTP Commands: Performing an HTTP Get reliably and consistently, to move a large number of bytes from a field device is not a task to assign to a PLC. It’s I/O scanning and logic functions will always supersede that data transfer. It may work within the desired time frame part of the time, but it can’t be counted on for reliable communication.
- Parsing ASCII Strings: A PLC is also not a good device for parsing messages. While PLCs have data manipulation functionality, ladder logic is a poor choice for extracting and converting data in a long ASCII message.
- Cybersecurity Risks: Never expose a programmable controller to unknown HTTP endpoints. This greatly expands the attack surface of the system and violates several standard cybersecurity practices.
Why Gateways Are a Better Choice for Moving Data from a RESTful Device Into a PLC
A gateway device is a much better choice for consistent and reliable operation. A gateway can:
- Issue the HTTP GET
- Parse and convert data fields buried in the ASCII message, converting the data to other data formats more easily processed by PLC logic.
- Write those data fields into the PLC’s data table.
How to Decide When to Use a Gateway or Direct PLC Communication
The table below provides a guide for using direct PLC-RESTful communication vs. a Gateway.
| Application Requirement | Recommended Solution | Why? |
|---|---|---|
| Consistent response time (bounded latency), not “usually fast” | Gateway | HTTP timing jitter plus PLC scan scheduling makes timing inconsistent |
| Continuous polling (More than occasional reads) | Gateway | PLCs are not optimized for sustained message transfer and will steal time from control |
| “Long” REST Payload (status blobs, JSON objects, nested fields) | Gateway | Parsing and string handling in PLC code is slow, brittle, and hard to diagnose |
| Tight PLC scan time (variable under load) | Gateway | Any comms task that blocks or spikes CPU will destabilize control timing |
| Safety or hard interlocks | Hardwired I/O or safety-rated network | REST is non-deterministic and not a safety channel |
| High update rate (fast polling) from the REST device | Gateway or industrial PC/edge device | PLC-based HTTP will bottleneck and become the limiting factor |
| Diagnostics such as timeouts, retries, HTTP codes, payload validation, logging, etc. | Gateway | Gateways and edge devices are built for comms visibility and troubleshooting |
| Cross-subnet/security zone access | Gateway (and segment properly) | Minimizes PLC exposure, reduces attack surface, supports firewall/routing patterns |
| Data transformation/normalization (strings to numbers, scaling, enums, bitfields) | Gateway | Keeps transformation out of PLC logic and reduces future maintenance burden |
| Infrequent reads (e.g., once per minute) and the data is non-critical | Direct PLC REST can be acceptable | Low duty cycle reduces timing risk and complexity |
| You need event-driven updates (push) rather than polling | Gateway / Edge Device | PLCs are poor at handling webhooks, sessions, TLS, and async messaging |
| Anticipate future expansion (more REST devices, more tags, more message types) | Gateway | Scaling REST integration inside PLC code becomes a long-term technical debt trap |
| Single, infrequent transactions | Direct PLC REST can be acceptable | Little risk in this application |
The Best Architecture for PLC RESTful Integration
In this scenario, the engineer is using a PLC incorrectly in his application. A PLC is seldom the best choice for applications that must move and parse data. More often, a better choice is to use a gateway device to request the data, parse it, format it properly and write it to the PLC’s data table where it can be processed by PLC logic.
RTA industrial gateways allow you to write clean data directly to a PLC’s data table where it can be processed by logic. This keeps your controller secure, responsive and focused on deterministic control.
PLC RESTful Integration FAQS
Yes, many modern PLCs support HTTP client functions. The issue is not capability, it is architecture. PLCs prioritize deterministic I/O scanning and control logic. RESTful communication is non-deterministic and message-based. When the PLC is busy, communications timing becomes inconsistent. That is a design conflict, not a configuration issue.
Only in low-speed, non-critical applications where timing and throughput do not matter. For example, occasional status updates or configuration reads. If the application requires frequent polling, large message parsing, or consistent response time, a PLC is the wrong tool.
PLC programming environments are optimized for Boolean logic and structured control, not string manipulation. Extracting fields from long ASCII or JSON messages requires significant ladder logic or structured text code. This increases development time, reduces readability, and makes troubleshooting harder.
A properly selected gateway will:
- Handle high-speed HTTP polling reliably
- Parse and normalize complex messages
- Convert data into PLC-friendly formats
- Isolate communications from control logic
- Improve diagnostics and troubleshooting
This keeps the PLC focused on what it does best: deterministic control and logic execution.
