(57)【要約】【課題】  従来の資源予約技術は、プロセスやスレッドという粒度に捉われず、任意の処理単位で計算資源を保障する事が困難だった。一方、プログラムの並列化技術は、並列度の無い処理を分割する事ができないため、処理時間の調整を施せない。また、時間制約を満たすためのプログラム変換技術では、挿入される静的なクリティカルセクションやリリースセクションが、実行時の非決定的動作に追従できなかった。【解決手段】  プログラムソースに対して、CPU利用率として与えた資源要求とその要求区間を、プログラム外から与え、CPU利用率を計測しながら実行優先度の上下や資源解放を行う資源制御ルーチンを適切な間隔で挿入し、それとは別に対象区間の中断時間を計測する資源測定ルーチンを他タスクのメインループ前後へ挿入することによって、所定の資源要求を保ちながら処理を完遂することを保障する。【選択図】図２
2010134494.tif 000002
【特許請求の範囲】
【請求項１】
プリエンティブなマルチタスクＯＳ（オペレーティングシステム）で実行されるプログラムのコード変換をおこなうプログラム変換装置であって、
前記プログラムと、前記プログラムの所定処理区間毎のCPU資源要求情報と、変換されたプログラムとを記録する記録部と、
前記情報に基づいて、前記プログラムの所定位置に資源利用時間測定コードを挿入する資源測定プログラム生成部と、
前記資源利用時間測定コードの測定結果と前記CPU資源要求情報とを比較して、前記プログラムの所定処理区間毎のスケジューラを制御する資源制御コードを挿入する資源予約プログラム生成部と、を備えたことを特徴とするプログラム変換装置。
【請求項２】
請求項１に記載のプログラム変換装置において、
前記資源制御コードは、資源利用率が目標よりも下回るとタスクの優先度を上昇させ、資源利用率が目標よりも上回ると超過分の資源を解放することを特徴とするプログラム変換装置。
【請求項３】
プリエンプティブなマルチタスクOS上で実行されるプログラムのコードを変換するプログラム変換装置であって、
前記プログラムを記憶する第１の記憶部と、
前記プログラムに対して処理ステートメントの始点位置と終点位置から成る区間情報毎に、CPU資源の要求値の下限値と上限値、実行優先度の下限値と上限値、資源制御間隔を設定する第２の記録部と、
前記第１の記憶部に記録されたプログラムを構成するタスクの内で、測定対象となるタスクを判定する測定タスク特定部と、
前記測定タスク特定部により測定対象と判定されたタスクについて、周期実行のメインループの始点と終点の位置を確定する資源測定ルーチン位置解決部と、
測定区間について、前記第１の記憶部に記録されたプログラムに資源測定ルーチンを挿入する資源測定ルーチン挿入変換部と、
前記第１の記憶部に記録されたプログラムから、前記第２の記録部に記録されている要求区間を特定する要求区間特定部と、
前記要求区間特定部により特定された要求区間毎に、前記第２の記録部に記録される当該区間の資源制御間隔から、プログラムのステートメント毎に資源制御位置かどうかを判定する資源制御ルーチン位置解決部と、
資源制御位置について、前記第１の記録部に記録されたプログラムに資源制御ルーチンを挿入する資源制御ルーチン挿入変換部と、を備えたことを特徴とするプログラム変換装置。
【請求項４】
請求項３に記載のプログラム変換装置において、
前記測定タスク特定部は、前記第１の記憶部に記録されたプログラムを構成するタスクの内で、前記第２の記録部に記録される要求区間を処理するタスクよりも高優先度に設定されるタスクのみ測定対象とすることを特徴とするプログラム変換装置。
【請求項５】
請求項３に記載のプログラム変換装置において、
前記資源測定ルーチン挿入変換部が挿入する資源測定ルーチンは、前記第２の記録部に記録される要求区間が処理されている間で、かつ下位優先度タスクが測定中で無い場合にのみ、処理時間を測定することを特徴とするプログラム変換装置。
【請求項６】
請求項３に記載のプログラム変換装置において、
前記資制御ルーチン挿入変換部が挿入する資源制御ルーチンは、前記第２の記録部に記録される要求区間の始点で優先度上昇、終点で優先度下降、要求区間内では超過資源を解放することを特徴とするプログラム変換装置。
【請求項７】
プリエンティブなマルチタスクＯＳで実行されるプログラムのコード変換をおこなうプログラム変換方法であって、
前記プログラムの所定区間毎の要求CPU利用率と優先度範囲を取得するステップと、
前記ステップで取得した所定区間毎の優先度範囲から、所定区間を処理するタスクよりも高優先度に設定されるタスクのメインループに資源測定コードを挿入するステップと、
前記ステップで挿入した資源測定コードが保持する前記高優先度タスクによる累積中断時間を確認しながら、CPU利用率が要求CPU利用率を上回れば超過分に相当する時間だけ資源を解放する資源制御コードを、前記プログラムの所定区間に挿入するステップと、を有することを特徴とするプログラム変換方法。
【請求項８】
プリエンティブなマルチタスクＯＳで実行されるプログラムの制御方法であって、
前記プログラムの所定位置に挿入された資源利用時間測定コードにより当該プログラムの所定区間毎のCPU利用率を取得するステップと、
前記取得したCPU利用率が予め設定された所定区間毎の要求CPU利用率とを比較して資源利用率が目標よりも下回るとタスク優先度を上昇させるステップと、
前記取得したCPU利用率が予め設定された所定区間毎の要求CPU利用率とを比較して資源利用率が目標よりも上回るとCPU資源を開放するステップと、を含むことを特徴とするプログラム制御方法。
【請求項９】
プリエンティブなマルチタスクＯＳを搭載した装置で実行されるプログラムであって、
前記プログラムの所定位置に挿入された資源利用時間測定コードにより当該プログラムの所定区間毎のCPU利用率を取得するステップと、
前記取得したCPU利用率が予め設定された所定区間毎の要求CPU利用率とを比較して資源利用率が目標よりも下回るとタスク優先度を上昇させるステップと、
前記取得したCPU利用率が予め設定された所定区間毎の要求CPU利用率とを比較して資源利用率が目標よりも上回るとCPU資源を開放するステップと、を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プリエンプティブなマルチタスクOSで実行されるプログラムに係り、プログラムの指定した区間に対してCPU資源（利用率）を確保する形に、プログラムを変換するプログラム変換装置、方法及び記録媒体に関するものである。
【背景技術】
【０００２】
時間的制約を持ったリアルタイム処理は、試行錯誤を経て綿密な微調整が施された形でハードコーディングされる事が多いため、その多くは最終的に性能要求や実装意図の読み取れない職人芸的プログラムになってしまう。可読性の悪い職人芸的プログラムは、バグ対応や性能チューニング等の保守作業において、プログラマに多大な労力を費やさせ、ソフトウェアの生産性・品質を低下させてしまう。Linux のようなプリエンプティブなマルチタスク機能をサポートするOSではより深刻であり、タスクスケジューリングを最適化しながら各タスクのリアルタイム性を満たさなければならない。そもそも、タイムシェアリング用のOSでは、構造自体が時間的制約を満たしにくい事も指摘されている。
【０００３】
また、リアルタイム性が特に重要である組み込みシステムにおいても、近年、ますます時間的制約の保障が困難になってきている。従来、組み込み向けのリアルタイムOSを適用したシステムでは、システム内のタスクが予め固定されている事が多かった。そのため、熟練者が注意深く各タスクの時間的制約が満たされる優先関係を設定し、優先度ベーススケジューリングを用いて、制約の違反を避けることができた。優先度ベーススケジューリングでは、実行可能となった上位優先度タスクが下位優先度タスクの実行を即座に中断できるアルゴリズムである。
【０００４】
しかしながら、最近では、組み込みシステムとはいえ、デジタル化、ネットワーク化によって、開放型システムになりつつあり加速度的に高機能化が進んでいる。そのようなシステム上では、動作するアプリケーションの種類や挙動を予め把握する事は非常に困難となる。
【０００５】
そこで、近年、資源予約型システムが提案されている。資源予約型システムでは、明示的に設定されたプロセッサの実行時間を確実にタスクへ割り当てる事で、必要な処理量を確保し、時間的制約を有するタスクを満足させる事ができる。
【０００６】
非特許文献１で報告された Resource Kernel では、周期とその周期のうちで割り当てるべき計算時間を明示して予約を行い、その予約に応じてプロセッサを割り当てることにより、デッドラインまでに処理が終了することを保障する。特許文献１では、時間的制約を満たしたプロセス群の優先度組み合わせを記録し、その順序通りにタスクスケジュールを再現する手法が述べられている。
【０００７】
しかしながら、これらの方法では、Linuxプロセスに対してCPU資源を予約するため、きめ細やかに資源を割り当てる事が難しい。プロセス単位の粗粒度な制御では、一部区間のCPU資源を予約するために、当該処理をプロセスへと再分割する必要が出てきてしまう。
【０００８】
特許文献２では、時間的制約を満たすように自動的に指定された処理のプログラムを並列化する方法が述べられている。しかし、当然ながら、適用対象が並列化によって性能向上が見込まれるプログラムに限定される。
【０００９】
したがって、十分な並列度の内在しない又は効果の少ないプログラムでは、実行時間を大きく制御できない。さらに、Resource Kernel のようなカーネルの改変を要求するシステムの場合、システムのプラットフォーム依存度が強くなるため移植性が損なわれてしまう。
【００１０】
非特許文献２では、特別なプラットフォームを用意せず、プログラム変換器によって、特定スレッドの時間的制約の違反を回避する QoSWeaver が提案されている。QoSWeaver は、特に J2EE アプリケーションサーバにおいて、オーバーロード時、過度にCPU 資源を占有するスレッドのプログラムに対して、静的に適度なプリエンプションコードを挿入する。しかし、このような間接的に特定のスレッドへの影響を抑えるアプローチでは、一部区間の時間的制約を満たすために、不要に多くの CPU 処理時間を与えてしまう場合が出てくるため精度がよくない。
【００１１】
【特許文献１】特開平6-202884号公報
【特許文献２】特開2006-126977号公報
【非特許文献１】S. Oikawa and R. Rajkumar，  “Portable RK: A Portable Resource Kernel for Guaranteed and Enforced Timing Behavior”，  IEEE Real-Time Technology and Applications Symposium， 1996
【非特許文献２】K. Kourai， H. Hibino and S. Chiba，  “Aspect-oriented Application-level Scheduling for J2EE Servers”，  6th International Conference on Aspect-Oriented Software Development， 2007
【発明の開示】
【発明が解決しようとする課題】
【００１２】
上記の資源予約技術は、プロセスやスレッドという粒度に捉われず、任意の処理単位で計算資源を保障する事が困難だった。一方、プログラムの並列化技術は、並列度の無い処理を分割する事ができないため、処理時間の調整を施せない。
【００１３】
また、時間制約を満たすためのプログラム変換技術では、挿入される静的なクリティカルセクションやリリースセクションが、実行時の非決定的動作に追従できない事がある。
【００１４】
本発明は、上記課題を解決し、プリエンプティブなマルチタスクOSにおいて、プログラムの資源要求を保証することができ、かつそのようなプログラムを自動生成するプログラム変換装置を提供することを目的とする。
【課題を解決するための手段】
【００１５】
上記目的を達成するために、本発明は、プログラムソースに対して、資源要求の対象区間に、資源利用率を計測しながら実行優先度の上下や資源解放を行う資源制御ルーチンを適切な間隔で挿入し、それとは別に対象区間の中断時間を計測する資源測定ルーチンを他タスクのメインループ前後へ挿入することによって、所定の資源要求を保ちながら処理を完遂することを保障するものである。中断時間とは、対象区間を実行するタスクが、上位優先度タスクによって割り込まれる時間を指す。生成された資源予約プログラムは、要求区間では、上位優先度タスクの実行時間と自タスクの実行時間を比較し、指定の資源利用率を守るように実行優先度を上下させる。資源利用率が目標よりも下回ると、自タスクの優先度を上昇させ、逆に上回ると超過分の資源を解放する。また、対象区間の実行が終わると、自タスクの優先度を元に下降させる。
【００１６】
また、本発明によるプログラム変換装置は、複数のタスクを同時に処理するプリエンプティブなマルチタスクOSにおいて、CPU利用率で示された所定の資源要求を持つ処理に対し、前記資源要求を満たしつつ処理を完遂することを保証させるプログラム変換装置であって、プログラムソース外に記述された資源要求を表す資源要求コードとその要求区間を表す要求区間コードを取得する資源要求及び要求区間コード取得部と、資源要求を満たすように資源制御ルーチンが挿入された資源予約プログラムを生成する資源予約プログラム生成部と、各タスクの資源利用量を測定するための資源測定コードが挿入された資源測定プログラムを生成する資源測定プログラム生成部、とを備えたものである。
【発明の効果】
【００１７】
本発明によれば、プリエンプティブなマルチタスクOSにおいて、プログラムの任意の指定区間を処理する際、実行時のCPU利用率に応じて、適切な処理群を高優先度で実行しつつ適度に資源解放を行う事で、資源要求を保証することができ、かつそのようなプログラムを自動生成することできるので、プログラムの品質向上をおこなうことができるとともに、プログラムの生産性を向上することもできる。
【発明を実施するための最良の形態】
【００１８】
以下、本発明を図面に示した具体的な実施の形態に沿って説明するが、本発明は、後述する実施の形態に限定されるものではない。
【００１９】
図１は、本発明のプログラム変換装置を組み込んだプログラム開発システムの実施例を示した図である。図１には、リモートコントローラ２０と、デジタル放送アンテナ３０と、表示装置４０と、本発明のプログラム変換装置５０と、デジタル放送受信機６０とからなるシステム１０が示されている。
【００２０】
デジタル放送受信機６０には、変換プログラムが格納される記憶装置６１と、プロセッサ６２、リモートコントローラ２０からの信号を受信する信号受信部６３、デジタル放送アンテナ３０を介して映像データ、音声データ及び字幕データを受信するデジタル放送チューナー６４とデジタル放送受信機ソフトウェア６５が搭載され、さらに各種資源の管理及びアプリケーションがそれら資源を利用できるようにするためのＯＳ及びアプリケーションが格納されている。
【００２１】
デジタル放送受信機ソフトウェア６５は、リモートコントローラタスク６５１と、チューナータスク６５２と、描画タスク６５３と、電子番組ガイドタスク６５４及びデータ放送ブラウザタスク６５５を備えている。
【００２２】
図１に示す実施の形態では、デジタル放送受信機ソフトウェア６５はプログラム変換装置５０により、資源予約プログラムへ変換され記憶装置６１へ格納される。記憶装置６１へ格納された資源予約プログラムは、プロセッサ６２によりデジタル放送受信機６５のOSへ読み込まれ、実行される。プロセッサ６２は、リモートコントローラ２０使用したユーザ操作に対するリモートコントローラタスク６５１による受信処理とその適切な応答処理を行っている。
【００２３】
例えば、選局に伴うチューナータスク６５２による放送局を切り替え、電子番組ガイド視聴に伴う電子番組ガイドタスク６５４による電子番組ガイド取得及び複合化、データ放送視聴に伴うデータ放送ブラウズタスク６５５によるデータ放送コンテンツ取得及び複合化を行い、変更された映像を描画タスク６５３が合成して表示装置４０に出力している。
【００２４】
リモートコントローラタスク６５１による受信処理は、確実に行わなければならず、常にプロセッサ６２によって稼動させられなければならない。しかし、同時に電子番組ガイドタスク６５４による電子番組ガイドの取得及び複合化、データ放送ブラウズタスク６５５によるデータ放送コンテンツの取得及び複合化においても、ユーザ操作に連動した処理の場合は、一定の時間内に処理を完遂させたいという要求がある。しかしながら、これらの応答処理は、平時においては状態変化の通知等の重要で無い処理を行うため、従来は低い優先度で稼動するものとされていた。
【００２５】
デジタル放送受信機ソフトウェア６５の動作は、優先度ベーススケジューリングアルゴリズムに基づくため、優先度の高いタスクは低いタスクを優先し、場合によっては中断させて処理される。したがって、例えば、いざ電子番組ガイド及びデータ放送コンテンツを視聴したい場合でも、プロセッサ６２は、高優先度で稼動するリモートコントローラタスク６５１や、チューナータスク６５２及び描画タスク６５３に処理時間を優先して与えている。
【００２６】
そうなると、一時的に時間的制約を持つ電子番組ガイドタスク６５４及びデータ放送ブラウザタスク６５５には、十分な処理時間が確保されにくかった。なぜなら、優先度ベーススケジューリングでは、優先度の低いタスクは高いタスクの処理を中断しないため、高優先度で稼動するリモートコントローラタスク６５１や、チューナータスク６５２及び描画タスク６５３の処理が完了して実行待ち状態へ遷移するまで、電子番組ガイドタスク６５４やデータ放送ブラウザタスク６５５は処理を待たされる事になるからである。
【００２７】
つぎに、本発明のプログラム変換の概要について説明する。本発明のプログラム変換装置は、特定の処理区間に対し、CPU利用率要求が保証されるだけの計算資源が与えられるように、プログラムを変換するシステム、言い換えればプログラム変換時の資源予約システムである。ここでは、CPUによる処理時間を計算資源とする。変換されたプログラムは、資源要求の無い区間では静的に設定された実行優先度に基づく計算資源がOSスケジューラにより与えられるが、資源要求のある区間では、OSスケジューラに依らず、制約を満たすのに十分な計算資源が与えられる。
【００２８】
具体的には、プログラム変換装置は、資源要求のある区間に、適切な処理単位で資源制御ルーチンを挿入する。資源制御ルーチンは、資源利用率が資源要求を下回れば実行優先度を上げ、上回れば超過分の資源を解放し、要求区間の実行が終わると実行優先度を元に戻すような制御を実施する。
【００２９】
資源制御ルーチンの挿入間隔は、関数呼び出し単位、ステートメント単位、ブロック単位、行単位等、任意の粒度で設定してもよい。ステートメントとは、プログラムの一文を表し、C言語やJava（登録商標）言語等の多くの高水準言語ではセミコロンで区切られる。一方、プログラム変換装置は、各タスクの周期実行のメインルーチン前後に資源測定ルーチンを挿入し、要求区間処理中に他タスクが割り込む時間、すなわち自タスクの中断時間を求める。
【００３０】
一般に、優先度に基づくタスクスケジューリングを行うOSでは、実行優先度の高いタスクは、低いタスクの処理を中断し割り込んで処理できる。したがって、資源測定ルーチンが計測するタスクの処理時間のうち、要求区間を処理するタスクよりも高優先度タスクの処理時間の合算が、要求区間での処理中断時間になる。
【００３１】
こうして、資源制御ルーチンは、経過時間と処理中断時間の差分から、自タスクの実際の処理時間を求め、資源利用率を算出する。ただし、資源測定ルーチンは、周期的に処理されるタスクにのみ挿入され、外部割り込みのハンドリング処理による中断時間は考慮しない。
【００３２】
より具体的に図１を参照して説明すると、ユーザがデータ放送視聴用のリモートコントローラ信号を送信すると、その信号に応答して、プロセッサ６２で実行されているOSは、リモートコントローラタスク６５１をディスパッチする。次に、データ放送ブラウザタスク６５５がディスパッチされ、データ放送コンテンツの取得及び複合化処理が実行される。
【００３３】
本発明のプログラム変換システムは、図２のように、プログラムソース５１及び資源資源要求コード及び要求区間コード５２から、要求区間中に適切な間隔で資源制御ルーチン５５を挿入し、各タスクのメインルーチンの前後に資源測定ルーチン５６を挿入した、資源予約プログラムソース５３及び資源測定プログラムソース５４を出力する。こうして、本発明のプログラム変換システムで資源予約プログラムへ変換されたデータ放送ブラウザタスク６５５は、設定された資源要求を指標に、実行優先度の上下や資源解放を行う。
【００３４】
図３では、資源予約プログラムの挙動を、プログラムステップにおける資源要求区間での実行優先度とCPU利用率の変化として模式的に示している。資源要求60%要求区間では、プログラムを実行するタスクの実行優先度は最大値まで上昇させられる。CPU利用率が要求値60%を超えると、実行優先度は最大値を保ちつつ、超過した資源が解放される。ここで、CPU利用率及び超過利用分の解放時間は、要求区間における累積処理時間を基に算出される。要求区間の処理が終わると、プログラムを実行するタスクの実行優先度は、初期優先度まで下降させられる。
【００３５】
図４には、資源予約プログラムソース５３と資源測定プログラムソース５４の一つの例を示す。本発明のプログラム変換装置によって、資源測定ルーチンは、プログラマが指定したタスクグループの中で、資源要求区間を処理するタスクよりも高優先度なタスクに挿入される。具体的には、資源要求区間を処理するタスクの優先度が50で、タスクグループを20，30，40の優先度を持つタスク群とするとき、優先度20，30，40のタスク処理時間、すなわちメインループのタスクコード処理にかかる時間を測定するコードが挿入される。
【００３６】
また、資源制御ルーチンは、資源要求区間内のソースコードに対して適度な間隔で挿入される。具体的には、要求区間入口での優先度上昇、要求区間出口での優先度下降、要求区間内での処理時間測定と資源解放、のためのコードが挿入される。ただし、それぞれのコードは、タスクグループ内でのCPU利用率と資源要求を比較した結果、実行するか否かが判定される。また、算出したCPU利用率を基に、資源解放時間も求められる。
【００３７】
図５は、本発明のプログラム変換装置の機能を表すブロック図である。本発明のプログラム変換装置５０は、複数のプロセスを同時に処理するプリエンプティブなマルチタスクOSにおいて、所定のCPU利用率を用いた資源要求を持つ処理に対し、前記資源要求を保ちながら処理を完遂することを保証させるプログラム変換装置であって、プログラムソース外に記述された資源要求を表す資源要求コードとその要求区間を表す要求区間コードを取得する資源要求及び要求区間コード取得部５０１と、資源要求を満たすように資源制御ルーチンが挿入された資源予約プログラムを生成する資源予約プログラム生成部５０２と、各タスクの資源利用量を測定するための資源測定ルーチンが挿入された資源測定プログラムを生成する資源生成プログラム生成部５０３とを備えたものである。
図６、図７には、それぞれ資源予約プログラム生成部５０２と資源測定プログラム生成部５０３の詳細を表すブロック図を示す。
【００３８】
資源予約プログラム生成部５０２は、プログラムソース５１を読み込んで解析し、資源要求コード及び要求区間コード５２で表された区間を特定する要求区間特定部５０２１と、要求区間中で資源制御ルーチンを挿入する位置及び粒度を決定する資源制御ルーチン位置解決部５０２２と、決定した位置で資源利用率を測定し、優先度を増加・減少の一方へと切り替える資源制御ルーチンを挿入する資源制御ルーチン挿入変換部５０２３とを備える。
【００３９】
また、資源測定プログラム生成部５０３は、プログラムソース５１を読み込んで解析し、資源の測定区間を特定する測定区間特定部５０３１と、測定区間に対して資源測定ルーチンを挿入する位置を決定する資源測定ルーチン位置解決部５０３２と、決定した位置で資源利用量、すなわち処理時間を測定する資源測定ルーチンを挿入する資源測定ルーチン挿入変換部５０３３とを備える。
【００４０】
図８に、入力として与えられる資源要求及び要求区間コード５２のうち、資源要求コード５２１の記述例を、図９に要求区間コード５２２の記述例を示し説明する。資源要求コード５２１は、例えばObject Constraint Language(OCL)で記述され、要求区間コード５２２は、ＡｓｐｅｃｔＪ言語で記述されている。ただし、本発明では、資源要求及び要求区間コード５２、さらには入力されるプログラムソース５１、出力される資源予約プログラムソース５３及び資源測定プログラムソース５４の言語や文法を規定するものでない。
【００４１】
資源要求コード５２１には、資源要求としてCPU利用率、実行優先度の範囲（CPU利用率を算出するタスクグループ）、資源制御ルーチンの挿入間隔、資源測定ルーチンの挿入箇所等と、要求区間を記述できる。図８の記述例では、BML-policyという名前の資源要求コードテンプレート（５２１ａ）を用いて、ＣＰＵ利用率を表すパラメータutilizationに対して６０％以上であるという資源要求（５２１ｂ）を、実行優先度の範囲を表すパラメータpriorityRangeに対して上限が２０、下限が５０であるという指定（５２１ｃ）を、資源制御ルーチンの挿入間隔を表すパラメータsampling-intervalに対して、関数呼び出し単位での挿入を表すcallという指定（５２１ｄ）を記述している。
【００４２】
資源制御ルーチンの挿入間隔は、関数呼び出し単位だけでなく、プログラム行、プログラムの基本ブロック、経過時間等、様々な単位を指定できる。また、資源測定ルーチンの挿入箇所を表すパラメータsamplingに対しては、名前がevnt、又はgui、tuneであり、戻り値がint型である関数群の指定（５２１ｅ）を記述している。資源測定ルーチンの挿入箇所は、関数だけでなく、プログラム中の任意の箇所を指定できる。
【００４３】
一方、要求区間コード５２２には、プログラム中の区間を指定するためのポイントカット表現が記述できる。ポイントカット表現とは、多くのアスペクト指向言語でサポートされる、プログラム中の位置を特定するための表現形式である。
【００４４】
図９の記述例では、QoSContractという名前の要求区間コードテンプレート（５２２ａ）を宣言し、BML-policyという名前の資源要求コードに対する要求区間である事を明示し（５２２ｂ）、ポイントカット表現として名前がupdateで戻り値の無い関数呼び出しの中で、名前がsend_commandである関数呼び出し以外の区間を指定している（５２２ｃ）。つまり、関数 send_comand()の呼び出しを除いた、関数update()のコールフロー全体を要求区間に指定している。ポイントカット表現５２２ｃでは、関数呼び出しだけでなく、プログラム行番号や変数アクセス等、プログラム中の任意の位置を指定できる。
【００４５】
資源要求及び要求区間コード取得部５０１は、図１０に示す処理フローにしたがって、資源要求及び要求区間コード５２を字句解析し、資源要求及び要求区間を取得し、図１１に示す構造で資源要求及び要求区間の情報を保持する。
【００４６】
図１０では、まず有効な要求区間コードがあるかどうかを調べ（５０１０）、もしあれば要求区間コードを取得し記憶する（５０１１）。次に、記憶した要求区間に対応する有効な資源要求コードがあるかどうかを調べ（５０１２）、もしあれば資源要求コードを取得し記憶する（５０１３）。
【００４７】
資源要求コードは、図１１に示すような構造で、定義された資源要求の識別子（名前）５２１０、CPU利用率５２１１、実行優先度の範囲５２１２、資源制御の間隔５２１３、資源測定の位置５２１４が保持される。
【００４８】
要求区間コードは、図１２に示すような構造で、定義された要求区間の識別子（名前）５２２０、対応する資源要求の識別子（名前）５２２１、要求区間を表すポイントカット表現５２２２が保持される。図１０に示される資源要求及び要求区間取得処理は、有効なコードをすべて記録するまで繰り返される。
【００４９】
資源予約プログラム生成部５０２において、要求区間特定部５０２１は、図１３に示す処理フローにしたがって、要求区間コード５２２を取得し、図１４に示すような構造で要求区間のプログラム中の位置を保持する。
【００５０】
図１３では、まず要求区間特定部５０２１は、プログラムを読み込み（５０２１０）、要求区間コードを読み込む（５０２１１）。もしプログラム中に、有効な要求区間があれば（５０２１２）、要求区間コードのポイントカット表現で示される位置を探索する（５０２１３）。そして、もし要求区間コードのポイントカット表現で示される位置の始点があり（５０２１４）、終点もあるならば（５０２１５）、そのプログラム位置を記憶する（５０２１６）。
【００５１】
プログラム位置は、図１４に示すような構造で、対応する要求区間名５１０、始点５１１のファイル名５１２と行番号５１３、終点５１４のファイル名５１５と行番号５１６が保持される。図１３に示される要求区間特定部処理は、要求区間コードのポイントカット表現で示される位置をすべて記憶するまで繰り返され、さらにすべての有効な要求区間コードに対して繰り返される。
【００５２】
資源予約プログラム生成部５０２において、資源制御ルーチン挿入変換部５０２３は、図１７に示す処理フローにしたがって、プログラムソース５１を読み込み、資源制御ルーチン位置解決部５０２２で決定した資源制御ルーチンの挿入位置に対して、資源制御ルーチンを挿入するプログラム変換を行う。
【００５３】
図１７では、まず資源制御ルーチン挿入変換部５０２３は、プログラムソース５１を読み込み（５０２３０）、字句解析、構文解析を行い、要求区間特定部５０２１で特定された要求区間内の全てのステートメントを記憶する（５０２３１）。そして、要求区間内の全てのステートメントに対して、資源制御ルーチン位置解決部５０２２で決定された資源制御位置かどうかをチェックする（５０２３２）。もし、資源制御位置であれば（５０２３３）、当該ステートメント直前に資源制御ルーチンを挿入し（５０２３４）、資源予約プログラムソースとしてファイルに書き出す（５０２３５）。資源制御位置でなければ、そのステートメントはそのまま資源予約プログラムソースのファイルに書き出す。
【００５４】
資源予約プログラム生成部５０２において、資源制御ルーチン位置解決部５０２２は、図１５に示す処理フローにしたがって、プログラムソース５１を読み込み、要求区間特定部５０２１で記憶された始点から終点の範囲で、資源制御ルーチンを挿入する位置を決定し、そのプログラム位置を図１６に示すような構造で保持する。
【００５５】
図１５では、まず資源制御ルーチン位置解決部５０２２は、プログラムを読み込み（５０２２０）、記憶されている要求区間の始点と終点を読み込む（５０２２１）。もし始点と終点の位置がプログラム中で有効なれば（５０２２２）、記憶されている資源制御間隔を読み込む（５０２２３）。そして、プログラムの要求区間である始点から終点までの、制御フローにおいて、資源制御間隔毎にプログラム位置を記憶する（５０２２４）。
【００５６】
資源制御間隔は、関数呼び出し単位やプログラム行等を単位とする。プログラム位置は、図１６に示すような構造で、対応するファイル名５１７と行番号５１８が保持される。図１５に示される資源制御ルーチン位置解決部処理は、要求区間内のプログラムにおいて、指定された資源制御間隔で特定されるプログラム位置を全て記憶するまで繰り返される。
【００５７】
図１８に、ステップ５０２３４において、資源制御ルーチン挿入変換部５０２３によって挿入される資源制御ルーチン５５の処理フローの一つの例を示す。資源制御ルーチン５５は、まず実行中のタスクが既に優先度を上限まで引き上げた状態、つまりブースト状態にあるかどうかを調べる（５５１）。優先度ブースト中で無い場合は、要求区間の始点からの経過時間を取得し（５５２）、要求区間における総中断時間、つまり上位優先度タスクの総処理時間を取得する（５５３）。
【００５８】
次に、得られた経過時間と総中断時間から、要求区間における資源利用率を算出する（５５４）。そして、資源制御ルーチンは、資源要求と資源利用率を比較し（５５５）、資源要求が満たされていなければ優先度ブーストを行う（５５６）。ステップ５５６における優先度ブーストは、多くのOSで提供されている優先度変更関数を利用する。例えば、Linuxでは、nice()やsetpriority()システムコールによって実行優先度の相対値や絶対値を設定でき、ITRON系OSでは、chg_pri()サービスコールによって設定できる。
【００５９】
一方、資源要求を超える資源量を利用していた場合は、超過した資源利用量から超過時間を算出し（５５７）、超過時間分だけ資源を解放する（５５８）。ステップ５５８における、資源解放についても、多くのOSで提供されているCPU資源解放関数を利用する。例えば、Linuxでは、sleep()システムコール、ITRON系OSでは、tsk_slp()サービスコールによって指定時間だけ、CPU資源を解放することができる。
【００６０】
図１９に、資源制御ルーチン挿入変換部５０２３によって、資源制御ルーチンが挿入された資源予約プログラムソースの１つの例を示す。図１９では、プログラムソース５１０１において、５１０２の要求区間が２〜９行目と決定されており、資源要求としてCPU利用率、優先度の範囲、資源測定位置が与えられ、資源制御間隔は行単位とされているものとする。
【００６１】
本発明のプログラム変換装置５０によって、資源予約プログラムソース５３０１には、資源制御ルーチンとして、resource-control()関数５３０２がプログラムソース５１０１の２〜９行目に行単位で挿入されている。resource-control()関数は、図１８に示す処理フローにしたがって、２〜９行目の処理について、資源要求を満たすように、実行優先度の増加や資源解放を行う。
【００６２】
また、図１９のプログラムソース５１０１及び資源予約プログラムソース５３０１では、要求区間５１０２及び資源制御ルーチンの挿入箇所はプログラムの静的な位置として示されているが、関数呼び出しやジャンプ等を考慮した動的な制御フローに対して要求区間を設定し、資源制御ルーチンを挿入することもできる。
【００６３】
資源測定プログラム生成部５０３において、測定タスク特定部５０３１は、図２０に示す処理フローにしたがって、資源要求コード５２１から測定対象タスクを特定し、その優先度リストを保持する。
【００６４】
図２０では、まず測定タスク特定部５０３１は、プログラムを読み込み（５０３１０）、資源要求コードを読み込む（５０３１１）。有効な資源要求コードがあれば（５０３１２）、資源要求コードの優先度範囲を取得し（５０３１３）、その範囲内の優先度を持つタスクがあるか否かを判定する（５０３１４）。図２０に示される測定タスク特定部処理は、優先度範囲内のすべての優先度について繰り返され、さらにすべての有効な資源要求コードに対して繰り返される。
【００６５】
資源測定プログラム生成部５０３において、資源測定ルーチン位置解決部５０３２は、図２１に示す処理フローにしたがって、プログラムソース５１を読み込み、測定タスク特定部５０３１で記憶された優先度を持つタスクの、メインループ始点と終点の位置を解決し、そのプログラム位置を図１４と同様の構造で保持する。
【００６６】
図２１では、まず資源測定ルーチン位置解決部５０３２は、プログラムを読み込み（５０３２０）、記憶されている測定タスクの優先度を読み込む（５０３２１）。そして、読み込んだ優先度が有効であれば（５０３２２）、プログラム中から、その優先度が設定される測定タスクのメインループを探索する（５０３２３）。そして、メインループの始点と終点の位置を記憶する（５０３２４）。
【００６７】
図２１に示される資源測定ルーチン位置解決部処理は、記憶された全ての測定タスクのメインループ始点と終点を記憶するまで繰り返される。タスクのメインループは、外部設定ファイルにて宣言されている場合があるため、資源測定ルーチン位置解決部処理は、測定タスクのメインループを探索する前に外部設定ファイルから情報を取得しても良い。
【００６８】
資源測定プログラム生成部５０３において、資源測定ルーチン挿入変換部５０３３は、図２２に示す処理フローにしたがって、プログラムソース５１を読み込み、資源測定ルーチン位置解決部５０３２で決定した資源測定ルーチンの挿入位置に対して、資源測定ルーチンを挿入するプログラム変換を行う。
【００６９】
図２２では、まず資源測定ルーチン挿入変換部５０３３は、プログラムソース５１を読み込み（５０３３０）、全タスクのメインループを特定して記憶する（５０３３１）。次に、記憶したメインループが、資源測定ルーチン位置解決部で決定された測定対象かどうかをチェックする（５０３３２）。もし、測定対象のメインループであれば（５０３３３）、その始点直後と終点直後に資源制御ルーチンを挿入し（５０３３４）、資源測定プログラムソースとしてファイルに書き出す（５０３３５）。
【００７０】
図２３に、ステップ５０３３４において、資源測定ルーチン挿入変換部５０３３によって挿入される資源測定ルーチン５６の処理フローの一つの例を示す。資源測定ルーチン５６は、まず資源要求区間を処理するタスクが優先度ブースト状態にあるかどうかを調べる（５６１）。優先度ブースト状態にあって、下位優先度でも自タスクでもまだ処理時間測定を開始してないならば測定を開始し（５６５）、測定中ならば測定を終了して（５６６）処理時間を累積処理時間へ加算する（５６７）。優先度ブースト状態でなければ累積処理時間を0にリセットする（５６２）。
【００７１】
ここで、上位優先度タスクは下位優先度タスクの処理を中断するため、下位優先度タスクで測定される処理時間にはその中断時間も含まれる。したがって、すでに下位優先度タスクで処理時間を測定中であれば、上位優先度タスクの資源測定ルーチンでは測定は行われない。ステップ５６５と５６６における測定開始及び終了は、多くのOSで提供されている時刻取得関数を利用する。例えば、Linuxでは、gettimeofday()システムコールによって絶対時間の取得ができ、ITRON系OSでも、get_tim()サービスコールによって取得できる。したがって、処理時間は測定終了時と開始時の時刻との差分で求められる。
【００７２】
図２４に、資源測定ルーチン挿入変換部５０３３によって、資源測定ルーチンが挿入された資源測定プログラムソースの１つの例を示す。図２４では、プログラムソース５１０３において、５１０４のメインループが２〜９行目と確定されており、資源要求として優先度の範囲が与えられているものとする。本発明のプログラム変換装置５０によって、資源測定プログラムソース５４０１には、資源測定ルーチンとして、resource-measure()関数５４０２がプログラムソース５１０３のメインループの始点直後と終点直前に挿入されている。
【００７３】
resource-measure関数は、図２３に示す処理フローにしたがって、メインループの処理時間を測定して累積処理時間を記憶する。また、資源測定プログラムソース５４０１に変換されるプログラムソースは、資源要求として与えられた優先度範囲内で優先度が設定されるタスクの中で、資源要求の対象区間を処理するタスクよりも高優先度タスクのメインループが記述されたものになる。
【００７４】
ここまで、本発明を図面に示した実施の形態に基づいて説明してきたが、本発明は図面に示した実施の形態に限定されるものでなく、各部の機能を上述してきたようなプログラムを実行させることにより達成することができる。また、この場合、プログラムが記録された記録媒体として提供することも可能である。
【産業上の利用可能性】
【００７５】
本発明のプログラム変換装置を用いれば、プログラムの任意の区間に対して細粒度にCPU利用率を用いた資源要求を与え、それを満たすような資源要求プログラムへ自動変換できるため、映像音声処理や自動制御システム、医療システムのようなリアルタイムシステムの開発環境に適用可能である。
【図面の簡単な説明】
【００７６】
【図１】プログラム変換装置が組み込まれたシステムの実施例を示した図である。
【図２】プログラムソースから資源予約プログラムソースへの変換を示した図である。
【図３】資源予約プログラムの実行優先度とCPU利用率の変化を示す図である。
【図４】資源予約プログラムと資源測定プログラムの１つの例を示す図である。
【図５】プログラム変換装置の１つの実施の形態を示した図である。
【図６】資源予約プログラム生成部の１つの処理フローを示した図である。
【図７】資源測定プログラム生成部の１つの処理フローを示した図である。
【図８】資源要求コードの１つの記述例を示した図である。
【図９】要求区間コードの１つの記述例を示した図である。
【図１０】資源要求及び要求区間コード取得部５０１の処理フローを示した図である。
【図１１】資源要求及び要求区間コード取得部５０１で保持する資源要求コードの１つの構造例を示した図である。
【図１２】資源要求及び要求区間コード取得部５０１で保持する要求区間コードの１つの構造例を示した図である。
【図１３】要求区間特定部５０２１の１つの処理フローを示した図である。
【図１４】要求区間特定部５０２１で保持する要求区間のプログラム位置の１つの構造例を示した図である。
【図１５】資源制御ルーチン位置解決部５０２２の１つの処理フローを示した図である。
【図１６】資源制御ルーチン位置解決部５０２２で保持する資源制御ルーチンを挿入するプログラム位置の１つの構造例を示した図である。
【図１７】資源制御ルーチン挿入変換部５０２３の１つの処理フローを示した図である。
【図１８】資源予約プログラムソース内に挿入される資源制御ルーチンの１つの動作例を示した図である。
【図１９】本発明のプログラム変換装置が変換する資源予約プログラムソースを模式的に示した１つの例である。
【図２０】測定タスク特定部５０３１の１つの処理フローを示した図である。
【図２１】資源測定ルーチン位置解決部５０３２の１つの処理フローを示した図である。
【図２２】資源制御ルーチン挿入変換部５０３３の１つの処理フローを示した図である。
【図２３】資源測定プログラムソース内に挿入される資源測定ルーチンの１つの動作例を示した図である。
【図２４】本発明のプログラム変換装置が変換する資源測定プログラムソースを模式的に示した１つの例である。
【符号の説明】
【００７７】
１０  システム、２０  リモートコントローラ、３０  デジタル放送アンテナ、４０  表示装置、５０  プログラム変換装置、
５１、５１０、５１０１、５１０３  プログラムソース、５２  資源要求コード及び要求区間コード、５３、５３０１  資源予約プログラムソース、５４、５４０１  資源測定プログラムソース、５５、５３０２  資源制御ルーチン、５６、５４０２  資源測定ルーチン、
５０１  資源要求及び要求区間コード取得部、５０２  資源予約プログラム生成部、５０３  資源測定プログラム生成部、５２１  資源要求コード、５２２  要求区間コード、
５０２１  要求区間特定部、５０２２  資源制御ルーチン位置解決部、５０２３  資源制御ルーチン挿入変換部、５０３１  測定タスク特定部、５０３２  資源測定ルーチン位置解決部、５０３３  資源測定ルーチン挿入変換部、５１０２  要求区間、５１０４  メインループ、
６０  デジタル放送受信機、６１  記憶装置、６２  プロセッサ、６３  信号受信部、６４  デジタル放送チューナー、６５  デジタル放送受信機ソフトウェア、６５１  リモートコントローラプロセス、
６５２  チューナープロセス、６５３  描画プロセス、６５４  電子番組ガイドプロセス、６５５  データ放送ブラウズプロセス
【図１】
2010134494.tif 000003
【図２】
2010134494.tif 000004
【図３】
2010134494.tif 000005
【図４】
2010134494.tif 000006
【図５】
2010134494.tif 000007
【図６】
2010134494.tif 000008
【図７】
2010134494.tif 000009
【図８】
2010134494.tif 000010
【図９】
2010134494.tif 000011
【図１０】
2010134494.tif 000012
【図１１】
2010134494.tif 000013
【図１２】
2010134494.tif 000014
【図１３】
2010134494.tif 000015
【図１４】
2010134494.tif 000016
【図１５】
2010134494.tif 000017
【図１６】
2010134494.tif 000018
【図１７】
2010134494.tif 000019
【図１８】
2010134494.tif 000020
【図１９】
2010134494.tif 000021
【図２０】
2010134494.tif 000022
【図２１】
2010134494.tif 000023
【図２２】
2010134494.tif 000024
【図２３】
2010134494.tif 000025
【図２４】
2010134494.tif 000026