chapter 15 human machine interface - utoledo …wevans/chap15_s.pdf · chapter 15 human machine...

Ch 15 Human Machine Interface 1

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-B’s 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.

Compact

Logix

WinCC

Siemens

1200

RSView

ME

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-1 HMI Graphic

Control Packages

Fig. 15-2 A Simple Control Panel

with Push Buttons and Switches

with Indicator Lights


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 user’s 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 plant’s

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 80’s:

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 90’s, 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 it’s 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 wasn’t

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 operator’s 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 operator’s HMI usually consisted

of a control wall concept such as Fig. 15-11.

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 operator’s

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-12

Example of a Control Wall


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.

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.

Fig. 15-14

A Typical

Crowded, P&ID-

Style Graphic

Fig. 15-13

Early Graphic

Showing Many

Problematic

Practices


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.

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-15

A Flashy Graphic

inappropriate for

Actual

Operational

Control

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.

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-17

All Data, No Information


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.

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-22

Depicting Process

Values


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.

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-23

Depiction of Alarms


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.

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.

Fig. 15-24

Linked Alarm Information

Fig. 15-25

Measurement Profile


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 bar’s 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.

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.

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

Fig. 15-27

Bars vs Pointers


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-28

Vessel Levels

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

equipment’s 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.

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-30

Digital Composite

Point Depiction


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-31

Trend Depiction of

Desirable Ranges

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.

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-33

Advanced Process Control


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.

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-34

Layers of Confirmation

Fig. 15-35

Interlock Symbology


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.

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-36

Interlock Before and After

Activation

Fig. 15-37

Interlock Diagnostic Table


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 don’t 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-38

Shutdown Initiator with First-Out


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.

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.

Fig. 15-39

High Performance Element

Designed for Startup Use

Fig. 15-40

Navigation Buttons

and Targets


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.

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.)

Fig. 15-41

Navigation Buttons and

Targets


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.

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-42

“Blob Graphic” Elements

with Insufficient Contrast

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 operator’s 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 doesn’t 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

today’s 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 operator’s 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 pulverizer’s 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 operator’s 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 Operator’s 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 didn’t 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 don’t 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 Beck’s 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 Beck’s 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 operation’s 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

today’s 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 operator’s

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


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.

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


Fig. 15-72 Adding an Object

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.

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:

To activate the Factory Talk RSLinx Enterprise, you must first configure Factory Talk per the

following:

Fig. 15-77 Various Animation Configurations


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-78 Activation of

Factory Talk RSLinx Enterprise


Tags may be monitored in the monitor mode. Editing of tags is done in the edit mode:

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-B’s 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-80 Various Program

Tags for Use with the HMI

Fig. 15-81 Tag Types in

RSLogix 5000


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


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.

While building a screen or series of screens requires more instruction, we leave the A-B software

to discuss Siemens’ HMI interface.

Fig. 15-98

Color and Captions Modified

under States Tab

Fig. 15-99

The Common Tab Controls

Size, Position and Name of

the Button

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.


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 world’s leading industrial companies, subscribes to the philosophy of

“Totally Integrated Automation” (TIA). This concept ensures users that automation equipment

from the company’s 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 tag’s 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 doesn’t

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.

7. First, under PLC connections, select Control conveyor.

Fig. 15-102

Select an

HMI Panel

Fig. 15-103

Connecting the

HMI to the PLC


Then click on Next.

8. Under Screen layout, change the background color to White and remove the check mark at

Page header.

Then click on Next.

9. Remove all check marks at Alarms.

Fig. 15-104

Connecting the

HMI to the PLC

(cont)

Fig. 15-105

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.

Then click on Next.

Fig. 15-106

Screen Layout

Fig. 15-107

Defining a

Root Screen


11. As system screens, select the switch-over Operating modes and Stop Runtime.

Then click on Next. Finally, predefined system buttons can be added. Remove all check marks.

Then click on Finish.

13. The WinCC flexible interface is opened with the root screen.

Fig. 15-108

Defining a System

of Screens

Fig. 15-109

Finishing the

Wizard


WinCC flexible 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.

Project navigation Menu bar and buttons

Detail view Properties window

Tools Work area

Fig. 15-110

The WinCC

Interface


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.

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.

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.

Fig. 15-111

Project Tree

for WinCC

Fig. 15-112 Menu Bar


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.

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 system’s 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

Fig. 15-115

Details of

the Object


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:

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.

The IP address has to be assigned to the panel also. By means of Accessible devices, read out the

panel’s MAC address, or read it on the back of the panel.

Fig. 15-116

The System Screen

Fig. 15-117

Establishing

the PLC

Connection


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.

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.

Fig. 15-118

Assigning the

IP Address

Fig. 15-119

Assigning the

IP Address


Select System screens and in the Properties window below copy the function Activate screen at

Events Release.

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.

Fig. 15-120

A Start-Up or

System Screen


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! Don’t press the input key; otherwise, a second line is generated.

Under Layout, enter position and size.

Fig. 15-123 Adding a Label

Fig. 15-124 Modifying a Label’s Size


Under Events Press select the function SetBitWhileKeyPressed under Edit bits.

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].

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-125 Select the Button’s Function

Fig. 15-126 Tie the Button to a Tag

in the PLC or HMI

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! Don’t 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.


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-130

More Example

HMI Tags


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 it’s 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

"Set PG/PC interface"

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-132

Conveyor

Program in

the PLC

Fig. 15-133

Running the

Simulator


Starting the Configuration in Runtime

Click on the button Start runtime.

Visualization is opened in the RT simulator.

Fig. 15-136 Running the Simulator

Fig. 15-135

Fig. 15-134

Running the

Simulator


Test the project of the conveyor control.

The automatic or manual mode is now pre-selected on the panel.

Downloading the Configuration to the Panel and Testing It

Click on the button Download to device.

Fig. 15-139 Download to HMI Panel

Then click the button Load.

Fig. 15-137

Fig. 15-138


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-140


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-141 Configuring the Start Button


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.

Load the configuration to the panel, and test the Start and Stop buttons.

Fig. 15-146

Fig. 15-145


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-148

Fig. 15-147


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.

Note

All screen objects have to be within the work area (320x240 pixels).

Fig. 15-150

Fig. 15-149


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 bottle’s 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.

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.

Fig. 15-158

Fig. 15-159


Then save the project, load it to the panel and test it.

After 20 bottles, the conveyor motor stops. The bottle counter has to be reset before the next

start.

Fig. 15-160

Fig. 15-61


Resetting the Bottle Counter

Drag a button into the root screen.

As text, enter Exchange beer case and adjust the color Position & size to the button.

Fig. 15-162

Fig. 15-163


Under Events Press, select under bit editing the function SetBitWhileKeyPressed.

Select the tag reset_counter from Conveyor_DB [DB1].

Set the acquisition cycle of the new HMI tag to 100ms.


Fig. 15-164

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.

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.

Fig. 15-167


Draw a horizontal line spaced at 30 pixels

With copy and paste, create the remaining lines spaced at 30 pixels.

Fig. 15-168


Highlight the beer case by dragging a border around it with the mouse.

In the menu Edit select the function Group

Fig. 15-169

Fig. 15-170


We don’t 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.

Group the two inserted cycles.

Fig. 15-175

Fig. 15-176


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.

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-183

Fig. 15-184


Set the acquisition cycle of the new HMI tag to 100ms.


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.

Fig. 15-185


DDE and OPC are integrated into the Allen-Bradley product through RSLinx. See the opening

tabs for these applications in RSLinx below:

Microsoft’s 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.

Fig. 15-186


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 person’s 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-B’s 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.

Memory

Circuit

From HMI

Turn On

From Program

Turn On

From HMI

Turn Off

From Program

Turn Off

View Status

On HMI

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.

Fig. 15-187


Start

Stop

PumpRun

Stop/StartRun

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.

Consider Multi-State Indicators for the application above using RSView Studio as an example:

Photoeye 1

Conveyor 1

Photoeye 2

Temporary

storage for 100

packages

Conveyor 2

Storage

area empty

Storage

area not

emptyStorage

area 50%

Storage

area 90%

Storage

area full

Packages outPackages in

Fig. 15-188

Fig. 15-190

Fig. 15-189


Example: Expressions that return numeric values

For these examples, assume tag1 = 5 and tag2 = 25.

Expression Returned

Value

tag1 5

tag1 + tag2 (arithmetic operator)

30

~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 Municipal\Valve

(logical operator)

1 (true) if both valves are open

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 button’s 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 button’s 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 state’s 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

object’s 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.

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.

Fig. 15-191


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.

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.

Fig. 15-192


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 HMI’s historical data replay technology used with a robot in a smart, connected

manufacturing environment.

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.

Fig. 15-193


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

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

Fig. 15-194


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.

http://msdn.microsoft.com/


Linking PLC UDT Tags to HMI Faceplates and Pop-ups in TIA Portal V13 SP1 (DMC Corp)

A blog posted by Jason Mayes in Front Page, PLC, Automation, Siemens PLC, HMI and

SCADA, WinCC

PLEASE NOTE: This blog was written using features available in TIA Portal V13 SP1 Update

1. Some of the functionality shown was removed in Update 3, specifically the ability to

multiplex UDTs. Hopefully the rest of the information will be still be helpful to you!

Here at DMC, we spend a lot of time programming PLCs and HMIs. While we program systems

of all types and flavors, I'm personally most experienced with Siemens (TIA Portal)

and Rockwell (RSLogix5000/FactoryTalk View). There are a few new features included in TIA

Portal V13 SP1 that I have found to be incredibly useful in the past few months and have

allowed me to be even more efficient in my programming. I'm going to focus today on a series of

updates that were added in SP1 that make it even simpler to take advantage of the nested data

structures we can create in our Data Blocks - specifically, the ability to share UDTs between a

PLC and HMI, link UDTs to Faceplates, multiplex arrays of UDTs, and create simple, powerful

pop-ups.

Before we get started, let me say that if you're not already taking advantage of PLC data types

and Global DBs to build rich data structures in your project, you're missing out. Having come

from an object-oriented programming background, I really appreciate what the Function

Block/Data Block paradigm will allow you to do in a PLC - it really does push PLC

programming towards object-oriented programming. And let's face it, the less time we all spend

on repeating tasks and minutiae, the more time we can spend actually programming.

As an exercise, let's pretend we have a project with a large number of simple valves. Of course

we like to save time, so we're going to develop a special FB to handle our valves: auto/manual

control, alarms, etc. In addition to eliminating the amount of code to be written, this allows us

the additional advantage of keeping our future valve logic updates to a single place. Our FB has a

few inputs including the feeback signals for open/close, an in-out for our 'valve' data type, and an

output for the open/close command.

So, what is in our 'valve' data type? For this simple example, let's create the following PLC data

type, udtValve:

Fig. 15-195 Valve

Created using UDT

https://www.dmcinfo.com/latest-thinking/blog/id/9136/linking-plc-udt-tags-to-hmi-faceplates-and-pop-ups-in-tia-portal-v13-sp1

https://www.dmcinfo.com/latest-thinking/blog/articletype/authorview/authorid/28/jasonm

https://www.dmcinfo.com/latest-thinking/blog/articletype/categoryview/categoryid/4/front-page

https://www.dmcinfo.com/latest-thinking/blog/articletype/categoryview/categoryid/10/plc

https://www.dmcinfo.com/latest-thinking/blog/articletype/categoryview/categoryid/56/automation

https://www.dmcinfo.com/latest-thinking/blog/articletype/categoryview/categoryid/57/siemens-plc

https://www.dmcinfo.com/latest-thinking/blog/articletype/categoryview/categoryid/66/hmi-and-scada


https://www.dmcinfo.com/latest-thinking/blog/articletype/categoryview/categoryid/67/wincc

https://www.dmcinfo.com/services/manufacturing-automation-and-intelligence/plc-programming/siemens-s7-plc-programming

https://www.dmcinfo.com/services/manufacturing-automation-and-intelligence/plc-programming/allen-bradley-plc-programming

https://support.industry.siemens.com/cs/document/104509915/delivery-release-for-simatic-wincc-v13-sp1?dti=0&lc=en-US

https://support.industry.siemens.com/cs/document/104509915/delivery-release-for-simatic-wincc-v13-sp1?dti=0&lc=en-US


Fig. 15-196 Siemens FB for udtValve

We've broken our data type into three structures: configuration, status, and control. The

configuration group of parameters defines the valve's physical behavior and its unique name. The

status group contains all status information about the valve and is used both within the PLC and

the HMI. The control group has the open/close and fault reset requests. I find breaking things up

like this makes it much easier to find the right tag you're looking for when programming.

For our valve Function Block, fbValve, let's say we have something like this:


Now that we've developed a re-usable function block for our valves, let's create a DB to contain

all of our valve data. I'm going to create a Global DB and name it dbValves. In it, I am going to

create an array of udtValve. Within this data block, I can set configuration values, including

valve names, for each of the valves I am going to use. Let's imagine we'll be using 10 valves. As

you can see below, I've entered configuration values in each valve's data structure.

Fig. 15-197 Siemens FB for udtValve

The final step on our PLC is to add our newly written code. I've created a FB (fbValves) to

contain all of my valves, instantiated 10 valves (multi-instanced versions of fbValve) within it,

and dropped fBValves into OB1.


Now, let's move to the HMI. Let's say we want to put together a simple P&ID of our system

showing each of the valves and their status. Let's also imagine we want to allow a user to click

on a valve and open a pop-up so that they can get more information as well as control it

manually.

Let's start with the first task - our simple P&ID. I'm going to grab a simple valve from the

toolbox (under "Elements - Symbol Library") and add an indicator for the valve name. Under

"Properties - Appearance" for the symbol, I'm going to change the "Fill Style" to "Shaded". This

will allow me to add some color animation to the valve: Orange/flashing when the valve state is

not known, Grey when the valve is closed, and Green when the valve is open. Additionally, I

would like the valve's name to change to Red and flash when the valve is faulted.

I could start adding in my animations now, but I don't want to have to redo that process for each

valve. Instead, I'm going to create a faceplate so I can write the logic once and reuse it several

times. To do this, select both the valve symbol and the valve name indicator, right-click, choose

"Create Faceplate", and name it 'ValveIndicator'.


Inside the faceplate editor, I could create new properties for the fault status, the valve state, and

the valve name, then tie each to the appropriate item/animation. However, this would require

linking each of these properties back to the appropriate tag inside of my data structure. With a lot

of valves, this could take a lot of work. This is where one of the new TIA Portal V13 SP1

updates will come in handy: the ability to use PLC UDTs (PLC data types) in the HMI.

To have access to a PLC data type on the HMI, we will first need to add it to our project library

as a type. To do so, just drag udtValve from the PLC project tree into the "Project Library -

Types" folder:


Now, back to our Faceplate. Let's add a new property of type udtValve. Now when we use this

Faceplate, we will only need to link a single tag: all of the individual animations and properties

will be internally linked, within the Faceplate, to the appropriate tag within our UDT. Below is

my Faceplate and the animation for the valve color. Notice in the Properties window that there is

only a single property of type udtValve.

When you're finished editing your Faceplate, release the version and let's go back to editing our

HMI screen. Select the new Faceplate object and view the Interface tab. Link it back to

dbValves.Valve[0] by navigating to "Program Blocks - dbValves".

That's it! Now we can add more instances of our Faceplate to the screen and simply link a new

valve instance to each - nothing to it!


So, getting back to our original goal - we've succeeded in creating a simple Faceplate that can be

linked directly to a single tag (UDT).

The second task we set out to accomplish was to create a pop-up that can show more detailed

information for any given valve. In this case, we want to create our pop-up so that it is capable of

being opened to display any one valve at a time. To do this, we will need to set up a

'multiplexing' tag to look at different valve instances in our array of udtValve. If you've tried this

before, you may have run into issues. Luckily, there have been a few updates in V13 SP1!

First, let's set up our 'multiplexing' tag. We'll need to create an 'index' tag locally on the HMI that

can be used to choose the active valve. In my default tag table, let's first create a local Index tag

(with type of "UInt"). Next, in your project tree and while still looking at your HMI tag table,

select dbValves. From the "Details View" (see screenshot below), drag Valve[1] over to your

HMI's default tag table and change the name to IndexedValve:


At this point, notice that the HMI Tag is linked to a specific valve within our array of udtValves,

dbValves.Valve[1]. Now, select your new IndexedValve tag and open up the property pane

below. Select the empty drop-down box for "Address" and choose "HMI Tag". Now, navigate to

your HMI tags and select "Index," the internal tag we created a few moments ago. At this point

you will notice that the PLC Tag name shows "<Multiplex Tag>" (instead of

dbValves.Valve[1]), and the 'address' now shows you a dynamic link to array. By setting

our Index tag, we can now vary where our IndexedValve is pointed.

Great! Now, let's create another faceplate to show

whatever information you would like. I've created the

faceplate at left and configured a single "udtValve"

property to link it. It will give the user the ability to

switch control modes, open and close the valve, and

see status information.


The last piece of our puzzle is the pop-up. This is another great addition to TIA Portal V13 SP1

(for more info, see this). To create a pop-up, navigate in the project tree under your HMI to

"Screen Management/Pop-up Screens". Add a new pop-up screen and add your new faceplate to

it. Select your faceplate and view the "Interface" tab under Properties. Now, link

your IndexedValve to the faceplate.

Finally - our last step. Add an invisible button and place it over one of the valves on your P&ID

screen. You can do this by using a button from your HMI toolbox and configuring it to be

'Invisible' from within the properties. On the button's Click Event, add the following:

https://www.dmcinfo.com/latest-thinking/blog/id/9091/wincc-comfortadvanced-v13-sp1-pop-up-screens-and-slide-in-screens


Now, when a user clicks on a valve from the P&ID, the triggered event will first update the index

of the valve that is chosen, and then show the pop-up screen.

There you have it! We've taken advantage of several really great features that were added in TIA

Portal V13 SP1: the ability to use PLC data types (UDTs) on an HMI, the ability to link a

faceplate to a single UDT, the ability to multiplex an array of UDTs, and the ability to add a

simple pop-up. As I'm sure you can imagine, there are many potential uses for these new features

and this example is just one possible application. Good luck programming and let me know if

there are any new features you've found that can help me be more efficient in the future!

Leveraging Siemens MultiUser Engineering for TIA Portal

Posted by Gina Brooks-Zak in PLC, Automation, Siemens PLC, HMI and SCADA

With Siemens TIA Portal V14, a great new tool for PLC and HMI development

called MultiUser Engineering was released.

MultiUser Engineering allows multiple developers to access a server project through local

sessions and quickly and seamlessly merge updates to PLC or HMI code such as function blocks,

user-defined types (UDTs), WinCC Comfort or Advanced screens, and more.

DMC has been using the MultiUser tools with great success, and I'd like to share a few insights

with you here.

How Does MultiUser Engineering Work?

MultiUser Engineering stores an alternate version of the typical TIA Portal .ap14 project files to

a central location where multiple developers can access the files.

This is called the server project.

For machine builders or large facilities with many TIA Portal projects, it makes sense to create a

secured LAN and/or VPN accessible file location for your developers. DMC has set up

something similar, but we've also used the MultiUser server in a static IP LAN environment for

short commissioning jobs where there is too much overhead to hook up to a wider network.

One commissioning engineer can easily set their laptop to host the server and other

commissioning team engineers can then access the files by inputting the static IP address of the

host laptop. This is a great time saver when hardware configuration or other fundamental project

https://www.dmcinfo.com/latest-thinking/blog/id/9545/leveraging-siemens-multiuser-engineering-for-tia-portal

https://www.dmcinfo.com/latest-thinking/blog/articletype/authorview/authorid/116/ginaz

https://www.dmcinfo.com/latest-thinking/blog/articletype/categoryview/categoryid/10/plc

https://www.dmcinfo.com/latest-thinking/blog/articletype/categoryview/categoryid/56/automation

https://www.dmcinfo.com/latest-thinking/blog/articletype/categoryview/categoryid/57/siemens-plc



changes common at commissioning time would require all engineers to get a new copy of the

project once the updates were downloaded to the PLC.

If you do use this strategy, make sure you always consider network security and use

caution, especially if there are any connections to an outside network.

Use HTTP in a static IP environment to quickly use a laptop as the server host

Creating Local Sessions

Once the server project location is established, developers can add projects and create local

sessions of projects.

A local session contains the individual changes of a developer. With local sessions, the following

can occur:

Each function block or HMI screen can be flagged by the developer to indicate to

everyone else who has a local session open that they are working on that block.

When the developer is complete with changes, they can be "checked in" to the server

project. The other developers can then push those changes to their local sessions

by refreshing from the server project.

If there is any question of who may be working on a certain flagged block, users can right-

click on the flagged item and select Usage Info to see the user’s local session and name.


Local instance toolbar at top, check-in, refresh, open server copy, server project status; left,

fbPump flagged in local session, displays as blue; right, fbPump displays as yellow in another

user’s local session


Top, local session check-in dialogue; bottom, local session refresh from server project view

Right-click on a flag-marked item to view “Usage Info”

Local Sessions versus Online PLC Code

When working online with a PLC using MultiUser Engineering, remember that the server

project is not necessarily consistent with the code that is on the PLC. Code changes still need

to be downloaded to the PLC. One developer’s changes do not automatically appear on another

developer’s software instance.

That being said, there are many instances where this functionality is advantageous; it allows

greater control of the timing of changes and when test code is set to be downloaded to the PLC.


An engineer may want to test code online with a PLC before checking in to the server copy while

another engineer tests their local session on a completely different PLC.

I have found that in a commissioning environment where you are working on one PLC, it is best

to keep the server project the “consistent” online copy of the PLC. When one user checks-in,

it is their responsibility to refresh their local session and then download the changes to the PLC.

Remember that the server project copy, local session, and the project online with the PLC may

all have different code or pending changes

Keep in mind that certain changes cannot be made in a local session copy.

These types of changes include:

Hardware configuration

PLC or HMI properties

HMI connections

Technology objects If the change attempted requires it made directly in the server project, you will receive a prompt

at the top of the window, asking to open the server project view.


This task is a bit confusing because once you open the server project, you must then navigate

back to what you were trying to add through the project tree on the left-hand side of the Portal

UI.

It's important to note that when you or another user is editing the server view, a yellow icon with

a lock symbol displays in the local instance toolbar and no other users can check in their

changes until the server view is closed through clicking Save Changes, Discard Changes or

the server symbol in the local instance toolbar.

Warning dialogue when attempting change in local session which must be made in the server

project

When opening a project in server view, make sure to navigate to the change you were trying to

make. You’ll see both the local session and the server view in your left-hand Portal Project Tree.

Users can not check-in while the server project is being edited. Users see a yellow icon with a

lock in this case.

If you are managing the server project file location, make sure to increase the number of stored

project versions through the MultiUser Configuration application (the default is 3).

If a mistake is made on a check-in, the server project version can be rolled back using the

MultiUser Administration application. In addition, I’ve seen a few times where the server project

gets locked, and I’ve had to go into the Administration application to unlock or delete a local

session.

This tool is very useful for managing all your projects. You will also want to occasionally export

and archive a local session consistent with the server project for an extra layer of backup since

the server projects or local session project types cannot be archived like a normal TIA Portal

project; the export can be made through TIA Portal in your local session project list.


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 McDonald’s 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:

Find the approximate prices from a McDonald’s 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.

Whopper

Combo

Whopper

Dbl Combo

Whopper Jr

Combo

Whopper

Fries

Drink

Cancel Last

New

Order

Total/Tax/

Optional

Fig. 15-195


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:

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.

Whopper

Burger

Fries

Onion R

Chicken

Wh Cmb

1

3

0

2

0

2 $17.31

Cancel Last

Reset

Order ToGo

Price of Whop Cmbo

Price of Whopper

Price of Burger

Price of Fries

Price of Onion Rings

Price of Chicken

Fig. 15-196

Fig. 15-197


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 clock’s hand.

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?

Fig. 15-198


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:

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:

Fig. 15-17

All Data, No Information


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.


The following must be set up to get the PID program to run properly with the HMI simulate

mode:

Click on the SetPG/PC Interface box above:

We are going to use the Siemens program TIA Portal V14 in order to run the program given for

the ball-in-tube lab. This program will be used to download the PLC program but not the HMI

program.

Choose the third of the Broadcom choices. Click OK.


This allows the Siemens program to run the HMI program in simulate mode. Then download the

program to the PLC. Do not download the HMI program since we do not have the HMI to

download to.

Then click on the HMI’s Screen, Screen_1. Notice the Start Simulation button turn blue. It now

allows the student to run the HMI via simulation mode from the screen of the pc.

We need to find the variables that need to be written to the historical data. Click on Laser Input

and get the tag Laser_Percent. This tag is one to be written to the historical data logger.


Next, go to the Historical data tag under HMI tags. Set the variables from the HMI screen above

that are to be saved. Fill in the appropriate fields and start the historical logger. This circular file

will contain the data from the analog data saved. Then run the program and run the Historical

data logger. It is a circular file and will wrap around after the table fills up.

chapter 15 human machine interface - utoledo …wevans/chap15_s.pdf · chapter 15 human machine...

Documents