Real-Time Monitoring: What Actually Changes

What is real-time monitoring in manufacturing?

Real-time monitoring in manufacturing is the continuous, automatic capture of machine, process and production events at a latency short enough to change the next decision on the shop floor. It is the data-layer foundation underneath OEE dashboards, alarm systems, quality control and every flavour of digital shopfloor management. Without it, everything downstream — KPIs, alerts, schedules, reports — is a retrospective based on partial memory. With it, the plant operates on facts that are minutes or seconds old, not shifts or days.

I have been building real-time monitoring systems for manufacturers since 1989 — first as a consultant at SAS, then at STERIA with process-control and early MES for food and beverage, and since 1995 at SYMESTIC. In those 36 years the underlying technology has changed completely four times. The underlying human problem has not changed at all. Every plant believes it already knows what is happening in its production. Almost every plant is wrong by 15 to 30 percent — not because the people are wrong, but because without continuous measurement, perception is systematically distorted. This article is about why that happens, what "real-time" actually means in manufacturing, and what separates real-time monitoring that works from real-time monitoring that just looks impressive.

"Real-time" is three different things — don't conflate them

The first source of confusion in nearly every RTM conversation is that "real-time" is being used as a single word for three latency classes that have almost nothing in common. They serve different decisions, require different architectures, and fail in different ways. Getting them apart is the prerequisite for every sensible monitoring decision.

A system can be excellent at one class and useless at another, and the choice has direct architectural consequences. Closed-loop control cannot be done in the cloud and should not be attempted. Operational dashboards cannot be done on a nightly ETL and should not be attempted. Managerial reporting does not need sub-second latency and paying for it is wasted money. Any vendor that sells "real-time monitoring" without telling you which class they mean is selling you a word, not a system.

The first-day gap: why real-time monitoring is disruptive before it is useful

In 36 years of turning on automatic data capture in plants for the first time, I have seen the same pattern repeat more than three hundred times. The plant believes, before the system is live, that it runs at 78 percent availability. On day one of real-time measurement, the system reports 61 percent. The operations director insists the number is wrong. It is not wrong. The measurement is correct. The previous number was an estimate stitched together from paper shift logs and memory, and it was systematically optimistic — always. I have never once seen the direction go the other way.

The same pattern repeats for micro-stops (nearly always 2-3× what the plant believed), changeover times (typically 20-40 percent longer), first-pass yield (usually 3-6 points lower than the previous number) and setup duration (almost always wider in variance than anyone thought). Not because people were lying. Because paper-based and memory-based measurement systems are physically incapable of capturing the sub-five-minute stops, the short deviations, the daily variance that real instrumentation sees by default.

The single rule I teach every customer before go-live: when the numbers drop in the first two weeks of real-time monitoring, that is the system working, not the system failing. The plant is not getting worse. The plant is getting measured for the first time. Resist the urge to "calibrate" the new numbers up to the old ones, because that is exactly how honest instrumentation gets turned back into comfortable fiction. The gap between the old number and the new number is the improvement runway.

The 30-year arc — and why "too complex" is no longer a valid reason

Real-time monitoring in manufacturing has gone through four generations in my career, and each one was roughly 10× cheaper and 10× faster to deploy than the previous one. The reason "we haven't done it because it's too complex" is no longer a valid answer in 2026 is that the complexity argument is about 15 years out of date.

• Generation 1 (1990s): Paper shift reports, manual end-of-shift entry into the plant's mainframe. Latency: 8-24 hours. Cost: mostly operator time. Accuracy: rough.
• Generation 2 (2000s): PLC direct-connect into on-premise process-control systems, specialist engineer required per line. Latency: minutes. Cost: six-figure per plant. Time to deploy: 6-18 months.
• Generation 3 (2010s): On-premise OEE software layered on top of MDE/BDE infrastructure, plant-level servers, custom integrations. Latency: seconds. Cost: mid-five- to low-six-figure per plant. Time to deploy: 3-9 months.
• Generation 4 (2020s): Cloud-native event ingestion via OPC UA, MQTT and digital-I/O gateways into a multi-tenant platform. Latency: sub-second. Cost: four-figure per month per plant. Time to deploy: days to weeks.

The deployment profile is the point. In generation 4 we routinely connect 10 machines in under a month and entire plants in under three months, with no PLC intervention and no production interruption. That is a categorical change, not an incremental one. Plants that still carry generation-2 assumptions about what real-time monitoring costs or takes to deploy are holding back investment for reasons that no longer exist in the market they operate in.

Monitoring is now cheap — acting on it is the hard part

Because the sensing, telemetry and dashboard layers have collapsed in cost, the failure pattern in real-time monitoring projects has shifted. It used to be that projects failed because the technology was too expensive or too brittle. In 2026 it is nearly always because the plant bought the monitoring layer and did not build the workflow response. The dashboard goes live, the numbers are visible, the alerts fire — and nothing happens, because nobody has defined who acts on what, by when, with what escalation if no action is taken.

The question that separates real monitoring from theatrical monitoring is uncomfortable and has to be answered before the system is built: when this threshold is crossed, what action is taken, by whom, within what timeframe, and what happens if that action is not taken? If the answer is "someone will see it at the next shift huddle and we'll discuss it then," that is not real-time monitoring; it is end-of-shift review with a more expensive display. Real-time monitoring that actually changes outcomes always has a specific, time-boxed human response attached to each significant event class — and it has an escalation if the first response does not close the event.

Alert fatigue: the category error

The second structural failure I see consistently is alert inflation. The monitoring system goes live, every possible threshold is configured, and within a month the plant is receiving 300-500 alerts per day. Within two months, nobody on the floor is reading them. Within three months, the whole system is treated as background noise and the plant effectively has no alerting. A monitoring system that generates 400 alerts a day has zero alerts, not 400. That is a category error, not a volume problem.

The fix is boring engineering. Define the five or ten events that actually warrant an immediate human response. Define who responds to each, with what action, in what timeframe. Send only those as alerts. Everything else goes to the dashboard as information, not as an alert, and is reviewed on a scheduled cadence. Signal-to-noise engineering is the single most underinvested discipline in manufacturing digitalisation, and it is the difference between a plant that acts faster because of monitoring and a plant that wastes engineering time drowning in it.

A real case: Neoperl

Neoperl is a German-headquartered specialist in water-flow products — aerators, flow regulators, backflow preventers — with production sites in Germany, Bulgaria, the UK and Italy. The fully-automated assembly lines that produce their products are technologically demanding, which is the kind of environment where real-time monitoring either earns its keep immediately or exposes itself as theatre within weeks. The Neoperl engagement is the cleanest example in the SYMESTIC portfolio of real-time monitoring used as a continuous-improvement engine rather than as a reporting tool.

The starting point was a four-week proof of concept on a single line. The technical architecture was deliberately narrow and precise: SPS-based alarm capture directly from the machine, automatic stop categorisation by the equipment itself without any operator entry, and correlation of PLC alarms with quality defects in the same data model. That last detail is the one that matters. Most "real-time monitoring" projects capture stops and quality separately and never cross-reference them. Correlating them turned out to be where the improvement insights actually lived.

After the PoC validated the functionality and the ROI model, Neoperl rolled out to the first three lines and has been expanding continuously since. The critical organisational detail — the one that separates successful monitoring implementations from the rest — was that the system was explicitly positioned as a KVP (continuous improvement) tool, not as a reporting tool. Every alarm pattern detected became the input to a structured improvement workflow, not just a coloured line on a dashboard.

The measured outcomes across the connected lines:

• 10 % fewer stops, through automatic capture and machine-driven categorisation (no operator-entry dependency)
• 8 % improvement in availability, through structured analysis of the top stop categories and targeted CI actions
• 15 % less scrap, through systematic correlation of PLC alarm patterns with quality defects
• 15 % productivity gain, through cumulative action on the highest-impact loss categories visible in the data

Every one of those numbers is a workflow-response outcome, not a dashboard outcome. The monitoring made the losses visible. The KVP workflow made them go away. Both were necessary. Neither was sufficient.

FAQ

What is the difference between real-time monitoring and SCADA?
SCADA is historically focused on operational control of the machine and process — it lives close to the PLC layer, and its primary job is supervisory control, not business-level visibility. Real-time monitoring in the MES sense is a layer above: it takes the same machine signals but contextualises them against orders, shifts, operators and products to produce KPIs like OEE, availability and first-pass yield. A modern MES can consume SCADA data, but the two layers answer different questions for different users.

What counts as "real-time" in a manufacturing context?
There is no single answer — it depends on the decision the data supports. Closed-loop control needs sub-100-millisecond latency. Operator dashboards need 1-60 seconds. Shift-management workflows can tolerate 1-15 minutes. Enterprise KPI reporting works fine at 15-minute to hourly refresh. A vendor that promises "real-time" without specifying which class is selling language, not engineering. Honest systems tell you the latency they deliver and let you pick the class that matches each use case.

Do we need to upgrade our PLCs to get real-time monitoring?
Almost never. I have personally seen plants with 1990s-vintage PLCs connected into real-time monitoring within a working day, using digital-I/O gateways that tap the existing cycle and stop signals without touching the PLC program. The belief that "our machines are too old" is the most common reason plants delay monitoring projects, and in 2026 it is almost always wrong. Modern retrofit connectivity was designed specifically for brownfield environments.

How fast should a real-time monitoring implementation be?
In 2026, go-live on the first line in 1-3 weeks is typical for a cloud-native platform. Scaling across a plant in 1-3 months is typical once the pattern is established. If a vendor quotes 9-18 months for initial go-live, they are quoting a generation-2 or generation-3 architecture, and the architecture is the problem, not the scope. This is one of the clearest differentiators between mature cloud-native MES platforms and older on-premise offerings repackaged as "cloud."

How do we avoid alert fatigue?
Define the five to ten event classes that genuinely require an immediate human response. Define who responds, with what action, in what timeframe, and what escalates if the response does not close the event. Everything else goes to the dashboard as information, not as an alert. Review the alert catalogue quarterly and retire anything that has not triggered action in the last 90 days. Signal-to-noise engineering is boring but decisive — a system with ten well-calibrated alerts beats a system with three hundred.

What should we monitor first?
Start with stop events (status, duration, category) and cycle counts at the bottleneck machines. Those two data classes deliver 80 percent of the improvement runway at 20 percent of the complexity. Add quality data once the availability baseline is honest. Add energy data once the operational KPIs are stable. Add predictive-maintenance data once the reactive-maintenance workflow is functioning. The common error is trying to monitor everything at once — by the time the system is live, the organisation is overwhelmed and acts on nothing.

Cloud or edge for real-time monitoring?
Both, for different jobs. Control-loop latency (sub-100-millisecond) must be handled at the edge; no cloud architecture will beat physics. Operational and tactical monitoring (seconds to minutes) is best served by a cloud platform with edge gateways — this gives you the scale and cross-plant analytics without the on-premise maintenance burden. In 2026 the pragmatic pattern is edge for control, cloud for visibility and analytics, and a clean protocol boundary (OPC UA, MQTT) between the two.

How does SYMESTIC support real-time monitoring?
Automatic event capture via OPC UA, MQTT and digital-I/O gateways (including retrofit on legacy machines); sub-second telemetry into Microsoft Azure; continuous aggregation of availability, performance, quality and alarm KPIs; role-appropriate rendering across operator terminals, shift-manager browsers and enterprise analytical views; bidirectional integration with SAP, Infor, proAlpha, Navision and Dynamics; alert catalogues with built-in signal-to-noise discipline. Go-live in days, not months, on 15,000+ connected machines across 18 countries. See SYMESTIC Production Metrics.

Related: OEE · MES · KPI Dashboard · Machine Data Acquisition · Shopfloor Management · Production Data · Alarm Management · SYMESTIC Production Metrics

About the author

Uwe Kobbert

Founder and CEO of SYMESTIC GmbH. Over 36 years in manufacturing software, starting at SAS (1989) and STERIA before founding SYMESTIC in Dossenheim in 1995. Built the company from on-premise MES roots to today's cloud-native platform connecting 15,000+ machines in 18 countries across four continents. Bootstrapped, profitable, zero customer churn in 2024. Dipl.-Ing. Nachrichtentechnik/Elektronik. Nominated for the Großer Preis des Mittelstandes. · LinkedIn