Distributed Control Systems (DCSs)

Distributed Control Systems (DCSs) are dedicated systems used to control manufacturing
processes that are continuous or batch-oriented, such as oil refining, petrochemicals, power
generation stations, pharmaceuticals, food & beverage manufacturing, cement production, steel
industry, pulp and paper industry. DCSs are connected to the sensors and actuators in the plant,
and use set point control to control/regulate the flow/properties of material through the plant.

A DCS is a combination of hardware (I/O field instruments, terminal panels, computer

subsystems, and operator stations, etc.), networks (network topology, protocols, gateways, data
access control, etc.), and software (monitoring, logging, reporting, and control). The computer
subsystems modules are in fact intelligent microprocessor-based boards where the control
functions are embedded. Normal control functions of an entire plant or a process are thus
distributed among a large number of these local control modules. The local control modules
communicate with the other units in the system on a variety of data communication highway

Evolution of the Distributed Control Systems

In the late 1940s and early 1950s, analog instrumentation hardware was generally based on
pneumatic (air pressure) devices. Large-case (approximately 18 x 18 in.) is used for control and
display. Each instrument was directly connected to a process sensing point and usually located
near that point. As a result, process measurement and control were largely decentralized and the
operator could only view one section of one unit in the operation. With the development of
pneumatic transmission techniques, centralized control became possible, gradually permitting
more control hardware to be placed in one section of a control panel. However, the
instrumentation was still fairly large and was usually dedicated to the display and/or control of
one process variable

The invention of the transistor in 1947 triggered a new revolution in instrumentation. In the late
1950s, the miniaturization trend of the receiver instrumentation continued at a high pace, and its
case size had decreased to 6 x 6 in. and eventually to 3 x 6 in. and 2 x 6 in. standards. Electronic
instrumentation hardware based on transistor technology started to replace pneumatic
instrumentation. This allowed for electronic transmission development and a consequent further
centralization of instrumentation on one control panel. This led to the birth of centralized control
rooms

During the early 1960s, the digital computer was introduced to process control, adding peripheral
hardware to the control room. New interface hardware, such as printers, typewriters, CRT
screens and keyboards, were now introduced to the operator, making the control room scene
more complex, as all of the new hardware was still backed by the conventional analog instrument
panel
During the late 70s and early 80s, a revolution in man-machine interface design philosophy
began, with the introduction of a distributed architecture based on microprocessor hardware, as
illustrated in Figure . This new hardware digitized the usual analog hardware and made
applicable new control modes. It also introduced the communications network into the
conventional analog loop and enabled the return of some decentralization of control to the field,
while at the same time centralizing more information at the main control console(s). Extensive
studies were conducted on the human engineering aspects of information gathering, e.g., the ISA
recommendation
(ISA-RP60.3-1977, revised in 1985) entitled “Human Engineering for Control Centers.” These
studies lead to a new revolution in human interfaces for computer based measurement systems
during the 80s and continuing in the present.
These distributed systems were introduced by most of the major instrument manufacturers;
namely, Honeywell, Inc., Foxboro Corporation, Taylor Instrument Company, the Bristol
Company, Fisher Controls Corporation, EMC Corporation and some others. Honeywell, Inc.’s
“TDC2000” was one of the first introduced (“TDC” stands for Totally Distributed Control). The
system is based on microprocessor hardware configured into a “data highway” network. During
the 1990s, the display station used high technology to enhance the human interface and enable
the operator to supervise larger amount of information. The display is based on the “Windows”
technology, animation, 3D display, icons, mouse pointers, touch screens, videos, and virtual
instruments. A typical control center during 90s is shown in Figure below.

Evolution of Control Panel and Instruments.

Typical Control Center during the 80s and 90s

Different types of DCS architectures

Types of DCS architectures
 Centralized Architecture
 Decentralized Architecture
 Hybrid Architecture
 Redundant Architecture
 Client/Server Architecture
 Centralized Architecture: In a centralized architecture, all control
functions are performed by a central controller. The central controller
communicates with field devices and other subsystems via a
communication network. This architecture is commonly used in smaller
systems where the processing power of a single controller is sufficient.
 Decentralized Architecture: In a decentralized architecture, the
control functions are distributed among multiple controllers. Each
controller is responsible for a specific section of the process. This
architecture is commonly used in larger systems where a single
controller may not have the processing power to control the entire
system.
 Hybrid Architecture: In a hybrid architecture, both centralized and
decentralized control functions are used. The centralized controller
 manages the overall process while the decentralized controllers control
specific sections of the process. This architecture is commonly used
in medium-sized systems where a combination of centralized and
decentralized control is required.
 Redundant Architecture: In a redundant architecture, multiple
controllers are used to provide redundancy and ensure high availability
of the system. If one controller fails, the backup controller takes over
without disrupting the process. This architecture is commonly used
in critical processes where downtime is not acceptable.
 Client/Server Architecture: In a client/server architecture, the control
functions are distributed among multiple servers. Each server is
responsible for a specific task, such as data acquisition or alarm
management. This architecture is commonly used in large systems
where multiple users need to access the system simultaneously.

DCS Architecture
The structure of a DCS is often referred to as its architecture. In terms of functional modules, the
DCSs marketed by the various vendors have a lot in common .This section therefore examines
these functional modules from the point of view of a generic system that is representative of all
manufacturers. Figure illus-trates the architecture of a such a generic system in terms of
functional modules. The key word is functional. The modules do not necessarily represent
physical components; some manufacturers may combine two or more functions in one physical
component.
In addition to the process instruments (such as temperature transmitters, flow-meters, pH
sensors, valves, and so forth), which are common to any process con-trol approach, there are six
generic functional modules:
(1) Input/output or I/O modules scan and digitize the input/ output data the process instruments.
Some may perform elementary simple logic.
(2) The local I/O bus links I/O modules to controller modules.
(3) Controller modules read and update field data as well as performing the control calculations
and logic to make process changes.
(4) User interfaces include operator interfaces and engineering work sta-tions.
(5) The data highway is a plant wide communications network.
(6) Communication modules provide a link between the data highway and
Other modules, typically controller modules and user interfaces.
Input/Output Modules
Input/output modules provide the main interface between the DCS and the process being
controlled. They convert the information provided by the process instruments into digital form.
They also provide signal filtering and contact de- \ bouncing. In some instances, they can also do
alarming, signal characterizing, and low-level logic. Four basic types of signals connect to I/O
modules:
(1) Analog inputs, also called analog ins or AIs
(2) Analog outputs, also called analog outs or AOs
(3) Digital inputs, also called digital ins or DIs
(4) Digital outputs, also called digital outs or DOs
Analog inputs are gradually varying (as opposed to two-position) signals that are typically
connected to sources such as 4–20 mA and 1–5 V DC transmitters, thermocouples, and
resistance temperature detectors (RTDs). Analog outputs are gradually varying signals, usually
4–20 mA, that are typically connected to devices, such as valves, dampers, and variable-speed
motors. Digital inputs are typically connected to two-position devices such as limit switches,
relays, and pulse contacts. Digital outputs are contact openings and closings that operate
controlled devices (such as valves, dampers, and motors) in a
two-position manner.I/O modules are typically designed for varying levels of input/output
loading
(1) A single board connected to a single field device providing single-point integrity
(2) A single board connected to a single input device and a single output device that provides
single-loop integrity
(3) A single board connected to multiple (4, 8, 12, 16, 32) inputs
(4) A single board connected to multiple (4, 8, 16) outputs
(5) A single board connected to multiple inputs and multiple outputs (for example, eight in and
four out)
I/O modules may have separate, individual circuits, or they may share components such as
analog-to-digital and digital-to-analog converters and multiplexers.
Typical features to look for in I/O modules are:
(1) Isolated or nonisolated grounding on a per-point or per-board basis
(2) Level of fusing protection on a per-point, per-circuit, or per-board basis
(3) Accuracy and linearity of the sampling frequency
(4) Protection from electromotive force (emf) and transients
(5) Immunity to radio frequency (rf) interference
(6) Fail-safe positioning
(7) Overload and surge protection
(8) Impedance matching with field devices
(9) Loop feedback sensing
(10) Manual override of loop control
(11) Mean time between failure (MTBF) and mean time to repair (MTTR)
(field values, not theoretical)
(12) Criticality—that is, if the board fails, an indication of what else will be
affected
Systems from different vendors have different redundancy needs based on criticality and
reliability.
With these criteria in mind, one should be able to evaluate the level of reliability I/O modules
provide when one compares various vendors' systems. This will indicate when and where to
apply redundancy at this level.
Local I/O Bus
The local I/O bus provides a bridge between the I/O and controller modules and, by definition, is
restricted in terms of geographical area and data loading. It typically operates at a slower speed
than the plantwide data highway, although communication rates can range from 9,600 to 250,000
to 1 million bitsper second.When evaluating a systemdesign, one is well advisedto consider
redundant I/Omodules as a key requirement.
I/O buses can connect any number of I/O and controller modules. The way inwhich I/O buses
provide communications can also vary, from polling or scanningof the I/O by the controller
modules to serial communications between I/ O andcontroller modules. I/O buses can also be
arranged for serial or parallel communi-cations or a combination of both.While I/O buses are
seldom a bottleneck or a limitation, they become a criticalcomponent if they fail. The loss of a
single I/O bus can affect the control of manyend devices

Controller Modules
Controller modules are the true brains of a DCS. Their primary function is touse continuously
updated information from I/O modules and then perform thecomplex logic and analog loop
calculations needed to produce the controller out-put signals that keep process variables at the
desired values. It is at the controllermodules that many DCS functions, such as the following, are
performed:
(1) I/O signal characterization
(2) Signal filtering
(3) Alarming I/O modules
(4) Ranging and engineering units
(5) Control logic
(6) Control interlocks
(7) Sequencing
(8) Batch control
(9) Passing on trending information
(10) Passing on report information
Controller modules are microcomputers and, as such, have similar limitations.Although the
numbers associated with the various types of controller modules canhave a mesmerizing effect,
not all of these numbers are important in one's evalua-tion of controller module performance.
The key ones are:
(1) available memory for configuration,
(2) available idle time (based on a given scan rate),
(3) I/O loading or criticality,
(4) number of available software addresses for input/output blocks, and
(5) number of available software addresses for control blocks

Communication Modules

Communication modules are also microcomputers, but they differ from con-troller
modules in function. Rather than execute control strategies, communicationmodules
manage the flow of information between the data highway and controllermodules,
user interfaces, and gateways to host computers and PLCs. There is al-ways a physical
limit to the amount of data that communication modules can han-dle. This limit means
that communication modules can at times be the source of abottleneck, particularly
when they are interfacing with numerous third-party ap-plications or coping with the
increased demand for data from PLCs.
Specifying redundant com-munication modules is al-most always a good idea.If
problems do occur, operators should check the communications rate andmemory
capacity. Performance improves if one either decreases the number ofcommunication
modules or decreases the number of devices served by singlemodules. Again, there
should always be room for expansion. Communicationmodules are critical to the
proper operation of a DCS; without them, the operatormay be blind to the process

Real-Time Data Highway

Real-time data highways come in many variations. Topologies can be linear,loop, or

star, and they may or may not include “traffic controllers.” Since a datahighway is a
microprocessor-based module, it should be viewed as considerablymore than one or
two cables strung out across the plant

Communication Modules

Communication modules are also microcomputers, but they differ from controller
modules in function. Rather than execute control strategies, communication modules
manage the flow of information between the data highway and controller modules,
user interfaces, and gateways to host computers and PLCs. There is al-ways a physical
limit to the amount of data that communication modules can handle. This limit means
that communication modules can at times be the source of a bottle neck, particularly
when they are interfacing with numerous third-party applications or coping with the
increased demand for data from PLCs. Specifying redundant communication modules
is almost always a good idea.

If problems do occur, operators should check the communications rate andmemory

capacity. Performance improves if one either decreases the number ofcommunication
modules or decreases the number of devices served by singlemodules. Again, there
should always be room for expansion. Communicationmodules are critical to the
proper operation of a DCS; without them, the operatormay be blind to the process.

Real-Time Data Highway

Real-time data highways come in many variations. Topologies can be linear,loop, or

star, and they may or may not include “traffic controllers.” Since a datahighway is a
microprocessor-based module, it should be viewed as considerablymore than one or
two cables strung out across the plant.If controller modules are the brains of a DCS,
then the data highway is its back-bone.

Interface Displays
The specific configuration of each operator console and the number of consoles required will depend on
the type of plant involved. Regardless of the configuration,however, when the system is powered up, the
first screen displayed isusually the main menu, which can be retrieved at any time during operation.
Interface displays are described in terms of:
(1) display hierarchy,
(2) plant overview displays,
(3) trend displays,
(4) alarm displays, and

(5) graphic displays.

Engineering Workstations
The engineering workstation is used principally to:
(1) configure the database and console,
(2) update and decompile the database, and
(3) implement application software.
Engineering workstations are usually physically separated from the locationof the operator interface. This
permits engineers to work independently before,during, and after the DCS is installed.Engineering
workstations are often put together with the same hardware asthe operator interface, that is, from CRTs,
electronics, keyboards, hard disks, and/or tape drives. The key difference between the workstation and the
operator interfaceis the software. Thus, an engineering workstation could be used as an operatorinterface
if it had the proper operator interface software.The engineering workstation is typically used off line.
However, with theright software it can be used on line as a diagnostic tool. In general, however, the
engineering and operator functions are separated, even by placing the workstationsin different physical
locations. This is to minimize any potential interference by the engineering workstation in the day-to-day
running of the plant

Selecting a Distributed Control System

 When selecting a Distributed Control System (DCS), consider factors
like functionality, scalability, compatibility, reliability, security, cost, vendor
reputation, and the specific needs of your process.

Here's a more detailed breakdown of key factors:

1. Process Requirements & Functionality:

 Process Complexity:
Determine the complexity of your process and the level of automation required.
 Control Loops:
Consider the number of control loops and the type of control algorithms needed
(e.g., PID, advanced control).
 Data Acquisition & Logging:
Evaluate the need for real-time data acquisition, historical data logging, and
reporting capabilities.
 HMI (Human-Machine Interface):
Ensure the DCS offers a user-friendly HMI for monitoring and control.
 Specific Industry Needs:
Consider any industry-specific regulations or standards that the DCS must comply
with.
2. Scalability & Flexibility:
 Future Growth:
Ensure the DCS can scale to accommodate future expansion and changes in your
process.
 Modularity:
Look for a modular system that allows for easy addition or removal of components.
 Integration:
Consider the ability to integrate the DCS with other systems (e.g., PLCs, SCADA,
ERP).
3. Reliability & Performance:
 Hardware Robustness:
 Evaluate the reliability and robustness of the DCS hardware, especially for critical
applications.
 Software Stability:
Ensure the DCS software is stable and reliable, with minimal downtime.
 Redundancy:
Consider the need for redundancy in critical components to ensure continuous
operation.
 Performance:
Assess the DCS's ability to handle the required processing load and control loop
performance.
4. Security:
 Network Security:
Ensure the DCS has robust security features to protect against unauthorized access
and cyber threats.
 Access Control:
Implement proper access control mechanisms to restrict access to sensitive data and
functions.
 Data Integrity:
Ensure the DCS can maintain the integrity of process data and prevent accidental or
malicious manipulation.
5. Cost & Vendor Support:
 Total Cost of Ownership (TCO):
Consider not only the initial purchase price but also ongoing maintenance, support,
and training costs.
 Vendor Reputation:
Evaluate the vendor's reputation for quality, reliability, and customer support.
 Support & Training:
Ensure the vendor provides adequate support and training for your personnel.
 Service and Support:
 Consider the vendor's ability to provide timely and effective support in case of issues
or failures.

6. Other Considerations:
 Expertise:
Ensure your team has the necessary expertise to implement, maintain, and
troubleshoot the DCS.
 Open Architecture:
Look for a DCS with an open architecture that allows for integration with other
systems and technologies.
 Future-Proofing:
Consider the long-term viability of the DCS and its ability to adapt to future
technologies and standards.

Evolution of Communication /siganal Standards

In 1993, the HART Communications Foundation developed a standard protocolfor superimposing digital
information on a conventional 4-to-20 mA analogsignal. This breakthrough in technology expanded
communications between devicesand the control system. Simultaneously, major device suppliers began
sellingsmart devices at the same price as analog devices. The HART protocol made itpossible to precisely
measure analog sources and digitally communicate the informationto the control system. Additional
functionality—such as identifying multipleensor types, measurement variables, product information, and
diagnosticissues—produced a wealth of information from these smart devices. Process manufacturers
immediately began reporting increases in reliability, accuracy, and stabilityusing HART devices rather
than conventional analog instruments. The rapidacceptance of this new technology was the impetus for
the continued developmentof digital process technology.

HART Communication Protocol

HART is an acronym for "Highway Addressable Remote Transducer." HARTwas developed by

Rosemount Inc. in the mid-80s, but has been made completelyopen, and all rights now belong to
the independent HART CommunicationFoundation, www.hartcomm.org. It is widely accepted in
the industry as the defactostandard for digitally enhanced 4-20mA communications with smart
fieldinstruments. The HART protocol was designed specifically for use with
intelligentmeasurement and control instruments, which traditionally communicate using 4-20mA
analogue signals. HART preserves the 4-20 mA signals and enables two-waydigital
communications to occur without disturbing the integrity of the 4-20mAsignals. The HART
protocol permits the process variable to continue to betransmitted by the 4-20 mA analogue
signal, and additional information pertaining toother variables, parameters, device configuration,
calibration, and device diagnosticsto be transmitted digitally at the same time.The HART
Protocol uses the Open Systems Interconnection (OSI) referencemodel as a guide. Traditionally,
it implements only layers 1,2 and 7, i.e., thephysical, data link and application layers; however,
the recent versions, includingwireless HART, allow forthe implementation of layers 3 and 4of
the OSI referencemodel.

The HART Physical Layer

The physical layer makes use of the Bell 202 Frequency Shift Keying (FSK)standard to
superimpose digital communication signals at a low level on top of the 4-20 mA, as shown in
Figure7.1. The HART protocol communicates at 1200 bpswithout interrupting the 4-20 mA
signal, and allows a host application (master) to gettwo or more digital updates per second from
a field device. As the digital FSK signalis phase continuous, there is no interference with the 4-
20 mA signal.
HART Data Link Layer (DLL)
The DLL is responsible for the reliable transmission of data packets across thenetwork. HART is
a master/slave, character oriented, protocol which means that afield (slave) device can only
speak when spoken to by a master. In normal use, afield device only replies when it is spoken to.
There can be two masters; for example,a control system as a primary master and a handheld
HART communicator as asecondary master. Timing rules define when each master may initiate
acommunication transaction
The HART Application Layer
The HART application layer (OSI layer 7) consists of three classes ofcommands or messages:
Universal Commands, Common Practice Commands, andDevice Specific Commands.
Theapplication layer defines the semantics of thesemessages and commands. The application
layer services and interoperability ofHART technology are established in IEC Standards(IEC
61158 Application Layer Services).
HART User Layer
Like most of the field buses, HART defines a layer above the OSI layer 7, called the user layer.
User layer defines a set of classes for the automation devices and predefined functions. Examples
of these predefined functions are known as function blocks, and device classes are known as
profiles. Function blocks are specified in the IEC 61804 series and 61499, while profiles are
described in the “IEC 61784-1 Communication Profile.”
A fieldbus
Fieldbus is the highest-level digital communications technology. Fieldbus is based on an open
architecture, which means that smart devices from multiple suppliers connect to each other and to the
digital automation system. This interoperable, bidirectional communications medium surpasses other bus
technologies because it can process variables, configure, control, calibrate, and pass a multitude
of historical and predictive maintenance data. Fieldbus, with its high data throughput, relatively simple
installation, and advanced capabilities is helping process manufacturing increase plant performance while
lowering overall costs.

is a control network used in process control and industrialautomation. Fieldbuses are bi-
directional, digital serial networks that offer services at layers 1 and 2 of the OSI model (physical
and data link). Some fieldbuses offer services at layer 7 as well. Examples of fieldbus networks
are FOUNDATION mfieldbus, DeviceNet, and PROFIBUS. In the 1990s, fieldbuses began to
replace the parallel wiring used in 4-20 mA and +/-10 volt analogue interfaces. There are many
available industrial networks designed to meet differing application requirements. For example, a
simple on/off switch on a conveyor belt has different communication requirements than a
complex control valve in a petroleum refinery. It is important to understand the target application
of a network in order to choose the right network for a given application. Fieldbus is an industrial
network system for real-time distributed control. It is a way to connect instruments and
intelligent devices in a manufacturing plant. As the electronic and microprocessor technology
becomes more powerful and less expensive, the sensors and actuators become smarter with
functionalities beyond their primary measurement or actuation function. Such smart devices
require digital communication means to benefit from these additional functionalities as self-test,
alarms, configuration, local control loops, diagnostics and calibration capabilities. Fieldbuses
enable us to benefit from these device capabilities. The 4-20 mA and RS422 are point-to-point
communication schemes, which require that each device has its own communication link to the
control room, while the fieldbus is the equivalent of the current LAN-type connections, which
allow multiple of analogue and digital points to be connected at the same time. Some Fieldbuses
work on network structures which allow daisy-chain, star, ring, branch and tree network
topologies. This flexibility reduces both the length and number of cables for any given
automation application. Furthermore, since devices that communicate through fieldbus have
embedded microprocessors, multiple measurement points and functionalities are typically
provided by the same device.

The following sections introduce some of these industrial networks.

PROFIBUS (Process Field Bus)

PROFIBUS (Process Field Bus) is one of the leading open fieldbus systems in Europe, and is
widely used worldwide in manufacturing, process industry and building automation. The
PROFIBUS architecture is traditionally divided into three compatible variants, as depicted in
Figure
1. PROFIBUS DP (DP = Decentralized Periphery, for rapid cyclic data traffic for discrete
automation )
2. PROFIBUS FMS (FMS = Fieldbus Message Specification, for asynchronous
data traffic with large amounts of data)
3. PROFIBUS PA (PA = Process Automation requiring fieldbus power and
Intrinsic safety)
These three variants were designed to meet a variety of application
requirements. PROFIBUS can be used for both high-speed, time-critical data transmission
between controllers and I/O, and for complex communications between programmable
controllers.
PROFIBUS was defined during 1991-1993 in DIN 19245, and was included in EN 50170 and
IEC 1158-2 in 1996. Since 1999, it has become IEC 61158/IEC 61784.PROFIBBUS technology
is developed and administered by the PROFIBUS User Organization
(http://www.profibus.com/home/), with a membership of more than 600 manufacturers, users
and research institutions. PROFIBUS currently features five different transmission technologies,
all of which are based on international standards:RS485/RS485-IS, MBP/MBP-IS(“IS” stands
for intrinsic safety protection) and fiber optics.
 Important Features of DCS

The main features of the distributed control system are:

 Management of complicated processes

 System redundancy
 Numerous pre-defined functional blocks – DCS provides various algorithms, many
standard application libraries, pre-defined and pre-tested activities to handle huge
systems
 More advanced HMI design allows to manage and monitor complex systems and also this
functions as a centralized system of the entire DCS.
 Enhanced scalability – The DCS structure allows more flexibility which can be used for
any range of server systems
 System protection

Comparison between DCS and PLC

To know clearly on DCS, one has to know how DCS is varied from PLC.

DCS PLC

With the prevailing function blocks, custom logics are To create custom logic, a high level of programming

created languages are used

There is more probability of system redundancy Redundancy is not that much required
 There must be provisions for the integration of functions
The whole system acts as one complete solution
into one single architecture

Most of the algorithms are complicated and there will be

This requires customized routines
no variation across the applications

It has simple to advanced PID and even sophisticated

PLC has simple PID only
process controlling

These are the crucial differences between the distributed control systems and PLC systems.

Advantages of DCS

The advantages of the distributed control system are:

 Minimal engineering time

 DCS shows a possibility of batch management
 The system needs reduced troubleshooting
 OPC server
 The system itself drives to enhanced organization and reliability
 Included with faceplates and HMI graphics
 Superfluous functional system servers

Applications of Distributed Control System

The processors where the DCS is employed are:

 Nuclear power plants, chemical, and petrochemical, metallurgical plants

 Automobile engineering
 Food processing industries
 Pharmaceutical industry
 Water handling and sewage plants
 Environmental management systems
Yokogawa CENTUM 3000
Yokogawa CENTUM 3000, and more recently CENTUM VP are widely used

DCSs in the process industry providing outstanding functionality, flexibility,

scalability and reliability.

Yokogawa Distributed Control System (DCS)

Figure 9.1(a) Yokogawa CENTUM FCS. Figure 9.1(b) Yokogawa HIS of CENTUMVP.

System Overview

The CENTUM 3000 or CENTUM VP is a scalable open application DCS

available for Microsoft Windows operating systems that can run several application packages
from Yokogawa as well as from third parties, enabling selection of any application software to
match the process needs. The CENTUM 3000 or CENTUM VP provides workstations standards-
based control and I/O, close coupling to safety nsystems, networking application software, and
measuring instruments.

Typical features are:

 Control bus: Ethernet/TCP/IP

 Enterprise information: Ethernet/TCP/IP

 Redundant Fieldbus to remote I/O

 Instrument bus: Intelligent field device integration (e.g., HART, Foundation

Fieldbus, Profibus, etc.)

 Dual/redundant communication at all levels of the system

434 Modern Distributed Control Systems

 Reliable engineering software packages.

 Yokogawa’s Enterprise Technology Solution integrates both factory and

business, allowing management to improve profits.

 The HISplatform can be used in any general purpose PC, Figure 9.1(b).

 OPC for interfacing with supervisory computers and other application

servers.

 CENTUM, Figure 9.1(a), can also integrate other types of sub system.
9.2.2 CENTUM CS 3000 System Key Specifications:

 The number of tags that can be monitored is 100,000 (expandable up to

1,000,000 tags).

 The number of stations that can be connected is 256 stations (max.16

domains,64 stations per domain);however, HIS is limited to a maximum of 16

stations/domain.

 A domain is a logical V-net bus segment. A bus converter can be used to link CENTUM CS
3000 domains, or link to previous systems (e.g., CENTUM CS

1000).

 The V net real-time control system bus links stations such as FCS, HIS,BCV

and CGW.

 Dual redundant V-net support is standard.

 Ethernet is used to link HIS, ENG and supervisory systems. It is also used for transferring
data files to supervisory computers.

 CENTUM CS 3000 and CENTUM VP support connections toFOUNDATION Fieldbus.

They have easy function configuration; theirengineering functions are designed for efficient
engineering and ease to use.

 The existing CENTUM CS 1000 can easily be migrated to the CENTUM CS3000 system.

 The Yokogawa system guarantees data updates every second in the HIS, even with a
1,000,000 tag project.

 Vnet/IP offers one millisecond time synchronization among all stations onVnet/IP.

CENTUM CS 3000 Components

A typical CENTUM configuration is shown in Fig. The following is ashort description of the
main components:

 The Human Interface Station (HIS) is mainly used for operation and435

monitoring, it displays process variables, control parameters and alarms. It also incorporates
open interfaces so that supervisory computers can access trend data, messages and process data.
 Console type HIS: This is a console type human interface station at which a general purpose
PC is installed. There are two types of console type Hiss, one is enclosed display style and
another is open display style. The console type HIS is composed of a console assembly and a
general purpose PC. It is a new type of HIS that can utilize the latest PC technology, while
succeeding the operability and functionality of the DCS.

 Desktop type HIS: This HIS uses a general purpose PC.

 The Field Control Station (FCS) controls the plant. There are two models ofFCS; namely,
the FCS for Field network I/O (FIO) and the FCS for Remote/O (RIO). In addition to the above
models, there is the compact type FCS