How OEE Is Calculated Over Time
How Availability, Performance and Quality are aggregated into time bins and rolled up across a period for dashboards and trends.
An OEE number only means something for a span of time — a shift, a day, a week. When you query the OEE data store or build a dashboard, Nexus computes the three pillars over that span and rolls them up. Two details of how this works explain why a dashboard looks the way it does.
This page goes a level deeper than OEE Concepts — read that first for the vocabulary and the configuration model.
Time bins
Reporting splits the timeline into fixed, clock-aligned bins — one hour by default (08:00–09:00, 09:00–10:00, …), though a dashboard can request a finer or coarser resolution. A query returns every bin that overlaps the selected range, even if the range starts or ends partway through a bin.
Bins are a reporting construct, not production events: orders, stops, shifts and state changes start and end whenever they actually happen, and the calculation splits their time across bins by overlap. Equipment state is carried forward between readings — the last reported state is assumed to hold until the next change ("step interpolation") — so the run-state tag only needs to emit on change, not continuously.
Availability is time-based; Performance and Quality are order-based
Availability comes straight from time: for each bin, how much of the scheduled time the equipment was actually running. It can be derived from the state timeline alone.
Performance and Quality are only known once an order's counts are reported — typically at order completion (see Aligning counts with order completion). Assigning all of an order's production to the bin where it completed would create artificial spikes, so a completed order's totals — produced, approved, rejected, and the ideal production time (produced × ideal cycle time) — are instead distributed across the productive time of the order. Only productive order time receives a share; time the equipment was stopped, idle, or outside its shift does not.
A practical consequence: an enabled Performance pillar with no completed order in a scheduled window has no production to distribute, so Performance — and therefore OEE — reads 0 for that time until the order completes, even when Availability looks healthy.
Totals come from summed base values, not averaged percentages
Whenever the pillars are rolled up — across bins for a period total, or across orders within a bin — Nexus sums the underlying durations and quantities and then divides, rather than averaging percentages:
Period Availability = Σ run time ÷ Σ scheduled time Period Performance = Σ ideal production time ÷ Σ actual productive time Period Quality = Σ good quantity ÷ Σ total quantity Period OEE = Period Availability × Period Performance × Period Quality
This weights large orders and busy bins correctly — a 10-unit order and a 10,000-unit order don't get equal say. Averaging per-bin or per-order percentages would distort the result, especially when some bins hold only part of an order or no production at all. Keep this in mind when authoring your own queries: aggregate the base values, don't average the percentages.
Concurrent orders and missing data
If two orders are active over the same interval — whether the equipment genuinely runs them in parallel or the source system reports overlapping order events — each is distributed independently and their contributions are summed, so a bin can legitimately hold more productive order time than its own length. If your equipment should only ever run one order at a time, overlapping orders are worth investigating as a data-quality issue.
Time where the equipment state is unknown is marked as missing rather than guessed. Missing time is excluded from the OEE math and surfaced in dashboards, so the score isn't quietly inflated or deflated by gaps in the data.
Last updated
Was this helpful?