OPC FOUNDATION

　 　

　

ＯＰＣにお寄せ頂いた質問事項をいろいろ集めてみました。少しでも皆様の参考になればと掲載しております。

Q1： Windows環境下での動作が基本という事ですが、その他のOS（Linux等）の対応、ＰＣ以外でのハードウェア（ＰＤＡ、携帯電話等）の対応は可能でしょうか。今後の見通しはどうでしょうか。
A1： Windows環境下での動作が基本となります。ヨーロッパのベンダーにてLinuxでサポートしたとの情報を得ていますが、詳細は不明です。また日本国内では現在Windows環境下の製品のみとなっています。

Q2： OPC-DX、OPC-XMLの製品はすでに発売されているのですか？発売されていない場合、その開発状況はどうでしょうか？
A2： 日本国内ベンダーでの製品は未だありません。ベンダーの開発状況については、調査しておりません。ただし、XML-DAの場合、従来のDAサーバをラッパーするXML-DAサーバをOPC協議会より提供しています。（会員のみダウンロード可）

Q3： ＯＰＣに関してプラントメーカがエンジニアリングを行う要素があるのか
A3： 従来行っている要素からみて、OPCを採用することで、特に要素が増えることはないと思います。
但し、作業としてネットワーク環境の構築、アクセスするデータの登録、I/Oリストの作成などがエンジニアリング要素であると考えられますが、これもネットワークを使用することですから従来と変わらないです。

Q4： ＯＰＣを採用する場合に、プラントメーカは制御装置メーカに対しどのような情報、条件を与えなければならないか
A4： OPCを採用する宣言を行って、ロゴ付きの製品とする宣言をしていただければ良いでしょう。

Q5： エンジニアリングメーカとしてＯPCインタフェースをどの程度まで意識して設計を行う必要がありますか？
A5： 接続のためのネットワーク環境（例えばドメインを使用するか、しないかなど）については、システム毎により異なるため、これらを意識する必要はあります。
それ以外に意識することは、特に無いと思います。
OPCを使用する場合は、入出力点を決めるパス・アイテム名をインタフェースとして決定する必要がありますが、所謂、I/Oリスト作成です。この作業は、従来も行われている作業ですから、変わりないです。

Q6： ＯＰＣそのものの仕組みはどこまでユーザまたは、プラントメーカに公開されているのですか。開示されてない部分の健全性、信頼性は保証されていますか、また現状では誰が保証しているのでしょうか？
A6： インタフェース仕様までは公開されています。健全性・信頼性の問題については、サーバ側・クライアント側の双方がシステム的に動作させ双方で作り上げるもので、これは、従来と変わらないと思います。OPCを採用するメリットは、インタフェースのトラブルが発生した時に、何を基準に問題解決をはかるかという課題になりますが、その時に、公開されているOPCインタフェース仕様に準じているのか、OPCが主催のInteroperability　Workshopで、OPC仕様に合ったOPCインタフェースであったかの結果を元に、問題解決にあたる事ができます。これは、重要なことだと考えます。

Q7： ＯＰＣの規約は、どこまで決められているのですか？　決められている範囲以外でベンダー間の仕様が異なり、その結果接続できなくなるようなことが起こらないのでしょうか？
A7： OPC仕様の範囲以外のインタフェースを導入するには、従来と同じく接続双方の事前話し合いが必要と思います。そこについてはOPCの範囲から外れますので、この問合わせの範囲に入らないと思います。

Q8： ＤＣＳメーカ毎で細かい仕様が異なっており、接続できないような場合はないのですか？
A8： データのやり取りにおいて、そのデータの意味がベンダー間で異なる可能性はあります。ただし、それが原因でデータのやり取りが出来なくなることはないと思います。当然、接続相手同士の打合せは必要と思いますが。

Q9： 相互接続テストはどこまで確認しているのですか？
A9： OPC協議会としては、Compliance Test、Interoperability Testと２つの相互接続のためのツール及び機会を用意しており、会員は、ツールを使って単独テストを行い、OPCの仕様に合わない項目は、ワーニングとしてその場で確認ができ、不具合箇所を治すことができます。さらに、相互接続テスト（Interoperability Workshop）は、各ベンダーが製品を持ち寄り、クライアント製品・サーバ製品間での接続とデータの送受信が出来ることを確認し、クライアント・サーバの両ベンダーにより、判定し申請します。Compliance TestでOPC仕様に適合しているかの妥当性を確認した製品は、登録のロゴが送られます。

Q10： 他地域のOPC製品（米国、欧州ならびに中国）との相互接続性はどのようにして保証されているのですか？相互接続テストの対象は、上記他地域の製品もふくまれているのですか？
A10： OPCでは、欧州、北米、日本で、年に一回ずつ相互接続テスト（Interoperability Workshop）が開催されており、これに参加し、ロゴを送られた製品同士の接続は、問題なくつながると思います。中国は立ち上がってまだ、日にちが経っていないのでこれからです。OPCインタフェースを持つ製品を採用するとしたら、相互接続テスト（Interoperability Workshop）に参加して相互接続性が確認されたベンダー製品を指定されることをお勧めします。OPCとしては、ここまでで、文書で保証すると言う活動は現状行っておりません。

Q11： ＯＰＣサーバやＯＰＣクライアントがサポートしているＯＰＣのバージョンの相違による問題（接続できないなど）はないのでしょうか。（ＤＣＳ　OS、Windowsではバージョンの違いにより処理が出来ないケースもあったようですが）
A11： OPCのバージョンにより異なるインタフェースが実装されていると場合によっては問題発生する可能性はあります。厳密に申し上げますと、上のバージョンで加えられた仕様部分を使用すると下のバージョンが理解できなくなると言うことです。できましたら、クライアント・サーバの接続についてはOPCのバージョンを指定することをお勧めします。

Q12： 非会員会社の製品との接続は問題ないのでしょうか？
A12： 非会員の製品についてのコメントは、OPC協議会としては、できません。OPC会員向には、Compliance Test、Interoperability Testと２つの相互接続のためのツール及び機会を用意していますが、非会員の場合それらを利用することが出来ません。また、毎年行われているInteroperability　Testに参加する意味は、年々増えているOPC製品との総当り接続テストでの接続確認及び接続性の性能向上に対応していける最大の効果があります。ですから、OPC会員の製品でInteroperability　Testに参加している製品をOPC-Fのサイトで確認して頂いてそれをご採用されることをお勧め致します。

Q13： 異なるベンダー製品（ＯＰＣサーバ／クライアント）間におけるデータアクセスに不具合が生じた場合,対応処置はどちらのベンダーが行うのでしょうか。ＯＰＣ協議会が調整役となる場合はありますか？
A13： OPC協議会が調整役として活動することは現状行っておりません。で、問題が起きた場合どうするかですが、公開しているOPC仕様を基準にご判断頂ければ良いと考えます。また、相互接続テスト（Interoperability Workshop)に参加した製品であるかによって、ご判断頂ければ良いと考えます。問題が起きた場合の立ち帰る基準がOPCで公開しているとお考え頂ければ幸いです。

Q14： OPCクライアントの内作を考えた場合、使用インタフェース（Ｃ++、VB、.NET）により開発環境が異なったり、異なるベンダーのラッパーは同一ＶＢプロジェクトに共存できないなどのデメリットがあるが、今後解決に向けての動きはあるのですか？
A14： VBの場合、OPC協議会は共通のオートメーションラッパを提供しています。C++および.NETについては共通のインタフェースを用意しています。で、お問合わせの共存できない件は、OPCの問題と言うよりは、Windows、ネットワークの課題を中心とする問題なので、OPC協議会の範囲を超える問題と認識しております。よって、的確な回答は難しい次第です。

Q15： ＯＰＣ技術そのものに対するサポート窓口のようなものがありますか？通常は採用しているベンダーが窓口になると考えられますが、アプリケーションソフトを内作する場合にどこに問合わせればよいのですか？　ＯＰＣ協議会でよいのでしょうか？
A15： OPC協議会としては、アプリケーション作成ガイドなどの書籍の発行を行っていますが、サポートを実施することは現状行っておりません。やはり利用するサーバベンダーに問合わせていただくのが良いかと思います。

Q16： ＯＰＣ協議会とマイクロソフト社の関係はどのようなものでしょうか？例えば、ＯＰＣパッケージに影響を与える不具合がOS（Windows）自体に発見された場合どのように対応されるのですか。Version管理はどのように行われていますか。
A16： マイクロソフトは、OPCの会員でもあります。マイクロソフトからの最新技術情報の開示、OPCからのマイクロソフト社への提案などを実施し、共に産業用途のために製品の立案から規格を行っています。当然OSに依存するようなバグをOPC協議会として発見した場合は、マイクロソフト社への修正依頼は実施しています。

Q17： ＯＰＣを採用する場合に、エンジニアリングメーカは制御装置メーカに対しどのような情報、条件を与えなければならないのでしょうか？　従来と異なる点があるのでしょうか？
A17： OPCのサーバの能力はベンダー毎により異なります。システム上の確認として、OPCクライアントとしてどの程度の性能を期待しているか等の利用レベルに関する条件は必要となるのではないでしょうか。

Q18： ＯＰＣサーバを使うメリットに設備ごとにシーケンサやSCADAが代わる場合があるが、その他のシステム構築を含めたメリットはどの程度あるのですか？
A18： OPCを採用するメリットとしては、
①OPC仕様の採用宣言をすることにより、異なるシーケンサや異なるSCADA製品を組み合わせることが可能になります。（マルチベンダーによるシステム構築が可能）。
②現場でのシステム接続作業で、基本接続確認の時間が少し短縮できます。
③接続トラブルが発生した時に、インタフェースの部分は、公開されているOPC仕様を参考にどのように修正すれば良いかが解かります。この時のシステムのネットワークの能力確認作業は、従来通り必要です。

Q19： 既設設備に対し、ＯＰＣを導入する場合にコスト及び改造工事として、容易にシステム構築が可能なのですか。また製造設備を止めなくとも改造が可能でしょうか。
A19： OPCサーバを提供するベンダーの仕様により、既設を停止せずに実施可能かどうかは異なります。多くの場合は、既設に影響なく実施できますが、最終的な確認はベンダーにご相談ください。

Q20： ユーザサイドから見たメリットは具体的にどんな点があげられますか？　またコストインパクトはどのくらいあるのですか？
例）データの追加・削除などのメンテナンス性は、容易にユーザ対応が可能ですか。
A20： 一番大きなメリットは、異なるベンダーの製品を相互接続するドライバ開発をその都度行うことで、コスト高になるのをOPC採用で、コスト削減になります。OPCを採用することにより設備を追加したいとか、海外からの装置を組み入れたいなどが発生した時に、OPC仕様を持った装置ということで、相互接続の詳細仕様確認のリスクは、軽減されます。もちろん、OPC仕様のバージョン確認は必要です。

Q21： インターネット通信でのリアルタイムによるデータ通信は、どの程度の速度、及びデータ量が確保されるのか。
A21： インターネットのデータ通信において、通信速度や通信量などリアルタイム性を保証することは難しい課題です。OPC-XMLではそのようなリアルタイム性の確保のために、データのバッファリング機能の仕様を定義しています。OPC-XMLサーバ内でデータのバッファリングを行い、通信速度を保証できないインターネット経由のアクセスに対して、バッファリングデータを返すことで擬似的なリアルタイム性を確保するように仕様が定義されています。
XMLだからと言って、必ずしもインターネットであるというものではありません。イントラネットでのXML採用も考えられます。しかし、msecレベルのリアル性を求める場合は、XMLという選択ではなくなると思います。XMLのメリットはある訳で、その目的と要求能力でシステムの構造をお考え頂いて選択して頂くことになると思います。

最終更新日：2005年10月27日