Architecture de référence de la messagerie, des données et de l’analytique automobiles

Cette architecture de référence est conçue pour prendre en charge les OEM automobiles et les fournisseurs de mobilité dans le développement d’applications avancées de véhicules connectés et de services numériques. Son objectif est de fournir une infrastructure de messagerie, de données et d’analyse fiable et efficace. L’architecture comprend des fonctionnalités de traitement des messages, de traitement des commandes et de stockage des états pour faciliter l’intégration de différents services via des API managées. Elle décrit également une solution de données et d’analytique qui garantit le stockage et l’accessibilité des données de manière évolutive et sécurisée pour l’ingénierie numérique et le partage des données avec l’écosystème de mobilité plus large.

Architecture

Le diagramme de l’architecture générale montre les principaux blocs logiques et les services d’une solution de messagerie, de données et d’analytique automobiles. Vous trouverez plus d’informations dans les sections suivantes.

• Le véhicule contient une collection d’appareils. Certains de ces appareils sont définis par logiciel et peuvent exécuter des charges de travail logicielles gérées à partir du cloud. Le véhicule collecte et traite une grande variété de données, qui vont des informations des capteurs provenant d’appareils électromécaniques comme le système de gestion de la batterie à des fichiers journaux de logiciels.
• Les services de messagerie du véhicule gèrent la communication vers et depuis le véhicule. Il est chargé de traiter les messages, d’exécuter des commandes en utilisant des workflows et d’assurer la médiation avec le back-end de gestion des véhicules, des utilisateurs et des appareils. Il assure également le suivi de l’inscription et de l’approvisionnement des véhicules, des appareils et des certificats.
• Les back-ends de gestion des véhicules et des appareils sont les systèmes OEM qui effectuent le suivi de la configuration des véhicules, de l’usine à la réparation et à la maintenance.
• L’opérateur dispose de services informatiques et opérationnels pour assurer la disponibilité et la performance des véhicules et du back-end.
• Les services de données et d’analytique fournissent le stockage des données, et permettent le traitement et l’analytique pour tous les utilisateurs des données. Il transforme les données en insights qui favorisent de meilleures décisions métier.
• Le fabricant de véhicules fournit des services numériques qui sont une valeur ajoutée pour le client final, et vont d’applications complémentaires à des applications de réparation et de maintenance.
• Plusieurs services numériques nécessitent une intégration métier à des systèmes back-ends comme la gestion des concessionnaires (DMS), la gestion de la relation client (CRM) ou les systèmes de planification des ressources d’entreprise (ERP).
• Le back-end de gestion du consentement fait partie de la gestion des clients et assure le suivi des autorisations des utilisateurs pour la collecte de données en fonction de la région géographique et de la législation du pays/de la région.
• Les données collectées auprès des véhicules sont une entrée dans le processus d’ingénierie numérique, avec l’objectif d’améliorer continuellement les produits en utilisant l’analytique et le machine learning.
• L’écosystème de mobilité intelligente peut s’abonner et consommer à la fois de la télémétrie en temps réel et des insights agrégés pour fournir davantage de produits et services.

Microsoft est membre du groupe de travail Eclipse Software Defined Vehicle, un forum de collaboration ouverte utilisant l’open source pour les plateformes logicielles des véhicules.

Dataflow

L’architecture utilise le modèle de messagerie éditeur/abonné pour découpler les véhicules des services.

Messages véhicules-à-cloud

Le flux de données véhicule-à-cloud est utilisé pour traiter les données de télémétrie provenant du véhicule. Les données de télémétrie peuvent être envoyées périodiquement (état du véhicule, collecte auprès des capteurs du véhicule) ou en fonction d’un événement (déclencheurs sur des conditions d’erreur, réaction à une action de l’utilisateur).

1. Le véhicule est configuré pour un client en fonction des options sélectionnées en utilisant les API de gestion. La configuration contient :
   1. Des informations de provisionnement pour les véhicules et les appareils.
   2. La configuration initiale de la collecte de données du véhicule en fonction des considérations liées au marché et à l’entreprise.
   3. Le stockage des paramètres de consentement initial de l’utilisateur en fonction des options du véhicule et de l’acceptation de l’utilisateur.
2. Le véhicule publie des données de télémétrie et des messages d’événement via un client MQTT (Message Queuing Telemetry Transport) avec des rubriques définies sur la fonctionnalité MQTT broker d’Azure Event Grid dans les services de messagerie du véhicule.
3. Event Grid route les messages vers différents abonnés en fonction des attributs de rubrique et de message.
   1. Les messages de faible priorité qui ne nécessitent pas de traitement immédiat (par exemple les messages d’analytique) sont routés directement vers le stockage en utilisant une instance Event Hubs pour la mise en mémoire tampon.
   2. Les messages à haute priorité qui nécessitent un traitement immédiat (par exemple les modifications d’état qui doivent être visualisées dans une application orientée utilisateur) sont routés vers une fonction Azure en utilisant un instance Event Hubs pour la mise en mémoire tampon.
4. Les messages de faible priorité sont stockés directement dans le lac de données en utilisant la capture d’événements. Ces messages peuvent utiliser le décodage et le traitement par lots pour des coûts optimaux.
5. Les messages à haute priorité sont traités avec une fonction Azure. La fonction lit les paramètres des véhicules, des appareils et de consentement des utilisateurs dans le Registre d’appareils et effectue les étapes suivantes :
   1. Elle vérifie que le véhicule et l’appareil sont inscrits et actifs.
   2. Elle vérifie que l’utilisateur a donné son consentement pour la rubrique du message.
   3. Elle décode et enrichit la charge utile.
   4. Elle ajoute des informations de routage supplémentaires.
6. Le hub d’événements Télémétrie en temps réel de la solution de données et d’analytique reçoit les messages décodés. Azure Data Explorer utilise l’ingestion en streaming pour traiter et stocker les messages à mesure qu’ils sont reçus.
7. La couche Services numériques reçoit les messages décodés. Service Bus fournit des notifications aux applications sur les modifications/événements importants sur l’état du véhicule. Azure Data Explorer fournit le dernier état connu du véhicule et l’historique à court terme.

Messages cloud-à-véhicule

Le flux de données cloud-à-véhicule est souvent utilisé pour exécuter des commandes à distance dans le véhicule depuis un service numérique. Ces commandes incluent des cas d’usage comme le verrouillage/déverrouillage des portes, le contrôle de la climatisation (définir la température préférée de l’habitacle) ou des modifications de configuration. La réussite de l’exécution dépend de l’état du véhicule et peut nécessiter un certain temps.

Selon les fonctionnalités du véhicule et le type d’action, il existe plusieurs approches possibles pour l’exécution des commandes. Nous prenons en charge deux variantes :

• Diriger les messages cloud-à-appareil (A) qui ne nécessitent pas de vérification du consentement de l’utilisateur et avec un temps de réponse prévisible. Ceci couvre les messages vers des véhicules individuels et vers plusieurs véhicules. Il s’agit par exemple de notifications météorologiques.
• Commandes de véhicule (B) qui utilisent l’état du véhicule pour déterminer la réussite et nécessitent le consentement de l’utilisateur. La solution de messagerie doit avoir une logique de workflow de commandes qui vérifie le consentement de l’utilisateur, assure le suivi de l’état d’exécution des commandes et avertit le service numérique quand c’est terminé.

Le flux de données suivant prend comme exemple les commandes émises depuis les services numériques d’une application complémentaire.

Les messages directs sont exécutés avec la quantité minimale de tronçons pour obtenir les meilleures performances possibles (A) :

1. L’application complémentaire est un service authentifié qui peut publier des messages sur Event Grid.
2. Event Grid vérifie l’autorisation du service de l’application complémentaire pour déterminer s’il peut envoyer des messages aux rubriques fournies.
3. L’application complémentaire s’abonne aux réponses provenant de la combinaison véhicule/commande spécifique.

Lorsque les commandes dépendantes de l’état du véhicule nécessitent le consentement de l’utilisateur (B) :

1. Le propriétaire/utilisateur du véhicule donne son consentement pour l’exécution de fonctions de commande et de contrôle pour un service numérique (dans cet exemple, une application complémentaire). Ceci se fait normalement lorsque l’utilisateur télécharge/active l’application et que l’OEM active son compte. Cela déclenche un changement de configuration sur le véhicule pour s’abonner à la rubrique des commandes associées dans le MQTT broker.
2. L’application complémentaire utilise l’API managée de commande et de contrôle pour demander l’exécution d’une commande à distance.
   1. L’exécution de la commande peut avoir plus de paramètres pour configurer des options comme le délai d’expiration, les options de stockage et de transfert, etc.
   2. La logique de la commande détermine comment traiter la commande en fonction de la rubrique et d’autres propriétés.
   3. La logique du workflow crée un état pour effectuer le suivi de l’état de l’exécution
3. La logique du workflow de la commande vérifie les informations de consentement de l’utilisateur pour déterminer si le message peut être exécuté.
4. La logique de workflow de la commande publie un message sur Event Grid avec la commande et les valeurs des paramètres.
5. Le module de messagerie dans le véhicule est abonné à la rubrique de la commande et reçoit la notification. Il route la commande vers la charge de travail appropriée.
6. Le module de messagerie supervise l’achèvement (ou l’erreur) de la charge de travail. Une charge de travail est responsable de l’exécution (physique) de la commande.
7. Le module de messagerie publie des rapports sur l’état des commandes dans Event Grid.
8. Le module de workflow est abonné aux mises à jour de l’état des commandes et met à jour l’état interne de l’exécution de la commande.
9. Une fois l’exécution de la commande terminée, l’application de service reçoit le résultat de l’exécution via l’API de commandes et de contrôles.

Provisionnement des véhicules et des appareils

Ce flux de données couvre le processus d’inscription et de provisionnement des véhicules et des appareils pour les services de messagerie des véhicules. Le processus est généralement lancé dans le cadre de la fabrication des véhicules.

1. Le système d’usine met en service l’appareil du véhicule dans l’état de construction souhaité. Ceci peut inclure l’installation et la configuration initiales du microprogramme et du logiciel. Dans le cadre de ce processus, le système d’usine obtient et écrit le certificat d’appareil, créé à partir du fournisseur d’infrastructure à clé publique.
2. Le système d’usine inscrit l’appareil le véhicule et l’appareil en utilisant l’API provisionnement de véhicule et d’appareil.
3. Le système d’usine déclenche le client de provisionnement d’appareil pour se connecter à l’inscription d’appareil et provisionner l’appareil. L’appareil récupère les informations de connexion auprès du répartiteur MQTT.
4. L’application d’inscription d’appareil crée l’identité de l’appareil avec le répartiteur MQTT.
5. Le système d’usine déclenche l’établissement par l’appareil d’une connexion au répartiteur MQTT pour la première fois.
   1. Le répartiteur MQTT authentifie l’appareil en utilisant le certificat racine d’autorité de certification et extrait les informations du client.
6. Le répartiteur MQTT gère l’autorisation pour les rubriques autorisées en utilisant le registre local.
7. En cas de remplacement d’une pièce, le système de concessionnaire OEM peut déclencher l’inscription d’un nouvel appareil.

Remarque

Les systèmes d’usine sont généralement locaux et n’ont pas de connexion directe au cloud.

Analytique des données

Ce flux de données couvre l’analytique pour les données des véhicules. Vous pouvez utiliser d’autres sources de données, comme les opérateurs d’usine ou d’atelier, pour enrichir et fournir du contexte aux données du véhicule.

1. La couche des services de messagerie du véhicule fournit des données de télémétrie, des événements, des commandes et des messages de configuration provenant de la communication bidirectionnelle avec le véhicule.
2. La couche Informatique et opérations fournit des informations sur les logiciels qui s’exécutent sur le véhicule et les services cloud associés.
3. Plusieurs pipelines permettent de traiter les données dans un état plus affiné
   • Traitement des données brutes aboutissant à des données sur le véhicule enrichies et dédupliquées.
   • Agrégation de données du véhicule, indicateurs de performances clés et insights.
   • Génération de données d’entraînement pour le machine learning.
4. Différentes applications consomment des données affinées et agrégées.
   • Visualisation en utilisant Power BI.
   • Flux de travail d’intégration métier en utilisant Logic Apps avec intégration dans le Dataverse.
5. Les données d’entraînement générées sont consommées par des outils comme ML Studio pour générer des modèles ML.

Extensibilité

Une solution connectée de véhicules et de données peut être mise à l’échelle pour des millions de véhicules et des milliers de services. Il est recommandé d’utiliser le modèle Empreintes de déploiement pour obtenir la scalabilité et l’élasticité.

Chaque unité d’échelle de messagerie de véhicule prend en charge une population de véhicules définie (par exemple les véhicules d’une région géographique spécifique, partitionnés par année du modèle). L’unité d’échelle des applications est utilisée pour mettre à l’échelle les services qui nécessitent l’envoi ou la réception de messages aux véhicules. Le service commun est accessible depuis n’importe quelle unité de mise à l’échelle, et fournit des services d’abonnement et de gestion des appareils pour les applications et les appareils.

1. L’unité d’échelle des applications abonne les applications aux messages appropriés. Le service commun gère l’abonnement aux composants de l’unité d’échelle de messagerie des véhicules.
2. Le véhicule utilise le service de gestion des appareils pour découvrir son affectation à une unité d’échelle de messagerie du véhicule.
3. Si nécessaire, le véhicule est provisionné en utilisant le workflow Provisionnement des véhicules et des appareils.
4. Le véhicule publie un message sur le répartiteur MQTT.
5. Event Grid route le message en utilisant les informations de l’abonnement.
   1. Les messages qui ne nécessitent pas de traitement et de vérification des revendications sont routés vers un hub d’entrée sur l’unité d’échelle d’application correspondante.
   2. Les messages qui nécessitent un traitement sont routés vers la logique de traitement D2C pour le décodage et l’autorisation (consentement de l’utilisateur).
6. Les applications consomment les événements provenant de l’instance de leurs hubs d’événements d’entrée d’application.
7. Les applications publient des messages pour le véhicule.
   1. Les messages qui ne nécessitent pas de traitement supplémentaire sont publiés sur le répartiteur MQTT.
   2. Les messages qui nécessitent davantage de traitement, de contrôle du workflow et d’autorisation sont routés vers la logique de traitement C2D appropriée via une instance Event Hubs.

Components

Cette architecture de référence mentionne les composants Azure suivants.

Connectivité

• Azure Event Grid permet l’intégration des appareils, AuthN/Z et la publication-abonnement via MQTT v5.
• Azure Functions traite les messages des véhicules. Il peut également être utilisé pour implémenter des API de gestion qui nécessitent une exécution de courte durée.
• Azure Kubernetes Service (AKS) est une alternative quand les fonctionnalités derrière les API managées se composent de charges de travail complexes déployées en tant qu’applications conteneurisées.
• Azure Cosmos DB stocke les paramètres des véhicules, des appareils et de consentement des utilisateurs.
• Gestion des API Azure fournit une passerelle d’API managée pour les services back-ends existants, comme la gestion du cycle de vie des véhicules (y compris l’OTA) et la gestion du consentement des utilisateurs.
• Azure Batch exécute efficacement des tâches lourdes nécessitant du calcul intensif, comme l’ingestion des traces de communication des véhicules.

Données et analyse

• Azure Event Hubs permet de traiter et d’ingérer des quantités massives de données de télémétrie.
• Azure Data Explorer permet d’explorer, d’organiser et d’analyser les données de télémétrie des véhicules basées sur des séries chronologiques.
• Stockage Blob Azure stocke des documents de grande taille (comme des vidéos et des traces CAN) et des données organisées sur les véhicules.
• Azure Databricks fournit un ensemble d’outils permettant de gérer des solutions de données de qualité entreprise à grande échelle. Nécessaire pour les opérations de longue durée sur de grandes quantités de données de véhicules.

Intégration du back-end

• Azure Logic Apps exécute des workflows automatisés pour l’intégration métier basés sur les données des véhicules.
• Azure App Service fournit des applications web orientées utilisateur et des back-ends mobiles, comme l’application complémentaire.
• Azure Cache pour Redis fournit une mise en cache en mémoire des données souvent utilisées par les applications orientées utilisateur.
• Azure Service Bus fournit un service de répartition qui découple la connectivité des véhicules des services numériques et de l’intégration métier.

Autres solutions

La sélection du type de calcul approprié pour implémenter le traitement des messages et les API managées dépend d’une multitude de facteurs. Sélectionnez le service approprié en utilisant le guide Choisir un service de calcul Azure.

Exemples :

• Azure Functions pour les processus pilotés par les événements et à courte durée, comme l’ingestion de télémétrie.
• Azure Batch pour les tâches d’informatique hautes performances, comme le décodage de gros fichiers de traces CAN / vidéo
• Azure Kubernetes Service pour une orchestration managée et complète de logiques complexes, comme la gestion des flux de travail de commandes et de contrôles.

Comme alternative au partage de données basé sur les événements, il est également possible d’utiliser Azure Data Share si l’objectif est d’effectuer la synchronisation par lots au niveau du lac de données.

Détails du scénario

Les OEM automobiles sont en train de subir une transformation importante, car ils passent de la production de produits fixes à une offre de véhicules connectés et définis par logiciel. Les véhicules offrent une gamme de fonctionnalités, comme les mises à jour automatiques, les diagnostics à distance et des expériences utilisateur personnalisées. Cette transition permet aux OEM d’améliorer continuellement leurs produits en fonction des données et des insights en temps réel, tout en développant leurs modèles d’activité pour inclure de nouveaux services et flux de revenus.

Cette architecture de référence permet aux constructeurs automobiles et aux fournisseurs de mobilité de :

• Utiliser les données de feedback dans le cadre du processus d’ingénierie numérique pour favoriser l’amélioration continue des produits, traiter de façon proactive les causes racines des problèmes et créer une nouvelle valeur ajoutée pour le client.
• Fournir de nouveaux produits et services numériques, et numériser les opérations avec l’intégration métier à des systèmes back-ends comme la planification des ressources d’entreprise (ERP) et la gestion de la relation client (CRM).
• Partager des données de façon sécurisée et répondre aux exigences propres aux pays/régions pour le consentement de l’utilisateur avec des écosystèmes de mobilité intelligente plus larges.
• L’intégration à des systèmes back-ends pour la gestion du cycle de vie des véhicules et la gestion des consentements simplifie et accélère le déploiement et la gestion des solutions de véhicules connectés en utilisant une chaîne d’outils DevOps de véhicules à définition logicielle.
• Stocker et fournir du calcul à grande échelle pour les véhicules et l’analytique.
• Gérer la connectivité des véhicules à des millions d’appareils de façon économique.

Cas d’usage potentiels

Les cas d’usage d’OEM automobile concernent l’amélioration des performances, de la sécurité et de l’expérience utilisateur des véhicules.

• Amélioration continue des produits : amélioration des performances des véhicules en analysant les données en temps réel et en appliquant des mises à jour à distance.
• Validation des flottes de test d’ingénierie : garantie de la sécurité et de la fiabilité des véhicules en collectant et en analysant les données des flottes de test.
• Application complémentaire et portail utilisateur : activation de l’accès et du contrôle à distance des véhicules via une application personnalisée et un portail web.
• Réparation et maintenance proactives : prédiction et planification de la maintenance des véhicules en fonction d’insights pilotés par les données.

Des cas d’usage d’un écosystème plus large étendent les applications des véhicules connectés afin d’améliorer le fonctionnement de la flotte, l’assurance, le marketing et l’assistance routière dans l’ensemble du paysage des transports.

• Fonctionnement d’une flotte commerciale connectée : optimisation de la gestion de la flotte via une supervision en temps réel et une prise de décision pilotée par les données.
• Assurance des véhicules numériques : personnalisation des primes d’assurance en fonction du comportement de conduite et fourniture de rapports d’accidents immédiats.
• Marketing basé sur la localisation : mise en œuvre de campagnes marketing ciblées aux conducteurs en fonction de leur emplacement et de leurs préférences.
• Assistance routière : fourniture d’un support et d’une assistance en temps réel aux conducteurs dans le besoin, en utilisant l’emplacement du véhicule et les données de diagnostic.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.

• Envisagez la mise à l’échelle horizontale pour augmenter la fiabilité.
• Utilisez des unités d’échelle pour isoler des régions géographiques avec des réglementations différentes.
• Mise à l’échelle automatique et instances réservées : gérez les ressources de calcul en effectuant une mise à l’échelle dynamique en fonction de la demande et en optimisant les coûts avec des instances préallouées.
• Géoredondance : répliquez les données dans plusieurs emplacements géographiques pour la tolérance de panne et la reprise d’activité.

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.

• Sécurisation de la connexion aux véhicules : consultez la section sur la gestion des certificats pour comprendre comment utiliser des certificats X.509 afin d’établir des communications sécurisées avec les véhicules.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

• Considérations relatives au coût par véhicule : les coûts de communication doivent dépendre du nombre de services numériques offerts. Calculez le retour sur investissement des services numériques par rapport aux coûts de fonctionnement.
• Établissez des pratiques pour l’analyse des coûts en fonction du trafic des messages. Le trafic des véhicules connectés a tendance à augmenter avec le temps à mesure que de plus en plus de services sont ajoutés.
• Prenez en compte les coûts du réseau et des mobiles
  • Utilisez l’alias de rubrique MQTT pour réduire le volume de trafic.
  • Utilisez une méthode efficace pour encoder et compresser les messages de charge utile.
• Gestion du trafic
  • Priorité des messages : les véhicules ont tendance à avoir des modèles d’utilisation répétés qui créent des pics de demande quotidiens/hebdomadaires. Utilisez les propriétés des messages pour retarder le traitement des messages non critiques ou analytiques afin de répartir la charge et d’optimiser l’utilisation des ressources.
  • Mise à l’échelle automatique en fonction de la demande.
• Réfléchissez à la durée pendant laquelle les données doivent être stockées chaud/tiède/froid.
• Envisagez d’utiliser des instances réservées pour optimiser les coûts.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et maintiennent son fonctionnement en production. Pour plus d’informations, consultez Vue d’ensemble du pilier Excellence opérationnelle.

• Envisagez de superviser les logiciels des véhicules (journaux/métriques/traces), les services de messagerie, les services d’analytique des données et les services back-ends associés dans le cadre des opérations informatiques unifiées.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.

• Envisagez d’utiliser le concept de mise à l’échelle pour les solutions dont la mise à l’échelle dépasse 50 000 appareils, en particulier si plusieurs régions géographiques sont nécessaires.
• Réfléchissez soigneusement à la meilleure façon d’ingérer des données (messagerie, streaming ou par lots).
• Réfléchissez à la meilleure façon d’analyser les données en fonction du cas d’usage.

Étapes suivantes

• Créez une solution AVOps (Autonomous Vehicle Operations) pour une présentation plus large de l’ingénierie numérique automobile pour la conduite autonome et assistée.

Ressources associées

Les articles suivants couvrent certains des concepts utilisés dans l’architecture :

• Le modèle de vérification des revendications est utilisé pour prendre en charge le traitement de messages de grande taille, comme les chargements de fichiers.
• Empreintes de déploiement couvre les concepts généraux nécessaires pour mettre à l’échelle la solution sur des millions de véhicules.
• Limitation décrit le concept lié à la gestion d’un nombre exceptionnel de messages provenant de véhicules.

Les articles suivants décrivent les interactions entre les composants de l’architecture :

• Configurer l’ingestion en streaming dans votre cluster Azure Data Explorer
• Capturer des données Event Hubs au format Parquet et les analyser avec Azure Synapse Analytics