Raggruppamento

Che cos'è il batching?

Il batching si riferisce al buffering degli eventi dei sensori in un hub di sensori e/o in una coda FIFO hardware prima di segnalarli tramite l'HAL Sensors. In questa pagina, la posizione in cui gli eventi del sensore vengono memorizzati nella memoria intermedia (hub del sensore e/o FIFO hardware) è indicata come "FIFO". Quando il raggruppamento degli eventi del sensore non è attivo, gli eventi del sensore vengono segnalati immediatamente all'HAL Sensors, se disponibili.

Nota: il raggruppamento e la funzione batch() dell'HAL di Sensors sono concetti distinti, anche se correlati. Il batching si riferisce al buffering degli eventi del sensore per risparmiare energia. La funzione batch() viene utilizzata per configurare la frequenza di generazione dei report di un sensore e l'intervallo di tempo massimo tra la generazione di un evento e la sua registrazione nell'HAL Sensors.

Il raggruppamento può consentire un risparmio energetico significativo riattivando l'AP (Application Processor) principale, che esegue Android, solo quando molti eventi del sensore sono pronti per essere elaborati, anziché riattivarlo per ogni singolo evento. Il potenziale risparmio energetico è direttamente correlato al numero di eventi che l'hub di sensori e/o FIFO può mettere in coda: il potenziale di risparmio energetico è maggiore se è possibile raggruppare più eventi. Il raggruppamento sfrutta l'utilizzo di memoria a basso consumo per ridurre il numero di risvegli degli AP ad alta potenza.

Il raggruppamento può avvenire solo quando un sensore dispone di una coda FIFO hardware e/o può immagazzinare gli eventi in un hub di sensori. In entrambi i casi, il sensore deve segnalare il numero massimo di eventi che possono essere raggruppati contemporaneamente tramite SensorInfo.fifoMaxEventCount.

Se un sensore ha spazio riservato all'interno di una coda FIFO, deve segnalare il numero di eventi riservati tramite SensorInfo.fifoReservedEventCount. Se la coda FIFO è dedicata al sensore, SensorInfo.fifoReservedEventCount è la dimensione della coda FIFO. Se la coda FIFO è condivisa tra più sensori, questo valore può essere zero. Un caso d'uso comune è consentire a un sensore di utilizzare l'intero FIFO se è l'unico sensore attivo. Se sono attivi più sensori, a ciascun sensore viene garantito lo spazio per almeno SensorInfo.fifoReservedEventCount eventi nella coda FIFO. Se viene utilizzato un hub di sensori, la garanzia può essere applicata tramite software.

Gli eventi dei sensori vengono raggruppati nelle seguenti situazioni:

• L'attuale latenza massima di generazione dei report del sensore è maggiore di zero, il che significa che gli eventi del sensore possono essere ritardati fino alla latenza massima di generazione dei report prima di essere registrati tramite l'HAL.
• L'AP è in modalità di sospensione e il sensore non è un sensore di risveglio. In questo caso, gli eventi non devono riattivare l'AP e devono essere memorizzati fino al risveglio dell'AP.

Se un sensore non supporta il raggruppamento e l'AP è in modalità di sospensione, solo gli eventi di risveglio del sensore vengono registrati nell'AP e gli eventi non di risveglio non devono essere registrati nell'AP.

Parametri di raggruppamento

I due parametri che regolano il comportamento del raggruppamento sono sampling_period_ns e max_report_latency_ns. sampling_period_ns determina la frequenza con cui viene generato un nuovo evento del sensore e max_report_latency_ns determina il tempo che deve trascorrere prima che l'evento venga segnalato all'HAL Sensors.

sampling_period_ns

Il significato del parametro sampling_period_ns dipende dalla modalità di generazione di report del sensore specificato:

• Continuo: sampling_period_ns è la frequenza di campionamento, ovvero la frequenza con cui vengono generati gli eventi.
• Al cambio: sampling_period_ns limita la frequenza di campionamento degli eventi, il che significa che gli eventi vengono generati non più velocemente di ogni sampling_period_ns nanosecondo. I periodi possono essere più lunghi di sampling_period_ns se non viene generato alcun evento e i valori misurati non cambiano per lunghi periodi. Per maggiori dettagli, vedi la modalità di generazione di report on-change.
• One-shot: sampling_period_ns viene ignorato. Non ha alcun effetto.
• Speciale: per informazioni dettagliate su come viene utilizzato sampling_period_ns per i sensori speciali, consulta Tipi di sensori.

Per ulteriori informazioni sull'impatto di sampling_period_ns nelle diverse modalità, consulta Modalità di generazione dei report.

Per i sensori continui e al variare:

• Se sampling_period_ns è inferiore a SensorInfo.minDelay, l'implementazione HAL deve impostarlo silenziosamente su max(SensorInfo.minDelay, 1ms). Android non supporta la generazione di eventi a una frequenza superiore a 1000 Hz.
• Se sampling_period_ns è maggiore di SensorInfo.maxDelay, l'implementazione HAL deve troncarlo silenziosamente a SensorInfo.maxDelay.

A volte i sensori fisici hanno limitazioni relative alla frequenza con cui possono essere eseguiti e alla precisione dei loro orologi. Per tenerne conto, la frequenza di campionamento effettiva può essere diversa da quella richiesta, purché soddisfi i requisiti riportati nella tabella seguente.

Se la frequenza richiesta è	La frequenza effettiva deve essere
inferiore alla frequenza minima (<1/maxDelay)	tra il 90% e il 110% della frequenza minima
tra la frequenza minima e quella massima	tra il 90% e il 220% della frequenza richiesta
superiore alla frequenza massima (>1/minDelay)	tra il 90% e il 110% della frequenza massima e inferiore a 1100 Hz

Nota: questo contratto è valido solo a livello di HAL, che ha sempre un unico client. A livello di SDK, le applicazioni potrebbero ricevere tariffe diverse a causa del multiplexing nel framework. Per maggiori dettagli, consulta Framework.

max_report_latency_ns

max_report_latency_ns imposta il tempo massimo in nanosecondi, in base al quale gli eventi possono essere ritardati e archiviati nella coda FIFO hardware prima di essere registrati tramite l'HAL mentre l'AP è attivo.

Un valore pari a zero indica che gli eventi devono essere registrati non appena vengono misurati, ignorando del tutto la coda FIFO o svuotandola non appena è presente un evento del sensore.

Ad esempio, un accelerometro attivato a 50 Hz con max_report_latency_ns=0 attiverà le interruzioni 50 volte al secondo quando l'AP è attivo.

Quando max_report_latency_ns>0, non è necessario registrare gli eventi del sensore non appena vengono rilevati. Possono essere memorizzati temporaneamente in FIFO e registrati in batch, a condizione che nessun evento sia in ritardo di più di max_report_latency_ns nanosecondi. Ciò significa che tutti gli eventi dal batch precedente vengono registrati e restituiti contemporaneamente. In questo modo si riduce la quantità di interruzioni inviate all'AP e l'AP può passare a una modalità di risparmio energetico (inattiva) mentre il sensore acquisisce e raggruppa i dati.

A ogni evento è associato un timestamp. Il ritardo nell'ora in cui viene registrato un evento non influisce sul timestamp dell'evento. Il timestamp deve essere accurato e corrispondere all'ora in cui si è verificato l'evento, non all'ora in cui è stato segnalato.

Consentire la memorizzazione temporanea degli eventi del sensore nella coda FIFO non modifica il comportamento dell'invio di eventi all'HAL; gli eventi di sensori diversi possono essere interlacciati e tutti gli eventi dello stesso sensore sono ordinati in base al tempo.

Eventi di risveglio e non risveglio

Gli eventi dei sensori dei sensori di attivazione devono essere memorizzati in uno o più FIFO di attivazione. Un design comune è avere un singolo FIFO di risveglio condiviso di grandi dimensioni in cui gli eventi di tutti i sensori di risveglio sono interlacciati. In alternativa, puoi avere una coda FIFO di risveglio per sensore o avere FIFO dedicate per determinati sensori di risveglio e una FIFO condivisa per il resto dei sensori di risveglio.

Analogamente, gli eventi dei sensori dei sensori non di risveglio devono essere archiviati in una o più code FIFO non di risveglio.

In tutti i casi, gli eventi del sensore di attivazione e quelli del sensore non di attivazione non possono essere interlacciati nella stessa coda FIFO. Gli eventi di risveglio devono essere archiviati in una coda FIFO di risveglio e gli eventi non di risveglio devono essere archiviati in una coda FIFO non di risveglio.

Per la coda FIFO di risveglio, il design FIFO singolo di grandi dimensioni e condiviso offre i migliori vantaggi in termini di potenza. Per la coda FIFO senza risveglio, la singola coda FIFO condivisa di grandi dimensioni e diversi piccoli design di code FIFO riservate hanno caratteristiche di potenza simili. Per altri suggerimenti su come configurare ogni coda FIFO, consulta la sezione Priorità di allocazione FIFO.

Comportamento al di fuori della modalità di sospensione

Quando l'AP è attivo (non in modalità di sospensione), gli eventi vengono memorizzati temporaneamente nelle code FIFO, a condizione che non siano in ritardo di più di max_report_latency.

Finché l'AP non entra in modalità di sospensione, nessun evento verrà eliminato o perso. Se le code FIFO interne si riempiono prima del termine del periodo max_report_latency, gli eventi vengono registrati in quel momento per garantire che non venga perso alcun evento.

Se più sensori condividono la stessa coda FIFO e il max_report_latency di uno di essi scade, tutti gli eventi della coda FIFO vengono registrati, anche se il max_report_latency degli altri sensori non è ancora scaduto. In questo modo, si riduce il numero di volte in cui vengono registrati i batch di eventi. Quando è necessario segnalare un evento, vengono registrati tutti gli eventi di tutti i sensori.

Ad esempio, se sono attivati i seguenti sensori:

• accelerometro raggruppato con max_report_latency = 20 s
• Giroscopio raggruppato con max_report_latency = 5 s

I batch dell'accelerometro vengono registrati contemporaneamente ai batch del giroscopio (ogni 5 secondi), anche se l'accelerometro e il giroscopio non condividono la stessa coda FIFO.

Comportamento in modalità sospensione

Il raggruppamento è particolarmente utile per raccogliere i dati dei sensori in background senza mantenere attivo l'AP. Poiché i driver dei sensori e l'implementazione HAL non sono autorizzati a mantenere un blocco di attivazione*, l'AP può entrare in modalità di sospensione anche durante la raccolta dei dati dei sensori.

Il comportamento dei sensori quando l'AP è in sospensione dipende dal fatto che il sensore sia un sensore di risveglio. Per maggiori dettagli, vedi Sensori di riattivazione.

Quando una coda FIFO non di risveglio si riempie, deve essere riavvolta e comportarsi come un buffer circolare, sovrascrivendo gli eventi precedenti con i nuovi eventi che sostituiscono quelli vecchi. max_report_latency non influisce sulle code FIFO non di risveglio in modalità sospensione.

Quando una coda FIFO di risveglio si riempie o quando scade il max_report_latency di uno dei sensori di risveglio, l'hardware deve riattivare l'AP e registrare i dati.

In entrambi i casi (risveglio e non risveglio), non appena l'AP esce dalla modalità di sospensione, viene prodotto un batch con i contenuti di tutti i FIFO, anche se non sono ancora trascorsi max_report_latency di alcuni sensori. In questo modo, si minimizza il rischio che l'AP debba risvegliarsi di nuovo poco dopo il ritorno alla modalità di sospensione e, di conseguenza, si riduce al minimo il consumo energetico.

*Un'eccezione notevole per i driver che non sono autorizzati a mantenere un blocco di attivazione si verifica quando viene attivato un sensore di attivazione con la modalità di generazione di report continua con max_report_latency < 1 secondo. In questo caso, il driver può mantenere un blocco di attivazione perché l'AP non ha il tempo di entrare in modalità di sospensione, in quanto verrebbe riattivato da un evento di attivazione prima di raggiungere la modalità di sospensione.

Precauzioni per l'organizzazione in batch dei sensori di riattivazione

A seconda del dispositivo, potrebbero essere necessari alcuni millisecondi prima che l'AP esca completamente dalla modalità di sospensione e inizi a svuotare la coda FIFO. È necessario allocare un margine sufficiente nella coda FIFO per consentire al dispositivo di uscire dalla modalità di sospensione senza che la coda FIFO di risveglio trabocchi. Nessun evento deve andare perso e il valore max_report_latency deve essere rispettato.

Precauzioni per l'aggregazione di sensori non di risveglio al cambiamento

I sensori on-change generano eventi solo quando il valore che misurano è in fase di variazione. Se il valore misurato cambia mentre l'AP è in modalità sospensione, le applicazioni si aspettano di ricevere un evento non appena l'AP si riattiva. Per questo motivo, il raggruppamento degli eventi del sensore di variazione non risveglio deve essere eseguito con attenzione se il sensore condivide la sua coda FIFO con altri sensori. L'ultimo evento generato da ogni sensore on-change deve essere sempre salvato al di fuori della coda FIFO condivisa in modo che non possa mai essere sovrascritto da altri eventi. Quando l'AP si riattiva, dopo che tutti gli eventi della coda FIFO sono stati registrati, deve essere registrato l'ultimo evento del sensore on-change.

Ecco una situazione da evitare:

1. Un'applicazione si registra al contatore dei passi senza risveglio (al cambio) e al sensore di accelerazione senza risveglio (continuo), entrambi che condividono la stessa coda FIFO.
2. L'applicazione riceve un evento contatore dei passi step_count=1000 stepscode>.
3. L'AP entra in stato di sospensione.
4. L'utente fa 20 passi, causando l'interlacciamento degli eventi del contatore dei passi e dell'accelerometro, l'ultimo evento del contatore dei passi è step_count = 1020 steps.
5. L'utente non si muove per molto tempo, causando un continuo accumulo di eventi dell'accelerometro nella coda FIFO, fino a sovrascrivere tutti gli eventi step_count nella coda FIFO condivisa.
6. L'AP si riattiva e tutti gli eventi della coda FIFO vengono inviati all'applicazione.
7. L'applicazione riceve solo eventi dell'accelerometro e pensa che l'utente non abbia camminato.

Salvando l'ultimo evento del contatore dei passi al di fuori della coda FIFO, l'HAL può segnalare questo evento quando l'AP si riattiva, anche se tutti gli altri eventi del contatore dei passi sono stati sovrascritti dagli eventi dell'accelerometro. In questo modo, l'applicazione ricevestep_count = 1020 steps quando l'AP si riattiva.

Implementare il raggruppamento

Per risparmiare energia, il raggruppamento deve essere implementato senza l'aiuto dell'AP e deve essere consentito all'AP di sospendersi durante il raggruppamento.

Se l'aggregazione viene eseguita in un hub di sensori, il consumo di energia dell'hub deve essere ridotto al minimo.

La latenza massima dei report può essere modificata in qualsiasi momento, in particolare quando il sensore specificato è già abilitato. Ciò non dovrebbe comportare la perdita di eventi.

Priorità di allocazione FIFO

Su piattaforme in cui la dimensione del buffer FIFO hardware e/o dell'hub sensore è limitata, i progettisti di sistema potrebbero dover scegliere la quantità di FIFO da riservare per ogni sensore. Per aiutarti in questa scelta, di seguito è riportato un elenco di possibili applicazioni quando il raggruppamento viene implementato sui diversi sensori.

Valore elevato: rilevamento della posizione tramite triangolazione a basso consumo per i pedoni

Tempo di raggruppamento target: da 1 a 10 minuti

Sensori da raggruppare:

• Rilevamento dei passaggi per riattivare il dispositivo
• Vettore di rotazione del gioco di attivazione a 5 Hz
• Barometro risveglio a 5 Hz
• Magnetometro non calibrato per sveglia a 5 Hz

L'aggregazione di questi dati consente di eseguire il calcolo approssimativo della posizione dei pedoni lasciando in sospensione il punto di accesso.

Valore alto: riconoscimento di attività/gesti intermittenti a media potenza

Tempo di raggruppamento target: 3 secondi

Sensori da includere nel batch: accelerometro non di risveglio a 50 Hz

L'aggregazione di questi dati consente di riconoscere periodicamente attività e gesti arbitrari senza dover mantenere attivo l'AP durante la raccolta dei dati.

Valore medio: riconoscimento di attività/gesti continui di media potenza

Tempo di raggruppamento target: da 1 a 3 minuti

Sensori da includere nel batch: accelerometro di attivazione a 50 Hz

L'aggregazione di questi dati consente di riconoscere continuamente attività e gesti arbitrari senza dover mantenere attivo l'AP durante la raccolta dei dati.

Valore medio-alto: riduzione del carico delle interruzioni

Tempo di raggruppamento target: < 1 secondo

Sensori da raggruppare: qualsiasi sensore ad alta frequenza, in genere non di risveglio.

Se il giroscopio è impostato su 240 Hz, anche raggruppare solo 10 eventi del giroscopio può ridurre il numero di interruzioni da 240/secondo a 24/secondo.

Valore medio: raccolta continua di dati a bassa frequenza

Tempo di raggruppamento target: da 1 a 10 minuti

Sensori da raggruppare:

• Barometro risveglio a 1 Hz
• Sensore di umidità di riattivazione a 1 Hz
• Altri sensori di attivazione a bassa frequenza con frequenze simili

Consente di creare applicazioni di monitoraggio a basso consumo.

Valore medio-basso: raccolta continua con tutti i sensori

Tempo di raggruppamento target: da 1 a 10 minuti

Sensori da includere nel batch: tutti i sensori di attivazione, ad alta frequenza

Consente la raccolta completa dei dati dei sensori lasciando l'AP in modalità sospensione. Valuta questa opzione solo se lo spazio FIFO non è un problema.