What is a Distributed Control System (DCS)?

DCS stands for Distributed Control System. What is distributed is the computing power: control runs on several controllers close to the process, and operation sits in a central control room. Both are set up as one system, typically an integrated system family with a shared engineering environment from a single vendor. Hybrid and migrated plants deviate from this, for example when third-party devices are connected or parts of an older system stay in service. The same kind of system is often called a process control system, and several vendors use that name for their products.

A typical DCS has four parts. Controllers execute the control loops for pressure, temperature, flow and level. Operator stations in the control room show the process and accept setpoints, permissives and alarm acknowledgments. An engineering system holds the configuration: control loops, graphics, alarms and recipes. And there is usually a historian that keeps measured values for months or years.

Below the controllers sit the field devices: sensors deliver the measurements, and actuators such as control valves carry out the control commands. They connect to the controllers through I/O modules or a fieldbus.

In the automation pyramid a DCS spans the control level and the supervisory level: its controllers sit on the control level, where PLCs otherwise sit, and its control room and operator stations on the supervisory level, alongside SCADA and HMI. In its description of ISA-95, ISA lists the DCS as a whole under Level 2. The two models count their levels differently, so every placement here names the model it belongs to.

A PLC (programmable logic controller) controls a machine or a line. A DCS controls a process that spans a production plant or a large part of it. Both run their logic on controllers close to the process. What sets a DCS apart from a collection of individual controllers is the unity of the system: a control loop, its operator faceplate and its alarms are defined in one place and apply across the whole system. That makes a DCS consistent. It also makes it a system that is not changed casually.

The two come from different jobs. The PLC replaced hard-wired control, in which the logic lived in the wiring, and runs machines and production lines. The DCS comes from the process industries, where many interdependent control loops are run from one control room.

The line is not sharp. Whether a process gets a DCS or individual PLCs depends more on its properties than on a single technical feature: how strongly the control loops depend on each other, what a stop costs, and what has to be documented.

For the connection to IT the difference is concrete. A PLC is reached controller by controller, over its own protocol or an OPC UA server on the device, and a plant with many machines means many connections. A DCS is one system with one configuration. A value written into it from outside reaches into an environment that was planned and approved as a whole, and the plant owner wants to know exactly what an outside system reads from it and writes into it. How a PLC is built and how its data gets out is covered in What is a PLC?

A DCS controls a connected process itself. A SCADA system supervises many installations whose control stays with the installations. The DCS grew up in the continuous process industries. SCADA grew up in supervising distributed assets, such as water supply and power grids.

As a tendency, a DCS is the more closed system, with vendor-specific interfaces and a change approval practice that deliberately makes changes harder. A SCADA system tends to be more open, speaks standard protocols more often and is quicker to extend. For a particular product this is no reliable guide: there are control systems with OPC UA and closed SCADA systems.

In many plants that have grown over decades, both are in place side by side: a DCS for the production units, a SCADA system for the utilities. An integration layer then serves both. The SCADA side is covered in What is SCADA?

A DCS belongs to process manufacturing: products made to a recipe rather than a bill of materials, and counted in batches or as a continuous flow rather than in pieces. Typical settings are chemicals and petrochemicals, pharmaceuticals, pulp and paper, and food and beverages.

These settings share properties that suit the way a DCS is built. The process often runs continuously, around the clock, or in batches that cannot be interrupted halfway. Stopping it wastes material or raises safety questions. The control loops depend on each other: when the temperature in one reactor changes, pressure and flow change elsewhere. And many of these industries are heavily regulated, which brings complete documentation and strict change approval with it.

The overview below lists widely used systems for orientation. It is neither complete nor a ranking.

For connecting a DCS to IT, the name matters less than which interfaces an installed system offers, and in which version. Many older installations provide their values through OPC DA, the classic OPC specification built on Windows DCOM. Newer versions often include OPC UA. Which interface is enabled and licensed in a particular plant is something to settle with the plant owner and the vendor before any planning starts.

As with SCADA there are two directions, and with a DCS the second is the more delicate one.

Out of the DCS. Measured values, states and batch data are needed in a database, an MES, an ERP system or the cloud. A middleware reads them as an OPC client from the DCS’s OPC server, over OPC DA or OPC UA, and writes them on. On the OPC Router product overview, DCS appears in the same list as PLC, SCADA and MES. SAP offers its own component for this as well: according to the SAP connection page on opc-router.com, SAP Plant Connectivity (PCo) enables data exchange between an SAP system and data sources such as process control systems, plant historian systems and SPC systems.

The international use cases on opc-router.com (page dated August 2026) give an example of this direction. A Japanese manufacturer of insulating materials replaced its DCS historian with an InfluxDB, into which the OPC Router relayed more than 10,000 data points every few seconds. Plant data also went over MQTT to the company’s global MES in the cloud.

Into the DCS. Order data, setpoints or recipes from the ERP system need to reach the process without a paper slip in between. That was the starting point at the wax manufacturer Hywax: order data from SAP was printed out, collected and typed into the machine’s interface by hand. The task was to connect two Siemens systems and a Yokogawa control system with SAP. A first solution assembled from many partial solutions took around 20,000 lines of code. With the OPC Router, the data transfer from SAP to the Siemens and Yokogawa systems was set up graphically, and according to the case study more than 90 percent of the programming was replaced by graphical connections.

A third route reverses the roles. The DCS fetches the values itself. If it can read as an OPC client and the middleware acts as an OPC UA server, the DCS sees values there that come from entirely different systems. The example on the OPC UA Server Plug-in page is a label printer: its status is provided as a variable in the OPC Router, the control system reads it as an OPC client and can raise alarms on it. Through the method trigger it can also start a print job. The advantage of this route is ownership: what is read and when is configured in the control system, and the middleware does not have to write anything into the approved system.

Background: What is middleware? · What is IT/OT integration?

The difficulties in connecting a DCS recur from plant to plant, and none of them is the fault of a particular product. They follow from how these systems are built: from the age of the interface, from the redundancy of the control system, and from the preselection the DCS’s OPC server makes before any client sees a value.

The DCS speaks OPC DA, and OPC DA needs DCOM

On the control system’s own computer the connection works. From a second machine the list of available OPC servers stays empty, or a connection that ran for years stops after a Windows update.

The cause lies underneath. OPC DA is based on Microsoft’s COM and DCOM. Across a network, DCOM negotiates the actual communication port dynamically: the client first contacts the endpoint mapper on the server computer via port 135 and learns there which port the connection will use. A firewall that only opens fixed ports blocks this. Security adds a second problem: with DCOM hardening, Microsoft tightened DCOM’s security requirements; since the Windows update of March 14, 2023, the hardening can no longer be turned off. Connections that do not meet the requirements are blocked.

The typical pattern: it works locally but not across the network. The server list in the connection dialog stays empty, because according to the manual the OPC Router needs DCOM permissions to read it from the target computer. Or the failure coincides with an update.

The DCOM configuration is on your side, because it is a Windows setting on the control system’s computer. Both computers need the same domain user for the service account, or a local user with exactly the same name and password on each. Port 135 is opened, and the dynamic port range is restricted in the Windows registry so that only that range has to be open in the firewall. The alternative is to convert DA to OPC UA right at the source. That was the setup at a company in the paper industry in Turkey described in the international use cases on opc-router.com (page dated August 2026): its DCS and its quality control system ran on two servers, each with an OPC DA server, and Kepware converted from OPC DA to OPC UA on both (more detail in What is SCADA?). An OPC tunnel, which carries OPC DA over OPC UA across a single TCP/IP port, achieves the same.

In the OPC Router, the OPC Classic plug-in speaks OPC DA versions 1, 2 and 3; the version is chosen in the connection under “DA Version”. For version 1 and 2 servers, the manual calls for the option “Disable change notifications”. If the OPC Router runs on the same computer as the control system’s OPC server, the DCOM route across the network disappears.

Two limits apply here. The manual puts it plainly: “Port 135 and the dynamic port range belong to Windows, not to the OPC Router.” And OPC Classic is not supported in Docker; running the OPC Router as a container requires OPC UA at this point.

The DCS is redundant, the connection is not

The control system switches over to its standby server. Operation in the control room continues without interruption, which is what the redundancy is designed for. In the database, a gap starts at the same minute.

Redundancy is a property of the server pair, not of the connection. A client configured with one address has no information about the pair. If the primary server fails, the client has no partner left. And a server that still responds but is no longer the active one may deliver values that are no longer being updated. Which role a server has at any given moment is held by the control system; the client only receives it if the control system exposes it as a data point.

The timing points to the cause: the gap starts with the control system’s switchover, not with any event in the target system. Put the DCS event log next to the missing periods and the times match.

Two things are on your side: the data point that shows the active role, and knowing the vendor’s switchover logic. The manual draws the line explicitly: “The actual high availability of the third-party system continues to be provided outside the OPC Router, for example, through a redundant server configuration or a vendor-specific failover solution.” How values from the switchover moment are treated in analysis is yours to decide.

In the OPC Router, the OPC UA and OPC Classic plug-ins accept a redundancy server next to the primary one, plus an optional alive item. The OPC Router switches when the primary server cannot be reached, or when the alive item cannot be read or returns the value “0”. If the control system exposes its active role as a data point, that data point can be entered as the alive item. This is set in the OPC connection under “Redundancy”. In the license overview the feature is called “Redundant Connection of Subsystems”; it belongs to the Enterprise+ add-on, which is included in the Enterprise license.

This is separate from the redundancy of the OPC Router itself, which concerns the middleware, not the connection to the control system. Store and forward does not help here either: it buffers when the target fails, not the source. Behavior at the moment of switchover depends on the control system and should be tested before going live.

The DCS’s OPC server filters changes in advance

The trend display in the control room shows fine fluctuations. The database shows a staircase, or values arrive far less often than configured.

With OPC DA, the update rate is a request from the client, not an instruction. The manual says that “the specific update rate used depends on the OPC server”. The dead band, the minimum percentage change, filters in the server before a value reaches the client, and it is “optional and does not have to be implemented by all OPC servers”. With OPC UA, a sample rate of “0” asks for the server’s fastest rate, and the server sets what that is. What reaches the client has already been selected at the source.

Small changes are missing altogether rather than arriving late. The number of values per hour stays consistently below what the configured rate would suggest. That distinguishes this case from trigger logic of the kind described in What is SCADA?: there the client sets when to transfer, here the server has already filtered.

Checking sampling and dead band on the control system’s OPC server is on your side, because that is where the selection happens. The manual gives Kepware’s “Scan Mode” as an example, the setting that defines which scan rate the server uses and how far it takes the client’s rate into account. The dead band belongs in a single place; otherwise values are filtered twice and there is no telling which filter applied.

In the OPC Router, the source is told what is needed: in the OPC Classic connection through “Update Rate (ms)” and “Dead Band (%)”, in the OPC UA plug-in through the “Sample Rate”, where “0” requests the server’s fastest possible rate. For values that need to be as fresh as possible there is the “Synchronous” read mode. It reads directly from the data source wherever possible, generates more network traffic in return, and is implemented only in the OPC transfer object. The OPC Router cannot force a rate.

What the control system’s OPC server filters out in advance reaches no client.

Distributed control systems come with large numbers of data points; in the Japanese case it was more than 10,000 data points every few seconds. With OPC UA, the Multi-Datachange trigger in the OPC Router watches a whole data point group instead of individual values and can check at runtime whether points have been added or removed.

For planning, the manual documents three measurement series for OPC data transfer, each with a single instance, measured with an earlier version of the OPC Router:

In the first two series the OPC Router ran on four cores with 16 GB of RAM, in the third on a virtual machine with eight processors and up to 16 GB. The manual contains no newer measurements.

For more throughput, or to keep plant areas apart, one instance per area can be used. That spreads the connections across several instances but does not lift any limit of the OPC server: in the series that reached about 28,500 data points per second, the manual names the OPC server as the limiting factor.