JP2011100338A - 車載用マルチアプリ実行装置 - Google Patents

Abstract

【課題】限られた処理能力のなかでリアルタイム性を損なうことなく複数のアプリケーションの動作保証を図り、打ち切り処理の発生を抑制することで利便性を保ちつつも安全性を確保することができる車載用マルチアプリ実行装置を提供すること。
【解決手段】車載用マルチアプリ実行装置は、各アプリの処理時間を動的に予測し、その予測した処理時間に基づいて各アプリのスケジューリングを行う。そして、スケジューリングを行った結果、規定周期内に処理が終了しないアプリケーションが存在すると判断した場合に、予め設定された優先順位に基づいて、アプリケーションの打ち切り、もしくはアプリケーションの機能を低下させる処理を行う。
【選択図】図１

Description

本発明は、例えば車載カメラ等の車載装置において複数のアプリケーションを実行する車載用マルチアプリ実行装置に関する。

車両走行に利用する情報を処理する装置において情報を的確に処理することが車両走行の安全性向上にとって重要である。近年、車両走行の安全性を高めようとするニーズがあり、情報処理装置における情報の処理量が多くなる傾向にある。車両の安全走行に関する情報の処理を、常に全て実行することは情報処理装置の負荷が大きくなり、対応速度の関係などで問題が出てくる。このため、規定周期内に処理が完了しないと判断した場合、次周期のＣＰＵ空き時間を上限として現周期に処理が完了しなかったアプリケーションのプログラムにＣＰＵ時間を割り当てることで、規定周期を保証しながら処理の打ち切りを抑制する技術が提案されている（例えば特許文献１を参照）。

特開２００９−８６７３３号公報

しかしながら、例えば車載カメラの画像認識を行うアプリケーションでは、現周期の処理が完了しなかった場合、次周期も負荷が高く空き時間が無い可能性が高い。このため、画像認識のアプリケーションでは、単に次周期のＣＰＵ空き時間を活用するだけでは、処理打ち切り抑制の効果は不十分であり、限られたＣＰＵ処理能力で、走行状況に合わせたマルチアプリケーションのスケジューリングが重要になると考える。

本発明は、上記の点に鑑みてなされたものであり、その目的とするところは、限られた処理能力のなかでリアルタイム性を損なうことなく複数のアプリケーションの動作保証を図り、打ち切り処理の発生を抑制することで利便性を保ちつつも安全性を確保することができる車載用マルチアプリ実行装置を提供することにある。

上記課題を解決する本発明の車載用マルチアプリ実行装置は、規定周期内に複数のアプリを実行する車載用マルチアプリ実行装置であって、各アプリの処理時間を動的に予測し、該予測した処理時間に基づいて各アプリのスケジューリングを行うことを特徴としている。

本発明の車載用マルチアプリ実行装置によれば、各アプリの処理時間を動的に予測し、該予測した処理時間に基づいて各アプリのスケジューリングを行うので、限られた処理能力でリアルタイム性を損なうことなく複数のアプリケーションプログラムの動作保証を図ることができ、打ち切り処理の発生を抑制することによって利便性を保ちつつも安全性を確保することができる。

本実施の形態における車載用マルチアプリ実行装置のブロック図。 車両制御部のブロック図。 走行環境情報部のブロック図。 マルチアプリ実行部のブロック図。 動的処理時間予測部のブロック図。 車両搭載のマルチアプリ実行装置の配置図。 一般道モードのタスクテーブルの一例を示す図。 高速道モードのタスクテーブルの一例を示す図。 従来のスケジューリングによる結果を示す図。 本実施の形態における車載用マルチアプリ実行方法を説明する処理フロー。 本実施の形態におけるスケジューリングの一例を説明する処理フロー。 本実施の形態におけるスケジューリングの他の一例を説明する処理フロー。 従来のスケジューリングの問題点を説明する図。 本実施の形態におけるスケジューリングの一例を説明する図。 本実施の形態における歩行者検出方法の一例を説明する図。 本実施の形態における車両検出方法の一例を説明する図。 本実施の形態における歩行者検出方法の他の一例を説明する図。 本実施の形態における機能小分割による並列処理の作用と効果を説明する図。 本実施の形態における処理周期を短縮するスケジューリングを説明する図。 本実施の形態における利便性を追加するスケジューリングを説明する図。 マルチコアにおけるスケジューリングの一例を説明する図。 マルチコアにおけるスケジューリングの一例を説明する図。 マルチコアにおけるスケジューリングの一例を説明する図。 車載用マルチアプリ実行装置の他の実施の形態を説明する図。 予測処理時間の算出方法を説明する図。 動的処理時間予測部のブロック図。 予測処理時間の算出方法を説明する図。 一般道モードのタスクテーブルの一例を示す図。 一般道モードのタスクテーブルの一例を示す図。 一般道モードのタスクテーブルの一例を示す図。

＜システム構成＞
図１は、本実施例における車載用マルチアプリ実行装置の機能ブロック図である。

車載用マルチアプリ実行装置１００は、車載の安全性もしくは利便性を向上するための認識を行う複数のアプリケーション（以下、単にアプリという）を規定周期内にリアルタイムで実施するものであり、本実施例では、車載用のカメラ装置内に一体に構成されている。

車載用マルチアプリ実行装置１００は、図１の機能別構成のブロック図に示すように、カメラ撮像部１０１、動的処理時間予測部１１１、マルチアプリ制御部（スケジューラ）１２１、マルチアプリ実行部１３１を備えている。

カメラ撮像部１０１は、自車周囲、もしくは車内を撮影し、動的処理時間予測部１１１は、規定周期ごとに各アプリの処理時間を予測する。リアルタイムに応答性を求められる車載用マルチアプリ実行装置１００は、予め設定された時間内に複数のアプリを実行する。この予め設定された時間を規定周期とする。

マルチアプリ制御部１２１は、動的処理時間予測部１１１によって動的に予測された予測処理時間を利用して、各アプリを安全性と利便性の観点から適切にスケジューリングする。スケジューリングでは、各アプリについて、実施の可否及び実施の順番が決定される。

マルチアプリ実行部１３１は、マルチアプリ制御部１２１のスケジューリング結果に基づいてアプリを実行する。マルチアプリ実行部１３１によって出力される結果は、車両制御部２５０にＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）経由で通信され、車両の安全性に関する、制御、警報、警告、表示などに利用される。

車両制御部２５０は、自車両の走行状況を把握しているとともに、ＣＡＮ経由で走行環境情報部２１０と通信し、自車走行環境に関する情報を得ている。これら車両制御部２５０の情報、走行環境情報部２１０の情報、マルチアプリ実行部１３１の情報より、動的処理時間予測部１１１は、次周期における各アプリの処理時間を予測する。

図２に車両制御部２５０の構成を示す。車両制御部２５０は、図２に示すような、車速センサ２６１、操舵角センサ２６２、ヨーレートセンサ２６３、アクチュエータ２６４、ブレーキ２６５、アクセル２６６、変速ギヤ２６７からなり、車両の走行状態を制御する。車両制御部２５０は、車両ＥＣＵ２６０を中心に車両の制御を行う。車両ＥＣＵ２６０は、ブレーキ２６５や、アクチュエータ２６４、アクセル２６６、ギヤ２６７を制御するとともに、車速センサ２６１、操舵角センサ２６２、ヨーレートセンサ２６３から現在の状態の情報を通信にて管理する。車両制御部２５０は、マルチアプリ実行部１３１の結果に応じて、安全のための制御、警告、警報、表示を実施する判断も行う。

走行環境情報部２１０は、図３に示すように、ウィンカー２１３、アプリ操作２１４、カーナビ２１５、レーダ２１６、路車間通信２１７、車々間通信２１８などから、車両走行には直接関係しない情報であって車両周囲の走行環境の状況を示す情報を得ている。車載用マルチアプリ実行装置１００の動的処理時間予測部１１１は、走行環境情報部２１０の結果を利用して、動的処理時間の予測を行っている。なお、図６は、車載用マルチアプリ実行装置１００を車両に搭載した配置例を模式的に示す図である。

図４は、マルチアプリ実行部１３１の詳細な構造を示すブロック図である。マルチアプリ実行部１３１は、全ての画像処理のアプリが機能別に登録されており、必須機能部１１００と付加機能部２１００の２つに分類された構造をもつ。マルチアプリ実行部１３１の機能は、図４に示すように、事故予防に直接的効果のある必須機能部１１００と、より快適な運転支援を主目的とする付加機能部２１００に分類される。

マルチアプリの処理負荷が高く規定周期内に処理が完了しないような場合にも、安全性確保のために動作保証したいアプリを必須機能部１１００として登録することで安全性を確保する。例えば、想定していた以上に歩行者候補や車両候補等がカメラ撮像部１０１の視野内に入った場合などには各アプリの処理時間が大きく伸びる。このように既定周期内に処理が完了しないような場合、既定周期を守るために処理の打ち切りを行うか、又は、規定周期の延長を容認している。

規定周期内に処理が完了せずに処理の打ち切りを実行すると安全性低下につながると考えて規定周期の延長を容認する安全性機能と、規定周期の延長よりも処理の打ち切りを実施して規定周期を厳守することがより安全性の確保に重要と考える付加機能とにアプリの種類を分類することで、安全性を保ちつつ、通常時の利便性を向上している。

規定周期を守るために処理を打ち切った場合、次周期まで結果が得られない他、次周期においても再度同一アプリに対して処理の打ち切りが発生する可能性がある。リアルタイム性を確保すべく規定周期を守ることだけに固執しては、安全性の観点から矛盾が生じる。そもそも処理の打ち切りが発生しないようなスケジューリングが望ましいほか、処理負荷が高い場合に、安全性のアプリに割り当てることのできるＣＰＵの空き時間が重要である。

処理負荷が高い場合など常に動作保証する必要はないが、通常走行時にドライバにとって有用な情報を提供するアプリを付加機能部２１００として登録することで利便性を追求する。利便性のための付加機能は、安全性のアプリの動作保証をするためのＣＰＵの空き時間マージンとして利用できる他、通常時はその利便性を有効活用することができる。

本実施例では、図４に示すように、レーン認識アプリ１３０、歩行者検知アプリ１４０、車両検知アプリ１５０について、必須機能部１１００と付加機能部２１００に分類して登録することで、安全性を重視した設計を可能にするとともに利便性の両立を行う。そして、オートライトアプリ１６０、標識検知アプリ１７０、路面標識検知アプリ１８０については、付加機能部２１００のみに登録している。

レーン認識アプリ１３０は、カメラ撮像部１０１によって撮影された画像から道路の白線ＷＬを認識する画像処理機能を有する。レーン認識アプリ１３０は、予防安全に直接効果が期待される車線逸脱防止に必要な車線内における自車両の横位置、ヨー角を推定することが可能な必須版アプリ１１３０を必須機能部１１００に分類する。そして、カーブより遠方の白線ＷＬの状況を検知対象とし、カーブ進入前における減速やカーブ時における操舵支援など快適な走行に効果が期待される付加版アプリ２１３０を付加機能部２１００として分割する。

このようにレーン認識アプリ１３０のうち、安全性に直接関係のある車線逸脱防止のための認識機能を必須版アプリ１１３０として必須機能部１１０に分類し、利便性に関連するカーブ進入前減速のための認識機能を付加版アプリ２１３０として付加機能部２１００に分類する。処理負荷の高いアプリケーションが想定した処理時間内に処理が完了しないような場合に、利便性に関連するアプリの処理を停止もしくは性能劣化させて実施することで、規定周期の保証を行うとともに、安全性に関わる処理の打ち切りを抑制し、より高い安全性を実現する。

歩行者検知アプリ１４０も、車速に応じた制動距離を考慮し衝突回避可能な距離に対して動作保証する必須版アプリ１１４０と、より遠方での歩行者候補に対しても検知処理を行う付加版アプリ２１４０に分類される。安全性確保のための必須版アプリ１１４０では、歩行者がある程度近距離にいることを想定しているため、高解像度の画像を利用するよりも、ある程度の解像度の画像を利用し、検知結果の更新周期をより早めることを重視した設定とする。そして、歩行者検知アプリ１４０の付加版アプリ２１４０では、より遠方の歩行者を対象とするために、高解像度の画像を利用する。

車両検知アプリ１５０も、先行車両との相対速度や距離、自車舵角を考慮し衝突を回避するために必要な車両候補に対して画像処理を行う必須版アプリ１１５０と、より早期な車両の検知や検知率の向上、車間距離制御などを目的により遠方の車両を検知対象とする付加版アプリ２１５０に分類される。解像度や処理周期に関する方針は、歩行者検知アプリ１４０と同様である。

歩行者検知アプリ１４０や車両検知アプリ１５０は、衝突回避のための認識処理を必須版アプリ１１４０、１１５０に分類し、車両制御には直接利用しない遠方などの認識を付加版アプリ２１４０、２１５０に分類することで、機能別の処理周期制御や機能のＯＮ、ＯＦＦを実現する。このように各アプリを機能別に必須機能部１１００と付加機能部２１００に分類することで、処理負荷が高く規定周期内に処理が完了しそうに無い場合に、付加版アプリの機能はその処理を停止、もしくは精度劣化させることで処理負荷を軽減させ、規定周期内に処理が完了するようにすることができる。従って、リアルタイム性を保証し、より安全性を高めるとともに、通常時の利便性を確保することができる。

オートライトアプリ１６０は、カメラ撮像部１０１で車外を撮像した画像の画像認識を行うことにより外界の明るさを検知し、ヘッドライトのＯＮ、ＯＦＦや方向を制御する。先行車の検知と併用することで、ハイビームとロービームの制御を行う。レーン認識アプリ１３０、もしくは車両制御部２５０の車速センサ２６１と舵角センサ２６２からの自車両予測進路、もしくはカーナビ２１５からの自車両予測進路と併用することでカーブ方向へヘッドライトの照射角度の制御を行う。更に路面標識検知１８０と併用することで、交差点における照射角度の制御などに利用する。オートライトアプリ１６０は、より快適な運転支援を目的としており、このアプリ全体を付加機能部２１００に分類する。

標識検知アプリ１７０は、制限速度などの道路標識の検知を行い、この情報をドライバに提供することで快適な運転支援を目的とするため、このアプリ全体を付加機能部２１００に分類する。

路面標識検知アプリ１８０は、路面上の制限速度表示などの検知や、横断歩道を検知することにより、ナビ位置情報の高精度化などのドライバへの運転支援の情報を検知する機能のため、このアプリ全体を付加機能部２１００に分類する。

図５に、動的処理時間予測部のブロック図を示す。動的処理時間予測部１１１では、動的処理時間予測制御部１１２にて各アプリ機能別に予測に利用する情報を、走行環境情報部２１０、マルチアプリ実行部１３１、車両制御部２５０の中から選択し、その選択した情報を各機能の動的予測部３１３０−３１５０、４１３０−４１８０に送信する。各機能の動的予測部３１３０−３１５０、４１３０−４１８０は、動的処理時間予測制御部１１２から得られた情報に基づいて、次フレームにおける処理時間を予測する。

＜タスクテーブル＞
マルチアプリ制御部１２１は、タスクテーブルをベースにして基本のスケジューリングを行い、動的処理時間予測部１１１で予測した予測処理時間を利用してスケジューリングの内容を修正する。打ち切り処理の対応や、低負荷時における利便性機能の追加などは、予測処理時間を利用した上で修正される。

図７は、一般道路の走行時に使用されるタスクテーブルを示し、図８は、高速道路の走行時に使用されるタスクテーブルを示す。タスクテーブルは、図７及び図８に示すように、各アプリを分類して縦軸に並べると共に、設定項目を横軸に並べており、各アプリを設定項目別に制御するようになっている。タスクテーブルにて設定する各項目の内容について以下に説明する。

有効フラグとは、一般道路を走行する一般道モードや、高速道路を走行する高速モード等から選択されたモードにて、アプリを動作すべきか否か、換言すると、アプリの実行の可否を判定するためのフラグであり、ＯＮで動作、ＯＦＦで停止を意味する。

レーン認識アプリ１３０、歩行者検知アプリ１４０、車両検知アプリ１５０は、必須機能部１１００と付加機能部２１００からなるアプリケーションであり、必須機能部１１００の有効フラグがＯＦＦの場合、同一アプリの付加機能部２１００の有効フラグは必ずＯＦＦとするように設定されている。

例えば、レーン認識アプリ１３０の必須版アプリ１１３０が有効フラグＯＦＦで動作停止した状態において、レーン認識１３０の付加版アプリ２１３０のみが有効フラグＯＮであり動作するということはない。必須機能部１１００がＯＮの場合には、付加機能部２１００に属するアプリは、状況に応じて制御する。

必須機能部１１００のＯＮ、ＯＦＦは、現在高速道路を走行中なのか、一般道を走行中なのか等の車両制御部２５０の自車両走行情報に基づいてモード設定を行う際に、変更される。例えば、高速道路を走行中は、歩行者は高速道路にいないとの仮定より、歩行者検知機能を動かすよりも他機能にプロセッサ処理を割り当てた方が、ドライバにとって快適で安全な運転ができると考え、歩行者検知アプリ全体をＯＦＦとし、他機能の処理の優先や、高速移動時における１サイクル分の処理時間を短くするためにアプリのＯＮ、ＯＦＦを制御する。また、この他、カーナビゲーションのモニタ画面からユーザが選択するような方法でＯＮ、ＯＦＦを変更しても良い。

付加機能部２１００のＯＮ、ＯＦＦは、車両制御部２５０からの自車両走行情報及びアプリからの認識情報に基づいて制御される。また、動的処理時間予測部１１１で動的に予測した各アプリの予測処理時間の長さが、既定周期内に終了しない場合には、既定周期内に処理が完了するように、優先順位の低い付加版からＯＦＦにすることによって、既定周期を守るようにスケジューリングする。また、処理対象の画像の解像度を低下させて、認識精度を劣化させる簡易的な手法により、リアルタイム性を確保しかつ安全性も確保してもよい。

優先順位とは、複数のアプリを実行する場合の優先順位を示し、数字が小さい方が優先度の高いアプリであることを示す。例えば、歩行者検知アプリ１４０で、ブレーキの制御が必要となるような歩行者候補を発見し、更に歩行者検知の処理時間が長くなったような場合、歩行者検知機能よりも優先順位が低い付加版の処理を、優先順位が低い順に停止する。このように優先順位にしたがって順番にアプリの停止などを試みることで、安全性と利便性をできる限り両立する。

割当コア（ＣＰＵ）とは、マルチコア、もしくはマルチＣＰＵを利用する場合において、各機能別に担当するコア（ＣＰＵ）の割当を指定する場合に利用する。コアの数が増えた場合などには、一つの機能に対して複数コア（ＣＰＵ）の割当を行うような場合にも、このタスクテーブルの設定内容を利用する。処理時間の予測結果に応じて動的にＣＰＵの割当を変える場合には、タスクテーブルの設定内容を書き換える。シングルコアもしくは、シングルＣＰＵの場合、もしくはマルチコア、もしくはマルチＣＰＵであっても機能別にＣＰＵの担当を決めずに、対称的、均一的に処理を割り当てる並列処理方式ＳＭＰの場合には、割当コアを全て１とし、明示的に各コア（ＣＰＵ）に対して機能を割り当てない。

処理とは、複数のアプリの処理が完了する規定周期におけるアプリの処理回数を示す。本画像処理装置における規定周期とは、例えば図９に示すような、一連の処理１回分のループを示す。同一の機能でも、優先度が低くなるにつれて処理回数が小さくなるような設計とする。例えば図７に記載されているレーン認識アプリ１３０の必須版アプリ１１３０の処理［１／１］とは、１サイクルに１回、アプリが実行されることを意味する。また、付加機能部２１００のオートライトアプリ１６０の処理［１／３］とは、３サイクル中に１回、アプリが実行されることを意味する。

予測処理時間に基づき、既定周期内に全てのアプリの処理が完了しそうにないと判断した場合に、まず優先度が低く、処理回数が低くても問題の生じない、処理回数の低いアプリから削ることで、優先度の高いアプリの実施が確保され、リアルタイム性が確保されて安全性が確保される場合が多い。

例えば、レーン認識１３０の曲率算出部分の機能などは、道路が急に曲率が変化することがないことを考慮すると、必ずしも高い処理周期である必要はない。高い処理周期であれば精度は良くなるが、他に優先する処理があるような場合には、［１／２］で処理しても問題がない。そこで優先する機能がある場合における調整項目として処理周期の変更などが利用される。

又、歩行者検知アプリ１４０の付加版アプリ２１４０、車両検知アプリ１５０の付加版アプリ２１５０、標識検知アプリ１７０、路面標識検知アプリ１８０などの場合は、処理周期が低くなると、検知タイミングが多少遅くなり、検知距離内に入ってからの認識処理回数が少なくなって、検知率が多少低下することが考えられるが、この検知率の低下よりも重要なアプリがある場合に、処理周期の調整にて優先事項の処理周期が早く、非優先事項については処理周期が遅くなるように調整される。カーブ中の速度抑制などの制御中には、標識検知アプリ１７０や、路面標識の検知率が多少下がるよりも減速制御のためのカーブ認識を高い周期で行う場合には重要となる。

解像度とは、画像認識に利用する入力画像のサイズを示す。カメラ撮像部１０１で撮像される画像の最大解像度を［１、１］と示す。［ａ、ｂ］の表記方法は、ａが画像横方向の解像度、ｂが画像縦方向の解像度を示す。例えば、最大解像度７６８×２４０の場合に、入力画像として２５６×２４０の画像入力とするレーン認識アプリ１３０の必須版アプリ１１３０の解像度は［１／３、１／２］と示し、横解像度が最大解像度の１／３、縦解像度が最大解像度の１／２であることを示す。

予測処理時間に基づき、既定周期内に全てのアプリが完了しそうにないと判断された場合には、解像度を低下させて処理時間を削減する処理を行う。解像度の低下により認識対象が近傍までになる制限がつくほか、解像度低下に伴う処理負荷低減により処理時間の削減が可能であり、性能劣化はするが応答性の確保しながらリアルタイム性を確保し、より安全で快適な車両の構築が必須となる。

レーン認識アプリ１３０や歩行者検知アプリ１４０において、検出結果の位置精度を重要視する場合や、より遠方を検知対象とする場合、高解像度の画像を利用することが望ましい。しかし、高解像度画像を利用することによる計算コストの増加が処理周期に影響を与える。したがって、検知位置精度、検知対象距離、処理周期などの条件に応じて解像度を調整する。

例えば、車線逸脱回避を想定した場合には、車両に対するレーンの横位置やヨー角にある程度の認識精度は必要とするものの、遠方の曲率値や車線逸脱予測位置より遠方のレーン位置などはあまり重要でない。車線逸脱回避のために車両制御するような状況では、低解像度な画像を利用し処理コストを削減することで、車両制御に利用されるレーン横位置やヨー角の更新周期を早め、より高度な車両制御を実現する。

検知距離とは、自車から各アプリが認識対象とする対象のうち最遠方のものまでの距離を示す。例えば、通常モードにおける歩行者検知アプリ１４０の必須版アプリ１１４０の検知距離が４０メートル［ｍ］であるとは、４０メートル［ｍ］より遠方にいる歩行者については検知対象外とすることを意味する。

歩行者検知アプリ１４０でいえば近傍に衝突可能性の高い歩行者が認識され、車両制御が必要と予測されるような場合に、車両制御の対象範囲外の遠方を検知することは重要ではない。したがって、遠方のものを対象からはずすことで処理コストを削減し、歩行者位置を高フレームレートで更新し、より高度な衝突回避制御を可能とする。また検知距離も遠いほど処理時間がかかるため、動的処理時間の予測に基づいて、検知距離を変更することで、処理時間の調整を行い、リアルタイム性を確保する。

初期処理時間とは、アプリのスケジューリングの際に利用する固定値の処理時間であり、動的処理時間の予測が失敗したときや、予測処理時間が利用できないような場合に利用する処理時間である。タスクテーブル生成時や、ユーザの選択によりどのアプリを動かすかを選択する際に、決められた規定周期内に処理が終了するかどうかなどの目安として利用し、これを基に、規定周期内に処理が完了するようなマルチアプリ構成となっているかチェックすることに利用できる。

予測処理時間とは、毎規定周期ごと、もしくはイベント成立時などに各アプリ機能別に処理が完了するために必要な時間を予測した時間である。歩行者検知などでは、レーダ２６１の検知情報等を利用し、処理完了に必要な時間を予測する。この予測された処理時間を利用して、タスクのスケジューリングに利用する。

＜全体処理フロー説明＞
次に、本実施の形態における車載用マルチアプリ実行装置の全体処理について、図１０の処理フローを用いて説明する。

ステップＳ０では、車両制御状態や、マルチアプリの実行状態等の情報がフィードバッグされる。これらの情報は、処理時間の予測に利用する情報の一部である。車両制御部２５０の情報は、タスクテーブルの変更や、処理時間の予測に利用する。マルチアプリの実行状態は、認識結果とともに、処理時間の予測に利用する。例えばレーン認識の場合には、次周期のレーン認識を行うための処理領域の大きさを情報としてフィードバックすることで処理時間を予測する。

ステップＳ１では、走行環境情報を取得する処理がなされる。ここでは、図３に示すウィンカー２１３、アプリ操作２１４、カーナビ２１５、レーダ２１６、路車間通信２１７、車々間通信２１８より走行環境の情報を取得する。これらの情報は、動的処理時間の予測や、タスクテーブルの変更に利用される。

ステップＳ２では、動的処理時間を予測する処理がなされる。ここでは、ステップＳ０で得られた車両走行状態やマルチアプリ実行結果や実行状態の情報と、ステップＳ１で得られた走行環境情報を利用して、タスクテーブルにおいて有効フラグがＯＮとなっている各アプリの処理時間を予測する。

ステップＳ３では、スケジューリングが行われる。スケジューリングは、ステップＳ０から得られる車両制御状態やマルチアプリの実行結果、実行状態の情報、ステップＳ１で得られた走行環境情報、ステップＳ２で予測した結果である予測処理時間、及びタスクテーブルに基づいて行われる。

ステップＳ４では、タスクテーブルの修正処理が行われる。ここでは、ステップＳ３のスケジューリングの結果に基づいて、タスクテーブルの内容に変更の必要があるか否かが判断され、変更の必要があると判断された場合に、タスクテーブルの修正がなされる。

ステップＳ５では、カメラ撮像部１０１で撮像した画像を取得する処理がなされる。ステップＳ６では、ステップＳ３で得られたスケジューリングの結果と、ステップＳ４で得られたタスクテーブルの結果に基づいて、マルチアプリを実行する処理が行われる。ステップＳ７では、ステップＳ６のアプリ実行結果に基づいて、車両制御が実施される。

なお、ステップＳ３、Ｓ４については、同時に実施するような方法でも良い。例えば、有効フラグ、優先順位、処理、解像度、検知距離など大まかにタスクテーブルを決定した後に、スケジューリングしながらタスクテーブルの内容に変更を加えるような方法でも良い。

または、ステップＳ２、Ｓ３、Ｓ４を同時に実施するような方法でも良い。例えば、タスクテーブルの優先順位順に処理時間を予測し、その予測結果に基づいてスケジューリングを行う。そして、アプリが既定周期内に入りきらなくなった状況で、再度タスクテーブルの有効フラグ、処理周期、解像度、検知距離の見直しを行った上で、スケジューリングの再考を行うような方法でも良い。

＜スケジューリング詳細処理フロー＞
次に、図１０のステップＳ３における処理の内容について図１１、図１２を用いて詳細に説明する。図１１は、スケジューリングの方法の一例を詳細に説明する処理フローである。ここでは、車載用マルチアプリ実行装置１００の演算手段がシングルコアもしくはシングルＣＰＵである場合を例に説明する。

ステップＳ２で動的処理時間の予測が行われると、ステップＳ３に移行し、ステップＳ３で、予測された処理時間とタスクテーブルに示された優先順位とに基づいてスケジューリングが行われる。より詳細には、ステップＳ３１で、タスクテーブルにおいて有効とされた複数のアプリの処理時間をスケジューリングした場合に、既定周期内に処理が完了しないアプリが存在するか否かを調査する。

そして、規定周期内に処理が未完となるアプリが存在する予測された場合は（ステップＳ３１でＹｅｓ）、情報の処理量を減らすべく、ステップＳ３４に移行する。ステップＳ３４では、タスクテーブルで有効と判断されたアプリの精度劣化による処理時間の短縮や、アプリの停止を検討する。そして、不足処理時間分のＣＰＵ負荷を削減するために、タスクテーブルの優先順位の低いアプリから、及び予測した処理時間の長さに基づいて、不足処理時間分のアプリ削減、もしくは不足処理時間分の精度劣化を実施する。

そして、ステップＳ３５では、ステップＳ３４、Ｓ３８にて決定されたスケジューリングに従い、スケジューリングテーブル（スケジュール）を決定する。そして、全ての利便性のアプリ（付加機能部２１００の処理）を停止しても既定周期内に処理が完了しない場合に、初めて処理周期の延長を検討し、スケジュールの修正を行う。または、安全性のアプリ（必須機能部１１００の処理）であっても、既定周期より大幅に処理時間が伸びることが予測されるような場合には、打ち切り処理を実行し、次の既定周期で実施してもよい。

システムのリアルタイムな応答が重要となる車載の認識アプリでは、検知距離なども重要な要素であるが、検知周期も重要な要素となる。この認識結果が最大何ｍｓｅｃ前の結果であるということを前提とした車両制御や、処理周期何フレームで得られる実行結果だと想定して作られた車両制御の場合に、この規定周期を守ることが安全性確保にも重要であることがわかる。

一方、規定周期内に各アプリの処理が全て完了すると予測された場合は（ステップＳ３１でＮＯ）、ステップＳ３７に移行し、ＣＰＵ空き時間が多いかどうかを判定する。そして、ＣＰＵ空き時間が多いと判定された場合は（ステップＳ３７でＹｅｓ）、より高い利便性の実現を図るべく、ステップＳ３８に移行し、空き時間中に処理が完了できる範囲内で利便性機能（付加版アプリ２１３０〜２１５０や、オートライトアプリ１６０等）の追加を検討する。そして、ステップＳ３７において、連続してＣＰＵに空き時間があると判断された場合には、ステップＳ３８で処理周期自体を短縮することも検討する。これにより、より高い安全性や、認識精度を実現することができる。

また、ＣＰＵ空き時間が少ないと判定された場合は（ステップＳ３７でＮｏ）、既に最適なスケジューリングであると判定し、そのまま処理を実行すべく、ステップＳ５に移行する。

図１２は、図１０のステップＳ３におけるスケジューリングの方法の他の一例を説明する処理フローである。ここでは、車載用マルチアプリ実行装置１００の演算手段がマルチコアもしくはマルチＣＰＵである場合を例に説明する。なお、図１１と同様の内容を有するステップには同一の符号を付することでその詳細な説明を省略する。

ステップＳ３１において、規定周期内に処理が未完と予測された場合は（ステップＳ３１でＹｅｓ）、ステップＳ３２に移行し、他のコアや他のＣＰＵ、或いは専用ハード等に、処理の空き時間が存在しないかを調査する。そして、空き時間が存在すると判断された場合には、各アプリのコア（ＣＰＵ）割り当て変更できるか否か、もしくは、処理時間の長い機能は、並列処理の実施により既定周期内に全ての機能が完了するか否かを調査判定する。そして、安全性の機能と優先順位の高いアプリから処理が完了するように、コア割当変更や並列処理によるスケジューリングを行う。

ステップＳ３３では、ＣＰＵ割り当ての変更、並列処理のみで既定周期内に各アプリの処理が完了するか否かを判断し、処理が未完となると判断された場合（Ｙｅｓ）には、情報の処理量を減らすべく、ステップＳ３４に移行する。また、処理が完了すると判断された場合（Ｎｏ）には、ステップＳ３７に移行する。ステップＳ３５では、ステップＳ３２、Ｓ３４、Ｓ３８にて決定されたスケジューリングに従い、スケジュールを決定する。

そして、ステップＳ３７において、ＣＰＵ空き時間が少ないと判定された場合（Ｎｏ）には、既に最適なスケジューリングであると判定してそのまま実行する。また、有効フラグがＯＦＦになっている停止機能を含めて再スタートさせるとどの程度の処理時間がかかるか予測したうえで、全処理時間を予測し、先に走行環境モード選択もしくはナビからのアプリ操作によって決められたタスクテーブルをベースに優先順位が高い順にスケジューリングしてもよい。

最後の規定処理周期の終了時をまたいで実行する機能が存在する時点で、そのアプリの優先順位と動的処理時間予測結果から、スケジュールに修正を加える。これにより、既定処理周期内にそもそも完了しないことがわかっていながらただ処理を実行して打ち切り処理を発生させることをせず、打ち切り処理が発生しないアプリで且つ優先順位は低いが処理時間が短いアプリを追加するなど対策をとり、利便性の追加を図っても良い。

なお、利用画像の違いなどから、連続実行させた方が都合の良いアプリなどが存在するため、優先順位の高さのみでスケジューリングが難しい場合もある。このような場合には、動的処理時間の予測結果を求めてスケジューリングした後に、再度、どのアプリを有効とするかを再判定し、スケジューリングを最初からやり直すような手法でも良い。

＜処理時間の予測方法＞
次に、図１０のステップＳ２における動的処理時間の予測方法について、アプリケーション別に詳細を記す。歩行者検知アプリ１４０、車両検知アプリ１５０、レーン認識アプリ１３０の順番で説明する。

例えば、歩行者検知アプリ１４０の場合、レーダ２１６とカメラ装置を併用するフュージョン方式と、カメラ装置のみとレーダ２１６のみの方式がある。フュージョン方式では、レーダ２１６によりレーダ視野内に存在する歩行者候補を検知し、この歩行者候補に対応する画像領域のみ画像処理している。このため、歩行者候補が存在しないような場合には、画像処理負荷が発生せず処理負荷が非常に小さくなる。反対に、歩行者候補が多い場合などは、歩行者候補が存在すると思われる画像領域が多数存在するために、画像処理負荷が高くなる。

このように画像処理量がレーダの結果より推定可能なため、処理時間の見積もり（処理時間の予測）が正確に行える。歩行者候補の増減に応じて、処理時間の増減が非常に大きいため、処理時間の動的予測結果を利用したスケジューリングにより、処理時間増加による処理周期遅延の抑制などに効果がある。特に、処理時間が長く、その増減が激しいアプリの処理時間を正確に予測することができれば、処理時間の増減に応じたスケジューリングをコントロールできる。

このため、動的処理時間の予測は全てのアプリに対して行わなくても良く、処理時間の長さがほぼ一定、もしくは処理時間が短い処理は、固定の処理時間を基にスケジューリングすることとし、歩行者検知のように処理時間の増減が激しい処理を対象とすると、動的予測した効果が高い。処理負荷が高く、処理時間が長くなるような場合には、優先順位の低い処理から処理停止、もしくは精度劣化、検知距離の短縮、処理レートの低下等により打ち切り処理の抑制を実施し、マルチアプリの規定処理周期を守るようにスケジューリングすることでリアルタイム性を維持し、より安全性を高める。反対に、処理時間が短い場合には、効率的に他利便機能の動作を可能とし、より利便性を高める効果がある。

フュージョン方式において、上記のレーダ２１６の結果から画像処理領域を絞り込むような手法ではなく、画像認識結果と、レーダ２１６の認識結果をフュージョンするような手法では、画像処理負荷部分は、カメラ装置のみの方式と同じ処理時間予測方法となり、効果も同様といえる。

また、カメラ装置のみの方式の場合、過去の認識結果をベースとして、自車速でその歩行者に近づいた際の画面上での大きさを予測し、その大きさに基づいて次処理周期における画像処理の負荷を推定し、処理時間を予測する。更に、新たに視野内に入る歩行者に割り当てるために、猶予時間を加える。

フュージョン方式と比較して、処理時間予測精度は劣化し、猶予時間を常に加えたスケジューリングとなるため、処理時間ほぼゼロのようなスケジューリングは困難となり、上記フュージョン方式と比較し効果は小さくなるものの、上記と同じように、動的予測結果を利用したスケジューリングにより、処理時間増加に応じて、優先順位の低い処理から処理停止、精度劣化による打ち切り処理の抑制、処理周期遅延の抑制などに効果がある。また、処理時間が非常に短い場合には、効率的に他の利便機能の動作を可能とし、より利便性を高める効果がある。また、このような処理時間の予測はレーダ２１６による歩行者検知で行っても同様の効果が得られる。

なお、車両検知アプリ１５０も歩行者検知アプリ１４０と同様に、フュージョン方式とカメラ装置のみの方式にわかれる。処理時間の予測や効果についてもほぼ同様のため、詳細は省く。

次に、レーン認識アプリ１３０の場合における処理時間の予測方法について説明する。レーン認識アプリ１３０の処理時間は、処理領域の大きさに影響を受ける。処理領域内に存在するレーンマーク（路面上の白線ＷＬ）がどのような傾きでどのような位置に存在するかを探索するための直線抽出処理が、特に処理時間の大きなウェイトを占める。

処理領域が多いほど、直線が存在する位置や傾きの可能性が増え、それに伴い処理時間が増加する。処理領域は、前回の認識結果を基にして次既定周期の処理領域を設定するため、次既定周期に設定する処理領域の大きさを情報として処理時間を予測する。なお、道路状況は急変することは少ないことから、過去の処理時間から次既定周期の処理時間を推定しても良い。もしくは、車両に搭載されたカーナビゲーションシステム（以下、単にナビという）の地図情報より、車線種別や道路環境に関する情報を取得し、これらの結果より処理時間を予測する手法でも良い。また、ナビの記憶装置を利用して、地図情報に照らし合わせて、以前に走った場合の処理時間を記憶装置に記録し、次回走行する場合には処理時間の予測に利用するような手法でも良い。

レーン認識アプリ１３０によるレーンの認識結果は、車両制御に利用されるので、制御の遅れなどが重要な問題となる。したがって、処理時間を予測して、レーン認識アプリ１３０が規定処理時間内に収まるようにスケジューリングし、安全な車線逸脱防止制御を実施する。

次に、オートライトアプリ１６０、標識検知アプリ１７０、路面標識検知アプリ１８０の場合における動的処理時間の予測方法についてそれぞれ説明する。オートライトアプリ１６０の場合、レーダ２１６の検知情報と組みあわせたフュージョン方式をとることで、車両候補が存在すると思われる処理領域に限定し、ライトを検知する処理時間を予測する。オートライトの画像処理では、処理時間が大きく変化することが少ないと考え、過去の処理時間より、次の周期における処理時間を予測しても良い。

標識検知アプリ１７０及び路面標識検知アプリ１８０の場合は、ナビの地図情報から路面標識や標識の位置情報を得て、路面標識や標識が撮像されると推定されるタイミングには、処理時間が多くかかりそうだと推定を行っても良い。また、認識後は、次既定周期に再度認識する標識が画像上でどのような大きさに撮像されるかを車速や操舵情報より推定し、処理時間を更に正確に推定しても良い。また、上記の場合、自車両走行時における処理時間をナビの地図情報に合わせて記録された結果を基に処理時間の予測を行っても良い。

標識検知アプリ１７０及び路面標識検知アプリ１８０の場合は、画像処理の処理時間が大きく変化することが少ないと考え、過去の処理時間より、次の周期における処理時間を予測してもよい。

その他のアプリとして、例えば駐車枠検知アプリの場合は、一度処理すると次既定周期の処理時間と大きく処理時間が変化することは少ないことから、過去の処理時間を基に次既定周期の処理時間を予測するような手法でも良い。

また、車室内の居眠り検知アプリの場合は、処理自体にモードを持たせ、居眠りしているのか怪しい場合にのみ、処理負荷が高くなるようにモード変更しても良く、このモード状態から処理時間の予測を行ってもよい。また、運転者の操舵やアクセル、ブレーキング操作に応じて、居眠り検知アプリにおける処理モードを変更するとともに、処理モードに応じた処理時間の予測を行っても良い。

窓のくもり検知アプリの場合は、湿度に基づいて窓のくもり検知の処理時間を予測しても良く、また、雨滴検知などの検知結果に基づいて予測しても良い。更に、温度計による計測結果に基づいて、雪検知か雨検知か処理を判断するとともに処理時間を予測しても良い。

＜打ち切り処理＞
次に、打ち切り処理の方法について以下に詳細に説明する。図１３は、従来のスケジューリングの問題点を説明する図であり、図１３（ａ）は、打ち切り処理により規定周期を保証する手法を示し、図１３（ｂ）は、スケジューリングされた各アプリが終了するまで周期を延長する手法を示すものである。そして、図１４は、本実施の形態におけるスケジューリングの方法を説明する図であり、図１４（ａ）は、優先順位に基づいて付加機能部のアプリを停止して規定周期を保証する手法を示し、図１４（ｂ）は、周期の延長を規定値まで許容する手法を示すものである。

従来手法では、図９に示すように固定で割り当てられた図７の初期処理時間に基づいて、各機能のスケジューリングを行っていた。しかしながら、上記の初期処理時間よりもある機能の処理時間が伸びてしまった場合には、様々な問題があった。例えば、既定処理周期を保証するために、打ち切り処理を実施する対策もあるが、図１３（ａ）に示す車両検知アプリ１５０のように、途中で処理が打ち切られたアプリはその結果が得られないほか、標識検知アプリ１７０のように、その後に処理予定であった例えば標識検知アプリ１７０などのアプリも実行もされずに、次の周期に入るような結果となる。

また、図１３（ｂ）に示すように、全てのアプリの処理が終了するまで周期を延長するような従来手法の場合には、既定周期が守られず、リアルタイム性に問題が生じていた。
他の従来手法として、規定周期を守るために、優先順位順に機能をスケジューリングし、優先順位の低い処理を打ち切りする方法もあるが、現周期の処理時間の長さを考慮しない打ち切り処理であった。

このため、例えば図１３（ａ）に示す車両検知アプリ１５０の必須版アプリ１１５０のように、規定周期の終了間際に、処理時間の長いアプリが実行された場合に、結果、打ち切り処理が発生し、車両検知アプリ１５０の必須版アプリ１１５０、付加版アプリ２１５０、標識検知アプリ１７０のいずれの結果も得られないようなスケジューリングになっていた。

このような従来手法では、予防安全のための車載アプリケーションに利用するには問題がある。したがって、リアルタイム性を確保しながらも、利便性を確保できるようなスケジューリングが望ましい。図１３（ａ）に示すようなケースの場合は、そもそも安全性機能が実行されるべきであるが、歩行者検知アプリ１４０や車両検知アプリ１５０が想定していた固定処理時間分よりも実際の処理時間が長かったために、車両検知アプリ１５０の必須版アプリ１１５０の処理までもが打ち切りになるという問題がある。

これに対して、本実施例では、図７のタスクテーブルと予測処理時間を利用してスケジューリングする。したがって、優先順位を考慮すれば歩行者検知アプリ１４０の必須版アプリ１１４０、車両検知アプリ１５０の必須版アプリ１１５０、レーン認識アプリ１３０の必須版アプリ１１３０及び付加版アプリ２１３０の次に、歩行者検知（付加）２１４０を実施したいが、すでに規定周期内に処理が終了しないことが動的処理時間の予測をしていれば前もって判定可能である。

このような場合、図１３（ａ）に示す車両検知アプリ１５０のように、アプリの処理が終了せず打ち切り処理が発生するようであれば、処理が規定周期内に完了する機能の中で、次に優先度の高い、車両検知（付加）２１５０をスケジューリングすべきである。

ただし、図１３、１４では、優先順位の高さだけでなく、同じアプリケーションはできる限り連続して処理するようなスケジューリングとした。これは、同一アプリケーションをデータ依存関係の少ない処理に細かく分割しても、他アプリを実行することと比較すれば共有する情報が多く、情報の退避や復帰などまで考慮すると連続実行すると処理負荷の面を考慮すると効率が良いとの考えからである。例えば、歩行者検知の必須版と付加版などで共有する情報は多く、必須機能が終わった後の情報の退避、付加版を開始する際の情報の復帰などを考慮すると同一アプリは連続実行したほうが処理負荷、メモリ消費量からみても効率的なためである。ただし、打ち切り処理抑制を最重要視するようであれば、優先順位の順にアプリケーションを実施するのが良いと考える。最終的には、アプリ実行の負荷と比較しアプリ小分割の際に生じる負荷の大きさや、タスク打ち切り抑制の重要度によってスケジューリングを決める。

図１３の場合における車両の周囲環境シーンを図２５（ｂ）に示す。図２５（ｂ）は、予測処理時間の算出方法を説明する図であり、自車２５１の前方に複数人の歩行者２５３Ａ〜Ｆと複数台の車両２５２Ａ〜Ｅが存在している状況を示している。

まず、動的処理時間予測部１１１において、各アプリの処理時間を予測する。図２６に示すように、動的処理時間予測制御部１１２の予測情報選定部１１３では、走行環境情報部２１０とマルチアプリ実行部１３１と車両制御部２５０から入力として得られた情報を、走行環境情報１１４、マルチアプリ実行情報１１５、車両制御情報１１６として保存する。これらの保存された情報から、動的処理時間予測に利用する情報を各アプリ別に選定して各アプリの動的予測部（３１３０−３１５０、４１３０−４１７０）に情報を送信する。

そして、レーン認識アプリ１３０の必須版アプリ１１３０における処理時間を予測する。ここでは、マルチアプリ実行情報１１５から前規定周期の処理結果より処理領域の大きさ、及び前回の認識結果を利用して、次規定周期におけるレーン認識アプリ１３０の必須版アプリ１１３０の処理時間を予測する。

前規定周期の処理領域の大きさと認識結果より次回の処理領域の大きさを決定するため、これらの情報を利用する。また、連続して不認識が続いているなどのレーン認識状況の情報も利用し、連続不検知の場合には処理領域を拡大して認識処理を実行するために、処理時間が長くなると予測する。このように処理領域の大きさ及び過去の認識結果の履歴を利用し、レーン認識アプリ１３０の必須版アプリ１１３０の処理時間を予測する。予測処理時間を初期処理時間で割り算し１００を乗算し、処理時間比率を図２５（ａ）に示す。

この比率が１００を超えた場合には、初期設定のスケジューリングを守ることができないことを意味する。このシーンにおいてはレーン認識アプリ１３０の必須版アプリ１１３０の処理時間比率は９０％と予測する。

または、走行環境情報のカーナビからきれいな実線が続くような道路であるか、ボッツドッツのように認識が困難で不検知になりがちな道路であるか道路状況の情報を得て、きれいな実線であれば認識結果も安定してトラッキング可能なため処理時間が短く、ボッツドッツであれば不検知や安定して認識することが困難であることから処理時間が長いというように処理時間の予測をおこなっても良い。もしくは、車両制御情報の車速やヨー角から次周期における白線ＷＬの位置を予測し、実線の場合には処理時間に変化無く、破線の場合には次周期における破線位置と空白部の位置を予測し、処理時間を予測するような方法でも良い。初期処理時間をベースに考えた場合の予測処理時間の長さのパーセンテージを図２５（ａ）に示す。レーン認識アプリ１３０の必須版アプリ１１３０は９０％と予測する。

次に、レーン認識アプリ１３０の付加版アプリ２１３０における処理時間を予測する。ここでは、必須版アプリ１１３０と同様にマルチアプリ実行情報１１５から前周期のレーン認識アプリ１３０の付加版アプリ２１３０の処理領域の大きさと認識結果を利用し、次規定周期の処理領域の大きさを決定し、この処理領域の大きさや認識結果の履歴より処理時間の予測を行う。必須版同様に認識状況、車両走行情報のナビからの道路状況や道路曲率情報、車両制御情報１１６の車速やヨー角情報から処理時間を予測しても良い。図２５（ｂ）の場合におけるこのレーン認識アプリ１３０の付加版アプリ２１３０の処理時間比率を９５％と予測する。

次に、歩行者検知アプリ１４０の処理時間を予測する方法について説明する。図２５（ｂ）に示すように、車両制御対象となる停止距離範囲内、及び走行予測経路内には３人の歩行者２５３Ａ〜Ｃが存在し、それよりも遠方に３人の歩行者２５３Ｄ、Ｆが存在する。停止距離範囲は、車両制御部２５０の車速センサ２６１の検出値を利用する。

走行環境情報部２１０のレーダ２６１により車両制御が働く停止距離範囲内には３人の歩行者２５３Ａ〜Ｃが歩行者候補として検知され、更に遠方では、３人の歩行者２５３Ｄ、Ｆと、電柱２５３Ｅが候補として検知される。

レーダ２６１のセンサ情報から、歩行者候補２５３Ａ〜Ｆの存在と、各候補２５３Ａ〜Ｆの自車両２５１からの距離と方向、物体幅が検知できるため、画像上の歩行者候補２５３Ａ〜Ｆの大きさと処理範囲が計算可能である。これにより画像上の歩行者候補２５３Ａ〜Ｆを探索する処理領域が決定する。

方向と物体幅、距離において画像上の処理領域を決定し、歩行者候補２５３Ａ〜Ｆまでの距離に応じ処理領域内の画像を正規化する。この正規化されたサイズでパターンマッチングし、歩行者検知を行う。このため、画像正規化の処理負荷とパターンマッチングの処理負荷より処理時間を予測する。

歩行者の距離から画像を正規化するため、大きく身長が異なる場合、パターンマッチングの検知率に影響を及ぼす。このため同じ歩行者候補に対して、複数のサイズでパターンマッチングするような手法でもよい。このような場合も、正規化の回数やパターンマッチングの回数によって処理時間を予測する方法で良い。このように歩行者検知の手法に応じて、画像正規化とパターンマッチングの処理負荷を考慮し、歩行者検知アプリ１４０の必須版アプリ１１４０の処理時間を予測する。

付加版アプリ２１４０では、歩行者候補２５３Ｄ〜Ｆに対する処理時間を予測する。処理は必須版アプリ１１４０と同様であるが、停止距離範囲外である遠方では画像上に小さく写る歩行者候補を対象とするため画像正規化の負担が軽減される。パターンマッチングの処理負荷は大きく変化しない。これらの情報より、歩行者の多いこのシーンにおいては、必須版アプリ１１４０、付加版アプリ２１４０ともに処理負荷が高くなり、図２５（ａ）の予測処理時間のグラフに示すように、必須版アプリ１１４０は処理時間比率２１０％、付加版アプリ２１４０は１９０％となり、初期処理時間と比較して予測処理時間が非常に長くなる。

次に、車両検知アプリ１５０の処理時間を予測する方法について説明する。車両検知アプリ１５０は、制御対象となる車両候補を必須版アプリ１１５０によって検知し、それ以外の車両を付加版アプリ２１５０によって検知する処理を行う。

走行環境部２１０のレーダ２１６より車両候補を検知し、相対速度と方向と車体幅を検知する。車両制御情報１１６より車両候補のなかから必須版対象の車両候補と、付加版対象の車両候補に分割する。図２５（ｂ）に示すシーンでは、車両候補２５２Ａ、Ｂが、必須版アプリ１１５０の認識対象とされ、車両候補２５２Ｃ〜Ｅが、付加版アプリ２１５０の認識対象とされる。

歩行者検知と同様に画像上に車両候補が映る処理領域を設定し、自車両からの距離に応じて処理領域内の画像を正規化する。決められた車両のパターンサイズにてパターンマッチングを行うため、この画像正規化とパターンマッチングの回数に応じて処理時間を予測する。図２５（ｂ）のシーンにおいては、車両検知アプリ１５０の必須版アプリ１１５０と付加版アプリ２１５０は、ともに処理時間が通常時よりも長くなり、必須版アプリ１１５０の処理時間比率及び付加版アプリ２１５０の処理時間比率は、共に１５０％と予測される。

次に、標識検知アプリ１７０の処理時間を予測する方法について説明する。マルチアプリ実行情報１１５の前規定周期における処理時間より、次規定周期の予測する。歩行者検知アプリ１４０や車両検知アプリ１５０がこのような手法をとってもよい。

予測のために車両制御部２５０の車速やヨー角情報より次規定周期における画像上の標識の大きさを推定し、処理時間の予測を行っても良い。トラッキングにより連続して検知できている対象にはこのような処理時間の予測が可能となり、新規に検知する標識は処理時間が予測できないために、上記過去の検知履歴から予測される処理時間にプラスして処理時間に余裕分を追加して予測処理時間とする。図２５（ｂ）のシーンにおいて標識検知アプリ１７０の処理時間比率は９５％と予測される。

そして、アプリごとに予測情報選定部１１３によって選択された情報から、処理時間を予測し、各アプリ予測情報１１９にデータを一時格納する。次に、このような各アプリの予測処理時間を利用することにより、アプリ実行前に、規定処理周期内に処理が完了しないこと、もしくは規定周期後にも処理が続いてしまうことが予想可能となる。

そこで、この予測処理時間結果を利用して、図１４（ａ）に示すように、優先順位の低い利便性機能である歩行者検知アプリ１４０の付加版アプリ２１４０と、標識検知アプリ１７０の実行を停止し、他の優先順位の高い処理を実行することで、規定周期内により優先度の高い処理を詰め込むことに成功している。動的に処理時間を予測することで、安全性機能に打ち切り処理が発生することを抑制している。

そして、図１３（ｂ）に示す車両検知アプリ１５０のように、打ち切り処理により結果が全く得られなくなることを避けるため規定処理周期に処理が完了することをあきらめて、処理周期を伸ばすスケジューリング方法もある。しかしながら、規定処理周期を守れずリアルタイム性が問題となっていた。このような場合、先ほどのように優先順位と動的予測処理時間を利用して規定周期を守る前記の図１４（ａ）のスケジューリング方法もあるが、図１４（ｂ）に示すように規定周期の延長を規定値まで認めたスケジューリングを行うことで、打ち切り処理を極力減らしながらも、処理周期の大きな遅延を認めないようなスケジューリングを行う手法でも良い。これにより、利便性も保ちながらも、安全性のためのリアルタイム性も保証することが可能となる。

このようにスケジューリングを行う際に、処理時間の長い処理は無駄時間が発生しやすいことや、頻繁に打ち切り処理が発生しやすいなどスケジューリングする側からみれば扱いにくい処理である。

次に、スケジューリングされたアプリのタスクを分割して実行する場合（タスク小分割）について以下に説明する。

打ち切り処理やスケジューリングにより柔軟に対応するために、アプリのタスクを分割して実行する手法をとってもよい。図１５、図１７は、歩行者検出方法の一例を説明する図であり、図１５は、自車と歩行者との位置関係を説明する図、図１７は、規定周期の終了時に打ち切り処理を行った場合に、タスクを小分割したか否かによる効果の相異について説明する図である。

歩行者検出は、レーダ２６１とカメラ装置を用いたフュージョン方式によって行われる。例えば、自車の車速Ｖや舵角等の情報と、レーダ２６１の検知結果に基づき、歩行者候補１５２Ａ〜Ｅの位置を特定し、これらの各歩行者候補１５２Ａ〜Ｅに対応する画像領域に対して歩行者認識の画像処理を実行する。

図１５に破線で示す停止距離Ｌは、空走距離と制動距離を加算することによって算出される（停止距離＝空走距離＋制動距離）。空走距離は、運転者が歩行者を認識してからブレーキ操作を行うまでの平均的反応時間に車速を乗算することによって算出され（空走距離＝平均的反応時間×車速）、制動距離は、車速の２乗と摩擦係数に基づいて算出される（制動距離＝車速の２乗／（２５４×摩擦係数）。摩擦係数は、平均的道路の摩擦係数であり、車両が雨滴センサや路面検知センサを備えている場合には、これらのセンサ値に基づいて動的に変化させてもよい。

例えば図１７（ａ）に示すように、歩行者検知アプリ１４０を一つのアプリとした場合には、その途中で打ち切り処理がなされると、歩行者検知の結果は得られない。そこで、車両制御に関係するような安全性の機能と、それよりも遠方を検知対象とし車両制御に直接関係せず注意を喚起するための利便性の機能に機能分割すべく、図１７（ｂ）に示すように必須版アプリ１１４０と付加版アプリ２１４０に分類する。

このように、一つのアプリを必須版アプリ１１４０と付加版アプリ２１４０に分割することにより、例えば、付加版アプリ２１４０の途中で打ち切り処理が行われた場合に、その打ち切り処理の被害を付加版アプリ２１４０による利便性に留めて、必須版アプリ１１４０による安全性の機能に影響が及ぶのを抑制することができる。

しかしながら、アプリを二つに分割しているとはいえ、アプリの最後の数パーセントの処理が完了しなかっただけでも、そのアプリの結果は全く得られなくなる。そこで、図１７（ｃ）に示すように、レーダ２１６で検知した歩行者候補１５２Ａ〜Ｅの候補一つずつに処理を分割し、認識処理が終了した時点で、結果を出力できるようにする。

このように認識対象の候補一つずつに処理を分割することにより、図１７に示すように、打ち切り処理による認識結果の欠落を最小限に抑制するとともに、スケジューリングに柔軟性を持たせる。このように細かく処理が分割されれば、処理時間予測結果に基づいて、規定処理周期内にどの候補まで歩行者検知可能かを考慮しながら細かい調整が可能となる。図１７に示す例では、必須版アプリ１１４０の認識結果に加えて、更に他の歩行者について付加版アプリ２１４０の認識結果についても得ることができる。

図１６は、車両検知方法の一例を説明する図であり、自車と自車周辺の他の車両との位置関係を説明する図である。

車両検知は、歩行者検出と同様に、レーダ２６１とカメラ装置を用いたフュージョン方式によって行われ、例えば、自車１６１の車速や舵角等の情報と、レーダ２６１の検知結果に基づき、車両候補１６２Ａ〜Ｄの位置を特定し、これらの各車両候補１６２Ａ〜Ｄに対応する画像領域に対して車両認識の画像処理を実行する。

ここでは、車両制御に関連する先行車両１６２Ｂ、Ｃ、車速を考慮した停止距離以内に存在し自車走行時に衝突危険性の高い隣接車線の車両Ａの検知を安全性機能、それ以外を利便性の機能に登録する構成は残したまま、レーダ２６１で検知された車両候補１６２Ａ〜Ｄのそれぞれに対して、画像認識のタスクを車両候補別に小分割する。

隣接車線を含む先行車両１６２Ｂ、Ｃは、相対速度を考慮して停止距離以内に存在する車両１６２Ｂを、安全性の機能として車両検知アプリ１５０の必須版アプリ１１５０による認識対象とする。対向車両１６２Ａ、Ｄは、レーダ２６１のみの検知結果において、このまま走行を続けると自車１６１との接触の可能性がある車両１６２Ａを、安全性の機能として車両検知アプリ１５０の必須版アプリ１１５０による認識対象とする。そして、レーダ２６１で検知されかつ自車１６１の車両制御に直接関係しない車両１６２Ｃ、Ｄは、利便性の機能として車両検知アプリ１５０の付加版アプリ２１５０による認識対象とする。

このように、認識対象の車両候補一つずつに処理を分割することにより、打ち切り処理による認識結果の欠落を抑制するとともに、スケジューリングに柔軟性を持たせる。このように細かく処理が分割されれば、処理時間予測結果に基づいて、規定処理周期内にどの候補まで車両検知可能かを考慮しながら細かい調整が可能となる。

図１８は、タスク小分割による並列処理の作用効果を説明する図である。歩行者、もしくは車両などの候補別にアプリのタスクを小分割すれば、データに依存関係の少ない処理に分割ができる。このため、並列処理が容易となり、マルチコアや、マルチＣＰＵを利用したシステム構成では、同じアプリでも並列処理を考慮した柔軟なスケジューリングが可能となり、安全性機能の処理完了を助けるほか、規定周期を守ること、利便性機能の追加にも効果が期待される。

また、画像処理のようにメモリを大量に消費するタスクでは、タスクの途中でＣＰＵの割当を切り替えるなどの仕事移送や、割り込み処理発生によるタスクの一時退避などは、ＣＰＵの処理負荷になることが多い。したがって、タスクを小さくすることで、ＣＰＵ間の仕事移送なしに、小分割されたタスクの合間にＣＰＵ割当を切り替えることができ、より柔軟なスケジューリングが可能となる。また、タスクを小さくしたことで、個々のタスクが消費するメモリも抑制することが可能となり、一時退避が発生した場合の処理負荷のリスクを低減することに成功している。

例えば、図１８（ａ）に示すように、歩行者検知アプリ１４０で歩行者検知機能が得られる場合（１つのアプリで一つの機能が得られる場合）に、他の機能との並列処理が可能となる。そして、図１８（ｂ）に示すように、歩行者検知アプリ１４０によって必須版アプリ１１４０と付加版アプリ２１４０という２つの機能が得られる場合（１つのアプリで２つの機能が得られる場合）には、これらのアプリを並列に処理することができる。また、図１８（ｃ）に示すように、必須版または付加版の属性を有するタスクに小分割する場合には、タスクごとに並列処理することができる。

次に、規定周期を短縮する方法について説明する。動的処理時間の予測より、全てのタスクテーブルの機能を実行しても規定周期よりも予測処理時間が短くなる場合、もしくは、もしくは処理周期が短い場合が連続した場合には、図１９に示すように規定周期を短縮することで、車両制御を高精度に安定的に行う。

車速が高くなるほど、または、車線に車両が近づくにつれて、処理周期を早めることで、より高性能な制御を実現する。この場合、現周期に処理時間の余裕があるかどうかの判定を行うと共に、処理時間に余裕がない場合はタスクテーブルの優先順位や、解像度、検知距離などの結果より処理負荷軽減策を図る。処理時間に余裕があり、なおかつその状態が連続して安定しているような場合には、規定の処理時間をそのまま短縮することで、検知間隔を短くし、検知の信頼性向上や精度向上、検知速度の向上を図る。

郊外、高速道路を走行し長期にわたって歩行者や車両が周囲に存在しないような場合には、処理時間に余裕のある状態が長期にわたって続く可能性が高い。このような状況では、処理時間を余らせておくよりも、処理周期を短くし、精度を高める方が安全性を高めることができる。もしくは、標識検知や路面標識検知などの利便性機能の詰め込みを行うことで利便性を高める。

次に、消費電力調整モードについて説明する。予測した各機能の処理時間に応じて、規定処理周期内に処理が完了しないような場合には、消費電力を調整することでＣＰＵの性能（クロック数、動作コア数、動作ＣＰＵ数）を調整し、規定処理周期内に処理が完了するように調整する。

規定処理周期内に処理が完了し、余剰時間があるような場合には低消費電力モードへ変更し、反対に処理負荷が高く、規定処理周期内に処理が完了しないような場合には、消費電力を上げるとともに、ＣＰＵ性能を向上させることで規定処理周期内に処理が完了するように対応する。処理時間を予測することで、緊急時に処理が追いつかないような状況を避け、処理負荷が軽い場合にはできる限り消費電力を下げる。

図２０は、利便性を追加するスケジューリングの方法を説明する図である。動的処理時間の予測より、全てのタスクテーブルの機能を実行しても規定処理周期よりも予測処理時間が短くなる場合、或いは、もしくは処理周期が短い場合が連続した場合には、図２０に示すように、規定周期内に収まるように、オートライトアプリ１６０や路面標識検知アプリ１８０等の利便性の機能を追加する。これにより、安全性を確保しながらも利便性を高めることができる。

また、雨滴検知や、窓ガラスの曇り検知、ヘッドライトのＯＮ、ＯＦＦやライトの光軸調整を行うオートライトなどの利便性機能の場合、毎規定周期ごとに処理し、状態の変化を観察する必要性は低い。雨が降ってきた場合などには、ワイパーが自動で作動するまでに、数秒程度の遅れが、ユーザに不便さを感じさせる可能性は低い。

このため、安全性機能の動的予測処理時間が比較的短く、規定周期内に処理が完結するような場合にのみ、上記、雨滴検知、窓ガラス曇り検知、オートライトなどを動作させるような優先順位のスケジューリングでも十分に利便性機能の有効性が認められる。

ただし、晴れから雨の状態への過渡期や、曇り無しから有り、昼から夜への過渡期など、判定状態を変更するような場合には、誤検知を少なくする上でも判定を何度か繰り返した後に最終的な判定を実行することが望ましい。このように状態の移行時には、ＣＰＵ空き時間があれば積極的に利用し検知ロジックを動作させることで、安全性の機能の劣化を招くことなく、利便性を高める。

アプリの選択は、例えばユーザがナビの操作画面から実行することによって行うことができる。アプリ登録では、各機能の初期処理時間を基にスケジューリングし、安全性の必須機能と利便性の付加機能の登録を行い、規定処理周期内に処理が完了するようにアプリを選択可能な設計とする。登録した各機能の必須機能の合計処理時間が規定時間１を越えた時点で必須機能の登録の受付を終了し、必須機能と付加機能の処理時間合計が規定時間２を越えた時点でアプリの追加を終了する。

しかし、この時点では、各機能は固定処理時間でスケジューリングをされていることから、実際の走行時に規定処理周期内に処理が完了するか、もしくはＣＰＵ空き時間が多いか判定は困難である。特に歩行者検知アプリ１４０や車両検知アプリ１５０が安全性機能として登録されている場合、レーダ２６１によって検知された歩行者候補、もしくは車両候補がない場合には、処理時間がほぼ０となり、ＣＰＵ空き時間が非常に大きくなる。

アプリ登録時のスケジューリングでは、当然、検知候補が存在する場合の処理時間をベースとしてスケジューリングすることから、ＣＰＵ空き時間が非常に多くなることが予想される。特に、郊外などの車両や人の通りがすくない場所では、ＣＰＵが常に活用されていないこととなる。

このような場合には、処理周期を上げることで、安全性機能の性能向上、もしくは利便性の機能を追加することでＣＰＵを有効活用し、ユーザの利便性を向上する。また、場合によっては、アプリ登録時のスケジューリングでは処理負荷が高く、規定周期内に処理が完了しないことが頻発するような場合も想定される。このような場合には、スケジューリングを調整するうえで、優先順位の低い処理から登録の除去をユーザに通知もしくは、選択画面にて選択させることで、スケジューリングを調整する。

また、アプリインストール時やアプリ新規追加時に、上記手法によるスケジューリング調整を行っても良い。メンテナンス性などを考慮しても、設計側が大量のタスクテーブルを準備しておくのは設計作業の負担が大きく、シーンやユーザの好みに合わせて自動的にタスクテーブルを最適に設計することで、安全性を考慮しながらもユーザの利便性や意思を尊重したシステム設計が可能となる。

＜コア割り当て変更 スケジューリング ２ＣＰＵ＞
マルチコアや、マルチＣＰＵの利用形態には、特定のコアもしくはＣＰＵに特定の機能とＯＳを割り当てるＡＭＰ（Ａｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉｐｒｏｃｅｓｓｉｎｇ）と、個々のコアもしくはＣＰＵが対等の条件でメモリを共有するＳＭＰ（Ｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−ｐｒｏｃｅｓｓｉｎｇ）、そして、一つのＯＳがあるタスクを特定のコアもしくはＣＰＵに割り当てて実行することで、ＡＭＰの持つ移植性とＳＭＰの持つ柔軟性を併せ持つＢＭＰ（Ｂｏｕｎｄ Ｍｕｌｔｉｐｒｏｃｅｓｓｉｎｇ）がある。

コアやＣＰＵに対して特定の機能を割り当てることが可能なＡＭＰ、ＢＭＰでは、このような動的予測時間処理を利用したスケジューリングにより、更に安全性、及び利便性を高めることができる。ＳＭＰやＡＭＰの場合において、機能を別コアもしくは別ＣＰＵに割り当てることができない構成の場合には、シングルコア、もしくはシングルＣＰＵの場合と同様の効果と作用である。

従来のスケジューリングでは、機能に固定の処理時間を基に、図２１に示すように、各コア（ＣＰＵ）に対して処理を割り当てている。図２１では、上段をコア１（ＣＰＵ１）とし、下段をコア２（ＣＰＵ２）とし、処理を割り当てている。そして、図２２（ａ）に示すように、車両検知アプリ１５０の必須版アプリ１１５０が規定周期をオーバーしても処理が完了しない場合、ＣＰＵ１のその後の規定周期内にスケジューリングされていたアプリ（車両検知アプリ１５０の付加版アプリ２１５０や路面標識検出アプリ１８０）の処理は完了せず、規定周期を延長するか、打ち切り処理を行うしかなかった。

図２７（ｂ）に示すようなシーンにおける処理時間の予測結果を図２７（ａ）に示す。予測処理時間は、ＣＰＵの処理速度をも考慮して行うが、マルチコアの場合も基本的には、１ＣＰＵ（１コア）の場合の予測処理と同様である。

レーン認識アプリ１３０の必須版アプリ１１３０と付加版アプリ２１３０の処理時間予測には、マルチアプリ実行部１３１からの過去認識結果や処理領域の大きさ、走行環境情報１１４に基づいて処理時間の予測を行う。処理時間の予測結果は図２７（ａ）に、初期処理時間と比較したパーセンテージで処理時間を表現している。

歩行者検知なども１ＣＰＵの場合と同様に処理時間の予測を行う。図２７（ｂ）のシーンにおいては、歩行者候補としてレーダ２６１が捕らえる候補は、電柱２７３Ａのみのため、この領域を切り出し、人かどうか画像処理にて判定を行うための画像正規化とパターンマッチングの計算量を見積もり、処理時間を予測する。

車両検知の場合も同様にレーザ２６１で検知し、処理時間を見積もる（処理時間を予測する）。図２７（ｂ）のシーンでは、車両２７２Ａ〜Ｉが多く、自車２７１付近に存在するために、処理負荷が非常に高く、車両検知アプリ１５０の必須版アプリ１１５０と付加版アプリ２１５０における処理時間比率は２５０％と２００％になっている。

オートライトアプリ１６０では、車外の明るさを検知し、ライトのＯＮ、ＯＦＦのための判定を行う。昼のために対向車や先行車のための処理は動かず、予測処理時間は短く初期処理時間と比較してその処理時間比率は３０％となっている。更に標識検知アプリ１７０や、路面標識検知アプリ１８０は、アプリ実行情報１５１の過去の認識結果と、車両制御情報１１６より処理時間を予測し、標識検知アプリの処理時間比率は９５％、路面標識検知アプリの処理時間比率は９３％となる。

動的に予測した処理時間を利用することができれば、例えば図２２（ａ）に示すように、あらかじめ予測される処理時間から規定処理周期内に車両検知アプリ１５０の必須版アプリ１１５０がコア１（ＣＰＵ１）で完了しないことが予測でき、それ以降にコア１でスケジューリングされている車両検知アプリ１５０の付加版アプリ２１５０や路面標識検知アプリ１８０も同様に処理できないことが予想できる。

更に、コア２（ＣＰＵ２）で処理時間に余剰の空き時間があることが予測できる。これにより、動的に処理時間を予測した結果を利用して、コア１（ＣＰＵ１）とコア２（ＣＰＵ２）に割り当てる機能を調整することができる。

このように、動的処理時間の予測を利用して、処理負荷をより均等に割り当てることで、マルチコア（ＣＰＵ）の性能を十分に活用できるスケジューリングが可能となり、既定周期内の処理完了や、利便性の機能の効率的動作に効果がある。

例えば、図２２（ｂ）に示すように、レーン認識アプリ１３０の付加版アプリ２１３０をコア１（ＣＰＵ１）からコア２（ＣＰＵ２）に割り当て変更することで、リアルタイム性を保持しながら、できる限り利便性の機能の動作保証をすることができる。

更に、各アプリをデータ依存関係の少ない、小さな処理に分割したことを利用し、並列処理することで、コア（ＣＰＵ）間の処理の分担方法に選択肢を増やす。図２２（ｂ）には、データ依存関係があった場合におけるスケジューリングを示した。データ依存関係を気にするために車両検知の並列処理が実行できず優先順位が高いにも関わらず車両検知（付加版）が処理できないなど問題があった。

例えば、図２３に示すスケジューリングでは、優先度の高さを考慮して、レーン認識アプリ１３０、歩行者検知アプリ１４０、車両検知アプリ１５０における必須版アプリと付加版アプリの両機能を全てスケジューリングできている。

このように並列処理ができることも考慮したスケジューリングにより、処理の順序や打ち切り処理の対応に柔軟にスケジューリングを組み替えることが可能となり、安全性を確保するスケジューリング方法をとりながらも、利便性を追求する付加機能を効率的に実施することができる。

＜別ハード構成＞
なお、上述の実施の形態では、車載用マルチアプリ実行装置１００が車載カメラ内に一体に設けられている構成の場合を例に説明したが、係る構成に限定されるものではない。例えば、ハード構成は、図２４に示すようなカメラの撮像系のデバイスが、画像処理する本体とは別れていて映像だけが転送されるような構造でも良い。

また、車載用マルチアプリ実行装置１００は、カーナビゲーション本体のＣＰＵを、一部利用して動作するような方法でも良く、また、予防安全のための環境認識系に共通の一つのＣＰＵ、車両制御を制御する車両ＥＣＵのＣＰＵを利用しても良い。また、図２４に示すように走行環境情報部２０１が、画像処理する装置本体の内部または外部に存在するものであってもよく、走行環境の情報が画像処理装置に送信されていれば良い。

そして、処理時間の予測処理は、処理時間の変動が大きい処理に限定しても良い。また、処理時間が正確に予測できるアプリに限定されていても良い。処理時間の変動が大きい処理の場合、毎回の予測によってスケジューリングをより効果的に変更することができる。毎回の処理時間がほぼ同等、もしくは処理時間の予測が不正確であると、むしろ適切なスケジューリングが困難になる。このような場合、動的に予測していない固定処理時間によりスケジューリングされている機能と動的処理時間予測の機能が混同しても、その効果は十分に活かされる。

レーダ２６１を利用したフュージョン方式の歩行者検知や車両検知では、レーダ２６１の結果を利用して処理領域を決めると、画像処理の計算量がかなり正確に予測することが可能となる。レーダ２６１の結果によっては、歩行者候補などが見つからなければ、動的な予測処理時間はほぼ０になりうる。このように処理時間が大幅に変化するような機能には、動的な処理時間の予測によるスケジューリング最適化の効果が大きい。反対に、処理時間がほぼ一定の機能の場合には、処理時間を予測する処理を追加するよりも常に固定処理周期でスケジューリングした方が、費用対効果に優れている場合もある。

１００・・・車載用マルチアプリ実行装置、１０１・・・カメラ撮像部、１１１・・・動的処理時間予測部、１２１・・・マルチアプリ制御部（スケジューラ）、１２５・・・マルチアプリ実行部、１３０・・・レーン認識アプリ、１１３０・・・必須版アプリ、２１３０・・・付加版アプリ、１４０・・・歩行者検知アプリ、１１４０・・・必須版アプリ、２１４０・・・付加版アプリ、１５０・・・車両検知アプリ、１１５０・・・必須版アプリ、２１５０・・・付加版アプリ、１６０・・・オートライトアプリ、１７０・・・標識検知アプリ、１８０・・・路面標識検知アプリ、１１００・・・必須機能部、２１００・・・付加機能部、２０１・・・自車両走行情報部、２１３・・・ウィンカー、２１４・・・アプリ操作、２１５・・・カーナビ、２１６・・・レーダ、２５０・・・車両制御部、２６０・・・車両ＥＣＵ、２６１・・・車速センサ、２６２・・・操舵角センサ、２６３・・・ヨーレートセンサ、２６４・・・アクチュエータ、３００・・・制御・警告判断部

Claims (13)

1. 規定周期内に複数のアプリケーションを実行する車載用マルチアプリ実行装置であって、
   各アプリケーションの処理時間を動的に予測する動的処理時間予測部と、
   該動的処理時間予測部により動的に予測した処理時間に基づいて各アプリケーションのスケジューリングを行うマルチアプリ制御部と、
   該マルチアプリ制御部のスケジューリング結果に基づいて前記複数のアプリケーションの処理を実行するマルチアプリ実行部と、
   を有することを特徴とする車載用マルチアプリ実行装置。
2. 前記マルチアプリ実行部は、前記マルチアプリ制御部によってスケジューリングを行った結果、予め設定された規定周期内に処理が終了しないアプリケーションが存在すると判断した場合に、予め設定された優先順位に基づいて、アプリケーションの打ち切り、もしくはアプリケーションの機能を低下させることを特徴とする請求項１に記載の車載用マルチアプリ実行装置。
3. 前記マルチアプリ実行部は、各アプリケーションを安全性と利便性の機能別に分類し、前記安全性に関わるアプリケーションの処理は前記規定周期が終了しても継続し、前記利便性に関わるアプリケーションの処理は規定周期の終了により停止するスケジューリングを行うことを特徴とする請求項２に記載の車載用マルチアプリ実行装置。
4. 前記マルチアプリ実行部は、前記アプリケーションが対象とする対象候補１つずつに処理を分割して実行することを特徴とする請求項２又は３に記載の車載用マルチアプリ実行装置。
5. マルチコア、もしくはマルチＣＰＵを備え、
   前記マルチアプリ実行部は、前記マルチアプリ制御部によってスケジューリングを行った結果、前記規定周期内に処理が終了しないアプリケーションが存在すると判断した場合に、前記アプリケーションを動作させるために指定したコアもしくはＣＰＵを他のコアもしくはＣＰＵに変更することを特徴とする請求項２から請求項４のいずれか一項に記載の車載用マルチアプリ実行装置。
6. マルチコアもしくはマルチＣＰＵを備え、
   前記マルチアプリ実行部は、前記マルチアプリ制御部によってスケジューリングを行った結果、予め設定された規定周期内に処理が終了しないアプリケーションが存在すると判断した場合、もしくは、各アプリケーションの処理を前記規定周期よりも早く完了させたい場合に、前記マルチコアもしくはマルチＣＰＵに対して同一のアプリケーションを並列処理させることを特徴とする請求項２から請求項４のいずれか一項に記載の車載用マルチアプリ実行装置。
7. マルチコアもしくはマルチＣＰＵを備え、
   前記マルチアプリ実行部は、データ依存関係の少ない認識対象別に前記アプリケーションのタスクを分割して前記マルチコアもしくはマルチＣＰＵに並列処理させることを特徴とする請求項２から請求項４のいずれか一項に記載の車載用マルチアプリ実行装置。
8. 前記マルチアプリ制御部は、前記スケジューリングを行った結果、規定周期内に規定値以上の空き時間が連続して存在する場合に、前記規定周期の処理時間を短縮することを特徴とする請求項１に記載の車載用マルチアプリ実行装置。
9. 前記マルチアプリ制御部は、前記スケジューリングを行った結果、規定周期内に規定値以上の空き時間が連続して存在する場合に、利便性機能を有するアプリケーションを前記規定周期内に追加するスケジューリングを実施することを特徴とする請求項１に記載の車載用マルチアプリ実行装置。
10. 前記動的処理時間予測部は、予め設定されたタスクテーブルの情報、アプリケーションの実行状態、車両制御状態、走行環境情報の少なくとも一つに基づいて前記処理時間を動的に予測することを特徴とする請求項１から請求項９のいずれか一項に記載の車載用マルチアプリ実行装置。
11. 前記アプリケーションがレーダの検知結果に基づいて画像処理領域を絞り込み、認識対象を認識する処理を行う場合に、
    前記動的処理時間予測部は、前記レーダの検知結果を利用して前記処理時間を動的に予測することを特徴とする請求項１から請求項９のいずれか一項に記載の車載用マルチアプリ実行装置。
12. 前記動的処理時間予測部は、カーナビゲーションシステムに記憶されている地図情報、もしくは、自車が過去に走行した時の実処理時間の履歴を利用して前記処理時間を動的に予測することを特徴とする請求項１から請求項９のいずれか一項に記載の車載用マルチアプリ実行装置。
13. 自車の走行情報を取得する自車走行情報取得部を有し、
    前記マルチアプリ実行部は、前記自車走行情報取得部により取得した自車走行情報に基づいて前記アプリの処理モードを設定し、
    前記動的処理時間予測部は、前記マルチアプリ実行部によって設定された処理モードに基づいて前記予測処理時間を予測することを特徴とする請求項１から請求項９のいずれか一項に記載の車載用マルチアプリ実行装置。

Images