In most of the estates we audit, event frames are configured, generating, and read by nobody. They are the feature with the widest gap between what it can do and what it is used for.

The problem they solve

Operational questions are usually about episodes, not instants. How did this startup compare with the last twenty? Which trips shared a precursor? Was yesterday’s excursion worse than the one in March? Does this batch resemble the batches that came out of specification?

Answering any of those from raw time series means an engineer choosing start and end times by eye on a trend, which is slow, inconsistent between people, and impossible to do across a fleet.

An event frame makes the episode a first-class object with a start, an end, an associated asset, and attributes captured over its duration. Once an episode is an object, it can be counted, filtered, compared and aggregated like anything else.

What they are good for

• Startups and shutdowns. Duration, fuel consumed, time to synchronise, peak temperatures — trended across every startup for years.
• Trips and excursions. Captured automatically with the conditions leading in, so investigation starts with data rather than with someone finding the right window.
• Outages. Planned and unplanned, with duration and cause, which turns availability reporting from a spreadsheet exercise into a query.
• Batches. The natural unit in process manufacturing, comparable against each other on the attributes that determine quality.
• Operating states. Which is what lets condition monitoring stop alerting on every normal transition.

Why they go unused

Three reasons recur. They are generated without anyone defining what question they should answer, so they accumulate without consumers. They are configured per asset rather than on templates, so coverage is patchy and comparison is unreliable. And the tooling to look at them is less familiar than a trend, so people fall back on what they know.

The first is the real one. Event frames created because the feature exists will not be used. Event frames created because somebody wanted to compare every startup this year will be.

Getting value from them

• Start with one question somebody actually asks repeatedly
• Define generation on a template so every asset of that class produces comparable frames
• Capture attributes at the frame level — peak, duration, total — so comparison does not require re-querying the raw history
• Backfill against historical data where you can, so the feature is useful immediately rather than in a year
• Make them visible somewhere people already look

And for analytics

Event frames are unusually valuable to any downstream modelling. They provide labelled episodes — the single thing most industrial machine-learning efforts lack. A model trying to predict trips is far easier to build when every historical trip is already an object with a known start time than when someone has to identify them by hand first.

If you are planning analytics work, building event frames first is one of the highest-return preparatory steps available. We build them as part of AF work.