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システム向けの最適なプロトコルの選択肢となっております。

Making OPC UA Secure for the Industrial IoT

Note: This article was originally published on the Automation.com website.

OPC UA was designed to be secure in an industrial environment, and it does a good job of it. In the world of Operations Technology (OT) you need reliable and secure data communications to run mission-critical systems. OPC UA provides robust connectivity, allowing your devices and machines to communicate, yet keeping them secure and locked down. But today’s OT world is expanding, being propelled into the larger, corporate world of IT, and beyond that, into the Industrial Internet of Things (IIoT) and Industrie 4.0. When connecting to IT and the IIoT, making OPC UA secure requires a new approach to meet new and different threats to security.

Securing an industrial system requires at the very least securing the perimeter against unauthorized access. Whether or not anything in the plant is connected to IT or the IIoT, this perimeter must remain intact for optimal security. In the past, perimeter protection was often accomplished by air-gapping, where the industrial network was physically isolated from any other network connection. Until recently, this approach or similar solutions like DMZs were sufficient. But these make it difficult if not impossible to share OT data with the company’s own IT department, much less on the IIoT. The challenge is to fully protect the perimeter, and yet still provide access to the data from OPC UA servers inside.

Are VPNs secure enough?

Accessing OPC UA servers or any other industrial system from the IIoT should be done through a secure network connection. The typical approach, one that many take for granted, is to use a VPN (Virtual Private Network). VPN technology is well known, having been used for decades in the IT world. In essence, a VPN provides an outside user with a log-in to the network, and establishes a secure tunnel through the Internet to allow access to the system―the entire system. And that can lead to problems.

While OPC UA can work over a VPN, that doesn’t guarantee robust security. VPNs were not designed for use with industrial process control systems. In fact, they can open vulnerabilities even in the IT world. The attack on Target stores in North America that cost the company millions of dollars was perpetrated through a VPN. Hackers got hold of a user name and password, and gained access to the system. Once in, they quickly found their way to customer records and credit card numbers, and had a field day. The problem with using a VPN to access an industrial system is not only that every VPN user account is a potential access point, but that once someone is inside the perimeter they gain access to the whole system.

The drawbacks of using a VPN for the IoT are examined in detail by Clemens Vasters, a Microsoft Developer. In a paper titled Internet of Things: Is VPN a False Friend? Vasters said, “VPN provides a virtualized and private (isolated) network space. The secure tunnels are a mechanism to achieve an appropriately protected path into that space, but the space per-se is not secured, at all. It is indeed a feature that the established VPN space is fully transparent to all protocol and traffic above the link layer.”

Using Reverse Proxies

Forward-thinking people who are working on the IIoT recognize this inherent risk in using VPNs. Many IT departments now require reverse proxies for OT systems to mask all internal servers and expose just one server to the Internet. But this approach does not secure OPC UA for the IIoT.

OPC UA clients can connect through reverse proxies using HTTP, but not HTTPS due to certificate handling. The proxy will either require opening a new firewall port, or effectively create a path to the control system that could easily be overlooked in the future. Either way an attack surface gets opened in the corporate perimeter. Furthermore, even if the message itself is encrypted, the message headers are exposed to outside observers. The only alternatives involve effectively tunneling through the proxy directly to the control system, which is what the proxy is trying to prevent.

The bottom line is that a reverse proxy is an improvement over a VPN, but it still requires a point of access into the control system from the Internet or IT network. Any point of access is an attack surface, and even if the server code is bulletproof it is still a candidate for a spear-phishing compromise.

Push Instead of Pull

The best way to completely close the plant perimeter is to eliminate all inbound connections, allowing only outbound connections. This is a good idea in principle, as it does not expose the plant to attack. The system presents zero attack surface, becoming invisible to hackers who cannot attack what they cannot see.

However, outbound connections run afoul of traditional design expectations. Effectively they turn the paradigm of industrial data communications on its head. Most client/server architectures, including OPC UA, assume that the server holds the data and the client initiates a connection to interact with it. The server is the authority on the data set, while the client is the non-authoritative user. Thus, in the OPC UA world-view the server must be situated with the primary data source, inside the control system.

To make a push design work in the IIoT, the server/client relationship must be reversed. The client must be the authority (inside the control system), and the server must be a non-authoritative receiver of the data. The client must be able to construct the data set on the server on the fly, based on its knowledge of the control system. This reversal of the client/server roles is something that OPC UA cannot accomplish on its own, but can be added through appropriate gateway software.

Using Forward Proxies

Using a push mechanism allows both OT and IT to completely close the network perimeter. If there is no way to make a connection from outside the network then there is no attack surface to exploit and there is no user to fool into revealing his password.

But even a closed perimeter is not sufficient. Best practice in IT networks is to route outgoing web traffic through a forward proxy, and to deny all other network traffic to the Internet. This substantially improves security by effectively shielding the internal network from a direct Internet connection. To be robust and IT-compliant the outbound IIoT connection must be able to pass through a standard forward proxy. Although OPC UA doesn’t inherently support forward proxies, appropriate gateway software can once again add this capability.

Secure by Design

The Chatham House Report, Cyber Security at Civil Nuclear Facilities Understanding the Risks, points out an alarming lack of security at some of the most critical infrastructure installations in the world, and makes a number of design recommendations. At one point it states, “Many industrial control systems are insecure by design, since cyber security measures were not designed in from the beginning.” And this does not just apply to nuclear facilities. Indeed, the “many industrial systems” may well include those which now or soon might incorporate OPC UA. And they require a new approach, a new design for security on the IIoT.

The new design approach must allow OPC UA clients from any location to connect and acquire data from OPC UA servers within the plant perimeter, to eliminate the need for reverse proxies and VPNs and to avoid opening any inbound firewall ports. At the same time, to fully support OPC UA’s real-time data access, the design must support bi-directional data communication between OT and IT systems and across the Internet at speeds very close to network propagation times. Secure-by-design for the IIoT should take a no-compromise approach, offering the best possible combination of speed, security, and convenience.

With this level of security, and near-real-time speeds, there is one more design consideration: practicality. To gain traction among users, the design should be convenient to implement. It should, for example, allow for seamless integration with legacy installations using OPC Classic and other industrial protocols, as well as newer OPC UA-enabled systems. It should provide a loose coupling to the IIoT, one that allows remote, authorized and secure access the data, optionally including supervisory control, but that has no impact on the primary control system if it gets disconnected. And it should be easy enough to implement that it doesn’t overly tax the time or resources of the system integrator or plant engineer who is implementing it.

This is the kind of design that is needed to secure the IIoT, and make it compatible with today’s factory or process. OPC UA is the industrial protocol of the present, and of the future. It has the ability to integrate plant data from virtually any machine or device, large or small, as well as to bring the disparate worlds of OT and IT together. When OPC UA is wedded to the appropriate, secure-by-design IoT technology, it will play a key role in Industrie 4.0 and IIoT applications.

Will IT and OT Converge?

It’s no secret down on the shop floor, or in the upper echelons of management, that IT and OT don’t always see eye to eye. For decades, the business computing world of Information Technology (IT) has been growing and evolving separately from the Operational Technology (OT) world. Plant engineers and system integrators working in the OT sphere are happy to keep their distance from the requirements and constraints of the IT department, going so far in many cases as to function on completely separate physical networks. Most executives, for their part, are reasonably satisfied to let the OT people do their work, and simply receive regular production reports from an ERP or possibly a MES system.

There are good reasons why these two siblings of IT and OT have grown up separately, despite their common parentage in computing technology. Yet now, increasing demands within and outside the enterprise are starting to force them to cooperate, and possibly even live under one roof. Exactly when and how this will happen may vary depending on the company and other factors, but it’s a trend that analysts such as Gartner and ARC Advisory Group predict will increase significantly in the next few years.

Much of this anticipated overlap (or collision) of IT and OT is due to advances in technology. On the OT side, Industry 4.0 and the Industrial IoT have become viable as the Internet becomes more reliable, and the cost of connecting devices drops exponentially. In the IT world, the lure and promise of Big Data and the analytical tools needed to extract value from it are moving quickly from the status of luxury to necessity. Heeding the lessons learned from the demise of Kodak and Blockbuster, executives understand the need to stay competitive in the digital age, or suffer the consequences.

Two Worlds of IT and OT

It is no accident that IT and OT seem to occupy two different worlds. You can trace this back to the primary goal of each. The focus of IT people is business improvement—to support accounting, logistics, human resources, and all other areas of the business to make it more effective and productive. In a sense, for IT, the product is the business itself. Upgrades to computer systems and improvements in skills pay off with immediate results in the success of the business. And it’s easy to make improvements because critical data is relatively static, providing ample opportunities to upgrade the tools and skills needed to manipulate the data.

In the OT world, the focus is on doing or making things. The production process is paramount. Complex factory systems, pipelines, power grids, and chemical plants cannot be switched on and off easily. Many systems run 24/7, and cannot be put on pause for software upgrades. Every hour of lost production time can cost millions. It may take months or years to build such a system, and once it is running, few engineers are willing to risk swapping in a piece of untested software. Computer skills are just one aspect of a project where the bulk of the expenditure and expertise is focused on the machinery and devices needed to do the work. OT is one of several players in the game, and not the star of the show that IT often becomes in its world.

Be that as it may, these two worlds are now poised to make contact. Businesses are waking up to the value of the data that’s coming from the production systems. Managers are discovering within OT data opportunities to harness real-time analytics and leverage predictive technologies that IT can provide. In a recent article, The Internet of Things: Bridging the OT/IT divide, John Pepper, CEO and Founder of Managed 24/7, said, “Unless organisations actively bridge the gap between OT and IT, the real operational benefits of the digital business will be lost.”

Bridging the Gap

As we understand it, there are at least three approaches to bridging the gap between IT and OT:

  1. Insert IT into OT. You can either import IT staff and expertise into the OT world, or build it in from the ground up. So far, this has not been a popular approach.
  2. Absorb OT into IT. Essentially this means expanding the IT world to encompass OT. Again, it may sound interesting in theory, but apparently the differences are too great, because we don’t see this happening much in practice.
  3. Allow OT and IT to communicate. For now, data communication seems to be the favored approach. Time will tell if this becomes a permanent necessity, or whether the two worlds can eventually merge.

For the foreseeable future, any convergence of IT and OT will continue to take place through data communication. What form does and will this communication take? Clearly OPC plays and will continue to play a major role. The key to OPC’s success to date has been its ability to foster communication between disparate systems. The large installed base of OPC Classic provides an easy way to obtain data from a wide range of systems. OPC UA is positioned as the data protocol for Industry 4.0 and the Industrial IoT. Whatever protocol may be used, and whatever form it takes, successful data communication between IT and OT must provide security, integration, and real-time performance.

Security is a major concern for OT professionals when considering connections to IT systems. For decades OT has usually been either physically separated from corporate IT networks, and/or functioning under the “security through obscurity” principle. The increasing number and sophistication of hacks to online industrial plants and power systems, along with the ability of viruses like Stuxnet to contaminate even an isolated system, underscore the need for an active and educated approach to security.

With this in mind, the best way to convince a prudent OT manager to share data with IT is to ensure the most secure connectivity scenario that is realistically achievable. The data communication protocol, such as OPC UA, should provide robust connectivity over TCP, and implement SSL and certificates. Keeping the plant’s firewalls closed and utilizing DMZs and proxy servers are essential for eliminating potential points of entry. Ideally, the system should be secure by design, and not need to rely on VPNs or additional security hardware. In fact, there is no need for IT to have any access to the plant at all, just the data. And access to that data should be restricted to just those in IT or management authorized to use it.

Seamless integration of data protocols is a second requirement for IT / OT convergence. OPC provides a way for the vast array of industrial protocols to be integrated into a single protocol. Converting OPC Classic to OPC UA will be needed to include legacy equipment in the conversation. To fit into the IT world of SQL databases, the ability to convert to ODBC is a must. And let’s not forget the IT world’s personal tool of choice: Excel. These are some of the more popular data protocols as a starting point; there may be others. The better the integration of OT data into familiar tools for IT, the more likely the IT and OT worlds will get along.

Finally, real-time performance is a big plus, if not an absolute necessity. Real-time data coming directly from the factory floor is one of the primary reasons for the whole project. This is the data that will power the real-time analytical engines and predictive technologies that management envisions, and that IT will be implementing.

Will we ever see IT and OT converge? It is difficult to say at this early stage. The trend right now is to open channels of data communication between the two. Success in these initial endeavors may inspire players on one side or the other to expand beyond their limited domains, and work towards a more fundamental level of integration. For now, professionals in both OT and IT can start by implementing secure, integrated, real-time data communication, and see where that leads.

Value Propositions for Industrial IoT

A mong all the fanfare and hoopla over the Industrial IoT, the more practical-minded among us quietly but persistently raise the question, “So, where’s the value?” It’s a fair question. The IoT represents a new area of influence for industrial automation. Before embarking on such a venture, it’s good to have some idea what the benefits may be.

As we see it, there are two main parties involved, producers and suppliers, and each of them stands to benefit in their own way:

Producers

By “producers” we mean any company in the industrial sector that produces goods or services, such as manufacturing, energy, oil & gas, chemicals, mining, water & wastewater, transportation, food & beverages, and so on.

OPEX over CAPEX

Traditionally, projects in the industrial sector require large up front capital expenses (CAPEX) and are usually accompanied by long-term commitments. Shifting these costs to operational expenses (OPEX) means that you do not need to justify a large capital expenditure over years of returns. Just like a cup of coffee, you buy it, consume it and when you need more, you buy it again.

The SkkyHub “pay as you go” model cuts costs in this way. There are no long-term commitments and no initial capital investments. Costs are reduced and shifted from high capital expenses to monthly operating expenses, which improves long-term expense planning and looks better on financial statements.

Data as a Service

There is no need for additional IT personnel or extra hardware, no programming and no upgrade headaches. SkkyHub takes care of data connectivity, freeing up customer staff and resources for higher priority tasks, while increasing ROI.

The Efficiency of Big Data

Knowing exactly what is happening at any given time in the system is a useful step that a producer can take towards improving efficiency, enhancing value. Until recently, this kind of analysis was only available to the biggest enterprises. Now SkkyHub provides a cost-effective way to bring the power of big-data collection to even the smallest enterprise. Combined with custom or third-party analytical tools, the real-time data flowing through SkkyHub can power both historical and real-time analysis, boosting KPIs and enabling significant gains in productivity.

Overall Equipment Effectiveness (OEE)

Overall equipment effectiveness (OEE) is a measure of how efficiently production equipment is being used. In manufacturing, for example, OEE is calculated according to three measures: uptime of production equipment, quantity of output, and quality of finished products. Manual methods and historical data archives give a rough idea of OEE, but according to a recent paper published by the ISA, a much more precise and relevant picture can be drawn by combining real-time operational visibility with real-time analytics. Any drop in production uptime or quantity, or in the quality of finished goods will be noticed immediately, and a fix can be applied on the spot, rather than waiting days, weeks, or months for a report to be generated.

Predictive Maintenance

Today’s engineers and managers recognize the need to shift from reactive to predictive maintenance. Instead of asking “What happened?” or “What’s happening?” they want to be asking “What will happen?” Instead of just putting out fires, management and production staff can use the real-time data provided by SkkyHub for optimization, data mining, and fault prediction.

Suppliers

By “suppliers” we mean companies that supply goods or services to industrial companies, in three broad categories:

  1. Raw Materials Suppliers
  2. OEMs (Original Equipment Manufacturers) and Equipment Vendors
  3. System Integrators
Raw Materials Suppliers

Connecting to a customer’s process data via the Industrial IoT provides value by giving suppliers a window into the real-time consumption rates of the raw materials they provide. This allows them to offer just-in-time deliveries, and coordinate their production with demand in real time. A well-known business model shows how the lack of communication between suppliers and producers can cause costly shortages and wasteful overruns. If the Industrial IoT is extended further to include customer order data, then the supply-production-delivery chain could be fully coordinated, with minimal waste and maximum profit.

OEMs and Equipment Vendors

Implemented properly, the Industrial IoT provides a way for OEMs and equipment vendors to monitor their tools and machines in real time. As industrial equipment grows increasingly complex, more and more specialized knowledge is required to maintain and keep it running at optimal efficiency. Meanwhile, customers constantly demand higher uptime rates.

The solution is to stay connected 24/7 in real time. This kind of connection provides vendors and manufacturers immediate notification when something goes wrong, and a convenient channel to check settings and tweak configuration. Rather than sending a technician out to the plant, the tech support team can address the problem using the full set of in-house resources. For the big picture over time, with every machine connected, the vendor or manufacturer can collect histories for every unit in the field, and analyze the data over the entire life of the product.

Given the benefits of OPEX over CAPEX, the growing complexity of machinery, and the convenience of remote monitoring and service, the Industrial IoT may well facilitate a trend towards providing equipment as a service. Plant owners pay a monthly leasing fee for the equipment, and tool manufacturers and/or vendors ensure that it is in place and functioning as expected.

System Integrators

System integration companies come in all sizes, from lone entrepreneurial engineers to mid-sized specialty shops to multi-national giants. Each may offer a different range of skills, products, and services. As the Industrial IoT gains traction, system integrators may begin looking for a way to offer such a service that works well.

Skkynet offers revenue sharing opportunities that meet the needs of any size system integrator working with customers in any sector or niche market. Skkynet partners are able to offer their customers a secure end-to-end solution for the Industrial IoT right now―at a fraction of the cost associated with ad-hoc or home-grown solutions. System integrators who can offer value through best of breed technology to enhance customer performance will deepen relationships with existing clients and grow their customer base.

Industrial IoTに適応する

“I t all sounds fine on paper, but will it work for me?”

「理論上は素晴らしいが、一体どのように活用したらよいのだろうか?」その質問は、Industrial IoTが話題になった時にエンジニアやシステムインテグレータからよく尋ねられます。それに合わせる方法はとてもたくさんあります。産業システムはスノーフレークのようなもので、全てがユニークです。各施設や工場、パイプライン、発電所などは、プラントオートメーションの歴史において、特別な目的、世界の異なる地理条件、その時代のテクノロジー技術の進化に合わせて、幅広く開発されてきました。私たちは、広範囲のマシン、ツール、センサー、および独自開発の自社製ソフトウェアとデータプロトコルの無限の組み合わせで使用される機器を見ています。時間が経つにつれてプラントの改造と拡張やハードウェアやソフトウェアのアップグレードとともにさらに多様化しています。

この多様性に対応できなければ、Industrial IoTに関して、新しい疑問が浮上してきます。実際にどのようにIoTをスタートすれば良いのだろうか?どこのサービスプロバイダを使用するのですか?アプローチやプラットフォームはどのようなものがベストですか?費用のメリットは何ですか?

これらをまとめてみると、優れたIndustrial IoTソリューションは快適なものでなければならないことは明らかです。それは実際にすべてのプラント内システムに接続する必要があり、リモートシステムへのリンクを提供すべきです。複数のデータプロトコルや従来のシステムと互換性があり、将来のハードウェアやソフトウェアとシームレスに統合する必要があります。新しいスーツを着るのと同じように、理想的なことは、何かを混乱させることなくIoTを容易にすることです。

目的に向けて、良いシステムが対応すべきことことは:

  • 多様なデータ通信プロトコルをサポート: OPC“Classic”とUAの両方のOPCは、産業データ通信の簡素化と統一において重要な役割を果たします。 産業用IoTプラットフォームは、Modbus、Profibus、HART、DeviceNetなどの一般的な工業用フィールドバスとともにOPCをサポートする必要があります。 IEC 61850、CAN、ZigBee、BACnetなどのより専門的な標準もサポートする必要があります。 これらに加えて、Industrial IoTは、Web接続用のHTMLやXML、データベース接続用のODBC、必要に応じてExcelに接続するためのDDE、カスタムプログラムに接続する機能など、非工業標準と互換性がある必要があります。
  • 組み込み機器への接続:“もの”のインターネットの部分は、主に組み込み機器を指しています。 センサ、アクチュエータなどのデバイスは、日々の小型化、安価化、多用途化が進んでいます。それらは、直接または有線またはモバイルゲートウェイ経由でクラウドに接続できる必要があります。これは、SCADAがIndustrial IoTに豊富な経験を提供できる分野であり、インターネット接続が提供できる拡張されたリーチから大幅に利益を得ることができます。
  • 新規または既存の機器や設備で作業する: 1970年代にDCSとPLCが導入されて以来、デジタル・オートメーションはますます発展し、進化しています。新しいテクにロジーが絶えず採用または適応されていますが、多くの古いシステムは引き続き稼働しています。多くの工学、労力、および資本が各プロジェクトに投資されているため、プラント管理者は、稼働しているシステムに変更を加えることに消極的です。“壊れていなければ、修理しない”世界で受け入れられるためには、Industrial IoTシステムは、既存設備に接続できるが、侵入するべきではありません。もちろん、新システムに対しても同様にすべきです。
  • 既存のツールを使用するか、それ以上のものを使用する: Industrial IoTは、車輪の再発明をする必要はありません。 ほとんどの産業オートメーションシステムには、DCSおよびSCADAシステムやHMI、MES、ERPおよび他の種類のデータベース、データのヒストリアン、その他、を含む実用的なツールセットがあります。互換性のあるIndustrial IoTの実装は、適切なプロトコルを使用して、これらのすべてのツールを使用してできるだけシームレスに動作する必要があります。 同時に、必要に応じて、あるいは改善されたツールへの接続を提供することもうまくいくでしょう。
  • ビッグデータの要件を満たす: 新しいツールの中で、既存または将来の産業システムをビッグデータに接続する機能は、Industrial IoTの主要な魅力の1つです。 互換性のあるIndustrial IoTソリューションは、ビッグデータエンジンを選択するために必要な接続性とパフォーマンスを提供する必要があります。
  • 段階的な導入を可能にする: オートメーションの専門家やIndustrial IoTの支持者は、このすべてを一度に実装する必要はないことを素早く指摘しています。 彼らはしばしば段階的な実装プロセスを推奨します。 小さなデータセット、独立したプロセスまたはシステムから始め、そこから構築します。 必要に応じてユーザに提供します。 あなたがツールやテクニックに慣れたら、あなたは増築することができます。もちろん、このアプローチをサポートするIoTプラットフォームが必要です。

Skkynetの仕組み

Skkynetは、Industrial IoTとの互換性をシームレスに連携する3つのコンポーネントDataHub®、Embedded Toolkit(ETK)、SkkyHub™で実現します。

Cogent DataHub® は、OPC、Modbus、ODBC、およびDDEを介してプラント内のシステムに直接接続し、または、Red Lion Data Station Plusと完全に統合され、300の追加の産業用プロトコルに接続します。 DataHubは、データ集約、サーバー間ブリッジ、データベースロギング、冗長性、およびその他のデータ統合機能をサポートします。 柔軟なWebベースのHMIであるWebViewも提供しています。

Embedded Toolkit (ETK) は、組み込みシステムがSkkyHubまたはDataHubと接続して通信するためのビルディングブロックを提供するCライブラリです。 Red Lion、B + B SmartWorx、NetComm、SysLINK、およびRenesas、Lantronix、Raspberry Pi、Arduino、ARMなどのデバイスのゲートウェイ上で動作するようにコンパイルされています。

これらの2つのコンポーネントは、事実上あらゆる産業システムに接続して統合することができます。 SkkyHubに接続すれば、いつでもクラウドに向かって進化の第一歩を踏み出すことができます。

SkkyHub™ サービスは、ローカルとリモートの両方でネットワーク上でリアルタイムデータを収集し、配信します。 DataHubまたはETK対応デバイスに接続することで、SkkyHubは遠隔地間の産業用IoTデータの安全なネットワーキングと、WebViewによる遠隔監視および監視制御を提供します。

SkkynetのIndustrial IoTソフトウェアとサービスは、今日広く使用されています。 製造施設、風力および太陽光発電所、オフショアプラットフォーム、鉱山、パイプライン、生産ライン、ゲージ、ポンプ、バルブ、アクチュエーター、およびセンサーを接続することができます。 事実上あらゆる産業システムとのセキュリティ、スピード、互換性のユニークな組み合わせにより、DataHub、ETK、SkkyHubは、Indusrial IoT に適合したコンポーネントです。

Industrial IoTのトップパフォーマンス

I ndustrial IoTは、通常のIoTとは異なります。. ミッションクリティカルな産業システムでは、コンシューマやビジネスITアプリケーションとは異なり、パフォーマンスが重要です。ほとんどのITシステムは、リレーショナル・データベース(クライアントが追加またはアクセスできるデータ・リポジトリ―)を中心に構築されており、応答時間に1~2秒が容認されています。ITデータは、通常、HTMLまたはXMLを介してネットワーク経由で送信されるため、生データに複雑さが増し、帯域幅が消費されます。オフィスや家庭での使用に適していますが、これらの技術は産業用IoTでは十分ではありません。

一般的な産業システムでは、データはリアルタイムで流れます。センサーからデバイスまたはプロセスを通ってシステムへ移動し、途中で他のデータと結合することが多く、オペレータのコントロールパネルや他のマシンやデバイス、または特殊目的のデータヒストリアンで終了することがあります。プラントまたはフィールドの状態が変化すると、データはリアルタイムで到着し、システムまたはオペレータはそれに対して反応しなければなりません。ロボットアームまたは他の装置は、毎秒数百のデータ変更を送信します。データ・セット内のミリ秒の微小な変動は、重要な影響またはトリガー・アラームを発報している可能性があり、トレンドチャートや履歴データベースは、詳細ごとにアクセスする必要があります。

Industrial IoTにおいてこのような性能に達成するには、非常に優れたデータ通信へのアプローチが要求されます。

  • リアルタイム・インメモリデータベースは、データの移動を保持します。 データは、迅速かつ容易にシステムを流れる必要があり、これらの急速な値の変更をサポートするためにインメモリデータベースが必要です。リレーショナル・データベースは、ITの世界で良く使われる製品ですが、この特別な目的のために構築されていません。レコードに書き込み、クエリの処理、および情報の取得には時間がかかります。従って、インメモリ・フラットファイルデータベースは、データスループットを向上させるのに適しています。
  • 高速なデータ統合により、任意のデータソースを任意のユーザへ接続します。 インメモリの重要な役割は、受信データの全てのソースを統合することです。すべての通信がデータ中心(下記参照)の場合、全てのデータソースを一つの共通データセットにまとめることができます。この設計はデータ処理を可能な限り単純化し、承認されたユーザがデータ入力の特定な組み合わせへリアルタイムに接続することを許可します。
  • パプリッシュ/サブスクライブはポーリングに勝る パプリッシュ/サブスクライブ、イベント駆動モデルでは、ユーザはデータソースに接続するためにワンタイムリクエストを行い、更新が発生するたびに更新情報を取得します。一方、ポーリングは時間指定されたデータ要求を定期的に送信します。これはデータの変更がまれである場合にリソースを無駄にします。複数の要求で同じ値が返される可能性があるためです。同時に、ポーリングサイクルの間にいくつかの値の変更が発生した場合に完全に値が失われるため、急速な変化ではポーリングは適切ではありません。
  • データソースを高速に「プッシュする」のが最も効率的です。 データは、システムへプッシュアウトされ、ユーザへプッシュされます。より良いセキュリティモデルであることに加えて、このアプローチもより効率的です。ソースからデータを「プル」するには、ポーリングが必要です。各データの更新には2つのメッセージ、つまり要求と応答が必要なため、処理に時間がかかり、帯域幅を多く使います。プッシュテクノロジーは、1つのメッセージしか必要としないため、より効率的に帯域幅の消費が少ない、マシン間通信を可能にします。
  • Web中心ではなく、データ中心の設計は、クラウド上で最高のパフォーマンスを発揮します。 ソースデータをトランスコーディングするには時間がかかり、多くの小型センサーにはないリソースがデバイス上に必要です。データをHTMLまたはXMLコードを使用しないシンプルな形式に保つことにより、可能な限り低遅延を実現します。ローデータは、ソースからクラウドを介して可能な限り早くユーザへ流れます。到着したローデータは、HTML、XML、SQLなどの他のフォーマットに変換することができます。Webブラウザ、データベース、スプレッドシート、M2Mなどのシステムは、到着地点で単一のデータソースへのアクセスが可能となり、システム内のデータ移動を削減します。/li>

Skkynet製品の導入

これらのSkkynetの SkkyHub™ DataHub® は、ネットワークレイテンシをわずか数ミリ秒に短縮し、1秒間に最大50,000回以上のデータ変更を可能にします。高いパフォーマンスレベルは、リアルタイムなインメモリデータベース技術とパブリッシュ/サブスクライブ、プッシュによるデータ収集、データ中心のコミュニケーションの方法を組み合わせることで実現します。

DataHubとSkkyHubの「ハブ」技術は、15年以上にわたって世界中の何百ものミッションクリティカルなシステムで使用されているリアルタイムのインメモリフラットファイルデータベースです。産業用データ通信のために設計されたDataHubと ETK は、すべての受信データをシンプルな内部のローデータ形式に変換することで動作します。このローデータは、非常に高速にデータを統合し送信することができます。

プラントレベルでは、DataHubはプロセスデータをリアルタイムで収集、統合、再配布します。 DataHubまたはETKをSkkyHubに接続するだけで、選択したデータセットをIoTにシームレスに渡すことができます。クラウドレベルでは、SkkyHubがリアルタイムデータの収集、統合、および配信を提供します。 IoTのパフォーマンスは、インターネットの実際のネットワーク伝播速度に近づき、遅延はほとんど追加されません。

正直なところ、一般的なIoTプラットフォームがこのレベルのパフォーマンスを提供するとは思わないはずです。産業IoTのために設計されたものはほとんどありません。 「Industrial Internet of Things」のような破壊的な概念を適切に実現するためには新しいアプローチを必要とするかもしれないことは驚くべきことではありません。パフォーマンスに加えて、産業用アプリケーションにはユニークなセキュリティ互換性が要求されます。 Industrial IoTのために堅牢で堅固なプラットフォームを選択するには、これらすべてが考慮すべき重要な要素です。