Runtime verification of real-time event streams under non-synchronized arrival

Abstract

We study the problem of online runtime verification of real-time event streams. Our monitors can observe concurrent systems with a shared clock, but where each component reports observations as signals that arrive to the monitor at different speeds and with different and varying latencies. We start from specifications in a fragment of the TeSSLa specification language, where streams (including inputs and final verdicts) are not restricted to be Booleans but can be data from richer domains, including integers and reals with arithmetic operations and aggregations. Specifications can be used both for checking logical properties and for computing statistics and general numeric temporal metrics (and properties on these richer metrics). We present an online evaluation algorithm for the specification language and a concurrent implementation of the evaluation algorithm. The algorithm can tolerate and exploit the asynchronous arrival of events without synchronizing the inputs. Then, we introduce a theory of asynchronous transducers and show a formal proof of the correctness such that every possible run of the monitor implements the semantics. Finally, we report an empirical evaluation of a highly concurrent Erlang implementation of the monitoring algorithm. Keywords Stream runtime verification • Monitoring • Real-time event streams • Formal methods • Parallel event processing Torben Scheffel

Stream-based Decentralized Runtime Verification

“…Runtime Verification of stream-based specification was introduced in [2], [23], where the occurrence of the events was assumed to be synchronous. To extend the stream-based runtime verification to more complex systems, one where the occurrence of events is asynchronous, a real-time based logic was introduced in [24]- [26]. However, these methods fall short to verify large geographically separated distributed system, due to their assumption regarding the presence of a shared global clock.…”

Vamos: Middleware for Best-Effort Third-Party Monitoring

“…Writing a run-time monitor can be a complex task, but many tools to express logical reasoning over streams of run-time observations [19,34,16,49,24,27,41] exist. However, trying to actually obtain a concrete stream of observations from a real system introduces a very different set of concerns, which in turn have a huge effect on the performance properties of run-time monitoring [11].…”

“…Vamos then offers a simple specification language for filtering and altering events coming from the event sources, and simple yet expressive event recognition rules that produce a single, global event stream by combining events from a (possibly dynamically changing) number of event sources. Lastly, monitoring code as it is more generally understood-which could be written directly or generated from existing tools for run-time verification like LTL formulae [47], or stream verification specifications [8] such as TeSSLa [41]processes these events to generate verdicts about the monitored system.…”

“…-We built middleware to connect higher-level monitors with event sources, addressing particular challenges of best-effort third-party monitoring (Section 2), using a mixture of efficient inter-process communication and easy-touse facilities for load management (Section 3) on one hand, and buffer groups and other event recognition abstractions (Section 4) on the other hand. -We implemented a compiler for Vamos specifications, a number of event sources, and a connector to TeSSLa [41] monitors (Section 5). -We conducted some stress-test experiments using our framework, as well as a case study in which we implemented a monitor looking for data races, providing evidence of the feasibility of low-overhead third-party monitoring with simple specifications (Section 6).…”

Formal Analysis of AI-Based Autonomy: From Modeling to Runtime Assurance

“…The design and implementation of the decision module is critical to achieve principled switching between the AC and SC that keeps performance penalties to a minimum while retaining strong safety guarantees. Monitors can be defined and implemented using a variety of frameworks [21,15,29,10,14,28,32], ranging from automata and logics to very expressive programming languages with a trade-off between expressivity and efficiency guarantees. The choice of monitor language depends on the requirements of the application and constraints of the implementation platform.…”