Companion Specを理解するために

Companion Information Modelの仕様を記載したドキュメントはCompaninon SpecもしくはCSと呼ばれます。Companion Information Modelの仕様を理解するためにはCSを精読する必要があります。ただし、OPC UAの最低限の基礎知識がないとCSは読めません。OPC UA 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はCompanion Specでどの番号を使うという指定があり、それぞれのCS内の”NamespaceとProfile”という章で記載されています。

情報モデル

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

１、２階層目はV1.03以上のOPC UA Serverであればデフォルトでロードしています。3層目は業界標準として使用するレイヤーでCompanion Information Modelと呼ばれドイツ機械工業会(VDMA)、ドイツ工作機工業会(VDW)、ドイツ自動車工業会(AIDA)など権威ある団体が作成し、事実上の国際標準になります。

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



Serverが情報モデルをロードするには読み込む情報モデルのXMLファイルをServerの設定ファイルに指定します。OPC UA Serverのコンフィグファイル（Empress iData OPC UA Serverの場合はuaserver.config.xml)の<AddtionalNodesetFile>に追加するXMLファイルへのパスとファイル名を追記し読み込む情報モデルファイルを定義します。Empress iData OPC UA ServerはMeta ModelとBuilt-in Information Modelはデフォルトでロードされる設定になっています。

モデリング

オブジェクトモデリング

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

Nodeモデリング

OPC UAでオブジェクトは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にNodeとして公開されません。

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というのはテンプレートです。ObjectTypeの定義を使用しインスタンス化したのが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」ObjectをObjects FolderのOrganizesとして定義されたサブフォルダーであるMachines Folderを作成し、Machine 1をMachines Folderに移すことを意味します。MachineTypeからインスタンス化された種類の異なるMachine<N>はMachines Folderに格納されます。

Machine 1がインスタンス化された際、｢構成要素であるMotorとTempuratureProbも同時にインスタンス化する｣と考える方が自然です。インスタンス化される時､MopdellingRuleを参照しインスタンス化するNodeをInstanceDeclarationといいます。Nodeを動的にインスタンス化させる際にすべてを単純に公開する場合はModellingRuleをMandatoryに定義し、公開させないNodeがある場合はOptionalを定義します。Machines FolderはすべてのClientにすべてのMachineを公開すると一般的に考えるのでModellingRuleはMandatoryにとします。

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

DataType

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

ProfileとNamespace

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

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