Have you ever noticed that data from the PLC to SCADA arrives late, or even disappears? A familiar picture: everything runs smoothly on the bench, but at the site you get timeouts or incorrect values. The cause is often not the hardware, but how the protocol gateway and register polling are configured. In this article, we'll examine why industrial IoT is not just "connecting a sensor to a server," and show with an example exactly where the chain breaks.
Why IIoT is not a "smart home" on steroids
In consumer IoT, you can afford to lose a packet — the temperature on the sensor will update in a minute, and no one will notice. In industry, every polling cycle has a cost. If the operator doesn't see in time that the pressure in the reactor has exceeded the threshold, the consequences can be catastrophic. That's why the requirements for reliability, determinism, and security are different here.
The key difference is the presence of a protocol gateway. This is not just a "Modbus to OPC UA" converter. It is a device or program that polls dozens of devices over serial lines (Modbus RTU) or over the network (Modbus TCP), converts data types, buffers values, and delivers them to a higher-level system (SCADA, MES, cloud) via OPC UA or MQTT. Whether you see an alarm in a second or in a minute depends on how this gateway is configured. For a deeper dive into this topic, see Serverless Architecture.
Task breakdown: how a practitioner configures PLC polling via Modbus RTU and OPC UA
Imagine: there is a pump station controlled by a PLC with a Modbus RTU interface (RS-485). You need to transmit three parameters to SCADA: pressure (register 40001, float type), temperature (40003, int16), and pump status (40005, coil). The distance to the gateway is 50 meters of twisted pair. The task is to ensure a polling cycle of no more than 1 second and not lose data during short-term interference.
Step 1. Choosing speed and timeouts. Speed 9600 bps, 8N1. One read request for two float registers (4 bytes) takes about 10-12 ms including delays. When polling 10 devices on the line, the total time approaches 150 ms. If you set a timeout of 100 ms, then at the slightest interference the gateway will repeatedly interrupt polling and data will become patchy. A practitioner sets a timeout of 300 ms and retry 2. This increases the response time in case of failure, but it doesn't lose packets.
Step 2. Addressing and type conversion. In Modbus, register addressing starts at 0, but documentation often specifies 40001. This creates confusion: if you specify address 40001 instead of 0 in the gateway, it will read the wrong register. In addition, float in Modbus is transmitted by two registers, and the word order (big-endian vs little-endian) depends on the PLC manufacturer. An error in the order — and you get pressure 0.0 instead of 6.2 bar. Always check on the emulator.
Step 3. Gateway configuration. The protocol gateway (for example, based on an industrial computer with software) must be configured to group requests: read all registers of one device in one block, not one by one. This reduces the load on the line. It is also important to enable buffering: when communication is lost, the gateway must store the last values with a timestamp, not return zeros.
What will go wrong if you skip these steps? At a site with poor interference conditions, you will get "chatter": data appears and disappears. The operator will stop trusting the system. And with the wrong byte order of float, you may not even notice the error until an accident occurs due to incorrect readings.
Where the mechanism breaks: failure modes
Even a properly configured system can fail. Here are three scenarios that occur most often.
1. Modbus line overload
Modbus RTU has no built-in arbitration. If two masters on the same line (for example, a gateway and a programmer) start polling simultaneously, collisions will occur. Symptom: periodic timeouts that disappear if one of the masters is disconnected. The solution is strictly one master per line.
2. Modbus security
Modbus TCP has no authentication or encryption. Anyone who gains access to the network can write to registers. This is not a theoretical vulnerability: in the 2020s, attacks on industrial networks through unprotected Modbus have become more frequent. A protocol gateway can partially solve the problem if you configure an address whitelist and write command filtering. But you cannot rely entirely on Modbus in an open network — you need OPC UA with security policies.
3. Lack of tagging and diagnostics
Many custom converters do not provide information about data quality. If a register cannot be read, they simply return the last known value or zero. OPC UA has built-in status mechanisms (Good, Bad, Uncertain) and diagnostic events. Without them, you won't know that a sensor has failed until it's too late.
Gateway or custom converter: counting the money
An industrial protocol gateway costs from $500 to $2,000 depending on the number of ports and supported protocols. A custom converter in Python or C++ can be free if you have a programmer. But don't forget about support costs: when the PLC configuration changes or a device is added, you will have to rewrite the code. A ready-made gateway is configured via a web interface in minutes.
| Criterion | Industrial gateway | Custom converter |
|---|---|---|
| Initial costs | $500–2,000 | $0 (if you have a developer) |
| Setup time | 1–2 days | 2–4 weeks |
| Protocol support | Modbus, OPC UA, MQTT, etc. | Only what was programmed |
| Diagnostics | Built-in | Must be written separately |
| Flexibility | Limited by gateway capabilities | Maximum |
Conclusion: if you have typical tasks and limited time — take a gateway. If you need non-standard logic (for example, complex data aggregation on the fly) — a custom converter may be justified, but budget for support.
When a gateway is not enough: moving to an OPC UA server
A protocol gateway is good for converting "Modbus → OPC UA". But if you have dozens of devices, multiple protocols, and require a unified address model with hierarchy, you need a full-fledged OPC UA server. It allows you to create a namespace, group tags by objects, configure access rights and subscriptions. This is no longer just a converter, but a data collection center.
Moving to an OPC UA server is justified when:
- the number of tags exceeds several thousand;
- integration with MES/ERP via standard interfaces is required;
- security is important (authentication, encryption);
- history and aggregation on the server side are needed.
Keep in mind that an OPC UA server is an additional layer that can become a bottleneck if polling is not designed correctly. For example, if the server polls each device sequentially with a 1-second timeout, with 100 devices the polling cycle will be 100 seconds. You need to use parallel subscriptions or asynchronous polling.
Learning paths: self-study, courses, practice
Self-study of IIoT and SCADA means reading documentation, articles, and videos. The plus is that it's free and at a convenient pace. The minus is that there is no feedback, it's difficult to verify your solutions, and many subtleties (for example, setting timeouts or byte order) go unnoticed until you encounter them at a real site.
Practice in real production is the best teacher, but you still need to get there. Often beginners are not allowed near operating equipment, and training drags on. For a deeper dive into this topic, see BI Analytics and Dashboards.
Courses provide a structured path and the opportunity to practice skills on PLC emulators and SCADA servers. For example, in the course "Industrial IoT (IIoT) and SCADA Systems" they cover exactly such scenarios: configuring a protocol gateway, type conversion, error diagnostics. This allows you to gain experience before going to the site.
Who this suits and who it doesn't
The path into IIoT will be comfortable if you:
- have basic knowledge in electrical engineering or automation;
- are familiar with programming (at least at the script level);
- are ready to understand protocols and documentation;
- want to solve practical problems, not just theory.
It's better not to start if you expect only "smart homes" and are not ready for industrial standards, or if you need quick results without delving into details.
In conclusion
Industrial IoT and SCADA is an area where the devil is in the details: in timeouts, byte order, gateway settings. Mistakes here are costly. If you want to master this profession from scratch or systematize your knowledge, check out the course Industrial IoT (IIoT) and SCADA Systems. There you will find analysis of real cases and receive feedback on your solutions.