Messaging in der Automobilindustrie, Daten und Analysereferenzarchitektur

Diese Referenzarchitektur wurde entwickelt, um Automobilhersteller und Mobilitätsanbieter bei der Entwicklung fortschrittlicher vernetzter Fahrzeuganwendungen und digitaler Dienste zu unterstützen. Ziel ist es, eine zuverlässige und effiziente Messaging-, Daten- und Analyseinfrastruktur bereitzustellen. Die Architektur umfasst Nachrichtenverarbeitungs-, Befehlsverarbeitungs- und Zustandsspeicherfunktionen, um die Integration verschiedener Dienste über verwaltete APIs zu vereinfachen. Außerdem wird eine Daten- und Analyselösung beschrieben, die die Speicherung und Zugänglichkeit von Daten auf skalierbare und sichere Weise für digitale Entwicklung und Datenfreigabe mit dem breiteren Mobilitätsökosystem sicherstellt.

Aufbau

Abbildung: Übersicht über die Architektur.

Die Übersicht über die Architektur zeigt die wichtigsten logischen Blöcke und Dienste einer automobilen Messaging- Daten- und Analyselösung. Weitere Einzelheiten finden Sie in den folgenden Abschnitten.

  • Das Fahrzeug enthält eine Sammlung von Geräten. Einige dieser Geräte sind softwaredefiniert und können Softwareworkloads ausführen, die aus der Cloud verwaltet werden. Das Fahrzeug erfasst und verarbeitet eine Vielzahl von Daten, von Sensorinformationen von elektromechanischen Geräten wie dem Batterieverwaltungssystem bis hin zu Softwareprotokolldateien.
  • Die Fahrzeugmessagingdienste verwalten die Kommunikation mit und aus dem Fahrzeug. Sie sind für die Verarbeitung von Nachrichten, die Ausführung von Befehlen mithilfe von Workflows und die Vermittlung des Back-Ends für Fahrzeug-, Benutzer- und Geräteverwaltung zuständig. Außerdem wird die Registrierung und Bereitstellung von Fahrzeugen, Geräten und Zertifikaten nachverfolgt.
  • Das Back-End für die Fahrzeug- und Geräteverwaltung sind die OEM-Systeme, die die Fahrzeugkonfiguration von der Fabrik bis hin zur Reparatur und Wartung nachverfolgen.
  • Der Betreiber verfügt über IT und Vorgänge, um die Verfügbarkeit und Leistung sowohl der Fahrzeuge als auch des Back-Ends sicherzustellen.
  • Die Daten- und Analysedienste bieten Datenspeicher und ermöglichen die Verarbeitung und Analyse für alle Datenbenutzer*innen. Daten werden in Erkenntnisse umgewandelt, die bessere Geschäftsentscheidungen ermöglichen.
  • Der Fahrzeughersteller bietet digitale Dienste als Mehrwert für den Endkunden, von Begleit-Apps bis hin zu Reparatur- und Wartungsanwendungen.
  • Mehrere digitale Dienste erfordern Geschäftsintegration in Back-End-Systeme wie Dealer Management- (DMS), Customer Relationship Management- (CRM) oder ERP-Systeme (Enterprise Resource Planning).
  • Das Back-End für die Einwilligungsverwaltung ist Teil der Kundenverwaltung und überwacht die Benutzerautorisierung für die Datenerfassung gemäß den rechtlichen Vorschriften der jeweiligen Regionen und Länder.
  • Aus Fahrzeugen erfasste Daten sind eine Eingabe für den digitalen Engineeringprozess mit dem Ziel kontinuierlicher Produktverbesserungen mithilfe von Analysen und maschinellem Lernen.
  • Das Ökosystem für intelligente Mobilität kann sowohl Livetelemetriedaten als auch aggregierte Erkenntnisse abonnieren und nutzen, um eine größere Anzahl von Produkten und Diensten bereitzustellen.

Microsoft ist Mitglied der Arbeitsgruppe Eclipse Software Defined Vehicle, einem Forum für offene Zusammenarbeit mit Open-Source-Software für Fahrzeugsoftwareplattformen.

Datenfluss

Die Architektur verwendet das Herausgeber-/Abonnenten-Messagingmuster, um Fahrzeuge von Diensten zu entkoppeln.

Nachrichten vom Fahrzeug in die Cloud

Der Fahrzeug-in-Cloud-Dataflow wird verwendet, um Telemetriedaten aus dem Fahrzeug zu verarbeiten. Telemetriedaten können in regelmäßigen Abständen (Fahrzeugzustand, Sammlung von Fahrzeugsensoren) oder basierend auf einem Ereignis (Trigger bei Fehlerbedingungen, Reaktion auf eine Benutzeraktion) gesendet werden.

Abbildung des Messagingdataflows.

  1. Das Fahrzeug wird für einen Kunden basierend auf den ausgewählten Optionen mithilfe der Verwaltungs-APIs konfiguriert. Die Konfiguration enthält Folgendes:
    1. Bereitstellungsinformationen für Fahrzeuge und Geräte.
    2. Anfängliche Konfiguration der Fahrzeugdatenerfassung basierend auf Markt- und Geschäftsüberlegungen.
    3. Speicherung der anfänglichen Benutzerzustimmungseinstellungen basierend auf Fahrzeugoptionen und Benutzerakzeptanz.
  2. Das Fahrzeug veröffentlicht Telemetrie- und Ereignisnachrichten über einen MQTT-Client (Message Queuing Telemetry Transport) mit definierten Themen für das MQTT Vermittler-Feature von Azure Event Grid in den Fahrzeugmessagingdiensten.
  3. Event Grid leitet Nachrichten basierend auf dem Thema und den Nachrichtenattributen an verschiedene Abonnenten weiter.
    1. Nachrichten mit niedriger Priorität, die keine sofortige Verarbeitung erfordern (z. B. Analysenachrichten), werden mithilfe einer Event Hubs-Instanz zur Pufferung direkt an den Speicher weitergeleitet.
    2. Nachrichten mit hoher Priorität, die sofortige Verarbeitung erfordern (z. B. Statusänderungen, die in einer benutzerseitigen Anwendung visualisiert werden müssen), werden mithilfe einer Event Hubs-Instanz zur Pufferung an eine Azure-Funktion weitergeleitet.
  4. Nachrichten mit niedriger Priorität werden mithilfe der Ereigniserfassung direkt im Data Lake gespeichert. Diese Nachrichten können Batchdecodierung und -verarbeitung verwenden, um optimale Kosten zu erzielen.
  5. Nachrichten mit hoher Priorität werden mit einer Azure-Funktion verarbeitet. Die Funktion liest die Fahrzeug-, Geräte- und Benutzereinwilligungseinstellungen aus der Geräteregistrierung und führt die folgenden Schritte aus:
    1. Überprüfen, ob das Fahrzeug und das Gerät registriert und aktiv sind.
    2. Überprüfen, ob der Benutzer seine Zustimmung für das Nachrichtenthema erteilt hat.
    3. Decodieren und Anreichern der Nutzdaten.
    4. Hinzufügen weiterer Routinginformationen.
  6. Der Event Hub der Livetelemetrie in der Daten-und Analyselösung empfängt die decodierten Nachrichten. Azure Data Explorer verwendet Streamingerfassung, um Nachrichten beim Empfang zu verarbeiten und zu speichern.
  7. Die digitale Dienstebene empfängt decodierte Nachrichten. Service Bus stellt Benachrichtigungen an Anwendungen zu wichtigen Änderungen/Ereignissen am Zustand des Fahrzeugs bereit. Azure Data Explorer stellt den letzten bekannten Zustand des Fahrzeugs und den kurzfristigen Verlauf bereit.

Cloud-an-Fahrzeug-Nachrichten

Der Cloud-an-Fahrzeug-Dataflow wird häufig verwendet, um Remotebefehle im Fahrzeug von einem digitalen Dienst auszuführen. Diese Befehle umfassen Anwendungsfälle wie Sperren/Entsperren der Tür, Steuerung der Klimatisierung (Festlegen der bevorzugten Kabinentemperatur) oder Konfigurationsänderungen. Die erfolgreiche Ausführung hängt vom Fahrzeugzustand ab und kann einige Zeit in Anspruch nehmen.

Abhängig von den Fahrzeugfunktionen und der Art der Aktion gibt es mehrere mögliche Ansätze für die Befehlsausführung. Zwei Varianten werden behandelt:

  • Direkte Cloud-an-Gerät-Nachrichten (A), die keine Überprüfung der Benutzereinwilligung erfordern und eine vorhersagbare Antwortzeit aufweisen. Dies umfasst Nachrichten sowohl an einzelne als auch an mehrere Fahrzeuge. Ein Beispiel sind z. B. Wetterbenachrichtigungen.
  • Fahrzeugbefehle (B), die den Fahrzeugzustand verwenden, um den Erfolg zu bestimmen und die die Zustimmung des Benutzers erfordern. Die Messaginglösung muss über eine Befehlsworkflowlogik verfügen, die die Benutzerzustimmung überprüft, den Befehlsausführungsstatus nachverfolgt und den digitalen Dienst nachdem Abschluss benachrichtigt.

Die folgenden Dataflow verwendet Befehle, die von einer Begleit-App digitaler Dienste ausgegeben werden, als Beispiel.

Abbildung: Befehlss- und Steuerungsdataflow.

Direkte Nachrichten werden mit der minimalen Anzahl von Hops für bestmögliche Leistung (A) ausgeführt:

  1. Die Begleit-App ist ein authentifizierter Dienst, der Nachrichten in Event Grid veröffentlichen kann.
  2. Event Grid überprüft die Autorisierung für den Begleit-App-Dienst, um zu ermitteln, ob Nachrichten an die bereitgestellten Themen gesendet werden können.
  3. Die Begleit-App abonniert Antworten von der jeweiligen Fahrzeug-/Befehlskombination.

Wenn Befehle, die vom Fahrzeugzustand abhängen, eine Benutzereinwilligung erfordern (B):

  1. Der Fahrzeugbesitzer/-benutzer erteilt die Zustimmung für die Ausführung von Befehls- und Steuerungsfunktionen für einen digitalen Dienst (in diesem Beispiel eine Begleit-App). Dies erfolgt normalerweise, wenn ein Benutzer oder eine Benutzerin die App herunterlädt/aktiviert und der OEM dazu zugehörige Konto aktiviert. Dadurch wird eine Konfigurationsänderung für das Fahrzeug ausgelöst, um das zugehörige Befehlsthema im MQTT Vermittler zu abonnieren.
  2. Die Begleit-App verwendet die verwaltete Befehls- und Steuerungs-API, um die Ausführung eines Remotebefehls anzufordern.
    1. Die Befehlsausführung verfügt möglicherweise über mehr Parameter, um Optionen wie Timeout, Speicher- und Weiterleitungsoptionen usw. zu konfigurieren.
    2. Die Befehlslogik entscheidet basierend auf dem Thema und anderen Eigenschaften, wie der Befehl verarbeitet werden soll.
    3. Die Workflowlogik erstellt einen Zustand, um den Status der Ausführung nachzuverfolgen.
  3. Die Workflowlogik des Befehls überprüft Informationen zur Benutzerzustimmung, um zu bestimmen, ob die Nachricht ausgeführt werden kann.
  4. Die Befehlsworkflowlogik veröffentlicht eine Nachricht in Event Grid mit dem Befehl und den Parameterwerten.
  5. Das Messagingmodul im Fahrzeug wird für das Befehlsthema abonniert und empfängt die Benachrichtigung. Es leitet den Befehl an die richtige Workload weiter.
  6. Das Messagingmodul überwacht den Abschluss (oder Fehler) der Workload. Eine Workload ist für die (physische) Ausführung des Befehls verantwortlich.
  7. Das Messagingmodul veröffentlicht Befehlstatusberichte in Event Grid.
  8. Das Workflowmodul wird von Befehlsstatusupdates abonniert und aktualisiert den internen Status der Befehlsausführung.
  9. Sobald die Befehlsausführung abgeschlossen ist, empfängt die Dienst-App das Ausführungsergebnis über die Befehls- und Steuerungs-API.

Fahrzeug- und Gerätebereitstellung

Dieser Dataflow deckt den Prozess zum Registrieren und Bereitstellen von Fahrzeugen und Geräten für die Fahrzeugmessagingdienste ab. Der Prozess wird in der Regel im Rahmen der Fahrzeugfertigung initiiert.

Abbildung: Bereitstellungsdataflow.

  1. Das Factorysystem versetzt das Fahrzeuggerät in den gewünschten Bauzustand. Dies kann die Erstinstallation und -konfiguration von Firmware und Software umfassen. Im Rahmen dieses Prozesses ruft das Factorysystem das Gerätezertifikat ab und schreibt es, das vom Anbieter der Public Key-Infrastruktur erstellt wurde.
  2. Das Factorysystem registriert das Fahrzeug und das Gerät mithilfe der Fahrzeug- und Gerätebereitstellungs-API.
  3. Das Facrorysystem löst den Gerätebereitstellungsclient aus, um eine Verbindung mit der Geräteregistrierung herzustellen und das Gerät bereitzustellen. Das Gerät ruft Verbindungsinformationen für den MQTT Vermittler ab.
  4. Die Geräteregistrierungsanwendung erstellt die Geräteidentität im MQTT Vermittler.
  5. Das Factorysystem löst das Gerät aus, um zum ersten Mal eine Verbindung mit dem MQTT Vermittler herzustellen.
    1. Der MQTT-Broker authentifiziert das Gerät mithilfe des Stammzertifikats der Zertifizierungsstelle und extrahiert die Clientinformationen.
  6. Der MQTT Vermittler verwaltet die Autorisierung für zulässige Themen mithilfe der lokalen Registrierung.
  7. Bei einem Teileaustausch kann das OEM-Händlersystem die Registrierung eines neuen Geräts auslösen.

Hinweis

Factorysysteme sind in der Regel lokal und haben keine direkte Verbindung mit der Cloud.

Datenanalyse

Dieser Dataflow deckt Analysen für Fahrzeugdaten ab. Sie können andere Datenquellen wie Factory- oder Werkstattbetreiber verwenden, um Fahrzeugdaten anzureichern und Kontext bereitzustellen.

Abbildung: Datenanalysen.

  1. Die Ebene der Fahrzeugmessagingdienste stellt Telemetriedaten, Ereignisse, Befehle und Konfigurationsmeldungen aus der bidirektionalen Kommunikation mit dem Fahrzeug bereit.
  2. Die Schicht IT und Betrieb stellt Informationen zur Software bereit, die für das Fahrzeug ausgeführt wird, sowie die zugehörigen Clouddienste.
  3. Mehrere Pipelines ermöglichen die Verarbeitung der Daten in einen verfeinerten Zustand.
    • Verarbeitung von Rohdaten zu angereicherten und deduplizierten Fahrzeugdaten.
    • Aggregation von Fahrzeugdaten, wichtige Leistungsindikatoren und Erkenntnisse.
    • Generierung von Trainingsdaten für maschinelles Lernen.
  4. Verschiedene Anwendungen nutzen verfeinerte und aggregierte Daten.
    • Visualisierung mithilfe von Power BI.
    • Geschäftsintegrationsworkflows mit Logic Apps mit Integration in Dataverse.
  5. Generierte Trainingsdaten werden von Tools wie ML Studio verwendet, um ML-Modelle zu generieren.

Skalierbarkeit

Eine vernetzte Fahrzeug- und Datenlösung kann auf Millionen von Fahrzeugen und Tausende von Diensten skaliert werden. Es wird empfohlen, das Muster „Bereitstellungsstempel“ zu verwenden, um Skalierbarkeit und Elastizität zu erzielen.

Abbildung: Skalierbarkeitskonzept.

Jede Skalierungseinheit für Fahrzeugnachrichten unterstützt eine definierte Fahrzeugpopulation (z. B. Fahrzeuge in einer bestimmten geografischen Region, partitioniert nach Modelljahr). Die Anwendungsskalierungseinheit wird verwendet, um die Dienste zu skalieren, die das Senden oder Empfangen von Nachrichten an bzw. von Fahrzeuge(n) erfordern. Der allgemeine Dienst ist von jeder Skalierungseinheit aus zugänglich und bietet Geräteverwaltungs- und Abonnementdienste für Anwendungen und Geräte.

  1. Die Anwendungsskalierungseinheit abonniert Anwendungen für interessante Nachrichten. Der allgemeine Dienst verarbeitet das Abonnement für die Komponenten der Skalierungseinheit für Fahrzeugmessaging.
  2. Das Fahrzeug verwendet den Geräteverwaltungsdienst, um seine Zuordnung zu einer Skalierungseinheit für Fahrzeugmessaging zu ermitteln.
  3. Bei Bedarf wird das Fahrzeug mithilfe des Workflows für Fahrzeug- und Gerätebereitstellung bereitgestellt.
  4. Das Fahrzeug veröffentlicht eine Nachricht für den MQTT Vermittler.
  5. Event Grid leitet die Nachricht mithilfe der Abonnementinformationen weiter.
    1. Nachrichten, die keine Verarbeitung und Anspruchsprüfung erfordern, werden an einen Eingangshub in der entsprechenden Anwendungsskalierungseinheit weitergeleitet.
    2. Nachrichten, die Verarbeitung erfordern, werden zur Decodierung und Autorisierung (Benutzereinwilligung) an die D2C-Verarbeitungslogik weitergeleitet.
  6. Anwendungen nutzen Ereignisse aus ihrer Event Hubs-Instanz für App-Eingang.
  7. Anwendungen veröffentlichen Nachrichten für das Fahrzeug.
    1. Nachrichten, die keine weitere Verarbeitung erfordern, werden im MQTT Vermittler veröffentlicht.
    2. Nachrichten, die weitere Verarbeitung, Workflowsteuerung und Autorisierung erfordern, werden über eine Event Hubs-Instanz an die relevante C2D-Verarbeitungslogik weitergeleitet.

Komponenten

Diese Referenzarchitektur verweist auf die folgenden Azure-Komponenten.

Konnektivität

  • Azure Event Grid ermöglicht das Onboarding von Geräten, AuthN/Z und Veröffentlichen/Abonnieren (Pub/Sub) über MQTT v5.
  • Azure Functions verarbeitet die Fahrzeugnachrichten. Functions kann auch verwendet werden, um Verwaltungs-APIs zu implementieren, die kurzlebige Ausführung erfordern.
  • Azure Kubernetes Service (AKS) ist eine Alternative, wenn die Funktionalität hinter den verwalteten APIs aus komplexen Workloads besteht, die als containerisierte Anwendungen bereitgestellt werden.
  • Azure Cosmos DB speichert die Einstellungen für Fahrzeug, Gerät und Benutzereinwilligung.
  • Azure API Management stellt ein verwaltetes API-Gateway für vorhandene Back-End-Dienste bereit, z. B. für Lebenszyklusverwaltung des Fahrzeugs (einschließlich OTA) und Benutzerzustimmungsverwaltung.
  • Azure Batch führt große rechenintensive Aufgaben effizient aus, z. B. die Erfassung der Ablaufverfolgung der Fahrzeugkommunikation.

Daten und Analysen

  • Azure Event Hubs ermöglicht die Verarbeitung und Erfassung großer Mengen von Telemetriedaten.
  • Azure Data Explorer ermöglicht die Untersuchung, Zusammenstellung und Analyse zeitreihenbasierter Fahrzeugtelemetriedaten.
  • Azure Blob Storage speichert große Dokumente (z. B. Videos und Can-Ablaufverfolgungen) und zusammengestellte Fahrzeugdaten.
  • Azure Databricks bietet eine Reihe von Tools zum Verwalten von Datenlösungen auf Unternehmensniveau im großen Stil. Für zeitintensive Vorgänge mit großen Mengen von Fahrzeugdaten erforderlich.

Back-End-Integration

  • Azure Logic Apps führt automatisierte Workflows für Geschäftsintegration basierend auf Fahrzeugdaten aus.
  • Azure App Service stellt benutzerseitige Web-Apps und mobile Back-Ends bereit, z. B. die Begleit-App.
  • Azure Cache for Redis bietet In-Memory-Zwischenspeicherung von Daten, die häufig von benutzerseitigen Anwendungen verwendet werden.
  • Azure Service Bus bietet Brokerfunktionen, die Fahrzeugkonnektivität von digitalen Diensten und Geschäftsintegration entkoppelt.

Alternativen

Die Auswahl des richtigen Computetyps zum Implementieren von Nachrichtenverarbeitung und verwalteten APIs hängt von einer Vielzahl von Faktoren ab. Wählen Sie den richtigen Dienst mithilfe des Leitfadens Auswählen eines Azure-Computediensts aus.

Beispiele:

  • Azure Functions für ereignisgesteuerte, kurzlebige Prozesse wie Telemetriedatenerfassung.
  • Azure Batch für Hochleistungs-Computingaufgaben wie das Decodieren großer CAN-Ablaufverfolgungs-/Videodateien
  • Azure Kubernetes Service für verwaltete, vollständige Orchestrierung komplexer Logik, z. B. Verwaltung von Befehls- und Befehlssteuerungsworkflows.

Als Alternative zur ereignisbasierten Datenfreigabe ist es auch möglich, Azure Data Share zu verwenden, wenn Batchsynchronisierung auf Data Lake-Ebene als Ziel durchgeführt werden soll.

Szenariodetails

Abbildung: Übersicht.

Automobilhersteller durchlaufen eine bedeutende Transformation, da sie sich von der Herstellung fester Produkte auf vernetzte, softwaredefinierte Fahrzeuge verlagern. Fahrzeuge bieten eine Reihe von Features, z. B. Over-the-Air-Updates, Remotediagnose und personalisierte Benutzerumgebungen. Diese Transformation ermöglicht es OEMs, ihre Produkte basierend auf Echtzeitdaten und Erkenntnissen kontinuierlich zu verbessern und gleichzeitig ihre Geschäftsmodelle um neue Dienste und Umsatzquellen zu erweitern.

Diese Referenzarchitektur ermöglicht Automobilherstellern und Mobilitätsanbietern Folgendes:

  • Verwenden von Feedbackdaten als Teil des digitalen Engineeringprozesses, um kontinuierliche Produktverbesserung zu fördern, proaktiv die Grundursachen von Problemen anzugehen und neuen Kundenmehrwert zu schaffen.
  • Bereitstellen neuer digitaler Produkte und Dienstleistungen und Digitalisieren des Betriebs durch Geschäftsintegration mit Back-End-Systemen wie Enterprise Resource Planning (ERP) und Customer Relationship Management (CRM).
  • Es gibt Daten sicher frei und erfüllt die länderspezifischen Anforderungen für die Benutzerzustimmung mit den breiteren intelligenten Mobilitätsökosystemen.
  • Integration in Back-End-Systeme für die Verwaltung des Fahrzeuglebenszyklus und die Zustimmungsverwaltung vereinfacht und beschleunigt die Bereitstellung und Verwaltung vernetzter Fahrzeuglösungen mithilfe einer softwaredefinierten Fahrzeug-DevOps-Toolkette.
  • Speichern und Bereitstellen von Computeleistung im großen Stil für Fahrzeuge und Analysen.
  • Verwalten von Fahrzeugkonnektivität für Millionen von Geräten auf kostengünstige Weise.

Mögliche Anwendungsfälle

OEM-Automobilanwendungsfälle dienen der Verbesserung von Leistung, Sicherheit und Benutzerfreundlichkeit des Fahrzeugs.

  • Kontinuierliche Produktverbesserung: Verbesserung der Fahrzeugleistung durch Analyse von Echtzeitdaten und Remoteanwendung von Updates.
  • Testflotten-Engineeringüberprüfung: Gewährleistung von Fahrzeugsicherheit und -zuverlässigkeit durch Erfassen und Analysieren von Daten aus Testflotten.
  • Begleit-App und Benutzerportal: Ermöglicht den Remotezugriff und die Steuerung von Fahrzeugen über eine personalisierte App und ein Webportal.
  • Proaktive Reparatur und Wartung: Vorhersagen und Planen der Fahrzeugwartung basierend auf datengesteuerten Erkenntnissen.

Allgemeinere Ökosystemanwendungsfälle erweitern Anwendungen für vernetzte Fahrzeuge, um den Betrieb von Flotten, Versicherungen, Marketing und Unterstützung auf der Straße in der gesamten Transportumgebung zu verbessern.

  • Vernetzter kommerzieller Flottenbetrieb: Optimierung des Flottenmanagements durch Echtzeitüberwachung und datengesteuerte Entscheidungsfindung.
  • Digitale Fahrzeugversicherung: Anpassung der Versicherungsprämien basierend auf dem Fahrverhalten und Bereitstellung einer sofortigen Unfallberichterstattung.
  • Standortbasiertes Marketing: Bereitstellung gezielter Marketingkampagnen für Fahrer basierend auf ihrem Standort und ihren Vorlieben.
  • Fahrerassistenz: Unterstützung und Hilfe in Echtzeit für Fahrer in Not, unter Verwendung von Fahrzeugstandort und Diagnosedaten.

Überlegungen

Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Zuverlässigkeit

Zuverlässigkeit stellt sicher, dass Ihre Anwendung Ihre Verpflichtungen gegenüber den Kunden erfüllen kann. Weitere Informationen finden Sie in der Überblick über die Säule „Zuverlässigkeit“.

  • Erwägen Sie horizontale Skalierung, um die Zuverlässigkeit zu erhöhen.
  • Verwenden Sie Skalierungseinheiten, um geografische Regionen mit unterschiedlichen Vorschriften zu isolieren.
  • Automatische Skalierung und reservierte Instanzen: Verwalten Sie Computeressourcen durch dynamische Skalierung basierend auf der Nachfrage und Optimieren der Kosten mit vorab zugeordneten Instanzen.
  • Georedundanz: Replizieren Sie Daten für Fehlertoleranz und Notfallwiederherstellung über mehrere geografische Standorte hinweg.

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.

  • Schützen der Fahrzeugverbindung: Informationen zur Verwendung von X.509-Zertifikaten zum Einrichten sicherer Fahrzeugkommunikation finden Sie im Abschnitt zur Zertifikatverwaltung.

Kostenoptimierung

Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

  • Überlegungen zu den Kosten pro Fahrzeug: Die Kommunikationskosten sollten von der Anzahl der angebotenen digitalen Dienste abhängen. Berechnen der Kapitalrendite der digitalen Dienste im Vergleich zu den Betriebskosten.
  • Einrichten von Verfahren zur Kostenanalyse auf der Grundlage des Nachrichtenverkehrs. Der Datenverkehr vernetzter Fahrzeuge steigt tendenziell im Lauf der Zeit, wenn weitere Dienste hinzugefügt werden.
  • Berücksichtigen Sie die Kosten für Netzwerke und mobile Geräte.
    • Verwenden Sie den MQTT-Themenalias, um das Datenverkehrsvolumen zu reduzieren.
    • Verwenden Sie eine effiziente Methode zum Codieren und Komprimieren von Nutzdatennachrichten.
  • Verarbeiten des Datenverkehrs
    • Nachrichtenpriorität: Fahrzeuge haben in der Regel sich wiederholende Nutzungsmuster, die zu täglichen/wöchentlichen Bedarfsspitzen führen. Verwenden Sie Nachrichteneigenschaften, um die Verarbeitung nicht kritischer oder analytischer Nachrichten zu verzögern, um die Auslastung zu verringern und die Ressourcennutzung zu optimieren.
    • Führe Sie nach Bedarf eine automatische Skalierung durch.
  • Überlegen Sie, wie lange die Daten heiß/warm/kalt gespeichert werden sollen.
  • Erwägen Sie die Verwendung reservierter Instanzen, um die Kosten zu optimieren.

Optimaler Betrieb

Die Säule „Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie unter Übersicht über die Säule „Optimaler Betrieb“.

  • Erwägen Sie die Überwachung der Fahrzeugsoftware (Protokolle, Metriken und Ablaufverfolgungen), der Messagingdienste, der Daten- und Analysedienste und der zugehörigen Back-End-Dienste im Rahmen eines einheitlichen IT-Betriebs.

Effiziente Leistung

Leistungseffizienz ist die Fähigkeit Ihrer Workload, auf effiziente Weise eine den Anforderungen der Benutzer entsprechende Skalierung auszuführen. Weitere Informationen finden Sie unter Übersicht über die Säule „Leistungseffizienz“.

  • Erwägen Sie, das Skalierungskonzept für Lösungen zu verwenden, die über 50.000 Geräte einbinden, insbesondere wenn mehrere geografische Regionen erforderlich sind.
  • Überlegen Sie sorgfältig, wie Sie Daten am besten erfassen können (Messaging, Streaming oder Batchverarbeitung).
  • Erwägen Sie die beste Möglichkeit, die Daten basierend auf dem jeweiligen Anwendungsfall zu analysieren.

Nächste Schritte

Die folgenden Artikel behandeln einige der Konzepte, die in der Architektur verwendet werden:

  • Das Anspruchsüberprüfungsmuster wird verwendet, um die Verarbeitung großer Nachrichten zu unterstützen, z. B. Dateiuploads.
  • Unter Bereitstellungsstempel finden Sie die allgemeinen Konzepte, die erforderlich sind, um die Lösung auf Millionen von Fahrzeugen zu skalieren.
  • Drosselung beschreibt das Konzept zum Verarbeiten einer außergewöhnlich hohen Anzahl von Nachrichten von Fahrzeugen.

In den folgenden Artikeln werden Interaktionen zwischen Komponenten in der Architektur beschrieben: