JP2016004359A

JP2016004359A - Ｏｐｃｕａサーバーの作成方法

Info

Publication number: JP2016004359A
Application number: JP2014123385A
Authority: JP
Inventors: 稔久藤井; Toshihisa Fujii
Original assignee: Azbil Corp
Current assignee: Azbil Corp
Priority date: 2014-06-16
Filing date: 2014-06-16
Publication date: 2016-01-12

Abstract

【課題】ＯＰＣＵＡサーバーの作成を容易にする。【解決手段】ＯＰＣＵＡサーバーＳＤＫの機能を用いて、クライアントとのインターフェイス部を利用し、そのもとで汎用ＯＰＣＵＡサーバー機能を実現する。対象とする各サブシステムにかかる従来のＯＰＣサーバー、あるいは新規な通信システムについて、それらのオブジェクトをデータモデルに定義することで、汎用ＯＰＣＵＡサーバーに包含させる方法である。これにより、新たなサブシステムを接続する際に、所定の定義だけでＯＰＣＵＡサーバーが実現できる。【選択図】図４

Description

この発明は、統合化されたＯＰＣサーバー（以下「ＯＰＣＵＡ（ＵｎｉｆｉｅｄＡｒｃｈｉｔｅｃｔｕｒｅ）サーバー」と呼ぶ）を効率的に開発するためのソフトウェア技術に関するものである。

従来、製品の製造や物流等に携わる企業では、複数のコンピュータ間を接続するネットワークシステムによって、プロセス制御や製品の出荷、生産管理、物流管理などを行うようになっている。このネットワークシステムは、大きく分けてプロセス制御システムや入出庫システム等の現場のシステムからデータを収集して蓄積するコンピュータであるサーバーと、サーバーからデータを取得して生産管理や物流管理等を行うコンピュータであるクライアントと、各コンピュータ間を接続するネットワークとから構成される。このようなネットワークシステムにおいて、異なるコンピュータ間でデータの送受信やデータの共有化を実現する技術として、ＯＰＣ（ＯＬＥｆｏｒＰｒｏｃｅｓｓＣｏｎｔｒｏｌ）が提案されている（例えば非特許文献１参照）。なお、ＯＰＣ（ＯｐｅｎｎｅｓｓＰｒｏｄｕｃｔｉｖｉｔｙ And Ｃｏｌｌａｂｏｒａｔｉｏｎ）の称呼もある。

ＯＰＣでは、当初のデータアクセス（ＤＡ）機能のみならず、順次にＯＰＣヒストリーデータアクセス（ＨＤＡ）、ＯＰＣアラーム＆イベント（Ａ&Ｅ）などのデータを発信する機能も開発されて、ＯＰＣ仕様のインターフェイスとして標準化されているのが現状である（非特許文献２参照）。

近年は、大規模プロセスオートメーション制御システムを情報管理するために、現場の計測器やコントローラから上位の運転監視（ＤＣＳ）、製造管理（ＭＥＳ）、経営決定（ＥＲＰ）への垂直方向の情報連携や、現場の機器同士が情報を交換する水平方向の情報連携を担う国際標準化された技術としてＯＰＣＵＡの普及が進んでいる。ＯＰＣＵＡは、従来のＯＰＣが対象としていた制御層でのデータ交換を包含する、さらに大きな適用範囲における統一した情報連携手段を提供してほしいという市場要求からきている（例えば、特許文献１参照）。

ＯＰＣＵＡはこれらの課題を解決する為に規定された情報連携基盤となるインターフェイス仕様である。ＯＰＣＵＡ仕様の特徴の１つであるデータモデルによって、関連のあるデータを整理した情報単位でやりとりすることで初めてデータの価値が個々の階層で認識できる。このためにＯＰＣＵＡではクライアントとサーバー間の交換単位をオブジェクト指向ベースである情報単位（データモデル）で定義する仕様である。

特開２００４−５０７７２１号公報

ＯＰＣＵＡサーバーの開発手段を紹介すると、既存のＯＰＣサーバーを包含して、そのデータをＯＰＣＵＡのデータモデルに変換してＯＰＣＵＡサーバーとして公開するプログラムが存在する。このようなプログラムをＯＰＣＵＡＷｒａｐｐｅｒとよび、幾つかのサードパーティベンダーが商品として提供している（図１Ａ参照）。しかし、既存のＯＰＣサーバーを前提にしていることで、既存のＯＰＣサーバーが存在することが前提であるので、ＯＰＣ以外の通信手段でアクセスするデータを取り込むことはできない問題がある。

一方、ＯＰＣＵＡが提供する機能を充分に活用し、自由な表現での情報モデルを公開するには純粋なＯＰＣＵＡサーバーを開発する方が良い。ＯＰＣＦｏｕｎｄａｔｉｏｎを始め、幾つかのサードパーティベンダーではＯＰＣＵＡアプリケーションの開発作業を支援するためのソフトウェア開発キット（ＳＤＫ : ＳｏｆｔｗａｒｅＤｅｖｅｌｏｐｍｅｎｔＫｉｔ）を提供している（非特許文献３のリスト参照）。どのＳＤＫにおいてもその構成は類似しており、ＯＰＣＵＡアプリケーションが提供しなければならない機能をフレームワークやライブラリの形式で実現し、独自のＯＰＣＵＡアプリケーションを開発する利用者はそのフレームワークの構造に則った特化部分の機能拡張を行い、その実装において適宜にライブラリを利用する (図１Ｂ参照)。しかし、ＳＤＫを用いても、どのような情報モデルを公開するかの設計は利用者が都度に設計を検討して実装をしなければならないので、開発の負担は大きい。

このようなＯＰＣＵＡサーバー開発における課題を解決し、ＯＰＣＵＡサーバーの作成にかかる開発を容易にすることを本願発明の課題とする。

本願発明は、ＯＰＣ基準仕様に準拠のインターフェイスを備えたＯＰＣＵＡサーバーの作成方法において、
データモデルを定義するステップと、
前記データモデル定義を解釈するクラスライブラリを具象化するステップと、
を特徴とするＯＰＣＵＡサーバーの作成方法である。

また、前記データモデル定義を解釈してオブジェクトのクラスからＵＡノードに変換する処理を行う汎用サーバー作成ステップを備えるＯＰＣＵＡサーバーの作成方法である。

前記データモデルはメタ言語で記述されることを特徴とするＯＰＣＵＡサーバーの作成方法である。

データモデルやその参照関係が宣言定義だけで構成でき、新たなプログラムの実装を必要としない。
データモデルが公開するオブジェクトのプロパティや変数とデータソースの紐付けが、データモデル宣言定義の中の変更だけで構成できる。
データモデルにデータ統合する仕組みを特定プロトコルに対応したソフトウェア部品としての実装を１度だけ行えば、あとはその部品を宣言定義の中で組み替えるだけで、１つのデータモデルが様々なデータソースに連携できる。
などの効果が得られる。

従来技術であるＯＰＣＵＡサーバーの作成方法：図１ＡＷｒａｐｐｅｒ方式図１ＢＳＤＫ方式本願発明の実施形態にかかるＯＰＣＵＡサーバーの階層的構成図本願発明の実施例であるデータモデル定義本願発明の実施例であるＯＰＣＵＡサーバーの作成方法のフロー図

[設計思想]
はじめに、本願発明にかかる設計の思想的特徴を述べる。
第一に、データモデルやその参照関係が宣言定義だけで構成でき、新たなプログラムの実装を必要としない。
第二に、データモデルが公開するオブジェクトのプロパティや変数とデータソースの紐付けが、データモデル宣言定義の中の変更だけで構成できる。データモデルにデータ統合する仕組みを特定プロトコルに対応したソフトウェア部品としての実装を１度だけ行えば、あとはその部品を宣言定義の中で組み替えるだけで、１つのデータモデルが様々なデータソースに連携できる。

[主要要素]
次に、本願発明にかかる主要な要素を説明する。
（１）データモデル
プログラムとは独立したファイルの中に公開すべきデータモデルを定義するようにした。
ＯＰＣＵＡ仕様では既にデータモデルの内容を外部にエキスポートするためのXMLスキーマが規定されている。本願発明でもその標準仕様を利用し、更なる機能拡張としてつぎの内容が定義できる概念を追加する。

具体的には、オブジェクトが持つ変数やプロパティに相当する定義部分に、そこへのアクセスが発生したときにどのデータソース内のどのデータにアクセスすべきかを指定する。
そして、オブジェクトの定義部分に、そこからのイベントの発生元を指定することでもある。このような仕様にしたことで、外部から取得したＯＰＣＵＡ情報モデルの対象を定義したメタ言語（ＸＭＬ）ファイルについて拡張部分を追加定義するだけで今回の試作品の環境に統合できる。

（２）クラスライブラリ
データモデル定義を解釈するクラスライブラリであって、これが具象化されるオブジェクトはロードした個々の情報モデルに相当し、そこに定義されているデータモデルとしてのオブジェクト、プロパティ、メソッドなどを公開する。このクラスライブラリから具象化されるオブジェクトの利用者はどのようなプロパティやメソッドがあるかを確認でき、プロパティへのアクセスの実行を要求できる。

プロパティへのアクセスを処理するために、このクラスライブラリはデータモデル定義で宣言したアクセス対象データソースを処理するデータソース通信ソフトウェア部品を利用する。より詳細にはデータモデル定義にはこのソフトウェア部品の所在と、それを使ってアクセスする対象のデータソース内アイテムの２種類が定義されている。データソースとして、従来のＯＰＣサーバーやＯＰＣＵＡサーバーに対応した通信ソフトウェア部品を用いることでよいが、ＯＰＣ以外のデータソースにもアクセスするためのプロトコルを実装した通信ソフトウェア部品を用意することでもよい。

以上述べた本願発明にかかるＯＰＣＵＡサーバーの構成図を図２に示す。
クライアントとのインターフェイス部分は、一般的なＳＤＫで提供されるフレームワークおよびライブラリが位置づけられる。その下に、データモデル定義を解釈するオブジェクト・クラスからＵＡノードに変換する処理を行う汎用ＯＰＣＵＡサーバー（ＵＡ依存アプリケーション）が存在する。
また、データモデル定義を解釈するクラスのオブジェクト群であり、これがデータモデル定義を解釈するクラスライブラリ（ＵＡ非依存アプリケーション）である。

これら、ＵＡ依存、非依存のアプリケーションはただ一度開発される必要はあるが、
前述のクラスライブラリが提供するメタ情報取得の仕組みやオブジェクトインスタンスの情報を利用して、汎用ＯＰＣＵＡサーバーとして必要な情報モデル（メタ情報のタイプノード、インスタンスとしてのオブジェクトノードなど）に変換して公開する。

公開されたＯＰＣＵＡサーバーへの各種要求はそのまま前述のクラスライブラリのオブジェクトに渡されて、その結果を返す。すなわち、ただ一つの汎用ＯＰＣＵＡサーバーと、ただ一つのクラスライブラリを実装することで、実際の情報モデルの構築はデータモデル宣言定義だけでＯＰＣＵＡサーバー機能を実現する。

１．データモデル
ＯＰＣＵＡのモデルを構成しているものは全てノードというデータ構造からできている。対象とする従来のＯＰＣサーバーなどのオブジェクトが持っている変数やメソッドも、オブジェクトを表すノードと変数やメソッドを表すノードが存在し、そのノード間にリファレンスを定義することで構成される。リファレンス自体はノードとは独立した概念であるが、そのメタ情報を定義しているものはリファレンスタイプというノードであり、ＯＰＣＵＡのデータモデルはノードとリファレンスから成り立つ。
ＯＰＣＵＡのノードの種類を次の表１に示し、そこで説明を付す。

次に、図３にノードの構造を示す。
各ノード属性とその説明を、次の表２および以下の項で述べる。

２．ＯＰＣＵＡサーバー作成方法のフロー
図４のフロー図を基に、ステップ順に説明する。各ステップは図中Ｓｎで示す。
まず、ステップＳ１でオブジェクト参照関係の解読に入る。これは、ＵＡで公開するアドレススペース（オブジェクト群を参照関係でつないだ空間）のコンフ情報を読み込み、どのようなクラスやインスタンスが必要かを確認する作業である。

例えば、下記の定義例では、Object というメタ（ＸＭＬ）要素では、インスタンスのノードを定義し、その中のReferenceという要素が参照関係を表す。
<Object NodeId="ノード名" BrowseName="xxx " WriteMask="0" UserWriteMask="0" EventNotifier="0">
<DisplayName>Sample<DisplayName>
<Description>Sample Folder<Description>
<References>
<Reference ReferenceType="HasTypeDefinition" IsForward="true">
Sample
</Reference>
<Reference ReferenceType="Organizes" IsForward="false">
Objects
</Reference>
</References>
</Object>

次に、ステップＳ２でクラスのメタ情報の解読を行う。これは、必要なクラス情報がどのようなデータメンバーやメソッドを持っているかを、そのクラスのメタ情報から取得する。入力ファイルもクラスのメタ情報である。
例えば、上記のインスタンスのノード定義の中には次のような HasTypeDefinition という参照定義があれば、インスタンスのノード名を指す。
<Reference ReferenceType="HasTypeDefinition" IsForward="true">
BoMaintenanceAspect_CompressedAirSource
</Reference>
ステップＳ１での定義内容と、実際のクラスのメタ情報から必要な情報を取得するというのが本ステップである。

次に、ステップＳ３でタイプノードの作成を行う。これは、ステップＳ２の情報からＵＡノードで表現するオブジェクトや変数のタイプノードを作成する。
例えば、ステップＳ１のXMLの全ての Object 要素に対してそのクラスを確認し、全てのクラスのObjectTypeノードを作成する。そのクラスが持つメソッドやプロパティの情報を確認し、適宜にVariableType, DataType, Variable,Methodノードも作成する。

次に、ステップＳ４でインスタンスノードの作成を行う。これは、ステップＳ３のタイプノードからインスタンスノードに具象化することで、ステップＳ１でテンプレート出力されているデータ定義の内容を具体化することである。
例えば、ステップＳ１での全ての Object 要素に対してそのObjectノードを作成する。そのインスタンスが持つメソッドやプロパティも、
ステップＳ３で作成したObjectTypeノードが持っているVariable, Methodノードもその複製を作成する。

このように、インスタンスノードを作成するときには、それに１対１で対応する
‘データモデル定義を解釈するクラスのオブジェクト’を作成し紐付けておく。
例えばVariableノードに対応するオブジェクトには、そのノードが持つValue属性へのデータアクセスを行うために必要なデータソース通信部品の参照と、そのデータソース通信部品を使ってValue属性に対応するデータソース内の対象データアイテムにアクセスするために必要なパス情報などを保持しておく。

最後に、ステップＳ５でＵＡノードの公開を行い、終了する。このＵＡノードがクライアントに公開されてデータアクセスなどができる。

以上述べたように、通常のＵＡサーバーが提供する機能はＳＤＫの中に作りこまれているのでその機能を利用して実現する。Value属性へのアクセスがＵＡクライアントから要求された場合には、ＵＡアプリ依存部分はそのサービス要求をＵＡ非依存アプリ部分に引き渡す。引き渡された側では対応するデータソース通信部品とそこに要求するパス情報を
‘データモデル定義を解釈するクラスのオブジェクト’から取り出してアクセスを行う。その結果はＵＡアプリ依存部分に渡され、ＳＤＫを通してＯＰＣＵＡのアクセス結果としてＵＡクライアントに渡される。

以上、本願発明ではデータアクセス（ＤＡ）を主に説明をしたが、イベント通知、メソッド実行などのＯＰＣ拡張的なサポートも同様に行えることは当然である。そのような種々の変形応用を行っても本願発明の範囲に属する。

Claims

ＯＰＣ基準仕様に準拠のインターフェイスを備えたＯＰＣＵＡサーバーの作成方法において、
データモデルを定義するステップと、
前記データモデル定義を解釈するクラスライブラリを具象化するステップと、
を特徴とするＯＰＣＵＡサーバーの作成方法。
請求項1に記載のＯＰＣＵＡサーバーの作成方法において、
前記データモデル定義を解釈してオブジェクトのクラスからＵＡノードに変換する処理を行う汎用サーバー作成ステップを備えるＯＰＣＵＡサーバーの作成方法。
請求項1また請求項２に記載のＯＰＣＵＡサーバーの作成方法において、
前記データモデルはメタ言語で記述されることを特徴とするＯＰＣＵＡサーバーの作成方法。