WO2023037576A1 - 車両制御システム及び車両制御方法 - Google Patents

Abstract

車両制御システムは、車両が第一の状態である場合に第一の制御ソフトウェアの演算を実行し、車両が第二の状態である場合に第二の制御ソフトウェアの演算を実行する演算部と、センサから第一及び第二の制御ソフトウェアにそれぞれ入力される入力データ、並びに第一及び第二の制御ソフトウェアの出力データと、を保存する比較基準データ保存部と、比較基準データ保存部から読み出した出力データの差分に基づいて、第二の制御ソフトウェアの性能を評価する評価部と、を備える。

Description

車両制御システム及び車両制御方法

　本発明は、車両制御システム及び車両制御方法に関する。

　車載電子制御装置(ＥＣＵ：Electronic Control Unit)に搭載されたプログラムの性能や安全性を検証するには、車両走行中に検証対象のプログラムを動作させて出力値を確認するシャドウテスティング又はシャドウモードテスティングと呼ばれる検証技術が有効である。シャドウテスティング又はシャドウモードテスティングによる検証では、例えば検証済みのプログラムを通常動作させておき、同時に、バックグラウンドにて検証対象のプログラムを動作させておく、そして、検証済みのプログラムの出力値と、検証対象のプログラムの出力値とを比較することで、検証対象のプログラムの性能や安全性を確認することができる。

　この時、検証対象のプログラムの出力値をアクセルやブレーキといったアクチュエータ動作には使用しない。このため、検証対象のプログラムに不具合が生じたとしても走行中の車両動作に影響を与えない。この結果、ドライバーの安全性を保ちつつ、検証対象のプログラムの性能及び安全性評価が可能となる。また、近年では、多様な入力データを処理するため、ＡＩ（Artificial Intelligence）を用いた技術がＥＣＵに提供されるようになっている。ＡＩでは、入力データと出力データとの対応が一意に決定されないような処理を行うことが可能である。そこで、開発者は、車両の走行中に行われたＡＩの処理によりどのような出力データが生成されたかを検証する必要がある。

　そこで、ＡＩ等を含むプログラムを検証するための特許文献１～３に記載された技術が知られている。
　特許文献１には、「現実の台上試験機又は現実のローラーテストスタンドでの／上での現実のテストからの出力変数と仮想の台上試験機又は仮想のローラーテストスタンドでの仮想のテストからの出力変数との間の偏差に基づいて、検査条件に反応する識別関数が存在するか否かが推定され得る。そして、当該自動車の制御及び／又は調整が、当該識別関数の存在の可否に応じて改竄されるか否かが推定され得る。」と記載されている。

　また、特許文献２には、「検査用装置は、車載装置の不具合（検査項目）を選択するだけで、その不具合を検証するための検査プログラムを含む検査用のシナリオを自動的に作成する。また、検査用装置は、作成した検査用のシナリオを記憶媒体に書き込むことができる。」と記載されている。

　また、特許文献３には、「プログラム実行制御部により駆動されるプログラムが環境情報に応じて順次呼び出す動作と行動検証シナリオで定義される動作の順序とを比較することにより、シミュレータや適応制御装置の実機を用いることなく、単体でプログラムの評価又は検証を行なうことができる。」と記載されている。

特開２０１８－１９０３４９号公報 特開２０１５－１９０９５６号公報 国際公開第２０１８／１８０１４３号

　特許文献１に記載された技術は、主に自動車の稼働をシミュレートするときに、自動車の制御装置のソフトウェアを検査するために用いられるが、走行する自動車の挙動をシミュレートする処理には、車載のＥＣＵと比べて高性能なコンピュータ装置が用いられる。
このため、車載のＥＣＵでは、特許文献１に記載されたソフトウェアを稼働することができない。

　また、特許文献２に記載された技術は、車載装置により検査プログラムが実行される。
車載装置の検査が終了すると、検査の結果が書き込まれた記憶媒体が車載装置から取り外され、検査用装置に接続されることで、車載装置の不具合に対応する対処方法を選択することができる。このため、実走行中の自動車に本技術を適用したとしても、車載装置の不具合への対処が遅れてしまう。

　また、特許文献３に記載された複数のアプリケーション・プログラムは、１又はそれ以上の定義動作と、１又はそれ以上の行動計画と、１又はそれ以上の行動検証シナリオを含んでおり、同一の自動走行車上で混在することが可能である。しかし、自動車等の組込み制御システム製品に搭載されているマルチコアプロセッサの計算処理能力は限られている。車載の計算資源には制約があるため、自動運転向けプログラムのような高負荷プログラムを、各プロセッサコアで同時に動作させることは困難であり、実行可能なプログラムは限定的となっていた。

　本発明はこのような状況に鑑みて成されたものであり、複数の制御ソフトウェアの出力値を比較するシャドウモードテスティングを可能とすることを目的とする。

　本発明に係る車両制御システムは、車両が第一の状態である場合に第一の制御ソフトウェアの演算を実行し、車両が第二の状態である場合に第二の制御ソフトウェアの演算を実行する演算部と、センサから第一の制御ソフトウェア及び第二の制御ソフトウェアにそれぞれ入力される入力データ、並びに第一の制御ソフトウェア及び第二の制御ソフトウェアが入力データを入力として実行した演算により出力する出力データと、を保存する保存部と、保存部から読み出した、第一の制御ソフトウェア及び第二の制御ソフトウェアがそれぞれ出力した出力データを比較して、第二の制御ソフトウェアの性能を評価する評価部と、を備える。

　本発明によれば、車両が第一の状態で第一の制御ソフトウェアの演算を実行して得られた出力データと、第二の状態で第二の制御ソフトウェアの演算を実行して得られた出力データとを比較して、第二の制御ソフトウェアの性能を評価するシャドウモードテスティングが可能となる。
　上記した以外の課題、構成及び効果は、以下の実施の形態の説明により明らかにされる。

本発明の第１の実施の形態に係る車両制御システムの全体構成例を示すブロック図である。 本発明の第１の実施の形態に係る車両制御システムの状態遷移の例を示した図である。 本発明の第１の実施の形態に係る車両制御システムの状態Ａにおけるデータフローの例を示した図である。 本発明の第１の実施の形態に係る比較基準データ選定部の処理手順例を示したフローチャートである。 本発明の第１の実施の形態に係る車両制御システムの状態遷移判定時におけるデータフローの例を示した図である。 本発明の第１の実施の形態に係る状態判定部の処理手順例を示したフローチャートである。 本発明の第１の実施の形態に係る車両制御システムの状態Ｂにおけるデータフローの例を示した図である。 本発明の第１の実施の形態に係る性能・品質評価部の処理手順例を示したフローチャートである。 本発明の第１の実施の形態に係る重要シナリオ特定部の処理手順例を示したフローチャートである。 本発明の第２の実施の形態に係る車両制御システムの全体構成例を示した図である。 本発明の第２の実施の形態に係る車両制御システムとクラウドサーバ間で送受信される通信データの例を示した図である。 本発明の第３の実施の形態に係る車両制御システムの全体構成例を示した図である。 本発明の第３の実施の形態に係る車両制御システムの状態遷移の例を示した図である。 本発明の第３の実施の形態に係る車両制御システムの状態Ｃにおけるデータフローの例を示した図である。 本発明の各実施の形態に係る計算機のハードウェア構成例を示した図である。

　以下、本発明を実施するための形態について、添付図面を参照して説明する。本明細書及び図面において、実質的に同一の機能又は構成を有する構成要素については、同一の符号を付することにより重複する説明を省略する。

　本発明に係る車両制御システムは、センサとアクチュエータが接続された形態とする。
そして、車両制御システムにはセンサから入力値としてセンサデータが入力され、車両制御システムの出力値がアクチュエータへと出力される構成とする。ただし、本発明は、入力元及び出力先の構成によらず、制御ソフトウェアが搭載された車両制御システムに広く適用可能である点に注意されたい。

［第１の実施の形態］
　図１は、第１の実施の形態に係る車両制御システム１の全体構成例を示すブロック図である。この車両制御システム１は、自動運転可能な車両に搭載されるシステムであり、複数の電子制御装置（ＥＣＵ）がネットワークにて接続されている。

　車両制御システム１は、センサ２及びアクチュエータ３とバス（ＢＵＳ）で接続されている。車両制御システム１は、センサ２（例えば、撮像センサ）から車両制御システム１の入力となるセンサデータ（例えば、画像データ）を受け取り、アクチュエータ３には車両制御システム１の出力データ（例えば、制御データ）を送る役割を持つ。

　車両制御システム１は、制御ソフトウェア１０、演算部１１、比較基準データ選定部１２、比較基準データ保存部１３、状態判定部１４、処理プログラム変更部１５、評価ソフトウェア実行指示部１６、性能・品質評価部１７、及び重要シナリオ特定部１８を有する。

　制御ソフトウェア１０は、第一の制御ソフトウェア１０１、第二の制御ソフトウェア１０２を有する。第一の制御ソフトウェア１０１は、検証済みのソフトウェアであり、車両の動作時に実行される。第一の制御ソフトウェア１０１と第二の制御ソフトウェア１０２は、いずれも処理の負荷が高いため、演算部１１では同時に実行することができない。このため、第二の制御ソフトウェア１０２は、検証対象のソフトウェアであり、車両制御システム１の空き時間に実行される。

　演算部（演算部１１）は、車両が第一の状態である場合に第一の制御ソフトウェア（第一の制御ソフトウェア１０１）の演算を実行し、車両が第二の状態である場合に第二の制御ソフトウェア（第二の制御ソフトウェア１０２）の演算を実行する。以下の説明では、車両が第一の状態であることを車両制御システム１が状態Ａであるとも呼び、車両が第二の状態であることを車両制御システム１が状態Ｂであるとも呼ぶ。第一の制御ソフトウェア１０１及び第二の制御ソフトウェア１０２はいずれも処理負荷が高いので演算部１１が同時に実行できないが、車両の状態に合わせて演算部１１が実行する制御ソフトウェアを変更することで、車両の自動運転に支障なく、第二の制御ソフトウェア１０２の動作検証が可能となる。そこで、車両制御システム１は、処理プログラム変更部１５の処理プログラムの変更指示に従い、第一の制御ソフトウェア１０１又は第二の制御ソフトウェア１０２のどちらかを演算部１１にて演算処理させる。図１では、演算部１１が第二の制御ソフトウェア１０２を実行している様子が示される。なお、本明細書では、第一の制御ソフトウェア１０１又は第二の制御ソフトウェア１０２をプログラムと同様の意味で用いる。

　ここで、車両制御システム１の状態遷移の例について説明する。
　図２は、第１の実施形態に係る車両制御システム１の状態遷移の例を示した図である。
図２の左上にある黒丸の初期ノードは、ドライバーにより車両の電源が投入され、車両制御システム１による処理が開始したことを表す。

　車両制御システム１は、状態Ａと状態Ｂの２つの状態を持つ。
　始めに、車両制御システム１が状態Ａの時の内部処理の例を説明する。状態Ａは、車両が自動運転を行っている状態である。そして、状態Ａにおける車両制御システム１の動作の概要は、図２の上部に示される。

　状態Ａにて車両制御システム１は、センサ２より車両制御システム１への入力となるセンサデータ２０を受け取る。そして、演算部１１は、第一の制御ソフトウェア１０１を実行し、第一の制御ソフトウェア出力データ１０１０をアクチュエータ３へと出力する。例えば、第一の制御ソフトウェア１０１は、センサデータ２０として画像データを受け取ると、画像内に映り込む物体を認識する処理を行い、車両の動作に必要な制御信号を生成する。

　また、第一の制御ソフトウェア１０１は、例えば、センサフュージョンの機能を用いて、各センサ２から得たセンサデータ２０を用いて車両が走っている道路の車線、周囲の他の車両の位置等を認識して、車両の加速又はブレーキをアクチュエータ３に指示するための制御信号を生成してもよい。また、第一の制御ソフトウェア１０１は、画像認識の結果に基づいて、車両が走行する車線を決定し、ステアリングを操作するための操作信号を生成してもよい。これらの信号が第一の制御ソフトウェア出力データ１０１０としてアクチュエータ３に出力される。

　保存部（比較基準データ保存部１３）は、センサ（センサ２）から第一の制御ソフトウェア（第一の制御ソフトウェア１０１）及び第二の制御ソフトウェア（第二の制御ソフトウェア１０２）にそれぞれ入力される入力データ、並びに第一の制御ソフトウェア（第一の制御ソフトウェア１０１）及び第二の制御ソフトウェア（第二の制御ソフトウェア１０２）が入力データを入力として実行した演算により出力する出力データと、を保存する。
例えば、比較基準データ保存部１３は、センサデータ２０と第一の制御ソフトウェア出力データ１０１０を保存する。このため、比較基準データ保存部１３には、第一の制御ソフトウェア１０１が使用した入力データ、及び出力データがセットで保存される。比較基準データ保存部１３に各データが保存されることで、第一の制御ソフトウェア１０１の処理後に、第二の制御ソフトウェア１０２が第一の制御ソフトウェア１０１と同様の処理を実行したり、開発者がデータを取り出してデータを検証したりすることができる。

　次に、車両制御システム１が状態Ｂの時の内部処理の例を説明する。例えば、車両制御システム１が空き時間になった時、状態Ａから状態Ｂに遷移する。空き時間の判定は、例えば、車両制御システム１がブレーキの踏み込みを検出したタイミングで行われ、車両が停止した時に状態Ａから状態Ｂに遷移する。他にも高速道路を走行中の車両が自動運転で動作する場合、車両制御システム１は状態Ａで稼働し、一般道路を走行する車両にドライバーの運転操作が必要になると車両制御システム１が状態Ｂに遷移して稼働することが想定される。また、車両が駐車場で停止し、車載バッテリが充電されている時には、車両制御システム１が状態Ｂで稼働してもよい。車両制御システム１が状態Ａから遷移した状態Ｂにおける車両制御システム１の動作の概要は、図２の下部に示される。

　状態Ｂにおいて、演算部１１、比較基準データ保存部１３は、状態Ａと共通して用いられる。ただし、状態Ｂでは、性能・品質評価部１７が稼働する。

　演算部１１は、比較基準データ保存部１３に保存されたセンサデータ２０を受け取り、第二の制御ソフトウェア１０２を実行する。そして、演算部１１は、第二の制御ソフトウェア出力データ１０２０を性能・品質評価部１７に出力する。なお、状態Ｂでは、第二の制御ソフトウェア出力データ１０２０がアクチュエータ３には出力されないので、第二の制御ソフトウェア出力データ１０２０によりアクチュエータ３が動作することはない。例えば、自動運転から手動運転に切り換わった時、車両制御システム１が状態Ｂに遷移する。手動運転中は車両制御システム１が空き時間となるのであれば、運転者がブレーキを踏み込んだ時のブレーキの踏み込み量のデータがアクチュエータ３に伝わり、ブレーキがかかる。

　評価部（性能・品質評価部１７）は、保存部（比較基準データ保存部１３）から読み出した、第一の制御ソフトウェア（第一の制御ソフトウェア１０１）及び第二の制御ソフトウェア（第二の制御ソフトウェア１０２）がそれぞれ出力した出力データを比較して、第二の制御ソフトウェア（第二の制御ソフトウェア１０２）の性能を評価する。例えば、性能・品質評価部１７は、比較基準データ保存部１３に保存された第一の制御ソフトウェア出力データ１０１０と、第二の制御ソフトウェア出力データ１０２０との差分を比較評価することで、シャドウモードテスティングを実現する。性能・品質評価部１７が比較評価するデータを出力する第一の制御ソフトウェア１０１と第二の制御ソフトウェア１０２は、それぞれ状態Ａと状態Ｂの異なる状態にて実行処理されている。このため、複数の制御ソフトウェアを車両制御システム１にて並列に動作させる必要が無い。この結果、複数の制御ソフトウェアの同時処理を可能とする高性能なＥＣＵを車両制御システム１は必要としない。

　次に、車両制御システム１で行われる処理の例について、図３～図９を参照して説明する。
　図３は、第１の実施形態に係る車両制御システム１の状態Ａにおけるデータフローの例を示した図である。

　上述したように車両制御システム１には、センサ２からセンサデータ２０が入力する。
　演算部１１は、センサ２の出力であるセンサデータ２０を入力データとし、第一の制御ソフトウェア１０１を実行し、第一の制御ソフトウェア出力データ１０１０を出力する。

　選定部（比較基準データ選定部１２）は、評価部（性能・品質評価部１７）が第二の制御ソフトウェア（第二の制御ソフトウェア１０２）を評価するための入力データ及び出力データを、第一の制御ソフトウェア（第一の制御ソフトウェア１０１）への入力とされた入力データ、及び第一の制御ソフトウェア（第一の制御ソフトウェア１０１）が出力した出力データから選定し、選定した入力データ及び出力データを保存部（比較基準データ保存部１３）に保存する。そこで、選定部（比較基準データ選定部１２）は、評価部（性能・品質評価部１７）による第二の制御ソフトウェア（第二の制御ソフトウェア１０２）の評価のための重要シナリオとして保存部（比較基準データ保存部１３）に保存すべきデータを、第一の制御ソフトウェア（第一の制御ソフトウェア１０１）が出力する出力データに基づいて選定する。

　例えば、比較基準データ選定部１２は、センサデータ２０と第一の制御ソフトウェア出力データ１０１０を受け取り、検証対象となる第二の制御ソフトウェア１０２の検証用データとして必要なデータを選定する。そして、比較基準データ選定部１２は、選定後のセンサデータ２１と、選定後の第一の制御ソフトウェア出力データ１０１１とを比較基準データ保存部１３に出力する。検証用データに必要なデータとして、例えば、第一の制御ソフトウェア１０１に入力されるデータがある。ただし、センサ２から出力されるデータを全てセンサデータ２０として保存するには膨大な記録容量が必要である。そこで、例えば、第一の制御ソフトウェア１０１に入力した時、第一の制御ソフトウェア１０１が誤判定すると分かっているデータが選定される。このデータは、例えば、バンボディの背面扉に人の絵が描かれたトラックをセンサ２が撮影した画像が挙げられる。このような画像が入力データとして入力された第一の制御ソフトウェア１０１が、人の絵を誤って実際の人であると誤判定するのであれば、第二の制御ソフトウェア１０２ではどのように判定されるのかが検証される。

　他にも第一の制御ソフトウェア１０１は、雨が降っていたり、逆光だったりする環境でセンサ２が撮影した画像を処理しても、画像に映る人、車両等を正しく検出できないことがある。この場合も、第一の制御ソフトウェア１０１が正しく検出できなかった画像を第二の制御ソフトウェア１０２はどのように検出するかが検証される。
　このようにセンサデータ２０としては、センサデータ２０から選定された一部のセンサデータ２１だけを制御ソフトウェア１０が有するソフトウェア群の動作検証に用いることで、センサデータ２０を保存するための記録媒体の記録容量を削減することが可能となる。

　比較基準データ保存部１３は、選定後のセンサデータ２１と選定後の第一の制御ソフトウェア出力データ１０１１を内部に保存する。ここで、図２に示した比較基準データ保存部１３が保存するセンサデータ２０と第一の制御ソフトウェア出力データ１０１０から選定されたデータが、図３で説明した選定後のセンサデータ２１と選定後の第一の制御ソフトウェア出力データ１０１１となる。

　次に、比較基準データ選定部１２の処理の詳細について説明する。
　図４は、第１の実施形態に係る比較基準データ選定部１２の処理手順例を示したフローチャートである。図４以降の各フローチャートは、車両制御システム１の車両制御方法の一例を表す。

　始めに、比較基準データ選定部１２は、第一の制御ソフトウェア１０１の入力となったセンサデータ２０と、第一の制御ソフトウェア出力データ１０１０とを受け取る（Ｓ１）。

　次に、比較基準データ選定部１２は、ステップＳ１にて受け取ったセンサデータ２０と、第一の制御ソフトウェア出力データ１０１０とを、シャドウモードテスティングにて利用すべきか否かを判断する（Ｓ２）。そして、比較基準データ選定部１２がシャドウモードテスティングにて、これらのデータを利用すべきと判断した場合（Ｓ２のＹＥＳ）、センサデータ２０と、第一の制御ソフトウェア出力データ１０１０とが保存すべきデータであるので、ステップＳ３へと進む。ここで保存されるデータは、例えば、悪天候の時に撮影された画像データ、第一の制御ソフトウェア１０１で誤検知された画像データ等がある。

　ステップＳ３では、比較基準データ選定部１２が比較基準データ保存部１３に対して、ステップＳ１にて受け取ったセンサデータ２０と、第一の制御ソフトウェア出力データ１０１０と、を保存するよう指示し（Ｓ３）、本処理を終了する。このため、センサデータ２０と、第一の制御ソフトウェア出力データ１０１０とが、比較基準データ保存部１３に保存される。

　一方、ステップＳ２にて比較基準データ選定部１２がシャドウモードテスティングにて利用すべきデータでないと判断した場合（Ｓ２のＮＯ）、特に処理は行わず本処理を終了する。この場合、ステップＳ１にて受け取ったセンサデータ２０と、第一の制御ソフトウェア出力データ１０１０とは、保存されない。

　次に、車両制御システム１の状態遷移の判定時におけるデータの流れを説明する。
　図５は、第１の実施形態に係る車両制御システム１の状態遷移判定時におけるデータフローの例を示した図である。

　状態判定部（状態判定部１４）は、演算部（演算部１１）が動作する計算資源の空きに基づいて、車両が第一の状態又は第二の状態のいずれであるかを判定する。ここで、状態判定部（状態判定部１４）は、演算部（演算部１１）が動作する計算資源の空きの有無を、自動運転サービスの提供範囲、車両が充電モード中であること、車両が停車中であること、又は、車両に搭載された計算機の負荷情報、のうち、少なくともいずれか一つに基づいて判断し、かつ評価部（性能・品質評価部１７）が第二の制御ソフトウェア（第二の制御ソフトウェア１０２）の評価を実行可能であるかを判定する。自動運転サービスの提供範囲とは、車両が自動運転で走行するシーンであり、例えば、車両が高速道路を走行中に該当する。また、車両が充電モード中であるとは、例えば、停車した車両に充電器が接続され、不図示の車載バッテリが充電されている状態である。また、車両が停車中であるとは、例えば、信号待ちであったり、路肩に一時停止していたりすることである。また、計算機の負荷情報とは、例えば、後述する図１５に示す計算機６０の負荷を計測した情報である。このように車両の状態が判定されるので、車両の自動運転に支障が生じない状態で第二の制御ソフトウェア１０２が実行される。

　そして、変更部（処理プログラム変更部１５）は、状態判定部（状態判定部１４）により計算資源の空きがないと判定された場合に演算部（演算部１１）が演算を実行する制御ソフトウェアを第一の制御ソフトウェア（第一の制御ソフトウェア１０１）とし、計算資源の空きがあると判定された場合に演算部（演算部１１）が演算を実行する制御ソフトウェアを第二の制御ソフトウェア（第二の制御ソフトウェア１０２）に変更する。処理プログラム変更部１５が変更する処理プログラムとは、第一の制御ソフトウェア１０１、第二の制御ソフトウェア１０２のいずれかである。

　このように処理プログラム変更部１５は、状態判定部１４により判定された、車両制御システム１の空き時間の有無に基づいて、車両制御システム１を状態Ａから状態Ｂ、逆に状態Ｂから状態Ａに遷移させてもよいかを判定する。そして、状態判定部１４は、空き時間の判定結果を状態判定結果データ１４０として生成する。状態判定結果データ１４０は、演算部１１で演算するデータの状態判定結果を含むデータである。車両の状態が判定されてから演算部１１で実行されるソフトウェアが選択されるので、状態Ａであるにも関わらず、第二の制御ソフトウェア１０２の処理が割り込んで、自動運転に支障が生じることがない。また、車両制御システム１が状態Ｂで第二の制御ソフトウェア１０２の処理が行われていても、状態Ａと判定された場合、速やかに第一の制御ソフトウェア１０１の処理が復帰し、車両の自動運転に支障がない。

　次に、状態判定部１４の処理の詳細について説明する。
　図６は、第１の実施形態に係る状態判定部１４の処理手順例を示したフローチャートである。

　始めに、状態判定部１４は、車両制御システム１の計算資源使用率情報を取得する（Ｓ１１）。計算資源使用率情報とは、例えば、車両制御システム１の計算機６０（後述する図１５を参照）の負荷率やメモリ使用率などの情報である。

　次に、状態判定部１４は、計算資源使用率情報を元に、車両制御システム１の計算資源に十分な空きがあるか否かを判定する（Ｓ１２）。状態判定部１４は、計算資源に十分な空きがないと判定した場合（Ｓ１２のＮＯ）、車両制御システム１の演算部１１にて処理するプログラムを状態Ａでの第一の制御ソフトウェア１０１とする状態判定結果データ１４０を出力し（Ｓ１３）、本処理を終了する。

　一方、状態判定部１４は、計算資源に十分な空きがあると判定した場合（Ｓ１２のＹＥＳ）、車両制御システム１の演算部１１にて処理するプログラムを状態Ｂでの第二の制御ソフトウェア１０２とする状態判定結果データ１４０を出力し（Ｓ１４）、本処理を終了する。計算資源に空きがある時に実行される第二の制御ソフトウェア１０２の処理では、選定後のデータが使われる。このため、第二の制御ソフトウェア１０２の処理で必要とするデータ量が少なくなり、第一の制御ソフトウェア１０１より計算資源を消費せずに済む。

　その後、図５に示した処理プログラム変更部１５は、状態判定部１４にて生成された状態判定結果データ１４０の内容に応じて、車両制御システム１の演算部１１にて処理するプログラムを第一の制御ソフトウェア１０１又は第二の制御ソフトウェア１０２のどちらかに変更する。

　実行指示部（評価ソフトウェア実行指示部１６）は、変更部（処理プログラム変更部１５）により変更された第二の制御ソフトウェア（第二の制御ソフトウェア１０２）を用いて、保存部（比較基準データ保存部１３）に重要シナリオとして保存された入力データを入力として演算部（演算部１１）に演算を実行する指示を行う。車両が状態Ｂに切り換わった直後に第二の制御ソフトウェア１０２の演算の実行が行われるのでなく、評価ソフトウェア実行指示部１６の指示を受けて第二の制御ソフトウェア１０２の演算の実行が開始される。このため、状態Ａにおける後処理等が完了する前に、第二の制御ソフトウェア１０２の処理は開始されず、状態Ａにおける処理で使われた余計なデータが第二の制御ソフトウェア１０２の処理に混ざることがない。

　なお、車両制御システム１が状態Ｂから状態Ａに遷移する際にも、状態判定部１４が計算資源の空きを判定し、計算資源の空きがない場合に、処理プログラム変更部１５が演算部１１にて処理するプログラムを第一の制御ソフトウェア１０１に変更する。そして、評価ソフトウェア実行指示部１６は、状態Ａにおける第一の制御ソフトウェア１０１の演算の実行開始を指示する。

　次に、状態Ｂの車両制御システム１におけるデータの流れを説明する。
　図７は、第１の実施形態に係る車両制御システム１の別の一状態（状態Ｂ）におけるデータフローの例を示した図である。

　比較基準データ保存部１３は、図２に示したように内部に保存していた選定後の第一の制御ソフトウェア出力データ１０１１と、選定後のセンサデータ２１とを出力する。

　演算部１１は、選定後のセンサデータ２１を受け取ると、第二の制御ソフトウェア１０２を実行処理する。そして、第二の制御ソフトウェア１０２は、第二の制御ソフトウェア出力データ１０２０を出力する。

　性能・品質評価部１７は、選定後の第一の制御ソフトウェア出力データ１０１１と、第二の制御ソフトウェア出力データ１０２０とを受け取り、両データと、両データを出力した各制御ソフトウェアの性能及び品質とを評価し、評価結果データ１７０を出力する。ここで性能・品質とは、例えば、第一の制御ソフトウェア１０１と第二の制御ソフトウェア１０２の機能性や、出力結果の妥当性を表す。第一の制御ソフトウェア１０１と第二の制御ソフトウェア１０２の機能性とは、各ソフトウェアの機能そのものを表し、例えば、物体検知機能、自動運転する車両の軌道生成機能等がある。そして、性能・品質評価部１７は、実行された各ソフトウェアの機能は、求める機能を満たしているかを評価する。例えば、物体検知機能であれば、人や標識等の物体を正しく検知できたかが評価され、軌道生成機能であれば、車両が歩道でなく車道を走行するように軌道を正しく生成できたかが評価される。また、出力結果の妥当性とは、ソフトウェアの実行により意図した出力結果を得られたかが性能・品質評価部１７により評価された結果を表す。性能・品質評価部１７により行われるデータ、及び制御ソフトウェアの性能及び品質を「性能評価」と総称する。

　重要シナリオ特定部（重要シナリオ特定部１８）は、評価部（性能・品質評価部１７）による評価結果と、選定部（比較基準データ選定部１２）により選定された入力データ及び出力データと、第二の制御ソフトウェア（第二の制御ソフトウェア１０２）が出力した出力データとを受け取り、評価結果に基づいて、保存部（比較基準データ保存部１３）に保存すべきデータを重要シナリオとして特定する。例えば、重要シナリオ特定部１８は、選定後のセンサデータ２１と、選定後の第一の制御ソフトウェア出力データ１０１１と、第二の制御ソフトウェア出力データ１０２０と、評価結果データ１７０とを受け取る。そして、重要シナリオ特定部１８は、受け取った各データの内容に基づき、各データが重要であるか否かを判定する。ここで、シナリオとは各ソフトウェアに入力される入力データと出力データのパターンを表す。開発者が後の検証に残しておきたい重要なシナリオを「重要シナリオ」とも呼ぶ。重要シナリオが特定されることで、膨大な入力及び出力データを比較基準データ保存部１３に保存しなくてよく、記録容量の圧迫を防ぐことができる。

　そして、重要シナリオ特定部（重要シナリオ特定部１８）は、評価結果が不一致と評価された、第一の制御ソフトウェア（第一の制御ソフトウェア１０１）の出力データと、第二の制御ソフトウェア（第二の制御ソフトウェア１０２）の出力データとを含む重要シナリオを特定する。重要シナリオ特定部１８は、特定した重要シナリオを用いることで、第一の制御ソフトウェア１０１と第二の制御ソフトウェア１０２の出力データでどのような違いが生じたかを比較しやすくなる。例えば、重要シナリオ特定部１８は、第一の制御ソフトウェア１０１と比べて第二の制御ソフトウェア１０２の性能が改善したかを確認する。そして、性能が改善しなければ選定後のセンサデータ２１と、選定後の第一の制御ソフトウェア出力データ１０１１と、第二の制御ソフトウェア出力データ１０２０とを廃棄する。この場合、改めて開発された第二の制御ソフトウェア１０２が車両に配布され、この第二の制御ソフトウェア１０２の演算が実行される。

　また、車両制御システム１の開発者であれば、評価結果に関わらず、データの内容を直接確認したい場合もある。また、演算処理を行うＡＩの制御ソフトウェアによっては、入力された同じ入力データ（例えば、画像データ）に対して判断が異なることで、異なる出力データを出力することがある。このような入力データ及び出力データは、開発者にとって制御ソフトウェアの開発に生かしたいデータである。この場合、重要シナリオ特定部１８は、性能・品質評価部１７により第二の制御ソフトウェア１０２の性能が評価された時に用いられた第二の制御ソフトウェア１０２への入力データを残すことも可能である。

　次に、性能・品質評価部１７の処理の詳細について説明する。
　図８は、第１の実施形態に係る性能・品質評価部１７の処理手順例を示したフローチャートである。

　始めに、性能・品質評価部１７は、選定後の第一の制御ソフトウェア出力データ１０１１を受け取る（Ｓ２１）。次に、性能・品質評価部１７は、第二の制御ソフトウェア出力データ１０２０を受け取る（Ｓ２２）。

　次に、性能・品質評価部１７は、選定後の第一の制御ソフトウェア出力データ１０１１と、第二の制御ソフトウェア出力データ１０２０とを比較し、比較結果を評価し、評価結果データ１７０を生成する（Ｓ２３）。そして、性能・品質評価部１７は、評価結果データ１７０を出力し（Ｓ２４）、本処理を終了する。

　例えば、前方から自車両にトラックが近づく場合に、画像から物体を検知する機能を有する第一の制御ソフトウェア１０１であれば、センサ２が設置された位置及び画像からトラックを認識できると仮定する。また、第二の制御ソフトウェア１０２が、第一の制御ソフトウェア１０１が車両を判断した時に用いた画像を入力として、第一の制御ソフトウェア１０１と同様に、前方から近づく車両をトラックであると認識したのであれば、性能・品質評価部１７は、第二の制御ソフトウェア１０２の物体検知機能の評価がよいか、物体検知機能の性能が悪化していないと判断できる。しかし、第一の制御ソフトウェア１０１と第二の制御ソフトウェア１０２とで画像から車両のサイズを異なって認識する可能性がある。この場合、第一の制御ソフトウェア１０１では車両をワゴンと誤って認識し、第二の制御ソフトウェア１０２では車両をトラックと正しく認識したのであれば、性能・品質評価部１７は、第二の制御ソフトウェア１０２の物体検知機能の性能が高くなったと評価できる。

　次に、図１に示した重要シナリオ特定部１８の処理の詳細について説明する。
　図９は、第１の実施形態に係る重要シナリオ特定部１８の処理手順例を示したフローチャートである。

　始めに、重要シナリオ特定部１８は、選定後のセンサデータ２１と、選定後の第一の制御ソフトウェア出力データ１０１１と、第二の制御ソフトウェア出力データ１０２０とを受け取る（Ｓ３１）。

　次に、重要シナリオ特定部１８は、評価結果データ１７０を受け取る（Ｓ３２）。
　次に、重要シナリオ特定部１８は、評価結果データ１７０に基づき、受け取った各データが重要であるか否かを判定する（Ｓ３３）。

　重要シナリオ特定部１８は、受け取ったデータを重要データと判定した場合（Ｓ３３のＹＥＳ）、各データを車両制御システム１に保存し（Ｓ３４）、本処理を終了する。車両制御システム１に保存される各データとは、選定後のセンサデータ２１と選定後の第一の制御ソフトウェア出力データ１０１１と第二の制御ソフトウェア出力データ１０２０に加えて、評価結果データ１７０を含む。車両制御システム１に保存された各データは、例えば、ＵＳＢメモリ等の可搬型の記憶媒体にコピーされて、開発者がデータの内容を検証したり、新たなソフトウェアを開発したりするために用いられる。

　一方、重要シナリオ特定部１８は、受け取ったデータが重要でないと判定した場合（Ｓ３３のＮＯ）、各データを車両制御システム１に保存せず、本処理を終了する。

　以上説明した第１の実施形態に係る車両制御システム１では、制御ソフトウェア１０の制御ソフトウェア群を、同一の選定後のセンサデータ２１を入力として異なるタイミングで処理する。ここで、比較基準データ保存部１３は、センサ２から入力した全ての入力データではなく、特定のデータだけをセンサデータ２０として保存する。車両制御システム１が保存するデータは、性能・品質評価部１７での比較対象となる制御ソフトウェア群が出力データを算出するタイミング、又はドライバーによる特定の操作が行われたタイミングとする。そして、性能・品質評価部１７は、出力値が算出されたタイミング、又は特定の操作が行われたタイミングとは異なる時刻にて、比較基準データ保存部１３に保存しておいたセンサデータ２０を用いて、検証用の第二の制御ソフトウェア１０２を実行し、第二の制御ソフトウェア出力データ１０２０と、第一の制御ソフトウェア出力データ１０１０とを比較する。このため、車両制御システム１として高性能なＥＣＵを必要としない。
また、車両制御システム１は、高負荷なプログラムであってもシャドウモードテスティングを行うことが可能となる。

　また、車両の動作をシミュレーションする際に第二の制御ソフトウェア１０２を動作させるだけでなく、実車両から得た入力データを用いてバックグラウンドで第二の制御ソフトウェア１０２を動作させる。このため、走行している実車両の安全性を損なうことなく、第二の制御ソフトウェア１０２を検証できる。

　また、第二の制御ソフトウェア１０２は、例えば、第一の制御ソフトウェア１０１とはＡＩの学習モデルが異なるソフトウェアや、ＣＰＵの負荷率を下げることが可能なソフトウェアが想定される。また、既に稼働している第一の制御ソフトウェア１０１に内包されるエラーを改善したソフトウェアを第二の制御ソフトウェア１０２として検証してもよい。このような検証は、想定外のデータが入力しやすい実車両に搭載された車両制御システム１で行われるため、性能・品質評価部１７は、様々なバリエーションの入力データ（センサデータ２０）を用いて、第二の制御ソフトウェア１０２の品質を検証することができる。例えば、第一の制御ソフトウェア１０１のＣＰＵ負荷率が８０%である場合、第二の制御ソフトウェア１０２のＣＰＵ負荷率が７０％であれば、開発者は、第二の制御ソフトウェア１０２として用いたソフトウェアを第一の制御ソフトウェア１０１として用いることを検討できる。

　また、車両制御システム１で用いる第一の制御ソフトウェア１０１より処理の負荷が軽い第二の制御ソフトウェア１０２を使っても、第一の制御ソフトウェア出力データ１０１０と同様の品質の第二の制御ソフトウェア出力データ１０２０を得られるのであれば、第二の制御ソフトウェア１０２として用いたソフトウェアを、自動運転で実行される第一の制御ソフトウェア１０１に置き換えることも可能となる。このように第一の制御ソフトウェア１０１を処理の負荷が軽いソフトウェアに置き換えることで、膨大な計算を行う自動運転中の計算処理、及び計算資源の消費を抑制することができる。

［第１の実施形態の変形例］
　ここで、重要シナリオ特定部（重要シナリオ特定部１８）は、第一の制御ソフトウェア（第一の制御ソフトウェア１０１）が動作中であって、かつ第一の制御ソフトウェア（第一の制御ソフトウェア１０１）の出力結果に誤りがあると判断された場合に、重要シナリオとして特定したデータを保存部（比較基準データ保存部１３）に保存する。このため、通常は、処理結果が正常であるはずの第一の制御ソフトウェア１０１の処理結果が異常である場合に、開発者は、重要シナリオとして特定したデータと、第一の制御ソフトウェア１０１の処理内容を検証することができる。

　そこで、選定部（比較基準データ選定部１２）は、複数種類のセンサ（センサ２）から入力される複数の入力データを合成するセンサフュージョン処理を行って得た結果と、第一の制御ソフトウェア（第一の制御ソフトウェア１０１）が演算を実行して出力した出力データとの不一致を発見した場合に、第一の制御ソフトウェア（第一の制御ソフトウェア１０１）の出力結果に誤りがあると判断する。
　例えば、画像認識の結果が誤検知であるか否かは、画像認識ソフトウェアだけで判定できないことがある。センサフュージョンは、複数の異なるセンサから得た情報を用いて画像認識の結果を判定するための技術である。例えば、ＬｉＤＡＲ（Light Detection and Ranging）をセンサとして用いた場合、車両の前方に人が立っているか否かは、カメラが撮影して出力される画像データでも認識できるし、ＬｉＤＡＲから出力される点群データでも認識できると想定される。ここで、カメラから出力される画像データに基づいて人が立っていることが認識されたにも関わらず、ＬｉＤＡＲから得た点群データでは人が立っていることが認識できなかった場合、画像データ、又は点群データのいずれか又は両方の認識が誤っている。一方で、第二の制御ソフトウェア１０２は、画像データ、又は点群データのいずれであっても人が立っていることを認識できたのであれば、第二の制御ソフトウェア１０２は正しく人を認識できている。そこで、第一の制御ソフトウェア１０１がセンサフュージョンにより物体を検知する機能を持たない場合、比較基準データ選定部１２は、評価結果データ１７０と、第二の制御ソフトウェア出力データ１０２０を取得することで、第一の制御ソフトウェア１０１の出力結果の誤りを判定できる。このようにセンサフュージョンの技術を用いることで、複数のセンサから得たデータの認識結果に基づいて、第一の制御ソフトウェア１０１の出力結果の正誤判定を行うことが可能である。

　なお、自動運転中のセンサフュージョンにより第一の制御ソフトウェア１０１の出力と、第二の制御ソフトウェア１０２の出力とで不一致が生じた場合、車両の前方には人がいるものとして安全側の動作（例えば、車両の停止）となるよう制御される。ただし、実際には人が立っていなかった場合、人が立っていると認識した第一の制御ソフトウェア１０１又は第二の制御ソフトウェア１０２について、改めてテストが必要となる。

　また、選定部（比較基準データ選定部１２）は、車両が取得する車両の走行ログと、第一の制御ソフトウェア（第一の制御ソフトウェア１０１）が演算を実行して出力した出力データとの不一致を発見した場合に、第一の制御ソフトウェア（第一の制御ソフトウェア１０１）の出力結果に誤りがあると判断する。
　車両制御システム１は、ＧＰＳ（Global Positioning System）ナビゲーションシステム、タイヤの回転数からの算出等により自車位置を常に取得し、車両の走行ログを保存している。ここで、第一の制御ソフトウェア１０１が車両の軌道計画を演算する機能を有していれば、比較基準データ選定部１２は、第一の制御ソフトウェア１０１で演算された車両の軌道計画と、実際の走行ログとを比較する。そして、比較基準データ選定部１２は、車両の軌道計画が実際の走行ログからずれていれば、軌道計画、すなわち第一の制御ソフトウェア１０１の出力データに誤りがあると判断する。

　また、選定部（比較基準データ選定部１２）は、車両が持つ地図データと、第一の制御ソフトウェア（第一の制御ソフトウェア１０１）が演算を実行して出力した出力データとの不一致を発見した場合に、第一の制御ソフトウェア（第一の制御ソフトウェア１０１）の出力結果に誤りがあると判断する。
　上述したように車両制御システム１が取得する自車位置では道路上を車両が走行しているにも関わらず、第一の制御ソフトウェア１０１が演算した自車位置が道路以外の場所を車両が走行していることを表すことがある。この場合、比較基準データ選定部１２は、地図データに対して、第一の制御ソフトウェア１０１が演算した自車位置、すなわち第一の制御ソフトウェア１０１の出力データに誤りがあると判断する。

［第２の実施形態］
　次に、本発明の第２の実施形態に係る車両制御システム及び方法について説明する。
　第２の実施形態に係る車両制御システムが第１の実施形態と異なる点は、車両制御システム１が車外ネットワークを介してクラウドサーバと接続されている点である。これにより、第１の実施形態では車両制御システム１内にて実施していた機能及びプロセス、データの保存をクラウドサーバにて代替処理する点である。なお、第１の実施形態と同様の構成については、同一の符号を付してその説明を省略する。

　図１０は、第２の実施形態に係る車両制御システム１の全体構成例を示した図である。
　車両制御システム１は、車外ネットワークＮを介してクラウドサーバ４に接続されている。このような構成により、例えば、クラウドサーバ４からＯＴＡ（Over The Air）機能を用いて検証対象となる第二の制御ソフトウェア１０２を車両制御システム１に配信することが可能になる。車両制御システム１がクラウドサーバ４から受信した第二の制御ソフトウェア１０２は、制御ソフトウェア１０に格納される。

　演算部（演算部１１）は、ネットワーク（車外ネットワークＮ）を介してクラウドサーバ（クラウドサーバ４）から受信した第二の制御ソフトウェア（第二の制御ソフトウェア１０２）の演算を実行し、重要シナリオ特定部（重要シナリオ特定部１８）により重要シナリオと特定された、評価部（性能・品質評価部１７）による評価結果と、選定部（比較基準データ選定部１２）により選定された入力データ及び出力データと、第二の制御ソフトウェア（第二の制御ソフトウェア１０２）による出力データとをクラウドサーバ（クラウドサーバ４）に送信する。

　車両制御システム１は、動作検証が終わった第二の制御ソフトウェア１０２を破棄してよい。このため、第二の制御ソフトウェア１０２を車両制御システム１に保持しないことで、車両制御システム１の計算資源を削減することができる。また、クラウドサーバ４は、車両製造メーカーからの出荷後の車両に対して、新しいソフトウェアを提供することができ、ソフトウェアのアップグレード、車両の機能向上が容易となる。

　図１１は、第２の実施形態に係る車両制御システム１とクラウドサーバ４間で送受信される通信データの例を示した図である。

　クラウドサーバ４から車両制御システム１には、シャドウモードテスティングにて検証したいプログラムとして第二の制御ソフトウェア１０２が配信される。このため、車両制御システム１内に予め検証対象のプログラムを保存する必要が無い点で、第１の実施形態と異なる。

　また、車両制御システム１からクラウドサーバ４には、選定後のセンサデータ２１と、選定後の第一の制御ソフトウェア出力データ１０１１と、第二の制御ソフトウェア出力データ１０２０と、評価結果データ１７０とが送信される。このため、例えばクラウドサーバ４内にて性能・品質評価部１７と同様の性能・品質評価が可能となる。また、クラウドサーバ４が車両制御システム１から受信したデータを用いて処理した評価結果と、車両制御システム１から受信した評価結果データ１７０とを比較することもできる。また、クラウドサーバ４内にて重要シナリオ特定部１８と同様の処理を実施することが可能である。
この結果、車両制御システム１内での処理を簡略化することが可能となる点で、第１の実施形態と異なる。

　以上説明した第２の実施形態に係る車両制御システム１では、第二の制御ソフトウェア１０２を予め保存しておく必要がなく、また、検証を行いたいタイミングでクラウドサーバ４から第二の制御ソフトウェア１０２が配信される。このため、車両制御システム１は、最新の第二の制御ソフトウェア１０２を用いて検証することが可能となる。

　また、車両制御システム１で用いる各データはクラウドサーバ４に送信される。そして、クラウドサーバ４は、受信した各データを用いて、性能・品質評価等の処理を実行可能である。このため、車両制御システム１では、性能・品質評価部１７、重要シナリオ特定部１８を備えない構成とすることが可能となる。

　また、車両制御システム１は、クラウドサーバ４からダウンロードした学習済みプログラムを第二の制御ソフトウェア１０２として制御ソフトウェア１０に格納し、この第二の制御ソフトウェア１０２の性能を評価できる。この学習済みプログラムは、例えば、ＡＩで作成されたプログラムである。このため、クラウドサーバ４は、多数の車両に搭載された車両制御システム１で学習済みプログラムの安全性の検証を行い、様々な走行シーンに応じた検証結果を得ることができる。そして、開発者は、第一の制御ソフトウェア１０１の出力結果に対して、第二の制御ソフトウェア１０２の出力結果の精度が低ければ、第二の制御ソフトウェア１０２を用いないようにする、又は改修するといった判断が可能となる。

　なお、第一の制御ソフトウェア１０１の出力結果に誤りがあると判断された入力及び出力データであっても比較基準データ保存部１３に保存されるとよい。このようなデータは、後に比較基準データ保存部１３からクラウドサーバ４にアップロードされることで入力及び出力データを開発者が取得し、内容を検証することが可能となる。また、第一の制御ソフトウェア１０１の出力結果に誤りがあると判断されたのであれば、開発者にとって第一の制御ソフトウェア１０１の機能を向上したソフトウェアの開発に役立てることが可能となる。このため、クラウドサーバ４は、多数の車両から第一の制御ソフトウェア出力データ１０１０と、この出力データに付随する第二の制御ソフトウェア１０２の評価結果データ１７０とを収集するとよい。

　そして、クラウドサーバ４に蓄積された各データを開発者が検証することで、第一の制御ソフトウェア１０１の不具合を改善した制御ソフトウェアを第二の制御ソフトウェア１０２として車両に配信し、改めてシャドウモードテスティングで第二の制御ソフトウェア１０２の性能を検証することができる。

［第３の実施形態］
　次に、本発明の第３の実施形態に係る車両制御システム及び方法について説明する。
　第３の実施形態に係る車両制御システムが第１の実施形態と異なる点は、車両制御システム１がドライバー操作センサ５に対してバスで接続されている点である。

　図１２は、第３の実施形態に係る車両制御システム１の全体構成例を示した図である。
　上述したように、車両制御システム１はドライバー操作センサ５に接続されている。
　ドライバー操作センサ５は、車両を運転するドライバーの操作を検出し、操作信号を車両制御システム１に出力する。ドライバーの操作として、例えば、ドライバーによるハンドル操作やブレーキ踏み込みが含まれ、ドライバーの操作量には、ハンドルの操作角やブレーキ踏み込み量といった操作量が含まれる。

　上述したように第１の実施形態に係る車両制御システム１では、第一の制御ソフトウェア出力データ１０１０を用いてアクチュエータ３を操作していた。一方、第３の実施形態に係る車両制御システム１の構成ではドライバーが行った操作の操作量をドライバー操作センサ５を介して入手し、アクチュエータ３へと伝達する。このように第１の実施形態に係る自動運転によるアクチュエータ３を動作させるためのプロセスが、第３の実施形態に係るドライバーの操作によるプロセスに代替されて、車両の制御が行われる。

　そこで、評価部（性能・品質評価部１７）は、車両の走行中に入力されるドライバーの操作データと、センサ（センサ２）から第二の制御ソフトウェア（第二の制御ソフトウェア１０２）に入力される入力データを用いて実行した演算により出力する出力データとを比較して、第二の制御ソフトウェア（第二の制御ソフトウェア１０２）の性能を評価する。このため、第３の実施形態に係る車両制御システム１は、シャドウモードテスティングによる比較参照データとして、第１の実施形態の性能・品質評価部１７にて選定後の第一の制御ソフトウェア出力データ１０１１と第二の制御ソフトウェア出力データ１０２０を用いた処理を、ドライバー操作センサ５を介して入手したドライバー操作量と第二の制御ソフトウェア出力データ１０２０とに代替する。アクチュエータ３の操作には第１の実施形態に係る第一の制御ソフトウェア１０１の出力データを用いる必要が無く、ドライバー操作センサ５の出力データであるドライバーによるハンドル操作やブレーキ踏み込み量を基に車両の運転が制御される。

　図１３は、第３の実施形態に係る車両制御システム１の状態遷移の例を示した図である。ここでは、車両制御システム１が状態Ｃに遷移したものとする。

　車両制御システム１の演算部１１では、センサ２の出力値を用いて第二の制御ソフトウェア１０２が演算処理されている。車両制御システム１の性能・品質評価部１７は、状態Ｃに遷移すると、ドライバー操作センサ５の出力値であるドライバー操作データ５０を直接受け取る。また、性能・品質評価部１７は、演算部１１が第二の制御ソフトウェア１０２を用いて演算した第二の制御ソフトウェア出力データ１０２０を受け取る。この性能・品質評価部１７は、第二の制御ソフトウェア１０２の性能・品質を評価し、シャドウモードテスティングを実行可能としている点で第１の実施形態と異なる。

　図１４は、第３の実施形態に係る車両制御システム１の一状態（状態Ｃ）におけるデータフローの例を示した図である。

　上述したように、ドライバー操作センサ５は、ドライバーのハンドル操作量やブレーキペダル踏み込み量といったドライバーによる操作量をドライバー操作データ５０として出力する。一方、センサ２は、センシング結果をセンサデータ２０として出力する。

　演算部１１は、受け取ったセンサデータ２０を基に第二の制御ソフトウェア１０２の演算処理を行い、第二の制御ソフトウェア出力データ１０２０を出力する。性能・品質評価部１７は、ドライバー操作データ５０と、第二の制御ソフトウェア出力データ１０２０とを受け取る。そして、性能・品質評価部１７は、両データの比較結果に基づき、第二の制御ソフトウェア１０２の性能及び品質を評価し、評価結果データ１７０を出力する。

　重要シナリオ特定部１８は、ドライバー操作データ５０と、センサデータ２０と、第二の制御ソフトウェア出力データ１０２０と、評価結果データ１７０とを受け取り、評価結果データ１７０の内容に基づき、重要シナリオを特定する。以上により、性能・品質評価部１７は、第一の制御ソフトウェア１０１の代わりにドライバー操作データ５０を用いることで、第二の制御ソフトウェア１０２の性能及び品質が評価できる点で、第１の実施形態と異なる。

　以上説明した第３の実施形態に係る車両制御システム１では、第一の制御ソフトウェア１０１の代わりにドライバー操作データ５０を用いて、車両の走行中に演算が実行される第二の制御ソフトウェア１０２の性能及び品質を評価する。このように車両制御システム１は、車両の走行中（状態Ｃ）におけるシャドウモードテスティングを実行することが可能となる。

　例えば、車両のドライバーが運転操作を行っている間、車両制御システム１が車両の状態を状態Ｃとして、バックグラウンドで第二の制御ソフトウェア１０２を実行しておく。
そして、性能・品質評価部１７は、ドライバーの運転により得られたドライバー操作データ５０と、第二の制御ソフトウェア１０２が出力した第二の制御ソフトウェア出力データ１０２０とをリアルタイムで比較し、評価する。このため、性能・品質評価部１７は、例えば、車両を走行中のドライバーが前方に落下物等を見つけて惰行操作した時の車両の軌道と、第二の制御ソフトウェア１０２が画像を認識して、生成した車両の軌道との一致度を確認することで、第二の制御ソフトウェア１０２の性能及び品質を評価することができる。

＜計算機のハードウェア構成＞
　次に、車両制御システム１を構成する計算機６０のハードウェア構成を説明する。
　図１５は、計算機６０のハードウェア構成例を示すブロック図である。計算機６０は、本実施の形態に係る車両制御システム１として動作可能なコンピューターとして用いられるハードウェアの一例である。

　計算機６０は、バス６４にそれぞれ接続されたＣＰＵ（Central Processing Unit）６１、ＲＯＭ（Read Only Memory）６２、及びＲＡＭ（Random Access Memory）６３を備える。さらに、計算機６０は、不揮発性ストレージ６５及びネットワークインターフェイス６６を備える。

　ＣＰＵ６１は、本実施の形態に係る各機能を実現するソフトウェアのプログラムコードをＲＯＭ６２から読み出してＲＡＭ６３にロードし、実行する。ＲＡＭ６３には、ＣＰＵ６１の演算処理の途中で発生した変数やパラメーター等が一時的に書き込まれ、これらの変数やパラメーター等がＣＰＵ６１によって適宜読み出される。ただし、ＣＰＵ６１に代えてＭＰＵ（Micro Processing Unit）を用いてもよい。図１等に示した演算部１１、比較基準データ選定部１２等の機能は、ＣＰＵ６１により実現される。

　不揮発性ストレージ６５としては、例えば、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フレキシブルディスク、光ディスク、光磁気ディスク、ＣＤ－ＲＯＭ、ＣＤ－Ｒ、磁気テープ又は不揮発性のメモリ等が用いられる。この不揮発性ストレージ６５には、ＯＳ（Operating System）、各種のパラメーターの他に、計算機６０を機能させるためのプログラムが記録されている。ＲＯＭ６２及び不揮発性ストレージ６５は、ＣＰＵ６１が動作するために必要なプログラムやデータ等を記録しており、計算機６０によって実行されるプログラムを格納したコンピューター読取可能な非一過性の記憶媒体の一例として用いられる。図１等に示した制御ソフトウェア１０、比較基準データ保存部１３は、不揮発性ストレージ６５に構成される。

　ネットワークインターフェイス６６には、例えば、ＮＩＣ（Network Interface Card）等が用いられ、ＮＩＣの端子に接続されたＬＡＮ（Local Area Network）、専用線等を介して各種のデータを装置間で送受信することが可能である。例えば、センサ２、アクチュエータ３とのインターフェイス、クラウドサーバ４との通信がネットワークインターフェイス６６を通じて行われる。また、車両制御システム１とセンサ２及びアクチュエータ３との間の通信は、例えば、ＣＡＮ（Controller Area Network）を介して行われる。

　なお、本発明は上述した各実施の形態に限られるものではなく、請求の範囲に記載した要旨を逸脱しない限りその他種々の応用例、変形例を取り得ることは勿論である。
　例えば、上述した各実施の形態は本発明を分かりやすく説明するために装置及びシステムの構成を詳細かつ具体的に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されない。また、ここで説明した実施の形態の構成の一部を他の実施の形態の構成に置き換えることは可能であり、さらにはある実施の形態の構成に他の実施の形態の構成を加えることも可能である。また、各実施の形態の構成の一部について、他の構成の追加、削除、置換をすることも可能である。
　また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

　１…車両制御システム、２…センサ、３…アクチュエータ、１０…制御ソフトウェア、１１…演算部、１２…比較基準データ選定部、１３…比較基準データ保存部、１４…状態判定部、１５…処理プログラム変更部、１６…評価ソフトウェア実行指示部、１７…性能・品質評価部、１８…重要シナリオ特定部、２０…センサデータ、２１…選定後のセンサデータ、１０１…第一の制御ソフトウェア、１０２…第二の制御ソフトウェア、１４０…状態判定結果データ、１７０…評価結果データ、１０１０…第一の制御ソフトウェア出力データ、１０１１…選定後の第一の制御ソフトウェア出力データ、１０２０…第二の制御ソフトウェア出力データ

Claims (15)

1. 　車両が第一の状態である場合に第一の制御ソフトウェアの演算を実行し、前記車両が第二の状態である場合に第二の制御ソフトウェアの演算を実行する演算部と、
   　センサから前記第一の制御ソフトウェア及び前記第二の制御ソフトウェアにそれぞれ入力される入力データ、並びに前記第一の制御ソフトウェア及び前記第二の制御ソフトウェアが前記入力データを入力として実行した演算により出力する出力データと、を保存する保存部と、
   　前記保存部から読み出した、前記第一の制御ソフトウェア及び前記第二の制御ソフトウェアがそれぞれ出力した前記出力データを比較して、前記第二の制御ソフトウェアの性能を評価する評価部と、を備える
   　車両制御システム。
2. 　前記評価部が前記第二の制御ソフトウェアを評価するための前記入力データ及び前記出力データを、前記第一の制御ソフトウェアへの入力とされた前記入力データ、及び前記第一の制御ソフトウェアが出力した前記出力データから選定し、選定した前記入力データ及び前記出力データを前記保存部に保存する選定部を備える
   　請求項１に記載の車両制御システム。
3. 　前記選定部は、前記評価部による前記第二の制御ソフトウェアの評価のための重要シナリオとして前記保存部に保存すべきデータを、前記第一の制御ソフトウェアが出力する前記出力データに基づいて選定する
   　請求項２に記載の車両制御システム。
4. 　前記演算部が動作する計算資源の空きに基づいて、前記車両が前記第一の状態又は前記第二の状態のいずれであるかを判定する状態判定部と、
   　前記状態判定部により前記計算資源の空きがないと判定された場合に前記演算部が演算を実行する制御ソフトウェアを前記第一の制御ソフトウェアとし、前記計算資源の空きがあると判定された場合に前記演算部が演算を実行する前記制御ソフトウェアを前記第二の制御ソフトウェアに変更する変更部を備える
   　請求項３に記載の車両制御システム。
5. 　前記変更部により変更された前記第二の制御ソフトウェアを用いて、前記保存部に前記重要シナリオとして保存された前記入力データを入力として前記演算部に演算を実行する指示を行う実行指示部を備える
   　請求項４に記載の車両制御システム。
6. 　前記評価部による評価結果と、前記選定部により選定された前記入力データ及び前記出力データと、前記第二の制御ソフトウェアが出力した前記出力データとを受け取り、前記評価結果に基づいて、前記保存部に保存すべきデータを重要シナリオとして特定する重要シナリオ特定部を備える
   　請求項４に記載の車両制御システム。
7. 　前記重要シナリオ特定部は、前記評価結果が不一致と評価された、前記第一の制御ソフトウェアの出力データと、前記第二の制御ソフトウェアの出力データとを含む前記重要シナリオを特定する
   　請求項６に記載の車両制御システム。
8. 　前記重要シナリオ特定部は、前記第一の制御ソフトウェアが動作中であって、かつ前記第一の制御ソフトウェアの出力結果に誤りがあると判断された場合に、前記重要シナリオとして特定したデータを前記保存部に保存する
   　請求項６に記載の車両制御システム。
9. 　前記選定部は、複数種類の前記センサから入力される複数の前記入力データを合成するセンサフュージョン処理を行って得た結果と、前記第一の制御ソフトウェアが演算を実行して出力した前記出力データとの不一致を発見した場合に、前記第一の制御ソフトウェアの出力結果に誤りがあると判断する
   　請求項８に記載の車両制御システム。
10. 　前記選定部は、前記車両が取得する前記車両の走行ログと、前記第一の制御ソフトウェアが演算を実行して出力した前記出力データとの不一致を発見した場合に、前記第一の制御ソフトウェアの出力結果に誤りがあると判断する
    　請求項８に記載の車両制御システム。
11. 　前記選定部は、前記車両が持つ地図データと、前記第一の制御ソフトウェアが演算を実行して出力した前記出力データとの不一致を発見した場合に、前記第一の制御ソフトウェアの出力結果に誤りがあると判断する
    　請求項８に記載の車両制御システム。
12. 　前記状態判定部は、前記演算部が動作する計算資源の空きの有無を、自動運転サービスの提供範囲、前記車両が充電モード中であること、前記車両が停車中であること、又は、
    前記車両に搭載された計算機の負荷情報、のうち、少なくともいずれか一つに基づいて判断し、かつ前記評価部が前記第二の制御ソフトウェアの評価を実行可能であるかを判定する
    　請求項４に記載の車両制御システム。
13. 　前記演算部は、ネットワークを介してクラウドサーバから受信した前記第二の制御ソフトウェアの演算を実行し、前記重要シナリオ特定部により前記重要シナリオと特定された、前記評価部による評価結果と、前記選定部により選定された前記入力データ及び前記出力データと、前記第二の制御ソフトウェアによる前記出力データとを前記クラウドサーバに送信する
    　請求項６に記載の車両制御システム。
14. 　車両が第一の状態である場合に第一の制御ソフトウェアの演算を実行し、前記車両が第二の状態である場合に第二の制御ソフトウェアの演算を実行する処理と、
    　センサから前記第一の制御ソフトウェア及び前記第二の制御ソフトウェアにそれぞれ入力される入力データ、並びに前記第一の制御ソフトウェア及び前記第二の制御ソフトウェアが前記入力データを入力として実行した演算により出力する出力データと、を保存部に保存する処理と、
    　前記保存部から読み出した、前記第一の制御ソフトウェア及び前記第二の制御ソフトウェアがそれぞれ出力した前記出力データを比較して、前記第二の制御ソフトウェアの性能を評価する処理と、を含む
    　車両制御方法。
15. 　第二の制御ソフトウェアの演算を実行する演算部と、
    　車両の走行中に入力されるドライバーの操作データと、センサから前記第二の制御ソフトウェアに入力される入力データを用いて実行した演算により出力する出力データとを比較して、前記第二の制御ソフトウェアの性能を評価する評価部と、を備える
    　車両制御システム。
     

Images