米国特許情報 | 欧州特許情報 | 国際公開(PCT)情報 | Google の米国特許検索
 
     特許分類
A 農業
B 衣類
C 家具
D 医学
E スポ−ツ;娯楽
F 加工処理操作
G 机上付属具
H 装飾
I 車両
J 包装;運搬
L 化学;冶金
M 繊維;紙;印刷
N 固定構造物
O 機械工学
P 武器
Q 照明
R 測定; 光学
S 写真;映画
T 計算機;電気通信
U 核技術
V 電気素子
W 発電
X 楽器;音響


  ホーム -> 写真;映画 -> 株式会社リコー

発明の名称 フィードバック制御装置、画像形成装置、フィードバック制御方法、フィードバック制御プログラム、及び記録媒体
発行国 日本国特許庁(JP)
公報種別 公開特許公報(A)
公開番号 特開2007−17789(P2007−17789A)
公開日 平成19年1月25日(2007.1.25)
出願番号 特願2005−200512(P2005−200512)
出願日 平成17年7月8日(2005.7.8)
代理人 【識別番号】100084250
【弁理士】
【氏名又は名称】丸山 隆夫
発明者 斎藤 賢一
要約 課題
再利用性や保守性を向上させたフィードバック制御装置、画像形成装置、フィードバック制御方法、フィードバック制御プログラム、及び記録媒体を提供する。

解決手段
リクエストに応じたジョブの実行を指示する調節手段と、物理量の目標の値を保持する目標値保持手段と、物理量の現在の値を保持する現在値保持手段とを備えたことにより、物理量のフィードバック制御を行う部分すべてに適応することができ再利用性、保守性が向上する。
特許請求の範囲
【請求項1】
ユーザ操作によるジョブ処理依頼を受け付けた場合に、該ジョブ処理依頼に応答する物理量の現在値を目標値に一致させるリクエストにより該物理量を調節するフィードバック制御装置であって、
前記リクエストに応じたジョブの実行を指示する調節手段と、
前記物理量の目標の値を保持する目標値保持手段と、
前記物理量の現在の値を保持する現在値保持手段とを備えたことを特徴とするフィードバック制御装置。
【請求項2】
前記調節手段は、前記現在値保持手段と一対一に対応し、該現在値保持手段へのリンク情報を保持することを特徴とする請求項1に記載のフィードバック制御装置。
【請求項3】
前記調節手段は、前記目標値保持手段を木構造の子として管理することを特徴とする請求項1または2に記載のフィードバック制御装置。
【請求項4】
前記調節手段は、当該リクエスト手段に対応するジョブの実行状態を取得して保持することを特徴とする請求項1から3のいずれか1項に記載のフィードバック制御装置。
【請求項5】
前記目標値保持手段は、ユーザ操作によりジョブ処理依頼を受け付けた際に、当該ユーザ操作の種別に応じた調節手段を生成することを特徴とする請求項1から4のいずれか1項に記載のフィードバック制御装置。
【請求項6】
前記目標値保持手段は、受付可能なジョブ処理依頼の限界数と生成した調節手段の数とを有し、これらの数の差に基づいてジョブ処理依頼の受け付け可否判定処理を行うことを特徴とする請求項1から5のいずれか1項に記載のフィードバック制御装置。
【請求項7】
前記目標値保持手段は、前記ジョブ処理依頼の仕様を定めた要望仕様と、該要望仕様を満たすことができない場合に前記要望仕様の代替仕様として用いられる許容仕様とを有することを特徴とする請求項1から6のいずれか1項に記載のフィードバック制御装置。
【請求項8】
前記調節手段は、調節仕様を保持する調節仕様保持手段をさらに備えたことを特徴とする請求項1から7のいずれか1項に記載のフィードバック制御装置。
【請求項9】
ユーザ操作によるジョブ処理依頼を受け付けた場合に、トナー画像の記録用紙への加熱による定着を行う定着ユニットの温度の現在値を目標値に一致させる、前記ジョブ処理依頼に応答するリクエストにより前記温度を調節するフィードバック制御装置であって、
前記定着のモードの管理を行うモード管理手段と、
前記リクエストに応じた前記温度の調節を行う調節手段と、
前記調節手段の調節内容を規定する調節仕様を保持する調節仕様保持手段と、
前記温度を検出する温度検出手段と、
前記温度検出手段からの温度情報と前記調節仕様とに基づいて温度の制御を行う温度制御手段とを備えたことを特徴とするフィードバック制御装置。
【請求項10】
表示部、印刷部及び撮像部等のハードウェア資源と、該ハードウェア資源を用いた画像形成に係るジョブ実行を行う共通処理部とを有し、ユーザ操作による画像形成に係るジョブ処理依頼を受け付けた場合に、該ジョブ処理依頼に応答するジョブを前記共通処理部で実行すると共に、各ジョブ処理依頼をリクエストとして管理する画像形成装置であって、
前記リクエストに応じたジョブの実行を前記共通処理部の定着ユニットに対して温度調節を指示する温度調節手段と、
前記ジョブの実行を受け付けると共に管理するモード管理手段と、
前記温度の目標の値を保持する温度制御仕様保持手段と、
前記温度の現在の値を検出する温度センサと、
前記温度調節手段により温度制御されるヒーターコントローラと
を備えたことを特徴とする画像形成装置。
【請求項11】
前記調節手段は、前記目標値保持手段を木構造の子として管理することを特徴とする請求項10に記載の画像形成装置。
【請求項12】
前記目標値保持手段は、ユーザ操作によりジョブ処理依頼を受け付けた際に、当該ユーザ操作の種別に応じた温度調節手段を生成することを特徴とする請求項10または11に記載の画像形成装置。
【請求項13】
前記目標値保持手段は、受付可能なジョブ処理依頼の限界数と生成した温度調節手段の数とを有し、これらの数の差に基づいてジョブ処理依頼の受け付け可否判定処理を行うことを特徴とする請求項10から12のいずれか1項に記載の画像形成装置。
【請求項14】
前記目標値保持手段は、前記ジョブ処理依頼の仕様を定めた要望仕様と、該要望仕様を満たすことができない場合に前記要望仕様の代替仕様として用いられる許容仕様とを有することを特徴とする請求項10から13のいずれか1項に記載の画像形成装置。
【請求項15】
ユーザから受け付けたジョブ処理のリクエストに応じて、該ジョブ処理依頼に応答する物理量の現在値を目標値に一致させるフィードバック制御方法であって、
コンピュータは、
前記ユーザから受け付けたリクエストの詳細な仕様を表すユーザの要望データを自己の属性区画で保持する目標保持手段を、前記リクエストごとに生成する目標値保持手段生成ステップと、
前記目標値保持手段のリンク情報及びリクエストの受付が可能な限界数を自己の属性区画で保持し、現在値をフォルダ管理する現在値保持手段を生成する現在値保持手段生成ステップと
を実行し、
前記目標値保持手段は、
前記リクエストを受け付けたならば、自己の属性区画で所持している限界数データを読み出して、前記受け付けたリクエストが限界数を超えるか否かによりリクエストの投入可否の判定を行う判定ステップと、
前記判定ステップにより投入可能と判定した場合には、前記リクエストに応じたジョブの実行を指示することが可能な調節手段を生成する調節手段生成ステップと、
前記調節手段生成ステップにより生成した調節手段に対して、前記目標値保持手段のリンク情報を渡すことでリクエストの投入を行うリクエスト投入ステップと
をコンピュータに実行させ、
前記調節手段は、
前記渡されたリンク情報を自己の属性区画に保持することにより、自己と前記目標手段との関連付けを行うリクエスト仕様関連付けステップと、
前記リクエスト関連付けステップにより関連付けした目標値保持手段に対して、該目標値保持手段の属性区画で保持しているユーザの要望データの参照を要求する参照要求ステップと
をコンピュータに実行させ、
前記目標値保持手段は、
前記リクエスト手段の参照要求に基づいて、自己の属性区画で保持しているユーザの要望データを読み出して、前記調節手段に渡す参照ステップ
をコンピュータに実行させ、
前記調節手段は、
前記目標値保持手段から取得したユーザの要望データに従い、他のサブシステムに対してジョブ処理の開始を指示する指示ステップ
をコンピュータに実行させることを特徴とするフィードバック制御方法。
【請求項16】
前記調節手段は、前記指示ステップの実行前に、
自己の属性区画で保持しているユーザの調節仕様を保持する調節仕様保持手段を生成する調節仕様保持手段生成ステップ
をコンピュータに実行させることを特徴とする請求項10に記載のフィードバック制御方法。
【請求項17】
ユーザから受け付けたジョブ処理のリクエストに応じて、該ジョブ処理依頼に応答する物理量の現在値を目標値に一致させるためのフィードバック制御プログラムであって、
コンピュータは、
前記ユーザから受け付けたリクエストに基づいて生成され、前記リクエストの詳細な仕様を表すユーザの要望データを自己の属性区画で保持する目標保持手段と、
前記目標保持手段のリンク情報及びリクエストの受付が可能な限界数を自己の属性区画で保持し、現在値をフォルダ管理する現在値保持手段と
を有した状態で、
前記目標値保持手段は、
前記リクエストを受け付けたならば、自己の属性区画で所持している限界数データを読み出して、前記受け付けたリクエストが限界数を超えるか否かによりリクエストの投入可否の判定を行う判定ステップと、
前記判定ステップにより投入可能と判定した場合には、前記リクエストに応じたジョブの実行を指示することが可能な調節手段を生成する調節手段生成ステップと、
前記調節手段生成ステップにより生成した調節手段に対して、前記目標値保持手段のリンク情報を渡すことでリクエストの投入を行うリクエスト投入ステップと
をコンピュータに実行させ、
前記調節手段は、
前記渡されたリンク情報を自己の属性区画に保持することにより、自己と前記目標手段との関連付けを行うリクエスト仕様関連付けステップと、
前記リクエスト関連付けステップにより関連付けした目標値保持手段に対して、該目標値保持手段の属性区画で保持しているユーザの要望データの参照を要求する参照要求ステップと
をコンピュータに実行させ、
前記目標値保持手段は、
前記リクエスト手段の参照要求に基づいて、自己の属性区画で保持しているユーザの要望データを読み出して、前記調節手段に渡す参照ステップ
をコンピュータに実行させ、
前記調節手段は、
前記目標値保持手段から取得したユーザの要望データに従い、他のサブシステムに対してジョブ処理の開始を指示する指示ステップ
をコンピュータに実行させることを特徴とするフィードバック制御プログラム。
【請求項18】
前記調節手段は、前記指示ステップの実行前に、
自己の属性区画で保持しているユーザの調節仕様を保持する調節仕様保持手段を生成する調節仕様保持手段生成ステップ
をコンピュータに実行させることを特徴とする請求項17に記載のフィードバック制御プログラム。
【請求項19】
ユーザから受け付けたジョブ処理のリクエストに応じて、該ジョブ処理依頼に応答する物理量の現在値を目標値に一致させるためのフィードバック制御プログラムを記録した記録媒体であって、
コンピュータは、
前記ユーザから受け付けたリクエストに基づいて生成され、前記リクエストの詳細な仕様を表すユーザの要望データを自己の属性区画で保持する目標保持手段と、
前記目標保持手段のリンク情報及びリクエストの受付が可能な限界数を自己の属性区画で保持し、現在値をフォルダ管理する現在値保持手段と
を有した状態で、
前記目標値保持手段は、
前記リクエストを受け付けたならば、自己の属性区画で所持している限界数データを読み出して、前記受け付けたリクエストが限界数を超えるか否かによりリクエストの投入可否の判定を行う判定ステップと、
前記判定ステップにより投入可能と判定した場合には、前記リクエストに応じたジョブの実行を指示することが可能な調節手段を生成する調節手段生成ステップと、
前記調節手段生成ステップにより生成した調節手段に対して、前記目標値保持手段のリンク情報を渡すことでリクエストの投入を行うリクエスト投入ステップと
をコンピュータに実行させ、
前記調節手段は、
前記渡されたリンク情報を自己の属性区画に保持することにより、自己と前記目標手段との関連付けを行うリクエスト仕様関連付けステップと、
前記リクエスト関連付けステップにより関連付けした目標値保持手段に対して、該目標値保持手段の属性区画で保持しているユーザの要望データの参照を要求する参照要求ステップと
をコンピュータに実行させ、
前記目標値保持手段は、
前記リクエスト手段の参照要求に基づいて、自己の属性区画で保持しているユーザの要望データを読み出して、前記調節手段に渡す参照ステップ
をコンピュータに実行させ、
前記調節手段は、
前記目標値保持手段から取得したユーザの要望データに従い、他のサブシステムに対してジョブ処理の開始を指示する指示ステップ
をコンピュータに実行させるプログラムを記録したことを特徴とする記録媒体。
【請求項20】
前記調節手段は、前記指示ステップの実行前に、
自己の属性区画で保持しているユーザの調節仕様を保持する調節仕様保持手段を生成する調節仕様保持手段生成ステップ
をコンピュータに実行させるプログラムを記録したことを特徴とする請求項19に記載の記録媒体。
発明の詳細な説明
【技術分野】
【0001】
本発明は、フィードバック制御装置、画像形成装置、フィードバック制御方法、フィードバック制御プログラム、及び記録媒体に関する。
【背景技術】
【0002】
従来、プリンタ、コピーおよびスキャナなどの複数の機能を一つの筐体内に収納した複合機が知られている。かかる複合機では、UNIX(登録商標)などの汎用OS上に、プリンタアプリ、コピーアプリおよびスキャナアプリと呼ばれる複数のアプリケーションを搭載し、これらのアプリケーションの実行処理を切替えながら複数の機能を実現していた。
【0003】
ところが、上記プリンタアプリ、コピーアプリおよびスキャナアプリは、それぞれエンジン制御、メモリ制御およびシステム制御などを別個に行っているので、重複処理という無駄が生ずる。
【0004】
このため、特許文献1では、複合機に搭載される複数のアプリケーションがそれぞれ担っていたエンジン制御、メモリ制御およびシステム制御などの処理を共通処理部分(プラットホーム)として各アプリケーションから括り出すことにより、アプリケーションの開発効率の向上を図っている。
【特許文献1】特開2002−084383号公報
【発明の開示】
【発明が解決しようとする課題】
【0005】
しかしながら、かかる特許文献1によれば、ジョブの生成以降の処理を共通化しているものの、ジョブ処理依頼(以下「リクエスト」と言う)の管理などをそれぞれのアプリケーションで別個に行っているため、複合機上のアプリケーションのスリム化を図るうえで改善の余地がある。なお、「ジョブ」とは、成果物の作成が完了するまでの処理の実行単位をいい、複合機全体として入力の始まりから出力の終了までを示す。また、一連の原稿束の読み取り処理や、一連の印刷処理を指して「ジョブ」と呼ぶこともある。
【0006】
たとえば、複合機に搭載されるコピーアプリは、コピーのリクエストを受け付けたならば、このリクエストに対応するジョブの実行を共通処理部分(プラットホーム)に指示するとともに、かかるリクエストの管理を行うことになるが、プリンタアプリの場合にも同様のジョブ実行指示とリクエスト管理をおこなっている。
【0007】
このため、リクエストの一元管理を行うことが望まれるが、かかるリクエストは、一元的に管理可能なジョブが生成される前段階のものであるので、特許文献1の共通処理部分で対応するのは無理がある。このリクエストにジョブと同様の仕様制限を加えてしまうと、複合機が新規のリクエストに対応できなくなってしまうからである。
【0008】
これらのことから、複合機に搭載されるアプリケーションへのリクエストをいかにして効率良く一元管理するかが大きな課題となっている。なお、かかる課題は複合機についてのみ生じるものではなく、たとえば異種のジョブを実行する複数のサーバ機能を搭載した多機能サーバ装置を形成するような場合にも同様に生ずる課題である。
さらに、従来はソースコードを利用して制御を行っていたが、再利用性や保守性に問題があった。
【0009】
本発明は、上述した従来技術による問題点を解消するためになされたものであり、再利用性や保守性を向上させたフィードバック制御装置、画像形成装置、フィードバック制御方法、フィードバック制御プログラム、及び記録媒体を提供することにある。
【課題を解決するための手段】
【0010】
上記課題を解決するため、請求項1に記載の発明は、ユーザ操作によるジョブ処理依頼を受け付けた場合に、該ジョブ処理依頼に応答する物理量の現在値を目標値に一致させるリクエストにより該物理量を調節するフィードバック制御装置であって、前記リクエストに応じたジョブの実行を指示する調節手段と、前記物理量の目標の値を保持する目標値保持手段と、前記物理量の現在の値を保持する現在値保持手段とを備えたことを特徴とする。
【0011】
請求項1に記載の発明によれば、リクエストに応じたジョブの実行を指示する調節手段と、物理量の目標の値を保持する目標値保持手段と、物理量の現在の値を保持する現在値保持手段とを備えたことにより、物理量のフィードバック制御を行う部分すべてに適応することができ再利用性、保守性が向上する。
【0012】
請求項2に記載の発明は、請求項1に記載の発明において、前記調節手段は、前記現在値保持手段と一対一に対応し、該現在値保持手段へのリンク情報を保持することを特徴とする。
【0013】
請求項2に記載の発明によれば、調節手段は、現在値保持手段と一対一に対応し、現在値保持手段へのリンク情報を保持することにより、フィードバック制御において拡張部分をモデル化することができ、応用範囲が拡大する。
【0014】
請求項3に記載の発明は、請求項1または2に記載の発明において、前記調節手段は、前記目標値保持手段を木構造の子として管理することを特徴とする。
【0015】
請求項3に記載の発明によれば、調節手段は、目標値保持手段を木構造の子として管理することにより、複数の目標値に対応することができるので、さらに再利用性、保守性が向上する。
【0016】
請求項4に記載の発明は、請求項1から3のいずれか1項に記載の発明において、前記調節手段は、当該リクエスト手段に対応するジョブの実行状態を取得して保持することを特徴とする。
【0017】
請求項4に記載の発明によれば、調節手段は、リクエスト手段に対応するジョブの実行状態を取得して保持することにより、再利用及び保守を行う際の進捗状況が把握できるので、再利用及び保守の効率が向上する。
【0018】
請求項5に記載の発明は、請求項1から4のいずれか1項に記載の発明において、前記目標値保持手段は、ユーザ操作によりジョブ処理依頼を受け付けた際に、当該ユーザ操作の種別に応じた調節手段を生成することを特徴とする。
【0019】
請求項5に記載の発明によれば、目標値保持手段は、ユーザ操作によりジョブ処理依頼を受け付けた際に、ユーザ操作の種別に応じた調節手段を生成することにより、ユーザ操作ごとにきめ細かく調節が行われるので、再利用及び保守の効率が向上する。
【0020】
請求項6に記載の発明は、請求項1から5のいずれか1項に記載の発明において、前記目標値保持手段は、受付可能なジョブ処理依頼の限界数と生成した調節手段の数とを有し、これらの数の差に基づいてジョブ処理依頼の受け付け可否判定処理を行うことを特徴とする。
【0021】
請求項6に記載の発明によれば、目標値保持手段は、受付可能なジョブ処理依頼の限界数と生成した調節手段の数とを有し、これらの数の差に基づいてジョブ処理依頼の受け付け可否判定処理を行うことにより、処理の限界を把握することができるので、再利用及び保守の能率が向上する。
【0022】
請求項7に記載の発明は、請求項1から6のいずれか1項に記載の発明において、前記目標値保持手段は、前記ジョブ処理依頼の仕様を定めた要望仕様と、該要望仕様を満たすことができない場合に前記要望仕様の代替仕様として用いられる許容仕様とを有することを特徴とする。
【0023】
請求項7に記載の発明によれば、目標値保持手段は、ジョブ処理依頼の仕様を定めた要望仕様と、要望仕様を満たすことができない場合に要望仕様の代替仕様として用いられる許容仕様とを有するので、再利用する際の応用範囲が広がる。
【0024】
請求項8に記載の発明は、請求項1から7のいずれか1項に記載の発明において、前記調節手段は、調節仕様を保持する調節仕様保持手段をさらに備えたことを特徴とする。
【0025】
請求項8に記載の発明によれば、調節手段は、調節仕様を保持する調節仕様保持手段をさらに備えたことにより、調節仕様に応じたきめ細かな再利用及び保守を行うことができる。
【0026】
請求項9に記載の発明は、ユーザ操作によるジョブ処理依頼を受け付けた場合に、トナー画像の記録用紙への加熱による定着を行う定着ユニットの温度の現在値を目標値に一致させる、前記ジョブ処理依頼に応答するリクエストにより前記温度を調節するフィードバック制御装置であって、前記定着のモードの管理を行うモード管理手段と、前記リクエストに応じた前記温度の調節を行う調節手段と、前記調節手段の調節内容を規定する調節仕様を保持する調節仕様保持手段と、前記温度を検出する温度検出手段と、前記温度検出手段からの温度情報と前記調節仕様とに基づいて温度の制御を行う温度制御手段とを備えたことを特徴とする。
【0027】
請求項9に記載の発明によれば、定着のモードの管理を行うモード管理手段と、リクエストに応じた温度の調節を行う調節手段と、調節手段の調節内容を規定する調節仕様を保持する調節仕様保持手段と、温度を検出する温度検出手段と、温度検出手段からの温度情報と調節仕様とに基づいて温度の制御を行う温度制御手段とを備えたことにより、温度情報と調節仕様とに基づく定着制御における再利用性及び保守性が向上する。
【0028】
請求項10に記載の発明は、表示部、印刷部及び撮像部等のハードウェア資源と、該ハードウェア資源を用いた画像形成に係るジョブ実行を行う共通処理部とを有し、ユーザ操作による画像形成に係るジョブ処理依頼を受け付けた場合に、該ジョブ処理依頼に応答するジョブを前記共通処理部で実行すると共に、各ジョブ処理依頼をリクエストとして管理する画像形成装置であって、前記リクエストに応じたジョブの実行を前記共通処理部の定着ユニットに対して温度調節を指示する温度調節手段と、前記ジョブの実行を受け付けると共に管理するモード管理手段と、前記温度の目標の値を保持する温度制御仕様保持手段と、前記温度の現在の値を検出する温度センサと、前記温度調節手段により温度制御されるヒーターコントローラとを備えたことを特徴とする。
【0029】
請求項10に記載の発明によれば、リクエストに応じたジョブの実行を共通処理部の定着ユニットに対して温度調節を指示する温度調節手段と、ジョブの実行を受け付けると共に管理するモード管理手段と、温度の目標の値を保持する温度制御仕様保持手段と、温度の現在の値を検出する温度センサと、温度調節手段により温度制御されるヒーターコントローラとを備えたことにより、モードと検出温度と目標温度との関係が明らかになるので、定着制御における再利用性及び保守性が向上する。
【0030】
請求項11に記載の発明は、請求項10に記載の発明において、前記調節手段は、前記目標値保持手段を木構造の子として管理することを特徴とする。
【0031】
請求項11に記載の発明によれば、調節手段は、目標値保持手段を木構造の子として管理することにより、複数の目標値に対応することができるので、さらに再利用性、保守性が向上する。
【0032】
請求項12に記載の発明は、請求項10または11に記載の発明において、前記目標値保持手段は、ユーザ操作によりジョブ処理依頼を受け付けた際に、当該ユーザ操作の種別に応じた温度調節手段を生成することを特徴とする。
【0033】
請求項12に記載の発明によれば、目標値保持手段は、ユーザ操作によりジョブ処理依頼を受け付けた際に、ユーザ操作の種別に応じた温度調節手段を生成することにより、ユーザ操作に対応できるので、再利用及び保守の能率が向上する。
【0034】
請求項13に記載の発明は、請求項10から12のいずれか1項に記載の発明において、前記目標値保持手段は、受付可能なジョブ処理依頼の限界数と生成した温度調節手段の数とを有し、これらの数の差に基づいてジョブ処理依頼の受け付け可否判定処理を行うことを特徴とする。
【0035】
請求項13に記載の発明によれば、目標値保持手段は、受付可能なジョブ処理依頼の限界数と生成した温度調節手段の数とを有し、これらの数の差に基づいてジョブ処理依頼の受け付け可否判定処理を行うことにより、処理の限界を把握することができるので、再利用及び保守の能率が向上する。
【0036】
請求項14に記載の発明は、請求項10から13のいずれか1項に記載の発明において、前記目標値保持手段は、前記ジョブ処理依頼の仕様を定めた要望仕様と、該要望仕様を満たすことができない場合に前記要望仕様の代替仕様として用いられる許容仕様とを有することを特徴とする。
【0037】
請求項14に記載の発明によれば、目標値保持手段は、ジョブ処理依頼の仕様を定めた要望仕様と、要望仕様を満たすことができない場合に要望仕様の代替仕様として用いられる許容仕様とを有することにより、再利用する際の応用範囲が広がる。
【0038】
請求項15に記載の発明は、ユーザから受け付けたジョブ処理のリクエストに応じて、該ジョブ処理依頼に応答する物理量の現在値を目標値に一致させるフィードバック制御方法であって、コンピュータは、前記ユーザから受け付けたリクエストの詳細な仕様を表すユーザの要望データを自己の属性区画で保持する目標保持手段を、前記リクエストごとに生成する目標値保持手段生成ステップと、前記目標値保持手段のリンク情報及びリクエストの受付が可能な限界数を自己の属性区画で保持し、現在値をフォルダ管理する現在値保持手段を生成する現在値保持手段生成ステップとを実行し、前記目標値保持手段は、前記リクエストを受け付けたならば、自己の属性区画で所持している限界数データを読み出して、前記受け付けたリクエストが限界数を超えるか否かによりリクエストの投入可否の判定を行う判定ステップと、前記判定ステップにより投入可能と判定した場合には、前記リクエストに応じたジョブの実行を指示することが可能な調節手段を生成する調節手段生成ステップと、前記調節手段生成ステップにより生成した調節手段に対して、前記目標値保持手段のリンク情報を渡すことでリクエストの投入を行うリクエスト投入ステップとをコンピュータに実行させ、前記調節手段は、前記渡されたリンク情報を自己の属性区画に保持することにより、自己と前記目標手段との関連付けを行うリクエスト仕様関連付けステップと、前記リクエスト関連付けステップにより関連付けした目標値保持手段に対して、該目標値保持手段の属性区画で保持しているユーザの要望データの参照を要求する参照要求ステップとをコンピュータに実行させ、前記目標値保持手段は、前記リクエスト手段の参照要求に基づいて、自己の属性区画で保持しているユーザの要望データを読み出して、前記調節手段に渡す参照ステップをコンピュータに実行させ、前記調節手段は、前記目標値保持手段から取得したユーザの要望データに従い、他のサブシステムに対してジョブ処理の開始を指示する指示ステップをコンピュータに実行させることを特徴とする。
【0039】
請求項15に記載の発明によれば、リクエストに応じたジョブの実行を指示する調節手段と、物理量の目標の値を保持する目標値保持手段と、物理量の現在の値を保持する現在値保持手段とを備えたことにより、物理量のフィードバック制御を行う部分すべてに適応することができ再利用性、保守性が向上する。
【0040】
請求項16に記載の発明は、請求項10に記載の発明において、前記調節手段は、前記指示ステップの実行前に、自己の属性区画で保持しているユーザの調節仕様を保持する調節仕様保持手段を生成する調節仕様保持手段生成ステップをコンピュータに実行させることを特徴とする。
【0041】
請求項16に記載の発明によれば、調節手段は、調節仕様を保持する調節仕様保持手段ステップをさらに備えたことにより、調節仕様に応じたきめ細かな再利用及び保守を行うことができる。
【0042】
請求項17に記載の発明は、ユーザから受け付けたジョブ処理のリクエストに応じて、該ジョブ処理依頼に応答する物理量の現在値を目標値に一致させるためのフィードバック制御プログラムであって、コンピュータは、前記ユーザから受け付けたリクエストに基づいて生成され、前記リクエストの詳細な仕様を表すユーザの要望データを自己の属性区画で保持する目標保持手段と、前記目標保持手段のリンク情報及びリクエストの受付が可能な限界数を自己の属性区画で保持し、現在値をフォルダ管理する現在値保持手段とを有した状態で、前記目標値保持手段は、前記リクエストを受け付けたならば、自己の属性区画で所持している限界数データを読み出して、前記受け付けたリクエストが限界数を超えるか否かによりリクエストの投入可否の判定を行う判定ステップと、前記判定ステップにより投入可能と判定した場合には、前記リクエストに応じたジョブの実行を指示することが可能な調節手段を生成する調節手段生成ステップと、前記調節手段生成ステップにより生成した調節手段に対して、前記目標値保持手段のリンク情報を渡すことでリクエストの投入を行うリクエスト投入ステップとをコンピュータに実行させ、前記調節手段は、前記渡されたリンク情報を自己の属性区画に保持することにより、自己と前記目標手段との関連付けを行うリクエスト仕様関連付けステップと、前記リクエスト関連付けステップにより関連付けした目標値保持手段に対して、該目標値保持手段の属性区画で保持しているユーザの要望データの参照を要求する参照要求ステップとをコンピュータに実行させ、前記目標値保持手段は、前記リクエスト手段の参照要求に基づいて、自己の属性区画で保持しているユーザの要望データを読み出して、前記調節手段に渡す参照ステップをコンピュータに実行させ、前記調節手段は、前記目標値保持手段から取得したユーザの要望データに従い、他のサブシステムに対してジョブ処理の開始を指示する指示ステップをコンピュータに実行させることを特徴とする。
【0043】
請求項17に記載の発明によれば、リクエストに応じたジョブの実行を指示する調節手段と、物理量の目標の値を保持する目標値保持手段と、物理量の現在の値を保持する現在値保持手段とを備えたことにより、物理量のフィードバック制御を行う部分すべてに適応することができ再利用性、保守性が向上する。
【0044】
請求項18に記載の発明は、請求項17に記載の発明において、前記調節手段は、前記指示ステップの実行前に、自己の属性区画で保持しているユーザの調節仕様を保持する調節仕様保持手段を生成する調節仕様保持手段生成ステップをコンピュータに実行させることを特徴とする。
【0045】
請求項18に記載の発明によれば、調節手段は、調節仕様を保持する調節仕様保持手段ステップをさらに備えたことにより、調節仕様に応じたきめ細かな再利用及び保守を行うことができる。
【0046】
請求項19に記載の発明は、ユーザから受け付けたジョブ処理のリクエストに応じて、該ジョブ処理依頼に応答する物理量の現在値を目標値に一致させるためのフィードバック制御プログラムを記録した記録媒体であって、コンピュータは、前記ユーザから受け付けたリクエストに基づいて生成され、前記リクエストの詳細な仕様を表すユーザの要望データを自己の属性区画で保持する目標保持手段と、前記目標保持手段のリンク情報及びリクエストの受付が可能な限界数を自己の属性区画で保持し、現在値をフォルダ管理する現在値保持手段とを有した状態で、前記目標値保持手段は、前記リクエストを受け付けたならば、自己の属性区画で所持している限界数データを読み出して、前記受け付けたリクエストが限界数を超えるか否かによりリクエストの投入可否の判定を行う判定ステップと、前記判定ステップにより投入可能と判定した場合には、前記リクエストに応じたジョブの実行を指示することが可能な調節手段を生成する調節手段生成ステップと、前記調節手段生成ステップにより生成した調節手段に対して、前記目標値保持手段のリンク情報を渡すことでリクエストの投入を行うリクエスト投入ステップとをコンピュータに実行させ、前記調節手段は、前記渡されたリンク情報を自己の属性区画に保持することにより、自己と前記目標手段との関連付けを行うリクエスト仕様関連付けステップと、前記リクエスト関連付けステップにより関連付けした目標値保持手段に対して、該目標値保持手段の属性区画で保持しているユーザの要望データの参照を要求する参照要求ステップとをコンピュータに実行させ、前記目標値保持手段は、前記リクエスト手段の参照要求に基づいて、自己の属性区画で保持しているユーザの要望データを読み出して、前記調節手段に渡す参照ステップをコンピュータに実行させ、前記調節手段は、前記目標値保持手段から取得したユーザの要望データに従い、他のサブシステムに対してジョブ処理の開始を指示する指示ステップをコンピュータに実行させるプログラムを記録したことを特徴とする。
【0047】
請求項19に記載の発明によれば、リクエストに応じたジョブの実行を指示する調節手段と、物理量の目標の値を保持する目標値保持手段と、物理量の現在の値を保持する現在値保持手段とを備えたことにより、物理量のフィードバック制御を行う部分すべてに適応することができ再利用性、保守性が向上する。
【0048】
請求項20に記載の発明は、請求項19に記載の発明において、前記調節手段は、前記指示ステップの実行前に、自己の属性区画で保持しているユーザの調節仕様を保持する調節仕様保持手段を生成する調節仕様保持手段生成ステップをコンピュータに実行させるプログラムを記録したことを特徴とする。
【0049】
請求項20に記載の発明によれば、調節手段は、調節仕様を保持する調節仕様保持手段生成ステップをさらに備えたことにより、調節仕様に応じたきめ細かな再利用及び保守を行うことができる。
【発明の効果】
【0050】
本発明によれば、リクエストに応じたジョブの実行を指示する調節手段と、物理量の目標の値を保持する目標値保持手段と、物理量の現在の値を保持する現在値保持手段とを備えたことにより、物理量のフィードバック制御を行う部分すべてに適応することができ再利用性、保守性が向上する。
【発明を実施するための最良の形態】
【0051】
以下に添付図面を参照して、この発明にかかるフィードバック制御装置の最良な実施の形態を詳細に説明する。なお、本実施の形態では、この発明を画像形成装置に適用した場合について説明するが、本発明はこれに限らず、フィードバック制御を行う各種装置やフィードバック制御プログラムやフィードバック制御プログラムを記録した記録媒体に適用することができる。
【0052】
まず、本実施の形態に係る画像形成装置(以下「複合機」と言う)1の概念について図1、図2、図3、図13および図14を用いて説明する。図1は、本実施の形態に係る複合機1を取り巻くネットワーク環境を説明するためのネットワーク図であり、図2は、図1に示した複合機1のハードウェア構成を示すブロック図であり、図3は、図1に示した複合機1のソフトウェアとハードウェアの関係を説明するための説明図であり、図13は、複合機1に搭載されるソフトウェア構成の変遷を説明するための説明図であり、図14は、従来の複合機のソフトウェアとハードウェアの関係を説明するための説明図である。
【0053】
図1に示すように、近年のネットワーク化の進展により、オフィスなどに設けられたパーソナルコンピュータ(PC)などの機器は、LAN(Local Area Network)などのネットワークに接続され、相互に通信することができる。たとえば、同図に示したように、LANなどのネットワークには、クライアントPC、SMTP(Simple Mail Transfer Protocol)サーバ、FTP(File Transfer Protocol)サーバ、サーバPCなどが接続され、電子メールの送受信やファイル転送をすることができ、モデム接続された配信サーバは、オフィス外のファックス装置と通信することができる。
【0054】
このようなネットワーク化の進展に伴い、複合機1についてもネットワークに接続され、PC等の機器と相互に通信することが可能となり、ハードディスク等の記憶装置を内蔵することで、いわゆるネットワーク複合機へと進化し、ユーザの様々なニーズに応えることができるようになった。
【0055】
具体的には、複合機1は、通常のコピー機能に加えて、クライアントPCからの印刷要求により文書データ等を印刷するプリンタ機能、クライアントPCからのファックス要求により文書データ等をサーバPCに接続されたモデムを経由して他のオフィスのファックス機器に送信するファックス機能、受信したファックス文書やコピー文書を内蔵したハードディスクに蓄積する蓄積機能などを有するようになった。このような多くの機能を実現するために、複合機1に搭載されるソフトウェアは規模が大きくなり、また、複雑なものとなってきた。
【0056】
図2は、かかる複合機1のハードウェア構成を示すブロック図である。同図に示すように、この複合機1は、コントローラ10とエンジン部(Engine)60とをPCI(Peripheral Component Interconnect)バスで接続した構成となる。コントローラ10は、複合機1全体の制御と描画、通信、図示しない操作部からの入力を制御するコントローラである。エンジン部60は、PCIバスに接続可能なプリンタエンジンなどであり、たとえば白黒プロッタ、1ドラムカラープロッタ、4ドラムカラープロッタ、スキャナまたはファックスユニットなどである。なお、このエンジン部60には、プロッタなどのいわゆるエンジン部分に加えて、誤差拡散やガンマ変換などの画像処理部分が含まれる。
【0057】
コントローラ10は、CPU11と、ノースブリッジ(NB)13と、システムメモリ(MEM−P)12と、サウスブリッジ(SB)14と、ローカルメモリ(MEM−C)17と、ASIC(Application Specific Integrated Circuit)16と、ハードディスクドライブ(HDD)18とを有し、ノースブリッジ(NB)13とASIC16との間をAGP(Accelerated Graphics Port)バス15で接続した構成となる。また、MEM−P12は、ROM(Read Only Memory)12aと、RAM(Random Access Memory)とをさらに有する。
【0058】
CPU11は、複合機1の全体制御を行うものであり、NB13、MEM−P12
およびSB14からなるチップセットを有し、このチップセットを介して他の機器と接続される。
【0059】
NB13は、CPU11とMEM−P12、SB14、AGP15とを接続するためのブリッジであり、MEM−P12に対する読み書きなどを制御するメモリコントローラと、PCIマスタおよびAGPターゲットとを有する。
【0060】
MEM−P12は、プログラムやデータの格納用メモリ、プログラムやデータの展開用メモリ、プリンタの描画用メモリなどとして用いるシステムメモリであり、ROM12aとRAM12bとからなる。ROM12aは、プログラムやデータの格納用メモリとして用いる読み出し専用のメモリであり、RAM12bは、プログラムやデータの展開用メモリ、プリンタの描画用メモリなどとして用いる書き込みおよび読み出し可能なメモリである。
【0061】
SB14は、NB13とPCIデバイス、周辺デバイスとを接続するためのブリッジである。このSB14は、PCIバスを介してNB13と接続されており、このPCIバスには、ネットワークインターフェース(I/F)部なども接続される。
【0062】
ASIC16は、画像処理用のハードウェア要素を有する画像処理用途向けのIC(Integrated Circuit)であり、AGP15、PCIバス、HDD18およびMEM−C17をそれぞれ接続するブリッジの役割を有する。このASIC16は、PCIターゲットおよびAGPマスタと、ASIC16の中核をなすアービタ(ARB)と、MEM−C17を制御するメモリコントローラと、ハードウェアロジックなどにより画像データの回転などを行う複数のDMAC(Direct Memory Access Controller)と、エンジン部60との間でPCIバスを介したデータ転送を行うPCIユニットとからなる。このASIC16には、PCIバスを介してFCU(Fax Control Unit)30、USB(Universal Serial Bus)40、IEEE1394(the Institute of Electrical and Electronics Engineers 1394)インターフェース50が接続される。
【0063】
MEM−C17は、コピー用画像バッファ、符号バッファとして用いるローカルメモリであり、HDD(Hard Disk Drive)18は、画像データの蓄積、プログラムの蓄積、フォントデータの蓄積、フォームの蓄積を行うためのストレージである。
【0064】
AGP15は、グラフィック処理を高速化するために提案されたグラフィックスアクセラレーターカード用のバスインターフェースであり、MEM−P12に高スループットで直接アクセスすることにより、グラフィックスアクセラレーターカードを高速にするものである。
【0065】
図3は、かかる複合機1のハードウェアおよびソフトウェアの構成を示した概念図であり、具体的には、後述する本実施形態の特徴部分であるリクエスト管理部113aを含む統合アプリケーション110と、ソフトウェア100およびハードウェア200の階層関係を示している。同図に示すように、ハードウェア200は、ハードウェアリソース201を有し、このハードウェアリソース201は、スキャナ201a、プロッタ201b、HDD(Hard Disk Drive)201c、ネットワーク201dおよびその他のリソース201eを有する。なお、その他のリソース201eは、201a〜201d以外のハードウェアリソース201のことであり、たとえば、操作パネルなどの入出力デバイスを示す。
【0066】
また、かかるハードウェア200に搭載されるソフトウェア100は階層化されており、オペレーティングシステム103の上層にはサービス層102が構築され、このサービス層102の上層にはアプリケーション層103が構築されている。そして、サービス層102は、各ハードウェアリソース(201a〜201e)を制御するドライバーに相当する、スキャナ制御102部a、プロッタ制御部102b、蓄積制御部102c、配信/メール送受信制御部102d、FAX送受信制御部102e、ネットワーク通信制御部102fおよびその他の制御部102gを有する。
【0067】
ここで、図3に示したソフトウェア100が、かかる階層構造をとるに至った経緯について、図13および図14を用いて説明する。図13は、複合機1に搭載されるソフトウェア構成の変遷を示す説明図である。図13のサービス層分離前アプリケーション501に示すように、多機能化した複合機1に搭載されるソフトウェアは、コピーアプリケーション、FAXアプリケーション、スキャナアプリケーションなどの機能別に独立したアプリケーションとして作成され、図3に示したオペレーティングシステム103上で動作していた。
【0068】
しかしながら、これらのアプリケーションは、ハードウェアリソースを制御するドライバー(サービス層102)を含んでいたため、各アプリケーションには重複した処理が存在していた。その結果、各アプリケーションの規模は大きなものとなっていた。
【0069】
そこで、図13のサービス層分離後アプリケーション502に示すように、サービス層分離前アプリケーション501のサービス層102相当部分を括りだしサービス層102とするとともに、各アプリケーションは、このサービス層102の上層であるアプリケーション層101に構築する構成とした。かかる階層化構成をとることにより、各アプリケーションはスリム化され開発労力も軽減された。
【0070】
しかしながら、複合機1のネットワーク化、多機能化がさらに進展するに従って、各アプリケーションに共通処理部分が存在することが問題となってきた。具体的には、アプリケーション層101の各アプリケーション、たとえば、コピーアプリケーションやスキャナアプリケーションなどは、それぞれ、スキャナ制御部102aや蓄積制御部102c等のドライバーと通信を行う処理や、リクエスト受付やリクエスト実行等のジョブ管理処理などの同様な処理を内部に有していた。このように、同様な処理を各アプリケーションが有していると、各アプリケーションの開発規模が大きくなるとともに、サービス層の仕様変更に対する各アプリケーションの改修規模が大きくなることが問題となってきた。
【0071】
この問題を解決するため、図13の共通ルーチン分離アプリケーション503に示すように、かかる同様な処理(共通処理部分)を共通ルーチンとして括りだすことも考えられた。
しかしながら、かかる共通ルーチンは、各アプリケーションにおいて微妙に異なる処理を共通化しようとするものであるため、共通ルーチン内部の処理は複雑なものとなってしまう。また、たとえば、プリンタアプリケーションなどの新規アプリケーションを追加する場合においては、かかる新規アプリケーションに適応するために、共通ルーチンの改修が必要となる。
【0072】
しかし、共通ルーチンの内部処理は複雑であるため、改修要員が処理を把握することが困難となり、改修規模の増大や、改修ミスによる他のアプリケーションへの影響が懸念された。
【0073】
そこで、図13のオブジェクト指向アプリケーション504に示すように、オブジェクト指向による設計手法(オブジェクトモデリング)により、かかる複数のアプリケーションを、統合アプリケーション110に統合することとした。具体的には、各アプリケーションの共通処理部分をオブジェクトモデルとして抽出し、このオブジェクトモデルの集合体から、統合アプリケーション110を構成する。そして、従来のコピー機能やスキャナ機能等の機能は、かかるオブジェクトモデルの協調関係によって実現する。
【0074】
このような構成をとることにより、たとえばプリンタ機能のような新規機能の追加は、
かかるオブジェクトモデルに属するクラスのサブクラス化などにより対処できる。このため、改修部分が明確となり、改修による他の機能への影響を小さくすることができる。また、オブジェクトモデリングによるプログラムは、従来の手続き型プログラムに比べて、処理の把握が容易であるため、改修要員が処理を把握することも容易となり、改修規模の削減や、改修ミスによる他のアプリケーションへの影響を小さくすることができる。
【0075】
図14は、図13に示したサービス層分離後アプリケーション502の段階における従来のアプリケーションの構成と、かかるアプリケーションとサービス層102の各ドライバーの関係を示した説明図である。図14に示すように、アプリケーション層101は、コピーアプリケーション120、スキャナアプリケーション130、ファックスアプリケーション140およびプリンタアプリケーション150を有する。
【0076】
たとえば、コピーアプリケーション120は、コピー機能を実現するために、スキャナ制御部102a、プロッタ制御部102b、蓄積制御部102cおよびその他の制御部102gとの間でデータの送受信を行う。また、ファックスアプリケーション140は、ファックス機能を実現するために、プロッタ制御部102b、蓄積制御部102c、FAX送受信制御部102e、ネットワーク通信制御部102fおよびその他の制御部102gとの間でデータの送受信を行う。このように、アプリケーション層101の各アプリケーションとサービス層102の各ドライバーとの間の通信は、複雑なものとなっていた。
【0077】
図3の説明に戻ると、上述したオブジェクトモデリングにより、アプリケーション層101に存在した複数のアプリケーションは、統合アプリケーション110に統合されている。そして、各アプリケーションが重複して行っていた各ドライバーとの通信処理は、統合アプリケーション110を構成する所定のオブジェクトモデルに行わせるように構成したことにより、アプリケーション層101のアプリケーションと、サービス層102の各ドライバーとの間の通信は、図14と比較して単純になっている。
【0078】
次に、統合アプリケーション110の内部構成について説明する。
図4は、後述する本実施形態の特徴部分であるリクエスト管理部の統合アプリケーション110における位置づけと、かかる統合アプリケーション110の概要構成を説明するための説明図である。
【0079】
同図に示すように、統合アプリケーション110は、図4は、後述する本実施形態の特徴部分であるリクエスト管理部113aの統合アプリケーション110における位置づけと、かかる統合アプリケーション110の概要構成を説明するための説明図である。
【0080】
同図に示すように、統合アプリケーション110は、操作系サブシステム111と、管理系サブシステム112および実行系サブシステム113とを有する。操作系サブシステム111は、マンマシンインタフェースを担当するソフトウェア群である。具体的には、この操作系サブシステム111は、ユーザの要求の受付サービスを行うとともに、かかる要求に対応した成果物(たとえば、コピーした記録紙)の品質、コストおよび納期を考慮したうえで、ユーザに対して情報提供サービスを行う。
【0081】
管理系サブシステム112は、複合機1の資源を管理するソフトウェア群である。具体的には、この管理系サブシステム112は、ハードウェアリソース201およびこのハードウェアリソース201が保持するデータ状態の管理サービスを行う。
【0082】
実行系サブシステム113は、ユーザ要求の実行を担当するソフトウェア群である。具体的には、この実行系サブシステム113は、コピーなどの文書操作要求から成果物の出力までの実行サービスを行う。そして、操作系サブシステム111、管理系サブシステム112および実行系サブシステム113は、必要に応じて相互に処理を依頼し結果を受けとることで、統合アプリケーション110全体として複合機1に必要とされるサービス提供を行う。
【0083】
かかる実行系サブシステム113は、後述する本実施形態の特徴部分であるリクエスト管理部113aと実行制御部113bとを有する。リクエスト管理部113aは、いわゆるジョブ管理を行うソフトウェア群である。具体的には、ユーザの要求をリクエストとして受け付け、このリクエストを実行するとともに、かかるリクエストの実行状態を管理する。
【0084】
また、実行制御部113bは、実行系サブシステム113からリクエスト管理部113aを除いた、その他の実行制御を行うソフトウェア群である。なお、図4#4において、リクエスト管理部113aが、操作系サブシステム111の近くに配置されているのは、ユーザのリクエストを管理するリクエスト管理部113aが、マンマシンインタフェースを担当する操作系サブシステム111と密接な関係を有することを示している。
【0085】
図5は、図4に示した各サブシステムを、UML(Unified Modeling Language)のクラス図(UMLクラス図)に置換えた図である。ここで、UMLとは、OMG(Object Management Group)という団体がまとめたシステムモデリング言語であり、システムモデリングの成果を記述する記法を定義したものである。そして、このUMLは、オブジェクト指向によるソフトウェア開発において、一般的に用いられている。
【0086】
図5に示すように、統合アプリケーション110は複数のパッケージを含み、この統合アプリケーション110自体もパッケージととらえることができる。ここで、パッケージとはUMLモデルの各構成要素(シンボル)をグループ化したものであり、このパッケージは、左上にタブのついたフォルダ型のシンボルで表現する。なお、かかるパッケージは、上述したオブジェクトモデルあるいはオブジェクトモデルの集合体ととらえることもできる。
【0087】
図5に示したように、統合アプリケーション110は、操作系サブシステム111、管理系サブシステム112および実行系サブシステム113の3つのパッケージを内部に有するパッケージである。さらに、実行系サブシステム113は、リクエスト管理部113aおよび実行制御部113bの2つのパッケージを内部に有するパッケージである。そして、操作系サブシステム111、管理系サブシステム112および実行系サブシステム113を相互に結ぶ直線は、各パッケージ間にメッセージ送受信などの関連があることを示している。なお、操作系サブシステム111、管理系サブシステム112および実行系サブシステム113のタブの右端に記された記号は、かかるパッケージがサブシステムであることを示すUMLのシンボルである。
【0088】
次に、本実施形態の特徴部分であるリクエスト管理部113aについて詳細に説明する。このリクエスト管理部113aは、ユーザから受け付けたジョブの実行依頼を管理するとともに、かかる実行依頼に応じて、実行制御部113bにジョブの実行指示をおこない、実行指示を行ったジョブの進捗管理を行うことを責務とする。
【0089】
図6(a)は、「ディレクトリ−ファイル」モデルを説明するための説明図であり、図6(b)は、リクエスト管理部のモデリングの概要を説明するための説明図である。図6(a)に示すように、いわゆる「ディレクトリ−ファイル」モデルは、UNIX(登録商標)やWINDOWS(登録商標)等のオペレーティングシステム(OS)において、ファイル管理モデルとして一般的に使用されているモデルである。
【0090】
この「ディレクトリ−ファイル」モデルは、複数のファイルを管理するディレクトリと、かかるディレクトリの管理下にあるファイルとを有し、ディレクトリおよびファイルは、それぞれディレクトリおよびファイルの詳細情報であるプロパティを有している。この「ディレクトリ−ファイル」モデルを採用することにより、かかるOSは、ファイルの作成、コピー、移動、削除および一覧表示等のファイル管理を実現している。
【0091】
このように、従来から用いられている「ディレクトリ−ファイル」モデルの類推(アナロジー)により、かかるリクエスト管理部113aのモデリングを行うことで、安定
したリクエスト管理モデルを実現できることが予想される。
【0092】
そこで、図6(b)に示すように、リクエスト管理部113aは、複数のリクエストを管理するリクエストフォルダと、かかるリクエストフォルダの管理下にあるリクエストとを有し、リクエストはリクエストの詳細情報であるリクエスト仕様を有する構成をとることとした。なお、「ディレクトリ−ファイル」モデルは、一般的に、ディレクトリ配下にディレクトリを階層的に有する階層構造をとるが、リクエスト管理部113aはかかる階層構造をとらない構成とした。しかしながら、リクエスト管理部113aはかかる階層構造をとる構成とすることもできる。
【0093】
このように、「ディレクトリ−ファイル」モデルのアナロジーとして構成したリクエスト管理部113aのクラス構成を、UMLのクラス図(UMLクラス図)により表現したものを図7に示す。
ここで、クラスとは、オブジェクト指向システムを構成するオブジェクトの設計図に相当する概念であり、このクラスは、データと処理を一体化(カプセル化)して内部に有するとともに、継承関係や集約関係等の他のクラスとの静的な関係を有する。そして、クラス図においては、各クラスが内部に有するデータおよび処理、複数のクラス間の静的な関係が表される。
【0094】
次に、本実施形態の特徴部分であるリクエスト管理部113aのクラス構成について説明する。
一般に、各クラスを示す矩形は3段の区画を有し、上から、クラス名を表す名前区画、クラスが有するデータ(属性)を示す属性クラス及びクラスが有する処理(操作)を示す操作区画と呼ばれる。
このように、各クラスは、データ(属性)を所持するための属性区画と、かかる属性の書き込みおよび読み出しを行う処理(操作)を所持するための操作区画とを有している。これらのクラスは、プログラム(統合アプリケーション110)の一部として含まれるので、あらかじめROM12aに格納されたこのプログラムが実行されると、各クラスはRAM12bの所定領域に実体化され、属性区画に含まれる各データ(属性)がRAM12b上に展開される。
したがって、クラスを実体化したオブジェクトは、RAM12b上の各データ(属性)の書き込みおよび読み出しをすることが可能となる。
【0095】
図7において、定着ユニットクラス700は、図示しない記録用紙に定着を行うユニットである。具体的には定着ユニットクラス700は、属性として、定着ユニット番号integer700aを有するが、操作は有さない。なお、かかる定着ユニットクラス700を実体化したオブジェクトが生成されると、定着ユニット番号integer700aがRAM12b上に展開されるので、このデータ(属性)の書込及び読み出しをすることが可能となる。
【0096】
モード管理部クラス701は、モードを管理するユニットである。モードにはリロードモード(直前に実行したプログラムを再度実行する)、プリントモード、待機モード、停止モードがある。具体的にはモード管理部クラス701は、属性として、現在のモード名string701aで指定されたモードstringを有するが、操作は有さない。なお、かかるモード管理部クラス701を実体化したオブジェクトが生成されると、現在のモード名string701aがRAM12b上に展開されるので、このデータ(属性)の書込及び読み出しをすることが可能となる。温度調節部による温度調節が実行される場面において、モード管理部クラス701を実体化したオブジェクトと定着ユニットクラス700を実体化したオブジェクトとは1対1の関係で存在する(R1)。
【0097】
温度調節部クラス702は、温度を調節するユニットである。具体的には温度調節部クラス702は、属性として、調節部番号integer702aを有するが、操作は有さない。温度調節部クラス702が実行される場面において、モード管理部クラスを701実体化したオブジェクト1個に対し、1個以上の温度調節部クラス702を実体化したオブジェクトが存在する(R9)。
【0098】
温度制御仕様クラス703は、温度制御仕様を規定するユニットである。具体的には温度制御仕様クラス703は、属性として、適用定着モード名string703aと目標温度integer703bとを有するが、操作は有しない。温度調節が実行される場面において、温度調節部クラス702を実体化したオブジェクトと温度制御仕様クラス703を実体化したオブジェクトとの関係R10、R11については以下のようになる。
温度調節部クラス702から見ると、「温度調節部クラス702は、1つの温度制御仕様を現在の温度仕様とする」ことになり(R10)、温度制御仕様クラス703から見ると「温度調節部クラス702にとって、1つ以上の全ての温度制御仕様は全ての温度仕様である」ことになる(R11)。
【0099】
ヒーターコントローラクラス704は、定着ユニットクラス700に用いられるヒータを管理するユニットである。具体的にはヒーターコントローラクラス704は、属性として、ヒータ番号integer704aを有するが、操作は有しない。温度調節が実行される場面において、温度調節部クラス702を実体化したオブジェクト1個に対し、1個以上のヒーターコントローラクラス704を実体化したオブジェクトが存在する。
【0100】
温度センサクラス705は、定着ユニットクラス700の温度を検出するユニットである。具体的には温度センサクラス705は、属性として、センサ番号integer705aと現在の温度integer705bとを有するが、操作は有しない。温度調節が実行される場面において温度調節部クラス702を実体化したオブジェクトと温度センサクラス705を実体化したオブジェクトとは1対1以上の関係で存在する。
【0101】
本実施の形態によれば、温度制御をオブジェクト指向(UML)でモデル化することにより、再利用性や保守性が向上する。
【0102】
次に、図7に示したクラス図における各クラスを実体化したオブジェクトの動作の概要について、図8、9を用いて説明する。
図8は、複合機1の操作パネル400の一例を示した図である。同図に示したように、かかる操作パネル400は、初期設定キー401、コピーキー402、コピーサーバーキー403、プリンタキー404、送信キー405、テンキー406、クリア/ストップキー407、スタートキー408、予熱キー409、リセットキー410および液晶タッチパネル420を有する。
【0103】
初期設定キー401をタッチすると、液晶タッチパネル420に初期設定用のメニューが表示され、かかるメニューにおいては、収納される用紙サイズなどを設定することができる。また、コピーをしたい場合にはコピーキー402を、コピー結果を複合機1に蓄積したい場合にはコピーサーバーキー403を、プリンタに係る操作をおこないたい場合には、プリンタキー404を、ファックスや蓄積画像などの送信をしたい場合には送信キー405を、それぞれタッチすると、液晶タッチパネル420に対応したメニューが表示される。
【0104】
図9は、図8に示したコピーサーバーキー403をタッチすると、液晶タッチパネル420に表示されるメニューの一例である。図9に示すように、この液晶タッチパネル420には、原稿読み取りボタン421、リストから削除ボタン422、印刷条件ボタン423などのボタンと、蓄積文書の一覧が表示される。
【0105】
そして、原稿を蓄積したい場合には、原稿を所定の場所にセットしたうえで、原稿読み取りボタン421をタッチする。また、蓄積文書を削除したい場合には、たとえば、ユーザIDがDEFの蓄積文書425をタッチし、かかる蓄積文書の表示を反転させたうえで、リストから削除ボタン422をタッチする。また、蓄積文書の印刷条件を変更したい場合には、たとえば、ユーザIDがABCの蓄積文書425をタッチし、かかる蓄積文書の表示を反転させたうえで、印刷条件ボタン423をタッチすると印刷条件メニューが表示される。
【0106】
かかるメニューにおいて印刷条件を変更することで、選択した蓄積文書425の印刷条件を変更することができる。なお、蓄積文書の数が多く表示エリア内に操作対象となる文書が表示されていない場合には、前へボタンおよび後へボタンをタッチすることで、操作対象となる文書を表示することができる。
【0107】
次に、本実施形態の特徴部分であるリクエスト管理部113aの機能追加の容易性について説明する。図10は、統合アプリケーション110に、プリンタ機能などの新規機能を追加する場合の概念を説明するための説明図である。
【0108】
同図に示すように、統合アプリケーション110は、楕円形で示したオブジェクトモデルの集合体として構成されており、各オブジェクトモデルは、統合アプリケーション110を構成する役割に相当する。この統合アプリケーション110に、プリンタ機能などの新規機能を追加する場合においては、まず、追加するプリンタ機能を、統合アプリケーション110を構成する各オブジェクトモデルに適合するよう分離する。そして、かかる分離部分を各オブジェクトモデルに反映させる。
【0109】
同図に示したサブクラス化によるクラス追加は、かかる反映方法の1つである。ここで、サブクラス化とは、上位クラスの属性および操作を継承して下位クラスを設計する手法であり、オブジェクト指向によるソフトウェア開発の利点の1つである。
【0110】
図11は本発明にかかるフィードバック制御の他の実施の形態におけるリクエスト管理部のクラス構成を、UMLのクラス図により表現したものである。
図11に示したクラス構成は、図7に示したクラス構成を一般化したものである。
同図に示す目標クラス1100は、温度、湿度、距離、高さ、長さ、速度、加速度、角度、角速度、角加速度、電圧、電流、電力、圧力、流量等の物理量の目標値を設定するユニットである。具体的には目標クラス1100は、属性として、目標値1100aを有するが、操作は有さない。
現在クラス1102は、物理量の現在の状態を把握するユニットである。具体的には現在クラス1102は、属性として、現在値1102aを有するが、操作は有さない。
調節クラス1101は、目標クラス1100の目標値1100aと現在クラス1102の現在値1102aとを参照して調節対象を調節するユニットである。
調節クラス1101は、属性として、調節ID1101aを有するが、操作は有さない。
調節クラス1101が実行される場面において、目標クラス1100を実体化したオブジェクトと、調節クラス1100を実体化したオブジェクトとは以下の関係がある。
調節クラス1101から見ると、「調節クラス1101は、1つの目標値を現在値とする」ことになり、目標クラス1100から見ると、「目標クラス1100は、調節クラス1101に現在値とされるものは1つであるが、されないものもある」ことになる。
調節クラス1101が実行される場面において、調節クラス1100を実体化したオブジェクト1個に対し現在クラス1102を実体化したオブジェクトが1個存在する。
このようにクラス構成を用いてモデル化することによりフィードバック制御を定着制御に限らず、フィードバック制御を行う部分全てに適用することができる。
【0111】
図12は本発明にかかるフィードバック制御のさらに他の実施の形態におけるリクエスト管理部のクラス構成を、UMLのクラス図により表現したものである。
図12に示したクラス構成と図11に示したクラス構成との相違点は調節仕様クラスを用いた点である。
すなわち、図12において、目標クラス1100は、温度、湿度、距離、高さ、長さ、速度、加速度、角度、角速度、角加速度、電圧、電流、電力、圧力等の物理量の目標を設定するユニットである。具体的には目標クラス1100は、属性として、目標値1100aを有するが、操作は有さない。
現在クラス1102は、物理量の現在の状態を把握するユニットである。具体的には現在クラス1102は、属性として、現在値1102aを有するが、操作は有さない。
調節クラス1101は、目標クラス1100の目標値1100aと現在クラス1102の現在値1102aとを参照して管理対象を調節するユニットである。
調節クラス1101は、属性として、調節ID1101aを有するが、操作は有さない。
調節仕様クラス1200は、調節仕様を設定するユニットである。具体的には調節仕様クラス1200は、属性として、調節仕様ID1200aを有するが、操作は有さない。調節仕様ID1200aは調節仕様が複数存在する場合に調節仕様を特定するためのものである。
調節クラス1101が実行される場面において、目標クラス1100を実体化したオブジェクトと、調節クラス1100を実体化したオブジェクトとは以下の関係がある。
調節クラス1101から見ると、「調節クラス1101は、1つの目標値を現在値とする」ことになり、目標クラス1100から見ると、「目標クラス1100は、調節クラス1101に現在値とされるものは1つであるが、されないものもある」ことになる。
調節クラス1101が実行される場面において、調節クラス1100を実体化したオブジェクト1個に対し現在クラス1102を実体化したオブジェクトが1個存在する。
また、調節クラス1101を実体化したオブジェクトと、調節仕様クラス1200を実体化したオブジェクトとは以下の関係がある。
調節仕様(調節方法)が複数存在するという関連が2本線のうちの下側の線の関連であり、複数存在する調節仕様のうち、1つを選んで関連を張っているというのが2本線のうちの上側の線の関連である。
【0112】
このようにクラス構成を用いてモデル化することによりフィードバック制御において、拡張部分(調節仕様)をモデル化したことでさらに応用範囲が広がる。
【0113】
なお、本実施の形態の画像形成装置で実行されるリクエスト管理プログラム(ジョブ処理指示プログラム)は、インストール可能な形式または実行可能な形式のファイルでCD−ROM(Compact Disc Read Only Memory)、フレキシブルディスク(FD)、CD−R(CD Recordable)、DVD(Digital Versatile Disk)などのコンピュータで読み取り可能な記録媒体に記録して提供するよう構成してもよい。この場合、CPU11が上記記憶媒体から、リクエスト管理プログラム(ジョブ処理指示プログラム)を読み出してMEM−P12上にロードすることで、画像形成装置に、上述した各ステップ(工程)、各手段または各部を実現させる。
【0114】
また、リクエスト管理プログラム(ジョブ処理指示プログラム)を、インターネットなどのネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するよう構成してもよい。さらに、かかるリクエスト管理プログラム(ジョブ処理指示プログラム)をインターネットなどのネットワーク経由で提供または配布するようにしてもよい。
【産業上の利用可能性】
【0115】
本発明は、定着制御の他、自動車のクルーズコントロール装置(自動速度制御)、電子ポット、炊飯ジャー等の民生機器等に適用できる。
【図面の簡単な説明】
【0116】
【図1】本実施の形態に係る複合機1を取り巻くネットワーク環境を説明するためのネットワーク図である。
【図2】図1に示した複合機1のハードウェア構成を示すブロック図である。
【図3】図1に示した複合機1のソフトウェアとハードウェアの関係を説明するための説明図である。
【図4】本実施形態の特徴部分であるリクエスト管理部113aの統合アプリケーション110における位置づけと、かかる統合アプリケーション110の概要構成を説明するための説明図である。
【図5】図4に示した各サブシステムを、UMLのクラス図に置換えた図である。
【図6】(a)は「ディレクトリ−ファイル」モデルを説明するための説明図であり、(b)は「ディレクトリ−ファイル」モデルを説明するための説明図である。
【図7】「ディレクトリ−ファイル」モデルのアナロジーとして構成したリクエスト管理部113aのクラス構成を、UMLのクラス図により表現したものである。
【図8】複合機1の操作パネル400の一例を示した図である。
【図9】図8に示したコピーサーバーキー403をタッチすると、液晶タッチパネル420に表示されるメニューの一例である。
【図10】統合アプリケーション110に、プリンタ機能などの新規機能を追加する場合の概念を説明するための説明図である。
【図11】本発明にかかるフィードバック制御の他の実施の形態におけるリクエスト管理部のクラス構成を、UMLのクラス図により表現したものである。
【図12】本発明にかかるフィードバック制御のさらに他の実施の形態におけるリクエスト管理部のクラス構成を、UMLのクラス図により表現したものである。
【図13】複合機1に搭載されるソフトウェア構成の変遷を説明するための説明図である。
【図14】従来の複合機のソフトウェアとハードウェアの関係を説明するための説明図である。
【符号の説明】
【0117】
201a スキャナ
201b プロッタ
201c HDD
201d ネットワーク
201e その他のリソース
400 操作パネル
401 初期設定キー
402 コピーキー
403 コピーサーバーキー
404 プリンタキー
405 送信キー
406 テンキー
407 クリア/ストップキー
408 スタートキー
409 予熱キー
410 リセットキー
420 タッチパネル
421 原稿読み取りボタン
422 リストから削除ボタン
423 印刷条件ボタン
424 文書リスト例1
425 文書リスト例2




 

 


     NEWS
会社検索順位 特許の出願数の順位が発表

URL変更
平成6年
平成7年
平成8年
平成9年
平成10年
平成11年
平成12年
平成13年


 
   お問い合わせ info@patentjp.com patentjp.com   Copyright 2007-2013