【IoT】消費電力量低減のため、複数回の計測データをSORACOMに一括送信する1〜構想編〜
電池駆動型IoTデバイスにおいて、消費電力量の低減は最重要課題の一つです。本記事では、まずは、消費電力量を因数分解し、送信回数低減の意義を整理した後、複数回の計測データを一括送信する方法について考えます。
背景と目的
冒頭の通り、電池駆動型IoTデバイスにおいて、消費電力量の低減は最重要課題の一つです。消費電力量を下げる手段の一つとして、IoTデバイスに接続されたセンサーで現場データを取得後、毎回クラウドに送信するのではなく、IoTデバイスに一時保存し、一括で送信することが考えられます。
現場データをリアルタイムで知る必要がある場合は、この手段を適用できませんが、リアルタイム性を求めない場合は、本方法が有効だと考えられます。
具体例として、1時間ごとに計測するIoTデバイスにおいて、IoTデバイス内に一時的にデータを保存し、24時間分のデータを1日1回クラウドに一括送信する事例を考えます。どのような課題があり、どのような解決策があるか模索します。
詳細
1. まずは消費電力量を因数分解する
消費電力量[mWh]を因数分解すると、どのような要素から構成されるでしょうか。まずは、下記の消費電力量の模式図をご覧ください。
グラフの横軸が時間、縦軸が消費電力であり、青色の線がIoTデバイスの消費電力の時間変化の模式図です。①が計測時の消費電力量、②が送信時の消費電力量、③が待機時の消費電力量です。消費電力量[mWh]は電力[mW]ｘ時間[h]であり、グラフの面積が消費電力量[mWh]に相当します。
1サイクルの消費電力量は①＋②＋③で表されます。私が扱うセンサーやマイコン（Arduino）の環境下では、①の計測時間は1秒以下であり、②の送信時間は10秒弱です。この送信時間10秒弱のうち、その大部分が通信モジュールの初期化や通信確立等の時間であり、実際に送信に要する時間はmsオーダーです。また、仮に①＋②の時間が10秒とし、計測頻度が1時間=3600秒とすると、③の時間は3590秒となります。
このような前提条件から、IoTデバイスの消費電力量[mWh]を下げる方針として、
方針１．①の計測時の消費電力量を下げる。例えば、低消費電力のマイコンを採用する
方針２．②の送信時の消費電力量を下げる。例えば、低消費電力のマイコン／通信方式／通信プロトコルを採用する
方針３．③の待機時の消費電力量を下げる。仮に、計測時間10秒、計測頻度3600秒の場合、待機時間は計測時間の359倍であり、待機時の消費電力を下げる効果は絶大！
方針４．計測頻度を下げる。必要な計測頻度を見極め、必要最低限の計測頻度とする
方針５．送信頻度を下げる。計測後毎回送信するのではなく、複数回の計測データを一括送信する
などの方針が考えられます。本記事では、「方針５」の送信頻度下げるための具体的な方法について考えます。23回分の計測時間が約1秒になり、24回目の一括送信が10秒＋αになると想定すると、数分の１オーダーで消費電力量を下げることができるのではないかと予想しています。実現できれば、相当な削減効果です！
2. 一括送信の課題は何か？
色々と思い巡らしてみましたが、下記のような課題が考えられます。
課題１．如何に複数回分の計測データをIoTデバイス内に一時保存するか？
課題２．送信エラー時の処理をどうするか？
課題３．計測時刻と送信時刻が異なるため、如何に計測時刻を記録するか？
課題４．複数回分の計測データを、どのようなデータフォーマットで送信するか？
課題５．計測時刻と送信時刻が異なるため、クラウド側でどのようにグラフ化するか？
なかなか、難易度が高そうです。。
3. 課題解決の方向性
前述の５つの課題に対し、次のような解決案を考えました。
課題１．如何に複数回分の計測データをIoTデバイス内に一時保存するか？
→マイコンのEEPROMに一時的に保存する課題２．送信エラー時の処理をどうするか？
→送信エラー時はEEPROMに保存しsleep。次の送信タイミングで再度送信課題３．計測時刻と送信時刻が異なるため、如何に計測時刻を記録するか？
→通信のタイミングで、NTP(Network Time Protocol)から現在時刻を取得し時刻補正する。通信しない時の時刻は、NTPの時刻＋sleep時間とする課題４．複数回分の計測データを、どのようなデータフォーマットで送信するか？
→CBOR形式で複数回分のデータを一つにまとめ一括で送信する課題５．計測時刻と送信時刻が異なるため、クラウド側でどのようにグラフ化するか？
→AWS Lambdaでタイムスタンプを付与し、SORACOM Inventoryを用いて、SORACOM Harvestにデータ入れ、SORACOM Lagoonでグラフ化する
4. IoTデバイスのフローチャート案
前述の、５つの課題と解決案をもとに、IoTデバイスのフローチャートを考えました。下図をご覧ください。
従来、つまり計測直後に送信する場合は、センサで計測→通信前処理→クラウドにデータ送信→マイコンsleepという流れでした。
一方、複数回の計測データを一括送信する場合は、課題１，２，３，４を考慮したフローが必要となります。
5. 現場〜クラウドの構成案
次に、現場〜クラウドの構成を考えました。下図をご覧ください。
課題４，５を考慮した構成にしています。IoTデバイス→SORACOMへはCBOR形式で送信後バイナリパーサーでJSONに変換したり、AWS Lambdaでタイムスタンプを付与したり、SORACOM Inventoryを用いてSORACOM Harvestに戻したりしています。
まとめと今後の課題
本記事では、消費電力量を因数分解し、送信頻度低減の意義を整理しました。また、計測データを一括送信する際の課題出しを行いました。さらに、課題解決案を出し、フローチャート図と構想図にまとめました。
次は、解決案の詳細を整理します。
参考
・IoTデバイスからデータ送信形式は、CBOR形式が良さそうです。
・過去データをSORACOM Lagoonで可視化するには、x-soracom-timestampを用います。
・SORACOM Inventoryを用いて、SORACOM Harvestにデータを入れる方法は、この記事が参考になります。