OEE and Downtime Tracking in SCADA: What Every Plant Manager Actually Wants

At some point in every integration project, the plant manager leans back in their chair and says the words: "Can we track OEE?" A wise man in management heard the term at a conference, read it in a LinkedIn post, or saw it on a competitor's factory tour. Now they want it on their floor. And they are looking at you to make it happen.

Here is what that usually means for the system integrator: you nod, you Google "OEE tracking software," you find a $50,000 MES platform, and then you spend the next three weeks trying to figure out how to deliver the same outcome for a plant that has a $15,000 total budget for everything including the PLC programming.

This post is about bridging that gap. What OEE actually is, what plant managers really need when they say "OEE," why most OEE solutions are absurdly over-engineered for small and mid-size plants, and how to deliver production metrics using tools that fit the actual budget.

What OEE Actually Is

OEE stands for Overall Equipment Effectiveness. It is a single percentage that tells you how productively a machine or production line is being used. The formula is straightforward:

OEE = Availability × Performance × Quality

Three factors, each a percentage between 0 and 100:

• Availability — Was the machine running when it was supposed to be running? Divide actual run time by planned production time. If a line was scheduled for 8 hours and was down for 1 hour of unplanned downtime, availability is 87.5%.
• Performance — When the machine was running, was it running at the intended speed? Divide actual throughput by theoretical throughput at full speed. If a machine should produce 100 units per minute but only averages 85, performance is 85%.
• Quality — Of the units produced, how many were good? Divide good units by total units. If you produced 1,000 parts and 30 were rejected, quality is 97%.

Multiply them together. An OEE of 72% means the machine is producing good parts at full speed 72% of the time it is scheduled to run. World-class OEE is generally considered to be 85%, which tells you something about how hard it is to achieve. Most manufacturing plants operate at 60-65% OEE and do not even know it.

For integrators, the key insight is this: OEE is a measurement, not a feature. It is something you calculate from raw data that already exists in the PLC. You do not need a $50,000 system to produce that calculation. You need the right data points and a way to aggregate them over time.

Why Most OEE Solutions Cost $50K+

The OEE software market is dominated by MES (Manufacturing Execution System) vendors. These platforms do a lot more than OEE. They handle production scheduling, batch tracking, genealogy, SPC (Statistical Process Control), material traceability, work order management, and integration with ERP systems like SAP. OEE tracking is one module among many.

That breadth is why they cost what they cost:

• License fees start at $20,000-$30,000 for a basic installation, and scale upward with the number of production lines, users, and integrations.
• Implementation runs $15,000-$50,000 in consulting fees because the software requires significant configuration. Someone has to map every machine state, define every downtime reason, configure every report, and connect every PLC.
• Annual maintenance is 15-20% of the license, every year, forever.
• Hardware requirements are non-trivial. These systems typically need dedicated servers, SQL databases, and sometimes additional edge devices for data collection.

For a Fortune 500 automotive plant with 200 presses and a dedicated IT team, this is a reasonable investment. For a 3-line food packaging facility with 30 machines and one electrician who also handles IT, it is not.

The "Poor Man's OEE" — What 90% of Sites Actually Need

Before you invest in a full MES implementation, ask what the plant manager is going to do with the data. In most cases, the answer is some combination of:

1. Machine state tracking — Is the machine running, idle, in setup, or down? Show me a timeline for each shift.
2. Downtime reason codes — When the machine stopped, why did it stop? Let the operator pick a reason from a list.
3. Shift production reports — At the end of the 8-hour shift, how many units were produced, how much time was lost, and to what causes?
4. A single dashboard — A chart on a monitor in the break room showing today's uptime percentage, the top 3 downtime reasons, and a comparison to yesterday.

That is the "poor man's OEE." It does not give you the full Availability x Performance x Quality formula with per-second granularity. It gives you the three numbers the plant manager actually looks at: uptime, top downtime causes, and parts produced. And for most plants, those three numbers drive 80% of the improvement decisions.

You can deliver all of this without touching a single line of PLC logic. Here is how.

Tracking Machine States from Existing PLC Data

Most PLCs already have the signals you need to determine machine state. You just need to know where to look. The key is reading existing registers and mapping them to states, not adding new logic to the PLC program.

The Signals Already Exist

Walk up to any machine on a plant floor and look at the HMI. The HMI already shows whether the machine is running, stopped, in fault, or in manual mode. That information comes from PLC registers. Your SCADA system just needs to read those same registers and apply rules to classify the state. Understanding PLC programming with ladder logic helps you identify the right registers quickly.

Typical signals you can poll from existing PLC data:

• Run signal — A boolean register that is TRUE when the machine is actively producing. Sometimes called "Auto Run," "Machine Running," or "Production Active."
• Fault/Alarm signal — TRUE when the machine is in a fault state. The HMI already displays this. Your SCADA reads the same bit.
• Speed or count register — An integer or float representing current line speed, or a counter that increments with each unit produced. If the counter is going up, the machine is running.
• Mode selector — A register indicating Auto, Manual, Setup, or Maintenance mode. Present on virtually every machine with a selector switch.

State Classification Logic

Once you are reading these signals, the classification logic is simple. It lives in your SCADA, not in the PLC:

• If Run = TRUE and Speed > threshold: state is Running
• If Run = FALSE and Fault = TRUE: state is Faulted
• If Run = FALSE and Mode = Setup: state is Setup/Changeover
• If Run = FALSE and Fault = FALSE and Mode = Manual: state is Manual/Idle
• If Run = FALSE and no other condition: state is Idle

No PLC program modification required. You are reading data that already exists and applying rules in the SCADA layer. The integrator configures the register addresses and thresholds in the SCADA's tag configuration, and the system handles the rest.

Recording State Durations

Once you have real-time state classification, the SCADA logs every state transition with a timestamp. Machine went from Running to Faulted at 10:32:15. Back to Running at 10:47:03. That gives you 15 minutes of fault downtime, categorized by state, stored with full timestamps. Aggregate that over a shift and you have the Availability component of OEE without writing a single line of PLC code.

Downtime Reason Codes — The Feature Operators Actually Use

Machine state tracking tells you when the machine was down. Downtime reason codes tell you why. And if you have ever spent time on a plant floor, you know that the "why" is where all the arguments happen.

Without a structured reason code system, the end-of-shift conversation goes like this:

"Why was line 3 down for 40 minutes?"
"I don't know, it just stopped."
"Was it a mechanical issue?"
"Maybe. Or maybe it was waiting for material."

With a reason code system, the operator taps a button on the dashboard or HMI when the machine stops: "Material Wait," "Mechanical Fault," "Changeover," "Operator Break." The system timestamps the selection and logs it against that downtime event. Now the shift report shows that 40 minutes of downtime was 25 minutes waiting for raw material and 15 minutes of mechanical adjustment. That is actionable data.

How to Implement Reason Codes

The simplest implementation works like this:

1. The SCADA detects a state change to a non-running state (faulted, idle, setup).
2. A notification appears on the operator's dashboard or HMI screen: "Line 3 stopped. Select reason."
3. The operator selects from a configurable list of reason codes that you define with the plant manager during commissioning. Typical codes: Mechanical Fault, Electrical Fault, Material Shortage, Changeover, Quality Hold, Operator Unavailable, Planned Maintenance.
4. The system logs the reason code, the machine, the start time, and the duration (calculated when the machine returns to running state).
5. At shift end, the system generates a report showing total downtime by reason code, sorted by duration.

The reason codes should be configurable per machine or per line because different equipment has different failure modes. A packaging line has different downtime causes than a CNC machining center. Let the plant manager define the codes. You just build the mechanism to capture and report them.

OEE Approaches Compared

Here is how the three common approaches to OEE and downtime tracking stack up against each other:

The spreadsheet approach deserves a mention because it is still the most common method at small plants. An operator writes down stop times and reasons on a clipboard. At end of shift, a supervisor types it into Excel. Someone builds a pivot table once a month. This works, barely, until it does not. The data is always late, always approximate, and never trustworthy enough to drive real decisions. The moment a plant manager sees real-time machine state tracking on a dashboard, the clipboard disappears.

What Voltrus Starter Delivers for $249

If you have read this far, you already understand the pattern: most plants need machine states, downtime reasons, and shift reports. They do not need a six-figure MES. They need a SCADA that handles this out of the box.

Voltrus Starter is built for exactly this use case. At $249 per deployment, it includes:

• Machine state tracking from existing PLC registers. Configure your tag addresses, set your thresholds, and the system classifies Running, Idle, Faulted, Setup, and Manual states in real time. No PLC logic changes.
• Configurable downtime reason codes. Operators tap a reason when a machine stops. You define the code list per machine during commissioning. Five codes or fifteen, your choice.
• Shift report generation. Automatic aggregation of run time, downtime by reason, and production counts per shift. The numbers appear on the dashboard at shift end without anyone pressing a button.
• OEE dashboard widgets. Uptime percentage, top downtime causes ranked by duration, production count vs. target. The key numbers, visible on a single screen, updating in real time.
• Modbus TCP and MQTT connectivity. Read PLC data via Modbus or ingest MQTT messages from edge gateways. Whatever your plant already has, Voltrus talks to it.
• Web-based interface. No client software to install. The dashboard runs in any browser. Operators view it on a tablet mounted to the machine. The plant manager checks it from their office.
• Single binary, runs on existing hardware. Deploy on the same industrial PC that runs the HMI. No dedicated server. No SQL instance. No additional hardware budget.

The integrator margin is where this gets interesting. Your client asks for OEE tracking. You quote a solution. With a full MES, you are passing through $20K+ in software costs before you bill your first hour of configuration. With Voltrus Starter at $249, the software cost is a rounding line on the proposal. You charge for your integration work (configuring tags, defining reason codes, building the dashboard layout) and the client gets production metrics for a fraction of what they expected to pay. Everyone wins.

Getting Started

The fastest path from "plant manager asked for OEE" to "OEE is on the dashboard" looks like this:

1. Survey the PLC registers. Walk the floor with the electrician or maintenance tech. Identify the run signal, fault signal, speed or count register, and mode selector for each machine. This takes 30-60 minutes per line. For extracting deeper production data beyond OEE, see our guide on SCADA data extraction for predictive maintenance.
2. Configure tags in Voltrus. Enter the register addresses for each signal. Set the speed threshold that defines "running" vs. "idle." Map each signal combination to a machine state.
3. Define downtime reason codes with the plant manager. Sit down for 15 minutes and agree on 5-8 codes per production line. Use language the operators already use, not consultant jargon.
4. Build the dashboard. Drop the OEE widgets onto a dashboard. Arrange the machine state timeline, top downtime reasons chart, and production counter. This is configuration, not programming. For layout principles that help operators actually use the dashboard, see our industrial dashboard design guide.
5. Train the operators. Show them the downtime reason selection screen. Keep it simple: when the machine stops, tap the reason. That is the only behavior change required.
6. Review the first week of data with the plant manager. Sit down on day five and look at the shift reports together. This is where the value becomes real and the plant manager becomes your reference.

From survey to live dashboard, expect 1-2 days of integrator time for a 3-5 line plant. Compare that to the 4-12 week timeline for a full MES implementation.

Frequently Asked Questions

Can you track OEE without buying an MES?

Yes. Most small and mid-size plants do not need a full MES to track OEE. You can calculate the core metrics (Availability, Performance, Quality) by reading existing PLC registers through your SCADA system: the run signal, fault signal, speed or count register, and mode selector. Machine state tracking and downtime reason codes give you the Availability component. Production counters give you Performance and Quality. A SCADA like Voltrus Starter at $249 provides machine state tracking, configurable downtime reason codes, shift reports, and OEE dashboard widgets without requiring an MES.

How do you track machine downtime in SCADA?

Read existing PLC registers for the run signal, fault signal, speed counter, and mode selector. Apply classification logic in the SCADA layer: if Run is TRUE and Speed is above threshold, the machine is Running; if Run is FALSE and Fault is TRUE, the machine is Faulted; and so on. Every state transition is logged with a timestamp. Aggregate state durations over a shift to get total downtime. No PLC program changes are required.

What are downtime reason codes and how do they work?

Downtime reason codes let operators tag each stoppage with a cause when the machine goes down. The SCADA detects a state change to a non-running state and prompts the operator to select a reason from a configurable list (Mechanical Fault, Material Shortage, Changeover, Quality Hold, etc.). The system logs the reason code with the machine ID, start time, and duration. At shift end, reports show total downtime sorted by reason, which is the data plant managers use to prioritize improvement efforts.

What is a good OEE percentage for manufacturing?

World-class OEE is generally considered 85%, but most manufacturing plants operate at 60-65% without knowing it. A realistic target for a plant starting to track OEE for the first time is to reach 65-70% within the first year. The fastest improvements come from reducing unplanned downtime (improving Availability), which is the easiest factor to address with basic machine state tracking and downtime reason codes.

Further Reading

• Voltrus vs Ignition: An Honest Comparison for System Integrators
• Lightweight SCADA Software: What It Actually Means
• SCADA Software Pricing: Why Lifetime Licenses Beat SaaS