L'exemple de charge de travail présenté ci-dessous illustre la création d'une simulation qui s'exécute automatiquement et évalue le fonctionnement du véhicule simulé via un pipeline Azure DevOps. Ce pipeline s’exécute chaque fois qu’un ingénieur vérifie une nouvelle version du code source de l’exemple de fonction ou de son environnement de simulation.
Architecture
Téléchargez un fichier Visio de cette architecture.
Couche d'entrée utilisateur
Le développeur interagit uniquement avec cette couche. Celle-ci contient la station de travail du développeur (dans notre étendue, il s'agit d'une machine virtuelle Azure) et le fichier de spécification décrivant l'environnement de simulation.
Couche Orchestration
Au sens large, le terme « orchestration » s’applique à certains problèmes qui sont résolus de manière triviale ; d’autres problèmes sont beaucoup plus complexes. Par exemple, de nombreux outils permettent de résoudre le problème « d’orchestration » de la création, du monitoring et de la destruction des conteneurs et des machines virtuelles. L’API Azure elle-même est un « orchestrateur » suffisant pour cela.
Workflow
Toutefois, il est important de décomposer la boîte noire de « l’orchestration » en plus petits composants.
API de simulation : cette API reçoit un fichier de spécification et constitue un point d'entrée pour contrôler les environnements de simulation et les simulations au niveau de la couche Orchestration.
Interpréteur : ce composant convertit le fichier de spécification en structure logique pour le gestionnaire de simulation.
Gestionnaire de simulation : machine à états qui convertit l'objet logique de l'environnement de simulation en états et actions souhaités pour une utilisation par d'autres composants. Il s'agit du composant qui déclenche la génération, l'exécution et la désactivation de la simulation. Il gère également les dépendances internes et les modes d'échec.
Planificateur : ce composant attribue des blocs de construction aux ressources de l'infrastructure et les démarre au sein de celle-ci. Il tient compte des conditions requises en termes de matériel et d'accès, des ressources disponibles et des limites de ressources.
Gestionnaire d'environnement : ce composant surveille l'infrastructure sous-jacente et répond aux problèmes, par exemple lorsqu'un hôte de conteneur tombe en panne.
Gestionnaire de réseau : ce composant gère les réseaux et le routage pour les environnements de simulation. Chaque environnement doit résider dans un environnement réseau isolé, avec des blocs de construction isolés recevant des connexions entrantes pour l'interactivité. Ce composant sera également utilisé pour résoudre les blocs de construction au sein d'une simulation (par exemple, via un DNS interne).
Gestionnaire d’accès : ce composant reflète l’autorisation/authentification Microsoft Entra ID dans le reste du système.
Configuration Manager : ce composant agit comme un mécanisme de stockage permanent pour l'état de l'infrastructure et des environnements de simulation.
Abstraction d'infrastructure : couche d'abstraction qui convertit les commandes génériques en commandes d'API Azure spécifiques pour les conteneurs par opposition aux machines virtuelles.
Gestionnaire de stockage : ce composant gère l'approvisionnement et l'attachement du stockage pour les environnements de simulation (par exemple, les périphériques racine des machines virtuelles ou les volumes attachés aux conteneurs).
Moniteur de ressources : ce composant supervise l’utilisation des ressources au niveau de l’infrastructure dans une base de données de séries chronologiques, pour une exportation vers le système de monitoring principal de la plateforme ADP.
Gestionnaire de journaux : ce composant agrège les journaux à partir des blocs de construction pour permettre aux utilisateurs de les examiner. Il exporte également les journaux vers la fonctionnalité de journalisation principale de la plateforme ADP.
La couche Orchestration est le point central de cet exemple de charge de travail.
Couche Infrastructure de simulation
Cette couche représente tous les environnements de simulation en cours d'exécution.
Environnement de simulation : la combinaison des blocs de construction définis par le fichier de définitions et les paramètres est créée ici, en appliquant un isolement réseau par rapport aux autres environnements de simulation.
Contrat des blocs de construction : norme écrite qui définit la façon dont tous les blocs de construction envoient les résultats, les erreurs et l'état à la couche Orchestration.
Pipeline des blocs de construction : cette zone gère la création et le stockage des blocs de construction.
Référentiel des blocs de construction : il s'agit du système de stockage et de récupération des images des blocs de construction, comme un registre de conteneurs et/ou une galerie d'images Azure.
Fabrique de blocs de construction : pipeline d'intégration et de livraison continues (CI/CD) qui crée des images de blocs de construction à l'aide de packages de composants immuables et vérifiables (par exemple, dpkg ou APT) dans un langage de configuration déclaratif (par exemple, Chef ou Ansible).
Couche Stockage
Cette couche stocke de manière durable et accessible les résultats de la simulation. Elle relève principalement de la responsabilité de l’équipe chargée du flux de travail Lac de données de la plateforme de développement d’applications mobiles (MADP), bien que vos résultats doivent être gérables par cette équipe.
Interface de stockage : interface qui permet aux utilisateurs d'utiliser le stockage des résultats de simulation. Elle fonctionne en étroite collaboration avec le composant d'orchestration Gestionnaire de stockage présenté ci-dessus, ou pourrait être supplantée par celui-ci.
Stockage : mécanisme de stockage utilisé pour enregistrer les résultats de simulation (par exemple, ressources Stockage Blob Azure ou Stockage sur disque Azure).
Components
Les machines virtuelles Azure fournissent des ressources informatiques évolutives à la demande qui vous donnent la flexibilité de la virtualisation sans devoir acheter ni maintenir le matériel physique.
Le Réseau virtuel Azure est le composant fondamental de votre réseau privé dans Azure. Le Réseau virtuel Azure permet à de nombreux types de ressources Azure, telles que les machines virtuelles Azure, de communiquer de manière sécurisée entre elles, avec Internet et avec des réseaux locaux.
Azure Container Instances offre le moyen le plus rapide et le plus simple d'exécuter un conteneur dans Azure, sans avoir à gérer de machines virtuelles et sans devoir adopter un service de niveau supérieur.
Azure Container Registry est un service de registre Docker managé privé, qui est basé sur le registre open source Docker 2.0. Vous pouvez utiliser des registres de conteneurs Azure avec vos pipelines de développement et de déploiement existants, ou utiliser Azure Container Registry Tasks pour créer des images conteneur dans Azure. Créez des builds à la demande ou des builds entièrement automatisés avec des déclencheurs, tels que des validations du code source et des mises à jour d’images de base.
Azure Pipelines fait partie des services Azure DevOps et permet d'exécuter des builds, des tests et des déploiements automatisés. Vous pouvez également utiliser des solutions CI/CD tierces telles que Jenkins.
Microsoft Entra ID est le service cloud de gestion des identités et des accès qui authentifie les utilisateurs, les services et les applications.
Stockage Azure offre une solution de stockage cloud durable, hautement disponible et extrêmement évolutive. Ce service propose des capacités de stockage d'objets, de fichiers, de disques, de files d'attente et de tables.
Azure Monitor collecte la télémétrie de surveillance à partir de diverses sources locales et Azure. Ce service agrège et stocke les données de télémétrie dans un magasin de journaux qui est optimisé en termes de coût et de performances.
Autres solutions
Cette architecture utilise des machines virtuelles et des conteneurs pour déployer les différents outils et services. Vous pouvez également utiliser Azure Kubernetes Services (AKS). AKS offre une solution Kubernetes serverless, une expérience d'intégration et de livraison continues (CI/CD), ainsi qu'une sécurité et une gouvernance de niveau entreprise.
Le mécanisme de stockage utilisé pour enregistrer les résultats de simulation dans cette architecture repose sur les services Stockage Blob Azure ou Stockage sur disque Azure. En guise d’alternative pour les charges de travail plus importantes, vous pouvez également vous tourner vers les solutions de données et d’analytique à grande échelle d’Azure afin de stocker et d’analyser les données.
Pensez aussi à utiliser Azure Monitor pour analyser et optimiser les performances de votre infrastructure, et pour superviser et diagnostiquer les problèmes de réseau sans vous connecter à vos machines virtuelles.
Détails du scénario
Pour évaluer les capacités de conduite autonome, les ingénieurs doivent simuler le comportement des véhicules qui les utilisent. Examinez l'exemple de scénario de conduite suivant :
Un véhicule d'essai roule de manière autonome à 130 km/h sur la voie de droite d'une autoroute à trois voies. Un camion roulant à 90 km/h sur la même voie et dans le même sens se trouve à 200 mètres devant lui. Il n'y a aucun véhicule sur la voie du milieu. Les panneaux de signalisation routière et les marquages au sol sont visibles, le soleil brille perpendiculairement au véhicule et la route est sèche.
L’action consistant à tester le comportement d’un véhicule à l’aide d’un scénario de ce type s’appelle une exécution de simulation. Dans le scénario ci-dessus, le comportement attendu du véhicule utilisé pour la simulation est de dépasser confortablement le camion sans provoquer d’accident et sans enfreindre le code de la route. En exécutant une simulation pour chaque nouvelle version d'une fonction de conduite autonome, les ingénieurs testent la nouvelle version pour déterminer si elle présente toujours le comportement attendu.
Pour effectuer une simulation, les ingénieurs utilisent généralement un ensemble d'applications logicielles. Il peut s'agir d'applications telles que Virtual Test Drive (VTD), Time Partition Testing (TPT), Avionics Development System 2G (ADS2) et Automotive Data and Time-Triggered Framework (ADTF), qui communiquent toutes entre elles selon leurs configurations spécifiques afin de tester une fonction de conduite autonome donnée, comme la conduite sur autoroute. Le déploiement de cet ensemble d’outils logiciels et de leurs configurations sur des machines physiques et/ou virtuelles localement et/ou dans le cloud est désigné sous le nom d’environnement de simulation.
Pour garantir la validité des résultats des tests générés par chacune des simulations que vous effectuez, vous devez veiller à ce que la simulation démarre dans un nouvel environnement de simulation défini sur son état initial.
Chaque équipe en charge d'un aspect particulier de la conduite autonome a besoin d'un ensemble distinct d'applications dans son environnement de simulation, avec une configuration spécifique. En présence de nombreuses équipes, plusieurs environnements de simulation différents seront également nécessaires. Par exemple, pour évaluer un capteur LIDAR, vous aurez besoin d’une simulation d’objet à très haute résolution, mais pas d’autres pilotes, marquages ni autres caractéristiques. Bien que chaque environnement soit unique, les applications utilisées se recoupent. Par exemple, beaucoup d'équipes utilisent VTD dans différents environnements de simulation.
Une simulation peut être réalisée dans un environnement de simulation composé d’unités réutilisables, encapsulées et évaluées indépendamment les unes des autres. Ces unités sont utilisées comme « blocs de construction » pour la création automatique et à la demande d’environnements de simulation dans le cloud Azure. Ces environnements de simulation sont également appelés « plateformes de conduite automatisée (ADP) ».
Cas d’usage potentiels
Cette solution est idéale pour les secteurs de l’automobile et des transports. Utilisations courantes de cette charge de travail :
Automatisation des tests de conduite.
Prototypage, développement, intégration, test, validation et vérification des systèmes de contrôle dans l'industrie automobile.
Enregistrement des données du véhicule à des fins de visualisation.
Simulation de scénarios de conduite complexes dans l'industrie automobile.
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.
Disponibilité et résilience
Pensez à déployer des machines virtuelles dans des groupes à haute disponibilité ou des zones de disponibilité pour protéger les applications contre des événements de maintenance planifiée et des interruptions non planifiées.
Un groupe à haute disponibilité est un regroupement logique de machines virtuelles qui permet à Azure de comprendre comment votre application est conçue, afin de garantir la redondance et la disponibilité.
Les zones de disponibilité constituent, au sein des régions Azure, des emplacements physiques uniques qui contribuent à protéger les machines virtuelles, les applications et les données contre les défaillances des centres de données. Chaque zone se compose d’un ou de plusieurs centres de données. Les machines virtuelles et les applications situées dans ces zones peuvent rester disponibles même en cas de défaillance physique dans un centre de données.
Extensibilité
Vous pouvez procéder à la mise à l'échelle des machines virtuelles Azure manuellement ou à l'aide des fonctionnalités de mise à l'échelle automatique.
Pour les déploiements de conteneurs, les instances Azure Container Instances et Azure Kubernetes Service sont également conçues pour être mises à l'échelle manuellement ou automatiquement.
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é.
Comme avec tout autre type d'application, l'environnement de simulation peut être conçu pour gérer des données sensibles. Par conséquent, vous devez limiter les utilisateurs autorisés à s'y connecter et à l'utiliser, et vous devez limiter les données accessibles en fonction de l'identité ou du rôle de l'utilisateur. Utilisez Microsoft Entra ID pour le contrôle des identités et des accès, ainsi qu’Azure Key Vault pour gérer les clés et les secrets.
Pour obtenir des conseils d’ordre général sur la conception de solutions sécurisées, consultez la documentation sur la sécurité Azure.
DevOps
Pour déployer de nouveaux environnements de simulation, il est préférable d’utiliser des processus CI/CD en utilisant une solution comme Azure DevOps ou GitHub Actions.
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 Vue d’ensemble du pilier d’optimisation des coûts.
En règle générale, utilisez la calculatrice de prix Azure pour estimer les coûts. Vous pouvez également optimiser vos coûts en suivant le processus visant à bien ajuster dès le départ la capacité de vos machines virtuelles, tout en procédant à un redimensionnement simplifié si nécessaire. D'autres considérations sont décrites dans la section Coûts de Microsoft Azure Well-Architected Framework.
Étapes suivantes
Documentation du produit :
Parcours d’apprentissage Microsoft :
Implémenter et gérer le stockage pour les administrateurs Azure
Déployer et gérer des ressources de calcul pour les administrateurs Azure
Configurer et gérer des réseaux virtuels pour les administrateurs Azure
Gérer les identités et la gouvernance pour les administrateurs Azure
Superviser et sauvegarder les ressources pour les administrateurs Azure
Ressources associées
Articles de vue d’ensemble du Centre des architectures Azure :
Architectures appropriées :