OEE Data Collection: Downtime, Microstops and Shift Boundaries

Define the denominator before collecting more tags

Under the convention described by Vorne's OEE calculation guide, the factors are:

Availability = Run Time / Planned Production Time
Performance = Ideal Cycle Time × Total Count / Run Time
Quality = Good Count / Total Count
OEE = Availability × Performance × Quality

Use consistent time units.

In that convention, stops within intended production can include changeovers, while periods without production intent are excluded before calculating Planned Production Time. The calendar decision therefore changes the measurement base.

A planned label alone does not settle that decision. Siemens' Insights Hub OEE time model distinguishes Production Time, Planned Stop and Downtimes within its own model. Map the actual intervals and equations when integrating products. Do not infer equivalent denominators from similar status names.

Document the selected convention with the plant's operating calendar. Define how breaks, maintenance and changeovers are treated, including the conditions under which that treatment changes. Store the rule version used for each calculation so a calendar revision does not silently rewrite historical comparisons.

A microstop test that should preserve total OEE

The following synthetic example uses invented production data. It follows the formulas above for one product with a constant ideal cycle time. It is a calculation test, not a factory benchmark.

Planned Production Time is 420 minutes. Total Count is 18,000 units, of which 17,100 are good. Ideal Cycle Time is one second per unit. Ten minutes of short stops are the only classification difference between the two calculations.

Availability rises in the second calculation, but performance falls. Run Time cancels when the factors are multiplied consistently. The equivalent calculation is:

17,100 good units × 1 second / (420 minutes × 60 seconds)
= 67.8571% OEE

This equivalence is also set out in the OEE.com formula guide. The numerical example above is original to this article.

If the denominator is accidentally changed to 480 minutes while the productive output stays the same, the result becomes 59.375%. That is a measurement-window change, not evidence that the machine deteriorated.

Siemens' microstop configuration allows a configurable threshold and assignment to performance or availability loss. There is no universal threshold to copy into every plant. Agree the diagnostic purpose of the classification and check that the implementation does not subtract the same interval twice.

A machine state needs a reason later

A controller can report that a machine stopped without knowing whether the cause was missing material or an inspection. Preserve the observed state even when an operator later supplies a reason.

Siemens' status-mapping documentation maps machine codes into a reason tree and describes operator refinement. In a custom model, give the raw event and the reason assignment separate identifiers and timestamps. Editing a reason should not alter when the machine's signal changed.

Use a manageable reason taxonomy that supports action. Vorne's Six Big Losses connects loss categories to the OEE factors. A plant can use a more detailed local tree beneath those categories, but every leaf should map consistently to the agreed calculation rules.

Unknown telemetry needs its own treatment. A missing signal establishes a data gap. It does not establish that the machine ran or stopped. Show the affected interval and apply an explicit data-quality policy before publishing a result as complete.

Operator input remains useful even in an automated collection system. The Point85 implementation architecture illustrates collectors alongside operator clients. Automating the state observation and asking a person for its cause can coexist without making one input overwrite the other.

Cut intervals at the boundaries that change meaning

A stop that crosses a shift boundary belongs partly to each shift. Intersect the stop interval with each calculation window before calculating duration. Treat adjacent intervals consistently, for example by including their start and excluding their end. If maintenance and a machine-stop event cover the same minutes, summing both durations can subtract the same time twice. Resolve the overlap according to the plant's category precedence, then retain the original observations for investigation.

The SAP ME 15.2 OEE guide, version 1.2 dated October 28, 2019, explicitly describes time operations as unions and differences of intervals. It also distinguishes calculation modes with different handling at shift boundaries. This is a historical product example, not a claim about every current SAP or MES implementation.

Apply the same boundary logic to product changes. If a line changes SKU, split the interval where the ideal cycle definition changes. Keep event time separate from ingestion time so a delayed message can be assigned to the shift in which the event occurred.

Store the site's time zone as part of the calendar definition. A daylight-saving transition can change the elapsed duration of a local-time shift. Resolve the actual instants before aggregating minutes; a label such as night shift is insufficient to reconstruct the window.

Counts and ideal cycle time need explicit contracts

For each counter, record the quantity it measures and its unit. A cycle count may differ from a part count when a machine produces several parts per cycle. A good-unit counter may be supplied by a downstream inspection process rather than the machine itself.

Define how resets and device replacement are recognized. A decrease in a cumulative counter might indicate a reset; treating it as a negative production event would corrupt the period. Preserve the raw reading and the interpretation used to derive an increment.

Vorne's OEE FAQ defines ideal cycle time by the fastest theoretical operation rather than the familiar average or a budget target. Version it by the relevant product and operation. A target based on average historical performance can make a slow process appear to have little speed loss.

For mixed products, calculate ideal productive time for each product using its applicable cycle definition, then combine compatible quantities. Do not multiply a whole mixed-SKU count by whichever cycle time happens to be active at the end of the shift.

The transport layer has separate responsibilities. An OPC UA integration can provide machine values and their delivery context. It cannot choose the plant's production calendar or establish that one counter means sellable units. Put those meanings in the measurement contract.

Aggregate shifts from their underlying quantities

A second synthetic example shows why the arithmetic mean of percentages can mislead. Shift A has 200 planned minutes and 50% OEE, representing 100 fully productive minutes under the selected model. Shift B has 400 planned minutes and 75% OEE, representing 300 fully productive minutes.

The combined result is:

(100 + 300) fully productive minutes / (200 + 400) planned minutes
= 66.6667% OEE

The simple average of 50% and 75% is 62.5%. It gives the shorter shift equal weight and answers a different question. For the combined production window, aggregate compatible productive time and planned time first.

Do not independently average availability, performance and quality and assume their product reproduces the aggregate. Retain the underlying quantities needed for the selected convention. When assets or products are not comparable, segment the report and explain the aggregation policy.

Keep calculations reproducible after corrections

A proposed model uses MachineEvent for observations and CalendarWindow for intended production. StateInterval records the interpreted timeline. ReasonAssignment adds the explanation, while CountObservation preserves readings and reset information. IdealCycleVersion identifies the applicable speed definition. Each CalculationRun should reference those inputs and the rule version. A late inspection count or corrected reason can trigger a revised calculation for a defined period. Retain the prior result and the reason for revision so yesterday's dashboard can still be explained.

Before releasing a result, verify that Good Count does not exceed Total Count and that the relevant denominators are positive. Check for overlapping duration deductions. Investigate performance above its expected range instead of silently capping it to make the dashboard look valid. The microstop and shift examples above provide additional regression cases.

Track data completeness beside OEE. A plant manager needs to know whether an apparent change came from production, a revised calendar or missing observations. A single percentage conceals those distinctions.

Scope a pilot around one explainable shift

Choose a machine and a shift with known product changes and downtime. Ask the implementation team to reconstruct the timeline from source observations, then reproduce the published result. Introduce a counter reset and a late correction before expanding the pilot.

The manufacturing software development guide places that work within the wider MES and plant integration scope. Pharos Production's manufacturing software development page is the commercial starting point for discussing the build. Bring a shift calendar, a representative counter export and the current downtime reason list so the first review can test the measurement model against actual inputs.