Voor het beoordelen van autonoom rijden (AD) moeten functietechnici het gedrag van voertuigen met AD-mogelijkheden simuleren. Kijk eens naar het volgende voorbeeld van een rijscenario:
Een testwagen rijdt autonoom op 80 km in de rechterweg op een snelweg met drie banen. Er rijdt een vrachtwagen van 600 ft vooruit in dezelfde baan en in dezelfde richting op 55 meter. Er is geen voertuig in de buurt in de middelste rij. De wegmarkeringen zijn zichtbaar, de zon is duidelijk zichtbaar voor het voertuig en de weg is leeg.
Een eindige simulatie van het gedrag van een voertuig met behulp van een scenario zoals dit wordt een simulatierun genoemd. In het bovenstaande scenario is het verwachte gedrag van uw gesimuleerde voertuig om de vrachtwagen te passeren zonder dat er een ongeluk is veroorzaakt en zonder dat er verkeersregels worden schendt. Door een simulatie uit te laten uitvoeren voor elke nieuwe versie van een functie, testen AD-functietechnici of de nieuwe versie nog steeds het verwachte gedrag vertoont.
Voor het uitvoeren van een simulatie gebruiken AD-functietechnici vaak een set softwaretoepassingen. Dit kunnen Virtual Test Drive (VTD), Time Partition Testing (TPT), Avionics Development System 2G (ADS2) en Autogegevens en Time-Triggered Framework (ADTF) zijn, die allemaal met elkaar communiceren volgens hun specifieke configuraties voor het testen van een bepaalde autonome rijfunctie, zoals de Highway Pilot. Een implementatie van deze set softwarehulpprogramma's en hun configuraties naar fysieke en/of virtuele machines (VM's) on-premises en/of in de cloud wordt een simulatieomgeving genoemd.
Om de geldigheid te garanderen van de testresultaten die worden gegenereerd door elke simulatie die u hebt uitgevoerd, moet u ervoor zorgen dat de simulatie wordt gestart in een nieuwe simulatieomgeving die is ingesteld op de begintoestand.
Elk autonoom rijdend team heeft een afzonderlijke set toepassingen in hun simulatieomgeving nodig, met een unieke configuratie. Veel teams hebben ook meerdere verschillende simulatieomgevingen nodig. Als u bijvoorbeeld een LIDAR-sensor wilt evalueren, hebt u objectsimulatie met een zeer hoge resolutie nodig, maar geen andere stuurprogramma's, wegmarkeringen of andere functies. Hoewel elke omgeving uniek is, is er aanzienlijke overlap in de toepassingen die worden gebruikt. Veel teams gebruiken bijvoorbeeld VTD in meerdere simulatieomgevingen.
Het is mogelijk om een simulatie uit te voeren in een simulatieomgeving die bestaat uit herbruikbare, ingekapselde en onafhankelijk geëvalueerde eenheden. Deze eenheden fungeren als de 'bouwstenen' die u gebruikt voor het automatisch en on-demand maken van simulatieomgevingen in de Azure-cloud. Deze simulatieomgevingen worden ook wel ADP (Automated Driving Platforms) genoemd.
In de voorbeeldworkload die hieronder wordt besproken, wordt beschreven hoe u een simulatie bouwt die automatisch wordt uitgevoerd en de functie van een gesimuleerd voertuig evalueert via een Azure DevOps-pijplijn. Deze pijplijn wordt elke keer uitgevoerd wanneer een technicus een nieuwe versie van de broncode of de simulatieomgeving van de voorbeeldfunctie controleert.
Potentiële gebruikscases
Typische toepassingen voor deze workload zijn:
Automatisatie van rijtests.
Prototyping, ontwikkeling, integratie, testen, validatie en verificatie van controlesystemen in de auto-industrie.
Voertuiggegevens vastleggen voor visualisatie.
Het simuleren van complexe rijscenario's in de auto-industrie.
Architectuur

Gebruikersinvoerlaag
De ontwikkelaar communiceert alleen met deze laag. Het bevat het ontwikkelwerkstation (een Azure-VM in ons bereik) en het specificatiebestand waarin de simulatieomgeving wordt beschreven.
Orchestration-laag
'Orchestration' heeft een brede betekenis: sommige van de problemen die door het woord worden beschreven, worden op een triviale manier opgelost; andere zijn veel complexer. Het 'orchestration'-probleem van het maken, bewaken en vernietigen van containers en VM's wordt bijvoorbeeld opgelost door veel hulpprogramma's. De Azure API zelf is daar voldoende 'orchestrator' voor! Het is echter belangrijk om de zwarte doos 'orchestration' op te delen in kleinere onderdelen.
Simulatie-API: Deze API ontvangt een specificatiebestand en is het toegangspunt voor het beheren van simulatieomgevingen en simulatie-uitvoeringen met de Orchestration-laag.
Interpreter: Dit onderdeel interpreteert het specificatiebestand in een logische structuur voor Simulatiebeheer.
Simulation Manager: Dit is de statusmachine die het logische simulatieomgevingsobject converteert naar de gewenste statussen en acties die door andere onderdelen moeten worden gebruikt. Dit is het onderdeel dat het bouwen, uitvoeren en afbreken van de simulatie activeert. Het beheert ook interne afhankelijkheden en foutmodi.
Scheduler: Met dit onderdeel worden bouwstenen toegewezen aan infrastructuurresources en worden deze daar gestart. Het account is verantwoordelijk voor hardware- en toegangsvereisten, beschikbare resources en resourcelimieten.
Environment Manager: Dit onderdeel bewaakt de onderliggende infrastructuur en reageert op problemen, zoals wanneer een containerhost uitgaat.
Network Manager: Dit onderdeel beheert de netwerken en routering voor simulatieomgevingen. Elke omgeving moet zich in een geïsoleerde netwerkomgeving leven, met geïsoleerde bouwstenen die binnenkomende verbindingen ontvangen voor interactiviteit. Dit onderdeel wordt ook gebruikt voor het oplossen van bouwstenen binnen een simulatie (bijvoorbeeld via een interne DNS).
Access Manager: Dit onderdeel weerspiegelt autorisatie/verificatie van Azure Active Directory (Azure AD) in de rest van het systeem.
Configuration Manager: Dit onderdeel fungeert als een permanent opslagmechanisme voor de status van de infrastructuur en simulatieomgevingen.
Infrastructuurabstr abstractie: Dit is een abstractielaag die algemene opdrachten vertaalt naar specifieke Azure API-opdrachten voor containers versus VM's.
Storage Manager: Met dit onderdeel beheert u het inrichten en koppelen van opslag voor simulatieomgevingen (bijvoorbeeld VM-basisapparaten of aan een container gekoppelde volumes).
Broncontrole: Dit onderdeel bewaakt het resourcegebruik op infrastructuurniveau in een tijdreeksdatabase, voor export naar de kernbewaking van de ADP.
Log Manager: dit onderdeel aggregeert logboeken uit bouwstenen voor gebruikersinspectie. Het exporteert ook logboeken naar ADP-kernlogboeken.
De Orchestration Layer is de primaire focus van deze voorbeeldworkload.
Infrastructuurlaag voor simulatie
Deze laag vertegenwoordigt alle simulatieomgevingen die worden uitgevoerd.
Simulatieomgeving: De combinatie van bouwstenen die zijn gedefinieerd door het definitiebestand en parameters worden hier gemaakt, in netwerkisolatie van andere simulatieomgevingen.
Building Block Contract: de geschreven standaard die definieert hoe alle bouwstenen uitvoer, fouten en status naar de Orchestration-laag verzenden.
Building Block Pipeline: Dit gebied beheert het maken en opslaan van bouwstenen.
Building Block Repository: dit is het opslag- en ophaalsysteem voor bouwsteeninstallatie afbeeldingen, zoals een containerregister en/of een Azure Image Gallery.
Building Block Factory: De pijplijn voor continue integratie en continue implementatie (CI/CD) waarmee bouwsteenafbeeldingen worden gemaakt met onveranderbare, verifieerbare onderdeelpakketten (bijvoorbeeld dpkg of apt) in een declaratieve configuratietaal (bijvoorbeeld Chef of Ansible).
Storage Laag
Deze laag is blijvend en toegankelijk en slaat de resultaten van de simulatie op. Het is voornamelijk de verantwoordelijkheid van het DATAP Data Lake-workstream (Mobile Application Development Platform), maar uw uitvoer moet door dat team kunnen worden beheerbaar.
Storage interface: De interface waarmee gebruikers kunnen werken met simulatieresultaatopslag. Dit werkt nauw samen met, of kan worden vervangen door het Storage Manager-orchestration-onderdeel hierboven.
Storage: het opslagmechanisme dat wordt gebruikt voor het opslaan van simulatieresultaten (bijvoorbeeld Azure Blob Storage of Azure Disk Storage resources).
Onderdelen
Azure Virtual Machines biedt schaalbare computingresources op aanvraag die u de flexibiliteit van virtualisatie bieden, zonder dat u de fysieke hardware moet kopen en onderhouden.
Azure Virtual Network is de fundamentele bouwsteen voor uw particuliere netwerk in Azure. Met Azure Virtual Network kunt u veel soorten Azure-resources, zoals Azure Virtual Machines, veilig met elkaar, internet en on-premises netwerken communiceren.
Azure Container Instances is de snelste en eenvoudigste manier om een container in Azure uit te voeren, zonder dat u VM's moet beheren en zonder een service op een hoger niveau te moeten gebruiken.
Azure Container Registry is een beheerde, persoonlijke Docker-registerservice op basis van de open-source Docker Registry 2.0. U kunt Azure-containerregisters gebruiken met uw bestaande pijplijnen voor containerontwikkeling en -implementatie, of Azure Container Registry-taken om containerafbeeldingen te bouwen in Azure. Bouw builds op aanvraag of automatiseer builds volledig met triggers, zoals broncode-commits en updates van basisafbeeldingen.
Azure Pipelines maken deel uit van DevOps Services en voeren geautomatiseerde builds, tests en implementaties uit. U kunt ook CI/CD-oplossingen van derden gebruiken, zoals Jenkins.
Azure Active Directory is de identiteits- en toegangsbeheerservice in de cloud die gebruikers, services en toepassingen verifieert.
Azure Storage biedt een duurzame, zeer beschikbare en zeer schaalbare cloudopslagoplossing. Het bevat mogelijkheden voor object-, bestands-, schijf-, wachtrij- en tabelopslag.
Azure Monitor verzamelt bewakings-telemetrie van verschillende on-premises en Azure-bronnen. Met deze service wordt telemetrie geaggregeerd en opgeslagen in een logboekgegevensopslag die is geoptimaliseerd voor kosten en prestaties.
Alternatieven
Deze architectuur maakt gebruik van VM's en containers voor het implementeren van de verschillende hulpprogramma's en services. Als alternatief kunt u ook Azure Kubernetes Services (AKS) gebruiken. AKS biedt serverloze Kubernetes, een geïntegreerde CI/CD-ervaring en hoogwaardige beveiliging en governance.
Het opslagmechanisme dat wordt gebruikt voor het opslaan van simulatieresultaten in deze architectuur is gebaseerd op Azure Blob Storage of Azure Disk Storage. Als alternatief voor grotere workloads kunt u ook de grootschalige gegevens- en analyseoplossingen van Azure bekijken voor het opslaan en analyseren van gegevens.
U kunt ook Azure Monitor gebruiken om de prestaties van uw infrastructuur te analyseren en optimaliseren, en om netwerkproblemen te bewaken en te diagnosticeren zonder u aan te melden bij uw VM's.
Overwegingen
Beschikbaarheid en tolerantie
Overweeg om VM's te implementeren in beschikbaarheidssetsof beschikbaarheidszones, waarmee toepassingen worden beschermd tegen geplande onderhoudsgebeurtenissen en ongeplande uitval.
Een beschikbaarheidsset is een logische groepering van virtuele machines waaruit Azure kan begrijpen hoe uw toepassing is ontworpen, om zo redundantie en beschikbaarheid te kunnen bieden.
Beschikbaarheidszones zijn unieke fysieke locaties binnen Azure-regio's die VM's, toepassingen en gegevens beschermen tegen datacenterfouten. Elke zone bestaat uit een of meer datacenters. VM's en toepassingen in zones kunnen beschikbaar blijven, zelfs als er een fysieke storing in één datacenter is.
Schaalbaarheid
U kunt azure-VM's handmatig schalen of met behulp van functies voor automatisch schalen.
Voor containerimplementaties zijn Azure Containers Instances en Azure Kubernetes Services ook ontworpen om handmatig of automatisch omhoog of uit te schalen.
Beveiliging
Net als bij elk ander type toepassing kan de simulatieomgeving worden ontworpen om gevoelige gegevens te verwerken. Daarom moet u beperken wie zich kan aanmelden en gebruiken, en u moet ook beperken welke gegevens toegankelijk zijn op basis van de identiteit of rol van de gebruiker. Gebruik Azure AD voor identiteits- en toegangsbeheer en gebruik Azure Key Vault sleutels en geheimen te beheren.
Zie de Azure-beveiligingsdocumentatie voor algemene richtlijnen voor het ontwerpen van beveiligde oplossingen.
DevOps
Voor het implementeren van nieuwe simulatieomgevingen kunt u het beste CI/CD-processen gebruiken met behulp van een oplossing zoals Azure DevOps of GitHub Actions, zoals beschreven in de Azure DevOps Starter-documentatie.
Prijzen
Over het algemeen gebruikt u de Azure-prijscalculator om de kosten te schatten. U kunt uw kosten ook optimaliseren door het proces te volgen om de capaciteit van uw VM's vanaf het begin op de juiste grootte te brengen, samen met een vereenvoudigde grootte als dat nodig is. Andere overwegingen worden beschreven in de sectie Kosten in Microsoft Azure Well-Architected Framework.
Volgende stappen
Azure Architecture Center overzichtsartikelen:
Productdocumentatie:
Microsoft Learn leertrajecten:
Rekenresources voor Azure-beheerders implementeren en beheren
Virtuele netwerken configureren en beheren voor Azure-beheerders