lifecycle c

8/10/2019 Lifecycle c

1/26

HMI Lifecycle

Bridget Fitzpatrick

Ian Nimmo


2/26


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.


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.


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.


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.


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/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?


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.


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.


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


12/26

Issues

Split of information across the

Philosophy and Style Guide tends

to vary by user.


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.


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?


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?


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?


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.


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.


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


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.


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.


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?


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.


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.


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.


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.

lifecycle c

Documents