IoT/M2Mについての覚え書き - Qiita の2015年5月版
IoT/M2Mとは何か
もはや何でもかんでもとりあえず IoT と付けとけ、というくらいバズワードになりつつある。もはや M2M の出る幕はない。正確な定義はもう無意味なので、まとめて IoT でいいと思う。
どうしても区別したいのであれば、これくらいか。
- M2M は機械と機械が通信して何かを行うものであり、人間が介在しなくても処理が進んでいくシステムのことを言う。
- IoT はモノがインターネットに接続して情報をやり取りしたりして処理が進んでいくシステムのことを言う。最近はそれだけではなく、機械学習やビッグデータが絡んできて今まで分からなかった傾向などが把握できるようになり、人間が判断しなくても機械がいい感じに処理を進めてくれるシステムのことを言う。人間ががんばってると、その時点でそれは IoT とは言えない。
なぜ流行ってるか？
様々な技術革新による低価格化のため。
それからクラウドやビッグデータが一段落したので、次のバズワードに選ばれたのが大きい。もう流行ってるのは説明もいらないだろう。
要素技術
IoT/M2M に必要な技術は次の通り。
- デバイスプロトコル（デバイスとゲートウェイ間に使うプロトコル）
- ゲートウェイ
- ゲートウェイプロトコル（ゲートウェイとクラウド間に使うプロトコル）
- クラウド
- ビッグデータ解析基盤
とにかく要素技術が多く、ある技術を提供しているベンダーが隣の技術のことを知らないことも多い。したがって要素技術をいかにインテグレーションするかが肝心となる。
現状クラウドやビッグデータ解析基盤に IoT/M2M 特有の事情はないので、通常の Web サービスを構築するのと変わりない。
そのため、それ以外の要素技術についてだけ記述する。
デバイスプロトコル
デバイスプロトコルは有線と無線に分かれる。有線プロトコルは信頼性を求める場面で利用され、無線プロトコルは信頼性より利便性を求める場面で利用される。無線プロトコルの多くは周波数に2.4GHz、920MHz帯を使う。
BACnet
インテリジェントビル用ネットワークのための有線プロトコル。
（個人的な見解）
今はまだ IoT に絡んできていないが、避けては通れないと思われる。
BLE(Bluetooth Low Energy)
2.4Ghzを使う無線プロトコル。
後述する Bluetooth の一部として Ver.4.0 でリリースされた無線プロトコル。徹底した省電力が特徴。Bluetooth 3.0 までのクラシック Bluetooth と互換性はない。Apple の iBeacon はアドバタイズに特化した BLE デバイスと言える。
BLE の互換性を示すブランディングとして「Bluetooth Smart」という名前がある。
（個人的な見解）
iOS や Android でサポートされているため、既にかなり普及している。IoT 向けの最有力プロトコルだろう。
Bluetooth / IEEE 802.15.1
2.4Ghzを使う無線プロトコル。
ブランディングとしては「Bleutooth Smart Ready」という名前がある。
（個人的な見解）
IoT 向けには前述の BLE だけ抑えておけば良い。
CC-Link
FA市場向けのフィールドネットワークのための有線プロトコル。
（個人的な見解）
これも工場などを IoT 化するためには避けては通れない。
DICOM
医用画像機器間の通信プロトコルを定義した有線プロトコル。
（個人的な見解）
これもいずれ IoT 化するために避けて通れない。
Dust Networks / IEEE 802.15.4
2.4GHzを使う無線プロトコル。
メッシュを構築するため、切れない無線とアピールしている。日本国内ではまだまだ実績はないが、海外ではそれなりに普及しているらしい。
（個人的な見解）
まだそれほど注目する理由はない。
ECHONET Lite
日本発のスマートホーム向けプロトコル。 ECHONET Lite はプロトコルスタックの上位層だけを指定しており、下位層は特に指定はない。
経産省に日本国内でのHEMS標準プロトコルとして認定されている。
（個人的な見解）
プロトコルスタックの下位層は Wi-SUN がほぼ既定路線。 ZigBee IP でもよいはずだが可能性は低いだろう。家電製品の最上位機種などに対応しているものがあるが、既存の家電と連携できない。そのため魅力がほとんどないため、それほど普及するとは思えない。
EnOcean
920MHz帯を使った無線プロトコル。
日本で 920MHz が許可される以前は 315MHz を使用していた。最大の特徴はエナジーハーベストで、バッテリーレスのセンサーを実現可能である。また、この技術は特許を取得しているため、他の技術ではエナジーハーベストを基本的に実現できない。
（個人的な見解）
バッテリーレスがかなり魅力。センサーデバイスさえ揃えばかなり有力だろう。
FIAP / IEEE1888
次世代BEMSやスマートグリッド向けに開発されたプロトコル。
東大グリーンICTプロジェクトが関与していて、プロトコルというよりはフレームワークといった方が良い。
（個人的な見解）
複雑すぎて普及するとは考えにくい。
IEEE 802.15.4
920MHz/2.4GHz帯の無線プロトコルの物理層。 ZigBee や Wi-SUN などのベースとなっている。これを使って無線プロトコルを独自に開発しているベンダーも存在する。
（個人的な見解）
独自プロトコルが普及するとは考えにくい。
MQTT-SN
後述するプロトコル MQTT のセンサーデバイス向けプロトコル。特に物理層は指定していない。
（個人的な見解）
MQTT との親和性から今後の普及が期待される。
Wi-Fi / IEEE 802.11 b/g/n a/n/ac
2.4GHzを使う b/g/n と 5GHz を使う a/n/ac に分かれる。センサーデバイスに使われることはまれな無線プロトコル。有線LANの代わりに利用されたり、ゲートウェイとクラウドの接続に利用される。
（個人的な見解）
既に普及しているため、気にすることはないだろう。
Weave
Google の IoT 向け OS Brillo を搭載したデバイス同士で通信するためのプロトコル。無線と思われるが、情報がないため不明。
（個人的な見解）
Google 製なのである程度普及すると思われるが、現時点では何とも言えない。 Nest と絡ませてくると普及するかもしれない。その場合 Apple の HomeKit との競争になると思われる。スマートホーム向けはこのどちらかが勝者になるのではないか。
Wi-SUN
920MHz帯の無線プロトコル。
日本発のスマートグリッド向け国際規格でもある。ZigBee と同じ IEEE802.15.4 をベースにしており（802.15.4g）、メッシュ状のネットワークを構成するため、通信距離が長い。
東京電力のスマートメーターと宅内HEMSコントローラ間（通称Bルート、スマートメーターと電力網は通称Aルート）の通信規格に採用された。
（個人的な見解）
日本国内のスマートメーター向けとして普及はするかもしれない。ただし、そこだけ。
ECHONET Liteが普及すれば普及するのだろうが、前述の理由により普及しないだろう。
ZigBee / IEEE 802.15.4
2.4Ghzを使う無線プロトコル（ZigBee IPは920MHz）。コーディネーター、ルーター、エンドデバイスで構成され、複雑なルーティング解決が必要とされるメッシュネットワークが利用可能。
ZigBee には 無印/PRO/Green Power/IP の4種類がある。現在使用されているのはPROとなる。 ZigBee Green Power はエナジーハーベスト規格であり、 EnOcean にライセンス料を払うことで実現している。
現在日本国内では 2.4GHz のものしか存在しない。
（個人的な見解）
メッシュネットワークが魅力だが、センサーデバイスの少なさが災いしてイマイチ。
Z-Wave
サブギガ帯を使う無線プロトコル。
海外ではそれなりに普及しているようだが、日本国内では使われていない。
（個人的な見解）
特に注目しなくてもよいだろう。
サブギガ帯
1GHz以下（日本国内では920MHz帯）の周波数を使った無線プロトコル。
（個人的な見解）
各メーカーが独自に開発しており、互換性はない。それほど注目することはないと思われる。
IPv6 / 6LoWPAN
6LoWPAN(シックスロウパン)はIPv6 over Low power Wireless Personal Area Networksの略。ZigBeeと同じ IEEE802.15.4をベースにしている。 Bluetooth が 4.2 でサポートしたり、 ZigBee IP がサポートしたりと IoT 関連でよく見るプロトコル。
（個人的な見解）
ゲートウェイならともかく、デバイスが IPv6 を持つメリットはほとんどない。直接インターネットにつなぐことはセキュリティ上ありえないと思うからだ。そうなるとゲートウェイが何らかの変換をするので、 IPv6 である必然性はないと思われる。メリットはインターネット側から Bluetooth も ZigBee も同じように扱えるくらいか。特にこだわる必要はない。
技術標準適合
無線プロトコルを使うデバイスでは避けて通れない。輸入品などでは特に取得しているかの確認が重要。取得していない製品で電波を発信した場合は電波法違反となる。 JATE/TELEC 取得とあれば大丈夫。
もちろん海外でもその国の電波法があるので、その国で取得しなければならない。モジュールレベルで取得すればOKな国がほとんどだが、中国は製品レベルで取得しなければならない。海外でビジネスする場合は、その国で取得済みの製品を選択するとよいだろう。
VCCI
電波を発信するデバイスでは避けて通れない。発生するノイズの基準値を定めたもので、産業用のクラスAと家庭用のクラスBがある。クラスBの方が基準が厳しい。
アメリカの場合は FCC 、ヨーロッパの場合は EC となる。海外製品は大抵 FCC/EC のどちらかが表記されている。
まとめ
現時点で決定的なプロトコルはない。センサーデバイスが普及すればそのプロトコルが勝者となるかもしれないが、デバイスベンダーも様子見な状態。恐らく独り勝ちするプロトコルは当分出てこないだろう。
したがって要件に応じたセンサーデバイスを探してきて、コストに見合うかどうかで採用するか決めるしかない。
ゲートウェイ
Arduino や Raspberry Pi などのボードコンピュータを発展させたものもあるが、通常は Linux を搭載したゲートウェイを使う。
Windows IoT を搭載したゲートウェイも今後は出てくると思われるが、現時点では Raspberry Pi 2 Model B しか存在しない。
現在販売されているゲートウェイは次の通り。
（個人的な見解）
現時点でこれだというゲートウェイは存在しない。目的に応じて選択するしかないだろう。
ゲートウェイプロトコル
ゲートウェイからクラウドにデータを送信するために使われるプロトコルは次の通り。
AMQP(Advanced Message Queuing Protocol)
メッセージ指向のプロトコル。
（個人的な見解）
Azure の IoT 向けサービスで採用されていたりするが、メッセージキューのためのプロトコルなので、ゲートウェイが使うには大変だろう。
CoAP(Constrained Application Protocol)
簡易HTTPを目指したプロトコル。
（個人的な見解）
UDPベースだし、特に使う理由がない。
HTTP/REST
特に説明は必要ないだろう。
（個人的な見解）
双方向通信が必要ないならこれでもよい。クラウド側に通常の Web 技術が使えるため構築が容易だろう。
MQTT(MQ Telemetry Transport)
このあたりを参考に
（個人的な見解）
現時点では何も考えずにこれを使うのがベター。
WebSocket
ウェブサーバーとウェブブラウザとの間の通信のために規定された双方向通信用のプロトコル。
（個人的な見解）
ブラウザならともかく、ゲートウェイで使う理由はない。
まとめ
これといった決定打となる技術はないので、要件に応じて選択するしかない。まだまだどこも模索中だろう。
ボードコンピュータで趣味レベルの IoT は簡単になったが、業務として行う IoT を実現するのはかなりの困難を伴う。ただ IoT はかなり面白いので、一刻も早く成功事例が出てくるといいね。