Sdílet prostřednictvím

Referenční architektura pro zasílání zpráv v automobilovém průmyslu, dat a analýzách

  • Článek

Tato referenční architektura je navržená tak, aby podporovala automobilové výrobce OEM a poskytovatele mobility při vývoji pokročilých propojených aplikací vozidel a digitálních služeb. Jejím cílem je poskytovat spolehlivou a efektivní infrastrukturu zasílání zpráv, dat a analýz. Architektura zahrnuje možnosti zpracování zpráv, zpracování příkazů a úložiště stavu, které usnadňují integraci různých služeb prostřednictvím spravovaných rozhraní API. Popisuje také řešení pro analýzu dat, které zajišťuje ukládání a přístupnost dat škálovatelným a zabezpečeným způsobem pro digitální inženýrství a sdílení dat s širším ekosystémem mobility.

Architektura

Diagram architektury vysoké úrovně

Diagram architektury vysoké úrovně znázorňuje hlavní logické bloky a služby automobilového zasílání zpráv, řešení pro analýzu dat a dat. Další podrobnosti najdete v následujících částech.

  • Vozidlo obsahuje kolekci zařízení. Některá z těchto zařízení jsou softwarově definovaná a můžou spouštět softwarové úlohy spravované z cloudu. Vozidlo shromažďuje a zpracovává širokou škálu dat, od informací ze snímačů z elektromechanických zařízení, jako je systém správy baterie, až po soubory protokolů softwaru.
  • Služby zasílání zpráv vozidel spravují komunikaci s vozidlem a z vozidla. Zodpovídá za zpracování zpráv, spouštění příkazů pomocí pracovních postupů a zprostředkovávání vozidla, back-endu správy uživatelů a zařízení. Také sleduje registraci a zřizování vozidel, zařízení a certifikátů.
  • Back-end správy vozidel a zařízení jsou systémy OEM, které sledují konfiguraci vozidel od továrny po opravu a údržbu.
  • Operátor má IT a provoz , aby zajistil dostupnost a výkon obou vozidel i back-endu.
  • Služby pro analýzu dat poskytují úložiště dat a umožňují zpracování a analýzu pro všechny uživatele dat. Mění data na přehledy, které řídí lepší obchodní rozhodnutí.
  • Výrobce vozidel poskytuje digitální služby jako hodnotu přidanou koncovému zákazníkovi, od doprovodných aplikací až po aplikace pro opravu a údržbu.
  • Několik digitálních služeb vyžaduje obchodní integraci do back-endových systémů, jako jsou systémy DMS (Dealer Management), Customer Relationship Management (CRM) nebo Erp (Enterprise Resource Planning).
  • Back-end správy souhlasu je součástí správy zákazníků a sleduje autorizaci uživatelů pro shromažďování dat podle geografických právních předpisů země/oblasti.
  • Data shromážděná z vozidel jsou vstupem do procesu digitálního inženýrství s cílem nepřetržitého vylepšování produktů pomocí analýz a strojového učení.
  • Ekosystém inteligentní mobility se může přihlásit k odběru živé telemetrie a využívat je i agregované přehledy, které poskytují více produktů a služeb.

Microsoft je členem pracovní skupiny Eclipse Software Defined Vehicle , fórum pro otevřenou spolupráci pomocí open source pro softwarové platformy vozidel.

Tok dat

Architektura používá model zasílání zpráv vydavatele/odběratele k oddělení vozidel od služeb.

Zprávy z vozidla do cloudu

Vozidlo do cloudu se používá ke zpracování telemetrických dat z vozidla. Telemetrická data je možné odesílat pravidelně (stav vozidla, shromažďování ze senzorů vozidel) nebo na základě události (triggery v chybových podmínkách, reakce na akci uživatele).

Diagram toku dat pro zasílání zpráv

  1. Vozidlo je nakonfigurované pro zákazníka na základě vybraných možností pomocí rozhraní API pro správu. Konfigurace obsahuje:
    1. Zřizování informací pro vozidla a zařízení
    2. Počáteční konfigurace shromažďování dat vozidel na základě obchodních aspektů a trhu.
    3. Uložení počátečního nastavení souhlasu uživatele na základě možností vozidla a přijetí uživatele.
  2. Vozidlo publikuje telemetrická data a zprávy událostí prostřednictvím klienta MQTT (Message Queuing Telemetry Transport) s definovanými tématy do funkce zprostředkovatele MQTT služby Azure Event Grid ve službách zasílání zpráv vozidel.
  3. Event Grid směruje zprávy různým odběratelům na základě atributů tématu a zpráv.
    1. Zprávy s nízkou prioritou, které nevyžadují okamžité zpracování (například analytické zprávy), se směrují přímo do úložiště pomocí instance služby Event Hubs pro ukládání do vyrovnávací paměti.
    2. Zprávy s vysokou prioritou, které vyžadují okamžité zpracování (například změny stavu, které musí být vizualizovány v aplikaci určené pro uživatele), se směrují do funkce Azure Functions pomocí instance služby Event Hubs pro ukládání do vyrovnávací paměti.
  4. Zprávy s nízkou prioritou se ukládají přímo v datovém jezeře pomocí zachytávání událostí. Tyto zprávy mohou používat dávkové dekódování a zpracování pro optimální náklady.
  5. Zprávy s vysokou prioritou se zpracovávají pomocí funkce Azure. Funkce přečte nastavení souhlasu vozidla, zařízení a uživatele z registru zařízení a provede následující kroky:
    1. Ověřuje, že vozidlo a zařízení jsou zaregistrované a aktivní.
    2. Ověří, že uživatel udělil souhlas s tématem zprávy.
    3. Dekóduje a rozšiřuje datovou část.
    4. Přidá další informace o směrování.
  6. Centrum událostí živé telemetrie v řešení pro analýzu dat přijímá dekódované zprávy. Azure Data Explorer používá příjem streamovaných dat ke zpracování a ukládání zpráv při jejich přijetí.
  7. Vrstva digitálních služeb přijímá dekódované zprávy. Service Bus poskytuje oznámení aplikacím o důležitých změnách nebo událostech ve stavu vozidla. Azure Data Explorer poskytuje poslední známý stav vozidla a krátkodobou historii.

Zprávy z cloudu do vozidel

Tok dat z cloudu do vozidel se často používá ke spouštění vzdálených příkazů ve vozidle z digitální služby. Mezi tyto příkazy patří případy použití, jako jsou zámky/odemknutí dveří, klimatizace (nastavení upřednostňované teploty kabiny) nebo změny konfigurace. Úspěšné provedení závisí na stavu vozidla a může trvat nějakou dobu.

V závislosti na schopnostech a typu akce vozidla existuje několik možných přístupů k provádění příkazů. Probereme dvě varianty:

  • Nasměrujte cloud na zprávy zařízení (A), které nevyžadují kontrolu souhlasu uživatele a s předvídatelnou dobou odezvy. Týká se to zpráv pro jednotlivá i více vozidel. Příkladem jsou oznámení o počasí.
  • Příkazy vozidel (B), které používají stav vozidla k určení úspěchu a vyžadují souhlas uživatele. Řešení zasílání zpráv musí mít logiku pracovního postupu příkazu, která kontroluje souhlas uživatele, sleduje stav spuštění příkazu a po dokončení oznámí digitální službě.

Příkladem jsou následující příkazy uživatelů toku dat vydané z digitálních služeb doprovodné aplikace.

Diagram příkazu a řízení toku dat

Přímé zprávy se provádějí s minimálním počtem segmentů směrování pro nejlepší možný výkon (A):

  1. Doprovodná aplikace je ověřená služba, která může publikovat zprávy do Event Gridu.
  2. Event Grid kontroluje autorizaci služby Companion App Service a zjišťuje, jestli může odesílat zprávy do zadaných témat.
  3. Doprovodná aplikace se přihlásí k odběru odpovědí z konkrétní kombinace vozidla nebo příkazu.

Pokud příkazy závislé na stavu vozidla vyžadují souhlas uživatele (B)::

  1. Vlastník vozidla nebo uživatel uděluje souhlas s prováděním řídicích a řídicích funkcí digitální službě (v tomto příkladu doprovodné aplikace). Obvykle se provádí, když uživatel stáhne nebo aktivuje aplikaci a OEM aktivuje svůj účet. Aktivuje změnu konfigurace ve vozidle, aby se přihlásil k odběru přidruženého tématu příkazu v zprostředkovateli MQTT.
  2. Doprovodná aplikace používá k vyžádání spuštění vzdáleného příkazu příkaz a řízení spravovaného rozhraní API.
    1. Spuštění příkazu může mít více parametrů pro konfiguraci možností, jako jsou vypršení časového limitu, ukládání a předávání atd.
    2. Logika příkazu rozhoduje, jak příkaz zpracovat na základě tématu a dalších vlastností.
    3. Logika pracovního postupu vytvoří stav, který bude sledovat stav provádění.
  3. Logika pracovního postupu příkazu kontroluje informace o souhlasu uživatele, aby určila, jestli je možné zprávu spustit.
  4. Logika pracovního postupu příkazu publikuje zprávu do Event Gridu pomocí příkazu a hodnot parametrů.
  5. Modul zasílání zpráv ve vozidle se přihlásí k odběru tématu příkazu a obdrží oznámení. Směruje příkaz do správné úlohy.
  6. Modul zasílání zpráv monitoruje úlohy pro dokončení (nebo chybu). Úloha má na starosti (fyzické) provedení příkazu.
  7. Modul zasílání zpráv publikuje zprávy o stavu příkazů do Event Gridu.
  8. Modul pracovního postupu se přihlásí k odběru aktualizací stavu příkazu a aktualizuje interní stav provádění příkazů.
  9. Po dokončení provádění příkazu aplikace služby obdrží výsledek spuštění přes rozhraní API pro příkaz a řízení.

Zřizování vozidel a zařízení

Tento tok dat se zabývá procesem registrace a zřizování vozidel a zařízení pro služby zasílání zpráv vozidel. Tento proces je obvykle zahájen jako součást výroby vozidel.

Diagram zřizovacího toku dat

  1. Systém továrny zprovozní zařízení vozidla do požadovaného stavu konstrukce. Může obsahovat počáteční instalaci a konfiguraci firmwaru a softwaru. V rámci tohoto procesu získá a zapíše certifikát zařízení vytvořený z poskytovatele infrastruktury veřejných klíčů.
  2. Systém továrny zaregistruje vozidlo a zařízení pomocí rozhraní API pro zřizování vozidel a zařízení.
  3. Systém továrny aktivuje klienta zřizování zařízení, aby se připojil k registraci zařízení a zřídil zařízení. Zařízení načte informace o připojení ke zprostředkovateli MQTT.
  4. Aplikace pro registraci zařízení vytvoří identitu zařízení pomocí zprostředkovatele MQTT.
  5. Systém továrny aktivuje zařízení tak, aby poprvé navázalo připojení ke zprostředkovateli MQTT.
    1. Zprostředkovatel MQTT ověřuje zařízení pomocí kořenového certifikátu certifikační autority a extrahuje informace o klientovi.
  6. Zprostředkovatel MQTT spravuje autorizaci pro povolená témata pomocí místního registru.
  7. U náhradní části může systém OEM Dealer System aktivovat registraci nového zařízení.

Poznámka:

Systémy továrny jsou obvykle místní a nemají přímé připojení ke cloudu.

Analýza dat

Tento tok dat se zabývá analýzou dat o vozidlech. K obohacení a poskytování kontextu dat dat můžete použít jiné zdroje dat, jako je továrna nebo operátor workshopu.

Diagram analýzy dat

  1. Vrstva služeb zasílání zpráv vozidel poskytuje telemetrii, události, příkazy a konfigurační zprávy z obousměrné komunikace s vozidlem.
  2. Vrstva IT a provoz poskytuje informace o softwaru běžícím na vozidle a přidružených cloudových službách.
  3. Několik kanálů poskytuje zpracování dat do přesnějšího stavu.
    • Zpracování z nezpracovaných dat na rozšířená a odstraněná data vozidel
    • Agregace dat vozidel, klíčové ukazatele výkonu a přehledy.
    • Generování trénovacích dat pro strojové učení
  4. Různé aplikace využívají zpřesněná a agregovaná data.
    • Vizualizace pomocí Power BI
    • Pracovní postupy obchodní integrace s využitím Logic Apps s integrací do Služby Dataverse
  5. Vygenerovaná trénovací data využívají nástroje, jako je ML Studio k vygenerování modelů ML.

Škálovatelnost

Propojené řešení vozidel a dat se může škálovat na miliony vozidel a tisíce služeb. K dosažení škálovatelnosti a elasticity se doporučuje použít model Razítka nasazení.

Diagram konceptu škálovatelnosti

Každá jednotka škálování zasílání zpráv vozidel podporuje definovanou populaci vozidel (například vozidla v konkrétní geografické oblasti rozdělené podle modelu roku). Jednotka škálování aplikací slouží ke škálování služeb, které vyžadují odesílání nebo příjem zpráv do vozidel. Běžná služba je přístupná z jakékoli jednotky škálování a poskytuje služby správy zařízení a předplatných pro aplikace a zařízení.

  1. Jednotka škálování aplikace odebírá aplikace k odběru zpráv, které jsou zajímavé. Běžná služba zpracovává odběr součástí jednotek škálování zasílání zpráv vozidel.
  2. Vozidlo používá službu správy zařízení ke zjištění jejího přiřazení k jednotce škálování zasílání zpráv vozidel.
  3. V případě potřeby je vozidlo zřízeno pomocí pracovního postupu zřizování vozidel a zařízení.
  4. Vozidlo publikuje zprávu do zprostředkovatele MQTT.
  5. Event Grid směruje zprávu pomocí informací o odběru.
    1. U zpráv, které nevyžadují kontrolu zpracování a deklarací identity, se směruje do centra příchozího přenosu dat v odpovídající jednotce škálování aplikace.
    2. Zprávy, které vyžadují zpracování, se směrují do logiky zpracování D2C pro dekódování a autorizaci (souhlas uživatele).
  6. Aplikace spotřebovávají události z instance centra událostí příchozího přenosu dat aplikace.
  7. Aplikace publikují zprávy pro vozidlo.
    1. Zprávy, které nevyžadují další zpracování, se publikují do zprostředkovatele MQTT.
    2. Zprávy, které vyžadují větší zpracování, řízení pracovního postupu a autorizaci, se směrují do příslušné logiky zpracování C2D přes instanci služby Event Hubs.

Komponenty

Tato referenční architektura odkazuje na následující komponenty Azure.

Připojení

  • Azure Event Grid umožňuje onboarding zařízení, AuthN/Z a pub-sub prostřednictvím MQTT v5.
  • Azure Functions zpracovává zprávy o vozidle. Dá se také použít k implementaci rozhraní API pro správu, která vyžadují krátkodobé spuštění.
  • Azure Kubernetes Service (AKS) je alternativou, když se funkce spravovaných rozhraní API skládají ze složitých úloh nasazených jako kontejnerizované aplikace.
  • Azure Cosmos DB ukládá nastavení souhlasu s vozidlem, zařízením a uživatelem.
  • Azure API Management poskytuje spravovanou bránu rozhraní API stávajícím back-endovým službám, jako je správa životního cyklu vozidel (včetně OTA) a správa souhlasu uživatele.
  • Azure Batch efektivně spouští velké výpočetní úlohy, jako je příjem trasování komunikace vozidel.

Data a analýzy

  • Azure Event Hubs umožňuje zpracovávat a ingestovat obrovské objemy telemetrických dat.
  • Azure Data Explorer poskytuje zkoumání, kurátorování a analýzu telemetrických dat vozidel založených na časových řadách.
  • Azure Blob Storage ukládá velké dokumenty (jako jsou videa a můžou trasovat) a kurátorovaná data vozidel.
  • Azure Databricks poskytuje sadu nástrojů pro správu datových řešení na podnikové úrovni ve velkém měřítku. Vyžaduje se pro dlouhotrvající operace s velkými objemy dat o vozidlech.

Integrace back-endu

  • Azure Logic Apps spouští automatizované pracovní postupy pro obchodní integraci na základě dat o vozidlech.
  • služba Aplikace Azure poskytuje uživatelské webové aplikace a mobilní back-endy, jako je doprovodná aplikace.
  • Azure Cache for Redis poskytuje ukládání dat do mezipaměti v paměti, které často používají aplikace přístupné uživatelům.
  • Azure Service Bus poskytuje zprostředkující oddělení připojení vozidel od digitálních služeb a obchodní integrace.

Alternativy

Výběr správného typu výpočetních prostředků pro implementaci zpracování zpráv a spravovaných rozhraní API závisí na mnoha faktorech. Vyberte správnou službu pomocí průvodce Zvolit výpočetní službu Azure.

Příklady:

  • Azure Functions pro krátkodobé procesy řízené událostmi, jako je příjem telemetrie.
  • Azure Batch pro vysokovýkonné výpočetní úlohy, jako je dekódování velkých souborů CAN Trace / Videosoubory
  • Azure Kubernetes Service pro spravovanou plnohodnotnou orchestraci komplexní logiky, jako je správa pracovních postupů a řízení příkazů.

Jako alternativu ke sdílení dat založeným na událostech je také možné použít Službu Azure Data Share , pokud je cílem provést dávkovou synchronizaci na úrovni datového jezera.

Podrobnosti scénáře

Diagram zobrazení vysoké úrovně

Automobilový výrobce OEM prochází významnou transformací, protože přechází z výroby pevných produktů na nabídku připojených softwarově definovaných vozidel. Vozidla nabízejí řadu funkcí, jako jsou aktualizace nad vzduchem, vzdálená diagnostika a přizpůsobené uživatelské prostředí. Díky tomuto přechodu můžou OEM průběžně zlepšovat své produkty na základě dat a přehledů v reálném čase a zároveň rozšiřovat své obchodní modely tak, aby zahrnovaly nové služby a datové proudy výnosů.

Tato referenční architektura umožňuje výrobcům automobilů a poskytovatelům mobility:

  • Data zpětné vazby můžete využít jako součást procesu digitálního inženýrství k zajištění průběžného zlepšování produktů, proaktivně řešit hlavní příčiny problémů a vytvářet novou hodnotu zákazníka.
  • Poskytovat nové digitální produkty a služby a digitalizovat operace s obchodní integrací s back-endovými systémy, jako je plánování podnikových zdrojů (ERP) a řízení vztahů se zákazníky (CRM).
  • Bezpečně sdílejte data a vyřešte požadavky specifické pro jednotlivé země/oblasti pro vyjádření souhlasu uživatelů s širšími ekosystémy inteligentní mobility.
  • Integrace s back-endovými systémy pro správu životního cyklu vozidel a správa souhlasu zjednodušuje a urychluje nasazování a správu připojených řešení vozidel pomocí sady nástrojů DevOps definovaného softwaru.
  • Ukládejte a zajistěte výpočetní prostředky ve velkém měřítku pro vozidla a analýzy.
  • Správa připojení vozidel k milionům zařízení nákladově efektivním způsobem

Potenciální případy použití

Případy použití OEM Automotive se týkají zvýšení výkonu, bezpečnosti a uživatelského prostředí.

  • Průběžné vylepšování produktů: Zvýšení výkonu vozidel analýzou dat v reálném čase a vzdáleným použitím aktualizací.
  • Ověřování technického testovacího parku: Zajištění bezpečnosti a spolehlivosti vozidel shromažďováním a analýzou dat z testovacích parků.
  • Doprovodná aplikace a portál User Portal: Povolení vzdáleného přístupu a řízení vozidel prostřednictvím přizpůsobené aplikace a webového portálu
  • Proaktivní oprava a údržba: Předpověď a plánování údržby vozidel na základě přehledů řízených daty

Širší případy použití ekosystému rozšiřují propojené aplikace vozidel za účelem zlepšení provozu vozového parku, pojištění, marketingu a silniční pomoci v celém dopravním prostředí.

  • Propojené komerční flotily: Optimalizace správy vozového parku prostřednictvím monitorování v reálném čase a rozhodování na základě dat.
  • Digitální pojištění vozidel: Přizpůsobení pojistného pojištění na základě chování při řízení a poskytování okamžitého hlášení nehod.
  • Marketing založený na poloze: Doručování cílových marketingových kampaní pro řidiče na základě jejich polohy a preferencí.
  • Silniční pomoc: Poskytování podpory a pomoci řidičům v reálném čase, které potřebují, pomocí umístění vozidla a diagnostických dat.

Důležité informace

Tyto aspekty implementují pilíře dobře architektuře Azure, což je sada hlavních principů, které je možné použít ke zlepšení kvality úlohy. Další informace naleznete v tématu Microsoft Azure Well-Architected Framework.

Spolehlivost

Spolehlivost zajišťuje, že vaše aplikace může splňovat závazky, které uděláte pro vaše zákazníky. Další informace najdete v tématu Přehled pilíře spolehlivosti.

  • Zvažte horizontální škálování pro zvýšení spolehlivosti.
  • Pomocí jednotek škálování můžete izolovat geografické oblasti s různými předpisy.
  • Automatické škálování a rezervované instance: Správa výpočetních prostředků dynamickým škálováním na základě poptávky a optimalizace nákladů pomocí předem přidělených instancí.
  • Geografická redundance: Replikace dat napříč několika geografickými umístěními pro odolnost proti chybám a zotavení po havárii

Zabezpečení

Zabezpečení poskytuje záruky proti záměrným útokům a zneužití cenných dat a systémů. Další informace najdete v tématu Přehled pilíře zabezpečení.

Optimalizace nákladů

Optimalizace nákladů se zabývá způsoby, jak snížit zbytečné výdaje a zlepšit efektivitu provozu. Další informace najdete v tématu Přehled pilíře optimalizace nákladů.

  • Důležité informace o nákladech na vozidlo: Náklady na komunikaci by měly záviset na počtu nabízených digitálních služeb. Výpočet návratnosti digitálních služeb oproti provozním nákladům
  • Vytvořte postupy analýzy nákladů na základě provozu zpráv. Při přidání dalších služeb se provoz připojených vozidel obvykle zvyšuje s časem.
  • Zvažte náklady na sítě a mobilní zařízení
    • Ke snížení objemu provozu použijte alias tématu MQTT.
    • Pomocí efektivní metody můžete kódovat a komprimovat zprávy datové části.
  • Zpracování provozu
    • Priorita zpráv: Vozidla mají tendenci opakovat vzorce použití, které vytvářejí denní nebo týdenní špičky poptávky. Pomocí vlastností zprávy můžete zpozdit zpracování nekritické nebo analytické zprávy, aby se zatížení vyhladí a optimalizovalo využití prostředků.
    • Automatické škálování na základě poptávky
  • Zvažte, jak dlouho mají být data uložena za horká/ teplá/studená.
  • Zvažte použití rezervovaných instancí k optimalizaci nákladů.

Provozní dokonalost

Efektivita provozu zahrnuje provozní procesy, které nasazují aplikaci a udržují ji spuštěnou v produkčním prostředí. Další informace najdete v tématu Přehled pilíře efektivity provozu.

  • Zvažte monitorování softwaru vozidel (protokoly, metriky/trasování), služby zasílání zpráv, služby pro analýzu dat a související back-endové služby jako součást sjednocených IT operací.

Efektivita výkonu

Efektivita výkonu je schopnost úlohy škálovat se tak, aby efektivním způsobem splňovala požadavky, které na ni kladou uživatelé. Další informace najdete v tématu Přehled pilíře efektivity výkonu.

  • Zvažte použití konceptu škálování pro řešení, která se škálují nad 50 000 zařízení, a to speciálně v případě, že je vyžadováno více geografických oblastí.
  • Pečlivě zvažte nejlepší způsob příjmu dat (zasílání zpráv, streamování nebo dávkování).
  • Zvažte nejlepší způsob analýzy dat na základě případu použití.

Další kroky

  • Vytvořte řešení AVOps (Autonomous Vehicle Operations) pro širší pohled do automobilového digitálního inženýrství pro autonomní a asistované řízení.

Následující články popisují některé koncepty používané v architektuře:

  • Model kontroly deklarací identity se používá k podpoře zpracování velkých zpráv, jako jsou nahrávání souborů.
  • Razítka nasazení se týkají obecných konceptů potřebných k škálování řešení na miliony vozidel.
  • Omezení popisuje koncept, který vyžaduje zpracování výjimečného počtu zpráv z vozidel.

Následující články popisují interakce mezi komponentami v architektuře: