La industria automotriz está pasando de una arquitectura de muchas unidades de procesamiento descentralizadas a una que combina varias funcionalidades en pocas unidades de procesamiento centralizadas que habilitan nuevas funciones, como las actualizaciones inalámbricas.
El SDV de AAOS utiliza el sistema y la infraestructura existentes de Android 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 inicial y permite 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 integrada, no implementa la pila de JVM de Android, sino que toda la funcionalidad del sistema se desarrolla de forma nativa.
SDV Core se desarrolló principalmente para un entorno virtualizado, y algunas decisiones de diseño suponen 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 sus 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 fundamental 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 la funcionalidad en el automóvil. Un servicio típico recibiría algunos indicadores, los procesaría y compartiría el resultado con otros servicios. Esta limitación del alcance es intencional, ya que permite que SDV Core ejecute una gran variedad de SoCs (sistemas en un chip) que pueden no contener motores avanzados y ahorrar costos.
Diseño detallado
Figura 2: Arquitectura detallada del núcleo del SDV
SDV Core se deriva de Android, por lo que su arquitectura intenta alinearse con Android lo mejor posible. Básicamente, esto significa que SDV Core también usa GKI, controladores, HAL y bibliotecas principales de Android, y agrega componentes necesarios para la arquitectura de servicio.
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 del host ejecuta un hipervisor que admite dispositivos Virtio. Además, el hipervisor debe implementar Ethernet o vsock, estados de energía y dispositivos de bloque. Además, el hipervisor debe admitir la ejecución de Android o Linux.
En cuanto al hardware, SDV Core supone que hay una CPU y una MMU que admiten la virtualización de hardware, y que el sistema está conectado a través de Ethernet. El sistema no necesita tener una GPU, una IPU, una CSI, motores multimedia, una pantalla ni otros buses de comunicación automotriz (p.ej., CAN o 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 o aplicaciones del sistema basados en JVM, ni funciones implementadas para JVM.
Esto también significa que 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
Los usuarios de SDV Core kernel de GKI de Android con el kernel 6.1 de Android. La ventaja de usar GKI es que los cambios que se realizan en el upstream finalmente se implementan en Android. Además, Android usa un solo kernel en toda la flota. Por ejemplo, los parches se aplican de forma centralizada en lugar de 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 funcionan con el GKI incluso cuando se implementa un nuevo kernel con correcciones de seguridad.
El kernel de GKI tiene un cronograma fijo, por lo que los cambios del proveedor que deberían formar parte del próximo kernel de GKI se deben incorporar al kernel de Linux hasta fin de año.
Con GKI, los controladores de dispositivos y los módulos que no se requieren para el inicio se compilarán como módulos del kernel y se incluirán en un ramdisk que se carga durante el inicio anticipado. Las configuraciones de dispositivos muy anticipadas que no pueden esperar la interfaz del módulo del kernel (p. ej., la inicialización aleatoria) se deben realizar en el árbol de dispositivos. No es necesario que los módulos del kernel se incorporen al upstream, pero deben compilarse en función de las interfaces de la 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 de open-dice para la confianza).
Esta combinación de Virtio (y estándares abiertos) y un hipervisor genera una abstracción de hardware. Por lo tanto, la necesidad de HAL en el SDV es mínima, pero algunas aún son necesarias debido a la falta de compatibilidad con Virtio. Por ejemplo, el HAL de KeyMint para la criptografía respaldada por hardware y el HAL de IRemotelyPrivisionedComponent estrechamente relacionado para la certificación entre las VMs de SDV.
Pila de redes y comunicación
Figura 3: Pila de comunicación y redes principales del SDV.
Para las redes, SDV Core supone que vsock o Ethernet están disponibles para comunicarse entre VMs. La comunicación interna de la VM también puede usar mecanismos de IPC, como binder.
El SDV admite la comunicación serial solo con fines de depuración.
Figura 4: Compatibilidad con la depuración de la serie SDV Core.
Dentro de un solo huésped, 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 entre 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 la 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á previsto para el tráfico de red de alta frecuencia.
Ethernet
Ethernet se usará para la comunicación entre varios SoCs, es decir, para la comunicación en el 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 ascendentes y desarrollos futuros, se deben admitir IPv4 e IPv6.
VLAN
Las VLAN son un mecanismo para crear arquitecturas de redes 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 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 recientemente desarrollado para el SDV que ofrece un canal de comunicación rápido según el modelo de publicación y suscripción. Por ejemplo, una aplicación publica un tema mientras que una o más aplicaciones pueden escucharlo. Internamente, 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
La RPC de SDV implementa llamadas de procedimiento remoto para SDV aprovechando el vinculador. Utiliza 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 Service Discovery (agente de SD)
Proporciona descubrimiento de servicios, autenticación y autorización al 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 en funcionamiento.
Middleware
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 incluido en la lista de entidades permitidas puede cruzar 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 cambio, 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 función clave de los SDV es su capacidad de actualización. Se pueden instalar funciones nuevas durante la vida útil del SDV a través de las actualizaciones del sistema Android y los paquetes APEX.
Actualizaciones del sistema de Android
Android ya proporciona un mecanismo para instalar actualizaciones. Utiliza actualizaciones 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 falla la actualización, el sistema puede revertir a la última versión conocida para que funcione.
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 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 incluyen 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 algo de código Java para la administración de APK y la verificación de 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 automóvil y necesitan coordinación con otras instancias de SDV y servicios del automóvil. Por ejemplo, para instalar dependencias de servicios o garantizar que las actualizaciones solo se instalen en un estado seguro del sistema.
El SDV considera el uso de 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 y garantizar que no se interrumpa 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 lanzamiento con Cuttlefish.