Technical Challenges of Software-Defined Vehicles

In this article, we’ll dive deeper into the hardware and software decoupling challenges in SDV vehicles, and explore how they can be navigated with virtualization, software-oriented architectures, AUTOSAR, and the Automotive API.

Hardware & Software Decoupling in SDV Vehicles

Before discussing the technical challenges, we need to understand what a software-defined vehicle is. The most common definition of SDVs is provided by BlackBerry QNX – “a Software-Defined Vehicle is any vehicle that manages its operations, adds functionality, and enables new features primarily or entirely through software”.

There’s another definition offered by IBM, which states that “An SDV serves as the technological base for future innovations, acting as a command center for collecting and organizing vast volumes of the data, applying AI for insights and automating thoughtful actions”.

The Eclipse Foundation suggests that SDV refers to “a transformation where the physical and digital components of an automobile are decoupled and features, functionality, and operations are defined through software”.

Although the definitions may vary, the one common ground is that SDV inevitably involves the decoupling of hardware and software (HW/SW). Ultimately, the concept of SDV has a range of universal characteristics, such as:

• Software-focused
• Standardized interfaces
• Hardware abstraction
• Dependencies management
• Remote updates
• Cybersecurity
• Portability
• Customization

Prior to learning how to enable the decoupling of HW/SW and exploring the related challenges, we need to understand why decoupling is needed in the first place. The reasons for it may be subdivided into three categories:

Hardware/Software Decoupling & AUTOSAR

In the early 2000s, it was clear that upgrading or changing hardware platforms becomes challenging due to the dependencies, so vendors would often implement their own hardware abstraction layers (HALs) as foundational layers for the drivers. Having a set of broadly used microcontroller units and microprocessors, a group of automotive manufacturers and suppliers along with electronics and semiconductor producers founded the Automotive Open System Architecture (AUTOSAR) in 2003. AUTOSAR’s primary objective is to develop a standardized software architecture for automotive electronic control units (ECUs) and enable open E/E systems that will foster intelligent mobility. The organization provides specifications for basic software modules, standardized interfaces, and a common development methodology that can be used in vehicles from different OEMs with diverse electronic components.

Overview of AUTOSAR Architecture

AUTOSAR was the first to provide a standardized solution for decoupling hardware and software by establishing the AUTOSAR classic platform, which differentiates three core software layers that run on a microcontroller application, runtime environment, and basic software (BSW). In its turn, BSW is broken down into three major layers – Service layer, ECU abstraction, and Microcontroller abstraction. In addition, there is a Complex Drivers layer that provides faster access to the capabilities of the microcontroller.

Although AUTOSAR classic solves the challenges of decoupling hardware and software to some extent, these modules still cannot be used as pluggable pieces of software.

Layers of AUTOSAR Architecture

The AUTOSAR classic platform is essentially a framework designed to control the mechatronic parts of the vehicle. Conversely, infotainment systems or other high-level features often operate via more powerful ECUs or HPCs with complex operating systems that require other solutions to decouple the hardware and software.

More powerful HW solutions support virtualization technology. In such a case, multiple operating systems are deployed on one board, typically one OS for hardware abstraction, communication with the vehicle network and optionally safety-related tasks (QNX, Linux), while the second one is dedicated for UI/UX-related tasks (Android, AGL). All of them have a set of applications, which can be upgraded via OTA updates.

In a basic virtualization scenario, physical devices have to be shared between operating systems running on VMs. This can be done with a “passthrough” solution, which grants exclusive access and full control to hardware only to one VM. Another solution is the virtual device concept, which allows accessing the same device from different VMs via sharing mechanisms. A proprietary solution for sharing and inter-partition communication could be solved by hardware providers, but it makes the development of software on VMs more complex and costly. This issue can be addressed with the VirtIO (Virtual Input & Output) standard, which provides a standardized interface for virtual devices and allows the guest operating system to control them. The only restriction is that the hypervisor has to support the standard.

Containerization vs. Virtualization

However, if we have performed the HW/SW decoupling this way, there is still one more dependency – the operating system and its runtime environment.

As changes to the requirements can occur regularly, replacing the hypervisor-managed partition (a logical unit of isolation, supported by the hypervisor, in which operating systems execute) via OTA updates is a rather resource-intensive task, so the majority of updates would need a simpler solution. Updating components in shared resources, such as libraries, can lead to complicated dependencies, which are hard to test and maintain. To address this challenge, we can introduce containers – lightweight software packages. Containers can be used to bring a layer of isolation while keeping the service and its dependencies in a package that can be easily managed, monitored, and updated.

Navigating SDV Challenges with a Service-Oriented Architecture

Containerization and virtualization can help us manage dependencies on hardware and runtime environments. Nevertheless, the automotive architecture has to be loosely coupled to support plug-and-play software, which can be seamlessly installed and modified without changing the vehicle’s hardware. This can be achieved by utilizing the service-oriented architecture (SOA).

SOA is a development approach that uses individual software components called services, which can perform specific tasks, and communicate with one another across different platforms or programming languages via common interfaces and communication standards. The crux of SOA is in software reusability and interoperability – by breaking down the software into small, better manageable building blocks, developers can rapidly assemble an application. By design, SOA has two major roles:

• Service provider – creates and provides the requested services
• Service consumer – a system, or an application that requests the services.

Service-Oriented Architecture Basics

Core Principles of Service-Oriented Architectures:

• Standardized service contract – all services adhere to a standardized communications agreement, which is outlined in service description documentation.
• Loose coupling – all services are self-contained, with minimal dependency on other services. If a service is modified, this won’t impact the application or other services.
• Abstraction – the service’s logic is hidden from consumers. All the information on how to use the service is provided in contracts and description documents.
• Interoperability – services can be executed regardless of the used platform or programming languages.
• Reusability – being designed as standalone components, services can be reused to reduce the development time.
• Autonomy – all services are independent and have full control over the logic they encapsulate.
• Discoverability – services have supplemental data by which they can be easily discovered.
• Granularity – SOA services need to have a specified scope and size and must provide relevant functionality to the consumer.
• Composability – services can be used as building blocks to create other, more complex services.

Benefits of Using a Service-Oriented Architecture:

• Faster time-to-market – by reusing the same services, engineers can rapidly develop and rollout software solutions and platforms.
• Facilitated maintenance – SOA services can be upgraded and modified without affecting the business processes.
• Adaptability – older services can be seamlessly migrated to new environments, which allows for modernizing apps in a cost-efficient manner.
• Reliability – SOA is more reliable than monolithic architectures, as it does not have a single point of failure that can disrupt an entire system, and it’s easier to fix smaller software components within a single service
• Scalability – in cases of increased demand, new instances can be started to improve the service performance.

Final Remarks on Software Reusability

SOA can help us build software components that can be applied in SDV vehicles, but there’s more that can be done. The key challenge is that even if we have a common communication layer and a feature isolated with SOA services, automotive applications still need to be developed with regard to a specific model or platform architecture. Automotive software ecosystems cannot interact with each other without complex translation components, which limits the portability and reusability of software.

This challenge can be navigated with standardized vehicle data models and the Automotive API – an interface that enables standardized, data-centric communication for vehicles with both onboard components and external applications from other organizations.

In our next article, we’ll delve into the Automotive API concept, including its use cases across in-vehicle experience, maintenance, fleet management, insurance, and shared mobility, as well as the tangible business benefits it has to offer.

Our experts are ready to help you navigate hardware and software decoupling challenges of any complexity. Contact us to accelerate your journey to SDV!