Background reading on the problem space: Linaro White paper on Software Defined Vehicles

Key Features for Automotive

A hypervisor is critical for Automotive
- Independently updateable, don't have to retest and recertify safety on none hypervisor kernel updates
- Many Type 1 hypervisors with no clear winner
- Therefore standardizing on virtio interfaces is paramount to enable multiple SOCs and multiple OSes on each hypervisor
Strong Isolation and documented Freedom from Interference (FFI)
- For Safety, Security, and Real-time isolation
- Proving Safety Isolation is much harder on Type 2 hypervisors
- Current type 2 hypervisors are less set up provide strong real-time guarantees (OS drivers in the path)
VirtIO based communication with CPUs not under a common hypervisor
- Cortex-R/M CPUs can offer stronger real-time guarantees
- Lockstep CPUs offer stronger Safety guarantees, these are commonly Cortex-R/M
- A virtio backend that needs to be highly available will be implemented on a Cortex-R/M
- A Cortex-R/M CPU may choose to have a frontend driver using a backend in a guest under the hypervisors
Safe Supervisor for the hypervisors and guests
- The safe supervisor needs to decide which guests need to be restarted or if the hypervisor itself should be restarted
- The supervisor will often need to be a higher safety standard than the hypervisor
- To restart a guest, the supervisor can talk directly to the hypervisor or via a guest at the same safety level as the hypervisor
- Ex: Safe Supervisor on lock step R/M core controls hypervisor via Virtio IPC like rpmsg
VirtIO interfaces for IVI
- The In-vehicle Infotainment function has a lot in common with mobile device
  - Rich UI, Multimedia playback, perhaps installable apps
- Key differences to mobile market
  - Multiscreen independent playback of media
  - AM/FM/Satelite Radio Tuner
- DRM protected playback is a key feature here as it is in mobile
VirtIO for cluster
- Guaranteed low latency rear-view camera display (<5 seconds from start)
- Guaranteed visible and audio alarms
- GPU acceleration for dial animation, eg: Speedometer
VirtIO interfaces for misc control
- SPI/I2C/GPIO controllers are very common on SOCs
- It is often difficult to ensure one I2C/SPI/GPIO bus is wholly owned by one guest
- Virtual interfaces allow the real control driver to be on a trusted domain and that domain can coordinate and police transactions
- Even when a given controller is owned wholly by one domain, a virtio interface gives SOC independence and avoids messiness in device assignment for platform devices.
- (Virtio may not be the best choice for critical real-time interactions)
VirtIO for Automotive control interfaces: CAN etc
- CAN seems like an obvious extension for Automotive to the plan for SPI/I2/GPIO
- However, CAN is so tied into the critical operations that some designs will not expose it to guests at all
- The real priority of CAN is TBD

AGL Relationship

Reference & Demo Platform is being leveraged to provide a demo in December 2020 to show the first steps in supporting AGL virtualization needs.

Reference Material

GSA Automotive

A Thought on Device Virtualization Architecture - Panasonic

AGL Member Webinar: Device Virtualization Architecture for Automotive