8

Engineering &
Design

Because software plays a central role in all modern automation

systems, it should also be given due attention during system engi-
neering and design. When selecting the software architecture for
an automation system, important aspects to be engineered include
integrating sub-systems and legacy systems, locating servers,
networking, database sizes, and licensing requirements. Proper
documentation is essential to facilitate future expansion and
change, and to quickly recover from a system disaster. Even users
that buy a pre-packaged system may want to make an evaluation
of the vendor’s proposed solution.

Design
When designing the information architecture, you may wish to start
by defining the software needs including requirements for opera-
tors, controls, execution, and business. For example, you need to
define which Key Performance Indicators (KPI) and plant metrics
will be required. Other factors include electronic record keeping to
meet regulatory requirements. Next, determine information
required from the field to meet these needs, including sampling
and logging rates, etc. Lastly, determine which measurements are
required and how this information is gathered, communicated,
pre-processed, stored, computed, reported, and disseminated.

Control system software engineering is a big task starting with

selecting the appropriate operating system platform and software
interface technologies. Currently, Microsoft’s Windows NT series
of operating systems, including 2000 and XP, is the de-facto

221
222 Software for Automation

industry standard. The bulk of the software engineering work is

configuring devices, control strategies, and operator workstation
graphics. However, these tasks are simplified if the appropriate
software architecture is chosen.

Network Architecture
A very small centralized system needs only a single computer to
handle all functions including OPC servers, operator visualiza-
tion, database engine, etc. A distributed system including more
than one workstation will also need networking. Currently,
TCP/IP on Ethernet is the industry standard. Thanks to the multi-
protocol nature of Ethernet and TCP/IP, the same network is
shared by automation networking protocols and computer
networking protocols. Depending whether the application is
process control, building automation, or discrete manufacturing,
the automation networking protocol may be FOUNDATION™
Fieldbus HSE, Modbus/TCP, EtherNet/IP or another protocol.
The protocols between workstations and servers include OPC and
other data on DCOM, plus printer and file sharing protocols.

Distributing applications’ alarm and trending tasks to several

servers results in higher performance by taking the load off indi-
vidual servers. Depending on the layout of the plant, distribution
may also be a much better fit.

Having visualization and historian on the same network as the

controls means substantial traffic sharing bandwidth with the
automation function. Therefore, use FastEthernet at 100 Mbit/s or
faster cable and LAN switch infrastructure and computers even if
some automation devices only use 10 Mbit/s.

Figure 8-1. Network Architecture

 Chapter 8 – Engineering & Design 223

It may be a good idea to use Virtual LAN (VLAN) prioritization to logi-

cally separate control on the Ethernet by making OPC visualization data
lower priority than control data. VLAN capability is provided in
managed LAN switches.

Decide if a domain or workgroup networking scheme should be

used for servers and workstations. For a system with more than a
handful of computers, domain is preferred. Strive to have the
entire automation system in the same domain and on the same IP
subnet to simplify security management.

Database Engine and Sizing

One of the main software engineering decisions for a project is to
decide which database engine to use for historical logging of
process data, alarms, events, and other information that should be
recorded. This is also an important evaluation point for a pre-
packaged system. The database engine needs to be sized
according to plant requirements. This ultimately boils down to the
number of tags and the sampling rate, as well as the number of
users it can support. A very small system logging less than 150
tags with a sampling rate slower than 5 seconds, and only a single
user, may be able to use MS-Access. A larger system of up to five
users or more tags can use MSDE, but size is limited to two giga-
bytes. For a large system with many users or many tags, a large
SQL-based server is the ultimate solution. Other considerations
include ease of backup and maintenance, as well as the security
and verification. The fidelity of the compression and decompres-
sion algorithm is an important selection criterion for historians.

Database Engine Selection

The practical limit for MS-Access is about 10 database connec-
tions. One connection is required for each viewer, plus a few for
the different logger tasks. This limits the number of users. Simi-
larly, MSDE performance decreases above five connections.

MS-Access does not permit backup and maintenance while

logging since all connections must be closed, but it is possible
using an MS-SQL server and MSDE.

Use high-performance machines for database servers, such as

multiple fast processors, lots of RAM, fast hard disks, and archi-
tectures with cache. Run the SQL database software on server
hardware in a server operating system. If MS-Access is used in the
224 Software for Automation

same machine as other applications (i.e., not a dedicated logger

server), consider a separate hard disk for data logging.

Database Sizing
Estimating the database size is not an exact science, but it does not
have to be because storage space is not expensive, so you can
afford to buy extra. Every logger application has a different
scheme for optimizing the rows and records in the database table
to strike a balance of condensing data while at the same time
maintaining fast access speed. Some loggers may use additional
data compression to save disk space.

To ensure the logged data is easily accessed by third-party appli-

cations for display and reporting, it is important to understand
how data is organized, and if it is compressed by the logger.

Logger application documentation should provide guides for

calculating the required disk space based on number of tags,
logging rate, etc. The results are usually worst-case scenarios,
since logging is only done if the value actually changes. This
drastically reduces storage space requirements. To ensure good
performance, it is important that the size of the database is
controlled. Logger applications may employ schemes such as
cyclic database table mechanisms where data is written on a
circular buffer rotating basis in a fixed number of tables that
overwrites existing data as it rolls over to the next table.

Don’t forget to include the cost of database licensing when

making the project budget.

Servers
In a small system, the same computer can be used for OPC
servers as well as historical, alarm, and event logging, but for
large systems it is a good idea to move the historical, alarm and
event logging to dedicated server machines for best performance.
Refer to database engine and logger application documentation to
determine resources required based on the number of tags and
frequency of logging.

Servers are centralized repositories for lots of information

including data necessary for system operation. It is therefore
important that the server machines are sufficiently powerful to
serve up the data to all clients. The server machines must also be
 Chapter 8 – Engineering & Design 225

very reliable, since failure will cause costly shutdown and poten-
tial loss of data required for regulatory reporting, resulting in
fines. Make sure to use machines designed for server tasks and
consider using redundant and fault tolerant servers to increase
system availability. Also, consider redundant power supplies,
Uninterruptible Power Supplies (UPS), and hot-swappable and
redundant disk arrays (see Chapter 10).

Workstations
Software applications should be hardware independent, meaning
they should not require a particular brand or model computer in
order to work. The software should run on a mainstream oper-
ating system such as Windows to ensure other applications can
run on the same machine and good support is available. All appli-
cations specify minimum resource requirement in terms of
processor speed and memory requirements but should not narrow
down the options to one particular machine.

The computer must be able to withstand the environment where it

will operate. In a control room, a regular office-grade computer of
a reputable brand may be sufficient, while on the plant floor it is
necessary to use industrially hardened computers.

When designing the graphics for operator visualization displays,

make sure to be consistent in order to provide a friendly and
logical user interface for the operators. This includes, for example,
consistent display formats and terminology; consistent screen
hierarchy and navigation; and consistent use of color, shape,
animation, and symbols. Make sure, for instance, that “red” has
the same meaning—open, on, off or tripped—in all applications
throughout the plant. Every plant does it differently, but it should
be done consistently.

The operator displays should be designed to show text in the local

language where the system will be used. For package units and
many types of machines, which are mass produced and shipped
to different countries all over the world, it may be beneficial to
use operator visualization software that permit standard displays
to be developed with language switching capabilities. Rather than
using actual display text, the graphic displays are configured with
alias names. At run-time, the alias name is used to pick the actual
display text from the configured dictionary based on the selected
language. The dictionary can be created by the systems integrator
or by the end user (Figure 8-2).
226 Software for Automation

Figure 8-2. Utility for Configuring Language Switching

(Screenshot: ICONICS Genesis32)

Accurately estimating the number of points or tags required for a

software license is difficult because it depends not only on the size
and complexity of the plant and the machinery in it, but also on
how sophisticated screens are desired. For example, for a temper-
ature sensor it is possible to simply access and display only the
temperature value, or you can also show its validity and if it is
limited. Further, you can access parameters for more detailed
diagnostics, limits, basic configuration, create several alarms, and
perform trending. Moreover, different software applications count
tags differently (see Chapter 3).

Alarms
The alarm system needs to be designed carefully in order to help,
and not hinder, operation. Alarms should make the operator pay
attention and act. It is important to take measures already at
design time to eliminate alarm flooding during a process upset or
fault situation. As a rule of thumb, the alarm system should be
designed to generate no more than 10 alarms the first 10 minutes
after a major upset. This means the system integrator must be
disciplined when defining alarms to eliminate duplicate and other
nuisance alarms. Other basic rules include alarms only on
abnormal and unexpected events – not normal or expected. Do
not generate alarms on the operator’s own actions. Be selective
 Chapter 8 – Engineering & Design 227

when assigning alarm priorities. Define alarm priorities based on

whether the operator can do something about the cause, if there is
time to act, what happens if the operator fails to act or acts too
late. Assign max 10% of alarms as “high” priority and max 20% of
alarms as “medium”. Assign only one pre-alarm per alarm. The
EEMUA specification 191 gives some useful hints for alarm
management practices.

Test
Software can first be tested separately, but ultimately it should be
integrated with the hardware and be fully tested. Test procedures,
including what constitutes a pass or fail, should be agreed upon
between the user and systems integrator before testing starts.
Typically, testing is done in two steps; first software-only, then
integrated with hardware.

Software Test
Good OPC servers can run in a simulation mode, making it
possible to test much of the system software functionality without
having the automation devices connected. However, values gener-
ated may not be representative of the actual device.

Integrated Test
When the software is networked to the actual automation hard-
ware, it is possible to make a more exhaustive and realistic test of
associated software.

Documentation
Network and computer infrastructure in an automation system
must be well documented just like the sensors, actuators, and
logic. Documentation assists in troubleshooting, engineering for
future expansion, and change. Documentation may also be handy
in a cyber security incident and for system recovery. A site may
need paper copies of documentation handy in case the storage file
server cannot be accessed due to some cyber attack.

Network Documentation
It is a good idea to make a drawing of the computer network in
the automation system and document which user or group will
use each computer and which client applications will connect to
servers. This will make DCOM security configuration easier. The
228 Software for Automation

drawing should also include IP addresses, routers, and should

indicate subnets and domains. It may be a good idea to create
both a simple logical network diagram for easy overview and IP
addressing aspects, as well as a more detailed physical network
diagram for Ethernet wiring aspects.

Logical Network Diagram

A logical network diagram (see Figure 8-3) does not show the
actual Ethernet star topology wiring through LAN switches, but
the logical bus architecture as the network is perceived in most
people’s minds. It may include addressing issues such as
domains, subnets, and IP addresses. Primary and secondary
networks may be shown using different colors. If networks are not
too large, it is possible to show networks for more than one area
in the same drawing illustrating routers. This diagram is also suit-
able to illustrate the system architecture.

Figure 8-3. Logical Network Diagram Shows Addressing Aspects

Physical Network Drawing

A physical network drawing may include LAN switches, port
numbers, cable tags, etc. and shows the true Ethernet star or ring
topology. It may or may not include addressing issues such as
domains, subnets, and IP addresses. Like an electrical drawing or
loop drawing, a physical network drawing may indicate in which
telecommunications closet networking equipment is located.
 Chapter 8 – Engineering & Design 229

Because automation systems often use complete LAN redundancy

or in some cases, ring topology, a physical network drawing for
an automation system becomes far more complex than a regular
office network (see Figure 8-4). Therefore, showing more than one
network per drawing is difficult, and drawings will usually be
restricted to a single plant area or building floor. The network
cable is usually drawn as a single line, since the connector pin-
assignment is standard.

Figure 8-4. Physical Network Drawing Shows Wiring Aspects

Computer Documentation
Software comes with a unique set of documentation requirements.
Certainly in automation systems there is a need to document
control strategies as well as cross referencing between device
communication, drivers, and so on. However, these documents are
typically generated automatically by the configuration entry tools,
ready for display and printout. Additionally, carefully document
all DCOM configuration settings for each machine, because the
only way to back up these is to create an image of the hard disk,
which can only be done while all applications are stopped. It may
be a good idea to create a sheet for each computer and application
to tabulate the DCOM settings as well as other aspects. A critical
aspect of documentation is to track versions of all software, as well
as service packs and other updates being made. Configuration
changes made within the operating system and applications, as
well as in registry and INI files, must be documented. Documenta-
tion is necessary to restore a failed computer quickly.
230 Software for Automation

Computer Datasheet
A datasheet similar to the example in Table 8-1 may be helpful for
documentation and version management. For each computer
document setup, tabulate the default DCOM settings and list all
applications installed. This makes it easy to reinstall applications
and restore the computer after a failure.

Table 8-1. Computer Datasheet

 Chapter 8 – Engineering & Design 231

Application Datasheet
A datasheet similar to the example in Table 8-2 may be helpful for
documentation and version management. Every application and
component may require specific settings for DCOM security. For
each application, document the setup and tabulate any specific
DCOM settings as well as any specific configuration required.
This makes it easy to reinstall applications and restore the
computer after a failure.

Table 8-2. Application Software Datasheet

232 Software for Automation

Exercises
1. Give example of methods to ensure that non-real-time
communication does not consume all Ethernet bandwidth
when shared with the automation communication.

2. What is the maximum recommended alarm rate as a result

of a major process upset?

References and Bibliography

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

2. Alarm Systems - A Guide to Design, Management and Procure-

ment. Engineering Equipment and Materials Users Associa-
tion (EEMUA), Publication No.191, ISBN 0 85931 076 0, 1999.

3. Process Plant Control Desks Utilising Human-Computer Interfaces

- A Guide to Design, Operational and Human Interface Issues.
Engineering Equipment and Materials Users Association
(EEMUA), Publication No. 201, ISBN 0 85931 136 8, 2002.