IoT/M2Mについての覚え書き

  • 124
    いいね
  • 0
    コメント
この記事は最終更新日から1年以上が経過しています。

IoT(Internet of Things)/M2M(Machine to Machine)は、とにかく規格が乱立してたり、
調べることが多くて混乱する。知識の整理を兼ねて文章にしておく。
※間違い指摘コメント歓迎します。

2015年5月時点の知識で書き直した。⇒ IoT/M2Mについての覚え書き 2015年5月版 - Qiita

IoT/M2Mとは何か

同じような意味に使われるが、M2Mはモノとモノが自律的に通信することを表し、
IoTはモノがインターネットに接続して通信することを表す。
IoTの場合、接続先がモノなのかそうでないかはどうでもいい。
なのでモノとモノが通信することを強調したい場合はM2M、モノがインターネットにつながることを強調したいならIoTを使えばいいだろう。ただ、IoTがバズワード化しつつあるので、IoTでいいかも。

IoTにしろM2Mにしろ、内容は似たようなもので大きな違いはない。
センサーのように今までインターネットにつながっていなかったモノがつながって、モノが自動的にデータをインターネットに送信する。そういった大量のデータを元にいろいろ予測して、今までになかったソリューションを提供しましょう、というのが定義と思う。

なぜ流行ってるか?

技術革新による低価格化のおかげ。
以前からIoT/M2Mは実現できていたが、高コストで現実的でなかった。
ところが近年MVNOによる格安SIMと安価なボードコンピューターによるプロトタイピングが
実現したため、現実的なコストで出来るようになった。他にもスマホの普及やPANの低電力化など
さまざまな要因が重なったことも大きい。
ただし要素技術が多岐に渡るため、統合的に提供できるベンダはほとんどいない。

要素技術

IoT/M2Mでよくあるパターンは、センサーデータをゲートウェイを経由してインターネットに送信し、
そうして集まったデータをもとに分析することである。
そのため幅広い要素技術が必須で、いかに効率よく既存製品を組み合わせるかが鍵。
これらすべてを自前で用意するのは現実的ではないが、大企業からベンチャーまで多様な製品が
あるため、どの企業のものを採用するか検討が必要。
また、どの技術がデファクトになるかはまだわからない状態であり、今後出てくる技術がデファクトかもしれない。そのため、ある程度のレイヤで取り換え可能にしておくのがよいだろう。レイヤは次のような単位で考えられる。

センサーデバイス

センサー自体は多種多様なものが存在するが、それを別のレイヤに送信できるものは少ない。
現時点では Zigbee/EnOcean/Z-Wave を使用したものが存在する。

PAN(Personal Area Network)

センサーデバイスとゲートウェイ間で構成するネットワーク。
ここでは次の技術を使う。

Wi-Fi(IEEE 802.11 b/g/n a/ac)

特に説明不要なほど普及した無線技術。2.4GHzか5GHzを使う。
ただしこれを使ってセンサーデータを送信することはほぼないはず。電力消費が大きすぎる。
ゲートウェイとWi-Fiルータを接続するなど、補助的に使われる。

Bluetooth(IEEE 802.15.1)

2.4GHz帯の無線技術。最新バージョンは Bluetooth 4.0。
通信距離が数10mだが指向性が高く電力消費が大きい。
マスタースレーブ方式でスレーブ数が最大でも7個と少ないため、センサーデータの送信には向かない。
後述するBLEを使った方がよいだろう。

2014/12に 4.2 が発表された。これによりIPv6/6LoWPANがサポートされる。

BLE(Bluetooth Low Energy)

Bluetooth 4.0の一部。徹底的な省電力を目指した規格で、ほぼ別物と考えた方がよい。
特徴はBluetoothと同様だが、iBeaconなど面白い使い方ができるので、センサーデバイスを
多数制御できればデファクトになるかも。

Zigbee(IEEE 802.15.4)

2.4GHz帯の無線技術。コーディネーター、ルーター、エンドデバイスで構成され、複雑なルーティング解決が必要とされるメッシュネットワークが利用可能。
セオリー的には、センサーがエンドデバイス、ゲートウェイがコーディネーターとなる。
電力消費も少ないため、現状かなり有力な技術。

Zigbeeには4種類あり、Zigbee/Zigbee PRO/Zigbee Green Power/Zigbee IPがある。
無印とPROはバッテリーが必要だが、Green PowerはEnOceanのようにバッテリーレスで動作する。
なお、Zigbeeはアドレスとして IEEE 64bit アドレスを持つが、 Zigbee IPはIPv6のアドレスを持つ。

※ IEEE 802.15.4 はZigbeeのベースとなる規格で、802.15.4 をベースにしたZigbee以外の規格も存在する。
※Zigbee IPは920MHzでも動作する。

EnOcean

最大の特徴はエナジーハーベスト。ソーラーで発電したり、スイッチの押下で起電する。
IoT/M2Mというキーワードで語るより、HEMS/BEMSというキーワードで語られることが多い。

Wi-SUN(Wireless Smart Utility Network)

920MHz帯の無線技術。日本発のスマートグリッド向け国際規格でもある。
Zigbeeと同じ IEEE802.15.4 をベースにしており(802.15.4g)、メッシュ状のネットワークを構成するため、
通信距離が長い。機器同士でも500m程度届くため、最大で数Km届く。
電池持ちに関しても、単3乾電池3本で10年以上動作するなど非常に良い。

※以下はかなり個人的な意見
東京電力のスマートメーターと宅内HEMSコントローラ間(通称Bルート)の通信規格に
採用されたため、同規格を推進しているWi-SUNアライアンスの鼻息も荒い。

スマートメーターと電力網(通称Aルート)や宅内無線、スマホにもWi-SUNが採用されるだろう、と
Wi-SUNアライアンスは強気だが、そもそもHEMSコントローラが家庭に導入される事がかなり疑問。
(電力消費量が家庭内で見れてうれしいだろうか?そのために安くない金額を出すだろうか?)
Wi-Fi機器を駆逐してまで、通信速度で数段劣るWi-SUN機器を導入するとは考えにくい。
国内市場だけを見てWi-SUN対応を進めていたら、海外ではWi-Fi対応機器が主流になり、
世界から取り残されていた、ともなりかねない。
技術的にはかなり良いものなので、Wi-Fiとの共存を目指してほしいところ。

ゲートウェイ

M2Mゲートウェイと呼ばれることが多いが、IoTゲートウェイの方が妥当な名前かも。
安価なボードコンピュータを使ったものや、ベンダ独自のアプライアンスが使われる。
ボードコンピュータには

があり、アプライアンスでもぷらっとホームのように Intel Edison ベースのものもある。

OSには独自のものもあるが、ほとんどLinuxベース。.NET Micro Framework やWindows EmbbededなどMS系もあることはあるが、ほとんど使われない。GUIが必要になることはないので、おとなしくLinuxを使った方がよい。

Web技術

モノがデータを送信する先はインターネットであり、クラウドやWebAPIといった技術も外せない。
ここに関しては各ベンダいろいろ模索している段階だろう。IBMのようにMQTTブローカーをアプライアンスとして提供するベンダもある。現状はデータ格納場所として機能するサービスが一部企業から提供されているだけにとどまっている。

SOA/Microservices

データを格納したあとはいかのそのデータを活用するかであり、ここからはWebサービス/WebAPIをいかに組み合わせるかが重要になる。
SOAの夢再び、という感じもしなくもないが、現在はMicroservicesといった方がよいかもしれない。
重厚長大なSOAでなく、Microservicesでライトに連携するのがトレンドかも。

プロトコル

IoT/M2Mで主に使われる通信プロトコルは次の3つ。

  • MQTT
  • HTTP(REST)
  • CoAP

個人的にはMQTT/RESTだけ押さえておけばいいかな、という感じ。
モノとインターネットではMQTTを使えばいいし、インターネットより上のレイヤでは通常のWebAPIの連携になるのでHTTP/RESTを使えばいいだろう。CoAPはUDPベースなので比較的信頼性の低い通信回線を使うIoTで選択することはないと思う。

HTTPではなくMQTTを使うメリットとしては、

  • MQTTはHTTPに比べて軽量
  • インターネット側からモノに通信したい場合、HTTPではモノ側にグローバルIPが必要になるがMQTTでは不要
  • MQTTはコネクションを確立し続けるので、通信がほぼリアルタイム

がある。あとはQoSやWill/Retainなどの便利な仕組みも捨てがたい。
人間が使う前提のHTTPよりも、IoTを前提に作られたMQTTの方が向いてるはず。

代表的なMQTTブローカーはこれくらい?

その他キーワード

思いついたら追記する。