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) The device publishes real-time telemetry messages or (1b) requests the upload of recorded data files to the Azure Event Grid MQTT broker functionality by using an MQTT client. Cette fonctionnalité utilise un modèle Claim-Check.

  2. (2a) Event Grid routes live vehicle signal data to an Azure Functions app. 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 coordinates the file upload from the device client to the 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) The eventstream routes the decoded JSON vehicle signals for ingestion in the Eventhouse.

    (3b) A data pipeline triggers the ingestion of decoded files from the lakehouse.

  4. The Eventhouse uses update policies to enrich the data and to expand the JSON data into a suitable row format, for example location data might be clustered to align with geospatial analytics. 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. Data engineers and data scientists use notebooks to store and share their analysis processes. 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. Data engineers and R&D engineers use Data Activator to create reflex items to monitor conditions and trigger actions, such as triggering Power Automate flows for business integration. 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.

  • Create a Signals Deduped materialized view by using the aggregation function take_any() on the unique key and timestamp. 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.

  • Create a Signals Downsampled materialized view by using the summarize operator with time bins such as hourly and daily. 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.

    • Use the scan operator to scan, match, and build sequences from the data. 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.

    • Use machine learning plugins like autocluster to find common patterns of discrete attributes.

  • Effectuez des analyses géospatiales avec des fonctions définies par l’utilisateur. Use the geospatial analytics functions to convert coordinates to a suitable grid system and perform aggregations on the data.

  • 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 permet d’extraire des informations et de visualiser la télémétrie des véhicules en mouvement. Vous pouvez utiliser des flux d’événements et des bases de données de séries temporelles KQL pour stocker et analyser des données et utiliser des réflexes pour réagir aux événements.

  • Data Activator is a no-code tool that you can use to automate actions when patterns or conditions change in data.

  • Event Grid is a highly scalable, fully managed Publish/Subscribe message distribution service that supports MQTT protocols. Les véhicules peuvent utiliser Event Grid pour publier et s’abonner à des sujets, par exemple ils peuvent publier de la télémétrie et s’abonner à des messages de commande et de contrôle.

  • Azure Event Hubs est une plateforme de streaming de données en temps réel qui est bien adaptée pour diffuser des millions d’événements de véhicules par seconde avec une faible latence.

  • Functions is a serverless solution that simplifies processing vehicle telemetry events at scale with event-driven triggers and bindings by using the language of your choice.

  • Azure Managed Grafana est une plateforme de visualisation de données basée sur le logiciel de Grafana Labs. Microsoft gère et supporte Azure Managed Grafana.

  • Azure App Service vous permet de créer et d’héberger des applications web, des back-ends mobiles et des API RESTful qui fournissent un accès aux données de télémétrie des véhicules stockées dans Fabric. Cette approche simplifie la consommation.

  • API Management is a hybrid multicloud management platform for APIs.

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 is an alternative that you can use to decode complex files. 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.

Scenario details

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.

  • Follower databases separate compute resources between production and nonproduction use cases.

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.

Cost Optimization

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.

Performance Efficiency

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. When the KQL database expands to contain billions or trillions of records, proper data filtration becomes essential, especially considering the active partition policy.

Warning

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

Déployer ce scénario

Use the step-by-step tutorial to deploy this scenario. 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.

Principal authors:

Other contributors:

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

Next steps