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のリアルタイムデータサーバにプッシュするエージェントをプラント内にインストールします。この接続は、プラントからインターネットへのアウトバンドであるため、プラントがインバウンド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つあれば、停止を余儀なくされます。化学プラントや食品加工システム内のただ一つの材料の不足は、大混乱を招く可能性があります。工場の自動化、発電、資源の抽出と処理、輸送と物流は、全てのメカニズム、ハードウェア、ソフトウェアの連鎖によってサポートされていますが、同様にオペレータやエンジニアも製品、サービスを生産するためにそれぞれのミッションを果たさなければなりません。


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




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




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


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


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








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







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ラインは休みなく回転しているようでした。 なにか問題があったのだろうか?


交替(またはスタンバイ)をどのくらい迅速にオンラインにするかによって分類されます。 コールドスタンバイ、ウォームスタンバイ、ホットスタンバイです。

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





OPCの冗長性の最も一般的な使用方法はOPC DAまたはUAですが、冗長なOPC A&Eシステムも同様に構成できます。原則は同じです。多くの場合、大規模なシステムでは、複数の冗長ペアを構成する必要があります。




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



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




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


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


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


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


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