Modifier

Partager via

Analytique données pour les flottes de tests automobiles

Microsoft Fabric
Explorateur de données Azure
Hubs d'événements Azure
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) Le dispositif publie des messages de télémétrie en temps réel ou (1b) demande le téléchargement de fichiers de données enregistrées à la fonctionnalité de courtier MQTT Azure Event Grid en utilisant un client MQTT. Cette fonctionnalité utilise un modèle Claim-Check.

  2. (2a) Event Grid route les données de signal du 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 téléchargement des fichiers depuis le 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 route les signaux de véhicule JSON décodés pour ingestion dans l’Eventhouse.

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

  4. L’Eventhouse utilise des politiques de mise à jour pour enrichir les données et étendre les données JSON dans un format de ligne approprié, par exemple, les données de localisation peuvent être regroupées pour s’aligner sur les analyses géospatiales. 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 de données et les data scientists 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 de données et les ingénieurs R&D utilisent Data Activator pour créer des éléments réflexes afin de surveiller les conditions et déclencher des actions, telles que le déclenchement de flux Power Automate pour l’intégration commerciale. 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 Signals Deduped en utilisant la fonction d’agrégation take_any() 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 Signals Downsampled en utilisant l’opérateur summarize avec des intervalles de temps tels que horaire et journalier. 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 scan pour scanner, matcher et construire 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 plugins de machine learning comme autocluster pour trouver des modèles communs 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 des coordonnées en un système de grille adapté 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.

Composants

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 est un outil sans code que vous pouvez utiliser pour automatiser des actions lorsque les modèles ou les conditions changent dans les données.

  • Event Grid est un service de distribution de messages Publish/Subscribe hautement évolutif et entièrement géré qui prend en charge les protocoles MQTT. 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 est une solution serverless qui 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 des événements en utilisant le langage de votre choix.

  • 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 est une plateforme de gestion hybride multicloud pour les API.

Autres solutions

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.

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 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 follower séparent les ressources de calcul entre les cas d’utilisation de production et non-production.

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 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 à s’adapter à la demande des utilisateurs de façon 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 trillions d’enregistrements, une bonne filtration des données devient essentielle, en particulier en tenant compte de la politique de partitionnement active.

Avertissement

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

Déployer ce scénario

Utilisez le didacticiel étape par étape 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.

Contributeurs

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

Principaux auteurs :

Autres contributeurs :

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

Étapes suivantes