Event Aggregated Measures
Turning an event scheme into numbers — counts, durations, gaps between events, and the age of the last one.
An event-sliced measure answers "what was this measure worth during each event". An event aggregated measure answers the other question: "what do the events themselves add up to over this period?"
How many stoppages this shift. How long the line was down. How long between failures. How long since the last changeover. None of those are readings from an instrument — they are properties of the event scheme, turned into a number per time period.
This is where most reliability and utilisation metrics actually come from. MTBF, MTTR, cycle time and downtime are all event aggregations, not calculations.
The fourteen aggregation types#
An event aggregated measure names an event scheme and one aggregation type. They fall into four families.
Counting events#
| Type | Counts |
|---|---|
| Count (Start) | Events that started in the period |
| Count (End) | Events that ended in the period |
| Active Count | Events overlapping the period, whenever they started |
| Inactive Count | Gaps between events overlapping the period |
The distinction between the first three is the one to get right, and it only matters for events that straddle a period boundary. A stoppage running from 05:50 to 06:10 is counted in the 05:00 hour by Count (Start), in the 06:00 hour by Count (End), and in both by Active Count.
Pick by the question. "How many breakdowns began on night shift" is Count (Start). "How many jobs completed today" is Count (End). "How many machines were down at some point this hour" is Active Count.
Count (Start) and Count (End) do not add up across periods the way you expect. An event is counted once by Count (Start), in the period it began. Sum a daily Count (Start) up to a month and you get the right answer. Active Count double-counts on purpose — an event spanning three hours is active in all three — so summing Active Count up a hierarchy is almost never meaningful. Aggregate Active Count with Maximum or Average, not Sum.
Measuring how long events lasted#
| Type | Measures |
|---|---|
| Event Duration (Start) | Total duration of events that started in the period |
| Event Duration (End) | Total duration of events that ended in the period |
| Active Duration | Time within this period that any event was active |
| Inactive Duration | Time within this period that no event was active |
Active Duration is the one you usually want for downtime, because it is bounded by the period: an event running all day contributes exactly one hour to each hourly period. Event Duration (End) attributes an event's whole length to the period it finished in, which suits "total repair time for repairs completed today" and badly misrepresents an hourly trend.
Active Duration and Inactive Duration together account for the whole period, which makes them a natural pair for utilisation: active over total is your downtime fraction, and you get its complement for free.
Measuring the gaps#
| Type | Measures |
|---|---|
| Duration Between Starts | Start of one event to the start of the next |
| Duration Between Ends | End of one event to the end of the next |
| Duration Between Events | End of one event to the start of the next |
These are the cycle-time and reliability metrics:
- Duration Between Starts is cycle time — bottle to bottle, batch to batch. It includes the event itself.
- Duration Between Events is the gap — how long the line ran between stoppages, which is mean time between failures when averaged.
- Duration Between Ends suits processes where completion is the milestone.
The odd ones#
| Type | Gives |
|---|---|
| Age | Time since the last event ended |
| Event Value (Start) | The event's value at its start |
| Event Value (End) | The event's value at its end |
Age is quietly one of the most useful. It answers "how long since the last…" — since the last changeover, the last clean, the last calibration, the last failure — and it keeps climbing until the next event occurs, which makes it a natural input to a limit. A limit on an Age measure is a maintenance-due alarm with no scheduling logic anywhere.
A worked shape#
Downtime reporting for a line, from one event scheme:
Line 3 Stoppages (event scheme)
+-- Stoppage Count Event Aggregated — Count (Start)
+-- Downtime Event Aggregated — Active Duration
+-- MTBF Event Aggregated — Duration Between Events (averaged up)
+-- MTTR Event Aggregated — Event Duration (End) (averaged up)
+-- Time Since Last Stop Event Aggregated — Age
Five measures, no calculations, all derived from one event scheme. Adding a limit to Downtime and to Time Since Last Stop gives the shift report and the maintenance alarm together.
Choosing between an event aggregation and a calculation#
If the number is a property of when events happened and how long they lasted, it is an event aggregation — and doing it with a calculation instead means reimplementing boundary handling that Infohub already gets right.
Use a calculation when the number combines events with other measures: downtime as a percentage of planned production time needs the planned time from somewhere else, so it is an event aggregation feeding a calculation, not a calculation reading events directly.
Diagnosing#
| Symptom | Likely cause |
|---|---|
| Counts higher than expected, and worse at shorter intervals | Active Count double-counts straddling events by design; use Count (Start) |
| Daily total does not match the sum of the hours | Event Duration (Start/End) attributes the whole event to one period; Active Duration is the one that is bounded by the period |
| Downtime exceeds the length of the period | An Event Duration type where Active Duration was meant |
| MTBF looks like cycle time | Duration Between Starts includes the event; Duration Between Events is the gap |
| An Age measure never resets | No event has ended since; that is what the measure says |
| A period is empty | No event overlapped it — Inactive Duration will show the full period |
| Numbers change after a backfill | Events that were still open have since closed — see Backfilling and Recalculation |