The display hierarchy, and why level one is usually missing
Most control systems have detail displays and unit displays. The overview that tells an operator whether the whole plant is normal frequently does not exist.
A display hierarchy organises graphics into levels, each with a distinct job. The convention that has settled in the industry uses four, and most real systems implement two of them well, one badly and one not at all.
The four levels
Level one is the plant or area overview. It answers a single question: is everything normal? It shows a small number of aggregate indications covering the whole area of responsibility and is designed to be readable from across the room.
Level two is the unit display. It covers one process unit in enough detail for routine monitoring and normal control actions, and it is where the operator spends most of their time.
Checklists and well-designed displays reduce cognitive demand by moving memory tasks into the work environment. A related reference is available at https://www.monitask.com/business-glossary/cognitive-offloading/.
Additional industry context is available in the ISA-101 HMI standards.
Level three is the detail display. It covers one system or one piece of equipment with full instrumentation, used for diagnosis and for less common operations.
Level four is the support display: trends, alarm detail, procedures, documentation, diagnostics.
Most sites have level two and three in abundance. The overview that would tell an operator at a glance that something is wrong three units away frequently does not exist, so they find out from the alarm list.
What a level one display actually shows
The temptation is to build the overview by shrinking a unit display, which produces an unreadable version of level two.
An effective overview shows aggregated condition rather than detail: a small number of key performance indications per unit, presented as deviation indicators with normal bands, plus a summary of abnormal conditions by area.
The design test is whether an operator standing three metres away can tell which unit needs attention. That constrains the design to a handful of large, well-separated indications, which is precisely what makes it useful.
The navigation problem
A hierarchy is only usable if moving between levels is fast and predictable. The common failure is a navigation scheme that requires the operator to know which display a given item lives on.
The two mechanisms that work together are hierarchical navigation — every display has an obvious route up to its parent and down to its children — and direct navigation from an item to its detail, so that selecting a pump on a unit display opens the pump's detail display.
Alarm-driven navigation is the third and most important under pressure: selecting an alarm should bring up the relevant display with the item indicated. An operator diagnosing an upset should never be navigating by menu.
How many displays is too many
Display counts grow the same way alarm counts do. A plant with four hundred graphics for one console has a navigation problem regardless of how good each individual display is, because no operator can hold four hundred locations in memory.
The remedy is consolidation rather than better menus. Many displays exist because a specific project needed a view and built one; several of them cover the same equipment from slightly different angles.
A display audit — listing every graphic, its purpose, and its usage frequency where the system logs that — typically finds a substantial proportion that are never opened.
Consistency across the hierarchy
The same equipment should look the same on every display it appears on. Where a pump is drawn one way on the unit display and another on the detail display, the operator is doing translation work for no reason.
This requires a component library and the discipline to use it. It is the sort of thing that is straightforward at the start of a project and nearly impossible to retrofit, which is an argument for establishing it early even when the immediate benefit is unclear.
Level one for the supervisor as well
A well-built overview serves people beyond the console operator: the shift supervisor, the process engineer, the plant manager who wants to know how the day is going.
Making it available outside the control room — on a read-only display in an office, or on a large screen in the control room — has a secondary effect worth noting: it creates an audience for the display's accuracy, which tends to keep it maintained.
Displays for abnormal operation
Most graphics are designed for normal running. The situations where display quality matters most are startup, shutdown, and abnormal events, and these are frequently served by the same screens.
Purpose-built displays for characteristic abnormal scenarios — a startup sequence display, a display for the most common upset — are unusual and highly valued where they exist. They can present exactly the information relevant to that situation, in the order it is needed, without the operator assembling it from three graphics.
Maintaining the hierarchy
Hierarchies decay through addition. A project adds a display, places it somewhere convenient, and the structure erodes.
The control is the same as everywhere else: display changes go through management of change, new displays are placed deliberately within the hierarchy, and someone owns the structure. Without that, a well-designed hierarchy becomes a flat collection of four hundred graphics within a decade.
Assigning displays to screens
On a multi-screen console, the hierarchy interacts with the physical arrangement. A common and effective convention dedicates one screen permanently to the alarm summary, one to the area overview, and leaves the remainder as working screens for unit and detail displays.
The benefit is that the two displays answering the question 'is anything wrong' are always visible without action, and the operator's navigation is confined to the working screens.
This only holds if it is a convention that operators follow. Where each operator arranges screens to personal preference, a supervisor or a relief operator arriving at the console has to reorient before they can do anything, which is a real cost during an event.
Auditing the display set
Display counts grow through projects and are almost never reduced. An audit lists every graphic with its purpose, the equipment it covers, and — where the system logs it — how often it is actually opened.
The characteristic finding is that a substantial proportion of displays are opened rarely or never. Some are obsolete, covering equipment that has been removed. Some duplicate a view available elsewhere. Some were built for a commissioning activity years ago.
Removing them is low risk if usage data supports the decision, and it improves navigation for everything that remains. It also reduces the maintenance burden, because every display is a thing that has to be updated when the plant changes.
The hierarchy has to survive projects
A capital project adding a new unit will produce displays, and the path of least resistance is to add them wherever is convenient and link them from a menu.
Specifying the hierarchy position in the project scope — this unit sits under this area overview, with these navigation links — is a small requirement that prevents the structure fragmenting one project at a time.
Overviews for areas outside the console
Level one displays are designed for the console operator and are frequently useful to people elsewhere: field operators at local stations, maintenance planners, the shift supervisor.
Providing read-only access outside the control room is usually straightforward and has a secondary benefit. A display seen by more people is a display whose errors get reported, which counteracts the tendency for graphics to drift out of alignment with the plant.
The controls needed are the ordinary ones — read-only access, no control capability, and clarity about what the viewer is and is not seeing — and they are worth establishing rather than allowing informal arrangements to develop.