JP2022143520A - 情報処理装置、情報処理方法、情報処理システム及びコンピュータプログラム - Google Patents

Abstract

【課題】対象となる要素の属性情報を容易に取得することを可能にする情報処理装置、情報処理方法、情報処理システム及びコンピュータプログラムを提供する。
【解決手段】本実施形態に係る情報処理装置は、複数の要素と前記要素間の第１関係とを含む第１情報における第１要素に対して、第２要素との間に第２関係を設定することを示す関係設定情報を選択する選択部と、前記関係設定情報に基づき、前記第１要素に対して少なくとも１つの前記第２要素との間に前記第２関係を設定する設定部と、設定された前記第２関係と前記第１情報とに基づいて、前記第１要素の属性情報を決定する決定部と、を備える。
【選択図】図３

Description

本実施形態は、情報処理装置、情報処理方法、情報処理システム及びコンピュータプログラムに関する。

IoT（Internet of Things）システムにおいては、設備に設置されたセンサで得られたデータを、設備の構成や設備を制御する方式に従った形式で収集し、収集したデータを用いた計算に基づき、制御装置（アクチュエータ）から設備を制御する方法がある。この方法において、収集したデータを利用するために、当該データが収集されたセンサの属性情報を確認する必要がある。属性情報として例えばセンサの種類、センサの設置箇所、センサが測定する対象などの情報がある。センサの属性情報を取得するため、人間がセンサに属性情報を設定し、センサデータとともに属性情報を取得する方法があるが、設定漏れが生じる場合があった。

そこで、設備の構成や設備を制御する方式を表す情報モデルを生成し、情報モデルとセンサとの関係表を作成する方式があった。しかしながら、情報モデルとセンサとの対応づけは、新規設備が導入されたり設備が変更されたりする都度、やり直さなければならず、効率が悪かった。

国際公開第2016/098805号 米国特許出願公開第2016-350364号明細書

本発明の実施形態は、対象となる要素の属性情報を容易に取得することを可能にする情報処理装置、情報処理方法、情報処理システム及びコンピュータプログラムを提供する。

本実施形態に係る情報処理装置は、複数の要素と前記要素間の第１関係とを含む第１情報における第１要素に対して、第２要素との間に第２関係を設定することを示す関係設定情報を選択する選択部と、前記関係設定情報に基づき、前記第１要素に対して少なくとも１つの前記第２要素との間に前記第２関係を設定する設定部と、設定された前記第２関係と前記第１情報とに基づいて、前記第１要素の属性情報を決定する決定部とを備える。

第１実施形態に係る情報処理システムを示す図。 本実施形態における対象システムとしてビル空調システムの具体例を概略的に示す図。 マッピング装置のブロック図。 情報モデルをソフトウエア工学のクラス図に従って模式的に表す図。 図４の情報モデルをAlloyの形式で記述した例を示す図。 タグ定義情報をAlloyの形式で記述した例を示す図。 タグ情報の制約をAlloyの形式で定義した例を示す図。 情報モデルにおける制約をAlloyで定義した例を示す図。 ユーザがインスタンスの定義の入力を行う例を示した図。 インスタンス情報（マッピング情報）の例を示す図。 図１０と同一内容を含むインスタンス表の例を示す図。 asssert定義の例を示す図 反例の例を示す図。 反例を表形式で表した図。 制約違反検出部のブロック図。 不足していたahuRefタグに関する情報を一行で示した図。 センサデータベースの一例を示す図。 本実施形態に係る情報処理システムのハードウェア構成図である。 本実施形態に係るマッピング装置の動作の一例のフローチャート。 本実施形態に係る対象システムとしてボイラ制御システムの具体例を概略的に示す図。 本実施形態におけるボイラ制御システムのモデルを表す図。 図２１の情報モデルをAlloyの形式で記述した例を示す図。 タグ情報の定義及び制約の例を示す図。 タグ情報の制約の例を示す図。 タグ情報を設定する様子を示す図。 インスタンス情報（マッピング情報）の例を示す図。 asssert定義の例を示す図。 反例の例を示す図。 対象システムに関する具体的なデータ構造の一例を示す図。 センサのデータの構造（ソースデータ構造）の一例を示す図。 変換ルール生成部が変換ルールを生成する事例を説明する図。 センサデータベースの例を示す図。 対象システムに関するデータ構造に合わせた形式のデータを生成する様子を示す図。

本発明の実施形態は、物理的な設備に設置された１つ以上のセンサ等からデータを収集し、収取したデータに基づき、当該物理的な設備に対する１つ以上のアクチュエータ（操作装置）を操作することで、制御対象を制御するシステムに用いられる。制御対象は、例えば当該設備が設置された空間の温度である。本実施形態で対象とするシステム（対象システム）は、例えばIoT（Internet of Things）システムとして構成される。

以下、図面を参照しながら本実施形態について説明する。

＜第１実施形態＞
図１は、第１実施形態に係る情報処理システムの構成を示す。図１の情報処理システムは、対象システム１００と、情報処理装置２００とを備える。対象システム１００は、設備システム１と、制御システム２とを備える。情報処理装置２００は、設備管理装置３と、情報モデル管理装置４と、マッピング装置５と、入力装置６と、表示装置７とを含む。本実施形態では対象システム１００が空調システムである場合の例を示す。

設備システム１は、物理的な設備と、当該設備に配置されたセンサ及びアクチュエータ（操作装置）とを有する。物理的な設備は、機器、建物、フロア、部屋、ダクトなど様々ある。

制御システム２は、対象システム１００のセンサで検出されたデータを収集し、収集したデータに基づき制御プログラム等で計算を行い、計算結果に基づき得られる制御情報を用いて、アクチュエータ（操作装置）を操作することで、設備システム１を制御する。例えば制御システム２は、制御装置としてのAHU（Air Handling Unit）を含む。アクチュエータは、一例として、送風機（VAV: Variable Air Volume system）である。

設備管理装置３は、設備システム１に含まれる、設備、センサ及びアクチュエータに関する情報を記憶する。例えば、設備管理装置３は、設備、センサ、アクチュエータのそれぞれの識別子（例えばシリアル番号又は名称等）を記憶する。設備管理装置３は、制御システム２に含まれる制御装置又は制御系に関する情報をさらに記憶していてもよい。

情報モデル管理装置４は、設備、センサ、アクチュエータ、及び制御プログラムそれぞれの関連性を定義した情報を管理する。例えばどの設備に設けられたセンサのデータを、制御プログラムのどの変数に割り当て、制御プログラムの計算により、どのアクチュエータに対する制御情報を生成するか（どのアクチュエータの操作用の変数を計算するか）等を定義した情報を記憶している。このような関連性を定義した情報を取得できるようにするため、本実施形態は、例えばセンサから受信したデータから、当該センサの属性情報を容易に決定できるようにする。属性情報として、例えばセンサの種類、センサが計測している物理量、センサが設けられたフロア・部屋、センサのデータに基づき操作する対象となるアクチュエータなどがある。センサの属性情報を決定することで、センサを具体的に特定でき、またセンサに関連するアクチュエータがどれかなども具体的に特定できる。これにより、当該センサのデータを制御プログラムのどの変数に割り当てればよいか、制御プログラムに基づく計算結果によりどのアクチュエータを制御すればよいか（どのアクチュエータの操作用の変数を計算するか）など容易に判断可能になる。センサとアクチュエータとがマッピングされた制御プログラムは制御システム２に送信され、制御システム２で実行されることができる。

入力装置６は、操作者であるユーザがデータ又は指示を入力するインタフェースである。入力装置６は、例えばキーボード、マウス、タッチパネル、音声入力装置、ジェスチャ入力装置等である。

表示装置７は、データ又は情報を画面に表示するディスプレイである。表示装置７は、例えば液晶表示パネル、有機EL表示パネル等である。入力装置６及び表示装置７は、マッピング装置５と有線又は無線により接続されている。

図２は、本実施形態における対象システム１００としてビル空調システムの具体例を概略的に示す。対象システム１００におけるビルは複数のフロアを備える。フロアは、複数の部屋を備える。各部屋には温度センサ６１が設置されている。図では１つの部屋にのみ温度センサ６１が設置されているが、他の部屋にも温度センサ又は他の種類のセンサが設置されていてよい。空調を制御する制御システム２には空気調和機（AHU：Air Handling Unit）６２が設けられている。部屋に設置された温度センサ６１の検出データは、AHU６２に送信される。AHU６２は、部屋の温度に合わせて供給する空気の温度を調節するため、空気を温めたり、冷やしたり、外気と混合するなどの空気調整を行う。AHU６２は、アクチュエータである送風機（VAV: Variable Air Volume system）６３を用いて、部屋に調整された空気を供給する。以下では、図２の具体例をベースに説明を行う。

図３は、マッピング装置５のブロック図である。マッピング装置５は、タグ情報設定部１１（選択部）と、マッピング部１２（設定部）と、制約違反検出部１３（検出部）と、決定部１４と、処理実行部１８、受信部１９と、センサ一覧表２１、情報モデル２２（第１情報）、タグ定義情報２３、センサデータベース２５を備える。情報モデル２２及びタグ定義情報２３は、図１の情報モデル管理装置４に格納されていてもよい。

図４は、本実施形態におけるビル空調システムに対応する情報モデル２２をソフトウエア工学のクラス図に従って模式的に表している。情報モデル２２は、例えば、後述するようにAlloyと呼ばれる言語又はソフトウエアで記述されることができる。Alloyは、オブジェクト指向におけるクラス定義に加えて、クラス（要素）間の制約を論理式で定義することができ、情報モデルの記述に適している。図４における各小さい矩形はクラス（情報モデルの要素又は対象システム１００の要素）に対応する。図４において、Tag、及び左下の角が曲線の矩形内のroomRef, ahuRef, tagSensor, tagTemp, tagHmdが本実施形態に係る関係設定情報に対応するタグ情報（ラベル）のクラスを表す。タグ情報は、タグ定義情報２３によって定義されている。黒の実線はクラスの継承を表している。破線はクラス間の関係を示している。タグ情報から出ている破線の関係（observes, controledBy等）はタグ情報によって定義（追加）される第２関係に相当する。それ以外の破線の関係（feeds, points, points, hasPart等）は、基本的に対象システム（設備システム及び制御システム）における要素間の第１関係に相当する。また、タグ情報によって第２関係を追加（設定）するために定義したクラス（ThePoint,deviceModel）に結合された破線の関係（hasTag, hadDeviceModel，isAssocTo）も第１関係に相当する。以下のクラス図の説明において、各要素の名称に「クラス」を付けずに各要素を参照する場合もある。例えばAHUクラスのことを、単にAHUと称する場合もある。

AHUは空調(HVAC:Heating Ventilation and Air Conditioning)クラスのサブクラスでる。AHUは、VAVに給気(feed)する。VAVはセンサ(sensor)を観測ポイント(points)として利用する。

ビル設備(TheEntity)は、フロア(Floor)、部屋(Room)、センサ(sensor)を有する。FloorはRoomをその一部として持ち(hasPart)、Roomにはsensorが観測ポイント(points)として配置されている,

機器モデル(deviceModel)は、タグ情報と呼ばれるラベルを設定する対象となる機器を表すクラスである。タグ情報は当該機器に第２関係を設定する条件を含む関係設定情報の一例に対応する。機器モデルの例としては、AHUの制御下にある温度センサ(rmTempSensorCtrAhu)がある。rmTempSensorCtrAhuは、機器モデルのサブクラスである。機器モデルは設備（TheEntity）と関連付け(isAssocTo)されている。また物理的な物(PhysicalBody)として温度(Temperature)と、湿度(Humidity)がある。温度と湿度は、物理的な物クラス（又は物理量のクラス）(PhisycalBody)のサブクラスである。

接点(ThePoint)は、機器モデル（deviceModel）と関連(hasDeviceModel)づけられ、かつ、Tagを複数持つ(hasTag)ことができる。接点(ThePoint)は、機器モデルが表す機器（図の例では温度センサ）との接点を意味し、当該機器を代替的に示すクラスであるとも言える。機器モデルはセンサ以外にも、アクチュエータなど、他の機器を表してもよい。つまり機器モデルを承継してアクチュエータのクラスを定義してもよい。本実施形態ではセンサは第２関係を設定する対象となる第１要素に対応し、第１要素以外の要素は第２要素に対応する。本実施形態に係る情報モデルは、複数の第１要素と第１要素間の関係とを含む第１情報に対応する。

図の左下に示すように、Tagクラスは、roomRef,tagSensor,ahuRef,tagTemp,tagHmdを有する。Tagクラスを承継して、roomRef,tagSensor,ahuRef,tagTemp,tagHmdのサブクラスのタグ情報を生成している。

tagTempは温度（temprature）を観測(observe)することを表すタグ情報に対応する。tagHmdは湿度（humidity）を観測することを表すタグ情報に対応する。roomRefは、上記接点が部屋(Room)に配置される(isLocated)ことを表すタグ情報に相当する。ahuRefは、上記接点（つまり温度センサ）が、AHUにより制御される(controlledBy)ことを表している。tagSensorは、上記接点が温度センサ（第１要素）を特定の機器として対象とすることを表している。

後述するようにタグ情報は、タグ定義情報２３において所定の言語で定義されている。本実施形態ではAlloyと呼ばれる言語又はソフトウエアを用いる場合を想定する。タグ定義情報２３は、タグ情報自体の定義の他、情報モデルにおける要素とタグ情報との間の制約も定義される。また情報モデルには情報モデル自体の定義以外に、情報モデルにおける制約も定義される。以下、タグ情報又は情報モデルに関する制約の例（制約１～制約４）を示す。制約２は情報モデルに関する制約、制約１、３，４はタグ情報に関する制約である。

＜制約１＞tagTempを含む機器モデルが、sensorに関連し、そのセンサが温度(temperature)を観測(observe)するならば、tagTempは温度に関連(relate)している。
＜制約２＞全ての部屋(Room)には、センサ(sensor)がある。
＜制約３＞全てのTagは、いずれかの機器モデルの一部(part of)でないといけない。
＜制約４＞全てのTagは、いずれかの接点に属する(hasTag)。

制約１は、第２関係を情報モデルに設定する条件を含む。つまり制約1を有するタグ情報は、情報モデルの第１要素（例えば温度センサ）に第２要素（例えば温度）との間で第２関係を設定する条件を含む関係設定情報の一例である。例えば、tagTempは、sensorに対して温度と第２関係（relate）を設定する条件（“tagTempを含む機器モデルが、sensorに関連し、そのセンサが温度(temperature)を観測(observe)するならば”）を含む関係設定情報である。
上述の制約１～４は一例に過ぎず、他にも様々な制約が可能である。

図５は、図４の情報モデルをAlloyの形式で記述したものである。abstract sigは抽象クラスの定義を表す。sigはクラスの定義、extendsはクラスの継承を表す。“：”の左の名前（feeds,points等）は、“：”の右側のクラスとの関係を表す。“lone”は高々１つを表し、“set”は複数持ってもよいことを意味する。例えばThePointは複数のTagを持ってもよい（“hasTag: set Tag”）。なお、図５において、図４におけるrmTempSensorCtrAhuのクラスの定義は省略している。

図６は、タグ定義情報をAlloyの形式で記述した例を示す。抽象クラスとしてTagが定義され、TagはdeviceModelの一部（partOf）である。Tagを継承して、４つのタグ（tagTemp,tagSensor,roomRef,ahuRef）を定義している。例えば、tagTempは、tagTempの所属先のdeviceModelが高々１つのPhysicalBodyとのみ関連することを表す。roomRefは、当該deviceModelが高々１つのRoomのみに配置されることを表す。ahuRefは、当該deviceModelが高々１つのAHUのみによって制御されることを表す。

図７は、タグ情報の制約をAlloyの形式で定義した例を示す。この制約もタグ定義情報２３に含まれる。factは制約を意味する。なお、factの直後のLoPはList of Propertyの略である。

図７の上側の制約は、AHUの制御下にある機器モデルが表す温度センサ(rmTempSensorCtrAhu)は、４つのタグ（tagTemp,tagSensor,roomRef,ahuRef）を部品として持つという制約である。なお、“：”は、制約を定義するうえで、変数を定義する∈である。”:”の左の側の記号(例えばn)で、右側のタグ又はクラスに含まれる要素であるnを表現し、nに関する制約式を記述することでnの属するタグまたはクラスの制約をあらわしている。例えば、”n: rmTempSensorCtrAhu “は、クラスrmTempSensorCtrAhuに含まれるある要素を“n”によって表現している。

図７の中段では３つの制約が示される。これら３つの制約はタグ情報が示す関係を条件が満たされた場合に追加（設定）することに相当する。つまり各制約は、該当するTag（tagTemp, romRef, ahuRef）が、情報モデルにおける第１要素（例えば温度センサ）に第２関係（relates, isLocated, controledBy）を設定する条件である。３つの制約の詳細はそれぞれ以下の通りである。

1つ目の制約は、tagTempが付与されたdeviceModelがsensorに関連し、sensorが温度(temperature)を観測（observes）するならば、tagTempは温度に関連(relate)していることを示す。なお、制約式において、tagTempは“t”で定義されている。“ tagTempが付与されたdeviceModelがsensorに関連し、sensorが温度(temperature)を観測（observes）するならば”が、relate（第２関係）を設定するための条件に相当する。

第２関係を設定するための条件は第１関係に基づいている（以下同様）。この例では、条件は、第１要素であるsensorと第２要素であるdeviceModelとの間に第１関係（関連：isAssocTo）が存在することと、第１要素であるsensorと第２要素である温度(temperature)との間に、第１関係（観測：observes）が存在することである。図４及び図５では、sensorとdeviceModelとの間に（TheEntityを介して）isAssocToが存在し、sensorとtemperatureとの間に（PhysicalBodyを介して）observesが存在するため、条件が満たされる。上記の第１関係の一例であるisAssocToやObservesは第１関係の種別に対応する。

２つ目の制約は、roomRefが付与されたdeviceModelがsensorに関連し、roomがセンサ(sensor)をもつ（points）ならば、roomRefは部屋に配置される(isLocated)ことを示す。“roomRefが付与されたdeviceModelがsensorに関連し、roomがセンサ(sensor)をもつ（points）ならば”が、isLocated（第２関係）を設定するための条件に相当する。この条件も図４及び図５から満たされていることが分かる。

すなわち、この例では、条件は、第１要素であるsensorと第２要素であるdeviceModelとの間に第１関係（関連：isAssocTo）が存在することと、第１要素であるsensorと第２要素である部屋(room)との間に、第１関係（points）が存在することである。図４及び図５では、sensorとdeviceModelとの間に（TheEntityを介して）isAssocToが存在し、sensorとroomとの間に（PhysicalBodyを介して）pointsが存在するため、条件が満たされる。上記の第１関係の一例であるisAssocToやpointsは、第１関係の種別に対応する。

３つめの制約は、ahuRefが付与されたdeviceModelがsensorに関連し、AHUがVAVに給気し、VAVがsensorに関連するならば、ahuRefはAHUによって制御される（controledBy）ことを示す。“ahuRefが付与されたdeviceModelがsensorに関連し、AHUがVAVに給気し、VAVがsensorに関連するならば”が、controledBy（第２関係）を設定するための条件に相当する。この条件も図４及び図５から満たされていることが分かる。

すなわち、この例では、条件は、第１要素であるsensorと第２要素であるdeviceModelとの間に第１関係（関連：isAssocTo）が存在することと、第２要素であるAHUと同じく第２要素であるVAVとの間にfeedsが存在することと、第１要素であるsensorと第２要素であるVAVとの間に、第１関係（points）が存在することである。図４及び図５では、sensorとdeviceModelとの間に（TheEntityを介して）isAssocToが存在し、AHUとVAVとの間にfeedsが存在し、sensorとVAVとの間にpointsが存在するため、条件が満たされる。上記の第１関係の一例であるisAssocTo、points及びfeedsは、第１関係の種別に対応する。

図７の下側の制約は、全てのTagは、いずれかのdeviceModelの一部(part of)であることを示す。

図８は、情報モデルにおける制約をAlloyで定義した例を示す。図８の制約は、全て(all)の部屋(Room)には センサー(sensor)が一つ(one)あることを示す。

以上、情報モデル２２とタグ定義情報２３について説明した。

センサ一覧表２１は、１つ又は複数のセンサのリストである。例えばセンサの識別子（識別情報）のリストである。

タグ情報設定部１１は、センサ一覧表２１に含まれる個々のセンサに対して１つ又は複数のタグ情報を付与する。より具体的には、前述したように、当該センサに対して他の要素との関係（第２関係）を設定するためのクラス（センサとの接点と呼ぶクラス）が定義されている。接点クラスのインスタンスに対してタグ情報を設定する。インスタンスの名前（接点の名前）は、例えばセンサの識別子を用いる。センサと一対一に対応すれば、接点の名称は、定義した識別子でもよい。タグ情報設定部１１は、このように接点にタグ情報を設定する記述を、入力装置６からのユーザの入力に基づき生成する。この記述は所定の言語に従って、（例えば前述したAlloy）により行う。

以下、接点(FI101)に、tagTemp,tagSensor,roomRef,ahuRefという４つのタグ情報を設定する例を示す。なお接点は複数定義してもよい。この場合、下記で使用されていないタグ情報（例えばtagHmd）を他の接点に対して設定してよい。

タグ情報設定部１１は、ユーザの入力に基づきインスタンス生成の定義を行う。上述の接点に対するタグ情報の定義は、当該インスタンス生成の定義に含めて行われる。

図９は、ユーザがインスタンスの定義の入力を行う例を示している。タグ情報設定部１１がユーザの入力に基づき、インスタンスの定義を生成する。一番下では、前述した例と同様に、センサとの接点Fl101のインスタンス（ThePointクラスを継承したクラスのインスタンス）に対してtagTemp,tagSensor,roomRef,ahuRefの４つのタグを設定（付与）する定義を行う様子を示している。この操作は、ユーザが、接点Fl101に対応するセンサに４つのタグ情報を付与していることに相当する。なお、ユーザが接点Fl101に対して、例えばある１つのタグ情報を付け忘れたときは、後述するように、この画面でタグ情報を追加する修正を行うことができる。またこの画面では、他のインスタンスとして、Floorを継承してFL1のインスタンスを定義している。また、Roomを継承してRM101のインスタンスを定義している。また、sensorを継承してtmsensor101のインスタンスを定義している。また、deviceModelを継承してrmTempSensorCtrAhuのインスタンスを定義している。また上述のように、ThePointを継承してfl101のインスタンスを定義している。

マッピング部１２は、タグ情報設定部１１により生成されたインスタンス生成の定義情報、情報モデル２２、タグ定義情報２３に基づき、インスタンス情報（インスタンス図又はインスタンス表）を生成する。インスタンス情報の生成は、前述した制約（タグ情報の制約、及び情報モデルの制約）を満たすように、行う。生成されたインスタンス情報は、対象システムの情報モデルにタグ情報によって定義された第２関係を情報モデルに追加する処理を行うことに相当する。

前述したように、タグ情報はdeviceModelが示す機器（本例では温度センサ）に対して第２関係を、図７の中段に示した条件（fact temp Tag{}参照）の成立に応じて、追加する。第２関係は、元々の情報モデルには定義されていなかった、温度センサと他の要素（対象システムのセンサ以外のインスタンス）との関係に相当する。このように温度センサを情報モデルにおける他の要素（対象システムのセンサ以外のインスタンス）に第２関係によって、制約に違反しないように、関係づけることをマッピングと呼ぶ。本例では、図７の中段に示した３つのタグ情報に関する条件がいずれも成立するが、成立しない条件のタグ情報については、第２関係が追加されない。

インスタンス生成は、インスタンス生成の定義情報、タグ定義情報（タグ情報の制約を含む）及び情報モデル（情報モデルの制約を含む）に基づき行う。インスタンス生成は、ソフトウエア工学における制約充足問題に帰着し、制約を満たす事例（＝インスタンス）の探索問題に帰着できる。ソフトウエア工学における制約充足にかかわるソフトウエアを用いれば、マッピングを実現することができる。

本実施形態では前述のAlloy（ソフトウエア）を用いてインスタンス生成を行う。Alloyは、制約充足ソルバを用いて、クラス定義と制約とを充足するインスタンスを生成する。またAlloyは、assert構文を用いて、確かめたい性質又は制約の成否を判定し、成立しないときは反例（性質又は制約が成立しない例）を例示できる。図９のインスタンス生成の定義に基づきインスタンスを生成するとともに、生成したインスタンスと関係するクラスのインスタンスを生成し、インスタンス間の関係を把握して、インスタンス情報を生成する。

図１０は、Alloyツールの実行(excecute)機能を用いて生成されたインスタンス情報（インスタンス図）を示す。インスタンス情報をマッピング情報とも呼ぶ。インスタンスにはクラスと区別するため”$0”などの文字が追加されている。

空調システムのAHU$0は、VAV$0に給気(feeds)し、VAV$0は、温度センサtmpsensor101$0を利用する(points)。

ビルのフロアFL$0には、部屋RM101$0があり、RM101$0には温度センサが設置されている(points)。

接点fl101$0は、autoRef$0、roomRef$0、tagSensor$0、tagTemp$0という４つのタグを有する(hasTag)。４つのタグはそれぞれ、機器モデル(rmTempSensorCtrAhu$0)を構成している(part of)。すなわち、当該４つのタグはそれぞれ、機器モデル(rmTempSensorCtrAhu$0)の一部である。

tagTemp$0タグは、rmTempSensorCtrAhu$0に関連する（isAssocTo）温度センサ（tmpsensor101$0）が、温度（temperature$0）を観測(observe)していることを示している。この観測(observe)は、温度センサにtemperature$0との間に設定された第２関係の一例である。

roomRef$0タグは、当該温度センサが、部屋（RM101$0）に設置(isLocated)されていることを示している。この設置(isLocated)は、温度センサにRM101$0との間に設定された第２関係の一例に相当する。

ahuRef$0タグは、温度センサが、AHU$0により制御されている(controledBy)ことを示している。controledByは、温度センサにAHU$0との間に設定された第２関係の一例に相当する。

tagSensor$0タグは、fl101$0が温度センサ（tmpsensor101$0）に関連（isAssocTo）することを示している。

図のfeeds, points等は、元々の情報モデルで定義されていた第１関係に相当する。

インスタンス情報は、図１０のインスタンス図の他、表形式で表すこともできる。表形式で表したインスタンス情報は、インスタンス表と呼ばれる。

図１１は、図１０と同一内容を含むインスタンス表の例を示す。＜主語、関係、対象＞の3組にて関係性を一行に表している。また主語、対象とも、インスタンス名とクラス名が記載されている。

例えば、fl101$0は、ThePointクラスのインスタンスであることがわかる。また、fl101$0は、TagクラスのインスタンスであるahuRef$0と、hasTag関係を有することがわかる。

このように、センサ（詳細にはセンサとの接点Fl101）に対してタグ情報を付与して、情報モデル（図４のクラス図を参照）にセンサに関する第２関係を矛盾なく設定（追加）できる。

図１０又は図１１のインスタンス情報は、センサで検出されたデータを保存するデータベースのスキーマそのものであり、インスタンス情報から、当該データを検出したセンサに関連する属性情報を容易に特定できる。例えばセンサから取得されたデータが、どのビルのどのフロアのどの部屋に設けられたどの種類のセンサ（例えば温度センサ）から取得されたかが分かる。また、取得されたデータがAHUによって空調制御に利用され、空調制御された空気がVAVによって上記の供給されることが分かる。またVAによって供給された空気の温度を上記センサが検出していることが分かる。したがって、データに関連する情報（センサの属性情報）を容易に取得して、データベースの必要な項目に格納することができる。

上述した説明ではインスタンス情報を制約に違反することなく生成できる例を示した。制約違反が発生する場合は、制約違反となる事例のインスタンス情報を生成する。例えば、Alloyを用いる場合、すべてのインスタンスが守る必要のある制約を、assert文を用いて定義する。Alloyツールでは、assert制約に矛盾する反例があるかどうかを検索できる機能をもっている。マッピング部１２は、assert文で示される制約が充足しない反例の有無を調べ、反例が存在する場合は、反例を生成する。全ての制約が充足していれば反例は生成されない。すなわち制約を満たすインスタンス情報が生成される。以下、具体例を示す。

前述した例で接点FI101に付与された４つのタグ情報のうち、ahuRefが設定されていなかったとする。すなわち、ユーザが、接点FI101に、タグ情報として以下の表に示す３つのタグ情報のみを定義したとする。

図１２は、前述の＜制約４＞に相当するasssert定義の例である。図１２の制約は、すべてのタグ(Tag)は、センサ接点(ThePoint)と関連付けられる(hasTag)ことを定義している。すなわち、図１２の制約は、全てのTagは、いずれかの接点に属する(hasTag)ことを定めている。

図１２の例では、すべてのタグ(Tag)は、センサ接点(ThePoint)と関連づけられる (hasTag)ことが定義されている。上述の４つのタグ情報が全て接点Fl101に対して設定されていた場合には、図１２のassert制約と矛盾する反例は生成されない。しかし、タグ情報ahuRefをFI101に対して設定せずに、センサ情報マッピングを行うと、どの接点(ThePoint)にも属さないahuRefタグのインスタンス化が可能であることを示す反例が生成される。

図１３は、反例の例を示す。ahuRef$0はどのセンサ接点にも属さない。ahuRef$0タグがどの接点にも属さないことは、＜制約４＞に違反する。すなわち＜制約４＞が満たされていない。なお、図４のtagHmdは別の接点に対して設定されており、タグ付けの漏れは無かったとする。

図１４は、反例を表形式で表したものである。＜制約４＞によれば、TagクラスのインスタンスであるahuRef$0は、いずれかのThePointクラスのインスタンスに対して、 hasTag関係を持たなければならない。しかしながら、図１４の表では、「対象」の列にahuRef$0を有し、「主語」の列にThePointクラスを有する行が存在しない。よって、この反例が＜制約４＞を満たしていない。

制約違反検出部１３は、反例のインスタンス情報に基づき制約違反があることをユーザに通知する第１情報を出力する。第１情報は一例として反例を含む。ユーザから修正の指示データを受けて、制約違反検出部１３は、タグ定義情報２３又は情報モデル２２の修正し、あるいは、接点に対するタグ情報の追加又は削除等を行う。ユーザは、反例を見ることで、接点に対して、タグ情報(ahuRef)の設定が不足していることを理解する。

図１５は、制約違反検出部１３のブロック図である。制約違反検出部１３は、タグ矛盾検出部３２と、タグ不足検出部３１と、タグ情報修正部３３と、定義修正部３４とを備える。

タグ不足検出部３１は、反例から、設定が不足しているタグ情報の検出又はタグ情報の設定が不足していることの検出を行う。前述の図１３又は図１４の例では、どの接点(ThePoint)にも属さないahuRefタグのインスタンス化が可能であることを示す反例が生成される。タグ不足検出部３１は、この反例から、接点に対して、タグ(ahuRef)の設定不足していることを検出する。タグ情報修正部３３が、検出したタグ情報をユーザに出力し、修正をユーザに促す。

例えば、図１４の表から、ThePointクラスのインスタンスは、fl101$のみである。よって、接点fl101に対して、ahuRefタグの設定が不足していたことが推測される。図１６は、不足していたahuRefタグに関する情報を一行で示したものである。よって、＜制約４＞を満たすためには、図１６に示した情報に基づき、ahuRefタグに関するインスタンスを追加すれば、十分である。タグ情報修正部３３は、図１６の情報をユーザに出力してもよい。ユーザは図１６の情報を見て、ahuRefタグを接点fl101$1に追加設定することを決定できる。

タグ情報の設定不足が検出されることは、制約充足問題においては、制約が足りない状態、すなわち“under constraint”状態を意味する。この場合、情報モデル２２の制約が充足されるものの、所望ではないインスタンス構成（インスタンス間の結合関係）が生成されることになる。そこで、作成されたインスタンス情報をユーザが見て、所望のインスタンス構成、及び所望でないインスタンス構成を特定し、両者の差分により、不足するタグ情報をユーザが見つけてもよい。

タグ情報修正部３３は、ユーザがからタグ情報の追加設定の指示を受け、指示されたタグ情報を接点に追加設定することをタグ情報設定部１１に依頼する。タグ情報設定部１１は依頼されたタグ情報を接点に対して追加する記述を、インスタンス生成の定義の記述に追加する。この後、マッピング部１２がインスタンス生成を再度行う。これにより、正しいインスタンス情報（マッピング情報）を生成することができる。

タグ矛盾検出部３２は、反例に基づき、接点に情報モデル及びタグ情報のそれぞれに関する制約に矛盾するタグ情報が設定されているかを検出する。矛盾するタグ情報が設定されている場合、当該制約を充足するインスタンス情報を生成することができない。

例えば、情報モデルに定義されていないセンサ（例えば赤外線センサ）を参照するタグ情報が、接点に付与されていたとする。この場合、情報モデルには赤外線センサのクラスが存在しないことから、赤外線センサのインスタンスは生成されず、当該赤外線センサのインスタンスと当該タグ情報のインスタンスとの関連を示すインスタンス構成も生成されない。

このように、タグ矛盾検出部３２は、制約を充足するインスタンスを生成されなかったとの情報（上記の例では赤外線クラスのインスタンスが生成できない等）をトレース情報として検出できる。タグ情報を修正することにより、矛盾のないタグ情報の設定が可能となり得る。タグ情報の修正は、タグ情報修正部３３がトレース情報を元に、矛盾するタグのタグ情報の設定を、接点から削除することで行ってもよい。トレース情報をユーザに提示して、ユーザが削除するタグ情報を決定し、タグ情報修正部３３にタグ情報の削除を指示してもよい。

接点に正しく（矛盾無く又は不足なく）タグ情報が設定されていても、情報モデルの定義（構成）又はタグ情報の定義自体に不備がある場合もある。情報モデルの定義の修正（制約の修正も含む）、又はタグ情報の定義の修正（例えば制約の修正も含む）することができる。修正により、例えばタグ情報の定義の不足を解消することができる。この修正は、例えば定義修正部３４がユーザからの指示データに基づき、タグ定義情報２３又は情報モデル２２に対して行う。

例えば、タグ矛盾検出部３２により画面に提示されたトレース情報等に基づき、ユーザが情報モデル又はタグ定義情報をどのように修正するかを決定し、修正指示を入力インタフェースから入力する。定義修正部３４が情報モデル２２又はタグ定義情報２３を、修正指示に従って、修正する。

例えば、＜制約４＞が不足しているとき、意図しないインスタンスが生成されることで、制約の不足が検知される。生成されたインスタンスのうちの所望のインスタンス及び所望でないインスタンスを判断し、これらのインスタンスの差分情報をもとに、制約を追加することで、タグ定義情報２３を修正することができる。もしahuRef$0が本来不要であった場合は、タグ定義情報２３からahuRef$0を削除する修正を行うこともあり得る。

このように、タグ情報の矛盾又はタグ情報の不足を検知し、正しいタグ情報をセンサの接点に設定することで、センサに対する関係（第２関係）を、制約に矛盾せずに、情報モデルに追加できる。上述した例では接点としてセンサの接点を記載したが、アクチュエータ（VAV）との接点に対しても同様に、本実施形態の手法を、適用可能である。

決定部１４は、マッピング情報（正しく生成されたインスタンス情報）に基づき、接点に関連する機器（本例では温度センサ）と、情報モデル内の他の要素との関係を特定する。一例としてタグ情報によって設定された第２関係を特定する。その他情報モデルに元々温度センサに対して設定された第１関係を特定してもよい。決定部１４は特定した関係に基づき、機器の属性情報又は機器から取得したデータの属性情報を決定する

図１０又は図１１のインスタンス情報の例では、タグ情報によって設定された第２関係として、接点が設定された機器（対象となる機器）が温度センサ（tmpsensor101$0）であることを示す関係（isAssocTo）が特定される。また、第２関係として、当該温度センサがAHU$0によって制御される関係（controledBy）、当該温度センサがRM101$0に配置される関係（isLocated）、温度センサが温度（temperature$0）を観測する関係（observes）が特定される。したがって、例えば機器の属性情報として、温度センサであるtmpsensor101$0、制御対象(controlled target)であるAHU$0、配置場所であるRM101$0、観測対象である温度が決定される。

変換ルール生成部１６は、接点に対応するセンサのデータを、上記で決定した属性情報に基づいて、対象システムのデータ構造に応じた形式、すなわち、センサデータベース２５の形式に変換する変換ルール２４を生成する。つまりセンサのデータを取得、データの変換、データの格納の手順を変換ルールとして生成する。この手順は、IoTの分野では、ETL手順と呼ばれる。ETL手順は、抽出し(Extract)、変換し(Transform)、格納する(Load)ことを含む手順である。例えば、センサデータベース２５の項目として、「機器の種類」、「制御対象」、「配置場所」、「観測対象」、「機器の観測値」が含まれていたとする。上記の例では、センサのデータ（観測値）の入力を、「機器の種類、制御対象、配置場所、観測対象、機器の観測値」に変換する変換ルール２４を生成する。例えば、センサのデータが“１４７”であれば、変換ルール２４により、“１４７”が、「tmpsensor101$0、AHU$0、RM101$0、temperature$0、１４７」に変換されることになる。変換ルール生成部１６は、変換ルール２４を接点に対応する機器の識別情報（本例ではfl101）に関連づけて変換ルール記憶部１７に格納する。なお、ここではインスタンス名（tmpsensor101$0、AHU$0、RM101$0、temperature$0）を格納したが、インスタンス名をユーザが可読しやすい表現に変更してもよい。例えばRM101$0の代わりに実際の部屋番号を用いてもよい。temperature$0の代わりに、“温度”を用いてもよい。またAHU$0の代わりに、AHUの実際の識別情報（名前等）を用いてもよい。また、tmpsensor101$0の代わりに、温度センサの実際の識別情報（名称等）を用いてもよい。

受信部１９は、センサ又は設備システム１から送信されるセンサのデータを受信する。センサのデータには、センサの識別情報（接点の識別情報）が関連づけられている。

処理実行部１８は、当該接点の識別情報を有する変換ルール記憶部１７から読み出し、読み出した変換ルールに従って、センサのデータを変換する。センサの識別情報がfl101であり、センサのデータが“１２３”であれば、変換ルールの実行により、「tmpsensor101$0、AHU$0、RM101$0、temperature$0、１２３」を出力する。処理実行部１８は出力されたデータをセンサデータベース２５に格納する。

図１７は、センサデータベース２５の一例を示す。この例では関係データベースを示しているが、XMLデータベースなど、他のデータベースでもよい。

このセンサデータベース２５を参照することで、センサから受信したデータがどのような属性情報をもつのか、つまりセンサの属性情報を容易に特定できる。このデータベースを利用して例えば対象システム１００の構成を正しく理解し、監視することができる。またセンサの観測値（データ）を制御プログラムのどの変数（第１変数）に入力して、どのアクチュエータ（本例ではAHU$0）を制御する変数（第２変数）を算出すればよいかが分かる。制御プログラムの第１変数に１４７を入力し、AHU＄０を制御する第２変数を算出し、第２変数が示す制御情報を設備システム１に送信するように制御プログラムを調整することができる。調整のための指示情報をマッピング装置５は制御システム２に送信し、制御システム２は指示情報に従って、設備システム１から受信したセンサのデータを第１変数に入力できる。また第２変数を算出し、設備システム１の該当するAHU（AHU$0）に制御情報を送信することができる。これにより適正に制御システム２は設備システム１を制御できる。

なお、上述した例では接点に設定したすべてのタグ情報に基づき属性情報を設定したが、設定したタグ情報の一部に基づき属性情報を設定してもよい。

図１８は、本実施形態に係る情報処理システムのハードウェア構成図である。情報処理システムは、ホストシステム４１と、制御コントローラ４２と、センサ４３と、アクチュエータ４４と、対象設備（対象機器）４５とを含む。

制御コントローラ４２はバス６０を介して、ホストシステム４１に接続されている。制御コントローラ４２は、設備システム１のセンサ４３から検出されたデータに基づき、アクチュエータ４４を介して、設備システム１における対象設備４５を制御する。制御コントローラ４２には制御プログラムが格納されており、制御コントローラ４２に含まれるＣＰＵ等のプロセッサが制御プログラムを実行することで制御コントローラ４２の機能を実現する。また制御コントローラ４２はバス６０を介して、ホストシステム４１と通信を行う。

ホストシステム４１は、ＣＰＵ５１、記録メディア５２、ＲＡＭ５３、ユーザインタフェース５４、通信インタフェース５５、データベース５６等を備えている。

記録メディア５２は、ＨＤＤ又はＳＳＤ等を含む。記録メディア５２には、設備システムの監視及び制御に必要なコンピュータプログラムが格納されている。

ＣＰＵ５１は、バス６０を介して制御コントローラ４２と接続し、制御コントローラ４２を制御すると共に、記録メディア５２に格納されたコンピュータプログラムを実行する。

ＲＡＭ５３は、ＳＲＡＭ，ＤＲＡＭ又はフラッシュメモリ等を含む。ＲＡＭ５３は、ＣＰＵ５１の実行時には、必要に応じて記録メディア５２に格納されているコンピュータプログラム等が展開され、一時的に記憶する。

ユーザインタフェース５４は、ディスプレイ，キーボード及びマウス等を含む。ユーザインタフェース５４は、ユーザからの入力の受付けや、ユーザへの情報出力が可能である。
通信インタフェース５５は、バス６０を介して、制御コントローラ４２と通信を行う。

データベース５６は、マッピング装置内のセンサデータベース２５を含む。またデータベース５６は、センサ一覧表２１、タグ定義情報２３、情報モデル２２等を記憶する。データベース５６に記憶されるデータ又は情報の一部がＲＡＭ５３に記憶されてもよい。

図１９は、本実施形態に係るマッピング装置５の動作の一例のフローチャートである。マッピング装置５は、ユーザからのタグ情報の定義及び制約の入力を受け付け、タグ定義情報２３を作成し、タグ定義情報２３を情報モデル管理装置４に格納する（Ｓ１０１）。

情報モデル２２は予め情報モデル管理装置４に格納されている。タグ情報設定部１１は、センサ一覧表２１内の各センサについて、ユーザの指示データに基づき、タグ定義情報２３で定義されている複数のタグ情報の中から１つ又は複数のタグ情報を選択し、選択したタグ情報をセンサに対して設定する（Ｓ１０２）。具体的には、各センサとの接点に対して、選択したタグ情報を設定する。またタグ情報設定部１１は、ユーザの指示データに基づき、接点インスタンスを含む複数のインスタンスの生成の定義の記述を生成する。当該定義の記述は、接点ごとに行う。

マッピング部１２は、生成されたインスタンス生成の定義の記述と、情報モデル２２と、タグ定義情報２３に基づき、インスタンス情報（例えばインスタンス図又はインスタンス表）をマッピング情報として生成する（Ｓ１０３）。マッピング情報は、複数の要素間の第１関係を含む情報モデルにタグ定義情報で指定された条件の成否に応じて、接点インスタンスに対応する要素（第１要素）に対して、他の要素（第２要素）との間に第２関係を設定した情報に相当する。マッピング部１２は、このように第２関係を設定する設定部に対応する。

制約違反検出部１３は、インスタンス情報（マッピング情報）に基づき、接点に設定されたタグ情報の不足、又は接点に設定されたタグ情報の矛盾があるかを判断する（Ｓ１０４）。制約違反検出部１３、不足又は矛盾を検出した場合、ユーザに不足又は矛盾を示す情報、不足又は矛盾の根拠となる情報を出力する（同Ｓ１０５）。ユーザから修正の指示データを受信した場合は、指示データに応じて、接点に設定されたタグ情報の修正・削除・追加、タグ定義情報の修正、又は情報モデルの修正を行う（Ｓ１０５）。タグ情報の修正・削除・追加は、タグ情報設定部１１に依頼し、タグ情報設定部１１がタグ情報の修正・削除・追加を行ってもよい（Ｓ１０２）。

タグ情報の不足又は矛盾が存在しない場合は、決定部１４は、今回生成されたマッピング情報が前回、同じ接点に対して生成されたマッピング情報と同じかを判断する。決定部１４は図示しない記憶部又は情報モデル管理装置４にこれまで生成したマッピング情報を格納しておくとする。マッピング情報が前回生成したマッピング情報と同じ場合、変換ルール生成部１６の処理を省略して、処理実行部１８の処理（Ｓ１０７）に進む。マッピング情報が前回生成したマッピング情報と異なる場合は、あるいは、今回初めて上記のセンサに対してマッピング情報が生成された場合は、決定部１４が、マッピング情報に基づき接点に対応する機器の属性情報を決定する（Ｓ１０６）。そして、変換ルール生成部１６が、決定された属性情報に基づき、変換ルール２４を生成する（同Ｓ１０６）。変換ルール２４は、接点に対応するセンサのデータを対象システム１００に関するデータ構造に応じた形式に変換する。変換ルール生成部１６は、生成した変換ルール２４を変換ルール記憶部１７に格納する。この後、ステップＳ１０７に進む。

ステップＳ１０７において、処理実行部１８は、受信部１９で受信されたセンサデータ２６に基づき、センサの識別情報を特定し、特定した識別情報を有する変換ルールを変換ルール記憶部１７から読み出す。読み出した変換ルールに従ってセンサデータ２６（例えばセンサの観測値）を変換し、変換後のデータをセンサデータベース２５に格納する。

以上、本実施形態によれば、センサ又はアクチュエータにタグ情報と呼ばれるラベルを設定し、タグ情報と情報モデルとの間の関係を定義することにより、自動的に情報モデルへのマッピングを行うことができる。またセンサ・アクチュエータに設定するタグ情報に不足又は矛盾あるとき、この不足又は矛盾を検出することができる。これにより、正しいタグ情報を定義し直したり、タグ情報を修正したりすることで、マッピングの省力化が図れる。

＜第２実施形態＞
第１実施形態では対象システム１００がビル空調システムの場合を説明したが、第２実施形態では、対象システム１００がボイラ制御システムの場合を説明する。対象システム１００が異なる点を除き、基本的な構成及び動作は同じため、詳細な説明は適宜省略する。

図２０は、本実施形態に係る対象システム１００としてボイラ制御システム（設備システム１及び制御システム２）の具体例を概略的に示す。設備システム１において、ボイラ２０１によって空気で燃料を燃やして熱を発生させ、ドラム２０２は熱により水を蒸気にする。ドラム２０２に対して燃料を供給する燃料パイプ２０３、ドラム２０２に空気を供給する空気パイプ２０４、ドラム２０２に水を供給する給水パイプ２０５、蒸気を出力する主蒸気パイプ２０６が接続されている。主蒸気パイプ２０６には主蒸気流量計２０７が備わっている。主蒸気パイプ２０６とドラム２０２の間は蒸気バイパスパイプ２１３によって接続され、蒸気バイパスパイプ２１３の途中には蒸気バルブ２１４が設けられている。制御システムは、サブシステムとして、主蒸気流量に基づき炉内圧力を制御する炉内圧力制御系２２１、ドラムの水位を調整するドラムレベル制御系２２２、燃料流量制御系２２３、空気流量制御系２２４、及び、給水流量制御系２２５を備える。燃料流量制御系２２３、空気流量制御系２２４、及び、給水流量制御系２２５の出力流量を調整する流量調節計２２７、２２８、２２９が設けられている。炉内圧力制御系２２１の出力側に炉内圧力を調節する圧力調節計２２９が設けられている。燃料パイプ２０３、空気パイプ２０４、給水パイプ２０５には、それぞれ制御のアクチュエータとして、流量調整バルブ（燃料流量調整バルブ２０８、空気流量調整バルブ２０９、給水流量調整バルブ２１０）が備わっている。また、制御のアクチュエータとして、ドラムレベル調整装置２１１（ドラムレベル制御装置）、炉内圧力調整装置２１２（炉内圧力制御装置）が設けられている。

各制御系はPID（Proportional-Integral-Differential Controller）制御を基本としている。炉内圧力制御系２２１のPID出力が空気流量制御系２２４と燃料流量制御系２２３とにカスケード接続している。ドラムレベル制御系２２２のPID出力が、給水流量制御系２２５と液面調節計２２６とにカスケード接続している。

図２１は、本実施形態における情報モデル２２としてボイラ制御システムのモデルを表している。ソフトウエア工学のクラス図に従って情報モデルを表している。ボイラ制御システムに含まれる要素間に成立する関係を定義している。例えば「主蒸気流量計」は「炉内圧力制御」は、制御信号を入力する関係”ctr_input”で接続されている。なお、図２１では図２０の要素の一部、例えば給水流量調整バルブ、炉内圧力制御装置等は省略されている。“LoP”はList of Propertyの略であり、前述した“Tag”（タグ）に相当する用語である。“LoP”を“Tag”に読み替えてもよい。

センサやアクチュエータ等の機器に対する接点(ThePoint)は、機器モデル（deviceModel）と関連(hasDeviceModel)づけられる。また、接点(ThePoint)は、LoP(Tag)を複数持つ(hasLoPあるいはhasTag)ことができる。

DeviceModelは、特定の機器のモデルのクラスである。特定の機器のモデルのクラスを承継して、主蒸気流量計のモデル、燃料流量調整バルブのモデル、空気量調整バルブのモデルが、それぞれDM主蒸気流量計、DM燃料流量調整バルブ、DM空気量調整バルブとして定義される。

タグ情報として、主蒸気流量計に対して、LoPセンサ、LoP流量、LoP蒸気などのタグ情報が定義される。より詳細には、LoPセンサ、LoP流量タグ、LoP蒸気は、Tagクラス（LoPクラス）を継承したクラスとして定義されている。その他のタグ情報として、LoP燃料流量調整、LoP空気流量調整（図示せず）、LoP炉内圧力制御（図示せず）等も定義されている。

タグ情報の定義として、第１実施形態と同様の制約を定義できる。例えば、前述した空調システムの例の場合と同様、以下の制約が定義される。
＜制約３＞全てのTagは、いずれかの機器モデルの一部(part of)でないといけない。
＜制約４＞全てのTagは、いずれかの接点に属する(hasLopあるいはhasTag)。

図２２は、図２１の情報モデルをAlloyの形式で記述したものである。なお、図２１におけるDM主蒸気流量計、DM燃料流量調整バルブ、DM空気量調整バルブのそれぞれのクラスの定義（deviceModelを継承するクラスの定義）等は省略している。

図２３（Ａ）は、タグ情報の定義をAlloyの形式で記述したものである。タグの抽象クラスとしてLoPが定義され、LoPはdeviceModelの一部（partOf）である。LoPを継承して、３つのタグ（LoP蒸気, LoP流量, LoPセンサ）を定義している（個別LoPの定義）。それぞれのタグは、DM主蒸気流量計の一部（partOf）である。図２３（Ｂ）は、全ての機器モデル（deviceModel）は、いずれかのTheEntityに関連する(isAssocTo)”との制約である。

図２４は、情報モデルに関するタグ情報の制約をAlloyの形式で定義した例を示す。factは制約を意味する。
１つ目の制約は、機器モデルであるDM主蒸気流量計は、３つのタグ情報を部品として持つという制約である。
２つ目の制約は、すべてのタグ情報は機器モデルの一部であるという制約である。
３つ目の制約は、すべてのタグ情報は、接点(ThePoint)に属している(hasLoP)という制約である。

以下、具体例を用いて、説明を続ける。
タグ情報設定部１１において、接点(FI101)に、LoP蒸気、LoP流量、LoPセンサ, LoP燃料流量調整バルブ, LoP空気流量調整バルブ, LoP炉内圧力制御という6つのタグ情報を設定したとする。

本例でも、空調システムの例の場合と同様、Alloyとよばれるソフトウエアを用いて、マッピング部１２が、マッピング情報の生成（インスタンス生成）を行う

図２５は、接点Fl101に対してLoP蒸気、LoP流量、LoPセンサの３つのタグ情報を設定する様子（ユーザの入力の様子）を示している。またその他のとして、接点pic102に対してLoP炉内圧力制御のタグ情報を設定している。また、接点fic101sに対して、LoP燃料流量調整バルブのタグ情報を定義している。さらに、接点fic103に対して、LoP空気流量調整バルブのタグ情報を定義している。このようにユーザの指示データに基づきタグ情報設定部は、図２５に示した接点のインスタンスの定義を行い、その他のインスタンスの定義（図示せず）も行う。

図２６は、Alloyツールの実行(excecute)機能を用いて、インスタンス生成を実行することにより生成されたインスタンス情報（マッピング情報）を示す。インスタンス生成の実行は、図２５のインスタンス生成のコードと、図２２の情報モデルと、図２３及び図２４のタグ定義情報とに基づき行われる。図２６では、インスタンス情報がインスタンス図によって表されている。インスタンスにはクラスと区別するため”$0”などの文字が追加されている。

図２６において、DM主蒸気流量計$0は主蒸気流量計$0に関連している(isAssocTo)。主蒸気流量計$0は、ドラムレベル制御$0と炉内圧力制御$0とに、ctr_input関係（制御を指示する関係）で接続されている。炉内圧力制御$0はさらに、燃料流量計$0と空気流量計$0とに、ctr_cascade関係（並列関係）で接続されている。ドラムレベル制御$0はドラムレベル制御装置$0とctr_output関係（制御出力を指示する関係）で接続されている。燃料流量制御$0は、燃料流量調整バルブ$0にctr_output関係で接続されている。空気流量制御$0は、空気流量調整バルブ$0にctr_output関係で接続されている。

センサ接点fl101$0は、３つのタグ情報、LoP蒸気$0、LoP流量$0、LoPセンサ$0を持ち(hasLoP)、それぞれのタグ情報は、センサであるDM主蒸気流量計$0の一部である(part of)。センサ接点fl101$0は、DM主蒸気流量計$0を介して、主蒸気流量計$0に関連づけられている(isAssocTo)。すなわち、タグ情報は主蒸気流量計$0が接点の対象（観測の対象）であることをisAssocToという関係（第２関係）によって示している。

fic101s$0は、タグ情報としてLoP燃料流量調整バルブ$0を持ち、タグ情報は機器モデル（DM燃料流量調整バルブ$0）の一部である(part of)。fic101s$0は、DM燃料流量調整バルブ$0を介して、燃料流量調整バルブ$0に関連づけられている(isAssocTo)。すなわち、タグ情報は燃料流量調整バルブ$0が接点の対象（操作の対象）であることをisAssocToという関係（第２関係）によって示している。

fic103$0は、タグ情報としてLoP空気流量調整バルブ$0を持ち、タグ情報は機器モデル（DM空気流量調整バルブ$0）の一部である(part of)。fic103$0は、DM空気流量調整バルブ$0を介して、空気流量調整バルブ$0に関連づけられている(isAssocTo)。すなわち、タグ情報は空気流量調整バルブ$0が接点の対象（操作の対象）であることをisAssocToという関係（第２関係）によって示している。

pic102$0は、タグ情報としてLoP炉内圧力制御$0を持ち、タグ情報は機器モデル（DM炉内圧力制御$0）の一部である(part of)。pic102$0は、DM炉内圧力制御$0を介して、炉内圧力制御$0に関連づけられている(isAssocTo)。すなわち、タグ情報は炉内圧力制御$0が接点の対象（操作の対象）であることをisAssocToという関係（第２関係）によって示している。

このように、センサ又はアクチュエータ等の特定の機器のインスタンスに対してタグ情報が示す関係を設定することを、情報モデルの制約及びタグ情報の制約に矛盾なく、行うことができる。図２６のインスタンス図は、センサの検出データ又はアクチュエータの操作データ（制御情報）を保存するデータベースのスキーマそのものであるといえる。

次に、制約違反検出部１３によるタグ情報欠損検知の事例を示す。前述の事例において、接点FI101に対して設定された６つのタグ情報のうち、LoP流量の設定がなかったとする。すなわち接点FI101に対して、以下のように５つのタグ情報（LoP蒸気、LoPセンサ、LoP燃料流量調整バルブ、LoP空気流量調整バルブ、LoP炉内圧力制御）が設定されたとする。

タグ情報の制約として図２７の制約があったとする。図２７は、前述した＜制約４＞に相当するasssert定義の例である。図２７の制約は、すべてのタグ情報(Tag)は、センサ接点(ThePoint)と紐づけられる(hasLoP)ことを定義している。すなわち、図２７の制約は、全てのタグ情報（Tag）は、いずれかの接点に属する(hasLoP)ことを定めている。

制約違反検出部１３は、Alloyツールの機能として、assert制約に矛盾する反例があるかどうかを検索できる機能をもっている。先ほどのタグ情報が６つ全て設定されていた場合には、assert制約と矛盾する反例は生成されない。しかし、タグ情報としてLoP流量が接点FI101に設定されない場合、どの接点(ThePoint)にも属さない、LoP流量タグのインスタンス化が可能であることを示す反例が生成される。

図２８は、生成された反例の例を示す。LoP流量$0はどの接点にも属さないタグ情報となり、これは＜制約４＞を満たしていない。この反例からLoP流量のタグ付けが漏れていることがわかる。

制約違反検出部１３の動作は第１実施形態と同様であるため説明を省略する。

決定部１４は、マッピング情報（正しく生成されたインスタンス情報）に基づき、接点に関連する機器（本例では温度センサ）と、情報モデル内の他の要素との関連を特定する。図２６の例では、例えば接点が、主蒸気流量計を観測の対象としていることをisAssocToにより特定する。特定した関係に基づき、機器の属性情報を決定する。例えば決定部１４は、属性情報として、観測対象が主蒸気流量計であることを決定する。

変換ルール生成部１６は、決定部１４により決定された属性情報と、対象システム１００の情報モデルの具体的なデータ構造と、インスタンス情報と、受信部１９で受信されるデータのデータ構造とに基づき、変換ルール２４を生成する。

図２９は、対象システム１００（ボイラ制御システム）に関する具体的なデータ構造の一例を示す。センサデータベース２５は、このデータ構造に従ってデータを格納する。このデータ構造は、XML又は関係データベースにより実現される。図２９において、“Dataitem”がセンサのデータ又はアクチュエータのデータを格納するデータ項目（フィールド）に対応する。Input”が制御系へ入力するデータを格納するデータ項目（フィールド）に対応し、“ControlOut”が制御系から出力するデータを格納するデータ項目（フィールド）に対応する。センサデータベース２５がフォルダ階層構造になっていてもよく、この場合、データを該当するフォルダ（データ項目）に格納してもよい。

センサから取得されるセンサデータ２６は、受信部１９で受信される。

図３０は、センサデータ２６のデータ構造（ソースデータ構造）の一例を示す。送信側においてセンサデータ２６にセンサの検出値（観測値）及びセンサ名（センサ識別情報）以外に、タグ情報が設定される。図の例では、センサの接点の名前が“fl101”であり、接点に設定されているタグ情報が“Lop蒸気”、“LoP流量”等であり、センサの観測値が“133”である。図３０のソースデータ構造では１つのセンサに対するソースデータ構造が示されるが、他のセンサ又はアクチュエータに対応する接点についても同様にソースデータ構造が定義されてよい。

このようにセンサのデータがソースデータ構造を有する場合を前提に変換ルールの生成例を説明する。

図３１は、変換ルール生成部１６が変換ルールを生成する事例を示す。この例では、インスタンス情報と、ソースデータ構造におよび、対象システム１００に関するデータ構造に基づき、センサのデータを当該データ構造に合わせて変換する変換ルールを生成している。
変換ルール
（１） ソースのname==“fl101”のVariableのvalue
=>ターゲットの、BoilerSystem>Drum101>Pipe_Steamの主蒸気流量のDataItem
（２） ．．．．．．

つまり変換ルール（１）は、ソースのデータ構造において、接点の値が“fl101”であるセンサ変数（Variable）の値を、BoilerSystem>Drum101>Pipe_Steamの主蒸気流量計のデータ項目値（例えば主蒸気流量値）へ変換する。タグ情報によって参照すべき主蒸気流量計が、具体的に属性情報として特定され、対象システム１００に関するデータ構造（図２９参照）から当該主蒸気流量計と、BoilerSystem及びDrum101との関係（階層関係）も把握できる。第２実施形態では対象システム１００に関するデータ構造を利用して主蒸気流量計と他の要素との階層関係を特定した。しかしながら、第１実施形態のように情報モデルでBoilerSystem及びDrum101等を定義することで、属性情報としてBoilerSystem及びDrum101を把握してもよい。変換ルールは、接点の値（センサの名称）とタグ情報と関連付けて変換ルール記憶部１７に記憶される。

処理実行部１８は、受信部１９からセンサのデータ（ソースのデータ構造）を受信すると、データに含まれる接点の値（名前）とタグ情報とに基づき、変換ルール記憶部１７から変換ルールを選択し、選択した変換ルールを読み出す。処理実行部１８は、読み出した変換ルールに従って、データに含まれる変数の値から、対象システム１００に関するデータ構造に合わせた形式のデータを生成する。処理実行部１８は、生成したデータをセンサデータベース２５に格納する。

上述の図３０に示したデータ構造を有するセンサのデータが受信された場合、生成されたデータは、例えば、「BoilerSystem>Drum101>Pipe_Steamの主蒸気流量“133”」である。例えば生成されたデータをXML形式で表現して、センサデータベース２５に格納してもよい。あるいは、センサデータベース２５が関係データベースの場合、該当する複数の項目に“BoilerSystem”、“Drum101”、“Pipe_Steam”、“主蒸気流量”、“133”を格納してもよい。

図３２（Ａ）は、関係データベースにおける複数の項目に“BoilerSystem”、“Drum101”、“Pipe_Steam”、“主蒸気流量”、“133”を格納した例を示す。他の方法として、フィールド名に“BoilerSystem”、“Drum101”、“Pipe_Steam”、“主蒸気流量”等、可能性のあるすべての項目名を用意する。そして、項目に該当する場合は“Ｔ”又はセンサの値等を格納し、該当しない項目には“Ｆ”又はNullを格納する。図３２（Ｂ）は、“BoilerSystem”、“Drum101”、“Pipe_Steam”、“主蒸気流量”の項目に“Ｔ”又はセンサの値を格納し、他の項目には“Ｆ”を格納した例を示す。

図３３は、生成された変換ルールを用いてタグ情報（LoP情報）が付与された接点(f101)に対応するセンサの変数の値(“133”)から、対象システム１００に関するデータ構造に合わせた形式のデータを生成する様子を示している。主蒸気流量計に対応するデータ項目が特定される。特定したデータ項目にセンサの変数の値が格納される形式のデータを、センサデータベース２５に格納する。格納する形式は、図３２（Ａ）又は図３２（Ｂ）のような関係データベースでもよいし、あるいは、XMLデータベースでもよい。また、データベースは、フォルダ階層構造になっていてもよく、この場合、データを該当するフォルダ（データ項目）に格納してもよい。

なお、本発明は上記各実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記各実施形態に開示されている複数の構成要素を適宜組み合わせることによって種々の発明を形成できる。また例えば、各実施形態に示される全構成要素からいくつかの構成要素を削除した構成も考えられる。さらに、異なる実施形態に記載した構成要素を適宜組み合わせてもよい。

１ 設備システム
２ 制御システム
３ 設備管理装置
４ 情報モデル管理装置
５ マッピング装置
６ 入力装置
７ 表示装置
１１ タグ情報設定部
１２ マッピング部（設定部）
１３ 制約違反検出部
１４ 決定部
１６ 変換ルール生成部
１７ 変換ルール記憶部
１８ 処理実行部
１９ 受信部
２１ センサ一覧表
２２ 情報モデル
２３ タグ定義情報
２４ 変換ルール
２５ センサデータベース
２６ センサデータ
３１ タグ不足検出部
３２ タグ矛盾検出部
３３ タグ情報修正部
３４ 定義修正部
４１ ホストシステム
４２ 制御コントローラ
４３ センサ
４４ アクチュエータ
４５ 対象設備
５２ 記録メディア
５４ ユーザインタフェース
５５ 通信インタフェース
５６ データベース
６０ バス
６１ 温度センサ
６２ 空気調和機（AHU）
６３ 送風機（VAV）
１００ 対象システム
２００ 情報処理装置

Claims (20)

1. 複数の要素と前記要素間の第１関係とを含む第１情報における第１要素に対して、第２要素との間に第２関係を設定することを示す関係設定情報を選択する選択部と、
   前記関係設定情報に基づき、前記第１要素に対して少なくとも１つの前記第２要素との間に前記第２関係を設定する設定部と、
   設定された前記第２関係と前記第１情報とに基づいて、前記第１要素の属性情報を決定する決定部と
   を備えた情報処理装置。
2. 前記関係設定情報は、前記第１要素及び前記第２要素との間に存在する前記第１関係に基づく条件を含み、
   前記設定部は、前記条件が成立する場合に前記第２関係を設定する
   請求項１に記載の情報処理装置。
3. 前記条件は、前記第１要素と前記第２要素との間に存在する前記第１関係の種別が第１種別を含むことである
   請求項２に記載の情報処理装置。
4. 前記第１要素は、データを検出するセンサ又はデータが示す操作量に従って動作するアクチュエータである
   請求項１～３のいずれか一項に記載の情報処理装置。
5. 前記第２関係が設定された前記第１情報が制約を満たすかを検出し、前記制約が満たされない場合に、前記制約が満たされないことを示す情報を出力する検出部
   を備えた請求項１～４のいずれか一項に記載の情報処理装置。
6. 前記関係設定情報の修正の指示データを受信し、前記指示データに基づき、前記関係設定情報を修正する修正部
   を備えた請求項５に記載の情報処理装置。
7. 前記関係設定情報の追加又は削除の指示データを受信し、前記指示データに基づき、前記第１要素に対して前記関係設定情報を追加又は削除する修正部
   を備えた請求項５に記載の情報処理装置。
8. 前記検出部は、前記第１要素に対して選択される関係設定情報が不足していることを検出する
   請求項５に記載の情報処理装置。
9. 前記検出部は、前記第１要素に設定された前記第２関係が前記制約に矛盾していることを検出する
   請求項５に記載の情報処理装置。
10. 前記制約は、前記第１要素が前記複数の要素のうちの１つに設置されていることを示す前記第１関係が、前記第１要素に関連していることを要求する
    請求項５に記載の情報処理装置。
11. 前記選択部は、１つ以上の前記第１要素に対して複数の前記関係設定情報の中から１つ以上の前記関係設定情報を選択し、
    前記制約は、複数の前記関係設定情報のすべてが前記第１要素のいずれかに対して選択されることを要求する
    請求項５に記載の情報処理装置。
12. 前記データを受信する受信部を備え、
    前記データは前記センサの識別情報又は前記アクチュエータの識別情報を含み、
    前記識別情報が示す前記第１要素の前記属性情報を、受信された前記データに関連付けてデータベースに記憶する処理実行部と
    を備えた請求項４に記載の情報処理装置。
13. 前記第１要素に関するデータに前記属性情報を関連付ける変換ルールを生成する変換ルール生成部と、
    前記処理実行部は、前記変換ルールに従って、前記受信部で受信された前記データに前記属性情報を関連付ける
    請求項１２に記載の情報処理装置。
14. 前記設定部は、前記第２関係を設定することにより前記第１要素を、前記関係設定情報が示す前記第２要素にマッピングする
    請求項１～１３のいずれか一項に記載の情報処理装置。
15. 前記第１情報は、対象システムの情報モデルである
    請求項１～１４のいずれか一項に記載の情報処理装置。
16. 前記情報モデルは、建物の空調システムをモデル化したものであり、
    前記複数の要素は、前記建物を構成する部品、前記建物に設置されたセンサ、前記センサが計測する対象となる物理量、前記建物の空調を制御する制御システムを構成する部品、を含む
    請求項１５に記載の情報処理装置。
17. 前記情報モデルは、ボイラ制御システムをモデル化したものであり、
    前記複数の要素は、前記ボイラ制御システムで計測される物理量を計測するセンサ、操作量に応じた出力を行うアクチュエータ、前記アクチュエータを制御する制御系を含む、
    請求項１５に記載の情報処理装置。
18. 複数の要素と前記要素間の第１関係とを含む第１情報における第１要素に対して、第２要素との間に第２関係を設定することを示す関係設定情報を選択するステップと、
    前記関係設定情報に基づき、前記第１要素に対して少なくとも１つの前記第２要素との間に第２関係を設定するステップと、
    設定された前記第２関係と前記第１情報とに基づいて、前記第１要素の属性情報を決定するステップと、
    を備えた情報処理方法。
19. 複数の要素と前記要素間の第１関係とを含む第１情報における第１要素に対して、第２要素との間に第２関係を設定することを示す関係設定情報を選択するステップと、
    前記関係設定情報に基づき、前記第１要素に対して少なくとも１つの前記第２要素との間に前記第２関係を設定するステップと、
    設定された前記第２関係と前記第１情報とに基づいて、前記第１要素の属性情報を決定するステップと、
    をコンピュータに実行させるためのコンピュータプログラム。
20. 複数の要素を含む対象システムと、
    前記複数の要素と前記複数の要素間の第１関係とを含む第１情報における第１要素に対して、第２要素との間で第２関係を設定することを示す関係設定情報を選択する選択部と、
    前記関係設定情報に基づき、前記第１要素に対して少なくとも１つの前記第２要素との間に前記第２関係を設定する設定部と、
    設定された前記第２関係と前記第１情報とに基づいて、前記第１要素の属性情報を決定する決定部と
    前記対象システムにおける前記第１要素からデータを受信する受信部と、
    前記データと前記属性情報とを対応づけてデータベースに格納する処理実行部と
    を備えた情報処理システム。

Images