Engineering Guide to Real-Time OEE Implementation

If you walk into a plant manager's office today and ask for their OEE (Overall Equipment Effectiveness), they will likely point to a whiteboard or open an Excel spreadsheet. "Last week," they'll say, "we ran at 72%."

This number may not reflect the full picture.

In traditional manufacturing, OEE is sometimes treated as a lagging indicator. It's calculated after the shift ends, often by summing up manual logbooks where downtimes are rounded to the nearest 15 minutes, and short stops might be missed. While this "Analog OEE" provides a baseline, manual tracking often lacks the resolution needed to solve deep process bottlenecks.

True digital transformation demands Real-Time OEE. This isn't just another dashboard metric; it's a high-resolution forensic tool that exposes the microscopic inefficiencies bleeding your profitability.

In this deep-dive guide, we move beyond the basic math. We explore how to architect a real-time OEE engine using a Unified Namespace (UNS), how to handle complex machine states (Starved vs. Blocked) at the edge, and how Proxus captures the "invisible" losses that manual logging misses.

Observed performance depends on workload shape, node capacity, and deployment design.

The Anatomy of "Real" OEE

Before writing code, we typically should agree on the philosophy. Real-time OEE differs from reported OEE in three critical ways:

1. Granularity: It captures events in milliseconds, not minutes.
2. Context: It knows what product is running (SKU context) to determine the exact theoretical speed.
3. Automaticity: It reduces sampling limitations. High-frequency PLC states drive the calculation natively.

The Six Big Losses: A Digital Mapping

To build a robust OEE engine, you typically should map the classic TPM "Six Big Losses" to digital signals in your Edge Gateway.

Why OEE Must Be Calculated at the Edge

Many IIoT platforms make the mistake of piping raw sensor data to the cloud and calculating OEE there. This is a fundamental flaw.

For low-latency and offline resilience, OEE is typically best calculated at the Edge.

Why?

1. Latency: Operators need to know now that they are falling behind, not 15 minutes later when a cloud batch job finishes.
2. Data Volume: Sending every millisecond status change across the WAN is expensive and brittle.
3. Resolution: Capturing a 200ms micro-stop requires improve local processing power.

The Logic Flow

In the Proxus architecture, the OEE logic runs inside a Docker container directly on the factory floor (the Edge Gateway).

The Killer Feature: Catching Micro-Stops

This is where you earn your ROI. A "Micro-Stop" is a stoppage typically shorter than 2-5 minutes. Operators rarely log these. They clear the jam, hit reset, and keep going.

However, if a machine stops for 30 seconds, 40 times a shift, you have lost 20 minutes of production. That is a massive chunk of your Availability vanished into thin air.

Implementing Micro-Stop Logic with C#

Using the Proxus Scripting Engine, we can detect these automatically. Here is a simplified logic pattern:

// Proxus Edge SDK: Mikro Duruş Dedektörü
// FunctionBase sınıfından türetilmiş bir Edge Fonksiyonu

public class MicroStopDetector : FunctionBase {

 private DateTime _lastStopStart;
 private bool _isStopped;
 private const double MICRO_STOP_THRESHOLD = 120.0; // saniye

 public MicroStopDetector(object sys, object log, object cfg)
 : base(sys, log, cfg) { }

 protected override void OnStarted() {
 // Tüm yerel cihazlardaki TransportData mesajlarına abone ol
 Subscriptions?.Add(new SubscriptionContext {
 Type = typeof(TransportData),
 Topics = (HashSet<string>) ["*"]
 });
 base.OnStarted();
 }

 protected override void OnMessageReceive(FunctionContext ctx) {
 if (ctx.Message is TransportData data) {
 var state = data.GetPayloadValueByName<string>("State");

 if (state == "STOPPED" && !_isStopped) {
 _lastStopStart = DateTime.Now;
 _isStopped = true;
 }
 else if (state == "RUNNING" && _isStopped) {
 var duration = (DateTime.Now - _lastStopStart).TotalSeconds;
 var category = duration < MICRO_STOP_THRESHOLD
 ? "MicroStop" : "Downtime";

 // UNS üzerine MQTT yayını
 PublishMqttMessage(
 $"Line1/OEE/Losses/{category}",
 duration.ToString("F1"));

 LogInformation(
 $"{category} detected: {duration:F1}s");

 _isStopped = false;
 }
 }
 base.OnMessageReceive(ctx);
 }
}

By publishing MicroStop_Duration to the UNS, you can create a heatmap showing exactly when these stops happen. Often, they cluster around shift changes or raw material batch swaps.

Starved vs. Blocked: The Attribution Dilemma

A machine isn't often "broken" when it stops running. In a continuous production line, context is everything.

• Starved: The machine is ready to run, but the upstream machine hasn't provided any material.
• Blocked: The machine is running fine, but the downstream machine is full/stopped, causing the conveyor to back up.

If you penalize a machine's OEE for being Starved or Blocked, your operators will revolt. They'll say, "It's not my fault the filler stopped!"-and they're right.

Handling Line Integration

In your OEE logic, you typically should differentiate between Internal Downtime (Machine Fault) and External Downtime (Starved/Blocked).

Implementation Tip: When calculating OEE, Starved and Blocked times should usually be excluded from the Availability calculation of this specific machine, or categorized separately as "Line Losses".

Performance: Escaping the Ideal Cycle Time Trap

The Performance component is calculated as:

Performance = (Total Count × Ideal Cycle Time) ÷ Run Time

The most common mistake is using a static "Nameplate Speed" for the Ideal Cycle Time.

• Scenario: The machine nameplate says 1000 units/hour.
• Reality: For Product A (small), it can do 1000. For Product B (large), physics dictates it can only do 600.

If you calculate Product B using the 1000 units/hour standard, your Performance will permanently sit at 60%. This can reduce trust in the metric since the target appears structurally unrealistic.

Dynamic Target Management

You typically should fetch the Ideal Cycle Time dynamically based on the active SKU.

1. ERP Integration: Proxus subscribes to the ERP's Current_Job topic via the IT/OT Bridge.
2. Lookup Table: The edge gateway holds a local lookup table (SQLite/JSON): { "SKU_001": 0.5s, "SKU_002": 0.8s }.
3. Real-Time Adjustment: When the job changes, the calculation formula automatically updates the denominator.

This ensures that 100% Performance means "We are running as fast as physics allows for this product."

Making OEE Visible: Andon Boards

Collecting data is useless if you don't visualize it effectively. An Andon Board is a large TV screen on the factory floor providing immediate feedback.

The Psychology of Visualization

Don't just show "OEE = 65%". That's abstract to floor staff. Show "Lost Units".

• "We have lost 350 bottles due to downtime today."
• "We are 15 minutes behind schedule."

These metrics trigger human action. Operators intuitively understand "bottles" and "minutes", not percentages.

Putting It All Together: Implementation Checklist

Ready to build this? Here is the checklist for deploying a Real-Time OEE solution using Proxus.

When this may not be suitable

• Lower-frequency telemetry may not justify full distributed complexity.
• Small single-line plants may prefer simpler architectures first.
• Strict legacy constraints may require phased adoption.
• Safety-critical closed-loop control should remain in PLC/Safety PLC layers.

Outcomes depend on workload profile, hardware capacity, and deployment topology.

Frequently Asked Questions

What is a realistic OEE target for most factories?

World-class OEE is often cited as 85% (90% Availability × 95% Performance × 99.9% Quality). However, this benchmark originated in the semiconductor industry (SEMI E10) and does not transfer directly to all sectors. A beverage bottling line may realistically achieve 80%, while a batch chemical reactor might struggle above 60% due to inherent changeover requirements. The more important metric is the rate of improvement over time, not the absolute number.

Should I include planned downtime in OEE calculations?

No. Standard OEE methodology excludes planned downtime (scheduled maintenance, breaks, no-production shifts) from the denominator. If you include it, you are measuring TEEP (Total Effective Equipment Performance), which is a different KPI. Mixing the two leads to misleading comparisons across plants.

How do I handle OEE for batch processes vs. continuous lines?

For batch processes, replace "Ideal Cycle Time" with "Ideal Batch Duration." Performance = (Number of Batches × Ideal Batch Time) / Run Time. Quality is measured per batch rather than per unit. The state machine logic remains the same, but the timing resolution shifts from seconds to minutes.

How does manual logging affect OEE accuracy?

Manual logging systems are inherently prone to sampling errors or rounding - operators might miss micro-stops or struggle to record exact timestamps while focused on resolving issues. This is precisely why automated, PLC-driven OEE is essential. When the machine's digital state directly drives the calculation, these measurement limitations are removed. Expect your automated OEE to initially be 5–15 points lower than the manual version - that gap represents the high-resolution truth that provides a baseline for continuous improvement.

How does OEE relate to machine downtime cost?

OEE quantifies what you lost; True Downtime Cost (TDC) quantifies how much money you lost. They are complementary. A 1% improvement in Availability on a machine with a $50,000/hour TDC translates to roughly $4,000/day in recovered revenue. Together they build the financial case for predictive maintenance investment.

Conclusion: From Measurement to Improvement

OEE is not a report card; it is a diagnostic instrument. The goal isn't achieving a "high score" that covers up inefficiencies - it's finding the hidden lost capacity buried in your process.

By moving from Excel spreadsheets to a Real-Time, Edge-Computed Architecture, you stop looking in the rearview mirror and start driving the car. You catch micro-stops before they accumulate into significant production losses. You adjust performance targets dynamically per SKU. You empower operators with live data they trust because the machine - not a human with a form - generated it.

This is the difference between a factory that survives and a factory that dominates.

References

1. SEMI E10 - Specification for Definition and Measurement of Equipment Reliability, Availability, and Maintainability (RAM). The semiconductor industry's OEE standard. SEMI Standards
2. ISO 22400-2 - Key performance indicators for manufacturing operations management, including OEE and its sub-components. ISO 22400
3. Seiichi Nakajima, "Introduction to TPM" (1988) - The original definition of OEE and the Six Big Losses framework within Total Productive Maintenance.
4. ISA-95 / IEC 62264 - Standard for integrating enterprise and control systems, relevant to the namespace design used for publishing OEE metrics to the UNS.
5. Hansen, Robert C., "Overall Equipment Effectiveness" (2001) - Practical implementation guide for OEE across diverse manufacturing environments.

Ready to calculate your True OEE? Explore the Proxus Edge Architecture to see how to deploy this logic, check our OEE & Downtime Analytics solution, or Contact Us to discuss a pilot implementation.