Dataåtgärder för autonom fordonsdrift

Den här artikeln innehåller en lösning och vägledning för att utveckla offlinedataåtgärder och datahantering (DataOps) för ett automatiserat körsystem. DataOps-lösningen bygger på det ramverk som beskrivs i designguiden för autonom fordonsdrift (AVOps). DataOps är en av byggstenarna i AVOps. Andra byggstenar är maskininlärningsåtgärder (MLOps), valideringsåtgärder (ValOps), DevOps och centraliserade AVOps-funktioner.

Apache®, Apache Spark och Apache Parquet är antingen registrerade varumärken eller varumärken som tillhör Apache Software Foundation i USA och/eller andra länder. Inget godkännande från Apache Software Foundation underförstås av användningen av dessa märken.

Arkitektur

Ladda ned en Visio-fil som innehåller arkitekturdiagrammen i den här artikeln.

Dataflöde

1. Mätdata kommer från ett fordons dataströmmar. Källor inkluderar kameror, fordonstelemetri och radar, ultraljuds- och lidarsensorer. Dataloggare i fordonet lagrar mätdata på loggningslagringsenheter. Loggningslagringsdata laddas upp till en landningsdatasjö. En tjänst som Azure Data Box eller Azure Stack Edge eller en dedikerad anslutning som Azure ExpressRoute matar in data i Azure. Mätdata i följande format hamnar i Azure Data Lake Storage: Måttdataformat version 4 (MDF4), tekniska datahanteringssystem (TDMS) och rosbag. De uppladdade data anger ett dedikerat lagringskonto med namnet Landing som är avsett för att ta emot och verifiera data.

2. En Azure Data Factory-pipeline utlöses med ett schemalagt intervall för att bearbeta data i landningslagringskontot. Pipelinen hanterar följande steg:

   • Utför en datakvalitetskontroll, till exempel en kontrollsumma. Det här steget tar bort data av låg kvalitet så att endast högkvalitativa data går vidare till nästa steg. Azure App Service används för att köra kvalitetskontrollkoden. Data som anses vara ofullständiga arkiveras för framtida bearbetning.
   • För ursprungsspårning anropar ett metadata-API med hjälp av App Service. Det här steget uppdaterar metadata som lagras i Azure Cosmos DB för att skapa en ny dataström. För varje mätning finns det en rådataström.
   • Kopierar data till ett lagringskonto med namnet Raw i Data Lake Storage.
   • Anropar metadata-API:et för att markera dataströmmen som fullständig så att andra komponenter och tjänster kan använda dataströmmen.
   • Arkiverar måtten och tar bort dem från landningslagringskontot.

3. Data Factory och Azure Batch bearbetar data i rådatazonen för att extrahera information som nedströmssystem kan använda:

   • Batch läser data från ämnen i rådatafilen och matar ut data till valda ämnen i respektive mappar.
   • Eftersom filerna i den råa zonen kan vara större än 2 GB, körs extraheringsfunktioner för parallell bearbetning på varje fil. Dessa funktioner extraherar bildbearbetning, lidar, radar och GPS-data. De utför också metadatabearbetning. Data Factory och Batch är ett sätt att utföra parallellitet på ett skalbart sätt.
   • Data är nedsamplade för att minska mängden data som måste märkas och kommenteras.

4. Om data från fordonsloggaren inte synkroniseras mellan de olika sensorerna utlöses en Data Factory-pipeline som synkroniserar data för att skapa en giltig datauppsättning. Synkroniseringsalgoritmen körs på Batch.

5. En Data Factory-pipeline körs för att utöka data. Exempel på förbättringar är telemetri, fordonsloggningsdata och andra data, till exempel väder, karta eller objektdata. Berikade data hjälper till att ge dataforskare insikter som de kan använda i algoritmutveckling, till exempel. De genererade data sparas i Apache Parquet-filer som är kompatibla med synkroniserade data. Metadata om berikade data lagras i ett metadatalager i Azure Cosmos DB.

6. Tredjepartspartner utför manuell eller automatisk etikettering. Data delas med tredjepartspartner via Azure Data Share och är integrerade i Microsoft Purview. Data Share använder ett dedikerat lagringskonto med namnet Labeled in Data Lake Storage för att returnera märkta data till organisationen.

7. En Data Factory-pipeline utför scenidentifiering. Scenmetadata sparas i metadatalagret. Scendata lagras som objekt i Parquet- eller Delta-filer.

8. Förutom metadata för berikningsdata och identifierade scener lagrar metadatalagret i Azure Cosmos DB metadata för mätningarna, till exempel enhetsdata. Det här arkivet innehåller också metadata för ursprunget av data när de går igenom processerna för extrahering, nedsampling, synkronisering, berikning och scenidentifiering. Metadata-API:et används för att komma åt måtten, ursprunget och scendata och för att leta upp var data lagras. Därför fungerar metadata-API:et som lagringslagerhanterare. Den sprider data över lagringskonton. Det ger också utvecklare ett sätt att använda en metadatabaserad sökning för att hämta dataplatser. Därför är metadatalagret en centraliserad komponent som erbjuder spårbarhet och ursprung i lösningens dataflöde.

9. Azure Databricks och Azure Synapse Analytics används för att ansluta till metadata-API:et och få åtkomst till Data Lake Storage och utföra forskning om data.

Komponenter

• Data Box är ett sätt att skicka terabyte data till och från Azure på ett snabbt, kostnadseffektivt och tillförlitligt sätt. I den här lösningen används Data Box för att överföra insamlade fordonsdata till Azure via ett regionalt transportföretag.
• Azure Stack Edge-enheter tillhandahåller Azure-funktioner på gränsplatser. Exempel på Azure-funktioner är beräkning, lagring, nätverk och maskinvaruaccelererad maskininlärning.
• ExpressRoute utökar ett lokalt nätverk till Microsoft-molnet via en privat anslutning.
• Data Lake Storage innehåller en stor mängd data i sitt ursprungliga rådataformat. I det här fallet lagrar Data Lake Storage data baserat på steg, till exempel rådata eller extraherade.
• Data Factory är en fullständigt hanterad, serverlös lösning för att skapa och schemalägga arbetsflöden för extrahering, transformering, inläsning (ETL) och extrahera, läsa in, transformera (ELT). Här utför Data Factory ETL via batchberäkning och skapar datadrivna arbetsflöden för orkestrering av dataförflyttning och transformering av data.
• Batch kör storskaliga parallella och högpresterande databehandlingsjobb (HPC) effektivt i Azure. Den här lösningen använder Batch för att köra storskaliga program för uppgifter som dataomvandling, filtrering och förberedelse av data och extrahering av metadata.
• Azure Cosmos DB är en globalt distribuerad databas med flera modeller. Här lagrar den metadataresultat som lagrade mått.
• Data Share delar data med partnerorganisationer med förbättrad säkerhet. Genom att använda delning på plats kan dataleverantörer dela data där de finns utan att kopiera data eller ta ögonblicksbilder. I den här lösningen delar Data Share data med etikettföretag.
• Azure Databricks tillhandahåller en uppsättning verktyg för att underhålla datalösningar i företagsklass i stor skala. Det krävs för långvariga åtgärder på stora mängder fordonsdata. Datatekniker använder Azure Databricks som analysarbetsbench.
• Azure Synapse Analytics minskar tiden till insikt i informationslager och stordatasystem.
• Azure Cognitive Search tillhandahåller söktjänster för datakataloger.
• App Service tillhandahåller en serverlös webbapptjänst. I det här fallet är App Service värd för metadata-API:et.
• Microsoft Purview tillhandahåller datastyrning mellan organisationer.
• Azure Container Registry är en tjänst som skapar ett hanterat register med containeravbildningar. Den här lösningen använder Container Registry för att lagra containrar för bearbetning av ämnen.
• Application Insights är ett tillägg till Azure Monitor som tillhandahåller hantering av programprestanda. I det här scenariot hjälper Application Insights dig att skapa observerbarhet kring extrahering av mått: du kan använda Application Insights för att logga anpassade händelser, anpassade mått och annan information medan lösningen bearbetar varje mätning för extrahering. Du kan också skapa frågor på log analytics för att få detaljerad information om varje mätning.

Information om scenario

Att utforma ett robust DataOps-ramverk för självkörande fordon är avgörande för att använda dina data, spåra dess ursprung och göra det tillgängligt i hela organisationen. Utan en väldesignad DataOps-process kan den enorma mängd data som självkörande fordon genererar snabbt bli överväldigande och svår att hantera.

När du implementerar en effektiv DataOps-strategi hjälper du till att se till att dina data lagras korrekt, är lättillgängliga och har en tydlig ursprung. Du gör det också enkelt att hantera och analysera data, vilket leder till mer välgrundat beslutsfattande och bättre fordonsprestanda.

En effektiv DataOps-process är ett sätt att enkelt distribuera data i hela organisationen. Olika team kan sedan komma åt den information som de behöver för att optimera sin verksamhet. DataOps gör det enkelt att samarbeta och dela insikter, vilket bidrar till att förbättra organisationens övergripande effektivitet.

Typiska utmaningar för dataåtgärder i samband med självkörande fordon är:

• Hantering av den dagliga terabyteskalan eller petabyteskalans volym av mätdata från forsknings- och utvecklingsfordon.
• Datadelning och samarbete mellan flera team och partner, till exempel för etikettering, anteckningar och kvalitetskontroller.
• Spårbarhet och ursprung för en säkerhetskritisk perceptionsstack som samlar in versionshantering och ursprunget för mätdata.
• Metadata och dataidentifiering för att förbättra semantisk segmentering, bildklassificering och objektidentifieringsmodeller.

Den här AVOps DataOps-lösningen ger vägledning om hur du hanterar dessa utmaningar.

Potentiella användningsfall

Den här lösningen gynnar oem-tillverkare (OEM), leverantörer på nivå 1 och oberoende programvaruleverantörer (ISV:er) som utvecklar lösningar för automatiserad körning.

Federerade dataåtgärder

I en organisation som implementerar AVOps bidrar flera team till DataOps på grund av den komplexitet som krävs för AVOps. Ett team kan till exempel ansvara för datainsamling och datainmatning. Ett annat team kan ansvara för datakvalitetshantering av lidar-data. Därför är följande principer för en datanätsarkitektur viktiga att tänka på för DataOps:

• Domänorienterad decentralisering av dataägarskap och arkitektur. Ett dedikerat team ansvarar för en datadomän som tillhandahåller dataprodukter för den domänen, till exempel etiketterade datauppsättningar.
• Data som en produkt. Varje datadomän har olika zoner på datasjö-implementerade lagringscontainrar. Det finns zoner för intern användning. Det finns också en zon som innehåller publicerade dataprodukter för andra datadomäner eller extern användning för att undvika dataduplicering.
• Självbetjäningsdata som en plattform för att aktivera autonoma, domänorienterade datateam.
• Federerad styrning för att möjliggöra samverkan och åtkomst mellan AVOps-datadomäner som kräver ett centraliserat metadatalager och en datakatalog. En etikettdatadomän kan till exempel behöva åtkomst till en datainsamlingsdomän.

Mer information om implementeringar av datanät finns i Analys i molnskala.

Exempelstruktur för AVOps-datadomäner

Följande tabell innehåller några idéer för att strukturera AVOps-datadomäner:

Varje AVOps-datadomän konfigureras baserat på en skissstruktur. Den strukturen omfattar Data Factory, Data Lake Storage, databaser, Batch och Apache Spark-körningar via Azure Databricks eller Azure Synapse Analytics.

Metadata och dataidentifiering

Varje datadomän är decentraliserad och hanterar sina motsvarande AVOps-dataprodukter individuellt. För central dataidentifiering och för att veta var dataprodukter finns krävs två komponenter:

• Ett metadatalager som bevarar metadata om bearbetade måttfiler och dataströmmar, till exempel videosekvenser. Den här komponenten gör att data kan identifieras och spåras med anteckningar som måste indexeras, till exempel för att söka i metadata för omärkta filer. Du kanske till exempel vill att metadatalagret ska returnera alla ramar för specifika fordonsidentifieringsnummer (VIN) eller ramar med fotgängare eller andra berikande objekt.
• En datakatalog som visar ursprung, beroenden mellan AVOps-datadomäner och vilka datalager som ingår i AVOps-dataloopen. Ett exempel på en datakatalog är Microsoft Purview.

Du kan använda Azure Data Explorer eller Azure Cognitive Search för att utöka ett metadatalager som baseras på Azure Cosmos DB. Ditt val beror på det slutliga scenario som du behöver för dataidentifiering. Använd Azure Cognitive Search för semantiska sökfunktioner.

Följande metadatamodelldiagram visar en typisk enhetlig metadatamodell som används i flera AVOps-datalooppelare:

Dela data

Datadelning är ett vanligt scenario i en AVOps-dataloop. Användning omfattar datadelning mellan datadomäner och extern delning, till exempel för att integrera etikettpartners. Microsoft Purview tillhandahåller följande funktioner för effektiv datadelning i en dataloop:

• Dataidentifiering och åtkomst med självbetjäning
• Datadelning på plats

Rekommenderade format för utbyte av etikettdata omfattar vanliga objekt i kontextdatauppsättningar (COCO) och Association for Standardization of Automation and Measuring Systems (ASAM) OpenLABEL-datauppsättningar.

I den här lösningen används de märkta datauppsättningarna i MLOps-processer för att skapa specialiserade algoritmer som perceptions- och sensorfusionsmodeller. Algoritmerna kan identifiera scener och objekt i en miljö, till exempel bilbyten, blockerade vägar, gångtrafik, trafikljus och trafikskyltar.

Datapipeline

I den här DataOps-lösningen automatiseras dataflytten mellan olika steg i datapipelinen. Med den här metoden ger processen fördelar med effektivitet, skalbarhet, konsekvens, reproducerbarhet, anpassningsbarhet och felhantering. Den förbättrar den övergripande utvecklingsprocessen, påskyndar framstegen och stöder säker och effektiv distribution av teknik för självkörande fordon.

I följande avsnitt beskrivs hur du kan implementera dataflytt mellan faser och hur du ska strukturera dina lagringskonton.

Hierarkisk mappstruktur

En välorganiserad mappstruktur är en viktig komponent i en datapipeline i utvecklingen av självkörande komponenter. En sådan struktur ger ett systematiskt och enkelt navigeringsbart arrangemang av datafiler, vilket underlättar effektiv datahantering och hämtning.

I den här lösningen har data i mappen raw följande hierarkiska struktur:

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

Data i det extraherade zonlagringskontot använder en liknande hierarkisk struktur:

region/extraherad/<mått-ID>/<data-stream-ID>/ÅÅÅÅ/MM/DD

Genom att använda liknande hierarkiska strukturer kan du dra nytta av den hierarkiska namnrymdsfunktionen i Data Lake Storage. Hierarkiska strukturer hjälper dig att skapa skalbar och kostnadseffektiv objektlagring. Dessa strukturer förbättrar också effektiviteten för objektsökning och hämtning. Partitionering efter år och VIN gör det enkelt att söka efter relevanta bilder från specifika fordon. I datasjön skapas en lagringscontainer för varje sensor, till exempel en kamera, en GPS-enhet eller en lidar- eller radarsensor.

Landningslagringskonto till Raw Storage-konto

En Data Factory-pipeline utlöses baserat på ett schema. När pipelinen har utlösts kopieras data från landningslagringskontot till Raw Storage-kontot.

Pipelinen hämtar alla måttmappar och itererar genom dem. Med varje mätning utför lösningen följande aktiviteter:

1. En funktion validerar mätningen. Funktionen hämtar manifestfilen från måttmanifestet. Sedan kontrollerar funktionen om alla MDF4-, TDMS- och rosbag-måttfiler för den aktuella mätningen finns i måttmappen. Om valideringen lyckas fortsätter funktionen till nästa aktivitet. Om verifieringen misslyckas hoppar funktionen över den aktuella mätningen och flyttas till nästa måttmapp.

2. Ett webb-API-anrop görs till ett API som skapar en mätning och JSON-nyttolasten från JSON-filen för måttmanifestet skickas till API:et. Om anropet lyckas parsas svaret för att hämta mått-ID:t. Om anropet misslyckas flyttas mätningen till aktiviteten vid fel för felhantering.

   Kommentar

   Den här DataOps-lösningen bygger på antagandet att du begränsar antalet begäranden till apptjänsten. Om din lösning kan göra ett obestämt antal begäranden bör du överväga ett hastighetsbegränsningsmönster.

3. Ett webb-API-anrop görs till ett API som skapar en dataström genom att skapa den JSON-nyttolast som krävs. Om anropet lyckas parsas svaret för att hämta dataströms-ID:t och dataströmsplatsen. Om anropet misslyckas flyttas mätningen till aktiviteten vid fel.

4. Ett webb-API-anrop görs för att uppdatera dataströmmens tillstånd till Start Copy. Om anropet lyckas kopierar kopieringsaktiviteten måttfiler till dataströmsplatsen. Om anropet misslyckas flyttas mätningen till aktiviteten vid fel.

5. En Data Factory-pipeline anropar Batch för att kopiera måttfilerna från landningslagringskontot till Raw Storage-kontot. En kopieringsmodul av en orchestrator-app skapar ett jobb med följande uppgifter för varje mätning:

   • Kopiera måttfilerna till Raw Storage-kontot.
   • Kopiera måttfilerna till ett arkivlagringskonto.
   • Ta bort måttfilerna från landningslagringskontot.

   Kommentar

   I dessa uppgifter använder Batch en orchestrator-pool och AzCopy-verktyget för att kopiera och ta bort data. AzCopy använder SAS-token för att utföra kopierings- eller borttagningsuppgifter. SAS-token lagras i ett nyckelvalv och refereras med hjälp av termerna landingsaskey, archivesaskeyoch rawsaskey.

6. Ett webb-API-anrop görs för att uppdatera dataströmmens tillstånd till Copy Complete. Om anropet lyckas fortsätter sekvensen till nästa aktivitet. Om anropet misslyckas flyttas mätningen till aktiviteten vid fel.

7. Måttfilerna flyttas från landningslagringskontot till ett landningsarkiv. Den här aktiviteten kan köra en viss mätning igen genom att flytta tillbaka den till landningslagringskontot via en hydratkopieringspipeline. Livscykelhantering är aktiverat för den här zonen så att mätningar i den här zonen tas bort eller arkiveras automatiskt.

8. Om ett fel uppstår med en mätning flyttas mätningen till en felzon. Därifrån kan den flyttas till landningslagringskontot för att köras igen. Alternativt kan livscykelhantering automatiskt ta bort eller arkivera mätningen.

Observera följande:

• Dessa pipelines utlöses baserat på ett schema. Den här metoden hjälper till att förbättra spårbarheten för pipelinekörningar och undvika onödiga körningar.
• Varje pipeline konfigureras med ett samtidighetsvärde på en för att se till att alla tidigare körningar slutförs innan nästa schemalagda körning startar.
• Varje pipeline är konfigurerad för att kopiera mätningar parallellt. Om en schemalagd körning till exempel hämtar 10 mått att kopiera kan pipelinestegen köras samtidigt för alla tio mätningarna.
• Varje pipeline har konfigurerats för att generera en avisering i Övervaka om pipelinen tar längre tid än förväntat.
• Aktiviteten på fel implementeras i senare observerbarhetsberättelser.
• Livscykelhantering tar automatiskt bort partiella mätningar, till exempel mätningar med saknade rosbag-filer.

Batch-design

All extraheringslogik paketeras i olika containeravbildningar, med en container för varje extraheringsprocess. Batch kör containerarbetsbelastningarna parallellt när den extraherar information från måttfiler.

Batch använder en orchestrator-pool och en körningspool för bearbetning av arbetsbelastningar:

• En orchestrator-pool har Linux-noder utan stöd för containerkörning. Poolen kör Python-kod som använder Batch-API:et för att skapa jobb och uppgifter för körningspoolen. Den här poolen övervakar också dessa uppgifter. Data Factory anropar orchestrator-poolen, som samordnar de containerarbetsbelastningar som extraherar data.
• En körningspool har Linux-noder med containerkörningar som stöd för containerarbetsbelastningar som körs. För den här poolen schemaläggs jobb och aktiviteter via orchestrator-poolen. Alla containeravbildningar som krävs för bearbetning i körningspoolen skickas till ett containerregister med hjälp av JFrog. Körningspoolen är konfigurerad för att ansluta till det här registret och hämta de nödvändiga avbildningarna.

Lagringskonton som data läse från och skrivs till monteras via NFS 3.0 på batchnoderna och containrarna som körs på noderna. Den här metoden hjälper batchnoder och containrar att bearbeta data snabbt utan att behöva ladda ned datafilerna lokalt till batchnoderna.

Anropa Batch från Data Factory

I extraheringspipelinen skickar utlösaren sökvägen till metadatafilen och sökvägen för rådataströmmen i pipelineparametrarna. Data Factory använder en sökningsaktivitet för att parsa JSON från manifestfilen. Rådataströms-ID:t kan extraheras från dataströmsökvägen för rådata genom att parsa pipelinevariabeln.

Data Factory anropar ett API för att skapa en dataström. API:et returnerar sökvägen för den extraherade dataströmmen. Den extraherade sökvägen läggs till i det aktuella objektet och Data Factory anropar Batch via en anpassad aktivitet genom att skicka det aktuella objektet efter att ha lagt till den extraherade dataströmsökvägen:

{
"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"
}

Stegvis extraheringsprocess

1. Data Factory schemalägger ett jobb med en uppgift för orkestreringspoolen för att bearbeta ett mått för extrahering. Data Factory skickar följande information till orchestrator-poolen:

   • Mått-ID:t
   • Platsen för måttfilerna av typen MDF4, TDMS eller rosbag som behöver extraheras
   • Målsökvägen för lagringsplatsen för det extraherade innehållet
   • Det extraherade dataströms-ID:t

2. Orchestrator-poolen anropar ett API för att uppdatera dataströmmen och ange dess status till Processing.

3. Orchestrator-poolen skapar ett jobb för varje måttfil som ingår i mätningen. Varje jobb innehåller följande uppgifter:

   Uppgift	Syfte	Kommentar
   Validering	Verifierar att data kan extraheras från mätfilen.	Alla andra aktiviteter är beroende av den här uppgiften.
   Bearbeta metadata	Härleder metadata från mätfilen och berikar filens metadata med hjälp av ett API för att uppdatera filens metadata.
   Process StructuredTopics	Extraherar strukturerade data från en viss måttfil.	Listan med ämnen för att extrahera strukturerade data från skickas som ett konfigurationsobjekt.
   Process CameraTopics	Extraherar bilddata från en viss måttfil.	Listan med ämnen att extrahera bilder från skickas som ett konfigurationsobjekt.
   Process LidarTopics	Extraherar lidar-data från en viss mätfil.	Listan över ämnen som ska extrahera lidar-data från skickas som ett konfigurationsobjekt.
   Process CANTopics	Extraherar CAN-data (Controller Area Network) från en viss måttfil.	Listan med ämnen att extrahera data från skickas som ett konfigurationsobjekt.

4. Orchestrator-poolen övervakar förloppet för varje aktivitet. När alla jobb har slutförts för alla måttfiler anropar poolen ett API för att uppdatera dataströmmen och ange dess status till Completed.

5. Orchestrator avslutas graciöst.

   Kommentar

   Varje uppgift är en separat containeravbildning som har logik som är korrekt definierad för sitt syfte. Uppgifter accepterar konfigurationsobjekt som indata. Indata anger till exempel var utdata ska skrivas och vilken mätfil som ska bearbetas. En matris med ämnestyper, till exempel sensor_msgs/Image, är ett annat exempel på indata. Eftersom alla andra aktiviteter är beroende av valideringsaktiviteten skapas en beroende aktivitet för den. Alla andra uppgifter kan bearbetas separat och kan köras parallellt.

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.

Tillförlitlighet

Tillförlitlighet säkerställer att ditt program kan uppfylla de åtaganden du gör gentemot dina kunder. Mer information finns i Översikt över tillförlitlighetspelare.

• I din lösning bör du överväga att använda Azure-tillgänglighetszoner, som är unika fysiska platser i samma Azure-region.
• Planera för haveriberedskap och redundansväxling av konton.

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.

Det är viktigt att förstå ansvarsfördelningen mellan en oem-tillverkare för bilar och Microsoft. I ett fordon äger OEM-tillverkaren hela stacken, men när data flyttas till molnet överförs vissa ansvarsområden till Microsoft. PaaS-lager (Plattform som en tjänst) i Azure ger inbyggd säkerhet på den fysiska stacken, inklusive operativsystemet. Du kan lägga till följande funktioner i de befintliga infrastruktursäkerhetskomponenterna:

• Identitets- och åtkomsthantering som använder Microsoft Entra-identiteter och principer för villkorsstyrd åtkomst i Microsoft Entra.
• Infrastrukturstyrning som använder Azure Policy.
• Datastyrning som använder Microsoft Purview.
• Kryptering av vilande data som använder inbyggda Azure-lagrings- och databastjänster. Mer information finns i Dataskyddsöverväganden.
• Skydd av kryptografiska nycklar och hemligheter. Använd Azure Key Vault för det här ändamålet.

Kostnadsoptimering

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

Ett viktigt problem för OEM-tillverkare och leverantörer på nivå 1 som driver DataOps för automatiserade fordon är kostnaden för drift. Den här lösningen använder följande metoder för att optimera kostnaderna:

• Dra nytta av olika alternativ som Azure erbjuder för att hantera programkod. Den här lösningen använder App Service och Batch. Vägledning om hur du väljer rätt tjänst för distributionen finns i Välj en Azure-beräkningstjänst.
• Använda datadelning på plats i Azure Storage.
• Optimera kostnader med hjälp av livscykelhantering.
• Spara kostnader på App Service med hjälp av reserverade instanser.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

• Ryan Matsumura | Senior Program Manager
• Jochen Schroeer | Leadarkitekt (Service Line Mobility)
• Brij Singh | Huvudprogramtekniker
• Ginette Vellera | Senior Software Engineering Lead

Om du vill se linkedin-profiler som inte är offentliga loggar du in på LinkedIn.

Nästa steg

• Vad är Azure Batch?
• Vad är Azure Data Factory?
• Introduktion till Azure Data Lake Storage Gen2
• Välkommen till Azure Cosmos DB
• Översikt över App Service
• Vad är Azure Data Share?
• Vad är Azure Data Box?
• Dokumentation om Azure Stack Edge
• Vad är Azure ExpressRoute?
• Vad är Azure Machine Learning?
• Vad är Azure Databricks?
• Vad är Azure Synapse Analytics?
• Översikt över Azure Monitor
• ROS-loggfiler (rosbags)
• Storskalig datadriftsplattform för självkörande fordon

Relaterade resurser

• DESIGNguide för AVOps
• Dataanalys för fordonstestflottor
• Byggstenar för autonoma simuleringsmiljöer
• Bearbeta fordonsdata i realtid med IoT
• Referensarkitektur för fordonsmeddelanden, data och analys