Distributed control system

A distributed control system (DCS) is a computerized control system for a process or plant
usually with many control loops, in which autonomous controllers are distributed throughout the
system, but there is no central operator supervisory control. This is in contrast to systems that
use centralized controllers; either discrete controllers located at a central control room or within
a central computer. The DCS concept increases reliability and reduces installation costs by
localizing control functions near the process plant, with remote monitoring and supervision.

Distributed control systems first emerged in large, high value, safety critical process industries,
and were attractive because the DCS manufacturer would supply both the local control level and
central supervisory equipment as an integrated package, thus reducing design integration risk.
Today the functionality of Supervisory control and data acquisition (SCADA) and DCS systems
are very similar, but DCS tends to be used on large continuous process plants where high
reliability and security is important, and the control room is not geographically remote. Many
machine control systems exhibit similar properties as plant and process control systems do.[1]

Structure

Functional levels of a manufacturing control operation

The key attribute of a DCS is its reliability due to the distribution of the control processing around
nodes in the system. This mitigates a single processor failure. If a processor fails, it will only
affect one section of the plant process, as opposed to a failure of a central computer which
would affect the whole process. This distribution of computing power local to the field
Input/Output (I/O) connection racks also ensures fast controller processing times by removing
possible network and central processing delays.

The accompanying diagram is a general model which shows functional manufacturing levels
using computerised control.

Referring to the diagram;

Level 0 contains the field devices such as flow and temperature sensors, and final control
elements, such as control valves

Level 1 contains the industrialised Input/Output (I/O) modules, and their associated distributed
electronic processors.

Level 2 contains the supervisory computers, which collect information from processor nodes
on the system, and provide the operator control screens.

Level 3 is the production control level, which does not directly control the process, but is
concerned with monitoring production and monitoring targets

Level 4 is the production scheduling level.

Levels 1 and 2 are the functional levels of a traditional DCS, in which all equipment are part of an
integrated system from a single manufacturer.

Levels 3 and 4 are not strictly process control in the traditional sense, but where production
control and scheduling takes place.

Technical points

Example of a continuous flow control

loop. Signalling is by industry
standard 4–20 mA current loops, and
a "smart" valve positioner ensures the
control valve operates correctly.

The processor nodes and operator graphical displays are connected over proprietary or industry
standard networks, and network reliability is increased by dual redundancy cabling over diverse
routes. This distributed topology also reduces the amount of field cabling by siting the I/O
modules and their associated processors close to the process plant.

The processors receive information from input modules, process the information and decide
control actions to be signalled by the output modules. The field inputs and outputs can be analog
signals e.g. 4–20 mA DC current loop or two-state signals that switch either "on" or "off", such as
relay contacts or a semiconductor switch.

DCSs are connected to sensors and actuators and use setpoint control to control the flow of
material through the plant. A typical application is a PID controller fed by a flow meter and using
a control valve as the final control element. The DCS sends the setpoint required by the process
to the controller which instructs a valve to operate so that the process reaches and stays at the
desired setpoint. (see 4–20 mA schematic for example).

Large oil refineries and chemical plants have several thousand I/O points and employ very large
DCS. Processes are not limited to fluidic flow through pipes, however, and can also include
things like paper machines and their associated quality controls, variable speed drives and motor
control centers, cement kilns, mining operations, ore processing facilities, and many others.

DCSs in very high reliability applications can have dual redundant processors with "hot" switch
over on fault, to enhance the reliability of the control system.

Although 4–20 mA has been the main field signalling standard, modern DCS systems can also
support fieldbus digital protocols, such as Foundation Fieldbus, profibus, HART, modbus, PC Link,
etc.

Modern DCSs also support neural networks and fuzzy logic applications. Recent research
focuses on the synthesis of optimal distributed controllers, which optimizes a certain H-infinity
or the H 2 control criterion.[2][3]

Typical applications

Distributed control systems (DCS) are dedicated systems used in manufacturing processes that
are continuous or batch-oriented.

Processes where a DCS might be used include:

Chemical plants

Petrochemical (oil) and refineries

Pulp and paper mills (see also: quality control system QCS)

Boiler controls and power plant systems

Nuclear power plants

Environmental control systems

Water management systems

Water treatment plants

 Sewage treatment plants

Food and food processing

Agrochemical and fertilizer

Metal and mines

Automobile manufacturing

Metallurgical process plants

Pharmaceutical manufacturing

Sugar refining plants

Agriculture applications

History

A pre-DCS era central control room.

Whilst the controls are centralised in
one place, they are still discrete and
not integrated into one system.

A DCS control room where plant

information and controls are
displayed on computer graphics
screens. The operators are seated as
they can view and control any part of
the process from their screens, whilst
retaining a plant overview.

Evolution of process control operations

Process control of large industrial plants has evolved through many stages. Initially, control
would be from panels local to the process plant. However this required a large amount of human
oversight to attend to these dispersed panels, and there was no overall view of the process. The
next logical development was the transmission of all plant measurements to a permanently-
staffed central control room. Effectively this was the centralisation of all the localised panels,
with the advantages of lower manning levels and easier overview of the process. Often the
controllers were behind the control room panels, and all automatic and manual control outputs
were transmitted back to plant. However, whilst providing a central control focus, this
arrangement was inflexible as each control loop had its own controller hardware, and continual
operator movement within the control room was required to view different parts of the process.

With the coming of electronic processors and graphic displays it became possible to replace
these discrete controllers with computer-based algorithms, hosted on a network of input/output
racks with their own control processors. These could be distributed around plant, and
communicate with the graphic display in the control room or rooms. The distributed control
system was born.

The introduction of DCSs allowed easy interconnection and re-configuration of plant controls
such as cascaded loops and interlocks, and easy interfacing with other production computer
systems. It enabled sophisticated alarm handling, introduced automatic event logging, removed
the need for physical records such as chart recorders, allowed the control racks to be networked
and thereby located locally to plant to reduce cabling runs, and provided high level overviews of
plant status and production levels.

Origins

Early minicomputers were used in the control of industrial processes since the beginning of the
1960s. The IBM 1800, for example, was an early computer that had input/output hardware to
gather process signals in a plant for conversion from field contact levels (for digital points) and
analog signals to the digital domain.

The first industrial control computer system was built 1959 at the Texaco Port Arthur, Texas,
refinery with an RW-300 of the Ramo-Wooldridge Company.[4]

In 1975, both Yamatake-Honeywell[5] and Japanese electrical engineering firm Yokogawa

introduced their own independently produced DCS's - TDC 2000 and CENTUM systems,
respectively. US-based Bristol also introduced their UCS 3000 universal controller in 1975. In
1978 Valmet introduced their own DCS system called Damatic (latest generation named Valmet
DNA[6]). In 1980, Bailey (now part of ABB[7]) introduced the NETWORK 90 system, Fisher Controls
(now part of Emerson Electric) introduced the PROVoX system, Fischer & Porter Company (now
also part of ABB[8]) introduced DCI-4000 (DCI stands for Distributed Control Instrumentation).
The DCS largely came about due to the increased availability of microcomputers and the
proliferation of microprocessors in the world of process control. Computers had already been
applied to process automation for some time in the form of both direct digital control (DDC) and
setpoint control. In the early 1970s Taylor Instrument Company, (now part of ABB) developed the
1010 system, Foxboro the FOX1 system, Fisher Controls the DC2 system and Bailey Controls the
1055 systems. All of these were DDC applications implemented within minicomputers (DEC PDP-
11, Varian Data Machines, MODCOMP etc.) and connected to proprietary Input/Output hardware.
Sophisticated (for the time) continuous as well as batch control was implemented in this way. A
more conservative approach was setpoint control, where process computers supervised clusters
of analog process controllers. A workstation provided visibility into the process using text and
crude character graphics. Availability of a fully functional graphical user interface was a way
away.

Development

Central to the DCS model was the inclusion of control function blocks. Function blocks evolved
from early, more primitive DDC concepts of "Table Driven" software. One of the first
embodiments of object-oriented software, function blocks were self-contained "blocks" of code
that emulated analog hardware control components and performed tasks that were essential to
process control, such as execution of PID algorithms. Function blocks continue to endure as the
predominant method of control for DCS suppliers, and are supported by key technologies such
as Foundation Fieldbus[9] today.

Midac Systems, of Sydney, Australia, developed an objected-oriented distributed direct digital

control system in 1982. The central system ran 11 microprocessors sharing tasks and common
memory and connected to a serial communication network of distributed controllers each
running two Z80s. The system was installed at the University of Melbourne.

Digital communication between distributed controllers, workstations and other computing

elements (peer to peer access) was one of the primary advantages of the DCS. Attention was
duly focused on the networks, which provided the all-important lines of communication that, for
process applications, had to incorporate specific functions such as determinism and
redundancy. As a result, many suppliers embraced the IEEE 802.4 networking standard. This
decision set the stage for the wave of migrations necessary when information technology moved
into process automation and IEEE 802.3 rather than IEEE 802.4 prevailed as the control LAN.
The network-centric era of the 1980s

In the 1980s, users began to look at DCSs as more than just basic process control. A very early
example of a Direct Digital Control DCS was completed by the Australian business Midac in
1981–82 using R-Tec Australian designed hardware. The system installed at the University of
Melbourne used a serial communications network, connecting campus buildings back to a
control room "front end". Each remote unit ran two Z80 microprocessors, while the front end ran
eleven Z80s in a parallel processing configuration with paged common memory to share tasks
and that could run up to 20,000 concurrent control objects.

It was believed that if openness could be achieved and greater amounts of data could be shared
throughout the enterprise that even greater things could be achieved. The first attempts to
increase the openness of DCSs resulted in the adoption of the predominant operating system of
the day: UNIX. UNIX and its companion networking technology TCP-IP were developed by the US
Department of Defense for openness, which was precisely the issue the process industries were
looking to resolve.

As a result, suppliers also began to adopt Ethernet-based networks with their own proprietary
protocol layers. The full TCP/IP standard was not implemented, but the use of Ethernet made it
possible to implement the first instances of object management and global data access
technology. The 1980s also witnessed the first PLCs integrated into the DCS infrastructure.
Plant-wide historians also emerged to capitalize on the extended reach of automation systems.
The first DCS supplier to adopt UNIX and Ethernet networking technologies was Foxboro, who
introduced the I/A Series[10] system in 1987.

The application-centric era of the 1990s

The drive toward openness in the 1980s gained momentum through the 1990s with the
increased adoption of commercial off-the-shelf (COTS) components and IT standards. Probably
the biggest transition undertaken during this time was the move from the UNIX operating system
to the Windows environment. While the realm of the real time operating system (RTOS) for
control applications remains dominated by real time commercial variants of UNIX or proprietary
operating systems, everything above real-time control has made the transition to Windows.

The introduction of Microsoft at the desktop and server layers resulted in the development of
technologies such as OLE for process control (OPC), which is now a de facto industry
connectivity standard. Internet technology also began to make its mark in automation and the
world, with most DCS HMI supporting Internet connectivity. The 1990s were also known for the
"Fieldbus Wars", where rival organizations competed to define what would become the IEC
fieldbus standard for digital communication with field instrumentation instead of 4–20 milliamp
analog communications. The first fieldbus installations occurred in the 1990s. Towards the end
of the decade, the technology began to develop significant momentum, with the market
consolidated around Ethernet I/P, Foundation Fieldbus and Profibus PA for process automation
applications. Some suppliers built new systems from the ground up to maximize functionality
with fieldbus, such as Rockwell PlantPAx System, Honeywell with Experion & Plantscape SCADA
systems, ABB with System 800xA,[11] Emerson Process Management[12] with the Emerson
Process Management DeltaV control system, Siemens with the SPPA-T3000[13] or Simatic PCS
7,[14] Forbes Marshall[15] with the Microcon+ control system and Azbil Corporation[16] with the
Harmonas-DEO system. Fieldbus technics have been used to integrate machine, drives, quality
and condition monitoring applications to one DCS with Valmet DNA system.[6]

The impact of COTS, however, was most pronounced at the hardware layer. For years, the
primary business of DCS suppliers had been the supply of large amounts of hardware,
particularly I/O and controllers. The initial proliferation of DCSs required the installation of
prodigious amounts of this hardware, most of it manufactured from the bottom up by DCS
suppliers. Standard computer components from manufacturers such as Intel and Motorola,
however, made it cost prohibitive for DCS suppliers to continue making their own components,
workstations, and networking hardware.

As the suppliers made the transition to COTS components, they also discovered that the
hardware market was shrinking fast. COTS not only resulted in lower manufacturing costs for the
supplier, but also steadily decreasing prices for the end users, who were also becoming
increasingly vocal over what they perceived to be unduly high hardware costs. Some suppliers
that were previously stronger in the PLC business, such as Rockwell Automation and Siemens,
were able to leverage their expertise in manufacturing control hardware to enter the DCS
marketplace with cost effective offerings, while the stability/scalability/reliability and
functionality of these emerging systems are still improving. The traditional DCS suppliers
introduced new generation DCS System based on the latest Communication and IEC Standards,
which resulting in a trend of combining the traditional concepts/functionalities for PLC and DCS
into a one for all solution—named "Process Automation System" (PAS). The gaps among the
various systems remain at the areas such as: the database integrity, pre-engineering
functionality, system maturity, communication transparency and reliability. While it is expected
the cost ratio is relatively the same (the more powerful the systems are, the more expensive they
will be), the reality of the automation business is often operating strategically case by case. The
current next evolution step is called Collaborative Process Automation Systems.

To compound the issue, suppliers were also realizing that the hardware market was becoming
saturated. The life cycle of hardware components such as I/O and wiring is also typically in the
range of 15 to over 20 years, making for a challenging replacement market. Many of the older
systems that were installed in the 1970s and 1980s are still in use today, and there is a
considerable installed base of systems in the market that are approaching the end of their useful
life. Developed industrial economies in North America, Europe, and Japan already had many
thousands of DCSs installed, and with few if any new plants being built, the market for new
hardware was shifting rapidly to smaller, albeit faster growing regions such as China, Latin
America, and Eastern Europe.

Because of the shrinking hardware business, suppliers began to make the challenging transition
from a hardware-based business model to one based on software and value-added services. It is
a transition that is still being made today. The applications portfolio offered by suppliers
expanded considerably in the '90s to include areas such as production management, model-
based control, real-time optimization, plant asset management (PAM), Real-time performance
management (RPM) tools, alarm management, and many others. To obtain the true value from
these applications, however, often requires a considerable service content, which the suppliers
also provide.

Modern systems (2010 onwards)

The latest developments in DCS include the following new technologies:

1. Wireless systems and protocols [17]

2. Remote transmission, logging and data historian

3. Mobile interfaces and controls

4. Embedded web-servers

Increasingly, and ironically, DCS are becoming centralised at plant level, with the ability to log into
the remote equipment. This enables operator to control both at enterprise level ( macro ) and at
the equipment level (micro), both within and outside the plant, because the importance of the
physical location drops due to interconnectivity primarily thanks to wireless and remote access.

The more wireless protocols are developed and refined, the more they are included in DCS. DCS
controllers are now often equipped with embedded servers and provide on-the-go web access.
Whether DCS will lead Industrial Internet of Things (IIOT) or borrow key elements from remains
to be seen.

Many vendors provide the option of a mobile HMI, ready for both Android and iOS. With these
interfaces, the threat of security breaches and possible damage to plant and process are now
very real.
See also

Annunciator panel

Building automation

EPICS

Industrial control system

Plant process and emergency shutdown systems

Safety instrumented system (SIS)

TANGO

References

1. Eloranta, Veli-Pekka; Koskinen, Johannes; Leppänen, Marko; Reijonen, Ville (2014).

Designing distributed control systems: a pattern language approach. Wiley series in software
design patterns. Chichester: Wiley. ISBN 978-1-118-69415-2.

2. D'Andrea, Raffaello (9 September 2003). "Distributed Control Design for Spatially

Interconnected Systems". IEEE Transactions on Automatic Control. 48 (9): 1478–1495.
CiteSeerX 10.1.1.100.6721 (https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.10
0.6721) . doi:10.1109/tac.2003.816954 (https://doi.org/10.1109%2Ftac.2003.816954) .

3. Massiaoni, Paolo (1 January 2009). "Distributed Control for Identical Dynamically Coupled
Systems: A Decomposition Approach" (http://resolver.tudelft.nl/uuid:2a1e3740-454f-4a1e-b
d0d-cda8846eadae) . IEEE Transactions on Automatic Control. 54: 124–135.
doi:10.1109/tac.2008.2009574 (https://doi.org/10.1109%2Ftac.2008.2009574) .
S2CID 14384506 (https://api.semanticscholar.org/CorpusID:14384506) .

4. Stout, T. M.; Williams, T. J. (1995). "Pioneering Work in the Field of Computer Process
Control". IEEE Annals of the History of Computing. 17 (1): 6–18. doi:10.1109/85.366507 (htt
ps://doi.org/10.1109%2F85.366507) .

5. "Group History | Azbil Corporation Info | About the azbil Group | Azbil Corporation (Former
Yamatake Corporation)" (https://www.azbil.com/corporate/company/history.html) .

6. [1] (https://www.valmet.com/automation/control-systems/) Valmet DNA

7. [2] (http://www.abb.com/controlsystems) INFI 90

8. [3] (http://www.abb.com/product/us/9AAC115762.aspx) DCI-4000

9. [4] (http://www.fieldbus.org) Foundation Fieldbus

10. "Foxboro I/A Series Distributed Control System" (https://archive.today/20120712134904/htt
p://iom.invensys.com/UK/Pages/Foxboro_DCSIASeries.aspx) . 2012. Archived from the
original (http://iom.invensys.com/UK/Pages/Foxboro_DCSIASeries.aspx%5d) on 2012-07-
12. Retrieved October 15, 2024.

11. "ABB System 800xA - process, electrical, safety, telecoms in one system" (http://www.abb.c
om/product/us/9AAC115756.aspx) . www.abb.com.

12. [5] (http://easydeltav.com) Emerson Process Management

13. [6] (https://www.energy.siemens.com/hq/en/automation/power-generation/sppa-t3000.ht

m) Archived (https://web.archive.org/web/20180203212221/https://www.energy.siemen
s.com/hq/en/automation/power-generation/sppa-t3000.htm) 2018-02-03 at the Wayback
Machine SPPA-T3000

14. "Siemens - SIMATIC PCS 7 - SIMATIC PCS 7 (SIMATIC, PCS 7, process control system,
SIMATIC PCS7, Add Ons, solutions for industry, process automation, process industry)" (htt
ps://web.archive.org/web/20070329065215/http://pcs.khe.siemens.com/index.aspx?nr=10
75) . Archived from the original (https://pcs.khe.siemens.com/index.aspx?nr%3D1075)
on 2007-03-29. Retrieved 2007-03-29. Simatic PCS 7

15. [7] (http://www.forbesmarshall.com/fm_micro/DCS/Products1.aspx?flag=1&id=dcs&pid=55

1&prodName=Microcon+%20Distributed%20Control%20System(DCS)) Forbes Marshall

16. [8] (http://www.azbil.com) Azbil Corporation

17. F. Foukalas and P. Pop, "Distributed control plane for safe cooperative vehicular cyber
physical systems (https://digital-library.theiet.org/content/journals/10.1049/iet-cps.2019.0
034) ." IET Cyber-Physical Systems: Theory & Applications, Oct. 2019 ).