OPC批判
自動化されたプロセス制御システムの開発により、PLCとソフトウェアのメーカーは、異なるプロトコルで動作するデバイスとソフトウェア間の相互作用の問題に直面しました。 Microsoftのイニシアチブでは、この問題の解決策はOPCプロトコルでした。これはもともとDCOMテクノロジーに基づいていました。 このプロトコルは現在どこでも使用されており、仕様の命名法はかなり発達していますが、実装の大部分はDCOMテクノロジーに基づいており、多くの問題を引き起こしています。
- ネットワーキング。 OPCには、MicrosoftのDCOMテクノロジーに基づくクライアントノーザンアーキテクチャがあります。 DCOMでのネットワーク通信のサポートは制限されており、ホストセキュリティの追加構成が必要です。 したがって、マルチレベルの企業イントラネットネットワークでのOPCの実装は難しく、インターネット経由のデータ転送は単に不可能です。 この欠点は、MESまたはERPレベルのシステムを構築する場合に重要です。これにより、無制限のDCOMの形式でデータを相互に送信し、OPCデータを提供する特別なゲートウェイが必要になります。
- Windowsへのバインド。 DCOMテクノロジはWindows OSのみをサポートします。これにより、コントローラー部分にOPCサーバーを展開し、モバイルデバイス用のクライアントプロセス制御ソフトウェア（iOS、Androidなどに基づく）を作成できません。 同じ理由で、Unix（Linux）に基づいたウイルス耐性システムを使用してデータを収集および保存することはできません。
- 構成 OPCテクノロジーの主な概念はタグであり、信号に関するデータを取得するには、OPCサーバーの構成と各クライアントソフトウェアの構成で信号を「取得」する必要があります。 したがって、構成のコストは、顧客の数と自動化システムのレベルに比例して増加します。 さらに、多くの場合、これらのレベルまたはクライアントはさまざまな組織からサービスを受けているため、新しいデータをすぐに見つけられない可能性があり、システムの無関係な読み取りにつながります。
- 閉じたプロトコル。 OPCテクノロジーは「オープン」テクノロジーとして位置付けられていますが、そうではありません。 仕様および開発ツールへのアクセスは、OPC Fundationのメンバーにのみ有料で提供されます。 このようなビジネスモデルは、大規模なメーカー同士を結集させ、残りはすべて完成品の消費者となりました。 OPCベースの自動プロセス制御システムの分野での些細な作業であっても、何かを購入する必要があります。
ご覧のとおり、代替の検索を開始するには多くの問題があります。
産業オートメーションのREST
RubyOnRailsで趣味としてWebアプリケーションを開発していたとき、RESTモデルを使用してデータ転送の問題を簡単に解決できることに驚きました！ 次に、このようなアプローチをACS TPに適用する可能性について考えました。 後にこのアイデアはオーストラリアの専門家であるTom Todenhamによって既に策定されていることが判明したため、 ここでこのトピックに関する彼の作品（または私の翻訳 ）を読むことができます。 このアイデアへの関心を喚起するために、その利点についての論文を紹介します。
- ネットワーキング。 HTTPプロトコルをトランスポートとして使用すると、インターネットおよびマルチレベルの企業ネットワークを介してデータを転送できます。 また、OPCテクノロジーとは異なり、ノードの追加構成は必要ありません。
- プラットフォームに依存しません。 HTTPはすべてのオペレーティングシステムでサポートされているため、モバイルデバイス用のクライアントを作成できます。 さらに、HTTPの単純さにより、中間ゲートウェイを使用せずにコントローラーレベルでRESTサーバーを実装し、それらからデータを削除することができます。
- 構成 RESTの主な概念はリソースであるため、データへのグループアクセスが可能（SQLのテーブルへのアクセスと同様）であるため、システム内の新しいデータは追加の構成なしで自動的に処理できます。 また、HTTPを使用すると、リソースからデータを受信できるだけでなく、それらを作成および構成できるため、ユニバーサルメソッドを使用してクライアント側からRESTサーバーを管理できます。
- 開放性。 RESTは、すべてのプログラミング言語とプラットフォームでサポートされるデータ（HTTP、HTML、XML、JSONなど）の転送と表示にオープンスタンダードを使用します。これにより、ツールへの投資を最小限に抑えて自動化アプリケーションを作成できます。
単純なRuby実装の例として、 私の記事を読むことができます。 Arduino周辺機器へのRESTアクセスのためのプロジェクトもあります-RESTdunio
現状と今後の計画
REST-PCAの記事の著者であるTomは、サイトxpca.org/を作成し、RESTスタイルのデータ交換を含む産業オートメーションシステムXPCA（eXtensible Process Control Architecture）の新しいアーキテクチャの作成を開始しました。このトピック-XPCA Googleグループについては、現在非アクティブです。 著者によると、新しいプロトコルの仕様はクラウドソーシングに基づいて開発され、公開される予定です。
次に、.NET \ Mono- Galileiで XPCAサーバーの最初の実装のオープンソースプロジェクトを立ち上げました。 現時点では、Galileiは構成用のRESTインターフェイスと乱数シミュレーターをサポートしています。近い将来、ModBusとOPCのドライバーを作成する予定です。 プロジェクトを支援してコミュニティに参加したい人がいれば、私はとても幸せです。
ご清聴ありがとうございました）