前々から噂には聞いていた OPC-UA に対して、私的な興味が出てきたので調査しました。
Item | Description |
---|---|
Research Date | 2019/04/08 |
OPC-UA Version | 1.04 (2017-11-22 Release) |
本家の仕様はこちら(要ユーザ登録)
OPC-UAとは
- OPC Unified Architecture の略
- OPCはObject Linking and Embedding for Process Controlの略
- 前身があり、OPC Classic (か省略してOPC)と呼び、こちらはMSのCOM/DCOMを元に、様々なベンダーにより通信規格がバラバラで断絶されていたPLCへのアクセスを行うために1997年ごろに登場した
- OPC-UAは OPC Classicからさらにアクセス方法などを汎化・高度化しマルチプラットフォーム対応したもの
- OPC Classicは実行環境がWindows OS前提だったりと制約があった
- 産業向けの通信規格で、Request/Reponseモデルと、Pub/Subモデルがある
- QueryではなくRPCであり、操作対象をオブジェクトにデータモデリングします
- Unified Architectureとは
- オブジェクトデータモデル、SOA志向、通信モデル、セキュリティモデルなどが組み合わさっているためだと思われる
- インダストリー4.0のRAMI(Reference Architecture Model Industrie 4.0)モデルに採用されたことにより注目される
- Webの世界の言葉でかなり強引に例えると、レイヤーとしてはREST+HTTPとかgRPCに近い存在か
- IEC(国際電気標準会議: International Electrotechnical Commission) 62541 で規格化されている
OPC-UAの背景
- 産業機器でよく利用されるPLCは、開発元によって通信規格がバラバラである事が多く接続が大変
- MES(Manufacturing Execution System)やERPとの連携が標準化できなかったり制約を受け入れる必要があったりする
- (例) WindowsServer必須であったり、利用できるRDBやバージョンに制限があったり
- いわゆる、TCP/IPですらなく、EtherCAT、PROFINET、Modbus/TCPなどである場合も...
- MES(Manufacturing Execution System)やERPとの連携が標準化できなかったり制約を受け入れる必要があったりする
- 裏返しになるが業界グローバルデファクトスタンダードな規格が無かった
- OPC-UA、ORiN、EdgeCross(MelsecProtocol?)など標準化を目指す規格はいくつもあった
- OPC-UAはその中で、RAMIに取り上げられたので有力になった
OPC-UAそのものの設計ポリシー
アーキテクチャページ によると、以下5分類の設計ゴールがあるとのこと。
- 機能的な互換性(Functional equivalence)
- OPC-Classicの仕様が全てOPC-UAにマッピングされる
- さらにOPC-ServerのDiscovery、Pub/Sub、Event監視などの機能を盛り込む
- プラットフォーム非依存(Platform independence)
- 組み込みからクラウドベースのインフラへ
- HW的な依存なし、OS的な依存なし
- セキュア性(Secure)
- 暗号、認証、監査
- 拡張性(Extensible)
- 既存のアプリケーションに影響を与えずに新機能を追加する機能
- 包括的な情報モデリング
- 複雑な構造もモデリングできる
まぁ、分かるって感じですよね。
Protocol Stack
OPC-UAは主に3種類のプロトコルスタックを利用するケースがある模様です。
- SOAPベースのスタック
- HTTP(S)+セキュリティ層を重ねたスタック
- TCP/IP上にセッション層+セキュリティ層を重ねたスタック
入門としてはHTTP上に構築された1か2を使いたいところです。
実際のところはレードオフとしてレイテンシやスループットが犠牲になりそうなので要件次第といったところでしょうか。
OPC-UA通信モデル
以下のような複数のモデルが構築できるようです。
- Request/Response
- Publish/Subscribe(1:N)
- Publish/Subscribe(N:1)
出展: https://jp.opcfoundation.org/
OPC-UAデータモデル
OPC-UAで操作する対象はすべてオブジェクトとして表現します。
RESTだとURLのエンドポイントと、利用できるHTTPメソッド、Request/Responseのパラメータ定義のイメージでしょうか。
Eventだけはやや特殊で、おそらくPub/Subを利用して取得することが多いと思います。
- 属性
- メソッド(RPCで呼び出す対象)
- Event(値が変更したなどのトリガー)
OPC-UAのオブジェクトがオブジェクトを参照もでき、コンポジットなオブジェクトも定義できます。
この辺は、よくあるオブジェクト志向そのものなので違和感ないですね。
これを応用して、現実世界にあるものをモデリングしていくようです。
"操作"という切り口で都合よくモデリングしたり、"メンテナンス"という切り口でモデリングするといったことも想定されているようです。
出展: https://jp.opcfoundation.org/
OPC-UAの広まり
AWS Greengrassでは標準で通信できます
https://docs.aws.amazon.com/ja_jp/greengrass/latest/developerguide/opcua.html
類似規格
- 産業IoT向けのコンテキスト
- Modbus(OPC-UAと比べると低レイヤーの定義のみ)
- ORiN
- MCプロトコル(OPC-UAと比べると低レイヤーの定義のみ)
- Web界隈
- MQTT, JSON+HTTP, JSON+WebSocket
実装
.NET, C#, Javaなどの実装がある模様。
Javaに関しては過去Versionのみ存在し、最新の仕様に追随はしないとのこと。
NodeやGolangなどの実装も欲しいところなので、コントリビュートチャンスかも。
QuickStart??
簡単にお試しできるDockerイメージがないか探しました。
OPC-UAのPython実装を利用した、OPC-UAサーバは見つかりました。(動作確認はしていません)
環境構築がちょっと楽できるかもなくらいでしょうか
https://github.com/purplesrl/docker-alpine-opcua
また、 Azure IoT Edge で利用するためだと思われる、OPC-UAのServer/Clientそれぞれのコンテナイメージも見つけました。
Azure環境でしか動かないかもですが、Azureをすでに利用しているのであれば簡単にお試しできそうだなと。
https://github.com/Azure-Samples/iot-edge-opc-plc
https://github.com/Azure-Samples/iot-edge-opc-client
まとめ
- OPC-UAは産業向けIoTではデファクトスタンダードになりそう
- OPC-UAではアクセス対象がオブジェクトモデルで、Request/Response, Pub/Subなどでアクセス可能
- 仕様上はHW, OSから非依存、実装はまだまだこれからか
Reference
-
OPC Foundation Japan (日本OPC協議会)
- 会員登録すると、OPC-UAを用いたケーススタディゆや OPC-UA仕様などの資料を参照できます
-
OPC UA(IEC62541)のセキュリティ - ものづくりNEXT2011 (*PDF注意)
- ITエンジニア向けでかなり参考になる。PDFスライド
-
OPC-UAによる工程間データ連携の方法
- ITエンジニア向けで理解しやすくかなり参考になる。PDFスライド
-
OPC UAとは何か?なぜ「製造業とITの橋渡し役」として最適なのか - ビジネス+IT
- 概念レベルの説明としてわかりやすい
-
急速に普及する産業向け国際標準「OPC UA」
- 短くすぐ読めます