Real-Time Insights in Manufacturing: What It Actually Means

What Real-Time Insights actually are

Real-Time Insights are analyses and decisions that work off live production data — machine states, counts, downtimes, process values and quality events as they happen, rather than as they appeared in last night's Excel export. The practical outcome is that a supervisor looking at a line knows its current condition within seconds, not hours; that OEE, First Pass Yield, scrap and throughput update continuously rather than at shift end; and that deviations become visible while there is still time to act on them.

That is the marketing definition, and it is correct as far as it goes. What it skips is the engineering question underneath: what does "real-time" actually mean, technically, and what has to work before any of the above is real?

What "real-time" actually means in manufacturing

Real-time is one of the most abused words in industrial software. It is worth separating three very different things that all get sold as "real-time":

When a Cloud MES talks about Real-Time Insights, it means the middle row. PLC-level real-time is the job of the automation layer, not the MES; any vendor claiming millisecond cycle-time reporting into a cloud dashboard is either confused or marketing. Batch-refreshed dashboards sold as "real-time" are the more common deception — and the one worth checking before signing any contract. The honest test: ask the vendor what the maximum delay is between a machine state changing and that change appearing on the dashboard. If the answer is hand-waving rather than a number in seconds, assume it is batch-refresh behind a live-looking UI.

What has to work before Real-Time Insights are real

The dashboard is the visible ten percent of the project. The other ninety percent is the data-capture layer, and this is where most Real-Time Insight programmes succeed or fail. Four elements have to work:

• Signal capture from the machine. For modern controls this is typically OPC UA — it is the standard, it is bidirectional, and if the machine has it exposed, integration is straightforward. For everything else (and a lot of machine parks are "everything else"), the path is a digital I/O gateway reading the existing signals the machine already produces, without touching the PLC. Both approaches work. The failure mode is trying to retrofit OPC UA to controls that don't support it properly — this is usually more painful and less reliable than a clean digital I/O retrofit.
• Reliable transport. The signals have to get from the plant to the cloud over whatever network is available, with the right buffering in case the connection drops. An IoT gateway that queues data during outages and forwards it when connectivity returns is the difference between a "real-time system" that works and one that lies quietly whenever the VPN hiccups.
• Contextualisation. A raw machine signal is not an insight. It has to be tied to an order, a product, a shift, an operator, a plant, a line. Without that context the data is unanalysable — you can see that cycle-times changed but not which product was running. This is where the ERP integration (bidirectional, ideally) matters.
• Consistent KPI definitions. OEE on Line A has to mean the same thing as OEE on Line B. This sounds obvious and is routinely violated. A Real-Time Insight dashboard that shows three different OEE calculations across three plants is worse than no dashboard, because it forces every cross-site discussion into a definitional argument rather than an improvement discussion.

Observation from three decades of machine connectivity: the single most common sentence I hear when I walk into a prospect's plant is "our old machines can't deliver data." It is almost never true. Controls from the early 1990s still produce digital signals — cycle outputs, part-counter pulses, downtime flags, often enough to reconstruct the full OEE picture. Controls from the late 1990s and onward can usually be read over whatever fieldbus they sit on. Even when the PLC itself is opaque, the electrical signals coming out of the machine are readable, which is exactly what a digital I/O gateway is for. I have retrofitted Simatic S5 lines from 1991 into live OEE dashboards without touching the PLC program, without unplanned production stops, and without a single line of code changed in the machine controller. The limitation is not the hardware — it is almost always the assumption that it can't be done. The real questions on a brownfield machine park are which signals are worth capturing, at what sampling rate, and with what reliability — not whether capture is possible. Once the team inside the plant sees the first genuinely-live dashboard from a machine they had written off as "not digitalisable," the conversation about Real-Time Insights stops being theoretical.

Where Real-Time Insights do not pay back — or actively cause harm

Honest cases where the effort produces less than it promises, or worse:

• Alert fatigue. Real-time data without defined thresholds and defined responses produces a firehose of notifications. Operators learn within two weeks which colours and sounds to ignore, and at that point the system has negative value — it creates a false sense of oversight while actually desensitising the people on the floor. The fix is not more alerts; it is fewer, better-targeted ones with defined ownership.
• "Real-time" without a real-time process. A shift meeting that runs at 8:00 a.m. on yesterday's data is not improved by adding live dashboards if the meeting rhythm doesn't change. The decision process has to become real-time as well, or the dashboards are decoration.
• Over-instrumentation of low-value machines. Retrofitting every piece of equipment in the plant to produce live signals is rarely defensible. The economics favour instrumenting the bottleneck assets first and leaving tertiary equipment on manual reporting until a specific use case justifies the capture cost.
• Signals without defined semantics. A digital output labelled "machine running" on one line and meaning "spindle energised" on another produces data that looks comparable and isn't. Real-Time Insights rest on standardised signal semantics more than on sampling rate. Getting the semantics wrong once scales the error across the whole plant.
• Expecting real-time to replace root-cause analysis. Live dashboards show what is happening. They rarely show why. The why usually requires process-parameter recording at higher resolution, correlated with events — not the same thing as a live KPI tile.

What can and cannot be captured in real time

A quick honest list that rarely appears in vendor content:

• Captured easily in real time: machine states, cycle counts, part counters, downtime start/stop, setup transitions, process parameters with electrical interfaces (temperature, pressure, torque, current), alarm signals from the PLC, power consumption via separate meters.
• Captured with effort: quality data from inline inspection systems (requires integration with the vision/gauging system), scrap categorisation (usually a mix of automatic detection and operator input), root-cause codes for downtimes (operator input, ideally with structured pick-lists).
• Not real-time even in principle: lab-measured quality data, offline inspection results, some batch-level process outputs that are only available once the batch closes, anything requiring manual human judgement that takes longer than the cycle time itself.

Treating the third category as if it should be real-time is a classic source of failed implementations. Some data is fundamentally delayed; architecting around that reality is cheaper than fighting it.

How this fits into the SYMESTIC platform

SYMESTIC is built on MES-level real-time — sub-second to a few seconds between machine-side events and dashboard-side visibility. The capture layer runs OPC UA for modern controls and IoT gateways with digital I/O for brownfield assets, which covers the mixed-machine-park reality in almost every prospect we see. Gateways buffer locally during connectivity interruptions and forward when the link is restored, so the real-time property survives the real conditions of plant networks. Contextualisation runs through bidirectional ERP integration — SAP R/3 via ABAP IDoc, Microsoft Dynamics/Navision, Infor/InforCOM, proAlpha — so order, product and shift context are attached to the live signals without spreadsheet work in the middle. KPI definitions are configured centrally and applied consistently across lines and sites. Over 15,000 connected machines in 18 countries currently operate on this foundation. Customer-facing module entry points most relevant to this topic: production metrics, process data, alarms and production control.

FAQ

How fast is "real-time" in a Cloud MES like SYMESTIC?
Typically sub-second to a few seconds between a machine-side event and its appearance on a dashboard. The exact latency depends on network conditions, gateway configuration and sampling rate, but as a rule of thumb: if your team cannot see a state change within a handful of seconds, the system is not delivering MES-level real-time regardless of what the marketing says. Ask for the specific maximum latency during vendor evaluation.

Do we need to replace our old machines to get Real-Time Insights?
Almost never. Brownfield machines from the early 1990s onwards can usually be instrumented through digital I/O gateways reading the signals the machine already produces — no PLC intervention, no production interruption, no software change inside the controller. The exceptions are extremely old purely mechanical equipment with no electrical signals of any kind, which is rare in modern production.

What is the difference between real-time data and "near real-time"?
Near real-time is usually a polite term for batch refresh at short intervals — every minute, every five minutes, every fifteen minutes. Some reporting dashboards marketed as "live" fall into this category. For most shopfloor decisions, batch refresh at fifteen-minute intervals is functionally indistinguishable from end-of-shift reporting. For downtime detection and immediate intervention, it is not enough.

Do I need OPC UA specifically, or will other protocols work?
OPC UA is the current standard for modern controls and is worth using where the machine supports it cleanly. Where it doesn't, or where the existing controls are older, digital I/O gateways capturing the existing signals are usually the more reliable path. MQTT has its place for specific IoT scenarios. The pragmatic answer is protocol-agnostic: whatever signal path is most reliable for the specific machine. See Cloud MES vs. on-premise for the architectural context.

How do Real-Time Insights relate to OEE?
OEE calculated from real-time signals is substantially more trustworthy than OEE calculated from end-of-shift manual summaries, because micro-stops are captured instead of estimated and downtime classification is tied to the actual event timestamp rather than reconstructed after the fact. In most deployments the OEE figure drops when automated real-time capture replaces manual reporting — this is usually the first honest reading the plant has seen. See OEE: definition, calculation & practice.

Can Real-Time Insights work over unreliable plant networks?
Yes, provided the gateway layer buffers locally and forwards when connectivity returns. A gateway that loses data during a network outage is not suitable for MES-level real-time because it creates silent gaps. A properly configured IoT gateway queues events locally and reconciles on reconnection, so the real-time property survives the real network conditions in most plants.

What is the biggest failure mode in Real-Time Insight projects?
In my experience, underestimating the signal-capture layer. Teams plan detailed dashboards before the basic question — "can we actually get reliable, contextualised data out of these specific machines at the required rate?" — has been answered in the field. The dashboard is the last thing to build. The capture layer is the first, and if it is unreliable, nothing downstream can be.

What role does the ERP play?
It provides the context that turns raw signals into meaningful data — which order was running, which product, which shift, which operator. Without that context, a downtime event is just a timestamp. With it, it is a downtime on Order 12345, Product variant X, Shift B, operator Y — which is what makes the data actionable. See MES: definition, functions & benefits for the broader integration picture and MES software compared for vendor-side context.

Related: MES: Definition, functions & benefits · OEE: Definition, calculation & practice · MES software compared · OEE software · Cloud MES vs. on-premise · AI in manufacturing and MES · Production metrics module · Process data module · Alarms module · Production control module · Automotive · Metal processing · Food & beverage · Plastics processing · For COOs & plant managers · For production managers · For maintenance managers.

About the author

Martin Brandel

MES Consultant at SYMESTIC. Over 30 years in industrial automation. Connecting machines to higher-level systems since 1991 — starting with Simatic S5, warehouse management and material-flow control; today with OPC UA, IoT gateways and Cloud MES. Career path: Ing. Büro Jürgen Albert (1991–1995, automation engineer), Hermos AG (1995–2000, large projects in Eastern Europe and China — conveyor systems, process technology, paint lines), ODEVIS / SYMESTIC (since 2000) — first eleven years as Head of Automation Engineering, then MES Consultant since 2019. Dipl.-Ing. Nachrichtentechnik. Expertise: machine data acquisition (MDE), operational data acquisition (BDE), machine connectivity, PLC programming (Simatic S5/S7/TIA), retrofit projects, OPC UA, IoT gateway integration, brownfield connectivity, process control systems, material-flow control, industrial automation, MES project management, CE conformity. · LinkedIn