以下、図面を参照しながら、実施形態を詳細に説明する。
図2は、実施形態の機器管理システムの構成例を示している。
この機器管理システム200は、同一の機種である複数の機器400と、これらの機器400を監視する監視装置であるサーバ500とを備えている。この例では、複数の機器400の各々は、自身が有しているモータの動作管理を行うものとする。
なお、便宜上、図2においては、機器400として、3台の機器400a、400b、及び400cを表している。
図1の機器管理システム1では、機器11の各々についてのログをサーバ12が記憶していたが、この機器管理システム200では、サーバ500ではなく、機器400の各々が自身についてのログを記憶しておく。このログは、機器400の自身の状態や機器400の自身で発生したイベントを表している情報を、当該状態の検知の日時及び当該イベントの発生の検知の日時を表している時間情報に対応付けた情報である。
以下の説明では、機器管理システム200が有する複数の機器400のうちの機器400cにおいて異常が発生した場合についての動作、より具体的には機器400cに故障が発生した場合についての動作を、図2及び図3を用いて説明する。図3は、機器管理システム200の各構成要素についてのシーケンス図であり、構成要素間での情報の流れを時系列に表したものである。
(1)まず、自身の監視を行っている機器400cは、自身での故障の発生を検知すると、この検知時点までの機器400cについてのログをサーバ500へ送付する。サーバ500は、このログを受信する。
(2)サーバ500は、機器400cより送られてきたログより要点コード列を生成する。
要点コード列は、ログに表されている情報の要点を表現しているコード列であり、ログに含まれている情報が表している前述の状態及びイベントと、当該状態及び当該イベントの発生の検知の順序とを表しているコード列である。ログ及び要点コード列の具体的なデータ構造については後述する。
サーバ500は、故障発生が検知された機器400cのログから、前述の状態及びイベントの情報とこの情報に対応付けられている前述の時間情報とを抽出し、抽出した情報を用いて要点コード列を生成する。サーバ500は、生成した要点コード列の配信を、機器400のうちの機器400c以外(図2及び図3の例では機器400a及び400b)の各々に対して行う。
(3)要点コード列の配信を受けた機器400(図2及び図3の例では機器400a及び400b)は、自身で記憶している自身のログを参照して判定を行う。この判定では、サーバ500から送られてくる要点コード列で表されている状態及びイベントが、当該要点コード列で表されている順序で検知したことがあるか否かが判定される。この判定において、受け取った要点コード列で表されている状態及びイベントが、当該要点コード列で表されている順序で検知したことがあると判定した場合には、機器400は、自身に故障の発生の可能性があることを示しているアラームをサーバ500へ送付する。
(4)サーバ500は、このアラームを機器400から受け取ると、アラーム表示を行って、受け取ったアラームについての情報を出力する。このアラーム表示によりアラームの内容を認識した機器管理システム200の管理者は、サービスマンに指示を与えて、故障の発生の可能性がある機器400に対し、当該故障を未然に防止するための対策を実施させる。
このように、機器管理システム200においては、故障が発生した機器400c以外の機器400(図2及び図3の例では機器400a及び400b)の各々と、サーバ500との間では、要点コード列の伝送を行うものの、ログの伝送は行わない。詳細は後述するが、要点コード列はログよりもデータ量が少ないので、機器400とサーバ500との間で伝送されるデータ量は少なくなる。
図4及び図5について説明する。図4は、機器管理システム200が有している複数の機器400の各々の構成例であり、図5は、機器管理システム200が有しているサーバ500の構成例である。
機器400は、モータ401、動作管理部402、及びログ記憶部410を備えている。機器400は、更に、故障検知部411及びログ送信部412と、要点コード列受信部421、アラーム判定部422、アラーム送信部423、及びアラーム表示部424とを備えている。
動作管理部402は、予め用意されている制御プログラムに従って、モータ401の動作管理を含む、機器400によるモータ401の動作制御の管理を行う。動作管理部402は、また、機器400自身の状態、例えばモータ401の動作状態の検知を行う。更に、動作管理部402は、機器400で発生したイベント、例えばモータ401に対する制御動作や不図示のスイッチに対する操作、当該制御動作に関する不図示の上位装置との通信などの検知も行う。動作管理部402は、検知した状態及び発生したイベントを表している情報を、検知した状態の検知の日時及びイベントの発生の検知の日時を表している時間情報に対応付けて、機器400についてのログとしてログ記憶部410に記憶する。
故障検知部411は、例えば動作管理部402から送られてくる、機器400で発生したイベントの情報を監視することによって、機器400での故障の発生を、機器400の異常発生として検出する。
ログ送信部412は、故障検知部411が故障の発生を検知したときに、ログ記憶部400に記憶されているログをサーバ500へ送信する。
要点コード列受信部421は、サーバ500から送られてくる要点コード列を受信する。
アラーム判定部422は、ログ記憶部410に記憶されているログを参照して、要点コード列受信部421が受信した要点コード列で表されている状態及びイベントが、当該要点コード列で表されている順序で検知したことがあるか否かを判定する。
アラーム送信部423は、受信した要点コード列で表されている状態及びイベントが、当該要点コード列で表されている順序で検知したことがあると判定された場合に、機器400自身に異常の発生の可能性があることを示しているアラームをサーバ500へ送信する。
アラーム表示部424は、受信した要点コード列で表されている状態及びイベントが、当該要点コード列で表されている順序で検知したことがあると判定された場合に、機器400自身に異常の発生の可能性があることを示しているアラーム表示を行う。
サーバ500は、ログ記憶部501と要点コード列記憶部502とを備えている。サーバ500は、更に、ログ受信部511、ログ解析部512、要点コード列生成部513、及び要点コード列送信部514と、アラーム受信部521及びアラーム表示部522とを備えている。
ログ受信部511は、複数の機器400のうちの、故障の発生が検知された機器400cから送られてくる、機器400cについてのログを受信する。更に、ログ受信部511は、受信したログをログ記憶部501に記憶させる。
ログ解析部512は、ログ受信部511が受信した、故障の発生が検知された機器400cについてのログの解析を行う。この解析では、ログ解析部512は、まず、ログから、機器400cの状態についてのログデータと、機器400cで発生したイベントについてのログデータとを抽出する。更に、ログ解析部512は、抽出したログデータが表している状態及びイベントの発生の検知の順序を、当該ログの時間情報に基づいて特定する。
要点コード列生成部513は、ログ解析部512による解析結果に基づいて要点コード列を生成する。生成される要点コード列は、機器400cについてのログから抽出したログデータが示している状態及びイベントを表しており、且つ、特定した当該状態及びイベントの発生の検知の順序を表しているコード列である。更に、要点コード列生成部513は、生成した要点コード列を要点コード列記憶部502に一旦記憶させる。
要点コード列送信部514は、要点コード列生成部513が生成して要点コード列記憶部502に記憶させておいた要点コード列を、複数の機器400の各々へ送信する。
アラーム受信部521は、複数の機器400の各々におけるアラーム送信部423により送信されるアラームを受信する。
アラーム表示部522は、アラーム受信部521が受信したアラームについての情報を、当該情報の表示により出力する。
次に、ログ及び要点コード列の詳細について、図6及び図7を用いて説明する。
図6において、(A)は、機器400のログ記憶部410に記憶されるログの例を示している。また、(B)は、要点コード列の例を示している。
まず、(A)のログについて説明する。
ログでは、「日付」、「時刻」、「コード」、及び「メッセージ」が各行で対応付けられている。このうちの「コード」は、機器400自身の状態や機器400自身で発生したイベントを表している情報である。つまり、各行のデータは、コードによって表現されている状態若しくはイベントの発生を、日付及び時刻で特定される日時に検知したことを表している。
なお、メッセージは、同一行に示されているコードによって検知されたことが表されている状態若しくは発生したイベントがどのようなものであるかを、簡単に説明した文である。このメッセージについてはログとして記録しなくてもよい。
サーバ500のログ解析部512は、ログ受信部511が(A)のログを受信すると、まず、コードと、コードに対応付けられている日付及び時刻とを各行から抽出する。続いて、ログ解析部512は、抽出した各コードに対応付けられている日付及び時刻で特定される日時に基づき、当該各コードにより表されている状態若しくはイベントの発生の検知の順序を特定する。要点コード列生成部513は、ログ解析部512が抽出した状態及びイベントについてのコードを、ログ解析部512が特定した状態及びイベントの発生の検知の順序に従った並び順で並べる。このようにして要点コード列が生成される。
(A)のログでは、ログの各行に示されているコードが、日付及び時刻で特定される日時順に並べられる結果、第1行のコード「S00」から第10行のコード「S22」までの各コードが行順に並べられて要点コード列が作成される。
なお、要点コード列に並べられる最後のコードは、故障の発生を表しているコードの直前のコードである。(A)のログでは、故障の発生を表しているのは第11行の「E21」なるコードであり、このコードは「上位通信送信故障イベント」なる故障の発生を表している。従って、この場合には、第11行の直前までのコードである第10行のコードまでが、要点コード列として並べられる。つまり、この場合には、10個のコードを状態及びイベントの発生の検知順序に従って並べた要点コード列「S00、E10、E70、S00、S10、E50、S11、S20、E30、S22」が生成される。
このように、要点コード列は、状態及びイベントの発生の検知の順序を、当該状態及びイベントを表しているコードの並び順で表現している。一方、ログは、前述したように、検知の順序を、状態及びイベントの発生の検知日時の情報を当該コードに対応付けることによって表現している。従って、要点コード列は、ログよりもデータ量が少ない。
ここで、(A)のログで示されているコードについて、図7を用いて説明する。
図7において、(A)は、機器400の状態を表す状態コードの例を表しており、(B)は、機器400で発生したイベントを表すイベントコードの定義を表している。
図7の(A)で表されているように、本実施形態では、機器400の状態として、「初期化中」状態、「待機」状態、「MT制御」状態、及び「停止制御」状態の4つの状態が定義されている。また、図7の(B)で表されているように、機器400で発生するイベントとして、「通常イベント」が7つ、「故障イベント」が2つ、それぞれ定義されており、これら9個のイベントに対して1つずつイベントコードが割り当てられている。
本実施形態において、「SW押下」(機器400が備えているスイッチ(不図示)が押下される)及び「MT起動」(モータ401を起動させる)のイベントは、何らかの処理の途中の機器400の状態を遷移させることがある通常イベントである。なお、図7の(B)で表されているように、「SW押下」イベントにはイベントコード「E50」が割り当てられており、「MT起動」イベントにはイベントコード「E30」が割り当てられている。
図7の(A)の状態コードの例について更に説明する。
まず、「初期化中」状態について説明すると、「S00」、「S01」、及び「S02」は、いずれも機器400が「初期化中」状態にあることを表している。
このうち、「S00」は、「初期化中」状態の処理中を表している。機器400は、この状態において、「初期化中」の処理が完了して「処理終了」イベント(イベントコード「E70」)が発生した場合には、状態が「初期化中」から「待機」へと遷移して、状態コード「S10」で表される「待機」状態の処理中の状態となることを表している。
「S01」及び「S02」は、それぞれ、機器400において「SW押下」イベント及び「MT起動」イベントが発生したときの「初期化中」状態を便宜上表している。但し、実際には、「初期化中」状態の機器400においてこれらのイベントが発生しても状態が遷移することはない。
次に、「待機」状態について説明すると、「S10」、「S11」、及び「S12」は、いずれも機器400が「待機」状態にあることを表している。
このうち、「S10」は「待機」状態の処理中を表している。
また、「S11」は「待機」状態の機器400において「SW押下」イベントが発生したことを表している。このとき、機器400は、状態が「待機」から「MT制御」へと遷移して、状態コード「S20」で表される「MT制御」状態の処理中の状態となることを表している。
「S12」は、機器400において「MT起動」イベントが発生したときの「待機」状態を便宜上表している。但し、実際には、「待機」状態の機器400においてこのイベントが発生しても状態が遷移することはない。
次に、「MT制御」状態について説明すると、「S20」、「S21」、及び「S22」は、いずれも機器400が「MT制御」状態にあることを表している。
このうち、「S20」は「MT制御」状態の処理中を表している。
また、「S22」は「MT制御」状態の機器400において「MT起動」イベントが発生したことを表している。このとき、機器400は、状態が「MT起動」から「停止制御」へと遷移して、状態コード「S30」で表される「停止制御」状態の処理中の状態となることを表している。
「S21」は、機器400において「SW押下」イベントが発生したときの「MT起動」状態を便宜上表している。但し、実際には、「MT起動」状態の機器400においてこのイベントが発生しても状態が遷移することはない。
次に、「停止制御」状態について説明すると、「S30」、「S31」、及び「S32」は、いずれも機器400が「停止制御」状態にあることを表している。
このうち、「S30」は「停止制御」状態の処理中を表している。
また、「S31」は「停止制御」状態の機器400において「SW押下」イベントが発生したことを表している。このとき、機器400は、状態コード「S30」で表される「停止制御」状態の処理中の状態となることを表している。なお、「S30」は「S31」と同一の「停止制御」状態を表しているので、この場合には機器400の状態は遷移しない。
「S32」は、機器400において「MT起動」イベントが発生したときの「停止制御」状態を便宜上表している。但し、実際には、「停止制御」状態の機器400においてこのイベントが発生しても状態が遷移することはない。
本実施形態において、状態コードは以上のように定義されている。
ここで、前述した要点コード列「S00、E10、E70、S00、S10、E50、S11、S20、E30、S22」に注目する。
この要点コード列において、第4番目に置かれている状態コード「S00」の1つ前の状態コードは、第1番目の「S00」である。つまり、第4番目の状態コードで表されている機器400の状態、すなわち、「初期化中」状態は、第1番目の状態コードで表されている状態から遷移していない。
また、この要点コード列において、第7番目に置かれている状態コード「S11」の1つ前の状態コードは、第5番目の「S10」である。つまり、第7番目の状態コードで表されている機器400の状態、すなわち、「待機」状態は、第5番目の状態コードで表されている状態から遷移していない。
同様に、この要点コード列において、第10番目に置かれている状態コード「S22」の1つ前の状態コードは、第8番目の「S20」である。つまり、第10番目の状態コードで表されている機器400の状態、すなわち、「MT制御」状態は、第8番目の状態コードで表されている状態から遷移していない。
要点コード列生成部513は、要点コード列を生成する際に、このような、時系列で1つ前の状態から遷移していない状態を表している状態コードを、要点コード列に含めないようにして、要点コード列のデータ量を更に少なくするようにしてもよい。すなわち、要点コード列生成部513は、要点コード列において状態コードにより表す機器400の状態を、ログの情報で表されている状態のうちで当該状態の1つ前の状態から遷移しているもののみとするようにしてもよい。図6の(B)に示されている要点コード列は、このようにして生成されたものであり、前述した要点コード列を構成している10個のコードのうちから、第4番目、第7番目、第10番目のコード「S00」、「S11」、「S22」が削除されて構成されている。
次に、機器管理システム200で行われる機器監視方法の詳細について、図8、図9、及び図10のフローチャートを参照しながら説明する。
図8は、複数の機器400の各々において行われる監視処理の処理内容を示している。
図8において、まず、S801では、ログを記録する処理が動作管理部402によって行われる。この処理により、動作管理部402は、機器400自身の状態を検知すると共に、機器400自身で発生したイベントを検知する。ここで、状態若しくはイベントの発生が検知される度に、動作管理部402は、検知した状態及び発生したイベントを表している情報を、当該状態の検知日時及び当該イベントの発生の検知日時をそれぞれ表している時間情報に対応付けて、機器400についてのログに追加してログ記憶部410に記憶し、処理をS802に進める。
次に、S802では、機器400での故障の発生を検知する処理が故障検知部411によって行われる。この処理により、故障検知部411は、ログ記憶部410に記憶されているログを参照して、所定の故障イベントに該当するイベントの発生がログに記録されたか否かを判定する。ここで、故障検知部411は、故障イベントに該当するイベントの発生がログに記録されたと判定した場合(判定結果がYesの場合)には、S803に処理を進める。一方、故障検知部411は、故障イベントに該当するイベントの発生がログに記録されていないと判定した場合(判定結果がNoの場合)には、S801へ処理を戻して、ログの記録の処理を動作管理部402に行わせる。
S803では、ログ記憶部410からログを取得する処理が行われ、続くS804では、取得したログを送信してサーバ500へ送る処理が行われる。このS803及びS804の処理はログ送信部412によって行われる。ログ送信部412は、故障検知部411によって発生が検知された故障イベントに該当するイベントまでの機器400についてのログをログ記憶部410から読み出して、サーバ500へ宛てて送信する。ログの送信後、ログ送信部412は図8の処理を終了させる。
図9は、サーバが行う処理の処理内容を示している。
図9において、まず、S901では、故障発生を検知した機器400についてのログを受信する処理がログ受信部511によって行われる。この処理により、ログ受信部511は、故障発生を検知した機器400において実行される図8のS804の送信処理によってサーバ500へ送信される、当該機器400についてのログの受信を試みる。
次に、S902では、故障発生を検知した機器400についてのログが、S901の処理によって受信されたか否かを判定する処理がログ受信部511によって行われる。ここで、ログ受信部511は、故障発生を検知した機器400についてのログが受信されたと判定した場合(判定結果がYesの場合)には、S903に処理を進める。一方、ログ受信部511は、ログが受信されないと判定した場合(判定結果がNoの場合)には、S901へ処理を戻し、以降、故障発生を検知した機器400についてのログが受信されるまでS901の処理とS902の処理とを繰り返す。
S903では、S901の処理によって受信されたログをログ記憶部501に記憶させる処理がログ受信部511によって行われる。この処理により、ログ受信部511は、受信したログに、当該ログの送信元である機器400を識別する情報を付して、ログ記憶部501に記憶させる。なお、機器400を識別する情報として、例えば、当該機器400に個別に与えられているシリアル番号(製造番号)が用いられる。
S904では、要点コード列を生成する処理がログ解析部512と要点コード列生成部513とによって行われる。
この処理では、まず、ログ解析部512が、S901の処理によって受信されたログを解析する。この解析において、ログ解析部512は、発生が検知された故障イベントに該当するイベントまでのログから、故障発生を検知した機器400の状態についてのログデータと、当該機器400で発生したイベントについてのログデータとを抽出する。更に、ログ解析部512は、抽出されたログデータが表している状態及びイベントの発生の検知の順序を、当該ログの時間情報に基づいて特定する。これらの解析結果は要点コード列生成部513に渡される。
要点コード列生成部513は、ログ解析部512による解析結果に基づいて要点コード列を生成する。このとき、要点コード列生成部513は、ログから抽出したログデータが表している状態及びイベントをそれぞれ示しているコードを、それらの検知の順序に従った並び順で前述したように並べることによって、要点コード列を生成する。
次に、S905では、S904の処理によって生成された要点コード列を要点コード列記憶部502に記憶させる処理が、要点コード列生成部513によって行われる。この処理により、要点コード列生成部513は、S901の処理によって受信されたログから生成した要点コード列に、当該ログの送信元である機器400を識別する情報を付して、要点コード列記憶部502に記憶させる。なお、機器400を識別する情報として、例えば、当該機器400に個別に与えられているシリアル番号(製造番号)が用いられる。
次に、S906では、要点コード列生成部513によって生成された要点コード列を複数の機器400のうちの1つへ配信する処理が要点コード列送信部514によって行われる。この処理により、要点コード列送信部514は、複数の機器400のうちから選択した、ログ受信部511が受信したログの送信元以外の機器400を宛先として、生成された要点コード列を送信する。
次に、S907では、要点コード列の送信先から送られてくる、アラーム判定の判定結果を受信する処理が、アラーム受信部521によって行われる。この処理により、アラーム受信部521は、S906の処理によって要点コード列送信部514が送信した要点コード列の宛先の機器400から送られてくる、当該送信した要点コード列に基づくアラーム判定の判定結果である、アラームの受信を試みる。
次に、S908では、アラーム判定の判定結果を受信したか否かを判定する処理がアラーム受信部521によって行われる。ここで、アラーム受信部521は、アラーム判定の判定結果を受信したと判定した場合(判定結果がYesの場合)には、S909に処理を進める。一方、アラーム受信部521は、アラーム判定の判定結果が受信されないと判定した場合(判定結果がNoの場合)には、S907へ処理を戻し、以降、アラーム判定の判定結果が受信されるまでS907の処理とS908の処理とを繰り返す。
次に、S909では、S906の処理である、要点コード列を配信する処理が、複数の機器400のうちの、ログ受信部511が受信したログの送信元以外の全てについて行われたか否かを判定する処理が要点コード列送信部514によって行われる。ここで、要点コード列送信部514は、要点コード列の配信が、複数の機器400のうちの、ログ受信部511が受信したログの送信元以外の全てについて行われたと判定した場合(判定結果がYesの場合)には、S910に処理を進める。一方、要点コード列送信部514は、複数の機器400のうちの、ログ受信部511が受信したログの送信元以外のいずれかに、要点コード列の配信を行っていないものが残されていると判定した場合(判定結果がNoの場合)には、S906へ処理を戻す。このようにして行われる処理の繰り返しにより、複数の機器400のうちの、ログ受信部511が受信したログの送信元以外の全てについて、要点コード列の配信及びアラーム判定の判定結果の受信が行われる。
S910では、S907の処理によってアラーム受信部521により受信されたアラームで表されている情報を、アラームの表示として、当該判定結果の送信元の機器400毎に表示する処理がアラーム表示部522によって行われる。その後、アラーム表示部522は、このアラーム表示を行った後に、図9の処理を終了させる。
図10は、複数の機器400の各々において行われる、アラーム判定処理の処理内容を示している。
図10において、まず、S1001では、サーバ500から配信される要点コード列を受信する処理が要点コード列受信部421によって行われる。この処理により、要点コード列受信部421は、図9のS906の処理によってサーバ500から配信される要点コード列の受信を試みる。
次に、S1002では、サーバ500から配信される要点コード列を、S1001の処理によって受信したか否かを判定する処理が要点コード列受信部421によって行われる。ここで、要点コード列受信部421は、要点コード列を受信したと判定した場合(判定結果がYesの場合)には、S1003に処理を進める。一方、要点コード列受信部421は、要点コード列が受信されないと判定した場合(判定結果がNoの場合)には、S1001へ処理を戻し、以降、サーバ500から配信される要点コード列を受信するまでS1001の処理とS1002の処理とを繰り返す。
S1003では、S1001の処理によって受信された要点コード列を記録しておく処理がアラーム判定部422によって行われる。
次に、S1004では、要点コード列とログデータとを比較する処理がアラーム判定部422によって行われる。この処理により、アラーム判定部422は、機器400自身についてのログをログ記憶部410から読み出して当該ログを参照し、記録した要点コード列と比較する。
次に、S1005では、アラームの判定処理がアラーム判定部422により行われる。この処理により、アラーム判定部422は、S1001の処理によって受信された要点コード列で表されている状態及びイベントの発生を、当該要点コード列で表されている検知の順序で検知していたことが、機器400自身についてのログに記録されているかどうかを判定する。この判定処理は、要点コード列に含まれている各コードが、要点コード列における各コードの並び順で、ログに記録されているか否かを判定するものに過ぎないので、機器400での処理負担が少なくて済む。
このS1005の判定処理において、そのような検知の記録がログに残されていた場合には、機器400自身において異常の発生の可能性があることをアラーム判定の判定結果とする。一方、そのような検知の記録がログにはない場合には、機器400自身において異常の発生の可能性がないことをアラーム判定の判定結果とする。
次に、S1006では、S1005のアラームの判定処理による判定結果を、アラームとしてサーバ500へ送信する処理が、アラーム送信部423によって行われる。この処理によって送信されたアラームで示される判定結果は、前述した図9のS907の処理によって、サーバ500により受信される。
次に、S1007では、S1005のアラームの判定処理による判定結果を機器400において表示する処理が、アラーム表示部424によって行われる。その後、アラーム表示部424は、このアラーム表示を行った後に、図10の処理を終了させる。
なお、本実施形態において、アラーム送信部423が送信する、機器400自身において異常の発生の可能性があるアラームを、機器400において異常の発生が検知されている場合と検知されていない場合とを識別可能なアラームとしてもよい。すなわち、図10のS1006の処理においてアラーム送信部423が送信するアラームとして、これより説明する、第1、第2、及び第3の3種類のアラームを定義しておいてもよい。
第1のアラームは、要点コード列受信部421が受信した要点コード列で表されている状態及びイベントの発生を、当該要点コード列で表されている検知の順序で検知していたことが、機器400自身についてのログに記録されており、且つ、機器400での故障の発生を故障検知部411が検知していた場合に送信されるアラームである。この第1のアラームは、3種類のアラームのうちで最も深刻な状況を表している。
また、第2のアラームは、要点コード列受信部421が受信した要点コード列で表されている状態及びイベントの発生を、当該要点コード列で表されている検知の順序で検知していたことが、機器400自身についてのログに記録されているものの、機器400での故障の発生を故障検知部411は検知していない場合に送信されるアラームである。この第2のアラームは、3種類のアラームのうち、第1のアラームの次に深刻な状況を表している。
そして、第3のアラームは、要点コード列受信部421が受信した要点コード列で表されている状態及びイベントの発生を、当該要点コード列で表されている検知の順序で検知していたことが、機器400自身についてのログには記録されていない場合に送信されるアラームである。
サーバ500では、これらの3種類のアラームのいずれかをアラーム受信部521が受信した場合には、アラーム表示部522は、アラームについての情報として、この3種類のアラームのうちのいずれを受信したかを示す情報を表示するようにする。このアラーム表示によりアラームの内容を認識した機器管理システム200の管理者は、サービスマンに指示を与えて、アラームが示している状況に応じた対策を実施させる。
例えば、最も深刻な状況を表している第1のアラームの送信元の機器400については、故障の修理を直ちに実施(緊急修理)して機器400の機能を速やかに回復させる。また、例えば、第2のアラームの送信元の機器400については、未だ故障にまでは至っていないので、例えば、故障が発生した機器400cにおける故障の原因となったものと同一の部品の交換を、例えば毎日実施する始業前の点検時に行う(定期外保守)ようにする。また、例えば、第3のアラームの送信元の機器400については、故障が発生した機器400cと同一の故障が発生する可能性は低いと判断し、機器400cにおける故障の原因となったものと同一の部品の交換を、例えば1週間毎に実施する定期点検時に行う(定期保守)ようにする。
このようにすることで、機器管理システム200の正常運用のための機器400の保守・修理の作業負担を軽減することができる。
なお、上記の3種類のアラームのうちの第1若しくは第2のアラームをアラーム送信部423が送信する場合には、機器400のログ送信部412が、ログ記憶部410に記憶されている機器400のログを、併せてサーバ500へ送信するようにしてもよい。このようにすることで、機器400のログについてのサーバ500側での更なる詳細な解析が可能になり、故障発生の予測の精度向上や、より的確な対策の実施が可能になる。
次に図11について説明する。図11は情報処理装置のハードウェア構成例を示している。
図11の情報処理装置1100は機器400に備えられる。また、情報処理装置1100はサーバ500として利用することができる。
情報処理装置1100は、プロセッサ1101が、メモリ1102、補助記憶装置1103、通信インタフェース1104、入力装置1105、及び出力装置1106の各構成要素と、バス1107を介して相互に接続されて構成されている。
プロセッサ1101は、補助記憶装置1103に予め記憶されている制御プログラムをメモリ1102に展開して実行することによって、メモリ1102、補助記憶装置1103、通信インタフェース1104、入力装置1105、及び出力装置1106を制御する。
メモリ1102は、例えば、Random Access Memory(RAM)である。補助記憶装置1103は、種々の情報を記憶する記憶装置であり、例えばハードディスクドライブや半導体メモリ等が適用されてもよい。
通信インタフェース1104は、通信ネットワークに接続され、通信に伴うデータ変換等を行う。なお、この情報処理装置1100を機器400が備える場合には、通信インタフェース1104は、更に、不図示のモータコントローラを介してモータ401にも接続され、モータ401の動作制御及び動作状態の検知のためのデータ交換も行う。
入力装置1105は、例えば、スイッチ、キーボード、ポインティングデバイス等であり、ユーザからの指示及び情報等の入力を受け付ける。
出力装置1106は、例えば、表示装置であり、ユーザへの問い合わせ又は指示、及び処理結果等を出力する。
情報処理装置1100を機器400が備える場合には、プロセッサ1101は、補助記憶装置1103に記憶されている制御プログラムを実行することによって、図11の各構成要素を制御して、図8及び図10のフローチャートで表されているものを含む各種処理を行う。この処理を行うことによって、プロセッサ1101が、図4の構成要素のうちの動作管理部402、故障検知部411、ログ送信部412、要点コード列受信部421、アラーム判定部422、アラーム送信部423、及びアラーム表示部424として機能する。なお、このとき、補助記憶装置1103は、ログ記憶部410として機能する。
また、情報処理装置1100をサーバ500として利用する場合には、プロセッサ1101は、補助記憶装置1103に記憶されている制御プログラムを実行することによって、図11の各構成要素を制御して、図9のフローチャートで表されているものを含む各種処理を行う。この処理を行うことによって、プロセッサ1101が、図5の構成要素のうちのログ受信部511、ログ解析部512、要点コード列生成部513、要点コード列送信部514、アラーム受信部521、及びアラーム表示部522として機能する。なお、このとき、補助記憶装置1103は、ログ記憶部501及び要点コード列記憶部502として機能する。
開示の実施形態とその利点について詳しく説明したが、当業者は、特許請求の範囲に明確に記載した本発明の範囲から逸脱することなく、様々な変更、追加、省略をすることができるであろう。