7

Application

Lots of software and industrial computer hardware have been

developed specifically for automation. This chapter gives an
overview of some of the application types used at the automation
level and at industrially hardened components used with
computers in automation. Other applications are used at the
execution and business levels of the enterprise. See Chapter 5 for
an overview of software used above the automation level.

Automation Level Software

Open software interfaces in general, but OPC in particular, create
compatibility among applications. This, in turn, has brought about
a vast array of software that can be used in automation systems
without requiring custom programming. Plant optimization and
savings can be achieved by putting these applications to good use.
Open interfaces have brought the cost of these applications down
and simplified integration work, making it affordable for just about
any plant, factory, or building. Perhaps the most important software
application in any automation system is the configuration tool.
However, these tools are device- and protocol-specific and therefore
not covered in this book. The wide selection of software enables
even the most sophisticated application requirements to be met.

Operator Visualization (HMI/SCADA)

In the past, automation systems, particularly in the process indus-
tries, had proprietary software in operator consoles to display
information to operators, collect trend data, activate alarms and
events, and issue reports. Operator visualization is now done in
software with OPC connectivity. 197
198 Software for Automation

Operator visualization software is the key software in the automa-

tion system. It is often called Human-Machine Interface (HMI) or
“SCADA software” because it is the software for data acquisition
and operation in Supervisory Control and Data Acquisition
(SCADA) systems. The principal components of operator visuali-
zation software are graphics, alarms, trend, and reporting (Figure
7-1). The mimic graphics depict the plant, factory or building
being automated. Alarm management consists of alarm detection,
logging, and display. Trend historian consists of logger and
viewer. The reporting tool generates reports based on logged
alarms and history. Operator screens can be configured to display
in any language.

The visualization, alarm generation, and trend components get

their data from the underlying hardware using OPC-DA. The
alarm logger and display subscribe to data from alarm sources
using OPC-A&E. Trend display and reporting get their data using
OPC-HDA. Alarm reporting must use OLE_DB, ADO, or other
technology to get historical data from the alarm loggers since
there is no OPC standard for getting historical alarm data.

Figure 7-1. Operator Visualization Software (Screenshot: ICONICS

Genesis32)

Historian/Process Information Management System (PIMS)

DCS in the past did not have storage capacity and software tech-
nology to support long-term trend analysis. Therefore, historical
data archiving has traditionally been done in a separate historian
 Chapter 7 – Application 199

application, from third parties, often called a Process Information

Management System (PIMS). For every combination of historian,
different communication driver software was required, adding to
the cost of the historian solution. The historian, in turn, was often
used by APC and RTO software. Plant information is now
managed in software with OPC connectivity.

The logger portion of the historian collects massive volumes of

process data, often from several diverse underlying automation
systems. The visualization portion of the historian permits
display, analysis, and reporting. The data is generally also acces-
sible to higher level MES applications and ERP systems. A current
trend is that many automation systems already have high capacity
SQL servers that handle the logger portion of the historian task.
The role of the historian is increasingly that of extracting and
aggregating information from different loggers and transforming
it into personalized reports, often through a Web browser. Such
data-mining applications are sometimes called Manufacturing
Intelligence System (MIS).

Data loggers use OPC-DA and OPC-A&E to access data from the
underlying automation hardware. Viewers and reporting tools
may use OPC-HDA to access logged process data. Logged alarms
and events may be accessed using, for example, OLE_DB.

Advanced Process Control (APC)

Advanced process control was previously performed in propri-
etary application stations that needed expensive drivers to inter-
face with the DCS hardware, or through the historian. Multivari-
able modeling and advanced control are examples of functions
now performed in software with OPC connectivity.

APC software maximizes plant output by pushing plant processes

to multiple constraints simultaneously and then holding them
there safely. APC is used when multiple variables affect the
process and multiple constraints must be considered. Advanced
control is done in software because the algorithms require the
enormous computational power available in computers to
perform the complex mathematics. Different suppliers of
advanced control software specialize in different industries and
processes and use different control algorithms. Methods used
include Model Predictive Control (MPC), fuzzy logic, neural
networks, and genetic algorithms. These software controllers are
specifically designed for use in hydrocarbon processing, pulp and
paper, various chemical industries, etc.
200 Software for Automation

Multivariable control software integrates with plant controllers

via OPC. The advanced process control software reads a large
number of process variables from the transmitters and analyzers
connected to the process automation system hardware using OPC.
Measurement readings are first used to build a process model or
to “teach” the control algorithm. Measurement readings received
though OPC are then used in combination with this learned
knowledge to perform advanced control. Similarly, the many
outputs are passed to valves and other final control elements by
writing to the process automation system hardware using OPC.
Using a control system that supports OPC for both inputs and
outputs, it is thus possible to choose the advanced control
package best suited to the process to be controlled, regardless of
the suppliers.

Typically there is no redundancy. Instead, if the APC or communi-

cation fails, the basic automation system falls back on regular PID
control. The concept of shedding from remote output to local
control is part of the mode in the FOUNDATION™ Fieldbus
programming language.1

Real-Time Optimization (RTO)

Real-time process optimization was previously performed in
proprietary application stations that needed expensive drivers to
interface with the DCS hardware, or through the historian. Real-
time process optimization is now performed in software with
OPC connectivity.

Process optimization software uses models in conjunction with

current economic information to determine optimum operating
points for the advanced process controllers. Often the same
process model used for APC is also used for RTO.

The process optimization software reads a large number of

process variables from the transmitters and analyzers connected
to the process automation system hardware using OPC.

Inferential Measurement
Inferential measurement was previously performed in proprietary
application stations that needed expensive drivers to interface with
the DCS hardware, or through the historian. Inferential measure-
ment is now performed in software with OPC connectivity.
 Chapter 7 – Application 201

An inferred measurement is calculated based on several simple

measurements such as pressure and temperature. It is typically
used to estimate the value of an important product property that
cannot be measured directly or used when the direct measure-
ment has a too slow update time, such as from some analyzers
and grab samples. The value is typically used as input for
advanced closed loop process control.

The inferential measurement software reads several process vari-

ables from transmitters and analyzers connected to the process
automation system hardware using OPC.

Operator Training Simulators

Training on an operating control system can be disruptive and
dangerous. Training may therefore instead be done on a system
not tied to a process but instead simulated in software, or at best
hooked to a pilot plant with generic loops. Operator training is
now done on software with OPC connectivity.

A simple means of training simulation is to “tie-back” controller

outputs to process inputs, but it does not mimic the real process
dynamics. Simple “tie-back” simulation can be achieved using an
OPC bridge to read the controller output and write it back to
inputs in simulation/override mode.

Operator training simulator software is used to let operators prac-

tice start-ups, shutdowns, load changes, upset, or emergency
conditions. Operators can make mistakes without risk and learn
from them. Realistic simulation is achieved by modeling the
process dynamics. Often the same process model as used for APC
and RTO is used for training simulation.

The operator training simulation software reads output values

from the control system using OPC-DA and applies it to the
process model to simulate high fidelity process response fed back
to the inputs of the control system also using OPC-DA.

Alarm Management
In the past, consolidating and managing alarms from package
units and skids such as SIS, APC, and compressors to the main
automation system using software or communication was next to
impossible. The only hope was if all subsystems came from the
same supplier, which was never the case. Often alarm integration
202 Software for Automation

had to fall back on hardwiring the most important alarms, and

often just a single general alarm from each package. Software for
alarm generation, capture, logging, display, and management now
use OPC.

Alarm generation servers monitor process variables and generate

alarms when limits are exceeded. Alarm capturing servers catch
alarms generated in hardware, such as controllers that communi-
cate across a bus. Alarm capture servers exist that can capture text
printed to a computer printer port, such as for a dot-matrix alarm
printer on a legacy DCS (Figure 7-2). This is ideal for migrating
older systems to OPC-A&E.

Alarm summary software subscribes to data from alarm sources

and displays alarms generated in hardware or software, permit-
ting filtering and sorting. Alarm logger software records alarms to
disk. Alarm reporting software produces reports from alarms
logged to disk.

Figure 7-2. Printer Port Alarm Capture (Screenshot: Matrikon OPC A&E
Historian)

Intelligent alarm management includes the ability to prioritize

and to filter out nuisance alarms, notifying only necessary alarms.
This prevents alarm flooding and distracting operators. Dynamic
alarm limits permit alarm settings to automatically change during
start-up, shutdown, load change, or other process changes.
 Chapter 7 – Application 203

All alarm sources are fitted with OPC-A&E servers to propagate

the alerts. Logger and display software are clients using OPC-
A&E to capture alarms. Moreover, alarm generator software may
use OPC-DA to access process variables and OPC-A&E to propa-
gate the alert. The alarm mechanisms are detailed in Chapter 4.

Multimedia Alarming and Agents

In the past, alarms could only be seen at the operator console.
When the alarm horn sounded, it was necessary to head back to
the console. Somebody would always have to remain within
earshot to attend operations.

Using modern communication and multimedia technology, many

options exist to announce alarms, making it possible to leave the
automation system unattended. Multimedia and communication
software is used to notify operators and technicians of alarms and
events wherever they may be in the plant or elsewhere in the world.
Work schedules can be created to notify only on-duty personnel
(Figure 7-3). Call progression and acknowledgement actions can be
configured, as can PIN security. Notification agents include:

• Instant messaging: with complete alarm details

• Pop-up Web page: with complete alarm details or even a video
• Email: with complete alarm details that can be acknowledged
via a reply
• Pager: simple alphanumeric message that can be acknowl-
edged by a two-way pager
• Speech: digitized or text-to-speech announced over speaker
system or call-out to phone or mobile phone
• Marquee: Message scrolling on ticker display
• SMS: alphanumeric message with alarm information
• Fax: with complete alarm details

Sophisticated menu-driven call-in systems can also be created,

permitting in-depth interrogation.

Multimedia alarming software subscribes to alarms and events

filtered in alarm sources using OPC-A&E. Many of these functions
require additional hardware such as modem cards, speech synthe-
sizer cards, and marquee displays.
204 Software for Automation

Figure 7-3. Multimedia Alarming Agent (Courtesy: ICONICS)

Auto-Tuner
In the past, each brand of PID controller had its own auto tuning
software, if it had any at all. Most of the time tuning had to be
done manually. If a plant had several different controllers, each
one required a different auto tuning software. Auto tuning soft-
ware with OPC interface is now available.

A PID controller must be properly tuned to control tightly. The

auto-tuning software analyzes the process and recommends
tuning parameters and damping suitable for the controller, based
on user-defined tuning criteria and some pre-configured details
regarding the PID algorithm style (Figure 7-4).

Using OPC, the auto-tuning software reads the process variable

and a number of variables for the PID algorithm from the
controller. Computed tuning parameters are sent to controller
hardware using OPC-DA. Alternatively, the auto-tuning software
can retrieve data logged to a historical database using OPC-HDA
and tune accordingly.
 Chapter 7 – Application 205

Figure 7-4. Auto-tuning Software (Courtesy: ExperTune)

OPC Infrastructure
Several specialized OPC applications exist to meet specific system
integration needs. These infrastructure applications do not
generate data; they do not consume data, either. They are there
simply to ensure applications can be integrated.

OPC Bridge
In the past, the only means to integrate subsystems was through
primitive hardwiring of on/off and analog signals. The amount of
data that could realistically be brought across from one system to
the other was very limited. In rare cases, it was possible to use
digital communication if both ends supported a common protocol
such as Modbus/RTU.

Using an OPC bridge, it is possible to fit different subsystems

with an OPC server, such as a boiler or utility water package unit
in a plant, the fire alarm and elevator subsystems in a building, or
an air-conditioning system in a factory, and to tie these subsys-
tems to the main automation system. The OPC server used by
each subsystem depends on the network protocol and devices
used in the system.
206 Software for Automation

The bridge uses OPC to read values from the OPC server of one
subsystem and to write it to another subsystem, or the main
automation system, using its OPC server. See detailed discussion
in Chapter 4

OPC Troubleshooting
Sometimes software vendors make slightly different interpreta-
tions of the OPC specification, leading to compatibility problems
between clients and servers. Although such differences and subse-
quent problems are minimized through compliance testing and
multivendor workshops, there may be residual differences which
are not caught. Most importantly, there are many non-tested
applications in the market. An OPC sniffer is a troubleshooting
tool that can be used in cases where applications do not connect.
The OPC sniffer appears to the OPC clients as just another OPC
server. Check compatibility by creating a test tag in the client.
When browsing for the data from the OPC client, simply pick the
OPC sniffer from the list of OPC servers. The OPC sniffer will in
turn permit you to select the actual target server (Figure 7-5).

Figure 7-5. A Sniffer Logs All Interactions between Client and Server
(Screenshot: Matrikon OPC Logger)

The OPC sniffer logs the OPC activity between applications. A

non-expert user is able to use the OPC sniffer to capture OPC
activity and email logs to experts at the respective component
vendors for analysis and resolution.

OPC Tunneller
OPC and DCOM in general do not work well on large WANs
such as the corporate Intranet, the public Internet, or slow and
unreliable communication links. For these applications it is neces-
sary to “tunnell” OPC using another protocol that permits adjust-
ment of time-out values. An OPC tunneller gets round DCOM
software security settings and can also use firewall friendly trans-
port protocols such as HTTP to deal with network security
(Figure 7-6). See detailed discussion in Chapter 3.
 Chapter 7 – Application 207

Figure 7-6. Tunneller Makes all OPC Servers Available Overcoming DCOM
Restrictions (Screenshot: Matrikon OPC Tunneller)

OPC Redundancy
Since many software applications required for the efficient opera-
tion of plants and factories rely on data accessed through OPC,
the OPC infrastructure must have a high availability. Industrial
hardware typically has redundant networks and can be fitted with
redundant OPC servers. Should one of the servers fail, OPC clients
use OPC data marshalling applications to automatically pick
values from a functioning OPC server in a hot-standby redundant
pair (Figure 7-7). See detailed discussion in Chapter 10.

Figure 7-7. OPC Redundancy Broker (Screenshot: Matrikon OPC

Redundancy Broker)
208 Software for Automation

OPC Funnel
An OPC funnel makes multiple OPC servers appear as one single
server. An OPC funnel has to be used when an OPC client appli-
cation designed or licensed to only support a single OPC server is
required to get data from multiple sources. The OPC funnel appli-
cation uses OPC to get data from the different underlying OPC
servers. The OPC client, in turn, gets its data from the OPC funnel
application.

OPC Automation Wrapper

Dedicated software with an OPC interface exists for all common
automation functions. Moreover, many applications support VBA,
permitting them to be customized to meet specific needs.
However, some very special applications are programmed by
system integrators in Visual Basic. Rapid development program-
ming languages such as Visual Basic and Delphi use the OPC
automation interface rather than the OPC custom interface used
for ready applications. Therefore it is necessary to use an OPC
automation wrapper that acts as a converter between the OPC
custom interface in the server and the OPC automation interface
required by applications programmed in Visual Basic.

Batch Execution
Many products such as food and specialty chemicals are manufac-
tured in batches, rather than continuously. In the past only low-level
controls were automated, such as those controlling temperature and
loading specified amounts of ingredients. Temperature set point and
ingredient quantities, for example, were set manually for each batch,
depending on product and batch size. Product transfer between
processing equipment required lots of human intervention. Simple
batch automation produces the same product all the time using the
same recipe, processing equipment and the same batch size.

Such batch manufacturing is easy to automate using sequential

function charts in a PLC and scripts in the operator visualization
software. Advanced batch automation requires the flexibility to
produce a different product in a different quantity using different
processing equipment for each batch. Such agile batch manufac-
turing requires specialized batch execution software and is
capable of handling multiple streams (Figure 7-8). Batch execution
is now done in software with OPC connectivity. These applica-
tions shall preferably be based on the ISA 88.01 (IEC 61512 and
NAMUR NE 33) standard models for batch control.
 Chapter 7 – Application 209

Advanced batch automation is achieved using a combination of

hardware and software. The lower level phase-control logic is
typically executed in controller hardware such as a PLC. The
higher level batch execution is done in software; it includes
control actions for Procedures, Unit Procedures, and Operations.
The batch execution software is also used for configuring and
managing recipes, scheduling campaigns, reporting, etc.

Figure 7-8. Batch Execution Software (Screenshot: GE Fanuc iBatch)

The batch execution software uses OPC-DA for passing set point
and other parameters to the underlying Phase logic. OPC-A&E is
used for capturing alarms during the batch execution and OPC-
HDA is used for batch history. A dedicated OPC-Batch specifica-
tion exists that includes specific namespace based on IEC 61512-1
(ANSI/ISA-88.01-1995) among other features.

Excel
In the past, data was manually collected from the automation
system and keyed into spreadsheets for analysis and reporting.
Data was not timely and only represented a snapshot of the plant
or factory as it was at some point in the past. The whole process
was tedious and error-prone. Data collection is now done in soft-
ware with OPC connectivity.

An OPC-to-Excel link can be used to automatically and continu-

ously bring live and historical data, including integrated totals
from anywhere in the automation system, into a spreadsheet
where sophisticated calculations, data manipulation, and chart
generation can be used. Reports can be generated much faster and
more accurately.
210 Software for Automation

The OPC-to-Excel link gets the data from the underlying automa-
tion system hardware or database through OPC client-server
connection and pipes the data into the cells of the spreadsheet
(Figure 7-9). A configuration wizard eliminates the need to manu-
ally write DDE topics, etc.

Figure 7-9. OPC-to-Excel Link (Screenshot: Matrikon OPC2XL)

The reader is cautioned that there have been patent disputes

regarding communicating data between a PLC and a spreadsheet
that may or may not include use of OPC. How this all will play
out remains to be seen, since the legal issues are unresolved as of
this writing.

Control
Hardware controllers are chosen to perform most basic automa-
tion tasks, because of their high reliability – particularly for
process control that demands very high availability. Control may
now also be done in software with OPC connectivity.

For some applications it is acceptable to do control in a regular

computer (Figure 7-10). Control strategies can be built using stan-
dard IEC 61131-3 languages: Ladder Diagram (LD), Function
Block Diagram (FBD), Instruction List (IL), and Structured Text
(ST). Further, logic can be structured using Sequential Function
Chart (SFC). Physical I/O signals are handled using remote-I/O
subsystems networked to the computer.

A software controller uses OPC-DA to read inputs from the

underlying I/O-subsystem and to write the outputs.
 Chapter 7 – Application 211

Figure 7-10. Software Controller Based on IEC 61131-3 Languages

(Screenshot: ICONICS ControlWorX32)

Statistical Process Control (SPC)

In the past, Statistical Process Control (SPC) required manual collec-
tion and entry into SPC software. An out-of-control process was
detected too late. SPC is now done in software with OPC connectivity.

SPC software acquires process data, analyzes it, and optionally

alarms if limits are exceeded (Figure 7-11). Control charts are used
to keep process in control and to identify special causes for fluctu-
ations. Data displays include histogram, all kinds of control charts
and Pareto analysis. Statistical calculations include standard devi-
ation and range. Normality tests include Kurtosis, Skewness, Chi-
Square, and so on.

The SPC application retrieves data using OPC-DA.

Figure 7-11. Statistical Process Control Application (ASI DataMyte, Inc.

Applied Stats)
212 Software for Automation

Other Software
In addition to all the software applications in the above categories,
there are a large number of unique and specialized applications for
all conceivable functions that use OPC to interface with other appli-
cations. In many cases a third party provides the OPC client inter-
face to someone else’s software. Applications include, for example:

• ODBC and SQL databases

• The MathWorks’ MATLAB® computing environment
• Pipeline leak detection
• Tank farm management

Data Servers
OPC-DA and OPC-A&E servers are available that capture both
live data as well as alarms and events and that work with inter-
face hardware for all kinds of automation protocols, legacy control
systems, and servers for specialized functions.

Legacy Control Systems

Controllers and I/O of legacy DCS and PLC may still be working
OK while operator workstations are completely outdated making
spares impossible or hard to come by. In this common scenario, a
popular solution is to use an interface converter and an OPC
server to get data from the control network to capture both live
data as well as alarms and events and to make it available to OPC
clients. OPC server solutions are available for all major legacy
DCS and PLC systems.

Automation Protocols
OPC servers and interface converter solutions are available for all
major automation protocols. Network protocols supported by
OPC servers include, but are not limited to:

• BACnet • IEC 60870-5

• CANopen • Interbus
• DNP3 • Modbus
• FOUNDATIONTM • PROFIBUS
Fieldbus
 Chapter 7 – Application 213

Many automation network protocols, such as PROFIBUS-DP,

require custom chip sets and many manufacturers, therefore, have
developed special adapter cards for these protocols. These manu-
facturers often supply an OPC server designed to work specifically
with their cards, and the server is tied to work only with that card.
On the other hand, some automation protocols such as Modbus
have less critical timing and can work through a regular computer
RS-232 port. This makes it possible to buy one of the many generic
Modbus OPC servers independent of hardware. Similarly, OPC
servers for automation networking based on Ethernet media can
simply use the Ethernet port on any computer and are, therefore,
not tied to a specific piece of computer hardware.

SNMP
Most Ethernet infrastructure devices such as LAN switches and
computers, as well as many automation devices, support the
Simple Network Management Protocol (SNMP). A SNMP OPC
server makes it possible to display network loading statistics and
health in operator workstation screens, such as in a system status
overview page. Performance can also be logged and alarmed. The
SNMP OPC server is explained in Chapter 9.

Universal
A universal OPC server can be configured to accept data from
hardware based on simple protocols. Examples of these include
weighing scales, barcode readers, and GPS (Global Positioning
Systems). The universal OPC server is explained in Chapter 4.

Simulator
An OPC simulator generates selected sequences of data in
selected data types (Figure 7-12). Typical sequence types include
sine wave, saw tooth, square wave, ramp, etc. The values can be
used for various simulation and testing purposes, in lieu of actual
hardware, or for training purposes.

Figure 7-12. OPC Simulator (Screenshot: SMAR SYSTEM302)

214 Software for Automation

Computer Resources
If a computer runs low on resources such as memory, disk space,
or processor time, critical applications such as OPC servers and
loggers may perform unsatisfactorily, negatively affecting other
software that relies on these applications. An OPC server for the
Windows performance monitor makes it possible to access a huge
amount of metrics on computer resources, CPU performance,
network throughput, and service activities from the machine (see
Figure 7-13). This includes information that can be seen in the
Windows task manager, and much more. The information can, of
course, be displayed in system status overview screens, as well as
be logged and alarmed. In fact, the performance monitor in
conjunction with trending is a powerful troubleshooting tool.

Figure 7-13. Filtered List of Tags in Windows Performance Monitor OPC Server

DDE Gateway
Some older applications and software not tailored specifically for
automation do not have OPC client interfaces but do support
DDE. Similarly, older hardware as well as hardware not tailored
specifically for automation do not come with an OPC server, but
do have a DDE server. To use such software and hardware in a
OPC-based system it is necessary to use a DDE gateway that
converts from OPC to DDE or from DDE to OPC. DDE gateways
are explained in greater detail in Chapter 4.

Industrial Computer Peripherals

Factories and plants often present harsh and difficult environments
for computers in automation systems. Workstations and servers can
usually be tucked away from ambient conditions in a clean and
 Chapter 7 – Application 215

controlled environment. In most cases, it is possible to use office-

grade equipment in control rooms. Industrial computers can handle
more demanding applications. Industrial computers and fault
tolerant servers are covered in Chapter 10. However, displays,
keyboards, and pointing devices must be accessible to the user, and
if the user is on the plant floor, these peripherals must handle harsh
conditions that prevail there, including washdown. Industrial-
grade computing gear range from articulating arms and stainless
steel enclosures to displays and keyboards. These components are
built on standards and, therefore, are compatible with regular
computers, including operating systems and software applications.

Industrial Displays & Touchscreens

There are many different computer monitors to choose from suit-
able to meet various different requirements. In the past, control
rooms had custom-made operator consoles with built-in monitors
and keyboards. However, these days it is far more common to place
regular monitors on a regular desk. When monitors are used on the
plant floor, such as next to a machine, they may either be fixed into
a panel or on a counterbalanced pendant arm that permits the posi-
tion to be adjusted to meet the needs of the operator.

Panel-Mounted Displays
Industrial displays can be mounted in the front of control panels
in the field or on the factory floor. These displays may be manu-
factured from stainless steel and are splash proof to IP65 and can
be mounted indoors or outdoor (see Figure 7-14).

Figure 7-14. Panel Display (Courtesy: IKEY)

Industrial panel-mounted computers look just like panel-mounted

displays but also include the computer motherboard, hard disk, etc.
216 Software for Automation

Touchscreen
Touchscreen is, in fact, a pointing device, but it is built into an
overlay on the display. Several different technologies exist such as
resistive, acoustic wave, infrared, and electrostatic. The most
common type is resistive. A touchscreen interfaces just like a
mouse and is, therefore, supported by an operating system, like
Windows, simply using a driver.

Multiple Screen
Operators need a large screen area to carry out tasks effectively.
Particularly during abnormal situations, it may be required to view
all pertinent information at the same time without having to spend
time navigating screens and waiting for displays to load. Oper-
ating systems such as MS-Windows support several windows
across multiple screens concurrently. For example, one screen can
be dedicated to alarm annunciation or process mimic, while the
other is used for general work. Screens are arranged vertically,
joined horizontally, or completely separate (see Figure 7-15).

Figure 7-15. Dual screen (Courtesy: Dell)

Display Wall
A display wall is particularly well suited for displaying large-scale
information such as a mimic of a process plant, factory or a hotel
building. Geographic maps for power lines or well sites, as well as
other topological information, is best shown on large screens.
Display walls use rear projection and are available in panel sizes
of 40-100 inches, which are designed to form display walls of any
size, in a linear or curved setup (see Figure 7-16). A wall is
composed of a matrix of rear projection modules that join hori-
zontally and stack vertically, forming a wall of any size with
screen stitching that results in a nearly imperceptible optical seam.
 Chapter 7 – Application 217

Figure 7-16. Display wall (Courtesy: Barco)

Hazardous Area Screen

In process control, it may be required to operate some plant units
from within a hazardous area, such as where flammable gas may
occasionally be present. Industrial monitors are available for Zone
1 and Zone 2 (Division 1 and Division 2) classified areas. Keyboard
and pointer may be integrated (see Figure 7-17).

Figure 7-17. Hazardous Area Display (Courtesy: Strongarm)

218 Software for Automation

Sanitary
The pharmaceutical industry and certain other application areas
require display on the plant floor to be designed to not trap dirt
and to make cleaning possible. Sanitary displays are made from
stainless steel, mounts flush, and are tightly sealed. Keyboard and
pointer may be integrated (see Figure 7-18).

Figure 7-18. Pharmaceutical Industry Display (Courtesy: Strongarm)

Industrial Keyboard
Two primary types of industrial keyboards are available:
membrane key or rubber key. The membrane keyboard is easier to
clean but has less tactile feel. Keys may be illuminated. Keyboards
may be manufactured from stainless steel and may come with
integrated pointer (see Figure 7-19).

Figure 7-19. Industrial Keyboard (Courtesy: IKEY)

The keyboard may be integrated with the display. A keyboard

alternative is to use a touchscreen and software keyboard.
 Chapter 7 – Application 219

Industrial Pointing Devices

Several types of industrial pointing devices are available. These
include trackball, touch pad, joystick, touch point, and industrial
mouse. Touchscreen is another type of pointing device. These
pointing devices are available in stainless steel and with sealed
buttons (see Figure 7-20). These pointing devices can be cleaned
and even submerged.

Figure 7-20. Stainless Steel Industrial Mouse (Courtesy: Strongarm)

The pointing device may be integrated with the display and keyboard.

Control Center Consoles

A very conducive and impressive work environment can be
created using purpose-built control center consoles with an
ergonomic design and aesthetic look (see Figure 7-21). Standard
LCD flat-panel or traditional CRT monitors are placed inside the
consoles and viewed through protective glass. No cutout is
required, so monitors can be replaced without modifying the
console. Modules can stack for two levels of displays. Work
surfaces and task lighting is also provided.

Figure 7-21. Operator Control Center (Courtesy: Evans Consoles)

220 Software for Automation

References and Bibliography

1. Berge, Jonas. Fieldbuses for Process Control: Engineering, Oper-
ation and Maintenance. ISA – The Instrumentation, Systems,
and Automation Society, 2002.

2. Wade, Harold L. Basic and Advanced Regulatory Control:

System Design and Application, 2nd Edition. ISA – The Instru-
mentation, Systems, and Automation Society, 2004.