JPH06309194A - 障害通知システム - Google Patents

Abstract

(57)【要約】 【構成】 パターンテーブル３には、障害のパターンに
対応した対策情報項目が示されている。保守履歴格納部
４には、各部の保守履歴が格納されている。例えば、通
帳証書発行装置１１で何らかの障害が発生した場合、障
害検知部２は、その障害を検知して障害情報制御部１５
に通知する。これにより、障害情報制御部１５は、パタ
ーンテーブル３を参照し、その障害に対応した対策情報
項目を調べる。次に、調べた対策情報項目に対応した保
守履歴を保守履歴格納部４より取出し、これを出力す
る。 【効果】 従来のような故障処理票の記入が不要とな
り、オペレータの負担が軽減されると共に、サービス員
への障害発生に対する情報伝達も正確に行うことができ
る。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、主として金融機関の窓
口装置に用いられる情報処理装置の障害状況を、その対
策情報を含めて通知する障害通知システムに関する。

【０００２】

【従来の技術】金融機関等では、顧客との窓口業務に窓
口装置が用いられており、この窓口装置によって各種の
取引業務を行っている。また、窓口装置は、通帳証書発
行装置等を備えており、このような通帳証書発行装置を
用いることによって顧客への通帳発行や記帳等も行って
いる。

【０００３】図２は、このような窓口装置の処理を示す
フローチャートである。このフローチャートの処理は、
特に通帳証書発行装置に中心とした処理である。先ず、
金融機関の業務が開始されると、オペレータは通帳証書
発行装置のカセット登録処理を行う（ステップＳ１）。
このカセット登録処理とは、通帳証書発行装置内に備え
られた通帳や証書のカセットがどの種類のものであるか
を登録する処理である。その後、カセット内に通帳や証
書等の媒体を補充あるいは新規に格納し（ステップＳ
２）、開局処理、即ち、窓口装置を業務可能な状態とす
る（ステップＳ３）。

【０００４】窓口装置が起動すると、各種取引が行われ
（ステップＳ４、Ｓ５）、この取引が正常に行われてい
る場合は、そのままステップＳ４の取引処理が続行され
る。また、ステップＳ５において、業務時間の終了等で
あった場合は、閉局処理、即ち窓口装置としての業務を
終了し（ステップＳ６）、その後、１日の取引処理の集
計等の処理である精査処理を行い（ステップＳ７）、そ
の日の業務を終了する。

【０００５】一方、取引業務中、何らかの障害が発生し
た場合、窓口装置は、その障害発生をエラー表示として
ディスプレイに表示する（ステップＳ８）。これによ
り、オペレータは、その障害状況を故障処理票に記入す
ると共に（ステップＳ９）、故障要因を除去し（ステッ
プＳ１０）、窓口装置に設けられた復旧キーを押下する
（ステップＳ１１）。尚、ここで故障処理票とは、発生
した故障の状況をオペレータが記載するための用紙であ
る。また、ステップＳ１０の故障要因除去とは、例え
ば、発生した故障が通帳証書発行装置における通帳の行
数相違エラーであった場合、センサ清掃等の処理を行う
ことをいう。

【０００６】上記ステップＳ１１において、復旧キーが
押下されると電源が再投入され、故障回復処理、即ち、
窓口装置の初期化処理が行われる（ステップＳ１２）。
その後、窓口装置が正常に動作するか否かを判定し（ス
テップＳ１３）、正常に動作する場合はステップＳ４に
戻って取引を続行する。一方、初期化処理を行っても、
窓口装置が正常に動作しない場合は、オペレータによる
復旧処理は不可能であるため、その旨エラー表示を行っ
てシステムアベンド（システムダウン）とし（ステップ
Ｓ１４）、サービス員に連絡する。

【０００７】

【発明が解決しようとする課題】しかしながら、取引を
行っている途中で障害が発生した場合、その故障要因の
除去作業を行っている間は、顧客を待たせることになっ
てしまう。このため、オペレータは、顧客に対しての待
ち時間を出来るだけ短くするよう、例えば、上述した通
帳の行数相違エラーといった障害のように、その時点で
故障要因を完全に除去せずとも復旧できるものについて
は、直ちに運用を再開させるのが一般的である。

【０００８】その結果、サービス員への連絡や故障処理
票への記入は、顧客との取引が終了してから、あるいは
業務が終了してから行われることになるが、通常は故障
発生時からある程度時間が経過してしまっているため、
その時の故障状況を正確に記憶しておくことは困難であ
る。従って、サービス員に対して故障状況が曖昧に連絡
されたり、またはサービスコールをせずに済ましてしま
う場合もある。このようなことから、サービス員が適切
な処置を行うことができず、本来であれば、部品交換等
の処置で済む故障が、そのままの状態で運用が継続され
ることから、その部品を含む装置全体の交換でしか対処
できなくなってしまう等の致命的故障に至るといった問
題点を有していた。

【０００９】即ち、図２のフローチャートに沿って説明
すると、障害が発生した場合でもステップＳ９、１０の
処理が行われずに運用が継続されるため、やがては、ス
テップＳ１２の故障回復処理を行っても復旧できなくな
り、システムダウンに至り、その窓口装置での取引続行
が不可能になってしまうものであった。

【００１０】例えば、発生した障害が、上述した行数相
違エラーやページめくりエラーであった場合、その対処
方法として、行数エラーの場合は、センサ清掃や印字イ
ンクリボン交換を行う。また、ページめくりエラーの場
合は、ローラ清掃または駆動ローラベルト張り調整を行
う必要がある。しかしながら、通常はこのような処置を
せずに直ちに業務を再開してしまっていた。ところが、
このような障害は暫くの間はそのまま運用を続けていて
も支障は生じないが、ある一定期間内に適切な処理を施
さなければ、センサの破損やインクリボンの破れによる
印字ヘッドの破損、あるいは用紙ジャムによる駆動系メ
カ破損等を誘発し、最終的には故障部分を含むハード装
置全体の交換でしか対処できなくなってしまっていた。

【００１１】本発明は、上記従来の問題点を解決するた
めになされたもので、故障への対処が的確に行え、かつ
顧客へのサービス低下も抑えることのできる障害通知シ
ステムを提供することを目的とする。

【００１２】

【課題を解決するための手段】本発明の障害通知システ
ムは、情報処理装置の運用中に発生した障害状況を検知
する障害検知部と、前記情報処理装置で発生する障害の
パターンに対応した対策情報項目を示すパターンテーブ
ルと、前記情報処理装置における各部の保守履歴を格納
する保守履歴格納部と、前記障害検知部で障害が検知さ
れた場合、前記パターンテーブルに基づき、当該障害の
対策情報項目に対応した保守履歴を前記保守履歴格納部
から取出す障害情報制御部とを備えたことを特徴とする
ものである。

【００１３】

【作用】本発明の障害通知システムにおいては、例え
ば、通帳証書発行装置でページめくりエラー等が発生し
た場合、障害検知部はこの障害を検知すると、そのエラ
ーコード等を障害情報制御部に出力する。障害情報制御
部は、１日の業務が終了し、精査処理において、パター
ンテーブルを参照し、例えば、ページめくりエラー等の
障害に対応した対処方法や対策情報項目を抽出する。そ
して、その対策情報項目から対応する保守履歴を保守履
歴格納部から取出し、これを対処方法と共に表示および
印刷する。オペレータは、表示および印刷された内容に
基づきサービス員に連絡する。サービス員は、オペレー
タからの連絡内容に基づいて障害発生要因を推測し、必
要と思われる部品等を持って障害発生装置の場所に向か
う。そして、サービス員は障害要因の除去を行い、かつ
保守履歴の内容を更新する。

【００１４】

【実施例】以下、本発明の実施例を図面を用いて詳細に
説明する。図１は本発明の障害通知システムの実施例を
示すブロック図である。図のシステムは、金融機関の窓
口装置の場合を示しており、主制御部１、障害検知部
２、パターンテーブル３、保守履歴格納部４、障害履歴
格納部５、キーボード６、ディスプレイ７、プリンタ
８、ハードディスク装置（ＨＤＤ）９、フロッピディス
ク装置（ＦＤＤ）１０、通帳証書発行装置１１、回線制
御部１２、ランダム・アクセス・メモリ（ＲＡＭ）１
３、リード・オンリ・メモリ（ＲＯＭ）１４からなる。

【００１５】主制御部１は、窓口装置としての制御を司
るプロセッサであり、障害情報制御部１５を備えてい
る。この障害情報制御部１５は、障害検知部２で障害が
検知された場合、パターンテーブル３に記録されている
障害に対する対策情報に基づき、保守履歴格納部４の対
応する項目の保守履歴を出力する機能を有している。障
害検知部２は、通帳証書発行装置１１におけるハード故
障といった障害を検知する機能を有し、その障害発生を
エラーコードで主制御部１に送出するようになってい
る。パターンテーブル３は、窓口装置で発生する障害の
パターンに対応した対策情報項目を示すものであり、不
揮発性メモリあるいはＲＯＭ１４内に格納されている。

【００１６】図３、４はパターンテーブル３の内容を示
す図である。このパターンテーブル３は、障害発生のエ
ラーコードとそのエラーメッセージ、そして障害に対す
る要因、対処方法および対策情報項目とから構成されて
いる。例えば、通帳のＭＳ（磁気ストライプ）行数エラ
ーでは、その要因として、オペレータミスやセンサ不良
あるいは印字濃度が薄いといった項目があり、この要因
に対応してセンサ清掃やリボン交換といった対処方法が
ある。そして、この障害の場合は対策情報項目として、
前回のセンサ清掃日時やリボン交換日時といった項目が
記されている。

【００１７】保守履歴格納部４は、窓口装置における各
部の保守履歴を格納するものでハードディスク装置や不
揮発性メモリで構成されている。図５に、保守履歴格納
部４内に格納されている保守履歴を示す。この保守履歴
は、窓口装置におけるハード修理履歴表であり、ローラ
清掃やセンサ清掃といった処理が何回行われたか、また
その日時が情報として記録されている。

【００１８】再び、図１に戻って、障害履歴格納部５
は、窓口装置における障害発生および障害対策を履歴と
して格納するもので、その障害発生履歴として、エラー
コード毎に、発生時刻、該当する取引、取引ステータ
ス、オペレータを記憶する。また、障害対策履歴も、エ
ラーコード毎に対策日時と対策者を記憶する。図６は、
このような障害履歴とパターンテーブル３とを示す図で
ある。即ち、障害履歴格納部５には、図示のように、エ
ラーコード毎の障害発生履歴と、対策履歴が格納されて
いる。また、障害発生履歴において、詳細情報に記載さ
れる内容は取引ステータスの情報であり、この取引ステ
ータスとは該当する取引の処理において、どの段階で障
害が発生したかを示す情報である。

【００１９】キーボード６は、オペレータが各種の取引
等を行う場合に種々の入力を行うものである。ディスプ
レイ７は、取引処理時において、その処理結果等を表示
すると共に、障害発生時には、そのエラーメッセージを
表示したり、障害に対する対策情報画面を表示するため
に用いられるものである。また、プリンタ８は、ディス
プレイ７と同様に窓口装置の出力装置であり、取引処理
時の印刷や障害発生時の対策情報等を印刷するためのも
のである。

【００２０】ハードディスク装置９は、窓口装置におけ
る各種のデータやプログラム等を格納する外部記憶装置
であり、またフロッピディスクディスク装置１０も、外
部からのデータを窓口装置に読込む場合等に用いるため
の外部記憶装置である。通帳証書発行装置１１は、通帳
や証書の発行や記帳を行う装置であり、通帳格納部や搬
送部および印字部等から構成されている。回線制御部１
２は、通信回線を介して行う上位装置と通信制御を実行
する制御部である。

【００２１】また、ＲＡＭ１３は、窓口装置が実行する
プログラムやデータを一時格納したり、主制御部１の実
行するための作業領域を構成するメモリであり、ＲＯＭ
１４は、プログラム等が格納されている不揮発性のメモ
リである。

【００２２】次にこのように構成された障害通知システ
ムの動作について説明する。図７に、その動作フローチ
ャートを示す。図のフローチャートは、窓口装置が起動
され、取引業務を行っている状態からの動作を示してお
り、一点鎖線枠内の処理が本実施例の特徴点を示
すものである。

【００２３】各種の取引業務を実行中（ステップＳ
１）、ステップＳ２において障害検知部２が異常を検知
した場合、障害検知部２はその障害発生をエラーコード
として障害情報制御部１５に通知する。これにより、障
害情報制御部１５は、エラーコードから該当するエラー
メッセージを編集し、ディスプレイ７にエラーメッセー
ジを表示する（ステップＳ３）。また、障害情報制御部
１５は、その障害発生履歴を、エラーコード毎に記憶す
る（ステップＳ４）。尚、この障害発生履歴は上述した
ように、発生時刻、該当取引、取引ステータス、オペレ
ータといった項目に関する情報である。

【００２４】尚、上記ステップＳ３におけるエラー表示
によって、本来、オペレータは故障要因の除去を行う必
要があるが、従来の技術の項で説明したように、顧客を
待たせることができないため、オペレータは通常、用紙
ジャム等の場合以外は直ちに復旧キーを押下する（ステ
ップＳ５）。

【００２５】復旧キーの押下によって、故障回復処理
（所謂リセット処理）が行われ（ステップＳ６）、その
結果、正常に動作した場合は（ステップＳ７）、ステッ
プＳ１の取引業務に戻る。また、故障回復処理を行って
も、正常に動作しない場合は、システムアベンドとし
て、その旨のエラー表示を行い（ステップＳ８）、更
に、障害情報制御部１５は、障害履歴格納部５に格納さ
れている障害発生履歴に基づき、その障害発生状況と対
策情報とをディスプレイ７に出力すると共に、プリンタ
８でハードコピーを行う（ステップＳ９）。尚、この出
力状態は後で詳述する。

【００２６】上記ステップＳ２において、取引業務が正
常に行われ、業務終了処理として、閉局処理および精査
処理が行われると（ステップＳ１０、Ｓ１１）、障害情
報制御部１５は、その日の障害発生履歴に基づき、障害
発生状況と対策情報とを出力する（ステップＳ１２）。

【００２７】図８は、この障害発生状況の出力動作を示
すフローチャートである。先ず、障害情報制御部１５
は、その日における障害発生状況をディスプレイ７に表
示させる（ステップＳ１０１）。即ち、この障害発生状
況とは、例えば、ＭＳ行数エラーが何件、ページめくり
エラーが何件、といったように１日における各障害毎の
件数を一覧表として表示するものである。また、この表
示内容は、必要に応じてプリンタ８でハードコピーされ
る。これにより、オペレータは所望する障害発生状況の
詳細情報を表示させる（ステップＳ１０２）。例えば、
オペレータが選択した障害がページめくりエラーであっ
た場合、図示のように、ページめくりエラーの詳細情報
としてその発生時刻、取引名、詳細情報（取引ステータ
ス）、オペレータといった項目の一覧表が表示される。

【００２８】更に、障害情報制御部１５は、その障害に
対する対策情報をパターンテーブル３を参照することに
よって抽出し、これを表示する（ステップＳ１０３）。
例えば、ページめくりエラーでは、その対策情報項目と
して、ローラ清掃日時、ローラ押し付け力調整、ベルト
張り調整日時、ベルト交換日時といった項目があるた
め、障害情報制御部１５は、この対策情報項目に基づき
保守履歴格納部４から対応する保守履歴として各項目の
前回行った＜月：日：時刻＞を読出し、これを表示す
る。また、ステップＳ１０２の障害発生状況画面とステ
ップＳ１０３の対策情報画面の内容も、プリンタ８によ
ってハードコピーされる。これによってオペレータは、
上記ステップＳ１０２、Ｓ１０３のハードコピーした情
報を基にサービス員に連絡する。

【００２９】尚、図７のステップＳ９における障害発生
状況と対策情報との出力状態は、図８におけるステップ
Ｓ１０２とステップＳ１０３の情報である。

【００３０】サービス員は、上記のような障害発生状況
情報とその対策情報とを基に、窓口装置の保守を行う
（図７におけるステップＳ１３）。図９は、その動作を
説明するためのフローチャートである。先ず、サービス
員は、窓口装置のオペレータからの連絡を受けると、そ
の障害発生状況情報と対策情報（保守履歴）に基づき、
障害発生の原因を推測し、必要と思われる部品を持って
修理に向かう。例えば、前回のベルト交換日時からかな
りの日数が経過している場合は、ベルト交換が必要であ
ると推測し、これを持って修理に向かう。この場合、従
来は障害に対する原因の推測を行うことができなかった
ため、全ての部品を持って修理に向かう必要があったの
に対し、本実施例では、修理に最低必要な部品のみを持
って向かえばよいことになる。

【００３１】そして、サービス員は、窓口装置の修理を
行い（ステップＳ１０４）、修理が終了すると、ディス
プレイ７に対策情報画面を表示させ、修理した項目の＜
月：日：時刻＞を更新（入力）する（ステップＳ１０
５）。例えば、ローラ清掃を行った場合は、その日時を
更新する。尚、障害内容によって、部品レベルでの修理
では対処できない場合は、装置ごとの交換となる。この
場合は、障害発生装置を、装置の設計部門に送付し、総
検査を実施する。

【００３２】サービス員による修理が終了すると、障害
情報制御部１５は、障害履歴格納部５における対策履歴
として、対策日時と対策者（通常はサービス員）の情報
を記録すると共に、保守履歴格納部４に格納されている
修理履歴表の該当項目の日時を入力し、新たな保守履歴
とする。また、この保守履歴は、必要に応じてプリンタ
８で出力する（ステップＳ１０６）。即ち、図５の内容
をプリントアウトする。

【００３３】これにより、サービス員は、出力された保
守履歴によって、何時どのような対処がなされていた
か、装置毎のハード障害履歴を判断できるため、定期点
検時の予防保全情報として活用することができ、また、
次回の修理においても的確な判断が行える。更に、各部
品の交換頻度等も分かるため、部品毎の予備品の個数を
どの程度ストックしておけばよいかといった予測も的確
に立てることができる。即ち、従来は装置毎の各部品の
交換頻度等は分からなかったため、余裕をみて各部品の
在庫を行っていたが、本実施例では、この余裕のための
部品を少なくすることができる。

【００３４】以上のように、上記実施例では、障害発生
履歴として取引ステータスといった詳細な情報まで記録
するため、従来のような故障処理票の記入が不要とな
り、オペレータの負担を軽減することができる。また、
障害発生時における故障処理票の記入もれやサービス員
に連絡する障害発生情報の曖昧さがなくなり、サービス
員も的確な修理を行うことができる。しかも、故障処理
票の記入が不要であることから、障害発生時でも速やか
な再立上げが可能となり、顧客へのサービス低下を防ぐ
ことができる。

【００３５】また、障害発生時には必ず的確な対処が施
されるため、ハード装置そのもの交換といった致命的な
障害にまで至ることを予防することができ、その結果、
業務中での障害発生によるシステムアベンドに至ること
が殆どなく、金融機関の業務中での顧客への迷惑を最小
限に抑えることができる。更に、サービス側も、保守履
歴により必要な部品の傾向が分かるため、余分な予備部
品を在庫しておく必要がない。

【００３６】尚、上記実施例では、障害の例として装置
のハード障害の場合を説明したが、これに限定されるも
のではなく、例えば主制御部１が実行するプログラム上
のバグ等により発生する障害に対しても適用することが
可能である。また、障害発生装置として、窓口装置だけ
ではなく、自動取引装置等であっても上記実施例と同様
の効果を奏することができる。

【００３７】

【発明の効果】以上説明したように、本発明の障害通知
システムによれば、障害に対する対策情報項目を示すパ
ターンテーブルと、各部の保守履歴とを備え、障害を検
知した場合は、パターンテーブルに基づき、その障害の
対策項目を判定し、その対策項目に相当する保守履歴を
出力するようにしたので、従来のような故障処理票に記
入する必要がなくオペレータの負担を軽減することがで
きると共に、障害発生装置の速やかな再立上げが可能と
なる。また、サービス員に連絡する情報の曖昧さも防止
することができるため、障害に対する対処を的確に行う
ことができる。更に、保守履歴により、装置毎の予備部
品等の判定も的確に行えるため、必要最低限の予備部品
をストックするだけで済み、装置の保守のためのコスト
低減化を図ることができる。

【図面の簡単な説明】

【図１】本発明の障害通知システムのブロック図であ
る。

【図２】従来の障害通知動作のフローチャートである。

【図３】本発明の障害通知システムにおけるパターンテ
ーブルを示す図（その１）である。

【図４】本発明の障害通知システムにおけるパターンテ
ーブルを示す図（その２）である。

【図５】本発明の障害通知システムにおける保守履歴を
示す図である。

【図６】本発明の障害通知システムにおけるパターンテ
ーブルと障害履歴とを示す図である。

【図７】本発明の障害通知システムの動作フローチャー
トである。

【図８】本発明の障害通知システムにおける障害発生状
況の出力動作を示すフローチャートである。

【図９】本発明の障害通知システムにおける保守動作を
示すフローチャートである。

【符号の説明】

２ 障害検知部 ３ パターンテーブル ４ 保守履歴格納部 ５ 障害履歴格納部 １５ 障害情報制御部

Claims (1)

【特許請求の範囲】
1. 【請求項１】 情報処理装置の運用中に発生した障害状
   況を検知する障害検知部と、 前記情報処理装置で発生する障害のパターンに対応した
   対策情報項目を示すパターンテーブルと、 前記情報処理装置における各部の保守履歴を格納する保
   守履歴格納部と、 前記障害検知部で障害が検知された場合、前記パターン
   テーブルに基づき、当該障害の対策情報項目に対応した
   保守履歴を前記保守履歴格納部から取出す障害情報制御
   部とを備えたことを特徴とする障害通知システム。