Companion Specを理解するために

Companion Information Modelの仕様を記載したドキュメントは、Companinon SpecもしくはCSと呼ばれます。Companion Information Modelの仕様を理解するためにはCSを精読する必要があります。ただし、OPC UAの最低限の基礎知識がないとCSは読めません。OPC Foundationのマニュアルをすべて精読するのも大変です。そこで最低限のOPC UAの基礎知識を効率的に説明します。ここで基礎を学ぶことで相当のショートカットが得られると思います。

OPC UAのSeverとClient

OPC UAではデータが蓄えられる側をSever、データを操作する側をClientと言います。１つのOPC UA ServerはServer名もしくはIPアドレスで表現され、これをEndpointといいます。１つのEndpointは１つのAddressSpaceを待ちます。

AddressSpaceは、OPC UA Severのメモリー上の大きなデータ構造体でカレントデータしか保存されません。過去データはヒストリカルデータと呼ばれ、AddressSpaceではなくServer内のデータベースに保存されます。但し、データベースはデフォルトでは準備されていません。ODBCが使用できるデータベースをユーザが選択し設定しなければなりません。

AddressSpaceは、巨大になりますのでNamespace（名前空間）で区別されます。NamespaceはCSでどの番号を使うという指定があり、それぞれのCS内の”NamespaceとProfile”という項で記載されています。

情報モデル

情報モデルは、FA機器同士が情報のやりとりをするデータの枠組です。XMLフォーマットのファイルとして提供されます。OPC UAで情報モデルは基本的に４階層のレイヤーで構築されています。

１、２階層目はOPC UA Bassicと言われる基礎的な部分です。
3層目は業界標準として使用するレイヤーでCompanion Information Modelと呼ばれ、事実上の国際標準になります。

４番目の階層はVendor Specific Extensionsと呼ばれます。Companion Information Modelとは反対で各企業が独自に情報を記載する階層になります。４階層目にあるのでMeta Model、Built-in Information Model、Companion Information Modelから情報をリンクしなければならないため、専用のツール（Modeler）を使用することが推奨されています。



Serverが情報モデルをロードするためには、情報モデルのXMLファイルをServerの設定ファイルに指定します。OPC UA Serverのコンフィグファイル（Empress iData OPC UA Serverの場合はuaserver.config.xml)の<AddtionalNodesetFile>に、追加するXMLファイルへのパスとファイル名を追記します。

モデリング

オブジェクトモデリング

OPC UAのオブジェクトモデルは、ServerがClientにオブジェクトを表す標準的な方法を提供しています。それはOPC UA Clientの視点から見ると、「VariableをRead、Writeする」、「MethodをCallする」、「Node間の関連付けを読み取る」の3つ機能を意味します（下の図を参照して下さい）。この３つの視点から定義されたオブジェクトは、AddressSpaceではNodeとして公開され、公開される各々のNodeは8つのNodeClassに割り当てられます。

Nodeモデリング

OPC UAでオブジェクトは、Objectとその構成要素をAddressSpace内のNodeとして公開します。AddressSpaceにはNodeしか存在しません。そして、各々のNodeは8つのNodeClassに分類されます。NodeClassはServerベンダーが独自に拡張はできません。これはOPC UAの規定です。

NodeはAttributeとReferenceの２つの要素により構成されます。AttributeはNodeの内容を定義し、Referenceは、NodeとNodeの間の関係を定義します。ReferenceはNode間の関連を定義するのと同時に、ReferenceType NodeClassのインスタンスとしてAddressSpaceでNodeとして公開されます。これに対しAttributeはNodeの記述要素のためにAddressSpaceに公開されません。

Base NodeClass

Nodeは８つのNodeClassに分類されますが、８つのNodeClassの親としてBase NodeClassが存在します。Base NodeClassのAttributeは、すべてのNodeに共通する構成要素になり、すべてのNodeに継承されます。

NodeClassはOPC UAの仕様によって定義されています。Sever（個別のシステム）は、新しいNodeClassを追加したり作成したりできません。各々のNodeのパラメータやデータは、規定により指定されたAttributeによって記述されます。そして、そのAttributeもOPC UAの仕様によって定義されます。Attributeは使用方法によりMandatory（必須）とOptional（オプショナル）に分類されます。

Base NodeClassのAttributes

下記のAttributeはBase NodeClassを定義します。Base NodeClassのAttributeは全てのNodeに引き継がれます。

8つのNodeClass

8つのNodeClassの概略は下記の通りです。

Companion Specを読む事前準備

OPC UAの仕様を一度で理解することは難しいと思います。これに対してCSはOPC UAの基礎が出来てしまえばそれほど難しいことではありません。通常、CSは２つの方法によって仕様を記述してます。OverviewとDefinitionです。Overviewは、CSの全体を鳥瞰的に理解するために適しています。Definitionは、ひとつのObjectTypeをより詳細に理解するのに適しています。

Overviewの読み方

OPC UAは、Companion SpecをOverviewするために下記の表記方法を使用しています。4つのインスタンス、4つのタイプと8つの代表的なRefernceから構成されます。良く使用されるRefernce以外は、矢印内にReferenceの名称が直接記述されます。ここで使用されるReferenceTypeは、重要かつ基本的なものですので、かならず表記法と意味を覚える必要があります。

Addtional Definitionとして長方形の形と枠線を併用し以下が定義されています。

ObjectType Definitionの読み方

CSを読む前に「ObjectTypeとは何か？」からはじめたいと思います。

ObjectTypeとは何なのか

OPC UA Foudatrionのドキュメントを読むと「Objectを定義するのがObjectTypeです。」と書かれています。わかりずらい表現です。具体的にいうとObjectTypeというのはObjectの定義書です。この定義書を使用しインスタンス化したのがObjectです。

単純なMachineを例にとって説明します。Machineがどう構成されているかを定義したものがObjectTypeです。MachineはMotorとTempuratureProbeで構成されています。Machineを構成しているMotorとTempuratureProbeを定義しているのがMotorTypeとTempuratureProbeTypeです。OPC UAはObjerctをインスタンス化する際、命名規則として「Machine 1」という様な表現方法が推奨されています。

次にOPC UAでObjectTypeからObjectへインスタンス化するということは具体的にどういう作業なのか説明します。OPC UAでインスタンス化するにはObjectTypeで定義されたインスタンスであるMachine 1をObjects FolderにOrganizesすることを意味します。

Machine 1がインスタンス化された際、TargetNodeであるMotorとTempuratureProbも同時にインスタンス化すると考える方が自然です。インスタンス化される時､MopdellingRuleを参照しインスタンス化するNodeをInstanceDeclarationといいます。Nodeを動的にインスタンス化し公開する場合は、ModellingRuleをMandatoryに定義し、公開させない場合はOptionalを定義します。

ObjectTypeのDefinitionの読み方

ObjectTypeのDefinitionの読み方を下記のサンプルを用いて説明します。

1 BrowseName

人間が読める名前として使用されるNodeの名称です。

2 IsAbstruct

ObjectTypeはBase NodeClassのAttributeにIsAbstract Attributeが追加されます。IsAbstractがFalseの場合は具体的なObjectTypeです。このObjectTypeからObjectが直接インスタンス化ができることを示します。Trueの場合、抽象的なObjectTypeです。このObjectTypeからObjectはインスタンス化せず、サブタイプのObjectTypeからObjectがインスタンス化することを表します。

3 Reference

Node間の関係を定義します。Refernceが定義されているこのObjectTypeをSourceNodeと言い、子供として関連付けられる（Refernceされる）NodeをTargetNodeと言います。

4 NodeClass

AddressSpace内のNodeは８つあるNodeClass（Variable、Object、Method、View、VariableType、ObjectType、ReferenceType、DataType）のどれかに分類されます。分類名が記載されています。これはOPC UAの規定です。

5 DataType

VariableとVariableType NodeのValue Attributeのデータ型（DataType）を表します。

6 TypeDifinition

ObjectまたはVariableをそれぞれObjectTypeまたはVariableTypeにバインドします。

7 ModellingRule

ModellingRuleは最上位ObjectTypeであるTypeDefinitionNodeがインスタンス化する際、Referenceで関連付けられたTargetNodeがどのように生成されるかを定義します。CSでインスタンス化が義務付けられたものをMandatoryに設定し、Severが独自に判断するものをOptionalとします。

8 何のSubTypeか

上位のNodeの継承の概念を表します。だれが親かが記述されています。

9 HasSubtype

HasSubtypeは比較的上位の階層にあるObjectTypeがObjectを構成要素にする場合に良く定義されます。ObjectTypeはTypeDefinitionで構造体を定義するので説明が必要です。このために"7.1項を参照してください。"という指示があります。

10 HasComponet

HasComponentはSourceNode（このObjectType）にObject、DataVariables、Methodを関連付けるために使用されます。HasComponentのVariableはDataVariableです。変化する値に用いられます。

11 HasProperty

SourceNode（このObjectType）にHasPropertyを用いてVariableを関連付けます。HasPropertyはHasComponentのVariableと異なり、動的に変化する値を記載するのではなく、上限値や下限値などのデフォルト値や初期値が記載されます。

CSの構成

CSはドキュメントはまず全体の概要を説明するためにObjectTypeか説明され、CS全体がどのようなオブジェクトで構成されているのかを説明します。次にCS内で横断的に使用されるReference、Event、DataTypeなどが説明されます。最後にServerとClientはCSのどの部分に対応できているかを示すProfileやFacetの説明があります。CSはこのような構成で作成されています。

ObjectType

CSの具体的な解説は必ずObjectTypeから始まります。ObjectTypeはCSがどういうオブジェクトで構成されているかを定義しています。ObjectTypeはObjectを定義しインスタンス化します。一般的にObjectが生まれるのと同時に子供のNodeも動的にインスタンス化します。ObjectはMethodやVariableという子供を持ちます。Methodは「この機械のコマンド」になり、Variableは「この機械の回転数」になります。子供のObjectを持つこともあり、「この機械の部品」になります。このようにObjectTypeを理解することはCS全体の概略が理解できることになります。

Event

これに対しEventはObjectの子供になりません。Eventはシステムと深く関連した機能です。たとえばServerの証明書が失効した場合、機械のモータが急にストップした場合にEventは発生されます。このようにEventは特定のObjectの子供にならずにシステムで横断的に使用されます。このためCSに独自のEventがある場合、別に項を設けてその中で説明されてます。

Reference

Referenceはちょっと特殊な形式で説明されます。まず、SourceNodeとなるObjerctTypeの中でReferenceの説明があります。横断的に使用するReferenceがあった場合は別に項を設けてその中で説明されています。ReferenceはCSによって記載方法が異なります。

DataType

基本的なデータ型はBuit-in DataTypeといわれOPC UAで定義されています。CSに特有のDataTypeが存在した場合は別に項を設けてその中で説明されています。例えばRoboticsのPositionType、VectorTypeなどがこれらにあたります。

ProfileとNamespace

NamespaceはすでにOPC UAで規定されている部分があります。たとえばOPC Foundationで規定されているOPC UA Basicのインデックスは0と決められています。また、ローカルサーバのインデックスは1と決められています。その他、個々のCSでどの番号のNamespaceを使用するか記載されている場合があります。

ProfileはOPC UA SeverとClientはCSのどの部分に対応できているかを規定しているのがProfileで、FacetはProfileをより細かく分化し定義したものです。OPC UA ServerやClientをCSに対応させる場合、ProfileやFacetは非常に重要ですので精読し理解することをおすすめします。