JP5534313B2 - 取引処理装置の予防保守システム及び予防保守サーバ - Google Patents

Description

本発明は取引処理装置の予防保守システム及び予防保守サーバに関し、例えば、自動取引装置（ＡＴＭ）、自動支払機（ＣＤ）、記帳専用機（ＡＰ）等の予防保守に適用し得るものである。

従来、ＡＴＭ、ＣＤ、ＡＰなどの取引処理装置に対しては、非定期的な点検を前提とした予防保守が適用されている。ここで、「予防保守」とは、取引処理装置から収集した、予防保守ログに基づいて、装置の故障につながる要因を事前に検出し、保守内容と保守期限を定めて、装置の故障前に計画的にメンテナンスを施し、機器の安定稼動を図るための保守運用である。このような予防保守を確実に実施することで、装置の故障を発生させることなく、安定した装置の稼動を実現させることができる。

このような予防保守方法を記載している文献として、特許文献１及び特許文献２を挙げることができる。

特許文献１には、保守データを収集したときに、今回収集の保守データ、前回収集の保守データ及び基準データに基づいて、各点検項目毎に、点検が必要か否かを判定すると共に、今回点検不要と判定された点検項目については、次回の最適な点検実施日を予測する現金取引装置が記載されている。

特許文献２には、取引処理装置の保守データをリモート保守サーバで収集し、予め設定した保守内容判定基準と比較して、実施すべき保守内容を決定し、次に、決定された保守内容を予め設定した保守員ランク判定基準と比較して、当該保守内容に応じた保守員のランクを決定し、そして、決定された保守内容および保守員ランクと、交換部品、作業時間等を含む保守点検情報をリモート保守サーバの表示部に表示することが記載されている。

特開平７−２２０１４０号公報 特開２００３−２８１３６５号公報

特許文献１の記載技術では、現金取引装置が、自装置の次回の最適な点検実施日を予測するものであり、現金取引装置がそれぞれ、予防保守に係る点検実施日を予測するための処理プログラムや処理部を備えていなければならず、各装置が複雑、高価なものとなってしまう。

特許文献２の記載技術では、保守サーバが、取引処理装置の保守データを収集して、収集した取引処理装置の保守点検情報を得るようにしているので、各取引処理装置は、保守データを収集し、保守サーバに送信できる処理プログラムや処理部を備えていれば良く、予防保守に係る全ての処理プログラムや処理部を備えていなくて良いので、各装置を、特許文献１の記載技術に比較して、各装置を簡単、安価なものとすることができる。

しかしながら、特許文献２の記載技術は、保守サーバが保守点検情報を取引処理装置毎に得る予防保守方法であるため、以下のような課題を有するものであった。

第１に、その取引処理装置の予防保守作業に必要な保守員のランクを定めることはできても、各保守員から見て必要な情報を直ちに得ることができない。例えば、保守員が複数の保守作業を効率的に実行させることが可能な作業スケジュールを計画することはできず、作業スケジュールの策定には多大な工数が必要となっていた。

第２に、従来技術では、予防保守診断によって点検や保守作業が必要と判断されても、点検や保守作業が未実施であることを検出する手段がなかったため、その装置に対し、保守点検がなされないまま放置される可能性があった。例えば、保守契約によって、年間の保守点検回数の下限が定められている場合等において、既に、下限回数の点検がなされている場合には、このような放置される恐れは高くなる。

第３に、保守サーバ及び取引処理装置間のデータ転送に介在するネットワークの障害によって、収集ができなかったり、データエラーが発生して予防保守診断が誤ったりしたとしても、このような異常を早期に検知するための機構がなく、検知ができないか、管理者がそのことを認識するまでにかなりの時間がかかっていた。すなわち、ネットワーク障害による正しい予防保守診断及び予防保守が行えない事態を早期に認識することができなかった。

本発明は、以上の点を考慮してなされたものであり、予防保守の信頼性を高めた、取引処理装置の予防保守システム及び予防保守サーバを提供しようとしたものである。

第１の本発明は、予防保守サーバが定期的に予防保守対象の取引処理装置から保守作業の必要時期を判断可能な予防保守情報を収集する検針を行い、収集した予防保守情報を解析し、上記各取引処理装置について、所定期間以内に保守作業が必要なアラーム状態となったか否かを判別する取引処理装置の予防保守システムにおいて、上記予防保守サーバは、（１）上記各取引処理装置について、予め設定されている第１の回数の連続した検針で全てアラーム状態となった連続アラームが生じたか否かを判別する連続アラーム検出手段と、（２）連続アラームが生じた上記取引処理装置があれば、連続アラームが生じた上記取引処理装置の保守作業を含む作業依頼を作成する作業依頼作成手段と、（３）上記第１の回数より多い第２の回数の連続した検針で連続アラームが生じたことがない点検が必要な上記取引処理装置があるか否かを判別する点検アラーム検出手段と、（４）点検が必要な上記取引処理装置があれば、そのことを提示させる点検アラーム提示手段とを有することを特徴とする。
第２の本発明は、予防保守サーバが定期的に予防保守対象の取引処理装置から保守作業の必要時期を判断可能な予防保守情報を収集する検針を行い、収集した予防保守情報を解析し、上記各取引処理装置について、所定期間以内に保守作業が必要なアラーム状態となったか否かを判別する取引処理装置の予防保守システムにおいて、上記予防保守サーバは、（１）上記各取引処理装置について、予め設定されている第１の回数の連続した検針で全てアラーム状態となった連続アラームが生じたか否かを判別するものであって、上記検針で上記予防保守情報を収集できない検針異常があった場合には、アラームの連続回数を更新させずに維持させる連続アラーム検出手段と、（２）連続アラームが生じた上記取引処理装置があれば、連続アラームが生じた上記取引処理装置の保守作業を含む作業依頼を作成する作業依頼作成手段と、（３）予防保守情報を収集する上記検針で上記予防保守情報を収集できない検針異常の上記取引処理装置があれば、システム管理者若しくは保守員に係る端末に発報する検針異常発報手段とを有することを特徴とする。

第３の本発明は、定期的に予防保守対象の取引処理装置から保守作業の必要時期を判断可能な予防保守情報を収集する検針を行い、収集した予防保守情報を解析し、上記各取引処理装置について、所定期間以内に保守作業が必要なアラーム状態となったか否かを判別する予防保守サーバにおいて、（１）上記各取引処理装置について、予め設定されている第１の回数の連続した検針で全てアラーム状態となった連続アラームが生じたか否かを判別する連続アラーム検出手段と、（２）連続アラームが生じた上記取引処理装置があれば、連続アラームが生じた上記取引処理装置の保守作業を含む作業依頼を作成する作業依頼作成手段と、（３）上記第１の回数より多い第２の回数の連続した検針で連続アラームが生じたことがない点検が必要な上記取引処理装置があるか否かを判別する点検アラーム検出手段と、（４）点検が必要な上記取引処理装置があれば、そのことを提示させる点検アラーム提示手段とを有することを特徴とする。
第４の本発明は、定期的に予防保守対象の取引処理装置から保守作業の必要時期を判断可能な予防保守情報を収集する検針を行い、収集した予防保守情報を解析し、上記各取引処理装置について、所定期間以内に保守作業が必要なアラーム状態となったか否かを判別する予防保守サーバにおいて、（１）上記各取引処理装置について、予め設定されている第１の回数の連続した検針で全てアラーム状態となった連続アラームが生じたか否かを判別するものであって、上記検針で上記予防保守情報を収集できない検針異常があった場合には、アラームの連続回数を更新させずに維持させる連続アラーム検出手段と、（２）連続アラームが生じた上記取引処理装置があれば、連続アラームが生じた上記取引処理装置の保守作業を含む作業依頼を作成する作業依頼作成手段と、（３）予防保守情報を収集する上記検針で上記予防保守情報を収集できない検針異常の上記取引処理装置があれば、システム管理者若しくは保守員に係る端末に発報する検針異常発報手段と
を有することを特徴とする。

本発明によれば、予防保守の信頼性を高めることができる。

第１の実施形態による取引処理装置の予防保守システムの構成を示すブロック図である。 第１の実施形態の予防保守システムにおける検診動作の流れを示す説明図である。 図２の検診動作で収集した予防保守ログの診断結果例と、診断結果がアラーム、プレアラームの部品や項目に対して必要な作業内容とを示す説明図である。 第１の実施形態の予防保守システムにおける作業内容診断動作及び作業管理動作の流れを示す説明図である。 第１の実施形態の予防保守システムにおける保守サーバ内のデータベースで管理されるＡＴＭ単位のアラーム履歴や判定結果の一例を示す説明図である。 図４のステップＳ２２及びＳ２３の処理の詳細例を示すフローチャートである。 第１の実施形態の予防保守システムにおけるついで点検の作業依頼の作成動作を示すフローチャートである。 第２の実施形態の予防保守システムにおいて「収集ＮＧ」の連続によりシステム管理者に通知する処理部分を示す部分的なフローチャートである。

（Ａ）第１の実施形態
以下、本発明による取引処理装置の予防保守システム及び予防保守サーバの第１の実施形態を、図面を参照しながら説明する。

（Ａ−１）用語の説明
まず、第１の実施形態の説明で用いる用語の定義を説明する。ここで、説明する用語は、従来技術でも適用されていた用語だけでなく、第１の実施形態で新規に定義した用語も含まれている。

（Ａ−１−１）「予防保守」とは、上述したように、取引処理装置の“予防保守ログ”を基に、装置の故障につながる要因を事前に検出し、保守内容と保守期限を自動抽出することで、装置の故障前に計画的にメンテナンスを施し、機器の安定稼動を図るための保守運用のことを指す。予防保守を確実に実施することで、装置の故障を発生させることなく、安定した稼動を実現させることができる。

また、予防保守は、従来主流であった“定期点検”（例えば、年４回など規定回数の保守点検を行うこと）とは異なり、保守作業が必要な時期に必要な場所を整備する“非定期点検”により、取引処理装置の稼働環境（設置場所や取引量）に応じたメンテナンス密度を実現すると共に、保守員の出動回数やメンテナンス時間の無駄を少なくする効果がある。

（Ａ−１−２）「予防保守ログ」は、（ｉ）寿命情報、（ii）リトライ情報、（iii）センサ情報、（iv）版数情報に分類される取引処理装置の各種内部情報の固まりのことを指す（後述する図３参照）。取引処理装置を構成するユニット毎に、交換、点検、清掃といった保守作業が可能な部品やセンサの単位で、各ユニット内のメモリ上に情報が蓄積され、上位からの検針指示により、各種予防保守情報を一つの固まりで取り出すことができる。この固まりを予防保守ログという。

（ｉ）寿命情報は、ユニット全体又は交換可能な部品単位の通電時間や動作回数などの累積カウンタを主体とする情報である。寿命情報は、交換時に０がセットされ、各部品の稼動状況によりカウントアップされ、ある基準値で交換時期の指標となる情報を指す。部品の磨耗や経年劣化、消耗品などの利用状況（寿命情報）を基に、正常動作が保証される基準内に、ユニット全体又は交換可能な部品を交換することで、装置の安定稼動を実現することができる。

（ii）例えば、磁気カードのストライプ情報の読取りリトライの頻度など、機器が停止しないまでも、異常兆候として検出可能な状態があり、リトライ情報は、そのような状態に関する情報である。リトライ情報は、例えば、１週間分の動作回数とリトライ回数からリトライ率を求め、リトライ率がある基準値を超えた場合に点検が必要な指標となる情報を指す。リトライ率を毎週確認し、連続して基準値を超える場合に該当箇所を点検整備することでリトライの発生要因を除去し、故障を未然に防ぐことで安定稼動を実現することができる。

（iii）センサ情報は、例えば、光学センサの発光電流値などにより、センサの汚れ具合を数値化し、基準値を超えた場合に、清掃の必要性の指標となる情報である。取引処理装置には、何百ものセンサがあり、センサの誤検知により装置障害を誘発させる危険がある。センサの正常動作を阻害する汚れなどの発生箇所と汚損レベルを事前に検知し、点検・清掃により除去することで安定稼動を実現することができる。

（iv）版数情報は、取引処理装置を構成する各種要素に係る版数や改訂などに係る詳細情報である。版数情報としては、例えば、ソフトウェア版数、ハードウェアを構成するユニットの有無、ファームウェア版数、シリアルナンバー、基板版数、メカ版数、リビジョン情報といった各種詳細情報を適用する。条件に該当しない版数などの情報が含まれる場合、不都合を修正したパッチなどの適用漏れ等の異常を検出することが可能になる。構成不備の異常を早期に検知し、修正することで機器の正常稼動を実現することができる。

（Ａ−１−３）上述した寿命情報、リトライ情報、センサ情報及び版数情報を含む予防保守ログを定期的に取引処理装置から収集し、基準値を超える項目を検出（予防保守診断）するシステム動作を「検針」と呼ぶ。検針には、基準値を超える項目の超過レベル毎にアラーム、プレアラームといった段階的な指標で超過を検出する仕組みがある。

各実施形態では、検針の実行周期を１週間毎とし、検針でのアラームが４週間連続して検知された場合に、次の検針日までに予防保守作業（交換、点検、清掃など）が必要になるように各基準値が設定されている。

（Ａ−１−３−１）「検針アラーム」は、特に混合しない場合は単に「アラーム」と記載する。「アラーム」は、検針により抽出された基準値を超過した処置が必要な予防保守項目の状態のうち、緊急度が高い状態を指す。各実施形態の場合、一律に、１ケ月以内に処置が必要なレベルの状態を指し、「アラーム」が４週間連続した場合に保守作業が必要な状態であることを確定するために用いる。

（Ａ−１−３−２）「検針プレアラーム」は、特に混合しない場合は単に「プレアラーム」と記載する。「検針プレアラーム」は、検針により抽出された基準値を超過した処置が必要な予防保守項目の状態のうち、緊急度が低い状態を指す。各実施形態の場合、一律に、６ケ月以内に処置が必要なレベルの状態を表し、保守作業時にアラームが発生した予防保守項目と同時にプレアラームが発生した予防保守項目を実施することにより、点検周期を効率化することができる。

（Ａ−１−４）「連続アラーム」は、検針によるアラームが規定週数（以下、「連続アラーム週数」と呼ぶ）だけ連続した場合にセットされる、保守作業実施の必要性を検知するための状態フラグである。例えば、検針の実行周期を１週間毎とし、連続アラーム週数を４週とした場合、４週連続して検針でアラームが検出された場合に「連続アラーム」を検出し、これをきっかけに保守作業を実施する。

（Ａ−１−５）「点検アラーム」は、検針による連続アラームが規定週数（以下、「点検アラーム週数」と呼ぶ）発生しなかった場合にセットされる、保守作業を促すための状態フラグである。例えば、点検アラーム週数を４０週とした場合に、４０週連続して連続アラームが発生していないときに「点検アラーム」を検出し、これをきっかけに保守作業を実施する。

（Ａ−１−６）「連続アラーム猶予日数」は、連続アラーム発生から保守作業実施期限までの日数を調整するためのパラメータである。「連続アラーム猶予日数」は、予防保守対象の取引処理装置を有する金融機関と保守サービス提供会社の契約内容、作業日の調整期間、設置場所までの移動時間などの条件に応じて、設定値が変更可能なものである。

（Ａ−１−７）「点検アラーム猶予日数」は、点検アラーム発生から保守作業実施期限までの日数を調整するためのパラメータである。上述した契約内容、作業日の調整期間、設置場所までの移動時間などの条件に応じて、設定値が変更可能なものである。

（Ａ−１−８）「保守作業実施期限」は、各実施形態のシステムが定める保守員の保守作業の実施期限である。ここでは、特に区別の必要がない場合は、「ＥＴＡ：Ｅｓｔｉｍａｔｅｄ Ｔｉｍｅ ｏｆ Ａｒｒｉｖａｌ（到着予定時刻）」と同意とし、略して使用する場合がある。

（Ａ−１−９）「作業依頼番号」は、アラーム、連続アラーム、点検アラームの発生により、保守員に作業を依頼する際に用いるシステム間で一意に採番される番号であり、後述する保守サーバで採番し、そのデータベース（ＤＢ）に作業依頼内容とセットで記憶されるものである。

アラームの初回発生時に後述する保守サーバによって「作業依頼番号」が採番され、この番号をキーに後述する作業管理システムに作業依頼内容を「追加」（依頼状態は「予約」）する。

アラームが解除された場合には、後述する保守サーバは、作業依頼番号をキーに後述する作業管理システムに対して作業依頼内容を「キャンセル」（依頼状態は「取消」）する。

アラームが連続して発生する度に、後述する保守サーバは、作業依頼番号をキーに後述する作業管理システムに対して作業依頼内容を「更新」（依頼状態は「予約」のまま）する。

連続アラームや点検アラームを検出したとき、後述する保守サーバは、作業依頼番号をキーに後述する作業管理システムに対して作業依頼内容を「更新」（依頼状態は「確定」）し、保守員を出動させる。

（Ａ−１−１０）「作業依頼内容」は、後述する保守サーバが内蔵する作業内容診断機能により作成する、後述する作業管理システムが保守員に対して保守作業指示を行うために必要となる情報である。「作業依頼内容」には、（ｉ）作業依頼番号、（ii）依頼状態（追加／更新／キャンセル、及び、予約／確定／取消）、（iii）機器情報（顧客番号、店番、機番など機器を特定する情報）、（iv）保守作業実施期限（ＥＴＡ）、（ｖ）必要な作業内容（アラーム、プレアラームの検出箇所に必要な保守作業内容）、(vi)その他補足情報（標準作業時間、詳細を確認するためのＵＲＬなどの情報）が含まれている。

（Ａ−１−１１）「ついで点検」は、１人の保守員に対して、「確定」状態の作業と同時に、「予約」状態の作業依頼の取引処理装置が同一設置場所又は近隣にある場合に、“ついで”に作業を行うように指示し、出動回数や移動時間の無駄を最小にする効率的な保守点検を実施することをいう。

（Ａ−２）第１の実施形態の構成
図１は、第１の実施形態による取引処理装置の予防保守システムの構成を示すブロック図である。

図１において、第１の実施形態の予防保守システム２０は、複数の営業店舗２のシステム（以下、営業店舗のシステムをも営業店舗と呼ぶことがある）、集中監視センタ４のシステム（以下、集中監視センタのシステムをも集中監視センタと呼ぶことがある）、複数の保守拠点９のシステム（以下、保守拠点のシステムをも保守拠点と呼ぶことがある）、複数の携帯デバイス１２ａを有している。

営業店舗２は、有人、無人を問わず、予防保守対象の取引処理装置１を有する施設を意味している。以下では、取引処理装置１がＡＴＭであるとして説明を行う。例えば、空港やデパートや駅などに設けられている、ＡＴＭ１を有する無人店舗や無人のボックスも営業店舗２の範疇に属する。図１では、１つの営業店舗２には１つのＡＴＭ１を示しているが、１つの営業店舗２に複数のＡＴＭ１が設けられていても良いことは勿論である。ＡＴＭ１は、動作状況に応じて予防保守ログ１ａを逐次更新して保管している。予防保守ログ１ａには、上述した寿命情報、リトライ情報、センサ情報、版数情報に分類される、予防保守診断に必要な情報が記録されている。ＡＴＭ１は、ネットワーク３を介して、集中監視センタ４と接続されており、保管している予防保守ログ１ａを集中監視センタ４へ与えることができる。

ネットワーク３の種類は問われないが、例えば、営業店舗２を設置している金融機関に係る専用ネットワークを適用できる。図１における記号「Ｒ」は、ＡＴＭ１と集中監視センタ４との経路設定機能を担当しているルータを表している。

集中監視センタ４は、保守端末５、保守サーバ６、Ｗｅｂサーバ７及び作業管理システム１０を有する。保守端末５、保守サーバ６及びＷｅｂサーバ７は、第１のシステム内バスに接続されており、Ｗｅｂサーバ７及び作業管理システム１０は、第２のシステム内バスに接続されている。第２のシステム内バスには、ファイアウォール（ＦＷ）も接続されており、Ｗｅｂサーバ７や作業管理システム１０は、ファイアウォールを介して、インターネット等の広域ネットワーク８側とも接続し得る。

保守サーバ６は、ＡＴＭ１の保守情報を蓄積し、集計・診断し、データベース６ｃに格納するものであり、検針機能部６ａ、作業内容診断機能部６ｂ及びデータベース６ｃを有する。検針機能部６ａは、ＡＴＭ１の予防保守ログ１ａをスケジュール管理に基づき定期的に収集し、アラーム／プレアラームの発生有無を診断するものである。作業内容診断機能部６ｂは、検針機能部６ａによる診断結果を長期間蓄積して管理し、保守作業の必要な時期と作業内容を診断するものである。データベース６ｃは、各ＡＴＭ１についてそれぞれ、マスタ情報、収集スケジュール（例えば、予約日及び周期など、ＡＴＭ毎に異なっていても良い）、検針結果、作業診断結果を格納しているものである。なお、検針機能部６ａ及び作業内容診断機能部６ｂはそれぞれ、保守サーバ６に搭載されているＣＰＵ及びメモリでなる制御部が、搭載されている検診用プログラム、作業内容診断プログラムを実行することにより、割り当てられている機能を実現するものである。

保守端末５は、システム管理者１３が、集中監視センタ４内の保守サーバ６、Ｗｅｂサーバ７、作業管理システム１０に対して、各種情報を設定したり、その動作を手動操作したりする際に用いる端末であり、例えば、パソコンや、パソコンと同様なレベルの専用端末で構成されている。保守端末５は基準値入力手段５ａを備え、システム管理者１３は、この基準値入力手段５ａを用いて、保守サーバ６の検針機能部６ａ、作業診断機能部６ｂが検診や診断に用いる各種基準値を設定したり更新したりすることができる。基準値入力手段５ａは、保守端末５の入出力部と、ＣＰＵ及びメモリでなる制御部と、基準値入力用プログラムとから構成されている。

Ｗｅｂサーバ７は、後述するＷｅｂ端末１１や携帯デバイス１２ａなどのＷｅｂクライアントに対しＷｅｂページを提供するものである。Ｗｅｂサーバ７は、例えば、保守サーバ６が集計したＡＴＭの診断情報を取り出して診断情報提供用のＷｅｂページを構築して提供することができる。また、Ｗｅｂサーバ７は、例えば、作業管理システム１０が管理している、ある保守員１２の作業内容を、その保守員１２が確認するためのＷｅｂページを構築して提供することができ、また、そのＷｅｂページ上で更新された作業進捗状況を作業管理システム１０に通知することができる。

作業管理システム１０は、保守員１２に、後述するＷｅｂ端末１１や携帯デバイス１２ａを介して、作業を依頼し、保守員１２に作業内容を確認させたり、進捗状況を逐次更新させたりすることができるものである。作業管理システム１０は、保守サーバ６が作業内容診断機能部６ｂによって診断した作業内容を保守員１２に依頼し、保守員１２からの作業進捗状況の更新を受け付ける作業管理機能部１０ａと、それらの情報を記憶するデータベース１０ｂを有する。作業管理システム１０は、例えば、１又は複数台のコンピュータで構成されており、作業管理機能部１０ａは、コンピュータに搭載されているＣＰＵ及びメモリでなる制御部が、搭載されている作業管理プログラムを実行することにより、割り当てられている機能を実現するものである。

保守拠点９は、例えば、各都道府県毎等の地域単位に設けられているものであり、保守員１２の待機場所ともなり得るものである。保守拠点９には、Ｗｅｂブラウザが搭載された、例えば、パソコンなどでなるＷｅｂ端末１１が設けられている。Ｗｅｂ端末１１は、ファイアウォールを介して、インターネット等の広域ネットワーク８側とも接続し得るものであり、保守拠点９において、保守員１２が、Ｗｅｂページを介した通信により、保守サーバ６が集計したＡＴＭ１の診断情報を参照したり、作業管理システム１０で管理されている作業内容を確認したり、作業進捗状況を通知したりするものである。

携帯デバイス１２ａはそれぞれ、保守員１２が保守拠点９を出た際に所持するものである。携帯デバイス１２ａは、Ｗｅｂブラウザを搭載したスマートフォンやノートパソコンなどが該当する。携帯デバイス１２ａは、保守員１２が、Ｗｅｂページを介した通信により、保守サーバ６が集計したＡＴＭ１の診断情報を参照したり、作業管理システム１０で管理されている作業内容を確認したり、作業進捗状況を通知したりするものである。

（Ａ−３）第１の実施形態の動作
次に、以上のような各部からなる、第１の実施形態の予防保守システム２０における主要な動作を、検針動作、作業内容診断動作、作業管理動作の順に説明する。

（Ａ−３−１）検針動作
図２は、第１の実施形態の予防保守システム２０における検診動作の流れを示す説明図である。

ステップＳ１１：まず、予め保守端末５の基準値入力手段５ａにより、ＡＴＭ１毎に、検針の収集スケジュール情報及び各種診断のための基準値が入力され、保守サーバ６のデータベース６ｃに格納される。収集スケジュール情報は、例えば、初回の収集日（予約日）と、その後、定期的に収集するための周期情報（例えば、１週間）とでなる。

ステップＳ１２：保守サーバ６の検診機能部６ａは、その日がステップＳ１１で設定された予約日に該当するＡＴＭ１から、予防保守ログ１ａを収集する。収集できたか否かを別とし、予約日に収集動作を実行した場合には、その予約日から、入力された周期情報で規定された日数などを加算した日が新たな予約日となる。なお、収集ができない場合には、保守サーバ６が翌日に自動的にリトライしたり、システム管理者１３が手動で保守端末５から保守サーバ６による収集動作を起動したりなどして、次の予約日までに予防保守ログ１ａを収集する。また、収集動作を行う時刻は任意であって良い。例えば、ＡＴＭ１を利用者が取り扱うことができない時刻に設定しても良い。また例えば、ＡＴＭ１を利用者が取り扱うことができる時間帯の所定時刻であって、ＡＴＭ１を利用者が取り扱っていないことを確認して収集動作を行うようにしても良い（その時刻に取り扱っていた場合には、その利用者の一連の操作が終了したときに収集する）。

ステップＳ１３：保守サーバ６の検診機能部６ａは、収集が完了した予防保守ログ１ａを各診断単位に分解して解析し、基準値に基づき、正常、異常（アラーム、プレアラーム）を診断し、診断結果をデータベース６ｃに格納する。

ステップＳ１４：保守員１２は、データベース６ｃに格納された診断結果を、Ｗｅｂ端末１１から、Ｗｅｂサーバ７が提供するＷｅｂページ上で確認することができる。

図３（Ａ）〜（Ｄ）は、ステップＳ１３の診断による結果例を示す説明図である。なお、図３（Ｅ）には、診断結果がアラーム、プレアラームの部品や項目に対して必要な作業内容を示している。

図３（Ａ）は、データベース６ｃにおける「寿命情報」の格納構成例を示し、「寿命情報」の診断結果を含んでいる。この構成例では、あるユニット（図示のものは「紙幣入出金部」）を構成する交換部品毎に、前回の交換日（交換年月日）からの使用状況に基づいた診断がなされるものである。交換部品によっては、複数の判定項目（判定カウンタ）が診断に用いられる。例えば、「接客ユニット」は、「ステージモータ動作回数」、「プール回転モータ動作回数」、「ビルプレスモータ動作回数」の３つの判定項目を考慮して診断結果を得るものである。「カウンタ値」は、今回収集した予防保守ログでの値であり、交換基準値（交換基準）は、交換を実行させるカウンタ値の目安を与えている。「余命」は、前回の交換日から今回の収集日までのカウンタ値の増加量から、今回の収集日から見て、カウンタ値が交換基準値に達成するまでの予測時間を表している。図３（Ａ）の例では、「余命」を月数で表している。

第１の実施形態では、余命１ケ月以内でアラーム、６ケ月以内でプレアラームを検出する。アラームを１ケ月以内にするのは、４週連続アラーム発生時に「連続アラーム」を検出し、交換作業を保守員に指示できるためである。なお、１つの交換部品について複数の判定カウンタを設けた場合には、いずれか１つでもアラームになった場合にアラームと判断し、アラームがない場合においていずれか１つでもプレアラームになった場合にプレアラームと判断する。

図３（Ａ）の例では、交換部品「接客ピッカゴム」の判定カウンタ「前回交換からの経過日」が余命１カ月であるため、交換部品「接客ピッカゴム」の診断結果は「アラーム」となっている。

図３（Ｂ）は、データベース６ｃにおける「リトライ情報」の格納構成例を示し、「リトライ情報」の診断結果を含んでいる。この構成例では、あるユニット（図示のものは「カード読取印字部」）について１又は複数の点検項目が定められており、この点検項目毎に、診断がなされるものである。点検項目によっては、複数の判定項目（判定カウンタ）が診断に用いられる。例えば、「カード系清掃」は、「ＪＩＳ−ＩＩ磁気無リードエラー連続」、「ＪＩＳ−ＩＩ磁気無リードエラー発生頻度」、「ＪＩＳ−ＩＩリードエラー連続」の３つの判定項目を考慮して診断結果を得るものである。現在値として、「リトライカウンタ」、「動作カウンタ」、「リトライ率」があり、「リトライカウンタ」及び「動作カウンタ」は収集される値であり、「リトライ率」は、動作カウンタとリトライカウンタとから算出されるものである。診断に用いる基準値としては、「プレアラーム基準値」と「アラーム基準値」とがある。

リトライ率の現在値がプレアラーム基準値以上であればプレアラームを検出し、リトライ率の現在値がアラーム基準値以上であればアラームを検出する。なお、１つの点検項目について複数の判定カウンタを設けた場合には、いずれか１つでもアラームになった場合にアラームと判断し、アラームがない場合においていずれか１つでもプレアラームになった場合にプレアラームと判断する。

図３（Ｂ）の例では、点検項目「カード系清掃」の判定カウンタ「ＪＩＳ−ＩＩ磁気無リードエラー発生頻度」がプレアラーム基準値以上であるので、点検項目「カード系清掃」の診断結果は「プレアラーム」となっている。

図３（Ｃ）は、データベース６ｃにおける「センサ情報」の格納構成例を示し、「センサ情報」の診断結果（判定結果）を含んでいる。この構成例では、あるユニット（図示のものは「紙幣入出金部」）を構成するセンサ毎に診断がなされる。

センサの現在値（収集された値）がプレアラーム基準値以上であればプレアラームを検出し、リトライ率の現在値がアラーム基準値以上であればアラームを検出する。

図３（Ｃ）の例では、センサ「入金第１−Ｒ」の現在値がアラーム基準値以上であるのでアラームが検出され、センサ「ＲＪ集積残留Ｌ」の現在値がプレアラーム基準値以上であるのでプレアラームが検出されている。

図３（Ｄ）は、データベース６ｃにおける「版数情報」の格納構成例を示し、「版数情報」の診断結果を含んでいる。この構成例では、あるユニット（図示のものは「紙幣入出金部」）毎に、１又は複数の確認項目が定められており、各確認項目には１又は複数の確認項目詳細が定められている。例えば、確認項目「ファームウェア」には、「メイン」、「認識プログラム」、「認識データ１」などの確認項目詳細が定められている。

確認項目詳細毎に現在値が収集され、確認項目詳細の現在値が、アラーム基準値に相当するアラーム検出範囲内に位置している場合にアラームを検出する。なお、版数情報については、アラームのみが検出でき、プレアラームという段階は設けられていない。第１の実施形態とは異なるが、プレアラームという段階を設けるようにしても良い。例えば、搭載されている部品の版数が搭載が求められている版数と大きく異なる場合にアラームを検出し、両版数間の差が小さい場合にはプレアラームを検出するようにしても良い。

（Ａ−３−２）作業内容診断動作
次に、第１の実施形態の予防保守システム２０における作業内容診断動作を、図面を参照しながら説明する。

図４は、保守サーバ６の作業内容診断機能部６ｂによる作業内容診断動作の流れを示す説明図である。なお、図４は、保守サーバ６の作業管理システム１０による作業管理動作の流れをも示しているが、作業管理動作については後述する。

ステップＳ２１：まず、予め保守端末５の基準値入力手段５ａにより、連続アラーム週数、点検アラーム週数、連続アラーム猶予日数及び点検アラーム猶予日数がＡＴＭ１毎に入力され、保守サーバ６のデータベース６ｃに格納される。

ステップＳ２２：各ＡＴＭ１について、上述したステップＳ１１〜ステップＳ１３の処理で保守サーバ６のデータベース６ｃに格納されたアラームという診断結果を、検診動作の周期毎に履歴管理した情報に基づいて、検診動作の周期毎（若しくは検診動作の周期より短い周期毎）に、アラーム、連続アラーム、点検アラームのいずれであるかを判定する。この判定に用いる履歴管理情報におけるアラームは、ＡＴＭの部品や項目などの要素の１つでもアラームがあれば、「アラーム」と捉えたＡＴＭ１の全体について見たアラームである。前回の検針動作からの日数が検針動作の周期より短いときに次の検針動作が実行されるような場合（後述する変形実施形態の項参照）や、検針収集日（例えば、毎週金曜日）の設定が切り替えられることなどを考慮し、検診動作の周期（例えば１週間）より、アラーム、連続アラーム、点検アラームの判定周期（例えば１日）を短くしても良い。

ステップＳ２３：ステップＳ２２の判定結果から、作業依頼を作業管理システム１０に対して発行する。

図５は、保守サーバ６のデータベース６ｃで管理される、ＡＴＭ単位のアラーム履歴や判定結果の一例を示す説明図である。なお、図５において、あるＡＴＭ１についてのカウント開始日には「ハッチ」を付与している。カウント開始日は、連続アラームや点検アラームの判定の基準日であって、連続アラームや点検アラームが検出された場合には、検出された次の週の検針収集日が改めてカウント開始日になる。

保守員には、複数のＡＴＭが、自己が担当するものとして割り当てられており、図５に示すような管理情報は、保守員毎に、区別して管理されている。なお、保守員のグループで担当すべきＡＴＭを割り当てるようにしても良く、このようにした場合には、図５に示すような管理情報は、グループ毎に区別して管理されることとなる。

図５においては、「店番機番」、「設置場所」及び「機種」などの書誌情報によってＡＴＭ１を特定する。このように特定されたＡＴＭ１毎に、しかも、検針周期（例えば１週間）毎に履歴を管理する。データベース６ｃに履歴を保管する検針収集日は、「点検アラーム」を検出できるように、点検アラーム週数の基準値（例えば４０週）以上に亘った検針収集日である。

今回の検針収集日において、ＡＴＭ１に、何らアラームの部品や項目がない場合には、今回の検針日の状態フラグとして正常を表す「空白」が設定される。なお、「空白」に代え、「正常」を設定するようにしても良い。

今回の検針収集日において、ＡＴＭ１に、アラームの部品や項目があり、しかも、カウント開始日の週から見て、今回の検針収集日の週の「アラーム」を含めた「アラーム」の連続週が４週（連続アラーム週数）未満の場合には、今回の検針収集日の状態フラグとして「アラーム」が設定される。

今回の検針収集日において、ＡＴＭ１に、アラームの部品や項目があり、しかも、カウント開始日の週から見て、今回の検針収集日の週の「アラーム」を含めた「アラーム」の連続週が４週の場合には、今回の検針収集日の状態フラグとして「連続アラーム」が設定される。

今回の検針収集日の週を含め、カウント開始日から４０週（点検アラーム週数）連続して、「連続アラーム」も「点検アラーム」も発生していない場合には（言い換えると、「アラーム」や後述する「収集ＮＧ」は発生していても良い）、今回の検針収集日の状態フラグとして「点検アラーム」が設定される。「点検アラーム」の設定は「アラーム」の設定より優先されている。また、「点検アラーム」の設定は「収集ＮＧ」の設定より優先されている。

今回の検針収集の予約日を含む週のいずれの日も、予防保守ログが収集できなかった場合には、言い換えると、検針がトラブルにより実施できなかった場合には、今回の検針収集日の状態フラグとして「収集ＮＧ」が設定される。

図５において、店番機番が「１００００００４」、設置場所が「本店営業部」、機種が「Ａ」のＡＴＭ（図５の１行目のＡＴＭ）は、最新の検針収集日の５月１２日におけるアラームで４週連続してアラームが発生したので、５月１２日の状態フラグとして「連続アラーム」が設定される。

また、図５において、店番機番が「１００００００５」、設置場所が「本店営業部」、機種が「Ａ」のＡＴＭ（図５の３行目のＡＴＭ）は、最新の検針収集日の５月１２日におけるアラームで１０週連続してアラームが発生したが、４週目及び８週目に「連続アラーム」が書き込まれており、現在のカウント開始日からカウントすれば２週連続であるため、５月１２日の状態フラグとして単に「アラーム」が設定される。

さらに、図５において、店番機番が「１０００００１３」、設置場所が「ＡＡＡ店」、機種が「Ｂ」のＡＴＭ（図５の５行目のＡＴＭ）は、最新の検針収集日の５月１２日の週に検針を実行できなかったので、５月１２日の状態フラグとして「収集ＮＧ」が設定される。

図５に示す範囲では、５月１２日の検針収集日には、「点検アラーム」の条件を満たすＡＴＭは存在していない。但し、店番機番が「１０００００６７」、設置場所が「本店営業部」、機種が「Ａ」のＡＴＭ（図５の１７行目のＡＴＭ）は、検針収集日が５月５日のときには、その検針収集日で４０週連続して連続アラームも検針アラームも発生していないので、５月５日の状態フラグとして「検針アラーム」が設定される。

図６は、上述した図４のステップＳ２２及びＳ２３の処理の詳細例を示すフローチャートである。なお、図５に示す状態フラグの設定内容「空白（正常）」、「アラーム」、「点検アラーム」、「連続アラーム」、「収集ＮＧ」は、図６に示す処理により設定されるものである。また、図６は、１台のＡＴＭ１に対する処理を示しているが、検針動作が実行される全てのＡＴＭについて、図６の処理が実行される。

保守サーバ６（の作業内容診断機能部６ｂ）は、図６に示す処理を開始すると、カウント開始日からの状態フラグと、本日の収集結果とを取得する（ステップＳ２２１）。ここで、本日の収集結果として、そのＡＴＭ１の部品や項目などに「アラーム」が１つでもあれば「アラーム」ありと、ＡＴＭ１の全ての部品や項目などに「アラーム」がなければ「アラーム」なしと取得するものである。

次に、保守サーバ６は、本日の収集結果を判別して、移行先の処理を切り替える（ステップＳ２２２）。本日の収集結果が「アラームなし」の場合には前週までの状態をも参照して、移行先の処理を切り替え（ステップＳ２２３）、本日の収集結果が「アラームあり」の場合にも前週までの状態をも参照して、移行先の処理を切り替える（ステップＳ２２４）。ここで、例えば、前週までの状態を参照する場合において、「収集ＮＧ」の週はその週がなく、その前後の週が連続した週になっていると取り扱う。

本日の収集結果が「収集ＮＧ」の場合には、保守サーバ６は、作業依頼番号及び依頼状態を前週のままとし（変更なし）、状態フラグに「収集ＮＧ」を設定して、図６に示す一連の処理を終了する（ステップＳ２２５）。

本日の収集結果が、その日を含め、直前の４０週連続して「連続アラーム」も「点検アラーム」もないというものである場合には、保守サーバ６は、作業依頼番号を新規に発行し（採番し）、状態フラグに「点検アラーム」を設定し、依頼状態に「追加／確定」を設定する（ステップＳ２２６）。さらに、保守サーバ６は、保守作業実施期限（ＥＴＡ）に、翌週の検針収集日に点検アラーム猶予日数を足し込んだ日を設定し、カウント開始日を翌週に更新した後、後述するステップＳ２３５に移行する（ステップＳ２２７）。

本日の収集結果が「アラームなし」であって、前週の状態が、「正常」、「連続アラーム」、「点検アラーム」のいずれかである場合には、保守サーバ６は、作業依頼番号及び依頼状態をなくし、状態フラグに「正常（空白）」を設定して、図６に示す一連の処理を終了する（ステップＳ２２８）。

本日の収集結果が「アラームなし」であって、前週の状態が、「アラーム」の場合には、保守サーバ６は、作業依頼番号を前週のままとし、状態フラグに「正常（空白）」を設定し、依頼状態に「キャンセル／取消」を設定した後、後述するステップＳ２３５に移行する（ステップＳ２２９）。

本日の収集結果が「アラームあり」であって、前週の状態が、「正常」、「連続アラーム」、「点検アラーム」のいずれかである場合には、保守サーバ６は、作業依頼番号を新規に発行し（採番し）、状態フラグに「アラーム（連続１週）」を設定し、依頼状態に「追加／予約」を設定する（ステップＳ２３０）。さらに、保守サーバ６は、保守作業実施期限（ＥＴＡ）に、今回の検針収集日（本日）から４週間後の日に、点検アラーム猶予日数を足し込んだ日を設定した後、後述するステップＳ２３５に移行する（ステップＳ２３１）。

本日の収集結果が「アラームあり」であって、本日を含めた「アラーム」の連続週が２週又は３週の場合には、保守サーバ６は、作業依頼番号を前週のままとし、状態フラグを「アラーム（連続ｎ週）」（但し、ｎには本日を含めた「アラーム」の連続週の数が入る）に設定し、依頼状態に「更新／予約」を設定した後、後述するステップＳ２３５に移行する（ステップＳ２３２）。

本日の収集結果が「アラームあり」であって、本日を含めた「アラーム」の連続週が４週の場合には、保守サーバ６は、作業依頼番号を前週のままとし、状態フラグに「連続アラーム」を設定し、依頼状態に「更新／確定」を設定する（ステップＳ２３３）。さらに、保守サーバ６は、カウント開始日を翌週に更新した後、後述するステップＳ２３５に移行する（ステップＳ２３４）。

上述したステップＳ２２７、Ｓ２２８、Ｓ２２９、Ｓ２３１、Ｓ２３２又はＳ２３４の実行後に移行されるステップＳ２３５においては、作業管理システム１０に作業依頼を発行する。そして、図６に示す一連の処理を終了する。

ここで、作業管理システム１０に発行する作業依頼には、上述したように、作業依頼番号、依頼状態、機器情報、保守作業実施期限（ＥＴＡ）、必要な作業内容、その他補足情報（標準作業時間、詳細を確認するためのＵＲＬなどの情報）が含まれる。

上述した図３（Ｅ）は、必要な作業内容の説明図になっている。例えば、データベース６ｃには、部品や項目などアラームの検出単位毎に、プレアラームやアラームが検出された場合の作業内容を対応して格納しており、プレアラームやアラームが検出された検出単位に応じて、作業内容をデータベース６ｃから取り出す。各作業内容の要素にはそれぞれ標準作業時間も併せて格納されている。

「寿命情報」に係る図３（Ａ）に示すように、交換部品「接客ピッカゴム」にアラームが検出された場合には、その交換部品「接客ピッカゴム」を交換することが作業内容となる。「リトライ情報」に係る図３（Ｂ）に示すように、点検項目「カード系清掃」にプレアラームが検出された場合には、その点検項目「カード系清掃」を点検することが作業内容となる。「センサ情報」に係る図３（Ｃ）に示すように、センサ「入金第１−Ｒ」にアラームが検出され、センサ「ＲＪ集積残留Ｌ」にプレアラームが検出された場合には、これらセンサを清掃することが作業内容となる。「版数情報」に係る図３（Ｄ）に示すように、確認項目「ファームウェア」の確認項目詳細「認識プログラム」及び「認識データ１」にアラームが検出された場合には、「認識プログラム」及び「認識データ１」を確認することが作業内容となる。

図３（Ｅ）の例であれば、交換部品「接客ピッカゴム」の交換に要する標準作業時間、点検項目「カード系清掃」の点検に要する標準作業時間、センサ「入金第１−Ｒ」の清掃に要する標準作業時間、センサ「ＲＪ集積残留Ｌ」の清掃に要する標準作業時間、「認識プログラム」の確認に要する標準作業時間、及び、「認識データ１」の確認に要する標準作業時間を合計した合計標準作業時間が、作業依頼に盛り込まれる標準作業時間となる。

（Ａ−３−３）作業管理動作
次に、第１の実施形態の予防保守システム２０における作業管理動作を説明する。

上述した図４のステップＳ３１に示すように、保守員１２は、保守拠点９のＷｅｂ端末１１又は携帯デバイス１２ａからＷｅｂサーバ７のＷｅｂページにアクセスし、アラームの履歴管理を参照したり、作業依頼（作業内容を含む）を確認したり、作業の進捗状況を更新したりすることができる。複数のＷｅｂページがリンクされており、先頭のＷｅｂページなどに参照し得る情報を選択するアイコンやチェックボックスなどが設けられており、これらを利用した選択により、履歴管理情報や作業依頼のＷｅｂページが作成されて、保守員に提供なされるようになされている。例えば、作業依頼のＷｅｂページが、依頼作業の進捗状況を書き込んだりクリックしたり部分を有し、保守員が作業の進捗状況を更新することができるようになされている。アラームの履歴管理の参照が求められた場合には、例えば、図５に示すような表形式で履歴管理情報を表示出力させるようにしても良い。Ｗｅｂ端末１１からのアクセスの場合であれば、受信した履歴管理情報を印刷出力することも可能である。

作業管理システム１０の作業管理機能部１０ａは、保守サーバ６が発行した作業依頼をデータベース１０ｂに記録する。この記録時には、保守員１２に依頼が必要な作業内容毎に、作業進捗状況の欄を設け、当初は、作業進捗状況の欄に「依頼待ち」を格納する。また、作業管理システム１０の作業管理機能部１０ａは、作業内容が、保守部品の手配が必要なものであれば、図示しない在庫管理システムと協働して手配の調整を行う。保守部品の送付先は、保守員１２に対応付けられている保守拠点９とする。

保守員１２がアクセスしてきたときに、記録されている作業依頼に、依頼する作業がある場合には作業を依頼し、作業進捗状況の欄に「依頼済」を格納する。保守員１２は、作業依頼に含まれている作業の内容を実行し、実行したときには、Ｗｅｂサーバ７のＷｅｂページにアクセスし、作業進捗状況の欄を「処置の完了」に更新する。

作業管理システム１０の作業管理機能部１０ａは、保守員によって、保守作業実施期限（ＥＴＡ）内に処置の完了が入力されない場合には、保守員１２がアクセスしてきた際に保守員１２に対して、作業未完了の警告を発信し、作業の実施進捗状況の入力と作業の早期完了を促す。

作業管理システム１０の作業管理機能部１０ａは、基本的には、依頼状態が「確定」の作業依頼に係るＡＴＭに対し、作業依頼の作業内容を保守員１２に依頼する。また、このような作業依頼を作業員１２に行ったＡＴＭ１の近傍のＡＴＭ（例えば、同一営業店舗の他のＡＴＭや近隣の営業店舗のＡＴＭ；例えば、距離が所定距離以内のＡＴＭ、若しくは、移動時間が所定時間内のＡＴＭを近傍のＡＴＭと捉える）について、依頼状態が「予約」の作業依頼が発行されている場合には、その近傍ＡＴＭに対して「ついで点検」を保守員１２に指示する。

図７は、作業依頼を含むＷｅｂページの作成動作を示すフローチャートである。

作業管理システム１０の作業管理機能部１０ａは、依頼状態が「確定」の作業依頼に係るＡＴＭを全て検索し（ステップＳ３００）、検索された「確定」のＡＴＭのそれぞれに対し、保守員１２が、ついで点検が可能な近傍範囲にある依頼状態が「予約」の他のＡＴＭを検索し（ステップＳ３０１）、依頼状態が「確定」のＡＴＭについては「保守点検」を指示し、依頼状態が「予約」のＡＴＭについては「ついで点検」を指示するためのＷｅｂページのテンプレートを取り出し、そのテンプレートに検索されたＡＴＭの依頼情報を盛り込んで、保守員１２に提供するＷｅｂページを作成する（ステップＳ３０２）。

（Ａ−４）第１の実施形態の効果
第１の実施形態によれば、「アラーム」が４週間連続した「連続アラーム」の場合に保守作業を必要と判断するようにしたので、保守作業の必要性を適切に捉えることができる。

また、第１の実施形態によれば、検針の実行結果の履歴を管理し、ＡＴＭのアラーム状態が、アラーム、連続アラーム、点検アラームのいずれであるかを判定し、その判定結果に応じて、保守作業を行うことが「確定」で作業依頼を直ちにしなければならないＡＴＭと、保守作業が必要であるが現時点では作業を「予約」しておく程度でよいＡＴＭとを検出し、保守員１２に、「確定」のＡＴＭに対する保守作業を依頼する際に、そのＡＴＭの近傍の「予約」の他のＡＴＭに対する作業（「ついで点検」）をも併せて依頼するようにしたので、保守員の出動回数を極力抑えたスケジュールの作成を可能とすることができる。

なお、総作業時間や総移動時間や総移動距離などを最適化するように複数の箇所（や装置）での作業順序を定める作業順序の決定システムは、既に、多くのシステムが提案されており、このようなシステムを適用することにより、複数のＡＴＭ間での保守作業の順序をも自動的に決定して保守員に依頼することもでき、このようにした場合には、保守員が多くのＡＴＭに対する保守作業を効率的に実行することができる。

「アラーム」が４週間連続した「連続アラーム」の場合に保守作業を必要と判断するようにしているので、仮に「連続アラーム」の概念だけを導入した場合には、「アラーム」が間欠的に生じても、４週間連続しない状況が長時間継続したときには、保守作業の対象とはならない。しかし、第１の実施形態によれば、「点検アラーム」としてこのような長時間を検出できるようにしたので、ずっと保守点検されず、放置されるＡＴＭを排除し、必要期間内に必ず点検を行うことができるようになる。

また、連続アラームが検出された後の検針での状況によって、再度連続アラームを検出するようにしたので、作業依頼を繰り返し発行でき、保守作業が実行されない状況では、保守作業を促すことができる。

（Ｂ）第２の実施形態
次に、本発明による取引処理装置の予防保守システム及び予防保守サーバの第２の実施形態を説明する。

第２の実施形態の予防保守システムの全体構成も、第１の実施形態の説明で用いた図１で示すことができる。また、検針機能も、第１の実施形態と同様である。

第２の実施形態の予防保守システムは、システム管理者１３が収集ＮＧのＡＴＭを認識できる機能を、第１の実施形態に追加したものである。

第１に、保守サーバ６のデータベース６ｃの情報を、システム管理者１３がＷｅｂ端末１１や保守端末５から参照可能とする。アラームの履歴管理情報（図５参照）を参照することにより、システム管理者１３が収集ＮＧのＡＴＭを認識することができる。

システム管理者１３がＷｅｂ端末１１からアラームの履歴管理情報を参照する方法は、第１の実施形態で説明した保守員１２がＷｅｂ端末１１からアラームの履歴管理情報を参照する方法と同様である。保守端末５から参照する場合も、保守端末５に、参照する情報を選択するための初期画面を表示し、システム管理者１３がこの初期画面からアラームの履歴管理情報の参照を選択し、この選択情報を受信した保守サーバ６がデータベース６ｃからアラームの履歴管理情報を取り出して保守端末５に提供して表示させる。

例えば、図５のような履歴管理情報表を表示する際に、操作者が指示した状態を他の状態に区別して表示できる機能（例えば、表示色を変えたり、そこだけ点滅させたりする）を盛り込んでおく。この機能により、「収集ＮＧ」だけを容易に認識し得るようにしても良い。また、操作者が指示した状態を指示した検針収集日に有するＡＴＭの行を、他の行と区別して表示する機能を盛り込んでおくようにしても良い。

第２に、収集ＮＧが連続発生した場合、保守サーバ６からシステム管理者１３に対して電子メールなどで連絡し、システム管理者１３が収集ＮＧのＡＴＭを認識することができるようにする。この場合には、保守サーバ６に予めシステム管理者１３に係るメールアドレスを記憶しておくことを要する。

この場合、収集ＮＧの連続発生回数を管理するようにし、収集ＮＧの連続発生回数が基準回数（１回であっても良い）に達した場合に、システム管理者１３に発報する。発報を受けた場合、システム管理者１３は収集ＮＧの原因を究明し、保守端末５から手動で「検針」を実施させ、その翌日の自動検針（リトライ）の結果により正常に収集できて復旧したことを確認する。

ここで、収集ＮＧの連続は、週毎に行う検針での連続を問題とするようにしても良く、また、検針できないときに次の日に再検針する場合に、当初の検針と再検針とでの連続を問題とするようにしても良い。

次に、収集ＮＧの連続発生回数を管理して発報する方法を採用した場合に、第１の実施形態の説明で用いた図６のフローチャートから変更される内容を説明する。図８は、変更した部分を取り出して示すフローチャートである。

ステップＳ２２５において、状態フラグに「収集ＮＧ」を設定する際に、単に、「収集ＮＧ」を設定するのではなく、「収集ＮＧ（連続ｎ週）」のように連続した週の数をも盛り込む。ステップＳ２２５が終わったときに、一連の処理を終了させるのではなく、次の処理を行う。すなわち、設定された状態フラグ「収集ＮＧ（連続ｎ週）」における連続した週の数がシステム管理者１３に発報する連続週数に達したか否かを判別する（ステップＳ４００）。達していなければ、一連の処理を終了させる。一方、達していれば、システム管理者１３に係る電子メールアドレスを取り出し、そのアドレスへ、収集ＮＧが連続したＡＴＭの情報を通知するメールを発送した後（ステップＳ４０１）、一連の処理を終了させる。

第２の実施形態によっても、上述した第１の実施形態と同様な効果を奏することができる。さらに、第２の実施形態によれば、ネットワーク障害や検針の誤診断などの理由による検針異常を、システム管理者に通知するようにしたので、システム管理者が検針異常を認識することができ、早期に措置を講じることができる。その結果、運用に影響なく正しい検針を実施することが可能になる。

（Ｃ）他の実施形態
上記各実施形態の説明においても、種々変形実施形態に言及したが、さらに、以下に例示するような変形実施形態を挙げることができる。

上記各実施形態においては、予防保守対象の取引処理装置がＡＴＭである場合を示したが、これに加え、又は、これに代え、他の取引処理装置を予防保守対象とするようにしても良い。

上記各実施形態においては、連続アラームと判断するための週数や点検アラームと判断するための週数をシステム管理者が設定するものを示したが、保守者が、自己が管轄する範囲について設定できるようにしても良い。例えば、保守作業が込んでいる時期や季節には、連続アラーム週数や点検アラーム週数を長く設定し、保守作業がすいている時期や季節には、連続アラーム週数や点検アラーム週数を短く設定するようなこともできる。

また、連続アラーム週数や点検アラーム週数を取引処理装置の機種や稼働期間などによって、別個に設定できるようにしても良い。例えば、市場に投入された時期が古い取引処理装置に対して連続アラーム週数や点検アラーム週数を短く設定し、市場に投入された時期が新しい取引処理装置に対して連続アラーム週数や点検アラーム週数を長く設定するようにしても良い。

上記各実施形態の説明では、保守員毎に担当するＡＴＭが定まっているように説明したが、複数の保守員が属するグループ（例えば保守主管部門）毎に、ＡＴＭの割当を定めていても良く、この場合、例えば、作業依頼を該当するグループの作業管理者若しくは作業管理者の端末宛に発行し、作業管理者が担当保守員を割り当てるようにすれば良い。

第２の実施形態のように、「収集ＮＧ」の連続をシステム管理者に通知して措置させる場合、この通知を発行した際、点検アラームのカウント週数をクリアするようにしても良い。

第２の実施形態では、「収集ＮＧ」を検知したＡＴＭの次の検針日も、「正常」などの他の検知状態のＡＴＭの検針周期（毎週）と同じ周期に基づいて定めるものを示したが、「収集ＮＧ」を検知したＡＴＭの次の検針日までの期間を、「正常」などの他の検知状態のＡＴＭの検針周期（毎週）より短くし、「収集ＮＧ」の連続を迅速に捉えられるようにしても良い。例えば、「収集ＮＧ」のＡＴＭに対しては翌日に検針を行うようにしても良く、また、３時間後など、日単位よりも短い期間の経過後に検針を行うようにしても良い。

上記各実施形態では、依頼状態が「確定」の取引処理装置の近傍にある依頼状態が「予約」の取引処理装置を全て検索して「ついで点検」の対象としたものを示したが、「ついで点検」の対象となる取引処理装置の数などを制限するようにしても良い。例えば、依頼状態が「確定」の取引処理装置の数や、依頼状態が「確定」の取引処理装置の標準作業時間の総和時間などに応じて、「ついで点検」の対象となる取引処理装置の数や近傍の条件（距離）などを制限するようにしても良い。「ついで点検」の取引処理装置を絞り込む場合において、連続アラームに達していないがアラームの連続週数が多いものを優先して「ついで点検」の対象とするようにしても良い。

上記各実施形態では、保守員がアクセスして作業管理システムから作業依頼を取り出すものを示したが、作業管理システムが保守員のアクセスを待たずにＷｅｂ端末や携帯デバイスなどに作業依頼を発行するようにしても良い。

第２の実施形態では、「収集ＮＧ」の連続をシステム管理者１３に通知するものを示したが、これに加え、又は、これに代え、収集ＮＧの取引処理装置を担当することとなっている保守員に通知するようにしても良い。

１…自動取引装置（ＡＴＭ）、２…営業店舗、４…集中監視センタ、５…保守端末、５ａ…基準値入力手段、６…保守サーバ、６ａ…検針機能部、６ｂ…作業内容診断機能部、６ｃ…データベース、７…Ｗｅｂサーバ、９…保守拠点、１０…作業管理システム、１０ａ…作業管理機能部、１０ｂ…データベース、１１…Ｗｅｂ端末、１２…保守員、１２ａ…携帯デバイス、２０…予防保守システム。

Claims (8)

1. 予防保守サーバが定期的に予防保守対象の取引処理装置から保守作業の必要時期を判断可能な予防保守情報を収集する検針を行い、収集した予防保守情報を解析し、上記各取引処理装置について、所定期間以内に保守作業が必要なアラーム状態となったか否かを判別する取引処理装置の予防保守システムにおいて、
   上記予防保守サーバは、
   上記各取引処理装置について、予め設定されている第１の回数の連続した検針で全てアラーム状態となった連続アラームが生じたか否かを判別する連続アラーム検出手段と、
   連続アラームが生じた上記取引処理装置があれば、連続アラームが生じた上記取引処理装置の保守作業を含む作業依頼を作成する作業依頼作成手段と、
   上記第１の回数より多い第２の回数の連続した検針で連続アラームが生じたことがない点検が必要な上記取引処理装置があるか否かを判別する点検アラーム検出手段と、
   点検が必要な上記取引処理装置があれば、そのことを提示させる点検アラーム提示手段と
   を有することを特徴とする取引処理装置の予防保守システム。
2. 上記作業依頼作成手段は、連続アラームが生じた上記取引処理装置の近傍にアラーム状態の他の上記取引処理装置があれば、上記作業依頼に、アラーム状態の他の上記取引処理装置の保守作業をも含めることを特徴とする請求項１に記載の取引処理装置の予防保守システム。
3. 上記予防保守サーバは、予防保守情報を収集する上記検針で上記予防保守情報を収集できない検針異常の上記取引処理装置があれば、システム管理者若しくは保守員に係る端末に発報する検針異常発報手段をさらに有することを特徴とする請求項１又は２に記載の取引処理装置の予防保守システム。
4. 予防保守サーバが定期的に予防保守対象の取引処理装置から保守作業の必要時期を判断可能な予防保守情報を収集する検針を行い、収集した予防保守情報を解析し、上記各取引処理装置について、所定期間以内に保守作業が必要なアラーム状態となったか否かを判別する取引処理装置の予防保守システムにおいて、
   上記予防保守サーバは、
   上記各取引処理装置について、予め設定されている第１の回数の連続した検針で全てアラーム状態となった連続アラームが生じたか否かを判別するものであって、上記検針で上記予防保守情報を収集できない検針異常があった場合には、アラームの連続回数を更新させずに維持させる連続アラーム検出手段と、
   連続アラームが生じた上記取引処理装置があれば、連続アラームが生じた上記取引処理装置の保守作業を含む作業依頼を作成する作業依頼作成手段と、
   予防保守情報を収集する上記検針で上記予防保守情報を収集できない検針異常の上記取引処理装置があれば、システム管理者若しくは保守員に係る端末に発報する検針異常発報手段と
   を有することを特徴とする取引処理装置の予防保守システム。
5. 定期的に予防保守対象の取引処理装置から保守作業の必要時期を判断可能な予防保守情報を収集する検針を行い、収集した予防保守情報を解析し、上記各取引処理装置について、所定期間以内に保守作業が必要なアラーム状態となったか否かを判別する予防保守サーバにおいて、
   上記各取引処理装置について、予め設定されている第１の回数の連続した検針で全てアラーム状態となった連続アラームが生じたか否かを判別する連続アラーム検出手段と、
   連続アラームが生じた上記取引処理装置があれば、連続アラームが生じた上記取引処理装置の保守作業を含む作業依頼を作成する作業依頼作成手段と、
   上記第１の回数より多い第２の回数の連続した検針で連続アラームが生じたことがない点検が必要な上記取引処理装置があるか否かを判別する点検アラーム検出手段と、
   点検が必要な上記取引処理装置があれば、そのことを提示させる点検アラーム提示手段と
   を有することを特徴とする予防保守サーバ。
6. 上記作業依頼作成手段は、連続アラームが生じた上記取引処理装置の近傍にアラーム状態の他の上記取引処理装置があれば、上記作業依頼に、アラーム状態の他の上記取引処理装置の保守作業をも含めることを特徴とする請求項５に記載の予防保守サーバ。
7. 予防保守情報を収集する上記検針で上記予防保守情報を収集できない検針異常の上記取引処理装置があれば、システム管理者若しくは保守員に係る端末に発報する検針異常発報手段をさらに有することを特徴とする請求項５又は６に記載の予防保守サーバ。
8. 定期的に予防保守対象の取引処理装置から保守作業の必要時期を判断可能な予防保守情報を収集する検針を行い、収集した予防保守情報を解析し、上記各取引処理装置について、所定期間以内に保守作業が必要なアラーム状態となったか否かを判別する予防保守サーバにおいて、
   上記各取引処理装置について、予め設定されている第１の回数の連続した検針で全てアラーム状態となった連続アラームが生じたか否かを判別するものであって、上記検針で上記予防保守情報を収集できない検針異常があった場合には、アラームの連続回数を更新させずに維持させる連続アラーム検出手段と、
   連続アラームが生じた上記取引処理装置があれば、連続アラームが生じた上記取引処理装置の保守作業を含む作業依頼を作成する作業依頼作成手段と、
   予防保守情報を収集する上記検針で上記予防保守情報を収集できない検針異常の上記取引処理装置があれば、システム管理者若しくは保守員に係る端末に発報する検針異常発報手段と
   を有することを特徴とする予防保守サーバ。

Images