Real-Time Monitoring Systems
- Real-Time Monitoring (RTM) is the continuous acquisition, processing, and visualization of operational data, enabling rapid diagnostics and intervention.
- RTM systems employ varied architectures—from sensor pipelines and digital twins to Bayesian and model-based inferences—to optimize efficiency and accuracy.
- Applications span manufacturing, healthcare, transportation, and environmental monitoring, with performance metrics validating timely decision-making.
Searching arXiv for the provided RTM papers to ground the article. Real-time monitoring (RTM) denotes the continuous acquisition, processing, and use of operational data while a process or system is running, with outputs delivered quickly enough to support diagnosis, warning, allocation, control, or human intervention. In the literature considered here, RTM spans RFID-based operator–machine allocation in manufacturing, Bayesian supervision of automated-vehicle time gaps, mobile electrocardiogram telemetry, IoT indoor air-quality sensing, reduced-order modeling of water networks, satellite-based environmental reconstruction, macroeconomic state estimation, stream-based runtime verification, digital twins for supercomputers, monocular traffic analytics, functional process monitoring, and cloud–edge railway fault diagnosis (Chavhan et al., 2014, Kontar et al., 2021, Yuksel, 19 Oct 2025, Elkhashap et al., 2022, Li et al., 2018, Baumeister et al., 2022, Bergeron et al., 2024, Wu et al., 2024).
1. Scope and defining characteristics
Across these works, RTM is not restricted to raw sensor polling. It includes event-driven state updates, online estimation of latent variables, synchronization of asynchronous streams, visualization-oriented filtering, and supervisory decisions taken before a run, batch, or maneuver has completed. The monitored entities differ sharply by domain: operator presence and operator–machine assignment in factories; time gap in automated vehicles; ECG waveform and pulse on mobile systems; temperature, humidity, and CO-equivalent in buildings; temperature, flow rate, and pressure in water networks; PM fields reconstructed from hourly geostationary observations; output gaps and trend inflation in macroeconomics; and fault states of railway turnout machines (Chavhan et al., 2014, Kontar et al., 2021, Yuksel, 19 Oct 2025, Sarkar et al., 2023, Elkhashap et al., 2022, Li et al., 2018, Hasenzagl et al., 2022, Wu et al., 2024).
A concise cross-domain view is shown below.
| Domain | Monitored quantity | RTM mechanism |
|---|---|---|
| Industrial shop floor | Operator presence and operator–machine assignment | RFID scan events and GSM/GPRS allocation updates |
| Automated vehicles | Actual time gap | Bayesian updating plus control chart |
| Mobile ECG | ECG waveform and pulse | Serial streaming, filtering, plotting, threshold alerts |
| Water networks | Temperature, flow rate, pressure | Reduced-order physics model and HiL prediction |
| Supercomputers | Node, GPU, storage, user activity | Big-data ingestion and 3D digital twin |
| Railway RTMs | Fault types from three-phase current | Edge–cloud pipeline parallelism |
The literature also uses different temporal interpretations of “real time.” FPGA monitoring of CPS targets hard real-time execution with statically bounded time and memory, whereas industrial allocation, indoor CO sensing, and public-cluster supervision operate at human-scale or near-real-time cadences; ecological forecasting updates every 3–4 hours because the underlying process evolves slowly (Baumeister et al., 2020, Sarkar et al., 2023, 0708.0607, Culita et al., 2017).
2. Architectural patterns and data pipelines
A recurring RTM architecture is a staged pipeline from acquisition to state update to presentation. In the operator–machine system Omams, Scan-In and Scan-Out units send RFID events via GSM/GPRS SIM900 to a Central Unit, which maintains the set of present operators, machine assignments, a waiting list, and a vacant-machine list, then updates workshop and office displays in near real time (Chavhan et al., 2014). In the mobile ECG system, the path is patient ECG module ADC serial link ECG server/.NET application SQL Server and web service mobile clients, with threshold-based alerting and remote viewing (Yuksel, 19 Oct 2025). In the CO0 instrument, MQ135 and DHT11 readings are processed by a NodeMCU ESP8266, displayed on a 16×2 I1C LCD, and uploaded to ThingSpeak over HTTP (Sarkar et al., 2023).
A second pattern is the explicit separation of local elements from global coordination. The water-network framework constructs a distributed-parameter model for each pipe, reduces it by parametric model order reduction, and then assembles the network from many such elements, coupled by a hydraulic solver on a directed graph (Elkhashap et al., 2022). The railway turnout system uses end devices, edge RMUs, and a cloud center; diagnosis tasks are partitioned into subtasks and scheduled across edge and cloud according to resource, queue, and communication conditions (Wu et al., 2024). The macroeconomic model is similarly layered in an abstract sense: monthly latent states, quarterly observables treated as missing for two months out of three, and Kalman filtering over mixed-frequency releases and vintages (Hasenzagl et al., 2022).
A third pattern is the conversion of large heterogeneous telemetry into a structured intermediate representation before visualization. MIT Lincoln Laboratory Supercomputing Center uses raw data/logs, pre-processed files, an LLSC dataset stored in Apache Accumulo with D4M, analytics in Matlab/Octave, and a Unity front end for 3D monitoring (Bergeron et al., 2021). The later “3D Digital Twin” system retains this architecture while adding history files, user isolation, and machine-level granularity (Bergeron et al., 2024). This suggests that, in large-scale RTM, the monitorable state is often a derived artifact rather than the raw stream itself.
3. Data processing, inference, and decision logic
Many RTM systems in this literature are model-based rather than purely threshold-based. In automated-vehicle monitoring, the observed spacing is modeled as
2
with 3, and online inference uses the closed-form Bayesian update
4
after which a Shewhart-type control chart compares the estimated time gap to 5, 6, and 7 (Kontar et al., 2021). In functional RTM, partially observed curves are registered via an open-end/open-begin functional dynamic time warping model, reduced by mixed FPCA, and monitored through
8
with Šidák-adjusted control limits across 9 and 0 charts (Centofanti et al., 2022).
Physics-based RTM appears most explicitly in water networks. Pipe temperature is modeled by the advection–diffusion–reaction PDE
1
which is semi-discretized into a bilinear ODE, reduced to a low-dimensional ROM, and then used online for prediction and future control-oriented work (Elkhashap et al., 2022). In satellite PM2 monitoring, a Geo-intelligent Deep Belief Network estimates ground-level PM3 from AOD, meteorology, NDVI, and spatial-temporal covariates, and a spatio-temporal fusion model reconstructs missing fields using auxiliary times and similarity-weighted regression (Li et al., 2018). In traffic monitoring, SG-IPM estimates a homography 4 between a camera view and satellite imagery, then computes bird’s-eye-view coordinates 5, which feed Kalman-filtered speed and trajectory estimates and 3D box rendering (Rezaei et al., 2021).
RTM in runtime verification follows yet another formalism. RTLola treats monitoring as the evaluation of input and output streams under explicit pacing types, offsets, holds, and sliding-window aggregations such as
6
and compiles these specifications to synthesizable VHDL with statically bounded memory and execution time (Baumeister et al., 2020). The later visualization work pushes this further: synchronization, interpolation, filtering, and attention management are described as RTLola stream equations, and visualization state becomes part of the monitor’s own computation rather than an external post-processing step (Baumeister et al., 2022). A recurring misconception is therefore that RTM is simply “sampling plus thresholds.” The cited work instead includes Bayesian estimation, reduced-order modeling, functional registration, spatio-temporal fusion, stream semantics, and reinforcement-learning-based scheduling (Kontar et al., 2021, Elkhashap et al., 2022, Centofanti et al., 2022, Li et al., 2018, Wu et al., 2024).
4. Visualization, interfaces, and the human operator
RTM repeatedly appears as a human-in-the-loop discipline. Omams exposes operator–machine assignments, waiting operators, and vacant machines on display units in the workshop and in the manager’s office, making a sequential FCFS allocation visible to both workers and supervisors (Chavhan et al., 2014). The pen-manufacturing production monitoring system similarly uses display boards to show current production data versus target, good count, rejection, and consumption trends, so that deviations can be acted upon while production is online (Prasad et al., 2017). EcoMonFor combines eko-View, eko-Greenhouse, and eko-Forecast, linking wireless sensing, greenhouse supervision, command logging, and forecasting interfaces (Culita et al., 2017).
In biomedical and transport settings, visualization is both analytical and operational. The ECG platform plots original and filtered data in standard ECG units, displays pulse rate in real time, and propagates data to mobile clients and remote viewers through a web service (Yuksel, 19 Oct 2025). Traffic-Net produces 3D vehicle and pedestrian boxes, bird’s-eye-view trajectories, and heatmaps for movement, speeding, congestion, and high-risk pedestrian–vehicle proximity (Rezaei et al., 2021). The RTLola visualization work argues that synchronization, filtering, aggregation, and prioritization should be the responsibility of the monitor itself; a bidirectional synchronous interface carries monitor outputs to the visualization component and backchannel inputs such as pixel scale or visibility back to the monitor (Baumeister et al., 2022).
The supercomputing literature turns visualization into a central RTM modality. MM3D maps over 3,000 HPC components and 6,366 environmental sensors into a Unity scene representing EcoPODs, racks, nodes, storage, and accelerators, with colors, animations, and overlays encoding load and alert states (Bergeron et al., 2021). The later MIT Lincoln Laboratory Supercomputing Center digital twin adds Virtual User Avatars whose size and color encode a usage score and potential performance impact, plus a history system for replaying system-wide events (Bergeron et al., 2024). This suggests that RTM interfaces increasingly serve not only alarming but also explanation, attribution, and training.
5. Timeliness, accuracy, and reported performance
The quantitative profile of RTM varies strongly by domain. ECG monitoring uses a 300 Hz sampling frequency with 9600 baud serial communication, which the paper treats as sufficient for soft real-time clinical visualization (Yuksel, 19 Oct 2025). The IoT indoor-air node updates roughly every 4–5 seconds, which is characterized as “Near real‑time” for slowly varying environmental parameters (Sarkar et al., 2023). Traffic-Net runs a customized YOLOv5-Large (3-head) detector at 7 fps on a single NVIDIA RTX 2080 GPU, while all other processing is reported as 8 ms per frame (Rezaei et al., 2021). At the hard-real-time end, FPGA compilation of RTLola yields cycle-bounded monitoring with fixed memory footprints (Baumeister et al., 2020).
Several papers report explicit prediction or diagnostic metrics:
| System | Reported RTM measure | Reported result |
|---|---|---|
| Water-network ROM | Downstream temperature prediction | mean relative error below 9; single step computation time did not exceed 0 msec |
| Full water-network validation | Temperature / flow / pressure | mean relative errors below 1, 2, and 3 |
| Himawari-8 PM4 retrieval | Out-of-sample cross-validation | 5, RMSE 6 |
| PM7 reconstruction | Recovery vs ground measurements | 8 |
| RTM turnout diagnosis | Fault classification accuracy | 9 |
| CEC-PA scheduling | Total inference time | speed-up ranging from 0 to 1 |
These results illustrate that RTM performance is multidimensional: latency, throughput, predictive accuracy, error rates, and recovery under disruption all matter. The railway paper makes this explicit by jointly optimizing execution time and transmission time under timeout, resource, coverage, and dependency constraints, and by adding coordinator-election logic to preserve service during downtime (Wu et al., 2024). The water-network paper uses Hardware in the Loop deployment on the VIEGA test bench to show that reduced-order models can satisfy industrial real-time constraints without sacrificing distributed spatial resolution (Elkhashap et al., 2022).
6. Benefits, limits, and directions of extension
The literature assigns RTM several recurring benefits: continuous visibility of the operating state, earlier detection of deviation or fault, more transparent allocation or scheduling, reduced manual recordkeeping, and support for later efficiency, utilization, or forensic analysis (Chavhan et al., 2014, Prasad et al., 2017, Kebande et al., 2020). In some domains RTM also functions as a foundation for control rather than as an end in itself: autonomous-vehicle monitoring recommends time-gap changes, greenhouse monitoring informs irrigation, water-network ROMs are intended for future NMPC, and railway diagnosis feeds early-warning decisions in a 7×24 transport system (Kontar et al., 2021, Culita et al., 2017, Elkhashap et al., 2022, Wu et al., 2024).
The limitations are equally domain-specific but structurally similar. Several systems depend on disciplined sensing behavior: operators must remember to scan in and out in Omams; ECG quality suffers from external noise, ambient temperature, and imperfect isolation; MQ135 calibration is only single-point and cloud uploads have no buffering; Traffic-Net depends on reliable monocular calibration and can be affected by lighting or occlusion (Chavhan et al., 2014, Yuksel, 19 Oct 2025, Sarkar et al., 2023, Rezaei et al., 2021). Model-based systems inherit model dependence: the Bayesian AV framework assumes Gaussian errors and a linear CTH relationship; water-network ROMs currently fix 2 and 3 as time-invariant; functional RTM requires registration quality and weighting choices; macroeconomic real-time estimates remain sensitive to identifying restrictions and to whether official output-gap measures are imposed (Kontar et al., 2021, Elkhashap et al., 2022, Centofanti et al., 2022, Hasenzagl et al., 2022).
A broader controversy concerns what should count as “real time.” The cited work does not impose a single universal latency target. For FPGAs and runtime verification, real time is tied to bounded per-event execution and fixed hardware size; for supercomputing digital twins, it is timely situational awareness at cluster scale; for PM4 monitoring, hourly fields from geostationary satellite data are sufficient; for greenhouse ecology, 3–4-hour forecast updates are appropriate because the process is slow (Baumeister et al., 2020, Bergeron et al., 2024, Li et al., 2018, Culita et al., 2017). This suggests that RTM is best understood as a relation between computational delay and process dynamics, rather than as a single frequency class.
The same papers also indicate likely directions of development. Several architectures are already posed as expandable: Omams could feed MES or ERP; ECG monitoring could support online patient monitoring, patient location tracking, and defibrillation infrastructure; water-network ROMs are intended to incorporate disinfectant concentration and centralized NMPC; supercomputer digital twins are moving toward replay, user isolation, and larger-scale ECS-based rendering; railway RTM points toward broader mission-critical cloud–edge fault diagnosis (Chavhan et al., 2014, Yuksel, 19 Oct 2025, Elkhashap et al., 2022, Bergeron et al., 2024, Wu et al., 2024). A plausible implication is that RTM increasingly serves as the connective tissue between sensing, inference, visualization, and intervention across cyber-physical systems.