Byggstenar för självkörande simuleringsmiljöer

Container Instances
Azure Active Directory
Virtual Network
Virtual Machines
Pipelines

För att utvärdera autonom körning (AD) behöver funktionstekniker simulera beteendet för fordon med AD-funktioner. Tänk dig följande exempel på ett körningsscenario:

Ett testfordon kör autonomt i 80 km/h i det högra körfältet på en 3-vägs motorväg. Det är en lastbil 600 fot före som kör i samma band och i samma riktning vid 55 km/s. Det finns inget fordon i närheten i mittfilen. Vägmarkörerna är synliga, sunen står vid fordonet och vägen är dry.

En begränsad simulering av ett fordons beteende med ett scenario som det här kallas för en simuleringskörning. I scenariot ovan är det simulerade fordonets förväntade beteende att klara lastbilen utan att orsaka en slump och utan att bryta mot trafikreglerna. Genom att köra en simulering för varje ny version av en funktion testar AD-funktionstekniker om den nya versionen fortfarande har det förväntade beteendet.

För att köra en simulering använder AD-funktionstekniker ofta en uppsättning program. Dessa kan vara Virtual Test Drive (GSD), Time Partition Testing (TPT), Avionics Development System 2G (ADS2) och Bildata och Time-Triggered Framework (ADTF), som alla kommunicerar med varandra enligt deras specifika konfigurationer för att testa en viss autonom körningsfunktion, till exempel Highway Pilot. En distribution av den här uppsättningen programvaruverktyg och deras konfigurationer till fysiska och/eller virtuella datorer (VM) lokalt och/eller i molnet kallas för en simuleringsmiljö.

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

Varje autonomt drivande team behöver en separat uppsättning program i sin simuleringsmiljö med en unik konfiguration. Många team behöver också flera olika simuleringsmiljöer. Om du till exempel vill utvärdera en LIDAR-sensor behöver du en 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, kapslade och oberoende utvärderade enheter. Dessa enheter fungerar som "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).

Exempelarbetsbelastningen som beskrivs nedan beskriver hur du bygger ut 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ö.

Potentiella användningsfall

Vanliga användningsområden för den här arbetsbelastningen är:

  • Automatisera körningstester.

  • Prototyper, utveckling, integrering, testning, validering och verifiering av kontrollsystem i fordonsbranschen.

  • Registrera fordonsdata för visualisering.

  • Simulera komplexa körningsscenarier i bilbranschen.

Arkitektur

En bild som innehåller grafiskt användargränssnitt

Indatalager för användare

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: vissa av de problem som beskrivs i ordet löses enkelt; andra är mycket mer komplexa. Till exempel löses orkestreringsproblemet med att skapa, övervaka och förstöra containrar och virtuella datorer med många verktyg – själva Azure-API:et är en tillräcklig "orkestrerare" för det! 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 styra 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 det logiska simuleringsmiljöobjektet till önskade tillstånd och åtgärder som ska användas av andra komponenter. Det här är den komponent som utlöser skrivning, körning och borttagning 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 tar upp 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 går ned.

  • Nätverkshanterare: Den här komponenten hanterar nätverken och routningen 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 Azure Active Directory (Azure AD) till resten av systemet.

  • Konfigurationshanteraren: Den här komponenten fungerar som en beständig lagringsmekanism för infrastrukturens och simuleringsmiljöernas tillstånd.

  • Infrastrukturabstrahering: 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 VM-rotenheter eller containerkopplade volymer).

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

  • Log Manager: Den här komponenten sammanställer loggar från byggstenar för användargranskning. 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 alla andra simuleringsmiljöer.

  • Byggblockkontrakt: Den skrivna standarden som definierar hur alla byggstenar skickar utdata, fel och status till Orchestration Layer.

  • Byggblockspipeline: Det här området hanterar skapande och lagring av byggstenar.

  • Skapa blocklagringsplats: Det här är lagrings- och hämtningssystemet för att skapa blockavbildningar, till exempel ett containerregister och/eller ett Azure-avbildningsgalleri.

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

Storage Layer

Det här lagret lagrar durably och tillgänglig resultatet av simuleringen. Det är främst data lake-dataströmmens (MOBILEP) dataplattformsplattforms ansvar, även om dina utdata måste kunna hanteras av det teamet.

  • Storage: Gränssnittet som gör att användare kan arbeta med lagring av simuleringsresultat. Detta fungerar i nära samarbete med, eller kan vara kompanterat av, Storage Manager-orkestreringskomponenten ovan.

  • Storage: Den lagringsmekanism 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 med virtualisering, utan att du behöver köpa och underhålla den fysiska maskinvaran.

Azure Virtual Network är den grundläggande byggstenen för ditt privata nätverk i Azure. Azure Virtual Network gör att många typer av Azure-resurser, till exempel Azure Virtual Machines, på ett säkert sätt kan kommunicera 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 som baseras på Docker Registry 2.0 med öppen källkod. Du kan använda Azure-containerregister med dina befintliga pipelines för utveckling och distribution av containrar, eller använda Azure Container Registry-uppgifter för att skapa containeravbildningar i Azure. Skapa på begäran eller automatisera helt byggen med utlösare, till exempel källkods genomföranden och uppdateringar av basavbildningar.

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

Azure Active Directory är den molnbaserade identitets- och åtkomsthanteringstjänsten som autentiserar användare, tjänster och program.

Azure Storage en beständig, hög tillgänglig och mycket skalbar molnlagringslösning. Den innehåller funktioner för objekt-, fil-, disk-, kö- och tabellagring.

Azure Monitor samlar in övervakningstelemetri från en mängd olika lokala källor och Azure-källor. Den här tjänsten aggregerar 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. Alternativt kan du också använda Azure Kubernetes Services (AKS). AKS erbjuder serverlös Kubernetes, en integrerad CI/CD-upplevelse och säkerhet och styrning i företagsklass.

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 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.

Överväganden

Tillgänglighet och återhämtning

Överväg att distribuera virtuella datorer över tillgänglighetsuppsättningareller tillgänglighetszoner som hjälper dig 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 skyddar virtuella datorer, program och data från datacenterfel. Varje zon består av ett eller flera datacenter. Virtuella datorer och program i zoner kan vara 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 autoskalningsfunktioner.

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

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 den, och du bör också begränsa vilka data som kan nås baserat på användarens identitet eller roll. Använd Azure AD 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, enligt beskrivningen i dokumentationen för Azure DevOps Starter.

Prissättning

I allmänhet använder du priskalkylatorn för Azure för att beräkna kostnader. Du kan också optimera dina kostnader genom att följa processen för att anpassa storleken på 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

Azure Architecture Center översiktsartiklar:

Produktdokumentation:

Microsoft Learn utbildningsvägar: