A SCADA system spread across a pipeline or an oilfield does not look like a plant network. Instead of switches in one building, it is a central control room reaching out to dozens or hundreds of remote sites scattered over miles of country, each connected by whatever communications the location allows. The most common shape for that wide-area system is hub-and-spoke, where one central host sits at the middle and every remote site is a spoke radiating out to it. This page explains what a hub-and-spoke SCADA topology is, how it differs from the star wiring inside a plant, and the bandwidth and single-hub failure realities that shape it for pipelines and well pads.
Hub-and-spoke in one line: A hub-and-spoke topology is a wide-area SCADA arrangement in which a single central host, the hub, communicates individually with many geographically dispersed remote sites, the spokes, typically by polling each one in turn over radio, cellular, satellite, or VPN links. The remote sites do not talk to each other; all traffic flows in and out through the central hub. It is the standard shape for pipelines, well pads, and other distributed operations because it lets one control room gather data from and issue commands to a large number of unmanned sites, at the cost of concentrating bandwidth and failure risk at the hub.
In a hub-and-spoke SCADA system, the hub is the central master, usually the SCADA host or a communications front-end in the control room, and each spoke is a remote site with its own RTU or PLC gathering local measurements and running local control. The defining feature is that the communication paths all radiate from the hub to the individual spokes and nowhere else. A well pad talks to the control room; it does not talk to the well pad next door. If two remote sites ever need to exchange data, that exchange goes up to the hub and back down, because there is no direct spoke-to-spoke path.
The hub usually reaches its spokes by polling, meaning it works through its list of remote sites asking each one in turn for its current data and then moving on to the next. Each spoke answers only when asked, which keeps the shared communications medium orderly and lets a single hub coordinate many remotes without them talking over each other. The links themselves are whatever the geography and budget allow: licensed or unlicensed radio for line-of-sight sites, cellular where there is coverage, satellite for the truly remote, and VPN tunnels over any of those to carry the traffic securely back to a central host that may itself live in a data center or the cloud.
This shape maps naturally onto how distributed field operations are actually laid out. A pipeline is a long chain of block valves, pump or compressor stations, and metering points, all of which need to report to one operations center, and an oilfield is a scatter of well pads and tank batteries doing the same. In both cases there is a clear center that owns the operation and a large number of outlying sites that each need a path back to that center, which is exactly the pattern hub-and-spoke describes. It is the topology of central supervision over dispersed, unmanned assets.
Hub-and-spoke is often drawn the same way as a star topology, with lines fanning out from a center, and the two are related, but the context and constraints are quite different. A plant-floor star is a local-area arrangement where devices in one building connect back to a central switch over short, fast, reliable Ethernet cabling, with bandwidth measured in hundreds or thousands of megabits and latency in fractions of a millisecond. Everything is close, the links are cheap and plentiful, and a failed cable affects one device. The star inside a plant is a wiring convenience.
A hub-and-spoke SCADA system is a wide-area arrangement where the spokes are miles away and the links are slow, sometimes intermittent, and often metered or costly. A cellular or radio spoke might offer only a modest data rate, may drop out with weather or terrain, and may charge by the byte, so the traffic across it has to be rationed rather than lavished. Latency is far higher and more variable than on a plant floor, and a lost link means an entire remote site goes dark, not just one device. The engineering therefore centers on making the most of scarce, unreliable long-distance communications rather than on convenient local cabling.
That difference drives the whole design philosophy of the two. On a plant star you can afford chatty protocols and frequent updates because bandwidth is effectively free; on a hub-and-spoke WAN you design the polling cycle carefully, send only what changed where the protocol allows it, and push intelligence out to the RTU so the remote site can keep running and logging locally even when the link to the hub is down. The remote is expected to be autonomous between polls, storing its data and continuing its control, precisely because the link back to the hub cannot be assumed to be always present or fast, which is never a concern inside a plant.
The first thing that constrains a hub-and-spoke system is the polling budget. Because one hub is working sequentially through many spokes over slow links, the total time to poll every site once, the scan cycle, grows with the number of sites and shrinks with the speed of each link. Add too many spokes or make the data requests too large and the hub cannot get all the way around its list fast enough, so the freshest data from a given site becomes stale by the time the hub returns to it. Designers manage this by trimming what each poll asks for, prioritizing critical points, using report-by-exception where the protocol supports it, and sometimes splitting the load across multiple communications channels so several spokes are being polled at once.
The second and more serious concern is that the hub is a single point of failure for the whole operation. Every spoke depends on the hub to be seen and controlled, so if the central host, the communications front-end, or the hub site's connectivity goes down, the control room loses visibility of every remote at once even though the field equipment itself is fine. This is why serious hub-and-spoke deployments harden the center with redundant SCADA servers, redundant communications paths into the hub, and backup power, and why the autonomy built into each RTU matters so much: a well-designed spoke keeps running its local control and logging its data through a hub outage, so nothing is lost and operations resume the moment the hub comes back.
Moving the hub to a cloud SCADA platform such as Merobix reshapes both of these concerns. Rather than every spoke polling back to one physical server in one control room, remote sites can report into a cloud service that is itself built for redundancy across multiple locations, which removes the single fragile hub building and its single power feed as the operation's weak point. The cloud also changes the bandwidth picture, because sites can push data on change or on a schedule to a service that scales rather than being polled one at a time by a fixed host, and the same central view is then reachable from anywhere without depending on one control-room workstation. The hub-and-spoke logic remains, one center supervising many dispersed sites, but the center becomes a resilient service instead of a single machine that the whole field hangs on.
By definition of the topology, no, not directly. All communication flows through the central hub, so if one remote site needs data from another, that data travels up to the hub and back down to the requesting site. This keeps the design simple and the field devices unaware of each other, but it also means any spoke-to-spoke interaction depends entirely on the hub being available. Where genuine site-to-site communication is needed, such as one pump station reacting to another, it is usually implemented through logic at the hub rather than by direct links between the remotes.
Polling gives the central hub orderly control over a shared communications medium so that many remote sites do not transmit at the same time and collide, which matters most on radio networks where all the spokes share one channel. It also lets the hub decide what to ask for and when. That said, many modern systems combine polling with report-by-exception, where a remote can flag an urgent change between polls, and cloud-connected sites often push data on change rather than waiting to be asked, which reduces traffic and improves how fresh the critical data is.
The control room loses visibility and remote control of every site at once, because every spoke depends on the hub to be reached, even though the field equipment itself keeps operating. A well-designed system limits the damage by making each remote RTU autonomous, so it continues its local control and logs its data through the outage and nothing is lost. Serious deployments also reduce the chance of a total hub failure with redundant central servers, redundant communications into the hub, and backup power, and moving the hub to a redundant cloud service removes the single-building weakness entirely.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.