The car industry is moving from an architecture of many decentralized compute units to an architecture that combines multiple functionalities into few, centralized compute units that enable new features like over the air updates.
AAOS SDV utilizes the existing Android system and infrastructure to offer a solution. In addition, OEMs are looking for solutions that can also run in the Cloud as this facilitates early development and enables new testing possibilities.
Design
Figure 1. SDV Core architecture.
AAOS for SDV Core (SDV Core) is an operating system that is based on Android. Because of its embedded nature, it does not implement Android's JVM stack, but instead, all system functionality is developed natively.
SDV Core is primarily developed for a virtualized environment and some design decisions assume this integration. Nevertheless, it is possible to run SDV Core natively, but this requires a larger amount of integration work compared to other Android releases.
SDV Core is designed for a local distributed system, for example it assumes that multiple instances of SDV Core (or derivatives) run next to each other either on the same chip, or across multiple systems, and they can communicate through a network connection. Therefore, a core aspect of the system architecture is the implementation of functionality as services that can be hosted on any of the instances.
SDV Core is the minimal set of functionality to develop in-car functionality. A typical service would receive a few signals, process them, and share the result with other services. This scope limitation is on purpose as it enables SDV Core to run a large variety of SoCs (System-on-a-chip) that may not contain advanced engines and save costs.
Detailed design
Figure 2. SDV Core detailed architecture.
SDV Core is derived from Android, and therefore its architecture is trying to align with Android as good as possible. Essentially, this means that SDV Core also uses GKI, drivers, HALs, and core libraries from Android, and adds components required for the service architecture.
The following sections will cover the system components in detail.
Host environment and Virtualization
SDV Core is developed with the assumption that it will run in a virtual environment, and therefore, we make some assumptions about the host host environment:
The host environment runs a hypervisor that supports Virtio devices. In addition, the hypervisor must implement Ethernet or vsock, power states, and block devices. Moreover, the hypervisor must support running Android/Linux.
Regarding the hardware, SDV Core assumes a CPU and an MMU that have hardware virtualization support and that the system is connected through Ethernet. The system is not required to have a GPU, IPU, CSI, media engines, display, or other automotive communication buses (e.g. CAN, LIN).
Android Base
SDV Core is based on Android, but reduces the system to essential system
functionality, and adds the SDV runtime environment. This means that SDV also
uses GKI, native system services (for example, adbd and logd) and system
functionality, but it does not include JVM, and JVM-based services or system
applications, nor features implemented for JVM.
This also means that SDV will adapt Android's update strategy and partition layout. It has similar security requirements, but it does not have a GUI.
GKI, Drivers, and HAL
SDV Core users Android's GKI kernel with Android 6.1 kernel. The advantage of using GKI is that changes landing upstream eventually land in Android. In addition, Android uses one kernel across the fleet. For example, patches are applied centrall instead of to multiple vendor kernels.
This also allows SDV to have a stable kernel interface. For example, you can compile drivers as modules that work with the GKI even when a new kernel with security fixes os deployed.
The GKI kernel has a fixed timeline, vendor changes that should become part of the next GKI kernel should be upstreamed to the Linux kernel until the end of the year.
With GKI, device drivers and nonboot-required modules will be compiled as kernel modules, and will be contained in a ramdisk that is loaded during early boot, very early device configurations that cannot wait for the kernel module interface (e.g. random initialization) must be done in the device tree. Kernel modules are not required to be upstreamed, but must be compiled against the GKI interfaces.
Because of SDV Core assuming that it is built on top of a Virtio-compatible hypervisor, drivers are delivered as Virtio kernel modules if the feature is supported, or as another open standard (for example, Open Profile for DICE and the open-dice kernel driver for trust).
This combination of Virtio (and open standards) and a hypervisor leads to hardware abstraction. Therefore, the need for HALs in SDV is minimal, but some are still required because of missing Virtio support. For example, the KeyMint HAL for hardware-backed cryptography and the closely related IRemotelyPrivisionedComponent HAL for attestation among SDV VMs.
Networking and Communication Stack
Figure 3. SDV Core Networking and Communication Stack.
For networking, SDV Core assumes that either vsock or Ethernet are available to communicate across VMs, VM-internal communication can also use IPC mechanisms like binder.
SDV supports serial communication for debugging purposes only.
Figure 4. SDV Core serial support for debugging.
Within a single guest, SDV provides multiple options that depend on the communication model and performance requirements.
Vsock
Vsock is the preferred channel for local communication between multiple VMs or Host and VM. VMs should use direct vsock communication between each other to allow the implementation to optimize the number of copies.
Shared Memory
Shared memory is only used to communicate with a VM for IPC (inter process communication), but not offered as a regular channel to communicate between multiple VMs. The host may use shared memory to share information with the guest, but it is not planned for high frequency networking traffic.
Ethernet
Ethernet will be used for communication between multiple SoCs, i.e. for in-vehicle communication. This can either be virtualized systems, but also native systems or legacy ECUs.
The vehicle network is small enough that the IPv4 address space is sufficient to identify all available systems. Nevertheless, to ensure that the system is compatible with potential uplinks and future development, IPv4 and IPv6 must be supported.
VLAN
VLAN is a mechanism to create virtual network architectures that allow to isolate different subnetworks and to form local networks. This can be used to create different security zones, and is used for that purpose within cars. VLAN support is required.
Protocols
TCP and UDP
Depending on the use-case, the system requires either a reliable or an unreliable, but fast communication protocol. Therefore, TCP and UDP will be supported.
Data Tunnel
Data Tunnel is a newly developed communication mechanism for SDV that offers a fast communication channel following the pubsub model, for example one application publishes a topic while one or more applications can listen to it. Internally, it either utilizes shared memory and FMQ (fast message queues) within the VM, or either vsock or Ethernet to communicate across VMs.
(SDV) RPC
SDV RPC implements remote procedure calls for SDV leveraging binder. It uses a predefined API to call a remote procedure. Similar to Data Tunnel, it either uses shared memory for communication within the VM, or either vsock or Ethernet for cross-VM communication.
Frameworks
SOMEIP
SOMEIP is used to communicate with non-SDV systems. It is built on top of TCP and UDP and does not require special hardware or drivers. Google will implement a reference.
Service Discovery Agent (SD Agent)
It provides service discovery, authentication and authorization to SDV. For communication, it may use any of the previously mentioned methods. For authentication and authorization, the SD Agent will need access to security hardware, and a working chain of trust.
Middleware
SDV develops a framework to simplify using all those different protocols called Middleware. It also implements a source of truth for all vehicle signals with a new language VSIDL.
Neutral zone
To isolate parts of the system to prevent attacks from a less trusted part of the system (for example, IVI with custom installed apps), the network may introduce different zones, including demilitarized zone(s). In practice, this means that subnetworks are physically or logically separated, and only allowlisted traffic can pass those borders.
Connectivity Manager
In Android, it is a common practice to limit the number of applications and services that can open socket connections themselves. Instead, a central instance is responsible for opening and managing connections. Since Android implements this functionality in a Java service, SDV will build its own connectivity manager.
Updatability
A key SDV features is the updatability. New features can be installed throughout the SDV lifetime through Android system updates and APEX packages.
Android System Updates
Android already provides a mechanism to install updates. It uses A/B and virtual A/B updates in recent versions, and SDV Core will leverage this mechanism. A/B updates create each partition twice, which gives two advantages: the system can be updated in the background, and if the update fails, the system can rollback to the last known version to work.
APEX Packages
In addition to splitting the system into multiple partitions and making them updatable, Android also provides APEX packages, a mechanism to put applications and libraries into small packages that can be installed and updated independently of system updates.
SDV Core will use APEX containers to install services dynamically on an SDV instance, but also to manage deployment of multiple services into a single process: only services that are bundled in the same APEX and use the same certificate can be deployed in the same binary to reduce security risks.
Android's mechanism to install APEX packages leverages some Java code for APK management to verify packages. SDV Core will need to implement a native alternative to allow installing APEX packages dynamically.
Update Management
SDV instances aren't fully independent units in the car, and need orchestration with other SDV instances and car services. For example, to install service dependencies or to ensure updates are only installed in a safe system state.
SDV considers using partitions across multiple VMs. This requires coordination between those VMs, as they have a data dependency on each other: there must be a primary VM to update those partitions, and a mechanism to notify the other VMs about the updated partition and synchronization for updating all VMs at the same time to ensure the previous known working state is not broken.
Getting Started
Our Getting Started Guide provides details about source code, building and launching with Cuttlefish.