IoT/M2M の覚え書き 2016年05月版

下記の記事の 2016 年 05 月版
- [IoT/M2Mについての覚え書き - Qiita](http://qiita.com/toruuetani/items/cb85781e127b2959c1c3)
- [IoT/M2Mについての覚え書き 2015年5月版 - Qiita](http://qiita.com/toruuetani/items/71ffd5a723075de07e3b)

# IoT の構成要素
IoT を構成する要素は次の通り。

- デバイス
- ゲートウェイ
- インターネット回線
- IoT プラットフォーム

# デバイス
ここではセンサーなどのモニタリング用のデバイスが用いられる。広義だとスマホも含めてもよいだろう。
センサーなどは直接インターネットにデータを送れないため、ゲートウェイなどの助けを借りることになる。
その時には以下のようなプロトコルを使って通信する。

## Bluetooth
IEEE802.15.1。2.4GHzを使うプロトコル。
コンピューターの周辺機器でよく使用される。Ver.2.x ～ 4.x まである。最新はVer.4.2。
Ver.4.0で統合されたBLEに主役を譲りつつある。IoT向けには後述するBLEを使うことになるだろう。

## Bluetooth Low Energy ( BLE )
IEEE802.15.1。2.4GHzを使うプロトコル。Bluetoothと互換性はない。
Bluetooth Ver.4.0 で全く別のプロトコルWibreeを統合して誕生した。
徹底した省電力が特徴で、セントラルを中心にペリフェラルがスター接続を構成する。
Apple の iBeacon や Google の Eddystone などのビーコンが使うプロトコルでもある。

## DECT
1.9GHzを使うプロトコル。
デジタルコードレス電話機向けのプロトコルで、ホームセキュリティ向けに使われる。
日本では Panasonic が製品を出しているくらいで特に普及は進まないだろう。

## Dust Network
2.4GHzを使う無線プロトコル。
メッシュを構築するため、切れない無線とアピールしている。
日本国内ではまだまだ実績はないが、海外ではそれなりに普及しているらしい。

## ECHONET Lite
日本発のスマートホーム向けプロトコル。プロトコルスタックの上位層だけを指定しており、
下位層は特に指定はない。指定はないが、後述する Wi-SUN が既定路線だろう。
経産省に日本国内でのHEMS標準プロトコルとして認定されている。

## EnOcean
920MHz帯を使う無線プロトコル。
日本で 920MHz が許可される以前は 315MHz を使用していた。
最大の特徴はエナジーハーベストで、バッテリーレスのセンサーを実現可能である。
また、この技術は特許を取得しているため、他の技術ではエナジーハーベストを基本的に実現できない。

## IPv6/6LowPAN
6LoWPAN(シックスロウパン)はIPv6 over Low power Wireless Personal Area Networksの略。
ZigBeeと同じ IEEE802.15.4をベースにしている。 Bluetooth が 4.2 でサポートしたり、 ZigBee IP がサポートしたりと IoT 関連でよく見るプロトコル。
このプロトコルは他のプロトコルと異なり、OSI参照モデルのネットワーク層を相当する。

## LoRa
920MHzを使う無線プロトコル。
低消費電力で長距離通信が特徴のLPWA(Low Power Wide Area Network)の１つ。
携帯電話網も届かない僻地や、広大な施設でセンサーをばらまく必要がある場合に向いている。
日本ではSORACOMが出資したことで注目度があがったプロトコル。

## SigFox
920MHzを使う無線プロトコル。LPWAの１つ。
日本ではドコモベンチャーズが出資しているが、そこまで存在感は出せていない。

## Sub-Giga
920MHz帯を使う無線プロトコル。特小とも言われる。
特定のプロトコルではなく、この周波数を使うプロトコルを総称するときに使う。
この周波数帯は回り込み特性があるため、2.4GHzなどに比べると長距離まで届く。
また、メッシュネットワークを構成することでさらに長距離まで届くのが特徴。
ただし、どれもオレオレプロトコルであるため、爆発的な普及は難しいだろう。

## Thread
Google傘下のnestが策定したプロトコル。
OSI参照モデルのネットワーク層とトランスポート層を担当し、下位２層はZigBeeを採用する。
上位のアプリケーション層は指定しておらず、ZigBee/Alljoyn/HomeKit/nest Weave/ECHONETなどを想定する。
メッシュネットワーク、IPコネクティビティ、金融サービスレベルのセキュリティが特徴。
ZigBeeデバイスのリプレースができれば普及するかもしれない。

## Weave 
Google の IoT 向け OS Brillo を搭載したデバイス同士で通信するためのプロトコル。
無線と思われるが、情報がないため不明。
Google 製なのである程度普及すると思われるが、現時点では何とも言えない。 Nest と絡ませてくると普及するかもしれない。

## Wi-Fi
IEEE 802.11 b/g/n a/n/ac。2.4GHzを使う b/g/n と 5GHz を使う a/n/ac に分かれる。
センサーデバイスに使われることはまれな無線プロトコル。
有線LANの代わりに利用されたり、ゲートウェイとクラウドの接続に利用される。

## Wi-Fi HaLow
920MHz帯の無線プロトコル。IEEE 802.11 ah。Wi-Fiアライアンスが策定したIoT向けプロトコル。
低消費電力と回り込みを生かした接続性が特徴。またWi-Fiと同様にIPをサポートする。
すでに普及しているWi-Fiルータの次世代機などに搭載されることが予想されるため、
ある程度の普及は約束されていると思われる。

## Wi-SUN
920MHz帯の無線プロトコル。
日本発のスマートグリッド向け国際規格でもある。
ZigBee と同じ IEEE802.15.4 をベースにしており（802.15.4g）、メッシュ状のネットワークを構成するため、通信距離が長い。
東京電力のスマートメーターと宅内HEMSコントローラ間（通称Bルート、スマートメーターと電力網は通称Aルート）の通信規格に採用された。

## ZigBee
2.4GHzを使う無線プロトコル（ZigBee IPは920MHz）。コーディネーター、ルーター、エンドデバイスで構成され、複雑なルーティング解決が必要とされるメッシュネットワークが利用可能。
ZigBee には 無印/PRO/Green Power/IP の4種類がある。現在使用されているのはPROとなる。 ZigBee Green Power はエナジーハーベスト規格であり、 EnOcean にライセンス料を払うことで実現している。
現在日本国内では 2.4GHz のものしか存在しない。
欧州、アメリカではそれなりに普及しているが、日本では普及しているとは言い難い。
現在 Ver.3.0 を策定中だが、前述した Thread にとってかわられる可能性も高い。

## Z-Wave
920MHzを使う無線プロトコル。
海外ではそれなりに普及しているようだが、日本国内では使われていない。

## その他
以下のようなフィールドネットワークプロトコルもあるが、特に IoT 向けというわけではないので省略する。

- CCLink/IE
- EtherCAT
- Modbus

## まとめ
デファクトスタンダードといえるプロトコルは存在しない。今後もしばらくは難しいだろう。
まずは技術的課題を検討し、コスト課題を解決できるプロトコルを選ぶしかない。
それでも選べないのであれば、エコシステムを構築できているかどうかで選択すればよい。
IoTでは耐用年数が長くなることが想定されるので、継続して使うためには技術的優位性よりも
エコシステムを構築して長生きできるかどうかが重要となる。


# ゲートウェイ
デバイスから送信されたデータをIoTプラットフォームに中継するデバイスのこと。
大抵の場合は Linux ゲートウェイが採用される。

## [OpenBlocks IoT BX1](http://openblocks.plathome.co.jp/products/obs_iot/bx1/)
Intel Edisonを搭載した小型ゲートウェイ。VCCI ClassBを取得しており、家庭内への設置も可能。
小型ゆえに特殊コネクタを採用しており、そこが惜しい。
BLE以外のプロトコルを使いたい場合は後述する EX1 の方が良いかもしれない。
Atom/Edisonの廃止がニュースになる前であればかなり有力候補だった。
linux kernel も 3.10 であり、これ以上の更新はむずかしい。
後継機種がどうなるかで採用するかどうか決定したほうがよいだろう。

## [OpenBlocks IoT EX1](http://openblocks.plathome.co.jp/products/obs_iot/ex1/)
前述したBX1に拡張性をもたせたゲートウェイ。
有線LAN、RS232C、EnOCean、Wi-SUNを使いたい場合などに選択肢となりえる。
ただし、これもIntelの方針次第かもしれない。

## [Armadillo-IoT](http://armadillo.atmark-techno.com/armadillo-iot)
新し目の linux kernel と拡張性を備えたゲートウェイ。
Wi-Fi/BLE/Wi-SUN/EnOcean/Dust Networks/Sug-Giga とオプションで様々なプロトコルに
対応可能で、ここまで拡張性が高いものは存在しない。

## [GX110](http://www.sun-denshi.co.jp/sc/gx110/)
耐環境性に優れたゲートウェイ。
屋外設置する場合に選択肢の上位に上ってくるだろう。
ただし、発売時期が2013年と古く linux kernel も 2.6 なため、そこがネックとなる。

## まとめ
上記以外にもゲートウェイは存在するが、今の所選択肢はこれくらいだろう。
Windowsを採用するメリットはなく、Androidも更新サイクルが早すぎる。
組込OSはクラウドとの親和性が低すぎるため、事実上 linux しか採用できない。


# インターネット回線
必要な回線帯域によって選択することになると思われる。
ある程度太い帯域が必要なら有線インターネット回線、Wi-Fiなどを採用すればよい。
ただし、Wi-Fiは民生品だと接続が不安定になることもあるため、企業向けを採用すべき。
それほど帯域が必要ないのであれば携帯電話網を使う。
ドコモ・au・ソフトバンクなどのキャリアやMVNOといった選択肢があるが、SORACOMが最有力。
AWSへの親和性やセキュリティの高さ、IoT向けに練られたサービスは他にはない。


# IoT プラットフォーム
最近は IoT プラットフォームが乱立しているため、次の機能を満たしているかどうかで選択する。

- データハブ機能
  - デバイス側からインターネット側へ送信されたデータのエンドポイント
  - インターネット側からデバイス側へのフィードバックのエンドポイント
- データ蓄積機能
  - デバイスから送信されたデータを蓄積し、取り出すことが可能
- ビジュアライズ機能
  - 蓄積されたデータをもとにグラフなどでわかりやすく表示
  - 分析結果などをわかりやすく表示
- フィードバック機能
  - インターネット側からデバイス側へコマンドを送信
  - 分析結果をもとに最適化された動作を指示
- 分析機能
  - IoTの主要機能というべき機能
  - 蓄積されたデータをもとに傾向を把握したり、未来を予測する機能

各社さまざまな機能を搭載してはいるが、上記全てを満たしたものは存在しないはず。
まだまだ過渡期なので、出来合いのIoTプラットフォームは時期尚早と思われる。
AWSなどが提供している各種クラウドサービスを組み合わせて自社向けに構築するのがよいかもしれない。