Datenanalyse für Fahrzeugtestflotten

Automobil-Erstausrüster (OEMs) benötigen Lösungen, um die Zeit zwischen Testfahrten und der Bereitstellung von Testfahrtdiagnosedaten an Forschungs- und Entwicklungsingenieure & zu minimieren. Mit der zunehmenden Automatisierung der Fahrzeuge werden die Lebenszyklen der Softwareentwicklung kürzer, was schnellere digitale Feedbackschleifen erfordert. Neue Technologien können den Zugriff auf die Daten demokratisieren und den Forschungs- und Entwicklungsingenieuren in Quasi-Echtzeit Erkenntnisse über die Diagnosedaten von Testfahrten liefern. Verwenden Sie Copilot für Data Science und Data Engineering zur Datenanalyse, um die Zeit bis zur Erkenntnisgewinnung weiter zu verkürzen. Durch den sicheren Datenaustausch kann die Zusammenarbeit zwischen OEMs und Zulieferern verbessert und die Entwicklungszyklen verkürzt werden.

Die Anleitung in diesem Artikel richtet sich an Telemetrieszenarien und Batchtestdatenaufnahmeszenarien. Der Schwerpunkt dieser Architektur liegt auf der Datenplattform, die Diagnosedaten verarbeitet, und den Konnektoren für die Datenvisualisierung und Datenberichterstattung.

Aufbau

Laden Sie eine PowerPoint-Datei mit allen Diagrammen in diesem Artikel herunter.

Datenfluss

Der folgende Dataflow entspricht dem vorherigen Diagramm:

1. Das Datenerfassungsgerät ist mit den Fahrzeugnetzwerken verbunden und sammelt hochauflösende Fahrzeugsignaldaten und -video. (1a) Das Gerät veröffentlicht Echtzeit-Telemetrienachrichten oder (1b) fordert das Hochladen aufgezeichneter Datendateien in die Azure Event Grid MQTT-Brokerfunktionalität mithilfe eines MQTT-Clients an. Diese Funktion verwendet ein Anspruchsprüfungsmuster.

2. (2a) Event Grid leitet Live-Fahrzeugsignaldaten an eine Azure Functions-App weiter. Diese App decodiert die Fahrzeugsignale im JSON-Format (JavaScript Object Notation) und sendet sie an einen Eventstream.

   (2b) Das Ereignisraster koordiniert den Dateiupload vom Geräteclient in das Lakehouse. Ein abgeschlossener Dateiupload löst eine Pipeline aus, die die Daten decodiert und die decodierte Datei in einem Format in OneLine schreibt, das für die Erfassung geeignet ist, z. B. Parquet oder CSV.

3. (3a) Der Eventstream leitet die decodierten JSON-Signale des Fahrzeugs zur Erfassung an das Eventhouse weiter.

   (3b) Eine Datenpipeline löst die Aufnahme entkoppelter Dateien aus dem Lakehouse aus.

4. Das Eventhouse verwendet Aktualisierungsrichtlinien, um die Daten anzureichern und die JSON-Daten in ein geeignetes Zeilenformat zu erweitern. So können beispielsweise standortbezogene Daten zur Abstimmung auf die Geoanalyse gruppiert werden. Jedes Mal, wenn eine neue Zeile aufgenommen wird, ruft das Analysemodul in Echtzeit eine zugeordnete Update() Funktion auf.

5. Data Engineers und Data Scientists verwenden Kusto-Abfragesprache (KQL) zum Erstellen von Analyse-Anwendungsfällen. Benutzer speichern häufig verwendete Fälle als gemeinsam genutzte benutzerdefinierte Funktionen. Die Ingenieure verwenden integrierte KQL-Funktionen wie Aggregation, Zeitreihenanalyse, Geospatialclustering, Fensterung und Machine Learning-Plug-Ins mit Copilot-Unterstützung.

6. R&D-Ingenieure und Data Scientists verwenden Notizbücher, um Daten zu analysieren und Test- und Validierungsanwendungsfälle zu erstellen.

   1. F&E-Ingenieure verwenden KQL-Abfragesätze und Copilot für Echtzeitintelligenz, um interaktive Datenanalysen durchzuführen.

   2. Data Engineers und Data Scientists verwenden Notizbücher , um ihre Analyseprozesse zu speichern und zu teilen. Mit Notizbüchern können Techniker Azure Spark verwenden, um Analysen auszuführen und Git zum Verwalten des Notizbuchcodes zu verwenden. Benutzer können Copilot für Data Science und Data Engineering nutzen, um ihren Workflow mit Kontextcodevorschlägen zu unterstützen.

7. R&D-Ingenieure und Data Scientists können Power BI mit dynamischen Abfragen oder Echtzeitanalysedashboards verwenden, um Visualisierungen für geschäftsbezogene Benutzer zu erstellen. Diese Visualisierungen rufen benutzerdefinierte Funktionen auf, um die Wartung zu erleichtern.

8. Techniker können auch weitere Tools mit Microsoft Fabric verbinden. Sie können beispielsweise Azure Managed Grafana mit dem Eventhouse verbinden oder eine Webanwendung erstellen, die das Eventhouse direkt abfragt.

9. Dateningenieure und F&D-Ingenieure verwenden Data Activator, um Reflexelemente zu erstellen, mit denen Bedingungen überwacht und Aktionen ausgelöst werden können, z. B. das Auslösen von Power Automate-Flows für die Geschäftsintegration. Beispielsweise kann der Datenaktivator einen Teams-Kanal benachrichtigen, wenn die Integrität eines Geräts beeinträchtigt wird.

10. Mit der Datensammlerkonfiguration können Techniker die Datensammlungsrichtlinien des Datenerfassungsgeräts ändern. Azure API Management abstrahiert und sichert die Partnerkonfigurations-API und bietet Observability.

Das KQL-Datenbankschema

Berücksichtigen Sie beim Entwerfen des Tabellenschemas den Unterschied zwischen fact Tabellen und dimension Tabellen. Telemetrie ist eine fact Tabelle, da Fahrzeugsignale schrittweise auf Streaming-Weise oder als Teil einer vollständigen Aufzeichnung angefügt werden, und Telemetrie ändert sich nicht. Sie können Flottenmetadaten als fact Tabelle klassifizieren, die langsam aktualisiert wird.

Die Fahrzeugtelemetrie landet in Rohtabellen. Sie können die folgenden Nachrichtenverarbeitungskonzepte verwenden, um die Daten für Analyse und Berichterstellung zu organisieren:

• Erstellen Sie Updaterichtlinien, um die JSON-Telemetriedateien mithilfe von Methoden wie:

  • mv-expand() erweitert komplexe Werte, die in JSON-Strukturen gespeichert sind, in Zeilen mit einzelnen Signalen.
  • geo_point_to_h3cell() oder geo_point_to_geohash() konvertiert Breiten- und Längengraden in Geohashes für räumliche Analysen.
  • todouble() und tostring() wandelt extrahierte Werte aus dynamischen JSON-Objekten in die entsprechenden Datentypen um.
  • lookup erweitert die Datensätze mit Werten aus einer Dimensionstabelle.

• Erstellen Sie eine materialisierte Signalansicht mithilfe der Aggregationsfunktion take_any() für den eindeutigen Schlüssel und Zeitstempel. Diese materialisierte Ansicht dedupliziert Signale.

• Erstellen Sie eine materialisierte Ansicht Letzte bekannte Signalwerte, indem Sie die Aggregationsfunktion arg_max() auf den Zeitstempel anwenden. Diese materialisierte Ansicht bietet einen aktuellen Status der Fahrzeuge.

• Erstellen Sie eine materialisierte Signal-Downsampled-Ansicht , indem Sie den Zusammenfassungsoperator mit Zeitcontainern wie Stündlich und täglich verwenden. Diese materialisierte Ansicht aggregiert Signale und vereinfacht die Berichterstattung über die gesamte Flotte.

• Erstellen Sie benutzerdefinierte Funktionen, die Anomalieerkennung oder Ursachenanalyse bereitstellen.

  • Verwenden Sie Zeitreihenfunktionen zur Anomalieerkennung und Prognose , um potenzielle Probleme zu erkennen und Fehler vorherzusagen.

  • Verwenden Sie den Scanoperator , um Sequenzen aus den Daten zu scannen, abzugleichen und zu erstellen. Techniker können den scan Operator verwenden, um Sequenzen zu erkennen. Wenn beispielsweise ein bestimmtes Ereignis auftritt, muss innerhalb eines bestimmten Zeitraums ein nachfolgendes Ereignis auftreten.

  • Verwenden Sie Plug-ins für maschinelles Lernen wie autocluster , um gemeinsame Muster diskreter Attribute zu finden.

• Durchführen von Geospatialanalysen mit benutzerdefinierten Funktionen. Verwenden Sie die Geospatialanalysefunktionen , um Koordinaten in ein geeignetes Rastersystem zu konvertieren und Aggregationen für die Daten durchzuführen.

• Erstellen Sie eine Flottenmetadatentabelle , um Änderungen an den Fahrzeugmetadaten und der Konfiguration zu speichern. Erstellen Sie eine zuletzt bekannte Werteansicht , um den neuesten Zustand der Fahrzeugflotte basierend auf einer zuletzt geänderten Spalte zu speichern.

Komponenten

Die folgenden Schlüsseltechnologien implementieren diese Workload: Verwenden Sie für jede Komponente in der Architektur den entsprechenden Dienstleitfaden im Well-Architected Framework, sofern verfügbar. Weitere Informationen finden Sie unter Servicehandbücher für Well-Architected Framework.

• Fabric Real-Time Intelligence ermöglicht die Extraktion von Erkenntnissen und der Visualisierung der Fahrzeugtelemetrie in Bewegung. Mithilfe von Eventstreams und Zeitreihen-KQL-Datenbanken können Sie Daten speichern und analysieren und Reflexe verwenden, um auf Ereignisse zu reagieren.

• Der Data Activator ist ein Code-No-Code-Tool, mit dem Sie Aktionen automatisieren können, wenn sich Muster oder Bedingungen in Daten ändern.

• Event Grid ist ein hoch skalierbarer, vollständig verwalteter Publish/Subscribe-Nachrichtenverteilungsdienst, der MQTT-Protokolle unterstützt. Fahrzeuge können mithilfe des Ereignisrasters Themen veröffentlichen und abonnieren, z. B. Telemetrie veröffentlichen und Befehls- und Kontrollmeldungen abonnieren.

• Azure Event Hubs ist eine Echtzeitdatenstreamingplattform, die für das Streamen von Millionen von Fahrzeugereignissen pro Sekunde mit geringer Latenz gut geeignet ist.

• Funktionen sind eine serverlose Lösung, die die Verarbeitung von Fahrzeugtelemetrieereignissen im Maßstab mit ereignisgesteuerten Triggern und Bindungen mithilfe der von Ihnen gewählten Sprache vereinfacht.

• Azure Managed Grafana ist eine Datenvisualisierungsplattform, die auf der Software von Grafana Labs basiert. Microsoft verwaltet und unterstützt Azure Managed Grafana.

• Mit Azure App Service können Sie Web-Apps, mobile Back-Ends und RESTful-APIs erstellen und hosten, die Zugriff auf die in Fabric gespeicherten Fahrzeugtelemetriedaten bieten. Dieser Ansatz vereinfacht den Verbrauch.

• API Management ist eine hybride Multi-Cloud-Verwaltungsplattform für APIs.

Alternativen

Sie können auch die folgenden Azure-Dienste verwenden, um diese Architektur zu implementieren:

• Azure Blob Storage speichert massive Mengen unstrukturierter Daten, z. B. Aufzeichnungen, Protokolle und Videos von den Fahrzeugen. Er ersetzt OneLake-Speicher.

• Azure Data Explorer ist ein schneller, vollständig verwalteter Datenanalysedienst für Echtzeitanalysen großer Mengen an Daten. Er ersetzt die Fabric Real-Time Intelligence-KQL-Datenbank.

• Azure Batch ist eine Alternative, mit der Sie komplexe Dateien decodieren können. Dieses Szenario umfasst eine große Anzahl von Dateien, die jeweils über 300 MB groß sind. Für die Dateien sind je nach Dateiversion oder Dateityp unterschiedliche Decodierungsalgorithmen erforderlich. Sie können entweder Fabric verwenden oder Blob Storage und Azure Data Explorer verwenden, um den folgenden Ansatz zu implementieren.

1. Der Benutzer oder das Aufzeichnungsgerät lädt eine aufgezeichnete Datendatei in das Lakehouse hoch. Nach Abschluss des Uploads löst sie eine Funktionen-App aus, die die Decodierung plant.

2. Der Scheduler startet eine Funktionen-App, die einen Batchauftrag basierend auf dem Dateityp, der Dateigröße und dem erforderlichen Decodierungsalgorithmus erstellt. Die App wählt eine virtuelle Maschine mit passender Größe aus dem Pool aus und startet den Job.

3. Batch schreibt die resultierende decodierte Datei zurück in das Seehaus, wenn der Auftrag abgeschlossen ist. Diese Datei muss für die direkte Erfassung in einem vom Eventhouse unterstützten Format geeignet sein.

4. Das Lakehouse löst eine Funktion aus, die die Daten beim Schreiben der Datei in das Eventhouse erfasst. Diese Funktion erstellt die Tabelle und die Datenzuordnung, falls erforderlich, und startet die Erfassung.

5. Die KQL-Datenbank erfasst die Datendateien aus dem Seehaus.

Diese Vorgehensweise bietet folgende Vorteile:

• Azure Functions und Batch-Pools können skalierbare Datenverarbeitungsaufgaben robust und effizient zu bewältigen.

• Batch-Pools bieten Erkenntnisse über Verarbeitungsstatistiken, Aufgabenwarteschlangen und die Integrität von Batch-Pools. Sie können den Status visualisieren, Probleme erkennen und fehlerhafte Aufgaben erneut ausführen.

• Die Kombination von Functions und Batch unterstützt die Plug & Play-Verarbeitung in Docker-Containern.

• Sie können virtuelle Spotcomputer verwenden, um Dateien während der Spitzenzeiten zu verarbeiten. Dieser Ansatz spart Geld.

Szenariodetails

Automobilhersteller verwenden große Flotten von Prototyp- und Testfahrzeugen, um verschiedene Fahrzeugfunktionen zu testen und zu überprüfen. Testverfahren sind teuer, da sie echte Fahrer und Fahrzeuge erfordern und bestimmte reale Straßentestszenarien mehrfach bestanden werden müssen. Integrationstests sind besonders wichtig, um die Wechselwirkungen zwischen elektrischen, elektronischen und mechanischen Komponenten in komplexen Systemen zu bewerten.

Um Fahrzeugfunktionen zu validieren und Anomalien und Fehler zu analysieren, müssen Sie Petabyte an Diagnosedaten von elektronischen Steuergeräten (ECUs), Computerknoten, Fahrzeugkommunikationsbussen wie Controller Area Network (CAN) und Ethernet sowie Sensoren erfassen.

Bisher speicherten kleine Datenlogger-Server in den Fahrzeugen Diagnosedaten lokal als Dateien im Measurement Data Format (MDF), im Multimedia Fusion Extension (MFX), im CSV- oder im JSON-Format. Nach Abschluss der Testfahrten luden die Server Diagnosedaten in Rechenzentren hoch, die diese verarbeiteten und zur Analyse an Forschungs- und Entwicklungsingenieure& schicken. Dieser Vorgang kann Stunden oder manchmal Tage dauern. Neuere Szenarien verwenden Muster für die Erfassung von Telemetriedaten wie synchrone Datenströme auf der Basis von MQTT (Message Queuing Telemetry Transport) oder Dateiuploads in Quasi-Echtzeit.

Mögliche Anwendungsfälle

• Die Fahrzeugverwaltung wertet die Leistung und die gesammelten Daten pro Fahrzeug über mehrere Testszenarien hinweg aus.

• Die System- und Komponentenüberprüfung verwendet gesammelte Fahrzeugdaten, um zu überprüfen, ob das Verhalten der Fahrzeugkomponenten während der Fahrt innerhalb der Betriebsgrenzen liegt.

• Die Anomalieerkennung lokalisiert Abweichungen eines Sensorwerts von seinem typischen Basismuster in Echtzeit.

• Die Ursachenanalyse verwendet Machine Learning-Plug-Ins wie Clusteringalgorithmen, um Veränderungen in der Verteilung von Werten in mehreren Dimensionen zu erkennen.

• Predictive Maintenance kombiniert mehrere Datenquellen, angereicherte Standortdaten und Fahrzeugdaten, um die Zeit bis zum Ausfall von Komponenten vorherzusagen.

• Die Nachhaltigkeitsbewertung verwendet das Fahrerverhalten und den Energieverbrauch, um die Umweltauswirkungen des Fahrzeugbetriebs zu bewerten.

• Automobilrennen, um die Leistung der Fahrzeuge vor, während und nach einem Rennen zu verstehen und zu verbessern.

Ü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 unter Erstellen einer Checkliste zur Überprüfung der Zuverlässigkeit.

• Azure-Verfügbarkeitszonen sind individuelle physische Standorte innerhalb der gleichen Azure-Region. Verfügbarkeitszonen können Azure Data Explorer-Computecluster und -Daten vor einem teilweisen Ausfall der Region schützen.

• Business Continuity & Disaster Recovery (BCDR) in Azure Data Explorer ermöglicht es Ihrem Unternehmen, den Geschäftsbetrieb im Falle einer Störung aufrechtzuerhalten.

• Followerdatenbanken trennen Computeressourcen zwischen Produktions- und Nichtproduktionsanwendungsfällen.

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Sicherheit.

Es ist wichtig, die Aufteilung der Zuständigkeiten zwischen dem Automobilhersteller und Microsoft zu verstehen. Im Fahrzeug ist der Hersteller der Besitzer des gesamten Stapels, aber wenn die Daten in die Cloud wandern, gehen einige Verantwortlichkeiten auf Microsoft über. Azure Platform as a Service (PaaS) bietet integrierte Sicherheit auf dem physischen Stapel, einschließlich des Betriebssystems.

• Verwenden Sie Azure-Richtlinie , um Sicherheitsschutzschienen anzuwenden.

• Überprüfen Sie die Governanceübersicht und Anleitungen für Fabric.

• Verwenden Sie private Endpunkte, um Netzwerksicherheit für alle Dienste bereitzustellen.

  • Verwenden Sie private Endpunkte für Azure Data Explorer

  • Gewähren des Zugriffs auf Event Hubs-Namespaces über private Endpunkte

• Verschlüsseln Sie Daten im Ruhezustand und bei der Übertragung.

• Verwenden Sie Microsoft Entra-Identitäten und Microsoft Entra-Richtlinien für bedingten Zugriff .

• Verwenden Sie Sicherheit auf Zeilenebene (RLS) für KQL-Datenbanken und Azure Data Explorer.

• Verwenden Sie die Restrict-Anweisung , wenn Sie Middleware-Anwendungen mit Zugriff auf die KQL-Datenbank implementieren. Diese Konfiguration erstellt ein logisches Modell, das den Benutzerzugriff auf die Daten einschränkt.

All diese Features helfen Automobilherstellern, eine sichere Umgebung für ihre Fahrzeugtelemetriedaten zu schaffen. Weitere Informationen finden Sie unter Sicherheit in Fabic.

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 Erstellen einer Checkliste zur Überprüfung der Kostenoptimierung.

Diese Lösung verwendet die folgenden Praktiken, um die Kosten zu optimieren:

• Konfigurieren Sie Hot Caches und Cold Storage für die Raw- und Signaltabellen richtig. Der Cache für heiße Daten wird im RAM oder auf einer SSD gespeichert und bietet eine verbesserte Leistung. Kalte Daten sind jedoch 45 Mal günstiger. Legen Sie eine „Hot Cache“-Richtlinie fest, die für Ihren Anwendungsfall angemessen ist, z. B. 30 Tage.

• Richten Sie eine Aufbewahrungsrichtlinie für die Rohtabelle und die Signaltabelle ein. Bestimmen Sie, wann die Signaldaten nicht mehr relevant sind, wie nach 365 Tagen, und legen Sie die Aufbewahrungsrichtlinie entsprechend fest.

• Überlegen Sie, welche Signale für die Analyse relevant sind.

• Verwenden Sie materialisierte Sichten bei Ihrer Abfrage der letzten bekannten Werte der Signale, der deduplizierten Signale und der Signale mit Downsampling. Materialisierte Sichten verbrauchen weniger Ressourcen als die Aggregation von Quelltabellen bei jeder Abfrage.

• Berücksichtigen Sie Ihre Anforderungen an die Echtzeitdatenanalyse. Richten Sie die Streamingerfassung für die Livetelemetrietabelle ein, um eine Latenz von weniger als einer Sekunde zwischen der Erfassung und der Abfrage bereitzustellen. Dieser Ansatz erhöht CPU-Zyklen und Kosten.

Effiziente Leistung

Leistungseffizienz ist die Fähigkeit Ihrer Workload, eine effiziente Skalierung entsprechend den Anforderungen der Benutzer auszuführen. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Leistungseffizienz.

• Wenn die Anzahl und Größe der aufgezeichneten Datendateien mehr als 1.000 Dateien oder 300 MB pro Tag beträgt, sollten Sie die Verwendung der Stapelverarbeitung zur Dekodierung in Erwägung ziehen.

• Führen Sie allgemeine Berechnungen und Analysen ggf. nach der Erfassung durch, und speichern Sie sie in exta Tabellen.

• Verwenden Sie Best Practices für KQL-Abfragen, damit Ihre Abfrage schneller ausgeführt wird.

• Verwenden Sie eine where Klausel, um ein Zeitfenster zu definieren, um die Datenmenge zu verringern, die abgefragt wird. Erwägen Sie, die Datenpartitionsrichtlinie für die Signaltabelle zu ändern, wenn Ihre allgemeinen Suchkriterien nicht zeitbasiert sind, z. B. wenn Sie nach Aufzeichnungs-ID und Signalname filtern. Wenn die KQL-Datenbank erweitert wird, um Milliarden oder Billionen von Datensätzen zu enthalten, wird eine ordnungsgemäße Datenfiltration unerlässlich, insbesondere in Anbetracht der aktiven Partitionspolitik.

Bereitstellen dieses Szenarios

Verwenden Sie das schrittweise Lernprogramm , um dieses Szenario bereitzustellen. Das Handbuch zeigt, wie Sie eine kostenlose Instanz bereitstellen, MDF-Dateien analysieren, Daten aufnehmen und mehrere grundlegende Abfragen ausführen.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

• Boris Scholl | Partner, Chief Architect
• Frank Kaleck | Branchenberater Automobilindustrie
• Henning Rauch | Principal Program Manager
• Mario Ortegon-Cabrera | Principal Program Manager

Andere Mitwirkende:

• Devang Shah | Hauptprogramm-Manager
• Hans-Peter Bareiner | Cloud Solution Architect
• Jason Bouska | Sr. Software Engineer

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

• MQTT-Broker-Feature in Event Grid
• Hinzufügen eines KQL-Datenbankziels zu einem Eventstream
• Abrufen von Daten aus OneLake
• Materialisierte Sichten
• Erstellen von Echtzeitdashboards
• Erstellen von Datenaktivatorwarnungen aus einem Echtzeit-Dashboard
• Power BI Bericht
• Visualisieren von Daten über Azure Data Explorer in Grafana
• Messaging in der Automobilindustrie, Daten und Analysereferenzarchitektur

Zugehörige Ressourcen

• DevOps-Toolkette für softwaredefinierte Fahrzeuge
• Entwurfsleitfaden für Vorgänge in autonomen Fahrzeugen
• Muster für die Anspruchsprüfung