How to Reduce Downtime with Real-Time Data: What Changed on One Packaging Line
Paweł Dera · CTO IoT, DBR77 · Published
Real-time data reduces downtime when it shortens the time between a machine stopping and the right person acting on it. On one corrugated-packaging line, making every stop visible as it happened cut the average response time from 24 to 9 minutes and lifted OEE from 61% to 70%.
The gain came from closing the gap between a stop and the moment anyone knew about it. This article shows where those minutes hide, what changed on that line, and what real-time data will not fix for you.
Why downtime is still so expensive
Unplanned downtime is one of the largest hidden costs in manufacturing. Siemens estimates that the world's 500 largest companies lose about 11% of their annual revenue to unplanned downtime, around $1.4 trillion a year. In automotive, one hour of a stopped line costs about $2.3 million (Siemens, The True Cost of Downtime 2024).
A mid-sized plant loses far less per hour, but the cost builds up the same way. Most of it is the time the line stands while people find out that it stopped, why, and who should go.
Where the minutes actually go
Take a typical stop on a line without live data. The machine halts. An operator notices, tries to restart, then walks to find the shift leader. The shift leader radios maintenance. Maintenance asks which machine and what the error was. Someone walks back to check.
Almost all of that time goes into noticing, walking, describing and waiting.
| Step in a stop | Without live data | With live data |
|---|---|---|
| Noticing the stop | When someone walks past or the line backs up | The moment the machine changes state |
| Knowing the reason | Guessed later, often logged as "unknown" | Operator picks a reason at the machine in about 2 seconds |
| Calling the right person | Radio, phone, walking to find them | Alert goes to the owner of that machine and stop type |
| Tracking the response | Not tracked | Time to acknowledge and time to fix are logged |
| Learning from it | End-of-shift notes, Excel the next day | Live downtime Pareto by machine and reason |
What changed on the packaging line
The line itself was modern, but stop tracking was manual. Operators logged stops from memory at the end of the shift. "Unknown" was the biggest bar on the downtime Pareto. OEE was rebuilt in a spreadsheet a day later, when nobody could act on it anymore.
The pilot changed four things:
- Machine status went live on the floor, so every stop showed up the moment it happened.
- Operators selected the stop reason on a tablet next to the machine, in about two seconds, while the cause was still obvious.
- Each alert reached maintenance as a task with an owner, the machine, the reason and the time.
- OEE was calculated live from the same events, so nobody had to rebuild it by hand.
After the pilot, the plant confirmed that OEE had risen from 61% to 70% and that average response time to a stop had fallen from 24 to 9 minutes. We do not name the client.
What would 9 OEE points mean for your line?
Enter your shifts, output and current OEE in the ROI calculator. It takes about three minutes and shows the value of every point of OEE.
Why response time moves before OEE
OEE multiplies availability, performance and quality. Vorne, which publishes OEE benchmarks, notes that 85% is often cited as world class, while most manufacturers are closer to 60%. The packaging line started right at that typical level.
OEE is an outcome, and you cannot change it directly on a Tuesday afternoon. Response time is under your control as soon as the floor becomes visible: every stop that gets an owner in one minute instead of ten adds availability.
That is why the first number to watch in a pilot is response time, not OEE. On the packaging line, the minutes saved per stop came out of searching for the cause and the right person. The OEE gain followed from that, together with "unknown" disappearing from the Pareto.
Five conditions that make real-time data cut downtime
Plenty of plants have live dashboards that nobody acts on. In our experience, downtime falls only when these five conditions are in place:
- A signal from every machine in scope. Machines with a PLC are read directly, older ones get a small edge device. Our article on the first 30 days of IoT in a brownfield factory shows how.
- The reason is captured at the stop. Reasons reconstructed at the end of the shift are guesses. Keep the list short, 10 to 15 reasons per machine type.
- One owner per alert. Route each alert to a person or a role on the current shift. If it goes to "maintenance" in general, nobody owns it.
- An escalation rule. For example: if an alert is not acknowledged within 5 minutes, it goes to the shift leader. Write the rule down before go-live.
- A short daily review. Spend ten minutes at the start of the shift on the top three losses from the day before.
What real-time data will not fix
Real-time monitoring makes losses visible and speeds up the reaction, but someone still has to remove the root causes. A worn bearing still needs replacing, and a bad changeover standard still needs rewriting. The data tells you which of them costs the most.
It is also not predictive maintenance. Predicting failures needs a longer history and more signals, and it pays off on a smaller number of critical assets. Start with visibility, which gives you the clean event history that any later prediction depends on.
Finally, some stations have no signal at all: manual assembly, packing, older presses. For those, a camera can act as a sensor. The IRIS Vision AI layer measures cycles and presence without wiring into the machine.
FAQ
How much can real-time data reduce downtime?
It depends on how much time your plant loses between a stop and a response today. The packaging line described above logged stops from memory and had "unknown" as its biggest loss, so it had a lot to gain. Plants that already react quickly will see smaller gains.
Do we need new machines or new PLCs?
No. Machines with a PLC are read over OPC UA or Modbus. Machines without a PLC get a small edge device that reads the signals that are available. The line keeps running during installation.
How quickly can we see results?
Response time is measurable from the first week, because every stop and every reaction is time-stamped. OEE changes become visible over the following weeks, once reasons are captured consistently.
What is the difference between real-time monitoring and predictive maintenance?
Monitoring shows what is happening now and speeds up the response. Predictive maintenance forecasts failures from historical data. Monitoring comes first, because it creates the data history that prediction needs.
What does a pilot involve?
One line, a few weeks, measured against a baseline. See how a DBR77 IIoT pilot works, or calculate the expected value first in the ROI calculator.
Conclusion
On most lines the quickest gain is in the minutes between a stop and the first person reacting to it, and a pilot can measure those minutes from its first week. Pick the line where "unknown" is the biggest bar on your downtime Pareto, connect it, and log time to acknowledge and time to fix for every stop. The article on the first 30 days of IoT in a brownfield factory covers how to get that first line connected.
See it on a live line
In a 30-minute online demo we show how stops, reasons and alerts look in DBR77 IIoT, and how a pilot on one of your lines would be measured.
Sources
- Institute for Supply Management, The Monthly Metric: Unscheduled Downtime (summary of Siemens data), 2024
- Siemens, The True Cost of Downtime 2024
- Vorne, World-Class OEE
- Vorne, The Six Big Losses
- McKinsey & Company, IoT value set to accelerate through 2030
- OPC Foundation, What is OPC UA
- DBR77 IIoT pilot data, corrugated-packaging line (client anonymous), 2026