L'industrie automobile passe d'une architecture composée de nombreuses unités de calcul décentralisées à une architecture qui combine plusieurs fonctionnalités dans un petit nombre d'unités de calcul centralisées, ce qui permet de nouvelles fonctionnalités telles que les mises à jour Over-The-Air.
Le SDV AAOS utilise le système et l'infrastructure Android existants pour proposer une solution. De plus, les OEM recherchent des solutions pouvant également s'exécuter dans le cloud, car cela facilite le développement précoce et offre de nouvelles possibilités de test.
Conception
Figure 1. Architecture SDV Core.
AAOS pour SDV Core (SDV Core) est un système d'exploitation basé sur Android. En raison de sa nature intégrée, il n'implémente pas la pile JVM d'Android. À la place, toutes les fonctionnalités du système sont développées de manière native.
SDV Core est principalement développé pour un environnement virtualisé, et certaines décisions de conception supposent cette intégration. Néanmoins, il est possible d'exécuter SDV Core de manière native, mais cela nécessite un travail d'intégration plus important que pour les autres versions d'Android.
SDV Core est conçu pour un système distribué local. Par exemple, il suppose que plusieurs instances de SDV Core (ou de ses dérivés) s'exécutent les unes à côté des autres sur la même puce ou sur plusieurs systèmes, et qu'elles peuvent communiquer via une connexion réseau. Par conséquent, un aspect essentiel de l'architecture du système est la mise en œuvre de fonctionnalités en tant que services pouvant être hébergés sur n'importe quelle instance.
SDV Core est l'ensemble minimal de fonctionnalités permettant de développer des fonctionnalités embarquées. Un service classique reçoit quelques signaux, les traite et partage le résultat avec d'autres services. Cette limitation du champ d'application est intentionnelle, car elle permet à SDV Core d'exécuter une grande variété de SoC (systèmes sur puce) qui ne contiennent pas nécessairement de moteurs avancés, et de réduire les coûts.
Conception détaillée
Figure 2. Architecture détaillée de SDV Core.
SDV Core est dérivé d'Android. Son architecture essaie donc de s'aligner au mieux sur Android. En gros, cela signifie que SDV Core utilise également GKI, les pilotes, les HAL et les bibliothèques de base d'Android, et ajoute les composants requis pour l'architecture de service.
Les sections suivantes décrivent en détail les composants du système.
Environnement de l'hôte et virtualisation
SDV Core est développé en partant du principe qu'il s'exécutera dans un environnement virtuel. Nous faisons donc certaines hypothèses sur l'environnement hôte :
L'environnement hôte exécute un hyperviseur compatible avec les appareils Virtio. De plus, l'hyperviseur doit implémenter Ethernet ou vsock, les états d'alimentation et les appareils de stockage en mode bloc. De plus, l'hyperviseur doit être compatible avec l'exécution d'Android/Linux.
En ce qui concerne le matériel, SDV Core suppose que le processeur et l'unité de gestion de la mémoire (MMU) sont compatibles avec la virtualisation matérielle et que le système est connecté via Ethernet. Le système n'a pas besoin d'un GPU, d'un IPU, d'un CSI, de moteurs multimédias, d'un écran ou d'autres bus de communication automobile (par exemple, CAN, LIN).
Android Base
SDV Core est basé sur Android, mais réduit le système aux fonctionnalités essentielles et ajoute l'environnement d'exécution SDV. Cela signifie que SDV utilise également GKI, les services système natifs (par exemple, adbd et logd) et les fonctionnalités système, mais n'inclut pas la JVM, les services ou applications système basés sur la JVM, ni les fonctionnalités implémentées pour la JVM.
Cela signifie également que le SDV adaptera la stratégie de mise à jour et la disposition des partitions d'Android. Il présente des exigences de sécurité similaires, mais ne dispose pas d'une IUG.
GKI, pilotes et HAL
SDV Core utilise le kernel GKI d'Android avec le kernel Android 6.1. L'avantage d'utiliser GKI est que les modifications apportées en amont finissent par être intégrées à Android. De plus, Android utilise un seul noyau pour l'ensemble du parc. Par exemple, les correctifs sont appliqués de manière centralisée plutôt qu'à plusieurs noyaux de fournisseurs.
Cela permet également au SDV d'avoir une interface de noyau stable. Par exemple, vous pouvez compiler des pilotes en tant que modules qui fonctionnent avec le GKI, même lorsqu'un nouveau noyau avec des correctifs de sécurité est déployé.
Le noyau GKI a un calendrier fixe. Les modifications apportées par les fournisseurs qui doivent être intégrées au prochain noyau GKI doivent être transmises au noyau Linux d'ici la fin de l'année.
Avec GKI, les pilotes d'appareil et les modules non requis pour le démarrage seront compilés en tant que modules de noyau et seront contenus dans un disque RAM chargé lors du démarrage initial. Les configurations d'appareil très précoces qui ne peuvent pas attendre l'interface du module de noyau (par exemple, l'initialisation aléatoire) doivent être effectuées dans l'arborescence de périphériques. Les modules de kernel ne doivent pas nécessairement être intégrés en amont, mais ils doivent être compilés avec les interfaces GKI.
Étant donné que SDV Core suppose qu'il est basé sur un hyperviseur compatible avec Virtio, les pilotes sont fournis en tant que modules de noyau Virtio si la fonctionnalité est compatible, ou en tant qu'autre norme ouverte (par exemple, Open Profile for DICE et le pilote de noyau open-dice pour la confiance).
Cette combinaison de Virtio (et de normes ouvertes) et d'un hyperviseur conduit à l'abstraction matérielle. Par conséquent, le besoin de HAL dans les SDV est minime, mais certains sont toujours requis en raison de l'absence de compatibilité avec Virtio. Par exemple, la HAL KeyMint pour la cryptographie intégrée au matériel et la HAL IRemotelyPrivisionedComponent, qui lui est étroitement liée, pour l'attestation entre les VM SDV.
Pile de mise en réseau et de communication
Figure 3. Pile de mise en réseau et de communication SDV Core.
Pour la mise en réseau, SDV Core suppose que vsock ou Ethernet sont disponibles pour communiquer entre les VM. La communication interne aux VM peut également utiliser des mécanismes IPC tels que binder.
SDV n'est compatible avec la communication série qu'à des fins de débogage.
Figure 4. Compatibilité de SDV Core avec le port série pour le débogage.
Dans un seul invité, SDV propose plusieurs options qui dépendent du modèle de communication et des exigences de performances.
Vsock
Vsock est le canal privilégié pour la communication locale entre plusieurs VM ou entre l'hôte et la VM. Les VM doivent utiliser une communication vsock directe entre elles pour permettre à l'implémentation d'optimiser le nombre de copies.
Mémoire partagée
La mémoire partagée n'est utilisée que pour communiquer avec une VM pour l'IPC (communication inter-processus), mais elle n'est pas proposée comme canal standard pour communiquer entre plusieurs VM. L'hôte peut utiliser la mémoire partagée pour partager des informations avec l'invité, mais cela n'est pas prévu pour le trafic réseau à haute fréquence.
Ethernet
Ethernet est utilisé pour la communication entre plusieurs SoC, c'est-à-dire pour la communication embarquée. Il peut s'agir de systèmes virtualisés, mais aussi de systèmes natifs ou d'ECU existants.
Le réseau du véhicule est suffisamment petit pour que l'espace d'adressage IPv4 suffise à identifier tous les systèmes disponibles. Néanmoins, pour garantir que le système est compatible avec les liaisons montantes potentielles et les développements futurs, IPv4 et IPv6 doivent être pris en charge.
VLAN
Le VLAN est un mécanisme permettant de créer des architectures de réseau virtuel qui permettent d'isoler différents sous-réseaux et de former des réseaux locaux. Cela peut être utilisé pour créer différentes zones de sécurité, et c'est d'ailleurs utilisé à cette fin dans les voitures. La compatibilité avec les VLAN est requise.
Protocoles
TCP et UDP
Selon le cas d'utilisation, le système nécessite un protocole de communication fiable ou non fiable, mais rapide. Par conséquent, les protocoles TCP et UDP seront compatibles.
Data Tunnel
Data Tunnel est un mécanisme de communication récemment développé pour les SDV. Il offre un canal de communication rapide suivant le modèle pub/sub. Par exemple, une application publie un sujet, tandis qu'une ou plusieurs applications peuvent l'écouter. En interne, il utilise la mémoire partagée et les FMQ (files d'attente de messages rapides) au sein de la VM, ou vsock ou Ethernet pour communiquer entre les VM.
RPC (SDV)
SDV RPC implémente des appels de procédure à distance pour SDV en exploitant Binder. Il utilise une API prédéfinie pour appeler une procédure distante. Comme Data Tunnel, il utilise la mémoire partagée pour la communication au sein de la VM, ou vsock ou Ethernet pour la communication entre VM.
Frameworks
SOMEIP
SOMEIP est utilisé pour communiquer avec des systèmes non SDV. Il est basé sur TCP et UDP, et ne nécessite pas de matériel ni de pilotes spéciaux. Google implémentera une référence.
Agent de découverte des services (agent SD)
Il fournit la découverte des services, l'authentification et l'autorisation au SDV. Pour la communication, il peut utiliser l'une des méthodes mentionnées précédemment. Pour l'authentification et l'autorisation, l'agent SD aura besoin d'accéder au matériel de sécurité et à une chaîne de confiance opérationnelle.
Middleware
SDV développe un framework appelé "middleware" pour simplifier l'utilisation de tous ces différents protocoles. Il implémente également une source de vérité pour tous les signaux du véhicule avec un nouveau langage, VSIDL.
Zone neutre
Pour isoler des parties du système afin d'empêcher les attaques provenant d'une partie moins fiable du système (par exemple, l'IVI avec des applications installées personnalisées), le réseau peut introduire différentes zones, y compris des zones démilitarisées. En pratique, cela signifie que les sous-réseaux sont séparés physiquement ou logiquement, et que seul le trafic figurant sur la liste d'autorisation peut franchir ces limites.
Gestionnaire de connectivité
Sur Android, il est courant de limiter le nombre d'applications et de services pouvant ouvrir eux-mêmes des connexions de socket. Au lieu de cela, une instance centrale est chargée d'ouvrir et de gérer les connexions. Comme Android implémente cette fonctionnalité dans un service Java, SDV va créer son propre gestionnaire de connectivité.
Facilité de mise à jour
La facilité de mise à jour est l'une des principales caractéristiques des SDV. De nouvelles fonctionnalités peuvent être installées tout au long de la durée de vie du SDV via les mises à jour du système Android et les packages APEX.
Mises à jour du système Android
Android fournit déjà un mécanisme pour installer les mises à jour. Il utilise des mises à jour A/B et A/B virtuelles dans les versions récentes, et SDV Core exploitera ce mécanisme. Les mises à jour A/B créent chaque partition deux fois, ce qui présente deux avantages : le système peut être mis à jour en arrière-plan et, en cas d'échec de la mise à jour, le système peut revenir à la dernière version connue pour fonctionner.
Packages APEX
En plus de diviser le système en plusieurs partitions et de les rendre modifiables, Android fournit également des packages APEX, un mécanisme permettant de placer les applications et les bibliothèques dans de petits packages qui peuvent être installés et mis à jour indépendamment des mises à jour du système.
SDV Core utilisera des conteneurs APEX pour installer des services de manière dynamique sur une instance SDV, mais aussi pour gérer le déploiement de plusieurs services dans un seul processus : seuls les services regroupés dans le même APEX et utilisant le même certificat peuvent être déployés dans le même binaire afin de réduire les risques de sécurité.
Le mécanisme d'Android pour installer des packages APEX exploite du code Java pour la gestion des APK afin de valider les packages. SDV Core devra implémenter une alternative native pour permettre l'installation dynamique des packages APEX.
Gestion des mises à jour
Les instances SDV ne sont pas des unités entièrement indépendantes dans la voiture et doivent être orchestrées avec d'autres instances SDV et services de la voiture. Par exemple, pour installer des dépendances de service ou pour s'assurer que les mises à jour ne sont installées que dans un état système sécurisé.
SDV envisage d'utiliser des partitions sur plusieurs VM. Cela nécessite une coordination entre ces VM, car elles ont une dépendance aux données l'une envers l'autre : il doit y avoir une VM principale pour mettre à jour ces partitions, et un mécanisme pour notifier les autres VM de la partition mise à jour et de la synchronisation pour mettre à jour toutes les VM en même temps afin de s'assurer que l'état de fonctionnement connu précédent n'est pas rompu.
Premiers pas
Notre guide de démarrage fournit des détails sur le code source, la compilation et le lancement avec Cuttlefish.