4.
10 DCS: Integration with Other Systems
T. L. BLEVINS, M. NIXON (2005)
Types of DCS System Interface:
Partial List of Suppliers:
INTRODUCTION
The reinstrumentation of an existing process or the con-
struction of a new plant often involves interfacing to intel-
ligent external devices or subsystems. For example, the
safety system that protects a critical piece of equipment
may be an integral part of and is provided by the equipment
manufacturer.
Devices as a motor starter may include embedded logic,
diagnostics, and support for digital communications to access
this added information. When an existing plant is being
expanded, the process control system selected for the expan-
sion may not be the same as that used in the existing plant.
To provide safe and efficient plant operation, it is important
to fully integrate these external devices and subsystems into
the new control system.
Integration provides the plant operator with a single win-
dow interface into all functions of the complete process.
Related process information may be included in the operator
displays. This way, the operator is provided with consistent
presentation of process alarming and trending and consistent
means of changing set points or modes of operation. This
makes it possible to provide a single login and span of control.
EXISTING SYSTEMS
When a new plant area is added or expanded, the operators
often need to know the conditions in the existing plant section
in order to maintain a coordinated operation. Similarly, the
700
2006 by Bla Liptk
Safety
system
PSH
230 UC
400
PS PS
220 250
Flow sheet symbol
A. OPC server
B. Serial interface
C. DCS gateway
ABB (A, B, C) (www.abb.com)
Allen-Bradley (A, B, C) (www.ab.com)
Emerson (A, B) (www.EasyDeltaV.com)
Honeywell (A, B, C) (www.honeywell.com)
Invensys (A, B, C) (www.invensys.com)
Schneider (A, B, C) (www.schneider.com)
Siemens (A, B, C) (www.siemens.com)
Yokogawa (A, B, C) (www.yokogawa.com/us)
operators of the existing plant will also need to have feedback
from the new process area to enable them to make decisions
on how best to run the balance of the plant. In most cases,
only a small fraction of the information in either system must
be communicated to support such coordination between pro-
cess areas or plant sections.
Three techniques that have been successfully used to
support the exchange of such information serving plant inte-
gration (Figure 4.10a) are:
1. OPC interface
2. Serial interface to highway gateway
3. Serial interface to serial port
A fourth technique is to hardwire the measurement signals
to more than one system. This method is not illustrated here,
although it is often used when only a small number of signals
are involved in the interface.
MODBUS Interface
MODBUS, a specialized network for use with other open
networks, was developed for use on the Modicon Company
proprietary network. MODBUS can be implemented over any
transmission medium but is most often seen on RS-232 and
less often on RS-422 or RS-485. It is a serial transmission
technique that uses master/slave arbitration and is discussed
in detail in Volume 3 of this handbook. MODBUS can trans-
fer 300 registers per second at 9.6 kB and can communicate
 4.10 DCS: Integration with Other Systems 701

OPC OPC
server server

1
OPC interface

Controller Controller

Highway
gateway
2
Serial interface

3
Serial interface
New control system
Existing control system

FIG. 4.10a
Three methods of integration of an existing DCS system and a new control system can be obtained by the use of three types of interfacing:
1) OPC interface, 2) serial interface to highway gateway, or 3) serial interface to serial port.

in half-duplex style with up to 247 slaves. MODBUS Plus is
an RS-485 based, peer-to-peer network protocol that trans-
mits at a rate of 1 mB.
Many new and existing DCS systems include a hardware
interface that utilizes a common communication protocol
such as MODBUS block transfer of information from other
devices. In some cases, this serial interface may be redundant
to improve system availability. If such interface exists, it may
be the least expensive method of exchanging information
between the systems.
MODBUS is a popular method for moving data values
between systems, but if the updating frequency cannot be
longer than 1 second, it can handle only a few hundred signals.
It is an application layer messaging protocol, positioned at
level 7 of the open system interconnection (OSI) model, which
provides client/server communication between devices con-
nected on different types of buses or networks. MODBUS
support is provided across both serial and transmission
protocol/Internet protocol (TCP/IP) networks, as illustrated in
Figure 4.10b.

MODBUS Application layer

MODBUS on
TCP

TCP

IP

MODBUS+/ Master/Slave Ethernet 802.3

Other
HDLC
EIA/TIA-232 or Ethernet physical
Other layer
Physical layer EIA/TIA-485

FIG. 4.10b
Integration of existing and new DCS systems using MODBUS interfacing.

2006 by Bla Liptk

702 Control Room Equipment
Support for MODBUS continues to be strong. Most ven-
dors have built-in support for master/slave stacks over serial
and/or TCP/IP. The Internet community can access MODBUS
at a reserved system port 502 on the TCP/IP stack.
Some manufacturers may also provide a gateway device
that can be used to interface to external systems. These
devices are often provided to connect different revisions of
equipment from the same manufacturer. Thus, such interfaces
may rely on a proprietary communication protocol and limit the
types of information that may be accessed through this interface.
OPC Interface
OPC (OLE for Process Control, where OLE stands for Object
Link Embedding) is based on Microsoft Windows COM
(Component Object Model) architecture. OPC was developed
by the OPC Foundation and provides standard software inter-
1
face to hardware databases. The three basic types of servers
it provides are for 1) data access, 2) alarm and events access
and 3) historical data access, as shown in Figure 4.10c.
Most modern process control systems support informa-
tion exchange based on the OPC Foundations Data Access
Specification Version 3.0, March 2003. This process industry
standard was created through a collaborative effort of leading
automation suppliers and Microsoft. The specification defines
a standard set of objects, interfaces, and methods that facil-
itate data interoperability. Many manufacturers offer OPC
servers that may be added to older DCS systems. Where such
capability exists, it is to exchange a large number of readings
between control systems.
On the other hand, the OPC approach has several disad-
vantages. One is that the addition of the OPC servers may
be more costly than using a serial interface (Figure 4.10a).
These interfaces tend to be time consuming to configure
Alarm Graphics Trend
display display display
OPC Alarm/Event OPC Historical
Alarm server Trend server
(SQL) (SQL)
OPC Data access
Conven- Any Most
Fieldbus tional MODBUS legacy
FIG. 4.10c
The three types of OPC servers are: 1) DA, data access, 2) A&E,
1
alarm and events, and 3) HAD, historical data access.
2006 by Bla Liptk
often requiring duplicate configuration to map parameters
from one system to another. The interfaces also tend to lack
basic features such as holding last value on configuration
download, upload, and integrated parameter security. Also,
such an interface often is not redundant and thus should be
used only where temporary loss of communication will not
impair plant operations.
The latest OPC standardization efforts are making impor-
tant improvements to the data model, in integrating data
sources such as alarms, and in supporting a much more capa-
ble Web Service Style interface.
One of the biggest challenges in DCS system integration
is the fact that each control implementation may represent
control parameters in a different manner. Take for example
the representation of the operating mode of a controller. Some
control systems implement the control mode as two separate
parameters, i.e., local/remote and auto/manual, while other
systems represent the control mode as a single parameter,
i.e., manual/auto/cascade/remote-cascade/remote-out.
Where such differences exist, the basic calculation fea-
tures of the old controller can be used to create a proxy in
the new controller to map these parameters to their equiv-
alent representation in the new control system.
Looking ahead, several developments are underway that
promise to make the integration easier. Perhaps the most
significant of these is again OPC. The OPC standardization
efforts, recognizing the importance of extensible markup lan-
guage (XML), software componentization, and Web services,
are moving forward with new standards that combine existing
data models on top of new service frameworks.
For example, real-time, alarms and events, and history
models are being combined. Once combined, a single client
will be able to browse to locate the data of interest, subscribe,
and then retrieve real-time data, alarms, and events, as well
as history. These newer models also address problems related
to consistent naming and consistent use of the status/quality
attribute.
Consistent/standardized naming would allow clients to
reconcile the naming differences between systems the
same OPC path would always refer to the same data. The
standardization would also define how status is assigned.
OPC servers would be expected to use a consistent status
when communicating and receiving data from devices. Uni-
formity in the assignment of status by OPC servers would
improve the consistency of clients.
Other standardization efforts, including the Fieldbus
High-Speed Ethernet and PROFIBUS PA, are extending the
reach of device networks. These standards provide capabilities
to integrate devices across much higher-speed networks.
MOTOR CONTROLS
Analog measurements and actuator signals represent only a
fraction of the total inputs and outputs of process control
systems. The remaining inputs and outputs are discrete. They

Process controller
Low voltage
control output and
discrete status
input
Traditional motor starters
FIG. 4.10d
Traditional and fieldbus-based interfacing of motor starters.
often are associated with motor control, position sensing, and
the operation of on/off valves.
The motor control interface for a DCS system often con-
sists of low-voltage discrete outputs from a controller wired
to motor starters. Controller feedback of the motor start relay
status (M contact) and associated conditions are provided
through discrete inputs. The installation cost of this approach
may be quite high because of the requirement for the instal-
lation and checkout of the large number of wires. Also, diag-
nostic information that may be available locally at the motor
starter may not be remotely accessible, or may be too costly
to access as discrete inputs.
Significant advances have been made in motor starter
designs that allow more compact packaging. New fault diag-
nostic capability is also often available for the detection of
power loss, sensor input circuit short and phase imbalance,
phase currents, full-load current, and thermal capacity for
easy troubleshooting and quick restarting.
Also, most manufacturers provide integrated add-on
communication interfaces for the motor starter and local
input hand-off-auto selectors and pushbuttons. For many
applications, this can reduce the quantity of wiring plus sim-
plify connections and thus can reduce installation and main-
tenance costs, as illustrated in Figure 4.10d.
Fieldbus Interface
The fieldbus communication interface with motor control
equipment is often specific to the manufacturer. Some of the
most popular intelligent motor starters offer either Profibus
DP, AS-Interface, or DeviceNet communication. Thus, mod-
ern process control systems are often designed to support a
variety of communication interfaces.
2006 by Bla Liptk
4.10 DCS: Integration with Other Systems 703
Process controller
Fieldbus
Fieldbus motor starters
The logic associated with motor start, stop, interlocks, and
permissive constraints is typically implemented in the process
controller. Such logic may have been designed and imple-
mented using ladder logic. However, it is possible to standard-
ize motor control logic as a function block. One example of
this is the Device Control block as defined by the Fieldbus
Foundation Function Block Application Process Specifica-
tion, Part 3. A variety of applications including single- and
multiple-speed motors with permissives and interlocks may
be addressed using this the Device Control block.
Integrating devices such as motor starters with control
systems has become considerably easier with standards such
as Fieldbus and Profibus. More recent standards such as
FDT/DTM (see below) are further simplifying the integration
of device configuration and operation by defining a common
parameterization format. Together, the Field Device Tool
(FDT) and Device Type Manager (DTM) provide a config-
uration front-end and driver-like back-end, similar to printer
drivers today, to support the configuration and communica-
tion interfaces to devices.
SAFETY SYSTEMS
Safety instrumented systems (SIS) is responsible for taking
the process to a safe state when predetermined conditions are
violated. The safety system includes the hardware, software,
and all field equipment necessary to perform the desired
operations to reach a safe state. Because of the critical role
these systems play in plant operation, their design and imple-
mentation are normally based on accepted standards, such as
IEC 61508, IEC 61511, and ANSI/ISA 84.01. In such designs,
the process control system is typically separated from the
704 Control Room Equipment

Hardwired
shutdown
switch

Process controller
Serial interface
Safety system

PT PT
I/P Solenoid 22 21
23

Process
FT
23
Blocking valves PT
23

FIG. 4.10e
The integration of the safety instrumented system (SIS) into the overall process control system.

SIS (Figure 4.10e) to avoid the need for all process control
systems to meet SIS requirements.
As it is illustrated in this example, the process input
signals to the safety system are separate and independent
from those used by the process control system. The outputs
of the safety system are also designed to act independently
from the process control system. For example, a solenoid
valve may be placed into the air tube between the I/P con-
verter and the control valve actuator.
In this configuration, when the SIS system requires that
the solenoid be energized, it will cause the control valve to
take up a safe position, i.e., open or closed. Also, the safety
system output may activate blocking on/off valves that stop
or divert process streams from their normal flow-paths,
regardless of the signals received from the process control
system.
As the safety system overrides the normal operation of
the throttling control valves of the process control system
and prevents the controllers from returning their controlled
variables to set point, the integral action is likely to saturate
the controllers output. The consequence of this is that when
the SIS system returns to normal, the control loop output is
still saturated and is not ready to take control.
To avoid any upsets this could cause, when the safety
system returns to normal, it also provides a status input to
the process control system. If the process control system has
maintained or memorized the controller output that existed
before the SIS episode, that output value can be automatically
set to provide smooth recovery.
The safety system status may be simply provided to the
process control system as a discrete input. However, a serial
link is typically used to provide status and other information
concerning the safety system. Through this link, such infor-
mation as first-out indication of the cause of action, status of
blocking valves, flame sensor indication, etc., may be com-
municated to the process control system and included in the
operator interface.
Operator requests such as initiate shutdown or reset
the safety system may also be added to the operator interface
and communicated to the safety system. However, even if
this capability is provided, an independent hardwired inter-
face is normally required for the operator to manually initiate
shutdown.
To reduce the effort required to integrate information
from a safety system into the process control, some process
control system manufacturers offer special controllers designed
for the execution of safety system logic. Alternatively, inde-
pendent hardware components may be added to a standard
controller for the execution of the SIS logic as illustrated in
Figure 4.10f.
When a manufacturer provides SIS controller support
as part of the process control system, information and
alarms from the SIS controller are available for use in the
operator interface without the need to map such information.
Also, this approach may allow the same tools that were
used to engineer the control system to also be used for the
configuration and checkout of the SIS system. Using a
common set of tools allows the user to easily integrate
parameter access, alarming, history collection, span of
control, diagnostics, and security. Advanced features such
as configuration audit trail and authorization can also be
provided.

2006 by Bla Liptk


SIS controller Process controller
FIG. 4.10f
The system configuration if SIS controller support is available in
the process control system.
CONCLUSIONS
Modern process control systems support a variety of com-
munication interfaces. These may be used to integrate infor-
mation from intelligent external devices, subsystems, and
existing DCS systems into the total process control system
of the plant. Where the products of several manufacturers are
used, it may be necessary to implement proxies in the con-
troller, which can be used to map the information from these
other suppliers to its equivalent representation in the total
control system of the plant.
2006 by Bla Liptk
4.10 DCS: Integration with Other Systems 705
Reference
1. Berge, J., Instrument Engineers Handbook, Vol. 3, Section 5.4, Joint
publication of CRC Press and ISA, 2002.
Bibliography
Fan, X.-G., Wang, Z., Sun, Y.-X., and Wang, L., OPC Based Ethernet Control
and Management, Information and Control, Vol. 32(2), pp. 113117,
2003.
Hoon, P. S., and Huan, Y. R., FOUNDATION Fieldbus Systems Integra-
tion Using OPC, Technical Papers ISA, Vol. 397, pp. 143152,
1999.
Janke, M., OPCPlug and Play Integration To Legacy Systems, IEEE
Conference Record Annual Pulp and Paper Industry Technical Con-
ference, pp. 6872, 2000.
Kleines, H., Zwoll, K., and Sarkadi, J., Integration of Industrial Automation
Equipment in Experiment Control Systems via PROFIBUS
Developments and Experiences at Forschungszentrum Julich, IEEE
Transactions on Nuclear Science Ns, Vol. 47(2p1), p. 229, 2000.
Luth, J., OPC Brings XML-DA to the Factory Floor, Control Solutions,
Vol. 75(7), pp. 3436, 2002.
Macias-Hernandez, J. J., and Feliu, J. A., Dynamic Simulation and OPC,
Hydrocarbon Engineering, Vol. 8(9), pp. 5358, 2003.
OPC DA 3.00 Specification, Data Access Automation Interface Standard,
www.opcfoundation.com, 2003.
PROFIBUS Organization, Specification for PROFIBUS Device Description
and Device Integration Volume 3: FDT V1.1, Karlsruhe, Germany,
November 2000.
Spear, M., Bridging the Data Gap, Process Engineering, Vol. 81(3), p. 25,
2000.
Wang, X. Z., Garcia-Flores, R., Hua, B., and Lu, M. L., Advanced Informa-
tion Systems for Process Control and Supply Chain Integration, Com-
puter Aided Chemical Engineering, Vol. 15(A), pp. 636641, 2003.