Automotive

Created by Mike Holmes
Last updated: Nov 02, 2021

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.