JP4146375B2 - 処理制御装置、処理制御方法及び処理制御プログラム - Google Patents

Description

本発明は、精度が保証されない時間処理手段を用いて定期的に処理を行う必要がある場合に、精度に関わらず平均して一定の時間間隔でリアルタイム処理を行う処理制御装置及び処理制御方法並びにそのプログラムと情報記憶媒体に関するものである。

近年、複数の処理を時分割多重処理で同時に実行することが可能な装置を用いて、特定の処理を一定時間間隔で定期的に繰り返すようなリアルタイム処理を行うことが多々ある。

一例として、テレビ会議システムなどのようにリアルタイムで音声や映像のパケット通信を行う場合には、理想的には一定の時間間隔（例えば２０ｍｓに１回の間隔）で正確にパケットを送受信処理する必要があり、この処理時間間隔の分散が所定の範囲内に収まらなければ、品質の高い通信を行うことができない。また、このようなシステムの場合、通信のリアルタイム性の劣化を低減するために、一般的に映像よりも音声を優先して通信を行う必要がある。

尚、ここでは「リアルタイム処理」、「リアルタイム性」、「リアルタイム性の劣化」を以下のように定義する。

即ち、１つの入力に対して出力乃至は決められた動作を行うようなモジュールを考えたとき、入力に対応する動作の実行が遅延無く、もしくは遅延が一定の範囲内で行われることを期待されるような機能モジュールの処理、あるいは、機能モジュールの処理が決められた一定の時間間隔で周期的に繰り返され、その周期的な処理が起動される時間の遅延、もしくは遅延の揺らぎが一定の範囲内であることが期待されるような処理を「リアルタイム処理」と定義する。

リアルタイム処理の起動時刻が期待された理想的な処理時刻に対して遅延を生じ、あるいは期待された理想的な処理時刻に対して早すぎたり遅すぎたりして、理想的な処理時刻との誤差（時間差）を生じる場合、その誤差（差の時間）の度合いが大きいほど、処理の結果得られる効果に対して性能上の劣化を生じる場合、この劣化を「リアルタイム性の劣化」と定義する。音声のリアルタイム処理の場合、リアルタイム性の劣化により、音切れ、音の欠落等の音声品質劣化を生じる。

従来法の一例として、例えば、特開平９−２９８７２７号公報（第１従来例）に開示される画像音声処理装置及びその信号処理能力割り当て方法や、特開平９−４６３９２号公報（第２従来例）に開示される情報通信制御装置等が知られている。

上記第１従来例は、ＣＰＵの処理能力の最大値と、実行されるすべての処理の各々についてのＣＰＵ負荷量とが既知であることを前提に、ＣＰＵの処理能力の最大値を超えないように処理機能を選択実行する方法である。

また、上記第２従来例は、通信される情報量とＣＰＵ負荷量との関係が既知である場合に、実行される処理をＣＰＵ負荷量が情報量に比例するものと情報量に関わらず一定となるものとに分類したうえで、処理量の総計がＣＰＵの処理能力の最大値を超えないように情報の流量を制限する方法である。

一方、コンピュータ装置を用いて複数の処理を時分割多重処理で同時に実行するためには、時間精度の保証されない処理休止命令を用いなければならない場合がある。時分割多重処理を実施する際に処理の起動タイミングを指定する処理休止命令は、一定時間以上、処理を休止することは保証するが、時分割多重で実行される他の処理との関係によって、どれだけ処理が休止されるかが変わってくるため、実際に処理が休止される時間の精度は保証されない。
特開平９−２９８７２７号公報 特開平９−４６３９２号公報

しかし、前述した従来法のように、処理制御装置、例えばＣＰＵの処理能力の最大値と実行される処理の各々についてのＣＰＵ負荷量とにのみ着目して処理を制御する方法では、実際の処理において、必ずしも所望の処理のリアルタイム性が満たされるとは限らないという問題がある。

例えば、精度の保証されない処理休止命令を用いて上記のような音声のリアルタイム通信処理を行う場合においては、制御装置の最大処理量（処理リソース）に対する利用率が１００％以下であるかどうかを観測するだけでは、リアルタイム処理が正しく行われているかどうかを判定することはできない。

具体的には、20ms毎に1msの時間をかけて音声を送受信処理する処理Ａと、2000ms毎に1000msの時間をかけてファイルを転送する処理Ｂがあり、処理Ａは当該処理の90%において累積遅延が40ms以下で且つ当該処理の95%において累積遅延が60ms以下でなければならないとすると共に、一度には、処理Ａと処理Ｂのどちらか一方しか実行できないとすると、処理ＢではＣＰＵのリソースを50%しか占有しないにもかかわらず、処理Ａは1000msごとにしか処理されなくなるため、許容される累積遅延40ms以下が満たされず、処理Ａのリアルタイム処理を正しく行うことができなくなる。

実際には処理装置における処理切り替えアルゴリズムとしては、様々なアルゴリズムがあるが、一般に、ＣＰＵ負荷量が１００％に満たないからといってリアルタイム処理が可能かどうかは保証できず、リアルタイム処理そのものを直接監視しない限り、その処理が基準を満たしているかどうかを判定することはできない。

本発明は上記のような従来法の欠陥に鑑みてなされたもので、所望のリアルタイム処理が平均して一定の時間間隔で実行されているかどうかを監視し、当該処理の平均的な実行時間間隔が所定の基準を満たしていないと判定された場合にはＣＰＵ負荷量を低減するような処理制御を行い、当該処理のリアルタイム性を向上できる処理制御装置、処理制御方法及び処理制御プログラムを提供することである。

本発明は上記の目的を達成するために、複数の処理を時分割多重処理で同時に実行すると共に所定の実行対象処理をリアルタイムで実行する処理制御装置において、リアルタイム動作を行うときに、前記実行対象処理に対して実際にリアルタイム処理を開始した時刻を用いて前記実行対象処理のリアルタイム性を監視する手段と、前記実行対象処理を前回開始した時刻から今回の処理開始時刻までの経過時間、または前記実行対象処理が実行されるべき処理時刻と前記実行対象処理が実際に実行された時刻との差の時間の何れか一方に関する所定時間内における統計的な値が所定の許容範囲外であるときに、所望のリアルタイム性が満たされていないと判定する手段と、前記実行対象処理の処理開始予定時刻と、実際の処理開始時刻の差から累積処理遅延時間を算出する手段と、前記算出された累積処理遅延時間が処理間隔より短い場合には、累積処理遅延時間が減少するように次回処理開始予定時刻まで処理休止命令で休止する時間を短くして遅延を回復する手段と、前記算出された累積処理遅延時間が処理間隔より大きい場合には、処理休止命令を実行せず連続で処理を行うことにより累積処理遅延を回復する手段と、累積処理遅延を回復するために処理休止命令を実行せず連続で処理を行った回数を計測する手段と、一定時間の間に連続処理を行った回数が所定の閾値を超えたときに、所望のリアルタイム性が満たされていないと判定する手段と、所望のリアルタイム性が満たされていないと判定されたときに、前記実行対象処理以外の処理を停止するか或いは該実行対象処理以外の処理の処理量を削減する手段とを備えた。

また、本発明は上記の目的を達成するために、複数の処理を時分割多重処理で同時に実行する処理制御装置を用いて所定の実行対象処理をリアルタイムで実行する処理制御方法において、前記処理制御装置は、リアルタイム動作を行うときに、前記実行対象処理に対して実際にリアルタイム処理を開始した時刻を用いて前記実行対象処理のリアルタイム性を監視するステップと、前記実行対象処理を前回開始した時刻から今回の処理開始時刻までの経過時間が、所望の処理間隔とどれだけの時間差があるかを統計的な基準で判定するステップと、前記処理間隔の時間差の統計的な値が所定の許容範囲外であるときに、所望のリアルタイム性が満たされていないと判定するステップと、前記実行対象処理の処理開始予定時刻と、実際の処理開始時刻の差から累積処理遅延時間を算出するステップと、前記算出された累積処理遅延時間が前記所望の処理間隔より短い場合には、累積処理遅延時間が減少するように次回処理開始予定時刻まで処理休止命令で休止する時間を短くして遅延を回復するステップと、前記算出された累積処理遅延時間が前記所望の処理間隔より大きい場合には、処理休止命令を実行せず連続で処理を行うことにより累積処理遅延を回復するステップと、累積処理遅延を回復するために処理休止命令を実行せず連続で処理を行った回数を計測するステップと、一定時間の間に連続処理を行った回数が所定の閾値を超えたときに、所望のリアルタイム性が満たされていないと判定するステップと、所望のリアルタイム性が満たされていないと判定されたときに、前記実行対象処理以外の処理を停止するか或いは該実行対象処理以外の処理の処理量を削減するステップとを実施する。

また、本発明の処理制御プログラムは上記の目的を達成するために、前記処理制御方法における各ステップを含む。

本発明の処理制御装置、処理制御方法及び処理制御プログラムによれば、実行対象処理に対してリアルタイム処理を行っている際にリアルタイム性が満たされていないとき、前記実行対象処理以外の処理を停止するか或いは該実行対象処理以外の処理の処理量を削減することによって、装置の負荷を低減することで前記実行対象処理に対するリアルタイム処理のリアルタイム性が満たされる可能性を向上する。

本発明では、一定の時間間隔でリアルタイム処理を行うときに実際に処理を実行するタイミングに誤差を生ずるようなリアルタイム処理の精度が保障されない処理制御装置を用いて、平均して一定の時間間隔でリアルタイム処理を実行する際に、所望のリアルタイム性を満たしていない場合、リアルタイム処理以外の処理を停止するか或いは該リアルタイム処理以外の処理の処理量を削減し、その結果として、相対的に当該リアルタイム処理に割り当てる処理時間を増加させることが可能となり、リアルタイム性の劣化を低減することができる。

以下、図面を参照して本発明の一実施形態を説明する。

図１は本発明の一実施形態における処理制御装置を示す構成図である。

図において、端末Ａ（処理制御装置）と端末Ｂ（処理制御装置）のそれぞれは、コンピュータ装置からなる装置本体１１と、装置本体１１に接続されているＣＣＤカメラ１２、ディスプレイ１３、マイク１４、スピーカ１５とから構成され、端末Ａと端末ＢはＩＰ網２０を介して通信を行えるようになっている。

ここでは、端末Ａと端末Ｂとの間で音声と映像の双方向通信を行い、端末Aと端末Bの間で音声パケットと映像パケットの送受信が行われる。また、各端末Ａ，Ｂ上では複数のサービスアプリケーションが動作可能であるものとする。

図２は端末Ａ，Ｂのそれぞれにおける装置本体１１の機能構成を示す図である。図に示すように装置本体１１は、ＧＵＩ制御部110と通信処理部120から構成されている。

ＧＵＩ制御部110は、通信処理部120からの制御に基づいてディスプレイ１３に所定の表示を行う。

通信処理部120は、通信状態制御部121と、映像入力処理部122、映像出力処理部123、音声入力処理部124、音声出力処理部125、映像送信処理部126、映像受信処理部127、音声送信処理部128、音声受信処理部129から構成されている。

次に、音声・映像データの入出力・送受信処理を行うための上記各構成部の動作を端末Ａを主体として説明する。尚、端末Bでも同様の処理が行われる。

音声入力処理部124では、マイク１４から入力された音声信号を音声データに変換し、Ymsの時間間隔でYms分ずつの単位で音声データを音声送信処理部128に渡す。音声送信処理部128では、Yms分の音声データを単位として符号化し、Yms分の音声パケットとしてRTP（Real-time Transport Protocol）を用いて端末Bに送信する。

映像入力処理部122では、通信状態制御部121から指定されたサイズ（例えばVGA）、指定されたフレームレート（例えば３０ｆｐｓ）で映像ストリームデータを得る。映像送信処理部126では、映像入力処理部122から渡された映像ストリームデータを、映像パケットとして、音声パケットと同様にRTPを用いて端末Bに送信する。

音声受信処理部129では、端末BからYmsの時間間隔でYms分ずつ到着する音声パケットを、伝送に伴ってパケットの到着順所が入れ替わる場合も考慮し、送信時刻の早い順に整列すると共に、音声受信処理部129が実行するバッファ処理により一定量以上を揺らぎ吸収バッファに蓄積した上で、バッファの先頭から順にXmsの時間間隔で一定量ずつXms分の音声データとして音声出力処理部125に渡す。

音声出力処理部125では、音声受信処理部129から渡された音声データを順にスピーカ１５から再生する。

映像受信処理部127では、端末Bから受信した映像のパケットを伝送に伴ってパケットの到達順序が入れ替わる場合も考慮し、送信時刻の早い順に整列し、映像出力処理部123に渡す。

映像出力処理部123では、映像受信処理部127から渡された映像データをディスプレイ１３に表示する。

このようなシステムの機能として映像通信よりも音声通信の重要度が高い場合には、音声通信のリアルタイム処理状況を監視し、ＣＰＵ負荷量が高い状態となってリアルタイムな音声処理を継続することが困難となった場合に、映像通信に使用するＣＰＵリソースを制限することで音声のリアルタイム性を確保するような制御を行うことができる。ここで、音声通信のリアルタイム処理状況を監視する際、例えば受信側においては、受信した音声パケットに基づいて音声を再生する動作の実行が遅延無く、もしくは遅延が一定の範囲内で行われているか否か、あるいは、受信した音声パケットに基づいて音声を再生する処理が決められた一定の時間間隔で周期的に繰り返され、その周期的な処理が起動される時間の遅延、もしくは遅延の揺らぎが一定の範囲内であるか否かを監視する。この様なリアルタイム音声再生処理の起動時刻が期待された理想的な処理時刻に対して遅延を生じ、あるいは期待された理想的な処理時刻に対して早すぎたり遅すぎたりして、理想的な処理時刻との誤差を生じる場合、その誤差の度合いが大きいほど、音声再生の劣化を生じる。音声再生のリアルタイム処理の場合、リアルタイム性の劣化により、音切れや、音の欠落等の音声品質劣化を生じる。

本実施形態では、例えば周知のSleep命令等の時間精度が保障されない時間処理手段を用いて定期的に処理を行う端末Ａ，Ｂにおいて、所望のリアルタイム処理が所定時間内において平均して一定の時間間隔で実行されているかどうかを監視し、当該リアルタイム処理の平均的な実行時間間隔が所定の基準を満たしていないと判定された場合には、優先度の低い他の処理を、停止もしくはＣＰＵ負荷量の低い処理に切り替えることにより、ＣＰＵ負荷量の総計を低減し、前記所望のリアルタイム処理のリアルタイム性を向上させている。

本実施形態の処理制御では、所望のリアルタイム処理のリアルタイム性を向上させるため、実行される処理のＣＰＵ負荷量を用いるのではなく、実際に当該リアルタイム処理が所定時間内において平均して一定の時間間隔で実行されているか否かを監視することで得られた情報を用いている。

本実施形態の処理制御は次の手順で行う。

(1) 実行対象となるリアルタイム処理（例えば音声信号処理）が、所定時間内において平均して一定の時間間隔で実行されているかどうかを後述する「判定手段」を用いて判定する。

(2) 上記(1)の判定の結果、当該リアルタイム処理（例えば音声信号処理）が所望のリアルタイム性を満たしていないと判定された場合、他の処理（例えば映像信号処理）を停止もしくはＣＰＵ負荷量の低い処理に切り替えることにより、ＣＰＵ負荷量の総計を低減する。その結果として、相対的に当該リアルタイム処理に割り当てる処理時間を増加させることができる。

ここで、前述の「判定手段」は、実行対象となるリアルタイム処理の過程で、
(1) 所定時間内における当該リアルタイム処理の実行時間間隔の揺らぎ値が所定の閾値を超えた場合
(2) 所定時間内における所定回数の当該リアルタイム処理の実行時間間隔の移動平均、または移動分散が所定の範囲外あるいは所定の範囲内となった回数をカウントし、このカウント値が所定の閾値を超えた場合
(3) 所定時間内における当該リアルタイム処理の実行時間間隔の移動平均或いは移動分散の値の増加量が所定の閾値を超えた場合
(4) 当該リアルタイム処理の累積遅延を回復するために、所定時間内において処理休止命令を実行しないで連続で処理を行った回数が、閾値として設定してある所定回数以上発生した場合
(5) 未処理のデータを逐次蓄積し、蓄積されたデータをリアルタイム処理対象とする場合、未処理のデータが一定量以上蓄積してリアルタイム処理に累積遅延を生ずるとき、蓄積されているデータのうち、当該リアルタイム処理の累積遅延を回復するために所定時間内において破棄したデータの量が、閾値として設定してある所定量以上であった場合
のいずれかの場合に所望のリアルタイム性を満たしていないと判定する。

尚、上記「揺らぎ値」とは、例えば、理想的な処理時刻に対する実際の処理時刻の誤差（これらの時刻の差の時間）の大きさを統計的に計測した値である。この揺らぎ値が大きくなると、リアルタイム性が劣化することになる。

上記の処理によって、リアルタイム処理の精度が保障されない端末Ａ，Ｂを用いて、平均して一定の時間間隔でリアルタイム処理を実行する場合に、所望のリアルタイム性を満たしていない場合に、ＣＰＵ負荷量の総計を低減し、その結果として、相対的に当該リアルタイム処理（例えば音声信号処理）に割り当てる処理時間を増加させることが可能となる。

尚、上記ではリアルタイム性を維持するリアルタイム処理として例えば音声信号処理を例として説明したが、これに限定されることはなく、映像信号処理のリアルタイム性を維持する場合にも同様に行うことができる。

以下、本発明を音声パケット送信処理に適用した例を図３乃至図５を参照して説明する。図３は音声送信処理部128を示す構成図であり、本実施例の音声送信処理部128はリアルタイム処理判定・制御部131と、前処理部132、パケット化処理部133、パケット送信処理部134から構成されている。また、本実施例では、音声入力処理部124には20msの十分な精度の時間間隔で音声データが入力されているとする。

前処理部132は、音声入力処理部124から入力された音声データに対して、サンプリング変換、エコー除去、雑音除去、符号化等の前処理を施す（Step1）。尚、これらの処理は任意であり、必要なければ行わなくても良い。

前処理部132において前処理を施された音声データは、パケット化処理部133に渡される。パケット化処理部133は、音声データを受け取ると、リアルタイム処理判定・制御部131に受け取った音声データのサイズ（この場合は20ms分のデータであることを表す160サンプルという値）を通知する（Step2）。

リアルタイム判定処理・制御部131は、当該音声データに対応するシーケンス番号とタイムスタンプ情報をパケット化処理部133に渡した（Step3）後、次回の音声データ処理に備えて、シーケンス番号を１増加させ（Step4）、タイムスタンプを今回送信した音声データのサンプル数に相当する値だけ増加させる（Step5）。

パケット化処理部133は、音声データ、シーケンス番号、タイムスタンプを用いてＲＴＰパケットを構成し（Step6）、パケット送信処理部134に渡す（Step7）。

パケット送信処理部134は、パケット化処理部133から受け取ったＲＴＰパケットを送信する（Step8）。

また、このとき、パケット送信処理部134は送信処理を行ったことをリアルタイム処理・制御部131に通知する（Step9）。これにより、リアルタイム処理・制御部131は当該パケットの送信処理が行われた実際の時間を知ることができる。

ここで、リアルタイム処理・制御部では、前回のパケットを送信した時刻・今回のパケットを送信した時刻、前回のパケット送信処理で送信した音声データ長を用いて、理想的な処理時刻を計算によって求めることができる。

例えば、図５に示すように、送信パケットのシーケンス番号iが０、１、２、・・・・n、タイムスタンプTSが0, 160, 320, 480, 640, 800, 960・・・(160×i)であらわされるとする。音声の処理単位が20msであるとすれば、各送信パケットの理想的な処理時刻TはT(0)=00:00, T(1)=00:20, T(3)=00:40, T(4)=00:60, T(5)=00:80, T(6)=00:100, T(7)=00:120である。

これに対して実際に処理が実行された時刻TrがTr(0)=00:00, Tr(1)=00:20, Tr(2)=00:55, Tr(3)=00:70, Tr(4)=00:80, Tr(5)=00:100, Tr(6)=00:120であるとする。このような場合には、たとえば所定時間内における実際の処理の実行時間間隔の揺らぎ値Ｄ，Ｄ’を次の(1)式或いは(2)式を用いて、理想的な処理時刻との差分を統計的に判定することができる。ここで、(1)式は移動平均による揺らぎ値Ｄを表し、(2)式は移動分散による揺らぎ値Ｄ’を表し、ｎは過去のｎパケットの処理時刻を用いて統計的な計算を行うことを表す。例えば、各音声パケットに含まれる音声データ長が20ms単位である場合には、所定時間として時間(n×20ms)内の揺らぎを観測することとなる。観測時間としては例えば、n=50とした場合には、所定時間として1sの間の処理の揺らぎを観測することとなる。

尚、ｉは０以上の整数である。また、(1)式及び(2)式の計算で、(i-n)が負の値をとる場合がある。この様な添え字が負となるような場合のTr(k)，T(k)をそれぞれ(3)式及び(4)式のように定義する（kが負の値であることに注意）。(3)式及び(4)式におけるdtは実行時間間隔の理想値であり、本実施例では20ms に設定している。

このような実際の処理の実行時間間隔の所定時間内における揺らぎ値Dが、許容される閾値を超えた場合に所望のリアルタイム性が満たされていないと判定することが可能となる。即ち、ＣＰＵ負荷により送信処理にリソースが割り当てられない場合には送信処理が滞り、処理遅延が発生する。理想的な処理時刻との差が一定の閾値を越えた場合に処理が間に合わないと判断する。

たとえば(1)式を適用する場合に、n=50とし、閾値をD＞20とすることもできる。この場合には、過去の1sの間の実際の実行時間間隔と理想的な実行時間間隔の差の平均が、20msを超えた場合に、所望のリアルタイム性を満たせていないと判定することとなる。

同様にして、たとえば、20msの時間間隔でパケット送信を行う場合に、各パケットの送信時刻を計測し、i番目のパケットを基準にi-nまでの過去のn個のパケットの送信間隔を移動平均或いは移動分散で計算し、この平均値或いは分散値が所定の範囲外となった回数又は所定の範囲内となった回数をカウントし、このカウント値が所定の閾値を超えた場合、或いは所定時間内における移動平均或いは移動分散の値の増加量が所定の閾値を超えた場合に、送信処理が所望のリアルタイム性を満たしていないと判定することも可能である。また、ＲＴＣＰに関する揺らぎ値を求める計算式を使ってリアルタイム性を判定しても良い。また、周知のＲＦＣ１８８９に記載されているインターバルジッター(interarrival jitter )を用いてリアルタイム性を判定してもよい。このインターバルジッターには、パケット送信間隔の揺らぎ値の推定値を示す計算方法が記載されている。即ち、受信装置が受信したｉ番目のＲＴＰパケットのタイムスタンプ値をSi、そのパケットの受信時刻をＲＴＰタイムスタンプの基準クロック周波数で表した値をRiとすると、受信装置は、ＲＴＰパケットを受信するごとに次の(5)式によりインターバルジッター（Ｊ）の値を更新する。受信したＲＴＰパケットはｉ番目であるとすると、

ただし、D(i,j)=(Rj-Ri)-(Sj-Si)=(Rj-Sj)-(Ri-Si)
D(i,j)はｊ番目のパケットの転送遅延とｉ番目のパケットの転送遅延の差を表している。従って、D(i-1,i)は連続して受信されたパケットの転送遅延の変動を表す。ＪはD(i-1,i)の移動平均を表す。厳密には、ＲＴＰタイムスタンプはパケットの送出時刻でなくデータの再生時刻を表すので、上記の式は転送遅延の変動でなく、データ符号化時点からパケット受信時点までの遅延の変動を示すことになる。

一方、送信処理が所望のリアルタイム性を満たしていないと判定された場合には、ＣＰＵの負荷量が高い状態にあると判定し、通信状態制御部121に対して、高負荷状態通知を行う。

通信状態制御部121では、高負荷状態通知を受けると、例えば、映像出力処理部123がディスプレイ１３に表示する画像のサイズやフレームレート、あるいは、映像送信処理部126が送信する映像パケットの符号化ビットレートやフレームレートを低減する等の制御を行うことによりＣＰＵ負荷量の総計の軽減を行う。この結果、装置本体１１は音声のリアルタイム処理を継続することが可能となる。

この例では一定の時間間隔で周期的に処理が行われるようなリアルタイム処理について述べたが、入力があるごとに特定の処理を行うような、一定の時間間隔で周期的に処理されない種類のリアルタイム処理に対して適用することも可能である。

たとえば、音声入力処理部から音声データが入力されてから、パケット送信処理部で出力されるまでに要した時間tp(i)を監視し、一定の所定時間（例えば30s）の間のtp(i)の平均値が、閾値（例えば5ms）を超えた場合にリアルタイム性を満たせていないと判定するようにすることで、一定の時間間隔で周期的に処理されないような例に対して適用することも可能である。

次に、本発明を音声パケット受信処理に適用した例を図６乃至図１０を参照して説明する。

音声パケット受信処理においても、実施例１の音声パケット送信処理と同様、所定時間内における実際の処理実行時間間隔の揺らぎ値Dに基づき、あるいは、所定回数の実際の処理の実行時間間隔の移動平均または移動分散が所定の範囲外あるいは所定の範囲内となった回数に基づき、当該処理が平均して一定の時間間隔で実行されているかどうかを判定することが可能である。

しかし本実施例では、音声パケット受信処理において、音声パケットの揺らぎ吸収処理制御を行った場合に、本発明を適用した処理の例について説明する。

まず、端末Aから送信された音声パケットを端末Bで受信する場合の、端末Bでの音声パケット受信処理の詳細を図６の音声受信処理部の機能的構成例を参照して説明する。図６に示すように、音声受信処理部129は、リアルタイム処理判定・制御部141と、パケット受信処理部142、揺らぎ吸収バッファ（FIFOバッファ）143、パケット取り出し部144から構成されている。

他の端末から受信した音声パケットは、音声受信処理部129の中の、パケット受信処理部142で受信される。そして、パケット受信処理部142は、受信したパケット中のＲＴＰシーケンス番号、ＲＴＰタイムスタンプを読み取って、これらに基づいて他端末が送出した順番になるように受信パケットを整列した上で揺らぎ吸収バッファ143に格納する。尚、受信パケットの順番が入れ替わっている場合には、パケット受信処理部142において、順番を元に戻す処理が行われる。

パケット受信処理部142において音声パケットを揺らぎ吸収バッファ143に格納する処理は、パケットを受信する毎に行われる。それに対して、パケット取り出し処理部144によるパケットの取り出し処理は、リアルタイム処理判定・制御部141の制御により、例えば図７に示すように、20msの時間間隔で定期的に行われる処理である。音声出力処理部125へのデータの送出は20msの時間間隔で20ms分の音声を定常的に送出する必要があり、この処理が滞ると音声再生が正しく行われず音切れが発生する。

リアルタイム処理判定・制御部141では、たとえば、平均20msの時間間隔でパケット取り出し処理部144への取り出し指示を行う。このような所望の時間間隔での処理の駆動は、処理休止命令等を用いて、休止処理部(OS:Operating System)150に処理休止要求を行うことにより実現される。

例えば、20msの時間間隔で処理を行う必要がある場合、リアルタイム処理判定・制御部141では前回処理起動時刻t(i）に20msを足した時刻をt(i+1）とすると、現在時刻tからの差分[t(i+1)-t]時間後にイベントを発生するように休止処理部150に処理休止命令を出し、処理を休止する。

休止処理部150では、処理休止命令により指定された時間以上の時間が経過した場合に、リアルタイム処理判定・制御部141に対して復帰イベントを発生する。

この復帰イベントを受けてリアルタイム処理判定・制御部141では、理想的には20msの時間間隔でパケット取り出し処理を行うことができる。

しかし実際には、休止処理部150は、処理休止命令で指定された時間である20ms以上の休止を保証するのみであり、正しく平均的に20msの時間間隔でデータを処理することができない場合がある。

このような場合には、リアルタイム処理判定・制御部141では、リアルタイム処理判定・制御部141がパケット取り出し処理を駆動した際に、システムクロックで得られた現在時刻と、本来処理が実行されるべきだった起動目標時刻とを比較することにより処理の遅延を検出することができる。

処理の遅延が生じているものの、所定の閾値ｄｘ以下である場合には、リアルタイム処理判定・制御部141は休止処理部150に対して処理休止命令を発行せず、処理の遅延が回復するまでの間、パケット取り出し処理部144に対して連続でパケット取り出し処理を指示する。この連続動作により遅延を回復することができる。

ここで、処理の遅延が閾値ｄｘを超えていた場合には、リアルタイム処理判定・制御部141は、パケット取り出し処理部144に揺らぎ吸収バッファ143上の音声データの破棄を指示することで、遅延の回復を試みる。例えば、図７に示すようにパケットＰ２を読み出した後に60msの処理遅延が発生した場合には60ms分のパケットＰ３〜Ｐ５を破棄して遅延を回復する。尚、本実施例では40msを閾値とし、40ms以上の処理遅延が発生したときにデータを破棄して遅延を回復するようにしている。

これにより、パケット取り出し処理部144では、データを破棄した上で、遅延を回復した適切な時刻の音声データを音声出力処理部125に送出することが可能となる。

このときリアルタイム処理判定・制御部141では、遅延回復のために連続動作を行った回数、もしくは破棄された音声データの量を保持し、所定時間内に連続動作を行った回数が所定の閾値を超えた場合、または所定時間内に破棄された音声データの量が所定の閾値を超えた場合に、ＣＰＵの負荷量が高い状態にあると判定し、通信状態制御部121に対して、高負荷状態通知を行う。

通信状態制御部121では、高負荷状態通知を受けると、例えば、映像出力処理部123がディスプレイ１３に表示する画像のサイズやフレームレート、あるいは、映像送信処理部126が送信する映像パケットの符号化ビットレートやフレームレートを低減する等の制御を行うことによりＣＰＵ負荷量の総計の軽減を行う。この結果、装置本体１１は音声のリアルタイム処理を継続することが可能となる。

次に、図９乃至図１２のフローチャート等を参照して本実施例における音声受信処理の詳細を説明する。

リアルタイム処理判定・制御部141は、駆動を開始すると初期化処理を行う（Step11）。この初期化処理では、パケット取り出し部144から揺らぎ吸収バッファ143に対してバッファクリア要求を送出し、これにより揺らぎ吸収バッファ143はバッファ内を空の状態にする。さらに、初期化処理では、パケット取り出し部144は揺らぎ吸収バッファ143内に格納されているパケットの数を表す変数ｎを０に設定すると共にモードをアイドリングモードに設定する。このとき、パケット受信処理部142は、図８に示すように、パケットＰを受信した場合には受信したパケットＰを順番に揺らぎ吸収バッファ143に格納してゆく。

次いで、リアルタイム処理判定・制御部141は、パケット取り出し部144によって処理開始時刻を取得する（Step12）。この処理開始時刻の取得では、パケット取り出し部144はリアルタイム処理判定・制御部141から現在時刻を取得して、変数StartTime（実行開始時刻）に現在時刻を設定する。

この後、パケット取り出し部144は、変数TargetTime（実行開始目標時刻）に変数StartTime（実行開始時刻）の値を設定すると共に、変数CheckStart(負荷監視開始時刻)に変数StartTime（実行開始時刻）の値を設定し、変数ContinueCnt（処理休止命令を発行せず、連続して処理を行った回数の累計値），LastContinueCnt（今回の負荷監視の時間区間の開始時におけるContinueCntの値），CutCnt（遅延回復のために破棄した音声データの破棄サンプル数の累計値），LastCutCnt（今回の負荷監視の時間区間の開始時におけるCutCntの値）のそれぞれの値を０に設定する（Step13）。尚、Step13の処理は、後述する負荷判定処理で用いられる値を初期化する処理で、駆動開始時のみに実行する。

次に、リアルタイム処理判定・制御部141が後述する負荷判定処理を行った後、パケット取り出し部144が、モードがアイドリングモードに設定されているか送出モードに設定されているかを判定し（Step15）、アイドリングモードに設定されているときは揺らぎ吸収バッファ143にパケット数確認要求を送出し、揺らぎ吸収バッファ143内に格納されているパケット数を取得してこの値を変数ｎに設定する(Step16)。

さらに、パケット取り出し部144は、揺らぎ吸収バッファ143内のパケット数ｎが予め設定されている基準値Ｎよりも多いか否かを判定する（Step17）。この基準値Ｎはパケット受信における揺らぎを吸収するための値であり、パケット受信に遅延が生じたときの遅延による音声再生の途切れを防止するために設定されている。

この判定の結果、パケット数ｎが基準値Ｎを超えているときは後述するStep21の処理に移行し、パケット数ｎが基準値Ｎ以下であるときは次回モードをアイドリングモードに設定（Step18）した後、後述するStep26の処理に移行する。

また、上記Step15の判定の結果、モードが送出モードに設定されているときは、パケット取り出し部144は、揺らぎ吸収バッファ143にパケット数確認要求を送出し、揺らぎ吸収バッファ143内に格納されているパケット数を取得してこの値を変数ｎに設定（Step19）した後、変数ｎが０であるか否かを判定する（Step20）。

この判定の結果、変数ｎが０であるときは後述するStep23の処理に移行し、変数ｎが０以外のときは変数ｎが最大許容値Ｎmaxを超えているか否かを判定する（Step21）。この判定の結果、変数ｎが最大許容値Ｎmax以下のときは後述するStep24の処理に移行し、変数ｎが最大許容値Ｎmaxを超えているときは、パケット取り出し部144は揺らぎ吸収バッファ143に対してバッファクリア要求を送出して揺らぎ吸収バッファ143内に格納されているパケットを全て消去する（Step22）。

ここで、変数ｎすなわち揺らぎ吸収バッファ143内に格納されているパケット数が最大許容量Ｎmaxを超えているときは、パケット取り出し部144による処理遅延の遅れを取り戻すことができないため、リアルタイムな処理を維持するために一時的に揺らぎ吸収バッファ143内のパケットを全て消去することによって処理遅延をなくしている。

次いで、パケット取り出し部144は、累積処理遅延をクリアするために変数TargetTimeに変数StartTimeの値を設定して（Step23）、前記Step18の処理に移行する。

前記Step21の判定の結果、変数ｎが最大許容値Ｎmax以下のときは、パケット取り出し部144は、揺らぎ吸収バッファ143から１パケットを取り出して音声出力処理部125に送出する（Step24）と共に、次回モードを送出モードに設定する（Step25）。音声出力処理部125は、パケット取り出し部144から受け取ったパケットから音声データを抽出して、この音声データを音声再生する。この音声再生にはＸmsの時間を要する。

この後、パケット取り出し部144は、休止時間の算出処理を行う（Step26）。この休止時間の算出処理では、図１１に示すように、変数StartTimeの値から変数TafgetTimeの値を引いた値を誤差時間ERRとする。駆動開始時においては、変数StartTimeの値と変数TargetTimeの値が等しいので誤差時間ERRは０である。

次いで、リアルタイム処理判定・制御部141から現在時刻を取得して、これを変数EndTime（処理終了時刻）に設定する。この処理終了時刻はパケット読み出し処理を終了した時刻である。

さらに、変数StartTime（処理開始時刻）に音声再生処理に要した時間Ｘmsを加算した値から誤差時間ERRを差し引いた値を変数TargetTime（実行開始目標時刻）の値として設定する。さらにまた、この変数TargetTime（実行開始目標時刻）の値から変数EndTime（処理終了時刻）の値を引いた値を休止時間SleepTimeとして設定する。

次に、パケット取り出し部144は、上記算出した休止時間SleepTimeの値が０よりも大きいか否かを判定し（Step27）、休止時間SleepTimeの値が０以下の場合は後述するStep29の処理に移行する。また、休止時間SleepTimeの値が０よりも大きいときは周知のSleep命令（処理休止命令）を実行して休止時間SleepTimeの処理停止状態に入り（Step28）、休止時間SleepTime経過後に前記Step12の処理を開始する。

また、前記Step27の判定の結果、休止時間SleepTimeの値が０以下の場合は、累積遅延が許容量を超えているか否かを判定する（Step29）。この判定では、変数sleeptimeの絶対値が予め設定されている所定の最大許容値maxdilaytimeよりも大きいとき、累積遅延が許容量を超えているものと判定する。

この判定の結果、累積遅延が許容量を超えていないときは連続処理カウンタの値を１増加させ（ContinueCnt++;）（Step30）、上記Step12の処理に移行し、遅延回復のために待機せず連続動作する。ここで、ContinueCntは、遅延回復のために処理休止命令を発行せず連続して処理を行った回数の累計値である。また、累積遅延が許容量を超えているときは、パケット取り出し部144は遅延回復をあきらめ、揺らぎ吸収バッファ143に対してバッファクリア要求を送出して揺らぎ吸収バッファ143内に格納されているパケットを全て消去すると共に変数TargetTimeに現在の時刻を設定して累積処理遅延をクリアし、さらにデータ破棄カウンタを破棄したデータのサンプル数だけ増加する（CutCnt+=破棄したデータ量;）（Step31）。ここで、CutCntは、遅延回復のために破棄した音声データサンプルの累計値である。この後、前記Step12の処理に移行して前述した処理を繰り返す。

ここで、sleeptimeの絶対値を20msで割った商をs＿div、余りをs＿modとし、揺らぎ吸収バッファ143内に格納されているパケットを、s＿div個だけ消去すると共に、変数TargetTimeに「現在時刻−s＿mod」を設定するようにすることもできる。この後、前記Step12の処理に移行して前述した処理を繰り返す。

このSleep命令では、休止時間SleepTime以上経過してから次の処理を行うことが規定されているのみであり、装置本体１１における処理負荷が高い場合には休止時間SleepTimeを超えた時間を経過した後に処理が行われることもある。しかし、上記のようなリアルタイム処理を行うことによって、処理負荷が高い場合にも精度の高い実時間処理を行うことが可能である。

即ち、上記のような精度の保証されないSleep命令を用いて平均して目標の一定時間間隔でリアルタイム処理を行うとき、装置本体１１が高負荷に陥り、処理遅延の回復が見込めないような場合にも、前述したように揺らぎ吸収バッファ143内のパケットを全て消去して累積処理遅延をリセットすることにより、システムが破綻しないようにして最大の遅延を制御することができる。

さらに、一定時間間隔で揺らぎ吸収バッファ143からパケットを取り出して音声出力処理を実行するために、パケット取り出し処理を実行した後、Sleep命令を設定するとき、パケット取り出し処理を実行するのに要した時間及び誤差時間ERRを考慮してSleep命令で設定する休止時間SleepTimeを設定すると共に算出した休止時間SleepTimeが０以下のときは継続してパケット読み出し処理を行うので、処理遅延を最小限に抑えることができる。

従って、一定時間（本実施例ではＸms）からパケット読み出し処理に要した時間と誤差時間ERRを差し引いた時間が休止時間SleepTimeとして設定されるので、パケット読み出し処理の開始時刻と次に行われるパケット読み出し処理の開始時刻との間の時間は平均してほぼ一定時間に保たれる。

次に、本実施例における負荷判定処理の詳細を図１２のフローチャートを参照して説明する。

リアルタイム処理判定・制御部141は負荷判定を行うために、((ContinueCnt−LastContinueCnt)＞ContinueThres)であるか又は((CutCnt−LastCutCnt)＞CutThres)であるかを判定する（Step41）。ここで、ContinueCntは遅延回復のために処理休止命令を発行せず連続して処理を行った回数の累計値、LastContinueCntは直近の計測時間区間の負荷計測を開始した際のContinueCntの値を保持している。これらの値の差は、直近の負荷計測区間において負荷判定のための計測を開始してから、これまでに処理休止命令を発行せずに連続動作した回数を表す。

また、CutCntは遅延回復のために破棄した音声データサンプル累計値、LastCutCntは直近の計測時間区間の負荷計測を開始した際のCutCntの値を保持している。これらの値の差は、直近の負荷計測区間において負荷判定のための計測を開始してから、これまでに遅延回復のために破棄した音声データのサンプル数の累計を表す。

前記Step41の判定式では、一定時間以内に連続動作した回数が連続動作閾値ContinueThresを超えているか、もしくは一定時間以内に破棄した音声データの量が連続動作閾値ContinueThresを超えている場合に、所望のリアルタイム性を満たせていないと判定する。

前記Step41の判定の結果、いずれの条件も満たしていないときは高負荷状態に至っていないものとして負荷判定処理を終了する。また、少なくとも何れか一方の条件を満たしているときは、高負荷状態にあるものとして映像通信のフレームレートを半分にする（Video＿frame＿rate＝(int)Video＿frame＿rate/2=;）（Step42）。

次に、Videoのフレームレートが下限値以下になったか否かを判定する。即ち、変数Video＿frame＿rateの値が下限値Video＿frame＿rate＿MINの値よりも小さいか否かを判定する（Video＿frame＿rate＜Video＿frame＿rate＿MIN？）（Step43）。この判定の結果、Videoのフレームレートが下限値以下ではないときは後述するStep47の処理に移行し、Videoのフレームレートが下限値以下になったときは映像通信フレームレートを下限値に設定する（Video＿frame＿rate＝１）と共にビットレートを半分に設定する（Video＿bit＿rate/2=;）（Step44）。

この後、ビットレートが下限値以下になったか否かを判定する。即ち、変数Video＿bit＿rateの値が下限値Video＿bit＿rate＿MINの値よりも小さいか否かを判定する（Video＿bit＿rate＜Video＿bit＿rate＿MIN）（Step45）。

この判定の結果、ビットレートが下限値以下でないときは後述するStep47の処理に移行し、ビットレートが下限値以下になったときは、映像通信のフレームレートを下限値に設定すると共に、ディスプレイ１３に過負荷のワーニングを表示して、ユーザに対して音声と映像以外のアプリケーションの停止を依頼する、もしくは、よりＣＰＵ能力の高い装置で利用するように指摘する（Step46）。

次いで、負荷監視開始から所定の一定時間が経過したか否かを判定する（(CheckStart−StartTime)＞CheckTimeLen？）（Step47）。この判定の結果、負荷監視開始から一定時間（CheckTimeLen）が経過していないときは負荷判定処理を終了し、負荷監視開始から一定時間（CheckTimeLen）が経過したときは負荷監視情報を更新して（Step48）、負荷判定処理を終了する。ここで、負荷監視情報を更新する際、変数CheckStartの値として変数StartTimeの値を設定する（CheckStart＝StartTime;）と共に、変数LastContinueCntの値として変数ContinueCntの値を設定し（LastContinueCnt＝ContinueCnt;）、変数LastCutCntの値として変数CutCntの値を設定する（LastCutCnt＝CutCnt;）。

ここで、ContinueThres，CutTres，CheckTimeLenの値は、たとえばContinueThres＝10（回），CutThres＝1600（sample），CheckTimeLen＝1sとすることができる。

以上のように本実施例では、所定の監視時間内に所定回数以上の連続動作もしくは所定量以上の揺らぎ吸収バッファ143内のデータ破棄が行われた場合に、ＣＰＵ負荷量が高くリアルタイム処理が継続できない状態にあると判定して、ＣＰＵ負荷量の総計を低減するような制御を行う。尚、本実施例では、揺らぎ吸収バッファ143内のデータ破棄を、破棄されたデータ量で計っているが、破棄した回数で判定しても良い。

前述した実施例１，２では、通信状態制御部121が、映像送信処理部126に対して、送信する映像パケットの符号化ビットレートとフレームレートの制御を行う際に、まずフレームレートを下限値まで低減する処理を行ってから、次に符号化ビットレートを低減する処理を行う例を示した。

本実施例では、通信状態制御部121が、映像出力処理部123に対して、ディスプレイ１３に表示する画像のサイズとフレームレートの制御を行う際に、サイズとフレームレートの各パラメータの設定を任意の組み合わせで行いつつ、ＣＰＵ負荷量の総計を順時、低減させる例について説明する。

本実施例では、画像のフレームレート、サイズ等の複数のパラメータ設定を、負荷が順に軽くなるような値にあらかじめ定義された負荷量表に保持する。そして、リアルタイム処理判定・制御部から通信状態制御部121に対して、高負荷状態通知が行われた場合に、この負荷量表に基づき、パラメータの負荷量設定を、負荷が軽くなるように段階的に下げることで処理制御を行う。

パラメータ設定の例を、図１３のパラメータ指定による負荷軽減方法を説明する図に示す。図中のＬＶは負荷量を表し、値が大きいほど負荷が高く、値が小さいほど負荷が低い。ＬＶが０では画像通信を行わず、音声のみの通信とする。

図１３においては、負荷に応じてＬＶを１０から１に段階的に落とすことで負荷を軽減する。「ＶＧＡ、３０ｆｐｓ」と「ＶＧＡ，１５ｆｐｓ」では負荷は１／２になる。ＶＧＡとＣＩＦでは画面サイズが１／３になるので、「ＶＧＡ，１０ｆｐｓ」と「ＣＩＦ，３０ｆｐｓ」が同等の負荷である。また、ＣＩＦとＱＣＩＦでは画面サイズが１／４となるので、負荷では「ＣＩＦ，１０ｆｐｓ」＞「ＱＣＩＦ，３０ｆｐｓ」となる。

同様に、音声・映像以外にアプリケーション共有、画面共有等を行う場合にも、あらかじめそれぞれの負荷を考慮して負荷量表にしておき、ＬＶに応じて機能制限を設けることもできる。

尚、本実施例において、負荷量に関してあらかじめ正確な知見が得られている場合には、従来法（例えば、(1)、(2)など）と本実施例の方法を組み合わせて利用することも可能である。

また、ディスプレイ１３に表示する画像の情報量とフレームレートの制御を行う際に、画像の情報量とフレームレートの各パラメータの設定を任意の組み合わせで行いつつ、且つその他の実行中アプリケーションによるＣＰＵ負荷量を低下させて、ＣＰＵ負荷量の総計を順時低減させてもよい。尚、上記画像の情報量とは送信側端末において符号化対象となる画像の情報量であり、この情報量を低減することにより送信側端末における符号化処理及び受信側端末における復号化処理に要するＣＰＵ負荷を低減することができる。

また、図１４に示すように、優先するリアルタイム処理以外の処理となるアプリケーションに対して優先順位を設定したテーブルを備えておき、ＣＰＵ負荷量に応じて音声通信処理以外の優先順位の低いアプリケーションから実行を禁止するようにしてもよい。図中のＬＶはＣＰＵ負荷量を表し、値が大きいほど負荷が高く、値が小さいほど負荷が低い。ＬＶが０で音声通信処理以外の処理を行わず、音声通信処理のみを実行するものとする。図１４においては、○印は実行許可を表すと共に×印は実行禁止を表し、負荷に応じてＬＶを１０から１に段階的に落とすことでＣＰＵ負荷を軽減する。また、図１４においては、インスタントメッセージ送受信、映像通信、端末間ファイル転送、アプリケーション１、アプリケーション２の順に優先順位を低く設定している。ここで、アプリケーション１、アプリケーション２は通信に関係するアプリケーションであってもよいし、通信に関係のないアプリケーションであってもよい。

本実施例では、利用中のシステムの処理性能ではリアルタイム処理を行うことが困難であると判定した場合に、ディスプレイ１３に利用するサービスを制限しなければリアルタイム処理が行えないことを示すメッセージを表示するようにした。これによりユーザの意思で処理負荷を低減するように設定を変更することが可能になる。

尚、上記実施形態及び各実施例は本発明の一具体例であって本発明が上記実施形態及び各実施例の構成のみに限定されることはない。本発明の処理制御装置はコンピュータ装置とコンピュータプログラムによって構成することもでき、また、ハードウェアのみによっても構成することができることは言うまでもない。

また、本発明の処理制御装置をコンピュータ装置とコンピュータプログラムによって構成する場合には、コンピュータプログラムを通信ネットワークを介して配布することにより、任意のコンピュータ装置を本発明の処理制御装置として動作させることが可能である。

さらに、上記のリアルタイム処理プログラムを記憶したコンピュータ読みとり可能な情報記憶媒体を作製するとこによっても、上記リアルタイム処理プログラムを容易に配布することができると共に、任意のコンピュータ装置を上記処理制御装置として動作させることができる。

本発明の一実施形態におけるリアルタイム処理システムを示す構成図 本発明の一実施形態における端末装置本体の機能構成を示す図 本発明の一実施形態における音声送信処理部を示す構成図 本発明の一実施形態における音声送信処理を説明するフローチャート 本発明の一実施形態におけるパケット送信処理の遅延を説明する図 本発明の一実施形態における音声受信処理部を示す構成図 本発明の一実施形態における遅延発生時におけるパケット受信処理を説明する図 本発明の一実施形態における揺らぎ吸収バッファへのパケット格納及び取り出しを説明する図 本発明の一実施形態における音声受信処理を説明するフローチャート 本発明の一実施形態における音声受信処理を説明するフローチャート 本発明の一実施形態における休止時間の算出方法を説明する図 本発明の一実施形態における音声受信処理を説明するフローチャート 本発明の一実施形態におけるパラメータ指定による負荷軽減方法を説明する図 本発明の一実施形態におけるパラメータ指定による負荷軽減方法を説明する図

符号の説明

１１…装置本体、１２…ＣＣＤカメラ、１３…ディスプレイ、１４…マイク、１５…スピーカ、２０…ＩＰ網、110…ＧＵＩ制御部、120…通信制御部、121…通信状態制御部、122…映像入力処理部、123…映像出力処理部、124…音声入力処理部、125…音声出力処理部、126…映像送信処理部、127…映像受信処理部、128…音声送信処理部、129…音声受信処理部、131…リアルタイム処理判定・制御部、132…前処理部、133…パケット化処理部、134…パケット送信処理部、141…リアルタイム処理判定・制御部、142…パケット受信処理部、143…揺らぎ吸収バッファ、144…パケット取り出し部、150…休止処理部（ＯＳ）。

Claims (13)

1. 複数の処理を時分割多重処理で同時に実行すると共に所定の実行対象処理をリアルタイムで実行する処理制御装置において、
   リアルタイム動作を行うときに、前記実行対象処理に対して実際にリアルタイム処理を開始した時刻を用いて前記実行対象処理のリアルタイム性を監視する手段と、
   前記実行対象処理を前回開始した時刻から今回の処理開始時刻までの経過時間、または前記実行対象処理が実行されるべき処理時刻と前記実行対象処理が実際に実行された時刻との差の時間の何れか一方に関する所定時間内における統計的な値が所定の許容範囲外であるときに、所望のリアルタイム性が満たされていないと判定する手段と、
   前記実行対象処理の処理開始予定時刻と、実際の処理開始時刻の差から累積処理遅延時間を算出する手段と、
   前記算出された累積処理遅延時間が処理間隔より短い場合には、累積処理遅延時間が減少するように次回処理開始予定時刻まで処理休止命令で休止する時間を短くして遅延を回復する手段と、
   前記算出された累積処理遅延時間が処理間隔より大きい場合には、処理休止命令を実行せず連続で処理を行うことにより累積処理遅延を回復する手段と、
   累積処理遅延を回復するために処理休止命令を実行せず連続で処理を行った回数を計測する手段と、
   一定時間の間に連続処理を行った回数が所定の閾値を超えたときに、所望のリアルタイム性が満たされていないと判定する手段と、
   所望のリアルタイム性が満たされていないと判定されたときに、前記実行対象処理以外の処理を停止するか或いは該実行対象処理以外の処理の処理量を削減する手段とを備えている
   ことを特徴とする処理制御装置。
2. 所定時間内における前記経過時間の揺らぎ値または前記差の時間が所定の閾値を超えたときに所望のリアルタイム性が満たされていないと判定する手段を備えている
   ことを特徴とする請求項１に記載の処理制御装置。
3. 所定回数の前記経過時間または前記差の時間の移動平均或いは移動分散の値が所定の許容範囲外となった回数をカウントし、該カウント値が所定の閾値を超えたときに所望のリアルタイム性が満たされていないと判定する手段を備えている
   ことを特徴とする請求項１に記載の処理制御装置。
4. 所定時間内における前記経過時間または前記差の時間の移動平均或いは移動分散の値の増加量が所定の閾値を超えたときに所望のリアルタイム性が満たされていないと判定する手段を備えている
   ことを特徴とする請求項１に記載の処理制御装置。
5. 前記累積処理遅延時間が所定の閾値よりも大きくなったときには、累積処理遅延時間に相当する分の処理待ちのデータを破棄することで、累積処理遅延を回復する手段を備えている
   ことを特徴とする請求項１に記載の処理制御装置。
6. 前記実行対象処理として音声通信処理を行うことを特徴とする請求項１乃至請求項５の何れかに記載の処理制御装置。
7. 前記実行対象処理以外の処理の処理量を削減する手段として、送信する映像パケットの符号化ビットレートを低減する手段、或いは送信する映像パケットのフレームレートを低減する手段のうちの少なくとも１つの手段を備えている
   ことを特徴とする請求項６に記載の処理制御装置。
8. 複数の処理を時分割多重処理で同時に実行する処理制御装置を用いて所定の実行対象処理をリアルタイムで実行する処理制御方法において、
   前記処理制御装置は、
   リアルタイム動作を行うときに、前記実行対象処理に対して実際にリアルタイム処理を開始した時刻を用いて前記実行対象処理のリアルタイム性を監視するステップと、
   前記実行対象処理を前回開始した時刻から今回の処理開始時刻までの経過時間が、所望の処理間隔とどれだけの時間差があるかを統計的な基準で判定するステップと、
   前記処理間隔の時間差の統計的な値が所定の許容範囲外であるときに、所望のリアルタイム性が満たされていないと判定するステップと、
   前記実行対象処理の処理開始予定時刻と、実際の処理開始時刻の差から累積処理遅延時間を算出するステップと、
   前記算出された累積処理遅延時間が前記所望の処理間隔より短い場合には、累積処理遅延時間が減少するように次回処理開始予定時刻まで処理休止命令で休止する時間を短くして遅延を回復するステップと、
   前記算出された累積処理遅延時間が前記所望の処理間隔より大きい場合には、処理休止命令を実行せず連続で処理を行うことにより累積処理遅延を回復するステップと、
   累積処理遅延を回復するために処理休止命令を実行せず連続で処理を行った回数を計測するステップと、
   一定時間の間に連続処理を行った回数が所定の閾値を超えたときに、所望のリアルタイム性が満たされていないと判定するステップと、
   所望のリアルタイム性が満たされていないと判定されたときに、前記実行対象処理以外の処理を停止するか或いは該実行対象処理以外の処理の処理量を削減するステップとを実施する
   ことを特徴とする処理制御方法。
9. 前記処理制御装置は、
   所定時間内における前記経過時間または前記時間差の揺らぎ値が所定の閾値を超えたときに所望のリアルタイム性が満たされていないと判定するステップを実施する
   ことを特徴とする請求項８に記載の処理制御方法。
10. 前記処理制御装置は、
    所定回数の前記経過時間または前記時間差の移動平均或いは移動分散の値が所定の許容範囲外となった回数をカウントするステップと、
    前記カウント値が所定の閾値を超えたときに所望のリアルタイム性が満たされていないと判定するステップとを実施する
    ことを特徴とする請求項８に記載の処理制御方法。
11. 前記処理制御装置は、
    所定時間内における前記経過時間または前記時間差の移動平均或いは移動分散の値の増加量が所定の閾値を超えたときに所望のリアルタイム性が満たされていないと判定するステップを実施する
    ことを特徴とする請求項８に記載の処理制御方法。
12. 前記処理制御装置は、
    前記累積処理遅延時間が所定の閾値よりも大きくなったときには、累積処理遅延時間に相当する分の処理待ちのデータを破棄することで、累積処理遅延を回復するステップを実施する
    ことを特徴とする請求項８に記載の処理制御方法。
13. 複数の処理を時分割多重処理で同時に実行するコンピュータ装置において、所定の実行対象処理をリアルタイムで実行するリアルタイム処理を実行するプログラムであって、
    請求項８乃至請求項１２の何れかに記載のステップを含むことを特徴とする処理制御プログラム。

Images