Modifier

Partager via


Messagerie automobile, données et analytique

Microsoft Fabric
Explorateur de données Azure
Azure Event Grid
Hubs d'événements Azure
Azure Functions

Cet exemple d’architecture explique comment les fabricants d’équipement d’origine automobile (OEM) et les fournisseurs de mobilité peuvent développer des applications de véhicules connectés et des services numériques avancés. Il fournit une infrastructure de messagerie, de données et d’analytique fiable. Cette infrastructure inclut le traitement des messages et des commandes, le stockage d’état et l’intégration d’API managée. L’architecture fournit également une solution de données de sécurité évolutive et améliorée pour l’ingénierie numérique, les opérations de flotte et le partage au sein de l’écosystème de mobilité plus large.

Architecture

Diagramme de l’architecture générale.

Télécharger un fichier PowerPoint qui contient ce diagramme d’architecture.

Le diagramme d’architecture de haut niveau précédent montre les principaux blocs logiques et services d’une solution de messagerie, de données et d’analytique automobile. Dans cet article, nous ne abordons pas les éléments de diagramme ombré. Mais la liste suivante décrit brièvement les autres éléments de diagramme. Vous trouverez plus d’informations dans les sections qui suivent.

  • Véhicule: chaque 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 un large éventail de données, telles que des informations sur les capteurs à partir d’appareils électromécaniques, d’interactions, de vidéos et de fichiers journaux logiciels.

  • appareils mobiles: les appareils mobiles fournissent des expériences numériques au conducteur ou à l’utilisateur et peuvent recevoir des messages et envoyer des messages aux véhicules à l’aide d’applications compagnons.

  • infrastructure Mobilité: infrastructure mobilité, telle que les bornes de recharge de batterie, reçoit des messages et envoie des messages aux véhicules.

  • Services de messagerie: les services de messagerie gèrent la communication vers et depuis le véhicule, l’infrastructure et les appareils mobiles. Ils traitent les messages, utilisent des flux de travail pour exécuter des commandes et implémenter le back-end de gestion. Ils effectuent également le suivi de l’inscription et de l’approvisionnement des certificats pour tous les participants.

  • back-end de gestion des véhicules et des appareils: les systèmes OEM gèrent le cycle de vie des véhicules et des appareils de l’usine au support après-vente.

  • services de données et d’analytique: les services d’analyse et de données fournissent des fonctionnalités de stockage, de traitement et d’analytique des données pour tous les utilisateurs. Ces services transforment les données en insights qui prennent de meilleures décisions métier.

  • services numériques: le fabricant de véhicules fournit des services numériques qui ajoutent de la valeur au client. Ces services incluent des applications complémentaires pour les tâches de réparation et de maintenance.

  • l’intégration d’entreprise: plusieurs services numériques nécessitent une intégration métier à des systèmes back-end tels que le système de gestion des concessionnaires (DMS), la gestion des relations client (CRM) ou les systèmes de planification des ressources d’entreprise (ERP).

  • gestion des consentements: le back-end de gestion du consentement fait partie de la gestion des clients et effectue le suivi de l’autorisation utilisateur pour la collecte de données conformément à la législation applicable.

  • d’ingénierie numérique : les systèmes d’ingénierie numérique utilisent des données de véhicules pour améliorer continuellement le matériel et les logiciels via l’analytique et le Machine Learning.

  • écosystème de mobilité intelligente: l’écosystème de mobilité intelligente se compose d’entreprises partenaires qui fournissent d’autres produits et services, tels que l’assurance connectée basée sur le consentement de l’utilisateur. Ils peuvent s’abonner à des événements et utiliser des événements et des insights agrégés.

  • informatique et les opérations: les opérateurs informatiques utilisent ces services pour maintenir la disponibilité et les performances des véhicules et des systèmes principaux.

  • centre d’opérations de sécurité des véhicules (VSOC): les opérateurs informatiques et les ingénieurs utilisent VSOC pour protéger les véhicules contre les menaces.

Microsoft est membre du groupe de travail Eclipse Software Defined Vehicle Working Group, qui sert de forum pour la collaboration ouverte sur les plateformes logicielles de véhicules qui utilisent open source.

Dataflow

L’architecture utilise le modèle de messagerie Publisher-Subscriber pour dissocier les véhicules des services. Il utilise Azure Event Grid pour activer la messagerie entre les véhicules et les services et pour acheminer les messages de transport de télémétrie de mise en file d’attente (MQTT) aux services Azure.

Messages véhicule-à-cloud

Le dataflow véhicule-à-cloud traite les données de télémétrie du véhicule. Les données de télémétrie, telles que l’état du véhicule et les données de capteur, peuvent être envoyées régulièrement. Vous pouvez envoyer des données basées sur des événements, tels que des déclencheurs sur des conditions d’erreur, comme une réaction aux actions de l’utilisateur ou en réponse aux requêtes distantes.

Diagramme du flux de données de messagerie.

  1. Gestion des API fournit un accès sécurisé au service de gestion du véhicule, de l’appareil et du consentement de l’utilisateur. Le véhicule est configuré pour un client en fonction de ses options d’achat. Les API managées fournissent l’accès aux éléments suivants :

    1. Informations d’approvisionnement pour les véhicules et les appareils.

    2. Configuration initiale de la collecte des données des véhicules en fonction des considérations relatives au marché et à l’entreprise.

    3. Stockage des paramètres de consentement utilisateur initiaux en fonction des options de véhicule et de l’acceptation des utilisateurs définis dans le back-end de gestion du consentement.

  2. Le véhicule publie des messages de télémétrie et d’événements par le biais d’un client MQTT avec des rubriques définies sur la fonctionnalité broker MQTT Event Grid dans les services de messagerie du véhicule.

  3. Event Grid achemine les messages vers différents abonnés en fonction de la rubrique, des attributs de message ou de la charge utile. Pour plus d’informations, consultez filtrage des messages routés par MQTT.

    1. Une instance Azure Event Hubs met en mémoire tampon des messages à volume élevé et de faible priorité qui ne nécessitent pas de traitement immédiat, comme ceux utilisés uniquement pour l’analytique. Ensuite, il achemine les messages directement vers le stockage. Pour des raisons de performances, n’utilisez pas le filtrage de charge utile pour ces messages.

    2. Une instance Event Hubs met en mémoire tampon les messages à priorité élevée qui nécessitent un traitement immédiat, comme les modifications d’état dans une application orientée utilisateur avec des attentes à faible latence. Ensuite, il les achemine vers une fonction Azure.

  4. Le système stocke les messages de faible priorité directement dans un lakehouse à l’aide de capture d’événements. Pour optimiser les coûts, ces messages peuvent utiliser décodage par lots et le traitement.

  5. Une fonction Azure traite les messages à priorité élevée. La fonction lit les paramètres de consentement du véhicule, de l’appareil et de l’utilisateur à partir du Registre de l’appareil et effectue les étapes suivantes :

    1. Vérifie que le véhicule et l’appareil sont inscrits et actifs.

    2. Vérifie que l’utilisateur a donné son consentement pour la rubrique du message.

    3. Décode et enrichit la charge utile.

    4. Ajoute des informations de routage supplémentaires.

  6. Le flux d’événements de télémétrie en direct dans la solution de données et d’analytique reçoit les messages décodés. Eventhouse traite et stocke les messages au fur et à mesure de leur arrivée.

  7. La couche services numériques reçoit les messages décodés. Azure Service Bus avertit les applications des modifications et événements importants concernant l’état du véhicule. Eventhouse fournit le dernier état connu du véhicule et l’histoire à court terme.

Messages cloud-à-véhicule

Flux de données de diffusion

Les services numériques utilisent le flux de données de diffusion pour fournir des notifications ou des messages à plusieurs véhicules sur une rubrique commune. Les exemples typiques incluent le trafic et les services météorologiques.

Diagramme de l’analytique des données.

  1. Le service de notification est un client MQTT qui s’exécute dans le cloud. Il est inscrit et autorisé à publier des messages sur des rubriques spécifiques dans Event Grid. L’autorisation peut être effectuée via l’authentification microsoft Entra JSON Web Token.

  2. Le service de notification publie un message. Par exemple, un avertissement météorologique à la rubrique /weather/warning/.

  3. Event Grid vérifie si le service est autorisé à publier sur la rubrique fournie.

  4. Le module de messagerie du véhicule est abonné aux alertes météorologiques et reçoit la notification.

  5. Le module de messagerie notifie une charge de travail de véhicule. Par exemple, il avertit le système d’infotainment d’afficher le contenu de l’alerte météorologique.

Flux de données de commande et de contrôle

Le flux de données de commande et de contrôle effectue des commandes distantes dans le véhicule à partir d’un service numérique, comme une application complémentaire ou une communication avec l’infrastructure de mobilité. Ces commandes incluent des cas d’usage tels que le verrouillage ou le déverrouillage des portes, la définition du contrôle climatique pour la cabine, la charge de la batterie et l’exécution de modifications de configuration. Le succès de ces commandes dépend de l’état du véhicule. Ils peuvent nécessiter un certain temps pour se terminer.

Les commandes de véhicules nécessitent souvent le consentement de l’utilisateur, car elles contrôlent les fonctionnalités du véhicule. Ces commandes utilisent l’état du véhicule pour stocker les résultats intermédiaires et évaluer l’exécution réussie. La solution de messagerie doit avoir une logique de flux de travail de commande qui vérifie le consentement de l’utilisateur, suit l’état d’exécution de la commande et avertit le service numérique lorsque la commande est terminée.

Le flux de données suivant utilise des commandes émises à partir d’un service numérique d’application complémentaire comme exemple. Comme dans l’exemple précédent, l’application complémentaire est un service authentifié qui peut publier des messages sur Event Grid.

Diagramme du flux de données de commande et de contrôle.

  1. Gestion des API permet d’accéder au serveur principal de gestion des véhicules, des appareils et des consentements. Le propriétaire ou l’utilisateur du véhicule accorde son consentement pour effectuer les fonctions de commande et de contrôle via un service numérique, tel qu’une application complémentaire. Cela se produit généralement lorsque l’utilisateur télécharge ou active l’application et que l’OEM active son compte. Il déclenche une modification de configuration sur le véhicule pour s’abonner à la rubrique de commande associée dans le répartiteur MQTT.

  2. L’application complémentaire utilise la commande et l’API managée de contrôle pour demander l’exécution d’une commande distante. L’exécution de commandes peut avoir plus de paramètres pour configurer des options telles que le délai d’expiration, et les options de stockage et de transfert. La logique de flux de travail traite l’appel d’API.

  3. La logique de flux de travail décide comment traiter la commande en fonction de la rubrique et d’autres propriétés. Il crée un état pour suivre l’état du processus. La logique de flux de travail de commande vérifie les informations de consentement de l’utilisateur pour déterminer si le message peut être traité.

  4. La logique de flux de travail de commande publie un message dans Event Grid avec la commande et les valeurs de paramètre.

  5. Event Grid utilise des identités managées pour authentifier la logique de flux de travail. Il vérifie ensuite si la logique de flux de travail est autorisée à envoyer des messages aux rubriques fournies.

  6. Le module de messagerie du véhicule est abonné à la rubrique de commande et reçoit la notification. Il achemine la commande vers la charge de travail appropriée.

  7. Le module de messagerie surveille la charge de travail pour l’achèvement ou l’erreur. La charge de travail est chargée de l’exécution physique de la commande.

  8. Le module de messagerie publie des rapports d’état de commande sur Event Grid. Le véhicule utilise un certificat X.509 pour s’authentifier auprès d’Event Grid.

  9. La logique de flux de travail est abonnée aux mises à jour de l’état des commandes et met à jour l’état interne de l’exécution des commandes.

  10. Une fois l’exécution de la commande terminée, l’application de service reçoit le résultat d’exécution sur l’API de commande et de contrôle.

La logique de flux de travail de commande et de contrôle peut échouer si le véhicule perd la connectivité. La fonctionnalité broker MQTT Event Grid prend en charge les messages Dernière volonté et testament. Si l’appareil se déconnecte brusquement, le répartiteur MQTT distribue un message à tous les abonnés. La logique de flux de travail s’inscrit au message will pour gérer la déconnexion, interrompre le traitement et avertir le client avec un code d’erreur approprié.

Provisionnement de véhicules et d’appareils

Ce flux de données décrit le processus d’inscription et de provisionnement de véhicules et d’appareils auprès des services de messagerie de véhicules. Le processus est généralement lancé dans le cadre de la fabrication de véhicules. Dans l’industrie automobile, les appareils de véhicules sont généralement authentifiés à l’aide de certificats X.509. Event Grid nécessite une racine ou un X.509 intermédiaire pour authentifier les appareils clients. Pour plus d’informations, consultez d’authentification du client.

Diagramme du flux de données d’approvisionnement.

  1. Le système d’usine commande l’appareil de véhicule à l’état de construction souhaité. Il peut inclure l’installation et la configuration initiales du microprogramme et des logiciels. Dans le cadre de ce processus, le système d’usine écrit le certificat X.509 de l’appareil, émis par une autorité de certification d’infrastructure à clé publique, dans le stockage conçu spécifiquement à cet effet, tel qu’un module de plateforme approuvée.

  2. Le système d’usine inscrit le véhicule et l’appareil à l’aide de l’API Vehicle and Device Provisioning.

  3. Le système d’usine déclenche le client d’approvisionnement d’appareils pour se connecter à l’inscription de l’appareil et approvisionner l’appareil. L’appareil récupère les informations de connexion au 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’appareil pour établir une connexion au répartiteur MQTT pour la première fois.

    1. Le répartiteur MQTT authentifie l’appareil à l’aide du certificat racine de l’autorité de certification et extrait les informations du client.
  6. Le répartiteur MQTT gère l’autorisation pour les rubriques autorisées à l’aide du Registre local.

  7. Pour le remplacement de la partie, le système de concessionnaire OEM peut déclencher l’inscription d’un nouvel appareil.

Note

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 des données du véhicule. Vous pouvez utiliser d’autres sources de données, telles que les informations d’usine, les données d’erreur, les rapports de réparation, les journaux logiciels, l’audio ou la vidéo, pour enrichir et fournir du contexte aux données du véhicule.

Diagramme de l’analytique des données.

  1. La couche 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 de la communication bidirectionnelle vers le véhicule.

  2. La couche Informatique et opérations fournit des informations sur le logiciel qui s’exécute sur le véhicule et les services numériques cloud associés.

  3. Les ingénieurs données utilisent des ensembles de requêtes Notebooks et Kusto Query Language (KQL) pour analyser les données, créer des produits de données et configurer des pipelines. Microsoft Copilot dans Fabric prend en charge le processus de développement.

  4. Les pipelines traitent les messages dans un état plus affiné. Les pipelines enrichissent et dédupliquent les messages, créent des indicateurs de performances clés et préparent des jeux de données d’apprentissage pour Machine Learning.

  5. Les ingénieurs et les utilisateurs professionnels visualisent les données à l’aide de tableaux de bord Power BI ou en temps réel.

  6. Les ingénieurs données utilisent le réflexe pour analyser les données de véhicule enrichies en quasi-temps réel pour créer des événements tels que des demandes de maintenance prédictive.

  7. Les ingénieurs données configurent l’intégration métier d’événements et d’insights avec Azure Logic Apps. Les flux de travail mettent à jour les systèmes d’enregistrement, tels que Dynamics 365 et Dataverse.

  8. Azure Machine Learning Studio consomme des données d’entraînement générées pour créer ou mettre à jour des modèles Machine Learning.

Scalabilité

Modèle Tampons de déploiement

Une solution de véhicule et de données connectée peut être mise à l’échelle à des millions de véhicules et des milliers de services. Utilisez le modèle Tampons de déploiement pour obtenir une scalabilité et une élasticité.

Diagramme du concept d’extensibilité.

Chaque unité d’échelle de messagerie de véhicule est conçue pour prendre en charge une population de véhicules spécifique. Les facteurs tels que la région géographique ou l’année du modèle peuvent définir cette population. L’unité de mise à l’échelle de l’application met à l’échelle les services qui nécessitent l’envoi ou la réception de messages aux véhicules. Le service commun est accessible à partir de n’importe quelle unité d’échelle et fournit des services de gestion des véhicules et d’appareils et des services d’abonnement pour les applications et les appareils.

  1. L’unité de mise à l’échelle de l’application abonne les applications aux messages d’intérêt. Le service commun gère l’abonnement aux composants de l’unité d’échelle de messagerie du véhicule.

  2. Le véhicule utilise le service de gestion des appareils pour découvrir son affectation à une unité d’échelle de messagerie de véhicule.

  3. Si nécessaire, le véhicule est approvisionné à l’aide du véhicule et du provisionnement d’appareils flux de travail dans une unité d’échelle de messagerie de véhicule.

  4. Le véhicule peut désormais publier des messages et s’abonner aux rubriques du répartiteur MQTT. Event Grid utilise les informations d’abonnement pour acheminer le message.

Les exemples de messagerie précédemment utilisés illustrent la communication entre les unités d’échelle :

(A)télémétrie de base sans traitement intermédiaire

  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 applications consomment des messages à partir de leur instance Event Hubs d’entrée d’application.

(B)commande et de contrôle

  1. Les applications publient des commandes sur le véhicule via une instance Event Hubs. Ces commandes nécessitent un traitement, un contrôle de flux de travail et une autorisation à l’aide de la logique de flux de travail appropriée.

  2. Les messages d’état qui nécessitent un traitement sont routés vers la logique de flux de travail.

  3. Une fois la commande terminée, la logique de flux de travail transfère la notification au hub d’événements correspondant dans l’unité d’échelle de l’application pour que l’application consomme.

  4. L’application consomme des événements à partir du hub d’événements associé.

Noms de domaine personnalisés Event Grid

Vous pouvez affecter des noms de domaine personnalisés aux noms d’hôtes MQTT et HTTP de votre espace de noms d’espace de noms Event Grid, ainsi que les noms d’hôtes par défaut. Les configurations de domaine personnalisées éliminent la nécessité de modifier les appareils clients qui sont déjà liés à votre domaine. Ils vous aident également à répondre à vos exigences de sécurité et de conformité. Pour simplifier les scénarios de configuration et de migration des appareils, utilisez noms de domaine personnalisés.

Composants

Cet exemple d’architecture inclut les composants Azure suivants.

Connectivité

  • event Grid vous permet de créer facilement des applications avec des architectures basées sur des événements. Dans cette solution, Event Grid gère l’intégration, l’authentification et l’autorisation des appareils. Il prend également en charge la messagerie de publication-abonnement à l’aide de MQTT.

  • Event Hubs est un service de traitement des événements évolutif conçu pour traiter et ingérer de grandes quantités de données de télémétrie. Dans cette solution, Event Hubs met en mémoire tampon les messages et les remet pour un traitement ou un stockage ultérieurs.

  • Azure Functions est un service de calcul serverless qui exécute du code déclenché par des événements. Dans cette solution, Functions traite les messages de véhicule. Vous pouvez également utiliser Functions pour implémenter des API de gestion qui nécessitent une opération à court terme.

  • Azure Kubernetes Service (AKS) déploie des charges de travail et des services complexes en tant qu’applications conteneurisées. Dans cette solution, AKS héberge la logique de flux de travail de commande et de contrôle et implémente les API de gestion.

  • Azure Cosmos DB est un service de base de données multimodèle distribué à l’échelle mondiale. Dans cette solution, elle stocke les paramètres de consentement du véhicule, de l’appareil et de l’utilisateur.

  • gestion des API Azure garantit une gestion sécurisée et efficace des API. Dans cette solution, Gestion des API fournit une passerelle d’API managée aux services back-end existants, tels que la gestion du cycle de vie des véhicules, y compris les mises à jour par air et la gestion du consentement des utilisateurs.

  • Azure Batch est un service de plateforme qui fournit des fonctionnalités de planification des travaux et de gestion des machines virtuelles. Dans cette solution, Batch exécute des applications en parallèle à grande échelle. Il gère également efficacement de grandes tâches nécessitant beaucoup de ressources de calcul, telles que l’ingestion de trace de communication des véhicules.

Données et analytique

  • Microsoft Fabric est une plateforme unifiée pour l’analytique des données qui inclut le déplacement, le traitement, l’ingestion, la transformation, le routage des événements et la génération de rapports. Il fournit des analyses de données pour toutes les données de véhicule et d’exploitation collectées.

Intégration du back-end

  • Logic Apps est une plateforme permettant de créer et d’exécuter des flux de travail automatisés. Dans cette solution, elle exécute des flux de travail pour l’intégration métier basée sur les données du véhicule.

  • Azure App Service est une plateforme entièrement managée pour la création, le déploiement et la mise à l’échelle d’applications web. Dans cette solution, elle fournit des applications web orientées utilisateur et des back-ends mobiles, comme l’application complémentaire.

  • cache Azure pour Redis fournit une mise en cache des données hautes performances pour accélérer les applications. Dans cette solution, elle fournit une mise en cache en mémoire des données souvent utilisées par les applications orientées utilisateur telles que l’application complémentaire.

  • Service Bus est un service de messagerie qui garantit une communication fiable, avec une sécurité renforcée, entre les applications distribuées et les services. Dans cette solution, elle dissocie la connectivité des véhicules à partir des services numériques et de l’intégration commerciale.

  • Microsoft Dynamics 365 est une suite d’applications métier intelligentes dans les ventes, les services, les finances et les opérations. Dans cette solution, elle offre une expérience client connectée et des processus métier transparents, ce qui garantit un meilleur concessionnaire et des opérations OEM.

  • Microsoft Dataverse stocke et gère les données des applications métier avec une sécurité renforcée. Dans cette architecture, elle stocke des informations sur le client et le véhicule.

Alternatives

Le choix du calcul approprié pour le traitement des messages et les API gérées dépend de plusieurs facteurs. Pour plus d’informations, consultez Choisir un service de calcul Azure.

Nous vous recommandons d’utiliser :

  • Functions pour les processus pilotés par les événements, tels que l’ingestion de télémétrie.

  • Batch pour les tâches de calcul hautes performances telles que le décodage de fichiers de trace CAN volumineux et vidéo.

  • AKS pour l’orchestration managée et complète de logique complexe conteneurisée, telle que la gestion des commandes et des flux de travail de contrôle.

En guise d’alternative au partage de données basé sur des événements, vous pouvez utiliser Azure Data Share si l’objectif est d’effectuer la synchronisation par lots au niveau du lac de données.

Pour l’analytique des données, vous pouvez utiliser :

  • Azure Databricks pour fournir un ensemble d’outils permettant de gérer des solutions de données de qualité entreprise à grande échelle. Databricks est nécessaire pour les opérations de longue durée sur de grandes quantités de données de véhicule.

  • Azure Data Explorer pour fournir une exploration, une curation et une analytique des données de télémétrie de véhicules basées sur des séries chronologiques.

Détails du scénario

Diagramme de la vue de haut niveau.

Les FABRICANTS automobiles subissent une transformation importante, car ils passent de la production de produits fixes à la fourniture de véhicules connectés et définis par logiciel (SDV). Les véhicules offrent une gamme de fonctionnalités, telles que les mises à jour à l’air, les diagnostics distants et les expériences utilisateur personnalisées. Cette transition permet aux OEM d’améliorer en permanence leurs produits en fonction des données et des insights en temps réel tout en développant leurs modèles métier pour inclure de nouveaux services et flux de revenus.

Cet exemple d’architecture décrit comment les fabricants automobiles et les fournisseurs de mobilité peuvent :

  • Utilisez les données de commentaires dans le cadre du processus d’ingénierie numérique pour favoriser l’amélioration continue des produits, résoudre de manière proactive les causes racines des problèmes et créer une valeur client.

  • Fournissez de nouveaux produits et services numériques et digitalisez les opérations avec l’intégration de l’entreprise avec des systèmes back-end tels que ERP et CRM.

  • Partagez des données avec une sécurité renforcée et répondez aux exigences propres aux pays ou aux régions pour le consentement de l’utilisateur à l’aide des écosystèmes de mobilité intelligente plus larges.

  • Intégrez des systèmes principaux pour la gestion du cycle de vie des véhicules et la gestion des consentements afin de simplifier et d’accélérer le déploiement et la gestion des solutions de véhicules connectés à l’aide d’une chaîne d’outils DevOps SDV.

  • Stockez et fournissez des calculs à grande échelle pour les véhicules et l’analytique.

  • Gérez la connectivité des véhicules à des millions d’appareils de manière rentable.

Cas d’usage potentiels

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

  • amélioration continue des produits améliore les performances des véhicules en analysant les données en temps réel et en appliquant des mises à jour à distance. Pour plus d’informations sur le développement de logiciels pour le véhicule, consultez chaîne d’outils SDV DevOps.

  • validation de la flotte d’essais techniques garantit la sécurité et la fiabilité des véhicules en collectant et en analysant les données des flottes d’essais. Pour plus d’informations, consultez Analyse des données pour les flottes de tests automobiles.

  • 'application compagnon et le portail utilisateur permet d’accéder et de contrôler à distance par le biais d’une application personnalisée et d’un portail web.

  • de réparation et de maintenance proactives prédit et planifie la maintenance des véhicules en fonction des insights pilotés par les données.

Des cas d’utilisation plus larges de l’écosystème améliorent les applications de véhicules connectés. Ces améliorations profitent aux opérations de flotte, à l’assurance, au marketing et à l’assistance routière dans l’ensemble du paysage du transport.

  • opérations de flotte commerciale connectées optimiser la gestion de la flotte grâce à la surveillance en temps réel et à la prise de décision pilotée par les données. Pour plus d’informations, consultez flottes connectées automobiles.

  • Assurance automobile numérique personnalise les primes d’assurance en fonction du comportement de conduite et fournit des rapports immédiats sur les accidents.

  • marketing basé sur l’emplacement fournit des campagnes marketing ciblées aux conducteurs en fonction de leur emplacement et de leurs préférences.

  • l’assistance routière utilise les données de localisation et de diagnostic des véhicules pour fournir un support en temps réel aux conducteurs en besoin.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, qui est un ensemble d’ensembles guidants qui peuvent être utilisés pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Azure Well-Architected Framework.

Fiabilité

La fiabilité garantit que votre application peut respecter les engagements que vous prenez à vos clients. Pour plus d’informations, consultez Vue d’ensemble du pilier fiabilité.

  • Augmentez la fiabilité avec la mise à l’échelle horizontale. Pour plus d’informations sur la mise à l’échelle de votre pipeline de traitement des messages, consultez options d’hébergement Functions. Pour plus d’informations sur la mise à l’échelle de la logique d’exécution du flux de travail et des services numériques, consultez options de mise à l’échelle pour les applications dans AKS.

  • Gérez les ressources de calcul en effectuant une mise à l’échelle dynamique en fonction de la demande via la mise à l’échelle automatique.

  • Utilisez unités d’échelle pour réduire la charge sur les composants individuels et fournir une cloison entre les véhicules. Une panne sur un tampon n’affecte pas les autres.

  • Utilisez unités d’échelle pour isoler les régions géographiques qui ont des réglementations différentes.

  • Répliquez des données dans plusieurs emplacements géographiques pour la tolérance de panne et la récupération d’urgence à l’aide de la géoredondance.

La fiabilité des connexions de véhicules est essentielle pour la messagerie automobile. Pour plus d’informations, consultez fiabilité dans l’espace de noms Event Grid et Event Grid.

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’abus de vos données et systèmes précieux. Pour plus d’informations, consultez Vue d’ensemble du pilier sécurité.

  • Utilisez des certificats X.509 pour garantir une communication sécurisée entre les véhicules et Azure. Pour plus d’informations, consultez gestion des certificats .

  • Établissez un VSOC pour détecter les menaces, prévenir les cyber-attaques et respecter les mesures réglementaires.

  • Collecter et fusionner des informations à partir de plusieurs sources de données. Établissez des processus d’atténuation des risques, d’investigation des données, de réponse aux incidents et d’atténuation des attaques.

  • Créez une détection d’anomalie et un avertissement précoce pour les réseaux, les services numériques et les unités de contrôle électronique.

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 Optimisation des coûts.

  • Considérez le coût par véhicule. Les coûts de communication doivent varier en fonction du nombre de services numériques fournis. Calculez le retour sur investissement pour chaque service numérique par rapport aux coûts opérationnels.

  • Établissez des pratiques pour l’analyse des coûts en fonction du trafic de messages. Le trafic de véhicules connectés peut augmenter au fil du temps à mesure que d’autres services sont ajoutés. Il s’agit notamment d’une collecte accrue de données pour les produits d’assurance télématique, l’IA générative optimisée pour les assistants numériques en véhicule et les applications de partage de voitures.

  • Prenez en compte les coûts réseau et mobile.

    • Utilisez alias de rubrique MQTT pour réduire la longueur de vos noms de rubriques. Cette approche permet de réduire le volume de trafic.

    • Utilisez une méthode efficace, telle que Protobuf ou JSON gzipped, pour encoder et compresser les messages de charge utile.

  • Gérez activement le trafic.

    • Les véhicules ont tendance à avoir des modèles d’utilisation récurrents qui créent des pics de demande quotidiens et hebdomadaires.

    • Hiérarchiser les messages à l’aide de propriétés utilisateur MQTT dans votre configuration de routage. Vous pouvez utiliser cette approche pour différer le traitement des messages non critiques ou analytiques pour faciliter la charge et optimiser l’utilisation des ressources.

    • Envisagez un traitement spécifique au contexte en fonction des exigences opérationnelles. Par exemple, envoyez davantage de données de télémétrie de frein uniquement pendant les conditions de freinage sévères.

    • Ajustez la capacité en fonction de la demande.

  • Réfléchissez à la durée pendant laquelle les données doivent être stockées dans un stockage chaud, chaud ou froid.

  • Optimisez les coûts à l’aide d’instances réservées.

Excellence opérationnelle

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

Pour améliorer les opérations informatiques unifiées, envisagez de surveiller le logiciel du véhicule. Ce logiciel inclut les journaux, les métriques et les traces, les services de messagerie, les services de données et d’analytique, ainsi que les services principaux associés.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à mettre à l’échelle pour répondre aux demandes qu’elle lui impose par les utilisateurs de manière efficace. Pour plus d’informations, consultez Vue d’ensemble du pilier Performance Efficiency.

  • Envisagez d’utiliser le concept d’unité d’échelle pour les solutions qui sont mises à l’échelle au-dessus de 50 000 appareils, en particulier si plusieurs régions géographiques sont requises.

  • Prenez en compte les limites, quotas et contraintes d’abonnement Azure, de quotas et de contraintes lorsque vous concevez vos unités d’échelle.

  • Considérez la meilleure façon d’ingérer des données, qu’il s’agisse d’une messagerie, d’une diffusion en continu ou d’une méthode par lots. Par exemple, gérez immédiatement les messages à priorité élevée, tels que les demandes des utilisateurs. Acheminer les messages d’analyse, tels que les données de performances des véhicules, directement vers le stockage sans traitement. Concevez votre système pour réduire le nombre de messages à priorité élevée nécessitant un traitement immédiat.

  • Considérez la meilleure façon d’analyser les données en fonction du cas d’usage, via un traitement par lots ou en quasi-temps réel. L’analyse en temps quasi réel fournit des notifications immédiates aux utilisateurs, telles que les alerter contre un problème de véhicule imminent. Les analyses par lots s’exécutent régulièrement et fournissent des notifications non chirurgicales, telles que la prédiction de la maintenance à venir.

Déployer ce scénario

Le tutoriel relatif à l’architecture de référence de la flotte connectée contient un exemple d’implémentation du pipeline de traitement des messages.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

Autres contributeurs :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

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

Les articles suivants couvrent certains des modèles utilisés dans l’architecture :