図1は、本発明の一実施形態による自動車に搭載した画像処理カメラシステムの概略構成ブロック図と画像処理カメラのハードウェア構成図である。この画像処理カメラシステムは、自動車1の前方向や後方向に設置したカメラ2,3を使用して、後述するような多数のアプリケーションを実現するものである。画像処理カメラ2,3は、ネットワーク4を介してインターフェース手段5と接続されている。自動車1の場合、ネットワーク4は、CAN( Control Area Network )など規格化されたネットワークや、単なる電力線でON/OFFを表現するだけの接続方法などが利用できる。インターフェース手段5は、ナビゲーションシステム、ハンドル、ブレーキなどドライバとの情報のやり取りをするデバイスであったり、エンジンコントロールユニット、GPS、各種センサなど制御装置との情報をやり取りするデバイスである。インターフェース手段5がナビゲーションシステムである場合は、CANなどのネットワーク4を通して多量の情報を伝達する。また、インターフェース手段5がサイドブレーキなどである場合は、必要最小限のON/OFF情報のみを伝達する。
図1(b)を用いて画像処理カメラ2,3のハードウェア構成の一実施形態を説明する。撮像デバイス6によって取得された画像は、撮像デバイスインターフェース7を介してRAM8に格納される。後述する多数のアプリケーションのプログラムや、撮像デバイス6の制御プログラムなどは、予めROM9に格納されており、必要に応じてCPU10によって実行される。画像処理カメラ2,3の内部では、外部インターフェース手段11が、ネットワーク4を介して外部のデバイスとの仲介を行っている。すなわち、これらの要素7〜11は、マイクロコンピュータ12を構成しており、ROM9には、画像処理カメラ2,3を起動するためのプログラムや実行可能なアプリケーションに関する情報が記憶されている。また、RAM8にはアプリケーションの実行に必要な情報を格納している。アプリケーションの実行に必要な情報としては、後述する環境情報や、図1(a)のインターフェース手段5から得られた情報、及び画像データなどがある。撮像デバイス6は、マイクロコンピュータ12すなわちCPU10が処理するプログラムによって制御され、その制御情報は、撮像デバイスインターフェース7を介して送信される。
図2は、自動車における多数のアプリケーションと、必要画質、レート、カメラ制御及び画像処理機能の説明図である。図2中に示すように、アプリケーション例として、次のようなものが挙げられる。(1)車両周囲のモニタリング、(2)走行時の状況を記録するドライブレコーダ、(3)走行時の周囲映像を記念として記録する映像アルバム、(4)走行レーンをカメラによって認識することにより実現される車線逸脱警報、(5)走行中の障害に対して警報を出す障害物警報、(6)割込み・追越し車両警報、(7)自動的にライトの消灯を制御したりライトの明るさ強度や方向を制御するライト自動制御機能、(8)駐車や車線変更するときの駐車支援・車線変更支援機能、(9)衝突前に衝突被害をできるだけ軽減する衝突軽減・回避機能などである。
これらの多数のアプリケーションが必要とする(1)画質、(2)レート、(3)カメラ制御及び(4)画像処理機能について説明する。
まず、「(1)画質」については、高ければ高いほど望ましいが、解像度が上がればデータ量が増加し、処理に負担がかかってしまい、結果として所定のレートで処理できなくなってしまう場合がある。そのため、アプリケーションに適した画質が存在する。図2では映像アルバムのみ使用する画質を指定しているが、他のアプリケーションでも映像アルバムと同様に適した画質がある。例えば、レーン認識に必要な画質は白線などのレーンマークが判別できれば良く、必要以上に高画質の画像を時間とメモリを消費して取得する必要はない。
次に、「(2)レート」についても画質同様、それぞれのアプリケーションに適したレートが存在する。ここでレートとは処理の頻度のことであり、レートが高いほど処理サイクル数が小さく、短い時間間隔で処理が繰返される。一般的に高画質な映像を取得しようとしたり、安全性に関係する制御をしようとすると短い間隔で画像の取得が必要となりレートは高くなる。例えば、衝突軽減や衝突回避など高い信頼性と高速な応答性を求められるアプリケーションでは、画像処理の回数を増やして信頼性の向上と応答性を改善する必要がある。このように、アプリケーションの中には、1秒間に1回処理できれば機能を満たすものもあれば、16ミリ秒間隔で処理が必要なものもあるため、撮像デバイスを共有するためにはレートを考慮しなければならない。
また、「(3)カメラ制御」は、主に人間が映像を見るアプリケーションと計算機が画像を処理するアプリケーションに分かれる。図2中のモニタリング、ドライブレコーダ、映像アルバム機能は見るアプリケーションであり、ライト自動制御以下のアプリケーションは認識処理を行うものである。カメラ制御の内容としては、モニタリング用の制御では、人間の見た目で自然な画像が取得できれば良く、画像処理用の制御では、画像処理する部分が処理できるような画像が取得できるように制御を行う。画像処理用の画像では、画像の暗い部分の処理用に低速シャッターで取得した画像や、明るい部分の処理用に高速シャッターで取得した画像などがある。これらシャッター制御を行った画像は、見た目には暗すぎたり、明るすぎたりしてモニタリング用のカメラ制御とは異なる場合が多い。また、カラー制御も信号を検知するために赤色や黄色を強調した画像を取得したりするため、自然な色を再現するモニタリング用のカメラ制御と異なる。
最後に、図2では、各アプリケーション別に、必要となる「(4)画像処理機能」を示している。基本となる画像処理機能としては、画像圧縮、色補正、レーン認識、車両検知などがあるが、いくつかの機能は複数のアプリケーションで同一の機能が必要とされている。複数のアプリケーションで同一機能が必要とされているのであれば、その機能が必要とするカメラ制御はアプリケーション間で共有できると考えられる。例えば、車線逸脱警報であればレーン認識機能が必要となり、同様にレーン認識機能が必要となる割込み車両警報とレーン認識機能の共有化を実施すれば、それに伴なって撮像デバイスの使用も共有化することができる。
以下に、1つのカメラ(撮像デバイス)を共有して、多数のアプリケーションを実現する本発明の一実施形態を説明する。
図3は、本発明による画像処理システムの一実施形態の概要を示す機能ブロック図である。ここに示す殆どの機能は、図1で説明したマイクロコンピュータ12によって実行される。まず、画像を取得する撮像デバイス6を制御する撮像デバイスコントロール部13と、アプリケーションの実行や停止を制御するアプリケーションスケジューリング部14を備える。N個のアプリケーション151〜15Nを備えたシステムであり、各アプリケーションは、基本となる画像処理機能(A〜M)16A〜16Mのうち必要なものを利用して動作する。また、各アプリケーションが処理に使用したり、アプリケーションスケジューリング部14が、アプリケーションの制御に使用する環境情報17を備えている。本実施形態では、通常カメラと呼ばれる撮像デバイス6に加えて、撮像デバイス6を制御する撮像デバイスコントロール部13、各アプリケーションA〜Mを実行する部分を、図1(a)に示す画像処理カメラ2,3部に集約している。そこで、前述したアプリケーションを実現する高度な処理機能まで持ったカメラ(例えば、カメラ2,3)のことを単なる画像を取得するカメラと区別するために画像処理カメラと呼ぶことにする。
まず、図3に示した各アプリケーション1〜Nのうちのひとつ151が、単独で実行する場合について説明する。この単独実行の説明は、従来技術の特許文献1、特許文献2などの動作と同様である。アプリケーション151は、処理に必要な画像を撮像デバイス6から取得するために、周囲の明るさ、画像処理範囲、現在取得している画像の状態などの環境情報17を参照する。これに基き、カメラパラメータ(カメラ向き、絞り値、シャッタースピードなど)を決定し、撮像デバイスコントロール部13に撮像デバイス6の制御を依頼する。撮像デバイスコントロール部13では、撮像デバイス6の露光タイミングなどを考慮して、アプリケーション151が欲するカメラパラメータを設定する。ここで、環境情報17は、地図情報、日時(季節)、車外の照度、天候、注視範囲などがある。
このように、単独のアプリケーションのみ存在した場合は、アプリケーションが欲するカメラパラメータを撮像デバイスコントロール部13が撮像デバイス6に設定するだけの機能で十分である。しかし、図3ではアプリケーションが複数であるため、各アプリケーションから要求されるカメラパラメータを受付け、撮像デバイス6がそれぞれの画像を限られた時間間隔で取得できるように制御する機能が必要となる。本実施例では、アプリケーションスケジューリング部14がその機能を果たしている。つまり、アプリケーションスケジューリング部14は、複数のアプリケーション1〜Nから要求され、撮像デバイス6に対する制御を調整して実行する機能を持つ。
アプリケーションの種類によっては、撮像デバイス6を共有できない場合が発生する。例えば、映像を高画質で録画したいため綺麗な画像を毎フレーム取得したいアプリケーションと、衝突回避のように画像処理に必要な画像をできるだけ短い時間間隔で毎回取得したいというアプリケーションである。この2つのアプリケーションを1つの撮像デバイスを使用して並行して実行することは、2つのアプリケーションのカメラ制御が全く同一でない限り困難である。このため、並行して実行するアプリケーションが限定されることになるが、その制御もアプリケーションスケジューリング部14で行う。アプリケーションスケジューリング部14は、各アプリケーションが必要とする画像制御情報と処理量、及び自動車1の走行状況から実行可能なアプリケーションを判断する。そして、実行できる場合には、画像の取得タイミングと処理タイミングとを調整する。このアプリケーションスケジューリング部14によって、カメラパラメータを動的に変化させる複数のアプリケーションでも、1つの撮像デバイスを効率的に共有することができる。なお、インターフェース手段5は、図1で説明したように、ナビゲーションシステム、ハンドル、ブレーキなどドライバや自動車1の走行制御システムとの仲介役を果している。
次に、図4、図5を用いて撮像デバイス1のカメラパラメータの制御について説明する。
図4は、撮像デバイスコントロール部13の機能ブロック図である。図に示すように、撮像デバイス6から得られる画像を制御するには、次の5つの制御機能部がある。まず、光量を電気信号に変換するための撮像素子に入射する光量を制御する露光制御部131、光量を電気信号に変換した後に電気信号で明るさを制御するゲイン制御部132及び色情報を制御するカラー制御部133がある。また、データ転送する範囲を限定し高速に画面をスキャンするスキャン範囲制御部134及び映像入力制御部135である。それぞれの制御は、図1(b)で説明したように、マイクロコンピュータ12のプログラム処理によって実行される。制御の対象によって、リアルタイムに変更できる静的パラメータもあれば、装置を機械的に制御して変更する動的パラメータもあり、後者の場合には希望する画像を取得するのに時間を要することもある。
図5は、撮像デバイス6のハードウェア構成図である。撮像デバイス6の内部では、信号処理部61によって、カメラパラメータを変更できるゲイン制御及びカラー制御などの静的制御を実行する。一方、レンズ62、絞り63及び撮像素子64などの光学系において、フォーカスやシャッタースピードを動的に制御する光学系制御部65がある。本実施例では、これらの変更に関するスケジューリングに関しても実行し、前述したように、信号処理のパラメータ変更は瞬時に可能であるが、光学系は、瞬時に変更ができない場合が多い。
次に、スケジューリングの方法について説明する。前述したように、各アプリケーションは所定のレートで処理する必要がある。例えば、車線逸脱警報において、車線を逸脱してから300[ms]以内に警報を出す必要があれば車線逸脱警報処理の処理サイクルは最長でも300[ms]以下でなければならない。もし、実行中のアプリケーションとの関係で所定のレートを実現できない場合は、この車線逸脱警報処理を起動すべきでない。このため、所定のレートが実現できるようにスケジューリングされて、各アプリケーションを起動しなければならない。以下にスケジューリングについて詳述する。
図6は、複数アプリケーションの動作スケジューリングの一例タイムチャートであり、割込み車両警報とドライブレコーダの2つのアプリケーションが1つの撮像デバイスを共有し、並行して実行される場合のスケジューリングを示す。映像フレーム300は、画像が取得できるタイミングを規定しており、それぞれのタイミングをフレームF0〜F5のフレーム番号で表現している。例えば、通常の撮像デバイスでは、1つのフレームは33[ms]もしくは16[ms]である。割込み車両警報301では、図2のカメラ制御の欄に示したように、高速と低速のシャッター制御を行った2枚の画像を用いて割込み車両の認識(車両検知)処理を行っている。このため、画像1,2の2枚の画像を取得して処理する必要がある。この図では、割込み車両警報301の処理サイクル(1周期)を6フレームとしているので、6フレームの期間内で2枚の画像の取得と、それぞれの画像処理を行う。一方、ドライブレコーダ302は、画像を記録する処理であるが、こちらの処理サイクルも6フレームであり、取得する画像は1枚である。図3のアプリケーションスケジューリング部14は、割込み車両警報301のための画像1,2の取得と、処理1,2の処理時間を計算する。そして、割込み車両警報301には6フレーム必要であることから、フレームF0に画像1の取込み、フレームF1〜F2に処理1を割当て、フレームF3に画像2の取込み、フレームF4〜F5に処理2を割当てる。他方、ドライブレコーダ302の処理は画像取得のみであり、割込み車両警報301で撮像デバイス6を使用していないフレームF1に画像3の取込みを割当てている。ここで、両アプリケーションにおいて、画像の取込みタイミングは異なっているため、画像1〜3のカメラパラメータは全く異なる設定が可能であり、これらのアプリケーションに1つの撮像デバイス6を共有することができる。
図7は、本発明の一実施形態におけるアプリケーションのスケジューリングの処理フロー図である。これを用いてスケジューリング処理の周期(サイクル)について説明する。前述した図6では、処理周期(サイクル)は、フレームF0〜F5からなる6フレームであり、この処理周期を繰返している。まず、周期的に繰返される処理周期の最初のステップ71で、実行中の処理スケジュールが更新されているかを確認する。スケジュールが変更になっていない場合は、ステップ72のフレームF0の期間の処理に移る。ステップ72の内部では、まずステップ721で、フレームF0の期間内に取込む画像データの取得コマンドの発行を行う。画像データの取込みは、通常DMA転送と呼ばれるCPUに負荷をかけない転送方法で実現されるため、CPUの処理は次のステップ722に移る。ステップ722では、次に来るフレームF1の期間内に取込むカメラパラメータ例えば、シャッタースピードなどの露光制御の設定を行う。カメラパラメータの設定は、図3の撮像デバイスコントロール部13の機能として、図1(b)に示したマイクロコンピュータ12によって実行する。すなわち、撮像デバイスインターフェース7を介し、撮像デバイス6に適したタイミングで設定する。この処理を終了すると、ステップ723に移行する。ステップ723では、フレームF0の期間で実行するソフト処理を行う。フレームF0期間に実行する処理を全て実行したのち、ステップ73では、次回にはフレームF1での処理を行うように設定し、今回の処理を終了する。その後、フレームF1の時期が来てタイマー割込みにより、再びこの処理が起動されると、今度は同様にしてフレームF1での処理を実行することになる。このようにして、タイマー割込みにより、順次フレームF0〜F5の処理を繰返す。
ステップ71において、スケジュールが更新されている場合も、以降の処理は上記で説明した処理内容と同様になるが、各処理タイミングは、新しいスケジュールに従って必要に応じて初期化される。新しいスケジュールの適用は、ステップ71で実行される。
図8は、複数アプリケーションの動作スケジューリングの他の一例タイムチャートであり、車線逸脱警報310,ライト自動制御311及びドライブレコーダ302の並行動作についての説明図である。車線逸脱警報310は、処理サイクルが6フレームとなっており、必要な画像は高速/低速シャッターの2枚、処理量はそれぞれの画像に対し1フレームで合計2フレームとなっている。ライト自動制御311も、処理サイクルは6サイクルで、高速/低速シャッターで2枚の画像、処理量はそれぞれの画像に対し1フレームとなっている。ドライブレコーダ302は、一定間隔(ここでは6フレーム)毎に1枚の画像を記録すればよい。この場合のアプリケーション実行のスケジューリングを、図8(a)と(b)に示す。同図(a)では、車線逸脱警報310で使用する高速/低速シャッターを適用した画像1,2を、ライト自動制御311で使用する画像と共有できる場合を示している。このとき、車両検知とレーン認識の画像処理機能のカメラ制御が同一であるとする。車線逸脱警報310とライト自動制御311とで同じ画像が使用できるため、画像1に対して、車線逸脱警報310の処理1とライト自動制御311の処理3とを実行し、画像2に対してそれぞれ処理2と処理4を実行する。結果として、同図(a)のようなスケジューリングを図3のアプリケーションスケジューリング部14の機能によって実行し、3つのアプリケーションで1つの撮像デバイス6を共有することができる。
車線逸脱警報310とライト自動制御311がそれぞれの画像を共有できない場合について、図8(b)を用いて説明する。このとき、それぞれのアプリケーションで使用するカメラパラメータ制御が異なり、必ずしも同一の制御にならない場合を想定している。車線逸脱警報310とライト自動制御311の画像が共有できないため、ライト自動制御311は独自に画像4,5の2枚の画像を取得する必要がある。車線逸脱警報310とドライブレコーダ302が使用していないフレームF2,F5で画像4,5をそれぞれ取得するようにスケジューリングを行っている。また、画像を取得するタイミングに合せてライト自動制御311のための処理3,4をフレームF0,F3にスケジューリングする。これにより、これら3つのアプリケーションで1つの撮像デバイス6を共有しながら、並行して動作させることができる。
図9は、映像アルバムのアプリケーションを動作させた場合のスケジューリングタイムチャートである。映像アルバムの高画質モード312では、画像を毎フレーム取得して、リアルタイムに圧縮する処理が求められる。画像の取得が毎フレーム行われるため、処理周期(サイクル)は1フレームとなり、図9(a)に示すようになる。一方、映像アルバムの低画質モード313の場合、画像を毎フレーム記録する必要はなく、コマ落ちした映像となる。この時の処理周期(サイクル)を仮に6フレームとすると、同図(b)に示すようなスケジューリングとなる。図から分るように、高画質の映像アルバム機能を実行させた場合、新たに撮像デバイス6を使用するアプリケーションが動作する余地が無く、ドライブレコーダ302など、映像アルバム(高画質)312と完全に画像を共有できるアプリケーションのみ並行して実行可能となる。
一方で、低画質の映像アルバム機能では、新たに別のカメラパラメータで撮像デバイス6を制御し画像を取得することができるので、様々なアプリケーションを選択して実行することができる。
図10は、アプリケーションを追加起動する手順のスケジューリングタイムチャートであり、低画質の映像アルバム機能313を動作させている状態で、ライト自動制御311を追加起動した場合を説明する図である。同図(a)では、低画質の映像アルバム機能313のみ動作しているため、撮像デバイス6も使用していない期間が多い。ここで、ライト自動制御311を追加する場合、その処理周期(サイクル)は最短4フレーム(画像の取込み2回、処理2回)であるため、映像アルバム機能313の処理サイクルである6フレーム内に収まる。また、サイクル数が4フレーム以上であれば、映像アルバム(低画質)313とライト自動制御311は並行して実行することができる。本実施例では、ライト自動制御311のサイクル数を6フレームとしている。
図10(b)のようなスケジューリングを、図3のアプリケーションスケジューリング部14において実行した結果、映像アルバム機能313とライト自動制御311の2つのアプリケーションを並行して動作させることができる。このとき、追加されたライト自動制御311の処理の開始は、映像アルバムの処理サイクルに合せて始めるようにコントロールされる。また、画像取込みにおいて映像の同期信号に同期して画像取得を行うため、処理のサイクルや開始タイミングは全て映像の同期信号に合せている。
以上の本発明の実施形態によれば、カメラパラメータを動的に変化させるアプリケーションの間においても、撮像デバイス6を共有することができる。
図11は、並行して動作可能なアプリケーションのグループ化の一例図である。動作可能なアプリケーションを予めグルーピングしておき、グループ毎に最適なスケジューリングを行うように制御することができる。予め動作するアプリケーションをグループ化することにより、ユーザが一つひとつのアプリケーションを選択する手間を省け、また、常に最適なスケジューリングができるため撮像デバイス6を効率的に使用することができる。各アプリケーション間における基本の画像処理機能(図2)の一致度合いなどを考慮して、図6,8〜10で説明した画像取込みと処理スケジュールの実行の可否から、グルーピングを決定する。この例では、グループ1〜4に、それぞれ3つ,2つ,5つ及び2つのアプリケーションを含むようにグループ化した場合を示している。
次に、本発明の一実施形態におけるユーザインターフェースについて説明する。本発明によれば、1つの撮像デバイス6を共有することで、複数のアプリケーションを切替えたり、並行して処理したりすることができる。そこで、ドライバが、走行中に画像処理カメラ2,3の機能を切替えたり、もしくは新しく始めたりすることができるユーザインターフェースを提供する。
図12は、アプリケーションの選択や切替えを行うナビゲーション画面の一例図である。ドライバーが、ナビゲーション画面19上でアプリケーションを選択し、あるいは切替える場合の手順について説明する。図12には、選択できる多数のアプリケーションが画面19上に表示されており、ドライバは、ナビゲーション画面19のアプリケーション表示部にタッチすることで、実行アプリケーションを選択することができる。例えば、映像アルバムの高画質を選択した場合について説明する。なお、図12以降の画面19においては、図2に示した多数のアプリケーションのうちの一部を紙面のスペースの都合で割愛しているが、実際には、全てのアプリケーションが表示される。
図13は、映像アルバムの高画質を選択した後の画面を示す。まず、高画質の映像アルバム機能312が選ばれ、動作中であるため、画面19上には、太線で図示するように、「映像アルバム(高画質)」が明るく表示されている。映像アルバム(高画質)312が動作中である場合には、図9(a)で説明したように、並行して動作できるアプリケーションは大幅に限定される。ここでは、図11の並行動作可能グループ4に示したように、モニタリング機能303が並行して動作可能であるものとする。したがって、「モニタリング」の表示は、実線で図示したように選択可能であることを示す色や明るさで表示されている。これ以外のアプリケーションの表示は、破線で示したように、全て選択不可の状態表示に切替わっている。
ドライバが、映像アルバム(高画質)312を止めたい場合は、「リセット」ボタン部にタッチするか、「映像アルバム(高画質)」表示部に再度タッチするとこのアプリケーションを終了する。アプリケーションの起動や停止は、直ちに撮像デバイスの制御に反映され、撮像デバイスから得られる画像は変化する。このとき、得られる画像自体が露光制御などによって変化する場合と、処理サイクルが変化して出力する画像のタイミングが変化する場合の2種類の変化が発生する。1つの撮像デバイス6を複数のアプリケーションで共有しているため、動作しているアプリケーションが変化すると、撮像デバイスの出力データを変化させる必要がある。
図14は、アプリケーションの追加を行うナビゲーション画面の一例図である。映像アルバム(低画質)が動作中には、映像アルバム(高画質)が動作中の場合よりも、他の多数のアプリケーションが実行可能である。図11の並行動作可能グループ4に示したように、映像アルバム(低画質)313のほかに、ライト自動制御311、割込み車両警報301、車線逸脱警報310及び駐車支援304の処理が可能である。図14(a)のナビゲーション画面19では、映像アルバム(低画質)が動作中であることを明示するとともに、そのほかに上記の4つのアプリケーションが起動可能であることを表示している。ここで、ドライバが、ライト自動制御311を追加起動した場合について説明する。この場合、図14(a)の画面で、「ライト自動制御」の表示部にタッチしたとする。
図14(b)は、ライト自動制御311が追加起動された画面である。図示するように、「ライト自動制御」の表示部は動作中であることを示す表示に切換るとともに、このアプリケーションが起動される。
さて、ナビゲーション画面19では、アプリケーションの選択や切替えは、ドライバの指示によることを想定しているが、ドライバ以外の情報でアプリケーションの選択や切替えを行うこともできる。例えば、高速で走行中には、駐車することはあり得ないため、駐車支援機能304は選択されることはない。この場合、アプリケーションの選択範囲を車速で限定して駐車支援機能を選択できないようにすることが望ましい。図14(b)では、高速走行中であるため、「駐車支援」の表示部が、選択不可に切換った状態を例示している。また、ドライバが駐車支援を予め選択していたとしても、予定の高速となった場合、同様に、「駐車支援」の表示を消し、選択も不可能とする。高速移動中は、割込み車両警報301や車線逸脱警報310などのアプリケーションが動作可能であり、これら可能なアプリケーションのみを表示し、選択を可能としている。
また、アプリケーションの切替えの例として、市街地を走行中は、衝突軽減などの安全機能が優先的に動作し、車線逸脱警報や映像アルバム機能よりも優先して動作させることもできる。その反対に、観光地や風光明媚な場所では、映像アルバム機能を優先して動作させ、他の機能を停止させることも可能である。さらに、このように、ドライバの操作以外に、ブレーキ、GPS、車速など各種センサからの情報を下に、周囲環境の変化に応じて動作するアプリケーションの選択を制限したり、アプリケーションの動作自体を切替えたりすることができる。
以上のように、図3のアプリケーションスケジューリング部14によって、アプリケーションの実行、追加起動及び停止などを行えば、ナビゲーション画面からドライバの意志によって動作アプリケーションを切替えることができる。
図12〜14では、ナビゲーション画面19上でのアプリケーションの切替え手順を説明したが、ナビゲーション画面以外で実行するアプリケーションの選択を行っても良い。例えば、ハンドルにボタンを付けて、レーン維持走行機能を選択しても良い。この場合、ドライバがボタンを押した時点でどのアプリケーションが動作しているか分らない。そのため、スケジューリングの方法としては、レーン維持走行機能を最優先に設定して、レーン維持走行機能と並行して動作しないアプリケーションについて、強制的に終了するよう制御することが考えられる。このような仕組みは、ボタンだけではなく、自動車に搭載されている様々なセンサがその役割を果たしても良い。例えば、障害物を検知する距離センサと接続して、障害物がありそうだとの信号が入力された場合、最優先で障害物回避のアプリケーションが起動するということも可能である。この場合、それまで動作しているアプリケーションを動作させたまま障害物回避アプリケーションが動作するのであれば、動作中のアプリケーションはそのままでよい。また、並行して動作できないのであれば、動作中のアプリケーションを中断し、障害物回避のアプリケーションを即座に起動して安全支援のための機能が作動しはじめるように制御することもできる。これらの機能は図3のアプリケーションスケジューリング部14によって実現される。
図15は、本発明の一実施形態によるアプリケーションの追加起動を行う処理フロー図である。例えば、図10及び図14で述べたように、映像アルバム(低画質)313の動作中に、ドライバが、ナビゲーション画面19において、ライト自動制御311を追加起動する場合を想定する。ドライバによって、「ライト自動制御」がタッチパネルにより選択されると、ステップ201において、ナビゲーションからアプリケーション追加のイベントを受け付け、割込み処理でこの処理を起動する。イベントを受け付けた後、プログラムは、ステップ202において、実行中及び追加するアプリケーションの情報を取得する。これらの情報は、図3の環境情報データベース17に格納されており、実行中のスケジュール、現在のフレーム、各アプリケーションの処理サイクル、カメラパラメータを含む画像取得情報である。また、図11で説明したような、どのアプリケーションが並行して実行できるかを調査したグルーピング情報などがある。ステップ203のスケジューリング処理では、選択されたライト自動制御が、動作している映像アルバム(低画質)機能と同じグループにあるかを確認する。グルーピング情報がなくても、選択されたアプリケーションが実行可能なアプリケーションであるか否かを、アプリケーション情報を参照して確認できる。実行可能か否かは、処理のサイクル数、取得画像枚数、必要な画像処理機能の情報を基に、図6〜10で説明したような、処理周期内への必要処理の割振りの可否により判定される。実行可能なアプリケーションと実行不可能なアプリケーションとの区分けを行った後、それらの情報をアプリケーション情報に反映する。実行可能であった場合、環境情報17内のアプリケーション情報やスケジューリング情報を用いてスケジュールを更新する。すなわち、追加起動を要求されたアプリケーションが動作中のアプリケーションとの間で、時間的に重なることなく1つの撮像デバイスから画像データの取込みを繰返すようにスケジュールを更新するのである。ステップ204では、更新した新たなスケジュールで再度、追加可能なアプリケーションを解析し、ドライバに通知したり、次のアプリケーション追加イベントに備えた後、ステップ205で処理を終了する。
このアプリケーションの追加起動の処理は、イベント発生を検知して割込み処理にて実行されるため、図7で説明したフローのどのステップで割込み処理が行われるか分からない。処理中の情報の整合性を確保するために、本実施の形態では、スケジュールの更新は図7のステップ71で行っている。
この実施形態による画像処理カメラシステムを要約すると次の通りである。まず、並行して実行可能な複数のアプリケーションを選択するステップ(202)を備えている。次に、実行可能な複数のアプリケーションが、時間的に重なることなく1つの撮像デバイスから画像データの取込みを繰返す画像データ取込みタイミングとインターバルを決定するスケジューリングステップ(203)を備えている。また、このスケジューリングステップ(203)は、各アプリケーションにおける取込んだ画像データを用いる処理を含めたタイミングを決定するステップを含んでいる。さらに、複数のアプリケーションにおいて必要な画像データの枚数と、必要な取込み頻度とを、これらを記憶した記憶手段(17)から読出すステップを含む。そして、読出した画像データの枚数と取込み頻度とに基いて、実行可能な複数のアプリケーションが、1つの撮像デバイスから画像データの取込みを繰返す画像データ取込みタイミングとインターバルを決定するステップを含んでいる。
図16は、新規アプリケーションの追加と既存アプリケーションの削除を実行する画面の一例である。アプリケーションは、処理周期(サイクル)、画像処理機能、使用する画像、処理量など動作に必要な情報を規定して、メニューに追加することができる。これを、従来のアプリケーションと同様に、画面から選択したり、削除したりすることができる。図16では、新たなアプリケーションを追加するために、ダウンロードするタッチパネル部191と、既存のアプリケーションを削除するためのタッチパネル部192を表示している。
図17は、新規アプリケーションをダウンロードする処理フロー図である。図16の画面を用いてダウンロードする際の説明を行う。新しいアプリケーションは、インターネットやコンパクトフラッシュ(登録商標)などの記録メディアから取得する。ユーザがダウンロードからの新規アプリケーションの選択を選んだ場合、ステップ171から、この処理が起動される。ステップ172では、ダウンロード可能なアプリケーションがユーザにメニューとして提示される。ステップ173において、ユーザは、メニューの中から必要な新規アプリケーションを選択する。この結果の下に、ステップ174で追加する新規アプリケーションの選択が終了すると、ステップ175では、並行して動作可能なアプリケーションの解析を実行する。並行して実行可能なアプリケーションの組合せは、前述した通り、処理のサイクル数,取得画像枚数及び必要な画像処理機能等から判断する。この結果により、図11に示した既存のグルーピングを更新する。ステップ176では、全てのグループでの組合せを確認した後、情報をアプリケーション情報として格納し、ステップ177でダウンロード処理を終了する。
図18は、新規アプリケーションを含めた動作スケジューリングの処理フロー図である。このスケジューリング処理は、図15のステップ203のスケジューリングで行っている処理である。まず、ステップ181でスケジューリング処理が起動され、ステップ182で実行中のアプリケーション及び追加されるアプリケーションの情報を取得する。そして、ステップ183で、最短の処理サイクルを持つアプリケーションについて、スケジュール上にマッピングする。このとき、他のアプリケーションが動作可能なように、できるだけ余裕を持たせてマッピングする。例えば、6フレーム以内に処理が完了すればよいアプリケーションを3フレームで処理をするようなマッピングはしない。最短の処理サイクル数を持ったアプリケーションをマッピングした後、ステップ184では、次に短い処理サイクル数を持ったアプリケーションをマッピングする。ここで、マッピングに失敗した場合、つまり、撮像デバイス6が使用できなかったり、ソフト処理の時間が取れなかった場合、1つ前のステップ183のアプリケーションのスケジューリング処理に戻る。そして、撮像デバイス6の使用タイミングやソフト処理のタイミングを変更し、再度、ステップ184の2番目に短い処理サイクル数を持つアプリケーションのマッピングを行う。マッピングができた場合、ステップ185に移行し、逐次、スケジュールにアプリケーションをマッピングする。ステップ186では、最長の処理サイクル数をもつアプリケーションについてスケジュール上にマッピングできることを確認する。途中でスケジュール上にマッピングできないアプリケーションが出現した時点で、要求されたアプリケーションの追加は、並行して実行できるアプリケーションではないと判断して、その旨をユーザに知らせ、追加起動を断念する。
以上の実施形態においては、画像データを取得する撮像デバイス(6)と、この撮像デバイスから得られた画像データを用いてそれぞれが異なる機能を持つように設定された複数のアプリケーション(151〜15N)を備えている。また、複数のアプリケーションに対応した画像データ取得要求に応じて撮像デバイスを制御する撮像デバイスコントロール部(13)を備えている。さらに、複数のアプリケーションが1つの撮像デバイスからの画像データを取込んで複数のアプリケーションを並行して実行させる制御部(14)を備えた画像処理カメラシステムを前提としている。ここで、複数のアプリケーションにおける必要な画像データ数と画像データ取込み頻度を記憶する手段(17)を備える。また、これら画像データ数と画像データ取込み頻度に基き、並行して実行可能な複数のアプリケーションを選択する手段(14)を備える。次に、実行可能な複数のアプリケーションが、1つの撮像デバイスから時間的に重なることなく画像データの取込みを繰返す画像データ取込みのタイミングとインターバルを決定する画像取込みスケジューリング部(14)を備える。このスケジューリング部(14)は、各アプリケーションにおける取込んだ画像データを用いた処理を含めたタイミングを決定するように構成している。
また、1つの撮像デバイスからの画像データを用いて並行して実行する複数のアプリケーションの組合せを記憶するアプリケーショングループ記憶手段(17)を備える。ここで、前記の選択手段は、アプリケーショングループ記憶手段から、並行して実行可能なアプリケーショングループについてのデータを読出している。
さらに、複数のアプリケーションを実行させるために撮像デバイスを制御する複数の基本画像処理機能部(16A〜16M)を備える。そして、必要とするこれら基本画像処理機能の一致の度合いに基き、1つの撮像デバイスからの画像データを用いて並行して実行する複数のアプリケーションを決定する手段を備えている。
前記の、画像データ数と画像データ取込み頻度に基き、並行して実行可能な複数のアプリケーションを選択する手段(14)は、あるアプリケーションを実行中に、実行中のアプリケーションと同一のアプリケーショングループに属することに基いて、実行可能な他のアプリケーションを選択するようにしている。また、必要とする基本画像処理機能について、実行中のアプリケーションとの一致の度合いに基いて、実行可能な他のアプリケーションを選択する一助としている。さらに、実行中のアプリケーションによる撮像デバイスからの画像データの取込み期間の合間のタイミングで、他のアプリケーションが必要とする撮像デバイスからの画像データ取込みが可能であることに応じて、他のアプリケーションを実行可能なアプリケーションとして選択するようにしている。
次に、マンマシンインターフェースについては、実行可能なアプリケーションを表示する手段(19)と、この表示された実行可能なアプリケーションの起動をユーザが指示するための操作手段を備えている。また、実行中のアプリケーション及び追加実行可能なアプリケーションを表示する手段と、追加実行可能なアプリケーションの起動及び実行中のアプリケーションの停止をユーザが指示するための操作手段を備えている。そして、この操作手段による指示入力に基きアプリケーションの起動及び停止を行う制御手段を備えている。
また、周囲環境の変化に応じて追加実行可能なアプリケーションを切替える実行可能アプリケーション選択手段と、この選択手段によって選択された実行可能なアプリケーションを表示する手段を備えている。
さらに、新たなアプリケーションのダウンロードによる追加を要求する操作手段を備えている。
これらの特徴により、複数のアプリケーションで1つの撮像デバイスを信頼性高く、かつ効率的に共有することができる。また、実行可能なアプリケーションをユーザが選択でき、ユーザに選択されたアプリケーションを即座に実行することができる。さらに、優先的に実行すべきアプリケーションをシステムの状況によって選択し、実行することができる。
これまで、本発明を、自動車に搭載する画像処理カメラシステムに適用した実施形態について詳細に説明したが、本発明は多種の画像処理カメラシステムに応用することができる。例えば、侵入者監視カメラシステムにも本発明を適用できる。ある特定の機能を実現するカメラを複数台設置するよりも、共有できる画像処理機能がある場合に本発明を適用し、アプリケーションが必要とする機能毎にカメラを信頼性高く共有して、カメラ台数を削減することができる。
1…自動車、2,3…カメラ、4…ネットワーク、5…インターフェース手段、6…撮像デバイス、7…撮像デバイスインターフェース、8…RAM、9…ROM、10…CPU、11…外部インターフェース手段、12…マイクロコンピュータ、13…撮像デバイスコントロール部、14…アプリケーションスケジューリング部、151〜15N…N個のアプリケーション、16A〜16M…画像処理機能(A〜M)、17…環境情報、18…インターフェース、19…画面。