Trends: the difference between a value and a direction

Ask an experienced operator how they decide whether a drifting variable needs intervention and the answer will involve rate of change, not value. A level at seventy percent and rising slowly is a different situation from a level at seventy percent and falling fast, and the number is identical.

Despite that, most process displays present values and put trends on a separate screen that has to be called up, configured and interpreted. The information that drives the decision is one navigation step away from the display where the decision is made.

Embedded trends change what the display does

A small trend placed next to the value it belongs to — a few hours of history, no axes, no legend, just the shape — converts a display of state into a display of behaviour.

Distributed engineering teams sometimes use remote monitoring as a supplementary management control. Further details are available via this resource.

Additional industry context is available in the ISA-101 HMI standards.

The space cost is modest and the perceptual gain is large: direction and rate of change become available without reading, in the same way that a deviation bar makes position available without reading.

The design constraints are that the time span must be appropriate to the process dynamics, the scale should be the normal operating range rather than the instrument range, and the trend should be readable at a glance rather than analysable in detail.

Choosing the time span

The span should be long enough to show the behaviour that matters and short enough that current change is visible.

For a fast loop, minutes. For a level in a large vessel, hours. For a slow quality variable, a shift. A single span applied uniformly across a display produces trends that are either flat lines or noise, depending on the variable.

Where a variable genuinely needs two spans — a short one for control and a long one for context — the answer is usually one embedded trend at the operational span and a detail trend available on selection.

Grouped trends for related variables

Individual trends show behaviour. Grouped trends show relationships, and relationships are what diagnosis depends on.

A set of related variables on a common time axis — the feed rate, the level, the temperature and the valve position for one unit — lets an operator see cause and effect in a way that four separate trends do not.

Building a small number of well-chosen trend groups, tied to the characteristic questions that arise on a unit, is one of the higher-value display activities and is frequently left to operators to assemble ad hoc.

Historical and live on the same axis

The distinction between real-time trending and historical trending is a system architecture artefact and should be invisible to the operator. A trend should extend continuously from history into live data without the operator switching tools.

Where the two are separate, operators use whichever is convenient rather than whichever is right, and comparisons across the boundary become error-prone.

Annotation and events

A trend showing a process variable is more useful with the relevant events marked: alarms, mode changes, setpoint changes, operator actions, equipment starts and stops.

Without the events, an operator looking at a step change in a variable is guessing at the cause. With them, the answer is frequently on the same screen — the step follows a setpoint change made forty minutes earlier.

This is straightforward where the historian records events alongside data, and it is one of the strongest arguments for recording operator actions into the same system as process data.

Trends for diagnosis after the fact

Beyond the operational use, trends are the primary evidence in any investigation into what happened during an upset.

That places requirements on the historian rather than the display: sufficient resolution during fast events, timestamps that agree across systems, and retention long enough that the data still exists when the investigation happens. These are configuration decisions taken at commissioning, and they are frequently discovered to be wrong during the first serious investigation.

Trend configuration should not be operator work

In many systems, producing a useful trend requires selecting tags, setting spans and scales, and arranging pens. Under normal conditions this is a minor irritation. During an upset it is a task the operator does not have time for.

Pre-configured trend groups, reachable in one action from the relevant display, remove that work at the moment it is most expensive. Building them is a modest engineering task and it is one operators consistently rate highly.

What good looks like

An operator asked whether a variable needs attention should be able to answer from the main display without navigating. An operator diagnosing an upset should be able to reach a pre-built group of related variables in one action, with events marked, extending back far enough to see the onset.

Neither requires new technology. Both are configuration and design decisions that are usually deferred and rarely revisited.

Trend resolution and what the display can show

A trend on a display is limited by pixel width: a two-hundred-pixel trend showing eight hours of data represents roughly two and a half minutes per pixel, and any faster behaviour is aggregated away.

For monitoring slow variables this is fine. For anything where short excursions matter, the embedded trend will not show them and the operator needs a route to a higher-resolution view.

The important thing is that the limitation is understood rather than assumed away. An operator concluding from a smooth embedded trend that a variable is steady, when it is oscillating between samples, has been misled by the display.

Scales that do not move

Autoscaling trends adjust their vertical range to the data, which maximises visible detail and destroys comparability: the same variable looks identical whether it is varying by half a degree or by thirty.

Fixed scales, set to the normal operating range, mean that the shape of the trend carries meaning. A flat line is genuinely steady and a large excursion looks large.

Autoscaling is useful for detailed analysis on a dedicated trend display, and it is the wrong default for an embedded trend whose purpose is at-a-glance interpretation.

Marking the limits on the trend

A trend showing a variable's history is more informative with the alarm limits and the normal operating band drawn on it. The operator can then see not only the direction of travel but how much room remains.

This converts the question 'is this rising' into 'is this rising, and will it reach the limit before I would have acted anyway', which is the question that actually determines the response.

Trends as the operator's memory

An operator returning from a break, or arriving at the start of a shift, needs to know not only the current state but what has been happening. A screen showing only present values requires them to ask someone.

Embedded trends spanning several hours make the recent past visible without any action, which is a substantial part of what a handover conversation otherwise has to convey.

For that purpose the span should comfortably exceed the length of a break and ideally approach the length of a shift, which argues for at least one long-span trend on any display an operator returns to.