Content deleted Content added
m Reverted edits by 2409:4072:908:454A:DCB2:9BFE:C386:3554 (talk) (HG) (3.4.6) |
m Updated Reference 11 due to original link not being valid/available anymore. (ABB's website has been completely restructured.) |
||
(48 intermediate revisions by 39 users not shown) | |||
Line 1:
{{Use British English|date=February 2018}}▼
{{Short description|Computerized control systems with distributed decision-making}}
▲{{Use British English|date=February 2018}}
{{Manufacturing}}
A '''distributed control system''' ('''DCS''') is a
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 [[SCADA|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 necessarily geographically remote. Many machine control systems exhibit similar properties as plant and process control systems do.<ref>{{Cite book |last=Eloranta |first=Veli-Pekka |title=Designing distributed control systems: a pattern language approach |last2=Koskinen |first2=Johannes |last3=Leppänen |first3=Marko |last4=Reijonen |first4=Ville |date=2014 |publisher=Wiley |isbn=978-1-118-69415-2 |series=Wiley series in software design patterns |___location=Chichester}}</ref>
==Structure==
[[File:Functional levels of a Distributed Control System.svg|thumb|500px|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;
Line 18:
* 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.
Line 26:
===Technical points===
[[File:Smart current loop positioner.png|thumb|Example of a continuous flow control loop. Signalling is by industry standard 4–20 mA current loops, and a "smart" [[control valve|valve positioner]] ensures the [[control valve]] operates correctly.]]
The processor nodes and operator [[graphical user interface|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 signal
DCSs are connected to sensors and actuators and use [[Setpoint (control system)|setpoint control]] to control the flow of material through the plant.
Large oil refineries and chemical plants have several thousand I/O points and employ very large DCS.
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,
Modern DCSs also support [[Artificial neural network|neural networks]] and [[fuzzy logic]] applications. Recent research focuses on the synthesis of optimal distributed controllers, which optimizes a certain [[H-infinity methods in control theory|H-infinity]] or the H 2 control criterion.<ref>{{Cite journal
==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 plant]]s
* [[Petrochemical]]
* [[Pulp and
* Boiler controls and [[power plant]] systems
* [[Nuclear power
* [[Environmental control
* [[Water management]] systems
* [[Water treatment]] plants
* [[Sewage treatment]] plants
* Food and [[food processing]]
*
* Metal and mines
* [[Automobile manufacturing]]
* [[Metallurgical]] process plants
* [[Pharmaceutical]] manufacturing
* [[Sugar refining]] plants
* [[Agriculture]]
==History==
Line 68:
===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
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.
Line 88:
}}</ref>
In 1975, both [[Yamatake-Honeywell]]<ref>{{Cite web|url=https://www.azbil.com/corporate/company/history.html|title = Group History | Azbil Corporation Info | About the azbil Group | Azbil Corporation (Former Yamatake Corporation)}}</ref> 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
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 DC<sup>2</sup> system and [[Bailey Controls]] the 1055 systems. All of these were DDC applications implemented within minicomputers ([[Digital Equipment Corporation|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.
Line 95:
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<ref>[http://www.fieldbus.org] Foundation Fieldbus</ref> today.
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
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 [[programmable logic controller|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<ref>
===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|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 Automation|Rockwell]] PlantPAx System, [[Honeywell]] with [[Experion]] & Plantscape [[SCADA]] systems, [[
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.
Line 122:
The latest developments in DCS include the following new technologies:
# [[Wireless]] systems and protocols <ref>F. Foukalas and P. Pop, "[https://digital-library.theiet.org/content/journals/10.1049/iet-cps.2019.0034 Distributed control plane for safe cooperative vehicular cyber physical systems]." IET Cyber-Physical Systems: Theory & Applications, Oct. 2019 ).</ref>
# [[Remote data transmission|Remote transmission]], logging and data historian
# Mobile interfaces and controls
# [[Embedded HTTP server|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,
Many vendors provide the option of a mobile HMI, ready for both [[Android (operating system)|Android]] and [[iOS]]. With these interfaces, the threat of security breaches and possible damage to plant and process are now very real.
Line 137:
* [[Building automation]]
* [[EPICS]]
* [[Industrial control system]]
* [[Plant process and emergency shutdown systems]]
* [[Safety instrumented system|Safety instrumented system (SIS)]]
* [[TANGO]]
|