JP2009146323A - Ｃｐｕ資源管理装置とその方法 - Google Patents

Abstract

【課題】追加アプリの動作検証を比較的短時間で行うことが可能なＣＰＵ資源管理装置とその方法を実現すること。
【解決手段】優先度の高い既存アプリを動作させながら優先度の低い追加アプリの動作を検証するのにあたり、既存アプリの各動作周期について実際のＣＰＵ使用時間に基づき所定の最大ＣＰＵ使用時間に満たない時間だけＣＰＵに負荷を発生させるＣＰＵ負荷発生部を設け、前記既存アプリの各動作周期について既存アプリの最大ＣＰＵ使用時間を確保することを特徴とするもの。
【選択図】 図１

Description

本発明は、ＣＰＵ資源管理装置とその方法に関し、詳しくは、新しく追加するアプリケーション（以下、アプリという）が正常動作するか否かを比較的短時間で検証できる装置とその方法に関するものである。

従来から、センサ、コントローラなどのフィールド機器やその他電子機器において、機能拡張や補充のために新たなアプリを追加するのにあたっては、既に実装されていたアプリ（以下、既存アプリという）の動作を従来どおりに継続させつつ、新たに追加するアプリ（以下、追加アプリという）も正常に動作させるべくＣＰＵ（Central Processing Unit）の資源管理が行われている。

従来の追加アプリを実装する場合におけるＣＰＵ資源を管理する電子機器およびその方法に関連する先行技術文献としては次のようなものがある。

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

ところで、従来のＣＰＵ資源を管理する電子機器およびその方法では、実装された複数のアプリに対して優先度を設定して最も優先度が高いアプリにＣＰＵを使用させる「優先度制御」の方式が利用されている。

図７は、従来のＣＰＵ資源管理機能を有する電子機器の構成ブロック図である。フィールド機器１はプラントに設置されていて、データを伝送する通信機能や、ＡＩ（アナログ信号入力）、ＡＯ（アナログ信号入出力）、ＰＩＤ演算（比例、積分、微分演算）などのフィールド機器固有の機能ブロックを実行する機能と、ＣＰＵ資源を管理するＣＰＵ資源管理機能を有している。

フィールド機器１は、ＣＰＵ１１とフィールド機器１に既に配備されフィールド機器固有の機能ブロックを実行するための既存アプリ１２とで構成されている。ＣＰＵ１１は、演算制御部として動作するものであり、図示しないＯＳ（Operation System）を起動してプログラムを実行することによりフィールド機器１全体を制御し、ＣＰＵ資源の割り当てを行う。

図７において、ＣＰＵ１１にはフィールド機器１の機能拡張や補充のために追加アプリ１３が実装され、ＣＰＵ１１は、ＯＳが提供する優先度制御機能を利用して追加アプリ１３の優先度を既存アプリ１２の優先度よりも低く設定しているものとする。

これにより、ＣＰＵ１１は、各アプリ１２〜１３に設定された優先度に基づき優先度の高い既存アプリ１２が優先的にＣＰＵを使用できるように制御し、優先度の高い既存アプリ１２がｗａｉｔ状態などによってＣＰＵ１１を使用しない場合は優先度の低い追加アプリ１３がＣＰＵ１１を使用できるように制御する。

このように従来のＣＰＵ資源を管理する電子機器では、優先度の低い追加アプリ１３が実装された場合であっても、優先度の高い既存アプリ１２は従来通りの動作を継続することができる。

ところで、優先度の高い既存アプリ１２の単位時間あたりのＣＰＵ使用率は、フィールド機器への入力などに依存して変動することがあり、常に一定とは限らない。たとえば既存アプリ１２が一定期間連続してあらかじめ割り当てられている最大ＣＰＵ使用時間で動作すると、この影響を受けて優先度の低い追加アプリ１３が正常動作しない場合もある。

そこで、追加アプリ１３が正常動作するか否かを検証するためには、既存アプリ１２に対して単位時間あたりにあらかじめ割り当てられている最大ＣＰＵ使用時間を確保しながら、既存アプリ１２と追加アプリ１３の両方を連続稼動させることが望ましい。

しかしながら、ただ単に既存アプリ１２と追加アプリ１３の両方をＣＰＵ１１に実装した状態で連続稼動させた場合には、前述のように既存アプリ１２の単位時間あたりのＣＰＵ使用率はフィールド機器への入力等に依存して変動することから、常にあらかじめ割り当てられている最大ＣＰＵ使用時間になるとは限らない。

すなわち、検証時間が短い場合には、既存アプリ１２が最もＣＰＵを使用する最も過酷な状況下での追加アプリ１３の動作検証が行われない不十分な条件で終了することも考えられる。したがって、このように不十分な条件での検証に終わらせないためには、検証時間を比較的長くとらなければならないという問題点があった。

本発明は上述の問題点を解決するものであり、その目的は、既存アプリの単位時間あたりのＣＰＵ使用率を常にあらかじめ割り当てられている最大ＣＰＵ使用時間に設定して、追加アプリの動作検証を比較的短時間で行えるＣＰＵ資源管理装置とその方法を実現することにある。

このような課題を達成するために、本発明のうち請求項１記載の発明は、
実装された複数のアプリに優先度を設定し、最も優先度が高いアプリにＣＰＵを使用させるように構成されたＣＰＵ資源管理装置において、
優先度の高い既存アプリを動作させながら優先度の低い追加アプリの動作を検証するのにあたり、既存アプリの各動作周期について実際のＣＰＵ使用時間に基づき所定の最大ＣＰＵ使用時間に満たない時間だけＣＰＵに負荷を発生させるＣＰＵ負荷発生部を設け、
前記既存アプリの各動作周期について既存アプリの最大ＣＰＵ使用時間を確保することを特徴とする。

請求項２記載の発明は、
請求項１記載のＣＰＵ資源管理装置において、
前記追ＣＰＵ負荷発生部は、
既存アプリの動作周期と動作周期あたりの最大ＣＰＵ使用時間を含む既存アプリ情報を記憶する既存アプリ情報テーブルと、
この既存アプリ情報テーブルに記憶された既存アプリ情報に基づき、既存アプリの各動作周期について実際のＣＰＵ使用時間に基づき所定の最大ＣＰＵ使用時間に満たない時間を計算する負荷計算処理部と、
この負荷計算処理部の計算結果に基づき、前記既存アプリの最大ＣＰＵ使用時間に満たない時間だけＣＰＵに負荷を発生させる負荷発生処理部、
で構成されることを特徴とする。

請求項３記載の発明は、
請求項１または請求項２記載のＣＰＵ資源管理装置において、
複数の既存アプリが実装されている場合は、
これら既存アプリの動作周期の最小公倍数およびこの動作周期の最小公倍数あたりにおける各既存アプリの最大ＣＰＵ使用時間の合計を算出し、各既存アプリの動作周期の最小公倍数あたりにおける実際のＣＰＵ使用時間の合計が前記算出した既存アプリの最大ＣＰＵ使用時間に満たない時間だけＣＰＵに負荷を発生させることを特徴とする。

請求項４記載の発明は、
請求項１から請求項３のいずれかに記載のＣＰＵ資源管理装置において、
ＣＰＵ資源管理装置はフィールド機器として構成されていることを特徴とする。

請求項５記載の発明は、
実装された複数のアプリに優先度を設定し、最も優先度が高いアプリにＣＰＵを使用させるＣＰＵ資源管理方法において、
優先度の高い既存アプリを動作させながら優先度の低い追加アプリの動作を検証するのにあたり、
既存アプリの動作周期と動作周期あたりの最大ＣＰＵ使用時間を含む既存アプリ情報に基づき既存アプリの各動作周期について実際のＣＰＵ使用時間に基づき所定の最大ＣＰＵ使用時間に満たない時間を求める第１のステップと、
第１のステップで求めた既存アプリの最大ＣＰＵ使用時間に満たない時間だけＣＰＵに負荷を発生させる第２のステップ、
を含むことを特徴とする。

請求項６記載の発明は、
請求項５記載のＣＰＵ資源管理方法において、
前記ＣＰＵ資源管理方法は、フィールド機器として構成された電子機器を対象とすることを特徴とする。

本発明によれば、ＣＰＵ資源管理装置は、既存アプリの各動作周期における最大ＣＰＵ使用時間を補償するので追加アプリの動作検証を比較的短時間で行うことができる。

また、本発明によれば、ＣＰＵ資源管理装置は、既存アプリの各動作周期単位であらかじめ割り当てられている既存アプリの最大ＣＰＵ使用時間を確保した残り時間で追加アプリの動作検証を行うので最も過酷な状況下で行うことになり、十分な条件での動作検証を比較的短時間で行うことができる。

また、本発明によれば、ＣＰＵ資源管理装置は、動作検証に必要な時間を制御するのにあたり、既存アプリと追加アプリの動作周期の長短に関連して、既存アプリが追加アプリよりも長いかまたは等しい場合には、既存アプリの動作周期１回分の時間で行うことができる。また、既存アプリが追加アプリよりも短い場合には、追加アプリの動作周期１回分の時間で行うことができる。

また、本発明によれば、ＣＰＵ資源管理装置は、ＣＰＵ負荷発生部の優先度が既存アプリよりも低く設定していることにより、既存アプリの処理を中断させることはなく、かつ、ＣＰＵ負荷発生部は既存アプリの外部にあるため、既存アプリを変更することなく既存アプリの運用中に追加アプリの動作検証を行うことができる。

また、本発明によれば、ＣＰＵ資源管理装置は、既存アプリの動作周期内にスリープを繰り返して既存アプリの動作状態を把握して既存アプリのＣＰＵ使用時間の合計が最大ＣＰＵ使用時間に満たない時間だけＣＰＵ負荷を発生させるので、既存アプリがＣＰＵを使用するタイミングに依存することなく各動作周期あたりの最大ＣＰＵ使用時間を確実に確保して補償できる。

図１は、本発明に係るＣＰＵ資源管理機能を有する電子機器などのＣＰＵ資源管理装置の一実施例を示す構成ブロック図であり、フィールド機器を例示している。フィールド機器２はプラントに設置されていて、データを伝送する通信機能や、ＡＩ（アナログ信号入力）、ＡＯ（アナログ信号入出力）、ＰＩＤ演算（比例、積分、微分演算）などのフィールド機器固有の機能ブロックを実行する機能と、追加アプリの動作検証を行う検証機能を有している。

フィールド機器２は、ＣＰＵ２１と、ＣＰＵ負荷発生部２２と、既に実装されているフィールド機器固有の機能ブロックを実行するための既存アプリ２３と、ＣＰＵ２１により機能拡張や補充のため新たに実装される追加アプリ２４とから構成される。

ＣＰＵ２１は、演算制御部として動作するものであり、図示しないＯＳを起動してプログラムを実行することによりフィールド機器２全体を制御し、追加アプリ２４の動作検証を行うとともに、ＣＰＵ負荷発生部２２、既存アプリ２３、追加アプリ２４にそれぞれ優先度を設定する。

ＣＰＵ負荷発生部２２は、既存アプリ２３の動作周期(単位時間)と同じ周期で動作して既存アプリ２３のＣＰＵ使用時間を取得し、単位時間あたりにおける既存アプリ２３のＣＰＵ使用時間の合計が最大ＣＰＵ使用時間に満たない場合には、その差分時間のＣＰＵ負荷を発生させる。

なおＣＰＵ２１は、ＯＳが提供する優先度制御機能を利用してＣＰＵ負荷発生部２２、既存アプリ２３および追加アプリ２４にそれぞれ優先度を設定するのにあたり、ＣＰＵ負荷発生部２２は既存アプリ２３(高優先度)よりも低くて追加アプリ２４よりも高く(中優先度)、追加アプリ２４は既存アプリ２３よりも低く設定する(低優先度)。

また、既存アプリ２３の動作周期と動作周期あたりの最大ＣＰＵ使用時間などの「既存アプリ動作情報」は、あらかじめ定められている既知の情報であり、既存アプリ２３はこの既存アプリ動作情報に反した動作はしないものとする。

図２は、図１のＣＰＵ負荷発生部２２の機能ブロック図である。ＣＰＵ負荷発生部２２は、既存アプリ情報テーブル２２Ａと、負荷計算処理部２２Ｂと、負荷発生処理部２２Ｃとから構成される。

図３は、図２の既存アプリ情報テーブル２２Ａが記憶するデータの一例を示す説明図である。図３の例では、既存アプリ情報テーブ２２Ａは、既存アプリ２３の動作周期が1000msec、動作周期1000msecあたりの最大ＣＰＵ使用時間が600msecである既存アプリ動作情報を記憶している。

負荷計算処理部２２Ｂは、既存アプリ２３のＣＰＵ使用時間を取得し、ＣＰＵ使用時間の合計が最大ＣＰＵ使用時間に満たないと判断した場合はその結果を負荷発生処理部２２Ｃに通知する。なお、既存アプリ２３のＣＰＵ使用時間を取得する方法については限定するものではなく、たとえばＯＳがＬｉｎｕｘの場合であれば、ＰｒｏｃファイルシステムからＣＰＵ使用時間を取得すればよい。

負荷発生処理部２２Ｃは、たとえばｗａｉｔ無しでループ処理を行うことによりＣＰＵを使い続ける処理を実行し、必要な時間に応じたＣＰＵ負荷を発生する。

図２のＣＰＵ負荷発生部２２の動作を説明する。負荷計算処理部２２Ｂは、既存アプリ情報テーブル２２Ａから既存アプリ情報を読み込み、以下の式（１）で既存アプリ２３の動作周期内における「１回目のスリープ時間」を算出する（ステップＳＰ１）。
１回目のスリープ時間＝動作周期−動作周期あたりの最大ＣＰＵ使用時間・・・（１）

いいかえれば負荷計算処理部２２Ｂは、既存アプリ２３が動作周期あたりＣＰＵ２１を使用しない「最小ＣＰＵ未使用時間」を算出する。

負荷計算処理部２２Ｂは、算出した１回目のスリープ時間（最小ＣＰＵ未使用時間）だけスリープする（ステップＳＰ２）。

負荷計算処理部２２Ｂは、１回目のスリープ終了後、１回目のスリープ中に発生した既存アプリ２３のＣＰＵ使用時間を取得し、その時間だけ２回目のスリープを行う。また、２回目のスリープを終えると、２回目のスリープ中に発生した既存アプリ２３のＣＰＵ使用時間を取得し、その時間だけ３回目のスリープを行う。以下、同様のスリープ処理を繰り返す。ただし、以下の条件Ａまたは条件Ｂが満たされた場合は繰り返し処理を終了し、ステップＳＰ２またはＳＰ４に移行する（ステップＳＰ３）。

条件Ａ（ＣＰＵ負荷の発生を必要としない場合）：Ｎ(Ｎ＞＝１)回全てのスリープ中の既存アプリ２３のＣＰＵ使用時間の合計が、既存アプリ動作情報の最大ＣＰＵ使用時間に達した場合は、次の動作周期までスリープしてステップＳＰ２へ戻る。
条件Ｂ（ＣＰＵ負荷の発生を必要とする場合）：Ｎ(Ｎ＞＝１)回目のスリープ中の既存アプリ２３のＣＰＵ使用時間が０であった場合は、ステップＳＰ４に移行する。

負荷発生処理部２２Ｃは、負荷計算処理部２２Ｂの計算結果に基づき、次の動作周期までＣＰＵ負荷を発生し続ける（ステップＳＰ４）。その後、ステップＳＰ２へ戻る。

このとき、ＣＰＵ負荷を発生している間に既存アプリ２３がＣＰＵ２１を使用する場合は、既存アプリ２３の優先度より優先度の低いＣＰＵ負荷発生部２２の処理（ＣＰＵ負荷の発生処理）が中断され、既存アプリ２３はＣＰＵ２１を使用する。

つまり、負荷発生処理部２２Ｃは、負荷計算処理部２２Ｂの計算結果に基づき、既存アプリ２３のＣＰＵ使用時間の合計があらかじめ定められた最大ＣＰＵ使用時間に満たない時間だけＣＰＵ負荷を発生することになる。

図４は図１のＣＰＵ負荷発生部２２、既存アプリ２３、追加アプリ２４のＣＰＵ使用状態を説明する説明図である。図４を用いて上記ステップＳＰ１〜ステップＳＰ４の処理を具体的に説明する。図４では、既存アプリ２３の動作周期は1000msec、動作周期あたりの最大ＣＰＵ使用時間600msecである。

ステップＳＰ１において、負荷計算処理部２２Ｂは、既存アプリ２３の動作周期（1000msec）内における「１回目のスリープ時間（400msec）」を以下の式（２）に示すように算出する。
１回目のスリープ時間(msec)＝動作周期−動作周期あたりの最大ＣＰＵ使用時間
＝1000-600
＝400・・・（２）

ステップＳＰ２において、ＣＰＵ負荷発生部２２は、400msecだけ（図４のＰ０〜Ｐ１の時間帯）１回目のスリープを行う。

ステップＳＰ３において、負荷計算処理部２２Ｂは、図４のＰ１の時点で１回目のスリープ中に発生した既存アプリ２３のＣＰＵ使用時間が200msecであることを取得し、200msecだけ(図４のＰ１〜Ｐ２の時間帯)２回目のスリープを行う。

また負荷計算処理部２２Ｂは、図４のＰ２の時点で２回目のスリープ中に発生した既存アプリ２３のＣＰＵ使用時間が100msecであることを取得し、100msecだけ(図４のＰ２〜Ｐ３の時間帯)３回目のスリープを行う。

さらに負荷計算処理部２２Ｂは、図４のＰ３の時点で３回目のスリープ中に発生した既存アプリ２３のＣＰＵ使用時間が0msecであることを取得し、この場合は条件Ｂに該当すするのでステップＳＰ４に移行する。

ステップＳＰ４において、負荷発生処理部２２Ｃは、ＣＰＵ負荷発生部２２の次の動作周期までＣＰＵ負荷を発生し続けた(図４のＰ３〜Ｐ４の時間帯)後、ステップＳＰ２へ戻る。

既存アプリ２３は、負荷発生処理部２２ＣがＣＰＵ負荷を発生し続ける間に、100msecだけＣＰＵ２１を使用する。このときＯＳ優先度制御機能により、ＣＰＵ負荷発生部２２によるＣＰＵ負荷の発生処理は中断される。

すなわち、図４のように既存アプリ２３のＣＰＵ使用時間は400msecであるところ、上述のように負荷発生処理部２２ＣがＣＰＵ負荷を発生することにより、ＣＰＵ負荷発生部２２のＣＰＵ使用時間は200msecとなり、既存ＡＰ２３の最大ＣＰＵ使用時間600msecを補償することができる。

この結果、追加アプリ２４は、既存アプリ２３とＣＰＵ負荷発生部２２の両方がＣＰＵ２１を使用していない状態のときに、ＣＰＵ２１を使用できることになる。

このように、追加アプリ２４の動作検証を行う電子機器のＣＰＵ負荷発生部２２は、既存アプリ情報テーブル２２Ａから読み込んだ既存アプリ情報に基づいて既存アプリ２３の動作周期単位で既存アプリ２３のＣＰＵ使用時間の合計が最大ＣＰＵ使用時間に満たない時間だけＣＰＵ２１に負荷を発生させることにより、既存アプリ２３の単位時間あたりのＣＰＵ使用率を各動作周期単位であらかじめ割り当てられている最大ＣＰＵ使用時間に設定することができる。

したがって、追加アプリ２４の動作検証は、既存アプリ２３の各動作周期単位であらかじめ割り当てられている既存アプリ２３の最大ＣＰＵ使用時間を確保した残り時間で行うので最も過酷な状況下で行うことになり、十分な条件での動作検証を比較的短時間で行うことができる。

なお、ＣＰＵ負荷発生部２２は、動作検証に必要な時間を制御するのにあたり、既存アプリ２３と追加アプリ２４の動作周期の長短に関連して、既存アプリ２３が追加アプリ２４よりも長いかまたは等しい場合には、既存アプリ２３の動作周期１回分の時間で行う。

これに対し、既存アプリ２３が追加アプリ２４よりも短い場合には、追加アプリ２４の動作周期１回分の時間で行う。

また、ＣＰＵ負荷発生部２２の優先度は既存アプリ２３よりも低いために、既存アプリ２３の処理を中断させることはなく、かつ、ＣＰＵ負荷発生部２２は既存アプリ２３の外部にあるので、既存アプリ２３を変更することなく既存アプリ２３の運用中に追加アプリ２４の動作検証を行うことができる。

また、ＣＰＵ負荷発生部２２は、既存アプリ２３の動作周期内にスリープを繰り返して既存アプリ２３の動作状態を把握して既存アプリ２３のＣＰＵ使用時間の合計が最大ＣＰＵ使用時間に満たない時間だけＣＰＵ負荷を発生させるので、既存アプリ２３がＣＰＵ２１を使用するタイミングに依存することなく各動作周期あたりの最大ＣＰＵ使用時間を確実に確保して補償できる。つまり、既存アプリ２３は、図４のように動作周期内に複数回のｗａｉｔ処理を含むものでも構わないし、動作周期の前半または後半に集中的にＣＰＵ２１を使用するものでも構わない。

なお、上記実施例では、追加アプリの動作検証を行う電子機器に１つの既存アプリが存在する場合を例として説明しているが、既存アプリが複数存在する場合であっても構わない。図５は既存アプリが複数存在する場合の追加アプリの動作検証を行う電子機器の一実施例を示す構成ブロック図、図６は図５の既存アプリ情報テーブル２２Ａが記憶するデータの一例である。

図５において、既存アプリ２５、既存アプリ２６以外の構成は図１と同様であるのでそれらの説明を省略する。図５のフィールド機器２には複数の既存アプリ２３、２５、２６が存在し、ＣＰＵ２１は既存アプリ２３、２５、２６の優先度を高優先度に設定する。

これら複数の既存アプリはそれぞれ動作周期と動作周期あたりの最大ＣＰＵ使用時間が異なるものであり、たとえば図６（Ａ）のように、既存アプリ２３は動作周期が500msecで最大ＣＰＵ使用時間が100msec、既存アプリ２５は動作周期が1000msecで最大ＣＰＵ使用時間が300msec、既存アプリ２６は動作周期が2000msecで最大ＣＰＵ使用時間が500msecとする。

このように既存アプリが複数あって動作周期および最大ＣＰＵ使用時間がそれぞれ異なる場合は、ＣＰＵ負荷発生部２２の負荷計算処理部２２Ｂは、全既存アプリ２３、２５、２６の動作周期の最小公倍数を算出するとともにこの動作周期の最小公倍数あたりにおける全既存アプリの最大ＣＰＵ使用時間を算出し、既存アプリ動作情報として既存アプリ情報テーブル２２Ａに記憶する。

たとえば図６（Ｂ）のように、負荷計算処理部２２Ｂは、既存アプリ２３の動作周期500msec、既存アプリ２５の動作周期1000msec、既存アプリ２６の動作周期2000msecから、これら既存アプリの動作周期の最小公倍数として動作周期2000msecを算出し、既存アプリ情報テーブル２２Ａに記憶する。

また、負荷計算処理部２２Ｂは、最小公倍数の動作周期2000msecあたりの既存アプリ２３の最大ＣＰＵ使用時間400msec、既存アプリ２５の最大ＣＰＵ使用時間600msec、既存アプリ２６の最大ＣＰＵ使用時間500msecから、動作周期の最小公倍数あたりにおけるこれら既存アプリの最大ＣＰＵ使用時間1500msecを算出し、既存アプリ情報テーブル２２Ａに記憶する。

そして、ＣＰＵ負荷発生部２２は、既存アプリ情報テーブル２２Ａに記憶されたこれら既存アプリの動作周期の最小公倍数、動作周期の最小公倍数あたりにおける全既存アプリの最大ＣＰＵ使用時間である既存アプリ動作情報に基づいて、上述のステップＳＰ１〜ＳＰ４を行うことにより、フィールド機器２などの電子機器に既存のアプリが複数存在する場合であっても、追加アプリの動作検証を短時間で行うことができる。

また、上記実施例のフィールド機器２や追加アプリの動作検証を行う電子機器は、ＯＳや各機器として動作するためのプログラムやアプリケーション、各種情報などを格納する記憶部、各部の動作を制御する演算制御部（たとえばＣＰＵ）、各機器間で通信を行う通信部などのハードウェアから構成されるものでもよい。またフィールド機器２や追加アプリの動作検証を行う電子機器の演算制御部は、記憶部に格納されているＯＳなどを起動して、このＯＳ上で格納されたプログラムを読み出し実行することにより、各機器全体を制御し、各機器固有の動作を行うものでもよい。

なお、上記実施例では、ＣＰＵ資源管理装置がフィールド機器の例を説明したが、これに限るものではなく、本発明はアプリが実装される各種の電子機器にも適用できるものである。

本発明の一実施例を示す構成ブロック図である。 図１のＣＰＵ負荷発生部２２の機能ブロック図である。 図３は図２の既存アプリ情報テーブル２２Ａが記憶するデータの一例である。 図１におけるＣＰＵ使用状態を説明する説明図である。 既存アプリが複数存在する場合の実施例を示す構成ブロック図である。 図５の既存アプリ情報テーブル２２Ａが記憶するデータの一例である。 従来のＣＰＵ資源管理装置の一例を示す構成ブロック図である。

符号の説明

１、２ フィールド機器
１１、２１ ＣＰＵ
１２、２３、２５、２６ 既存アプリ
１３、２４ 追加アプリ
２２ ＣＰＵ負荷発生部
２２Ａ 既存アプリ情報テーブル
２２Ｂ 負荷計算処理部
２２Ｃ 負荷発生処理部

Claims (6)

1. 実装された複数のアプリに優先度を設定し、最も優先度が高いアプリにＣＰＵを使用させるように構成されたＣＰＵ資源管理装置において、
   優先度の高い既存アプリを動作させながら優先度の低い追加アプリの動作を検証するのにあたり、既存アプリの各動作周期について実際のＣＰＵ使用時間に基づき所定の最大ＣＰＵ使用時間に満たない時間だけＣＰＵに負荷を発生させるＣＰＵ負荷発生部を設け、
   前記既存アプリの各動作周期について既存アプリの最大ＣＰＵ使用時間を確保することを特徴とするＣＰＵ資源管理装置。
2. 前記追ＣＰＵ負荷発生部は、
   既存アプリの動作周期と動作周期あたりの最大ＣＰＵ使用時間を含む既存アプリ情報を記憶する既存アプリ情報テーブルと、
   この既存アプリ情報テーブルに記憶された既存アプリ情報に基づき、既存アプリの各動作周期について実際のＣＰＵ使用時間に基づき所定の最大ＣＰＵ使用時間に満たない時間を計算する負荷計算処理部と、
   この負荷計算処理部の計算結果に基づき、前記既存アプリの最大ＣＰＵ使用時間に満たない時間だけＣＰＵに負荷を発生させる負荷発生処理部、
   で構成されることを特徴とする請求項１記載のＣＰＵ資源管理装置。
3. 複数の既存アプリが実装されている場合は、
   これら既存アプリの動作周期の最小公倍数およびこの動作周期の最小公倍数あたりにおける各既存アプリの最大ＣＰＵ使用時間の合計を算出し、各既存アプリの動作周期の最小公倍数あたりにおける実際のＣＰＵ使用時間の合計が前記算出した既存アプリの最大ＣＰＵ使用時間に満たない時間だけＣＰＵに負荷を発生させることを特徴とする請求項１または請求項２に記載のＣＰＵ資源管理装置。
4. ＣＰＵ資源管理装置はフィールド機器として構成されていることを特徴とする請求項１から請求項３のいずれかに記載のＣＰＵ資源管理装置。
5. 実装された複数のアプリに優先度を設定し、最も優先度が高いアプリにＣＰＵを使用させるＣＰＵ資源管理方法において、
   優先度の高い既存アプリを動作させながら優先度の低い追加アプリの動作を検証するのにあたり、
   既存アプリの動作周期と動作周期あたりの最大ＣＰＵ使用時間を含む既存アプリ情報に基づき既存アプリの各動作周期について実際のＣＰＵ使用時間に基づき所定の最大ＣＰＵ使用時間に満たない時間を求める第１のステップと、
   第１のステップで求めた既存アプリの最大ＣＰＵ使用時間に満たない時間だけＣＰＵに負荷を発生させる第２のステップ、
   を含むことを特徴とするＣＰＵ資源管理方法。
6. 前記ＣＰＵ資源管理方法は、フィールド機器として構成された電子機器を対象とすることを特徴とする請求項５記載のＣＰＵ資源管理方法。

Images