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

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

2015年5月時点の知識で書き直した。⇒ [IoT/M2Mについての覚え書き 2015年5月版 - Qiita](http://qiita.com/toruuetani/items/71ffd5a723075de07e3b)


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

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

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

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

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

* [ZigBee](http://www.zbsigj.org/)
  * [NETVOX](http://www.netvox.com.tw/)
* [EnOcean](http://www.enocean.com/jp/home/)
  * [EnOcean製品のご紹介 | ローム 半導体 ROHM](http://www.rohm.co.jp/web/japan/enocean)
  * [EnOcean GmbH社製品 - アーミン株式会社](http://www.ermine.co.jp/goodsindex3001.html)
  * [電源不要のセンサー・スイッチのアーミン・シリーズ](http://www.ermine.biz/)
* [Z-Wave](http://www.z-wavealliance.org/)
  * 日本国内ではほぼ普及していない。 


## 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。
通信距離が数10ｍだが指向性が高く電力消費が大きい。
マスタースレーブ方式でスレーブ数が最大でも７個と少ないため、センサーデータの送信には向かない。
後述する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）、メッシュ状のネットワークを構成するため、
通信距離が長い。機器同士でも５００ｍ程度届くため、最大で数Kｍ届く。
電池持ちに関しても、単3乾電池3本で10年以上動作するなど非常に良い。

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

* http://eetimes.jp/ee/articles/1310/09/news098.html

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


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

* [Arduino](http://www.arduino.cc/)
* [Raspberry PI](http://www.raspberrypi.org/)
* [Beagle Bone](http://beagleboard.org/)
* [mbed](https://mbed.org/)
* [Intel Galileo](http://www.intel.co.jp/content/www/jp/ja/do-it-yourself/galileo-maker-quark-board.html)
* [Intel Edison](http://www.intel.co.jp/content/www/jp/ja/do-it-yourself/edison.html)
* [littleBits](http://jp.littlebits.com/)

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

* [ぷらっとホーム OpenBlocks IoT BX1](http://openblocks.plathome.co.jp/products/obs_a/bx1/)
* [Eurotech　ReliaGATE 15-10](http://eurotech.com/jp/products/ReliaGATE%2015-10)
* [オプション・ワイヤレス・ジャパン CloudGate](http://www.option-wireless.jp/prod_M2Mbox.html)
* [サン電子 GX110](http://www.sun-denshi.co.jp/sc/gx110/)
* [バレイキャンパスジャパン iNode](http://valleycampus.com/ja/?page_id=845)

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


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


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


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

* 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ブローカーはこれくらい？

* [An Open Source MQTT v3.1 Broker](http://mosquitto.org/)
* [株式会社時雨堂 sango](https://sango.shiguredo.jp/)
* [IBM MessageSight](http://www-03.ibm.com/software/products/ja/messagesight/)
* [インヴェンティット株式会社 ServiceSync](http://www.yourinventit.com/product/service_sync.html)



# その他キーワード
思いついたら追記する。

* HEMS(Home Energy Management System)
  * Z-Wave
* BEMS(Building Energy Management System)
  * [IEEE1888 - Wikipedia](http://ja.wikipedia.org/wiki/IEEE1888)(FIAP)
    * [IEEE1888(FIAP) - 東大グリーンＩＣＴプロジェクト](http://www.gutp.jp/fiap/) 
  * [BACnet - Wikipedia](http://ja.wikipedia.org/wiki/BACnet)
  * [LONWORKS - Wikipedia](http://ja.wikipedia.org/wiki/LONWORKS)
* 6LowPAN(IPv6 over Low power Wireless Personal Area Networks)
* ECHONET, ECHONET Lite
* VCCI class A(業務環境向け)/class B(家庭環境向け) 
* サブギガ帯
  920MHz帯のこと。2012/7より日本でも解禁になった。UHF帯RFIDもここに含まれる。