JP2014229176A - 情報管理装置及び情報管理方法 - Google Patents

Abstract

【課題】 複数の機器についての稼働情報を、各機器について規定されている管理内容に従って、効率的に管理可能とする。
【解決手段】 複数の機器の稼動状態を示す情報である稼働情報を各機器から収集して保持し、稼働情報を活用したサービスを提供する情報利用装置によって参照させる情報管理装置であって、機器に関して提供されるサービスレベルについて規定された契約に関する情報を保持し、機器についての契約情報を取得し、その契約情報に基づき、各機器について保持されている前記稼動情報の管理方式を規定する情報である管理ポリシー情報を、少なくとも各稼働情報の格納場所に関する情報である格納場所情報を含めて生成する。
【選択図】 図２

Description

本発明は、情報管理装置及び情報管理方法に関する。

建設機器等の保守サービスとして、機器に多数のセンサを取り付け、そのセンサが計測した機器の稼動情報をリアルタイムで監視することで機器の異常、もしくは異常の予兆を検出し、部品交換などの対策を迅速に実施することが提案されている。さらに、機器から収集して蓄積した稼動情報を、機器の異常発生の傾向や異常発生時の原因究明、もしくは異常は発生していないものの、定常状態とは逸脱した値を計測した場合にその後引き起こされる異常の推定、などへ活用することが提案されている。ただし、保守の対象となる機器が多い場合、蓄積する稼働情報は大量になり、それに伴う管理コストも増大する。

このような問題に対し、情報の業務的価値が時間的に変化することに着目したＩＬＭ（Information Lifecycle Management）と呼ばれる情報ライフサイクル管理の適用が提案されている。ＩＬＭでは、予め指定されたポリシーに従ってその時々の業務的価値に応じた情報管理方法を適用することで、情報の管理コストを削減することが可能となる。例えば特許文献１に記載されている技術では、法定文書の保管・保存に要する運用コストを押さえるため、法定要件（公訴期限・保存年限など）、情報ライフサイクルマネジメント要件（データの重要度、アクセス頻度など）の両方の要件に基づき、適切な情報管理方法の適用を支援する構成が提案されている。

特開２００７−１９３４０８号公報

前記の建設機器等の保守サービスでは、サービスの提供者（保守サービス提供者）と被提供者（機器の使用者）との間で締結した契約に規定されているサービスレベルを満たすサービスを提供する必要がある。サービスレベルは個々の契約ごとに異なるため、サービスを提供するために必要な情報のライフサイクル管理方式もそのサービスレベルに応じて個々に適切な方式を選択する必要がある。また、このサービスレベルは契約の更新の際に変更となる可能性があり、情報ライフサイクル方式もその変更に対応する必要がある。特許文献１に記載の技術では法定要件を想定しているため、前記の保守サービスのように同種の情報でも契約内容の違いによって異なるポリシーを適用する必要があることを考慮していない。また、サービス提供者と被提供者の間の契約に基づいたポリシーの定義に特許文献１の技術を適用した場合、運用者が個々の契約ごとにそれぞれポリシーを設定する必要がある。また、契約の内容が変更となった場合にも、運用者は変更内容に合せて該当するポリシーを検索して修正する必要がある。

そこで、本発明の一の目的は、情報サービスに関する契約内容に基づいて、その契約に規定されている内容に合致したデータ管理に関するポリシーを自動生成することができる情報管理装置及び情報管理方法を提供することにある。

また、特許文献１に記載の技術では、機器の異常やその予兆に該当する稼動情報を重要度の高いデータとして定義した場合、異常・予兆に該当するセンサ値の稼動情報のみが高速・高信頼な管理方式で扱われるが、定常状態の稼動情報であってもその異常や予兆の原因と考えられる稼動情報や、異常・予兆に該当する期間の他のセンサの稼動情報は重要度が低いデータとして低速・低信頼な管理方式で扱われる可能性がある。この場合、保守サービス提供者は異常の原因究明を行う際に稼動情報の検索で時間がかかり、異常に対する迅速な対策が行えず、契約で約束したサービスレベルを満たせなくなる可能性がある。

そこで、本発明の他の目的は、情報サービス利用者の業務遂行に役立つ情報を幅広く収集して利用可能とする情報管理装置及び情報管理方法を提供することにある。なお、本発明の更なる目的は、後述する実施形態の記載から明らかになるであろう。

上記の、及び他の目的を達成するために、本発明の一態様は、複数の機器の稼動状態を示す情報である稼働情報を前記機器から収集して保持し、前記稼働情報を活用したサービスを提供する情報利用装置によって参照させる情報管理装置であって、前記機器に関して前記情報利用装置によって提供されるサービスレベルについて規定された契約に関する情報である契約情報を保持する契約情報保持部と、各前記機器について保持されている前記契約情報を前記契約情報保持部から取得し、前記契約情報に基づき、各前記機器について保持されている前記稼動情報の管理方式を規定する情報である管理ポリシー情報を、少なくとも各前記稼働情報の格納場所に関する情報である格納場所情報を含めて生成する管理ポリシー生成部とを有することを特徴とする。
その他、本願が開示する課題、およびその解決手段は、発明を実施するための形態の欄、および図面により明らかになる。

本発明によれば、複数の機器についての稼働情報を、各機器について規定されている管理内容に従って、効率的に管理可能となる。

本発明の実施形態による情報管理システム１に関する概要図である。 本発明の実施形態による情報管理装置であるサーバ１０の全体構成を示すブロック図である。 本発明の実施形態に関する履歴データベース（以下「ＤＢ」）１４１が保持する履歴テーブル１４１ａの一例である。 本発明の実施形態に関する機器構成マスタ１８が保持する属性テーブル１８ａの一例である。 本発明の実施形態に関する機器構成マスタ１８が保持する構成関係テーブル１８ｂの一例である。 本発明の実施形態に関する契約ＤＢ１９が保持する契約テーブル１９ａの一例である。 本発明の実施形態に関するポリシー作成処理のフローチャート例である。 本発明の実施形態に関する契約ＤＢ１９が保持する契約種別マスタ１９ｂの一例である。 本発明の実施形態に関するポリシーＤＢ１７が保持する契約ポリシーテーブル１７ａの一例である。 本発明の実施形態に関するポリシーＤＢ１７が保持する異常値ポリシーテーブル１７ｂの一例である。 本発明の実施形態に関するデータ移行処理のフローチャート例である。 本発明の実施形態に関する履歴テーブル１４１ａが保持する異常値ポリシーに該当する履歴の一例である。 本発明の実施形態に関する関連度ＤＢ１６が保持する関連度テーブル１６ａの一例である。 本発明の実施形態に関する期間の設定例に関する模式図である。 本発明の実施形態に関する履歴管理処理のフローチャート例である。 本発明の実施形態に関する参照履歴ＤＢ１５が保持する参照回数テーブル１５ａの一例である。 本発明の実施形態に関する関連度管理処理のフローチャート例である。 本発明の実施形態に関する関連度ＤＢ１６が保持する関連度更新マスタ１６ｂの一例である。 本発明の実施形態に関する機器構成管理プログラムの処理のフローチャートである。 本発明の実施形態に関する関連度ＤＢ１６が保持する関連度定義マスタ１６ｃの一例である。 本発明の実施形態に関する情報管理システム１が適用される機器構成例の模式図である。

次に、本発明の一実施形態に係る情報管理システムについて、添付図面を参照しながら説明する。図１は、本発明の一実施形態に係る情報管理システム１を鉱山などで使用される建設機器やマイニング機器（以下、「機器」と記す）の情報管理に適用した場合の概要図を表す。以下、この図を用いて本発明の実施形態が想定する機器保守業務について説明する。

保守事業者はユーザとの間で機器に関する保守サービス契約を締結しており、多数の機器２０からの情報をサーバ１０によって管理している。サーバ１０は、機器２０の管理や保守に必要な情報を保持し、実際に機器２０の保守を行う事業者やそのアプリケーション４０に対して保持する情報を提供する。機器２０の稼動時、機器２０を構成する各部品に取り付けられたセンサ２２一つ乃至複数から定期的に収集したセンサ値が公衆回線などM2M(Machine to Machine)等の通信ネットワーク５０を介してサーバ１０に収集される。収集したセンサ値はサーバ１０の履歴ＤＢ１４１に蓄積される。ただし、サーバ１０側のデータ監視機能は収集されたセンサ値の値をチェックし、予めセンサ２２ごとに定義されたセンサ値の閾値や範囲から逸脱しているセンサ値（以下、「逸脱センサ値」と記す）があった場合は、それを検出し機器保守事業者に通知する。例えば、ある機器２０のエンジンの出力が定常状態の範囲よりも低下していることを示すセンサ値、などである（図１中の(1)）。

機器保守事業者は、(1)のデータ監視機能からの通知を受け、通知された逸脱センサ値をサーバ１０の対策レコメンド機能に入力する。対策レコメンド機能は、過去の逸脱センサ値と、その問題に対し実施された対策の組合せのパターン（教師データ）を保持する。入力に類似する“パターン”を保持する場合、そのパターンを一つないし複数、入力した機器保守事業者に提示する。機器保守事業者はパターンが一つ提示されたら、そのパターンに記載されている対策を実行、もしくは現場の作業者に指示する。例えば、(1)のエンジン出力のセンサ値と類似しているパターンの対策としてエンジンオイルの交換が提示される、などがある（図１中の(2)）。

(2)にて該当するパターンがないと判定した場合は、(1)の逸脱センサ値と類似したセンサ値が過去になかったか、を機器保守事業者がサーバ１０の履歴ＤＢ１４１から検索する。該当するセンサ値があれば、(1)の逸脱した期間と同じ期間の他のセンサ２２のセンサ値や逸脱した期間の前後の期間のセンサ値と、該当する過去の他センサ２２や前後のセンサ値とを比較することで、(1)の逸脱センサ値が発生した原因の究明や、(1)の逸脱センサ値の原因によってもたらされる異常などの推定を行い、それに伴い必要な対策の検討を行う。これは対策レコメンド機能に追加する新規のパターンの生成もかねる（図中の(3)）。

また、(2)にてサーバ１０の対策レコメンド機能が複数のパターンを提示した場合、機器保守事業者はその中からどのパターンの対策をとるのが最適かを検討する。そのために、(3)と同様に、履歴ＤＢ１４１から過去のセンサ値を検索して(1)の逸脱した期間と同じ期間の他のセンサ２２のセンサ値や逸脱した期間の前後の期間のセンサ値と、該当する過去の他センサ２２や前後のセンサ値とを比較し、最も状況が類似するパターンを選択し、その対策を実行する（図１中の(4)）。

以上、(1)〜(4)に例示した機器保守業務において、本実施形態の情報管理システム１により提供される履歴ＤＢ１４１のデータライフサイクル管理に適用した場合のブロック図を図２に示す。本図中には、理解を容易にするために、情報管理システム１のデータライフサイクル管理に関する構成のみを記している。

図２中のサーバ１０（情報管理装置）は前記のとおり、機器２０の管理・保守に必要な情報を保持し、保守用のアプリケーション４０にそれらの情報を提供するコンピュータである。サーバ１０は、管理対象の機器２０に取り付けられたセンサ２２からセンサ値を収集する。サーバ１０は一つ乃至複数の機器２０から定期的に送信されるセンサ値を受信し自身のデータベース(ＤＢ)に保持する。また、サーバ１０はアプリケーション４０に対しＤＢに保持するセンサ値を提供する。

アプリケーション４０とサーバ１０も通信ネットワーク５０を介して接続され、アプリケーション４０は定期的に、もしくは適宜のタイミングでサーバ１０に検索条件を含むセンサ値の履歴取得のリクエストを送信する。サーバ１０はそのアプリケーション４０に該当するセンサ値の履歴をレスポンスとして返す。アプリケーション４０は、例えば、サーバ１０の機能を利用する保守事業者の事業所等に設置されるコンピュータに実装される。

また、サーバ１０は運用アプリケーション３０とも接続される。運用アプリケーション３０はサーバ１０の運用者がサーバ１０に保持されているＤＢのデータ移行などの運用を行うためのアプリケーションである。運用者はデータ移行のコマンドを運用アプリケーション３０が提供するインタフェースを通して行い、運用アプリケーション３０はその内容をサーバ１０に通知することで運用を行う。運用アプリケーション３０は、例えば、サーバ１０の運用管理者の事業所等に設置されるコンピュータ（情報利用装置）に実装される。

なお、サーバ１０は後述するように、演算処理を行う際に用いられる記憶手段としてのメモリ１１と、前記演算処理を行う演算処理装置とを少なくとも備えるコンピュータとして構成される。なお、メモリ１１は、RAM（Random Access Memory）などにより構成される。演算処理は、CPU（Central Processing Unit）１２によって構成される演算処理装置が、メモリ１１上のプログラムを実行することで実現される。また、サーバ１０を構成するコンピュータは、通信のためのネットワークインタフェースである通信部１３を備える。通信ネットワーク５０を通じたデータ通信は、適宜の通信プロトコルによって実行させるようにすることができる。

データ収集対象となる機器２０には、CPU、メモリ、その他ネットワークインタフェースがコントローラ２１として組み込まれている。コントローラ２１は、機器２０内の各部品に取り付けられたセンサ２２から定期的にセンサ値を収集し、収集した情報を定期的にサーバ１０に送信する。情報の送信間隔は通信ネットワーク５０の利用可能帯域にもよるが、機器２０の異常やその予兆をすぐに保守事業者に通知できるよう、少なくとも数分に1回、帯域に余裕があれば数十秒に１回程度を想定する。

次にサーバ１０の詳細な構成例について、図１を用いて説明する。サーバ１０の通信部１３は、機器２０がサーバ１０へ送信したセンサ値の受信を行う。また、アプリケーション４０からのセンサ値の履歴の参照要求の受付と該当するセンサ値の返信を行う。通信部１３が送信する情報はCPU１２から渡され、通信部１３が受信した情報はCPU１２に送信される。

CPU１２は通信部１３から受信した情報をメモリ１１に展開し、メモリ１１上の各種プログラムを実行して情報の加工やメモリ１１内のキャッシュ、ＤＢ、ファイルへの登録・更新を行う。また、同様にメモリ１１上の各種プログラムを実行してメモリ１１内のキャッシュ、ＤＢ、ファイルから情報を検索・取得し、メモリ１１に展開して必要に応じて加工し、通信部１３への送信等を行う。CPU１２が実行するプログラムとしては、機器２０とそれを構成する部品、取り付けられたセンサ２２、およびその機器２０の使用者や使用場所の登録・更新・削除・検索を行う機器構成管理プログラム１１ｄ、機器２０から収集したセンサ値の履歴の登録・検索を行う履歴管理プログラム１１ｂ、関連度情報更新部を含み後述する関連度を管理する関連度管理プログラム１１ｃ、稼働情報管理部としてセンサ値の履歴のデータ移行を実行するデータ移行プログラム１１ａ、本システム１による情報管理のポリシーを生成するためのポリシー生成プログラム１１ｅ（管理ポリシー生成部）などが含まれる。これらのプログラムは通常ファイルとして図示しないハードディスク等のストレージに格納されており、必要に応じてメモリ１１上に展開される。各プログラムの動作の詳細については後述する。

次に、サーバ１０が保持する情報について説明する。サーバ１０が保持する情報は、例えば以下に示すものを含む。

履歴管理庫１４は機器２０の各センサ２２から収集したセンサ値（稼働情報）の履歴を保持する。履歴管理庫１４は、稼働情報履歴保持部である履歴ＤＢ１４１とテープ１４２にて構成される。履歴ＤＢ１４１は履歴テーブル１４１ａを保持する。機器２０から送信されたセンサ値はまず履歴ＤＢ１４１に登録される。その後、定期的にもしくはデータ移行のコマンドが運用アプリケーション３から実行されたタイミングで、履歴ＤＢ１４１の一部のセンサ値の履歴についてはそのまま履歴ＤＢ１４１に残されるが、それ以外のセンサ値の履歴もしくは全ての履歴がテープ１４２に移行されるか、もしくは削除される。テープ１４２移行の際には必要に応じて履歴のデータ圧縮も行われる。テープ１４２に保持されるセンサ値の履歴はランダムアクセスができないため、その情報を参照しようとすると読み込み、解凍、メモリ１１へのロードが必要になる。また、テープ１４２に保持する履歴は大量となるため、全ての履歴のメモリ１１へのロードは困難である。これらの理由により、アプリケーション４０からの参照要求に対するレスポンスには時間がかかるため、瞬時のレスポンスが要求されないデータがテープ１４２に格納される。

履歴テーブル１４１ａの例を図３に記す。履歴テーブル１４１ａは一つのレコードが一つのセンサ値を表し、センサ２２を一意に特定するＩＤ１４１ａ０、センシングした日時を表すTIMESTAMP１４１ａ１、センシングした値をあらわすVALUE１４１ａ２、センサ値が履歴テーブル１４１aに登録された日時を表すADD_DATE１４１ａ３、などのデータを保持する。一つのセンサ２２で複数の種類の値をセンシングできる場合は、その種類ごとにＩＤを割り振る。

機器構成マスタ１８（機器構成情報保持部）はサーバ１０が管理する機器２０の情報、および機器２０間、機器２０とセンサ２２間、および機器２０の使用者や使用される場所（鉱山など）に関する情報を保持するＤＢである。機器構成マスタ１８は属性テーブル１８ａと構成関係テーブル１８ｂを保持する。属性テーブル１８ａは機器２０やセンサ２２、機器２０を構成する部品、使用者、場所それぞれに関する属性情報を保持するテーブルである。構成関係テーブル１８ｂは機器２０やセンサ２２、機器２０を構成する部品、使用者、場所の間の関係に関する情報を保持するテーブルである。

属性テーブル１８ａの例を図４に記す。属性テーブル１８ａは一つのレコードが1つの機器２０、部品、センサ２２、使用者、場所を表し、これらを一意に特定するID１８ａ０とその種類をあらわすID_TYPE１８ａ１、などを保持する。例えばID１８ａ０として「S001O」が割り当てられているセンサ２２はモータの出力をセンシングするセンサである。同様に、ID１８ａ０が「P004M」である機器はモータであり、「D003E」は掘削機、「U002」は機器２０の使用者、「L001」は機器２０が使用される場所をそれぞれ表す。

構成関係テーブル１８ｂの例を図５に記す。構成関係テーブル１８ｂは一つのレコードが機器２０、部品、センサ２２、使用者、場所の中の１対１の関係を表し、関係間の一つ目のＩＤを表すID(1)１８ｂ０、二つ目のＩＤを表すID(2)１８ｂ１、それらの関係が開始された日時を表すSTART_DATE１８ｂ２、関係が終了した日時を表すEND_DATE１８ｂ３、などを保持する。END_DATE１８ｂ３に値がないレコードはその関係が継続していることを表す。例えば、図中の１番目のレコードは場所L001で使用者U002が作業を行っていることを表す。２番目のレコードは使用者U002が掘削機D003Eを使用していることを表す。３番目のレコードは掘削機D003Eを構成する部品としてモータP004Mがあることを意味する。４番目のレコードはモータP004Mに取り付けられたセンサ２２としてモータの出力を計測するセンサS001Oがあることを意味する。また、機器２０間の構成だけでなく、例えば同じ部品や同じ掘削機の型式である場合にもこの構成関係テーブル１８ｂにてそれらの間の関係を保持する。例えば、掘削機D003EとD005Eが同じ型式の場合には、それらを構成関係として登録する。構成関係テーブル１８ｂにて保持する構成関係の模式図を図１９に示す。この図が示すように、機器２０が使用される場所（LOCATION X）−機器２０の使用者（個人）（USER Z）−機器２０（EXCAVATOR a）−部品（PART 01）−センサ２２（SENSOR A）の関係は包含するもの・されるものといった関係や、保守事業者と使用者との間の保守契約に基づいた契約番号（CONTRACT C1）−契約対象の機器２０（EXCAVATOR a）といった関係がある。これらの関係は上下関係であるため、包含するものをID(1)１８ｂ０に、包含されるものをID(2)１８ｂ１に保持する。場所と使用者の関係であれば、場所をID(1)１８ｂ０に、使用者をID(2)１８ｂ１に保持する。同一型式の場合など、上下関係がない場合はどちらをID(1)１８ｂ０／ID(2)１８ｂ１に保持しても構わない。これらの情報は、保守事業者がアプリケーション４０を通して機器２０を製造した際にＢＯＭ（Bill of Materials）などの情報に基づいて機器２０、部品、センサ２２の情報を登録する。また、同様に保守事業者が機器２０を販売もしくはレンタル・リースする際に、機器２０が使用される場所やそれを使用する使用者の情報として登録、もしくは機器の使用者と保守事業者が保守契約を締結した際に登録する。

契約ＤＢ１９（契約情報保持部）は、保守事業者と機器使用者との間で締結された保守契約の内容を保持するＤＢであり、契約テーブル１９ａを保持する。図６に契約テーブル１９ａの例を記す。契約テーブル１９ａは一つのレコードが一つの契約を表し、契約を識別する契約番号C_ID１９ａ０、契約を締結した機器使用者を識別するUSER_ID１９ａ１、契約種別C_TYPE１９ａ２、契約開始日時を表すSTART_DATE１９ａ３、契約終了日時を表すEND_DATE１９ａ４、などを保持する。契約種別とは契約の種類を表す。本実施例では、機器の稼動を保守事業者が保証するか／しないか、また、保証する場合には機器のダウンタイムが発生し連続稼動が達成できなかった場合、違約金を機器使用者に支払う等のペナルティが契約上存在するか／しないか、の計３種類を想定する。契約が延長された場合は、END_DATE１９ａ４を更新するのではなく新規レコードを追加する。関連度ＤＢ１６、参照履歴ＤＢ１５、ポリシーＤＢ１７および他のテーブルについては後述するサーバ１０の各プログラムの動作の説明の中で説明する。

＜実施例１＞
次に、サーバ１０の各プログラムの動作について説明する。最初にポリシー生成プログラム１１eの動作について説明する。このプログラムは、サーバ１０の運用者が運用アプリケーション３０を通して、もしくは保守事業者がアプリケーション４０を通して契約テーブル１９ａにレコードを追加した際に、または構成関係テーブル１８ｂに契約番号がID(1)１８ｂ０として指定されたレコードが追加された場合に実行され、その内容に応じたデータ移行に関する「ポリシー」をポリシーＤＢ１７に追加する。図７はポリシー生成プログラム１１ｅによる処理のフローチャート例を示したものである。以下、この図に沿って説明する。なお、説明の便宜上、プログラムを動作主体として記述するが、この動作は、実際には該当プログラムを読み込んだCPU１２が実行する。

最初に、契約テーブル１９ａへの新規レコード追加時の処理について説明する。ポリシー生成プログラム１１ｅは、契約テーブル１９ａを定期的に監視するなどして契約テーブル１９ａへの新規レコードの追加を検出し、その内容を取得する（Ｓ１０）。

ポリシー生成プログラム１１ｅは、Ｓ１０で取得したレコードから、契約種別C_TYPE１９ａ２の値を抽出する（Ｓ２０）。

ポリシー生成プログラム１１ｅは、Ｓ２０で抽出した値を基に、契約ＤＢ１９の契約種別マスタ１９ｂを参照し、該当する契約種別のレコードを取得する。契約種別マスタ１９ｂの例を図８に記す。契約種別マスタ１９ｂは一つのレコードが一つの契約種別とその契約種別に対応するために必要な履歴の保管場所を表しており、契約種別C_TYPE１９ｂ０、対象とする履歴とその保管場所を表すDATA_LOCATION１９ｂ１、などを保持する。例えば契約種別C_TYPE１９ｂ０が「稼働率保証あり・ペナルティあり」の場合、該当する履歴は履歴ＤＢ１４１とテープ１４２の両方に全履歴（図中では「ALL」と表現）を保持する。これは、機器の異常もしくはその予兆が発生した際に迅速に対応して機器のダウンタイムをできるだけ短くできるようにするために履歴ＤＢ１４１に保持するとともに、機器の稼動状態の証跡としてテープ１４２に保持しておくためである。契約種別C_TYPE１９ｂ０が「稼働率保証あり・ペナルティなし」の場合は、機器２０の稼動状態の証跡として全データをテープ１４２に保持しておくのは前記と同様であるが、機器２０のダウンによるペナルティがないため異常やその予兆の履歴である逸脱センサ値のみ（図中では「ABNORMAL」と表現）は履歴ＤＢ１４１に保持しておくことで、ペナルティがある契約対象を優先してその機器２０の履歴の検索時間の短縮を図る。契約種別C_TYPE１９ｂ０が「稼働率保証なし」の場合は、全ての履歴をテープ１４２に保持しておき、履歴ＤＢ１４１には履歴を保持しないようにすることで、前記の稼働率保証ありの契約対象を優先してその機器２０の履歴の検索時間の短縮を図る（Ｓ３０）。なお、このような契約種別C_TYPE１９ｂ０に対応するデータ保存の態様は一例であり、設定される契約内容に応じて契約種別C_TYPE１９ｂ０に対するデータ保存態様を適宜変更することができる。

次に、ポリシー生成プログラム１１ｅは、S01で取得したレコードから契約番号C_ID１９ａ０を取得し、その契約番号C_IDが構成関係テーブル１８ｂのID(1)１８ｂ０に一致し、END_DATE１８ｂ３がNULL、もしくは処理実行日時がSTART_DATE１８ｂ２とEND_DATE１８ｂ３の間となるレコードを構成関係テーブル１８ｂから取得する（Ｓ４０）。Ｓ４０の処理にて一つでも該当するレコードがある場合はＳ６０の処理へ、該当するレコードがない場合はＳ７０の処理へ移る（Ｓ５０）。

Ｓ４０にて該当するレコードが構成関係テーブル１８ｂにあると判定した場合、ポリシー生成プログラム１１ｅは、そのレコードから関係を辿ってセンサ２２のＩＤを取得する。具体的には、Ｓ４０で取得したレコードのID(1)１８ｂ０に契約番号、ID(2)１８ｂ１に機器のＩＤが指定されているため、次にID(1)１８ｂ０にその機器のＩＤ、ID(2)１８ｂ１に部品のＩＤが指定されているレコードを検索する。該当するレコードが存在すると判定した場合、同様に次にID(1)１８ｂ０にその部品のＩＤ、ID(2)１８ｂ１にセンサ２２のＩＤが指定されているレコードを検索する。なお、各レコードのＩＤが機器２０か、部品か、センサ２２かは、属性テーブル１８ａのID_TYPE１８ａ１の値の先頭を参照し、それぞれDEVICE、PART、SENSORであることを確認する。これらの処理を繰り返し、Ｓ４０にて取得したレコードから辿れる全てのセンサ２２のＩＤを取得する（Ｓ６０）。

Ｓ８０では、ポリシーＤＢ１７の契約ポリシーテーブル１７ａにＳ６０以前に取得した内容をもとにレコードを追加する。ここでいうポリシーとは、センサ値の履歴の保持場所を定義したものであり、契約ポリシーでは契約テーブル１９ａの内容に基づいて生成されたポリシーのことである。契約ポリシーテーブル１７ａの例を図９に記す。契約ポリシーテーブル１７ａは一つのレコードが一組の対象履歴の条件とその保管場所を表しており、契約ポリシーを識別するためのＩＤであるP_ID１７ａ０、対応する契約番号を表すC_ID１７ａ１、対象履歴の条件を表すTARGET１７ａ２、履歴の保管場所を表すDATA_LOCATION１７ａ３、保管期限の日時を表すVALID_DATE１７ａ４、などを保持する。一つの契約に対して複数の契約ポリシーが対応する場合もある。例えば、図９の例では契約番号CONT001に対応する契約ポリシーとしてP_ID１７ａ０がP101とP102の二つが存在する。P101は履歴ＤＢ１４１に保持する履歴に関する内容であり、TARGET１７ａ２には対象履歴の条件として履歴のＩＤが複数指定されている。P102はテープ１４２に保持する履歴に関する内容であり、TARGET１７ａ２にはP101と同じＩＤが指定されている。対象履歴が異常やその予兆を表す履歴の場合、TARGET１７ａ２に「ABNORMAL」と指定するが、異常値の具体的な定義はポリシーＤＢ１７の異常値ポリシーテーブル１７ｂにて保持する。図１０に異常値ポリシーテーブル１７ｂの例を記す。異常値ポリシーテーブル１７ｂは一つのレコードが一つの異常値の定義（異常値ポリシー）を表し、異常値ポリシーを識別するA_ID１７ｂ０、異常値ポリシーが対象とする履歴の条件を表すTARGET１７ｂ１、値の境界条件を表すRANGE１７ｂ２、などを保持する。例えばA_ID１７ｂ０がAP101では、ID_TYPE１８ａ１がSENSOR_OUTPUTに該当する全てのセンサ２２のＩＤに対して、値が２０未満の場合は、その値は異常値であることを示している。契約ポリシーテーブル１７ａではTARGET１７ａ２にて「ABNORMAL」が指定されている場合、異常値ポリシーテーブル１７ｂに定義されている全ての異常値ポリシーが適用対象となる。異常値ポリシーは保守事業者がアプリケーション４０を通して登録する。

Ｓ８０の処理の説明に戻る。ポリシー生成プログラム１１ｅは、識別ＩＤP_ID１７ａ０を採番し、S01にて検出した契約レコードの契約番号C_IDを契約ポリシーテーブル１７ａのC_ID１７ａ０に、Ｓ６０にてセンサ２２のＩＤを取得した場合はその内容をTARGET１７ａ２に、Ｓ３０で取得したDATA_LOCATION１９ｂ１の内容を契約ポリシーテーブル１７ａのTARGET１７ａ２およびDATA_LOCATION１７ａ３に指定する。VALID_DATE１７ａ４にはS01にて検出したレコードのEND_DATE１９ａ４を指定する。

Ｓ５０にて該当するレコードがないと判定した場合は、ポリシー生成プログラム１１ｅは、アプリケーション４０を通じて新規の契約があるかを問い合わせ、あった場合にはＳ６０以降のポリシー追加登録処理を実行する。Ｓ７０で新規の契約がないと判定した場合には、ポリシー生成プログラム１１ｅは処理を終了する（S09）。なお、Ｓ５０において該当するレコードがないと判定された場合には、そのまま本処理フローを終了させてもよい。以上が、契約テーブル１９ａへの新規レコード追加時のポリシー生成プログラム１１eの処理の流れである。

同様に、ポリシー生成プログラム１１ｅは、構成関係テーブル１８ｂへの新規レコード追加を監視し、契約テーブル１９ａに登録されている契約番号C_ID１９ａ０をID(1)１８ｂ０とするレコードの追加を検出した場合には、前記Ｓ６０で実施した関係するセンサ２２のＩＤの検索を行い、検索した結果を契約ポリシーテーブル１７ａのTARGET１７ａ２に追記する。構成関係テーブル１８ｂのEND_DATE１８ｂ３に日時が登録されている場合は、その日時のタイミングで契約ポリシーテーブル１７ａのTARGET１７ａ２から該当するＩＤを削除する。

以上の処理により、サーバ１０の履歴ＤＢ１４１やテープ１４２に蓄積される大量の機器２０のセンサ値の履歴の移行や削除を定めたポリシーに関し、保守事業者とその事業者と保守契約を結んだ機器使用者との間の契約内容に基づいて、その契約が表す保証範囲やサービスレベルに合ったポリシーを自動生成することが可能になる。これにより、保守事業者やサーバ１０の運用者が契約内容の登録や変更があった場合に都度その内容を確認してポリシーを定義し登録する必要をなくすことができる。

次にデータ移行プログラム１１ａの動作について説明する。データ移行プログラム１１ａは、サーバ１０の運用者が運用アプリケーション３０を通じて履歴ＤＢ１４１の使用可能容量、および使用済み容量を把握し、残りの容量が逼迫するなど履歴ＤＢ１４１のセンサ値の履歴をテープ１４２に移行する必要がある場合、同様にテープ１４２の容量が逼迫する場合などに実行される。また、データ移行プログラム１１ａは、例えば一週間や一ヶ月に一度、定期的に、自動的に実行される場合も考えられる。図１１はデータ移行プログラム１１ａのコマンドが実行された際の処理のフローチャート例を示したものである。以下、この図に沿って説明する。

まずコマンドが実行されたら、データ移行プログラム１１ａはポリシーＤＢ１７の契約ポリシーテーブル１７ａ、及び異常値ポリシーテーブル１７ｂの内容を読み込む。ここで、異常値ポリシーテーブル１７ｂについて追加で説明する。図１０の２行目の例が示すレコードでは、TARGET１７ｂ１に異常値ポリシーのＩＤである「A_ID=AP101」が指定されている。このレコードは、異常値ポリシーに関連付けて登録されるもので、「A_ID=AP101」の異常値ポリシーにて定義された履歴との「関連度」が、RANGE１７ｂ２で指定した値の条件を満たす履歴（図の例では関連度が０．５以上）についてはそれも異常値ポリシーに該当した履歴と同様の処理（この例では履歴ＤＢ１４１に保持する）を行うことを意味する。関連度は異常値ポリシーにて定義した逸脱センサ値が検出され、図１にて前記した機器保守業務の(3)もしくは(4)にて検出した逸脱センサ値と類似した過去のセンサ値の履歴を保守事業者が検索する際に、他センサ２２や前後のセンサ値として検索される可能性を意味する。関連度は、「センサ間の関連」と「期間の関連」のどちらか、もしくはこれら二つによって定義される。センサ間の関連は、例えば、異常値ポリシーにて定義した逸脱センサ値（SENSOR_OUTPUTのセンサ値が２０未満）と関連度が高いセンサ値として、「エンジンオイルの量」を表すセンサ値があるとする。この場合、エンジンオイルの量を表すセンサ値について異常値ポリシーに定義されていなくとも、それらの間の関連度が高い場合には、エンジンオイルの量を表すセンサ値についても履歴ＤＢ１４１に保持することとする。これにより、保守作業者が、エンジン出力が２０未満となる異常を検出してその原因究明を行う場合、エンジン出力が２０未満となった過去のセンサ値と合せてそのときのエンジンオイルの量も履歴ＤＢ１４１に保持されているため、これらの履歴を参照して過去と異常検出時との比較を行うことができる。また、期間の関連については、例えば同様に、SENSOR_OUTPUTのセンサ値が２０未満の異常の予兆として、２０以上の値ではあるが、ある特定の値の推移パターンをとる可能性がある場合、２０未満の値をセンシングした期間だけでなく、それ以前の（正常値の）期間についても履歴ＤＢ１４１に保持しておくことで、保守事業者は異常検出時の比較を行うことができる。関連度については、より詳しく後述する。

データ移行プログラム１１ａは前記の契約ポリシーテーブル１７ａ、異常値ポリシーテーブル１７ｂの読み込みのほか、サーバ１０の内部ファイルに保持されている移行実行ログを読み込む。このログには以前実行された履歴ＤＢ１４１の移行に関する情報が保持されており、この中から前回実行時の日時を取得し保持しておく(Ｓ１０１)。

データ移行プログラム１１ａは、Ｓ１０１で読みこんだ内容から、異常値ポリシーを抽出する（Ｓ１０２）。以下、Ｓ１０４からＳ１１９までの処理をＳ１０２にて抽出した異常値ポリシーに対して実行する（Ｓ１０３）。

処理対象の異常値ポリシーについて、そのポリシーに該当する履歴を履歴ＤＢ１４１の履歴テーブル１４１ａから検索する。例えば、ID_TYPE１８ａ１がSENSOR_OUTPUTに該当するＩＤのVALUEが２０未満の履歴を検索する。なお、検索対象は、ADD_DATE１４１ａ３がＳ１０１で取得した前回移行実行時の日時以降の履歴である。該当する履歴をＩＤと期間の組み合わせで分類する、つまり該当した複数の履歴のＩＤが同一で、TIMESTAMP１４１ａ１が連続している場合はそれらを一つのＩＤ・期間に分類する。例えば、図１２の履歴テーブル１４１ａの例では、異常値ポリシーに該当する履歴情報は２番目、３番目、５番目、８番目のレコードであるが、２番目と３番目のレコードは一つの期間とする。従って、この例では異常値ポリシーに該当するＩＤと期間の組合せは３つとなる（Ｓ１０４）。

Ｓ１０４にて該当する履歴が履歴テーブル１４１ａに存在する場合はＳ１０６の処理へ、ない場合はＳ１１９の処理へ移り、次の異常値ポリシーを処理対象とした処理を行う（Ｓ１０５）。
ポリシーに該当する履歴が存在する場合、データ移行プログラム１１ａは、処理対象の異常値ポリシーのA_IDがTARGET１７ｂ１に「A_ID=」と指定されているポリシーをＳ１０１にて読み込んだ異常値ポリシーテーブル１７ｂの内容から抽出する。以下、このポリシーのことを「関連ポリシー」と記す（Ｓ１０６）。Ｓ１０６にて該当する関連ポリシーが一つでもある場合はＳ１０８の処理へ移る。ない場合はＳ１１９の処理へ移り、次の異常値ポリシーを処理対象とした処理を行う（Ｓ１０７）。以下、Ｓ１０９からＳ１１７までの処理をＳ１０６にて抽出した関連ポリシーに対して実行する（Ｓ１０８）。

次に、データ移行プログラム１１ａは、処理対象の関連ポリシーのRANGE１７ｂ２を取得する（Ｓ１０９）。

次いで、データ移行プログラム１１ａは、Ｓ１０４で取得した異常値ポリシーに該当するＩＤと期間の組合せの数だけ、以下Ｓ１１１からＳ１１２もしくはＳ１１６までの処理を各ＩＤ・期間の組合せに対して実行する（Ｓ１１０）。

データ移行プログラム１１ａは、処理対象のＩＤ・期間に対して、関連度ＤＢ１６（関連度情報保持部）に保持される関連度テーブル１６ａを参照し、Ｓ１０９にて取得した関連ポリシーの条件に該当する関連度ＩＤを取得する。図１３に関連度テーブル１６ａの例を記す。まずこの図を用いて関連度テーブル１６ａについて説明する。

関連度テーブル１６ａは、センサ間および期間ごとに関連度を定義したものであり、一つのレコードが一つのセンサ間の関係と期間の組合せを表す。関連度テーブル１６ａは、一つのセンサ間の関係と期間の組合せを一意に特定する関連度ＩＤ（R_ID）１６ａ０、センサ間の一つのＩＤを保持するID(1)１６ａ１、もう一つのセンサのＩＤを保持するID(2)１６ａ２、期間の種類を表すPERIOD１６ａ３、関連度の値を意味するRELATED_DEGREE１６ａ４、などを保持する。

前記のセンサ間の関係とは、前記の構成関係テーブル１８ｂにて定義されるセンサ間のことであり、サーバ１０で管理する機器２０に取り付けられたセンサ２２とセンサ２２との組合せを意味する。一般に、同一の機器２０や部品、同一型式に取り付けられたセンサ間は関係が強いと、また、同一の場所や同一の使用者に使用されている機器２０のセンサ間は関係が強いと考える。逆に、型式が異なる機器２０で別の使用者や場所で使用されている機器２０のセンサ間は関係が弱いと考える。また、前記の期間とは、異常値ポリシーのRANGE１７ｂ２に該当する履歴の期間との相対的な関係を表すものである。図１４にセンサ値と期間との関係の例を示す。「PT」は、異常値ポリシーの条件に該当する期間であり、図１４の例では時刻t3からt4までの期間が該当する。「FT」は異常値ポリシーの条件に該当する期間PTの直前の期間であり、図１４では時刻t2からt3までの期間が該当する。「FT」よりさらに前の期間が「F2T」であり、図１４では時刻t1からt2までの期間が該当する。同様に、PTの直後の期間が「LT」であり、図１４では時刻t4からt5までの期間が該当する。「LT」よりさらに後の期間が「L2T」であり、図１４では時刻t5からt6までの期間が該当する。FnT、LnTのnの数(nは自然数)や、各FnT、LnTの期間の長さは予めサーバ１０にて所定の数や長さに設定しておく。

図１３の関連度テーブル１６ａの説明に戻ると、関連度ＩＤ（R_ID）１６ａ０がR001である１番目のレコードの例では、S001OとS002VとがそれぞれID(1)１６ａ１、ID(2)１６ａ２に定義されており、PERIOD１６ａ３はPTとなっている。これは、例えばセンサS001Oで異常値ポリシーに該当する期間が存在する場合、その履歴とそれと同じ日時の期間内に該当するセンサS002Vの履歴との関連度は「0.7」であることを意味する。これは逆の場合も成り立ち、センサS001Vで異常値ポリシーに該当する期間が存在する場合、その履歴とそれと同じ日時の期間PT内に該当するセンサS001Oの履歴との関連度も「0.7」である。また、関連度ＩＤがR002のレコードでは、PERIODが「FT」となっている。これは、例えばセンサS001Oで異常値ポリシーに該当する期間が存在する場合、その履歴と、その期間の前の期間FT内に該当するセンサS002Vの履歴との関連度は「0.56」であることを意味する。逆の場合も同様に、センサS001Vで異常値ポリシーに該当する期間が存在する場合、その履歴と、その期間の前の期間FT内に該当するセンサS001Oの履歴との関連度も「0.56」である。なお、関連度テーブル１６ａにないセンサ間や期間の場合の関連度は0である。この関連度テーブル１６ａへのレコードの追加・更新・削除は、保守事業者がアプリケーション４０を通じて、もしくはサーバ１０運用者が運用アプリケーション３０を通じて、原因究明や結果推定の作業の際によく検索されるセンサ値の内容を基に関連度を決定するなどして行うことができる。

図１１のデータ移行プログラム１１ａの処理の説明に戻る。データ移行プログラム１１ａは、処理対象のＩＤが関連度テーブル１６ａのID(1)１６ａ１もしくはID(2)１６ａ２のいずれかと一致し、かつ関連度RELATED_DEGREE１６ａ４がＳ１０９にて取得した条件に該当する関連度ＩＤを検索する（Ｓ１１１）。

Ｓ１１１の処理にて該当する関連度ＩＤがある場合はＳ１１３の処理へ、ない場合は処理Ｓ１１７へ移り、異常値ポリシーに該当したＩＤ・期間の組合せを処理対象として同一の処理を実施する（Ｓ１１２）。以下、Ｓ１１４からＳ１１５までの処理を、Ｓ１１１の検索に該当した各関連度ＩＤ、およびそれに該当する関連度テーブル１６ａのレコードを処理対象として実施する（Ｓ１１３）。

Ｓ１０４で検索した異常値ポリシーに該当する期間PTを基に、関連度テーブル１６ａの処理対象のレコードのPERIOD１６ａ３の具体的な開始・終了日時を取得する。PERIOD１６ａ３の値がPTの場合はＳ１０４の異常値ポリシーの期間と同一であるが、FnT、LnTの場合は予め定義されたFnT、LnTの値を基に開始・終了日時を算出する（Ｓ１１４）。

次に、データ移行プログラム１１ａは、処理対象の関連度テーブル１６ａのレコードのID(1)１６ａ１もしくはID(2)１６ａ２に定義されている、異常値ポリシーに該当したＩＤではないもう一つのＩＤと、Ｓ１１４で取得した期間とを検索条件として履歴テーブル１４１ａを検索する。検索対象はＳ１０４と同様、ADD_DATE１４１ａ３がＳ１０１で取得した前回移行実行時の日時以降のレコードである（Ｓ１１５）。Ｓ１１４、Ｓ１１５の処理により、関連ポリシーに該当する履歴が取得できることになる。

Ｓ１１５の処理を行ったら、データ移行プログラム１１ａは、次の関連度ＩＤを処理対象としてＳ１１４、Ｓ１１５の処理を行う（Ｓ１１６）。

さらに、全ての関連度ＩＤに対してＳ１１６までの処理を行ったら、データ移行プログラム１１ａは、次の異常値ポリシーに該当するＩＤ・期間を処理対象としてＳ１０１からＳ１１６までの処理を行う（Ｓ１１７）。

全てのＩＤ・期間に対してＳ１１７までの処理を行ったら、データ移行プログラム１１ａは、次の関連ポリシーを処理対象としてＳ１０９からＳ１１７までの処理を行う（Ｓ１１８）。

全ての関連ポリシーに対してＳ１１８までの処理を行ったら、データ移行プログラム１１ａは、次の異常値ポリシーを処理対象としてＳ１０４からＳ１１８までの処理を行う（Ｓ１１９）。

全ての異常値ポリシーに対してＳ１１９までの処理を行ったら、データ移行プログラム１１ａは、契約ポリシーテーブル１７ａの内容に従ってデータの移行、削除を行う。異常値ポリシー・関連ポリシーについては、Ｓ１０４、およびＳ１１５で該当した履歴を契約ポリシーテーブル１７ａのTARGET１７ａ２「ABNORMAL」に該当する履歴とする。移行・削除対象の履歴は、ADD_DATE１４１ａ３がＳ１０１で取得した前回移行実行時の日時以降の全てのレコードである。処理実行日時がVALID_DATE１７ａ４を過ぎている場合は、対象となる履歴を履歴ＤＢ１４１やテープ１４２から削除する。正常終了したら、データ移行プログラム１１ａは、移行実行ログにデータ移行プログラム１１aのコマンドを受け付けた日時を追記する（Ｓ１２０）。以上がデータ移行プログラム１１aの処理の流れである。

なお、上記の例ではセンサ間の構成と、期間との組合せごとに関連度テーブル１６ａを定義するとしたが、期間の間の関連が明白に低い場合はセンサ間の構成のみで定義する、としてもよい。逆に、センサ間の関連が明白に低い場合は期間のみで定義する、としてもよい。

以上の処理により、サーバ１０の履歴ＤＢ１４１に蓄積される大量の機器２０のセンサ値の履歴について、ＤＢの容量や検索性能の観点からＤＢからテープ１４２への移行や削除が必要な場合においても、機器２０の異常やその予兆を表す逸脱センサ値を検出した際の原因分析や引き起こされる結果の推定に将来使用する可能性のある正常値の履歴も逸脱センサ値と合せてＤＢに残したまま、テープ１４２へのデータ移行を行うことが可能になる。これにより、センサ２２から収集した全てのセンサ値の履歴をＤＢに保持することなく、異常・予兆の検出時にも迅速に過去の類似センサ値の検索と合せて、その周辺の他のセンサ２２や前後の期間のセンサ値の迅速な検索が可能になり、原因究明、結果推定による対策の検討が迅速に行える。特に、稼働率保証・ペナルティありの保守契約の対象機器に逸脱センサ値が発生した場合、関連ポリシーにより履歴ＤＢ１４１には対象機器だけでなく対象機器と関連のある機器のセンサ値の履歴が保持されているため、その原因究明、結果推定にそれらの履歴を活用することが可能になる。

＜実施例２＞
次に、本発明の他の実施形態について、関連図面を参照して説明する。実施例１では、関連度テーブル１６ａの更新は保守事業者もしくはサーバ１０運用者が行うとしたが、実施例２として、関連度テーブル１６ａの関連度RELATED_DEGREE１６ａ４の見直しをサーバ１０自身が自動的に行う例について記す。本実施例で記載の内容以外の部分については、実施例１と同一である。

本実施例におけるサーバ１０の各プログラムの動作について説明する。本実施例では、保守事業者で動作するアプリケーション４０からの参照回数により関連度テーブル１６ａの関連度RELATED_DEGREE１６ａ４の値を見直し、更新する構成が採用されている。そのために、サーバ１０では履歴管理プログラム１１ｂ（参照履歴管理部）がアプリケーション４０からの参照回数をカウントする。また、関連度管理プログラム１１ｃが定期的もしくはサーバ１０運用者からの運用アプリケーション３０を通じたコマンド実行により、上記参照回数を基に関連度RELATED_DEGREE１６ａ４の値を更新する。

最初に履歴管理プログラム１１ｂの動作について説明する。図１５は履歴管理プログラム１１ｂが実行する処理のフローチャート例を示したものである。以下、この図に沿って説明する。

まずコマンドが実行されたら、履歴管理プログラム１１ｂは、契約ポリシーテーブル１７ａ、異常値ポリシーテーブル１７ｂの内容を読み込み、そこに定義されている異常値ポリシーを抽出しメモリ１１に読み込む（Ｓ１５１）。

その後、履歴管理プログラム１１ｂは、アプリケーション４０から履歴ＤＢ１４１への参照要求のリクエスト受信を待機する（Ｓ１５２）。

アプリケーション４０から履歴ＤＢ１４１への参照要求のリクエストを受信したら、履歴管理プログラム１１ｂは、リクエストに含まれる検索条件に該当する履歴を履歴テーブル１４１ａから検索する（Ｓ１５３）。履歴管理プログラム１１ｂは、検索結果として得られた履歴をアプリケーション４０に返信する（Ｓ１５４）。

次に、履歴管理プログラム１１ｂは、アプリケーション４０に返信した履歴の中に、Ｓ１５１で読み込んだ異常値ポリシーに該当する履歴が含まれているかを確認する。該当する履歴がある場合は、その履歴の内容を取得し、図１１のデータ移行処理におけるＳ１０４と同様に、ＩＤと期間の組合せを抽出する（Ｓ１５５）。抽出したら、履歴管理プログラム１１ｂはＳ１５７の処理へ移る。該当する履歴がない場合は、履歴管理プログラム１１ｂは、Ｓ１５２の処理に戻る（Ｓ１５６）。

Ｓ１５６で、異常値ポリシーに該当する履歴が返信に含まれる場合、履歴管理プログラム１１ｂは、それ以外の履歴が返信の中にあるかを確認する（Ｓ１５７）。ある場合、履歴管理プログラム１１ｂは、Ｓ１５９の処理へ移る。ない場合、履歴管理プログラム１１ｂは、Ｓ１５２の処理に戻る（Ｓ１５８）。

以下、Ｓ１５５で抽出したＩＤと期間の各組合せに対し、Ｓ１６０からＳ１６５までの処理を繰り返す（Ｓ１５９）。

まず、履歴管理プログラム１１ｂは、処理対象のＩＤ・期間の組合せについて、PT以外の期間（LnT、FnT）の具体的な開始・終了日時を予め定義された内容を基に算出する（Ｓ１６０）。以下、Ｓ１５７で取得した異常値ポリシーに該当しない他の履歴に対して、それぞれＳ１６２からＳ１６４までの処理を行う（Ｓ１６１）。

履歴管理プログラム１１ｂは、処理対象の履歴のTIMESTAMP１４１ａ１を取得し、その日時がＳ１６０で算出したどの期間に該当するかを判定する（Ｓ１６２）。なお、Ｓ１６０で算出したどの期間にも該当しない場合は、この履歴に対する処理を終了し次の履歴の処理に移る。同様に、履歴管理プログラム１１ｂは、処理対象の履歴のＩＤを取得する（Ｓ１６３）。

履歴管理プログラム１１ｂは、Ｓ１６２で該当した期間（PERIOD）、Ｓ１６３で取得したＩＤ、およびＳ１５５で抽出した異常値ポリシーに該当する履歴のＩＤを基に、関連度テーブル１６ａ中の該当するレコードを検索する。ＩＤはそれぞれID(1)１６ａ１、ID(2)１６ａ２のどちらに該当してもよい。該当するレコードがない場合は、関連度ＩＤを採番して関連度テーブル１６ａにレコードを追加する。その場合の関連度RELATED_DEGREE１６ａ４の値は0とする。履歴管理プログラム１１ｂは、該当したレコードの関連度ＩＤ、および追加した関連度ＩＤをメモリ１１に保持する。ただしすでにメモリ１１のリストに関連度ＩＤが格納されている場合は、その関連度ＩＤは追加しない(Ｓ１６４)。

Ｓ１６４の処理を行ったら、履歴管理プログラム１１ｂは、次の履歴を処理対象としてＳ１６２からＳ１６４までの処理を行う（Ｓ１６５）。

次いで、履歴管理プログラム１１ｂは、全ての履歴に対してＳ１６５までの処理を行ったら、次の異常値ポリシーに該当するＩＤ・期間を処理対象として、Ｓ１６０からＳ１６５までの処理を行う（Ｓ１６６）。

さらに、履歴管理プログラム１１ｂは、全てのＩＤ・期間の組合せに対してＳ１６６までの処理を行ったら、Ｓ１６４にてメモリ１１に保持されている関連度ＩＤのリストを取得し、リストに含まれる各関連度ＩＤに対して、参照履歴ＤＢ１５が保持する参照回数テーブル１５ａに該当する関連度ＩＤがあるかを確認する。参照回数テーブル１５ａの例を図１６に示す。参照回数テーブル１５ａは関連度ＩＤごとにアプリケーション４０の参照回数をカウントしたもので、関連度ＩＤを表すR_ID１５ａ０、参照回数を表すREF_COUNT１５ａ１を保持する。該当する関連度ＩＤがこのテーブルにある場合は、REF_COUNT１５ａ１の値をインクリメントする。該当する関連度ＩＤがない場合は参照回数テーブル１５ａに関連度ＩＤを追加し、REF_COUNT１５ａ１を「１」とする。リスト中の全ての関連度ＩＤについて参照回数テーブル１５ａへの更新／追加処理を行ったら、Ｓ１５２へ戻り再び待機状態とする（Ｓ１６７）。以上が履歴管理プログラム１１ｂの処理の流れである。

次に、関連度管理プログラム１１ｃの動作について説明する。関連度管理プログラム１１ｃは、前記の履歴管理プログラム１１ｂが更新・作成した参照回数テーブル１５ａを基に、関連度テーブル１６ａの関連度RELATED_DEGREE１６ａ４の値を更新するプログラムである。関連度管理プログラム１１ｃは、サーバ１０運用者が運用アプリケーション３０を通してコマンドを実行することにより、もしくは定期的に動作する。図１７は関連度管理プログラム１１ｃが実行する処理のフローチャート例を示したものである。以下、この図に沿って説明する。

最初に、関連度管理プログラム１１ｃは、サーバ１０の内部ログとして保持する関連度更新ログの内容を取得し、前回更新日時を取得する。また、関連度管理プログラム１１ｃは、関連度更新プログラムのコマンド実行を受け付けた日時（コマンド実行日時）も保持しておく（Ｓ２０１）。

次に、関連度管理プログラム１１ｃは、参照回数テーブル１５ａの内容を取得し、REF_COUNT１５ａ１が0以外の関連度ＩＤであるR_IDを取得する（Ｓ２０２）。

以下、関連度管理プログラム１１ｃは、S202で抽出したREF_COUNT１５ａ１が0でない各関連度ＩＤに対し、S204からS206までの処理を繰り返す（Ｓ２０３）。

次いで、関連度管理プログラム１１ｃは、処理対象の関連度ＩＤの参照回数REF_COUNT１５ａ１を取得する。そして、Ｓ２０１で取得した前回更新日時とコマンド実行日時との差から、単位時間あたりの参照回数を算出する。例えば、関連度更新プログラム１１ｃが毎週日曜0時に定期的に起動する場合、この間の参照回数が７回、単位時間を１日とすると、単位時間あたりの参照回数は１となる（Ｓ２０４）。

関連度管理プログラム１１ｃは、Ｓ２０４で算出した単位時間あたりの参照回数を基に、関連度ＤＢ１６が保持する関連度更新マスタ１６ｂの該当する内容を取得する。関連度更新マスタ１６ｂの例を図１８に示す。本マスタは単位時間あたりの参照回数に基づく関連度の更新値を保持するもので、単位時間あたりの参照回数REF_COUNT１６ｂ０、更新値UPDATE_VALUE１６ｂ１、などを保持する。例えば単位時間あたりの参照回数が１の場合、図１８の例だと更新値は「-0.2」となる（Ｓ２０５）。

次に、関連度管理プログラム１１ｃは、Ｓ２０５で取得した更新値を基に、関連度テーブル１６ａの該当する関連度ＩＤの関連度RELATED_DEGREE１６ａ４の値を更新する。例えば、関連度テーブル１６ａの関連度の値が0.7で更新値が-0.2の場合、更新後の値は0.5となる。更新完了できたら、関連度管理プログラム１１ｃは、参照回数テーブル１５ａの該当する関連度のREF_COUNT１５ａ１を0に更新する（Ｓ２０６）。

関連度管理プログラム１１ｃは、Ｓ２０６の処理を行ったら、次の関連度ＩＤを処理対象としてＳ２０４からＳ２０６までの処理を行う（Ｓ２０７）。

さらに、関連度管理プログラム１１ｃは、全ての関連度ＩＤに対してＳ２０７までの処理を行ったら、関連度更新ログの前回更新日時をコマンド実行日時の値に更新し（Ｓ２０８）、処理を終了する。以上が関連度管理プログラム１１ｃの処理の流れである。

以上の処理により、逸脱センサ値と他の期間・センサとの間の関連度を、アプリケーション４０からの参照頻度に合せて見直し、更新することが可能になる。これにより、アプリケーション４０を利用する保守事業者が原因究明・結果推定時によく参照する過去の履歴の傾向にあわせて、検索される傾向のある関係の履歴は履歴ＤＢ１４１に残したままにするなど、検索される可能性の高い履歴をＤＢに残すデータ移行が可能になる。

＜実施例３＞
次に、本発明の実施例３について説明する。実施例２では、関連度更新プログラム１１ｃはサーバ１０運用者からのコマンド実行をトリガーとして動作するとしたが、実施例３として、関連度更新プログラム１１ｃの実行を構成関係テーブル１８ｂの変更をトリガーとして行う例について記す。本実施例で記載の内容以外の部分については、実施例２と同一である。

まず、本実施例におけるサーバ１０の各プログラムの動作について説明する。本実施例では、保守事業者がアプリケーション４０を通して機器２０の追加・配置、撤去、機器２０の部品の交換など、機器構成の変更のリクエストをサーバ１０に対して実施する。サーバ１０はこのリクエストを受信したら、機器構成管理プログラム１１ｄによりリクエストに対応する処理を実行する。図１９はこのときの機器構成管理プログラム１１ｄの処理のフローチャート例を示したものである。以下、この図に沿って説明する。

まず、機器構成管理プログラム１１ｄは、アプリケーション４０から、機器構成の変更要求に関するリクエストを受信する（Ｓ３０１）。リクエストを受信したら、機器構成管理プログラム１１ｄは、その内容を参照して機器等の削除なのか、追加なのか、交換なのかを判定する。機器構成管理プログラム１１ｄは、削除の場合はＳ３０３、追加の場合はＳ３１１、交換の場合はＳ３２１の処理を行う（Ｓ３０２）。なお、使用場所や使用者が変更になった場合は、機器構成管理プログラム１１ｄは、「交換」ではなく「削除」と「追加」を実施し、部品やセンサ２２の変更の場合は「交換」を実施する。これはアプリケーション４０にて判断する。

機器等（機器だけでなく場所、使用者、部品、センサ２２など機器構成マスタ１８で管理するＩＤ全てが対象）の削除の場合、機器構成管理プログラム１１ｄは、Ｓ３０１で受信したリクエストに含まれる削除対象のＩＤを取得し、各ＩＤに対してそれぞれＳ３０４からＳ３０８までの処理を実施する（Ｓ３０３）。

まず、機器構成管理プログラム１１ｄは、リクエストで指定のＩＤが、属性も削除するのか、単に構成から削除するのみか、をリクエストの内容から取得する。前者の場合、削除対象のＩＤに該当するレコードを属性テーブル１８ａから削除する。後者の場合は何もせず次の処理へ移る（Ｓ３０４）。

属性も削除する場合、機器構成管理プログラム１１ｄは、削除対象のＩＤがID(1)１８ｂ０もしくはID(2)１８ｂ１に指定されているレコードを構成関係テーブル１８ｂからすべて削除する。構成から削除する場合は、削除対象のＩＤがID(1)１８ｂ０もしくはID(2)１８ｂ１に含まれるレコードのEND_DATE１８ｂ３に処理実行時の日時を登録する（Ｓ３０５）。

機器構成管理プログラム１１ｄは、削除対象のＩＤがID(1)１８ｂ０もしくはID(2)１８ｂ１に指定されているレコードを関連度テーブル１６ａから全て削除する。関連度テーブル１６ａについては属性も削除する場合、構成から削除するのみの場合いずれの場合もレコードを削除する（Ｓ３０６）。

機器構成管理プログラム１１ｄは、Ｓ３０６にて削除した関連度テーブル１６ａのレコードの関連度ＩＤ(R_ID)１６ａ０に該当するレコードを、参照回数テーブル１５ａから削除する（Ｓ３０７）。

Ｓ３０７の処理を行ったら、機器構成管理プログラム１１ｄは、次の削除対象ＩＤを処理対象としてＳ３０３からＳ３０７までの処理を行う（Ｓ３０８）。全ての削除対象に対する処理を終えたら、機器構成管理プログラム１１ｄは、関連度管理プログラム１１ｃを起動し、関連度の更新を行う。

Ｓ３０２の処理に戻って、機器等の追加の場合、機器構成管理プログラム１１ｄは、Ｓ３０１で受信したリクエストに含まれる追加対象のＩＤを取得し、各ＩＤに対してそれぞれＳ３１２からＳ３１４までの処理を実施する（Ｓ３１１）。

まず、機器構成管理プログラム１１ｄは、追加対象のＩＤを、リクエストに含まれるID_TYPEと合せて属性テーブル１８ａにレコード追加する。ただし既に属性テーブル１８ａに該当するＩＤが存在する場合は、何もせず次の処理へ移る（Ｓ３１２）。

次いで、機器構成管理プログラム１１ｄは、リクエストに追加対象のＩＤのほか、そのＩＤと関連のあるＩＤも指定されている場合は構成関係テーブル１８ｂにその指定の数だけレコードを追加する。START_DATE１８ｂ２はレコードを追加した日時を指定する。包含関係など関係が上下関係を意味する関係の場合、リクエストでは追加対象のＩＤの上位に位置するＩＤを指定する。追加対象のＩＤはID(2)１８ｂ１に登録し、関係のあるＩＤをID(1)１８ｂ０に登録する。同一型式など上下でない関係の場合はどちらのＩＤをID(1)１８ｂ０／ID(2)１８ｂ１に登録しても構わない（Ｓ３１３）。

次に、追加したＩＤのID_TYPE１８ａ１がセンサ２２を表す場合（「SENSOR_」で始まる文字列の場合）、機器構成管理プログラム１１ｄは、関連度ＤＢ１６が保持する関連度定義マスタ１６ｃを基に関連度テーブル１６ａに追加対象のＩＤに対応するレコードを追加する。図２０に関連度定義マスタ１６ｃの例を示す。

関連度定義マスタ１６ｃは、センサ間の関係または期間ごとに、関連度の初期値を定義したものである。一つのレコードが一つの関係または期間の値に振られる関連度の初期値を表し、そのレコードが関係（CONFIGURE）または期間（PERIOD）のどちらを対象としているかを表すTYPE１６ｃ０、TYPEの値を表すVALUE１６ｃ１、関連度の初期値を表すRELATED_DEGREE１６ｃ２、などを保持する。TYPEがPERIOD（期間）の場合、VALUE１６ｃ１にはPTもしくはLnT、FnTが指定される。TYPEがCONFIGURE（関係）の場合、VALUE１６ｃ１にはセンサ２２間の距離が指定される。センサ２２間の距離とは、機器構成から導き出されるセンサ２２間の論理的な関係の近さ／遠さを意味し、例えば図２１の例では、SENSOR AとSENSOR Bとは同一部品PART 01に取り付けられたセンサ２２であるため、距離を「１」と定義する。SENSOR AとSENSOR Cの場合、部品は異なるが同じ機器２０（EXCAVATOR a）に取り付けられたセンサ２２であるため、距離を「２」と定義する。なお、同一センサの場合には距離は「０」である。このように、構成関係テーブル１８ｂのレコードから図２１のような機器の論理構成を生成し、これを基にセンサ２２間の距離が算出できる。

以上のように、構成関係テーブル１８ｂを基に、関連度定義マスタ１６ｃで定義されているTYPE１６ｃ０「CONFIGURE」の全ての距離に該当するセンサ２２を取得する。例えば関連度定義マスタ１６ｃでは距離が「３」までのレコードが定義されている場合は、構成関係テーブル１８ｂの内容を参照し（END_DATE１８ｂ３がNULL、もしくは処理実行時がSTART_DATE１８ｂ２とEND_DATE１８ｂ３の間の日時のレコードのみが対象）、機器２０の論理構成を基に追加したセンサ２２のＩＤと距離が３までに含まれる全てのセンサ２２を取得する。そして、取得した全てのセンサ２２に対して、関連度定義マスタ１６ｃで定義されているTYPE１６ｃ０「PERIOD」の全ての期間の組合せをレコードとして関連度テーブル１６ａに追加する。例えば、追加対象としてセンサ２２との距離が関連度定義マスタ１６ｃでTYPE１６ｃ０「CONFIGURE」のVALUE１６ｃ１に該当するセンサ２２が４個あり、TYPE１６ｃ０「PERIOD」のVALUE１６ｃ１がPT、LT、FT、L2T、F2Tの５つが定義されているとすると、関連度テーブル１６ａに追加するレコードは両者の組み合わせで２０個となる。関連度テーブル１６ａの関連度RELATED_DEGREE１６ａ４に登録する値は、関連度定義マスタ１６ｃから取得した該当するTYPE１６ｃ０「CONFIGURE」と、TYPE１６ｃ０「PERIOD」の関連度の初期値を掛け合わせたものとする。例えば、図２０の例だとCONFIGUREのVALUE１６ｃ１が２、PERIODのVALUE１６ｃ１がFTの場合、0.8×0.85＝0.68が、関連度テーブル１６ａの関連度RELATED_DEGREE１６ａ４に登録する値となる。この計算を関連度テーブル１６ａに追加する全てのレコードに対して実施し、関連度を算出して登録する。なお、追加したＩＤのID_TYPE１８ａ１がセンサ２２以外の場合、本処理は実施されない（Ｓ３１４）。

Ｓ３１４の処理を行ったら、機器構成管理プログラム１１ｄは、次の追加対象ＩＤを処理対象としてＳ３１２からＳ３１４までの処理を行う（Ｓ３１５）。全ての追加対象に対する処理を終えたら、機器構成管理プログラム１１ｄは、関連度管理プログラム１１ｃを起動し、関連度の更新を行う。

Ｓ３０２に戻って、機器等の交換の場合、機器構成管理プログラム１１ｄは、Ｓ３０１で受信したリクエストに含まれる交換後のＩＤを取得し、各ＩＤに対してそれぞれＳ３２２からＳ３２４までの処理を実施する（Ｓ３２１）。

交換の場合、機器構成管理プログラム１１ｄは、リクエストで指定の交換前ＩＤは属性テーブル１８ａからの削除は行わず、構成を他のＩＤに交換するのみである。交換後のＩＤを属性テーブル１８ａに追加するが、既に交換後のＩＤが属性テーブル１８ａに存在する場合は追加しない。追加する場合、リクエストに含まれるID_TYPEと合せて追加する。ただし、交換前のＩＤのID_TYPE１８ａ１とリクエストに含まれる交換後のＩＤのID_TYPEが一致しない場合は交換不可とし、エラーとして処理を終了する（Ｓ３２２）。

次いで、機器構成管理プログラム１１ｄは、交換前のＩＤが構成関係テーブル１８ｂのID(1)１８ｂ０もしくはID(2)１８ｂ１に指定されているレコードを検索し、該当するレコードについてはEND_DATE１８ｂ３に処理実行時の日時を登録する。そして、そのレコードを基に、交換前のＩＤを交換後のＩＤとし（ただしもう一方のＩＤは引き継ぐ）、START_DATE１８ｂ２を処理実行時の日時とする（ただしEND_DATE１８ｂ３はNULL）レコードを追加する（Ｓ３２３）。

関連度テーブル１６ａについては、交換前のＩＤがID(1)１８ｂ０もしくはID(2)１８ｂ１に指定されているレコードを検索し、該当するレコードについては交換後のＩＤに更新する（Ｓ３２４）。

Ｓ３２４の処理を行ったら、機器構成管理プログラム１１ｄは、次の追加対象ＩＤを処理対象としてＳ３２２からＳ３２４までの処理を行う（Ｓ３２５）。全ての追加対象に対する処理を終えたら、関連度管理プログラム１１ｃを起動し、関連度の更新を行う。以上が機器構成管理プログラム１１ｄの処理の流れである。

なお、上記の例ではＳ３１４において関連度定義マスタ１６ｃから取得した距離の初期値とセンサ２２間の構成の初期値とを掛け合わせて関連度を算出するとしたが、あらかじめ定義した距離の初期値とセンサ２２間の構成の初期値を含む算出式により算出することとしてもよい。また、実施例１にて記載したように、期間の間の関連が明白に低い場合はセンサ２２間の構成のみで算出する、としてもよい。逆に、センサ２２間の関連が明白に低い場合は期間のみで算出する、としてもよい。

以上の処理により、関連度に大きく変化が生じる可能性がある機器構成の変化（機器の使用場所や使用者の変更、もしくは部品やセンサの交換）が生じた場合をトリガーとして、関連度の見直し・修正を自動で行うことが可能になる。これにより、機器構成の変更に連動して関連度の修正を即座に行うことが可能になり、ひいては機器構成の変更の前後で逸脱センサ値と合せて検索される可能性の高い正常センサ値の対象が変わる場合でも、その正常センサ値をＤＢに残すデータ移行が可能になる。

以上、本発明を実施するための形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。例えば、前記のように本実施例ではＤＢからの履歴の移行先としてテープを想定したが、他の記憶媒体、もしくは移行せずに履歴を削除する場合においても対応が可能である。

また、以上の実施形態では、サーバ１０が履歴や機器構成情報などを一元管理するとして説明したが、情報や機能を分散して保持するなどの場合でも、サーバ1が仮想的に一元管理するなど自由に利用・参照可能であれば、実際の情報・機能の所在場所はどこでも構わない。

１ 情報管理システム
１０ サーバ
２０ 機器
３０ 運用アプリケーション
４０ アプリケーション
５０ 通信ネットワーク
１１ メモリ
１１ａ データ移行プログラム
１１ｂ 履歴管理プログラム
１１ｃ 関連度管理プログラム
１１ｄ 機器構成管理プログラム
１１ｅ ポリシー生成プログラム
１２ ＣＰＵ
１３ 通信部
１４ 履歴管理庫
１５ 参照履歴ＤＢ
１６ 関連度ＤＢ
１７ ポリシーＤＢ
１８ 機器構成マスタ
１９ 契約ＤＢ
２１ コントローラ
２２ センサ
１４１ 履歴ＤＢ
１４２ テープ

Claims (10)

1. 複数の機器の稼動状態を示す情報である稼働情報を前記機器から収集して保持し、前記稼働情報を活用したサービスを提供する情報利用装置によって参照させる情報管理装置であって、
   前記機器に関して前記情報利用装置によって提供されるサービスレベルについて規定された契約に関する情報である契約情報を保持する契約情報保持部と、
   各前記機器について保持されている前記契約情報を前記契約情報保持部から取得し、前記契約情報に基づき、各前記機器について保持されている前記稼動情報の管理方式を規定する情報である管理ポリシー情報を、少なくとも各前記稼働情報の格納場所に関する情報である格納場所情報を含めて生成する管理ポリシー生成部と、
   を有することを特徴とする情報管理装置。
2. 請求項１に記載の情報管理装置であって、
   各前記機器から収集された前記稼働情報を各前記機器に対応させて時系列に保持している稼働情報履歴保持部と、
   各前記機器に対応する前記稼働情報を前記稼働情報履歴保持部から取得し、各前記機器に対応する前記管理ポリシー情報に基づいて各前記機器に関する前記稼働情報を管理する稼動情報管理部と、を有し、
   前記稼動情報管理部は、前記稼働情報履歴保持部から各前記機器に対応する前記稼働情報を取得し、各前記機器に対応する前記管理ポリシー情報を参照して各前記機器に対応する前記稼働情報について規定されている前記格納場所情報に従って、前記稼働情報の格納場所を再配置する、
   ことを特徴とする情報管理装置。
3. 請求項２に記載の情報管理装置であって、
   前記稼働情報が数値データであり、前記管理ポリシー情報が前記数値データに関する判定条件を含み、
   各前記機器の相互関係、又は前記数値データが前記判定条件を満たした時間の前後において所定の長さで設定された期間の相互関係の関連する度合いを示す情報である関連度情報を保持する関連度情報保持部を有し、
   前記稼働情報管理部は、各前記機器に対応して前記稼働情報履歴保持部に保持されている前記稼働情報を取得し、前記管理ポリシー保持部を参照して前記判定条件を満たすか判定し、満たすと判定した稼働情報について、前記関連度情報保持部を参照して所定の関連度を有する前記機器又は前記期間を前記稼働情報とともに前記管理ポリシー情報に従って格納場所の再配置を実行する、ことを特徴とする情報管理装置。
4. 請求項３に記載の情報管理装置であって、
   前記情報利用装置からの前記稼動情報の参照履歴を管理する参照履歴管理部と、
   前記関連度情報保持部に保持されている、前記機器に対応する前記関連度情報を更新する関連度情報更新部と
   を有し、
   前記参照履歴管理部は、前記機器又は前記期間ごとに該当する前記稼動情報の参照頻度を集計し、
   前記関連度更新部は、前記機器又は前記期間ごとの前記参照頻度に基づいて、前記関連度情報を更新する、
   ことを特徴とする情報管理装置。
5. 請求項４に記載の情報管理装置であって、
   各前記機器についての属性を示す属性情報と、前記属性相互の関係を規定する機器構成情報とを含む情報である機器構成情報を保持する機器構成情報保持部を有し、
   前記関連度更新部は、前記機器構成情報保持部を継続的にモニタし、いずれかの前記機器に関する属性情報又は前記機器構成情報が変更されたと判定した場合、前記変更ありと判定された前記機器に関して前記関連度情報保持部に保持されている関連度情報を更新する、
   ことを特徴とする情報管理装置。
6. 複数の機器の稼動状態を示す情報である稼働情報を前記機器から収集して保持し、前記稼働情報を活用したサービスを提供する情報利用装置によって参照させる情報管理方法であって、プロセッサとメモリとを備えるコンピュータが、
   前記機器に関して前記情報利用装置によって提供されるサービスレベルについて規定された契約に関する情報である契約情報を保持し、
   各前記機器について保持されている前記契約情報を取得し、前記契約情報に基づき、各前記機器について保持されている前記稼動情報の管理方式を規定する情報である管理ポリシー情報を、少なくとも各前記稼働情報の格納場所に関する情報である格納場所情報を含めて生成する
   ことを特徴とする、
   情報管理方法。
7. 請求項６に記載の情報管理方法であって、前記コンピュータが、
   各前記機器から収集された前記稼働情報を各前記機器に対応させて時系列に保持し、
   各前記機器に対応する前記稼働情報を取得し、各前記機器に対応する前記管理ポリシー情報に基づいて各前記機器に関する前記稼働情報を管理し、
   各前記機器に対応する前記稼働情報を取得し、各前記機器に対応する前記管理ポリシー情報を参照して各前記機器に対応する前記稼働情報について規定されている前記格納場所情報に従って、前記稼働情報の格納場所を再配置する、
   ことを特徴とする情報管理方法。
8. 請求項７に記載の情報管理方法であって、
   前記稼働情報が数値データであり、前記管理ポリシー情報が前記数値データに関する判定条件を含み、前記コンピュータが、
   各前記機器の相互関係、又は前記数値データが前記判定条件を満たした時間の前後において所定の長さで設定された期間の相互関係の関連する度合いを示す情報である関連度情報を保持し、
   各前記機器に対応して保持されている前記稼働情報を取得し、前記管理ポリシー情報を参照して前記判定条件を満たすか判定し、満たすと判定した稼働情報について、前記関連度情報を参照して所定の関連度を有する前記機器又は前記期間を前記稼働情報とともに前記管理ポリシー情報に従って格納場所の再配置を実行する、ことを特徴とする情報管理方法。
9. 請求項８に記載の情報管理方法であって、前記コンピュータが、
   前記情報利用装置からの前記稼動情報の参照履歴を、前記機器又は前記期間ごとに該当する前記稼動情報の参照頻度を集計することによって管理し、
   前記機器に対応する前記関連度情報を、前記機器又は前記期間ごとの前記参照頻度に基づいて更新する、
   ことを特徴とする情報管理方法。
10. 請求項９に記載の情報管理方法であって、前記コンピュータが、
    各前記機器についての属性を示す属性情報と、前記属性相互の関係を規定する機器構成情報とを含む情報である機器構成情報を保持し、
    前記機器構成情報を継続的にモニタし、いずれかの前記機器に関する属性情報又は前記機器構成情報が変更されたと判定した場合、前記変更ありと判定された前記機器に関して保持されている関連度情報を更新する、
    ことを特徴とする情報管理方法。

Images