バッチ処理

バッチ処理とは

バッチ処理とは、センサー HALを介してイベントを報告する前に、センサー ハブやハードウェア FIFO でセンサー イベントをバッファリングすることを指します。センサー イベントがバッファリングされる場所 (センサー ハブおよび/またはハードウェア FIFO) は、このページでは "FIFO" と呼ばれます。センサー イベントのバッチ処理がアクティブでない場合、センサー イベントは、使用可能な場合はセンサー HAL にすぐに報告されます。

バッチ処理により、個々のイベントごとに起動するのではなく、多くのセンサー イベントを処理する準備ができたときに、Android を実行するメイン アプリケーション プロセッサ (AP) のみを起動することで、大幅な電力節約を実現できます。省電力の可能性は、センサー ハブや FIFO がバッファできるイベントの数に直接関係しています。より多くのイベントをバッチ処理できれば、省電力の可能性が大きくなります。バッチ処理では、低電力メモリの使用を活用して、高電力 AP ウェイクアップの数を減らします。

バッチ処理は、センサーがハードウェア FIFO を所有している場合、および/またはセンサー ハブ内でイベントをバッファーできる場合にのみ発生します。いずれの場合も、センサーはSensorInfo.fifoMaxEventCountを使用して、一度にバッチ処理できるイベントの最大数を報告する必要があります。

センサーが FIFO 内にスペースを予約している場合、センサーはSensorInfo.fifoReservedEventCountを通じて予約されたイベントの数を報告する必要があります。 FIFO がセンサー専用の場合、 SensorInfo.fifoReservedEventCountは FIFO のサイズです。 FIFO が複数のセンサー間で共有されている場合、この値はゼロになることがあります。一般的な使用例は、センサーが唯一のアクティブなセンサーである場合に、センサーが FIFO 全体を使用できるようにすることです。複数のセンサーがアクティブな場合、各センサーには、FIFO 内の少なくともSensorInfo.fifoReservedEventCountイベント用のスペースが保証されます。センサー ハブを使用する場合、保証はソフトウェアによって強制される場合があります。

センサー イベントは、次の状況でバッチ処理されます。

• センサーの現在の最大レポート レイテンシは 0 より大きいため、HAL を通じてレポートされる前に、センサー イベントを最大レポート レイテンシまで遅延させることができます。
• AP はサスペンド モードで、センサーは非ウェイクアップ センサーです。この場合、イベントは AP をウェイクアップしてはならず、AP がウェイクアップするまで保存する必要があります。

センサーがバッチ処理をサポートしておらず、AP がスリープ状態の場合、ウェイクアップ センサー イベントのみが AP に報告され、非ウェイクアップ イベントは AP に報告されてはなりません。

バッチ処理パラメーター

バッチ処理の動作を制御する 2 つのパラメーターは、 sampling_period_nsとmax_report_latency_nsです。 sampling_period_nsは、新しいセンサー イベントが生成される頻度を決定し、 max_report_latency_nsは、イベントがセンサー HAL に報告されるまでの時間を決定します。

sampling_period_ns

sampling_period_nsパラメータの意味は、指定されたセンサーのレポート モードによって異なります。

• 連続: sampling_period_nsはサンプリング レートであり、イベントが生成されるレートを意味します。
• 変更時: sampling_period_nsは、イベントのサンプリング レートを制限します。つまり、イベントは、 sampling_period_nsナノ秒ごとに生成されることはありません。イベントが生成されず、測定値が長期間変化しない場合、期間はsampling_period_nsよりも長くなる可能性があります。詳細については、変更時レポート モードを参照してください。
• ワンショット: sampling_period_nsは無視されます。効果はありません。
• 特別: 特別なセンサーでsampling_period_nsを使用する方法の詳細については、「センサーの種類」を参照してください。

さまざまなモードでのsampling_period_nsの影響の詳細については、レポート モードを参照してください。

連続センサーとオンチェンジセンサーの場合:

• sampling_period_nsがSensorInfo.minDelayより小さい場合、HAL 実装はサイレントにmax(SensorInfo.minDelay, 1ms)にクランプする必要があります。 Android は、1000 Hz を超えるイベントの生成をサポートしていません。
• sampling_period_nsがSensorInfo.maxDelayより大きい場合、HAL 実装はそれをSensorInfo.maxDelayに静かに切り詰める必要があります。

物理センサーには、実行できる速度とクロックの精度に制限がある場合があります。これを考慮して、実際のサンプリング周波数は、以下の表の要件を満たしている限り、要求された周波数と異なる場合があります。

max_report_latency_ns

max_report_latency_nsは、AP が起動している間に HAL を介して報告される前に、イベントを遅延させてハードウェア FIFO に格納できる最大時間をナノ秒単位で設定します。

ゼロの値は、FIFO を完全にスキップするか、センサーからの 1 つのイベントが存在するとすぐに FIFO を空にするかのいずれかで、測定されたらすぐにイベントを報告する必要があることを意味します。

たとえば、 max_report_latency_ns=0で 50 Hz でアクティブ化された加速度計は、AP が起動しているときに 1 秒あたり 50 回の割り込みをトリガーします。

max_report_latency_ns>0の場合、センサー イベントは検出されたらすぐに報告する必要はありません。イベントがmax_report_latency_nsナノ秒を超えて遅延しない限り、FIFO に一時的に格納し、バッチでレポートすることができます。これは、前のバッチ以降のすべてのイベントが記録され、一度に返されることを意味します。これにより、AP に送信される割り込みの量が減り、センサーがデータをキャプチャしてバッチ処理している間、AP は低電力モード (アイドル) に切り替えることができます。

各イベントには、関連付けられたタイムスタンプがあります。イベントが報告される時間を遅らせても、イベントのタイムスタンプには影響しません。タイムスタンプは正確で、イベントが報告された時間ではなく、物理的に発生した時間に対応している必要があります。

センサー イベントを FIFO に一時的に保存できるようにしても、イベントを HAL に送信する動作は変更されません。異なるセンサーからのイベントはインターリーブでき、同じセンサーからのすべてのイベントは時間順に並べられます。

ウェイクアップ イベントと非ウェイクアップ イベント

ウェイクアップ センサーからのセンサー イベントは、1 つ以上のウェイクアップ FIFO に格納する必要があります。一般的な設計は、すべてのウェイクアップ センサーからのイベントがインターリーブされる単一の大きな共有ウェイクアップ FIFO を持つことです。または、センサーごとに 1 つのウェイクアップ FIFO を使用するか、特定のウェイクアップ センサー専用の FIFO と残りのウェイクアップ センサー用の共有 FIFO を使用することもできます。

同様に、非ウェイクアップ センサーからのセンサー イベントは、1 つ以上の非ウェイクアップ FIFO に格納する必要があります。

いずれの場合も、ウェイクアップ センサー イベントと非ウェイクアップ センサー イベントを同じ FIFO にインターリーブすることはできません。ウェイクアップ イベントはウェイクアップ FIFO に格納する必要があり、非ウェイクアップ イベントは非ウェイクアップ FIFO に格納する必要があります。

ウェイクアップ FIFO の場合、単一の大規模な共有 FIFO 設計は、最高の消費電力の利点を提供します。非ウェイクアップ FIFO の場合、単一の大きな共有 FIFO といくつかの小さな予約済み FIFO の設計は、同様の電力特性を持っています。各 FIFO の構成方法に関するその他の提案については、 FIFO 割り当ての優先度を参照してください。

サスペンド モード以外の動作

AP が起動している (サスペンド モードではない) 場合、イベントはmax_report_latencyを超えて遅延しない限り、FIFO に一時的に保存されます。

AP がサスペンド モードに移行しない限り、イベントがドロップまたは失われることはありません。 max_report_latencyが経過する前に内部 FIFO がいっぱいになった場合、その時点でイベントが報告され、イベントが失われないようにします。

複数のセンサーが同じ FIFO を共有し、そのうちの 1 つのmax_report_latencyが経過すると、他のセンサーのmax_report_latencyがまだ経過していなくても、FIFO からのすべてのイベントが報告されます。これにより、イベントのバッチが報告される回数が減ります。 1 つのイベントを報告する必要がある場合、すべてのセンサーからのすべてのイベントが報告されます。

たとえば、次のセンサーがアクティブになっているとします。

• max_report_latency = 20s でバッチ処理された加速度計
• max_report_latency = 5s でバッチ処理されたジャイロスコープ

加速度計とジャイロスコープが同じ FIFO を共有していなくても、加速度計のバッチは、ジャイロスコープのバッチが報告されるのと同時に (5 秒ごとに) 報告されます。

サスペンドモード時の挙動

バッチ処理は、AP を停止させずにバックグラウンドでセンサー データを収集する場合に特に役立ちます。センサー ドライバーと HAL 実装はウェイクロックを保持することが許可されていないため*、センサー データが収集されている間でも、AP はサスペンド モードに入ることができます。

AP が中断されている間のセンサーの動作は、センサーがウェイクアップ センサーであるかどうかによって異なります。詳細については、ウェイクアップ センサーを参照してください。

非ウェイクアップ FIFO がいっぱいになると、循環バッファーのように動作し、古いイベントを新しいイベントに置き換えて古いイベントを上書きする必要があります。 max_report_latencyは、サスペンド モードの間、非ウェイクアップ FIFO に影響を与えません。

ウェイクアップ FIFO がいっぱいになるか、いずれかのウェイクアップ センサーのmax_report_latencyが経過すると、ハードウェアは AP をウェイクアップしてデータを報告する必要があります。

どちらの場合でも (ウェイクアップと非ウェイクアップ)、AP がサスペンド モードから復帰するとすぐに、一部のセンサーのmax_report_latencyがまだ経過していない場合でも、すべての FIFO の内容を含むバッチが生成されます。これにより、AP がサスペンド モードに戻った直後に再びウェイクアップしなければならないリスクが最小限に抑えられるため、消費電力が最小限に抑えられます。

*ウェイクロックの保持が許可されていないドライバーの注目すべき例外の 1 つは、連続レポート モードのウェイクアップ センサーがmax_report_latency < 1 秒でアクティブ化されている場合です。この場合、AP はサスペンド モードに入る前にウェイクアップ イベントによって起動されるため、AP にはサスペンド モードに入る時間がないため、ドライバーはウェイク ロックを保持できます。

ウェイクアップ センサーをバッチ処理する際の注意事項

デバイスによっては、AP がサスペンド モードから完全に抜け出し、FIFO のフラッシュを開始するまでに数ミリ秒かかる場合があります。ウェイクアップ FIFO がオーバーフローすることなくデバイスがサスペンド モードから復帰できるように、FIFO に十分なヘッド ルームを割り当てる必要があります。イベントが失われることはなく、 max_report_latencyを尊重する必要があります。

非ウェイクアップ オンチェンジ センサーをバッチ処理する際の注意事項

変化時センサーは、測定している値が変化している場合にのみイベントを生成します。 AP がサスペンド モードのときに測定値が変化した場合、アプリケーションは、AP がウェイクアップするとすぐにイベントを受信することを期待します。このため、センサーがその FIFO を他のセンサーと共有する場合、非ウェイクアップオン チェンジ センサー イベントのバッチ処理は慎重に実行する必要があります。各オンチェンジ センサーによって生成された最後のイベントは、他のイベントによって上書きされないように、常に共有 FIFO の外に保存する必要があります。 AP がウェイクアップすると、FIFO からのすべてのイベントが報告された後、最後のオンチェンジ センサー イベントが報告される必要があります。

避けるべき状況は次のとおりです。

1. アプリケーションは、同じ FIFO を共有する非ウェイクアップ ステップ カウンター (変更時) と非ウェイクアップ加速度計 (連続) に登録します。
2. アプリケーションは、ステップ カウンター イベントstep_count=1000 steps code> を受け取ります。
3. AP はサスペンド状態になります。
4. ユーザーが 20 歩歩くと、歩数カウンター イベントと加速度計イベントがインターリーブされ、最後の歩数カウンター イベントはstep_count = 1020 stepsになります。
5. ユーザーが長時間動かないため、加速度計イベントが FIFO に蓄積され続け、最終的に共有 FIFO のすべてのstep_countイベントが上書きされます。
6. AP が起動し、FIFO からのすべてのイベントがアプリケーションに送信されます。
7. アプリケーションは加速度計イベントのみを受け取り、ユーザーが歩いていないと判断します。

最後のステップ カウンター イベントを FIFO の外に保存することで、他のすべてのステップ カウンター イベントが加速度計イベントによって上書きされた場合でも、HAL は AP がウェイクアップしたときにこのイベントを報告できます。このようにして、AP がウェイクアップすると、アプリケーションはstep_count = 1020 stepsを受け取ります。

バッチ処理の実装

電力を節約するには、AP の助けを借りずにバッチ処理を実装する必要があり、バッチ処理中に AP を一時停止できるようにする必要があります。

センサー ハブでバッチ処理を実行する場合は、センサー ハブの電力使用量を最小限に抑える必要があります。

最大レポート遅延は、特に指定されたセンサーが既に有効になっている場合はいつでも変更できます。これにより、イベントが失われることはありません。

FIFO割り当て優先度

ハードウェア FIFO やセンサー ハブのバッファー サイズが制限されているプラ​​ットフォームでは、システム設計者は、各センサーに予約する FIFO の量を選択する必要がある場合があります。この選択を支援するために、さまざまなセンサーにバッチ処理が実装されている場合に可能なアプリケーションのリストを次に示します。

高価値: 低消費電力の歩行者推測航法

目標バッチ処理時間: 1 ～ 10 分

バッチ処理するセンサー:

• ウェイクアップステップ検出器
• 5 Hz でのウェイクアップ ゲーム回転ベクトル
• 5 Hz でのウェイクアップ バロメーター
• キャリブレーションされていない磁力計を 5 Hz でウェイクアップ

このデータをバッチ処理することで、AP を一時停止させながら、歩行者推測航法を実行できます。

高価値: 中程度のパワーの断続的なアクティビティ/ジェスチャ認識

目標バッチ処理時間: 3 秒

バッチ処理するセンサー: 50 Hz の非ウェイクアップ加速度計

このデータをバッチ処理することで、データの収集中に AP をアクティブにしておく必要なく、任意のアクティビティやジェスチャを定期的に認識することができます。

中値: 中パワーの継続的なアクティビティ/ジェスチャー認識

目標バッチ処理時間: 1 ～ 3 分

バッチ処理するセンサー: 50 Hz でのウェイクアップ加速度計

このデータをバッチ処理することで、データの収集中に AP をアクティブにしておく必要なく、任意のアクティビティやジェスチャを継続的に認識することができます。

中高値: 割り込み負荷の軽減

目標バッチ処理時間: < 1 秒

バッチ処理するセンサー: 任意の高周波センサー、通常は非ウェイクアップ。

ジャイロスコープが 240 Hz に設定されている場合、ジャイロ イベントを 10 個だけバッチ処理するだけでも、割り込みの数を 240/秒から 24/秒に減らすことができます。

中程度の値: 継続的な低頻度のデータ収集

目標バッチ処理時間: 1 ～ 10 分

バッチ処理するセンサー:

• 1 Hz でのウェイクアップ バロメーター
• 1 Hz でウェイクアップ湿度センサー
• 同様のレートでの他の低頻度ウェイクアップセンサー

低消費電力で監視アプリケーションを作成できます。

中低値: 連続フルセンサー収集

目標バッチ処理時間: 1 ～ 10 分

バッチ処理するセンサー: すべてのウェイクアップ センサー、高頻度

AP をサスペンド モードにしたまま、センサー データを完全に収集できます。 FIFO スペースが問題にならない場合にのみ検討してください。