Referensarkitektur för fordonsmeddelanden, data och analys

  • Artikel

Den här referensarkitekturen är utformad för att stödja oem-tillverkare och mobilitetsleverantörer för fordon i utvecklingen av avancerade program för anslutna fordon och digitala tjänster. Målet är att tillhandahålla tillförlitlig och effektiv infrastruktur för meddelanden, data och analys. Arkitekturen innehåller funktioner för meddelandebearbetning, kommandobearbetning och tillståndslagring för att underlätta integreringen av olika tjänster via hanterade API:er. Den beskriver också en data- och analyslösning som säkerställer lagring och tillgänglighet för data på ett skalbart och säkert sätt för digital teknik och datadelning med det bredare mobilitetsekosystemet.

Arkitektur

Diagram över arkitekturen på hög nivå.

Arkitekturdiagrammet på hög nivå visar de viktigaste logiska blocken och tjänsterna för en lösning för fordonsmeddelanden, data och analys. Mer information finns i följande avsnitt.

  • Fordonet innehåller en samling enheter. Vissa av dessa enheter är Programvarudefinierade och kan köra programvaruarbetsbelastningar som hanteras från molnet. Fordonet samlar in och bearbetar en mängd olika data, från sensorinformation från elektromekaniska enheter, till exempel batterihanteringssystemet till loggfiler för programvara.
  • Meddelandetjänsterna för fordon hanterar kommunikationen till och från fordonet. Den ansvarar för att bearbeta meddelanden, köra kommandon med hjälp av arbetsflöden och förmedla fordons-, användar- och enhetshanteringsserverdelen. Den håller också reda på registrering och etablering av fordon, enheter och certifikat.
  • Serverdelen för fordons- och enhetshantering är OEM-system som håller reda på fordonskonfigurationen från fabrik till reparation och underhåll.
  • Operatören har IT-åtgärder för att säkerställa tillgänglighet och prestanda för både fordon och serverdel.
  • Data - och analystjänsterna tillhandahåller datalagring och möjliggör bearbetning och analys för alla dataanvändare. Det omvandlar data till insikter som ger bättre affärsbeslut.
  • Fordonstillverkaren tillhandahåller digitala tjänster som värdetillägg till slutkund, från tillhörande appar till reparations- och underhållsprogram.
  • Flera digitala tjänster kräver affärsintegrering till serverdelssystem som Dealer Management (DMS), Crm-system (Customer Relationship Management) eller ERP-system (Enterprise Resource Planning).
  • Serverdelen för medgivandehantering är en del av kundhanteringen och håller reda på användarauktorisering för datainsamling enligt lagstiftningen om geografiskt land/region.
  • Data som samlas in från fordon är indata till den digitala teknikprocessen , med målet att kontinuerligt förbättra produkten med hjälp av analys och maskininlärning.
  • Ekosystemet för smart mobilitet kan prenumerera och använda både live-telemetri och aggregerade insikter för att tillhandahålla fler produkter och tjänster.

Microsoft är medlem i eclipse software defined vehicle working group, ett forum för öppet samarbete med öppen källkod för programvaruplattformar för fordon.

Dataflöde

Arkitekturen använder meddelandemönstret utgivare/prenumerant för att frikoppla fordon från tjänster.

Meddelanden från fordon till molnet

Dataflödet mellan fordon och moln används för att bearbeta telemetridata från fordonet. Telemetridata kan skickas regelbundet (fordonstillstånd, insamling från fordonssensorer) eller baserat på en händelse (utlösare vid feltillstånd, reaktion på en användaråtgärd).

Diagram över meddelandedataflödet.

  1. Fordonet är konfigurerat för en kund baserat på de valda alternativen med hjälp av hanterings-API:er. Konfigurationen innehåller:
    1. Etableringsinformation för fordon och enheter.
    2. Inledande konfiguration av fordonsdatainsamling baserat på marknads- och affärsöverväganden.
    3. Lagring av inledande inställningar för användarmedgivande baserat på fordonsalternativ och godkännande av användare.
  2. Fordonet publicerar telemetri- och händelsemeddelanden via en MQTT-klient (Message Queuing Telemetry Transport) med definierade ämnen till Azure Event Grids MQTT-koordinatorfunktion i fordonsmeddelandetjänsterna.
  3. Event Grid dirigerar meddelanden till olika prenumeranter baserat på ämnes- och meddelandeattribut.
    1. Meddelanden med låg prioritet som inte kräver omedelbar bearbetning (till exempel analysmeddelanden) dirigeras direkt till lagring med hjälp av en Event Hubs-instans för buffring.
    2. Meddelanden med hög prioritet som kräver omedelbar bearbetning (till exempel statusändringar som måste visualiseras i ett användarbaserat program) dirigeras till en Azure-funktion med hjälp av en Event Hubs-instans för buffring.
  4. Meddelanden med låg prioritet lagras direkt i datasjön med hjälp av händelseinsamling. Dessa meddelanden kan använda batchkodning och bearbetning för optimala kostnader.
  5. Meddelanden med hög prioritet bearbetas med en Azure-funktion. Funktionen läser inställningarna för fordons-, enhets- och användarmedgivande från enhetsregistret och utför följande steg:
    1. Verifierar att fordonet och enheten är registrerade och aktiva.
    2. Verifierar att användaren har gett sitt medgivande till meddelandeavsnittet.
    3. Avkodar och berikar nyttolasten.
    4. Lägger till mer routningsinformation.
  6. Live Telemetry Event Hub i data - och analyslösningentar emot de avkodade meddelandena. Azure Data Explorer använder strömmande inmatning för att bearbeta och lagra meddelanden när de tas emot.
  7. Det digitala tjänstlagret tar emot avkodade meddelanden. Service Bus tillhandahåller meddelanden till program om viktiga ändringar/händelser i fordonets tillstånd. Azure Data Explorer tillhandahåller det senaste kända tillståndet för fordonet och den kortsiktiga historiken.

Meddelanden från moln till fordon

Dataflödet från molnet till fordon används ofta för att köra fjärrkommandon i fordonet från en digital tjänst. Dessa kommandon omfattar användningsfall som lås/upplåsningsdörr, klimatkontroll (ange önskad kabintemperatur) eller konfigurationsändringar. Den lyckade körningen beror på fordonets tillstånd och kan kräva lite tid att slutföra.

Beroende på fordonets funktioner och typ av åtgärd finns det flera möjliga metoder för kommandokörning. Vi går igenom två varianter:

  • Dirigera molnet till enhetsmeddelanden (A) som inte kräver en kontroll av användarmedgivande och med en förutsägbar svarstid. Detta omfattar meddelanden till både enskilda och flera fordon. Ett exempel inkluderar väderaviseringar.
  • Fordonskommandon (B) som använder fordonstillstånd för att fastställa framgång och kräva användarmedgivande. Meddelandelösningen måste ha en kommandoarbetsflödeslogik som kontrollerar användarens medgivande, håller reda på kommandots körningstillstånd och meddelar den digitala tjänsten när det är klart.

Följande dataflödesanvändare kommandon som utfärdats från en tillhörande app digitala tjänster som ett exempel.

Diagram över kommando- och kontrolldataflödet.

Direktmeddelanden körs med den minsta mängden hopp för bästa möjliga prestanda (A):

  1. Kompletterande app är en autentiserad tjänst som kan publicera meddelanden till Event Grid.
  2. Event Grid söker efter auktorisering för appen Companion Service för att avgöra om den kan skicka meddelanden till de angivna ämnena.
  3. Kompletterande app prenumererar på svar från den specifika fordons-/kommandokombinationen.

När fordonstillståndsberoende kommandon kräver användarmedgivande (B):

  1. Fordonsägaren/användaren ger medgivande för körning av kommando- och kontrollfunktioner till en digital tjänst (i det här exemplet en tillhörande app). Det görs normalt när användaren laddar ned/aktiverar appen och OEM-tillverkaren aktiverar sitt konto. Det utlöser en konfigurationsändring på fordonet för att prenumerera på det associerade kommandoavsnittet i MQTT-koordinatorn.
  2. Den tillhörande appen använder kommando- och kontrollhanterat API för att begära körning av ett fjärrkommando.
    1. Kommandokörningen kan ha fler parametrar för att konfigurera alternativ som timeout, lagring och vidarebefordran osv.
    2. Kommandologiken bestämmer hur kommandot ska bearbetas baserat på ämnet och andra egenskaper.
    3. Arbetsflödeslogik skapar ett tillstånd för att hålla reda på körningens status
  3. Logiken för kommandoarbetsflödet kontrollerar om meddelandet kan köras mot information om användarens medgivande.
  4. Logiken för kommandoarbetsflödet publicerar ett meddelande till Event Grid med kommandot och parametervärdena.
  5. Meddelandemodulen i fordonet prenumererar på kommandoavsnittet och tar emot meddelandet. Kommandot dirigeras till rätt arbetsbelastning.
  6. Meddelandemodulen övervakar arbetsbelastningen för slutförande (eller fel). En arbetsbelastning ansvarar för (fysisk) körning av kommandot.
  7. Meddelandemodulen publicerar kommandostatusrapporter till Event Grid.
  8. Arbetsflödesmodulen prenumererar på kommandostatusuppdateringar och uppdaterar det interna tillståndet för kommandokörning.
  9. När kommandokörningen är klar tar tjänstappen emot körningsresultatet via kommando- och kontroll-API:et.

Etablering av fordon och enhet

Det här dataflödet omfattar processen för att registrera och etablera fordon och enheter till fordonens meddelandetjänster. Processen initieras vanligtvis som en del av fordonstillverkningen.

Diagram över etableringsdataflödet.

  1. Fabrikssystemet beställer fordonsenheten till önskat byggtillstånd. Den kan innehålla inbyggd programvara och inledande installation och konfiguration av programvara. Som en del av den här processen hämtar och skriver fabrikssystemet enhetscertifikatet som skapats från providern för infrastruktur för offentlig nyckel.
  2. Fabrikssystemet registrerar fordonet och enheten med hjälp av API:et för fordons- och enhetsetablering.
  3. Fabrikssystemet utlöser enhetsetableringsklienten för att ansluta till enhetsregistreringen och etablera enheten. Enheten hämtar anslutningsinformation till MQTT-koordinatorn.
  4. Enhetsregistreringsprogrammet skapar enhetsidentiteten med MQTT Broker.
  5. Fabrikssystemet utlöser enheten för att upprätta en anslutning till MQTT-koordinatorn för första gången.
    1. MQTT-koordinatorn autentiserar enheten med ca-rotcertifikatet och extraherar klientinformationen.
  6. MQTT-koordinatorn hanterar auktorisering för tillåtna ämnen med hjälp av det lokala registret.
  7. För att ersätta en del kan OEM-återförsäljarsystemet utlösa registreringen av en ny enhet.

Kommentar

Fabrikssystem är vanligtvis lokala och har ingen direkt anslutning till molnet.

Dataanalys

Det här dataflödet omfattar analys av fordonsdata. Du kan använda andra datakällor som fabriks- eller verkstadsoperatorer för att berika och ge kontext till fordonsdata.

Diagram över dataanalysen.

  1. Tjänstlagret för fordonsmeddelanden tillhandahåller telemetri, händelser, kommandon och konfigurationsmeddelanden från den dubbelriktade kommunikationen till fordonet.
  2. IT- och driftlagret innehåller information om programvaran som körs på fordonet och tillhörande molntjänster.
  3. Flera pipelines ger bearbetning av data till ett mer förfinat tillstånd
    • Bearbetning från rådata till berikade och deduplicerade fordonsdata.
    • Fordonsdataaggregation, viktiga prestandaindikatorer och insikter.
    • Generation av träningsdata för maskininlärning.
  4. Olika program förbrukar raffinerade och aggregerade data.
    • Visualisering med Power BI.
    • Arbetsflöden för affärsintegrering med hjälp av Logic Apps med integrering i dataversum.
  5. Genererade träningsdata används av verktyg som ML Studio för att generera ML-modeller.

Skalbarhet

En ansluten fordons- och datalösning kan skalas till miljontals fordon och tusentals tjänster. Vi rekommenderar att du använder mönstret Distributionsstämplar för att uppnå skalbarhet och elasticitet.

Diagram över skalbarhetskonceptet.

Varje enhet för meddelandehantering för fordon stöder en definierad fordonspopulation (till exempel fordon i en specifik geografisk region, partitionerad efter modellår). Programskalningsenheten används för att skala de tjänster som kräver att meddelanden skickas eller tas emot till fordonen. Den gemensamma tjänsten är tillgänglig från alla skalningsenheter och tillhandahåller enhetshanterings- och prenumerationstjänster för program och enheter.

  1. Programskalningsenheten prenumererar program på intressanta meddelanden. Common Service hanterar prenumerationen på enhetskomponenterna för fordonsmeddelandeskalning .
  2. Fordonet använder enhetshanteringstjänsten för att identifiera tilldelningen till en enhet för meddelandeskalning av fordon.
  3. Om det behövs etableras fordonet med hjälp av arbetsflödet För etablering av fordon och enhet .
  4. Fordonet publicerar ett meddelande till MQTT-koordinatorn.
  5. Event Grid dirigerar meddelandet med hjälp av prenumerationsinformationen.
    1. För meddelanden som inte kräver bearbetning och anspråkskontroll dirigeras det till en ingresshubb på motsvarande programskalningsenhet.
    2. Meddelanden som kräver bearbetning dirigeras till D2C-bearbetningslogik för avkodning och auktorisering (användarmedgivande).
  6. Program använder händelser från instansen av appens ingresshändelsehubbar .
  7. Program publicerar meddelanden för fordonet.
    1. Meddelanden som inte kräver mer bearbetning publiceras till MQTT-asynkron meddelandekö.
    2. Meddelanden som kräver mer bearbetning, arbetsflödeskontroll och auktorisering dirigeras till relevant C2D-bearbetningslogik över en Event Hubs-instans.

Komponenter

Den här referensarkitekturen refererar till följande Azure-komponenter.

Anslutning

  • Med Azure Event Grid kan du registrera enheter, AuthN/Z och pub-sub via MQTT v5.
  • Azure Functions bearbetar fordonsmeddelandena. Den kan också användas för att implementera hanterings-API:er som kräver kortlivad körning.
  • Azure Kubernetes Service (AKS) är ett alternativ när funktionerna bakom hanterade API:er består av komplexa arbetsbelastningar som distribueras som containerbaserade program.
  • Azure Cosmos DB lagrar inställningar för fordons-, enhets- och användarmedgivande.
  • Azure API Management tillhandahåller en hanterad API-gateway till befintliga serverdelstjänster som hantering av fordonslivscykel (inklusive OTA) och hantering av användarmedgivande.
  • Azure Batch kör stora beräkningsintensiva uppgifter effektivt, till exempel spårningsinmatning för fordonskommunikation.

Data och analys

  • Med Azure Event Hubs kan du bearbeta och mata in enorma mängder telemetridata.
  • Azure Data Explorer tillhandahåller utforskning, kuration och analys av tidsseriebaserade fordonstelemetridata.
  • Azure Blob Storage lagrar stora dokument (till exempel videor och kan spåra) och granskade fordonsdata.
  • Azure Databricks tillhandahåller en uppsättning verktyg för att underhålla datalösningar i företagsklass i stor skala. Krävs för tidskrävande åtgärder på stora mängder fordonsdata.

Serverdelsintegrering

  • Azure Logic Apps kör automatiserade arbetsflöden för affärsintegrering baserat på fordonsdata.
  • Azure App Service tillhandahåller användarriktade webbappar och mobila serverdelar, till exempel den tillhörande appen.
  • Azure Cache for Redis tillhandahåller minnesintern cachelagring av data som ofta används av användarinriktade program.
  • Azure Service Bus tillhandahåller koordinatortjänster som frikopplar fordonsanslutningen från digitala tjänster och affärsintegrering.

Alternativ

Valet av rätt typ av beräkning för att implementera meddelandebearbetning och hanterade API:er beror på en mängd olika faktorer. Välj rätt tjänst med hjälp av guiden Välj en Azure-beräkningstjänst .

Exempel:

  • Azure Functions för händelsedrivna, kortvariga processer som telemetriinmatning.
  • Azure Batch för databehandling med höga prestanda, till exempel avkodning av stora CAN-spårnings-/videofiler
  • Azure Kubernetes Service för hanterad, fullständig orkestrering av komplex logik, till exempel hantering av kommando- och kontrollarbetsflöden.

Som ett alternativ till händelsebaserad datadelning är det också möjligt att använda Azure Data Share om målet är att utföra batchsynkronisering på datasjönivå.

Information om scenario

Diagram över vyn på hög nivå.

Oem-tillverkare för fordon genomgår en betydande omvandling när de övergår från att producera fasta produkter till att erbjuda anslutna, programvarudefinierade fordon. Fordon erbjuder en rad funktioner, till exempel uppdateringar via luften, fjärrdiagnostik och anpassade användarupplevelser. Den här övergången gör det möjligt för OEM-tillverkare att kontinuerligt förbättra sina produkter baserat på realtidsdata och insikter samtidigt som deras affärsmodeller utökas till att omfatta nya tjänster och intäktsströmmar.

Med den här referensarkitekturen kan fordonstillverkare och mobilitetsleverantörer:

  • Använd feedbackdata som en del av den digitala teknikprocessen för att driva kontinuerlig produktförbättring, proaktivt åtgärda rotorsaker till problem och skapa nytt kundvärde.
  • Tillhandahålla nya digitala produkter och tjänster och digitalisera verksamheten med affärsintegrering med backend-system som Enterprise Resource Planning (ERP) och Customer Relationship Management (CRM).
  • Dela data på ett säkert sätt och hantera lands-/regionspecifika krav för användarmedgivande med de bredare ekosystemen för smart mobilitet.
  • Integrera med serverdelssystem för hantering av fordonslivscykel och medgivandehantering förenklar och påskyndar distributionen och hanteringen av anslutna fordonslösningar med hjälp av en DevOps-verktygskedja för programvarudefinierade fordon.
  • Lagra och tillhandahålla beräkning i stor skala för fordon och analys.
  • Hantera fordonsanslutning till miljontals enheter på ett kostnadseffektivt sätt.

Potentiella användningsfall

OEM Automotive användningsfall handlar om att förbättra fordonets prestanda, säkerhet och användarupplevelse.

  • Kontinuerlig produktförbättring: Förbättra fordonsprestanda genom att analysera realtidsdata och fjärrtillämpa uppdateringar.
  • Validering av teknisk testflotta: Säkerställa fordonssäkerhet och tillförlitlighet genom att samla in och analysera data från testflottor.
  • Tilläggsapp och användarportal: Aktivera åtkomst och kontroll för fjärrfordon via en anpassad app och webbportal.
  • Proaktiv reparation och underhåll: Förutsäga och schemalägga fordonsunderhåll baserat på datadrivna insikter.

Bredare användningsfall för ekosystem utökar anslutna fordonsapplikationer för att förbättra flottans verksamhet, försäkring, marknadsföring och vägassistans i hela transportlandskapet.

  • Anslut verksamhet i den kommersiella flottan: Optimera vagnparkshanteringen genom realtidsövervakning och datadrivet beslutsfattande.
  • Digital Fordonsförsäkring: Anpassa försäkringspremier baserat på körbeteende och tillhandahålla omedelbar olycksrapportering.
  • Platsbaserad marknadsföring: Leverera riktade marknadsföringskampanjer till förare baserat på deras plats och inställningar.
  • Väghjälp: Ge stöd och hjälp i realtid till behövande förare, med hjälp av fordonsplats och diagnostikdata.

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.

  • Överväg horisontell skalning för att öka tillförlitligheten.
  • Använd skalningsenheter för att isolera geografiska regioner med olika regler.
  • Automatisk skalning och reserverade instanser: hantera beräkningsresurser genom att dynamiskt skala baserat på efterfrågan och optimera kostnader med förallokerade instanser.
  • Geo-redundans: replikera data över flera geografiska platser för feltolerans och haveriberedskap.

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.

  • Skydda fordonsanslutning: Se avsnittet om certifikathantering för att förstå hur du använder X.509-certifikat för att upprätta säker fordonskommunikation.

Kostnadsoptimering

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

  • Överväganden för kostnad per fordon: Kommunikationskostnaderna bör vara beroende av antalet digitala tjänster som erbjuds. Beräkna roI för de digitala tjänsterna mot åtgärdskostnaderna.
  • Upprätta metoder för kostnadsanalys baserat på meddelandetrafik. Anslut fordonstrafiken tenderar att öka med tiden när fler tjänster läggs till.
  • Överväg nätverks- och mobilkostnader
    • Använd MQTT-ämnesalias för att minska trafikvolymen.
    • Använd en effektiv metod för att koda och komprimera nyttolastmeddelanden.
  • Trafikhantering
    • Meddelandeprioritet: fordon tenderar att ha upprepade användningsmönster som skapar dagliga/veckovisa efterfrågetoppar. Använd meddelandeegenskaper för att fördröja bearbetningen av icke-kritiska eller analytiska meddelanden för att jämna ut belastningen och optimera resursanvändningen.
    • Autoskalning baserat på efterfrågan.
  • Fundera på hur länge data ska lagras varm/varm/kall.
  • Överväg att använda reserverade instanser för att optimera kostnaderna.

Driftsäkerhet

Driftskvalitet omfattar de driftsprocesser som distribuerar ett program och håller det igång i produktion. Mer information finns i Översikt över grundpelare för driftskvalitet.

  • Överväg att övervaka fordonsprogramvaran (loggar/mått/spårningar), meddelandetjänsterna, data- och analystjänsterna och relaterade serverdelstjänster som en del av enhetliga IT-åtgärder.

Prestandaeffektivitet

Prestandaeffektivitet handlar om att effektivt skala arbetsbelastningen baserat på användarnas behov. Mer information finns i Översikt över grundpelare för prestandaeffektivitet.

  • Överväg att använda skalningskonceptet för lösningar som skalar över 50 000 enheter, särskilt om flera geografiska regioner krävs.
  • Överväg noggrant det bästa sättet att mata in data (meddelanden, strömning eller batchbaserad).
  • Överväg det bästa sättet att analysera data baserat på användningsfall.

Nästa steg

  • Skapa en AVOps-lösning (Autonomous Vehicle Operations) för en bredare titt på digital fordonsteknik för autonom och assisterad körning.

Följande artiklar beskriver några av de begrepp som används i arkitekturen:

  • Mönster för anspråkskontroll används för bearbetning av stora meddelanden, till exempel filuppladdningar.
  • Distributionsstämplar omfattar de allmänna begrepp som krävs för att skala lösningen till miljontals fordon.
  • Begränsning beskriver det begrepp som krävs för att hantera exceptionellt många meddelanden från fordon.

I följande artiklar beskrivs interaktioner mellan komponenter i arkitekturen: