Emerson’s Aaron Crews, Molly Firkins, and Jessica Graham presented, “Rules” for Designing Optimal Operator Displays at the 2012 Emerson Exchange. Their abstract:
“How can I design displays in the right way?” No matter whether we are creating, migrating or optimizing operator displays, we need to provide Operators with all the relevant information to perform his job. This workshop will provide a framework for you to follow when designing graphics. We will discuss the methodology on how to design your Operator environment and share details of which dynamos are appropriate for different levels of displays. Focusing on the needs of your Operators will allow for an environment that allows them to react to the demands of their process.
Molly opened by discussing the importance of graphics design to convey information, data, or knowledge. She showed example of sports scoreboards in baseball and football in how they convey the state of the game in a concise way.
Modern scoreboards have added videos, advertisements, and other information that begin to clutter the basic purpose of the scoreboard. Molly used this as an analogy for the importance of simplicity in the design of operator graphics. The focus should be on design for purpose. What is the important information to convey?
For operators it is to provide current state, history trends, alarms and events. Aaron came up next to discuss the process of developing logical displays. Where do you begin? Start with I/O counts, control loops, one graphic per screen, copying existing graphics from legacy system? How do you make navigation intuitive?
Aaron advised to begin with a plant asset hierarchy, group controls per the hierarchy, group assets into operator span of control, map hierarchy to console layout, and use the hierarchy to aid in the navigation. Keep the P&IDs out of the operator display discussions. Start by asking the operators about their mental models of the process. How do they visualize it? This provides the basis for intuitive navigation. Then aggregate the equipment in units and units into areas.
In DeltaV, these logical groupings go into equipment modules. It’s absolutely key that you don’t separate the design of the control strategies from the graphics. They must be aligned logically so you’re not hacking graphics together using workarounds. As a project engineer for many years with lots of experience. Aaron was emphatic about this point. It is very difficult since project schedules are tight and the natural desire is to separate tasks. The project scope must include time for this upfront design to logically match control strategies with operator graphics design.
Next, map this hierarchy back to the operator console layout–overview (level 1), unit process (level 2), and equipment (level 3). Level 3 graphics are for troubleshooting, specialized tasks, and non-normal conditions. Level 2 displays may be the quad-head displays showing units, close circuit TV, and other screens to provide a view of the current plant operating state.
This 3-level navigation means the operators are two clicks away from troubleshooting to the process overview. Don’t overload the operator with too many screens. As a project engineer, you must keep asking why to maintain a simplified design. You must also consider information outside the control system such as standard operating procedures, full-time trends, and video feeds.
Simple tabbed navigations can help quickly navigate to fit the mental model the operators have of their plant. Aaron noted to use equipment modules to control equipment operating states and implement conditional alarming to keep what the operator sees relevant to the operating state of the equipment.
Jessica next came up and began by discussing dynamo creation. Start by analyzing who will use the graphics and what are their primary motivations for their use. These groups may include operators, supervisors, maintenance technicians, and plant engineers to name a few. Next ask what are the plant’s current work processes. What does the plant currently have and how are they used–if at all. If not used, they can be removed. What tasks are “painful” that could be streamlined? What clutter exists in current displays that are not regularly used?
Typical display types include overviews, schematic type process displays, task-based process displays, and supporting displays. Think of Google maps as a schematic display type–they are good if you know the area. Task-based views are when Google maps provides turn by turn directions. Zooming the map out can present too much detail and become confusing.
In DeltaV, the dynamo set provides 90% of what most operator graphics designs require. For the parts that require customizations, ask the questions about if it’s really needed or useful, what value it adds, and if there is another way to accomplish the task. Some customizations may include lockout flags and fast links to AMS screens.