JP2021179762A - 車載制御装置、サーバ、検証システム - Google Patents

Abstract

【課題】複数の検証アプリケーションプログラムを効率よく検証できる車載制御装置、サーバ及び検証システムを提供する。【解決手段】車両２に搭載された車載制御装置２１は、処理部２２０と、車載記憶部２１０と、通信部２３０と、を有する。車載記憶部は、車両の走行制御に関する基本アプリケーションプログラム２１１、基本アプリケーションプログラムとは異なる複数の検証アプリケーションプログラム２１２、検証アプリケーションプログラムを検証する車両に関する条件である走行環境条件２１６及び走行環境条件の検証優先度２１５を格納する。処理部の基本アプリ実行制御部２２３は、基本アプリケーションプログラムの実行スケジュールに基づいて、車載制御装置のＣＰＵ上で基本アプリケーションプログラムを実行及び制御する。検証アプリ実行制御部２２４は、走行環境条件及び検証優先度に基づき、検証アプリケーションプログラムの検証の実行を制御する。【選択図】図２

Description

本発明は、車載制御装置、サーバ、および検証システムに関する。

自動運転を実現する制御アプリケーションは、車両の周辺の多様な情報である車両周辺環境データに対して正しく動作するよう検証する必要がある。車両周辺環境データとは、車両の周辺に存在する障害物の情報や、車両の周辺における道路の特徴を示す特徴物等の情報等である。将来的には自動運転車が普及すると見込まれるため、自動運転中に得られる車両周辺環境データを用いて検証を行うことが考えられる。しかし自動運転中には、自動運転のアプリケーション処理でＣＰＵリソースが使用されるため、検証に対して用いることが可能なＣＰＵリソースが限られている。ＣＰＵリソースが限られている中にあっても、効率的にアプリケーションの検証を行う必要を行うことが求められる。特許文献１には車載情報システムのハードウエア環境およびソフトウェア環境をエミュレートするエミュレート手段と、車載情報システム用に開発されたプログラムを受け取るプログラム受信手段と、車載情報システムのリソース状態および環境状態を制約条件として保持する制約条件保持手段と、前記制約条件保持手段に保持された制約条件に基づいて前記プログラムの動作を制限するプログラム実行制限手段と、前記エミュレート手段によって提供されるリソースを用いて、前記プログラム受信手段から受け取ったプログラムを、前記プログラム実行制限手段による制限にしたがって実行するプログラム実行手段とを備えたプログラム提供装置が開示されている。

特開２０１１−１４６０６８号公報

特許文献１に記載されている発明では、複数の検証アプリケーションプログラムの検証において改善の余地がある。

本発明の第１の態様による車載制御装置は、車両に搭載される車載制御装置であって、前記車両の走行制御に関する基本アプリケーションプログラム、前記基本アプリケーションプログラムとは異なる複数の検証アプリケーションプログラム、前記検証アプリケーションプログラムを検証する前記車両に関する条件である走行環境条件、および前記走行環境条件の検証優先度、を格納する車載記憶部と、前記基本アプリケーションプログラムおよび前記検証アプリケーションプログラムを実行可能なＣＰＵと、前記走行環境条件および前記検証優先度に基づき、前記検証アプリケーションプログラムの検証の実行を制御する検証実行制御部と、を備える。
本発明の第２の態様によるサーバは、車両と通信可能なサーバであって、前記車両において検証されるアプリケーションプログラムである検証アプリケーションプログラム、および前記検証アプリケーションプログラムを検証すべき条件である走行環境条件を格納するサーバ記憶部と、前記車両から取得した車両情報および前記走行環境条件に基づき前記検証アプリケーションプログラムの検証優先度を決定し、前記走行環境条件と、前記検証アプリケーションプログラムと、前記検証優先度と、を含む検証計画情報を生成する検証計画情報生成部と、前記検証計画情報を前記車両に出力する検証計画情報出力部と、を備える。
本発明の第３の態様による検証システムは、車両に搭載される車載制御装置および前記車載制御装置と通信可能なサーバを含む、検証システムであって、前記サーバは、前記車両において検証されるアプリケーションプログラムである検証アプリケーションプログラム、および前記検証アプリケーションプログラムを検証すべき条件である走行環境条件を格納するサーバ記憶部と、前記車両から取得した車両情報および前記走行環境条件に基づき前記検証アプリケーションプログラムの検証優先度を決定し、前記走行環境条件と、前記検証アプリケーションプログラムと、前記検証優先度と、を含む検証計画情報を生成する検証計画情報生成部と、前記検証計画情報を前記車両に出力する検証計画情報出力部と、を備え、前記車載制御装置は、前記サーバが出力した前記検証計画情報を取得する検証計画情報取得部と、前記車両の走行制御に関する基本アプリケーションプログラムと並行して、前記検証アプリケーションプログラムの検証の実行を前記走行環境条件と前記検証優先度に基づき制御する検証実行制御部と、を備える。

本発明によれば、複数の検証アプリケーションプログラムを効率よく検証できる。

検証システムのブロック図 車両のブロック図 データの流れを示す図 走行環境条件の一例を示す図 検証計画情報の一例を示す図 予測情報の一例を示す図 検証実行スケジュールの定義処理を示すフローチャート 進捗情報の一例を示す図 検証計画情報の生成処理を示すフローチャート

自動運転を実現する制御アプリケーションは、車両の周辺の多様な車両周辺環境データに対して正しく動作する必要がある。アプリケーションの正常動作確認を担保するため、アプリケーション開発中に、車両周辺環境データを入力とした検証を行う必要がある。検証に用いる車両周辺環境データを用意する方法としては、実車を使い車両周辺環境データを収集することや、シミュレータを用いて人工的に生成することが挙げられる。車両周辺環境データとしては、歩行者、車両、道路状況、天候をはじめとして、実世界の多様な状況を想定する必要があり、そのような車両周辺環境データをシミュレータだけで網羅的に模擬するのは一般的に困難とされている。そのため、実際の車両において走行中に得られる車両周辺環境データを活用しての検証は欠かせないと考えられている。

実車において収集したデータを活用する検証タイミングとして、リアルタイムに検証するオンライン検証と、ログデータをデータセンタ側に送って、データセンタ側でアプリケーションの検証を行うオフライン検証の2通り存在する。オフライン検証では、アプリケーションの検証に用いるデータをデータセンタ側に送る際の、データ量が膨大であり通信負荷が大きいことが欠点としてあるため、本発明では、オンライン検証を扱う。

オンライン検証の場合にも、実車走行が手動運転されている場合と自動運転となっている場合で、検証の課題が異なる。人が運転する手動運転の場合は、検証に対して用いることができる余剰のＣＰＵリソースが潤沢にある。一方で自動運転の場合は、自動運転のアプリケーション処理でＣＰＵリソースが使用されるため、検証に対して用いられるＣＰＵリソースが手動運転時に比べ小さい。将来的には自動運転車が普及すると見込まれるため、この自動運転中に得られる車両周辺環境データを用いて、ＣＰＵリソースが小さい中にあっても、効率的にアプリケーションの検証を行う必要がある。本形態では、車載制御装置上で複数のアプリケーションの複数の走行環境条件において検証のスケジュールを制御する技術を説明する。

以下、図面を参照して、車両群を跨いで検証を管理する検証管理サーバと演算装置である車載制御装置からなる検証システムの実施の形態を説明する。なお、本実施形態では、本発明の適用先の車載制御装置の一例として、先進運転支援システム（ＡＤＡＳ：Ａｄｖａｎｃｅｄ Ｄｒｉｖｅｒ Ａｓｓｉｓｔａｎｃｅ Ｓｙｓｔｅｍｓ）や自動運転システムにおいて車両の運転支援又は走行制御を処理する装置を扱うが、これに限らず他のシステムであってもよい。

―第１の実施の形態―
以下、図１〜図９を参照して、検証システムの第１の実施の形態を説明する。

（システム構成）
図１は、本発明による検証システム１の構成の一例を示すブロック図である。ただし図１では作図の都合により車両２の構成を簡略して記載しており、詳細は図２に記載する。

図１に示すように、本実施例に係る検証システム１は、１台以上の車両２と、１台以上の車両２に対して車載アプリケーションの検証を管理する検証管理サーバ１０とを含んで構成される。それぞれの車両２と検証管理サーバ１０は、ネットワーク３を経由して接続される。まず図２を参照して車両２の構成を説明する。

（車両の構成）
車両２は、車載制御装置２１と、無線通信装置２０と、外界センサ群２２と、車両センサ群２３と、アクチュエータ群２４と、車載ネットワーク２５と、を有する。

（車載制御装置の構成）
車載制御装置２１は、例えば、車両２に搭載されたＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）等であり、処理部２２０と、車載記憶部２１０と、通信部２３０と、を有する。なお、車載制御装置２１の形態に特に制限はなく、例えば、車両２の位置推定を行うための車両位置推定装置でもよいし、車両２のＡＤＡＳを実現するための走行制御装置でもよい。さらに車載制御装置２１は、外界センサから取得した周辺環境データから周辺物体の検出を行う周辺物体検出処理装置でもよいし、車両２のユーザが車両２の内部ネットワークに接続したスマートフォン等の外部装置でもよい。

処理部２２０は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ：中央演算処理装置）及びＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などを含んで構成され、所定の動作プログラムを実行することで、車載制御装置２１の機能を実現する処理を行う。また、処理部２２０には、機能ブロックとして、センサ入力部２２１、アクチュエータ出力部２２２、基本アプリ実行制御部２２３、検証アプリ実行制御部２２４、検証計画情報取得部２２５、検証結果出力部２２６、および走行環境条件成立予測部２２７、を備える。処理部２２０は、車載制御装置２１に外部から停止命令が入力されると、センサ入力部２２１、アクチュエータ出力部２２２、基本アプリ実行制御部２２３、検証アプリ実行制御部２２４、検証計画情報取得部２２５、検証結果出力部２２６、走行環境条件成立予測部２２７に停止命令を出力する。

センサ入力部２２１は、車両の周辺に関連する周辺環境情報と、車両の動きに関連する車両センサ情報とを外界センサ群２２および車両センサ群２３から取得して、これらを車載記憶部２１０に不図示のアプリケーション入出力データ群として格納する。周辺環境情報とは、たとえば車両の周辺に存在する障害物の情報や、車両の周辺における道路の特徴を示す特徴物等の情報等である。なお車両の周辺に存在する障害物とは、たとえば車両の周囲を移動している他車両、自転車、歩行者等の移動体や、車両の周囲の道路上で静止している駐車車両、落下物、設置物等である。車両センサ情報とは、たとえば車両の位置、走行速度、操舵角、アクセルの操作量、ブレーキの操作量等である。センサ入力部２２１により取得された周辺環境情報と車両センサ情報は、アプリケーション入出力データ群として車載記憶部２１０に格納される。

アクチュエータ出力部２２２は、車載記憶部２１０に格納される不図示のアプリケーション入出力データ群から制御情報を取得し、車載ネットワーク２５に接続されたアクチュエータ群２４に対して出力する。

基本アプリ実行制御部２２３は、車載記憶部２１０に格納されている基本アプリケーションプログラム２１１の実行スケジュールに基づいて、車載制御装置２１上の１つ以上のＣＰＵ上で基本アプリケーションプログラム２１１を実行および制御する。基本アプリケーションプログラム２１１とは、検証が完了しており車載制御装置上でメインのアプリケーションとして実行されるプログラムである。基本アプリケーションプログラム２１１は、検証が既に完了している点で、検証アプリケーションプログラム２１２とは異なる。

基本アプリケーションプログラム２１１はたとえば、位置推定を行うための車両位置推定アプリケーション、先進運転支援システムを実現するための走行制御アプリケーション、完全自動運転を実現するための自動運転アプリケーション、および外界センサから取得した周辺環境データから周辺物体の検出を行う周辺物体検出アプリケーションのいずれかである。

基本アプリケーションプログラム２１１の実行スケジュールとは、アプリケーションを逐次的または並列的に動作させるときの動作開始や終了のタイミング、および動作周期等が定義されたものである。たとえば、周期が１０ｍｓと設定されたアプリケーションに対しては、基本アプリ実行制御部２２３が１０ｍｓで当該アプリケーションを実行する。たとえば、データ並列化が設定されたアプリケーションに対しては、１つ以上のＣＰＵ上でアプリケーションを決められたタイミングで実行する等の制御を基本アプリ実行制御部２２３が行う。なお基本アプリケーションプログラム２１１の実行スケジュールは、不図示である。

検証アプリ実行制御部２２４は、車載記憶部２１０の検証計画情報２１３に格納されている検証アプリケーションプログラム２１２を、車載制御装置２１上の１つ以上のＣＰＵ上で実行および制御する。検証アプリケーションプログラム２１２は、検証管理サーバ１０からネットワーク３を経由して、検証計画情報取得部２２５にて取得される。検証アプリケーションプログラム２１２は、後に詳述する検証実行スケジュール２１９Ａに基づき実行される。

検証アプリケーションプログラム２１２は、基本アプリケーションプログラム２１１と同一のＣＰＵ上で実行されてもよく、また異なるＣＰＵ上で実行されるよう隔離されていてもよい。また、検証アプリケーションプログラム２１２および基本アプリケーションプログラム２１１は、同一のＯＳ上で実行されてもよいし、また異なるＯＳ上で実行されるよう隔離されていてもよい。

この検証アプリケーションプログラム２１２のそれぞれには検証優先度２１５が設定されており、車載制御装置２１は検証優先度２１５にしたがって検証を行う。検証優先度２１５は、検証管理サーバ１０が、車両２では不可知の情報や複数の車両２での検証の進捗等に基づいて作成するので、車載制御装置２１は効率よく検証を実行できる。

検証計画情報取得部２２５は、検証管理サーバ１０から検証アプリケーションプログラム２１２と、検証方法定義２１４と、走行環境条件２１６と、検証優先度２１５とを含む検証計画情報２１３を取得し、車載記憶部２１０に格納する。検証計画情報２１３は、たとえばテーブルのフォーマットで表され、複数のエントリを有する。このエントリを以下では「検証計画エントリ」とも呼ぶ。検証計画エントリは、検証アプリケーションプログラム２１２と走行環境条件２１６の組合せごとに作成され、各検証計画エントリは、検証方法定義２１４と検証優先度２１５とを含む。

検証方法定義２１４は、検証アプリケーションプログラム２１２の検証方法の定義である。検証方法定義２１４の例としては、アプリケーションの出力値が直接定義されていてもよく、また基本アプリケーションプログラム２１１の出力値との比較で定義されていてもよい。走行環境条件２１６とは、検証アプリケーションプログラム２１２の検証を行うべき、車両の内外の環境条件である。

検証結果出力部２２６は、検証アプリケーションプログラム２１２に関する検証の結果を検証結果２１８として検証アプリ実行制御部２２４から取得し、車両２に関する車両情報２１９とともに検証管理サーバ１０へ出力する。検証結果２１８には、例えば１つ以上の検証アプリケーションプログラム２１２ごとの検証の進捗情報が含まれる。車両情報２１９には、車両２の位置、速度、操舵情報、走行軌道情報、走行ルート情報を含む、車両２にて取得される車両２に関する情報が含まれる。この車両情報２１９は、例えば、検証アプリケーションプログラム２１２または基本アプリケーションプログラムが出力する情報でもよく、車両センサ群２３や外界センサ群２２やアクチュエータ群２４が出力する情報でもよい。

走行環境条件成立予測部２２７は、走行環境条件２１６が成立するタイミングおよび成立しなくなるタイミングを事前に予測し、走行環境条件予測情報２１７を作成して車載記憶部２１０に格納する。走行環境条件成立予測部２２７は例えば、車両情報２１９と、走行環境条件２１６を照らし合わせて予測を行う。

車載記憶部２１０は、たとえば、ＨＤＤ（ＨＡＲＤ Ｄｉｓｋ Ｄｒｉｖｅ）やフラッシュメモリである。ただしＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）を含んで構成されてもよい。車載記憶部２１０には、処理部１００がその機能を実現するために実行するプログラム、周期的に実行されるアプリケーションプログラム、車載制御装置２１が動作するために必要なデータ群などが格納される。具体的には、車載記憶部２１０には、基本アプリケーションプログラム２１１、検証アプリケーションプログラム２１２、検証計画情報２１３、検証方法定義２１４、検証優先度２１５、走行環境条件２１６、走行環境条件予測情報２１７、検証結果２１８、車両情報２１９、および検証実行スケジュール２１９Ａが格納される。

基本アプリケーションプログラム２１１は、ＡＤＡＳや自動運転向けの制御プログラムなどである。基本アプリケーションプログラム２１１はたとえば、位置推定を行うための車両位置推定アプリケーション、先進運転支援システムを実現するための走行制御アプリケーション、完全自動運転を実現するための自動運転アプリケーション、および外界センサから取得した周辺環境データから周辺物体の検出を行う周辺物体検出アプリケーションのいずれかである。

基本アプリケーションプログラム２１１は、不図示のアプリケーション入出力データ群を入出力する。このアプリケーション入出力データ群は、基本アプリケーションプログラム２１１に入力される情報、およびアプリケーションから出力される情報である。具体的にはアプリケーション入出力データ群は、車両の周辺に関連する周辺環境情報や、車両の動きに関連する車両センサ情報、およびアプリケーションがそれらを処理した情報である。このアプリケーション入出力データ群に含まれる、所定の対象要素に対応するデータの集合を、「オブジェクトデータ」と呼称し、このオブジェクトデータを単位としてデータの管理及び操作を行う。

ここで、「対象要素」とは、オブジェクトデータとして一纏めにした個々の情報要素が共通して表現する概念的な対象である。対象要素とは例えば、センサの検出対象やアクチュエータの制御対象、さらにはアプリケーションの演算処理結果である。好ましくは、特に、外界センサにおいては、認識された個々の環境要素（障害物、道路形状、交通ルール等）が対象要素に該当する。即ち本実施の形態では、外界センサというハードウエアそのものを抽象化するのではなく、検出対象である環境要素を単位として、データを抽象化する方式を採る。なお、内界センサについては、自車両という概念でオブジェクトデータを構成してもよいし、個々の検出対象ごと、たとえば車速センサであれば車速情報ごとにオブジェクトデータを構成してもよい。以下では、オブジェクトデータをデータと呼ぶ。

検証アプリケーションプログラム２１２は、基本アプリケーションプログラム２１１と異なり検証を要するプログラムである。検証アプリケーションプログラム２１２は、検証管理サーバ１０からネットワーク３を経由して、検証計画情報取得部２２５にて取得される。検証アプリケーションプログラム２１２は、検証計画情報取得部２２５にて取得された検証計画情報２１３に基づいて、実行がスケジューリングされる。

検証アプリケーションプログラム２１２は、基本アプリケーションプログラム２１１と同一のＣＰＵ上で実行されてもよく、また異なるＣＰＵ上で実行されるよう隔離されていてもよい。また検証アプリケーションプログラム２１２は、基本アプリケーションプログラム２１１と同一のＯＳ上で実行されてもよいし、基本アプリケーションプログラム２１１とは異なるＯＳ上で実行されるように隔離されてもよい。

検証計画情報２１３は後述する図４に示すデータフォーマットからなるデータであり、各検証計画エントリには、検証アプリケーションプログラム２１２と、検証方法定義２１４と、検証優先度２１５と、走行環境条件２１６とを含む。

検証方法定義２１４は、検証計画エントリごとに定義される、アプリケーションの検証方法の定義である。この定義は、想定される正常な出力値の範囲でもよいし、出力が同一となるべき基本アプリケーションプログラム２１１を特定する情報でもよい。たとえば検証アプリケーションプログラム２１２が、特定の基本アプリケーションプログラム２１１（以下、「同一機能基本アプリ」と呼ぶ）と同一の機能を有し、アルゴリズムを改善して実行速度を向上させた場合には、その検証アプリケーションプログラム２１２の検証方法定義２１４はたとえば、”同一機能基本アプリと出力が同一”と定義される。この既存のアプリケーションの出力値は、基本アプリケーションプログラム２１１として走行中に動作させその結果を逐次比較してもよく、また、事前に既存のアプリケーションの出力値を検証方法定義として保持しておき、それと比較することでもよい。

検証優先度２１５は、検証計画エントリごとに定義される。この検証優先度２１５は、検証管理サーバ１０から取得されて、車載制御装置２１の車載記憶部２１０に格納される。検証アプリ実行制御部２２４は、この検証優先度２１５を含む検証計画情報２１３に基づいて、検証実行スケジュール２１９Ａを作成することで、検証アプリケーションプログラム２１２の実行をスケジューリングする。

走行環境条件２１６は、検証アプリケーションプログラム２１２に対して定義される１つ以上の、検証を行うべき走行環境を定義した設定情報である。この走行環境条件２１６と検証アプリケーションプログラム２１２との組に対して、各検証計画エントリが存在する。例えば、検証アプリケーションプログラム２１２が認知アプリケーションプログラムの場合は、走行環境条件２１６は、”交差点領域にいる場合”などの走行環境が設定されている。

走行環境条件予測情報２１７は、走行環境条件２１６が成立するタイミングおよび成立しなくなるタイミングに関する情報が記載されている。走行環境条件予測情報２１７は、走行環境条件成立予測部２２７により作成される。こ走行環境条件成立予測部２２７は例えば、車両情報２１９と、走行環境条件２１６とを照らし合わせて走行環境条件予測情報２１７を作成する。この走行環境条件予測情報２１７は、走行環境条件２１６が成立する将来時間や、非成立になる将来時間、成立頻度や持続時間、成立確率などの情報を含む。

検証結果２１８は、検証計画情報２１３の検証計画エントリごとの、検証の成否や進捗を示す情報である。検証アプリ実行制御部２２４により、検証方法定義２１４に従って検証の成否が記される。また検証が完了する前でも、検証方法定義２１４に従って、検証アプリ実行制御部２２４により検証の進捗情報が記される。この検証結果２１８は検証結果出力部２２６から検証管理サーバ１０へ出力される。

車両情報２１９は、車両２の位置、速度、操舵情報、走行軌道情報、走行ルート情報などが含まれ、車両２にて取得される車両２に関する車両情報が含まれる。この車両情報２１９は、例えば、検証アプリケーションプログラム２１２または基本アプリケーションプログラムが出力する情報でもよく、車両センサ群２３や外界センサ群２２やアクチュエータ群２４が出力する情報でもよい。

検証実行スケジュール２１９Ａは、検証アプリケーションプログラム２１２を実行するスケジュールの情報である。検証実行スケジュール２１９Ａは、検証アプリ実行制御部２２４により作成される。この作成には、検証アプリケーションプログラム２１２と、走行環境条件２１６と、検証優先度２１５と、走行環境条件２１６と、走行環境条件予測情報２１７と、を含む情報が利用される。なお以下では、検証実行スケジュール２１９Ａを作成、更新、変更することを「検証スケジュールを行う」や「検証のスケジューリングを実行する」とも表現する。

通信部２３０は、例えば、イーサネット（登録商標）又はＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）等の通信規格に準拠したネットワークカード等を含んで構成される。通信部２３０は、車両２に搭載された他の装置と各種プロトコルに基づきデータの送受信を行う。なお、通信部２３０と車両２に搭載された他の装置との間の接続形態は、イーサネットのような有線接続に限定されることはなく、Ｂｌｕｅｔｏｏｔｈ（登録商標）や無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）などの近距離無線接続であってもよい。

無線通信装置２０は、例えば、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）等の長距離無線通信規格、または無線ＬＡＮやＤＳＲＣ（Ｄｅｄｉｃａｔｅｄ Ｓｈｏｒｔ Ｒａｎｇｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）等の近距離無線通信規格に準拠したネットワークカード等を有する。無線通信装置２０はたとえば、検証管理サーバ１０、１台又は複数台の他車両に搭載された無線通信装置２０、１台又は複数台の人等が保有する不図示の通信端末等、とデータ通信が可能に構成される。

無線通信装置２０は、検証管理サーバ１０とネットワーク３を介してデータ通信を行う。無線通信装置２０は、好ましくは、長距離無線通信を用いてネットワーク３に接続し、例えば、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）系の各種プロトコルなどに基づいて生成されたデータの送受信を行う。なお、無線通信装置２０は、長距離無線通信に限らず、近距離無線通信を用いてネットワーク３に直接接続しても良いし、路側機等の他の通信装置を介してネットワーク３に接続しても良い。

外界センサ群２２は、車両周辺の一定範囲の障害物、たとえば他車両、歩行者、物体などや、道路標識や白線などの特徴物を認識するセンサ群である。外界センサ群２２は、たとえば、カメラ、レーダ、ライダ等により構成される。外界センサ群２２は、検出した車両周辺の障害物や特徴物の情報、たとえば車両からの相対距離と相対角度などを、外界センサ群２２や車載制御装置２１が接続されている車載ネットワーク２５に出力する。車載制御装置２１は、この車載ネットワーク２５を介して外界センサ群２２からの出力結果を取得できる。なお本実施の形態では、外界センサ群２２で障害物や特徴物を検出する処理を実施する構成になっているが、外界センサ群２２から出力される信号やデータを用いて車載制御装置２１や他装置でこれらの検出処理を行ってもよい。

車両センサ群２３は、車両の動きに関する情報、たとえば走行速度、操舵角、アクセルの操作量、ブレーキの操作量などを検出する装置群である。車両センサ群２３は、たとえば、車載ネットワーク２５上に検出したこれらの状態量を出力する。車載ネットワーク２５に接続された車載制御装置２１や他装置は、この車載ネットワーク２５を通じて、車両センサ群２３から出力された各種部品の状態量を取得する。

アクチュエータ群２４は、車両の動きを決定する操舵、ブレーキ、アクセル等の制御要素を制御する装置群である。アクチュエータ群２４は、運転者によるハンドル、ブレーキペダル、アクセルペダル等の操舵情報や、車載制御装置２１から出力される目標制御値に基づいて車両の動きを制御する。

ネットワーク３は、無線および有線の少なくとも一方を媒体とする回線交換網又はパケット交換網の任意の組み合わせで構成される通信ネットワークである。ネットワーク３は、検証管理サーバ１０と車両２に搭載された無線通信装置２０とが相互にデータを送受信可能となるように構成される。車載制御装置２１は、無線通信装置２０を介して、ネットワーク３を経由して検証管理サーバ１０と通信する。

（検証管理サーバの構成）
図１に戻って検証管理サーバ１０の構成を説明する。検証管理サーバ１０は、車両２の車載制御装置２１で動作するアプリケーションプログラムの検証を計画し、その進捗を管理する。なお図１では検証管理サーバ１０は１つのハードウエア装置として記載しているが、複数のハードウエア装置から構成されてもよい。検証管理サーバ１０は、処理部１００とサーバ記憶部１１０と通信部１２０と、を有する。

処理部１００は、例えば、ＣＰＵ及びＲＡＭなどを含んで構成され、所定の動作プログラムを実行することで、検証管理サーバ１０の機能を実現する。また、処理部１００には、機能ブロックとして、１つ以上の車両２から検証結果情報を受信する検証結果取得部１０２や走行環境条件成立予測部１０４を有する。また処理部１００には、検証アプリケーションプログラムごとの検証計画情報を生成する検証計画情報生成部１０３、検証計画情報を車両２に送信する検証計画情報出力部１０１等が含まれる。

検証計画情報出力部１０１は、車両２に対して、サーバ記憶部１１０に格納されている検証アプリケーションプログラム１１１と、検証方法定義１１２と、検証優先度１１３と、走行環境条件１１４とを含む検証計画情報２１３を出力する。

検証結果取得部１０２は、車両２から送信された、検証アプリケーションプログラム１１１に関する検証結果情報を取得し、車両２に関する車両情報とともにサーバ記憶部１１０に格納する。検証結果情報には、１つ以上の検証アプリケーションプログラム２１２ごとの検証の進捗情報が含まれる。

検証計画情報生成部１０３は、検証進捗情報１１５と走行環境条件予測情報１１６に基づき、検証計画情報１１７を生成する。この検証計画情報１１７の各エントリには検証アプリケーションプログラム、検証方法定義、走行環境条件、検証優先度、等が含まれる。

走行環境条件成立予測部１０４は、１または複数の車両２から車両情報２１９を受け取る。走行環境条件成立予測部１０４は、検証アプリケーションプログラム１１１の走行環境条件１１４が、いずれの車両２にて近い将来に満たされるかを予測し、走行環境条件予測情報１１６を検証計画情報生成部１０３に渡す。この走行環境条件成立予測部１０４では、車両２では不可知の情報と、車両２の車両情報２１９を用いて、走行環境条件１１４の成立予測を行ってよい。例えば検証管理サーバ１０が、車両２は不可知の、特定地域の渋滞情報を保持していた場合、その渋滞情報と車両２の車両情報を用いて走行環境条件の成立予測を行ってよい。

サーバ記憶部１１０は、例えば、ＨＤＤ、フラッシュメモリ、ＲＯＭなどの記憶装置を含んで構成され、処理部１００が実行するプログラム、及び本システムの実現に必要なデータ群などが格納される。本実施例では、特に、検証アプリケーションプログラム１１１、検証方法定義１１２、検証優先度１１３、走行環境条件１１４、検証進捗情報１１５、走行環境条件予測情報１１６、および検証計画情報１１７がサーバ記憶部１１０に格納される。

検証アプリケーションプログラム１１１は、車載制御装置２１上の検証アプリケーションプログラム２１２と同様に、車載制御装置２１上で検証を要するものである。検証アプリケーションプログラムごとに走行環境条件１１４、検証方法定義１１２、検証優先度１１３、等が定義されている。検証管理サーバ１０が検証アプリケーションプログラム１１１を車載制御装置２１上へ送信する。

検証方法定義１１２は、車載記憶部２１０に格納される検証方法定義２１４と同様であってよい。検証優先度１１３は車載記憶部２１０に格納される検証優先度２１５と同様であってよい。走行環境条件１１４は、車載記憶部２１０に格納される走行環境条件２１６と同様であってよい。走行環境条件１１４には、検証管理サーバ１０にのみ知ることができ意味がある情報が含まれてもよい。

検証進捗情報１１５は、例えば進捗値で表され、検証の進捗を示す。この値の進捗表現値は検証アプリケーションプログラム２１２に依存し、検証アプリケーションプログラム２１２のカバレッジを示す場合や、検証アプリケーションプログラム２１２を検証動作させる目標時間に対するその時の検証実行時間の割合を示す場合がある。

走行環境条件予測情報１１６は、走行環境条件１１４が成立するタイミングおよび成立しなくなるタイミングを示す情報である。検証計画情報１１７は、検証計画情報生成部１０３が生成する情報であり、検証アプリケーションプログラム１１１と、検証方法定義１１２と、検証優先度１１３と、走行環境条件１１４とを含む。

通信部１２０は、例えば、イーサネット又はＣＡＮ等の通信規格に準拠したネットワークカード等を含んで構成され、検証管理サーバ１０に搭載された他の装置と各種プロトコルに基づきデータの送受信を行う。なお、通信部１２０と検証管理サーバ１０に搭載された他の装置との間の接続形態は、イーサネットのような有線接続に限定されることはなく、Ｂｌｕｅｔｏｏｔｈや無線ＬＡＮなどの近距離無線接続であってもよい。

図３は、検証システム１における検証管理サーバ１０の処理部１００と、車両２の車載制御装置２１の処理部２２０との間のデータの流れを示す図である。

検証管理サーバ１０は、車載制御装置２１に対して検証計画情報２４０を送信する。この通信のタイミングは、車両２が検証管理サーバ１０に対して送信要求を出した際に車両２から送信してもよく、また検証管理サーバ１０が任意のタイミングで車両２に対して送信してもよい。また、複数の車両２に対して同時に送信してもよい。ただし、すべての車両２に対して送信する必要はなく、いずれかの１台以上の車両に送信する。また、検証管理サーバ１０から車両２に直接の送信を行わず、別の車両や別のサーバを経由して車両２に到達してもよい。検証管理サーバ１０は、送信先のすべての車両２に対して同一の検証計画情報２４０を送信してもよいし、車両２ごとに異なる検証計画情報２４０を送信してもよい。

車両２上の車載制御装置２１は、検証管理サーバ１０に対して検証結果２１８と車両情報２１９を送信する。この通信のタイミングは、検証管理サーバが車両2に対して送信要求を出した際に車両２から送信しても、また車両２が任意のタイミングで検証管理サーバ１０に送信してもよい。また、車両２から別の車両やサーバを経由して検証管理サーバ１０へ到達してもよい。

検証管理サーバ１０の検証結果取得部１０２は、１または複数の車両２から検証結果２１８を受け取る。この検証結果２１８には１または複数の検証アプリケーションプログラム２１２に関する検証結果として検証の成否または進捗情報が格納されている。検証結果取得部１０２は、検証進捗情報１１５として検証計画情報生成部１０３に渡す。

走行環境条件成立予測部１０４は、１または複数の車両２から車両情報２１９を受け取る。走行環境条件成立予測部１０４は、走行環境条件１１４がいずれの車両２にて近い将来に満たされるかを予測して走行環境条件予測情報１１６を生成し、走行環境条件予測情報１１６を検証計画情報生成部１０３に渡す。走行環境条件成立予測部１０４では、車両２では不可知の情報と、車両２の車両情報２１９とを用いて、走行環境条件の成立予測を行ってよい。例えば、車両２は不可知の、特定地域の渋滞情報を検証管理サーバ１０が保持していた場合、その渋滞情報と車両２の車両情報を用いて走行環境条件の成立予測を行ってよい。この成立予測に基づいて検証計画情報生成部１０３で検証優先度を定義することにより、検証アプリケーションプログラム２１２の検証をさらに効率化できる。

検証計画情報生成部１０３は検証進捗情報１１５と走行環境条件予測情報１１６とに基づき、検証計画情報１１７を生成する。この検証計画情報１１７の各エントリには検証アプリケーションプログラム、検証方法定義、走行環境条件、検証優先度、等が含まれる。車載制御装置２１の検証計画情報取得部２２５は、検証計画情報１１７を取得する。

走行環境条件成立予測部２２７は、車両情報２１９と検証計画エントリに含まれる走行環境条件２１６が満たされるか否か予測し、走行環境条件予測情報２１７を生成する。この際、検証管理サーバ１０で予測された走行環境条件予測情報１１６を車載制御装置２１が予め受信し、この走行環境条件予測情報１１６と組み合わせて走行環境条件予測情報２１７を生成してもよい。

検証アプリ実行制御部２２４は、検証計画情報２１３をもとに検証アプリケーションプログラム２１２の検証を行う。その際に検証アプリ実行制御部２２４は、基本アプリ実行制御部２２３からデータの入出力を受けてもよい。また図３には記載していないが、検証アプリ実行制御部２２４は検証アプリケーションプログラム２１２の検証を行う際に外界センサ群２２や車両センサ群２３からデータの入力を受けてもよい。検証アプリ実行制御部２２４は、検証の結果を検証結果２１８として生成する。この検証結果２１８には、１つ以上の検証計画情報２１３ごとの検証の進捗情報が含まれる。検証結果出力部２２６は、検証結果２１８を検証アプリ実行制御部２２４から受け取り、車両情報２１９とともに検証管理サーバ１０へ送信する。

図４は、検証管理サーバ１０のサーバ記憶部１１０に格納される走行環境条件１１４のデータのフォーマットの一例を示す図である。このフォーマットは、車載記憶部２１０の走行環境条件２１６に格納されているデータのフォーマットと同一である。走行環境条件１１４は１以上のエントリを有し、各エントリは検証アプリケーションプログラム名３０１と走行環境条件３０２のフィールドを有する。

検証アプリケーションプログラム名３０１のフィールドには、検証対象となる検証アプリケーションプログラム２１２を特定する１または複数の名称が格納される。この識別子は車両２が一意に特定することができればよく、自然言語でなく識別子でもよい。

走行環境条件３０２のフィールドには、検証アプリケーションプログラム２１２の検証を実行すべき走行環境の条件が格納される。同一の検証アプリケーションプログラム名３０１に対して、複数の走行環境条件３０２を設定可能である。検証アプリケーションプログラム名３０１と走行環境条件３０２の組で一意となっている必要がある。この走行環境条件３０２は自然言語で設定されており検証アプリ実行制御部２２４で解析してもよいし、コンピュータで処理する特定の言語体系で記載されていてもよい。

走行環境条件３０２はたとえば、場所の条件として「車両が交差点領域にいる場合」、「車両が高速道にいる場合」、「車両がＸＸ国にいる場合」等がある。この判定条件となる車両の位置情報は、走行中にセンサ群または基本アプリケーションプログラムから提供される。また、周辺環境の条件として「周辺車両がＸ台存在する場合」、「歩行者がＹ人存在する場合」等がある。この判定条件となる周辺環境に関する情報は、走行中にセンサ群や基本アプリケーションプログラム２１１から提供される。また、車種に関する条件として設定してもよく、例えば「車種ＸＸ上で動作する場合」などと条件が指定されてもよい。また、天候等の条件として「曇り」「雨」などの条件を指定してもよい。また、日付や時刻で指定してもよく、例えば「Ｙ時〜Ｚ時」などの条件で指定してもよい。

また、複数の条件を統合して記載してもよく、例えば「高速道にいる場合かつＹ時〜Ｚ時の間」などの条件で指定してもよく、「高速道にいる場合またはＹ時〜Ｚ時の間」などの条件で指定してもよい。また、基本アプリケーションプログラムや他の検証アプリケーションプログラムの出力や入力を監視し、その入出力データを走行環境条件としてもよい。例えば走行環境条件を「基本アプリケーションプログラムの認知アプリＣが、特定のデータＤを出力している場合」としてもよい。また、基本アプリケーションプログラム２１１や他の検証アプリケーションプログラム２１２の実行を監視し、その実行状況を走行環境条件としてよく、例えば「検証アプリケーションプログラムＤが動作している場合」などと指定してもよい。

この走行環境条件３０２は、アプリケーションの開発者が手動で設定してもよいし、検証計画情報生成部１０３が検証アプリケーションプログラム１１１を解析して自動で設定されてもよい。例えば、プログラム上のすべての分岐をカバーするように走行環境条件３０２が自動で設定されてもよい。

この走行環境条件１１４は、検証アプリケーションプログラム２１２や走行環境条件３０２が細かく設定されるとサイズが大きくなるため、検証管理サーバ１０ではオリジナルの走行環境条件１１４を保持しておくものの、車載制御装置２１へ送信される走行環境条件１１４は、検証実行が行われるアプリケーションプログラムに関する設定のみ抽出されたサブセットだけであってもよい。

図５は、検証管理サーバ１０の検証計画情報生成部１０３で生成される検証計画情報２１３の一例を示す図である。検証計画情報２１３は複数のエントリを含み、各エントリは検証アプリケーションプログラム名３０１と、走行環境条件３０２と、空きＣＰＵリソース条件４０３と、優先度４０４と、検証方法定義４０５とを含む。検証計画情報２１３は必ずしも一つのデータとして統合されている必要はなく、複数のデータ群として存在しそれらが紐づいている形で存在していてもよい。例えば、図４に記載の走行環境条件１１４と、各走行環境条件に対する優先度と、空きＣＰＵリソース条件と、検証方法定義とが別個に定義されていてもよい。また、ＣＰＵリソース条件４０３、優先度４０４、および検証方法定義４０５は、静的に定義されている必要はなく、例えば車両２の車種ごとに異なる設定情報として保持されてもよい。ここでは図５の記載に沿って説明する。

検証計画情報２１３のそれぞれの検証計画エントリは、検証アプリケーションプログラム名４０１と走行環境条件４０２の組合せに対して一意に存在する。各検証計画エントリには、優先度４０４と空きＣＰＵリソース条件４０３と検証方法定義４０５とがそれぞれ設定される。優先度４０４、空きＣＰＵリソース条件４０３、および検証方法定義４０５は同一の内容が設定されていても構わない。検証アプリケーションプログラム名３０１および走行環境条件３０２は図４において説明したとおりなので説明を省略する。

空きＣＰＵリソース条件４０３は、検証計画情報１１７や検証計画情報２１３に含まれるデータ要素であり、検証アプリケーションプログラム２１２の検証を行う際に必要となるＣＰＵリソースを示すものである。空きＣＰＵリソース条件４０３に記載される値は、事前に計測した、または走行中に更新された、検証時に消費されるＣＰＵリソースの平均値や最大値などの値である。空きＣＰＵリソース条件４０３の値が大きいほど検証には多くのＣＰＵリソースを消費することを意味する。

優先度４０４は、車載制御装置２１上の検証アプリ実行制御部２２４が、検証実行スケジュール２１９Ａの作成の際に参照する情報であり、これに基づいて、検証アプリケーションプログラム２１２を検証する順序を決定する。優先度４０４の値が大きいほど優先して検証が行われる。例えば、走行環境条件４０２が満たされており、さらに空きＣＰＵリソース条件４０３も満たされているときには、検証アプリケーションプログラム２１２のうち優先度が高いものから検証が行われる。

例えば、検証計画情報２１３が図５に示す例のとおりであり、天気が曇りであり、かつ空きＣＰＵリソースが１０％以上存在している場合には、優先度が「２０」の「認知アプリＡ」ではなく、優先度が「３０」の「認知アプリＢ」の検証が優先的にスケジューリングされる。ただし検証のスケジューリング方法は、優先度だけでなく他の情報も併せて、検証アプリ実行制御部２２４にて特定のアルゴリズムで制御されてもよい。この優先度の定義は検証管理サーバ１０の検証計画情報生成部１０３にて行われてもよいし、車載制御装置２１上の走行環境条件成立予測部で、成立予測に基づいて定義を修正してもよい。

検証方法定義４０５は、検証アプリケーションプログラム２１２の検証方法の定義である。検証アプリ実行制御部２２４は、この検証方法定義４０５に従って、実行した検証アプリケーションプログラム２１２の検証成否および進捗情報を管理する。検証方法定義４０５はアプリケーションに依存して設定される項目である。例えば検証方法定義４０５には、検証アプリケーションプログラム２１２の適切な出力値の範囲が直接定義されてもよい。また検証方法定義４０５には、出力が同一になるべき基本アプリケーションプログラム２１１が指定されてもよい。具体例を説明する。

ここでは、検証アプリケーションプログラム２１２が既存の基本アプリケーションプログラム２１１を改良したものであるケースを想定する。この場合に、改良が機能自体は変更がなく、アルゴリズムが簡略化や効率化された場合などにはこの出力値を基本アプリケーションプログラム２１１の出力値と比較するのみで問題ないケースが多い。その一方で、改良が機能の変更である場合には、単純に基本アプリケーションプログラムのとの出力値の比較では対応できないことがある。その際には、検証アプリケーションプログラム２１２の適切な出力値を予め検証方法定義４０５に記載しておく。

さらに検証方法定義４０５には次のケースも考えられる。例えば、３つのアプリケーションプログラムである検証アプリケーションプログラムＡ、Ｂ、Ｃの検証を次のように省力化できる。検証アプリケーションプログラムＡ、Ｂ、Ｃを複数連成して動作させる場合に、アプリケーションプログラムＣの出力値を厳密にチェックすることで、前段のアプリケーションプログラムＡ、Ｂの検証を実質的には検証を済ませることが考えられる。

図６（ａ）〜（ｃ）は検証管理サーバ１０における走行環境条件予測情報１１６と、車載制御装置２１上の走行環境条件予測情報２１７のデータのフォーマットの例を３つ示す図である。ここでは代表して走行環境条件予測情報１１６のフォーマットとして説明する。検証管理サーバ１０における走行環境条件予測情報１１６と、車載制御装置２１上の走行環境条件予測情報２１７のデータのフォーマットとは、同一でもよいし異なってもよい。

図６（ａ）に示す例では、走行環境条件予測情報２１７をテーブルの形態で保持している場合のフォーマットを示す。走行環境条件予測情報２１７は、検証アプリケーションプログラム名５１１と、走行環境条件５１２と、直近の成立タイミング５１３と、直近の不成立タイミング５１４と、のカラムを含む。走行環境条件５１２に対して、直近の成立タイミング５１３と、直近の不成立タイミング５１４が定義されている。

図６（ａ）の１行目の例では、走行環境条件５１２が「交差点領域にいる場合」と定義されており、直近の不成立タイミングが５秒後、と定義されている。これは、この走行環境条件の内容が成立しており、はじめて不成立になるタイミングが５秒後であることを示している。車載制御装置２１上の検証アプリ実行制御部２２４は、例えば、この情報を用いて検証アプリケーションプログラム２１２が「認知アプリＡ」と走行環境条件２１６が「交差点領域にいる場合」の組に対する検証優先度２１５の値を大きくし、直近に優先的に検証が実行されるように調整する。これにより、将来の不成立がわかっているアプリケーションプログラムの走行環境条件に対して、優先的に検証を実行する制御が可能となる。

図６（ａ）の２行目の例では走行環境条件５１２が「周辺車両がＸ台存在する場合」と定義されており、直近の成立タイミングが５秒後、と定義されている。車載制御装置２１上の検証アプリ実行制御部２２４は、例えば、「認知アプリＡ」の走行環境条件２１６に対して検証を行いたい場合には、５秒後に検証スケジューリングを再実行するようにタイマーをかけることが考えられる。またその際に、検証計画情報２１３の優先度４０４を上げることが考えられる。これにより、走行環境条件２１６が不成立だったアプリケーションプログラムに対して、走行環境条件２１６が成立してから最短で優先的に実行するような制御が可能となる。

図６（ｂ）に示す例では、特定の検証アプリケーションプログラム２１２と走行環境条件２１６の組合せを対象とする走行環境条件予測情報２１７を、成立または非成立の２値の時系列データとして保持している。この例では、図６（ａ）に示す例では不可能であった、走行環境条件の複数回の成立および不成立を表現することができる。これにより例えば、現状成立しており５秒後に非成立し、６秒後にすぐ再度成立するケースにおいて、図６（ａ）の説明において述べたような優先度を上げる制御を行う必要がないことが表現できる。このように図６（ｂ）に示す例では、将来の一定期間における成立・非成立の頻度や成立時間の情報を保持できるので、これを用いた検証スケジュールの制御が可能となる。

図６（ｃ）に示す例では、特定の検証アプリケーションプログラム２１２と走行環境条件２１６の組合せを対象とする走行環境条件予測情報２１７を、成立確率の時系列データとして保持している。走行環境条件の成立予測を、例えば基本アプリケーションプログラム２１１の認知アプリケーションの結果を用いて行う場合に、その認知アプリケーションが出力を確率として表現する際に、それをそのまま予測情報として用いることができる。もし図６（ｂ）の例のように２値で表現せざるを得ない場合、例えば成立確率が０．５として本来存在する場合に、その情報を切り上げや切り捨てを行うので正確な情報を失ってしまう。予測情報としてそのまま確率として保持することができれば、より正確な予測情報に基づいて検証スケジュールの制御が可能となる。

図７は、検証アプリ実行制御部２２４による検証アプリケーションプログラム２１２の検証実行スケジュール２１９Ａの定義処理を示すフローチャートである。なお図７は、検証実行スケジュール２１９Ａの作成処理や修正処理を示すフローチャートとも呼べる。検証アプリ実行制御部２２４は、まずステップＳ５００において、実行スケジューリング要求を受けてステップＳ５０１に進む。

ステップＳ５００を詳述すると、検証アプリ実行制御部２２４は、車載制御装置２１のミドルウェアやＯＳ、アプリケーションのいずれからこの要求を受けてもよい。この要求を受けるタイミングは起動時、停止中、走行中のいずれでもよい。さらに検証アプリ実行制御部２２４は、検証管理サーバ１０から動的に要求を受けてもよい。例えば、優先度の高い検証アプリケーションプログラム２１２が検証管理サーバ１０で定義された際に、検証管理サーバ１０から各車両２の検証実行スケジュール２１９Ａを変更するように要求されることが考えられる。また、走行環境条件２１６の成立が困難である場合には、検証管理サーバ１０が成立条件を予測した場合にスケジューリングを要求することがありうる。

検証アプリ実行制御部２２４は、ステップＳ５０１において、検証計画情報２１３を読み込む。この検証計画情報２１３は例えば図５に図示したデータフォーマットで構成され、各エントリに検証アプリケーションプログラム名、走行環境条件、検証方法定義、検証優先度などを含む。もし、最新の検証計画情報を検証管理サーバ１０から受け取って一定の時間が経過していた場合には、検証アプリ実行制御部２２４は検証管理サーバ１０に検証計画情報２１３を要求してもよい。検証アプリ実行制御部２２４は、ステップＳ５０２において、走行環境条件予測情報２１７を読み込む。この走行環境条件予測情報２１７は走行環境条件に関して、走行環境条件成立予測部２２７が作成した予測情報である。

検証アプリ実行制御部２２４は、ステップＳ５０３において、走行環境条件予測情報２１７に基づいて検証計画エントリの優先度を更新してステップＳ５０４に進む。この更新の一例を説明する。図６（ａ）に示す例のように、走行環境条件５１２が「交差点領域にいる場合」と定義されており、直近の不成立タイミングが５秒後、と定義されている場合を想定する。この場合に検証アプリ実行制御部２２４は、例えば、走行環境条件予測情報２１７を用いてこのアプリケーションプログラムと走行環境条件５１２の組に対する検証優先度２１５の値を大きくし、直近に優先的に検証が実行されるように調整する。これにより、将来の不成立がわかっている検証アプリケーションプログラム２１２の走行環境条件に対して、優先的に検証を実行する制御が可能となる。

優先度の更新の別の例を、図６（ｂ）を参照して説明する。図６（ｂ）に示す例では、ある走行環境条件が現状成立しており５秒後に非成立し、６秒後にすぐ再度成立する。この場合には、優先度を上げる制御を行う必要がないため、優先度を下げることが考えられる。

検証アプリ実行制御部２２４は、ステップＳ５０４において、検証計画情報２１３の中で優先度の高い検証計画エントリから順に走査し、走行環境条件４０２を満たす検証計画エントリを抽出する。走行環境条件４０２を満足するか否かの具体例を説明する。まず走行環境条件４０２が場所に関する条件である「交差点領域にいること」である場合の例を説明する。この場合にはたとえば、基本アプリケーションプログラム２１１の自己位置推定アプリケーションの出力する自己位置データをもとに判断する。車両２が交差点領域にいる場合であれば走行環境条件４０２を満たしたものとして、ステップＳ５０５に進む。車両２が交差点領域にいない場合には走行環境条件４０２を満たさないので、次に優先度の高い走行環境条件に移る。

ステップＳ５０４の別な具体例を説明する。走行環境条件４０２に例えば、「車種ＸＸであること」等の車両に関する条件が設定されている場合には、例えば、車両情報２１９に基づいて判断する。車両情報２１９に含まれる車種の情報が「車種ＸＸ」に合致する場合には走行環境条件４０２を満たしたものとして、ステップＳ５０５に進む。車両情報２１９に含まれる車種の情報が「車種ＸＸ」に合致しない場合には走行環境条件４０２を満たさないので、次に優先度の高い走行環境条件に移る。

ステップＳ５０４のさらに別な具体例を説明する。走行環境条件４０２に例えば、「天気が曇りであること」等の天候に関する条件が設定されている場合には、例えば、基本アプリケーションプログラム２１１の画像認識アプリケーションが出力する天候情報をもとに判断する。天候情報が曇りの場合には、走行環境条件４０２を満たしたものとして、ステップＳ５０５に進む。天候情報が曇り以外の場合には走行環境条件４０２を満たさないので、次に優先度の高い走行環境条件に移る。もし、走行環境条件が存在しない場合はステップＳ５０７へ進む。

なおステップＳ５０４において優先度が同じ値の検証計画エントリが複数存在する場合には、任意の検証計画エントリから選択してもよいし、検証に要するＣＰＵリソースが大きいものから走査してもよい。このように、検証アプリケーションプログラム２１２の走行環境条件２１６を優先度の高いものから空きＣＰＵリソース条件に基づいて判断することで、ＣＰＵリソースが少ない環境においても、優先度の高いアプリケーションの検証を優先的に完了することができる。

検証アプリ実行制御部２２４は、ステップＳ５０５において、ＣＰＵリソース条件や、予測情報などに基づいて、タスクに対して検証アプリケーションプログラム２１２の実行を割り当てる。この割り当てとは、検証実行スケジュール２１９Ａに書き込みを行うことである。予測情報に基づく割り当てとは、例えば、走行環境条件の成立がＸＸｍｓ後に成立することが予測されている場合は、そのＸＸｍｓの経過後に実行されるように割り当てられるのが望ましい。また逆に、ＹＹｍｓ後に不成立となることが予測されている場合は、そのＹＹｍｓの経過前に割当てられるのが望ましい。さらに、長時間成立しないことが予測されている場合には、当該アプリケーションプログラムは検証のためのタスクに割当てずに、他の検証アプリケーションプログラム２１２に譲るようにしてもよい。検証アプリ実行制御部２２４は、車載制御装置２１上のＣＰＵリソース状態の情報を受け取り、ＣＰＵリソース条件４０３に記載された数値との大小関係を比較することで、ＣＰＵリソース条件４０３を満足するか否かを判断する。

検証アプリ実行制御部２２４は、続くステップＳ５０６において、検証用のＣＰＵリソースの空きが存在するか否かを判断する。検証アプリ実行制御部２２４は、リソースの空きが存在しないと判断する場合はステップＳ５０７に進み、リソースの空きが存在すると判断する場合にはステップＳ５０４に戻り、次に優先度の高い検証アプリケーションプログラムの割り当てを試みる。

検証アプリ実行制御部２２４は、ステップＳ５０７において、検証実行スケジュール２１９Ａを確定して車載記憶部２１０に格納して図７に示す処理を終了する。検証アプリ実行制御部２２４は、この検証実行スケジュール２１９Ａに基づいて検証アプリケーションプログラム２１２を実行する。

図８は、検証管理サーバ１０における検証進捗情報１１５の一例を示す図である。図８では検証進捗情報１１５がテーブルのフォーマットで表され、複数のエントリを有する。このエントリを以下では「進捗情報エントリ」とも呼ぶ。この進捗情報エントリは、検証計画情報１１７の検証計画エントリに対応して存在する。

進捗情報エントリは検証アプリケーションプログラム名７１０と、走行環境条件７１１と、進捗値７１２と、を含む。このエントリに検証経過時間７１３が含まれていてもよい。検証アプリケーションプログラム名７１０と走行環境条件７１１の組は、検証計画エントリに存在するものと対応する。進捗情報エントリの進捗値７１２は、検証の進捗を示す。この値の進捗表現値は検証アプリケーションプログラムに依存し、検証アプリケーションプログラムのカバレッジを示す場合や、検証アプリケーションプログラムを検証動作させる目標時間に対するその時の検証実行時間の割合を示す場合を示す。この検証進捗情報１１５は車載制御装置２１の検証アプリ実行制御部２２４において作られる。

進捗情報エントリの検証経過時間７１３は、当該アプリケーションプログラムと走行環境条件が検証計画情報として初めて車載制御装置２１上でスケジューリングされてから経過した時間を示す。なお、検証管理サーバ１０上での経過時間が検証進捗情報１１５に含まれてもよい。

図９は、検証計画情報生成部１０３による検証計画情報１１７の生成処理を示すフローチャートである。検証計画情報生成部１０３は、まずステップＳ８００において、検証計画情報生成要求を受ける。検証計画情報生成部１０３は、ステップＳ８０１において、検証の検証進捗情報１１５と走行環境条件予測情報１１６を受け取る。検証進捗情報１１５は検証結果取得部１０２から受け取り、走行環境条件予測情報１１６は走行環境条件成立予測部１０４から受け取る。

検証計画情報生成部１０３は、ステップＳ８０２において、検証計画情報２１３を生成する。検証計画情報生成部１０３は、それぞれの検証計画エントリに対して、検証進捗情報１１５に基づいて検証経過時間に対して進捗値が小さいものの優先度を上げてもよい。また、検証経過時間に対して進捗値が大きいものの優先度を下げてもよい。また、検証管理サーバ１０における走行環境条件予測情報１１６に基づき、直近で不成立であるが将来的に成立見込みのある検証計画エントリを優先度下げてもよいし、逆に直近は成立するが、将来的に不成立見込みのある検証計画エントリの優先度を上げてもよい。

上述した第１の実施の形態によれば、次の作用効果が得られる。
（１）車載制御装置２１は、車両２に搭載され、車両２の走行制御に関する基本アプリケーションプログラム２１１、複数の検証アプリケーションプログラム２１２、検証アプリケーションプログラム２１２を検証する車両２に関する条件である走行環境条件２１６、および走行環境条件２１６の検証優先度２１５、を格納する車載記憶部２１０と、走行環境条件２１６および検証優先度２１５に基づき、検証アプリケーションプログラム２１２の検証の実行を制御する検証アプリ実行制御部２２４と、を備える。そのため車載制御装置２１は、検証する条件と優先度を考慮して、複数の検証アプリケーションプログラム２１２の検証を効率よく実行できる。

（２）車載制御装置２１は、車載記憶部２１０に、走行環境条件２１６における検証方法を定義した検証方法定義２１４が格納される。検証アプリ実行制御部２２４は、さらに検証方法定義２１４に基づき検証アプリケーションプログラム２１２の検証の実行を制御する。そのため車載制御装置２１は、検証アプリケーションプログラム２１２の検証の成否を容易に判断できる。たとえば検証アプリケーションプログラム２１２が、既存の基本アプリケーションプログラム２１１と同一の機能を有し、アルゴリズムを改善して実行速度を向上させた場合には、既存の基本アプリケーションプログラム２１１と出力値が一致するか否かを検証する。

（３）検証アプリ実行制御部２２４は、検証アプリケーションプログラム２１２の検証に必要なデータを基本アプリケーションプログラム２１１から取得する。そのため検証アプリ実行制御部２２４は、データ処理の一部を省略でき、効率よく検証を実行できる。

（４）車載制御装置２１は、車両２の走行環境が、検証計画情報２１３に含まれる走行環境条件２１６に合致するタイミングを予測する走行環境条件成立予測部２２７を備える。検証アプリ実行制御部２２４は、走行環境条件成立予測部２２７が予測した走行環境条件予測情報２１７に基づき、検証アプリケーションプログラム２１２の検証の実行を制御する。検証アプリ実行制御部２２４は、走行環境条件成立予測部２２７の予測に基づき検証実行スケジュール２１９Ａを作成し、検証実行スケジュール２１９Ａに従って検証を行うので、たとえば車両２の進行予定にあわせて複数の検証アプリケーションプログラム２１２を効率よく検証できる。

（５）検証管理サーバ１０は、車両２と通信可能である。検証管理サーバ１０は、車両２において検証されるアプリケーションである検証アプリケーションプログラム１１１、および検証アプリケーションプログラム１１１を検証すべき条件である走行環境条件１１４を格納するサーバ記憶部１１０と、車両２から取得した車両情報２１９および走行環境条件１１４に基づき検証アプリケーションプログラム２１２の検証優先度１１３を決定し、走行環境条件１１４と、検証アプリケーションプログラム２１２と、検証優先度１１３と、を含む検証計画情報１１７を生成する検証計画情報生成部１０３と、検証計画情報１１７を車両２に出力する検証計画情報出力部１０１と、を備える。そのため検証管理サーバ１０は、車両２から取得した車両情報２１９および走行環境条件１１４に基づき検証アプリケーションプログラム２１２の検証優先度１１３を決定するので、複数の検証アプリケーションプログラム２１２の検証を効率よく実行させることができる。

（６）車両情報２１９は、車両２において実行された検証アプリケーションプログラム２１２の検証結果を含む。検証計画情報生成部１０３は、検証アプリケーションプログラム２１２の検証結果に基づき検証アプリケーションプログラム２１２の検証進捗情報１１５を更新し、検証進捗情報１１５に基づいて検証アプリケーションプログラム１１１の検証優先度１１３を決定する。そのため検証管理サーバ１０は、進捗にあわせて検証優先度１１３を操作することで、一部の検証アプリケーションプログラム２１２だけが著しく遅れる事態を回避できる。さらに、検証管理サーバ１０に複数の車載制御装置２１が接続されている場合には、複数の車載制御装置２１における検証の進捗をもとに検証優先度１１３を操作するので、１台の車載制御装置２１だけでは不可能な、検証システム１の全体としての最適化ができる。

（７）検証管理サーバ１０は、車両情報２１９に基づき、車両２の走行環境が検証計画情報１１７に含まれる走行環境条件に合致するタイミングを予測する走行環境条件成立予測部１０４を備える。検証計画情報生成部１０３は、予測したタイミングに基づき、検証アプリケーションプログラム１１１の検証優先度１１３を決定する。そのため検証管理サーバ１０は、それぞれの車載制御装置２１に最適な検証アプリケーションプログラム２１２の検証を担当させ、検証システム１の全体としての最適化ができる。

（８）検証システム１は、車両２に搭載される車載制御装置２１および車載制御装置２１と通信可能な検証管理サーバ１０を含む。検証管理サーバ１０は、車両２において検証されるアプリケーションである検証アプリケーションプログラム１１１、および検証アプリケーションプログラム２１２を検証すべき条件である走行環境条件１１４を格納するサーバ記憶部１１０と、車両２から取得した車両情報２１９および走行環境条件１１４に基づき検証アプリケーションプログラム２１２の検証優先度１１３を決定し、走行環境条件１１４と、検証アプリケーションプログラム１１１と、検証優先度１１３と、を含む検証計画情報１１７を生成する検証計画情報生成部１０３と、検証計画情報１１７を車両２に出力する検証計画情報出力部１０１と、を備える。車載制御装置２１は、検証管理サーバ１０が出力した検証計画情報１１７を取得する検証計画情報取得部２２５と、車両２の走行制御に関する基本アプリケーションプログラム２１１と並行して、検証アプリケーションプログラム２１２の検証の実行を走行環境条件２１６と検証優先度２１５に基づき制御する検証アプリ実行制御部２２４と、を備える。そのため検証システム１は、複数の検証アプリケーションプログラム２１２の検証を効率よく実行できる。

（変形例１）
車載制御装置２１における優先度の更新量と、検証管理サーバ１０における優先度の更新量の配分はシステム全体で事前に調整してもよい。例えば、車載制御装置２１における優先度の更新を全く行わず、検証管理サーバ１０でのみ優先度の更新するようにしてもよい。もしくは、例えば、検証管理サーバ１０で優先度を更新し、さらに車両２での予測の結果に基づいて、細かく調整可能としてもよい。なお車載制御装置２１における優先度の更新を行わない場合には、図７のステップＳ５０３の処理を行わない。

（変形例２）
図７に示した検証実行スケジュール２１９Ａの定義処理は次の（Ａ）〜（Ｃ）のように変更してもよい。

（Ａ）図７では、ステップＳ５０４において、優先度の高い検証計画エントリから走査し、実行スケジュールを割り当てた。しかし別の方法として、優先度ではなく検証に必要とするＣＰＵリソースが大きいものから走査してもよい。
（Ｂ）図７では、ステップＳ５０４において、優先度の高い検証計画エントリから走査した。しかしこの段階でＣＰＵリソース条件４０３を確認し、ＣＰＵリソースを満たさないエントリについては無視してもよい。
（Ｃ）図７では検証計画情報２１３は読み込むのみであった。しかし、検証実行スケジュール２１９Ａの定義が繰り返された際に、割り当てられない検証アプリケーションプログラム２１２に対して、優先度を大きくする処理を追加してもよい。それにより、一向に実行がスケジュールされない検証アプリケーションプログラム２１２の実行を保証することができる。

（変形例３）
検証計画情報２１３には、検証方法定義２１４が含まれなくてもよい。この場合には車載制御装置２１は、検証アプリケーションプログラム２１２の実行結果、たとえばプログラムが出力する情報を検証管理サーバ１０に送信することで、検証の代替とすることができる。

（変形例４）
車載制御装置２１は、走行環境条件成立予測部２２７を備えなくてもよい。この場合には車載制御装置２１は、検証する検証アプリケーションプログラム２１２の順番を予め既定の手法またはランダムに決定してもよい。または車載制御装置２１は、所定の時間間隔ごとに走行環境条件２１６の成立を判断し、そのときに成立している走行環境条件２１６を有する検証アプリケーションプログラム２１２を実行してもよい。

（変形例５）
検証管理サーバ１０の検証計画情報生成部１０３は、検証結果２１８に基づく検証優先度１１３の更新を行わなくてもよい。

（変形例６）
検証管理サーバ１０は、走行環境条件成立予測部１０４を備えなくてもよい。この場合には検証管理サーバ１０は、たとえばそれぞれの車載制御装置２１にランダムに検証アプリケーションプログラム２１２の検証を割り当てる。

上述した各実施の形態および変形例において、機能ブロックの構成は一例に過ぎない。別々の機能ブロックとして示したいくつかの機能構成を一体に構成してもよいし、１つの機能ブロック図で表した構成を２以上の機能に分割してもよい。また各機能ブロックが有する機能の一部を他の機能ブロックが備える構成としてもよい。

車載制御装置２１が不図示の入出力インタフェースを備え、必要なときに入出力インタフェースと車載制御装置２１が利用可能な媒体を介して、他の装置からプログラムが読み込まれてもよい。ここで媒体とは、たとえば入出力インタフェースに着脱可能な記憶媒体、または通信媒体、すなわち有線、無線、光などのネットワーク、または当該ネットワークを伝搬する搬送波やディジタル信号、を指す。また、プログラムにより実現される機能の一部または全部がハードウエア回路やＦＰＧＡにより実現されてもよい。上述した複数の変形例は、それぞれ組み合わせてもよい。上記では、種々の実施の形態および変形例を説明したが、本発明はこれらの内容に限定されるものではない。本発明の技術的思想の範囲内で考えられるその他の態様も本発明の範囲内に含まれる。

上述した各実施の形態および変形例は、それぞれ組み合わせてもよい。上記では、種々の実施の形態および変形例を説明したが、本発明はこれらの内容に限定されるものではない。本発明の技術的思想の範囲内で考えられるその他の態様も本発明の範囲内に含まれる。

１０…検証管理サーバ
２１…車載制御装置
１０１…検証計画情報出力部
１０２…検証結果取得部
１０３…検証計画情報生成部
１０４…走行環境条件成立予測部
１１０…サーバ記憶部
１１１、２１２…検証アプリケーションプログラム
１１２、２１４…検証方法定義
１１３、２１５…検証優先度
１１４、２１６…走行環境条件
１１５…検証進捗情報
１１６…走行環境条件予測情報
１１７、２１３…検証計画情報
２１０…車載記憶部
２１１…基本アプリケーションプログラム
２１７…走行環境条件予測情報
２１８…検証結果
２１９…車両情報
２１９Ａ…検証実行スケジュール
２２０…処理部
２２１…センサ入力部
２２２…アクチュエータ出力部
２２３…基本アプリ実行制御部
２２４…検証アプリ実行制御部
２２５…検証計画情報取得部
２２６…検証結果出力部
２２７…走行環境条件成立予測部

Claims (8)

1. 車両に搭載される車載制御装置であって、
   前記車両の走行制御に関する基本アプリケーションプログラム、前記基本アプリケーションプログラムとは異なる複数の検証アプリケーションプログラム、前記検証アプリケーションプログラムを検証する前記車両に関する条件である走行環境条件、および前記走行環境条件の検証優先度、を格納する車載記憶部と、
   前記基本アプリケーションプログラムおよび前記検証アプリケーションプログラムを実行可能なＣＰＵと、
   前記走行環境条件および前記検証優先度に基づき、前記検証アプリケーションプログラムの検証の実行を制御する検証実行制御部と、を備える車載制御装置。
2. 請求項１に記載の車載制御装置であって、
   前記車載記憶部に、さらに前記走行環境条件における検証方法を定義した検証方法定義が格納され、
   前記検証実行制御部は、さらに前記検証方法定義に基づき前記検証アプリケーションプログラムの検証の実行を制御する車載制御装置。
3. 請求項１に記載の車載制御装置であって、
   前記検証実行制御部は、前記検証アプリケーションプログラムの検証に必要なデータを前記基本アプリケーションプログラムから取得する車載制御装置。
4. 請求項１に記載の車載制御装置であって、
   前記車両の走行環境が、前記走行環境条件に合致するタイミングを予測する走行環境条件成立予測部をさらに備え、
   前記検証実行制御部は、さらに前記走行環境条件成立予測部が予測した予測情報に基づき、前記検証アプリケーションプログラムの検証の実行を制御する車載制御装置。
5. 車両と通信可能なサーバであって、
   前記車両において検証されるアプリケーションプログラムである検証アプリケーションプログラム、および前記検証アプリケーションプログラムを検証すべき条件である走行環境条件を格納するサーバ記憶部と、
   前記車両から取得した車両情報および前記走行環境条件に基づき前記検証アプリケーションプログラムの検証優先度を決定し、前記走行環境条件と、前記検証アプリケーションプログラムと、前記検証優先度と、を含む検証計画情報を生成する検証計画情報生成部と、
   前記検証計画情報を前記車両に出力する検証計画情報出力部と、を備えるサーバ。
6. 請求項５に記載のサーバであって、
   前記車両情報は、前記車両において実行された前記検証アプリケーションプログラムの検証結果を含み、
   前記検証計画情報生成部は、前記検証アプリケーションプログラムの検証結果に基づき前記検証アプリケーションプログラムに関する検証の進捗を示す検証進捗情報を更新し、前記検証進捗情報に基づいて前記検証アプリケーションプログラムの前記検証優先度を決定するサーバ。
7. 請求項５または請求項６に記載のサーバであって、
   前記サーバは、
   前記車両情報に基づき、前記車両の走行環境が前記検証計画情報に含まれる走行環境条件に合致するタイミングを予測する走行環境条件成立予測部をさらに備え、
   前記検証計画情報生成部は、前記予測したタイミングに基づき、前記検証アプリケーションプログラムの前記検証優先度を決定するサーバ。
8. 車両に搭載される車載制御装置および前記車載制御装置と通信可能なサーバを含む、検証システムであって、
   前記サーバは、
   前記車両において検証されるアプリケーションプログラムである検証アプリケーションプログラム、および前記検証アプリケーションプログラムを検証すべき条件である走行環境条件を格納するサーバ記憶部と、
   前記車両から取得した車両情報および前記走行環境条件に基づき前記検証アプリケーションプログラムの検証優先度を決定し、前記走行環境条件と、前記検証アプリケーションプログラムと、前記検証優先度と、を含む検証計画情報を生成する検証計画情報生成部と、
   前記検証計画情報を前記車両に出力する検証計画情報出力部と、を備え、
   前記車載制御装置は、
   前記サーバが出力した前記検証計画情報を取得する検証計画情報取得部と、
   前記車両の走行制御に関する基本アプリケーションプログラムと並行して、前記検証アプリケーションプログラムの検証の実行を前記走行環境条件と前記検証優先度に基づき制御する検証実行制御部と、を備える検証システム。
   

Images