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.
Performing thorough back engineering
One of the most difficult things about using existing graphics from older control systems as the design basis for new graphics is accurately estimating the complexity. Often, it is not feasible to go through each graphic in detail during the early stages of a migration project when the estimate is developed, or as part of the bid process. In many older control system graphics, dynamic functionality requires scripting or logic functionality programming. For instance, to change pump colors with run and stop status changes in many legacy control systems requires coding or scripting in some vendor programming language. This background scripting, which can be extensive and complex, is not evident when just looking at the static graphic, or even in performing a surface review of the graphic. While much of this functionality is now easier to configure in newer control systems, the back engineering process can be time consuming.
Back engineering involves reviewing the scripting in older graphics to develop a complete understanding, so that the dynamic functionality can be accurately built into the new screens. Scripting or additional functionality that is not identified during the scoping stage of the project may lead to more configuration effort during project execution than originally planned. If your existing graphics will be the design basis for the new ones, then it is essential that you allocate time at some early stage of the project to do a complete back engineering of the graphics. This will ensure that you fully understand the scope of functionality required in the new system and estimate accordingly.
Involving operations throughout the process
The primary users of graphics are operators, so it is essential that the operations department be actively involved in the graphics design and development process, if the graphics are to be effective. They should be involved from the early stages of the migration project, providing input for the graphics design guide and going on to play a role in the actual design and development. Finally, operators should be central to the graphics testing, review, and approval processes.
The way that organizations involve operations in the process varies greatly. In ideal circumstances, organizations might have an operator, or possibly several, actually design and build graphics. This can improve their practical usability because operators will bring a unique and practical perspective to the process. An added benefit is that it generally speeds time to acceptance by other operators because those responsible for graphics development will help promote acceptance of the new control system to their counterparts. Unfortunately, in many organizations, the time requirements needed for complete graphics development make it impractical to have operators wholly committed to these tasks. When this is the case, an alternative is to have a team of operators who regularly consult with the engineering team developing graphics to provide input for key graphics-related decisions.
As graphics move from development to testing, review, and approval, operations should be centrally involved in all of these efforts. For example, having operators participate in the factory acceptance test is a great way to gain valuable feedback about the operability of your graphics, while also increasing the comfort level of the operators with the new system.
Clearly defining the review and approval process
My experiences as an end-user, system integrator, and vendor have taught me that many times, companies do not have a clear vision or consensus when it comes to graphics. This translates to scope changes, cost overruns, and schedule delays, leading to frustration on everyone’s part. Ask several people and you will likely get a variety of answers regarding what they want to see on the screens. To manage this reality effectively, it is important to have a clearly defined graphics review and approval process that specifies who reviews and approves graphics, when in the process that review takes place, and how much time is allocated to the review and feedback cycle.
One approach that is often employed is to build a few sample graphics and get approval for them, subsequently using them as the templates going ahead. The templates shift major changes to the front-end of the project by allowing for early review of basic items, such as general layout, color usage, and equipment and instrument symbols. This approach also minimizes the replication of issues on individual graphics that will later need to be changed.
It’s never too soon to plan
HMI graphics are a substantial challenge on control system migration projects. The initial decisions of how much to change graphics and whether to use conversion tools or start from scratch are complex. The key driver in the decision process should be determining what approach will give you the most benefits from the new control system, and thoroughly defining graphics needs can help mitigate the risks. This involves complete back engineering of graphics in the old control system to fully understand the existing operating capabilities. It also requires up-front planning using tools like a comprehensive graphics design guide and a graphics inventory and complexity spreadsheet. Involving operations throughout the graphics development process is essential to reducing back-end changes, while also increasing the comfort level and satisfaction with the new system among operators. Finally, clearly defining the graphics review and approval process can prevent individual preferences and ongoing changes from derailing your project.
Daniel Roessler is author of Control System Migrations: A Practical Project Management Handbook (Momentum Press 2013) and an owner of DANR Consulting.
For more information, visit:
Read more about control system migration below.
Subscribe to Process & Advanced Control eNewsletter at www.controleng.com/newsletters
- HMI graphics can be a major element of a larger DCS migration, but can be overshadowed by other concerns.
- Careful functional evaluation can help avoid confusing operators with new screens while gaining functionality of the new control system.
- Planning following these five steps can smooth out the process.