HMI Lifecycle

1. HMI Lifecycle Bridget Fitzpatrick Ian Nimmo

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

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

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

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

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

8. 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?

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

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

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

12. Issues • Split of information across the Philosophy and Style Guide tends to vary by user.

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

14. 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?

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

16. 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?

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

18. 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, • Processmodels, • Other OPC packages (e.g. tank farm levels), • Alarm rationalization information, etc.

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

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

21. 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. 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?

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

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

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

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