Five key considerations for improving HMI graphics during a control system migration
When taking on a DCS migration project, it’s important to create a well-thought-out strategy for handling HMI graphics. Some basic planning can avoid confused operators and lost opportunities for improvements.
Control system migration projects are complex and filled with elements that can derail the scope, schedule, and budget when not handled properly. One of the highest risk areas is making a successful transition for the HMI (human-machine interface) graphics. The graphics that appear on operators’ HMI screens are an essential part of daily operations and the most tangible aspect of the control system to many operators because those graphics are their point of interaction with the system. There are many factors essential to creating an effective HMI experience such as layout, navigation, color usage, text and numerical formatting, faceplate design, and so forth. Over the years, control system capabilities have evolved to simplify implementation of modern HMI-related best practices. However, the process of planning and executing graphics conversions or redesigns as part of a control system migration remains a struggle for many organizations.
Specific to control system migrations, there are numerous graphics-related factors that present challenges to the design, engineering, project management, and long-term operation of the new control system. Five key graphics considerations that must be addressed during various stages of the migration project are:
- Making the graphics conversion methodology decision
- Defining graphics needs
- Performing thorough back engineering
- Involving operations throughout the project, and
- Clearly defining the review and approval process.
This article examines each of these considerations in more detail, explains why they are important, and suggests ways to proactively manage these areas to optimize your graphics for a seamless transition to your new control system.
Making the graphics conversion methodology decision
Hopefully before your migration project even begins or at least in the early stages of the front-end engineering and design (FEED) effort, a decision must be made regarding the methodology that will be used to convert the graphics to the new control system. At the most basic level, the primary decision is between keeping the existing graphic designs or redesigning the graphics from scratch. This is usually not a straightforward decision, even though it should be. From my perspective, if you do not take advantage of the opportunity to redesign your graphics and leverage the capabilities of the new system, then you have diminished the benefits of having a modern control system.
Many organizations hesitate to redesign graphics because they are concerned that too many changes with a new control system will be difficult for operators. As a result, they often keep the graphics as near to the existing screens as possible to minimize the transition challenges for the operators. The weaknesses in this approach are two-fold. First, they fail to take advantage of the newer capabilities and best practices available in the new control systems, which are designed to improve the effectiveness of graphics. Second, they fail to eliminate the problems with their existing graphics that may have accumulated over the years. These can include items such as screens that are too busy, use of colors that make abnormal situations difficult to recognize, or simply overdoing it with too many process graphics.
Once a decision is made as to whether basic designs will change, a secondary decision must be made regarding how to make the transition. For instance, if you keep your existing design, will you rebuild your graphics from scratch in the new system mimicking the graphics in the old system or will you use conversion tools? Vendors and third-party service providers offer many conversion tools, but some are better than others. The poorer examples can leave you with graphics that are only partially converted. This can translate to a significant time investment troubleshooting and identifying the scope of dynamic functionality that needs to be added so they work as intended.
If you decide to start from scratch and redesign your graphics, you will still want to invest time to understand the functionality of the old graphics as a starting point. It is also important to understand the capabilities of the new system, so that you can take full advantage of those features in your new design. Equally important is involving operations in the design process to improve the usability of the graphics and build support for new graphics. Changes might be subtle or might result in a total revamp. For example, many older style graphics were designed around P&IDs (piping and instrumentation diagrams), grouping equipment based on those layouts. Today, process graphics are generally designed around functionality rather than physical layout and screens reflect that.
Defining graphics needs
A comprehensive graphics design guide is a fundamental requirement to support a control system migration, and should be created early in the migration project process, if not prior to the project. The guide provides direction on display-related topics such as types of displays, screen layouts, navigation, color usage, equipment and instrument symbols, faceplates, alarms, and general presentation of text and numerical information. It does not have to be control system specific, so it is often created in advance of the project or at the FEED stage. One benefit to this is that it can then be included with any service bid packages, so that bidders have some idea of the design approach for graphics, which can improve bid accuracy.
The graphics design guide is a documented roadmap for establishing consistency. As questions arise during the development process, a thorough design guide should be able to provide answers. It forms a basis for building graphics and eliminates many of the misinterpretations that can occur when verbal instructions are used. In addition, a complete graphics design guide can prevent differences of opinion from impacting the project schedule and cost. Since some aesthetic elements are involved, it is common to see differences between engineers, operators, and even various operating shifts. A guide can address these differences up front, and when others arise later in the project, there is already a master document for resolution.
Another valuable component of work definition is a graphics inventory and complexity spreadsheet, which enables accurate estimating. The first step is to develop complexity definitions, which can be as simple as low, medium, and high complexity designations. The time required to develop each complexity level graphic should then be estimated. For example, an overview graphic in tabular format might be considered a simple graphic that takes an estimated 4 hours to create, while a process graphic with 10 static elements and significant dynamic functionality may be designated as complex requiring 12 hours to create. Finally, each anticipated graphic should be added to the spreadsheet with an associated complexity level and subsequent estimated development time. This will not only give you an estimate basis for in-house funding and project management activities, but if you are planning on having a third-party provide services, it also gives that party an equal bid basis.
Finally, as you go through your development process, it is important to have a progress tracking method. You can start with your graphics inventory and complexity spreadsheet. In addition to the existing name, description, complexity designation, and estimate, you should add columns for each step in your development process. This can vary depending on how you approach the graphics, but I would recommend columns for layout and design, static configuration, dynamic configuration, testing, in review, and approval. As graphics are developed, you have the capability to track their progress by regularly updating the spreadsheet. This will provide insight into overall graphics development progress as well as allow you to evaluate how individual graphics are tracking versus estimate and schedule.
|Search the online Automation Integrator Guide|
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.