Cette page définit les termes clés utilisés dans la documentation Android Automotive OS (AAOS) Software Defined Vehicle (SDV) et associe les concepts standards de l'industrie automobile à leurs concepts AAOS SDV correspondants.
Mappez les concepts de l'industrie automobile à AAOS SDV
Le tableau suivant met en correspondance les architectures, protocoles et spécifications standards de l'industrie automobile avec les concepts SDV AAOS les plus proches :
| Norme ou concept du secteur | Concept AAOS SDV correspondant | Rôle et documentation |
|---|---|---|
| Composant logiciel (SWC) Automotive Open System Architecture (AUTOSAR) ou application adaptative | Pack de services | Module de domaine déployable indépendamment (.apex) encapsulant la logique métier et les points de terminaison de communication associés (serveurs, clients, éditeurs et abonnés RPC). Consultez la section Architecture logique. |
Définition de l'interface AUTOSAR Adaptive ara::com |
VSIDL (.vsidl) et tampons de protocole (.proto) |
Schémas de service et de messages déclaratifs compilés par vsidlc dans des liaisons de bibliothèque cliente Rust. Consultez la présentation de VSIDL et du middleware. |
| Scalable service-Oriented MiddlewarE over IP (SOME/IP) et SOME/IP Service Discovery (SD) | Transport SOME/IP et ISomeIpStack |
Transport d'appel de procédure à distance (RPC) et de publication/abonnement inter-ECU pris en charge par le biais de piles partenaires personnalisées (ISomeIpStack AIDL stable) ou de l'alliance COVESA (Connected Vehicle Systems Alliance) vsomeip. Consultez la présentation de l'intégration SOME/IP. |
| COVESA Vehicle Signal Specification (VSS) | Propriétés VHAL et catalogues VSIDL | Signaux de véhicule standardisés exposés sur le système d'infoloisirs embarqué (IVI) via la couche d'abstraction matérielle du véhicule (VHAL) et pontés vers les services SDV. Consultez Utiliser la passerelle SDV sur IVI. |
| Unité de commande électronique (ECU) | Instances AAOS SDV s'exécutant dans des machines virtuelles (VM) sur un hyperviseur | VM invitées isolées exécutant le profil AAOS SDV Core sans interface graphique, communiquant via des sockets VirtIO (vsock) ou Ethernet. Consultez l'architecture du système AAOS SDV. |
| Gestionnaire de voyants et de cluster d'instruments ISO 26262 / ASIL | Afficher le rendu de sécurité et de haute disponibilité (HAR) | Pipeline de rendu isolé et architecture DriverUI pour les voyants et les vues de caméra arrière critiques pour la sécurité du combiné d'instruments. Consultez Sécurité de l'écran. |
Termes du glossaire
- Profil AAOS SDV Core
- Système léger headless, qui contient des capacités de connectivité et d'orchestration ainsi que des services automobiles de base.
- OS Android
- Système d'exploitation Android utilisé dans les appareils mobiles, tels que les téléphones mobiles et les tablettes.
- catalogue
- Répertoire contenant tous les fichiers protobuf et VSIDL qui définissent les interfaces de service d'un véhicule. Le compilateur VSIDL accepte un répertoire de catalogue en entrée et génère du code pour tous les fichiers qu'il contient.
- catalogue de dépendances
- : le catalogue de dépendances spécifie les emplacements des définitions externes définies dans les fichiers VSIDL ou protobuf. Aucun code n'est généré pour les dépendances. Le compilateur VSIDL prend le chemin d'accès au catalogue de dépendances en entrée.
- unité de commande électronique (ECU)
- Module contrôlant l'un des sous-systèmes du véhicule (par exemple, le moteur, la carrosserie ou la connectivité). Sa partie informatique peut être aussi simple qu'un petit microcontrôleur ou aussi avancée qu'un ordinateur complet sous Linux, parfois avec plusieurs SoC. Pour en savoir plus, consultez Electronic control unit (Unité de commande électronique).
- bibliothèque cliente de middleware
- Bibliothèque cliente (également appelée clientlib) qui fournit des API de haut niveau pour interagir avec la pile de communication SDV. Cette bibliothèque masque les détails de l'enregistrement et de la découverte des services, ce qui permet aux développeurs de se concentrer sur les thèmes et les chaînes. Les API clientlib sont conçues pour fonctionner avec les descripteurs de points de terminaison générés à partir du générateur de code VSIDL (
vsidlc), ce qui réduit considérablement les erreurs de configuration manuelle et accélère le développement. - Tampons de protocole (protobuf)
Les tampons de protocole sont un mécanisme extensible de description et de sérialisation des données structurées, indépendant de la langue et de la plate-forme.
Les fichiers Protobuf ont l'extension
.protoet définissent la structure des messages (données) échangés entre les services. Ces fichiers spécifient également les types de données, les champs et les relations dans les messages.- Agent SDV
Application privilégiée s'exécutant sur le système SDV et fournissant la fonctionnalité principale SDV. Les agents SDV se comportent comme des daemons Linux, qui sont des applications exécutées pendant toute la durée de vie du système d'exploitation et fournissant certaines fonctionnalités de bas niveau. Chaque composant principal SDV peut fournir aucun, un ou plusieurs agents.
- Instance SDV (VM SDV)
Instance unique du profil AAOS SDV Core, s'exécutant dans une machine virtuelle (VM) sur un système sur puce (SoC) ou dans un environnement virtuel. Le plus souvent, plusieurs instances de SDV fonctionnent dans un seul véhicule automobile, qui forment ensemble un déploiement AAOS SDV complet.
- Package SDV
La plus petite unité du logiciel SDV pouvant être mise à jour. Un package SDV peut comporter plusieurs bundles de services.
- Plate-forme SDV
Plate-forme SDV comprenant le profil SDV Core en tant que plate-forme qui permet aux développeurs de créer des services et sur laquelle ils peuvent les exécuter.
- Le développeur de plate-forme SDV :
Ingénieur qui intègre, configure et gère le profil de base AAOS SDV sous-jacent, les VM et l'infrastructure système. Il est l'équivalent d'un développeur de plate-forme Android sur les systèmes d'infoloisirs embarqués. Voici les principales responsabilités :
- Configurer les mécanismes d'isolation des processus et des VM, les stratégies de sécurité et la planification des ressources pour les services SDV.
- Intégrer la pile de transport (telle que SOME/IP ou VirtIO) et assurer l'adressabilité réseau entre les ECU et les VM.
- Gérer la façon dont les packs de services (packages
.apex) sont provisionnés, chargés et mis à jour par l'orchestrateur SDV.
- Le développeur de services SDV :
Ingénieur qui crée des fonctionnalités de véhicule spécifiques à un domaine sous forme de bundles de services modulaires s'exécutant sur la plate-forme SDV. Il est comparable à un développeur d'applications Android sur les systèmes IVI, mais il crée des services de véhicule headless plutôt que des applications d'interface utilisateur (UI). Voici quelques-unes de vos responsabilités :
- Définition des interfaces de service et des structures de données à l'aide de VSIDL (
.vsidl) et de tampons de protocole (.proto). - Implémenter la logique métier du domaine à l'aide des liaisons de la bibliothèque cliente Rust générée (serveurs, clients, éditeurs et abonnés RPC).
- Empaqueter, tester et déployer des bundles de services indépendamment de l'image de plate-forme sous-jacente.
- Définition des interfaces de service et des structures de données à l'aide de VSIDL (
- offre groupée de services
Module déployable de manière indépendante de logique métier associée qui encapsule une fonctionnalité de domaine spécifique et applique des limites d'autorisation strictes.
- découverte des services
Agent SDV permettant la découverte des services et des points de terminaison de communication.
- architecture orientée services (SOA)
Style de logiciel informatique dans lequel des services sont fournis aux autres composants par des composants d'application, par le biais d'un protocole de communication sur un réseau.
- unité de service
Entité de point de terminaison sous-jacente de la pile de communication SDV (telle qu'un serveur RPC ou un éditeur de sujet) déclarée dans un bundle de services. La bibliothèque cliente du middleware gère automatiquement l'enregistrement et la découverte des unités de service.
- sujet
Chemin de communication nommé pour les messages axés sur les données (publication/abonnement). Les thèmes sont identifiés par des chaînes et contiennent des messages d'un type spécifique. Les sujets permettent une communication de type "plusieurs à plusieurs", ce qui autorise plusieurs éditeurs et abonnés pour le même sujet.
- chaîne
Chemin de communication nommé pour les services RPC. Les canaux permettent de distinguer plusieurs instances du même type de service (par exemple,
main-control,high-priority).- véhicule défini par logiciel (SDV, software defined vehicle)
Terme externe faisant référence à la solution dans le code et la documentation. Pour référence, consultez Véhicules définis par logiciel : comment l'Open Source alimente l'innovation.
- système sur une puce (SoC)
Circuit intégré qui réunit tous les composants d'un ordinateur ou d'un autre système électronique dans une seule puce. Ces composants comprennent généralement un processeur (CPU), une mémoire, des ports d'entrée/sortie et un espace de stockage secondaire. Pour en savoir plus, consultez système sur une puce.
- unité de commande télématique (TCU)
ECU responsable des périphériques de communication externe, tels que GSM/LTE, Wi-Fi, GNSS ou Bluetooth. Pour en savoir plus, consultez Unité de commande télématique.
- Langage de définition d'interface de service de véhicule (VSIDL)
VSIDL est un langage spécifique à un domaine conçu pour définir les interfaces et les interactions entre les services au sein du système logiciel d'un véhicule.
Les fichiers VSIDL décrivent les packs de services, leurs fonctionnalités et les messages qu'ils échangent. Ils définissent la structure de l'architecture logicielle du véhicule.
Les fichiers VSIDL ont l'extension
.vsidl.