Bearbeiten

Freigeben über

Datenvorgänge für autonome Fahrzeugvorgänge

Azure Batch
Azure Cosmos DB
Azure Data Factory
Azure Data Lake Storage
Azure Data Share

Dieser Artikel enthält eine Lösung und Anleitung für die Entwicklung von Offlinedatenvorgängen und Datenverwaltung (DataOps) für ein automatisiertes Fahrsystem. Die DataOps-Lösung basiert auf dem Framework, das in Designhandbuch für autonome Fahrzeugvorgänge (AVOps)beschrieben wird. DataOps ist einer der Bausteine von AVOps. Weitere Bausteine sind Machine Learning Operations (MLOps), Validierungsvorgänge (ValOps), DevOps und zentralisierte AVOps-Funktionen.

Apache®, Apache Sparkund Apache Laminat sind entweder eingetragene Marken oder Marken der Apache Software Foundation in den USA und/oder anderen Ländern. Keine Bestätigung durch die Apache Software Foundation wird durch die Verwendung dieser Marken impliziert.

Architektur

Architekturdiagramm, das eine Lösung zum Aufnehmen, Verarbeiten und Anreichern autonomer Fahrzeugdaten zeigt.

Laden Sie eine Visio-Datei herunter, die die Architekturdiagramme in diesem Artikel enthält.

Datenfluss

  1. Messdaten stammen aus den Datenströmen eines Fahrzeugs. Zu den Quellen gehören Kameras, Fahrzeugtelemetrie und Radar-, Ultraschall- und Lidar-Sensoren. Datenlogger im Fahrzeug speichern die Messdaten auf Logger-Speichergeräten. Die Loggerspeicherdaten werden in einen Landedatensee hochgeladen. Ein Dienst wie Azure Data Box oder Azure Stack Edge oder eine dedizierte Verbindung wie Azure ExpressRoute erfasst die Daten in Azure. Messdaten in den folgenden Formaten landen in Azure Data Lake Storage: Messdatenformat Version 4 (MDF4), technische Datenmanagementsysteme (TDMS) und Rosbag. Die hochgeladenen Daten geben ein dediziertes Speicherkonto mit dem Namen Landing ein, das für den Empfang und die Überprüfung der Daten bestimmt ist.

  2. Eine Azure Data Factory-Pipeline wird in einem geplanten Intervall ausgelöst, um die Daten im Zielspeicherkonto zu verarbeiten. Die Pipeline behandelt die folgenden Schritte:

    • Führt eine Datenqualitätsprüfung aus, z. B. eine Prüfsumme. In diesem Schritt werden daten mit niedriger Qualität entfernt, sodass nur qualitativ hochwertige Daten an die nächste Stufe weitergeleitet werden. Azure App Service wird verwendet, um den Qualitätsüberprüfungscode auszuführen. Daten, die als unvollständig eingestuft werden, werden zur zukünftigen Verarbeitung archiviert.
    • Zum Nachverfolgen von Linien ruft eine Metadaten-API mithilfe von App Service auf. In diesem Schritt werden Metadaten aktualisiert, die in Azure Cosmos DB gespeichert sind, um einen neuen Datenstrom zu erstellen. Für jede Messung gibt es einen Rohdatenstrom.
    • Kopiert die Daten in ein Speicherkonto namens Raw in Data Lake Storage.
    • Ruft die Metadaten-API auf, um den Datenstrom als vollständig zu markieren, damit andere Komponenten und Dienste den Datenstrom nutzen können.
    • Archiviert die Messungen und entfernt sie aus dem Landespeicherkonto.

  3. Data Factory und Azure Batch verarbeiten die Daten in der Rohzone, um Informationen zu extrahieren, die nachgelagerte Systeme nutzen können:

    • Batch liest die Daten aus Themen in der Rohdatei und gibt die Daten in ausgewählte Themen in den jeweiligen Ordnern aus.
    • Da die Dateien in der unformatierten Zone jeweils mehr als 2 GB groß sein können, werden parallele Verarbeitungsextraktionsfunktionen für jede Datei ausgeführt. Diese Funktionen extrahieren Bildverarbeitungs-, Lidar-, Radar- und GPS-Daten. Sie führen auch Metadatenverarbeitung durch. Data Factory und Batch bieten eine Möglichkeit, Parallelität auf skalierbare Weise durchzuführen.
    • Die Daten werden herunterstempelt, um die Datenmenge zu reduzieren, die beschriftet und kommentiert werden muss.

  4. Wenn Daten aus dem Fahrzeuglogger nicht über die verschiedenen Sensoren synchronisiert werden, wird eine Data Factory-Pipeline ausgelöst, die die Daten synchronisiert, um ein gültiges Dataset zu erstellen. Der Synchronisierungsalgorithmus wird im Batch ausgeführt.

  5. Eine Data Factory-Pipeline wird ausgeführt, um die Daten zu bereichern. Beispiele für Verbesserungen sind Telemetrie, Fahrzeugprotokollierungsdaten und andere Daten, z. B. Wetter-, Karten- oder Objektdaten. Angereicherte Daten helfen Datenwissenschaftlern dabei, Erkenntnisse zu gewinnen, die sie beispielsweise in der Algorithmusentwicklung verwenden können. Die generierten Daten werden in Apache-Parkettdateien gespeichert, die mit den synchronisierten Daten kompatibel sind. Metadaten zu den angereicherten Daten werden in einem Metadatenspeicher in Azure Cosmos DB gespeichert.

  6. Drittanbieterpartner führen manuelle oder automatische Bezeichnungen aus. Die Daten werden über Azure Data Share an die Drittanbieterpartner weitergegeben und in Microsoft Purview integriert. Die Datenfreigabe verwendet ein dediziertes Speicherkonto mit dem Namen mit bezeichnungsgeschrifteten in Data Lake Storage, um die bezeichneten Daten an die Organisation zurückzugeben.

  7. Eine Data Factory-Pipeline führt die Szenenerkennung durch. Szenenmetadaten werden im Metadatenspeicher gespeichert. Szenendaten werden als Objekte in Parkett- oder Delta-Dateien gespeichert.

  8. Neben Metadaten für die Anreicherungsdaten und erkannten Szenen speichert der Metadatenspeicher in Azure Cosmos DB Metadaten für die Messungen, z. B. Laufwerkdaten. Dieser Speicher enthält auch Metadaten für die Herkunft der Daten, da sie die Prozesse der Extraktion, Dessampling, Synchronisierung, Anreicherung und Szenenerkennung durchläuft. Die Metadaten-API wird verwendet, um auf die Messungen, die Linien und die Szenendaten zuzugreifen und nachzuschlagen, wo Daten gespeichert sind. Daher dient die Metadaten-API als Speicherschicht-Manager. Sie verteilt Daten über Speicherkonten. Es bietet Entwicklern auch eine Möglichkeit, eine metadatenbasierte Suche zum Abrufen von Datenspeicherorten zu verwenden. Aus diesem Grund ist der Metadatenspeicher eine zentrale Komponente, die Rückverfolgbarkeit und Linienführung über den Datenfluss der Lösung hinweg bietet.

  9. Azure Databricks und Azure Synapse Analytics werden verwendet, um eine Verbindung mit der Metadaten-API herzustellen und auf Data Lake Storage zuzugreifen und Forschungsarbeiten zu den Daten durchzuführen.

Komponenten

  • Data Box- bietet eine Möglichkeit zum Senden von Daten in und aus Azure auf schnelle, kostengünstige und zuverlässige Weise. In dieser Lösung wird Data Box verwendet, um gesammelte Fahrzeugdaten über einen regionalen Netzbetreiber an Azure zu übertragen.
  • Azure Stack Edge Geräte bieten Azure-Funktionen an Edgespeicherorten. Beispiele für Azure-Funktionen sind Compute, Speicher, Netzwerk und hardwarebeschleunigtes maschinelles Lernen.
  • ExpressRoute erweitert ein lokales Netzwerk über eine private Verbindung in die Microsoft Cloud.
  • Data Lake Storage- enthält eine große Menge an Daten im nativen, rohen Format. In diesem Fall speichert Data Lake Storage Daten basierend auf Phasen, z. B. roh oder extrahiert.
  • Data Factory ist eine vollständig verwaltete, serverlose Lösung zum Erstellen und Planen von Extrakten, Transformationen, Lasten (ETL) und Extrahieren, Laden, Transformieren (ELT)-Workflows. Hier führt Data Factory ETL über Batch compute aus und erstellt datengesteuerte Workflows zum Orchestrieren von Datenbewegungen und Transformieren von Daten.
  • Batch- werden parallele und HOCHLEISTUNGS-Batchaufträge effizient in Azure ausgeführt. Diese Lösung verwendet Batch zum Ausführen von umfangreichen Anwendungen für Aufgaben wie das Wrangling von Daten, das Filtern und Vorbereiten von Daten und das Extrahieren von Metadaten.
  • Azure Cosmos DB- ist eine global verteilte Datenbank mit mehreren Modellen. Hier werden Metadatenergebnisse wie gespeicherte Messungen gespeichert.
  • Datenfreigabe Daten mit Partnerorganisationen mit verbesserter Sicherheit gemeinsam nutzen. Mithilfe der direkten Freigabe können Datenanbieter Daten freigeben, an denen sie sich befinden, ohne die Daten zu kopieren oder Momentaufnahmen zu erstellen. In dieser Lösung teilt Data Share Daten mit Bezeichnungsunternehmen.
  • Azure Databricks bietet eine Reihe von Tools für die Aufrechterhaltung von Datenlösungen auf Unternehmensniveau im großen Maßstab. Es ist für lange Betriebsabläufe in großen Mengen von Fahrzeugdaten erforderlich. Datentechniker verwenden Azure Databricks als Analyse-Workbench.
  • Azure Synapse Analytics reduziert Zeit für Einblicke in Data Warehouses und Big Data-Systeme.
  • Azure Cognitive Search stellt Suchdienste für den Datenkatalog bereit.
  • App Service stellt einen serverlosen Web App Service bereit. In diesem Fall hosten App Service die Metadaten-API.
  • Microsoft Purview bietet Datengovernance in allen Organisationen.
  • Azure Container Registry ist ein Dienst, der eine verwaltete Registrierung von Containerimages erstellt. Diese Lösung verwendet containerregistrierung zum Speichern von Containern für verarbeitungsthemen.
  • Application Insights ist eine Erweiterung von Azure Monitor, die anwendungsleistungsverwaltung bietet. In diesem Szenario hilft Application Insights Ihnen beim Erstellen der Observability rund um die Messextraktion: Sie können Application Insights verwenden, um benutzerdefinierte Ereignisse, benutzerdefinierte Metriken und andere Informationen zu protokollieren, während die Lösung jede Messung für die Extraktion verarbeitet. Sie können auch Abfragen auf Log Analytics erstellen, um detaillierte Informationen zu den einzelnen Messungen zu erhalten.

Szenariodetails

Das Entwerfen eines robusten DataOps-Frameworks für autonome Fahrzeuge ist entscheidend für die Verwendung Ihrer Daten, die Ablaufverfolgung ihrer Herkunft und die Bereitstellung in Ihrer gesamten Organisation. Ohne einen gut gestalteten DataOps-Prozess kann die massive Menge an Daten, die autonome Fahrzeuge generieren, schnell überwältigend und schwierig zu verwalten sein.

Wenn Sie eine effektive DataOps-Strategie implementieren, können Sie sicherstellen, dass Ihre Daten ordnungsgemäß gespeichert, leicht zugänglich sind und über eine klare Linie verfügen. Sie machen es auch einfach, die Daten zu verwalten und zu analysieren, was zu fundierteren Entscheidungsfindungen und verbesserter Fahrzeugleistung führt.

Ein effizienter DataOps-Prozess bietet eine Möglichkeit zum einfachen Verteilen von Daten in Ihrer gesamten Organisation. Verschiedene Teams können dann auf die Informationen zugreifen, die sie benötigen, um ihre Vorgänge zu optimieren. DataOps erleichtert die Zusammenarbeit und das Teilen von Erkenntnissen, was dazu beiträgt, die Gesamteffizienz Ihrer Organisation zu verbessern.

Typische Herausforderungen für Datenvorgänge im Kontext autonomer Fahrzeuge sind:

  • Management des täglichen Terabyte- oder Petabyte-Umfangs von Messdaten aus Forschungs- und Entwicklungsfahrzeugen.
  • Datenfreigabe und Zusammenarbeit in mehreren Teams und Partnern, z. B. für Bezeichnungen, Anmerkungen und Qualitätsprüfungen.
  • Traceability and lineage for a safety-critical perception stack that captures versionsing and the lineage of measurement data.
  • Metadaten und Datenermittlung zur Verbesserung der semantischen Segmentierung, Bildklassifizierung und Objekterkennungsmodelle.

Diese AVOps DataOps-Lösung bietet Anleitungen zur Bewältigung dieser Herausforderungen.

Potenzielle Anwendungsfälle

Diese Lösung profitiert von automobilen Originalausrüstungsherstellern (OEMs), Tier 1-Anbietern und unabhängigen Softwareanbietern (ISVs), die Lösungen für automatisiertes Fahren entwickeln.

Sammeldatenvorgänge

In einer Organisation, die AVOps implementiert, tragen mehrere Teams aufgrund der Komplexität, die für AVOps erforderlich ist, zu DataOps bei. Beispielsweise kann ein Team für die Datenerfassung und Die Erfassung von Daten verantwortlich sein. Ein anderes Team kann für die Datenqualitätsverwaltung von Lidar-Daten verantwortlich sein. Aus diesem Grund sind die folgenden Prinzipien einer Datengitterarchitektur für DataOps wichtig:

  • Domänenorientierte Dezentralisierung von Datenbesitz und Architektur. Ein dediziertes Team ist für eine Datendomäne verantwortlich, die Datenprodukte für diese Domäne bereitstellt, z. B. mit Bezeichnungen versehene Datasets.
  • Daten als Produkt. Jede Datendomäne verfügt über verschiedene Zonen auf implementierten Data Lake-Speichercontainern. Es gibt Zonen für die interne Nutzung. Es gibt auch eine Zone, die veröffentlichte Datenprodukte für andere Datendomänen oder externe Nutzung enthält, um Die Datenduplizierung zu vermeiden.
  • Self-serve data as a platform to enable autonomous, domain-oriented data teams.
  • Verbundgovernance zum Aktivieren der Interoperabilität und des Zugriffs zwischen AVOps-Datendomänen, die einen zentralen Metadatenspeicher und einen Datenkatalog erfordern. Beispielsweise kann eine Bezeichnungsdatendomäne Zugriff auf eine Datensammlungsdomäne haben.

Weitere Informationen zu Datengitterimplementierungen finden Sie unter Cloud-Skalierungsanalyse.

Beispielstruktur für AVOps-Datendomänen

Die folgende Tabelle enthält einige Ideen zum Strukturieren von AVOps-Datendomänen:

Datendomäne Veröffentlichte Datenprodukte Lösungsschritt
Datensammlung Hochgeladene und validierte Messdateien Landung und roh
Extrahierte Bilder Ausgewählte und extrahierte Bilder oder Frames, Lidar- und Netzdaten Extrahiert
Extrahiertes Radar oder Lidar Ausgewählte und extrahierte Lidar- und Netzdaten Extrahiert
Extrahierte Telemetrie Ausgewählte und extrahierte Autotelemetriedaten Extrahiert
Beschriftet Beschriftete Datasets Beschriftet
Wieder rechnen Generierte Key Performance Indicators (KPIs) basierend auf wiederholten Simulationsläufen Wieder rechnen

Jede AVOps-Datendomäne wird basierend auf einer Blueprint-Struktur eingerichtet. Diese Struktur umfasst Data Factory, Data Lake Storage, Datenbanken, Batch und Apache Spark Runtimes über Azure Databricks oder Azure Synapse Analytics.

Metadaten und Datenermittlung

Jede Datendomäne wird dezentralisiert und verwaltet die entsprechenden AVOps-Datenprodukte individuell. Für die zentrale Datenermittlung und um zu wissen, wo sich Datenprodukte befinden, sind zwei Komponenten erforderlich:

  • Ein Metadatenspeicher, der Metadaten zu verarbeiteten Messdateien und Datenströmen wie Videosequenzen speichert. Diese Komponente macht die Daten mit Anmerkungen auffindbar und nachverfolgbar, die indiziert werden müssen, z. B. zum Durchsuchen der Metadaten von nicht bezeichneten Dateien. Beispielsweise möchten Sie, dass der Metadatenspeicher alle Frames für bestimmte Fahrzeugidentifikationsnummern (VINs) oder Frames mit Fußgängern oder anderen anreicherungsbasierten Objekten zurückgibt.
  • Ein Datenkatalog, der Die Linien, die Abhängigkeiten zwischen AVOps-Datendomänen und welche Datenspeicher an der AVOps-Datenschleife beteiligt sind. Ein Beispiel für einen Datenkatalog ist Microsoft Purview.

Sie können Azure Data Explorer oder Azure Cognitive Search verwenden, um einen Metadatenspeicher zu erweitern, der auf Azure Cosmos DB basiert. Ihre Auswahl hängt vom endgültigen Szenario ab, das Sie für die Datenermittlung benötigen. Verwenden Sie Azure Cognitive Search für semantische Suchfunktionen.

Das folgende Metadatenmodelldiagramm zeigt ein typisches einheitliches Metadatenmodell, das in mehreren AVOps-Datenschleifenpfeilern verwendet wird:

Diagramm, das zeigt, wie die Lösung rohe Messdaten in abgeleitete Datenströme konvertiert.

Datenfreigabe

Die Datenfreigabe ist ein gängiges Szenario in einer AVOps-Datenschleife. Zu den Verwendungen gehören die Datenfreigabe zwischen Datendomänen und externer Freigabe, z. B. zum Integrieren von Bezeichnungspartnern. Microsoft Purview bietet die folgenden Funktionen für eine effiziente Datenfreigabe in einer Datenschleife:

Empfohlene Formate für den Datenaustausch von Bezeichnungen umfassen allgemeinen Objekte im Kontext-Dataset (COCO) und Association for Standardization of Automation and Measuring Systems (ASAM) OpenLABEL-Datasets.

In dieser Lösung werden die bezeichneten Datasets in MLOps- Prozessen verwendet, um spezielle Algorithmen wie Wahrnehmungs- und Sensorfusionsmodelle zu erstellen. Die Algorithmen können Szenen und Objekte in einer Umgebung erkennen, z. B. die Autowechselspuren, blockierte Straßen, Fußgängerverkehr, Ampeln und Verkehrsschilder.

Datenpipeline

In dieser DataOps-Lösung wird die Verschiebung von Daten zwischen verschiedenen Phasen in der Datenpipeline automatisiert. Durch diesen Ansatz bietet der Prozess Effizienz, Skalierbarkeit, Konsistenz, Reproduzierbarkeit, Anpassungsfähigkeit und Fehlerbehandlungsvorteile. Er verbessert den gesamten Entwicklungsprozess, beschleunigt den Fortschritt und unterstützt die sichere und effektive Bereitstellung autonomer Fahrtechnologien.

In den folgenden Abschnitten wird beschrieben, wie Sie die Datenverschiebung zwischen Phasen implementieren und wie Sie Ihre Speicherkonten strukturieren sollten.

Hierarchische Ordnerstruktur

Eine gut organisierte Ordnerstruktur ist eine wichtige Komponente einer Datenpipeline bei der autonomen Fahrentwicklung. Eine solche Struktur bietet eine systematische und leicht navigierbare Anordnung von Datendateien, wodurch eine effiziente Datenverwaltung und -abruf ermöglicht wird.

In dieser Lösung weist die Daten im rohen Ordner die folgende hierarchische Struktur auf:

Region/raw/<Maß-ID>/<Datenstrom-ID>/JJJJ/MM/DD

Die Daten im extrahierten Zonenspeicherkonto verwenden eine ähnliche hierarchische Struktur:

Region/extrahiert/<Mess-ID>/<data-stream-ID>/JJJJ/MM/DD

Mit ähnlichen hierarchischen Strukturen können Sie die hierarchische Namespacefunktion von Data Lake Storage nutzen. Hierarchische Strukturen helfen beim Erstellen skalierbarer und kostengünstiger Objektspeicher. Diese Strukturen verbessern auch die Effizienz der Objektsuche und des Abrufs. Die Partitionierung nach Jahr und VIN erleichtert die Suche nach relevanten Bildern aus bestimmten Fahrzeugen. Im Datensee wird für jeden Sensor ein Speichercontainer erstellt, z. B. für eine Kamera, ein GPS-Gerät oder einen Lidar- oder Radarsensor.

Landespeicherkonto für unformatiertes Speicherkonto

Eine Data Factory-Pipeline wird basierend auf einem Zeitplan ausgelöst. Nachdem die Pipeline ausgelöst wurde, werden die Daten aus dem Zielspeicherkonto in das Rohspeicherkonto kopiert.

Architekturdiagramm, das eine Data Factory-Pipeline zeigt. Die Pipeline überprüft, kopiert und archiviert Daten. Außerdem werden Datenströme erstellt.

Die Pipeline ruft alle Messordner ab und durchläuft sie. Bei jeder Messung führt die Lösung die folgenden Aktivitäten aus:

  1. Eine Funktion überprüft die Messung. Die Funktion ruft die Manifestdatei aus dem Messmanifest ab. Anschließend überprüft die Funktion, ob alle MDF4-, TDMS- und Rosbag-Messdateien für die aktuelle Messung im Messordner vorhanden sind. Wenn die Überprüfung erfolgreich ist, fährt die Funktion mit der nächsten Aktivität fort. Wenn die Überprüfung fehlschlägt, überspringt die Funktion die aktuelle Messung und wechselt zum nächsten Messordner.

  2. Ein Web-API-Aufruf erfolgt an eine API, die eine Messung erstellt, und die JSON-Nutzlast aus der JSON-Datei des Messmanifests wird an die API übergeben. Wenn der Aufruf erfolgreich ist, wird die Antwort analysiert, um die Mess-ID abzurufen. Wenn der Aufruf fehlschlägt, wird die Messung zur Fehlerbehandlung in die Fehleraktivität verschoben.

    Anmerkung

    Diese DataOps-Lösung basiert auf der Annahme, dass Sie die Anzahl der Anforderungen an den App-Dienst einschränken. Wenn Ihre Lösung möglicherweise eine unbestimmte Anzahl von Anforderungen vorgibt, sollten Sie ein Ratelimitingmusterin Betracht ziehen.

  3. Ein Web-API-Aufruf erfolgt an eine API, die einen Datenstrom erstellt, indem die erforderliche JSON-Nutzlast erstellt wird. Wenn der Aufruf erfolgreich ist, wird die Antwort analysiert, um die Datenstrom-ID und den Datenstromspeicherort abzurufen. Wenn der Aufruf fehlschlägt, wird die Messung in die On-Error-Aktivität verschoben.

  4. Ein Web-API-Aufruf wird ausgeführt, um den Status des Datenstroms auf Start Copyzu aktualisieren. Wenn der Aufruf erfolgreich ist, kopiert die Kopieraktivität Messdateien an den Datenstromspeicherort. Wenn der Aufruf fehlschlägt, wird die Messung in die On-Error-Aktivität verschoben.

  5. Eine Data Factory-Pipeline ruft Batch auf, um die Messdateien aus dem Zielspeicherkonto in das Rohspeicherkonto zu kopieren. Ein Kopiermodul einer Orchestrator-App erstellt einen Auftrag mit den folgenden Aufgaben für jede Messung:

    • Kopieren Sie die Messdateien in das Unformatierte Speicherkonto.
    • Kopieren Sie die Messdateien in ein Archivspeicherkonto.
    • Entfernen Sie die Messdateien aus dem Zielspeicherkonto.

    Anmerkung

    In diesen Aufgaben verwendet Batch einen Orchestratorpool und das AzCopy-Tool, um Daten zu kopieren und zu entfernen. AzCopy verwendet SAS-Token zum Ausführen von Kopier- oder Entfernungsaufgaben. SAS-Token werden in einem Schlüsseltresor gespeichert und mithilfe der Begriffe landingsaskey, archivesaskeyund rawsaskeyreferenziert.

  6. Ein Web-API-Aufruf wird ausgeführt, um den Status des Datenstroms auf Copy Completezu aktualisieren. Wenn der Aufruf erfolgreich verläuft, wird die Sequenz mit der nächsten Aktivität fortgesetzt. Wenn der Aufruf fehlschlägt, wird die Messung in die On-Error-Aktivität verschoben.

  7. Die Messdateien werden aus dem Landing Storage-Konto in ein Zielarchiv verschoben. Diese Aktivität kann eine bestimmte Messung erneut ausführen, indem sie über eine Hydratkopie-Pipeline zurück zum Zielspeicherkonto verschoben wird. Die Lebenszyklusverwaltung ist für diese Zone aktiviert, sodass Messungen in dieser Zone automatisch gelöscht oder archiviert werden.

  8. Wenn ein Fehler mit einer Messung auftritt, wird die Messung in eine Fehlerzone verschoben. Von dort aus kann es in das Landing Storage-Konto verschoben werden, um erneut ausgeführt zu werden. Alternativ kann die Lebenszyklusverwaltung die Messung automatisch löschen oder archiven.

Beachten Sie die folgenden Punkte:

  • Diese Pipelines werden basierend auf einem Zeitplan ausgelöst. Dieser Ansatz trägt dazu bei, die Rückverfolgbarkeit von Pipelineläufen zu verbessern und unnötige Läufe zu vermeiden.
  • Jede Pipeline ist mit einem Parallelitätswert von 1 konfiguriert, um sicherzustellen, dass alle vorherigen Ausführungen abgeschlossen sind, bevor die nächste geplante Ausführung beginnt.
  • Jede Pipeline ist so konfiguriert, dass Maßangaben parallel kopiert werden. Wenn beispielsweise eine geplante Ausführung 10 Messungen abnimmt, können die Pipelineschritte für alle zehn Messungen gleichzeitig ausgeführt werden.
  • Jede Pipeline ist so konfiguriert, dass eine Warnung in Monitor generiert wird, wenn die Pipeline länger dauert als die erwartete Zeit bis zum Ende.
  • Die On-Error-Aktivität wird in späteren Observability-Storys implementiert.
  • Die Lebenszyklusverwaltung löscht teilmaßliche Messungen automatisch, z. B. Messungen mit fehlenden Rosbag-Dateien.

Batchentwurf

Alle Extraktionslogik wird in verschiedenen Containerimages verpackt, wobei für jeden Extraktionsprozess ein Container vorhanden ist. Batch führt die Containerworkloads parallel aus, wenn sie Informationen aus Messdateien extrahiert.

Architekturdiagramm, das zeigt, wie Batch Bilder aus einer Containerregistrierung abruft und Extraktionsaufträge ausführt.

Batch verwendet einen Orchestratorpool und einen Ausführungspool für die Verarbeitung von Workloads:

  • Ein Orchestratorpool verfügt über Linux-Knoten ohne Unterstützung der Containerlaufzeit. Der Pool führt Python-Code aus, der die Batch-API zum Erstellen von Aufträgen und Aufgaben für den Ausführungspool verwendet. Dieser Pool überwacht diese Aufgaben ebenfalls. Data Factory ruft den Orchestratorpool auf, der die Containerarbeitslasten koordiniert, die Daten extrahieren.
  • Ein Ausführungspool verfügt über Linux-Knoten mit Containerlaufzeiten, um die Ausführung von Containerarbeitslasten zu unterstützen. Für diesen Pool werden Aufträge und Aufgaben über den Orchestratorpool geplant. Alle Containerimages, die für die Verarbeitung im Ausführungspool erforderlich sind, werden mithilfe von JFrog an eine Containerregistrierung übertragen. Der Ausführungspool ist so konfiguriert, dass eine Verbindung mit dieser Registrierung hergestellt und die erforderlichen Images abgerufen werden.

Speicherkonten, aus denen Daten gelesen und geschrieben werden, werden über NFS 3.0 auf den Batchknoten und den Containern bereitgestellt, die auf den Knoten ausgeführt werden. Mit diesem Ansatz können Batchknoten und Container Daten schnell verarbeiten, ohne die Datendateien lokal auf die Batchknoten herunterladen zu müssen.

Anmerkung

Die Batch- und Speicherkonten müssen sich im selben virtuellen Netzwerk befinden, damit die Bereitstellung erfolgt.

Batch aus Data Factory aufrufen

In der Extraktionspipeline übergibt der Trigger den Pfad der Metadatendatei und den Rohdatenstrompfad in den Pipelineparametern. Data Factory verwendet eine Nachschlageaktivität, um den JSON-Code aus der Manifestdatei zu analysieren. Die Rohdatenstrom-ID kann aus dem Rohdatenstrompfad extrahiert werden, indem die Pipelinevariable analysiert wird.

Data Factory ruft eine API zum Erstellen eines Datenstroms auf. Die API gibt den Pfad für den extrahierten Datenstrom zurück. Der extrahierte Pfad wird dem aktuellen Objekt hinzugefügt, und Data Factory ruft Batch über eine benutzerdefinierte Aktivität auf, indem das aktuelle Objekt übergeben wird, nachdem der extrahierte Datenstrompfad angefügt wurde:

{
"measurementId":"210b1ba7-9184-4840-a1c8-eb£397b7c686",
"rawDataStreamPath":"raw/2022/09/30/KA123456/210b1ba7-9184-4840-
alc8-ebf39767c68b/57472a44-0886-475-865a-ca32{c851207",
"extractedDatastreamPath":"extracted/2022/09/30/KA123456
/210bIba7-9184-4840-a1c8-ebf39767c68b/87404c9-0549-4a18-93ff-d1cc55£d8b78",
"extractedDataStreamId":"87404bc9-0549-4a18-93ff-d1cc55fd8b78"
}

Schrittweiser Extraktionsprozess

Architekturdiagramm, das die Schritte eines Auftrags zeigt, der Informationen aus Messdaten extrahiert.

  1. Data Factory plant einen Auftrag mit einer Aufgabe für den Orchestratorpool, um eine Messung für die Extraktion zu verarbeiten. Data Factory übergibt die folgenden Informationen an den Orchestratorpool:

    • Die Maß-ID
    • Speicherort der Messdateien vom Typ MDF4, TDMS oder Rosbag, die extrahiert werden müssen
    • Der Zielpfad des Speicherorts des extrahierten Inhalts
    • Die extrahierte Datenstrom-ID

  2. Der Orchestratorpool ruft eine API auf, um den Datenstrom zu aktualisieren und seinen Status auf Processingfestzulegen.

  3. Der Orchestratorpool erstellt einen Auftrag für jede Messdatei, die Teil der Messung ist. Jeder Auftrag enthält die folgenden Aufgaben:

    Aufgabe Zweck Anmerkung
    Validierung Überprüft, ob Daten aus der Messdatei extrahiert werden können. Alle anderen Vorgänge sind von diesem Vorgang abhängig.
    Verarbeiten von Metadaten Leitet Metadaten aus der Messdatei ab und erweitert die Metadaten der Datei mithilfe einer API, um die Metadaten der Datei zu aktualisieren.
    ProzessStructuredTopics Extrahiert strukturierte Daten aus einer bestimmten Messdatei. Die Liste der Themen, aus der strukturierte Daten extrahiert werden sollen, wird als Konfigurationsobjekt übergeben.
    ProzessCameraTopics Extrahiert Bilddaten aus einer bestimmten Messdatei. Die Liste der Themen zum Extrahieren von Bildern wird als Konfigurationsobjekt übergeben.
    ProzessLidarTopics Extrahiert Lidar-Daten aus einer bestimmten Messdatei. Die Liste der Themen, aus der Lidar-Daten extrahiert werden sollen, wird als Konfigurationsobjekt übergeben.
    ProzessCANTopics Extrahiert Daten des Controllerbereichsnetzwerks (CAN) aus einer bestimmten Messdatei. Die Liste der Themen zum Extrahieren von Daten wird als Konfigurationsobjekt übergeben.

  4. Der Orchestratorpool überwacht den Fortschritt jeder Aufgabe. Nachdem alle Aufträge für alle Messdateien abgeschlossen wurden, ruft der Pool eine API auf, um den Datenstrom zu aktualisieren und den Status auf Completedfestzulegen.

  5. Der Orchestrator beendet ordnungsgemäß.

    Anmerkung

    Jede Aufgabe ist ein separates Containerimage mit Logik, die für ihren Zweck entsprechend definiert ist. Aufgaben akzeptieren Konfigurationsobjekte als Eingabe. Beispielsweise gibt die Eingabe an, wo die Ausgabe geschrieben werden soll und welche Messdatei verarbeitet werden soll. Ein Array von Thementypen, z. B. sensor_msgs/Image, ist ein weiteres Beispiel für Eingaben. Da alle anderen Aufgaben von der Überprüfungsaufgabe abhängen, wird dafür eine abhängige Aufgabe erstellt. Alle anderen Aufgaben können unabhängig verarbeitet und parallel ausgeführt werden.

Betrachtungen

Diese Überlegungen implementieren die Säulen des Azure Well-Architected-Frameworks, das eine Reihe von leitden Tenets ist, die verwendet werden können, um die Qualität einer Workload zu verbessern. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Zuverlässigkeit

Zuverlässigkeit stellt sicher, dass Ihre Anwendung die Verpflichtungen erfüllen kann, die Sie an Ihre Kunden vornehmen. Weitere Informationen finden Sie unter Übersicht über die Zuverlässigkeitssäule.

  • In Ihrer Lösung sollten Sie Azure-Verfügbarkeitszonenverwenden, die eindeutige physische Standorte innerhalb derselben Azure-Region sind.
  • Planen der Notfallwiederherstellung und des Kontos Failover-.

Sicherheit

Die Sicherheit bietet Sicherheitsmaßnahmen gegen bewusste Angriffe und den Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Sicherheitssäule.

Es ist wichtig, die Verantwortungsteilung zwischen einem Automobil-OEM und Microsoft zu verstehen. In einem Fahrzeug besitzt der OEM den gesamten Stapel, aber da die Daten in die Cloud verschoben werden, übertragen einige Verantwortlichkeiten an Microsoft. Azure-Plattform als Dienstebene (PaaS) bieten integrierte Sicherheit im physischen Stapel, einschließlich des Betriebssystems. Sie können den vorhandenen Infrastruktursicherheitskomponenten die folgenden Funktionen hinzufügen:

Kostenoptimierung

Die Kostenoptimierung untersucht Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Kostenoptimierungssäule.

Ein hauptanliegend für OEMs und Tier 1-Lieferanten, die DataOps für automatisierte Fahrzeuge betreiben, ist die Betriebskosten. Diese Lösung verwendet die folgenden Methoden, um Kosten zu optimieren:

Beitragende

Dieser Artikel wird von Microsoft verwaltet. Sie wurde ursprünglich von den folgenden Mitwirkenden verfasst.

Hauptautoren:

Um nichtublic LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Nächste Schritte

Weitere Informationen zur Entwicklung von ValOps für ein autonomes Fahrsystem finden Sie unter:

Validierungsvorgänge für autonome Fahrzeugvorgänge

Möglicherweise sind Sie auch an diesen verwandten Artikeln interessiert: