Académique Documents
Professionnel Documents
Culture Documents
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.
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.
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.
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).
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.
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.
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).
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).
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.
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.
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.
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.
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).
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
122 Software for Automation
Figure 4-24. DDE Link Typed into Client (Screenshot: Microsoft Excel)
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.
Chapter 4 – Configuration and Scripting 123
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.
124 Software for Automation
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.
Chapter 4 – Configuration and Scripting 125
Figure 4-27. Manually Type the URL of the OPC-XML-DA Servers in the
Client (Courtesy: ICONICS)
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.
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.
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.
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.
132 Software for Automation
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.
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.
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.
Chapter 4 – Configuration and Scripting 137
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.
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.
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.
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.
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).
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).
142 Software for Automation
Figure 4-39. Selecting Columns for the Data Fields (Screenshot: SMAR
SYSTEM302)
Chapter 4 – Configuration and Scripting 143
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).
Database Logging
The database logger subscribes to alarms and events generated in
OPC-A&E servers.
146 Software for Automation
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.
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.
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.
148 Software for Automation
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.
Figure 4-45. Peeking into a Database Accessed through ODBC and OLE_DB
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.
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).
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.
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.
Figure 4-49. VBA Script for Third-Party ActiveX Component Accesses OPC
Data (Screenshot: SMAR SYSTEM302)
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.
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).
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.
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).
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.
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
158 Software for Automation
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
160 Software for Automation
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?
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?
5. What are the three parts of a DDE link, and how are they
separated?