　最下層にあたるのがOPC UA BASEと呼ばれる部分である。ここは従来COM/DCOMで実装されていたメッセージ交換部分であるが、OPC UA BASEではこれをSOA（Service-Oriented Architecture）で実装している。SOAはさまざまなプラットフォームで利用されているから、これでマルチプラットフォーム性が担保できることになる。

　その上に「DA」「A＆E」「HDA」「CMDs」という4つのInformation Serviceと、それとは別にInformation Model Specification（Photo02では「標準インフォメーションモデル」とされている）という層が載っている。このうちDA/A＆E/HDAの3つはOPC Classicと同じもので、CMDsというのは2004年に追加されたOPC Commandsという仕様である。

　もともとOPC Classicの3つの機能は稼働中のシステムの状態やデータを取得するためのものだが、もっと根本的にシステムの起動/停止といった動作制御も行いたいという要望があり、このために追加されたのがOPC Comamnds（CMDs）である。OPC Classicではこれが追加仕様という扱いだったのが、OPC UAでは標準仕様として取り込まれた形だ。

　その上位にある「標準インフォメーションモデル」とは何か？というと、OPCのもっと上位にあるアプリケーションプロトコルである。Photo02ではIEC（IEC 62541）、ISA（ISA-95）、MIMOSAといった標準規格が挙げられているが、他にもFDI（Field Device Integration）、ADI（OPC Analyzer Device Integration）、FDT、ODVA、PLCopenなど、さまざまなものが想定されている。これらはOPC UA Companionと呼ばれているが、こうした標準規格の下位層として利用できるのがOPC UAの特徴でもある。

　もちろん、これらの中にはOPCが定めたものもある。例えばIEC 62541はOPC UAをIEC標準化したものそのままである。ただそれ以外の標準規格とも扱いは同じになっており、実際多くの規格が利用されている。またISA-95とPLCopenに関しては、OPC Foundation内にWorking Groupが設けられており、ここでそれぞれの規格をOPC UA上で利用するための仕様の策定活動などが行われている形だ。

　Photo02に話を戻すと、標準インフォメーションモデルの上位に、さらにベンダー固有インフォメーションモデルが用意されているが、これは名前の通りそれぞれの機器ベンダーが独自拡張する事を許しており、これをサポートする形だ。このベンダー固有インフォメーションモデルの上位にアプリケーションがあるが、このアプリケーションはどのサービスにもアクセスできる様になっている。

　そんなわけで、OPC UAは言ってみればOSIの参照モデルで言うところのトランスポート層～プレゼンテーション層に相当する機能を提供するだけで、その上位層や下位層に関しては特に規定がないという柔軟性を持つ。その一方で、製造・生産現場のシステムに要求される通信方式に関して幅広い機能を提供できる。ということでOPC-UAはIndustry 4.0における推奨通信規格として採用されるに至っている。次回はこのあたりの話をご紹介したい。