Tunnelling OPC DA – Know Your Options

Since OPC was introduced over fifteen years ago, it has seen a steady rise in popularity within the process control industry. Using OPC, automation professionals can now select from a wide range of client applications to connect to their PLCs and hardware devices. The freedom to choose the most suitable OPC client application for the job has created an interest in drawing data from more places in the plant. Industry-wide, we are seeing a growing need to connect OPC clients on one computer to OPC servers on other, networked computers. As OPC has grown, so has the need to network it.

The most widely-used OPC protocol for real-time data access is OPC DA.  However, anyone who has attempted to network OPC DA knows that it is challenging, at best. The networking protocol for OPC DA is DCOM, which was not designed for real-time data transfer. DCOM is difficult to configure, responds poorly to network breaks, and has serious security flaws. Using DCOM between different LANs, such as connecting between manufacturing and corporate LANs, is sometimes impossible to configure. Using OPC DA over DCOM also requires more network traffic than some networks can handle because of bandwidth limitations, or due to the high traffic already on the system. To overcome these limitations, there are various tunnelling solutions on the market. This article will look at how tunneling OPC DA solves the issues associated with DCOM, and show you what to look for in a tunnelling product.

Eliminating DCOM

The goal of tunnelling OPC DA is to eliminate DCOM, which is commonly done by replacing the DCOM networking protocol with TCP. Instead of connecting the OPC client to a networked OPC server, the client program connects to a local tunnelling application, which acts as a local OPC server. The tunnelling application accepts requests from the OPC client and converts them to TCP messages, which are then sent across the network to a companion tunnelling application on the OPC server computer. There the request is converted back to OPC DA and is sent to the OPC server application for processing. Any response from the server is sent back across the tunnel to the OPC client application in the same manner.

OPC Tunnelling

This is how most tunnellers for OPC DA work, in principle. A closer look will show us that although all of them eliminate DCOM, there are some fundamentally different approaches to tunnelling architecture that lead to distinctly different results in practice. As you review tunnelling solutions, here are four things to look out for:

  1. Does the tunnelling product extend OPC transactions across the network, or does it keep all OPC transactions local?
  2. What happens to the OPC client and server during a network break?
  3. How does the tunnel support multiple client-server connections?
  4. Does the tunnelling product provide security, including data encryption, user authentication, and authorization?

1. Extended or Local OPC Transactions?

There are two basic types of tunnelling products on the market today, each with a different approach to the problem. The first approach extends the OPC transaction across the network link, while the second approach keeps all OPC transactions local to the sending or receiving computer.

OPC Tunnelling Comparison

Extending the OPC transaction across the network means that a typical OPC client request is passed across the network to the OPC server, and the server’s response is then passed all the way back to the client. Unfortunately, this approach preserves the synchronous nature of DCOM over the link, with all of its negative effects. It exposes every OPC client-server transaction to network issues like timeouts, delays, and blocking behavior. Link monitoring can reduce these effects, but it doesn’t eliminate them, as we shall see below.

On the other hand, the local OPC transaction approach limits the client and server OPC transactions to their respective local machines. For example, when the tunnelling program receives an OPC client request, it responds immediately to the OPC client with data from a locally cached copy. At the other end, the same thing happens. The tunnelling program’s job is then to maintain the two copies of the data (client side and server side) in constant synchronization. This can be done very efficiently without interfering with the function of the client and server. The result is that the data crosses the network as little as possible, and both OPC server and OPC client are protected from all network irregularities.

2. Handling Network Issues

There is a huge variety of network speeds and capabilities, ranging from robust LANs, to WANs running over T1 lines on multi-node internets, and on down to low-throughput satellite connections. The best tunnelling products give the best possible performance over any given kind of network.

To protect against network irregularities and breaks, any good tunnelling application will offer some kind of link monitoring. Typically this done with a “heartbeat” message, where the two tunnel programs send messages to one another on a timed interval, for example every few seconds. If a reply isn’t received back within a user-specified time, the tunnelling application assumes that the network is down. The OPC client and server may then be informed that the network is broken.

In practice this sounds simple. The problem arises when you have to specify the timeout used to identify a network disconnection. If you set the timeout too long, the client may block for a long time waiting for a reply, only to discover that the network is down. On the other hand, setting the timeout too short will give you false indications of a network failure if for some reason the connection latency exceeds your expectations. The slower the network, the greater the timeout must be.

However, this balancing act is only necessary if the tunnelling product uses the extended OPC approach. A product that offers local OPC transactions still provides link monitoring, but the OPC client and server are decoupled from the network failure detection. Consequently, the timeout can be set appropriately for the network characteristics—from a few hundred milliseconds for highly robust networks to many seconds, even minutes for extremely slow networks—without the risk of blocking the OPC client or server.

How the tunnelling product informs your OPC client of the network break also varies according to the tunnel product design. Products that extend the OPC transactions generally do one of two things:

  1. Synthesize an OPC server shutdown. The OPC client receives a shutdown message that appears to be coming from the server. Unaware of the network failure, the client instead operates under the assumption that the OPC server itself has stopped functioning.
  2. Tell the client nothing, and generate a COM failure the next time the client initiates a transaction. This has two drawbacks. First the client must be able to deal with COM failures, the most likely event to crash a client. Worse yet, since OPC clients often operate in a “wait” state without initiating transactions, the client may think the last data values are valid and up-to-date, never realizing that there is any problem.

Products that provide local OPC transactions offer a third option:

  1. Maintain the COM connection throughout the network failure, and alter the quality of the data items to “Not Connected” or something similar. This approach keeps the OPC connection open in a simple and robust way, and the client doesn’t have to handle COM disconnects.

3. Support for Multiple Connections

Every tunnelling connection has an associated cost in network load. Tunnelling products that extend OPC transactions across the network may allow many clients to connect through the same tunnel, but each client sends and receives data independently. For each connected client the network bandwidth usage increases. Tunnelling products that satisfy OPC transactions locally can handle any number of clients and servers on either end of the tunnel, and the data flows across the network only once. Consequently, adding clients to the system will not add load to the network. In a resource-constrained system, this can be a crucial factor in the success of the control application.

If you are considering multiple tunnelling connections, be sure to test for cross-coupling between clients. Does a time-intensive request from a slow client block other requests from being handled? Some tunnelling applications serialize access to the OPC server when multiple clients are connected, handling the requests one by one. This may simplify the tunnel vendor’s code, but it can produce unacceptable application behavior. If one client makes a time-consuming request via the tunnel, then other clients must line up and wait until that request completes before their own requests will be serviced. All clients block for the duration of the longest request by any client, reducing system performance and increasing latency dramatically.

On the other hand, if the tunnel satisfies OPC requests locally, this situation simply does not happen. The OPC transactions do not cross the network, so they are not subject to network effects nor to serialization across the tunnel.

4. What About Security?

Whenever you get involved in networking plant data, security is a key concern. In fact, security is a primary reason for choosing tunnelling over DCOM. DCOM was never intended for use over a wide area network, so its security model is primarily designed to be easily configured only on a centrally administered LAN. Even making DCOM security work between two different segments of the same LAN can be extremely difficult. One approach to DCOM security is to firewall the whole system, so that nothing gets in or out, then relax the security settings on the computers inside the firewall. This is perhaps the best solution on a trusted network, but it is not always an option. Sometimes you have to transmit data out through the firewall to send your data across a WAN or even the Internet. In those cases, you are going to want a secure connection. Relaxed DCOM settings are simply not acceptable.

Most experts agree that there are three aspects to network security:

  • Data encryption is necessary to prevent anyone who is sniffing around on the network from reading your raw data.
  • User authentication validates each connecting user, based on their user name and password, or some other shared secret such as a private/public key pair.
  • Authorization establishes permissions for each of those authenticated users, and gives access to the appropriate functionality.

There are several options open to tunneling vendors to provide these three types of security. Some choose to develop their own security solution from the ground up. Others use standard products or protocols that many users are familiar with. These include:

SSL (Secure Socket Layer) – Provides data encryption only, but is very convenient for the user. Typically, you just check a box in the product to activate SSL data encryption. The tunneling product must provide user authentication and authorization separately.

VPN (Virtual Private Network) – Provides both encryption and authentication. VPN does not come as part of the product, per se, but instead is implemented by the operating system. The tunneling product then runs over the VPN, but still needs to handle authorization itself.

SSH (Secure Shell) Tunneling – Provides encryption and authentication to a TCP connection. This protocol is more widely used in UNIX and Linux applications, but can be effective in MS-Windows. SSH Tunnelling can be thought of as a kind of point-to-point VPN.

As none of these standard protocols covers all the three areas, you should ensure that the tunnelling product you chose fills in the missing pieces. For example, don’t overlook authorization. The last thing you need is for some enterprising young apprentice or intern to inadvertently link in to your live, production system and start tweaking data items.

How Can You Know? Test!

The concept of tunnelling OPC DA is still new to many of us. Vendors of tunnelling products for OPC DA spend a good deal of time and energy just getting the basic point across: eliminate the hassles of DCOM by using TCP across the network. Less attention has been put on the products themselves, and their design. As we have seen, though, these details can mean all the difference between a robust, secure connection, or something significantly less.

How can you know what you are getting? Gather as much information as you can from the vendor, and then test the system. Download and install a few likely products. (Most offer a time-limited demo.) As much as possible, replicate your intended production system. Put a heavy load on it. Pull out a network cable and see what happens. Connect multiple clients, if that’s what you plan to do. Configure the security. Also consider other factors such as ease of use, OPC compliance, and how the software works with other OPC-related tasks you need to do.

If you are fed up with DCOM, tunnelling OPC DA provides a very good alternative. It is a handy option that any engineer or system integrator should be aware of. At the very least, you should certainly find it an improvement over configuring DCOM. And with the proper tools and approach, you can also make it as robust and secure as your network will possibly allow.

Download White Paper (PDF)

Industrial IoTのセキュリティ

業システムからデータへリモートデータアクセスする問題 は、新しい問題ではありません。プラントオーナーは、長年にわたり、管理者、運営者、保守技術者またはパートナーが、プラントから生成された貴重なリアルタイムデータへアクセスする方法を作り出してきました。グローバル化やJIT(Just-In-Time Manufacturing)などの革命的な実業は、このデータに対する低レイテンシのリモートアクセスを必要とし、多くの場合、信頼されていないネットワークを介して適度に信頼しているエンドユーザへ送信されています。例えば、製造業者は、生産情報をリモートサプライヤと共有したいが、製造システムまたはデータベースへのログインアクセスを提供しないことがあります。

リモートリアルタイムアクセスの必要性から、いくつかの根本的なセキュリティ上の問題が発生しました。

インターネットからの攻撃  プラントがリモートからシステムにアクセスできるようユーザを許可することは、悪意のアクターがシステムへアクセスすることを試みるための攻撃面を自然に作り出します。

ITネットワークからの攻撃  プラントがリモートシステムにアクセスできるようユーザを許可するこには、会社のITシステムのネットワークインフラへプラントをさらけ出す必要があります。一般的に、プラントネットワークは、大企業ではサブネットです。プラント内への侵入は、ITインフラを介して侵入します。ITネットワークからの侵入はあまりありませんが、ITネットワーク内のいくつかの問題が、プラントネットワーク上の正常なネットワークデータフローを中断させる可能性があります。可能な限りITとプラントネットワークを分離することが賢明です。

必要なデータ以外へのリモートアクセス  Microsoft RDPのようなデスクトップへのリモートユーザアクセスを許可することは、好奇心または悪意のあるユーザが意図された以上のプログラムやデータへのアクセスを試みる可能性があることを意味します。

一部のプラントネットワークの危険性  一部の工場では、インターネット接続を制限するためにVPN接続を使用することを選択しています。しかしながら、VPNはすべての参加者を効率的にローカルサブネットワークに配置し、参加マシンに効果的に互いへのローカルネットワークアクセスを提供します。妥協して任意のマシン(リモートサプライヤなど)をネットワークに配置することで、攻撃者がVPN経由でプラントネットワーク内に侵入する機会が生じます。

高額な費用  VPNやRDPエントリーポイント、ファイウォール、ルータの管理には、IT担当者の継続的な注意と労力が必要です。この費用は、システム内の参加者の数が増えるにつれて増加します。ITへリソースを費やさないプラントは、安全性の低いリモートデータアクセスを実施している可能性が高いです。

How can Skkynet Help?

Skkynet社のユニークなソリューションSkkyHub™は、リモートプラントデータアクセスにおける従来のセキュリティ問題のすべてに対応するメカニズムを提供しています。

インターネットからの攻撃に対して安全性を確保します  SkkynetのSkkyHubユーザは、プラント情報を収集し、Skkynetのリアルタイムデータサーバにプッシュするエージェントをプラント内にインストールします。この接続は、プラントからインターネットへのアウトバンドであるため、プラントがインバウンドTCPポートを開く必要がなく、プラントは決してインターネットからの攻撃にさらされることはありません。

ITネットワークからの攻撃に対して安全性を確保します  プラントからITネットワークへのアウトバウンド接続のみを許可するルータを使用して、ITネットワークからプラントを隔離することをお勧めします。SkkyHubサービスを使用することで、ITネットワークプラントから信頼されていないものとして扱われ、ファイアウォールは、ルータとSkkyHubの間に配置され、プラント内へインバウンド接続を許可しません。ITネットワークの破損は、プラントネットワークからSkkynetサービスへのデータフローに影響する可能性がありますが、プラントネットワーク内のデータフローには影響しません。 リモートデータアクセスが低下したとしても、プラントは安全で機能的なままです。

リモートプラントデータアクセスにおいて、従来のセキュリティ問題に対処するソリューションを設計しました。

必要なデータ範囲を超えるリモートアクセスはありません  SkkyHubを使用して、プラントはどのデータをリモートで使用可能にするか決定します。プラントエンジニアは、プラントで生成されたデータのサブセットを選択し、データグループのリモートユーザへ選択データを使用できるようにします。各グループには、グループごとに読み取り/書き込み権限があり、リモートユーザが接続しているリモートユーザ名とIPアドレスに基づいて制限を設定します。リモートユーザは、プラントエンジニアが許可している範囲を超えてデータアクセスを拡張するメカニズムはありません。

一部のプラントネットワークの安全性を確保します SkkyHubサービスは、VPNなどの汎用ネットワーク構成を作成しません。それは、データの送信のためのTCP接続のみを行います。その結果、参加しているマシンは、ローカルネットワークまたはVPN経由で他のマシンにさらされることはありません。データはネットワークプロキシ、データプロキシ、DMZサーバを経由してルーティングすることができ、アウトバウンド接続の場合でも、プラントネットワークがインターネットに直接接続することはありません。Skkynetサービスに参加するシステムは、ネットワークを共有する必要はありません。

高額の費用はかかりません.  SkkyHubは多くのセキュリティ上ハードルを排除し、それによって、実質的にITの実装コストを縮小します。しばしば、既存のITインフラストラクチャを変更することなく、Skkynetサービスに参加することができます。プラントでは、追加のIT専門家を雇ったり、ネットワーク機器を増設する必要はありません。多くの場合、唯一のコストは、プラントとSkkynetサービス自体へのSkkynetエージェントの設定です。

Skkynetの技術は、すべてのインターネットトラフィックにSSL接続を使用し、証明書の信頼チェーンを検証することによって証明されます。これにより、Industrial IoTのセキュリティが強化され、ネットワークののぞき見(snooping)や中間者攻撃(man-in-the-middle attacks)に対して保護します。

Industrial SaaSへの効果的なアプローチは何ですか?

“鎖はその一番弱い輪と同じだけの強さでしかない” ということわざがあります。その真意は産業用制御システムにあります。組み立てラインに小さなグリッジが1つあれば、停止を余儀なくされます。化学プラントや食品加工システム内のただ一つの材料の不足は、大混乱を招く可能性があります。工場の自動化、発電、資源の抽出と処理、輸送と物流は、全てのメカニズム、ハードウェア、ソフトウェアの連鎖によってサポートされていますが、同様にオペレータやエンジニアも製品、サービスを生産するためにそれぞれのミッションを果たさなければなりません。

時折、新しい技術の導入により、コスト削減、パフォーマンスや使い易さの向上が実現します。-連鎖の新しいリンクです。電気リレー、空気圧制御、DCS、PLC、RTU、SCADA、プラントネットワークおよびフォールドバスは、全て計画の段階で同時に提案されます。それぞれの製品にはエバンジェリストと懐疑主義者がいて、徹底的にテストされます。一度その価値が実証されると、各製品がオートメーションチェーンの中で強いつながりになります。

提案されている最新の技術の一つは、ソフトウェアをサービスとして提供すること(SaaS)です。SaaSは、ネットワーク(一般的にはインターネット)を介してホストされたソフトウェアへのアクセスを提供し、スマート工場、クラウドコンピューティング、インダストリアル・インターネット、M2M(Machine-to-Machine)、IoT(Internet of Things)のコンセプトに密接に関連します。SaaSを産業プロセス制御システムに追加することは、データの収集と統合、またはほとんどの既存の社内システムの限界を超えた分配能力の追加を意味します。

SaaSは、リアルタイムなプラントデータへのより広いアクセスを開くことができ、プロセスのリアルタイム監視をサポートし、予知保全プログラムを推進するために必要なビッグデータを提供、顧客サポート施設を外部委託する能力を提供、リアルタイムにKPIを提供、そうでない場合は、新規または既存のSCADA投資の価値を活用します。サービスとしてのソフトウェアは、従来のソフトウェア所有権よりも大幅なコスト削減を実現するはずです。

本当に有用であるために、サービスとしての産業用ソフトウェアは、安全でありながら、迅速、堅牢、同様に適応性があり、使い易いものであるべきです。

安全性

産業システムは、可能な限り高いレベルのセキュリティを必要とします。Lopez Researchの2014年1月の記事『Building Smarter Manufacturing With The Internet of Things』によると、「ITセキュリティは、スマートな工場を設立する上で最も大きな障害となっていました。」GEの包括的なレポート『Industrial Internet: Pushing the Boundaries of Minds and Machines states』では、「堅牢なサイバーセキュリティシステムと脆弱性を管理し、機密情報や知的財産を保護するためのアプローチ」を含む産業界のインターネットは、一連の重要な原動力と触媒を必要とします。このレベルのセキュリティを実現するには、安全なサーバ、ユーザーの認可と認証、暗号化されたデータ転送メカニズム、およびすべてのファイアウォールポートをプラントレベルで閉じた状態に保つなど、包括的なアプローチが必要です。

迅速かつ堅牢

サービスとしての産業用ソフトウェアは、ネットワークまたはインターネットインフラストラクチャがサポートするリアルタイムパフォーマンスに近いものを提供する必要があります。つまり、データの更新は秒または分ではなく、ミリ秒単位で行う必要があります。1秒間に何千ものデータ変更を処理でき、ホットスワップオーバー機能で冗長接続をサポートできるはずです。

適応性

産業システムは、多様でさまざまなデータプロトコルを使用して幅広い機器や制御装置から構築されており、あらゆる規模のものがあります。 産業用SaaSは、ハードウェアやソフトウェアを変更することなく、任意の数の場所で新規またはインストール済みのシステムにシームレスに接続できる必要があります。 オープンデータプロトコルとAPIを使用する必要があります。 理想的には、完全なDCSおよびSCADAシステムから、単一のマシンまたは組み込み機器まで、あらゆるサイズのシステムで動作する必要があります。 クラウドベースのサービスとして実行すると、ユーザーのニーズに応じて容易に拡大または縮小する必要があります。

利便性

市場で受け入れられるようにするためには、SaaSは使いやすいものでなければなりません。 デモ、サービスプランへのサインアップ、接続の設定、使用状況とコストの監視が簡単に行えます。 クラウドとの間でデータをやりとりしたり、プログラミングを行わずにデータを取得したり、複数のソースからのデータを簡単に統合する機能を提供したり、データストレージやHMIディスプレイなどのオプションが含まれており、産業プロセスを中断させることはありません。

セキュリティのための再設計

これらの要件の中で、最も能力を試されることはセキュリティです。 ミッションクリティカルなプロセスとそのデータを完全に保護する能力がなければ、産業用SaaSは成功する見込みはありません。 また、ほとんどすべての産業システムの基本的な特性は、クラウドベースのシステムに大きなセキュリティリスクをもたらします。ファイアウォールポートをオープンにしておく必要があります。

この問題に対する現在のアプローチは、VPN(バーチャルプライベートネットワーク)技術を実装することです。
VPNは、他のすべてのトラフィックから隔離された安全なスペースをネットワーク上に作成します。ただし、これは理想的なソリューションではありません。VPNでは、接続されているすべてのデバイスとユーザーが他のすべてのデバイスやユーザーにフルアクセスできるためです。1つのコントロールルームでは、これはあまり問題にはならないようです。しかし、クラウドコンピューティングの世界では、オペレータや現場のエンジニアは、タブレットや携帯電話のデータにアクセスすることを期待しています。

皮肉なことに、VPNを使用するとプラスをマイナスにすることさえできます。SaaSの強力なセールスポイントは認可されたサプライヤ、顧客、および他の当事者とが限定されたデータセットを共有するためのプラットフォームとしての可能性です。コーポレートVPNへのアクセスをプレーヤーへ提供するために、ストアの鍵を提供することをいとわないIT部門はほとんどありません。

より良いアプローチが必要です。VPNは特定の状況下では有効ですが、クライアント/サーバのアーキテクチャのほぼすべての産業データ通信の根本的な設計上の問題に対処するものではありません。産業システムからデータを取得するには、クライアントがサーバにデータを要求する必要があります。そのため、プラントのファイアウォールの背後に配置されたサーバからプロセスデータにアクセスが必要なクラウドサービスでは、プラントのファイアウォールのポートを常に開いた状態にしておく必要があります。ファイアウォールを開くことは、内在するセキュリティリスクです。

必要なのは新しいデザインです。SaaSは、インターネット経由でデータを送信し、WebSocketという異なる接続モデルをサポートするTCPプロトコルがあります。適切なエンジニアリングによって、このプロトコルは、プラントからクラウドへのアウトバウンド接続のみを許可する産業用データ通信に適用することができます。インバウンド接続は必要ありません。プラントのファイアウォールのポートを開いたままにする必要はありません。接続が確立されると、データは双方向に流れることができます。また、データ全部または一部を読み取り専用にすることで、クラウドからのデータ変更を防ぐことができます。どちらのアプローチをとっても、データは閉じられたファイアウォールを通って流れるため、プラントはインターネットからの攻撃に対して効果的に見えなくなります。

プラントを保護することに加えて、この設計では、プライマリまたはミッションクリティカルな制御をサービスで実行する必要はありません。すべてのローカルコントロールはそのままで変化がありません。システム管理者は、データがサービスに渡されることに対する完全な柔軟性を持ち、必要に応じて接続を読み取り専用に設定できます。

リアルタイムデータ

セキュリティの次に、効果的なSaasソリューションは、うまく機能するべきです。あなたがクラウドコンピューティングについて話すとき、ほとんどの人が、GmailやDropboxのようなデータを格納し、必要な時に取り出せる、空中のどこかに座っている巨大なデータベースのイメージを思い浮かべます。このモデルは、静的なデータの保存には有効ですが、産業システムは、リアルタイムで機能します。産業用SaaSの真の価値は、リアルタイムパフォーマンスで、これはクラウド上で根本的に異なるアーキテクチャを必要とします。

効果的なアプローチの一つは、サービスプロバイダーが、1秒あたり何万回ものデータ変更速度でデータを受信し再送できるメモリ ディシデント データベースをリアルタイムにホストすることです。これらの速度を達成するには、データ配信のパブリッシュ/サブスクライブ方式、つまりクライアントがデータ変更のために一度登録し、発生した直後に後続のアップデートを受け取るイベントドリブンモデルがあります。この種の低レイテンシシステムは、データ伝送時間全体にほとんど何も加えず、スループット速度を効果的にネットワーク伝送時間より数ミリ秒だけ長く維持します。

スループットをさらに高速化するには、データ中心のアプローチをすることによって、全てのデータを可能な限り単純な形式で処理する必要があります。このようなシステムは、制御システム、OPCサーバ、データベース、スプレッドシート、Webページ、組み込みデバイスなど、あらゆる種類のデータソースとユーザを連携します。データソースが接続されると、そのデータはすべての不要な形式(XML、HTML、OPC、SQLなど)が取り除かれ、接続されたすべてのソースのデータから構成された、ユニバーサルデータセットへ追加されます。このデータセット内の任意のポイントの更新は、登録されたすべてのクライアントに直ちに通知されます。受信側では、データは元の形式または、クライアントが必要とする他の形式に変換することができます。

うまく機能させる

産業オートメーションに関わってきた人は、すべてのシステムがユニークであることにすぐ気が付きます。産業、プラント、プロジェクトの要件によって、幅広いツール、機械、およびその他のデバイスが必要となり、数百の独立した供給業者によって提供され、世界各地の多様なシステムインテグレータやプラントエンジニアによって導入されています。

効果的な産業用SaaSは、これらの異なる種類のシステム、プロトコル、およびブランドの機器に可能な限り多く適合する必要があります。OPC、TCP、ODBCのようなオープンで標準的なプロトコルを使用する必要があります。全くベンダーに依存していない場合は、既存の設備の投資を活用したり、リアルタイムのデータ接続で新しい設備を強化するには最良のポジションです。理想的には、SCADAシステムに追加したり、個々のマシンのHMIとして機能したり、RTUや個々の組み込み機器にアクセスすることができます。

クラウドベースのシステムのように、ユーザのニーズを満たすために、サービス規模の拡大または縮小ができることを期待しています。これは、いかなる時でもデータフロー内の高速活動のバーストを処理する能力を意味し、拡大するシステムの拡張要件をサポートするための迅速な再構成能力も含まれています。ユーザは、特定のデバイスにデータポイントを追加したり、新しいデバイスを導入したり、新しいSCADAシステム、使い易いインターフェイスを通して新しい場所や設備にも追加できるべきです。

最後に、サービスのデータは、主要な意思決定者が最もよく使う方法で容易に利用できるべきです。それは、監視、監視制御のためにHMIを使用するオペレータであり、プラントから最新の数字を取得するフィールドエンジニア、3つの大陸にまたがる施設からのリアルタイムシナリオを実行するアナリスト、現在の生産水準にシステムを調整するジャストインタイムサプライヤー、隔離された施設のグループで生産を担当するプラントマネージャーなど。サービスのように効果的な産業用ソフトウェアは、コストを削減し、全てのプレイヤーのニーズを満たし、安全かつ迅速で便利に動作し、チェーン内の強固なつながりでなければなりません。

Can I Store and Forward OPC Data?

Every once in a while we get asked: “Can I store and forward my OPC data?” It seems like a reasonable question. I’m connecting an OPC server and client across a network, possibly with OPC UA, or more likely OPC DA—using DCOM or an OPC tunnelling product. In any case, should there be a network problem and the connection gets broken, I don’t want to lose any of my data. Why not store it, and forward it later when the connection is back up? A little understanding of the purpose of OPC, and how it works, though, should make it clear that this impossible.  The answer to this question is effectively “No–not real-time data, anyway.”

Let’s look at the OPC DA scenario first, since this is where the question comes up most often. Put simply, you cannot store and forward OPC DA data. The OPC DA protocol is for live, real-time data. OPC DA clients need to know what is happening right now in the system. An OPC DA server does not maintain a history of past values, and an OPC DA client only works with the most recent value of an OPC tag.

Despite this reality, suppose some bright spark decided he wanted to go ahead and add store-and-forward capability to OPC DA. When the connection to the client breaks, somehow the OPC server would need to start storing values―and this raises questions. How would the client identify which items in the server need to replay past values? How would the server know how long to store the data? What should the server do if this limit is exceeded? There is no facility in OPC for the client to specify any of this information, and it could not be robustly specified at the server. Not all clients would have the same requirements.

Then, when the connection gets re-established, the OPC server would start sending those values to the OPC client. Here it runs into more trouble. How would the server know that this was the same client reconnecting? How long has the client been disconnected? Has the client configuration changed since the last connection and therefore the previous store-and-forward configuration is out of date? How quickly should the values get sent? Should the OPC server replicate the time gaps between value changes? Then it would never catch up to the present. Or should it send all the stored values in a sudden burst of changes?

But the biggest problem is that old values are, by definition, wrong – only the most recent value is correct. In a store-and-forward scenario the client would experience a series of changes that could manifest as wrong indications in an HMI, or worse, wrong control signals to a physical system. Would you really want a piece of equipment turning on and off repeatedly as the data history catches up on the client? That could be inefficient, damaging or dangerous. In practice, most OPC clients can only hold one value for any given tag, and only now matters. The client doesn’t need and can’t use a replay of historical data, it needs to know what’s happening this instant.

It is a fact of life that network connections drop occasionally. When this happens, the client should present the data with a Bad or Not Connected quality, or show a Last Known Value warning until the connection is restored. Once the connection is back the client should receive the current data values. Whatever happened in the meantime is unimportant or downright misleading.

The idea of store-and-forward makes perfect sense, though, for data logging, archiving, and historical data. This is where it is possible to maintain a complete record of everything that has taken place on the OPC server. Although OPC DA itself does not offer this capability, a user can add an OPC HDA server, or connect a database to the OPC DA server. The responsibility for store-and-forward is now in the hands of the historian, where it belongs.

Turning now to OPC UA, from a fundamental design perspective the store–and-forward story is actually pretty much the same as it was for OPC DA. Nothing has really changed for an OPC UA client – it still expects to receive the latest data possible. The only slight difference is that the OPC UA architecture integrates historical data access better than OPC Classic does. This makes it easier for OPC UA servers to support historical data, and for OPC UA clients to request historical information. But whether data storage or archiving abilities are built into the server or provided separately, the reality of real-time data communications is that a real-time client cannot handle data that has been stored and forwarded. Nor is that its purpose. There are other tools designed for that.

So, the answer to the question, “Can I store and forward my OPC data?” is two-fold. On the one hand, you can record your OPC data, and then store and forward it as archived data. But you cannot store and forward data in real time.

 

Relational Database or Real-Time Historian for Logging Process Data?

Quite a few years ago, while living in a part of the world where personal computers were a relatively new phenomenon, I happened to be in an office watching a secretary busily typing away at her new PC. She was thrilled to have such powerful tool to use. “Look!” she said excitedly. “Now I can write and correct my work so easily!” I looked at the screen, and had to smile. She was composing an entire business letter within a single cell of an Excel spreadsheet.

What determines the right tool for the job? For that secretary, the right tool was the one that was available and that she knew how to use. What’s the right tool for logging data from a process control application? Sometimes a CSV file is all that is needed. Sometimes Excel will do. More often, though, engineers and system integrators will use either a relational database or a real-time historian to store permanent records of process data.

Relational databases have the advantage of availability and familiarity. SQL Server, MySQL, Oracle, or any other relational database, including Microsoft Access, are usually already installed at the company. They offer a common interface, ODBC, and the IT department is familiar with them. It’s no surprise that relational databases are being used for logging process data, particularly when the requests for data come from management personnel familiar with this kind of database.

But a relational database may not be the ideal choice for all process control applications. Designed for the needs of corporations, businesses, and banks to store transactional data, relational databases are optimized for analyzing complex relationships between data. These databases can afford to focus processing power on these relationships because the data itself gets updated relatively infrequently, usually in terms of hours, days, or months. While analytical power is good for business applications, process control applications typically don’t need it. What they do need is speed.

Blog-HistorianorODBCA real-time historian, on the other hand, is like a flight-recorder for process data. Rather than relational, it is a temporal database, storing its records in a flat file, consisting of simply the name, value, quality, and timestamp for a data point. The historian is designed for speed of storage and retrieval of data, and can typically process millions of transactions per second. This kind of performance is valuable for processes with variables that may change many times per second, and where capturing every event over the course of each eight-hour shift is vital.

Despite the performance advantages of a real-time historian, some companies opt for using relational databases for logging process data. This is completely understandable, since those are the tools that company IT staff and upper management are most familiar with. But there are three important reasons why this approach may not be sufficient:

  1. A real-time historian logs every data change for a point, even when the values change rapidly. Using highly efficient storage algorithms, the complete data set can be stored for long time periods. A relational database, in contrast, typically needs to drop some or most of the data as it is being logged, because it is not optimized for storing high volumes of data. Unfortunately, the data is dropped regardless of its importance. So you might end up logging routine changes and throwing away the unusual events that could lead to alarm conditions. In addition to detecting every change, big or small, the high volume capabilities of a real-time historian are useful for detecting subtle trends that may only appear over months or years.
  2. A strong advantage of a real-time historian is its native ability to process time-based queries. For example, you might need the standard deviation of a point that changes on average 25 times per second, in 10-second windows for the last two minutes. A good historian will provide an easy way to submit such a query, and will return the results quickly, with a minimum drain on system resources. Built-in query functions typically allow you to select any time period, from a few seconds to weeks or more, and retrieve averages, percentages of good and bad quality, time correlations, regressions, standard deviations, and so on. All of this may be possible through SQL queries on a relational database, but through much more programming effort and greater system resource use.
  3. The two above advantages of a real-time historian may perhaps best be appreciated when working with live trend displays. Calculating and displaying a moving line that updates several times per second requires not just the ability to log all the data points in real time, but also to re-emit them quickly and repeatedly for the moving display. And if a user wants to scroll backwards and forwards through the data set as it is being logged, the historian has to be able to manage rapid, continuous queries to the data set. This kind of task is nearly impossible for an off-the-shelf relational database, unless the screen refresh rate is annoyingly slow.

Even with these points in mind, there are many applications for which logging process data in a relational database works just fine. In fact, sometimes logging to a CSV file is sufficient. To be fair, these are really not the same level of technology mis-match as writing a complete business letter in one cell of a spreadsheet. The well-informed system integrator or engineer will understand the values of each approach, look at the needs of the project and resources available, and employ the right tool for the job.

Redundancy for OPC

る日の早朝、メル・ファーンズワースは、Hardy Automotive Parts社の組立ラインのコントロールブースに座って、シフトの終わり前にコーヒーを飲んでいました。彼は、HMIコンソールでラインメーターグラフを見て、ライン3の生産高と効率の傾向がゼロになっていることに気付きました。それで彼はコントロールルームの窓から見下ろしたが、3ラインは休みなく回転しているようでした。 なにか問題があったのだろうか?
ラインはスムーズに走っていたが、メルは必要なデータを取得できていませんでした。PLCとHMIディスプレイの間のどこかにデータの切断があり、フィールドバスの問題もしくは、ネットワーク接続不良の可能性がありました。おそらく、彼のOPCサーバー、あるいは恐らく彼のHMIシステムそのものによって引き起こされたと考えられました。理由が何であれ、メルのデータ接続は単一のチェーンであったため、チェーン内の1つの中断により、彼は自分のデータを取得できなかった。この種のリスクを最小限に抑え、可能な限り高い可用性を確保するために、ミッションクリティカルなシステムでは冗長性を使用することがよくあります。

冗長性とは何か?

プロセス制御システムにおける冗長性とは、システムの一部または全部が重複または冗長化されていることを意味します。目的は、単一障害点を可能な限り排除することです。1つの機器または通信リンクがダウンすると、類似または同一のコンポーネントが引き継ぐ準備が整います。冗長システムには3種類あり、
交替(またはスタンバイ)をどのくらい迅速にオンラインにするかによって分類されます。 コールドスタンバイ、ウォームスタンバイ、ホットスタンバイです。

コールドスタンバイ とは、交替システムを起動して稼動させる際にかなりの時間がかかることを意味します。ハードウェアとソフトウェアは利用可能ですが、起動して適切なデータをロードする必要があります。昔の蒸気機関車を想像してください。コールドスタンバイは、燃え上がらせて、奉仕に持ち込まれなければならない、円形機関車庫の別エンジンでした。コールドスタンバイは、データ更新が非常にまれでない限り、制御システムには使用されません。

ウォームスタンバイは、バックアップ(冗長)システムが常に稼動しているため、データセットの最新のコピーで定期的に更新されるため、応答時間が速くなります。プライマリシステムで障害が発生すると、冗長システムは、障害の発生したシステムから切断され、代わりにバックアップシステムに接続できます。これにより、システムはかなり早く(通常は数秒以内に)回復し、作業を続行できます。この切断/再接続のサイクル中に一部のデータが失われますが、ウォームスタンバイは、いくつかのデータ損失が許される容認可能なソリューションです。

ホットスタンバイは、プライマリとセカンダリの両方のデータシステムが同時に動作し、両方がダウンストリームクライアントに同一のデータストリームを提供していることを意味します。基盤となる物理システムは同じですが、2つのデータシステムでは別々のハードウェアを使用して、単一障害点が存在しないことを保証します。プライマリシステムに障害が発生すると、セカンダリシステムへのスイッチオーバーは完全にシームレスに行われるか、または「バンプレス」になり、データが失われることはありません。ホットスタンバイは、コールドスタンバイシステムまたはウォームスタンバイシステムのデータ損失を許容できないシステムに最適です。

典型的な冗長OPCシステム

OPCベースのシステムでは冗長性はどのように見えますか?
一般的なシナリオでは、2つのOPCサーバーが1つのデバイスまたはPLCに接続されているか、または重複しているデバイスまたはPLCに接続されています。これらの2つのOPCサーバーは、ある種のOPC冗長管理ソフトウェアに接続します。これは、HMIなどのOPCクライアントへの単一の接続を提供します。プライマリOPCサーバーからのデータに問題が発生した場合、冗長マネージャはセカンダリOPCサーバーに切り替える役割を担います。このシナリオでは、物理システムからHMIまでの冗長データストリームが作成されます。

OPCの冗長性の最も一般的な使用方法はOPC DAまたはUAですが、冗長なOPC A&Eシステムも同様に構成できます。原則は同じです。多くの場合、大規模なシステムでは、複数の冗長ペアを構成する必要があります。
冗長性は、DCOMまたはOPCトンネリングを使用してネットワーク上で構成することもできます。ネットワーク構成の場合、障害の可能性のある点の数を最小限に抑えるために、冗長マネージャは通常OPCクライアント・マシンに常駐します。

いくつかの状況では、コールドまたはウォームスタンバイが有用かもしれないが、通常、冗長OPCシステムを実装するエンジニアまたはシステムインテグレータは、ホットスタンバイを求めている。これは、プロセス制御システムで最も有用な種類の冗長性であり、同時に達成するのが最も困難です。ホットスタンバイシステムにおけるOPC冗長管理の重要な作業をもう少し詳しく見てみましょう。

スイッチを作る

簡単に言えば、ホットスタンバイ冗長マネージャは、2つの同一の入力からデータを受け取り、OPCクライアントに単一の出力を送信します。ステータスが変わるたびに、できるだけ早く2つのデータストリームのどれが最良であるかを常に判断し、できるだけ早く切り替えるのは冗長マネージャの仕事です。このスイッチは、さまざまな種類のイベントによって起動されます。:

  • シングルポイント値の変更 – 特定の値へ、またはその値からの変更、しきい値の達成など
  • シングルポイントの品質の変更 – たとえば、「Good」から他のOPC品質へ
  • 複数のアイテムの監視 – グループ内の任意のポイントの品質や価値が悪くなった場合
  • 変更監視率 – ポイントが予想よりもゆっくりと値を変更する場合
  • ネットワークブレークとタイムアウト – 何らかの種類のハートビートメカニズムでチェックされています。

スイッチが発生すると、システムまたは冗長マネージャ自体がアラームまたは電子メールメッセージを送信し、何らかの種類の診断または調査プログラムを起動する可能性があります。また、プライマリOPCサーバーまたはネットワーク接続の状態に関する診断情報を記録することもできます。また、プライマリ入力とセカンダリ入力を区別するシステムでは、プライマリ入力を優先し、可能であればその入力に戻す手段が存在することがよくあります。フォールバックと呼ばれることもあります。

実際に配慮すべき点

OPCの冗長性の考え方は把握するのが難しくありませんが、実装にはいくらか考えがあります。コールド、ワーム、またはホットスタンバイに関する最初の決定は、実装のすべての側面に影響します。適切なハードウェアとソフトウェアの選択は、適切に機能するシステムにとって重要です。堅牢なシステムアーキテクチャは、特に接続がネットワークを介している場合にも重要です。OPCサーバーの選択と(必要に応じて)ネットワークインフラストラクチャの計画に加えて、重要な決定は、冗長性を管理するために使用されるソフトウェアです。優れた冗長管理ソフトウェアは、プログラミングが不要で、使いやすいものでなければなりません。 この技術は最新のものでなければならず、最新のWindowsで動作する必要があります。スイッチオーバー中は、たとえネットワーク上であっても、データ損失の可能性は最小限に抑える必要があります。

タイマーの落とし穴

実際には、ホットスタンバイシステムを使用していても、すべてのケースで完全にシームレスなスイッチオーバーを達成することは不可能です。たとえば、プライマリ接続でネットワーク障害が発生した場合、冗長マネージャがその障害を検出するまでに一定の時間が経過します。この期間中に送信されたデータは到着しませんが、冗長マネージャはデータフローの障害と通常の一時停止を区別できません。

多くの冗長性マネージャは、タイマーを実装して定期的にネットワーク接続のステータスをチェックしてこの遅延を最小限に抑えますが、定期的なタイマーに基づくスイッチオーバーメカニズムは常にデータ損失を被ります。複数のタイミングパラメータを持つシステムでは、多くの場合、追加の遅延が発生します。システムの最速のスイッチオーバーは、これらのタイミング遅延の合計です。さらに、タイマーを使用してネットワーク障害を検出すると、システムインテグレータがスイッチオーバー―待ち時間と誤判定のネットワーク障害検出をトレードオフする必要がある構成上の問題が発生する可能性があります。これは事実、システムの安定性と応答性との間のトレードオフになります。

タイマーを使用してデータ値や品質を定期的に確認したり、OPCサーバーをポーリングしたりすることも、タイマーがシステムに不必要な遅延を導入するため問題になります。 ネットワーク障害はタイミングに基づいて検出されなければならないが、データ値または品質変化は、イベントが発生したときに直ちに検出することができる。 通常、時間ベースの値変更検出に基づいてシステムを回避し、代わりにイベントベースのオブジェクト監視を使用するのが最善です。

オブジェクトとリンクの監視

優れた冗長マネージャは、オブジェクト監視とリンク監視の両方をサポートできる必要があります。オブジェクト監視とは、個々のポイントを監視し、イベントに基づいてスイッチオーバーを行う機能です。たとえば、指定されたウォッチドッグ・タグがマイナスになるか、または指定されたしきい値を超えるような重要な方法で変更された場合、セカンダリOPCサーバーに切り替えることができます。または、あなたがポイントのグループを監視したいと思うかもしれません、そして、それらのいずれかの品質が “Bad”または ” Unconnected “に行く場合、あなたは切り替えることができます。

リンク監視は、ネットワーク接続に特に便利です。あなたのシステムは、データ消失を防ぐために非常に迅速にネットワーク切断を検出する方法が必要です。高速データ更新速度の高速システムでのホットスタンバイでは、応答速度が1秒未満のタイムアウト検出が不可欠です。いずれにせよ、システムは、失敗したネットワーク接続のタイムアウトとデータ受信の失敗を検出できる必要があります。この区別は重要です。通信障害を検出するには数秒または数分かかることがありますが、冗長マネージャは物理システムからの真のデータレートに非常に近い時間にデータフローの停止を検出できる必要があります。冗長マネージャは、データがプライマリ接続から到着していないが、バックアップシステムから到着したという観測のみに基づいて、あるソースから別のソースに切り替えることができます。

システムによっては、リンク監視にCOMタイムアウトを使用するシステムもあります。 これは、比較的長いデータ停止が許容される状況では許容されるかもしれませんが、ホットスタンバイまたはウォームスタンバイのCOMタイムアウトにはお勧めできません。

スマートスイッチオーバー

スイッチオーバー中の冗長システムの動作は重要な意味を持ちます。 たとえば、何らかの理由でプライマリとセカンダリの接続が両方とも失敗したとします。典型的な冗長マネージャは、一方が応答してから応答するまで、もう一方のOPCサーバーに接続しようとするサイクルを開始します。冗長性マネージャは、2つの間で無期限にフリップフロップし、各フリップフロップ間にスリープ期間を挿入して、システムリソースの負荷を軽減します。このスリープ期間は、それ自体がレイテンシの原因です。よりスマートなスイッチオーバーモデルは、ソースの状態が変化したときにのみ冗長マネージャを切り替えることができるソースの健全性状態を維持することです。これにより、冗長マネージャは、ソースの状態が変化するまで効果的にアイドル状態にしたり、再接続の同時試みを実行したりすることができます。よりスマートなスイッチングロジックにより、システム負荷とスイッチオーバー時間が大幅に短縮されます。

強制切り替えと優先ソース

現在接続されているソースが正常であっても、別のデータソースを選択することができれば便利です。純粋な冗長マネージャは、バックアップシステムが利用できない場合でも、ユーザーに切り替えを強制します。これにより、冗長マネージャが使用できないバックアップソースに切り替えるときに、再びフリップフロップ動作になります。はるかに良いアプローチは、冗長性マネージャが実行時に変更できる優先ソースの概念を理解することです。優先ソースが使用可能な場合、冗長マネージャはそのソースに切り替えます。ユーザーがあるソースから別のソースに切り替える必要がある場合は、優先ソースを変更するだけです。 そのソースが利用可能な場合、スイッチが作成されます。そうでない場合、冗長マネージャは使用可能になったときにのみスイッチを行います。
これにより、フリップフロップの動作が排除されると同時に、ナイーブな冗長性マネージャが課す最小2回のスイッチサイクルに伴うデータ損失を排除します。

生データへのアクセス

優れたホット・リダンダンシ・システムは、クライアント・アプリケーションに冗長データだけでなく、両方のソースからの生データへのアクセスを提供します。これにより、クライアント・アプリケーションは、冗長マネージャの遠方のシステムに関する診断情報を提示することができます。ほとんどの冗長マネージャは、この情報を隠して、クライアント・アプリケーションが生データにアクセスするために複数の接続を作成し管理する必要があれるならば、それを行う必要があります。

その他のオプションと機能

上記の機能に加えて、優れた冗長マネージャは、利便性のために追加機能を提供する場合があります。スイッチオーバー時にデータセット全体をリフレッシュするオプションが提供される場合があります。たぶん、電子メールを送信し、各スイッチオーバーで追加のプログラムを起動することさえできます。これは、主要な要員にシステムステータスを通知するのに便利です。診断を記録して、切り替えの理由に関する重要な情報を提供することができます。一部の冗長マネージャは、複数のサーバーに接続し、複数の冗長接続を作成できます。他のものでは、データのサブセットを扱うことができます。もう1つの望ましい機能は、プライマリデータソースとセカンダリデータソースを割り当て、セカンダリからプライマリデータソースへのフォールバックをトリガする機能です。

制御システムが複雑さを増し続けるにつれて、我々がますます依存するにつれて、メル・ファーンズワースの状況はより一般的になり、より価値の高いものになります。データの接続性が企業の成功に不可欠である場合、冗長システムをインストールする可能性を検討することが賢明でしょう。OPCの冗長性を実装する際には、上記の事情を考慮する必要があります。