Attention
This website is best viewed in portrait mode.
Navigation
Navigation
Software-defined vehicles (SDVs) represent the transition from conventional mechanical-based systems to a software-driven approach.
In a conventional vehicle, the hardware and software are closely coupled, so the features and performance remain the same throughout the vehicle’s operational life. Unlike current vehicles, SDV decouples the hardware and software parts of the vehicle, allowing it to continuously add, update, enable and disable features and services through an over-the-air (OTA) concept. This enables vehicles upgrades throughout their lifetime. These features help to customise the vehicle settings basis the demands of the end-user, resulting in an enhanced personalised driving experience. Moreover, SDVs offer better computing capabilities for efficient data processing within the vehicle. It also provides diagnostic services that continuously monitor functionalities and detects errors early without the need to consult any service specialists.
For effective SDV implementation, it's crucial to utilize cloud-native technology. Achieving cloud-native software development involves ensuring that the development environment in the cloud aligns seamlessly with the automotive edge environment. Moving to a cloud-based system, where software can be developed in the cloud and then distributed to an SDV at the edge, is known as cloud-native automotive development. Developers could develop and test software applications from any location using cloud and then securely deliver them to the car. The concept of creating and executing applications in order to make use of the distributed computing capabilities provided by the cloud delivery model is referred to as cloud-native. Applications that are cloud-native are created to take advantage of the size, elasticity, resilience, and flexibility that the cloud offers. With thecloud-native technology, it is possible to create callable applications on public, private and hybrid clouds. OEM’s aspiration to develop new software features with adaptability, and to supply vehicle services that are upgradeable over the vehicle life cycle are also supported by the cloud-native SDV.
In the context of SDV, "environment parity" refers to the concept of ensuring that the applications and services should function in the same way in both development platform and the embedded system of the target vehicle. In terms of software development and testing, environment parity means that the software is developed and tested in an environment that closely replicates the actual properties of the physical hardware in which it will run ultimately. This allows the early detection of issues and helps to debug these problems before reaching the production stage. Environment parity reduces the hardware dependencies which in turn accelerates the development and testing stages of the vehicle software. This concept helps OEMs to completely focus on developing the software rather than complexities arising due to the physical hardware, their interactions, and their integration. This will improve the safety, reliability, and robustness of the software, leading to the creation of more efficient vehicles.
Path towards SDV architecture: SOAFEE
A collaborative initiative within the automotive and software technology industries, named Scalable Open Architecture for Embedded Edge (SOAFEE) has established a standard architecture for the development of SDV. The main goal of SOAFEE is to offer a service-oriented framework which facilitates the cloud-native development and the deployment of services and functions on the vehicle edge platform.
Figure. 1 shows the cloud-native technology based SDV architecture inspired by SOAFEE. It primarily consists of two sections, automotive edge, and cloud. Unlike conventional vehicles, which have hundreds of ECUs, SDV mainly consists of high-performance computers (HPC) and supporting zonal controllers. Most of the computation is done in HPC where a system on chip (SOC) is used to cross the limitations in terms of complexity and performance in vehicles. SoC is an integrated circuit (IC) with multiple processor cores that incorporates an entire computer system onto it. This forms the basic hardware layer in the SDV architecture at the vehicle edge.
On top of this hardware layer, a software called hypervisor is present which helps to create and run virtual machines (VM). Above the hypervisor, it runs multiple operating systems (OS) in parallel. Based on the requirements, it can be non-real-time OS or Real-Time Operating System (RTOS). RTOS is used for time-bound applications. The Hardware abstraction layer (HAL) is placed above the OS. HAL maps the hardware-dependent functions and services to hardware-independent services and functions at a higher level. Application software is the topmost layer in the automotive edge which runs above the HAL. HAL decouples the application software from the hardware of the vehicle. Application software is developed as a standalone entity based on specific functions and services.
There are 2 types of applications- monolithic and containerized applications. Containerized applications are software applications that are executed within isolated packages known as containers. These containers encompass all necessary dependencies like libraries, configuration files, etc. required to execute the application on diverse host OS, thereby consolidating them into a single executable entity. The all-in-one packaging ensures application portability, allowing it to behave consistently across various hosts, enabling developers to write code once and run it on almost any platform. Monolithic application is also a vehicle function implemented for a specific underlying hardware and it is not portable across multiple hardware.
To enable cloud native development and OTA updates in SDV, the application software is first developed, built, validated, and managed on the virtual execution environment in the cloud platform before deploying it in the automotive edge. This forms the second part of the given architecture. The virtual execution environment closely resembles the actual automotive edge ensuring the environment parity between the vehicle edge and the cloud platform.
For this, the OS, HAL, and the hardware are simulated to achieve the various environment parity levels (L0 to L4). To recreate the target vehicle environment, the cloud platform should be able to incorporate some technical capabilities, which include the integration of the software with the virtual vehicle model and the simulation of the interaction between them. By including features like flexibility, scalability, and data simulation, the virtual execution environment achieves a close parity to the actual operating condition of the target vehicle.
How to bring in environmental parity with Cloud technology?
The concept of environment parity and cloud native technology is demonstrated here using:
- Quick Emulator (QEMU): It is a machine emulator and ECU virtualization tool that allows to run the same embedded binary/hex file that runs inside the microcontroller in a PC-based environment.
- Docker: It is a containerization platform that allows to package the application into a container. This makes it easier to deploy and run the application in different environments.
- Amazon Web Services (AWS)
The architecture of the same is shown in figure 2.
To demonstrate environment parity, initially containerization concept is executed on the Linux system using QEMU. For this, an image of QEMU is created using a containerization tool like Docker. Using this image, the binary file of the application specific for ARM64 microcontroller architecture is executed on the Linux system. This showcases the environment parity concept as another microcontroller architecture specific application was able to run on a Linux system.
To demonstrate the cloud native technology, AWS cloud platform is used. In this cloud platform, an EC2 instance is created and launched. The executable file of the application is then transferred to the EC2 instance. Similarly, the QEMU image file is also downloaded into the EC2 instance. Later, using the QEMU, the binary application file is executed in cloud. This exhibits the cloud native technology as the binary application is now executed using virtualization tool on the cloud platform.
Book a Meeting
