R2U2: Tool Overview

Abstract

R2U2 (Realizable, Responsive, Unobtrusive Unit) is an extensible framework for runtime System Health Management (SHM) of cyber-physical systems. R2U2 can be run in hardware (e.g., FPGAs), or software; can monitor hardware, software, or a combination of the two; and can analyze a range of different types of system requirements during runtime. An R2U2 requirement is specified utilizing a hierarchical combination of building blocks: temporal formula runtime observers (in LTL or MTL), Bayesian networks, sensor filters, and Boolean testers. Importantly, the framework is extensible; it is designed to enable definitions of new building blocks in combination with the core structure. Originally deployed on Unmanned Aerial Systems (UAS), R2U2 is designed to run on a wide range of embedded platforms, from autonomous systems like rovers, satellites, and robots, to human-assistive ground systems and cockpits.R2U2 is named after the requirements it satisfies; while the exact requirements vary by platform and mission, the ability to formally reason about Realizability, Responsiveness, and Unobtrusiveness is necessary for flight certifiability, safety-critical system assurance, and achievement of technology readiness levels for target systems. Realizability ensures that R2U2 is sufficiently expressive to encapsulate meaningful runtime requirements while maintaining adaptability to run on different platforms, transition between different mission stages, and update quickly between missions. Responsiveness entails continuously monitoring the system under test, real-time reasoning, reporting intermediate status, and as-early-as-possible requirements evaluations. Unobtrusiveness ensures compliance with the crucial properties of the target architecture:

Towards a framework for certification of reliable autonomous systems

“…Specifications are difficult to write for the same reasons as for model checking; further complications include noisiness of sensor data and challenges of real-world environments. Limitations and constraints of embedded systems and certification processes challenge RV implementations, though to date three tools have risen to these real-world-deployment challenges and more are sure to follow [3,196,220]. Of course, violation of certain critial safety properties is not acceptable, even if this is detected.…”

Embedding Online Runtime Verification for Fault Disambiguation on Robonaut2

“…In flight, Robonaut2's configuration system will handle specification loading. R2U2 is realizable, responsive, and unobtrusive [22]; it embeds observers for Robonaut2's symptoms in hardware, returns observer verdicts at the system clock rate, and is adaptable to the highlyconstrained operational environment without affecting existing joint control, respectively. We apply two of R2U2's reasoning layers: signal processing (which processes incoming signals into Boolean atomics) and temporal observation (which evaluates MLTL specifications).…”

“…R2U2 allows runtime configuration of the observer specifications, while the size and duration limits of these specifications are design-time parameters. For R2U2 to dynamically reconfigure specifications at runtime (without resynthesis or recertification), we utilize BRAMs for instruction memory, variable memory, and queues; see [22]. Memory requirements are driven by queue depth and timestamp length.…”

“…RVS is the only other modern hardware RV implementation; its limited expression language only monitors the internal behavior of a real-time operating system and RVS requires resynthesis to change monitored properties [27]. The Realizable Responsive Unobtrusive Unit [22] (R2U2) is the only RV tool that starts an encoding with the resource constraints and then optimizes the verification configuration to reliably detect as many faults as possible, rather than, e.g., starting with runtime monitors and creating resource-consuming implementations. R2U2's online, stream-based, hardware (FPGA) implementation, provable unobtrusiveness, and ability to change monitors without resynthesis fit the R2 project.…”

From Simulation to Runtime Verification and Back: Connecting Single-run Verification Techniques

“…Both discrete-event simulation and runtime verification can be either event-triggered or time-triggered, with event-triggered being the most common, as in next-event simulation. Few RV tools are time-triggered by default (Falcone, Krstić, Reger, and Traytel 2018), with a few notable exception of time-triggered monitors (Rozier and Schumann 2017, Azzopardi, Colombo, Ebejer, Mallia, and Pace 2017, Navabpour, Joshi, Wu, Berkovich, Medhat, Bonakdarpour, and Fischmeister 2013. Importantly, runtime verification tools do not generally represent clocks in the same way as simulations, though we can usually define equivalences, e.g., through counters or reliance on checks of external-to-the-RV-engine system clocks.…”