JP5275715B2 - エラー通知方法、情報処理装置および通信システム - Google Patents

Description

本発明は、情報通信装置においてＯＳが起動するまでに生じたエラーを処理する通信システムに関するものである。

ＰＣなどの情報通信装置の起動時に障害が発生した場合における起動を確保するための様々な方法が、従来から提案されている。たとえば、下記特許文献１では、電源やＰＯＳＴ（Power On Self Test）のエラーを監視し、リトライを行う技術が開示されている。この技術によれば、偶発故障によるシステムダウンを防止できる。

特開２００２−０７３３６２号公報

しかしながら、上記従来の技術は、主に回路の偶発故障を想定しており、あくまでリトライを目的としているため、情報通信装置が完全に止まった状態には対応できない。また、リトライによって正常起動を確保できてしまうことで、潜在的には不具合があるにも関わらず、ユーザが見過ごしてしまう、という問題があった。また、不具合が見過ごされた結果、その不具合が非常に重くなり、リトライが不能になるまで放置されることともなり、メンテナンスコストが増大する、という問題があった。

本発明は、上記に鑑みてなされたものであって、ハードウェア障害等の重篤なエラーも含めて、起動時に発生するエラーを監視することができ、かつエラーの内容を管理者に通知できるエラー通知方法、情報処理装置および通信システムを得ることを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、外部ネットワークを介して接続された管理端末との間で通信を行う通信制御部と、自端末の状態を監視する監視制御部と、を備えたクライアント端末におけるエラー通知方法であって、前記監視制御部が実行する処理として、起動時に実行されるＰＯＳＴのＰＯＳＴコードを取得し、ＰＯＳＴの進行状況を監視するＰＯＳＴ監視ステップと、前記監視中に最終のＰＯＳＴコード以外のＰＯＳＴコードで処理が停止したと判断した場合に、ＰＯＳＴを実行中に処理が停止した旨およびその時点のＰＯＳＴコードをエラー情報として保持するＰＯＳＴエラー保持ステップと、保持しておいたエラー情報を前記通信制御部に送信するエラー情報送信ステップと、を含み、前記通信制御部が実行する処理として、受信したエラー情報に基づいて、前記管理端末に対してエラーの内容を通知するためのファイルであるエラー通知ファイルを生成するファイル生成ステップと、前記エラー通知ファイルを前記管理端末に向けて送信するファイル送信ステップと、を含むことを特徴とする。

また、本発明にかかるエラー通知方法は、前記監視制御部が、ＰＯＳＴを実行中に処理が停止することなく正常にＰＯＳＴが終了したと判断した後に、最終のＰＯＳＴコードが所定時間にわたって変化していないと判断した場合に、ＯＳの起動に失敗したと判断し、ＯＳの起動が失敗した旨および最終のＰＯＳＴコードをエラー情報として保持するＯＳ起動エラー保持ステップ、を含むことを特徴とする。

また、本発明にかかるエラー通知方法は、前記監視制御部が、前記ＰＯＳＴ監視ステップを実行する前に、給電の状況を監視し、正常に給電が行われていない箇所がある場合に、その旨および正常に給電が行われていない箇所への給電系統をエラー情報として保持する給電エラー保持ステップ、を含むことを特徴とする。

また、本発明にかかるエラー通知方法において、前記エラー情報送信ステップでは、前記エラー情報をまとめて送信するために必要な時間であるエラー情報保持タイムアウト時間を設定し、当該エラー情報保持タイムアウト時間が経過した時点で、保存されているすべてのエラー情報を前記通信制御部に送信することを特徴とする。

また、本発明にかかるエラー通知方法は、前記監視制御部がＣＰＵの温度情報を取得する温度取得ステップ、をさらに含み、前記エラー情報送信ステップでは、前記温度取得ステップで取得した温度情報をエラー情報とともに前記通信制御部に送信し、前記ファイル生成ステップでは、前記エラー通知ファイルに温度情報を含めることを特徴とする。

また、本発明にかかるエラー通知方法は、前記給電エラー保持ステップにおいて前記通信制御部への給電が正常でないと判断された場合、前記監視制御部は、前記エラー情報送信ステップを実行せずに、保持しているエラー情報および温度情報を不揮発性メモリに記憶することを特徴とする。

また、本発明は、外部ネットワークを介して接続された管理端末との間で通信を行う通信制御部と、自装置の状態を監視する監視制御部とを備えた、クライアント端末として動作する情報処理装置であって、前記監視制御部が、起動時に実行されるＰＯＳＴのＰＯＳＴコードを取得することによりＰＯＳＴの進行状況を監視し、監視中に最終のＰＯＳＴコード以外のＰＯＳＴコードで処理が停止したと判断した場合に、ＰＯＳＴを実行中に処理が停止した旨およびその時点のＰＯＳＴコードをエラー情報として出力する監視部と、エラー情報を保持し、所定のタイミングで、保持しておいたエラー情報を前記通信制御部に送信するエラー通知制御部と、を備え、前記通信制御部が、受信したエラー情報に基づいて、前記管理端末に対してエラーの内容を通知するためのファイルであるエラー通知ファイルを生成し、当該エラー通知ファイルを前記管理端末に向けて送信することを特徴とする。

また、本発明にかかる情報処理装置において、前記監視部は、さらに、ＰＯＳＴを実行中に処理が停止することなく正常にＰＯＳＴが終了したと判断した後に、最終のＰＯＳＴコードが所定時間にわたって変化していないと判断した場合に、ＯＳの起動に失敗したと判断し、ＯＳの起動が失敗した旨および最終のＰＯＳＴコードをエラー情報として出力することを特徴とする。

また、本発明にかかる情報処理装置において、前記監視部は、さらに、前記ＰＯＳＴの進行状況を監視する前に、給電の状況を監視し、正常に給電が行われていない箇所がある場合に、その旨および正常に給電が行われていない箇所への給電系統をエラー情報として出力することを特徴とする。

また、本発明にかかる情報処理装置において、前記エラー通知制御部は、前記エラー情報をまとめて送信するために必要な時間であるエラー情報保持タイムアウト時間を設定し、当該エラー情報保持タイムアウト時間が経過した前記所定のタイミングで、保存されているすべてのエラー情報を前記通信制御部に送信することを特徴とする。

また、本発明にかかる情報処理装置において、前記監視部は、さらに、ＣＰＵの温度情報を取得し、取得した温度情報をエラー情報とともに出力し、前記エラー通知制御部は、エラー情報に加えて温度情報を前記通信制御部に送信し、前記通信制御部は、前記エラー通知ファイルにさらに温度情報を含めることを特徴とする。

また、本発明にかかる情報処理装置は、前記監視部が前記通信制御部への給電が正常でないと判断した場合、前記エラー通知制御部は、前記通信制御部への送信処理を実行せずに、保持しているエラー情報および温度情報を不揮発性メモリに記憶することを特徴とする。

また、本発明は、請求項７〜１２のいずれか一つに記載のクライアント端末とネットワークを介して接続された、管理端末として動作する情報処理装置であって、ＰＯＳＴコードに対応した故障部位および故障原因を登録したエラー集計テーブルと、前記クライアント端末からエラー通知ファイルを受信した場合に、当該エラー通知ファイルに含まれるＰＯＳＴコードをキーに前記エラー集計テーブルから故障部位および故障原因を抽出し、得られた故障部位および故障原因を含む原因通知メッセージを生成し、当該原因通知メッセージを所定の端末に通知する制御部と、を備えることを特徴とする。

また、本発明にかかる情報処理装置において、前記エラー集計テーブルには、さらに、ＰＯＳＴコードと故障部位および故障原因との組合せに対する総発生件数を登録することとし、前記制御部は、前記原因通知メッセージに当該総発生件数をさらに含めることを特徴とする。

また、本発明にかかる情報処理装置において、前記制御部は、さらに、前記エラー通知ファイルによって正常に給電が行われていない箇所がある旨が通知された場合、その旨および正常に給電が行われていない箇所への給電系統を含む原因通知メッセージを生成することを特徴とする。

また、本発明にかかる情報処理装置は、前記所定の端末を、メンテナンスを担当する端末とすることを特徴とする。

また、本発明にかかる情報処理装置において、前記原因通知メッセージの通知は、電子メール、ファイル転送または所定のサーバへのアップロードにより実施することを特徴とする。

また、本発明にかかる通信システムは、請求項７〜１２のいずれか一つに記載のクライアント端末と、請求項１３〜１７のいずれか１つに記載の管理端末と、を備えることを特徴とする。

本発明によれば、起動時に発生するエラーを監視し、エラーの内容を管理者に通知することとしたので、メンテナンス作業の効率を大幅に改善することができる、という効果を奏する。

以下に、本発明にかかる通信システムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。

図１は、本発明にかかる情報処理装置の構成例を示す図である。図１の情報処理装置は、外部ネットワークとの間で情報の送受信を行う通信制御部１と、電源制御部２と、ユーザによるメイン電源を投入する操作を受け付けるＰｏｗｅｒスイッチ３と、情報処理装置内の各部へ電源を供給する電源部４と、ＣＰＵやメモリなどから構成される中央処理装置５と、ＨＤＤなどから構成される記憶装置６とを備える。また、図１の点線は、各構成部へ電源を供給するためのパワーラインを表している。

また、中央処理装置５は、演算処理や制御処理などを行うＣＰＵ７と、アドレスバスおよびデータバスを制御するバス制御部８と、ＢＩＯＳ ＲＯＭ９と、メインメモリ１０とを備え、各部間はバスで接続されている。なお、図１では、データバスのみを示している。ＢＩＯＳ ＲＯＭ９は、ＢＩＯＳ（Basic Input Output System）を格納する。ＢＩＯＳは、情報処理装置内の各ハードウェアの初期化およびＯＳのロードなどを行うためのプログラムであって、ＰＯＳＴを実行するためのプログラム部分を含む。ＣＰＵ７は、ＢＩＯＳの記述にしたがい、ＰＯＳＴを含む処理を実行する。また、ＰＯＳＴが実行されると、バス制御部８が保持するレジスタ（図示せず）に、随時ＰＯＳＴコードが書き込まれる。メインメモリ１０は、ランダムアクセスメモリであって、ＣＰＵ７がＰＯＳＴを実行する際にメモリテストの対象となり、ＰＯＳＴ内のメモリテストが終了した後には、ＣＰＵ７のワークメモリとして用いられる。また、ＣＰＵ７がＰＯＳＴをすべて終了した場合には、ＯＳを起動する際のワークメモリとして用いられる。

バス制御部８は、アドレスバス（図示せず）およびデータバス（以下、単に「バス」）を制御し、その際、データバスについては送信側と受信側を切り替える制御を行う。ここでは、ＣＰＵ７とバスによって接続されたバス制御部８のみを示しているが、ＣＰＵ７と記憶装置６との間にもバス制御部（ＩＯ制御部）（図示せず）が存在する。このバス制御部は、ＣＰＵ７がＰＯＳＴにおいて記憶装置６をテストする場合は、ＣＰＵ７と記憶装置６とが接続されるようにバスを切り替える。また、バス制御部８は、自身が保持するレジスタを随時参照して現在のＰＯＳＴコードを取得し、電源制御部２に対して接続されたバス（たとえばＬＰＣ（Low Pin Count）バス）に出力する。また、バス制御部８は、ＣＰＵ７の近傍に設置された温度センサ（図示せず）から通知される温度情報を取得し、電源制御部２に対して接続された別のバス（たとえばＵＳＢ（Universal Serial Bus）バス）に出力する。なお、温度センサからバス制御部８への温度情報の通知は、たとえば、ＣＰＵ７が温度情報をバス制御部８の所定のポートに書き込む方法でもよく、ＣＰＵ７からバス制御部８へシリアルバスで送る方法でもよい。

図２は、電源制御部２の構成例を示すブロック図である。図２の電源制御部２は、制御部２１と、記憶部２２と、ハードウェア監視部２３とを備える。制御部２１は、通信制御部１との間で通信を行うエラー通知制御部２４と、各部への電源の供給を行うよう電源部４を制御する給電制御部２５と、を備える。記憶部２２は、不揮発性メモリ２６と、ＲＡＭ（Random Access Memory）２７とを備える。ハードウェア監視部２３は、電源監視部２８と、エラー監視部２９とを備え、制御部２１からの制御にしたがって電源に関する不具合および様々なエラーを監視する。たとえば、電源監視部２８は、Ｐｏｗｅｒスイッチ３の投入を監視するスイッチ監視部３０と、電源部４より各構成部への電源の供給を監視する電圧・電流監視部３１とを備える。また、エラー監視部２９は、ＰＯＳＴコードおよび温度情報を制御部２１に通知する。また、制御部２１にはタイマ３２が接続され、制御部２１のエラー通知制御部２４は、タイマ３２からの通知を受けると、制御部２１に通知されたエラーを通信制御部１に通知する。

つづいて、上記のように構成された情報処理装置を用いた通信システムにおけるエラー発生時の動作について説明する。図３は、本実施例の情報処理装置を用いた通信システムの構成例を示す図である。この通信システムは、上記情報処理装置を適用したクライアント端末５０−ｍ−ｎ（ｍ，ｎ＝１，２，…）と、営業所端末５０−ｍと、ネットワーク５１と、管理端末５２とを備える。各クライアント端末は、事業者が提供するサービスのクライアントであるユーザが管理する端末である。なお、図３では、クライアント端末を、営業所“ｍ”が管轄する端末“ｎ”として示す。

営業所端末５０−ｍは、クライアント端末５０−ｍ−ｎを管轄する営業所に設置される端末である。各営業所は、管轄するクライアント端末のメンテナンス（修理や問合せなど）を担当する。

管理端末５２は、事業者が管理する端末であって、たとえばリモートメンテナンスセンタなどに設置される。図４は、図３の通信システムにおける管理端末５２の構成例を示す図である。管理端末５２は、制御部６１および記憶部６２を備え、記憶部６２は、エラーの原因および件数等を含むテーブルであるエラー集計テーブル６３を備える。管理端末５２の制御部６１は、内部ネットワークおよび外部ネットワーク（ネットワーク５１）との間で送受信を行い、クライアント端末からエラーの発生および内容を通知するファイルであるエラー通知ファイルを受信し、また、クライアント端末および該当する営業所端末に対しエラー原因を通知する。ここで、営業所端末とクライアント端末との対応関係は、一例として、以下のように管理する。たとえば、クライアント端末を一意に示すコードが営業所端末を示すコードを含むコード体系とし、クライアント端末の不揮発性メモリ２６にクライアント端末コード（たとえば、５０−ｍ−ｎ）を記録しておくことで、クライアント端末コードから営業所コード（たとえば、５０−ｍ）を判別できるようにする。または、クライアント端末のＭＡＣアドレス（Media Access Control Address）や製造番号を、管理端末５２の不揮発性メモリ（図示せず）に記録しておき、管理端末５２において、営業所コード（たとえば、５０−ｍ）との対応をテーブルで保持する。

以下、クライアント端末５０−１−２が起動する場合を例に、クライアント端末のエラー発生時の動作を詳細に説明する。

図５は、クライアント端末の起動時のエラー通知動作を示すフローチャートである。なお、クライアント端末が立ち上がっていない状態においても、クライアント端末の電源制御部２には通電されていることを前提とする。

電源制御部２のスイッチ監視部３０は、Ｐｏｗｅｒスイッチ３が投入されたことを検出すると（ステップＳ１）、その旨を制御部２１に通知する。制御部２１の給電制御部２５は、これを受けて、クライアント端末内の各部に対して電源を供給するように電源部４を制御する。電源部４は、電源制御部２の制御にしたがい、通信制御部１，中央処理装置５，記憶装置６等の各構成部に対して電源を供給する。

電源制御部２の電圧・電流監視部３１は、各構成部への給電系統（パワーライン）に対応して電源部４に搭載された電流・電圧センサ（図示せず）からの信号によって、電圧が適正に印加され特定の電流が検出されたか否かを監視する（ステップＳ２）。

たとえば、正常に給電されていない構成部（電源オンが失敗した構成部）があると判断した場合（ステップＳ２：Ｙｅｓ）、電圧・電流監視部３１は、電源オンが失敗した旨および電源オンが失敗した給電系統を、制御部２１に通知する（ステップＳ３）。そして、制御部２１のエラー通知制御部２４では、上記電源オンの失敗によって通知された情報（以下、エラー情報という）を、ＲＡＭ２７に保存する。なお、ここでのエラー情報は、電源オンが失敗した旨および電源オンが失敗した給電系統、である。

そして、上記ステップＳ３の処理において、中央処理装置５の電源オンが失敗してエラー情報を制御部２１に通知した場合は（ステップＳ４：Ｎｏ）、以後のＣＰＵ７の起動処理は行われないので、制御部２１のエラー通知制御部２４は、所定のエラー情報保持タイムアウト時間の経過待ち状態に移行する。

また、上記ステップＳ２においてすべての構成部が正常に給電されていると判断した場合（ステップＳ２：Ｎｏ）、または、正常に給電されていない構成部はあるが中央処理装置５の電源オンが成功している場合は（ステップＳ４：Ｙｅｓ）、ＣＰＵ７がＢＩＯＳ ＲＯＭ９にアクセスしＢＩＯＳを実行するので、電源制御部２のエラー監視部２９では、以降、ＰＯＳＴの監視を行う（ステップＳ５）。

具体的には、ＰＯＳＴが実行されると、ＣＰＵ７は、バス制御部８内のレジスタに、随時、ＰＯＳＴコードを書き込み、バス制御部８が、自身の保持するレジスタを随時参照して現在のＰＯＳＴコードを取得し、そのＰＯＳＴコードを電源制御部２に接続されたＬＰＣバスに出力する。そして、電源制御部２のエラー監視部２９では、出力されたＰＯＳＴコードを取得し、ＰＯＳＴの進行状況を監視する。

たとえば、上記監視中に取得したＰＯＳＴコードが最終のＰＯＳＴコードではなく、かつ、そのＰＯＳＴコードが予め規定された一定時間にわたって変化しなかった場合、エラー監視部２９は、ＰＯＳＴを実行中に処理が停止したと判断し（ステップＳ５：Ｙｅｓ）、ＰＯＳＴを実行中に処理が停止した旨およびそのときのＰＯＳＴコード（エラー情報）を、制御部２１に通知する（ステップＳ６）。ここで、処理が停止する具体的なケースとしては、たとえば、ＰＯＳＴ実行中にＣＰＵ７が停止（ハングアップ）することでＰＯＳＴが停止してしまう場合や、メインメモリ１０のメモリテストなどでエラーが発生したことで、ＢＩＯＳの制御において、システム起動に重大な障害があるためＰＯＳＴの続行に意味がないとしてＰＯＳＴが停止される場合などがある。制御部２１のエラー通知制御部２４では、このエラー情報をＲＡＭ２７に保存し、その後、所定のエラー情報保持タイムアウト時間の経過待ち状態に移行する。

一方、電源制御部２のエラー監視部２９によりＰＯＳＴを実行中に処理が停止したと判断されることなく、正常にＰＯＳＴが終了した場合（ステップＳ５：Ｎｏ）、ＣＰＵ７は、ＯＳの起動処理に入る（ステップＳ７）。ＣＰＵ７は、ＢＩＯＳに記述されたプログラムコードにしたがって、自身のアクセス先を、ＢＩＯＳ ＲＯＭ９から、記憶装置６よりロードしたメインメモリ１０上のＯＳ起動プログラムの先頭に移す。ここで、電源制御部２のエラー監視部２９は、バス制御部８から最終のＰＯＳＴコードが出力され、かつ、所定の時間（ＯＳが起動するまでの妥当な時間）にわたってそのＰＯＳＴコードが変化しなかった場合、ＯＳの起動に失敗したと判断する（ステップＳ８：Ｙｅｓ）。そして、ＯＳ起動が失敗した旨および最終のＰＯＳＴコード（エラー情報）を、制御部２１に通知する（ステップＳ９）。制御部２１のエラー通知制御部２４では、このエラー情報をＲＡＭ２７に保存し、その後、所定のエラー情報保持タイムアウト時間の経過待ち状態に移行する。

そして、制御部２１のエラー通知制御部２４では、エラー情報保持タイムアウト時間が経過した時点で（ステップＳ１０）、ＲＡＭ２７に保存されているすべてのエラー情報を通信制御部１に送信する（ステップＳ１１）。なお、上記エラー情報保持タイムアウト時間を設定する理由は、起動時に通知された複数のエラー情報をまとめて同時に通知するためである。したがって、上記エラー情報保持タイムアウト時間は、上記複数のエラー情報をまとめて通知するために必要となる十分な時間が設定される。たとえば、記憶装置６への電源オンのみが失敗した場合は（ステップＳ４：Ｙｅｓ）、ＣＰＵ７がＰＯＳＴを実行していく中で、他のエラーによりＰＯＳＴが停止する（ステップＳ５：Ｙｅｓ）可能性がある。このような場合は、電源供給が失敗したことによるエラー情報（ステップＳ３）と、ＰＯＳＴ停止によるエラー情報（Ｓ６）とが通知されることになる。すなわち、エラー通知制御部２４では、エラーの発生状況に応じて、ステップＳ３，ステップＳ６，ステップＳ９によるエラー情報のうちのいずれか一つ、ステップＳ３およびステップＳ６によるエラー情報、または、ステップＳ３およびステップＳ９によるエラー情報、を送信する場合がある。

なお、たとえば図１および図２の構成において、ＣＰＵ７が正常に動作している場合、電源制御部２のエラー監視部２９は、バス制御部８からＵＳＢバスを通じて出力されるＣＰＵ７の温度情報を常時取得している。そして、エラー監視部２９は、取得した温度情報を適宜処理して、常時、制御部２１に通知する。具体的には、エラー監視部２９は、温度情報を所定の閾値と比較し、たとえば、ＣＰＵ７付近の温度が「高い／中温／低い」または「正常／異常」である旨を制御部２１に通知している。これらの処理は、ＣＰＵ７の動作中は継続して行われる。以下、この処理結果を温度ステータスと呼ぶ。そこで、本実施例では、電源制御部２の制御部２１が、読み出したエラー情報を通信制御部１に送信する際に、上記で得られる温度ステータスについても同時に送信する。

また、上記ステップＳ２による監視で、通信制御部１への給電が正常でないと判断された場合には、電源制御部２は通信制御部１と通信を行うことができない。したがって、電源制御部２のエラー通知制御部２４は、電圧・電流監視部３１から通信制御部１の電源オンが失敗した旨を通知された場合、通信制御部１へエラー情報および温度ステータスを送信する代わりに、たとえば、記憶部２２内の不揮発性メモリ２６の所定の箇所に、上記送信すべきエラー情報および温度ステータスを書き込む。これにより、通信が不可能な場合であっても、メンテナンス担当者は、不揮発性メモリ２６に書きこまれた内容を調べることでエラーの原因を知ることができる。

つぎに、通信制御部１は、管理端末５２に対してエラー通知を行うために、受信したエラー情報等に基づいてエラー通知ファイルを作成する。

図６は、エラー通知ファイルの構成例を示す図である。図６のエラー通知ファイルは、一例として、「日時」，「識別番号」，「電源オンの成否」，「給電不可能系統の識別子」，「ＰＯＳＴコード」，「温度ステータス」，「エラーメッセージ」といった項目を含む。日時はシステム日付から取得される。識別番号は、クライアント端末を特定するためのシリアルナンバーであって、たとえば、電源制御部２の不揮発性メモリ２６などから取得される。また、エラーメッセージは、エラーの原因と推測される内容を示すメッセージであって、通信制御部１が、ＰＯＳＴコードまたは電源オンの成否、に対応させてセットする。管理端末５２の管理者は、単にＰＯＳＴコードを送られる場合、別途ＰＯＳＴコード表などを参照しなければ具体的な故障部位や故障原因を把握することは困難であるが、エラーメッセージを通知される場合は、これに比較して、即座に状況を把握できる。

そして、クライアント端末５０−１−２の通信制御部１は、以上のように作成したエラー通知ファイルを管理端末５２に対して送信する（ステップＳ１２）。なお、エラー通知ファイルは、管理端末５２に対して送信する代わりに、クライアント端末５０−１−２を管轄する営業所端末５０−１に対して送信してもよい。また、クライアント端末５０−１−２の通信制御部１は、エラー通知ファイルを送信する代わりに、エラーの内容を特定のＷｅｂページにアップロードしてもよい。

なお、上記起動時の動作においてエラーが発生しなかった場合、すなわち、上記ステップＳ８の判断処理において、上記所定の時間（ＯＳが起動するまでの妥当な時間）が経過する前にバス制御部８内のレジスタがクリアされ、ＯＳの起動に成功したと判断した場合（ステップＳ８：Ｎｏ）、電源制御部２のエラー監視部２９では、起動時の動作に異常がないと判断して（ステップＳ１３）、図５のエラー通知処理を終了する。

以上のようにして送信されたエラー通知ファイルを受信すると、管理端末５２の制御部６１は、受信したエラー通知ファイルを「識別番号」単位にマージし、記憶部６２内に保存する。

管理端末５２の制御部６１は、エラー通知ファイルの到着を随時または定期的にチェックする。制御部６１は、エラー通知ファイルが到着していた場合、エラー集計テーブル６３を参照してエラーの原因を特定する。図７は、エラー集計テーブル６３の項目およびデータの一例を示す図である。図７のエラー集計テーブル６３は、「エラーコード」，「故障部位」，「原因」，「現象」，「総発生件数」といった項目を備え、これまでのエラーを解析・集計した結果のデータが登録されている。

エラーコードには、ＰＯＳＴコードがセットされる。故障部位および原因には、実際に技術者などが解析を行って解明された結果が登録される。なお、故障部位および原因の解析では、エラー通知ファイルにおける「電源オンの成否」および「給電不可能系統の識別子」や、「温度ステータス」を参考にできる。現象は、そのクライアント端末に発生した現象であって、エラーコードによって特定される。すなわち、エラーコードが、最終のＰＯＳＴコード以外であれば「ＢＩＯＳ起動中停止」であり、最終のＰＯＳＴコードであれば「ＯＳ起動中停止」である。総発生件数は、同一の「エラーコード，故障部位，原因」の組合せに対して発生した、エラーの件数を集計した値である。

エラー集計テーブル６３には、解析され登録されなければ原因が特定できないエラーが登録されている。ＰＯＳＴまで至らずに電源オンが失敗した場合は、その旨および給電不可能系統の識別子によって、即座に原因が特定できる。

管理端末５２の制御部６１は、エラー集計テーブル６３を参照し、通知されたＰＯＳＴコードと一致するエラーコードについて、エントリを全て抽出する。そして、各エントリから「故障部位」，「原因」，「総発生件数」の値を取得し、これらにしたがってエラー原因を通知する。

たとえば、クライアント端末５０−１−２からのエラー通知ファイルにおいて、エラーコード「５２」が通知された場合を想定する。図７のデータ例では、エラーコードが「５２」であるエントリは２件登録されている。したがって、管理端末５２の制御部６１は、エラー原因を通知するための原因通知メッセージとして、「ＣＰＵ，ＢＧＡクラック，総発生件数５件」および「メモリ，コネクタ接触不良，総発生件数２６件」を作成する。そして、制御部６１は、作成した原因通知メッセージを営業所端末５０−１に通知する。ここで、クライアント端末を管轄する営業所端末の特定（すなわち営業所端末と、クライアント端末との対応関係）は、エラー通知ファイルによって通知される「識別番号」と営業所端末の識別子との関連をメンテナンスセンタ側で管理することによって行う。なお、クライアント端末を納品する際に担当営業所を示す識別子を不揮発性メモリに書き込んでおき、その識別子をエラー通知ファイルに含めてもよい。

また、管理端末５２の制御部６１は、作成した原因通知メッセージをクライアント端末５０−１−２に通知することもできる。なお、クライアント端末５０−１−２へ通知を行うのは、クライアント端末内の通信制御部１が起動している可能性があるためである。すなわち、クライアント端末は、通信制御部１が起動している場合には原因通知メッセージを受信するので、これを自身内の不揮発性メモリ２６に記録できる。これにより、担当営業所端末にかかるカストマ担当者が、クライアント端末のメンテナンスに出向いたときにその情報を参照できる。この際、たとえば、クライアントユーザがリトライを繰り返し、別のエラーが発生した場合には、カストマ担当者がメンテナンスに出向いたタイミングによっては、参照できる情報が増える可能性があるため、メンテナンス作業に有用である。なお、原因通知メッセージを受信したクライアント端末は、その内容をそのまま自身の画面に表示させてもよい。また、制御部６１は、そのクライアント端末が接続されたＬＡＮ内の、別のクライアント端末に対して、原因通知メッセージを通知してもよい。

なお、電源オンが失敗した場合は、原因が明確であるので、その旨および給電不可能系統の識別子をそのまま搭載した原因通知メッセージを作成し、通知する。たとえば、「電源オン失敗，（識別子）」といった原因通知メッセージである。

また、図７の例では、エラー集計テーブル６３にはＰＯＳＴ開始後のエラーについて登録し、ＰＯＳＴ開始後のエラーとＰＯＳＴ開始前のエラー（電源オンが失敗）とで、原因通知メッセージの作成方法を別としたが、エラー集計テーブル６３は、ＰＯＳＴ開始前のエラー（電源オンが失敗）も登録する構成としてもよい。この構成の場合、エラーコードとして、ＰＯＳＴコードの他にも、給電不可能を示すコードなどを使用する。故障部位には、電源部４または、給電不可能系統であったハードウェアなどを登録する。こうしたエラー集計テーブル６３を用いる場合、原因通知メッセージは、上述したＰＯＳＴ開始後のエラーについて用いた方法で統一的に作成できる。

営業所端末５０−１に原因通知メッセージが到着することで、その営業所では、自身が管轄するクライアント端末の故障の原因を予め把握することができる。上記の例では、総発生件数からみて、「メモリコネクタ接触不良」である可能性が高く、ついで「ＣＰＵのＢＧＡクラック」である可能性が高いことを把握することができる。これにより、メンテナンス作業の負担を軽減することができ、また、メンテナンス作業を実行する前から必要部品の準備，作業時間の見積もりなどが可能になるため、効率のよいメンテナンスが実現できる。

また、クライアント端末５０−１−２に原因通知メッセージが到着することで、クライアント端末のユーザは、故障の程度を把握でき、一定の安心感を得られる。また、故障の重篤さを知ることで、業務への影響を把握することも可能となる。

このように、上記通信システムでは、担当営業所端末にかかるカストマ担当者が、エラーの発生したクライアント端末の所在および原因と推測される不具合を、実際にメンテナンス作業に出向く前に速やかに知ることができるので、保守用部品の準備などに資することができる。特に、本発明が主にターゲットとする重篤なハードウェア障害が発生した場合には、端末が全く利用できない状態であることが多い。ここで、たとえば、会計事務所のような、多くの顧問先を抱え、かつ税務申告など時期的に業務が集中する業種では、端末の起動不良は非常に重大な問題であり、メンテナンス完了までのレスポンス時間が特に短いことが要請される。したがって、こうした業種での利用形態では、本発明の有用性は非常に高くなる。

また、クライアント端末および営業所端末への原因通知メッセージの通知は、電子メール，ファイル転送，所定のサーバへのアップロードなど、どのような手段であってもよい。また、通知方法は、クライアント端末と営業所端末で異なっていても構わない。

なお、本実施例では、クライアント端末が直接ネットワークに接続されるように通信システムを構成したが、これに限らず、クライアント端末がそれぞれの所属する営業所の営業所端末に接続される構成としてもよい。図８は、本実施例の情報処理装置を用いた通信システムの、別の構成例を示す図である。図８では、ネットワーク５１に対して接続された営業所端末５０−ｍの配下に、各営業所端末が管轄するクライアント端末５０−ｍ−ｎが接続される場合を示している。この場合、クライアント端末からのエラー通知ファイルは必ず営業所端末を経由するので、営業所端末はリアルタイムにクライアント端末の状況を把握できる。また、営業所端末がクライアント端末への通知を行うこととなるので、管理端末５２（メンテナンスセンタ側）の負担を軽減できる。

以上説明したように、本実施例の通信システムでは、クライアント端末である情報処理装置が、起動時に発生するエラーについて発生状況を網羅的に監視し、その内容を、ネットワークを介して管理端末に通知する構成とした。また、管理端末は、過去に発生したエラーの原因を集計したテーブルを保持し、このテーブルを参照して、推測される原因をクライアント端末または営業所端末に通知するとした。これにより、メンテナンス作業の効率を大幅に改善することができる。

以上のように、本発明にかかる情報処理装置は、起動時にエラー監視を行うクライアント端末として有用であり、特に、メンテナンスなど、サポート体制の強化が必要なシステムに適している。

本発明にかかる情報処理装置の構成例を示す図である。 電源制御部の構成例を示すブロック図である。 情報処理装置を用いた通信システムの構成例を示す図である。 図３の通信システムにおける管理端末の構成例を示す図である。 クライアント端末の起動時のエラー通知動作を示すフローチャートである。 エラー通知ファイルの構成例を示す図である。 エラー集計テーブルの項目およびデータの一例を示す図である。 情報処理装置を用いた通信システムの別の構成例を示す図である。

符号の説明

１ 通信制御部
２ 電源制御部
３ Ｐｏｗｅｒスイッチ
４ 電源部
５ 中央処理装置
６ 記憶装置
７ ＣＰＵ
８ バス制御部
９ ＢＩＯＳ ＲＯＭ
１０ メインメモリ
２１ 制御部
２２ 記憶部
２３ ハードウェア監視部
２４ エラー通知制御部
２５ 給電制御部
２６ 不揮発性メモリ
２７ ＲＡＭ
２８ 電源監視部
２９ エラー監視部
３０ スイッチ監視部
３１ 電圧・電流監視部
３２ タイマ
５０−ｍ 営業所端末
５０−ｍ−ｎ クライアント端末
５１ ネットワーク
５２ 管理端末
６１ 制御部
６２ 記憶部
６３ エラー集計テーブル

Claims (18)

1. 外部ネットワークを介して接続された管理端末との間で通信を行う通信制御部と、自端末の状態を監視する監視制御部と、を備えたクライアント端末におけるエラー通知方法であって、
   前記監視制御部が実行する処理として、
   起動時に実行されるＰＯＳＴ（Power On Self Test）のＰＯＳＴコードを取得し、ＰＯＳＴの進行状況を監視するＰＯＳＴ監視ステップと、
   前記監視中に最終のＰＯＳＴコード以外のＰＯＳＴコードで処理が停止したと判断した場合に、ＰＯＳＴを実行中に処理が停止した旨およびその時点のＰＯＳＴコードをエラー情報として保持するＰＯＳＴエラー保持ステップと、
   保持しておいたエラー情報を前記通信制御部に送信するエラー情報送信ステップと、
   を含み、
   前記通信制御部が実行する処理として、
   受信したエラー情報に基づいて、前記管理端末に対してエラーの内容を通知するためのファイルであるエラー通知ファイルを生成するファイル生成ステップと、
   前記エラー通知ファイルを前記管理端末に向けて送信するファイル送信ステップと、
   を含むことを特徴とするエラー通知方法。
2. 前記監視制御部が、ＰＯＳＴを実行中に処理が停止することなく正常にＰＯＳＴが終了したと判断した後に、最終のＰＯＳＴコードが所定時間にわたって変化していないと判断した場合に、ＯＳの起動に失敗したと判断し、ＯＳの起動が失敗した旨および最終のＰＯＳＴコードをエラー情報として保持するＯＳ起動エラー保持ステップ、
   を含むことを特徴とする請求項１に記載のエラー通知方法。
3. 前記監視制御部が、前記ＰＯＳＴ監視ステップを実行する前に、給電の状況を監視し、正常に給電が行われていない箇所がある場合に、その旨および正常に給電が行われていない箇所への給電系統をエラー情報として保持する給電エラー保持ステップ、
   を含むことを特徴とする請求項１または２に記載のエラー通知方法。
4. 前記エラー情報送信ステップでは、前記エラー情報をまとめて送信するために必要な時間であるエラー情報保持タイムアウト時間を設定し、当該エラー情報保持タイムアウト時間が経過した時点で、保存されているすべてのエラー情報を前記通信制御部に送信することを特徴とする請求項３に記載のエラー通知方法。
5. 前記監視制御部がＣＰＵの温度情報を取得する温度取得ステップ、
   をさらに含み、
   前記エラー情報送信ステップでは、前記温度取得ステップで取得した温度情報をエラー情報とともに前記通信制御部に送信し、
   前記ファイル生成ステップでは、前記エラー通知ファイルに温度情報を含めることを特徴とする請求項３または４に記載のエラー通知方法。
6. 前記給電エラー保持ステップにおいて前記通信制御部への給電が正常でないと判断された場合、前記監視制御部は、前記エラー情報送信ステップを実行せずに、保持しているエラー情報および温度情報を不揮発性メモリに記憶することを特徴とする請求項５に記載のエラー通知方法。
7. 外部ネットワークを介して接続された管理端末との間で通信を行う通信制御部と、自装置の状態を監視する監視制御部とを備えた、クライアント端末として動作する情報処理装置であって、
   前記監視制御部が、
   起動時に実行されるＰＯＳＴ（Power On Self Test）のＰＯＳＴコードを取得することによりＰＯＳＴの進行状況を監視し、監視中に最終のＰＯＳＴコード以外のＰＯＳＴコードで処理が停止したと判断した場合に、ＰＯＳＴを実行中に処理が停止した旨およびその時点のＰＯＳＴコードをエラー情報として出力する監視部と、
   エラー情報を保持し、所定のタイミングで、保持しておいたエラー情報を前記通信制御部に送信するエラー通知制御部と、
   を備え、
   前記通信制御部が、受信したエラー情報に基づいて、前記管理端末に対してエラーの内容を通知するためのファイルであるエラー通知ファイルを生成し、当該エラー通知ファイルを前記管理端末に向けて送信することを特徴とする情報処理装置。
8. 前記監視部は、さらに、
   ＰＯＳＴを実行中に処理が停止することなく正常にＰＯＳＴが終了したと判断した後に、最終のＰＯＳＴコードが所定時間にわたって変化していないと判断した場合に、ＯＳの起動に失敗したと判断し、ＯＳの起動が失敗した旨および最終のＰＯＳＴコードをエラー情報として出力することを特徴とする請求項７に記載の情報処理装置。
9. 前記監視部は、さらに、
   前記ＰＯＳＴの進行状況を監視する前に、給電の状況を監視し、正常に給電が行われていない箇所がある場合に、その旨および正常に給電が行われていない箇所への給電系統をエラー情報として出力することを特徴とする請求項７または８に記載の情報処理装置。
10. 前記エラー通知制御部は、
    前記エラー情報をまとめて送信するために必要な時間であるエラー情報保持タイムアウト時間を設定し、当該エラー情報保持タイムアウト時間が経過した前記所定のタイミングで、保存されているすべてのエラー情報を前記通信制御部に送信することを特徴とする請求項９に記載の情報処理装置。
11. 前記監視部は、さらに、ＣＰＵの温度情報を取得し、取得した温度情報をエラー情報とともに出力し、
    前記エラー通知制御部は、エラー情報に加えて温度情報を前記通信制御部に送信し、
    前記通信制御部は、前記エラー通知ファイルにさらに温度情報を含めることを特徴とする請求項９または１０に記載の情報処理装置。
12. 前記監視部が前記通信制御部への給電が正常でないと判断した場合、前記エラー通知制御部は、前記通信制御部への送信処理を実行せずに、保持しているエラー情報および温度情報を不揮発性メモリに記憶することを特徴とする請求項１１に記載の情報処理装置。
13. 請求項７〜１２のいずれか一つに記載のクライアント端末とネットワークを介して接続された、管理端末として動作する情報処理装置であって、
    ＰＯＳＴコードに対応した故障部位および故障原因を登録したエラー集計テーブルと、
    前記クライアント端末からエラー通知ファイルを受信した場合に、当該エラー通知ファイルに含まれるＰＯＳＴコードをキーに前記エラー集計テーブルから故障部位および故障原因を抽出し、得られた故障部位および故障原因を含む原因通知メッセージを生成し、当該原因通知メッセージを所定の端末に通知する制御部と、
    を備えることを特徴とする情報処理装置。
14. 前記エラー集計テーブルには、さらに、ＰＯＳＴコードと故障部位および故障原因との組合せに対する総発生件数を登録することとし、
    前記制御部は、前記原因通知メッセージに当該総発生件数をさらに含めることを特徴とする請求項１３に記載の情報処理装置。
15. 前記制御部は、さらに、
    前記エラー通知ファイルによって正常に給電が行われていない箇所がある旨が通知された場合、その旨および正常に給電が行われていない箇所への給電系統を含む原因通知メッセージを生成することを特徴とする請求項１３または１４に記載の情報処理装置。
16. 前記所定の端末を、当該エラー通知を送信したクライアント端末に対応する営業所端末とすることを特徴とする請求項１３、１４または１５に記載の情報処理装置。
17. 前記原因通知メッセージの通知は、電子メール、ファイル転送または所定のサーバへのアップロードにより実施することを特徴とする請求項１３〜１６のいずれか一つに記載の情報処理装置。
18. 請求項７〜１２のいずれか一つに記載のクライアント端末と、
    請求項１３〜１７のいずれか１つに記載の管理端末と、
    を備えることを特徴とする通信システム。

Images