Underneath the hardware names - MTU, RTU, PLC - SCADA communication is organized around two roles: a master that asks and outstations that answer. This request/response relationship frames everything about how a telemetry system polls, who initiates a conversation, and how many devices one link can serve. This page defines the master and outstation roles as a communication topology, separate from the hardware view of what an MTU or RTU physically is. Understanding the roles is what makes polling, scheduling, and event reporting make sense.
Master / Outstation Architecture in one line: In master/outstation architecture, the master is the central station that initiates communication - it sends requests and issues commands - while outstations are the field devices that respond to those requests with their data and carry out commands. The master drives the conversation on a request/response basis: it asks and the outstations answer, and normally an outstation does not speak until spoken to. This role structure, sometimes called master/slave, is the foundation of virtually all traditional SCADA polling.
The defining feature of the architecture is the asymmetry of initiative. The master is the active party: it decides when to communicate, which device to address, and whether to request data or send a command. An outstation is the responsive party: it listens for a request addressed to it, and only then does it reply with the values asked for or acknowledge a command carried out. In the classic model, an outstation never volunteers information - it waits to be polled, and its role is to answer accurately and promptly when it is.
This request/response discipline is what makes a shared link workable. Because only the master initiates, there is a single authority deciding who talks and when, so many outstations can share one serial line or radio channel without colliding - the master addresses them one at a time and they take turns replying. Remove that single point of initiative and you would have devices trying to transmit whenever they liked, stepping on each other. The master/outstation structure is, at heart, a way to arbitrate a shared medium cleanly.
The roles are about communication, not about intelligence or capability. An outstation can be a sophisticated RTU running its own local control loops, far smarter than the polling engine that queries it, yet in the communication relationship it is still the outstation because it answers rather than initiates. This is why the roles are best understood as a topology of who-asks-whom, layered on top of whatever the devices are as hardware. The same physical RTU is an outstation to its master and could be a master to devices below it.
The master/outstation roles are what all the polling machinery is built on. Poll rate, poll scheduling, round-robin rotation, retries, and timeouts all describe how the master conducts its side of the request/response relationship - how often it asks, in what order, and how it decides an outstation failed to answer. None of those concepts make sense without the underlying architecture: they are all elaborations of a master working through its outstations one request at a time. Understanding the roles first is what makes the rest of SCADA communication legible.
Some protocols relax the pure rule that an outstation never speaks unprompted. Report-by-exception and unsolicited reporting let an outstation initiate a message to tell the master about a significant change without waiting for the next poll. Even here, though, the roles remain - the outstation is reporting to the master, and the master is still the central authority that the outstation reports up to. Unsolicited reporting is a refinement of the relationship for efficiency, not a reversal of it, and the master typically still integrity-polls periodically to keep the picture correct.
The architecture also scales in tiers. A master at the control center polls outstations in the field, but one of those field devices may itself be a master to a sub-network of devices beneath it, aggregating their data and presenting it upward as a single outstation. This layering is how large telemetry systems are built - a hierarchy of master/outstation relationships rather than one flat one - and it is possible precisely because the roles are relative to a link, not absolute properties of a box. A device's role depends on which conversation you are looking at.
In cloud SCADA for oil and gas, the master role moves from a dedicated control-center computer to the platform itself, but the topology is unchanged: the platform is the master that reaches out to field outstations - RTUs, PLCs, flow computers - across cellular, radio, or satellite links, and those devices answer. The physical location of the master shifts to the cloud, yet it still initiates every conversation and still arbitrates access to each shared field link the same way a traditional master station always did.
A platform such as Merobix acts as that master, polling remote outstations, issuing control commands, and, where protocols support it, accepting unsolicited reports of significant changes between polls. Framing the deployment in these role terms is what makes the behavior predictable: an engineer knows the platform drives the schedule, decides the poll order, and detects a non-responding outstation through timeouts and retries, exactly as the architecture prescribes. The cloud does not change the roles; it changes where the master lives.
For remote operations, the practical value of understanding the architecture is that it explains both the strengths and the limits of the system. Because the master initiates, data is only as fresh as the last poll, and an outstation on a shared link competes with its neighbors for the master's attention - which is why poll scheduling and event reporting matter. Seeing the whole field as one master working through many outstations is the mental model that makes every downstream tuning decision, from poll rate to retry counts, coherent rather than a bag of unrelated settings.
It is the communication structure where a central master initiates all conversation - sending requests and commands - and field outstations respond with their data and carry out commands. The master asks and the outstations answer, and traditionally an outstation does not transmit until it is polled. This request/response relationship is the foundation of nearly all SCADA polling.
MTU and RTU are hardware names - the master terminal unit is the control-center computer and the remote terminal unit is the field device. Master and outstation are communication roles describing who initiates and who responds. An MTU usually plays the master role and an RTU the outstation role, but the roles are about the request/response topology, not about which box a device physically is.
Yes, because the roles are relative to a specific link. A field RTU can be an outstation to the central master that polls it while simultaneously acting as a master to a sub-network of devices beneath it, aggregating their data. Large telemetry systems are built as tiers of master/outstation relationships, so a device's role depends on which conversation you are considering.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.