Datenanalyse für Fahrzeugtestflotten

Automobil-Erstausrüster (OEMs) benötigen Lösungen, um die Zeit zwischen Testfahrten und der Übermittlung 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 auf Szenarien der Telemetrie und zur Erfassung von Batch-Testfahrdaten. Der Schwerpunkt dieser Architektur liegt auf der Datenplattform, die Diagnosedaten verarbeitet, und den Konnektoren für die Datenvisualisierung und Datenberichterstattung.

Architecture

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

Dataflow

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 Claim-Check-Muster.

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-Fahrzeugsignale für die Aufnahme im Eventhouse weiter.

   (3b) Eine Datenpipeline löst die Eingabe dekodierter Dateien aus dem Lakehouse aus.

4. Das Eventhouse verwendet Updaterichtlinien, um die Daten anzureichern und die JSON-Daten in ein geeignetes Zeilenformat zu erweitern; beispielsweise könnten standortbezogene Daten gruppiert werden, um sie an geospatiale Analysen anzupassen. Jedes Mal, wenn eine neue Zeile aufgenommen wird, ruft das Analysemodul in Echtzeit eine zugeordnete Update() Funktion auf.

5. Dateningenieure und Datenwissenschaftler verwenden die Kusto-Abfragesprache (KQL), um Analyseanwendungen zu erstellen. 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. Dateningenieure und Datenwissenschaftler 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. Datentechniker und R&D-Techniker verwenden Datenaktivator , um Reflexelemente zu erstellen, um Bedingungen zu überwachen und Aktionen auszulösen, z. B. Das Auslösen von Power Automate-Flüssen für die Unternehmensintegration. Beispielsweise kann der Data Activator einen Teams-Kanal benachrichtigen, wenn sich der Zustand eines Geräts verschlechtert.

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 in einzelne Fahrzeugsignalaufzeichnungen zu erweitern, indem Sie Methoden wie die folgenden verwenden:

  • 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 Ansicht für deduplizierte Signale durch die Verwendung der Aggregationsfunktion take_any() auf den eindeutigen Schlüssel und den 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 Machine Learning-Plug-Ins wie Autocluster , um häufige Muster von diskreten Attributen 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 materialisierte Ansicht der zuletzt bekannten Metadaten der Flotte, um den aktuellen Zustand der Fahrzeugflotte basierend auf der Spalte "Zuletzt geändert" zu speichern.

Components

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 ist ein Dienst, der Daten über Eventstreams und KQL-Datenbanken erfasst, analysiert und darauf reagiert. In dieser Architektur speichert und verarbeitet sie Fahrzeugtelemetrie in Bewegung, die Echtzeitanalysen ermöglicht und automatisierte Aktionen durch Reflexe auslöst.

• Der Datenaktivator ist ein Automatisierungstool ohne Code, das auf Datenmuster und -bedingungen reagiert. In dieser Architektur überwacht sie Telemetriedaten und löst Aktionen wie Warnungen oder Power Automate-Flüsse aus, wenn Daten vordefinierte Bedingungen erfüllen.

• Event Grid ist ein verwalteter Ereignisroutingdienst, der MQTT und andere Protokolle unterstützt. In dieser Architektur verteilt sie Telemetrie- und Dateiuploadereignisse von Fahrzeugen an nachgeschaltete Dienste wie Azure Functions und das Lakehouse. Fahrzeuge können das Event Grid verwenden, um Themen zu veröffentlichen und zu abonnieren. Beispielsweise können sie Telemetrie veröffentlichen und Befehls- und Kontrollmeldungen abonnieren.

• Azure Event Hubs ist eine Echtzeitdatenstreamingplattform, die für Szenarien mit hohem Durchsatz entwickelt wurde. In dieser Architektur erfasst sie Millionen von Fahrzeugtelemetrieereignissen pro Sekunde mit geringer Latenz für die Echtzeitverarbeitung.

• Funktionen sind ein serverloser Computedienst, der Code als Reaktion auf Ereignisse ausführt. In dieser Architektur decodiert sie Telemetriedaten, koordiniert die Dateiaufnahme und löst nachgeschaltete Analyseworkflows aus. Sie vereinfacht die Verarbeitung von Fahrzeugtelemetrieereignissen in großem Maßstab durch den Einsatz ereignisgesteuerter Trigger und Bindungen mithilfe Ihrer Wunschsprache.

• Azure Managed Grafana ist eine Datenvisualisierungsplattform, die auf der Software von Grafana Labs basiert. Microsoft verwaltet und unterstützt Azure Managed Grafana. In dieser Architektur werden Telemetriedaten visualisiert, die im Eventhouse gespeichert sind und Dashboards für Engineering- und Betriebsteams unterstützen.

• Azure App Service ist ein Dienst zum Erstellen und Hosten von Web-Apps und APIs. In dieser Architektur werden Fahrzeugtelemetriedaten verfügbar gemacht, die in Fabric gespeichert sind, über RESTful-APIs, die externe Anwendungen nutzen.

• API-Verwaltung ist eine hybride Multicloud-Plattform zum Verwalten von APIs. In dieser Architektur wird der Zugriff auf partnerorientierte APIs gesichert und abstrahiert, die zum Konfigurieren von Datenerfassungsgeräten und zum Integrieren von Geschäftsworkflows verwendet werden.

Alternatives

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 wird eine Functions-App ausgelöst, die die Decodierung einplant.

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 Dateischreiben in das Eventhouse einliest. Diese Funktion erstellt die Tabelle und die Datenzuordnung, falls erforderlich, und startet die Erfassung.

5. Die KQL-Datenbank importiert die Daten aus dem Lakehouse.

Diese Vorgehensweise bietet folgende Vorteile:

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

• Batch-Pools bieten Einblicke in Verarbeitungsstatistiken, Aufgabenwarteschlangen und den Zustand 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 Nebenzeiten 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, wo sie verarbeitet und zur Analyse an die Forschungs- und Entwicklungsingenieure weitergeleitet wurden. 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.

Considerations

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.

Reliability

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.

Security

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 Leitlinien 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 Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz 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 Ansichten, wenn Sie die letzten bekannten Werte der Signale, deduplizierte Signale und Signale mit Downsampling abfragen. 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.

Leistungseffizienz

Die Leistungseffizienz ist die Fähigkeit Ihrer Workload, sich auf effiziente Weise an die Anforderungen der Benutzer anzupassen. 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 nach der Erfassung allgemeine Berechnungen und Analysen durch und speichern Sie diese in zusätzlichen 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.

Contributors

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

Hauptautoren:

• Boris Scholl | Partner, Chief Architect
• Frank Kaleck | Branchenberater Automotive
• Henning Rauch | Hauptprogramm-Manager
• Mario Ortegon-Cabrera | Hauptprogramm-Manager

Andere Mitwirkende:

• Devang Shah | Hauptprogramm-Manager
• Hans-Peter Bareiner | Cloud-Lösungsarchitekt
• Jason Bouska | Senior Software Engineer, Azure Patterns & Practices

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

Nächste Schritte

• MQTT-Broker-Funktion in Event Grid
• Hinzufügen eines KQL-Datenbankziels zu einem Eventstream
• Abrufen von Daten aus OneLake
• Materialisierte Ansichten
• Erstellen von Echtzeitdashboards
• Erstellen von Datenaktivatorwarnungen aus einem Echtzeit-Dashboard
• Power BI Bericht
• Visualisieren von Daten über Azure Data Explorer in Grafana
• Automobilnachrichten, Daten und Analyse-Referenzarchitektur

Verwandte Ressourcen

• DevOps-Toolkette für softwaredefinierte Fahrzeuge
• Referenzarchitektur für autonome Fahrzeugvorgänge (AVOps)
• Claim-Check Muster