JP2022013187A

JP2022013187A - 車両制御装置

Info

Publication number: JP2022013187A
Application number: JP2020115578A
Authority: JP
Inventors: 祐石郷岡; Hiroshi Ishigooka; 一芹沢; Hajime Serizawa
Original assignee: Hitachi Astemo Ltd
Current assignee: Astemo Ltd
Priority date: 2020-07-03
Filing date: 2020-07-03
Publication date: 2022-01-18
Anticipated expiration: 2040-07-03
Also published as: US20230222050A1; US12536094B2; DE112021002403T5; WO2022004324A1; JP7508293B2

Abstract

【課題】旧バージョンの制御ソフトウェア（旧制御ソフト部）と新バージョンの制御ソフトウェア（新制御ソフト部）の出力を比較することで、精度に影響を与える実行条件を特定することができる車両制御装置を提供する。【解決手段】車両制御装置は、旧バージョンの制御ソフトウェアを示す旧制御ソフト部１１２と、新バージョンの制御ソフトウェアを示す新制御ソフト部１１３を並行または並列に実行する検証管理部と、前記旧制御ソフト部１１２の出力と前記新制御ソフト部１１３の出力が不一致に相当する場合に不一致を示す情報を出力する出力検証部と、を備える。【選択図】図１４

Description

本発明は、車両制御装置に関する。

自動運転システムは複数の電子制御ユニット（ＥＣＵ）で構成される。例えば、カメラなどの外界環境を認識するＥＣＵと、認識した外界情報に基づいて走行経路を決定する自動運転ＥＣＵと、決定された経路に基づいて車両を走行させるためにステアリングなどを制御するアクチュエータＥＣＵで構成される。

運転手の代わりに走る、曲がる、止まるを判断・実施する自動運転システムの高度化に伴い、外界認識・走行経路計画・車両制御を実現する制御ソフトウェアの複雑化が進展している。

高品質な自動運転システムの実現には、十分なテストが求められるが、システムの稼働条件が膨大であるために、まれに発生する状況も含めたテストケースの設計が困難である。特に機械学習を含む制御ソフトウェアの場合、特定の状況で精度を向上させた制御ソフトウェアが、別の状況で精度が低下している可能性があり、網羅性の高い検証手法が求められる。

特許第6571897号公報

特許文献１記載の技術によると、マルチコア対応の制御ソフトウェアにおいて、第一の制御ソフトウェアと、一部が変更された第二の制御ソフトウェアに対して、同一のテストケースで実行した処理結果を比較することで、並行性処理の妥当性と前記並行性欠陥の原因を推定できる。

しかしながら、特許文献１では、予め設計されたテストケースで品質が依存しているため、本発明が求める高い網羅性を達成することができない課題がある。

本発明は、上記のような課題を解決するためになされたものであり、オンボードで旧バージョンの制御ソフトウェア（旧制御ソフト部）と新バージョンの制御ソフトウェア（新制御ソフト部）の出力から、精度に影響を与える実行条件を特定することができる車両制御装置を提供することを目的とする。

上記目的を達成するために、本発明の車両制御装置は、旧バージョンの制御ソフトウェアを示す旧制御ソフト部と、新バージョンの制御ソフトウェアを示す新制御ソフト部を並行または並列に実行する検証管理部と、前記旧制御ソフト部の出力と前記新制御ソフト部の出力が不一致に相当する場合に不一致を示す情報を出力する出力検証部と、を備える。

本発明によれば、旧制御ソフト部と新制御ソフト部の出力から、精度に影響を与える実行条件を特定することができる。上記した以外の課題、構成及び効果は、以下の実施の形態の説明により明らかにされる。

実施の形態１に係るシステムと車両制御装置の構成図である。実施の形態１に係る旧制御ソフト部の処理フローである。実施の形態１に係る新制御ソフト部の処理フローである。実施の形態１、２、３に係るセンサ受信部の処理フローである。実施の形態１、３に係る検証管理部の処理フローである。実施の形態１、２、３に係る時系列テスト入力保存部の処理フローである。実施の形態１、２、３に係る時系列テストケース定義部の処理フローである。実施の形態１、２、３に係る出力比較部の処理フローである。実施の形態１、２、３に係る送信部の処理フローである。実施の形態１、２、３に係るセンシング部の処理フローである。実施の形態１、２、３に係る転送処理部の処理フローである。実施の形態１、２、３に係る制御処理部の処理フローである。実施の形態１、２、３に係る情報保存部の処理フローである。実施の形態１に係る車両制御装置のデータフローである。実施の形態１に係る車両制御装置のスケジューリング情報である。実施の形態２に係るシステムと車両制御装置の構成図である。実施の形態２に係る旧制御ソフト部の動作フローである。実施の形態２に係る新制御ソフト部の動作フローである。実施の形態２に係る検証管理部の動作フローである。実施の形態２に係る車両制御装置のスケジューリング情報である。実施の形態３に係るシステムと車両制御装置の構成図である。実施の形態３に係る切替監視部の動作フローである。実施の形態３に係る車両制御装置のスケジューリング情報である。実施の形態４に係る車両制御装置のスケジューリング情報である。

以下、図面を用いて本発明の実施の形態について説明する。

本発明の実施の形態に係る車両制御装置は、オンボードでセンサ情報を一定時間の間、時系列に保存する。保存した時系列センサ情報からテストケースを生成し、実時間とは異なる検証内時間に基づいて旧制御ソフトと新制御ソフトを前記テストケースで実行する。それらの出力結果を比較することで精度に影響を与える実行条件を特定できる。旧制御ソフトを実行していない空きリソース（時間、CPU）を用いて検証するため、コストを抑制しつつ、自動運転システムを検証できる。

（実施の形態１）
図１は、本発明の実施の形態１に係るシステムと車両制御装置の構成図を示す。自動運転システム１は、自動運転ＥＣＵ１１、センサＥＣＵ１２、ゲートウェイＥＣＵ１３、アクチュエータＥＣＵ１４、クラウド１５で構成される。自動運転ＥＣＵ１１はセンサＥＣＵ１２、ゲートウェイＥＣＵ１３、アクチュエータＥＣＵ１４と通信可能であり、クラウド１５にはゲートウェイＥＣＵ１３経由でデータの送受信が可能である。

自動運転ＥＣＵ１１は旧制御ソフト部１１１、旧制御ソフト部１１２、新制御ソフト部１１３、センサ値受信部１１４、検証管理部１１５、時系列テスト入力保存部１１６、時系列テストケース定義部１１７、出力比較部１１８、送信部１１９で構成される。

また、自動運転ＥＣＵ１１は、ＣＰＵ－Ａ１０１、ＣＰＵ－Ｂ１０２、ＣＰＵ－Ｃ１０３を搭載し、新制御ソフト検証出力値１０４、旧制御ソフト検証出力値１０５、新制御ソフト検証入力値１０６、旧制御ソフト検証入力値１０７、時系列入力値１０８、旧制御ソフト入力値１０９を備える。

センサＥＣＵ１２はセンシング部１２１で構成される。ゲートウェイＥＣＵ１３は転送処理部１３１で構成される。アクチュエータＥＣＵ１４は制御処理部１４１で構成される。クラウド１５は情報保存部１５１で構成される。

以降より、実施の形態１に係る動作フローの詳細を説明する。

図２は旧制御ソフト部１１１と旧制御ソフト部１１２の動作フローである。以下、図２の各ステップについて説明する。

（図２：ステップ１１１１）
旧制御ソフト部１１１または１１２は入力されたセンサ値に基づいて認識処理・経路計画・制御指令を算出する。旧制御ソフト部１１１は旧制御ソフト入力値１０９から、旧制御ソフト部１１２は旧制御ソフト検証入力値１０７を参照しセンサ値を読み出す。

（図２：ステップ１１１２）
旧制御ソフト部１１１または１１２は、自身が検証で用いられるプログラムか否かを判定し、偽（Ｎ：ＮＯ）である場合にはステップ１１１３に進み、真（Ｙ：ＹＥＳ）である場合にはステップ１１１４に進む。

（図２：ステップ１１１３）
旧制御ソフト部１１１または１１２は、送信部１１９を利用して制御指令をアクチュエータＥＣＵに送信する。

（図２：ステップ１１１４）
旧制御ソフト部１１１または１１２は、検証対象となる計算結果を旧制御ソフト検証出力値１０５に保存する。

図３は新制御ソフト部１１３の動作フローである。以下、図３の各ステップについて説明する。

（図３：ステップ１１３１）
新制御ソフト部１１３は入力されたセンサ値に基づいて認識処理・経路計画・制御指令を算出する。

（図３：ステップ１１３２）
新制御ソフト部１１３は、検証対象となる計算結果を新制御ソフト検証出力値１０４に保存する。

図４はセンサ値受信部１１４の動作フローである。以下、図４の各ステップについて説明する。

（図４：ステップ１１４１）
センサ値受信部１１４はセンサＥＣＵ１２からセンサ値を受信し、旧制御ソフト入力値１０９に保存する。

（図４：ステップ１１４２）
センサ値受信部１１４は受信したセンサ値を入力として、時系列ソフト入力保存部１１６を実行する。

図５は検証管理部１１５の動作フローである。以下、図５の各ステップについて説明する。

（図５：ステップ１１５１）
検証管理部１１５は、検証フラグがＯＮであるか否かを判定し、偽（Ｎ：ＮＯ）である場合には本動作フローを終了する。真（Ｙ：ＹＥＳ）である場合にはステップ１１５２に進む。

（図５：ステップ１１５２）
検証管理部１１５は、検証内時間が検証終了時間を超過するか否かを判定し、真（Ｙ：ＹＥＳ）である場合にはステップ１１５３に進み、偽（Ｎ：ＮＯ）である場合にはステップ１１５４に進む。検証内時間は車両制御装置起動時に初期化される想定である。

（図５：ステップ１１５３）
検証管理部１１５は、検証内時間を初期化した後に、検証フラグをＯＦＦにする。

（図５：ステップ１１５４）
検証管理部１１５は、時系列テストケース定義部１１７を実行し、現在の検証内時間に対応したテストケースを入手する。

（図５：ステップ１１５５）
検証管理部１１５は、前記テストケースを入力として、検証用の旧制御ソフト部１１２を実行する。

（図５：ステップ１１５６）
検証管理部１１５は、前記テストケースを入力として、検証用の新制御ソフト部１１３を実行する。

（図５：ステップ１１５７）
検証管理部１１５は、旧制御ソフト部１１２と新制御ソフト部１１３の出力を比較するために出力比較部１１８を実行する。

（図５：ステップ１１５８）
検証管理部１１５は、検証内時間を進め、ステップ１１５２に進む。

図６は時系列テスト入力保存部１１６の動作フローである。以下、図６の各ステップについて説明する。

（図６：ステップ１１６１）
時系列テスト入力保存部１１６は、入力されたセンサ値を時系列入力値１０８に保存する。

（図６：ステップ１１６２）
時系列テスト入力保存部１１６は、メモリに空き領域があるか否かを判定し、真（Ｙ：ＹＥＳ）である場合には本動作フローを終了し、偽（Ｎ：ＮＯ）である場合にはステップ１１６３に進む。本実施例では、センサ値を保存する終了条件および検証を開始する条件をメモリの空き領域としているがこれに限らない。例えば、一定時間の間のセンサ値を保存することを終了条件としてよい。さらに、終了条件と開始条件を異なる条件としてよい。例えば、終了条件をメモリの空き領域が一定以下、開始条件をＣＰＵ負荷が一定以下としてもよい。

（図６：ステップ１１６３）
時系列テスト入力保存部１１６は、検証フラグをＯＮにする。

図７は時系列テストケース定義部１１７の動作フローである。以下、図７の各ステップについて説明する。

（図７：ステップ１１７１）
時系列テストケース定義部１１７は、時系列入力値１０８から現在の検証内時間に対応する入力値を旧制御ソフト検証入力値１０７と新制御ソフト検証入力値１０６にコピーする。

図８は出力比較部１１８の動作フローである。以下、図８の各ステップについて説明する。

（図８：ステップ１１８１）
出力比較部１１８は、旧制御ソフト検証出力値１０５と新制御ソフト検証出力値１０４を比較する。

（図８：ステップ１１８２）
出力比較部１１８は、比較した結果が一致しているか否かを判定し、真（Ｙ：ＹＥＳ）である場合には本動作フローを終了し、偽（Ｎ：ＮＯ）である場合にはステップ１１８３に進む。本実施例では、出力結果が妥当であるか否かを比較結果との一致によって判定しているがこれに限らない。例えば、各々出力値が予め設定した正解値と比較することで妥当性を判定してもよい。正解値とは危険状態に到達する可能性のある条件である。しかしこれに限らない。

ここで、危険状態は、異常値（例えば、シーンにそぐわない値、連続性がない値）を出力する状態である。具体的には、例えば、高速道路にそぐわない物体が識別される状態や、AIで物体を識別するときに、今まで「人」として識別されていた物体が急に「猫」と判定されるような状態である。

例えば、出力検証部は、旧制御ソフト部１１２の出力と新制御ソフト部１１３の出力をそれぞれ正解値と比較し、それぞれの比較結果のうち少なくとも一方が正解値と異なる場合に不一致を示す情報を出力するようにする。

（図８：ステップ１１８３）
出力比較部１１８は、時系列入力値１０８とマイコン情報（ＣＰＵやペリフェラル）、実行情報（ＣＰＵ負荷、メモリ消費量、スケジューリングログ）などをゲートウェイＥＣＵ経由でクラウド１５に送信する。本実施例では、クラウドに送信しているがこれに限らない。例えば、同じ車両に搭載したドライブレコーダなどの記憶装置に保存してもよい。

図９は送信部１１９の動作フローである。以下、図９の各ステップについて説明する。

（図９：ステップ１１９１）
送信部１１９は、入力されたデータを指定先に送信する。指定先とは、例えば、アクチュエータＥＣＵ１４やクラウド１５である。

図１０はセンシング部１２１の動作フローである。以下、図１０の各ステップについて説明する。

（図１０：ステップ１２１１）
センシング部１２１は、センシングしたセンサ値を自動運転ＥＣＵ１１に送信する。

図１１は転送処理部１３１の動作フローである。以下、図１１の各ステップについて説明する。

（図１１：ステップ１３１１）
転送処理部１３１は、入力されたデータをクラウド１５に転送する。

図１２は制御処理部１４１の動作フローである。以下、図１２の各ステップについて説明する。

（図１２：ステップ１４１１）
制御処理部１４１は、入力された制御指令値に基づいてアクチュエータを制御する。

図１３は情報保存部１５１の動作フローである。以下、図１３の各ステップについて説明する。

（図１３：ステップ１５１１）
情報保存部１５１は、受信した時系列入力値１０８とマイコン情報（ＣＰＵやペリフェラル）、実行情報（ＣＰＵ負荷、メモリ消費量、スケジューリングログ）などを保存する。

図１４は実施の形態１に係る車両制御装置のデータフローである。

センサ値受信部１１４は受信したセンサ値を時系列テスト入力保存部１１６に入力する。また、センサ値受信部１１４は受信したセンサ値を旧制御ソフト入力値１０９に保存する。旧制御ソフト部１１１は入力されたセンサ値に基づいて演算を行い、その結果を送信部１１９で送信する。

時系列テスト入力保存部１１６は入力されたセンサ値を時系列入力値１０８に保存する。換言すれば、時系列テスト入力保存部１１６は、走行中の車両のセンサによる時系列の入力値を示す時系列入力値を保存する。

時系列テストケース定義部１１７は時系列入力値１０８から検証内時間に応じた保存済みセンサ値を、旧制御ソフト検証入力値１０７と新制御ソフト検証入力値１０６に保存する。換言すれば、時系列テストケース定義部１１７は、時系列入力値から検証内時間に対応する入力値を含むテストケースを選定する。

旧制御ソフト部１１２は旧制御ソフト検証入力値１０７を入力として演算を行い、その結果を旧制御ソフト検証出力値１０５に保存する。新制御ソフト部１１３は新制御ソフト検証入力値１０６を入力として演算を行い、その結果を新制御ソフト検証出力値１０４に保存する。出力比較部１１８は旧制御ソフト検証出力値１０５と新制御ソフト検証出力値１０４を比較し、結果に応じてテスト条件情報を送信部で送信する。

換言すれば、検証管理部は、旧バージョンの制御ソフトウェアを示す旧制御ソフト部１１２と、新バージョンの制御ソフトウェアを示す新制御ソフト部１１３を並行（図１５参照）または並列（図２０参照）に実行する。出力検証部は、旧制御ソフト部１１２の出力と新制御ソフト部１１３の出力が不一致に相当する場合に不一致を示す情報を出力する。具体的には、例えば、出力検証部は、旧制御ソフト部１１２の出力と新制御ソフト部１１３の出力を比較し、それらが不一致の場合に不一致を示す情報を出力する。

本実施の形態では、出力検証部は、旧制御ソフト部１１２の出力と新制御ソフト部１１３の出力が不一致の場合に時系列入力値を外部に出力する出力比較部を含む。

図１５は実施の形態１に係る自動運転ＥＣＵ１１のスケジューリング情報である。実施の形態１ではＣＰＵ－Ａ１０１を、制御処理を実行する制御コアとして用い、ＣＰＵ－Ｂ１０２を、検証処理を実行する検証コアとして用いる。具体的にはＣＰＵ－Ａ１０１で旧制御ソフト部１１１を１００ｍｓ周期で実行する。一方、ＣＰＵ－Ｂ１０２では検証処理を検証内時間に基づいて実行する。換言すれば、出力検証部は、旧制御ソフト部１１１を実行する制御用のＣＰＵ－Ａ１０１（プロセッサ）と別のＣＰＵ－Ｂ１０２（プロセッサ）で検証処理を実行する。

図１５に示すように実施の形態１では旧制御ソフト部１１２と新制御ソフト部１１３を順次実行する。また、実施の形態１の構成では、実時間と検証内時間は一致しない可能性が高い。一致させるには旧制御ソフト部１１１の実行周期内に、旧制御ソフト部１１２と新制御ソフト部１１３の双方の実行を終了させる必要がある。本発明の実施の形態では、実時間と検証内時間を分離しているため、そのような高性能なマイコンでなくても、検証を可能としている。

本実施の形態１によると、時系列入力値は１種類に限らない。例えば２種類以上のセンサ値の時系列データでも良い。またテスト条件に関係すれば、センサ値に限らない。

本実施の形態１によると、時系列入力値は旧制御ソフト部や新制御ソフト部への入力値に限らない。例えば、旧制御ソフト部や新制御ソフト部を分割した中間データであってもよい。

本実施の形態１によると、旧制御ソフト検証出力値や新制御ソフト検証出力値に保存されるデータは、旧制御ソフト部や新制御ソフト部が算出するアクチュエータＥＣＵへの制御指令に限らない。例えば、機械学習ベースの認識処理の結果や判断処理の結果などでも良い。

本実施の形態１によると、検証フラグをONとする条件をメモリに空き領域がなくなった条件としているが（図６、ステップ１１６２：ＮＯ）、これに限らない。例えば、一定時間の間のセンサ値を保存したことを条件としてもよい。またこれに限らない。例えば、手動運転状態や駐車状態などの予め決めた特定状態であることを条件としてもよい。あるいは、予め設定したＣＰＵ負荷以下となったときに検証フラグをONとする条件であってもよい。

本実施の形態１によると、検証フラグをOFFとする条件を、検証内時間が終了時間を超えたときとしているが（図５、ステップ１１５２：ＹＥＳ）、これに限らない。例えば、今後多くの計算リソースを使用する可能性が高い場合には、事前に検証フラグをOFFとすることが考えられる。これには自車がヒアリハット多発地点に近づいた状況であったり、新しいソフトウェアをインストールする状況などであることが考えられるが、これらに限らない。

本実施の形態１によると、旧制御ソフト部と新制御ソフト部の出力結果を比較しているが、これに限らない。例えば、各々の出力結果を予め設定した正解値または基準値と比較し、その比較結果が一致しないときに、クラウドに報告することが考えられる。またこれに限らない。

本実施の形態１によると、比較結果が一致しないときに時系列入力値をクラウドに報告しているがこれに限らない。時系列入力値のすべてでも良いし、一致しなかった時間のものでも良い。さらに、演算結果となる出力値も同時に送付してもよい。またこれらに限らない。クラウドに報告されたデータは新制御ソフト部の再学習や不具合修正に用いられる。

本実施の形態１によると、旧制御ソフト部と新制御ソフト部の２種類の制御ソフトウェアを比較しているが、これに限らない。例えば、旧制御ソフト部が２種類、新制御ソフト部が２種類、またはそれ以上であってもよい。

本実施の形態１によると、時系列テストケース定義部１１７が、検証対象の旧制御ソフト部１１１、１１２や新制御ソフト部１１３に対してテストケースを選定するため、時系列入力値と旧制御ソフト検証入力値と新制御ソフト検証入力値が一致しなくてもよい。

本実施の形態１によると、旧制御ソフト部と新制御ソフト部を交互に実行しているが（図１５）、これに限らない。例えば、最初に旧制御ソフト部を一定時間実行し、その後に検証内時間を巻き戻し、巻き戻した検証内時間に基づいたテストケースで新制御ソフト部を一定時間実行してもよい。また実行順序はこの逆でも良い。

換言すれば、並行に実行するとは、例えば、旧制御ソフト部を一定の範囲の検証内時間で実行した後に新制御ソフト部を一定の範囲の検証内時間で実行する、または新制御ソフト部を一定の範囲の検証内時間で実行した後に旧制御ソフト部を一定の範囲の検証内時間で実行することである。

本実施の形態１では、旧制御ソフト部と新制御ソフト部は独立のメモリ空間となっていることを前提としている。例えば、事前に共有変数を持たないように設計されたスレッドで旧制御ソフト部と新制御ソフト部を実行してもよいし、プロセスで分離して実行してもよいし、コンテナで分離して実行してもよいし、ハイパーバイザで分離して実行しても良い。

本実施の形態１によると、本発明の実施の形態によって空いているＣＰＵを用いて旧制御ソフト部と新制御ソフト部を検証できるため、各々に対して専用のＣＰＵを用意する場合と比較して、低コストで検証を実現できる。

（実施の形態２）
図１６は、本発明の実施の形態２に係るシステムと車両制御装置の構成図を示す。自動運転システム２は、自動運転ＥＣＵ２１の他、実施の形態１と同様のＥＣＵで構成される。自動運転ＥＣＵ２１は旧制御ソフト部２１２、新制御ソフト部２１３、検証管理部２１５の他、実施の形態１と同様の機能で構成される。

以降より、実施の形態２に係る動作フローの詳細を説明する。

図１７は旧制御ソフト部２１２の動作フローである。以下、図１７の各ステップについて説明する。

（図１７：ステップ２１１１）
旧制御ソフト部２１２は、検証管理部２１５からの実行要求イベントを待つ。実行要求イベントが発行された際にはステップ２１１２に進む。

（図１７：ステップ２１１２）
旧制御ソフト部２１２は、入力されたセンサ値に基づいて認識処理・経路計画・制御指令を算出する。旧制御ソフト部２１２は旧制御ソフト入力値１０９から、旧制御ソフト部２１２は旧制御ソフト検証入力値１０７を参照しセンサ値を読み出す。

（図１７：ステップ２１１３）
旧制御ソフト部２１２は、自身が検証で用いられるプログラムか否かを判定し、偽（Ｎ：ＮＯ）である場合にはステップ２１１４に進み、真（Ｙ：ＹＥＳ）である場合にはステップ２１１５に進む。

（図１７：ステップ２１１４）
旧制御ソフト部２１２は、送信部１１９を利用して制御指令をアクチュエータＥＣＵに送信する。

（図１７：ステップ２１１５）
旧制御ソフト部２１２は、検証対象となる計算結果を旧制御ソフト検証出力値１０５に保存する。

（図１７：ステップ２１１６）
旧制御ソフト部２１２は、終了イベントを発行する。

図１８は新制御ソフト部２１３の動作フローである。以下、図１８の各ステップについて説明する。

（図１８：ステップ２１３１）
新制御ソフト部２１３は、検証管理部２１５からの実行要求イベントを待つ。実行要求イベントが発行された際にはステップ２１３２に進む。

（図１８：ステップ２１３２）
新制御ソフト部２１３は入力されたセンサ値に基づいて認識処理・経路計画・制御指令を算出する。

（図１８：ステップ２１３３）
新制御ソフト部２１３は、検証対象となる計算結果を新制御ソフト検証出力値１０４に保存する。

（図１８：ステップ２１３４）
新制御ソフト部２１３は、終了イベントを発行する。

図１９は検証管理部２１５の動作フローである。以下、図１９の各ステップについて説明する。

（図１９：ステップ２１５１）
検証管理部２１５は、検証フラグがＯＮであるか否かを判定し、偽（Ｎ：ＮＯ）である場合には本動作フローを終了する。真（Ｙ：ＹＥＳ）である場合にはステップ２１５２に進む。

（図１９：ステップ２１５２）
検証管理部２１５は、検証内時間が検証終了時間を超過するか否かを判定し、真（Ｙ：ＹＥＳ）である場合にはステップ２１５３に進み、偽（Ｎ：ＮＯ）である場合にはステップ２１５４に進む。検証内時間は車両制御装置起動時に初期化される想定である。

（図１９：ステップ２１５３）
検証管理部２１５は、検証内時間を初期化した後に、検証フラグをＯＦＦにする。

（図１９：ステップ２１５４）
検証管理部２１５は、時系列テストケース定義部１１７を実行し、現在の検証内時間に対応したテストケースを入手する。

（図１９：ステップ２１５５）
検証管理部２１５は、前記テストケースを入力として、検証用の旧制御ソフト部２１２に実行要求イベントを発行する。

（図１９：ステップ２１５６）
検証管理部２１５は、前記テストケースを入力として、検証用の新制御ソフト部２１３に実行要求イベントを発行する。

（図１９：ステップ２１５７）
検証管理部２１５は、旧制御ソフト部２１２と新制御ソフト部２１３から発行される実行終了イベントを待つ。

（図１９：ステップ２１５８）
検証管理部２１５は、旧制御ソフト部２１２と新制御ソフト部２１３の出力を比較するために出力比較部１１８を実行する。

（図１９：ステップ２１５９）
検証管理部２１５は、検証内時間を進め、ステップ２１５２に進む。

このように、検証管理部２１５は、検証期間内の時間を示す検証内時間を管理し、検証内時間に基づいて旧制御ソフト部２１２と新制御ソフト部２１３を実行する。

図２０は実施の形態２に係る自動運転ＥＣＵ２１のスケジューリング情報である。実施の形態２ではＣＰＵ－Ａ１０１を、制御処理を実行する制御コアとして用い、ＣＰＵ－Ｂ１０２とＣＰＵ‐Ｃ１０３を、検証処理を実行する検証コアとして用いる。具体的にはＣＰＵ－Ａ１０１で旧制御ソフト部１１１を１００ｍｓ周期で実行する。一方、ＣＰＵ－Ｂ１０２とＣＰＵ－Ｃ１０３では検証処理を検証内時間に基づいて実行する。

換言すれば、並列に実行するとは、例えば、旧制御ソフト部と新制御ソフト部を互いに異なるプロセッサ（ＣＰＵ－Ｂ１０２とＣＰＵ－Ｃ１０３）に割り当て、同じテストケースを用いて互いに同期して実行することである。

図２０に示すように実施の形態２では旧制御ソフト部２１２をＣＰＵ－Ｃ１０３で、新制御ソフト部２１３をＣＰＵ－Ｂ１０２で実行する。実施の形態２は旧制御ソフト部２１２と新制御ソフト部２１３を並列実行しているため、検証時間が短くなる特徴がある。

本実施の形態２によると、旧制御ソフト部と新制御ソフト部を別のＣＰＵを用いて検証できるため、検証に要する時間を短縮することができる。

（実施の形態３）
図２１は、本発明の実施の形態３に係るシステムと車両制御装置の構成図を示す。自動運転システム３は、自動運転ＥＣＵ３１の他、実施の形態１と同様のＥＣＵで構成される。自動運転ＥＣＵ３１は切替監視部３１０の他、実施の形態１と同様の機能で構成される。

図２２は切替監視部３１０の動作フローである。以下、図２２の各ステップについて説明する。

（図２２：ステップ３１０１）
切替監視部３１０は、自動運転要求があるか否かを判定し、偽（Ｎ：ＮＯ）である場合にはステップ３１０２に進み、真（Ｙ：ＹＥＳ）である場合にはステップ３１０３に進む。自動運転要求は、運転手が自動運転開始ボタンを押下する等のイベントである。

（図２２：ステップ３１０２）
切替監視部３１０は、検証処理許可を出す。すなわち、検証処理を停止させていた場合には、それらの再開処理を実施し、すでに検証処理を実行している場合には継続する。

（図２２：ステップ３１０３）
切替監視部３１０は、現在検証処理を実行中であるか否かを判定する。真（Ｙ：ＹＥＳ）である場合にはステップ３１０４に進み、偽（Ｎ：ＮＯ）である場合にはステップ３１０５に進む。

（図２２：ステップ３１０４）
切替監視部３１０は、現在実行中の検証処理を停止させる。

（図２２：ステップ３１０５）
切替監視部３１０は、旧制御ソフトを実行する。

図２３は実施の形態３に係る自動運転ＥＣＵ３１のスケジューリング情報である。実施の形態３ではすべての処理をＣＰＵ－Ａ１０１で実行する。そして、検証モードで検証処理を行い、自動運転モードでは検証処理を実行しない。検証モードは、例えば、バッテリーの充電中、手動運転中等が該当する。

換言すれば、出力検証部は、旧制御ソフト部が実行中でない時に、空きリソース（時間、ＣＰＵ）を用いて検証処理を実行する。

このようにすることで旧制御ソフト部１０１と、旧制御ソフト部１０２の同時処理を避けることができ、メモリ消費量を抑制することができる。

本実施の形態３によると、空いている旧制御ソフト部と新制御ソフト部を別のＣＰＵを用いて検証できるため、検証に要する時間を短縮することができる。

（実施の形態４）
図２４は実施の形態４に係る自動運転ＥＣＵ１１のスケジューリング情報である。実施の形態４ではすべての処理をＣＰＵ－Ａ１０１で実行する。旧制御ソフト部の空いている時間（例えば、車両の回りに人や車がいないとき）に検証処理を実行する。旧制御ソフト部の処理実行優先度を高くする設定をオペレーティングシステムに行うことで、旧制御ソフト部に影響を与えずに検証処理を実行できる。

なお、本発明は上記した実施の形態に限定されるものではなく、様々な変形例が含まれる。例えば、上述した実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施の形態の構成の一部を他の実施の形態の構成に置き換えることが可能であり、また、ある実施の形態の構成に他の実施の形態の構成を加えることも可能である。また、各実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各構成、機能等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、SSD（Solid State Drive）等の記録装置、または、ICカード、SDカード、DVD等の記録媒体に置くことができる。

なお、本発明の実施の形態は、以下の態様であってもよい。

（１）．旧バージョンの制御ソフトウェアを示す旧制御ソフト部と、新バージョンの制御ソフトウェアを示す新制御ソフト部を並行または並列に実行する検証管理部と、複数の前記制御ソフトのそれぞれの出力を比較し、不一致時には不一致を示す情報を出力する出力検証部と、を備えることを特徴とする車両制御装置。
（２）．自動運転などの制御アプリケーション処理が実行されていない空き時間資源で検証処理を実行することを特徴とする（１）に記載の車両制御装置
（３）．前記検証管理部は、検証内の実行時間（検証内時間）を管理し、前記検証内時間に基づいて複数の前記制御ソフトを実行することを特徴とする（１）に記載の車両制御装置。

（４）．走行中の車両のセンサによる入力値を時系列に時系列入力値に保存する時系列テスト入力保存部と、前記制御ソフトの前記検証の実行時間と検証対象のソフトウェアに応じて、テストケースを選定する時系列テストケース定義部と、を備えることを特徴とする（１）に記載の車両制御装置。

（５）．前記出力が不一致を示す情報である際には、前記時系列入力値を外部に出力する出力比較部と、を備えることを特徴とする（１）に記載の車両制御装置。
（６）．前記の空き時間資源で検証処理を実行するとは、自動運転などの制御アプリケーション処理とは別のＣＰＵで検証処理を実行することを示す（２）に記載の車両制御装置。

（７）．前記の並行に実行するとは、旧制御ソフト部を一定の検証内時間で実行した後に新制御ソフト部を一定の検証内時間で実行する、またはその逆を実施することを示す（１）に記載の車両制御装置。

（８）．前記の並列に実行するとは、旧制御ソフト部と新制御ソフト部を別のCPUに割り当て、同じテスト入力データを用いて互いに同期して実行することを特徴とする（１）に記載の車両制御装置。

（９）．自動運転などの制御アプリケーション処理よりも低い優先度で検証処理を実行することを特徴とする前記検証管理部を備えることを特徴とする（２）に記載の車両制御装置。

（１０）．旧制御ソフトから新制御ソフトに実行を切り替え、またはその逆に実行を切り替える際に、検証内時間に際が生じている場合には、前記検証内時間を戻し、戻した前記検証内時間時間に応じてテスト入力データを変更することを特徴とする（１）に記載の車両制御装置。

（１１）．前記出力比較部は前記旧制御ソフト部と前記新制御ソフト部の出力を比較する、または、出力を正解値と比較し、その結果を比較することを特徴とする（１）に記載の車両制御装置。

（１２）．前記正解値とは、一定値または範囲で定義された値であることを特徴とする（１）に記載の車両制御装置。

（１３）．前記正解値とは、非安全状態に到達する可能性のある条件であることを特徴とする（１）に記載の車両制御装置。

（１４）．前記の空き時間資源として、手動運転モードや充電モード、前方車両追従モード、駐車モードであることを特徴とする（１）に記載の車両制御装置。

換言すれば、車両制御装置は、オンボードでセンサ情報を一定時間の間、時系列に保存する時系列テスト入力保存部と、保存した時系列センサ情報からテストケースを生成する時系列テストケース定義部と、実時間とは異なる検証内時間に基づいて旧制御ソフトと新制御ソフトを前記テストケースで実行する検証管理部と、出力結果を比較することで精度に影響を与える実行条件を特定する出力比較部と、で構成される。

この車両制御装置によれば、車両を制御する自動運転ソフトウェア（旧制御ソフト）の動作を阻害せずに、次のバージョンの新制御ソフトの検証を可能とする。旧制御ソフトを実行していない空きリソース（時間、CPU）を用いて検証するため、コストを抑制しつつ、自動運転システムを検証できる。

１…自動運転システム
２…自動運転システム
３…自動運転システム
１５…クラウド
１０１…旧制御ソフト部
１０２…旧制御ソフト部
１０４…新制御ソフト検証出力値
１０５…旧制御ソフト検証出力値
１０６…新制御ソフト検証入力値
１０７…旧制御ソフト検証入力値
１０８…時系列入力値
１０９…旧制御ソフト入力値
１１１…旧制御ソフト部
１１２…旧制御ソフト部
１１３…新制御ソフト部
１１４…センサ値受信部
１１５…検証管理部
１１６…時系列テスト入力保存部
１１７…時系列テストケース定義部
１１８…出力比較部
１１９…送信部
１２１…センシング部
１３１…転送処理部
１４１…制御処理部
１５１…情報保存部
２１２…旧制御ソフト部
２１３…新制御ソフト部
２１５…検証管理部
３１０…切替監視部

Claims

旧バージョンの制御ソフトウェアを示す旧制御ソフト部と、新バージョンの制御ソフトウェアを示す新制御ソフト部を並行または並列に実行する検証管理部と、
前記旧制御ソフト部の出力と前記新制御ソフト部の出力が不一致に相当する場合に不一致を示す情報を出力する出力検証部と、
を備えることを特徴とする車両制御装置。
請求項１に記載の車両制御装置であって、
前記出力検証部は、
前記旧制御ソフト部が実行中でない時に、空きリソースを用いて検証処理を実行する
ことを特徴とする車両制御装置。
請求項１に記載の車両制御装置であって、
前記検証管理部は、
検証期間内の時間を示す検証内時間を管理し、前記検証内時間に基づいて前記旧制御ソフト部と前記新制御ソフト部を実行する
ことを特徴とする車両制御装置。
請求項３に記載の車両制御装置であって、
走行中の車両のセンサによる時系列の入力値を示す時系列入力値を保存する時系列テスト入力保存部と、
前記時系列入力値から前記検証内時間に対応する入力値を含むテストケースを選定する時系列テストケース定義部と、
を備えることを特徴とする車両制御装置。
請求項４に記載の車両制御装置であって、
前記出力検証部は、
前記旧制御ソフト部の出力と前記新制御ソフト部の出力が不一致に相当する場合に前記テストケースを外部に出力する出力比較部を含む
ことを特徴とする車両制御装置。
請求項２に記載の車両制御装置であって、
前記出力検証部は、
前記旧制御ソフト部を実行する制御用のプロセッサと別のプロセッサで検証処理を実行する
ことを特徴とする車両制御装置。
請求項１に記載の車両制御装置であって、
並行に実行するとは、
前記旧制御ソフト部を一定の範囲の検証内時間で実行した後に前記新制御ソフト部を一定の範囲の検証内時間で実行する、または
前記新制御ソフト部を一定の範囲の検証内時間で実行した後に前記旧制御ソフト部を一定の範囲の検証内時間で実行することである
ことを特徴とする車両制御装置。
請求項１に記載の車両制御装置であって、
前記並列に実行するとは、
前記旧制御ソフト部と前記新制御ソフト部を互いに異なるプロセッサに割り当て、同じテストケースを用いて互いに同期して実行することである
ことを特徴とする車両制御装置。
請求項１に記載の車両制御装置であって、
前記出力検証部は、
前記旧制御ソフト部の出力と前記新制御ソフト部の出力を比較し、それらが不一致の場合に不一致を示す情報を出力する
ことを特徴とする車両制御装置。
請求項１に記載の車両制御装置であって、
前記出力検証部は、
前記旧制御ソフト部の出力と前記新制御ソフト部の出力をそれぞれ正解値と比較し、それぞれの比較結果のうち少なくとも一方が正解値と異なる場合に不一致を示す情報を出力する
ことを特徴とする車両制御装置。