Gegevensbewerkingen voor autonome voertuigbewerkingen

Dit artikel bevat een oplossing en richtlijnen voor het ontwikkelen van offlinegegevensbewerkingen en gegevensbeheer (DataOps) voor een geautomatiseerd rijsysteem. De DataOps-oplossing is gebaseerd op het framework dat wordt beschreven in de ontwerphandleiding voor autonome voertuigbewerkingen (AVOps). DataOps is een van de bouwstenen van AVOps. Andere bouwstenen zijn machine learning-bewerkingen (MLOps), validatiebewerkingen (ValOps), DevOps en gecentraliseerde AVOps-functies.

Apache, Apache® Spark en Apache Parquet zijn gedeponeerde handelsmerken of handelsmerken van de Apache Software Foundation in de Verenigde Staten en/of andere landen. Er wordt geen goedkeuring door de Apache Software Foundation geïmpliceerd door het gebruik van deze markeringen.

Architectuur

Download een Visio-bestand met de architectuurdiagrammen in dit artikel.

Gegevensstroom

1. Meetgegevens zijn afkomstig uit de gegevensstromen van een voertuig. Bronnen zijn camera's, voertuigtelemetrie en radarsensoren, ultrasone en lidarsensoren. Gegevensloggers in het voertuig slaan de meetgegevens op logboekopslagapparaten op. De opslaggegevens van de logboekregistratie worden geüpload naar een landingsdata lake. Een service zoals Azure Data Box of Azure Stack Edge, of een toegewezen verbinding, zoals Azure ExpressRoute, neemt de gegevens op in Azure. Meetgegevens in de volgende indelingen komen terecht in Azure Data Lake Storage: Measurement Data Format versie 4 (MDF4), technical data management systems (TDMS) en rosbag. De geüploade gegevens voeren een toegewezen opslagaccount in met de naam Landing dat is aangewezen voor het ontvangen en valideren van de gegevens.

2. Een Azure Data Factory-pijplijn wordt met een gepland interval geactiveerd om de gegevens in het landingsopslagaccount te verwerken. De pijplijn verwerkt de volgende stappen:

   • Voert een gegevenskwaliteitscontrole uit, zoals een controlesom. Met deze stap worden gegevens van lage kwaliteit verwijderd, zodat alleen gegevens van hoge kwaliteit worden doorgegeven aan de volgende fase. Azure-app Service wordt gebruikt om de kwaliteitscontrolecode uit te voeren. Gegevens die als onvolledig worden beschouwd, worden gearchiveerd voor toekomstige verwerking.
   • Voor het bijhouden van herkomst roept u een metagegevens-API aan met behulp van App Service. Met deze stap worden metagegevens bijgewerkt die zijn opgeslagen in Azure Cosmos DB om een nieuwe gegevensstroom te maken. Voor elke meting is er een onbewerkte gegevensstroom.
   • Kopieert de gegevens naar een opslagaccount met de naam Raw in Data Lake Storage.
   • Roept de metagegevens-API aan om de gegevensstroom als voltooid te markeren, zodat andere onderdelen en services de gegevensstroom kunnen gebruiken.
   • Hiermee worden de metingen gearchiveerd en verwijderd uit het Landing Storage-account.

3. Data Factory en Azure Batch verwerken de gegevens in de onbewerkte zone om informatie te extraheren die downstreamsystemen kunnen gebruiken:

   • Batch leest de gegevens uit onderwerpen in het onbewerkte bestand en voert de gegevens uit in geselecteerde onderwerpen in respectieve mappen.
   • Omdat de bestanden in de onbewerkte zone elk meer dan 2 GB groot kunnen zijn, worden functies voor parallelle verwerkingextractie uitgevoerd op elk bestand. Deze functies extraheren beeldverwerking, lidar, radar en GPS-gegevens. Ze voeren ook metagegevensverwerking uit. Data Factory en Batch bieden een manier om parallellisme op een schaalbare manier uit te voeren.
   • De gegevens worden downsampled om de hoeveelheid gegevens te verminderen die moet worden gelabeld en geannoteerd.

4. Als gegevens van de voertuiglogger niet worden gesynchroniseerd tussen de verschillende sensoren, wordt een Data Factory-pijplijn geactiveerd waarmee de gegevens worden gesynchroniseerd om een geldige gegevensset te maken. Het synchronisatie-algoritme wordt uitgevoerd in Batch.

5. Een Data Factory-pijplijn wordt uitgevoerd om de gegevens te verrijken. Voorbeelden van verbeteringen zijn telemetrie, gegevens van voertuiglogger en andere gegevens, zoals weer-, kaart- of objectgegevens. Verrijkte gegevens helpen gegevenswetenschappers te voorzien van inzichten die ze kunnen gebruiken bij het ontwikkelen van algoritmen, bijvoorbeeld. De gegenereerde gegevens worden bewaard in Apache Parquet-bestanden die compatibel zijn met de gesynchroniseerde gegevens. Metagegevens over de verrijkte gegevens worden opgeslagen in een metagegevensarchief in Azure Cosmos DB.

6. Externe partners voeren handmatige of automatische labels uit. De gegevens worden gedeeld met de externe partners via Azure Data Share en zijn geïntegreerd in Microsoft Purview. Data Share maakt gebruik van een toegewezen opslagaccount met de naam Gelabeld in Data Lake Storage om de gelabelde gegevens terug te geven aan de organisatie.

7. Een Data Factory-pijplijn voert scènedetectie uit. Metagegevens van scènes worden bewaard in het metagegevensarchief. Scènegegevens worden opgeslagen als objecten in Parquet- of Delta-bestanden.

8. Naast metagegevens voor de verrijkingsgegevens en gedetecteerde scènes slaat het metagegevensarchief in Azure Cosmos DB metagegevens op voor de metingen, zoals stationsgegevens. Dit archief bevat ook metagegevens voor de herkomst van de gegevens tijdens het doorlopen van de processen van extractie, downsampling, synchronisatie, verrijking en scènedetectie. De metagegevens-API wordt gebruikt voor toegang tot de metingen, de herkomst en de scènegegevens en om te zoeken waar gegevens worden opgeslagen. Als gevolg hiervan fungeert de metagegevens-API als een opslaglaagbeheerder. Het verspreidt gegevens over opslagaccounts. Het biedt ontwikkelaars ook een manier om een zoekopdracht op basis van metagegevens te gebruiken om gegevenslocaties op te halen. Daarom is het metagegevensarchief een gecentraliseerd onderdeel dat traceerbaarheid en herkomst biedt in de gegevensstroom van de oplossing.

9. Azure Databricks en Azure Synapse Analytics worden gebruikt om verbinding te maken met de metagegevens-API en toegang te krijgen tot Data Lake Storage en onderzoek te doen naar de gegevens.

Onderdelen

• Data Box biedt een manier om op een snelle, goedkope en betrouwbare manier terabytes aan gegevens naar en uit Azure te verzenden. In deze oplossing wordt Data Box gebruikt om verzamelde voertuiggegevens via een regionale vervoerder over te dragen naar Azure.
• Azure Stack Edge-apparaten bieden Azure-functionaliteit op edge-locaties. Voorbeelden van Azure-mogelijkheden zijn rekenkracht, opslag, netwerken en machine learning die versneld zijn voor hardware.
• ExpressRoute breidt een on-premises netwerk uit naar de Microsoft-cloud via een privéverbinding.
• Data Lake Storage bevat een grote hoeveelheid gegevens in de oorspronkelijke, onbewerkte indeling. In dit geval slaat Data Lake Storage gegevens op op basis van fasen, bijvoorbeeld onbewerkt of geëxtraheerd.
• Data Factory is een volledig beheerde, serverloze oplossing voor het maken en plannen van etl-werkstromen (extract, transform, load, load, transform, transform) en ELT-werkstromen (Load, Transform, Transform). Hier voert Data Factory ETL uit via batch-berekening en maakt gegevensgestuurde werkstromen voor het organiseren van gegevensverplaatsing en het transformeren van gegevens.
• Batch voert grootschalige parallelle en HPC-batchtaken (High Performance Computing) efficiënt uit in Azure. Deze oplossing maakt gebruik van Batch om grootschalige toepassingen uit te voeren voor taken zoals gegevens wrangling, filteren en voorbereiden van gegevens en het extraheren van metagegevens.
• Azure Cosmos DB is een wereldwijd gedistribueerde database met meerdere modellen. Hier worden metagegevensresultaten opgeslagen, zoals opgeslagen metingen.
• Data Share deelt gegevens met partnerorganisaties met verbeterde beveiliging. Door in-place delen te gebruiken, kunnen gegevensproviders gegevens delen waar ze zich bevinden zonder de gegevens te kopiëren of momentopnamen te maken. In deze oplossing deelt Data Share gegevens met labelbedrijven.
• Azure Databricks biedt een set hulpprogramma's voor het onderhouden van hoogwaardige gegevensoplossingen op schaal. Het is vereist voor langdurige bewerkingen op grote hoeveelheden voertuiggegevens. Data engineers gebruiken Azure Databricks als een analytics workbench.
• Met Azure Synapse Analytics kunt u minder inzicht krijgen in datawarehouses en big data-systemen.
• Azure Cognitive Search biedt zoekservices voor gegevenscatalogus.
• App Service biedt een serverloze web-app-service. In dit geval host App Service de metagegevens-API.
• Microsoft Purview biedt gegevensbeheer voor organisaties.
• Azure Container Registry is een service waarmee een beheerd register van containerinstallatiekopieën wordt gemaakt. Deze oplossing maakt gebruik van Container Registry om containers op te slaan voor het verwerken van onderwerpen.
• Application Insights is een uitbreiding van Azure Monitor die beheer van toepassingsprestaties biedt. In dit scenario helpt Application Insights u bij het bouwen van waarneembaarheid rond metingextractie: u kunt Application Insights gebruiken om aangepaste gebeurtenissen, aangepaste metrische gegevens en andere informatie te registreren terwijl de oplossing elke meting verwerkt voor extractie. U kunt ook query's maken in Log Analytics om gedetailleerde informatie over elke meting op te halen.

Scenariodetails

Het ontwerpen van een robuust DataOps-framework voor autonome voertuigen is van cruciaal belang voor het gebruik van uw gegevens, het traceren van de herkomst en het beschikbaar maken van gegevens in uw organisatie. Zonder een goed ontworpen DataOps-proces kan de enorme hoeveelheid gegevens die autonome voertuigen genereren snel overweldigend en moeilijk te beheren worden.

Wanneer u een effectieve DataOps-strategie implementeert, zorgt u ervoor dat uw gegevens correct worden opgeslagen, gemakkelijk toegankelijk zijn en een duidelijke herkomst hebben. U maakt het ook eenvoudig om de gegevens te beheren en te analyseren, wat leidt tot meer geïnformeerde besluitvorming en verbeterde voertuigprestaties.

Een efficiënt DataOps-proces biedt een manier om eenvoudig gegevens over uw hele organisatie te distribueren. Verschillende teams hebben vervolgens toegang tot de informatie die ze nodig hebben om hun activiteiten te optimaliseren. Met DataOps kunt u eenvoudig samenwerken en inzichten delen, wat helpt de algehele effectiviteit van uw organisatie te verbeteren.

Typische uitdagingen voor gegevensbewerkingen in de context van autonome voertuigen zijn:

• Beheer van het dagelijkse terabyte- of petabyte-schaalvolume van meetgegevens van onderzoeks- en ontwikkelingsvoertuigen.
• Gegevens delen en samenwerken tussen meerdere teams en partners, bijvoorbeeld voor labels, aantekeningen en kwaliteitscontroles.
• Traceerbaarheid en herkomst voor een veiligheidskritieke perceptiestack die versiebeheer en de herkomst van meetgegevens vastlegt.
• Metagegevens en gegevensdetectie om semantische segmentatie, afbeeldingsclassificatie en objectdetectiemodellen te verbeteren.

Deze AVOps DataOps-oplossing biedt richtlijnen voor het oplossen van deze uitdagingen.

Potentiële gebruikscases

Deze oplossing profiteert van oem's (oem's), leveranciers van laag 1 en onafhankelijke softwareleveranciers (ISV's) die oplossingen ontwikkelen voor geautomatiseerd rijden.

Federatieve gegevensbewerkingen

In een organisatie die AVOps implementeert, dragen meerdere teams bij aan DataOps vanwege de complexiteit die vereist is voor AVOps. Eén team kan bijvoorbeeld verantwoordelijk zijn voor het verzamelen en opnemen van gegevens. Een ander team is mogelijk verantwoordelijk voor het beheer van gegevenskwaliteit van lidar-gegevens. Daarom zijn de volgende principes van een data mesh-architectuur belangrijk om rekening te houden met DataOps:

• Domeingerichte decentralisatie van gegevenseigendom en -architectuur. Eén speciaal team is verantwoordelijk voor één gegevensdomein dat gegevensproducten voor dat domein levert, bijvoorbeeld gelabelde gegevenssets.
• Gegevens als product. Elk gegevensdomein heeft verschillende zones op data lake geïmplementeerde opslagcontainers. Er zijn zones voor intern gebruik. Er is ook een zone met gepubliceerde gegevensproducten voor andere gegevensdomeinen of extern gebruik om duplicatie van gegevens te voorkomen.
• Selfservice voor gegevens als platform om autonome, domeingerichte gegevensteams mogelijk te maken.
• Federatieve governance om interoperabiliteit en toegang mogelijk te maken tussen AVOps-gegevensdomeinen waarvoor een gecentraliseerd metagegevensarchief en een gegevenscatalogus is vereist. Een labelgegevensdomein heeft bijvoorbeeld toegang nodig tot een domein voor gegevensverzameling.

Zie Analyses op cloudschaal voor meer informatie over data mesh-implementaties.

Voorbeeldstructuur voor AVOps-gegevensdomeinen

De volgende tabel bevat enkele ideeën voor het structureren van AVOps-gegevensdomeinen:

Elk AVOps-gegevensdomein wordt ingesteld op basis van een blauwdrukstructuur. Deze structuur omvat Data Factory, Data Lake Storage, databases, Batch en Apache Spark-runtimes via Azure Databricks of Azure Synapse Analytics.

Metagegevens en gegevensdetectie

Elk gegevensdomein is gedecentraliseerd en beheert de bijbehorende AVOps-gegevensproducten afzonderlijk. Voor centrale gegevensdetectie en om te weten waar gegevensproducten zich bevinden, zijn er twee onderdelen vereist:

• Een metagegevensarchief dat metagegevens over verwerkte meetbestanden en gegevensstromen persistent maakt, zoals videoreeksen. Dit onderdeel maakt de gegevens detecteerbaar en traceerbaar met aantekeningen die moeten worden geïndexeerd, zoals het zoeken naar de metagegevens van niet-gelabelde bestanden. U wilt bijvoorbeeld dat het metagegevensarchief alle frames voor specifieke voertuigidentificatienummers (VIN's) of frames met voetgangers of andere verrijkingsobjecten retourneert.
• Een gegevenscatalogus met herkomst, de afhankelijkheden tussen AVOps-gegevensdomeinen en welke gegevensarchieven betrokken zijn bij de AVOps-gegevenslus. Een voorbeeld van een gegevenscatalogus is Microsoft Purview.

U kunt Azure Data Explorer of Azure Cognitive Search gebruiken om een metagegevensarchief uit te breiden dat is gebaseerd op Azure Cosmos DB. Uw selectie is afhankelijk van het laatste scenario dat u nodig hebt voor gegevensdetectie. Gebruik Azure Cognitive Search voor semantische zoekmogelijkheden.

In het volgende diagram van het metagegevensmodel ziet u een typisch uniform metagegevensmodel dat wordt gebruikt voor verschillende AVOps-gegevensluspijlers:

Delen van gegevens

Gegevens delen is een veelvoorkomend scenario in een AVOps-gegevenslus. Maakt gebruik van gegevens delen tussen gegevensdomeinen en extern delen, bijvoorbeeld om labelpartners te integreren. Microsoft Purview biedt de volgende mogelijkheden voor het efficiënt delen van gegevens in een gegevenslus:

• Selfservice voor gegevensdetectie en -toegang
• In-place gegevens delen

Aanbevolen indelingen voor het uitwisselen van labelgegevens omvatten algemene objecten in contextgegevenssets (COCO) en Association for Standardization of Automation and Measuring Systems (ASAM) OpenLABEL-gegevenssets.

In deze oplossing worden de gelabelde gegevenssets gebruikt in MLOps-processen om gespecialiseerde algoritmen zoals perception- en sensorfusiemodellen te maken. De algoritmen kunnen scènes en objecten in een omgeving detecteren, zoals de auto veranderende banen, geblokkeerde wegen, voetgangersverkeer, verkeerslichten en verkeersborden.

Gegevenspijplijn

In deze DataOps-oplossing wordt het verplaatsen van gegevens tussen verschillende fasen in de gegevenspijplijn geautomatiseerd. Door deze aanpak biedt het proces efficiëntie, schaalbaarheid, consistentie, reproduceerbaarheid, aanpassingsvermogen en foutafhandelingsvoordelen. Het verbetert het algehele ontwikkelingsproces, versnelt de voortgang en ondersteunt de veilige en effectieve implementatie van autonome autonoom rijdende technologieën.

In de volgende secties wordt beschreven hoe u gegevensverplaatsing tussen fasen kunt implementeren en hoe u uw opslagaccounts moet structuren.

Hiërarchische mapstructuur

Een goed georganiseerde mapstructuur is een essentieel onderdeel van een gegevenspijplijn in autonome ontwikkeling. Een dergelijke structuur biedt een systematische en gemakkelijk navigeerbare rangschikking van gegevensbestanden, waardoor efficiënt gegevensbeheer en ophalen wordt vergemakkelijkt.

In deze oplossing hebben de gegevens in de onbewerkte map de volgende hiërarchische structuur:

regio/raw/<measurement-ID>/<data-stream-ID>/JJJJ/MM/DD

De gegevens in het geëxtraheerde zoneopslagaccount maken gebruik van een vergelijkbare hiërarchische structuur:

regio/geëxtraheerd/<meting-ID>/<data-stream-ID>/JJJJ/MM/DD

Door vergelijkbare hiërarchische structuren te gebruiken, kunt u profiteren van de hiërarchische naamruimtemogelijkheid van Data Lake Storage. Hiërarchische structuren helpen bij het maken van schaalbare en rendabele objectopslag. Deze structuren verbeteren ook de efficiëntie van het zoeken en ophalen van objecten. Partitionering per jaar en VIN maakt het eenvoudig om te zoeken naar relevante afbeeldingen van specifieke voertuigen. In de data lake wordt een opslagcontainer gemaakt voor elke sensor, zoals een camera, een GPS-apparaat of een lidar- of radarsensor.

Landingsopslagaccount naar Raw-opslagaccount

Een Data Factory-pijplijn wordt geactiveerd op basis van een schema. Nadat de pijplijn is geactiveerd, worden de gegevens gekopieerd van het landingsopslagaccount naar het Raw-opslagaccount.

De pijplijn haalt alle maatmappen op en doorloopt ze. Bij elke meting voert de oplossing de volgende activiteiten uit:

1. Een functie valideert de meting. De functie haalt het manifestbestand op uit het meetmanifest. Vervolgens controleert de functie of alle MDF4-, TDMS- en rosbag-maatbestanden voor de huidige meting aanwezig zijn in de meetmap. Als de validatie slaagt, gaat de functie verder met de volgende activiteit. Als de validatie mislukt, slaat de functie de huidige meting over en gaat deze naar de volgende maateenheidmap.

2. Er wordt een web-API-aanroep uitgevoerd naar een API die een meting maakt en de JSON-nettolading van het JSON-bestand met het meetmanifest wordt doorgegeven aan de API. Als de aanroep slaagt, wordt het antwoord geparseerd om de meet-id op te halen. Als de aanroep mislukt, wordt de meting verplaatst naar de on-error-activiteit voor foutafhandeling.

   Notitie

   Deze DataOps-oplossing is gebaseerd op de veronderstelling dat u het aantal aanvragen voor de app-service beperkt. Als uw oplossing een onbepaald aantal aanvragen kan maken, kunt u een frequentiebeperkingspatroon overwegen.

3. Er wordt een web-API-aanroep uitgevoerd naar een API die een gegevensstroom maakt door de vereiste JSON-nettolading te maken. Als de aanroep slaagt, wordt het antwoord geparseerd om de gegevensstroom-id en de locatie van de gegevensstroom op te halen. Als de aanroep mislukt, wordt de meting verplaatst naar de on-error-activiteit.

4. Er wordt een web-API-aanroep uitgevoerd om de status van de gegevensstroom bij te werken naar Start Copy. Als de aanroep is geslaagd, kopieert de kopieeractiviteit meetbestanden naar de locatie van de gegevensstroom. Als de aanroep mislukt, wordt de meting verplaatst naar de on-error-activiteit.

5. Een Data Factory-pijplijn roept Batch aan om de meetbestanden van het Landing Storage-account naar het Raw-opslagaccount te kopiëren. Een kopieermodule van een orchestrator-app maakt een taak met de volgende taken voor elke meting:

   • Kopieer de meetbestanden naar het Raw-opslagaccount.
   • Kopieer de meetbestanden naar een archiefopslagaccount.
   • Verwijder de meetbestanden uit het landingsopslagaccount.

   Notitie

   In deze taken gebruikt Batch een orchestratorgroep en het AzCopy-hulpprogramma om gegevens te kopiëren en te verwijderen. AzCopy gebruikt SAS-tokens om kopieer- of verwijderingstaken uit te voeren. SAS-tokens worden opgeslagen in een sleutelkluis en waarnaar wordt verwezen met behulp van de termen landingsaskey, archivesaskeyen rawsaskey.

6. Er wordt een web-API-aanroep uitgevoerd om de status van de gegevensstroom bij te werken naar Copy Complete. Als de aanroep slaagt, gaat de reeks verder met de volgende activiteit. Als de aanroep mislukt, wordt de meting verplaatst naar de on-error-activiteit.

7. De meetbestanden worden verplaatst van het Landing Storage-account naar een landingsarchief. Deze activiteit kan een bepaalde meting opnieuw uitvoeren door deze terug te verplaatsen naar het Landing Storage-account via een hydrate copy-pijplijn. Levenscyclusbeheer is ingeschakeld voor deze zone, zodat metingen in deze zone automatisch worden verwijderd of gearchiveerd.

8. Als er een fout optreedt bij een meting, wordt de meting verplaatst naar een foutzone. Van daaruit kan het worden verplaatst naar het Landing Storage-account om opnieuw te worden uitgevoerd. Het levenscyclusbeheer kan de meting ook automatisch verwijderen of archiveren.

Let op de volgende punten:

• Deze pijplijnen worden geactiveerd op basis van een schema. Deze aanpak helpt de traceerbaarheid van pijplijnuitvoeringen te verbeteren en onnodige uitvoeringen te voorkomen.
• Elke pijplijn wordt geconfigureerd met een gelijktijdigheidswaarde van een pijplijn om ervoor te zorgen dat eventuele eerdere uitvoeringen zijn voltooid voordat de volgende geplande uitvoering wordt gestart.
• Elke pijplijn is geconfigureerd om metingen parallel te kopiëren. Als een geplande uitvoering bijvoorbeeld 10 metingen ophaalt om te kopiëren, kunnen de pijplijnstappen gelijktijdig worden uitgevoerd voor alle tien metingen.
• Elke pijplijn is geconfigureerd voor het genereren van een waarschuwing in Monitor als het langer duurt dan de verwachte tijd voordat de pijplijn is voltooid.
• De on-error-activiteit wordt geïmplementeerd in latere waarneembaarheidsverhalen.
• Levenscyclusbeheer verwijdert automatisch gedeeltelijke metingen, bijvoorbeeld metingen met ontbrekende rosbagbestanden.

Batch-ontwerp

Alle extractielogica wordt verpakt in verschillende containerinstallatiekopieën, met één container voor elk extractieproces. Batch voert de containerworkloads parallel uit wanneer er informatie uit meetbestanden wordt geëxtraheerd.

Batch maakt gebruik van een orchestratorpool en een uitvoeringsgroep voor het verwerken van workloads:

• Een orchestratorpool heeft Linux-knooppunten zonder ondersteuning voor containerruntime. De pool voert Python-code uit die gebruikmaakt van de Batch-API voor het maken van taken en taken voor de uitvoeringsgroep. Deze pool bewaakt deze taken ook. Data Factory roept de orchestrator-pool aan, waarmee de containerworkloads worden ingedeeld die gegevens extraheren.
• Een uitvoeringsgroep heeft Linux-knooppunten met containerruntimes ter ondersteuning van actieve containerworkloads. Voor deze pool worden taken en taken gepland via de orchestratorpool. Alle containerinstallatiekopieën die vereist zijn voor verwerking in de uitvoeringsgroep, worden met behulp van JFrog naar een containerregister gepusht. De uitvoeringsgroep is geconfigureerd om verbinding te maken met dit register en de vereiste installatiekopieën op te halen.

Opslagaccounts waaruit gegevens worden gelezen en waarnaar wordt geschreven, worden gekoppeld via NFS 3.0 op de batchknooppunten en de containers die op de knooppunten worden uitgevoerd. Met deze aanpak kunnen batchknooppunten en containers gegevens snel verwerken zonder dat de gegevensbestanden lokaal naar de batchknooppunten hoeven te worden gedownload.

Batch aanroepen vanuit Data Factory

In de extractiepijplijn geeft de trigger het pad door van het metagegevensbestand en het pad naar de onbewerkte gegevensstroom in de pijplijnparameters. Data Factory gebruikt een opzoekactiviteit om de JSON te parseren uit het manifestbestand. De id van de onbewerkte gegevensstroom kan worden geëxtraheerd uit het pad van de onbewerkte gegevensstroom door de pijplijnvariabele te parseren.

Data Factory roept een API aan om een gegevensstroom te maken. De API retourneert het pad voor de geëxtraheerde gegevensstroom. Het geëxtraheerde pad wordt toegevoegd aan het huidige object en Data Factory roept Batch aan via een aangepaste activiteit door het huidige object door te geven nadat het geëxtraheerde gegevensstroompad is toegevoegd:

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

Stapsgewijs extractieproces

1. Data Factory plant een taak met één taak voor de orchestratorpool om een meting voor extractie te verwerken. Data Factory geeft de volgende informatie door aan de orchestratorgroep:

   • De meet-id
   • De locatie van de meetbestanden van het type MDF4, TDMS of rosbag die moeten worden geëxtraheerd
   • Het doelpad van de opslaglocatie van de geëxtraheerde inhoud
   • De geëxtraheerde gegevensstroom-id

2. De orchestratorpool roept een API aan om de gegevensstroom bij te werken en de status ervan in te stellen op Processing.

3. De orchestratorpool maakt een taak voor elk meetbestand dat deel uitmaakt van de meting. Elke taak bevat de volgende taken:

   Opdracht	Doel	Notitie
   Validatie	Valideert dat gegevens kunnen worden geëxtraheerd uit het meetbestand.	Alle andere taken zijn afhankelijk van deze taak.
   Metagegevens verwerken	Hiermee worden metagegevens afgeleid van het meetbestand en worden de metagegevens van het bestand verrijkt met behulp van een API om de metagegevens van het bestand bij te werken.
   Proces StructuredTopics	Extraheert gestructureerde gegevens uit een bepaald meetbestand.	De lijst met onderwerpen waaruit gestructureerde gegevens moeten worden geëxtraheerd, wordt doorgegeven als een configuratieobject.
   Proces CameraTopics	Extraheert afbeeldingsgegevens uit een bepaald meetbestand.	De lijst met onderwerpen waaruit afbeeldingen moeten worden geëxtraheerd, wordt doorgegeven als een configuratieobject.
   Proces LidarTopics	Hiermee worden lidargegevens uit een bepaald meetbestand geëxtraheerd.	De lijst met onderwerpen waaruit lidargegevens moeten worden geëxtraheerd, wordt doorgegeven als een configuratieobject.
   Proces CANTopics	Hiermee worden gegevens van controller area network (CAN) uit een bepaald meetbestand geëxtraheerd.	De lijst met onderwerpen waaruit gegevens moeten worden geëxtraheerd, wordt doorgegeven als een configuratieobject.

4. De orchestratorgroep bewaakt de voortgang van elke taak. Nadat alle taken voor alle meetbestanden zijn voltooid, roept de pool een API aan om de gegevensstroom bij te werken en de status ervan in te stellen op Completed.

5. De orchestrator wordt correct afgesloten.

   Notitie

   Elke taak is een afzonderlijke containerinstallatiekopieën met logica die op de juiste wijze is gedefinieerd voor het doel ervan. Taken accepteren configuratieobjecten als invoer. De invoer geeft bijvoorbeeld aan waar de uitvoer moet worden geschreven en welk meetbestand moet worden verwerkt. Een matrix met onderwerptypen, zoals sensor_msgs/Image, is een ander voorbeeld van invoer. Omdat alle andere taken afhankelijk zijn van de validatietaak, wordt er een afhankelijke taak voor gemaakt. Alle andere taken kunnen onafhankelijk worden verwerkt en kunnen parallel worden uitgevoerd.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.

Betrouwbaarheid

Betrouwbaarheid zorgt ervoor dat uw toepassing kan voldoen aan de toezeggingen die u aan uw klanten hebt gedaan. Zie Overzicht van de betrouwbaarheidspijler voor meer informatie.

• Overweeg in uw oplossing om Azure-beschikbaarheidszones te gebruiken, die unieke fysieke locaties binnen dezelfde Azure-regio zijn.
• Plan herstel na noodgevallen en failover van accounts.

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Overzicht van de beveiligingspijler voor meer informatie.

Het is belangrijk om inzicht te hebben in de verdeling van de verantwoordelijkheid tussen een oem voor auto's en Microsoft. In een voertuig is de OEM eigenaar van de hele stack, maar naarmate de gegevens naar de cloud worden verplaatst, dragen sommige verantwoordelijkheden over naar Microsoft. PaaS-lagen (Platform as a Service) van Azure bieden ingebouwde beveiliging op de fysieke stack, inclusief het besturingssysteem. U kunt de volgende mogelijkheden toevoegen aan de bestaande infrastructuurbeveiligingsonderdelen:

• Identiteits- en toegangsbeheer dat gebruikmaakt van Microsoft Entra-identiteiten en beleid voor voorwaardelijke toegang van Microsoft Entra.
• Infrastructuurbeheer dat gebruikmaakt van Azure Policy.
• Gegevensbeheer dat gebruikmaakt van Microsoft Purview.
• Versleuteling van data-at-rest die gebruikmaakt van systeemeigen Azure-opslag- en databaseservices. Zie Overwegingen voor gegevensbescherming voor meer informatie.
• De beveiliging van cryptografische sleutels en geheimen. Gebruik Azure Key Vault voor dit doel.

Kostenoptimalisatie

Kostenoptimalisatie bekijkt manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie Overzicht van de pijler kostenoptimalisatie voor meer informatie.

Een belangrijke zorg voor OEM's en leveranciers van laag 1 die DataOps voor geautomatiseerde voertuigen gebruiken, zijn de kosten van het gebruik. Deze oplossing maakt gebruik van de volgende procedures om de kosten te optimaliseren:

• Profiteren van verschillende opties die Azure biedt voor het hosten van toepassingscode. Deze oplossing maakt gebruik van App Service en Batch. Zie Een Azure-rekenservice kiezen voor hulp bij het kiezen van de juiste service voor uw implementatie.
• Gegevens delen in azure Storage in-place gebruiken.
• Kosten optimaliseren met behulp van levenscyclusbeheer.
• Kosten besparen op App Service met behulp van gereserveerde instanties.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Belangrijkste auteurs:

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

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

• Wat is Azure Batch?
• Wat is Azure Data Factory?
• Inleiding tot Azure Data Lake Storage Gen2
• Welkom bij Azure Cosmos DB
• Overzicht van App Service
• Wat is Azure Data Share?
• Wat is Azure Data Box?
• Documentatie voor Azure Stack Edge
• Wat is Azure ExpressRoute?
• Wat is Azure Machine Learning?
• Wat is Azure Databricks?
• Wat is Azure Synapse Analytics?
• Overzicht van Azure Monitor
• ROS-logboekbestanden (rosbags)
• Grootschalige Data Operations Platform voor autonome voertuigen

Verwante resources

• AVOps-ontwerphandleiding
• Gegevensanalyse voor autotest fleets
• Bouwstenen voor autonome simulatieomgevingen
• Realtime voertuiggegevens verwerken met Behulp van IoT
• Naslagarchitectuur voor automotive messaging, data & analytics