> For the complete documentation index, see [llms.txt](https://docs.tricloudnexus.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tricloudnexus.io/management-portal/oee/oee-concepts/how-oee-is-calculated-over-time.md).

# 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](/management-portal/oee/oee-concepts.md) — 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](/management-portal/oee/equipment/tag-mapping/product-and-order.md#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.

{% hint style="info" %}
The distribution assumes production was **uniform** across the order's productive time — an order that produced 1,000 units over 10 productive hours contributes 100 units to each hour. This is a deliberate approximation: it doesn't reconstruct the exact minute-by-minute rate, but it places Performance and Quality in the bins where the machine was actually producing, which gives far more useful trends than dumping everything into the completion bin.
{% endhint %}

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.