OEE Data Collection Methods: Manual, Sensor and Camera Capture Compared
Key takeaways
- The collection method decides which losses your OEE can even see; the number is only as honest as the events behind it.
- Manual logging is cheap and rich in context, but it systematically misses short stops and rounds durations at shift end.
- Sensors and PLCs timestamp every stop precisely but cannot say why it happened, and events with no signal stay invisible.
- The most trustworthy setups are hybrid: machine signals for states and counts, cameras for true cause, people to confirm reason codes.
OEE data collection methods fall into three families: manual logging by operators, automatic capture from sensors and PLCs, and camera-based vision systems, and most plants end up combining at least two of them. The method you choose decides whether your OEE number can be trusted, because every method sees some losses clearly and is blind to others. This guide compares all three honestly: what each captures, what each misses, and how to tell when your data is lying to you.
Why the collection method decides whether OEE is trustworthy
An OEE figure is not a measurement, it is a calculation built on top of event records: when the machine ran, when it stopped, why it stopped, how many parts it made and how many were good. Change how those events are captured and the same shift on the same machine can produce very different OEE numbers. That is why two plants running identical equipment can report figures that are not comparable at all: one logs stops on paper at shift end, the other timestamps them from the PLC.
This matters because OEE is used to justify real decisions: capital requests, staffing, maintenance priorities, which line gets the improvement team next. If the data under the number is biased, every decision inherits the bias. A plant chasing the commonly cited 85% world-class benchmark on flattering data will invest in the wrong problems while the real losses stay hidden. Before comparing your OEE with anyone else's, or even with last year's, ask how the events behind it were collected.
Manual logging: cheap to start, biased by design
Manual collection means an operator or team leader records stops, reasons and counts on paper, a whiteboard or a spreadsheet. It is the cheapest way to start, it needs no integration work, and it captures something automatic systems struggle with: context. A person can write "waiting on forklift for raw material" or "label reel snapped twice on changeover", which is exactly the kind of reason a root cause effort needs.
The weaknesses are structural, not a question of operator honesty. Someone clearing a jam cannot also be timing it, so durations get rounded and reconstructed at the end of the shift. Stops shorter than a few minutes rarely get written down at all, which quietly deletes micro-stops, often the largest single loss on packaging and moulding lines. And there is an unavoidable conflict of interest: people are less likely to log delays that reflect on their own area, so recorded reasons drift toward machine faults and away from organisational causes like missing materials or slow changeovers.
Manual logging is still the right first step for a plant with no data at all. Treat the resulting OEE as directional, standardise a short reason code list so entries are comparable, and expect the number to drop when you later automate capture. That drop is not performance getting worse, it is the data getting honest.
Sensor and PLC capture: accurate states, missing reasons
Sensor and PLC capture pulls machine states automatically: run signals, fault bits, cycle counters and part-present sensors, taken from the PLC directly or from retrofit sensors on older equipment. Timing accuracy is its great strength. Every stop is timestamped to the second, nothing is reconstructed from memory, and the micro-stops that manual logs never see suddenly appear in the record. Counts and speeds come straight from the machine, so availability and performance calculations rest on solid ground.
The blind spot is the reason. A PLC knows that the machine stopped; it usually cannot know why. Fault codes describe the machine's own diagnostics, not your loss categories, and many of the most expensive events generate no signal at all: an operator pausing the line to clear a jam by hand, idle time waiting for material or a quality decision, a cell stopped because the upstream process starved it. In a signal-only system these all collapse into one undifferentiated "stopped" state, and someone still has to attach a reason after the fact, which reintroduces the same human bias manual logging suffers from, just later in the process.
Camera and vision capture: seeing what the signals miss
Camera-based capture points a camera at the cell and uses vision software, human review or both to classify what actually happened during a stop. Its unique value is evidence. Where a PLC records "stopped, 14:32 to 14:41", video shows the operator fetching a tool, the forklift arriving late or the changeover overrunning at one specific step. Events with no electrical signal, exactly the category sensors miss, are the ones a camera sees best. It also ends arguments: when maintenance and production disagree about what caused a stop, footage settles it faster than any meeting.
The trade-offs are real. Cameras raise privacy and works council questions that must be handled openly, with the clear framing that the system watches the process, not the people. Lighting, camera placement and housekeeping around the cell affect what can be classified. And a camera is a poor substitute for a cycle counter: it complements state data rather than replacing it. Plants that get value from vision use it to explain stops that signals have already detected, not to detect stops in the first place.
The hybrid reality, and how bad data shows up
In practice almost no plant runs on a single method. The common pattern is layered: PLC and sensor signals provide the timeline and the counts, cameras or structured operator input provide the cause, and a person confirms or corrects reason codes on the exceptions. Each layer covers another layer's blind spot. The question is not which method wins, it is which combination gives you defensible states, honest reasons and affordable effort on your specific lines.
Whatever you run today, the data itself will tell you when the collection method is failing. The classic symptoms:
Fixing these symptoms is a collection problem before it is an improvement problem: get states from the machine, get causes from evidence rather than memory, and make logging a by-product of the work instead of extra work. The partner we recommend, Fabrico, reads stops directly from machine signals and shows the true cause on video, so a reason code becomes evidence instead of a guess. Fabrico is a partner we recommend; the tools here are free regardless.
- OEE looks too good. Figures at or above the commonly cited 85% world-class benchmark on a line that still misses its schedule usually mean losses are not being captured, not that the line is world class.
- The "other" bucket dominates. When the biggest downtime category is "other", "unknown" or "miscellaneous", reasons are being invented at shift end rather than recorded at the event.
- No short stops in the record. If the shortest logged stop is several minutes long, micro-stops are being absorbed into cycle times and your performance losses are hiding, or vanishing entirely.
- Downtime does not reconcile. Add up logged run time, downtime and changeovers; if the total falls well short of the scheduled shift, the gap is unrecorded loss.
Size the prize with the free OEE and downtime calculators.
FAQ
Which OEE data collection method is the most accurate?
For stop timing and part counts, sensor or PLC capture is the most accurate, because every event is timestamped automatically. For stop reasons, no single method wins: signals detect that a stop happened, while cameras and structured operator input explain why. The most trustworthy data comes from combining them.
Is manual OEE data collection good enough to start with?
Yes. Manual logging is the right first step when you have no data at all, and the reason context operators write down is genuinely valuable. Just treat the resulting OEE as directional: expect short stops to be missing and durations to be rounded, and expect the number to fall when you automate capture.
Why does my automatic OEE system show so much unknown downtime?
Because signals tell you that the machine stopped, not why. Any event without its own electrical signature, such as a manual intervention, waiting for material or upstream starvation, lands in the unknown bucket unless a person or a camera attaches a cause. Fix it by simplifying reason codes and capturing evidence at the point of the stop.
Do camera-based systems replace sensors and PLC data?
No. Cameras are strongest at explaining stops and capturing events that generate no signal, but they are a poor substitute for cycle counters and machine state signals. In practice vision works alongside PLC data: the signals build the timeline, the video explains it.
Related: what is OEE · micro-stops & the hidden factory · the six big losses · how to calculate OEE