Designing SCADA Trend Displays Operators Can Troubleshoot From
Trend screens that answer the operator's real question during an upset: grouping by loop, choosing scales, and drawing a comms gap as a gap.
Header pressure sagged, the operator pulled up the trend, and all it showed was one pen labeled PT_204 swinging between 40 and 80 on an autoscaled axis. No setpoint, no valve position, no pump run status, no way to tell whether the instrument moved or the process did. That trend wasn't wrong — it just couldn't answer the only question that mattered at 2 a.m.: what moved first?
A trend earns its screen space when it turns a handful of tags into a short cause-and-effect story. Most of the ones I inherit do the opposite: one lonely signal, or twenty unrelated ones crammed onto shared axes. Both are useless when you're closing in on a cause. ISA-101 (Human-Machine Interfaces for Process Automation Systems) devotes a full section to trends for this reason — the display is a diagnostic instrument, not decoration.
Start from the question, not the tag
Don't build a trend because a tag exists. Build it because someone needs to compare behavior over time. Before I pick pens, I write the question the trend has to answer at the top of the display config, in a comment if nowhere else:
- What changed in the minute before this alarm?
- Did the command produce the feedback we expected?
- Is the loop oscillating, or is that just instrument noise?
- Did the upstream condition move before the downstream one?
The tags follow from the question. A trend with twenty lines looks thorough and usually slows you down, because the one relationship that matters is buried under nineteen that don't.
Group by the control loop, not by whatever's nearby
The useful groupings track the equipment or the loop. For a pump I want the command, run feedback, speed or output, discharge and suction pressure, flow, and the trip/permissive status — not "every tag on P-204's faceplate." For a PID loop I want the four signals that let me read the loop's behavior at a glance:
| Pen | Why it's on the trend |
|---|---|
| Process variable | What the loop is actually doing |
| Setpoint | What it's being told to do |
| Controller output (or valve position) | The loop's effort — reveals saturation and windup |
| Mode / equipment state | Auto vs Manual, Running vs Stopped — half of "why didn't it respond" |
Add one or two likely disturbance variables and the alarm limit line if the platform supports it. That's it. Mixing units on one axis is fine — valve percent against header pressure is a genuinely useful pair — but only if the operator can tell at a glance which pen reads which scale. If they can't, you've built a puzzle, not a trend.
Autoscale is for exploring, not for operating
Independent autoscale on every pen is the single fastest way to lie to an operator. A tag jittering ±0.3 barg on sensor noise fills the whole chart and looks like a crisis; a real 2 barg excursion on a wide fixed scale vanishes into the baseline. Autoscale is great when you're hunting around unfamiliar data. It's a poor default for a screen someone reads under pressure.
So set scales on purpose. For each analog pen, decide the normal operating band, the alarm/engineering limits, the startup and shutdown extremes it has to survive, and whether zero must be visible. Flow, speed, valve command, and percent output should almost always be zero-based — a flow trend that starts its axis at 400 m³/h makes a 10% dip look catastrophic. Header pressure, pH, or a tight temperature loop read better on a narrow band as long as the axis is labeled. When you're unsure, give it a stable fixed default and leave manual rescale available for troubleshooting.
Don't let the trend draw a line through a hole
This is the failure that burns people. If the collector lost comms for ten minutes, the trend must not connect the last good sample to the next one with a smooth line, as though the process calmly moved that way. During an event, data quality is part of the event: a pressure trend that drops because the transmitter failed is a completely different problem from one that drops because the pump tripped, and a straight interpolated line hides the difference.
Two things to check on your platform:
- How it renders bad quality, uncertain quality, comms loss, and collector shutdown — a gap, a dashed segment, a color change, anything but a confident straight line.
- What your historian compression is quietly eating. Swinging-door / deadband compression is there to save disk, but a 1% deadband on a fast pressure tag will happily drop a 3-second spike that tripped a downstream interlock. If the trend can't show an excursion the PLC clearly reacted to, suspect the deadband before you suspect the instrument.
Put the limit on the alarm-response trend
Alarm response is where a trend pays for itself, so a high-pressure alarm page should show far more than the alarm bit. Show the pressure, its setpoint, the valve output, the pump or compressor state, the upstream and downstream conditions — and the alarm limit line itself, drawn on the same axis. Crucially, show the period before the alarm, not just after; the cause is almost always in the lead-up. ISA-18.2 pushes alarm rationalization toward "what does the operator do about this" — the trend on that page should make the answer obvious without them hunting for the matching tag.
If the alarm was shelved or suppressed, the trend should still show the real process values through the shelved window. Suppressing a notification is not a reason to hide an abnormal value.
Operator trends and engineering trends are not the same screen
Operators need stable, named, task-oriented trends they can trust. Commissioning, tuning, and root-cause work need dense, disposable trends full of controller internals, comm counters, and temporary test points. Both are legitimate; making them the same screen serves neither. Keep the operator library curated and predictable. When a temporary engineering trend keeps proving useful, don't leave it as a scratch screen — promote it into the maintained library with proper labels, scales, and an owner.
That last word matters. Trends rot like any HMI object: tags get renamed, transmitters get swapped, compression settings drift, control strategies change. Assign ownership at handover so the site knows who can approve changes to the trend library — otherwise every display slowly stops matching the plant it was drawn for.
Commission it against a known event
Confirming that lines appear is not commissioning. Before handover, drive a known event — a pump start, a valve stroke, a mode change, a deliberate setpoint bump — and check the trend tells the same story as the field and the PLC logic. While you're there, walk the boring list: every pen points to the right tag, units and labels are correct, scales hold up under both normal and upset conditions, the default time window matches the equipment (seconds for motion, tens of minutes for flow/pressure loops, hours for tanks and thermal systems, days for fouling and slow drift), discrete states line up with real equipment state, and historical retrieval still works after a server restart or collector failover.
If the trend and the field disagree during that test, you found a wiring, scaling, or tag-mapping error while it was cheap — which is the whole point of doing it before an operator finds it during a real upset.