127
130

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

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

Last updated at Posted at 2014-10-03

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

その他キーワード

思いついたら追記する。

127
130
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
127
130

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?