Human Machine Interface

Chapter 15 HUMAN MACHINE INTERFACE
Introduction
Communications between processor and HMI (human machine interface) is an important subject
as well as constructing an operator interface. The chapter includes procedures for attaching
computers as HMI devices to the CompactLogix processor from A-B and the Siemens 1200
processor. Graphic control packages used are A-Bs RSView ME and Siemens WinCC. Other
packages exist and were not excluded based on their capabilities. The ones used are among the
more common and popular ones used today.
The following HMI panels communicating to PLC processors will be discussed in this chapter
followed by a lab that can show advantages and disadvantages of each.
RSView WinCC
ME
Fig. 15-1 HMI Graphic
Control Packages
Compact Siemens
Logix 1200
In each case, the emphasis is on getting a simple application operational and then expanding
from that, remembering the analogy of the kite flying with a simple string over Niagara River.
Later, the more difficult applications are discussed but only after a single button is programmed
from the HMI and communicates successfully to the PLC.
Historical Panel Design
The design of an operator panel requires much coordination with the programming of the PLC
and the design of the machine being controlled. Before the computer-designed systems, there
were individual component systems that were hard-wired to the control devices inside the panel.
Fig. 15-2 A Simple Control Panel

with Push Buttons and Switches
with Indicator Lights
Ch 15 Human Machine Interface 1

Fig. 15-3 This Printer is used for alarms for a process. Each alarm was recorded at the
time of occurrence and printed as a single line of data to be analyzed by a process
engineer or controls engineer.
Fig. 15-4 This panel

shows many discrete
devices as well as
mimic panels showing
process lines.
Meters show levels or

flows of various
devices.
Alarms are shown in

grids of illuminated
push buttons.

Fig. 15-5 Alarm panels were designed with discrete panels that lit or blinked with each
alarm. Buttons were used to acknowledge each alarm point.
Fig. 15-6 Data was collected with recording devices similar to the above. Multiple
points were individually recorded and studied.

Fig. 15-7 A handheld
thermocouple readout
device with paper
recording output
Fig. 15-8 Several discrete controller devices for process control. Each
device is capable of solving a single or multiple loops of process data
executing a PID formula and controlling the output of the control loop.

Fig. 15-9
Whatever the appearance of the outside

of the panel, the inside many times
looks similar to the panel shown at left.
It is too easy for the panel to look like
this after a short time even though the
original plan showed a neat design with
well-organized wiring layout. This is
not just a rare bad example.
Fig. 15-10
The picture below is of a panel

designed in 1980 for a chemical
batching system. It should be seen as
what was and not as what today
should be a good design. It cost
approximately $100K then and was a
divider between the operator room and
the instrument control room for the
process.

How to Improve Plant Operations through Better HMI Graphics
A number of good texts are available for better design of HMI graphics including:
The High Performance HMI Handbook by Bill Hollifield, Dana Oliver, Ian Nimmo and Eddie
Habibi
Designing for Situation Awareness (An approach to User-centered Design) by Mica R. Endsley
and Debra G. Jones
Human Machine Interface (HMI) Design: The Good, The Bad, and The Ugly (and what makes
them so) by Paul Gruhn, P.E.
Who wants to be responsible for designing an HMI graphic that can lead to confusion? The
following screen shows much confusion that should be avoided. (Fig. 15-11)
Five areas are primary in the successful design of a good HMI screen system. They are:
Situation Awareness
Using Color Effectively
Interpreting the data
Depicting Device State
HMI Display Organization
Situation awareness relates to the goals and objectives of a specific job or function. First of all,
designers and engineers form in their heads another mental model of the process than an
operator. By understanding how operators select and use goals, designers can better understand
how information is perceived. Without understanding the users goals on Situation Awareness,
the information that is presented has no meaning.
Applying SA terminology to HMI Graphics:
Level 1 SA P&ID representation with Live numbers

Level 2 SA Provide the operator with the relevant information they require to
understand how the plant is operating
Level 3 SA Provide trending data so that the operator can extrapolate the plants
performance to the future
Level 2 and Level 3 SA reinforces the operators mental model of the plant or process
A look back at how HMI Graphics have evolved. First from the 80s:
Is the pump in alarm or stopped?

Are the valves in alarm or closed?
High Contrast
These three areas are a big cause for eye fatigue.
In the 90s, the following characteristics were thought to be important:

Is this a good graphic?
What is the reactor temperature?
What Percentage of the screen is presenting useful data?
The pretty 3D objects and Gradient fill are superfluous
The flame attracts your attention
The moving truck attracts your attention
Overuse of color causes confusion.
Objects that have high contrast, warm colors or movement draw attention to themselves, causing
distraction and fatigue, possibly causing the operator to miss important data. Warm colors
include red, orange and yellows and, especially when flashing, draw attention. Also, complex
graphics and 3-D models draw attention to themselves and are to be avoided.
The Use of Trending
Using trend displays helps provide Level 3 SA projection of future status. By extrapolating, the
operator can then see where the process is heading. The operator can then be proactive and
recognize impending problems, rather than being reactive and responding to alarms and
problems after the fact. Use trending with thought. For instance, a trend display with eight
variables is confusing and takes a long time to analyze. We can see the value and its past trends.
We can make predictions of what the value is about to do based on its historical behavior.
BUT
What should the value be? What is the normal good operating high and low limits?
We can see the value and its past trends. We can see what the value should be. We can see what
are the normal operational high and low limits.
Using Color Effectively
Seven to 10 % of males are Red-Green color blind. Also, avoid using color alone to express
information. Only attract attention to an area of the display if there is an Abnormal Situation.

For things that are Normal
Gray is in fashion gray backgrounds, gray pipelines, gray vessels.

Use low contrast.
No animation, blinking or flashing to grab attention
For things that are Abnormal
Color, contrast, animation

Red and colors containing red for Alarms
Multiple digital devices can be represented as a light box. Running is a normal condition, so
there is no need to show a color for its status. How about going one step further and removing
the normal condition from the screen and only display the item if its in an abnormal condition.
Interpreting the data
Is this process healthy?

What should the numbers be?
How long does it take you to scan and interpret the information?
Do the numbers mean anything to you?
Are the numbers actually meaningful?
How much training would you require before you could interpret the numbers
We can now see the upper and lower limit for these values.
How long does it take you to scan and compare these numbers?
How much longer does it take you to calculate by how much they are within range?
This is data that requires examining and processing (Level 1 SA)
Data should be presented that supports comprehension (Level 2 SA)
Interpreting the data:
Normal operational values that are shown in white

High and low alarm ranges shown in dark gray
Desirable operational ranges that are shown in dark blue
Alarm indicator with priority level and color
Different shape for alarm priority
Depicting Material Balance
Two major accidents with flammable material have been attributed to HMI graphics that
have NOT shown flow in and flow out on the same graphic.
P&ID representation often leads designers of graphics to split the flow in and the flow
out of a vessel at opposite sides of a display, or on separate displays all too common
practice
A properly implemented mass balance or volumetric material balance calculation and
display of that data could have prevented these accidents

Level Indication
Provide high and low bad indication on the vessel

Provide normal good upper and good lower indication
Trend the level inside of the vessel outline
Depicting Device State
Do not use red for stopped or closed and green for running or opened. Only use color to
bring attention to an abnormal condition. A pump simply not running is often not an
abnormal condition.
Consider using a visually different shape within the object to represent running/opened.
This not only helps color blind people, but also aids understanding for everyone.
Use status words that describe the device state that is running and stopped. Words like
run and stop could be confused with command words. Provide feedback to a command
or button click within a time window that tells the operator that the command is being
acted upon.
Too slow (ASM states 3 seconds) and the operator may think the command wasnt
executed.
Too fast (ASM states 0.5 seconds) and the operator may miss the change.
HMI Display Organization
Provide information that helps the operator retain the data in short-term memory.
Group related information together so that it can be processed as one chunk.
The average short-term memory can hold seven items plus or minus 2, so group data
together to facilitate this fact.
If you have a vessel that has three specific values relating to it, then display it inside the
vessel, this allows the operator to see them as one chunk of data as opposed to placing
them outside of the vessel where the operator will see them as three individual pieces of
data.
Be consistent!
Putting Ideas into Practice
Only show information that supports comprehension of the process or plant. (Level 2 SA)
Represent key performance data as trends. (Level 3 SA)
Design to allow the operator to achieve their goals
Gray background, vessels and pipes, low contrast
Use of saturated color for abnormal plant conditions only
No movement of objects to distract attention
Avoid Gradient Shading
Use analog value indicators
Low-level details of plant are accessed by clicking to them
Consistent navigation across displays
Mixed case text is easier to read than ALL UPPER CASE.

Introduction and Overview of High Performance HMI
The process control and automation industry has spent billions on improving process safety via
complex, instrumented systems. Yet, we continue to frequently see industrial incidents,
accidents, and fatalities in the news. The causes are generally not the failure of such automated
systems but are instead the result of a wide variety of human errors. We firmly believe that
addressing the causes of human error and the improvement of Operator Effectiveness is of the
highest importance. The proper use of such technologies as High Performance HMITM
(HPHMI) and Alarm Management can actually save lives and prevent injuries. Detailed
information on these should not be withheld, and that is why we offer this and other white papers
freely. They can also significantly lessen process upsets, improve process efficiency, and
increase productivity.
The human-machine interface (HMI) is the collection of screens, graphic displays, and other
technologies used by the operator to monitor and interact with the control system (typically DCS
or SCADA). Several major accidents, such as the Texas City refinery explosion in 2005, have
cited poor HMIs as a significant contributing factor. The design of the HMI plays a critical role
in determining the operators ability to effectively manage the operation, particularly in quickly
detecting and resolving an abnormal situation, which is the most important task of an operator. A
poor HMI can actively interfere with this ability.
For several reasons, the current designs and capabilities of most HMIs are far from optimal for
running the kinds of complex operations we have in industry. Most HMIs consist simply of
schematic or P&ID style graphics covered in numbers. Such displays provide the operator large
amounts of raw data but almost no real information. They are difficult to interpret and provide
inadequate situation awareness to the operator.
Since we published The High Performance HMI Handbook in 2008, improving HMI has become
one of the hottest topics in the automation industry. In that book, we explained exactly why most
current HMI practices were poor, and we put forth the proper principles and details for making
graphics significantly better. Many companies have adopted those principles and have completed
migrations to improved graphics. Many more have such efforts currently underway.
This two-part paper provides a history, justification, and detailed plan of action for the
improvement of a process control HMI. Here is an overview of the contents.
Part 1
Examples: We provide typical examples of common but poor HMIs, along with highly
detailed depictions of improved methods that provide for much better operator situation
awareness and control.
Principles: We cover the most important aspect of HPHMI, the display of information to
the operator rather than raw data. Many other necessary graphic principles including the
correct way to use color are provided. Depictions of detailed graphic elements are
included.
Hierarchy: HPHMI graphic designs must reflect a proper hierarchy the exposure of
additional detail as needed. We include examples of graphics that illustrate this hierarchy,
along with the work processes used to design such graphics.

If your facility utilizes a process control system with a computer-based HMI, you will find this
information useful. This white paper augments the detailed content in The High Performance
HMI Handbook.
HMIs Past and Present
Before the advent of sophisticated digital control systems, the operators HMI usually consisted
of a control wall concept such as Fig. 15-11.
Fig. 15-12
Example of a Control Wall
The control wall had the advantages of providing an overview of the entire operation, key trends,
and a limited number of well-defined alarms. A trained operator could see the entire operation
almost at-a-glance. Spatial and pattern recognition played an important role in the operators
ability to detect burgeoning abnormal situations.
These systems had several disadvantages. They were difficult to modify, the addition of
incremental capabilities was problematic, and the ability to extract and analyze data from them
was almost non-existent. In the 1980s-1990s, the modern electronic control systems (DCS/
SCADA) replaced them for such reasons.
When the modern systems were introduced, they included the capability to create and display
graphics for aiding in the control of the operation. However, there were no guidelines available
as to how to create effective graphics. Early adopters created graphics that mimicked P&ID or
schematic drawings, primarily because they were readily available. The limited color palette was
used inconsistently, and screens began to be little more than crowded displays of numbers on a
P&ID.

Fig. 15-13
Early Graphic
Showing Many
Problematic
Practices
Graphics such as Fig. 15-13 and 14 were developed over 20 years ago and remain common
throughout the industry. Indeed, inertia, not cost, is the primary obstacle to the improvement of
HMIs. Engineers and operators become accustomed to this style of graphic and are resistant to
change.
Fig. 15-14
A Typical
Crowded, P&ID-
Style Graphic
As a result, industries that use modern control systems are now running multi-million dollar
operations from primitive HMIs created decades ago at a time that little knowledge of proper
practices and principles was available.
As control system hardware progressed, the manufacturers began to develop very flashy example
graphics which were used for marketing purposes. While fit for that purpose, they were quite
ineffective for actually controlling a process. Many companies and projects, however, began to
create graphics similar to those examples. The results were displays that are actually suboptimal
for operators.
To illustrate this point, Fig. 15-15 is an example of flashy design taken from a power generation
facility. The graphic dedicates 90 percent of the screen space to the depiction of 3-D equipment,
vibrantly colored operation lines, cutaway views, and similar elements. However, the
information actually used by the operator consists of poorly depicted numerical data, which is
scattered around the graphic, and only makes up 10 percent of the available screen area.
Fig. 15-15
A Flashy Graphic
inappropriate for
Actual
Operational
Control
There are no trends, condition indicators, or key performance elements. You cannot easily tell
from this graphic whether the operation is running well or poorly. That situation is true for more
than 90 percent of the graphics used throughout industry today because they were not designed
to incorporate such information. Instead, they simply display dozens to hundreds of raw numbers
lacking any informative context.
Justification for HMI Improvement
Poorly performing HMIs have been cited time and again as significant contributing factors to
major accidents. Yet, our industry has made little significant change in HMI design. There is
another industry that learns from its accidents and has made phenomenal advancement in HMI
design based on new technology. That industry is avionics. The resulting improvement in pilot
situation awareness is one of the largest contributing factors in the decades-long decline in
aviation accidents.
Fig. 15-16
Garmin G2000
Avionics Package
in a Small Plane

Modern avionics feature fully-integrated electronic displays as shown in Fig. 15-16. These depict
all of the important information, not just raw data, needed by the operator (i.e., pilot). Position,
course, route, engine diagnostics, communication frequencies, and automated checklists are
displayed on moving maps with built-in terrain proximity awareness. Real-time weather from
satellite is overlaid on the map. Detailed database information on airports is available with just a
click. Situation awareness and abnormal situation detection is far improved by these advances.
This capability impossible even a dozen years ago in multi-million dollar airliners is now
standard on even the smallest single engine aircraft.
There have been tests involving actual operators running realistic simulations using traditional
graphics vs. High Performance ones. PAS participated in such a test at a large power plant,
sponsored by the EPRI and detailed later in this paper. The results were consistent with a similar
test run by the ASM (Abnormal Situation Management) Consortium on an ethylene plant. The
test showed the High Performance graphics provided significant improvement in the detection of
abnormal situations (even before alarms occurred) and significant improvement in the success
rate for handling them. In the real world, this translates into a savings of hundreds of thousands
of dollars per year.
Since safety is significantly improved with modern HMIs, it is only logical that we would want
all operators to have access to them. Yet, most companies have done little to upgrade.
Proper Graphic Principles
Ineffectively designed graphics are easy to find. Simply search the internet for images under the
category HMI. Problems with these graphics include:
Primarily a schematic or P&ID representation

Lots of displayed numbers
Few or no trends
Spinning pumps/compressors, moving conveyors, animated flames, and similar distracting
elements
Brightly colored 3-D equipment
Highly detailed equipment depictions
Attempts to color code piping with contents
Long, cryptic tag names shown on the screen
Brightly colored liquid levels displaying the full width of the vessel
Lots of crossing lines and inconsistent flow direction
Inconsistent color coding
Bright colors on dark backgrounds
Misuse of alarm-related colors
Limited, haphazard navigation
A lack of display hierarchy
Ineffective graphics encourage poor operating practices, such as operating by alarm. By contrast,
High Performance graphics have:
A generally non-schematic depiction except when functionally essential and at Level 3

Limited use of color, where color is used specifically and consistently
Gray backgrounds to minimize glare and reflection issues
No animation, except for specific alarm-related graphic behavior
Embedded, properly-formatted trends of important parameters
Analog representation of important measurements, including their value to normal, abnormal,
alarm, and interlock conditions
A proper hierarchy of display content providing for the progressive exposure of detailed
information as needed
Simple and straightforward depictions in 2-D not 3-D
Consistent flow depiction and layout to minimize crossing lines
Embedded information in context (via right-click menus or similar methods) such as alarm
documentation and rationalization, standard operating procedures, and more.
Logical and consistent navigation methods
Techniques to minimize operator data entry mistakes
Validation and security measures
Show Information Instead of Raw Data
A primary difference of High Performance graphics is the underlying principle that, wherever
possible, operational values are shown in an informational context and not simply as raw
numbers scattered around the screen.
As an example, consider this depiction of a compressor shown in Fig. 15-17. Much money has
been spent on the purchase of instrumentation. Yet, unless you are specifically trained and
experienced with this compressor, you cannot tell if it is running at peak efficiency or is about to
fail.
Fig. 15-17
All Data, No Information
The mental process of comparing each number to a memorized mental map of what is good is
a difficult cognitive process. Operators have hundreds (or even thousands) of measurements to
monitor. Thus, the results vary by the experience and memory of the operators as well as how
many abnormal situations they have personally experienced with this particular compressor.
Training new operators is difficult because the building of these mental maps is a slow process.
Adding more numbers to a screen like this one does not aid in situation awareness; it actually
detracts from it.
By contrast, a bank of analog indicators, as in Fig. 15-18, can represent these numbers much
more effectively. Analog is a powerful tool because humans intuitively understand analog
depictions.

Fig. 15-18 Analog Depiction of Information
Fig. 15-19 Further Explanation of Moving Analog Indicators
We are hard-wired for pattern recognition. With a single glance at this bank of properly designed
analog indicators, in Fig. 15-19 above, the operators can tell if any values are outside of the
normal range, by how much, the proximity of the reading to both alarm ranges, and the values at
which interlock actions occur. Analog depictions such as these moving analog indicators are a
key element of HPHMI.

In just a second or two of examination, the operator knows which readings, if any, need further
attention. If none do, the operator can continue to survey the other portions of the operation. In a
series of short scans, the operator becomes fully aware of the current performance of their entire
span of control.
The knowledge of what is normal is embedded into the HMI itself, making training easier and
facilitating abnormal situation detection, even before alarms occur, which is highly desirable.
Similarly, depiction of PID controllers is accomplished with the addition of easily scanned
setpoint, mode, and output information, as in Fig. 15-20. If the final control element has a
position feedback signal, deviation is easily and effectively shown on the output scale.
Mechanical deviations are prime causes of abnormal situations, and they should be made easy to
spot.
The subtle, slight gradients and shadows are intended to increase prominence of the live
elements. Images in printed form are often significantly different than images shown on a screen.
For that reason, other modifications to increase printed visibility have been made on some
depictions in this paper. Actual design of HPHMI elements concerns their appearance on the
screen.
Fig. 15-20 Analog Depiction of PID Controllers
Proper User of Color
Color must be used consistently. People have several types of common color-detection
deficiency (e.g., red-green, white-cyan, green-yellow). For this reason, the most important rule
for color is this:
Color, by itself, is never used as the sole differentiator of an important condition or status
Most graphics throughout the world violate this principle. A color palette must have a limited
number of distinguishable colors used consistently. Bright colors are primarily used to bring or
draw attention to abnormal situations, not normal ones. Screens depicting the operation running
normally should not show brightly saturated colors, such as bright red or green pumps,
equipment, valves, and similar items.
When alarm colors are chosen, such as bright red and yellow, they are used solely as an aspect of
the depiction of an alarm-related condition and for no other purpose. If color is used
inconsistently, then it ceases to have meaning. Fig. 15-21 is a workable HPHMI color palette,
and the example figures in this paper generally follow it. There should not be very many colors,
and all colors must be easily distinguishable.
Fig. 15-21 An Example of HPHMI Color Palette
Graphics with color-neutral gray backgrounds on LCD screens are effective. They also enable
the lights in the control room to be turned back to bright where they should be. Poor graphics
began with dark backgrounds and bright colors due to 1980s-90s CRT hardware limitations. This
scheme resulted in major glare and reflection problems which were addressed by dimming the
control room lights. For operator alertness, the control room lighting should actually be brighter
than a typical office, all day and all night.
Elements and Depictions of HPHMI
This section shows many of the common situations that a process graphic must depict and how to
accomplish those depictions by following High Performance HMI principles.
Depicting Process Values
The display of live values on the screen should be shown in a different way than static text:
The choice of a bold, dark blue is a good choice with the gray background and
differentiates live values from static text done in black or dark gray as in Fig. 15-22.
Leading zeros are not displayed, except on fractional values (e.g., 0.27). Values are
shown only to the precision needed by the operator.
In tables or columns, generally align numbers on the decimal point.
Units of measurement are displayed in non-bold text near the value.
Point names should not be shown on the screen by default. It should never be necessary
for an operator to have to type in a point name in the entire HMI.
Process values can have a variety of diagnostic conditions. Fig. 15-22
shows a clear, concise, and visible way for depicting those. Color coding is not
recommended.
When items are selected, that status should be indicated. Surrounding the selected
item with a white outline is a good practice.
Fig. 15-22
Depicting Process
Values
Depicting Alarms
Proper alarm depiction should also be redundantly coded based upon alarm priority (color /
shape / text). Alarm colors should not be used for non-alarm related functionality.
When a value or object comes into alarm, the separate alarm indicator appears next to it, as
shown in Fig. 15-23. The indicator flashes while the alarm is unacknowledged (one of the very
few proper uses of animation) and ceases flashing after acknowledgement but remains visible as
long as the alarm condition is in effect. People do not detect color change well in peripheral
vision, but movement such as flashing is readily detected. Alarms thus readily stand out on a
graphic (and on multiple screens) and are detectable at a glance.

Fig. 15-23 shows that the most common methods of alarm indication are a direct violation of the
basic rule of color use, as they are different solely by the use of color.
Fig. 15-23
Depiction of Alarms
It is highly beneficial to include access within the HMI to the alarm rationalization information
contained in the Master Alarm Database as show in Fig. 15-243. If these terms are unfamiliar,
you are advised to read the ISA 18.2 standard for Alarm Management in the Process Industry, or
read the API RP-1167 Alarm Management Recommended Practice if you are in the pipeline
industry. PAS offers free white papers explaining both documents.

Fig. 15-24
Linked Alarm Information
Depicting Profiles of Temperature or Pressure
Consider these alternative distillation column temperature profile displays. When only numbers
are shown, even an experienced operator may easily miss a suboptimal condition. Additionally, a
new operator will find it difficult to build a mental map of a proper profile. The desire is for all
operators to recognize normal and abnormal profiles at a single glance.
Fig. 15-25
Measurement Profile
A correct profile can be seen at a glance as a straight line.
Depicting Dynamic Equipment
So what about the paradigm of using bright green to depict ON and bright red for OFF (or
vice versa in the power industry)? This is an improper use of color. The answer is a depiction
such as Fig. 15-26.
The relative brightness of the object shows its
ON-oFF status, as does the use of a process
value word next to it. Equipment items brighter
than the background are ON (think of a light
bulb inside them). Items darker than the
background are OFF. If equipment has no
status that is sensed by the control system, but
is desired on the graphic anyway, it is shown as
transparent to the background color. The status
word can indicate several conditions, as shown.
Remember, if any of those are also alarm
conditions, the separate alarm indicator will
appear next to the equipment when it is in an
alarmed state.
Fig. 15-26 - Depicting Status with Redundant

Coding and Proper Color Usage
Bars vs. Pointers
Attention to detail is important. It is typical to use bar graph elements to show relative positions
and values. While this may be better than simply showing numbers, it is inferior to the use of
moving pointer elements since the bar disappears as the bars value gets low. The human eye is
better at detecting the presence of something than its absence. And, the low condition may be
more important than the high condition and should have equal visual prominence. The example
in Fig. 15-27 is superior in showing relative values, besides the color improvement.
Fig. 15-27
Bars vs Pointers
Depicting Level Indication
Vessel levels should not be shown as large blobs of saturated color. A simple strip depiction
showing the proximity to alarm limits is better. A combination of trend and analog indicator
depictions is even better such as Fig. 15-28. The right-hand edge of the trend replaces the pointer
and provides context.

Fig. 15-28
Vessel Levels
Depicting Control Valves and Shutoff Valves
Control valves turn out to be one of the more complicated items to depict. The tendency is to
want to cram too much data into a small space. Traditionally, we depict a control valve
(throttling, variable position) with a domed head depiction and an automated block valve (only
on-off) with a rectangular head depiction.
In keeping with equipment depictions, the valve body is filled darkly for closed and brightly for
open. This also follows the P&ID paradigm for block valves. The same method can depict the
state of three-way valves. The solenoid and position switch statuses can also be shown if desired.
Fig. 15-29
Control and Automated
Block Valves

Depicting Equipment Commands
When DCS/SCADA points are built that indicate equipment state, the control engineer can
usually decide which words to display to represent the current state. The choices they make are
often poor. The most common example is RUN and STOP. Do these represent the
equipments status, or a command to it? RUNNING and STOPPED are much better status
indication words. STOP and START are commands, not statuses.
Similarly, the graphics need to differentiate clearly between status indications and command
possibilities. In general, the graphic indicates the current state, and faceplate interactions are used
to command changes to that state. It is common to have a point type that includes both a switch-
type (binary) output command and binary status feedback, commonly called a Digital Composite
Point. Fig. 15-30 shows a compact graphic presentation of those statuses. Selecting the graphic
element would call up the faceplate for the actual interaction.
Fig. 15-30
Digital Composite
Point Depiction
Use of Trends
The most glaring deficiency in HMI today is the general lack of properly implemented trends.
Every graphic generally has one or two values on it that would be far better understood if
presented as trends. However, the graphics rarely incorporate them.
Instead, engineers and managers believe vendor claims that their operators can easily trend any
value in the control system on demand with just a click. This is incorrect in practice; a properly
scaled and ranged trend may take 10 to 20 clicks/selections to create and usually disappears into
the void if the screen is used for another purpose (like calling up a different graphic).
This deficiency is easily provable; simply walk into the control room and count how many trends
are displayed. Our experience in hundreds of control rooms is that trends are vastly underutilized
and situation awareness suffers due to that.
Trends should be embedded in the graphics and appear, showing proper history, whenever the
graphic is called up. This is generally possible but is a capability often not utilized. Trends
should incorporate elements that depict both the normal and abnormal ranges for the trended
value. There are a variety of ways to accomplish this as shown in Fig. 15-31. The range indicator
could also indicate the alarm and interlock ranges (see the later Level 1 Overview Example; Fig.
15-44).

Fig. 15-31
Trend Depiction of
Desirable Ranges
Depicting Tables
Even tables and checklists can incorporate proper principles as shown in Fig. 15-32. Consistent
colors and status indication can be integrated. The intent is to make the abnormal stand out.
Fig. 15-32
Tables and
Checklists

Depicting Advanced Process Control
Advanced Process Control (APC) is also known as Multi-Variable Control. It is the method by
which a sophisticated computer program monitors the process and adjusts controllers in real time
to continually optimize performance.
Not all controllers are touched by the APC system, and it is useful for the operator to see
which ones are and what the APC system is doing with them. Small indicators next to the
affected controllers are useful for this. Fig. 15-33 shows this with an alternative, non-analog PID
controller representation that is useful in some circumstances.
Fig. 15-33
Advanced Process Control
A Level 2 or 3 screen showing overall health and functionality of the APC system itself is
desirable.
Depicting Shutdown Activation
Operators must have the ability to shut down operating equipment manually and quickly.
However, when an important action with significant consequences is based upon operator input,
the input should have a confirmation mechanism that avoids inadvertent activation. The
cancellation option should be consistently implemented.
It should never be possible to make a single selection on a screen that results in an inadvertent
shutdown. A Shutdown button should call up at least one, and perhaps two, layers of
confirmation before it is possible to actually cause such a significant event.
The defaults of such mechanisms should be on the safe option. Always consider what an
inadvertent ENTER will do and label screen items with full clarity.
Major process upsets have occurred by mistyping an input (for example, opening a slide valve to
47 percent instead of 4.7 percent). Older DCSs using membrane keyboards are particularly
susceptible to this type of error. Error checking methods should be used to require confirmation
of numerical entries that seem inappropriate.

Fig. 15-34
Layers of Confirmation
Depicting Interlock Functionality
Interlocks are functions whereby normal control actions are overridden by predetermined process
conditions. An example would be to override a steam valve to the closed position if the
equipment temperature or pressure is too high. There are several HMI-related issues to be
addressed for interlocks, and these must be handled regardless of whether the interlock is
implemented in the DCS or in a separate Safety Instrumented System.
Fig. 15-35
Interlock Symbology
Interlocks are implemented using logic structures, usually blocks or points or ladders.
These are usually complicated and cryptic to understand when displayed using the native
capabilities of the DCS (e.g., logic point detail). They may activate infrequently since they are
usually designed to protect against an abnormal situation. Due to this, the operator may not
encounter them for months. When they activate, the operator may not remember being told about
the new column interlock implemented a year ago and have no idea why he cannot start feed to
the column. If this occurs at 2 a.m. on a Saturday night, then the engineer is (deservedly) likely
to get a phone call and production may be delayed.
Therefore, every interlock, when activated, needs to indicate that activation on the appropriate
Level 2 and 3 display. The strategy may be different for those displays.

Fig. 15-36
Interlock Before and After
Activation
For Level 2 displays, a small bank of interlock symbols can be created, with functionality as
shown in Fig. 15-37 and 47. An element next to it can indicate the interlock action conditions.
When an interlock becomes active, any element that it is affecting (such as a pump or control
valve) should have the interlock symbol appear next to it. In this manner, the operator can clearly
see which interlocks are in effect and what items they are affecting.
Fig. 15-37
Interlock Diagnostic Table
For Level 3 displays, a more detailed view of the interlock can be shown such as in Fig. 15-38.
When active, the specific interlock symbol can be displayed next to each initiator signal and
affected output. For Level 3 displays, an interlock diagnostic element should be created, clearly
showing the possible initiators and possible actions taken by the interlock. This does not have to
be complicated; a table such as the following can often suffice.

Fig. 15-38
Shutdown Initiator with First-Out
When an interlock shuts down a piece of equipment, a First Out indication is often desirable
since some of the other initiators may activate after the shutdown trip occurs. Fig. 15-38 is a
simple example of a Shutdown First Out Table:
Shortly after the compressor shuts down due to high vibration, the oil pressure also drops which
produces another shutdown initiator. As a result of equipment isolation, the suction pressure may
also drop sufficiently to activate another shutdown initiator. Thus, by the time the diagnostic
graphic is consulted, three separate shutdown causes are present and the question is which is
the original culprit? Two are a consequence of the immediately prior shutdown, and the actual
cause of the shutdown is shown via the First Out. The vibration reading depicted is currently
much less than the shutdown limit (since it quits shaking after the shutdown), thus the high
vibration indication (the X) needs to be latched until reset.
Startup Map
Consider the principle illustrated by Fig. 15-39. The roadmap for a proper startup is clearly
depicted and progress is visible. (In this case, the trend lines grow from the left.) The roadmap
reflects the proper rates and conditions for temperature rise, staggered feed introduction, and
staggered additive introduction. It takes many pages of written procedures to describe what this
single diagram more clearly depicts. The structure gives the operator proper situation awareness
and shows not only what has happened, but what is coming up next. A picture of a P&ID
sprinkled with live values can do none of this, yet startup graphic elements like this are
extremely rare. People may say, But it costs money to design custom elements like this! Yes,
but we dont save money by not painting lane divider lines in our roads. A single poorly-
executed startup often costs much more than proper HMI development.

Fig. 15-39
High Performance Element
Designed for Startup Use
Navigation and Command Buttons
Multiple methods of navigation should be provided. The operator should be able to go up and
down through the hierarchy, side to side through the process, and call related details, trends, and
shutdown status displays from any graphic. This navigation capability should work with all
available methods provided by the DCS vendor mouse or touch screen target selections,
keyboard keystrokes, context sensitive menus, or others.
Fig. 15-40
Navigation Buttons
and Targets
Every screen (particularly Level 2) should have navigation targets to the most likely other
screens that the operator would access. When a P&ID depiction is used, any process line entering
or exiting the screen should contain a navigation link to the relevant graphic. Navigation buttons
or targets should be consistent and simple (and not look identical to command buttons). Most
control systems provide pre-made navigation button objects, including many that are
inappropriately colored, needlessly 3-D, and overly intrusive.
The system and graphics should be configured so it is never necessary for the operator to type in
a point name or graphic name. Some DCSs have arrays of programmable keys, which can be
assigned to call up certain displays or combinations of displays. For systems that do not,
programmable key arrays are inexpensive on the computer accessory market.

Implementing an entire navigation structure in a single Windows-type pull-down hierarchical
menu (i.e., one with sub-menus that pop-out of the side) is generally not recommended,
particularly a structure more than two levels deep.
The Main Menu: It is desirable for the operator to have two-click access from any graphic to any
other graphic, to supplement any other navigation method used. Every graphic should have a
consistently placed Main Menu navigation button. It opens a simple text screen, logically and
hierarchically arranged, with one-click navigation links to all graphics.
Display Layout and Faceplate Handling
Displays need a consistent look and feel. Different DCSs have unique embedded structures and
paradigms around the location and type of navigation abilities, faceplates, change zones,
programmable keys, and similar items. These features should be implemented in such a way as
to comply with the principles of High Performance displays.
It is important to use these built-in abilities to their maximum potential. It is inadvisable to

attempt to make a Brand XYZ DCS look like a Brand ABC. The results will usually be far
from optimum.
Fig. 15-41
Navigation Buttons and
Targets
Layout for a typical screen is shown in Fig. 15-41. Screen layout usually includes these
elements:
A top menu and status area shows a variety of information, such as screen and alarm
controls. This element is provided by the DCS manufacturer, is often mandatory, fixed
in size, and usually configurable in several ways.
A bottom status line area, usually optional, depicts information about a selected
object, a command, or similar condition.
A process depiction area is where the graphic is created.
A reserved area for faceplates is provided. (This reserved area is a High Performance
practice.)
When screen objects are selected, additional information about them should be shown. This is
typically in the form of a faceplate popup. If the operator can interact with or manipulate the
object, the interface for that interaction is contained in the faceplate. A reserved area in which the
faceplate appears is important. It is undesirable for a faceplate to appear randomly on the screen,
obscuring the primary graphic, and then requiring it being manually dismissed or moved.
Reserved areas should be a rectangular area on the upper or lower right side of the screen, or a
narrow strip across the bottom or right-hand side.
The size of the reserved faceplate area is determined by the brand of DCS. Ideally, faceplates are
tall and narrow. This provides for placing them adjacent to the right-hand edge of the graphic,
leaving a large, contiguous, mostly rectangular area for the process depiction. But, some DCSs
have faceplates that are large, square, clunky, and poorly organized, making a reserved area for
them difficult to accomplish. If you own such a system, encourage the manufacturer to move into
the 21st century and modify their standard faceplates.
Only one item on a screen should be selectable at a time. Any new selection on the screen should
replace any prior faceplate from a prior selection, without any manual closing of the prior
faceplate needed. On a few screens, it might be desirable to enable more than one faceplate at a
time.
Faceplates are usually supplied as standard elements by the DCS manufacturer. It may or may
not be possible to alter them, and they may not follow some of the principles you desire for your
HMI, such as proper and consistent use of color. However, rebuilding or replicating dozens of
standard faceplates from scratch to correct minor consistency issues may not be worth the effort
since future vendor software upgrades may override that work.
The faceplate should show the point name and description since point names should not normally
be shown on a graphic. Exposing even more configuration information (i.e., Level 4 point
detail or configuration data) about the point should be possible from the faceplate element.
Faceplate interaction should not be modal (i.e., preventing other graphic action until the faceplate
is closed).
We have seen a presentation advocating that faceplate functionality (altering setpoints, outputs,
modes, states, etc.) be incorporated into the graphics themselves and the use of the standard
faceplate interaction eliminated. Now, as you can imagine, we are always open to evaluating new
ideas, but not every new idea is a good one! The claim is made that it is speedier and the
operator might save fractions of a second per interaction that way, which will add up to maybe
several hours saved per year. This is a bad idea, because huge amounts of additional custom
coding and its upkeep are needed and significant layout and consistency problems must be
addressed. Stick with faceplates.
Depending on DCS HMI capabilities, other methods for point information manipulation are
possible, such as right-click menu access.
Avoiding Blob Graphics
Some places have carried the gray-scale principle too far and created extremely low-contrast
blob graphics shown in Fig. 15-42. These are gray-on-gray, typically without even thin black
boundary lines defining the various elements. These are a bad idea; we have seen many operators
squinting at these to figure out what is happening. Graphics should be clear and unambiguous,
and blob graphics are not recommended. The key is to provide easy visibility of elements but to
reserve emphasis for abnormal situations.
Fig. 15-42
Blob Graphic Elements
with Insufficient Contrast
Display Hierarchy
Displays should be designed in a hierarchy that provides progressive exposure of detail. Displays
designed from a stack of P&ID schematic designs will not have this; they will be flat like a
computer hard disk with one folder for all the files. This does not provide for optimum situation
awareness and control. A four-level hierarchy is desired.
Fig. 15-43
High Performance
HMI Display
Hierarchy

Level 1 Operation Overview
Fig.15-44 Example Level 1 Display
This is a single graphic showing the operators entire span of control, the big picture. It is an
overall indicator as to how the operation is running. It provides clear indication of the current
performance of the operation by tracking the Key Performance Indicators as in Fig. 15-44.
Level 1 Overview graphics are usually not designed for making control interactions (i.e., no
faceplate zone).
The Fig. 15-44 example is from a large power plant. We often hear But it doesnt look like a
power plant! Correct! Does your automobile instrument panel look like a diagram of your
engine surrounded by numbers? The display is designed so that it is easy to detect if the plant is
running well or poorly and that important abnormal conditions and alarms stand out clearly.
The Level 1 graphic is ideal for display on a large, perhaps off-console, monitor. Many have
purchased such large screens with little idea of how to make the best use of them.

Level 2 Unit Control
Fig. 15-45 Example Level 2 Display of a Reactor
Every operation consists of smaller, sub-sectional unit operations. Examples include a single
reactor, a pipeline segment, a distillation train, or a compressor station. A Level 2 graphic exists
for each separate major unit operation. It is designed to contain all the information and controls
required to perform almost all operator tasks associated with that section from a single graphic as
shown in Fig. 15-45.
Notice how the analog indicators and controllers are lined up for easy scanning rather than being
scattered all around a P&ID depiction. Ease of abnormal situation detection is an important
HPHMI design consideration.
When properly designed, most operator actions will occur at Level 2, and the Level 3 graphics
will be used only for more detailed troubleshooting.

Level 3 Unit Detail
Fig. 15-46 Example Level 3 Display
Level 3 graphics provide all of the detail about a single piece of equipment. These are used for
detailed diagnosis of problems. They show all of the instruments, interlock status, and other
details. A schematic or P&ID type of depiction is often desirable for a Level 3 display.
The Fig. 15-46 example shows what could be created from scratch as a Level 3. Besides the
P&ID depiction, other HPHMI elements are included. In existing systems, most graphics are
actually Level 3. See the HPHMI Implementation on a Budget section in the Part 2 document
for guidance about this.
Level 4 Support and Diagnostic Displays
Level 4 displays provide the most detail of subsystems, individual sensors, or components. They
show the most detailed possible diagnostic or miscellaneous information. A Point Detail
display is a typical example. The dividing line between Level 3 and Level 4 displays can be
somewhat gray.
Conclusion:
The principles of High Performance HMI are specifically developed to deal with the needs of
todays operators regarding the complex systems they manage. A High Performance HMI is
designed to be the best tool for operator interaction with the process control system. It is
designed to maximize operator situation awareness and abnormal situation detection and
response.

A Real World Case Study and Test of HPHMI Concepts
The following section is taken from a study conducted by the Electric Power Research Institute
(EPRI).
Operator HMI Case Study: The Evaluation of Existing Traditional Operator Graphics vs.
High Performance Graphics in a Coal Fired Power Plant Simulator, Product ID 1017637
Fig. 15-47 1990s Graphics from the EPRI HPHMI Test
The EPRI study tested the HPHMI concepts in this paper at a large, coal-fired power plant. The
plant had a full and accurate simulator used for operator training. The existing graphics on the
simulator (created in the early 1990s) operated the same as those on the actual control system.
PAS was retained to prepare several High Performance graphics for the simulator. Several
operators were then put through multiple abnormal situations using both the existing and the new
High Performance graphics.
Four examples of the existing graphics are in Fig. 15-47. They have the following characteristics:
Many controller elements are not shown on any of the existing graphics.
No graphic hierarchy.
No Overview.
Numbers and digital states are presented inconsistently.
Poor graphic space utilization.
Inconsistent selectability of numbers and elements.
Poor color choices, overuse, and inconsistencies.
Bright red and yellow used for normal conditions.
Poor interlock depiction.
No implemented trends (trend-on-demand rarely used by the operators).
Alarm conditions generally not indicated on graphics even if the value is a precursor
to an automated action.
The operators used dozens of such graphics to control the process. PAS prepared the following
High Performance graphics:
Power Plant Overview (Level 1) Fig. 15-48

Pulverizer Overview Graphic (Level 1.5) Fig. 15-49
8 Individual Pulverizer Level 2 Control Graphic Fig. 15-50
Runback 1 and 2: Special Abnormal Situation Graphics Fig. 15-51
The Level 1 Overview
Fig. 15-48 Example Level 1 Display
The Overview graphic shown in Fig. 15-48 (repeated from the Part 1 document) shows the key
performance indicators of the entire system under the operators control. The most important
parameters incorporate trends. It is easy to scan these at a glance and detect any non-normal
conditions. Status of major equipment is shown. Alarms are easily detected.
The operators found the overview display to be far more useful than the existing graphics in
providing overall situation awareness and also very useful in detecting burgeoning abnormal
situations.
The Level 1.5 Pulverizer Overview Graphic
The operator controls eight identical, heavily instrumented, and complex pieces of equipment
called coal pulverizers. At normal rates, seven are in use and one is on standby in case of a
problem. The seven that are running should be showing almost identical performance. It was
immediately apparent that an Overview graphic of just these eight items would be useful to the
operators, since much of their activity is in monitoring and manipulating them. Being
mechanical, they are subject to a variety of problems and abnormal conditions. There were three
separate existing graphics needed for monitoring and controlling each pulverizer, 24 in total for
them all. Monitoring using 24 graphics was difficult for the operators.
Fig. 15-49 The Level 1.5 Pulverizer Overview
The new Pulverizer Overview in Fig. 15-49 depicts more than 160 measurements on a single
graphic! The key to making this understandable is that the devices are supposed to run alike.
Instead of blocks of indicators for each pulverizer being grouped together, the same
measurement from each pulverizer is grouped together. Any individual unit operating differently
than the others stands out. The unit that is in standby service also is easily seen. Air damper
command vs. actual positions, a consistent source of problems, is clearly shown.
Note that the trends seemingly violate our recommendation of showing no more than three or
four traces on a single trend. In this case, what the operator is looking for is any trend line that is

not bunched in with the others. For such a condition, having these eight traces was acceptable.
Note that the standby pulverizers trace is normally on the bottom.
Even with such a dense information depiction and with so many measurements, the operators
found it easy to monitor all eight devices and easily detect burgeoning abnormal situations. It is
easy to scan your eye across the screen and spot any elements that are inconsistent (Pulverizer
B in the depiction). Alarm conditions are also easy to spot.
Note that control actions are not taken on this screen but rather on the eight individual Level 2
graphics, one for each pulverizer. This graphic is in-between Level 1 and 2, as it is an
overview of a complex sub-part of the operators responsibility. The most common sources or
problems are depicted.
The Level 2 Pulverizer Control Graphic
Fig. 15-50 Level 2 Pulverizer Control
Rather than using the three separate graphics shown to control each pulverizer (24 graphics
total), a single Level 2 graphic for each pulverizer was created with everything needed to
accomplish all typical control manipulations.
While complex in appearance to the layman, the trained operator had no difficulty in
understanding and accessing everything they needed for pulverizer startup, shutdown, and swap
situations that arose during the test. Much of the text on the screen has to do with the status of
existing semi-automated sequences that sometimes require operator intervention. Everything on
the screen is selectable, and when selected the standard faceplate for the element appears in a
reserved faceplate zone rather than floating around the screen obscuring the graphic. Element
manipulation is made via the faceplate.

Abnormal Situation Response Graphics
The operator response for many abnormal plant situations is to cut rates by half, from 700MW to
350MW. Called a Runback, this is a complicated and stressful procedure that takes about 20
minutes to accomplish. If done incorrectly or if important parameters are missed, the plant can
fall to zero output, a very undesirable situation. One of the main purposes of the simulator was to
periodically re-train the operators for this situation. The operators have to use more than a dozen
of the existing graphics to accomplish the task, involving a lot of navigation activity around
screen callups and dismissals along with control manipulation.
However, in more than a decade of such training, it had never occurred to anyone to design
special graphics specifically designed to assist in this task. This demonstrates the power of
inertia in dealing with our HMIs. Specific Abnormal Situation Detection and Response graphics
are an important element of an HPHMI.
PAS created two Runback graphics designed specifically to assist in this task. Every element
that the operator needed to monitor and control the runback situation effectively was included on
them. In use, the operators placed them on adjacent physical screens. Fig. 15-51 shows Runback
1; Runback 2 was similar. The reserved faceplate zone is on the lower right.
As a simple example of providing information rather than data, consider the trend graph at the
upper left of Runback 1. To be successful, the rate of power reduction must not be too slow or
too fast. The existing graphics had no trend of this, simply showing the current power megawatt
number. This new trend graph had the sloped-line element placed next to it, indicating the
ideal rate of power reduction, the full load zone, and the target half-rate zone. On the figure, the
actual rate of drop is initially exceeding the desired rate, and that condition is easily seen. (Note:
It would have been more desirable to have the sloped lines on the background of the trend area
itself, but the DCS could not accomplish such a depiction. This is a compromise, but one the
operators still found to be useful.)
Fig. 15-51
Abnormal Situation
Graphics Runback 1

The Testing
Eight Operators, averaging eight years of console operating experience each, were used in the
test. They received only one hour of training with the new graphics prior to the start of testing.
(This was to address the common objection of Changing our graphics would take months of
retraining!) They were tested on four increasingly complex situations, each lasting about 20
minutes.
Coal Pulverizer Swap Under Load

Pulverizer Trip and Load Reduction
Manual Load Drop with Malfunctions
Total Plant Load Runback
All operators did all scenarios twice, using the old graphics alone, and the HPHMI graphics. Half
used the old graphics first (without having been shown the new graphics), and half used the new
HPHMI graphics first.
Quantitative and qualitative measurements were made on the performance of each scenario (e.g.,
detection of the abnormal condition, time to respond, correct and successful response).
The Results
The High Performance graphics were significantly better in assisting the operator in:
Maintaining situational awareness.

Recognizing abnormal situations.
Recognizing equipment malfunctions.
Dealing with abnormal situations.
Embedding knowledge into the control system.
Operators highly rated the Overview screen, agreeing that it provided highly useful big picture
situation awareness. Even with only one hour of familiarization with the new graphics, operators
had no difficulties in operating the unit. The High Performance graphics are designed to have
intuitive depictions.
Very positive Operator comments were received on the analog depictions, alarm depictions, and
embedded trends. There were consistent positive comments on how obvious the HPHMI made
the various process situations. Values moving towards a unit trip were clearly shown and noticed
by the operators.
The operators commented that HPHMI would enable faster and more effective training of new
operations personnel. The negative operator comments generally had to do with lack of
familiarity with the graphics prior to the test (which was intentional).
The best summary quote was this one:
Once you got used to these new graphics, going back to the old ones would be hell.
The effect of inertia being the controlling factor for HMI change was once more confirmed. The
existing HMI had been in use since the early 1990s, with simulator training for more than a

decade. Despite clear deficiencies, almost no change to the existing HMI had been made since
inception.
Operators using the existing graphics first in the test were then asked What improvements
would you make to the existing graphics to help in these situations? In response, there were
very few or no suggestions!
However, operators using the existing graphics after they used the HPHMI graphics had many
suggestions for improvement, namely analog depictions, embedded trends, alarm depiction,
consistent navigation, etc.
So, people get used to what they have and do not complain or know what they are missing if
they are unfamiliar with these HPHMI concepts.
A lack of complaints does not indicate that you have a good HMI!
PowerGraphiX
After the publication of The High Performance HMI Handbook, Southern Company, a major
United States power generation and distribution company, took notice of it. Southern Company
operates more than 280 nuclear, coal, oil, gas, biomass, wind, solar, and hydro generating units at
more than 75 power plants, with a combined capacity of more than 45,000 megawatts. They are
well known for their forward thinking and engineering approach to problem solving.
Southern had traditionally designed graphics much like others have. This was either using the
perspective of an engineer looking at the P&IDs, or by delegating graphics creation to operators,
who tended to arrange screens of numbers suiting their individual preferences. Neither of those
approaches led to a consistent or satisfactory end product.
In 2009, Southern suspected that there had to be a better way to present information to their
operators. Significant problems were being found as new projects were each being treated as
custom HMI implementations. Existing control rooms had significant screen and graphic
proliferation with many plants having more than 500 different graphics used for control and
creating significant HMI maintenance problems.
An in-house study was made and identified these common deficiencies:
Few internal standards were in place.

Personal graphic preferences resulted in each control project being a custom,
inconsistent solution.
Large HMI inconsistencies existed between identical plants.
Significant retraining was required for personnel transfer.
The over-abundant use of color incorporated in their graphics was not an aid to the
operator.
Individually plant-customized graphics led to significant impacts to cost, schedule, and
consistency.
Southern concluded that the graphics portion of a controls project should be an engineered
solution, just like the rest of the project. After considerable research, they recognized that the
principles and design practices covered in The High Performance HMI Handbook dealt with all
the issues they identified and went beyond them. Managerial support of a major improvement
effort was obtained. A test case project was chosen, involving a DCS conversion for two coal-
fired generation units. HPHMI Workshops were held and workgroups formed. Corporate-wide
operations experts designed template Level 1 and 2 graphics based on task analysis. The screen
layout was driven by the Operators thought processes. The goal was total fleet standardization
of High Performance graphics.
Fig. 15-52 Original Control Room and How it Grew After DCS Conversion
The test project was successful and then further proven in 17 plant conversions with more
underway. Operator response is positive:
I can see problems coming before they happen.

You got it right.
I didnt like it at first, but I do now.
I wish I had this when I was learning to operate.
I can find what I need now.
I dont have to jump around between screens to operate.
Fig. 15-53 Control Room after HPHMI Implementation of PowerGraphiX
The number of graphics used to control a plant was reduced from a typical value of 300-600 to
approximately 80. Southern Company has documented both performance improvements and
substantial costs savings in these areas:
Improved operator situation awareness.

Improved abnormal situation detection and handling.
Reduced engineering time and cost for new plants, conversions, and modernizations.
Reduced hardware costs (fewer workstations).
Reduced licensing cost for control system software.
Reduced ongoing maintenance cost.
Reduced ongoing cybersecurity cost (fewer workstations and licenses).
Reduced training costs.
Upsets avoided (anecdotal evidence and cases).
Now designated as PowerGraphiX, these graphics represent thousands of hours of design,

improvement, and actual in-operation experience. The measurements and statuses shown on each
graphic have received highly detailed review and proof testing by experienced power industry
experts. The designs, layouts, and functionalities are the right choices for implementation of a
proper graphic hierarchy and HPHMI. They support maximum functionality for effective
operator monitoring and control.
The power generation industry is much more consistent in plant design than is the petrochemical
/chemical industry. This makes it possible for advancements such as PowerGraphiX to be
incorporated much more easily and inexpensively by other companies. Southern and PAS
realized that making PowerGraphiX available to the power industry would benefit overall
operational effectiveness as well as safety.
Paradigm Busting: The Pipeline Overview
This is an example of the kind of out-of-the-box thought process involved in re-examination of

some of our HMI paradigms. The pipeline industry (including the water and wastewater
segment) typically involves a process network of pipelines and processing facilities spread over
large geographical area.
Fig. 15-54 A Typical Pipeline Network Overview Display
That industry has the typical P&ID-covered-in-numbers approach to graphics involving the
facilities. They also have usually developed an Overview type of display. The paradigm for
that is as shown in Fig. 15-54, a map covered in numbers. By now, you should have guessed this!
Certainly some geographic detail is relevant to the role of the operator in this case. But is all of
this detail relevant or helpful? Or is it a distraction? Is a map covered in numbers any better than
a P&ID covered in numbers? The question is what would be better?
It is a great tradition in engineering to build on the work of others to adapt and enhance
concepts that are successful in other domains. The trick is to have a wide enough view of the
topic to recognize an applicable solution. It is to ask, Has anyone else solved a similar
problem? In this case, the answer is yes, and in a big way.
A map of the very complex 1908 London Underground subway system is shown in Fig. 15-55.
The user of this map is the subway rider. It is not that easy to interpret, for the purpose of
figuring out the best route from your current position to the destination, using which subway
lines, and changing at which stations. And there is time pressure you are looking at the map,
and the train has just pulled in next to you. Do you get on this one or the next one? Hurry!
It took about three decades for something better to be produced. In 1936, Engineer Harry Beck
came up with a radically different depiction. He determined these questions to be the key ones
for the subway rider:
Where am I now (what station)?

Where am I going (what station)?
What lines service this station and where do they go?
Where do I change trains?
How many stops until my destination?
Even more importantly, he realized that there were many things that the subway rider did not
need to know:
Am I going around a curve?

Am I passing under a river or near another train line?
What is the relative distance between stations?
Am I traveling in a specific direction (N,S,E,W) in between stations?
Beck realized that depicting topology, and not geography, was the key.
In the revised map, every line is horizontal, vertical, or at 45 degrees even the River Thames.
There is just enough geography and landmark depiction for the rider to orient their current
position and find their destination station. It is fast and easy to pick out an efficient route, even
for the novice rider.
Since 1936, the London Underground has continued to grow in complexity, but Becks Paradigm still
works. It has become an iconic image, so functional that it has been universally adopted.
How can this paradigm be adapted to a Level 1 Overview display for a pipeline network? There
are geographic cues important to a pipeline operator.
Fig. 15-56 Harry Becks 1936 London Underground Map
For example, the location of a station or spill relative to state lines can mean that different
regulations, reporting requirements, or emergency procedures apply.
Task analysis has shown these to be some important things for depiction:
Important status conditions and alarms.

Significant highway crossings.
Significant waterway crossings.
Neighborhoods if adjacent to pipeline.
Important boundaries (i.e., state lines).
Pressure profiles.
Analog indicators showing station performance.
Direction and content indicators.
Important trends.
Topology, not geography.
A conceptual Pipeline Overview Display with these elements is shown in Fig. 15-57.
Fig. 15-57 A Conceptual Pipeline Overview Display
HMI design is not simply arranging objects from a library onto a screen. There is room for a
creative approach, as long as the proper principles are reflected in the design. When faced with
an unusual process depiction problem, look at how similar situations have been solved in other
areas, and then adapt them.
A Review of HMI Standards
Many readers of this white paper will already have The High Performance HMI Handbook and
may be curious about other HMI-related documents. In this section, we review the API-1165
Recommended Practice and the ISA-101 HMI Standard released in August 2015.
We need to be precise in our language when discussing standards. In this section, the term
standard applies only to a document that is produced in documented accordance with a strict
methodology that involves balance of interests, consensus, and a stringent review and
documentation process. Recognized bodies like the ISA follow these principles in issuing
documents they call standards. Other organizations (e.g., EEMUA) do not, and the documents
they produce are essentially books and reports, not standards.
When standards are issued by a recognized body, they acquire the status of being a recognized
and generally accepted good engineering practice (RAGAGEP). This clumsy acronym denotes
something very important, because regulatory agencies can and will cite the principle of
RAGAGEP as being enforceable, as a catch-all.

Standards are highly restricted in their allowable content. Standards intentionally describe the
minimum acceptable and not the optimum. By design, they focus on the what to do rather than the
how to do it. Standards intentionally do not have detailed or specific how-to guidance the kind
of guidance that most people actually want or need, but that we do not want to be mandatory.
Standards do not contain examples of specific proven methodologies or detailed work practices.
Other than The High Performance HMI Handbook, and this much expanded white paper, there
are very few authoritative documents that address process control HMI. Here is a discussion of
two of them.
API-1165: Recommended Practice for Pipeline SCADA Displays
API documents are often considered as RAGAGEP by their regulatory agency, PHMSA
(Pipeline and Hazardous Materials Safety Administration). In 2006, API issued a document on
SCADA HMI displays. There are some significant inconsistencies within that document.
Overall, the concepts incorporated in the text portion of the document are valid. It mentions
several good practices. The examples provided, however, contain several depictions that are in direct
violation of the principles in the text.
For example, Section 8.2.4 states, Color should not be the only indication for information. That
is, pertinent information should also be available from some other cue in addition to color such
as a symbol or piece of text.
Fig. 15-58
Sub-optimal Examples from API-RP-1165

Yet throughout the remainder of the document, examples are shown that routinely violate this
principle. Fig. 15-57 shows only a few of the recommended practice examples from API-RP-
1165. In many of these examples, only subtle color differences, not distinguishable by a
substantial fraction of the operator population, are the only means to distinguish a significant
status difference.
In one table, API-1165 recommends color coding alarms by type. The well-known best practice
is that they are redundantly coded by priority, not type.
Users of API-1165 are therefore advised to pay more attention to the written principles it
contains than to the example depictions.
ISA-101 Human Machine Interfaces for Process Automation Systems
ISA-101 (officially ANSI/ISA-101.01-2015) was begun in October 2008, very close to the time
that the first edition of The High Performance HMI Handbook was published. PAS is a voting
member of the ISA-101 committee. In June 2014, a final draft of ISA-101 was sent out to the
overall committee for final comment and ballot. The draft was approved by vote but 1,163
comments were returned and had to be resolved. In March 2015, the version reflecting those
modifications was sent out for a revote, which passed and the document was released in August
2015. Understand that the ISA document is much more about the work process of creating and
operating an HMI and not the details of what makes for a good vs. poor HMI. Those that are
looking for such detail will be disappointed.
The ISA-101 document is relatively short, containing approximately 44 pages of content and
approximately 20 pages of introduction, definitions, and legal notice.
ISA-101 contains consistent definitions of various aspects of an HMI. It has the typical text
principles of good graphics design, but these are constrained by what is allowable in a standard.
Standards are to provide the minimum acceptable, not the optimum. For example, ISA-101 can
make a statement like Color should be used to direct attention and add meaning to the display.
But ISA-101 does not contain anything like the example color palette of Fig. 15-58 in this paper
(Part 1), nor should it. Such detail is not within the purview of a standard.
ISA-101 follows the usual Life Cycle approach of other ISA Standards. Life Cycle is a document
structure, not a project plan. An example of a Life Cycle for HMI development and operation is
supplied. It is mandatory to use some sort of life cycle process to administer an HMI. But the life
cycle shown in the document is labeled as an example and is not mandatory.
ISA-101 also makes it mandatory to place changes in the HMI under Management of Change
(MOC) procedures, similar to those that govern other changes in the plant and the control
system. The details of the MOC procedures are left to the user.
A reader with only brief and rudimentary knowledge of control systems and process control HMI
will find nothing new or unusual in ISA-101.
ISA-101 makes it mandatory to create System Standards. These are documents that govern the
design and creation of the HMI. These are the familiar HMI Philosophy, Style Guide, and
Toolkit (Object Library). It is mandatory to apply MOC to the Toolkit. ISA-101 has discussion
of ways to create these documents, but there are no examples. Brief descriptions of the contents
of such documents are provided (See the end of this white paper for a detailed Table of Contents
listing of a comprehensive HMI Philosophy and Style Guide). It is noted that the primary user of
the HMI is the operator and design should keep that in mind. There is a small bit of guidance
about the use of scripting logic and color.
There is a brief section on the determination of the tasks that a user will accomplish when using
the HMI and how those feed the HMI design process.
The activities listed in the ISA-101 life cycle are generally discussed in bullet list and table form.
It contains basic (and well known) recommendations such as these:
The HMI should be consistent and intuitive.

The information shown should be relevant to the operator.
Color should not be the only indicator of an important condition.
Colors chosen should be distinguishable by the operators.
Auditory warnings should be clear and unambiguous.
There are no examples of proper and improper human factors design and no details such as
appropriate color palettes or elements. The only HMI examples in ISA-101 are in a survey-type
section providing a list of different types of display styles. Each style is accompanied by a small,
intentionally non-detailed example, typically of about one square inch in size. Fig. 15-59 shows a
few of those examples in their actual sizes.
Fig. 15-59 ISA-101 Example Images, Full Size
ISA-101 mentions the concept of display hierarchy with discussion of Level 1, 2, 3, and 4
displays. Each has an example, and those have been made intentionally undetailed and
simplified. The descriptions of the different levels contain no unusual items. Here, for example,
are the ISA-101 Level 1, 2, and 3 display examples.

Fig. 15-60 ISA-101 Example Level 1 Graphic
ISA-101 finishes by providing brief descriptions of the following methods for interacting with an
HMI.
Data entry in fields.

Entering and showing numbers.
Entering and showing text.
Entering commands.
Designing buttons.
Using faceplates.
Navigation various common methods for navigating from one graphic to another are
discussed, such as hierarchical menus and navigation buttons.
User access and security are briefly mentioned.
In ISA-101, user training in use of the HMI is mandatory. There is brief discussion of a list of
things that the training should cover, such as interpreting screen symbols, manipulating the
controls, and navigating from screen to screen. If non-operators are also expected to use the
HMI, they are expected to be trained as well.

In summary, the publication of ISA-101 is an important step in the field of HMI. ISA-101 is a
short document containing some generally well-known and basic principles of HMI design. Its
only mandatory requirements are to have an HMI Philosophy, Style Guide, and Object Library,
to apply MOC to the HMI, and to provide for user training. ISA-101 contains no detailed examples
and does not provide detailed design guidance. For those, the reader will need to seek other sources
of expertise. ISA plans to create additional Technical Reports on ISA-101, but these typically take
from two to six years to publish

The PAS Seven Step HPHMI Work Process
There is a seven step methodology for the development of an HPHMI with more detail in The
High Performance HMI Handbook.
Step 1: Adopt a High Performance HMI philosophy, Style Guide, and Object Library. You must
have a written set of principles detailing the proper way to construct and implement a High
Performance HMI.
Step 2: Assess and benchmark existing graphics against the HPHMI philosophy. It is necessary
to know your starting point and have a gap analysis.
Step 3: Determine specific performance and goal objectives for the control of the operation and
for all modes of operation. These are such factors as:
Safety parameters/limits.
Production rate.
Run length.
Efficiency.
Equipment health.
Environmental (i.e., emission control).
Production cost.
Quality.
Reliability.
It is important to document these along with their goals and targets. This is rarely done and is
one reason for the current poor state of most HMIs.
Step 4: Perform task analysis to determine the control monitoring and manipulations needed to
achieve the performance and goal objectives. This is a simple step involving the determination of
which specific controls and measurements are used to accomplish the operations goal
objectives. The answer determines the content of each Level 2, 3, and 4 graphic.
Step 5: Design High Performance graphics using the design principles in the HMI philosophy
and elements from the style guide and object library to address the identified tasks.
Step 6: Install, commission, and provide training on the new HMI.
Step 7: Control, maintain, and periodically reassess the HMI performance.
HPHMI Implementation on a Budget
While desirable, it is not necessary to replace all (or any) of your existing graphics to obtain
much of the benefit of HPHMI. A partial implementation can provide most of the benefits with
minimum disruption. A partial implementation involves:
ALL EXISTING GRAPHICS ARE KEPT ON THE SYSTEM. This eliminates almost
all objections to HMI improvement.
Design and deploy new Level 1, Level 2, and Abnormal Situation Management
graphics designed with HPHMI principles. This is generally around 20 or so graphics.
Existing graphics can be designated as Level 3 (which is generally what they actually

are) and navigation paths to them altered.
Improvements to those existing Level 3s (correcting color choices, adding status
indications, adding embedded trends, and providing proper context) can be made over
time as desired. Yes, there will be inconsistency between the HPHMI graphics and the
existing ones. But in examining hundreds of existing HMIs, we have yet to find one
that did not already have significant inconsistencies within itself. Operators can handle
this with no problem.
Experience has shown that the operators will begin to use the High Performance Level 2
graphics preferentially for normal operation and abnormal situation detection. Why? Because
they are BETTER for the purpose. They will use the existing Level 3 graphics for the detailed
troubleshooting purposes that they are most suited to support.
Any facility can afford about twenty new graphics! A High Performance HMI is affordable.
Conclusion
The most important job of an operator is to detect and successfully respond to an abnormal
situation. The HMI is the means by which the operator accomplishes this task. Existing HMIs are
woefully inadequate for this purpose. They were generally designed in an era when proper
practices were unknown, and the resistance to change has kept those graphics in commission for
two or more decades.
The principles of High Performance HMI are specifically developed to deal with the needs of
todays operators and the complex systems they manage. A High Performance HMI is designed
to be the best tool for operator interaction with the process control system. It is designed with
these important capabilities in mind:
Provision of an easily monitored overview of the equipment under the operators

control.
Ease in maintaining full situation awareness of the span of a large process.
Early detection and clear depiction of abnormal conditions.
Effective resolution methods for abnormal situations.
Embedding easily accessible and relevant knowledge into the control system.
The benefits of such an HMI are more than just reducing human error and avoiding abnormal
and unsafe operations. The HMI becomes an effective operational tool for maximizing
production, reliability, efficiency, quality, and profitability.
Industry is now recognizing the need and benefits of improved HMIs. Dozens of major
companies are in the process of HMI modernization and see it as not only a safety initiative, but
a cost-saving and productivity-enhancing one as well.
The functionality and effectiveness of our process automation systems can be greatly enhanced if
redesigned in accordance with proper HMI principles. A High Performance HMI is both
practical and achievable.

Hardware to Complement the Software
The following is a listing of one of the hardware vendors, Siemens, which provides a complete
offering of hardware operator interface units to complement the software designs discussed
above.
Fig. 15-63 Siemens HMI



The RSView ME Stand-Alone Application
RSView ME is one of a number of software programs furnished to collect and display

information from the factory floor, first to the operator and then to the business itself.
To open RSView Studio and gain access to RSView ME, open the program and click on the New
tab. For Application name, the following example program used test.
Fig. 15-69 RSView ME Project Name
The A-B product uses RSLinx Enterprise. This means that RSLinx Enterprise has the ability to
allow this software package to browse directly for the tag database and link existing tags and not
requiring a tag created in the HMI to complement the tag in the PLC.
When starting a new application, select Objects from the main menu. Notice the types of objects
selectable. Under each selection are sub-menu selections. In the case of Push Buttons, the four
sub-menu selections are:
Momentary
Maintained
Latched
Multistate
etc
The pushbutton is a good example of a type of object that can be used for a number of different
operations. For example, momentary is the most used button with an exact simulation of a real
button in which the operator pushes the button and a 1 appears in the data address of the
device. When the button is released, the button returns to a 0. As simple as this is, it is a very
profound device in that the device continues to write a 1 to the data tag until the device de-
activates and the device writes a 0. Other button types have various other characteristics and
these characteristics allow the programmer flexibility in programming of the various functions
surrounding the logic of the pushbutton. More will be discussed later regarding some of the
button types.
Remember that input and output bits used for a HMI are tags with internal addresses, not hard-
wired inputs or outputs. For A-B, the device should have a tag referring to an internal location.
For Siemens, the address should have an M prefix.
RSView Machine Edition (ME) is designed

for the machine-level HMI and supports
operator interface solutions for the
monitoring and controlling of individual
machines or for small processes.
The system tree at left shows the graphical

application and is organized by area. These
include:
System
HMI Tags
Graphics
Alarms
Information
Logic and Control
Data Log
RecipePlus
For the simple assignments of this text, the

user can simply add a display and create the
appropriate graphics on the form. To test or
run the form requires a link to a PLC. The
procedure for linking to a PLC is included
next. The tags created for the PLC are used
in the graphic and any button or indicator
will reference the PLC tag.
Fig. 15-70 RSView Project Tree
Fig. 15-2 RSView ME Project Tree

RSView ME uses RSLinx Enterprise instead
of RSLinx Classic. To configure RSLinx
Enterprise, using the Communications setup
tab, double click and choose to Create a new
configuration. We will use Ethernet/IP for
our applications.
Fig. 15-71
RSView ME Communications Setup
The Communications Setup screen has two tabs, Target and Local. For the labs of this course,
only use the Local tab. This tab will provide a simulation mode of the graphic on the computer
screen similar to the screen an operator would use on a target system. Usually, target systems
are hardened touch screen computers found on the factory floor. We will not be using them
although there are a couple target systems in the lab. The Target tab refers to the path of
processor of the RUNTIME application.
The Local tab refers to the path of the processor under the DEVELOPMENT mode and is only
found on the computer running RSView Studio. An Offline Tag File allows the programmer to
browse tags located in an ACD file. In the development mode, the application can be tried out in
a manner similar to the operation found online. Using Offline Tag File requires that a LOCAL
path be created. Then the development system can browse for tags and use the tags of a PLC to
animate an object on the screen of the development system. Directions for connecting to the
LOCAL tab include:
Click on the LOCAL tab

Right Click on Ethernet/IP
Right click on RSLinx Enterprise, (Computer Name), click Add Driver,
Click Ethernet/IP, then OK
Click Start Browsing
Under the Device Shortcuts window, click Add
Change the name of the Shortcut (if desired)
Click on the processor
Click Apply
The LOCAL path is now created.

In order to tie a button to a PLC tag,
do the following:
Click and hold the mouse button on

the Display screen.
Drag a box to create a button.
Double click on the button.
To change the assigned tag, click on
the Connections tab.
In the Value row, click on the ellipsis

(...) under Tag
Right click on the top selection in the
Tag Explorer which bears the name
of the application, in this case Test.
Click Refresh All Folders - this step is

necessary any time a change is made
in the Communication Setup.
Fig. 15-72 Adding an Object
Click Refresh All Folders - this step is

necessary any time a change is made
in the Communication Setup.
If this procedure works (and it may

not work the first time), do the
procedure again.
When it works, the tags from the

program will appear and you may tie
the tag to a button or other object to be
animated.
Fig. 15-73 Tying a Tag to an Object

Fig. 15-74 Tying a Tag to an Object (cont)
You may run the application screen by simply toggling the triangle button at the top of the page.
This runs the screen but does not run the entire application. To run the application (multiple
pages), run the little man
Figure 15-75 below shows an example page generated by RSView Studio. This page may be
used to generate a sequence of events that a program would sequence through step-by-step.
Fig. 15-75 Sample Page in RSView
The following screens create a button. Click and hold the mouse button on the Display screen.
Drag a box to create a button. Double click on the button.

Fig. 15-76 A Button Object Tied to PLC Tag
To change the assigned tag, click on the Connections tab. Click on the ellipsis (...) under Tag.
Right click on the top selection in the Tag Explorer which bears the name of the application, in
this case Test. Click Refresh All Folders - this step is necessary any time a change is made in the
Communication Setup. Click on the tag to be tied to the button. If the button is from the SLC
5/03, the bit must be added to the B3 tag. For instance if the bit is B3:1/1, the /1 must be added
to the tag B3:1. The animation folder allows a number of other functions with an object. See the
various tabs for animating an element below:
Fig. 15-77 Various Animation Configurations
To activate the Factory Talk RSLinx Enterprise, you must first configure Factory Talk per the
following:

Fig. 15-78 Activation of
Factory Talk RSLinx Enterprise
Then, configure the local directory per administration sign-in configuration of your pc.
Fig. 15-79 Administrative Signin User Name/Password
After this configeration is complete, you may proceed with your HMI application and connect
the HMI screens to a PLC via RSView Enterprise as described above.
Creation of tags is accomplished either in the program tag or controller tag areas. Either may be
accessed by FactoryTalk. The type of tag must be considered since numeric tags must be scaled
and configured for proper display. Boolean tags must also be configured properly.

Fig. 15-80 Various Program
Tags for Use with the HMI
Tags may be monitored in the monitor mode. Editing of tags is done in the edit mode:
Fig. 15-81 Tag Types in

RSLogix 5000
An Example RSView Display
The suspension bridge at Niagara Falls was started by flying a kite with a string attached across
the Niagara River. When wind conditions were favorable, the kite was flown across the river.
Then a string was attached to the thread and a bridge was the eventual result. Likewise,
programs in this chapter can be started with small threads and then expanded. It is best to get a
simple device such as a button programmed and fully working and then adding the rest of the
project after the button has been proved to thoroughly work in all modes.
The following is an example much like that in Ch. 7 for the Siemens HMI. The example shows
the first use of A-Bs RSView linking a simple button to the PLC. This is much like the kite
example for the bridge at Niagara Falls. If the process is completed for one element
successfully, the remaining portions of the HMI may be more confidently programmed with
success.
The project is begun with the following screen present. The project name is test1.

Fig. 15-82 First Screen with RSView Studio
Fig. 15-83 Selecting the Main Display

Fig. 15-84 Building a Momentary Push Button
Fig. 15-85 Establishing Communication with RSLinx Enterprise

Fig. 15-86 After Selecting Communication Setup under RSLinx Enterprise
Fig. 15-87 Click Add for Device Shortcut, Enter Name test1

Fig. 15-88 Highlight the Ethernet Device PLC
When APPLY IS HIGHLIGHTED - CLICK IT
Fig. 15-89 The Local Path is Determined for the Application

Fig. 15-90 The Local Path is set with OK
Fig. 15-91 Back at the Ranch (I mean Button)

Fig. 15-92 Working with the
Button Tab 1 - General
Fig. 15-93 Establishing the

PLC Connection to the Button

Fig. 15-94 Click Tag and
the Link to the PLC test1 is
Displayed
Fig. 15-95 Choose

Refresh All Folders

Fig. 15-96
PLC Tags are Shown in
the Online Tags
Fig. 15-97
The Tag shows the
Tag/Expression with the PLC Tag

Fig. 15-98
Color and Captions Modified
under States Tab
Fig. 15-99
The Common Tab Controls
Size, Position and Name of
the Button
It is time to try the button with the connection to the PLC. Run the display by choosing the
triangle in the command line. Test the screen with the button in the off and on position. View
the bit in the PLC online program.
Use the triangle for testing single screens. To run all

screens together in local mode, run the little man. There
may be problems with this operation as it invokes a
program called KEP that may interfere with other
applications. Be careful when running the little man.
While building a screen or series of screens requires more instruction, we leave the A-B software
to discuss Siemens HMI interface.
Siemens Win CC
From a white paper featuring Siemens new TIA Portal design, the concept of design of tags is
used:
TIA Portal Integrates Engineering Tools
Siemens AG, one of the worlds leading industrial companies, subscribes to the philosophy of
Totally Integrated Automation (TIA). This concept ensures users that automation equipment
from the companys vast portfolio of hardware and software will be compatible and therefore
easy to integrate, helping customers lower their engineering costs. Now, Siemens is extending
the concept of total integration to its automation software.
The first step of Siemens initiative is the release of the TIA Portal, an engineering framework
that integrates multiple automation application in a single environment. TIA Portal is a new,
intuitive development environment that integrates existing engineering tools with which
automation users are already familiar. The first release of TIA Portal brings together the familiar
STEP 7 tool for programming and configuring SIMATIC controllers. Integrated into this
environment is WinCC, the configuration tool for setting up Siemens extensive family of
operator panels. Finally, drives can set up and parameterized in the same framework with
StartDrive, a configuration tool for SINAMIC AC drives.
Common Tags
The most obvious advantage of using TIA Portal is the universal accessibility of data tags. Tags
created in any tool for any device are automatically and immediately accessible to other devices.
If, for example, a user creates a new tag in the PLC to measure temperature, that tag is
automatically created in the operator panel at the same time. This saves valuable engineering
time compared to conventional methods that require the tag to be created in each device. Should
the user wish to modify that tags proper-ties, he or she can change parameters from whichever
tool is currently being used just by changing the view. In any case, the data is universally
accessible.
For handling large amounts of data, the Portal makes it easy to create large data blocks and
supports incremental naming of tags. Tag properties can be copied or changed easily for multiple
objects simultaneously, and newly created data can be dropped directly into the configurations
of other controllers or panels. The Portal ensures that the proper HMI variable, tag name, or IO
field is created in the target object and creates a connection between the devices if one doesnt
already exist.
The above description of the new software from Siemens may be an advertisement for the
product but is a view that details the movement of software for ease of implementation. All
software must move to this concept or an equivalent of this system. The student or engineer
must be able to quickly solve the difficult problems of creation of logic and graphical interface
and test the implemented system prior to launch in a factory.
Hardware
It is possible to add a new device in either Portal view or in Project view. Add a PLC device
(CPU) or an HMI device in the "Devices & Networks" portal. If required, one can insert
additional modules or network the devices, requiring the Project view.
An Example: Conveyor Control with Counter and Multi-Instance
For our process visualization with WINCC flexible, a counter and a multi-instance counter are to
be added to the example of a conveyor control.
With the conveyor, 20 bottles respectively are always to be transported into a case. When the
case is full, the conveyor is stopped, and the case has to be exchanged.
With button 'S1', the operating mode Manual is to be selected and with button 'S2' the operating
mode Automatic. In the Manual mode, the motor is switched on as long as button S3 is
activated, whereby button S4 must not be operated. In the Automatic mode, the conveyor
motor is switched on with button 'S3', and with button 'S4' (NC), the conveyor motor is switched
off. There is also a sensor B0 that counts the bottles into a case. When 20 bottles are counted, the
conveyor stops.
When a new case is provided, it has to be confirmed with button S5.
Assignment list
Address Symbol Comment
%I 0.0 S1 Button manual mode S1 NO

%I 0.1 S2 Button automatic mode S2 NO
%I 0.2 S3 On-button S3 NO
%I 0.3 S4 Off-button S4 NC
%I 0.6 S5 Button S5 NO Reset counter/new case
%I 0.7 B0 Sensor B0 NO bottle counter
%Q 0.2 M01 Conveyor motor M01
Task
The conveyor control is to be operated and monitored using the panel.

With the aid of the panel, the following requirements are to be met:
The operating mode is switched using the panel, and the respective operating mode is
to be displayed on the panel.
The conveyor motor is started and stopped from the panel.
The case exchange is confirmed on the panel.
The transport of the bottles and the filling of the case is to be represented graphically.
Configuration
Under the configuration software STEP7 Basic, process visualization for the conveyor control is
generated using the integrated WinCC flexible version. The process values are represented with
screens and screen objects. Default values can be transferred to the control system using operator
elements. Communication between the operator panel and the machine or the process takes place
by means variables via the control system. The value of a variable is written into a memory area
(address) in the control system where it is read out by the operator panel.
The process visualization is saved and loaded into the panel KPT600 Basic color PN.
After the panel is powered up, the conveyor control can be monitored and operated.
Inserting Panel KPT600 PN into the Project of the Conveyor Control
Project management and programming is carried out with the software Totally Integrated
Automation Portal.
Here, under a uniform interface, components such as the control system, visualization, and
networking of the automation solution are set up, parameterized, and programmed. Online tools
are available for error diagnosis. In the following steps, we are opening a project for the
SIMATIC S7-1200, storing it under a different name, and adapting it to the new requirements.
1. The central tool is the Totally Integrated Automation Portal, which we call here with a double
click.
2. Next, the project FB_Conveyor_Counter is opened in the portal view as a pattern for this
program.
3. Now, First steps are suggested for the configuration. We Open the project view.
4. Now, first we save the project under another name.
5. Save the project under the new name ConveyorControl_KPT600.
Fig. 15-100
Saving the
Project
Fig. 15-101
Saving the
Project (cont)

6. To set up a new panel in the project, open the selection window by double clicking on
Add new device.
Under SIMATIC HMI, select the 6 display panel KPT600 PN. Place a check mark at Start
device wizard. Then click OK.
Fig. 15-102
Select an
HMI Panel
7. First, under PLC connections, select Control conveyor.
Fig. 15-103
Connecting the
HMI to the PLC

Fig. 15-104
Connecting the
HMI to the PLC
(cont)
Then click on Next.
8. Under Screen layout, change the background color to White and remove the check mark at
Page header.
Fig. 15-105
Screen Layout
Then click on Next.
9. Remove all check marks at Alarms.

Fig. 15-106
Screen Layout
Then click on Next.
10. Under Screen navigation we could set up a screen menu structure.

For our example, the screen with the name Root screen is initially sufficient.
Fig. 15-107
Defining a
Root Screen
Then click on Next.

11. As system screens, select the switch-over Operating modes and Stop Runtime.
Fig. 15-108
Defining a System
of Screens
Then click on Next.
Finally, predefined system buttons can be added. Remove all check marks.
Fig. 15-109
Finishing the
Wizard
Then click on Finish.
13. The WinCC flexible interface is opened with the root screen.

WinCC flexible Interface
Project navigation Menu bar and buttons Work area Tools
Detail view
Fig. 15-110 Properties window
The WinCC
Interface
Project Navigation
The project navigation window is the central control point for project processing. All constituent
parts and all available editors of a project are displayed in the project window in a tree structure,
and can be opened from there.

Each editor is assigned a symbol with which you can identify the associated objects. Only those
elements are displayed in the project window that the selected operator panel supports. In the
project window, the device settings of the operator panel can be accessed.
Fig. 15-111
Project Tree
for WinCC
Menu Bar and Buttons
All functions that you need to configure your operator panel are located in the menus and symbol
bars. If a corresponding editor is active, editor specific menu commands and symbol bars are
displayed.
Pointing with the mouse pointer to a command provides a corresponding QuickInfo for each
function.
Fig. 15-112 Menu Bar

Work Area
In the work area we edit the objects of the project. All elements of WinCC flexible are arranged
around the work area. In the work area, we edit the project data either in the form of tables (for
example, variables), or graphically (for example, a process display). The upper part of the work
area contains a symbol bar. Here, the font, the font color or functions such as Rotate, Align, etc.
can be selected.
Fig. 15-113 The Root Screen
Tools
The tool window provides a selection of objects that you can insert in your screens; for example,
graphic objects and operating elements. In addition, the tool window contains libraries with
assembled library objects and collections of picture blocks. The objects are dragged and dropped
into the work area.
Properties Window
The properties of objects are edited in the properties window; for example, the color of screen
objects. The properties window is available only in certain editors. The properties of the
selected object are displayed in the properties window, arranged according to categories. Value
changes become effective as soon as an entry field is exited. If you are entering an invalid value,
it is color-enhanced.
By using QuickInfo, information is provided about the valid value range, for example. In the
properties window, animations and events of the selected object are configured also; here, for
example, a screen change when releasing the button.

Fig. 15-114 Dealing with Object Properties
Details View
In the Details view, additional details about the object highlighted in project navigation are
displayed.
Fig. 15-115
Details of
the Object
Operating Screens and Connections
A screen can consist of static and dynamic components. Static components, such as text and
graphs, are not updated by the control system. Dynamic components are connected to the
control system and visualize current values from the control systems memory. Visualization
can be in the form of alphanumerical displays, curves and bars. Inputs at the operator panel that
are written to the memory of the control system are also dynamic components. They are
interfaced with the control system by means of variables. Initially, we are only generating a
screen for our conveyor control.
Root Screen or Start Screen
This screen was set up automatically and defined as start screen. Here, the entire plant is
represented. Buttons can be used to do the following: switching the operating mode between

automatic and manual; starting and stopping the conveyor motor, and exchanging the box. The
movement of the bottle on the conveyor belt and the fill level of the box are represented
graphically.
Using button F6, we are jumping to the system screen:
Fig. 15-116
The System Screen
Connections to S7 Control Systems
In the case of operator objects and display objects that access the process values of a control
system, a connection to the control system has to be configured first. Here we specify how the
panel communicates with the control system, and with which interface.
In Project navigation, click on Connections. Because of the settings in the hardware

configuration, all parameters are already set.
Fig. 15-117
Establishing
the PLC
Connection
The IP address has to be assigned to the panel also. By means of Accessible devices, read out the
panels MAC address, or read it on the back of the panel.

Fig. 15-118
Assigning the
IP Address
Assigning the IP Address
After inputting the MAC address, the IP address can be assigned under Online & diagnostics. The
panel has to be in the Transfer Mode in this case.
Fig. 15-119
Assigning the
IP Address
Note
The IP address can also be checked or entered on the panel in the system control under Control
Panel at Profinet.
Configuring the Root Screen
Clicking on the button System screens displays the system screen. We want to transfer the
function of the button System screens to the function key F6.

Select System screens and in the Properties window below copy the function Activate screen at
Events Release.
Fig. 15-120
A Start-Up or
System Screen
Function Key F6
Select function key F6 and in the Properties window below, insert the function Activate screen at
Events Release key. Then, delete the text field in the center, and delete or remove the button
System screens.
Fig. 15-121 Defining a Function Key
The yellow corner on the F6 key indicates that the key is configured.

Configuring the Buttons Automatic and Manual
Drag a button into the work area of the root screen.
Fig. 15-122 Configuring a Button
At Label, enter Automatic.

Caution! Dont press the input key; otherwise, a second line is generated.
Fig. 15-123 Adding a Label
Under Layout, enter position and size.
Fig. 15-124 Modifying a Labels Size

Under Events Press select the function SetBitWhileKeyPressed under Edit bits.
Fig. 15-125 Select the Buttons Function
Then, click on the field Tags (input/output) and using button, open the tag window. Here, it
is also possible to access the interface declaration of data blocks. As tag, select auto from the
Conveyor_DB [DB1].
Fig. 15-126 Tie the Button to a Tag

in the PLC or HMI
Now, the button is to flash in the automatic mode, and change color. With a double click, select
under Animations\New animation Appearance.
Fig. 15-127 Use of Animate Feature

As tag, select automan of Conveyor_DB [DB1].
The button is to change color in the automatic mode; that means, when the variable automan has
the value 1. For the color change to become visible, change the foreground color at Appearance
to White and the background color to Green. At Flashing, say Yes.
Fig. 15-128 Change Color of Button
Copy and paste the button Automatic. Place the inserted button under the Automatic button.
At Label, enter Manual. Caution! Dont press the input key; otherwise, a second line is
generated.
Fig. 15-129 HMI Tag
Under Events Press, select man from Conveyor_DB [DB1] as tag. The variable has to be selected,
because only then will the new HMI tag be generated.

Fig. 15-130
More Example
HMI Tags
The button is to change color in the manual mode; that means when the variable automan has the
value 0. For the color change to become visible, change the foreground color at Appearance to
White and the background color to Blue. Set Flashing to No.
Fig. 15-131 Button Appearance
Now save your project.
Changes in the Step7 Program
Before we test the visualization, we have to make a change in the Step7 program.
From OB1, remove the assignment S1 and S2 when calling FB1. This is necessary because
otherwise, the panel signals are overwritten by the process image of the inputs. Save and load
the modified program.

Fig. 15-132
Conveyor
Program in
the PLC
Setting the PG/PC Interface for Runtime Simulation
In order to establish a connection between runtime simulation at the PG/PC and theS7-1200
CPU, first we have to set the PG/PC interface to TCP/IP.
No. How its done

1 Open the system control
with "Start > System control"
(start menu for the simplified access to the programs under Windows XP)
or with "Start > Settings > System control"
(for the classical start menu as in earlier Windows versions).
2 Now double click on the icon

Fig. 15-133
"Set PG/PC interface" Running the
Simulator
3 In the tab "Access Path", set the following parameters:

1. For the access point of the application, select from the drop down menu
"S7ONLINE [STEP 7]".
2. In the list of Interface Parameter Assignment Used, highlight the
interface "TCP/IP(Auto) -> with your network card that is connected directly to
the panel and the control system; for example, Intel(R) PRO/100 VE.
3. Then click OK and confirm the message that follows with OK also.
Fig. 15-134
Running the
Simulator
Starting the Configuration in Runtime
Click on the button Start runtime.
Fig. 15-135
Visualization is opened in the RT simulator.
Fig. 15-136 Running the Simulator

Test the project of the conveyor control.
The automatic or manual mode is now pre-selected on the panel.
Fig. 15-137
Downloading the Configuration to the Panel and Testing It
Click on the button Download to device.
Fig. 15-138
Fig. 15-139 Download to HMI Panel
Then click the button Load.

Fig. 15-140
If the operating system on the panel should not be current, an additional window is displayed to
update the operating system.
Also, test the function key F6.
Start and Stop Buttons
Next, we configure the start and stop buttons.

The Start button is created exactly like the automatic and manual buttons.
The Stop button has a break contact function and has to remove the signal when operated.
- Create the Start button

- Set the background color to Green
- Under Events Press, select under bit editing the function SetBitWhileKeyPressed.
- Then select the tag on in Conveyor_DB [DB1].

Fig. 15-141 Configuring the Start Button
Next, do the following: Create the Stop button. Set the background color to Red.
Under Events, at Press, select under Bit editing the function ResetBit and at Release the function
SetBit with the tag off in Conveyor_DB [DB1].

Fig. 15-142 Screen with Start and Stop Buttons

Allen-Bradley Button Configuration
The choice of button type indicates the type of function desired. There is no need to program
both press and reset but rather only type and the function is performed.
Fig. 15-143 Choice of Button Type Determines Function
Fig. 15-144 Connections Tab on Push Button Function
The tag or expression may be programmed for the value as well as for an indicator. The
indicator actually is a second button with the state desiring to be displayed. This value may be
the same address as the value entry or a second address. To perform a similar function, Siemens
may require two buttons overlaying each other.

Before we test the visualization, first another change has to be made in the Step7 program
In OB1, remove the assignment S3 and S4 when calling FB1.
Save and load the modified program.
Fig. 15-145
Load the configuration to the panel, and test the Start and Stop buttons.
Fig. 15-146

Inserting Graphics from the Graphics Folder
In the tool box under Graphics, open the directory tree WinCC graphics folder\SymbolFactory
256Colors\Conveyors, Misc.
Drag and drop the graphic of the conveyor belt to the root screen.
Fig. 15-147
Fig. 15-148

In the tool box under Graphics, open the directory tree WinCC Graphic folder\SymbolFactory 256
Colors\Food.
Then drag and drop the picture of the beer bottle in the root screen.
Change the size and the position of the bottle.
Fig. 15-149
Fig. 15-150
Note
All screen objects have to be within the work area (320x240 pixels).

Control Program for Simulating the Bottle Movement
To simulate the bottle movement and the bottle sensor, we create a new block. The FB2
(simulation) below with tag declaration and networks consists of a counter that, through a start
signal, always counts up from 0 to 50.
In Network 1, the CTU (count upward) is inserted as multi-instance.

In Network 2, a bottle sensor pulse signal is read out when the count 50 is reached.
This simulates when a bottle leaves the conveyor.
Fig. 15-151

Activate the Clock Memory and Assign MB100
An internal CPU clock memory bit is used as clock generator. Activate the clock memory bits
and assign MB100 as address.
Fig. 15-152

Calling FB2 (Simulation) in OB1
Before calling FB1 (conveyor), insert a new network. Call the simulation block (FB2) before
the conveyor block (FB1). Set up the Temp tag bottle and wire the blocks. Then save the project
and load it to the control.
Fig. 15-153

Configuring the Bottle Movement
Highlight the bottle and select under the tab Properties at Animations - Horizontal movement
(double click).
Fig. 15-154

As variable, select COUNT_VALUE of the Simulation_DB (DB2).
For range, enter from 0 to 50.
Change the bottles target position up to the conveyor end X150.
Fig. 15-155

Allen-Bradley Animation
The Allen-Bradley animation proceeds much the same as Siemens in that the device edited may
be animated in a number of ways including horizontal position. The position is a function of a
number in a location which is monitored and the beer bottle moved accordingly.
Fig. 15-156
Fig. 15-157

In the project window, select the HMI tags.
Fig. 15-158
Fig. 15-159
Drag the slider in the window to the right in order to get to the column Acquisition cycle.
Set the acquisition cycle of the HMI tag to 100ms.

Then save the project, load it to the panel and test it.
Fig. 15-160
Fig. 15-61
After 20 bottles, the conveyor motor stops. The bottle counter has to be reset before the next
start.

Resetting the Bottle Counter
Drag a button into the root screen.
Fig. 15-162
As text, enter Exchange beer case and adjust the color Position & size to the button.
Fig. 15-163

Under Events Press, select under bit editing the function SetBitWhileKeyPressed.
Select the tag reset_counter from Conveyor_DB [DB1].
Fig. 15-164
Set the acquisition cycle of the new HMI tag to 100ms.

Fig. 15-165

Drawing the Beer Case
Draw a rectangle with a transparent background.

Enter the width of the border, the position and size.
Fig. 15-166

Draw a vertical line at a distance of 30 pixels.
Fig. 15-167
Note
Although the measurements of the line are correct, it is drawn beyond the rectangle.
Change the form of the line ends to flush, and shorten the line by one pixel from 150 to 149.

Draw a horizontal line spaced at 30 pixels
Fig. 15-168
With copy and paste, create the remaining lines spaced at 30 pixels.

Highlight the beer case by dragging a border around it with the mouse.
Fig. 15-169
In the menu Edit select the function Group
Fig. 15-170

We dont want to display the rectangle and the lines when the beer case is exchanged.
At Rectangle_1 and at the lines, generate the animation Visibility using the tag
Conveyor_DB_reset_counter at value 1 Invisible. For the lines, the animation can also be copied
and pasted.
Fig. 15-171
Fig. 15-172
Drawing Bottles in the Case
Enlarge the view and draw a circle in the lower right field of the box.
Fig. 15-173
Fig. 15-174

Draw a second circle.
Fig. 15-175
Fig. 15-176
Group the two inserted cycles.

At Circle_1 and Circle_2, generate the animation Visibility with the tag
Conveyor_DB_IEC_Counter_0_COUNT_VALUE value range 0 to19 Visible.
Fig. 15-177
Fig. 15-178
Copy and paste the bottle.
For both circles, under Visibility change the value range of the tag
Conveyor_DB_IEC_Counter_0_COUNT_VALUE to 0 to18 Visible.
Fig. 15-179
Fig. 15-180

Animation with visibility is available with Allen-Bradley as well. It is shown below with
visibility as a property with a tag or an expression with tags available to provide logic for the
visibility of a device, in this case, a circle.
Fig. 15-181
Fig. 15-182

The expression editor gives the ability of the programmer to add logic to select the visibility of
an object.
Copy and paste the individual bottles. Fig. 15-183
At the animation Visibility of both circles decrease the value to by 1.

The last bottle has the value range from 0 to 0.
Fig. 15-184
Set the acquisition cycle of the new HMI tag to 100ms.
Fig. 15-185

OPC and Visual Basic
OPC is short for OLE for Process Control. OLE is short for Object Linking and Embedding.
OPC strives to connect industrial automation with software programs (sometimes referred to as
enterprise systems) to share data. OPC is an open system with shared standard approaches.
Currently seven standards comprise the OPC system. OPC Foundation is the organization to
oversee the adoption and creation of these standards.
OPC is a program that works with OLE (Object Linking and Embedding) a technology
developed by Microsoft for the purpose of embedding and linking to documents. OLE stands for
OLE for Process Control. Included in OPC are devices that provide aid to the programmer in
areas such as:
Alarms and Event
Redundancy: Industrial applications frequently require high availability and reliability

that can be easily achieved by implementing communication redundancy
Client Server Architecture: The client/server nature of OPC enables users to architect
connectivity solutions that would previously be prohibitively expensive.
Historical Data Access: OPC Historical Data Access (OPC HDA) specification is used to
archive and retrieve process data. Also included are trends reports using the OPC HDA
client applications.
DDE and OPC are integrated into the Allen-Bradley product through RSLinx. See the opening
tabs for these applications in RSLinx below:
Fig. 15-186
Microsofts Access and Crystal Reports are examples of the power of using OPC with Visual
Basic.

Graphic Standards From Windows Standards
Graphics come in many flavors but not all file formats are suitable for all purposes. How do you
know which is best? Some standards exist for a specific company. Other standards for graphics
are general and used by most. Some of these are:
Use All Caps with the Right Fonts
Use Less Clip Art - Use clip art with moderation and with purpose.
Use More White Space - White space provides visual breathing room for the eye.
Alignment - Everything on the page should align with something else. A grid is an
effective tool in insuring that text and images align. Break alignment only for emphasis
and sparingly within a piece.
Rule of Thirds - Visually divide your page into thirds. Place elements on the page within
these thirds for a more interesting and visually appealing layout. The rule of thirds says
that most designs can be made more interesting by visually dividing the page into thirds
vertically and/or horizontally and placing our most important elements within those
thirds.
Elements can be spaced more or less evenly or put the main elements in the upper third or
lower third of the page. Take this concept a step further by dividing the page into thirds
both vertically and horizontally and placing your most important elements at one or more
of the four intersections of those lines.
Single Visual - One of the simplest and perhaps most powerful layouts use one strong
visual combined with a strong (usually short) headline plus additional text.
Size - Use larger graphics to communicate the most important goals of the piece. Smaller
graphics are of lesser importance. When space is at a premium, drop the smaller elements
first they are less important.
Z Layout - Mentally impose the letter Z or a backwards S on the page. Place important
items or those you want the reader to see first along the top of the Z. The eye normally
follows the path of the Z, so place your "call to action" at the end of the Z.
Some recommend the font type and size. The most preferable is the Tahoma, Sans Serif
or Ariel. Font sizes of 8, 9, 10, 11, or 12 are usually recommended. The number of
different font sizes should be limited to one or two. Use of italics and underlining should
be limited. Make items bold that need to be emphasized.
As the human eye is attracted to color, use color to attract the eye to portions of the
screen. Over-use of color is to be avoided. A suggestion is to build the graphic interface
entirely in black and white and add color if there is a reason for its inclusion. Also
remember that many people have some form of color blindness and have trouble
distinguishing colors.
It is usually best to use black text on a white or off-white background. The black color is
easiest to see and should be encouraged. If the user insists on another pattern, it is
usually easy to change to accommodate their wishes. Do not use color to identify a color
of item. Always use text to identify a color of an item.
Borders of buttons should be uniform and same size if stacked vertically. If stacked
horizontally, heights should be the same but widths may vary.
While these are some simple suggestions to use in the development of a graphic, common sense
and an eye for the layout is usually best to start with. If the process is built on an autocadd or
other type of drawing, see if the layout can be imported and used as a background.
Remember that many clients and companies have a standard in place that should be followed
wherever possible. The graphic look is important and will be viewed by many people including
those in management. This is one of the best places that you can show your creative style and
make a statement as to the value of the engineering effort involved in the process. Your extra
effort in a good graphical interface will make many friends for you and your efforts.
Also, do not under-estimate the time and effort involved with a good graphic display. The larger
projects have a graphic programmer assigned to accompany a PLC programmer. The two must
work together or the project will fail. Usually they work in the same lab space and are
developing and testing software together as they progress through a project.
There is a natural argument as to the extent of programming code that must be written in the
HMI program. It can be done in the more sophisticated packages and should be considered. It
should also be limited. Be careful that any code involved in the HMI program should not
interfere with code in the PLC or real problems will follow. If the same programmer does not
generate both sides of code, then there may be misunderstanding as to who should do a particular
task. If the same programmer does both, others should watch that he or she does not include
very hard-to-maintain code. If the programmer programs the same idea in two or three places
that are not naturally linked, they can really mess with a subsequent persons ability to figure out
what is really going on. These programmers should be avoided and their code should not be
allowed to be used in any large organization. The ethical question of such programming style
is to be considered as unnecessary and unusually hard to change by anyone other than the
original programmer.

Practical Design of Logic with HMI
From early in the chapter, A-Bs design allows for a Push Buttons with the selection Multistate.
The memory circuit can be turned on or off from the multistate button. The better memory
circuit can also be turned on or off from the program. The memory circuit then must be able to
report to the HMI the present state. The program for this function is left as an exercise.
From HMI
Turn On
Fig. 15-187
From HMI
Turn Off
View Status
Memory
On HMI
Circuit
From Program
Turn On
From Program
Turn Off
The use of multistate buttons to provide this logic is useful but not necessary. The use of a single
button on the screen is an advantage in that one button can be used to turn on the memory, turn
off the memory and display the present state of the memory. All three functions can be
accomplished with a single button. All the time in advertising, we hear the ad for buy one, get
one free or the two-fer ad. This is a real three-fer. Buy one button and get the start button,
the stop button and the indicator light in the same button.
Stop
Fig. 15-188
Stop/Start
Start
Run
Pump
Run

Where to Put the Logic
The following conveyor system has five outputs, lights for percent complete of packages going
down conveyor 1 to conveyor 2. Write a program to turn on these lights based on the fact that
packages must pass photo-eye 1 to enter the storage area and pass photo-eye 2 to exit. This
program was solved in Ch. 8 using greater/less-than statements and discrete outputs. It is
possible now to turn on these outputs in the HMI program with no statements in the Ladder other
than the Up-Down counter.
You may find it easier or better to provide the logic in the HMI or Ladder. There is usually a
preference in most companies for one or the other or you may decide for them.
Storage
Storage area not Storage Storage Storage
area empty empty area 50% area 90% area full
Photoeye 1 Photoeye 2
Packages in Packages out
Conveyor 1 Temporary Conveyor 2

storage for 100
packages
Fig. 15-189
Consider Multi-State Indicators for the application above using RSView Studio as an example:
Fig. 15-190

Example: Expressions that return numeric values
For these examples, assume tag1 = 5 and tag2 = 25.
Expression Returned
Value
tag1 5
tag1 + tag2 (arithmetic 30
operator)
~tag1 (bitwise operator) -6
SQRT(tag2) (mathematical
function)
Example: Expressions that return true/false values
Expression Returned value

tag1 > 20 (relational operator) 1 (true) if tag1 is greater
than 20
0 (false) if tag1 is less than

or equal to 20
Industry\Valve AND 1 (true) if both valves are
Municipal\Valve open
(logical operator) 0 (false) if one or both

valves are closed
Example: Controlling visibility with If-Then-Else logic
To create a graphic object that is to be visible only when tag1 exceeds a specified value
1. Draw the object.

2. In the Visibility animation dialog type the expression:
If (tag1 > 55) Then 1 Else 0
3. Specify that the object is to be visible when the expression is true.
Example: Write expressions
In this example, the operator regulates the speed of a conveyor belt by entering a value in feet or
meters per second. When the operator enters the value in feet per second, the value is passed to
the data source without conversion. When the operator enters the value in meters per second, the
value is converted to feet per second before being passed to the data source.
The operator first indicates whether the value is in feet or meters by pushing a maintained push
button. The push button has one state corresponding to feet per second, and the other state to
meters per second. A tag called feet_or_meters is assigned to the maintained push buttons Value
connection.
Then the operator enters the value in a numeric pop-up keypad. The "?" character is the
placeholder for the value the operator enters.
Here is the write expression assigned to the numeric input enable buttons Optional Expression
connection:
IF feet_or_meters == 0 THEN
?
ELSE
? * 3.281
The application writes the result of the expression to the Value connection assigned to the
numeric input enable button.
Example: Using a multistate indicator
In these examples, the multistate indicator shows the status of a discharge screw for a bag filler
machine. The discharge screw has three states: Off, Running, and Faulted.
These examples show three different methods of achieving the same results. When designing
your own project, use the method that best fits your overall design.
Method 1: Using text to indicate the states
Create a multistate indicator with the captions "Off" for State 0, "Running" for State 1, and
"Faulted" for State 2. Select the border style None, the back style Transparent, and caption colors
that reflect each state. For example, use gray for State 0, green for State 1, and red for State 2.
Method 2: Using an image that changes colors to indicate the states
Create a multistate indicator with a monochrome image of the discharge screw on each state.
Select an image color of gray for State 0, green for State 1, and red for State 2.
Tip
You would typically use the symbol indicator object if you want to use the same
monochrome image on all states. The advantages of using the multistate indicator are that
you can use a different image for each state, the images can have more than two colors,
and you can add a caption to each state as well.
Method 3: Using color by itself to indicate the states
Create a multistate indicator with no images or captions. Place the indicator beside text or an
image of the discharge screw and select the back color gray for State 0, green for State 1, and red
for State 2.
Create multistate indicators
The multistate indicator displays the current state of a process or operation by showing a
different color, caption, or image to reflect different states.

You configure the state values of the multistate indicator. Then, at run time, the object displays
the state whose value matches the Indicator connection value at the data source.
You can enter a maximum of 2000 states plus the Error state.
To create a multistate indicator
1. In the Graphics Display editor, choose Indicator > Multistate from the Objects menu.
2. Drag the mouse to position and draw a rectangle the general size and location you want
the indicator to be.
3. Double-click the indicator to open its Properties dialog box.
4. In the Properties dialog box, specify how the indicator looks, set up its states and assign
an Indicator tag.
Tip
If the value of the Indicator connection does not match any of the configured state values
for the multistate indicator, the error state is displayed.
Set up how the multistate indicator looks (General tab)
To set up general options for the multistate indicator
1. In the Graphics Display editor, double-click the indicator to open its Properties dialog
box.
2. Click the General tab.
3. Specify these properties:
general appearance
state settings
Tip
Once you set up the options in the General tab, click the States tab to specify how the
indicator looks in each state at run time.
State settings
Number of states
Select the number of states for the object.
Trigger type
Choose Value if you want the object to trigger a state based on the value of the Value
connection.
Choose LSB if you want the object to trigger a state based on the least significant bit that is set
high in the Value connection.

Set up states for the multistate indicator (States tab)
In the States tab, set up how the multistate indicator's appearance changes to match the value of
the Indicator connection.
To set up states for the multistate indicator
box.
2. Click the States tab.
3. In the Select state list, click State 0.
4. Specify these properties for State 0:
value
general appearance
caption, if any
image, if any
5. Repeat steps 3 and 4 for each additional state and the Error state. (The Error state does
not have a value.) You can enter a maximum of 2000 states, plus the Error state.
Tips
Once you set up the general, caption, and image properties for one state, you can copy
and paste the states properties to another state or to all states.
To add or remove a state without returning to the General tab, click Insert State or Delete
State.
Insert Variable
To insert a variable in the caption, click this box and select the type of variable to be inserted
from the list. In the dialog box, specify the details of the variable and then click OK.
Set up connections for the multistate indicator (Connections tab)
To set up a tag or expression for the multistate indicator
box.
2. Click the Connections tab.
3. Assign a tag or expression to this connection:
4. Indicator

A read connection - You can assign a tag or an expression to this connection
If you assign a tag, the application reads the value of the tag at the data source, assigns this value
to the connection, and updates the object in the display to reflect the state corresponding to the
value or least significant bit value (depending on the trigger type).
If you assign an expression, the application calculates the value of the expression and updates the
objects display to reflect the state corresponding to the value or least significant bit value
(depending on the trigger type).
How the multistate indicator works at run time
The multistate indicator displays the current state of a process or operation by showing a
different color, caption, or image to reflect different states. The current state is the state whose
value matches the Indicator connection value at the data source if the Trigger type is set to Value
in the General tab) or the state whose value matches the value of the least significant bit set high
in the Indicator connection at the data source (if the Trigger type is set to LSB).
Using controls
If the Indicator connection value is a floating point value, the application rounds the value to the
nearest integer to determine the state to display.
Opening graphic displays
When you open a display at run time, the application reads the Indicator connection value and
updates the display based on the value and the trigger type.

benefits of integrating human-machine interfaces, historians
Human-machine interfaces (HMIs) and historians differ but need to be tightly integrated to
provide company operations with optimal value. Big data has little value without analysis and
access in real time. Seven application examples explain HMI-historian integration benefits,
including troubleshooting, analysis, and regulatory compliance.
Fig. 15-191
Human-machine interfaces (HMIs) and historians differ in purpose but need to be tightly
integrated to provide great value to companies' operations. HMIs provide effective control and
interactions between humans and machines. Historians collect high-speed time-series data to
maintain a chronology of events. Seven applications examples help explain integration benefits.
Connecting to data
HMIs typically connect to programmable logic controllers (PLCs) to get their real-time data.
Historians typically can connect to a HMI or directly to PLCs via OPC servers. Sometimes users
want to connect to the HMI because certain tags have calculated values within the HMI. The
preferred method should be that the historian connects directly to the PLC or source of the data.
The objective for the historian is to have a complete chronology of process events for future
analysis. HMI screens are typically being updated with new displays and graphics and may be
shut down or restarted on occasion. When this happens, the data is not being collected properly
and there are probably "holes" in the data-if the historian is connected to the HMI. By connecting
directly to the PLC source, there is an independent connection that still collects data whether the
HMI is running or not. Well-engineered historians also incorporate store and forward capabilities
within the logger/collector components and should be located on the same machine as the source.
This allows no data to be lost if network connections or communications go down between
computers due to network failure or unreliable remote connections via satellite, cellular, or
wireless connections. Also, data will not be lost when updating software to the latest software
revisions.

Historian storage, performance
With today's PC standard technology and capabilities, a typical historian system should be able
to store and access more than 10 years of raw data. Aggregated manufacturing big data is good
for certain reports, and historians should have the features to get access to this data, but it should
not be stored as aggregates. Raw data streams are needed for true analysis. A well-performing
historian should be able to easily exceed 1 million updates per second when storing data while
retrieving more than 3 million updates per second at the same time. Users become quickly
frustrated if they cannot get access to the data they need for analysis within a few seconds.
Historian ease of use
Users need intuitive tools to leverage historical data. They need easy access to the data tools that
don't require weeks of training. This historical data needs to be accessible to the operators within
the HMI via client applications that use Microsoft ActiveX controls or preferably Microsoft
.NET applications. If operators and engineers could view how different values were moving and
setpoints were being changed, they could identify the rippling effect through the entire system
and determine problems and solutions more quickly. The value is creating information that leads
to faster decisions from this data as opposed to having a bunch of data.
Fig. 15-192
The key is easy access to this data. The value of the trend data is that the user can ask "what if?"
and pull the data together to verify the theory immediately. If they must go through IT to get data
from the archives, which could take one or two days, they have lost that thought process. In
reality, if analysis doesn't happen in almost real time, it is not going to happen.
Data historians and HMI: The foundation of big data analytics
Cover story: Integration guidelines for human-machine interface and historian software should
help organizations determine the best combination of data historian and HMI software
components to turn big data into a big return on investment. See 9 best practice strategies in
combined use of human-machine interface and historian software. Link to a video demonstrating
an HMIs historical data replay technology used with a robot in a smart, connected
manufacturing environment.
Fig. 15-193
Integrating human-machine interface/supervisory control and data acquisition (HMI/SCADA)

software and historian software helps aggregate, merge, and analyze big data collected and create
a big return on investment (ROI). HMI/SCADA technology provides the ability to connect to an
array of data sources and to visualize that data for monitoring and control. Such data sources can
range from a programmable logic controller (PLC) in a manufacturing environment to an OPC
server in a data center to an IT device communicating via simple network manage protocol
(SNMP) to a building control device making contact via BACnet (an Ethernet protocol). It's all
part of the Internet of Things (IoT), connecting people and services, and leading HMIs are
evolving to embrace this trend.
Data is visualized by the HMI/SCADA software in real time to help with immediate decision
making, tie in to fault-state alarming, or provide points for trending. To remain competitive in
today's markets, that same data must also be recorded and then analyzed using a scalable, robust
plant data historian.
The high-capacity storage and fast retrieval capability of the latest historians complement the
rich 2D and 3D graphical data visualization of cutting-edge HMI/SCADA software, providing a
foundation for full use of an organization's big data.
Following are nine best practice strategies in the combined use of data historian and
HMI/SCADA software.

Cloud-integrated storage
Today's premium data historians are integrated with the latest in cloud-based technology. A
high-speed, reliable industrial plant historian becomes even more scalable by integrating with a
cloud application platform, such as Microsoft Azure, allowing access to big data from any
desktop, Web browser, or mobile device. IT costs are reduced due to simple setup and minimal
maintenance requirements, allowing organizations to infinitely grow applications based on the
changing needs of their business. Customers experience increased collaboration while
maintaining the security expected from trusted vendors.
Enhanced data synchronization via logger-to-logger communications
A premium data historian should also provide data logger to data logger communications, to
aggregate and merge data from any plant historian server. This feature allows historian servers to
exchange data hierarchically with other servers of similar type or brand, as well as with third-
party historians. These data exchanges can be triggered on a schedule or manually on demand,
regardless of whether the server is located on premise or in the cloud. This enables remote access
to the most critical information with maximum flexibility and control.
High speed
When comparing data historians, look for the use of a "swinging door" data compression
algorithm to provide high-speed data collection of over 100,000 data events per second. Also
check for automatic archiving, which allows for routine or triggered scheduling of data archives,
freeing up disk space and backing up files for long-term storage and retrieval.
Maximum compatibility with open standards connectivity
A data historian should take full advantage of the latest 64-bit Microsoft .NET-based computing
technologies and numerous performance features, including full use of multi-core hardware. It
should be certified for the latest operating systems such as Microsoft Windows 8, Microsoft
Windows Server 2012, and soon, Microsoft Windows 10, as well as with the Microsoft SQL
Server Business Intelligence platform and Microsoft Office 365. It should also fully use OPC
UA communication standards, as well as a wide variety of other protocols for connecting to
existing infrastructure. Third-party OPC HDA compliance ensures interoperability with hundreds
of applications to minimize the impact on existing plant infrastructure.
Extensive redundancy
Leading data historians support redundancy at all levels, including the use of remote distributed
data collectors, multiple distributed loggers, and multiple OPC classic and OPC UA interfaces.
By integrating automatic failover to active loggers, organizations can be certain that their
operations have the highest possible level of availability and performance.

Intelligent asset technology
Fig. 15-194
A growing need for data historians is integration with asset management tools. Users should look
for data historians that can integrate with an ISA-95-compliant asset modeling tool (most likely
within the linked HMI/SCADA component). Once connected, any analysis derived by the data
historian can then be included as a property of any asset, and subsequently, as a real-time value
within the HMI itself.
Powerful performance calculations
Top data historians provide extensive performance calculation capabilities, allowing users to
configure complex calculations that can be triggered periodically or on any data change event,
using a flexible set of date/time, mathematical, string, and historical data retrieval functions for
advanced analysis.
Data insertion
A tool should be provided for automatic or manual insertion of data into the data historian, to
import historical data or to log data from databases, other historians, field devices, and other
equipment, such as PLCs.
HMI/SCADA visualization, integrated historical data replay
Historical data should be just as easily accessible within the HMI as its real-time counterparts,
using desired conventions, such as gauges, trends, grids, charts, or animated objects. Fully
customizable 2D or 3D trends and charts can bring applications to life. A rich library of 2D and
3D charts (such as X vs. Y, logarithmic, bar graph, strip chart recorder, circular, and more)
provides clear and accurate representations of the data.
Intuitive ribbons and galleries can be used to customize trends by adding color, gradients,
smooth animation, translucency, size effects, anti-aliasing and more, making data analysis clear
and straightforward. Users should be able to drag and drop data sources during run-time
operations to view multiple trends simultaneously. Data can also be viewed in tabular formats
with the ability to enter operator comments, as well as manage lab data and audit trails, a useful
feature for companies following 21 CFR Part 11 policies. Historical data replay is an innovative
new feature that allows users to interact with on-screen playback controls to pause, rewind, fast-
forward, and replay the data movements of their plant assets and equipment, corresponding to the
logged data from the historian.
This level of integration is a significant development in the HMI/SCADA market, available

within leading HMI software platforms.
These guidelines should help organizations determine the best combination of data historian and
HMI/SCADA software components to turn big data into a big return on investment.
How to Get the Most from a Database
Databases help record, analyze, and relay plant-floor information, often behind the scenes. Data
arrive from manufacturing, controls, instrumentation, automation software, human-machine
interface software, execution systems, and even clipboard-wielding personnel, who may still
manually collect and enter information.
Databases help record, analyze, and relay plant-floor information, often behind the scenes. Data
arrive from manufacturing, controls, instrumentation, automation software, human-machine
interface software, execution systems, and even clipboard-wielding personnel, who may still
manually collect and enter information.
Without proper consideration of the process, database design, and implementation, however, a
database can become a monster to be fed, rather a source of intelligence and value for users.
Think about the databases used in your facility-are they working for you, or are you working for
them?
Almost all software uses some type of database to store and retrieve data. Arguably, an effective
database is organized so users unfamiliar with the underlying structure can get information in a
useful form without a lot of difficulty.
The software language providing the interface between the user and the data can vary.
Understanding how to organize and retrieve the information in a standard way obviously can
help.
Structured query language
Structured query language (SQL or database query language)-some say Satan's query language
because of its complexity-is a standard established by the American National Standards Institute
(ANSI) and International Standards Organization (ISO). IBM originally developed it in the
1970s.
SQL is described as a declarative language; users tell it what to do, rather than how to do it. The
resulting relational database, designed to organize large quantities of data, is usually a collection
of tables with relationships among them.
Tables' records are in rows and fields are in columns. Field types vary widely according to
content needs: numbers, text, currency, dates, objects and others.
Courses and books are available on database design and organization, to help establish and
understand the relationships between each table, each collection, of information.
Compatible software can retrieve its own information from databases. If information exists once,
in theory, it's easier to maintain and manage, because an update in a one location updates
information in related forms or reports in many places. This provides one 'truth.'
Users retrieve a set of information from SQL via a query or request. Queries can update, modify,
and calculate data. They also can be automated to feed standard reports and accept information
from various sources.
According to Microsoft Corp. (Redmond, Wa.), software programs do most database access, in
regularly scheduled reports, statistical analyses, and data entry programs. While Microsoft's SQL
Server offers online query tools and other wizards, Ronald Sielinski, senior industry technical
strategist within the Industry Solutions Group at Microsoft, says most end-users will likely want
an application interface between them and a database, because writing queries is like writing
code. And, he says, 'The cheapest line of code is one you can buy... not many companies are
interested in writing their own applications.'
Microsoft Developer Network Library at msdn.microsoft.com explains that software programs

access SQL three ways:
Embedded SQL, in which SQL statements are embedded in a host language, such as C or
COBOL;
SQL modules, in which SQL statements are compiled on the database management
system (DBMS) and called from a host language; and
Call-level interface (CLI), which consists of functions called to pass SQL statements to
the DBMS, and to retrieve results from the DBMS.
ISA/IEC-62443 (Formerly ISA-99)
ISA/IEC-62443 is a series of standards, technical reports, and related information that define
procedures for implementing electronically secure Industrial Automation and Control Systems
(IACS). This guidance applies to end-users (i.e. asset owner), system integrators, security
practitioners, and control systems manufacturers responsible for manufacturing, designing,
implementing, or managing industrial automation and control systems.
These documents were originally referred to as ANSI/ISA-99 or ISA99 standards, as they were
created by the International Society for Automation (ISA) and publicly released as American
National Standards Institute (ANSI) documents. In 2010, they were renumbered to be
the ANSI/ISA-62443 series. This change was intended to align the ISA and ANSI document
numbering with the corresponding International Electrotechnical Commission (IEC) standards.
All ISA work products are now numbered using the convention ISA-62443-x-y and previous
ISA99 nomenclature is maintained for continuity purposes only. Corresponding IEC documents
are referenced as IEC 62443-x-y. The approved IEC and ISA versions are generally identical
for all functional purposes.
ISA99 remains the name of the Industrial Automation and Control System Security Committee
of the ISA. Since 2002, the committee has been developing a multi-part series of standards and
technical reports on the subject. These work products are then submitted to the ISA approval and
publishing under ANSI. They are also submitted to IEC for review and approval as standards and
specifications in the IEC 62443 series.

Summary
This chapter is the only chapter solely dedicated to the HMI graphic panel. In Ch. 7, we had a
short tutorial involving getting the Siemens HMI attached to the S7-1200. That was an
introduction to the HMI panel and useful for encouraging students to use the panels instead of
wiring to buttons and lights. This chapter expands on that first experience in that both Siemens
and A-B are discussed as well as types of product.
The basic panels for both manufactures are introduced and explored. Buttons as well as other
devices are built. Some examples of how to use various graphics are included as well. The
chapter ends with a discussion of graphics standards and a common problem that I commonly
refer as the three-fer button. The chapter is not meant to be an exhaustive study of HMI panels
but as a starting point for students needing to learn some graphics before launching their careers.
While this chapter begins the broad development of HMI panels, the design of panel interfaces
and screen interfaces continue in subsequent chapters, especially the chapter on motion and the
chapter on pid control.

Lab 15.1 Revisit - The Cash Register
The basic lab is copied from Chapter 7 as follows:
Design a simple cash register similar to one found at McDonalds or Burger King. To do this,
determine a menu of five or six items from the restaurant. Also, include a Total button or a clear
button or possibly both. Also, include a means for backing out of a mistake without starting over
from zero. Display the cost of the total order in the PLC at an address in the data table. Use
floating point math and you are encouraged to do so.
For example:
Whopper
Whopper Cancel Last
Combo
Whopper New
Dbl Combo Fries Order
Fig. 15-195
Whopper Jr Total/Tax/
Combo Drink Optional
Find the approximate prices from a McDonalds or Burger King for the items chosen. When an
item is entered, its count is incremented automatically by one. If a button is entered multiple
times, the count is incremented to display the total count. If a mistake is made, the attendant
must be able to back up at least one entry and erase the last item or decrement that item by one.
Hints to the base lab:
Notice that counters may be referenced as either Count Up or Count Down. If the count is
counting up, the count is incremented in rung 0000. If the count is counted down, the count is
decremented in rung 0001. Individual inputs are used to increment each product choice.
However, to decrement the count, a separate button labeled Cancel Last is used. This button
must remember the last product chosen and decrement that item. Use the logic in chapter 7
Relay Instructions to remember when a button was pushed.
Use the Count Up/Count Down logic for holding active counts for the various items in the cash
register.
Make the following changes for the application:
1. Display the total price for the order on the screen. Use Floating Point numbers where
possible. Display totals in $xx.xx format.

2. Add a second screen to allow the manager to change base prices for each item. Do not
include a password to move from screen to screen.
3. Include a button to add 6.25% tax if not To Go for the order.
4. Include a live count of the number of each item ordered.
5. Create means for going from Screen 1 to Screen 2.
6. Screens should resemble the following for Lab 15.1:
Whopper 1
Burger 3 Order ToGo
Fries 0 Reset
Onion R Cancel Last

Fig. 15-196
2
Chicken 0
Wh Cmb 2 $17.31
Price of Whopper
Price of Burger Fig. 15-197
Price of Fries
Price of Onion Rings
Price of Chicken
Price of Whop Cmbo
Lab 15.2 Build the Conveyor application as described above for Siemens. Then build the
same application for A-B. Compare the two. You will need to write PLC logic to move the
elements and increment counts. You do not need to copy the programs included but may write
your own programs.

Questions
1. How would you build the following pushbuttons in Siemens? Describe:
Momentary
Maintained
Latched
Multistate
Interlocked
Ramp
2. Describe how to demonstrate the flow of a liquid of red color through a series of pipes.
Several hand valves are in the path of the flow. How would one describe this graphic with
A-B, Siemens?
3. You are assigned the task of describing a ride at an amusement park graphically. The ride is
a zip-line. You may place sensors at the beginning and end of the ride. Describe the graphic
using A-B and then Siemens controllers and HMI.
4. For the following device, what is the animation property used to move the clocks hand.
Fig. 15-198
5. Why would one design a PLC and HMI system with OPC and Visual Basic rather than one
of the packages described in this chapter?
6. Write code to accomplish the memory circuit in Fig. 15-188 using A-B, Siemens.
7. Describe how the programmer would animate the bottle on the conveyor moving right to left
for Allen-Bradley, for Siemens.
8. Describe how A-B and Siemens shows each bottle being entered into the case of bottles.
9. When designing the Cash Register program, what differences were noted between how A-B
and Siemens handle math data types?
10. Why is it important that a memory circuit such as Fig. 15-188 be able to be programmed?

11. Using either A-B or Siemens ladder logic, write a cash register program that uses an
accompanying HMI program with only three items [hamburger, fries, drink]. Include logic
to calculate the total price ignoring tax. Ignore the cancel last button and combo logic as
well.
12. Using A-B or Siemens ladder logic, write a program that could be used to show the
movement of a bottle across a conveyor belt and populate a case. Use a case of 12. Use a
start and stop button to start the operation. Use a reset button to set the bottle counter in the
case back to 0 and allow another operation to fill the case with bottles.
13. If you were moving a program from real pushbuttons to an HMI, what one thing must you
do?
14. Write code and describe how an HMI would be constructed to achieve the following:
Fig. 15-17
All Data, No Information
By contrast, a bank of analog indicators, as in Fig. 15-18, can represent these numbers much
more effectively. Analog is a powerful tool because humans intuitively understand analog
depictions. Show how the HMI would be changed:

And finally the following:
15. Again, write code and describe how to provide HMI input for the following:
Fig. 15-22
Depicting Process
Values

16. Beck realized that depicting topology, and not geography, was the key using a map
demonstrate the following principles:
He determined these questions to be the key ones for the subway rider:
Where am I now (what station)?

Where am I going (what station)?
What lines service this station and where do they go?
Where do I change trains?
How many stops until my destination?
Even more importantly, he realized that there were many things that the subway rider did
not need to know:
Am I going around a curve?

Am I passing under a river or near another train line?
What is the relative distance between stations?
Am I traveling in a specific direction (N,S,E,W) in between stations?
17. Fill in the following blanks from the statement on pg. 55 of this chapter:
Experience has shown that the operators will begin to use the High Performance Level ____
graphics preferentially for normal operation and abnormal situation detection. Why?
They will use the existing Level _____ graphics for the detailed troubleshooting purposes
that they are most suited to support.

Human Machine Interface

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Human Machine Interface

Uploaded by

Copyright:

Available Formats

Chapter 15 HUMAN MACHINE INTERFACE

Historical Panel Design

Fig. 15-2 A Simple Control Panel

Ch 15 Human Machine Interface 1

Fig. 15-4 This panel

Meters show levels or

Alarms are shown in

Ch 15 Human Machine Interface 2

Ch 15 Human Machine Interface 3

Ch 15 Human Machine Interface 4

Whatever the appearance of the outside

The picture below is of a panel

Ch 15 Human Machine Interface 5

Level 1 SA P&ID representation with Live numbers

Is the pump in alarm or stopped?

These three areas are a big cause for eye fatigue.

In the 90s, the following characteristics were thought to be important:

The Use of Trending

Using Color Effectively

Ch 15 Human Machine Interface 7

Gray is in fashion gray backgrounds, gray pipelines, gray vessels.

For things that are Abnormal

Color, contrast, animation

Interpreting the data

Is this process healthy?

Interpreting the data:

Normal operational values that are shown in white

Depicting Material Balance

Ch 15 Human Machine Interface 8

Provide high and low bad indication on the vessel

Depicting Device State

HMI Display Organization

Putting Ideas into Practice

Ch 15 Human Machine Interface 9

Ch 15 Human Machine Interface 10

HMIs Past and Present

Ch 15 Human Machine Interface 11

Justification for HMI Improvement

Ch 15 Human Machine Interface 13

Proper Graphic Principles

Primarily a schematic or P&ID representation

A generally non-schematic depiction except when functionally essential and at Level 3

Show Information Instead of Raw Data

Ch 15 Human Machine Interface 15

Fig. 15-19 Further Explanation of Moving Analog Indicators

Ch 15 Human Machine Interface 16

Fig. 15-20 Analog Depiction of PID Controllers

Proper User of Color

Fig. 15-21 An Example of HPHMI Color Palette

Elements and Depictions of HPHMI

Depicting Process Values

Ch 15 Human Machine Interface 19

Ch 15 Human Machine Interface 20

Depicting Profiles of Temperature or Pressure

A correct profile can be seen at a glance as a straight line.

Depicting Dynamic Equipment

Fig. 15-26 - Depicting Status with Redundant

Bars vs. Pointers

Depicting Level Indication

Ch 15 Human Machine Interface 22

Depicting Control Valves and Shutoff Valves

Ch 15 Human Machine Interface 23

Ch 15 Human Machine Interface 24

Ch 15 Human Machine Interface 25