IIoT(産業用Internet of Things)は、OT(Operation Technology)マシンとデバイスをIT(Information Technology)システムに接続することでデジタルトランスフォーメーションを可能にします。これにより、新しい価値の追加やスマートマニュファクチャリング、スマートエネルギーといった、異なる産業への新しい利点を提供します。
このデジタルトランスフォーメーション革命の中で、IIoTアプリケーションはエッジデバイスをクラウドアプリケーションと統合するためにより多くの帯域幅を必要とすることから、コネクティビティが重要な役割を果たしています。さらに、エンジニアは、異なる産業用プロトコルを使用する数十万のデバイスを接続する方法を学ぶ必要があり、多くのデバイスがインターネットに接続されるのに伴い、セキュリティ問題を管理する必要が生じます。
IIoTの新しい開発に対応するために、多くの新しいコネクティビティ技術が登場しました。例えば、標準イーサネットネットワークを介した確定的なデータの伝送を可能にするために、IEEE (Institute of Electrical and Electronic Engineers) が定義したイーサネットの拡張規格 TSN (Time-Sensitive Network) が開発されました。また、OPC UAは、製造現場の異なるデバイス間で異なる言語を統合することに焦点を当てています。その中で最も重要なことは、MQTT (Message Queuing Telemetry Transport) が、マシン・ツー・マシン通信 またはエッジからクラウドおよびエンタープライズシステムにデータを取り込むことを可能にするために優先されるpublishおよびsubscribeメッセージングプロトコルとして登場したことです。
自動化エンジニアがデータ収集およびデータ解析のためにセンサ、マシン、またはエッジコンピュータをクラウドに接続する場合、インターネットを介した一般的な通信プロトコルはHTTP/HTTPです。このプロトコルは、コンピュータネットワークおよびインターネットで広範に使用されています。しかしながら、HTTP/HTTPSはrequest-response(要求/応答)パターンプロトコルと呼ばれ、クライアントとサーバの両方を同時にオンラインにして、データを正常に送受信できることが必要です。太陽光発電所、上下水道マネージメントプラント、石油パイプラインといったIIoTアプリケーションの場合においては、デバイスが必要なデータを受信するためにネットワークとの十分に強固なコネクションを維持することが不可能な場合があります。従って、このrequest-responseパターンはこのようなアプリケーションには適していません。
MQTTは、1999年にIBMとCirrus Linkによって最初に開発され、2013年にISO標準として承認されました。このMQTTは、砂漠の石油パイプラインからデータを送信するために設計されているため、帯域幅効率、軽量、低バッテリー消費が必要とされました。MQTTのpublish-subscribeパターンは、デバイスが同時にネットワークに接続されることが保証されていない状況を考慮してカスタマイズされています。
HTTP/HTTPと比較すると、MQTTはpublish-subscribeパターン(下図を参照)を使用してメッセージを交換します。図に示すように、MQTTシステムは、1つのbrokerと複数のクライアントで構成され、クライアントはpublisherまたはsubscriberのいずれかとなります。Publisherは、topic(トピック)とpayload(ペイロード)で構成されるMQTTパケットフォームでデータをbrokerに送信します。次に、brokerは、関心を示したtopicに基づいて、subscriberにデータを転送します。
他のプロトコルと比較して、MQTTは、IoTアプリケーションに最適にマッチする他の利点を提供します。
利点は次のとおりです:
MQTTの詳細については、ホワイトペーパー「MQTT-IIoT時代において、いま見直されるM2M通信に最適なMQTTプロトコルによるエッジデバイスコネクティビティの実現」をご覧ください。
MQTTプロトコルは30年近く前から知られていましたが、このプロトコルはオートメーションエンジニアリングの最新の動向であるIIoTアプリケーションに最適な設計がされています。MQTTは、デバイスが定期的にポーリングする"パッシブ通知"とは対照的に、デバイスが必要なときにだけデータを提供する"アクティブ通知"を強調するアプリケーションに特に当てはまります。MQTTのブローカー/クライアント設計により、システム内のすべてのデバイスを同時にオンラインにする必要がなくなります。クライアント("デバイス" または "モノ")はブローカーと直接通信し、クライアント間でメッセージをやり取りする仲介者の役割を果たします。