Real-time OEE without manual operator input is possible when every required input has an automated or integrated source. Automate machine facts such as run, idle, down, and count. Integrate planned time, work order, product, ideal rate, and quality from their authoritative systems. Operators can still add reasons or confirm exceptions, but they should not re-enter timestamps the machine already supplied. A current sensor can create machine-state timelines without a PLC; it cannot determine accepted quality, the production plan, or root cause by itself.
TL;DR
- Overall Equipment Effectiveness needs trustworthy Availability, Performance, and Quality inputs.
- Assign one authoritative source to planned time, state, rate, total count, and good count.
- Use PLCs, current sensing, counters, ERP/MES, and quality systems where each is strongest.
- Keep human input for context and exceptions, not routine re-entry of observed facts.
- Validate known stops, shift boundaries, product changes, counts, scrap timing, outages, and edits before rollout.
At-a-glance decision table
| OEE input | Preferred automated or integrated sources | What must be validated |
|---|---|---|
| Planned production time | ERP/MES schedule, dispatch plan, or controlled calendar | Breaks, maintenance, no-order time, and last-minute plan changes |
| Runtime and stops | PLC state, current sensor, machine signal, or validated external sensor | Running/idle/down thresholds, overlapping states, and cross-shift events |
| Ideal rate or cycle time | Approved engineering master, product routing, or controlled target table | Product version, tooling, cavity count, and units |
| Total count | PLC counter, photoeye, machine cycle, or production system | Reset, reject loops, multi-part cycles, and duplicate streams |
| Good count | Quality system, in-line inspection, or controlled disposition record | Scrap timing, rework, delayed inspection, and product identity |
What must be automated for real-time OEE?
Every OEE input needs a current, trustworthy source. A live runtime signal alone is not full Overall Equipment Effectiveness.
OEE combines Availability, Performance, and Quality. ISO treats manufacturing KPIs as formulas with corresponding elements. In practical terms, the OEE formula needs these fields:
| Component | Required facts | Common context |
|---|---|---|
| Availability | Planned production time and runtime/stop boundaries | Shift calendar, breaks, maintenance, no-order time, and schedule changes |
| Performance | Runtime, total count, and approved ideal cycle time or target rate | Product, operation, tooling, cavities, units, and rate version |
| Quality | Good count and total count | Scrap, rework, delayed inspection, product identity, and disposition rule |
"Real time" should describe the data contract, not only the screen refresh. Ask when each input becomes authoritative. A machine state may be immediate while quality disposition arrives later. The platform should show that difference instead of treating a provisional count as final quality.
Define four things for each field: source, update rule, exception, and owner. If two sources can write a total count, decide which wins. If an order changes during the shift, decide when the new ideal rate becomes effective. If a quality result is reversed, decide whether historical OEE restates and how that edit appears.
The goal is not "no humans." The goal is no routine re-entry of facts that a machine or system already knows. People remain essential for context, confirmation, and action.
Choose the right source for each OEE input
Use the strongest source field by field. Hybrid architecture is usually more honest than forcing every input through one capture method.
| Source | Strong fit | Limitation to test |
|---|---|---|
| PLC or machine controller | Rich state, alarm, speed, cycle, and count tags on accessible equipment | Tag meaning, controls access, machine-specific mapping, and change management |
| Clip-on current sensor | Broad run/idle/down and load-pattern coverage on mixed-age motor-driven equipment | Machines whose electrical load does not map cleanly to production state |
| Photoeye or external counter | Independent part or cycle count where movement is observable | Rework loops, multi-part cycles, blockage, and duplicate counts |
| ERP or MES | Schedule, order, product, operation, and approved master context | Update latency, identifier matching, cancellations, and corrections |
| Quality system or in-line inspection | Good/reject status and disposition | Delayed results, reclassification, rework, and product genealogy |
| Controlled manual fallback | Rare context or a temporary gap with clear ownership | Delay, inconsistency, and backfill from memory |
Guidewheel's no-PLC monitoring guide describes current-based state timelines without a PLC or plant-network connection. It also states the central limitation: current-based Availability and Performance data still needs scrap or quality context to complete OEE.
Prefer the source closest to the fact: the machine or validated sensor observes state, the production system owns the order, engineering owns the approved rate, and quality owns disposition. Avoid silent fallbacks. If the quality interface is down, display Quality as incomplete or provisional rather than showing a confident wrong score. A visible data gap is always better than a hidden error.
Prefer the source closest to the fact. The machine or validated sensor observes state. The production system owns the order. Engineering owns the approved rate. Quality owns disposition. A real-time OEE layer joins those facts, preserves lineage, and exposes when one is missing.
Avoid silent fallbacks. If the quality interface is down, display Quality as incomplete or provisional. If the schedule cannot be retrieved, flag planned time. A confident wrong score is worse than a visible data gap.
What can be automatic and what still needs context?
Automate observed facts. Ask people for explanations only when those explanations change a decision.
| Machine or system can observe | Human or workflow may add | Why both matter |
|---|---|---|
| State transition and timestamp | Provisional downtime reason | Detection is objective; context explains the operational situation |
| Count or cycle | Confirmation of abnormal counting condition | Automation captures volume; people flag rework or blocked flow |
| Product/order change from an interface | Confirmation when the source is missing or wrong | The system supplies context; users manage exceptions |
| Quality disposition | Cause of defect or containment action | Quality status and causal diagnosis are different facts |
| Alert and acknowledgment | Action taken and result | The event becomes an improvement record |
Do not ask an operator to enter "machine stopped at 10:14" after the sensor already captured it. Present the event and offer a short context workflow: confirm the current reason, choose unknown, or assign follow-up. Preserve the original timestamp and every later edit.
"Unknown" is useful data. It shows where the taxonomy, training, or diagnostic process needs work. Forcing a precise cause during the stop creates false confidence. Root cause often belongs to maintenance, engineering, or continuous improvement after evidence is available.
Design role-specific views. The OEE dashboard guide distinguishes operator, line, and plant decisions. Operators need state and target. Supervisors need current exceptions and owners. Improvement leaders need stable component trends and loss patterns. Leadership needs progress and action closure, not a crowded live feed.
How to implement real-time OEE without manual logs
Build the data contract before the dashboard, then validate one representative line before scaling.
- Approve definitions. Document planned time, Availability, Performance, Quality, ideal-rate policy, count rules, exclusions, units, rounding, and restatement behavior.
- Inventory assets and operating modes. Record available PLC tags, electrical/cycle patterns, counters, products, rate changes, quality flow, and known exceptions.
- Assign authoritative sources. Name the primary and fallback for every field. Define identifier, timestamp, update, retry, correction, and ownership rules.
- Configure state and count logic. Use PLC, current, counter, or another validated signal. Preserve raw observations and the logic version that turns them into states.
- Integrate production context. Connect schedules, orders, products, targets, and quality where those systems are authoritative. Surface stale or missing context.
- Design the exception workflow. Present auto-created events for confirmation or context. Keep unknown available. Separate provisional reason, confirmed cause, and corrective action.
- Run acceptance tests. Reconcile known events, shifts, products, counts, quality, outages, and edits. Fix the source or rule rather than manually correcting the final percentage.
- Publish role-specific views. Give each user the smallest view that supports a decision and a named response.
- Govern and scale. Control definition changes, retain lineage, monitor interfaces, review data quality, and expand by asset segment.
Keep the manual log during validation only as comparison evidence, not as a parallel permanent truth. When a difference appears, investigate its source. The sensor may need tuning; the schedule may be wrong; the manual record may be late; the product mapping may have changed.
Scale after the hardest representative condition passes. Copying an unvalidated model across the plant multiplies error faster than it creates visibility.
Validation tests before you trust the number
Trust real-time OEE only after each component and exception path reconciles independently.
| Test | Evidence | Failure to investigate |
|---|---|---|
| Known run/stop event | Independent observation and raw signal | Wrong threshold, delayed event, overlapping state, or clock issue |
| Shift boundary | Calendar, event timeline, and component totals | Double-counted or split event; wrong time zone |
| Break or planned maintenance | Approved schedule and OEE calendar | Necessary time incorrectly counted as loss or excluded without approval |
| Product/rate change | Product event and approved rate version | Old rate persists or changes at the wrong time |
| Counter reset | Source counter and accumulated total | Lost, duplicated, or negative count |
| Multi-part cycle | Cycle event, cavity/tooling context, and count | One cycle treated as one part when output differs |
| Scrap and rework | Quality disposition history | Quality changes too early, too late, or against the wrong product |
| Interface outage | Connection log and recovered events | Silent data loss, duplicate replay, or stale context |
| Edited reason or source record | Before/after values, author, time, and rationale | History overwritten without audit |
Review component trends, not only the combined number. An apparently stable OEE can hide an Availability decline offset by a Quality correction. Preserve provisional states when source data is incomplete.
Set plant-approved tolerances and stop conditions before testing. A failed mandatory test blocks rollout until resolved or explicitly scoped out. Do not compensate for a failed data requirement with a better dashboard demonstration.
Where Guidewheel fits
Guidewheel can supply the real-time machine-state layer across mixed-age equipment. Its FactoryOps platform uses non-invasive machine signals, shared views, alerts, and integrations to connect floor observations with existing systems.
The fit is strongest where runtime and stop logging still depends on memory or where PLC access does not cover the fleet. The platform does not make production plan, product, ideal rate, or quality context disappear. Those fields still need authoritative sources and validation.
Cantex illustrates the problem at one plant. Guidewheel's case study says Cantex's prior manually logged ERP production data was off 50% of the time and that Guidewheel data replaced manual shift logs for production reports. That is a Cantex-specific account, not a universal manual-error rate.
If manual runtime reporting is your binding gap, evaluate one representative line. Bring the input-source map and acceptance tests. The goal is not merely a live score; it is a number the floor can trace, trust, and use.
See the full feature by feature comparison
Frequently asked questions
Can OEE be calculated without any operator input?
Yes, when planned time, runtime, ideal rate, total count, and good count all have reliable automated or integrated sources, although human context can still improve diagnosis.
Can current sensors measure all three OEE components?
No. Current sensing can support machine-state and sometimes cycle evidence, but it cannot independently determine the production plan, accepted quality, product-specific ideal rate, or root cause.
Do you need a PLC for real-time OEE?
No. Validated external sensors can capture machine states without PLC access, while ERP, MES, quality, counters, or controlled master data provide the remaining OEE inputs.
How should downtime reasons work without manual logs?
Create event timestamps automatically, then let operators or supervisors add concise observed context and allow qualified owners to confirm root cause later without overwriting the original record.
What should you test before trusting automated OEE?
Test known stops, schedules, shift boundaries, product and rate changes, counter resets, multi-part cycles, quality timing, outages, late data, duplicate events, edits, and source reconciliation.
Not sure which tool fits your plant?
30 minutes with your machines, your sites, your numbers. No slideware.