Everything else on this site is about finding faults in equipment and networks. This one is about a fault in the thing you use to look for faults.
A building automation graphic is a rendering of what the front end believes. When that belief is wrong — because a binding broke, a device went offline, or a gateway stopped updating — most graphics show no indication whatsoever. They display the last value they received, in exactly the same font and colour as live data, indefinitely.
Three ways a graphic lies
Stale data from a dead point
The most common and the most dangerous, because it is completely silent. The point stopped updating, the last good value persists, and every operator who looks at that screen believes it is current. There is no error, no colour change, no timestamp — just a number that stopped being true at some point nobody can identify.
A binding pointed at the wrong thing
The graphic updates perfectly and displays the wrong point. Usually created by duplicating a graphic for a similar unit and missing one reference during the retarget. It is impossible to detect by looking at the screen, because everything about it appears healthy.
Command shown as if it were reality
The graphic displays what was commanded rather than what the equipment is actually doing. The fan shows running because the BAS told it to run. Whether it is running is a different point — status, current, or differential pressure — that the graphic may not show at all.
Designing graphics that fail visibly
The fix in all three cases is the same principle: the graphic should be capable of expressing uncertainty. Most aren't, because nobody asked them to.
Show data age, or at least flag it
Most platforms can expose a point's status or last-update time. Use it. A value that has not refreshed within an expected window should look different — greyed, struck through, or annotated. The operator does not need a precise timestamp on every point. They need to be able to tell live data from a fossil.
Show command and feedback together
Wherever both exist, display both. A fan symbol driven only by the command point tells you what was asked for. Command alongside status tells you whether it happened — and the gap between them is one of the highest-value pieces of information on the whole screen.
| Command | Feedback | What the graphic should convey |
|---|---|---|
| On | Running | Normal |
| On | Not running | Fault — this is the one that matters |
| Off | Running | Fault — something else is controlling it |
| Off | Not running | Normal |
| Any | No data | Unknown — and it must look different from all of the above |
Give “unknown” its own appearance
Most graphics have two visual states: normal and alarm. Add a third for unknown. It does not need to be dramatic — grey is ideal, precisely because it reads as absence rather than urgency. What matters is that a technician glancing at the screen can tell the difference between this is fine and I have no idea whether this is fine.
Reserve colour for meaning
A graphic where everything is colourful communicates nothing, because there is no contrast to carry information. Using a restrained palette for normal operation and reserving saturated colour for genuine abnormality is a well-established practice in control room design, and it applies just as well to a mechanical floor plan.
How to audit graphics you inherited
- Pick a device you know is offline and look at its graphic. Whatever you see is what every offline device looks like on this system. If it looks normal, you have found a systemic problem, not a one-off.
- Cross-check a handful of values against the source. Read the point directly from the controller and compare it to the graphic. Mismatches indicate binding errors.
- Look for command-only displays. Any equipment symbol driven purely by a command point is showing intent, not reality.
- Check duplicated graphics carefully. Where one screen was copied for several similar units, at least one reference usually didn't get retargeted.
Why this matters more than it looks
The front end is where nearly every troubleshooting session begins. If it can silently present stale or wrong data as current fact, then every investigation that starts there begins from a premise nobody verified.
That is the whole argument for not troubleshooting from the front end — but it is a much easier argument to win if the graphic is honest about what it does and doesn't know. A screen that says unknown when it means unknown sends the technician to the right layer immediately, instead of sending them to chase a value that stopped being real last month.
Go deeper
This is the same method, applied to protocols
Drives, sensors and sequences are all instances of one bigger problem: working out which layer is actually broken when the front end and reality disagree. That's what the book is about — BACnet, Modbus, LonWorks, OPC UA, gateways, and the diagnostic method that works across all of them.
Get BAS Communication — A Field ReferenceFound a wrong number or a broken link? Tell me and I’ll fix it.