JP2016021208A - コンピュータ組み込み装置 - Google Patents

Abstract

【課題】ＯＳ環境に影響されずに、コンピュータ組み込み装置の複雑で正確な制御を行えるようにする。
【解決手段】ソフトウェアにより実現される、複数の階層に分かれ、上位に対して所定のサービスを提供する複数のレイヤと、前記レイヤのそれぞれに設けられ、該レイヤに入出力するメッセージの順序制御を行うメッセージ処理部とを備える。
【選択図】図１

Description

本発明は、画像形成装置等のコンピュータ組み込み装置の制御技術に関する。

画像形成装置等のコンピュータ組み込み装置では、プリンタエンジン、スキャナエンジン等のハードウェアについて、複雑で正確な制御が必要になる。

従来、この種のコンピュータ組み込み装置では、シングルプロセッサ（シングルコア）のコンピュータハードウェア上でオープンソースの汎用ＯＳ（Operating System）を稼働させて制御を行うことが多かった（特許文献１等を参照。）。

昨今では、従来のシングルプロセッサに代えてマルチプロセッサ（マルチコア）のコンピュータハードウェアが主流となりつつあり、オープンソースの汎用ＯＳもマルチプロセッサに対応してきている。

マルチプロセッサに対応した汎用ＯＳは、ＯＳのスケジューリング機能により実行コードを複数のプロセッサに割り振るマルチスレッド化を行う。しかし、複雑で正確な制御が必要になるコンピュータ組み込み装置では、マルチスレッド化に起因するコード実行のタイミング誤りやスレッドセーフ（処理単位であるスレッドが複数同時に一つのデータを扱ってもデータが正常に保たれる状態）の問題が生じやすい。

そのため、不具合が生じないようにチューニング等の対応が必要であるが、いったん正常な動作を確保したとしても、汎用ＯＳのアップデートによりバージョンが変わると再び不具合が発生することがあり、その都度の対応が困難であった。また、オープンソースの汎用ＯＳはメーカ製品とは異なり、提供元が不具合に対して責任をとらないため、コンピュータ組み込み装置を開発する側で全て対応せざるを得なかった。

本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、ＯＳ環境に影響されずに、コンピュータ組み込み装置の複雑で正確な制御を行えるようにすることにある。

上記の課題を解決するため、本発明にあっては、ソフトウェアにより実現される、複数の階層に分かれ、上位に対して所定のサービスを提供する複数のレイヤと、前記レイヤのそれぞれに設けられ、該レイヤに入出力するメッセージの順序制御を行うメッセージ処理部とを備える。

本発明にあっては、ＯＳ環境に影響されずに、コンピュータ組み込み装置の複雑で正確な制御を行うことができる。

画像形成装置の構成例を示す図である。 メッセージ処理部の構成例を示す図である。 メッセージ処理部の処理例を示すフローチャートである。 実機に対する外部からのテストのための構成例を示す図である。 実機がない場合のテストのための構成例を示す図（その１）である。 実機がない場合のテストのための構成例を示す図（その２）である。 画像形成装置、サーバ装置および情報処理装置のコンピュータ部分の構成例を示す図である。 デバイスエミュレータの構成例および他の部分との接続例を示す図である。 テスト例を示すシーケンス図である。

以下、本発明の好適な実施形態につき説明する。なお、組み込み装置として複合機等の画像形成装置を例に説明するが、その他の一般的な情報処理装置が内蔵しないハードウェアを有する装置に適用できることは言うまでもない。

＜画像形成装置＞
図１は画像形成装置１の構成例を示す図である。図１において、画像形成装置１は、サービスレイヤ１１２と、サービスサポートレイヤ１２２と、サービスランタイムレイヤ１３２と、アブストラクトデバイスレイヤ（抽象機器レイヤ）のモジュール１４２、１４３、１４４、１４５とを備えている。サービスレイヤ１１２は、プリント、コピー、スキャン、ファックス等の様々なサービスを提供するレイヤ（層）である。サービスサポートレイヤ１２２は、サービスを実現するための共通機能を提供するレイヤである。サービスランタイムレイヤ１３２は、デバイス管理、サービス（ジョブ）管理、認証、ストレージ等の機能を提供するレイヤである。アブストラクトデバイスレイヤは、プリンタ、スキャナ、ファックス等の機器（デバイス）を抽象化したインタフェースを提供するレイヤである。

サービスレイヤ１１２には、サービスレイヤＡＰＩ１１１が設けられている。サービスレイヤＡＰＩ１１１は、ＨＴＴＰ（HyperText Transfer Protocol）ＲＥＳＴ（REpresentational State Transfer）等によるサービスレイヤＷｅｂＡＰＩ（１１１１）と、Unix Domain Socket等のプロセス間通信によるサービスレイヤプロセス間通信ＡＰＩ（１１１２）とを含んでいる。

サービスサポートレイヤ１２２には、サービスサポートレイヤＡＰＩ１２１が設けられている。サービスサポートレイヤＡＰＩ１２１は、ＨＴＴＰ ＲＥＳＴ等によるサービスサポートレイヤＷｅｂＡＰＩ（１２１１）と、Unix Domain Socket等のプロセス間通信によるサービスサポートレイヤプロセス間通信ＡＰＩ（１２１２）とを含んでいる。

サービスランタイムレイヤ１３２にはサービスランタイムレイヤＡＰＩ１３１が設けられている。サービスランタイムレイヤＡＰＩ１３１は、ＨＴＴＰ ＲＥＳＴ等によるサービスランタイムレイヤＷｅｂＡＰＩ（１３１１）と、Unix Domain Socket等のプロセス間通信によるサービスランタイムレイヤプロセス間通信ＡＰＩ（１３１２）とを含んでいる。

アブストラクトデバイスレイヤには、アブストラクトデバイスレイヤＡＰＩ１４１が設けられている。アブストラクトデバイスレイヤＡＰＩ１４１は、ＨＴＴＰ ＲＥＳＴ等によるアブストラクトデバイスレイヤＷｅｂＡＰＩ（１４１１）と、Unix Domain Socket等のプロセス間通信によるアブストラクトデバイスレイヤプロセス間通信ＡＰＩ（１４１２）とを含んでいる。

サービスレイヤ１１２には、メッセージ処理部１１２１とプリンタアプリ１１２２とコピーアプリ１１２３とスキャナアプリ１１２４とファックスアプリ１１２５とが設けられている。メッセージ処理部１１２１は、サービスレイヤ１１２における３種類のメッセージ（コマンド、レスポンス、ノーティフィケーション）についての処理を行う機能を有している。内部構成および処理の詳細については後述する。プリンタアプリ１１２２は、プリントサービスを提供するアプリケーションプログラムである。コピーアプリ１１２３は、コピーサービスを提供するアプリケーションプログラムである。スキャナアプリ１１２４は、スキャンサービスを提供するアプリケーションプログラムである。ファックスアプリ１１２５は、ファックスサービスを提供するアプリケーションプログラムである。

サービスサポートレイヤ１２２には、メッセージ処理部１２２１とメール処理部１２２２と文書管理部１２２３とレンダリング処理部１２２４とＲＩＰ処理部１２２５とが設けられている。メッセージ処理部１２２１は、サービスサポートレイヤ１２２における３種類のメッセージ（コマンド、レスポンス、ノーティフィケーション）についての処理を行う機能を有している。内部構成および処理の詳細については後述する。メール処理部１２２２は、メールの受信および送信の処理機能を提供するものである。文書管理部１２２３は、文書の管理および保存の処理機能を提供するものである。レンダリング処理部１２２４は、画像の描画の処理機能を提供するものである。ＲＩＰ処理部１２２５は、ＲＩＰ（Raster Image Processing）の処理機能を提供するものである。

サービスランタイムレイヤ１３２にはメッセージ処理部１３２１とプリビュー処理部１３２２とジョブ管理部１３２３とストレージ処理部１３２４と認証処理部１３２５とデバイス管理部１３２６とが設けられている。メッセージ処理部１３２１は、サービスランタイムレイヤ１３２における３種類のメッセージ（コマンド、レスポンス、ノーティフィケーション）についての処理を行う機能を有している。内部構成および処理の詳細については後述する。プリビュー処理部１３２２は、プリビュー画像生成の処理機能を提供するものである。ジョブ管理部１３２３は、ジョブ管理の処理機能を提供するものである。ストレージ処理部１３２４は、ストレージ管理の処理機能を提供するものである。認証処理部１３２５は、認証の処理機能を提供するものである。デバイス管理部１３２６は、デバイス管理の処理機能を提供するものである。

アブストラクトデバイスレイヤは、画像形成装置１のコントローラアーキテクチャの中核をなしている。アブストラクトデバイスレイヤは、プリンタ、スキャナ、コピー、ファックスといった複合機のコントローラアーキテクチャ上、最下位に位置するレイヤである。その主な役割として、接続されているハードウェア機器の制御方法を隠蔽して、抽象的なＡＰＩを提供する。例えば、スキャナ機器を考えると、その接続方法や制御方法は、機器ごとに様々である。このような実際の機器の制御方法は、ＡＰＩに反映することなく、もっと抽象度が高いレベルで機器を使用するＡＰＩを提供するのが抽象機器レイヤである。一方で、アブストラクトデバイスレイヤは、上位クライアントが機器を利用する際に実現したい機能に対して制約を課さないように注意しなければならない。例えば、スキャナ機器では、原稿の１ページごとに様々なパラメータを変更することを可能にしなければならない。それは、読み込んだ１ページ目の原稿内容を解析した結果、２ページ目の読み込み方法を変更することを可能にするようなサービスを実現できるようにするためである。結果として、アブストラクトデバイスレイヤでは、原稿をまとめて読むというＡＰＩではなく、原稿１ページごとのスキャン指示ができるＡＰＩが必要となる。

アブストラクトデバイスレイヤのＡＰＩには、障害回復手順を実現するものも含まれる。通常、アブストラクトデバイスレイヤのクライアントは、機器で発生した障害（例えば、プリンタでの用紙ジャム）からの具体的な回復方法を知っている必要がないようにしなければならない。そうしないと、クライアントは、接続されている機器ごとに障害回復手順を知っていなければならなくなる。しかし、現実には、実際のユーザに対して回復方法を指示しなければならない。例えば、用紙ジャムを取り除く手順を示されなければならない。アブストラクトデバイスレイヤは、クライアントがユーザに対して障害回復手順を示すためのＡＰＩも提供し、機器ごとの障害回復手順を抽象機器レイヤのみが知っていればよいとする。総じて、アブストラクトデバイスレイヤは、制御する機器を細かく制御できるだけでなく、実際の制御方法を隠蔽したＡＰＩを提供することとなる。

プリンタモジュール１４２は、プリンタエンジン（プロッタエンジン）を抽象化した機能を提供する。基本的には、ページ単位の印刷機能を提供する。ただし、クライアントが十分に多くの印刷要求を発行した場合には、プリンタエンジンの性能を最大限となるような制御をする責任を持つ。

スキャナモジュール１４３は、スキャナエンジンを抽象化した機能を提供する。基本的には、原稿のページ単位のスキャン機能を提供する。ＡＤＦ（Auto Document Feeder）等の機器をフルスピードで制御する責任を持つ。

イメージ処理モジュール１４４は、イメージ処理を抽象化した機能を提供する。論理的に１つのモジュールとして位置付けているが、単独に行えるイメージ処理だけでなく、他のモジュールとも連携したイメージ処理を行う。例えば、スキャンしてｊｐｅｇ圧縮する場合を考えてみる。接続するスキャナによっては、ハードウェアによってスキャンと同時にｊｐｅｇ圧縮するハードウェアを持っているかもしれない。あるいは、そのようなｊｐｅｇ圧縮ハードウェアを持っていないかもしれない。どちらの構成であるかは、アブストラクトデバイスレイヤのクライアントが意識することなく、スキャンしてｊｐｅｇ圧縮を指示できる必要がある。この場合、クライアントはｊｐｅｇ圧縮処理をイメージ処理モジュール１４４へ依頼する。イメージ処理モジュール１４４は依頼処理を表す記述子を返す。クライアントは、スキャンのパラメータの１つにその記述子を指定することで、スキャン結果を圧縮することをスキャナモジュール１４３に依頼する。実際のｊｐｅｇ圧縮はハードウェアで行われるのか、ソフトウェアで行われるのかはクライアントが関知する必要がない。一方で、イメージ処理モジュール１４４は、単独でイメージ処理を行うための指示も可能である。例えば、ディスク上に保存されている複数ページのドキュメントを読み込んで、サムネイルイメージを持つドキュメントへ変換したり、各ページを回転したドキュメント変換したりすることができる。

ファックスモジュール１４５は、ファックスの送受信を抽象化した機能を提供する。

なお、各モジュール１４２、１４３、１４４、１４５は、管理しているハードウェア資源の利用権管理を行う。例えば、スキャナモジュール１４３に接続されているスキャナが１台しかない場合には、ハードウェア資源の利用は、１クライアントに限定される。そのため、クライアントは利用権を獲得して使用する必要がある。一方で、論理的に同時に利用できるクライアントを制限しない機器もある。例えば、ファックスモジュール１４５においては、送信指示は複数のクライアントから行える。なぜなら、ファックス送信は、遅延（実際には送信失敗による再送信）が許されるためである。どちらの種類の機器であっても、クライアントはハードウェア資源の獲得要求、資源の利用、資源の解放という手順を踏んでハードウェアを使用する必要がある。ここで述べるところのハードウェア資源とは、それぞれの装置が持つ細かな装置は含まれない。例えば、プリンタモジュール１４２であれば、用紙トレイやステープラなどのフィニッシャがあるが、そのようなものをハードウェア資源として個別に獲得するということではない。もっと大きな単位で、スキャナやプリンタという単位でハードウェア資源とみなして獲得する。

プリンタモジュール１４２は、メッセージ処理部１４２１と印刷処理部１４２２とエミュレータ／実機選択インタフェース１４２３とを備えている。メッセージ処理部１４２１は、プリンタモジュール１４２における３種類のメッセージ（コマンド、レスポンス、ノーティフィケーション）についての処理を行う機能を有している。内部構成および処理の詳細については後述する。印刷処理部１４２２は、印刷処理を制御する機能を有している。エミュレータ／実機選択インタフェース１４２３は、実機でないか実機であるかに応じ、デバイスエミュレータ１６２かカーネルドライバ１５を選択する機能を有している。

スキャナモジュール１４３は、メッセージ処理部１４３１とスキャン処理部１４３２とエミュレータ／実機選択インタフェース１４３３とを備えている。メッセージ処理部１４３１は、スキャナモジュール１４３における３種類のメッセージ（コマンド、レスポンス、ノーティフィケーション）についての処理を行う機能を有している。内部構成および処理の詳細については後述する。スキャン処理部１４３２は、スキャン処理を制御する機能を有している。エミュレータ／実機選択インタフェース１４３３は、実機でないか実機であるかに応じ、デバイスエミュレータ１６２かカーネルドライバ１５を選択する機能を有している。

イメージ処理モジュール１４４は、メッセージ処理部１４４１とイメージ処理部１４４２とエミュレータ／実機選択インタフェース１４４３とを備えている。メッセージ処理部１４４１は、イメージ処理モジュール１４４における３種類のメッセージ（コマンド、レスポンス、ノーティフィケーション）についての処理を行う機能を有している。内部構成および処理の詳細については後述する。イメージ処理部１４４２は、イメージ処理を制御する機能を有している。エミュレータ／実機選択インタフェース１４４３は、実機でないか実機であるかに応じ、デバイスエミュレータ１６２かカーネルドライバ１５を選択する機能を有している。

ファックスモジュール１４５は、メッセージ処理部１４５１とファックス処理部１４５２とエミュレータ／実機選択インタフェース１４５３とを備えている。メッセージ処理部１４５１は、ファックスモジュール１４５における３種類のメッセージ（コマンド、レスポンス、ノーティフィケーション）についての処理を行う機能を有している。内部構成および処理の詳細については後述する。ファックス処理部１４５２は、ファックス送受信処理を制御する機能を有している。エミュレータ／実機選択インタフェース１４５３は、実機でないか実機であるかに応じ、デバイスエミュレータ１６２かカーネルドライバ１５を選択する機能を有している。

アブストラクトデバイスレイヤを構成するモジュール１４２、１４３、１４４、１４５の下位には、カーネルドライバ１５とエミュレータＷｅｂＡＰＩ１６１とデバイスエミュレータ１６２とエンジン１７とが設けられている。カーネルドライバ１５には、実機上のエンジン１７を制御するデバイスドライバが含まれている。デバイスエミュレータ１６２は、実機上のエンジン１７の代わりに、エンジンの処理（用紙への印刷等の物理的な処理を除き、信号上のテスト対象となり得る処理）をエミュレートする機能を有している。エミュレータＷｅｂＡＰＩ１６１は、エミュレータＷｅｂＡＰＩ１６１に対して、直接にテストを行えるようにするための、ＨＴＴＰ ＲＥＳＴ等によるＡＰＩである。なお、実機においては、エミュレータＷｅｂＡＰＩ１６１およびデバイスエミュレータ１６２は起動されず、利用の観点からは画像形成装置１内に配置しておくる意義はあまりない。しかし、後述するように、サーバやＰＣ（Personal Computer）等の情報処理装置で実行される仮想画像形成装置と同じソフトウェア構成とすることで、ソフトウェアパッケージの統一性の観点からは管理が容易となる。そのような利点を考慮しない場合は、実機の画像形成装置１からはエミュレータＷｅｂＡＰＩ１６１とデバイスエミュレータ１６２を省略することもできる。

エンジン１７は、プロッタ制御部１７１とスキャナ制御部１７２とエンジン制御部１７３とエンジンドラム制御部１７４とを備えている。プロッタ制御部１７１は、プロッタの制御を行うものである。スキャナ制御部１７２は、スキャナの制御を行うものである。エンジン制御部１７３は、エンジンハードウェアの制御を行うものである。エンジンドラム制御部１７４は、エンジンドラム（モノクロの場合は１つ、カラーの場合は４つ）の制御を行うものである。

＜メッセージ処理部＞
図２はメッセージ処理部１８（１１２１、１２２１、１３２１、１４２１、１４３１、１４４１、１４５１）の構成例を示す図である。図２において、メッセージ処理部１８は、コマンド処理部１８１とレスポンス処理部１８２とノーティフィケーション処理部１８３と順序制御部１８４とを備えている。順序制御部１８４は、処理にあたって待ち合わせルール情報１８５を参照する。

コマンド処理部１８１は、コマンド入力部１８１１とタイプ識別部１８１２とタイプ別キューイング処理部１８１４とコマンド出力部１８１７とを備えている。コマンド入力部１８１１は、ＡＰＩを介して自レイヤまたは自モジュールに送信されたコマンドを入力する機能を有している。タイプ識別部１８１２は、定義情報１８１３を参照し、コマンド入力部１８１１が入力したコマンドのタイプを識別する機能を有している。タイプ別キューイング処理部１８１４は、タイプ識別部１８１２が識別したタイプ別のキュー１８１５、１８１６、・・にコマンドをキューイングする機能を有している。なお、タイプ別キューイング処理部１８１４は、対応するキューがフルである場合、続くコマンドの入力をブロックする。キューは、タイプにより深さが設定されており、待ち合わせせずに即座に実行するタイプのコマンドに対応するキューは深さが「１」とされている。コマンド出力部１８１７は、順序制御部１８４によるコマンド、レスポンス、ノーティフィケーションの順序関係の制御に基づき、許可が行われたコマンドをキュー１８１５、１８１６、・・から取り出して処理実体に出力する機能を有している。

レスポンス処理部１８２は、レスポンス入力部１８２１とタイプ識別部１８２２とタイプ別キューイング処理部１８２４とレスポンス出力部１８２７とを備えている。レスポンス入力部１８２１は、処理実体から送信されたレスポンスを入力する機能を有している。タイプ識別部１８２２は、定義情報１８２３を参照し、レスポンス入力部１８２１が入力したレスポンスのタイプを識別する機能を有している。タイプ別キューイング処理部１８２４は、タイプ識別部１８２２が識別したタイプ別のキュー１８２５、１８２６、・・にレスポンスをキューイングする機能を有している。レスポンス出力部１８２７は、順序制御部１８４によるコマンド、レスポンス、ノーティフィケーションの順序関係の制御に基づき、許可が行われたレスポンスをキュー１８２５、１８２６、・・から取り出してコマンド送信元に出力する機能を有している。

ノーティフィケーション処理部１８３は、ノーティフィケーション入力部１８３１とタイプ識別部１８３２とタイプ別キューイング処理部１８３４とノーティフィケーション出力部１８３７とを備えている。ノーティフィケーション入力部１８３１は、処理実体から送信されたノーティフィケーションを入力する機能を有している。タイプ識別部１８３２は、定義情報１８３３を参照し、ノーティフィケーション入力部１８３１が入力したノーティフィケーションのタイプを識別する機能を有している。タイプ別キューイング処理部１８３４は、タイプ識別部１８３２が識別したタイプ別のキュー１８３５、１８３６、・・にノーティフィケーションをキューイングする機能を有している。ノーティフィケーション出力部１８３７は、順序制御部１８４によるコマンド、レスポンス、ノーティフィケーションの順序関係の制御に基づき、許可が行われたノーティフィケーションをキュー１８３５、１８３６、・・から取り出して該当する宛先に出力する機能を有している。

図３はメッセージ処理部１８の処理例を示すフローチャートである。図３において、コマンド処理部１８１のコマンド入力部１８１１は、ＡＰＩを介して自モジュールに送信されたコマンドを入力する（ステップＳ１０１）。次いで、タイプ識別部１８１２は、定義情報１８１３を参照し、コマンド入力部１８１１が入力したコマンドのタイプを識別する（ステップＳ１０２）。次いで、タイプ別キューイング処理部１８１４は、タイプ識別部１８１２が識別したタイプ別のキュー１８１５、１８１６、・・にコマンドをキューイングする（ステップＳ１０３）。

また、レスポンス処理部１８２のレスポンス入力部１８２１は、処理実体から送信されたレスポンスを入力する（ステップＳ１０４）。次いで、タイプ識別部１８２２は、定義情報１８２３を参照し、レスポンス入力部１８２１が入力したレスポンスのタイプを識別する（ステップＳ１０５）。次いで、タイプ別キューイング処理部１８２４は、タイプ識別部１８２２が識別したタイプ別のキュー１８２５、１８２６、・・にレスポンスをキューイングする（ステップＳ１０６）。

また、ノーティフィケーション処理部１８３のノーティフィケーション入力部１８３１は、処理実体から送信されたノーティフィケーションを入力する（ステップＳ１０７）。次いで、タイプ識別部１８３２は、定義情報１８３３を参照し、ノーティフィケーション入力部１８３１が入力したノーティフィケーションのタイプを識別する（ステップＳ１０８）。次いで、タイプ別キューイング処理部１８３４は、タイプ識別部１８３２が識別したタイプ別のキュー１８３５、１８３６、・・にノーティフィケーションをキューイングする（ステップＳ１０９）。

一方、順序制御部１８４は、待ち合わせルール情報１８５を参照し、コマンド、レスポンス、ノーティフィケーションの順序関係を判断して指示を行う（ステップＳ１１１）。コマンド処理部１８１のコマンド出力部１８１７は、順序制御部１８４から指示を受けた場合、許可が行われたコマンドをキュー１８１５、１８１６、・・から取り出し（ステップＳ１１２）、処理実体に出力する（ステップＳ１１３）。

レスポンス処理部１８２のレスポンス出力部１８２７は、順序制御部１８４から指示を受けた場合、許可が行われたレスポンスをキュー１８２５、１８２６、・・から取り出し（ステップＳ１１４）、コマンド送信元に出力する（ステップＳ１１５）。

ノーティフィケーション処理部１８３のノーティフィケーション出力部１８３７は、順序制御部１８４から指示を受けた場合、許可が行われたノーティフィケーションをキュー１８３５、１８３６、・・から取り出し（ステップＳ１１６）、該当する宛先に出力する（ステップＳ１１７）。

以下、アブストラクトデバイスレイヤの各モジュール１４２、１４３、１４４、１４５におけるメッセージ処理部１４２１、１４３１、１４４１、１４５１の扱うメッセージについて、より詳細に説明する。

アブストラクトデバイスレイヤに対するクライアントのＡＰＩは、コマンド（Command）、レスポンス（Response）、ノーティフィケーション（Notification）の３つのメッセージから構成される。コマンドは、クライアントからアブストラクトデバイスレイヤに対する指示に用いられる。コマンドには、順番に実行されるものと、優先的に実行されるものがある。後者の例としては、「発行済みコマンドをキャンセルするコマンド」等が含まれる。クライアントは、個々のコマンドに対するレスポンスを待つことなく、連続してコマンドを発行することができる。

レスポンスは、コマンドに対するレスポンスとしてアブストラクトデバイスレイヤからクライアントへ返される。ノーティフィケーションは、アブストラクトデバイスレイヤで発生した抽象機器モジュールから何らかの事象を通知するためのものである。ノーティフィケーションには、自発的にアブストラクトデバイスレイヤから通知されるものと、コマンドの実行により発生して通知されるものがある。後者をイベント（Event）と呼び、コマンドを発行したクライアントへのみ通知される。それ以外のノーティフィケーションは、論理的に接続しているすべてのクライアントへ通知される。論理的というのは、物理的に常に接続されているとは限らないことを指して使用している。最終的な実装では、ＴＣＰ（Transmission Control Protocol）などで常に接続されている場合も考えられる。イベントと他の種類のノーティフィケーションは、メッセージ名の末尾がEVENTで終了するか否かで区別される。

レスポンスとノーティフィケーションは、クライアントに対しては非同期に通知される。アブストラクトデバイスレイヤが、完全な非同期なメッセージ通信方式を利用しているのは、本質的に要求を出された処理が完了するために時間を要するためである。仮にＲＰＣ（Remote Procedure Call）などの方式を用いて、レスポンスが返ってくるまでに時間を要することを前提とする設計では、一般にアクティブオブジェクトパターン（もしくはFuture）方式が採用される。しかし、それを前提とした設計は、いわゆるマルチスレッドプログラミングを要求することになり、設計・実装が難しくなる。また、非同期なメッセージ通信方式の上に、クライアントのプログラミングを容易にするようなライブラリを構築することは難しくはない。

コマンドは、大きく、基本コマンドとモジュール固有コマンドに分類される。基本コマンドは、すべてのモジュールがサポートするコマンドである。コマンドの意味はほとんどのモジュールで同じである。モジュール固有コマンドは、その名前の通り、モジュールに固有のコマンドである。コマンドは、その処理形態において、順次キューイングされて実行されるコマンドと、キューイングされずに即時実行されるコマンドの２種類に分類される。

コマンド、レスポンス、ノーティフィケーションの各メッセージには共通なパラメータとしてシーケンス番号を持つ。コマンドを発行する際には、クライアント側がクライアント毎に一意となる１以上の整数のシーケンス番号を割り振って、単調増加するように付与しなければならない。シーケンス番号は、例えば、６４ビット整数を使用して表現する。６４ビット整数を使用することで、コマンドごとに１増やしながら割り当てても、一巡して戻ってくることを回避することができる。レスポンスに付与されるシーケンス番号は、対応するコマンドのシーケンス番号と同じである。ノーティフィケーションに付与されるシーケンス番号は、常に０である。

基本コマンドとしては、
ENABLE / DISABLE
SHUTDOWN
LOCK-DEVICE / UNLOCK-DEVICE
START-JOB / END-JOB
ABORT-COMMAND
START-FAULT-RECOVERY / END-FAULT-RECOVERY
ATTACH-SHARED-MEMORY / DETACH-SHARED-MEMORY
がある。

ENABLEコマンドは、抽象機器モジュールの動作を開始することを指示する。ここでいう動作の開始とは、様々なノーティフィケーションの通知を行ってよいという意味での開始である。各モジュールは、起動時に必要な機器の初期化を行う。しかし、初期化の結果、機器が使用可能な状態なのか、あるいは何らかの障害が発生して使用できない状態なのかを判断済みである。しかし、そのような状態の通知は、あくまでもクライアントが通知を受ける準備が整ってから送る必要がある。そのために、ENABLEコマンドが用いられる。ENABLEコマンドを受け付けた時点ですでに機器に障害が発生している場合には、コマンドに対するCOMPLETEDレスポンスが返される前に、FAULTEDノーティフィケーションが通知される。

DISABLEコマンドは、システムが終了する際に送られるコマンドであり、それ以降、一切のノーティフィケーションを通知をしない状態となる。なお、これ以降のみ、ENABLEコマンド以外にSHUTDOWNコマンドを受け付ける。

SHUTDOWNコマンドは、ENABLEされていない状態でのみ発行可能なコマンドであり、抽象機器モジュールに対して、プログラムの終了を指示する。SHUTDOWNコマンドに対するレスポンスを送信後、該当モジュールは終了する。

LOCK-DEVICEコマンドは、機器の使用権を獲得する。UNLOCK-DEVICEコマンドは、機器の使用権を解除する。接続されている機器を使用できるクライアントが高々１つだけの場合には、多重にロックはできない。ファックスモジュールなどのような場合には、多重にロックできることもある。スキャナやプリンタ等のエンジンは、通常の複合機の構成では１台しか接続されないが、ここでは、複数台接続される構成も考慮している。一方、１台しか接続されていない場合でも、上位のレイヤからは、一度に１つのクライアントのみがアクセスすることを保証するためにあえてLOCK-DEVICEコマンドを発行してもらう。１台のプリンタが持つトレイやフィニッシャ等は、ロックする対象ではない。それらは、あくまでもアブストラクトデバイスレイヤで管理されるものである。

ABORT-COMMANDコマンドは、すでに依頼済みのコマンドをキャンセルするためのコマンドである。このコマンドを使用して、前述の「ジョブ」全体をキャンセルすることも可能である。どのコマンドをキャンセルするかは、該当コマンドのシーケンス番号を指定することで行う。

START-FAULT-RECOVERYコマンドは、FAULT-RECOVERY-INSTRUCTIONノーティフィケーションの通知を指示するコマンドである。通常、障害（FAULT）は、ノーティフィケーションとして通知されるが、どのように回復するかを指示するノーティフィケーションは自発的には通知されない。START_FAULT_RECOVERYコマンドが発行された時点で障害が発生していない場合にでも、その後に障害が発生するとFAULT-RECOVERY-INSTRUCTIONノーティフィケーションの通知が行われる。そのような通知を停止するには、END_FAULT_RECOVERYコマンドを使用する。

ATTACH-SHARED-MEORYコマンドとDETACH-SHARED-MEMORYコマンドは、上位レイヤとの画像の受け渡しに使用する共有メモリのアッタチとデタッチを行う。ATTACH-SHARED-MEMORYコマンドでは、共有メモリのキーおよび大きさがパラメータとして渡される。DETACH-SHARED-MEMORYコマンドでは、共有メモリのキーが渡される。

REGISTER-EXEC-PARAMSコマンドとUNREGISTER-EXEC-PARAMSコマンドは、アブストラクトデバイスレイヤが提供する各モジュール（プリンタモジュール、スキャナモジュール、イメージ処理モジュール、ファックスモジュール）に対する動作モードパラメータ（各種動作条件）一式を登録および削除する。

全てのコマンドに対するレスポンスには、基本レスポンスとして、
COMPLETED
ABORTED
ILLEGAL-PARAMETER-ERROR
ILLEGAL-STATE-ERROR
NO-SUCH-COMMAND-ERROR
がある。モジュール固有コマンドであってもレスポンスは、ここに記述されたものだけである。

COMPLETEDレスポンスは、コマンドが完了したことを示すレスポンスである。レスポンスには、追加のパラメータを付けることが可能である。

ABORTEDレスポンスは、コマンドが中止されたことを示すレスポンスである。コマンドは、基本的にABORT-COMMANDコマンドでのみ中止されるコマンドと、自発的に中止されるコマンドの２種類に分かれる。例えば、LOCK-DEVICEコマンドの場合には、機器をロックできなければ、ABORTEDレスポンスが返されて、追加のパラメータでその理由が示される。ファックスモジュール等の再送回数オーバの場合は、ABORTEDレスポンスが返されて、追加パラメータで再送回数オーバであることを示す。

ILLEGAL-PARAMETER-ERRORレスポンスは、コマンドに付随するパラメータの値が不正であったり、必要なパラメータが指定されていなかったりした場合に返されるレスポンスである。追加の情報としてどのパラメータが問題であるかを示すパラメータを持つ。

IILLEGAL-STATE-ERRORレスポンスは、コマンドが誤った順序、もしくは、誤った状態の時に発行されたことを示すレスポンスである。

NO-SUCH-COMMAND-ERRORレスポンスは、指定されたコマンドがサポートされていないことを示すレスポンスである。

全てのモジュールに共通な基本ノーティフィケーションとしては、
ENABLED / DISABLED
WARMING-UP / READY
DEVICE-LOCKED / DEVICE-UNLOCKED
FAULTED / FAULT-CLEARED
FAULT-RECOVERY-INSTRUCTION
STATUS
がある。

ENABLEDノーティフィケーションとDISABLEDノーティフィケーションは、ENABLEコマンド／DISABLEコマンドにより状態が変化した場合の通知を行う。これらのノーティフィケーションは、コマンドのレスポンスに先立って通知される。例えば、ENABLEコマンドを受け付けて処理を行うと、ENABLEDノーティフィケーションが通知されて、それから、ENABLEコマンドに対するCOMPLETEDレスポンスが返される。ENABLEコマンドを受け付けた時点で、すでに何らかの障害が発生している場合には、COMPLETEDレスポンスが返される前に、FAULTEDノーティフィケーションの通知が行われる。

WARMING-UPノーティフィケーションとREADYノーティフィケーションは、接続されている機器が使用可能状態である通知を行う。何らかの障害が発生している場合には、FAULTEDノーティフィケーションが代わりに通知される。また、すべての障害がクリア（解消）された場合にも、このREADYノーティフィケーションが通知される。何も障害は発生していないが、機器がウォームアップ中であればREADYノーティフィケーションの代わりにWARMING-UPノーティフィケーションが通知される。

DEVICE-LOCKEDノーティフィケーションとDEVICE-UNLOCKEDノーティフィケーションは、LOCK-DEVICEコマンド／UNLOCK-DEVICEコマンドにより、機器がロックされたりロック解除された場合の通知を行う。このノーティフィケーションは、コマンドのレスポンスに先立って通知される。ノーティフィケーションは、すべてのクライアントに通知されるため、実際にロックを行っていないクライアントも、これらの通知を受けることでロックに関する状態を知ることができる。

FAULTEDノーティフィケーションは、機器に障害が発生したことを通知する。障害ごとに障害番号が自動採番されて付与される。FAULT-CLEAREDノーティフィケーションは、その障害番号を示すことで、該当する障害が解消されたことを示す。

FAULT-RECOVERY-INSTRUCTIONノーティフィケーションは、機器に障害が発生している場合に、START-FAULT-RECOVERYコマンドを受け付けて処理した結果として通知が行われる。障害が無い場合には、START-FAULT-RECOVERYコマンドを受け付けても何も処理されない。このノーティフィケーションは、ユーザが行う障害対応処理に関する情報を含んでおり、ユーザに示されることが想定されている。例えば、印刷時の用紙ジャムが発生している場合には、どのように取り除くかを示すための情報が含まれる。ユーザの障害対応状況に応じて、必要ならば自動的に次のFAULT-RECOVERY-INSTURCTIONノーティフィケーションが通知される。END-FAULT-RECOVERYコマンドが発行されるまでは、新たに障害が発生すると自動的にＦAULT-RECOVERY-INSTRUCTIONノーティフィケーションが通知される。FAULT-RECOVERY-INSTRUCTIONノーティフィケーションで通知される情報は、基本的にユーザに障害を取り除かせるための情報であるため、メッセージ、画像、あるいは、両方の情報を含むことになる。詳細を検討する際には、多言語対応を考慮する必要がある。

STATUSノーティフィケーションは各種の状態を通知する。状態が変更になった場合には、自動的に通知される。このノーティフィケーションは通知対象種別とその対象のステータスを含む。STATUSという名前のメッセージは存在しない。STATUSノーティフィケーションとして分類されるのは、メッセージの名前の末尾がSTATUSとなっているものを指す。

なお、ここではメッセージの実際の通信方式の詳細については規定しない。しかし、コマンド／レスポンス／ノーティフィケーションの通信ができればよく、実際の通信ではバイナリデータ形式ではなくＡＳＣＩＩ文字もしくはＵＴＦ−８形式で送受信されることが望ましい。テキスト形式を用いることにより、デバッグ時の情報としてそのまま利用できることが、バイナリデータ形式ではない最大の理由である。また、実際の通信として、REST APIに準拠する可能性を考えると、ＪＳＯＮ形式がよいと思われる。

アブストラクトデバイスレイヤと上位レイヤ間でのイメージの受け渡し方式は、基本的にファイルか共有メモリの２通りとなる。ファイルを指定される場合には、アブストラクトデバイスレイヤは、画像データをそのファイルから読み出したり、画像データをそのファイルへ保存したりする。Linux（登録商標）システム上では、mmapを使用することを想定している。mmapされたファイルへscatter/gather DMAを使用してプリンタエンジンへ転送したり、スキャナエンジンから転送したりする。共有メモリに関しては、ATTACH-SHARED-MEMORYコマンドで指定された共有メモリの指定されたオフセットから画像データを読み出したり、指定されたオフセットへ画像データを書き込んだりする。アブストラクトデバイスレイヤでは、共有メモリの管理は行わない。共有メモリをどのように管理するかは上位レイヤの責務である。

＜実機によるテスト構成＞
図４は実機に対する外部からのテストのための構成例を示す図である。図４において、画像形成装置１はインターネット等のネットワーク３に接続され、ネットワーク３には、サーバ装置２とＰＣ等の情報処理装置４が接続されている。なお、サーバ装置２と情報処理装置４はいずれも「情報処理装置」であるが、ここでは、便宜的に、ネットワーク上にあって共用されるものをサーバ装置２、個々のユーザにより使用されるものを情報処理装置４と呼んでいるに過ぎない。

サーバ装置２には、テストを容易にするための各種のテストコード群２１が格納され、情報処理装置４等から参照することができる。なお、実機でのテストでは、原則として画像形成装置１内のデバイスエミュレータ（１６２）を使用しないため、図示を省略してある。情報処理装置４には、サーバ装置２のテストコード群２１を元に作成した操作部コード４１と任意レイヤテストコード４２が保持されている。

情報処理装置４において、操作部コード４１を実行することで、画像形成装置１に対して実際上の操作部（オペレーションパネル）として実機に対するのと同様の操作を行うことができる。画像形成装置１について言えば、操作部のない（操作部レスの）画像形成装置となる。これにより、ユーザ先に納入された多数の画像形成装置１について、所定の操作に対して所定の処理が正常に行えるか否かのテストを実施することができる。

また、情報処理装置４において、任意レイヤテストコード４２を実行することで、画像形成装置１の任意のレイヤについて任意のテストを実施することができる。

＜実機なしのテスト構成＞
図５は実機がない場合のテストのための構成例を示す図である。図５において、インターネット等のネットワーク３にはサーバ装置２とＰＣ等の情報処理装置４が接続されている。サーバ装置２には、テストを容易にするための各種のテストコード群２１が格納され、情報処理装置４等から参照することができる。また、サーバ装置２には、実機の画像形成装置１からエンジン部分を除いたソフトウェアのみで実行する仮想画像形成装置１Ｖが設けられている。仮想画像形成装置１Ｖは、サービスレイヤＡＰＩ１１１Ｖ、サービスレイヤ１１２Ｖ、サービスサポートレイヤＡＰＩ１２１Ｖ、サービスサポートレイヤ１２２Ｖ、サービスランタイムレイヤＡＰＩ１３１Ｖ、サービスランタイムレイヤ１３２Ｖ、アブストラクトデバイスレイヤＡＰＩ１４１Ｖ、プリンタモジュール１４２Ｖ、スキャナモジュール１４３Ｖ、イメージ処理モジュール１４４Ｖ、ファックスモジュール１４５Ｖ、エミュレータＷｅｂＡＰＩ１６１Ｖ、デバイスエミュレータ１６２Ｖを備えている。情報処理装置４には、サーバ装置２のテストコード群２１を元に作成した操作部コード４１と任意レイヤテストコード４２が保持されている。

情報処理装置４において、操作部コード４１を実行することで、サーバ装置２上の仮想画像形成装置１Ｖに対して操作上のテストを行うことができる。また、情報処理装置４において、任意レイヤテストコード４２を実行することで、仮想画像形成装置１Ｖの任意のレイヤについて任意のテストを実施することができる。

図６は実機がない場合のテストのための他の構成例を示す図である。図６において、インターネット等のネットワーク３にはサーバ装置２とＰＣ等の情報処理装置４が接続されている。サーバ装置２には、テストを容易にするための各種のテストコード群２１が格納され、情報処理装置４等から参照することができる。また、サーバ装置２には、実機の画像形成装置１からエンジン部分を除いたソフトウェアのみの仮想画像形成装置プログラム２２が格納され、情報処理装置４等からダウンロードすることができる。情報処理装置４には、仮想画像形成装置プログラム２２をダウンロードして実行することで実現される、実機の画像形成装置１からエンジン部分を除いたソフトウェアのみで実行する仮想画像形成装置１Ｖが設けられている。仮想画像形成装置１Ｖは、サービスレイヤＡＰＩ１１１Ｖ、サービスレイヤ１１２Ｖ、サービスサポートレイヤＡＰＩ１２１Ｖ、サービスサポートレイヤ１２２Ｖ、サービスランタイムレイヤＡＰＩ１３１Ｖ、サービスランタイムレイヤ１３２Ｖ、アブストラクトデバイスレイヤＡＰＩ１４１Ｖ、プリンタモジュール１４２Ｖ、スキャナモジュール１４３Ｖ、イメージ処理モジュール１４４Ｖ、ファックスモジュール１４５Ｖ、エミュレータＷｅｂＡＰＩ１６１Ｖ、デバイスエミュレータ１６２Ｖを備えている。情報処理装置４には、サーバ装置２のテストコード群２１を元に作成した操作部コード４１と任意レイヤテストコード４２が保持されている。

情報処理装置４において、操作部コード４１を実行することで、情報処理装置４上の仮想画像形成装置１Ｖに対して操作上のテストを行うことができる。また、情報処理装置４において、任意レイヤテストコード４２を実行することで、仮想画像形成装置１Ｖの任意のレイヤについて任意のテストを実施することができる。

図７は画像形成装置１、サーバ装置２および情報処理装置４のコンピュータ部分の構成例を示す図である。図７において、コンピュータ部分は、システムバス１００１に接続されたＣＰＵ（Central Processing Unit）１００２、ＲＯＭ（Read Only Memory）１００３、ＲＡＭ（Random Access Memory）１００４、ＮＶＲＡＭ（Non-Volatile Random Access Memory）１００５を備えている。また、コンピュータ部分は、Ｉ／Ｆ（Interface）１００６と、Ｉ／Ｆ１００６に接続された、Ｉ／Ｏ（Input/Output Device）１００７、ＨＤＤ（Hard Disk Drive）１００８、ＮＩＣ（Network Interface Card）１００９と、Ｉ／Ｏ１００７に接続されたモニタ１０１０、キーボード１０１１、マウス１０１２等を備えている。Ｉ／Ｏ１００７にはＣＤ／ＤＶＤ（Compact Disk/Digital Versatile Disk）ドライブ等を接続することもできる。

＜デバイスエミュレータ＞
図８はデバイスエミュレータ１６２の構成例および他の部分との接続例を示す図である。原則として実機の画像形成装置１ではデバイスエミュレータ１６２を使用する実益はあまりないため、図５または図６による利用形態が一般的となる。ただし、実機の画像形成装置１であっても、エンジンに不具合があって利用できない場合や、搭載されたエンジンとは異なる仕様のエンジンについてテストしたい場合等には、デバイスエミュレータ１６２を使用することは可能である。そのため、図４による利用形態も排除されるものではない。従って、画像形成装置１および仮想画像形成装置１Ｖの構成要素については、便宜上、画像形成装置１の構成要素の符号を用いて示す。

図８において、デバイスエミュレータ１６２は、フロントエンド部１６２１とバックエンド部１６２２とを備えている。フロントエンド部１６２１は、エミュレータＷｅｂＡＰＩ１６１を介して送受信されるメッセージに対してＷｅｂサーバの機能を提供するものであり、エミュレータＷｅｂＡＰＩ１６１から受信したメッセージを変換（例えば、ＲＥＳＴから内部プロトコルへ変換）してバックエンド部１６２２に伝え、バックエンド部１６２２からのメッセージを変換（例えば、内部プロトコルからＲＥＳＴへ変換）してエミュレータＷｅｂＡＰＩ１６１に送信する。バックエンド部１６２２は、エンジンの実質的なエミュレーション機能を有しており、アブストラクトデバイスレイヤの各モジュール（スキャナモジュール１４３についてのみ図示）のエミュレータ／実機選択インタフェース１４３３、・・との接続と、フロントエンド部１６２１との接続の２つの接続を有している。

また、図示の例では、情報処理装置４上のテストコード４３により、エミュレータＷｅｂＡＰＩ１６１にアクセスする経路と、アブストラクトデバイスレイヤＷｅｂＡＰＩ１４１１にアクセスする経路と、アブストラクトデバイスレイヤプロセス間通信ＡＰＩ１４１２にアクセスする経路とを示しているが、アクセスする経路はこれに限らない。テストコード４３からエミュレータＷｅｂＡＰＩ１６１にアクセスする経路は、他のレイヤを通さずに直接にデバイスエミュレータ１６２によりテストを行う場合に適している。Ｗｅｂ経由のみのアクセスであれば、エミュレータＷｅｂＡＰＩ１６１を使用するか、サービスレイヤＷｅｂＡＰＩ１１１１、サービスサポートレイヤＷｅｂＡＰＩ１２１１、サービスランタイムレイヤＷｅｂＡＰＩ１３１１、アブストラクトデバイスレイヤＷｅｂＡＰＩ１４１１にアクセスする経路を用いることができる。プロセス間通信が使える環境では、サービスレイヤプロセス間通信ＡＰＩ１１１２、サービスサポートレイヤプロセス間通信ＡＰＩ１２１２、サービスランタイムレイヤプロセス間通信ＡＰＩ１３１２、アブストラクトデバイスレイヤプロセス間通信ＡＰＩ１４１２にアクセスする経路を用いることができる。プロセス間通信による経路では、Ｗｅｂ経由よりも高速にアクセスを行うことができる。

図９はテスト例を示すシーケンス図であり、テストコード４３からアブストラクトデバイスレイヤＷｅｂＡＰＩ１４１１またはアブストラクトデバイスレイヤプロセス間通信ＡＰＩ１４１２を介してスキャナモジュール１４３との間でメッセージのやりとりを行う場合と、テストコード４３からエミュレータＷｅｂＡＰＩ１６１を介してデバイスエミュレータ１６２のフロントエンド部１６２１にメッセージを送信し、バックエンド部１６２２からスキャナモジュール１４３とアブストラクトデバイスレイヤＷｅｂＡＰＩ１４１１またはアブストラクトデバイスレイヤプロセス間通信ＡＰＩ１４１２を介してテストコード４３にメッセージを送信する場合の例について示している。

図９において、テストコード４３からENABLEコマンドをアブストラクトデバイスレイヤＷｅｂＡＰＩ１４１１またはアブストラクトデバイスレイヤプロセス間通信ＡＰＩ１４１２を介してスキャナモジュール１４３に送信する（ステップＳ２０１）。スキャナモジュール１４３は、ENABLEDノーティフィケーション、ORIGINAL-STATUSノーティフィケーション、PLATEN-STATUSノーティフィケーション、READYノーティフィケーション、COMPLETEDレスポンスを順にテストコード４３に送信する（ステップＳ２０２〜Ｓ２０６）。

同様に、テストコード４３からLOCK-DEVICEコマンドをアブストラクトデバイスレイヤＷｅｂＡＰＩ１４１１またはアブストラクトデバイスレイヤプロセス間通信ＡＰＩ１４１２を介してスキャナモジュール１４３に送信する（ステップＳ２１１）。スキャナモジュール１４３は、DEVICE-LOCKEDノーティフィケーション、COMPLETEDレスポンスを順にテストコード４３に送信する（ステップＳ２１２、Ｓ２１３）。

一方、テストコード４３からエミュレータＷｅｂＡＰＩ１６１を介してコマンド「PUT/scanner/platen {"cover":"open"}」を介してフロントエンド部１６２１に送信する（ステップＳ２２１）。フロントエンド部１６２１は、内部プロトコルのコマンド「Platen.SetCover(PlatenCoverStatus.OPEN)」に変換してバックエンド部１６２２に伝える（ステップＳ２２２）。バックエンド部１６２２は、エミュレーションを行い、変更されたステータスをスキャナモジュール１４３に伝える（ステップＳ２２３）。スキャナモジュール１４３は、PLATEN-STATUSノーティフィケーションをテストコード４３に送信する（ステップＳ２２４）。

同様に、テストコード４３からエミュレータＷｅｂＡＰＩ１６１を介してコマンド「PUT/scanner/platen {"cover":"close"}」を介してフロントエンド部１６２１に送信する（ステップＳ２３１）。フロントエンド部１６２１は、内部プロトコルのコマンド「Platen.SetCover(PlatenCoverStatus.CLOSE)」に変換してバックエンド部１６２２に伝える（ステップＳ２３２）。バックエンド部１６２２は、エミュレーションを行い、変更されたステータスをスキャナモジュール１４３に伝える（ステップＳ２３３）。スキャナモジュール１４３は、PLATEN-STATUSノーティフィケーションをテストコード４３に送信する（ステップＳ２３４）。

一方、テストコード４３からSTARTコマンドをアブストラクトデバイスレイヤＷｅｂＡＰＩ１４１１またはアブストラクトデバイスレイヤプロセス間通信ＡＰＩ１４１２を介してスキャナモジュール１４３に送信する（ステップＳ２４１）。スキャナモジュール１４３は、STARTコマンドをバックエンド部１６２２に伝える（ステップＳ２４２）。これにより、スキャンのエミュレーションが開始される。

図８に戻り、デバイスエミュレータ１６２のバックエンド部１６２２と、スキャナモジュール１４３のエミュレータ／実機選択インタフェース１４３３（他のモジュールについても同様）およびフロントエンド部１６２１との間の通信について以下に説明する。

バックエンド部１６２２は、サーバ側として、クライアント側であるスキャナモジュール１４３のエミュレータ／実機選択インタフェース１４３３およびフロントエンド部１６２１からの接続を待ち受ける機能を有している。

サーバ側は、例えば、Unix Domain Socketでクライアント側からの接続を待ち受ける。クライアント側は、例えば、Unix Domain Socketでサーバに接続する。使用するUnix Domain Socketのパス名は予め合意しているものとする。

サーバ側は、同時に一つのクライアント側からだけ接続をアクセプト（Accept）し、コネクタの初期状態のStatusメッセージを送信する。クライアント側は、初期状態のStatusメッセージに対し返答のStatusメッセージを返してから、通信を開始する。

クライアント側は、いつでもサーバ側との接続を切断してもよい。サーバ側は、エラー検出時を除き、クライアント側との接続を切断してはならない。クライアント側とサーバ側は、プロトコル上のエラーや復旧不可能な内部エラーが発生した場合は、接続を切断する。

Statusメッセージでは、コネクタのステータスとして、"ready"、"frozen"、"unavailable"の文字列を送ることができる。サーバ側は、クライアント側に対してStatusメッセージを通知できる。クライアント側は、Statusメッセージを受信すると、メッセージを処理し、返答としてサーバ側に同じＳｔａｔｕｓメッセージを通知しなければならない。サーバ側は、Statusメッセージの送信後は、クライアント側からその返答のStatusメッセージを受信するまでは次のStatusメッセージを送信してはならない。サーバ側は、最後にクライアント側から受信したStatusメッセージと同じStatusメッセージを通知してはならない。

Commandメッセージでは、一つの内部プロトコルによるコマンドのバイトスライスを送信することができる。サーバ側は、クライアント側からのready Statusメッセージ受信後にCommandメッセージを送信できる。サーバ側は、クライアント側へfrozen Statusメッセージもしくはunavailable Statusメッセージの送信後は、ready Statusメッセージを受信するまではCommandメッセージを送信してはならない。クライアント側は、サーバ側へready Statusメッセージの送信後にCommandメッセージを送信できる。クライアント側は、サーバ側へfrozen Statusメッセージもしくはunavailable Statusメッセージの送信後は、ready Statusメッセージを受信するまではCommandメッセージを送信してはならない。

＜総括＞
以上説明したように、本実施形態によれば、次のような利点がある。
（１）画像形成装置のソフトウェア部分を構成する各レイヤのそれぞれに、各レイヤに入出力するメッセージの順序制御を行うメッセージ処理部を備えているため、マルチプロセッサ環境でも、ＯＳ環境に影響されずに、実行順序の維持やスレッドセーフを実現することができ、コンピュータ組み込み装置の複雑で正確な制御を行うことができる。
（２）各レイヤはメッセージのやりとりだけで所定のサービスを提供することができるため、各レイヤの置かれる物理的な位置に影響されず、位置透過性を実現することができる。
（３）各レイヤは、実装詳細を隠蔽し、実装詳細に影響されないインタフェースを外部に提供しているため、ＡＰＩを変更することなく、内部構造を変更することができる。そのため、ＡＰＩを用いたクライアントプログラムの変更は発生せず、工数の大幅な削減を図ることができる。
（４）実機のハードウェアをエミュレートするデバイスエミュレータとその他のソフトウェア部分により、サーバ装置や情報処理装置の上で仮想的な画像形成装置を動作させることができ、実機がなくても任意のレイヤのテストを行うことができる。これにより、コンピュータ組み込み装置のテストを柔軟に行うことができる。
（５）実機に対して任意のレイヤのテストを行うことができるため、顧客に納入後の市場規模の台数のテストを行うことができる。これにより、コンピュータ組み込み装置のテストを柔軟に行うことができる。
（６）最下層のレイヤは、実機のハードウェアとデバイスエミュレータとを切り替える選択インタフェースを備えるため、実機とテスト環境とで同じソフトウェア構成とすることができる。
（７）操作部の機能を画像形成装置の機能から分離して開発することが可能となる。

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

１ 画像形成装置
１１１ サービスレイヤＡＰＩ
１１１１ サービスレイヤＷｅｂＡＰＩ
１１１２ サービスレイヤプロセス間通信ＡＰＩ
１１２ サービスレイヤ
１１２１ メッセージ処理部
１１２２ プリンタアプリ
１１２３ コピーアプリ
１１２４ スキャナアプリ
１１２５ ファックスアプリ
１２１ サービスサポートレイヤＡＰＩ
１２１１ サービスサポートレイヤＷｅｂＡＰＩ
１２１２ サービスサポートレイヤプロセス間通信ＡＰＩ
１２２ サービスサポートレイヤ
１２２１ メッセージ処理部
１２２２ メール処理部
１２２３ 文書管理部
１２２４ レンダリング処理部
１２２５ ＲＩＰ処理部
１３１ サービスランタイムレイヤＡＰＩ
１３１１ サービスランタイムレイヤＷｅｂＡＰＩ
１３１２ サービスランタイムレイヤプロセス間通信ＡＰＩ
１３２ サービスランタイムレイヤ
１３２１ メッセージ処理部
１３２２ プリビュー処理部
１３２３ ジョブ管理部
１３２４ ストレージ処理部
１３２５ 認証処理部
１３２６ デバイス管理部
１４１ アブストラクトデバイスレイヤＡＰＩ
１４１１ アブストラクトデバイスレイヤＷｅｂＡＰＩ
１４１２ アブストラクトデバイスレイヤプロセス間通信ＡＰＩ
１４２ プリンタモジュール
１４２１ メッセージ処理部
１４２２ 印刷処理部
１４２３ エミュレータ／実機選択インタフェース
１４３ スキャナモジュール
１４３１ メッセージ処理部
１４３２ スキャン処理部
１４３３ エミュレータ／実機選択インタフェース
１４４ イメージ処理モジュール
１４４１ メッセージ処理部
１４４２ イメージ処理部
１４４３ エミュレータ／実機選択インタフェース
１４５ ファックスモジュール
１４５１ メッセージ処理部
１４５２ ファックス処理部
１４５３ エミュレータ／実機選択インタフェース
１５ カーネルドライバ
１６１ エミュレータＷｅｂＡＰＩ
１６２ デバイスエミュレータ
１６２１ フロントエンド部
１６２２ バックエンド部
１７ エンジン
１７１ プロッタ制御部
１７２ スキャナ制御部
１７３ エンジン制御部
１７４ エンジンドラム制御部
１８ メッセージ処理部
１８１ コマンド処理部
１８１１ コマンド入力部
１８１２ タイプ識別部
１８１３ 定義情報
１８１４ タイプ別キューイング処理部
１８１５、１８１６ キュー
１８１７ コマンド出力部
１８２ レスポンス処理部
１８２１ レスポンス入力部
１８２２ タイプ識別部
１８２３ 定義情報
１８２４ タイプ別キューイング処理部
１８２５、１８２６ キュー
１８２７ レスポンス出力部
１８３ ノーティフィケーション処理部
１８３１ ノーティフィケーション入力部
１８３２ タイプ識別部
１８３３ 定義情報
１８３４ タイプ別キューイング処理部
１８３５、１８３６ キュー
１８３７ ノーティフィケーション出力部
１８４ 順序制御部
１８５ 待ち合わせルール情報
２ サーバ装置
２１ テストコード群
２２ 仮想画像形成装置プログラム
３ ネットワーク
４ 情報処理装置
４１ 操作部コード
４２ 任意レイヤテストコード
４３ テストコード
１Ｖ 仮想画像形成装置
１１１Ｖ サービスレイヤＡＰＩ
１１２Ｖ サービスレイヤ
１２１Ｖ サービスサポートレイヤＡＰＩ
１２２Ｖ サービスサポートレイヤ
１３１Ｖ サービスランタイムレイヤＡＰＩ
１３２Ｖ サービスランタイムレイヤ
１４１Ｖ アブストラクトデバイスレイヤＡＰＩ
１４２Ｖ プリンタモジュール
１４３Ｖ スキャナモジュール
１４４Ｖ イメージ処理モジュール
１４５Ｖ ファックスモジュール
１６１Ｖ エミュレータＷｅｂＡＰＩ
１６２Ｖ デバイスエミュレータ

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

Claims (6)

1. ソフトウェアにより実現される、複数の階層に分かれ、上位に対して所定のサービスを提供する複数のレイヤと、
   前記レイヤのそれぞれに設けられ、該レイヤに入出力するメッセージの順序制御を行うメッセージ処理部と
   を備えたことを特徴とするコンピュータ組み込み装置。
2. 請求項１に記載のコンピュータ組み込み装置において、
   前記メッセージ処理部が入出力するメッセージは、コマンド、レスポンスおよびノーティフィケーションの３種類とする
   ことを特徴とするコンピュータ組み込み装置。
3. 請求項２に記載のコンピュータ組み込み装置において、
   前記メッセージ処理部は、
   コマンドの入出力処理を行うコマンド処理部と、
   レスポンスの入出力処理を行うレスポンス処理部と、
   ノーティフィケーションの入出力処理を行うノーティフィケーションと、
   コマンド、レスポンスおよびノーティフィケーションの順序制御を行う順序制御部と
   を備えたことを特徴とするコンピュータ組み込み装置。
4. 請求項３に記載のコンピュータ組み込み装置において、
   前記コマンド処理部は、コマンドを入力し、タイプ別にコマンドをキューに格納し、前記順序制御部の制御に従ってキューからコマンドを取り出して出力し、
   前記レスポンス処理部は、レスポンスを入力し、タイプ別にレスポンスをキューに格納し、前記順序制御部の制御に従ってキューからレスポンスを取り出して出力し、
   前記ノーティフィケーション処理部は、ノーティフィケーションを入力し、タイプ別にノーティフィケーションをキューに格納し、前記順序制御部の制御に従ってキューからノーティフィケーションを取り出して出力し、
   前記順序制御部は、待ち合わせルール情報に基づいてコマンド、レスポンスおよびノーティフィケーションの順序制御を行う
   ことを特徴とするコンピュータ組み込み装置。
5. 請求項１乃至４のいずれか一項に記載のコンピュータ組み込み装置において、
   前記レイヤは、実装詳細を隠蔽し、実装詳細に影響されないインタフェースを外部に提供する
   ことを特徴とするコンピュータ組み込み装置。
6. コンピュータ組み込み装置を構成するコンピュータを、
   複数の階層に分かれ、上位に対して所定のサービスを提供する複数のレイヤ、
   前記レイヤのそれぞれに設けられ、該レイヤに入出力するメッセージの順序制御を行うメッセージ処理部
   として機能させるプログラム。

Images