Color can carry a device's live state on top of a diagram whose layout never has to move
Aliases: dynamic state overlays on stable topology · process control display
What it is
Overlay coding places color changes on top of a topology diagram whose node and link positions stay fixed, using color to show a device's current running, energized, flow-direction, isolation, or abnormal state without ever rearranging the geometry itself. The stable structure carries the spatial memory an operator has already built up; the color layer carries "what is happening right now" — the two do different jobs and should not change together.
Why it happens
If the structure itself rearranges in real time as state changes — a branch moving forward when it comes into service, retreating when it goes out — an operator watching the screen has no way to tell whether a visible change came from the process itself or from the layout being recomputed, and comparing two moments in time becomes genuinely hard once those two sources of change are tangled together. Locking the structure to fixed coordinates leaves color as the only thing that changes, turning state difference into a single, clean visual variable an operator can catch at a glance. But color alone cannot carry the full load: color-vision deficiency, ambient lighting, and the limited number of states color can distinguish all bound what it can do on its own, so a dynamic overlay needs redundant channels — text labels, line style, symbols — so that a viewer who cannot rely on color, or a screen under poor viewing conditions, can still read the same state through another channel.
Where it stops holding
A color change often does not represent a directly measured physical flow at all; it represents a state the control logic inferred from valve position and other indirect signals, or simply what a sensor reports — and either the inference or the sensor can be wrong, so color cannot be treated as proof of actual flow. Complex multiphase conditions — mixed gas, liquid, and solid, or flow direction reversing with operating state — resist being captured accurately by a single hue, and forcing one color to summarize them hides the complexity instead of representing it. When a large fraction of the display turns to an abnormal color at once, the channel's original purpose — pulling attention to what is abnormal — gets diluted; if half the screen is red, red no longer points anywhere in particular.
Applying it
Lock the topology's coordinates as a fixed baseline first, then define, for every overlay color, its data source, that data's reliability, and what "unknown" should look like when data is missing or contradictory, and pair every color with a noncolor redundant code such as a text label or line style. Validate specifically against three replayed scenarios — a communication dropout that loses data, sensors reporting contradictory states, and a mode transition before and after — checking that the structure stays completely stable and that what the color represents, a real measurement or an indirect inference, stays honestly distinguishable; if inferred states are rendered visually identical to measured ones, operators will end up treating a guess as a fact.
Related
- Same group: Y3.06.1 Physical connectivity in process diagrams · Y3.06.2 Mental-model-compatible process layout · Y3.06.3 Hidden bypasses in simplified topology
- Nearby: Y3.03 Color and safety coding · Y3.12 Low-saturation high-performance graphics
- Search terms:
overlay coding·dynamic state overlay·high-performance HMI·ASM Consortium guidelines
Cards in the same group
- Y3.06.1A process diagram needs the real plumbing and flow direction, not a tidied-up abstraction of it
- Y3.06.2A schematic should follow how operators actually think about the process, not how a database stores it
- Y3.06.3Simplifying a topology diagram down to the main route can hide the bypass everyone forgets exists