JP2006042073A - 異常対応プログラム、異常対応方法および画像形成装置 - Google Patents

Abstract

【課題】異常対応を効率よく実現することができる異常対応プログラム、異常対応方法および画像形成装置を提供すること。
【解決手段】異常情報取得手段に相当するスタッフクラス３４０を設け、対応選定手段に相当する操作者クラス３１０は、このスタッフクラス３４０から報告された情報を異常情報とみなして、これに対する対応策を選択してその実行を依頼する。また、操作者クラス３１０は、属性である要求内容３１０ａに、異常が発生した当該の処理を実現するための方法を優先順位付きで保持し、この優先順位に基づいてどの対応策を選択するべきかの判定をおこなう。
【選択図】 図８

Description

本発明は、所定の処理をおこなう処理実行手段において発生した異常に係る異常情報を受け付け、該異常への対応をおこなう異常対応プログラム、異常対応方法および画像形成装置に関し、特に異常への対応の選択処理を効率よく実現することができ、機能追加と改修を容易におこなうことができる異常対応プログラム、異常対応方法および画像形成装置に関するものである。

従来、プリンタ、コピーおよびスキャナなどの複数の機能を一つの筐体内に収納した複合機が知られている。かかる複合機では、ＵＮＩＸ（Ｒ）などの汎用ＯＳ上に、プリンタアプリ、コピーアプリおよびスキャナアプリと呼ばれる複数のアプリケーションを搭載し、これらのアプリケーションの実行処理を切替えながら複数の機能を実現していた。

ところが、上記プリンタアプリ、コピーアプリおよびスキャナアプリは、共通して含まれるエンジン制御、メモリ制御およびシステム制御などの機能をそれぞれ別個に実現していたので、重複開発という無駄が生じていた。

このため、特許文献１では、複合機に搭載される複数のアプリケーションがそれぞれ担っていたエンジン制御、メモリ制御およびシステム制御などの処理を共通処理部分（プラットホーム）として各アプリケーションから括り出すことにより、アプリケーションの開発効率の向上を図っている。

特開２００２−０８４３８３号公報

しかしながら、この特許文献１で開示されている発明は、ハードウェアを制御する処理部分を共通化するものであり、各アプリケーションの内部処理全般を共通化するものではない。このため、複合機上のアプリケーションには、開発効率の向上を図るうえで改善の余地が残されている。

たとえば、操作管理処理の一部として実装され、ハードウェアの制御部等から障害の発生の報告を受け付け、この障害に対して自身で対応かどうかを判断し、対応可能な場合は対応を実施する異常対応処理は、画像形成機上の各アプリケーションに共通して存在する機能であるが、ハードウェアを直接制御する処理ではないため各アプリケーションで別個に実現されており、共通化することが可能である。

ところで、この異常対応処理は、複写機が多機能化するのに伴って複雑化しており、新たな機能を追加する場合や不具合の改修をおこなう場合には、既存の機能に障害が発生しないように注意して開発をおこなうことが必要とされ、多くの開発工数を割当てなければならなくなっている。このため、異常対応処理を各アプリケーションで共通化するにあたっては、機能追加や改修のための工数を低減することが強く求められている。

本発明は、上述した従来技術による問題点を解消するためになされたものであり、異常対応処理を効率よく実現することができ、機能追加と改修を容易におこなうことができる異常対応プログラム、異常対応方法および画像形成装置を提供することを目的とする。

上述した課題を解決し、目的を達成するために、請求項１にかかる発明は、所定の処理をおこなう処理実行手段において発生した異常に係る異常情報を受け付け、該異常への対応をおこなう異常対応プログラムであって、前記処理実行手段から前記異常情報を受け付ける異常情報取得手順と、前記異常情報取得手順により受け付けられた前記異常情報の示す前記異常への対応策を選定する対応選定手順とをコンピュータに実行させることを特徴とする。

また、請求項２にかかる発明は、請求項１の発明において、前記対応選定手順は、前記処理実行手段に前記所定の処理をおこなわせるための実現策に係る情報を少なくとも一つ保持し、この実現策に係る情報のひとつを対応策として選択することを特徴とする。

また、請求項３にかかる発明は、請求項２の発明において、前記対応選定手順は、前記実現策に係る情報を優先順位をつけて保持し、この実現策に係る情報のうち未実施で且つ最も優先順位の高いものを対応策として選択することを特徴とする。

また、請求項４にかかる発明は、請求項２または３の発明において、前記対応選定手順は、前記実現策に係る情報に選択可能なものがない場合には、前記異常情報取得手段により取得された当該の異常情報を他の対応手段に転送することを特徴とする。

また、請求項５にかかる発明は、所定の処理をおこなう処理実行手段において発生した異常に係る異常情報を受け付け、該異常への対応をおこなう異常対応方法であって、前記処理実行手段から前記異常情報を受け付ける異常情報取得工程と、前記異常情報取得工程により受け付けられた前記異常情報の示す前記異常への対応策を選定する対応選定工程とを含んだことを特徴とする。

また、請求項６にかかる発明は、所定の処理をおこなう処理実行手段において発生した異常に係る異常情報を受け付け、該異常への対応をおこなう異常対応プログラムを制御ソフトウェアの一部として有する画像形成装置であって、前記処理実行手段から前記異常情報を受け付ける異常情報取得手順と、前記異常情報取得手順により受け付けられた前記異常情報の示す前記異常への対応策を選定する対応選定手順とをコンピュータに実行させることを特徴とする。

また、請求項７にかかる発明は、請求項６の発明において、前記対応選定手順は、前記処理実行手段に前記所定の処理をおこなわせるための実現策に係る情報を少なくとも一つ保持し、この実現策に係る情報のひとつを対応策として選択することを特徴とする。

また、請求項８にかかる発明は、請求項７の発明において、前記対応選定手順は、前記実現策に係る情報を優先順位をつけて保持し、この実現策に係る情報のうち未実施で且つ最も優先順位の高いものを対応策として選択することを特徴とする。

また、請求項９にかかる発明は、請求項７または８の発明において、前記対応選定手順は、前記実現策に係る情報に選択可能なものがない場合には、前記異常情報取得手段により取得された当該の異常情報を他の対応手段に転送することを特徴とする。

請求項１にかかる発明によれば、異常情報取得手順を設け、この異常情報取得手順を通じて情報がもたらされた場合のみ対応選定手順が異常状態への対策を選定するように構成したので、もたらされた情報が異常に関するものであるか否かを対応選定手順が判定する必要が無くなり、これによって対応選定手順の処理が単純化され、処理内容が理解され易くなり、もって機能追加と改修に容易に対応することができるという効果を奏する。

また、請求項２にかかる発明によれば、異常への対応方法を個別のロジックとしてではなく情報としてもち、この対応方法に関する情報を共通のロジックで実行するように構成したので、対応方法を実行するための処理が単純化され、処理内容が理解され易くなり、もって機能追加と改修に容易に対応することができるという効果を奏する。

また、請求項３にかかる発明によれば、対応方法が複数存在する場合に事前に定義された優先順位によってどの対応方法を選択するかを決定するように構成したので、複数の選択肢から対応方法を選択するための処理が単純化され、処理内容が理解され易くなり、もって機能追加と改修に容易に対応することができるという効果を奏する。

また、請求項４にかかる発明によれば、事前に用意された対応方法で対応できない場合は他の手段に対応を委ねるように構成したので、対応策が見つからない場合の例外処理等を作りこむ必要がなくなって処理が単純化され、処理内容が理解され易くなり、もって機能追加と改修に容易に対応することができるという効果を奏する。

また、請求項５にかかる発明によれば、異常情報取得工程を設け、この異常情報取得工程を通じて情報がもたらされた場合のみ対応選定工程が異常状態への対策を選定するように構成したので、もたらされた情報が異常に関するものであるか否かを対応選定手順が判定する必要が無くなり、これによって対応選定工程の処理が単純化され、処理内容が理解され易くなり、もって機能追加と改修に容易に対応することができるという効果を奏する。

また、請求項６にかかる発明によれば、異常情報取得手順を設け、この異常情報取得手順を通じて情報がもたらされた場合のみ対応選定手順が異常状態への対策を選定するように構成したので、もたらされた情報が異常に関するものであるか否かを対応選定手順が判定する必要が無くなり、これによって対応選定手順の処理が単純化され、処理内容が理解され易くなり、もって機能追加と改修に容易に対応することができるという効果を奏する。

また、請求項７にかかる発明によれば、異常への対応方法を個別のロジックとしてではなく情報としてもち、この対応方法に関する情報を共通のロジックで実行するように構成したので、対応方法を実行するための処理が単純化され、処理内容が理解され易くなり、もって機能追加と改修に容易に対応することができるという効果を奏する。

また、請求項８にかかる発明によれば、対応方法が複数存在する場合に事前に定義された優先順位によってどの対応方法を選択するかを決定するように構成したので、複数の選択肢から対応方法を選択するための処理が単純化され、処理内容が理解され易くなり、もって機能追加と改修に容易に対応することができるという効果を奏する。

また、請求項９にかかる発明によれば、事前に用意された対応方法で対応できない場合は他の手段に対応を委ねるように構成したので、対応策が見つからない場合の例外処理等を作りこむ必要がなくなって処理が単純化され、処理内容が理解され易くなり、もって機能追加と改修に容易に対応することができるという効果を奏する。

以下に添付図面を参照して、この発明にかかる異常対応プログラム、異常対応方法および画像形成装置の最良な実施の形態を詳細に説明する。ここでは、まず、画像形成装置の概要について説明し、その後に、この発明にかかる異常対応プログラム、異常対応方法および画像形成装置の構成および処理手順について説明することとする。なお、本実施の形態では、この発明を画像形成装置に適用した場合について説明するが、本発明はこれに限らず、異常情報の報告を受け付け、その異常情報の示す異常に対応する対応策を選定することが必要な各種プログラムおよび装置に適用することができる。

（画像形成装置の概要）
まず、画像形成装置の概要について説明する。近年、画像形成装置は、デジタル化にともなって機能の複合化が進んでいる。たとえば、帯電したドラムに電子制御されたレーザー光等を照射することで部分的に電荷を消失させて像を作り、電荷の残った部分にトナーを付着させてこれを紙に転写する印刷機能は、コピー機とプリンタとＦＡＸ機に共通して用いることができる。また、原稿をＣＣＤ（Charge Coupled Devices）によって読み取って電子情報化する機能はＦＡＸ機とスキャナに共通して用いることができる。

このような共通する機能を１台の筐体にまとめて統合したいわゆる複合機は、従来のコピー機、プリンタ、ＦＡＸ機およびスキャナがもっていた役割を１台で果たすことができ、オフィスのスペース効率の向上と機器導入コストの低減に貢献している。

また、近年の画像形成装置は、かかる複合化に加えてネットワーク化も進んでいる。図１は、画像形成装置が接続されたネットワーク環境の一例を示す説明図である。同図に示すように、近年のオフィスは、クライアントＰＣや各種サーバがＬＡＮ（Local Area Network）などのネットワークに接続された形態をとることが多い。

このようなネットワーク環境に接続された画像形成装置は、クライアントＰＣから要求により文書を印刷するいわゆるネットワークプリンタとしての機能以外に、クライアントＰＣから要求により文書をＦＡＸ送信するネットワークＦＡＸ機能や、スキャナ機能により読み取った文書を画像形成装置内のハードディスク装置に蓄積し、クライアントＰＣからネットワーク経由で取得させる文書蓄積機能等を備えるようになっている。

こうして複合化とネットワーク化の進展により必要となった多くの機能を実現するため、画像形成装置に搭載されるソフトウェアは、規模が大きく、複雑なものとなっている。そして、それにともなって、それらのソフトウェアの開発と維持管理のための工数も大幅に増大している。

図２は、画像形成装置に搭載されるソフトウェアの構成の変遷を示す説明図である。サービス層分離前アプリケーション４０１に示すように、複合化した画像形成装置に搭載されるソフトウェアは、コピーアプリケーション、ＦＡＸアプリケーション、スキャナアプリケーションなどの機能別に独立したアプリケーションとして作成されていた。

しかしながら、これらのアプリケーションは、ハードウェアリソースを制御するドライバー（サービス層相当部分）をそれぞれ独自に含んでいたため、メンテナンスに工数を要するものとなっていた。たとえば、コピーアプリケーションとＦＡＸアプリケーションは、どちらも出力結果を得るためにプロッタ装置を制御する必要があるが、この制御処理はコピーアプリケーションとＦＡＸアプリケーションにそれぞれ別個に実装されていた。このため、プロッタ装置に関する新しい制御方法を追加する場合には、コピーアプリケーションとＦＡＸアプリケーションの両方に手を加えなければならず、メンテナンスのための開発工数が重複して発生していた。

そこで、サービス層分離後アプリケーション４０２に示すように、サービス層分離前アプリケーション４０１のサービス層相当部分を括りだしてサービス層とし、その上層に位置するアプリケーション層の各アプリケーションがこのサービス層の機能を呼び出してハードウェアを制御する構成とした。かかる構成をとることにより、各アプリケーションに重複していた機能がサービス層に集約され、ソフトウェアのメンテナンスに要する労力が軽減された。

しかしながら、画像形成装置の多機能化、ネットワーク化がさらに進展するに従って各アプリケーションの複雑化と大規模化が大きく進み、開発とメンテナンスに要する工数が再び増大してきた。こうした中で、各アプリケーションに共通処理部分が存在することが問題となってきた。

具体的には、コピーアプリケーションやスキャナアプリケーションなどのアプリケーション層のアプリケーションは、サービス層の機能を呼び出すための処理や、ジョブ管理処理などの同様な内部処理を共通して有していた。このように、共通した処理を各アプリケーションが有していると、メンテナンスのための工数が重複して発生する。さらに、各アプリケーションが大規模で複雑になり、全体の仕様を理解するのが困難になることから、機能追加や不具合修正をおこなう際に不具合を発生させ易くなる。

この問題を解決するため、共通ルーチン分離アプリケーション４０３に示すように、共通処理部分を共通ルーチンとして括りだすこともできる。しかしながら、かかる共通ルーチンは、各アプリケーションにおいて微妙に異なる処理を共通化する必要があるため、共通ルーチン内部の処理が複雑化してしまい、開発者にとって把握が困難なものになる可能性が高い。また、たとえば、プリンタアプリケーションなどの新規アプリケーションを追加する必要が生じた場合には、共通ルーチンの改修が必要となり、その影響で共通ルーチンを使用する既存のアプリケーションに不具合が発生する可能性もある。

そこで、オブジェクト指向アプリケーション４０４に示すように、オブジェクト指向による設計手法を用いて、機能ごとに存在していた複数のアプリケーションを一つのアプリケーションに統合することを解決策とした。すなわち、各アプリケーションの共通処理部分をオブジェクトとして抽出し、この共通して利用されるオブジェクトとこれらのオブジェクトを利用してコピー機能やスキャナ機能といった個別の機能を実現するオブジェクトの集合体として統合アプリケーションを構築することとした。

ここで、オブジェクト指向とは、データとそれを操作する手続きをオブジェクトという単位で一体化し、ソフトウェアをこのオブジェクトの集合として設計／プログラミングする手法のことを指す。オブジェクト指向では、自立したオブジェクトがそれぞれ協調して処理を実現する形態がとられるが、協調に関係のないデータや手続き、すなわちオブジェクト内部でのみ使用されるデータや手続きは、カプセル化と呼ばれる仕組みによってオブジェクト内部に隠蔽される。このため、個々のオブジェクトの仕様が明確化され、設計者や開発者に理解され易いという利点を有する。また、継承と呼ばれる汎化／特化の仕組みを備え、既存のオブジェクトを再利用して新たなオブジェクトを作成することが容易であるという利点も有する。

このオブジェクト指向の考え方をとりいれると、たとえばプリンタ機能を追加するというような新規機能の追加の必要が生じた場合も、継承の仕組みによって既存の類似のオブジェクトとの差分のみを設計・実装することが可能になる。また、オブジェクト間のインターフェースも明確化されるため、改修要員が仕様を把握することも容易となる。このように、オブジェクト指向の考え方をとりいれることにより、開発工数を削減でき、仕様の理解不足による改修ミスを回避することができる。

図１０は、図２のサービス層分離後アプリケーション４０２の段階の画像形成装置のハードウェアおよびソフトウェアの構成を説明するための説明図である。同図に示すように、ハードウェア２００は、各種機器からなるハードウェアリソース２０１を有する。このハードウェアリソース２０１に含まれる機器には、スキャナ２０１ａ、プロッタ２０１ｂ、ＨＤＤ（Hard Disk Drive）２０１ｃ、ネットワークインターフェース２０１ｄなどがある。また、その他のリソース２０１ｅとして、たとえば、オペレーションパネルのような入出力デバイス等も有する。

このハードウェア２００を制御するソフトウェア１００は、３階層に階層化されている。最下層には、オペレーティングシステム１０３が存在する。その上層にはサービス層１０２が設けられ、最上層にはアプリケーション層１０１が設けられる。

オペレーティングシステム１０３は、サービス層１０２とアプリケーション層１０３とが動作するための基盤を提供する。そして、サービス層１０２は、各ハードウェアリソース（２０１ａ〜２０１ｅ）を制御するドライバーに相当し、スキャナ制御プログラム１０２ａ、プロッタ制御プログラム１０２ｂ、蓄積制御プログラム１０２ｃ、配信／メール送受信制御プログラム１０２ｄ、ＦＡＸ送受信制御プログラム１０２ｅ、ネットワーク通信制御プログラム１０２ｆおよびその他の制御プログラム１０２ｇを有する。

アプリケーション層１０３は、このサービス層１０２を利用してコピー機能やＦＡＸ機能等を実現する。アプリケーション層１０１には、コピーアプリケーション１２０、スキャナアプリケーション１３０、ファックスアプリケーション１４０およびプリンタアプリケーション１５０が個別に存在している。

たとえば、コピーアプリケーション１２０は、コピー機能を実現するために、スキャナ制御プログラム１０２ａ、プロッタ制御プログラム１０２ｂ、蓄積制御プログラム１０２ｃおよびその他の制御プログラム１０２ｇとデータの送受信をおこなう。また、ファックスアプリケーション１４０は、ファックス機能を実現するために、プロッタ制御プログラム１０２ｂ、蓄積制御プログラム１０２ｃ、ＦＡＸ送受信制御プログラム１０２ｅ、ネットワーク通信制御プログラム１０２ｆおよびその他の制御プログラム１０２ｇとデータの送受信をおこなう。このように、アプリケーション層１０１とサービス層１０２の通信は、複雑なものとなっており、それを実現するためのソフトウェアも理解が困難なものとなっていた。

図３は、図２のオブジェクト指向アプリケーション４０４の段階の画像形成装置のハードウェアおよびソフトウェアの構成を説明するための説明図である。同図に示すように、アプリケーション層１０１に存在した複数のアプリケーションは、統合アプリケーション１１０に統合されている。そして、各アプリケーションがそれぞれおこなっていたサービス層１０２との通信処理を、統合アプリケーション１１０を構成する所定のオブジェクトがおこなうようになっているので、アプリケーション層１０１とサービス層１０２の間の通信は、図１０と比較して単純になっており、システムが単純化され仕様の理解が容易になっているのが見て取れる。

このようにオブジェクト指向に基づいてアプリケーションを統合することにより、重複していた機能を集約することができ、また、システムの仕様の理解しやすくなり、機能追加や改修に容易に対応できるようになる。

（第１の実施の形態）
まず、本実施の形態に係る画像形成装置のハードウェア構成について説明する。図４は、本実施の形態に係る画像形成装置のハードウェア構成を示すブロック図である。同図に示すように、画像形成装置１は、コントローラ１０と、ＦＡＸ制御装置（ＦＣＵ（Fax Control Unit））３０と、ＵＳＢ（Universal Serial Bus）インターフェース４０と、ＩＥＥＥ１３９４（the Institute of Electrical and Electronics Engineers 1394）インターフェース５０と、エンジン部（Engine）６０とをＰＣＩ（Peripheral Component Interconnect）バス７０で接続した構成となる。

コントローラ１０は、画像形成装置１の全体制御をおこなう制御装置であり、ＣＰＵ１１と、システムメモリ（ＭＥＭ−Ｐ）１２と、ノースブリッジ（ＮＢ）１３と、サウスブリッジ（ＳＢ）１４と、ＡＳＩＣ（Application Specific Integrated Circuit）１６と、ローカルメモリ（ＭＥＭ−Ｃ）１７と、ハードディスクドライブ（ＨＤＤ（Hard Disk Drive））１８とを有し、ノースブリッジ（ＮＢ）１３とＡＳＩＣ１６との間をＡＧＰ（Accelerated Graphics Port）１５で接続した構成となる。

ＣＰＵ１１は、各種ソフトウェアを実行するための演算装置である。本実施の形態に係る異常対応プログラムを含む、画像形成装置１のコピー機能やＦＡＸ機能を実現するためのソフトウェア群は、ＭＥＭ−Ｃ１７もしくはＨＤＤ１８に記憶保持され、必要に応じてＭＥＭ−Ｐ１２にロードされてこのＣＰＵ１１により実行される。

ＭＥＭ−Ｐ１２は、プログラムやデータの格納用メモリ、プログラムやデータの展開用メモリ、プリンタの描画用メモリなどとして用いるシステムメモリであり、ＲＯＭ（Read Only Memory）１２ａとＲＡＭ(Random Access Memory)１２ｂとからなる。ＲＯＭ１２ａは、プログラムやデータの格納用メモリとして用いる読み出し専用のメモリであり、ＲＡＭ１２ｂは、プログラムやデータの展開用メモリ、プリンタの描画用メモリなどとして用いる書き込みおよび読み出し可能なメモリである。

ＮＢ１３およびＳＢ１４は、ＭＥＭ−Ｐ１２やＡＧＰ１５を制御する制御装置であり、ＮＢ１３を介してＣＰＵ１１とＭＥＭ−Ｐ１２とＳＢ１４とＡＧＰ１５とが接続される形をとる。ＮＢ１３は、ＡＧＰ１５を介してＡＳＩＣ１６とも接続され、その先にＰＣＩバス７０が接続される。

ＡＳＩＣ１６は、画像処理のための制御装置である。このＡＳＩＣ１６は、ＭＥＭ−Ｃ１７やＨＤＤ１８やオペレーションパネル２０のような周辺機器と接続され、これらの制御もおこなう。ＭＥＭ−Ｃ１７は、ＡＳＩＣ１６が画像処理をおこなう画像データ等を一時記憶する記憶部であり、ＨＤＤ１８は、各種ソフトウェア、フォントデータ、蓄積するよう指示された画像データ等を記憶する記憶部である。オペレーションパネル２０は、利用者の操作を受け付ける入力装置である。

ＰＣＩバス７０に接続されるＦＡＸ制御装置（ＦＣＵ）３０は、ＦＡＸ送受信を制御する制御装置である。ＵＳＢインターフェース４０およびＩＥＥＥ１３９４インターフェース５０は、外部機器を接続するためのインターフェースである。エンジン部（Engine）６０は、印刷処理をおこなう装置であり、たとえば白黒プロッタ、１ドラムカラープロッタ、４ドラムカラープロッタ、スキャナまたはファックスユニットなどからなる。ＰＣＩバス７０には、これら以外にネットワーク接続のためのインターフェース装置等も接続される。

次に、統合アプリケーション１１０の内部構成について説明する。図５は、統合アプリケーション１１０の内部構成を示すブロック図である。同図に示すように、統合アプリケーション１１０は、操作系サブシステム１１１と、管理系サブシステム１１２と、実行系サブシステム１１３とを有する。

操作系サブシステム１１１は、マンマシンインタフェースを担当するソフトウェア群である。具体的には、この操作系サブシステム１１１は、ユーザの要求を受け付ける処理と、この要求の実行を指示する処理と、この要求の実行状況と実行結果についての情報をユーザに提供する処理をおこなう。

さらに、操作系サブシステム１１１は、要求の実行状況として何らかの異常情報を取得した場合に、可能であれば自身で対応方法を判断して実行を指示する処理もおこなう。たとえば、文書のコピーをおこなう際に指定されたトレイに用紙がない場合、他に同じサイズの用紙を格納するトレイがあれば、そのトレイの用紙を使用してコピーをおこなうように指示をおこなう。このように、操作系サブシステム１１１が異常時の対応をおこなうことにより、ユーザに異常への対応方法を問い合わせる必要がなくなり、処理を迅速に完了させることができる。

管理系サブシステム１１２は、画像形成装置１の資源を管理するソフトウェア群である。具体的には、この管理系サブシステム１１２は、ハードウェアリソース２０１およびこのハードウェアリソース２０１が保持するデータ状態を管理するサービスをおこなう。

実行系サブシステム１１３は、ユーザからの要求の実行を担当するソフトウェア群である。具体的には、この実行系サブシステム１１３は、コピー要求がなされた場合には、原稿の読み取りから成果物の出力までの処理をおこなう。

操作系サブシステム１１１、管理系サブシステム１１２および実行系サブシステム１１３は、必要に応じて相互に処理を依頼してその結果を送り合う。このようにそれぞれのサブシステムが協調し合って、統合アプリケーション１１０全体として画像形成装置１に必要とされるサービスの提供をおこなう。

そして、操作系サブシステム１１１は、操作管理部１１１ａと操作制御部１１１ｂを有する。操作管理部１１１ａは、ユーザの要求を受け付ける処理と、この要求の実行状況と実行結果についての情報をユーザに提供する処理と、実行状況として異常が報告された場合にそれに対処する処理とをおこなう。操作制御部１１１ｂは、ユーザの要求の実行を実行系サブシステム１１３または管理系サブシステム１１２に指示する処理をおこなう。

次に、統合アプリケーション１１０のオブジェクトモデルについて説明する。図６は、統合アプリケーション１１０のＵＭＬクラス図である。ＵＭＬ（Unified Modeling Language）とは、ＯＭＧ（Object Management Group）が仕様を策定しているシステムモデリング言語であり、モデリングの成果を記述する記法を定義したものである。このＵＭＬは、オブジェクト指向によるソフトウェアの設計において広く用いられている。

同図に示すように、統合アプリケーション１１０は複数のパッケージを有し、また、統合アプリケーション１１０自体もひとつのパッケージとなっている。ここで、パッケージとは、オブジェクトモデルの構成要素（シンボル）をグループ化したものであり、ＵＭＬにおいては、左上にタブのついたフォルダの形をしたシンボルで表現される。また、各パッケージを相互に結ぶ直線は、各パッケージ間に処理依頼などの関連があることを示している。

図５に示すように、統合アプリケーション１１０は、操作系サブシステム１１１、管理系サブシステム１１２および実行系サブシステム１１３という３つのパッケージを有する。さらに、操作系サブシステム１１１は、操作管理部１１１ａと操作制御部１１１ｂという２つのパッケージを有する。また、操作系サブシステム１１１と管理系サブシステム１１２、操作系サブシステム１１１と実行系サブシステム１１３、および管理系サブシステム１１２と実行系サブシステム１１３の間には処理依頼などの関連があり、さらに、操作管理部１１１ａと操作制御部１１１ｂの間にも処理依頼などの関連がある。

次に、操作管理部１１１ａのクラス構成について説明する。なお、操作管理部１１１ａをオブジェクト指向に基づいて設計するにあたって、既存の処理を単純にオブジェクト化せず、機能追加や改修をより一層容易におこなうことができる構成をとっている。ここで、この構成について説明しておく。

図７−１は、既存の処理を単純にオブジェクト化した場合のオブジェクトモデルを説明するための説明図である。同図に示すように、このモデルでは、ユーザからの要求をユーザインターフェース制御部を経由して受け取る「操作者」と、「操作者」が受け取った要求を受け付けてそれを実現するために必要な処理を洗い出し、個々の処理の実行を指示する「受付」と、「受付」から指示された個別の処理の実行を操作制御部１１１ｂを経由して管理系サブシステム１１２もしくは実行系サブシステム１１３に依頼する「オプション」とが存在する。

「オプション」は、原稿の読み取り処理、印刷処理などの個別の処理ごとに専用のものが存在する。このため、たとえば、原稿を読み取ってこれを印刷し、さらに印刷結果にパンチ穴を開けるようにという要求が「操作者」からあった場合には、「受付」は、この要求を分析して、原稿の読み取り処理をおこなう「オプション」と印刷処理をおこなう「オプション」とパンチ処理をおこなう「オプション」とを選別し、これらに個別に指示を出すことになる。

そして、管理系サブシステム１１２もしくは実行系サブシステム１１３において何らかの異常が発生した場合には、その情報が操作制御部１１１ｂを経由して「オプション」に伝えられる。異常を知った「オプション」は、その障害が自身で対応可能であるか否かを判断し、対応可能である場合には操作制御部１１１ｂを経由して管理系サブシステム１１２もしくは実行系サブシステム１１３に対応を依頼する。対応不能な場合は、異常に関する情報を「受付」と「操作者」を通じてユーザインターフェース制御部に送り、ユーザにそれを通知して対処を求める。

例えば、文書のコピー中に用紙がなくなったという異常が伝えられた場合は、「オプション」は同じサイズの用紙を格納した別のトレイを使ってコピーを継続するように依頼する。このように「オプション」が自分自身で対応可能な障害の対応をおこなうことにより、ユーザは細かな異常に対応する煩わしさがなくなり、処理も迅速に完了する。

しかし、「オプション」にこのようなエラー処理を埋め込むと、各「オプション」の処理が複雑化し、機能追加と改修が困難になる恐れがある。「オプション」は、既に説明したとおり、原稿の読み取り処理、印刷処理などの個別の処理ごとに専用のものが存在するため種類が多く存在する。このように種類の多いクラスがそれぞれに異なる複雑な内部処理を抱え持つことは、処理の理解を難しいものにしてしまう可能性が高い。

そこで、操作管理部１１１ａをオブジェクト指向に基づいて設計するにあたって、エラー処理を「オプション」ではなく、「操作者」でおこなうように改めた。図７−２は、エラー処理を「操作者」でおこなう場合のオブジェクトモデルを説明するための説明図である。同図に示すように、管理系サブシステム１１２もしくは実行系サブシステム１１３からの異常情報を受け取るための「スタッフ」を設け、この「スタッフ」を経由して「操作者」が異常情報を取得しエラー処理をおこなう構成とした。

このモデルでは、管理系サブシステム１１２もしくは実行系サブシステム１１３において何らかの異常が発生した場合には、その情報が操作制御部１１１ｂを経由して「スタッフ」に伝えられる。「スタッフ」は、異常情報を「操作者」に伝え、「操作者」は、その異常に自身で対応できるかどうかを判断する。もし、対応できないと判断した場合には、異常情報をユーザインターフェース制御部に送り、ユーザにそれを通知して対処を求める。対応できると判断した場合は、対応方法を「受付」と「オプション」を通じて操作制御部１１１ｂに伝え、管理系サブシステム１１２もしくは実行系サブシステム１１３に実行を依頼する。

このような構成をとることにより、「オプション」が単純化され理解が容易になる反面、「操作者」が複雑化してしまう。これを避けるため、「操作者」は、異常への対処方法をロジックとしてではなく、優先順位をもった情報としてもつこととした。異常への対処方法をロジックとしてもつと、異常への対処方法が複雑になるにつれてプログラムのコード量が増大し、処理を理解するのが困難になる。

一方、異常への対処方法を優先順位をもった情報としてもつと、異常への対処方法が複雑になってもデータ量が増えるだけでコード量は変わらないため、処理を理解するのが困難になることはない。この場合、具体的には、異常の種類毎に０件以上の対処方法を優先順位をつけて保持しておき、異常が発生した場合はその異常に該当する対処方法のうちその時点で適用が可能で優先順位が最も高いものを選択して実行するというロジックを「操作者」に実装することになる。

また、「スタッフ」を設けたのは、「受付」を経由して取得される通常の実行経過情報と「スタッフ」を経由して取得される異常情報とを明確に分離し、「操作者」がエラー処理をおこなう必要があるか否かを容易に判断することができるようにするためである。このような構成にすることにより、「操作者」は、「スタッフ」を経由して情報を取得した場合のみエラー処理をおこなえばよいことになり、処理を単純化することができる。

このように「スタッフ」を経由して「操作者」が異常情報を取得してエラー処理をおこなう構成をとることにより、操作管理部１１１ａの処理を単純化することができ、単純にオブジェクト指向を適用した場合よりもさらに機能追加と改修への対応が容易になる。

図８は、操作管理部１１１ａのクラス構成を示すＵＭＬクラス図である。ここで、クラスとＵＭＬクラス図におけるクラスの記述方法について説明しておく。クラスとは、オブジェクトの設計図に相当する概念であり、オブジェクト内部に有する属性と操作や、他のオブジェクトとの関係を定義するものである。

クラスは、ＵＭＬクラス図においては、３段の区画を有する矩形として記述される。それぞれの区画は、上から、名前区画、属性区画および操作区画と呼ばれる。名前区画には、当該のクラスの名称が記述され、属性区画には、当該のクラスが有するデータ（属性）が記述され、操作区画には、当該のクラスが有する手続き（操作）が記述される。

このように、クラスは、データ（属性）を所持するための属性区画と、かかる属性の書き込みおよび読み出しをおこなう手続き（操作）を所持するための操作区画とを有している。これらのクラスは、プログラム（統合アプリケーション１１０）の一部として含まれるので、あらかじめＲＯＭ１２ａに格納されたこのプログラムが実行されると、各クラスはＲＡＭ１２ｂの所定領域に実体化され、属性区画に含まれる各データ（属性）がＲＡＭ１２ｂ上に展開される。したがって、クラスを実体化したオブジェクトは、ＲＡＭ１２ｂ上の各データ（属性）の書き込みおよび読み出しをすることが可能となる。

なお、クラス図において、属性や操作の左側に「−」記号を付した場合は、当該の属性や操作が外部のクラスに非公開であることを示し、「＋」記号を付した場合は、当該の属性や操作が外部のクラスに公開されていることを示す。また、操作については「リクエスト投入（）」のように「（）」記号を付することが通例であり、「（引数１，引数２）」のように、かかる操作に引き渡す引数を記述する場合もある。

図８に示すように、操作管理部１１１ａは、操作者クラス３１０と、受付クラス３２０と、オプションクラス３３０と、スタッフクラス３４０とを有する。なお、操作者クラス３１０およびスタッフクラス３４０は、特許請求の範囲における対応選定手順および異常情報取得手順にそれぞれ相当する。

操作者クラス３１０は、ユーザインターフェース制御部３５０からユーザの要求を受け取り、また、ユーザインターフェース制御部３５０に対して要求の実行経過と実行結果を報告するクラスである。さらに、操作者クラス３１０は、スタッフクラス３４０から異常情報を取得した場合にその異常に対する対応を検討し、可能であれば対応を指示する処理もおこなう。操作者クラス３１０は、属性として、要求内容３１０ａと目的３１０ｂを有し、操作として、要求する（）３１０ｃと問合せ（）３１０ｄと選択する（）３１０ｅとを有する。これらの属性と操作のうち、要求内容３１０ａと目的３１０ｂと選択する（）３１０ｅは、クラスの外部に公開されない。

要求内容３１０ａは、ユーザインターフェース制御部３５０から受け取ったユーザの要求を実現するための少なくとも一つの実現方法を優先順位とともに保持する。また、要求内容３１０ａは、現在選択されている実現方法がどれであるのかも保持する。目的３１０ｂは、ユーザインターフェース制御部３５０から受け取ったユーザの要求が求めているものを保持する。なお、要求内容３１０ａおよび目的３１０ｂは、操作者クラス３１０を実体化したオブジェクトが生成される際にＲＡＭ１２ｂ上に展開され、書き込みおよび読み出しをすることが可能となる。

要求する（）３１０ｃは、ユーザインターフェース制御部３５０からの要求を受け付け、受付クラス３２０のオブジェクトに対し要求への対応を依頼する処理である。また、問合せ（）３１０ｄは、スタッフクラス３４０のオブジェクトから異常情報を受け取る処理である。

選択する（）３１０ｅは、スタッフクラス３４０のオブジェクトから異常情報を受け取った場合に、選択可能な対応方法があるかどうかを判断し、選択可能な対応方法がある場合にはそれを選択して、受付クラス３２０のオブジェクトに対して実行を依頼する処理である。選択する（）３１０ｅは、選択可能な対応方法がない場合には、異常情報をユーザインターフェース制御部３５０へ引き渡してユーザに対応方法を決めさせる。

ここで、操作者クラス３１０の動作を例を挙げて説明しておく。たとえば、ＦＡＸ送信には、スキャナ部で読み込んだ文書データを逐次送信する直接送信と、スキャナ部で読み込んだ文書をいったん記憶装置に記憶しておき、読み込みが全て終了した時点で一括して送信する蓄積送信とがあるが、ユーザが直接送信を選択した場合、その旨が要求する（）３１０ｃの呼び出しによってユーザインターフェース制御部から操作者クラス３１０のオブジェクトに伝えられる。

呼び出された要求する（）３１０ｃは、伝えられた「直接送信によるＦＡＸ送信」という情報を属性区画のデータ（属性）である目的３１０ｂに設定し、それを実現するための方法として「直接送信によるＦＡＸ送信」を第１の優先順位で、結果として同じ効果が得られる「蓄積送信によるＦＡＸ送信」を第２の優先順位で属性区画のデータ（属性）である要求内容３１０ａに設定する。このような、目的３１０ｂと要求内容３１０ａの設定値の組合せは、事前に記憶部に記憶しておくことにより簡単に呼び出して設定することができる。

そして、要求する（）３１０ｃは、第１の優先順位である「直接送信によるＦＡＸ送信」を選択したことを属性区画のデータ（属性）である要求内容３１０ａに記録して、その実行を受付クラス３２０のオブジェクトに依頼する。

これにより「直接送信によるＦＡＸ送信」を実行する準備がなされることとなるが、その直後にＦＡＸの受信がおこなわれてＦＡＸ装置がその処理に占有されてしまうと、ＦＡＸ送信をおこなうことができなくなり、その旨が問合せ（）３１０ｄの呼び出しによりスタッフクラス３４０のオブジェクトから操作者クラス３１０のオブジェクトに伝えられる。

問合せ（）３１０ｄは、内部処理として選択する（）３１０ｅを呼び出して対応策を検討する。選択する（）３１０ｅは、現在選択されている「直接送信によるＦＡＸ送信」の次の優先順位で「蓄積送信によるＦＡＸ送信」が属性区画のデータ（属性）である要求内容３１０ａに設定されているので、これを対応方法として採用し、要求内容３１０ａにこれを選択したことを記録して、受付クラス３２０のオブジェクトに「蓄積送信によるＦＡＸ送信」の実行を依頼する。

「蓄積送信によるＦＡＸ送信」は、ＦＡＸ受信中でも処理をすすめることができるため、結果としてユーザの目的をより短時間で処理できることになる。このように、操作者クラス３１０は、異常発生時に自立的に対応をおこなうことにより、ユーザを煩わせることなく、ユーザの希望する処理を迅速に完了させることができる。なお、属性区画のデータ（属性）である要求内容３１０ａに現在選択されているものよりも優先順位の低い対応方法が存在しない場合は、異常情報をユーザインターフェース制御部に引き渡して、ユーザに異常への対処を求めることになる。

受付クラス３２０は、操作者クラス３１０のオブジェクトの依頼を受け付けて、依頼された要求を実現するために必要なオプションクラス３３０のオブジェクトを選別し、選別したオブジェクトに作業を依頼するクラスである。受付クラス３２０は、操作として、要求する（）３２０ａを有する。

要求する（）３２０ａは、操作者クラス３１０のオブジェクトからの依頼を受け付け、依頼された要求を実現するために必要なオプションクラス３３０のオブジェクトを選別し、選別したオブジェクトに作業を依頼する処理である。

オプションクラス３３０は、受付クラス３２０のオブジェクトから依頼された作業を実現するために操作制御部１１１ｂに作業を依頼するクラスである。オプションクラス３３０は、操作として、変更する（）３３０ａを有する。変更する（）３３０ａは、受付クラス３２０のオブジェクトからの依頼を受け、操作制御部１１１ｂに作業を依頼する処理である。

スタッフクラス３４０は、操作制御部１１１ｂを経由して管理系サブシステム１１２もしくは実行系サブシステム１１３から処理の異常に関する情報を取得し、その情報を操作者クラス３１０のオブジェクトに引き渡すクラスである。スタッフクラス３４０は、操作として、状況報告（）３４０ａを有する。状況報告（）３４０ａは、処理の異常に関する情報を取得し、その情報を操作者クラス３１０のオブジェクトに引き渡す処理である。

次に、図８に示した各クラスの関係について説明する。同図に示すように、ＵＭＬクラス図においては、クラス間に何らかの関係がある場合には、それらのクラスを表す矩形の間が直線で結ばれる。この直線の両端付近の文字はクラスのロールを表し、数字はクラスの多重度を表す。ここで、ロールとは、直線で結ばれた他方のクラスに対する当該のクラスの役割のことであり、多重度とは、直線で結ばれた他方のクラスのオブジェクトと関連付けられて生成されるオブジェクトの数のことである。

まず、操作者クラス３１０と受付クラス３２０の関係について説明する。受付クラス３２０のオブジェクトは、操作管理部１１１ａにひとつだけ存在する。この受付クラス３２０のオブジェクトは、０以上存在する操作者クラス３１０のオブジェクトからの依頼を受け付ける。このように、操作者クラス３１０と受付クラス３２０は、「顧客」と「依頼先」という関係をなしている。

次に、受付クラス３２０とオプションクラス３３０の関係について説明する。原稿の読み取り処理、印刷処理などの個別の処理ごとに存在するオプションクラス３３０のオブジェクトは、操作管理部１１１ａにひとつだけ存在する受付クラス３２０のオブジェクトが依頼された処理の実行要求を受け付ける。このように、受付クラス３２０とオプションクラス３３０は、「仲介者」と「依頼先」という関係をなしている。

次に、操作者クラス３１０とスタッフクラス３４０の関係について説明する。操作管理部１１１ａにひとつだけ存在するスタッフクラス３４０のオブジェクトは、０以上存在する操作者クラス３１０のオブジェクトに当該のオブジェクトの要求を実行する際に発生した異常情報を引き渡す。このように、操作者クラス３１０とスタッフクラス３４０は、「報告先」と「情報提供者」という関係をなしている。

このように、操作者クラス３１０、受付クラス３２０、オプションクラス３３０およびスタッフクラス３４０の各オブジェクトは、相互に関連し合い、協調して、操作管理部１１１ａに必要な機能を実現している。

次に、図８に示した各クラスの操作の実行手順について例を挙げて説明する。図９は、管理系サブシステム１１２もしくは実行系サブシステム１１３で異常が発生した場合の操作の実行手順を示すＵＭＬシーケンス図である。

ここで、ＵＭＬシーケンス図について説明しておく。図９の上部に並んだ矩形は、それぞれがクラスのオブジェクトを示している。各オブジェクトから下方に伸びた線は、各オブジェクトが生存していることを示す線（ライフライン）であり、上方から下方に向かって時間が流れているものとみなされる。この線上に存在する細長い矩形は、当該のオブジェクトが実際に活動している期間（活性期間）を示す。

各ライフラインの間を結ぶ横向きの矢印は、オブジェクトに含まれるの操作の実行を示す。具体的には、この矢印は、矢印の元のオブジェクトが、矢印の先のオブジェクトに含まれる操作を呼び出すことを示す。また、矢印が自分自身のオブジェクトを指している場合は、オブジェクトが自分に含まれる操作を自身で呼び出すことを意味する。

図９に示すように、管理系サブシステム１１２もしくは実行系サブシステム１１３で異常が発生した場合は、スタッフクラス３４０のオブジェクトの状況報告（）３４０ａが呼び出される（ステップＳ１０１）。スタッフクラス３４０のオブジェクトは、異常が発生した処理の要求元である操作者クラス３１０のオブジェクトの問合せ（）３１０ｄを呼び出して異常を通知する（ステップＳ１０２）。

異常の通知を受けた操作者クラス３１０のオブジェクトは、自身の選択する（）３１０ｅを呼び出して異常に対処するための判断処理をおこなう（ステップＳ１０３）。この処理において対応方法がみつかった場合には、その実行を受付クラス３２０のオブジェクトに依頼する。

対処方法がみつからなかった場合には、ユーザインターフェース制御部３５０に異常を通知し（ステップＳ１０４）、オペレーションパネル等に異常が発生した旨を表示させてユーザに対処を求める。そして、ユーザが何らかの対処をおこなうと、ユーザインターフェース制御部３５０が操作者クラス３１０のオブジェクトの要求する（）３１０ｃを呼び出してユーザの要求を伝える（ステップＳ１０５）。呼び出された操作者クラス３１０のオブジェクトは、その要求の実行を受付クラス３２０のオブジェクトに依頼し、その依頼はオプションクラス３３０のオブジェクト等を経由して管理系サブシステム１１２もしくは実行系サブシステムに伝えられて実行される。

上述してきたように、本実施の形態では、オブジェクト指向設計により異常対応を含む操作管理の仕組みを構築し、さらに操作者クラス３１０が対応策を定義した情報に基づいて一括して異常情報への対応をおこなうように構成したので、異常対応の機能を効率よく実現することができる。

以上のように、本発明に係る異常対応プログラム、異常対応方法および画像形成装置は、各種装置における異常対応処理の選択に有用であり、特に、機能を効率よく実現し、機能追加や改修を容易におこなうことが必要な場合に適している。

画像形成装置が接続されたネットワーク環境の一例を示す説明図である。 画像形成装置に搭載されるソフトウェアの構成の変遷を示す説明図である。 図２のオブジェクト指向アプリケーションの段階の画像形成装置のハードウェアおよびソフトウェアの構成を説明するための説明図である。 本実施の形態に係る画像形成装置のハードウェア構成を示すブロック図である。 統合アプリケーションの内部構成を示すブロック図である。 統合アプリケーションのＵＭＬクラス図である。 既存の処理を単純にオブジェクト化した場合のオブジェクトモデルを説明するための説明図である。 エラー処理を「操作者」でおこなう場合のオブジェクトモデルを説明するための説明図である。 操作管理部のクラス構成を示すＵＭＬクラス図である。 管理系サブシステムもしくは実行系サブシステムで異常が発生した場合の操作の実行手順を示すＵＭＬシーケンス図である。 図２のサービス層分離後アプリケーションの段階の画像形成装置のハードウェアおよびソフトウェアの構成を説明するための説明図である。

符号の説明

１ 画像形成装置
１０ コントローラ
１１ ＣＰＵ
１２ ＭＥＭ−Ｐ
１２ａ ＲＯＭ
１２ｂ ＲＡＭ
１３ ＮＢ
１４ ＳＢ
１５ ＡＧＰ
１６ ＡＳＩＣ
１７ ＭＥＭ−Ｃ
１８ ＨＤＤ
２０ オペレーションパネル
３０ ＦＣＵ
４０ ＵＳＢインターフェース
５０ ＩＥＥＥ１３９４インターフェース
６０ エンジン部（Engine）
７０ ＰＣＩバス
１００ ソフトウェア
１０１ アプリケーション層
１０２ サービス層
１０２ａ スキャナ制御プログラム
１０２ｂ プロッタ制御プログラム
１０２ｃ 蓄積制御プログラム
１０２ｄ 配信／メール送受信制御プログラム
１０２ｅ ＦＡＸ送受信制御プログラム
１０２ｆ ネットワーク通信制御プログラム
１０２ｇ その他の制御プログラム
１０３ オペレーティングシステム
１１０ 統合アプリケーション
１１１ 操作系サブシステム
１１１ａ 操作管理部
１１１ｂ 操作制御部
１１２ 管理系サブシステム
１１３ 実行系サブシステム
１２０ コピーアプリケーション
１３０ スキャナアプリケーション
１４０ ファックスアプリケーション
１５０ プリンタアプリケーション
２００ ハードウェア
２０１ ハードウェアリソース
２０１ａ スキャナ
２０１ｂ プロッタ
２０１ｃ ＨＤＤ
２０１ｄ ネットワークインターフェース
２０１ｅ その他のリソース
３１０ 操作者クラス（対応選定手順）
３１０ａ 要求内容
３１０ｂ 目的
３１０ｃ 要求する（）
３１０ｄ 問合せ（）
３１０ｅ 選択する（）
３２０ 受付クラス
３２０ａ 要求する（）
３３０ オプションクラス
３３０ａ 変更する（）
３４０ スタッフクラス（異常情報取得手順）
３４０ａ 状況報告（）
４０１ サービス層分離前アプリケーション
４０２ サービス層分離後アプリケーション
４０３ 共通ルーチン分離アプリケーション
４０４ オブジェクト指向アプリケーション

Claims (9)

1. 所定の処理をおこなう処理実行手段において発生した異常に係る異常情報を受け付け、該異常への対応をおこなう異常対応プログラムであって、
   前記処理実行手段から前記異常情報を受け付ける異常情報取得手順と、
   前記異常情報取得手順により受け付けられた前記異常情報の示す前記異常への対応策を選定する対応選定手順と
   をコンピュータに実行させることを特徴とする異常対応プログラム。
2. 前記対応選定手順は、前記処理実行手段に前記所定の処理をおこなわせるための実現策に係る情報を少なくとも一つ保持し、この実現策に係る情報のひとつを対応策として選択することを特徴とする請求項１に記載の異常対応プログラム。
3. 前記対応選定手順は、前記実現策に係る情報を優先順位をつけて保持し、この実現策に係る情報のうち未実施で且つ最も優先順位の高いものを対応策として選択することを特徴とする請求項２に記載の異常対応プログラム。
4. 前記対応選定手順は、前記実現策に係る情報に選択可能なものがない場合には、前記異常情報取得手段により取得された当該の異常情報を他の対応手段に転送することを特徴とする請求項２または３に記載の異常対応プログラム。
5. 所定の処理をおこなう処理実行手段において発生した異常に係る異常情報を受け付け、該異常への対応をおこなう異常対応方法であって、
   前記処理実行手段から前記異常情報を受け付ける異常情報取得工程と、
   前記異常情報取得工程により受け付けられた前記異常情報の示す前記異常への対応策を選定する対応選定工程と
   を含んだことを特徴とする異常対応方法。
6. 所定の処理をおこなう処理実行手段において発生した異常に係る異常情報を受け付け、該異常への対応をおこなう異常対応プログラムを制御ソフトウェアの一部として有する画像形成装置であって、
   前記処理実行手段から前記異常情報を受け付ける異常情報取得手順と、
   前記異常情報取得手順により受け付けられた前記異常情報の示す前記異常への対応策を選定する対応選定手順と
   をコンピュータに実行させることを特徴とする画像形成装置。
7. 前記対応選定手順は、前記処理実行手段に前記所定の処理をおこなわせるための実現策に係る情報を少なくとも一つ保持し、この実現策に係る情報のひとつを対応策として選択することを特徴とする請求項６に記載の画像形成装置。
8. 前記対応選定手順は、前記実現策に係る情報を優先順位をつけて保持し、この実現策に係る情報のうち未実施で且つ最も優先順位の高いものを対応策として選択することを特徴とする請求項７に記載の画像形成装置。
9. 前記対応選定手順は、前記実現策に係る情報に選択可能なものがない場合には、前記異常情報取得手段により取得された当該の異常情報を他の対応手段に転送することを特徴とする請求項７または８に記載の画像形成装置。

Images