Concetti relativi alla configurazione delle metriche

Le configurazioni delle metriche definiscono le campagne di telemetria eseguite dal servizio di telemetria. Una configurazione delle metriche è un'istanza di un messaggio del buffer di protocollo (protobuf) MetricsConfig. Le configurazioni delle metriche specificano come raccogliere, elaborare e segnalare i dati. Gli OEM possono attivare le configurazioni delle metriche tramite l'API del servizio di telemetria. È possibile eseguire più configurazioni contemporaneamente.

Prima di iniziare, familiarizza con l'architettura SDV, che è un'architettura orientata ai servizi in cui i servizi pubblicano i dati come messaggi protobuf. Questi messaggi comunicano utilizzando lo stack di comunicazione SDV tramite RPC o pubblicazione/sottoscrizione.

Termini chiave

Una configurazione delle metriche orchestra la raccolta dei dati definendo le origini dati, le regole di elaborazione e i meccanismi di generazione di report. Uno dei principali vantaggi di questa elaborazione edge è la riduzione dell'utilizzo dei dati mobili. Elaborando i dati ad alta frequenza sul dispositivo e caricando solo aggregazioni o insight, riduci significativamente la quantità di dati trasmessi al cloud.

La definizione di una configurazione delle metriche inizia elencando le origini dati da utilizzare nella configurazione. Questi sono servizi che rendono disponibili i dati tramite lo stack di comunicazione SDV. Quando attivi una configurazione, il servizio di telemetria si connette a queste origini per eseguire lo streaming o recuperare i dati in base alle esigenze.

Il nucleo di una configurazione è la sua capacità di elaborazione dei dati edge, gestita tramite aggregatori di dati con stato. Ogni aggregatore utilizza un generatore di messaggi che mantiene un'istanza di messaggio proto con stato. Ogni campo di questo messaggio viene compilato valutando un'espressione, definendo quali dati leggere da altre origini dati o aggregatori e quali operazioni matematiche, logiche o di aggregazione applicare ai dati. Puoi applicare aggregazioni aggiuntive al risultato di un'espressione.

I trigger sono fondamentali per controllare questo processo. Possono essere attivati periodicamente, in risposta a nuovi dati o quando vengono soddisfatte condizioni basate sui dati. I trigger determinano quando gli aggregatori valutano il generatore di messaggi, quando vengono generati i report sulle metriche e possono influenzare il ciclo di vita della configurazione, ad esempio avviando o interrompendo la raccolta dei dati.

I report sulle metriche sono l'output finale. Ogni report include il payload dei dati definito da un generatore di messaggi, insieme a metadati come timestamp e ID report. Puoi generare report in momenti specifici del ciclo di vita della configurazione, ad esempio quando una configurazione viene attivata o disattivata. I report generati vengono archiviati in memoria e il client viene informato per il recupero tramite il canale di notifica dello stato del report.

La figura seguente fornisce un esempio concettuale di come i componenti possono interagire all'interno di una configurazione delle metriche:

Figura 1. Origini dati, elaborazione e generazione di report all'interno di una configurazione delle metriche.

Componenti della configurazione delle metriche

Puoi utilizzare le configurazioni delle metriche per definire attività di raccolta dei dati e pipeline di elaborazione su dispositivo complesse. Questa sezione descrive in dettaglio i componenti principali utilizzati per definire una campagna di metriche. I componenti vengono presentati nell'ordine in cui i dati fluiscono attraverso il sistema, dall'input all'output. Puoi definire questi componenti in qualsiasi ordine. L'elaborazione dei dati con gli aggregatori e la gestione del ciclo di vita sono facoltative.

• Definisci le origini dati
• Elabora i dati con gli aggregatori
• Controlla il flusso di esecuzione con i trigger
• Genera report sulle metriche
• Gestisci il ciclo di vita della raccolta dei dati

Definisci le origini dati

La base di qualsiasi campagna di metriche sono i dati. In una configurazione delle metriche, il meccanismo di ricezione dei dati è astratto e devi specificare solo il nome con cui un'origine dati può essere identificata e la modalità di connessione (sottoscrizione o su richiesta). Le origini dati possono essere qualsiasi servizio che rende disponibili i dati tramite lo stack di comunicazione SDV o si registra nel registro dei publisher configurabili, il che consente la raccolta dei dati dalle app in cui il middleware SDV non è disponibile. Ogni origine dati deve avere un nome univoco all'interno della configurazione in modo che possa essere referenziata da altri componenti della configurazione delle metriche, come trigger o aggregatori. Puoi configurare la modalità di connessione, la frequenza di ricezione dei dati e fornire un oggetto di configurazione specifico del servizio.

Configurazione delle origini dati

Il servizio di telemetria può connettersi a un'origine dati in due modi:

• Getter: questo metodo recupera i dati su richiesta ogni volta che un'espressione definita nella configurazione delle metriche deve leggere i dati da questa origine. È utile per le origini dati che non forniscono uno stream continuo o quando hai bisogno di snapshot di dati poco frequenti.
• Sottoscrizione: questo è il metodo predefinito. Stabilisce uno stream di dati continuo dall'origine. Questo tipo di connessione è necessario se intendi utilizzare un trigger di dati che si attiva quando arrivano nuovi messaggi da questa origine.

Quando utilizzi una sottoscrizione, puoi configurare:

• Sottocampionamento: per evitare di inserire i dati troppo spesso, puoi definire un intervallo di tempo minimo tra i messaggi consecutivi della stessa origine. Se l'origine pubblica i dati più velocemente di questo intervallo, il servizio di telemetria limita le notifiche e i trigger di dati si attivano solo per i messaggi ricevuti dopo la limitazione. In questo modo, i dati vengono sottocampionati.
• Recupero del messaggio iniziale: puoi configurare il servizio in modo che recuperi il messaggio più recente dall'origine quando stabilisce la sottoscrizione. Di conseguenza, l'origine dati viene compilata immediatamente con un valore, se disponibile, anziché attendere la pubblicazione del primo nuovo messaggio. È utile nei trigger condizionali o negli aggregatori che richiedono uno stato iniziale o quando l'origine dati pubblica raramente.

Indipendentemente dal tipo, i messaggi vengono memorizzati nella cache internamente. Se più espressioni o aggregatori richiedono dati dalla stessa origine durante un singolo ciclo di valutazione, il sistema recupera i dati una sola volta, dalla cache se è arrivato un nuovo messaggio utilizzando una sottoscrizione o utilizzando una singola chiamata su richiesta.

Elabora i dati con gli aggregatori

Mentre le origini dati forniscono dati non elaborati, gli aggregatori eseguono l'elaborazione dei dati edge con stato. Consumano i dati dalle origini dati o da altri aggregatori, li trasformano e rendono il risultato disponibile per la lettura da parte dei report sulle metriche o per l'ulteriore elaborazione da parte di altri aggregatori. In questo modo è possibile creare pipeline di elaborazione a più fasi, ad esempio calcolare le statistiche sulla velocità in un aggregatore e utilizzare queste statistiche in un altro componente che rileva i pattern di comportamento di guida.

Gli aggregatori vengono attivati per eseguire i calcoli da uno o più trigger. Ogni volta che uno dei suoi trigger si attiva, l'aggregatore valuta le sue regole e aggiorna il suo stato interno.

Puoi configurare un aggregatore in modo che reimposti il suo stato dopo che il suo valore è stato letto da un altro componente, il che è utile per calcolare le statistiche su finestre temporali non sovrapposte.

Un generatore di messaggi definisce la struttura e la logica di un aggregatore. Un generatore di messaggi specifica come costruire un'istanza di un messaggio proto descrivendo come generare i dati per ciascuno dei suoi campi. Per ogni campo, un'espressione definisce come leggere i dati dalle origini dati e dagli aggregatori e applicare le operazioni a questi dati. Inoltre, puoi applicare un'aggregazione, ovvero un' operazione di calcolo o raccolta applicata ai risultati dell'espressione nel tempo.

Sono supportati i seguenti tipi di aggregazione:

• Matematica: calcola le statistiche (media, minimo, massimo, somma, deviazione standard e delta) sui valori restituiti da un'espressione su ogni trigger. Delta è la differenza tra il valore numerico attuale e quello precedente restituito da un'espressione.
• Elenco: raccoglie i valori restituiti da un'espressione in un elenco. Puoi limitare le dimensioni dell'elenco per creare una finestra mobile (buffer ad anello) dei valori recenti.
• Conteggio: caso speciale in cui non viene specificata alcuna espressione. Conta il numero di volte in cui il campo viene valutato (ovvero il numero di volte in cui viene attivato l'aggregatore o il report).
• Passthrough: utilizza direttamente il risultato di un'espressione, senza applicare un'aggregazione. È utile nelle configurazioni dei report per accedere ai valori finali degli aggregatori.

La figura seguente è un diagramma concettuale che illustra la valutazione dell'aggregatore:

Figura 2. Valutazione dell'aggregatore.

Esegui calcoli o definisci condizioni utilizzando le espressioni

Le espressioni vengono utilizzate all'interno dei generatori di messaggi e dei trigger condizionali per eseguire calcoli o definire condizioni. Quando utilizzi il generatore di configurazioni delle metriche (MCG) per creare oggetti JSON di configurazione delle metriche, le espressioni vengono scritte come stringhe leggibili che utilizzano la notazione con punti per accedere ai campi dell'origine dati (ad esempio, vehicle_speed.speed_value) e applicare un'ampia gamma di operazioni. MCG traduce queste stringhe in una struttura ad albero ottimizzata, analoga a un albero di sintassi astratta (AST), per una valutazione on-device efficiente nel messaggio protobuf MetricsConfig finale.

Operatori e funzioni

Le espressioni supportano il seguente insieme di operatori e funzioni:

• Aritmetica: supporta addizione, sottrazione (binaria e unaria), moltiplicazione, divisione, modulo e potenza.
• Logica: supporta AND, OR, NOT e XOR.
• Relazionale: supporta il controllo dell'uguaglianza e il confronto maggiore di e minore di.
• Elenco: verifica se un elenco contiene o meno un valore specifico.
• Timestamp: restituisce il timestamp al momento della valutazione in microsecondi. Il tipo di orologio può essere l'orologio in tempo reale, il tempo monotono dall'avvio (incluso il tempo di sospensione) o il tempo monotono dall'avvio o dall'ultimo ripristino.
• Valore assoluto: restituisce il valore assoluto di un numero.
• Arrotondamento: arrotonda al numero intero più vicino (round), restituisce il numero intero più grande minore o uguale a un numero (floor) oppure restituisce il numero intero più piccolo maggiore o uguale a un numero (ceil).

Ecco un'espressione di esempio che legge da due origini dati e restituisce true se la velocità del veicolo supera i 100 km/h e non è presente alcun avviso sulla pressione dei pneumatici:

(vehicle_speed.speed_value * 3.6) > 100 && tire_pressure.warning == false

Controlla il flusso di esecuzione con i trigger

I trigger sono gli orchestratori di una configurazione delle metriche; controllano quando i dati vengono elaborati e quando vengono generati i report. Ogni trigger deve avere un nome univoco.

Esistono tre tipi di trigger:

• Trigger di dati: si attivano quando un'origine dati con una connessione di sottoscrizione pubblica un nuovo messaggio (dopo il sottocampionamento, se configurato).
• Trigger periodici: si attivano a un intervallo di tempo fisso.
• Trigger condizionali: si attivano quando viene soddisfatta una condizione logica specificata.

Trigger condizionali

I trigger condizionali ascoltano altri trigger (dati, periodici o altri trigger condizionali) e, quando uno di questi trigger si attiva, valutano un'espressione. Il trigger condizionale si attiva solo se il risultato dell'espressione soddisfa una condizione specifica.

Puoi configurare un trigger condizionale in modo che si attivi in base a diversi tipi di condizioni:

• Valore: quando l'espressione restituisce true (o diverso da zero) o false (o zero).
• Fronte di salita: quando un'espressione booleana passa da false a true o un valore numerico aumenta.
• Fronte di discesa: quando un'espressione booleana passa da true a false o un valore numerico diminuisce.
• Al cambio: ogni volta che il risultato dell'espressione è diverso dal valore precedente.

Filtra le modifiche di stato rumorose

Per i trigger basati su edge o al cambio, puoi filtrare le modifiche di stato brevi o rumorose (glitch) richiedendo che la condizione rimanga nel nuovo stato per una durata minima prima che il trigger si attivi.

Ad esempio, puoi configurare un trigger in modo che si attivi solo se vehicle_speed > 100 diventa true e rimane true per almeno 5 secondi. In questo modo, il trigger non si attiva a causa di un picco momentaneo nella lettura della velocità. Puoi anche richiedere che tutti i valori visualizzati durante questa durata di attesa siano esattamente uguali.

Genera report sulle metriche

Dopo l'elaborazione dei dati, definisci come e quando vengono inseriti nei report.

I report vengono definiti utilizzando le configurazioni dei report sulle metriche, che utilizzano i generatori di messaggi per definire la struttura e il contenuto dell'output. Quando uno dei trigger del report si attiva, il generatore di messaggi valuta le assegnazioni dei campi per costruire il payload dei dati del report.

Ogni report generato è un'istanza di un messaggio Protobuf MetricsReport che racchiude l'output del generatore di messaggi in un campo payload e aggiunge metadati. Il servizio di telemetria aggiunge automaticamente i seguenti metadati a ogni MetricsReport:

• Un identificatore univoco universale (UUID) per il report
• Un numero di report sequenziale, che aumenta per ogni report generato da questa configurazione di report
• Il timestamp relativo alla data e all'ora di generazione del report
• Il motivo della generazione (ad esempio, attivato da una regola o generato all'arresto)
• L'UUID e la versione della configurazione delle metriche che ha generato il report
• Il nome della configurazione del report sulle metriche

Controllo della generazione dei report

Sebbene i report vengano in genere generati in risposta ai trigger, puoi anche configurarli in modo che vengano generati in momenti specifici del ciclo di vita della configurazione delle metriche:

• Report sull'attivazione: se abilitato, il sistema genera un report iniziale immediatamente quando la configurazione delle metriche viene attivata.
• Report finale: se abilitato, il sistema genera un report finale quando la raccolta dei dati viene messa in pausa o interrotta oppure quando il servizio di telemetria viene arrestato. Questo report contiene i dati aggregati fino a quel momento, contribuendo a garantire che nessun dato venga perso alla fine di una sessione.

Gestisci il ciclo di vita della raccolta dei dati

Per impostazione predefinita, una configurazione delle metriche inizia a raccogliere ed elaborare i dati non appena viene attivata da un client e continua fino a quando non viene disattivata dal client. Tuttavia, puoi controllare questo ciclo di vita in modo più granulare definendo i trigger che avviano o interrompono la raccolta dei dati o la configurazione delle metriche:

• Trigger di avvio: se definito, la raccolta dei dati inizia solo quando questo trigger si attiva. Se la raccolta è stata messa in pausa da un trigger di arresto, il trigger di avvio la riprende.
• Trigger di arresto: se definito, questo trigger mette in pausa la raccolta dei dati. L'aggregazione e la generazione di report si interrompono fino a quando il trigger di avvio non si attiva di nuovo.
• Trigger di disattivazione: questo trigger disattiva la configurazione delle metriche nello stesso modo in cui lo farebbe una chiamata deactivate_metrics_config dal client.

Ad esempio, puoi definire un trigger condizionale che si attiva quando vehicle_state passa a DRIVING come trigger di avvio e un altro che si attiva quando vehicle_state passa a PARKED come trigger di arresto. In questo modo, i dati vengono raccolti solo quando il veicolo è in movimento.