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と言います。1つのOPC UA ServerはServer名もしくはIPアドレスで表現され、これをEndpointといいます。1つのEndpointは1つのAddressSpaceを待ちます。
AddressSpaceはOPC UA Severのメモリー上の大きなデータ構造体でカレントデータしか保存されません。過去データはヒストリカルデータと呼ばれ、AddressSpaceではなくServer内のデータベースに保存されます。但し、データベースはデフォルトでは準備されていません。ODBCが使用できるデータベースをユーザが選択し設定しなければなりません。
AddressSpaceは巨大になりますのでNamespace(名前空間)で区別されます。NamespaceはCompanion Specでどの番号を使うという指定があり、それぞれのCS内の”NamespaceとProfile”という章で記載されています。
情報モデル
情報モデルはFA機器同士が情報のやりとりをするデータの枠組です。XMLフォーマットのファイルとして提供されます。OPC UAで情報モデルのは基本的に4階層のレイヤーで構築されています。複雑な情報モデルでは4つ以上になる場合もあります。
1、2階層目はV1.03以上のOPC UA Serverであればデフォルトでロードしています。3層目は業界標準として使用するレイヤーでCompanion Information Modelと呼ばれドイツ機械工業会(VDMA)、ドイツ工作機工業会(VDW)、ドイツ自動車工業会(AIDA)など権威ある団体が作成し、事実上の国際標準になります。
4番目の階層はVendor Specific Extensionsと呼ばれます。Companion Information Modelとは反対で各企業が独自に情報を記載する階層になります。4階層目にあるので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つ機能を意味します(下の図を参照して下さい)。この3つの視点から定義されたオブジェクトはAddressSpaceではNodeとして公開され、公開される各々のNodeは8つのNodeClassに割り当てられます。
Nodeモデリング
OPC UAでオブジェクトはAddressSpace内のNodeとして公開されます。AddressSpaceにはNodeしか存在しません。各々のNodeは8つのNodeClassに必ず割り当てられます。NodeClassはServerベンダーが独自に拡張はできません。これはOPC UAの規定です。
NodeはAttributeとReferenceの2つの要素により構成されます。AttributeはNodeの内容を定義し、ReferenceはNodeとNodeの間の関係を定義します。ReferenceはNode間の関連を定義するのと同時にReferenceType NodeClassのインスタンスとしてAddressSpaceでNodeとして公開されるます。これに対しAttributeはNodeの記述要素のためにAddressSpaceにNodeとして公開されません。
Base NodeClass
Nodeは8つのNodeClassに分類されますが、8つの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に引き継がれます。
Attribute名 | データタイプ | 説明 | M/O |
---|---|---|---|
NodeID | NodeID | AddressSpaceでNodeを一意に識別するためのIdです。NodeはNamespaceとIdentifierの組み合わせで一意化されます。例えば「NodeId="ns=1;i=3018"」の様にXMLに記載されます。Identifierの2000番まではOPC UA Foundationにより予約されています。 | M |
NodeClass | NodeClass | Nodeは8つのNodeClassどれかに分類します。 | M |
BrowseName | QualifiedName | 人間が読める名前として使用されるAttributeです。TranslateBrowsePathsToNodeIds Serviceを使用しBrowseNameで構成されたパスからNodeIdまでたどることができます。 | M |
DisplayName | LocalizedText | ローカライズ可能なAttributeで人間が判読できる文字としてClientsに公開されます。例えばBrowseNameは英語、DisplayNameはドイツ語の場合が多く見受けられます。 | M |
Description | LocalizedText | Nodeの意味を説明します。 | O |
WriteMask | UInt32 | WriteMaskはClientが書き込む可能性を公開します。 | O |
UserWriteMask | UInt32 | UserWriteMaskはClientがユーザーアクセス権を参照し書き込む可能性を公開します。 | O |
RolePermissions | UInt32 | Nodeにアクセスするロールの権限を指定します。ArrtuibuteのValueはRolePermissionTypeの構造体の配列です。指定しない場合はNamespaceMetadata ObjectのDefaultRolePermissions Propertyの値が使用されます。 | O |
UserRolePermissions | UInt32 | UserWriteMaskはClientがユーザーアクセス権を参照し書き込む可能性を公開します。 | O |
AccessRestrictions | UInt32 | UserWriteMaskはClientがユーザーアクセス権を参照し書き込む可能性を公開します。 | O |
8つのNodeClass
8つのNodeClassの概略は下記の通りです。
NodeClass名 | 説明 |
---|---|
Object NodeClass | システム、システムコンポーネント、実世界のオブジェクト(例えば自動車など)、およびソフトウェアオブジェクトを表すために使用されます。 |
Variable NodeClass | 値を表すために使用されます。 |
Method NodeClass | Method(FA機器の場合はコマンド)を表すために使用されます。 |
View NodeClass | AddressSpaceでNodeとReferenceの数を制限するために使用されます。 |
ReferenceType NodeClass | Node間の関係を示すために使用されます。 |
ObjectType NodeClass | ObjectのTypeを表すために使用されます。ObjectTypeはObjectからHasTypeDefinitionによりインスタンス化されます。 |
VariableType NodeClass | VariableType NodeClassはValueのデフォルト値もしくは初期値を記述するために使用します。VariableTypeはVariableからHasTypeDefinitionによりインスタンス化されます。 |
DataType NodeClass | VariableやVariableTypeのNodeはDataType Attributeを持ちます。DataType Attributeの値はValue Attributeのデータ型を表します。DataType NodeはHasEncodingをReferenceを介してエンコーディング情報も提供します。 |
Companion Specを読む事前準備
OPC UAは仕様を一度で理解することは難しいと思います。これに対してCSはOPC UAの基礎が出来てしまえばそれほど難しいことではありません。通常、CSは2つの方法によって仕様を記述してます。OverviewとDefinitionです。OverviewはCSの全体を鳥瞰的に理解するために適しています。DefinitionはひとつのObjectTypeをより詳細に理解するのに適しています。
Overviewの読み方
OPC UAはCompanion SpecをOverviewするために下記の表記方法を使用しています。4つのインスタンス、4つのタイプと8つの代表的なRefernceから構成されます。良く使用されるRefernce以外は矢印内にReferenceの名称が直接記述されます。ここで使用されるReferenceTypeは重要かつ基本的なものですので、かならず表記法と意味を覚える必要があります。
Addtional Definitionとして長方形の形と枠線を併用し以下が定義されています。
Nodeの要素 | グラフ表示 | 定義 |
---|---|---|
Mandatory Object | 長方形の枠線 | タイプ定義を持つ必須のObject |
Optionalal Object | 長太字の破線枠の方形 | タイプ定義を持つオプションのObject |
Mandatory Placeholder Object | 太字枠の長方形 | タイプ定義を持つ必須のプレースホルダーObject |
Optionalal Placeholder Object | 点線枠の長方形 | タイプ定義を持つオプションのプレースホルダーObject |
ObjectType | 点線枠の影付きの長方形 | タイプ定義を持つObjectType |
VariableType | 角丸枠の影付き長方形 | タイプ定義を持つVariableType |
Mandatory Variable | 角が丸い枠の長方形 | タイプ定義を持つ必須のVariable |
Optionalal Variable | 角が丸い点線枠の長方形 | タイプ定義を持つオプションのVariable |
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は8つある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は非常に重要ですので精読し理解することをお奨めします。