特許 6262055 データ復旧システム及びデータ復旧方法

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】6262055

(24)【登録日】2017年12月22日

(45)【発行日】2018年1月17日

(54)【発明の名称】データ復旧システム及びデータ復旧方法

(51)【国際特許分類】

   G06F 12/00 20060101AFI20180104BHJP

【ＦＩ】

   G06F12/00 533A

【請求項の数】5

【全頁数】15

(21)【出願番号】特願2014-69225(P2014-69225)

(22)【出願日】2014年3月28日

(65)【公開番号】特開2015-191514(P2015-191514A)

(43)【公開日】2015年11月2日

【審査請求日】2016年11月21日

(73)【特許権者】

【識別番号】507214083

【氏名又は名称】メタウォーター株式会社

(74)【代理人】

【識別番号】100147485

【弁理士】

【氏名又は名称】杉村 憲司

(74)【代理人】

【識別番号】100150360

【弁理士】

【氏名又は名称】寺嶋 勇太

(72)【発明者】

【氏名】天津 尊仁

(72)【発明者】

【氏名】折茂 義文

【審査官】 福田 正悟

(56)【参考文献】

【文献】 特開２０００−２１４９１９（ＪＰ，Ａ）

【文献】 特開２０００−１８１７７０（ＪＰ，Ａ）

【文献】 特開平０９−０５４７１９（ＪＰ，Ａ）

【文献】 特開平０９−０８１４３１（ＪＰ，Ａ）

【文献】 特開２０００−１２２９８２（ＪＰ，Ａ）

【文献】 特開２０１１−２４８５６７（ＪＰ，Ａ）

【文献】 特開２００５−１０７８１９（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １２／００

(57)【特許請求の範囲】

【請求項1】

通信状態にあるサーバと複数のクライアントとを備え、前記サーバが外部からのデータを常時受信して該データを格納するサーバ側データベースを有し、前記複数のクライアントが前記外部からの前記データを常時受信して該データを格納するクライアント側データベースを有するデータ復旧システムであって、
前記クライアントは、前記サーバと通信不能であることを検知した場合に縮退モードに移行し、
前記複数のクライアントは自己の優先度を記憶しており、
前記サーバは、前記サーバ側データベースのデータに欠損が生じた場合、前記優先度が最高のクライアントの前記クライアント側データベースに基づき、前記サーバ側データベースにおけるデータを補完することを特徴とする、データ復旧システム。

【請求項2】

前記サーバは、前記サーバ側データベースのデータの欠損が発生した期間を判定し、前記優先度が最高のクライアントの前記クライアント側データベースに基づき、前記サーバ側データベースの前記期間におけるデータを補完することを特徴とする、請求項１に記載のデータ復旧システム。

【請求項3】

前記優先度は、前記クライアントの直近の起動時刻が早い程、高く設定されることを特徴とする、請求項１又は２に記載のデータ復旧システム。

【請求項4】

前記クライアントは、自装置が稼働停止後に再起動した場合、前記クライアント側データベースのデータに欠損が発生しているか否かを判定し、前記欠損が発生している場合、前記サーバが補完をした後の前記サーバ側データベース又は前記優先度が最高のクライアントの前記クライアント側データベースに基づき前記クライアント側データベースのデータを補完することを特徴とする、請求項１乃至３のいずれか一項に記載のデータ復旧システム。

【請求項5】

通信状態にあるサーバと複数のクライアントとを備え、前記サーバが外部からのデータを常時受信して該データを格納するサーバ側データベースを有し、前記複数のクライアントが前記外部からの前記データを常時受信して該データを格納するクライアント側データベースを有するシステムにおけるデータ復旧方法であって、
前記クライアントが、前記サーバとの通信状態を監視し、前記サーバと通信不能であることを検知した場合に縮退モードに移行するステップと、
前記複数のクライアントは自己の優先度を記憶しており、前記サーバは前記サーバ側データベースのデータに欠損が生じた場合、前記優先度が最高のクライアントの前記クライアント側データベースに基づき、前記サーバ側データベースにおけるデータを補完するステップと、
を含むことを特徴とするデータ復旧方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、サーバコンピュータ及びクライアントコンピュータを備えるデータ復旧システム及びデータ復旧方法に関するものである。

【背景技術】

【0002】

従来から、サーバコンピュータ（以下、サーバという。）とクライアントコンピュータ（以下、クライアントという。）を備えるシステムにおいて、サーバが異常等により停止した場合のシステムの復旧方法が提案されている（例えば特許文献１）。具体的には特許文献１には、サーバが異常等により稼働状態でないことをクライアントが検知した場合、クライアントがサーバプログラムを実行することによりサーバとして機能し、システムの復旧を迅速に行う技術が開示されている。

【先行技術文献】

【特許文献】

【0003】

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

【発明の概要】

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

【0004】

従来の技術は、サーバが稼働状態でないことが検知された場合に、クライアントがサーバプログラムを起動する構成を採用している。そのため、例えばサーバがデータを常時受信し蓄積するシステムにおいては、サーバの停止からクライアントにおけるサーバプログラムの起動までの間のデータを受信することができず、データ当該期間においてデータを閲覧することができなかった。

【0005】

従って、上記のような問題点に鑑みてなされた本発明の目的は、サーバが停止した場合であってもタイムラグ無くデータの閲覧をすることができるデータ復旧システム及びデータ復旧方法を提供することにある。

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

【0006】

上記課題を解決するために本発明に係るデータ復旧システムは、
通信状態にあるサーバとクライアントとを備え、前記サーバが外部からのデータを常時受信して該データを格納するサーバ側データベースを有し、前記クライアントが前記外部からの前記データを常時受信して該データを格納するクライアント側データベースを有するデータ復旧システムであって、
前記クライアントは、前記サーバと通信不能であることを検知した場合に縮退モードに移行することを特徴とする。

【0007】

また本発明に係るデータ復旧システムは、前記サーバが、自装置が稼働停止後に再起動した場合、前記サーバ側データベースのデータに欠損が発生しているか否かを判定し、欠損が発生している場合、前記クライアント側データベースに基づき前記サーバ側データベースのデータを補完することを特徴とする。

【0008】

また本発明に係るデータ復旧システムは、前記クライアントが、自装置が稼働停止後に再起動した場合、前記クライアント側データベースのデータに欠損が発生しているか否かを判定し、欠損が発生している場合、前記サーバ側データベースに基づき前記クライアント側データベースのデータを補完することを特徴とする

【0009】

また本発明に係るデータ復旧システムは、
前記データ復旧システムは前記クライアントを複数備え、
前記複数のクライアントは自己の優先度を記憶しており、
前記サーバは、自装置が稼働停止後に再起動した場合、前記サーバ側データベースのデータの欠損が発生した期間を判定し、前記優先度が最高のクライアントの前記クライアント側データベースに基づき、前記サーバ側データベースの前記期間におけるデータを補完することを特徴とする。

【0010】

また本発明に係るデータ復旧システムは、
前記優先度が、前記クライアントの直近の起動時刻が早い程、高く設定されることを特徴とする。

【0011】

また本発明に係るデータ復旧システムは、
前記クライアントが、自装置が稼働停止後に再起動した場合、前記クライアント側データベースのデータに欠損が発生しているか否かを判定し、前記欠損が発生している場合、前記サーバが補完をした後の前記サーバ側データベース又は前記優先度が最高のクライアントの前記クライアント側データベースに基づき前記クライアント側データベースのデータを補完することを特徴とする。

【0012】

また、本発明に係るデータ復旧方法は、
通信状態にあるサーバとクライアントとを備え、前記サーバが外部からのデータを常時受信して該データを格納するサーバ側データベースを有し、前記クライアントが前記外部からの前記データを常時受信して該データを格納するクライアント側データベースを有するシステムにおけるデータ復旧方法であって、
前記クライアントが、前記サーバとの通信状態を監視し、前記サーバと通信不能であることを検知した場合に縮退モードに移行するステップ
を含むことを特徴とする。

【発明の効果】

【0013】

本発明におけるデータ復旧システム及びデータ復旧方法によれば、サーバが停止した場合であってもタイムラグ無くデータの閲覧をすることができる。

【図面の簡単な説明】

【0014】

【図1】実施の形態１のデータ復旧システムのブロック図である。

【図2】実施の形態１のデータ復旧システムのサーバの動作を示すフローチャートである。

【図3】実施の形態１のデータ復旧システムのクライアントの動作を示すフローチャートである。

【図4】実施の形態２のデータ復旧システムのブロック図である。

【図5】優先度決定処理を示すフローチャートである。

【図6】実施の形態２のデータ復旧システムのサーバの動作を示すフローチャートである。

【図7】実施の形態２のデータ復旧システムのクライアントの動作を示すフローチャートである。

【図8】優先度決定処理を他の例を示すフローチャートである。

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

【0015】

以下、本発明の実施の形態について説明する。

【0016】

（実施の形態１）
図１は本発明の実施の形態１に係るデータ復旧システムのブロック図である。実施の形態１に係るデータ復旧システムは、コントローラ１と、サーバ２と、クライアント３とを備える。コントローラ１とサーバ２間、及びコントローラ１とクライアント３間は制御ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）４により接続されている。またサーバ２と、クライアント３とは、情報ＬＡＮ５により接続されている。概略として本システムにおいては、コントローラ１から監視に必要なデータをサーバ２及びクライアント３のデータベースに格納し、クライアント３により、サーバ２に格納したデータを表示可能なように構成されている。なおコントローラ１は本システムにおいて必須の構成ではなく、サーバ２及びクライアント３は、外部からデータを受信する構成であればよい。

【0017】

コントローラ１は、プラントを監視する外部の装置である。コントローラ１は、制御ＬＡＮ４によりサーバ２及びクライアント３に、プラントに係る瞬時値、等のデータを常時送信する。図１においてはコントローラ１が１台のみの例を示しているがこれに限られず、コントローラ１は２台以上であってもよい。

【0018】

サーバ２は、通信部２１と、サーバ側データベース（ＤＢ）２２と、表示部２３と、制御部２４とを備える。

【0019】

通信部２１は、制御ＬＡＮ４を介して外部であるコントローラ１と通信する。また通信部２１は、情報ＬＡＮ５を介して、クライアント３と通信、すなわちデータの送受信をする。通信部２１は、サーバ２に割り当てられた制御ＬＡＮ４用のＩＰアドレスと、情報ＬＡＮ５のＩＰアドレスとを用いてこれらの通信を行う。

【0020】

サーバ側データベース２２には、制御ＬＡＮ４を介してコントローラ１から通信部２１が常時受信しているデータが格納（蓄積）される。

【0021】

表示部２３は、液晶ディスプレイ、有機ＥＬディスプレイ等により構成され、サーバ側データベース２２のデータを抽出して、ユーザの指定する形式で表示する。ユーザの指定する形式は、瞬時データ、トレンドデータ、履歴データ、帳票データ等を加工したトレンド画面、履歴画面、帳票画面等の表示画面である。すなわちユーザは表示部２３により、コントローラ１からのデータを適宜閲覧することができる。

【0022】

制御部２４は、サーバ２に係る各種制御を行う。例えば制御部２４は、制御ＬＡＮ４を介して通信部２１がコントローラ１から受信した瞬時値等のデータを、サーバ側データベース２２に格納する。また制御部２４は、クライアント３にサーバ側データベース２２に格納されているデータを通信部２１により送信する。

【0023】

また制御部２４は、自装置の状況を監視し、自装置が稼働停止状態から再起動したか否かを判定する。サーバ２の稼働停止は、通信部２１に異常が生じた場合、又はサーバ２自体に異常が生じた場合に起きる。また制御部２４は、クライアント３との通信を監視し、通信状態又は通信不能であるかを検知する。ここで通信状態とは、サーバ２又はクライアント３が、サーバ２とクライアント３とつながる情報ＬＡＮ５を介して、それぞれが相手を検知できる状態である。また通信不能とは、サーバ２又はクライアント３が、サーバ２とクライアント３とつながる情報ＬＡＮ５を介して、相手を検知できない状態である。通信不能の原因として考えられるのは、サーバ２がクライアント３を検知できなくなる場合（原因１）と、クライアント３がサーバ２を検知できなくなる場合（原因２）の２つがある。原因１の場合、さらにサーバ２とクライアント３とつながる情報ＬＡＮ５に異常が生じたことに起因する場合（原因１−１）と、クライアント３が、クライアント３の各部設備に故障が生じたこと（例えば通信部３１に異常が生じた）、クライアントの制御ＬＡＮ４に異常が生じたこと（データを取れなくなる）、クライアント３の保守などによってクライアント３の稼動が停止したことに起因する場合（原因１−２）とがある。原因１−１の場合、データの欠損は生じない。一方、原因１−２の場合、クライアント側データベース３２にデータ欠損が生じる。

【0024】

また原因２の場合、さらにサーバ２とクライアント３とつながる情報ＬＡＮ５に異常が生じたことに起因する場合（原因２−１）と、サーバ２が、サーバ２の各部設備に故障（例えば通信部２１に異常が生じた）生じたこと、サーバ２の制御ＬＡＮ４に異常が生じたこと（データを取れなくなる）、サーバ２の保守などによってサーバ２の稼動が停止したことに起因する場合（原因２−２）とがある。原因２−１の場合、データの欠損は生じない。原因２−２の場合、サーバ側データベース２２にデータ欠損が生じる。

【0025】

制御部２４は、自装置が稼働停止から再起動した場合、サーバ側データベース２２にデータの欠損があるか否かを判定する。制御部２４は、データの欠損がある場合、後述するクライアント３のクライアント側データベース３２に基づき、サーバ側データベース２２のデータを補完する。この場合、制御部２４は、サーバ側データベース２２において欠損の生じている期間を特定し、当該期間におけるデータをクライアント側データベース３２から取得して、当該期間のデータの補完をする。データの欠損は、例えばサーバ２の通信部２１において異常が生じコントローラ１との通信ができていなかった場合に生じる。あるいは、サーバ２が異常停止していた場合にも、生じる。このような場合において、制御部２４は、稼働停止から再起動した場合、サーバ側データベース２２にデータの欠損があることを検知し、クライアント側データベース３２に基づき、サーバ側データベース２２のデータを補完する。

【0026】

クライアント３は、通信部３１と、クライアント側データベース（ＤＢ）３２と、表示部３３と、制御部３４とを備える。

【0027】

通信部３１は、制御ＬＡＮ４を介して外部であるコントローラ１と通信する。また通信部３１は、情報ＬＡＮ５を介して、サーバ２と通信、すなわちサーバ２とデータの送受信をする。通信部３１は、クライアント３に割り当てられた制御ＬＡＮ４用のＩＰアドレスと、情報ＬＡＮ５のＩＰアドレスとを用いてこれらの通信を行う。

【0028】

クライアント側データベース３２には、制御ＬＡＮ４を介してコントローラ１から通信部３１が常時受信しているデータが格納（蓄積）される。なおクライアント側データベース３２に格納されるデータは、所定期間内（以下、データ保持期間という。）におけるデータであり、当該期間よりも前のデータは削除される。したがってクライアント側データベース３２に格納されているデータは、サーバ側データベース２２に格納されるデータよりもデータ量が少ない。

【0029】

表示部３３は、液晶ディスプレイ、有機ＥＬディスプレイ等により構成される。表示部３３には、サーバ２から受信するサーバ側データベース２２のデータを抽出して、ユーザの指定する形式で表示する。ユーザの指定する形式は、瞬時データ、トレンドデータ、履歴データ、帳票データ等を加工したトレンド画面、履歴画面、帳票画面等の表示画面である。すなわちユーザは表示部３３により、コントローラ１からのデータを適宜閲覧することができる。

【0030】

制御部３４は、クライアント３に係る各種制御を行う。例えば制御部３４は、制御ＬＡＮ４を介して通信部３１がコントローラ１から受信した瞬時値等のデータを、クライアント側データベース３２に格納する。また制御部３４は、通信部３１により、サーバ２からサーバ側データベース２２に格納されているデータを受信する。また制御部３４は、当該データを表示部３３に表示させる。

【0031】

さらに制御部３４は、サーバ２との情報ＬＡＮ５による通信の状況を監視し、通信状態であるか、通信不能であるかを判定する。

【0032】

制御部３４は、サーバ２との通信状況に応じて、クライアント３を縮退モードに移行させる。ここで縮退モードとは、サーバ２が通信不能であるとクライアント３の制御部３４が判定した場合に、クライアント３が移行する動作モードである。縮退モードにおいては、クライアント３がユーザ指示に基づきコントローラからのデータを参照する際、サーバ側データベース２２の代わりに、自己のクライアント側データベース３２を参照する。このようにサーバ２と通信不能である場合、クライアント３は縮退モードに移行するため、ユーザはサーバ２と通信ができない状況であっても、コントローラ１からクライアント３が受信している瞬時値等のデータを参照することができる。なお通常の動作モード（以下、通常モードという。）においては、上述したようにクライアント３がユーザ指示に基づきコントローラからのデータを参照する際、サーバ側データベース２２を参照する。

【0033】

なおクライアント３がサーバ２と通信不能になる場合は、例えばサーバ２の稼働が停止している場合、サーバ２とクライアント３との間の情報ＬＡＮ５に係る通信経路に異常がある場合が考えられる。

【0034】

また制御部３４は、サーバ２と通信可能に復帰した場合、縮退モードから通常モードに移行する。

【0035】

また制御部３４は、自装置の状況を監視し、自装置が稼働停止状態から再起動したか否かを判定する。クライアント３の稼働停止は、通信部３１に異常が生じた場合、又はクライアント３自体に異常が生じた場合に起きる。制御部３４は、自装置が稼働停止から再起動した場合、データ保持期間内のクライアント側データベース３２のデータに欠損があるか否かを判定する。制御部３４は、データの欠損がある場合、サーバ２のサーバ側データベース２２に基づき、クライアント側データベース３２のデータを補完する。例えば制御部３４は、クライアント側データベース３２において欠損の生じている期間を特定し、当該期間におけるデータを、サーバ側データベース２２から取得して、当該期間のデータの補完をする。データの欠損は、例えばクライアント３の通信部３１において異常が生じコントローラ１との通信ができていなかった場合に生じる。あるいは、クライアント３が異常停止していた場合にも、生じる。このような場合において、制御部３４は、サーバ２と通信不能から通信状態に復帰した場合、クライアント側データベース３２にデータの欠損があることを検知し、サーバ側データベース２２に基づき、クライアント側データベース３２のデータを補完する。

【0036】

次に、実施の形態１に係るデータ復旧システムについて、図２及び図３に示すフローチャートによりサーバ２及びクライアント３の各動作を説明する。

【0037】

図２は、サーバ２の動作を示すフローチャートである。まずサーバ２の通信部２１は、制御ＬＡＮ４を介してコントローラ１からのデータを受信する（ステップＳ１１０）。なお通信部２１はコントローラ１からのデータを常時受信している。制御部２４は、制御ＬＡＮ４を介して通信部２１がコントローラ１から受信した瞬時値等のデータを、サーバ側データベース２２に格納する。

【0038】

続いてサーバ２が稼働停止し（ステップＳ１２０）、その後再起動した場合（ステップＳ１３０）、制御部２４は、サーバ側データベース２２にデータの欠損があるか否かを判定する（ステップＳ１４０）。制御部２４は、データの欠損がある場合（ステップＳ１４０：はい）、クライアント３のクライアント側データベース３２に基づき、サーバ側データベース２２のデータを補完する（ステップＳ１５０）。例えば制御部２４は、サーバ側データベース２２において欠損の生じている期間を特定し、当該期間におけるデータを、クライアント側データベース３２から取得して、データの補完をする。一方、データの欠損が無い場合（ステップＳ１４０：いいえ）、処理を完了する。

【0039】

図３は、クライアント３の動作を示すフローチャートである。はじめにクライアント３の通信部３１は、制御ＬＡＮ４を介してコントローラ１からのデータを受信する（ステップＳ２１０）。なお通信部３１はコントローラ１からのデータを常時受信している。制御部３４は、制御ＬＡＮ４を介して通信部３１がコントローラ１から受信した瞬時値等のデータを、クライアント側データベース３２に格納する。

【0040】

続いてクライアント３がサーバ２と通信不能になった場合（ステップＳ２２０）、制御部３４は、クライアント３を通常モードから縮退モードに移行させる（ステップＳ２３０）。その後、クライアント３がサーバ２と通信可能になった場合、制御部３４は、クライアント３を縮退モードから通常モードに移行させる（ステップＳ２４０）。

【0041】

続いて制御部３４は、クライアント３が稼働停止し（ステップＳ２５０）、再起動した場合（ステップＳ２６０）、クライアント側データベース３２にデータ保持期間内におけるデータの欠損があるか否かを判定する（ステップＳ２７０）。制御部３４は、データの欠損がある場合、サーバ２のサーバ側データベース２２に基づき、クライアント側データベース３２のデータを補完する（ステップＳ２８０）。例えば制御部３４は、クライアント側データベース３２において欠損の生じている期間を特定し、当該期間におけるデータを、サーバ側データベース２２から取得して、データの補完をする。一方、データの欠損が無い場合（ステップＳ２７０：いいえ）、処理を完了する。

【0042】

図１に戻り、実施の形態１のデータ復旧システムにおけるデータ補完の概念を示す。図１において、矢印６は、クライアント３からサーバ２へデータの補完をしていることを示している。例えばサーバ２が異常等により停止して通信不能になり、その後サーバ２が起動して通信状態になった場合、矢印６に示すようにクライアント３のクライアント側データベース３２から、サーバ２にデータを送信し、サーバ側データベース２２のデータを補完する。

【0043】

このように本発明によれば、サーバ２及びクライアント３が常時コントローラ１からのデータを常時受信し、それぞれサーバ側データベース２２及びクライアント側データベース３２に格納している。そしてクライアント３がサーバ２と通信できない場合、クライアントが縮退モードに移行することで、ユーザはサーバ２と通信ができない状況であっても、コントローラ１からクライアント３が受信している瞬時値等のデータを参照することができる。さらにサーバ２及びクライアント３が、異常停止、通信障害等により通信不能な状態から通信可能な状態に復帰した場合に、各データベースの欠損の有無を判定し、欠損がある場合に別のデータベースに基づきデータを補完するようにしている。このため、データを常時受信し蓄積するようなシステムにおいても、データの完全性及び信頼性の低下を防止することができる。

【0044】

（実施の形態２）
以下に、本発明の実施の形態２について説明をする。図４は本発明の実施の形態２のデータ復旧システムの構成を示すブロック図である。実施の形態１と同一の構成については同一の符号を付し、説明は省略する。実施の形態２に係るデータ復旧システムは、実施の形態１にかかる構成と比較して、クライアントが複数存在する点が相違する。本実施の形態では、クライアント３ａ、３ｂの２台のクライアントを備える例を説明するがこれに限られず、クライアント端末は３台以上であってもよい。クライアント３ａとクライアント３ｂとの構成は同一であるため、以下クライアント３ａについてその構成を説明し、クライアント３ｂの構成については説明を省略する。

【0045】

クライアント３ａは、通信部３１ａと、クライアント側データベース３２ａと、表示部３３ａと、制御部３４ａと、優先度記憶部３５ａとを備える。通信部３１ａ、クライアント側データベース３２ａ、表示部３３ａは、それぞれ実施の形態１の通信部３１、クライアント側データベース３２、表示部３３と同一の構成である。

【0046】

制御部３４ａは、実施の形態１の制御部３４に対応する。制御部３４ａは、実施の形態１の制御部３４と同様の制御に加えて、以下に示す制御を行う。

【0047】

制御部３４ａは、自己の端末の優先度（優先順位）を設定する処理（以下、優先度設定処理という）を行う。優先度とは、サーバ２、又はクライアント（３ａ又は３ｂ）が自己のデータベースの補完を行う場合に、補完元となるデータベースの順位を示す値である。サーバ２、は、優先度が最高のクライアント（３ａまたは３ｂ）のクライアント側データベースに基づき、自己のデータベースを補完する。また、優先度が最高でないクライアント（３ａ又は３ｂ）は、優先度が最高のクライアント（３ａまたは３ｂ）のクライアント側データベースに基づき自己のデータベースを補完する。本実施の形態の場合、クライアントが２台であるため、優先度は１または２である。この場合優先度「１」が最高であり、優先度「２」は、優先度「１」より低い。なおクライアントがＮ台存在する場合には、優先度は１からＮまでとなる。ここでＮは２以上の整数である。当該優先度は、優先度記憶部３５ａに格納される。

【0048】

制御部３４ａは優先度設定処理を、クライアントの端末起動時に行う。以下、制御部３４ａが行う優先度設定処理について説明する。図５は、優先度設定処理を示すフローチャートである。まず制御部３４は、自己の直近の起動時刻を取得する（ステップＳ３１０）。次に制御部３４ａは、他の全てのクライアント（本実施の形態では、クライアント３ｂ）の直近の起動時刻を通信部３１ａにより、情報ＬＡＮ５を介して取得する（ステップＳ３２０）。続いて制御部３４ａは、自己の起動時刻と、他の全てのクライアントの起動時刻とを比較し、起動時刻順に優先度を設定する（ステップＳ３３０）。すなわち制御部３４ａは、直近の起動時刻が早い程、優先度を高く設定する。例えば制御部３４ａは、クライアント３ａの直近の起動時刻が、２０１４年３月１日１１時００分であり、クライアント３ｂの直近の起動時刻が２０１４年３月１日１０時００分である場合、クライアント３ａの優先度を２と設定する。またクライアント３ｂの優先度を１と設定する。制御部３４ａは、設定した優先度を、優先度記憶部３５ａに記憶する（ステップＳ３４０）。

【0049】

制御部３４ａは、上述の優先度設定処理を、制御ＬＡＮ４、情報ＬＡＮ５等に異常が生じる等、状況が変化した場合に行う。具体的には制御部３４ａは、サーバ２と通信不能から通信可能に復帰した場合や、他のクライアント（クライアント３ｂ）と通信不能から通信可能に復帰した場合（或いは通信可能から通信不能に変化した場合）に、優先度設定処理を行う。このような場合は、サーバ２又は他のクライアントが稼働停止や再起動等している可能性があり、直近の起動時刻が変わるため、制御部３４ａは、優先度設定処理をそれに応じて行う。

【0050】

そして実施の形態２に係るサーバ２の制御部２４は、サーバ側データベース２２の補完の際に、クライアントの優先度を用いる。すなわち制御部２４は、クライアント３と通信不能から通信状態に復帰した場合、サーバ側データベース２２にデータの欠損があるか否かを判定する。制御部２４は、データの欠損がある場合、優先度が最高のクライアント（例えばクライアント３ｂ）のクライアント側データベース３２ｂに基づき、サーバ側データベース２２のデータを補完する。サーバ２は、クライアント３ａ、３ｂの優先度を、各クライアントから自動的に通知を受けて把握してもよい。或いはサーバ２がデータを補完する際に、各クライアント（３ａ、３ｂ）に優先度の送信を要求して、各クライアントの優先度を把握してもよい。

【0051】

同様にクライアント３ａの制御部３４ａは、クライアント側データベース３２ａのデータに欠損があるか否かを判定する。制御部３４ａは、データの欠損がある場合、サーバ２のサーバ側データベース２２に基づき、クライアント側データベース３２ａのデータを補完する。或いは制御部３４ａは、データの欠損がある場合、優先度が最高のクライアント（例えばクライアント３ｂ）のクライアント側データベース３２ｂに基づき、クライアント側データベース３２ａのデータを補完するようにしてもよい。

【0052】

次に、実施の形態２に係るデータ復旧システムについて、図６、７に示すフローチャートによりサーバ２及びクライアント３ａの各動作を説明する。実施の形態１と同一の動作については同一の符号を付し、説明は省略する。また、以下の動作ではクライアント３ｂの優先度が最高（優先度が１）であるものとして説明をする。

【0053】

図６は、サーバ２の動作を示すフローチャートである。ステップＳ１１０からステップＳ１４０までは実施の形態１と同一である。サーバ２の制御部２４は、データの欠損がある場合（ステップＳ１４０：はい）、優先度が最高のクライアント３ｂのクライアント側データベース３２ｂに基づき、サーバ側データベース２２のデータを補完する（ステップＳ１５１）。

【0054】

図７は、クライアント３ａの動作を示すフローチャートである。ステップＳ２１０からステップＳ２４０までは実施の形態１と同一である。クライアント３ａの制御部３４ａは、ステップＳ２４０に続いて、優先度設定処理を行う（ステップＳ２４１）。その後、制御部３４ａは、クライアント側データベース３２ａにデータの欠損がある場合、サーバ２のサーバ側データベース２２に基づき、データの補完をする。あるいは制御部３４ａは、クライアント３ｂのクライアント側データベース３２ｂに基づき、クライアント側データベース３２のデータを補完する（ステップＳ２８１）。

【0055】

図４に戻り、実施の形態２のデータ復旧システムにおけるデータ補完の概念を示す。図４において、矢印７は、クライアント３ｂからサーバ２へデータの補完をしていることを示している。例えばサーバ２が異常等により停止して通信不能になり、その後サーバ２が起動して通信状態になった場合、矢印７に示すようにクライアント３のクライアント側データベース３２から、サーバ２にデータを送信し、サーバ側データベース２２のデータを補完する。また図４において、矢印８は、クライアント３ｂからクライアント３ａへデータを送信して補完をしていることを示している。例えばクライアント３ａが異常等により停止して通信不能になり、その後クライアント３ａが起動して通信状態になった場合、矢印８に示すようにクライアント３ｂのクライアント側データベース３２ｂから、クライアント３ａにデータを送信し、クライアント側データベース３２ａのデータを補完する。

【0056】

このように実施の形態２にかかるデータ復旧システムによれば、サーバ２及びクライアント３ａ、３ｂが常時コントローラ１からのデータを常時受信し、それぞれサーバ側データベース２２及びクライアント側データベース３２ａ、３２ｂに格納している。そしてサーバ２及びクライアント３ａ、３ｂが、異常停止、通信障害等により通信不能な状態から、通常の通信可能な状態に復帰した場合に、各データベースの欠損の有無を判定し、欠損がある場合に優先度に応じて別のデータベースに基づきデータを補完するようにしている。このため、データを常時受信し蓄積するようなシステムにおいても、データの完全性及び信頼性の低下を防止することができる。また優先度は、起動時刻に応じて定めており、起動時刻が最も早いクライアントの優先度を高く設定しているため、最も完全性の高いデータを保持している可能性の高いデータベースからデータの補完ができ、データの完全性及び信頼性の低下を防止することができる。

【0057】

ここで、サーバ、クライアントとして機能させるために、コンピュータを好適に用いることができ、そのようなコンピュータは、サーバ、クライアントの各機能を実現する処理内容を記述したプログラムを、当該コンピュータの記憶部に格納しておき、当該コンピュータの中央演算処理装置（ＣＰＵ）によってこのプログラムを読み出して実行させることで実現することができる。

【0058】

本発明を諸図面や実施例に基づき説明してきたが、当業者であれば本開示に基づき種々の変形や修正を行うことが容易であることに注意されたい。従って、これらの変形や修正は本発明の範囲に含まれることに留意されたい。例えば、各手段、各ステップ等に含まれる機能等は論理的に矛盾しないように再配置可能であり、複数の手段やステップ等を１つに組み合わせたり、或いは分割したりすることが可能である。

【0059】

例えば実施の形態１及び２において、コントローラ１とサーバ２と、クライアント３間は制御ＬＡＮ４により通信し、サーバ２とクライアント３間は、情報ＬＡＮ５により通信するものとしたがこれに限られない。例えば制御ＬＡＮ４及び情報ＬＡＮ５とを１つのＬＡＮにより構成するようにしてもよい。この場合、サーバ２及びクライアント３は、ネットワーク用のアドレス（ＩＰアドレス）を１つのみ割り当てればよい。

【0060】

また実施の形態２における優先度設定処理は上述したものに限られない。図８は優先度設定処理の他の例を示すフローチャートである。図８に示す優先度設定処理では、クライアント３ａの制御部３４ａは、他の全てのクライアントの通信状態に係る情報（通信状態情報）を取得する（ステップＳ３２１）。そして制御部３４ａは、起動時刻に加えて、当該通信状態情報に応じて優先度を決定する（ステップＳ３３１）。通信状態情報は、制御ＬＡＮ４及び情報ＬＡＮ５に係る通信の状態を表す情報（各通信経路に係る通信可能か通信不能かを示す情報）を含む。例えばあるクライアントにおいて制御ＬＡＮ４が通信不能である場合、当該クライアントはコントローラ１からのデータを受信できない。このような場合、当該クライアントの優先度を、起動時刻にかかわらず下げるようにしてもよい。このような優先度設定処理を行うことにより、コントローラ１からのデータに欠損が生じている可能性の高いクライアントの優先を下げ、データに欠損が生じていない可能性の高いクライアントの優先度を上げることになるため、よりデータの完全性及び信頼性の低下を防止することができる。

【0061】

なお図７において、クライアント３ａは優先度設定処理をステップＳ２４０の後のみに行っているがこれに限られず、ステップＳ２２０の後にも行ってもよい。またクライアント３ａは、優先度設定処理を所定時間間隔毎に定期的に行ってもよい。

【0062】

以下、各クライアントの起動時刻及び通信状態情報に応じて優先度を設定（変更）する例について説明する。まずクライアントＡ〜Ｃにそれぞれ起動順に優先度１〜３が設定されているとする。クライアントＡが異常停止した場合、クライアントＢ及びクライアントＣは、クライアントＡと通信できないため、自己の直近の起動時刻がクライアントの起動時刻より早いと判断し、自己の優先度をそれぞれ１及び２に上げるように変更する。一方クライアントＡは、再起動されたとき、自己の起動時刻が一番遅いと判断し、自己の優先度を３に下げる。

【0063】

次に優先度が最高のクライアントの制御ＬＡＮ４に異常が生じた場合の優先度の設定について説明する。まずクライアントＡ〜Ｃにそれぞれ起動順に優先度１〜３が設定されているとする。クライアントＡの制御ＬＡＮ４に異常が生じた場合、クライアントＡは稼動停止される。クライアントＢ及びクライアントＣは、クライアントＡと通信できないため、自己の直近の起動時刻がクライアントの起動時刻より早いと判断し、自己の優先度をそれぞれ１及び２にあげるように変更する。一方クライアントＡは、再起動されたとき、自己の起動時刻が一番遅いと判断し、自己の優先度を３に下げる。

【0064】

次にあるクライアントの情報ＬＡＮ５に異常が生じた場合の優先度の設定について説明する。まずクライアントＡ〜Ｃにそれぞれ起動順に優先度１〜３が設定されているとする。クライアントＣの情報ＬＡＮ５に異常が生じた場合、クライアントＣは、クライアントＡ及びクライアントＢと通信不能となるため、自己の直近の起動時刻が最も早いと判定し、優先度を１に上げ、かつ縮退モードに移行する。クライアントＣの情報ＬＡＮが正常に復帰した場合において、自己の直近起動時刻を、クライアントＡ及びＢの直近の起動時刻と比較し、自己の優先度を変更する。このように構成しているため優先度が最高のクライアントが複数存在することを防ぐことができる。

【0065】

次に、全てのクライアントの情報ＬＡＮ５に異常が生じた場合の優先度の設定について説明する。当該異常は、例えばクライアントＡ〜Ｃを接続するスイッチングハブ等に異常が生じた場合に発生する。まずクライアントＡ〜Ｃにそれぞれ起動順に優先度１〜３が設定されているとする。クライアントＡ〜Ｃの情報ＬＡＮ５に異常が生じた場合、クライアントＡ〜Ｃは、それぞれ他のクライアントと通信不能となるため、それぞれ自己の直近の起動時刻が最も早いと判定し、それぞれ自己の優先度を１に上げ、縮退モードに移行する。その後クライアントＡ〜Ｃの情報ＬＡＮが正常に復帰した場合において、それぞれ自分の直近起動時刻を、他のクライアントの直近の起動時刻と比較し、自己の優先度を変更する。このように構成しているため優先度が最高のクライアントが複数存在することを防ぐことができる。

【0066】

なお実施の形態１及び２のシステムにおいてサーバ２は表示部２３を備えるとしたがこれに限られず、サーバ２には表示部２３を設けなくてもよい。この場合、コントローラ１からのデータは、クライアント３（３ａ、３ｂ）のみで閲覧することができる。

【0067】

なお実施の形態１及び２のシステムにおいて、クライアント３（３ａ、３ｂ）の制御部３４は、サーバ２との通信状況に応じてクライアント３（３ａ、３ｂ）を縮退モードに移行するとしたが、当該縮退モードへの移行を行わなくてもよい。すなわち制御部３４は、図３及び図７におけるステップＳ２３０及びステップＳ２４０の縮退モードへの移行及び通常モードへの復帰を行わなくてもよい。この場合、クライアント３は、ステップＳ２３０及びステップＳ２４０以外の処理は行う。すなわちサーバ２及びクライアント３はそれぞれ、自装置が稼働停止から再起動した場合において、サーバ側データベース２２及びクライアント側データベース３２の補完の処理を行う。従来は、サーバがデータを常時受信し蓄積するシステムにおいては、サーバの停止からクライアントにおけるサーバプログラムの起動までの間のデータを受信することができず、データの欠損が生じてしまっていた。一方で本願発明の実施の形態１及び２では、当該データの欠損が生じないことを目的として、サーバ２及びクライアント３（３ａ、３ｂ）がそれぞれ、自装置が稼働停止から再起動した場合において、サーバ側データベース２２及びクライアント側データベース３２の補完の処理を行う。そのため、サーバの停止からクライアントにおけるサーバプログラムの起動までの間のデータも受信及び記憶でき、データの完全性及び信頼性の低下を防止することができる。

【符号の説明】

【0068】

１ コントローラ
２ サーバ
３、３ａ、３ｂ クライアント
４ 制御ＬＡＮ
５ 情報ＬＡＮ
２１ 通信部
２２ サーバ側データベース
２３ 表示部
２４ 制御部
３１、３１ａ、３１ｂ 通信部
３２、３２ａ、３２ｂ クライアント側データベース
３３、３３ａ、３３ｂ 表示部
３４、３４ａ、３４ｂ 制御部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】