Batching

Was ist Batching?

Beim Batching werden Sensorereignisse in einem Sensorhub und/oder einem Hardware-FIFO zwischengespeichert, bevor sie über die Sensors HAL gemeldet werden. Der Speicherort, an dem Sensorereignisse zwischengespeichert werden (Sensorhub und/oder Hardware-FIFO), wird auf dieser Seite als „FIFO“ bezeichnet. Wenn die Batchverarbeitung von Sensorereignissen nicht aktiv ist, werden Sensorereignisse sofort an die Sensors HAL gemeldet, sofern verfügbar.

Durch Batching können Sie erheblich Energie sparen, da der Haupt-Anwendungsprozessor (AP), auf dem Android ausgeführt wird, nur dann aktiviert wird, wenn viele Sensorereignisse zur Verarbeitung bereit sind, anstatt für jedes einzelne Ereignis. Die möglichen Energieeinsparungen hängen direkt mit der Anzahl der Ereignisse zusammen, die der Sensorhub und/oder der FIFO-Puffer speichern können. Je mehr Ereignisse in einem Batch zusammengefasst werden können, desto größer ist das Einsparpotenzial. Beim Batching wird der Einsatz von Low-Power-Speicher genutzt, um die Anzahl der Weckvorgänge von Hochleistungs-Zugangspunkten zu reduzieren.

Batching ist nur möglich, wenn ein Sensor einen Hardware-FIFO hat und/oder Ereignisse in einem Sensorhub puffern kann. In beiden Fällen muss der Sensor die maximale Anzahl von Ereignissen melden, die über SensorInfo.fifoMaxEventCount gleichzeitig in einem Batch gesendet werden können.

Wenn ein Sensor innerhalb eines FIFO-Puffers Speicherplatz reserviert hat, muss er die Anzahl der reservierten Ereignisse über SensorInfo.fifoReservedEventCount melden. Wenn der FIFO dem Sensor zugewiesen ist, ist SensorInfo.fifoReservedEventCount die Größe des FIFO. Wenn der FIFO von mehreren Sensoren gemeinsam genutzt wird, kann dieser Wert null sein. Ein häufiger Anwendungsfall ist, dass einem Sensor der gesamte FIFO zur Verfügung gestellt wird, wenn er der einzige aktive Sensor ist. Wenn mehrere Sensoren aktiv sind, ist für jeden Sensor Platz für mindestens SensorInfo.fifoReservedEventCount Ereignisse im FIFO-Puffer verfügbar. Wenn ein Sensorhub verwendet wird, kann die Garantie durch Software erzwungen werden.

Sensorereignisse werden in den folgenden Fällen in Batches zusammengefasst:

  • Die aktuelle maximale Berichtslatenz des Sensors ist größer als null. Das bedeutet, dass Sensorereignisse bis zu der maximalen Berichtslatenz verzögert werden können, bevor sie über die HAL gemeldet werden.
  • Der ZP befindet sich im Ruhemodus und der Sensor ist kein Wecksensor. In diesem Fall dürfen Ereignisse den ZP nicht wecken und müssen gespeichert werden, bis der ZP aufwacht.

Wenn ein Sensor das Batching nicht unterstützt und der Zugangspunkt im Ruhemodus ist, werden nur Wecksensorereignisse an den Zugangspunkt gesendet. Nicht-Wecksensorereignisse dürfen nicht an den Zugangspunkt gesendet werden.

Parameter für die Batchverarbeitung

Die beiden Parameter, die das Batching-Verhalten steuern, sind sampling_period_ns und max_report_latency_ns. Mit sampling_period_ns wird festgelegt, wie oft ein neues Sensorereignis generiert wird, und mit max_report_latency_ns, wie lange es dauert, bis das Ereignis an die Sensors HAL gemeldet werden muss.

sampling_period_ns

Die Bedeutung des Parameters sampling_period_ns hängt vom Berichtsmodus des angegebenen Sensors ab:

  • Kontinuierlich: sampling_period_ns ist die Abtastrate, also die Rate, mit der Ereignisse generiert werden.
  • Bei Änderung: sampling_period_ns schränkt die Stichprobenerhebungsrate von Ereignissen ein. Das bedeutet, dass Ereignisse nicht schneller als alle sampling_period_ns Nanosekunden generiert werden. Zeiträume können länger als sampling_period_ns sein, wenn kein Ereignis generiert wird und sich die gemessenen Werte über einen längeren Zeitraum nicht ändern. Weitere Informationen finden Sie im Hilfeartikel zum Berichtsmodus Bei Änderung.
  • Einmalig: sampling_period_ns wird ignoriert. Es hat keine Auswirkungen.
  • Speziell: Weitere Informationen zur Verwendung von sampling_period_ns für spezielle Sensoren finden Sie unter Sensortypen.

Weitere Informationen zu den Auswirkungen von sampling_period_ns in den verschiedenen Modi finden Sie unter Mögliche Berichtsmodi.

Für kontinuierliche und bei Änderungen ausgelöste Sensoren:

  • Wenn sampling_period_ns kleiner als SensorInfo.minDelay ist, muss die HAL-Implementierung sie geräuschlos auf max(SensorInfo.minDelay, 1ms) begrenzen. Android unterstützt die Generierung von Ereignissen mit mehr als 1.000 Hz nicht.
  • Wenn sampling_period_ns größer als SensorInfo.maxDelay ist, muss die HAL-Implementierung ihn geräuschlos auf SensorInfo.maxDelay abschneiden.

Bei physischen Sensoren gibt es manchmal Einschränkungen bei der Taktfrequenz und der Genauigkeit der Uhren. Die tatsächliche Stichprobenrate kann daher von der angeforderten Rate abweichen, solange sie die Anforderungen in der folgenden Tabelle erfüllt.

Wenn die angeforderte Häufigkeit

Die tatsächliche Häufigkeit muss dann

unter der Mindesthäufigkeit (< 1/maxDelay)

zwischen 90% und 110% der Mindesthäufigkeit

zwischen Mindest- und Höchsthäufigkeit

zwischen 90% und 220% der angeforderten Häufigkeit

über der maximalen Frequenz (> 1/minDelay)

zwischen 90% und 110% der maximalen Frequenz und unter 1.100 Hz

max_report_latency_ns

Mit max_report_latency_ns wird die maximale Zeit in Nanosekunden festgelegt, um die Ereignisse verzögert und im Hardware-FIFO gespeichert werden können, bevor sie über die HAL gemeldet werden, während der ZP aktiv ist.

Ein Wert von null bedeutet, dass die Ereignisse sobald sie gemessen werden, gemeldet werden müssen. Dabei wird der FIFO entweder komplett übersprungen oder er wird geleert, sobald ein Ereignis vom Sensor vorhanden ist.

Ein Beschleunigungsmesser, der mit max_report_latency_ns=0 auf 50 Hz aktiviert ist, löst beispielsweise 50 Mal pro Sekunde Unterbrechungen aus, wenn der ZP aktiv ist.

Bei max_report_latency_ns>0 müssen Sensorereignisse nicht sofort nach der Erkennung gemeldet werden. Sie können vorübergehend im FIFO-Verfahren gespeichert und in Batches erfasst werden, solange kein Ereignis um mehr als max_report_latency_ns Nanosekunden verzögert wird. Das bedeutet, dass alle Ereignisse seit dem vorherigen Batch auf einmal aufgezeichnet und zurückgegeben werden. Dadurch wird die Anzahl der an den Zugangspunkt gesendeten Unterbrechungen reduziert und der Zugangspunkt kann in einen niedrigeren Energiesparmodus (Inaktivität) wechseln, während der Sensor Daten erfasst und bündelt.

Jedem Ereignis ist ein Zeitstempel zugeordnet. Eine Verzögerung bei der Meldung eines Ereignisses hat keinen Einfluss auf den Zeitstempel des Ereignisses. Der Zeitstempel muss korrekt sein und dem Zeitpunkt entsprechen, zu dem das Ereignis tatsächlich aufgetreten ist, nicht dem Zeitpunkt, zu dem es gemeldet wurde.

Wenn Sensorereignisse vorübergehend im FIFO gespeichert werden dürfen, ändert sich das Verhalten beim Senden von Ereignissen an die HAL nicht. Ereignisse von verschiedenen Sensoren können überlagert werden und alle Ereignisse vom selben Sensor sind zeitgeordnet.

Weck- und Nicht-Weck-Ereignisse

Sensorereignisse von Wecksensoren müssen in einem oder mehreren Weck-FIFOs gespeichert werden. Ein gängiges Design ist ein einzelner, großer, gemeinsam genutzter Wake-up-FIFO, in dem Ereignisse von allen Wake-up-Sensoren interleaved werden. Alternativ können Sie einen Wake-up-FIFO pro Sensor oder spezielle FIFOs für bestimmte Wake-up-Sensoren und einen freigegebenen FIFO für die übrigen Wake-up-Sensoren verwenden.

Ebenso müssen Sensorereignisse von Nicht-Wecksensoren in einem oder mehreren Nicht-Weck-FIFOs gespeichert werden.

In jedem Fall können Wecksensorereignisse und Nicht-Wecksensorereignisse nicht in derselben FIFO-Warteschlange interleaved werden. Weck-Ereignisse müssen in einem Weck-FIFO und Nicht-Weck-Ereignisse in einem Nicht-Weck-FIFO gespeichert werden.

Für das Wake-up-FIFO bietet das einzelne, große, freigegebene FIFO-Design die besten Energievorteile. Bei der FIFO-Variante ohne Weckfunktion haben das einzelne große freigegebene FIFO und mehrere kleine reservierte FIFOs ähnliche Leistungsmerkmale. Weitere Vorschläge zur Konfiguration der einzelnen FIFOs finden Sie unter FIFO-Zuweisungspriorität.

Verhalten außerhalb des Ruhemodus

Wenn der ZP aktiv ist (nicht im Ruhemodus), werden Ereignisse vorübergehend in FIFOs gespeichert, solange sie nicht um mehr als max_report_latency verzögert werden.

Solange der ZP nicht in den Ruhemodus wechselt, werden keine Ereignisse verworfen oder verloren. Wenn die internen FIFOs vor Ablauf von max_report_latencygefüllt sind, werden die Ereignisse an diesem Punkt gemeldet, damit keine Ereignisse verloren gehen.

Wenn mehrere Sensoren denselben FIFO teilen und die max_report_latency eines davon abläuft, werden alle Ereignisse aus dem FIFO gemeldet, auch wenn die max_report_latency der anderen Sensoren noch nicht abgelaufen ist. So wird die Häufigkeit reduziert, mit der Ereignis-Batches gemeldet werden. Wenn ein Ereignis gemeldet werden muss, werden alle Ereignisse von allen Sensoren gemeldet.

Beispiel: Die folgenden Sensoren sind aktiviert:

  • Beschleunigungsmesser-Batch mit max_report_latency = 20 Sekunden
  • Gyroskop-Batch mit max_report_latency = 5 s

Die Beschleunigungsmesser-Batches werden gleichzeitig mit den Gyroskop-Batches (alle 5 Sekunden) erfasst, auch wenn der Beschleunigungsmesser und das Gyroskop nicht denselben FIFO teilen.

Verhalten im Ruhemodus

Das Batching ist besonders nützlich, um Sensordaten im Hintergrund zu erfassen, ohne den Zugangspunkt aktiv zu halten. Da die Sensortreiber und die HAL-Implementierung keinen Wakelock halten dürfen*, kann der AP in den Ruhemodus wechseln, auch wenn Sensordaten erfasst werden.

Das Verhalten der Sensoren, während der Zugangspunkt inaktiv ist, hängt davon ab, ob es sich um einen Wecksensor handelt. Weitere Informationen finden Sie unter Wecksensoren.

Wenn ein FIFO ohne Weckfunktion voll ist, muss er sich umkehren und sich wie ein zyklischer Puffer verhalten, wobei ältere Ereignisse durch neue Ereignisse überschrieben werden. max_report_latency hat keine Auswirkungen auf FIFOs ohne Weckfunktion im Ruhemodus.

Wenn ein Weck-FIFO voll ist oder die max_report_latency eines der Wecksensoren abläuft, muss die Hardware den ZP wecken und die Daten melden.

In beiden Fällen (Aufwachen und Nicht-Aufwachen) wird, sobald der ZP aus dem Ruhemodus herauskommt, ein Batch mit dem Inhalt aller FIFOs erstellt, auch wenn max_report_latency einiger Sensoren noch nicht abgelaufen ist. So wird das Risiko minimiert, dass der ZP kurz nach dem Wechsel in den Ruhemodus wieder aktiviert werden muss, und damit auch der Energieverbrauch.

*Eine wichtige Ausnahme für Treiber, die keine Wake-Locks halten dürfen, ist, wenn ein Wecksensor mit dem Modus für kontinuierliche Berichte aktiviert ist und max_report_latency < 1 Sekunde beträgt. In diesem Fall kann der Treiber eine Wake-Lock halten, da der ZP nicht genügend Zeit hat, in den Ruhemodus zu wechseln, da er durch ein Weck-Ereignis geweckt wird, bevor er den Ruhemodus erreicht.

Vorsichtsmaßnahmen beim Batching von Wecksensoren

Je nach Gerät kann es einige Millisekunden dauern, bis der ZP vollständig aus dem Ruhemodus herauskommt und mit dem Leeren des FIFO beginnt. Im FIFO muss genügend Pufferplatz zugewiesen werden, damit das Gerät aus dem Ruhemodus herauskommen kann, ohne dass der Wake-up-FIFO überläuft. Es dürfen keine Ereignisse verloren gehen und die max_report_latency muss eingehalten werden.

Vorsichtsmaßnahmen beim Batching von Sensoren, die nicht bei Änderungen aufwachen

On-change-Sensoren generieren nur Ereignisse, wenn sich der gemessene Wert ändert. Wenn sich der gemessene Wert ändert, während sich der ZP im Ruhemodus befindet, erwarten Anwendungen, dass sie ein Ereignis erhalten, sobald der ZP wieder aktiv ist. Aus diesem Grund muss das Batching von On-Change-Sensorereignissen ohne Weckfunktion sorgfältig durchgeführt werden, wenn der Sensor seinen FIFO mit anderen Sensoren teilt. Das letzte Ereignis, das von jedem Sensor bei einer Änderung generiert wird, muss immer außerhalb des freigegebenen FIFO gespeichert werden, damit es nicht von anderen Ereignissen überschrieben werden kann. Wenn der ZP aufwacht, muss nach dem Melden aller Ereignisse aus dem FIFO das letzte On-Change-Sensorereignis gemeldet werden.

Hier ist eine Situation, die Sie vermeiden sollten:

  1. Eine Anwendung registriert sich beim Schrittzähler ohne Weckfunktion (bei Änderung) und beim Beschleunigungsmesser ohne Weckfunktion (kontinuierlich), die beide denselben FIFO teilen.
  2. Die Anwendung empfängt ein Schrittzählerereignis step_count=1000 stepscode>.
  3. Der ZP wird angehalten.
  4. Der Nutzer geht 20 Schritte, wodurch die Ereignisse des Schrittzählers und des Beschleunigungsmessers überlappen. Das letzte Ereignis des Schrittzählers ist step_count = 1020 steps.
  5. Der Nutzer bewegt sich lange Zeit nicht, wodurch sich Beschleunigungsmesserereignisse im FIFO ansammeln und schließlich alle step_count-Ereignisse im freigegebenen FIFO überschrieben werden.
  6. Der ZP wird aktiviert und alle Ereignisse aus dem FIFO werden an die Anwendung gesendet.
  7. Die Anwendung empfängt nur Beschleunigungsmesserereignisse und geht davon aus, dass der Nutzer nicht gelaufen ist.

Durch das Speichern des letzten Schrittzähler-Ereignisses außerhalb des FIFO kann das HAL dieses Ereignis melden, wenn der AP aufwacht, auch wenn alle anderen Schrittzähler-Ereignisse von Beschleunigungsmesser-Ereignissen überschrieben wurden. So erhält die Anwendung step_count = 1020 steps, wenn der ZP aktiviert wird.

Batchverarbeitung implementieren

Um Energie zu sparen, muss die Batchverarbeitung ohne Zuhilfenahme des ZP implementiert werden und der ZP darf während der Batchverarbeitung in den Ruhemodus versetzt werden.

Wenn die Batchverarbeitung in einem Sensorhub ausgeführt wird, sollte der Stromverbrauch des Sensorhubs minimiert werden.

Die maximale Berichtslatenz kann jederzeit geändert werden, insbesondere wenn der angegebene Sensor bereits aktiviert ist. Dies sollte nicht zu Datenverlusten führen.

FIFO-Zuweisungspriorität

Auf Plattformen, auf denen die Hardware-FIFO- und/oder Sensorhub-Puffergröße begrenzt ist, müssen Systementwickler möglicherweise festlegen, wie viel FIFO für jeden Sensor reserviert werden soll. Zur Unterstützung bei dieser Entscheidung finden Sie hier eine Liste möglicher Anwendungen, wenn die Batchverarbeitung auf den verschiedenen Sensoren implementiert ist.

Hohe Wertschätzung: Energieeffizientes Dead Reckoning für Fußgänger

Ziel-Batch-Zeit: 1 bis 10 Minuten

Sensoren für Batch:

  • Schritterkennung für Weckfunktion
  • Weckspiel-Rotationsvektor bei 5 Hz
  • Weckbarometer bei 5 Hz
  • Nicht kalibrierten Magnetometer bei 5 Hz aktivieren

Durch das Batchen dieser Daten kann die Standortbestimmung für Fußgänger ausgeführt werden, während der Zugangspunkt in den Ruhemodus versetzt wird.

Hoch: Erkennung von Aktivitäten/Gesten mit mittlerer Leistung, die nur zeitweise aktiv sind

Ziel-Batchzeit: 3 Sekunden

Zu gruppiernden Sensoren: Beschleunigungsmesser ohne Weckfunktion bei 50 Hz

Durch das Batching dieser Daten können beliebige Aktivitäten und Gesten regelmäßig erkannt werden, ohne dass der Zugangspunkt während der Datenerhebung aktiv bleiben muss.

Mittlerer Wert: Mittlere Leistung bei kontinuierlicher Aktivitäts-/Gestenererkennung

Ziel-Batch-Zeit: 1 bis 3 Minuten

Zu gruppiernden Sensoren: Weck-Beschleunigungsmesser bei 50 Hz

Durch das Batching dieser Daten können beliebige Aktivitäten und Gesten kontinuierlich erkannt werden, ohne dass der Zugangspunkt während der Datenerhebung aktiv bleiben muss.

Mittelhoher Wert: Unterbrechungslast reduzieren

Ziel-Batch-Zeit: < 1 Sekunde

Sensoren für Batch: Alle Hochfrequenzsensoren, in der Regel ohne Weckfunktion.

Wenn das Gyroskop auf 240 Hz eingestellt ist, kann die Anzahl der Unterbrechungen von 240 pro Sekunde auf 24 pro Sekunde reduziert werden, wenn Sie auch nur 10 Gyroskopereignisse gruppieren.

Mittlerer Wert: kontinuierliche Datenerhebung mit niedriger Frequenz

Ziel-Batch-Zeit: 1 bis 10 Minuten

Sensoren für Batch:

  • Weckbarometer bei 1 Hz
  • Luftfeuchtigkeitssensor mit 1 Hz aktivieren
  • Andere Sensoren mit niedriger Aktivierungshäufigkeit und ähnlichen Raten

Ermöglicht das Erstellen von Überwachungsanwendungen bei geringem Energieverbrauch.

Mittelniedriger Wert: kontinuierliche Erfassung aller Sensoren

Ziel-Batch-Zeit: 1 bis 10 Minuten

Sensoren für Batch-Daten: Alle Wecksensoren mit hoher Frequenz

Ermöglicht die vollständige Erfassung von Sensordaten, während der Zugangspunkt im Ruhemodus bleibt. Nur in Betracht ziehen, wenn der FIFO-Speicherplatz kein Problem darstellt.