Naslagarchitectuur voor automotive messaging, data & analytics

Deze referentiearchitectuur is ontworpen ter ondersteuning van auto-OEM's en Mobiliteitsproviders bij de ontwikkeling van geavanceerde toepassingen voor verbonden voertuigen en digitale services. Het doel is om betrouwbare en efficiënte infrastructuur voor berichten, gegevens en analyse te bieden. De architectuur bevat mogelijkheden voor berichtverwerking, opdrachtverwerking en statusopslag om de integratie van verschillende services via beheerde API's te vergemakkelijken. Ook wordt een oplossing voor gegevens en analyses beschreven die zorgt voor de opslag en toegankelijkheid van gegevens op een schaalbare en veilige manier voor digitale engineering en het delen van gegevens met het bredere mobiliteitsecosysteem.

Architectuur

Het architectuurdiagram op hoog niveau toont de belangrijkste logische blokken en services van een automotive messaging- en data & analytics-oplossing. Meer informatie vindt u in de volgende secties.

• Het voertuig bevat een verzameling apparaten. Sommige van deze apparaten zijn software-gedefinieerd en kunnen softwareworkloads uitvoeren die worden beheerd vanuit de cloud. Het voertuig verzamelt en verwerkt een groot aantal gegevens, van sensorinformatie van elektromechanische apparaten zoals het batterijbeheersysteem tot softwarelogboekbestanden.
• De berichtendiensten van het voertuig beheren de communicatie van en naar het voertuig. Het is belast met het verwerken van berichten, het uitvoeren van opdrachten met behulp van werkstromen en het mediateren van het voertuig, de back-end van gebruikers- en apparaatbeheer. Ook wordt het voertuig, apparaat en certificaatregistratie en inrichting bijgehouden.
• De back-end voor voertuig- en apparaatbeheer zijn de OEM-systemen die de voertuigconfiguratie van de fabriek bijhouden tot reparatie en onderhoud.
• De operator heeft IT & operations om de beschikbaarheid en prestaties van zowel voertuigen als back-end te garanderen.
• De data & analytics-services bieden gegevensopslag en maken verwerking en analyse mogelijk voor alle gegevensgebruikers. Hiermee worden gegevens omgezet in inzichten die betere zakelijke beslissingen stimuleren.
• De fabrikant van het voertuig levert digitale diensten als waarde aan de eindklant, van aanvullende apps tot reparatie- en onderhoudstoepassingen.
• Voor verschillende digitale services is bedrijfsintegratie met back-endsystemen vereist, zoals DMS-systemen (Dealer Management), Customer Relationship Management (CRM) of ERP-systemen (Enterprise Resource Planning).
• De back-end voor toestemmingsbeheer maakt deel uit van klantbeheer en houdt gebruikersautorisatie bij voor het verzamelen van gegevens volgens de wetgeving van geografisch land/regio.
• Gegevens die van voertuigen worden verzameld, zijn invoer voor het digitale engineeringproces , met als doel continue productverbeteringen met behulp van analyses en machine learning.
• Het slimme mobiliteitsecosysteem kan zowel live telemetrie als geaggregeerde inzichten abonneren en gebruiken om meer producten en services te bieden.

Microsoft is lid van de Eclipse Software Defined Vehicle-werkgroep , een forum voor open samenwerking met behulp van open source voor voertuigsoftwareplatforms.

Gegevensstroom

De architectuur maakt gebruik van het berichtenpatroon uitgever/abonnee om voertuigen los te koppelen van services.

Voertuig naar cloudberichten

Het voertuig naar de cloudgegevensstroom wordt gebruikt om telemetriegegevens van het voertuig te verwerken. Telemetriegegevens kunnen periodiek worden verzonden (voertuigstatus, verzameling van voertuigsensoren) of op basis van een gebeurtenis (triggers op foutvoorwaarden, reactie op een gebruikersactie).

1. Het voertuig is geconfigureerd voor een klant op basis van de geselecteerde opties met behulp van de Beheer-API's. De configuratie bevat:
   1. Inrichtingsgegevens voor voertuigen en apparaten.
   2. Initiële configuratie van voertuiggegevensverzameling op basis van markt- en bedrijfsoverwegingen.
   3. Opslag van initiële instellingen voor gebruikerstoestemming op basis van voertuigopties en gebruikersacceptatie.
2. Het voertuig publiceert telemetrie- en gebeurtenisberichten via een Message Queuing Telemetry Transport-client (MQTT) met gedefinieerde onderwerpen naar de MQTT-brokerfunctie van Azure Event Grid in de berichtenservices voor voertuigen.
3. Event Grid stuurt berichten naar verschillende abonnees op basis van de onderwerp- en berichtkenmerken.
   1. Berichten met een lage prioriteit waarvoor geen onmiddellijke verwerking is vereist (bijvoorbeeld analyseberichten) worden rechtstreeks doorgestuurd naar de opslag met behulp van een Event Hubs-exemplaar voor buffering.
   2. Berichten met hoge prioriteit waarvoor onmiddellijke verwerking is vereist (bijvoorbeeld statuswijzigingen die moeten worden gevisualiseerd in een gebruikersgerichte toepassing) worden gerouteerd naar een Azure-functie met behulp van een Event Hubs-exemplaar voor buffering.
4. Berichten met lage prioriteit worden rechtstreeks in de data lake opgeslagen met behulp van gebeurtenisopname. Deze berichten kunnen batchdecodering en -verwerking gebruiken voor optimale kosten.
5. Berichten met hoge prioriteit worden verwerkt met een Azure-functie. De functie leest de instellingen voor voertuig-, apparaat- en gebruikerstoestemming uit het apparaatregister en voert de volgende stappen uit:
   1. Controleert of het voertuig en apparaat zijn geregistreerd en actief zijn.
   2. Controleert of de gebruiker toestemming heeft gegeven voor het berichtonderwerp.
   3. Ontsleutelt en verrijkt de nettolading.
   4. Hiermee voegt u meer routeringsinformatie toe.
6. De Live Telemetry Event Hub in de oplossing voor gegevens en analyse ontvangt de gedecodeerde berichten. Azure Data Explorer maakt gebruik van streamingopname om berichten te verwerken en op te slaan wanneer ze worden ontvangen.
7. De digital Services-laag ontvangt gedecodeerde berichten. Service Bus biedt meldingen aan toepassingen over belangrijke wijzigingen/gebeurtenissen over de status van het voertuig. Azure Data Explorer biedt de laatste bekende status van het voertuig en de korte termijngeschiedenis.

Cloud-naar-voertuigberichten

De gegevensstroom van de cloud naar het voertuig wordt vaak gebruikt om externe opdrachten in het voertuig uit te voeren vanuit een digitale service. Deze opdrachten omvatten gebruiksvoorbeelden zoals vergrendelings-/ontgrendelingsdeur, klimaatregeling (voorkeurstemperatuur van de cabine instellen) of configuratiewijzigingen. De geslaagde uitvoering is afhankelijk van de status van het voertuig en kan enige tijd nodig hebben om te voltooien.

Afhankelijk van de voertuigmogelijkheden en het type actie zijn er meerdere mogelijke benaderingen voor het uitvoeren van opdrachten. We behandelen twee variaties:

• Directe cloud naar apparaatberichten (A) waarvoor geen controle van gebruikerstoestemming is vereist en met een voorspelbare reactietijd. Dit omvat berichten voor zowel individuele als meerdere voertuigen. Een voorbeeld hiervan is weermeldingen.
• Voertuigopdrachten (B) die de voertuigstatus gebruiken om succes te bepalen en gebruikerstoestemming te vereisen. De berichtenoplossing moet beschikken over een werkstroomlogica voor opdrachten die gebruikerstoestemming controleert, de uitvoeringsstatus van de opdracht bijhoudt en de digitale service op de hoogte stelt wanneer u klaar bent.

De volgende gegevensstroomgebruikersopdrachten die zijn uitgegeven vanuit een secundaire app digitale services als voorbeeld.

Directe berichten worden uitgevoerd met de minimale hoeveelheid hops voor de best mogelijke prestaties (A):

1. De companion-app is een geverifieerde service die berichten naar Event Grid kan publiceren.
2. Event Grid controleert op autorisatie voor de Companion app Service om te bepalen of berichten naar de opgegeven onderwerpen kunnen worden verzonden.
3. De aanvullende app abonneert zich op reacties van de specifieke combinatie van voertuigen/opdrachten.

Wanneer voor de statusafhankelijke opdrachten van het voertuig gebruikerstoestemming (B) is vereist:

1. De eigenaar/gebruiker van het voertuig geeft toestemming voor het uitvoeren van opdracht- en besturingsfuncties voor een digitale service (in dit voorbeeld een aanvullende app). Dit wordt normaal gesproken gedaan wanneer de gebruiker de app downloadt/activeert en de OEM zijn of haar account activeert. Het activeert een configuratiewijziging op het voertuig om u te abonneren op het bijbehorende opdrachtonderwerp in de MQTT-broker.
2. De bijbehorende app maakt gebruik van de beheerde API voor opdrachten en beheer om de uitvoering van een externe opdracht aan te vragen.
   1. De uitvoering van de opdracht heeft mogelijk meer parameters voor het configureren van opties, zoals time-out, opslag- en doorstuuropties, enzovoort.
   2. De opdrachtlogica bepaalt hoe de opdracht moet worden verwerkt op basis van het onderwerp en andere eigenschappen.
   3. De werkstroomlogica maakt een status om de status van de uitvoering bij te houden
3. De werkstroomlogica van de opdracht controleert op gebruikerstoestemmingsgegevens om te bepalen of het bericht kan worden uitgevoerd.
4. De werkstroomlogica van de opdracht publiceert een bericht naar Event Grid met de opdracht en de parameterwaarden.
5. De berichtenmodule in het voertuig is geabonneerd op het opdrachtonderwerp en ontvangt de melding. Hiermee wordt de opdracht naar de juiste workload gerouteerd.
6. De berichtenmodule bewaakt de werkbelasting op voltooiing (of fout). Een workload is belast met de (fysieke) uitvoering van de opdracht.
7. De berichtenmodule publiceert opdrachtstatusrapporten naar Event Grid.
8. De werkstroommodule is geabonneerd op updates van de opdrachtstatus en werkt de interne status van de uitvoering van de opdracht bij.
9. Zodra de uitvoering van de opdracht is voltooid, ontvangt de service-app het uitvoeringsresultaat via de opdracht- en besturings-API.

Voertuig- en apparaatinrichting

Deze gegevensstroom omvat het proces voor het registreren en inrichten van voertuigen en apparaten voor de berichtendiensten van voertuigen. Het proces wordt doorgaans geïnitieerd als onderdeel van de productie van voertuigen.

1. Het Fabriekssysteem laat het voertuigapparaat aan de gewenste constructiestatus toe. Het kan firmware - en software-initiële installatie en configuratie omvatten. Als onderdeel van dit proces verkrijgt en schrijft het fabriekssysteem het apparaatcertificaat, gemaakt op basis van de Public Key Infrastructure-provider.
2. Het Factory-systeem registreert het voertuig en apparaat met behulp van de Vehicle & Device Provisioning-API.
3. Het fabriekssysteem activeert de client voor apparaatinrichting om verbinding te maken met de apparaatregistratie en het apparaat in te richten. Het apparaat haalt verbindingsgegevens op met de MQTT-broker.
4. De apparaatregistratietoepassing maakt de apparaat-id met MQTT Broker.
5. Het fabriekssysteem activeert het apparaat om voor het eerst verbinding te maken met de MQTT-broker .
   1. De MQTT-broker verifieert het apparaat met behulp van het CA-basiscertificaat en extraheert de clientgegevens.
6. De MQTT-broker beheert autorisatie voor toegestane onderwerpen met behulp van het lokale register.
7. Voor de vervanging van het onderdeel kan het OEM Dealer System de registratie van een nieuw apparaat activeren.

Notitie

Fabriekssystemen zijn meestal on-premises en hebben geen directe verbinding met de cloud.

Data Analytics

Deze gegevensstroom bevat analyses voor voertuiggegevens. U kunt andere gegevensbronnen zoals fabrieks- of workshopoperators gebruiken om voertuiggegevens te verrijken en context te bieden.

1. De servicelaag voor voertuigberichten biedt telemetrie, gebeurtenissen, opdrachten en configuratieberichten van de bidirectionele communicatie naar het voertuig.
2. De IT & Operations-laag biedt informatie over de software die wordt uitgevoerd op het voertuig en de bijbehorende cloudservices.
3. Verschillende pijplijnen bieden de verwerking van de gegevens in een meer verfijnde status
   • Verwerking van onbewerkte gegevens tot verrijkte en ontdubbelde voertuiggegevens.
   • Aggregatie van voertuiggegevens, key performance indicators en inzichten.
   • Het genereren van trainingsgegevens voor machine learning.
4. Verschillende toepassingen verbruiken verfijnde en geaggregeerde gegevens.
   • Visualisatie met behulp van Power BI.
   • Werkstromen voor bedrijfsintegratie met behulp van Logic Apps met integratie in Dataverse.
5. Gegenereerde trainingsgegevens worden gebruikt door hulpprogramma's zoals ML Studio om ML-modellen te genereren.

Schaalbaarheid

Een oplossing voor verbonden voertuigen en gegevens kan worden geschaald naar miljoenen voertuigen en duizenden services. Het wordt aanbevolen om het patroon Implementatiestempels te gebruiken om schaalbaarheid en elasticiteit te bereiken.

Elke voertuigberichtenschaaleenheid ondersteunt een gedefinieerde voertuigpopulatie (bijvoorbeeld voertuigen in een specifieke geografische regio, gepartitioneerd op modeljaar). De schaaleenheid voor toepassingen wordt gebruikt om de services te schalen waarvoor het verzenden of ontvangen van berichten naar de voertuigen is vereist. De algemene service is toegankelijk vanuit elke schaaleenheid en biedt apparaatbeheer- en abonnementsservices voor toepassingen en apparaten.

1. De toepassingsschaaleenheid abonneert toepassingen op berichten die van belang zijn. De algemene service verwerkt het abonnement op de onderdelen van de voertuigberichtenschaaleenheid .
2. Het voertuig maakt gebruik van de apparaatbeheerservice om de toewijzing te detecteren aan een voertuigberichtenschaaleenheid.
3. Indien nodig wordt het voertuig ingericht met behulp van de werkstroom Voertuig en Apparaatinrichting .
4. Het voertuig publiceert een bericht naar de MQTT-broker.
5. Event Grid routeert het bericht met behulp van de abonnementsgegevens.
   1. Voor berichten waarvoor geen verwerking en claimcontrole is vereist, wordt deze doorgestuurd naar een ingress-hub op de bijbehorende toepassingsschaaleenheid.
   2. Berichten waarvoor verwerking is vereist, worden doorgestuurd naar de D2C-verwerkingslogica voor ontsleuteling en autorisatie (gebruikerstoestemming).
6. Toepassingen gebruiken gebeurtenissen van hun app-exemplaar voor inkomend verkeer van event hubs.
7. Toepassingen publiceren berichten voor het voertuig.
   1. Berichten waarvoor geen meer verwerking is vereist, worden gepubliceerd naar de MQTT-broker.
   2. Berichten waarvoor meer verwerking, werkstroombeheer en autorisatie is vereist, worden doorgestuurd naar de relevante C2D-verwerkingslogica via een Event Hubs-exemplaar.

Onderdelen

Deze referentiearchitectuur verwijst naar de volgende Azure-onderdelen.

Connectiviteit

• Met Azure Event Grid kunt u onboarding van apparaten, AuthN/Z en pub-sub via MQTT v5.
• Azure Functions verwerkt de voertuigberichten. Het kan ook worden gebruikt voor het implementeren van beheer-API's waarvoor kortdurende uitvoering is vereist.
• Azure Kubernetes Service (AKS) is een alternatief wanneer de functionaliteit achter de beheerde API's bestaat uit complexe workloads die zijn geïmplementeerd als containertoepassingen.
• Azure Cosmos DB slaat de instellingen voor voertuig-, apparaat- en gebruikerstoestemming op.
• Azure API Management biedt een beheerde API-gateway voor bestaande back-endservices, zoals voertuiglevenscyclusbeheer (inclusief OTA) en beheer van gebruikerstoestemming.
• Azure Batch voert grote rekenintensieve taken efficiënt uit, zoals de opname van communicatietracering van voertuigen.

Gegevens en analyse

• Met Azure Event Hubs kunt u enorme hoeveelheden telemetriegegevens verwerken en opnemen.
• Azure Data Explorer biedt verkenning, curatie en analyse van op tijdreeks gebaseerde voertuigtelemetriegegevens.
• In Azure Blob Storage worden grote documenten (zoals video's en traceringen) en gecureerde voertuiggegevens opgeslagen.
• Azure Databricks biedt een set hulpprogramma's voor het onderhouden van hoogwaardige gegevensoplossingen op schaal. Vereist voor langdurige bewerkingen op grote hoeveelheden voertuiggegevens.

Back-endintegratie

• Azure Logic Apps voert geautomatiseerde werkstromen uit voor bedrijfsintegratie op basis van voertuiggegevens.
• Azure-app Service biedt gebruikersgerichte web-apps en mobiele back-ends, zoals de bijbehorende app.
• Azure Cache voor Redis biedt in-memory caching van gegevens die vaak door gebruikersgerichte toepassingen worden gebruikt.
• Azure Service Bus biedt brokering die de connectiviteit van voertuigen loskoppelt van digitale services en bedrijfsintegratie.

Alternatieven

De selectie van het juiste type rekenproces voor het implementeren van berichtverwerking en beheerde API's is afhankelijk van een groot aantal factoren. Selecteer de juiste service met behulp van de handleiding Een Azure Compute-service kiezen.

Voorbeelden:

• Azure Functions voor gebeurtenisgestuurde, kortdurende processen zoals telemetrieopname.
• Azure Batch voor high-performance computingtaken, zoals het decoderen van grote CAN-tracerings-/videobestanden
• Azure Kubernetes Service voor beheerde, volwaardige indeling van complexe logica, zoals opdracht- en beheerwerkstroombeheer.

Als alternatief voor het delen van gegevens op basis van gebeurtenissen is het ook mogelijk om Azure Data Share te gebruiken als het doel is batchsynchronisatie uit te voeren op data lake-niveau.

Scenariodetails

Automotive OEM's ondergaan een aanzienlijke transformatie naarmate ze overstappen van het produceren van vaste producten tot het aanbieden van verbonden, softwaregedefinieerde voertuigen. Voertuigen bieden een scala aan functies, zoals over-the-air updates, externe diagnostische gegevens en gepersonaliseerde gebruikerservaringen. Met deze overgang kunnen OEM's hun producten continu verbeteren op basis van realtime gegevens en inzichten, terwijl ook hun bedrijfsmodellen worden uitgebreid met nieuwe services en omzetstromen.

Met deze referentiearchitectuur kunnen automobielfabrikanten en mobiliteitsproviders:

• Gebruik feedbackgegevens als onderdeel van het digitale engineeringproces om continue productverbetering te stimuleren, proactief de hoofdoorzaken van problemen op te lossen en nieuwe klantwaarde te creëren.
• Bied nieuwe digitale producten en services en digitaliseer bewerkingen met bedrijfsintegratie met back-endsystemen zoals Enterprise Resource Planning (ERP) en Customer Relationship Management (CRM).
• Gegevens veilig delen en voldoen aan land-/regiospecifieke vereisten voor gebruikerstoestemming met de bredere slimme Mobility-ecosystemen.
• Integreren met back-endsystemen voor het beheer van de levenscyclus van voertuigen en toestemmingsbeheer vereenvoudigt en versnelt de implementatie en het beheer van verbonden voertuigoplossingen met behulp van een Software Defined Vehicle DevOps Toolchain.
• Sla berekeningen op schaal op voor voertuigen en analyses.
• Beheer de connectiviteit van voertuigen met miljoenen apparaten op een rendabele manier.

Potentiële gebruikscases

OEM Automotive use cases gaan over het verbeteren van de prestaties, veiligheid en gebruikerservaring van het voertuig.

• Continue productverbetering: de prestaties van voertuigen verbeteren door realtime gegevens te analyseren en updates op afstand toe te passen.
• Technische test vlootvalidatie: veiligheid en betrouwbaarheid van voertuigen garanderen door gegevens van testvloten te verzamelen en te analyseren.
• Companion App & User Portal: Het inschakelen van toegang en beheer van externe voertuigen via een gepersonaliseerde app en webportal.
• Proactief herstel en onderhoud: voertuigonderhoud voorspellen en plannen op basis van gegevensgestuurde inzichten.

Bredere gebruiksscenario's voor ecosystemen breiden verbonden voertuigtoepassingen uit om vlootactiviteiten, verzekeringen, marketing en hulp bij de weg in het hele transportlandschap te verbeteren.

• Verbonden commerciële vlootoperaties: vlootbeheer optimaliseren via realtime bewaking en gegevensgestuurde besluitvorming.
• Digital Vehicle Insurance: Aanpassing van verzekeringspremies op basis van rijgedrag en onmiddellijke ongevallenrapportage.
• Locatiegebaseerde marketing: gerichte marketingcampagnes leveren aan chauffeurs op basis van hun locatie en voorkeuren.
• Hulp bij de weg: realtime ondersteuning en hulp bieden aan bestuurders in nood, met behulp van voertuiglocatie en diagnostische gegevens.

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 horizontale schaalaanpassing om betrouwbaarheid toe te voegen.
• Gebruik schaaleenheden om geografische regio's te isoleren met verschillende voorschriften.
• Automatisch schalen en gereserveerde instanties: rekenresources beheren door dynamisch te schalen op basis van vraag en kosten te optimaliseren met vooraf toegewezen instanties.
• Georedundantie: repliceer gegevens over meerdere geografische locaties voor fouttolerantie en herstel na noodgevallen.

Beveiliging

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

• Voertuigverbinding beveiligen: zie de sectie over certificaatbeheer om te begrijpen hoe u X.509-certificaten gebruikt om beveiligde voertuigcommunicatie tot stand te brengen.

Kostenoptimalisatie

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

• Overwegingen voor kosten per voertuig: de communicatiekosten moeten afhankelijk zijn van het aantal aangeboden digitale diensten. Bereken de RoI van de digitale diensten op basis van de operationele kosten.
• Bepaal procedures voor kostenanalyse op basis van berichtverkeer. Verbonden voertuigverkeer neemt meestal toe met de tijd naarmate er meer services worden toegevoegd.
• Overweeg netwerken en mobiele kosten
  • Gebruik de MQTT-onderwerpalias om het verkeersvolume te verminderen.
  • Gebruik een efficiënte methode om nettoladingberichten te coderen en comprimeren.
• Verkeersafhandeling
  • Berichtprioriteit: voertuigen hebben meestal herhalende gebruikspatronen die dagelijkse/wekelijkse vraagpieken creëren. Gebruik berichteigenschappen om de verwerking van niet-kritieke of analytische berichten te vertragen om de belasting te vereffenen en het resourcegebruik te optimaliseren.
  • Automatisch schalen op basis van vraag.
• Bedenk hoe lang de gegevens moeten worden opgeslagen: dynamisch/warm/koud.
• Overweeg het gebruik van gereserveerde instanties om de kosten te optimaliseren.

Operationele uitmuntendheid

Operationele uitmuntendheid omvat de operationele processen die een toepassing implementeren en deze in productie houden. Zie Overzicht van de operationele uitmuntendheidpijler voor meer informatie.

• Overweeg om de voertuigsoftware (logboeken/metrische gegevens/traceringen), de berichtenservices, de data & analytics-services en gerelateerde back-endservices te bewaken als onderdeel van geïntegreerde IT-bewerkingen.

Prestatie-efficiëntie

Prestatie-efficiëntie is de mogelijkheid om op efficiënte wijze uw werkbelasting te schalen om te voldoen aan de vereisten die gebruikers eraan stellen. Zie overzicht van de pijler Prestatie-efficiëntie voor meer informatie.

• Overweeg het schaalconcept te gebruiken voor oplossingen die hoger zijn dan 50.000 apparaten, speciaal als er meerdere geografische regio's nodig zijn.
• Overweeg zorgvuldig de beste manier om gegevens op te nemen (berichten, streaming of batched).
• Overweeg de beste manier om de gegevens te analyseren op basis van use-case.

Volgende stappen

• Maak een AVOps-oplossing (Autonomous Vehicle Operations) voor een breder overzicht van auto-digitale engineering voor autonoom en ondersteund rijden.

Verwante resources

In de volgende artikelen worden enkele van de concepten besproken die in de architectuur worden gebruikt:

• Claimcontrolepatroon wordt gebruikt ter ondersteuning van het verwerken van grote berichten, zoals bestandsuploads.
• Implementatiestempels hebben betrekking op de algemene concepten die nodig zijn om de oplossing te schalen naar miljoenen voertuigen.
• Beperking beschrijft het concept dat een uitzonderlijk aantal berichten van voertuigen moet verwerken.

In de volgende artikelen worden interacties tussen onderdelen in de architectuur beschreven:

• Streamingopname configureren in uw Azure Data Explorer-cluster
• Event Hubs-gegevens vastleggen in parquet-indeling en analyseren met Azure Synapse Analytics