Posts

IIoT Protocol Comparison

最適なIIoTプロトコルについて

IIoTシステムの構築の際に通信プロトコルの選定は重要なポイントであり、通信プロトコルは効果的なIIoTデータ通信を実現するための基礎(土台)になります。安全で堅牢なIIoT向けの通信プロトコルでなければ、データの遅延、欠落、矛盾が発生し、致命的なデータエラーを引き起こす可能性があり、そのためにエラーの解消作業などの時間の浪費となってコストをかけなければならなくなる懸念があります。

IIoTシステムの普及はまだまだ初期段階にあるために、IIoTシステムの検討時に多くの企業は、まずは使い慣れていて十分にテストされたデータ通信プロトコルとしてMQTTやAMQP、REST、OPC UAのような通信プロトコルに着目します。しかし、それぞれのプロトコルはもともとの目的を持って設計されておりその目的のためには有効かもしれませんが、どの通信プロトコルもIIoTシステムでのデータ通信をサポートするために設計されたものではありません。そのため、“堅牢で安全な産業向けのIoTシステムの実現“を基準に評価した場合には、これらの通信プロトコルは、すべてやや不十分と言えます。

SkkynetのソフトウェアとサービスはそもそもIIoTシステム向けに設計されており、最適なIIoTデータ通信のためのすべての基準を満たしています。ここでは、MQTT、AMQP、REST、OPC UA、およびSkkynet独自の DHTP (DataHub Transfer Protocol) について、IIoTシステムにおける最適な通信プロトコルとして上の表にある基準をどの程度満たしているかについて比較しています。 上記の各基準については、以降のセクションでさらに詳しく説明します。

DHTP Protocol Comparison - Closed Firewalls

いわゆるデータソースとデータユーザの両方に対して、ファイアウォールのすべての受信ポートを閉じたままにします。

DHTP Protocol Comparison - Closed Firewalls Diagram

工場等においてファイアウォールのすべての受信ポートを閉じたままにしておく事は、IIoTシステムの多くのセキュリティに関する問題を解決します。MQTT、AMQP、REST、およびDHTPはこの基準を満たしています。OPC UAは、クライアント/サーバ・アーキテクチャなので、クライアントからの接続を可能にするためにサーバー側(通常は工場側)でファイアウォールに少なくとも1つのポートを開放しておく必要があり、この基準を満たしません。これはほとんどの産業向け通信システムにとって容認できないリスクです。SkkynetのDataHubやETKは、工場内のローカルネットワークにおいてサーバーやクライアントに接続する事が可能で、外部に対しては DHTP によってクラウドサービスであるSkkyHub、やDMZに配置されたコンピューターで実行されている別のDataHubにアウトバウンド接続できます。このアウトバウンド接続は、工場側のファイアウォールのすべての受信ポートを閉じたままにして工場内を外部から遮断する事を可能にします。

DHTP Protocol Comparison - Low Bandwith

最小限の帯域幅を活用し、可能な限り最小限の通信遅延時間で機能します。

DHTP Protocol Comparison - Low Bandwith Diagram

多くの産業用の通信プロトコルやIIoTシステム向けの通信プロトコルの目的の一つは、可能な限り低い帯域幅で、最小限の通信遅延時間でデータ通信を行うことです。MQTTとAMQPはこのことについてうまく機能します。RESTは、ソケットのセットアップ時間と通信のオーバーヘッドがすべてのトランザクションに含まれるために、この基準を満たしません。OPC UAは、帯域幅とレイテンシとの優先度を指定できるポーリングメカニズムを使用しているため、十分には満たしません。Skkynet社のソフトウェアとサービスは、接続を維持しながらDHTPを介して必要最小限のデータのみを送信するために、非常に小さな遅延時間内で、かつ、低帯域でのデータ通信を行います。

DHTP Protocol Comparison - Ability to Scale

何百、何千ものデータソースとユーザとの相互接続をサポートします。

DHTP Protocol Comparison - Ability to Scale Diagram

IIoTシステムの重要な側面のひとつとして、何百、何千、あるいは、何百万の“モノ”とインターネットを介して接続する事や、不特定多数のクライアントから、単一、あるいは複数の“モノ”へのデータアクセスを提供する事に対して、柔軟に対応できる将来的な拡張性があります。MQTTやAMQPなどのイベント駆動型のプロトコルはこのようなスケールアップが可能ですが、RESTのようなポーリング形式のプロトコルでは支障があります。OPC UAもイベント駆動型なので理論的にはスケールアップ対応が可能ですが、その機構の根本はポーリング形式なので大量な同時接続には対応できません。 DHTP は、その接続を介してそのプロトコルからのデータを抜き出し、イベント駆動型のプロトコルとして実行されます。このことによりうまくスケールアップすることが可能になります。

DHTP Protocol Comparison - Real-Time

最小遅延時間でのデータ送信動作。

DHTP Protocol Comparison - Real Time Diagram

多くの見える化ツール(リモートHMI)や監視制御システムでは、リアルタイム性が高いほど有効であると言えます。1秒以上の伝送遅延は特定の条件下やユースケースでは許容できる場合がありますが、それは理想的なものではありません。AMQPとMQTTは“到達保証”で動作していない場合のみにリアルタイム動作を提供できます。言い換えると、“guaranteed delivery” (保証された配信)のサービス品質を選択した場合にはプロトコル手順が増すので、その分、リアルタイム性は損なわれる事になります。それとは対照的に、DHTP は都度のパケット配信についてだけでなく一貫してデータの整合性を保証し、帯域幅の狭い接続においてもリアルタイム性を保ちながらその保証を維持します。RESTはほとんどの場合、リアルタイムなパフォーマンスを実現するには基本的に接続時のオーバーヘッドが大きすぎます。工業用プロトコルとして策定されたOPC UAは、この基準を十分に満たしています。

DHTP Protocol Comparison - Interoperable Data Format

クライアントとサーバーとのデータ通信における相互運用性の確保。

DHTP Protocol Comparison - Interoperable Diagram

通信プロトコルのデータフォーマットが明確に定義されている事は、データ通信において相互運用性に不可欠であり、すべてのユーザがあらゆるデータソースに対してシームレスに通信することを可能にします。OPCプロトコルでは相互運用性はそもそもOPCプロトコルを支える重要な要素であり、OPC UAプロトコルのデータフォーマットによって完全にサポートされています。どのような産業用IoTソフトウェアやサービスでも、相互運用可能なデータフォーマットを1つはサポートする必要があります。Skkynet のDataHubとETKはいくつかの通信プロトコルをサポートしながら、それらのプロトコルと DHTP 間のリアルタイムなデータ交換を可能にします。MQTT、AMQPおよびRESTでは、データフォーマットを定義せずメッセージのエンベローブ部分のみを定義しているため、サーバーとクライアント間のデータ通信においてデータの相互運用をサポートしません。したがって、あるベンダーのMQTTサーバーは他のベンダーのMQTTクライアントとはデータ通信できない可能性が高く、それはAMQPとRESTについても同じことが言えます。

DHTP Protocol Comparison - Intelligent Overload

データユーザが受信データレートについていけない時に、メッセージングブローカが適切に対応します。

DHTP Protocol Comparison - Intelligent Overload Handling Diagram

過負荷処理とは、クライアントの受信処理が通信データレートに追いつかない場合、または、サーバーの受信処理がクライアントからの通信データレートについていけない場合のブローカでの対応処理です。MQTTとAMQPは、2つの方法のどちらかで応答します。ひとつの方法は、クライアントのどちらかをブロックする事により、事実上、データ通信機能不能にして、すべてのクライアントをブロックします。またもうひとつの方法では、受信していた古いデータを優先して新しいデータを破棄するので、クライアントとサーバー間でのデータに矛盾が生じます。RESTにおいては、そのWebサーバーを飽和させてしまい、応答しなくなります。OPC UAは、新しいデータを保持し、古いデータを破棄しようとしますが、そのために大量のCPUリソースを消費してしまいます。必要に応じて、SkkynetのDataHubとSkkyHubは、古いデータを効果的に破棄します。DHTP を使用すると複数のホップに渡ってクライアントとサーバー間のデータの一貫性が保証されます。過剰負荷のクライアント間で送受信されるデータは、一貫性を保ち、他のすべてのクライアントは影響を受けません。

DHTP Protocol Comparison - Propagation of Failure Notification

クライアントは、回線上で接続断となった時、また、回復した時を確実に知ることができます。

DHTP Protocol Comparison - Propagation of Failure Notifications Diagram

ほとんどの通信プロトコルは、その機能として障害通知情報を提供しません。むしろ、ソケット接続が失われた事の認識はクライアントの機能に依存しています。このメカニズムだけはネットワークに複数のホップがある場合に他のホップに対して伝達されません。一部のプロトコル(MQTTなど)では “last will and testament” という回線切断時の通知機能が使用できますが、これはアプリケーション固有のもので移植性がなく、ネットワーク内の1接続に対してのみ有効です。複数のソースからデータを取得するクライアントは、どの“last will ”(回線切断)メッセージがどのデータソースに関連付けられているかがわかるように具体的に設定する必要があります。MQTT、AMQP、RESTおよびOPC UAにおいては、クライアントがデータの通過するホップ数を知っている事、クライアントがすべてのホップの状態を監視しようと試みる事を前提とします。この条件は、クライアントにおいてネットワーク内のホップをすべて定義しておかなければならないという見地から非常に脆弱だと言えます。通常、これを信頼できるものにすることができません。DHTP は、データ値だけではなく、通信の接続状態を示すデータの品質に関する情報も同時に伝達します。各ホップは、データの品質を完全に認識しており、そのデータ値やデータ品質を含めた情報を次のホップまたはクライアントに伝達します。

DHTP Protocol Comparison - Quality of Service

複数のホップで保存されたデータの一貫性を保証します。

DHTP Protocol Comparison - Quality of Service Diagram

IIoTシステム構築において重要な目標は、データ保存、状態監視、監視制御のために、システム全体で整合性のとれた産業用データを提供できる事です。MQTTは、データの一貫性を保証する能力は脆弱だと言えます。 MQTTの通信データのサービス品質オプション“SoQ”は、データネットワーク内の通信先のみ適用されるからです。そして、そのシングルホップ内での配信はリアルタイム性を犠牲にしてのみ保証されます。データ通信におけるリアルタイム性の欠如はメッセージの喪失を発生させる可能性を含み、クライアントとサーバー間でのデータの矛盾を容認しなければなりません。AMQPのデータ保証機能は、MQTTと同様にチェーン内の単一ホップにしか適用されないため脆弱です。さらに、クライアントの通信処理がサーバーに追いつく事ができずに飽和状態になった場合に、データ保証は損なわれます。RESTについては、そのプロトコルにおいてデータの品質サービスオプションを提供しません、OPC UAは通信データの一貫性を保証しますが、複数のホップにまたがっては機能しません。DHTP では通信データの一貫性を保証し、ホップ数を問わずに維持されます。

DHTP Protocol Comparison - Can Daisy Chain?

ブローカは他のブローカとの接続を可能し、幅広い収集とデータ交換できるネットワークの構築をサポートします。

DHTP Protocol Comparison - Daisy Chain Diagram

IIoTシステムの必要条件は、従来の産業用アプリケーションの基本的なクライアント-サーバ・アーキテクチャを超えています。例えば、プラント内のデータを送信し、他所のプラントや、本社、Webページまたはクライアントに取り込むには、多くの場合に、通常はDMZまたはクラウドサーバーを介して2台以上のサーバーを連携させるために接続する必要があります。OPC UAプロトコルは、デイジーチェーンで接続構成を実現するには複雑すぎます。情報は、最初のホップで失われます。OPC UAプロトコルでいくつかのホップをデイジーチェーン接続しようとすると、同期したマルチホップにおけるデータ交換処理は最も信頼性の高いネットワーク以外ではすべて不安定となり、大きな遅延を発生させる事になります。OPC UAでのデイジーチェーン接続では、各ノードへのデータアクセスはできません。RESTサーバーは、理論的にデイジーチェーン接続は可能ですが、データの同期は実現できず、また、そのチェーン内の各ノードにおけるデータアクセスはできません。MQTTとAMQPでは、デイジーチェーン接続できますが、各ノードがチェーン内での位置を認識した上で個々の処理設定が必要になります。MQTTおよびAMQPの通信データのサービス品質オプション“SoQ”はチェーンを介して伝播する事ができないために、MQTTおよびAMQPでのデイジーチェーン接続は末端に位置するノードのデータの信頼性を低下させます。SkkynetのDataHubとSkkyHubはどちらもデイジーチェーン接続をサポートしています。DHTPは各ノードにフルデータセットのミラーリングを許可し、そのデータへのアクセスは限定されたクライアントだけではなく、チェーン内の他のノードにも提供します。DHTP のデータ保証(QoS)は、たとえ限られた帯域幅に対応するために一部のイベントを破棄する必要があったとしても、チェーン内のどのクライアントまたは中間ポイントのデータセットも発信元のデータと一致する事を保証します。

最後に

本稿でそれぞれのプロトコルの概要を全て説明しきれたとは言い切れませんが、このIIoTシステムにおけるデータ通信の概要が、皆様のIIoT向けのプロトコルのご理解に少しでもお役に立てれば幸いです。MQTT、AMQP、REST、またはOPC UAのいずれも、IIoTシステムのために特別に設計されたものではありませんので、これらの基準を満たしていないのは当然のことです。一方、DHTP は、効果的な産業用およびIIoTデータ通信の条件を満たすために特別に設計されたものですので、自ずとIIoTシステム向けの最適なプロトコルの選択肢となっております。

Industrial IoT that Works

Data Communication for Industrial IoT – Conclusion

The Industrial IoT holds a lot of promise for improving productivity and cutting costs for industrial systems.  Yet the IIoT is different from both the consumer IoT and traditional SCADA systems.  In particular, data communications have unique requirements that you need to keep in mind if you are planning to implement an IIoT project that works well.

Re-Thinking Assumptions

Because industrial data communication was developed independently of the Internet, the merging of these two technologies requires a re-thinking of some basic assumptions.  The most secure and reliable approach is to focus on the data, and to allow access to the data onlyAccessing a device means that the device is open to an attack.  Accessing the network leaves the network exposed, even if you use a VPN.  A more secure-by-design approach allows the data source and the data user to make outbound connections to a public or private cloud service that holds only the data.  This keeps all plant firewall ports closed, and provides a secure spot independent of the plant where the data can be accessed by authorized users.

Data Protocol Problems

A number of data communications protocols have been proposed for the IIoT, each with its advantages and drawbacks.  UDP works for VOIP and streaming media, but it lacks the accuracy and completeness so necessary for good industrial communication.  MQTT offers a publish/subscribe mechanism and many-to-many connectivity, but lacks a standard data protocol and the ability to handle messages intelligently.  OPC UA is a good choice for in-plant connectivity, but suffers from the traditional server/client design that requires an open firewall port to connect from the Internet.  REST over HTTP is popular for general IoT applications, but has issues with bandwidth, latency, scalability, symmetry, and robustness when faced with the high speed and large number of connection requirements of the IIoT.  To implement security Blockchain may sound good in theory, but a closer look shows why it will fail in practice.

A New Approach

Clearly, a new approach specifically designed for IIoT is needed.  This approach should use the robust foundation of TCP, the security of a publish/subscribe model like MQTT, and the in-plant connectivity of OPC UA.  Its bandwidth use, latency, and scalability should far exceed RESTful HTML.  This new approach should support edge processing, and in fact, provide the means for edge processing, cloud processing, and fog processing, as dictated by the circumstances on the ground or in the field.  It should be available as a public cloud, a private cloud, or a hybrid combination of public and private clouds.

Something That Actually Works

Most important, this approach should actually work.  You should be able to install it in greenfield or brownfield projects.  It should connect to existing systems, use open protocols, and provide secure, robust, real-time performance at speeds not much slower than Internet propagation speeds.  And it should be available today, right now.  If you’re interested, give us a call.

Go back to Table of Contents