Historian Trend Annotations: Store Operator Events as Events, Not Fake Tags
Recording calibration, manual mode and bypass windows as event records separate from the sampled stream, joined back by asset ID and time window.
At 14:07 the P-204 discharge pressure trend goes flat. Twenty minutes later it moves again. Six months on, the engineer who opens that window has no way to tell whether the unit was down or somebody pulled the instrument. It was an FT-1203 calibration, and the output was simply held at its last good value.
Annotations fill that gap. Where you attach them decides whether they survive. The sampled stream produced by the controller and the instruments stays immutable. The event record a person creates from the HMI or MES lives separately and gets corrected by revision, never by overwrite. The two meet again in the trend and the report, keyed on asset ID and time window.
Do not smuggle events into sampled tags
"Pump checked" is not a pressure sample. Yet the most common implementation in the field is a single string tag whose value receives operator notes. Three things break at once.
- Compression eats the note. Swinging-door and deadband compression discard repeated values. The second time an operator types the same wording, it is not stored.
- You cannot express an interval. A calibration is 09:00–09:35, a window with a start and an end. A sample is one instant.
- It is not searchable. Text living in a tag value has to be found with a trend query instead of an event query.
Modelling a maintenance window as a Boolean tag has the same defect. If the controller does not actually produce that bit, it is not a process state — it is a claim a person made. In an investigation those two are weighted very differently.
Keep alarms out of this as well. Alarm records belong to the alarm system defined by ISA-18.2 (IEC 62682); duplicating them as annotations gives you two copies that will disagree. Annotations carry only what the alarm system does not — why somebody did what they did.
The minimum an event record needs
| Field | Example |
|---|---|
| Event time | 2026-06-26T14:07:32+09:00 — ISO 8601 with offset |
| Created time | When it was entered. A separate column from event time |
| Asset reference | A stable ID from the ISA-95 (IEC 62264-1) hierarchy: Site/Area2/P-204 |
| Event type | Manual mode, calibration, bypass, maintenance, quality hold |
| Start / end time | Only for events that are intervals |
| Source | HMI user, maintenance system, PLC event, MES |
| Reason code | Planned maintenance, troubleshooting, product change |
| Free text | A short note with practical detail |
| Related record | Work order, alarm id, batch id, lot id |
If the asset reference is a screen name, every annotation breaks the next time screens are reworked. Keep the HMI display name as an alias and store the ID that comes out of the ISA-95 hierarchy. This is the single most expensive field to fix later.
Timezone handling does not end at storing an offset. A Korean site has no DST, so +09:00 is constant and nobody thinks about it — until the same historian starts receiving data from a European line. Store the offset, but store the IANA time zone name too (Asia/Seoul, Europe/Berlin) so shift boundaries can be recomputed afterwards.
Reason codes and free text travel together
Free text alone cannot be searched. Reason codes alone give you twenty identical "Planned maintenance" rows. Use both.
- Type:
Calibration - Reason:
Scheduled PM - Asset:
Site/Area2/FT-1203 - Window:
09:00-09:35 - Note:
Loop check after transmitter replacement. Output held at last good value. - Work order:
WO-78412
Keep the reason list short. Past about ten entries operators stop reading and pick the first or the last one, and you get a column that is fully populated and worthless. If detailed classification genuinely matters, that is the maintenance system's job or the MES's job, not an HMI popup's.
Rules for drawing them on a trend
An annotation should explain the trend, not cover it.
Draw calibration, manual override, bypass, and bad-data windows from comm faults as interval markers. Draw mode changes, recipe changes, and lab results as point markers. Filtering by event type and asset has to work, and the trend itself should carry only a short label with the full record one click away.
Screens that fail usually fail the same way. Every log entry in the area appears on every trend. Long comments hide the curve. A note attached to a pump propagates up into the unit-level report. Manual entries render identically to controller-generated events. That last one is the worst — it changes the evidentiary weight of the record in the room where it matters.
A trend used for troubleshooting has to let the engineer switch context on and off in one action. Context that is always on is context nobody looks at.
The audit trail is where regulation shows up
On a GMP line an annotation is not a note, it is an electronic record. 21 CFR Part 11 §11.10(e) requires secure, computer-generated, time-stamped audit trails covering creation, modification, and deletion, and states that record changes shall not obscure previously recorded information. EU GMP Annex 11 clause 9 (Audit Trails) asks for a record of GMP-relevant changes and deletions on the same logic. Silent overwrite runs straight into both.
So the minimum behaviour is:
- Store who created the event, or the identity of the source system that imported it.
- Keep created time separate from event time. This is where ALCOA+'s contemporaneous is judged.
- Stack corrections as revisions and keep the original.
- Require a reason on deletion or cancellation.
- Split create, edit, and close permissions on intervals by role.
If you are on OPC UA, this model is already in the spec. In Part 11 Historical Access (OPC 10000-11), a HistoryRead with isReadModified set in ReadRawModifiedDetails returns HistoryModifiedData, and every value carries ModificationInfo — ModificationTime, UpdateType (Insert/Replace/Update/Remove), and UserName. Before designing your own revision table, check whether the historian you already own exposes that.
Late entry is not the problem. Writing up the shift at the end of it is what actually happens. The problem is a system that hides the fact. The moment created time is stored equal to event time, the historian looks cleaner than reality, and that comes back as a data-integrity observation.
Common failure modes
| Symptom | Cause | Fix |
|---|---|---|
| Flat trend during calibration with no explanation | Output was held but no event marker stored | Store the calibration interval with its work order |
| Report excludes downtime on free text alone | No structured reason, no related record | Event type + reason code + link to the downtime record |
| Operators stop writing notes | Slow form, or notes required for trivial actions | Auto-capture known events, require notes only where useful |
| Annotation timestamps are off | Inconsistent local time / UTC / DST handling | Store offset and IANA zone name, test at shift boundaries |
| Notes cannot be found later | Asset names differ across HMI, historian, maintenance system | Store the ISA-95 hierarchy ID, display names as aliases |
Annotation projects do not fail for lack of a text box. They fail because time, asset identity, ownership, and audit behaviour were never decided.
What to actually try during commissioning
- Put a loop in manual for ten minutes and return to auto — do both markers land at the right instant?
- Calibrate a transmitter with collection running — does the interval marker line up with the held window?
- Apply and remove a bypass with a reason required.
- Add a note after the event time and confirm the audit trail shows it as a late entry.
- Pull the same window into a report and confirm the event is visible or linked.
- Edit one event and check the previous value is still retrievable — this is where most products fail.
If step 6 fails, the first five do not matter. "Audit trail supported" in a datasheet tells you nothing about whether the product stacks revisions or just keeps the latest value and writes a log line; you have to click it yourself.