I don't have a signals to calculate OEE. What should I do?

There's plenty of material explaining the OEE formula itself — Availability × Performance × Quality — but far less on the actual data that formula depends on. Before any of those three numbers can be calculated, specific raw signals have to be captured from the machine, correctly interpreted, and turned into the right inputs. This article is about that data layer: which signals actually matter for OEE, and where each one typically comes from.

Contents:

1. Why the signal layer matters more than the formula
2. Signals behind Availability
3. Signals behind Performance
4. Signals behind Quality
5. Where these signals actually come from
6. Common signal gaps and workarounds
7. Frequently asked questions
8. Conclusion

Why the signal layer matters more than the formula

The OEE formula itself is simple and well documented — we cover it in full in our complete OEE guide and measuring OEE in practice. What determines whether an OEE number is actually trustworthy has less to do with the formula and much more to do with the quality and completeness of the signals feeding it. Two shops using the identical formula can end up with very different confidence in their OEE numbers depending on whether their run-state detection is accurate, their ideal cycle time is realistic, and their scrap counts are actually captured rather than estimated.

Signals behind Availability

Availability compares actual run time to planned production time, which means it depends on accurately knowing when a machine was genuinely running versus stopped, and why.

Without reason codes specifically, Availability can tell you a machine was down, but not why — which limits how actionable the number actually is beyond a raw percentage.

Signals behind Performance

Performance compares actual output speed against ideal speed, which depends on accurately capturing how fast the machine actually ran relative to what it should have.

Performance is often the most misleading of the three components in practice, since it depends heavily on having a genuinely accurate ideal cycle time as a baseline — an unrealistic baseline makes the resulting percentage meaningless regardless of how good the underlying signals are.

Signals behind Quality

Quality compares good parts produced to total parts produced, which depends on capturing both numbers accurately — something that's often less automated than Availability or Performance data.

Quality is frequently the weakest-instrumented of the three OEE components, since scrap and rework data commonly lives in a separate quality system, a paper process, or an operator's memory rather than in the machine's own data stream.

Where these signals actually come from

Most Availability and Performance signals come directly from the CNC controller or its PLC, reachable through whichever connection method fits the machine — MTConnect, OPC UA, a vendor-specific protocol, or, for older equipment, PLC or signal-based access. We cover this connection layer generally in our data acquisition architecture overview, and for machines without a usable protocol, in connecting machines with no open protocol. Quality signals are the exception: they frequently originate outside the machine entirely, in a separate quality management system, a manual inspection log, or operator input, which means a complete OEE picture often requires integrating more than one data source rather than relying on machine connectivity alone.

Common signal gaps and workarounds

• No reason codes for downtime. Machine data alone usually can't explain why a stop happened; some form of operator input, however lightweight, is typically needed to make Availability data actionable rather than just descriptive.
• Unrealistic or missing ideal cycle time. Performance is meaningless without a credible baseline; this has to be defined deliberately, not inferred automatically from historical averages that might already include inefficiencies.
• Scrap data not captured at all. On some shop floors, Quality ends up assumed at 100% by default simply because no scrap signal exists — which quietly overstates OEE rather than reflecting reality.
• Micro-stops invisible to the system. Very short pauses that don't trigger a full "stopped" state can still meaningfully affect Performance without showing up as discrete downtime events.

Frequently asked questions

Can OEE be calculated with only machine-sourced data, no manual input?

Availability and Performance can often be calculated largely from machine data alone. Quality frequently cannot, since scrap and rework information commonly lives outside the machine, making at least some manual or system-integrated input necessary for a complete, accurate OEE figure.

What's the minimum signal set needed to start tracking OEE at all?

At a minimum: a reliable run/stop signal for Availability, a defined ideal cycle time paired with actual cycle time or part counts for Performance, and some method — even manual — of recording scrap or rejects for Quality. More signals improve accuracy and reason-code detail, but this minimum set gets a usable starting number.

Why does my OEE number look higher than it feels on the shop floor?

This is often a signal gap, not a calculation error — commonly an ideal cycle time set too conservatively, micro-stops not being captured, or scrap data that's incomplete, all of which inflate the resulting percentage without the formula itself being wrong.

Do all three OEE components need the same level of data granularity?

Not necessarily. Availability generally benefits from high-frequency, near-real-time state data, while Quality data is often captured at a coarser, per-batch or per-shift level without materially affecting the usefulness of the resulting metric.

Conclusion

The OEE formula is the easy part; the harder and more consequential work is making sure the signals feeding it — run state, cycle time, part counts, scrap data — are actually accurate and complete. A shop with imperfect signals but a clear understanding of where the gaps are can trust its OEE number more than one with a technically correct formula built on data nobody has actually checked. From raw signals, the next step is turning them into the specific metrics that show up on a dashboard, which we cover separately.

Related articles:

• OEE Production KPI: Complete Guide
• Measuring OEE in Practice: Formula and Results
• What Is Overall Equipment Efficiency?
• CNC Data Acquisition: Architecture Basics
• MDCplus Machine Connectivity & Integrations

About MDCplus

Our key features are real-time machine monitoring for swift issue resolution, power consumption tracking to promote sustainability, computerized maintenance management to reduce downtime, and vibration diagnostics for predictive maintenance. MDCplus's solutions are tailored for diverse industries, including aerospace, automotive, precision machining, and heavy industry. By delivering actionable insights and fostering seamless integration, we empower manufacturers to boost Overall Equipment Effectiveness (OEE), reduce operational costs, and achieve sustainable growth along with future planning.