Improving OEE Through a Line Performance Assessment: A Controls Integrator’s Approach
Most plants already track overall equipment effectiveness (OEE), and most of those numbers are wrong. Not wildly wrong, usually, but wrong in the direction that hides money. One line reports 82% OEE while a hand count of good parts against theoretical capacity says something closer to 68%. The gap is rarely an arithmetic error. It comes from where the data was captured, what the line counted as a stop, and how micro-losses got rounded away.
That gap is the reason to look at OEE from the controls and data side rather than the spreadsheet side. A line performance assessment starts at the PLC, the drives, and the sensors, because that is where the truth about a line’s losses actually lives.
What OEE Actually Measures
OEE is the product of three factors: Availability, Performance, and Quality. Availability is the share of scheduled production time the line was actually running. Performance is how fast it ran against its ideal cycle time while it was running. Quality is the share of parts that came off good the first time, without rework or scrap. Multiply the three and you get a single percentage that expresses how much of a line’s theoretical output you actually captured.
The formula is simple. The honesty of the inputs is not. A world-class benchmark of 85% assumes each factor is measured against a defensible standard: real scheduled time, a real ideal cycle time, a real first-pass quality count. Change any of those reference points and the number moves without the lin
e changing at all. That is the first thing a controls integrator checks, and it is usually where the reported figure starts to come apart.
Why Your OEE Number Is Probably Wrong
Manual and semi-manual data collection loses the losses. When an operator logs downtime on a clipboard or a tablet, short stops under a few minutes rarely get recorded. Those micro-stops, a jam cleared in ninety seconds, a photo-eye blocked and reset, a station starved for thirty seconds, are individually trivial and collectively enormous. On a high-cycle line they can account for more availability loss than the big, obvious breakdowns everyone already tracks.
Ideal cycle time is the second common error. Many plants set it to the rated nameplate speed, or to a number negotiated years ago, rather than to the fastest sustained rate the line has actually demonstrated. If the standard is soft, Performance loss disappears into it, and the line looks like it is running at pace while it quietly leaves throughput on the floor.
Then there is the boundary problem: what counts as a stop, what counts as planned versus unplanned, and where one asset’s downtime becomes the next asset’s starvation. Answer those definitions inconsistently across shifts and the OEE trend becomes noise. None of these are math mistakes. They are data-capture and definition problems, and they are fixable at the controls layer.
Where the Losses Actually Hide
Read from the automation layer, each OEE factor points at a different class of fix.
Availability losses show up in the PLC state history and fault logs. Real-time capture timestamps every stop, tags it to the station that caused it, and separates true downtime from blocked-and-starved time propagating down the line. That distinction matters: throwing maintenance at a machine that is actually starved by an upstream bottleneck fixes nothing. The data tells you which station is the constraint.
Performance losses live in the drives and the cycle data. Comparing actual station cycle times against the demonstrated best rate exposes the slow stations and the speed losses that never trip an alarm. Few lines announce that they are running four percent under pace. The servo and cycle data say so, if someone is capturing it.
Quality losses hide when scrap and rework are counted at final inspection instead of at the station that created the defect. Tying quality data back to process signals, a temperature that drifted, a torque curve out of band, a vision reject at a specific fixture, turns a Quality percentage into a root cause instead of a tally.
What a Line Performance Assessment Looks At
A line performance assessment is a structured assessment of a production line’s OEE from the data and controls side, aimed at finding where output is being lost and what it would take to recover it. It works from the signals the equipment already produces, plus the instrumentation it is missing.
The review typically covers four things. First, what the line is currently capturing: which stops, cycles, and quality events are logged automatically, and which depend on someone remembering to write them down. Second, the integrity of the standards: whether scheduled time, ideal cycle time, and first-pass quality are defined consistently and defensibly. Third, the loss map: where availability, performance, and quality losses actually concentrate once real data is on the table, and which few stations drive most of the gap. Fourth, the instrumentation and visibility gap: what sensors, PLC logic, or SCADA data model would need to change to make those losses visible in real time going forward.
The output is a prioritized picture of recoverable output, ranked by what the data supports, rather than a generic list of control system upgrades. Some fixes are mechanical or procedural and cost little. Others justify new instrumentation or a SCADA and historian layer that pays for itself in recovered throughput. The review tells those apart before anyone spends.
How Data Visibility Turns Into Recovered Output
The durable fix is capturing loss data automatically and putting it where operators and engineers can act on it. That means PLC logic that classifies and timestamps stops as they happen, a SCADA or historian layer that aggregates cycle and downtime data across the line, and dashboards that show OEE and its three factors in near real time rather than in a report assembled next week.
The value is speed of response. A downtime Pareto that updates live tells a team which station to attack this shift, not which one hurt last month. Trended performance data catches a cycle-time drift while it is still small. First-pass quality tied to process signals flags a drifting station before it fills a scrap bin. This is the controls contribution to OEE that a general operational-excellence engagement usually cannot deliver: the measurement system itself has to be built and integrated before the improvement work has solid ground to stand on.
Patti Engineering comes at OEE from control systems and data integration rather than from lean workbooks alone. We work across Siemens, Ignition, and multiple platforms, which matters when a line’s data has to be pulled from mixed controls and unified into one honest view. Cross-industry pattern recognition helps too: a hidden micro-stop problem often has the same shape once you read it from the data.
Frequently Asked Questions
An OEE of 85% is a commonly cited world-class benchmark for discrete manufacturing. The more useful question is whether your score is measured against honest standards. A defensible 65% tells you more than an 85% built on a soft cycle-time standard and unlogged micro-stops. Before comparing your number to a benchmark, confirm what it is actually measuring.
Almost always because losses are not being captured. The math is rarely the problem. Manual downtime logging misses short stops, ideal cycle time is often set below the line’s demonstrated best rate, and quality issues get counted at final inspection instead of at the source. Each of these inflates the reported figure. Automated data capture at the controls layer is what closes the gap between the reported number and the real one.
OEE equals Availability multiplied by Performance multiplied by Quality. Availability is run time divided by planned production time. Performance is actual output divided by the output the ideal cycle time would have produced in that run time. Quality is good parts divided by total parts produced. Their product is the OEE percentage. The arithmetic is straightforward; capturing each input accurately is the hard part.
It varies by line, but availability losses from unlogged micro-stops are the most commonly underestimated. Because each stop is short, operators rarely record them, so they never appear in the reported number even though they add up to a large share of lost time. Real-time capture from the PLC is often the single change that reveals the most previously invisible loss.
Not always. Many lines already generate enough signal at the PLC and drive level to reconstruct accurate availability and performance data; the gap is that nobody is capturing or modeling it. A review of the existing controls determines what they already expose before recommending new instrumentation, so you add sensors only where the data genuinely is not there.
A lean engagement focuses on process, standard work, and waste reduction, and it depends on trustworthy data to target that work. A controls integrator builds the measurement system that produces the data: PLC logic, SCADA, historians, and dashboards that capture losses automatically and in real time. The two roles are complementary, but when the underlying OEE data is unreliable, the controls and instrumentation work has to come first.
A prioritized map of where a line is losing output across availability, performance, and quality, built from actual equipment data rather than estimates, along with the specific instrumentation or integration changes needed to make those losses visible going forward. The deliverable ranks recoverable output by what the data supports, so improvement spending goes to the constraints that actually move the number.
If your OEE number and your shipped-part count do not agree, the problem is usually in how the line is measured. Patti Engineering conducts line performance assessments that start at the controls and data layer, find where output is genuinely being lost, and build the real-time visibility that keeps it found. Reach out to talk through your line and what the data is, and is not, telling you.
Related categories: Blog Automation & Industry 4.0 Control Systems
