GPSマルチユニットSORACOM Editionに学ぶIoTアーキテクチャ設計

はじめに

GPSマルチユニットSORACOM Editionは単体のデバイスとしてみても面白いですが、リファレンスデバイス、つまり「IoTデバイスおよびシステムを設計する際のお手本にするデバイス」としてみると勉強になります。特にセンシング対象やアップロード間隔などを設定する必要があるセンサーデバイスの場合、かなり良いです。

今回はGPSマルチユニットSORACOM Editionのアーキテクチャ的な面を見ていきたいと思います。

結論を先に書くと以下の２点です。

• センサーデータはUDPでUnified Endpointに送信する
• 設定はSIMのタグかSIMグループのユーザーデータに持たせてSORACOM Airメタデータサービスから読ませる

センサーデバイスを使ったIoTシステムの場合この２つを検討する、ということを伝えるための記事です。

GPSマルチユニットSORACOM Editionとは

製品説明は過去の記事に書きましたので、こちらをご覧ください。

センシングシステムに対する要求

GPSマルチユニットSORACOM EditionはGPSや温湿度、加速度センサーの情報を、セルラー回線を使って送信し、クラウドで保存、可視化などの利用をする、というIoTシステムのデバイスです。このようなセンサーデバイスはIoTシステムではよく見られるものですね。

このようなセンサーデバイスを使ったIoシステムでは、以下のような要求が考えられます。

• 電池持続時間を長くしたい
• どのセンサーからデータを取得するか、センサーのアップロード間隔などを簡単に設定したい
• センサーデータはクラウドで活用したい
• 開発期間を短くして、早く導入したい
• デバイスの製造、ランニングコストを抑えたい
• セキュリティを高めたい

このような要求が、どのように実現されているかを見ていきましょう。

システム構成

公式のブログでは、以下のような構成図になっています。
https://blog.soracom.jp/blog/2020/02/12/gps-multiunit-soracom-edition/

通信するための設定は設定済でありSORACOM AirのSIMを挿すだけで使えること、ユーザーコンソールから設定ができること、クラウド側の処理はUnified Endpointに送信してその先で様々なサービスに連動していることが分かりますね。

回線にはLTE-MというセルラーLPWA（省電力無線）が使われています。前回の記事でも書きましたが、LTE-MにはeDRXやPSMといった、通信を確立したまま受信の電力消費を抑える機能があるため、センサーデバイスのように一定間隔でデータを送信する用途にはよく合います。

Unified Endpointを使うとデバイスの設定は何も変えることなく、クラウドの設定だけで動作を変えられるので、デバイス側は変更せずに機能を追加していくことができます。お勧めの機能です。

この図でわからないのは、どのように設定が反映されているかです。実際に試してみると、設定はSORACOM Air メタデータサービスのユーザーデータに保存され、起動時、ボタン押した時、1日1回いずれかのタイミングでその設定を読むようになっています。

設定すると以下のようなユーザーデータが保存されていました。

{"SensorData":{"acc":{"i1":"ON"},"loc":{"i1":"OFF"},"tem":{"i1":"ON"},"hum":{"i1":"ON"},"bat":{"i1":"ON"}},"Common":{"C1":["null","null","null","null","null","1981/04/01","1981/04/01","1981/04/01","null","null"],"C2":["null","null","null","null","null","2059/12/31","2059/12/31","2059/12/31","null","null"],"C3":["null","null","null","null","null","00:00","00:00","00:00","null","null"],"C4":["null","null","null","null","null","23:59","23:59","23:59","null","null"],"C5":[-20000,-20000,-20000,-20000,-20000,10,1440,2160,-20000,-20000],"C6":["null","null","null","null","null",["SUN","MON","TUE","WED","THU","FRI","SAT"],["SUN","MON","TUE","WED","THU","FRI","SAT"],["SUN","MON","TUE","WED","THU","FRI","SAT"],"null","null"],"C7":"5,6"},"Setting":{"itr":{"i2":496}}}

使うセンサーの種類や使用する時間帯、送信間隔などが入っています。これをデバイスから読んで、動作に反映させているのですね。

ちなみにSIMのタグには「soracom.gadgets」タグに「GPS-Multiunit」が設定されますが、これはユーザーコンソールに表示するために使われており、デバイスからは参照されていません。

設定をユーザーデータに持たせてメタデータサービスで参照する構成の利点は、

• デバイスの設定データベースなど、新しいコンポーネントを用意する必要が無い。SORACOM Airを使っていれば追加料金なしで使える
• デバイスから認証なし、暗号化なしで安全に参照することができる。metadata.soracom.ioにHTTPでアクセスするだけでよく実装が簡単
• ユーザーからはWeb APIで設定でき、自社開発のプログラムに簡単に組み込むことができる

といったものです。この構成は自社開発のデバイス、IoTシステムでも、簡単に同じ構成にすることができます。苦労してデバイス設定用のデータベースを構築、運用したり、デバイスに認証情報を書き込んで認証させてアクセスさせたり、といった必要がなくなります。手軽にクラウドとデバイスで設定を共有できるのでお勧めです。

なお、この方法ではリアルタイムに設定を反映させることができません。リアルタイム性を持たせようとした場合、短めの間隔でメタデータサービスをポーリングするか、MQTTやLwM2Mで常時接続しておき必要なタイミングでメタデータサービスの設定を読ませるコマンドを送る、などで対応することができます。

全体の構成が分かったところで、SORACOMを利用する際に利用すべき

• SIM認証
• プロトコル変換
• 連携先の切り替え

といった技術要素を一つ一つ見ていきましょう。

SIM認証

SORACOMを利用したIoTシステムを考える際、活用すべきなのはSIM認証です。SIM認証とは、セルラー回線を利用する際にはSIMを使って正しい利用者かどうかが認証されているのですが、その認証をデバイスの認証に使ってしまおうというアイデアです。デバイスはSIMの識別IDであるIMSI(International Mobile Subscriber Identity)で識別されることになります。

SIM認証では、SORACOM Beamなど各種SORACOMのアプリケーションサービスまではデバイス認証なしの簡単なプロトコルでアクセスし、そのサービスからインターネット上のサーバーや、AWSのクラウドサービスに対しては、SORACOMが認証情報付きの安全なプロトコルで代理アクセスする形になります。

以下はBeamの例です。

SIM認証を利用するとデバイスに認証情報を持たせる必要が無くなり、認証情報の発行と、デバイス、クラウド双方への保存といった厄介な生産上の問題を無くすことができます。また、認証や暗号化などの負荷が高い処理をクラウド側にオフロードできるので、デバイスのソフトウェアをシンプルで軽い処理に抑えることができます。SORACOMのSIM側からデータを受け取るサービス、Beam、Funnel、Harvest、Funk、そしてUnified Endpointは全てSIM認証に対応しています。

また、SIMの設定はSORACOM側で持っており、SIMの名前やタグ、SIMのグループに設定されたテキストデータ(ユーザーデータ)はSORACOM Air メタデータから認証なしで読むことができます。クラウドとデバイスの設定共有にはここを使うと良いでしょう。個別のSIMに設定したタグなどのデータは

SIMグループにつけたユーザーデータは

にて取得することができます。ユーザーデータはグループ設定なので、そのグループに属する全てのSIMに反映させることができます。まとめて設定したい場合には便利ですね。（逆にいえば、ユーザーデータを使っているGPSマルチユニットでは、１つのデバイスに対する設定が同じグループ内の全てのデバイスに反映されてしまうので注意が必要です）

このSIM認証を活用することで、デバイスの認証情報や個別の設定を全てクラウドに持たせることができ、デバイスは永続情報をなんら持たなくても動作できる、ということができます。これによりメーカー側は同じデバイスを量産するだけで良く在庫できる（特定ユーザーでしか使えないデバイスにならない）、ユーザー側は故障などの際にいつでも交換できる（SIM交換だけで対応できるし、仮にSIMを含めて壊れたとしてもSIMの設定を同じにすれば良い）、といったメリットがあります。

クラウドでも要求を処理する部分は状態を持たない、ステートレスなサーバーにすることが推奨されていますが、デバイスもソラコムを使うことによってステートレスにできるのですね。AWSでたとえると、SIMグループがIAMロールで、そのグループにSIMを所属させるのはEC2にIAMロールをアタッチするイメージです。とても便利なので、ぜひUnified EndpointやAir メタデータを試してみてください。

なお、ファームウェアなどある程度大きなデータの場合、Unified EndpointやAir メタデータよりも、Harvest Filesというファイルを扱うサービスの方が使いやすくなりますので、それも知っておくと役に立つと思います。

プロトコル変換による通信量削減

まずこちらをご覧ください。

これはデータのアップロードを10分間隔にした際の通信量グラフです。ソラコムでは利用しているSIMの通信量がほぼリアルタイム(5分ごと)に計測され、簡単に確認することができます。これによると、通常は1時間アップロードが1070B程度、ダウンロードは正確に270Bになっています。これは10分ごとのセンサーアップロードの通信量で、1回あたりアップロード約180B、ダウンロードは正確に45Bであることがわかります。

これはとても小さいですね（普通にHTTPSで通信をすると、1回あたり数kBは普通にかかります）月の通信量は約1MBになりますので、plan-Dであれば月の通信料金は1円以下になります。GPSマルチユニットでは使えないですが仮に通信料金の高いplan01s-LDV(グローバルで使えるSIM)であったとしても50円程度で済みます。

また、1日に1回だけアップロードが730B程度、ダウンロードが1650B程度増える時間がある、ということが分かります。FAQに

また、GPS マルチユニットは 1 日に 1 回設定情報を SORACOM プラットフォームより取得します。SORACOM プラットフォームと接続できていれば最長 24 時間以内に設定は自動反映されます。

とあるので、おそらくSORACOM Air メタデータサービスからの設定取得のための通信です。

より具体的にどんな通信をしているかは、SORACOM Junctionのミラーリング機能を使えばわかります。ここでは詳しい説明はしませんが、以下のページを参考にすれば設定できます。

センサーのアップロードをキャプチャした結果がこちらになります。

アップロード

ダウンロード

このパケットはGREというプロトコルによってカプセル化されています。

この送信があった時間帯の通信量をAPIで取得すると以下のようになりました。

[
  {
    "date": "2020-02-29T07:41:29.915",
    "unixtime": 1582962089,
    "dataTrafficStatsMap": {
      "s1.standard": {
        "uploadByteSizeTotal": 176,
        "downloadByteSizeTotal": 45,
        "uploadPacketSizeTotal": 1,
        "downloadPacketSizeTotal": 1
      }
    }
  }
]

パケットは送受信それぞれ1つずつなので、このパケットだけですね。GREのパケットの中をみてパケットの大きさを算出すると、

	アップロード	ダウンロード
イーサネットヘッダー	14	14
IPヘッダー	20	20
UDPヘッダー	8	8
ペイロード	98	3
謎	36	0
合計	176	45

ダウンロードはぴったり合うので方法に間違いないと思うのですが、アップロードはこの方法では捉えられない謎の36Bがあります。しばらく考えたのですがわからないので、今回は深追いしません。

送信先は100.127.69.42、つまりUnified Endpointに向けて送っていることがわかりますね。後で書きますが、クラウド側の拡張を考えると最適な送信先です。また、送信プロトコルはUDPで、かつHTTPヘッダなどのないペイロードのみの送信です。HTTPSやHTTP、またTCPではプロトコルのヘッダーが大きく通信量が増えてしまいますが、UDPで送信すればオーバーヘッドは42Bで済みます。素晴らしい。

送信している内容はセンサーデバイスのJSONそのもので、100byte程度とそこそこのサイズがあります。バイナリパーサーを使えば1/3程度になりそうなのですが、意外にもバイナリパーサーは使っていません。バイナリパーサーは送るセンサーが決まっている時にはバッチリ決まりますが、このデバイスのように設定によってセンサが変わるのは扱いにくいのかな、とか邪推します。バイナリパーサーのアップデートに期待？

とはいえ、UDP送信にすれば通信量がかなり抑えられるのは間違いないので、積極的に使っていきたいところですね。

（ちなみに、過去の記事「SORACOM Beamによる通信量の削減効果を金額と電力量の数値で示す」で言えば4番目に相当するレベルです）

おまけ: メタデータサービスへのアクセスのパケットキャプチャ

ボタンを押した際のパケットはこのようになります。

ボタンを押すと、まずセンサーデータをアップロードしてから、ユーザーデータをダウンロードするのですね。順番逆だと思ってました。ここはSORACOM Airメタデータサービスに対しHTTPで通信して、ユーザーデータをダウンロードしています。HTTPのヘッダー部とTCPの3wayハンドシェイクなどの影響があり、そこそこ通信量が多くなってますね。

HTTPする前にmetadata.soracom.ioに対してDNSで名前解決していますね。そういえば、さっきのセンサーアップロードの時はDNSが無かったですが、IPアドレス直指定なんでしょうか？

あと最後にFIN/ACKが沢山送られてきているのはなぜ？デバイスがFIN/ACK返してない疑惑があります。

通信量取得のAPIで該当時間の通信量を取得すると、

[
  {
    "date": "2020-02-29T07:46:25.93",
    "unixtime": 1582962385,
    "dataTrafficStatsMap": {
      "s1.standard": {
        "uploadByteSizeTotal": 906,
        "downloadByteSizeTotal": 1694,
        "uploadPacketSizeTotal": 6,
        "downloadPacketSizeTotal": 14
      }
    }
  }
]

となっています。パケットキャプチャの結果を表にすると、

	アップロードパケット	ダウンロードパケット	アップロードバイト数	ダウンロードバイト数
センサーアップロード	1	1	176	45
DNS	1	1	115	95
3Wayハンドシェイク	2	1	188	62
HTTPリクエスト	1	1	337	54
HTTPレスポンス	1	1	90	952
FIN/ACK	0	9	0	486
合計	6	14	906	1694

となるので、一致しますね。(アップロードパケットには謎の36Ｂを加算してます。これで計算ぴったり合うので、アップロードには36Bが加算されるのは間違いなさそう)FIN/ACKの分も加算されているみたいなので、ここは改善して欲しいところですね。

Unified Endpointによる柔軟なクラウド活用

Unified Endpointはセンサーデバイスの送信先として最適です。SORACOMにはBeamやFunnel、HarvestやFunkなどがあり、それぞれに特長がありますが、Unified Endpointに送信するとその全てを利用することができます。

これにより、とりあえずデータを保存して可視化したい、という場合にはSORACOM HarvestをONにする、自社サーバーにデータを送って処理したい場合はSORACOM BeamをONにする、クラウドサービスと連携させたい場合はFunnelやFunkをONにする、といったデータの連係が、SORACOMの設定だけでできます。また、いずれかを選ぶことも、同時に送信させることもできます。例えば、Harvestにデータを保存させるのと同時に、Funkに送信して値に応じて通知などの処理をさせる、といったこともできます。

BeamやHarvestなどのサービスもプロトコル変換による軽量化の恩恵は受けられるものの、送信先の切り替えやその設定をデバイス側に持たせ、設定させるのはそこそこ面倒です。また、新しいソラコムサービスができたとして、デバイスをそれに対応させるにはデバイスのバージョンアップが必要になりますが、Unified EndpointであればSORACOM側で対応してくれます。

このように、できるだけデバイスはシンプルかつ変更せずに、クラウドの発展の恩恵を最大限受けることができるのがUnified Endpointです。試したことの無い人はぜひ。

この柔軟なクラウド活用はSORACOMではCloud Agnosticと表現されており、過去の記事「ソラコム最大の謎ワード「Agnostic」を解明する」で取り扱っていますので、未読の方は読んでみていただければと思います。

要求の実現の確認

最初に挙げた要求は、以下のように実現されていることがわかります。

• 電池の持続時間：セルラーLPWAのLTE-Mを採用している。また、UDPのUnified Endpointを利用することにより、デバイス側で負荷の高い暗号化処理や、デバイス認証など時間のかかる通信処理をしなくとも良くしていることも省電力に寄与している
• 設定：SORACOMのWebコンソールやWebAPIからユーザーデータを設定することで、新しいコンポーネントを用意することなく多数のデバイスをまとめて簡単に設定することができる
• クラウドでのデータ活用：Unified Endpointにデータを送信することにより、Harvestに送信してデータを保存、可視化したり、Funkに送信してクラウドサービスに処理させるなど、柔軟にクラウドサービスで利用することができ、後から拡張することも容易になっている
• 開発スピード：デバイス側はUnified Endpointに単純なプロトコルでデータを送信するだけでクラウド連携できるため、クラウドサービスに合わせた開発をする必要がない。クラウド側はすでにあるコンポーネントがそのまま利用でき、特にSORACOM HarvestとSORACOM Lagoonを使えば、最短でセンサーデータを可視化できる。
• 製造コスト：Unified Endpointやメタデータサービスなど、SIM認証を利用できるサービスを使うことで、デバイス個別の認証情報を発行し、保存するなどの工数を削減できる。また暗号化など負荷の高い処理を行うための価格の高いCPUを使用する必要が無く、場合によっては部品代が下げられる。
• ランニングコスト：UDPのUnified Endpointを利用することにより通信量を削減し、通信料金を抑えている。通信頻度を更に減らせば、基本料金が低い（通信単価が高い）プランを使ってよりコストを削減できる。
• セキュリティ：SIMの不正利用を防止するためのIMEIロックや、SORACOM Canalなどの閉域接続サービス、必要ないサービスにアクセス出来ないようにするPrivate Gardenなどのセキュリティ機能を使うことができる。

おわりに

はじめにに書きましたが、設定をもつセンサーデバイスは、Unified EndpointとSORACOM Air メタデータサービスを使うことで、簡単・柔軟・安全・安価なIoTシステムが実現できます。これからIoTデバイスやシステムを開発する際には、GPSマルチユニットが参考になるので使ってみて研究するのがいいですよ！