HMI Lifecycle
Bridget Fitzpatrick
Ian Nimmo
HMI Philosophy
• The philosophy is a comprehensive
document that provides best practice
guidance for the establishment and
maintenance of the HMI. The
Philosophy document should provide a
road map that documents the design
basis, such that new users can grasp the
underlying principles and technical
rationales, allowing the HMI to be
maintained successfully over time.
• The HMI Philosophy document provides
an overview of the design basis for the
HMI and provides insight into the
rationale behind the design decisions. It
does not go into implementation
specifics, which are covered in the HMI
Style Guide.
HMI Philosophy
• General Principles – The Philosophy
should describe the design
principles that support:
– alignment with the human
psychological capabilities, including
mental capacity and sensory limits,
models for human interaction, and the
effect of stress and sensory overload,
– alignment with physiological limits,
such as color blindness, limited
peripheral perception, and the effect
of the overall control console design,
– provides interaction devices that are
sensitive to human errors and
deficiencies.
HMI Philosophy
• Scope - The HMI Philosophy
specifies the scope of the varied
parts of the HMI and the HMI as a
whole. Specific design decisions
allow the HMI to be an effective
tool for the safe and efficient
control of the process, in all
possible modes of operation,
both normal and abnormal.
HMI Philosophy
• Purpose – The Philosophy document spells out
the specific design purpose for the HMI. This
purpose includes the operating graphics, as well
as graphics to support maintenance, testing,
training and engineering support, as long as they
reside within the control system. This technical
report does not cover the entire scope of support
of, for example, operator training simulators.
• The purpose should spell out HMI support for:
– operations at optimal conditions managing
multiple constraints,
– early detection, diagnosis, and proper response to
abnormal situations,
– operation during upset and shutdown conditions,
– instrument maintenance activities,
– shutdown system testing,
– operator training,
– engineering troubleshooting.
HMI Philosophy
• Design Work Processes - The
Philosophy should spell out the HMI
work processes, detailing the
personnel involved, review
requirements and the general work
flow for: design, implementation,
training, testing, commissioning and
maintenance processes.
– Should we discuss:
•
•
•
•
User Security Model
Designing for Redundancy
Backups and Recovery
Varied Methods of HMI Development
– From existing graphics, from P&ID, from
sketches?
– Continuously iterative, Set # of Formal
Reviews, etc.
HMI Philosophy
• Framework: Research in the area
of effective operator graphics is
underway and will continue in the
future, the documentation must
be established in a manner that
allows for continual
improvement.
– Are we covering:
– Tablet PCs and things like handhelds
(example Intellatrac)?
– Wearable computers?
– Advanced advice and state
detection systems?
General Principles
•
•
•
•
•
•
•
•
•
•
•
Simplicity in the design of graphics is important. Visual
clutter and unneeded data are avoided for clarity.
Displays should be consistent in their presentation methods
for similar information.
Displays should be designed to support user situational
awareness.
The prominence of the appearance of a screen object is
associated with its importance, creating a salience hierarchy
in the design and presentation decisions.
Displays should be designed with timeliness and feedback
taken into careful consideration. Feedback on completion of
action and/or of failure to complete action should be
provided.
User interaction techniques should be clear and consistent.
Error tolerance in user interaction for critical devices should
be included, with simple notification of error and effective
methods for recovery.
Status of field instrumentation and communication status
should be shown clearly and consistently.
Display content should support all types of tasks and
activities required of the operator.
Symbols and process arrangement are depicted in a simple,
meaningful, unambiguous, and consistent manner.
Navigation and layout schemes should be consistent and
varied, to support an intuitive fast navigation scheme.
Style Guide
• The HMI Style Guide takes the Philosophy
one step closer to implementation,
detailing the specifics of the presentation
and methods of interacting with the objects
on the displays, as well as an overall view of
the operating console itself.
• The presentation specifics should include
the use of:
–
–
–
–
–
static elements (for process representation),
static text,
lines and limitations on animation of lines,
sound (both for alarms and any other use),
dynamic symbols (for equipment status
representation),
– dynamic process values,
– navigation schemes embedded in the
displays,
– menu and tool bars.
Style Guide
• For all of the major objects, the HMI
Style guide will contain a description of
the objects behavior, presentation
specifics (size, color, etc.) and
illustrations of each of the possible
states.
• The overall console section should
include:
– support for trending,
– interaction with third-party applications,
– navigation schemes not embedded in the
displays (including context shortcut
menus),
– windows management,
– input methods (keyboard, mouse, etc.).
Issues
• Split of information across the
Philosophy and Style Guide tends
to vary by user.
HMI Toolkit
• As the name implies, the HMI
Toolkit is the collection of all of
the design elements for the
displays (all of the static and
dynamic objects) and the related
operating console. The design
specifics are contained in the HMI
Style Guide. The toolkit is a
separate element, since one set
will exists for each control or
SCADA system in use.
Issues for Toolkit
• Inclusion in the life cycle since it exists,
but also to provide some guidance on
how to manage toolkits across
multiple releases, etc.
• Advice on level of testing required?
• One at each major release
• One for each operating area
• To allow for different patch levels
• To limit scope of loss if an error is made
– What else?
User Requirements
• All aspects of the HMI is intended
for a specific set of purposes
(primary and secondary) and a set
of users (again primary and
secondary). The User
Requirements activity develops
and documents the specific needs
of the users. This is an input to
the design stage.
• Do we want to get into methods
for developing User
Requirements?
Task Analysis and
Functional Requirements
• Once the basic user requirements are defined, the
actual tasks to be performed by the users are
captured, reviewed and potentially optimized. The
terminology in use by the user and the user model of
the process is also documented in this process. The
need for online or offline user support should also be
evaluated. The functional HMI support needs are
captured in this process.
• Different techniques are available to do this analysis.
Perhaps the most thorough routinely used technique
is Hierarchical Task Analysis. Timeline analysis is a
charting technique that records events versus time.
Link Analysis demonstrates the frequency of linkage
between tasks. It is useful for streamlining tasks and
can also be used to identify how often a user has to
navigate from one display to another.
• Other more advanced techniques such Abstraction
Hierarchical Analysis, Cognitive Work Analysis and
Ecological Analysis exist but may require Human
Factor expertise to complete them.
• Do we want Appendices that cover these methods?
Navigation
• Navigation design is one of the most
critical aspects of HMI design, since an
effective and intuitive navigation
scheme can directly impact the speed of
operator intervention.
• The key design basics for navigation are
consistency and intuitiveness.
• The navigation scheme includes
navigation from:
– Alarm summary to point detail or display,
– Display to faceplate or interaction zone,
point detail, trending, alarm history,
change history, and other third party
devices,
– Display to Display,
– Display to Detailed Display and vice versa,
– Display to Overview and vice versa.
Navigation
• There are other navigation methods to
consider, including:
–
–
–
–
Keyboard buttons,
Menu buttons,
Toolbar buttons,
Context shortcut menus.
• Integration of Third Party Interfaces to the
HMI also includes navigation methods.
Common third party interfaces include:
–
–
–
–
–
–
Advanced Process Control systems,
Historians,
Trend packages,
Process models,
Other OPC packages (e.g. tank farm levels),
Alarm rationalization information, etc.
Navigation Issues
• Do we want to talk about best
practices in Implementation?
– Symbology
– Use of Microsoft/Web Standards
– Scripting Error Messages
– Use of different technologies to
avoid loss of navigation or limit its
scope
– Concept of providing a manual
method on loss of navigation
Design
• The HMI should be conceptually designed with
the known information and then reviewed by a
cross-functional team which includes the primary
and secondary users (generally operations and
support staff). This is an iterative process known
as prototype development. It is relatively
common to perform a first “layout” review where
the basic content is shown, followed by a final
review with all information and interaction
devices completed.
• An effective HMI is achieved by refining the user
requirements and task and functional
specifications in an iterative process, ensuring
that the final HMI supports the user models and
needs. The review cycle (L) is shown as a parallel
process to design, implement and test to
emphasize the ongoing nature of this part of the
HMI lifecycle.
• Often a specific validation and documentation
plan will be required for this stage of the lifecycle.
Implementation
• Implementation is the
construction of the HMI in the
actual control system interface.
The HMI is built and tested by the
developer offline. Often a
specific validation and
documentation plan will be
required for this stage of the
lifecycle.
Test
• Formal testing, is also commonly done offline or
in a simulated environment. This is the formal
testing against user needs and task/functional
requirements. Ideally, this is performed with real
operators performing relevant tasks with the
system they will be operating, thereby affording
observation of issues with the interface of which
even the operators might not be aware. If
available, simulated upsets and other abnormal
conditions can test the effectiveness of the HMI
under all modes of operation.
• Any implementation issues that result in redesign
are most effectively handled at this point in the
process and therefore minimize the cost and
effort related to re-work on graphics that have
already been commissioned.
• Often a specific validation and documentation
plan will be required for this stage of the lifecycle.
• Advice on failure modes to test?
Commission
• Commissioning is basically a final
testing with the process devices
connected. The level of online
testing will likely vary with the
level of customization and the
relative acceptance level of the
toolkit objects. Often a specific
validation and documentation
plan will be required for this stage
of the lifecycle.
Train
• Training is often completed in
parallel to commissioning, where all
operators are trained prior to using
the new HMI, but not all operators
are trained prior to the start of
commissioning. The relative detail
and documentation of the training
step will vary with the complexity of
the HMI and the base requirements
of the process. Often a specific
validation and documentation plan
will be required for this stage of the
lifecycle.
Maintain
• Once the HMI is in service, any
changes to the HMI must be
handled in a controlled manner.
The process must not be
cumbersome, in order to not
hamper continuous
improvement.
• Often a specific validation,
documentation and management
of change plan will be required
for this stage of the lifecycle.
Validation, Documentation,
Management of Change
• Validation, Documentation, and
Management of Change are an
activities that may be mandated
to be performed in a particular
manner, depending on the
application. It is a continuous
effort during the life cycle of an
HMI.