OTとITを繋ぐプロトコル「OPC UA」について
前置き
OPC UAについて以前に触ったことがあるので知っている部分を知っているだけ解説します。
想定読者
ある程度、OPC UAが分かっている人である。少なくとも以下で書かれているくらいのことは知っていることを期待しています。
OPC UAとは
概要
OPC UA(OPC Unified Architecture)とはFAやPAシステムのOTとITを繋ぐアプリケーションプロトコルです。
教科書通りの概要なんかはいろいろなサイトにあるのでそちらで知識をINPUTしてくれていることを期待しています。個人的にオムロンのHPはかなり詳しく説明してあった参考になります。
EU主催のIndustire4.0のRAMI(Reference Architecture Model Industrie 4.0)で標準通信として推奨されたものです。
いわゆるITネットワークは標準化が進んでおり通信プロトコルも絞れてきているのだが、工場内のOT(制御技術)ネットワークに関しては制御機器のツールベンダが推奨しているプロトコルが乱立しています。結局それでは制御機器のベンダごとにドライバを作る羽目になり、会社としては儲かっても国の視点からすると非効率的だということで標準化されることになったと思われます。あとその他、サイバーセキュリティへの対応も視野に入れているようであります。その手の話に関しては上記のオムロンの資料に書いているので詳しく読んでほしいです。
一応、最終的に目指す姿としてはOPC UAサーバを積んだ機器をOT層とIT層の間くらいにポン置きするだけじゃなくてネットワーク上のすべての機器、IT層のパソコンやPLCだけでなくフィールド機器まで積んで同一ネットワークでつなぐことを志向しているらしいです。ただしするをそれにはOPC UA自体はプロトコルとして緩すぎてフィールド機器に使うにはリアルタイム性が足らない部分があります。そのためにOPC UA FXなる規格ができてきています。
データ交換規格(≠プロトコル)
ざっくり「アプリケーションプロトコル」と説明しましたがが、OPC UAの仕様書等を読んでもらうとわかる通り、公式的には「データ交換規格」となっています。公式としては頑なに「データ交換規格」としておりどうやらこだわりポイントのようです。
意味するところは正確にはわからないが、データフォーマットの標準化も視野に入れているのかもしれないです。
数年前にAIがフィーチャーされた際に多くの大企業の社長が「うちには本物のデータがあるからGAFAに負けない。」と豪語していましたが、データはそのままでは利用できないです。データはAIに食わせやすい形に整形しないといけないです。特に工場のデータはフォーマットも計測方法もバラバラでそのままでは正直、使い物にならない(整形しようとしてもどうにもならないかもしれない)。ただ、OPC UAサーバという仲立ちするものを現場のフィールド機器とデータベース等の間に噛ませて一旦、エッジでOPC UAのフォーマットに変換しておけばデータのフォーマットが統一され、利用しやすい形になります。
「データ交換規約」とこだわるのはそういうことなのかもしれないです。
Microsoftの影響
OPC UAはIndustrie4.0の策定にあたっていきなりドイツに降ってわいたものではないです。前身があります。それがOPC(OLE for Process Control)です。これはMSのDCOMという要素技術をベースとしたもので目指すところはOPC UAと比較的近いです。ただ色々オープンでなく、プラットフォームがWindowsに限定されていなかったためそこまで普及しなかったです。
OPC UAはそれを下敷きにしたものです。もちろんOPCの反省を踏まえ仕様等をオープンにしており、さらにプラットフォームも特に限定していないです。WindowsはもちろんのことLinux等の他の汎用OSやRTOSにも搭載可能です。
ただしMSが一枚かんでいるようではあります。以下リンクの「Officers」を見ていればわかる通りシーメンス等の機器ベンダと一緒にMSの社員もいます。
それが関係あるのかないのかはよくわからないですが、アーキテクチャのキレイさ等よりもとにかく機能を詰め込めるだけ詰め込んで使いたい人が使ってねというMS流の思想が垣間見えます。実際、以下リンクでわかる通り、機能がとにかく多いです。
目指しているところ
軽量UNIXサーバ？
上記のようにMSが一嚙みしている雰囲気は感じるが目指している姿は軽量UNIXサーバ的なものに見えます。組み込み機器等のために余計な部分を抜いて必要な部分に付け加えたような。
例えばデータの表現の仕方がその最たる例です。
OPC UAクライアントを積んだGUIツールをサーバにつなぐと以下のような画面が出てきます。この画像が示す通り、OPC UAサーバはディレクトリのような階層構造で整理してデータを見せています。
出典：https://www.unified-automation.com/products/development-tools/uaexpert.html
便宜的にファイルが入っているように見えますがこれはUNIX系で言うところのデバイスファイルに相当する存在に見えます。サーバ自身の機器内に入っているデータに加えて、サーバ搭載機器の下位にありネットワークでつながっている別の機器内のデータもファイル(OPC UAではこれをNodeと呼ぶ)として表現されています。それに対してクライアントから読み書きするとサーバ搭載機器からネットワークを経由してファイルの実データが置かれている場所へ読み書きされます。
またOPC UAサーバ上のNodeにはNodeIdというUNIX系で言う所のinode番号ライクなものが振られています。一応、ディレクトリの構造を取っているので上位のディレクトリからの参照情報もあり、rootからたどっていけば参照できるのだが、OPC UAサーバ内のNodeが固定ならシンプルにNodeIdを直指定することで効率的にアクセスすることが可能であります。
このようになんとなくUNIX系のファイルシステムの思想が取り入られています。
サービス指向アーキテクチャ
OPC UA自体はサービス指向アーキテクチャであり、サービスという単位で機能が定義されています。その中で解説しがいのありそうなものをピックアップして解説します。
Monitored Items and Subscription Service Set
名前からなんとなく気づく人もいるかもしれないがやりたいことはPubSub的なことのようです。
細かい仕組みは仕様書等に記載していますがざっくり説明するとクライアントが監視したいNodeのNodeId等の情報を詰め込んだ定義した定義データをMonitoredItems Serviceを使用してOPC UAサーバに投げると、サーバが一定周期ごとに自動的にクライアントにデータを返してくれる(Subscription)ことです。
ミソとしては一定周期ごとに機械的にデータを投げるのではなく変化があった場合のみデータを返してくれることとサーバが勝手に返してくれることです。これによりクライアントやネットワークに負担をかけず特定のデータを監視できます。ただデータを監視するだけならクライアントから一定周期でREADすればいいがそれだとデータが変化してない場合もパケットを流さないといけなくクライアントやネットワークへの負担が大きいです。もちろんその分、サーバに関しては一定周期ごとに指定されたNodeのデータが変化してないか前回値と比較しないといけなく負荷が大きいです。
おそらくすみわけとしてはなんとなく監視しておきたい(=ReadOnly)ものはSubscriptionして、リアルタイムに読みたいNodeや書き込みを行いたい場合はREAD/WRITEサービスを使用するのだろうと思われます。Subscriptionだとどうしても監視周期に縛られるのでリアルタイム性に欠けます。そして監視周期を短くするとサーバへの負荷が大きく使い物にならないです。
ちなみに補足しておくとSubscriptionサービスとは別にOPC UA自体は本家本元のPubSub通信を行うことができます。
参考資料
仕様書
仕様書は以下のリンクに存在しています。
OPC Foundationのgithubリポジトリ
OPC Foundationはgithubリポジトリを持っており様々なサンプルソースを手に入れることができます。
リファレンス実装
ただしC言語のOPC UAサーバのリファレンス実装だけはなぜかSoftingの方に入っています。
フォルダ構成はOSI参照モデルのレイヤーに準拠して分けられており、レイヤー間はガチガチのレイヤードアーキテクチャとなってて純粋にミドルウェアの実装として参考になりそうだと思います。
Discussion