JP7135654B2 - 情報処理装置及び情報処理プログラム - Google Patents

Description

本発明は、情報処理装置及び情報処理プログラムに関する。

特許文献１には、端末へのプログラムのインストールを管理するインストール管理方法において、前記端末が所有する固有リソース量と前記端末における経時的なリソース消費量とに基づいて前記端末のリソース消費状態を決定するステップと、前記端末にインストールされようとするプログラムの推定リソース消費量を算定するステップと、前記リソース消費状態と前記推定リソース消費量とに基づいて前記端末におけるインストールされようとするプログラムの仮想的な実行快適度を推定するステップと、前記実行快適度に基づいて前記端末に対する当該プログラムのインストール可否を決定するステップとを備えるインストール管理方法が開示されている。

特開２００８－２６９４２２号公報

複合機等の情報処理装置は、装置全体を統括的に制御するシステム制御部と、画像形成部等のデバイスを制御するデバイス制御部と、がインターフェース回路を介して接続される構成をとることがある。

本発明は、旧仕様のデバイス制御部及び周辺装置の少なくとも一方から新仕様のシステム制御部に連続的に送信されるデータの実時間処理をシステム制御部で実現した場合に、新規のアプリケーションの実行の可否を確認することができる情報処理装置及び情報処理プログラムを提供することを目的とする。

第１態様に係る情報処理装置は、旧仕様のデバイス制御部及び周辺装置の少なくとも一方に接続される新仕様のシステム制御部が提供する新規のアプリケーションの実行に要求されるリソースに関するアプリ要求リソース情報と、前記システム制御部のリソースに関するシステムリソース情報と、前記デバイス制御部及び周辺装置の少なくとも一方から前記システム制御部に連続的に送信されるデータの実時間処理を前記システム制御部で実現するために前記システム制御部に要求されるリソースに関するデバイス要求リソース情報と、を取得する取得部と、前記システムリソース情報及び前記デバイス要求リソース情報から、前記システム制御部で前記実時間処理を実現した場合における前記システム制御部のリソースの余裕度を算出する算出部と、前記アプリ要求リソース情報及び前記余裕度から、前記アプリケーションの実行の可否を判定する判定部と、を備える。

第２態様に係る情報処理装置は、前記判定部は、前記余裕度が、前記アプリケーションの実行に要求されるリソースから定めた閾値以上の場合は、前記アプリケーションの実行を許可する。

第３態様に係る情報処理装置は、前記判定部は、前記余裕度が、前記アプリケーションの実行に要求されるリソースから定めた閾値未満の場合は、前記アプリケーションの実行を禁止する。

第４態様に係る情報処理装置は、前記アプリケーションの実行の許可に必要なリソースの条件を報知する報知部を備える。

第５態様に係る情報処理装置は、前記算出部は、前記アプリケーションを安定して動作させるための安定係数を用いて前記余裕度を算出する。

第６態様に係る情報処理装置は、前記安定係数は、前記リソースの種類に応じて設定されている。

第７態様に係る情報処理装置は、コンピュータを、第１態様～第６態様の何れか１態様に記載の情報処理装置の各部として機能させるための情報処理プログラムである。

第１態様に係る情報処理装置及び第７態様に係る情報処理プログラムによれば、旧仕様のデバイス制御部及び周辺装置の少なくとも一方から新仕様のシステム制御部に連続的に送信されるデータの実時間処理をシステム制御部で実現した場合に、新規のアプリケーションの実行の可否を確認することができる、という効果を有する。

第２態様に係る情報処理装置によれば、余裕度が閾値以上でない場合にアプリケーションの実行を許可する場合と比較して、アプリケーションを実行した際の不具合を抑制することができる、という効果を有する。

第３態様に係る情報処理装置によれば、余裕度が閾値未満でない場合にアプリケーションの実行を禁止する場合と比較して、必要以上にアプリケーションの実行が禁止されてしまうのを抑制することができる、という効果を有する。

第４態様に係る情報処理装置によれば、アプリケーションの実行の許可に必要なリソースの条件を報知しない場合と比較して、容易にアプリケーションの実行の許可に必要なリソースの条件を把握することができる、という効果を有する。

第５態様に係る情報処理装置によれば、安定係数を用いずに余裕度を算出する場合と比較して、更に安定してアプリケーションを実行させることができる、という効果を有する。

第６態様に係る情報処理装置によれば、リソースの種類に関係なく安定係数を固定にした場合と比較して、アプリケーションの実行可否を精度良く判定することができる、という効果を有する。

画像形成装置の構成図である。 システムリソース情報の一例を示す図である。 デバイス要求リソース情報及びアプリ要求リソース情報の一例を示す図である。 システム制御部のＣＰＵの機能ブロック図である。 情報処理プログラムによる処理の流れを示すフローチャートである。 合成リソース情報の一例を示す図である。

以下、図面を参照して、本発明を実施するための形態例を詳細に説明する。

図１は、画像形成装置１０の概略構成を示す図である。なお、画像形成装置１０は、情報処理装置の一例である。

図１に示すように、画像形成装置１０は、システム制御部１２、デバイス制御部１４、画像形成部１６、スキャナ装置１８、ファクシミリ装置２０、及びＵＩ（ユーザインターフェース）装置２２を備える。なお、スキャナ装置１８、ファクシミリ装置２０、及びＵＩ装置２２は、周辺装置の一例である。なお、周辺装置とは、画像形成装置１０の主機能である画像形成機能に対して副次的な機能を提供する装置である。

システム制御部１２とデバイス制御部１４とは、インターフェース３０を介して接続されている。インターフェース３０は標準化されたインターフェースであり、システム制御部１２及びデバイス制御部１４の仕様が異なる場合でも正常に動作するように設計されたインターフェースである。

システム制御部１２とスキャナ装置１８とは、インターフェース３２を介して接続されている。インターフェース３２は標準化されたインターフェースであり、システム制御部１２及びスキャナ装置１８の仕様が異なる場合でも正常に動作するように設計されたインターフェースである。

システム制御部１２とファクシミリ装置２０とは、インターフェース３４を介して接続されている。インターフェース３４は標準化されたインターフェースであり、システム制御部１２及びファクシミリ装置２０の仕様が異なる場合でも正常に動作するように設計されたインターフェースである。

システム制御部１２とＵＩ装置２２とは、インターフェース３６を介して接続されている。インターフェース３６は標準化されたインターフェースであり、システム制御部１２及びＵＩ装置２２の仕様が異なる場合でも正常に動作するように設計されたインターフェースである。

なお、本実施形態では、旧仕様のシステム制御部が新仕様のシステム制御部１２に交換された場合について説明する。すなわち、旧仕様のデバイス制御部１４、スキャナ装置１８、ファクシミリ装置２０、及びＵＩ装置２２に新仕様のシステム制御部１２が接続された場合について説明する。ここで、例えばシステム制御部の仕様とは、システム制御部の性能及び機能の少なくとも１つを含む。そして、本実施形態では、旧仕様のシステム制御部よりも新仕様のシステム制御部１２の方が、性能及び機能の少なくとも１つが優れている場合について説明する。

システム制御部１２は、デバイス制御部１４、画像形成部１６、スキャナ装置１８、ファクシミリ装置２０、及びＵＩ装置２２を統括制御する。システム制御部１２は、ＣＰＵ１２Ａ、ＲＯＭ１２Ｂ、ＲＡＭ１２Ｃ、不揮発性メモリ（ＮＶＭ）１２Ｄ、通信インターフェース（Ｉ／Ｆ）１２Ｅ、ゲートアレイ（ＧＡ）１２Ｆ、ＳＤメモリ１２Ｇ、ネットワークインターフェース（Ｉ／Ｆ）１２Ｈ等の各種ハードウェアを含んで構成される。通信Ｉ／Ｆ１２Ｅは、デバイス制御部１４、スキャナ装置１８、ファクシミリ装置２０、及びＵＩ装置２２と通信するためのインターフェースである。

また、ネットワークＩ／Ｆ１２ＨはネットワークＮと接続されており、これによりシステム制御部１２は、ネットワークＮを介して端末装置１００と接続される。

デバイス制御部１４は、紙等の記録媒体に画像を形成する機能を有する画像形成部１６を制御する。デバイス制御部１４は、ＣＰＵ１４Ａ、ＲＯＭ１４Ｂ、ＲＡＭ１４Ｃ、不揮発性メモリ（ＮＶＭ）１４Ｄ、及び通信Ｉ／Ｆ１４Ｅ等の各種ハードウェアを含んで構成される。通信Ｉ／Ｆ１４Ｅは、システム制御部１２と通信するためのインターフェースである。

画像形成部１６は、例えば電子写真方式又はインクジェット記録方式等により、紙等の記録媒体に画像を形成する。

スキャナ装置１８は、紙等の原稿に記録された原稿画像を読み取るスキャン機能を有する。スキャナ装置１８は、ＣＰＵ１８Ａ、ＲＯＭ１８Ｂ、ＲＡＭ１８Ｃ、不揮発性メモリ（ＮＶＭ）１８Ｄ、通信Ｉ／Ｆ１８Ｅ、及びスキャン部１８Ｆ等の各種ハードウェアを含んで構成される。通信Ｉ／Ｆ１８Ｅは、システム制御部１２と通信するためのインターフェースである。

ファクシミリ装置２０は、スキャナ装置１８によってスキャンされた原稿画像を指定された宛先にファクシミリ送信したり、外部から送信されたファクシミリを受信したりするファクシミリ機能を有する。ファクシミリ装置２０は、ＣＰＵ２０Ａ、ＲＯＭ２０Ｂ、ＲＡＭ２０Ｃ、不揮発性メモリ（ＮＶＭ）２０Ｄ、通信Ｉ／Ｆ２０Ｅ、及びファクシミリ通信部２０Ｆ等の各種ハードウェアを含んで構成される。通信Ｉ／Ｆ２０Ｅは、システム制御部１２と通信するためのインターフェースである。

ＵＩ装置２２は、ユーザーがコピー機能、スキャン機能、及びファクシミリ機能等の各種機能の実行を指示するための操作を行う操作機能、各種メニューを表示する画面及び各種機能の実行結果等を表示する画面等の各種画面を表示する表示機能を有する。ＵＩ装置２２は、ＣＰＵ２２Ａ、ＲＯＭ２２Ｂ、ＲＡＭ２２Ｃ、不揮発性メモリ（ＮＶＭ）２２Ｄ、通信Ｉ／Ｆ２２Ｅ、及びタッチパネル２２Ｆ等の各種ハードウェアを含んで構成される。通信Ｉ／Ｆ２２Ｅは、システム制御部１２と通信するためのインターフェースである。

システム制御部１２のＮＶＭ１２Ｄには、後述する情報処理プログラム、アプリ要求リソース情報、及びシステムリソース情報等が記憶される。

アプリ要求リソース情報は、旧仕様のデバイス制御部１４、スキャナ装置１８、ファクシミリ装置２０、及びＵＩ装置２２に接続された新仕様のシステム制御部１２が提供する新規のアプリケーションの実行に要求されるリソースに関する情報である。ここで、新規のアプリケーションとは、旧仕様のシステム制御部では提供されていないアプリケーション、すなわち新規の機能をいう。また、リソースとは、機能及び処理性能の少なくとも一方をいう。

新規のアプリケーションの例としては、例えば新仕様のシステム制御部１２においてＣＰＵの性能が向上している場合には、旧仕様のシステム制御部では提供されなかった高圧縮率での画像データの圧縮処理等が挙げられる。これを旧仕様のシステム制御部のままで実現しようとすると、別途専用のハードウェアアクセラレータ等の追加が必要となるが、本実施形態では不要となる。

また、システム制御部１２のようにハードディスクが搭載されていない場合でも、旧仕様のシステム制御部と比較してＳＤメモリ１２Ｇの容量が増加している場合には、ＳＤメモリ１２Ｇの未使用領域をファクシミリデータを保存する領域として使用可能なため、ハードディスクが搭載されていない画像形成装置でも新規のアプリケーションとしてファクシミリ通信機能を搭載することが可能となる。

システムリソース情報は、システム制御部１２のリソースに関する情報である。

図２には、システムリソース情報の一例を示した。図２の例では、リソースは機能及び処理性能の２種類に分類されている。機能は、水準１としてプロセッサ、メモリ、ストレージ、インターフェース、電源、及びソフトウェアに分類されている。また、処理性能は、水準１としてリソース消費及びベンチマーク性能に分類されている。また、水準１の項目は更に水準２の項目に分類され、水準２の項目は更に水準３の項目に分類される。そして、水準３の項目に対してスペックが設定されている。例えば、機能を表すリソースの一例としてプロセッサのクロック周波数、メモリのメモリ容量等がある。また、処理性能を表すリソースの一例として、プロセッサの占有率、メモリの消費率等がある。

また、デバイス制御部１４のＮＶＭ１４Ｄには、デバイス要求リソース情報が記憶されている。同様に、スキャナ装置１８のＮＶＭ１８Ｄ及びファクシミリ装置２０のＮＶＭ２０にも、それぞれの装置に対応したデバイス要求リソース情報が各々記憶されている。

デバイス要求リソース情報は、デバイス制御部１４、スキャナ装置１８、及びファクシミリ装置２０の各々からシステム制御部１２に連続的に送信されるデータの実時間処理をシステム制御部１２で実現するためにシステム制御部１２に要求されるリソースに関する情報である。ここで、実時間処理とは、デバイス制御部１４、スキャナ装置１８、及びファクシミリ装置２０からシステム制御部１２に連続的に送信されるデータをリアルタイムで処理する必要がある処理である。例えば複数枚の原稿をコピーする処理等である。この場合、スキャナ装置１８により原稿からスキャンした画像の画像データが連続的にシステム制御部１２に送信される。

図３には、デバイス要求リソース情報及びアプリ要求リソース情報の一例を示した。

例えばデバイス要求リソース情報は、図２に示すシステムリソース情報から、デバイス制御部１４に接続されたデバイスである画像形成部１６を設計仕様通りに動作させるために必要なリソース以外の不要なリソースを除いたリソースの情報である。

また、アプリ要求リソース情報は、システムリソース情報から、新規のアプリケーションの実行に必要なリソース以外の不要なリソースを除いたリソースの情報である。

図３では、グレーアウトされたリソースが不要なリソースとして表されており、スペックの欄は空欄となっている。図３の例では、インターフェース等のリソースが不要なリソースとされている。

システム制御部１２では、スキャナ装置１８から連続的に送信された画像データに対して予め定めた画像処理を施して画像形成部１６で画像形成が可能な画像形成データを生成し、デバイス制御部１４に出力する。このコピー処理では、システム制御部１２がスキャナ装置１８から連続的に送信される画像データをリアルタイムに処理できなかった場合、画像形成部１６で記録媒体に記録される画像に乱れが生じる等の不具合が発生してしまう虞がある。従って、この場合のデバイス要求リソース情報は、画像形成部１６で記録媒体に記録される画像に乱れが生じる等の不具合が発生しないようにシステム制御部１２に要求されるリソースの情報である。

次に、システム制御部１２のＣＰＵ１２Ａの機能構成について説明する。

図４に示すように、ＣＰＵ１２Ａは、機能的には、取得部５０、算出部５２、判定部５４、及び報知部５６を備える。

取得部５０は、アプリ要求リソース情報及びシステムリソース情報を、ＮＶＭ１２Ｄから読み出すことにより取得する。また、取得部５０は、デバイス要求リソース情報を送信するようにデバイス制御部１４、スキャナ装置１８、ファクシミリ装置２０、及びＵＩ装置２２に通信Ｉ／Ｆ１２Ｅを介して要求し、取得する。これにより、デバイス制御部１４は、ＮＶＭ１４Ｄからデバイス要求リソース情報を読み出して通信Ｉ／Ｆ１４Ｅを介してシステム制御部１２に送信する。スキャナ装置１８等も同様に、ＮＶＭ１８Ｄ等からデバイス要求リソース情報を読み出し、通信Ｉ／Ｆ１８Ｅ等を介してシステム制御部１２に送信する。

算出部５２は、取得部５０が取得したシステムリソース情報及びデバイス要求リソース情報から、システム制御部１２で実時間処理を実現した場合におけるシステム制御部１２のリソースの余裕度を算出する。

判定部５４は、取得部５０が取得したアプリ要求リソース情報及び算出部５２が算出したシステム制御部１２のリソースの余裕度から、新仕様のシステム制御部１２が提供する新規のアプリケーションの実行の可否を判定する。

報知部５６は、判定部５４により新規のアプリケーションの実行を禁止すると判定された場合に、新規のアプリケーションの許可に必要なリソースの条件を報知する。例えば、報知部５６は、新規のアプリケーションの許可に必要なリソースの条件をＵＩ装置２２に出力し、表示させる。

次に、システム制御部１２のＣＰＵ１２Ａで実行される情報処理の流れについて図５に示すフローチャートを参照して説明する。なお、図５に示す処理は、オペレータが旧仕様のシステム制御部を新仕様のシステム制御部１２に交換した後、新規のアプリケーションのインストールを指示する操作を行った場合に実行される。

ステップＳ１００では、アプリ要求リソース情報及びシステムリソース情報を、ＮＶＭ１２Ｄから読み出すことにより取得する。

ステップＳ１０２では、デバイス要求リソース情報を、デバイス制御部１４、スキャナ装置１８、ファクシミリ装置２０、及びＵＩ装置２２から各々取得する。

ステップＳ１０３では、ステップＳ１００で取得したアプリ要求リソース情報及びシステムリソース情報と、ステップＳ１０２で取得したデバイス要求リソース情報と、を１つにまとめた合成リソース情報を生成する。図６には、合成リソース情報の一例を示した。

ステップＳ１０４では、ステップＳ１０２で取得したデバイス要求リソース情報に記述されたリソースのうち、後述するステップＳ１０８の余裕度の判定処理を行っていないリソースを、余裕度の判定対象のリソースとして選択する。

ステップＳ１０６では、ステップＳ１００で取得したシステムリソース情報及びステップＳ１０２で取得したデバイス要求リソース情報から、システム制御部１２で実時間処理を実現した場合におけるシステム制御部１２のリソースの余裕度を算出する。すなわち、ステップＳ１０４で選択したリソースについて、デバイス要求リソース情報に記述されたリソースと、リソースに対応するシステムリソース情報に記述されたリソースと、の比較結果に基づいて余裕度を算出する。

ステップＳ１０８では、ステップＳ１０６で算出したリソースの余裕度に基づいて、新規のアプリケーションの実行を許可する余裕が有るか否かを判定する。

具体的には、例えば、ステップＳ１０６で算出した余裕度が閾値以上であるか否かを判定する。ここで、余裕度の算出方法及び閾値については、リソースの種類に応じて選択する。

例えば、リソースの種類は、リソースの積算値によって余裕の有無を判定すべき第１の種類のリソースと、リソースの最大値又は仕様のバージョンによって余裕の有無を判定すべき第２の種類のリソースと、に概ね分けられる。

第１の種類のリソースとしては、プロセッサ占有率、メモリ及びストレージ等のバス占有率、メモリ容量、ストレージ容量、及びインターフェース数等が挙げられる。

以下、プロセッサ占有率の事例で説明する。

システムリソース情報におけるプロセッサ占有率Ｒ１が２０（％）、デバイス要求リソース情報におけるプロセッサ占有率Ｒ２が２０（％）、アプリ要求リソース情報におけるプロセッサ占有率Ｒ３が３０（％）であった場合、余裕度Ｍ１は次式で算出される。

Ｍ１＝１００－（Ｒ１＋Ｒ２＋Ｒ３）＝１００－（２０＋２０＋３０）＝３０（％）

そして、プロセッサの占有率の積算値が１００（％）以下の場合、すなわち、余裕度Ｍ１が０（％）以上であれば余裕有りと判定してよいため、閾値は０（％）に設定される。従って、上記の例の場合は、余裕度Ｍ１（３０％）が閾値（０％）以上なので、余裕有りと判定される。

次に、リソースがメモリ容量である場合について説明する。

例えばシステムリソース情報におけるメモリ容量Ｃ１が１０（ギガバイト）、デバイス要求リソース情報におけるメモリ容量Ｃ２が２（ギガバイト）、アプリ要求リソース情報におけるメモリ容量Ｃ３が３（ギガバイト）であった場合、余裕度Ｍ２は次式で算出される。

Ｍ２＝Ｃ１－Ｃ２＝１０－２＝８（ギガバイト）

そして、余裕度Ｍ２がアプリ要求リソース情報におけるメモリ容量Ｃ３以上であれば余裕有りと判定してよいため、閾値はメモリ容量Ｃ３（３ギガバイト）に設定される。従って、上記の例の場合は、余裕度Ｍ２（８ギガバイト）が閾値（３ギガバイト）以上なので、余裕有りと判定される。

なお、上記の例はデバイス要求リソース情報が１つの場合であるが、複数のデバイス要求リソース情報がある場合は、複数のデバイス要求リソース情報の合計値を用いて余裕度を算出すればよい。

なお、新規のアプリケーションを安定して動作させるために、予め定めた安定係数Ｋを用いて余裕度を算出してもよい。例えば上記のプロセッサの占有率の例の場合、次式により余裕度Ｍ１を算出してもよい。

Ｍ１＝１００－（Ｒ１＋Ｒ２＋Ｒ３＋Ｋ）

例えば安定係数Ｋを２５％とした場合、余裕度Ｍ１は以下のように算出される。

Ｍ１＝１００－（２０＋２０＋３０＋２５）＝５（％）

この場合も、余裕度Ｍ１（５％）が閾値（０％）以上なので、新規のアプリケーションのインストールは許可される。なお、安定係数Ｋをリソースの種類に応じて設定してもよい。

また、第２の種類のリソースとしては、プロセッサ動作周波数、メモリ及びインターフェース等のクロック周波数、ファームウェアのバージョン情報等が挙げられる。

プロセッサ動作周波数、メモリ及びインターフェース等のクロック周波数等は、データ処理の性能を左右する重要なリソースである。これらのリソースについては、デバイス要求リソース情報には、画像形成部１６を設計仕様通りに動作させるために必要な推奨条件として記述されており、アプリ要求リソース情報には、新規のアプリケーションを設計仕様通りに動作させるために必要な推奨条件として記述されている。そして、システムリソース情報におけるリソースが、デバイス要求リソース情報及びアプリ要求リソース情報に記述された推奨条件を下回った場合は、新規のアプリケーションが安定して動作する保障はないため、余裕無しと判定する。

また、各種インターフェース及びファームウェアのバージョンについては、一般的に下位互換を前提としているため、新しいバージョンであれば古いバージョンの機能に基本的に同じ機能に対応していると考えてよい。従って、各種インターフェース及びファームウェアのバージョンについては、システムリソース情報におけるバージョンが、デバイス要求リソース情報及びアプリ要求リソース情報におけるバージョンよりも新しい場合には、余裕有りと判定する。

ステップＳ１０８の判定が肯定された場合、すなわち、判定対象のリソースが余裕有りと判定された場合はステップＳ１１０へ移行する。一方、ステップＳ１０８の判定が否定された場合、すなわち、判定対象のリソースが余裕無しと判定された場合はステップＳ１１２へ移行する。

ステップＳ１１０では、ステップＳ１０３で生成した図６に示す合成リソース情報のうち、判定対象のリソースについて余裕有りとして記録する。図６の例では、余裕有りを「○」で示している。また、図６の例では、機能について総合的に判定した結果を「機能判定」として記録している。機能判定が「○」となるのは、機能に関するリソースの全てが「○」の場合である。処理性能についても同様である。また、機能及び処理性能を総合的に判定した結果を「総合判定」として記録している。総合判定が「○」となるのは、機能判定及び処理性能判定の全てが「○」の場合である。

一方、ステップＳ１１２では、ステップＳ１０３で生成した図６に示す合成リソース情報のうち、判定対象のリソースについて余裕無しとして記録する。

ステップＳ１１４では、全てのリソースについて余裕の有無を判定したか否かを判定する。そして、ステップＳ１１４の判定が肯定された場合はステップＳ１１６へ移行する。一方、ステップＳ１１４の判定が否定された場合は、ステップＳ１０４へ移行し、未判定のリソースを選択して上記と同様の処理を実行する。

ステップＳ１１６では、合成リソース情報を参照し、全てのリソースについて余裕有りと判定されたか否かを判定する。そして、ステップＳ１１６の判定が肯定された場合はステップＳ１１８へ移行する。一方、ステップＳ１１６の判定が否定された場合、すなわち、１つでも余裕無しと判定されたリソースが存在する場合は、ステップＳ１２０へ移行する。

ステップＳ１１８では、新仕様のシステム制御部１２が提供する新規のアプリケーションの実行を許可してもよいため、アプリケーションをインストールする。ここで、インストールとは、アプリケーションの実行が可能な状態となるように、新規のアプリケーションを実行するためのプログラムをＮＶＭ１２Ｄに展開すること等をいう。

一方、ステップＳ１２０では、新仕様のシステム制御部１２が提供する新規のアプリケーションの実行は禁止すべきであるため、アプリケーションのインストールは実行せず、アプリケーションの実行の許可に必要なリソースの条件を算出し、算出した条件をＵＩ装置２２に出力して表示させる。

例えば、リソースがプロセッサ占有率の場合について説明する。

システムリソース情報におけるプロセッサ占有率Ｒ１が３０（％）、デバイス要求リソース情報におけるプロセッサ占有率Ｒ２が４０（％）、アプリ要求リソース情報におけるプロセッサ占有率Ｒ３が４０（％）であった場合、余裕度Ｍ１は次式で算出される。

Ｍ１＝１００－（Ｒ１＋Ｒ２＋Ｒ３）＝１００－（３０＋４０＋４０）＝－１０（％）

この場合、プロセッサ占有率Ｒ１が４０％以上であればアプリケーションの実行が許可されることを示すメッセージをＵＩ装置２２に表示させる。これにより、アプリケーションの実行に必要なプロセッサ占有率がオペレータによって把握される。

ところで、旧仕様のデバイス制御部１４、スキャナ装置１８、及びＵＩ装置２２に記憶されたデバイス要求リソース情報は、旧仕様のシステム制御部１２に対応して算出された情報であるのが通常である。このため、新仕様のシステム制御部１２に交換（アップグレード）した場合、旧仕様のデバイス制御部１４等に記憶されたデバイス要求リソース情報の算出基準が新仕様のシステム制御部１２と異なり、デバイス要求リソース情報が新仕様のシステム制御部１２に対して不適切な場合がある。このようなデバイス要求リソース情報の例としては、旧仕様のシステム制御部を基準として算出されたプロセッサ占有率が挙げられる。

従って、新仕様のシステム制御部１２のリソースの余裕度を算出するにあたり、図５の処理に先立ち、デバイス要求リソース情報を新仕様のシステム制御部１２に対応した情報に予め変換するようにしてもよい。

以下、新仕様のシステム制御部１２に交換された場合に、デバイス要求リソース情報を新仕様のシステム制御部１２に対応させる方法の一例を説明する。

新仕様のシステム制御部１２に交換した後に、システム制御部１２で実時間処理が必要となる処理を実行させた場合に、システム制御部１２のリソースを測定する評価プログラムを実行する。評価プログラムは、プリント処理、スキャン処理、及びファクシミリ通信処理の少なくとも１つの処理が個別に又は並行して実行された場合、すなわち、デバイス制御部１４、スキャナ装置１８、及びファクシミリ装置２０の少なくとも１つからシステム制御部１２に連続的にデータが送信され、送信されたデータをシステム制御部１２で実時間処理した場合に、システム制御部１２の各種リソース、すなわちデバイス要求リソース情報を測定するためのプログラムである。測定対象のデバイス要求リソース情報としては、例えばプロセッサ占有率、メモリ消費量、ストレージ消費量、メモリ転送速度、ストレージ転送速度、ネットワーク帯域占有率、バス帯域占有率、及び電力供給量等が挙げられる。

なお、評価プログラムを実行する際には、例えばオペレータの指示によりプリント処理、スキャン処理、及びファクシミリ通信処理等を並行して実行させる。

そして、評価プログラムを実行して測定により得られたデバイス要求リソース情報を、新仕様のシステム制御部１２のＮＶＭ１２Ｄに追加又は上書きにより記憶させる。

評価プログラムを実行して測定により得られたデバイス要求リソース情報を、新仕様のシステム制御部１２のＮＶＭ１２Ｄに追加又は上書きにより記憶させる。

なお、評価プログラムに代えてベンチマークテストを実行することでシステム制御部１２のリソースを測定してもよい。ベンチマークテストは、リソースの種類に応じて適切なベンチマークテストを選択すればよい。

また、新仕様のシステム制御部１２に交換した場合、アプリ要求リソース情報についても、前述したデバイス要求リソース情報と同様に、アプリ要求リソース情報の算出基準が旧仕様のシステム制御部を基準に算出されている場合がある。

従って、図５のステップＳ１００でアプリ要求リソース情報を取得した後、アプリ要求リソース情報を新仕様のシステム制御部１２に対応した情報に置き換えるようにしてもよい。

例えば、現存する複数種類のシステム制御部１２を想定したアプリ要求リソース情報を例えばネットワークＮに接続された図示しないサーバ装置等の記憶装置に予め記憶しておき、その中から新仕様のシステム制御部１２に対応するアプリ要求リソース情報を選択し、選択したアプリ要求リソース情報をＮＶＭ１２Ｄに一時的に記憶するようにしてもよい。

また、他の方法として、旧仕様及び新仕様のシステム制御部の処理性能の差に基づいて、アプリ要求リソース情報の予測値を算出し、算出した予測値をアプリ要求リソース情報としてＮＶＭ１２Ｄに記憶させるようにしてもよい。

以下、具体例について説明する。

例えばステップＳ１００で取得したアプリ要求リソース情報が、旧仕様のシステム制御部１２のプロセッサ処理性能のスコア（特定の条件下におけるプロセッサ処理性能を示す数値）Ｓｃ１（＝１００）を前提とした情報であり、且つ、旧仕様のシステム制御部のプロセッサの占有率Ｐ１が例えば５０％であったとする。

この場合、新規のアプリケーションの実行に必要なアプリ要求リソース情報としてのプロセッサ処理性能のスコアＳｃ１’は、次式で算出される。

Ｓｃ１’＝Ｓｃ１×Ｐ１＝１００×０．５０＝５０

そして、新仕様のシステム制御部１２のプロセッサ処理性能のスコアＳｃ２が旧仕様のシステム制御部１２のプロセッサ処理性能のスコアＳｃ１の２倍、すなわちＳｃ２＝２００であった場合、新仕様のシステム制御部のプロセッサの占有率Ｐ２は、次式で算出される。

Ｐ２＝Ｓｃ１’／Ｓｃ２＝５０／２００＝２５（％）

すなわち、新仕様のシステム制御部１２のプロセッサ処理性能のスコアＳｃ２は、旧仕様のシステム制御部１２のプロセッサ処理性能のスコアＳｃ１の２倍なので、単位時間当たりの処理性能が２倍ということである。従って、新仕様のシステム制御部１２の方が、旧仕様のシステム制御部と比べて短時間にデータ処理が可能であり、新仕様のシステム制御部１２のプロセッサの占有率Ｐ２は、旧仕様のシステム制御部のプロセッサの占有率の１／２となる。

このように、本実施形態では、新規のアプリケーションをインストールする前に、リソースの余裕度を算出して新規のアプリケーションの実行の可否を判定する。このため、実際はアプリケーションを実行するためのリソースの余裕度が足りないにも関わらずアプリケーションをインストールしてしまい、画像乱れ等の不具合が発生するのが抑制される。

以上、各実施形態を用いて本発明について説明したが、本発明は各実施形態に記載の範囲には限定されない。本発明の要旨を逸脱しない範囲で各実施形態に多様な変更または改良を加えることができ、当該変更または改良を加えた形態も本発明の技術的範囲に含まれる。

例えば、本実施形態では、画像形成装置に本発明を適用した場合について説明したが、他の情報処理装置に本発明を適用してもよい。

また、本実施形態では、全てのリソースが余裕有りと判定された場合に限って新規のアプリケーションのインストールを許可したが、一部のリソースが余裕無しと判定された場合でも新規のアプリケーションのインストールを許可するようにしてもよい。

また、例えば、図５に示した情報処理をＡＳＩＣ（Application Specific Integrated Circuit）等のハードウェアで実現するようにしてもよい。この場合、ソフトウェア で実現する場合に比べて、処理の高速化が図られる。

また、各実施形態では、情報処理プログラムがＮＶＭ１２Ｄにインストールされている形態を説明したが、これに限定されるものではない。本実施形態に係る情報処理プログラムを、コンピュータ読取可能な記憶媒体に記録した形態で提供してもよい。例えば、本実施形態に係る情報処理プログラムを、ＣＤ(Compact Disc)－ＲＯＭ及びＤＶＤ(Digital Versatile Disc)－ＲＯＭ等の光ディスクに記録した形態、若しくはＵＳＢ(Universal Serial Bus)メモリ及びメモリカード等の半導体メモリに記録した形態で提供してもよい。また、本実施形態に係る情報処理プログラムを、ネットワークＩ／Ｆ１２Ｈに接続されたネットワークＮを介して端末装置１００等の外部装置から取得するようにしてもよい。

１０ 画像形成装置
１２ システム制御部
１４ デバイス制御部
１６ 画像形成部
１８ スキャナ装置
２０ ファクシミリ装置
２２ ＵＩ装置
５０ 取得部
５２ 算出部
５４ 判定部
５６ 報知部
１００ 端末装置

Claims (7)

1. 旧仕様のデバイス制御部及び周辺装置の少なくとも一方に接続される新仕様のシステム制御部が提供する新規のアプリケーションの実行に要求されるリソースに関するアプリ要求リソース情報と、前記システム制御部のリソースに関するシステムリソース情報と、前記デバイス制御部及び周辺装置の少なくとも一方から前記システム制御部に連続的に送信されるデータの実時間処理を前記システム制御部で実現するために前記システム制御部に要求されるリソースに関するデバイス要求リソース情報と、を取得する取得部と、
   前記システムリソース情報及び前記デバイス要求リソース情報から、前記システム制御部で前記実時間処理を実現した場合における前記システム制御部のリソースの余裕度を算出する算出部と、
   前記アプリ要求リソース情報及び前記余裕度から、前記アプリケーションの実行の可否を判定する判定部と、
   を備えた情報処理装置。
2. 前記判定部は、前記余裕度が、前記アプリケーションの実行に要求されるリソースから定めた閾値以上の場合は、前記アプリケーションの実行を許可する
   請求項１記載の情報処理装置。
3. 前記判定部は、前記余裕度が、前記アプリケーションの実行に要求されるリソースから定めた閾値未満の場合は、前記アプリケーションの実行を禁止する
   請求項１又は請求項２記載の情報処理装置。
4. 前記アプリケーションの実行の許可に必要なリソースの条件を報知する報知部
   を備えた請求項３記載の情報処理装置。
5. 前記算出部は、前記アプリケーションを安定して動作させるための安定係数を用いて前記余裕度を算出する
   を備えた請求項１～４の何れか１項に記載の情報処理装置。
6. 前記安定係数は、前記リソースの種類に応じて設定されている
   請求項５記載の情報処理装置。
7. コンピュータを、請求項１～６の何れか１項に記載の情報処理装置の各部として機能させるための情報処理プログラム。

Images