Byggstenar för autonoma simuleringsmiljöer

Azure Container Instances
Microsoft Entra ID
Azure Virtual Network
Azure Virtual Machines
Azure Pipelines

Exempelarbetsbelastningen som beskrivs nedan beskriver hur du skapar en simulering som körs automatiskt och utvärderar simulerad fordonsfunktion via en Azure DevOps-pipeline. Den här pipelinen körs varje gång en tekniker kontrollerar en ny version av exempelfunktionens källkod eller dess simuleringsmiljö.

Arkitektur

Diagram som visar byggstenar för autonoma simuleringsmiljöer.

Ladda ned en Visio-fil med den här arkitekturen.

Användarens indatalager

Utvecklaren interagerar bara med det här lagret. Den innehåller utvecklararbetsstationen (en virtuell Azure-dator i vårt omfång) och specifikationsfilen som beskriver simuleringsmiljön.

Orkestreringslager

"Orkestrering" har en bred betydelse: några av de problem som beskrivs av ordet är trivialt lösta; andra är mycket mer komplexa. Till exempel löses "orkestreringsproblemet" med att skapa, övervaka och förstöra containrar och virtuella datorer av många verktyg – Själva Azure-API:et är en tillräcklig "orkestrerare" för det!

Arbetsflöde

Det är dock viktigt att dela upp den svarta rutan med "orkestrering" i mindre komponenter.

  • Simulerings-API: Det här API:et tar emot en specifikationsfil och är startpunkten för att kontrollera simuleringsmiljöer och simuleringskörningar med Orchestration Layer.

  • Tolk: Den här komponenten tolkar specifikationsfilen till en logisk struktur för Simuleringshanteraren.

  • Simuleringshanteraren: Det här är tillståndsdatorn som konverterar miljöobjektet för logisk simulering till önskade tillstånd och åtgärder som ska användas av andra komponenter. Det här är komponenten som utlöser build, execute och teardown av simuleringen. Den hanterar även interna beroenden och fellägen.

  • Scheduler: Den här komponenten tilldelar byggstenar till infrastrukturresurser och startar dem där. Den står för maskinvaru- och åtkomstkrav, tillgängliga resurser och resursgränser.

  • Miljöhanterare: Den här komponenten bevakar den underliggande infrastrukturen och svarar på problem, till exempel när en containervärd slutar fungera.

  • Nätverkshanterare: Den här komponenten hanterar nätverk och routning för simuleringsmiljöer. Varje miljö måste finnas i en isolerad nätverksmiljö, med isolerade byggstenar som tar emot inkommande anslutningar för interaktivitet. Den här komponenten används också för att lösa byggstenar i en simulering (till exempel via en intern DNS).

  • Access Manager: Den här komponenten återspeglar auktorisering/autentisering från Microsoft Entra-ID till resten av systemet.

  • Configuration Manager: Den här komponenten fungerar som en beständig lagringsmekanism för tillståndet för infrastrukturen och simuleringsmiljöerna.

  • Infrastrukturabstraktion: Det här är ett abstraktionslager som översätter allmänna kommandon till specifika Azure API-kommandon för containrar jämfört med virtuella datorer.

  • Storage Manager: Den här komponenten hanterar etablering och anslutning av lagring för simuleringsmiljöer (till exempel rotenheter för virtuella datorer eller containeranslutna volymer).

  • Resursövervakare: Den här komponenten övervakar resursanvändningen på infrastrukturnivå till en tidsseriedatabas för export till ADP:s kärnövervakning.

  • Log Manager: Den här komponenten aggregerar loggar från byggstenar för användarinspektion. Den exporterar även loggar till ADP-kärnloggning.

Orkestreringsskiktet är det primära fokuset för den här exempelarbetsbelastningen.

Infrastrukturlager för simulering

Det här lagret representerar alla simuleringsmiljöer som körs.

  • Simuleringsmiljö: Kombinationen av byggstenar som definieras av definitionsfilen och parametrarna skapas här, i nätverksisolering från andra simuleringsmiljöer.

  • Byggblockskontrakt: Den skrivna standarden som definierar hur alla byggblock skickar utdata, fel och status till orkestreringsskiktet.

  • Byggblockspipeline: Det här området hanterar skapandet och lagringen av byggblock.

  • Byggblockslagringsplats: Det här är lagrings- och hämtningssystemet för byggblocksavbildningar, till exempel ett containerregister och/eller ett Azure-avbildningsgalleri.

  • Byggblocksfabrik: Pipelinen för kontinuerlig integrering och kontinuerlig distribution (CI/CD) som skapar byggblocksbilder med oföränderliga, verifierbara komponentpaket (till exempel dpkg eller apt) på ett deklarativt konfigurationsspråk (till exempel Chef eller Ansible).

Lagringslager

Det här lagret lagrar resultatet av simuleringen på ett durabelt och åtkomstbart sätt. Det är främst ansvaret för arbetsströmmen för mobilprogramutvecklingsplattformen (MADP) Data Lake, även om dina utdata måste vara hanterbara av det teamet.

  • Lagringsgränssnitt: Det gränssnitt som gör det möjligt för användare att arbeta med simuleringsresultatlagring. Detta fungerar i nära samarbete med, eller kan ersättas av, Storage Manager-orkestreringskomponenten ovan.

  • Lagring: Lagringsmekanismen som används för att spara simuleringsresultat (till exempel Azure Blob Storage eller Azure Disk Storage-resurser).

Komponenter

Azure Virtual Machines tillhandahåller skalbara datorresurser på begäran som ger dig flexibiliteten i virtualisering, utan att behöva köpa och underhålla den fysiska maskinvaran.

Azure Virtual Network är den grundläggande byggstenen för ditt privata nätverk i Azure. Med Azure Virtual Network kan många typer av Azure-resurser, till exempel Virtuella Azure-datorer, kommunicera säkert med varandra, internet och lokala nätverk.

Azure Container Instances är det snabbaste och enklaste sättet att köra en container i Azure, utan att behöva hantera några virtuella datorer och utan att behöva använda en tjänst på högre nivå.

Azure Container Registry är en hanterad, privat Docker-registertjänst baserad på Docker Registry 2.0 med öppen källkod. Du kan använda Azure-containerregister med dina befintliga pipelines för containerutveckling och distribution, eller använda Azure Container Registry Tasks för att skapa containeravbildningar i Azure. Skapa på begäran eller automatisera helt versioner med utlösare, till exempel incheckningar av källkod och uppdateringar av basavbildningar.

Azure Pipelines ingår i Azure DevOps Services och kör automatiserade versioner, tester och distributioner. Du kan också använda CI/CD-lösningar från tredje part, till exempel Jenkins.

Microsoft Entra ID är den molnbaserade identitets- och åtkomsthanteringstjänsten som autentiserar användare, tjänster och program.

Azure Storage erbjuder en hållbar, mycket tillgänglig och mycket skalbar molnlagringslösning. Den innehåller funktioner för objekt-, fil-, disk-, kö- och tabelllagring.

Azure Monitor samlar in övervakningstelemetri från en mängd olika lokala källor och Azure-källor. Den här tjänsten sammanställer och lagrar telemetri i ett loggdatalager som är optimerat för kostnad och prestanda.

Alternativ

Den här arkitekturen använder virtuella datorer och containrar för att distribuera de olika verktygen och tjänsterna. Som ett alternativ kan du också använda Azure Kubernetes Services (AKS). Det erbjuder serverlös Kubernetes, en integrerad CI/CD-upplevelse samt säkerhet och styrning på företagsnivå.

Lagringsmekanismen som används för att spara simuleringsresultat i den här arkitekturen baseras på Azure Blob Storage eller Azure Disk Storage. Som ett alternativ för större arbetsbelastningar kan du också titta på Azures storskaliga data- och analyslösningar för att lagra och analysera data.

Överväg också att använda Azure Monitor för att analysera och optimera infrastrukturens prestanda och för att övervaka och diagnostisera nätverksproblem utan att logga in på dina virtuella datorer.

Information om scenario

För att utvärdera autonom körning (AD) måste funktionstekniker simulera beteendet hos fordon med AD-funktioner. Tänk dig följande exempel på körscenario:

Ett testfordon kör autonomt i 80 mph i höger körfält på en 3-lane motorväg. Det finns en lastbil 600 ft framåt som kör i samma körfält och i samma riktning vid 55 mph. Det finns inget fordon i närheten i mittfilen. Vägmarkeringarna är synliga, solen skiner vinkelrätt mot fordonet och vägen är torr.

En begränsad simulering av ett fordons beteende med ett scenario som detta kallas för en simuleringskörning. I scenariot ovan är ditt simulerade fordons förväntade beteende att bekvämt passera lastbilen utan att orsaka en olycka och utan att bryta mot några trafikregler. Genom att köra en simulering för varje ny version av en funktion testar AD-funktionstekniker om den nya versionen fortfarande uppvisar det förväntade beteendet.

För att köra en simulering använder AD-funktionstekniker ofta en uppsättning program. Dessa kan omfatta virtuell provkörning (VTD), tidspartitionstestning (TPT), Avionics Development System 2G (ADS2) och Automotive Data and Time-Triggered Framework (ADTF), som alla kommunicerar med varandra enligt deras specifika konfigurationer för att testa en viss autonom körfunktion, till exempel Highway Pilot. En distribution av den här uppsättningen programvaruverktyg och deras konfigurationer till fysiska och/eller virtuella datorer lokalt och/eller i molnet kallas för en simuleringsmiljö.

För att säkerställa giltigheten för testresultaten som genereras av varje simulering du kör bör du se till att simuleringen startar i en ny simuleringsmiljö inställd på dess ursprungliga tillstånd.

Varje autonomt körteam behöver en separat uppsättning program i sin simuleringsmiljö med en unik konfiguration. Många team behöver också flera olika simuleringsmiljöer. För att till exempel utvärdera en LIDAR-sensor behöver du mycket högupplöst objektsimulering, men inga andra drivrutiner, vägmarkeringar eller andra funktioner. Även om varje miljö är unik finns det betydande överlappning i de program som används. Många team använder till exempel VTD i flera simuleringsmiljöer.

Det går att köra en simulering i en simuleringsmiljö som består av återanvändbara, inkapslade och oberoende utvärderade enheter. De här enheterna fungerar som de "byggstenar" som du använder för att automatiskt och på begäran skapa simuleringsmiljöer i Azure-molnet. Dessa simuleringsmiljöer kallas även för automatiserade körplattformar (ADP).

Potentiella användningsfall

Den här lösningen är idealisk för fordons- och transportindustrin. Vanliga användningsområden för den här arbetsbelastningen är:

  • Automatisera körtester.

  • Prototyper, utveckling, integrering, testning, validering och verifiering av kontrollsystem inom fordonsindustrin.

  • Registrera fordonsdata för visualisering.

  • Simulera komplexa körscenarier inom fordonsindustrin.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Tillgänglighet och motståndskraft

Överväg att distribuera virtuella datorer mellan tillgänglighetsuppsättningar eller tillgänglighetszoner, vilket hjälper till att skydda program mot planerade underhållshändelser och oplanerade avbrott.

En tillgänglighetsuppsättning är en logisk gruppering av virtuella datorer som gör att Azure kan förstå hur ett program är utformat och kan tillhandahålla redundans och tillgänglighet.

Tillgänglighetszoner är unika fysiska platser i Azure-regioner som hjälper till att skydda virtuella datorer, program och data från datacenterfel. Varje zon består av ett eller flera datacenter. Virtuella datorer och program i zoner kan förbli tillgängliga även om det uppstår ett fysiskt fel i ett enda datacenter.

Skalbarhet

Du kan skala virtuella Azure-datorer manuellt eller med hjälp av funktioner för automatisk skalning.

För containerdistributioner är Azure Containers Instances och Azure Kubernetes Services också utformade för att skala upp eller ut manuellt eller automatiskt.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Översikt över säkerhetspelare.

Precis som med andra typer av program kan simuleringsmiljön utformas för att hantera känsliga data. Därför bör du begränsa vem som kan logga in och använda dem, och du bör också begränsa vilka data som kan nås baserat på användarens identitet eller roll. Använd Microsoft Entra-ID för identitets- och åtkomstkontroll och använd Azure Key Vault för att hantera nycklar och hemligheter.

Allmän vägledning om hur du utformar säkra lösningar finns i Azure-säkerhetsdokumentationen.

DevOps

För att distribuera nya simuleringsmiljöer är det bäst att använda CI/CD-processer med hjälp av en lösning som Azure DevOps eller GitHub Actions.

Kostnadsoptimering

Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.

Normalt beräknar du kostnader med hjälp av Azures priskalkylator. Du kan också optimera dina kostnader genom att följa processen för att rätt storleksanpassa kapaciteten för dina virtuella datorer från början, tillsammans med förenklad storleksändring efter behov. Andra överväganden beskrivs i avsnittet Kostnad i Microsoft Azure Well-Architected Framework.

Nästa steg

Produktdokumentation:

Microsofts utbildningsvägar:

Översiktsartiklar för Azure Architecture Center:

Relevanta arkitekturer: