.NETのOPC DA 2チートシート

先日、OPC DA 2.05aプロトコルを使用してリモートサーバーコールを設定することに多くの手を加えなければならず、この情報は事前に知っていれば非常に役立ちます。



1. OPC DA、特にOPC DA 2.05aとは



一般的に、OPCは、たとえばSCADAシステムなどのさまざまな自動化オブジェクト間の相互作用を規制する一連のオープンプロトコルです。 OPC DA(データアクセス)はこれらのプロトコルの1つであり、デバイスまたはソフトウェアコンポーネントとのデータ交換を提供します。 私の場合、このプロトコルに従って、SCADAシステムから定期的にデータを収集する必要がありました。 そして最も重要なことは、OPC DAはCOMテクノロジーに基づいているため、OPCサーバーとの相互作用は基本的にCOMサーバーとの相互作用に帰着するということです。



2.ライブラリとは





Opc Foundationのバイナリ


それらはOPC .NET API 2.00再頒布可能と呼ばれます -それらをそのようにダウンロードすることはできません。あなたは「メンバー」である必要があります(=登録してお金を追加します)。 このライブラリが依存するOPCコアコンポーネントもあります。 両方ともルートトラッカーで見つけることができます。 一般に、「オープンスタンダード」を推進している企業であるOpc Foundationからライブラリを取得するために何かを支払う必要がある理由は完全には明らかではありません。

このライブラリについて何が言えますか。 ドキュメントはどこにもありません。また、APIは最適な方法で構築されていません(たとえば、同じ名前のインターフェイスとクラスがいくつかありますが、異なる名前空間では、非常に不便です。常にオブジェクトブラウザにアクセスして、必要なクラスを確認する必要があります)ただし、機能は完全です-OPCサーバーでできることは何でもできます。 ちなみに、便宜上、リフレクターを使用してアセンブリを実行し、ソースで既に作業しました-幸運なチャンスによるすべての逆コンパイルの問題は他のプロトコル(OPC AE、OPC HDA)で発生し、私はそれらを不必要に捨てました。 誰かが興味を持っているなら、私は解決策を送ることができます。



Advasolのコンポーネント


有料コンポーネント(および非常に高価)。 パスワード(!)が必要なインストーラーである評価版をダウンロードしましたが、パスワードはメールで送信されました。 このセットで最も有用なコンポーネントは、OPCのテストクライアントです-接続してOPCサーバー内の内容を確認できるwinformsアプリケーション。 ライブラリ自体は見ませんでした。ライブラリは難読化されており、30分という制限時間があるため、プログラムを再起動する必要があります。 しかし、テストクライアントを使用するには、64ビットシステムがあり、テストクライアントアセンブリはターゲットプラットフォーム= AnyCPUでビルドされ、32ビットWindowsでは32ビットアプリケーションとして起動し(すべてが正常に機能した)、64ビットであったため、 64ビットのような。 これにより、「CLSIDが登録されていません」という形式のCOM相互運用コードにエラーが発生しました。 そして、secpol.msc、dcomcnfg、compmgmt.mscを掘るために何かが間違って設定され、2日間で殺されたと思いました。 幸せな偶然の一致によって、私は別の車からクライアントを開始することを推測し、すべてが明らかになりました。 ILDASMとHexエディターを使用して、TargetClatformフラグのオフセットを(CLRヘッダーの先頭から)決定し、そこに2番目の32BITREQUIREDビットを追加し、機能しました。 結論-COM Interopが機能しない場合は、まずプラットフォームの適合性を確認してください。 ところで、クライアントも難読化され(SmartAssemblyを使用)、そのCLRヘッダーは最後に配置されました。



OPCDOTNETライブラリ


codeproject.comの愛好家のライブラリ。 何も言えませんが、OPCサーバーとのローカルインタラクションを実装した私の前任者が使用したのは彼女のコードでした。 記事に書かれていることから判断すると、それは単にローカルでのやり取りのためであり、意図されています。 長所-利用可能なソース、テストクライアントの存在、依存関係の欠如。



3.ライブラリを使用せずにコードを書くことは可能ですか



原則として、COM / DCOMアプリケーションとの対話の経験があれば、これで複雑なことはありません。 そして、私のように、これらの技術に特に精通していない人には、OPC Foundationからの逆コンパイルされたライブラリソースを見て、コードを書くことをお勧めします。 実際、OPCサーバーとやり取りするには、必要なインターフェイスで相互運用を行い、それらを取得してメソッドをプルするだけで十分です。



4.問題



-テストクライアントがエラーで接続しないRPCサーバーが利用できない-ポートの可用性を確認してください、少なくともポート番号135(メインDCOMポート)。



-アクセスが拒否されました-サーバーとクライアントの両方を設定する必要があります。 以下のリンクをご覧ください



-CLSIDが登録されていません-コアコンポーネントがインストールされているかどうかを確認してください。インストールされていない可能性があります。 または、相互運用を実行するターゲットプラットフォームアセンブリを確認します。 AnyCPUがあるかもしれませんが、x86でなければなりません。



-CoCreateInstanceExは有効なCOMオブジェクトを返しますが、キャストすると、アクセス拒否(0x80070001)がCOMインターフェイスにフォールアウトします。 私はこの問題を半日いじりました。 このことは、サーバーにアクセスするためにユーザーとパスワードを指定する必要があるときに起こります。 CoCreateInstanceExを呼び出して、この前にSERVER_INFOを記入し、オブジェクトへの参照を取得します。 ただし、次のQueryInterface呼び出しでは、オブジェクトの受信時に指定したアクセスパラメーターが保存されないため、アクセスが拒否されます。 解決策は、COM関数の既定のセキュリティ設定を設定するマジック関数CoInitializeSecurityを呼び出すことです。 コード:



[DllImport("ole32.dll")] private static extern int CoInitializeSecurity(IntPtr pSecDesc, int cAuthSvc, SOLE_AUTHENTICATION_SERVICE[] asAuthSvc, IntPtr pReserved1, uint dwAuthnLevel, uint dwImpLevel, IntPtr pAuthList, uint dwCapabilities, IntPtr pReserved3); public static void InitializeSecurity() { int errorCode = CoInitializeSecurity(IntPtr.Zero, -1, null, IntPtr.Zero, 1, 2, IntPtr.Zero, 0, IntPtr.Zero); if (errorCode != 0) { throw new ExternalException("CoInitializeSecurity: " + GetSystemMessage(errorCode), errorCode); } }
      
      







この関数を呼び出すと、RPC_E_TOO_LATEエラーが発生する場合があります。 このエラーは通常、起動時に暗黙的にCoInitializeSecurityを呼び出すVisual Studioホストプロセスが原因で発生します。 問題を解決するには、プロジェクト設定でホストプロセスの使用を無効にするだけで十分です。



この問題に関する有用な情報のリンクがいくつかあります。

Stackoverflowを使用している人々がどのようにそれを理解したか

備考付きの既製の相互運用機能

Microsoftはこの問題に関して開発者から提供しています



5.関連リンク



OPC Training Instituteは、問題が発生した場合に役立つ多くのよく書かれた記事があるサイトです。 たとえば、DCOMを構成する方法、RPCサーバーが利用できないというエラーの考えられる原因など。 登録が必要です。登録は無料です。



DCOM Tuning Tutorials-チューニングのためのもう1つの適切に設計されたチュートリアル。



All Articles