JP2019168845A - 情報処理装置とその制御方法 - Google Patents

Abstract

【課題】記憶ユニットの動作時間を増やす要因となるアプリケーションを特定できる情報処理装置とその制御方法を提供する。【解決手段】アプリ管理部２０１は、画像形成装置で動作するアプリケーション（アプリ）２１０〜２１２の起動や停止を管理する。関数ライブラリ部２０２は、アプリが処理を行うために呼び出す関数の集合である。ファイルドライバ部２０６は、関数ライブラリ部からの要求により、ＨＤＤ上のファイルにアクセスするためのドライバである。アクセス監視部２０３は、アプリからの要求によるＨＤＤへのアクセス実行を監視する。第一のアクセス判定部２０４は、アクセス監視部の情報を用いて、アプリが定期的にＨＤＤにアクセスする第一のアプリであるかどうかを判定する。第二のアクセス判定部２０５は、第一のアクセス判定部により判定された第一のアプリが、想定外にＨＤＤへのアクセスを増やす要因となる第二のアプリであるかを判定する。【選択図】図２

Description

本発明は、情報処理装置とその制御方法に関し、特に情報処理装置のハードディスク装置(以下、HDD)の故障検知や回避の技術に関する。

アプリケーション(以下、アプリ)などのソフトウエアによるHDD上にファイルに対する読込みや書込みなどのアクセス要求により、HDDは動作する。このHDDの動作時間の累計時間(以下、累計動作時間)が、HDDメーカーの保証する累積動作時間(以下、限界時間)を越えると、HDDは故障しやすくなる。HDDを組み込んだ情報処理装置は、一般的には装置本体のサポート期間を設けており、HDDも含めてそのサポート期間内の動作を保証している。

特許文献1は、別の情報処理装置から対象の情報処理装置のHDDの累計動作時間を定期的に調べ、累積動作時間からHDDの限界時間までの残時間を算出し、HDDの残時間に基づいて警告を表示する技術である。

特開2008-65744号公報

先行技術の方法により、HDDが限界時間を越えることの予測は可能である。しかし、先行技術のHDDの累計動作時間を確認する方法では、情報処理装置のサポート期間内にHDDが限界時間を越える要因(想定外にHDDアクセスを増やす要因)を特定することが困難であるという課題がある。

本発明な上記従来例に鑑みてなされたもので、記憶ユニットの動作時間を増やす要因となるアプリケーションを特定することができる情報処理装置とその制御方法を提供することを目的とする。

上記目的を達成するために本発明は以下の構成を有する。
すなわち、本発明の一側面によれば、記憶ユニットにアクセスするアプリケーションを実行可能な情報処理装置であって、
前記記憶ユニットに対するアプリケーションごとのアクセスを監視するアクセス監視手段と、
前記アクセス監視手段により監視したアプリケーションごとのアクセスの時間間隔に基づいて、前記記憶ユニットに定期的にアクセスしている定期アクセスアプリケーションを特定する第一のアプリケーションの特定手段と、
前記定期アクセスアプリケーションの数と、前記記憶ユニットに対するアクセスの基準の時間間隔である基準間隔とに基づいて、一つの定期アクセスアプリケーションに許容されるアクセスの時間間隔である許容間隔を決定する決定手段と、
前記定期アクセスアプリケーションのうちから、前記許容間隔よりも短い時間間隔で前記記憶ユニットにアクセスしているアプリケーションを、前記記憶ユニットの動作時間を長くするアプリケーションとして特定する第二のアプリケーションの特定手段と
を有することを特徴とする情報処理装置が提供される。

本発明により、記憶ユニットの動作時間を増やす要因となるアプリケーションをを特定することができる。

画像形成装置１００のコントローラユニット１１９を表すブロック図である。 コントローラユニット１１９のソフトウエア構成を表すモジュール構成図である。 画像形成装置１００の第二のアプリ特定の処理を表すフローチャートである。 アプリごとのファイル構造のイメージ図である。 HDD１０４へのアクセス実行を記憶したログのイメージ図である。 基準間隔を説明するためのイメージ図である。 画像形成装置１００の第二のアプリ特定の処理を表すフローチャート図である。

以下、本発明を実施するための最良の形態について、図面を用いて説明する。
［第１の実施形態］
最初に、アプリを実行可能な情報処理装置の一実施例である画像形成装置のコントローラユニットの説明を行う。

●画像形成装置のコントローラユニットの構成
図1は、本発明の各実施形態に係る画像形成装置１００のコントローラユニットの内部構造を示すブロック図である。

コントローラユニット１１９は、各種制御プログラムを実行するCPU１０１を有する。CPU１０１は、ROM１０３に格納されているブートプログラムに基づきシステムを起動し、このシステム上で記憶ユニットであるHDD(ハードディスク装置)１０４に格納されている制御プログラムを読み出してRAM１０２をワークエリアとして所定の処理を実行する。この制御プログラムにより、Java（登録商標）プログラムなどで作成したアプリの所定の制御を実行することが可能である。HDD１０４には、上記各種制御プログラムが格納されるとともに、後述するネットワーク部１０７が有するすべての通信手段に関する情報や後述するアプリがアクセス可能なファイルやそれに関する情報を格納する。

CPU１０１には、RAM１０２、ROM１０３、HDD１０４がシステムバス１１１を介して接続されている。さらに操作部I/F１０５、ネットワーク部１０７、イメージバスI/F１１０、電源管理部１０９がシステムバス１１１を介して接続されている。

操作部Ｉ／Ｆ１０５は、操作部（ディスプレイ）１０６との間のインターフェイス部であり、操作部１０６に表示する画像データをＲＡＭ１０２から取得して転送する処理や、操作部１０６で発生した信号をＣＰＵ１０１へ転送する処理などを行う。

操作部１０６は、ユーザが操作可能なボタンなどの対象物を表示するための表示処理と、表示処理に表示された情報をユーザが操作した信号(入力信号)を検知する入力処理を行う。

電源管理部１０９は、画像形成装置１００の電源OFFと電源ONの管理を行う。なお電源をONにすると、CPU１０１は、ROM１０３のブートプログラムに基づきシステムを起動し、このシステム上でHDD１０４に格納されている制御プログラムを実行することで、画像形成装置１００の初期化処理(アプリの初期化も含む)を行う。さらに電源管理部１０９は、画像形成装置１００をスリープ状態(省電力モード)へ移行とスリープ状態から通常状態への復帰の管理も行う。

ネットワーク部１０７は、LAN１０８に接続され、LAN１０８を介した情報の入出力を行う。LAN回線にwebサーバなどのサーバが接続されている場合は、そのサーバからLAN１０８を介して情報を取得することが可能である。また、LAN回線内のプロキシサーバなどを介して、インターネットに接続し、インターネット上のサーバからアプリを取得することも可能である。

イメージバスI/F１１０は、システムバス１１１と、画像バス１１２とを接続し、データ構造を変換するバスブリッジである。画像バス１１２は、画像データを高速で転送可能なPCIバスまたはIEEE１３９４規定に従うバスから構成される。画像バス１１２には、デバイスI/F１１４および画像処理部１１３が接続されている。

デバイスI/F１１４は、画像入出力デバイスであるスキャナ１１６やプリンタ１１８とコントローラユニット１１９とを接続し、画像データの同期系／非同期系の変換を行う。ここでは、デバイスI/F１１４とスキャナ１１６とがケーブル１１５を介して、デバイスI/F１１４とプリンタ１１８とがケーブル１１７を介してそれぞれ接続されている。

画像処理部１１３は、多値画像データに対してJPEG、二値画像データに対して、JBEG、MMR、MHなどの圧縮伸張処理を行う。また、入力画像データや出力画面に対して、プリンタの補正や解像度変換などの補正、加工、編集を行う。

このように、コントローラユニット１１９のCPU１０１は、各制御プログラムに基づき、システムバス１１０に接続される各種デバイスとのアクセスを総括的に制御するととともに、アプリの初期化やアプリの動作に関する制御や動作を行う。

●ソフトウエア構成
次に、図２のモジュール構成図を用いて、画像形成装置１００のCPU１０１やHDD１０４などの各ハードウエア上で動作するソフトウエアのモジュール構成を説明する。なお、これらの各モジュールにおける処理は、CPU１０１が、ROM１０３やHDD１０４に記憶されているプログラムを読み出し、RAM１０２をワークエリアとして所定の処理を実行することで実現している。また、所定の処理を実行することで生成される全ての情報は、RAM１０２もしくはHDD１０４に記憶する。なお、このような各モジュールにおける処理は以降でも同様であるため、以降では記載を省略する。

アプリ管理部２０１は、画像形成装置１００で動作するアプリケーション（アプリ）の起動や停止などのライフサイクルを管理するための処理を行う。このアプリのライフサイクル管理については、一般的にはOSGiなどが知られており、ここでの説明は省略する。また、このアプリ管理部２０１は、管理しているアプリの種類の判定するための処理も行う。本実施例では、アプリの種類として、システムアプリ、ログインアプリ、後入れアプリがあることとする。ログインアプリは、ユーザが認証を行うためのアプリであり、操作部１０６でユーザが操作を行う際に最初にログイン画面を表示する。システムアプリは、画像形成装置１００にあらかじめ(工場出荷時から)インストールされていたアプリである。システムアプリとログインアプリのように工場でインストールされたアプリをプレインストールされたアプリケーションと呼ぶこともある。

また、後入れアプリは、ユーザが工場出荷後に画像形成装置１００にインストールしたアプリである。なお、ユーザが工場出荷後に画像形成装置１００にインストールしたアプリが認証を行うアプリである場合、このアプリの種類は、後入れアプリではなく、ログインアプリとする。なお本実施例では、システムアプリとログインアプリは、定期的にHDD１０４にアクセスしないことを工場出荷前に確認済みのアプリであることとする。近年の画像形成装置では、この後入れアプリのように、ユーザが用途に応じたアプリを画像形成装置にインストールし、動作させることが可能になっている。そのため、これらの後入れアプリの動作も含めて、HDDの限界時間を保証する(画像形成装置のサポート期間内にHDDの限界時間を越えないようにする)必要がある。

アプリ２１０〜２１２は、アプリ管理部２０１で管理され、画像形成装置１００で動作するアプリの一例である。ここでは、アプリ２１０がシステムアプリ、アプリ２１１とアプリ２１２が後入れアプリとする。

関数ライブラリ部２０２は、アプリ管理部２１０で管理しているアプリが処理を行うために呼び出す関数(メソッド含む)の集合である。具体的な処理としては、HDD１０４のファイルに対するアクセスやネットワーク通信等である。なおこの関数ライブラリ部２０２に含まれるHDD１０４のファイルにアクセスする関数は、後述のファイルドライバ部２０６を呼び出してHDD１０４にアクセスする。そしてさらに、後述のアクセス監視部２０３にHDD１０４のファイルへのアクセス処理の実行(以降、アクセス実行)を通知する。HDD１０４へのアクセス実行としては、読込処理のread()関数や書込処理のwrite()関数などがある。

アクセス監視部２０３は、アプリからの要求によるHDD１０４へのアクセス実行を監視するための処理を行う。具体的な処理としては、まず、画像形成装置１００がアクセスを監視する状態であるかどうかを判定する。そして、アクセスを監視する状態になっている場合は、アプリからのHDD１０４へのアクセス実行を、アクセス実行結果としてRAM１０２に記憶する。詳細は図３を参照して後述する。

第一のアクセス判定部２０４は、アクセス監視部２０３の情報を用いて、アプリ管理部２０１のアプリが定期的に(一定間隔で)HDD１０４にアクセスする第一のアプリであるかどうかを判定するための処理を行う。すなわち、第一のアクセス判定部は、後入れアプリのうちから第一のアプリを特定する。第一のアプリを、定期アクセスアプリケーションと呼ぶこともある。なお第一のアプリとは、HDD１０４に定期的にアクセスするアプリのことである。第一のアプリを判定するための詳細な処理は後述する。

第二のアクセス判定部２０５は、第一のアクセス判定部２０４により判定された第一のアプリが、想定外にHDDへのアクセスを増やす要因となる第二のアプリであるかを判定するための処理を行う。すなわち、第二のアクセス判定部は、第一のアプリのうちから第二のアプリを特定する。なお第二のアプリは、想定外定期アクセスアプリと呼ぶこともある。第二のアプリを判定するための詳細な処理は後述する。

ファイルドライバ部２０６は、HDD１０４上のファイルにアクセスするためのドライバであり、関数ライブラリ部２０２からの要求により、HDD１０４上のファイルにアクセスするための処理を行う。このドライバの処理は、一般的なLinux（登録商標）に含まれるドライバと同じであるため、詳細は省略する。

スリープ検知部２０７は、電源管理部１０９を用いて、画像形成装置１００がスリープ状態（すなわち省電力状態）であるかを判定するための処理を行う。なお、スリープ検知部２０７は、画像形成装置１００がスリープ状態から通常状態に復帰したことを判定するための判定も行い、画像形成装置１００がスリープ状態であるかどうかの情報をRAM１０２に記憶する。
以上が、モジュール構成図の説明である。

＜第二のアプリを特定するための処理＞
続いて、画像形成装置１００で動作するアプリ、特に後入れアプリの中から第二のアプリを特定するための処理の説明を、フローチャート図３を用いて説明する。図３のフローは、アクセス監視部２０３、第一のアクセス判定部２０４、第二のアクセス判定部２０５、スリープ検知部２０７により実行される。またこれらはすべてＣＰＵ１０１により実現される機能ブロックであるから、図３の手順はＣＰＵ１０１により実行されるということもできる。

●アクセス集計結果の作成処理
アプリからのHDDアクセス実行を受信した関数ライブラリ部２０２は、ファイルドライバ部２０６にHDDアクセス実行の要求を送信すると共に、アクセス監視部２０３にアプリによるHDDアクセス実行が行われたことを通知すると、図３の手順が開始される。関数ライブラリ部２０２からの通知を受信したアクセス監視部２０３は、画像形成装置１００がHDDアクセスを監視する状態になっているかを表す情報をRAM１０２から取得し、アクセスを監視するかどうかを判定する(ステップ３０１)。本実施例では、画像形成装置１００がアクセスを監視する状態とは、画像形成装置１００の操作部１０６でユーザが操作できない状態(以降、スリープ状態)である。ステップ３０１では、画像形成装置１００がスリープ状態であれば、アクセスを監視すると判断することとする。一方、画像形成装置１００がスリープ状態でない場合は、スリープ状態になるまで待つこととする。

画像形成装置１００がスリープ状態であるかどうかを表す情報は、スリープ検知部２０７によりRAM１０２に記憶されている、スリープ状態であるか否かを示す情報を取得することで判定する。なお、アクセスを監視する状態になっているかは別の方法により判定しても良い。このための別の方法としては、ユーザによる明示的なアクセス監視指示を受けた状態、もしくはアプリ管理部２０１により1つ以上のアプリが動作を開始した状態であれば、アクセスを監視すると判断しても良い。これにより、画像形成装置１００がスリープ状態にならない場合も監視を行うことが可能となる。

アクセス監視部２０３は、画像形成装置１００がHDDアクセスを監視する状態であると判断すると、このアクセスを実行したアプリが後入れアプリであるかどうかを判定する(ステップ３０２)。ここで、後入れアプリであるかどうかを判定する方法について説明する。本実施例では、アプリ管理部２０１のアプリがアクセスするHDD１０４のファイルは、他のアプリからアクセスすることができず、 アクセスするファイルパスから、アプリを一意に特定することができることとする。より詳細には、アプリがアクセスする全てのファイルは、アプリを特定するディレクトリ名の下に配置することで、アクセスするファイルパスからアプリを一意に特定できることとする。そのため、アクセス監視部２０３は、関数ライブラリ部２０２からの、アプリによるHDDアクセス実行が行われたことを示す通知にアクセス先のファイルのファイルパスを含めておく。この通知は、関数ライブラリ部２０２がファイルドライバ部２０６に送ったHDDアクセス実行の要求と同じものであってもよい。アクセス監視部２０３は通知に含まれたファイルパスからアプリを特定する。このイメージを図４で表す。

図４では、点線で囲ったディレクトリ名"1234"がアプリ1を表し、ディレクトリ名"1235"がアプリ2を表す。そのため、図４最下行のようにファイル名"Log2.log"に対するアクセスを行った場合、"Log2.log"の ファイルパスのディレクトリ名"1235"から、アプリ2によるファイルアクセスと特定できる。このようにしてHDDアクセスを要求したアプリの識別情報が特定されたなら、それがあらかじめ定めた後入れアプリの識別情報と照合し、一致しなければ後入れアプリと判定してよい。なお、後入れアプリであるかどうかを判定する別の方法としては、関数ライブラリ部２０２の関数を呼び出すときの引数にアプリの種類情報を付加し、この種類情報を関数ライブラリ部２０２からアクセス監視部２０３に送信することとしても良い。このようにしてアプリを特定した後、アクセス監視部２０３は、特定したアプリが後入れアプリであるかどうかをアプリ管理部２０１を用いて判定する。

アクセス監視部２０３は、関数ライブラリ部２０２からのHDDアクセスの実行を後入れアプリが行ったと判断すると、実行したアクセス処理の内容をRAM１０２にアクセス結果として記憶する(ステップ３０３)。実行したアクセス処理の内容は、受信した関数ライブラリ部２０２から受信した通知に含まれている。なお以降では、このアクセス結果を、アクセス結果ログと呼ぶこととする。ここでアクセス結果ログで記憶する情報としては、ファイル名を含むファイルパス、アクセス関数、アクセス関数を呼び出した時刻を含むこととする。ここでアクセス結果ログの具体例の説明を、図５(A)を用いて行う。

図５(A)は、10時(10:00:00)から10時3分(10:03:00)までのアクセス結果ログのイメージ図である。図５(A)のアクセス結果ログは、8回のアクセスを表している。なお図５(A)では説明の便宜上、8回のアクセス結果にそれぞれNo.1〜No.8の番号を付けている。アクセス結果ログの最初のログ(No.1のログ)は、ファイルパス"/yyyy/y1.log"というファイルに、書込み処理(write関数)を10時に実行したことを表す。なおここでは、"/yyyy/"というディレクトリは、後入れアプリYがアクセスするファイルのあるディレクトリであることとする。また同様に、"/xxxx/"というディレクトリは、後入れアプリXがアクセスするファイルのあるディレクトリであることとする。このようにアクセス結果ログに記録された情報からは、少なくともHDD１０４にアクセスしたアプリと、その時刻とを特定することができる。

以上がステップ３０３で記憶するアクセス結果ログの具体例の説明である。なお本実施例では、ステップ３０２とステップ３０３で、後入れアプリからのHDDアクセスのみ記憶した。これは、前述のようにシステムアプリとログインアプリはHDD１０４に定期的にアクセスすることがないためであり、これにより、ステップ３０３以降の処理を高速に行うことができる。一方、システムアプリもしくはログインアプリが定期的にHDDにアクセスするような場合は、ステップ３０２の判定処理を行わずに、ステップ３０３で全てのアプリのHDアクセスを記憶しても良い。

アクセス監視部２０３は、HDDアクセスを記憶した後、HDD１０４へのアクセス結果ログを解析するかどうかを判定する(ステップ３０４)。本実施例では、アクセス結果を解析するかどうかを判定する方法としては、画像形成装置１００が通常状態に戻っているかで判断することとする。具体的には、アクセス監視部２０３は、ステップ３０４でスリープ検知部２０７に対して画像形成装置１００が通常状態であるかを確認し、スリープ状態から通常状態に戻っていれば、アクセス結果を解析すると判断する。つまり、画像形成装置１００がスリープ状態の間のみ、アクセスを記憶することとする。なおアクセス結果ログを解析するかどうかの判定は別の方法でも良い。例えば、ユーザによる明示的なアクセス結果の解析指示を受けた状態もしくは、アクセスを監視してから一定時間経過した場合にアクセス結果を解析すると判断しても良い。解析を行わないと判定した場合には処理を終了する。この場合には、アクセス結果の解析を行う状態（すなわち電源の通常状態）に画像形成装置１００が遷移したことをきっかけとしてステップ３０５から処理が実行されてよい。状態の判定は状態遷移があったときに割り込みを発生させても行ってよいし、電源の状態をポーリングしてもよい。またステップ３０３でいったん処理を終了させてもよい。

アクセス監視部２０３は、HDD１０４へのアクセス結果を解析するとステップ３０４で判断すると、ステップ３０３で記憶したアクセス結果ログからアクセス集計結果ログを作成する(ステップ３０５)。このアクセス集計結果ログは、HDD１０４へのアクセス結果をわかりやすく表したものであり、後述の第一のアプリの特定に用いる。ここで、アクセス集計結果ログの具体例を、図５(b)を用いて説明する。図５(b)は、1時間にわたってステップ３０３でアクセスを記憶したアクセス結果ログの内容を集計したアクセス結果集計テーブル（あるいはアクセス結果集計情報）の一例である。このアクセス結果集計テーブルは、アプリ毎に、アクセス回数、最大間隔、平均間隔をまとめたものである。アクセス結果集計テーブルの説明の前に、いくつかの用語の説明を行う。

●用語説明
まず、アクセス間隔について説明する。アクセス間隔とは、HDD１０４のファイルに対するアクセスとその次のアクセスとの間の時間すなわち時間的に隣接したアクセスの時間間隔のことである。ただし、HDDのハードウエア的な動作の性質上、短時間に複数回のアクセスがあった場合、まとめて1回のアクセスと見なしても、HDDの限界時間には影響しない。そのため本実施例では、最初のアクセスと次のアクセスの間隔が短時間以内であれば、さらに次のアクセスまでのアクセス間隔を確認することで、短時間以内のアクセスをまとめることとする。すなわち、所定時間内に生じた複数のアクセスを一つのアクセスとみなしてよい。例えばこの短時間（所定時間）を15秒とする。図５(A)のNo.2のアクセスは10時30秒に行われ、次のNo.3のアクセスが10時34秒に行われている。この場合、アクセス間隔は4秒＜15秒のため、これら二つのアクセスを一つのアクセスとみなし、さらに次のアクセス(No.4)の時刻を確認する。No.4のアクセスは10時50秒に行われているため、No.3とNo.4のアクセスの間隔は16秒＞15秒である。そのため、No.4のアクセスは、その直前のアクセスとの時間間隔が、一つにまとめることができる短時間ではないと判断し、アクセス間隔は16秒とする。なおこのような判定を繰り返すと、15秒より短い間隔ですべてのアクセスが行われていると、それら全体で一つのアクセスと判定されることになる。そこで例えば、間隔の基準となるアクセスを、ひとつのアクセスとみなされる複数のアクセスのうちの最先のアクセスとしてもよい。そのようにすれば最先のアクセスから15秒以内のアクセスが一つのアクセスとみなされることになる。

次に、最大間隔について説明する。最大間隔とは、ある1つのアプリがアクセスする全てのファイルに対するアクセスを時系列順に参照し、あるアクセスと次のアクセスのアクセス間隔の中で最大(最長)のアクセス間隔のことである。すなわち最大間隔は、各アプリの最大のアクセス間隔のことである。例えば図5(A)のアプリYの場合、アクセスするファイルは"y1.log"と"y2.dat"である。そしてアクセス間隔は、No.1のアクセスから順に着目して、1分(No.1とNo5のアクセス間隔)、30秒(No.5とNo.6のアクセス間隔)、29秒(No.6とNo.7のアクセス間隔)、1分(No.7とNo.8のアクセス間隔)である。そのため、アプリYの最大間隔はそれらのうちの最大値である1分である。なお、アプリがアクセス可能なファイルに1回しかアクセスが無い場合、例外的にこのアプリのアクセス時間はあらかじめ定めた一定値より大きい値(例えば61分)とみなす。この一定値は、たとえば、後述する図３のステップ３０６において第一のアプリと判定する条件である。すなわちアクセス可能なファイルに1回しかアクセスが無いアプリについては、それが第一のアプリと判定されることのない属性や条件などを与えておけばよい。

最後に、平均間隔について説明する。平均間隔とは、ステップ３０１でアクセスの監視を開始してステップ３０４でアクセス結果の解析を開始するまでの時間を、アプリごとのアクセス回数で除算することで求めたアクセスの平均間隔である。すなわち平均間隔とは、各アプリの平均アクセス間隔のことである。なお、ここで用いたアプリのアクセス回数とは、あるアプリがアクセスする全てのファイルに対するアクセスの合計回数である。以上が、用語の説明である。

ここでは、ステップ３０５により図５(b)のアクセス結果集計テーブルを作成したこととする。図５(b)は、アプリXのアクセス回数が14回、最大間隔が5分、平均間隔が4.2分であることを表している。さらに図５(b)は、アプリYのアクセス回数が60回、最大間隔が１分、平均間隔が１分であることを表している。

以上が、アクセス集計結果ログ作成の処理の説明である。なお本実施例では、説明をわかりやすくするために、ステップ３０５でアクセス結果集計テーブルを作成したが、アクセス結果集計テーブルを生成せずに、アクセス集計ログを基に後述のステップ３０６〜３０７で第一のアプリを特定してもよい。
続いて、第一のアプリの特定処理の説明を行う。

●第一のアプリ(定期アクセスアプリ)の特定処理
第一のアプリの特定処理は、図３のステップ３０６、３０７を、アクセス結果集計テーブルに登録されたアプリのうち、アプリ管理部２０１で動作している全ての後入れアプリを対象として、アプリごとに順次着目して行うことで実現される。アクセス結果集計テーブルの作成後、アクセス監視部２０３は、第一のアクセス判定部２０４に第一のアプリの特定要求を送信する。これを受信した第一のアクセス判定部２０４は、アプリ管理部２０１で動作している全ての後入れアプリに対して、第一のアプリであるかどうかの判定を行う(ステップ３０６)。そして、アクセス監視部２０３は、第一のアプリであると判定したアプリを、このアプリを第一のアプリとみなす(ステップ３０７)。例えばアプリの識別情報と関連付けて、それが第一のアプリであることを示す情報をＲＡＭ１０２等に記憶すればよい。さらに、第一のアプリについては、その最大間隔も定期アクセス間隔としてアプリに関連付けて記憶しておく。第一のアプリであるかどうかの判定には、ステップ３０５で作成したアクセス結果集計テーブルの最大間隔を用いる。具体的には、第一のアプリの最大間隔が一定の値以下であるかを判定する。例えば図５(b)の場合、一定値を60分とすると、アプリXは最大間隔が5分であるため第一のアプリであり、アプリYは最大間隔が1分のため第一のアプリと判定する。そして、この最大間隔をアプリの定期アクセス間隔とする。具体的には、アプリXの定期アクセス間隔を1分、アプリYの定期アクセス間隔を5分とする。なお本実施例では、第一のアプリの判定やアプリの定期アクセス間隔の決定に最大間隔を用いるが、アプリの平均間隔を用いても良い。この場合には、平均間隔を定期アクセス間隔としてアプリに関連付けて記憶しておく。

なお図３において、ステップ３０６とステップ３０７とを挟む六角形のブロックは、すべての後入れアプリについてステップ３０６とステップ３０７とを繰りかえすことを示す。以上が、第一のアプリ特定の処理の説明である。続いて、第二のアプリの特定処理の説明を行う。

●第二のアプリ(想定外定期アクセスアプリ)の特定処理
第一のアクセス判定部２０４は、第一のアプリを特定すると、第二のアクセス判定部２０５に、第二のアプリの特定要求を送信する。第二のアプリの特定要求が送信されたとき、第一のアプリを特定するための情報とそれぞれの定期アクセス間隔とを含む第一のアプリ情報があらかじめ定めた記憶場所に記憶されているか、あるいは第一のアプリ情報そのものやそれを特定するための情報が第二のアクセス判定部２０５に引き渡される。第二のアプリの特定要求を受信した第二のアクセス判定部２０５は、まず基準間隔を取得する(ステップ３０８)。なお、この基準間隔は、本実施例ではあらかじめROM１０３に記憶しておくこととするが、HDD１０４の限界時間までの残時間とこれまでの累積動作時間から算出しても良い。

ここで、基準間隔の説明を行う。基準間隔は、画像形成装置１００のサポート期間内にHDD１０４が限界時間を越えないために、アプリがHDDアクセス１０４にアクセスして問題のないアクセス間隔である。そのため、アプリ管理部２０１で動作中の全アプリのHDD１０４へのアクセスの平均が、この基準間隔よりも長い間隔になっている場合、このままの状態で動作し続けても、画像形成装置のサポート期間内にHDDの限界時間を越えない。しかし逆に、アプリ管理部２０１で動作中の全アプリのHDD１０４へのアクセスの平均が、基準間隔よりも短い間隔になっている場合、このままの状態では画像形成装置１００のサポート期間内にHDD１０４は限界時間を越えてしまう。ここで図６を用いて、具体例を説明する。図６は、アプリ１のアクセスを実線の矢印で表し、アプリ２のアクセスを点線で表している。また、アクセスとアクセスの間の数字は、アクセス間隔を表している。また、これらのアプリ１とアプリ２のアクセスをまとめたアクセスを"全アプリのアクセス"に表している(アクセス間隔の記載は非表示)。アプリ１のアクセスは３分間隔で６回であり、アプリ２のアクセスは６分間隔で３回であることを表している。そのため、全アプリのアクセスは、15分間に9回となる。図６の場合、HDD１０４へのアクセス15分間で9回のため全アプリの平均のアクセス間隔は15分/8≒2分である。そのため、基準間隔が3分であると、このままの状態では、画像形成装置１００のサポート期間内にHDD１０４が限界時間を越えてしまう。以上が具体例を用いた基準間隔の説明である。

図３に戻ると、ステップ３０８で基準間隔を取得した第二のアクセス判定部２０５は、前記第一のアクセス判定部２０４で特定した第一のアプリの数を基に、各アプリの第一のアクセス間隔を決定する(ステップ３０９)。この第一のアクセス間隔とは、想定外のHDD故障を引き起こさないために、各アプリのアクセスをこの間隔以上の時間にする必要がある間隔である。すなわち第一のアクセス間隔とは、各アプリの最低アクセス間隔のことである。たとえば、基準間隔に第一のアプリの数を乗ずることで第一のアクセス間隔を得ることができる。第一のアクセス間隔は、アプリケーションに許容されたアクセスの時間間隔（許容間隔とも呼ぶ）ともいえる。

第一のアクセス間隔を決定した後、第二のアクセス判定部２０５は、全ての第一のアプリに対して、各アプリの定期アクセス間隔は前述の第一のアクセス間隔よりも短いかどうかを判定する(ステップ３１０)。そして、第二のアクセス判定部２０５は、ステップ３１０の判定で短いと判定したアプリを、第二のアプリとして特定する(ステップ３１１)。そして第二のアクセス判定部２０５は、ステップ３１１で特定した全ての第二のアプリを、あらかじめROM１０３に記憶されている通知先にネットワーク部１０７もしくは操作部１０６を用いて通知する(ステップ３１２)。ここで、図３において、ステップ３１０およびステップ３１１をはさむ六角形のブロックは、ステップ３１０およびステップ３１１を全ての第一のアプリを対象として繰り返し実行することを意味している。次にステップ３０８〜ステップ３１１で第二のアプリを特定する処理の具体例を説明する。

まず、第一のアプリが1つの場合の具体例として、ステップ３０７で特定した第一のアプリが図５(B)のアプリXのみである場合を説明する。なお、ステップ３０８で取得した基準間隔は3分とする。第二のアクセス判定部２０５は、第一のアプリの数が1であり、基準間隔は3分のため、各アプリの第一のアクセス間隔を3分(3分×1アプリ)に決定する(ステップ３０９)。続いて第二のアクセス判定部２０５は、後入れアプリXの定期アクセス間隔が、第一のアクセス間隔よりも短いかどうかを判定する(ステップ３１０)。アプリXの定期アクセス間隔は本例では最大アクセス間隔の5分であり、第一のアクセス間隔は3分であるため、ステップ３１０の判定により長い（Ｎｏ）と判定する。そのため、アプリXは第二のアプリと特定されない。

次に、第一のアプリが2つの場合の具体例として、ステップ３０７で特定した第一のアプリが、図５(B)のアプリXとアプリYである場合を説明する。なお、ステップ３０８で取得した基準間隔は3分とする。第二のアクセス判定部２０５は、第一のアプリの数が2であり、基準間隔は3分のため、第一のアクセス間隔を6分(3分×2アプリ)に決定する(ステップ３０９)。続いて第二のアクセス判定部２０５は、後入れアプリXの定期アクセス間隔が、第一のアクセス間隔よりも短いかどうかを判定する(ステップ３１０)。アプリXの定期アクセス間隔は5分であり、第一のアクセス間隔は6分であるため、ステップ３１０の判定により短いと判定する。そのため、アプリXは第二のアプリであると特定される(ステップ３１１)。続いて、ステップ３１０でアプリYの判定を行う。アプリYの定期アクセス間隔は1分であり、第一のアクセス間隔は6分であるため、ステップ３１０の判定により短いと判定する。そのため、アプリYは第二のアプリであると特定される(ステップ３１１)。

以上が第二のアプリの特定処理の具体例の説明であり、これでフローチャート図３の説明を終える。

本実施形態により、想定外にHDDアクセスを増やす要因（特にアプリ）の有無を判断することができる。それだけではなく、想定外にHDDアクセスを増やす要因となる第二のアプリを特定することができる。これにより、特定したアプリに関する情報を画像形成装置１００の管理者やサービスマンに連絡を行い、HDD故障前にHDDを交換することが可能となり、管理者やサービスマンの保守コストを減らすことができる。さらに、ユーザ視点でも、画像形成装置１００のHDD１０４に記憶されたユーザのデータを守ると共に、ユーザが画像形成装置１００を利用できない時間を減らすことで操作性の低下を防ぐこともできる。また、本実施例形態により特定したアプリに対して、修正を行うもしくは特定したアプリを停止する等の運用条件を変えることで、今後同じ要因でHDD１０４が故障することを防ぐことも可能となる。

［第２の実施形態］
第１の実施形態により想定外にHDDアクセスを増やす要因となる第二のアプリを特定できる。ここで特定した第二のアプリを修正もしくは動作を停止する等の対策を行うため、ユーザがアプリや画像形成装置１００を使用できないことが起こりえる。これによりユーザの操作性を低下する可能性がある。そのため、最小限のアプリのみを第二のアプリとして特定したいという要望もある。

そこで、本実施例では、最小限の第二のアプリを特定するための実施形態を、フローチャート図７を用いて説明する。なお、基本的な処理や制御は第１の実施形態と同じであるため、第１の実施形態と異なる点のみを説明する。

ステップ３０１〜ステップ３１０の処理は第1の実施形態と同じであるため、説明は省略する。ステップ３１０において、アプリの定期アクセス間隔が各アプリの第一のアクセス間隔よりも短いと判断すると、第二のアクセス判定部２０５は、このアプリを第二のアプリ候補と特定する(ステップ７０１)。そしてすべての第一のアプリに対してステップ３１０とステップ７０１を実行する。これにより、第一のアプリから第二のアプリ候補が抽出される。この後、第二のアクセス判定部２０５は、第二のアプリ候補が存在しないかどうかを判定する(ステップ７０２)。ここで、第二のアプリ候補が存在しない場合は、後述のステップ７０４で特定した第二のアプリを、第1の実施形態と同じく通知する(ステップ３１２)。なお、第二のアプリ候補が存在しない場合(ステップ７０４に一度も到達しない場合)は、ステップ７０１で特定した第二のアプリ候補を第二のアプリとして通知することとする。あるいは、第二のアプリがない旨を通知してもよい。

一方、ステップ７０２で第二のアプリ候補が存在する場合は、第二のアプリ候補の中で最小の定期アクセス間隔のアプリを特定する(ステップ７０３)。そして第二のアクセス判定部２０５は、ステップ７０３で特定した第二のアプリ候補を第二のアプリと特定し、第二のアプリ候補と第一のアプリとから、この特定した第二アプリを除外する(ステップ７０４)。そして第二のアクセス判定部２０５は、再度ステップ３０９のアプリの第一のアクセス間隔の決定に戻る。ステップ３０９では、定期アクセス間隔が最小のアプリを除外した第一のアプリに基づいて第一のアクセス間隔を再決定する。すなわち、前回第一のアクセス間隔を決定した時よりも、アプリの数が一つ減っているので、第一のアクセス間隔は前回の値よりも小さくなる。このようにして第二のアプリ候補の中で、定期アクセス間隔が短いアプリから順に第二のアプリとして特定し、第二のアプリを特定する都度、第一のアクセス間隔を短縮する。それにより、第二のアプリを特定する都度、第一のアプリを特定する条件が狭まり、第一のアプリが特定されにくくなる。この結果第一のアプリの数が減少し、ひいては第二のアプリの数も減少することが期待できる。

この具体例を説明する。なおステップ３０７により、図５(B)の定期アクセス間隔5分の第一のアプリXと、定期アクセス間隔1分の第一のアプリYを特定していることとする。また、ステップ３０８で取得する基準間隔は3分とする。第二のアクセス判定部２０５は、ステップ３１０でアプリの定期アクセス間隔が第一のアクセス間隔よりも短いアプリを第二のアプリ候補として特定する(ステップ７０１)。ここでは、アプリXとアプリYが第二のアプリ候補と特定できる。この後、第二のアクセス判定部２０５は、第二のアプリ候補が存在しないかどうかを判定する(ステップ７０２)。ここではアプリXとアプリXが存在するため、定期アクセス間隔が最小のアプリの特定に進む(ステップ７０３)。アプリXの定期アクセス間隔は5分であり、アプリYの定期アクセス間隔は1分であるため、ステップ７０３ではアプリYを特定する。そしてこのアプリYを第二のアプリと見なし、さらにアプリYを第二のアプリ候補と第一のアプリから除外する(ステップ７０４)。そしてステップ３０９に戻る。ステップ３０９では、第一のアプリはXのみであるため、アプリの第一のアクセス間隔は3分と決定する(ステップ３０９)。そして第1の実施形態と同じく、ステップ３１０で判定を行うと、アプリXの定期アクセス間隔は5分であるため、アプリXは第二のアプリ候補ではなくなる(ステップ３１０でNOになる)。そのため、ステップ７０２の判定で第二のアプリ候補はなくなり(ステップ７０２がYES)、ステップ３１２で通知する第二のアプリはアプリYのみとなる。以上が、第２の実施形態の説明である。

第２の実施形態により、第1の実施形態よりも特定する第二のアプリの数を減らすことができる。これにより修正する修正もしくは動作を停止するアプリの数を減らすことで、ユーザがアプリを使用できないことや画像形成装置１００を使用できないことによるユーザの操作性の低下を防ぐことが可能となる。

［その他の実施例］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１０１ CPU、 １０２ RAM、 １０３ ROM、 １０４ HDD

Claims (12)

1. 記憶ユニットにアクセスするアプリケーションを実行可能な情報処理装置であって、
   前記記憶ユニットに対するアプリケーションごとのアクセスを監視するアクセス監視手段と、
   前記アクセス監視手段により監視したアプリケーションごとのアクセスの時間間隔に基づいて、前記記憶ユニットに定期的にアクセスしている定期アクセスアプリケーションを特定する第一のアプリケーションの特定手段と、
   前記定期アクセスアプリケーションの数と、前記記憶ユニットに対するアクセスの基準の時間間隔である基準間隔とに基づいて、一つの定期アクセスアプリケーションに許容されるアクセスの時間間隔である許容間隔を決定する決定手段と、
   前記定期アクセスアプリケーションのうちから、前記許容間隔よりも短い時間間隔で前記記憶ユニットにアクセスしているアプリケーションを、前記記憶ユニットの動作時間を長くするアプリケーションとして特定する第二のアプリケーションの特定手段と
   を有することを特徴とする情報処理装置。
2. 請求項１に記載の情報処理装置であって、
   前記第二のアプリケーションの特定手段により特定した前記アプリケーションを示す情報を出力する出力手段をさらに有することを特徴とする情報処理装置。
3. 請求項２に記載の情報処理装置であって、
   前記出力手段は、前記第二のアプリケーションの特定手段により特定した前記アプリケーションを示す情報を、あらかじめ決められた通知先に通知することを特徴とする情報処理装置。
4. 請求項１または２に記載の情報処理装置であって、
   前記アクセス監視手段は、前記情報処理装置が省電力モードである場合に、前記アクセスを監視することを特徴とする情報処理装置。
5. 請求項１乃至４のいずれか一項に記載の情報処理装置であって、
   前記第二のアプリケーションの特定手段により特定したアプリケーションのうち、アクセスの時間間隔が最小のアプリケーションを除いたアプリケーションの数と前記基準間隔とに基づいて前記許容間隔を再決定し、前記再決定された許容間隔よりも短い時間間隔で前記記憶ユニットにアクセスしているアプリケーションを前記記憶ユニットの動作時間を長くするアプリケーションとして特定する第三のアプリケーションの特定手段をさらに有することを特徴とする情報処理装置。
6. 請求項１乃至５のいずれか一項に記載の情報処理装置であって、
   前記第一のアプリケーションの特定手段は、前記監視手段により監視された前記アプリケーションごとの前記アクセスの時間間隔のうちで最長の時間間隔が所定時間より短いアプリケーションを前記定期アクセスアプリケーションとして特定することを特徴とする情報処理装置。
7. 請求項１乃至５のいずれか一項に記載の情報処理装置であって、
   前記第一のアプリケーションの特定手段は、前記監視手段により監視された前記アプリケーションごとの前記アクセスの時間間隔の平均の時間間隔が所定時間より短いアプリケーションを前記定期アクセスアプリケーションとして特定することを特徴とする情報処理装置。
8. 請求項１乃至７のいずれか一項に記載の情報処理装置であって、
   前記決定手段は、前記基準間隔に前記定期アクセスアプリケーションの数を乗じた値を前記許容間隔として決定することを特徴とする情報処理装置。
9. 請求項１乃至８のいずれか一項に記載の情報処理装置であって、
   前記アクセス監視手段は、前記記憶ユニットに定期的にアクセスしない所定のアプリケーションを除くアプリケーションを対象としてアクセスを監視することを特徴とする情報処理装置。
10. 請求項１乃至９のいずれか一項に記載の情報処理装置であって、
    前記記憶ユニットはハードディスク装置を含むことを特徴とする情報処理装。
11. 記憶ユニットにアクセスするアプリケーションを実行可能な情報処理装置の制御方法であって、
    アクセス監視手段が、前記記憶ユニットに対するアプリケーションごとのアクセスを監視するアクセス監視工程と、
    第一のアプリケーションの特定手段が、前記アクセス監視工程により監視したアプリケーションごとのアクセスの時間間隔に基づいて、前記記憶ユニットに定期的にアクセスしている定期アクセスアプリケーションを特定する第一のアプリケーションの特定工程と、
    決定手段が、前記定期アクセスアプリケーションの数と、前記記憶ユニットに対するアクセスの基準の時間間隔である基準間隔とに基づいて、一つの定期アクセスアプリケーションに許容されるアクセスの時間間隔である許容間隔を決定する決定工程と、
    第二のアプリケーションの特定手段が、前記定期アクセスアプリケーションのうちから、前記許容間隔よりも短い時間間隔で前記記憶ユニットにアクセスしているアプリケーションを、前記記憶ユニットの動作時間を長くするアプリケーションとして特定する第二のアプリケーションの特定工程と
    を有することを特徴とする情報処理装置の制御方法。
    
12. 記憶ユニットにアクセスするアプリケーションを実行可能な情報処理装置を、
    前記記憶ユニットに対するアプリケーションごとのアクセスを監視するアクセス監視手段と、
    前記アクセス監視手段により監視したアプリケーションごとのアクセスの時間間隔に基づいて、前記記憶ユニットに定期的にアクセスしている定期アクセスアプリケーションを特定する第一のアプリケーションの特定手段と、
    前記定期アクセスアプリケーションの数と、前記記憶ユニットに対するアクセスの基準の時間間隔である基準間隔とに基づいて、一つの定期アクセスアプリケーションに許容されるアクセスの時間間隔である許容間隔を決定する決定手段と、
    前記定期アクセスアプリケーションのうちから、前記許容間隔よりも短い時間間隔で前記記憶ユニットにアクセスしているアプリケーションを、前記記憶ユニットの動作時間を長くするアプリケーションとして特定する第二のアプリケーションの特定手段と
    して機能させるためのプログラム。

Images