Download - Lifecycle c
-
8/10/2019 Lifecycle c
1/26
HMI Lifecycle
Bridget Fitzpatrick
Ian Nimmo
-
8/10/2019 Lifecycle c
2/26
-
8/10/2019 Lifecycle c
3/26
HMI Philosophy
The philosophy is a comprehensivedocument that provides best practiceguidance for the establishment and
maintenance of the HMI. ThePhilosophy document should provide aroad map that documents the designbasis, such that new users can grasp theunderlying principles and technicalrationales, allowing the HMI to bemaintained successfully over time.
The HMI Philosophy document providesan overview of the design basis for theHMI and provides insight into the
rationale behind the design decisions. Itdoes not go into implementationspecifics, which are covered in the HMIStyle Guide.
-
8/10/2019 Lifecycle c
4/26
HMI Philosophy
General PrinciplesThe Philosophyshould describe the designprinciples that support:
alignment with the humanpsychological capabilities, includingmental capacity and sensory limits,models for human interaction, and the
effect of stress and sensory overload, alignment with physiological limits,
such as color blindness, limitedperipheral perception, and the effectof the overall control console design,
provides interaction devices that aresensitive to human errors anddeficiencies.
-
8/10/2019 Lifecycle c
5/26
HMI Philosophy
Scope - The HMI Philosophy
specifies the scope of the varied
parts of the HMI and the HMI as awhole. 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.
-
8/10/2019 Lifecycle c
6/26
HMI Philosophy
PurposeThe Philosophy document spells outthe specific design purpose for the HMI. Thispurpose includes the operating graphics, as wellas graphics to support maintenance, testing,
training and engineering support, as long as theyreside within the control system. This technicalreport does not cover the entire scope of supportof, 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.
-
8/10/2019 Lifecycle c
7/26
HMI Philosophy
Design Work Processes - ThePhilosophy should spell out the HMIwork processes, detailing the
personnel involved, reviewrequirements and the general workflow for: design, implementation,training, testing, commissioning andmaintenance 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 FormalReviews, etc.
-
8/10/2019 Lifecycle c
8/26
HMI Philosophy
Framework: Research in the areaof effective operator graphics is
underway and will continue in thefuture, the documentation mustbe established in a manner thatallows for continual
improvement. Are we covering:
Tablet PCs and things like handhelds(example Intellatrac)?
Wearable computers? Advanced advice and state
detection systems?
-
8/10/2019 Lifecycle c
9/26
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 statusshould 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 andvaried, to support an intuitive fast navigation scheme.
-
8/10/2019 Lifecycle c
10/26
Style Guide
The HMI Style Guide takes the Philosophyone step closer to implementation,detailing the specifics of the presentationand methods of interacting with the objectson the displays, as well as an overall view ofthe operating console itself.
The presentation specifics should includethe 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 statusrepresentation),
dynamic process values,
navigation schemes embedded in thedisplays,
menu and tool bars.
-
8/10/2019 Lifecycle c
11/26
Style Guide
For all of the major objects, the HMIStyle guide will contain a description ofthe objects behavior, presentation
specifics (size, color, etc.) andillustrations of each of the possiblestates.
The overall console section should
include: support for trending,
interaction with third-party applications,
navigation schemes not embedded in thedisplays (including context shortcut
menus),
windows management,
input methods (keyboard, mouse, etc.).
-
8/10/2019 Lifecycle c
12/26
Issues
Split of information across the
Philosophy and Style Guide tends
to vary by user.
-
8/10/2019 Lifecycle c
13/26
HMI Toolkit
As the name implies, the HMI
Toolkit is the collection of all of
the design elements for thedisplays (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 orSCADA system in use.
-
8/10/2019 Lifecycle c
14/26
Issues for Toolkit
Inclusion in the life cycle since it exists,
but also to provide some guidance on
how to manage toolkits acrossmultiple 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?
-
8/10/2019 Lifecycle c
15/26
User Requirements
All aspects of the HMI is intendedfor a specific set of purposes
(primary and secondary) and a setof users (again primary andsecondary). The UserRequirements activity develops
and documents the specific needsof the users. This is an input tothe design stage.
Do we want to get into methodsfor developing UserRequirements?
-
8/10/2019 Lifecycle c
16/26
Task Analysis and
Functional Requirements Once the basic user requirements are defined, the
actual tasks to be performed by the users arecaptured, reviewed and potentially optimized. Theterminology in use by the user and the user model ofthe process is also documented in this process. Theneed for online or offline user support should also beevaluated. The functional HMI support needs arecaptured in this process.
Different techniques are available to do this analysis.Perhaps the most thorough routinely used techniqueis Hierarchical Task Analysis. Timeline analysis is a
charting technique that records events versus time.Link Analysis demonstrates the frequency of linkagebetween tasks. It is useful for streamlining tasks andcan also be used to identify how often a user has tonavigate from one display to another.
Other more advanced techniques such AbstractionHierarchical Analysis, Cognitive Work Analysis and
Ecological Analysis exist but may require HumanFactor expertise to complete them.
Do we want Appendices that cover these methods?
-
8/10/2019 Lifecycle c
17/26
Navigation
Navigation design is one of the mostcritical aspects of HMI design, since aneffective and intuitive navigation
scheme can directly impact the speed ofoperator intervention.
The key design basics for navigation areconsistency 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.
-
8/10/2019 Lifecycle c
18/26
Navigation
There are other navigation methods toconsider, including: Keyboard buttons,
Menu buttons, Toolbar buttons,
Context shortcut menus.
Integration of Third Party Interfaces to theHMI 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.
-
8/10/2019 Lifecycle c
19/26
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 toavoid loss of navigation or limit its
scope
Concept of providing a manual
method on loss of navigation
-
8/10/2019 Lifecycle c
20/26
Design
The HMI should be conceptually designed withthe known information and then reviewed by across-functional team which includes the primaryand secondary users (generally operations and
support staff). This is an iterative process knownas prototype development. It is relativelycommon to perform a first layout review wherethe basic content is shown, followed by a finalreview with all information and interactiondevices completed.
An effective HMI is achieved by refining the userrequirements and task and functionalspecifications in an iterative process, ensuringthat the final HMI supports the user models andneeds. The review cycle (L) is shown as a parallelprocess to design, implement and test toemphasize the ongoing nature of this part of theHMI lifecycle.
Often a specific validation and documentationplan will be required for this stage of the lifecycle.
-
8/10/2019 Lifecycle c
21/26
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.
-
8/10/2019 Lifecycle c
22/26
Test
Formal testing, is also commonly done offline orin a simulated environment. This is the formaltesting against user needs and task/functionalrequirements. Ideally, this is performed with real
operators performing relevant tasks with thesystem they will be operating, thereby affordingobservation of issues with the interface of whicheven the operators might not be aware. Ifavailable, simulated upsets and other abnormalconditions can test the effectiveness of the HMIunder all modes of operation.
Any implementation issues that result in redesignare most effectively handled at this point in theprocess and therefore minimize the cost andeffort related to re-work on graphics that havealready been commissioned.
Often a specific validation and documentationplan will be required for this stage of the lifecycle.
Advice on failure modes to test?
-
8/10/2019 Lifecycle c
23/26
Commission
Commissioning is basically a final
testing with the process devices
connected. The level of onlinetesting 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.
-
8/10/2019 Lifecycle c
24/26
Train
Training is often completed inparallel to commissioning, where alloperators are trained prior to usingthe new HMI, but not all operatorsare trained prior to the start ofcommissioning. The relative detailand documentation of the training
step will vary with the complexity ofthe HMI and the base requirementsof the process. Often a specificvalidation and documentation plan
will be required for this stage of thelifecycle.
-
8/10/2019 Lifecycle c
25/26
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 requiredfor this stage of the lifecycle.
-
8/10/2019 Lifecycle c
26/26
Validation, Documentation,
Management of Change
Validation, Documentation, and
Management of Change are an
activities that may be mandatedto be performed in a particular
manner, depending on the
application. It is a continuous
effort during the life cycle of an
HMI.