Integrating third-party systems with a DCS

Dec 10, 2014 6:16:00 AM | Posted by Tony Kolluri

Several considerations need to be made when interfacing a distributed control system (DCS) to a third-party system, including the choice between using SCADA or peer-control solutions.

Figure 1: Interfacing a distributed control system (DCS) to a programmable logic controller (PLC). Courtesy: Maverick Technologies

Interfacing a distributed control system (DCS) to a third-party system—let’s say a programmable logic controller (PLC)—is most commonly done via SCADA or peer-control using various communication protocols. While it appears that it’s just a task of getting the data ‘in’ to the DCS, several considerations need to be made to understand the purpose, the data interaction with the DCS points, and the criticality of the data.

When considering SCADA as a solution, the DCS acts like any other SCADA system providing a robust human operator interface (HMI). This involves creating a SCADA database, which is usually a copy of the PLC database with points, alarming, historization, and other features offered by the DCS. The operator is at an advantage with this approach as the interface is the same, essentially working from the same workstation, using the similar faceplates, trends, and displays as the DCS points. If a third-party system is run as a stand-alone system, this would be a perfect solution.

Figure 2: Comparison between a SCADA solution and a peer-control solution. Courtesy: Maverick Technologies








In a DCS, the DCS server is the SCADA database repository. The server making use of the appropriate drivers generates communication requests and responds to requests by the third-party device. The server essentially becomes the key component for the entire interface to work. If the data needs to be passed to the DCS controllers, then this server would be a point-of-failure in case of network mishaps. The server also becomes the middle man to pass data in normal operations, which could add delays.

In the peer-control approach, the third-party device is interfaced through a DCS controller. The controller generates and responds to the device by making use of appropriate drivers and protocols. Thus the controller becomes a ‘peer’ to a third-party device as it is able to communicate to another system directly. It must be kept in mind that a process controller must not be loaded with communications duties in addition to normal processing; hence central processing unit loading must be done carefully. This could necessitate a dedicated communications controller to handle third-party data.

So the question arises: which is a better solution? A better question would be: when would each approach be the best solution? The nature of the data brought in determines which one is a best fit for the application. If the third-party device is a stand-alone system with minimal interaction with DCS points then SCADA must be the route. If the third-party system—like a safety instrumented system—with trips and permissives that affect DCS points to respond in a certain way in a certain time frame then peer-control interfacing would be the best approach.

This post was written by Tony Kolluri. Tony is a senior engineer at MAVERICK Technologies, a leading automation solutions provider offering industrial automation, strategic manufacturing, and enterprise integration services for the process industries. MAVERICK delivers expertise and consulting in a wide variety of areas including industrial automation controls, distributed control systems, manufacturing execution systems, operational strategy, business process optimization and more.