Fundamentals of

Distributed Control
Systems / Digital
Automation Systems

Helen Beecroft
Jim Cahill

Extracted from
Fundamentals of Industrial Control, 2nd Edition
Copyright 2005
ISA – The Instrumentation, Systems, and Automation Society

This file is copyright protected and no authorization is granted for resale or distribution.
Original purchaser is authorized to print one copy for personal use.
8
Distributed Control
Systems / Digital
Automation Systems

I n broad terms, instrumentation can be divided into two groups—primary and

secondary. Primary instrumentation consists of the sensors and final control ele-
ments that are located near the process being controlled. This is an area in which
quiet improvements occur continuously. Secondary instrumentation is essentially
what one sees in a control room: the equipment used to indicate, alarm, record,
and control.
Indicating, alarming, and recording support the principal function, which is
controlling. In a continuous process environment, control in its simplest terms
means keeping the process variable equal to the set point. In a batch process envi-
ronment, control means keeping the process variable equal to the set point as well
as ensuring that all physical events are synchronize with the sequence of events of
the process recipe. Advanced control means determining correct set points or an
ideal process recipe. If the control system design ensures that the right set points
are being effectively maintained, then consistent and efficient process perfor-
mance is the result.
Tremendous technological advances in hardware and software have enabled
process automation system suppliers to move far beyond systems based on 4–20
mA signals and proprietary communications. Microprocessors now can be em-
bedded virtually anywhere, delivering information not previously available in the
eras of the PLC or the distributed control system (DCS). Today’s digital automa-
tion systems (DAS) are unprecedented in speed, scope and scale.

Introduction
The technological advances in instrumentation that have improved the perfor-
mance of conventional control applications include the following:
(1) Pneumatic telemetry permitted the birth of centralized control rooms.
(2) Electronic analog controls improved accuracy and allowed control pan-
els to be arranged more compactly.

1
Distributed Control Systems / Digital Automation Systems

(3) Digital technology (minicomputers) introduced sophisticated and

advanced controls, which made it possible to do logical alarming and
indication through CRTs.
(4) Distributed control systems (DCS) initially lowered installation costs
because DCS enabled control modules to be interconnected and
grouped, lowered maintenance costs, improved system reliability, and
made it easier to configure the process concept and expand the system.
(5) Today’s digital automation systems are built using:
• accepted industry standards
• totally interoperable architecture
• the communications architecture and bandwidth to support the vast
intelligence found within digital devices
• comprehensive batch solutions
• embedded advanced control
• OPC, XML, and web services to integrate the process with the global
enterprise
• software to facilitate the migration from existing DCS/PLC systems
to DASs.
Figure 8-1 shows other key developments and illustrates the general progres-
sion of industrial control from its mechanical regulator beginnings to
state-of-the-art distributed control systems and digital automation systems.

Figure 8-1. Industrial Control from Mechanical Regulator to DAS [Ref. 1]

2
 Introduction

Overview
Because of its complete dependence on computer technology, the DCS or
DAS is clearly software intensive. Consequently, practitioners cannot neglect the
software aspect. Nevertheless, we will not discuss advanced computer-related top-
ics such as artificial intelligence, management information systems, optimization,
simulation, and modeling in any great detail in this chapter. The implementation
of advanced computer capabilities varies widely not only in terms of the way such
capabilities are used but where and why they are used. Which specific choices are
selected depend on the philosophy and operating needs of the individual plant.
Most DCSs or DASs provide similar capabilities in a comparatively cost-ef-
fective way for a given project. However, they may vary greatly in terms of cost
of ownership. Simple things such as the ease with which the system can be started
up (and restarted after a shutdown) may have profound effects on the overall cost
of a DCS or DAS project. Adding a seemingly small number of extra modules or
even a software upgrade can double project costs and delay startup. A DCS or
DAS purchase requires careful evaluation and planning for the future.
Other factors, such as site preparation costs, ease of expansion, product obso-
lescence, the upgradability of hardware and software, backward and forward sys-
tems’ compatibility, maintenance, training, and integratibility with other
computers, are important issues when evaluating any DCS or DAS.
DCSs and DASs can also vary widely in terms of reliability and availability.
Some suppliers offer proven, off-the-shelf products; some products are still in the
developmental stage. Software that is continually promised but never delivered
has come to be known as “vaporware.” “Vendor support requirements” is a term
for how much an owner can do alone before returning it to the vendor to do. Any
of these factors could make the difference between an easily implemented,
cost-effective computer system and a financial “black hole.” Often, apparently
low-cost systems turn into overbudget problems because the right questions were
not asked in the beginning.
Thus, this chapter presents DCS and DAS basics in a broader scope, from
hardware and software to startup, expansion, maintenance, upgrades, and purchas-
ing strategies. We do this in acknowledgement of the fact that a DCS or DAS is a
long-term, living investment rather than simply a one-time computer purchase.
We conclude this chapter by focusing on solutions for migrating from legacy sys-
tems to a digital automation system.

DCS Defined
As implied by its name, a distributed control system is one whose functions
are distributed rather than centralized. A DCS consists of a number of micropro-
cessor-based modules that work together to control and monitor a plant's opera-
tions. The modules are distributed geographically. This reduces field-wiring and
installation costs. It also reduces risk by distributing the control function through-
out a number of small modules rather than concentrating it in one large module.
A DCS is a computer network. It differs from an office or personal computer
network in that a DCS does real-time computer processing rather than the transac-
tional processing performed by business computers. The difference between real-
time and business computers is the way they execute their programs.
Business computers typically do a single program operation at a time. The
program will start with some fixed data, perform a complex set of calculations,
and provide a set of results. Once the program has done its job, it stops until it is
instructed to run again with new data. An example would be the monthly process-
ing of invoices by a utility company.
The real-time computer also executes its program by using fixed data, per-
forming calculations, and providing a set of results. The difference, however, is

3
Distributed Control Systems / Digital Automation Systems

that it runs the same program repeatedly with updated data, sometimes several
times a second.
A simple example of a real-time operation is the computerized cruise control
on a car. For example, assume the speed set point is 100 kph (62 mph). The real-
time computer continuously scans the car's actual speed. If the actual speed is
lower, say 90 kph (56 mph), the computer will increase the speed by calculating
how much more fuel to inject into the engine and then executing that increase.
Similarly, if the measured speed were higher, say 110 kph (68 mph), the computer
would decrease the fuel intake.
It makes tiny incremental adjustments several times a second by scanning the
actual speed, comparing it to the set speed, and recalculating the fuel require-
ments. A DCS does exactly the same repetitive scanning and recalculating for
hundreds or even thousands of devices throughout a plant.

Basic DCS Functions

The DCS, like the programmable logic controller, is connected to primary
control elements such as temperature and pressure transmitters, flowmeters, gas
analyzers, pH and conductivity sensors, weigh scales, contact switches, valves
and motors, and so on. From these field devices it receives electrical signals, for
example, 4–20 mA, 1–5 V DC, 24 V AC, and 120 V AC. The DCS converts these
signals (digitizes them). Once converted, they can be used by the computer to:
(1) control loops,
(2) execute special programmed logic,
(3) monitor inputs,
(4) alarm the plant operations,
(5) trend, log, and report data, and
(6) perform many other functions.

Field signals are divided into two basic categories—analog and discrete. Ana-
log signals are continuously variable; they act like the dining room dimmer, which
can gradually change the lighting intensity in the room. Discrete signals can have
only two values or positions and are thus called two-position, on-off, or snap-act-
ing. They are often associated with contact devices, such as the light switch in a
home. There is no “in between” with discrete devices—they are either open or
closed, true or false, on or off.
Analog loop control often involves simply maintaining a process variable
(such as temperature or pressure) equal to a set point. It is like the cruise control
maintaining its set speed. Of course, many different types of control loops (feed-
forward, lead-lag, cascade, etc.) are being executed in a DCS, but simple, set
point-maintaining loops often account for the bulk of them.
Discrete control very often consists of simple logic statements coupled with
field sensors to provide logic interlocks or process sequences. For example, con-
sider a tank that is filled with a liquid and then heated. To protect the product and/
or equipment one could use a logic interlock that says:
(1) IF the level is below a minimum point,
(2) THEN the heater coil cannot be turned on (or must shut off).

The process might also call for the liquid to be stirred with an agitator. The
previous logic interlock could be coupled with sequencing logic that says:

4
 Introduction

(1) First, fill tank.

(2) Second, turn on heater.
(3) Third, start agitator.
(4) Fourth, empty tank.

In the sequence, the second step cannot take place until the first is completed.
Likewise, the third step cannot start until the second step is completed and so on.
By adding the IF-THEN logic interlock, if the level should ever drop below the
minimum level, the heater would still trip off.

The Role of the Computer in DCS

Because a DCS is computer-based and all its information is in digital form, it
can easily combine analog control loops with discrete logic (interlocks and se-
quences). The previous example in which sequencing and logic were used to con-
trol the heating and stirring of a liquid in a tank could also incorporate an analog
loop to maintain a constant temperature in the liquid. As illustrated in Figure 8-2,
all functions would execute simultaneously.

Figure 8-2. Control of Stirred Liquid in a Tank

A DCS can involve as few as a hundred inputs, outputs, control loops, and
logic interlocks or tens of thousands of them. It can scan all the primary elements
or sensors, characterize the input signals and alarm them, recalculate loop param-
eters and execute logic, and then send the results to motors and valves throughout
the plant. It constantly reevaluates the status of the plant and makes thousands of

5
Distributed Control Systems / Digital Automation Systems

incremental decisions in fractions of a second. It is capable of all this and more for
two main reasons:
(1) A DCS is made up of many independent control modules that can oper-
ate simultaneously and independently.
(2) It has the ability to carry out rapid communications between these and
other modules by means of a communications link called a real-time
data highway.

Multiple, high-speed, incremental control adjustments permit close and coor-

dinated plant control that results in more consistent production. This close control
provides a plant with the means to fine-tune the process (for example, to accom-
modate variations in feedstock). It also provides the means to maintain a more
consistent product within process areas, thereby minimizing the amount of com-
pensating done downstream. A more consistent product means fewer rejects and a
more efficient operation.
Close control is only the first step toward efficient production. Many plants
find that their process units need to make adjustments not only for varying feed-
stock characteristics but also for changing end product requirements and varying
operating techniques. To keep track of and coordinate all these fluctuating cir-
cumstances, a DCS incorporates extensive capacity for communications, data
storage, and data retrieval. This, then, is another key DCS function, because it en-
ables plant personnel to make the right decisions by supplying information that is
both accurate and timely.
Most DCSs are capable of rapidly displaying process information and storing
it to be retrieved, reviewed, and analyzed at a later date. Typically, this informa-
tion would be used by all the departments in the plant, from process engineering
and maintenance to production and plant management. A good DCS provides the
appropriate personnel with quick and easy access to the appropriate information.
Being computer-based, the DCS also offers intelligent alarm management. It
can force the operator to focus on the most important alarm, thus allowing him or
her to respond more appropriately to the situation. Some alarm functions include
the ability to:
(1) filter out nuisance alarms,
(2) recalculate alarm limits,
(3) re-alarm lingering alarms, and
(4) prioritize alarms.

DCS and Expert Systems

To reduce costs and improve performance, DCS manufacturers are incorpo-
rating many enhancements introduced by the computer industry:
(1) Higher-resolution CRTs
(2) Third-party HMIs integrated into the standard DCS architecture
(3) Migration of proprietary operating systems, applications, and networks
to the more open standards available on the market today
(4) Better networking between the control areas of complex processes
(5) Gigabyte memory chips

6
 DCS Architecture

(6) Enhanced algorithms to continuously tune loops and assure that every
loop performs optimally
(7) Many more state-of-the-art technologies applied to solve classic instru-
mentation problems

The most important DCS enhancement, however, is a product of the great

strides made by the computer industry in artificial intelligence (AI), particularly
expert systems. Expert systems have already shown tremendous potential not only
as a diagnostic tool but as a development aid for the control engineer.
Expert systems are attractive because they clone the knowledge of a small
number of experts and then make it usable by a large number of nonexperts. This
is particularly applicable in the control industry. Control systems are usually oper-
ated in the automatic mode because efficient operation in the manual mode is de-
pendent on the skills of a particular operator. Some operators are more effective
than others.
Expert systems that capture the expertise of the most skilled operators can al-
low less-skilled operators to perform their tasks with considerably increased profi-
ciency. Such a technique can be used to optimize startups, optimize grade changes
in a process, improve overall plant performance and execute emergency shut-
downs.

DCS Architecture

Overall Structure
The structure of a DCS is often referred to as its architecture. In terms of func-
tional 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 8-3 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 worksta-
tions.
(5) The data highway is a plantwide communications network.
(6) Communication modules provide a link between the data highway and
other modules, typically controller modules and user interfaces.

Each DCS vendor has a proprietary approach, and it is possible, for example,
for the functions of control and I/O to be combined in the same physical compo-

7
Distributed Control Systems / Digital Automation Systems

Figure 8-3. Architecture of a Generic DCS

nent. Nevertheless, it is still possible, even preferable, for a DCS to be described

by means of the generic functional modules.

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 de-
vices, 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 clos-
ings 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,
for example:

8
 DCS Architecture

(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 compo-
nents 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

With these criteria in mind, one should be able to evaluate the level of reliabil-
ity I/O modules provide when one compares various vendors' systems. This will Systems from different ven-
indicate when and where to apply redundancy at this level. dors have different redun-
dancy needs based on
criticality and reliability.
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 bits per sec-
ond.
I/O buses can connect any number of I/O and controller modules. The way in
which I/O buses provide communications can also vary, from polling or scanning When evaluating a system
of the I/O by the controller modules to serial communications between I/ O and design, one is well advised
to consider redundant I/O
controller modules. I/O buses can also be arranged for serial or parallel communi- modules as a key require-
cations or a combination of both. ment.
While I/O buses are seldom a bottleneck or a limitation, they become a critical
component if they fail. The loss of a single I/O bus can affect the control of many
end devices.

9
Distributed Control Systems / Digital Automation Systems

Controller Modules
Controller modules are the true brains of a DCS. Their primary function is to
use continuously updated information from I/O modules and then perform the
complex 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 controller
modules 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 can
have 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.

When sizing and selecting a DCS, it is vitally important to ensure that there is
enough processing power not only to serve the active I/O and control functions
but also to provide some spare capacity for future I/O expansion, additional logic,
and extra things such as totalizers. This is an important consideration because
adding this processing power after the fact doubly penalizes the owner. First, there
is the added cost of the extra modules and other associated equipment, such as
communication modules, power supplies, and cabinets. This added cost is often
determined on a noncompetitive basis and is, therefore, higher than it would have
been if purchased as part of the initial contract.
The second penalty is inferior performance as a result of the extra loading put
on the original and the new controller modules, the communication modules, and
the data highway. This extra loading is the result of controller modules doing link
communications instead of simple control. Link communications are those that
pass high volumes of information between control processors. Such communica-
tions consume large amounts of memory and scan time in the associated controller
and communication modules. This loads the data highway. A simple way to avoid
this potentially reduced performance is to specify suitable values of I/O loading,
memory usage, and idle time for controller modules. For example, for a given
scan cycle (1/4, 1/2, or 1 s on average), one can specify the amount of spare mem-

10
 DCS Architecture

ory and idle time to be available in the controller module after the I/O and control
functions are executes. Spare memory and idle time should normally range from
20 percent to 60 percent, depending on the application. Limiting the number of
I/O and control functions that a controller module executes is a good idea for three
reasons:
(1) It ensures the availability of the microprocessor power needed to carry
out the specified functions and thereby simplifies configuration engi-
neering.
(2) It allows for easier, more flexible future expansions and reduces the risk
of link communications.
(3) It reduces the criticality of any given controller module by limiting the
number of I/Os and loops controlled, thus limiting the damage caused
by failure of the module.

Communication Modules
Communication modules are also microcomputers, but they differ from con-
troller 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 han-
dle. This limit means that communication modules can at times be the source of a
bottleneck, particularly when they are interfacing with numerous third-party ap-
plications or coping with the increased demand for data from PLCs.
If problems do occur, operators should check the communications rate and
memory capacity. Performance improves if one either decreases the number of Specifying redundant com-
communication modules or decreases the number of devices served by single munication modules is al-
most always a good idea.
modules. Again, there should always be room for expansion. Communication
modules are critical to the proper operation of a DCS; without them, the operator
may 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 data
highway is a microprocessor-based module, it should be viewed as considerably
more 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. It is an active component through which pass the system's messages and file
transfers, all in real time. Countless times each second, it updates the consoles,
gateways, and other modules connected throughout the system. It is probably one of the
most critical DCS modules because it is common to all other plantwide components. If the
data highway should fail, operators are cut off from the process, link communications are
lost, and process control is affected. The data highway is the one DCS component that
should almost always be made redundant. In this case, redundant does not mean one high-
way is active and one is a hot standby. It means that both highways are active, which per-
mits a bumpless transfer between highways without the need for human intervention. If
traffic directors are part of a data highway, they should also be made redundant.

The following are the principal issues to be addressed when evaluating a DCS
data highway:
(1) Synchronized versus nonsynchronized
(2) Deterministic versus nondeterministic

11
Distributed Control Systems / Digital Automation Systems

(3) Token-passing versus report-by-exception

(4) Variation in protocol types (most are proprietary)
(5) Peer-to-peer versus collision-detection-based communications
(6) Speed of data transmission
(7) Maximum transmission distance

The evaluation of the security and reliability of a data highway is not straight-
forward because many factors are involved. Most importantly, speed isn't every-
thing. Other key factors are module highway access, message buffering and
prioritizing, and efficiency. For example, highways that are based on collision de-
tection and report-by-exception can lose 70 to 80 percent of their rated capacity
when message loading increases as a result of alarm burst and process upset con-
ditions. Unfortunately, it is under such conditions that it is most important for the
data highway to perform efficiently. Generally, one should evaluate a data high-
way design based on a worst-case scenario. One should consider:
(1) the number of tags (I/Os and control loops) that are connected to the
highway,
(2) how much trending and reporting information is being transferred,
(3) the volume of link communications, and
(4) the number of alarm points.

Once the required data highway capacity is known, the size, number, and con-
figuration of highways (and traffic directors) can then be specified.
Repeaters or gateways are an integral part of real-time data highways. When
one data highway is fully loaded and more capacity is still needed, additional
highways can be used. Two common approaches are used to permit communica-
tions between highways. The first is to link the highways together via a higher-
level or so-called super highway. Each real-time data highway is joined to the su-
per highway by means of gateway modules, which are usually redundant. This
means that connecting two redundant real-time data highways together would re-
quire four gateway modules. The second approach is a straightforward high-
way-to-highway connection via highway interface modules. In this approach,
there is no super highway acting as a go-between.
Whichever approach a plant uses, if one ends up with a requirement for multi-
ple highways, extra costs should be expected. If the requirement happens to be
“unplanned,” the extra cost could be substantial, considering the gateways, other
interface hardware, software, engineering, and possibly re-engineering involved
— all added “after the fact.” Sizing a real-time data highway means looking as far
as possible into the future and planning for maximum loading.

Host Computer Interfaces and PLC Gateways

A requirement in many DCS applications is the ability to transfer information
to and from other types of computers. This can be required for a variety of rea-
sons, such as:
(1) integrating the application with management information systems (MIS)
computers,
(2) integrating the application with optimizing or modeling computers,

12
 DCS Architecture

(3) integrating the application with production and maintenance computers

or computer networks already in place (or to come), and
(4) integrating the application with other process control computers (such
as PLCs).

Whatever the situation, the distinctly different computer systems must be able
to communicate with one another. That is, the real-time computer system may
have to talk to NT, Windows-based, or Unix-based computers or use some of the
more recent established protocols of OPC and ODBC. There is no universal
agreement on operating systems (although the trend appears to be toward Win-
dows-based platforms). However, all DCS vendors have taken the approach of us-
ing a “translator box” or “host gateway.” Typically, this gateway is a passive
device in that it does not initiate communications but merely translates and trans-
ports information. Typically, it does this using a method similar in concept to that
used in a post office box, as illustrated in Figure 8-4.
This method is often explained in terms of a data transfer table and is gener-
ally an efficient means of communication. It is faster and accommodates more
data than an approach that uses a direct question and answer on a point-to-point
basis. Gateways can also accommodate file transfers of large quantities of data,
such as trend or report files, although not all gateways have these abilities.

Figure 8-4. “Post Office Box” Operation of a Host Gateway

Since a host gateway module is normally a passive device that simply trans-
lates, it needs to be told what information to translate and when to read and write
to the various system registers. In short, it requires a driver device with driver
software to take charge of the communications. This setup is often a master-slave
relationship between the DCS and the host computer.
In communications with a PLC, it is usually the DCS that is the master han-
dling the driver software. The reverse is normally true when a DCS communicates
with a host computer. It is essential to know if a vendor includes the driver soft-

13
Distributed Control Systems / Digital Automation Systems

ware with the interface or gateway. Proven, off-the-shelf driver software is highly
preferred to software that must be custom developed. In the latter case, a user
must be prepared to pay a high premium and, in addition, suffer the frustration of
on-the-job debugging. Custom software development is very expensive in both
the short and long terms.
While a host gateway module is passive in terms of communications, it is an
active computer device. Plant personnel must therefore be aware of memory and
scan-time limitations with respect to:
(1) size of database,
(2) speed of communications,
(3) rate of database refresh, and
(4) types of data accessible (for example, trend files, report files, types of
live data, and so on).

DAS Defined
The timeline shown in Figure 8-5 places us at the epilogue of the technologi-
cal revolution’s big bang. Not since the Industrial Revolution has there been a
more intense change in the way human beings conduct themselves and their busi-
nesses. Today, it is possible to buy a completely digital automation system. Of
course, to anyone born in the past three decades this may seem ordinary. How-
ever, to any process engineer, operator, or technician over the age of forty this is
nirvana! In this section, we will describe a digital automation system (DAS) that
was built using the immense processing power and memory available only since
the mid-1990s.
The main differences between a digital automation system and a traditional
DCS or a traditional DCS with digital added are physical size, ease of use, scal-
ability, and interoperability. The key factor that enabled these changes to occur is
that intelligence moved to the edge of the network. End devices such as transmit-
ters, valves, motors, and analyzers are now “smart” and have taken over control
that previously was in the central host computer or distributed control computers.
A smart device is defined as any microprocessor-based device. Being closer to the
process, the device can spot problems, like plugged sensor lines, more readily
than can the remote automation system. Users can attain a level of predictive
maintenance that was not possible before the advent of microprocessors and of bi-
directional digital communications using open, interoperable standards like Foun-
dation fieldbus.

Foundation Fieldbus High-speed

Ethernet
HART OPC

1984 1994 1996 1999 2002

Figure 8-5. Technological Timeline

Today’s digital automation system is highly complex. On the hardware side it

comprises multiple PCs, client and server platforms, controllers, Ethernet-based
networks, multiple digital buses, and smart devices, and on the nonhardware side,

14
 System Architecture, Functionality, and Standards

highly sophisticated software programs and standards-based communication pro-

tocols. Using the latest commercially available technology, a digital automation
system is intensely powerful yet easy to use. Unlike a control system that has
added digital subsystems, a purely digital automation system is built with all-digi-
tal communications that can easily handle the volume of process, diagnostics, cal-
ibration, and asset information contained in smart field devices. The global nature
of process automation makes it imperative that the system conform to many inter-
national standards set by the following organizations:
• International Electrotechnical Commission (IEC)
• ISA – The Instrumentation, Systems, and Automation Society
• International Organization for Standardization (ISO), and
• Safety and environmental organizations such as OSHA and ATEX

It must be interoperable, which means that various suppliers’ devices can be

used within the system and multiple third-party software systems can interact
seamlessly with it. The system must encompass traditional process control. It
must also errorlessly pass a multitude of additional information peer-to-peer,
across the Internet, and through wireless devices. Finally, it must be able to easily
interact with existing systems so as to accurately transition the data from the old
system to the new.
A well-designed digital automation system enables forward-looking process
companies to increase plant performance, lower associated costs, and become
leaders in their highly competitive industries. By using and integrating the wealth
of information the system generates, a digital automation system improves the
processes that are used to make the desired product, optimizes plant operations,
manages plant assets, and uses predictive maintenance instead of reactive meth-
ods to maintain the plant. Simultaneously, the business side of the plant uses some
of the process data to optimize organizing, planning, and scheduling both inter-
nally and among global business partners.

System Architecture, Functionality, and Standards

Commercial, off-the-shelf digital technologies are the building blocks of a
digital automation system. Enterprise-class PCs, workstations, controllers, and de-
vices that are connected to digital buses are networked together using high-speed
Ethernet-based communications, both wired and wireless. Figure 8-6 shows the
architecture of a digital automation system that supports a multi-tier bus network.
Functionally, a digital automation system connects process instruments such
as temperature and pressure transmitters, flowmeters, gas analyzers, pH and con-
ductivity sensors, weigh scales, contact switches, valves, and motors to controllers
via a common bus that is based on open, interoperable digital communications.
Some of the most popular buses today include Foundation fieldbus, AS-i bus, De-
viceNet, and Profibus DP. The Fieldbus Foundation’s high-speed Ethernet (HSE)
is rapidly emerging as well. A digital bus is a high-speed communications path-
way between devices and the controller. Additionally, the controller connects to
the PCs and workstations via a high-speed Ethernet connection so as to pass large
quantities of information every second. Such broadband data flow enables engi-
neers, operators, and technicians to run the process better than ever before and to
give business managers a plethora of information to increase enterprise perfor-
mance. Communications between controllers, operator stations, engineering
workstations, and the enterprise use TCP-IP-based communications.

15
Distributed Control Systems / Digital Automation Systems

Figure 8-6. Digital Automation System Architecture

(Courtesy of Emerson Process Management)

In the past, automation systems were proprietary, meaning that the system
only used one vendor’s devices and communications system, and it didn’t com-
municate with third-party systems or did so only through low-band gateways. In
the mid-1990s, the influx of new technologies encouraged suppliers and end-users
of automation systems to create consortiums to develop standards for automation
systems. Consortiums such as Foundation Fieldbus, the OPC Foundation, and the
IEC have created and implemented the standards that digital automation systems
must adhere to in order to be accepted by process manufacturers worldwide. The
customer’s operating philosophies and plant constraints now control the process
environment instead of the narrow vision of a proprietary system.

Interoperability
Interoperability is an essential design philosophy of a digital automation sys-
A digital bus is a high-speed tem. In 1996, the OPC Foundation created a standard data exchange for software
communications pathway communications between process automation components, the control system,
between devices and the
controller. and software applications. This universally accepted industry standard enables
hardware suppliers to provide OPC servers or clients with their devices. Using
embedded OPC communications technology, a digital automation system ensures
interoperability between the devices, control system, and software applications.
Similarly, XML is the data exchange standard that a digital automation system
uses to communicate over enterprise LANs, intranets, and the Internet for transac-
tional data.
The Fieldbus Foundation organization developed a standard to ensure interop-
erability between digital field devices. These devices, tested and certified by the
Foundation, ensure communications between devices as well as with the digital
automation system. This is described further in the fieldbus section (see “Field-
buses”) later in this chapter.

Expanded Functionality
The exponential increase in computing power from a conventional DCS to a
digital automation system has enabled software engineers to integrate comprehen-

16
 System Architecture, Functionality, and Standards

sive batch solutions and embedded advanced control software, formerly done in
powerful host computers, right into the process controllers.

Evolution of Communication Standards

In 1993, the HART Communications Foundation developed a standard proto-
col for superimposing digital information on a conventional 4-to-20 mA analog
signal. This breakthrough in technology expanded communications between de-
vices and the control system. Simultaneously, major device suppliers began sell-
ing smart devices at the same price as analog devices. The HART protocol made it
possible to precisely measure analog sources and digitally communicate the infor-
mation to the control system. Additional functionality—such as identifying multi-
ple sensor types, measurement variables, product information, and diagnostic
issues—produced a wealth of information from these smart devices. Process man-
ufacturers immediately began reporting increases in reliability, accuracy, and sta-
bility using HART devices rather than conventional analog instruments. The rapid
acceptance of this new technology was the impetus for the continued development
of digital process technology.

Digital Buses and Devices

A digital automation system is connected to the field devices, such as valves,
transmitters, analyzers, and motor controllers, by using native interfaces with the
digital buses. This enables direct communications between the control system and
the devices. The gateways to systems that are not architected to receive the wealth
of information in digital field devices are typically limited, slow, and often require
that controllers be restarted when devices are added or changed. This causes pro-
cess shutdowns in many cases. Native implementations of digital buses, on the
other hand, mean the digital automation system can receive the full wealth of in-
formation and automatically communicate with the digital field devices as they
are added and removed without upsetting the process. Communications speed is
increased and accuracy is improved, which makes the digital device/bus network
more valuable to the control system. A digital automation system should be pow-
erful enough to natively integrate a full spectrum of digital buses, thus enabling
the customer to choose the best buses and devices for the plant.
TYPES OF DIGITAL BUSES
Several digital buses are available for process industry use. There are three
categories of buses within this market: sensor buses, device buses, and fieldbuses. Implementing digital buses
A sensor bus connects discrete devices such as on-off valves, solenoids, and prox- normally replaces conven-
tional point-to-point wiring
imity switches to the digital automation system. A device bus connects more com- and thus yields an obvious
plex devices such as motor, starters and drives to the control system. Finally, the cost benefit. To ensure that
highest-level bus system is fieldbus. A fieldbus connects smart devices in the field system and network perfor-
to each other and to the digital automation system. Working bidirectionally with mance are not compro-
the digital automation system, fieldbuses provide regulatory control as well as cal- mised—no data lost due to
poor distribution and loading
ibration, configuration, diagnostic, and predictive information. Generally, process of drops—the digital bus
manufacturers will use a combination of the three bus types. must be given a sound eval-
uation in the early stages of
SENSOR BUSES engineering design.
All digital buses reduce wiring costs by connecting to multiple devices on a
single pair of wires running back to the system. Additionally, digital sensor buses
report status information such as failure or overflow. Previously, this information
was not available. An overflowing tank was noticed because there was a puddle
on the floor. A digital sensor bus system eliminates this by automatically report-
ing impending status. This causes a predictive maintenance solution to replace the
reactive solution of the past. Beginning with low-level digital sensor buses, such

17
Distributed Control Systems / Digital Automation Systems

as AS-i bus, process plants decrease costs by anticipating device performance.

Sensor buses are typically inexpensive and provide little more than on-off infor-
mation. There is rarely diagnostic information associated with these devices.
DEVICE BUSES
Moving up in digital communication sophistication after sensor buses are de-
vice buses. Device buses connect limit switches, motors, starters, valve manifolds,
and drives to the control system. Before digital device bus technology, informa-
tion such as motor speed, motor temperature, and draw were virtually nonexistent
or had to be collected via many additional pairs of wires and I/O channels in the
automation system. An example of this would be to incorporate running amps in a
motor that feeds into a control strategy so as to optimize performance. This infor-
mation, combined with other improved diagnostics, gives operators and mainte-
nance personnel abundant information by which to improve plant performance at
the device level. As with the sensor buses, digital device buses such as DeviceNet
and Profibus DP reduce wiring costs and decrease errors associated with manually
connecting wires. The best digital device buses connect with multiple vendor de-
vices, which makes them interoperable.
FIELDBUSES
Fieldbus is the highest-level digital communications technology. Fieldbus is
based on an open architecture, which means that smart devices from multiple sup-
pliers connect to each other and to the digital automation system. This interopera-
ble, 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 through-
put, relatively simple installation, and advanced capabilities is helping process
manufacturing increase plant performance while lowering overall costs.
Fieldbus technology is highly desirable for process manufacturing because it
offers reductions in wiring, predictive maintenance alerts, the ability to add de-
vices while the system is running, field-based control, dynamic diagnostics, and
asset information. In fact, studies by the Fieldbus Foundation report vast reduc-
tions in wiring, terminations, and I/O cards (see Table 8-1). Technology has dra-
matically improved at the edge of the network. Smart devices connected to a
digital automation system significantly improve process performance because
they are capable of efficiently processing a wealth of information, including pro-
viding advanced control and predicting impending abnormal situations. Process
manufacturers are avoiding shutdowns, improving quality by reducing variability,
and seeing a return on investment (ROI) because of interoperable, totally digital
automation systems.

Table 8-1 Reductions Using Foundation Fieldbus

Task Percentage decrease

Field wiring 74
Control room space 93
Field device commissioning time 80

Footprint is significantly reduced when Foundation Fieldbus is used. The full

cabinet in Figure 8-7a handles 320 inputs and outputs (I/O). The nearly empty
field-based system cabinet in Figure 8-7b is shown with 384 I/O.
As with sensor and device buses, there are a number of fieldbus manufactur-
ers. Distinguishing such factors as quality of product, price, availability, and
available support help decision makers when choosing a product. However, the

18
 System Architecture, Functionality, and Standards

Figure 8-7a. I/O Cabinet Layout Using Conventional Wiring

(Courtesy of Emerson Process Management)

deciding factor for digital bus networks and devices is interoperability. Innovative
manufacturers of digital buses and devices are keenly aware of the importance of
creating products that meet the needs of the process industry.

Batch
Process manufacturers must adhere to strict regulations and requirements, es-
pecially in batch processing environments. Impeccable record keeping is impera-
tive to satisfy government regulations and continuously improve quality.
Internationally defined standards such as ANSI/ISA-88.01-1995 – Batch Control
Part 1: Models and Terminology, Namur NE33 Batch, IEC 61131-3, ISO 9000,

19
Distributed Control Systems / Digital Automation Systems

Figure 8-7b. Cabinet Footprint Using Foundation Fieldbus

(Courtesy of Emerson Process Management)

and the FDA’s 21 CFR specify the requirements for good manufacturing practices
(GMP) in the design of batch systems. Digital automation systems that follow
these standards have an advantage over both legacy systems and loosely devel-
oped batch processes in the following ways:
• The five standards just mentioned have defined a physical and functional
batch control architecture that creates logical coherence throughout the
system.
• A digital automation batch system that conforms to the accepted industry
standards ensures an integrated batch control environment.
• A digital automation system batch environment seamlessly integrates the
applications of the process with each other and with information systems,
beginning with recipe management (configuration) through to batch exe-
cution, production planning, and scheduling and ending with batch his-
tory and analysis and reporting.
Once again, the giant leap in processing power has made it possible to create a
powerful batch-processing environment. Only automation systems built with all-
digital communications can achieve this level of integration. A single, global data-
base, not previously possible, enables seamless interaction between recipe man-
agement, batch execution, production planning and scheduling, and batch history,

20
 System Architecture, Functionality, and Standards

analysis, and reporting. Controller memory capacity, recipe size, and phase logic
all have an impact on batch performance. However, the advanced, efficient com-
munications of a digital automation system greatly increase the power of a batch
system. The digital automation system ensures the transparent, continuous flow of
batch information between the PCs, servers, and controllers, including configur-
ing and processing recipes, allocating equipment, phase-to-phase communica-
tions, collecting and reporting history, and communicating with third-party
software. The result is diminished process variability and increased plant perfor-
mance.

Figure 8-8. Phase Logic Graphical Construction Using IEC 61131-3 Sequential Function Charts

The importance of following the ANSI/ISA-88.01-1995 and IEC 61131.3

batch design standards cannot be overstated. By implementing these batch envi-
ronment standards, digital automation system manufacturers and users are en-
sured of a common protocol in recipe management, batch execution, and
historical collection.

Advanced Control
Today’s technology makes it possible for intensive computing applications
such as advanced control to be embedded in the digital control system. The vast
amount of processing power and speed now available are enabling advanced ap-
plications to become integral parts of the digital automation system. These appli-
cations include automatic variability inspection, tuning, fuzzy logic control,
model predictive control, simulation, and plant optimization. Advanced applica-
tions bring precision control to the process. This precise control increases plant ef-

21
Distributed Control Systems / Digital Automation Systems

ficiency by reducing process variability, thereby increasing product quality. In the

following paragraphs, we will discuss three advanced control applications found
within a digital control system.
AUTOMATIC VARIABILITY INSPECTION
Process variability and under-performing loops are two major contributors to
poor plant performance. In the past, only severely under-performing loops would
send a process alarm to the operator. To correct the abnormal condition, engineers
would perform calculations manually. Now, digital automation systems automati-
cally and continuously monitor all process variability and control-loop perfor-
mance. The application automatically calculates total standard deviation and
capability standard deviation. The total standard deviation provides a continuous
measurement of process variability. Abnormal loop conditions such as improper
mode, limited control, uncertain process variability, or excess variability are
graphically displayed on workstations. The additional functionality of this ad-
vanced control provides quantitative measurements of the amount of variability
that could be reduced with optimum control loop performance. Also, this inspec-
tion application reports the frequency with which control loops operate in the cor-
rect mode. As Figure 8-9 shows, this wealth of information is presented in an
easy-to-follow format. Taking advantage of this detailed information, plants can
implement additional advanced control applications so as to expertly tune and cal-
ibrate control loops.

Figure 8-9. System and Process Diagnostics

(Courtesy of Emerson Process Management)

TUNING
Until the advent of digital automation systems, it took an expert to tune a con-
trol loop for optimum performance. Now, measuring process dynamics and calcu-
lating tuning constants are simply a part of the dynamic digital automation
system. Process manufacturers that do not employ a digital automation system
with advanced control have many improperly tuned loops. And these poorly tuned

22
 System Architecture, Functionality, and Standards

loops mean lower quality, lost production and reduced profits, along with poten-
tially costly environmental and safety issues.
The interoperability of a digital automation system is a crucial factor in
achieving optimally tuned loops. Malfunctioning transmitters or sticky valves
prohibit proper tuning under any circumstances. In a digital automation system,
smart devices communicate diagnostic and health information, which ensures that
tuning is only performed on fully functioning components. Once underperforming
loops have been detected, the advanced tuning application automatically calcu-
lates gain, rate, and reset parameters to expertly tune all loops. Advanced tune ap-
plications also can provide simulation and analysis information that enables users
to predict control loop performance before the new tuning is used.
FUZZY CONTROL LOGIC
Traditional proportional, integral, derivative (PID) control has been the stan-
dard method for loop control in process manufacturing. However, digital automa- OPC is a standard interface
tion systems have improved this method with automating fuzzy logic. Before that makes it possible to de-
velop interoperable applica-
digital automation systems existed, expert knowledge of fuzzy mathematics was a tions for servers and clients,
prerequisite for using fuzzy logic control. Now, high-speed digital automation makes possible multi-client/
systems running fuzzy algorithms are improving PID loop performance by 30 to server architecture, allows
40 percent. Fuzzy advanced control responds faster than PID control to set-point local and remote server ac-
changes and load disturbances without overshoot. For example, in temperature cess, and manages real-time
information.
and composition loops where overshoot can ruin the product, fuzzy logic’s re-
sponse curve provides better control. Also, fuzzy advanced control stabilizes
loops that have noisy process signals better than does PID control. Before digital
automation, PID control was the workhorse of process manufacturers because
fuzzy was too difficult. Digital automation systems have taken the complexity out
of fuzzy so that process manufacturers can get superior performance out of their
control loops.

Communications
Since Windows 3.0, multiple applications have been running simultaneously
and exchanging data with each other. The tools that enable diverse software appli-
cations and platforms to communicate with each have become more robust, flexi-
ble, and faster as technology has advanced. Following are some of the more
commonly used communication applications.

OPC and DCOM

For process manufacturing, OLE (object linking and embedding) for process
control (OPC) client/server technology, the industry standard, enables software Windows applications that
components to directly communicate over a network. Digital automation systems enable the user to access au-
tomation objects from other
use this technology to integrate multiple applications into common databases for applications are called OPC
viewing, archiving, and managing data. Clients. OPC is based on the
There are multiple OPC specifications within the OPC standard, which cre- Microsoft OLE/COM technol-
ates a truly open, interoperable architecture. These multiple standards support ogy. OLE automation pro-
vides data access via a local
real-time data communications for process data, alarm and event data, historical area network (LAN), remote
data, and batch data. This standard protocol has eliminated the need for custom sites, or the Internet. COM
device drivers, which were the norm for legacy systems. Hardware vendors now enables objects to be de-
provide a standard OPC server or client with their devices. The OPC specification fined using methods and
is a natural part of the digital automation system. Interoperability is ensured, and properties.
process manufacturers now have the freedom to choose the best devices for the Local: The server and the cli-
process. OPC creates a common interface for all applications and platforms. It re- ent are on the same PC.
duces costs associated with implementing and maintaining applications and elimi- Remote (DCOM): The server
nates the need for custom-made device drivers. and client are on different
PCs.

23
Distributed Control Systems / Digital Automation Systems

The Distributed Component Object Model (DCOM) is a protocol that enables

software components to communicate directly over a network in a reliable, secure,
and efficient way. DCOM has the potential to completely hide the fact that soft-
ware applications are running on different computers. Customers and vendors
alike thus realize significant integration cost savings.

Figure 8-10. OPC/DCOM Local/Remote Architecture

XML
XML (for “eXtensible Mark-up Language”) is a data definition standard that
is currently being used in all industries to exchange business data across intranets
and the Internet. Current global business trends such as enterprise resource plan-
ning (ERP), customer relationship management (CRM), and online learning are
promoting the use of XML. Digital automation systems use XML to integrate
themselves with these latest business applications. For example, a digital automa-
tion system can integrate a production control system with the maintenance sys-
tem so the equipment proactively generates work orders. Then, it delivers
inventory information to suppliers for the purpose of inventory management and
plant scheduling. Working with the ERP system, production schedules and quotas
are automatically delivered to the production control system.
Another example of XML’s diverse functionality is communicating device
alerts to the appropriate personnel. A digital automation system can send device
alerts along with instructions on how to fix the problem to a pager, cell phone,
PDA, or workstation. This embedded functionality of digital automation systems
goes far beyond the capabilities of DCS or PLC systems simply because these sys-
tems were written before XML existed.

Power Distribution System

Power distribution is the part of a DCS and DAS that is most often over-
looked, and, like the real-time data highway, the power distribution system is a
system component that is linked to all other components in the system. It is the
DCS and DAS component that takes raw electrical power, converts it, conditions
it, and regulates it for all the other computer modules in the system.
The typical power distribution system can be split into two parts—bulk power
and power regulation. With bulk power, the key issue is to ensure that variations
in the main AC source do not exceed the capabilities of bulk power supplies. Bat-
tery backup, usually mentioned in the same breath as bulk power supplies, may
take various forms: an uninterruptible power supply (UPS), separate battery

24
 User Interfaces

packs, or integral battery packs. Whichever approach is used, the batteries should
be able to take over instantaneously if power fails or dips. Loss of power to the
microprocessor modules could erase some sections of memory and also require
the system to be rebooted. Battery backup is sized to keep the system energized
long enough to meet essential needs. Typical backup times may range from two or
three minutes to two hours.
Power regulation is also vital to the operation of a DCS. Nevertheless, redun-
dant power regulation is recommended for most system modules and most appli- The power distribution sys-
cations. tem is not a high-cost DCS
component, but it is impor-
tant and should not be
skimped on. It is highly rec-
User Interfaces ommended that plants plan-
ning for their future power
In many industries, the user interface has undergone quite a revolution over needs and use partial load-
the past fifty years. Given the complexity of today's processes, engineering per- ing of 50 percent to 75 per-
sonnel as well as for process operators need user interfaces. In the days of smaller cent of the rated capacity.
and simpler industrial plants, manual control was the first form of operator inter- Redundancy in bulk power
and power regulation is a
face. An operator would walk a tour, check tank levels and pressure gages, and wise investment.
adjust valves. As industrial operations grew in size and sophistication, tours be-
came longer, and more operators were required. Adjustments became less
straightforward as processes became more interrelated. Manually collected data
became less helpful in providing a true picture of what was going on.
With the advent of relay logic panels and pneumatic transmission the concept
of a centralized control or monitoring room emerged. For the first time, informa-
tion was brought to the operator. However, the centralized information was in-
complete, and what was there tended to be unreliable. Consequently, operators
still made their tours, reading strip-chart recorders and local panel indicators.
Electronic analog controllers and PLCs soon made possible more precise,
cost-effective, and reliable control. It also made for a more centralized control
room. Fewer operators were required for ever larger and more complicated plants.
However, since much of the old pneumatic control equipment and relay panels
still existed, manual intervention was still necessary, and operators continued to
do their tours. If an operator went out for an hour or two and a process upset oc-
curred just after he or she left, it could be some time before it was corrected.
Off-spec products and rejects usually the result.
In the late 1960s and early 1970s the first digital computers emerged and were
quickly followed by the first CRT-based display stations. For the first time, virtu-
ally any instrumented information about the process was available at the touch of
a button.
Since then, CRT-based consoles have increased in power, speed, and reliabil-
ity. They permit almost instantaneous access to measured variables throughout
even the largest production plant. Single control centers that operate entire paper
mills, steel mills, and refineries are increasingly replacing the multiple operator
rooms distributed throughout a site. Today, plants use common operator interface
stations with multiple displays on a single CRT, reducing the number and types of
consoles required.
The operator or human-machine interface (HMI) is the “razzle-dazzle” mod-
ule in a DCS. It is the one device that strongly influences people's perceptions of
the entire DCS. An impressive operator interface translates into an impressive
DCS. The question is, “Is this just a pretty face or is the beauty more than skin
deep?” The answer to this question depends on the extent to which the following
features are present:
(1) access to and size of the database,
(2) integrity of information,

25
Distributed Control Systems / Digital Automation Systems

(3) speed (static and dynamic) at which the screen (or image) builds, and
(4) reliability and redundancy.

Operator interfaces come in many different configurations, with very different

capabilities and methods of operation. Some operator interfaces are still “tag lim-
ited,” that is, they are restricted to the size of database they can access. DCS ven-
dors offer PC-based interfaces in consoles that range in capacity from five
hundred to ten thousand tags. These interfaces usually have a live RAM-resident
database that duplicates the database that resides in the I/O and controller mod-
ules.
This RAM database is continually updated from the field, and screen-display infor-
mation is continually refreshed from it. One should be cautioned here that the op-
erator sees information from the interface database and not directly from the field
measurement. If the system operates on a report-by-exception basis and communication is
lost, the operator could be unaware that the process is doing something completely differ-
ent.

So-called display-based consoles do not use a RAM-resident database. These

interfaces store various display pages, whose dynamic points will be refreshed di-
rectly from field measurements when the pages are loaded onto the screen.
The time it takes to refresh a screen image (screen build) is an important fac-
tor to evaluate when considering an operator interface. A screen display is usually
divided into areas of static and dynamic data. Static data is associated with objects
(such as boxes, tanks, pipes, and valves) that do not change (except for color,
flashing, or reverse video) with the process. They are a fixed part of the display.
Dynamic data consists of live field data such as process-variable values, loop
set points, controller outputs, and contact status. It is information that is constantly
updated, or refreshed, on the CRT.
Screen builds can be as fast as 1/4 second and as slow as 2 to 15 seconds. This
speed can be affected by things such as:
(1) size of display page (amount of static information),
(2) number of dynamic points on display pages,
(3) location of resident display pages (hard or floppy disk), and
(4) use of display pages from another highway module.

Typically, RAM-resident display pages that have few dynamic points will
build very quickly. Screen build times could be much longer if an interface has to
display many dynamic points that are scattered throughout a plant and have to
travel over a busy data highway.
Some operator interfaces have a multitasking ability—that is, they can carry
out several functions at the same time. Thus, while an operator is using the inter-
face, activities such as trending, reporting, and alarm and event logging are going
on in the background. An operator interface can sometimes be configured to act as
an engineering workstation as well. These extra tasks should not affect the funda-
mental purpose of the interface, which is to give the operator an efficient window
on the process being controlled. This should not be a problem if the added func-
tions are treated as enhancements to the interface.
Multitasking operator interfaces cost more than the single-tasking units, but
they can be more cost-effective than buying a number of separate single-tasking
units.
Another important factor to consider when evaluating an operator interface is
how many the job needs, including the associated hardware. The following are
typical choices:

26
 User Interfaces

(1) Number of CRTs

• one per operator
• three CRTs for two operators
• two or more per operator
(2) Number of sets of electronics
• one per CRT
• one per two or more CRTs
(3) Number of hard disks
• per interface
• per electronics
In evaluating a plant’s needs, it is a good idea to imagine what happens to the
operator if any one component fails. For example, if there are four CRTs, two sets Interfaces tend to be expen-
of electronics, and two hard disks, one would ordinarily expect to be secure. How- sive modules in a DCS. Add-
ing them in an unplanned
ever, if the electronics are each handling separate databases and one fails, part of way often leads to a budget-
the plant may be running blind simply because it cannot access the other's data- ary problem because added
base. Running blind may not necessarily be fatal, but it is generally considered un- equipment and engineering
safe. Such a situation can be readily prevented with today's interfaces, which is required.
allow appropriate levels of flexibility and redundancy to be built in.

Operator Interface Hardware

The operator interface hardware consists of CRT displays, keyboards and
other access devices, and hardcopy devices. It also includes power supplies, disk
drive units, and card files.
The CRT video display unit is the main interface component. It is the vehicle
by which system users operate, control, and manage the entire control process.
CRT displays replace the conventional analog control panel, and they provide the
user with an easy view of the process through a hierarchical series of displays.
The layout of the various components depends on the manufacturer as well as the
user's preferences. In principle, however, the interface should be designed to
increase the operational capabilities of the people who use it. In other words, it
should follow good ergonomic design principles (see Chapter 10).
CRT DISPLAY MONITORS
CRT monitors operate through a dedicated video module that has its own pro-
cessor, which may support alphanumeric keyboards, mice or trackballs, and an
alarm horn. The sizes of color monitors vary from nineteen inches to twenty-one
inches and larger. Monitors may be mounted into a workstation or on a desktop,
and newer models can be flat-screen. The video information monitors display may
include text, charts, and graphics.
Monitors may include a touchscreen display as an optional feature. With this
option, the user selects display objects by touching a menu on the screen. This is
accomplished by means of infrared LEDs and phototransistor detectors that are
mounted opposite one another on the front surface, forming an invisible lattice of
infrared light beams. Each time the beams are intercepted, either by a finger
touching an object on the screen or by a pointing device, a signal is sent to the pro-
cessor that indicates the position of the selection.
ALPHANUMERIC KEYBOARD
The alphanumeric keyboard is a regular computer terminal keyboard, with the
standard QWERTY key arrangement and ASCII-formatted output. It may have
additional keys to help the engineer configure the data base, build displays, and
set up system application packages such as historical trending.

27
Distributed Control Systems / Digital Automation Systems

OPERATOR KEYBOARD
The operator keyboard is a specialized device that is designed to make the op-
erator's interaction with the process faster and easier. It can be a full-stroke key-
board or a spill-proof membrane style with tactile feedback. Various dedicated
keys allow an operator to select important functions with a single keystroke. The
actual layout of the keyboard varies with the DCS supplier.
Some keyboards contain an annunciator section with light-emitting diodes
(LED) and a Mylar key switch. Each LED can be configured by the user as ON,
OFF, or FLASHING, according to process conditions. The numeric section con-
tains numeric and data-entry keys and cursor control.
TRACKBALL AND MOUSE
The trackball is a cursor control device. It allows users to control the cursor
position by manually rotating a mechanical ball whose position is converted into
data signals that are equivalent to those generated by the normal cursor control
keys. The trackball also has a push button to acknowledge alarms and messages
and to select an action, as one would do with the “Enter” key on a regular key-
board.
The mouse is another table-top cursor control device. When the user moves
the mouse across a surface, an internal mechanical ball in contact with the surface
rotates, generating cursor control signals similar to those of the trackball. Ac-
knowledge and Enter push buttons are also provided.
HARDCOPY DEVICES
Hardcopy devices include printers. The printer is used for alarm and event
logging, graphics, and reports. Printer output may be in color or in black and
white. With a color printer, a user can print blocks, characters, and graphics with
different colors. Alarm conditions can print with a different color to distinguish
them from normal operator actions.

Figure 8-11. Operator Interface Hardware

Operational Philosophy
The role of the operator can be described in terms of the four plant conditions
given in Table 8-2.

28
 User Interfaces

Level 1 - Steady-state operation. In a steady-state plant condition, the operator's

role is normally limited to maintaining an overview of the whole or part of the
process plant and to monitoring the trend records of key variables or variables that
are in an acknowledged alarm condition.

Table 8-2. Plant Conditions and Role of Operator

Level Plant Condition Description Operator Mode Description

1 Steady-state operation Overall process surveillance

2 Minor plant/unit upset Unit and section monitoring
3 Planned startup/shutdown or feed Interactive
changes
4 Major plant upset or emergency Priority loop Interaction

Level 2 - Minor plant/unit upset. When a condition of minor upsets occurs on a

particular section of the plant or when the operator anticipates an upset as a result
of changing conditions in a related process area, the operator needs to take a
closer look at the plant area in question. In this mode of operation, it is essential
that the operator have easy access to a summary of the loops involved as well as to
the related trends. Usually, two CRT consoles are required to maintain sound pro-
cess control. While the operator looks at the individual loops, a standby overview
display should be on all the time.

Level 3 - Planned startup/shutdown. In this operational mode, the operator’s in-

formation needs are similar to those in the previous unit-monitoring mode. How-
ever, in this mode the operator is now interacting with the process because he or
she needs to change and manipulate the control loops.

Level 4 - Emergency/major upset. In a major upset condition the operator’s inter-

action with the system is the most intense. It is essential that he or she be able to
access the required information and manipulate the available parameters of the
priority loops with speed and simplicity. The operator should format special page
displays giving status and multitrend reports in advance so they can be used under
upset conditions, while recognizing full well that there can always be an unpre-
dictable major upset. In this situation, the judgment of the operator, in conjunction
with the process’s parallel safety interlock and shutdown systems, should override
any predefined procedures.

Interface Displays
The specific configuration of each operator console and the number of con-
soles required will depend on the type of plant involved. Regardless of the config-
uration, however, when the system is powered up, the first screen displayed is
usually 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.

29
Distributed Control Systems / Digital Automation Systems

The display hierarchy is a sequence of different displays that take the operator
from the general to the specific, for example, from a plant overview display to a
group display that shows one group, unit, or individual loop. Figure 8-12 illus-
trates a typical display hierarchy.

Figure 8-12. Typical Display Hierarchy

The plant overview display includes the name of the process area, bar graphs
of normalized deviation, color alarm blocks, a list of alarms, and the date and
time. The actual display configuration would depend on the manufacturer's speci-
fications. From the overview display, the operator can take no direct action. Direct
action can be only be taken when a more specific display, such as a loop in alarm,
is selected. Other overview displays are obtained by using a page-forward and
page-back process.
Group displays may contain individual control loops showing tag name, a bar
graph of measured variable, the output value, the set point, the process value in
engineering units, the set-point source (remote, local, or tracking), the output
mode (auto, manual, tracking), and also alarm information. A page-forward and
page-back technique can be used to select other groups.
Trend displays indicate the rate of change of the key variables in a process
and are important indicators of plant status. This information can help the operator
identify or anticipate process upset conditions. The user can select a real-time or
historical mode (from one second to one month, typically) and scale in both per-
centage and engineering units for all variables as well as for the time base. Trends
are often recorded on a hardcopy printer. Table 8-3 lists the principal features to
look for in trend displays.
Trending and reporting are methods for archiving information, and they re-
quire that there be a method for backing up hard disk files. It is important for the
operator to understand how this backup is accomplished and how the data can be
retrieved (and reviewed) later on.

30
 Basic DCS/DAS Software Modules and Functionality

Table 8-3. Principal Features of Trend Displays

(1) Sample frequencies available (one per sec, one per five sec, one per minute).
(2) Number of variables that can be trended.
(3) Duration of trending periods available (one hour, one shift, one day, one week,
one month, one year).
(4) Amount of RAM and amount of hard disk space available for trend files.
(5) How sampling and duration are related and how they affect each other.

Alarm displays provide a list of alarms along with their tags, types, descrip-
tions, priorities, and acknowledgment status. Alarms are listed chronologically ac-
cording to the time of detection of the alarm. The size of an alarm list is defined
by the user and usually contains approximately two hundred alarms. As the num-
ber of alarms exceeds this figure, the oldest alarms drop off. Dedicated keys on
the keyboard or functions configured on the screens permit the operator to quickly
identify active alarm conditions, to scroll up and down the alarm listings, and to
acknowledge alarms.
The graphic display is a schematic of the process being controlled. The dis-
play is dynamic, giving the operator real-time data on the condition of the process.
The display is also user-definable and is constructed with a variety of geometric
shapes, texts, and process control symbols. Graphic displays indicate loop tag
names, measured values, output values, output modes, and engineering units. The
operator can control the display’s graphic representation directly by means of ani-
mated symbols and color changes of parameters such as tank levels and process
temperatures.

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 location

of 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 as
the operator interface, that is, from CRTs, electronics, keyboards, hard disks, and/
or tape drives. The key difference between the workstation and the operator inter-
face is the software. Thus, an engineering workstation could be used as an opera-
tor interface if it had the proper operator interface software.
The engineering workstation is typically used off line. However, with the
right 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 worksta-
tions in different physical locations. This is to minimize any potential interference
by the engineering workstation in the day-to-day running of the plant.

Basic DCS/DAS Software Modules and Functionality

Programming Concepts
All computer systems need software (programming) to be able to execute
their assigned tasks. The DCS or DAS, which is highly computer-based, must be

31
Distributed Control Systems / Digital Automation Systems

programmed with process information, control algorithms, and the operator inter-
face instructions that are necessary for proper operation.
Some control functions can be preprogrammed by the system supplier, while
other functions must be configured by the user's control system engineer. Com-
puter-based control systems come with standard fill-in-the-blank software for data
acquisition, process control, alarming, and operator displays. Software can be
classified as “executive,” “system support,” and “application,” even though manu-
facturers’ descriptions do not always seem to fit neatly into these categories.

Executive Software
As mentioned in Chapter 7, executive software is the operating system of the
computer. It is comprised of the programs that supervise the actual operation of
the system. Executive software performs functions such as the following:
(1) scheduling and initiating the execution of system-application programs;
(2) allocating main memory and loading programs into main memory; and
(3) supervising I/O operations.

System Support Software

System support software consists of programs that help the user develop ap-
plication programs. These programs are generally supplied by the vendor. They
include:
(1) computer language processors that translate high-level language pro-
grams into machine-language programs;
(2) editors, to facilitate the creation or modification of user-written pro-
grams; and
(3) debugging aids (to find program errors).

Application Software
Application software consists of programs for tasks that are directly related to
the primary functions of a system. Examples are reading analog or digital inputs
into memory, computing control outputs based on input and set-point values, and
converting this information into engineering units.

Communications Software
The communications system facilitates the exchange of information between
process control and information devices. Communications software is proprietary,
even though there is a standard, which is based on the International Standards Or-
ganization’s (ISO) Open System Interconnection (OSI). This standard enables one
communication system to be connected to another using a standard protocol. A
protocol is a set of conventions that govern the way devices communicate with
each other. As we mentioned earlier in the subsection “Communications” in the
section on DAS, OPC creates a common interface for all applications and plat-
forms. This provides a more open and less proprietary communications interface.
The OSI reference model of seven layers of communications networks is an
industry standard for linking intelligent devices in a distributed applications envi-
ronment. As long as a manufacturer complies with this standard, which includes a
unique twelve-digit manufacturing code and serial number at the transport level,
then a communications link can be established between two or more computers.
The seven layers are described in Table 8-4.

32
 Basic DCS/DAS Software Modules and Functionality

Table 8-4. Seven Layers of the OSI Reference Model

Layer 7 Application — Provides the interface for the application to access the OSI environment
Layer 6 Presentation — Provides for data conversion in order to preserve the meaning of the
data
Layer 5 Session — Provides user-to-user connections
Layer 4 Transport — Provides end-to-end reliability
Layer 3 Network — Provides routing of data through the network
Layer 2 Data link — Provides link access control and reliability
Layer 1 Physical — Provides an interface to the physical medium

System Configuration
System configuration, which includes the configuration of the database and
console, is the main engineering function. Database configuration is used to cre-
ate, maintain, and document the system database. It involves building, compiling,
installing, and downloading the database and then updating it at run time.
Console configuration is used to specify the contents and to define the portion of
the database that is assigned to each console. It involves the following:
(1) defining the console environments or scope;
(2) specifying the loops that are to appear on the operational displays;
(3) specifying the graphics to be associated with the operational displays;
and
(4) specifying the users who are allowed access to each console.

The configuration process is organized in a hierarchical manner. Configura-

tion techniques can vary widely from manufacturer to manufacturer. They can
range from syntax-laden, line-by-line programming to small interactive logic
blocks or large multifunction blocks. A block for one DCS vendor does not mean
the same thing as a block for another. In the same way, a display page means dif-
ferent things to different suppliers. Some are prestructured while others are cus-
tomized graphics.
Depending on the owner’s knowledge of the control system, it may be desir-
able to have the vendor be responsible for configuring the system. The complexity An owner should exercise
caution if he or she is plan-
of different configuration techniques can easily lead to extra engineering hours. ning to configure a system
Long-term costs may be incurred if one considers all the potential troubleshoot- entirely on his or her own or
ing, modifications, and expansions that may be necessary. Table 8-5 gives exam- through a third party.
ples of the specific tasks that are entailed in configuration.

Table 8-5. Typical Configuration Tasks

Configure an input block. Develop faceplates.
Do signal characterization. Define groups (normally four or eight faceplates).
Define alarming parameters. Define multitag displays
Set range/scale and engineering Design dynamic graphics.
units.
Define links to control blocks. Define trend reports.
Configure control blocks with Define alarm and event logs.
PID or other algorithms.
Configure displays. Define other modules.
Develop alarm banners.

33
Distributed Control Systems / Digital Automation Systems

Finally, note that upgrading the system software will likely involve modifying
the configuration. This can be almost as expensive as buying the original system.
We discuss this topic in more detail in the section titled “Upgrading a DCS” later
in this chapter.
Software as provided by a supplier does not always fit neat categories. What-
ever the supplier’s approach to the software, you can safely assume that they will
not guarantee the absence of bugs. As a rule, software will have fewer bugs the
more it has been field-tested in actual installations. Generally speaking, a single
integrated package is better than a number of little packages. Another consider-
ation is the consistency of operation between different software packages. That is,
are the same commands and techniques used from one application package to an-
other? As always, the simpler the better.

Installation
Installing a DCS is the process of placing the components, environmental
conditioning, power distribution, and wiring in physical locations.

Physical Location
The components of a DCS or DAS may or may not be distributed widely
throughout a plant. A plant’s type and its philosophy of operation play key roles in
where the same component will be physically located from one project to the next.
Table 8-6 presents one possible distribution scheme for DCS or DAS equipment.
The basic intent of control room design is to ensure that equipment performs
optimally and that the operator is personally comfortable. Future expansion is also
an important consideration when laying out a control room. Figure 8-13 shows a
typical layout for a control room and a computer room.
Vendors provide the dimensions and clearances needed to plan equipment
layouts or move equipment through doorways and halls.

Table 8-6. Typical Distribution of DCS or DAS Equipment

Control Room Engineering Room Computer Room
Operator consoles Engineering workstations Cabinets containing:
- process I/O cards
- controllers
- communications modules
Operator keyboards Printers
Printers

Lighting is an important aspect of control room design. Typical lighting rec-

ommendations from manufacturers include the following:
(1) Use indirect or recessed incandescent lighting fixtures with diffusion
lenses to prevent glare and to ensure uniform illumination.
(2) Provide illumination levels of approximately 420 lumens per square
meter where CRTs are operated.
(3) Provide illumination levels of approximately 650 lumens per square
meter where CRTs are not operated.
(4) Where variable lighting intensity is desirable or required, consider task
lighting and/or lighting controls, such as dimmers.

34
 Installation

Figure 8-13. Typical Control Room and Computer Room Layout

Emergency lighting is necessary so essential functions are not shut down in

case a power failure knocks out the plant’s illumination. Emergency lighting can
be powered by a battery backup system or by an emergency generator.
Take vibration into account if the control room is next to large machinery
such as shakers or presses. To protect sensitive control equipment, install shock
absorbers or isolation pads on the offending machinery. The operational and the
static vibration limits are specified by the control system equipment manufacturer.

Environmental Conditioning
Environmental controls ensure that equipment operates optimally and that op-
erators are comfortable. When selecting environmental conditioning systems,
temperature, humidity, and air filtration must be considered. Temperature in a
process environment is generally maintained between 65°F (18°C) and 75°F
(24°C). Relative humidity should be around 50 percent. Aside from optimal
equipment operation and personal comfort, proper environmental conditioning
also helps reduce the buildup of static electricity charges. See Table 8-7.

Table 8-7. Typical Equipment Environmental Characteristics

Controller Subsystem All Other Subsystems
Data Processor
Signal Conditioning and Interfaces
Characteristics Subsystem (with Disk
Card and (without Printers or
Drive and Printers)
Terminations Disk Drives)

Operating 32 - 122°F 50 - 104°F 32 - 104°F

temperature (0 - 50°C) (10 - 40°C) (0 - 40°C)
Storage temperature –40 - 140°F –40 - 140°F –40 - 140°F
(–20 - 60°C) (–20 - 60°C) (–20 - 60°C)
Relative Humidity 10 - 90% 20 - 80% 10 - 90%
Maximum Wet Bulb 90% RH at 90°F 90% RH at 80°F 90% RH at 90°F
Temperature (32°C) (26.7°C) (32°C)

35
Distributed Control Systems / Digital Automation Systems

To determine how much air conditioning to provide in the control room, one
must consider the internal and external factors that contribute to heat gains and
losses in the control room area. Internal factors include equipment, lighting, and
people, all of which generate heat. External factors include outside temperature,
exposure to sun, and wind. If the control room is located inside a building, gener-
ally only internal factors will be taken into consideration.
To reduce the risk that exterior airborne contaminants will damage electrical
components or disk and tape drives, the control room should be maintained under
a positive pressure of approximately 25 pascals with respect to its exterior.
Different levels of corrosion protection are given in the standard, ANSI/ISA-
71.04-1985 - Environmental Conditions for Process Measurement and Control
Systems: Airborne Contaminants.

Power Source
Two important power source criteria are power quality as well as grounding
of the DCS and must be considered in the design and installation of the DCS.
POWER SOURCE QUALITY
Depending on the country in which a DCS is installed, DCS system equip-
ment will operate on 115–230 V AC, 50 to 60 Hz, single phase. Dedicated power
supplies mounted in the system cabinetry supply DC power for the actual system
components. Manufacturers use the following parameters to characterize the qual-
ity of power needed for acceptable operation of their equipment:
(1) Range of voltage variation from the nominal value
(2) Range of frequency variation from the nominal value
(3) Harmonic distortion

The total AC power requirements can be calculated by adding up the individ-

ual power consumption values for each device. These values are specified by the
manufacturer.
Table 8-8 shows the power consumption and cooling requirements for a typi-
cal system.

Table 8-8. Typical AC Power Consumption and Cooling Load

AC Power
Cooling Load
Draw (V A,
(Btu/h, Typical)
Equipment Description Typical)
Console subsystem with 2 color monitors and keyboards 900 3200
Data processor or gateway subsystems 1000 3200
Controller subsystem (3 fully loaded card files) 900 3105
SC controller subsystem (3 fully loaded card files) 1464 4850
Multi-bus I/O system (fully loaded) 1600 4000
19-in. Color monitor without touch screen 80 276
19-in. Color monitor with touch screen 95 300
System maintenance terminal 60 110
Black and white or multi-color printer
operating 138 431
standby 55 170
Systems terminal printer 120 410
Workstation processor 820 2830
Local control panel 42 150
Remote hardened console 95 300

36
 Installation

As an option, some manufacturers offer a backup power arrangement. When

the primary AC power fails or drops below approximately 15 percent of the nom-
inal voltage level, internal batteries supply DC power to the system for a predeter-
mined period of time. The AC power is reconnected when the level returns to its
nominal value. A simple battery backup does not regulate either frequency or
voltage when the system works from primary AC power. Such regulation is possi-
ble only if the backup power is provided by an uninterruptible power supply
(UPS).
Since the power supply is such a critical element, installation planning may
stipulate uninterruptible power supplies (UPS) to ensure that vendor's equipment
specifications are met.
GROUNDING SYSTEM
To minimize the effects of electrical noise (steady state or transient) caused
by large electrical equipment, large relays, and motor contactors, the primary AC
power source must be stable and noise-free and possibly even completely inde-
pendent. In addition, an adequate grounding system is needed to avoid conditions
that lead to equipment operability problems. Such conditions include electrical
noise caused by ground currents circulating through the system and by static elec-
tricity discharges.
The grounding system should terminate at common grounding electrodes
(ground rods). It should also have a resistance to earth of one ohm or less when The grounding system will
the system grounding is used in combination with power generation equipment. also minimize the hazard of
electric al shock to person-
When it is not, five ohms or less is recommended. Grounding systems require pe- nel.
riodic inspection and testing. Figure 8-14 illustrates a typical grounding installa-
tion.

Wiring
Type of cable and termination, as well as location of I/O and cabinets must all
be considered in the DCS installation. The following sections outline recom-
mended practices and specifications.
CABLING AND TERMINATIONS
Wiring coming from field equipment may terminate directly at cabinets that
contain the I/O cards or at conveniently located remote marshaling panels. The re-
mote marshaling panel is simply an electrical box that contains terminal blocks
and is designed to facilitate wiring between field junction boxes and I/O cabinets.
Wiring cabinets have cable entry openings at the top and bottom. This makes it
easier to design computer rooms when there is a raised floor or elevated cable
tray. Figure 8-15 illustrates typical cable routing inside a cabinet, and Figure 8-16
illustrates analog inputs and outputs and field wire termination.
TYPE OF CABLE
Cables recommended for 120 V AC service should have the following charac-
teristics:
(1) Conductors: seven-strand, class B, 14 AWG
(2) Ground conductor: single, seven-strand, class B, concentric bare
(3) Inner jacket: high temperature PVC
(4) Outer jacket: flame-retardant PVC
(5) Armor: interlocking aluminum alloy or galvanized steel

Single-pair or triad cables that are recommended for 24 V DC and 4–20 mA

service should have the following characteristics:

37
Distributed Control Systems / Digital Automation Systems

Figure 8-14. Typical Grounding Installation [Ref. 4]

(Courtesy of Emerson Process Management)

(1) Conductors: seven-strand concentric bare copper, class B, 16 AWG

(2) Shield: aluminum/Mylar tape shield with tinned copper drain wire
(3) Lay of twist: two inches nominal
(4) Jacket: FR PVC

Multiple-pair or multiple-triad cables that are recommended for 24 V DC and

4–20 mA service would have the following characteristics:
(1) Conductors: seven-strand concentric bare copper, class B, 20 AWG
(2) Shield: aluminum/Mylar tape shield with tinned copper drain wire, indi-
vidual and overall shield (4–20 mA analog signals), overall shield (24 V
DC and on-off signals)
(3) Lay of twist: two inches nominal
(4) Jacket: FR PVC
The choice of armored or nonarmored cable is up to the user, but generally ar-
mored cable is the safe choice.

38
 Installation

Figure 8-15. Typical Cable Routing in a Wiring Cabinet [Ref. 4]

(Courtesy of Emerson Process Management.)

Intrinsically Safe Barriers

An intrinsically safe barrier has terminals for connecting field and control
room wiring, which minimizes the number of panel terminals. Also, the barrier
system provides a sharp line of demarcation between the hazardous and safe area.
The barrier is a completely passive device that requires no power source and
passes a 4–20 mA DC signal at a nominal 24 V DC power rating with virtually no
degradation (less than 0.1%).
A barrier contains wire-wound resistors to limit current and redundant Zener
diodes to limit the voltage. A fuse is in series with the resistors. The question often

39
Distributed Control Systems / Digital Automation Systems

Figure 8-16. Typical Field Termination of AIs and AOs [Ref. 4] (Courtesy of Emerson Process Management.)

arises why a fuse alone would not do the job. If a high voltage were placed on the
input terminals with only a fuse and resistors present (without diode), an explo-
sion could occur in the hazardous area before the fuse could blow. A fuse can pass
sufficient energy to cause the explosion before it opens. Only microseconds are
needed, under the right conditions, for an explosion to take place. Without some
method for limiting voltage, a fault voltage that appears on the barrier input termi-
nals, when combined with increased current, could be passed along to the hazard-
ous area.

40
 Installation

System Check-Out and Site Power-Up

The system check-out and site power-up activity is almost always the exclu-
sive domain of the DCS or DAS vendor because it is associated with the warranty
of the system. An owner should always be sure that these two functions are in-
cluded in the vendor's price. The owner may not have the expertise to do it and
certainly does not want to pay the exorbitant price that some vendors ask after the
fact. It is clearly a good idea for the system check-out and power-up to be in-
cluded in the vendor's original price and quoted under competitive conditions.
There should also be a payment retention (ranging from 5 to 20%) that is payable
when the system is accepted. This ensures that the system is up and running be-
fore the final payment is made. Experienced owners know that “money talks.”

Typical System Layouts

Although the approach of this chapter has been to look at distributed control
systems in a generic way, each vendor tends to have a unique and sometimes pro-
prietary approach. Figures 8-17, 8-18, and 8-19 show how the overall structure
can vary among different manufacturers.
It would be of little value to analyze each structure for its various strengths
and weaknesses because each is generally the result of the vendor's proprietary ap-
proach. For the purposes of this chapter, it can be simply stated that there are more
similarities than there are differences.

Figure 8-17. DCS Structure Typical of Foxboro

Startup Services
DCS startup services may easily get overlooked when evaluating a vendor's
system because the buyer doesn't readily see their importance at the time of pur-
chase. Usually, it is only after installation that the tremendous importance of
things like staging, functional testing, and training become apparent.

41
Distributed Control Systems / Digital Automation Systems

Figure 8-18. DCS Structure Typical of Bailey

ABB CIMS ABB OP. ABB OP. ABB ENG. Macroview EXPERT APPS EXPERT APPS
STATION STATION STATION STATION Workstation Server Client

ABB Masterbus 300

ABB ABB
AC 450 AC450
CONTROLLER CON TROLLER UTP
Dat a Highway +
DH+

BM85 MUX
MB+

MB

MOD 584 A-B PLC-5 MOD 984

PLC PLC

Figure 8-19. DCS Structure Typical of ABB

42
 Installation

STAGING
This is a little-known service, especially to first-time buyers. Depending on an
owner's experience, it could be seen either as a waste of time or as a valuable tool
instrumental to an efficient, on-time startup. Staging may be defined as a type of
stress or operational test that is aimed primarily at DCS or DAS hardware. It is an
activity in which the entire DCS or DAS is completely assembled and the cable
connected so as to duplicate the eventual site installation. After powering up with
only the system software programs running, the system is expected to operate
without problems for a given period of time (usually forty-eight hours or more).
Some DCS/DAS vendors will further stress test the system in an overheated envi-
ronment by cycling the AC power supply and increasing the surrounding tempera-
ture to 50ºC or more.
Stress testing is done to eliminate the “infant mortality” associated with com-
puter components. Infant mortality is the expression used to describe the tendency
of a component that is destined to fail to do so very early in its life. For a compo-
nent that survives this early period, the rate of component failure will drop to a
low level for a long period of time and then increase again as the aging process
takes over. As Figure 8-20 shows, the curve that expresses this process takes on
the shape of a bathtub.

Figure 8-20. Mortality of DCS/DAS Components As a Function of Time

The time required for staging is considered time very well spent, even (espe-
cially) when a project is on a tight schedule. Component failures that occur on site
during startup can cause frustrating delays that are readily avoided by the staging
process. In addition, staging ensures that there are no missing cables, connections,
or system components when the DCS arrives at the site.
SYSTEM FUNCTIONAL TEST
The system functional test is similar to staging except that it focuses on the
configuration rather than the DCS/DAS hardware. This service involves assem-
bling and powering up the system with the system software programs, and it also

43
Distributed Control Systems / Digital Automation Systems

includes the configuration software. The purpose of this test is to eliminate prob-
lems in the loops and logic of the particular application. Inputs and outputs are
verified and simulated, and logic interlocks and loops are flexed.
Generally speaking, this service is best performed off site, away from the dis-
tractions of the plant. The time required for a functional test should be two or
three weeks for everything from assembly through testing, re-crating, and reship-
ping. The advantage of the system functional test is that it allows the vendor's
technicians to identify and correct problems under conditions that are as close as
possible to ideal. Troubleshooting on the job is difficult at best. Besides the
distractions and the pressure to perform once startup has occurred, isolating the
source of the problem is often more complicated. In other words, is it the system
configuration or is it the field equipment?
TRAINING
Every manager wants his or her staff properly trained in running the control
system as well as diagnosing and repairing it. Most project specifications call for
some combination of off- and onsite training. Off-site training is usually done in a
formal classroom setting by instructors who are often, but not always, full-time
professionals. Ideally, the classroom instruction is supplemented by hands-on lab-
oratory work.
Onsite training has the advantage that it is done with the actual equipment that
will be operated. On the other hand, the instructor is often an installation techni-
cian who, though knowledgeable about the system, can be greatly lacking in teach-
ing ability. In addition, onsite training is frequently a cram session in which too much
information is passed on too quickly for the operator to really absorb it effectively.

Because the importance of training is often undervalued, what little is done is

often of little use. A proper training program can involve the development of quite
an elaborate master plan. A good one takes into account the actual and required
skill levels of the people who will have to deal with the DECISion/DAS. It will in-
clude all the training programs necessary to take individuals from their actual to
future skill levels. This learning is best done over an extended time so it is effec-
tive and, therefore, useful. Training courses that are part of the master plan may
come from any number of sources, including vendors, local colleges, owners’ in-
house programs, and so on.
Finally, training should be seen as an ongoing process, in which refresher
courses are part of the overall plan. The world of DCS/DAS is closely connected
to computers and therefore evolving at breakneck speed.

System Documentation
System documentation consists of the process of collecting written materials
and electronic media that describe the DCS/DAS. Ideally, it must be complete
enough to tell an owner everything he or she needs to know about the system. At
the same time, it must be as easy to use as picking up a phone and calling the ven-
dor. Anyone who has used a personal computer and any assortment of available
software knows how difficult it is to end up with “ideal” documentation.

Maintenance
Placing an order for a DCS/DAS signals the start of an owner's concern with a
number of factors involved in the satisfactory operation of the system. These in-
clude site preparation, mounting hardware, installation time, staging, documenta-
tion, commissioning, training, and finally maintenance.

44
 Maintenance

Although the design of today's modern digital circuits promotes minimal

maintenance and a high degree of self-monitoring, an owner still needs to know
how such circuits work and how they should be maintained.

Flexible Level of Support Programs

Historically, a plant provides the level of maintenance for its DCS/DAS sys-
tem that will most effectively provide satisfactory operation at a reasonable cost.
The strategy for supplying effective maintenance has to be worked out by both the
user and the manufacturer. Manufacturers are generally quite willing to work
closely with customers to help them become familiar with things.
For smaller systems, many customers are interested in doing as much as pos-
sible with their own resources. This is to be encouraged as long as it does not re-
sult in an operational hazard or equipment damage. When it comes to complex
maintenance activities (those requiring specially trained service personnel) the
owner should consider a higher level of maintenance support. Choosing the com-
bination of support services that best fits the needs of the customer will lower
product costs and promote higher quality. Since a DCS/DAS can be considered a
production tool, its real value depends on how effectively it is used. A well-de-
signed maintenance program adds to this effectiveness.
As shown in Figure 8-21, a reactive maintenance philosophy of replacement
and repair shortens a system’s life. The more proactive approach of preventive
and predictive maintenance extends the life of the system. However, the payoff re-
ally occurs when operational services and system upgrades are provided. Then
system life is extended almost indefinitely, and the DCS provides greater func-
tional value.

Figure 8-21. DCS/DAS Value As a Function of Maintenance Approach

(Courtesy of Honeywell, Inc.)

45
Distributed Control Systems / Digital Automation Systems

Categories of Maintenance
Every organization has its own maintenance philosophy. It is up to manage-
ment to determine what overall approach to maintenance is needed to achieve ac-
ceptable reliability for the DCS or DAS.
Maintenance can be seen as falling into three categories:
(1) Enhancement maintenance
(2) Preventive maintenance
(3) Corrective maintenance

Manufacturers and designers will customize their programs to meet users’ re-
quirements in these three areas.
ENHANCEMENT MAINTENANCE
Enhancement maintenance involves using the most recent releases of hard-
ware and software, which have been redesigned for improved maintenance and
functionality. Keeping a DCS at current revision levels provides a cost-effective
way of operating at peak performance.
The DCS manufacturer can implement software enhancement and support
programs in three different ways:
(1) Through periodic software enhancements issued to the customer
(2) Through technical engineering assistance made available to the cus-
tomer at any time
(3) By the manufacturer managing the client's DCS documentation
PREVENTIVE MAINTENANCE
The intent of preventive maintenance is to keep a system from breaking down
Experience indicates that the by providing regular equipment inspections. Since there is no obvious immediate
ratio of the cost of preven- benefit to this type of maintenance, it can vary widely according to individual
tive maintenance to the cost
of repair and replacement is preferences (and perhaps to the salesman’s skill in selling the idea). It is up to
about 1:2. management to provide a structure that will produce a balanced program that uses
in-house resources together with the support programs offered by the systems
manufacturer.
CORRECTIVE MAINTENANCE
Corrective maintenance consists of performing qualified repairs to a system
that has failed and thereby returning the system to its original usable condition.
Providing this type of service on such a complex integrated system as a DCS or
DAS can be a formidable challenge for both plant maintenance departments and
equipment vendors.
Owners must find an efficient way to supplement their in-house capabilities
with outside industrial support groups. It is very important that such outside sup-
port services be provided by an experienced team and with the same promptness
that the user would provide with his or her own resources, had they been avail-
able.

Service Contracts
Each organization has its own maintenance philosophy and must, therefore,
determine what service program suits its needs best, so the DCS/DAS remains
available, capable, and dependable. The service activities needed to support a
proper program of maintenance are shown in Figure 8-22.
A variety of services are available from outside firms, including:

46
 Maintenance

(1) On-call service

(2) Equipment maintenance
(3) Equipment or system audits
(4) Maintenance service retainers
(5) System utilization services
(6) Software support services
(7) Resident field engineers

Figure 8-22. Maintenance Support Activities

On-call service is service done by a support group that maintains well-trained

service engineers who are capable of troubleshooting nearly any DCS or DAS.
Equipment maintenance is done according to a contract in which routine pre-
ventive and corrective maintenance is performed by a qualified engineer located
in the general area of the client.
Equipment or system audits are done according to an agreement that includes
periodic review of system performance by a qualified engineer who is familiar
with the process that the DCS/DAS system is controlling. This sometimes in-
cludes added features, such as extended support journals, semiannual performance
reviews, technical support with PC computer-based bulletin boards, and so on.
Maintenance service retainers are agreements whereby on-demand service is
made available at a level of so many days, at an agreed cost per day, and for a
specified term. Emergency demand service is not the same thing. It means deliver-
ing adequate service support in time to avert possible downtime. This would be an
extra cost to the retainer.
System utilization services are provided according to an agreement whereby a
process specialist is scheduled to actually operate the process in order to optimize
it for the customer.
Software support services are provided via telephone system and modem,
usually by qualified systems and application engineers. This can include periodic
system update letters, software updates, and remote diagnostics.
Resident field engineer services involve an agreement in which an engineer
resides in the immediate area of the client's plant and reports to work only at that
plant.
Note that the organization that supplies service support may be the original
equipment manufacturer or a sophisticated repair center established by a third
party. Third parties can provide maintenance and repair for laboratory, industrial
process control, and electronic test equipment. This support can include warranty
and nonwarranty service, as well as installation and startup assistance.

47
Distributed Control Systems / Digital Automation Systems

Purchasing Strategies
DCS purchasing strategies will vary depending upon whether the decision
taken is to completely replace a system or to expand and upgrade hardware and/or
software to newer versions. The following sections outline the different options
that can be considered.

Long-Term Buying
A DCS or DAS must be purchased in the context of a long-term management
commitment. Planning in advance for such a purchase will ensure that answers are
more readily available when problems occur. Some of the factors to be considered
in such long-term purchases are:
(1) System effectiveness
(2) Technical performance
(3) Capability
(4) Availability
(5) Support effectiveness
(6) Reliability
(7) Maintainability
(8) Safety
(9) Accessibility
(10) Software configuration
(11) Quality
(12) Software enhancement

System effectiveness is the ability of the system to sustain successfully the

overall system demand within a given time when it is operated under specific con-
ditions. It also can be characterized as capability, function availability, and sup-
port effectiveness.
Technical performance is similar to technical capability but often additionally
means a measure of what total technical support the manufacturer can offer.
Capability is a measure of how well a system performs.
Availability is the probability that a system will operate satisfactorily and ef-
fectively when it is needed or used to control a process under specific conditions.
Support effectiveness is the service support that is required to sustain the
equipment and keep it operating effectively by furnishing it with whatever en-
hancement it needs.
The reliability of a system is the probability that it will perform as intended
without failure for a specific time period under specific design conditions.
The maintainability of a system is its inherent capacity to have technical
knowledge and management skills applied to it so it can be effectively operated
and efficiently maintained.
The safety of an overall system is an assessment that both system and human
safety levels are attained whenever the system is used.
Safety design is of great importance because it protects the system against failure
and breakage and eliminates the hazardous conditions that can cause operating
accidents and injury.

48
 Purchasing Strategies

Accessibility is the ease with which personnel can access a control system to
attend to an assembly or subassembly, as well as that system’s capacity to quickly
yield answers to specific questions.
Software configuration is what an organization must consider in terms of
physical properties and functional characteristics in the makeup of a DCS. The de-
sign of the DCS’s hardware/software must be intelligently engineered, and the
specific system configuration installed at the plant must satisfy that customer's
needs.
The quality of equipment and service is especially important for reducing a
system’s downtime. Quality means that the system should be at least 99 percent
fault-free. DCS suppliers must have the capability to provide quality in both prod-
ucts and services.
Software enhancements must be considered so that the system's functionality
can be expanded or improved with every new product the manufacturer releases.
Software enhancements provide the platform for new system applications by add-
ing new system functions, improving system performance, and introducing new
technology innovations.

Expanding and Upgrading

When it comes to the expandability of a DCS, modularity is often the only
thing considered. Unfortunately, in most cases, there is no discernible difference
from one DCS to another in modularity. All DCSs are modular by nature and,
therefore, expandable. The only difference among them is where the “break
points” are in terms of add-ons. The term break point refers to that number of in-
puts and/or outputs beyond which additional hardware is needed—sometimes at a
dramatically increased cost. It is possible for the addition of a single point to ne-
cessitate extra cabinetry, power and communication modules, and data highways.
The unseen difference in system expandability often lies in its backwards
compatibility and its upgradability. All DCS designs are changing constantly and
at a pace unfathomable to most laymen. Computer chips can become obsolete
within months. DCS vendors have to keep up with such changes to stay competi-
tive. In addition, customers are constantly demanding added functionality. As a
result, software is continuously being written and integrated into vendors' sys-
tems.

Dealing with Obsolescence

The constant evolutionary change of DCS/DSAs has both good and bad as-
pects. The good news is that costs will drop while the systems become easier to
use, more powerful, and less human-labor intensive. This makes for more effi-
cient and competitive plant operations. The bad news is that system components
will become obsolete (and therefore costly to support, repair, and replace) and will
require a program of continual upgrades to stay current.
Many current DCS owners find that new, more powerful modules or even
whole new systems come on the market less than a year after they made the initial Technological advance-
purchase. The question for them then becomes whether to buy the “slightly out- ments made in the past six
years are the leading cause
of-date” version and make it compatible or update to the “new” technology. It is a of process control system
complex decision and poses the risk of potentially skyrocketing costs. obsolescence. The availabil-
Costs can be excessive in either case. Older components can become very ity of replacement parts and
costly after their manufacturer discontinues them or they are pronounced obsolete. services for pre-1990 control
systems is limited.
They then become more difficult to get repaired. Spares and technical support are
harder to obtain and are more expensive. Upgrading existing equipment can also
be an expensive proposition, depending on the design of the system. This is one
area of real differentiation between vendors. Every vendor will swear to “back-

49
Distributed Control Systems / Digital Automation Systems

wards compatibility” and, to some extent, will have it. But there are systems with
good compatibility and others with very poor compatibility.
It is often a good idea to review the R&D program of the vendors you are con-
sidering. This will indicate what the outlook for the firm is for the future and will
give you a better perspective on their product. Their R&D program is also a good
barometer of the company's stability and commitment to the product. Having one
or two years of system upgrades built into the project is a good insurance policy.

Upgrading a DCS
Obsolescence can be avoided by identifying an “upgrade path.” In other
Most reputable companies words, find out exactly how upgrading will be done. Some of the options are:
will guarantee the availability
of a product for around ten (1) Upgrade the system software only.
years after it has been dis-
continued. Get it in writing! (2) Upgrade both the system and configuration software.
Read the guarantee and un-
derstand it. (3) Upgrade hardware modules that have been modified with system soft-
ware.
(4) Use all new hardware and software.

Understanding the relationship between a vendor's hardware and software

will make it easier for plant personnel to decide on the “what and when” of up-
grades. For example, a plant ought to consider upgrades to a DCS that will not be
expanded. Keeping a DCS up to date is a good way to protect one's initial invest-
ment.
With an appropriate program of upgrades, a plant can avoid the wholesale re-
placement of an older system that has become obsolete.
This sort of upgrading means that, after a couple of years, when significant (to
the user) functional improvements have been made, the plant has brought the sys-
tem up to the current technology. This spreads out the costs and implementation
time entailed in making DCS changes. If it seems that few functional changes are
taking place in a system, chances are the manufacture isn’t investing in R&D. If
this is the case, it would be wise to hold off on an upgrade and perhaps even look
at alternatives systems.
Upgrade paths will vary from vendor to vendor. Some will be more costly and
difficult than others. Some require downtime; others do not. As much as possible,
find out what is likely to be involved before making a final selection. Talk to other
users to get a feel for what they have done. This will often be a good indicator of
things to come.

Migration Solutions

Example 1: Hybrid DCS / HMI

An alternative to expanding and upgrading a DCS with the same vendor parts
is to consider a hybrid solution, as shown in Figure 8-23. Because of cost con-
straints and limited production downtime, the plant in this example opted for a hy-
brid solution that consisted of replacing obsolete operator stations with an off-the-
shelf HMI and then integrating these into the existing plant architecture. A graph-
ics converter was used to convert the DCS graphics to the HMI format. Minor
modifications to the graphics were required. A standard interface provided by the
DCS vendor was added between the HMI and the DCS network.

50
 Migration Solutions

Business
LAN QNX Network

Busin ess
LAN

EXPERT APP SERVER EXPERT APPS CLIEN T HMI H MI PCV PC V

SCADA1 CL IENT CLIENT SER VER
C IU CI U CIU

Bailey LAN

GPI

PCU1 PCU2 PCU3 PCU4 PCU 5 PCU6 BRID GE MCS 1 MCS 2

Modbus plus

GPI

BR IDGE

PLC PGM PLC1 PLC2 PLC3 PLC4 VFD DRIVE 1 DRIVE 2

STATION DRIVE

Figure 8-23. Hybrid Solution: DCS / HMI integration

Example 2: Digital Automation Systems

Although at one time state of the art, proprietary DCS systems are challenging
to maintain and not as reliable, secure, robust, or scalable as standards-based,
high-speed, digital automation systems. However, the interoperable nature of a
digital automation system enables it to be connected with DCS and PLC systems
to do the following:
• provide scalability
• incorporate new bus technology
• improve process optimization
• lower maintenance costs
• integrate smart diagnostics.
A digital automation system offers multiple migration techniques that enable
process manufacturers to choose the best solution for their transition to a digital
automation system. The solutions presented here all ensure minimal downtime
and a phased approach to the migration process. Over time, the digital automation
system will completely replace the proprietary system.
CABLE CONNECTION
The controllers in a digital automation system can connect to the existing ter-
mination panel of a DCS by using a trademarked cable and a mass termination
block. After simply connecting the cables, personnel use software running in the
digital automation system to verify input/output configurations. The software then
either connects directly to the controller or uses OPC to set up communications.
The digital automation system then uses file-conversion utilities to translate and

51
Distributed Control Systems / Digital Automation Systems

replicate DCS graphics and engineering configurations such as batch applications.

Also, as time permits, it is easy to build high-resolution graphics in the digital au-
tomation system. Once these steps are completed, advanced control applications,
such as tuning, may be applied to quickly get the process to optimum capacity.
This solution uses existing wiring and engineering configurations, doesn’t disturb
field connections, eliminates engineering configuration, and produces minimal
downtime.

Figure 8-24. DAS Connectivity to Existing DCS

(Courtesy of Emerson Process Management)

Some process manufacturers will use a serial interface and MODBUS proto-
col to set up communications between the proprietary system and the digital con-
trol system. This solution uses a serial I/O card in the digital automation system
controller with a serial communications link. This requires the use of custom-writ-
ten drivers for both ends of the serial link. Some types of proprietary systems will
necessitate the use of this migration method.
CONSOLE CONNECTION
An OPC server gets data from the proprietary control system, puts the data
into a standard format, and is read by an OPC-compliant client. Normally, a server
provides data to clients only. However, a digital automation system makes possi-
ble data sharing between OPC servers. This functionality links not only to the
control system but to all plant subsystems. This creates plantwide interoperability
at the workstation level.

52
 Conclusion

Conclusion
The process control paradigm has changed. Where once it was advantageous
to use a proprietary system, doing so now hinders a firm’s competitive advantage
in the global workplace. The technological revolution has placed great demands
on process manufacturers to reduce plantwide costs and process variability while
simultaneously increasing plant performance and efficiency. Completely digital
automation systems harness the intense memory and processing power that is now
available to help process manufacturers achieve their goals of reducing costs and
process variability while increasing performance and efficiency.
A digital automation system is built to open, interoperable standards. High-
speed communications technology enables terabits of data to pass through intra-
nets and the Internet. Standards-based digital automation systems take advantage
of this by passing process information through the DAS as well as across the In-
ternet and seamlessly interacting with a multitude of other applications.
Devices at the edge of the network are smart and capable of passing a wealth
of information to a digital automation system. The capacity to process and pass on
this information efficiently and effectively distinguishes a digital automation sys-
tem from legacy systems. Immensely increased functionality such as predictive
maintenance, asset management, comprehensive batch solutions, and embedded
advanced control are additional distinguishing factors of a digital automation sys-
tem. By efficiently processing this increased wealth of information, digital auto-
mation systems are enabling process manufacturers to get the most out of their
capital investments, optimize their processes, work in safer environments, and ul-
timately produce best-in-class products.
Finally, digital automation systems are keeping up with technology. Their de-
sign and functionality make them an enabling technology, not an end in them-
selves. As technology changes and new standards are set, digital automation
systems, unlike legacy systems, are positioned to embrace the new and continue to
assist process manufacturers in meeting their multiple goals.

References
(1) Lukas, Michael P. Distributed Control Systems. New York: Van Nos-
trand Reinhold, 1986.
(2) Taylor. MOD 300 — Overview. Rochester, NY: ABB Kent-Taylor.
(3) Foxboro Co. Intelligent Automation Series: Hardware Overview. Fox-
boro, MA: The Foxboro Company.
(4) Rosemount, Inc. System 3. Eden Prairie, MN: Rosemount, Inc.
(5) Honeywell, Inc. TDC 3000 Bookset Directory. Minneapolis, MN: Hon-
eywell Inc.
(6) ANSI/ISA-71.04-1985 - Environmental Conditions for Process Mea-
surement and Control Systems: Airborne Contaminants. Research Tri-
angle Park, NC: ISA – The Instrumentation, Systems, and Automation
Society, 1986.
(7) ISA – The Instrumentation, Systems, and Automation Society. The
RPGO Series of Recommended Practices for Control Centers. Research
Triangle Park, NC: ISA – The Instrumentation, Systems, and Automa-
tion Society.

53
Distributed Control Systems / Digital Automation Systems

(8) Wade, H. L., eds. Distributed Control Systems Manual. Research Trian-
gle Park, NC: Instrumentation, Systems, and Automation, 1991.
(9) Herb, S. M., and J. A. Moore. Understanding Distributed Process Con-
trol. Research Triangle Park, NC: Instrumentation, Systems, and Auto-
mation, 1987.

About the Authors

Helen Beecroft has twenty-five years of experience in the development
and design of instrumentation and process controls for application in the ce-
ment industry, among several others. As Electrical and Automation Director
for the Lafarge Corporate Technical Services, Ms. Beecroft is responsible
for developing, managing, and directing major aspects of Lafarge’s North
American electrical and automation initiatives. These include implementing
and upgrading factory-wide integrated control systems and manufacturing
applications from the specification and procurement stage through to the de-
sign of standards, databases, and graphics as well as start-up, system analy-
sis, and operator training. A graduate of Concordia University in Montreal,
she earned the Bachelor of Science degree in Physics. She is an active ISA
member and president of the ISA Montreal Section.
Jim Cahill is the communications director with Emerson Process Man-
agement systems business unit and successfully launched the DeltaV system
in 1996. A graduate of the University of Texas at Austin in Electrical Engi-
neering, and an MBA from University of New Orleans, Jim has worked as a
systems engineer with Conoco before joining Emerson in 1988.
We wish to thank Maurice L. Pyndus, Alberto J. Dufau and Daniel D.
Bellefontaine for their contributions to the original chapter on Distributed
Control Systems, PGS Fundamentals published in 1992.

54