(57)【特許請求の範囲】
【請求項１】
走行状態の情報を取得する情報取得部と、
該情報取得部で取得した情報に基づいて、緊急事態に遭遇する可能性の有無を判断し、緊急事態に遭遇する可能性有りと判断された場合、緊急の内容を区別する制御部と、
走行の安全性向上のための情報処理を行う第１のアプリケーションを実行する第１の実行部と、走行のフィーリング向上に関する情報処理を行う第２のアプリケーションを実行する第２の実行部と、を有する実行部と、を備え、
前記制御部は、前記緊急の内容に基づいて、前記第１のアプリケーションと前記第２のアプリケーションの一部又は全部の処理の実行の有無と、前記第１のアプリケーションと前記第２のアプリケーションの優先順位と、前記第１のアプリケーションと前記第２のアプリケーションの処理周期と、を決定し、
前記実行部は、前記制御部により決定された情報に基づいて、前記第１のアプリケーション又は前記第２のアプリケーションを実行する、車両走行に関する情報処理装置。
【請求項２】
前記情報取得部は、走行環境に関する画像を取得し、
前記制御部は、前記情報取得部で取得した情報及び画像に基づいて、前記緊急事態に遭遇する可能性の有無を判断する、請求項１記載の車両走行に関する情報処理装置。
【請求項３】
前記制御部は、前記情報取得部で取得した情報及び画像に基づいて、緊急制御に要する時間を予測し、当該予測時間が所定値より少ない場合に、緊急事態に遭遇する可能性ありと判断する、請求項２記載の車両走行に関する情報処理装置。
【請求項４】
前記第１のアプリケーションは、第１の距離より手前に存在する障害物を検知するアプリケーションと、第１の距離より遠くに存在する障害物を検知するアプリケーションと、を有する請求項１記載の車両走行に関する情報処理装置。
【請求項５】
前記第１のアプリケーションで検知される障害物に歩行者が含まれている、請求項４記載の車両走行に関する情報処理装置。
【請求項６】
前記情報取得部は、走行環境に関する画像を取得し、
前記制御部は、前記実行部における前記第１のアプリケーションを実行する処理周期を変更するために、前記画像から検知する検知対象となる距離の条件を変更する、請求項４記載の車両走行に関する情報処理装置。
【請求項７】
前記制御部は、前記緊急の内容に基づいて、前記画像から検知する検知対象の解像度を変更する、請求項２記載の車両走行に関する情報処理装置。
【請求項８】
前記制御部は、前記第１の実行部の実行周期を変更するために、前記第２の実行部の処理機能の一部あるいは全部を停止するよう決定する、請求項１記載の車両走行に関する情報処理装置。
【請求項９】
前記第１のアプリケーションは、走行レーンの曲率が所定曲率以下である場合の走行レーンを認識するアプリケーションと、走行レーンの曲率が所定曲率より大きい場合の走行レーンを認識するアプリケーションと、を有する請求項１記載の車両走行に関する情報処理装置。
【請求項１０】
前記第１のアプリケーションは、走行レーンあるいは障害物を認識するアプリケーションであり、
前記第２のアプリケーションは、ライトの照射方向を制御するアプリケーションである、請求項１記載の車両走行に関する情報処理装置。
【請求項１１】
前記第１のアプリケーションは、走行レーンあるいは障害物を認識するアプリケーションであり、
前記第２のアプリケーションは、道路標示を検知するアプリケーションである、請求項１記載の車両走行に関する情報処理装置。
【請求項１２】
各アプリケーションの一部又は全部の処理の実行の有無と、前記各アプリケーションの優先順位と、前記各アプリケーションの処理周期と、が対応付けられたタスクテーブルが予め複数記憶され、
前記制御部は、前記緊急の内容に基づいて、前記複数のタスクテーブルから、参照する一つのタスクテーブルを選択し、
前記実行部は、選択された前記タスクテーブルに基づいてアプリケーションを実行する、請求項１記載の車両走行に関する情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両走行に利用する情報の処理装置や処理方法に関する。
【背景技術】
【０００２】
車両の走行に利用する情報を的確に処理することが走行の安全性向上にとって重要である。車両走行の安全性を高めようとするニーズがあり、このために使用する処理量が多くなる傾向にある。車両の安全走行に関するいろいろな書類の処理について、常に全ての処理を実行する必要はなく、また常に全て処理を実行しようとすると処理装置の負荷が非常に大きくなり、対応速度の関係などで処理できないなどの問題が出てくる。このため処理内容に優先度を設けて処理する考え方があった。【０００３】
ここで、車載カメラやセンサ、レーダなどの検出内容に関する情報を利用する車両走行のための複数のアプリケーションの処理について、優先度を付けて処理する技術が特開２００６−２８１９００号公報（特許文献１参照）に開示されている。
【特許文献１】特開２００６−２８１９００号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
車両の走行制御に関して、安全性向上のニーズが強くきめ細かい処理が必要であり、それぞれの処理のための時間を確保することが望ましい。走行制御に関する複数のアプリケーションに対して、一定の優先度を設けて処理するのみでは、ニーズに十分に応えられない。上記ニーズに応えるには、車両の走行状況に応じて、処理の必要性の判断あるいは処理の優先度を決めることが望ましい。【０００５】
本発明の目的は、車両の走行状況に応じた処理ができる情報の処理装置及び処理方法を提供することにある。
【課題を解決するための手段】
【０００６】
１つの発明は、車両の走行状況に基づき処理、実行すべき処理の対象、あるいは処理の必要性の有無や処理の優先度、あるいは処理の周期などの処理条件を変えるようにしたことである。【０００７】
他の発明は、車両の安全走行の観点から緊急状態を検知し、前記検知に基づき、緊急時には処理の優先度を変更し、緊急処理を優先的に行うようにしたことである。【０００８】
さらに他の発明は、処理の必要性の有無や処理の優先度あるいは処理の周期などの処理条件を変える処理条件を設定するための設定プログラムと、上記設定された条件に基づいて実行される走行処理プログラムとを分離したことである。
【発明の効果】
【０００９】
本発明によれば、車両の走行状況に応じた処理ができる情報の処理装置及び処理方法を提供することができる。この結果安全性が更に向上する。【００１０】
本明細書は、本願の優先権の基礎である日本国特許出願2008-256947号の明細書及び／または図面に記載されている内容を包含する。
【図面の簡単な説明】
【００１１】
【図１】道路環境認識画像処理装置の構成を説明するブロック図。
【図２】マルチアプリ部に保持されているアプリケーションプログラムの構成を示すブロック図。
【図３】自車両走行部のブロック図。
【図４】一般道路走行モードのマルチアプリのタスクテーブル。
【図５】高速道路走行モードのマルチアプリのタスクテーブル。
【図６】一般道路走行モードのマルチアプリのタスクテーブル。
【図７】高速道路走行モードのマルチアプリのタスクテーブル。
【図８】車間距離制御走行のマルチアプリのタスクテーブル。
【図９】アプリケーション実行のフローチャート。
【図１０】走行環境を考慮したアプリケーション実行のフローチャート。
【図１１】一般道モードのマルチアプリの実行タイミングチャート。
【図１２】高速モードのマルチアプリの実行タイミングチャート。
【図１３】歩行者衝突防止のマルチアプリの実行タイミングチャート。
【図１４】高速モードの車輪逸脱に回避に関するマルチアプリの実行タイミングチャート。
【図１５】先行車との車間距離維持に関するマルチアプリの実行タイミングチャート。
【図１６】タスクテーブル変更タイミングを説明する説明図。
【図１７】歩行者衝突回避タイミングを説明する説明図。
【図１８】歩行者衝突回避に必要な時間を説明するための説明図。
【図１９】車両衝突回避タイミングを説明するための図。
【図２０】高速走行におけるレーンからの車線逸脱回避のための制御について説明する図。
【図２１】制御・警告表のアプリを説明するための説明図。
【図２２】アプリを実行するための他の実施形態を説明する制御ブロック図。
【図２３】アプリを実行するための他の実施形態を説明する制御ブロック図。
【図２４】アプリを実行するための他の実施形態を説明する制御ブロック図。
【図２５】非周期アプリを説明する制御ブロック図。
【図２６】タスクテーブルの変更を説明するための説明図。
【図２７】車の発進前のタスクテーブルを説明するための説明図。
【図２８】車の発進直後のタスクテーブルを説明するための説明図。
【図２９】車の低速走行のタスクテーブルを説明するための説明図。
【図３０】省エネ走行モードのタスクテーブルを説明するための説明図。
【図３１】省エネ走行モードの他の実施の形態のタスクテーブルを説明するための説明図。
【図３２】スポーツオートマモードの他の実施の形態のタスクテーブルを説明するための説明図。
【図３３】市街地走行モードの実施の形態のタスクテーブルを説明するための説明図。
【図３４】町乗りコンパクトカーのタスクテーブルを説明するための説明図。
【図３５】日本向け車のタスクテーブルを説明するための説明図。
【図３６】北米向け車のタスクテーブルを説明するための説明図。
【図３７】他の実施の形態を示すタスクテーブルを説明するための説明図。
【図３８】他の実施の形態を示すアプリの実行タイミングを説明図。
【図３９】他の実施の形態を示すアプリ実行フローの説明図。
【図４０】更に他の実施の形態を示すアプリ実行フローの説明図。
【符号の説明】
【００１２】
１００…処理部、１０１…カメラ撮像部、１１１…マルチアプリ制御部、１２１…マルチアプリ実行部、１３０…レーン認識アプリ、１４０…歩行者検知アプリ、１５０…車両検知アプリ、１６０…オートライトアプリ、１７０…標識検知アプリ、１８０…路面標識検知アプリ、２０１…自車両走行情報部、３００…制御・警告判断部、１１００…必須機能部、１１３０…レーン認識（必須版）、１１４０…歩行者検知（必須版）、１１５０…車両検知（必須版）、２１００…付加機能部、２１３０…レーン認識（付加版）、２１４０…歩行者検知（付加版）、２１５０…車両検知（付加版）
【発明を実施するための最良の形態】
【００１３】
図面を用いて一実施形態を説明する。以下の実施形態は製品として望ましい色々なニーズに応える技術思想を有している。これらのうちの幾つかを以下の実施形態の中で説明する。尚、上記発明の解決しようとする課題あるいは目的として記載した内容は、以下に説明する、解決しようとする課題あるいは達成しようとする目的の内の１つであり、このほかに以下に説明のいろいろな課題を解決し、目的を達成している。【００１４】
以下の実施の形態では、複数のアプリケーションを搭載した車載カメラにおいて、限られたプロセッサ性能の中では、利便性を追求するためにより多くのアプリを動作させること、及び、緊急時に対応するために安全性に関するアプリの処理周期を確保することの２つを両立させる工夫を成している。ここで、利便性を追求するためのアプリとは、例えば、ドライバがより快適に運転できるようにするための、標識認識や路面標識などの処理である。又、緊急時とは、衝突や車線逸脱を回避するための制御が必要と判断されるような状態を意味している。安全性に関するアプリとは、衝突を判断する歩行者検知１４０や車両検知１５０、車線逸脱を判断するレーン認識１３０などの処理を指す。緊急状態では車両をどのように制御するかの判断に上記認識処理の結果が利用されるため、認識結果の更新周期がより短いことが望ましい。【００１５】
以下の実施形態では、複数のアプリケーションを搭載した車載カメラにおいて、緊急時には安全性に関するアプリの処理周期を短くすることで安全性を確保し、通常走行時にはより多くのアプリケーションを時分割で動作させ利便性を確保することで、安全性と利便性の両立を可能とする。【００１６】
なお、以下の実施形態では、代表例として、単眼カメラを使用しているが、複数のカメラ、即ち、ステレオカメラを使用することで、処理精度を向上することができる。基本的な動作は同じである。以下の実施形態では、カメラの画像処理が最適であるが、カメラの変わりにレーダを使用することも可能である。
【実施例１】
【００１７】
〔道路環境認識画像処理装置の構成の説明〕
図１を用い、最初に構成要素を説明する。車両走行における通常時や緊急時の判断に基づきアプリケーションの処理周期を動的に切り替えることが可能な複数のアプリケーションを時分割で実行する（以下、マルチアプリと記載する場合がある）ための一実施の形態として、車載カメラからの情報を用いた道路の環境認識を行うための画像処理装置（以下道路環境認識画像処理装置と記載する場合がある）の構成を示す。【００１８】
道路環境認識画像処理装置には、カメラあるいはレーダなどの計測装置１０１からの画像を処理するための処理部１００と、自車両走行情報部２０１と、制御・警告判断部３００を備えている。処理部１００はカメラやレーダなどの装置からの情報を処理し、道路の状況を検知し判断する。例えば、人や他の車両を含む走行上の障害物、白線や路肩さらに標識や信号など、あるいはカーブなどの道路状態などを検知し判断するための情報を計測装置から受ける。これら計測装置としては上述のカメラ、例えば、単眼あるいはステレオカメラがあり、あるいは光を使用したレーダあるいは音波を利用したレーダがある。この中で特にカメラの撮像情報を代表例として計測装置１０１を説明する。他計測装置を使用する場合は、カメラ撮像部１０１の代わりに、これらの計測装置に接続されているとして扱うことができる。又、上記装置の組合せでもよく、その場合にはカメラ撮像部１０１の代わりに複数種類の計測装置が繋がり、これらから情報を受けることとなる。【００１９】
この実施形態はカメラ撮像部１０１を代表として使用した例で、処理部１００は、カメラ撮像部１０１で撮影された画像を利用して画像処理を行う内容で説明する、しかし同じ考え方で、他の情報を使用する処理にも適用可能である。マルチアプリ制御部１１１では、制御・警告判断部３００の判断に基づいて、各機能の処理周期や実行動作を行う（ＯＮで記載）、実行を停止する（ＯＦＦで記載）などを決定し、その結果に基づいてマルチアプリ実行部１２１では各機能を実行する。車載カメラの認識結果を利用して衝突回避や車線逸脱回避などの車両制御を行う場合には、通常走行時と比較してカメラの認識処理周期が短いことが望ましい。反対に、上記のような緊急事態に備えている通常走行時には、緊急時ほど短い処理周期で車の外界を認識する必要はない。マルチアプリ制御部１１１において処理周期や実行動作のＯＮ、ＯＦＦを制御することで、緊急時における衝突回避や車線逸脱回避に関するカメラの認識処理を短い処理周期で実行可能とする。一方車両の通常走行時には利便性を追求するアプリケーションを時分割で動作させ、限られたプロセッサの処理能力をより効果的に活用することを可能とする。【００２０】
図２に、マルチアプリ実行部１２１の詳細な構造を示す。マルチアプリ実行部１２１には、全ての画像処理のアプリケーション（アプリ）すなわちアプリの処理プログラムが機能別に登録され、この各機能が必須機能部１１００と付加機能部２１００とに分類された構造をなしている。もちろん構造が分離されているので、図の左側に示すレーン認識アプリ、あるいは歩行者検知アプリ、あるいは車両検知アプリのそれぞれに対して、必須機能部１１００と付加機能部２１００とを別々に実行できる。必須機能部１１００と付加機能部２１００とを全く別々のプログラムに分離しても良いし、同じ処理内容はその処理内容のプログラムを共通に実施できるようにしても良い。重要なことは見かけ上別々に実行できることである。【００２１】
この実施の形態では、図２に示すマルチアプリ実行部１２１の機能は、事故予防に直接的効果のある必須機能部１１００と、より快適な運転支援を主目的とする付加機能部２１００との観点で分類されている。衝突回避時や車線逸脱回避時などの緊急時においても動作保証したいアプリを必須機能部１１００として登録することで安全性を確保する。反対に緊急時には動作保障する必要はないが、通常走行時にドライバにとって有用な情報を提供するアプリを付加機能部２１００として登録することで利便性を追求する。必須機能部１１００と付加機能部２１００に分類して登録することで、緊急時と通常時に動作する機能のより柔軟な切り替えを可能にし、安全性と利便性の両立を図ることが可能となる。【００２２】
レーン認識アプリ１３０は、カメラによって撮影された画像から白線を認識する画像処理機能である。レーン認識アプリ１３０は、予防安全に直接効果が期待される車線逸脱防止に必要な車線内における自車両の横位置、ヨー角を推定することが可能なレーン認識アプリ１３０（必須版１１３０）を必須機能部１１００に分類する。又、カーブより遠方の白線状況を検知対象とし、カーブ進入前における減速やカーブ時における操舵支援など快適な走行に効果が期待されるレーン認識アプリ１３０（付加版２１３０）を付加機能部２１００として機能分割する。このようにレーン認識アプリ１３０という一つのアプリケーションを、安全性に直接関係のある車線逸脱防止のための認識機能を必須版に、利便性に関連するカーブ進入前減速のための認識機能を付加版に分類する。これにより車線逸脱などの緊急時には、車線逸脱回避のために必要な最小限の認識処理だけを優先して実行し、利便性に関する認識処理を停止させることで、全体の処理周期を短くすることを可能とする。【００２３】
歩行者検知アプリ１４０も、車速に応じた制動距離を考慮し衝突回避可能な距離に対して動作保障する歩行者検知アプリ１４０（必須版１１４０）と、より遠方での歩行者候補に対しても検知処理を行う歩行者検知アプリ１４０（付加版２１４０）に分類する。安全性確保のための歩行者検知アプリ１４０（必須版１１４０）では、歩行者がある程度近距離にいることを想定しているため、高解像度の画像を利用するよりも、ある程度の解像度の画像を利用し、検知結果の更新周期をより早めることを重視した設定とする。反対に、歩行者検知アプリ１４０（付加版２１４０）では、より遠方の歩行者を対象とするために、高解像度の画像を利用する。【００２４】
車両検知アプリ１５０も、先行車両との相対速度や距離、自車舵角を考慮し衝突を回避するために必要な車両候補に対して画像処理する車両検知アプリ１５０（必須版１１５０）を必須機能部１１００へ分類する。より早期における車両の検知や検知率の向上、車間距離制御などを目的により遠方の車両を検知対象とする車両検知アプリ１５０（付加版２１５０）を付加機能部２１００に分類する。解像度や処理周期に関する方針は、歩行者検知アプリ１４０と同様である。歩行者検知アプリ１４０や車両検知アプリ１５０は、衝突回避のための認識処理を必須版、車両制御には直接利用しない遠方などの処理を分類して付加機能部に登録することで、機能別の処理周期制御や機能のＯＮ、ＯＦＦを実現する。このようなマルチアプリの動的処理周期の制御により、緊急時の安全性確保と通常時の利便性確保を効果的に実現する。【００２５】
オートライト１６０アプリは、カメラの画像認識を行うことにより外界の明るさを検知し、ヘッドライトのＯＮ、ＯＦＦや方向を制御するアプリであり、自動的に制御されることで利便性が向上するが、仮に自動的に行われなくても、運転者が必要に応じて操作可能である。先行車の検知と併用することで、ハイビームとロービームの制御を行う。レーン認識１３０、もしくは自車両走行情報部２０１の車速センサ２１１と舵角センサ２１２からの自車両予測進路、もしくはカーナビ２１５からの自車両予測進路と併用することでカーブ方向へヘッドライトの照射角度の制御を行う。更に路面標識検知１８０と併用することで交差点における照射角度の制御などに利用する。より快適な運転支援を目的としており、このアプリ全体を付加機能部２１００に分類する。標識検知アプリ１７０は、制限速度などの道路標識の検知を行い、この情報をドライバに提供することで快適な運転支援を目的とするため、このアプリ全体を付加機能部２１００に分類する。路面標識検知アプリ１８０は、路面上の制限速度表示などの検知や、横断歩道を検知することにより、ナビ位置情報の高精度化などのドライバへの運転支援の情報を検知する機能のため、このアプリ全体を付加機能部２１００に分類する。【００２６】
図３に、図１の自車両走行情報部２０１の詳細を示す。自車両走行情報部２０１は、自車両の走行に関する情報を車載の通信網を通じて処理部１００へ送信する。自車両走行情報部２０１は、自車両の車速センサ２１１、舵角センサ２１２、ウィンカー２１３、アプリ操作２１４、カーナビ２１５、からなる。【００２７】
〔タスクテーブルについての説明〕
図４から図８は、アプリケーションの実行を管理するために、車両の各走行モードにおける緊急時及び制御時におけるタスクテーブルの状態を示す。この状態タスクテーブルの内容に基づいて、対象アプリの必須部〔版〕や付加部〔版〕に関する実行の有無や優先度、実行頻度、使用する情報の条件、などが決められる。従ってタスクテーブルの内容を変更することで、アプリの処理条件などが簡単に変更できる。まず、タスクテーブルの内容について以下に説明する。各機能を縦軸に分類し、タスクテーブルにて設定する各項目を横軸に並べ、これをモード切り替え時もしくは、緊急時、制御時などに各項目を変更することで、各機能の各項目別の制御を行いマルチアプリの処理周期を変更する。このようにタスクテーブルの情報を自車両走行情報や外界認識結果に応じて動的に書き換えることで、状況に応じて変化するシステム要求に対応し、緊急時における安全性確保と、通常時における利便性の確保を両立したシステム構成とした。【００２８】
次に、タスクテーブルにて設定する各項目を以下に示す。有効フラグとは、選択されたモードにて機能を動作すべきか判定するためのフラグであり、ＯＮは実行対象であることを示し、ＯＦＦは実行停止を意味する。すなわち有効フラグをＯＮにすれば実行され、ＯＦＦに変えられると実行されない。図４に示す、車両の一般道路の走行時には、左側の項目に示すレーン認識〔必須版〕、レーン認識〔付加版〕、から最後の路面標識検知の全てのアプリが実行対象となり、優先順位に従い実行される。一方車両が高速道路を走行している場合には、図４に示す如く、歩行者検知アプリ１４０の必須版アプリ１１４０や、歩行者検知アプリ１４０の付加版アプリ２１４０が、その有効フラグの項目がＯＦＦとなっている。高速道路の走行中は歩行者が走行している道路にいることが考えられないため、歩行者検知アプリ１４０の必須版アプリ１１４０や付加版アプリ２１４０が実行されないように、有効フラグにＯＦＦがセットされる。また路面に標識が記されることもほとんど無いので、このアプリも実行の必要が無く、有効フラグがＯＦＦに変えられる。このことにより、高速道路の走行では、他のアプリの処理に時間を割り当てることが可能となる。【００２９】
図４の一般道走行から高速道路走行に、走行環境が変わった条件で、必須機能部１１００と付加機能部２１００からなるアプリケーションのレーン認識１３０、歩行者検知１４０、車両検知１５０は、必須機能部１１００の有効フラグがＯＦＦの場合、同一アプリの付加機能部２１００の有効フラグは必ずＯＦＦとする。例えば、レーン認識１３０の場合、レーン認識１３０（必須版１１３０）が有効フラグＯＦＦで動作停止した状態において、レーン認識１３０（付加版２１３０）のみが有効フラグＯＮであり動作するということはない。必須機能部がＯＮの場合には、付加機能部２１００に属する機能は、状況に応じて制御する。【００３０】
必須機能部１１００のＯＮ、ＯＦＦは、現在高速道路を走行中なのか、一般道を走行中なのか等の自車両走行情報部２０１に基づいてモード設定を行う際に、変更を行う。例えば、高速道路走行中には、歩行者は高速道路にいないとの仮定より、歩行者検知機能を動かすよりも他機能にプロセッサ処理を割り当てた方が、ドライバにとって快適で安全な運転ができると考え、歩行者検知アプリ全体をＯＦＦとし、他機能の処理の優先や、高速移動時における１サイクル分の処理時間を短くするためにアプリのＯＮ、ＯＦＦを制御する。【００３１】
付加機能部２１００のＯＮ、ＯＦＦは、自車両走行情報部２０１及びアプリからの認識情報に基づいて制御される。特に、緊急時などは、安全のための制御に関わる機能を優先させるために、付加機能をＯＦＦとする場合が多い。反対に、通常走行時などは、安全に関わる必須機能の処理周期が必ずしも短い必要がない場合には、付加機能にプロセッサの処理を割り振ることで、利便性の向上を図る。【００３２】
上記の如くアプリの実行条件の切り換えは、一般道の走行からの高速道路への走行環境の切り替りに基づいている。このように走行環境が切り替わることで実行すべきアプリが変わり、また優先度やその他の実行条件が変わる。走行環境が切り替わりを検知する方法として、例えば、ギヤ変更の切り換え、車速の変化、高速道路などの有料道路の料金所の通過、カーナビの情報、などがある。【００３３】
優先順位とは、各機能（アプリ）の相互間の実行における優先順位を示し、数字が小さい方が優先度の高い機能（アプリ）であることを示す。例えば、遠方にカーブを検知したことによる減速の制御が行われる場合には、この減速制御に関係しない付加機能（アプリ）の優先順位を下げることで、優先度の高い機能の実行開始時期を早め、すなわち短い周期で実行することが可能となる。それ反面優先度が下げられた付加機能（アプリ）の実行開始時期が遅らせるなど、実行周期が長くなる。図４から図８における処理の項目は、図１０に示す１サイクルにおける処理回数を示す。本画像処理装置における１サイクルとは、図１０に示す、１連の処理１回分のループを示す。同一の機能でも、優先度が低くなるにつれて処理回数が小さくなるような設計とする。レーン認識１３０（必須版１１３０）の処理［１／１］とは、１サイクルに１回、プログラムが実行されることを意味する。付加機能のオートライト１６０の処理［１／３］とは、３サイクル中に１回、機能が実行されることを意味する。【００３４】
例えば、レーン認識アプリ１３０の曲率算出部分の機能（アプリ）などは、道路が急に曲率が変化することがないことを考慮すると、必ずしも高い優先度で短い処理周期で繰り返し実行する必要がない。短い処理周期であれば精度は良くなるが、他に優先する処理があるような場合には、［１／２］で処理しても問題がない。そこで曲率算出部分の機能（アプリ）より優先すべき機能（アプリ）がある場合には、曲率算出部分の機能（アプリ）の実行周期を調整項目として処理周期を変更することができる。この場合は、図４〜図８に示す処理の欄の内容を［１／２］とする。・・・処理時間が不足する場合には、予め定められた手順で優先度の低いアプリの実行周期を長くする。【００３５】
歩行者検知アプリ１４０の付加版アプリ２１４０、車両検知アプリ１５０の付加版アプリ２１５０、標識検知アプリ１７０、路面標識検知アプリ１８０などの場合は、処理レベルが低くなると、実行順位が下がり実行タイミングが多少遅くなる。検知距離内に入ってからの認識処理回数が少なくなるため検知率が多少低下するなどが考えられるが、この低下よりも重要な機能すなわちアプリがある場合に、処理周期の調整にて優先事項の処理開始が早くなり、非優先事項については処理開始が遅くなるように制御される。カーブ中の速度抑制などの制御中には、標識検知１７０や、路面標識の検知率が多少下がるよりも減速制御のためのカーブ認識アプリを高い優先度で早く実行することが重要となる。【００３６】
図４から図８で、解像度の項目は、画像認識に利用する入力画像のサイズを示す。カメラの最大解像度を［１、１］と示す。［ａ、ｂ］の表記方法は、ａが画像横方向の解像度、ｂが画像縦方向の解像度を示す。例えば、最大解像度７６８×２４０の場合に、入力画像として２５６×２４０の画像入力とするレーン認識１３０（必須版１１３０）の解像度は、［１／３、１／２］と示し、横解像度が最大解像度の１／３、縦解像度が最大解像度の１／２であることを示す。すなわち、図４から図８で、各アプリに必要な画像などの情報の量を、解像度を規定する。解像度が高く情報量が多い場合には、処理に時間が係る。アプリの目的に照らし、適切な解像度がどれだけかをアプリごとに定める。この解像度に基づき図１のマルチアプリ実行部１２１から計測装置１０１であるカメラ画像部１０１に指示を送り、カメラなどの計測装置の設定を変えるようにする。なお、計測装置１０１から高い解像度の出力すなわち画像を取り込み解像度の項目の値に合せて、解像度を下げ、処理するようにしても良い。図４から図８の実施の形態は、計測装置１０１から高い解像度の出力すなわち画像を取り込み解像度の項目の値に合せて、解像度を下げる処理を行っている。【００３７】
レーン認識アプリ１３０や歩行者検知アプリ１４０において検出結果の位置精度を重要視する場合や、より遠方を検知対象とする場合、高解像度の画像を利用することが望ましい。しかし、高解像度画像を利用することによる計算時間が増加し、処理負荷の関係で、処理周期に間に合わないなどの影響を与える可能性がある。検知位置精度、検知対象距離、処理周期などの条件に応じて必要な解像度に合わせアプリの実効前に解像度を調整する。例えば、車線逸脱回避を想定した場合には、車両に対するレーンの横位置やヨー角にある程度の認識精度は必要とするものの、遠方の曲率値や車線逸脱予測位置より遠方のレーン位置などはあまり重要でない。車線逸脱回避のために車両制御するような状況では、低解像度な画像を利用し処理コストを削減することで、車両制御に利用されるレーン横位置やヨー角の更新周期を早め、より高度な車両制御を実現する。【００３８】
検知距離とは、各機能が認識対象とする最遠方の距離を示す。例えば、通常モードにおける歩行者検知１４０（必須版１１４０）の検知距離が、４０［ｍ］とは、４０［ｍ］より遠方にいる歩行者については検知対象外とすることを意味する。歩行者検知１４０でいえば近傍に衝突可能性の高い歩行者が認識され、車両制御が必要と予測されるような場合に、車両制御の対象範囲外の遠方を検知することが重要でない。遠方を対象からはずすことで処理コストを削減し、歩行者位置を高フレームレートで更新し、より高度な衝突回避制御を可能とする。【００３９】
〔タスクテーブルを利用した処理フローの説明〕
図９に、タスクテーブルを利用したマルチアプリの処理フローを示す。例えば、図１０から図１４に示す実行タイミングＲ毎に実行される。ステップＳ１で、自車両走行に関する情報、また車両走行環境に関する情報を取得する。自車両走行情報とは、自車両の車速センサ２１１による車速、舵角センサ２１２によるヨーレート、ウィンカー２１３によるウィンカー操作情報、アプリ操作２１４によるアプリ操作情報、カーナビ２１５によるカーナビからの情報であり、これらの情報を取得する。【００４０】
ステップＳ２では、カメラ撮像部１０１において撮像された画像を取得する。上述のとおり、カメラ撮像部１０１はレーダでも良く、一般にはセンサなどの計測装置であり、計測装置の出力を取り込む。【００４１】
ステップＳ３はステップＳ１において取得した自車両走行情報及び、ステップＳ６において得られる画像処理アプリの認識結果に基づいて、緊急の事象が発生するまでの時間や、それを回避するための制御を開始する時間、緊急の事象が発生する可能性を推定する。これを基に快適な運転支援のための処理か、緊急処理が必要かの判断を行う。緊急処理が必要と判断された場合には、ステップＳ６の処理へ移る。緊急の処理が必要でないと判断された場合には、ステップＳ４の処理を行い、ステップＳ５の処理へ移る（アプリ別の推定方法は、タイミングの箇所で後述する）。ステップＳ４ではＳ３において推定結果より緊急時と判断された場合に、緊急の内容を区別し、緊急の内容別に予め定めておいた、タスクテーブルを読出し、ステップＳ５で読み出した内容に基づき、その車両制御内に応じたシステムの要求を満たすように各機能のタスクテーブルを変更する。【００４２】
次にステップＳ６で、変更されたタスクテーブルを参照し、ステップＳ６とステップＳ７により、各アプリケーションのアップリケーションの有効フラグがＯＮになっているタスクの中から、優先順序の最も高いアプリを選定し、ステップＳ８で実行する。図４から図８に示したように各アプリケーションの機能別に、それぞれの有効フラグ、優先順位、処理サイクル、解像度、検知距離を記載するテーブルとし、このテーブルを書き替えることでアプリケーションの動作のＯＮ、ＯＦＦから、処理サイクル、解像度、検知距離の設定などを行う。マルチアプリ実行部１２１では、このテーブルを参照することで、機能を制御する。【００４３】
緊急制御における高度な制御や、より早急な制御開始には、処理サイクルの高フレームレートが重要である。車両走行情報と外界認識結果に基づいて、有効フラグの設定、優先順位、処理サイクル、画像処理に利用する画像の解像度、検知距離の変更などを行うことにより、高フレームレートでの処理を行う。解像度を低解像度な画像に変更する場合、検知距離が短くなる、検知率の低下、又はレーン認識１３０では認識精度（レーン位置やレーンとのヨー角）が低下することを考慮した上で、それ以上に認識結果の高フレームな更新が重要であるとシステム側が判断した場合に解像度の低下を選択することになる。反対に、制御が必要と判断されなかった場合に、より遠方を検知対象とすることが重要な場合には、高解像度な画像を利用するかわりにフレームレートが遅くなるようなタスクテーブルの変更を行う。ステップＳ６で変更されたタスクテーブルを参照し、このタスクテーブルの情報を基にステップＳ７において実行されるべきアプリが決められ、ステップ８で実行する。【００４４】
〔一般道と高速道路のモード切り替えについての説明〕
図１０は図９の処理フローにおいて、さらに走行環境の情報に基づき実行するアプリの実行条件を変える処理を説明している。なお、同じステップの符号は同じ処理、同じ機能を示す。ステップＳ３で緊急時の有無を判断する点は同じである。緊急処理が必要と判断すると図９のステップＳ４やステップＳ５を実行するのと同様の処理を行う。図１０ではステップＳ４やステップＳ５を合せて、ステップＳ４／Ｓ５−１として表現しているが内容は同じである。その後図９ではステップＳ６とステップＳ７を実行するがこの内容も同じであり、図１０ではステップＳ６／Ｓ７と記載した。その後、選択されたアプリをステップＳ８で実行する。【００４５】
一方緊急性が無い場合であっても図１０では、ステップＳ３−１で、走行車両の環境状態を判断する。その一例が高速道路などの自動車専用道路か一般道路過の判断である。例えば、図１や図３の自車両走行情報部２０１で、カーナビ２１５もしくは、ナビ画面からのアプリ操作２１４によって、一般道であると判断されると、一般道路の走行に適した、図４に示すタスクテーブルが、ステップＳ４／Ｓ５−２で読み出され、タスクテーブルは図４の内容となる。一方高速道路の走行中であると判断されると、ステップＳ４／Ｓ５−３が実行され、タスクテーブルの内容は図５の内容となる。【００４６】
図１１は図４に示すタスクテーブルに基づくアプリの実行を示す。レーン認識１３０（必須版）１１３０やレーン認識１３０（付加版）２１３０、歩行者検知（必須版）１１４０や歩行者検知（付加版）２１４０、車両検知（必須版）１１５０や車両検知（付加版）２１５０は、図４に示す如く有効フラグが全てＯＮであり、また処理欄が全て〔１／１〕である。従って１サイクルに１度実行される。図１１で四角の箱はアプリプログラムの実行状態を示している。レーン認識１３０（必須版）１１３０やレーン認識１３０（付加版）２１３０、歩行者検知（必須版）１１４０や歩行者検知（付加版）２１４０、車両検知（必須版）１１５０や車両検知（付加版）２１５０は全て１サイクルに１度実行されることが分かる。１サイクルはこの実施の形態では、７個の実行タイミングＲで構成されている。一方、オートライトアプリ１６０は５サイクルに一回実行であり、図１１の範囲では、実行されていない。また標識検知アプリ１７０は３サイクルに一回実行であり、図１１の左のサイクルで実行されているが、次のサイクルでは実行されない。路面標識検知アプリ１８０は３サイクルに一回実行であり、図１１の左のサイクルでは実行されていないが、次のサイクルでは実行されている。このように図４のタスクテーブルに従って実行される。【００４７】
一方高速道路を走行している場合には、図５に示すように、歩行者検知（必須版）１１４０や歩行者検知（付加版）２１４０は実行されない。図１２に示す如く、アプリプログラムの実行を見ると歩行者検知（必須版）１１４０や歩行者検知（付加版）２１４０は実行されない。さらに図５では、路面標識検知アプリ１８０の有効フラグがＯＦＦであり、図１２においても実行されていない。このように図１０のフローにおいて、ステップＳ３−１で一般道の走行か、高速道路あるいは自動車専用道路の走行かによって、タスクテーブルが選択され、図１１や図１２に示す如く、アプリの実行が異なってくる。上述の通り、一般道を走行している場合には、一般道における制限速度から制動距離を算出し、制動距離に所定値の距離を加えた距離を、歩行者検知１４０と車両検知１５０の必須機能とする。これにより制御をかけ始めるタイミングにある障害物を必ず必須機能部１１００の検知対象内に含めるように設計することで安全性の確保を図る。レーン認識１３０は、車線逸脱の制御などには、遠方よりも近傍領域におけるレーンに対する車両の角度や横位置が重要となるため、対象距離を短めに設定する。【００４８】
更に図１０のフローのステップＳ３−１で、自車両走行情報に基づいて一般道でないと判断された場合には、図５に示す通常時の高速モードにタスクテーブルを書き替える。人が歩いている可能性が非常に低い高速道路において歩行者検知機能を動かすよりも、他の認識処理を短い処理周期で動かした方がドライバにとって有効なシステムであると考えられる。高速モードでは、歩行者検知１４０の有効フラグを、必須機能版、付加機能版ともにＯＦＦとする。車速の高い高速道路では、安全を確保するために、各機能の検知対象距離を長く設定する。車速が高いために制御を行う場合には、より高フレームレートの認識結果が得られることが望ましく、歩行者検知１４０をＯＦＦにすることで処理コストを下げ、緊急制御時における高フレームレートを実現し、車速が高いことによって難しくなる制御にも対応する。【００４９】
〔緊急モードへの変更処理の流れ〕
次に一般道モード：歩行者衝突防止の緊急制御時について説明する。【００５０】
（１）タスクテーブル変更内容の説明
図９や図１０のステップＳ３において、歩行者との衝突防止のための制御、もしくは警告が必要か否かの判断は、歩行者検知１４０によって判断される。歩行者検知１４０もしくはレーダなどの外界認識装置により、自車両に対する歩行者位置が時系列に検知できるため、これより歩行者の動き予測を行う。図１８に示すように、自車両の車速と歩行者までの距離から衝突余裕時間（ＴＴＣ）を算出し、更にＴＴＣ秒後の衝突予想時刻における歩行者横位置（Lateral）から衝突の可能性を推定する。衝突余裕時間（ＴＴＣ）は次のように計算される。【００５１】
衝突余裕時間（ＴＴＣ）＝歩行者までの距離（Ｌ）／自車速（Ｖ）
歩行者横位置（Lateral）＝(自車速(Ｖ)×cosθ−Ｖped)×衝突余裕時間(ＴＴＣ)
車両ヨー角：θ
歩行者横移動速度：Ｖped
自動ブレーキ制御などでは、ドライバの回避操作が疎かにならないように、ドライバが通常の運転で行う回避操作よりも遅くすることが望ましく、更に衝突を避けるためには、衝突不可避になるタイミングより早いことが望ましい。そこで、図１６に示すようにＴＴＣがこのドライバの通常の回避操作と衝突不可避のタイミングの間で、制御開始予測時間より所定値α早いタイミングにてタスクテーブルを書き替える。制御開始タイミングよりも早めにタスクテーブルを設定し、アプリの周期を変更することで車両制御側からは常に短い周期で認識処理されている場合と同等の車両制御を行うことができる。又、タスクテーブル書き替えのタイミングが、ドライバが通常の運転で行う回避操作よりも遅めに選ぶことで、通常走行時にマルチタスクをむやみに緊急時のタスクテーブルへ変更しないようにし利便性にも配慮する。【００５２】
（２）タスクテーブル変更内容の説明
歩行者衝突防止の制御を行うためには歩行者検知１４０（必須版１１４０）が必須機能であり、特に、制御中はより短い間隔で処理する必要がある。このためタスクテーブル変更タイミングにおいて、図９におけるステップＳ６のループを回り、タスクテーブルの変更処理を行う。一般道モードにおける歩行者衝突防止緊急モード時のタスクテーブルの変更例を、図６のタスクテーブルに示す。緊急時においても必須機能に登録された、レーン認識１３０（必須版１１３０）、歩行者検知１４０（必須版１１４０）、車両検知１５０（必須版１１５０）の３つは常に動作させる。緊急制御に利用される可能性のある機能の優先度は保持することで安全性を確保する。反対に緊急時には、付加機能部分の優先度や精度、処理周期を下げる、もしくは機能停止させることにより１サイクル分の処理時間を短くすることで、歩行者の認識結果の更新周期を高め高精度な制御を可能にする。通常時は付加機能に利用される処理を、緊急時には制御に利用される安全性の機能に処理を割り振ることで安全性に配慮したマルチアプリ制御を行う。【００５３】
１サイクルに相当する周期を短くした緊急モード時におけるタイミングチャートを図１３に示す。１サイクルの長さを短くすることで、レーン認識１３０（必須版１１３０）によって算出されるヨー角、横位置の更新周期を早め、車線逸脱防止の制御を高精度に行う。図１１では７個の実行タイミングを１サイクルとし、図１２では５個の実行タイミングを１サイクルとしている。図１３では、１サイクルの長さを固定せず、緊急処理が必要な場合に１サイクルの長さを短くできる。図１３では、通常４個の実行タイミングを１サイクルとしているが、緊急時には、図１３に示すとおり、３個の実行タイミングを１サイクルとし、優先度の高いアプリの実行周期を短い周期に変更している。このようにすることで、応答性を向上させることが可能となる。【００５４】
次に一般走行での車両衝突回避の緊急制御時について説明する。【００５５】
（１）タスクテーブルの切り替え時期の説明
先行車両との衝突回避のための制御、もしくは警告が必要か否かの判断は、車両検知１５０もしくはレーダによって判断される。図１９に示すように車両検知１５０もしくはレーダなどの外界認識装置により、自車両に対する先行車の位置が時系列に検知できるため、先行車の相対速度Ｖreと相対位置Ｌreを得る。相対速度と相対位置より衝突余裕時間（ＴＴＣ）を推定する。衝突余裕時間（ＴＴＣ）は次のようになる。【００５６】
衝突余裕時間（ＴＴＣ）＝相対位置Ｌre／相対速度Ｖre
ＴＴＣ秒後の衝突予想時刻における先行車と自車両の横位置（Ｌat）を計算する。【００５７】
Ｌat＝（自車速Ｖ×自車ヨー角cosθ）×衝突余裕時刻（ＴＴＣ）
更に、先行車と自車両の重なり程度（オーバーラップ率）を考慮の上、衝突の可能性を推定する。タスクテーブル変更のタイミングは、対象が歩行者から車両となるため、車速やオーバーラップ率などが影響するが、基本的な考えは歩行者衝突回避と同様であるため詳細は省略する。【００５８】
（２）タスクテーブル変更内容の説明
歩行者の一般道におけるテーブル内容と同一となるため省略する。【００５９】
次に一般走行での車間制御時に処理について図１９を用いて説明する。【００６０】
（１）制御を起動する、すなわちタスクテーブルの変更時期の説明
他車との車間距離の制御では、衝突回避のための車間距離の維持が重要である。このため衝突の回避のためにブレーキ制御が必要と判断されたタイミングで、タスクテーブル変更を行ってから車両制御を行うことが望ましい。【００６１】
（２）タスクテーブル変更内容の説明
例えば、一般の街中の走行において、先行車両と３０ｍの車間距離で制御するケースを考える。図１９において、車両検知１５０（必須版１１５０）とレーン認識１３０（必須版１１３０）が必須機能であり、これらのアプリは、より早い処理周期で実行されることが望ましい。制御モード起動タイミングにおいて、タスクテーブル２への変更処理を行う。先行他車が検知されると、その検知を基に図８に示すタスクテーブルに切り替わる。この検知は図９や図１０のステップＳ３で行われ、図８のタスクテーブルの切り替わりはステップＳ４とステップＳ５で行われる。図８は一般道の走行モードにおいて先行車両との車間距離を安全な距離、例えば３０ｍ以上を保持しながら走行する場合における制御モードに使用されるタスクテーブルを示す。先行車両が３０ｍ前に存在するため、車両検知１５０（付加版２１５０）や歩行者検知１４０（付加版２１４０）は有効フラグをＯＦＦに設定し、必須版の検知対象を４０ｍとする。レーン認識１３０についてもレーン認識１３０（付加版２１３０）は動作させるものの、先行車に隠されて遠方の道路が見えない可能性も高いため、検知範囲は４０ｍとする。又、その他の付加機能については、処理のサイクルを落として回すことで、１サイクルの処理時間を更に短くしている。このようにすることにより、タスクテーブルを切り替えることで、安全性を高めることが可能となる。【００６２】
次に高速走行におけるレーンからの車線逸脱回避のための制御について図２０を用いて説明する。【００６３】
（１）タスクテーブルの切り替え時期の説明
車線逸脱回避のための制御が必要か否かの判断は、レーン認識１３０（必須版１１３０）、の結果によって判断される。レーン認識１３０（必須版１１３０）では車線に対する自車両のヨー角、横位置が算出可能である。制御開始の予測算出時間より所定値α前から、減速制御のためのタスクテーブル変更を行う。【００６４】
車線逸脱回避のための制御、もしくは警告が必要か否かの判断は、レーン認識１３０（必須版１１３０）によって判断される。自車両に対するレーン位置、姿勢が時系列に検知できるため、自車両走行情報も利用し、車線逸脱の予測を行う。【００６５】
車線逸脱余裕時間ＴＴＤ＝車線横位置ＬＬat／（自車速Ｖ×車両ヨー角cosθ）  基本の考え方は歩行者や車両の衝突回避と同じであり、自動制御などは、ドライバの回避操作が疎かにならないように、ドライバが通常の運転で行う回避操作よりも遅くすることが望ましく、更に車線逸脱を避けるためには、逸脱不可避になるタイミングより早いことが望ましい。ドライバの通常の回避操作と逸脱不可避のタイミングの間で、制御開始予測時間より所定値α早いタイミングにてタスクテーブルを書き替える。制御開始タイミングよりも早めにタスクテーブルを設定し、アプリの周期を変更することで車両制御側からは常に短い周期で認識処理されている場合と同等の車両制御を行うことができる。又、タスクテーブル書き替えのタイミングが、ドライバが通常の運転で行う回避操作よりも遅めに選ぶことで、通常走行時にマルチタスクをむやみに緊急時のタスクテーブルへ変更しないようにし利便性にも配慮する。【００６６】
（２）タスクテーブル変更内容の説明
図７は高速道路走行モードのマルチアプリのタスクテーブルを示す。図９や図１０のステップＳ３やステップＳ３−１で高速道路走行と判断すると、図９や図１０のステップＳ４やステップＳ５あるいはステップＳ４／Ｓ５−２やステップＳ４／Ｓ５−３で、図７のテーブルを検索により特定し、実行テーブルとしてセットする。この高速道路走行のモードでは、必須機能は、レーン認識１３０（必須版１１３０）と車両検知１５０（必須版１１５０）である。高速道路に歩行者はいないと仮定し、一般道モードでは歩行者検知に割かれていた処理コストを、車速が高くなったことに対応するために利用する。車速が高くなったため緊急制御に必要な検知対象距離は長くする必要がある。このため、必須機能が対象とする検知距離も長くするが、これを歩行者に割かれていた処理コストで補う。このため制御モードの起動タイミングにおいて、図９や図１０におけるステップＳ６を実行し、図７に示すようにタスクテーブルの変更処理を行う。高速モードにおける車線逸脱回避時のタスクテーブルの変更例を、図７のタスクテーブルに示す。このようにすることにより、走行環境に適したアプリを優先的に実行でき、安全性を向上できる。高速道路の走行の制御時においても必須機能に登録された、レーン認識１３０（必須版１１３０）、車両検知１５０（必須版１１５０）の２つは、常に動作させる機能とする。制御に利用される機能の優先度は保持するものの、付加機能部分は優先度を下げる、もしくは機能停止させることにより１サイクル分の時間を短くすることで、高精度の制御を可能にする。１サイクル分を短くした緊急モード時におけるタイミングチャートを図１３に示す。１サイクルを短くすることで、レーン認識１３０（必須版１１３０）によって算出されるヨー角、横位置の更新を早めることで、より高度な制御を行う。【００６７】
その他の場合についても、上記のタスクテーブル変更タイミングと同様の考え方をする。基本概念は図１７に示すように、制御や警告が発動される予測タイミングから所定値α前に、タスクテーブルの変更を行う。起動要因となった制御要因や必要とされる機能によって所定値αは変化する。又、通常時における１処理サイクルは長くなるが、付加機能が動作するために、多種類の検知結果（例えば標識や路面標識、オートライト１６０）などの情報が得られる。反対に、緊急時には１処理サイクルが短く、歩行者までの距離、レーンと車両相対位置などの情報の更新周期が早くなるかわりに付加機能に関する情報の更新が遅く、もしくは停止する。【００６８】
図２２に他の実施例を示す。他の図面と同じ符号は同じ機能および同じ動作を示す。この実施例は、カメラの計測装置１０１の中にタスクテーブルの処理機能も持たせたものであるが、上記処理機能は他の装置の制御用コンピュータで行っても良い。自車両の走行情報処理部１３０で、車速情報１３１や操舵角情報１３２を基にまた、必要に応じ画像情報やレーダ情報を使用して、先に説明した如く走行の環境や衝突の危険性、障害物や歩行者に対する注意の必要性を、先に説明した計算あるいは、予め走行状態に合せて記憶しておいたデータから、制御予測判断部１４２でタスクテーブルを選定する。例えば図２１のタスクテーブルを予め記憶されていた多くのタスクテーブルから選定する。ステップ２２１４において、先に説明したようにタスクテーブルに基づき、実行の優先度を判定し、優先度の高いタスクからステップ２２１６により実行する。実行対象のアプリは記憶部２２１６に記憶されているアプリである。この実行に基づき、新たな危険性が予測されると、あるいは走行環境の変化が検知されると、制御予測判断部１４２で、その予測や検知に対応したタスクテーブルを、予め記憶していた中から選択し、その選択されたタスクテーブルに従って、上述のステップ２２１４において優先的に実行すべきアプリが選定され、ステップ２２１６により選定したアプリが実行される。記憶しておいたタスクテーブルを制御予測判断部１４２でそのまま使用しても良いが、記憶されていたデータの一部を予測および検知内容に沿って変更しても良い。【００６９】
図２３や図２４は図１の変形性である。図１は計測装置１０１が画像などの処理部１００と一体となっているが、図２３の実施例では、制御・警告判断部３００を車両の他の装置と一体化したものであり、制御・警告判断部３００からの危険を運転者に伝える情報、あるいは運転を助ける情報を操作補助部３１０や表示警報部３２０、車両制御部３３０に伝え、これらの装置を介して運転者に連絡する。あるいは上記装置の制御に領する。図２４の実施の形態は処理部１００を車両制御の計算機により処理するものであり、処理内容は図２３と同じである。【００７０】
図２５はアプリの内容をさらに増やした例である。特に非周期実行アプリを記憶部の中の非周期部３１００に保持したことである。車両制御の開始時に必要となるアプリの中に一度実行すると運転中は実行しないアプリがある。これらのアプリは運転モードに基づいて実行される。運転モードに応じたタスクの選定を図２６に示す。タスクテーブルを決定するステップＳ３−２は、図９や図１０のステップＳ３やＳ３−１に対応する。エンジン制御装置やトランスミッションなど、自車両走行情報部２０１からの情報に基づき、運転開始状態であると、記憶されたタスクテーブルから図２５の非周期部のタスクすなわちアプリが選定され、次のステップＳ４／Ｓ５は特定の実行アプリが決められ実行されるステップＳ６で実行される。次のステップＳ４／Ｓ５は図９や図１０のステップＳ４やステップＳ５に対応し、機能や動作が同じである。【００７１】
次にエンジンや、車両駆動用回転電機を制御するインバータ装置が運転を開始すると、ステップＳ３−２は図２７に示す発進前タスクテーブルを選定する。ステップＳ４／Ｓ５以下の動作は同じである。車両が走行を開始すると、ステップＳ３−２は図２８に示すタスクテーブルを選定する。なお、図９や図１０に記載の如く、ステップＳ３−２で危険を感じると、ステップＳ３−２は図２９に示すタスクテーブルを選定する。このように車の運転開始から通常の走行状態に移るまで、車の状態に合せてタスクテーブルを切り換えることで、非常にきめ細かな制御が可能となり、安全性や快適性が向上する。【００７２】
また、運転者が経済性を優先した運転を望む場合には、ステップＳ３−２は図３０に示すタスクテーブルを選定する。経済性を優先した運転の好みをスイッチで確認してもよいが、エンジン制御装置やトランスミッションの情報に基づき、運転者の運転パターンを判断すると経済性を優先した運転を希望しているのか、スポーティな運転を好んでいるのかが判断でき、ステップＳ３−２で運転者の好みに合ったタスクテーブルを選定する。なお、スポーティな運転を好む場合は図３２に示すタスクテーブルがステップＳ３−２で選定される。また経済性を優先した運転を希望する場合であってもカメラ情報から、雨天や雪、濃霧の環境状態が検出されると、図３１に示すタスクテーブルがステップＳ３−２で選定される。このようにすることで、きめ細かい対応が可能となり、安全性が向上する。【００７３】
図３３はカメラ情報やナビ情報により、市街地の走行が検知された場合であり、運転環境に応じて、タスクテーブルがステップＳ３−２により切り替ることで、運転環境に合わせたアプリの実行が可能となり、安全性や快適性が向上する。【００７４】
図３４や図３５、図３６に記載のタスクテーブルは、図２６に示す、適用車両の型式や仕向け地に合せて、図２６のステップＳ３−２で、タスクテーブルを選択するものである。同じ車種においても、使用される仕向け地や型式により、実行すべきアプリが異なってくる。これらのプログラムを幾種類も数多く用意することは、いろいろ問題がある。従って同じ内容のアプリのプログラムを搭載しても、仕向け地の情報や型式の情報に基づき、適したアプリが選定されるようにすれば、アプリのプログラムを共有することが可能となる。【００７５】
図３８は、図１１から図１５で説明したタスクテーブルの設定方法あるいは、実行方法の代案である。図３８では、１サイクルを構成している実行タイミングＲごとにどのアプリを実行するかをきめ、サイクルの残りの実行タイミングＲでどのアプリを実行するのかを決める方式で、応答性を向上できる。今図３８の現在と記した実行タイミングＲを実行するものとする。この状態のタスクテーブルを図３７に示す。またこのときの制御フローを図３９に示す。図３８によれば既に歩行者検知（必須版）１１４０と車両検知（必須版）１１５０は実行が終了しており、図３７のタスクテーブルの実行状況欄にはこのサイクルでの実行状態が終了であることが表示されている。優先順位の欄では、歩行者検知（必須版）アプリ１１４０が最も優先順位が高く、次に車両検知（必須版）アプリ１１５０が優先順位が高い。その次に優先順位の高いアプリはレーン認識１３０（必須版）アプリ１１３０である。このアプリは今実行中であり、図３７のタスクテーブルの実行状態欄には、実行中の表示が出ている。有効フラグがＯＮ状態であるが、未だ実行されていないアプリは待機中の表示がセットされている。【００７６】
図３９のステップＳ１６でアプリが実行されると、次のステップＳ１２で実行状態が終了に変更される。さらに実行結果や自車両走行情報部２０１からの情報に基づきステップＳ１２で、テーブルの優先順位その他の変更の有無が見直される。ステップＳ１３で、１サイクルの残りの時間を考慮して、有効フラグがＯＮで処理が〔１／１〕のアプリの内待機アプリについて執行可能かをチェックする。次にステップＳ１４で待機中のアプリの内優先度の高いアプリを選定する。従って、レーン認識１３０（必須版）アプリ１１３０の実行が終了すると、ステップＳ１４では歩行者検知（付加版）２１４０が選択されて、実行されることになる。その次には、ステップＳ２でのタスクテーブルの実行条件に関する変更が無いものとすると、優先順位に従い車両検知（付加版）アプリ２１５０が実行されることとなる。このように実行タイミングＲ毎に、タスクテーブルの設定やタスクの選択が行われる。【００７７】
図３７でオートライトアプリ１６０や標識検知アプリ１７０は処理欄が１／５や１／３であり、実行周期を制御するカウンタがサイクル毎に計数を行い。オートライトアプリ１６０はカウンタの値が処理欄のサイクル数この場合サイクル数５に達すると定期状態となる。同様に標識検知アプリ１７０は実行周期を制御するカウント値が３に達するごとに初期値となり、そのとき待機状態となる。なお、もちろん有効フラグがＯＦＦに変更されると大気状態にはならない、このため有効フラグがＯＦＦ状態では実行されない。なお、図３９でアプリが実行される場合に、ステップＳ５で解像度欄に合せて情報の解像度が決められる。これは上述のとおり、不必要な解像度で処理することによる処理のための負荷を必要な値に抑制するためである。【００７８】
図４０は図３９の処理に加え車種や仕向け地の情報を考慮する機能を持つ、なお、当然の事ながらステップＳ１１では、図３９のＳ１１の機能も有しているが説明を省略する。図４０のステップＳ１１では、図３９のＳ１１の処理に加え仕向け地や、ＣＰＵやハード構成の違いを型式情報により判断し、タスクテーブルの組を選択し、加え仕向け地や型式情報にあわせた、タスクテーブル内容に変更する。次にステップＳ１２により市街地走行向けの車両かどうかに基づいてアプリの優先順位を変更する。ステップＳ１３で、想定車速や優先順位の高いアプリに応じた１サイクルの長さを変更、すなわち設定する。たとえば、市街地向け車両の場合には1サイクルの長さを長くし、スポーツタイプの車両の場合には1サイクル長さを短くする。【００７９】
車のハードが同じであっても、仕向け地変更の場合には優先順位やサイクルを構成する実行タイミングの数が異なってくる。例えば、北米は事故要因に車線逸脱が多いのでレーンの優先度が高くなるよう設定する。一方日本は歩行者車両の事故が多いので歩行者車両の優先度を高くする。また高速対応に重きを置くために、欧米の方が日本より、１サイクルの処理時間が短くなるように設定する。【００８０】
以上説明しましたように、上記の実施の形態では、タスクテーブルで各アプリの実行の有無や、実行の優先度、実行周期を制御できる。このため、車両の状態や、走行環境などにより、きめ細かく変更でき、安全性の向上を図れる。【００８１】
また、上記の実施の形態では、各アプリごとにプログラムを作成し、そのプログラムを、タスクテーブルの使用により複雑に組み合わせることが、可能となる。このため制御の質が向上する。【００８２】
また、プログラムの作成において、他のプログラムの実行条件をあまり考慮しなくても、システムを構築でき、アプリの生産性が著しく向上する。【００８３】
異常が発生した場合や、動作の確認を行う場合に、各アプリごとにタスクテーブルの有効フラグを変更することで、実行および実行停止を簡単に操作でき、確認操作が極めて容易となる。
【図１】
0005415434.tif 000002
【図２】
0005415434.tif 000003
【図３】
0005415434.tif 000004
【図４】
0005415434.tif 000005
【図５】
0005415434.tif 000006
【図６】
0005415434.tif 000007
【図７】
0005415434.tif 000008
【図８】
0005415434.tif 000009
【図９】
0005415434.tif 000010
【図１０】
0005415434.tif 000011
【図１１】
0005415434.tif 000012
【図１２】
0005415434.tif 000013
【図１３】
0005415434.tif 000014
【図１４】
0005415434.tif 000015
【図１５】
0005415434.tif 000016
【図１６】
0005415434.tif 000017
【図１７】
0005415434.tif 000018
【図１８】
0005415434.tif 000019
【図１９】
0005415434.tif 000020
【図２０】
0005415434.tif 000021
【図２１】
0005415434.tif 000022
【図２２】
0005415434.tif 000023
【図２３】
0005415434.tif 000024
【図２４】
0005415434.tif 000025
【図２５】
0005415434.tif 000026
【図２６】
0005415434.tif 000027
【図２７】
0005415434.tif 000028
【図２８】
0005415434.tif 000029
【図２９】
0005415434.tif 000030
【図３０】
0005415434.tif 000031
【図３１】
0005415434.tif 000032
【図３２】
0005415434.tif 000033
【図３３】
0005415434.tif 000034
【図３４】
0005415434.tif 000035
【図３５】
0005415434.tif 000036
【図３６】
0005415434.tif 000037
【図３７】
0005415434.tif 000038
【図３８】
0005415434.tif 000039
【図３９】
0005415434.tif 000040
【図４０】
0005415434.tif 000041