TL;DR: OEE (Overall Equipment Effectiveness) measures how much of your planned production time a machine actually spends making good parts at rated speed. The formula is OEE = Availability x Performance x Quality, where Availability is run time / planned production time, Performance is (ideal cycle time x total count) / run time, and Quality is good count / total count. Multiply the three, and you get one number between 0 and 100%. The widely quoted world-class figure for discrete manufacturing is 85%. Most OEE numbers reported in real plants are wrong, and the reason is almost always the data source, not the maths.
Motionwell Automation builds custom machines and retrofits control systems on existing ones in Singapore, so we spend a lot of time wiring the sensors and counters that OEE dashboards are eventually fed from. This guide is written from that side: what the three factors mean, where each signal comes from on a real machine, why most reported numbers flatter, and what actually moves each factor.
What Is OEE in Manufacturing?
OEE is one percentage that answers a narrow question: of the time you planned to produce, how much did you spend producing good parts at the speed the machine is capable of?
It compresses three separate failures into one score.
- Availability — the machine was supposed to be running and wasn’t. Breakdowns, changeovers, material starvation, waiting for an operator.
- Performance — the machine was running, but slower than its rated cycle. Micro-stops, jams cleared in ten seconds, reduced speed settings, feeder hesitation.
- Quality — the machine was running at speed, but produced parts you cannot ship. Rejects, rework, startup scrap after a changeover.
Those are the Six Big Losses from TPM literature: breakdowns and setup/adjustment under Availability, idling/minor stoppages and reduced speed under Performance, process defects and startup losses under Quality. The categories matter more than the label — they tell you who owns the fix.
The OEE Formula
Availability = Run Time / Planned Production Time
Performance = (Ideal Cycle Time x Total Count) / Run Time
Quality = Good Count / Total Count
OEE = Availability x Performance x Quality
Note what is not in there. Planned Production Time excludes time you never intended to run — unmanned shifts, maintenance windows, public holidays. OEE does not punish you for closing on Sunday. The metric that counts all 168 hours in a week is TEEP, and it answers a capacity question instead.
A Worked OEE Calculation
One shift, one machine. Illustrative figures, not a customer result.
| Input | Value |
|---|---|
| Shift length | 480 min |
| Planned downtime (breaks, scheduled changeover) | 30 min |
| Planned production time | 450 min |
| Unplanned stop time | 60 min |
| Run time | 390 min |
| Ideal cycle time | 15 sec/part |
| Total count | 1,200 parts |
| Good count | 1,170 parts |
Availability = 390 / 450 = 86.7% Performance = (15 x 1,200) / (390 x 60) = 18,000 / 23,400 = 76.9% Quality = 1,170 / 1,200 = 97.5%
OEE = 0.867 x 0.769 x 0.975 = 65.0%
There is a shortcut that skips the three factors: good count x ideal cycle time / planned production time, or (1,170 x 15) / 27,000 = 65.0%. Run both. If the shortcut and the long form disagree, one of your counters is lying, and finding out which is more valuable than the score.
The 15-second cycle above is not arbitrary. It is the real indexing cycle of a 12-station rotary syringe assembly machine we built (P22068), with vision inspection at multiple stations. That is a design cycle, and agreeing on one is the precondition for the whole calculation.
Where Does OEE Data Actually Come From?
This is the part software vendors skip. Every OEE number is only as good as three signals coming off the machine, and on older equipment two of the three usually do not exist yet.
Availability: Run Time and Stop Reasons
Run time is not “power on”. A machine can sit energised, in cycle-stop, for a whole shift. What you need is a state signal the PLC already holds — auto-mode, cycle-active, or index-drive-enabled — sampled and timestamped.
Stop reasons are harder, and this is where most implementations quietly fail. The PLC already knows why it stopped: which E-stop, which interlock, which alarm word, which upstream sensor went empty. Map alarm bits to downtime reasons at the controller and you get honest categories for free. Skip it, and an operator picks from a dropdown at end of shift — the largest category becomes “Other”.
On the control-system retrofits that now make up the largest share of our project work, this mapping is designed in from the start. Modernising a legacy machine onto a current platform — CompactLogix or ControlLogix with PowerFlex drives and Kinetix servos, or the Siemens and Mitsubishi equivalents — rebuilds the alarm structure anyway. Tagging each alarm with a loss category at that moment costs almost nothing. Doing it two years later means touching a validated program.
Performance: Counts and the Ideal Cycle Time
Total count comes from a physical event, not a software estimate: a photoelectric sensor at the discharge, a servo index counter, a reject-gate actuation count. Position it after the last operation, or you count parts that never made it out.
Ideal cycle time is where OEE gets manipulated most often. Three definitions compete:
- The machine’s design cycle (what it was engineered to do).
- The best sustained cycle ever observed for that product.
- Whatever the current recipe is set to.
Only the first two are defensible. Using the current recipe speed makes Performance read near 100% forever, which hides the reduced-speed loss entirely — the machine has simply been slowed down to a comfortable pace and the metric applauds. If a machine has several products with different cycles, ideal cycle time is per product, and the calculation has to be split by run.
Quality: Good Count Versus Total Count
Good count means first-pass good. Parts reworked and later passed do not count. That distinction is unpopular, and it is the whole point of the factor.
The cleanest source is the inspection station itself. Where we integrate Keyence or Cognex vision, the camera controller already produces a pass/fail verdict per part plus a defect classification, so good count, reject count and reject reason arrive as one dataset instead of three. On a packaging line running serialization with DataMan readers and Domino coders, code-grade failures are already counted for compliance — that count is your quality loss data too. How those systems are specified and lit is covered in our machine vision inspection guide.
Where inspection is offline, the data arrives hours late and disconnected from the machine state that caused it.
Why Are Most OEE Numbers Wrong?
Five failure modes account for nearly all of it.
The ideal cycle time was set to the current speed. Performance reads 95%+ permanently. The single most common way to make a dashboard look good.
Micro-stops disappear. Most collectors only log a stop past a threshold, often 60 seconds. A jam cleared in 15 seconds, forty times a shift, vanishes from Availability and reappears as a Performance shortfall nobody can locate. Set the threshold low, then aggregate.
Planned downtime absorbs everything inconvenient. Reclassify a slow changeover as planned maintenance and Availability improves with no physical change. Draw the line once and stop moving it.
Rework counts as good. Quality reads 99% while the rework bench is stacked.
The dashboard averages across products. One machine, three products, three different ideal cycles, one OEE number. It’s arithmetic with no physical meaning. Split by product run.
A sixth: measuring a machine that isn’t the constraint. Lifting a non-bottleneck station from 60% to 80% produces inventory, not shipments. Instrument the bottleneck first.
What Is a Good OEE Score?
The number quoted everywhere is 85% for discrete manufacturing, built from 90% Availability, 95% Performance and 99.9% Quality. It is not a survey result. It was set by Seiichi Nakajima in Introduction to TPM (Japan Institute of Plant Maintenance, 1988) as the level demonstrated by plants awarded the JIPM Distinguished Plant Prize, and it is a hard target — the Quality component alone means one reject in a thousand.
The companion figure, “typical plants run near 60%”, is worth treating differently. It circulates through vendor benchmarking material without a primary survey anyone can cite, so it tells you roughly where the conversation sits rather than where the industry actually is. The worked example above landed at 65%, which is deliberately ordinary.
The 85% figure is orientation, not a grade, and the 60% figure is not even that. Context changes what “good” means:
| Situation | What to expect |
|---|---|
| Single product, long runs, no changeover | High Availability, benchmark is meaningful |
| High-mix, frequent format changes | Availability structurally lower; measure changeover separately |
| GMP or validated production | Cleaning, line clearance and batch documentation are non-negotiable time |
| Manual load / unload stations | Performance tracks operator pace, not machine capability |
| New line still ramping | Startup losses dominate; do not benchmark yet |
A validated filling line with mandatory cleaning between batches will read lower than a single-product assembly machine and still be the better-run asset. Compare a machine against its own history, same definitions, over months. Cross-plant league tables mostly measure who defined planned downtime most generously.
How Do You Improve OEE?
Find the lowest of the three factors, then let the loss categories underneath it choose the fix. Anything else is guessing.
Raising Availability
Changeover is usually the largest single line item, and it is a mechanical design problem before it is a scheduling one. Tool-free format parts, keyed so no re-teach is required, and recipe-driven adjustment instead of manual dial-setting. On filling platforms we design nest plates that swap without tools for exactly this reason; the custom filling machines page covers how that is specified.
Unplanned stops need failure data before a fix. Drives that already report motor current, temperature and fault history turn “it stopped again” into a repeat-cause list. Bearings, feeders and grippers are the usual offenders.
Safety-related nuisance stops deserve their own audit. Light-curtain trips from operators reaching across a conveyor, interlocked doors opened for a routine reach-in, laser scanner zones set wider than the actual hazard. The fix is layout and zone design, never an override: reposition the guard, add a properly rated muting arrangement, or convert a full stop into a safe reduced-speed state. We build safety doors, interlocks and laser scanner systems with LVD/CE testing on every machine, and a well-zoned cell shows up directly in the Availability column. Cobot safety standards covers the collaborative case.
Material starvation is not a machine fault, but it lands on the machine’s OEE. The four-year QA lab automation programme we run with AMRs, a cobot and server-based task scheduling exists largely to keep instruments fed without a technician standing there.
Raising Performance
Micro-stops first, because they stay invisible until you log them. Record every stop over one second with its trigger sensor, run it a week, sort by frequency. The list is usually short and boring: one feeder escapement, one gripper losing a particular part orientation, one sensor mounted where it catches a reflection.
Feeding is the classic assembly bottleneck. Vibratory bowls with escapements sized for the part, correct track geometry, orientation verification before the pick. A feeder that presents a wrong-way part every fiftieth cycle costs more than it looks like it should.
Reduced-speed running is worth investigating rather than accepting. Machines get slowed for a reason, usually one station that could not hold tolerance at rated speed. Fix that station and the line goes back up.
Raising Quality
Move inspection upstream. A defect caught at final inspection has consumed every downstream station’s cycle time; caught where it was created, it costs one part. Hence vision at several points on a rotary machine, not only at the discharge.
Then measure the process, not only the outcome. Force-monitored insertion with per-cycle logging tells you a press station is drifting before it produces rejects. The copper-plate thickness gauge we delivered in 2026 uses a Keyence displacement system for the same reason: it turns pass/fail into a trend. SICK-based leak-test fixtures do this for sealing.
Startup scrap after changeover is a Quality loss with an Availability cause. Recipe-driven setup with stored parameters, plus a first-article check inside the sequence, shortens it.
Getting OEE Data Off a Machine That Was Never Instrumented
Most machines on a Singapore shop floor were commissioned without any of this. A relay-logic machine has no cycle-active tag and no counter anything can read. Three routes, in ascending order of cost and value:
-
Bolt-on sensing. Discrete sensors and a small edge controller that reads them. Nothing in the original control system changes, so nothing needs revalidating. You get run/stop state and total count, but not honest downtime reasons — the old controller cannot tell you why it stopped.
-
Tap the existing PLC. If there is a modern-enough PLC with spare capacity and a network port, add the collection logic and read the tags directly. Cheapest good outcome, when the platform allows it.
-
Control-system retrofit. Replace the PLC, drives and HMI on a mechanically sound machine. The mechanics stay, the controls become current, the data structure is designed in rather than bolted on. This is now the largest single line of work we do, and the instrumentation is a small addition to a project already justified on obsolescence risk.
Where the data goes afterwards follows the same design sequence as any machine project, described in special purpose machine design. The electronic device history record platform we deliver to a medical device OEM is this problem under regulatory constraints — every parameter attributable and retained.
What to Bring When You Want This Measured
OEE is not a software purchase. It is a wiring and definitions exercise that produces a number, and the number is only worth having if the signals underneath it are honest. To get a useful answer on a specific machine, bring:
- The machine’s control platform — PLC make and model, drive types, HMI, and whether program source is available.
- The design cycle time per product, and the products currently run on it.
- Your current stop-reason list, even if it is a paper log or a whiteboard.
- Where quality is judged today — inline, at a bench, or at final inspection — and who records it.
- What you believe the bottleneck is, and why.
We’ll tell you which of the three factors is actually costing you output, whether it needs sensors, a PLC tap or a full control retrofit, and what changes on the machine itself. If a spreadsheet and a week of manual logging would answer your question, we’ll say that too.
Talk to a Motionwell engineer with those five items and we can scope it from there.