(57)【要約】【課題】データ処理の途中で処理を中断して別の処理を優先させるとき、中断する処理の進捗状態に応じて退避・復帰に要するオーバーヘッドを少なくする。【解決手段】ＣＰＵ(１１６)が画像処理などに用いられるアクセラレータ（１０６〜１０９）を用いて一のタスクを処理中に、アクセラレータを別のタスクの処理に割り当てることが要求されたとき、ＣＰＵは別のタスクの処理を一のタスクの処理よりも優先させる場合に中断フラグをセットし、一のタスクによるアクセラレータの処理の段階に応じて予め決められたタイミングで中断フラグのセット状態が検出されることによって、アクセラレータを別のタスクの処理に利用可能にする。セットされた中断フラグの検出タイミングを、中断される側のタスクの処理の進捗状態に応じて決定するから、中断されるタスクの処理にとって退避・復帰のオーバーヘッドを少なくするタイミングでタスクスイッチ可能になる。【選択図】図１
2010181989.tif 000002
【特許請求の範囲】
【請求項１】
複数のタスクを処理するＣＰＵと、前記ＣＰＵからの指示に従って異なるタスクの処理に共用されるアクセラレータと、を有し、
前記ＣＰＵがアクセラレータを用いて一のタスクを処理中に、前記アクセラレータを別のタスクの処理に割り当てることが要求されたとき、前記ＣＰＵは前記別のタスクの処理を前記一のタスクの処理よりも優先させる場合に中断フラグをセットし、前記一のタスクによる前記アクセラレータの処理の段階に応じて予め決められたタイミングで前記中断フラグのセット状態が検出されることによって、前記アクセラレータが前記別のタスクの処理に利用可能にされる、データ処理装置。
【請求項２】
前記アクセラレータが前記別のタスクの処理に利用可能にされる場合には、前記ＣＰＵが前記一のタスクの処理が中断直前の状態に復帰可能に退避を行う、請求項１記載のデータ処理装置。
【請求項３】
前記退避すべきデータは前記中断フラグの検出タイミングに応じて決定される、請求項２記載のデータ処理装置。
【請求項４】
前記ＣＰＵは、テーブルを参照することによって、前記退避すべきデータを判別する、請求項３記載のデータ処理装置。
【請求項５】
前記ＣＰＵは、前記別のタスクの処理を前記一のタスクの処理よりも優先させる必要がない場合には当該別のタスクの処理を前記一のタスクの処理完了まで待たせる、請求項１記載のデータ処理装置。
【請求項６】
前記ＣＰＵは前記別のタスクの処理を前記一のタスクの処理よりも優先させるか否かを、タスクの優先度によって判別する、請求項１記載のデータ処理装置。
【請求項７】
前記ＣＰＵは、テーブルを参照することによって、前記アクセラレータの処理の段階に応じて予め決められたタイミングを判別する、請求項1記載のデータ処理装置。
【請求項８】
前記アクセラレータは、画像処理用の画像処理ハード部と、画像処理用のデータを一時的に蓄積するデータバッファと、前記ＣＰＵからの指示に従って前記画像処理ハード部及びデータバッファを制御する画像処理制御部を有し、
前記画像処理ハード部は、前記データバッファから供給される画像データを演算し、演算結果を前記データバッファに書き戻し、書き戻されたデータと別のデータを用いて演算を行う動作を繰り返す繰り返し演算によって画像処理が可能にされる、請求項１記載のデータ処理装置。
【請求項９】
複数のタスクを処理するＣＰＵと、前記ＣＰＵからの指示に従って異なるタスクの処理に共用されるアクセラレータと、を有し、
前記ＣＰＵがアクセラレータを用いて一のタスクを処理中に、前記アクセラレータを別のタスクの処理に割り当てることが要求されたとき、
前記ＣＰＵは前記別のタスクの処理を前記一のタスクの処理よりも優先させる場合に中断フラグをセットしてから当該別のタスクを待ち行列に繋いで前記一のタスクの中断を待ち、
前記一のタスクによる前記アクセラレータの処理の段階に応じて予め決められたタイミングで前記アクセラレータが前記中断フラグのセット状態を検出することによって、前記一のタスクの処理が中断直前の状態に復帰可能に退避が行われると共に、当該一のタスクが待ち行列に繋がれて、前記別のタスクの処理に前記アクセラレータが利用可能にされる、データ処理装置。
【請求項１０】
前記退避すべきデータは前記中断フラグの検出タイミングに応じて決定される、請求項９記載のデータ処理装置。
【請求項１１】
前記ＣＰＵは、テーブルを参照することによって、前記退避すべきデータを判別する、請求項１０記載のデータ処理装置。
【請求項１２】
前記待ち行列は、後から書き込まれたデータはそのデータのタスクの優先度より低い優先度のタスクのデータよりも先に読み出し可能とする、タスク優先度付きＦＩＦＯとされる、請求項９記載のデータ処理装置。
【請求項１３】
前記ＣＰＵは、前記別のタスクの処理を前記一のタスクの処理よりも優先させる必要がない場合には当該別のタスクの処理を前記一のタスクの処理完了まで待たせる、請求項９記載のデータ処理装置。
【請求項１４】
前記ＣＰＵは、テーブルを参照することによって、前記アクセラレータの処理の段階に応じて予め決められたタイミングを判別する、請求項９記載のデータ処理装置。
【請求項１５】
前記アクセラレータは、画像処理用の画像処理ハード部と、画像処理用のデータを一時的に蓄積するデータバッファと、前記ＣＰＵからの指示に従って前記画像処理ハード部及びデータバッファを制御する画像処理制御部を有し、
前記画像処理ハード部は、前記データバッファから供給される画像データを演算し、演算結果を前記データバッファに書き戻し、書き戻されたデータと別のデータを用いて演算を行う動作を繰り返す繰り返し演算によって画像処理が可能にされる、請求項９記載のデータ処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の画像処理機能を実現するマルチタスクに対応した画像処理装置に関し、特に、画像処理を中断する事が可能な画像処理装置に関する。
【背景技術】
【０００２】
計算機技術、および映像技術の進化により、複数の画像処理機能を１つの画像処理装置で実現する事が重要となってきている。例えば自動車に搭載するカメラを用いた画像処理装置では、コストを低減する目的から、歩行者検知や、雨滴検知、車線認識など、複数の画像処理機能を１つの画像処理装置で処理する事が求められている。複数の画像処理機能を１つの装置で実行する場合、計算機は、複数ある機能をタスクといわれる細かい処理機能に分割して処理を分割する。ここで、それぞれのタスクには優先順位があり、例えば自動車に搭載するカメラを用いた画像処理タスクが雨滴検知タスクと歩行者検知タスクがあった場合、ワイパー動作にからむ雨滴検知よりも衝突及びその回避のためのブレーキ制御に絡む歩行者検知に高い優先度が与えられる事が考えられる。さらに自動車などに代表される画像処理装置では多くの場合実時間で処理する事が期待されるが、タスクの優先度が高ければ高いほど、そのタスクはより実時間で動く事が要求され、遅延は許されなくなる。
【０００３】
１つの画像処理装置で複数のタスクを処理する場合、通常、あるタスクが画像処理装置を占有して画像処理を実行している状態では、優先度の優劣に関わらず、その画像処理が終了するまで、別のタスクの画像処理は実行されない。つまり、一旦画像処理装置が起動され、画像処理が行われると、その終了までその画像処理が別の画像処理に切り替わる事は無い。これは、先に低いタスクが画像処理装置を占有していて、次に優先度の高い処理の遅延が許されないようなタスクが画像処理装置の実行を要求してきた時に、優先度の高いタスクの処理の遅延が起こるために問題となる。
【０００４】
特許文献１では、前記問題を、低い優先度を持つタスクが画像処理装置を起動しようとするときに、高い優先度を持つタスクの画像処理装置を起動する時刻を予測し、低い優先度を持つタスクの画像処理装置の実行時間と起動時刻の和、即ち終了時刻が、高い優先度を持つタスクの起動時刻を越えるようであれば、低い優先度を持つタスクの画像処理装置の実行を後回しにして、高い優先度を持つタスクの画像処理装置の実行を先に行なう画像処理装置を提案している。こうする事で、高い優先度を持つタスクは遅延しない。
【０００５】
別の解決手段として、低い優先度を持つ画像処理装置が占有している時に、高い優先度を持つ画像処理装置の占有要求が入ると、一旦画像処理装置の情報を退避させて低い優先度を持つ画像処理装置を中断させ、高い優先度を持つ画像処理装置処理を起動させた後、前記で保存した情報を復帰させ、低い優先度を持つ画像処理装置の残りの実行を行なうことが考えられる。これに類する公知例として特許文献２を用いる事が考えられる。この公知例では、ある画像の処理を中断して、画像の処理を行い、元の画像の処理を再開できる機能を拡大縮小回路に持たせた画像処理装置である。この様に、低い優先度を持つタスクの画像処理装置に中断、復帰の機能を持たせることで、高い優先度を持つタスクの画像処理装置の実行を遅延せずにすむ。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００３−１３１８９２号公報
【特許文献２】特開平８−１６１４６２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
例えば自動車に搭載するような画像処理装置では、歩行者検知の様に、優先して処理が行なわなければならないタスクや、雨滴検知の様に、歩行者検知に比べれば優先度の低いタスクが混在している。この時、優先度の低いタスクが画像処理装置を長時間占有して、優先度の高いタスクの動作を邪魔し、結果優先度の高いタスクが遅延する事は避けなければならない。特許文献１の装置のように、低い優先度を持つタスクの実行時間と、高い優先度を持つタスクの実行時刻を見て、低い優先度を持つタスクの画像処理装置の実行を優先度の高いタスクの画像処理装置終了後に行なおうとすると、例えば、その低い優先度を持つタスクの画像処理装置の占有時間が長く、本来高い優先度を持つタスクの画像処理装置開始時間の重なりがわずかだった場合に、低い優先度を持つタスクの画像処理装置の処理時間分がまるまる空いてしまい、画像処理装置を効率的に使えていないと言う問題が起きる。特に、複雑な画像処理機能は時間が大きくかかるものがあり、この問題が顕著になる。その点において、特許文献２の装置はこの問題を、低い優先度を持つタスクの画像処理装置の処理を途中で中断して高い優先度を持つ画像処理を行い、元の画像処理を再開する事で解決していると言える。
【０００８】
しかし特許文献２では機能が拡大縮小回路に限られているという問題がある。この構成は多くの画像処理機能を必要とする画像認識においては不十分である。さらに、中断する際には全てのハード情報を退避している為、退避と復帰に要する時間や容量のオーバーヘッドが大きいと言う問題がある。これは、多くの画像処理機能が搭載されている画像処理装置においては、使用する内部情報保持手段が多い為、退避と復帰に要する時間や容量のオーバーヘッドが大きくなるため、この問題が顕著となる。
【０００９】
本発明の目的は、データ処理の途中で処理を中断して別の処理を優先させるとき、中断する処理の進捗状態に応じて退避・復帰に要するオーバーヘッドを少なくすることができるデータ処理装置を提供することにある。
【００１０】
本発明の別の目的は、画像処理の実行中で処理の切り替えを行なうことができると共に、その切り替えの際に、実行中の処理に応じて退避しなければいけない情報を、オーバーヘッドが少なくて済むように適切に選別することができるデータ処理装置を提供することにある。
【００１１】
本発明の前記並びにその他の目的と新規な特徴は本明細書の記述及び添付図面から明らかになるであろう。
【課題を解決するための手段】
【００１２】
本願において開示される発明のうち代表的なものの概要を簡単に説明すれば下記の通りである。
【００１３】
すなわち、ＣＰＵが画像処理などに用いられるアクセラレータを用いて一のタスクを処理中に、前記アクセラレータを別のタスクの処理に割り当てることが要求されたとき、前記ＣＰＵは前記別のタスクの処理を前記一のタスクの処理よりも優先させる場合に中断フラグをセットし、前記一のタスクによる前記アクセラレータの処理の段階に応じて予め決められたタイミングで前記中断フラグのセット状態が検出されることによって、前記アクセラレータを前記別のタスクの処理に利用可能にする。
【００１４】
上記手段によれば、セットされた中断フラグの検出タイミングを、中断される側のタスクの処理の進捗状態に応じて決定するから、中断されるタスクの処理にとって退避・復帰のオーバーヘッドを少なくするタイミングでタスクスイッチを行うことが可能になる。
【発明の効果】
【００１５】
本願において開示される発明のうち代表的なものによって得られる効果を簡単に説明すれば下記のとおりである。
【００１６】
すなわち、データ処理の途中で処理を中断して別の処理を優先させるとき、中断する処理の進捗状態に応じて退避・復帰に要するオーバーヘッドを少なくすることができる。更に具体的には、例えば画像処理の実行中で処理の切り替えを行なうことができると共に、その切り替えの際に、実行中の処理に応じて退避しなければいけない情報を、オーバーヘッドが少なくて済むように適切に選別することができる。
【図面の簡単な説明】
【００１７】
【図１】図１は本発明に係る画像処理装置の一例を示すブロック図である。
【図２】図２は画像処理用のアクセラレータの詳細を例示するブロック図である。
【図３】図３は画像処理装置における画像処理タスクのタスク構造を例示する説明図である。
【図４】図４は画像処理装置を適用した自動車のブロック図である。
【図５】図５は雨滴検知タスク、車線逸脱検知タスク、及び歩行者検知タスクの間で画像処理ハード部に対する資源競合が起こったときの動作を例示する動作フローである。
【図６】図６は図５に代表されるようなタスクスイッチ動作を実現するための各タスク毎における画像ハード処理の制御フローである。
【図７】図７は図６における画像ハード処理の詳細を例示する制御フローである。
【図８】図８は画像ハード処理の中断判定においてタスク切り替えの際に情報の退避量を少なくするための処理の流れの一例を示す説明図である。
【図９】図９はハード管理テーブルの構成を例示する説明図である。
【図１０】図１０はタスク情報管理テーブルの構成を例示する説明図である。
【図１１】図１１は画像処理退避情報テーブルの構成を例示する説明図である。
【図１２】図１２は必要情報退避処理による退避処理の内容を例示する説明図である。
【図１３】図１３は待ち行列の実現例を例示する説明図である。
【図１４】図１４は図５とは異なる手順によるタスクスイッチ動作を例示する動作フローである。
【図１５】図１５は優先度の高いタスクが複数回に分けて画像ハード処理を実行する際に処理の合間に優先度の低いタスクの画像ハード処理が退避・復帰を繰り返すことによるオーバーヘッドを抑制可能にするタスクスイッチ動作フローである。
【発明を実施するための形態】
【００１８】
１．実施の形態の概要
先ず、本願において開示される発明の代表的な実施の形態について概要を説明する。代表的な実施の形態についての概要説明で括弧を付して参照する図面中の参照符号はそれが付された構成要素の概念に含まれるものを例示するに過ぎない。
【００１９】
〔１〕本発明に係るデータ処理装置(１０)は、複数のタスクを処理するＣＰＵ(１１６)と、前記ＣＰＵからの指示に従って異なるタスク（１０３）の処理に共用されるアクセラレータ（１０６，１０７，１０８，１０９）と、を有する。前記ＣＰＵがアクセラレータを用いて一のタスクを処理中に、前記アクセラレータを別のタスクの処理に割り当てることが要求されたとき、前記ＣＰＵは前記別のタスクの処理を前記一のタスクの処理よりも優先させる場合に中断フラグをセットし、前記一のタスクによる前記アクセラレータの処理の段階に応じて予め決められたタイミングで前記中断フラグのセット状態が検出されることによって、前記アクセラレータが前記別のタスクの処理に利用可能にされる。中断フラグがセット状態にされているか否かの検出は直接アクセラレータが行っても良いし、ＣＰＵが行ってもよい。
【００２０】
上記手段によれば、セットされた中断フラグの検出タイミングを、中断される側のタスクの処理の進捗状態に応じて決定するから、中断されるタスクの処理にとって退避・復帰のオーバーヘッドを少なくするタイミングでタスクスイッチを行うことが可能になる。
【００２１】
〔２〕項１に記載のデータ処理装置において、前記アクセラレータが前記別のタスクの処理に利用可能にされる場合には、前記ＣＰＵが前記一のタスクの処理が中断直前の状態に復帰可能に退避を行う。アクセラレータが行うことも可能である。
【００２２】
〔３〕項２に記載のデータ処理装置において、前記退避すべきデータは前記中断フラグの検出タイミングに応じて決定される。
【００２３】
〔４〕項３に記載のデータ処理装置において、前記ＣＰＵは、テーブルを参照することによって、前記退避すべきデータを判別する。前記退避すべきデータの判別は、その処理のためプログラム記述で行なっても良いが、テーブル参照で行うようにすれば、テーブルの書換えによってその参照タイミングを簡単に変更可能になる。
【００２４】
〔５〕項１に記載のデータ処理装置において、前記ＣＰＵは、前記別のタスクの処理を前記一のタスクの処理よりも優先させる必要がない場合には当該別のタスクの処理を前記一のタスクの処理完了まで待たせる。一定時間だけ待つようにしても良い。
【００２５】
〔６〕項１に記載のデータ処理装置において、前記ＣＰＵは前記別のタスクの処理を前記一のタスクの処理よりも優先させるか否かを、タスクの優先度によって判別する。タスクの処理時間の長短によって判別してもよい。
【００２６】
〔７〕項１に記載のデータ処理装置において、前記ＣＰＵは、テーブルを参照することによって、前記アクセラレータの処理の段階に応じて予め決められたタイミングを判別する。タイミングの判別は、その処理のためプログラム記述で行なっても良いが、テーブル参照で行うようにすれば、テーブルの書換えによってそのタイミングを簡単に変更可能になる。
【００２７】
〔８〕項１に記載のデータ処理装置において、前記アクセラレータは、画像処理用の画像処理ハード部と、画像処理用のデータを一時的に蓄積するデータバッファと、前記ＣＰＵからの指示に従って前記画像処理ハード部及びデータバッファを制御する画像処理制御部を有する。前記画像処理ハード部は、前記データバッファから供給される画像データを演算し、演算結果を前記データバッファに書き戻し、書き戻されたデータと別のデータを用いて演算を行う動作を繰り返す繰り返し演算によって画像処理が可能にされる。
【００２８】
繰り返し演算の段階に応じてデータバッファ上の退避すべきデータが相違されるとき、退避すべきデータ量が少なくなる処理の区切り毎に、中断フラグの検出タイミングを決めればよい。
【００２９】
〔９〕本発明に係るデータ処理装置は、複数のタスクを処理するＣＰＵと、前記ＣＰＵからの指示に従って異なるタスクの処理に共用されるアクセラレータと、を有する。前記ＣＰＵがアクセラレータを用いて一のタスクを処理中に、前記アクセラレータを別のタスクの処理に割り当てることが要求されたとき、前記ＣＰＵは前記別のタスクの処理を前記一のタスクの処理よりも優先させる場合に中断フラグをセットしてから当該別のタスクを待ち行列に繋いで前記一のタスクの中断を待ち、前記一のタスクによる前記アクセラレータの処理の段階に応じて予め決められたタイミングで前記アクセラレータが前記中断フラグのセット状態を検出することによって、前記一のタスクの処理が中断直前の状態に復帰可能に退避が行われると共に、当該一のタスクが待ち行列に繋がれて、前記別のタスクの処理に前記アクセラレータが利用可能にされる。
【００３０】
上記手段によれば、セットされた中断フラグの検出タイミングを、中断される側のタスクの処理の進捗状態に応じて決定するから、中断されるタスクの処理にとって退避・復帰のオーバーヘッドを少なくするタイミングでタスクスイッチを行うことが可能になる。
【００３１】
〔１０〕項９に記載のデータ処理装置において、前記退避すべきデータは前記中断フラグの検出タイミングに応じて決定される。
【００３２】
〔１１〕項１０に記載のデータ処理装置において、前記ＣＰＵは、テーブルを参照することによって、前記退避すべきデータを判別する。
【００３３】
〔１２〕項９に記載のデータ処理装置において、前記待ち行列は、後から書き込まれたデータはそのデータのタスクの優先度より低い優先度のタスクのデータよりも先に読み出し可能とする、タスク優先度付きＦＩＦＯとされる。
【００３４】
〔１３〕項９に記載のデータ処理装置において、前記ＣＰＵは、前記別のタスクの処理を前記一のタスクの処理よりも優先させる必要がない場合には当該別のタスクの処理を前記一のタスクの処理完了まで待たせる。
【００３５】
〔１４〕項９に記載のデータ処理装置において、前記ＣＰＵは、テーブルを参照することによって、前記アクセラレータの処理の段階に応じて予め決められたタイミングを判別する。
【００３６】
〔１５〕項９に記載のデータ処理装置において、前記アクセラレータは、画像処理用の画像処理ハード部と、画像処理用のデータを一時的に蓄積するデータバッファと、前記ＣＰＵからの指示に従って前記画像処理ハード部及びデータバッファを制御する画像処理制御部を有する。前記画像処理ハード部は、前記データバッファから供給される画像データを演算し、演算結果を前記データバッファに書き戻し、書き戻されたデータと別のデータを用いて演算を行う動作を繰り返す繰り返し演算によって画像処理が可能にされる。
【００３７】
繰り返し演算の段階に応じてデータバッファ上の退避すべきデータが相違されるとき、退避すべきデータ量が少なくなる処理の区切り毎に、中断フラグの検出タイミングを決めればよい。
【００３８】
２．実施の形態の詳細
実施の形態について更に詳述する。図１には本発明に係る画像処理装置が例示される。同図に示される画像処理装置は、特に制限されないが、画像処理用のデータプロセッサとして、シングルチップ又はマルチチップで構成される。シングルチップで構成される場合にはＳＯＣ（システム・オン・チップ）と称されるようなＬＳＩとして１個の半導体チップ上に実現され、マルチチップで構成される場合にはＳＩＰ（システム・イン・パッケージ）と称されるようなモジュールとして実現される。
【００３９】
画像処理装置１０では、ビデオカメラ、撮像素子、ハードディスクレコーダなどの画像取得部１００から映像データを入力する。画像取得部１００から取得された画像データはＳＤＲＡＭ（シンクロナス・ダイナミック・ランダム・アクセス・メモリ）などから成る記録媒体としての主メモリ１０１の画像データ保存領域１１０に格納され、画像処理の対象とされる。画像処理された画像データは液晶ディスプレイ等の画像出力部１０２に表示される。
【００４０】
画像処理装置１０は、主メモリ１０１のほかに、主演算装置としてのＣＰＵ（セントラル・プロセッシング・ユニット）１１６を備えると共に、ＣＰＵ１１６が実行するソフトウェアとして位置付けられる画像処理タスク１０３、画像処理ライブラリ１０４、及びオペレーティングシステムとしてのリアルタイムＯＳ１０５を有する。画像処理タスクに代表されるタスクは所謂ユーザプログラムとして与えられる。画像処理ライブラリ１０４は画処理用に予め用意されたプログラムモジュールとして位置付けられ、前記タスクによって呼び出されて用いられる。ＣＰＵ１１６が前記タスクを処理するときに用いる画像処理アクセラレータとして、画像処理ハード部１０６、画像処理制御部１０７、レジスタ群１０８、及びバッファメモリ１０９を備える。上記画像処理アクセラレータは各種の画像処理タスクの実行に用いられる。要するに、画像処理ハード部１０６、画像処理制御部１０７、レジスタ群１０８、及びバッファメモリ１０９は、画像処理タスク１０３、画像処理ライブラリ１０４、及びリアルタイムＯＳの内容に従ってその動作が規定される。画像処理制御部１０７は、特に制限されないが、ＣＰＵ１１６から与えられるコマンドに応答してマイクロプログラム制御によって画像処理ハード部１０６を制御する。画像処理ハード部１０６は画像処理をパイプライン的に行なう場合にはパイプラインステージ毎に並列処理が可能になっている。また、複数のタスクを並列処理可能な構成の場合には前記アクセラレータの構成が複数組み設けられる。
【００４１】
複数の画像処理タスクを実行する画像処理装置１０は画像処理タスクの優先度や画像処理タスクによる画像処理内容及び画像処理タスクによる画像処理の進捗状況等に応じて実行中のタスクの実行を中断してタスクスイッチ制御を行う。図１において、前記タスクスイッチのための制御機能としてＣＰＵ１１６は代表的に示されたタスクの中断可能判定機能１１２、退避情報決定機能１１３、必要情報退避機能１１４、退避情報復元機能１１５、及び中断処理復帰機能１１６を有する。
【００４２】
画像処理タスク１０３に従ってＣＰＵ１１６が画像処理ハード部１０６を初期設定してその動作を起動すると、画像処理ハード部１０６及び画像処理制御部１０７が、画像処理タスク１０３で指定された画像データを画像データ保存領域１１０からバッファメモリ１０９に読み込む。画像処理ハード部１０６はバッファメモリ１０９に読み込んだ画像データに対して実際の画像処理を行い、処理結果を画像データ保存領域１１０に書き込む。画像ハード処理を終了した後は、処理終了を画像処理タスク１０３に通達し、ＣＰＵ１１６は別のタスクの実行に遷移する。
【００４３】
あるタスクが画像処理ハード部１０６を用いる処理を行なっているときに、別のタスクが画像処理ハード部１０６の占有要求を出してきた場合、画像処理装置１０は、中断可能判定機能１１２で現在実行中の画像ハード処理が中断可能かどうかを判定し、退避情報決定機能１１３で中断の為に退避する情報を決定し、必要情報退機能１１４でその情報を退避し、その後、退避情報復元機能１１５で退避情報を復元し、中断処理復帰機能１１７で中断した処理を中断直後の状態に復帰させる制御が行われる。
【００４４】
図２には画像処理用のアクセラレータの詳細が例示される。以下の説明では前記バッファメモリ１０９は、画像の表示ラインの情報を保持するラインバッファとして構成されるものとする。尚、バッファメモリ１０９はライン単位で処理するのではなく画像を小領域単位で処理するブロックメモリで構成されることも可能である。
【００４５】
図２の構成における画像処理形態は、第１に、バッファメモリ１０９に入力画像データ領域１１０Ａのデータを読み込み、画像処理ハード部１０６で画像ハード処理を実行し、処理結果をデータパス４０１経由で出力画像データ領域１１０Ｂに返す形態と、第２に、画像処理ハード部１０６で得られた処理結果をデータパス４０２を経由してバッファメモリ１０９に再度書き込んで画像処理ハードを再度実行する形態がある。第２の画像処理形態は、画像処理ハード部１０６を繰り返し用いて複数の画像処理を一度に実行する処理形態に好適であり、このような処理を以下では繰り返し画像処理と呼ぶことにする。繰り返し画像処理は同じ画像ハード処理を繰り返して１つの画像処理とする事もあれば違う画像ハード処理を組み合わせて１つの画像処理とする事もある。繰り返し画像処理は画像処理制御部１０７が予め用意されたバッファメモリ１０９や主メモリ１０１を制御する命令コード若しくはコマンド４００を解読する事によって生成された制御信号を用いて制御される。命令コード若しくはコマンド４００は画像データの読み書き、画像処理の実行、レジスタやメモリの読み書き等を制御するコードを持つ。
【００４６】
図３には画像処理装置１０における画像処理タスク１０３のタスク構造が例示される。この例では、自動車向けの画像処理装置を想定しており、画像処理機能としては、画像処理を用いた自動車の運転支援を想定する。
【００４７】
まず、アプリケーションの初期化タスク２０１が起動され、映像取得タスク２０２が所定のタイミングで画像取得部１００から画像を取得し、所定の処理を終えて映像表示タスク２０３が画像表示部１０２にその結果を投影する。
【００４８】
運転支援の機能としてはここでは、雨滴検知タスク２０４、車線逸脱検知タスク２０５、及び歩行者検知タスク２０６を挙げる。
【００４９】
雨滴検知タスク２０４は画像処理により雨滴検知を行い、その結果をワイパー制御部２０７にその結果を送信する。
【００５０】
車線逸脱検知タスク２０５は、車線逸脱検知を行い、その結果を警報装置２０８に送信する。
【００５１】
歩行者検知タスク２０５は、車両前方の歩行者の検知を行い、ブレーキ制御部２０９にその結果を送信する。
【００５２】
初期化タスク２０１、映像取得タスク２０２、映像表示タスク２０３、雨滴検知タスク２０４、車線逸脱検知タスク２０５、及び歩行者検知タスク２０６の機能はマルチタスク対応のリアルタイムＯＳ１０５の管理の下で実行される。実際のデータ処理環境では、上述したタスクよりも多くのタスクが存在することになるが、ここでは理解を容易化する為に、その他のタスクについては触れず、図３のタスク構造を前提とする。
【００５３】
尚、ワイパー制御部２０７、警報装置２０８、及びブレーキ制御部２０９は画像処理装置外の機能である。初期化タスク２０１、映像取得タスク２０２、映像表示タスク２０３、ワイパー制御部２０７、警報装置２０８、ブレーキ制御部２０９については本発明の要旨に直接関係しないので、ここではその詳細な説明を省略する。
【００５４】
図４には画像処理装置１０の適用例である自動車が示される。自動車３００のフロントガラスの後ろに車載カメラ３０１が設置され、フロントガラスに落ちる雨滴３０２の検出や、車両前方の歩行者３０３の検知を画像処理装置１０が行い、雨滴検知の結果をワイパー制御部２０７に、車線逸脱検知の結果を警報装置２０８に、歩行者検知の結果をブレーキ制御部２０９に送信する。
【００５５】
図３において、雨滴検知タスク２０４、車線逸脱検知タスク２０５、及び歩行者検知タスク２０６の３つのタスクにはどのタスクを優先して処理するかを決める指標となる優先度が存在する。この優先度をPriority（タスク名）で表すと、その優先度の関係を、
Priority（雨滴検知タスク）＜Priority（レーン検知タスク）＜Priority（歩行者検知タスク）
とする。これは、雨滴を検知してワイパーの制御を行なったり、車線逸脱検知で警報を出したりするよりも、検知した歩行者の危険度を見て回避行動を行なう方を、遅延の許されない処理として優先しようとするものである。
【００５６】
図５に基づいて雨滴検知タスク２０４、車線逸脱検知タスク２０５、及び歩行者検知タスク２０６の間で画像処理ハード部に対する資源競合が起こったときに期待される動作を考える。
【００５７】
図５は縦方向に時間軸７００が伸びており、縦太線は延長上にある処理が行なわれていることを意味する。横太線は処理の遷移を示す。太い点線は、なんらかの待ち状態を表すとする。図において画像ハード処理は雨滴検知タスク２０４では２回、車線逸脱検知タスク２０５ではで１回、歩行者検知タスク２０６では２回起こるとする。最初は、雨滴検知タスク２０４によって１回目の画像処理ハード部１０６が起動されたとする。次に、車線逸脱検知タスク２０５が起床され（７０２）、画像処理ハード部１０６の占有要求を車線逸脱検知タスク２０５が出した（７０３）場合について考える。雨滴検知タスク２０４が画像処理ハード部１０６を用いている状態で、車線逸脱検知タスク２０５が画像処理ハード部１０６の占有要求を出している。この状態を画像処理ハード部１０６の資源競合が起こると言うことにする。資源競合が起こると、優先度が高いタスクの画像処理が優先して行なわれる。占有要求７０３による資源競合の結果、優先度は、
Priority（車線逸脱検知タスク）＞Priority（雨滴検知タスク）
であるから、画像処理ハード部１０６の処理は車線逸脱検知タスク２０５に移る。この様に画像処理ハード部１０６の実行権が移った後、今度は歩行者検知タスク２０６の起動がかかった時の事を考える(７０４)。歩行者検知タスク２０６が画像処理ハード部１０６の占有要求を出す（７０５）と、まだ車線逸脱検知タスク２０５が画像処理ハード部１０６を実行しているのでここでも資源競合が起こるが、優先度は、
Priority（歩行者検知タスク）＞Priority（車線逸脱検知タスク）
であるから、画像処理ハード部１０６の実行権は歩行者検知タスク２０６に移り、車線逸脱検知タスク２０５のハード処理は待ち状態に入る。歩行者検知タスク２０６に画像処理ハード部１０６の実行権が移り１回目の画像処理ハード部１０６の実行が終了すると（７０６）、占有要求７０５によって画像処理ハード部１０６の実行権が切り替わることによって待ち状態に入っていた車線逸脱検知タスク２０５が画像処理ハード部を用いた処理に復帰される。次に歩行者検知タスク２０６は２回目の画像処理ハード部１０６の占有要求７０７を行なう。再び資源競合が発生し、画像処理ハード部１０６の実行権は歩行者検知タスク２０６に移り、車線逸脱検知タスク２０５のハード処理は再び待ち状態に入る。７０８で２回目の画像処理ハードの実行が終わると、占有要求７０６によって待ち状態に入っていた車線逸脱検知タスク２０５による画像処理ハード部１０６を用いた処理に復帰される。この間に歩行者検知タスク２０６はその動作を終了するとする(７０９)。
【００５８】
そうすると、画像処理ハード部１０６の実行権は、車線逸脱検知タスク２０５に戻り、残った画像処理を終えると（７１０）、次に画像処理ハード部１０６の実行権は、雨滴検知タスク２０４に戻り(７１１)、７０３の時点で残った画像処理の実行を終える(７１２)。その間に車線逸脱検知タスクはその動作を終了する（７１３）。
【００５９】
図６には図５に代表されるようなタスクスイッチ動作を実現するための各タスクにおける画像ハード処理のフローが例示される。図において実線の矢印は処理の遷移、点線は括弧内のテーブルをその処理が参照もしくは更新する事を示す。
【００６０】
タスクがハードウェア占有要求８００を出すと、先ず、画像処理ハード部１０６が起動中であるかどうか、つまり別タスクが画像処理ハード部１０６を占有していないかどうかの確認を行う(８０１)。画像処理ハード部１０６が起動中でなければ、ハード処理起動（８０６）に移る。画像処理ハード部１０６が起動中である場合は優先処理判定（８０２）に移り、自分のタスクが、現在動いている画像処理ハード部１０６を動かしているタスクより、優先度が高いかどうかを判断する。この際、リアルタイムＯＳ１０５から自分のタスクのタスクＩＤを取得し、ハード管理テーブル８１１から、実行中のハード処理のタスクＩＤを取得し、タスク情報管理テーブル８１０を参照して、それぞれの優先度を取得する。リアルタイムＯＳのサービスコールで、任意のタスクの優先度が取得できる場合にはそれを利用すればよい。
【００６１】
優先処理判定８０２で自分のタスクの優先度が高ければ次の中断可能判定処理（８０４）に移り、それ以外であれば、待ち行列更新処理（８０３）に移り、待ち行列８１３を更新して、待ち状態に入る。
【００６２】
中断可能判定処理（８０４）では、ハード管理テーブル８１１を参照して、現在実行中の処理が中断可能かどうかを調べる。中断可能であれば、中断フラグ８１５をセットし（８１４）、その後に、自らを待ち行列８１３につなぐために待ち行列更新を行って（８０３）、自ら待ち状態に遷移する。詳細は後述するが、中断可能であって現在実行中のタスクは、中断フラグを所定のタイミングで検出することによって中断のための処理が行なわれてから待ち行列に繋がる。これによって、優先レベルが高く先に待ち行列に繋がれた当該タスクが待ち行列から抜けて実行可能にされる。中断不可能であれば、同様に待ち行列更新処理（８０３）に移り、待ち行列（８１３）を更新し、待ち状態に移る。尚、待ち行列８１３は、例えば優先度付きＦＩＦＯとされ、先入れ先出しを基本とし、先に書き込まれ、且つ優先度の高いものほど先に読み出されるように構成される。
【００６３】
待ち行列から抜けるとき、中断フラグがクリアされ（８０５）、ハード起動処理によって内部の必要な初期化などが行なわれ（８０６）、その次に画像ハード処理（８０７）が行われる。すなわち、待ち状態から実行状態に移るときは、必要な場合には画像処理ハード部１０６のためのレジスタ群等必要情報を設定した上で、画像処理ハード部１０６によるハード処理を起動する（８０６）。ハード処理起動（８０６）においてはハード管理テーブル８１１に自分が動かす画像ハード処理やタスクの情報を登録する。起動後、画像ハード処理（８０７）に移り、画像ハード処理が終了すると、ハード処理終了（８０８）を経て、次処理取得の処理（８０９）により、待ち行列８１３で処理待ちになっている高優先度の先頭の画像ハード処理を呼び出す。
【００６４】
図７には画像ハード処理（８０７）の詳細が例示される。画像ハード処理（８０７）では、所定のタイミングで中断フラグの検出を行う（９０１）。即ち、自らのタスクよりも優先度の高いタスクによって中断フラグがセットされたか否かを検出する。
【００６５】
中断フラグがセットされていなければタスクの処理を行なう（９０７）。
【００６６】
中断フラグがセットされているということは、処理中（９０７）の自らのタスクよりも優先度が高い別のタスクによってタスク実行に中断が要求されているということである。したがって、中断フラグのセット状態を検出すると、当該タスクの実行に関する退避処理として、退避情報決定処理（９０２）で、退避情報を適切に選択し、必要情報退避処理（９０３）で退避する。退避情報としては、レジスタ群１０８の値、バッファメモリ１０９の記憶データ、画像処理ハード部１０６の内部データ、及び画像処理制御部１０７の状態などとされる。退避するレジスタとしては、画像ハード処理の機能を決定するレジスタ、画像ハード処理が画像メモリのどこまで進んだかを保持するレジスタ等が考えられる。
【００６７】
この時、画像処理退避情報テーブル８１２を見て退避情報を決定する。その退避情報に従って、必要情報退避処理（９０３）で、退避情報保存領域１１１に退避を行う。その後は、待ち行列８１３に自らのタスを繋ぎ、待ち状態に遷移する。優先度の低いタスクが待ち状態に遷移することにより（９０４）、中断を要求した優先レベルの高いタスクは待ち状態（８０３）から抜けて実行可能な状態に遷移する（８０５，８０６，８０７）。
【００６８】
図７において、待ち状態から抜けて実行状態に遷移するときは、中断タスクを再実行するための復帰処理として、退避情報復元処理（９０５）で退避情報保存領域１１１から、先に必要情報退避処理（９０３）で退避された情報を復帰させ、中断処理復帰処理（９０６）で中断位置や画像処理の機能に従ってハードの初期化処理などを行なって画像処理ハード部１０６の起動等を適切に行った後、当該タスクによる画像処理を再開する（９０７）。
【００６９】
自らよりも低いタスクに対して実行の中断を要求するための中断フラグと中断フラグの判定処理（９０１）とを設けることで、画像処理ハード部を用いたタスク処理の中断タイミングを任意に指定する事が出来る。要するに、中断が要求されるタスクの処理の進捗状況に従って中断フラグを参照して、中断すべきか否かを決定することができる。特に、タスク切り替えの際に情報の退避量が少なくて済むようなところを中断フラグに判定タイミングとして選ぶことで、退避と復帰にかかる時間的、容量的なオーバーヘッドを軽減する事が可能である。例えば、画像データの１ラインの処理を終了した時や、繰り返して複数の画像処理を１度に行なうときは、１つの画像処理を区切りとして中断フラグの判定を行う事が考えられる。このような場所で中断フラグの判定を行なうと、画像処理途中のランダムな箇所で中断するのに比べて退避情報を少なくすることができる。
【００７０】
画像ハード処理によって、タスクを中断すべき適切な位置は異なるので、画像ハード処理に応じて中断フラグの判定位置を適切に選べばよい。
【００７１】
尚、図１、図６、図７において、例えば、図１の中断可能判定機能１１２は、優先処理判定（８０２）と中断可能判定（８０４）に相当し、退避情報決定機能１１３は退避情報決定処理（９０２）及び画像処理退避情報テーブル８１２に相当し、必要情報退避機能１１４は、必要情報退避処理（９０３）に相当し、退避情報復元機能１１５は、退避情報復元処理（９０５）に相当し、中断処理復帰機能１１７は中断処理復帰処理（９０６）に相当する。
【００７２】
画像ハード処理の中断判定は前述の様にタスク切り替えの際に情報の退避量が少なくて済むようなところで行う。図８を例に採って１つの処理の中で退避量が少ない箇所を示す。図８に示す処理は、入力画像Ａ（１５０１）と入力画像Ｂ（１５０２）を入力に取り、入力画像Ａ（１５０１）の３×３の平滑化処理を行い、その後入力画像Ｂ（１５０２）との差分を取り、出力画像１５１３に出力する。入力画像Ａ（１５０１）のi番目のラインを例にとって処理の流れの詳細を説明する。
【００７３】
（１）入力画像Ａのi番目のライン及びその１つ手前のi-１番目のライン、１つ後のi+１番目のラインの画像データをラインバッファに読み出す（１５０３）。
【００７４】
（２）i-１番目、i番目、i+１番目のラインの画像データをそれぞれラインバッファL１（１５０４）、ラインバッファL２(１５０５)、ラインバッファL３(１５０６)に書き込む。
【００７５】
（３）３×３の演算を行う演算器X（１５０７）でその３ラインを処理し、その結果をラインバッファL８（１５０８）に格納する。
【００７６】
（４）入力画像Ｂのi番目のラインからラインバッファL４(１５１１)に画像データを読み込む。
【００７７】
（５）ラインバッファL８とラインバッファL４を入力として、差分演算を行う演算器Ｙ（１５１２）で演算し、その演算結果を出力画像１５１３のi番目のラインに書き込む。
【００７８】
上記一連の処理を全ライン分繰り返し行って、入力画像Ａ（１５０１）の３×３の平滑化処理を行い、その後入力画像Ｂ（１５０２）との差分を取り出力する機能を実現する。この様な書き込み、読み出し、及び演算の実行など一連の命令制御は全て画像処理制御部１０７で行なわれるとする。
【００７９】
この場合に、ラインバッファに着目すると（２）で中断を行うよりも、（３）で中断を行う方が復帰に必要な退避量は少なくて済む。なぜならば、（２）で中断を行うと３つのラインバッファＬ１，Ｌ２，Ｌ３の退避を行わなければならないが、（３）で中断を行うと、ラインバッファの退避はＬ８の１個だけでよく、他のラインバッファを退避する必要がないからである。
【００８０】
さらに、（１）〜（５）の処理を繰り返し全ラインに対して行うことで、必要な画像全体の処理が成立するとすれば、（１）〜（５）の一連の処理が終了した時点で中断を行うと、ラインバッファの退避は不必要であり、さらに退避量が少なくて済む。この様に、中断位置によって退避量が異なる為、退避量の少ない例えば、（３）終了後や（５）終了後に中断フラグをセットしてタスクの処理を中断することにより、処理量とリソースの使用量を減らして効率的に画像処理の中断及び復帰を行うことが可能になる。
【００８１】
ここではラインバッファを例に説明したが、主メモリや内部レジスタ等も画像処理・中断位置によって復帰に必要な退避量が異なる。例えば、主メモリに置いた変換テーブルを用いて画素値変換する画像処理を考えた時に、この関数では途中で中断すれば主メモリを退避する必要があるが、その様な変換を用いない画像処理では退避する必要がない。
【００８２】
また、図８の例では画像処理機能をラインバッファと演算器の組合せによって実現したが、画像処理機能によってこれらの組合せ自体も様々に変わる為、適切な中断位置は画像処理機能に依存して決定されることになる。 
図９にはハード管理テーブル８１１の構成が例示される。このテーブルは画像処理ハード部などの画像処理用アクセラレータ（単に画像処理ハードとも称する）の状態を管理し、現在画像ハード処理が動いているか否かを管理するハード使用フラグ１０００、現在動いている画像ハード処理の番号（１００１）、その画像ハード処理を動かしたタスクの番号（１００２）、中断許可フラグ（１００３）を保持する。
【００８３】
中断許可フラグとは、現在動いている画像処理ハードを中断させ得るかどうかを示したフラグであり、１であれば中断が許可され、０であれば中断は許可しない。例えば、処理時間が長いような画像ハード処理は中断を許可しなければ優先度の高いタスクの遅延によるリスクが大きいため１とし、逆に処理時間が短いような画像処理は優先度の高いタスクの遅延によるリスクが少ないと判断された時は０とする。同じ画像処理でも処理範囲が大きいか小さいかでフラグのセットを切り分けても良い。
【００８４】
この様に中断処理を行なうかどうかを動的に切り替えることによって、処理に柔軟性を持たせる事が可能である。また、予め画像処理退避情報テーブルにこの中断許可フラグの情報を持たせておき、中断可能判断部で画像処理退避情報テーブルを参照しに行っても良い。
【００８５】
このハード管理テーブル８１１は、現在画像ハード処理が動いているか否か、現在動いている画像ハード処理、その画像ハード処理を動かしたタスクの番号が更新されるたびにその変更を反映させる。例えば、図６では、待ち状態から始めて実行されるタスクに対して、ハード起動処理（８０６）において画像ハードで実行される処理が切り替わるので、ここでハード管理テーブル８１１の情報を更新してもよい。
【００８６】
図１０にはタスク情報管理テーブル８１０の構成が例示される。このテーブルはタスクの情報を管理し、タスクの番号(１１００)やそのタスクの優先度(１１０１)を保持する。
【００８７】
図１１には画像処理退避情報テーブル８１２の構成が例示される。画像処理退避情報テーブル８１２は、画像処理の番号をキーとして(１２００)、中断位置(１２０１)、画像処理の内容(１２０２)、退避時に必要なレジスタの指定を行なうフラグ(１２０３)を管理する。退避時に必要なレジスタの指定を行なうフラグとは、例えばビットごとにレジスタ番号が割り振られ、ビットが１であれば退避、ビットが０であれば指定するレジスタ番号を持つレジスタの退避を行なわないというような指定の仕方が考えられる。レジスタのほかにも、ラインバッファや、画像処理制御部の情報をこのビット列で指定しても良い。この様に指定し、退避する情報を選別する事で全ての情報を退避するよりも、退避にかかるオーバーヘッドが少なくて済む。また、図中のハフ変換に示すように中断位置によって、退避すべき情報を変更することも考えられる。
【００８８】
図１２には必要情報退避処理９０３による退避処理の内容が例示される。必要情報退避処理９０３においては画像処理退避情報テーブル８１２によって指定された情報を退避する。退避する情報としては、レジスタ１０８のアドレスや、保存するレジスタの値、ラインバッファ１０９の状態、画像処理制御部１０７の内部状態（汎用レジスタやプログラムカウンタの値）がある。加えて退避必須なものとして退避する画像処理を発行したタスクの番号と画像処理の番号（１３００）がある。この番号は、ハード管理テーブル８０２を参照する事で取得できる。また、図示は省略するが、画像の変換テーブルを保持すること等に使われる内部メモリや、命令コードの退避も考えられる。退避の実現方法としては、回路として実現するやり方や、ソフト的に指定情報を読みながら実現する方法が考えられる。
【００８９】
必要情報退避処理９０３では、当該情報を退避情報保存領域１１１に格納するが、１回に退避する情報をまとめて退避ブロック（１３０１）と呼ぶ事にする。退避ブロックには、退避対象と、退避情報を格納する。退避対象とは例えば、レジスタやラインバッファを指し、退避情報は退避時のレジスタやラインバッファの中身をさす。退避ブロックはレジスタ、ラインバッファ、画像処理制御部の内部状態のように分けて用意しても良いし、図１２のようにまとめてしまっても良い。退避情報保存領域１１１には１つ要素（退避ブロック）の領域長が可変で格納できる機能（１３０２)を持たせる。１つの退避ブロックを可変としたのは、退避の情報量が変動するための対策と退避情報保存領域１１１の領域節約のためである。ただし十分な領域があれば固定長でもかまわない。
【００９０】
図１３には待ち行列の８１３の実現例が示される。待ち行列８１３には、現在動くことができないが、次に動く候補となる画像ハード処理の情報が入る。この先頭のデータが取られるのは現在実行中のハード処理が終わるか、中断した時である。
【００９１】
待ち行列に入ってくる経路は図６、図７に示すとおり、優先度判定処理(８０２）で優先度がハード実行中のタスクよりも低かった時、すでに動いている画像ハード処理が中断可能判定処理(８０４）で中断不可能とされた場合と、中断待ちのための中断フラグのセット（８１４）の後、中断の為の退避処理を行う必要情報退避処理（９０３）の後である。これらを待ちタイミングと呼ぶことにする。最後の中断処理で待ち行列に入ってきた画像ハード処理は退避情報保存領域１１１に格納されている退避情報との対応が取れている必要があるため、その対応が分かる情報（タスク番号や画像処理番号）を保持する必要がある。  
【００９２】
図１３に示される具体的な待ち行列は、優先度付き待ち行列で実現される。ここで優先度付き待ち行列とは、後から入ってきた要素でも優先度が高ければ当該優先度よりも低い優先度の要素よりも先の位置に繋がることを許容した待ち行列のことを言う。優先度付き待ち行列にする事で、タスクが複数入ってきた時でも、例えば、高いタスクがハードを占有している時に低いタスクが中断させてしまうような整合性が失われる状態が発生する事はない。
【００９３】
各画像ハード処理の情報要素１４００は、待ちタイミング１４０１、画像処理の種類（画像処理番号）１４０２、その画像処理を発行したタスク番号１４０３、及びそのタスクの優先度１４０４であり、更に、待ちタイミングが必要情報退避処理であれば、退避情報保存領域１１１の先頭アドレス１４０６及び最終アドレス１４０７を保持する。この２つのアドレスを保持することで、必要情報退避処理で中断されたハード処理は、処理を復帰するときに簡便に必要情報の復帰を行なうことができる。
【００９４】
他の情報としては、例えば、待ち状態に入ったときのタイムスタンプ（ＣＰＵ絶対時間）を保持する事も考えられる。タイムスタンプは同じ画像ハード処理の情報が時間を異にして入ってきた時にそれらを区別したり、特定の画像ハード処理が長く待ち状態になるのを避ける為に待ち時間の長いものは先頭に移すなど、待ち行列の更新を行ったりする時に用いる。
【００９５】
待ちタイミング１４０１を保持する理由は、待ちタイミングによって、待ち状態から実行状態への遷移の際に行う処理が違う事があるからである。例えば、図６において、８０１，８０２，８０４，８１４，８０３までのフローをＣＰＵ処理で実装し、図７の処理を画像処理制御部１０７で実装したとすると、待ちタイミングが中断可能判定処理（８０４）で待ち状態に入ったものと、待ちタイミングが必要情報退避処理９０２で待ち状態に入ったものでは、前者は実行状態への遷移処理前に現在ＣＰＵ処理を行っているタスクとの優先度の比較という処理が加わる。これらを実現する事で、ある画像ハード処理が終わった後の次の処理を適切に決定する事が出来る。
【００９６】
退避情報復元処理９０５では、待ち行列８１３の先頭にある退避ブロックを復元する。図１３の１４００を例に採ると、中断処理から復帰したタスク２の退避ブロックは、先頭アドレス０x０４００００から、最終アドレス０x０４００２０になっている為、この場所にある退避ブロックに従って退避情報をレジスタ・ラインバッファ等に復元させる。退避ブロックには退避対象と退避情報が入っているため、この作業が可能である。もしくは、画像処理退避情報テーブル８１２に従えば、退避した対象が分かるので、この情報に従って退避を行っても良い。
【００９７】
中断処理復帰処理９０６では、中断した処理を再開する際に必要な前処理と、中断処理の再起動を行う。中断した処理を再開する際に必要な前処理とは、例えば、復帰処理前に残って、かつ中断処理を再開する際に不必要な情報のクリアが考えられる。例えば、ラインバッファやレジスタの値が考えられる。他にも、画像処理が中断された位置と処理を再開する時の位置が異なる場合は、再開位置や処理の調整をする必要がある。例えば、指定された位置の周辺の情報を処理に用いる局所領域処理では、その前のラインの情報を読み込む必要がある。それは、復帰情報にある画像処理機能や中断位置から決定する事が考えられる。これらの調整を行った後、中断処理の再起動を行う。
【００９８】
図５を用いて、図６及び図７の処理手順が画像ハード処理の切り替わりを許す事について説明する。ただし、各タスクで発行される画像ハード処理はどれも中断可能であるとする。はじめに雨滴検知タスクが画像処理ハードを占有し、７０３で車線逸脱検知タスクが画像処理ハードの占有要求を出す。この時、車線逸脱検知タスクの画像ハード処理はハード起動中であるかを確認し（８０１）、雨滴検知タスクが画像ハード処理を行っているので、優先度判定（８０２）に移り、
Priority（車線逸脱検知タスク）＞Priority（雨滴検知タスク）
なので、中断可能判定８０４に移る。ここでも中断可能であるので、中断フラグを立て(８１４)、待ち行列に追加されて、一旦待ち状態に入る。一方、雨滴検知タスクの画像ハード処理は、その中で、中断フラグを参照（９０１）し、中断フラグが立っているので、退避情報決定処理９０２、必要情報退避処理９０３を経て、待ち行列に自分を追加して(９０４)待ち状態に入る。しばらく車線逸脱検知タスクの画像ハード処理が動くが、７０５で、優先度最高の歩行者検知タスクが占有要求を出す。このとき、
Priority（歩行者検知タスク）＞Priority（車線検知タスク）
で、中断可能であるので、車線検知タスクは中断フラグ判定処理（９０１）、退避情報決定処理（９０２）、必要情報退避処理（９０３）を経て、待ち行列に追加される（９０４）。この時、待ち行列には既に雨滴検知タスクが入っているが、
Priority（車線逸脱検知タスク）＞Priority（雨滴検知タスク）
なので、優先度付き待ち行列の性質上、待ち行列の先頭は車線逸脱検知タスクに切り替わる。図５の７０６で歩行者検知タスクの１回目の画像ハード処理が終了すると、その画像ハード処理の次処理取得処理（８０９）が、７０５で中断されて待ち行列の先頭にいる車線逸脱検知タスクの画像ハード処理を呼び出してハード処理から抜ける。呼び出された車線逸脱検知タスクの画像ハード処理は、待ち状態から復帰し、退避情報復元処理９０５、中断処理復帰処理９０６で必要情報を必要か書に再書き込みした後、ハード処理を再起動し、処理（９０７）を開始する。以下、図５の７０７、７０８、７１０のタイミングにおいてもでも上記同様の、中断、復帰処理が行われる。
【００９９】
図１４には図５とは異なる手順によるタスクスイッチ動作タイミングが例示される。図１４は、図６の優先処理判定（８０２）の後に中断可能判定（８０４）を行わず、待ち行列更新に行く例である。雨滴検知タスクが最初ハードの実行権を得た(５００)後、歩行者検知タスクが画像処理ハードの占有要求５０１をし、資源競合が起こる。このとき、
Priority(歩行者検知タスク))))＞Priority（雨滴検知タスク）
なので、歩行者検知タスクが画像処理ハードの実行権を獲得し、歩行者検知タスクの画像ハード処理を実行する。この時、雨滴検知タスクの発行した画像ハード処理は待ちタイミング１３０１が必要情報退避処理として記録され、待ち行列に入る。その間、車線逸脱検知タスクが実行され、５０２で画像処理ハードの占有要求を行なうため、資源競合が起こるが、歩行者検知タスクの優先度が車線逸脱検知タスクの優先度に比べて高い為、５０２の画像ハード処理は待ち行列に入り歩行者検知タスクの発行した画像ハード処理はそのまま実行を続け、車線逸脱検知タスクの発行した画像ハード処理は待ち行列に入る。この時、待ち行列タイミング１３０１は優先度判定として保存される。このとき、優先度付き待ち行列の先頭には、車線逸脱検知タスクの発行した画像ハード処理が入る。図１４の５０３で、歩行者検知タスクの発行した画像ハード処理が終了し、次に車線逸脱検知タスクの発行した画像ハード処理が呼び出され、実行される。最後に図１４の５０４で車線逸脱検知タスクの発行した画像ハード処理が終了し、雨滴検知タスクの画像ハード処理が復帰され、再実行される。
【０１００】
図５及び図１４の例では、優先度の高い歩行者検知のタスクが複数回の画像ハード処理を実行する際に、７０６と７０７の間など、その合間に優先度の低い歩行者検知タスクの画像ハード処理が退避・復帰を繰り返す。そのオーバーヘッドが優先度の高いタスクの遅延に影響を及ぼすような場合は、優先度の高いタスクが終了するまで、優先度の低いタスクの画像処理を禁じれば良い。この様な構成を実現する場合には、次処理取得部８０９でハード管理テーブルを参照し、待ち行列の先頭に入っている画像ハード処理を発行したタスクの優先度がハードを現在占有中のタスクの優先度より低い時には、実行しないという手法を採る。この様な場合はタスクの最後で、待ち行列の先頭の画像ハード処理を復帰する。
【０１０１】
この場合の動作タイミング例を図１５に示す。６００で雨滴検知タスクの画像ハード処理が実行され、６０１で車線逸脱検知タスクによる画像処理ハードの占有要求が出される。画像処理ハードの実行権は車線逸脱検知タスクに移る。次に、６０２で歩行者検知タスクと車線逸脱検知タスクの資源競合が起こり、画像処理ハードの実行権は歩行者検知タスクに移る。歩行者検知タスクの画像ハード処理は６０３で一旦終了するが、車線逸脱検知タスクのハード処理は復帰することなく、次の歩行者検知の画像ハード処理が６０４で起動される。歩行者検知タスクが終了して初めて車線逸脱検知タスクの画像ハード処理が復帰(６０５)し、車線逸脱検知タスクが終了して初めて雨滴検知タスクのハード処理が復帰(６０６)する。
【０１０２】
以上本発明者によってなされた発明を実施形態に基づいて具体的に説明したが、本発明はそれに限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは言うまでもない。
【０１０３】
例えば、画像処理アクセラレータとしての画像処理ハード部１０６、画像処理制御部１０７、レジスタ群１０８、及びバッファメモリ１０９を複数組も受けても良い。例えば画像処理をパイプライン的に処理する場合に、そのパイプライン処理段数分だけ上記回路のペアを設ければよい。また、図６の処理と図７の処理の双方をＣＰＵ処理として実装する場合だけでなく、図６の処理をＣＰＵ処理に実装し、図７の処理をアクセラレータの処理に実装してもよい。本発明に係るデータ処理装置は画像処理を行なうものに限定されず、音声処理、暗号化処理などに広く適用することができる。
【符号の説明】
【０１０４】
１０  画像処理装置
１００  画像取得部
１０１  主メモリ
１１０  画像データ保存領域
１１６  ＣＰＵ
１０３  画像処理タスク
１０４  画像処理ライブラリ
１０５  リアルタイムＯＳ
１０６  画像処理ハード部
１０７  画像処理制御部
１０８  レジスタ群
１０９  バッファメモリ
１１２  中断可能判定機能
１１３  退避情報決定機能
１１４  必要情報退避機能
１１５  退避情報復元機能
１１７  中断処理復帰機能
２０１  初期化タスク
２０２  映像取得タスク
２０３  映像表示タスク
２０４  雨滴検知タスク
２０５  車線逸脱検知タスク
２０６  歩行者検知タスク
【図１】
2010181989.tif 000003
【図２】
2010181989.tif 000004
【図３】
2010181989.tif 000005
【図４】
2010181989.tif 000006
【図５】
2010181989.tif 000007
【図６】
2010181989.tif 000008
【図７】
2010181989.tif 000009
【図８】
2010181989.tif 000010
【図９】
2010181989.tif 000011
【図１０】
2010181989.tif 000012
【図１１】
2010181989.tif 000013
【図１２】
2010181989.tif 000014
【図１３】
2010181989.tif 000015
【図１４】
2010181989.tif 000016
【図１５】
2010181989.tif 000017