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

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

Apache®, Apache Sparket Apache Parquet sont des marques déposées ou des marques de commerce de La Fondation Apache Software aux États-Unis et/ou dans d’autres pays. Aucune approbation par Apache Software Foundation n’est implicite par l’utilisation de ces marques.

Architecture

Télécharger 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, la télémétrie des véhicules et le radar, les capteurs ultrasoniques et lidar. Les enregistreurs de données du véhicule stockent les données de mesure sur les appareils de stockage des enregistreurs 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 tel qu’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 s’affichent dans Azure Data Lake Storage : Format de données de mesure version 4 (MDF4), systèmes de gestion des données techniques (TDMS) et rosbag. Les données chargées entrent un compte de stockage dédié appelé atterrissage désigné pour la réception et la validation des 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 :

   • Effectue un contrôle de 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é passent à l’étape suivante. Azure App Service est utilisé pour exécuter le code de vérification de la qualité. Les données jugées incomplètes sont archivées pour un traitement ultérieur.
   • Pour le suivi de traçabilité, appelle 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 brut.
   • Copie les données dans un compte de stockage appelé brut dans Data Lake Storage.
   • Appelle 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.
   • Archive les mesures et les supprime du compte de stockage d’atterrissage.

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

   • Batch lit les données 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 les fichiers de la zone brute peuvent chacun être de plus de 2 Go de taille, les fonctions d’extraction de traitement parallèle sont exécutées sur chaque fichier. Ces fonctions extraient le traitement des images, le lidar, le radar et les données GPS. Ils effectuent également un traitement des métadonnées. Data Factory et Batch offrent un moyen d’effectuer un parallélisme de manière évolutive.
   • Les données sont réduites 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é qui synchronise les données pour créer un jeu de données valide. L’algorithme de synchronisation s’exécute sur Batch.

5. Un pipeline Data Factory s’exécute pour enrichir les données. Parmi les exemples d’améliorations, citons la télémétrie, les données d’enregistreur de véhicules et d’autres données, telles que la météo, la carte ou les données d’objet. Les données enrichies permettent aux scientifiques des données d’obtenir des insights qu’ils peuvent utiliser dans le développement d’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. Les partenaires tiers effectuent des étiquetages manuels ou automatiques. Les données sont partagées avec les partenaires tiers via Azure Data Share et sont intégrées à Microsoft Purview. Data Share utilise un compte de stockage dédié nommé étiqueté dans Data Lake Storage pour retourner les données étiquetées à l’organisation.

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

8. Outre les métadonnées pour les données d’enrichissement et les scènes détectées, le magasin de métadonnées dans Azure Cosmos DB stocke les métadonnées pour les mesures, telles que les données de lecteur. Ce magasin contient également des métadonnées pour la traçabilité des données au fur et à mesure qu’elles passent par les processus d’extraction, d’échantillonnage, de synchronisation, d’enrichissement et de détection de scène. L’API de métadonnées est utilisée pour accéder aux mesures, à la traçabilité et aux données de scène et à rechercher où les données sont stockées. Par conséquent, l’API de métadonnées sert de gestionnaire de couches de stockage. Il répartit les données entre les comptes de stockage. Il fournit également aux développeurs un moyen d’utiliser une recherche basée sur des 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 la traçabilité et la 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 et accéder à Data Lake Storage et effectuer des recherches sur les données.

Composants

• Data Box offre un moyen d’envoyer des téraoctets de données vers et hors d’Azure d’une manière rapide, économique et fiable. Dans cette solution, Data Box est utilisé pour transférer des données de véhicule collectées vers Azure via un opérateur régional.
• appareils Azure Stack Edge fournissent des fonctionnalités Azure dans des emplacements de périphérie. Parmi les exemples de fonctionnalités Azure, citons le calcul, le stockage, la mise en réseau et le Machine Learning à accélération matérielle.
• ExpressRoute étend un réseau local dans le cloud Microsoft via une connexion privée.
• Data Lake Storage contient une grande quantité de données dans son format brut natif. Dans ce cas, Data Lake Storage stocke les données en fonction des étapes, par exemple, brutes ou extraites.
• Data Factory est une solution serverless entièrement managée pour créer et planifier des flux de travail d’extraction, de transformation, de chargement (ETL) et d’extraction, de chargement, de transformation (ELT). Ici, Data Factory effectue etL via de calcul par lots et crée des flux de travail pilotés par les données pour orchestrer le déplacement des données et transformer des données.
• Batch exécute efficacement des travaux de traitement par lots de calcul parallèle et haute performance (HPC) à grande échelle dans Azure. Cette solution utilise Batch pour exécuter des applications à grande échelle pour des tâches telles que le wrangling de données, le filtrage et la préparation des données, et l’extraction de 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 des données avec des organisations partenaires avec une sécurité renforcée. En utilisant le partage sur place, les fournisseurs de données peuvent partager des données où elles résident sans copier les données ou prendre des instantanés. Dans cette solution, Data Share partage des données avec des entreprises d’étiquetage.
• Azure Databricks fournit un ensemble d’outils permettant de gérer des solutions de données de qualité entreprise à grande échelle. Il est nécessaire pour les opérations de longue durée sur de grandes quantités de données sur les véhicules. Les ingénieurs données utilisent Azure Databricks comme workbench d’analytique.
• Azure Synapse Analytics réduit le temps d’insights sur les entrepôts de données et les systèmes Big Data.
• Recherche cognitive Azure fournit des services de recherche de catalogue de données.
• app Service fournit un app Service web serverless. Dans ce cas, App Service héberge l’API de métadonnées.
• Microsoft Purview fournit une gouvernance des données au sein des organisations.
• Azure Container Registry est un service qui crée un registre managé d’images conteneur. Cette solution utilise Container Registry pour stocker des conteneurs pour les rubriques de traitement.
• Application Insights est une extension de Azure Monitor qui fournit la gestion des performances des applications. Dans ce scénario, Application Insights vous aide à créer une observabilité autour de l’extraction de mesures : vous pouvez utiliser Application Insights pour consigner 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 créer 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 pour utiliser vos données, tracer sa traçabilité et la rendre disponible dans toute votre organisation. Sans processus DataOps bien conçu, la quantité massive de données générées par les véhicules autonomes peut rapidement devenir écrasante et difficile à gérer.

Lorsque 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 des données au sein de votre organisation. 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.

Les défis typiques liés aux opérations de données dans le contexte des véhicules autonomes sont les suivants :

• Gestion du volume quotidien de données de mesure à l’échelle des téraoctets ou des pétaoctets des véhicules de recherche et de développement.
• Partage et collaboration de données entre plusieurs équipes et partenaires, par exemple, pour l’étiquetage, les annotations et les vérifications de qualité.
• Traçabilité et traçabilité pour une pile de perception critique de sécurité qui capture le contrôle de version et la traçabilité des données de mesure.
• Métadonnées et découverte de 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 des conseils sur la façon de résoudre ces défis.

Cas d’usage potentiels

Cette solution bénéficie aux fabricants d’équipement d’origine automobile ( OEM), aux fournisseurs de niveau 1 et aux é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 de données et de l’ingestion des données. Une autre équipe peut être responsable de la gestion de la qualité des données des données lidar. Pour cette raison, les principes suivants d’une architecture de maillage de données sont importants à prendre en compte 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 dispose de différentes zones sur les conteneurs de stockage implémentés par le lac de données. Il existe des zones pour l’utilisation interne. Il existe également une zone qui contient des produits de données publiés pour d’autres domaines de données ou une utilisation externe afin d’éviter la duplication des données.
• Les données en libre-service en tant que plateforme pour permettre aux é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 de données, consultez d’analytique à l’échelle du cloud.

Exemple de structure pour les domaines de données AVOps

Le tableau suivant 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, bases de données, Batch et runtimes Apache Spark via Azure Databricks ou 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 centralisée des données et pour savoir où se trouvent les produits de données, deux composants sont requis :

• 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 traceables avec des annotations qui doivent être indexées, par exemple pour rechercher les métadonnées des fichiers sans étiquette. Par exemple, vous souhaiterez peut-être que le magasin de métadonnées retourne toutes les trames pour des numéros d’identification de véhicules spécifiques (VIN) ou des cadres avec des piétons ou d’autres objets basés sur l’enrichissement.
• 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. Un exemple de catalogue de données est Microsoft Purview.

Vous pouvez utiliser Azure Data Explorer ou Recherche cognitive Azure pour étendre un magasin de métadonnées basé sur Azure Cosmos DB. Votre sélection dépend du scénario final dont vous avez besoin pour la découverte de données. Utilisez recherche cognitive Azure pour les 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 utilisé dans plusieurs piliers de boucle de données AVOps :

Partage de 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 de données en libre-service et accès aux
• partage de données sur place

Les formats recommandés pour l’échange de données d’étiquette incluent objets communs dans des jeux de données de contexte (COCO) et Association pour la normalisation des systèmes d’automatisation et de mesure (ASAM) OpenLABEL.

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

Pipeline de données

Dans cette solution DataOps, le déplacement des données entre différentes étapes du pipeline de données est automatisé. Grâce à cette approche, le processus offre des avantages d’efficacité, d’évolutivité, de cohérence, de reproductibilité, d’adaptabilité et de 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 étapes et la façon dont vous devez structurer vos comptes de stockage.

Structure de dossiers hiérarchiques

Une structure de dossiers bien organisée est un composant essentiel d’un pipeline de données dans le développement 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 brut ont la structure hiérarchique suivante :

region/raw/<measurement-ID>/<data-stream-ID>/AAAA/MM/DD

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

region/extracted/<measurement-ID>/<data-stream-ID>/AAAA/MM/DD

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 vin facilite la recherche d’images pertinentes à partir 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.

Atterrissage du compte de stockage vers le 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 mesure et effectue une itération dans 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, la fonction 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é d’erreur pour la gestion des erreurs.

   Note

   Cette solution DataOps repose sur l’hypothèse que vous limitez le nombre de requêtes au service d’application. Si votre solution peut faire un nombre indéterminé de requêtes, envisagez un modèle de limitation de 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 du 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é d’erreur.

4. Un appel d’API web est effectué pour mettre à jour l’état du flux de données vers 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é d’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 orchestrator crée un travail avec les tâches suivantes pour chaque mesure :

   • Copiez les fichiers de mesure dans le compte de stockage brut.
   • Copiez les fichiers de mesure dans un compte de stockage d’archivage.
   • Supprimez les fichiers de mesure du compte de stockage d’atterrissage.

   Note

   Dans ces tâches, Batch utilise un pool d’orchestrateurs et l’outil AzCopy pour copier et supprimer des données. AzCopy utilise des jetons SAS pour effectuer des 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, archivesaskeyet rawsaskey.

6. Un appel d’API web est effectué pour mettre à jour l’état du flux de données vers 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é d’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 déplaçant vers le compte de stockage d’atterrissage via un pipeline de copie hydraté. La gestion du cycle de vie est activée pour cette zone afin que les mesures de cette zone soient automatiquement supprimées ou archivées.

8. Si une erreur se produit avec une mesure, la mesure est déplacée vers une zone d’erreur. À partir de là, il peut être déplacé vers le compte de stockage d’atterrissage à réexécuter. 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 d’accès concurrentiel d’une pour vous 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 des mesures en parallèle. Par exemple, si une exécution planifiée récupère jusqu’à 10 mesures à copier, les étapes du pipeline peuvent être exécutées simultanément pour toutes les dix mesures.
• Chaque pipeline est configuré pour générer une alerte dans Monitor si le pipeline prend plus de temps que prévu.
• L’activité d’erreur est implémentée dans des récits d’observabilité ultérieurs.
• La gestion du cycle de vie supprime automatiquement les mesures partielles, par exemple, les mesures avec des fichiers rosbag manquants.

Conception par lots

Toutes les logiques d’extraction sont empaquetées dans des images conteneur différentes, avec un conteneur pour chaque processus d’extraction. Batch exécute les charges de travail de conteneur en parallèle lorsqu’il extrait des informations à partir de fichiers de mesure.

Batch utilise un pool d’orchestrateurs et un pool d’exécution pour le traitement des charges de travail :

• Un pool d’orchestrateurs dispose de 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écutions. Ce pool surveille également ces tâches. Data Factory appelle le pool d’orchestrateurs, qui orchestre les charges de travail de conteneur qui extraient des données.
• Un pool d’exécutions a des nœuds Linux avec des runtimes de conteneur pour prendre en charge l’exécution de charges de travail de conteneur. Pour ce pool, les travaux et les tâches sont planifiés via le pool d’orchestrateurs. 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écutions est configuré pour se connecter à ce Registre et extraire les images requises.

Les comptes de stockage à partir 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 de traitement par lots 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 bruts dans les paramètres du pipeline. Data Factory utilise une activité de recherche pour analyser le code JSON à partir du fichier manifeste. L’ID de flux de données bruts peut être extrait du chemin du flux de données brut en analysant la variable de pipeline.

Data Factory appelle une API pour créer un flux de données. L’API retourne le chemin d’accès du flux de données extrait. Le chemin d’accès extrait est ajouté à l’objet actuel et Data Factory appelle Batch via une activité personnalisée en passant 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 pas à pas

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

   • ID de mesure
   • Emplacement des fichiers de mesure de type MDF4, TDMS ou rosbag qui doivent être extraits
   • Chemin d’accès de destination de l’emplacement de stockage du contenu extrait
   • ID de flux de données extrait

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

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

   Tâche	But	Note
   Validation	Valide que les données peuvent être extraites du fichier de mesure.	Toutes les autres tâches dépendent de cette tâche.
   Traiter les 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.
   Processus StructuredTopics	Extrait des données structurées à partir d’un fichier de mesure donné.	La liste des rubriques à partir de laquelle extraire des données structurées est passée en tant qu’objet de configuration.
   Processus CameraTopics	Extrait les données d’image d’un fichier de mesure donné.	La liste des rubriques à partir de laquelle extraire des images est passée en tant qu’objet de configuration.
   Processus LidarTopics	Extrait les données lidar d’un fichier de mesure donné.	La liste des rubriques à partir de laquelle extraire des données lidar est passée en tant qu’objet de configuration.
   Processus CANTopics	Extrait les données de réseau de zone du contrôleur (CAN) à partir d’un fichier de mesure donné.	La liste des rubriques à partir de laquelle extraire des données est passée en tant qu’objet de configuration.

4. Le pool d’orchestrateurs surveille la progression 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 sort normalement.

   Note

   Chaque tâche est une image conteneur distincte qui a une logique qui est correctement définie à son usage. Les tâches acceptent les objets de configuration comme entrée. Par exemple, l’entrée spécifie où écrire 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 elle. 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 d’ensembles guidants qui peuvent être utilisés pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Fiabilité

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

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

Sécurité

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

Il est important de comprendre la division de responsabilité 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 PaaS (Platform as a Service) Azure 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 les identités Microsoft Entra et 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 qui utilise le stockage Azure natif et les services de base de données. Pour plus d’informations, consultez 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.

Une préoccupation clé pour les oem et les fournisseurs de niveau 1 qui exploitent DataOps pour les véhicules automatisés est le coût d’exploitation. Cette solution utilise les pratiques suivantes pour optimiser les coûts :

• Tirer parti des différentes options offertes par Azure pour l’hébergement de code d’application. Cette solution utilise App Service et Batch. Pour obtenir des conseils sur la façon de choisir le service approprié pour votre déploiement, consultez Choisir un service de calcul Azure.
• Utilisation partage de données sur place du stockage Azure.
• Optimisation des coûts à l’aide de gestion du cycle de vie.
• Économiser 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 du programme senior
• Jochen Schroeer | Architecte principal (Mobilité de ligne de service)
• Brij Singh | Ingénieur logiciel principal
• Ginette Vellera | Senior Software Engineering Lead

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

Étapes suivantes

• Qu’est-ce qu’Azure Batch ?
• Qu’est-ce qu’Azure Data Factory ?
• Présentation d’Azure Data Lake Storage Gen2
• bienvenue dans le 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 qu’Azure Machine Learning ?
• Qu’est-ce qu’Azure Databricks ?
• Qu’est-ce qu’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 :

Vous pouvez également vous intéresser à ces articles connexes :

• guide de conception AVOps
• Analyse des données pour les flottes d’essais automobiles
• blocs de construction pour les environnements de simulation autonomes
• messagerie automobile, architecture de référence des données & analytics