Redigera

Dela via

Dataanalys för fordonstestflottor

Azure Blob Storage
Azure Data Explorer
Azure Event Hubs
Azure Functions
Azure IoT Hub

Oem-tillverkare för fordon behöver lösningar för att minimera tiden mellan att göra provkörningar och att få diagnostikdata för provkörning till R&D-tekniker. I takt med att fordonen blir mer automatiserade blir programvarulivscyklerna kortare och digitala feedbackslingor måste bli snabbare. Ny teknik kan demokratisera dataåtkomst och ge R&D-tekniker nästan realtidsinsikter om diagnostikdata för testkörningar. Säker datadelning kan förbättra samarbetet mellan OEM-tillverkare och leverantörer, vilket ytterligare förkortar utvecklingscyklerna.

Det här exemplet gäller både telemetri- och batchtestkörningsdatainmatningsscenarier. Arbetsbelastningen fokuserar på den dataplattform som bearbetar diagnostikdata och anslutningsappar för visualisering och rapportering.

Arkitektur

Diagram som visar analysdataflödet för strömmande fordonsdata och filer.

Ladda ned en PowerPoint-fil med alla diagram i den här artikeln.

Dataflöde

  1. Azure IoT Hub matar in live, rådata (A) och laddar upp inspelade datafiler (B) från fordonet.

  2. IoT Hub skickar livetelemetrin (A) till en Azure Functions-app som avkodar telemetrin till JavaScript Object Notation (JSON) och publicerar den till Azure Event Hubs.

    IoT Hub skickar de inspelade datafilerna (B) till Azure Blob Storage. En slutförd filuppladdning utlöser en Functions-app som avkodar data och skriver den avkodade filen till Blob Storage i ett CSV-format (kommaavgränsade värden) som är lämpligt för inmatning.

  3. Azure Data Explorer matar in avkodade JSON-telemetridata från Event Hubs (A) till en rådatatelemetritabell och matar in de avkodade CSV-filerna (B) från Blob Storage.

  4. Azure Data Explorer använder Update funktionen för att expandera JSON-data till ett lämpligt radformat och för att utöka data. Funktionen klustrade till exempel platsdata för geospatial analys.

  5. Dataexperter och R&D-tekniker använder funktioner för Kusto-frågespråk (KQL) för att skapa analysanvändningsfall som de lagrar som användardefinierade funktioner. KQL-funktioner omfattar plugin-program för aggregering, tidsserieanalys, geospatial klustring, fönster och maskininlärning (ML).

  6. Power BI använder Dynamisk fråga för att skapa visualiseringar med användardefinierade frågor. Plugin-programmet grafanadatakälla för Azure Data Explorer använder användardefinierade frågor för nästan realtidsuppdateringar.

  7. En Azure App Service-app använder Azure Kartor funktioner för återgivning av datakällor för att visualisera användardefinierade frågeresultat som använder GeoJSON-format.

  8. Azure API Management ger åtkomst till lagrade rådatafiler från fordon och ett konfigurations-API som hanterar principer för datainsamling från tredje part.

Azure Data Explorer-schema

Diagram som visar funktionerna och metoderna i Azure Data Explorer för att extrahera, expandera och berika data.

  1. Funktionen Update() använder metoder som:

    • mv-expand() för att expandera komplexa värden som lagras i JSON-strukturer till rader med enskilda signaler.
    • geo_point_to_h3cell() eller geo_point_to_geohash() konvertera latitud och longitud till geohashes för geospatial analys.
    • todouble() och tostring() för att omvandla extraherade värden från dynamiska JSON-objekt till lämpliga datatyper.

  2. Vyn Senaste kända värden för fleet-metadata kopplar samman andra vyer som en del av inmatningen för att tillhandahålla kontext. Historiska metadata för flottan är användbara om nya användningsfall kräver ombearbetning av råtelemetrin.

  3. Vid behov används take_any() en materialiserad signaluppdaterad vy för att deduplicera signaler.

  4. Den materialiserade vyn Signal senast kända värden använder arg_max() tidsstämpeln för realtidsrapportering.

  5. Den materialiserade vyn Signals Downsampled aggregerar signaler med hjälp av fördefinierade lagerplatser, till exempel varje timme och dagligen , för att förenkla rapporteringen i hela flottan.

  6. Lagrade plugin-funktioner som DetectAnomaly() att hitta avvikelser i dataserier. ML-plugin-program som autokluster hittar vanliga mönster för diskreta attribut.

  7. Funktionen GetGeospatial() genererar GeoJSON-filer som innehåller grupperade signaler efter geohashes.

Komponenter

Följande viktiga tekniker implementerar den här arbetsbelastningen:

Alternativ

Azure Batch är ett bra alternativ för komplex filkodning. Det här scenariot omfattar ett stort antal filer över 300 megabyte som kräver olika avkodningsalgoritmer baserat på filversion eller typ.

Diagram som visar en alternativ Azure Batch-metod för avkodning av komplexa filer.

  1. När du laddar upp en inspelad datafil till Blob Storage utlöses en Functions-app för att schemalägga avkodning.
  2. Functions-appen skapar ett batchjobb med hänsyn till filtyp, storlek och nödvändig avkodningsalgoritm. Appen väljer en lämplig virtuell dator (VM) från poolen och startar jobbet.
  3. När jobbet är klart skriver Batch den resulterande avkodade filen tillbaka till Blob Storage. Den här filen måste vara lämplig för direkt inmatning i ett format som Stöds av Azure Data Explorer.
  4. När du laddar upp en avkodad signalfil till Blob Storage utlöses en funktion som matar in data i Azure Data Explorer. Den här funktionen skapar tabellen och datamappningen vid behov och startar inmatningsprocessen.
  5. Azure Data Explorer matar in datafilerna direkt från Blob Storage.

Den här metoden erbjuder följande fördelar:

  • Azure Functions- och Batch-pooler kan hantera skalbara databearbetningsuppgifter på ett robust och effektivt sätt.
  • Batchpooler ger insikter om bearbetningsstatistik, uppgiftsköer och batchpoolens hälsa. Du kan visualisera status, identifiera problem och köra misslyckade uppgifter igen.
  • Kombinationen av Azure Functions och Azure Batch stöder plug-and-play-bearbetning i Docker-containrar.

Information om scenario

Oem-tillverkare för fordon använder stora fordonsflottor av prototyp- och testfordon för att testa och verifiera alla typer av fordonsfunktioner. Testprocedurer är dyra, eftersom verkliga förare och fordon måste vara inblandade, och vissa specifika verkliga scenarier för vägtester måste passera flera gånger. Integreringstestning är särskilt viktigt för att utvärdera interaktioner mellan elektriska, elektroniska och mekaniska komponenter i komplexa system.

För att verifiera fordonsfunktioner och analysera avvikelser och fel måste gigabyte diagnostikdata samlas in från elektroniska styrenheter (ECUs), datornoder, fordonskommunikationsbussar som Controller Area Network (CAN) och Ethernet och sensorer. Tidigare lagrade små dataloggarservrar i fordonen diagnostikdata lokalt som huvuddatabas (MDF), multimediefusionstillägg (MFX), CSV- eller JSON-filer. När testenheterna var klara laddade servrarna upp diagnostikdata till datacenter, som bearbetade dem och gav dem till R&D-tekniker för analys. Den här processen kan ta timmar eller ibland dagar. Nyare scenarier använder telemetriinmatningsmönster som MQTT-baserade synkrona dataströmmar (Message Queuing Telemetry Transport) eller filuppladdningar i nära realtid.

Potentiella användningsfall

  • Fordonshantering utvärderar prestanda och insamlade data per fordon i flera testscenarier.
  • System- och komponentvalidering använder insamlade fordonsdata för att verifiera att beteendet för fordonskomponenter faller inom driftsgränserna över resor.
  • Avvikelseidentifiering letar upp avvikelsemönster för ett sensorvärde i förhållande till dess typiska baslinjemönster i realtid.
  • Rotorsaksanalys använder ML-plugin-program som klustringsalgoritmer för att identifiera ändringar i fördelningen av värden på flera dimensioner.
  • Förutsägande underhåll kombinerar flera datakällor, berikade platsdata och telemetri för att förutsäga komponentens tid till fel.
  • Hållbarhetsutvärderingen använder förarens beteende och energiförbrukning för att utvärdera miljöpåverkan från fordonsdrift.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som du kan använda 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.

  • Azure-tillgänglighetszoner är unika fysiska platser i samma Azure-region. Tillgänglighetszoner kan skydda Azure Data Explorer-beräkningskluster och data från partiella regionfel.
  • Med affärskontinuitet och haveriberedskap (BCDR) i Azure Data Explorer kan ditt företag fortsätta att fungera efter avbrott.
  • Överväg att använda en uppföljningsdatabas i Azure Data Explorer för att separera beräkningsresurser mellan användningsfall för produktion och icke-produktion.

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 fordons-OEM och Microsoft. I fordonet äger OEM-tillverkaren hela stacken, men när data flyttas till molnet överförs vissa ansvarsområden till Microsoft. Azure Platform-as-a-Service (PaaS) ger inbyggd säkerhet på den fysiska stacken, inklusive operativsystemet. Du kan använda följande funktioner ovanpå infrastruktursäkerhetskomponenterna.

Alla dessa funktioner hjälper fordonsoperativsystem att skapa en säker miljö för sina fordonstelemetridata. Mer information finns i Säkerhet i Azure Data Explorer.

Kostnadsoptimering

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

Den här lösningen använder följande metoder för att optimera kostnaderna:

  • Konfigurera frekventa cacheminnen och kall lagring för tabellerna Raw och Signals. Cacheminnet för frekventa data lagras i RAM-minne eller SSD och ger bättre prestanda. Kalla data är dock 45 gånger billigare. Ange en princip för frekvent cache som är lämplig för ditt användningsfall, till exempel 30 dagar.
  • Konfigurera en kvarhållningsprincip för tabellerna Raw och Signals. Fastställ när signaldata inte längre är relevanta, till exempel efter 365 dagar, och ange kvarhållningsprincipen i enlighet med detta.
  • Tänk på vilka signaler som är relevanta för analys.
  • Använd materialiserade vyer när du frågar efter de senast kända signalvärdena, signalerna deduplicerade och signalerna nedsamplade. Materialiserade vyer förbrukar färre resurser än källtabellsammansättningar för varje fråga.
  • Överväg dina dataanalysbehov i realtid. När du konfigurerar strömmande inmatning för tabellen livetelemetri kan du få svarstider på mindre än en sekund mellan inmatning och fråga, men till en högre kostnad för fler CPU-cykler.

Prestandaeffektivitet

Prestandaeffektivitet är arbetsbelastningens förmåga att skala effektivt för att uppfylla användarnas krav. Mer information finns i Översikt över grundpelare för prestandaeffektivitet.

  • Om antalet och storleken på registrerade datafiler är större än 1 000 filer eller 300 MB per dag kan du överväga att använda Azure Batch för avkodning.
  • Överväg att utföra vanliga beräkningar och analyser efter inmatning och lagra dem i ytterligare tabeller.

Distribuera det här scenariot

Om du vill distribuera Azure Data Explorer och mata in MDF-filer kan du följa den stegvisa självstudien som visar hur du distribuerar en kostnadsfri instans, parsar MDF-filer , matar in och utför några grundläggande frågor.

Deltagare

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

Huvudsakliga författare:

Övriga medarbetare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg