The short answer
SCADA Communications
SCADA communications carry values from the controllers to the servers and commands back, by polling on a schedule or by devices reporting changes as they happen. The protocol is chosen for the job: Modbus for simple devices, DNP3 for telemetry with events and timestamps, EtherNet/IP and vendor protocols for plant controllers, OPC UA and MQTT for server-to-server and cloud paths. The medium ranges from plant Ethernet and fiber to licensed and unlicensed radio, cellular, and leased circuits, each with its own bandwidth, latency, and reliability that set the poll rate. Every link has a timeout and retry policy that turns a lost response into a communication alarm and marks the data bad rather than stale, time is synchronized across the link, remote sites buffer data while the link is down, and each path is secured according to what it crosses.
Key points
- Polling asks; report by exception tells. Slow links want exceptions with timestamps, which is what DNP3 was built for.
- Match the protocol to the job: Modbus for devices, DNP3 for telemetry, vendor protocols in the plant, OPC UA and MQTT between servers.
- The medium sets the poll rate: the arithmetic of bytes per poll, devices, and bandwidth decides what is possible.
- Timeouts and retries convert a silent device into a communication alarm and bad-quality data; stale data that looks good is the failure to avoid.
- Remote sites keep their own history while the link is down and backfill it when the link returns.
- Every path that leaves the building is encrypted or private; Modbus and plain DNP3 carry nothing of their own.
Polling and report by exception
In a polled system the server asks each device for its data on a schedule, and the device answers. The load on the link is the same whether anything changed or not, the latency of a change is up to one poll interval, and the poll interval is set by how many devices share the link and how fast it is. In a report by exception system the device sends a message when a value changes by more than a deadband or a state changes, with a timestamp, and the server polls only occasionally to confirm the device is alive and to fetch anything it missed. The link carries only changes, latency is the transmission time, and events arrive with the time they happened. Plant networks with plenty of bandwidth poll; radio and cellular telemetry benefits from exceptions, and DNP3 is the protocol that does it well.
Protocols
| Protocol | Where it fits | Strengths | Limits |
|---|---|---|---|
| Modbus RTU and TCP | Drives, meters, analyzers, small controllers | Universal, simple, cheap to implement | No timestamps, no events, no security; polled only |
| DNP3 | Telemetry to remote sites over radio and cellular | Events with timestamps, unsolicited reporting, time sync, buffering, secure authentication option | More to configure; not native on every controller |
| EtherNet/IP, and other vendor protocols | Plant controllers of that vendor | Native tags, high performance on Ethernet | Vendor-specific; bandwidth hungry on slow links |
| OPC UA | Server to server, controller to server on modern equipment | Standard data model, built-in security, subscriptions | Newer; not on legacy devices |
| MQTT with Sparkplug | Publish and subscribe to a broker; cloud and enterprise paths | Efficient on poor links, report by exception by design, one-to-many | Needs a broker; the control path is indirect |
| OPC DA and legacy drivers | Older systems | Everything supported something | Windows dependencies, difficult security, being retired |
Media
| Medium | Typical use | Character |
|---|---|---|
| Plant Ethernet and fiber | Inside the plant and between buildings | Fast, reliable, cheap per bit; the polling rate is limited by the devices, not the link |
| Licensed radio | Remote sites within line of sight, tens of miles | Reliable, low latency, low throughput, owned by the utility, licensed frequency protects it |
| Unlicensed spread spectrum radio | Remote sites, shorter range | Cheaper, higher throughput, shared spectrum and interference risk |
| Cellular | Remote sites anywhere with coverage | Good throughput, variable latency, monthly cost, carrier dependency, needs encryption |
| Leased line and private carrier circuits | Legacy telemetry and critical links | Reliable, expensive, disappearing as carriers retire copper |
| Satellite | Sites with nothing else | High latency, cost, weather; last resort |
The arithmetic of a poll cycle
On a shared serial or radio channel the server polls one device at a time, and the cycle time is the sum of every poll. Each poll takes the time to send the request, the time for the device to respond, and the time for the response to come back, plus the turnaround overhead of the radio.
T_cycle ≈ N × (T_request + T_turnaround + T_response + T_retry × P_fail)
- N = devices on the channel
- T_request, T_response = bytes divided by the channel data rate, including protocol overhead
- T_turnaround = radio keying and settling time, often tens to hundreds of milliseconds
- T_retry × P_fail = the average time lost to retries at the failure rate of the link
Twenty sites on a 9,600 bit per second radio channel with 200 bytes per exchange and 100 milliseconds of turnaround gives a cycle near ten seconds with no retries, and longer as retries appear. That is the update rate every site gets, and doubling the site count doubles it. Report by exception, a faster channel, or a second channel are the ways out. On Ethernet the same arithmetic applies to each device rather than the channel: a controller that takes 50 milliseconds to answer a request cannot be polled every 20 milliseconds, no matter how fast the network is.
Timeouts, retries, and quality
When a device does not answer, the server waits for the timeout, tries again up to the retry count, and then declares the device offline, raises a communication alarm, and marks the data from that device with bad quality. The timeout is longer than the slowest normal response, including radio turnaround, and shorter than the poll interval; the retries are few. What must not happen is the server continuing to show the last value as if it were current: stale data with good quality has started pumps against empty wells. Every display shows communication status, every control loop that uses a remote value checks its quality, and the communication alarm is a real alarm with a priority.
Time and store and forward
Events from remote sites are useful only if their timestamps agree with everyone else. DNP3 and OPC UA carry time synchronization from the server to the device; plant controllers on Ethernet use network time. A remote controller with a buffer keeps events and history samples while the link is down and delivers them when it returns, with their original timestamps, so that the historian shows what happened during the outage rather than a gap. That buffering is configured at the controller and at the server, and it is tested by disconnecting the radio for an hour and checking the trend afterward.
Security by path
- Inside the plant: the control network is segmented and the polling crosses a firewall with rules for the specific devices, ports, and direction.
- Radio: licensed radio is private but not secret; modern radios encrypt, and the configuration turns it on. Unlicensed radio is encrypted without exception.
- Cellular: a private network or VPN tunnel from each modem to the utility, never a public address on a modem, and never a controller reachable from the internet.
- Server to server and cloud: OPC UA with certificates, MQTT with TLS and authentication, through a DMZ.
- Modbus and DNP3 without secure authentication carry no protection of their own; the path around them provides it.
Diagnostics
The server keeps statistics per device and per channel: polls sent, responses received, timeouts, retries, average and maximum response time, and the time of the last good response. Those numbers are historized and alarmed like process data: a site whose success rate has fallen from 99 to 90 percent is a radio path or an antenna problem that will become an outage, and a response time creeping up on an Ethernet device is a controller that is overloaded or a switch that is dropping. The communication diagnostic display, showing every site with its status and its statistics, is the first display opened when anything remote misbehaves.
Frequently asked questions
- Modbus or DNP3 for a lift station over radio?
- DNP3 if the controller supports it well: it reports changes with timestamps, buffers while the radio is down, and synchronizes time. Modbus works and is simpler, and it is what many small controllers offer; with Modbus the poll interval sets the latency and there is no history during an outage unless the controller keeps its own.
- How fast should remote sites be polled?
- As fast as the channel allows after the arithmetic, and as slow as the process permits. A lift station that changes over minutes is fine at a 30-second update; a pressure zone with surge concerns wants seconds. Poll critical values faster than the rest, use exceptions where the protocol supports them, and never let the poll cycle exceed the time in which a lost site becomes a problem.
- The site shows good data but the values never change. Is the link working?
- Probably not. The server is displaying the last received values without marking them stale, which is a configuration failure at the server or the driver. Check the communication statistics for that site; the time of last good response will tell you. Then fix the quality handling so that the display goes bad when the link does.
- Can cellular be the primary path for telemetry?
- Yes, and increasingly it is, with private carrier networks or VPNs, static private addressing, and modems the utility manages. The risks are coverage, carrier outages, and monthly cost, and the mitigations are a second path for critical sites and local control that does not need the link.
Related topics
- DNP3The protocol built for utility telemetry: master and outstation, static and event data classes, unsolicited reporting, time-stamped events, and why it suits slow links that Modbus does not.
- Modbus TCPModbus over Ethernet: what the MBAP header changes, why the CRC disappears, how the unit identifier works, and what does not get easier just because it is on Ethernet.
- OPC UAWhat OPC UA is for, how its information model, security, and transports differ from OPC Classic, where it belongs in a plant, and what to check before relying on it.
- SCADA ArchitectureThe parts of a SCADA system and how data moves between them: I/O servers, the tag database, clients, the historian, the alarm server, and the topologies from a single panel PC to a redundant, distributed plant.
- Device Times OutA polled device that answers late or not at all: how to read the driver counters, tell a dead device from a slow one, and find the timeout setting, the bus loading, the radio latency, the duplicate address, or the device that is simply too busy to answer.
- How to Diagnose a Bad Quality TagTrace a bad quality indication from the SCADA screen back to its source: the tag configuration, the driver and device connection, the controller tag, and the field signal, using the diagnostics each layer provides, and separate a stale value from a bad one.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.