JP4712248B2 - 画像形成装置およびソフトウェア診断方法 - Google Patents
画像形成装置およびソフトウェア診断方法 Download PDFInfo
- Publication number
- JP4712248B2 JP4712248B2 JP2001264888A JP2001264888A JP4712248B2 JP 4712248 B2 JP4712248 B2 JP 4712248B2 JP 2001264888 A JP2001264888 A JP 2001264888A JP 2001264888 A JP2001264888 A JP 2001264888A JP 4712248 B2 JP4712248 B2 JP 4712248B2
- Authority
- JP
- Japan
- Prior art keywords
- application
- program
- diagnostic
- applications
- image forming
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Accessory Devices And Overall Control Thereof (AREA)
- Control Or Security For Electrophotography (AREA)
- Debugging And Monitoring (AREA)
- Facsimiles In General (AREA)
Description
【０００１】
【発明の属する技術分野】
この発明は、プリンタ、コピーまたはファクシミリなどの画像形成処理にかかるユーザサービスを提供する際に動作するコントロールサービスやアプリケーションの診断を行うことができる画像形成装置およびこのような画像形成装置で実行されるソフトウェア診断方法に関するものである。
【０００２】
【従来の技術】
近年、プリンタ、コピー、ファクシミリ、スキャナなどの各装置の機能を１つの筐体内に収納した画像形成装置（以下、「複合機」という。）が一般的に知られている。この複合機は、１つの筐体内に表示部、印刷部および撮像部などを設けるとともに、プリンタ、コピーおよびファクシミリ装置にそれぞれ対応する３種類のソフトウェアを設け、ソフトウェアの切り替えによって、当該装置をプリンタ、コピー、スキャナまたはファクシミリ装置として動作させるものである。
【０００３】
このような複合機では、電源投入の際にＯＳ（Operating System）が起動する前に、いわゆるＢＩＯＳ（Basic Input/Output System）内で診断プログラムが動作し、メモリ、セントロインタフェース、ネットワークインタフェースなどのハードウェア資源のエラーチェックを行うことが一般的になっている。
【０００４】
ところで、従来の複合機では、内部にプリンタ、コピー、スキャナおよびファクシミリ装置に対応するソフトウェア（汎用ＯＳを含む）をそれぞれ別個に設ける構成となっており、各ソフトウェアの開発に多大の時間を要する。このため、出願人は、表示部、印刷部および撮像部などの画像形成処理で使用されるハードウェア資源を有し、プリンタ、コピーまたはファクシミリなどの各ユーザサービスにそれぞれ固有の処理を行うアプリケーションを複数搭載し、これらのアプリケーションとハードウェア資源との間に介在して、ユーザサービスを提供する際に、アプリケーションの少なくとも２つが共通的に必要とするハードウェア資源の管理、実行制御並びに画像形成処理を行う各種コントロールサービスからなるプラットホームを備えた画像形成装置を発明した。この画像形成装置によれば、アプリケーションの少なくとも２つが共通的に必要とするハードウェア資源の管理、実行制御並びに画像形成処理を行うプラットホームを備えた構成とすることによって、ソフトウェア開発の効率化を図るとともに、装置全体としての生産性を向上させることが可能となる。
【０００５】
【発明が解決しようとする課題】
このような複合機では、アプリケーションと、アプリケーションの少なくとも２つが共通的に必要とするサービスを提供するコントロールサービスを有する構成となっているため、ユーザにサービスを提供するためには、ハードウェア資源の他、各アプリケーションおよび各コントロールサービスが正常に動作している必要がある。
【０００６】
しかしながら、従来は診断プログラムによってハードウェア資源のエラーチェックしか行っていないため、アプリケーションやコントロールサービスにエラーが生じてユーザサービスの機能が停止している場合でも、診断プログラムによるハードウェア資源の診断結果は正常として通知されてしまう。このため、ユーザまたは保守作業者は、画像形成装置で生じた障害の原因を認識できないという問題がある。
【０００７】
この発明は上記に鑑みてなされたもので、コントロールサービスやアプリケーションなどのソフトウェアのエラーを検知することにより、画像形成装置に障害が生じた場合の原因究明を正確かつ速やかに行える画像形成装置を得ることを目的とする。
【０００８】
【課題を解決するための手段】
上記目的を達成するため、本発明にかかる画像形成装置は、プリンタ部及びスキャナ部のうち、少なくとも一方を含むハードウェア資源と、前記ハードウェア資源の制御を行うプログラムと、前記プログラムと、画像形成処理にかかるユーザサービスにそれぞれ固有の処理を行う複数のアプリケーションと、前記プログラムが正常に動作しているかを診断する診断アプリケーションとを動作させるオペレーティングシステムと、を備え、前記プログラムは、あらかじめ定義された関数により前記複数のアプリケーションからの処理要求を受信可能とするアプリケーションプログラムインターフェースを有し、前記複数のアプリケーションから前記アプリケーションプログラムインターフェースを介して受信した処理要求に基づいて前記ハードウェア資源を制御し、前記診断アプリケーションは、前記プログラム及び前記複数のアプリケーションが起動されたときに、該起動されたプログラム及び複数のアプリケーションが正常に動作しているか否かを診断することを特徴とする。
【０００９】
なお、画像形成処理にかかるユーザサービスとは、プリンタ、コピーまたはファクシミリなどの画像形成処理においてユーザに提供するサービスをいう。
【００１０】
また、本発明にかかるソフトウェア診断方法は、画像形成装置で実行されるソフトウェア診断方法であって、前記画像形成装置は、プリンタ部及びスキャナ部のうち、少なくとも一方を含むハードウェア資源と、 前記ハードウェア資源の制御を行うプログラムと、前記プログラムと、画像形成処理にかかるユーザサービスにそれぞれ固有の処理を行う複数のアプリケーションと、前記プログラムが正常に動作しているかを診断する診断アプリケーションとを動作させるオペレーティングシステムと、を備え、前記プログラムは、あらかじめ定義された関数により前記複数のアプリケーションからの処理要求を受信可能とするアプリケーションプログラムインターフェースを有し、前記プログラムが、前記複数のアプリケーションから前記アプリケーションプログラムインターフェースを介して受信した処理要求に基づいて前記ハードウェア資源を制御し、前記診断アプリケーションが、前記プログラム及び前記複数のアプリケーションが起動されたときに、該起動されたプログラム及び複数のアプリケーションが正常に動作しているかを診断することを特徴とする。
【００３９】
【発明の実施の形態】
以下に添付図面を参照して、この発明にかかる画像形成装置およびソフトウェア診断方法の好適な実施の形態を詳細に説明する。
【００４０】
（実施の形態１）
図１は、この発明の実施の形態１である画像形成装置（以下、「複合機」という）の構成を示すブロック図である。図１に示すように、複合機１００は、白黒ラインプリンタ（B&W LP）１０１と、カラーラインプリンタ（Color LP）１０２と、スキャナ、ファクシミリなどのハードウェアリソース１０３などを有するとともに、プラットホーム１２０とアプリケーション１３０とから構成されるソフトウェア群１１０とを備えている。
【００４１】
プラットホーム１２０は、アプリケーションからの処理要求を解釈してハードウェア資源の獲得要求を発生させるコントロールサービスと、一または複数のハードウェア資源の管理を行い、コントロールサービスからの獲得要求を調停するシステムリソースマネージャ（ＳＲＭ）１２３と、汎用ＯＳ１２１とを有する。
【００４２】
コントロールサービスは、複数のサービスモジュールから形成され、ＳＣＳ（システムコントロールサービス）１２２と、ＥＣＳ（エンジンコントロールサービス）１２４と、ＭＣＳ（メモリコントロールサービス）１２５と、ＯＣＳ（オペレーションパネルコントロールサービス）１２６と、ＦＣＳ（ファックスコントロールサービス）１２７と、ＮＣＳ（ネットワークコントロールサービス）１２８とから構成される。なお、このプラットホーム１２０は、あらかじめ定義された関数により前記アプリケーション１３０から処理要求を受信可能とするアプリケーションプログラムインタフェース（ＡＰＩ）を有する。
【００４３】
汎用ＯＳ１２１は、ＵＮＩＸなどの汎用オペレーティングシステムであり、プラットホーム１２０並びにアプリケーション１３０の各ソフトウェアをそれぞれプロセスとして並列実行する。
【００４４】
コントロールサービスのそれぞれは、いずれもプロセスとして動作し、処理単位あるいは一連の処理ごとの単位を一スレッドとした一または複数のスレッドを有している。
【００４５】
また、コントロールサービスのそれぞれは、後述する診断アプリ１１７から発行される診断関数を実装している。この診断関数は、各コントロールサービスの動作確認を行うために擬似的な処理を行うものであり、ハードウェア資源にアクセスせずに内部で完結するような各コントロールサービスの最低限の処理を実行する。そして、その処理結果によって正常またはエラー発生を示す関数戻り値を呼び出し元の診断アプリ１１７に返すようになっている。
【００４６】
ＳＲＭ１２３のプロセスは、ＳＣＳ１２２とともにシステムの制御およびリソースの管理を行うものであり、スキャナ部やプリンタ部などのエンジン、メモリ、ＨＤＤファイル、ホストＩ／Ｏ（セントロＩ／Ｆ、ネットワークＩ／Ｆ、ＩＥＥＥ１３９４ Ｉ／Ｆ、ＲＳ２３２Ｃ Ｉ／Ｆなど）のハードウェア資源を利用する上位層からの要求にしたがって調停を行い、実行制御を行う。
【００４７】
具体的には、このＳＲＭ１２３は、要求されたハードウェア資源が利用可能であるか（他の要求により利用されていないかどうか）を判断し、利用可能であれば要求されたハードウェア資源が利用可能である旨を上位層に伝える。また、ＳＲＭ１２３は、上位層からの要求に対してハードウェア資源の利用スケジューリングを行い、要求内容（例えば、プリンタエンジンにより紙搬送と作像動作、メモリ確保、ファイル生成など）を直接実施している。
【００４８】
ＳＣＳ１２２のプロセスは、アプリ管理、操作部制御、システム画面表示、ＬＥＤ表示、リソース管理、割り込みアプリ制御を行う。
【００４９】
ＥＣＳ１２４のプロセスは、白黒ラインプリンタ（B&W LP）１０１、カラーラインプリンタ（Color LP）１０２、スキャナ、ファクシミリなどからなるハードウェアリソース１０３のエンジンの制御を行う。
【００５０】
ＭＣＳ１２５のプロセスは、画像メモリの取得および解放、ハードディスク装置（ＨＤＤ）の利用、画像データの圧縮および伸張などを行う。
【００５１】
ＯＣＳ１２６のプロセスは、オペレータと本体制御間の情報伝達手段となる操作パネル（オペレーションパネル）の制御を行う。
【００５２】
ＦＣＳ１２７のプロセスは、システムコントローラの各アプリ層からＰＳＴＮ／ＩＳＤＮ網を利用したファクシミリ送受信、ＢＫＭ（バックアップＳＲＡＭ）で管理されている各種ファクシミリデータの登録／引用、ファクシミリ読みとり、ファクシミリ受信印刷、融合送受信を行うためのＡＰＩを提供する。
【００５３】
ＮＣＳ１２８は、ネットワークＩ／Ｏを必要とするアプリケーションに対して共通に利用できるサービスを提供するためのプロセスであり、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分けたり、アプリケーションからデータをネットワーク側に送信する際の仲介を行う。
【００５４】
アプリケーション１３０は、ページ記述言語（ＰＤＬ）、ＰＣＬおよびポストスクリプト（ＰＳ）を有するプリンタ用のアプリケーションであるプリンタアプリ１１１と、コピー用アプリケーションであるコピーアプリ１１２と、ファクシミリ用アプリケーションであるファックスアプリ１１３と、スキャナ用アプリケーションであるスキャナアプリ１１４と、ネットワークファイル用アプリケーションであるネットファイルアプリ１１５と、工程検査用アプリケーションである工程検査アプリ１１６と診断用のアプリケーションである診断アプリ１１７を有している。
【００５５】
アプリケーションのそれぞれは、いずれもプロセスとして動作する。診断アプリ１１７を除く各アプリも、コントロールサービスと同様に、診断アプリ１１７から関数呼び出しされる診断関数を実装している。この診断関数は、各アプリの動作確認を行うために擬似的な処理を行うものであり、プリンタ、コピーまたはファクシミリなどの画像形成処理にかかるユーザサービスの機能を停止し、かつコントロールサービスへのアクセスを行わずに内部で完結するような最低限の処理を実行する。そして、その処理結果によって正常またはエラー発生を示す関数戻り値を呼び出し元の診断アプリ１１７に返すようになっている。
【００５６】
診断アプリ１１７は、その起動時、すなわち複合機１００が電源投入され、汎用ＯＳ１２１、プラットホーム１２０、アプリケーション１３０が順に起動されたときに、各コントロールサービス、ＳＲＭ１２３および各アプリに対して順番に診断関数の呼び出しを行う。そしてそれらの関数戻り値が正常かエラー発生かをチェックしてエラー発生の関数戻り値の場合には、その関数戻り値からソフトウェアエラーの種類を判断し、そのソフトウェアエラーの種類とソフトウェアエラーが生じているソフトウェア（各コントロールサービス、ＳＲＭ１２３、各アプリ）の名称などのエラー情報をオペレーションパネルのディスプレイに表示する。また、これらのエラー情報は、ＮＣＳ１２８が正常動作している場合にはＮＣＳ１２８を介して、公衆回線などのネットワークを利用してサービスセンタのホストコンピュータなどへ送信するようになっている。なお、診断アプリ１１７は本発明における診断手段を構成するものである。
【００５７】
次に、このように構成された実施の形態１の複合機によるコントロールサービスおよびアプリケーション１３０の診断処理について説明する。図２は、実施の形態１の複合機における電源投入からコントロールサービスおよびアプリケーション１３０の診断処理までの全体の流れを示すフローチャートである。
【００５８】
複合機１００に電源が投入されると（ステップＳ２０１）、まずハードウェア資源の初期化が行われ（ステップＳ２０２）、ついでハードウェア資源のエラーチェックによる診断処理が実行される（ステップＳ２０３）。ハードウェア資源の診断が正常に終了した場合には、引き続き汎用ＯＳ１２１が起動される（ステップＳ２０４）。汎用ＯＳ１２１が正常に起動した場合には、プログラム起動部（図示せず）によって、まず汎用ＯＳ１２１上でコントロールサービスおよびＳＲＭ１２３からなるプラットホーム１２０の起動が行われ（ステップＳ２０５）、ついでプラットホーム１２０上にアプリケーション１３０の起動が行われる（ステップＳ２０６）。このとき、同時に診断アプリ１１７も起動する。そして、起動した診断アプリ１１７によって、コントロールサービスおよびアプリケーション１３０のそれぞれに対してソフトウェアエラーのチェックによる診断処理が実行される（ステップＳ２０７）。
【００５９】
図３は、実施の形態１の複合機１００の診断アプリ１１７によるコントロールサービスおよびアプリケーションの診断の処理手順を示すフローチャートである。図４は、実施の形態１の複合機１００における診断アプリ１１７と各コントロールサービスまたは各アプリのプロセス間通信の状態を示す模式図である。
【００６０】
診断アプリ１１７のプロセスは起動されると、まず各コントロールサービスおよび各アプリのプロセスをサーバプロセスとしたクライアントプロセスとして動作し、各コントロールサービスおよび各アプリのプロセスに対して順番に診断関数の呼び出しを行う（ステップＳ３０１）。そして、診断アプリ１１７は、関数戻り値待ち状態となる。
【００６１】
各コントロールサービスまたは各アプリのプロセスでは、診断アプリ１１７から診断関数呼び出しを受信すると（ステップＳ４０１）、診断関数により上述の擬似的な処理を実行し（ステップＳ４０２）、その処理結果を正常またはエラー発生の旨の関数戻り値として診断アプリ１１７へ返す（ステップＳ４０３）。なお、エラーが発生している場合には、戻り値の数値によってソフトウェアエラーの種類を識別できるように、エラー時の戻り値をあらかじめ定義しておく。
【００６２】
このように、診断アプリ１１７のプロセスから各コントロールサービスまたは各アプリのプロセスへの診断関数の呼び出しと、各コントロールサービスまたは各アプリのプロセスから診断アプリ１１７のプロセスへの関数戻り値の送信というプロセス間通信によって、診断アプリ１１７によるコントロールサービスまたはアプリケーション１３０のソフトウェアエラーの検知が行われる。
【００６３】
診断アプリ１１７は、関数戻り値を受信すると（ステップＳ３０２）、その関数戻り値によって各コントロールサービスまたは各アプリが正常動作しているか否かを判断する（ステップＳ３０３）。そして、エラーが発生している場合には、関数戻り値の数値によってソフトウェアエラーの種別を特定し（ステップＳ３０４）、ソフトウェアエラーの種別とエラーが発生しているコントロールサービスまたはアプリケーションの名称あるいは識別記号などをエラー情報として、オペレーションパネルのディスプレイに表示するととともに、ＮＣＳ１２８を介して公衆回線などを利用してサービスセンタのホストコンピュータなどへ送信する（ステップＳ３０５）。
【００６４】
一方、ステップＳ３０３において、関数戻り値が正常を示す場合には、診断を行ったコントロールサービス、アプリケーションは正常動作していると判断する。
【００６５】
このようなステップＳ３０１〜Ｓ３０５までの診断処理をすべてのコントロールサービスおよびすべてのアプリケーションに対して繰り返し実行する（ステップＳ３０６）。
【００６６】
このように、実施の形態１の複合機では、診断アプリ１１７と各コントロールサービスまたは各アプリとのプロセス間通信によって、各コントロールサービスまたは各アプリのソフトウェアエラーを検知しているので、ユーザサービスが停止した場合でハードウェア資源にエラーがないときでも、ソフトウェアエラーが原因であることを把握することができ、複合機１００のユーザサービスの機能障害などが生じた場合にも、その原因究明を早期かつ正確に行うことができる。
【００６７】
また、実施の形態１の複合機では、診断関数の呼び出しとその関数戻り値の受信という簡易なインタフェースのプロセス間通信によって、各コントロールサービスや各アプリのソフトウェアエラーを検知しているので、プロセス間通信のインタフェースを確保することで各モジュール間の独立性を保ちながら、ソフトウェアエラーの検知というユーザに有益な情報を提供することができる。
【００６８】
（実施の形態２）
実施の形態１の複合機１００は、コントロールサービスおよびアプリケーションの診断を、複合機１００の電源投入時に行うものであったが、この実施の形態２にかかる複合機１００は、ユーザサービスの機能を実行中に、コントロールサービスおよびアプリケーションの診断を行うものである。
【００６９】
実施の形態２にかかる複合機１００の構成は、図１に示す実施の形態１の複合機１００と同様であるので説明を省略する。
【００７０】
実施の形態２の複合機１００では、各コントロールサービスおよび各アプリは、実施の形態１と同様に、いずれもプロセスとして動作し診断アプリ１１７から関数呼び出しされる診断関数を実装している。しかし、各コントロールサービスおよび各アプリは、ユーザサービスの機能を提供する際に実行される通常モードスレッドと、診断関数を実行する診断モードスレッドを有している点が実施の形態１の複合機１００と異なる。
【００７１】
すなわち、ＳＣＳ１２２のプロセスは、アプリ管理、操作部制御、システム画面表示、ＬＥＤ表示、リソース管理、割り込みアプリ制御というユーザサービスを行う際に実行される通常モードスレッドと、かかる処理を実行せずに、単に上記診断関数を実行する診断モードスレッドを有している。
【００７２】
ＥＣＳ１２４のプロセスは、白黒ラインプリンタ（B&W LP）１０１、カラーラインプリンタ（Color LP）１０２、スキャナ、ファクシミリなどからなるハードウェアリソース１０３のエンジンの制御というユーザサービスを行う際に実行される通常モードスレッドと、このようなエンジン制御を行わずに診断関数を実行する診断モードスレッドを有している。
【００７３】
ＭＣＳ１２５のプロセスは、画像メモリの取得および解放、ハードディスク装置（ＨＤＤ）の利用、画像データの圧縮および伸張などのコピー、プリンタ、ファクシミリおよびスキャナなどのユーザサービスを行う際に実行される通常モードスレッドと、かかる機能を実行せずに診断関数を実行する診断モードスレッドを有している。
【００７４】
ＯＣＳ１２６のプロセスは、オペレータと本体制御間の情報伝達手段となる操作パネル（オペレーションパネル）の制御というユーザサービスを行う際に起動される通常モードスレッドと、かかる操作パネルの制御を行わず診断関数を実行する診断モードスレッドを有している。
【００７５】
ＦＣＳ１２７のプロセスは、システムコントローラの各アプリ層からＰＳＴＮ／ＩＳＤＮ網を利用したファクシミリ送受信、ＢＫＭ（バックアップＳＲＡＭ）で管理されている各種ファクシミリデータの登録／引用、ファクシミリ読みとり、ファクシミリ受信印刷、融合送受信を行うためのＡＰＩを提供するというユーザサービスを行う際に起動される通常モードスレッドと、かかる機能を実行せずに診断関数を実行する診断モードスレッドを有している。
【００７６】
ＮＣＳ１２８は、ネットワークＩ／Ｏを必要とするアプリケーションに対して共通に利用できるサービスを提供するためのプロセスであり、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分けたり、アプリケーションからデータをネットワーク側に送信する際の仲介を行うというユーザサービスを行う際に実行される通常モードスレッドと、かかる機能を実行せずに診断関数を実行する診断モードスレッドを有している。
【００７７】
このように、ＳＣＳ１２２、ＥＣＳ１２４、ＭＣＳ１２５、ＯＣＳ１２６、ＦＣＳ１２７、ＮＣＳ１２８の各診断モードスレッドはいずれも診断関数を実行してソフトウェアエラーが発生しているか否かを判断し、その結果を診断アプリ１１７に返すようになっている。
【００７８】
プリンタアプリ１１１、コピーアプリ１１２、ファックスアプリ１１３、スキャナアプリ１１４、ネットファイルアプリ１１５、工程検査アプリ１１６のそれぞれも、ユーザサービスを行う際に実行される通常モードスレッドと、かかる機能を実行せずに診断関数を実行する診断モードスレッドを有している。
【００７９】
また、診断アプリ１１７は、実施の形態１の複合機１００と異なり、コントロールサービスまたはアプリケーション１３０の診断要求があったときに起動されて、実施の形態１の複合機１００と同様の診断処理を行う。
【００８０】
次に、このように構成された実施の形態２の複合機によるコントロールサービスおよびアプリケーション１３０の診断処理について説明する。図５は、実施の形態２の複合機におけるコントロールサービスおよびアプリケーション１３０の診断要求から診断処理までの全体の流れを示すフローチャートである。
【００８１】
複合機１００によるユーザサービスの処理を実行中、診断要求があると、この診断要求をＳＣＳ１２２で受け取る（ステップＳ５０１）。ここで、診断要求には、ユーザが明示的に指示した診断要求の他、ネットワーク経由で複合機開発元あるいはサービスセンタのホストコンピュータなどから送信される診断要求や、複合機１００内部でタイマー機能などを利用して一定期間ごとに指令する診断要求も含まれる。なお、ネットワーク経由で診断要求を受信する場合には、診断要求はＮＣＳ１２８経由でＳＣＳ１２２が受信することになる。
【００８２】
ついで、ＳＣＳ１２２はプログラム起動部（図示せず）に対して診断アプリ１１７の起動を要求し、これによって診断アプリ１１７がプラットホーム１２０上に起動される（ステップＳ５０２）。そして、診断アプリ１１７によって、コントロールサービスおよびアプリケーションの診断処理が実行される（ステップＳ５０３）。
【００８３】
図６は、実施の形態２の複合機１００における診断アプリ１１７と各コントロールサービスまたは各アプリのプロセス間通信の状態を示す模式図である。診断アプリ１１７によるコントロールサービスおよびアプリケーションの診断の具体的処理手順については、図３に示した実施の形態１の複合機１００の場合と同様であるため図示を省略する。
【００８４】
診断アプリ１１７のプロセスは起動されると、まず各コントロールサービスおよび各アプリのプロセスをサーバプロセスとしたクライアントプロセスとして動作し、各コントロールサービスおよび各アプリのプロセスに対して順番に診断関数の呼び出しを行う（ステップＳ６０１）。そして、診断アプリ１１７は、関数戻り値待ち状態となる。
【００８５】
各コントロールサービスまたは各アプリのプロセスでは、診断アプリ１１７から診断関数呼び出しを受信すると（ステップＳ６０２）、診断モードスレッドによって診断関数を実行する（ステップＳ６０３）。これにより、上述の擬似的な処理が実行される。一方、このとき、診断モードスレッドと別スレッドである通常モードスレッドでは、ユーザサービスに関する処理が、診断モードスレッドと並列実行されている。
【００８６】
診断モードスレッドでは、診断関数の処理結果を、正常またはエラー発生の旨の関数戻り値として診断アプリ１１７へ返す（ステップＳ６０４）。診断アプリ１１７は、関数戻り値を受信して（ステップＳ６０５）、その関数戻り値によって各コントロールサービスまたは各アプリが正常動作しているか否かを判断する。以降の処理は、実施の形態１で説明した図３におけるステップＳ３０３以降の処理と同様であるため、説明を省略する。
【００８７】
このように、実施の形態２の複合機では、各コントロールサービスとアプリケーションのプロセスが通常モードスレッドと診断モードスレッドの並列実行し、診断モードスレッドによって診断関数の実行を行っているので、ユーザサービスの機能を停止させずに、ソフトウェアエラーを検知することができる。
【００８８】
以上、説明した実施の形態１および２の複合機では、本発明の診断手段を診断アプリ１１７に適用しているが、このほか、同様の機能を、たとえば診断コントロールサービスとして、プラットホーム１２０に含める構成としても良い。
【００８９】
また、実施の形態２では、各コントロールサービスとアプリケーションのプロセスが通常モードスレッドと診断モードスレッドを有する構成の適用例として、ユーザサービスの実行中に診断要求がある場合について説明しているが、実施の形態１と同様に、複合機１００の電源投入時における診断に適用することも可能である。
【００９０】
【発明の効果】
以上説明したように、本発明によれば、ハードウェア資源のエラーのみならず、画像形成装置上で動作するコントロールサービスやアプリケーションにおけるソフトウェアエラーを把握して画像形成装置の障害原因を早急に究明することができるという効果を奏する。
【００９１】
また、本発明によれば、簡易なインタフェースのプロセス間通信によってソフトウェアエラーを検知することができ、各モジュール間の独立性を維持しながらも、ソフトウェアエラーの検知というユーザに有益な情報を提供することができるという効果を奏する。
【００９２】
また、本発明によれば、ユーザサービスの提供前に速やかにソフトウェアエラーを検知することができるという効果を奏する。
【図面の簡単な説明】
【図１】実施の形態１である複合機の構成を示すブロック図である。
【図２】実施の形態１の複合機における電源投入からコントロールサービスおよびアプリケーションの診断処理までの全体の流れを示すフローチャートである。
【図３】実施の形態１の複合機の診断アプリによるコントロールサービスおよびアプリケーションの診断の処理手順を示すフローチャートである。
【図４】実施の形態１の複合機における診断アプリと各コントロールサービスまたは各アプリのプロセス間通信の状態を示す模式図である。
【図５】実施の形態２の複合機におけるコントロールサービスおよびアプリケーションの診断要求から診断処理までの全体の流れを示すフローチャートである。
【図６】実施の形態２の複合機における診断アプリと各コントロールサービスまたは各アプリのプロセス間通信の状態を示す模式図である。
【符号の説明】
１００ 複合機
１０１ 白黒ラインプリンタ
１０２ カラーラインプリンタ
１０３ ハードウェアリソース
１１０ ソフトウェア群
１１１ プリンタアプリ
１１２ コピーアプリ
１１３ ファックスアプリ
１１４ スキャナアプリ
１１５ ネットファイルアプリ
１１６ 工程検査アプリ
１１７ 診断アプリ
１２０ プラットホーム
１２１ 汎用ＯＳ
１２２ ＳＣＳ
１２３ ＳＲＭ
１２４ ＥＣＳ
１２５ ＭＣＳ
１２６ ＯＣＳ
１２７ ＦＣＳ
１２８ ＮＣＳ
１３０ アプリケーション
【発明の属する技術分野】
この発明は、プリンタ、コピーまたはファクシミリなどの画像形成処理にかかるユーザサービスを提供する際に動作するコントロールサービスやアプリケーションの診断を行うことができる画像形成装置およびこのような画像形成装置で実行されるソフトウェア診断方法に関するものである。
【０００２】
【従来の技術】
近年、プリンタ、コピー、ファクシミリ、スキャナなどの各装置の機能を１つの筐体内に収納した画像形成装置（以下、「複合機」という。）が一般的に知られている。この複合機は、１つの筐体内に表示部、印刷部および撮像部などを設けるとともに、プリンタ、コピーおよびファクシミリ装置にそれぞれ対応する３種類のソフトウェアを設け、ソフトウェアの切り替えによって、当該装置をプリンタ、コピー、スキャナまたはファクシミリ装置として動作させるものである。
【０００３】
このような複合機では、電源投入の際にＯＳ（Operating System）が起動する前に、いわゆるＢＩＯＳ（Basic Input/Output System）内で診断プログラムが動作し、メモリ、セントロインタフェース、ネットワークインタフェースなどのハードウェア資源のエラーチェックを行うことが一般的になっている。
【０００４】
ところで、従来の複合機では、内部にプリンタ、コピー、スキャナおよびファクシミリ装置に対応するソフトウェア（汎用ＯＳを含む）をそれぞれ別個に設ける構成となっており、各ソフトウェアの開発に多大の時間を要する。このため、出願人は、表示部、印刷部および撮像部などの画像形成処理で使用されるハードウェア資源を有し、プリンタ、コピーまたはファクシミリなどの各ユーザサービスにそれぞれ固有の処理を行うアプリケーションを複数搭載し、これらのアプリケーションとハードウェア資源との間に介在して、ユーザサービスを提供する際に、アプリケーションの少なくとも２つが共通的に必要とするハードウェア資源の管理、実行制御並びに画像形成処理を行う各種コントロールサービスからなるプラットホームを備えた画像形成装置を発明した。この画像形成装置によれば、アプリケーションの少なくとも２つが共通的に必要とするハードウェア資源の管理、実行制御並びに画像形成処理を行うプラットホームを備えた構成とすることによって、ソフトウェア開発の効率化を図るとともに、装置全体としての生産性を向上させることが可能となる。
【０００５】
【発明が解決しようとする課題】
このような複合機では、アプリケーションと、アプリケーションの少なくとも２つが共通的に必要とするサービスを提供するコントロールサービスを有する構成となっているため、ユーザにサービスを提供するためには、ハードウェア資源の他、各アプリケーションおよび各コントロールサービスが正常に動作している必要がある。
【０００６】
しかしながら、従来は診断プログラムによってハードウェア資源のエラーチェックしか行っていないため、アプリケーションやコントロールサービスにエラーが生じてユーザサービスの機能が停止している場合でも、診断プログラムによるハードウェア資源の診断結果は正常として通知されてしまう。このため、ユーザまたは保守作業者は、画像形成装置で生じた障害の原因を認識できないという問題がある。
【０００７】
この発明は上記に鑑みてなされたもので、コントロールサービスやアプリケーションなどのソフトウェアのエラーを検知することにより、画像形成装置に障害が生じた場合の原因究明を正確かつ速やかに行える画像形成装置を得ることを目的とする。
【０００８】
【課題を解決するための手段】
上記目的を達成するため、本発明にかかる画像形成装置は、プリンタ部及びスキャナ部のうち、少なくとも一方を含むハードウェア資源と、前記ハードウェア資源の制御を行うプログラムと、前記プログラムと、画像形成処理にかかるユーザサービスにそれぞれ固有の処理を行う複数のアプリケーションと、前記プログラムが正常に動作しているかを診断する診断アプリケーションとを動作させるオペレーティングシステムと、を備え、前記プログラムは、あらかじめ定義された関数により前記複数のアプリケーションからの処理要求を受信可能とするアプリケーションプログラムインターフェースを有し、前記複数のアプリケーションから前記アプリケーションプログラムインターフェースを介して受信した処理要求に基づいて前記ハードウェア資源を制御し、前記診断アプリケーションは、前記プログラム及び前記複数のアプリケーションが起動されたときに、該起動されたプログラム及び複数のアプリケーションが正常に動作しているか否かを診断することを特徴とする。
【０００９】
なお、画像形成処理にかかるユーザサービスとは、プリンタ、コピーまたはファクシミリなどの画像形成処理においてユーザに提供するサービスをいう。
【００１０】
また、本発明にかかるソフトウェア診断方法は、画像形成装置で実行されるソフトウェア診断方法であって、前記画像形成装置は、プリンタ部及びスキャナ部のうち、少なくとも一方を含むハードウェア資源と、 前記ハードウェア資源の制御を行うプログラムと、前記プログラムと、画像形成処理にかかるユーザサービスにそれぞれ固有の処理を行う複数のアプリケーションと、前記プログラムが正常に動作しているかを診断する診断アプリケーションとを動作させるオペレーティングシステムと、を備え、前記プログラムは、あらかじめ定義された関数により前記複数のアプリケーションからの処理要求を受信可能とするアプリケーションプログラムインターフェースを有し、前記プログラムが、前記複数のアプリケーションから前記アプリケーションプログラムインターフェースを介して受信した処理要求に基づいて前記ハードウェア資源を制御し、前記診断アプリケーションが、前記プログラム及び前記複数のアプリケーションが起動されたときに、該起動されたプログラム及び複数のアプリケーションが正常に動作しているかを診断することを特徴とする。
【００３９】
【発明の実施の形態】
以下に添付図面を参照して、この発明にかかる画像形成装置およびソフトウェア診断方法の好適な実施の形態を詳細に説明する。
【００４０】
（実施の形態１）
図１は、この発明の実施の形態１である画像形成装置（以下、「複合機」という）の構成を示すブロック図である。図１に示すように、複合機１００は、白黒ラインプリンタ（B&W LP）１０１と、カラーラインプリンタ（Color LP）１０２と、スキャナ、ファクシミリなどのハードウェアリソース１０３などを有するとともに、プラットホーム１２０とアプリケーション１３０とから構成されるソフトウェア群１１０とを備えている。
【００４１】
プラットホーム１２０は、アプリケーションからの処理要求を解釈してハードウェア資源の獲得要求を発生させるコントロールサービスと、一または複数のハードウェア資源の管理を行い、コントロールサービスからの獲得要求を調停するシステムリソースマネージャ（ＳＲＭ）１２３と、汎用ＯＳ１２１とを有する。
【００４２】
コントロールサービスは、複数のサービスモジュールから形成され、ＳＣＳ（システムコントロールサービス）１２２と、ＥＣＳ（エンジンコントロールサービス）１２４と、ＭＣＳ（メモリコントロールサービス）１２５と、ＯＣＳ（オペレーションパネルコントロールサービス）１２６と、ＦＣＳ（ファックスコントロールサービス）１２７と、ＮＣＳ（ネットワークコントロールサービス）１２８とから構成される。なお、このプラットホーム１２０は、あらかじめ定義された関数により前記アプリケーション１３０から処理要求を受信可能とするアプリケーションプログラムインタフェース（ＡＰＩ）を有する。
【００４３】
汎用ＯＳ１２１は、ＵＮＩＸなどの汎用オペレーティングシステムであり、プラットホーム１２０並びにアプリケーション１３０の各ソフトウェアをそれぞれプロセスとして並列実行する。
【００４４】
コントロールサービスのそれぞれは、いずれもプロセスとして動作し、処理単位あるいは一連の処理ごとの単位を一スレッドとした一または複数のスレッドを有している。
【００４５】
また、コントロールサービスのそれぞれは、後述する診断アプリ１１７から発行される診断関数を実装している。この診断関数は、各コントロールサービスの動作確認を行うために擬似的な処理を行うものであり、ハードウェア資源にアクセスせずに内部で完結するような各コントロールサービスの最低限の処理を実行する。そして、その処理結果によって正常またはエラー発生を示す関数戻り値を呼び出し元の診断アプリ１１７に返すようになっている。
【００４６】
ＳＲＭ１２３のプロセスは、ＳＣＳ１２２とともにシステムの制御およびリソースの管理を行うものであり、スキャナ部やプリンタ部などのエンジン、メモリ、ＨＤＤファイル、ホストＩ／Ｏ（セントロＩ／Ｆ、ネットワークＩ／Ｆ、ＩＥＥＥ１３９４ Ｉ／Ｆ、ＲＳ２３２Ｃ Ｉ／Ｆなど）のハードウェア資源を利用する上位層からの要求にしたがって調停を行い、実行制御を行う。
【００４７】
具体的には、このＳＲＭ１２３は、要求されたハードウェア資源が利用可能であるか（他の要求により利用されていないかどうか）を判断し、利用可能であれば要求されたハードウェア資源が利用可能である旨を上位層に伝える。また、ＳＲＭ１２３は、上位層からの要求に対してハードウェア資源の利用スケジューリングを行い、要求内容（例えば、プリンタエンジンにより紙搬送と作像動作、メモリ確保、ファイル生成など）を直接実施している。
【００４８】
ＳＣＳ１２２のプロセスは、アプリ管理、操作部制御、システム画面表示、ＬＥＤ表示、リソース管理、割り込みアプリ制御を行う。
【００４９】
ＥＣＳ１２４のプロセスは、白黒ラインプリンタ（B&W LP）１０１、カラーラインプリンタ（Color LP）１０２、スキャナ、ファクシミリなどからなるハードウェアリソース１０３のエンジンの制御を行う。
【００５０】
ＭＣＳ１２５のプロセスは、画像メモリの取得および解放、ハードディスク装置（ＨＤＤ）の利用、画像データの圧縮および伸張などを行う。
【００５１】
ＯＣＳ１２６のプロセスは、オペレータと本体制御間の情報伝達手段となる操作パネル（オペレーションパネル）の制御を行う。
【００５２】
ＦＣＳ１２７のプロセスは、システムコントローラの各アプリ層からＰＳＴＮ／ＩＳＤＮ網を利用したファクシミリ送受信、ＢＫＭ（バックアップＳＲＡＭ）で管理されている各種ファクシミリデータの登録／引用、ファクシミリ読みとり、ファクシミリ受信印刷、融合送受信を行うためのＡＰＩを提供する。
【００５３】
ＮＣＳ１２８は、ネットワークＩ／Ｏを必要とするアプリケーションに対して共通に利用できるサービスを提供するためのプロセスであり、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分けたり、アプリケーションからデータをネットワーク側に送信する際の仲介を行う。
【００５４】
アプリケーション１３０は、ページ記述言語（ＰＤＬ）、ＰＣＬおよびポストスクリプト（ＰＳ）を有するプリンタ用のアプリケーションであるプリンタアプリ１１１と、コピー用アプリケーションであるコピーアプリ１１２と、ファクシミリ用アプリケーションであるファックスアプリ１１３と、スキャナ用アプリケーションであるスキャナアプリ１１４と、ネットワークファイル用アプリケーションであるネットファイルアプリ１１５と、工程検査用アプリケーションである工程検査アプリ１１６と診断用のアプリケーションである診断アプリ１１７を有している。
【００５５】
アプリケーションのそれぞれは、いずれもプロセスとして動作する。診断アプリ１１７を除く各アプリも、コントロールサービスと同様に、診断アプリ１１７から関数呼び出しされる診断関数を実装している。この診断関数は、各アプリの動作確認を行うために擬似的な処理を行うものであり、プリンタ、コピーまたはファクシミリなどの画像形成処理にかかるユーザサービスの機能を停止し、かつコントロールサービスへのアクセスを行わずに内部で完結するような最低限の処理を実行する。そして、その処理結果によって正常またはエラー発生を示す関数戻り値を呼び出し元の診断アプリ１１７に返すようになっている。
【００５６】
診断アプリ１１７は、その起動時、すなわち複合機１００が電源投入され、汎用ＯＳ１２１、プラットホーム１２０、アプリケーション１３０が順に起動されたときに、各コントロールサービス、ＳＲＭ１２３および各アプリに対して順番に診断関数の呼び出しを行う。そしてそれらの関数戻り値が正常かエラー発生かをチェックしてエラー発生の関数戻り値の場合には、その関数戻り値からソフトウェアエラーの種類を判断し、そのソフトウェアエラーの種類とソフトウェアエラーが生じているソフトウェア（各コントロールサービス、ＳＲＭ１２３、各アプリ）の名称などのエラー情報をオペレーションパネルのディスプレイに表示する。また、これらのエラー情報は、ＮＣＳ１２８が正常動作している場合にはＮＣＳ１２８を介して、公衆回線などのネットワークを利用してサービスセンタのホストコンピュータなどへ送信するようになっている。なお、診断アプリ１１７は本発明における診断手段を構成するものである。
【００５７】
次に、このように構成された実施の形態１の複合機によるコントロールサービスおよびアプリケーション１３０の診断処理について説明する。図２は、実施の形態１の複合機における電源投入からコントロールサービスおよびアプリケーション１３０の診断処理までの全体の流れを示すフローチャートである。
【００５８】
複合機１００に電源が投入されると（ステップＳ２０１）、まずハードウェア資源の初期化が行われ（ステップＳ２０２）、ついでハードウェア資源のエラーチェックによる診断処理が実行される（ステップＳ２０３）。ハードウェア資源の診断が正常に終了した場合には、引き続き汎用ＯＳ１２１が起動される（ステップＳ２０４）。汎用ＯＳ１２１が正常に起動した場合には、プログラム起動部（図示せず）によって、まず汎用ＯＳ１２１上でコントロールサービスおよびＳＲＭ１２３からなるプラットホーム１２０の起動が行われ（ステップＳ２０５）、ついでプラットホーム１２０上にアプリケーション１３０の起動が行われる（ステップＳ２０６）。このとき、同時に診断アプリ１１７も起動する。そして、起動した診断アプリ１１７によって、コントロールサービスおよびアプリケーション１３０のそれぞれに対してソフトウェアエラーのチェックによる診断処理が実行される（ステップＳ２０７）。
【００５９】
図３は、実施の形態１の複合機１００の診断アプリ１１７によるコントロールサービスおよびアプリケーションの診断の処理手順を示すフローチャートである。図４は、実施の形態１の複合機１００における診断アプリ１１７と各コントロールサービスまたは各アプリのプロセス間通信の状態を示す模式図である。
【００６０】
診断アプリ１１７のプロセスは起動されると、まず各コントロールサービスおよび各アプリのプロセスをサーバプロセスとしたクライアントプロセスとして動作し、各コントロールサービスおよび各アプリのプロセスに対して順番に診断関数の呼び出しを行う（ステップＳ３０１）。そして、診断アプリ１１７は、関数戻り値待ち状態となる。
【００６１】
各コントロールサービスまたは各アプリのプロセスでは、診断アプリ１１７から診断関数呼び出しを受信すると（ステップＳ４０１）、診断関数により上述の擬似的な処理を実行し（ステップＳ４０２）、その処理結果を正常またはエラー発生の旨の関数戻り値として診断アプリ１１７へ返す（ステップＳ４０３）。なお、エラーが発生している場合には、戻り値の数値によってソフトウェアエラーの種類を識別できるように、エラー時の戻り値をあらかじめ定義しておく。
【００６２】
このように、診断アプリ１１７のプロセスから各コントロールサービスまたは各アプリのプロセスへの診断関数の呼び出しと、各コントロールサービスまたは各アプリのプロセスから診断アプリ１１７のプロセスへの関数戻り値の送信というプロセス間通信によって、診断アプリ１１７によるコントロールサービスまたはアプリケーション１３０のソフトウェアエラーの検知が行われる。
【００６３】
診断アプリ１１７は、関数戻り値を受信すると（ステップＳ３０２）、その関数戻り値によって各コントロールサービスまたは各アプリが正常動作しているか否かを判断する（ステップＳ３０３）。そして、エラーが発生している場合には、関数戻り値の数値によってソフトウェアエラーの種別を特定し（ステップＳ３０４）、ソフトウェアエラーの種別とエラーが発生しているコントロールサービスまたはアプリケーションの名称あるいは識別記号などをエラー情報として、オペレーションパネルのディスプレイに表示するととともに、ＮＣＳ１２８を介して公衆回線などを利用してサービスセンタのホストコンピュータなどへ送信する（ステップＳ３０５）。
【００６４】
一方、ステップＳ３０３において、関数戻り値が正常を示す場合には、診断を行ったコントロールサービス、アプリケーションは正常動作していると判断する。
【００６５】
このようなステップＳ３０１〜Ｓ３０５までの診断処理をすべてのコントロールサービスおよびすべてのアプリケーションに対して繰り返し実行する（ステップＳ３０６）。
【００６６】
このように、実施の形態１の複合機では、診断アプリ１１７と各コントロールサービスまたは各アプリとのプロセス間通信によって、各コントロールサービスまたは各アプリのソフトウェアエラーを検知しているので、ユーザサービスが停止した場合でハードウェア資源にエラーがないときでも、ソフトウェアエラーが原因であることを把握することができ、複合機１００のユーザサービスの機能障害などが生じた場合にも、その原因究明を早期かつ正確に行うことができる。
【００６７】
また、実施の形態１の複合機では、診断関数の呼び出しとその関数戻り値の受信という簡易なインタフェースのプロセス間通信によって、各コントロールサービスや各アプリのソフトウェアエラーを検知しているので、プロセス間通信のインタフェースを確保することで各モジュール間の独立性を保ちながら、ソフトウェアエラーの検知というユーザに有益な情報を提供することができる。
【００６８】
（実施の形態２）
実施の形態１の複合機１００は、コントロールサービスおよびアプリケーションの診断を、複合機１００の電源投入時に行うものであったが、この実施の形態２にかかる複合機１００は、ユーザサービスの機能を実行中に、コントロールサービスおよびアプリケーションの診断を行うものである。
【００６９】
実施の形態２にかかる複合機１００の構成は、図１に示す実施の形態１の複合機１００と同様であるので説明を省略する。
【００７０】
実施の形態２の複合機１００では、各コントロールサービスおよび各アプリは、実施の形態１と同様に、いずれもプロセスとして動作し診断アプリ１１７から関数呼び出しされる診断関数を実装している。しかし、各コントロールサービスおよび各アプリは、ユーザサービスの機能を提供する際に実行される通常モードスレッドと、診断関数を実行する診断モードスレッドを有している点が実施の形態１の複合機１００と異なる。
【００７１】
すなわち、ＳＣＳ１２２のプロセスは、アプリ管理、操作部制御、システム画面表示、ＬＥＤ表示、リソース管理、割り込みアプリ制御というユーザサービスを行う際に実行される通常モードスレッドと、かかる処理を実行せずに、単に上記診断関数を実行する診断モードスレッドを有している。
【００７２】
ＥＣＳ１２４のプロセスは、白黒ラインプリンタ（B&W LP）１０１、カラーラインプリンタ（Color LP）１０２、スキャナ、ファクシミリなどからなるハードウェアリソース１０３のエンジンの制御というユーザサービスを行う際に実行される通常モードスレッドと、このようなエンジン制御を行わずに診断関数を実行する診断モードスレッドを有している。
【００７３】
ＭＣＳ１２５のプロセスは、画像メモリの取得および解放、ハードディスク装置（ＨＤＤ）の利用、画像データの圧縮および伸張などのコピー、プリンタ、ファクシミリおよびスキャナなどのユーザサービスを行う際に実行される通常モードスレッドと、かかる機能を実行せずに診断関数を実行する診断モードスレッドを有している。
【００７４】
ＯＣＳ１２６のプロセスは、オペレータと本体制御間の情報伝達手段となる操作パネル（オペレーションパネル）の制御というユーザサービスを行う際に起動される通常モードスレッドと、かかる操作パネルの制御を行わず診断関数を実行する診断モードスレッドを有している。
【００７５】
ＦＣＳ１２７のプロセスは、システムコントローラの各アプリ層からＰＳＴＮ／ＩＳＤＮ網を利用したファクシミリ送受信、ＢＫＭ（バックアップＳＲＡＭ）で管理されている各種ファクシミリデータの登録／引用、ファクシミリ読みとり、ファクシミリ受信印刷、融合送受信を行うためのＡＰＩを提供するというユーザサービスを行う際に起動される通常モードスレッドと、かかる機能を実行せずに診断関数を実行する診断モードスレッドを有している。
【００７６】
ＮＣＳ１２８は、ネットワークＩ／Ｏを必要とするアプリケーションに対して共通に利用できるサービスを提供するためのプロセスであり、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分けたり、アプリケーションからデータをネットワーク側に送信する際の仲介を行うというユーザサービスを行う際に実行される通常モードスレッドと、かかる機能を実行せずに診断関数を実行する診断モードスレッドを有している。
【００７７】
このように、ＳＣＳ１２２、ＥＣＳ１２４、ＭＣＳ１２５、ＯＣＳ１２６、ＦＣＳ１２７、ＮＣＳ１２８の各診断モードスレッドはいずれも診断関数を実行してソフトウェアエラーが発生しているか否かを判断し、その結果を診断アプリ１１７に返すようになっている。
【００７８】
プリンタアプリ１１１、コピーアプリ１１２、ファックスアプリ１１３、スキャナアプリ１１４、ネットファイルアプリ１１５、工程検査アプリ１１６のそれぞれも、ユーザサービスを行う際に実行される通常モードスレッドと、かかる機能を実行せずに診断関数を実行する診断モードスレッドを有している。
【００７９】
また、診断アプリ１１７は、実施の形態１の複合機１００と異なり、コントロールサービスまたはアプリケーション１３０の診断要求があったときに起動されて、実施の形態１の複合機１００と同様の診断処理を行う。
【００８０】
次に、このように構成された実施の形態２の複合機によるコントロールサービスおよびアプリケーション１３０の診断処理について説明する。図５は、実施の形態２の複合機におけるコントロールサービスおよびアプリケーション１３０の診断要求から診断処理までの全体の流れを示すフローチャートである。
【００８１】
複合機１００によるユーザサービスの処理を実行中、診断要求があると、この診断要求をＳＣＳ１２２で受け取る（ステップＳ５０１）。ここで、診断要求には、ユーザが明示的に指示した診断要求の他、ネットワーク経由で複合機開発元あるいはサービスセンタのホストコンピュータなどから送信される診断要求や、複合機１００内部でタイマー機能などを利用して一定期間ごとに指令する診断要求も含まれる。なお、ネットワーク経由で診断要求を受信する場合には、診断要求はＮＣＳ１２８経由でＳＣＳ１２２が受信することになる。
【００８２】
ついで、ＳＣＳ１２２はプログラム起動部（図示せず）に対して診断アプリ１１７の起動を要求し、これによって診断アプリ１１７がプラットホーム１２０上に起動される（ステップＳ５０２）。そして、診断アプリ１１７によって、コントロールサービスおよびアプリケーションの診断処理が実行される（ステップＳ５０３）。
【００８３】
図６は、実施の形態２の複合機１００における診断アプリ１１７と各コントロールサービスまたは各アプリのプロセス間通信の状態を示す模式図である。診断アプリ１１７によるコントロールサービスおよびアプリケーションの診断の具体的処理手順については、図３に示した実施の形態１の複合機１００の場合と同様であるため図示を省略する。
【００８４】
診断アプリ１１７のプロセスは起動されると、まず各コントロールサービスおよび各アプリのプロセスをサーバプロセスとしたクライアントプロセスとして動作し、各コントロールサービスおよび各アプリのプロセスに対して順番に診断関数の呼び出しを行う（ステップＳ６０１）。そして、診断アプリ１１７は、関数戻り値待ち状態となる。
【００８５】
各コントロールサービスまたは各アプリのプロセスでは、診断アプリ１１７から診断関数呼び出しを受信すると（ステップＳ６０２）、診断モードスレッドによって診断関数を実行する（ステップＳ６０３）。これにより、上述の擬似的な処理が実行される。一方、このとき、診断モードスレッドと別スレッドである通常モードスレッドでは、ユーザサービスに関する処理が、診断モードスレッドと並列実行されている。
【００８６】
診断モードスレッドでは、診断関数の処理結果を、正常またはエラー発生の旨の関数戻り値として診断アプリ１１７へ返す（ステップＳ６０４）。診断アプリ１１７は、関数戻り値を受信して（ステップＳ６０５）、その関数戻り値によって各コントロールサービスまたは各アプリが正常動作しているか否かを判断する。以降の処理は、実施の形態１で説明した図３におけるステップＳ３０３以降の処理と同様であるため、説明を省略する。
【００８７】
このように、実施の形態２の複合機では、各コントロールサービスとアプリケーションのプロセスが通常モードスレッドと診断モードスレッドの並列実行し、診断モードスレッドによって診断関数の実行を行っているので、ユーザサービスの機能を停止させずに、ソフトウェアエラーを検知することができる。
【００８８】
以上、説明した実施の形態１および２の複合機では、本発明の診断手段を診断アプリ１１７に適用しているが、このほか、同様の機能を、たとえば診断コントロールサービスとして、プラットホーム１２０に含める構成としても良い。
【００８９】
また、実施の形態２では、各コントロールサービスとアプリケーションのプロセスが通常モードスレッドと診断モードスレッドを有する構成の適用例として、ユーザサービスの実行中に診断要求がある場合について説明しているが、実施の形態１と同様に、複合機１００の電源投入時における診断に適用することも可能である。
【００９０】
【発明の効果】
以上説明したように、本発明によれば、ハードウェア資源のエラーのみならず、画像形成装置上で動作するコントロールサービスやアプリケーションにおけるソフトウェアエラーを把握して画像形成装置の障害原因を早急に究明することができるという効果を奏する。
【００９１】
また、本発明によれば、簡易なインタフェースのプロセス間通信によってソフトウェアエラーを検知することができ、各モジュール間の独立性を維持しながらも、ソフトウェアエラーの検知というユーザに有益な情報を提供することができるという効果を奏する。
【００９２】
また、本発明によれば、ユーザサービスの提供前に速やかにソフトウェアエラーを検知することができるという効果を奏する。
【図面の簡単な説明】
【図１】実施の形態１である複合機の構成を示すブロック図である。
【図２】実施の形態１の複合機における電源投入からコントロールサービスおよびアプリケーションの診断処理までの全体の流れを示すフローチャートである。
【図３】実施の形態１の複合機の診断アプリによるコントロールサービスおよびアプリケーションの診断の処理手順を示すフローチャートである。
【図４】実施の形態１の複合機における診断アプリと各コントロールサービスまたは各アプリのプロセス間通信の状態を示す模式図である。
【図５】実施の形態２の複合機におけるコントロールサービスおよびアプリケーションの診断要求から診断処理までの全体の流れを示すフローチャートである。
【図６】実施の形態２の複合機における診断アプリと各コントロールサービスまたは各アプリのプロセス間通信の状態を示す模式図である。
【符号の説明】
１００ 複合機
１０１ 白黒ラインプリンタ
１０２ カラーラインプリンタ
１０３ ハードウェアリソース
１１０ ソフトウェア群
１１１ プリンタアプリ
１１２ コピーアプリ
１１３ ファックスアプリ
１１４ スキャナアプリ
１１５ ネットファイルアプリ
１１６ 工程検査アプリ
１１７ 診断アプリ
１２０ プラットホーム
１２１ 汎用ＯＳ
１２２ ＳＣＳ
１２３ ＳＲＭ
１２４ ＥＣＳ
１２５ ＭＣＳ
１２６ ＯＣＳ
１２７ ＦＣＳ
１２８ ＮＣＳ
１３０ アプリケーション
Claims (6)
- プリンタ部及びスキャナ部のうち、少なくとも一方を含むハードウェア資源と、
前記ハードウェア資源の制御を行うプログラムと、
前記プログラムと、画像形成処理にかかるユーザサービスにそれぞれ固有の処理を行う複数のアプリケーションと、前記プログラムが正常に動作しているかを診断する診断アプリケーションとを動作させるオペレーティングシステムと、を備え、
前記プログラムは、あらかじめ定義された関数により前記複数のアプリケーションからの処理要求を受信可能とするアプリケーションプログラムインターフェースを有し、前記複数のアプリケーションから前記アプリケーションプログラムインターフェースを介して受信した処理要求に基づいて前記ハードウェア資源を制御し、
前記診断アプリケーションは、前記プログラム及び前記複数のアプリケーションが起動されたときに、該起動されたプログラム及び複数のアプリケーションが正常に動作しているか否かを診断すること
を特徴とする画像形成装置。 - 前記プログラム及び前記複数のアプリケーションのそれぞれは、自身が正常に動作しているかを確認するための診断関数を有し、
前記診断アプリケーションは、前記プログラム及び前記複数のアプリケーションのそれぞれが有する前記診断関数を呼び出すことにより、前記プログラム及び前記複数のアプリケーションが正常に動作しているかを診断すること
を特徴とする請求項１に記載の画像形成装置。 - 前記診断アプリケーションは、呼び出した診断関数の戻り値により、エラーの種別を判断すること
を特徴とする請求項２に記載の画像形成装置。 - 前記診断アプリケーションは、前記プログラム及び前記複数のアプリケーションのうち、エラーが発生しているプログラム及びアプリケーションを画面に表示させること
を特徴とする請求項１〜３のいずれか一つに記載の画像形成装置。 - 前記プログラム、前記複数のアプリケーション及び前記診断アプリケーションのそれぞれを、プロセスとして起動させること
を特徴とする請求項１〜３のいずれか一つに記載の画像形成装置。 - 画像形成装置で実行されるソフトウェア診断方法であって、
前記画像形成装置は、プリンタ部及びスキャナ部のうち、少なくとも一方を含むハードウェア資源と、 前記ハードウェア資源の制御を行うプログラムと、前記プログラムと、画像形成処理にかかるユーザサービスにそれぞれ固有の処理を行う複数のアプリケーションと、前記プログラムが正常に動作しているかを診断する診断アプリケーションとを動作させるオペレーティングシステムと、を備え、
前記プログラムは、あらかじめ定義された関数により前記複数のアプリケーションからの処理要求を受信可能とするアプリケーションプログラムインターフェースを有し、
前記プログラムが、前記複数のアプリケーションから前記アプリケーションプログラムインターフェースを介して受信した処理要求に基づいて前記ハードウェア資源を制御し、
前記診断アプリケーションが、前記プログラム及び前記複数のアプリケーションが起動されたときに、該起動されたプログラム及び複数のアプリケーションが正常に動作しているかを診断すること、
を特徴とするソフトウェア診断方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001264888A JP4712248B2 (ja) | 2001-08-31 | 2001-08-31 | 画像形成装置およびソフトウェア診断方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001264888A JP4712248B2 (ja) | 2001-08-31 | 2001-08-31 | 画像形成装置およびソフトウェア診断方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003078688A JP2003078688A (ja) | 2003-03-14 |
| JP4712248B2 true JP4712248B2 (ja) | 2011-06-29 |
Family
ID=19091423
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001264888A Expired - Fee Related JP4712248B2 (ja) | 2001-08-31 | 2001-08-31 | 画像形成装置およびソフトウェア診断方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4712248B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4636029B2 (ja) * | 2007-01-26 | 2011-02-23 | 富士ゼロックス株式会社 | 画像形成装置及びプログラム |
| JP6150048B2 (ja) * | 2013-05-10 | 2017-06-21 | コニカミノルタ株式会社 | 画像形成システムおよび画像形成システムの診断方法 |
-
2001
- 2001-08-31 JP JP2001264888A patent/JP4712248B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003078688A (ja) | 2003-03-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8115943B2 (en) | Image forming apparatus and print process method | |
| JP4444752B2 (ja) | サービス提供装置、サービス提供プログラム、記録媒体及びサービス提供方法 | |
| JP3679349B2 (ja) | 画像形成装置、画像形成方法、画像形成プログラムおよびアプリケーションプログラム | |
| JP2004098658A (ja) | 画像形成装置及びラッピング処理方法並びにプログラム | |
| JP4843372B2 (ja) | 画像処理装置 | |
| JP5700093B2 (ja) | 画像形成装置 | |
| JP3677478B2 (ja) | 画像形成装置、アプリケーション利用制限方法およびその方法をコンピュータに実行させるプログラム | |
| JP3898476B2 (ja) | 画像情報処理装置およびソフトウェア再構築方法 | |
| JP2003296065A (ja) | 画像形成装置 | |
| JP3683542B2 (ja) | 画像形成装置 | |
| JP4512565B2 (ja) | 画像形成装置およびアプリケーションインストール方法 | |
| JP4394740B2 (ja) | 画像形成装置、方法、及びプログラム | |
| JP4128506B2 (ja) | 画像形成装置およびアプリケーション情報取得方法 | |
| US20160019105A1 (en) | Computer embedded apparatus, recording medium and computer embedded apparatus test system | |
| JP4712248B2 (ja) | 画像形成装置およびソフトウェア診断方法 | |
| JP3683543B2 (ja) | 画像形成装置 | |
| JP4676977B2 (ja) | 画像形成装置、アプリケーション情報取得方法、及びプログラム | |
| US8041889B2 (en) | Information processor and image generator for stopping rotation of a magnetic disk in response to an abnormal state | |
| JP3887191B2 (ja) | 画像情報処理装置および障害情報通知方法 | |
| JP2011188411A (ja) | 画像処理装置と画像処理システム | |
| JP5691483B2 (ja) | 画像形成装置、遠隔管理方法、およびプログラム | |
| JP2003298793A (ja) | 画像形成装置 | |
| JP3710789B2 (ja) | 複数の通信プロトコルを有する画像形成装置 | |
| JP2006271005A (ja) | 画像形成装置およびアプリケーションインストール方法 | |
| JP4677054B2 (ja) | 画像形成装置、プログラム、記録媒体、及び方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080821 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20100723 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100824 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20101025 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20110322 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20110323 |
|
| LAPS | Cancellation because of no payment of annual fees |