Experimental Validation of User Experience-focused Dynamic Onboard Service Orchestration for Software Defined Vehicles

TL;DR

Experimental results obtained from a dedicated test bench illustrate, validate, and assess the practicality of the proposed dynamic onboard service orchestration in SDVs, providing a solid foundation for the continued advancement of dynamic onboard service orchestration in SDVs.

Abstract

In response to the growing need for dynamic software features in automobiles, Software Defined Vehicles (SDVs) have emerged as a promising solution. They integrate dynamic onboard service management to handle the large variety of user-requested services during vehicle operation. Allocating onboard resources efficiently in this setting is a challenging task, as it requires a balance between maximizing user experience and guaranteeing mixed-criticality Quality-of-Service (QoS) network requirements. Our previous research introduced a dynamic resource-based onboard service orchestration algorithm. This algorithm considers real-time invehicle and V2X network health, along with onboard resource constraints, to globally select degraded modes for onboard applications. It maximizes the overall user experience at all times while being embeddable onboard for on-the-fly decisionmaking. A key enabler of this approach is the introduction of the Automotive eXperience Integrity Level (AXIL), a metric expressing runtime priority for non-safety-critical applications. While initial simulation results demonstrated the algorithm's effectiveness, a comprehensive performance assessment would greatly contribute in validating its industrial feasibility. In this current work, we present experimental results obtained from a dedicated test bench. These results illustrate, validate, and assess the practicality of our proposed solution, providing a solid foundation for the continued advancement of dynamic onboard service orchestration in SDVs.

Figures (5)

• Figure 1: Example of AXIL ratings attributed to the 1-5 runtime modes for each of the 20 applications. Higher modes provide more features, hence better QoE and execution priority.
• Figure 2: Hardware architecture of test bench made of 4 ECUs connected in star topology using TSN-enabled network links.
• Figure 3: Simplified representation of the software stack. (A) We use K3s as the Kubernetes distribution to orchestrate and distribute the containerized applications and their runtime modes into the ECUs. (B) The application is structured to generate mock best-effort network traffic according to a manifest file. These manifests are distributed to the ECUs at launch time.
• Figure 4: Solving times on the test bench depending on the problem size with parameters given in the associated table.
• Figure 5: Experimental results with an app store of 50 applications and 6 state changes of random sets of applications. We show our proposed network health metric when launching apps at (A) their nominal modes and (B) at the mode calculated by our algorithm. (C) Illustrates the runtime mode decisions in both scenarios with the requested applications and launched modes.