04

4
Configuration and
Scripting
This chapter’s focus is implementation at the automation system
level. The execution and business levels are briefly covered in
Chapter 5. Implementing automation system software requires
software configuration and possibly some scripting. OPC,
ActiveX, VBA and other software technologies have been made
very easy to use, almost invisible to the user. Most configuration
is a matter of pointing, clicking, and filling in some blanks.
Configuration details are product-specific and explained in
product manuals. This chapter’s purpose is to give a general idea
of the steps involved in bringing data from device networks,
detecting alarm conditions, logging and displaying alarms, and
issuing reports.
Live Data Interface (OPC-DA and DDE)

Technologies such as OPC support mandatory and optional inter-
faces (features). A server must implement required interfaces, but
many others are optional. A client can function using only the
required features; optional server features are not needed to
perform the server’s basic functions. A client may support many
optional features, but if a feature is not implemented in the server,
it will not be available.
OPC-DA is primarily used for live access to fresh data in hard-

ware, but special servers exist also for software simulation as well
as sharing data among applications that generate data. Note that
OPC-DA handles only live values as they occur, not historical
values that have been logged. Older systems may not support
OPC, but likely support DDE.
97
98 Software for Automation
OPC-DA Server
OPC servers are specific to the network protocol as well as to the
interface hardware, although some protocols can use standard
computer hardware interfaces such as the regular RS-232 serial
port or the Ethernet NIC. This means, for example, that an OPC
server developed for Profibus communication using one manufac-
turer’s interface card will not work with an interface card from
another manufacturer. Therefore, simply saying a “Profibus OPC
server” is not sufficient, it is necessary to say which interface card
it uses. Only one server is required for all devices on the network
using the same protocol. This OPC server is shared by all clients.
Because RS-232 and RS-485 networking is being phased out,

Ethernet is quickly taking their place as the network medium of
choice. This is very much due to dwindling support for serial
communications in computer hardware, and the fact that Ethernet
is now built-in for free. Many kinds of equipment for process
control, building automation, and factory automation communi-
cate using Ethernet and TCP/IP. Contrary to popular belief,
Ethernet and TCP/IP alone are not interoperable protocols or a
completely open solution. Simply having an Ethernet card in a
computer is not sufficient to get data on the screen. The reason is
Ethernet and TCP/IP are only half the protocol. In addition to the
TCP/IP stack already built into Windows, the OPC server is
required to interpret the specifics of each application layer
protocol such as FOUNDATION™ Fieldbus HSE, Modbus/TCP, and
other open application protocols as well as hundreds of propri-
etary Ethernet implementations.
At graphic creation time, the designer at the OPC client locates

data of interest in the server by browsing the namespace in the
server. The hierarchical namespace is a tree-shaped structure
much like files and folders on a hard disk (Figure 4-1).
Chapter 4 – Configuration and Scripting 99
Figure 4-1. Hierarchical Namespace (Screenshot: SMAR SYSTEM302)
There is no standard namespace defined, although the ANSI/ISA-

88.01 physical model (formerly designated S88 by the SP88 group)
is recommended for batch control. This namespace in the server
needs to be created as part of the OPC server configuration. It
may be created manually or automatically. The namespace may
be, for example: block, parameter, and sub-parameter, or building,
floor, and room. Regulatory process control may also follow the
ANSI/ISA 88.01 model, see Table 4-1.
Table 4-1. Possible Namespace Hierarchy

Process Control Factory Automation Building Automation
(ANSI/ISA 88.01)
Enterprise Enterprise Chain
Site Site Location
Area Area Building
Process Cell Production Line Floor
Unit Work Cell Room
Equipment Module
Control Module
OPC does not require data to be logically organized or parameters

to have meaningful names. There are servers with flat namespace
and just numbered tags, but this makes it more difficult to locate
the proper data from the client.
An OPC-DA server needs to be configured for how it shall access

data it may need to furnish the clients from the underlying hard-
ware. OPC-DA servers come in two types: “native” servers,
specifically designed by the hardware manufacturer for their
product, and “generic” servers, for a protocol such as Modbus
that uses standard computer interface hardware. In the case of a
native server designed specifically for some device, the engi-
neering tool used to configure the device—for example, hardware
setup and logic programming—usually configures the communi-
cation and OPC server automatically. However, since a generic
OPC server is not made specifically for a particular device, it will
need to be manually configured by the system integrator.
To simplify system implementation, it is a good idea to use a system that

configures OPC servers automatically. Not only is this convenient, it
also eliminates chances of mistakes.
When the OPC server is connected directly to the device using a

small local network within the plant, speed is usually relatively
high and communication very good. As a result, few communica-
tion errors occur and throughput and response become very good.
However, in SCADA applications using telephony or radio
communication, response turnaround times are longer, with noisy
signals including radio squelch. The severity of the problem
depends on characteristics of the protocol, radio and modem. In
such remote applications it is often necessary to configure the
devices for a lower speed and to adjust the OPC server’s time-outs
and retries. For some protocols, there are special OPC servers
developed to enable settings to deal with unique demands of
SCADA applications. SCADA often involves a large number of
small Remote Terminal Unit (RTU) devices. These devices may
use Modbus/RTU communication just like a bottling plant, but
the demands of SCADA may make unsuitable many OPC servers
optimized for the plant floor environment. Special OPC servers
for SCADA periodically poll all devices to collect all data, but
dynamically prioritize polling based on current user demand.
Native OPC-DA Server

Modern devices and integrated automation systems come with
“native” OPC servers specifically designed for a device type and
tightly integrated with their programming tool. When the control
strategy and logic is built, all tags and parameters are automati-
cally exported to the OPC server. The namespace is created auto-
matically, generally following the same structure as in the system

configuration tool. Therefore no configuration of the OPC server
is required to establish the connection. For data-intense systems,
such as those based on FOUNDATION™ Fieldbus, the only realistic
option is using hardware that comes with a native OPC server
that is automatically configured by the strategy configuration tool.
In object-oriented automation systems, parameters are usually
grouped together, for example, into function blocks. Typically the
user then assigns the tag name for the block, and individual
parameters have predefined names depending on the block type.
Modern protocols have a defined object structure; ideally the OPC
server for such a protocol retains that object structure. For
example, FOUNDATION™ Fieldbus has simple parameters grouped
into record parameters, in turn grouped into blocks and logical
devices. However, OPC-DA only supports simple data types, of a
single piece of information each, not the complex data types in
protocols with object structure, such as FOUNDATION™ Fieldbus
and DeviceNet. Therefore, in OPC-DA larger objects are broken
into individual parameters. For some protocols not all types of
information may be made available. However, the new Complex
Data Access (OPC-CDA) technology as well as the upcoming
Unified Architecture (OPC-UA) support sophisticated data
structures.
A native server drawback in some cases is it may limit the number

of device types possible on the network. Take the case of Modbus.
It is possible for a Modbus network to have many different kinds
and brands of devices, such as PLCs, drives, and weighing scales.
The PLC may come with an OPC server automatically configured
by the PLC programming tool. However, it does not configure the
OPC server for the specific registers of the other devices that share
the same network. In that case, a generic Modbus OPC server may
be better. Otherwise, the devices have to be on different networks
with different OPC servers, which is not very elegant. However,
some bus technologies overcome the issue of handling data from
diverse devices. For example, a FOUNDATION™ Fieldbus network
has devices of many different brands, but the engineering tool is
loaded with a Device Description (DD) file for each device type.
The OPC server is therefore able to automatically configure a
single native OPC server for the interface card to handle the
specifics of all these different kinds of devices on the same network
(Figure 4-2).
Figure 4-2. Device Description Ensures a Native Server Supports Many

Devices
Generic OPC-DA Protocol Server

For devices without tools that automatically configure the OPC
server, the namespace and communication have to be configured
manually. Typical examples are “generic” protocol servers, such as
an OPC Modbus server, or an OPC server for a legacy DCS. The
generic OPC protocol server has an associated configuration tool
used for setup. It is first necessary to select port, configure baud
rate, parity bits, and stop bit, flow control, and time-outs for the
automation network (Figure 4-3). Then the address of every
device must be configured.
Figure 4-3. Communication Port (Screenshot: ICONICS Modbus OPC Server)

Next, it is necessary to map every device parameter with register

number, data type, scaling, and so on. The systems integrator
must also build the hierarchical namespace, create individual tags
and organize the tags in some logical way. For example, data may
be arranged by physical location such as device, logical device,
and block, or by application such as area, process cell, unit, and
control module. For programmable devices such as PLCs, the
configuration tool typically generates a very helpful listing of
which register each parameter is located in (Figure 4-4).
Figure 4-4. Register Numbers Exported from PLC Configuration Tool
For devices not fully programmable, such as drives, registers are

typically stated in the manual. The register number is then config-
ured in the OPC server for each parameter (Figure 4-5). Some
configuration tools permit exporting their database in CSV or
Excel file format, and some generic OPC servers permit importing
such files. This way the OPC server can be configured in a semi-
automatic way. However, it is usually necessary to arrange data
columns and make other modifications on exported data before it
can be imported into the OPC server configuration tool. After
importing, the namespace can be rearranged logically in a hierar-
chical tree structure to make browsing from the clients easier.
The last step of manual server configuration is to set the scale

conversion for analog values. Many older devices, such as those
that don’t have a native OPC server, internally use scaled integers
rather than floating-point engineering units; for example, -200 to
+850ºC may be represented by 0 to 65535 (Figure 4-6). Although
some OPC client applications, such as most HMI, permit scaling,
far from all do. Therefore it is better to do the conversion from
raw counts to an engineering unit range in the OPC server to

ensure the value is correctly displayed in all clients. It has the
additional benefit that scaling only needs to be done once, not in
every display. Discrete signals can have labels assigned for the on
and off states, respectively.
Figure 4-5. OPC Server Configuration for a Modbus Device

(Screenshot: ICONICS Modbus OPC Server)
Figure 4-6. Scaling (Screenshot: ICONICS Modbus OPC Server)

Although such a generic server is not as convenient as a native

OPC server, it offers many benefits over custom device drivers.
Unlike a device driver, a generic OPC server is configured once,
instead of in every client. Once the OPC server is configured, it
permits multiple client access, network-wide access, browser
interface, and so on. For example, multiple operator visualization
software and other client applications can access it without the
need to configure the communication again in each client.
Ideally the OPC server configuration tool should have a live

monitoring mode, making it possible to see values online without
having to use a separate OPC client. This is an ideal trouble-
shooting tool to ensure the OPC server is correctly configured
before work is started on OPC client applications. Simulation is
another handy feature found in some OPC servers. It permits
manual entry of an override value, or an automatically generated
function, which is passed to the clients. This is great for testing
client functionality and for operator training, as well as devel-
oping client graphics when no hardware is available.
It may be a good idea to look for an OPC server that permits online
configuration, enabling changes to be made on the fly without stopping
the server and thereby avoiding interrupting data flow to the clients.
Universal OPC Servers

Some simple devices, such as many barcode scanners and
weighing scales, have extremely primitive character-based proto-
cols and typically do not come with OPC servers. Moreover, these
devices often do not provide readings continuously, but may send
unsolicited updates once in a while as they happen. Some generic
OPC servers can be configured to work with just about any of
these devices without needing programming skills. First, the steps
for read, write, and unsolicited transactions are defined. This
requires steps for constructing transmit and request frames, iden-
tifying and receiving responses, validating and parsing the
responses, and finally converting them (Figure 4-7).
Figure 4-7. Universal OPC Server (Screenshot: Kepware Technologies UCON)
In essence, this means no device is too simple to have an OPC

server.
Special OPC Servers

OPC servers exist not only for automation protocols like Fieldbus,
Modbus, PROFIBUS, EIB, and so on, but also for Simple Network
Management Protocol (SNMP). Such a server makes it possible to
collect communication statistics and diagnostics from network
gear such as Ethernet switches and computers. This makes it easy
to detect network infrastructure problems and to display them in
the system overview screen on operator consoles (see Chapter 9).
Embedded OPC Server

Rarely, some devices have the OPC server embedded in device
firmware. These devices do not need a proxy computer to run an
OPC server. One reason embedded OPC servers are rare is very
few embedded operating systems support DCOM, and MS-Windows
is not popular in automation devices. OPC clients do not care if the
OPC server is a dedicated Windows server or an embedded
device; all data is accessed and displayed the same way. One
drawback of an embedded OPC server is the device must be
connected before client configuration can be done. Another is,
when there are many devices on the network, the person config-
uring the OPC client must know in which device each OPC tag is
located. If a single OPC server computer is used instead, talking
with the devices using an automation protocol, all the data is
neatly arranged in one place regardless of physical location.
OPC-DA Client
OPC clients are independent of the underlying network protocols
and topology. Therefore, client software can access information in
devices on different networks at the same time. For the same
reason, many automation software applications can be used in
process control, factory automation, and building automation,
although these industries use different communication network
protocols. The most common form of OPC client is operator visu-
alization software, such as HMI, MMI, or SCADA software. Other
OPC clients include auto-tuning, but these applications require
little or no configuration, or are configured in a fashion similar to
that of operator visualization software. At graphics creation time,
designers at the OPC client locate data of interest in the server by
browsing the namespace in the server (Figure 4-8).
Figure 4-8. Hierarchical Namespace (Screenshot: Wonderware InTouch)
The OPC client is independent of the underlying protocols and,

therefore, no communication aspects need to be configured in the
client.
Direct OPC vs. Intermediate Database

Several different OPC client implementations exist (Figure 4-9).
Some software uses a separate OPC client application provided
with the package to interface to an intermediate database for
mapping each parameter, consistent with traditional device
drivers, whereas other applications access the OPC server directly.
Some clients permit both configuration methods. Although appli-
cations are implemented differently, clients and servers are still
compatible. One drawback of an intermediate database is that
renaming and mapping of parameters is required. This time-
consuming effort may be prone to errors. Moreover, it is not
always easy to come up with a second name for all parameters,
and the parameters will be known by different names in different
parts of the system. When OPC goes through an intermediate
database, scaling as well as other functions may be performed.
This may be useful for some field I/O but not for many other
parameters in the devices such as mode, controller tuning gains,
status, diagnostics, and so on. Many times conversion is not
needed, but if conversion is used anyway, there is a risk for incon-
sistent display among applications. Any intermediate application
also delays the update, as DDE may be used internally between
applications causing a performance bottleneck.
It may be a good idea to use OPC clients that support the direct access
method in order to reduce work, ensure consistency and guarantee best
performance. It may be worthwhile to study the OPC implementation in
the software you are going to buy.
Figure 4-9. Different OPC Client Implementations

When parameter mapping is configured in display applications

using an intermediate OPC access client application, it is often
necessary to first create one or more groups. Parameters are then
mapped into these groups. Subsequently, it is possible to configure
different OPC communication settings for these groups to meet
different needs for display refresh and bandwidth constraints.
Applications that access data directly from the server typically
only create a single group in the server and include parameters
automatically without any configuration effort from the user. Para-
meters are automatically added and removed, depending on the
needs of the applications running and pages displayed.
OPC Communication
Deep down in the OPC “plumbing”, data exchange between the
client and the server application can be done in three different
ways. In the asynchronous scheme, the client requests data from the
server and then executes other tasks, never stopping. The server
takes its time, only a couple of milliseconds, gathering the data and
then replies to the client in “callback” response. In the synchronous
polling scheme, the client requests data from the server and stops to
wait, a couple of milliseconds, while the server gets data from the
underlying hardware and then provides it for the client. Although
wait time is short, it adds up for many continuous requests. The
synchronous scheme leaves execution idle waiting and may result
in performance issues. Asynchronous polling is therefore the more
common form of communication because it frees up the client to
perform other tasks while waiting for the callback from the server.
However, in some special cases when programming VBA, synchro-
nous polling is a more reliable option.
In both synchronous and asynchronous schemes, the client

requests the server on a periodic basis to get fresh data. The rate
depends on the application’s needs, but it typically is one second.
Subscription is a third mechanism for which the client is not
doing any polling. Instead, the server continuously polls the
underlying hardware at a specified update rate, but only trans-
mits the value to the client when changes in the value exceed the
specified deadband (i.e., the deadband only reduces OPC commu-
nication, not the underlying network communication). The dead-
band and update rate is configured when the subscription method
is chosen. Most subscription applications use asynchronous
polling without leaving the user any option. Therefore very few
client applications actually permit the user to select the method
used (Figure 4-10). A function called Refresh is a special case of

subscription sometimes counted as a fourth method of getting
data from a server. Basically, refresh makes a first read of all
values from a group (e.g., to build the initial screen). From then on
subscription is used to keep changing values up to date. For most
purposes, it is not necessary to understand what goes on down in
the OPC engine room.
Figure 4-10. OPC Communication Settings (Screenshot: GE Fanuc Power

Tool)
Clients that permit OPC communication settings to be made, typi-

cally do so on a per-group basis. Users manually create these
groups and select which parameter goes into which group, so it is
possible to create different groups based on communication needs
of different users, screens, or parameter types. Although manually
configuring groups and items is a lot of additional work, it enables
control of OPC communications. For example, it is possible for
parameters that change value infrequently on an exception basis to
be accessed using one scheme, whereas constantly changing
parameters are accessed using another, and fast-changing values
are updated more frequently than others. Similarly, parameters
used for historical trending and alarms that are always used can be
together in a group that is always active. When the OPC client is
launched, it creates the configured groups and items in the OPC

server. And once the method is set in the client, the server simply
responds according to the method used by the client.
Clients that access data directly typically each create a single

group in the server. Parameters are automatically added and
removed from the group, depending on the needs of the applica-
tion. This eliminates the need for user configuration and has the
additional benefit that the underlying automation network is not
loaded with communicating parameters not displayed or used for
other purposes at that moment. Processing parameter addition
and removal as well as getting the initial value for a new param-
eter takes time and resources that can result in data-intense
graphics pages loading slowly. However, once loaded, the param-
eters update fast. These applications typically permit some
tweaking of timing that controls how requests for new parameters
are processed as the operator switches screens (Figure 4-11).
Figure 4-11. Tweaking OPC Settings (Screenshot: SMAR SYSTEM302)
Some parameters accessed through OPC may be critical; it is

essential that these values load quickly when the pages are
selected. The trick commonly employed to achieve quick loading
in this situation also for direct access applications is to have one
OPC client constantly running in the background, permanently
accessing these critical parameters. Thus, these values are always
freshly available in the server.
Of the three OPC communication schemes, subscription has the

highest performance as it uses less bandwidth and resources.
However, some detail and tendency (i.e., movement smaller than
the deadband) of parameter change is lost due to the deadband.
Configuring a low deadband defeats the purpose of using excep-
tion-based communication.
An OPC client should use the OPC status and time stamp to
detect broken or non-functioning OPC links. These should be
indicated by invalid non-numerical characters in a different color
to clearly distinguish them from a valid value.
Graphics Configuration
The primary application in any automation system, be it process
control, factory automation, or building automation, is the oper-
ator visualization software. In a proprietary system operator visu-
alization software is one specific application inseparable from the
other software and hardware. In an open system, one of many
operator visualization software packages available in the market
can be chosen. Operator visualization software packages usually
come in large “suites”, including components such as alarm,
trending, report, etc. However, the most important component is
the mimic graphics. Many screens, typically referred to as
“displays”, have standard layouts generated automatically,
created using templates, or based on ActiveX (Figure 4-12).
Figure 4-12. Typical Operator Console Screens
Other screens, typically referred to as “mimic graphics”, are plant-

specific and always have to be drawn (Figure 4-13). The graphics
packages permit creation of totally customizable screens.
Figure 4-13. Mimic Graphics (Screenshot: SMAR SYSTEM302)
When using parameter values in graphics displays, historical

trending, for alarming, and so on, the parameter is chosen simply
by pointing and clicking in the universal tag browser in the OPC
client. For many applications, it is possible to use templates and
ActiveX components to simplify graphics creation and ensure
consistency. Operator visualization software typically has pre-
configured faceplates for PID controllers, motor control centers,
monitoring, etc. Advanced systems integrators can also create
ActiveX controls using toolkits (Figure 4-14).
Figure 4-14. Faceplate (Screenshot: SMAR SYSTEM302)

Mimic graphics are application-specific and must always be

customized, although symbol templates for common devices and
equipment usually exist. It is important to use templates for the
overall page layout, faceplates, and symbols to provide a consis-
tent look throughout all pages and displays. The function of all
controls should be implemented consistently. In particular, it is
important to use common Windows controls the proper way to
ensure an intuitive interface. For example, radio buttons or check-
boxes should not be used to load other pages.
Because modern network protocols operate in engineering units

such as 200 to 850 mm, rather than percentages, no scaling is
required when displaying a numerical value. On the other hand,
when the value has to be represented graphically, like a bar graph
or dynamically mimicked level in a tank, then range values are
required to define the end points (Figure 4-15).
Figure 4-15. Scaling Engineering Unit Values to Percentage of Range
Scaling values can be hardcoded in the graphics or can access the

range values from the device through OPC. Access from the field
device is preferable as it ensures the scaling is correct even if the
device range is changed. The device itself checks that operator
entered parameter values such as set point and output are within
the range and limits.
Semantics and Conversion

OPC-DA does not specify the semantics, or meaning, of the data.
OPC simply transfers values from server to client. For example, in
the case of FOUNDATION™ Fieldbus, the mode of a control loop is
set using the MODE_BLK parameter, for which the value 16
means manual mode regardless of who manufactures the device.
However, for other protocols such as Modbus or PROFIBUS,
putting the loop into manual is achieved by writing other values

to registers or indexes, which even differ among manufacturers.
Some devices and protocols transmit measurement values as real
floating-point numbers in engineering units, while others use
scaled integers. It is necessary to configure the clients to handle
these differences in semantics in order to present the data in a
consistent way to the operators. This becomes particularly impor-
tant in systems mixing different network protocols and device
types. This is a good reason to stick with one protocol.
Since modern protocols now use values in engineering units for

the vast majority of parameters, simply picking the parameter
using the tag browser is sufficient to get it onto the screen or into
the historical trend. However, for older devices using scaled inte-
gers such as -32,768 to +32,767, the raw number should be
converted to an engineering unit value such as -200 to +850ºC
(Figure 4-16). Ideally this is done already in the OPC server, and
many generic OPC servers provide exactly this capability. If not
converted in the server, the conversion has to be done in each and
every client. Frequently it is necessary to use mathematical and
logical expressions to decode the data. Doing this work many
times over is time-consuming, and OPC clients other than oper-
ator visualization software may not provide this functionality at
all. Scaling can also be done in the OPC data, marshalling applica-
tions used for OPC bridging and redundancy. The bridge accesses
raw counts from any simple OPC server, performs the scaling,
and makes the engineering unit value available to all clients.
Figure 4-16. Scaling from Raw Counts to Engineering Unit (Screenshot:

Wonderware InTouch)
It is a good idea to do scaling to floating-point engineering units already

in the OPC server.
Enumerated parameters need to have each valid value interpreted

into a corresponding text string. Enumeration of two values is
supported in many OPC servers, while more enumeration must
be done in the client. This is commonly used for state, status,
mode, and option parameters. Examples include showing “Off” in
place of zero, and “On” in place of one (Figure 4-17).
Figure 4-17. Enumerated States (Screenshot: SMAR SYSTEM302)
Bit-enumerated parameters need to have each bit isolated, and

depending on the bit being true or false, displayed as one string
or another. This is commonly used for alarms, diagnostic
summary parameters and multiple I/O groups. Examples include
one bit representing low alarm and the next bit representing high
alarm, where zero means no alarm is active and one means the
alarm is active.
Quite clearly, manually configuring the clients to interpret seman-

tics for each place a value is displayed would result in an absurd
amount of work. Several steps can be taken to reduce this burden
while integrating a system. First and foremost, use modern
devices and protocols that use floating-point values and operate
in engineering units. If this is not possible, use an OPC server to
ensure the conversion is done once in a single place as close to the
source as possible. Make extensive use of ActiveX controls and

templates that embed the pre-configured conversion.
OPC Status
With every OPC value there is an OPC status that indicates the
quality of the value from an OPC perspective. Typically the
quality is “Good”, but if the OPC communication does not work
this will be indicated as “Bad”. If the status is Bad, most OPC
clients automatically indicate to the user that the value is invalid.
However, to achieve this, some client applications require scripts
to be written to interpret the status. Some protocols, including
FOUNDATION™ Fieldbus and PROFIBUS-PA, also have status with
quality indicated as Good, Uncertain, and Bad. However, this
relates to the communication between devices on the bus and
other aspects; it should not be confused with the OPC status
between OPC client and server (see Chapter 6).
Table 4-2. OPC Status Quality Bit Interpretation

Quality Bits 7 and 6 Range of Values
Bad 00 0-63
Uncertain 01 64-127
N/A 10 128-191
Good 11 192-255
Use the values in Table 4-2 to write scripts to interpret quality in

the OPC status in case it is not a standard feature in the software.
However, since configuring such scripts means lots of additional work, it

may be a good idea to choose software that automatically indicates if
quality is bad.
Operation
The graphics display is automatically updated with live data from
the devices to show numeric values and animate the mimic
graphics. As the operator changes or toggles parameters, new
values are written to the devices. Range checking may be applied
in the OPC client or in the device itself.
WARNING—Be careful of writing to static parameters too

frequently, as this may kill certain types of non-volatile memory
with limited numbers of write cycles found in many embedded
devices. Refer to device documentation.
Screen Management
The operator console usually has the capability to divide the
screen space into panes or panels and manage the appearance and
behavior of applications. Such capability can be used to enhance
safety and security of the host computer. The screen can be config-
ured to show several applications or displays at the same time in
a specific panel arrangement that can be fixed to ensure important
information is always visible and not hidden behind other
windows (Figure 4-18). Typically screens have top and bottom
fields that remain the same while only the main field of the
display changes as you move from screen to screen.
Figure 4-18. Screen Layout (Screenshot: ICONICS Screen Manager)
Additionally, it is possible to assign priority to different panels or

make sure a particular panel is always on top and cannot be mini-
mized, resized or maximized. Several methods are available to
ensure important information is not hidden or goes unnoticed on
screens that otherwise may be cluttered and messy. User input can
even be disabled from a particular panel (Figure 4-19).
Figure 4-19. Screen Controls (Screenshot: ICONICS Screen Manager)

DDE Server
DDE was the most widely used device driver technology before
OPC. DDE I/O servers communicate with the underlying network
to get data from automation devices such as controllers. However,
software applications can also be DDE servers (Figure 4-20). For
example, MS-Excel has a DDE server interface permitting other
applications to access data from an MS-Excel spreadsheet.
Figure 4-20. Various Forms of DDE Servers in the Software Architecture
A DDE server can also be an OPC client, creating a software gateway.
DDE Server Configuration

A DDE conversation link is defined in three parts: application
name, topic name, and item name. The application name is the
name of the DDE server software. Topic name is usually a name
configured for each device accessed by the server. The item name
can either be the number of the register or a parameter name.
Together, the application and topic names are sometimes called a
channel. Configuring a DDE server is actually not very different
from configuring a generic OPC server. Typically, it is first neces-
sary to configure the basic communication parameters such as
baud rate and parity bits. Next, topic names are configured corre-
sponding to each device address. This may be something like
“Slave1” or “PLC1”. Lastly, each DDE item is configured (Figure
4-21). Some DDE servers use the register number as the item
name and need no further configuration, whereas other DDE
servers may permit tag names such as “LSH-123” to be configured
for each item.
Figure 4-21. DDE Server (Courtesy: Engineering Specialists, Inc)
DDE Communication
When DDE clients on other computers in the network access the
DDE server, it is necessary to use NetDDE. At Services in the
Windows Control Panel, configure the “Network DDE” and
“Network DDE DSDM” to start up automatically.
Gateway from OPC

Some older automation applications as well as most execution
and business level applications do not have an OPC client inter-
face, only a DDE client interface. These cannot access data from
modern OPC servers. In this case, a DDE server with an OPC
interface is required for the DDE clients to access data in the
device. The DDE server functions as a software gateway. Similarly,
to integrate DDE client software into an OPC system, similar DDE
servers with an OPC client interface are used (Figure 4-22). Thus,
it is possible to get data from an OPC server into a DDE client.
The DDE server again functions as a software gateway. The data
from a device will pass through a number of applications and
undergo several conversions on its way to a client such as a
spreadsheet in MS-Excel.
Figure 4-22. Software Gateway from OPC to DDE (Screenshot: Rensen

OPC Office Link)
DDE Client
DDE clients access data in DDE servers. DDE clients include (e.g.,
operator visualization software, statistical process control, and
auto-tuning). MS-Excel has a DDE client interface that can access
data in servers (Figure 4-23).
Figure 4-23. Various Forms of DDE Clients in the Software Architecture
When the DDE link is specified in the DDE client, the application
name is separated from the topic name using the “pipe” character,
and the topic name is separated from the item name using an
exclamation mark. The application name is simply the name of
the DDE server software; the topic name may be a device name or
document name, such as an Excel spreadsheet name. The item

may be a register number in a device or cell name in an Excel
spreadsheet. For example, the link used by a DDE client to access
a cell in Excel may be: Excel|Sheet1!R1C1 The link in Excel to
access a parameter in a device may be: MODBUS|Slave1!40001
Since DDE does not support browsing DDE servers the way OPC
clients can browse OPC servers, it is necessary to know the DDE
link and type it in when configuring the client (Figure 4-24). In
some cases, it is possible to copy the link from the DDE server and
then paste it into the DDE client. Some device and DDE server
configuration tools generate tag lists of all topics and items that
can then be imported by some DDE clients to semi-automatically
generate the client’s tag database.
Figure 4-24. DDE Link Typed into Client (Screenshot: Microsoft Excel)
If the application name, topic name, or item name contains spaces

or special characters, it is necessary to enclose the name in single
quotation marks.
Gateway to OPC
Most modern automation devices come with OPC servers and,
therefore, use of DDE servers is now quite rare. However, there
are situations where a DDE server is the only available option. For
ease of integration, DDE is still a much better option than custom
drivers. In this case, a DDE-protocol OPC server with a DDE
client interface is required for OPC clients to access data in the
device (i.e., an OPC server for the DDE protocol [refer back to
Figure 4-23]). Thus, it is possible to pass data from DDE servers to
OPC clients. The OPC server acts as a gateway.
A DDE protocol OPC server can generally operate in two modes.

In the easy-to-use “pass-through” mode, no configuration of the
OPC gateway is required. In the OPC client, simply specify the
tag using the DDE application name, topic name, and item name;
for example: DDEOPCServer\Excel|Sheet1!R2C1. The pass-
through mode requires no setup in the OPC server, but may actu-
ally be more difficult to use from the OPC client because the DDE
item names for some DDE servers may not relate to the applica-
tion. For example, the cell name in Excel gives no clue what the
value in it represents. Therefore, DDE protocol OPC servers also
permit DDE items to be renamed as they are made available as
OPC. Thus, an MS-Excel cell name such as R2C1 can be given a
proper name such as “FIT-123” or “Fourth story room tempera-
ture” when browsing from the OPC client (Figure 4-25).
Figure 4-25. Software Gateway from DDE to OPC (Screenshot: ICONICS

DDE OPC Server)
OPC-XML-DA Server
Most OPC-XML-DA servers are not native, but are “wrappers” for
DCOM-based OPC-DA servers. An OPC-XML-DA wrapper is an
XML-DA server and a DCOM OPC-DA client (i.e., a wrapper acts
as a gateway). The OPC-XML-DA wrapper provides an OPC-
XML-DA Web service interface as a front end to the OPC-DA
server. The main configuration work is done in the underlying
OPC-DA server.
Figure 4-26 Web Server Virtual Directory for OPC-XML-DA Wrapper

(Courtesy: ICONICS)
OPC-XML-DA is Web-based and therefore requires a Web server to

provide the higher-level transport (Figure 4-26). Some server prod-
ucts may require a specific Web server to work, such as Microsoft
IIS (Internet Information Server and the .NET framework).
OPC-XML-DA Client
OPC-XML-DA is not much different from OPC-DA. However,
currently there is no mechanism to automatically detect which
computers have OPC-XML-DA servers or to detect which OPC-
XML-DA servers are available in a computer. Therefore it is neces-
sary to know the URL of the server computer and type it into the
client the first time (Figure 4-27). The URL is typically stored as a
shortcut among favorites eliminating the need to type it in the
next time.
Figure 4-27. Manually Type the URL of the OPC-XML-DA Servers in the
Client (Courtesy: ICONICS)
OPC XML Communication

There are two schemes for OPC-XML-DA clients to poll the servers:
basic and advanced. Basic Polling means the client periodically polls
for values at a constant interval and server responds immediately—
regardless of value having changed or not. Advanced Polling means
that when the client makes a poll the server responds only if and
when the value has actually changed. However, there is a shortest
permitted response time “Hold time” before which the server will
not respond even if the value has already changed, and also a
longest permitted response time “Wait time” by which the server
will respond even if the value has not changed.
For advanced polling set the “Hold time” to balance the

conflicting interest of faster update rate and reduced network
traffic. A shorter Hold time will result in faster updates but
heavier load on the communications. Use “Wait time” to balance
the conflicting interest of quickly detecting server failure and
reduced network traffic. A shorter Wait time will result in faster
failure detection but heavier load on the communications. Other
parameters that can be set to optimize the data management
include sampling rate and deadband. Additionally, it is possible to
perform buffering in the server, meaning the client can read many
samples in a single poll.
Historical Database Interface (OPC-HDA)

OPC-HDA is used for accessing historical records logged in a
database and for optional statistical analysis. Note that OPC-HDA
technology handles only historical values that have already been
logged, not live values as they occur. An OPC-HDA server may
often be an OPC-DA client at the same time, using OPC-DA to
access the live data, which it then logs. Through mandatory and
optional features, OPC-HDA supports applications of different
degrees of sophistication. For example, operator visualization soft-
ware may include a simple server for historical trending and a
viewer for raw data, while a sophisticated plant information histo-
rian may additionally be able to display filtered and processed
data and support annotations. Configuring a historian solution
based on OPC-HDA is a matter of first configuring the OPC-HDA
server, such as a logger, then configuring the OPC-HDA client,
such as a viewer.
OPC-HDA Server
OPC-HDA servers typically are data loggers that collect live data
and archive it in a database. The logged data is made available to
viewer applications through the OPC-HDA interface. The server
may internally compress data before storing it in the underlying
database. Regardless of compression method, OPC-HDA clients
retrieve data in common form. The fidelity of the compression/
decompression algorithm is an important selection criterion for
historians.
Direct vs. Gateway HDA Server

Client-server-based trend applications in operator visualization
software and sophisticated historians may implement OPC-HDA
in different ways. For older applications, the interface between the
logger and its dedicated viewer may be completely proprietary. An
OPC-HDA server may be added to proprietary applications to
provide for viewing in OPC-HDA client applications. This type of
solution, which remains closed internally, is common in monolithic
automation systems as well as in plant historian systems. Modern
open systems eliminate the proprietary interfaces between the
logger and the server, using only OPC-HDA (Figure 4-28).
Figure 4-28. Different OPC-HDA Implementations
In an open system, the HDA server may at a lower level use ADO
or OLE_DB technologies through an ODBC interface to archive
data in, for example, a SQL database server.
Trend Logger Configuration

Historical trending to a database on disk requires the historian to
be configured. To configure the logger, the underlying database
engine must first have been configured and its ODBC interface set
up. The next step is usually to establish a link to the underlying
database engine. In an open system, this may be an SQL server,
MSDE, MS-Access, or any other ODBC machine data source.
Although the underlying database may be an SQL-server, no SQL
or ODBC knowledge is required to configure a logger. Windows
automatically lists all ODBC sources in a computer (Figure 4-29).
The SQL server can be on the same computer as the logger server,
or on a different machine, in which case login name and password
must be provided. The logger computer must have sufficient rights
to access the database machine. For applications that require high
availability for the historical data, redundant database servers may
be used. Depending on the software, the logger may be able to
share the logging over several database servers simultaneously.
Figure 4-29. ODBC Data Sources
Different named groups of parameters are created for different

needs. All parameters in a group are sampled at the same rate.
The sampling rate for each group can be configured according to
needs, keeping in mind that a faster sampling rate means require-
ment for more disk space. Additional groups can be created,
corresponding to process cell, building floor, manufacturing line,
or other subdivisions (Figure 4-30). In some cases, special trigger
criteria for start and stop are configured. Some groups may have
fast sampling, others slow. Some groups run continuously while
others are triggered at the start and end of a batch or lot.
Figure 4-30. Logger Configuration (Screenshot: SMAR SYSTEM302)

A group corresponds to one database table. It may be a good idea not to

include too many pens in each group as this will make the database table
large and slow to manage.
The logger is then configured for which variables it shall trend,

applying range conversion or other mathematical manipulation if
necessary. The logger can use either the range provided by the
OPC-DA server or a manually entered range. The underlying data-
base engine has to be sized, depending on required performance
and capacity. Security and audit trail requirements should also be
taken into consideration if there is a need to meet the FDA 21 CFR
Part 11 or similar requirements for electronic record-keeping.
To reduce the size of the database, loggers typically permit config-

uration of deadband and “aggregates.” Aggregate means multiple
samples are pre-processed in the server using different methods,
including average, last sample in interval, maximum, minimum,
standard deviation, etc. Deadband means not every sample is
logged. Instead logging is done only when a significant change,
exceeding the deadband, occurs. When many parameters are
logged, particularly at a high rate, the size of the database may
grow very quickly. Loggers may be configured to work with a
fixed size database with revolving tables, meaning old data gets
overwritten when the database is full.
A logger can typically also operate as a totalizer, logging the inte-

grated value over time, such as flow totalized as volume, or
power totalized as energy, instead of the momentary value. This is
ideal for tracking production totals or consumption.
To reduce database loading, the logger collects samples cached in

RAM and then writes to the database on a periodic basis,
improving performance. Configure groups to write log in RAM to
the hard disk at different times to prevent hard disk overload,
which could happen if all groups try to write at the same time.
Write to disk as infrequently as possible; don’t write every
sample. Some understanding of the internal workings of the
logger may be helpful to improve performance. In general, the
smaller the database tables are the higher the performance will be.
Thus, understanding how the logger uses and manages tables can
help you improve performance. For example, a database is typi-
cally organized in subgroups corresponding to database tables. By
taking care in assigning variables to such groups, the table size
can be kept manageable, ensuring good performance.
OPC-HDA Client
An OPC-HDA client may be a simple trend display embedded in
graphics or a sophisticated analysis and reporting tool. OPC-HDA
clients typically are trend chart displays that permit the user to
“playback” historical data, zoom, analyze, and compare. Logged
data is retrieved from the logger applications through the OPC-
HDA interface. A client can access data from several servers and
may display data from different servers in the same display if
necessary. The OPC client is independent of the underlying data-
base and therefore access aspects need to be configured. For the
same reason, the same client software can access information in
databases on different computers at the same time.
Direct vs. Gateway HDA Client

It is worth mentioning again that different implementations of
OPC-HDA exist. Although applications are implemented differ-
ently, they are still compatible. Some older historians have a dedi-
cated viewer and the interface to the logger may be completely
proprietary (Figure 4-31). An OPC-HDA client may be added to
proprietary applications to provide viewing data from OPC-HDA
server applications. This type of solution, which remains closed
internally, is common in monolithic automation systems as well as
in plant historian systems.
Figure 4-31. OPC-HDA Client Architectures
An OPC-HDA client can be an application on its own, but more

often is a component inside a larger application. For example, a
trend viewer can be an ActiveX executing in any container. Such

an ActiveX can be used on a graphics page inside operator visual-
ization software or a stand-alone historian display.
Trend Chart Viewer Configuration

Configuring the OPC-HDA client is simply a matter of selecting
the display type, such as strip chart, circular chart, or X-Y plot,
depending on operator preference and what the software
supports, and adjusting it to desired size. An important adjust-
ment supported in most trend displays is the time span – the
period covered in one display window, for example. For each
“pen,” use the universal tag browser to point and click to the
desired group and parameter in the server. It is possible to plot
the trend based on “raw” sampled values, or “aggregates,”
samples processed based on the values in a specified resample
subinterval. Commonly supported aggregate processing includes:
average, last sample in interval, maximum, minimum, standard
deviation, etc. The clients retrieve a list of supported aggregate
processing functions from the server. The aggregate processing is
performed in the HDA server when the client requests data. Addi-
tionally the colors, grids, ranges and other appearance aspects can
be configured. Alarm limits can also be displayed (Figure 4-32).
Figure 4-32. Configuration of a “Pen” in a Trend Client (Screenshot: SMAR

SYSTEM302)
It may be a good idea to define a standard color scheme for common pens
representing, for example, process variable, set point, output, etc., and
use it consistently throughout the system. For systems where software is
used in place of old DCS consoles, consider selecting colors, fonts, grids,
and layout to make the new displays look identical to the old DCS
screens, making migration easier.
Live Data Trend

Typically, a trend viewer is able to plot live data at the same time
as historical data from a logger. Live data may be brought in
using OPC-DA and may be non-persistent. For example, when the
display is closed the live samples on the screen are not retained
and are, therefore, gone when the operator opens the screen once
again. Optionally, the trend viewer may cache live data in
memory for short periods, permitting samples to persist. The live
trend takes data direct from the source device whereas historical
trend retrieves data from the historian server and the underlying
database engine. That is, for historical trend get data from a HDA
server, and for live trend get data from a DA server. The trend
viewer should adjust for time differences between the logger and
viewer computer.
Working with Live and Historical Trends

A trend viewer displays data continuously, but the display can be
frozen. It is then possible to go “back in time” by scrolling back
and forth, playing back the variables as they happened. By
moving the cursor, it is possible to see a value at any given point
in history (Figure 4-33). Other viewer features generally include
zoom, minimum and maximum, and other statistics. In addition
to the OPC-DA qualities, OPC-HDA also supports qualities to
indicate time intervals where data logging stopped, actual (raw)
data samples, or calculated samples.
Figure 4-33. OPC-HDA Trend Chart Display (Screenshot: SMAR SYSTEM302)
Typically, it is possible to add, delete, and modify pens in opera-

tion mode as well as to adjust the time scale and aggregate
processing. Some applications may permit additional tags to be
dragged and dropped into the trend from elsewhere on the

screen. A useful feature is the ability to compare current data
against historical data such as an “ideal run.” To easily compare
the executing batch versus the benchmark, just pick a date and
time for a batch or lot run from the past to be replayed while the
current batch runs.
OPC-HDA supports annotations, meaning the operator can enter

a comment for the pen at a relevant point in time. It may indicate
the start or stop of a batch, some comment related to an abnormal
process upset, lot or batch ID, and so on. The HDA client passes
the comments for storage in the HDA server. It is then possible to
review the comments later (Figure 4-34).
Figure 4-34. Annotations (Screenshot: SMAR SYSTEM302)
It is also possible to shift historical trend backward and forward in

time to compare it with earlier values.
Live Alarm & Event (OPC-A&E)

OPC-A&E is used to propagate event-based data such as alarms
and events as they happen (Figure 4-35). An OPC-A&E server
such as an alarm generator may often be an OPC-DA client at the
same time, using OPC-DA to access the live values, on which it
then detects alarm conditions. Through mandatory and optional
features, OPC-A&E supports alarm and event management of
different degrees of sophistication. For example, operator visuali-
zation software may include a simple A&E server for detecting
alarm conditions and associated alarm generation, while another
type of A&E server captures alarms generated by hardware and
propagates it to clients. A sophisticated alarm and event server
may additionally be able to filter for different clients and only

propagate relevant alarms and events. Clients include alarm
summary viewers and historical database or printer loggers.
Configuring a historian based on OPC-A&E is a matter of first
configuring the OPC-A&E server, such as an alarm generator, then
configuring the OPC-A&E client, such as a viewer or logger. A
logger may store in a database or print to a printer.
Figure 4-35. Alarm Management Architecture
Note that the OPC-A&E deals only with live alarms and events as
they happen, not historical alarms and events that have been logged.
OPC-A&E is an ideal technology to meet FDA 21 CFR Part 11

requirements for audit trails; for more information, see Chapter 10.
Alarm & Event Terminology

The terminology in OPC specifications, and some OPC product
manuals, follows software jargon that is different from normal
industry practice, including, for example, the FOUNDATION™
Fieldbus programming language, possibly creating confusion. In
automation, an “alarm” (such as a high-level alarm) happens,
remains active for a while, and then clears, whereas an “event”
(such as change in configuration) simply occurs. In other words,
an “alarm” has a state associated with it that lasts for a while,
whereas an “event” does not. In OPC-A&E, an “alarm” (such as a
high-level alarm) is known as a “condition” while an “event”
(such as change in configuration) is known as an “occurrence.” In

software terminology, an “event” is something that happens,
usually to something else at a given date and time. Similarly,
OPC-A&E uses the term “severity” although “priority” is more
commonly used in the industry. This book sticks with the automa-
tion industry practice rather than the software terminology.
Types and Categories

There are three types of alarms and events: condition-related
alarms, simple events, and tracking events (see Table 4-3). Simple
events carry no information on their cause and do not support
acknowledgement. Tracking events include updates on parameter
changes made in a device. Tracking events make it possible to log
changes in an audit trail. Condition-related alarms include level
alarms, deviation alarms, and discrete alarms. Level alarm condi-
tions include high and low alarms on a process variable. Devia-
tion alarm conditions include high and low alarms between the
process variable and set point.
Table 4-3. Alarm and Event Types

Event Type Event Category Remark
Condition-related alarms Level High-high, high, low, and low-
low-level alarms
Deviation High and low deviation alarms
Discrete Discrete state alarms and
diagnostic alarms
Simple event Device Failure
Batch Status
System Message
Tracking event Operator Change
System Configuration Update event
This classification permits alarms and events to be filtered so only

alarm conditions appear on a particular person’s screen, while
event occurrences go elsewhere. For example, the operator at one
workstation only sees the process alarms, not notifications of
configuration changes. Alternatively, all configuration changes are
logged in a specific database.
Conditions and Sub-Conditions

Only condition-related alarms have sub-conditions. The conditions
usually have names identical to the event category. Sub-conditions
are all related to the same source parameter (see Table 4-4). The
sub-conditions can have different priorities (e.g., high-high and
low-low alarms typically have higher priority than high and low
alarms). Simple and tracking event types have no sub-conditions.
Table 4-4. Sub-Conditions

Condition Sub-Condition Remark
Level Alarm High-High Alarm
High Alarm
Low Alarm
Low-Low Alarm
Deviation Alarm High Deviation Alarm Deviation between
Low Deviation Alarm controlled variable and set point
Discrete Alarm
Areas
Alarms and events may be filtered in the OPC-A&E server based
on geographical location of the source, to be propagated only to
relevant OPC-A&E clients such as specific alarm summary
viewers or loggers. The areas may represent different sectors of
operator responsibility, typically corresponding to different
sections of the plant, factory, or building. In OPC-A&E clients
such as viewers and loggers, the alarms may be organized or
sorted by area. This permits alarms relevant to a certain sector of
the plant, factory, or building to be filtered to appear only on a
particular person’s screen. Other alarms and events go elsewhere.
For example, the operator at one workstation only sees alarm
conditions from one process unit. Not all OPC-A&E servers
support event area browsing.
Area browsing makes client configuration much easier, so it may be a

good idea to look for the browsing feature when selecting servers.
Priority
Alarm and event priority is assigned in the range 1-1000 where 1
means low priority and 1000 means very high priority. Different
device types, protocols, and applications internally use different
ranges for priority. For example, all FOUNDATION™ Fieldbus
devices use priority 0-15. OPC-A&E servers must map alarm
priorities into OPC severity. This must be done consistently
throughout the system (Table 4-5). That is, servers for all devices
and protocols must be configured for the same interpretation of
OPC-A&E priority levels. The OPC specification is not particu-
larly clear on this, and there is a risk that severity 700 in one
server is considered high, while in another server it is not. When
displayed in a client, one of them will be misleading. Alarm and
event management applications may be able to convert priority
levels and messages in order to get a consistent interpretation
across all client and servers.
Table 4-5. Recommended Priority Ranges

Description Priority (Severity)
Critical (high) 667-1000
Advisory (medium) 334-666
Journal (low) 1-333
There is a tendency to assign priority of all alarms as “high”,

which in effect renders the priority useless. Good engineering
practice includes classification of alarms according to their severity.
OPC-A&E Server
At configuration time, the designer at the OPC client configures
source filters by browsing the “event area” in the server. Like the
namespace in a DA server, the event area in an A&E server is a tree-
shaped structure much like files and folders on a hard disk. No
standard event area is defined. This event area in the server needs
to be created as part of the OPC server configuration. It may be
created manually or automatically. Regulatory process control may
also follow the ANSI/ISA-88.01-1995 - Batch Control Part 1: Models
and Terminology model. Other industries follow other models.
OPC-A&E servers come in two types. “Capture” servers are

specifically designed by the manufacturer for their hardware or
software product that internally generates alarms or events, while
“generate” servers are manually configured for each installation
to detect alarm conditions when this capability does not exist else-
where. In the case of capture servers designed specifically for
some product, the engineering tool used to configure the product
usually configures the server automatically.
Adding a software alarm costs very little, if anything. Therefore,

there is a tendency to define too many alarms in an automation
system. An alarm indicates a parameter value that exceeds a spec-
ified threshold. Alarms are useful to get the operator’s attention to
a beginning process upset at an early stage, especially considering
the process can, during normal operation be quite uneventful,
almost boring. However, during a fault or process upset, many
alarms may subsequently trip as a result of the ripple effect of the
real problem. The operators are not able to deal with the ensuing
flood of alarms, which also don’t tell what the real problem is.
To avoid alarm flooding, do not configure nuisance alarms—alarms

that won’t tell the operator anything people are not already aware
of. Nuisance alarms include those that trigger as a direct result of
another earlier problem already reported, or situations the oper-

ator can do nothing about or, which require no action. It is
possible to reduce nuisance alarms by dynamically reconfiguring
alarm trip limits and adapting suppression of specific alarms
depending on the operating conditions. For example, adapt the
alarm trip limits depending on properties of the particular fuel
used, and suppress subsequent alarms in a group once one of
them is already active. The EEMUA specification 191 gives some
useful hints to alarm management practices.
Alarm and Event Capture OPC-A&E Server

An alarm capture server collects alarms and events generated in
hardware or proprietary software and propagates them to
subscribing clients. For example, FOUNDATION™ Fieldbus devices
generate “alerts” that are captured by the OPC-A&E server.
Modern devices and integrated automation systems come with

“native” OPC-A&E servers specifically designed for a device type
and tightly integrated with their programming tool. This means,
when hardware alarms are defined, all tags and parameters are
automatically exported to the OPC-A&E server. The event area is
created automatically, generally following the structure in the
system configuration tool. No configuration of the OPC-A&E
server is required to establish the connection. Not only is this
convenient, it also eliminates chances of mistakes.
It’s a good idea to use hardware that comes with a native OPC-A&E
server that is automatically configured by the strategy configuration tool.
Alarm Generator OPC-A&E Server

An alarm generator monitors analog variables and detects level
and deviation conditions. For level conditions, sub-conditions
such as high-high, high, low, and low-low can be alarmed. For
deviation conditions, it may detect high and low deviation sub-
conditions. Some servers also support rate-of-change alarms as
well as other sub-conditions. Software alarms are typically only
used for indication and logging. Interlock trips are best done in
the hardware. The alarm generator also detects alarm conditions
on discrete values. A central tool can configure many alarm gener-
ator servers running on different machines on the network. An
alarm generator needs to be configured for which alarm condi-
tions it shall detect, on which variables.
The hierarchical structure for the “event area” for the alarm server
must be created. This simplifies the definition of filters in the
clients. In a process plant, this may consist of several process cells
divided into units (Figure 4-36). In a factory, it may consist of
several production lines divided into work cells. In a hotel, it may
consist of floors in turn consisting of rooms. This logical arrange-
ment may be used in conjunction with “first-out” disarm, such as
suppressing subsequent alarms in the group after the first alarm
in the group triggers. This is a good mechanism to prevent
nuisance alarm floods.
Figure 4-36. Hierarchical Event Area Configuration for Process Plant

(Screenshot: SMAR SYSTEM302)
Configuring the overall alarm server includes deciding which

machine it will execute on, and which scan period will be used.
Other options include an initial start-up period during which
alarm conditions due to bad status are suppressed, and if a time
stamp is received from an OPC-DA server or internal OPC-A&E
server, whether the time stamp shall be used.
The individual monitored variable is picked from an OPC-DA

server simply by pointing and clicking using the universal tag
browser. Arithmetic functions can be applied on the value to
adjust for scale, etc. Threshold trip limits and priorities for each
alarm sub-condition can be fixed, entered at configuration time, or
received dynamically from another OPC-DA source, permitting
limits to be set by the operator during operation (Figure 4-37).
Trip limits may have to be different depending on the operating
mode, or for different process fluids, in order not to trigger false
alarms. Some OPC-DA servers act as interfaces to easy-to-use
databases ideal for persistent storage of operator-entered variables
such as alarm limits. Similarly, each alarm sub-condition can be

set to indicate if the alarm requires acknowledgement or not.
Figure 4-37. OPC-A&E Alarm Generator (Screenshot: SMAR SYSTEM302)
Deadband (hysteresis) can be configured for the alarm condition’s

monitored parameter to eliminate “chatter” of individual sub-
condition alarms when a noisy variable is close to the respective
trip limit. This is a useful feature to reduce repeating nuisance
alarms. For each alarm sub-condition, an operator message can be
configured to be displayed in the alarm summary, log, or when
the alarm condition arises.
OPC-A&E Client
An OPC-A&E client may be a simple alarm summary or a sophis-
ticated logger with analysis and reporting. OPC-A&E clients typi-
cally are list displays that permit the user to view current and
unacknowledged alarms, filter, sort, and acknowledge them.
Clients subscribe to alarms in alarm generator servers and alarm
capture servers through the OPC-A&E interface. A client can
subscribe to data from several servers, and may display time-
stamped alarms/events from multiple sources in chronological
order. The OPC client is independent of the underlying protocols
and therefore no communication aspects need to be configured in
the client. For the same reason, the same client software can access
information in devices on different networks at the same time.
Unlike OPC-DA and HDA where clients subscribe to individual

tags, the OPC-A&E client does not subscribe to specific tags; it
filters and captures any tag based on user-set criteria such as type,
area, or priority. Subsequently, the OPC-A&E browser interface

does not browse for tags but for possible filter criteria.
There are two main categories of OPC-A&E clients: current alarm

summary displays, and loggers. Configuring the OPC-A&E client
is a matter of setting up the subscriptions, which includes config-
uring filters. This is done by pointing and clicking to the desired
area and source using the event area browser. It is simply a matter
of selecting which type of alarms in which alarm summary, which
information associated with the alarm should be displayed, plus
colors and other preferences.
Server Filtering
Filters are used by both loggers and viewers. The filtering is done
in the server, but the filters are configured in the clients and then
passed to the servers when the subscription is established. The
event area browser is used to point and click your way to the
server and the specific source or group of sources from which
alarms and events are displayed or logged. Filtering is done in the
server to reduce communication, thereby improving throughput.
Filtering is done based on event types, event categories, and
minimum and maximum for the priority range (Table 4-6).
Table 4-6. Subscription Filter Criteria

Subscription Filter Criteria Description Examples
Server Computer and OPC- “ICONICS.AlarmServer.1”
A&E server name
Event Type Simple, Tracking, Condition
related
Priority (Severity) 0-1000
Event Category Failure, System message
Operator change, System
configuration
Deviation, Discrete, Level
Area A group of sources “Boiler House”
Source A tag or a device “LIC-123”
The desired filter passed from the client to the server has a
sophisticated syntax. However, most clients have simple point-
and-click configuration and configure the filter transparent to the
user (Figure 4-38).
Figure 4-38. Alarm Subscription Filter Configuration (Screenshot: SMAR

SYSTEM302)
Note that not all OPC-A&E servers support subscription filtering.

Additional filtering may be possible at the client end.
In order to keep OPC communication overhead at a minimum, it is a

good idea to use OPC-A&E servers that support filtering.
Alarm & Event Data Field

When an OPC-A&E server propagates an alarm or event to the
client, it provides many pieces of information. An OPC-A&E
client may display, log, or print some or all of these fields. The
OPC specification defines several fields, and OPC-A&E servers
often provide additional data. Many of these fields are relevant
only to the internal workings of the OPC-A&E clients, such as the
acknowledgement mechanism; only some are relevant for the
user. At configuration time, the desired fields for display and
logging are picked (Figure 4-39).
Figure 4-39. Selecting Columns for the Data Fields (Screenshot: SMAR
SYSTEM302)
Those fields most commonly used to display alarm conditions in

clients are described in Table 4-7; see Appendix B for a complete
listing.
Table 4-7. Partial List of Alarm Condition Attributes

Field Description Example
Source Initiator of the alarm “TT-123”
(e.g., a function block)
Area Location where the alarm “Boiler #1”
occurred (e.g., process unit,
work-cell, or room).
Sub-Condition Name Description High-high
Severity Priority 10
Time Time stamp (i.e., when the 13:53:42 07/09/2004
alarm occurred)
Message Additional information. 90.0016ºC
Usually operators need to
know which value caused
the alarm to trip.
Alarm Viewer Configuration (Current Alarm Summary)

An alarm viewer is a typical OPC-A&E client. Since OPC-A&E
only deals with current alarms, not historical ones, only active
alarms are displayed. Alarm viewers often are ActiveX compo-
nents that can be used in all kinds of graphic displays such as
mimic screen or an alarm management system, as well as in other
container software (Figure 4-40).
Figure 4-40. ActiveX Alarm Summary Viewer (Screenshot: SMAR SYSTEM302)
Configuration of the viewer consists primarily of setting up the

subscription with filters, selecting desired data fields for the
columns, and then setting preferences for alarm condition appear-
ance and general appearance, such as background color. An alarm
summary viewer shows alarm conditions of many different priori-
ties. Priorities can be distinguished using different backgrounds
and font colors, as well as blinking and beeping in a nearly infi-
nite number of combinations (Figure 4-41).
Figure 4-41. Priority Color Scheme Configuration

Usually alarm conditions are displayed in viewers separate from

event occurrence viewers because they concern different users and
applications.
Occasionally alarms and events may be displayed together, and it may

then be a good idea to also distinguish these using different color schemes.
With operator visualization software’s graphical capabilities, it is

easy to get overly creative and artistic, defining a bewildering
number of combinations of colors, flash, beep, and other attrib-
utes. Limit yourself to seven different colors and two flash rates.
Bright colors such as red and yellow are preferred. For audible
alarms, a higher volume and higher frequency should mean
higher priority.
It may be a good idea to adopt a corporate standard practice for alarm

annunciation if one is not already in place. Refer to the ANSI/ISA-18.1-
1979 - (R1992) - Annunciator Sequences and Specifications standard
for annunciators to pick a sequence, such as F3A, and implement it
consistently throughout the company. EEMUA specification 191 may
also be useful.
Working with Alarms and Events

By default, alarms and events are sorted by their time-stamp, but
display may be arranged according to other criteria. For example,
sorting may first be done by priority and then by time-stamp.
Sorting can be done in ascending or descending order. The viewer
sorting criteria can be changed during run-time. Single or multiple
alarms can be acknowledged at a click of a button. Some alarm
displays may permit the operator to enter comments. Such
comments are logged in a separate database, as this functionality
is not part of OPC-A&E, which deals only with live alarms, not
historical records. The alarm viewer may also trigger subsequent
functions when alarms and events are received. For example, it

may trigger the executing other applications or some OLE
automation function.
Alarms that remain active for long periods during normal plant
operation are called “standing alarms.” These do not clear even
under normal conditions because of unsuitable trip limit setting,
device fault, or equipment put in out-of-service mode. Standing
alarms must be avoided. They are tantamount to disabled alarms
because they cannot trigger again. As per EEMUA specification
191, an alarm shall be selected and configured to have certain
characteristics (Table 4-8).
Table 4-8. EEMUA Alarm Characteristics

Feature Description
Relevant Justified and pertinent to the operator’s priorities
Unique New, not a repetition of what the operator already knew from
previous alarms
Timely Not too early, and not too late
Prioritized Indicating the urgency or severity
Understandable A clear, easy-to-understand message
Diagnostic Helps find the problem
Advisory Helps identify the correct action
Focusing Direct the operator’s attention in the right direction
It is a good idea to engineer alarm settings carefully, and review settings

for standing alarms. Again, the EEMUA specification 191 or NAMUR
NA 102 may be helpful.
Alarm Logger Configuration (Historical)

An alarm logger is another typical OPC-A&E client. Configuring
the logger consists primarily of setting up the subscription with
filters, selecting the desired data fields for the columns, and then
setting other preferences. One tool can be used to configure
logging to many databases or printers in many logger machines.
Each log can have different filter criteria and log different data
fields. Using the same application, alarms and events can be
logged to databases and printers.
Database Logging
The database logger subscribes to alarms and events generated in
OPC-A&E servers.
There is no historical alarm and event specification for OPC. There-

fore, logging must be done in a more or less proprietary manner.
The database logger is at the same time an OLE_DB client. Histor-
ical alarms and events may then be retrieved from other applica-
tions through an ODBC or OLE_DB interface (Figure 4-42).
To permit other applications to access the logged alarms and events with
relative ease, it is a good idea to use an application that does database
logging based on ODBC and OLE_DB, meaning in the least proprietary
scheme possible.
Figure 4-42. Alarm Logging to Database (Screenshot: SMAR SYSTEM302)
Logging alarms and events to a database on disk requires config-

uring the historian. To configure the logger, the underlying data-
base engine must first have been configured and its ODBC inter-
face set up. The next step is usually to establish a link to the
underlying database engine. In an open system, this may be an
SQL server, MSDE, MS-Access, or any other ODBC machine data
source. Even if the underlying database is an SQL-server, no SQL
or ODBC knowledge is required to configure a logger. Database
tables are managed in the same way as explained for historical
trend logging.
Since there is no OPC specification for historical alarms and

events, both ActiveX controls and applications for historical
alarms and events use OLE_DB to retrieve logged data to display
summary history of alarms and events (Figure 4-43). After estab-
lishing the database connection, configuration includes setting the
filter and selecting which database field goes into which column.
Figure 4-43. Historical Alarm Report ActiveX (Screenshot: SMAR SYSTEM302)
Preferences for alarm condition appearance, sorting, and general

appearance, such as background color, are configured last.
Printer Logging
The printer logging subscribes to alarms and events generated in
OPC-A&E servers. The printer where the logging will be done is
selected. A secondary printer can also be selected to take over in
case the first runs out of paper or has some failure (Figure 4-44).
Page setup such as size, header and footer can also be done.
Figure 4-44. Alarm Logging to Printer (Screenshot: SMAR SYSTEM302)
Dot-matrix printers (line printers) are best suited for alarm and
event logging, as the printed log becomes visible line by line as it
happens. Other printers typically only eject the printed page
when sufficient alarms have accumulated to fill an entire page.
Apart from a hardcopy printer, a printer such as a fax modem or
.PDF file creator can also be chosen.
Reporting and Analysis (OLE_DB)

A historian is a typical example of an application using OLE_DB
and ODBC. Historical trend as well as alarm and event data is
logged into the database using OLE_DB. Data is later extracted
using OLE_DB for display and analysis. Reporting is about
extracting a chosen subset of data based on some filter criteria.
For example, list only value or events for a certain area or tag, and
a certain type or priority. Since OPC-HDA is an open interface for
retrieving logged process values, OPC-HDA is one possible solu-
tion for a report generation tool to retrieve historical data from a
database. However, no historical interface exists for alarms and
events. Many reporting applications rely entirely on OLE_DB or
ODBC. The reporting and analysis tool can be application soft-
ware, or it can be an ActiveX component. An ActiveX report
component can be used in all kinds of graphic displays such as
mimic screen or plant information historian, as well as in other
container software. At system configuration time, report formats
are designed and then used to generate reports on a shift, daily,
weekly, monthly, or yearly basis.
Since OLE_DB and ODBC do not define the database format, such
as what information goes into what table and what field, logging
applications and their associated reporting tools always have a
semi-proprietary relationship. The reporting tool must always be
configured or (worst case) have scripts written, to retrieve the
data from the right table and correct field. If the reporting tool
(OLE_DB client) and database (OLE_DB provider) are products
from the same supplier, the reporting tool is likely pre-configured
to extract the data from all the right places.
If the historian logger application has an associated reporting tool,

few further selections are required to generate a report. However,
if a generic reporting tool or any OLE_DB client is used, it is
necessary to get documentation on the internal database format
and semantics in order to configure the client to parse the data
correctly. Even if good documentation is not available, the fact
that the interface is OLE_DB or ODBC makes it possible to use
database software to first peek into the database (Figure 4-45).
Figure 4-45. Peeking into a Database Accessed through ODBC and OLE_DB
Opening the database will reveal its structure, such as names of

tables and fields, data types, and a description, as well as exam-
ples of values. Armed with this information and some experience
with the software that originated the database, it is usually
possible to figure out how to use the data. It should be noted that
if an open interface is not used, connecting to a database in the
automation system is nearly impossible.
Configuration
The reporting component or application accompanying the logger
application is generally tailored for the specific database format
used by the logger application, and predefined report format. This
is typically the case of historical trend as well as alarm and event
logs. Such an application requires little or no setting to generate
reports, particularly since these applications usually have prede-
fined layouts.
Reports can be generated on user demand or triggered automati-

cally based on date, time, or events such as the completion of a
batch or some kind of faults. Reports should be triggered auto-
matically so people don’t have to go hunting for information
On the other hand, other reporting applications may be generic,

having no pre-configured “knowledge” of the database from
which data is extracted, and no defined layout for the printed
report. In this case, some programming and design effort is

required. Regardless of the type of the reporting tool, whether
specific to the historian or a generic free-format tool, the first step is
to establish connection to the database through OLE_DB or ODBC.
Alarm Report
The report and analysis tool for an alarm logger is configured by
selecting the database and table. Logged alarms can be filtered,
sorted, and the resulting subset subsequently presented in tabular
format, such as a long list of alarms and events. It is possible to
display or print multiple columns for the related data, such as
time-stamp (Figure 4-46).
Figure 4-46. Tabular Alarm Report Print Preview

The number of alarms can also be presented in a pie or bar chart

to visualize trouble spots graphically (Figure 4-47).
Figure 4-47. Alarm Analysis Bar Chart (Screenshot: SMAR SYSTEM302)

Historical Report
A report for historical trend is presented in a tabular format, such
as a long log of data. It is generated by a reporting tool that
extracts a subset of information from the original log file, filtered
based on, for example, tag and time. A report can be generated
instantly or a configuration can be created to generate the report
at a specific time, on a periodic basis, or triggered by an event
such as the end of a batch. This type of report is usually exported
as an Excel spreadsheet (Figure 4-48) to another database table
through OLE_DB or ODBC, or to other applications through a file.
Text files (.txt) have tab-separated values with decimal comma.
Comma-separated value files (CSV) have decimal point. Third-
party applications may then use the historical process data for
further analysis.
Figure 4-48. Historical Trend Report (Screenshot: Microsoft Excel)
After connecting to the source database through OLE_DB or

ODBC, select the tags or groups of tags of interest and the rele-
vant date and time span. In a fixed-format report, no further
configuration is required.
Advanced and Generic Reporting

Many applications for logging to database come with sophisti-
cated reporting capability built-in. The same generic tool can be
purchased stand-alone. Free format reporting tools provide much
greater flexibility in processing data before presentation, enabling
free form design of report formats. Using OLE_DB and ODBC,
configuring database connectivity and table is easy, and data

fields can be dragged and dropped into the report design.
Distributing Reports
Reports can be presented on the screen, printed on paper, as .PDF
files, or as faxes, or rendered as Web pages or email. Another
simple scheme generates the report as a file saved into a shared
folder on a server. Applications that need the data scan the folder
and import the data whenever a new file is detected.
Scripting (VBA)
The functional elements of VBA are functions, statements,
methods, properties, objects, and events. VBA functions permit
sophisticated scripts to perform all kinds of tasks including
program flow control, data conversion, date and time, file
management, financial functions, file access and printing, arith-
metic, comparison, logic, text string manipulation, and error-
handling. Familiar keywords include DO...LOOP, IF...
THEN...ELSE, FOR...NEXT, GO TO, EXIT, and DIM, just
to mention a few. VBA scripts can run hidden or be used with
forms that pop up in Windows with controls for user interaction.
VBA scripting in automation software is no different from

working with modules and forms in other applications such as
Microsoft Office products (Word, PowerPoint, Access, and Excel).
VBA scripting is covered in hundreds of books and tutorials and
therefore not repeated in this book. Refer to Microsoft Visual Basic
Programmer’s Guide or documentation and the help file that comes
with VBA, or refer to examples provided with the software used.
Since VBA scripting engines are embedded in many automation
applications, there is no need to have Visual Basic installed on the
computer.
VBA container applications for the automation industries come

with libraries that include OPC support such as connecting to
OPC servers, getting access to OPC groups and items, dealing
with data types and errors etc. (Figure 4-49). Documentation and
examples that accompany applications explain how to use the
automation aspects of VBA implementation such as communica-
tion. In most cases, asynchronous mode OPC-DA is most efficient,
but the VBA script may continue to execute before the OPC
calback is received. In some cases, it is important that a read or
write is completed before the remainder of the VBA script
executes; in this case, a synchronous read or write should be used.
Figure 4-49. VBA Script for Third-Party ActiveX Component Accesses OPC
Data (Screenshot: SMAR SYSTEM302)
VBA is most powerful when used with ActiveX components and

applications that support OLE automation.
Although VBA is useful for sophisticated functions, it should not

be necessary to use VBA script for basic functions. For example, a
button that just writes a value to the device to set or toggle a
value, invoke a function, launch an application or load another
display or document should be configured by simply using fill-in-
the-blanks.
Components and Controls (ActiveX)

An almost infinite selection of ActiveX controls and components
exists for every conceivable function, including reporting, email,
document viewing, communication, etc. These can easily be used
in ActiveX containers. Several companies make their living selling
ActiveX components and controls (Figure 4-50). Advanced system
integrators can even create ActiveX components using rapid
development tool kits.
Figure 4-50. Third-Party Library of ActiveX Components (Screenshot:

Software Toolbox Symbol Factory)
Many ActiveX components do not have native OPC support. To

activate the dynamic animation of ActiveX based on measurement
or other signals from the plant, factory or building, it is necessary
to write a short VBA script. The script retrieves the data from the
OPC server and writes it to the ActiveX component.
OPC Marshalling
In addition to simple OPC server-to-OPC client connection, some-
times solutions require special data marshalling. Examples of
special OPC functionality include bridging between many OPC
servers, optimization of data access, mathematical expressions,
conversion, and global variables. OPC software that provides
these functions and more is available.
Bridge OPC to Make a Gateway (DA-to-DA)

To simplify operation and maximize automation, it is often neces-
sary to integrate subsystems in a plant, factory, or building. If the
connection requirement for plant integration is not time critical,
OPC is an ideal solution. For example, in a plant, the modern
fieldbus system must coexist with a legacy DCS and be integrated
to the emergency shutdown system and turbine controls. In a
factory, there may be a need to integrate several brands of PLCs as
well as variable speed drives and robots. In a building, it may be
advantageous to integrate the HVAC controls with fire alarms,

access control, and elevators. In the past, connectivity between
such subsystems was only possible if one manufacturer made
them all. OPC-DA removes this limitation. Various systems in the
plant holding large amounts of data can be tied together with
relative ease. Each subsystem may come with an OPC server, but
OPC servers speak to clients, not to other OPC servers. To tie
together OPC servers for different subsystems, it is necessary to
use an OPC bridge (Figure 4-51).
Figure 4-51. Bridge as a Software Gateway Links Several OPC Servers

Together
The OPC bridge software polls data from one OPC-DA server and
writes it to the OPC-DA servers that need the information. Setting
up the OPC bridge is a simple matter of selecting input from a
parameter in a source OPC server, and then output to parameters
in one or more destination OPC servers (Figure 4-52).
Figure 4-52. DA to DA Server Bridging (Screenshot: SMAR SYSTEM302)

One application for OPC-DA to OPC-DA is as a software gateway

between the many different and incompatible industrial Ethernet
protocols, such as FOUNDATION™ Fieldbus HSE, PROFInet,
EtherNet/IP, Modbus/TCP and hundreds of proprietary proto-
cols. Perhaps one of the major advantages of OPC bridging is
third parties have developed OPC servers for legacy DCS, making
it possible for them to coexist with modern network-based
systems. OPC-DX will take the place of DA-to-DA bridging as a
direct server-server scheme without an intermediate bridge.
OPC-DA to OPC-DA bridging solves tricky integration problems

that cannot be accomplished by other means. However, it is not a
perfect solution. Because OPC and the bridge software run on
computers, care should be taken to ensure the suitability of this
scheme for the system. It should be noted that DCOM is not as
fast as a purposely built application protocol for Ethernet, and is
not as safe or reliable either. Therefore, it is important to know in
which loops it is possible to use OPC as part of the control loop.
Closed loop control across dissimilar networks should always be
avoided, but when a single network technology is not possible, an
embedded hardware gateway is the highest performance solution.
Since there are concerns with the uptime of server computers,
some control loops and interlocks may require safety and avail-
ability better achieved using regular embedded gateways or
possibly hardwiring.
OPC was conceived for display, not closed loop control and safety
interlocks. For example, OPC does not have a native redundancy
scheme and the exact assignment of parameter status is not well
defined. The status interpretation differs among software vendors,
and some don’t even use it at all. Therefore, there may be issues
with status propagation from one system to another. OPC
bridging of dissimilar protocols is not a complete substitute for a
single system-wide protocol, which would be the ideal solution. It
is important to establish a scheme in the destination server that
can detect if the OPC connection to the source server has failed,
permitting the destination server to take safe action.
The trickiest part when bridging disparate network protocols is

the different semantics the protocols have. OPC does a good job of
dealing with different data types such as floats and integers, and
leafing through the different naming schemes that vendors use is
also simple thanks to the tag browser scheme. However, very
often just passing a value from one OPC server to another OPC
server will give an incorrect result. For example, one server may
operate in engineering units while the other operates in percent-
ages. Therefore, it is necessary to configure scaling in the OPC
bridge to make the conversion. Similarly, one OPC server may
represent a particular state such as “manual mode” using the
value 16 and “automatic mode” as 4, while in the other OPC
server “manual mode” is represented by 1 and “automatic mode”
by 0 (Figure 4-53).
Figure 4-53. Semantics
The OPC bridge must therefore support free format equations and
logic to make it possible to perform this conversion before the
data enters the system. Otherwise the data will enter the system
in a foreign format and the conversion must be done within the
system itself. The ability to configure a scale conversion once and
reuse it many times can save lots of time.
An OPC bridge may be used by systems that don’t have native

OPC client support but do have an OPC server. The OPC bridge
makes it possible to map data into the system database and then
onto the screen.
Global Variables
To simplify operation and maximize automation, it is often neces-
sary to integrate different client software in a plant, factory, or
building. For example, in a plant the operator consoles, auto
tuning software, and advanced process control software may need
to exchange some data. Each software application is an OPC
client, but OPC clients speak to servers, not to other OPC clients.
To exchange data between OPC clients, it is necessary to use OPC
global variables as a bridge. An OPC bridge may also support
creation of global variables, registers that one OPC client applica-
tion can write to, and other OPC client applications can read. This
permits clients to share information. However, as is always the

case with global variables, they have to be managed well. It must
be clear which application is the “owner” of the variable and can
write to it. If many clients can write to the same variable, it may
become “dirtied” and not work as intended.
Peer-to-Peer Gateway (OPC-DX)

An alternative to OPC DA-DA bridging is to use OPC-DX, if
supported by the subsystems. OPC-DX provides peer to peer live
data access. Each subsystem has an OPC-DX server. Although
called a server, the DX server really is a “gateway” because it acts
partly in a server role and partly in a client role. OPC-DX is the
“soft gateway” that makes it possible to link systems based on
dissimilar networking through computers and software. OPC-DX
is ideal for non-time-critical plant integration. At the time of
writing only few OPC-DX products are available.
For example, using OPC-DX a system with ControlNet

networking can be connected to another system with Profibus
networking if they both have DX on some Windows proxy work-
station (Figure 4-54). In the past, every network technology
required a gateway to every other network technology and often
the desired combination for the gateway was not available. OPC-
DX eliminates this problem.
Figure 4-54. OPC-DX Gateway Architecture
The connection between two OPC-DX servers (gateways) is

achieved using an OPC-DX configuration tool called an OPC-DX
client. Although called a client, the DX client is really an editor
because once the connection is established the editor is no longer
part of the data transaction. The connection editor browses the DX

source and destination namespaces just like a DA client browses a
DA server. Establishing the connection is a simple matter of
pointing and clicking. The harder part of the configuration is to
handle the difference in semantics at the source and destination
systems, as explained for bridging OPC DA-to-DA. As with DA
bridging, it is important to establish a scheme in the destination
that can detect if the OPC connection to the source has failed,
permitting the destination to take safe action.
The precautions for OPC-DX are the same as for bridging OPC-
DA to OPC-DA (i.e., semantics, safety, and availability). Because
the meaning of data is not defined, status is not well defined, and
there is no redundancy scheme, OPC-DX cannot replace control-
level networking. As far as possible, all devices and subsystems in
the plant should communicate using the same protocol in order to
eliminate gateways. Process engineers are still uncomfortable
having to pass more than some few pieces of information from
one controller to another through software in a computer. They
prefer using only embedded devices, even though computers are
OK for visualization. Linking from one protocol to another always
results in “looser” integration than if a single protocol is used.
Because differences in semantics require mapping of data, a single
bus in the plant is still preferable, albeit not always possible.
Calculator
To deal with different semantics, units of measure, scaling, and to
make inferential measurements etc., it is often necessary to make
calculations on one or more values before they can be used. An
OPC bridge may also support reading values from different
servers, perform computation, and make the result available to
many clients. Do it once in the OPC bridge rather than again and
again in every client – for example, to compute mass flow or
energy flow, BTU calculation for HVAC efficiency or density
correction of level and volume. The OPC bridge may also be used
when scaling is not available in an OPC server (i.e., for one that
provides data in raw counts).
Funnel
Some OPC clients may have license or other limitations preventing
use of more than one or so OPC servers. Systems with such limi-
tations requiring data from multiple sources can use an OPC
bridge in a “funnel mode” where the OPC bridge works as an
OPC client for multiple servers and itself constitutes only a single
OPC server for the system. This way the system with such a
restriction can connect to a single OPC server, the OPC bridge, yet
access data from multiple sources.
Other Functionality
The basic configuration of system host software presented here
covers only clients and servers for the core functions at the
automation level of the system: graphics, alarm, trend, report, and
data marshalling. An overview of other powerful automation
applications is described in Chapter 7. It should be noted that the
implementation of OPC and OLE_DB, etc., in this vast array of
applications from a multitude of vendors may vary somewhat,
but the core concepts presented here apply to any system. It is the
author’s experience that, once you are familiar with OPC, you can
easily apply it to any application.
Exercises
1. Is OPC an interface between hardware and software or
from software to software?
2. Will an OPC software for a particular communication

protocol work with any computer interface for that protocol?
3. When the OPC server responds with data to the client the
roles of client and server are in fact reversed. The server
acts as a client and the client acts as the server. What is this
mechanism called?
4. Do different OPC server provide data in the same way?
5. What are the three parts of a DDE link, and how are they
separated?
6. Is a historical data logger a client or a server application?
7. Which are the aggregates commonly available for HDA

subscription?
8. What mechanism does OPC-A&E work on (choose one):

A. The client continuously polls the server for alarm state
B The server continuously publishes the alarm state to the
client
C. The server only publishes the alarm state to the client

when state changes
9. Which are the criteria that can be set in an OPC-A&E client

to capture some specific alarms out of the many alarms
being generated?
10. Which OPC interface is used to retrieve historical alarms

and events?
11. Which technology does reporting software use to retrieve

data from databases?
12. How does data get into ActiveX components?
13. Can an OPC-DA server communicate with another OPC-

DA server?
References and Bibliography

1. Berge, Jonas. Fieldbuses for Process Control: Engineering,
Operation and Maintenance. ISA – The Instrumentation,
Systems, and Automation Society, 2002.
2. Alarm Systems, A Guide to Design, Management and

Procurement, Engineering Equipment and Materials
Users Association (EEMUA). Publication No.191,
ISBN: 0-85931-076-0.
3. ANSI/ISA-18.1-1979 - (R1992) - Annunciator Sequences and

Specifications. ISA – The Instrumentation, Systems, and
Automation Society.

04

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

04

Caricato da

Copyright:

Formati disponibili

4

Live Data Interface (OPC-DA and DDE)

OPC-DA is primarily used for live access to fresh data in hard-

Because RS-232 and RS-485 networking is being phased out,

At graphic creation time, the designer at the OPC client locates

Figure 4-1. Hierarchical Namespace (Screenshot: SMAR SYSTEM302)

There is no standard namespace defined, although the ANSI/ISA-

Table 4-1. Possible Namespace Hierarchy

OPC does not require data to be logically organized or parameters

An OPC-DA server needs to be configured for how it shall access

To simplify system implementation, it is a good idea to use a system that

When the OPC server is connected directly to the device using a

Native OPC-DA Server

matically, generally following the same structure as in the system

A native server drawback in some cases is it may limit the number

Figure 4-2. Device Description Ensures a Native Server Supports Many

Generic OPC-DA Protocol Server

Figure 4-3. Communication Port (Screenshot: ICONICS Modbus OPC Server)

Next, it is necessary to map every device parameter with register

Figure 4-4. Register Numbers Exported from PLC Configuration Tool

For devices not fully programmable, such as drives, registers are

The last step of manual server configuration is to set the scale

raw counts to an engineering unit range in the OPC server to

Figure 4-5. OPC Server Configuration for a Modbus Device

Figure 4-6. Scaling (Screenshot: ICONICS Modbus OPC Server)

Although such a generic server is not as convenient as a native

Ideally the OPC server configuration tool should have a live

Universal OPC Servers

Figure 4-7. Universal OPC Server (Screenshot: Kepware Technologies UCON)

In essence, this means no device is too simple to have an OPC

Special OPC Servers

Embedded OPC Server

Figure 4-8. Hierarchical Namespace (Screenshot: Wonderware InTouch)

The OPC client is independent of the underlying protocols and,

Direct OPC vs. Intermediate Database

Figure 4-9. Different OPC Client Implementations

When parameter mapping is configured in display applications

In both synchronous and asynchronous schemes, the client

used (Figure 4-10). A function called Refresh is a special case of

Figure 4-10. OPC Communication Settings (Screenshot: GE Fanuc Power

Clients that permit OPC communication settings to be made, typi-

launched, it creates the configured groups and items in the OPC

Clients that access data directly typically each create a single

Figure 4-11. Tweaking OPC Settings (Screenshot: SMAR SYSTEM302)

Some parameters accessed through OPC may be critical; it is

Of the three OPC communication schemes, subscription has the

Figure 4-12. Typical Operator Console Screens

Other screens, typically referred to as “mimic graphics”, are plant-

Figure 4-13. Mimic Graphics (Screenshot: SMAR SYSTEM302)

When using parameter values in graphics displays, historical

Figure 4-14. Faceplate (Screenshot: SMAR SYSTEM302)

Mimic graphics are application-specific and must always be

Because modern network protocols operate in engineering units

Figure 4-15. Scaling Engineering Unit Values to Percentage of Range

Scaling values can be hardcoded in the graphics or can access the

Semantics and Conversion

putting the loop into manual is achieved by writing other values

Since modern protocols now use values in engineering units for

Figure 4-16. Scaling from Raw Counts to Engineering Unit (Screenshot:

It is a good idea to do scaling to floating-point engineering units already

Enumerated parameters need to have each valid value interpreted

Figure 4-17. Enumerated States (Screenshot: SMAR SYSTEM302)

Bit-enumerated parameters need to have each bit isolated, and