Table of Contents
Fetching ...

Towards Timing Isolation for Mixed-Criticality Communication in Software-Defined Vehicles

Lóránt Meszlényi, Julius Kahle, Dominik Püllen, Stefan Kowalewski, Stefan Katzenbeisser, Alexandru Kampmann

TL;DR

The paper addresses unpredictable latency and jitter from mixed-criticality workloads on Linux-based automotive ECUs caused by contention in the Linux network stack. It proposes a layered timing-isolation architecture that combines a fixed-priority, non-preemptive middleware scheduler, kernel-bypass via XDP (afxdp) to route critical traffic directly into application memory, and NIC-queue isolation with dedicated RX/TX queues, complemented by CPU-core isolation. The approach is evaluated in a DDS-based system, showing bounded latency and reduced jitter under line-rate interference, with maximum end-to-end latency remaining within practical bounds (e.g., under $500\,\mu s$ in tested scenarios). The results demonstrate improved determinism and robustness under load, offering a practical path to deterministic mixed-criticality communication on standard Linux stacks for automotive use cases. This work has practical implications for safety-critical, time-sensitive in-vehicle applications by enabling predictable data exchange without resorting to specialized hardware alone.

Abstract

As the automotive industry transitions toward centralized Linux-based architectures, ensuring the predictable execution of mixed-criticality applications becomes essential. However, concurrent use of the Linux network stack introduces interference, resulting in unpredictable latency and jitter. To address this challenge, we present a layered software architecture that enforces timing isolation for Ethernet-based data exchange between mixed-criticality applications on Linux-based automotive control units. Our approach integrates traffic prioritization strategies at the middleware layer, the network stack layer, and the hardware layer to achieve isolation across the full software stack. At the middleware layer, we implement a fixed-priority, non-preemptive scheduler to manage publishers of varying criticality. At the network layer, we leverage the express data path (XDP) to route high-priority data directly from the network interface driver into critical application memory, bypassing the standard Linux network stack. At the hardware layer, we dedicate a network interface card (NIC) queue exclusively to real-time traffic. We demonstrate how our architecture performs in a Data Distribution Service (DDS)-based system. Our evaluation shows that the approach leads to consistent and predictable latencies for real-time traffic, even under heavy interference from best-effort applications.

Towards Timing Isolation for Mixed-Criticality Communication in Software-Defined Vehicles

TL;DR

The paper addresses unpredictable latency and jitter from mixed-criticality workloads on Linux-based automotive ECUs caused by contention in the Linux network stack. It proposes a layered timing-isolation architecture that combines a fixed-priority, non-preemptive middleware scheduler, kernel-bypass via XDP (afxdp) to route critical traffic directly into application memory, and NIC-queue isolation with dedicated RX/TX queues, complemented by CPU-core isolation. The approach is evaluated in a DDS-based system, showing bounded latency and reduced jitter under line-rate interference, with maximum end-to-end latency remaining within practical bounds (e.g., under in tested scenarios). The results demonstrate improved determinism and robustness under load, offering a practical path to deterministic mixed-criticality communication on standard Linux stacks for automotive use cases. This work has practical implications for safety-critical, time-sensitive in-vehicle applications by enabling predictable data exchange without resorting to specialized hardware alone.

Abstract

As the automotive industry transitions toward centralized Linux-based architectures, ensuring the predictable execution of mixed-criticality applications becomes essential. However, concurrent use of the Linux network stack introduces interference, resulting in unpredictable latency and jitter. To address this challenge, we present a layered software architecture that enforces timing isolation for Ethernet-based data exchange between mixed-criticality applications on Linux-based automotive control units. Our approach integrates traffic prioritization strategies at the middleware layer, the network stack layer, and the hardware layer to achieve isolation across the full software stack. At the middleware layer, we implement a fixed-priority, non-preemptive scheduler to manage publishers of varying criticality. At the network layer, we leverage the express data path (XDP) to route high-priority data directly from the network interface driver into critical application memory, bypassing the standard Linux network stack. At the hardware layer, we dedicate a network interface card (NIC) queue exclusively to real-time traffic. We demonstrate how our architecture performs in a Data Distribution Service (DDS)-based system. Our evaluation shows that the approach leads to consistent and predictable latencies for real-time traffic, even under heavy interference from best-effort applications.

Paper Structure

This paper contains 20 sections, 6 figures, 2 tables.

Figures (6)

  • Figure 1: Our objective is to leverage standard Linux scheduling and networking mechanisms to minimize the impact of best-effort traffic on the jitter and maximum end-to-end latency experienced by the real-time traffic.
  • Figure 2: We propose mitigation at different technical levels to reduce the impact of interference traffic on concurrent real-time traffic. We address the middleware layer, the network stack, as well as the network interface controller.
  • Figure 3: We measure rtt and owd in an open-loop fashion, not waiting for the response. Real-time packets are generated at 2kHz with varying packet sizes.
  • Figure 4: Distribution and maximum of owd and rtt using the baseline configuration with a payload size of 1024; bin size equals 10µs.
  • Figure 5: Distribution and maximum of owd and rtt using our timing isolation architecture with a payload size of 1024; bin size equals 10µs.
  • ...and 1 more figures