JP2006123511A - 画像形成装置、ハードウェア制御方法、および、ハードウェア制御プログラム - Google Patents

Abstract

【課題】 画像データに対する操作を行うハードウェアを備えた画像形成装置において、画像データに対する操作を行うハードウェアの制御を効率化することを目的とする。
【解決手段】 画像データに対する操作を行うハードウェアと、上記操作を遂行するソフトウェア実行実体に対するメモリの割り振りおよび実行制御を行うイメージメモリハンドラとを備えた画像形成装置であって、上記ソフトウェア実行実体から要求される上記ハードウェアの制御にかかる動作指定をキューにより管理し、上記イメージメモリハンドラとは独立に実行制御を行う処理部を備える。
【選択図】 図４

Description

本発明は、画像データに対する操作を行うハードウェアのドライバを統合化し制御を効率化した画像形成装置、ハードウェア制御方法、および、ハードウェア制御プログラムに関する。

コピー機、プリンタ等に代表される画像形成装置は、画像データの入力・出力、圧縮・伸長、回転、編集等の画像データに対する操作をＤＭＡ（Direct Memory Access）により行う機能を有しており、一般にこれらの機能はＡＳＩＣ（Application Specific Integrated Circuit）等に実装されたハードウェアにより提供される。また、これらのハードウェアを制御するドライバがＯＳ（Operating System）側に設けられている。

図１は従来の画像形成装置におけるドライバ制御のための構成図であり、画像形成装置上で実行される各種のプロセス（ソフトウェア実行実体）に対するメモリの割り振りおよびプロセスに割り振ったメモリの管理を行うイメージメモリハンドラ（ＩＭＨ）２３内において、タスク制御スレッドの制御のもと、複数のタスクスレッド＃１〜＃Ｎが動作に必要な単体機能のドライバを制御して所望の動作を実現するようになっている。なお、各ドライバ内には処理対象となる画像データのメモリ上の位置を示すディスクリプタが確保され、画像データに対する処理に際して用いられる。

上述したように、従来の画像形成装置においては、使用しているすべてのドライバの動作開始から動作完了までをイメージメモリハンドラ（ＩＭＨ）２３が制御しなければならず、ドライバの数が少ない場合には問題とならなかったが、昨今の画像形成装置の高機能化に伴って制御対象のドライバの数が増大してきたことから、イメージメモリハンドラ２３が過負荷状態になるという問題が発生してきた。

特に、イメージメモリハンドラ２３内のタスク制御スレッドは、どのタスクスレッドがどのドライバを使用するかというスケジューリングを行うとともに、各ドライバの連動を行うためにタスクスレッド間のタイミング制御を行う必要があることから、過負荷状態になると各処理のタイミングが合わなくなる場合があり、正常に動作が行えないという問題があった。例えば、連続して印刷を行う場合、紙間内にリクエストを出さなければならないといった時間制約があることから、イメージメモリハンドラ２３が過負荷状態になると限られた所定の時間内にリクエストを出せない場合があり、正常な印刷が行えなくなる。

本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、画像データに対する操作を行うハードウェアの制御を効率化することのできる画像形成装置、ハードウェア制御方法、および、ハードウェア制御プログラムを提供することにある。

上記の課題を解決するため、本発明にあっては、請求項１に記載されるように、画像データに対する操作を行うハードウェアと、上記操作を遂行するソフトウェア実行実体に対するメモリの割り振りおよび実行制御を行うイメージメモリハンドラとを備えた画像形成装置であって、上記ソフトウェア実行実体から要求される上記ハードウェアの制御にかかる動作指定をキューにより管理し、上記イメージメモリハンドラとは独立に実行制御を行う処理部を備えるようにしている。

また、請求項２に記載されるように、上記処理部は、上記キューの先頭の動作指定を実行するとともに、実行の完了した動作指定を上記キューから削除するようにすることができる。

また、請求項３に記載されるように、上記ハードウェアの個々の機能に対応する複数の上記キューの動作指定の間に同時実行を指定可能とし、上記処理部は上記同時実行の指定に従って連動制御を行うようにすることができる。

また、請求項４に記載されるように、上記処理部は、画像データに対する処理を行うソフトウェア実行実体から与えられる実行指示に対応する実行結果を当該ソフトウェア実行実体に返却するようにすることができる。

また、請求項５に記載されるように、上記処理部は、処理対象となる画像データのメモリ上の位置を示すディスクリプタとして用いる未使用ディスクリプタを複数保持した共通のディスクリプタプールを有するようにすることができる。

また、請求項６に記載されるように、上記処理部は、上記ハードウェアとして実装されていない機能に対応する仮想ドライバを有するものとすることができる。

また、請求項７に記載されるように、上記仮想ドライバはビデオ入力器であるようにすることができる。

また、請求項８に記載されるように、上記処理部は、画像データに対する処理を行うタスクスレッドから呼び出される関数を提供するとともに、上記タスクスレッドから与えられるコマンドに対応するレスポンスを当該タスクスレッドに返却する統合ドライバライブラリと、上記ハードウェアの個々の機能に対応するデバイスユニットに対する動作指定をキューとして管理して実行制御を行う統合ドライバとを備えるようにすることができる。

また、請求項９に記載されるように、上記統合ドライバライブラリは、上記タスクスレッドから与えられるコマンドと当該タスクスレッドに返却するレスポンスとを対応付けて管理するディスパッチャを備えるようにすることができる。

また、請求項１０に記載されるように、上記統合ドライバは、データの書き込み専用の第１のマイナドライバと、データの読み出し専用の第２のマイナドライバとを備えるようにすることができる。

また、請求項１１に記載されるように、画像データに対する操作を行うハードウェアと、上記操作を遂行するソフトウェア実行実体に対するメモリの割り振りおよび実行制御を行うイメージメモリハンドラとを備えた画像形成装置における上記ハードウェアの制御方法であって、上記ソフトウェア実行実体から要求される上記ハードウェアの制御にかかる動作指定をキューにより管理し、上記イメージメモリハンドラとは独立に実行制御を行うハードウェア制御方法として構成することができる。

また、請求項１８に記載されるように、画像データに対する操作を行うハードウェアと、上記操作を遂行するソフトウェア実行実体に対するメモリの割り振りおよび実行制御を行うイメージメモリハンドラとを備えた画像形成装置における上記ハードウェアの制御プログラムであって、上記ソフトウェア実行実体から要求される上記ハードウェアの制御にかかる動作指定をキューにより管理し、上記イメージメモリハンドラとは独立に実行制御を行う機能をコンピュータに実現させるハードウェア制御プログラムとして構成することができる。

本発明の画像形成装置、ハードウェア制御方法、および、ハードウェア制御プログラムにあっては、画像データに対する操作を行うハードウェアを備えた画像形成装置において、ハードウェアの制御にかかる動作指定をキューにより管理して実行制御を行うようにしたので、上位のソフトウェアの処理負担が軽減され、制御を効率化することができる。

以下、本発明の好適な実施形態につき説明する。

図２は本発明の一実施形態にかかる画像形成装置の構成図である。

図２において、画像形成装置１は、ソフトウェア群２と、画像形成装置起動部３と、ハードウェア資源４とを含むように構成される。

画像形成装置起動部３は画像形成装置１の電源投入時に最初に実行され、アプリケーション層５およびプラットホーム層６を起動する。例えば画像形成装置起動部３は、アプリケーション層５およびプラットホーム層６のプログラムを、ハードディスク装置（以下、ＨＤＤという）などから読み出し、読み出した各プログラムをメモリ領域に転送して起動する。ハードウェア資源４は、スキャナ２５と、プロッタ２６と、ＡＤＦ（Auto Document Feeder）などのハードウェアリソース２４とを含む。

また、ソフトウェア群２は、ＵＮＩＸ（登録商標）などのオペレーティングシステム（以下、ＯＳという）上に起動されているアプリケーション層５とプラットホーム層６とを含む。アプリケーション層５は、プリンタ、コピー、ファックスおよびスキャナなどの画像形成にかかるユーザサービスにそれぞれ固有の処理を行うプログラムを含む。

アプリケーション層５は、プリンタ用のアプリケーションであるプリンタアプリ９と、コピー用アプリケーションであるコピーアプリ１０と、ファックス用アプリケーションであるファックスアプリ１１と、スキャナ用アプリケーションであるスキャナアプリ１２とを含む。

また、プラットホーム層６は、アプリケーション層５からの処理要求を解釈してハードウェア資源４の獲得要求を発生するコントロールサービス層７と、１つ以上のハードウェア資源４の管理を行ってコントロールサービス層７からの獲得要求を調停するシステムリソースマネージャ（以下、ＳＲＭという）２１と、ＳＲＭ２１からの獲得要求に応じてハードウェア資源４の管理を行うハンドラ層８とを含む。

コントロールサービス層７は、ネットワークコントロールサービス（以下、ＮＣＳという）１３、デリバリーコントロールサービス（以下、ＤＣＳという）１４、オペレーションパネルコントロールサービス（以下、ＯＣＳという）１５、ファックスコントロールサービス（以下、ＦＣＳという）１６、エンジンコントロールサービス（以下、ＥＣＳという）１７、メモリコントロールサービス（以下、ＭＣＳという）１８、ユーザインフォメーションコントロールサービス（以下、ＵＣＳという）１９、システムコントロールサービス（以下、ＳＣＳという）２０など、一つ以上のサービスモジュールを含むように構成されている。

なお、プラットホーム層６は予め定義されている関数により、アプリケーション層５からの処理要求を受信可能とするＡＰＩ２８を有するように構成されている。ＯＳは、アプリケーション層５およびプラットホーム層６の各ソフトウェアをプロセスとして並列実行する。

ＮＣＳ１３のプロセスは、ネットワークＩ／Ｏを必要とするアプリケーションに対して共通に利用できるサービスを提供するものであり、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分けたり、各アプリケーションからのデータをネットワーク側に送信する際の仲介を行う。例えば、ＮＣＳ１３は、ネットワークを介して接続されるネットワーク機器とのデータ通信をｈｔｔｐｄ（HyperText Transfer Protocol Daemon）により、ＨＴＴＰ（HyperText Transfer Protocol）で制御する。

ＤＣＳ１４のプロセスは、蓄積文書の配信などの制御を行う。ＯＣＳ１５のプロセスは、オペレータと本体制御との間の情報伝達手段となるオペレーションパネルの制御を行う。ＦＣＳ１６のプロセスは、アプリケーション層５からＰＳＴＮまたはＩＳＤＮ網を利用したファックス送受信、バックアップ用のメモリで管理されている各種ファックスデータの登録／引用、ファックス読み取り、ファックス受信印刷などを行うためのＡＰＩを提供する。

ＥＣＳ１７のプロセスは、スキャナ２５、プロッタ２６、その他のハードウェアリソース２４などのエンジン部の制御を行う。ＭＣＳ１８のプロセスは、メモリの取得および解放、ＨＤＤの利用などのメモリ制御を行う。ＵＣＳ１９は、ユーザ情報の管理を行うものである。

ＳＣＳ２０のプロセスは、アプリケーション管理、操作部制御、システム画面表示、ＬＥＤ表示、ハードウェア資源管理、割り込みアプリケーション制御などの処理を行う。

ＳＲＭ２１のプロセスは、ＳＣＳ２０と共にシステムの制御およびハードウェア資源４の管理を行うものである。例えばＳＲＭ２１のプロセスは、スキャナ２５やプロッタ２６などのハードウェア資源４を利用する上位層からの獲得要求に従って調停を行い、実行制御する。具体的に、ＳＲＭ２１のプロセスは獲得要求されたハードウェア資源４が利用可能であるか（他の獲得要求により利用されていないかどうか）を判定し、利用可能であれば獲得要求されたハードウェア資源４が利用可能である旨を上位層に通知する。また、ＳＲＭ２１のプロセスは上位層からの獲得要求に対してハードウェア資源４を利用するためのスケジューリングを行い、要求内容（例えば、プリンタエンジンによる紙搬送と作像動作、メモリ確保、ファイル生成など）を直接実施している。

また、ハンドラ層８は後述するファックスコントロールユニット（以下、ＦＣＵという）の管理を行うファックスコントロールユニットハンドラ（以下、ＦＣＵＨという）２２と、プロセスに対するメモリの割り振りおよびプロセスに割り振ったメモリの管理を行うイメージメモリハンドラ（ＩＭＨ）２３とを含む。

ＳＲＭ２１およびＦＣＵＨ２２は、予め定義されている関数によりハードウェア資源４に対する処理要求を送信可能とするエンジンＩ／Ｆ２７を利用して、ハードウェア資源４に対する処理要求を行う。

このように、画像形成装置１は、各アプリケーションで共通的に必要な処理をプラットホーム層６で一元的に処理することができる。

次に、画像形成装置１のハードウェア構成について説明する。

図３は本発明の一実施形態にかかる画像形成装置のハードウェア構成図である。

図３において、画像形成装置１は、コントローラボード３０と、オペレーションパネル４３と、ＦＣＵ４４と、エンジン４７とを含む。また、ＦＣＵ４４は、Ｇ３規格対応ユニット４５と、Ｇ４規格対応ユニット４６とを有する。

また、コントローラボード３０は、ＣＰＵ３１と、ＡＳＩＣ４０と、ＨＤＤ４２と、システムメモリ（ＭＥＭ−Ｐ）３２と、ローカルメモリ（ＭＥＭ−Ｃ）４１と、ノースブリッジ（以下、ＮＢと記す）３３と、サウスブリッジ（以下、ＳＢと記す）３４と、ＮＩＣ３５（Network Interface Card）と、ＵＳＢデバイス３６と、ＩＥＥＥ１３９４デバイス３７と、セントロニクスデバイス３８とを含む。

オペレーションパネル４３は、コントローラボード３０のＡＳＩＣ４０に接続されている。また、ＳＢ３４と、ＮＩＣ３５と、ＵＳＢデバイス３６と、ＩＥＥＥ１３９４デバイス３７と、セントロニクスデバイス３８とは、ＮＢ３３にＰＣＩバスで接続されている。

また、ＦＣＵ４４と、エンジン４７は、コントローラボード３０のＡＳＩＣ４０にＰＣＩバスで接続されている。

なお、コントローラボード３０は、ＡＳＩＣ４０にＭＥＭ−Ｃ４１、ＨＤＤ４２などが接続されると共に、ＣＰＵ３１とＡＳＩＣ４０とがＣＰＵチップセットのＮＢ３３を介して接続されている。このように、ＮＢ３３を介してＣＰＵ３１とＡＳＩＣ４０とを接続すれば、ＣＰＵ３１のインタフェースが公開されていない場合に対応できる。

また、ＡＳＩＣ４０とＮＢ３３とはＰＣＩバスを介して接続されているのでなく、ＡＧＰ（Accelerated Graphics Port）３９を介して接続されている。このように、図２のアプリケーション層５やプラットホーム層６を形成する一つ以上のプロセスを実行制御するため、ＡＳＩＣ４０とＮＢ３３とを低速のＰＣＩバスでなくＡＧＰ３９を介して接続し、パフォーマンスの低下を防いでいる。

ＣＰＵ３１は、画像形成装置１の全体制御を行うものである。ＣＰＵ３１は、図２のＮＣＳ１３、ＤＣＳ１４、ＯＣＳ１５、ＦＣＳ１６、ＥＣＳ１７、ＭＣＳ１８、ＵＣＳ１９、ＳＣＳ２０、ＳＲＭ２１、ＦＣＵＨ２２、ＩＭＨ２３をＯＳ上にそれぞれプロセスとして起動して実行させると共に、アプリケーション層５を形成するプリンタアプリ９、コピーアプリ１０、ファックスアプリ１１、スキャナアプリ１２を起動して実行させる。

ＮＢ３３は、ＣＰＵ３１、ＭＥＭ−Ｐ３２、ＳＢ３４およびＡＳＩＣ４０を接続するためのブリッジである。ＭＥＭ−Ｐ３２は、画像形成装置１の描画用メモリなどとして用いるメモリである。ＳＢ３４は、ＮＢ３３とＰＣＩバス、周辺デバイスとを接続するためのブリッジである。また、ＭＥＭ−Ｃ４１はコピー用画像バッファ、符号バッファとして用いるメモリである。

ＡＳＩＣ４０は、画像処理用のハードウェア要素を有する画像処理用途向けのＩＣである。ＨＤＤ４２は、画像の蓄積、プログラムの蓄積、フォントデータの蓄積、フォームの蓄積などを行うためのストレージである。また、オペレーションパネル４３は、ユーザからの入力操作を受け付けると共に、ユーザに向けた表示を行う操作部である。

次に、本発明の主要部である画像データに対する操作を行うハードウェアの制御のための構成について説明する。

図４はハードウェア制御のための統合ドライバライブラリおよび統合ドライバの構成図である。

図４において、画像形成装置上で実行される各種のプロセス（ソフトウェア実行実体）に対するメモリの割り振りおよびプロセスに割り振ったメモリの管理を行うイメージメモリハンドラ（ＩＭＨ）２３には、ソフトウェア実行実体である複数のタスクスレッド５０およびこれらのタスクスレッド５０を生成する親タスク等から呼び出される関数（システムコールではなく関数形式のインタフェース）を提供するとともに、タスクスレッド５０から与えられるコマンドに対応するレスポンスを当該タスクスレッド５０に返却する統合ドライバライブラリ５１が設けられている。また、統合ドライバライブラリ５１内には、タスクスレッド５０から与えられるコマンドと当該タスクスレッド５０に返却するレスポンスとを対応付けて管理するディスパッチャ５２が設けられている。

一方、ＯＳ（Operating System）側にはＡＳＩＣ４０（図３）により実装される画像データに対する操作を行うハードウェアの個々の機能に対する動作指定をキューとして管理して実行制御を行う統合ドライバ５３が設けられている。ここで、統合ドライバ５３は、データの書き込みと読み出しの同時実行を保証するため、データの書き込み専用のマイナドライバ５４と、データの読み出し専用のマイナドライバ５５とにインタフェースが集約されている。

図５は統合ドライバ５３の詳細構成図であり、ＩＭＨ２３の統合ドライバライブラリ５１とのインタフェースをとり、コマンドの振り分けを行うコマンド制御部５６と、処理対象となる画像データのメモリ上の位置を示すディスクリプタとして用いる未使用ディスクリプタを複数保持した共通のディスクリプタプール５７と、ハードウェアの個々の機能に対応するデバイスユニット５８と、各デバイスユニット５８に対応して設けられ、デバイスユニット５８に対する動作指定（ＯＰＥ：オペレーション）を待ち行列として積み上げて管理するＯＰＥキュー５９とを備えている。ここで、各デバイスユニット５８は、ＯＰＥキュー５９の先頭の動作指定を実行し、実行の完了した動作指定はＯＰＥキュー５９の先頭から削除される。また、ハードウェアの個々の機能に対応する複数のＯＰＥキュー５９の任意の動作指定の間にはＯＰＥ連動設定により同時実行が指定可能となっている。このＯＰＥ連動設定はキューエントリー内に設定される。図６はＯＰＥのデータ構造の例を示す図であり、ここではビデオ伸長器のＯＰＥを例に挙げているが、そのデータ構造中のａにおけるコマンド「header.command」において、「UV_UPPER_GO」指定により「UV_OPE_ENTER」で登録されるＯＰＥとの連動が指定される。また、ｂにおいて連動タイプ「header.type」が指定される。なお、連動タイプとしては、デバイス間でメモリを介さずに画像データを渡すオンザフライ（ON THE FLY）連動、ビデオ伸長器とビデオ出力器の動作を交互に行うＡＰＣＭ連動、ＡＰＣＭ連動と同等の動作を行うソフト連動、制御上無関係な複数のＯＰＥをグループ化して実行するグルーピング等がある。また、連動の組み合わせとしては、ビデオ伸長器→ビデオ出力器、ビデオ伸長器→圧縮伸長器→ビデオ出力器、圧縮伸長器→ＨＤＤ（Hard Disk Drive）、ＨＤＤ→圧縮伸長器等の様々な組み合わせがある。ＭＬＢ（Media Link Board）との連動も可能である。

図７はハードウェア制御の処理を示すシーケンス図である。

図７において、画像データの処理に際し、ＩＭＨ２３のタスクスレッド５０は統合ドライバライブラリ５１にタスク遂行に必要な、複数のディスクリプタから構成されるディスクセットの登録を行い（ステップＳ１）、統合ドライバライブラリ５１は統合ドライバ５３に対して同様にディスクセットの登録を行う（ステップＳ２）。この際、統合ドライバ５３はディスクリプタプール５７（図５）からディスクリプタを取得し、要求されたディスクセットとして用いる。

次いで、ＩＭＨ２３のタスクスレッド５０は動作指定（ＯＰＥ）を生成し、統合ドライバライブラリ５１に与える（ステップＳ３）。

次いで、ＩＭＨ２３のタスクスレッド５０は動作指定のパラメータを設定し（ステップＳ４）、統合ドライバライブラリ５１に動作指定を投入し（ステップＳ５）、統合ドライバライブラリ５１は統合ドライバ５３に対して同様に動作指定を投入する（ステップＳ６）。この際、統合ドライバ５３は投入された動作指定をＯＰＥキュー５９（図５）に積む。

そして、統合ドライバ５３ではＯＰＥキュー５９の先頭の動作指定を実行し、統合ドライバライブラリ５１に対してレスポンスを返却し（ステップＳ７）、統合ドライバライブラリ５１はタスクスレッド５０に同様にレスポンスを返却する（ステップＳ８）。

次いで、統合ドライバ５３は実行が完了した動作指定を解放してその旨を統合ドライバライブラリ５１に伝え（ステップＳ９）、統合ドライバライブラリ５１は同様にタスクスレッド５０に動作指定の解放を伝える（ステップＳ１０）。なお、統合ドライバ５３は動作指定の解放に際して実行の完了した動作指定をＯＰＥキュー５９の先頭から削除する。

次いで、統合ドライバ５３は実行が完了した動作指定において用いられたディスクセットを解放してその旨を統合ドライバライブラリ５１に伝え（ステップＳ１１）、統合ドライバライブラリ５１は同様にタスクスレッド５０にディスクセットの解放を伝える（ステップＳ１２）。

なお、ここでは一つのタスクスレッド５０について示したが、一般にタスクスレッド５０は複数となり、それぞれについて上述した処理が行われる。また、動作指定の間にＯＰＥ連動設定が行われている場合、統合ドライバ５３はＯＰＥ連動設定の対象となっている複数の動作指定が実行可能になるまで待ち合わせを行い、タイミング制御を自律的に行う。

このような動作により、ＩＭＨ２３のタスクスレッド５０は統合ドライバライブラリ５１側にディスクセットの登録と動作指定の生成、パラメータの設定、および動作指定の投入を行うだけで、統合ドライバライブラリ５１および統合ドライバ５３による自律的動作によりタイミング制御を含めたすべての実行制御が行われるため、従来のような複雑な制御から解放されることになる。

また、タスク遂行に必要なディスクリプタは統合ドライバ５３内でディスクリプタプール５７として共通に管理されるため、統合ドライバ５３全体としての最大使用量を確保すればよく、資源の効率的な使用を図ることができる。すなわち、従来はドライバの使用するディスクリプタはドライバをオープンする毎に必要となるものであり、昨今の機器の高機能化に伴って制御対象のドライバの数が増大してきたことからディスクリプタの消費量も相当なものとなり、組み込み機器（汎用パーソナルコンピュータとは異なり、コンピュータを組み込んだ画像形成装置等の機器）としての限られたメモリ資源を圧迫するという問題があったが、本発明においてはこのような問題が解決されるものである。

更に、本発明にあっては、従来のようなハードウェアの単体機能に対応したドライバを設けるのとは異なり、統合ドライバライブラリ５１および統合ドライバ５３として、ハードウェアの制約なしに自由にドライバ機能を実現することができるため、対応するハードウェアの存在しない仮想ドライバを設けることができる。例えば、画像処理に際しては広大なメモリ領域をクリア（キャッシュフラッシュ）する処理がたびたび発生し、この点、画像データの入力を行うハードウェア（ビデオ入力器）を備えた機器では「０」データを連続的にメモリ上に書き込むことで、ドライバを経由したハードウェア処理によってキャッシュフラッシュ処理を行うことができる。しかしながら、ビデオ入力器を持たない機器も存在することから、従来はプロセス側でキャッシュフラッシュ処理を行わなければならず、プロセス側の処理負担が大きいという問題があった。この点、本発明では、例えばビデオ入力器に相当する仮想ドライバを設けることができるため、処理負担の大きいキャッシュフラッシュ処理を統合ドライバライブラリ５１および統合ドライバ５３を経由し、プロセス側の負担なく行うことができる。

次に、図８はＩＭＨから統合ドライバライブラリを呼び出す処理を示すフローチャートである。

図８において、ＩＭＨ２３は先ず各種サービスを利用できるようにするために統合ドライバライブラリ５１および統合ドライバ５３の初期化を行う（ステップＳ２１）。この初期化においては、統合ドライバライブラリ５１の提供する各種の初期化関数が呼び出される。

次いで、ＩＭＨ２３は統合ドライバ５３で使用できるデバイスユニット５８等の情報を取得する（ステップＳ２２）。この情報取得においては、統合ドライバライブラリ５１の提供する情報取得関数が呼び出される。

そして、処理内容に応じて複数のタスクスレッド５０を生成し（ステップＳ２３）、各タスクスレッド５０において、ディスクセットの構成、ディスクセットの登録、コールバック（レスポンス）の登録、パラメータ領域の取得・設定、ＯＰＥ登録および実行、コールバック待ちを行う。

タスクスレッド５０の処理が終了した後は、パラメータの消去、ディスクセットの解放等の終了処理を行う（ステップＳ２４）。

次に、図９はＩＭＨから統合ドライバライブラリを呼び出す処理を示すフローチャートの他の例を示したものであり、連動タスクを生成する場合の例を示している。

図９において、初期化（ステップＳ３１）、統合ドライバ情報取得（ステップＳ３２）、タスク生成（ステップＳ３３）、終了処理（ステップＳ３４）の流れは図８に示したものと同様であるが、タスク生成（ステップＳ３３）において、例えば、圧縮伸長器とビデオ出力器の連動タスク５０ａを、圧縮伸長器バンド圧縮タスク５０ｂとは別に生成するようにしている。ここで、圧縮伸長器は画像データの圧縮・伸長を行うもの、ビデオ出力器は画像データ（印刷のための作像データ等）を出力するものであり、画像データの伸長の完了と同期してビデオ出力を行う必要があることから連動が必要となる。図１０は連動タスク５０ａにおける処理の例を示す図であり、圧縮伸長器についてのディスクセットの構成、ディスクセットの登録、コールバックの登録、ビデオ出力器についてのディスクセットの構成、ディスクセットの登録、圧縮伸長器についてのパラメータ領域の取得・設定、ＯＰＥ登録、ビデオ出力器についてのパラメータ領域の取得・設定、ＯＰＥ登録、コールバック待ちを行う。連動の指定は、パラメータ領域の取得・設定において行われる。そして、連動が指定された圧縮伸長器に対する動作指定の投入後、ビデオ出力器の動作指定の投入があれば、両者は連動するとみなされる。また、圧縮伸長器バンド圧縮タスク５０ｂは画像データの圧縮伸長に用いられるバンド（メモリ領域の単位）を圧縮するものである。

以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。

従来の画像形成装置におけるドライバ制御のための構成図である。 本発明の一実施形態にかかる画像形成装置の構成図である。 本発明の一実施形態にかかる画像形成装置のハードウェア構成図である。 ハードウェア制御のための統合ドライバライブラリおよび統合ドライバの構成図である。 統合ドライバの詳細構成図である。 ＯＰＥのデータ構造の例を示す図である。 ハードウェア制御の処理を示すシーケンス図である。 ＩＭＨから統合ドライバライブラリを呼び出す処理を示すフローチャート（その１）である。 ＩＭＨから統合ドライバライブラリを呼び出す処理を示すフローチャート（その２）である。 連動タスクにおける処理の例を示す図である。

符号の説明

１ 画像形成装置
２ ソフトウェア群
３ 画像形成装置起動部
４ ハードウェア資源
５ アプリケーション層
６ プラットホーム層
７ コントロールサービス層
８ ハンドラ層
９ プリンタアプリ
１０ コピーアプリ
１１ ファックスアプリ
１２ スキャナアプリ
１３ ＮＣＳ
１４ ＤＣＳ
１５ ＯＣＳ
１６ ＦＣＳ
１７ ＥＣＳ
１８ ＭＣＳ
１９ ＵＣＳ
２０ ＳＣＳ
２１ ＳＲＭ
２２ ＦＣＵＨ
２３ ＩＭＨ
２４ ハードウェアリソース
２５ スキャナ
２６ プロッタ
２７ エンジンＩ／Ｆ
４０ ＡＳＩＣ
５０ タスクスレッド
５１ 統合ドライバライブラリ
５２ ディスパッチャ
５３ 統合ドライバ
５４、５５ マイナドライバ
５６ コマンド制御部
５７ ディスクリプタプール
５８ デバイスユニット
５９ ＯＰＥキュー

Claims (18)

1. 画像データに対する操作を行うハードウェアと、上記操作を遂行するソフトウェア実行実体に対するメモリの割り振りおよび実行制御を行うイメージメモリハンドラとを備えた画像形成装置であって、
   上記ソフトウェア実行実体から要求される上記ハードウェアの制御にかかる動作指定をキューにより管理し、上記イメージメモリハンドラとは独立に実行制御を行う処理部を備えたことを特徴とする画像形成装置。
2. 上記処理部は、上記キューの先頭の動作指定を実行するとともに、実行の完了した動作指定を上記キューから削除することを特徴とする請求項１に記載の画像形成装置。
3. 上記ハードウェアの個々の機能に対応する複数の上記キューの動作指定の間に同時実行を指定可能とし、
   上記処理部は上記同時実行の指定に従って連動制御を行うことを特徴とする請求項１または２のいずれか一項に記載の画像形成装置。
4. 上記処理部は、画像データに対する処理を行うソフトウェア実行実体から与えられる実行指示に対応する実行結果を当該ソフトウェア実行実体に返却することを特徴とする請求項１乃至３のいずれか一項に記載の画像形成装置。
5. 上記処理部は、処理対象となる画像データのメモリ上の位置を示すディスクリプタとして用いる未使用ディスクリプタを複数保持した共通のディスクリプタプールを有することを特徴とする請求項１乃至４のいずれか一項に記載の画像形成装置。
6. 上記処理部は、上記ハードウェアとして実装されていない機能に対応する仮想ドライバを有することを特徴とする請求項１乃至５のいずれか一項に記載の画像形成装置。
7. 上記仮想ドライバはビデオ入力器であることを特徴とする請求項６に記載の画像形成装置。
8. 上記処理部は、
   画像データに対する処理を行うタスクスレッドから呼び出される関数を提供するとともに、上記タスクスレッドから与えられるコマンドに対応するレスポンスを当該タスクスレッドに返却する統合ドライバライブラリと、
   上記ハードウェアの個々の機能に対応するデバイスユニットに対する動作指定をキューとして管理して実行制御を行う統合ドライバとを備えたことを特徴とする請求項１乃至７のいずれか一項に記載の画像形成装置。
9. 上記統合ドライバライブラリは、上記タスクスレッドから与えられるコマンドと当該タスクスレッドに返却するレスポンスとを対応付けて管理するディスパッチャを備えたことを特徴とする請求項８に記載の画像形成装置。
10. 上記統合ドライバは、データの書き込み専用の第１のマイナドライバと、データの読み出し専用の第２のマイナドライバとを備えたことを特徴とする請求項８または９のいずれか一項に記載の画像形成装置。
11. 画像データに対する操作を行うハードウェアと、上記操作を遂行するソフトウェア実行実体に対するメモリの割り振りおよび実行制御を行うイメージメモリハンドラとを備えた画像形成装置における上記ハードウェアの制御方法であって、
    上記ソフトウェア実行実体から要求される上記ハードウェアの制御にかかる動作指定をキューにより管理し、上記イメージメモリハンドラとは独立に実行制御を行うことを特徴とするハードウェア制御方法。
12. 上記キューの先頭の動作指定を実行するとともに、実行の完了した動作指定を上記キューから削除することを特徴とする請求項１１に記載のハードウェア制御方法。
13. 上記ハードウェアの個々の機能に対応する複数の上記キューの動作指定の間に同時実行を指定可能とし、上記同時実行の指定に従って連動制御を行うことを特徴とする請求項１１または１２のいずれか一項に記載のハードウェア制御方法。
14. 画像データに対する処理を行うソフトウェア実行実体から与えられる実行指示に対応する実行結果を当該ソフトウェア実行実体に返却することを特徴とする請求項１１乃至１３のいずれか一項に記載のハードウェア制御方法。
15. 処理対象となる画像データのメモリ上の位置を示すディスクリプタとして用いる未使用ディスクリプタを複数保持した共通のディスクリプタプールを有することを特徴とする請求項１１乃至１４のいずれか一項に記載のハードウェア制御方法。
16. 上記ハードウェアとして実装されていない機能に対応する仮想ドライバを有することを特徴とする請求項１１乃至１５のいずれか一項に記載のハードウェア制御方法。
17. 上記仮想ドライバはビデオ入力器であることを特徴とする請求項１６に記載のハードウェア制御方法。
18. 画像データに対する操作を行うハードウェアと、上記操作を遂行するソフトウェア実行実体に対するメモリの割り振りおよび実行制御を行うイメージメモリハンドラとを備えた画像形成装置における上記ハードウェアの制御プログラムであって、
    上記ソフトウェア実行実体から要求される上記ハードウェアの制御にかかる動作指定をキューにより管理し、上記イメージメモリハンドラとは独立に実行制御を行う機能をコンピュータに実現させることを特徴とするハードウェア制御プログラム。

Images