The Engineering Guide to Real-Time OEE: Moving Beyond the Spreadsheet

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

This number is almost certainly wrong.

In the traditional manufacturing world, OEE is treated as a lagging indicator. It is calculated after the fact, usually by summing up operator logbooks where downtimes are rounded to the nearest 15 minutes, and short stops are ignored entirely. This "Analog OEE" is a participation trophy; it makes people feel good, but it doesn't solve problems.

True Digital Transformation requires Real-Time OEE. This is not just a dashboard; it is a high-resolution forensic tool that exposes the microscopic inefficiencies bleeding your profitability.

In this deep-dive guide, we will move beyond the basic formula. We will explore how to architect a real-time OEE engine using the Unified Namespace (UNS), how to handle complex machine states (like Starved vs. Blocked) at the edge, and how to use Proxus to capture the "invisible" losses that Excel can never see.

1. The Anatomy of "Real" OEE

Before writing code, we must 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 correct theoretical speed.
3. Automaticity: It removes the human bias. Operators don't "decide" why the machine stopped; the PLC tells us.

The Six Big Losses: A Digital Mapping

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

Reduced Speed | Actual_Cycle_Time> Ideal_Cycle_Time | | Quality | Process Defects | Quality Station NG_Count increment | | Quality | Startup Yield | Scrap_Count during State == RAMP_UP |

---

## 2. The Architecture: Edge-First Calculation

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

OEE must be calculated at the Edge.

Why? 1. Latency: An operator needs to know now that they are falling behind, not 15 minutes later when the cloud processes the batch. 2. Data Volume: Sending every millisecond status change to the cloud is expensive. 3. Resolution: Capturing a 200ms micro-stop requires local processing power.

### The Logic Flow In the Proxus architecture, the OEE logic runs inside the Docker container on the factory floor (the Edge Gateway).

---

## 3. The Killer Feature: Micro-Stop Detection

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 4% 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:

```csharp // Proxus Edge Script: MicroStopDetector.cs

public class OEEEngine : IEdgeScript { private DateTime _lastStopStart; private bool _isStopped = false; // Threshold: Stops shorter than 120s are "Micro", longer are "Downtime" private const double MICRO_STOP_THRESHOLD = 120.0;

public void OnDataUpdate(string topic, object value) { // Assume topic is "Line1/PLC/State" var state = value.ToString();

if (state == "STOPPED" && !_isStopped) { // Machine just stopped _lastStopStart = DateTime.Now; _isStopped = true; } else if (state == "RUNNING" && _isStopped) { // Machine just started - calculate duration var duration = (DateTime.Now - _lastStopStart).TotalSeconds;

if (duration < MICRO_STOP_THRESHOLD) { // This is a Micro-Stop LogMicroStop(duration); Publish("Line1/OEE/Losses/MicroStop_Duration", duration); } else { // This is a major Downtime LogDowntime(duration); Publish("Line1/OEE/Losses/Downtime_Duration", duration); } _isStopped=false; } } } ``` 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 batches. --- ## 4. The "Starved" vs. "Blocked" Dilemma A machine isn't always "broken" when it's not running. In a continuous production line, context is everything. * Starved: The machine is ready to run, but the upstream machine hasn't given it any material. * Blocked: The machine is running, but the downstream machine is full/stopped, so the conveyor is backed up. If you penalize a machine's OEE for being Starved or Blocked, your operators will revolt. They will say, "It's not my fault the filler stopped!" And they are right. ### Handling Line Integration In your OEE logic, you must differentiate between Internal Downtime (Machine Fault) and External Downtime (Starved/Blocked).