Redundant SCADA is usually described in terms of two servers, one live and one standby, ready to swap if the primary dies. Redundant polling is the same idea aimed specifically at the scanning layer, where the question is not just which server is in charge of the screens but which engine is actually talking to the field devices. Two poll engines stand ready to scan the RTUs, but at any moment only one should own each device, because two masters hammering the same RTU at once causes as many problems as no master at all. The interesting engineering is in how they decide who polls, and how that decision moves cleanly when one of them fails.
Redundant Polling in one line: Redundant polling is an arrangement where two SCADA masters or poll engines are both capable of scanning the field devices, but ownership of each device is arbitrated so that only one poller actively communicates with it at a time. If the active poller fails, the standby takes over scanning that device without a gap, and the arbitration ensures the two never poll the same RTU simultaneously, which would double the load and corrupt request-response ordering.
The central problem redundant polling solves is that two masters wired to the same field devices must never both poll a device at once. Many field protocols are request-response over a link with limited capacity, and an RTU expects one conversation at a time; if two masters interleave requests, responses get mismatched to the wrong request, the RTU is loaded with twice the traffic it was sized for, and on a shared bus the two masters can collide and corrupt each other's frames. So the whole point of a redundant poller pair is not to poll twice for safety but to poll exactly once, from whichever master currently owns the device.
Ownership is therefore an explicit, arbitrated state rather than an accident of which master happened to speak first. Each device or group of devices has exactly one owning poller at any instant, and the two masters coordinate to agree on who that is. The active owner does all the talking; the standby stays silent on the wire for that device, keeping its configuration warm and ready but not sending a single request. This keeps the field-side traffic identical to a single-master system during normal operation, which is essential because the RTUs and the link were engineered for one master's worth of load, not two.
Because silence on the wire is the standby's normal state, the redundancy is invisible to the field under healthy conditions. The RTUs see one steady stream of polls, the link carries one master's worth of traffic, and nothing about the field-side behavior betrays that a second master is standing by. The redundancy only becomes visible at the moment it is needed, when ownership has to move, and everything up to that moment is spent making sure it can move cleanly. That discipline, one owner per device and a silent standby, is what separates real redundant polling from simply pointing two masters at the same RTUs and hoping.
For ownership to move safely, the two masters need a way to know each other's health and to agree on a transfer, which is the arbitration layer. Each poller watches for signs the other is alive, typically a heartbeat exchanged between them, and watches its own ability to reach the field. When the active poller stops answering its heartbeat or loses its path to the devices, the standby needs to conclude that it should take ownership, and it needs to do so without a race where both masters grab the same device or, worse, where a briefly stalled active master and an impatient standby both claim it at once.
The hazard to design against is split ownership, where a network partition or a slow-but-alive active master leads both engines to believe they own a device and both start polling it, reintroducing the double-poll the whole scheme exists to prevent. Robust arbitration guards against this with mechanisms such as a tie-breaking arbiter or a rule that the standby only assumes ownership when it has positive evidence the active poller has genuinely stopped, not merely gone quiet for a moment. The transfer of ownership has to be atomic in effect: at the instant it completes, the old owner is confirmed silent and the new owner begins, with no overlap in between.
Done well, the handoff is nearly seamless from the field's point of view. The standby has kept the device configuration, the poll schedule, and the last known values warm, so when it takes ownership it can resume scanning immediately rather than rediscovering the site from scratch. The gap in fresh data is only as long as it took to detect the failure and complete the arbitration, and the RTUs simply see the poll stream continue, unaware that a different master is now asking the questions. Continuity of scanning, not just continuity of screens, is the deliverable, which is why redundant polling is a distinct concern from having a redundant server for the user interface.
For a fleet of remote, unmanned sites, an interruption in polling is an interruption in visibility, and visibility is often the only thing standing between a small problem and an expensive one. If the poller goes down and nothing takes over, the sites keep running but nobody is reading them, so a tank quietly climbs toward overflow or a compressor drifts into trouble with no one watching. The value of redundant polling is precisely that the field never goes dark: even when a master fails, some engine is still asking the RTUs how they are doing and still delivering their answers to operators.
A cloud SCADA platform such as Merobix can run the poll engines in a redundant arrangement so that scanning of remote wells, tanks, and stations continues across a failure of any single poller, with ownership of each site arbitrated so the RTUs are never double-polled and never abandoned. Because remote assets often sit behind metered or capacity-limited links, the guarantee that they are polled exactly once, by exactly one owner, protects both the data plan and the RTU from the load a careless dual-master setup would impose. The redundancy buys availability of monitoring without buying extra field-side traffic.
Seamless scan continuity also changes what a maintenance window looks like. Because either master can own the field, the standby can pick up the polling while the active master is patched, rebooted, or upgraded, so routine software maintenance no longer means a blind spot over the whole fleet. The arbitration that handles an unplanned failure handles a planned handoff just as well, letting an operator deliberately move ownership to the standby, work on the primary, and move it back, with the RTUs seeing nothing but a continuous poll stream throughout. For a monitoring operation that is supposed to be always on, that ability to lose or service a poller without losing the field is the whole reason redundant polling exists.
Because most field protocols are request-response and expect one conversation at a time, two masters polling the same RTU interleave requests, mismatch responses to the wrong request, and double the load the RTU and link were sized for. On a shared bus the two masters can also collide and corrupt frames. Redundant polling exists to ensure each device is polled exactly once, by exactly one owning master, not twice.
The two masters exchange a heartbeat and monitor their own path to the field, and the standby only assumes ownership when it has positive evidence the active poller has genuinely stopped rather than merely gone quiet for a moment. Robust arbitration uses a tie-breaker or an atomic transfer so both masters never claim the same device at once. This prevents split ownership, which would reintroduce the double-poll the scheme is meant to prevent.
A redundant server pair is mainly about keeping the screens, alarms, and database available if one server fails. Redundant polling is specifically about the scanning layer: which engine actually communicates with the field devices, how ownership of each device is arbitrated, and how scanning continues without double-polling when the active poller fails. You can have a redundant server and still lose polling if the scan ownership is not handled as its own concern.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.