IoTアーキテクチャ、4つのパターン(2) - 「Using Mobile」「Using Server」

IoTシステムで求められるアーキテクチャや技術をご紹介する本連載。早いもので、今回で四回目です。

前回より、具体的なアーキテクチャパターンを四つに分けて紹介しています。今回は、前回説明しきれなかった「Using Mobile」パターン、「Using Server」パターンの二つをご紹介していきたいと思います。

Using Mobile - ウェアラブルに最適

コンシューマ向けのサービスに多いのが、この「Using Mobile」パターンです。

前回ご紹介した「Using Gateway」パターンに近いですが、IoT Gatewayの代わりにスマートフォンなどのモバイル端末を利用します。

このパターンの特徴をまとめると以下のようになります。

[メリット]

• ユーザのモバイル端末を流用できる
• 中継だけでなく他の使いみちにも使える
• 転送をコントロールしやすい

[デメリット]

• モバイル端末が必ずデバイスのそばにあるとは限らない
• 代表的な端末に対して動作検証を事前にしておく必要がある
• デバイスの数が多い場合にはモバイル端末への負荷が高くなる

このパターンで一番想像しやすいのは、ウェアラブル系のサービスでしょう。

ユーザが身に着けている端末から直接インターネット上にデータを転送してしまうと、電池消費やデータ転送の制御に課題が出てきます。そこで、ユーザが持っている場合の多いスマートフォンなどのモバイル端末を経由して、データ転送を行う仕組みにします。

そうすれば、課題が解決できるだけでなく、ユーザ側で転送の許可を確認したり、データにユーザ自身が何らかの属性をつけて転送したりするといった転送前の操作を求めることが可能です。

ただし、モバイル端末が常にデバイスのそばにあるわけではなく、また使える状態でない場合も考えられるため、データ転送の契機や中間データの保管などの転送の工夫が求められます。

Using Server - 既存の資産を活かす

「Using Server」は、前パターン同様、IoT Gatewayの代わりにいわゆる一般的なPCサーバを利用するパターンです。

サーバというとピンと来ない方も多いかと思いますが、特別用途向けに軽量化、コンパクト化されたPLC(Programmable Logic Controller)のような端末も含みます。

このパターンの特徴をまとめると以下のようになります。

[メリット]

• データ中継時にデータ変換やデータストアなどの処理が可能
• 既存の資産を転用できる場合が多い
• 転送をコントロールしやすい

[デメリット]

• モビリティに欠ける(デバイスが固定的になる)
• サーバ追加時のコストがかかる
• ネットワーク環境の構築やセキュリティ対策に課題

そもそもサーバを利用するという点で、IoTらしくはないかもしれません。しかし、工場での生産ラインからデータ収集する場合などでは、わざわざIoT Gatewayを導入せずに既存のPLC等の端末やそういったデータを集約しているサーバからデータ転送の処理を行う方が効率が良い場合があります。

また、データを集約する際に複雑な処理を作りこむことが可能なので、いわゆるエッジコンピューティング的にある程度の処理をエッジ側で行ってから転送をするという構成も容易にとれます。

ただし、コストに課題があるのと、PLCなどの端末が直接インターネットに接続できない場合も多く、ネットワークやセキュリティ対策に大きな手間がかかってしまう場合もあります。

4つのパターンのまとめと使いところ

以上、4つのパターンをご紹介しましたが、それぞれ一長一短があり、それぞれのシーンで使い分けるのが現実的でしょう。

パターンの特徴と利用シーンを簡単にまとめてみました。

	構築容易性	コスト	柔軟性	拡張性	安定性	使いみち
Device to Cloud	○	○	×	×	△	スマートメーター、リモートモニタリング、数の少ないセンサリング、テレマティクス
Using Gateway	○	△	△	○	○	数の多いセンサリング、ホームセキュリティ、コネクテッドカー、農業IoT
Using Mobile	△	○	○	△	×	ウェアラブル、スマートヘルスケア、スマートペット、オンライン決済、ビーコン、IoTを使ったコンシューマサービス
Using Server	△	×	○	△	○	生産管理、予兆検知、ファクトリーオートメーション

今回、パターンを4つにまとめましたが、技術革新やテクノロジートレンドによって今後大きく変化する可能性があることは考慮すべきです。

例えば、Device to Cloudは現時点では電池消費の問題で現実的ではないと説明しましたが、低電力な転送技術が開発されれば、この問題はすぐに解決されることでしょう。また、IoT Gatewayのスペックは日増しに向上しています。IoT GatewayがPCサーバ並のスペックになる日は近いかもしれません。

とは言え、このアーキテクチャパターンが将来的に全く意味がなくなるかというと、そうとも言えません。

このアーキテクチャパターンでは「デバイスとクラウドの距離」というのがポイントになっています。

どうやってデータを収集して、どのようにデータを転送するのか。デバイスとクラウドが近ければよいというわけではなく、状況ややりたいことによって距離をコントロールする――この点がIoTアーキテクチャでは極めて重要だということが、4つのアーキテクチャパターンから読み取れると思います。

つまりデバイスとクラウドとの適切な距離のコントロールこそが、IoTアーキテクチャの勘所ということです。

次回は、具体的なプロトコルの種類や転送方法に関して、HULFT IoTの開発者にバトンタッチして、ご紹介をしたいと思います。