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 quelques unités de calcul centralisées permettant de nouvelles fonctionnalités, telles que les mises à jour à distance.
AAOS SDV utilise le système et l'infrastructure Android existants pour proposer une solution. De plus, les OEM recherchent des solutions qui peuvent é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 for 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, mais 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 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 dérivés) s'exécutent côte à côte 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 l'implémentation de fonctionnalités en tant que services pouvant être hébergés sur l'une des instances.
SDV Core est l'ensemble minimal de fonctionnalités à développer dans une voiture. Un service type reçoit quelques signaux, les traite et partage le résultat avec d'autres services. Cette limitation de la portée est intentionnelle, car elle permet à SDV Core d'exécuter une grande variété de SoC (System-on-a-chip) qui ne contiennent peut-être pas 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 tente donc de s'aligner au mieux sur Android. En substance, cela signifie que SDV Core utilise également GKI, des pilotes, des HAL et des 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 hôte et virtualisation
SDV Core est développé en supposant qu'il s'exécutera dans un environnement virtuel. Par conséquent, nous faisons certaines hypothèses concernant 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, des états d'alimentation et des appareils de 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 un processeur et une MMU compatibles avec la virtualisation matérielle, et que le système est connecté via Ethernet. Le système n'a pas besoin de GPU, d'IPU, de CSI, de moteurs multimédias, d'écran ni d'autres bus de communication automobile (par exemple, CAN, LIN).
Base Android
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, des services système natifs (par exemple, adbd et logd) et des fonctionnalités système, mais n'inclut pas JVM, ni les services ou applications système basés sur JVM, ni les fonctionnalités implémentées pour JVM.
Cela signifie également que 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'interface graphique.
GKI, pilotes et HAL
Les utilisateurs de SDV Core utilisent le noyau GKI d'Android avec le noyau Android 6.1. L'avantage d'utiliser GKI est que les modifications en amont finissent par arriver dans Android. De plus, Android utilise un seul noyau sur l'ensemble de la flotte. Par exemple, les correctifs sont appliqués de manière centralisée au lieu de l'être à plusieurs noyaux de fournisseurs.
Cela permet également à SDV d'avoir une interface de noyau stable. Par exemple, vous pouvez compiler des pilotes en tant que modules qui fonctionnent avec 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 du fournisseur qui doivent faire partie du prochain noyau GKI doivent être transmises au noyau Linux d'ici la fin de l'année.
Avec GKI, les pilotes de périphériques 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é au début du démarrage. Les configurations de périphériques 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 des périphériques. Les modules de noyau ne sont pas obligatoires en amont, mais doivent être compilés par rapport aux 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 SDV est minime, mais certains sont toujours nécessaires en raison de l'absence de compatibilité avec Virtio. Par exemple, le HAL KeyMint pour la cryptographie intégrée au matériel et le HAL IRemotelyPrivisionedComponent étroitement lié 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 de 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 des VM peut également utiliser des mécanismes IPC tels que Binder.
SDV n'est compatible avec la communication série que pour le débogage.
Figure 4. Compatibilité série de SDV Core 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 préféré pour la communication locale entre plusieurs VM ou entre l'hôte et la VM. Les VM doivent utiliser la 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 interprocessus), mais n'est pas proposée comme canal régulier pour communiquer entre plusieurs VM. L'hôte peut utiliser la mémoire partagée pour partager des informations avec l'invité, mais elle n'est pas prévue pour le trafic réseau à haute fréquence.
Ethernet
Ethernet sera utilisé pour la communication entre plusieurs SoC, c'est-à-dire pour la communication dans le véhicule. Il peut s'agir de systèmes virtualisés, mais aussi de systèmes natifs ou d'ECU hérités.
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 s'assurer que le système est compatible avec les liaisons montantes potentielles et le développement futur, IPv4 et IPv6 doivent être compatibles.
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. Il peut être utilisé pour créer différentes zones de sécurité et est 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, TCP et UDP seront compatibles.
Tunnel de données
Data Tunnel est un mécanisme de communication récemment développé pour SDV qui offre un canal de communication rapide suivant le modèle pubsub. Par exemple, une application publie un sujet tandis qu'une ou plusieurs applications peuvent l'écouter. En interne, il utilise soit la mémoire partagée et les FMQ (Fast Message Queues) dans la VM, soit vsock ou Ethernet pour communiquer entre les VM.
RPC (SDV)
SDV RPC implémente des appels de procédure à distance pour SDV à l'aide de Binder. Il utilise une API prédéfinie pour appeler une procédure à distance. Comme Data Tunnel, il utilise soit la mémoire partagée pour la communication dans la VM, soit vsock ou Ethernet pour la communication entre les 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 de services (agent SD)
Il fournit la découverte des services, l'authentification et l'autorisation à 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 devra accéder au matériel de sécurité et à une chaîne de confiance fonctionnelle.
Middleware
SDV développe un framework pour simplifier l'utilisation de tous ces protocoles différents appelés Middleware. 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, 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 autorisé peut franchir ces limites.
Gestionnaire de connectivité
Dans Android, il est courant de limiter le nombre d'applications et de services qui peuvent 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. Étant donné qu'Android implémente cette fonctionnalité dans un service Java, SDV créera son propre gestionnaire de connectivité.
Facilité de mise à jour
L'une des principales fonctionnalités de SDV est la facilité de mise à jour. De nouvelles fonctionnalités peuvent être installées tout au long du cycle de vie de 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 les 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 mises à jour, Android fournit également des packages APEX, un mécanisme permettant de placer des applications et des 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 les packages APEX exploite du code Java pour la gestion des APK afin de vérifier 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 nécessitent une orchestration avec d'autres instances SDV et services de 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 de système sécurisé.
SDV envisage d'utiliser des partitions sur plusieurs VM. Cela nécessite une coordination entre ces VM, car elles dépendent les unes des autres en termes de données : il doit y avoir une VM principale pour mettre à jour ces partitions, et un mécanisme pour informer 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 informations sur le code source, la compilation et le lancement avec Cuttlefish.