OPC について知る

OPC の相互運用性: オープン規格によるオープンな接続

OPC はクライアント / サーバー テクノロジです。一方のアプリケーションがデータを供給するサーバーの役割を、もう一方がデータを使用するクライアントの役割を果たします。

OPC は広く採用されている産業用通信規格です。OPC に準拠することで、特定のベンダーに縛られることなく、さまざまなベンダーのデバイスや制御アプリケーション間でデータを交換できます。OPC サーバーは、作業現場の PLC、現場の RTU、HMI ステーション、デスクトップ PC 上のソフトウェア アプリケーションの間で、データを継続的に伝達できます。ハードウェアとソフトウェアのベンダーが異なっていても、OPC コンプライアンスによりリアルタイムの継続的な通信が可能です。

OPC によって、テクノロジ プロバイダとユーザーの間の協力関係も強化されました。OPC のおかげでオートメーション サプライヤは真のオープン ソリューションを提供できるようになり、その結果、ユーザーのオートメーション アプリケーションの選択の幅が広がりました。業界にとっては、まさに歓迎すべき時代です。相互運用性、オープン ソリューション、選択の自由 - これらのおかげで、世界中のオートメーション担当者は、OPC を産業アプリケーションに組み込むメリットを手に入れました。

OPC は、業界を支える産業オートメーションおよびエンタープライズ システムにおいてオープンな接続性を提供します。相互運用性は、独占的でないオープン規格仕様の策定と維持によって確実なものとなります。初の OPC 規格仕様は、Microsoft と連携する世界トップクラスの多数のオートメーション サプライヤのコラボレーションから生まれました。元々 Microsoft の OLE COM および DCOM テクノロジをベースとしていたこの仕様では、相互運用性を促進するためにプロセス制御および製造オートメーション アプリケーションで使用する、オブジェクト、インタフェース、メソッドの標準セットを定義しました。COM/DCOM テクノロジは、開発するソフトウェア製品のフレームワークとなりました。現在では、数百種類もの OPC Data Access サーバーおよびクライアントがあります。

OPC 規格は、一般的なコンピューティング市場のテクノロジをベースとしています。OPC メンバーが提供する製品のツールは幅広く、"市販の" 製品を好むユーザーから、ツールキットを利用したビルドの効率性を重宝する中間レベルのエンジニア、アプリケーション全体のビルドを好む開発者まで、その対象はさまざまです。

OPC Data Access の概要

この仕様には、OPC COM オブジェクトと、OPC サーバーによって実装されるそれらのオブジェクトのインタフェースについて記述されています。さまざまなベンダーが OPC サーバーを提供しており、各 OPC クライアントは、1 社または複数のベンダーが提供する OPC サーバーに接続できます。

各サーバーがアクセスできるデバイスとデータ、データ名、サーバーがそのデータに物理的にアクセスする方法の詳細は、ベンダーによって提供されるコードで指定されます。命名規則の詳細は、この後のセクションで説明しています。

大まかに言って、OPC サーバーは、サーバー、グループ、アイテムという複数のオブジェクトで構成されています。OPC サーバー オブジェクトは、サーバーに関する情報を維持し、OPC グループ オブジェクトのコンテナの役割を果たします。OPC グループ オブジェクトは、それ自体に関する情報を維持し、OPC アイテムを格納して論理的に整理するためのメカニズムを提供します。

OPC グループは、クライアントがデータを整理するための手段となります。たとえば、特定のレポートまたはオペレータ ディスプレイの中のアイテムを表すグループを作成できます。データは、読み取り、書き込みが可能です。クライアントとグループ内のアイテムの間に例外ベースの接続を作成し、それらを必要に応じて有効化したり無効化したりすることもできます。OPC クライアントは、OPC サーバーがデータ変更を OPC クライアントに提供する頻度を設定できます。グループには、パブリックとローカルの 2 つのタイプがあります。パブリックは複数のクライアントにまたがる共有が可能ですが、ローカルはクライアントのローカルとなります (パブリック グループのセクションで、その意図、目的、機能などの詳細を確認してください)。さらに、パブリック グループには、特定のオプション インタフェースがあります。クライアントは、各グループ内に 1 つまたは複数の OPC アイテムを定義できます。

OPC アイテムは、サーバー内のデータ ソースへの接続を表します。カスタム インタフェースの観点からすると、OPC アイテムがオブジェクトとして OPC クライアントからアクセスされることはありません。このため、OPC アイテム用の外部インタフェースは定義されていません。OPC アイテムへのアクセスはすべて、その OPC アイテムを含む OPC グループ オブジェクト、つまり、その OPC アイテムが定義されている場所を介して行われます。

各アイテムには、値、品質、タイム スタンプが関連付けられています。値は VARIANT 型であり、品質は Fieldbus の仕様と同様です。

アイテムは、データ ソースではなく、データ ソースへの接続です。たとえば、DCS システム内のタグは、OPC クライアントによって現在アドレス指定されているかどうかにかかわらず存在します。OPC アイテムは、アドレスが参照するデータの実際の物理的なソースではなく、データのアドレスを指定するだけのものと考えてください。

OPC Data Access の詳細

OPC は、もともとはネットワーク サーバーのデータへのアクセスを目的として設計されたものですが、OPC インタフェースはアプリケーション内の複数の場所で使用することができます。最も下位のレベルでは、物理的なデバイスから SCADA または DCS への、あるいは SCADA または DCS システムからアプリケーションへの生データを取得することができます。OPC のアーキテクチャと設計によって、単一のオブジェクトを通じて異なるノード上で実行されている、多数の異なる OPC ベンダーが提供する多数の OPC サーバーのデータに、クライアント アプリケーションからアクセスできるようになります。

OPC の仕様には、COM インタフェース、つまりインタフェースは何なのかが規定されています。それらのインタフェースの実装については規定されていません。インタフェースがそれらを使用するクライアント アプリケーションに提供することが期待される動作が規定されています。その中には、アーキテクチャとそれらのアーキテクチャに最適と思われるインタフェースの説明が含まれます。あらゆる COM 実装がそうであるように、OPC のアーキテクチャはクライアント / サーバー モデルであり、OPC サーバー コンポーネントが OPC オブジェクトにインタフェースを提供し、それらを管理します。

OPC サーバーの実装時に検討すべき独自の事項がいくつかあります。最大の問題は、非共有の通信パスを経由して物理的なデバイスにデータを転送する頻度です。このため、OPC サーバーはローカルまたはリモートの EXE となり、その中に、物理的なデバイスから効率的にデータ収集するコードが含まれることが期待されます。

OPC クライアント アプリケーションは、指定された OPC のカスタム インタフェースおよびオートメーション インタフェースを通じて OPC サーバーと通信します。OPC サーバーは、カスタム インタフェースの実装が必須であり、オプションでオートメーション インタフェースを実装できます。

InProc (OPC ハンドラ) を使用してインタフェースをマーシャルし、OPC オートメーション インタフェースのアイテム レベルの機能を追加で提供することができます。

また、さまざまなクライアントから要求されたデータ アクセスを OPC サーバーが統合して最適化し、物理的なデバイスとの通信の効率化を図ることも期待されます。入力 (読み込み) では、デバイスから返されたデータは、さまざまな OPC クライアントによる非同期分配と同期収集のためにバッファされます。出力 (書き込み) では、OPC クライアントに代わって、OPC サーバーが物理的なデバイスのデータを更新します。

現在最新の OPC Data Access 仕様はバージョン 3.0 です。KEPServerEX は 2005 年以降、OPC DA 3.0 を完全にサポートしています。

OPC の歴史

1994 年、産業分野の広範な専門領域のベンダーが集まり、OPC 協議会という組織を結成しました。OPC 協議会は、高速で堅牢な方法でデータを共有できるソフトウェアやアプリケーションを開発するために、あらゆるベンダーが使用可能な単一のクライアント / サーバー仕様を策定することを目標として掲げました。そうした仕様により、各ベンダーが重複する開発作業を行わなければならなくなるような独自スキームが不要になります。

OPC 協議会が策定した最初の仕様が、1996 年前半にリリースされた Data Access Specification 1.0a です。この仕様により、ベンダーはクライアント / サーバー ソフトウェアを迅速に開発できるようになりました。

OPC 協議会および Data Access 仕様の主な目的の 1 つは、クライアント アプリケーションのベンダーが一連の独自の通信ドライバーを開発する必要性を排除することでした。多くのベンダーにとって、さまざまな通信ドライバーの開発は、クライアント アプリケーション自体の開発作業よりも多くの労力を必要とする作業でした。OPC テクノロジの採用により、ベンダーは、クライアント アプリケーションの開発にほぼ専念できるようになりました。Data Access 仕様では、クライアントとサーバー アプリケーションの両方の構成要件を定義しています。この仕様に適切に従っていれば、クライアントのベンダーは、データ アクセスのために必要な接続性が産業用機器向けの OPC サーバーによって提供されることを前提とすることができます。これにより、市場投入までの期間や信頼性といった問題が OPC アプリケーションの制約とはならなくなります。

OPC のエンド ユーザーには、アプリケーションの問題の解決に最善のソフトウェアを選択できるという付加的なメリットもあります。従来、アプリケーション ソフトウェアが適切な通信ドライバーを備えていない場合や、利用可能なドライバーが適切に機能しない場合の唯一の解決策は、アプリケーション ベンダーに必要なドライバーの開発または既存のドライバーの修復を求めることでした。しかし通常は、いずれの解決策も時間がかかりました。OPC を採用している場合、エンド ユーザーは、クライアント アプリケーション ベンダーのリソースの限界に縛られることがなくなります。ユーザーは、新しいドライバー要件を解決したり、パフォーマンスの問題を解決したりするためのベンダーを、さまざまな OPC サーバー ベンダーの中から選ぶことができます。同様に、クライアント アプリケーション ベンダーも、通信関連の問題やニーズへの対応作業に煩わされることなく、自社の主力製品の継続的な改善に集中できるようになりました。

Kepware が OPC 環境で目標としているのは、OPC という方程式の一構成要素であるサーバーの主要プロバイダとなることであり、信頼性が高く使いやすい製品の提供によってそれを実現することです。KEPServerEX は、長年にわたる通信ドライバー開発と OPC テクノロジを基盤としています。

ここでは OPC について説明してきましたが、OPC 仕様はどのように機能するのでしょうか。

OPC 規格の詳細については、OPC 協議会のページにアクセスするか、Kepware の『Understanding OPC (OPC について知る)』電子ブックをダウンロードしてご確認ください。