Your Historian Event Frame Is Only as Good as Its End Trigger
Event frames pay off only if their boundaries hold. Where to take start and end triggers, what to capture as attributes, and frames that never close.
A quality engineer pulls the report for batch B-2026-0617-04 and the dryer outlet temperature averages 41 °C over what should have been a 90-minute cycle. Nothing was wrong with the dryer. The frame never closed on the previous batch, the new start trigger opened a second one anyway, and the query summed 14 hours of idle plant into a 90-minute answer.
That is the normal failure. Storing the frame is trivial — every historian does it. Deciding when it starts and stops is the whole job, and the end trigger is where projects lose.
The questions that don't fit a time range
People don't ask the historian for "13:40 to 15:10". They ask:
- What did the pressure profile look like for this CIP step?
- Which press cycles ran long last week, and were they all on the same tool?
- Did this lot run before or after the recipe change?
- Which downtime event overlapped the filler speed drop?
Event frames (PI AF's term), batch segments, or whatever your product calls the same object answer these by putting a named, bounded, attributed window over the raw time series. Without them, people export trends and draw vertical lines by hand. That's fine once. It doesn't survive being a weekly quality review.
Take boundaries from state, not from analog thresholds
If the equipment already has a state machine, use it. ISA-88 (IEC 61512-1) gives you the shape for free on batch equipment — procedure, unit procedure, operation, phase — and phase state transitions to RUNNING, COMPLETE, ABORTED, HELD are exactly the boundary events you want. On discrete equipment, a CycleActive bit paired with a cycle counter does the same job.
What I avoid: starting a frame on an analog crossing like "outlet temp above 80 °C" or "motor current above 10 A". It looks fine on a display and it falls apart on warm-up, on jog, on a maintenance test at 06:00 Sunday, and on any sensor that chatters within a degree of the threshold. If you must use an analog trigger, put real hysteresis and an on-delay on it — 2 °C and 30 s, not a bare comparison — and expect to tune it.
Two more traps worth naming:
Start on running, not on the start command. Start_PB or an MES lot-start message tells you someone asked. Running tells you it happened. The gap is 3 seconds on a small pump and 4 minutes on a rotary dryer, and it's the difference between a clean cycle-time distribution and one with a fat left tail nobody can explain.
End on process completion, not on the operator leaving the screen. I have seen a frame closed by an HMI navigation event because the developer had a convenient script hook there. It worked until the shift that stayed on the screen through the changeover.
For each frame type, write down five things before you build anything: what starts it, what ends it, what happens on abort/hold/restart, whether nesting is allowed, and which clock is authoritative. If you can't explain the boundary rule to the process engineer in two sentences, it's too fragile to survive commissioning.
Attributes are the part that ages well
The frame name is for humans. Everything downstream joins on attributes.
Capture at minimum: batch/lot/work-order id, equipment id at the ISA-95 (IEC 62264) level you actually report on, recipe id and recipe version, product code, shift or crew, completion state, and the MES transaction id if there is one. Add the key setpoints as they were at start.
The word that matters there is at start. A batch id attribute bound to a live tag reference instead of a captured value will quietly change halfway through the frame when the next lot downloads, and you won't notice until someone asks why two frames claim the same lot. Capture on the start trigger, freeze it, never re-read.
And don't lean on a display name like Batch B123 Line 2. It reads well and it joins with nothing — LIMS, alarm history, and the CMMS all key on something else.
Open frames need a policy, not a cleanup script
Every site gets open frames eventually. PLC restart mid-batch, network outage, aborted run, MES message dropped, script exception at 02:00.
Decide the policy before production, because the default — leave it open forever — is the one that produced the 14-hour dryer average above:
- Put open frames on an engineering dashboard where somebody sees them the same day.
- Auto-close past a maximum duration with an explicit
timeoutorinferredstatus. Set the maximum from the actual distribution, not the recipe nominal: if the P95 batch is 3 h 10 m, close at 6 h, not at 3 h 30 m. - Allow authorized manual closure with reason and user recorded. In a GxP plant the audit trail requirement (21 CFR Part 11) applies here too — keep the original start time and log the correction separately rather than overwriting.
- Block a new frame from silently shadowing an unclosed one on the same equipment. Either refuse it or close the old one with a status that says why.
Validate on a trend, not in SQL
After the logic is written, overlay the frame boundaries on the tags — state, speed, temperature, pressure, recipe, lot id — and look at them. Off-by-one transitions and stale context are obvious to the eye and nearly invisible in a row count.
Sample deliberately: one normal run, one abort, one hold-and-resume, a short test cycle, a maintenance jog, a run with a PLC restart in it, one with late-arriving data after a network outage, and one with a product changeover mid-interval. That last one catches more attribute-capture bugs than the other seven together.
Two clock issues show up here and only here: DST transitions shifting boundaries against tag data if anything in the chain stores local time, and drift between the PLC clock and the historian server if they aren't both disciplined to the same NTP source. A frame that starts 40 seconds before its own data is a clock problem, not a logic problem.
The commissioning report
Before handover, run this over the last few days and read it yourself:
| Check | What it usually means when it fires |
|---|---|
| Frames still open | Missing end trigger or unhandled abort path |
| Longer than max expected | Same, or a nesting rule that never unwinds |
| Shorter than min expected | Threshold chatter, or test cycles leaking in |
| Missing batch/recipe/product attribute | Attribute bound to a tag that was null at start |
| Start time after end time | Clock skew, or late data reordered |
| Overlapping where overlap is disallowed | Shadowed open frame |
| Created by manual correction | Fine occasionally; a trend means the trigger is wrong |
Simple checks, but they're the ones that decide whether the historian gets trusted. If the frame list looks wrong on day one, operators go back to screenshots and spreadsheets and never come back.
Start with the intervals that support one clear workflow — batch review, or cycle comparison, or downtime analysis. Get the boundaries and the attribute capture right there. Adding frame types after that is cheap; adding them on top of shaky boundaries just produces more history nobody believes.