La industria automotriz está pasando de una arquitectura de muchas unidades de procesamiento descentralizadas a una que combina varias funciones en pocas unidades de procesamiento centralizadas que permiten nuevas funciones, como las actualizaciones inalámbricas.
El SDV de AAOS utiliza el sistema y la infraestructura de Android existentes para ofrecer una solución. Además, los OEM buscan soluciones que también se puedan ejecutar en la nube, ya que esto facilita el desarrollo temprano y habilita nuevas posibilidades de prueba.
Diseño
Figura 1: Arquitectura principal de SDV.
AAOS para SDV Core (SDV Core) es un sistema operativo basado en Android. Debido a su naturaleza incorporada, no implementa la pila de JVM de Android, sino que toda la funcionalidad del sistema se desarrolla de forma nativa.
SDV Core se desarrolla principalmente para un entorno virtualizado, y algunas decisiones de diseño asumen esta integración. Sin embargo, es posible ejecutar SDV Core de forma nativa, pero esto requiere una mayor cantidad de trabajo de integración en comparación con otras versiones de Android.
SDV Core está diseñado para un sistema distribuido local. Por ejemplo, supone que varias instancias de SDV Core (o derivados) se ejecutan una junto a la otra en el mismo chip o en varios sistemas, y que pueden comunicarse a través de una conexión de red. Por lo tanto, un aspecto central de la arquitectura del sistema es la implementación de la funcionalidad como servicios que se pueden alojar en cualquiera de las instancias.
SDV Core es el conjunto mínimo de funciones para desarrollar funciones en el vehículo. Un servicio típico recibiría algunas señales, las procesaría y compartiría el resultado con otros servicios. Esta limitación de alcance es intencional, ya que permite que SDV Core ejecute una gran variedad de SoC (sistema en chip) que podrían no contener motores avanzados y ahorrar costos.
Diseño detallado
Figura 2: Arquitectura detallada de SDV Core.
SDV Core deriva de Android y, por lo tanto, su arquitectura intenta alinearse con Android lo mejor posible. En esencia, esto significa que SDV Core también usa GKI, controladores, HAL y bibliotecas principales de Android, y agrega componentes necesarios para la arquitectura de servicios.
En las siguientes secciones, se describirán los componentes del sistema en detalle.
Entorno host y virtualización
SDV Core se desarrolla con la suposición de que se ejecutará en un entorno virtual y, por lo tanto, hacemos algunas suposiciones sobre el entorno del host:
El entorno de host ejecuta un hipervisor que admite dispositivos Virtio. Además, el hipervisor debe implementar Ethernet o vsock, estados de energía y dispositivos de almacenamiento en bloques. Además, el hipervisor debe admitir la ejecución de Android o Linux.
En cuanto al hardware, SDV Core asume una CPU y una MMU que tienen compatibilidad con la virtualización de hardware y que el sistema está conectado a través de Ethernet. No es necesario que el sistema tenga una GPU, una IPU, una CSI, motores multimedia, una pantalla ni otros buses de comunicación automotriz (p.ej., CAN, LIN).
Android Base
SDV Core se basa en Android, pero reduce el sistema a la funcionalidad esencial
y agrega el entorno de ejecución de SDV. Esto significa que SDV también usa GKI, servicios nativos del sistema (por ejemplo, adbd y logd) y funcionalidad del sistema, pero no incluye JVM ni servicios basados en JVM o aplicaciones del sistema, ni funciones implementadas para JVM.
Esto también significa que el SDV adaptará la estrategia de actualización y el diseño de particiones de Android. Tiene requisitos de seguridad similares, pero no tiene una GUI.
GKI, controladores y HAL
SDV Core usa el kernel de GKI de Android con el kernel 6.1 de Android. La ventaja de usar la GKI es que los cambios que se realizan upstream finalmente se aplican en Android. Además, Android usa un kernel en toda la flota. Por ejemplo, los parches se aplican de forma centralizada en lugar de aplicarse a varios kernels de proveedores.
Esto también permite que el SDV tenga una interfaz de kernel estable. Por ejemplo, puedes compilar controladores como módulos que funcionen con la GKI, incluso cuando se implemente un kernel nuevo con correcciones de seguridad.
El kernel de GKI tiene un cronograma fijo, y los cambios del proveedor que deberían formar parte del próximo kernel de GKI deben enviarse al kernel de Linux hasta fin de año.
Con la GKI, los controladores de dispositivos y los módulos que no se requieren para el inicio se compilarán como módulos de kernel y se incluirán en un disco RAM que se carga durante el inicio anticipado. Las configuraciones de dispositivos muy tempranas que no pueden esperar a la interfaz del módulo de kernel (p. ej., la inicialización aleatoria) se deben realizar en el árbol de dispositivos. No es necesario que los módulos de kernel se envíen a la rama principal, pero deben compilarse con las interfaces de GKI.
Debido a que SDV Core supone que se compila sobre un hipervisor compatible con Virtio, los controladores se entregan como módulos de kernel de Virtio si se admite la función, o como otro estándar abierto (por ejemplo, Open Profile para DICE y el controlador de kernel open-dice para la confianza).
Esta combinación de Virtio (y estándares abiertos) y un hipervisor genera una abstracción del hardware. Por lo tanto, la necesidad de HAL en SDV es mínima, pero algunas siguen siendo necesarias debido a la falta de compatibilidad con Virtio. Por ejemplo, la HAL de KeyMint para la criptografía respaldada por hardware y la HAL de IRemotelyPrivisionedComponent estrechamente relacionada para la certificación entre las VMs de SDV.
Pila de redes y comunicación
Figura 3: Pila de comunicación y redes principales de SDV
En el caso de las redes, SDV Core supone que vsock o Ethernet están disponibles para comunicarse entre VMs. La comunicación interna de las VMs también puede usar mecanismos de IPC, como Binder.
El SDV admite la comunicación en serie solo con fines de depuración.
Figura 4: Se agregó compatibilidad con el puerto en serie de SDV Core para la depuración.
Dentro de un solo invitado, SDV proporciona varias opciones que dependen del modelo de comunicación y los requisitos de rendimiento.
Vsock
Vsock es el canal preferido para la comunicación local entre varias VMs o el host y la VM. Las VMs deben usar la comunicación directa de vsock entre sí para permitir que la implementación optimice la cantidad de copias.
Memoria compartida
La memoria compartida solo se usa para comunicarse con una VM para IPC (comunicación entre procesos), pero no se ofrece como un canal regular para comunicarse entre varias VMs. El host puede usar la memoria compartida para compartir información con el invitado, pero no está planificado para el tráfico de red de alta frecuencia.
Ethernet
Ethernet se usa para la comunicación entre varios SoC, es decir, para la comunicación dentro del vehículo. Pueden ser sistemas virtualizados, pero también sistemas nativos o ECU heredadas.
La red del vehículo es lo suficientemente pequeña como para que el espacio de direcciones IPv4 sea suficiente para identificar todos los sistemas disponibles. Sin embargo, para garantizar que el sistema sea compatible con posibles vínculos de subida y desarrollos futuros, se deben admitir IPv4 e IPv6.
VLAN
La VLAN es un mecanismo para crear arquitecturas de red virtuales que permiten aislar diferentes subredes y formar redes locales. Esto se puede usar para crear diferentes zonas de seguridad y se usa con ese propósito en los automóviles. Se requiere compatibilidad con VLAN.
Protocolos
TCP y UDP
Según el caso de uso, el sistema requiere un protocolo de comunicación confiable o uno no confiable, pero rápido. Por lo tanto, se admitirán TCP y UDP.
Túnel de datos
Data Tunnel es un mecanismo de comunicación desarrollado recientemente para SDV que ofrece un canal de comunicación rápido que sigue el modelo de pubsub, por ejemplo, una aplicación publica un tema, mientras que una o más aplicaciones pueden escucharlo. De forma interna, utiliza memoria compartida y FMQ (colas de mensajes rápidos) dentro de la VM, o bien vsock o Ethernet para comunicarse entre VMs.
RPC de SDV
SDV RPC implementa llamadas de procedimiento remoto para SDV que aprovechan Binder. Usa una API predefinida para llamar a un procedimiento remoto. Al igual que Data Tunnel, usa memoria compartida para la comunicación dentro de la VM, o bien vsock o Ethernet para la comunicación entre VMs.
Frameworks
SOMEIP
SOMEIP se usa para comunicarse con sistemas que no son de SDV. Se basa en TCP y UDP, y no requiere hardware ni controladores especiales. Google implementará una referencia.
Agente de descubrimiento de servicios (agente de SD)
Proporciona descubrimiento de servicios, autenticación y autorización para SDV. Para la comunicación, puede usar cualquiera de los métodos mencionados anteriormente. Para la autenticación y la autorización, el agente de SD necesitará acceso al hardware de seguridad y una cadena de confianza que funcione.
Middleware
El SDV desarrolla un framework para simplificar el uso de todos esos protocolos diferentes, llamado middleware. También implementa una fuente de información para todos los indicadores del vehículo con un nuevo lenguaje VSIDL.
Zona neutral
Para aislar partes del sistema y evitar ataques desde una parte menos confiable del sistema (por ejemplo, IVI con apps instaladas personalizadas), la red puede introducir diferentes zonas, incluidas las zonas desmilitarizadas. En la práctica, esto significa que las subredes están separadas física o lógicamente, y solo el tráfico de la lista de entidades permitidas puede pasar esos límites.
Administrador de conectividad
En Android, es una práctica común limitar la cantidad de aplicaciones y servicios que pueden abrir conexiones de socket por sí mismos. En su lugar, una instancia central es responsable de abrir y administrar las conexiones. Dado que Android implementa esta funcionalidad en un servicio de Java, SDV compilará su propio administrador de conectividad.
Capacidad de actualización
Una de las funciones clave de los SDV es la capacidad de actualización. Se pueden instalar funciones nuevas durante la vida útil del SDV a través de actualizaciones del sistema Android y paquetes APEX.
Actualizaciones del sistema de Android
Android ya proporciona un mecanismo para instalar actualizaciones. Usa actualizaciones de A/B y A/B virtuales en versiones recientes, y SDV Core aprovechará este mecanismo. Las actualizaciones A/B crean cada partición dos veces, lo que ofrece dos ventajas: el sistema se puede actualizar en segundo plano y, si la actualización falla, el sistema puede revertirse a la última versión que se sabe que funciona.
Paquetes de APEX
Además de dividir el sistema en varias particiones y hacer que se puedan actualizar, Android también proporciona paquetes APEX, un mecanismo para colocar aplicaciones y bibliotecas en paquetes pequeños que se pueden instalar y actualizar de forma independiente de las actualizaciones del sistema.
SDV Core usará contenedores de APEX para instalar servicios de forma dinámica en una instancia de SDV, pero también para administrar la implementación de varios servicios en un solo proceso: solo los servicios que se agrupan en el mismo APEX y usan el mismo certificado se pueden implementar en el mismo objeto binario para reducir los riesgos de seguridad.
El mecanismo de Android para instalar paquetes APEX aprovecha un código Java para la administración de APKs con el objetivo de verificar los paquetes. SDV Core deberá implementar una alternativa nativa para permitir la instalación dinámica de paquetes APEX.
Administración de actualizaciones
Las instancias de SDV no son unidades completamente independientes en el vehículo y necesitan coordinación con otras instancias de SDV y servicios del vehículo. Por ejemplo, para instalar dependencias de servicio o garantizar que las actualizaciones solo se instalen en un estado seguro del sistema.
El SDV considera usar particiones en varias VMs. Esto requiere coordinación entre esas VMs, ya que tienen una dependencia de datos entre sí: debe haber una VM principal para actualizar esas particiones y un mecanismo para notificar a las otras VMs sobre la partición actualizada y la sincronización para actualizar todas las VMs al mismo tiempo para garantizar que no se rompa el estado de funcionamiento conocido anterior.
Comenzar
Nuestra guía de introducción proporciona detalles sobre el código fuente, la compilación y el inicio con Cuttlefish.