In Messwertkonfigurationen werden die Telemetriekampagnen definiert, die vom Telemetriedienst ausgeführt werden. Eine Messwertkonfiguration ist eine Instanz einer MetricsConfig-Protokollpuffer-Nachricht (protobuf). In Messwertkonfigurationen wird festgelegt, wie Daten erhoben, verarbeitet und gemeldet werden. OEMs können Messwertkonfigurationen über die API des Telemetriedienstes aktivieren. Mehrere Konfigurationen können gleichzeitig ausgeführt werden.
Machen Sie sich zuerst mit der SDV-Architektur vertraut. Dabei handelt es sich um eine dienstorientierte Architektur, bei der Dienste Daten als Protobuf-Nachrichten veröffentlichen. Diese Nachrichten kommunizieren über den SDV-Kommunikationsstack über RPC oder Publish/Subscribe.
Wichtige Begriffe
Eine Messwertkonfiguration orchestriert die Datenerhebung, indem sie Datenquellen, Verarbeitungsregeln und Berichtsmechanismen definiert. Einer der Hauptvorteile dieser Edge-Verarbeitung ist die geringere mobile Datennutzung. Wenn Sie Daten mit hoher Frequenz auf dem Gerät verarbeiten und nur Aggregationen oder Erkenntnisse hochladen, reduzieren Sie die Menge der an die Cloud übertragenen Daten erheblich.
Die Definition einer Messwertkonfiguration beginnt mit der Auflistung der Datenquellen , die in der Konfiguration verwendet werden sollen. Das sind Dienste, die Daten über den SDV-Kommunikationsstack zur Verfügung stellen. Wenn Sie eine Konfiguration aktivieren, stellt der Telemetriedienst eine Verbindung zu diesen Quellen her, um Daten nach Bedarf zu streamen oder abzurufen.
Der Kern einer Konfiguration ist die Edge-Datenverarbeitungsfunktion, die über zustandsorientierte Datenaggregatoren verwaltet wird. Jeder Aggregator verwendet einen Nachrichtenersteller , der eine zustandsorientierte Proto-Nachrichteninstanz verwaltet. Jedes Feld in dieser Nachricht wird durch Auswerten eines Ausdrucks gefüllt, der definiert, welche Daten aus anderen Datenquellen oder Aggregatoren gelesen werden sollen und welche mathematischen, logischen oder Aggregationsvorgänge auf die Daten angewendet werden sollen. Sie können zusätzliche Aggregationen auf das Ergebnis eines Ausdrucks anwenden.
Trigger sind für die Steuerung dieses Prozesses von zentraler Bedeutung. Sie können in regelmäßigen Abständen, als Reaktion auf neue Daten oder wenn datenbasierte Bedingungen erfüllt sind, ausgelöst werden. Trigger legen fest, wann Aggregatoren ihren Nachrichtenersteller auswerten und wann Messwertberichte generiert werden. Sie können auch den Lebenszyklus der Konfiguration beeinflussen, z. B. durch Starten oder Beenden der Datenerhebung.
Messwertberichte sind die endgültige Ausgabe. Jeder Bericht enthält die durch einen Nachrichtenersteller definierte Datennutzlast sowie Metadaten wie Zeitstempel und Berichts-ID. Sie können Berichte zu bestimmten Zeitpunkten im Lebenszyklus der Konfiguration erstellen, z. B. wenn eine Konfiguration aktiviert oder deaktiviert wird. Generierte Berichte werden im Arbeitsspeicher gespeichert und der Client wird über den Benachrichtigungskanal für den Berichtsstatus benachrichtigt, wenn sie abgerufen werden können.
Die folgende Abbildung zeigt ein konzeptionelles Beispiel dafür, wie Komponenten in einer Messwertkonfiguration interagieren können:
Abbildung 1 : Datenquellen, Verarbeitung und Berichterstellung in einer Messwertkonfiguration.
Komponenten der Messwertkonfiguration
Mit Messwertkonfigurationen können Sie Datenerhebungsaufgaben und komplexe Verarbeitungspipelines auf dem Gerät definieren. In diesem Abschnitt werden die Kernkomponenten beschrieben, die zum Definieren einer Messwertkampagne verwendet werden. Die Komponenten werden in der Reihenfolge dargestellt, in der Daten durch das System fließen, von der Eingabe bis zur Ausgabe. Sie können diese Komponenten in beliebiger Reihenfolge definieren. Die Verarbeitung von Daten mit Aggregatoren und die Lebenszyklusverwaltung sind optional.
- Datenquellen definieren
- Daten mit Aggregatoren verarbeiten
- Ausführungsablauf mit Triggern steuern
- Messwertberichte erstellen
- Lebenszyklus der Datenerhebung verwalten
Datenquellen definieren
Die Grundlage jeder Messwertkampagne sind Daten. In einer Messwertkonfiguration wird der Mechanismus zum Empfangen von Daten abstrahiert. Sie müssen nur den Namen angeben, mit dem eine Datenquelle identifiziert werden kann, und den Verbindungsmodus (Abo oder auf Anfrage). Datenquellen können beliebige Dienste sein, die Daten über den SDV-Kommunikationsstack zur Verfügung stellen oder sich in der konfigurierbaren Publisher-Registrierungregistrieren. Dadurch wird die Datenerhebung aus Apps ermöglicht, in denen keine SDV-Middleware verfügbar ist. Jede Datenquelle muss in der Konfiguration einen eindeutigen Namen haben, damit sie von anderen Komponenten der Messwertkonfiguration wie Triggern oder Aggregatoren referenziert werden kann. Sie können konfigurieren, wie die Verbindung hergestellt wird, wie oft Daten empfangen werden und ein dienstspezifisches Konfigurationsobjekt angeben.
Konfiguration von Datenquellen
Der Telemetriedienst kann auf zwei Arten eine Verbindung zu einer Datenquelle herstellen:
- Getter:Mit dieser Methode werden Daten auf Anfrage abgerufen, wenn ein in der Messwertkonfiguration definierter Ausdruck Daten aus dieser Quelle lesen muss. Das ist nützlich für Datenquellen, die keinen kontinuierlichen Stream bereitstellen, oder wenn Sie nur selten Snapshots von Daten benötigen.
- Abo:Dies ist die Standardmethode. Es wird ein kontinuierlicher Datenstream aus der Quelle eingerichtet. Dieser Verbindungstyp ist erforderlich, wenn Sie einen Datentrigger verwenden möchten, der ausgelöst wird, wenn neue Nachrichten aus dieser Quelle eingehen.
Wenn Sie ein Abo verwenden, können Sie Folgendes konfigurieren:
- Subsampling:Um zu vermeiden, dass Daten zu häufig aufgenommen werden, können Sie ein Mindestzeitintervall zwischen aufeinanderfolgenden Nachrichten aus derselben Quelle definieren. Wenn die Quelle Daten schneller als dieses Intervall veröffentlicht, drosselt der Telemetriedienst die Benachrichtigungen und Datentrigger werden nur für Nachrichten aktiviert, die nach der Drosselung empfangen wurden. Dadurch werden die Daten effektiv untersampelt.
- Abruf der ersten Nachricht:Sie können den Dienst so konfigurieren, dass er die letzte Nachricht aus der Quelle abruft, wenn das Abo eingerichtet wird. Dadurch wird die Datenquelle sofort mit einem Wert gefüllt, falls einer verfügbar ist, anstatt auf die Veröffentlichung der ersten neuen Nachricht zu warten. Das ist nützlich bei bedingten Triggern oder Aggregatoren, die einen Anfangszustand erfordern, oder wenn die Datenquelle nur selten Daten veröffentlicht.
Unabhängig vom Typ werden Nachrichten intern im Cache gespeichert. Wenn mehrere Ausdrücke oder Aggregatoren während eines einzelnen Auswertungszyklus Daten aus derselben Quelle benötigen, ruft das System die Daten nur einmal ab. Das kann entweder aus dem Cache erfolgen, wenn eine neue Nachricht über ein Abo eingegangen ist, oder über einen einzelnen Aufruf auf Anfrage.
Daten mit Aggregatoren verarbeiten
Datenquellen liefern Rohdaten, während Aggregatoren zustandsorientierte Edge-Datenverarbeitung durchführen. Sie verwenden Daten aus Datenquellen oder anderen Aggregatoren, transformieren sie und stellen das Ergebnis zur Verfügung, damit es von Messwertberichten gelesen oder von anderen Aggregatoren weiterverarbeitet werden kann. So lassen sich mehrstufige Verarbeitungspipelines erstellen, z. B. Geschwindigkeitsstatistiken in einem Aggregator berechnen und diese Statistiken in einer anderen Komponente verwenden, die Muster im Fahrverhalten erkennt.
Aggregatoren werden durch einen oder mehrere Trigger ausgelöst, um ihre Berechnungen durchzuführen. Jedes Mal, wenn einer der Trigger ausgelöst wird, wertet der Aggregator seine Regeln aus und aktualisiert seinen internen Zustand.
Sie können einen Aggregator so konfigurieren, dass sein Zustand zurückgesetzt wird, nachdem sein Wert von einer anderen Komponente gelesen wurde. Das ist nützlich, um Statistiken für nicht überlappende Zeiträume zu berechnen.
Ein Nachrichtenersteller definiert die Struktur und Logik eines Aggregators. Ein Nachrichten-Builder gibt an, wie eine Instanz einer Proto-Nachricht erstellt wird, indem er beschreibt, wie Daten für jedes Feld generiert werden. Für jedes Feld wird mit einem Ausdruck definiert, wie Daten aus Datenquellen und Aggregatoren gelesen und Vorgänge auf diese Daten angewendet werden. Außerdem können Sie eine Aggregation anwenden. Das ist eine Berechnungs- oder Erhebungsvorgang, der im Zeitverlauf auf die Ergebnisse des Ausdrucks angewendet wird.
Die folgenden Aggregationstypen werden unterstützt:
- Mathematisch:Berechnet Statistiken (Durchschnitt, Minimum, Maximum, Summe, Standardabweichung und Delta) für die Werte, die von einem Ausdruck bei jedem Trigger zurückgegeben werden. Delta ist die Differenz zwischen dem aktuellen und dem vorherigen numerischen Wert, der von einem Ausdruck zurückgegeben wird.
- Liste:Erhebt die von einem Ausdruck zurückgegebenen Werte in einer Liste. Sie können die Listengröße begrenzen, um ein gleitendes Fenster (Ringpuffer) der letzten Werte zu erstellen.
- Anzahl:Sonderfall, bei dem kein Ausdruck angegeben wird. Zählt, wie oft das Feld ausgewertet wird (d. h. wie oft der Aggregator oder Bericht ausgelöst wird).
- Passthrough:Verwendet das Ergebnis eines Ausdrucks direkt, ohne eine Aggregation anzuwenden. Das ist in Berichtskonfigurationen nützlich, um auf Endwerte von Aggregatoren zuzugreifen.
Die folgende Abbildung ist ein konzeptionelles Diagramm, das die Aggregatorauswertung veranschaulicht:
Abbildung 2 : Aggregatorauswertung.
Berechnungen durchführen oder Bedingungen mit Ausdrücken definieren
Ausdrücke werden in Nachrichtenerstellern und bedingten Triggern verwendet, um Berechnungen durchzuführen oder Bedingungen zu definieren. Wenn Sie den Generator für Messwertkonfigurationen (Metrics Configuration Generator, MCG) verwenden, um JSON-Objekte für Messwertkonfigurationen zu erstellen, werden Ausdrücke als für Menschen lesbare Strings geschrieben, die die Punktnotation verwenden, um auf Felder der Datenquelle zuzugreifen (z. B. vehicle_speed.speed_value) und eine Vielzahl von Vorgängen anzuwenden. MCG übersetzt diese Strings in eine optimierte Baumstruktur, ähnlich einem abstrakten Syntaxbaum (Abstract Syntax Tree, AST), für eine effiziente Auswertung auf dem Gerät in der endgültigen MetricsConfig-Protobuf-Nachricht.
Operatoren und Funktionen
Ausdrücke unterstützen die folgenden Operatoren und Funktionen:
- Arithmetisch:Unterstützt Addition, Subtraktion (binär und unär), Multiplikation, Division, Modulo und Potenz.
- Logisch:Unterstützt AND, OR, NOT und XOR.
- Relational:Unterstützt Gleichheitsprüfung und Vergleiche mit „größer als“ und „kleiner als“.
- Liste:Prüft, ob eine Liste einen bestimmten Wert enthält oder nicht.
- Zeitstempel:Gibt den Zeitstempel zum Zeitpunkt der Auswertung in Mikrosekunden zurück. Der Uhrtyp kann die Echtzeituhr, die monotone Zeit seit dem Start (einschließlich der Zeit im Standby-Modus) oder die monotone Zeit seit dem Start oder der letzten Wiederaufnahme sein.
- Absolutwert:Gibt den Absolutwert einer Zahl zurück.
- Runden:Rundet auf die nächste Ganzzahl (
round), gibt die größte Ganzzahl zurück, die kleiner oder gleich einer Zahl ist (floor), oder gibt die kleinste Ganzzahl zurück, die größer oder gleich einer Zahl ist (ceil).
Hier ist ein Beispiel für einen Ausdruck, der aus zwei Datenquellen liest und true zurückgibt, wenn die Fahrzeuggeschwindigkeit 100 km/h übersteigt und keine Reifendruckwarnung vorliegt:
(vehicle_speed.speed_value * 3.6) > 100 && tire_pressure.warning == false
Ausführungsablauf mit Triggern steuern
Trigger sind die Orchestratoren einer Messwertkonfiguration. Sie steuern, wann Daten verarbeitet und wann Berichte erstellt werden. Jeder Trigger muss einen eindeutigen Namen haben.
Es gibt drei Arten von Triggern:
- Datentrigger:Werden ausgelöst, wenn eine Datenquelle mit einer Aboverbindung eine neue Nachricht veröffentlicht (nach dem Subsampling, falls konfiguriert).
- Periodische Trigger:Werden in einem festen Zeitintervall ausgelöst.
- Bedingte Trigger:Werden ausgelöst, wenn eine bestimmte logische Bedingung erfüllt ist.
Bedingte Trigger
Bedingte Trigger beobachten andere Trigger (Daten-, periodische oder andere bedingte Trigger) und werten einen Ausdruck aus, wenn einer dieser Trigger ausgelöst wird. Der bedingte Trigger wird nur ausgelöst, wenn das Ergebnis des Ausdrucks eine bestimmte Bedingung erfüllt.
Sie können einen bedingten Trigger so konfigurieren, dass er basierend auf verschiedenen Bedingungstypen ausgelöst wird:
- Wert:Wenn der Ausdruck
true(oder ungleich null) oderfalse(oder null) ergibt. - Steigende Flanke:Wenn sich ein boolescher Ausdruck von
falseintrueändert oder ein numerischer Wert steigt. - Fallende Flanke:Wenn sich ein boolescher Ausdruck von
trueinfalseändert oder ein numerischer Wert sinkt. - Bei Änderung:Immer wenn sich das Ergebnis des Ausdrucks von seinem vorherigen Wert unterscheidet.
Rauschen bei Statusänderungen herausfiltern
Bei Edge-basierten oder On-Change-Triggern können Sie kurze oder verrauschte Statusänderungen (Glitches) herausfiltern, indem Sie festlegen, dass die Bedingung für eine Mindestdauer im neuen Zustand bleiben muss, bevor der Trigger ausgelöst wird.
Sie können beispielsweise einen Trigger so konfigurieren, dass er nur ausgelöst wird, wenn vehicle_speed > 100
zu true wird und mindestens 5 Sekunden lang true bleibt. So wird verhindert, dass der Trigger aufgrund eines kurzzeitigen Anstiegs der Geschwindigkeitsmessung ausgelöst wird. Sie können auch festlegen, dass alle Werte, die während dieser Haltezeit erfasst werden, genau gleich sein müssen.
Messwertberichte erstellen
Nachdem die Daten verarbeitet wurden, definieren Sie, wie und wann sie in Berichte verpackt werden.
Berichte werden mit Messwertberichtskonfigurationen definiert, die Nachrichtenersteller verwenden, um die Struktur und den Inhalt ihrer Ausgabe zu definieren. Wenn einer der Trigger des Berichts ausgelöst wird, wertet der Nachrichtenersteller seine Feldzuweisungen aus, um die Datennutzlast des Berichts zu erstellen.
Jeder generierte Bericht ist eine Instanz einer MetricsReport-Protobuf-Nachricht, die die Ausgabe des Nachrichtenerstellers in einem payload-Feld umschließt und Metadaten hinzufügt. Der Telemetriedienst fügt jedem MetricsReport automatisch die folgenden Metadaten hinzu:
- Eine Universally Unique Identifier (UUID) für den Bericht
- Eine fortlaufende Berichtsnummer, die für jeden Bericht erhöht wird, der mit dieser Berichtskonfiguration erstellt wurde
- Der Zeitstempel, der angibt, wann der Bericht generiert wurde
- Der Grund für die Generierung (z. B. durch eine Regel ausgelöst oder beim Herunterfahren generiert)
- Die UUID und Version der Messwertkonfiguration, mit der der Bericht generiert wurde
- Der Name der Messwertberichtskonfiguration
Steuerung der Berichterstellung
Berichte werden in der Regel als Reaktion auf Trigger erstellt. Sie können sie aber auch so konfigurieren, dass sie zu bestimmten Zeitpunkten im Lebenszyklus der Messwertkonfiguration generiert werden:
- Bericht bei Aktivierung:Wenn diese Option aktiviert ist, generiert das System sofort einen ersten Bericht, wenn die Messwertkonfiguration aktiviert wird.
- Abschlussbericht:Wenn diese Option aktiviert ist, generiert das System einen Abschlussbericht, wenn die Datenerhebung pausiert oder beendet wird oder wenn der Telemetriedienst heruntergefahren wird. Dieser Bericht enthält die bis zu diesem Zeitpunkt aggregierten Daten, damit am Ende einer Sitzung keine Daten verloren gehen.
Lebenszyklus der Datenerhebung verwalten
Standardmäßig beginnt eine Messwertkonfiguration mit der Erhebung und Verarbeitung von Daten, sobald sie von einem Client aktiviert wird, und wird fortgesetzt, bis sie vom Client deaktiviert wird. Sie können diesen Lebenszyklus jedoch genauer steuern, indem Sie Trigger definieren, die die Datenerhebung oder die Messwertkonfiguration starten oder beenden:
- Starttrigger:Wenn dieser Trigger definiert ist, beginnt die Datenerhebung erst, wenn er ausgelöst wird. Wenn die Erhebung durch einen Stopptrigger pausiert wurde, wird sie durch den Starttrigger wieder aufgenommen.
- Stopptrigger:Wenn dieser Trigger definiert ist, pausiert er die Datenerhebung. Aggregationen und Berichterstellung werden beendet, bis der Starttrigger wieder ausgelöst wird.
- Deaktivierungstrigger:Dieser Trigger deaktiviert die Messwertkonfiguration auf dieselbe Weise wie ein
deactivate_metrics_config-Aufruf vom Client.
Sie können beispielsweise einen bedingten Trigger definieren, der ausgelöst wird, wenn sich vehicle_state in DRIVING ändert, als Starttrigger und einen anderen, der ausgelöst wird, wenn sich vehicle_state in PARKED ändert, als Stopptrigger. So wird sichergestellt, dass Daten nur erhoben werden, wenn sich das Fahrzeug bewegt.