SCADA does not “read the PLC.” It reads specific memory locations inside the PLC, over a network, using a protocol both sides agree on, on a schedule the SCADA engine controls. Every screen value, every alarm, every trend point comes from that one loop: ask, answer, map, display.
Most explanations stop at a list of protocol names. That list does not help you when a value reads 10x too high or a tag goes stale at 3 a.m. So let’s follow one number all the way from the field to the screen, then look at what breaks along the way.
Table of Contents
One value, end to end
A pressure transmitter sends 4-20 mA into an analog input card. The card converts it to a raw count, usually 0-27648 or 0-32767 depending on the vendor. The PLC program scales that count into engineering units and writes the result into a memory location. On a Modbus device the value might sit in two consecutive holding registers as a 32-bit float, protocol addresses 0 and 1, usually documented as 40001 and 40002.
Now the PLC has done its job. It has no idea SCADA exists.
The SCADA server holds a tag list. One of those tags is configured as: this device, this protocol, this register address, this data type, this poll group. Every second, the SCADA communication driver sends a read request. The PLC answers with four bytes. The driver turns those bytes into 25.7, stamps it with a timestamp and a quality flag, and hands it to the display, the alarm engine, and the historian.
That is the whole mechanism. Everything else is detail about how each step can go wrong.
Four things that have to line up
Two devices only exchange data when all four of these match. Miss one and you get nothing, or worse, you get wrong numbers.
A physical path. Ethernet through a switch, or RS-485 multidrop, or a radio link. Both ends on the same network, or routed with the firewall rules to prove it.
A shared protocol. Modbus TCP, EtherNet/IP, PROFINET, S7 communication, DNP3, IEC 60870-5-104, OPC UA. The SCADA side loads a driver for it. The PLC has to support that protocol and have the communication service or interface enabled, which is not always on by default.
A device address. An IP address for Ethernet protocols, plus a unit ID or slave address for Modbus, plus rack and slot for Siemens S7 connections. On Modbus RTU the slave address is normally 1 to 247. Other serial protocols use their own link address ranges.
A memory address. The exact register, data block, or tag name inside the PLC. This is where most integration time actually goes.
Who asks, who answers
Most SCADA-to-PLC traffic is client/server. SCADA is the client, or master, or originator, depending on which protocol’s vocabulary you are using. The PLC is the server, or slave, or controlled station. It sits there and answers.
The SCADA polling engine works through a list. Poll group 1 every 500 ms, poll group 2 every 5 seconds, poll group 3 on demand. Each poll is a request frame out and a response frame back. The driver batches nearby registers into one request because 100 separate reads cost far more than one block read of 100 registers.
This is why address layout in the PLC matters. Scattered registers mean many small requests. Contiguous blocks mean few large ones. On a slow link that difference decides whether your screen updates in one second or eight.
Poll rate is not scan cycle
This trips up a lot of people, including experienced ones.
The PLC scans its program maybe every 10 ms. SCADA polls maybe every 1000 ms. You see one out of every hundred states. Anything shorter than your poll interval is invisible.
A motor that trips and auto-resets in 200 ms never appears on the SCADA screen. The value was there, in the register, and it was gone before the next poll. Polling faster is not the answer, because you hit the link limit long before you hit the scan rate.
The fix lives in the PLC. Latch short events into a bit that stays set until SCADA acknowledges it. Or buffer events with PLC-generated timestamps and let SCADA collect them. For sequence-of-events work, a 1-second poll cannot resolve anything, and you need the timestamp made where the event happened, not where it was read.
When the PLC talks first
Not everything is polled. Several protocols let the field device report on its own.
DNP3 has unsolicited responses. The outstation pushes changes to the master instead of waiting. IEC 60870-5-104 does the same with spontaneous transmission. Whether the data carries a time tag is a separate matter, decided by the type identification you configure. MQTT with Sparkplug B inverts the model completely: the device publishes on change to a broker, and SCADA subscribes. IEC 61850 uses buffered and unbuffered reports, plus GOOSE for the fast stuff between IEDs.
Report by exception saves bandwidth and catches short events. The trade-off is that silence becomes ambiguous. Nothing reported could mean nothing changed, or it could mean the link died. That is why these protocols carry keep-alives, integrity polls, and test frames. If you use report by exception, configure the integrity poll. Without it you will eventually trust a screen that stopped updating an hour ago.
The mapping, in detail
Here is the part that generates most support calls. Take that 25.7 value again, as a 32-bit IEEE 754 float.
25.7 encodes as 0x41CD999A. Modbus registers are 16 bits, so the float takes two of them.
| Word order | Register n | Register n+1 | SCADA reads |
|---|---|---|---|
| Big-endian (high word first) | 0x41CD | 0x999A | 25.7 |
| Word-swapped (low word first) | 0x999A | 0x41CD | about -1.6e-23, not a pressure |
Same bytes on the wire. Same registers. One configuration setting in the driver, and the value is either right or meaningless. Modbus defines a 16-bit register and the byte order inside it, but it says nothing about how a 32-bit value spans two registers. Vendors handle that differently. Check the device documentation and the driver’s byte and word order setting before you start suspecting the PLC program.
Three more mapping traps:
The 40001 offset. Documentation says holding register 40001. Function code 03 asks for address 0. Some drivers expect the 4xxxx notation, some expect the raw offset. Off by one, and you read the neighbour.
Scaling done twice. The PLC scales raw counts to 25.7. Then someone adds a 0.1 multiplier in the SCADA tag “to be safe.” Now the screen shows 2.57. If the number is exactly 10x, 100x, or 0.1x, look for a second scaling factor before anything else.
Signed versus unsigned. A 16-bit value of 65530 read as signed reads -6. Common on flow totalisers and anything that can go slightly negative.
Driver, OPC server, or gateway
Three ways to get the protocol into SCADA.
Native driver. The SCADA package includes the protocol. Fewest moving parts, lowest latency, one less thing to license and patch. Use it when it exists.
OPC UA. SCADA is the OPC UA client, the PLC or a server application is the OPC UA server. You get a browsable information model instead of raw register numbers. The security model supports application certificates, message signing, and encryption, but only when the endpoint uses a security policy that turns them on. An endpoint set to None is not secure. Newer PLCs run a UA server on the CPU. The cost is more configuration and more CPU load on the controller. Legacy OPC DA still exists on Windows via COM/DCOM, and it is a firewall nightmare.
Protocol gateway. A converter box speaks PROFIBUS or a proprietary serial protocol on one side and Modbus TCP or EtherNet/IP on the other. This is how old equipment survives a SCADA upgrade. It also adds a device that can fail, a second mapping table to maintain, and extra latency.
Quality flags are half the data
Every value SCADA stores has a quality attached. Good, bad, uncertain, plus substatus.
A driver that cannot reach a PLC does not have a value to show. What it does next is a configuration decision. It can hold the last known value, or mark the tag bad, or force it to a default. Holding the last value on the screen with no visual indication is dangerous, because the operator sees a pressure reading that has not been real for twenty minutes.
Set your displays to show bad quality clearly. Dashes, a colour change, a hatch pattern. Handle process alarms on bad quality, otherwise one dropped link floods the list with process alarms that mean nothing. Keep the communication alarm itself active, so the operator knows the source is gone instead of reading a screen that has quietly stopped.
Serial has not gone away
Plenty of installed base still runs Modbus RTU over RS-485. One master, multiple slaves on the same pair, half duplex.
Bandwidth is the constraint. At 9600 baud with standard 8N1 framing, each character costs 10 bits, so about 960 characters per second. Subtract frame overhead, turnaround delay, and the 3.5-character silent interval between frames, and the usable figure is lower. Thirty slaves, each with a 40-register read, will not complete in one second. Do the arithmetic before promising an update rate.
Also check the physical layer before blaming the protocol. Termination resistors at both ends only, biasing on the master, and correct A/B polarity. Intermittent CRC errors usually come from the physical layer: termination, biasing, grounding, shield handling, polarity, or noise. Rule those out before you suspect the software.
What actually breaks
In rough order of how often you will see it:
- Wrong unit ID or slave address, with correct IP. The device answers or ignores you depending on the gateway.
- Word order wrong on 32-bit values.
- Register offset off by one.
- Communication service not enabled on the PLC, or the PLC restricting connections to a fixed number of clients that are already used up.
- Firewall blocking the port the protocol normally uses. 502 for Modbus TCP, 102 for S7, 44818 for EtherNet/IP explicit messaging, 4840 for OPC UA, 20000 for DNP3, 2404 for IEC 104. These are defaults and can be changed, so confirm what the device is actually set to.
- Poll rate too fast for the link, so requests queue and timestamps drift.
- Duplicate IP address after a spare CPU was swapped in.
- Scaling applied in two places.
Work in that order and you will solve most of them before opening a packet capture.
FAQ
Does the PLC need to be programmed for SCADA to read it?
For the data itself, usually no. Modbus and similar protocols expose memory directly, so if the value is in a register, SCADA can read it. You do need the communication service enabled, and you often need to program latching or event buffering for anything faster than the poll rate.
Can SCADA write to a PLC, or only read?
Both. Writes are how operators start pumps and change setpoints. The safety logic stays in the PLC, never in SCADA. Treat every write path as something that must be interlocked at the controller, because a SCADA write can arrive at any moment, including from a session someone forgot to close.
What is the best protocol for SCADA to PLC communication?
The one both devices already support well. Modbus TCP for simple register reads, EtherNet/IP or PROFINET when the PLC vendor is fixed, OPC UA when you want security and browsable data, DNP3 or IEC 60870-5-104 for wide-area utility links with time-stamped events.
How fast can SCADA poll a PLC?
Ethernet links commonly run 100 ms to 1 second per group. Faster is possible but rarely useful, because the operator cannot read a screen updating ten times a second and the historian just stores more of the same. Serial links are much slower and limited by baud rate and device count.
Why does a value show on the PLC but not on SCADA?
Almost always addressing or data type. Confirm the register the PLC writes to, confirm the address the driver requests, then confirm the data type and word order. Use a standalone Modbus or OPC client to read the value outside SCADA. That single test tells you which side of the driver the problem is on.