Logo
ScienceStack
Table of Contents
Fetching ...
Sign In

CARISMA: CAR-Integrated Service Mesh Architecture

Kevin Klein, Pascal Hirmer, Steffen Becker

TL;DR

CARISMA addresses the growing software complexity in modern vehicles by adapting service-m mesh concepts to automotive HPC clusters. It introduces a centralized Control Plane with a single service proxy per HPC, plus node and service registries that generate node-specific configuration views to support dynamic, location-agnostic service deployment, including cloud integration. The prototypical validation demonstrates feasible inter-service communication across nodes and runtime redeployment without downtime, using Go, gRPC, and Envoy. The approach promises scalable, flexible, and efficient distribution of in-car applications while mitigating in-vehicle resource constraints, with planned evaluations of overhead and broader deployment scenarios.

Abstract

The amount of software in modern cars is increasing continuously with traditional electric/electronic (E/E) architectures reaching their limit when deploying complex applications, e.g., regarding bandwidth or computational power. To mitigate this situation, more powerful computing platforms are being employed and applications are developed as distributed applications, e.g., involving microservices. Microservices received widespread adoption and changed the way modern applications are developed. However, they also introduce additional complexity regarding inter-service communication. This has led to the emergence of service meshes, a promising approach to cope with this complexity. In this paper, we present an architecture applying the service mesh approach to automotive E/E platforms comprising multiple interlinked High-Performance Computers (HPCs). We validate the feasibility of our approach through a prototypical implementation.

CARISMA: CAR-Integrated Service Mesh Architecture

TL;DR

CARISMA addresses the growing software complexity in modern vehicles by adapting service-m mesh concepts to automotive HPC clusters. It introduces a centralized Control Plane with a single service proxy per HPC, plus node and service registries that generate node-specific configuration views to support dynamic, location-agnostic service deployment, including cloud integration. The prototypical validation demonstrates feasible inter-service communication across nodes and runtime redeployment without downtime, using Go, gRPC, and Envoy. The approach promises scalable, flexible, and efficient distribution of in-car applications while mitigating in-vehicle resource constraints, with planned evaluations of overhead and broader deployment scenarios.

Abstract

The amount of software in modern cars is increasing continuously with traditional electric/electronic (E/E) architectures reaching their limit when deploying complex applications, e.g., regarding bandwidth or computational power. To mitigate this situation, more powerful computing platforms are being employed and applications are developed as distributed applications, e.g., involving microservices. Microservices received widespread adoption and changed the way modern applications are developed. However, they also introduce additional complexity regarding inter-service communication. This has led to the emergence of service meshes, a promising approach to cope with this complexity. In this paper, we present an architecture applying the service mesh approach to automotive E/E platforms comprising multiple interlinked High-Performance Computers (HPCs). We validate the feasibility of our approach through a prototypical implementation.
Paper Structure (10 sections, 4 figures)

This paper contains 10 sections, 4 figures.

Table of Contents

  1. INTRODUCTION
  2. RELATED WORK
  3. CARISMA
  4. Node Registration
  5. Service Registration
  6. Local Configuration View
  7. Global Configuration View
  8. Service-to-Service Communication
  9. PROTOTYPICAL VALIDATION
  10. CONCLUSION AND FUTURE WORK

Figures (4)

  • Figure 1: Example applying the traditional service mesh architecture. Figure adopted with minor modifications from Li2019.
  • Figure 2: Example applying CARISMA.
  • Figure 3: Typical communication scenarios within CARISMA.
  • Figure 4: Setup used for validating CARISMA. The minimalistic orchestrator has been left out for a better overview.