特開2020-204802(P2020-204802A)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ アズビル株式会社の特許一覧
<>
  • 特開2020204802-データ管理システムおよび方法 図000003
  • 特開2020204802-データ管理システムおよび方法 図000004
  • 特開2020204802-データ管理システムおよび方法 図000005
  • 特開2020204802-データ管理システムおよび方法 図000006
  • 特開2020204802-データ管理システムおよび方法 図000007
  • 特開2020204802-データ管理システムおよび方法 図000008
  • 特開2020204802-データ管理システムおよび方法 図000009
  • 特開2020204802-データ管理システムおよび方法 図000010
  • 特開2020204802-データ管理システムおよび方法 図000011
  • 特開2020204802-データ管理システムおよび方法 図000012
  • 特開2020204802-データ管理システムおよび方法 図000013
  • 特開2020204802-データ管理システムおよび方法 図000014
  • 特開2020204802-データ管理システムおよび方法 図000015
  • 特開2020204802-データ管理システムおよび方法 図000016
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】特開2020-204802(P2020-204802A)
(43)【公開日】2020年12月24日
(54)【発明の名称】データ管理システムおよび方法
(51)【国際特許分類】
   G06F 16/182 20190101AFI20201127BHJP
【FI】
   G06F16/182
【審査請求】未請求
【請求項の数】8
【出願形態】OL
【全頁数】14
(21)【出願番号】特願2019-110823(P2019-110823)
(22)【出願日】2019年6月14日
(71)【出願人】
【識別番号】000006666
【氏名又は名称】アズビル株式会社
(74)【代理人】
【識別番号】100098394
【弁理士】
【氏名又は名称】山川 茂樹
(74)【代理人】
【識別番号】100064621
【弁理士】
【氏名又は名称】山川 政樹
(72)【発明者】
【氏名】藤井 稔久
(57)【要約】      (修正有)
【課題】管理側の情報とサーバーとを同期して管理する必要を無くすためのデータ管理システム及びデータ管理方法を提供する。
【解決手段】データ管理システムは、データを記憶する複数のヒストリサーバー1−A〜1−Cと、ヒストリサーバー1−A〜1−Cを統括する統合管理部2と、を備える。統合管理部2は、クライアントからの要求内容を含む要求メッセージをヒストリサーバー1−A〜1−Cに同報送信する第1の送受信処理部20と、要求メッセージに対する各ヒストリサーバー1−A〜1−Cからの応答データの内容を統合した結果をクライアントに送信する第2の送受信処理部21と、を備える。各ヒストリサーバー1−A〜1−Cは、データを記憶するデータベース10と、受信した要求メッセージの要求内容に相当するデータを自装置のデータベース10内で管理しているときに、応答データを統合管理部2に送信する制御部14と、を備える。
【選択図】図1
【特許請求の範囲】
【請求項1】
データを記憶する複数のサーバーと、
前記複数のサーバーを統括する統合管理部とを備え、
前記統合管理部は、
クライアントからの要求内容を含む要求メッセージを前記複数のサーバーに同報送信するように構成された第1の送受信処理部と、
前記要求メッセージに対する各サーバーからの応答データの内容を統合した結果を前記クライアントに送信するように構成された第2の送受信処理部とを備え、
各サーバーは、
データを記憶するように構成されたデータベースと、
受信した要求メッセージの要求内容に相当するデータを自装置の前記データベース内で管理しているときに、応答データを前記統合管理部に送信するように構成された制御部とを備えることを特徴とするデータ管理システム。
【請求項2】
請求項1記載のデータ管理システムにおいて、
前記クライアントからの要求内容は、特定のデータを要求するものであり、
各サーバーの制御部は、前記要求メッセージの要求内容に相当するデータを自装置の前記データベース内で管理しているときに、管理しているデータとこのデータの期間の情報とを含む前記応答データを前記統合管理部に送信することを特徴とするデータ管理システム。
【請求項3】
請求項1記載のデータ管理システムにおいて、
前記クライアントからの要求内容は、特定のデータを管理しているかどうかの確認を要求するものであり、
各サーバーの制御部は、前記要求メッセージの要求内容に相当するデータを自装置の前記データベース内で管理しているときに、管理しているデータの期間の情報を含む前記応答データを前記統合管理部に送信し、
前記統合管理部の第2の送受信処理部は、前記応答データを送信したサーバーが管理しているデータの期間の情報とこのサーバーの識別情報とを対応付けた結果を前記クライアントに送信することを特徴とするデータ管理システム。
【請求項4】
請求項2または3記載のデータ管理システムにおいて、
各サーバーの制御部は、前記要求メッセージの要求内容に相当するデータを自装置の前記データベース内で管理していないときに、データが無いことを示す前記応答データを前記統合管理部に送信することを特徴とするデータ管理システム。
【請求項5】
クライアントからの要求内容を含む要求メッセージを、複数のサーバーを統括する統合管理部から前記複数のサーバーに同報送信する第1のステップと、
前記複数のサーバーのそれぞれが、受信した要求メッセージの要求内容に相当するデータを自装置のデータベース内で管理しているときに、応答データを前記統合管理部に送信する第2のステップと、
前記統合管理部が、前記要求メッセージに対する各サーバーからの応答データの内容を統合した結果を前記クライアントに送信する第3のステップとを含むことを特徴とするデータ管理方法。
【請求項6】
請求項5記載のデータ管理方法において、
前記クライアントからの要求内容は、特定のデータを要求するものであり、
前記第2のステップは、前記要求メッセージの要求内容に相当するデータを自装置のデータベース内で管理しているときに、管理しているデータとこのデータの期間の情報とを含む前記応答データを前記統合管理部に送信するステップを含むことを特徴とするデータ管理方法。
【請求項7】
請求項5記載のデータ管理方法において、
前記クライアントからの要求内容は、特定のデータを管理しているかどうかの確認を要求するものであり、
前記第2のステップは、前記要求メッセージの要求内容に相当するデータを自装置のデータベース内で管理しているときに、管理しているデータの期間の情報を含む前記応答データを前記統合管理部に送信するステップを含み、
前記第3のステップは、前記応答データを送信したサーバーが管理しているデータの期間の情報とこのサーバーの識別情報とを対応付けた結果を前記クライアントに送信するステップを含むことを特徴とするデータ管理方法。
【請求項8】
請求項6または7記載のデータ管理方法において、
前記第2のステップは、前記要求メッセージの要求内容に相当するデータを自装置のデータベース内で管理していないときに、データが無いことを示す前記応答データを前記統合管理部に送信するステップを含むことを特徴とするデータ管理方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、複数のサーバーにデータを分散して管理するデータ管理システムおよび方法に関するものである。
【背景技術】
【0002】
産業オートメーションの世界では従来よりも広範囲なデータ、1つ以上の製造現場と上位の経営側のアプリケーションとの情報連携など、を利用した解析により局所最適から全体最適に向けた動きがある。ヒストリデータのアクセスに関しては長期間に渡るデータにアクセスするケースが考えられ、そのデータ量は1つのヒストリサーバーで管理する量を超える場合がある。従来のように1つのヒストリサーバーが保持できるものを超える時間幅のデータを扱う場合には、つぎに挙げるような分断された作業を人手によって連結することが求められていた。
【0003】
従来の技術では、1つのサーバーで管理できないデータを複数のサーバーに分散させて管理するようにしている(特許文献1、特許文献2参照)。
特許文献1、特許文献2に開示された技術では、分散しているサーバーに関する情報を一括して管理する必要があり、サーバーの追加や構成変更などが行われた場合には、管理側の情報も変更する必要がある。管理側の情報とサーバーとを同期して管理する必要がある為に操作ミスが発生し、正しいデータを抽出できないというミスが発生する可能性があった。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特許第4948276号広報
【特許文献2】特開2001−265768号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
本発明は、上記課題を解決するためになされたもので、サーバーの追加や削除、構成変更などが行われた場合でも、管理側の情報とサーバーとを同期して管理する必要を無くすことができるデータ管理システムおよび方法を提供することを目的とする。
【課題を解決するための手段】
【0006】
本発明のデータ管理システムは、データを記憶する複数のサーバーと、前記複数のサーバーを統括する統合管理部とを備え、前記統合管理部は、クライアントからの要求内容を含む要求メッセージを前記複数のサーバーに同報送信するように構成された第1の送受信処理部と、前記要求メッセージに対する各サーバーからの応答データの内容を統合した結果を前記クライアントに送信するように構成された第2の送受信処理部とを備え、各サーバーは、データを記憶するように構成されたデータベースと、受信した要求メッセージの要求内容に相当するデータを自装置の前記データベース内で管理しているときに、応答データを前記統合管理部に送信するように構成された制御部とを備えることを特徴とするものである。
【0007】
また、本発明のデータ管理システムの1構成例において、前記クライアントからの要求内容は、特定のデータを要求するものであり、各サーバーの制御部は、前記要求メッセージの要求内容に相当するデータを自装置の前記データベース内で管理しているときに、管理しているデータとこのデータの期間の情報とを含む前記応答データを前記統合管理部に送信することを特徴とするものである。
また、本発明のデータ管理システムの1構成例において、前記クライアントからの要求内容は、特定のデータを管理しているかどうかの確認を要求するものであり、各サーバーの制御部は、前記要求メッセージの要求内容に相当するデータを自装置の前記データベース内で管理しているときに、管理しているデータの期間の情報を含む前記応答データを前記統合管理部に送信し、前記統合管理部の第2の送受信処理部は、前記応答データを送信したサーバーが管理しているデータの期間の情報とこのサーバーの識別情報とを対応付けた結果を前記クライアントに送信することを特徴とするものである。
また、本発明のデータ管理システムの1構成例において、各サーバーの制御部は、前記要求メッセージの要求内容に相当するデータを自装置の前記データベース内で管理していないときに、データが無いことを示す前記応答データを前記統合管理部に送信することを特徴とするものである。
【0008】
また、本発明のデータ管理方法は、クライアントからの要求内容を含む要求メッセージを、複数のサーバーを統括する統合管理部から前記複数のサーバーに同報送信する第1のステップと、前記複数のサーバーのそれぞれが、受信した要求メッセージの要求内容に相当するデータを自装置のデータベース内で管理しているときに、応答データを前記統合管理部に送信する第2のステップと、前記統合管理部が、前記要求メッセージに対する各サーバーからの応答データの内容を統合した結果を前記クライアントに送信する第3のステップとを含むことを特徴とするものである。
【発明の効果】
【0009】
本発明によれば、複数のサーバーに関する情報を統合管理部で管理する必要がなくなるので、サーバーの追加や削除、構成変更などが行われた場合でも、統合管理部には何の変更を加えることなく、その変更を反映した形で処理を継続することができる。その結果、本発明では、正しいデータを抽出できないというミスが発生する可能性を大幅に低減することができる。
【図面の簡単な説明】
【0010】
図1図1は、本発明の第1の実施例に係るデータ管理システムの構成を示すブロック図である。
図2図2は、本発明の第1の実施例に係る統合管理部の動作を説明するフローチャートである。
図3図3は、本発明の第1の実施例に係るヒストリサーバーの動作を説明するフローチャートである。
図4図4は、本発明の第1の実施例に係るデータ管理システムの動作例を説明する図である。
図5図5は、本発明の第1の実施例に係るデータ管理システムの動作例を説明する図である。
図6図6は、本発明の第1の実施例に係るデータ管理システムの動作例を説明する図である。
図7図7は、本発明の第1の実施例に係るデータ管理システムの動作例を説明する図である。
図8図8は、本発明の第2の実施例に係る統合管理部の動作を説明するフローチャートである。
図9図9は、本発明の第2の実施例に係るヒストリサーバーの動作を説明するフローチャートである。
図10図10は、本発明の第2の実施例に係るデータ管理システムの動作例を説明する図である。
図11図11は、本発明の第2の実施例に係るデータ管理システムの動作例を説明する図である。
図12図12は、本発明の第2の実施例に係るデータ管理システムの動作例を説明する図である。
図13図13は、本発明の第2の実施例に係るデータ管理システムの動作例を説明する図である。
図14図14は、本発明の第1、第2の実施例に係るデータ管理システムを実現するコンピュータの構成例を示すブロック図である。
【発明を実施するための形態】
【0011】
[第1の実施例]
以下、本発明の実施例について図面を参照して説明する。図1は本発明の第1の実施例に係るデータ管理システムの構成を示すブロック図である。データ管理システムは、時系列データを記憶する複数のヒストリサーバー1−A,1−B,1−Cと、複数のヒストリサーバー1−A〜1−Cを統括する統合管理部2と、クライアントの要求を受信する受信部3と、クライアントからの要求内容を含む要求メッセージをヒストリサーバー1−A〜1−Cに同報送信する送信部4と、ヒストリサーバー1−A〜1−Cからの応答データを受信する受信部5と、ヒストリサーバー1−A〜1−Cからの応答データの内容を統合した結果をクライアントに送信する送信部6とから構成される。
【0012】
受信部3,5と送信部4,6とは、API(Application Programming Interface)のエンドポイント/エントリポイントのようにソフトウェアで実装されるものであってよいし、ネットワーク端末のようにハードウェアで実装されるものであってよい。
【0013】
各ヒストリサーバー1−A〜1−Cは、それぞれ時系列データ(ヒストリデータ)を記憶するデータベース10と、時系列データに割り当てられた論理名と自装置内で管理している時系列データに割り当てられた内部アイテム名との対応表を記憶するデータベース11と、統合管理部2からの要求メッセージを受信する受信部12と、応答データを統合管理部2に送信する送信部13と、ヒストリサーバー全体を制御する制御部14とを備えている。
【0014】
受信部12と送信部13とは、API(Application Programming Interface)のエンドポイント/エントリポイントのようにソフトウェアで実装されるものであってよいし、ネットワーク端末のようにハードウェアで実装されるものであってよい。
統合管理部2は、第1の送受信処理部20と、第2の送受信処理部21とを備えている。
【0015】
図2は統合管理部2と受信部3,5と送信部4,6の動作を説明するフローチャート、図3は各ヒストリサーバー1−A〜1−Cの動作を説明するフローチャートである。図4図7はデータ管理システムの動作例を説明する図である。ただし、図4図7では、各ヒストリサーバー1−A〜1−Cの受信部12と送信部13と制御部14の記載を省略している。
本実施例では、時系列データの例として、装置X,Yの温度の時系列データをヒストリサーバー1−A〜1−Cに分散させて管理する例で説明する。
【0016】
統合管理部2は、クライアント(ユーザ)の要求を受信する受信部3(エンドポイント)と、クライアントの要求をブロードキャストまたはマルチキャストで同報する送信部4(エントリポイント)と、要求の処理結果を受信する受信部5(エンドポイント)とを管理する。
個々のヒストリサーバー1−A〜1−Cは、起動すると、送信部4からブロードキャストまたはマルチキャストで通知されるメッセージの受信待ち状態になる。
【0017】
統合管理部2の第1の送受信処理部20は、受信部3を通じて、クライアントの装置(不図示)からの要求を受信する(図2ステップS100)。
例えば図4の例では、装置X温度という論理名で特定されるアクセス対象の時系列データのうち、アクセス対象期間が2018年2月1日10時00分から2018年4月10日13時00分までのデータを求めるクライアントからの要求を受信している。
【0018】
統合管理部2の第1の送受信処理部20は、クライアントからの要求を受信すると、クライアントからの要求内容と要求に対する処理結果の通知先(受信部5)の情報とを定義した要求メッセージRMを送信部4に送信する(図2ステップS101)。そして、統合管理部2は、要求に対する処理結果が受信部5に返信されるのを待つ。
【0019】
例えば図5の例では、アクセス対象が装置X温度でアクセス対象期間が2018年2月1日10時00分から2018年4月10日13時00分まで、という要求内容と、処理結果の通知先の情報とを含む要求メッセージRMが送信部4に送信される。なお、図5の例では、受信部5をAPIのエンドポイントとし、このエンドポイントをepBとしている。
【0020】
送信部4は、統合管理部2から受信した要求メッセージRMを、ブロードキャストで全てのヒストリサーバー1−A〜1−Cに送信するか、またはヒストリサーバー1−A〜1−Cのうち特定の複数のヒストリサーバーにマルチキャストで送信する(図2ステップS102)。
【0021】
マルチキャストで送信する場合には、予め定められた複数のヒストリサーバーに要求メッセージRMを送信すればよい。あるいはクライアント側から所望のヒストリサーバーが物理的に存在している領域等を指定し、送信部4が、クライアントから指定された条件に合う複数のヒストリサーバーに要求メッセージRMを送信するようにしてもよい。
【0022】
各ヒストリサーバー1−A〜1−Cの制御部14は、自装置内の受信部12を通じて、送信部4からの要求メッセージRMを受信すると(図3ステップS200においてYES)、受信した要求メッセージRMに含まれる要求内容に相当する時系列データを自装置内で管理しているかどうかを判定する(図3ステップS201)。
【0023】
各ヒストリサーバー1−A〜1−Cは、それぞれ時系列データを記憶するデータベース10と、時系列データに割り当てられた論理名と各ヒストリサーバー1−A〜1−C内で管理している時系列データに割り当てられた内部アイテム名との対応表を記憶するデータベース11とを有している。例えば図1図5の例では、装置X温度という論理名に対応するヒストリサーバー1−A内の内部アイテム名は、TX100である。装置X温度という論理名に対応するヒストリサーバー1−B内の内部アイテム名は、X50_Tである。また、装置X温度という論理名に対応するヒストリサーバー1−C内の内部アイテム名は、X−20−Tである。
【0024】
各ヒストリサーバー1−A〜1−Cの制御部14は、要求メッセージRMの要求内容に記述されたアクセス対象(論理名)とアクセス対象期間の少なくとも一部とに相当する時系列データを、自装置内のデータベース10に格納している場合(ステップS201においてYES)、この時系列データをデータベース10から取り出す。そして、制御部14は、データベース10から取り出した時系列データと、その時系列データの期間の情報とを含む応答データRDを、要求メッセージRMに記述された通知先に送信する(図3ステップS202)。
【0025】
上記の図5の例では、要求メッセージRMは、アクセス対象が装置X温度でアクセス対象期間が2018年2月1日10時00分から2018年4月10日13時00分まで、という要求内容と、通知先の情報として受信部5(epB)の情報とを含んでいる。
このため、ヒストリサーバー1−Aの制御部14は、図6に示すように、装置X温度という論理名に対応するTX100という内部アイテム名が割り当てられた時系列データのうち、2018年2月1日10時00分から2018年3月31日23時59分までの期間の時系列データと、この期間の情報とを格納した応答データRD−Aを、通知先の受信部5に送信する。
【0026】
同様に、ヒストリサーバー1−Bの制御部14は、図6に示すように、装置X温度という論理名に対応するX50_Tという内部アイテム名が割り当てられた時系列データのうち、2018年4月1日00時00分から2018年4月10日13時00分までの期間の時系列データと、この期間の情報とを格納した応答データRD−Bを、通知先の受信部5に送信する。
【0027】
なお、要求メッセージの要求内容に相当する時系列データを自装置内に格納していないヒストリサーバーの制御部14は、データが無いことを示す応答データを通知先に返信するようにしてもよい。
【0028】
統合管理部2の第2の送受信処理部21は、受信部5を通じて応答データRDを受信して、応答データRDの内容を取り出し(図2ステップS103)、クライアントから要求された全ての期間の時系列データが揃ったかどうかを判定する(図2ステップS104)。第2の送受信処理部21は、要求された全ての期間の時系列データが揃った時点で、各ヒストリサーバーから受信した応答データRDの内容を統合した応答データGDを、送信部6を通じてクライアントの装置に送信する(図2ステップS105)。
【0029】
図7の例では、2018年2月1日10時00分から2018年4月10日13時00分までの期間の時系列データと、この期間の情報とを格納した応答データGDがクライアントに送信される。
【0030】
以上のように、本実施例では、クライアントの要求をブロードキャストまたはマルチキャストで各ヒストリサーバーに同報送信する。統合管理部2は、各ヒストリサーバーが格納しているデータに関する情報を有しておらず、各ヒストリサーバー側で要求内容に相当する時系列データを自装置内に格納しているかどうかを判定する。
【0031】
本実施例によれば、分散しているヒストリサーバーに関する情報を統合管理部2で管理する必要がなくなるので、ヒストリサーバーの追加や削除、構成変更などが行われた場合でも、統合管理部2には何の変更を加えることなく、その変更を反映した形で処理を継続することができる。
【0032】
なお、統合管理部2と個々のヒストリサーバーとの通信プロトコルの方法には他にも応用が考えられる。例えば要求メッセージRMを受信した全てのヒストリサーバーが受信確認メッセージを返すことで、その時点で初めて統合管理部2は、今回の処理を行う可能性のあるヒストリサーバーとしてどのようなヒストリサーバーがあるかを確認することができる。そして、統合管理部2は、受信確認メッセージを返した全てのヒストリサーバーから何等かの応答があった時点で、処理終了と見なすことができる。要求メッセージの要求内容に相当する時系列データを自装置内に格納していないヒストリサーバーの制御部14は、データが無いことを示す応答データを統合管理部2に返信すればよい。
【0033】
また、各ヒストリサーバー1−A〜1−Cのデータベース11で記憶している対応表に、時系列データの有効期間の情報を加えるようにしてもよい。
【0034】
[第2の実施例]
次に、本発明の第2の実施例について説明する。本実施例においても、データ管理システムの構成は第1の実施例と同様であるので、図1の符号を用いて説明する。
ヒストリデータベースの分散化を設計するシステムエンジニアにとっては次の(I)〜(III)のようなことを検証できる手段があることが望ましい。なぜならば、システム運用上問題となるヒストリサーバーの構成になっているか否かを検証し、問題がある場合にはその構成を変更するという役割を担っているからである。
(I)過去に収集したデータが漏れなく何れかのヒストリサーバーに保存されているか。
(II)運用上の適切なヒストリサーバーにデータが保存されているか。
(III)ヒストリサーバーへのデータの分散化において過度の重複や過度のフラグメンテ―ションが発生していないか。
【0035】
クライアント(システムエンジニア)は、自身が構築した分散構成が意図したとおりになっているかの評価を以下のように効率的に実施することができる。
図8は本実施例の統合管理部2と受信部3,5と送信部4,6の動作を説明するフローチャート、図9は本実施例の各ヒストリサーバー1−A〜1−Cの動作を説明するフローチャートである。図10図13はデータ管理システムの動作例を説明する図である。図4図7と同様に、図10図13では、各ヒストリサーバー1−A〜1−Cの受信部12と送信部13と制御部14の記載を省略している。
【0036】
統合管理部2の第1の送受信処理部20は、受信部3を通じて、クライアント(システムエンジニア)からの要求を受信する(図8ステップS300)。
例えば図10の例では、装置X温度という論理名が割り当てられた時系列データを管理しているヒストリサーバーの構成情報を求めるクライアントからの要求を受信している。
【0037】
統合管理部2の第1の送受信処理部20は、クライアントからの要求を受信すると、クライアントからの要求内容と要求に対する処理結果の通知先の情報とを定義した要求メッセージRMを送信部4に送信する(図8ステップS301)。
図11の例では、確認対象が装置X温度、という要求内容と、処理結果の通知先の情報とを含む要求メッセージRMが送信部4に送信される。
【0038】
送信部4は、統合管理部2から受信した要求メッセージRMを、ブロードキャストで全てのヒストリサーバー1−A〜1−Cに送信するか、またはヒストリサーバー1−A〜1−Cのうち特定の複数のヒストリサーバーにマルチキャストで送信する(図8ステップS302)。
【0039】
第1の実施例と同様に、マルチキャストで送信する場合には、予め定められた複数のヒストリサーバーに要求メッセージRMを送信すればよい。あるいは送信部4は、クライアントから指定された条件に合う複数のヒストリサーバーに要求メッセージRMを送信するようにしてもよい。
【0040】
各ヒストリサーバー1−A〜1−Cの制御部14は、自装置内の受信部12を通じて、送信部4からの要求メッセージRMを受信すると(図9ステップS400においてYES)、受信した要求メッセージRMに含まれる要求内容に相当する時系列データを自装置内で管理しているかどうかを判定する(図9ステップS401)。
【0041】
各ヒストリサーバー1−A〜1−Cの制御部14は、要求メッセージRMの要求内容に記述された確認内容(論理名)に相当する時系列データを、自装置内のデータベース10に格納している場合(ステップS401においてYES)、当該時系列データの期間の情報を含む応答データRDを、要求メッセージRMに記述された通知先に送信する(図9ステップS402)。
【0042】
また、制御部14は、要求メッセージRMの要求内容に記述された確認内容に相当する時系列データを自装置内のデータベース10に格納していない場合、当該時系列データを管理していないことを示す応答データRDを、要求メッセージRMに記述された通知先に送信する(図9ステップS403)。
【0043】
上記の図11の例では、要求メッセージRMは、確認対象が装置X温度、という要求内容と、通知先の情報として受信部5(epB)の情報とを含んでいる。
各ヒストリサーバー1−A〜1−Cの制御部14は、それぞれ装置X温度という論理名に対応するTX100,X50_T,X−20−Tという内部アイテム名が割り当てられた時系列データを管理しているので、指定された論理名の時系列データを管理していることを示すフラグと、この時系列データの期間の情報とを格納した応答データRD−A,RD−B,RD−Cを、通知先の受信部5に送信する(図12)。
【0044】
統合管理部2の第2の送受信処理部21は、受信部5を通じて応答データRDを受信して、応答データRDの内容を取り出し(図8ステップS303)、全てのヒストリサーバーからの応答があったかどうかを判定する(図8ステップS304)。第2の送受信処理部21は、全てのヒストリサーバーからの応答が揃った時点で、各ヒストリサーバーから受信した応答データRDの内容を統合した応答データGDを、送信部6を通じてクライアントの装置に送信する(図8ステップS305)。
【0045】
図13の例では、各ヒストリサーバー1−A〜1−Cの識別情報と、各ヒストリサーバー1−A〜1−Cが管理している時系列データの期間の情報とを対応付けた応答データGDがクライアントに送信される。
【0046】
本実施例によれば、期待する論理名の時系列データを管理しているヒストリサーバーの構成情報取得が可能となる。その結果、システムエンジニアとしてのクライアントは、各ヒストリサーバーに対して個別にデータ存在の有無を検証するという煩雑な作業をすることなく、応答データGDが自身の期待する情報と同じであるかを確認することのみにより、分散構成が正しいかを評価することができる。
【0047】
第1、第2の実施例では、時系列データアクセスの例で説明しているが、一般的なデータベースに本発明を適用することも可能である。一般的なデータベースにおいて、検索対象を管理するデータベースサーバーが分散して存在していても、データベースサーバーに関する情報を統合管理部2で管理する必要は無く、第1、第2の実施例と同様に分散データベースアクセスを実現することができる。
【0048】
また、第1、第2の実施例では、複数のサーバーの例として、3つのサーバーを例に挙げて説明しているが、2つのサーバーでもよいし、3つ以上のサーバーであってもよい。
【0049】
第1、第2の実施例で説明した統合管理部2と受信部3,5と送信部4,6とは、CPU(Central Processing Unit)、記憶装置及びインターフェースを備えたコンピュータと、これらのハードウェア資源を制御するプログラムによって実現することができる。このコンピュータの構成例を図14に示す。コンピュータは、CPU200と、記憶装置201と、インターフェース装置(以下、I/Fと略する)202とを備えている。I/F202には、通信回路等が接続される。このようなコンピュータにおいて、本発明のデータ管理方法を実現させるためのプログラムは記憶装置201に格納される。CPU200は、記憶装置201に格納されたプログラムに従って第1、第2の実施例で説明した処理を実行する。また、各ヒストリサーバー1−A〜1−Cについても、周知のとおりコンピュータとプログラムによって実現することができる。
【産業上の利用可能性】
【0050】
本発明は、大量のデータを扱う技術に適用することができる。
【符号の説明】
【0051】
1−A〜1−C…ヒストリサーバー、2…統合管理部、3,5,12…受信部、4,6,13…送信部、10,11…データベース、14…制御部、20…第1の送受信処理部、21…第2の送受信処理部。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14