Analysing Data by Event

Event-aggregated measures#

An event-aggregated measure asks one question of an event scheme, once per interval. It is an ordinary measure afterwards — chartable, limitable, aggregatable, publishable to consumers.

Creating one needs three things: the event scheme, the interval, and the anchor — which question you are asking. There are fourteen anchors; the Event Anchor and Trigger Reference lists them all.

The four you will use most:

Active Duration is the one to learn first#

If you are building availability, utilisation, or downtime percentages, use Active Duration.

It attributes only the portion of each event that fell inside each interval. That is what makes the values across an interval sum to the interval's length — and that is what makes a percentage meaningful.

The alternative anchors do not have that property, and the consequence is stark. Take an eight-hour stoppage that began at 22:00:

• Active Duration puts two hours in the 22:00–00:00 window and six in the next day. Each day's downtime is at most that day's length.
• Event Duration (Start) puts all eight hours in the interval the event started in. If that interval is an hour, you have eight hours of downtime in a one-hour period, and an availability figure below zero.

Count (Start) versus Count (End)#

For an event that spans a boundary — a batch starting at 23:40 and ending at 01:20 — these attribute it to different days.

Choose by what the number is for. Production counting usually wants Count (Start), because the plant thinks of the batch as having been started on that shift. Quality release reporting often wants Count (End), because the batch is only complete when it finishes. Pick one, and be consistent, because a plant with both in use will find its batch counts disagreeing.

Building an availability measure#

The canonical pattern, worth having in full:

Downtime Minutes Hourly     event-aggregated, Hourly,
                            anchor: Active Duration, scheme: Stoppage

Availability Hourly         calculated, Hourly, unit %

With the calculation:

Period.Duration.TotalMinutes == 0 ? 0
  : (Period.Duration.TotalMinutes - (Measure_<downtimeId>.Value ?? 0))
    / Period.Duration.TotalMinutes * 100

Using Period.Duration.TotalMinutes rather than a hard-coded 60 means the calculation is correct at every interval, and survives the daylight-saving days that are twenty-three or twenty-five hours long.

From there, aggregate availability upward — but aggregate it from the hourly downtime minutes, not by averaging hourly availability percentages, so that partial hours weigh correctly. See Aggregated Measures.

Pulling attribute values onto the grid#

The Event Value (Start) and Event Value (End) anchors take a numeric event attribute and put it on the interval grid.

This is how a batch's yield, a run's average rate, or a CIP cycle's peak temperature becomes a normal measure that can be trended, limited, and alerted on.

Non-numeric attributes stay in event-based charts, where they are used to group and filter rather than to plot.

Event-based chart types#

Three chart types read events directly.

Event Based Timeline. Events drawn as bars along time, coloured by an enumerated attribute. This is the single most useful event visualisation: a shift's worth of runs, stoppages, and changeovers as a coloured strip, immediately readable. Because colours come from the enumeration, a well-chosen palette makes the pattern obvious without a legend.

Event Based Table. One row per event, with attribute columns. The workhorse for detail — the list of today's batches with their yields, or the shift's stoppages with reasons and durations. It is also where operators go to check whether an event was recorded correctly.

Event Based Form. A table you can type into, which is how manually entered attributes get captured. See Forms and Data Capture.

Event charts take the Event Based constructors rather than an interval constructor, since they are not on the interval grid.

Pareto analysis#

The most valuable single output of a downtime scheme.

Build it from an event-aggregated measure counting or summing durations, grouped by the reason attribute. The chart ranks reasons by contribution and shows the cumulative curve, so the handful of causes accounting for most of the loss is immediately visible.

Two things determine whether it is useful:

The reason attribute must be enumerated — free text produces a chart ranking spelling variants.

The reason attribute must be filled in — a chart whose largest bar is "unspecified" is a statement about data capture, not about the plant.

Where reasons are grouped into an enumeration group, you get a hierarchy: rank by category for a management view, drill into specific reasons for the maintenance team. See Pareto Analysis.

Comparing across events#

Once events carry attributes, comparison becomes straightforward and is where the value compounds.

• Rate per product — is the line genuinely slower on one product, or was that a bad week?
• Yield per raw material lot — does one supplier's material consistently underperform?
• Downtime per shift or crew — with the caveat that crews work different products and conditions
• Changeover duration by from-product and to-product — which transitions cost the most
• Batch duration distribution — how consistent is the process really

These are event table and chart questions rather than measure questions, because they group by attribute rather than by time.

OEE#

OEE is availability × performance × quality, and events supply the first and contribute to the third.

• Availability from Active Duration on a stoppage scheme, against scheduled time.
• Performance from actual output against the rate the product should achieve — which usually means the run's product attribute selecting the right target rate.
• Quality from good output against total, both frequently available as event attributes.

Guard every division, and be explicit about what counts as scheduled time — a manual entry measure for planned hours is the usual way to make that visible and adjustable rather than assumed.

Diagnosing#

See also#

• Event Anchor and Trigger Reference
• Pareto Analysis
• Why Events Matter
• Event Attributes and Enumerations