RTLola: Real-Time Stream Monitoring

• RTLola is a stream-based specification language that defines real-time properties for reactive and cyber-physical systems using variable-rate inputs and sliding windows.
• It achieves predictable constant memory usage by trading off full expressiveness for static resource safety, leveraging formal pacing types and bounded memory analyses.
• The framework supports multiple execution backends and development tools, enabling deployment on FPGA, Rust, WebAssembly, and integrated environments like the RTLola Playground.

RTLola is a stream-based specification language and monitoring framework for the description of real-time properties of reactive and cyber-physical systems. It extends Lola with true real-time support, variable-rate input streams, time-driven output clocks, real-time offsets into the past, and sliding windows with aggregation; across its subsequent development, it has also acquired static analyses for pacing, dependency structure, and memory usage, multiple execution backends, browser-based authoring support, and formal type systems for asynchronous and parameterized monitoring (Faymonville et al., 2017, Finkbeiner et al., 2023).

1. Origins, scope, and design trade-offs

RTLola emerged from the stream-based tradition represented by Lola, but its defining move was to incorporate real-time structure directly into the language. In the foundational account, an RTLola specification consists of input streams and output stream templates, with optional fixed-rate clocks and real-time sliding windows, so that monitors can combine variable-rate observations with time-driven derived quantities (Faymonville et al., 2017). Later system descriptions sharpen the design goals as expressiveness, predictability, nonintrusiveness, and efficiency, especially for safety-critical cyber-physical systems such as unmanned aircraft (Baumeister et al., 2020).

The framework is explicitly positioned as a runtime monitoring technology rather than a general-purpose programming environment. Input streams represent sensor readings, messages, or other timestamped observations; output streams represent filtered, aggregated, or otherwise derived quantities; triggers report violations or notable conditions. This organization recurs across deployments ranging from FPGA-based aircraft monitors and Android automotive diagnostics to fairness monitoring and visualization-oriented monitors (Baumeister et al., 2020, Biewer et al., 2021, Baumeister et al., 30 Jan 2025, Baumeister et al., 2022).

A central design choice is the trade-off between expressiveness and analyzability. Several papers emphasize that RTLola targets predictable constant memory and statically bounded resource usage. This yields strong implementation properties, but it also means that not every real-time property is admitted in exact form. One representative statement is that a fully sound monitor of “every request r must be followed by g within 1 s” would require unbounded memory, so RTLola rejects the exact specification and admits only constant-memory under-approximations (Schwenger, 2020). That trade-off is fundamental to the identity of the language, not an incidental implementation restriction.

2. Stream model, temporal operators, and parameterization

At the core of RTLola is a stream-equational model. In one formalization, each stream defines a partial function $s : \mathbb{R} \to T$ that maps real-valued timestamps to values when the stream ticks; in another, semantics are given over a discrete index together with a strictly increasing time map. These presentations are compatible in spirit: the monitor observes timestamped inputs and evaluates derived streams only at designated event times or logical clock ticks (Faymonville et al., 2017, Baumeister et al., 28 Jul 2025, Baumeister et al., 11 Mar 2026).

RTLola distinguishes event-triggered and time-triggered behavior. Event-based outputs update when relevant dependencies produce new values; periodic outputs update at fixed frequencies such as @1Hz or @100mHz. The language further supports past references via offsets, zero-order retention via hold, and first-class real-time sliding windows with aggregation functions such as sum, count, min, max, average, ∫, and, in later application-oriented presentations, pctl(n) (Faymonville et al., 2017, Biewer et al., 2021). A window expression of duration $r$ over a stream $s$ is defined over the multiset

$W_t = \{ s(\tau) \mid \tau \in [t-r,t) \},$

with the aggregate applied to $W_t$ when nonempty and a default otherwise (Faymonville et al., 2017).

A notable semantic feature is the decoupling of variable-rate inputs from fixed-rate outputs through windowing. The original real-time stream paper describes how sliding windows evaluated at monitor frequency $f$ are partitioned into intervals of width $z = 1/f$, allowing aggregation over a real-time window without requiring the input stream itself to be periodic (Faymonville et al., 2017). This mechanism is one of the main ways RTLola reconciles asynchronous sensing with predictable evaluation schedules.

Later work extends the language with parameterized streams. Instead of a single output stream, a declaration can denote an unbounded family of stream instances indexed by parameter tuples. The operational discipline is organized around spawn, eval, and close clauses, so instances are created on demand, evaluated under explicit pacing and guards, and reclaimed when their close condition holds (Baumeister et al., 11 Mar 2026). This instance model underlies specifications for dynamically evolving collections such as products, waypoints, defendants in fairness monitoring, or airspace participants (Faymonville et al., 2017, Baumeister et al., 30 Jan 2025).

3. Pacing, type systems, and static analysis

A defining technical theme in RTLola is that streams are typed not only by value domain but also by timing behavior. One account describes this as a two-dimensional type discipline consisting of a value type and a pacing type (Schwenger, 2020); the IDE-oriented presentation states that in RTLola every stream carries both a data type and a pacing type describing when new values appear, with exactly two pacing classes in that setting: event-based and periodic (Finkbeiner et al., 2023).

Pacing is not merely a scheduling annotation. In the asynchronous-stream formalization, direct synchronous access and prev require a value “now,” whereas hold may fall back on the most recent value. Output streams carry pacing annotations expressed as positive Boolean formulas over input names, and inconsistency arises when an output is required to fire at times when a synchronously accessed dependency cannot supply a value (Kohn et al., 26 May 2026). This makes pacing semantically substantive: it constrains when an equation must be computable.

The static analyses exposed in the RTLola toolchain include pacing-type checking, dependency-graph construction with cycle detection, and memory-bound computation. The IDE paper gives an informal compatibility rule for synchronous accesses: periodic-to-periodic access is allowed iff the consumer frequency divides the producer frequency; event-based-to-event-based access is allowed iff the consumer formula implies the producer formula; periodic-to-event-based mixing is disallowed (Finkbeiner et al., 2023). The same paper defines the dependency graph as a directed, weighted multi-graph with one node per input or output stream and an edge whenever a definition contains an offset or synchronous access. A specification is ill-formed iff this graph contains a cycle whose total weight sums to zero; in the IDE this is surfaced as a causal cycle error (Finkbeiner et al., 2023).

Memory analysis is equally central. For discrete offsets, the IDE presentation states the upper bound

$B_s \le w_{\max}+1,$

where $w_{\max}$ is the maximum offset used on stream $s$ (Finkbeiner et al., 2023). For sliding windows over periodic streams of frequency $r$0 and duration $r$1, the same source gives the bound $r$2 memory slots (Finkbeiner et al., 2023). The foundational real-time stream paper generalizes this with an annotated dependency graph: non-homomorphic windows over variable-rate dependencies can yield $r$3, whereas fixed-rate or homomorphic windows admit finite bounds such as $r$4, $r$5, or $r$6 depending on pacing and aggregation class (Faymonville et al., 2017). The distinction between homomorphic and non-homorphic aggregation is therefore operationally decisive.

Two later type-theoretic developments strengthen these guarantees. The pacing-types work proves a soundness theorem stating that well-typed specifications are consistent, and the proof has been machine-checked in the Rocq proof assistant (Kohn et al., 26 May 2026). The parameterized-streams work adds a refinement type system over pacing and semantic tick-sets, shows that full semantic implication is undecidable by reduction to Robinson arithmetic embedded in stream expressions, and therefore adopts a decidable but conservative approximation that guarantees accepted specifications are memory-safe and error-free at runtime (Baumeister et al., 11 Mar 2026). Together, these results move RTLola beyond resource analysis toward formally justified absence of runtime timing and memory errors.

4. Evaluation algorithms, optimization, and target backends

RTLola monitors are executed by combining event-driven and time-driven computation. The foundational evaluation algorithm separates a variable-rate component, triggered on each incoming input event, from a fixed-rate component, triggered at each tick of a fixed-rate clock. The variable-rate phase extends the input stream, updates frame summaries for dependent windows, and performs stream-instance bookkeeping; the fixed-rate phase combines the last $r$7 frame summaries, evaluates due output instances, propagates newly produced values, repeats to a fixpoint, and terminates instances whose close condition holds (Faymonville et al., 2017). This organization is the operational basis for mixed asynchronous and periodic monitoring.

For useful aggregation functions, RTLola uses pane-based window evaluation. Homomorphic aggregates such as sum, count, min, and max can be maintained by partitioning time into frames and storing only interval summaries, so each window update shifts a bounded frame buffer and re-aggregates the summaries rather than replaying all raw events (Faymonville et al., 2017). This same idea reappears in later descriptions of FPGA and software execution as the reason sliding windows can remain statically bounded (Baumeister et al., 2020, Schwenger, 2020).

Compilation and optimization have become a major subsystem in their own right. One line of work presents direct compilation to synthesizable VHDL for FPGA deployment, organized around a High-Level Controller, FIFO queue, and Low-Level Controller, with evaluation layers derived from the dependency graph so that independent streams run in parallel (Baumeister et al., 2020). Another line introduces StreamIR, an intermediate representation that preserves stream concepts while translating specifications into a single-loop imperative form with tasks such as spawn, shift, eval, and close, together with rewrites such as Common-If, Iterate-Inside, Unique-Assign, Unnecessary-Shift, and exact ring-buffer sizing (Baumeister et al., 30 Apr 2025). Earlier optimization work had already adapted Sparse Conditional Constant Propagation and Common Subexpression Elimination to RTLola, and added RTLola-specific Pacing Type Refinement and Filter Refinement (Baumeister et al., 2020).

The reported performance data illustrate the practical impact of these backends. On a Zynq-7000 Artix-7 FPGA, one avionics monitor is reported at approximately $r$8 clock cycles at $r$9 MHz, i.e. $s$0, while a network monitor is reported at approximately $s$1 clock cycles, i.e. $s$2 (Baumeister et al., 2020). For a highly parallelizable case study with $s$3 independent outputs, the sequential variant is reported at approximately $s$4 and the fully parallel variant at $s$5, host-limited (Baumeister et al., 2020). In the StreamIR evaluation, the existing RTLola interpreter is consistently the slowest; the StreamIR interpreter is faster, and compiled Rust with StreamIR rewrites is faster still, with the COMPAS equalized-odds monitor reported at $s$6 ms for the existing interpreter, $s$7 ms for the unoptimized StreamIR interpreter, $s$8 ms for the optimized StreamIR interpreter, $s$9 ms for unoptimized compiled Rust, and $W_t = \{ s(\tau) \mid \tau \in [t-r,t) \},$0 ms for optimized compiled Rust (Baumeister et al., 30 Apr 2025).

5. Development environments and integration architecture

RTLola has also developed a substantial tooling story around specification authoring, debugging, and system integration. The RTLola Playground is a browser-based development environment that uses a Monaco-based editor, surfaces static analyses from the Rust-based frontend, visualizes the dependency graph with D3.js and elkjs, executes specifications locally in the browser through a Rust-to-WebAssembly interpreter, plots Boolean and numerical streams with Apache ECharts, and supports step-wise execution over user-provided traces in CSV, JSON, PCAP, and related formats (Finkbeiner et al., 2023). Its stated purpose is to help specifiers understand pacing behavior, dependency structure, and memory consequences while testing and debugging specifications interactively.

The Playground makes several analysis results explicit in the user interface. In memory view mode, edge thickness is proportional to offset size and node color to the buffer bound $W_t = \{ s(\tau) \mid \tau \in [t-r,t) \},$1; in pacing view mode, node color is proportional to frequency, with fast streams in red and slower streams in blue (Finkbeiner et al., 2023). The paper’s examples show how a copy-paste error in a hold(or: ...) argument can change a stream from @1Hz to event-based pacing, and how a wrong offset size can leave type checking intact while visibly changing the memory view (Finkbeiner et al., 2023). This suggests that RTLola’s static analyses are not only compilation aids but also specification-comprehension tools.

A separate integration line, developed in the Volocopter case study, formalizes the separation between a stable RTLola monitor core and environment-specific adapters. The paper introduces an abstraction layer with EventConversion and VerdictConversion around the RTLola core; on the Rust side this is expressed through EventSource, EventFactory, VerdictSink, and VerdictFactory traits (Baumeister et al., 2024). The same core monitor is then reused across log-file analysis, software-in-the-loop, hardware-in-the-loop, and flight testing by changing only the adapters. Reported figures include latencies of < 2 ms in SiL on a 3 GHz x86 machine, < 5 ms per event on an ARM Cortex-M4 at 168 MHz in HiL, and < 1 µs worst-case latency in FPGA mode (Baumeister et al., 2024).

The Android deployment for Real Driving Emissions provides a further integration archetype. There, the RTLola engine is embedded in the LolaDrives app behind a pipeline consisting of a Bluetooth OBD-II adapter, an Android BluetoothService, a DataBuffer with GPS provider, an RTLolaEngine, a UI module, and an optional CloudUploader (Biewer et al., 2021). The monitor processes tuples (PID, value, timestamp) from OBD-II, supports both event-triggered and time-triggered evaluation, and maintains sliding windows by incremental insertion and garbage collection. On a “typical mid-range Android phone,” the paper reports up to 200 events/s sustained, CPU load of 3–6 % of one core when monitoring 30 streams, actual rural-spec window memory of approximately 2.2 MB peak, and end-to-end processing per sample < 0.3 ms (Biewer et al., 2021).

6. Applications, misconceptions, limitations, and ongoing extensions

RTLola has been applied across a strikingly wide range of monitoring domains. In unmanned aircraft and eVTOL settings, it has been used for geofencing, GPS–IMU cross-validation, watchdogs, flight-phase detection, and other hazard monitors, with deployment both in passive FPGA monitors adjacent to a datalogger and in software-integrated development environments (Baumeister et al., 2020, Baumeister et al., 2024). In automotive monitoring, it has been used on smartphones for EU Real Driving Emissions diagnosis via OBD-II adapters (Biewer et al., 2021). In algorithmic fairness, RTLola has been used to formalize group-fairness metrics such as demographic parity and equalized odds over temporal data streams, including the COMPAS dataset (Baumeister et al., 30 Jan 2025). In visualization, it has been used to specify the data transformation layer itself, so synchronization, filtering, aggregation, and user-attention management remain inside the monitor specification rather than being outsourced to an external visualization tool (Baumeister et al., 2022).

Several misconceptions are corrected by this body of work. First, RTLola is not restricted to passive observation. The conventional setup is indeed a passive external component that continuously receives sensor data, but active monitoring extends RTLola with scheduling annotations such as #[priority="k"] and #[deadline="d s"], allowing a scheduler to decide which sensors to query and how often based on the monitor’s current internal state (Baumeister et al., 28 Jul 2025). In an AirSim drone study, the scheduled monitor uses total bandwidth = 4 inputs/sec, matching the 1 Hz passive baseline, yet is reported to detect violations on average as early as the 2 Hz monitor using 8 inputs/sec, with median latency approximately that of the 3 Hz monitor (Baumeister et al., 28 Jul 2025).

Second, RTLola is not an FPGA-only technology. FPGA compilation is one prominent backend, but the literature also documents browser execution via WebAssembly, embedded Android execution, Rust compilation, Solidity compilation through StreamIR, and deployment in simulator and desktop environments (Finkbeiner et al., 2023, Biewer et al., 2021, Baumeister et al., 30 Apr 2025). Conversely, it is also not merely a lightweight scripting layer: the formal developments around pacing soundness, parameterized memory safety, and dependency-graph-based resource analysis show that static guarantees are a first-class design objective (Kohn et al., 26 May 2026, Baumeister et al., 11 Mar 2026, Faymonville et al., 2017).

The literature also records clear limitations. The browser-based Playground has no built-in module system yet; graph collapsing is only a UI workaround, very large specifications can still overwhelm the browser, an interactive tutorial is planned but not yet integrated, and a VS Code extension is envisioned (Finkbeiner et al., 2023). The basic pacing-type system is equation-order sensitive, though later work introduces a permutation rule to address that issue; self-references require a more intricate interpretation (Kohn et al., 8 Sep 2025). At the language-design level, the persistent limitation remains the one already present in early RTLola: predictable constant memory constrains expressiveness, especially for properties that require remembering an unbounded set of pending obligations (Schwenger, 2020).

Taken together, these developments present RTLola as a formally structured, implementation-oriented stream language whose distinctiveness lies in the combination of real-time windowing, explicit pacing, parameterized dynamic instances, static resource reasoning, and multi-target deployment. The cumulative research record suggests a framework that has evolved from a real-time stream calculus into a broader monitoring ecosystem while retaining its original emphasis on analyzability and deployment in safety-critical settings.