What is SCADA? Components and How It Differs from HMI, MES and DCS

The four letters stand for Supervisory Control and Data Acquisition. The name describes the division of labor precisely. A SCADA system does not control anything itself in millisecond cycles; the controllers do that. It supervises them, collects their values and allows intervention where a human has to make a decision.

A typical system has three parts. A SCADA server handles data storage, alarm logic and history. Operator stations display the plant and accept input. In between sit communication drivers to the controllers, over fieldbuses or OPC UA, for example.

Not every field station is a PLC. In widely distributed plants, for example in water supply or in power grids, remote terminal units (RTUs) sit at the outlying stations: they acquire the values, report them to the SCADA system and execute its commands, often over telecontrol protocols such as IEC 60870-5-104 or DNP3.

This article concentrates on how SCADA differs from neighboring systems and how it connects to IT.

SCADA sits on the supervisory level of the automation pyramid. Below it are the controllers, above it the MES. The level number depends on the model: ISA’s own ISA-95 description lists SCADA under Level 3, while common Purdue model diagrams place it at Level 2.

This hierarchy describes responsibilities. In practice, it no longer dictates the data paths: an ERP system can also talk directly to this level. The values are already collected there, and the ERP system receives the plant state as it is now rather than as it was last night.

More: What is ISA-95?

An HMI is the operator interface of a machine or an area. A SCADA system brings many of them together.

In practice, the HMI on an extruder shows that extruder. The SCADA system shows every extruder, their alarms and their history, and lets you compare them. An HMI can be part of a SCADA system.

The distinction blurs with web HMIs that can be reached from several locations, and it blurs further now that panels are network devices in their own right and can keep their own history. The useful dividing line is therefore the scope: Does an interface operate one machine, or does it supervise a group of plants and let you compare their parts? A specification that calls a system both HMI and SCADA says little on its own. The useful follow-up question is how many plants it shows at once and whether it can put their values side by side.

More: What is an HMI?

Both collect production data, but they answer different questions.

The difference lies in the order reference.

A SCADA system shows that oven 3 is running at 180 degrees. An MES assigns those 180 degrees to batch 4711 and therefore to the quality record.

In practice the two overlap, and many SCADA systems have picked up MES functions. The distinction is still useful: it determines which system is authoritative when two numbers contradict each other.

A DCS (Distributed Control System) was historically built for the continuous process industries: chemicals, refining, paper, pharmaceuticals. There, control is part of the system rather than of the individual controller, and availability is the overriding requirement.

SCADA comes from distributed monitoring: water supply, power grids, manufacturing with many individual machines. Control stays with the plants; the SCADA system supervises them and allows intervention.

The boundary has been blurring for years, and specifications sometimes use the two terms interchangeably. As a tendency, a DCS is more of a closed system, with vendor-specific interfaces and an approval practice that deliberately makes changes harder. A SCADA system tends to be more open, more often speaks standard protocols and can be extended faster. For an individual product, that is not a reliable guide: there are DCS products with an OPC interface and closed SCADA systems. Before planning an integration, it is therefore necessary to establish which interfaces the installed system offers in its version and whether they are enabled. That decides whether the route runs through a documented interface or through an approval from the vendor.

More: What is a Distributed Control System (DCS)?

There are two directions to distinguish, and they are technically different.

First direction: SCADA reads. It fetches values from the controllers, through drivers for their native protocols or over OPC UA. Middleware can itself act as an OPC UA server and offer the SCADA system data that does not come from a controller at all: values from a database, an ERP system or a web service. The SCADA system treats it like one more controller.

The state of a connection itself can also be provided this way. The SCADA system then displays whether the link to the ERP system is up, alongside the plant values. An alarm on a broken interface thus appears in the control room, not only in a server log.

A SCADA system can also be fed this way instead of only being polled. According to the international use cases on opc-router.com (page dated August 2026), a Brazilian mining company supplied its SCADA software at five sites by this route: KEPServerEX read the Allen-Bradley PLCs and passed the values over OPC UA to the OPC Router, where a script turned them into JSON objects that were sent to the SCADA software over REST.

Second direction: out of SCADA. Values need to go into a database, an MES, an ERP system or the cloud. For that, middleware reads the SCADA data and writes it onward. Which routes a SCADA system opens for this depends on the product: for example its own OPC server (OPC UA or classic OPC DA), the database behind its archive, or a REST or MQTT interface. The OPC Router can address each of these routes with the matching plug-in; it reads history from an OPC UA server over Historical Access.

The gain can also lie in decoupling. According to the same use cases, a Spanish manufacturer of dairy products collected information from an OPC server, managed its redundancy and supplied its PI systems, that is, a historian database. The benefit the entry names is that the company can improve or change its data analysis systems without changing the way it extracts data from the process.

Such an integration layer can bring together systems of different kinds and from different vendors. According to the ZewaTec use case on opc-router.com (page dated January 2025), the system integrator ZewaTec connected the SAP system of a manufacturer of wax technologies with two Siemens systems and a Yokogawa control system. The first solution was a patchwork of partial solutions that took around 20,000 lines of code. After the switch to the OPC Router, its graphical connections replaced over 90% of that programming, according to the page.

A second case couples a control system with an inspection system. According to the international use cases, a paper manufacturer in Turkey ran its quality control system and its DCS on two separate servers, one for paper values, the other for process variables such as line speed and temperature. Both came with an OPC DA server, and Kepware converted to OPC UA. One OPC Router instance linked the tags between the quality system and the DCS; a second collected everything on a third server and wrote it to an SQL database. On that third server, a second inray product, the Factory Application Server (FAS), generated the daily, weekly and monthly reports.

The SCADA system and the report read the same plant and still arrive at different results. That can happen without either side being misconfigured: the discrepancy then follows from how the connection is built. On top of that comes the outage of a target system, which only leaves a lasting mark if nobody decided beforehand what should happen while it lasts.

A change-driven connection reports states, not events

The trend in the SCADA system shows a spike, a switchover, a counter step. The database does not. Both series come from the same source, neither reports an error, and both are formally correct.

The cause: A change-driven connection that gets only the latest state per read cycle reacts to the change notifications it receives, not directly to changes in the plant. Such a notification describes the state at the end of a read cycle. If a data point changes twice within one cycle, the intermediate value never existed as far as the reader is concerned. There is no acknowledgment and no gap notice, so neither side indicates that something is missing.

The behavior is documented. For the Data Change trigger, the OPC Router manual states that if the data point changes multiple times within a read cycle, “the OPC Router only sees the latest value”, and “the intermediate values are lost without notification.”

How it shows: Only by comparison, for example a counter reading from the plant against the sum of the individually transferred events. Where completeness matters, a counter is therefore part of the design.

On your side. The counter belongs in the controller, and no middleware can make up for it: an event the PLC does not number never happened as far as any downstream analysis is concerned. Three things belong in the PLC program. First, the counter itself, incremented by one whenever there is new data. Second, the order: write all related values first and set the counter last. Third, a timeout for a missing acknowledgment. The third is easily overlooked, because its absence produces no message: a transfer that never fired simply does not happen. Searching the counter column for gaps is then an analysis in the target system.

In the OPC Router. Where no record may be lost, a change-driven connection is the wrong choice. For those cases the OPC Router offers the message trigger and the bit trigger. With the message trigger, the controller increments a counter for every record, and according to the manual, every change of the counter triggers exactly one transfer. The bit trigger fires on a set bit. When several events follow one another, the manual recommends the message trigger, because it is based on a change counter. With both, the router can acknowledge through a response data point; if that is enabled, the controller can tell from a missing acknowledgment that it has to repeat. Before reading, the router waits one additional read cycle, so that the controller has had time to write all related values. It can also set an error bit in the controller if a transfer fails. The counter value of the message trigger can be written along as a field. That makes it possible to check in the target system whether a record is missing or arrived twice. For restarts there is the “Trigger on startup” option, one of whose settings picks up the record whose message and response IDs had diverged at the restart.

Trend and database trigger by different rules

Two series of the same variable over the same period, and they do not even have the same number of points. The average differs, although both sides read the same source.

The cause: A trend in a SCADA system often records on a time basis, on a fixed grid; some archives record on change with a deadband. A database connection frequently runs change-driven, only when a value changes. Both are correct and describe the same plant. But an average over a change-driven series is weighted by the number of changes, not by time. A variable that sits still for an hour and then jumps around for five minutes looks systematically different in the two series.

How it shows: The series differ in point count before they differ in value. Counting is therefore a quicker check than averaging.

On your side. Which logic applies is a design decision about the analysis, and it has to be the same on both sides. No middleware can set the SCADA side for you. Two things come on top in the target system: it has to use the timestamp delivered with the value instead of its own arrival time, and the time horizons have to match. A trend on a 5-second grid and a database series on a 1-minute grid are not comparable even with the same trigger logic.

In the OPC Router. It supports both logics. On a time basis, the Cron trigger fires at times described by a cron expression, down to the second and up to the day of the week, month and year. On a change basis, the Data Change trigger fires. The two can be combined: the Data Change trigger can also fire once a set interval has elapsed, even when the value has not changed, turning a staircase into a series with at least one point per interval. Conversely, how often it fires can be limited. That reduces the load and gives up intermediate values in return: at the end of the lockout period, the most recently reported value is delivered, with the timestamp of its measurement, not of its transfer.

Despite its name, the Time trigger does not produce a fixed grid. According to the manual, the router calculates the interval from the end of the last transfer: with a setting of 1 s, it does not transfer every second, but 1 second after the end of the previous transfer. For two series that line up, the Cron trigger is therefore the right choice.

An aggregated history value is a calculation, not a measurement

The same report over the same period, pulled twice, gives two different numbers. Or the curve has no gap, although the plant was demonstrably down.

The cause has two independent parts. First, a historian may correct its stored values after the fact. A normal read returns the values as they stand now, that is, the corrected ones; the replaced versions are returned only on a separate request. Second, an average, minimum or maximum over an interval is calculated by the server, and depending on the aggregate, interpolation over missing values is part of the procedure. The smooth curve across the downtime is then the agreed result.

How it shows: A report that changes when it is pulled again. An aggregate that runs inconspicuously across a downtime. The check is to run the same query once raw and once aggregated.

On your side. First, the server has to support Historical Access at all. The manual states that reading history “is only available for OPC UA servers that support the OPC UA Historical Access specification.” A SCADA system that keeps its trends only internally cannot be read this way. If the route exists, the calculation still belongs to the server. That is why the option “Use Server Capabilities Defaults” deserves a look: when it is enabled, the server’s defaults apply, and your own settings for extrapolation and quality percentages have no effect. Which aggregation applies to a report remains a design decision that is made before the first report.

In the OPC Router. It reads history data over OPC UA Historical Access in two modes: raw, meaning the individually stored values, or processed, meaning values aggregated over intervals. Whether the changes to history values are read as well can be set in raw mode. In processed mode, the OPC UA server does the calculation, and whether it interpolates across a gap between two values depends on the selected aggregate. The extrapolation setting only concerns extending the series beyond the last available value. An accepted percentage of bad values and a required percentage of good values determine how the result of an interval with bad values is flagged, unless the server’s defaults apply.

The check from above can therefore be configured without custom development: raw and processed are two read modes of the same transfer object, so two flows. The server timestamp and the OPC Router timestamp can be output separately, which keeps the time of measurement and the time of retrieval apart.

In practice: According to the international use cases on opc-router.com (page dated August 2026), a Japanese manufacturer of insulating materials replaced its DCS historian with an InfluxDB; the OPC Router relayed over 10,000 data points every few seconds. The figure shows the order of magnitude of the load when a history is moved out of the control system.

Bad-quality values are discarded, and the gap does not look like one

The plant had a fault. The SCADA system shows it as an alarm and a flat line. The database shows nothing at all for that period, and the shift average makes the shift look better than it was, because the bad phase is not included.

The cause: Over OPC, every value carries a quality besides its number and timestamp. A connection filters on it, and whatever it does not accept is discarded instead of being passed on flagged as invalid. On its own, the quality does not survive the boundary to the target system anyway: an ordinary target schema has only a column for the number, unless someone adds a second one. So what remains is a gap, and a gap cannot be told apart from “nothing was running”.

How it shows: The fault phase is missing from the analysis entirely, instead of appearing in it as bad values.

On your side. The trade-off itself is yours to make. Letting only “Good” through is a legitimate choice, but it creates the gap described above; letting all states through brings values into the analysis that cannot be relied on. Two things are easily overlooked. First, the setting sits on the connection, not on the individual flow; if a reporting flow needs different qualities than a control flow, a second connection is needed. Second, the target system needs a column for the quality, and the analysis has to use it. A quality code that is written but never evaluated does nothing for a wrong shift average. And a cleanly flagged bad value is still a record of a fault; it does not become a measurement.

In the OPC Router. Whether a value with limited or bad quality is processed at all is determined by the “Allowed Qualities” field of the OPC connection, from “Good” only to all states. If bad qualities are allowed, the OPC Router can pass the quality along in the flow as a field of its own, as an integer or as a string. For classic OPC data points, the column then holds 192 for “good”, for example. Instead of a gap, the target table holds a value with a note on why it should not be trusted. The prerequisite remains that the target system has a field for it and that the analysis takes it into account.

Two more settings target the silent gap directly. If bad qualities are allowed in the connection, the Data Change trigger can also fire on a change in quality; the transition from good to bad to good then becomes a sequence of timestamped rows. And the Data-Change-Missing trigger fires when a data point does not change within a check period, optionally with the metadata of the last known value.

The gap can come from the target system

An hour is missing from the database. The plant was running, the values were good, and the connection no longer reports an error. What was missing was the other end: a maintenance window, a restart, a network link.

The cause: A connection without a buffer transfers at the moment it is triggered. If the other end cannot be reached, the operation has nowhere to wait. Afterwards everything carries on, and no trace of it remains.

How it shows: This gap has sharp edges and coincides with an event in the target system, not with an event in the plant. Putting maintenance windows and missing periods side by side makes the connection visible.

On your side. First, Store and Forward has to be enabled in two places, globally and additionally in every flow that is meant to buffer; enabled only globally, it buffers nothing. Second, the decision belongs to each flow, because catching up does not make sense for every value. Third, every record has to carry its own value or recording timestamp, because the original order is not guaranteed when data is caught up; that is a decision about the data model in the target system. Fourth, retention time and storage capacity need to be sized, because once the retention time has elapsed, values that are too old are discarded.

In the OPC Router. If a target system is temporarily down, the OPC Router can buffer the affected transfers and deliver them once transmission is possible again. Retention time, storage capacity and the behavior when capacity is reached are configurable, and the status of every buffered record is visible in the status view.

Four limitations come with it. As a rule, Store and Forward is available on the transfer objects at the end of a flow; whether it applies to a specific one is shown by the Store and Forward icon once the feature is enabled. Values delivered later do not necessarily arrive in their original order. If delivery keeps failing, the router gives up after a few attempts; according to the manual, this usually affects invalid records. And for values where only the current state matters, the vendor explicitly advises against it, because outdated values would otherwise be written with a delay. For a visualization tag in the SCADA system, Store and Forward is the wrong choice; for a batch report, it is the right one.

Store and Forward does not solve two cases: a value discarded for bad quality is not an error in the target system and does not end up in the buffer, and an intermediate value that never reached the router cannot be buffered either. Store and Forward is also an add-on. Whether your license includes it is something to clarify before planning.

No, it shifts some of its tasks. Operating and intervening stay on site, because they have to work even when the internet connection is down. What moves to the cloud is analysis across plants and sites: key figures, comparisons, reports.

That results in layers. Controllers and SCADA stay where they are. An integration layer carries the values upward. Above it sits a platform that analyzes without controlling anything itself. That role is taken by manubes.

A case from Japan shows what this can look like in a plant that has grown over time. According to the international use cases on opc-router.com (page dated August 2026), the OPC Router at a carbon materials company transferred data between Mitsubishi PLCs, smart meters, MySQL, Excel, a GE SCADA system, a historian and an IoT data platform, which it supplied over REST. The page describes the plant status being visible in a web browser and on smart devices within the company’s VPN: production data, energy consumption and demand, control data, alarms and events, historical data and trends. The GE SCADA system remained one of several systems between which the OPC Router mediated.

More: What is an MES? · What is OPC UA?