IoTの構成要素（★）
[IoT製品・IoTサービスの開発依頼とコンサルティングは、フィールドデザインまでお気軽にお問い合わせください。このコラムで紹介されている技術はすべて弊社にて開発可能なものです。]
この項目は一般的に説明されていることですので、簡単に説明します。
全体の構成(★)
IoTの全体の構成からわかるように、主な構成要素としては次のものがあります。
- IoTデバイス
- IoTゲートウェイ
- サーバ(DB含む)
IoTデバイスの動作としては、大きく分けて２種類あります。これらの違いによって、セキュリティ上のリスクが大きく異なります。
- IoTデバイスがIoTゲートウェイにてプロトコル変換をし、インターネットを通しサーバにアクセスする
- IoTデバイスがIPプロトコルを使い、Wi-Fiやセルラー網を使い、インターネットを通しサーバにアクセスする
IoTデバイス
IoTデバイスは、通常、入力部（センサー）と出力部（アクチュエーター）と通信部からなります。
通常、マイコン(MCU,ECU,マイクロプロセッサー等)と呼ばれる動作周波数が低く（10MHzから100MHz）、低消費電力(10mW程度)のプロセッサでセンサーやアクチュエーターを制御しています。
また、IoTデバイスのマイコンは、OSがないものや、リアルタイムOSで動作するものがほとんどです。
入力部の例としては下記のようなものがあります。
- カメラ
- 温度・湿度
- GPS
- 圧力、ひずみ
- 音、振動
出力部の例としては下記のようなものがあります。
- モーター
- ライト
- ディスプレイ
- スピーカー
IoTゲートウェイ(★)
IoTゲートウェイは、通信部のみからなります。
IoTデバイスによっては、IPプロトコルで通信する方法を持たないため、直接インターネットにはアクセスできません。
IoTゲートウェイは、IoTデバイスの通信データをIPプロトコルに変換することで、IoTデバイスの情報をサーバに届けます。
その際、IoTデバイスのデータをまとめたり、演算したりすることも行います。
IoTで使われるネットワーク(★)
IoTデバイスで使われるネットワークの物理層としては下記のものがあります。
無線ネットワークとしては下記のものがあります。
| 名称 | 周波数 | 通信速度 | 通信距離 | その他 |
|---|---|---|---|---|
| Bluetooth | 2.4GHz | 2Mbps | 30m(2MPHY)/ 500m(CodedPHY) | 低消費電力。ピーク電力小さい。 |
| Wi-Fi | 2.4GHz/5GHz | 9.6Gbps | 100mから1km 通信速度に依存 | 消費電力多い |
| Zigbee | 2.4GHz | 250kbps | 50m | 低消費電力。ほとんど使われてない。 |
| LTE (CAT-M1) | LTEバンド内 | DL300kbps/ UL375kbps | 10km | 低消費電力。移動可能。 |
| LTE (CAT-NB1) | LTEバンド内 | DL21kbps/ UL62kbps | 10km | 低消費電力。ハンドオーバないため移動不向き。 |
| LoRa | 920MHz | 50kbps | 10km | 低消費電力。免許不要帯域のため通信品質を保つのが難しい。 |
920MHz帯の通信は、距離が10km以上も飛ぶにもかかわらず、キャリアセンス以外の混信の制御（管理）をしていないことから、市街地では信頼できる通信としては使えません。Ack付きのプロトコルなら、いつかは通信ができるかもしれませんが、その間にかかる電力は膨大になり、電池駆動の製品なら電池がなくなってしまいます。セキュリティを考える以前の問題です。市街地では、セルラー系(LTE)を利用した方が無難です。
有線ネットワークとしては下記のものがあります。
| 名称 | 通信速度 | その他 |
|---|---|---|
| Ethernet | 10Mbpsから10Gbps | IEEE802.3で規定。通常ペイロードは1500Byte。アクセスはCSMA/CD方式。 |
| CAN | 10kbpsから1Mbps | 自動車やロボットなどで利用。通常、識別子11bit、ペイロード8Byte。アクセスはCSMA/CA方式。 |
サーバで使われる通信プロトコル(★)
サーバはインターネットに接続されているため、IP層以上の通信プロトコルを利用して、IoTデバイスとデータのやり取りをします。
以下で挙げるものは、IoTデバイスとサーバが直接通信する場合のプロトコルです。
IoTゲートウェイを間に入れるのでしたら、あえてややこしいことはせずに、HTTPを使うのが通常です。
なお、ユーザーからサーバへのアクセスはブラウザにより行われますので、HTTP一択となります（WebSocketもブラウザで使えないことはないですが、通知でしたら、HTTPのServer Sent Eventsでも同じことができます）。
| 名称 | レイヤ | 説明 |
|---|---|---|
| UDP | IP上のプロトコル | オーバーヘッドが少なく高速リアルタイム通信に向く。SSL(TLS)による暗号化可能(DTLS)。 |
| TCP | IP上のプロトコル | Ackがあるため信頼性のある通信に向く。 |
| HTTP | TCP/IP上のプロトコル | SSL(TLS)による暗号化可能(HTTPS)。 |
| MQTT | TCP/IP上のプロトコル | 軽量で、HTTPよりオーバーヘッドは少ない。SSL(TLS)による暗号化可能(MQTTS)。サーバからクライアントへの通知が可能。 |
| CoAP | UDP/IP上のプロトコル | 軽量で、ほぼHTTPと同じ動作をする。DTLS上での実装により暗号化も可能。 |
| WebSocket | TCP/IP上のプロトコル | HTTPとは違い、サーバからクライアントへの通知が可能。コネクションを常に張るため、負荷が大きい。 |
結局、プロトコルの優位性よりも、開発工数、セキュリティ面、保守性を考えると、HTTPを使うのが無難です。
そもそも企業のFirewallがHTTPしか通さないようになっているケースもあり、HTTPしか選べないこともあります。
また、ごく稀に、動画関連など、リアルタイム性が必要な場合などは、UDPを使うケースはあると思います。
IoTプラットフォーム(★)
IoTサービスに関して、サーバで処理される内容は共通している項目が多くあります。その共通項目をまとめてプラットフォームとして提供しているベンダーもあります。
IoTプラットフォームの機能は下記のものがあります。
- デバイス認証、ユーザー認証
- データ管理（保存、加工、分析、転送）
- ユーザー管理（課金）
- デバイス制御
- ユーザーインターフェイス（データ表示、データ通知、データ入力）
IoTプラットフォームの機能内でIoTサービスを構築できる場合は、短期間で運用を開始できます。
また、セキュリティも高いため、セキュリティ知識がない企業が独自開発するよりは、はるかに安全です。
しかし、IoTプラットフォームの機能をそのまま使えない場合は、その部分は独自に開発することになります。
IoTプラットフォームの機能は、それほど複雑なものでもないため、独自開発の方が自由度があってよいと思います。
主なプラットフォームとしては、下記のものがあります。
- AWS IoT
- Azure IoT
- Soracom(Air,Harvest)（セルラー回線経由のみ）
上記以外にもありますが、アプリケーションの分野が限定的だったり、カスタマイズ(System Integration)前提だったり、プラットフォームと呼ぶことが難しいものばかりですので、除いています。