Opérations de données pour les opérations de véhicules autonomes

Cet article fournit une solution et de l’aide pour le développement d’une solution d’opérations de données hors connexion et de gestion des données (DataOps) pour un système de conduite automatisée. La solution DataOps repose sur l’infrastructure décrite dans le guide de conception d’opérations de véhicules autonomes (AVOps). DataOps est l’un des blocs de construction d’AVOps. Les autres blocs de construction incluent les opérations d’apprentissage automatique (MLOps), les opérations de validation (ValOps), DevOps et les fonctions AVOps centralisées.

Apache®, Apache Spark et Apache Parquet sont soit des marques déposées, soit des marques commerciales d’Apache Software Foundation aux États-Unis et/ou dans d’autres pays. L’utilisation de ces marques n’implique aucune approbation de l’Apache Software Foundation.

Architecture

Téléchargez un fichier Visio qui contient les diagrammes d’architecture de cet article.

Dataflow

1. Les données de mesure proviennent des flux de données d’un véhicule. Les sources incluent les caméras, les données de télémétrie du véhicule, ainsi que les capteurs radar, à ultrasons et lidar. Les enregistreurs de données du véhicule stockent les données de mesure sur les appareils de stockage de l’enregistreur d’événements. Les données de stockage de l’enregistreur d’événements sont chargées dans un lac de données d’atterrissage. Un service comme Azure Data Box ou Azure Stack Edge, ou une connexion dédiée comme Azure ExpressRoute, ingère les données dans Azure. Les données de mesure dans les formats suivants arrivent dans Azure Data Lake Storage : Measurement Data Format version 4 (MDF4), systèmes de gestion des données techniques (SGDT) et rosbag. Les données chargées entrent dans un compte de stockage dédié appelé Landing (atterrissage) qui est désigné pour recevoir et valider les données.

2. Un pipeline Azure Data Factory est déclenché à un intervalle planifié pour traiter les données dans le compte de stockage d’atterrissage. Le pipeline gère les étapes suivantes :

   • Réalisation d’un contrôle de la qualité des données, tel qu’une somme de contrôle. Cette étape supprime les données de faible qualité afin que seules les données de haute qualité soient transmises à l’étape suivante. Azure App Service est utilisé pour exécuter le code de contrôle qualité. Les données jugées incomplètes sont archivées pour traitement ultérieur.
   • À des fins de suivi de traçabilité des données, appel d’une API de métadonnées à l’aide d’App Service. Cette étape met à jour les métadonnées stockées dans Azure Cosmos DB pour créer un flux de données. Pour chaque mesure, il existe un flux de données brutes.
   • Copie des données dans un compte de stockage appelé Raw (brut) dans Data Lake Storage.
   • Appel de l’API de métadonnées pour marquer le flux de données comme étant terminé afin que d’autres composants et services puissent consommer le flux de données.
   • Archivage des mesures et suppression de ces mesures du compte de stockage d’atterrissage.

3. Data Factory et Azure Batch traitent les données dans la zone brute pour extraire les informations que les systèmes en aval peuvent consommer :

   • Batch lit les données à partir des rubriques du fichier brut et génère les données dans les rubriques sélectionnées dans les dossiers respectifs.
   • Étant donné que la taille de chaque fichier de la zone brute peut être supérieure à 2 Go, les fonctions d’extraction de traitement parallèle sont exécutées sur chaque fichier. Ces fonctions extraient les données de traitement d’images, de lidar, de radar et de GPS. Elles effectuent également le traitement des métadonnées. Data Factory et Batch offrent un moyen d’effectuer le parallélisme de manière évolutive.
   • Les données sont sous-échantillonnée pour réduire la quantité de données qui doivent être étiquetées et annotées.

4. Si les données de l’enregistreur d’événements du véhicule ne sont pas synchronisées entre les différents capteurs, un pipeline Data Factory est déclenché pour synchroniser les données et créer un jeu de données valide. L’algorithme de synchronisation s’exécute sur Batch.

5. Un pipeline Data Factory est exécuté pour enrichir les données. Parmi les exemples d’améliorations, citons les données de télémétrie, les données de l’enregistreur d’événements du véhicule et d’autres données, telles que les données météorologiques, cartographiques ou d’objets. Les données enrichies permettent de fournir aux scientifiques des données des insights qu’ils peuvent utiliser pour développer des algorithmes, par exemple. Les données générées sont conservées dans des fichiers Apache Parquet compatibles avec les données synchronisées. Les métadonnées relatives aux données enrichies sont stockées dans un magasin de métadonnées dans Azure Cosmos DB.

6. Des partenaires tiers effectuent l’étiquetage manuel ou automatique. Les données sont partagées avec les partenaires tiers par le biais d’Azure Data Share et sont intégrées à Microsoft Purview. Data Share utilise un compte de stockage dédié nommé Labeled (étiqueté) dans Data Lake Storage pour retourner les données étiquetées à l’organisation.

7. Un pipeline Data Factory effectue la détection de scènes. Les métadonnées des scènes sont conservées dans le magasin de métadonnées. Les données des scènes sont stockées en tant qu’objets dans des fichiers Parquet ou Delta.

8. Outre les métadonnées relatives aux données d’enrichissement et aux scènes détectées, le magasin de métadonnées dans Azure Cosmos DB stocke les métadonnées des mesures, telles que les données de conduite. Ce magasin contient également les métadonnées de la traçabilité des données tout au long des processus d’extraction, de sous-échantillonnage, de synchronisation, d’enrichissement et de détection de scènes. L’API de métadonnées sert à accéder aux mesures, à la traçabilité et aux données des scènes, ainsi qu’à rechercher l’emplacement de stockage des données. Par conséquent, l’API de métadonnées fait office de gestionnaire de couches de stockage. Elle répartit les données entre les comptes de stockage. Elle permet également aux développeurs d’utiliser une recherche basée sur les métadonnées pour obtenir des emplacements de données. Pour cette raison, le magasin de métadonnées est un composant centralisé qui offre une traçabilité dans le flux de données de la solution.

9. Azure Databricks et Azure Synapse Analytics sont utilisés pour se connecter à l’API de métadonnées, accéder à Data Lake Storage et effectuer des recherches sur les données.

Composants

• Data Box permet d’envoyer des téraoctets de données à l’intérieur et à l’extérieur d’Azure de manière rapide, économique et fiable. Dans cette solution, Data Box est utilisé pour transférer les données de véhicule collectées vers Azure via un opérateur régional.
• Les appareils Azure Stack Edge fournissent des fonctionnalités Azure dans les emplacements de périphérie. Le calcul, le stockage, la mise en réseau et l’apprentissage automatique avec accélération matérielle sont des exemples de fonctionnalités Azure.
• ExpressRoute étend un réseau local vers le cloud Microsoft via une connexion privée.
• Data Lake Storage stocke une grande quantité de données dans son format brut natif. Dans ce cas, Data Lake Storage stocke les données en fonction de phases, par exemple brut ou extraction.
• Data Factory est une solution serverless complètement managée pour la création et la planification de workflows ETL (extraction, transformation, chargement) et ELT (extraction, chargement, transformation). Ici, Data Factory effectue l’ETL via le calcul par lots et crée des workflows pilotés par les données pour orchestrer le déplacement et la transformation des données.
• Batch exécute des programmes de traitement par lots de calcul haute performance (HPC) en parallèle, efficacement et à grande échelle dans Azure. Cette solution utilise Batch pour exécuter des applications à grande échelle pour des tâches comme le data wrangling, le filtrage et la préparation des données, ainsi que l’extraction des métadonnées.
• Azure Cosmos DB est une base de données multimodèle distribuée à l’échelle mondiale. Ici, il stocke les résultats des métadonnées, comme les mesures stockées.
• Data Share partage les données avec les organisations partenaires avec une sécurité renforcée. Grâce au partage sur place, les fournisseurs de données peuvent partager des données où elles résident sans les copier ou prendre des instantanés. Dans cette solution, Data Share partage des données avec des sociétés d’étiquetage.
• Azure Databricks fournit un ensemble d’outils permettant de gérer des solutions de données de qualité entreprise à grande échelle. Cela est nécessaire pour les opérations de longue durée sur de grandes quantités de données de véhicule. Les ingénieurs données utilisent Azure Databricks comme banc d’essai analytique.
• Azure Synapse Analytics raccourcit le délai d’obtention d’analyses sur l’ensemble des entrepôts de données et des systèmes Big Data.
• Recherche cognitive Azure fournit des services de recherche dans le catalogue de données.
• App Service fournit un service d’application web basé sur une architecture serverless. Dans ce cas, App Service héberge l’API de métadonnées.
• Microsoft Purview assure la gouvernance des données entre les organisations.
• Azure Container Registry est un service qui crée un registre managé d’images conteneur. Cette solution utilise Container Registry pour stocker les conteneurs pour le traitement des rubriques.
• Application Insights est une extension d’Azure Monitor qui fournit des fonctionnalités de gestion des performances des applications. Dans ce scénario, Application Insights vous aide à générer l’observabilité de l’extraction de mesures. Vous pouvez utiliser Application Insights pour journaliser des événements personnalisés, des métriques personnalisées et d’autres informations pendant que la solution traite chaque mesure pour l’extraction. Vous pouvez également générer des requêtes sur Log Analytics pour obtenir des informations détaillées sur chaque mesure.

Détails du scénario

La conception d’une infrastructure DataOps robuste pour les véhicules autonomes est essentielle utiliser vos données, suivre leur traçabilité et les mettre à disposition dans l’ensemble de votre organisation. Sans un processus DataOps bien conçu, la quantité massive de données générées par les véhicules autonomes peut rapidement devenir insurmontable et difficile à gérer.

Quand vous implémentez une stratégie DataOps efficace, vous vous assurez que vos données sont correctement stockées, facilement accessibles et disposent d’une traçabilité claire. Vous facilitez également la gestion et l’analyse des données, ce qui permet de prendre des décisions plus éclairées et d’améliorer les performances des véhicules.

Un processus DataOps efficace permet de distribuer facilement les données dans votre organisation. Les différentes équipes peuvent ensuite accéder aux informations dont elles ont besoin pour optimiser leurs opérations. DataOps facilite la collaboration et le partage d’insights, ce qui permet d’améliorer l’efficacité globale de votre organisation.

Voici les défis courants pour les opérations de données dans le contexte des véhicules autonomes :

• Gestion du volume quotidien des données de mesure, en téraoctets ou en pétaoctets, provenant des véhicules de recherche et développement.
• Partage de données et collaboration entre plusieurs équipes et partenaires, par exemple, pour l’étiquetage, les annotations et les contrôles de la qualité.
• Traçabilité pour une pile de perception critique pour la sécurité qui capture le contrôle de version et la traçabilité des données de mesure.
• Découverte des métadonnées et des données pour améliorer la segmentation sémantique, la classification d’images et les modèles de détection d’objets.

Cette solution AvOps DataOps fournit de l’aide pour relever ces défis.

Cas d’usage potentiels

Cette solution est utile pour les fabricants d’équipements d’origine (OEM) automobiles, les fournisseurs de niveau 1 et les éditeurs de logiciels indépendants (ISV) qui développent des solutions pour la conduite automatisée.

Opérations de données fédérées

Dans une organisation qui implémente AVOps, plusieurs équipes contribuent à DataOps en raison de la complexité requise pour AVOps. Par exemple, une équipe peut être chargée de la collecte et de l’ingestion des données, et une autre de la gestion de la qualité des données lidar. Pour cette raison, il est important de prendre en compte les principes suivants d’une architecture de maillage des données pour DataOps :

• Décentralisation orientée domaine de la propriété et de l’architecture des données. Une équipe dédiée est responsable d’un domaine de données qui fournit des produits de données pour ce domaine, par exemple des jeux de données étiquetés.
• Données en tant que produit. Chaque domaine de données possède différentes zones sur des conteneurs de stockage implémentés par un lac de données. Il existe des zones destinées à une utilisation interne. Il existe également une zone qui contient des produits de données publiées pour d’autres domaines de données ou pour une utilisation externe afin d’éviter la duplication des données.
• Données en libre-service en tant que plateforme pour permettre des équipes de données autonomes orientées domaine.
• Gouvernance fédérée pour permettre l’interopérabilité et l’accès entre les domaines de données AVOps qui nécessitent un magasin de métadonnées centralisé et un catalogue de données. Par exemple, un domaine de données d’étiquetage peut avoir besoin d’accéder à un domaine de collecte de données.

Pour plus d’informations sur les implémentations de maillage des données, consultez l’article Analyse de niveau cloud.

Exemple de structure pour les domaines de données AVOps

Le tableau ci-dessous fournit quelques idées pour structurer les domaines de données AVOps :

Chaque domaine de données AVOps est configuré en fonction d’une structure de blueprint. Cette structure inclut Data Factory, Data Lake Storage, des bases de données, Batch et des runtimes Apache Spark par le biais d’Azure Databricks ou d’Azure Synapse Analytics.

Découverte des métadonnées et des données

Chaque domaine de données est décentralisé et gère individuellement ses produits de données AVOps correspondants. Pour la découverte des données centralisée et pour connaître l’emplacement des produits de données, deux composants sont nécessaires :

• Un magasin de métadonnées qui conserve les métadonnées relatives aux fichiers de mesure et aux flux de données traités, tels que les séquences vidéo. Ce composant rend les données détectables et traçables avec des annotations qui doivent être indexées, par exemple pour la recherche des métadonnées de fichiers sans étiquette. Par exemple, vous pouvez souhaiter que le magasin de métadonnées retourne toutes les images pour des numéros d’identification de véhicule (VIN) spécifiques ou des cadres images de piétons ou d’autres objets basés sur l’enrichissement.
• Un catalogue de données qui montre la traçabilité, les dépendances entre les domaines de données AVOps et les magasins de données impliqués dans la boucle de données AVOps. Microsoft Purview est un exemple de catalogue de données.

Vous pouvez utiliser Azure Data Explorer ou la Recherche cognitive Azure pour étendre un magasin de métadonnées basé sur Azure Cosmos DB. L’option choisie dépend du scénario final dont vous avez besoin pour la découverte des données. Utilisez la Recherche cognitive Azure pour bénéficier de fonctionnalités de recherche sémantique.

Le diagramme de modèle de métadonnées suivant montre un modèle de métadonnées unifié classique qui est utilisé sur plusieurs piliers de boucle de données AVOps :

Partage des données

Le partage de données est un scénario courant dans une boucle de données AVOps. Les utilisations incluent le partage de données entre les domaines de données et le partage externe, par exemple pour intégrer des partenaires d’étiquetage. Microsoft Purview fournit les fonctionnalités suivantes pour un partage de données efficace dans une boucle de données :

• Découverte des données et accès en libre service
• Partage de données sur place

Les formats recommandés pour l’échange de données d’étiquette incluent les jeux de données COCO (Common Objects in Context) et les jeux de données OpenLABEL AsAM (Association for Standardization of Automation and Measuring Systems).

Dans cette solution, les jeux de données étiquetés sont utilisés dans les processus MLOps pour créer des algorithmes spécialisés tels que des modèles de perception et de fusion de capteurs. Les algorithmes peuvent détecter des scènes et des objets dans un environnement, tels que la voiture qui change de voie, les routes bloquées, le trafic piétonnier, les feux de signalisation et les panneaux de signalisation.

Pipeline de données

Dans cette solution DataOps, le déplacement des données entre les différentes phases du pipeline de données est automatisé. Grâce à cette approche, le processus offre différents avantages : efficacité, scalabilité, cohérence, reproductibilité, adaptabilité et gestion des erreurs. Il améliore le processus de développement global, accélère la progression et prend en charge le déploiement sûr et efficace des technologies de conduite autonome.

Les sections suivantes décrivent comment implémenter le déplacement des données entre les phases et comment structurer vos comptes de stockage.

Structure de dossiers hiérarchique

Une structure de dossiers bien organisée est un composant essentiel d’un pipeline de données dans le développement de la conduite autonome. Une telle structure fournit une disposition systématique et facilement navigable des fichiers de données, ce qui facilite la gestion et la récupération efficaces des données.

Dans cette solution, les données du dossier raw présentent la structure hiérarchique suivante :

region/raw/<ID_mesure>/<ID_flux_données>/AAAA/MM/JJ

Les données du compte de stockage de la zone extraite utilisent une structure hiérarchique similaire :

region/extracted/<ID_mesure>/<ID_flux_données>/AAAA/MM/JJ

En utilisant des structures hiérarchiques similaires, vous pouvez tirer parti de la fonctionnalité d’espace de noms hiérarchique de Data Lake Storage. Les structures hiérarchiques permettent de créer un stockage d’objets évolutif et économique. Ces structures améliorent également l’efficacité de la recherche et de la récupération d’objets. Le partitionnement par année et par numéro VIN facilite la recherche d’images pertinentes provenant de véhicules spécifiques. Dans le lac de données, un conteneur de stockage est créé pour chaque capteur, tel qu’une caméra, un appareil GPS ou un capteur lidar ou radar.

Compte de stockage d’atterrissage vers compte de stockage brut

Un pipeline Data Factory est déclenché en fonction d’une planification. Une fois le pipeline déclenché, les données sont copiées du compte de stockage d’atterrissage vers le compte de stockage brut.

Le pipeline récupère tous les dossiers de mesures et effectue une itération au sein de ces dossiers. Avec chaque mesure, la solution effectue les activités suivantes :

1. Une fonction valide la mesure. La fonction récupère le fichier manifeste à partir du manifeste de mesure. Ensuite, elle vérifie si tous les fichiers de mesure MDF4, TDMS et rosbag pour la mesure actuelle existent dans le dossier de mesure. Si la validation réussit, la fonction passe à l’activité suivante. Si la validation échoue, la fonction ignore la mesure actuelle et passe au dossier de mesure suivant.

2. Un appel d’API web est effectué à une API qui crée une mesure, et la charge utile JSON du fichier JSON du manifeste de mesure est transmise à l’API. Si l’appel réussit, la réponse est analysée pour récupérer l’ID de mesure. Si l’appel échoue, la mesure est déplacée vers l’activité en erreur à des fins de gestion des erreurs.

   Notes

   Cette solution DataOps repose sur l’hypothèse que vous limitez le nombre de requêtes destinées au service d’application. Si votre solution peut créer un nombre indéterminé de requêtes, envisagez un modèle de limitation du débit.

3. Un appel d’API web est effectué à une API qui crée un flux de données en créant la charge utile JSON requise. Si l’appel réussit, la réponse est analysée pour récupérer l’ID de flux de données et l’emplacement du flux de données. Si l’appel échoue, la mesure est déplacée vers l’activité en erreur.

4. Un appel d’API web est effectué pour mettre à jour l’état du flux de données sur Start Copy. Si l’appel réussit, l’activité de copie copie les fichiers de mesure vers l’emplacement du flux de données. Si l’appel échoue, la mesure est déplacée vers l’activité en erreur.

5. Un pipeline Data Factory appelle Batch pour copier les fichiers de mesure du compte de stockage d’atterrissage vers le compte de stockage brut. Un module de copie d’une application orchestrateur crée un travail avec les tâches suivantes pour chaque mesure :

   • Copie des fichiers de mesure vers le compte de stockage brut.
   • Copie des fichiers de mesure vers un compte de stockage d’archive.
   • Suppression des fichiers de mesure du compte de stockage d’atterrissage.

   Notes

   Dans ces tâches, Batch utilise un pool orchestrateur et l’outil AzCopy pour copier et supprimer des données. AzCopy utilise des jetons de signature d’accès partagé (SAP) pour effectuer les tâches de copie ou de suppression. Les jetons SAP sont stockés dans un coffre de clés et sont référencés à l’aide des termes landingsaskey, archivesaskey et rawsaskey.

6. Un appel d’API web est effectué pour mettre à jour l’état du flux de données sur Copy Complete. Si l’appel réussit, la séquence passe à l’activité suivante. Si l’appel échoue, la mesure est déplacée vers l’activité en erreur.

7. Les fichiers de mesure sont déplacés du compte de stockage d’atterrissage vers une archive d’atterrissage. Cette activité peut réexécuter une mesure particulière en la redéplaçant vers le compte de stockage d’atterrissage par le biais d’un pipeline de copie hydrate. La gestion du cycle de vie est activée pour cette zone afin que les mesures effectuées dans cette zone soient automatiquement supprimées ou archivées.

8. Si une erreur se produit lors d’une mesure, celle-ci est déplacée vers une zone d’erreur. À partir de là, elle peut être déplacée vers le compte de stockage d’atterrissage pour être réexécutée. La gestion du cycle de vie peut également supprimer ou archiver automatiquement la mesure.

Notez les points suivants :

• Ces pipelines sont déclenchés en fonction d’une planification. Cette approche permet d’améliorer la traçabilité des exécutions de pipeline et d’éviter les exécutions inutiles.
• Chaque pipeline est configuré avec une valeur de concurrence de un pour s’assurer que toutes les exécutions précédentes se terminent avant le démarrage de l’exécution planifiée suivante.
• Chaque pipeline est configuré pour copier les mesures en parallèle. Par exemple, si une exécution planifiée récupère 10 mesures à copier, les étapes du pipeline peuvent être exécutées simultanément pour les dix mesures.
• Chaque pipeline est configuré pour générer une alerte dans Monitor si son exécution prend plus de temps que prévu.
• L’activité en erreur est implémentée dans les récits d’observabilité ultérieurs.
• La gestion du cycle de vie supprime automatiquement les mesures partielles, par exemple les mesures dont des fichiers rosbag sont manquants.

Conception de Batch

Toute la logique d’extraction est empaquetée dans différentes images conteneur, un conteneur étant prévu pour chaque processus d’extraction. Batch exécute les charges de travail de conteneur en parallèle quand il extrait des informations des fichiers de mesure.

Batch utilise un pool orchestrateur et un pool d’exécution pour traiter les charges de travail :

• Un pool orchestrateur contient des nœuds Linux sans prise en charge du runtime de conteneur. Le pool exécute du code Python qui utilise l’API Batch pour créer des travaux et des tâches pour le pool d’exécution. Ce pool supervise également ces tâches. Data Factory appelle le pool orchestrateur, qui orchestre les charges de travail de conteneur qui extraient les données.
• Un pool d’exécution contient des nœuds Linux avec des runtimes de conteneur pour prendre en charge les charges de travail de conteneur en cours d’exécution. Pour ce pool, les travaux et les tâches sont planifiés par le biais du pool orchestrateur. Toutes les images conteneur requises pour le traitement dans le pool d’exécution sont envoyées (push) à un registre de conteneurs à l’aide de JFrog. Le pool d’exécution est configuré pour se connecter à ce registre et tirer (pull) les images requises.

Les comptes de stockage dans lesquels les données sont lues et écrites sont montés via NFS 3.0 sur les nœuds Batch et les conteneurs qui s’exécutent sur les nœuds. Cette approche permet aux nœuds Batch et aux conteneurs de traiter rapidement les données sans avoir à télécharger les fichiers de données localement sur les nœuds Batch.

Appeler Batch à partir de Data Factory

Dans le pipeline d’extraction, le déclencheur transmet le chemin du fichier de métadonnées et le chemin du flux de données brutes dans les paramètres du pipeline. Data Factory utilise une activité de recherche pour analyser le JSON à partir du fichier manifeste. L’ID de flux de données brutes peut être extrait du chemin du flux de données brutes en analysant la variable de pipeline.

Data Factory appelle une API pour créer un flux de données. L’API retourne le chemin du flux de données extrait. Le chemin extrait est ajouté à l’objet actuel et Data Factory appelle Batch via une activité personnalisée en transmettant l’objet actuel, après avoir ajouté le chemin du flux de données extrait :

{
"measurementId":"210b1ba7-9184-4840-a1c8-eb£397b7c686",
"rawDataStreamPath":"raw/2022/09/30/KA123456/210b1ba7-9184-4840-
alc8-ebf39767c68b/57472a44-0886-475-865a-ca32{c851207",
"extractedDatastreamPath":"extracted/2022/09/30/KA123456
/210bIba7-9184-4840-a1c8-ebf39767c68b/87404c9-0549-4a18-93ff-d1cc55£d8b78",
"extractedDataStreamId":"87404bc9-0549-4a18-93ff-d1cc55fd8b78"
}

Processus d’extraction progressive

1. Data Factory planifie un travail avec une tâche pour le pool orchestrateur afin de traiter une mesure à des fins d’extraction. Data Factory transmet les informations suivantes au pool orchestrateur :

   • L’ID de la mesure
   • L’emplacement des fichiers de mesure de type MDF4, TDMS ou rosbag qui doivent être extraits
   • Le chemin de destination de l’emplacement de stockage du contenu extrait
   • L’ID du flux de données extrait

2. Le pool orchestrateur appelle une API pour mettre à jour le flux de données et définir son état sur Processing.

3. Le pool orchestrateur crée un travail pour chaque fichier de mesure qui fait partie de la mesure. Chaque travail contient les tâches suivantes :

   Tâche	Objectif	Notes
   Validation	Confirme que les données peuvent être extraites du fichier de mesure.	Toutes les autres tâches dépendent de cette tâche.
   Traitement des métadonnées	Dérive les métadonnées du fichier de mesure et enrichit les métadonnées du fichier à l’aide d’une API pour mettre à jour les métadonnées du fichier.
   Traitement de StructuredTopics	Extrait les données structurées d’un fichier de mesure donné.	La liste des rubriques desquelles les données structurées doivent être extraites est transmise en tant qu’objet de configuration.
   Traitement de CameraTopics	Extrait les données d’image d’un fichier de mesure donné.	La liste des rubriques desquelles les images doivent être extraites est transmise en tant qu’objet de configuration.
   Traitement de LidarTopics	Extrait les données de lidar d’un fichier de mesure donné.	La liste des rubriques desquelles les données de lidar doivent être extraites est transmise en tant qu’objet de configuration.
   Traitement de CANTopics	Extrait les données CAN (Controller Area Network) à partir d’un fichier de mesure donné.	La liste des rubriques desquelles les données doivent être extraites est transmise en tant qu’objet de configuration.

4. Le pool orchestrateur surveille l’état d’avancement de chaque tâche. Une fois tous les travaux terminés pour tous les fichiers de mesure, le pool appelle une API pour mettre à jour le flux de données et définir son état sur Completed.

5. L’orchestrateur se ferme normalement.

   Notes

   Chaque tâche est une image conteneur distincte qui a une logique correctement définie pour son objectif. Les tâches acceptent les objets de configuration comme entrée. Par exemple, l’entrée spécifie l’emplacement d’écriture de la sortie et le fichier de mesure à traiter. Un tableau de types de rubriques, tels que sensor_msgs/Image, est un autre exemple d’entrée. Étant donné que toutes les autres tâches dépendent de la tâche de validation, une tâche dépendante est créée pour celle-ci. Toutes les autres tâches peuvent être traitées indépendamment et peuvent s’exécuter en parallèle.

Considérations

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

Fiabilité

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

• Dans votre solution, envisagez d’utiliser des zones de disponibilité Azure, qui sont des emplacements physiques uniques au sein d’une même région Azure.
• Planifiez la récupération d’urgence et le basculement de compte.

Sécurité

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

Il est important de comprendre la répartition des responsabilités entre un OEM automobile et Microsoft. Dans un 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. Les couches Azure PaaS (platform as a service) fournissent une sécurité intégrée sur la pile physique, y compris le système d’exploitation. Vous pouvez ajouter les fonctionnalités suivantes aux composants de sécurité d’infrastructure existants :

• Gestion des identités et des accès qui utilise des identités Microsoft Entra et des stratégies d’Accès conditionnel Microsoft Entra.
• Gouvernance de l’infrastructure qui utilise Azure Policy.
• Gouvernance des données qui utilise Microsoft Purview.
• Chiffrement des données au repos utilisant les services de stockage et de base de données natifs d’Azure. Pour plus d’informations, consultez l’article Considérations relatives à la protection des données.
• Protection des clés de chiffrement et des secrets. Utilisez Azure Key Vault à cet effet.

Optimisation des coûts

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

Le coût d’exploitation est l’une des principales préoccupations des OEM et des fournisseurs de niveau 1 qui exploitent DataOps pour les véhicules automatisés. Cette solution utilise les pratiques suivantes pour optimiser les coûts :

• Exploitation des différentes options offertes par Azure pour l’hébergement du code d’application. Cette solution utilise App Service et Batch. Pour obtenir de l’aide pour sélectionner le service approprié pour votre déploiement, consultez l’article Choisir un service de calcul Azure.
• Utilisation du partage de données sur place Stockage Azure.
• Optimisation des coûts à l’aide de la gestion du cycle de vie.
• Réduction des coûts sur App Service à l’aide d’instances réservées.

Contributeurs

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

Auteurs principaux :

• Ryan Matsumura | Responsable de programme senior
• Jochen Schroeer | Architecte principal (Service Line Mobility)
• Brij Singh | Ingénieur logiciel principal
• Ginette Vellera | Responsable senior de l’ingénierie logicielle

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

Étapes suivantes

• Présentation d’Azure Batch
• Présentation d’Azure Data Factory
• Introduction à Azure Data Lake Storage Gen2
• Bienvenue dans Azure Cosmos DB
• Vue d'ensemble d'App Service
• Qu’est-ce qu’Azure Data Share ?
• Qu’est-ce qu’Azure Data Box ?
• Documentation Azure Stack Edge
• Qu’est-ce qu’Azure ExpressRoute ?
• Qu'est-ce que Microsoft Azure Machine Learning ?
• Présentation d’Azure Databricks
• Présentation d’Azure Synapse Analytics
• Vue d’ensemble d’Azure Monitor
• Fichiers journaux ROS (rosbags)
• Plateforme d’opérations de données à grande échelle pour les véhicules autonomes

Ressources associées

Pour plus d’informations sur le développement de ValOps pour un système de conduite autonome, consultez la section :

Les rubriques suivantes peuvent également vous intéresser :

• Guide de conception AVOps
• Analytique données pour les flottes de tests automobiles
• Principaux composants pour les environnements de simulation de conduite autonome
• Architecture de référence de la messagerie, des données et de l’analytique automobiles