車載用マルチアプリ実行装置
【課題】限られた処理能力のなかでリアルタイム性を損なうことなく複数のアプリケーションの動作保証を図り、打ち切り処理の発生を抑制することで利便性を保ちつつも安全性を確保することができる車載用マルチアプリ実行装置を提供すること。
【解決手段】車載用マルチアプリ実行装置は、各アプリの処理時間を動的に予測し、その予測した処理時間に基づいて各アプリのスケジューリングを行う。そして、スケジューリングを行った結果、規定周期内に処理が終了しないアプリケーションが存在すると判断した場合に、予め設定された優先順位に基づいて、アプリケーションの打ち切り、もしくはアプリケーションの機能を低下させる処理を行う。
【解決手段】車載用マルチアプリ実行装置は、各アプリの処理時間を動的に予測し、その予測した処理時間に基づいて各アプリのスケジューリングを行う。そして、スケジューリングを行った結果、規定周期内に処理が終了しないアプリケーションが存在すると判断した場合に、予め設定された優先順位に基づいて、アプリケーションの打ち切り、もしくはアプリケーションの機能を低下させる処理を行う。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、例えば車載カメラ等の車載装置において複数のアプリケーションを実行する車載用マルチアプリ実行装置に関する。
【背景技術】
【0002】
車両走行に利用する情報を処理する装置において情報を的確に処理することが車両走行の安全性向上にとって重要である。近年、車両走行の安全性を高めようとするニーズがあり、情報処理装置における情報の処理量が多くなる傾向にある。車両の安全走行に関する情報の処理を、常に全て実行することは情報処理装置の負荷が大きくなり、対応速度の関係などで問題が出てくる。このため、規定周期内に処理が完了しないと判断した場合、次周期のCPU空き時間を上限として現周期に処理が完了しなかったアプリケーションのプログラムにCPU時間を割り当てることで、規定周期を保証しながら処理の打ち切りを抑制する技術が提案されている(例えば特許文献1を参照)。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2009−86733号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、例えば車載カメラの画像認識を行うアプリケーションでは、現周期の処理が完了しなかった場合、次周期も負荷が高く空き時間が無い可能性が高い。このため、画像認識のアプリケーションでは、単に次周期のCPU空き時間を活用するだけでは、処理打ち切り抑制の効果は不十分であり、限られたCPU処理能力で、走行状況に合わせたマルチアプリケーションのスケジューリングが重要になると考える。
【0005】
本発明は、上記の点に鑑みてなされたものであり、その目的とするところは、限られた処理能力のなかでリアルタイム性を損なうことなく複数のアプリケーションの動作保証を図り、打ち切り処理の発生を抑制することで利便性を保ちつつも安全性を確保することができる車載用マルチアプリ実行装置を提供することにある。
【課題を解決するための手段】
【0006】
上記課題を解決する本発明の車載用マルチアプリ実行装置は、規定周期内に複数のアプリを実行する車載用マルチアプリ実行装置であって、各アプリの処理時間を動的に予測し、該予測した処理時間に基づいて各アプリのスケジューリングを行うことを特徴としている。
【発明の効果】
【0007】
本発明の車載用マルチアプリ実行装置によれば、各アプリの処理時間を動的に予測し、該予測した処理時間に基づいて各アプリのスケジューリングを行うので、限られた処理能力でリアルタイム性を損なうことなく複数のアプリケーションプログラムの動作保証を図ることができ、打ち切り処理の発生を抑制することによって利便性を保ちつつも安全性を確保することができる。
【図面の簡単な説明】
【0008】
【図1】本実施の形態における車載用マルチアプリ実行装置のブロック図。
【図2】車両制御部のブロック図。
【図3】走行環境情報部のブロック図。
【図4】マルチアプリ実行部のブロック図。
【図5】動的処理時間予測部のブロック図。
【図6】車両搭載のマルチアプリ実行装置の配置図。
【図7】一般道モードのタスクテーブルの一例を示す図。
【図8】高速道モードのタスクテーブルの一例を示す図。
【図9】従来のスケジューリングによる結果を示す図。
【図10】本実施の形態における車載用マルチアプリ実行方法を説明する処理フロー。
【図11】本実施の形態におけるスケジューリングの一例を説明する処理フロー。
【図12】本実施の形態におけるスケジューリングの他の一例を説明する処理フロー。
【図13】従来のスケジューリングの問題点を説明する図。
【図14】本実施の形態におけるスケジューリングの一例を説明する図。
【図15】本実施の形態における歩行者検出方法の一例を説明する図。
【図16】本実施の形態における車両検出方法の一例を説明する図。
【図17】本実施の形態における歩行者検出方法の他の一例を説明する図。
【図18】本実施の形態における機能小分割による並列処理の作用と効果を説明する図。
【図19】本実施の形態における処理周期を短縮するスケジューリングを説明する図。
【図20】本実施の形態における利便性を追加するスケジューリングを説明する図。
【図21】マルチコアにおけるスケジューリングの一例を説明する図。
【図22】マルチコアにおけるスケジューリングの一例を説明する図。
【図23】マルチコアにおけるスケジューリングの一例を説明する図。
【図24】車載用マルチアプリ実行装置の他の実施の形態を説明する図。
【図25】予測処理時間の算出方法を説明する図。
【図26】動的処理時間予測部のブロック図。
【図27】予測処理時間の算出方法を説明する図。
【図28】一般道モードのタスクテーブルの一例を示す図。
【図29】一般道モードのタスクテーブルの一例を示す図。
【図30】一般道モードのタスクテーブルの一例を示す図。
【発明を実施するための形態】
【0009】
<システム構成>
図1は、本実施例における車載用マルチアプリ実行装置の機能ブロック図である。
【0010】
車載用マルチアプリ実行装置100は、車載の安全性もしくは利便性を向上するための認識を行う複数のアプリケーション(以下、単にアプリという)を規定周期内にリアルタイムで実施するものであり、本実施例では、車載用のカメラ装置内に一体に構成されている。
【0011】
車載用マルチアプリ実行装置100は、図1の機能別構成のブロック図に示すように、カメラ撮像部101、動的処理時間予測部111、マルチアプリ制御部(スケジューラ)121、マルチアプリ実行部131を備えている。
【0012】
カメラ撮像部101は、自車周囲、もしくは車内を撮影し、動的処理時間予測部111は、規定周期ごとに各アプリの処理時間を予測する。リアルタイムに応答性を求められる車載用マルチアプリ実行装置100は、予め設定された時間内に複数のアプリを実行する。この予め設定された時間を規定周期とする。
【0013】
マルチアプリ制御部121は、動的処理時間予測部111によって動的に予測された予測処理時間を利用して、各アプリを安全性と利便性の観点から適切にスケジューリングする。スケジューリングでは、各アプリについて、実施の可否及び実施の順番が決定される。
【0014】
マルチアプリ実行部131は、マルチアプリ制御部121のスケジューリング結果に基づいてアプリを実行する。マルチアプリ実行部131によって出力される結果は、車両制御部250にCAN(Controller Area Network)経由で通信され、車両の安全性に関する、制御、警報、警告、表示などに利用される。
【0015】
車両制御部250は、自車両の走行状況を把握しているとともに、CAN経由で走行環境情報部210と通信し、自車走行環境に関する情報を得ている。これら車両制御部250の情報、走行環境情報部210の情報、マルチアプリ実行部131の情報より、動的処理時間予測部111は、次周期における各アプリの処理時間を予測する。
【0016】
図2に車両制御部250の構成を示す。車両制御部250は、図2に示すような、車速センサ261、操舵角センサ262、ヨーレートセンサ263、アクチュエータ264、ブレーキ265、アクセル266、変速ギヤ267からなり、車両の走行状態を制御する。車両制御部250は、車両ECU260を中心に車両の制御を行う。車両ECU260は、ブレーキ265や、アクチュエータ264、アクセル266、ギヤ267を制御するとともに、車速センサ261、操舵角センサ262、ヨーレートセンサ263から現在の状態の情報を通信にて管理する。車両制御部250は、マルチアプリ実行部131の結果に応じて、安全のための制御、警告、警報、表示を実施する判断も行う。
【0017】
走行環境情報部210は、図3に示すように、ウィンカー213、アプリ操作214、カーナビ215、レーダ216、路車間通信217、車々間通信218などから、車両走行には直接関係しない情報であって車両周囲の走行環境の状況を示す情報を得ている。車載用マルチアプリ実行装置100の動的処理時間予測部111は、走行環境情報部210の結果を利用して、動的処理時間の予測を行っている。なお、図6は、車載用マルチアプリ実行装置100を車両に搭載した配置例を模式的に示す図である。
【0018】
図4は、マルチアプリ実行部131の詳細な構造を示すブロック図である。マルチアプリ実行部131は、全ての画像処理のアプリが機能別に登録されており、必須機能部1100と付加機能部2100の2つに分類された構造をもつ。マルチアプリ実行部131の機能は、図4に示すように、事故予防に直接的効果のある必須機能部1100と、より快適な運転支援を主目的とする付加機能部2100に分類される。
【0019】
マルチアプリの処理負荷が高く規定周期内に処理が完了しないような場合にも、安全性確保のために動作保証したいアプリを必須機能部1100として登録することで安全性を確保する。例えば、想定していた以上に歩行者候補や車両候補等がカメラ撮像部101の視野内に入った場合などには各アプリの処理時間が大きく伸びる。このように既定周期内に処理が完了しないような場合、既定周期を守るために処理の打ち切りを行うか、又は、規定周期の延長を容認している。
【0020】
規定周期内に処理が完了せずに処理の打ち切りを実行すると安全性低下につながると考えて規定周期の延長を容認する安全性機能と、規定周期の延長よりも処理の打ち切りを実施して規定周期を厳守することがより安全性の確保に重要と考える付加機能とにアプリの種類を分類することで、安全性を保ちつつ、通常時の利便性を向上している。
【0021】
規定周期を守るために処理を打ち切った場合、次周期まで結果が得られない他、次周期においても再度同一アプリに対して処理の打ち切りが発生する可能性がある。リアルタイム性を確保すべく規定周期を守ることだけに固執しては、安全性の観点から矛盾が生じる。そもそも処理の打ち切りが発生しないようなスケジューリングが望ましいほか、処理負荷が高い場合に、安全性のアプリに割り当てることのできるCPUの空き時間が重要である。
【0022】
処理負荷が高い場合など常に動作保証する必要はないが、通常走行時にドライバにとって有用な情報を提供するアプリを付加機能部2100として登録することで利便性を追求する。利便性のための付加機能は、安全性のアプリの動作保証をするためのCPUの空き時間マージンとして利用できる他、通常時はその利便性を有効活用することができる。
【0023】
本実施例では、図4に示すように、レーン認識アプリ130、歩行者検知アプリ140、車両検知アプリ150について、必須機能部1100と付加機能部2100に分類して登録することで、安全性を重視した設計を可能にするとともに利便性の両立を行う。そして、オートライトアプリ160、標識検知アプリ170、路面標識検知アプリ180については、付加機能部2100のみに登録している。
【0024】
レーン認識アプリ130は、カメラ撮像部101によって撮影された画像から道路の白線WLを認識する画像処理機能を有する。レーン認識アプリ130は、予防安全に直接効果が期待される車線逸脱防止に必要な車線内における自車両の横位置、ヨー角を推定することが可能な必須版アプリ1130を必須機能部1100に分類する。そして、カーブより遠方の白線WLの状況を検知対象とし、カーブ進入前における減速やカーブ時における操舵支援など快適な走行に効果が期待される付加版アプリ2130を付加機能部2100として分割する。
【0025】
このようにレーン認識アプリ130のうち、安全性に直接関係のある車線逸脱防止のための認識機能を必須版アプリ1130として必須機能部110に分類し、利便性に関連するカーブ進入前減速のための認識機能を付加版アプリ2130として付加機能部2100に分類する。処理負荷の高いアプリケーションが想定した処理時間内に処理が完了しないような場合に、利便性に関連するアプリの処理を停止もしくは性能劣化させて実施することで、規定周期の保証を行うとともに、安全性に関わる処理の打ち切りを抑制し、より高い安全性を実現する。
【0026】
歩行者検知アプリ140も、車速に応じた制動距離を考慮し衝突回避可能な距離に対して動作保証する必須版アプリ1140と、より遠方での歩行者候補に対しても検知処理を行う付加版アプリ2140に分類される。安全性確保のための必須版アプリ1140では、歩行者がある程度近距離にいることを想定しているため、高解像度の画像を利用するよりも、ある程度の解像度の画像を利用し、検知結果の更新周期をより早めることを重視した設定とする。そして、歩行者検知アプリ140の付加版アプリ2140では、より遠方の歩行者を対象とするために、高解像度の画像を利用する。
【0027】
車両検知アプリ150も、先行車両との相対速度や距離、自車舵角を考慮し衝突を回避するために必要な車両候補に対して画像処理を行う必須版アプリ1150と、より早期な車両の検知や検知率の向上、車間距離制御などを目的により遠方の車両を検知対象とする付加版アプリ2150に分類される。解像度や処理周期に関する方針は、歩行者検知アプリ140と同様である。
【0028】
歩行者検知アプリ140や車両検知アプリ150は、衝突回避のための認識処理を必須版アプリ1140、1150に分類し、車両制御には直接利用しない遠方などの認識を付加版アプリ2140、2150に分類することで、機能別の処理周期制御や機能のON、OFFを実現する。このように各アプリを機能別に必須機能部1100と付加機能部2100に分類することで、処理負荷が高く規定周期内に処理が完了しそうに無い場合に、付加版アプリの機能はその処理を停止、もしくは精度劣化させることで処理負荷を軽減させ、規定周期内に処理が完了するようにすることができる。従って、リアルタイム性を保証し、より安全性を高めるとともに、通常時の利便性を確保することができる。
【0029】
オートライトアプリ160は、カメラ撮像部101で車外を撮像した画像の画像認識を行うことにより外界の明るさを検知し、ヘッドライトのON、OFFや方向を制御する。先行車の検知と併用することで、ハイビームとロービームの制御を行う。レーン認識アプリ130、もしくは車両制御部250の車速センサ261と舵角センサ262からの自車両予測進路、もしくはカーナビ215からの自車両予測進路と併用することでカーブ方向へヘッドライトの照射角度の制御を行う。更に路面標識検知180と併用することで、交差点における照射角度の制御などに利用する。オートライトアプリ160は、より快適な運転支援を目的としており、このアプリ全体を付加機能部2100に分類する。
【0030】
標識検知アプリ170は、制限速度などの道路標識の検知を行い、この情報をドライバに提供することで快適な運転支援を目的とするため、このアプリ全体を付加機能部2100に分類する。
【0031】
路面標識検知アプリ180は、路面上の制限速度表示などの検知や、横断歩道を検知することにより、ナビ位置情報の高精度化などのドライバへの運転支援の情報を検知する機能のため、このアプリ全体を付加機能部2100に分類する。
【0032】
図5に、動的処理時間予測部のブロック図を示す。動的処理時間予測部111では、動的処理時間予測制御部112にて各アプリ機能別に予測に利用する情報を、走行環境情報部210、マルチアプリ実行部131、車両制御部250の中から選択し、その選択した情報を各機能の動的予測部3130−3150、4130−4180に送信する。各機能の動的予測部3130−3150、4130−4180は、動的処理時間予測制御部112から得られた情報に基づいて、次フレームにおける処理時間を予測する。
【0033】
<タスクテーブル>
マルチアプリ制御部121は、タスクテーブルをベースにして基本のスケジューリングを行い、動的処理時間予測部111で予測した予測処理時間を利用してスケジューリングの内容を修正する。打ち切り処理の対応や、低負荷時における利便性機能の追加などは、予測処理時間を利用した上で修正される。
【0034】
図7は、一般道路の走行時に使用されるタスクテーブルを示し、図8は、高速道路の走行時に使用されるタスクテーブルを示す。タスクテーブルは、図7及び図8に示すように、各アプリを分類して縦軸に並べると共に、設定項目を横軸に並べており、各アプリを設定項目別に制御するようになっている。タスクテーブルにて設定する各項目の内容について以下に説明する。
【0035】
有効フラグとは、一般道路を走行する一般道モードや、高速道路を走行する高速モード等から選択されたモードにて、アプリを動作すべきか否か、換言すると、アプリの実行の可否を判定するためのフラグであり、ONで動作、OFFで停止を意味する。
【0036】
レーン認識アプリ130、歩行者検知アプリ140、車両検知アプリ150は、必須機能部1100と付加機能部2100からなるアプリケーションであり、必須機能部1100の有効フラグがOFFの場合、同一アプリの付加機能部2100の有効フラグは必ずOFFとするように設定されている。
【0037】
例えば、レーン認識アプリ130の必須版アプリ1130が有効フラグOFFで動作停止した状態において、レーン認識130の付加版アプリ2130のみが有効フラグONであり動作するということはない。必須機能部1100がONの場合には、付加機能部2100に属するアプリは、状況に応じて制御する。
【0038】
必須機能部1100のON、OFFは、現在高速道路を走行中なのか、一般道を走行中なのか等の車両制御部250の自車両走行情報に基づいてモード設定を行う際に、変更される。例えば、高速道路を走行中は、歩行者は高速道路にいないとの仮定より、歩行者検知機能を動かすよりも他機能にプロセッサ処理を割り当てた方が、ドライバにとって快適で安全な運転ができると考え、歩行者検知アプリ全体をOFFとし、他機能の処理の優先や、高速移動時における1サイクル分の処理時間を短くするためにアプリのON、OFFを制御する。また、この他、カーナビゲーションのモニタ画面からユーザが選択するような方法でON、OFFを変更しても良い。
【0039】
付加機能部2100のON、OFFは、車両制御部250からの自車両走行情報及びアプリからの認識情報に基づいて制御される。また、動的処理時間予測部111で動的に予測した各アプリの予測処理時間の長さが、既定周期内に終了しない場合には、既定周期内に処理が完了するように、優先順位の低い付加版からOFFにすることによって、既定周期を守るようにスケジューリングする。また、処理対象の画像の解像度を低下させて、認識精度を劣化させる簡易的な手法により、リアルタイム性を確保しかつ安全性も確保してもよい。
【0040】
優先順位とは、複数のアプリを実行する場合の優先順位を示し、数字が小さい方が優先度の高いアプリであることを示す。例えば、歩行者検知アプリ140で、ブレーキの制御が必要となるような歩行者候補を発見し、更に歩行者検知の処理時間が長くなったような場合、歩行者検知機能よりも優先順位が低い付加版の処理を、優先順位が低い順に停止する。このように優先順位にしたがって順番にアプリの停止などを試みることで、安全性と利便性をできる限り両立する。
【0041】
割当コア(CPU)とは、マルチコア、もしくはマルチCPUを利用する場合において、各機能別に担当するコア(CPU)の割当を指定する場合に利用する。コアの数が増えた場合などには、一つの機能に対して複数コア(CPU)の割当を行うような場合にも、このタスクテーブルの設定内容を利用する。処理時間の予測結果に応じて動的にCPUの割当を変える場合には、タスクテーブルの設定内容を書き換える。シングルコアもしくは、シングルCPUの場合、もしくはマルチコア、もしくはマルチCPUであっても機能別にCPUの担当を決めずに、対称的、均一的に処理を割り当てる並列処理方式SMPの場合には、割当コアを全て1とし、明示的に各コア(CPU)に対して機能を割り当てない。
【0042】
処理とは、複数のアプリの処理が完了する規定周期におけるアプリの処理回数を示す。本画像処理装置における規定周期とは、例えば図9に示すような、一連の処理1回分のループを示す。同一の機能でも、優先度が低くなるにつれて処理回数が小さくなるような設計とする。例えば図7に記載されているレーン認識アプリ130の必須版アプリ1130の処理[1/1]とは、1サイクルに1回、アプリが実行されることを意味する。また、付加機能部2100のオートライトアプリ160の処理[1/3]とは、3サイクル中に1回、アプリが実行されることを意味する。
【0043】
予測処理時間に基づき、既定周期内に全てのアプリの処理が完了しそうにないと判断した場合に、まず優先度が低く、処理回数が低くても問題の生じない、処理回数の低いアプリから削ることで、優先度の高いアプリの実施が確保され、リアルタイム性が確保されて安全性が確保される場合が多い。
【0044】
例えば、レーン認識130の曲率算出部分の機能などは、道路が急に曲率が変化することがないことを考慮すると、必ずしも高い処理周期である必要はない。高い処理周期であれば精度は良くなるが、他に優先する処理があるような場合には、[1/2]で処理しても問題がない。そこで優先する機能がある場合における調整項目として処理周期の変更などが利用される。
【0045】
又、歩行者検知アプリ140の付加版アプリ2140、車両検知アプリ150の付加版アプリ2150、標識検知アプリ170、路面標識検知アプリ180などの場合は、処理周期が低くなると、検知タイミングが多少遅くなり、検知距離内に入ってからの認識処理回数が少なくなって、検知率が多少低下することが考えられるが、この検知率の低下よりも重要なアプリがある場合に、処理周期の調整にて優先事項の処理周期が早く、非優先事項については処理周期が遅くなるように調整される。カーブ中の速度抑制などの制御中には、標識検知アプリ170や、路面標識の検知率が多少下がるよりも減速制御のためのカーブ認識を高い周期で行う場合には重要となる。
【0046】
解像度とは、画像認識に利用する入力画像のサイズを示す。カメラ撮像部101で撮像される画像の最大解像度を[1、1]と示す。[a、b]の表記方法は、aが画像横方向の解像度、bが画像縦方向の解像度を示す。例えば、最大解像度768×240の場合に、入力画像として256×240の画像入力とするレーン認識アプリ130の必須版アプリ1130の解像度は[1/3、1/2]と示し、横解像度が最大解像度の1/3、縦解像度が最大解像度の1/2であることを示す。
【0047】
予測処理時間に基づき、既定周期内に全てのアプリが完了しそうにないと判断された場合には、解像度を低下させて処理時間を削減する処理を行う。解像度の低下により認識対象が近傍までになる制限がつくほか、解像度低下に伴う処理負荷低減により処理時間の削減が可能であり、性能劣化はするが応答性の確保しながらリアルタイム性を確保し、より安全で快適な車両の構築が必須となる。
【0048】
レーン認識アプリ130や歩行者検知アプリ140において、検出結果の位置精度を重要視する場合や、より遠方を検知対象とする場合、高解像度の画像を利用することが望ましい。しかし、高解像度画像を利用することによる計算コストの増加が処理周期に影響を与える。したがって、検知位置精度、検知対象距離、処理周期などの条件に応じて解像度を調整する。
【0049】
例えば、車線逸脱回避を想定した場合には、車両に対するレーンの横位置やヨー角にある程度の認識精度は必要とするものの、遠方の曲率値や車線逸脱予測位置より遠方のレーン位置などはあまり重要でない。車線逸脱回避のために車両制御するような状況では、低解像度な画像を利用し処理コストを削減することで、車両制御に利用されるレーン横位置やヨー角の更新周期を早め、より高度な車両制御を実現する。
【0050】
検知距離とは、自車から各アプリが認識対象とする対象のうち最遠方のものまでの距離を示す。例えば、通常モードにおける歩行者検知アプリ140の必須版アプリ1140の検知距離が40メートル[m]であるとは、40メートル[m]より遠方にいる歩行者については検知対象外とすることを意味する。
【0051】
歩行者検知アプリ140でいえば近傍に衝突可能性の高い歩行者が認識され、車両制御が必要と予測されるような場合に、車両制御の対象範囲外の遠方を検知することは重要ではない。したがって、遠方のものを対象からはずすことで処理コストを削減し、歩行者位置を高フレームレートで更新し、より高度な衝突回避制御を可能とする。また検知距離も遠いほど処理時間がかかるため、動的処理時間の予測に基づいて、検知距離を変更することで、処理時間の調整を行い、リアルタイム性を確保する。
【0052】
初期処理時間とは、アプリのスケジューリングの際に利用する固定値の処理時間であり、動的処理時間の予測が失敗したときや、予測処理時間が利用できないような場合に利用する処理時間である。タスクテーブル生成時や、ユーザの選択によりどのアプリを動かすかを選択する際に、決められた規定周期内に処理が終了するかどうかなどの目安として利用し、これを基に、規定周期内に処理が完了するようなマルチアプリ構成となっているかチェックすることに利用できる。
【0053】
予測処理時間とは、毎規定周期ごと、もしくはイベント成立時などに各アプリ機能別に処理が完了するために必要な時間を予測した時間である。歩行者検知などでは、レーダ261の検知情報等を利用し、処理完了に必要な時間を予測する。この予測された処理時間を利用して、タスクのスケジューリングに利用する。
【0054】
<全体処理フロー説明>
次に、本実施の形態における車載用マルチアプリ実行装置の全体処理について、図10の処理フローを用いて説明する。
【0055】
ステップS0では、車両制御状態や、マルチアプリの実行状態等の情報がフィードバッグされる。これらの情報は、処理時間の予測に利用する情報の一部である。車両制御部250の情報は、タスクテーブルの変更や、処理時間の予測に利用する。マルチアプリの実行状態は、認識結果とともに、処理時間の予測に利用する。例えばレーン認識の場合には、次周期のレーン認識を行うための処理領域の大きさを情報としてフィードバックすることで処理時間を予測する。
【0056】
ステップS1では、走行環境情報を取得する処理がなされる。ここでは、図3に示すウィンカー213、アプリ操作214、カーナビ215、レーダ216、路車間通信217、車々間通信218より走行環境の情報を取得する。これらの情報は、動的処理時間の予測や、タスクテーブルの変更に利用される。
【0057】
ステップS2では、動的処理時間を予測する処理がなされる。ここでは、ステップS0で得られた車両走行状態やマルチアプリ実行結果や実行状態の情報と、ステップS1で得られた走行環境情報を利用して、タスクテーブルにおいて有効フラグがONとなっている各アプリの処理時間を予測する。
【0058】
ステップS3では、スケジューリングが行われる。スケジューリングは、ステップS0から得られる車両制御状態やマルチアプリの実行結果、実行状態の情報、ステップS1で得られた走行環境情報、ステップS2で予測した結果である予測処理時間、及びタスクテーブルに基づいて行われる。
【0059】
ステップS4では、タスクテーブルの修正処理が行われる。ここでは、ステップS3のスケジューリングの結果に基づいて、タスクテーブルの内容に変更の必要があるか否かが判断され、変更の必要があると判断された場合に、タスクテーブルの修正がなされる。
【0060】
ステップS5では、カメラ撮像部101で撮像した画像を取得する処理がなされる。ステップS6では、ステップS3で得られたスケジューリングの結果と、ステップS4で得られたタスクテーブルの結果に基づいて、マルチアプリを実行する処理が行われる。ステップS7では、ステップS6のアプリ実行結果に基づいて、車両制御が実施される。
【0061】
なお、ステップS3、S4については、同時に実施するような方法でも良い。例えば、有効フラグ、優先順位、処理、解像度、検知距離など大まかにタスクテーブルを決定した後に、スケジューリングしながらタスクテーブルの内容に変更を加えるような方法でも良い。
【0062】
または、ステップS2、S3、S4を同時に実施するような方法でも良い。例えば、タスクテーブルの優先順位順に処理時間を予測し、その予測結果に基づいてスケジューリングを行う。そして、アプリが既定周期内に入りきらなくなった状況で、再度タスクテーブルの有効フラグ、処理周期、解像度、検知距離の見直しを行った上で、スケジューリングの再考を行うような方法でも良い。
【0063】
<スケジューリング詳細処理フロー>
次に、図10のステップS3における処理の内容について図11、図12を用いて詳細に説明する。図11は、スケジューリングの方法の一例を詳細に説明する処理フローである。ここでは、車載用マルチアプリ実行装置100の演算手段がシングルコアもしくはシングルCPUである場合を例に説明する。
【0064】
ステップS2で動的処理時間の予測が行われると、ステップS3に移行し、ステップS3で、予測された処理時間とタスクテーブルに示された優先順位とに基づいてスケジューリングが行われる。より詳細には、ステップS31で、タスクテーブルにおいて有効とされた複数のアプリの処理時間をスケジューリングした場合に、既定周期内に処理が完了しないアプリが存在するか否かを調査する。
【0065】
そして、規定周期内に処理が未完となるアプリが存在する予測された場合は(ステップS31でYes)、情報の処理量を減らすべく、ステップS34に移行する。ステップS34では、タスクテーブルで有効と判断されたアプリの精度劣化による処理時間の短縮や、アプリの停止を検討する。そして、不足処理時間分のCPU負荷を削減するために、タスクテーブルの優先順位の低いアプリから、及び予測した処理時間の長さに基づいて、不足処理時間分のアプリ削減、もしくは不足処理時間分の精度劣化を実施する。
【0066】
そして、ステップS35では、ステップS34、S38にて決定されたスケジューリングに従い、スケジューリングテーブル(スケジュール)を決定する。そして、全ての利便性のアプリ(付加機能部2100の処理)を停止しても既定周期内に処理が完了しない場合に、初めて処理周期の延長を検討し、スケジュールの修正を行う。または、安全性のアプリ(必須機能部1100の処理)であっても、既定周期より大幅に処理時間が伸びることが予測されるような場合には、打ち切り処理を実行し、次の既定周期で実施してもよい。
【0067】
システムのリアルタイムな応答が重要となる車載の認識アプリでは、検知距離なども重要な要素であるが、検知周期も重要な要素となる。この認識結果が最大何msec前の結果であるということを前提とした車両制御や、処理周期何フレームで得られる実行結果だと想定して作られた車両制御の場合に、この規定周期を守ることが安全性確保にも重要であることがわかる。
【0068】
一方、規定周期内に各アプリの処理が全て完了すると予測された場合は(ステップS31でNO)、ステップS37に移行し、CPU空き時間が多いかどうかを判定する。そして、CPU空き時間が多いと判定された場合は(ステップS37でYes)、より高い利便性の実現を図るべく、ステップS38に移行し、空き時間中に処理が完了できる範囲内で利便性機能(付加版アプリ2130〜2150や、オートライトアプリ160等)の追加を検討する。そして、ステップS37において、連続してCPUに空き時間があると判断された場合には、ステップS38で処理周期自体を短縮することも検討する。これにより、より高い安全性や、認識精度を実現することができる。
【0069】
また、CPU空き時間が少ないと判定された場合は(ステップS37でNo)、既に最適なスケジューリングであると判定し、そのまま処理を実行すべく、ステップS5に移行する。
【0070】
図12は、図10のステップS3におけるスケジューリングの方法の他の一例を説明する処理フローである。ここでは、車載用マルチアプリ実行装置100の演算手段がマルチコアもしくはマルチCPUである場合を例に説明する。なお、図11と同様の内容を有するステップには同一の符号を付することでその詳細な説明を省略する。
【0071】
ステップS31において、規定周期内に処理が未完と予測された場合は(ステップS31でYes)、ステップS32に移行し、他のコアや他のCPU、或いは専用ハード等に、処理の空き時間が存在しないかを調査する。そして、空き時間が存在すると判断された場合には、各アプリのコア(CPU)割り当て変更できるか否か、もしくは、処理時間の長い機能は、並列処理の実施により既定周期内に全ての機能が完了するか否かを調査判定する。そして、安全性の機能と優先順位の高いアプリから処理が完了するように、コア割当変更や並列処理によるスケジューリングを行う。
【0072】
ステップS33では、CPU割り当ての変更、並列処理のみで既定周期内に各アプリの処理が完了するか否かを判断し、処理が未完となると判断された場合(Yes)には、情報の処理量を減らすべく、ステップS34に移行する。また、処理が完了すると判断された場合(No)には、ステップS37に移行する。ステップS35では、ステップS32、S34、S38にて決定されたスケジューリングに従い、スケジュールを決定する。
【0073】
そして、ステップS37において、CPU空き時間が少ないと判定された場合(No)には、既に最適なスケジューリングであると判定してそのまま実行する。また、有効フラグがOFFになっている停止機能を含めて再スタートさせるとどの程度の処理時間がかかるか予測したうえで、全処理時間を予測し、先に走行環境モード選択もしくはナビからのアプリ操作によって決められたタスクテーブルをベースに優先順位が高い順にスケジューリングしてもよい。
【0074】
最後の規定処理周期の終了時をまたいで実行する機能が存在する時点で、そのアプリの優先順位と動的処理時間予測結果から、スケジュールに修正を加える。これにより、既定処理周期内にそもそも完了しないことがわかっていながらただ処理を実行して打ち切り処理を発生させることをせず、打ち切り処理が発生しないアプリで且つ優先順位は低いが処理時間が短いアプリを追加するなど対策をとり、利便性の追加を図っても良い。
【0075】
なお、利用画像の違いなどから、連続実行させた方が都合の良いアプリなどが存在するため、優先順位の高さのみでスケジューリングが難しい場合もある。このような場合には、動的処理時間の予測結果を求めてスケジューリングした後に、再度、どのアプリを有効とするかを再判定し、スケジューリングを最初からやり直すような手法でも良い。
【0076】
<処理時間の予測方法>
次に、図10のステップS2における動的処理時間の予測方法について、アプリケーション別に詳細を記す。歩行者検知アプリ140、車両検知アプリ150、レーン認識アプリ130の順番で説明する。
【0077】
例えば、歩行者検知アプリ140の場合、レーダ216とカメラ装置を併用するフュージョン方式と、カメラ装置のみとレーダ216のみの方式がある。フュージョン方式では、レーダ216によりレーダ視野内に存在する歩行者候補を検知し、この歩行者候補に対応する画像領域のみ画像処理している。このため、歩行者候補が存在しないような場合には、画像処理負荷が発生せず処理負荷が非常に小さくなる。反対に、歩行者候補が多い場合などは、歩行者候補が存在すると思われる画像領域が多数存在するために、画像処理負荷が高くなる。
【0078】
このように画像処理量がレーダの結果より推定可能なため、処理時間の見積もり(処理時間の予測)が正確に行える。歩行者候補の増減に応じて、処理時間の増減が非常に大きいため、処理時間の動的予測結果を利用したスケジューリングにより、処理時間増加による処理周期遅延の抑制などに効果がある。特に、処理時間が長く、その増減が激しいアプリの処理時間を正確に予測することができれば、処理時間の増減に応じたスケジューリングをコントロールできる。
【0079】
このため、動的処理時間の予測は全てのアプリに対して行わなくても良く、処理時間の長さがほぼ一定、もしくは処理時間が短い処理は、固定の処理時間を基にスケジューリングすることとし、歩行者検知のように処理時間の増減が激しい処理を対象とすると、動的予測した効果が高い。処理負荷が高く、処理時間が長くなるような場合には、優先順位の低い処理から処理停止、もしくは精度劣化、検知距離の短縮、処理レートの低下等により打ち切り処理の抑制を実施し、マルチアプリの規定処理周期を守るようにスケジューリングすることでリアルタイム性を維持し、より安全性を高める。反対に、処理時間が短い場合には、効率的に他利便機能の動作を可能とし、より利便性を高める効果がある。
【0080】
フュージョン方式において、上記のレーダ216の結果から画像処理領域を絞り込むような手法ではなく、画像認識結果と、レーダ216の認識結果をフュージョンするような手法では、画像処理負荷部分は、カメラ装置のみの方式と同じ処理時間予測方法となり、効果も同様といえる。
【0081】
また、カメラ装置のみの方式の場合、過去の認識結果をベースとして、自車速でその歩行者に近づいた際の画面上での大きさを予測し、その大きさに基づいて次処理周期における画像処理の負荷を推定し、処理時間を予測する。更に、新たに視野内に入る歩行者に割り当てるために、猶予時間を加える。
【0082】
フュージョン方式と比較して、処理時間予測精度は劣化し、猶予時間を常に加えたスケジューリングとなるため、処理時間ほぼゼロのようなスケジューリングは困難となり、上記フュージョン方式と比較し効果は小さくなるものの、上記と同じように、動的予測結果を利用したスケジューリングにより、処理時間増加に応じて、優先順位の低い処理から処理停止、精度劣化による打ち切り処理の抑制、処理周期遅延の抑制などに効果がある。また、処理時間が非常に短い場合には、効率的に他の利便機能の動作を可能とし、より利便性を高める効果がある。また、このような処理時間の予測はレーダ216による歩行者検知で行っても同様の効果が得られる。
【0083】
なお、車両検知アプリ150も歩行者検知アプリ140と同様に、フュージョン方式とカメラ装置のみの方式にわかれる。処理時間の予測や効果についてもほぼ同様のため、詳細は省く。
【0084】
次に、レーン認識アプリ130の場合における処理時間の予測方法について説明する。レーン認識アプリ130の処理時間は、処理領域の大きさに影響を受ける。処理領域内に存在するレーンマーク(路面上の白線WL)がどのような傾きでどのような位置に存在するかを探索するための直線抽出処理が、特に処理時間の大きなウェイトを占める。
【0085】
処理領域が多いほど、直線が存在する位置や傾きの可能性が増え、それに伴い処理時間が増加する。処理領域は、前回の認識結果を基にして次既定周期の処理領域を設定するため、次既定周期に設定する処理領域の大きさを情報として処理時間を予測する。なお、道路状況は急変することは少ないことから、過去の処理時間から次既定周期の処理時間を推定しても良い。もしくは、車両に搭載されたカーナビゲーションシステム(以下、単にナビという)の地図情報より、車線種別や道路環境に関する情報を取得し、これらの結果より処理時間を予測する手法でも良い。また、ナビの記憶装置を利用して、地図情報に照らし合わせて、以前に走った場合の処理時間を記憶装置に記録し、次回走行する場合には処理時間の予測に利用するような手法でも良い。
【0086】
レーン認識アプリ130によるレーンの認識結果は、車両制御に利用されるので、制御の遅れなどが重要な問題となる。したがって、処理時間を予測して、レーン認識アプリ130が規定処理時間内に収まるようにスケジューリングし、安全な車線逸脱防止制御を実施する。
【0087】
次に、オートライトアプリ160、標識検知アプリ170、路面標識検知アプリ180の場合における動的処理時間の予測方法についてそれぞれ説明する。オートライトアプリ160の場合、レーダ216の検知情報と組みあわせたフュージョン方式をとることで、車両候補が存在すると思われる処理領域に限定し、ライトを検知する処理時間を予測する。オートライトの画像処理では、処理時間が大きく変化することが少ないと考え、過去の処理時間より、次の周期における処理時間を予測しても良い。
【0088】
標識検知アプリ170及び路面標識検知アプリ180の場合は、ナビの地図情報から路面標識や標識の位置情報を得て、路面標識や標識が撮像されると推定されるタイミングには、処理時間が多くかかりそうだと推定を行っても良い。また、認識後は、次既定周期に再度認識する標識が画像上でどのような大きさに撮像されるかを車速や操舵情報より推定し、処理時間を更に正確に推定しても良い。また、上記の場合、自車両走行時における処理時間をナビの地図情報に合わせて記録された結果を基に処理時間の予測を行っても良い。
【0089】
標識検知アプリ170及び路面標識検知アプリ180の場合は、画像処理の処理時間が大きく変化することが少ないと考え、過去の処理時間より、次の周期における処理時間を予測してもよい。
【0090】
その他のアプリとして、例えば駐車枠検知アプリの場合は、一度処理すると次既定周期の処理時間と大きく処理時間が変化することは少ないことから、過去の処理時間を基に次既定周期の処理時間を予測するような手法でも良い。
【0091】
また、車室内の居眠り検知アプリの場合は、処理自体にモードを持たせ、居眠りしているのか怪しい場合にのみ、処理負荷が高くなるようにモード変更しても良く、このモード状態から処理時間の予測を行ってもよい。また、運転者の操舵やアクセル、ブレーキング操作に応じて、居眠り検知アプリにおける処理モードを変更するとともに、処理モードに応じた処理時間の予測を行っても良い。
【0092】
窓のくもり検知アプリの場合は、湿度に基づいて窓のくもり検知の処理時間を予測しても良く、また、雨滴検知などの検知結果に基づいて予測しても良い。更に、温度計による計測結果に基づいて、雪検知か雨検知か処理を判断するとともに処理時間を予測しても良い。
【0093】
<打ち切り処理>
次に、打ち切り処理の方法について以下に詳細に説明する。図13は、従来のスケジューリングの問題点を説明する図であり、図13(a)は、打ち切り処理により規定周期を保証する手法を示し、図13(b)は、スケジューリングされた各アプリが終了するまで周期を延長する手法を示すものである。そして、図14は、本実施の形態におけるスケジューリングの方法を説明する図であり、図14(a)は、優先順位に基づいて付加機能部のアプリを停止して規定周期を保証する手法を示し、図14(b)は、周期の延長を規定値まで許容する手法を示すものである。
【0094】
従来手法では、図9に示すように固定で割り当てられた図7の初期処理時間に基づいて、各機能のスケジューリングを行っていた。しかしながら、上記の初期処理時間よりもある機能の処理時間が伸びてしまった場合には、様々な問題があった。例えば、既定処理周期を保証するために、打ち切り処理を実施する対策もあるが、図13(a)に示す車両検知アプリ150のように、途中で処理が打ち切られたアプリはその結果が得られないほか、標識検知アプリ170のように、その後に処理予定であった例えば標識検知アプリ170などのアプリも実行もされずに、次の周期に入るような結果となる。
【0095】
また、図13(b)に示すように、全てのアプリの処理が終了するまで周期を延長するような従来手法の場合には、既定周期が守られず、リアルタイム性に問題が生じていた。
他の従来手法として、規定周期を守るために、優先順位順に機能をスケジューリングし、優先順位の低い処理を打ち切りする方法もあるが、現周期の処理時間の長さを考慮しない打ち切り処理であった。
【0096】
このため、例えば図13(a)に示す車両検知アプリ150の必須版アプリ1150のように、規定周期の終了間際に、処理時間の長いアプリが実行された場合に、結果、打ち切り処理が発生し、車両検知アプリ150の必須版アプリ1150、付加版アプリ2150、標識検知アプリ170のいずれの結果も得られないようなスケジューリングになっていた。
【0097】
このような従来手法では、予防安全のための車載アプリケーションに利用するには問題がある。したがって、リアルタイム性を確保しながらも、利便性を確保できるようなスケジューリングが望ましい。図13(a)に示すようなケースの場合は、そもそも安全性機能が実行されるべきであるが、歩行者検知アプリ140や車両検知アプリ150が想定していた固定処理時間分よりも実際の処理時間が長かったために、車両検知アプリ150の必須版アプリ1150の処理までもが打ち切りになるという問題がある。
【0098】
これに対して、本実施例では、図7のタスクテーブルと予測処理時間を利用してスケジューリングする。したがって、優先順位を考慮すれば歩行者検知アプリ140の必須版アプリ1140、車両検知アプリ150の必須版アプリ1150、レーン認識アプリ130の必須版アプリ1130及び付加版アプリ2130の次に、歩行者検知(付加)2140を実施したいが、すでに規定周期内に処理が終了しないことが動的処理時間の予測をしていれば前もって判定可能である。
【0099】
このような場合、図13(a)に示す車両検知アプリ150のように、アプリの処理が終了せず打ち切り処理が発生するようであれば、処理が規定周期内に完了する機能の中で、次に優先度の高い、車両検知(付加)2150をスケジューリングすべきである。
【0100】
ただし、図13、14では、優先順位の高さだけでなく、同じアプリケーションはできる限り連続して処理するようなスケジューリングとした。これは、同一アプリケーションをデータ依存関係の少ない処理に細かく分割しても、他アプリを実行することと比較すれば共有する情報が多く、情報の退避や復帰などまで考慮すると連続実行すると処理負荷の面を考慮すると効率が良いとの考えからである。例えば、歩行者検知の必須版と付加版などで共有する情報は多く、必須機能が終わった後の情報の退避、付加版を開始する際の情報の復帰などを考慮すると同一アプリは連続実行したほうが処理負荷、メモリ消費量からみても効率的なためである。ただし、打ち切り処理抑制を最重要視するようであれば、優先順位の順にアプリケーションを実施するのが良いと考える。最終的には、アプリ実行の負荷と比較しアプリ小分割の際に生じる負荷の大きさや、タスク打ち切り抑制の重要度によってスケジューリングを決める。
【0101】
図13の場合における車両の周囲環境シーンを図25(b)に示す。図25(b)は、予測処理時間の算出方法を説明する図であり、自車251の前方に複数人の歩行者253A〜Fと複数台の車両252A〜Eが存在している状況を示している。
【0102】
まず、動的処理時間予測部111において、各アプリの処理時間を予測する。図26に示すように、動的処理時間予測制御部112の予測情報選定部113では、走行環境情報部210とマルチアプリ実行部131と車両制御部250から入力として得られた情報を、走行環境情報114、マルチアプリ実行情報115、車両制御情報116として保存する。これらの保存された情報から、動的処理時間予測に利用する情報を各アプリ別に選定して各アプリの動的予測部(3130−3150、4130−4170)に情報を送信する。
【0103】
そして、レーン認識アプリ130の必須版アプリ1130における処理時間を予測する。ここでは、マルチアプリ実行情報115から前規定周期の処理結果より処理領域の大きさ、及び前回の認識結果を利用して、次規定周期におけるレーン認識アプリ130の必須版アプリ1130の処理時間を予測する。
【0104】
前規定周期の処理領域の大きさと認識結果より次回の処理領域の大きさを決定するため、これらの情報を利用する。また、連続して不認識が続いているなどのレーン認識状況の情報も利用し、連続不検知の場合には処理領域を拡大して認識処理を実行するために、処理時間が長くなると予測する。このように処理領域の大きさ及び過去の認識結果の履歴を利用し、レーン認識アプリ130の必須版アプリ1130の処理時間を予測する。予測処理時間を初期処理時間で割り算し100を乗算し、処理時間比率を図25(a)に示す。
【0105】
この比率が100を超えた場合には、初期設定のスケジューリングを守ることができないことを意味する。このシーンにおいてはレーン認識アプリ130の必須版アプリ1130の処理時間比率は90%と予測する。
【0106】
または、走行環境情報のカーナビからきれいな実線が続くような道路であるか、ボッツドッツのように認識が困難で不検知になりがちな道路であるか道路状況の情報を得て、きれいな実線であれば認識結果も安定してトラッキング可能なため処理時間が短く、ボッツドッツであれば不検知や安定して認識することが困難であることから処理時間が長いというように処理時間の予測をおこなっても良い。もしくは、車両制御情報の車速やヨー角から次周期における白線WLの位置を予測し、実線の場合には処理時間に変化無く、破線の場合には次周期における破線位置と空白部の位置を予測し、処理時間を予測するような方法でも良い。初期処理時間をベースに考えた場合の予測処理時間の長さのパーセンテージを図25(a)に示す。レーン認識アプリ130の必須版アプリ1130は90%と予測する。
【0107】
次に、レーン認識アプリ130の付加版アプリ2130における処理時間を予測する。ここでは、必須版アプリ1130と同様にマルチアプリ実行情報115から前周期のレーン認識アプリ130の付加版アプリ2130の処理領域の大きさと認識結果を利用し、次規定周期の処理領域の大きさを決定し、この処理領域の大きさや認識結果の履歴より処理時間の予測を行う。必須版同様に認識状況、車両走行情報のナビからの道路状況や道路曲率情報、車両制御情報116の車速やヨー角情報から処理時間を予測しても良い。図25(b)の場合におけるこのレーン認識アプリ130の付加版アプリ2130の処理時間比率を95%と予測する。
【0108】
次に、歩行者検知アプリ140の処理時間を予測する方法について説明する。図25(b)に示すように、車両制御対象となる停止距離範囲内、及び走行予測経路内には3人の歩行者253A〜Cが存在し、それよりも遠方に3人の歩行者253D、Fが存在する。停止距離範囲は、車両制御部250の車速センサ261の検出値を利用する。
【0109】
走行環境情報部210のレーダ261により車両制御が働く停止距離範囲内には3人の歩行者253A〜Cが歩行者候補として検知され、更に遠方では、3人の歩行者253D、Fと、電柱253Eが候補として検知される。
【0110】
レーダ261のセンサ情報から、歩行者候補253A〜Fの存在と、各候補253A〜Fの自車両251からの距離と方向、物体幅が検知できるため、画像上の歩行者候補253A〜Fの大きさと処理範囲が計算可能である。これにより画像上の歩行者候補253A〜Fを探索する処理領域が決定する。
【0111】
方向と物体幅、距離において画像上の処理領域を決定し、歩行者候補253A〜Fまでの距離に応じ処理領域内の画像を正規化する。この正規化されたサイズでパターンマッチングし、歩行者検知を行う。このため、画像正規化の処理負荷とパターンマッチングの処理負荷より処理時間を予測する。
【0112】
歩行者の距離から画像を正規化するため、大きく身長が異なる場合、パターンマッチングの検知率に影響を及ぼす。このため同じ歩行者候補に対して、複数のサイズでパターンマッチングするような手法でもよい。このような場合も、正規化の回数やパターンマッチングの回数によって処理時間を予測する方法で良い。このように歩行者検知の手法に応じて、画像正規化とパターンマッチングの処理負荷を考慮し、歩行者検知アプリ140の必須版アプリ1140の処理時間を予測する。
【0113】
付加版アプリ2140では、歩行者候補253D〜Fに対する処理時間を予測する。処理は必須版アプリ1140と同様であるが、停止距離範囲外である遠方では画像上に小さく写る歩行者候補を対象とするため画像正規化の負担が軽減される。パターンマッチングの処理負荷は大きく変化しない。これらの情報より、歩行者の多いこのシーンにおいては、必須版アプリ1140、付加版アプリ2140ともに処理負荷が高くなり、図25(a)の予測処理時間のグラフに示すように、必須版アプリ1140は処理時間比率210%、付加版アプリ2140は190%となり、初期処理時間と比較して予測処理時間が非常に長くなる。
【0114】
次に、車両検知アプリ150の処理時間を予測する方法について説明する。車両検知アプリ150は、制御対象となる車両候補を必須版アプリ1150によって検知し、それ以外の車両を付加版アプリ2150によって検知する処理を行う。
【0115】
走行環境部210のレーダ216より車両候補を検知し、相対速度と方向と車体幅を検知する。車両制御情報116より車両候補のなかから必須版対象の車両候補と、付加版対象の車両候補に分割する。図25(b)に示すシーンでは、車両候補252A、Bが、必須版アプリ1150の認識対象とされ、車両候補252C〜Eが、付加版アプリ2150の認識対象とされる。
【0116】
歩行者検知と同様に画像上に車両候補が映る処理領域を設定し、自車両からの距離に応じて処理領域内の画像を正規化する。決められた車両のパターンサイズにてパターンマッチングを行うため、この画像正規化とパターンマッチングの回数に応じて処理時間を予測する。図25(b)のシーンにおいては、車両検知アプリ150の必須版アプリ1150と付加版アプリ2150は、ともに処理時間が通常時よりも長くなり、必須版アプリ1150の処理時間比率及び付加版アプリ2150の処理時間比率は、共に150%と予測される。
【0117】
次に、標識検知アプリ170の処理時間を予測する方法について説明する。マルチアプリ実行情報115の前規定周期における処理時間より、次規定周期の予測する。歩行者検知アプリ140や車両検知アプリ150がこのような手法をとってもよい。
【0118】
予測のために車両制御部250の車速やヨー角情報より次規定周期における画像上の標識の大きさを推定し、処理時間の予測を行っても良い。トラッキングにより連続して検知できている対象にはこのような処理時間の予測が可能となり、新規に検知する標識は処理時間が予測できないために、上記過去の検知履歴から予測される処理時間にプラスして処理時間に余裕分を追加して予測処理時間とする。図25(b)のシーンにおいて標識検知アプリ170の処理時間比率は95%と予測される。
【0119】
そして、アプリごとに予測情報選定部113によって選択された情報から、処理時間を予測し、各アプリ予測情報119にデータを一時格納する。次に、このような各アプリの予測処理時間を利用することにより、アプリ実行前に、規定処理周期内に処理が完了しないこと、もしくは規定周期後にも処理が続いてしまうことが予想可能となる。
【0120】
そこで、この予測処理時間結果を利用して、図14(a)に示すように、優先順位の低い利便性機能である歩行者検知アプリ140の付加版アプリ2140と、標識検知アプリ170の実行を停止し、他の優先順位の高い処理を実行することで、規定周期内により優先度の高い処理を詰め込むことに成功している。動的に処理時間を予測することで、安全性機能に打ち切り処理が発生することを抑制している。
【0121】
そして、図13(b)に示す車両検知アプリ150のように、打ち切り処理により結果が全く得られなくなることを避けるため規定処理周期に処理が完了することをあきらめて、処理周期を伸ばすスケジューリング方法もある。しかしながら、規定処理周期を守れずリアルタイム性が問題となっていた。このような場合、先ほどのように優先順位と動的予測処理時間を利用して規定周期を守る前記の図14(a)のスケジューリング方法もあるが、図14(b)に示すように規定周期の延長を規定値まで認めたスケジューリングを行うことで、打ち切り処理を極力減らしながらも、処理周期の大きな遅延を認めないようなスケジューリングを行う手法でも良い。これにより、利便性も保ちながらも、安全性のためのリアルタイム性も保証することが可能となる。
【0122】
このようにスケジューリングを行う際に、処理時間の長い処理は無駄時間が発生しやすいことや、頻繁に打ち切り処理が発生しやすいなどスケジューリングする側からみれば扱いにくい処理である。
【0123】
次に、スケジューリングされたアプリのタスクを分割して実行する場合(タスク小分割)について以下に説明する。
【0124】
打ち切り処理やスケジューリングにより柔軟に対応するために、アプリのタスクを分割して実行する手法をとってもよい。図15、図17は、歩行者検出方法の一例を説明する図であり、図15は、自車と歩行者との位置関係を説明する図、図17は、規定周期の終了時に打ち切り処理を行った場合に、タスクを小分割したか否かによる効果の相異について説明する図である。
【0125】
歩行者検出は、レーダ261とカメラ装置を用いたフュージョン方式によって行われる。例えば、自車の車速Vや舵角等の情報と、レーダ261の検知結果に基づき、歩行者候補152A〜Eの位置を特定し、これらの各歩行者候補152A〜Eに対応する画像領域に対して歩行者認識の画像処理を実行する。
【0126】
図15に破線で示す停止距離Lは、空走距離と制動距離を加算することによって算出される(停止距離=空走距離+制動距離)。空走距離は、運転者が歩行者を認識してからブレーキ操作を行うまでの平均的反応時間に車速を乗算することによって算出され(空走距離=平均的反応時間×車速)、制動距離は、車速の2乗と摩擦係数に基づいて算出される(制動距離=車速の2乗/(254×摩擦係数)。摩擦係数は、平均的道路の摩擦係数であり、車両が雨滴センサや路面検知センサを備えている場合には、これらのセンサ値に基づいて動的に変化させてもよい。
【0127】
例えば図17(a)に示すように、歩行者検知アプリ140を一つのアプリとした場合には、その途中で打ち切り処理がなされると、歩行者検知の結果は得られない。そこで、車両制御に関係するような安全性の機能と、それよりも遠方を検知対象とし車両制御に直接関係せず注意を喚起するための利便性の機能に機能分割すべく、図17(b)に示すように必須版アプリ1140と付加版アプリ2140に分類する。
【0128】
このように、一つのアプリを必須版アプリ1140と付加版アプリ2140に分割することにより、例えば、付加版アプリ2140の途中で打ち切り処理が行われた場合に、その打ち切り処理の被害を付加版アプリ2140による利便性に留めて、必須版アプリ1140による安全性の機能に影響が及ぶのを抑制することができる。
【0129】
しかしながら、アプリを二つに分割しているとはいえ、アプリの最後の数パーセントの処理が完了しなかっただけでも、そのアプリの結果は全く得られなくなる。そこで、図17(c)に示すように、レーダ216で検知した歩行者候補152A〜Eの候補一つずつに処理を分割し、認識処理が終了した時点で、結果を出力できるようにする。
【0130】
このように認識対象の候補一つずつに処理を分割することにより、図17に示すように、打ち切り処理による認識結果の欠落を最小限に抑制するとともに、スケジューリングに柔軟性を持たせる。このように細かく処理が分割されれば、処理時間予測結果に基づいて、規定処理周期内にどの候補まで歩行者検知可能かを考慮しながら細かい調整が可能となる。図17に示す例では、必須版アプリ1140の認識結果に加えて、更に他の歩行者について付加版アプリ2140の認識結果についても得ることができる。
【0131】
図16は、車両検知方法の一例を説明する図であり、自車と自車周辺の他の車両との位置関係を説明する図である。
【0132】
車両検知は、歩行者検出と同様に、レーダ261とカメラ装置を用いたフュージョン方式によって行われ、例えば、自車161の車速や舵角等の情報と、レーダ261の検知結果に基づき、車両候補162A〜Dの位置を特定し、これらの各車両候補162A〜Dに対応する画像領域に対して車両認識の画像処理を実行する。
【0133】
ここでは、車両制御に関連する先行車両162B、C、車速を考慮した停止距離以内に存在し自車走行時に衝突危険性の高い隣接車線の車両Aの検知を安全性機能、それ以外を利便性の機能に登録する構成は残したまま、レーダ261で検知された車両候補162A〜Dのそれぞれに対して、画像認識のタスクを車両候補別に小分割する。
【0134】
隣接車線を含む先行車両162B、Cは、相対速度を考慮して停止距離以内に存在する車両162Bを、安全性の機能として車両検知アプリ150の必須版アプリ1150による認識対象とする。対向車両162A、Dは、レーダ261のみの検知結果において、このまま走行を続けると自車161との接触の可能性がある車両162Aを、安全性の機能として車両検知アプリ150の必須版アプリ1150による認識対象とする。そして、レーダ261で検知されかつ自車161の車両制御に直接関係しない車両162C、Dは、利便性の機能として車両検知アプリ150の付加版アプリ2150による認識対象とする。
【0135】
このように、認識対象の車両候補一つずつに処理を分割することにより、打ち切り処理による認識結果の欠落を抑制するとともに、スケジューリングに柔軟性を持たせる。このように細かく処理が分割されれば、処理時間予測結果に基づいて、規定処理周期内にどの候補まで車両検知可能かを考慮しながら細かい調整が可能となる。
【0136】
図18は、タスク小分割による並列処理の作用効果を説明する図である。歩行者、もしくは車両などの候補別にアプリのタスクを小分割すれば、データに依存関係の少ない処理に分割ができる。このため、並列処理が容易となり、マルチコアや、マルチCPUを利用したシステム構成では、同じアプリでも並列処理を考慮した柔軟なスケジューリングが可能となり、安全性機能の処理完了を助けるほか、規定周期を守ること、利便性機能の追加にも効果が期待される。
【0137】
また、画像処理のようにメモリを大量に消費するタスクでは、タスクの途中でCPUの割当を切り替えるなどの仕事移送や、割り込み処理発生によるタスクの一時退避などは、CPUの処理負荷になることが多い。したがって、タスクを小さくすることで、CPU間の仕事移送なしに、小分割されたタスクの合間にCPU割当を切り替えることができ、より柔軟なスケジューリングが可能となる。また、タスクを小さくしたことで、個々のタスクが消費するメモリも抑制することが可能となり、一時退避が発生した場合の処理負荷のリスクを低減することに成功している。
【0138】
例えば、図18(a)に示すように、歩行者検知アプリ140で歩行者検知機能が得られる場合(1つのアプリで一つの機能が得られる場合)に、他の機能との並列処理が可能となる。そして、図18(b)に示すように、歩行者検知アプリ140によって必須版アプリ1140と付加版アプリ2140という2つの機能が得られる場合(1つのアプリで2つの機能が得られる場合)には、これらのアプリを並列に処理することができる。また、図18(c)に示すように、必須版または付加版の属性を有するタスクに小分割する場合には、タスクごとに並列処理することができる。
【0139】
次に、規定周期を短縮する方法について説明する。動的処理時間の予測より、全てのタスクテーブルの機能を実行しても規定周期よりも予測処理時間が短くなる場合、もしくは、もしくは処理周期が短い場合が連続した場合には、図19に示すように規定周期を短縮することで、車両制御を高精度に安定的に行う。
【0140】
車速が高くなるほど、または、車線に車両が近づくにつれて、処理周期を早めることで、より高性能な制御を実現する。この場合、現周期に処理時間の余裕があるかどうかの判定を行うと共に、処理時間に余裕がない場合はタスクテーブルの優先順位や、解像度、検知距離などの結果より処理負荷軽減策を図る。処理時間に余裕があり、なおかつその状態が連続して安定しているような場合には、規定の処理時間をそのまま短縮することで、検知間隔を短くし、検知の信頼性向上や精度向上、検知速度の向上を図る。
【0141】
郊外、高速道路を走行し長期にわたって歩行者や車両が周囲に存在しないような場合には、処理時間に余裕のある状態が長期にわたって続く可能性が高い。このような状況では、処理時間を余らせておくよりも、処理周期を短くし、精度を高める方が安全性を高めることができる。もしくは、標識検知や路面標識検知などの利便性機能の詰め込みを行うことで利便性を高める。
【0142】
次に、消費電力調整モードについて説明する。予測した各機能の処理時間に応じて、規定処理周期内に処理が完了しないような場合には、消費電力を調整することでCPUの性能(クロック数、動作コア数、動作CPU数)を調整し、規定処理周期内に処理が完了するように調整する。
【0143】
規定処理周期内に処理が完了し、余剰時間があるような場合には低消費電力モードへ変更し、反対に処理負荷が高く、規定処理周期内に処理が完了しないような場合には、消費電力を上げるとともに、CPU性能を向上させることで規定処理周期内に処理が完了するように対応する。処理時間を予測することで、緊急時に処理が追いつかないような状況を避け、処理負荷が軽い場合にはできる限り消費電力を下げる。
【0144】
図20は、利便性を追加するスケジューリングの方法を説明する図である。動的処理時間の予測より、全てのタスクテーブルの機能を実行しても規定処理周期よりも予測処理時間が短くなる場合、或いは、もしくは処理周期が短い場合が連続した場合には、図20に示すように、規定周期内に収まるように、オートライトアプリ160や路面標識検知アプリ180等の利便性の機能を追加する。これにより、安全性を確保しながらも利便性を高めることができる。
【0145】
また、雨滴検知や、窓ガラスの曇り検知、ヘッドライトのON、OFFやライトの光軸調整を行うオートライトなどの利便性機能の場合、毎規定周期ごとに処理し、状態の変化を観察する必要性は低い。雨が降ってきた場合などには、ワイパーが自動で作動するまでに、数秒程度の遅れが、ユーザに不便さを感じさせる可能性は低い。
【0146】
このため、安全性機能の動的予測処理時間が比較的短く、規定周期内に処理が完結するような場合にのみ、上記、雨滴検知、窓ガラス曇り検知、オートライトなどを動作させるような優先順位のスケジューリングでも十分に利便性機能の有効性が認められる。
【0147】
ただし、晴れから雨の状態への過渡期や、曇り無しから有り、昼から夜への過渡期など、判定状態を変更するような場合には、誤検知を少なくする上でも判定を何度か繰り返した後に最終的な判定を実行することが望ましい。このように状態の移行時には、CPU空き時間があれば積極的に利用し検知ロジックを動作させることで、安全性の機能の劣化を招くことなく、利便性を高める。
【0148】
アプリの選択は、例えばユーザがナビの操作画面から実行することによって行うことができる。アプリ登録では、各機能の初期処理時間を基にスケジューリングし、安全性の必須機能と利便性の付加機能の登録を行い、規定処理周期内に処理が完了するようにアプリを選択可能な設計とする。登録した各機能の必須機能の合計処理時間が規定時間1を越えた時点で必須機能の登録の受付を終了し、必須機能と付加機能の処理時間合計が規定時間2を越えた時点でアプリの追加を終了する。
【0149】
しかし、この時点では、各機能は固定処理時間でスケジューリングをされていることから、実際の走行時に規定処理周期内に処理が完了するか、もしくはCPU空き時間が多いか判定は困難である。特に歩行者検知アプリ140や車両検知アプリ150が安全性機能として登録されている場合、レーダ261によって検知された歩行者候補、もしくは車両候補がない場合には、処理時間がほぼ0となり、CPU空き時間が非常に大きくなる。
【0150】
アプリ登録時のスケジューリングでは、当然、検知候補が存在する場合の処理時間をベースとしてスケジューリングすることから、CPU空き時間が非常に多くなることが予想される。特に、郊外などの車両や人の通りがすくない場所では、CPUが常に活用されていないこととなる。
【0151】
このような場合には、処理周期を上げることで、安全性機能の性能向上、もしくは利便性の機能を追加することでCPUを有効活用し、ユーザの利便性を向上する。また、場合によっては、アプリ登録時のスケジューリングでは処理負荷が高く、規定周期内に処理が完了しないことが頻発するような場合も想定される。このような場合には、スケジューリングを調整するうえで、優先順位の低い処理から登録の除去をユーザに通知もしくは、選択画面にて選択させることで、スケジューリングを調整する。
【0152】
また、アプリインストール時やアプリ新規追加時に、上記手法によるスケジューリング調整を行っても良い。メンテナンス性などを考慮しても、設計側が大量のタスクテーブルを準備しておくのは設計作業の負担が大きく、シーンやユーザの好みに合わせて自動的にタスクテーブルを最適に設計することで、安全性を考慮しながらもユーザの利便性や意思を尊重したシステム設計が可能となる。
【0153】
<コア割り当て変更 スケジューリング 2CPU>
マルチコアや、マルチCPUの利用形態には、特定のコアもしくはCPUに特定の機能とOSを割り当てるAMP(Asymmetric Multiprocessing)と、個々のコアもしくはCPUが対等の条件でメモリを共有するSMP(Symmetric Multi−processing)、そして、一つのOSがあるタスクを特定のコアもしくはCPUに割り当てて実行することで、AMPの持つ移植性とSMPの持つ柔軟性を併せ持つBMP(Bound Multiprocessing)がある。
【0154】
コアやCPUに対して特定の機能を割り当てることが可能なAMP、BMPでは、このような動的予測時間処理を利用したスケジューリングにより、更に安全性、及び利便性を高めることができる。SMPやAMPの場合において、機能を別コアもしくは別CPUに割り当てることができない構成の場合には、シングルコア、もしくはシングルCPUの場合と同様の効果と作用である。
【0155】
従来のスケジューリングでは、機能に固定の処理時間を基に、図21に示すように、各コア(CPU)に対して処理を割り当てている。図21では、上段をコア1(CPU1)とし、下段をコア2(CPU2)とし、処理を割り当てている。そして、図22(a)に示すように、車両検知アプリ150の必須版アプリ1150が規定周期をオーバーしても処理が完了しない場合、CPU1のその後の規定周期内にスケジューリングされていたアプリ(車両検知アプリ150の付加版アプリ2150や路面標識検出アプリ180)の処理は完了せず、規定周期を延長するか、打ち切り処理を行うしかなかった。
【0156】
図27(b)に示すようなシーンにおける処理時間の予測結果を図27(a)に示す。予測処理時間は、CPUの処理速度をも考慮して行うが、マルチコアの場合も基本的には、1CPU(1コア)の場合の予測処理と同様である。
【0157】
レーン認識アプリ130の必須版アプリ1130と付加版アプリ2130の処理時間予測には、マルチアプリ実行部131からの過去認識結果や処理領域の大きさ、走行環境情報114に基づいて処理時間の予測を行う。処理時間の予測結果は図27(a)に、初期処理時間と比較したパーセンテージで処理時間を表現している。
【0158】
歩行者検知なども1CPUの場合と同様に処理時間の予測を行う。図27(b)のシーンにおいては、歩行者候補としてレーダ261が捕らえる候補は、電柱273Aのみのため、この領域を切り出し、人かどうか画像処理にて判定を行うための画像正規化とパターンマッチングの計算量を見積もり、処理時間を予測する。
【0159】
車両検知の場合も同様にレーザ261で検知し、処理時間を見積もる(処理時間を予測する)。図27(b)のシーンでは、車両272A〜Iが多く、自車271付近に存在するために、処理負荷が非常に高く、車両検知アプリ150の必須版アプリ1150と付加版アプリ2150における処理時間比率は250%と200%になっている。
【0160】
オートライトアプリ160では、車外の明るさを検知し、ライトのON、OFFのための判定を行う。昼のために対向車や先行車のための処理は動かず、予測処理時間は短く初期処理時間と比較してその処理時間比率は30%となっている。更に標識検知アプリ170や、路面標識検知アプリ180は、アプリ実行情報151の過去の認識結果と、車両制御情報116より処理時間を予測し、標識検知アプリの処理時間比率は95%、路面標識検知アプリの処理時間比率は93%となる。
【0161】
動的に予測した処理時間を利用することができれば、例えば図22(a)に示すように、あらかじめ予測される処理時間から規定処理周期内に車両検知アプリ150の必須版アプリ1150がコア1(CPU1)で完了しないことが予測でき、それ以降にコア1でスケジューリングされている車両検知アプリ150の付加版アプリ2150や路面標識検知アプリ180も同様に処理できないことが予想できる。
【0162】
更に、コア2(CPU2)で処理時間に余剰の空き時間があることが予測できる。これにより、動的に処理時間を予測した結果を利用して、コア1(CPU1)とコア2(CPU2)に割り当てる機能を調整することができる。
【0163】
このように、動的処理時間の予測を利用して、処理負荷をより均等に割り当てることで、マルチコア(CPU)の性能を十分に活用できるスケジューリングが可能となり、既定周期内の処理完了や、利便性の機能の効率的動作に効果がある。
【0164】
例えば、図22(b)に示すように、レーン認識アプリ130の付加版アプリ2130をコア1(CPU1)からコア2(CPU2)に割り当て変更することで、リアルタイム性を保持しながら、できる限り利便性の機能の動作保証をすることができる。
【0165】
更に、各アプリをデータ依存関係の少ない、小さな処理に分割したことを利用し、並列処理することで、コア(CPU)間の処理の分担方法に選択肢を増やす。図22(b)には、データ依存関係があった場合におけるスケジューリングを示した。データ依存関係を気にするために車両検知の並列処理が実行できず優先順位が高いにも関わらず車両検知(付加版)が処理できないなど問題があった。
【0166】
例えば、図23に示すスケジューリングでは、優先度の高さを考慮して、レーン認識アプリ130、歩行者検知アプリ140、車両検知アプリ150における必須版アプリと付加版アプリの両機能を全てスケジューリングできている。
【0167】
このように並列処理ができることも考慮したスケジューリングにより、処理の順序や打ち切り処理の対応に柔軟にスケジューリングを組み替えることが可能となり、安全性を確保するスケジューリング方法をとりながらも、利便性を追求する付加機能を効率的に実施することができる。
【0168】
<別ハード構成>
なお、上述の実施の形態では、車載用マルチアプリ実行装置100が車載カメラ内に一体に設けられている構成の場合を例に説明したが、係る構成に限定されるものではない。例えば、ハード構成は、図24に示すようなカメラの撮像系のデバイスが、画像処理する本体とは別れていて映像だけが転送されるような構造でも良い。
【0169】
また、車載用マルチアプリ実行装置100は、カーナビゲーション本体のCPUを、一部利用して動作するような方法でも良く、また、予防安全のための環境認識系に共通の一つのCPU、車両制御を制御する車両ECUのCPUを利用しても良い。また、図24に示すように走行環境情報部201が、画像処理する装置本体の内部または外部に存在するものであってもよく、走行環境の情報が画像処理装置に送信されていれば良い。
【0170】
そして、処理時間の予測処理は、処理時間の変動が大きい処理に限定しても良い。また、処理時間が正確に予測できるアプリに限定されていても良い。処理時間の変動が大きい処理の場合、毎回の予測によってスケジューリングをより効果的に変更することができる。毎回の処理時間がほぼ同等、もしくは処理時間の予測が不正確であると、むしろ適切なスケジューリングが困難になる。このような場合、動的に予測していない固定処理時間によりスケジューリングされている機能と動的処理時間予測の機能が混同しても、その効果は十分に活かされる。
【0171】
レーダ261を利用したフュージョン方式の歩行者検知や車両検知では、レーダ261の結果を利用して処理領域を決めると、画像処理の計算量がかなり正確に予測することが可能となる。レーダ261の結果によっては、歩行者候補などが見つからなければ、動的な予測処理時間はほぼ0になりうる。このように処理時間が大幅に変化するような機能には、動的な処理時間の予測によるスケジューリング最適化の効果が大きい。反対に、処理時間がほぼ一定の機能の場合には、処理時間を予測する処理を追加するよりも常に固定処理周期でスケジューリングした方が、費用対効果に優れている場合もある。
【符号の説明】
【0172】
100・・・車載用マルチアプリ実行装置、101・・・カメラ撮像部、111・・・動的処理時間予測部、121・・・マルチアプリ制御部(スケジューラ)、125・・・マルチアプリ実行部、130・・・レーン認識アプリ、1130・・・必須版アプリ、2130・・・付加版アプリ、140・・・歩行者検知アプリ、1140・・・必須版アプリ、2140・・・付加版アプリ、150・・・車両検知アプリ、1150・・・必須版アプリ、2150・・・付加版アプリ、160・・・オートライトアプリ、170・・・標識検知アプリ、180・・・路面標識検知アプリ、1100・・・必須機能部、2100・・・付加機能部、201・・・自車両走行情報部、213・・・ウィンカー、214・・・アプリ操作、215・・・カーナビ、216・・・レーダ、250・・・車両制御部、260・・・車両ECU、261・・・車速センサ、262・・・操舵角センサ、263・・・ヨーレートセンサ、264・・・アクチュエータ、300・・・制御・警告判断部
【技術分野】
【0001】
本発明は、例えば車載カメラ等の車載装置において複数のアプリケーションを実行する車載用マルチアプリ実行装置に関する。
【背景技術】
【0002】
車両走行に利用する情報を処理する装置において情報を的確に処理することが車両走行の安全性向上にとって重要である。近年、車両走行の安全性を高めようとするニーズがあり、情報処理装置における情報の処理量が多くなる傾向にある。車両の安全走行に関する情報の処理を、常に全て実行することは情報処理装置の負荷が大きくなり、対応速度の関係などで問題が出てくる。このため、規定周期内に処理が完了しないと判断した場合、次周期のCPU空き時間を上限として現周期に処理が完了しなかったアプリケーションのプログラムにCPU時間を割り当てることで、規定周期を保証しながら処理の打ち切りを抑制する技術が提案されている(例えば特許文献1を参照)。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2009−86733号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、例えば車載カメラの画像認識を行うアプリケーションでは、現周期の処理が完了しなかった場合、次周期も負荷が高く空き時間が無い可能性が高い。このため、画像認識のアプリケーションでは、単に次周期のCPU空き時間を活用するだけでは、処理打ち切り抑制の効果は不十分であり、限られたCPU処理能力で、走行状況に合わせたマルチアプリケーションのスケジューリングが重要になると考える。
【0005】
本発明は、上記の点に鑑みてなされたものであり、その目的とするところは、限られた処理能力のなかでリアルタイム性を損なうことなく複数のアプリケーションの動作保証を図り、打ち切り処理の発生を抑制することで利便性を保ちつつも安全性を確保することができる車載用マルチアプリ実行装置を提供することにある。
【課題を解決するための手段】
【0006】
上記課題を解決する本発明の車載用マルチアプリ実行装置は、規定周期内に複数のアプリを実行する車載用マルチアプリ実行装置であって、各アプリの処理時間を動的に予測し、該予測した処理時間に基づいて各アプリのスケジューリングを行うことを特徴としている。
【発明の効果】
【0007】
本発明の車載用マルチアプリ実行装置によれば、各アプリの処理時間を動的に予測し、該予測した処理時間に基づいて各アプリのスケジューリングを行うので、限られた処理能力でリアルタイム性を損なうことなく複数のアプリケーションプログラムの動作保証を図ることができ、打ち切り処理の発生を抑制することによって利便性を保ちつつも安全性を確保することができる。
【図面の簡単な説明】
【0008】
【図1】本実施の形態における車載用マルチアプリ実行装置のブロック図。
【図2】車両制御部のブロック図。
【図3】走行環境情報部のブロック図。
【図4】マルチアプリ実行部のブロック図。
【図5】動的処理時間予測部のブロック図。
【図6】車両搭載のマルチアプリ実行装置の配置図。
【図7】一般道モードのタスクテーブルの一例を示す図。
【図8】高速道モードのタスクテーブルの一例を示す図。
【図9】従来のスケジューリングによる結果を示す図。
【図10】本実施の形態における車載用マルチアプリ実行方法を説明する処理フロー。
【図11】本実施の形態におけるスケジューリングの一例を説明する処理フロー。
【図12】本実施の形態におけるスケジューリングの他の一例を説明する処理フロー。
【図13】従来のスケジューリングの問題点を説明する図。
【図14】本実施の形態におけるスケジューリングの一例を説明する図。
【図15】本実施の形態における歩行者検出方法の一例を説明する図。
【図16】本実施の形態における車両検出方法の一例を説明する図。
【図17】本実施の形態における歩行者検出方法の他の一例を説明する図。
【図18】本実施の形態における機能小分割による並列処理の作用と効果を説明する図。
【図19】本実施の形態における処理周期を短縮するスケジューリングを説明する図。
【図20】本実施の形態における利便性を追加するスケジューリングを説明する図。
【図21】マルチコアにおけるスケジューリングの一例を説明する図。
【図22】マルチコアにおけるスケジューリングの一例を説明する図。
【図23】マルチコアにおけるスケジューリングの一例を説明する図。
【図24】車載用マルチアプリ実行装置の他の実施の形態を説明する図。
【図25】予測処理時間の算出方法を説明する図。
【図26】動的処理時間予測部のブロック図。
【図27】予測処理時間の算出方法を説明する図。
【図28】一般道モードのタスクテーブルの一例を示す図。
【図29】一般道モードのタスクテーブルの一例を示す図。
【図30】一般道モードのタスクテーブルの一例を示す図。
【発明を実施するための形態】
【0009】
<システム構成>
図1は、本実施例における車載用マルチアプリ実行装置の機能ブロック図である。
【0010】
車載用マルチアプリ実行装置100は、車載の安全性もしくは利便性を向上するための認識を行う複数のアプリケーション(以下、単にアプリという)を規定周期内にリアルタイムで実施するものであり、本実施例では、車載用のカメラ装置内に一体に構成されている。
【0011】
車載用マルチアプリ実行装置100は、図1の機能別構成のブロック図に示すように、カメラ撮像部101、動的処理時間予測部111、マルチアプリ制御部(スケジューラ)121、マルチアプリ実行部131を備えている。
【0012】
カメラ撮像部101は、自車周囲、もしくは車内を撮影し、動的処理時間予測部111は、規定周期ごとに各アプリの処理時間を予測する。リアルタイムに応答性を求められる車載用マルチアプリ実行装置100は、予め設定された時間内に複数のアプリを実行する。この予め設定された時間を規定周期とする。
【0013】
マルチアプリ制御部121は、動的処理時間予測部111によって動的に予測された予測処理時間を利用して、各アプリを安全性と利便性の観点から適切にスケジューリングする。スケジューリングでは、各アプリについて、実施の可否及び実施の順番が決定される。
【0014】
マルチアプリ実行部131は、マルチアプリ制御部121のスケジューリング結果に基づいてアプリを実行する。マルチアプリ実行部131によって出力される結果は、車両制御部250にCAN(Controller Area Network)経由で通信され、車両の安全性に関する、制御、警報、警告、表示などに利用される。
【0015】
車両制御部250は、自車両の走行状況を把握しているとともに、CAN経由で走行環境情報部210と通信し、自車走行環境に関する情報を得ている。これら車両制御部250の情報、走行環境情報部210の情報、マルチアプリ実行部131の情報より、動的処理時間予測部111は、次周期における各アプリの処理時間を予測する。
【0016】
図2に車両制御部250の構成を示す。車両制御部250は、図2に示すような、車速センサ261、操舵角センサ262、ヨーレートセンサ263、アクチュエータ264、ブレーキ265、アクセル266、変速ギヤ267からなり、車両の走行状態を制御する。車両制御部250は、車両ECU260を中心に車両の制御を行う。車両ECU260は、ブレーキ265や、アクチュエータ264、アクセル266、ギヤ267を制御するとともに、車速センサ261、操舵角センサ262、ヨーレートセンサ263から現在の状態の情報を通信にて管理する。車両制御部250は、マルチアプリ実行部131の結果に応じて、安全のための制御、警告、警報、表示を実施する判断も行う。
【0017】
走行環境情報部210は、図3に示すように、ウィンカー213、アプリ操作214、カーナビ215、レーダ216、路車間通信217、車々間通信218などから、車両走行には直接関係しない情報であって車両周囲の走行環境の状況を示す情報を得ている。車載用マルチアプリ実行装置100の動的処理時間予測部111は、走行環境情報部210の結果を利用して、動的処理時間の予測を行っている。なお、図6は、車載用マルチアプリ実行装置100を車両に搭載した配置例を模式的に示す図である。
【0018】
図4は、マルチアプリ実行部131の詳細な構造を示すブロック図である。マルチアプリ実行部131は、全ての画像処理のアプリが機能別に登録されており、必須機能部1100と付加機能部2100の2つに分類された構造をもつ。マルチアプリ実行部131の機能は、図4に示すように、事故予防に直接的効果のある必須機能部1100と、より快適な運転支援を主目的とする付加機能部2100に分類される。
【0019】
マルチアプリの処理負荷が高く規定周期内に処理が完了しないような場合にも、安全性確保のために動作保証したいアプリを必須機能部1100として登録することで安全性を確保する。例えば、想定していた以上に歩行者候補や車両候補等がカメラ撮像部101の視野内に入った場合などには各アプリの処理時間が大きく伸びる。このように既定周期内に処理が完了しないような場合、既定周期を守るために処理の打ち切りを行うか、又は、規定周期の延長を容認している。
【0020】
規定周期内に処理が完了せずに処理の打ち切りを実行すると安全性低下につながると考えて規定周期の延長を容認する安全性機能と、規定周期の延長よりも処理の打ち切りを実施して規定周期を厳守することがより安全性の確保に重要と考える付加機能とにアプリの種類を分類することで、安全性を保ちつつ、通常時の利便性を向上している。
【0021】
規定周期を守るために処理を打ち切った場合、次周期まで結果が得られない他、次周期においても再度同一アプリに対して処理の打ち切りが発生する可能性がある。リアルタイム性を確保すべく規定周期を守ることだけに固執しては、安全性の観点から矛盾が生じる。そもそも処理の打ち切りが発生しないようなスケジューリングが望ましいほか、処理負荷が高い場合に、安全性のアプリに割り当てることのできるCPUの空き時間が重要である。
【0022】
処理負荷が高い場合など常に動作保証する必要はないが、通常走行時にドライバにとって有用な情報を提供するアプリを付加機能部2100として登録することで利便性を追求する。利便性のための付加機能は、安全性のアプリの動作保証をするためのCPUの空き時間マージンとして利用できる他、通常時はその利便性を有効活用することができる。
【0023】
本実施例では、図4に示すように、レーン認識アプリ130、歩行者検知アプリ140、車両検知アプリ150について、必須機能部1100と付加機能部2100に分類して登録することで、安全性を重視した設計を可能にするとともに利便性の両立を行う。そして、オートライトアプリ160、標識検知アプリ170、路面標識検知アプリ180については、付加機能部2100のみに登録している。
【0024】
レーン認識アプリ130は、カメラ撮像部101によって撮影された画像から道路の白線WLを認識する画像処理機能を有する。レーン認識アプリ130は、予防安全に直接効果が期待される車線逸脱防止に必要な車線内における自車両の横位置、ヨー角を推定することが可能な必須版アプリ1130を必須機能部1100に分類する。そして、カーブより遠方の白線WLの状況を検知対象とし、カーブ進入前における減速やカーブ時における操舵支援など快適な走行に効果が期待される付加版アプリ2130を付加機能部2100として分割する。
【0025】
このようにレーン認識アプリ130のうち、安全性に直接関係のある車線逸脱防止のための認識機能を必須版アプリ1130として必須機能部110に分類し、利便性に関連するカーブ進入前減速のための認識機能を付加版アプリ2130として付加機能部2100に分類する。処理負荷の高いアプリケーションが想定した処理時間内に処理が完了しないような場合に、利便性に関連するアプリの処理を停止もしくは性能劣化させて実施することで、規定周期の保証を行うとともに、安全性に関わる処理の打ち切りを抑制し、より高い安全性を実現する。
【0026】
歩行者検知アプリ140も、車速に応じた制動距離を考慮し衝突回避可能な距離に対して動作保証する必須版アプリ1140と、より遠方での歩行者候補に対しても検知処理を行う付加版アプリ2140に分類される。安全性確保のための必須版アプリ1140では、歩行者がある程度近距離にいることを想定しているため、高解像度の画像を利用するよりも、ある程度の解像度の画像を利用し、検知結果の更新周期をより早めることを重視した設定とする。そして、歩行者検知アプリ140の付加版アプリ2140では、より遠方の歩行者を対象とするために、高解像度の画像を利用する。
【0027】
車両検知アプリ150も、先行車両との相対速度や距離、自車舵角を考慮し衝突を回避するために必要な車両候補に対して画像処理を行う必須版アプリ1150と、より早期な車両の検知や検知率の向上、車間距離制御などを目的により遠方の車両を検知対象とする付加版アプリ2150に分類される。解像度や処理周期に関する方針は、歩行者検知アプリ140と同様である。
【0028】
歩行者検知アプリ140や車両検知アプリ150は、衝突回避のための認識処理を必須版アプリ1140、1150に分類し、車両制御には直接利用しない遠方などの認識を付加版アプリ2140、2150に分類することで、機能別の処理周期制御や機能のON、OFFを実現する。このように各アプリを機能別に必須機能部1100と付加機能部2100に分類することで、処理負荷が高く規定周期内に処理が完了しそうに無い場合に、付加版アプリの機能はその処理を停止、もしくは精度劣化させることで処理負荷を軽減させ、規定周期内に処理が完了するようにすることができる。従って、リアルタイム性を保証し、より安全性を高めるとともに、通常時の利便性を確保することができる。
【0029】
オートライトアプリ160は、カメラ撮像部101で車外を撮像した画像の画像認識を行うことにより外界の明るさを検知し、ヘッドライトのON、OFFや方向を制御する。先行車の検知と併用することで、ハイビームとロービームの制御を行う。レーン認識アプリ130、もしくは車両制御部250の車速センサ261と舵角センサ262からの自車両予測進路、もしくはカーナビ215からの自車両予測進路と併用することでカーブ方向へヘッドライトの照射角度の制御を行う。更に路面標識検知180と併用することで、交差点における照射角度の制御などに利用する。オートライトアプリ160は、より快適な運転支援を目的としており、このアプリ全体を付加機能部2100に分類する。
【0030】
標識検知アプリ170は、制限速度などの道路標識の検知を行い、この情報をドライバに提供することで快適な運転支援を目的とするため、このアプリ全体を付加機能部2100に分類する。
【0031】
路面標識検知アプリ180は、路面上の制限速度表示などの検知や、横断歩道を検知することにより、ナビ位置情報の高精度化などのドライバへの運転支援の情報を検知する機能のため、このアプリ全体を付加機能部2100に分類する。
【0032】
図5に、動的処理時間予測部のブロック図を示す。動的処理時間予測部111では、動的処理時間予測制御部112にて各アプリ機能別に予測に利用する情報を、走行環境情報部210、マルチアプリ実行部131、車両制御部250の中から選択し、その選択した情報を各機能の動的予測部3130−3150、4130−4180に送信する。各機能の動的予測部3130−3150、4130−4180は、動的処理時間予測制御部112から得られた情報に基づいて、次フレームにおける処理時間を予測する。
【0033】
<タスクテーブル>
マルチアプリ制御部121は、タスクテーブルをベースにして基本のスケジューリングを行い、動的処理時間予測部111で予測した予測処理時間を利用してスケジューリングの内容を修正する。打ち切り処理の対応や、低負荷時における利便性機能の追加などは、予測処理時間を利用した上で修正される。
【0034】
図7は、一般道路の走行時に使用されるタスクテーブルを示し、図8は、高速道路の走行時に使用されるタスクテーブルを示す。タスクテーブルは、図7及び図8に示すように、各アプリを分類して縦軸に並べると共に、設定項目を横軸に並べており、各アプリを設定項目別に制御するようになっている。タスクテーブルにて設定する各項目の内容について以下に説明する。
【0035】
有効フラグとは、一般道路を走行する一般道モードや、高速道路を走行する高速モード等から選択されたモードにて、アプリを動作すべきか否か、換言すると、アプリの実行の可否を判定するためのフラグであり、ONで動作、OFFで停止を意味する。
【0036】
レーン認識アプリ130、歩行者検知アプリ140、車両検知アプリ150は、必須機能部1100と付加機能部2100からなるアプリケーションであり、必須機能部1100の有効フラグがOFFの場合、同一アプリの付加機能部2100の有効フラグは必ずOFFとするように設定されている。
【0037】
例えば、レーン認識アプリ130の必須版アプリ1130が有効フラグOFFで動作停止した状態において、レーン認識130の付加版アプリ2130のみが有効フラグONであり動作するということはない。必須機能部1100がONの場合には、付加機能部2100に属するアプリは、状況に応じて制御する。
【0038】
必須機能部1100のON、OFFは、現在高速道路を走行中なのか、一般道を走行中なのか等の車両制御部250の自車両走行情報に基づいてモード設定を行う際に、変更される。例えば、高速道路を走行中は、歩行者は高速道路にいないとの仮定より、歩行者検知機能を動かすよりも他機能にプロセッサ処理を割り当てた方が、ドライバにとって快適で安全な運転ができると考え、歩行者検知アプリ全体をOFFとし、他機能の処理の優先や、高速移動時における1サイクル分の処理時間を短くするためにアプリのON、OFFを制御する。また、この他、カーナビゲーションのモニタ画面からユーザが選択するような方法でON、OFFを変更しても良い。
【0039】
付加機能部2100のON、OFFは、車両制御部250からの自車両走行情報及びアプリからの認識情報に基づいて制御される。また、動的処理時間予測部111で動的に予測した各アプリの予測処理時間の長さが、既定周期内に終了しない場合には、既定周期内に処理が完了するように、優先順位の低い付加版からOFFにすることによって、既定周期を守るようにスケジューリングする。また、処理対象の画像の解像度を低下させて、認識精度を劣化させる簡易的な手法により、リアルタイム性を確保しかつ安全性も確保してもよい。
【0040】
優先順位とは、複数のアプリを実行する場合の優先順位を示し、数字が小さい方が優先度の高いアプリであることを示す。例えば、歩行者検知アプリ140で、ブレーキの制御が必要となるような歩行者候補を発見し、更に歩行者検知の処理時間が長くなったような場合、歩行者検知機能よりも優先順位が低い付加版の処理を、優先順位が低い順に停止する。このように優先順位にしたがって順番にアプリの停止などを試みることで、安全性と利便性をできる限り両立する。
【0041】
割当コア(CPU)とは、マルチコア、もしくはマルチCPUを利用する場合において、各機能別に担当するコア(CPU)の割当を指定する場合に利用する。コアの数が増えた場合などには、一つの機能に対して複数コア(CPU)の割当を行うような場合にも、このタスクテーブルの設定内容を利用する。処理時間の予測結果に応じて動的にCPUの割当を変える場合には、タスクテーブルの設定内容を書き換える。シングルコアもしくは、シングルCPUの場合、もしくはマルチコア、もしくはマルチCPUであっても機能別にCPUの担当を決めずに、対称的、均一的に処理を割り当てる並列処理方式SMPの場合には、割当コアを全て1とし、明示的に各コア(CPU)に対して機能を割り当てない。
【0042】
処理とは、複数のアプリの処理が完了する規定周期におけるアプリの処理回数を示す。本画像処理装置における規定周期とは、例えば図9に示すような、一連の処理1回分のループを示す。同一の機能でも、優先度が低くなるにつれて処理回数が小さくなるような設計とする。例えば図7に記載されているレーン認識アプリ130の必須版アプリ1130の処理[1/1]とは、1サイクルに1回、アプリが実行されることを意味する。また、付加機能部2100のオートライトアプリ160の処理[1/3]とは、3サイクル中に1回、アプリが実行されることを意味する。
【0043】
予測処理時間に基づき、既定周期内に全てのアプリの処理が完了しそうにないと判断した場合に、まず優先度が低く、処理回数が低くても問題の生じない、処理回数の低いアプリから削ることで、優先度の高いアプリの実施が確保され、リアルタイム性が確保されて安全性が確保される場合が多い。
【0044】
例えば、レーン認識130の曲率算出部分の機能などは、道路が急に曲率が変化することがないことを考慮すると、必ずしも高い処理周期である必要はない。高い処理周期であれば精度は良くなるが、他に優先する処理があるような場合には、[1/2]で処理しても問題がない。そこで優先する機能がある場合における調整項目として処理周期の変更などが利用される。
【0045】
又、歩行者検知アプリ140の付加版アプリ2140、車両検知アプリ150の付加版アプリ2150、標識検知アプリ170、路面標識検知アプリ180などの場合は、処理周期が低くなると、検知タイミングが多少遅くなり、検知距離内に入ってからの認識処理回数が少なくなって、検知率が多少低下することが考えられるが、この検知率の低下よりも重要なアプリがある場合に、処理周期の調整にて優先事項の処理周期が早く、非優先事項については処理周期が遅くなるように調整される。カーブ中の速度抑制などの制御中には、標識検知アプリ170や、路面標識の検知率が多少下がるよりも減速制御のためのカーブ認識を高い周期で行う場合には重要となる。
【0046】
解像度とは、画像認識に利用する入力画像のサイズを示す。カメラ撮像部101で撮像される画像の最大解像度を[1、1]と示す。[a、b]の表記方法は、aが画像横方向の解像度、bが画像縦方向の解像度を示す。例えば、最大解像度768×240の場合に、入力画像として256×240の画像入力とするレーン認識アプリ130の必須版アプリ1130の解像度は[1/3、1/2]と示し、横解像度が最大解像度の1/3、縦解像度が最大解像度の1/2であることを示す。
【0047】
予測処理時間に基づき、既定周期内に全てのアプリが完了しそうにないと判断された場合には、解像度を低下させて処理時間を削減する処理を行う。解像度の低下により認識対象が近傍までになる制限がつくほか、解像度低下に伴う処理負荷低減により処理時間の削減が可能であり、性能劣化はするが応答性の確保しながらリアルタイム性を確保し、より安全で快適な車両の構築が必須となる。
【0048】
レーン認識アプリ130や歩行者検知アプリ140において、検出結果の位置精度を重要視する場合や、より遠方を検知対象とする場合、高解像度の画像を利用することが望ましい。しかし、高解像度画像を利用することによる計算コストの増加が処理周期に影響を与える。したがって、検知位置精度、検知対象距離、処理周期などの条件に応じて解像度を調整する。
【0049】
例えば、車線逸脱回避を想定した場合には、車両に対するレーンの横位置やヨー角にある程度の認識精度は必要とするものの、遠方の曲率値や車線逸脱予測位置より遠方のレーン位置などはあまり重要でない。車線逸脱回避のために車両制御するような状況では、低解像度な画像を利用し処理コストを削減することで、車両制御に利用されるレーン横位置やヨー角の更新周期を早め、より高度な車両制御を実現する。
【0050】
検知距離とは、自車から各アプリが認識対象とする対象のうち最遠方のものまでの距離を示す。例えば、通常モードにおける歩行者検知アプリ140の必須版アプリ1140の検知距離が40メートル[m]であるとは、40メートル[m]より遠方にいる歩行者については検知対象外とすることを意味する。
【0051】
歩行者検知アプリ140でいえば近傍に衝突可能性の高い歩行者が認識され、車両制御が必要と予測されるような場合に、車両制御の対象範囲外の遠方を検知することは重要ではない。したがって、遠方のものを対象からはずすことで処理コストを削減し、歩行者位置を高フレームレートで更新し、より高度な衝突回避制御を可能とする。また検知距離も遠いほど処理時間がかかるため、動的処理時間の予測に基づいて、検知距離を変更することで、処理時間の調整を行い、リアルタイム性を確保する。
【0052】
初期処理時間とは、アプリのスケジューリングの際に利用する固定値の処理時間であり、動的処理時間の予測が失敗したときや、予測処理時間が利用できないような場合に利用する処理時間である。タスクテーブル生成時や、ユーザの選択によりどのアプリを動かすかを選択する際に、決められた規定周期内に処理が終了するかどうかなどの目安として利用し、これを基に、規定周期内に処理が完了するようなマルチアプリ構成となっているかチェックすることに利用できる。
【0053】
予測処理時間とは、毎規定周期ごと、もしくはイベント成立時などに各アプリ機能別に処理が完了するために必要な時間を予測した時間である。歩行者検知などでは、レーダ261の検知情報等を利用し、処理完了に必要な時間を予測する。この予測された処理時間を利用して、タスクのスケジューリングに利用する。
【0054】
<全体処理フロー説明>
次に、本実施の形態における車載用マルチアプリ実行装置の全体処理について、図10の処理フローを用いて説明する。
【0055】
ステップS0では、車両制御状態や、マルチアプリの実行状態等の情報がフィードバッグされる。これらの情報は、処理時間の予測に利用する情報の一部である。車両制御部250の情報は、タスクテーブルの変更や、処理時間の予測に利用する。マルチアプリの実行状態は、認識結果とともに、処理時間の予測に利用する。例えばレーン認識の場合には、次周期のレーン認識を行うための処理領域の大きさを情報としてフィードバックすることで処理時間を予測する。
【0056】
ステップS1では、走行環境情報を取得する処理がなされる。ここでは、図3に示すウィンカー213、アプリ操作214、カーナビ215、レーダ216、路車間通信217、車々間通信218より走行環境の情報を取得する。これらの情報は、動的処理時間の予測や、タスクテーブルの変更に利用される。
【0057】
ステップS2では、動的処理時間を予測する処理がなされる。ここでは、ステップS0で得られた車両走行状態やマルチアプリ実行結果や実行状態の情報と、ステップS1で得られた走行環境情報を利用して、タスクテーブルにおいて有効フラグがONとなっている各アプリの処理時間を予測する。
【0058】
ステップS3では、スケジューリングが行われる。スケジューリングは、ステップS0から得られる車両制御状態やマルチアプリの実行結果、実行状態の情報、ステップS1で得られた走行環境情報、ステップS2で予測した結果である予測処理時間、及びタスクテーブルに基づいて行われる。
【0059】
ステップS4では、タスクテーブルの修正処理が行われる。ここでは、ステップS3のスケジューリングの結果に基づいて、タスクテーブルの内容に変更の必要があるか否かが判断され、変更の必要があると判断された場合に、タスクテーブルの修正がなされる。
【0060】
ステップS5では、カメラ撮像部101で撮像した画像を取得する処理がなされる。ステップS6では、ステップS3で得られたスケジューリングの結果と、ステップS4で得られたタスクテーブルの結果に基づいて、マルチアプリを実行する処理が行われる。ステップS7では、ステップS6のアプリ実行結果に基づいて、車両制御が実施される。
【0061】
なお、ステップS3、S4については、同時に実施するような方法でも良い。例えば、有効フラグ、優先順位、処理、解像度、検知距離など大まかにタスクテーブルを決定した後に、スケジューリングしながらタスクテーブルの内容に変更を加えるような方法でも良い。
【0062】
または、ステップS2、S3、S4を同時に実施するような方法でも良い。例えば、タスクテーブルの優先順位順に処理時間を予測し、その予測結果に基づいてスケジューリングを行う。そして、アプリが既定周期内に入りきらなくなった状況で、再度タスクテーブルの有効フラグ、処理周期、解像度、検知距離の見直しを行った上で、スケジューリングの再考を行うような方法でも良い。
【0063】
<スケジューリング詳細処理フロー>
次に、図10のステップS3における処理の内容について図11、図12を用いて詳細に説明する。図11は、スケジューリングの方法の一例を詳細に説明する処理フローである。ここでは、車載用マルチアプリ実行装置100の演算手段がシングルコアもしくはシングルCPUである場合を例に説明する。
【0064】
ステップS2で動的処理時間の予測が行われると、ステップS3に移行し、ステップS3で、予測された処理時間とタスクテーブルに示された優先順位とに基づいてスケジューリングが行われる。より詳細には、ステップS31で、タスクテーブルにおいて有効とされた複数のアプリの処理時間をスケジューリングした場合に、既定周期内に処理が完了しないアプリが存在するか否かを調査する。
【0065】
そして、規定周期内に処理が未完となるアプリが存在する予測された場合は(ステップS31でYes)、情報の処理量を減らすべく、ステップS34に移行する。ステップS34では、タスクテーブルで有効と判断されたアプリの精度劣化による処理時間の短縮や、アプリの停止を検討する。そして、不足処理時間分のCPU負荷を削減するために、タスクテーブルの優先順位の低いアプリから、及び予測した処理時間の長さに基づいて、不足処理時間分のアプリ削減、もしくは不足処理時間分の精度劣化を実施する。
【0066】
そして、ステップS35では、ステップS34、S38にて決定されたスケジューリングに従い、スケジューリングテーブル(スケジュール)を決定する。そして、全ての利便性のアプリ(付加機能部2100の処理)を停止しても既定周期内に処理が完了しない場合に、初めて処理周期の延長を検討し、スケジュールの修正を行う。または、安全性のアプリ(必須機能部1100の処理)であっても、既定周期より大幅に処理時間が伸びることが予測されるような場合には、打ち切り処理を実行し、次の既定周期で実施してもよい。
【0067】
システムのリアルタイムな応答が重要となる車載の認識アプリでは、検知距離なども重要な要素であるが、検知周期も重要な要素となる。この認識結果が最大何msec前の結果であるということを前提とした車両制御や、処理周期何フレームで得られる実行結果だと想定して作られた車両制御の場合に、この規定周期を守ることが安全性確保にも重要であることがわかる。
【0068】
一方、規定周期内に各アプリの処理が全て完了すると予測された場合は(ステップS31でNO)、ステップS37に移行し、CPU空き時間が多いかどうかを判定する。そして、CPU空き時間が多いと判定された場合は(ステップS37でYes)、より高い利便性の実現を図るべく、ステップS38に移行し、空き時間中に処理が完了できる範囲内で利便性機能(付加版アプリ2130〜2150や、オートライトアプリ160等)の追加を検討する。そして、ステップS37において、連続してCPUに空き時間があると判断された場合には、ステップS38で処理周期自体を短縮することも検討する。これにより、より高い安全性や、認識精度を実現することができる。
【0069】
また、CPU空き時間が少ないと判定された場合は(ステップS37でNo)、既に最適なスケジューリングであると判定し、そのまま処理を実行すべく、ステップS5に移行する。
【0070】
図12は、図10のステップS3におけるスケジューリングの方法の他の一例を説明する処理フローである。ここでは、車載用マルチアプリ実行装置100の演算手段がマルチコアもしくはマルチCPUである場合を例に説明する。なお、図11と同様の内容を有するステップには同一の符号を付することでその詳細な説明を省略する。
【0071】
ステップS31において、規定周期内に処理が未完と予測された場合は(ステップS31でYes)、ステップS32に移行し、他のコアや他のCPU、或いは専用ハード等に、処理の空き時間が存在しないかを調査する。そして、空き時間が存在すると判断された場合には、各アプリのコア(CPU)割り当て変更できるか否か、もしくは、処理時間の長い機能は、並列処理の実施により既定周期内に全ての機能が完了するか否かを調査判定する。そして、安全性の機能と優先順位の高いアプリから処理が完了するように、コア割当変更や並列処理によるスケジューリングを行う。
【0072】
ステップS33では、CPU割り当ての変更、並列処理のみで既定周期内に各アプリの処理が完了するか否かを判断し、処理が未完となると判断された場合(Yes)には、情報の処理量を減らすべく、ステップS34に移行する。また、処理が完了すると判断された場合(No)には、ステップS37に移行する。ステップS35では、ステップS32、S34、S38にて決定されたスケジューリングに従い、スケジュールを決定する。
【0073】
そして、ステップS37において、CPU空き時間が少ないと判定された場合(No)には、既に最適なスケジューリングであると判定してそのまま実行する。また、有効フラグがOFFになっている停止機能を含めて再スタートさせるとどの程度の処理時間がかかるか予測したうえで、全処理時間を予測し、先に走行環境モード選択もしくはナビからのアプリ操作によって決められたタスクテーブルをベースに優先順位が高い順にスケジューリングしてもよい。
【0074】
最後の規定処理周期の終了時をまたいで実行する機能が存在する時点で、そのアプリの優先順位と動的処理時間予測結果から、スケジュールに修正を加える。これにより、既定処理周期内にそもそも完了しないことがわかっていながらただ処理を実行して打ち切り処理を発生させることをせず、打ち切り処理が発生しないアプリで且つ優先順位は低いが処理時間が短いアプリを追加するなど対策をとり、利便性の追加を図っても良い。
【0075】
なお、利用画像の違いなどから、連続実行させた方が都合の良いアプリなどが存在するため、優先順位の高さのみでスケジューリングが難しい場合もある。このような場合には、動的処理時間の予測結果を求めてスケジューリングした後に、再度、どのアプリを有効とするかを再判定し、スケジューリングを最初からやり直すような手法でも良い。
【0076】
<処理時間の予測方法>
次に、図10のステップS2における動的処理時間の予測方法について、アプリケーション別に詳細を記す。歩行者検知アプリ140、車両検知アプリ150、レーン認識アプリ130の順番で説明する。
【0077】
例えば、歩行者検知アプリ140の場合、レーダ216とカメラ装置を併用するフュージョン方式と、カメラ装置のみとレーダ216のみの方式がある。フュージョン方式では、レーダ216によりレーダ視野内に存在する歩行者候補を検知し、この歩行者候補に対応する画像領域のみ画像処理している。このため、歩行者候補が存在しないような場合には、画像処理負荷が発生せず処理負荷が非常に小さくなる。反対に、歩行者候補が多い場合などは、歩行者候補が存在すると思われる画像領域が多数存在するために、画像処理負荷が高くなる。
【0078】
このように画像処理量がレーダの結果より推定可能なため、処理時間の見積もり(処理時間の予測)が正確に行える。歩行者候補の増減に応じて、処理時間の増減が非常に大きいため、処理時間の動的予測結果を利用したスケジューリングにより、処理時間増加による処理周期遅延の抑制などに効果がある。特に、処理時間が長く、その増減が激しいアプリの処理時間を正確に予測することができれば、処理時間の増減に応じたスケジューリングをコントロールできる。
【0079】
このため、動的処理時間の予測は全てのアプリに対して行わなくても良く、処理時間の長さがほぼ一定、もしくは処理時間が短い処理は、固定の処理時間を基にスケジューリングすることとし、歩行者検知のように処理時間の増減が激しい処理を対象とすると、動的予測した効果が高い。処理負荷が高く、処理時間が長くなるような場合には、優先順位の低い処理から処理停止、もしくは精度劣化、検知距離の短縮、処理レートの低下等により打ち切り処理の抑制を実施し、マルチアプリの規定処理周期を守るようにスケジューリングすることでリアルタイム性を維持し、より安全性を高める。反対に、処理時間が短い場合には、効率的に他利便機能の動作を可能とし、より利便性を高める効果がある。
【0080】
フュージョン方式において、上記のレーダ216の結果から画像処理領域を絞り込むような手法ではなく、画像認識結果と、レーダ216の認識結果をフュージョンするような手法では、画像処理負荷部分は、カメラ装置のみの方式と同じ処理時間予測方法となり、効果も同様といえる。
【0081】
また、カメラ装置のみの方式の場合、過去の認識結果をベースとして、自車速でその歩行者に近づいた際の画面上での大きさを予測し、その大きさに基づいて次処理周期における画像処理の負荷を推定し、処理時間を予測する。更に、新たに視野内に入る歩行者に割り当てるために、猶予時間を加える。
【0082】
フュージョン方式と比較して、処理時間予測精度は劣化し、猶予時間を常に加えたスケジューリングとなるため、処理時間ほぼゼロのようなスケジューリングは困難となり、上記フュージョン方式と比較し効果は小さくなるものの、上記と同じように、動的予測結果を利用したスケジューリングにより、処理時間増加に応じて、優先順位の低い処理から処理停止、精度劣化による打ち切り処理の抑制、処理周期遅延の抑制などに効果がある。また、処理時間が非常に短い場合には、効率的に他の利便機能の動作を可能とし、より利便性を高める効果がある。また、このような処理時間の予測はレーダ216による歩行者検知で行っても同様の効果が得られる。
【0083】
なお、車両検知アプリ150も歩行者検知アプリ140と同様に、フュージョン方式とカメラ装置のみの方式にわかれる。処理時間の予測や効果についてもほぼ同様のため、詳細は省く。
【0084】
次に、レーン認識アプリ130の場合における処理時間の予測方法について説明する。レーン認識アプリ130の処理時間は、処理領域の大きさに影響を受ける。処理領域内に存在するレーンマーク(路面上の白線WL)がどのような傾きでどのような位置に存在するかを探索するための直線抽出処理が、特に処理時間の大きなウェイトを占める。
【0085】
処理領域が多いほど、直線が存在する位置や傾きの可能性が増え、それに伴い処理時間が増加する。処理領域は、前回の認識結果を基にして次既定周期の処理領域を設定するため、次既定周期に設定する処理領域の大きさを情報として処理時間を予測する。なお、道路状況は急変することは少ないことから、過去の処理時間から次既定周期の処理時間を推定しても良い。もしくは、車両に搭載されたカーナビゲーションシステム(以下、単にナビという)の地図情報より、車線種別や道路環境に関する情報を取得し、これらの結果より処理時間を予測する手法でも良い。また、ナビの記憶装置を利用して、地図情報に照らし合わせて、以前に走った場合の処理時間を記憶装置に記録し、次回走行する場合には処理時間の予測に利用するような手法でも良い。
【0086】
レーン認識アプリ130によるレーンの認識結果は、車両制御に利用されるので、制御の遅れなどが重要な問題となる。したがって、処理時間を予測して、レーン認識アプリ130が規定処理時間内に収まるようにスケジューリングし、安全な車線逸脱防止制御を実施する。
【0087】
次に、オートライトアプリ160、標識検知アプリ170、路面標識検知アプリ180の場合における動的処理時間の予測方法についてそれぞれ説明する。オートライトアプリ160の場合、レーダ216の検知情報と組みあわせたフュージョン方式をとることで、車両候補が存在すると思われる処理領域に限定し、ライトを検知する処理時間を予測する。オートライトの画像処理では、処理時間が大きく変化することが少ないと考え、過去の処理時間より、次の周期における処理時間を予測しても良い。
【0088】
標識検知アプリ170及び路面標識検知アプリ180の場合は、ナビの地図情報から路面標識や標識の位置情報を得て、路面標識や標識が撮像されると推定されるタイミングには、処理時間が多くかかりそうだと推定を行っても良い。また、認識後は、次既定周期に再度認識する標識が画像上でどのような大きさに撮像されるかを車速や操舵情報より推定し、処理時間を更に正確に推定しても良い。また、上記の場合、自車両走行時における処理時間をナビの地図情報に合わせて記録された結果を基に処理時間の予測を行っても良い。
【0089】
標識検知アプリ170及び路面標識検知アプリ180の場合は、画像処理の処理時間が大きく変化することが少ないと考え、過去の処理時間より、次の周期における処理時間を予測してもよい。
【0090】
その他のアプリとして、例えば駐車枠検知アプリの場合は、一度処理すると次既定周期の処理時間と大きく処理時間が変化することは少ないことから、過去の処理時間を基に次既定周期の処理時間を予測するような手法でも良い。
【0091】
また、車室内の居眠り検知アプリの場合は、処理自体にモードを持たせ、居眠りしているのか怪しい場合にのみ、処理負荷が高くなるようにモード変更しても良く、このモード状態から処理時間の予測を行ってもよい。また、運転者の操舵やアクセル、ブレーキング操作に応じて、居眠り検知アプリにおける処理モードを変更するとともに、処理モードに応じた処理時間の予測を行っても良い。
【0092】
窓のくもり検知アプリの場合は、湿度に基づいて窓のくもり検知の処理時間を予測しても良く、また、雨滴検知などの検知結果に基づいて予測しても良い。更に、温度計による計測結果に基づいて、雪検知か雨検知か処理を判断するとともに処理時間を予測しても良い。
【0093】
<打ち切り処理>
次に、打ち切り処理の方法について以下に詳細に説明する。図13は、従来のスケジューリングの問題点を説明する図であり、図13(a)は、打ち切り処理により規定周期を保証する手法を示し、図13(b)は、スケジューリングされた各アプリが終了するまで周期を延長する手法を示すものである。そして、図14は、本実施の形態におけるスケジューリングの方法を説明する図であり、図14(a)は、優先順位に基づいて付加機能部のアプリを停止して規定周期を保証する手法を示し、図14(b)は、周期の延長を規定値まで許容する手法を示すものである。
【0094】
従来手法では、図9に示すように固定で割り当てられた図7の初期処理時間に基づいて、各機能のスケジューリングを行っていた。しかしながら、上記の初期処理時間よりもある機能の処理時間が伸びてしまった場合には、様々な問題があった。例えば、既定処理周期を保証するために、打ち切り処理を実施する対策もあるが、図13(a)に示す車両検知アプリ150のように、途中で処理が打ち切られたアプリはその結果が得られないほか、標識検知アプリ170のように、その後に処理予定であった例えば標識検知アプリ170などのアプリも実行もされずに、次の周期に入るような結果となる。
【0095】
また、図13(b)に示すように、全てのアプリの処理が終了するまで周期を延長するような従来手法の場合には、既定周期が守られず、リアルタイム性に問題が生じていた。
他の従来手法として、規定周期を守るために、優先順位順に機能をスケジューリングし、優先順位の低い処理を打ち切りする方法もあるが、現周期の処理時間の長さを考慮しない打ち切り処理であった。
【0096】
このため、例えば図13(a)に示す車両検知アプリ150の必須版アプリ1150のように、規定周期の終了間際に、処理時間の長いアプリが実行された場合に、結果、打ち切り処理が発生し、車両検知アプリ150の必須版アプリ1150、付加版アプリ2150、標識検知アプリ170のいずれの結果も得られないようなスケジューリングになっていた。
【0097】
このような従来手法では、予防安全のための車載アプリケーションに利用するには問題がある。したがって、リアルタイム性を確保しながらも、利便性を確保できるようなスケジューリングが望ましい。図13(a)に示すようなケースの場合は、そもそも安全性機能が実行されるべきであるが、歩行者検知アプリ140や車両検知アプリ150が想定していた固定処理時間分よりも実際の処理時間が長かったために、車両検知アプリ150の必須版アプリ1150の処理までもが打ち切りになるという問題がある。
【0098】
これに対して、本実施例では、図7のタスクテーブルと予測処理時間を利用してスケジューリングする。したがって、優先順位を考慮すれば歩行者検知アプリ140の必須版アプリ1140、車両検知アプリ150の必須版アプリ1150、レーン認識アプリ130の必須版アプリ1130及び付加版アプリ2130の次に、歩行者検知(付加)2140を実施したいが、すでに規定周期内に処理が終了しないことが動的処理時間の予測をしていれば前もって判定可能である。
【0099】
このような場合、図13(a)に示す車両検知アプリ150のように、アプリの処理が終了せず打ち切り処理が発生するようであれば、処理が規定周期内に完了する機能の中で、次に優先度の高い、車両検知(付加)2150をスケジューリングすべきである。
【0100】
ただし、図13、14では、優先順位の高さだけでなく、同じアプリケーションはできる限り連続して処理するようなスケジューリングとした。これは、同一アプリケーションをデータ依存関係の少ない処理に細かく分割しても、他アプリを実行することと比較すれば共有する情報が多く、情報の退避や復帰などまで考慮すると連続実行すると処理負荷の面を考慮すると効率が良いとの考えからである。例えば、歩行者検知の必須版と付加版などで共有する情報は多く、必須機能が終わった後の情報の退避、付加版を開始する際の情報の復帰などを考慮すると同一アプリは連続実行したほうが処理負荷、メモリ消費量からみても効率的なためである。ただし、打ち切り処理抑制を最重要視するようであれば、優先順位の順にアプリケーションを実施するのが良いと考える。最終的には、アプリ実行の負荷と比較しアプリ小分割の際に生じる負荷の大きさや、タスク打ち切り抑制の重要度によってスケジューリングを決める。
【0101】
図13の場合における車両の周囲環境シーンを図25(b)に示す。図25(b)は、予測処理時間の算出方法を説明する図であり、自車251の前方に複数人の歩行者253A〜Fと複数台の車両252A〜Eが存在している状況を示している。
【0102】
まず、動的処理時間予測部111において、各アプリの処理時間を予測する。図26に示すように、動的処理時間予測制御部112の予測情報選定部113では、走行環境情報部210とマルチアプリ実行部131と車両制御部250から入力として得られた情報を、走行環境情報114、マルチアプリ実行情報115、車両制御情報116として保存する。これらの保存された情報から、動的処理時間予測に利用する情報を各アプリ別に選定して各アプリの動的予測部(3130−3150、4130−4170)に情報を送信する。
【0103】
そして、レーン認識アプリ130の必須版アプリ1130における処理時間を予測する。ここでは、マルチアプリ実行情報115から前規定周期の処理結果より処理領域の大きさ、及び前回の認識結果を利用して、次規定周期におけるレーン認識アプリ130の必須版アプリ1130の処理時間を予測する。
【0104】
前規定周期の処理領域の大きさと認識結果より次回の処理領域の大きさを決定するため、これらの情報を利用する。また、連続して不認識が続いているなどのレーン認識状況の情報も利用し、連続不検知の場合には処理領域を拡大して認識処理を実行するために、処理時間が長くなると予測する。このように処理領域の大きさ及び過去の認識結果の履歴を利用し、レーン認識アプリ130の必須版アプリ1130の処理時間を予測する。予測処理時間を初期処理時間で割り算し100を乗算し、処理時間比率を図25(a)に示す。
【0105】
この比率が100を超えた場合には、初期設定のスケジューリングを守ることができないことを意味する。このシーンにおいてはレーン認識アプリ130の必須版アプリ1130の処理時間比率は90%と予測する。
【0106】
または、走行環境情報のカーナビからきれいな実線が続くような道路であるか、ボッツドッツのように認識が困難で不検知になりがちな道路であるか道路状況の情報を得て、きれいな実線であれば認識結果も安定してトラッキング可能なため処理時間が短く、ボッツドッツであれば不検知や安定して認識することが困難であることから処理時間が長いというように処理時間の予測をおこなっても良い。もしくは、車両制御情報の車速やヨー角から次周期における白線WLの位置を予測し、実線の場合には処理時間に変化無く、破線の場合には次周期における破線位置と空白部の位置を予測し、処理時間を予測するような方法でも良い。初期処理時間をベースに考えた場合の予測処理時間の長さのパーセンテージを図25(a)に示す。レーン認識アプリ130の必須版アプリ1130は90%と予測する。
【0107】
次に、レーン認識アプリ130の付加版アプリ2130における処理時間を予測する。ここでは、必須版アプリ1130と同様にマルチアプリ実行情報115から前周期のレーン認識アプリ130の付加版アプリ2130の処理領域の大きさと認識結果を利用し、次規定周期の処理領域の大きさを決定し、この処理領域の大きさや認識結果の履歴より処理時間の予測を行う。必須版同様に認識状況、車両走行情報のナビからの道路状況や道路曲率情報、車両制御情報116の車速やヨー角情報から処理時間を予測しても良い。図25(b)の場合におけるこのレーン認識アプリ130の付加版アプリ2130の処理時間比率を95%と予測する。
【0108】
次に、歩行者検知アプリ140の処理時間を予測する方法について説明する。図25(b)に示すように、車両制御対象となる停止距離範囲内、及び走行予測経路内には3人の歩行者253A〜Cが存在し、それよりも遠方に3人の歩行者253D、Fが存在する。停止距離範囲は、車両制御部250の車速センサ261の検出値を利用する。
【0109】
走行環境情報部210のレーダ261により車両制御が働く停止距離範囲内には3人の歩行者253A〜Cが歩行者候補として検知され、更に遠方では、3人の歩行者253D、Fと、電柱253Eが候補として検知される。
【0110】
レーダ261のセンサ情報から、歩行者候補253A〜Fの存在と、各候補253A〜Fの自車両251からの距離と方向、物体幅が検知できるため、画像上の歩行者候補253A〜Fの大きさと処理範囲が計算可能である。これにより画像上の歩行者候補253A〜Fを探索する処理領域が決定する。
【0111】
方向と物体幅、距離において画像上の処理領域を決定し、歩行者候補253A〜Fまでの距離に応じ処理領域内の画像を正規化する。この正規化されたサイズでパターンマッチングし、歩行者検知を行う。このため、画像正規化の処理負荷とパターンマッチングの処理負荷より処理時間を予測する。
【0112】
歩行者の距離から画像を正規化するため、大きく身長が異なる場合、パターンマッチングの検知率に影響を及ぼす。このため同じ歩行者候補に対して、複数のサイズでパターンマッチングするような手法でもよい。このような場合も、正規化の回数やパターンマッチングの回数によって処理時間を予測する方法で良い。このように歩行者検知の手法に応じて、画像正規化とパターンマッチングの処理負荷を考慮し、歩行者検知アプリ140の必須版アプリ1140の処理時間を予測する。
【0113】
付加版アプリ2140では、歩行者候補253D〜Fに対する処理時間を予測する。処理は必須版アプリ1140と同様であるが、停止距離範囲外である遠方では画像上に小さく写る歩行者候補を対象とするため画像正規化の負担が軽減される。パターンマッチングの処理負荷は大きく変化しない。これらの情報より、歩行者の多いこのシーンにおいては、必須版アプリ1140、付加版アプリ2140ともに処理負荷が高くなり、図25(a)の予測処理時間のグラフに示すように、必須版アプリ1140は処理時間比率210%、付加版アプリ2140は190%となり、初期処理時間と比較して予測処理時間が非常に長くなる。
【0114】
次に、車両検知アプリ150の処理時間を予測する方法について説明する。車両検知アプリ150は、制御対象となる車両候補を必須版アプリ1150によって検知し、それ以外の車両を付加版アプリ2150によって検知する処理を行う。
【0115】
走行環境部210のレーダ216より車両候補を検知し、相対速度と方向と車体幅を検知する。車両制御情報116より車両候補のなかから必須版対象の車両候補と、付加版対象の車両候補に分割する。図25(b)に示すシーンでは、車両候補252A、Bが、必須版アプリ1150の認識対象とされ、車両候補252C〜Eが、付加版アプリ2150の認識対象とされる。
【0116】
歩行者検知と同様に画像上に車両候補が映る処理領域を設定し、自車両からの距離に応じて処理領域内の画像を正規化する。決められた車両のパターンサイズにてパターンマッチングを行うため、この画像正規化とパターンマッチングの回数に応じて処理時間を予測する。図25(b)のシーンにおいては、車両検知アプリ150の必須版アプリ1150と付加版アプリ2150は、ともに処理時間が通常時よりも長くなり、必須版アプリ1150の処理時間比率及び付加版アプリ2150の処理時間比率は、共に150%と予測される。
【0117】
次に、標識検知アプリ170の処理時間を予測する方法について説明する。マルチアプリ実行情報115の前規定周期における処理時間より、次規定周期の予測する。歩行者検知アプリ140や車両検知アプリ150がこのような手法をとってもよい。
【0118】
予測のために車両制御部250の車速やヨー角情報より次規定周期における画像上の標識の大きさを推定し、処理時間の予測を行っても良い。トラッキングにより連続して検知できている対象にはこのような処理時間の予測が可能となり、新規に検知する標識は処理時間が予測できないために、上記過去の検知履歴から予測される処理時間にプラスして処理時間に余裕分を追加して予測処理時間とする。図25(b)のシーンにおいて標識検知アプリ170の処理時間比率は95%と予測される。
【0119】
そして、アプリごとに予測情報選定部113によって選択された情報から、処理時間を予測し、各アプリ予測情報119にデータを一時格納する。次に、このような各アプリの予測処理時間を利用することにより、アプリ実行前に、規定処理周期内に処理が完了しないこと、もしくは規定周期後にも処理が続いてしまうことが予想可能となる。
【0120】
そこで、この予測処理時間結果を利用して、図14(a)に示すように、優先順位の低い利便性機能である歩行者検知アプリ140の付加版アプリ2140と、標識検知アプリ170の実行を停止し、他の優先順位の高い処理を実行することで、規定周期内により優先度の高い処理を詰め込むことに成功している。動的に処理時間を予測することで、安全性機能に打ち切り処理が発生することを抑制している。
【0121】
そして、図13(b)に示す車両検知アプリ150のように、打ち切り処理により結果が全く得られなくなることを避けるため規定処理周期に処理が完了することをあきらめて、処理周期を伸ばすスケジューリング方法もある。しかしながら、規定処理周期を守れずリアルタイム性が問題となっていた。このような場合、先ほどのように優先順位と動的予測処理時間を利用して規定周期を守る前記の図14(a)のスケジューリング方法もあるが、図14(b)に示すように規定周期の延長を規定値まで認めたスケジューリングを行うことで、打ち切り処理を極力減らしながらも、処理周期の大きな遅延を認めないようなスケジューリングを行う手法でも良い。これにより、利便性も保ちながらも、安全性のためのリアルタイム性も保証することが可能となる。
【0122】
このようにスケジューリングを行う際に、処理時間の長い処理は無駄時間が発生しやすいことや、頻繁に打ち切り処理が発生しやすいなどスケジューリングする側からみれば扱いにくい処理である。
【0123】
次に、スケジューリングされたアプリのタスクを分割して実行する場合(タスク小分割)について以下に説明する。
【0124】
打ち切り処理やスケジューリングにより柔軟に対応するために、アプリのタスクを分割して実行する手法をとってもよい。図15、図17は、歩行者検出方法の一例を説明する図であり、図15は、自車と歩行者との位置関係を説明する図、図17は、規定周期の終了時に打ち切り処理を行った場合に、タスクを小分割したか否かによる効果の相異について説明する図である。
【0125】
歩行者検出は、レーダ261とカメラ装置を用いたフュージョン方式によって行われる。例えば、自車の車速Vや舵角等の情報と、レーダ261の検知結果に基づき、歩行者候補152A〜Eの位置を特定し、これらの各歩行者候補152A〜Eに対応する画像領域に対して歩行者認識の画像処理を実行する。
【0126】
図15に破線で示す停止距離Lは、空走距離と制動距離を加算することによって算出される(停止距離=空走距離+制動距離)。空走距離は、運転者が歩行者を認識してからブレーキ操作を行うまでの平均的反応時間に車速を乗算することによって算出され(空走距離=平均的反応時間×車速)、制動距離は、車速の2乗と摩擦係数に基づいて算出される(制動距離=車速の2乗/(254×摩擦係数)。摩擦係数は、平均的道路の摩擦係数であり、車両が雨滴センサや路面検知センサを備えている場合には、これらのセンサ値に基づいて動的に変化させてもよい。
【0127】
例えば図17(a)に示すように、歩行者検知アプリ140を一つのアプリとした場合には、その途中で打ち切り処理がなされると、歩行者検知の結果は得られない。そこで、車両制御に関係するような安全性の機能と、それよりも遠方を検知対象とし車両制御に直接関係せず注意を喚起するための利便性の機能に機能分割すべく、図17(b)に示すように必須版アプリ1140と付加版アプリ2140に分類する。
【0128】
このように、一つのアプリを必須版アプリ1140と付加版アプリ2140に分割することにより、例えば、付加版アプリ2140の途中で打ち切り処理が行われた場合に、その打ち切り処理の被害を付加版アプリ2140による利便性に留めて、必須版アプリ1140による安全性の機能に影響が及ぶのを抑制することができる。
【0129】
しかしながら、アプリを二つに分割しているとはいえ、アプリの最後の数パーセントの処理が完了しなかっただけでも、そのアプリの結果は全く得られなくなる。そこで、図17(c)に示すように、レーダ216で検知した歩行者候補152A〜Eの候補一つずつに処理を分割し、認識処理が終了した時点で、結果を出力できるようにする。
【0130】
このように認識対象の候補一つずつに処理を分割することにより、図17に示すように、打ち切り処理による認識結果の欠落を最小限に抑制するとともに、スケジューリングに柔軟性を持たせる。このように細かく処理が分割されれば、処理時間予測結果に基づいて、規定処理周期内にどの候補まで歩行者検知可能かを考慮しながら細かい調整が可能となる。図17に示す例では、必須版アプリ1140の認識結果に加えて、更に他の歩行者について付加版アプリ2140の認識結果についても得ることができる。
【0131】
図16は、車両検知方法の一例を説明する図であり、自車と自車周辺の他の車両との位置関係を説明する図である。
【0132】
車両検知は、歩行者検出と同様に、レーダ261とカメラ装置を用いたフュージョン方式によって行われ、例えば、自車161の車速や舵角等の情報と、レーダ261の検知結果に基づき、車両候補162A〜Dの位置を特定し、これらの各車両候補162A〜Dに対応する画像領域に対して車両認識の画像処理を実行する。
【0133】
ここでは、車両制御に関連する先行車両162B、C、車速を考慮した停止距離以内に存在し自車走行時に衝突危険性の高い隣接車線の車両Aの検知を安全性機能、それ以外を利便性の機能に登録する構成は残したまま、レーダ261で検知された車両候補162A〜Dのそれぞれに対して、画像認識のタスクを車両候補別に小分割する。
【0134】
隣接車線を含む先行車両162B、Cは、相対速度を考慮して停止距離以内に存在する車両162Bを、安全性の機能として車両検知アプリ150の必須版アプリ1150による認識対象とする。対向車両162A、Dは、レーダ261のみの検知結果において、このまま走行を続けると自車161との接触の可能性がある車両162Aを、安全性の機能として車両検知アプリ150の必須版アプリ1150による認識対象とする。そして、レーダ261で検知されかつ自車161の車両制御に直接関係しない車両162C、Dは、利便性の機能として車両検知アプリ150の付加版アプリ2150による認識対象とする。
【0135】
このように、認識対象の車両候補一つずつに処理を分割することにより、打ち切り処理による認識結果の欠落を抑制するとともに、スケジューリングに柔軟性を持たせる。このように細かく処理が分割されれば、処理時間予測結果に基づいて、規定処理周期内にどの候補まで車両検知可能かを考慮しながら細かい調整が可能となる。
【0136】
図18は、タスク小分割による並列処理の作用効果を説明する図である。歩行者、もしくは車両などの候補別にアプリのタスクを小分割すれば、データに依存関係の少ない処理に分割ができる。このため、並列処理が容易となり、マルチコアや、マルチCPUを利用したシステム構成では、同じアプリでも並列処理を考慮した柔軟なスケジューリングが可能となり、安全性機能の処理完了を助けるほか、規定周期を守ること、利便性機能の追加にも効果が期待される。
【0137】
また、画像処理のようにメモリを大量に消費するタスクでは、タスクの途中でCPUの割当を切り替えるなどの仕事移送や、割り込み処理発生によるタスクの一時退避などは、CPUの処理負荷になることが多い。したがって、タスクを小さくすることで、CPU間の仕事移送なしに、小分割されたタスクの合間にCPU割当を切り替えることができ、より柔軟なスケジューリングが可能となる。また、タスクを小さくしたことで、個々のタスクが消費するメモリも抑制することが可能となり、一時退避が発生した場合の処理負荷のリスクを低減することに成功している。
【0138】
例えば、図18(a)に示すように、歩行者検知アプリ140で歩行者検知機能が得られる場合(1つのアプリで一つの機能が得られる場合)に、他の機能との並列処理が可能となる。そして、図18(b)に示すように、歩行者検知アプリ140によって必須版アプリ1140と付加版アプリ2140という2つの機能が得られる場合(1つのアプリで2つの機能が得られる場合)には、これらのアプリを並列に処理することができる。また、図18(c)に示すように、必須版または付加版の属性を有するタスクに小分割する場合には、タスクごとに並列処理することができる。
【0139】
次に、規定周期を短縮する方法について説明する。動的処理時間の予測より、全てのタスクテーブルの機能を実行しても規定周期よりも予測処理時間が短くなる場合、もしくは、もしくは処理周期が短い場合が連続した場合には、図19に示すように規定周期を短縮することで、車両制御を高精度に安定的に行う。
【0140】
車速が高くなるほど、または、車線に車両が近づくにつれて、処理周期を早めることで、より高性能な制御を実現する。この場合、現周期に処理時間の余裕があるかどうかの判定を行うと共に、処理時間に余裕がない場合はタスクテーブルの優先順位や、解像度、検知距離などの結果より処理負荷軽減策を図る。処理時間に余裕があり、なおかつその状態が連続して安定しているような場合には、規定の処理時間をそのまま短縮することで、検知間隔を短くし、検知の信頼性向上や精度向上、検知速度の向上を図る。
【0141】
郊外、高速道路を走行し長期にわたって歩行者や車両が周囲に存在しないような場合には、処理時間に余裕のある状態が長期にわたって続く可能性が高い。このような状況では、処理時間を余らせておくよりも、処理周期を短くし、精度を高める方が安全性を高めることができる。もしくは、標識検知や路面標識検知などの利便性機能の詰め込みを行うことで利便性を高める。
【0142】
次に、消費電力調整モードについて説明する。予測した各機能の処理時間に応じて、規定処理周期内に処理が完了しないような場合には、消費電力を調整することでCPUの性能(クロック数、動作コア数、動作CPU数)を調整し、規定処理周期内に処理が完了するように調整する。
【0143】
規定処理周期内に処理が完了し、余剰時間があるような場合には低消費電力モードへ変更し、反対に処理負荷が高く、規定処理周期内に処理が完了しないような場合には、消費電力を上げるとともに、CPU性能を向上させることで規定処理周期内に処理が完了するように対応する。処理時間を予測することで、緊急時に処理が追いつかないような状況を避け、処理負荷が軽い場合にはできる限り消費電力を下げる。
【0144】
図20は、利便性を追加するスケジューリングの方法を説明する図である。動的処理時間の予測より、全てのタスクテーブルの機能を実行しても規定処理周期よりも予測処理時間が短くなる場合、或いは、もしくは処理周期が短い場合が連続した場合には、図20に示すように、規定周期内に収まるように、オートライトアプリ160や路面標識検知アプリ180等の利便性の機能を追加する。これにより、安全性を確保しながらも利便性を高めることができる。
【0145】
また、雨滴検知や、窓ガラスの曇り検知、ヘッドライトのON、OFFやライトの光軸調整を行うオートライトなどの利便性機能の場合、毎規定周期ごとに処理し、状態の変化を観察する必要性は低い。雨が降ってきた場合などには、ワイパーが自動で作動するまでに、数秒程度の遅れが、ユーザに不便さを感じさせる可能性は低い。
【0146】
このため、安全性機能の動的予測処理時間が比較的短く、規定周期内に処理が完結するような場合にのみ、上記、雨滴検知、窓ガラス曇り検知、オートライトなどを動作させるような優先順位のスケジューリングでも十分に利便性機能の有効性が認められる。
【0147】
ただし、晴れから雨の状態への過渡期や、曇り無しから有り、昼から夜への過渡期など、判定状態を変更するような場合には、誤検知を少なくする上でも判定を何度か繰り返した後に最終的な判定を実行することが望ましい。このように状態の移行時には、CPU空き時間があれば積極的に利用し検知ロジックを動作させることで、安全性の機能の劣化を招くことなく、利便性を高める。
【0148】
アプリの選択は、例えばユーザがナビの操作画面から実行することによって行うことができる。アプリ登録では、各機能の初期処理時間を基にスケジューリングし、安全性の必須機能と利便性の付加機能の登録を行い、規定処理周期内に処理が完了するようにアプリを選択可能な設計とする。登録した各機能の必須機能の合計処理時間が規定時間1を越えた時点で必須機能の登録の受付を終了し、必須機能と付加機能の処理時間合計が規定時間2を越えた時点でアプリの追加を終了する。
【0149】
しかし、この時点では、各機能は固定処理時間でスケジューリングをされていることから、実際の走行時に規定処理周期内に処理が完了するか、もしくはCPU空き時間が多いか判定は困難である。特に歩行者検知アプリ140や車両検知アプリ150が安全性機能として登録されている場合、レーダ261によって検知された歩行者候補、もしくは車両候補がない場合には、処理時間がほぼ0となり、CPU空き時間が非常に大きくなる。
【0150】
アプリ登録時のスケジューリングでは、当然、検知候補が存在する場合の処理時間をベースとしてスケジューリングすることから、CPU空き時間が非常に多くなることが予想される。特に、郊外などの車両や人の通りがすくない場所では、CPUが常に活用されていないこととなる。
【0151】
このような場合には、処理周期を上げることで、安全性機能の性能向上、もしくは利便性の機能を追加することでCPUを有効活用し、ユーザの利便性を向上する。また、場合によっては、アプリ登録時のスケジューリングでは処理負荷が高く、規定周期内に処理が完了しないことが頻発するような場合も想定される。このような場合には、スケジューリングを調整するうえで、優先順位の低い処理から登録の除去をユーザに通知もしくは、選択画面にて選択させることで、スケジューリングを調整する。
【0152】
また、アプリインストール時やアプリ新規追加時に、上記手法によるスケジューリング調整を行っても良い。メンテナンス性などを考慮しても、設計側が大量のタスクテーブルを準備しておくのは設計作業の負担が大きく、シーンやユーザの好みに合わせて自動的にタスクテーブルを最適に設計することで、安全性を考慮しながらもユーザの利便性や意思を尊重したシステム設計が可能となる。
【0153】
<コア割り当て変更 スケジューリング 2CPU>
マルチコアや、マルチCPUの利用形態には、特定のコアもしくはCPUに特定の機能とOSを割り当てるAMP(Asymmetric Multiprocessing)と、個々のコアもしくはCPUが対等の条件でメモリを共有するSMP(Symmetric Multi−processing)、そして、一つのOSがあるタスクを特定のコアもしくはCPUに割り当てて実行することで、AMPの持つ移植性とSMPの持つ柔軟性を併せ持つBMP(Bound Multiprocessing)がある。
【0154】
コアやCPUに対して特定の機能を割り当てることが可能なAMP、BMPでは、このような動的予測時間処理を利用したスケジューリングにより、更に安全性、及び利便性を高めることができる。SMPやAMPの場合において、機能を別コアもしくは別CPUに割り当てることができない構成の場合には、シングルコア、もしくはシングルCPUの場合と同様の効果と作用である。
【0155】
従来のスケジューリングでは、機能に固定の処理時間を基に、図21に示すように、各コア(CPU)に対して処理を割り当てている。図21では、上段をコア1(CPU1)とし、下段をコア2(CPU2)とし、処理を割り当てている。そして、図22(a)に示すように、車両検知アプリ150の必須版アプリ1150が規定周期をオーバーしても処理が完了しない場合、CPU1のその後の規定周期内にスケジューリングされていたアプリ(車両検知アプリ150の付加版アプリ2150や路面標識検出アプリ180)の処理は完了せず、規定周期を延長するか、打ち切り処理を行うしかなかった。
【0156】
図27(b)に示すようなシーンにおける処理時間の予測結果を図27(a)に示す。予測処理時間は、CPUの処理速度をも考慮して行うが、マルチコアの場合も基本的には、1CPU(1コア)の場合の予測処理と同様である。
【0157】
レーン認識アプリ130の必須版アプリ1130と付加版アプリ2130の処理時間予測には、マルチアプリ実行部131からの過去認識結果や処理領域の大きさ、走行環境情報114に基づいて処理時間の予測を行う。処理時間の予測結果は図27(a)に、初期処理時間と比較したパーセンテージで処理時間を表現している。
【0158】
歩行者検知なども1CPUの場合と同様に処理時間の予測を行う。図27(b)のシーンにおいては、歩行者候補としてレーダ261が捕らえる候補は、電柱273Aのみのため、この領域を切り出し、人かどうか画像処理にて判定を行うための画像正規化とパターンマッチングの計算量を見積もり、処理時間を予測する。
【0159】
車両検知の場合も同様にレーザ261で検知し、処理時間を見積もる(処理時間を予測する)。図27(b)のシーンでは、車両272A〜Iが多く、自車271付近に存在するために、処理負荷が非常に高く、車両検知アプリ150の必須版アプリ1150と付加版アプリ2150における処理時間比率は250%と200%になっている。
【0160】
オートライトアプリ160では、車外の明るさを検知し、ライトのON、OFFのための判定を行う。昼のために対向車や先行車のための処理は動かず、予測処理時間は短く初期処理時間と比較してその処理時間比率は30%となっている。更に標識検知アプリ170や、路面標識検知アプリ180は、アプリ実行情報151の過去の認識結果と、車両制御情報116より処理時間を予測し、標識検知アプリの処理時間比率は95%、路面標識検知アプリの処理時間比率は93%となる。
【0161】
動的に予測した処理時間を利用することができれば、例えば図22(a)に示すように、あらかじめ予測される処理時間から規定処理周期内に車両検知アプリ150の必須版アプリ1150がコア1(CPU1)で完了しないことが予測でき、それ以降にコア1でスケジューリングされている車両検知アプリ150の付加版アプリ2150や路面標識検知アプリ180も同様に処理できないことが予想できる。
【0162】
更に、コア2(CPU2)で処理時間に余剰の空き時間があることが予測できる。これにより、動的に処理時間を予測した結果を利用して、コア1(CPU1)とコア2(CPU2)に割り当てる機能を調整することができる。
【0163】
このように、動的処理時間の予測を利用して、処理負荷をより均等に割り当てることで、マルチコア(CPU)の性能を十分に活用できるスケジューリングが可能となり、既定周期内の処理完了や、利便性の機能の効率的動作に効果がある。
【0164】
例えば、図22(b)に示すように、レーン認識アプリ130の付加版アプリ2130をコア1(CPU1)からコア2(CPU2)に割り当て変更することで、リアルタイム性を保持しながら、できる限り利便性の機能の動作保証をすることができる。
【0165】
更に、各アプリをデータ依存関係の少ない、小さな処理に分割したことを利用し、並列処理することで、コア(CPU)間の処理の分担方法に選択肢を増やす。図22(b)には、データ依存関係があった場合におけるスケジューリングを示した。データ依存関係を気にするために車両検知の並列処理が実行できず優先順位が高いにも関わらず車両検知(付加版)が処理できないなど問題があった。
【0166】
例えば、図23に示すスケジューリングでは、優先度の高さを考慮して、レーン認識アプリ130、歩行者検知アプリ140、車両検知アプリ150における必須版アプリと付加版アプリの両機能を全てスケジューリングできている。
【0167】
このように並列処理ができることも考慮したスケジューリングにより、処理の順序や打ち切り処理の対応に柔軟にスケジューリングを組み替えることが可能となり、安全性を確保するスケジューリング方法をとりながらも、利便性を追求する付加機能を効率的に実施することができる。
【0168】
<別ハード構成>
なお、上述の実施の形態では、車載用マルチアプリ実行装置100が車載カメラ内に一体に設けられている構成の場合を例に説明したが、係る構成に限定されるものではない。例えば、ハード構成は、図24に示すようなカメラの撮像系のデバイスが、画像処理する本体とは別れていて映像だけが転送されるような構造でも良い。
【0169】
また、車載用マルチアプリ実行装置100は、カーナビゲーション本体のCPUを、一部利用して動作するような方法でも良く、また、予防安全のための環境認識系に共通の一つのCPU、車両制御を制御する車両ECUのCPUを利用しても良い。また、図24に示すように走行環境情報部201が、画像処理する装置本体の内部または外部に存在するものであってもよく、走行環境の情報が画像処理装置に送信されていれば良い。
【0170】
そして、処理時間の予測処理は、処理時間の変動が大きい処理に限定しても良い。また、処理時間が正確に予測できるアプリに限定されていても良い。処理時間の変動が大きい処理の場合、毎回の予測によってスケジューリングをより効果的に変更することができる。毎回の処理時間がほぼ同等、もしくは処理時間の予測が不正確であると、むしろ適切なスケジューリングが困難になる。このような場合、動的に予測していない固定処理時間によりスケジューリングされている機能と動的処理時間予測の機能が混同しても、その効果は十分に活かされる。
【0171】
レーダ261を利用したフュージョン方式の歩行者検知や車両検知では、レーダ261の結果を利用して処理領域を決めると、画像処理の計算量がかなり正確に予測することが可能となる。レーダ261の結果によっては、歩行者候補などが見つからなければ、動的な予測処理時間はほぼ0になりうる。このように処理時間が大幅に変化するような機能には、動的な処理時間の予測によるスケジューリング最適化の効果が大きい。反対に、処理時間がほぼ一定の機能の場合には、処理時間を予測する処理を追加するよりも常に固定処理周期でスケジューリングした方が、費用対効果に優れている場合もある。
【符号の説明】
【0172】
100・・・車載用マルチアプリ実行装置、101・・・カメラ撮像部、111・・・動的処理時間予測部、121・・・マルチアプリ制御部(スケジューラ)、125・・・マルチアプリ実行部、130・・・レーン認識アプリ、1130・・・必須版アプリ、2130・・・付加版アプリ、140・・・歩行者検知アプリ、1140・・・必須版アプリ、2140・・・付加版アプリ、150・・・車両検知アプリ、1150・・・必須版アプリ、2150・・・付加版アプリ、160・・・オートライトアプリ、170・・・標識検知アプリ、180・・・路面標識検知アプリ、1100・・・必須機能部、2100・・・付加機能部、201・・・自車両走行情報部、213・・・ウィンカー、214・・・アプリ操作、215・・・カーナビ、216・・・レーダ、250・・・車両制御部、260・・・車両ECU、261・・・車速センサ、262・・・操舵角センサ、263・・・ヨーレートセンサ、264・・・アクチュエータ、300・・・制御・警告判断部
【特許請求の範囲】
【請求項1】
規定周期内に複数のアプリケーションを実行する車載用マルチアプリ実行装置であって、
各アプリケーションの処理時間を動的に予測する動的処理時間予測部と、
該動的処理時間予測部により動的に予測した処理時間に基づいて各アプリケーションのスケジューリングを行うマルチアプリ制御部と、
該マルチアプリ制御部のスケジューリング結果に基づいて前記複数のアプリケーションの処理を実行するマルチアプリ実行部と、
を有することを特徴とする車載用マルチアプリ実行装置。
【請求項2】
前記マルチアプリ実行部は、前記マルチアプリ制御部によってスケジューリングを行った結果、予め設定された規定周期内に処理が終了しないアプリケーションが存在すると判断した場合に、予め設定された優先順位に基づいて、アプリケーションの打ち切り、もしくはアプリケーションの機能を低下させることを特徴とする請求項1に記載の車載用マルチアプリ実行装置。
【請求項3】
前記マルチアプリ実行部は、各アプリケーションを安全性と利便性の機能別に分類し、前記安全性に関わるアプリケーションの処理は前記規定周期が終了しても継続し、前記利便性に関わるアプリケーションの処理は規定周期の終了により停止するスケジューリングを行うことを特徴とする請求項2に記載の車載用マルチアプリ実行装置。
【請求項4】
前記マルチアプリ実行部は、前記アプリケーションが対象とする対象候補1つずつに処理を分割して実行することを特徴とする請求項2又は3に記載の車載用マルチアプリ実行装置。
【請求項5】
マルチコア、もしくはマルチCPUを備え、
前記マルチアプリ実行部は、前記マルチアプリ制御部によってスケジューリングを行った結果、前記規定周期内に処理が終了しないアプリケーションが存在すると判断した場合に、前記アプリケーションを動作させるために指定したコアもしくはCPUを他のコアもしくはCPUに変更することを特徴とする請求項2から請求項4のいずれか一項に記載の車載用マルチアプリ実行装置。
【請求項6】
マルチコアもしくはマルチCPUを備え、
前記マルチアプリ実行部は、前記マルチアプリ制御部によってスケジューリングを行った結果、予め設定された規定周期内に処理が終了しないアプリケーションが存在すると判断した場合、もしくは、各アプリケーションの処理を前記規定周期よりも早く完了させたい場合に、前記マルチコアもしくはマルチCPUに対して同一のアプリケーションを並列処理させることを特徴とする請求項2から請求項4のいずれか一項に記載の車載用マルチアプリ実行装置。
【請求項7】
マルチコアもしくはマルチCPUを備え、
前記マルチアプリ実行部は、データ依存関係の少ない認識対象別に前記アプリケーションのタスクを分割して前記マルチコアもしくはマルチCPUに並列処理させることを特徴とする請求項2から請求項4のいずれか一項に記載の車載用マルチアプリ実行装置。
【請求項8】
前記マルチアプリ制御部は、前記スケジューリングを行った結果、規定周期内に規定値以上の空き時間が連続して存在する場合に、前記規定周期の処理時間を短縮することを特徴とする請求項1に記載の車載用マルチアプリ実行装置。
【請求項9】
前記マルチアプリ制御部は、前記スケジューリングを行った結果、規定周期内に規定値以上の空き時間が連続して存在する場合に、利便性機能を有するアプリケーションを前記規定周期内に追加するスケジューリングを実施することを特徴とする請求項1に記載の車載用マルチアプリ実行装置。
【請求項10】
前記動的処理時間予測部は、予め設定されたタスクテーブルの情報、アプリケーションの実行状態、車両制御状態、走行環境情報の少なくとも一つに基づいて前記処理時間を動的に予測することを特徴とする請求項1から請求項9のいずれか一項に記載の車載用マルチアプリ実行装置。
【請求項11】
前記アプリケーションがレーダの検知結果に基づいて画像処理領域を絞り込み、認識対象を認識する処理を行う場合に、
前記動的処理時間予測部は、前記レーダの検知結果を利用して前記処理時間を動的に予測することを特徴とする請求項1から請求項9のいずれか一項に記載の車載用マルチアプリ実行装置。
【請求項12】
前記動的処理時間予測部は、カーナビゲーションシステムに記憶されている地図情報、もしくは、自車が過去に走行した時の実処理時間の履歴を利用して前記処理時間を動的に予測することを特徴とする請求項1から請求項9のいずれか一項に記載の車載用マルチアプリ実行装置。
【請求項13】
自車の走行情報を取得する自車走行情報取得部を有し、
前記マルチアプリ実行部は、前記自車走行情報取得部により取得した自車走行情報に基づいて前記アプリの処理モードを設定し、
前記動的処理時間予測部は、前記マルチアプリ実行部によって設定された処理モードに基づいて前記予測処理時間を予測することを特徴とする請求項1から請求項9のいずれか一項に記載の車載用マルチアプリ実行装置。
【請求項1】
規定周期内に複数のアプリケーションを実行する車載用マルチアプリ実行装置であって、
各アプリケーションの処理時間を動的に予測する動的処理時間予測部と、
該動的処理時間予測部により動的に予測した処理時間に基づいて各アプリケーションのスケジューリングを行うマルチアプリ制御部と、
該マルチアプリ制御部のスケジューリング結果に基づいて前記複数のアプリケーションの処理を実行するマルチアプリ実行部と、
を有することを特徴とする車載用マルチアプリ実行装置。
【請求項2】
前記マルチアプリ実行部は、前記マルチアプリ制御部によってスケジューリングを行った結果、予め設定された規定周期内に処理が終了しないアプリケーションが存在すると判断した場合に、予め設定された優先順位に基づいて、アプリケーションの打ち切り、もしくはアプリケーションの機能を低下させることを特徴とする請求項1に記載の車載用マルチアプリ実行装置。
【請求項3】
前記マルチアプリ実行部は、各アプリケーションを安全性と利便性の機能別に分類し、前記安全性に関わるアプリケーションの処理は前記規定周期が終了しても継続し、前記利便性に関わるアプリケーションの処理は規定周期の終了により停止するスケジューリングを行うことを特徴とする請求項2に記載の車載用マルチアプリ実行装置。
【請求項4】
前記マルチアプリ実行部は、前記アプリケーションが対象とする対象候補1つずつに処理を分割して実行することを特徴とする請求項2又は3に記載の車載用マルチアプリ実行装置。
【請求項5】
マルチコア、もしくはマルチCPUを備え、
前記マルチアプリ実行部は、前記マルチアプリ制御部によってスケジューリングを行った結果、前記規定周期内に処理が終了しないアプリケーションが存在すると判断した場合に、前記アプリケーションを動作させるために指定したコアもしくはCPUを他のコアもしくはCPUに変更することを特徴とする請求項2から請求項4のいずれか一項に記載の車載用マルチアプリ実行装置。
【請求項6】
マルチコアもしくはマルチCPUを備え、
前記マルチアプリ実行部は、前記マルチアプリ制御部によってスケジューリングを行った結果、予め設定された規定周期内に処理が終了しないアプリケーションが存在すると判断した場合、もしくは、各アプリケーションの処理を前記規定周期よりも早く完了させたい場合に、前記マルチコアもしくはマルチCPUに対して同一のアプリケーションを並列処理させることを特徴とする請求項2から請求項4のいずれか一項に記載の車載用マルチアプリ実行装置。
【請求項7】
マルチコアもしくはマルチCPUを備え、
前記マルチアプリ実行部は、データ依存関係の少ない認識対象別に前記アプリケーションのタスクを分割して前記マルチコアもしくはマルチCPUに並列処理させることを特徴とする請求項2から請求項4のいずれか一項に記載の車載用マルチアプリ実行装置。
【請求項8】
前記マルチアプリ制御部は、前記スケジューリングを行った結果、規定周期内に規定値以上の空き時間が連続して存在する場合に、前記規定周期の処理時間を短縮することを特徴とする請求項1に記載の車載用マルチアプリ実行装置。
【請求項9】
前記マルチアプリ制御部は、前記スケジューリングを行った結果、規定周期内に規定値以上の空き時間が連続して存在する場合に、利便性機能を有するアプリケーションを前記規定周期内に追加するスケジューリングを実施することを特徴とする請求項1に記載の車載用マルチアプリ実行装置。
【請求項10】
前記動的処理時間予測部は、予め設定されたタスクテーブルの情報、アプリケーションの実行状態、車両制御状態、走行環境情報の少なくとも一つに基づいて前記処理時間を動的に予測することを特徴とする請求項1から請求項9のいずれか一項に記載の車載用マルチアプリ実行装置。
【請求項11】
前記アプリケーションがレーダの検知結果に基づいて画像処理領域を絞り込み、認識対象を認識する処理を行う場合に、
前記動的処理時間予測部は、前記レーダの検知結果を利用して前記処理時間を動的に予測することを特徴とする請求項1から請求項9のいずれか一項に記載の車載用マルチアプリ実行装置。
【請求項12】
前記動的処理時間予測部は、カーナビゲーションシステムに記憶されている地図情報、もしくは、自車が過去に走行した時の実処理時間の履歴を利用して前記処理時間を動的に予測することを特徴とする請求項1から請求項9のいずれか一項に記載の車載用マルチアプリ実行装置。
【請求項13】
自車の走行情報を取得する自車走行情報取得部を有し、
前記マルチアプリ実行部は、前記自車走行情報取得部により取得した自車走行情報に基づいて前記アプリの処理モードを設定し、
前記動的処理時間予測部は、前記マルチアプリ実行部によって設定された処理モードに基づいて前記予測処理時間を予測することを特徴とする請求項1から請求項9のいずれか一項に記載の車載用マルチアプリ実行装置。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【公開番号】特開2011−100338(P2011−100338A)
【公開日】平成23年5月19日(2011.5.19)
【国際特許分類】
【出願番号】特願2009−255106(P2009−255106)
【出願日】平成21年11月6日(2009.11.6)
【出願人】(509186579)日立オートモティブシステムズ株式会社 (2,205)
【Fターム(参考)】
【公開日】平成23年5月19日(2011.5.19)
【国際特許分類】
【出願日】平成21年11月6日(2009.11.6)
【出願人】(509186579)日立オートモティブシステムズ株式会社 (2,205)
【Fターム(参考)】
[ Back to top ]