Real-time monitoring is one of the most discussed concepts in production digitization - and at the same time one of the most frequently wrongly dimensioned. Too many companies invest in monitoring infrastructure and only realize after implementation that they have either monitored too much (a data grave), too little (no added value) or the wrong thing (data that nobody needs).
The reason is usually a lack of clarity about two fundamental questions: What exactly should the monitoring do? And: What latency do I really need? After all, a real-time monitoring system for predictive maintenance has completely different requirements to one for OEE reporting - and this is directly reflected in complexity, infrastructure requirements and costs.
This article provides an honest overview: five specific monitoring use cases with measurable benefits, realistic implementation costs and ROI calculations - plus the technical principles that determine what 'real-time' really means in which context.
THE MOST IMPORTANT FACTS IN BRIEF
|
BRIEFLY SUMMARIZED
|
What real-time monitoring in production really means
'Real-time' is not an absolute term. It describes a time span between event and reaction that is short enough to be meaningful for the respective use case. What real-time means for welding robot collision protection (< 1 millisecond) is irrelevant for an OEE dashboard (30-second aggregation is completely sufficient).
Production monitoring can be divided into four reaction levels: Control level (< 1 ms, PLC/PLC), monitoring level (< 100 ms, plant protection), optimization level (seconds to minutes, process control) and analysis level (minutes to hours, reporting and KPIs). Each level has different infrastructure requirements - and different costs.
|
62 % Manufacturing companies with monitoring without a defined use case Fraunhofer IPA Digital Study 2024 |
3-5× Cost factor real-time infrastructure vs. batch infrastructure CSP project data 2024/25 |
12-18 mon. Typical ROI of well-dimensioned monitoring CSP customer projects DACH |
< 30 s Sufficient latency for 80% of all production KPIs ISA 95 practical analysis |
The system architecture: from sensor to dashboard
A complete real-time monitoring system consists of four architectural levels that build on each other. Each level has a specific function, specific technologies and specific latency characteristics.
|
LEVEL 1 Sensor level |
FUNCTION Physical measurement: temperature, pressure, vibration, current, position, image |
TECHNOLOGY Industrial sensors, screwdriver IO, camera, RFID, barcode |
LATENCY µs-ms (native measurement) |
|
LEVEL 2 Edge level |
FUNCTION Local pre-processing and filtering: limit value monitoring, aggregation, protocol conversion |
TECHNOLOGY Edge computer, IPC, OPC UA gateway, MQTT broker |
LATENCY ms-100 ms |
|
LEVEL 3 Platform level |
FUNCTION Central processing, persistence, analysis: time series database, stream processing, ML inference |
TECHNOLOGY Time series database (InfluxDB, TimescaleDB), Apache Kafka, MES |
LATENCY 100 ms-seconds |
|
LEVEL 4 Dashboard level |
FUNCTION Visualization, alerting, reporting: real-time dashboards, KPIs, alarm management, reports |
TECHNOLOGY Grafana, SCADA HMI, MES dashboard, mobile app |
LATENCY Seconds-Minutes |
Latency requirements: What really needs real time?
The latency requirement of a monitoring use case directly determines the infrastructure costs. If you do not explicitly clarify this requirement early on in the project, you are either building too expensive (real-time infrastructure for batch use cases) or too cheap (batch infrastructure for real-time use cases).
|
Monitoring scenario |
Max. Latency |
Response window |
Technology |
Architecture requirement |
|---|---|---|---|---|
|
Machine protection / emergency shutdown |
< 1 ms |
microseconds |
PLC/PLC, fieldbus |
Dedicated control level - no IT system |
|
Collision and safety monitoring |
< 100 ms |
milliseconds |
Real-time OS, EtherCAT |
Deterministic edge processing, no cloud |
|
Process control loop (temperature, pressure) |
< 1 s |
seconds |
OPC UA, Edge IPC |
Edge + local control logic, minimal network dependency |
|
Anomaly detection process parameters |
< 10 s |
minutes (intervention) |
OPC UA, MQTT, Edge-ML |
Edge inference or local platform, no cloud constraint |
|
OEE live tracking |
< 1 min |
Shift/hour |
REST API, MQTT, OPC UA |
MES/platform sufficient, cloud possible |
|
Energy monitoring |
< 1 min |
Hourly/daily |
Smart meter, Modbus, REST |
Platform or cloud, aggregation sufficient |
|
Predictive maintenance trigger |
< 5 min |
Hours to days |
OPC UA, MQTT, ML platform |
Cloud or on-premises ML platform |
|
KPI reporting and OEE analysis |
< 5 min |
End of day / shift |
REST API, batch ETL |
Batch pipeline sufficient - no real-time required |
The five use cases with ROI calculation
The following use case maps show the five most cost-effective real-time monitoring applications in series production - with realistic implementation costs, running costs and ROI timeframes for a typical production plant with 100-200 production employees.
| Use case | Measurable benefits | Implementation costs | Ongoing p.a. | ROI | Latency |
|---|---|---|---|---|---|
|
UC 01
OEE Live Tracking
monitoring |
|
15.000-40.000 €
Hardware, integration, configuration
|
4.000-8.000 €
License, support, maintenance
|
8-14 months | < 1 min. |
|
UC 02
Anomaly detection Process parameters
monitoring |
|
25.000-60.000 €
Machine connection, ML model, integration
|
6.000-12.000 €
ML infrastructure, retraining, support
|
10-18 months | < 10 sec. |
|
UC 03
Predictive maintenance
Monitoring |
|
40.000-120.000 €
Vibration sensors, ML modeling, integration
|
10.000-25.000 €
ML platform, sensor maintenance, retraining
|
14-24 months | < 5 min. |
|
UC 04
Inline quality monitoring
Monitoring |
|
30.000-150.000 €
Camera/measurement system per inspection point, software
|
5.000-15.000 €
Camera maintenance, model maintenance, support
|
8-20 months | < 1 sec. |
|
UC 05
Energy monitoring & load optimization
Monitoring |
|
10.000-30.000 €
Smart meter, aggregator, dashboard
|
2.000-6.000 €
Data platform, reporting, support
|
6-12 months | < 1 min. |
What real-time monitoring costs: an honest calculation
The following calculation shows the full cost components for a typical real-time monitoring implementation in a plant with 20-30 machines and the primary use case OEE tracking + anomaly detection. All figures are based on CSP project experience in the DACH region.
|
Cost category |
One-off |
Ongoing p.a. |
Assumptions / Explanation |
|---|---|---|---|
|
Hardware: sensors, IoT gateway, edge devices |
8.000-20.000 € |
800-2.000 € |
Depending on machine type and number of measuring points; retrofit often cheaper than new equipment |
|
Software license: Monitoring platform |
5,000-15,000 € (setup) |
6.000-18.000 € |
SaaS or on-premises; per system or flat rate depending on provider |
|
Integration: MES/ERP connection |
8.000-25.000 € |
1.000-3.000 € |
Interface development; standardized OPC UA reduces costs considerably |
|
Commissioning & configuration |
5.000-15.000 € |
- |
Dashboard configuration, threshold setting, training |
|
Ongoing IT infrastructure (cloud/on-prem) |
- |
3.000-8.000 € |
Cloud: according to data volume; on-premises: server maintenance |
|
BENEFITS: OEE increase +5 PP (estimated) |
- |
↑ 80.000-200.000 € |
For 20 machines × 500 €/h × 20h shift × 250 days × 5 PP OEE |
|
BENEFITS: Scrap reduction -25 % |
- |
↑ 30.000-80.000 € |
Depending on the current scrap value; typically 1-3 % scrap rate |
|
BENEFITS: Energy saving -12 % |
- |
↑ 15.000-40.000 € |
Dependent on energy consumption; larger systems proportionally higher benefit |
|
Total investment: € 26,000-75,000 one-off |
↑ 100,000-250,000 € benefit p.a. less ~11,000-31,000 € ongoing costs |
→ ROI: 6-18 months |
Real-time monitoring is not an IT investment. It is a productivity investment. The question is not: What does the system cost? The question is: What does every hour of machine downtime that we don't see cost?
-Amadeus Lederle CTE, CSP Intelligence GmbH
The implementation path: from simple to complex
Real-time monitoring does not have to start as a major project. A step-by-step expansion - starting with the simplest use case with the highest ROI - reduces the project risk and enables quick initial results that build internal trust in the technology.
|
STAGE 1 Reactive |
STAGE 2 Transparent |
LEVEL 3 Preventive |
LEVEL 4 Predictive |
|---|---|---|---|
|
WHAT IS MEASURED Downtimes, machine conditions, OEE basis |
WHAT IS MEASURED Process parameters, quality KPIs, shift comparison |
WHAT IS MEASURED Anomalies, limit value monitoring, maintenance planning |
WHAT IS MEASURED ML-based prediction, predictive quality, predictive maintenance |
|
TECHNOLOGY Signal access, simple dashboard |
TECHNOLOGY OPC UA, MES connection, SPC |
TECHNOLOGY Edge analysis, time series data, alerting |
TECHNOLOGY ML platform, cloud or on-prem, model retraining |
|
Investment: €5,000-15,000 ROI: < 12 months |
Invest: €20,000-60,000 ROI: 8-18 months |
Invest: €50,000-120,000 ROI: 12-24 months |
Invest: € 80,000-200,000 ROI: 18-36 months |
The most common monitoring mistakes and how to avoid them
Real-time monitoring rarely fails because of the technology - it fails because of the strategy. The following list shows the most common mistakes made in CSP projects.
|
Error |
Symptom |
Cause |
Solution |
|---|---|---|---|
|
Use case unclear |
Dashboards built, but nobody looks at them |
No defined goal: What should change as a result of monitoring? |
Define use case before selecting technology: Who reacts to which data and how? |
|
Too many data points |
Data grave: TBs of data, 0 decisions |
Every sensor is connected 'because you already have it' |
Think backwards: What decision do I need? Then which data? |
|
Real-time for batch use case |
High infrastructure costs without added value |
Latency requirement not analyzed - 'real-time' ordered across the board |
Explicitly define latency requirements for each use case before architecture decision |
|
No alert concept |
Dashboards ring constantly, are ignored |
Alerts not prioritized according to ISA 18.2 - everything is CRITICAL |
Alert design parallel to monitoring introduction: priorities, thresholds, escalation |
|
No integration into the MES |
Monitoring island without consequence in the system |
Monitoring and MES not connected: Data remains in the dashboard |
Write monitoring data back to MES production order for traceability |
|
No ownership |
Dashboards become obsolete, no one acknowledges alarms |
No one is responsible for monitoring data and response |
Designate a monitoring owner: Who is responsible for data quality and response? |
Real-time monitoring integrated with full traceability
|
PRACTICAL TIP CSP IPM - Real-time monitoring natively integrated CSP IPM combines real-time monitoring with complete production traceability in one system. Process parameters, machine statuses and quality data are recorded in real time and automatically assigned to the respective serial number or batch - for seamless verification and real added value.
|
Frequently asked questions
What is the difference between real-time monitoring and data history?
Real-time monitoring shows the current status of a system or process with a minimal time delay. Data history is the recording of these values over time - it enables trend analysis, root cause analysis and comparisons over time. Both are complementary: without real-time monitoring, I react too slowly to current events. Without a data history, I cannot recognize patterns or build predictive maintenance models. A complete monitoring system needs both.
How many sensors do I need to get started with OEE monitoring?
For simple OEE monitoring, a single signal tap per machine is often sufficient: the operating hours counter or the run/idle signal. This can be used to calculate availability and utilization. For complete OEE including performance and quality rate, you also need a cycle/piece counter and an IO/NIO message from the test station. That is a total of 2-4 signals per machine - far fewer than many companies assume.
Can I retrofit older machines without OPC UA for real-time monitoring?
Yes - through retrofit approaches. The most common method is to attach external sensors (vibration, current, temperature sensors) to the machine without interfering with the control system. Alternatively: tapping existing signals via IO modules on the control cabinet socket. For older PLC controllers, there are OPC UA gateways that translate proprietary protocols (Siemens S7, Modbus) into OPC UA. The retrofit cost is typically around €500-3,000 per machine, depending on the level of automation.
What is the difference between edge computing and cloud monitoring?
Edge computing processes data locally on the machine or in the network segment - with very low latency (milliseconds) and without internet dependency. Cloud monitoring transmits data to a remote server for processing - with higher latency (seconds to minutes), but with more computing power for analysis and ML. For security functions and process control: always Edge. For predictive maintenance models and comprehensive analyses: often cloud or hybrid model. Most production companies use both levels in combination.
How long does it take to implement a real-time monitoring system?
That depends heavily on the use case and the number of machines. Simple OEE monitoring for 10 machines with an existing network infrastructure: 4-6 weeks. Anomaly detection with OPC UA connection for 20 machines: 8-16 weeks. Predictive maintenance with ML modeling: 3-9 months (including 2-6 months of model training on historical data). The most common time waster is not the technology - it is the data quality check: machine signals must be validated, time stamps synchronized and outliers corrected.
What is OEE and how do I calculate it?
OEE (Overall Equipment Effectiveness) is the combined key figure for machine efficiency. It is calculated from three factors: availability (actual runtime / planned runtime), performance (actual output / theoretical output) and quality rate (good parts / total parts produced). OEE = availability × performance × quality rate. An OEE of 85% is considered a world-class value for discrete manufacturing. In practice, many plants are at 50-65 %. The gap is the potential.
When is predictive maintenance worthwhile - and when is it not?
Predictive maintenance is worthwhile if: the machine is expensive (> €200,000), unplanned downtimes have expensive consequences (line downtime, delivery delays), the machine type has a predictable wear path and historical data is available for ML model training. It is not worthwhile if: the machine is inexpensive and can be replaced quickly, breakdowns do not generate any relevant follow-up costs or the system has too short an operating time to generate sufficient training data. As a rule of thumb: Unplanned downtime > 3 hours × hourly rate > annual monitoring costs → pays off.
Can I also use monitoring data for quality audits?
Yes - and this is one of the most important, often underestimated added values. If monitoring data (process parameters, machine status) is automatically assigned to the serial number or batch, proof of quality in accordance with IATF 16949 section 8.5.1 (process parameter documentation) and 7.1.5.1 (measuring device management) is created at the same time. This means that real-time monitoring is not just a productivity tool - it is a compliance infrastructure. CSP IPM automatically links monitoring data and traceability data.