Partager via

Analytique données pour les flottes de tests automobiles

Microsoft Fabric
Explorateur de données Azure
Azure Event Hubs
Azure Functions
Azure Event Grid

Les fabricants d’équipements d’origine automobile (OEM) ont besoin de solutions pour minimiser le temps entre les essais routiers et la livraison des données de diagnostic des essais routiers aux ingénieurs R&D. À mesure que les véhicules deviennent plus automatisés, les cycles de développement de logiciels deviennent plus courts, ce qui nécessite des boucles de rétroaction numérique plus rapides. La nouvelle technologie peut démocratiser l’accès aux données et fournir aux ingénieurs en recherche et développement des insights quasiment en temps réel sur des données de diagnostic d’essai. Utilisez Copilot pour la Data Science et le Data Engineering pour l’analyse des données afin de réduire encore le temps nécessaire pour obtenir des informations. Le partage sécurisé des données peut améliorer la collaboration entre les OEM et les fournisseurs et réduire les temps de cycle de développement.

Les conseils de cet article concernent les scénarios de télémétrie et les scénarios d’ingestion de données d’essais routiers par lots. Cette architecture se concentre sur la plateforme de données qui traite les données de diagnostic et les connecteurs pour la visualisation et la génération de rapports de données.

Architecture

Diagramme montrant le flux de données analytiques pour les données et fichiers automobiles en streaming.

Téléchargez un fichier PowerPoint avec tous les diagrammes de cet article.

Dataflow

Le flux de données suivant correspond au diagramme précédent :

  1. Le dispositif de capture de données est connecté aux réseaux du véhicule et collecte des données de signal du véhicule en haute résolution et des vidéos. (1a) L’appareil publie des messages de télémétrie en temps réel ou (1b) demande le chargement de fichiers de données enregistrés vers la fonctionnalité de répartiteur MQTT Azure Event Grid à l’aide d’un client MQTT. Cette fonctionnalité utilise un modèle Claim-Check.

  2. (2a) Event Grid achemine les données de signal de véhicule en direct vers une application Azure Functions. Cette application décode les signaux du véhicule au format JavaScript Object Notation (JSON) et les publie dans un flux d’événements.

    (2b) Event Grid coordonne le chargement du fichier à partir du client de l’appareil vers le lakehouse. Un téléchargement de fichier terminé déclenche un pipeline qui décode les données et écrit le fichier décodé dans OneLine dans un format adapté à l’ingestion, tel que parquet ou CSV.

  3. (3a) Le flux d’événements achemine les signaux de véhicule JSON décodés pour l’ingestion dans l’Eventhouse.

    (3b) Un pipeline de données déclenche l’ingestion de fichiers décodés à partir du lakehouse.

  4. Eventhouse utilise des stratégies de mise à jour pour enrichir les données et développer les données JSON dans un format de ligne approprié, par exemple, les données d’emplacement peuvent être regroupées pour s’aligner sur l’analytique géospatiale. Chaque fois qu’une nouvelle ligne est ingérée, le moteur d’analyse en temps réel invoque une fonction Update() associée.

  5. Les ingénieurs de données et les data scientists utilisent Kusto Query Language (KQL) pour créer des cas d’utilisation analytique. Les utilisateurs stockent des cas fréquemment utilisés en tant que fonctions définies par l’utilisateur partageables. Les ingénieurs utilisent des fonctions KQL intégrées telles que l’agrégation, l’analyse de séries temporelles, le regroupement géospatial, le fenêtrage et les plugins de machine learning avec le support de Copilot.

  6. Les ingénieurs R&D et les data scientists utilisent des notebooks pour analyser les données et créer des cas d’utilisation de test et de validation.

    1. Les ingénieurs R&D utilisent des ensembles de requêtes KQL et Copilot pour l’intelligence en temps réel pour effectuer des analyses de données interactives.

    2. Les ingénieurs données et les scientifiques des données utilisent des notebooks pour stocker et partager leurs processus d’analyse. Avec des notebooks, les ingénieurs peuvent utiliser Azure Spark pour exécuter des analyses et utiliser Git pour gérer le code du notebook. Les utilisateurs peuvent tirer parti de Copilot for Data Science and Data Engineering pour soutenir leur flux de travail avec des suggestions de code contextuelles.

  7. Les ingénieurs R&D et les data scientists peuvent utiliser Power BI avec des requêtes dynamiques ou des tableaux de bord d’analyse en temps réel pour créer des visualisations à partager avec les utilisateurs professionnels. Ces visualisations invoquent des fonctions définies par l’utilisateur pour faciliter la maintenance.

  8. Les ingénieurs peuvent également connecter plus d’outils à Microsoft Fabric. Par exemple, ils peuvent connecter Azure Managed Grafana à l’Eventhouse ou créer une application web qui interroge directement l’Eventhouse.

  9. Les ingénieurs données et les ingénieurs R&D utilisent l’activateur de données pour créer des éléments réflexeurs pour surveiller les conditions et déclencher des actions, telles que le déclenchement de flux Power Automate pour l’intégration métier. Par exemple, Data Activator peut notifier un canal Teams si la santé d’un appareil se dégrade.

  10. La configuration du collecteur de données permet aux ingénieurs de modifier les politiques de collecte de données du dispositif de capture de données. Azure API Management abstrait et sécurise l’API de configuration des partenaires et fournit de l’observabilité.

Schéma de base de données KQL

Diagramme montrant la base de données KQL et les méthodes pour extraire, étendre et enrichir les données.

Lorsque vous concevez le schéma de la table, considérez la différence entre les tables fact et les tables dimension. La télémétrie est une table fact car les signaux des véhicules sont progressivement ajoutés de manière continue ou dans le cadre d’un enregistrement complet, et la télémétrie ne change pas. Vous pouvez classer les métadonnées de la flotte comme une table fact qui se met à jour lentement.

La télémétrie du véhicule atterrit dans des tables brutes. Vous pouvez utiliser les concepts de traitement de messages suivants pour organiser les données pour l’analyse et la génération de rapports :

  • Créez des politiques de mise à jour pour étendre les fichiers de télémétrie JSON en enregistrements de signaux de véhicule individuels en utilisant des méthodes telles que :

    • mv-expand() étend les valeurs complexes stockées dans les structures JSON en lignes avec des signaux individuels.
    • geo_point_to_h3cell() ou geo_point_to_geohash() convertissent la latitude et la longitude en géohachages pour l’analyse géospatiale.
    • todouble() et tostring() convertissent les valeurs extraites des objets JSON dynamiques en types de données appropriés.
    • lookup étend les enregistrements avec des valeurs provenant d’une table de dimensions.

  • Créez une vue matérialisée de signaux dédupliquée à l’aide de la fonction take_any() d’agrégation sur la clé unique et l’horodatage. Cette vue matérialisée déduplique les signaux.

  • Créez une vue matérialisée Signals Last Known Values en utilisant la fonction d’agrégation arg_max() sur l’horodatage. Cette vue matérialisée fournit un état à jour des véhicules.

  • Créez une vue matérialisée signalant les signaux à l’aide de l’opérateur de synthèse avec des compartiments de temps tels que toutes les heures et tous les jours. Cette vue matérialisée agrège les signaux et simplifie la génération de rapports sur l’ensemble de la flotte.

  • Créez des fonctions définies par l’utilisateur qui fournissent une détection d’anomalies ou une analyse des causes profondes.

    • Utilisez des fonctions de séries temporelles pour la détection d’anomalies et les prévisions afin de détecter des problèmes potentiels et prédire des défaillances.

    • Utilisez l’opérateur d’analyse pour analyser, mettre en correspondance et générer des séquences à partir des données. Les ingénieurs peuvent utiliser l’opérateur scan pour détecter des séquences. Par exemple, si un événement spécifique se produit, alors un événement ultérieur doit se produire dans un certain laps de temps.

    • Utilisez des plug-ins Machine Learning comme autocluster pour rechercher des modèles courants d’attributs discrets.

  • Effectuez des analyses géospatiales avec des fonctions définies par l’utilisateur. Utilisez les fonctions d’analyse géospatiale pour convertir les coordonnées en un système de grille approprié et effectuer des agrégations sur les données.

  • Créez une table de métadonnées de flotte pour stocker les modifications des métadonnées et de la configuration du véhicule. Créez une vue matérialisée dernières valeurs connues des métadonnées de la flotte pour stocker l’état le plus récent de la flotte de véhicules en fonction d’une colonne de dernière modification.

Components

Les technologies clés suivantes mettent en œuvre cette charge de travail. Pour chaque composant de l’architecture, utilisez le guide de service pertinent dans le cadre bien architecturé, le cas échéant. Pour plus d’informations, veuillez consulter les guides de service de Well-Architected Framework.

  • Fabric Real-Time Intelligence est un service qui ingère, analyse et réagit aux données de streaming via des flux d’événements et des bases de données KQL. Dans cette architecture, elle stocke et traite les données de télémétrie des véhicules en mouvement, ce qui permet l’analytique en temps réel et déclenche des actions automatisées par le biais de réflexes.

  • L’activateur de données est un outil d’automatisation sans code qui répond aux modèles et conditions de données. Dans cette architecture, il surveille les données de télémétrie et déclenche des actions telles que des alertes ou des flux Power Automate lorsque les données répondent à des conditions prédéfinies.

  • Event Grid est un service de routage des événements managé qui prend en charge MQTT et d’autres protocoles. Dans cette architecture, elle distribue les événements de télémétrie et de chargement de fichiers à partir de véhicules vers des services en aval tels qu’Azure Functions et le lakehouse. Les véhicules peuvent utiliser Event Grid pour publier et s’abonner à des rubriques. Par exemple, ils peuvent publier des données de télémétrie et s’abonner aux messages de commande et de contrôle.

  • Azure Event Hubs est une plateforme de diffusion en continu de données en temps réel conçue pour les scénarios à haut débit. Dans cette architecture, elle ingère des millions d’événements de télémétrie de véhicules par seconde avec une faible latence pour le traitement en temps réel.

  • Functions est un service de calcul serverless qui exécute du code en réponse aux événements. Dans cette architecture, elle décode les données de télémétrie, orchestre l’ingestion de fichiers et déclenche des workflows d’analytique en aval. Il simplifie le traitement des événements de télémétrie des véhicules à grande échelle avec des déclencheurs et des liaisons pilotés par les événements à l’aide du langage de votre choix.

  • Azure Managed Grafana est une plateforme de visualisation des données basée sur le logiciel de Grafana Labs. Microsoft gère et supporte Azure Managed Grafana. Dans cette architecture, elle visualise les données de télémétrie stockées dans la maison d’événements, qui prennent en charge les tableaux de bord pour les équipes d’ingénierie et d’exploitation.

  • Azure App Service est un service permettant de créer et d’héberger des applications web et des API. Dans cette architecture, elle expose les données de télémétrie des véhicules stockées dans Fabric via des API RESTful que les applications externes consomment.

  • Gestion des API est une plateforme multicloud hybride pour la gestion des API. Dans cette architecture, elle sécurise et extrait l’accès aux API orientées partenaires utilisées pour configurer des appareils de capture de données et intégrer des flux de travail métier.

Alternatives

Vous pouvez également utiliser les services Azure suivants pour mettre en œuvre cette architecture :

  • Azure Blob Storage stocke d’énormes quantités de données non structurées, telles que des enregistrements, des journaux et des vidéos des véhicules. Il remplace le stockage OneLake.

  • Azure Data Explorer est un service d’analytique données rapide et entièrement managé dédié à l’analyse en temps réel de volumes importants de données de streaming. Il remplace la base de données KQL Fabric Real-Time Intelligence.

  • Azure Batch est une alternative que vous pouvez utiliser pour décoder des fichiers complexes. Ce scénario implique un grand nombre de fichiers de plus de 300 mégaoctets chacun. Les fichiers nécessitent différents algorithmes de décodage en fonction de la version ou du type de fichier. Vous pouvez utiliser Fabric ou utiliser Blob Storage et Azure Data Explorer pour mettre en œuvre l’approche suivante.

Diagramme montrant une méthode alternative par lots pour décoder des fichiers complexes.

  1. L’utilisateur ou le dispositif d’enregistrement télécharge un fichier de données enregistré dans le lakehouse. Lorsque le téléchargement se termine, il déclenche une application Functions qui planifie le décodage.

  2. Le planificateur démarre une application Functions qui crée un travail par lots en fonction du type de fichier, de la taille du fichier et de l’algorithme de décodage requis. L’application sélectionne une machine virtuelle de taille appropriée dans le pool et démarre le travail.

  3. Batch écrit le fichier décodé résultant dans le lakehouse lorsque le travail est terminé. Ce fichier doit être adapté pour une ingestion directe dans un format pris en charge par l’Eventhouse.

  4. Le lakehouse déclenche une fonction qui ingère les données dans l’Eventhouse lors de l’écriture du fichier. Cette fonction crée la table et la cartographie des données si nécessaire et démarre le processus d’ingestion.

  5. La base de données KQL ingère les fichiers de données du lakehouse.

Cette approche offre les avantages suivants :

  • Les pools Functions et Batch peuvent gérer de manière robuste et efficace les tâches de traitement des données évolutives.

  • Les pools Batch fournissent des insights sur les statistiques de traitement, les files d’attente de tâches et l’intégrité du pool Batch. Vous pouvez visualiser l’état, détecter les problèmes et réexécuter les tâches ayant échoué.

  • La combinaison de Functions et Batch prend en charge le traitement plug-and-play dans des conteneurs Docker.

  • Vous pouvez utiliser des machines virtuelles spot pour traiter les fichiers pendant les heures creuses. Cette approche permet d’économiser de l’argent.

Détails du scénario

Les OEM automobiles utilisent de grandes flottes de véhicules prototypes et d’essai pour tester et vérifier plusieurs fonctions du véhicule. Les procédures de test sont coûteuses car elles nécessitent des conducteurs et des véhicules réels, et des scénarios de test en conditions réelles spécifiques doivent réussir plusieurs fois. Les tests d’intégration sont particulièrement importants pour évaluer les interactions entre les composants électriques, électroniques et mécaniques dans les systèmes complexes.

Pour valider les fonctions des véhicules et analyser les anomalies et les défaillances, vous devez capturer des pétaoctets de données de diagnostic provenant des unités de contrôle électronique (ECU), des nœuds informatiques, des bus de communication des véhicules comme le Controller Area Network (CAN) et l’Ethernet, et des capteurs.

Dans le passé, de petits serveurs de journalisation de données dans les véhicules stockaient des données de diagnostic localement sous forme de fichiers au format Measurement Data Format (MDF), extension de fusion multimédia (MFX), CSV ou JSON. Après la fin des essais routiers, les serveurs téléchargeaient les données de diagnostic vers des centres de données, qui les traitaient et les envoyaient aux ingénieurs R&D pour analyse. Ce processus pouvait prendre des heures, ou parfois des jours. Les scénarios plus récents utilisent des modèles d’ingestion de télémétrie tels que des flux de données synchrones basés sur le Message Queuing Telemetry Transport (MQTT) ou des téléchargements de fichiers quasi en temps réel.

Cas d’usage potentiels

  • La gestion des véhicules évalue les performances et les données collectées par véhicule dans plusieurs scénarios de test.

  • La validation du système et des composants utilise les données de véhicule collectées pour vérifier que le comportement des composants du véhicule se situe dans des limites opérationnelles tout au long des trajets.

  • La détection d’anomalies localise les modèles d’écart d’une valeur de capteur par rapport à son modèle de référence classique en temps réel.

  • L’analyse des causes profondes utilise des plugins de machine learning tels que les algorithmes de clustering pour identifier les changements dans la distribution des valeurs sur plusieurs dimensions.

  • La maintenance prédictive combine plusieurs sources de données, des données de localisation enrichies et des signaux de véhicule pour prédire le temps de défaillance des composants.

  • L’évaluation de la durabilité utilise le comportement des conducteurs et la consommation d’énergie pour évaluer l’impact environnemental des opérations des véhicules.

  • Les courses automobiles pour comprendre et améliorer les performances des véhicules avant, pendant et après une course.

Considerations

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.

Reliability

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la fiabilité.

  • Les zones de disponibilité Azure sont des emplacements physiques uniques au sein de la même région Azure. Les zones de disponibilité peuvent protéger les clusters de calcul et les données d’Azure Data Explorer contre une défaillance partielle de la région.

  • Dans Azure Data Explorer, la continuité d’activité et la reprise d’activité permettent à votre entreprise de continuer de fonctionner en cas de perturbation.

  • Les bases de données de suivi séparent les ressources de calcul entre les cas d’usage de production et de non-production.

Security

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 en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la sécurité.

Il est important de comprendre la répartition des responsabilités entre l’OEM automobile et Microsoft. Dans le véhicule, l’OEM possède l’ensemble de la pile, mais à mesure que les données se déplacent vers le cloud, certaines responsabilités sont transférées à Microsoft. La plateforme en tant que service (PaaS) Azure fournit une sécurité intégrée sur la pile physique, y compris le système d’exploitation.

Toutes ces fonctionnalités aident les OEM automobiles à créer un environnement sécurisé pour leurs données de télémétrie des véhicules. Pour plus d’informations, consultez la section Sécurité dans Fabric.

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 Liste de contrôle de la révision de la conception pour l'optimisation des coûts.

Cette solution utilise les pratiques suivantes pour optimiser les coûts :

  • Configurez correctement les caches chauds et le stockage à froid pour les tables brutes et de signaux. Le cache de données chaudes est stocké dans la RAM ou le SSD et offre des performances améliorées. Toutefois, les données froides sont 45 fois moins chères. Définissez une stratégie de cache chaud appropriée pour votre cas d’usage, par exemple 30 jours.

  • Définissez une politique de rétention sur la table brute et la table de signaux. Déterminez quand les données de signaux ne sont plus pertinentes, par exemple après 365 jours, et définissez la politique de rétention en conséquence.

  • Déterminez les signaux qui sont pertinents pour l’analyse.

  • Utilisez des vues matérialisées lorsque vous interrogez les dernières valeurs connues des signaux, les signaux dédupliqués et les signaux échantillonnés. Les vues matérialisées consomment moins de ressources que d’effectuer des agrégations de tables sources sur chaque requête.

  • Tenez compte de vos besoins en matière d’analytique des données en temps réel. Configurez l’ingestion en streaming pour la table de télémétrie en direct afin de fournir une latence de moins d’une seconde entre l’ingestion et la requête. Cette approche augmente les cycles CPU et le coût.

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 en savoir plus, consultez Liste de vérification de l'examen de la conception pour l'efficacité des performances

  • Envisagez d’utiliser Batch pour effectuer le décodage si le nombre et la taille des fichiers de données enregistrées dépassent 1 000 fichiers ou 300 Mo par jour.

  • Envisagez d’effectuer des calculs et analyses courants après ingestion et de les stocker dans des tables supplémentaires.

  • Utilisez les bonnes pratiques des requêtes KQL pour rendre votre requête plus rapide.

  • Utilisez une clause where pour définir une fenêtre de temps afin de réduire la quantité de données interrogées. Envisagez de modifier la politique de partitionnement des données pour la table de signaux si vos critères de recherche courants ne sont pas basés sur le temps, par exemple si vous filtrez par ID d’enregistrement et nom de signal. Lorsque la base de données KQL s’étend pour contenir des milliards ou des billions d’enregistrements, une filtrage appropriée des données devient essentielle, en particulier compte tenu de la stratégie de partition active.

Warning

Consultez votre équipe de support avant de modifier une politique de partitionnement des données.

Déployer ce scénario

Utilisez le didacticiel pas à pas pour déployer ce scénario. Le guide montre comment déployer une instance gratuite, analyser des fichiers MDF, ingérer des données et effectuer plusieurs requêtes de base.

Contributors

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