Microservice Architectures for Advanced Driver Assistance Systems: A Case-Study

Abstract

The technological advancements of recent years have steadily increased the complexity of vehicle-internal software systems, and the ongoing development towards autonomous driving will further aggravate this situation. This is leading to a level of complexity that is pushing the limits of existing vehicle software architectures and system designs. By changing the software structure to a service-based architecture, companies in other domains successfully managed the rising complexity and created a more agile and future-oriented development process. This paper presents a case-study investigating the feasibility and possible effects of changing the software architecture for a complex driver assistance function to a microservice architecture. The complete procedure is described, starting with the description of the software-environment and the corresponding requirements, followed by the implementation, and the final testing. In addition, this paper provides a high-level evaluation of the microservice architecture for the automotive use-case. The results show that microservice architectures can reduce complexity and time-consuming process steps and make the automotive software systems prepared for upcoming challenges as long as the principles of microservice architectures are carefully followed.

Feature dependencies in automotive software systems: Extent, awareness, and refactoring

“…A recent trend in automotive architectures is the migration to service-oriented architectures [29,40,41] to allow for more flexible and faster development and deployment. In a recent case study, we have shown how an advanced driver assistance function can be migrated to a microservice architecture [30]. The definition of modular services may well support our proposed refactoring approach.…”

“…The most prominent example of a layered architecture for automotive software is probably AUTOSAR [28], which decouples application software components from base software components within an ECU. However, also within the application software, there is a trend towards structuring the application software components with respect to different dedications (e.g., sensor fusion, controllers, service functionality) [29,30]. Figure 3 shows an example of an application software component architecture that has a dedicated platform component layer (PCL).…”

Model-based resource analysis and synthesis of service-oriented automotive software architectures

“…As an example, the RACE approach [89] was initialised in 2012. More recently, Lotz et al [61] published one approach that relies on a run-time environment for microservices. In this work, we are using the SOME/IP as the communication protocol.…”

Identifying Domain-Based Cyclic Dependencies in Microservice APIs Using Source Code Detectors

“…Several solutions for this problem have been suggested, all with their specific advantages or disadvantages: Applying the API Gateway pattern [28], as recommended by Taibi and Lenarduzzi [27], is a possible way of decoupling the system, switching to an asynchronous communication model is another [7,19]. While the first approach reduces the coupling, it bears the risk of creating a single point of failure in the system [15]. Worse, in this solution there is still a cycle in the system, but just via the API gateway.…”

“…Some authors (see e.g. [15,33]) suggest that the only effective way to resolve these domain-based communication cycles is redesigning the architecture on the domain level. However, for this, the cyclic connections first have to be identified, which is not always a trivial task, considering the polyglot nature of microservice implementations [26].…”