(57)【要約】【課題】ＯＰＣ  ＵＡサーバーの作成を容易にする。【解決手段】  ＯＰＣ  ＵＡサーバーＳＤＫの機能を用いて、クライアントとのインターフェイス部を利用し、そのもとで汎用ＯＰＣ  ＵＡサーバー機能を実現する。対象とする各サブシステムにかかる従来のＯＰＣサーバー、あるいは新規な通信システムについて、それらのオブジェクトをデータモデルに定義することで、汎用ＯＰＣ  ＵＡサーバーに包含させる方法である。これにより、新たなサブシステムを接続する際に、所定の定義だけでＯＰＣ  ＵＡサーバーが実現できる。【選択図】  図４
2016004359.tif 000002
【特許請求の範囲】
【請求項１】
ＯＰＣ基準仕様に準拠のインターフェイスを備えたＯＰＣ  ＵＡサーバーの作成方法において、
データモデルを定義するステップと、
前記データモデル定義を解釈するクラスライブラリを具象化するステップと、
を特徴とするＯＰＣ ＵＡサーバーの作成方法。
【請求項２】
請求項1に記載のＯＰＣ ＵＡサーバーの作成方法において、
前記データモデル定義を解釈してオブジェクトのクラスからＵＡノードに変換する処理を行う汎用サーバー作成ステップを備えるＯＰＣ ＵＡサーバーの作成方法。
【請求項３】
請求項1また請求項２に記載のＯＰＣ ＵＡサーバーの作成方法において、
前記データモデルはメタ言語で記述されることを特徴とするＯＰＣ ＵＡサーバーの作成方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、統合化されたＯＰＣサーバー（以下「ＯＰＣ  ＵＡ（Ｕｎｉｆｉｅｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）サーバー」と呼ぶ）を効率的に開発するためのソフトウェア技術に関するものである。
【背景技術】
【０００２】
従来、製品の製造や物流等に携わる企業では、複数のコンピュータ間を接続するネットワークシステムによって、プロセス制御や製品の出荷、生産管理、物流管理などを行うようになっている。このネットワークシステムは、大きく分けてプロセス制御システムや入出庫システム等の現場のシステムからデータを収集して蓄積するコンピュータであるサーバーと、サーバーからデータを取得して生産管理や物流管理等を行うコンピュータであるクライアントと、各コンピュータ間を接続するネットワークとから構成される。このようなネットワークシステムにおいて、異なるコンピュータ間でデータの送受信やデータの共有化を実現する技術として、ＯＰＣ （ ＯＬＥ ｆｏｒ Ｐｒｏｃｅｓｓ Ｃｏｎｔｒｏｌ ） が提案されている（ 例えば非特許文献１ 参照） 。なお、ＯＰＣ（  Ｏｐｅｎｎｅｓｓ Ｐｒｏｄｕｃｔｉｖｉｔｙ And Ｃｏｌｌａｂｏｒａｔｉｏｎ  ）の称呼もある。
【０００３】
ＯＰＣでは、当初のデータアクセス（ＤＡ）機能のみならず、順次にＯＰＣヒストリーデータアクセス（ＨＤＡ）、ＯＰＣアラーム＆イベント（Ａ&Ｅ）などのデータを発信する機能も開発されて、ＯＰＣ仕様のインターフェイスとして標準化されているのが現状である（非特許文献２  参照）。
【０００４】
近年は、大規模プロセスオートメーション制御システムを情報管理するために、現場の計測器やコントローラから上位の運転監視（ＤＣＳ）、製造管理（ＭＥＳ）、経営決定（ＥＲＰ）への垂直方向の情報連携や、現場の機器同士が情報を交換する水平方向の情報連携を担う国際標準化された技術としてＯＰＣ ＵＡの普及が進んでいる。ＯＰＣ ＵＡは、従来のＯＰＣが対象としていた制御層でのデータ交換を包含する、さらに大きな適用範囲における統一した情報連携手段を提供してほしいという市場要求からきている（例えば、特許文献１  参照）。
【０００５】
ＯＰＣ ＵＡはこれらの課題を解決する為に規定された情報連携基盤となるインターフェイス仕様である。ＯＰＣ ＵＡ仕様の特徴の１つであるデータモデルによって、関連のあるデータを整理した情報単位でやりとりすることで初めてデータの価値が個々の階層で認識できる。このためにＯＰＣ ＵＡではクライアントとサーバー間の交換単位をオブジェクト指向ベースである情報単位（データモデル）で定義する仕様である。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００４−５０７７２１号公報
【非特許文献】
【０００７】
【非特許文献１】「ＯＰＣ 技術概要書 Ｖｅｒｓｉｏｎ２．０」， 日本ＯＰＣ協議会，１９９９年１１月
【非特許文献２】製造業ＸＭＬフォーラム  ＯＰＣ最新情報２００６、日本ＯＰＣ協議会、２００６年
【非特許文献３】http://www.OPCconnect.com/ＵＡkit.php#overview    Copyright &copy; OPCconnect.com. Last modified 2013-Jun-24.
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ＯＰＣ  ＵＡサーバーの開発手段を紹介すると、既存のＯＰＣサーバーを包含して、そのデータをＯＰＣ ＵＡのデータモデルに変換してＯＰＣ ＵＡサーバーとして公開するプログラムが存在する。このようなプログラムをＯＰＣ ＵＡ Ｗｒａｐｐｅｒとよび、幾つかのサードパーティベンダーが商品として提供している（図１Ａ  参照）。しかし、既存のＯＰＣサーバーを前提にしていることで、既存のＯＰＣサーバーが存在することが前提であるので、ＯＰＣ以外の通信手段でアクセスするデータを取り込むことはできない問題がある。
【０００９】
一方、ＯＰＣ ＵＡが提供する機能を充分に活用し、自由な表現での情報モデルを公開するには純粋なＯＰＣ ＵＡサーバーを開発する方が良い。ＯＰＣ Ｆｏｕｎｄａｔｉｏｎを始め、幾つかのサードパーティベンダーではＯＰＣ ＵＡアプリケーションの開発作業を支援するためのソフトウェア開発キット（ＳＤＫ : Ｓｏｆｔｗａｒｅ Ｄｅｖｅｌｏｐｍｅｎｔ Ｋｉｔ）を提供している（非特許文献３のリスト参照）。どのＳＤＫにおいてもその構成は類似しており、ＯＰＣ ＵＡアプリケーションが提供しなければならない機能をフレームワークやライブラリの形式で実現し、独自のＯＰＣ ＵＡアプリケーションを開発する利用者はそのフレームワークの構造に則った特化部分の機能拡張を行い、その実装において適宜にライブラリを利用する (図１Ｂ  参照)。しかし、ＳＤＫを用いても、どのような情報モデルを公開するかの設計は利用者が都度に設計を検討して実装をしなければならないので、開発の負担は大きい。
【００１０】
このようなＯＰＣ ＵＡサーバー開発における課題を解決し、ＯＰＣ ＵＡサーバーの作成にかかる開発を容易にすることを本願発明の課題とする。
【課題を解決するための手段】
【００１１】
本願発明は、ＯＰＣ基準仕様に準拠のインターフェイスを備えたＯＰＣ  ＵＡサーバーの作成方法において、
データモデルを定義するステップと、
前記データモデル定義を解釈するクラスライブラリを具象化するステップと、
を特徴とするＯＰＣ ＵＡサーバーの作成方法である。
【００１２】
また、前記データモデル定義を解釈してオブジェクトのクラスからＵＡノードに変換する処理を行う汎用サーバー作成ステップを備えるＯＰＣ ＵＡサーバーの作成方法である。
【００１３】
前記データモデルはメタ言語で記述されることを特徴とするＯＰＣ ＵＡサーバーの作成方法である。
【発明の効果】
【００１４】
データモデルやその参照関係が宣言定義だけで構成でき、新たなプログラムの実装を必要としない。
データモデルが公開するオブジェクトのプロパティや変数とデータソースの紐付けが、データモデル宣言定義の中の変更だけで構成できる。
データモデルにデータ統合する仕組みを特定プロトコルに対応したソフトウェア部品としての実装を１度だけ行えば、あとはその部品を宣言定義の中で組み替えるだけで、１つのデータモデルが様々なデータソースに連携できる。
などの効果が得られる。
【図面の簡単な説明】
【００１５】
【図１】従来技術であるＯＰＣ  ＵＡサーバーの作成方法：              図１Ａ  Ｗｒａｐｐｅｒ方式        図１Ｂ  ＳＤＫ方式
【図２】本願発明の実施形態にかかるＯＰＣ  ＵＡサーバーの階層的構成図
【図３】本願発明の実施例であるデータモデル定義
【図４】本願発明の実施例であるＯＰＣ  ＵＡサーバーの作成方法のフロー図
【発明を実施するための形態】
【００１６】
[設計思想]
はじめに、本願発明にかかる設計の思想的特徴を述べる。
第一に、データモデルやその参照関係が宣言定義だけで構成でき、新たなプログラムの実装を必要としない。
第二に、データモデルが公開するオブジェクトのプロパティや変数とデータソースの紐付けが、データモデル宣言定義の中の変更だけで構成できる。データモデルにデータ統合する仕組みを特定プロトコルに対応したソフトウェア部品としての実装を１度だけ行えば、あとはその部品を宣言定義の中で組み替えるだけで、１つのデータモデルが様々なデータソースに連携できる。
【００１７】
[主要要素]
次に、本願発明にかかる主要な要素を説明する。
（１）データモデル
プログラムとは独立したファイルの中に公開すべきデータモデルを定義するようにした。
ＯＰＣ ＵＡ仕様では既にデータモデルの内容を外部にエキスポートするためのXMLスキーマが規定されている。本願発明でもその標準仕様を利用し、更なる機能拡張としてつぎの内容が定義できる概念を追加する。
【００１８】
具体的には、オブジェクトが持つ変数やプロパティに相当する定義部分に、そこへのアクセスが発生したときにどのデータソース内のどのデータにアクセスすべきかを指定する。
そして、オブジェクトの定義部分に、そこからのイベントの発生元を指定することでもある。このような仕様にしたことで、外部から取得したＯＰＣ ＵＡ情報モデルの対象を定義したメタ言語（ＸＭＬ）ファイルについて拡張部分を追加定義するだけで今回の試作品の環境に統合できる。
【００１９】
（２）クラスライブラリ
データモデル定義を解釈するクラスライブラリであって、これが具象化されるオブジェクトはロードした個々の情報モデルに相当し、そこに定義されているデータモデルとしてのオブジェクト、プロパティ、メソッドなどを公開する。このクラスライブラリから具象化されるオブジェクトの利用者はどのようなプロパティやメソッドがあるかを確認でき、プロパティへのアクセスの実行を要求できる。
【００２０】
プロパティへのアクセスを処理するために、このクラスライブラリはデータモデル定義で宣言したアクセス対象データソースを処理するデータソース通信ソフトウェア部品を利用する。より詳細にはデータモデル定義にはこのソフトウェア部品の所在と、それを使ってアクセスする対象のデータソース内アイテムの２種類が定義されている。データソースとして、従来のＯＰＣサーバーやＯＰＣ ＵＡサーバーに対応した通信ソフトウェア部品を用いることでよいが、ＯＰＣ以外のデータソースにもアクセスするためのプロトコルを実装した通信ソフトウェア部品を用意することでもよい。
【００２１】
以上述べた本願発明にかかるＯＰＣ  ＵＡサーバーの構成図を図２に示す。
クライアントとのインターフェイス部分は、一般的なＳＤＫで提供されるフレームワークおよびライブラリが位置づけられる。その下に、データモデル定義を解釈するオブジェクト・クラスからＵＡノードに変換する処理を行う汎用ＯＰＣ  ＵＡサーバー（ＵＡ依存アプリケーション）が存在する。
また、データモデル定義を解釈するクラスのオブジェクト群であり、これがデータモデル定義を解釈するクラスライブラリ（ＵＡ非依存アプリケーション）である。
【００２２】
これら、ＵＡ依存、非依存のアプリケーションはただ一度開発される必要はあるが、
前述のクラスライブラリが提供するメタ情報取得の仕組みやオブジェクトインスタンスの情報を利用して、汎用ＯＰＣ ＵＡサーバーとして必要な情報モデル（メタ情報のタイプノード、インスタンスとしてのオブジェクトノードなど）に変換して公開する。
【００２３】
公開されたＯＰＣ ＵＡサーバーへの各種要求はそのまま前述のクラスライブラリのオブジェクトに渡されて、その結果を返す。すなわち、ただ一つの汎用ＯＰＣ ＵＡサーバーと、ただ一つのクラスライブラリを実装することで、実際の情報モデルの構築はデータモデル宣言定義だけでＯＰＣ ＵＡサーバー機能を実現する。
【実施例】
【００２４】
１．データモデル
ＯＰＣ ＵＡのモデルを構成しているものは全てノードというデータ構造からできている。対象とする従来のＯＰＣサーバーなどのオブジェクトが持っている変数やメソッドも、オブジェクトを表すノードと変数やメソッドを表すノードが存在し、そのノード間にリファレンスを定義することで構成される。リファレンス自体はノードとは独立した概念であるが、そのメタ情報を定義しているものはリファレンスタイプというノードであり、ＯＰＣ ＵＡのデータモデルはノードとリファレンスから成り立つ。
ＯＰＣ  ＵＡのノードの種類を次の表１に示し、そこで説明を付す。
【００２５】
【表１】
2016004359.tif 000003
【００２６】
次に、図３にノードの構造を示す。
各ノード属性とその説明を、次の表２および以下の項で述べる。
【００２７】
【表２】
2016004359.tif 000004
【００２８】
２．ＯＰＣ  ＵＡサーバー作成方法のフロー
図４のフロー図を基に、ステップ順に説明する。各ステップは図中Ｓｎで示す。
まず、ステップＳ１でオブジェクト参照関係の解読に入る。これは、ＵＡで公開するアドレススペース（オブジェクト群を参照関係でつないだ空間）のコンフ情報を読み込み、どのようなクラスやインスタンスが必要かを確認する作業である。
【００２９】
例えば、下記の定義例では、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属性へのアクセスがＵＡクライアントから要求された場合には、ＵＡアプリ依存部分はそのサービス要求をＵＡ非依存アプリ部分に引き渡す。引き渡された側では対応するデータソース通信部品とそこに要求するパス情報を
‘データモデル定義を解釈するクラスのオブジェクト’から取り出してアクセスを行う。その結果はＵＡアプリ依存部分に渡され、ＳＤＫを通してＯＰＣ ＵＡのアクセス結果としてＵＡクライアントに渡される。
【産業上の利用可能性】
【００３６】
以上、本願発明ではデータアクセス（ＤＡ）を主に説明をしたが、イベント通知、メソッド実行などのＯＰＣ拡張的なサポートも同様に行えることは当然である。そのような種々の変形応用を行っても本願発明の範囲に属する。
【図１】
2016004359.tif 000005
【図２】
2016004359.tif 000006
【図３】
2016004359.tif 000007
【図４】
2016004359.tif 000008