KB Controls is reader-supported. When you buy through links on our site, we may earn an affiliate commission. Read more in our disclaimer
In this post, we learn what a DCS is, what components make up a DCS, and why a DCS is supplied as a single unit to end-users
A DCS, or Distributed Control System, is a tightly-integrated system made up of hardware and software components to control processes in the process control industry.
That definition raises a few more questions than it answers, so let’s start with the basics — what is a process?
A process is a series of steps that are used to create a product.
In the process industry, processes usually involve a combination of mixing materials and having them react together, changing the properties of materials by subjecting them to heat and pressure, and separating the resulting materials.
Process systems are defined in Piping and Instrumentation Drawings, also known as P&IDs. An example of a P&ID is shown below.
A process system contains specialized equipment for each process step such as heating and mixing.
The state of the process is monitored at each piece of equipment using specialized sensors, collectively called instrumentation. These sensors read the temperature, pressure, flow rates, and other process variables of equipment and materials to make sure that a process remains under control.
Material is transported from one piece of equipment to another through a system of pipes.
Now we know what a process is, let’s talk about the elements that make up a DCS and allow a DCS to control a process.
So a Distributed Control System is a system made up of hardware and software components that controls a process. But what components actually make up a DCS?
A DCS is a well-integrated assembly of compatible components that all work together as a system. The components used in a DCS are all designed to be assembled together into a system — in general, a DCS is sold as a single unit by a vendor, not as individual parts to be assembled by an end-user.
At the lowest level of a DCS, instrumentation and field devices convey process data back to the control system.
In older systems, the instrumentation devices sent back process data such as temperatures, pressures, and flow rates to the control system as analog electrical signals.
In modern systems, instrumentation devices typically communicate with the control system over an industrial network like EtherNet/IP. The advantage of communication over an industrial network is that more data can be sent to the control system, including diagnostic data about the health of the instrumentation device.
Instrumentation and field devices send process data to controllers that run tasks at consistent, periodic intervals.
Within those tasks, the DCS controllers execute programs, which are typically written as Function Block Diagrams. These programs are put together by engineers, who leverage objects from a standard library for process control like the PlantPax Library of Process Objects from Rockwell Automation to quickly create high-quality control programs.
Since a DCS is an integrated system, engineers use pre-defined software components wherever possible. The engineering of a DCS controller is more accurately described as “configuration” than “programming”. The advantage of using pre-defined software components is that a lot of common functionality is available for DCS applications off the shelf, without the need for development or testing on each project.
As you may have guessed, the most common type of DCS controller is a PLC.
The day-to-day operation of the DCS is done on Operator Workstations, which are computer stations or HMI terminals mounted close to the process equipment.
An Operator Workstation provides a graphical view of the process and allows an operator to interact with the process. The Operator Workstation is used exclusively for operator interaction — Operator Workstations are not typically used for development or maintenance tasks.
Using an Operator Workstation, a DCS operator can navigate through the entire system and see warnings and errors related to the process through a standardized alarm system.
Engineering workstations are workstations that have the configuration software for the DCS installed on them. This may be programming software for DCS Controllers like Rockwell Automation’s Studio 5000 Logix Designer or configuration software for the visualization application like Rockwell Automaton’s FactoryTalk View.
Using these workstations, engineers can debug the status of a process or make required changes to a DCS controller, application, or instrumentation device.
A DCS system includes high-level software applications.
One common application is the visualization application which serves visualization screens to the Operator Workstations.
Another is a historian application that logs data from the process to a database for quality, safety, and tracking purposes.
These applications run on dedicated servers that are connected to the DCS network. These servers may be physical or virtual servers and are typically installed in a dedicated server room away from the factory floor.
Communication between the application servers, workstations, and DCS controllers is handled by an Ethernet network.
A core idea behind a DCS is that although control strategies are distributed across multiple controllers, there should only be one centralized repository for data storage and manipulation.
This centralized repository for data storage and manipulation is typically a Process Automation System Server which acts as a data server to connect the DCS controllers with high-level applications running on application servers.
In many process applications, the ability to continue to perform certain tasks after a hardware failure or general fault has occurred is essential. If the process stops, then valuable products may be wasted and it may be very expensive to get the process running again.
This need for high availability is so important that many end users are willing to pay for additional, specialized hardware and software configurations to ensure that DCS components are fault-tolerant, that is that the DCS can continue to operate even when one or more components have failed.
It is very common to have backup system components such as controllers, application servers, and data storage servers designed into a DCS.
Of course, additional hardware and software configuration adds to the upfront cost of a DCS but most end-users accept that this additional cost is less expensive than the cost of unplanned system downtime or product waste in the event that a component fails later on.
DCS vendors supply the hardware and software for a DCS along with engineering, installation, commissioning, project management, and support contracts. Basically, DCS vendors supply end users with a complete turnkey solution to control their processes based on the vendor’s process knowledge and control system knowledge.
A DCS system like the one shown above is designed, built, tested, and released by a vendor to the end-user.
You may be wondering why a DCS is handled differently from, for example, a packaging line in a discrete industry. In discrete industries, it is not uncommon for end-users to buy several different machines from different manufacturers and to connect those machines together to form a packaging line.
The main reason is that for processes to run continuously, without interruption, every component has to be tightly integrated and guaranteed to be compatible with other components in the system. Therefore, end-users are less likely to buy individual components and integrate those components themselves in process applications.
In this post, we learned what a process and a DCS are.
As well as learning what a DCS is, we talked about the components that make up a DCS and learned why DCSes are typically supplied as a tightly integrated system to end-users.
PLC Programming from Scratch is designed to teach you everything you need to know to be an effective PLC programmer. Using practical examples, this course teaches you how to program PLCs using the most popular IEC 61131-3 programming languages including Ladder Diagram, Structured Text, and Function Block Diagram in a free development environment.
A Detailed Explanation of the Value of Secure Remote Access for OEMs and End Users, Including Examples of Common Use Cases
In this post we learn the difference between a continuous process and a batch process and discuss the reasons why a manufacturing facility would choose to design a process as a continuous process or a batch process.