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