---
title: 'RTLola: Real-Time Stream Monitoring'
url: https://www.emergentmind.com/topics/rtlola
type: topic
---

# RTLola: Real-Time Stream Monitoring

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 [1711.03829][2311.08096].

## 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 [1711.03829]. Later system descriptions sharpen the design goals as expressiveness, predictability, nonintrusiveness, and efficiency, especially for safety-critical cyber-physical systems such as unmanned aircraft [2004.06488].

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 [2004.06488][2111.05255][2501.18331][2205.12823].

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 [2012.08959]. 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 [1711.03829][2507.20615][2603.11104].

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)` [1711.03829][2111.05255]. 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 [1711.03829].

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 [1711.03829]. 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 [2603.11104]. This instance model underlies specifications for dynamically evolving collections such as products, waypoints, defendants in fairness monitoring, or airspace participants [1711.03829][2501.18331].

## 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 [2012.08959]; 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 [2311.08096].

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 [2605.26635]. 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 [2311.08096]. 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 [2311.08096].

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$ [2311.08096]. For sliding windows over periodic streams of frequency $f$ and duration $D$, the same source gives the bound $\lceil D \cdot f \rceil$ memory slots [2311.08096]. The foundational real-time stream paper generalizes this with an annotated dependency graph: non-homomorphic windows over variable-rate dependencies can yield $\infty$, whereas fixed-rate or homomorphic windows admit finite bounds such as $\lceil y \cdot r \rceil$, $\lceil r/z \rceil$, or $\min(\lceil r/z \rceil,\lceil y \cdot r \rceil)$ depending on pacing and aggregation class [1711.03829]. 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 [2605.26635]. 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 [2603.11104]. 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 $\lceil r/z \rceil$ frame summaries, evaluates due output instances, propagates newly produced values, repeats to a fixpoint, and terminates instances whose close condition holds [1711.03829]. 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 [1711.03829]. This same idea reappears in later descriptions of FPGA and software execution as the reason sliding windows can remain statically bounded [2003.12477][2012.08959].

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 [2003.12477]. 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 [2504.21458]. 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 [2011.13344].

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 $428$ clock cycles at $100$ MHz, i.e. $4.28\,\mu s/\text{event}$, while a network monitor is reported at approximately $320$ clock cycles, i.e. $3.20\,\mu s/\text{event}$ [2003.12477]. For a highly parallelizable case study with $512$ independent outputs, the sequential variant is reported at approximately $43.83\,\mu s/\text{event}$ and the fully parallel variant at $\le 3.77\,\mu s/\text{event}$, host-limited [2003.12477]. 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 $17.258$ ms for the existing interpreter, $12.889$ ms for the unoptimized StreamIR interpreter, $7.943$ ms for the optimized StreamIR interpreter, $3.157$ ms for unoptimized compiled Rust, and $1.443$ ms for optimized compiled Rust [2504.21458].

## 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 [2311.08096]. 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 $B_s$; in pacing view mode, node color is proportional to frequency, with fast streams in red and slower streams in blue [2311.08096]. 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 [2311.08096]. 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 [2404.12035]. 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 [2404.12035].

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` [2111.05255]. 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` [2111.05255].

## 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 [2004.06488][2404.12035]. In automotive monitoring, it has been used on smartphones for EU Real Driving Emissions diagnosis via OBD-II adapters [2111.05255]. 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 [2501.18331]. 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 [2205.12823].

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 [2507.20615]. 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 [2507.20615].

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 [2311.08096][2111.05255][2504.21458]. 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 [2605.26635][2603.11104][1711.03829].

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 [2311.08096]. 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 [2509.06724]. 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 [2012.08959].

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.

Source: https://www.emergentmind.com/topics/rtlola