A Trend Cursor Only Proves What the Clocks Agree On

The cursor is only useful if the clocks agree

An operator drops a cursor on a trend, points at the readout, and says the header pressure fell before the pump tripped. In the incident review that sentence becomes a cause. But it is only a cause if the HMI client, the SCADA server, the historian, the PLC, and whatever report tool printed the record all agree on how time was stamped and how it is displayed. Often they don't, and the disagreement is small enough — two, five, sometimes eight seconds — to survive a casual look.

That is what makes trend time errors nasty: the line still looks plausible. Nothing is flagged bad quality. The problem only surfaces when you lay the alarm list, the batch record, the PLC event log, and the historian trend side by side and the order of events stops making sense.

Identify where the timestamp is created

Before blaming the trend display, find the timestamp source for each signal path.

Data path	Common timestamp source	What to verify
Live HMI tag	SCADA server receive time	Driver group delay and server clock
Historian sample	Historian interface or archive node	Compression, buffering, and late data handling
PLC event record	PLC real-time clock	Time sync method and daylight saving handling
Alarm event	Alarm engine evaluation time	Alarm delay, shelving, and server redundancy behavior
Batch or MES record	Application service or database server	Time zone storage and report conversion

Do not assume one project uses one rule. A live pen may show server receive time while a historical pen beside it shows historian archive time.

OPC UA makes this explicit, and it is worth pulling into the light because a lot of SCADA drivers hide it. Every DataValue carries two timestamps (Part 4 of the spec): a SourceTimestamp, meant to be when the value was actually acquired at the device or gateway, and a ServerTimestamp, when the OPC UA server processed it. If your historian subscribes to the server and stores ServerTimestamp while the operator believes it is field time, every reading is offset by the transport and polling latency — usually tens to a few hundred milliseconds, worse across a slow radio link. Decide which one you archive and write it down. DNP3 (IEEE 1815) has the same split: a Class 1/2/3 time-tagged event object carries the outstation's own timestamp, while a plain static poll gets stamped when the master received it. Fast events and slow static reads on the same point can therefore disagree by a full poll interval.

Compare live values against historical replay

A simple commissioning test is to force a safe test signal and watch it in both live and historical modes.

Useful checks:

• Toggle a non-production test bit or simulator tag at a known time.
• Watch the live trend cursor while the value changes.
• Wait until the historian has archived the point, then reload the same range from history.
• Compare the timestamp, value, and quality shown in both views.
• Repeat through a SCADA server failover if the system is redundant.

If the live display shows the edge at 10:00:02 and the historical replay shows it at 10:00:07, decide whether this is expected buffering or a configuration defect. Do not leave it as an unexplained difference.

Check time zones and daylight saving behavior

Many trend issues are not sampling problems. They are display conversion problems.

Field checks:

• Confirm whether the historian stores UTC or local time.
• Confirm whether the HMI client converts timestamps or simply displays server strings.
• Test from an engineering laptop set to a different time zone only if that use case is allowed.
• Review daylight saving rules for sites that report across regions.
• Verify exported CSV files include a time zone or offset column when they leave the HMI system.

A one-hour offset after a daylight saving change can look like a process delay. For regulated or audited processes, trend exports should make the time basis unambiguous.

Cursor interpolation can mislead root cause analysis

Some trend controls show the nearest stored sample. Others interpolate a value between two samples. Both behaviors can be acceptable, but the operator and engineer need to know which one is being used.

Watch for these cases:

• A digital signal appears half-on because the cursor value is interpolated.
• A slow historian sample hides the exact order of two fast events.
• A compressed analog tag shows a straight line across a real disturbance.
• The cursor value changes when the time range is zoomed because the trend control requests different resolution data.

For event analysis, do not rely on a compressed analog trend alone. Use alarm events, PLC sequence numbers, totalizers, or high-resolution historian points when order matters.

Align pens with different sample rates

A common mistake is to put fast status bits, slow analog values, and calculated KPIs on the same trend and then read the cursor as if every value was sampled at the same instant.

A better trend page separates the context:

• Fast event pens for commands, feedback, permissives, and sequence states.
• Process pens for analog values with engineering units and reasonable scaling.
• Calculated or MES values with clear labels that show they are not real-time PLC samples.
• A notes field or event markers for recipe changes, mode changes, and operator actions.

When the cursor lands between samples, the trend should make the sample age visible if the tool supports it. At minimum, document the collection rate for important pens.

Common failure modes

• Historian interface buffering data after a network outage but writing samples with the wrong receive time.
• HMI clients using local workstation time while the server uses UTC.
• Redundant SCADA servers with clocks that differ by several seconds.
• PLC event arrays running on the controller's free-running RTC with no time sync at all. NTP over a quiet control LAN holds a controller inside a few milliseconds of the source; PTP (IEEE 1588) gets you to sub-microsecond, but only if the switches are boundary or transparent clocks. A PLC with neither drifts a second or more a day, and nobody notices until the event log is a second ahead of the historian.
• Trend export files losing milliseconds even though the archive stores them.
• Report queries mixing local date filters with UTC archive timestamps.
• Cursor readouts showing rounded values while the plot uses raw values.

Most of these problems are found only when someone compares two records during an incident. It is better to test them during commissioning.

Write down the time basis before you leave site

The one artifact worth producing for each critical trend or report is a few lines naming, per pen: the timestamp source (live, historical, alarm, exported), the storage basis (UTC or site local), the sample rate plus deadband, compression and interpolation behavior, and the expected worst-case lag between live display and historian availability. Add one line on how far you trust the millisecond ordering, because that is the claim someone will over-read during an incident.

None of this needs to be long. It exists so that the next engineer — probably you, at 2 a.m., a year from now — treats a clean-looking trend line as what it is: a display, not a calibrated time sequence, until the clocks behind it have been checked.