What machine data do you need to calculate OEE automatically?

Three signal families: a run/stop state with timestamps for availability, a cycle or part count for performance, and good versus reject counts for quality. Run state and counts can come from PLC tags on newer machines or from retrofit sensors like photo eyes and current sensors on older ones. Quality can stay a human entry where machines cannot judge it.

Why is manually tracked OEE usually wrong?

Because operators log downtime between everything else they do. Stops under a few minutes rarely get written down, end-of-shift entries are reconstructed from memory, and slow cycles never appear at all. The result is inflated availability and invisible performance loss. Automatic capture removes the recording burden and keeps every event.

Do I need new machines or a new control system to connect machines for OEE?

No. Machines with PLCs usually already hold the needed tags, and machines without networking can be fitted with simple sensors for counts and run state. Connecting for OEE is a mapping and retrofit exercise, not a replacement project, and it works across mixed-vintage lines.

Should I expect my OEE score to drop after connecting machines?

Very often, yes, because automatic capture counts the micro stops and slow cycles that clipboards miss. The drop means the measurement got honest, not that the line got worse. The honest baseline is what makes improvement real, since you can now see and rank the losses you were previously guessing at.

Which machines should I connect first for OEE?

Start with the constraint line, the one that gates total plant output, because an availability or performance point recovered there converts directly into shippable product. Prove the loop of measure, review, fix on one line, then expand with the playbook you built.

How is automatic OEE different from a machine monitoring system?

Machine monitoring collects states and counts; OEE is one calculation on top of that data. The bigger difference is what surrounds it: an operational layer joins machine data with schedules, products, and operator context, so the OEE number comes with reasons and can drive daily decisions rather than sitting in a report.

Connecting Machines for OEE: Beyond Clipboard Math

Availability and counts straight from the equipment, so the score finally matches what the line actually did.

Connecting machines for OEE means feeding run states and part counts from the equipment itself into the OEE calculation instead of relying on clipboard logs. Automatic capture records every stop and every cycle, including the short ones manual tracking misses, so the score matches what the line actually did. Most plants that move from manual to automatic capture watch their availability number drop, sometimes sharply. That is not the system being pessimistic. It is the first honest reading the plant has ever had, and it is the starting point for every real improvement that follows.

This guide covers why clipboard OEE misleads, exactly which machine signals the calculation needs, how to wire them in on equipment of any age, and what changes on the floor once the numbers arrive on their own. If you want the formula itself first, start with our OEE calculation guide and the free OEE calculator, then come back here for the connectivity side.

Why does clipboard OEE mislead you?

Clipboard OEE misleads because the person recording the data is the same person running the line, and running the line always wins. When a machine jams for ninety seconds, the operator clears the jam. They do not stop to write down the start time, end time, and reason code for a ninety-second event, and nobody should expect them to. So short stops vanish. At the end of the shift, the operator reconstructs the day from memory, and memory rounds generously: a dozen small stops become one entry that says fifteen minutes, or nothing at all.

The damage concentrates in two of OEE's three factors:

Availability inflates. Micro stops and minor stoppages, two of the classic six big losses, are precisely the events manual logging cannot see. A line that looks 90 percent available on paper is often far lower when a sensor counts every stop.
Performance hides in plain sight. Manual tracking almost never captures slow cycles. If the machine is nominally rated at 60 parts a minute but has been quietly running at 52 since the last changeover, a clipboard shows a running machine and a paper count that seems fine. Only a cycle-by-cycle count reveals the speed loss.
Quality data lags. Reject counts written at end of shift cannot tell you which hour, which setting, or which pallet of material produced the scrap.

None of this is an operator problem. It is a data collection problem, and the fix is to take data collection off people entirely. Our guide on machine signals that matter goes deeper on the signal side; the short version follows.

Which machine signals does OEE actually need?

OEE needs exactly three families of signals, one per factor. Everything else is context.

Run/stop state feeds availability. A single boolean that says the machine is producing or it is not, timestamped at every transition. From this one signal you get run time, stop count, stop duration, and the shape of your downtime.
Cycle count feeds performance. Total cycles or parts attempted, compared against ideal cycle time, exposes speed losses and micro stops that are too short to register as availability events.
Good and reject counts feed quality. Where the machine or an inline inspection knows the difference, capture it. Where it does not, quality stays a human entry, and that is fine: two of three factors on automatic capture is still a transformation.

OEE only needs three signal families from a machine. Run/stop state drives availability, cycle counts drive performance, and good/reject counts drive quality.

Where do the signals come from? On newer equipment, they usually already exist as PLC tags, and connecting is a mapping exercise; see our PLC tag mapping guide. On older equipment with no network port, retrofit options work well because OEE's needs are so modest: a photo eye or proximity sensor gives you a cycle count, a current sensor on the motor gives you run/stop, a stack light tap gives you state. Our guide to connecting legacy machines walks through each method. The point is that machine age is not a barrier. A 1980s press can report availability just as faithfully as a new one.

How do you connect machines for OEE, step by step?

The path from clipboard to automatic OEE is a sequence of small decisions, not a big project. A workable order:

Pick one line, ideally the constraint. The line that gates plant output is where an OEE point is worth the most money.
Inventory signal sources. For each machine on the line, note whether run state and counts exist in a PLC, a sensor, or nowhere yet. Ten minutes per machine with an electrician answers this.
Choose the collection method per machine. PLC tags where they exist, retrofit sensors where they do not. Do not wait for the perfect signal; a current sensor today beats an integration project next year.
Define machine states with the crew. Decide what counts as planned downtime, unplanned downtime, changeover, and idle, and write it down. Availability arguments are almost always definition arguments; see machine downtime for a working taxonomy.
Map counts to products. A count is only meaningful against an ideal cycle time, and ideal cycle time varies by SKU. Load the rates per product so performance calculates honestly.
Let the operational layer do the math. States and counts flow in, OEE comes out continuously, per shift and per SKU, with stop reasons attached where operators add a tap of context.
Review the number daily where the crew can see it. A score nobody discusses changes nothing. Ten minutes at the start of each shift on yesterday's losses is where the return lives.

Notice what is not on the list: replacing machines, rewiring the plant, or a year of integration. This is deliberate, and it is how the economics stay sane; our post on the ROI of connecting machines breaks down the cost side.

What changes when the numbers arrive on their own?

The first change is that the score usually drops, and the second is that people finally trust it. A clipboard OEE of 78 that everyone quietly disbelieves is worth less than a measured 61 that everyone accepts, because only the second number supports decisions. Plants often find the honest baseline sits well below the widely cited 85 percent world-class benchmark; our guide to what a good OEE score is explains why that is normal and not alarming.

The practical differences show up within days:

Micro stops become a category you can attack. When the system shows 47 stops under two minutes on the filler in one shift, the conversation changes from arguing about the number to fixing the feeder.
Losses get names. Automatic states plus light operator tagging sorts downtime into the six big losses, which is what makes Pareto-driven improvement possible.
Slow cycles surface. Rate losses that manual tracking has never once caught appear on the first day of cycle counting.
Operators stop doing paperwork. The time that went into tally sheets and end-of-shift reconstruction goes back into running the line. Machine monitoring covers what continuous visibility looks like in practice, and live dashboards shows how the data reaches the floor.

Manual logging compresses a messy hour into one remembered stop. Connected capture keeps every event, including the slow-running stretch no clipboard has ever recorded.

What do the standards say about machine data for OEE?

The plumbing that carries availability and count signals is mature, open, and standardized, which is a large part of why connecting machines has become affordable:

Modbus, published in 1979, remains one of the most widely implemented industrial protocols, which means even decades-old equipment often has a standard way to report registers like counts and states.
OPC UA is standardized as IEC 62541 and gives modern PLCs a vendor-neutral way to expose typed, described data such as machine state and production counts.
MQTT, standardized as ISO/IEC 20922, and the Sparkplug specification, published as ISO/IEC 20237 in 2023, define the lightweight publish-subscribe transport most modern edge devices use to move those signals with report-by-exception efficiency.

In practice a plant meets a mix of all of these across machine vintages. Our overview of protocols for machine connectivity explains what each one is for and how they get translated into a single stream.

Where does Harmony AI fit?

Harmony AI connects your machines, software, and paperwork into one real-time operational layer, and OEE is one of the first things that layer produces on its own. Availability comes from machine states, performance from counts against per-SKU rates, and quality from inspection data or a quick operator entry, with AI agents summarizing losses by shift and flagging the patterns worth a morning conversation. There is no rip-and-replace: Harmony AI connects to the PLCs and sensors you already have, whatever mix of protocols they speak, and the field team deploys in person, typically visiting once or twice to walk the floor and wire the rollout around how your lines actually run. The CLS case study shows the progression from paper logging to real-time visibility on a working decoration line. When you want to see what an honest score would be worth, run your numbers through the OEE calculator, or see everything the platform connects on the features overview.