こんにちは!
機械とAIが繋がるスマートな製造現場を作っているEdgeCrossです。
この記事では、より多くの方にAIとIoT技術について、分かりやすくお伝えするためにどのような技術がどう変化しているのか、また、その技術が実際の現場ではどのように適用され、イノベーションを加速させているのかお伝えしていきたいと思います。
その第一弾として、実際のAIoT開発に欠かせないコアコンセプトであるMQTTをご紹介します。
IoTデータはどのようにして届くのでしょうか?
MQTTを説明する前に、まず、IoTセンサーで収集された温度などのデータが実際にどのようにユーザーに送信されるんかについて説明します。
機械からデータが収集され、クラウドに送信され、そのデータが再びユーザーに届くまでの過程を簡単に説明すると、以下の図のようになります。

1.デバイスに内蔵された温度センサーが周囲の温度値を測定します。
2.デバイスのファームウェアは、測定値をユーザーが理解できる特定のフォーマットに加工します。
3.加工されたデータは、クラウドのデータ収集ポイントに送信されます。
4.最終的に、クラウドは収集されたデータをユーザーに送ります。
このようなプロセスを通じて、デバイスがデータを目的地まで安全かつ効率的に転送するためには、以下の2つが必須です。
1) WifiやLTEのような信頼できるネットワーク技術
2) このようなネットワーク技術を通じてデータを伝送するためのIoTメッセージ伝送プロトコル
IoTメッセージ転送プロトコル MQTT
プロトコルとは、コンピュータ内部またはコンピュータ間でデータの交換方法を定義するルール体系を意味します。
では、IoTメッセージを送信するためのプロトコルにはどのようなものがあるのでしょうか?
IoTデバイスは一般的に小型で都市部のビル内から農村部まで様々な環境に配置されています。
そのため、これらの特性を考慮すると、安定した電源を供給するためにバッテリーを使用することが多いと言われています。
バッテリーで動作するデバイスは、低消費電力設計により、長時間の使用を可能としなければなりません。
つまり、低消費電力と低帯域幅でもIoTメッセージを送信できるプロトコルが必須ということです。
このため、一般的にWEB上でよく使われるHTTPは、IoTデバイスの通信には適していません。
IoTメッセージ送信プロトコルとしてMQTTとCoAPを主に使うことになります。
MQTTをもっと詳しく知る

MQTTはPublish-Subscribeメッセージプロトコルで、BrokerがPulisherとSubscriberの間を仲介します。
PublisherはBrokerが管理する特定のトピックでメッセージを発行し、Subscriberは関心のある特定のトピックで発行されたメッセージを購読する方式です。
Topicはメッセージを伝達する通路で、’/’を基準に階層的に表現されます。
例えば、sensor/temperature/room1、sensor/humidity/room1のように指定して使用します。
Topicを基準に複数のPublisherがメッセージを発行することができ、複数Subscriberがメッセージを購読して同時に同じメッセージを受信することができる構造です。
でも、もしPublisherが発行したメッセージがネットワーク上の問題でうまく配信されない場合はどうなるのでしょうか?
この場合は、QoSの設定値によって異なります。
QoSはメッセージング品質を保証するためのオプションで、MQTTは下記のように3つのQoS設定値を提供しています。
- QoS 0 (At most once) : メッセージは最大一度だけ転送されます。送信確認がないため、流失の可能性があります。
- QoS 1 (At least once) : メッセージは少なくとも一度以上送信されます。送信確認を行いますが、重複して転送される可能性があります。
- QoS 2 (Exactly once) : 正確に1回の転送を保証します。ただし、伝送遅延の可能性があります。
MQTTとは、HTTPと何が違うのでしょうか?
最も一般的によく知られているHTTPとはどう違うのでしょうか?
MQTTとHTTPの違いを比較整理してみると、なぜMQTTがIoT環境でMQTTが適切なプロトコルであるかをより明確に理解することができます。
1.ヘッダーサイズ:MQTTのヘッダーサイズは非常に小さいです。最小ヘッダーサイズは2バイトですが、HTTPのヘッダーは一般的に数百バイトに達することもあります。これは、MQTTがはるかに少ない量のデータを送信できることを意味します。
2.プロトコルの複雑さ: HTTPはテキストベースのプロトコルであり、比較的複雑なリクエスト-レスポンスパターンを使用します。一方、MQTTはシンプルなパブリッシュ-サブスクリプションモデルを使用しているため、プロトコル処理に必要な計算量を減らすことができます。
3.永続的な接続:MQTTは永続的な接続を維持し、1回の接続設定後に複数のメッセージを送信することができます。一方、HTTPは通常、リクエストごとに新しい接続を必要とします(ただし、HTTP/1.1とHTTP/2は接続の再利用と多重化をサポートしています)。この違いは、MQTTがネットワークオーバーヘッドに関してより効率的であることを意味します。
4.メッセージ配信保証(QoS)オプション:MQTTは様々なレベルのメッセージ配信保証を提供します。これにより、必要に応じてネットワーク帯域幅と電力消費を最適化することができます。HTTPはこのような柔軟性を提供しません。 MQTTは、メッセージ配信の信頼性を保証するために様々なQoSレベルを提供します。
例えば、QoS 0は、メッセージが最大1回のみ転送されることを意味し(最小限のオーバーヘッド)、QoS 1は、メッセージが少なくとも1回転送されることを保証し、QoS 2は、メッセージが正確に1回転送されることを保証します(最も高いオーバーヘッド)。
5.リアルタイム通信:MQTTはリアルタイム通信に最適化されており、非常に低い遅延時間を提供します。HTTPはポーリング方式を使用することが多く、リアルタイム通信には非効率的な場合があります。
6.テキスト対バイナリプロトコル:HTTPは基本的にテキストベースであり、バイナリデータをbase64でエンコードする必要があります。 一方、MQTTはバイナリプロトコルであり、同じ情報を表現するのに必要なデータが少なくなります。
MQTTについてのまとめ
EdgeCrossは低電力と低帯域幅などの限界を超え、各種IoTデータを信頼性の高いMQTTプロトコルを使用して収集しています。
その中でもQoS 0方式で可能な限り軽量化し、リアルタイムでデータを早くユーザーに伝達しています。
(もちろん、場合によっては漏れのない伝送のためにQoS 1方式も一緒に使用しています)。
EdgeCrossと一緒にIoTデータをリアルタイムで収集してモニタリングしてみてませんか?
EdgeCrossのソリューションをもっと詳しく知りたい方は、以下のリンクからEdgeCross公式ホームページをご参照ください。