Traitement par lot

Qu'est-ce que le traitement par lot ?

Le traitement par lot consiste à mettre en mémoire tampon les événements des capteurs dans un hub de capteurs et/ou un FIFO matériel avant de les signaler via le HAL des capteurs. L'emplacement où les événements des capteurs sont mis en mémoire tampon (hub de capteurs et/ou FIFO matériel) est appelé "FIFO" sur cette page. Lorsque le traitement par lot des événements de capteur n'est pas actif, les événements de capteur sont immédiatement signalés au HAL Sensors lorsqu'ils sont disponibles.

Le traitement par lot peut permettre d'économiser de l'énergie de manière significative en ne réveillant le processeur d'applications principal (AP), qui exécute Android, que lorsque de nombreux événements de capteur sont prêts à être traités, au lieu de le réveiller pour chaque événement individuel. Les économies d'énergie potentielles sont directement corrélées au nombre d'événements que le hub de capteurs et/ou le FIFO peuvent tamponner: plus le nombre d'événements pouvant être regroupés est élevé, plus les économies d'énergie sont importantes. Le traitement par lot exploite l'utilisation de la mémoire basse consommation afin de réduire le nombre de réveils de point d'accès haute consommation.

Le traitement par lot ne peut se produire que lorsqu'un capteur possède un FIFO matériel et/ou peut tamponner des événements dans un hub de capteurs. Dans les deux cas, le capteur doit indiquer le nombre maximal d'événements pouvant être traités en lot à la fois via SensorInfo.fifoMaxEventCount.

Si un capteur a réservé de l'espace dans une file d'attente FIFO, il doit indiquer le nombre d'événements réservés via SensorInfo.fifoReservedEventCount. Si le FIFO est dédié au capteur, SensorInfo.fifoReservedEventCount correspond à la taille du FIFO. Si la file d'attente FIFO est partagée entre plusieurs capteurs, cette valeur peut être nulle. Un cas d'utilisation courant consiste à autoriser un capteur à utiliser l'ensemble de la file d'attente FIFO s'il s'agit du seul capteur actif. Si plusieurs capteurs sont actifs, chaque capteur dispose d'un espace garanti pour au moins SensorInfo.fifoReservedEventCount événements dans la file d'attente FIFO. Si un hub de capteurs est utilisé, la garantie peut être appliquée via un logiciel.

Les événements des capteurs sont regroupés dans les situations suivantes:

  • La latence de rapport maximale actuelle du capteur est supérieure à zéro, ce qui signifie que les événements du capteur peuvent être retardés jusqu'à la latence de rapport maximale avant d'être signalés via le HAL.
  • Le point d'accès est en mode suspension et le capteur n'est pas un capteur de réveil. Dans ce cas, les événements ne doivent pas réveiller l'AP et doivent être stockés jusqu'à ce qu'il se réveille.

Si un capteur n'est pas compatible avec le traitement par lot et que l'AP est en veille, seuls les événements de réveil du capteur sont signalés à l'AP. Les événements de non-réveil ne doivent pas être signalés à l'AP.

Paramètres de traitement par lots

Les deux paramètres qui régissent le comportement du traitement par lot sont sampling_period_ns et max_report_latency_ns. sampling_period_ns détermine la fréquence à laquelle un nouvel événement de capteur est généré, et max_report_latency_ns détermine le délai avant que l'événement ne soit signalé au HAL Sensors.

sampling_period_ns

La signification du paramètre sampling_period_ns dépend du mode de création de rapports du capteur spécifié:

  • Continu: sampling_period_ns correspond au taux d'échantillonnage, c'est-à-dire au taux auquel les événements sont générés.
  • "On-change" (En cas de modification) : sampling_period_ns limite le taux d'échantillonnage des événements, ce qui signifie que les événements ne sont pas générés plus rapidement que toutes les sampling_period_ns nanosecondes. Les périodes peuvent être plus longues que sampling_period_ns si aucun événement n'est généré et que les valeurs mesurées ne changent pas pendant de longues périodes. Pour en savoir plus, consultez le mode de création de rapports à chaque modification.
  • Une seule fois: sampling_period_ns est ignoré. Elle n'a aucun effet.
  • Spécial: Pour en savoir plus sur l'utilisation de sampling_period_ns pour les capteurs spéciaux, consultez la section Types de capteurs.

Pour en savoir plus sur l'impact de sampling_period_ns dans les différents modes, consultez la section Modes de création de rapports.

Pour les capteurs continus et à changement:

  • Si sampling_period_ns est inférieur à SensorInfo.minDelay, l'implémentation HAL doit le fixer à max(SensorInfo.minDelay, 1ms) en mode silencieux. Android n'est pas compatible avec la génération d'événements à plus de 1 000 Hz.
  • Si sampling_period_ns est supérieur à SensorInfo.maxDelay, l'implémentation HAL doit le tronquer en SensorInfo.maxDelay de manière silencieuse.

Les capteurs physiques présentent parfois des limites quant aux fréquences à laquelle ils peuvent fonctionner et à la précision de leurs horloges. Pour tenir compte de cela, la fréquence d'échantillonnage réelle peut différer de la fréquence demandée tant qu'elle répond aux exigences du tableau ci-dessous.

Si la fréquence demandée est

La fréquence réelle doit donc être

inférieure à la fréquence minimale (<1/maxDelay)

entre 90 et 110 % de la fréquence minimale

entre la fréquence minimale et la fréquence maximale

entre 90 et 220 % de la fréquence demandée

au-dessus de la fréquence maximale (>1/minDelay)

entre 90 et 110 % de la fréquence maximale, et en dessous de 1 100 Hz

max_report_latency_ns

max_report_latency_ns définit la durée maximale en nanosecondes, au cours de laquelle les événements peuvent être retardés et stockés dans le FIFO matériel avant d'être signalés via le HAL lorsque l'AP est actif.

Une valeur de zéro signifie que les événements doivent être signalés dès qu'ils sont mesurés, en ignorant complètement la file d'attente FIFO ou en la vidant dès qu'un événement du capteur est présent.

Par exemple, un accéléromètre activé à 50 Hz avec max_report_latency_ns=0 déclenchera des interruptions 50 fois par seconde lorsque l'AP est actif.

Lorsque max_report_latency_ns>0, les événements de capteur n'ont pas besoin d'être signalés dès qu'ils sont détectés. Ils peuvent être stockés temporairement dans la file d'attente FIFO et signalés par lots, à condition qu'aucun événement ne soit retardé de plus de max_report_latency_ns nanosecondes. Cela signifie que tous les événements depuis le lot précédent sont enregistrés et renvoyés en une seule fois. Cela réduit le nombre d'interruptions envoyées au point d'accès et permet à celui-ci de passer en mode d'alimentation inférieur (inactif) pendant que le capteur capture et regroupe les données.

Chaque événement est associé à un code temporel. Le report de l'heure à laquelle un événement est signalé n'a aucune incidence sur son code temporel. Le code temporel doit être précis et correspondre à l'heure à laquelle l'événement s'est produit physiquement, et non à l'heure à laquelle il a été signalé.

Autoriser le stockage temporaire des événements de capteur dans la file d'attente FIFO ne modifie pas le comportement d'envoi des événements au HAL. Les événements de différents capteurs peuvent être entrelacés, et tous les événements du même capteur sont ordonnés par ordre chronologique.

Événements de réveil et non de réveil

Les événements de capteurs des capteurs de réveil doivent être stockés dans un ou plusieurs FIFO de réveil. Une conception courante consiste à utiliser une file d'attente FIFO de réveil partagée, grande et unique, dans laquelle les événements de tous les capteurs de réveil sont entrelacés. Vous pouvez également avoir un FIFO de réveil par capteur ou des FIFO dédiés à des capteurs de réveil particuliers et un FIFO partagé pour le reste des capteurs de réveil.

De même, les événements de capteurs provenant de capteurs sans réveil doivent être stockés dans un ou plusieurs FIFO sans réveil.

Dans tous les cas, les événements de capteur de réveil et les événements de capteur non de réveil ne peuvent pas être entrelacés dans le même FIFO. Les événements de réveil doivent être stockés dans une file d'attente FIFO de réveil, et les événements de non-réveil doivent être stockés dans une file d'attente FIFO de non-réveil.

Pour le FIFO de réveil, la conception FIFO unique, grande et partagée offre les meilleurs avantages énergétiques. Pour le FIFO sans réveil, le grand FIFO partagé unique et plusieurs conceptions de petits FIFO réservés présentent des caractéristiques d'alimentation similaires. Pour obtenir des suggestions sur la configuration de chaque file d'attente FIFO, consultez la section Priorité d'allocation FIFO.

Comportement en dehors du mode suspendu

Lorsque l'AP est actif (pas en mode suspension), les événements sont stockés temporairement dans des FIFO tant qu'ils ne sont pas retardés de plus de max_report_latency.

Tant que l'AP ne passe pas en mode suspension, aucun événement ne doit être abandonné ni perdu. Si les FIFO internes sont saturés avant l'expiration de max_report_latency, des événements sont signalés à ce stade pour s'assurer qu'aucun événement n'est perdu.

Si plusieurs capteurs partagent le même FIFO et que le max_report_latency de l'un d'eux expire, tous les événements du FIFO sont signalés, même si le max_report_latency des autres capteurs n'a pas encore expiré. Cela réduit le nombre de fois où des lots d'événements sont signalés. Lorsqu'un événement doit être enregistré, tous les événements de tous les capteurs sont enregistrés.

Par exemple, si les capteurs suivants sont activés:

  • Accéléromètre groupé avec max_report_latency = 20 s
  • Gyroscope groupé avec max_report_latency = 5 s

Les lots d'accéléromètre sont signalés en même temps que les lots de gyroscope (toutes les 5 secondes), même si l'accéléromètre et le gyroscope ne partagent pas le même FIFO.

Comportement en mode suspendu

Le traitement par lot est particulièrement utile pour collecter des données de capteur en arrière-plan sans maintenir l'AP allumé. Étant donné que les pilotes de capteurs et l'implémentation HAL ne sont pas autorisés à maintenir un wake-lock*, l'AP peut passer en mode suspension même lorsque des données de capteur sont collectées.

Le comportement des capteurs lorsque l'AP est suspendu dépend du fait que le capteur soit un capteur de réveil. Pour en savoir plus, consultez la section Capteurs de réveil.

Lorsqu'un FIFO sans réveil se remplit, il doit se boucler et se comporter comme un tampon circulaire, en écrasant les anciens événements par les nouveaux. max_report_latency n'a aucun impact sur les FIFO non réveillés en mode suspension.

Lorsqu'un FIFO de réveil se remplit ou que le max_report_latency de l'un des capteurs de réveil expire, le matériel doit réveiller l'AP et signaler les données.

Dans les deux cas (réveille et non-réveille), dès que l'AP sort du mode suspension, un lot est généré avec le contenu de tous les FIFO, même si le max_report_latency de certains capteurs n'est pas encore écoulé. Cela réduit le risque que l'AP doive se réveiller peu de temps après son retour en mode suspension et, par conséquent, réduit la consommation d'énergie.

*Une exception notable à l'interdiction des pilotes de maintenir un wakelock est lorsqu'un capteur de réveil avec le mode de signalement continu est activé avec max_report_latency < 1 seconde. Dans ce cas, le pilote peut maintenir un verrouillage de réveil, car l'AP n'a pas le temps d'entrer en mode suspension, car il serait réveillé par un événement de réveil avant d'atteindre le mode suspension.

Précautions à prendre lors du traitement par lot des capteurs de réveil

En fonction de l'appareil, il peut s'écouler quelques millisecondes avant que l'AP ne sorte complètement du mode suspension et commence à vider le FIFO. Un espace suffisant doit être alloué dans la file d'attente FIFO pour permettre à l'appareil de sortir du mode suspension sans que la file d'attente FIFO de réveil ne déborde. Aucun événement ne doit être perdu, et le max_report_latency doit être respecté.

Précautions à prendre lors du traitement par lot des capteurs de changement sans réveil

Les capteurs à changement ne génèrent des événements que lorsque la valeur qu'ils mesurent change. Si la valeur mesurée change alors que l'AP est en mode suspension, les applications s'attendent à recevoir un événement dès que l'AP se réveille. Par conséquent, le traitement par lot des événements de capteur de modification sans réveil doit être effectué avec précaution si le capteur partage son FIFO avec d'autres capteurs. Le dernier événement généré par chaque capteur de modification doit toujours être enregistré en dehors de la file d'attente FIFO partagée afin qu'il ne puisse jamais être écrasé par d'autres événements. Lorsque l'AP se réveille, après que tous les événements du FIFO ont été signalés, le dernier événement de capteur de changement doit être signalé.

Voici une situation à éviter:

  1. Une application s'inscrit au compteur de pas sans réveil (à la modification) et à l'accéléromètre sans réveil (en continu), qui partagent tous les deux le même FIFO.
  2. L'application reçoit un événement de compteur de pas step_count=1000 stepscode>.
  3. Le point d'accès passe en mode suspension.
  4. L'utilisateur fait 20 pas, ce qui entraîne l'intercalation des événements du compteur de pas et de l'accéléromètre, le dernier événement du compteur de pas étant step_count = 1020 steps.
  5. L'utilisateur ne bouge pas pendant une longue période, ce qui entraîne une accumulation continue d'événements d'accéléromètre dans la file d'attente FIFO, qui écrase finalement chaque événement step_count dans la file d'attente FIFO partagée.
  6. Le point d'accès se réveille et tous les événements de la file d'attente FIFO sont envoyés à l'application.
  7. L'application ne reçoit que des événements d'accéléromètre et pense que l'utilisateur n'a pas marché.

En enregistrant le dernier événement du compteur de pas en dehors de la file d'attente FIFO, le HAL peut signaler cet événement lorsque l'AP se réveille, même si tous les autres événements du compteur de pas ont été écrasés par des événements d'accéléromètre. De cette manière, l'application reçoit step_count = 1020 steps lorsque l'AP se réveille.

Implémenter le traitement par lots

Pour économiser de l'énergie, le traitement par lot doit être implémenté sans l'aide du PA, et le PA doit être autorisé à suspendre le traitement par lot.

Si le traitement par lot est effectué dans un hub de capteurs, l'alimentation du hub de capteurs doit être réduite au minimum.

La latence maximale des rapports peut être modifiée à tout moment, en particulier lorsque le capteur spécifié est déjà activé. Cela ne devrait pas entraîner la perte d'événements.

Priorité d'allocation FIFO

Sur les plates-formes où la taille de la mémoire tampon du hub de capteurs et/ou du FIFO matériel est limitée, les concepteurs de systèmes peuvent devoir choisir la quantité de FIFO à réserver pour chaque capteur. Pour vous aider à faire ce choix, voici une liste des applications possibles lorsque le traitement par lot est implémenté sur les différents capteurs.

Valeur élevée: estimation de la position à pied à faible consommation d'énergie

Durée de traitement par lot cible: de 1 à 10 minutes

Capteurs à traiter en lot:

  • Détecteur de pas pour le réveil
  • Vecteur de rotation du jeu de réveil à 5 Hz
  • Baromètre de réveil à 5 Hz
  • Réveil du magnétomètre non étalonné à 5 Hz

Le traitement par lot de ces données permet d'effectuer le calcul de position par triangulation pédiatrique tout en laissant l'AP en suspension.

Valeur élevée: activité intermittente à intensité moyenne/reconnaissance des gestes

Durée de traitement par lot cible: 3 secondes

Capteurs à traiter en lot: accéléromètre sans réveil à 50 Hz

Le traitement par lot de ces données permet de reconnaître périodiquement des activités et des gestes arbitraires sans avoir à maintenir le point d'accès allumé pendant la collecte des données.

Valeur moyenne: reconnaissance de l'activité/des gestes continue à puissance moyenne

Durée de traitement par lot cible: 1 à 3 minutes

Capteurs à traiter en lot: accéléromètre de réveil à 50 Hz

Le traitement par lot de ces données permet de reconnaître en continu des activités et des gestes arbitraires sans avoir à maintenir le point d'accès allumé pendant la collecte des données.

Valeur moyenne-élevée: réduction de la charge d'interruption

Temps de traitement par lot cible: < 1 seconde

Capteurs à traiter en lot: tout capteur haute fréquence, généralement sans réveil.

Si le gyroscope est défini sur 240 Hz, même le traitement par lot de seulement 10 événements de gyroscope peut réduire le nombre d'interruptions de 240 par seconde à 24 par seconde.

Valeur moyenne: collecte continue de données à faible fréquence

Durée de traitement par lot cible: de 1 à 10 minutes

Capteurs à traiter en lot:

  • Baromètre de réveil à 1 Hz
  • Capteur d'humidité de réveil à 1 Hz
  • Autres capteurs de réveil à basse fréquence à des fréquences similaires

Permet de créer des applications de surveillance à faible consommation d'énergie.

Valeur moyenne-basse: collecte continue de tous les capteurs

Durée de traitement par lot cible: de 1 à 10 minutes

Capteurs à mettre en lot: tous les capteurs de réveil, à haute fréquence

Permet de collecter l'intégralité des données des capteurs tout en laissant l'AP en mode suspension. Ne le faites que si l'espace FIFO n'est pas un problème.