Logo
ScienceStack
Table of Contents
Fetching ...
Sign In

REDriver: Runtime Enforcement for Autonomous Vehicles

Yang Sun, Christopher M. Poskitt, Xiaodong Zhang, Jun Sun

TL;DR

This work presents REDriver, a general runtime enforcement framework for autonomous vehicles that uses an STL-based specification language (LawBreaker) to encode complex safety properties and traffic laws. It monitors the ADS planned trajectory, computes a robustness measure to detect near-violations, and performs gradient-based trajectory repairs to proactively avoid violations with minimal changes to the journey. Implemented for Apollo 6.0/7.0 and evaluated in a high-fidelity LGSVL simulator against Chinese traffic-law benchmarks, REDriver significantly improves conformance while maintaining low runtime overhead. The approach generalizes runtime enforcement beyond simple safety checks and demonstrates practical viability for enforcing broad policies on real-world ADS architectures.

Abstract

Autonomous driving systems (ADSs) integrate sensing, perception, drive control, and several other critical tasks in autonomous vehicles, motivating research into techniques for assessing their safety. While there are several approaches for testing and analysing them in high-fidelity simulators, ADSs may still encounter additional critical scenarios beyond those covered once they are deployed on real roads. An additional level of confidence can be established by monitoring and enforcing critical properties when the ADS is running. Existing work, however, is only able to monitor simple safety properties (e.g., avoidance of collisions) and is limited to blunt enforcement mechanisms such as hitting the emergency brakes. In this work, we propose REDriver, a general and modular approach to runtime enforcement, in which users can specify a broad range of properties (e.g., national traffic laws) in a specification language based on signal temporal logic (STL). REDriver monitors the planned trajectory of the ADS based on a quantitative semantics of STL, and uses a gradient-driven algorithm to repair the trajectory when a violation of the specification is likely. We implemented REDriver for two versions of Apollo (i.e., a popular ADS), and subjected it to a benchmark of violations of Chinese traffic laws. The results show that REDriver significantly improves Apollo's conformance to the specification with minimal overhead.

REDriver: Runtime Enforcement for Autonomous Vehicles

TL;DR

This work presents REDriver, a general runtime enforcement framework for autonomous vehicles that uses an STL-based specification language (LawBreaker) to encode complex safety properties and traffic laws. It monitors the ADS planned trajectory, computes a robustness measure to detect near-violations, and performs gradient-based trajectory repairs to proactively avoid violations with minimal changes to the journey. Implemented for Apollo 6.0/7.0 and evaluated in a high-fidelity LGSVL simulator against Chinese traffic-law benchmarks, REDriver significantly improves conformance while maintaining low runtime overhead. The approach generalizes runtime enforcement beyond simple safety checks and demonstrates practical viability for enforcing broad policies on real-world ADS architectures.

Abstract

Autonomous driving systems (ADSs) integrate sensing, perception, drive control, and several other critical tasks in autonomous vehicles, motivating research into techniques for assessing their safety. While there are several approaches for testing and analysing them in high-fidelity simulators, ADSs may still encounter additional critical scenarios beyond those covered once they are deployed on real roads. An additional level of confidence can be established by monitoring and enforcing critical properties when the ADS is running. Existing work, however, is only able to monitor simple safety properties (e.g., avoidance of collisions) and is limited to blunt enforcement mechanisms such as hitting the emergency brakes. In this work, we propose REDriver, a general and modular approach to runtime enforcement, in which users can specify a broad range of properties (e.g., national traffic laws) in a specification language based on signal temporal logic (STL). REDriver monitors the planned trajectory of the ADS based on a quantitative semantics of STL, and uses a gradient-driven algorithm to repair the trajectory when a violation of the specification is likely. We implemented REDriver for two versions of Apollo (i.e., a popular ADS), and subjected it to a benchmark of violations of Chinese traffic laws. The results show that REDriver significantly improves Apollo's conformance to the specification with minimal overhead.
Paper Structure (12 sections, 3 theorems, 15 equations, 4 figures, 7 tables, 2 algorithms)

This paper contains 12 sections, 3 theorems, 15 equations, 4 figures, 7 tables, 2 algorithms.

Table of Contents

  1. Introduction
  2. Background and Problem
  3. Overview of Autonomous Driving Systems
  4. Property Specification
  5. The Runtime Enforcement Problem for AVs
  6. Our Approach
  7. Plan Validation
  8. Trajectory Repair
  9. Runtime Enforcement
  10. Implementation and Evaluation
  11. Related Work
  12. Conclusion

Key Result

Proposition 3.3

Let $\varphi$ be an STL formula, $\pi$ be a trace, and $\varepsilon$ be a real value larger than 0. Then, there exists a value $a_1$ such that $|\Tilde{\rho}(\varphi, \pi, i) - \rho(\varphi, \pi, i)| < \varepsilon$ holds for all $a > a_1$. ∎

Figures (4)

  • Figure 1: The architecture of an ADS with $\mathtt{REDriver}$
  • Figure 2: Specification language syntax, where $\varphi$, $\varphi_1$ and $\varphi_2$ are STL formulas, $I$ is an interval, and $f$ is a multivariate linear continuous function over language variables $x_i$
  • Figure 3: Improvement of performance across thresholds
  • Figure 4: Magnitude of modifications to planned trajectories

Theorems & Definitions (12)

  • Example 2.1
  • Definition 1: Problem Definition
  • Definition 2: Quantitative Semantics
  • Example 3.1
  • Example 3.2
  • Proposition 3.3
  • Definition 3
  • Example 3.4
  • Proposition 3.5
  • Proposition 3.6
  • ...and 2 more