特開 2020-204802 データ管理システムおよび方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】特開2020-204802(P2020-204802A)

(43)【公開日】2020年12月24日

(54)【発明の名称】データ管理システムおよび方法

(51)【国際特許分類】

   G06F 16/182 20190101AFI20201127BHJP

【ＦＩ】

   G06F16/182

【審査請求】未請求

【請求項の数】8

【出願形態】ＯＬ

【全頁数】14

(21)【出願番号】特願2019-110823(P2019-110823)

(22)【出願日】2019年6月14日

(71)【出願人】

【識別番号】000006666

【氏名又は名称】アズビル株式会社

(74)【代理人】

【識別番号】100098394

【弁理士】

【氏名又は名称】山川 茂樹

(74)【代理人】

【識別番号】100064621

【弁理士】

【氏名又は名称】山川 政樹

(72)【発明者】

【氏名】藤井 稔久

(57)【要約】      （修正有）

【課題】管理側の情報とサーバーとを同期して管理する必要を無くすためのデータ管理システム及びデータ管理方法を提供する。
【解決手段】データ管理システムは、データを記憶する複数のヒストリサーバー１−Ａ〜１−Ｃと、ヒストリサーバー１−Ａ〜１−Ｃを統括する統合管理部２と、を備える。統合管理部２は、クライアントからの要求内容を含む要求メッセージをヒストリサーバー１−Ａ〜１−Ｃに同報送信する第１の送受信処理部２０と、要求メッセージに対する各ヒストリサーバー１−Ａ〜１−Ｃからの応答データの内容を統合した結果をクライアントに送信する第２の送受信処理部２１と、を備える。各ヒストリサーバー１−Ａ〜１−Ｃは、データを記憶するデータベース１０と、受信した要求メッセージの要求内容に相当するデータを自装置のデータベース１０内で管理しているときに、応答データを統合管理部２に送信する制御部１４と、を備える。
【選択図】図１

【特許請求の範囲】

【請求項1】

データを記憶する複数のサーバーと、
前記複数のサーバーを統括する統合管理部とを備え、
前記統合管理部は、
クライアントからの要求内容を含む要求メッセージを前記複数のサーバーに同報送信するように構成された第１の送受信処理部と、
前記要求メッセージに対する各サーバーからの応答データの内容を統合した結果を前記クライアントに送信するように構成された第２の送受信処理部とを備え、
各サーバーは、
データを記憶するように構成されたデータベースと、
受信した要求メッセージの要求内容に相当するデータを自装置の前記データベース内で管理しているときに、応答データを前記統合管理部に送信するように構成された制御部とを備えることを特徴とするデータ管理システム。

【請求項2】

請求項１記載のデータ管理システムにおいて、
前記クライアントからの要求内容は、特定のデータを要求するものであり、
各サーバーの制御部は、前記要求メッセージの要求内容に相当するデータを自装置の前記データベース内で管理しているときに、管理しているデータとこのデータの期間の情報とを含む前記応答データを前記統合管理部に送信することを特徴とするデータ管理システム。

【請求項3】

請求項１記載のデータ管理システムにおいて、
前記クライアントからの要求内容は、特定のデータを管理しているかどうかの確認を要求するものであり、
各サーバーの制御部は、前記要求メッセージの要求内容に相当するデータを自装置の前記データベース内で管理しているときに、管理しているデータの期間の情報を含む前記応答データを前記統合管理部に送信し、
前記統合管理部の第２の送受信処理部は、前記応答データを送信したサーバーが管理しているデータの期間の情報とこのサーバーの識別情報とを対応付けた結果を前記クライアントに送信することを特徴とするデータ管理システム。

【請求項4】

請求項２または３記載のデータ管理システムにおいて、
各サーバーの制御部は、前記要求メッセージの要求内容に相当するデータを自装置の前記データベース内で管理していないときに、データが無いことを示す前記応答データを前記統合管理部に送信することを特徴とするデータ管理システム。

【請求項5】

クライアントからの要求内容を含む要求メッセージを、複数のサーバーを統括する統合管理部から前記複数のサーバーに同報送信する第１のステップと、
前記複数のサーバーのそれぞれが、受信した要求メッセージの要求内容に相当するデータを自装置のデータベース内で管理しているときに、応答データを前記統合管理部に送信する第２のステップと、
前記統合管理部が、前記要求メッセージに対する各サーバーからの応答データの内容を統合した結果を前記クライアントに送信する第３のステップとを含むことを特徴とするデータ管理方法。

【請求項6】

請求項５記載のデータ管理方法において、
前記クライアントからの要求内容は、特定のデータを要求するものであり、
前記第２のステップは、前記要求メッセージの要求内容に相当するデータを自装置のデータベース内で管理しているときに、管理しているデータとこのデータの期間の情報とを含む前記応答データを前記統合管理部に送信するステップを含むことを特徴とするデータ管理方法。

【請求項7】

請求項５記載のデータ管理方法において、
前記クライアントからの要求内容は、特定のデータを管理しているかどうかの確認を要求するものであり、
前記第２のステップは、前記要求メッセージの要求内容に相当するデータを自装置のデータベース内で管理しているときに、管理しているデータの期間の情報を含む前記応答データを前記統合管理部に送信するステップを含み、
前記第３のステップは、前記応答データを送信したサーバーが管理しているデータの期間の情報とこのサーバーの識別情報とを対応付けた結果を前記クライアントに送信するステップを含むことを特徴とするデータ管理方法。

【請求項8】

請求項６または７記載のデータ管理方法において、
前記第２のステップは、前記要求メッセージの要求内容に相当するデータを自装置のデータベース内で管理していないときに、データが無いことを示す前記応答データを前記統合管理部に送信するステップを含むことを特徴とするデータ管理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、複数のサーバーにデータを分散して管理するデータ管理システムおよび方法に関するものである。

【背景技術】

【0002】

産業オートメーションの世界では従来よりも広範囲なデータ、１つ以上の製造現場と上位の経営側のアプリケーションとの情報連携など、を利用した解析により局所最適から全体最適に向けた動きがある。ヒストリデータのアクセスに関しては長期間に渡るデータにアクセスするケースが考えられ、そのデータ量は１つのヒストリサーバーで管理する量を超える場合がある。従来のように１つのヒストリサーバーが保持できるものを超える時間幅のデータを扱う場合には、つぎに挙げるような分断された作業を人手によって連結することが求められていた。

【0003】

従来の技術では、１つのサーバーで管理できないデータを複数のサーバーに分散させて管理するようにしている（特許文献１、特許文献２参照）。
特許文献１、特許文献２に開示された技術では、分散しているサーバーに関する情報を一括して管理する必要があり、サーバーの追加や構成変更などが行われた場合には、管理側の情報も変更する必要がある。管理側の情報とサーバーとを同期して管理する必要がある為に操作ミスが発生し、正しいデータを抽出できないというミスが発生する可能性があった。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特許第４９４８２７６号広報

【特許文献2】特開２００１−２６５７６８号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

本発明は、上記課題を解決するためになされたもので、サーバーの追加や削除、構成変更などが行われた場合でも、管理側の情報とサーバーとを同期して管理する必要を無くすことができるデータ管理システムおよび方法を提供することを目的とする。

【課題を解決するための手段】

【0006】

本発明のデータ管理システムは、データを記憶する複数のサーバーと、前記複数のサーバーを統括する統合管理部とを備え、前記統合管理部は、クライアントからの要求内容を含む要求メッセージを前記複数のサーバーに同報送信するように構成された第１の送受信処理部と、前記要求メッセージに対する各サーバーからの応答データの内容を統合した結果を前記クライアントに送信するように構成された第２の送受信処理部とを備え、各サーバーは、データを記憶するように構成されたデータベースと、受信した要求メッセージの要求内容に相当するデータを自装置の前記データベース内で管理しているときに、応答データを前記統合管理部に送信するように構成された制御部とを備えることを特徴とするものである。

【0007】

また、本発明のデータ管理システムの１構成例において、前記クライアントからの要求内容は、特定のデータを要求するものであり、各サーバーの制御部は、前記要求メッセージの要求内容に相当するデータを自装置の前記データベース内で管理しているときに、管理しているデータとこのデータの期間の情報とを含む前記応答データを前記統合管理部に送信することを特徴とするものである。
また、本発明のデータ管理システムの１構成例において、前記クライアントからの要求内容は、特定のデータを管理しているかどうかの確認を要求するものであり、各サーバーの制御部は、前記要求メッセージの要求内容に相当するデータを自装置の前記データベース内で管理しているときに、管理しているデータの期間の情報を含む前記応答データを前記統合管理部に送信し、前記統合管理部の第２の送受信処理部は、前記応答データを送信したサーバーが管理しているデータの期間の情報とこのサーバーの識別情報とを対応付けた結果を前記クライアントに送信することを特徴とするものである。
また、本発明のデータ管理システムの１構成例において、各サーバーの制御部は、前記要求メッセージの要求内容に相当するデータを自装置の前記データベース内で管理していないときに、データが無いことを示す前記応答データを前記統合管理部に送信することを特徴とするものである。

【0008】

また、本発明のデータ管理方法は、クライアントからの要求内容を含む要求メッセージを、複数のサーバーを統括する統合管理部から前記複数のサーバーに同報送信する第１のステップと、前記複数のサーバーのそれぞれが、受信した要求メッセージの要求内容に相当するデータを自装置のデータベース内で管理しているときに、応答データを前記統合管理部に送信する第２のステップと、前記統合管理部が、前記要求メッセージに対する各サーバーからの応答データの内容を統合した結果を前記クライアントに送信する第３のステップとを含むことを特徴とするものである。

【発明の効果】

【0009】

本発明によれば、複数のサーバーに関する情報を統合管理部で管理する必要がなくなるので、サーバーの追加や削除、構成変更などが行われた場合でも、統合管理部には何の変更を加えることなく、その変更を反映した形で処理を継続することができる。その結果、本発明では、正しいデータを抽出できないというミスが発生する可能性を大幅に低減することができる。

【図面の簡単な説明】

【0010】

【図1】図１は、本発明の第１の実施例に係るデータ管理システムの構成を示すブロック図である。

【図2】図２は、本発明の第１の実施例に係る統合管理部の動作を説明するフローチャートである。

【図3】図３は、本発明の第１の実施例に係るヒストリサーバーの動作を説明するフローチャートである。

【図4】図４は、本発明の第１の実施例に係るデータ管理システムの動作例を説明する図である。

【図5】図５は、本発明の第１の実施例に係るデータ管理システムの動作例を説明する図である。

【図6】図６は、本発明の第１の実施例に係るデータ管理システムの動作例を説明する図である。

【図7】図７は、本発明の第１の実施例に係るデータ管理システムの動作例を説明する図である。

【図8】図８は、本発明の第２の実施例に係る統合管理部の動作を説明するフローチャートである。

【図9】図９は、本発明の第２の実施例に係るヒストリサーバーの動作を説明するフローチャートである。

【図10】図１０は、本発明の第２の実施例に係るデータ管理システムの動作例を説明する図である。

【図11】図１１は、本発明の第２の実施例に係るデータ管理システムの動作例を説明する図である。

【図12】図１２は、本発明の第２の実施例に係るデータ管理システムの動作例を説明する図である。

【図13】図１３は、本発明の第２の実施例に係るデータ管理システムの動作例を説明する図である。

【図14】図１４は、本発明の第１、第２の実施例に係るデータ管理システムを実現するコンピュータの構成例を示すブロック図である。

【発明を実施するための形態】

【0011】

［第１の実施例］
以下、本発明の実施例について図面を参照して説明する。図１は本発明の第１の実施例に係るデータ管理システムの構成を示すブロック図である。データ管理システムは、時系列データを記憶する複数のヒストリサーバー１−Ａ，１−Ｂ，１−Ｃと、複数のヒストリサーバー１−Ａ〜１−Ｃを統括する統合管理部２と、クライアントの要求を受信する受信部３と、クライアントからの要求内容を含む要求メッセージをヒストリサーバー１−Ａ〜１−Ｃに同報送信する送信部４と、ヒストリサーバー１−Ａ〜１−Ｃからの応答データを受信する受信部５と、ヒストリサーバー１−Ａ〜１−Ｃからの応答データの内容を統合した結果をクライアントに送信する送信部６とから構成される。

【0012】

受信部３，５と送信部４，６とは、ＡＰＩ（Application Programming Interface）のエンドポイント／エントリポイントのようにソフトウェアで実装されるものであってよいし、ネットワーク端末のようにハードウェアで実装されるものであってよい。

【0013】

各ヒストリサーバー１−Ａ〜１−Ｃは、それぞれ時系列データ（ヒストリデータ）を記憶するデータベース１０と、時系列データに割り当てられた論理名と自装置内で管理している時系列データに割り当てられた内部アイテム名との対応表を記憶するデータベース１１と、統合管理部２からの要求メッセージを受信する受信部１２と、応答データを統合管理部２に送信する送信部１３と、ヒストリサーバー全体を制御する制御部１４とを備えている。

【0014】

受信部１２と送信部１３とは、ＡＰＩ（Application Programming Interface）のエンドポイント／エントリポイントのようにソフトウェアで実装されるものであってよいし、ネットワーク端末のようにハードウェアで実装されるものであってよい。
統合管理部２は、第１の送受信処理部２０と、第２の送受信処理部２１とを備えている。

【0015】

図２は統合管理部２と受信部３，５と送信部４，６の動作を説明するフローチャート、図３は各ヒストリサーバー１−Ａ〜１−Ｃの動作を説明するフローチャートである。図４〜図７はデータ管理システムの動作例を説明する図である。ただし、図４〜図７では、各ヒストリサーバー１−Ａ〜１−Ｃの受信部１２と送信部１３と制御部１４の記載を省略している。
本実施例では、時系列データの例として、装置Ｘ，Ｙの温度の時系列データをヒストリサーバー１−Ａ〜１−Ｃに分散させて管理する例で説明する。

【0016】

統合管理部２は、クライアント（ユーザ）の要求を受信する受信部３（エンドポイント）と、クライアントの要求をブロードキャストまたはマルチキャストで同報する送信部４（エントリポイント）と、要求の処理結果を受信する受信部５（エンドポイント）とを管理する。
個々のヒストリサーバー１−Ａ〜１−Ｃは、起動すると、送信部４からブロードキャストまたはマルチキャストで通知されるメッセージの受信待ち状態になる。

【0017】

統合管理部２の第１の送受信処理部２０は、受信部３を通じて、クライアントの装置（不図示）からの要求を受信する（図２ステップＳ１００）。
例えば図４の例では、装置Ｘ温度という論理名で特定されるアクセス対象の時系列データのうち、アクセス対象期間が２０１８年２月１日１０時００分から２０１８年４月１０日１３時００分までのデータを求めるクライアントからの要求を受信している。

【0018】

統合管理部２の第１の送受信処理部２０は、クライアントからの要求を受信すると、クライアントからの要求内容と要求に対する処理結果の通知先（受信部５）の情報とを定義した要求メッセージＲＭを送信部４に送信する（図２ステップＳ１０１）。そして、統合管理部２は、要求に対する処理結果が受信部５に返信されるのを待つ。

【0019】

例えば図５の例では、アクセス対象が装置Ｘ温度でアクセス対象期間が２０１８年２月１日１０時００分から２０１８年４月１０日１３時００分まで、という要求内容と、処理結果の通知先の情報とを含む要求メッセージＲＭが送信部４に送信される。なお、図５の例では、受信部５をＡＰＩのエンドポイントとし、このエンドポイントをｅｐＢとしている。

【0020】

送信部４は、統合管理部２から受信した要求メッセージＲＭを、ブロードキャストで全てのヒストリサーバー１−Ａ〜１−Ｃに送信するか、またはヒストリサーバー１−Ａ〜１−Ｃのうち特定の複数のヒストリサーバーにマルチキャストで送信する（図２ステップＳ１０２）。

【0021】

マルチキャストで送信する場合には、予め定められた複数のヒストリサーバーに要求メッセージＲＭを送信すればよい。あるいはクライアント側から所望のヒストリサーバーが物理的に存在している領域等を指定し、送信部４が、クライアントから指定された条件に合う複数のヒストリサーバーに要求メッセージＲＭを送信するようにしてもよい。

【0022】

各ヒストリサーバー１−Ａ〜１−Ｃの制御部１４は、自装置内の受信部１２を通じて、送信部４からの要求メッセージＲＭを受信すると（図３ステップＳ２００においてＹＥＳ）、受信した要求メッセージＲＭに含まれる要求内容に相当する時系列データを自装置内で管理しているかどうかを判定する（図３ステップＳ２０１）。

【0023】

各ヒストリサーバー１−Ａ〜１−Ｃは、それぞれ時系列データを記憶するデータベース１０と、時系列データに割り当てられた論理名と各ヒストリサーバー１−Ａ〜１−Ｃ内で管理している時系列データに割り当てられた内部アイテム名との対応表を記憶するデータベース１１とを有している。例えば図１〜図５の例では、装置Ｘ温度という論理名に対応するヒストリサーバー１−Ａ内の内部アイテム名は、ＴＸ１００である。装置Ｘ温度という論理名に対応するヒストリサーバー１−Ｂ内の内部アイテム名は、Ｘ５０＿Ｔである。また、装置Ｘ温度という論理名に対応するヒストリサーバー１−Ｃ内の内部アイテム名は、Ｘ−２０−Ｔである。

【0024】

各ヒストリサーバー１−Ａ〜１−Ｃの制御部１４は、要求メッセージＲＭの要求内容に記述されたアクセス対象（論理名）とアクセス対象期間の少なくとも一部とに相当する時系列データを、自装置内のデータベース１０に格納している場合（ステップＳ２０１においてＹＥＳ）、この時系列データをデータベース１０から取り出す。そして、制御部１４は、データベース１０から取り出した時系列データと、その時系列データの期間の情報とを含む応答データＲＤを、要求メッセージＲＭに記述された通知先に送信する（図３ステップＳ２０２）。

【0025】

上記の図５の例では、要求メッセージＲＭは、アクセス対象が装置Ｘ温度でアクセス対象期間が２０１８年２月１日１０時００分から２０１８年４月１０日１３時００分まで、という要求内容と、通知先の情報として受信部５（ｅｐＢ）の情報とを含んでいる。
このため、ヒストリサーバー１−Ａの制御部１４は、図６に示すように、装置Ｘ温度という論理名に対応するＴＸ１００という内部アイテム名が割り当てられた時系列データのうち、２０１８年２月１日１０時００分から２０１８年３月３１日２３時５９分までの期間の時系列データと、この期間の情報とを格納した応答データＲＤ−Ａを、通知先の受信部５に送信する。

【0026】

同様に、ヒストリサーバー１−Ｂの制御部１４は、図６に示すように、装置Ｘ温度という論理名に対応するＸ５０＿Ｔという内部アイテム名が割り当てられた時系列データのうち、２０１８年４月１日００時００分から２０１８年４月１０日１３時００分までの期間の時系列データと、この期間の情報とを格納した応答データＲＤ−Ｂを、通知先の受信部５に送信する。

【0027】

なお、要求メッセージの要求内容に相当する時系列データを自装置内に格納していないヒストリサーバーの制御部１４は、データが無いことを示す応答データを通知先に返信するようにしてもよい。

【0028】

統合管理部２の第２の送受信処理部２１は、受信部５を通じて応答データＲＤを受信して、応答データＲＤの内容を取り出し（図２ステップＳ１０３）、クライアントから要求された全ての期間の時系列データが揃ったかどうかを判定する（図２ステップＳ１０４）。第２の送受信処理部２１は、要求された全ての期間の時系列データが揃った時点で、各ヒストリサーバーから受信した応答データＲＤの内容を統合した応答データＧＤを、送信部６を通じてクライアントの装置に送信する（図２ステップＳ１０５）。

【0029】

図７の例では、２０１８年２月１日１０時００分から２０１８年４月１０日１３時００分までの期間の時系列データと、この期間の情報とを格納した応答データＧＤがクライアントに送信される。

【0030】

以上のように、本実施例では、クライアントの要求をブロードキャストまたはマルチキャストで各ヒストリサーバーに同報送信する。統合管理部２は、各ヒストリサーバーが格納しているデータに関する情報を有しておらず、各ヒストリサーバー側で要求内容に相当する時系列データを自装置内に格納しているかどうかを判定する。

【0031】

本実施例によれば、分散しているヒストリサーバーに関する情報を統合管理部２で管理する必要がなくなるので、ヒストリサーバーの追加や削除、構成変更などが行われた場合でも、統合管理部２には何の変更を加えることなく、その変更を反映した形で処理を継続することができる。

【0032】

なお、統合管理部２と個々のヒストリサーバーとの通信プロトコルの方法には他にも応用が考えられる。例えば要求メッセージＲＭを受信した全てのヒストリサーバーが受信確認メッセージを返すことで、その時点で初めて統合管理部２は、今回の処理を行う可能性のあるヒストリサーバーとしてどのようなヒストリサーバーがあるかを確認することができる。そして、統合管理部２は、受信確認メッセージを返した全てのヒストリサーバーから何等かの応答があった時点で、処理終了と見なすことができる。要求メッセージの要求内容に相当する時系列データを自装置内に格納していないヒストリサーバーの制御部１４は、データが無いことを示す応答データを統合管理部２に返信すればよい。

【0033】

また、各ヒストリサーバー１−Ａ〜１−Ｃのデータベース１１で記憶している対応表に、時系列データの有効期間の情報を加えるようにしてもよい。

【0034】

［第２の実施例］
次に、本発明の第２の実施例について説明する。本実施例においても、データ管理システムの構成は第１の実施例と同様であるので、図１の符号を用いて説明する。
ヒストリデータベースの分散化を設計するシステムエンジニアにとっては次の（I）〜（III）のようなことを検証できる手段があることが望ましい。なぜならば、システム運用上問題となるヒストリサーバーの構成になっているか否かを検証し、問題がある場合にはその構成を変更するという役割を担っているからである。
（I）過去に収集したデータが漏れなく何れかのヒストリサーバーに保存されているか。
（II）運用上の適切なヒストリサーバーにデータが保存されているか。
（III）ヒストリサーバーへのデータの分散化において過度の重複や過度のフラグメンテ―ションが発生していないか。

【0035】

クライアント（システムエンジニア）は、自身が構築した分散構成が意図したとおりになっているかの評価を以下のように効率的に実施することができる。
図８は本実施例の統合管理部２と受信部３，５と送信部４，６の動作を説明するフローチャート、図９は本実施例の各ヒストリサーバー１−Ａ〜１−Ｃの動作を説明するフローチャートである。図１０〜図１３はデータ管理システムの動作例を説明する図である。図４〜図７と同様に、図１０〜図１３では、各ヒストリサーバー１−Ａ〜１−Ｃの受信部１２と送信部１３と制御部１４の記載を省略している。

【0036】

統合管理部２の第１の送受信処理部２０は、受信部３を通じて、クライアント（システムエンジニア）からの要求を受信する（図８ステップＳ３００）。
例えば図１０の例では、装置Ｘ温度という論理名が割り当てられた時系列データを管理しているヒストリサーバーの構成情報を求めるクライアントからの要求を受信している。

【0037】

統合管理部２の第１の送受信処理部２０は、クライアントからの要求を受信すると、クライアントからの要求内容と要求に対する処理結果の通知先の情報とを定義した要求メッセージＲＭを送信部４に送信する（図８ステップＳ３０１）。
図１１の例では、確認対象が装置Ｘ温度、という要求内容と、処理結果の通知先の情報とを含む要求メッセージＲＭが送信部４に送信される。

【0038】

送信部４は、統合管理部２から受信した要求メッセージＲＭを、ブロードキャストで全てのヒストリサーバー１−Ａ〜１−Ｃに送信するか、またはヒストリサーバー１−Ａ〜１−Ｃのうち特定の複数のヒストリサーバーにマルチキャストで送信する（図８ステップＳ３０２）。

【0039】

第１の実施例と同様に、マルチキャストで送信する場合には、予め定められた複数のヒストリサーバーに要求メッセージＲＭを送信すればよい。あるいは送信部４は、クライアントから指定された条件に合う複数のヒストリサーバーに要求メッセージＲＭを送信するようにしてもよい。

【0040】

各ヒストリサーバー１−Ａ〜１−Ｃの制御部１４は、自装置内の受信部１２を通じて、送信部４からの要求メッセージＲＭを受信すると（図９ステップＳ４００においてＹＥＳ）、受信した要求メッセージＲＭに含まれる要求内容に相当する時系列データを自装置内で管理しているかどうかを判定する（図９ステップＳ４０１）。

【0041】

各ヒストリサーバー１−Ａ〜１−Ｃの制御部１４は、要求メッセージＲＭの要求内容に記述された確認内容（論理名）に相当する時系列データを、自装置内のデータベース１０に格納している場合（ステップＳ４０１においてＹＥＳ）、当該時系列データの期間の情報を含む応答データＲＤを、要求メッセージＲＭに記述された通知先に送信する（図９ステップＳ４０２）。

【0042】

また、制御部１４は、要求メッセージＲＭの要求内容に記述された確認内容に相当する時系列データを自装置内のデータベース１０に格納していない場合、当該時系列データを管理していないことを示す応答データＲＤを、要求メッセージＲＭに記述された通知先に送信する（図９ステップＳ４０３）。

【0043】

上記の図１１の例では、要求メッセージＲＭは、確認対象が装置Ｘ温度、という要求内容と、通知先の情報として受信部５（ｅｐＢ）の情報とを含んでいる。
各ヒストリサーバー１−Ａ〜１−Ｃの制御部１４は、それぞれ装置Ｘ温度という論理名に対応するＴＸ１００，Ｘ５０＿Ｔ，Ｘ−２０−Ｔという内部アイテム名が割り当てられた時系列データを管理しているので、指定された論理名の時系列データを管理していることを示すフラグと、この時系列データの期間の情報とを格納した応答データＲＤ−Ａ，ＲＤ−Ｂ，ＲＤ−Ｃを、通知先の受信部５に送信する（図１２）。

【0044】

統合管理部２の第２の送受信処理部２１は、受信部５を通じて応答データＲＤを受信して、応答データＲＤの内容を取り出し（図８ステップＳ３０３）、全てのヒストリサーバーからの応答があったかどうかを判定する（図８ステップＳ３０４）。第２の送受信処理部２１は、全てのヒストリサーバーからの応答が揃った時点で、各ヒストリサーバーから受信した応答データＲＤの内容を統合した応答データＧＤを、送信部６を通じてクライアントの装置に送信する（図８ステップＳ３０５）。

【0045】

図１３の例では、各ヒストリサーバー１−Ａ〜１−Ｃの識別情報と、各ヒストリサーバー１−Ａ〜１−Ｃが管理している時系列データの期間の情報とを対応付けた応答データＧＤがクライアントに送信される。

【0046】

本実施例によれば、期待する論理名の時系列データを管理しているヒストリサーバーの構成情報取得が可能となる。その結果、システムエンジニアとしてのクライアントは、各ヒストリサーバーに対して個別にデータ存在の有無を検証するという煩雑な作業をすることなく、応答データＧＤが自身の期待する情報と同じであるかを確認することのみにより、分散構成が正しいかを評価することができる。

【0047】

第１、第２の実施例では、時系列データアクセスの例で説明しているが、一般的なデータベースに本発明を適用することも可能である。一般的なデータベースにおいて、検索対象を管理するデータベースサーバーが分散して存在していても、データベースサーバーに関する情報を統合管理部２で管理する必要は無く、第１、第２の実施例と同様に分散データベースアクセスを実現することができる。

【0048】

また、第１、第２の実施例では、複数のサーバーの例として、３つのサーバーを例に挙げて説明しているが、２つのサーバーでもよいし、３つ以上のサーバーであってもよい。

【0049】

第１、第２の実施例で説明した統合管理部２と受信部３，５と送信部４，６とは、ＣＰＵ（Central Processing Unit）、記憶装置及びインターフェースを備えたコンピュータと、これらのハードウェア資源を制御するプログラムによって実現することができる。このコンピュータの構成例を図１４に示す。コンピュータは、ＣＰＵ２００と、記憶装置２０１と、インターフェース装置（以下、Ｉ／Ｆと略する）２０２とを備えている。Ｉ／Ｆ２０２には、通信回路等が接続される。このようなコンピュータにおいて、本発明のデータ管理方法を実現させるためのプログラムは記憶装置２０１に格納される。ＣＰＵ２００は、記憶装置２０１に格納されたプログラムに従って第１、第２の実施例で説明した処理を実行する。また、各ヒストリサーバー１−Ａ〜１−Ｃについても、周知のとおりコンピュータとプログラムによって実現することができる。

【産業上の利用可能性】

【0050】

本発明は、大量のデータを扱う技術に適用することができる。

【符号の説明】

【0051】

１−Ａ〜１−Ｃ…ヒストリサーバー、２…統合管理部、３，５，１２…受信部、４，６，１３…送信部、１０，１１…データベース、１４…制御部、２０…第１の送受信処理部、２１…第２の送受信処理部。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】