JP2021195029A - 車両制御システム - Google Patents

Abstract

【課題】車載電気電子システムのリソースを有効に活用して車両を安全に走行させることができる車両制御システムを提供する。【解決手段】車両制御システムＳ１１１は、要求生成部ＲＧと、可用性取得部ＡＡと、優先度生成部ＰＧと、実行管理部ＥＭと、を備える。要求生成部ＲＧは、車両を走行シナリオに従って走行させるためのタスクの要求を生成する。可用性取得部ＡＡは、車載電気電子システムにおけるリソースの可用性を取得する。優先度生成部ＰＧは、タスクの要求とリソースの可用性とに基づいてタスクの優先度を生成する。実行管理部ＥＭは、優先度に従ってタスクを実行する。【選択図】図９

Description

本開示は、車両制御システムに関する。

従来から、車両のセンサからセンサデータを受信するコンピュータシステムが知られている（下記特許文献１を参照）。特許文献１に記載されたコンピュータシステムは、車両の一以上のセンサからセンサデータを受信し、受信したセンサデータに基づいて車両に関連する指標を測定し、その指標に基づいて車両の通信網における伝送サイクルの長さを決定する。この伝送サイクルは、通信網のそれぞれの第１ノードからデータを伝送するための一以上の予定された期間を含む。コンピュータシステムは、少なくとも部分的に、伝送サイクルの長さ基づいて、伝送サイクルの複数のインスタンスにおける予定された期間のそれぞれの発生頻度を調整するために、車両の通信網を構成する（同文献、要約等を参照）。

米国特許出願公開第２０１９／０３２２２８８号明細書

特許文献１に記載されたコンピュータシステムは、主に、センサデータの伝送レイテンシと、ネットワークの可用性との間のルールベースのマッチングに焦点を当てている。車両の自動運転システム（ＡＤＳ）や先進運転支援システム（ＡＤＡＳ）における安全上重大な走行シナリオでは、安全な最小リスク操作を実行するための特定のセンサデータを要求する複数のインスタンスが存在する可能性がある。このような走行シナリオにおいて、ネットワーク・リソースの不足によるセンサタスクの達成または実行の遅延は、車両の危険な状態につながりかねない。

本開示は、車載電気電子システムのリソースを有効に活用して車両を安全に走行させることができる車両制御システムを提供する。

本開示の一態様は、車両を走行シナリオに従って走行させるためのタスクの要求を生成する要求生成部と、車載電気電子システムにおけるリソースの可用性を取得する可用性取得部と、前記タスクの要求と前記リソースの可用性とに基づいて前記タスクの優先度を生成する優先度生成部と、前記優先度に従って前記タスクを実行する実行管理部と、を備えることを特徴とする車両制御システムである。

本開示によれば、車載電気電子システムのリソースを有効に活用して車両を安全に走行させることができる車両制御システムを提供することができる。

本開示の車両制御システムの一実施形態を示すブロック図。 図１のセンサシステムに含まれる外界センサの一例を示す平面図。 図１の車載電気電子システムの構成例を示すブロック図。 図１の車載電気電子システムの構成例を示すブロック図。 図３に示す車載電気電子システムのより詳細なブロック図。 図４に示す車載電気電子システムのより詳細なブロック図。 図３から図６に示す車載電気電子システムが実行するタスクの一例。 図５および図６の実行管理部の動作の一例を示すフロー図。 図５および図６の車両制御システムのブロック図。 図９に示す車両制御システムの処理の流れの一例を示すフロー図。 車両に搭載されたカメラの画像の一例。 タスク要求とリソースの可用性とレイテンシとの関係の一例を示す表。 図９の車両制御システムの処理の流れの一例を示すフロー図。 車両の走行シナリオの一例を示す平面図。 車載電気電子システムによるアプリケーションの実行順序を示すフロー図。

以下、図面を参照して本開示に係る車両制御システムの実施形態を説明する。

図１は、本開示の車両制御システムの一実施形態を示すブロック図である。本実施形態の車両制御システムＳ１１１は、たとえば、車載電気電子システム（以下、「車載ＥＥシステム」と略称する。）Ｓ１００に含まれる。車載ＥＥシステムＳ１００は、たとえば、自動車などの車両に搭載され、車両の自動運転システム（ＡＤＳ）または先進運転支援システム（ＡＤＡＳ）を構成する。図１に示す車載ＥＥシステムＳ１００の各構成要素または各モジュールは、たとえば、ハードウェア、ソフトウェア、ネットワーク、ワイヤ・ハーネスなどによって構成されている。

図１に示す車載ＥＥシステムＳ１００は、たとえば、車両制御システムＳ１１１の他に、センサシステムＳ１０１、外界認識システムＳ１０２、計画システムＳ１０３、無線通信システムＳ１０４、物理ネットワークＳ１０５、動作システムＳ１０６、を含む。また、車載ＥＥシステムＳ１００は、たとえば、車体制御システムＳ１０７、インフォテインメント・システムＳ１０８、ヒューマン・マシン・インタフェース（ＨＭＩ）システムＳ１０９、運転者監視システムＳ１１０、Ｖ２ＸシステムＳ１１２を含む。さらに、車載ＥＥシステムＳ１００は、たとえば、運転者意図認識システムＳ１１３、車両診断・故障監視システムＳ１１４、駆動系システムＳ１１５を含む。なお、車載ＥＥシステムＳ１００は、図１に示す構成要素の一部を省略してもよく、他の構成要素を含んでもよい。

図１に示すように、車載ＥＥシステムＳ１００は、たとえば、個々の構成要素間の通信を可能にする無線通信システムＳ１０４および物理ネットワークＳ１０５を備えている。また、車載ＥＥシステムＳ１００は、たとえば、高い冗長性とリソースの可用性を提供して、システムの信頼性を向上させる一以上の物理ネットワークＳ１０５または無線ネットワークを備えてもよい。センサシステムＳ１０１は、たとえば、外界センサ、車両センサ、位置測定センサなどを含む。車両制御システムＳ１１１は、たとえば、車両のステアリングホイール、スロットル、ブレーキ、ギアシフトなどを操作するためのアクチュエータを含む。

図２は、図１のセンサシステムＳ１０１に含まれる外界センサＥＳの一例を示す平面図である。外界センサＥＳは、たとえば、車載ＥＥシステムＳ１００が搭載された車両ＳＶの前方に測定範囲ＲＭ１，ＲＭ２を有する長距離レーダＥＳ１および赤外線レーザセンサＥＳ２と、車両ＳＶの前後左右に測定範囲ＲＭ３を有する複数のカメラＥＳ３とを含む。また、外界センサＥＳは、たとえば、車両ＳＶの前後に測定範囲ＲＭ４を有する複数の短距離レーダＥＳ４と、車両ＳＶの前後に測定範囲ＲＭ５を有する複数のＬｉＤＡＲ（ＥＳ５）とを含む。

長距離レーダＥＳ１の測定距離は、たとえば、１[ｍ]から２８０[ｍ]程度であり、赤外線レーザセンサＥＳ２の測定距離は、たとえば、０．２[ｍ]から１２０[ｍ]程度であり、カメラＥＳ３の測定距離は、たとえば、０．２[ｍ]から１００[ｍ]程度である。また、短距離レーダＥＳ４の測定距離は、たとえば、０．２[ｍ]から６０[ｍ]程度であり、ＬＩＤＡＲ（ＥＳ５）の測定距離は、たとえば、０．２[ｍ]から８０[ｍ]程度である。

図３および図４は、それぞれ、図１の車載ＥＥシステムＳ１００の構成例を示すブロック図である。より詳細には、図３は、ドメイン・アーキテクチャを採用した車載ＥＥシステムＳ１００の一例を示すブロック図であり、図４は、ゾーン・アーキテクチャを採用した車載ＥＥシステムＳ１００の一例を示すブロック図である。

図３に示すドメイン・アーキテクチャを採用した車載ＥＥシステムＳ１００は、たとえば、複数の電子制御ユニット（ＥＣＵ）を備えている。より具体的には、車載ＥＥシステムＳ１００は、たとえば、ゲートウェイＥＣＵと、このゲートウェイＥＣＵを介して相互に接続された複数のドメインＥＣＵとを備えている。複数のドメインＥＣＵは、たとえば、駆動系ＥＣＵ、車体／快適性ＥＣＵ、自動運転／先進運転支援（ＡＤ／ＡＤＡ）ＥＣＵ、インフォテインメントＥＣＵ、接続性ＥＣＵなどを含む。各ドメインＥＣＵは、たとえば、さらに複数のＥＣＵを備えている。

図４に示すゾーン・アーキテクチャを採用した車載ＥＥシステムＳ１００は、たとえば、エンジンルームやトランクルームなど、車両ＳＶのゾーンごと配置された複数のゾーン・ゲートウェイＥＣＵを備える。各々のゾーン・ゲートウェイＥＣＵに対し、たとえば、駆動系、車体／快適性、ＡＤ／ＡＤＡ、インフォテインメント、接続性など、複数のドメインが構築される。複数のゾーン・ゲートウェイＥＣＵは、ネットワーク伝送経路を介して相互に接続されるとともに、複数のネットワーク伝送経路を介して中央演算ＥＣＵに接続されている。すなわち、車載ＥＥシステムは、各ゾーン・ゲートウェイＥＣＵと中央演算ＥＣＵとを接続する冗長な複数のネットワーク伝送経路を有している。

図５は、図３に示すドメイン・アーキテクチャを採用した車載ＥＥシステムのより詳細なブロック図である。なお、図５では、インフォテインメントＥＣＵと接続性ＥＵＣの図示を省略している。たとえば、駆動系ＥＣＵ、車体／快適性ＥＣＵ、ＡＤ／ＡＤＡ・ＥＣＵなどの各ドメインＥＣＵは、それぞれのドメインに求められる判断を担う。ゲートウェイＥＣＵは、ドメインＥＣＵ間のネットワーク通信を提供する。また、各ドメインＥＣＵは、たとえば、検知および検出を担う複数のセンサＥＣＵと、作動・動作を担う複数のアクチュエータＥＣＵとを備えている。

より具体的には、図５に示すＡＤ／ＡＤＡ・ＥＣＵは、たとえば、図２に示す外界センサＥＳを含む複数のセンサに接続された複数のセンサＥＣＵを有することができる。また、車体／快適性ＥＣＵは、たとえば、ステアリングやブレーキなどのアクチュエータに接続された複数のアクチュエータＥＣＵと、操舵角センサやブレーキ踏力センサなどに接続された複数のセンサＥＣＵを有することができる。駆動系ＥＣＵも同様に、スロットルのアクチュエータに接続されたＥＣＵを含む複数のアクチュエータＥＣＵと、複数のセンサＥＣＵを有することができる。

また、図５に示すゲートウェイＥＣＵと各ドメインＥＣＵは、それぞれ、オペレーティングシステム（ＯＳ）と、種々のアプリケーションと、実行管理部ＥＭと、可用性取得部ＡＡとを有している。より具体的には、ゲートウェイＥＣＵと各ドメインＥＣＵは、それぞれ、記憶装置と中央処理装置を含む。ＯＳ、アプリケーション、実行管理部ＥＭ、および可用性取得部ＡＡは、たとえば、各ＥＣＵの記憶装置に記憶されて中央処理装置によって実行されるソフトウェアやプログラムである。

図５に示すゲートウェイＥＣＵと各ドメインＥＣＵにおいて、実行管理部ＥＭは、たとえば、実行中のタスクを判定して可用性取得部ＡＡへ出力し、可用性取得部ＡＡは、実行管理部ＥＭの出力である実行中のタスクに基づいてリソースの可用性を取得する。ここで、可用性取得部ＡＡが取得するリソースの可用性は、たとえば、各ＥＣＵにおける演算リソースの可用性と、ネットワーク帯域幅などの通信リソースの可用性とを含む。

図５に示すゲートウェイＥＣＵの可用性取得部ＡＡは、たとえば、取得したリソースの可用性を各ドメインＥＣＵへ伝送する。また、各ドメインＥＣＵの可用性取得部ＡＡは、たとえば、取得したリソースの可用性をゲートウェイＥＣＵへ伝送する。また、ＡＤ／ＡＤＡ・ＥＣＵは、たとえば、要求生成部ＲＧと、可用性取得部ＡＡと、優先度生成部ＰＧとを有し、本実施形態の車両制御システムＳ１１１として機能する。要求生成部ＲＧと優先度生成部ＰＧは、たとえば、ＡＤ／ＡＤＡ・ＥＣＵの記憶装置に記憶されて中央処理装置によって実行されるソフトウェアやプログラムである。

図６は、図４に示すゾーン・アーキテクチャを採用した車載ＥＥシステムＳ１００のより詳細なブロック図である。各々のゾーン・ゲートウェイＥＣＵは、たとえば、ＯＳと、アクチュエータ状態取得部と、アクチュエータ指令生成部と、センサデータ取得部と、センサデータ処理部と、実行管理部ＥＭと、可用性取得部ＡＡと、その他の複数の処理部とを有している。これらゾーン・ゲートウェイＥＣＵのＯＳおよび各部は、たとえば、記憶装置に記憶されて中央処理装置によって実行されるソフトウェアやプログラムである。ゾーン・ゲートウェイＥＣＵのＯＳを除く各部は、同一のアプリケーションまたは異なるアプリケーションの一部であってもよい。車両ＳＶのセンサおよびアクチュエータは、たとえば、ゾーン・ゲートウェイ・ＥＣＵに接続されている。

図６に示すように、中央演算ＥＣＵは、たとえば、ＯＳと、計画処理部と、動作処理部と、認識処理部と、走行シナリオ生成部と、複数のアプリケーションと、実行管理部ＥＭと、要求生成部ＲＧと、可用性取得部ＡＡと、優先度生成部ＰＧとを備えている。これら中央演算ＥＣＵのＯＳおよび各部は、たとえば、記憶装置に記憶されて中央処理装置によって実行されるソフトウェアやプログラムである。たとえば、中央演算ＥＣＵのＯＳを除く各部によって、本実施形態の車両制御システムＳ１１１を構成することができる。

図７は、車載ＥＥシステムＳ１００が実行するタスクの一例を示す。車載ＥＥシステムＳ１００は、前述の構成により、検知タスク、動作タスク、推定タスクまたは認識タスク、診断タスク、計画タスク、および監視タスクなどの複数のタスクを実行することで、車両の自動運転や高度運転支援を実現する。各タスクは、たとえば、タスクＩＤ、実行周期または期間、実行時間、開始時間、期限または終了時間、および優先度などの属性を有する。なお、本実施形態の説明は、「タスク」を「サービス」または「タスク／サービス」に置き換えても成立する。

検知タスクは、たとえば、外界認識タスクを含む。外界認識タスクは、車両制御システムが車両の安全なナビゲーションを行うための走行シナリオに基づく外界情報の要求に応じて種々の外界センサＥＳを使用して、車両ＳＶの周囲の物体を認識するタスクである。検知タスクは、たとえば、外界センサＥＳの作動や、外界センサＥＳの検知データの取得などを担ういくつかのタスクをさらに有する。

同様に、動作タスク、推定タスクまたは認識タスク、診断タスク、計画タスク、および監視タスクは、たとえば、車載ＥＥシステムの各構成要素または各モジュールの制御と統合を担ういくつかのサブタスクに分解することができる。各タスクの属性に基づいて各タスクを監視することで、タスクのスケジューリングの状況、実行の状況、終了の状況など、ランタイムでのタスクの監視を実現することができる。

図８は、図５および図６の実行管理部ＥＭの動作を示すフロー図である。実行管理部ＥＭは、各ＥＣＵにおけるリソースの配分とタスクのスケジューリングを担う。これにより、ランタイムでのリソースの可用性と状態の監視を行うことができる。車両制御システムＳ１１１を構成するモジュール／アプリケーションは、それぞれ、実行管理部ＥＭを備えてもよい。モジュール／アプリケーションのバイナリは、たとえば、いくつかのプロセスを含む。実行管理部ＥＭは、たとえば、各プロセスの他のプロセスに対する従属関係を規定する。

図８に示すように、実行管理部ＥＭは、たとえば、要求されるリソースのアプリケーション（プロセス）への配分、ならびに、プロセスのスケジューリング、実行処理、終了処理、および、終了後のリソースの解放を担う。図８の上部に示すフローにおいて、遊休状態は、アプリケーションが実行される前の状態である。実行管理部ＥＭがアプリケーションを実行して起動すると、プロセスの生成とリソースの配分、すなわちスケジューリングが行われる。具体的には、図８の左下のフローに示すように、ＯＳを起動して実行管理部ＥＭを起動すると、実行管理部ＥＭは、アプリケーションの従属関係とリソースの要求を確認し、アプリケーションにリソースを配分する。これにより、配分されたリソースと空きリソースの知識ベースが作成される。

さらに、図８の上部のフローに示すように、プロセスの実行処理が行われる。ここで、図８の左下のフローに示すように、実行管理部ＥＭは、リソースの配分後に、インスタンスの作成を行う。より具体的には、実行管理部ＥＭは、当初の順序またはスケジューリングされた順序に基づいて、アプリケーションの実行可能なプロセスのインスタンスを作成する。これにより、配分されたリソースと空きリソースの知識ベースに基づいて、データ伝送ネットワーク・リソースが利用される。以上のように、ランタイムの演算リソースおよびネットワーク・リソースの可用性および状態へのアクセスが行われる。

以下、本実施形態の車両制御システムＳ１１１の動作の一例を、図９から図１２を参照して説明する。図９は、本実施形態の車両制御システムＳ１１１のブロック図である。図１０は、図９に示す車両制御システムＳ１１１の処理の流れを示すフロー図である。図１１は、車両ＳＶに搭載されたカメラＥＳ３の画像の一例である。

本実施形態の車両制御システムＳ１１１は、たとえば、図５、図６および図９に示すように、少なくとも、要求生成部ＲＧと、可用性取得部ＡＡと、優先度生成部ＰＧと、実行管理部ＥＭと、を備え、車載ＥＥシステムＳ１００の一部を構成する。車両制御システムＳ１１１が図１０に示す処理を開始する前に、車載ＥＥシステムＳ１００は、走行シナリオＤＳを生成する。車載ＥＥシステムＳ１００は、たとえば、図１に示すセンサシステムＳ１０１、外界認識システムＳ１０２、および計画システムＳ１０３、もしくは、図５、図６に示す走行シナリオ生成部によって、以下のような手順で走行シナリオＤＳを生成する。

車載ＥＥシステムＳ１００は、たとえば、図１１に示すカメラＥＳ３の画像データなど、外界センサＥＳによって取得されたセンサデータに基づいて、車両ＳＶの周囲の他の車両、障害物、道路、道路標示などを含む外部環境の認識結果を取得する。車載ＥＥシステムＳ１００は、たとえば、外部環境の認識結果に基づいて、車両ＳＶの走行シナリオＤＳを生成する。走行シナリオＤＳは、たとえば、所定の速度での直進、先行車両との車間距離を維持した追従走行、先行車両の追い越し、障害物の回避、交差点の右左折、信号や道路標示による減速や停止などを含む。

車両制御システムＳ１１１が図１０に示す処理フローを開始すると、要求生成部ＲＧは、車両ＳＶを走行シナリオＤＳに従って走行させるためのタスク要求を生成する処理Ｐ１１を実行する。タスク要求は、たとえば、図７に示す検知タスク、推定タスク、計画タスク、動作タスク、診断タスク、監視タスクなどの各種のタスクにおける要求を含む。次いで、優先度生成部ＰＧは、たとえば、タスク要求の理想的な優先度要求を生成する処理Ｐ１２を実行する。

また、たとえば、要求生成部ＲＧおよび優先度生成部ＰＧによるタスク要求および優先度要求を生成する処理Ｐ１１，Ｐ１２と並行して、可用性取得部ＡＡは、車載ＥＥシステムＳ１００のリソースの可用性を取得する処理Ｐ１３を実行する。ここで、車載ＥＥシステムＳ１００のリソースは、車載ＥＥシステムＳ１００の演算リソースＡＲの可用性と、車載ＥＥシステムＳ１００のネットワーク帯域幅などの通信リソースＣＲの可用性とを含む。より具体的には、可用性取得部ＡＡは、たとえば、車載ＥＥシステムＳ１００の演算リソースＡＲの状態と通信リソースＣＲの状態に基づいて、演算リソースＡＲの可用性と通信リソースＣＲの可用性を算出する。

図１２は、タスク要求と、リソースの可用性と、レイテンシとの関係の一例を示す表である。図１２の表は、たとえば、通信リソースＣＲの可用性としてのネットワーク帯域幅に基づくデータ速度が２５［Ｇｂ／ｓ］である場合、カメラＥＳ３とＬｉＤＡＲ（ＥＳ５）からデータを取得するタスク要求のレイテンシは、それぞれ１０［ｍｓ］と１［ｍｓ］であることを示している。

しかし、通信リソースＣＲの可用性が低下して、データ速度が５［Ｇｂ／ｓ］に低下すると、上記データを取得するタスク要求のレイテンシは、それぞれ４５［ｍｓ］と２［ｍｓ］に増加する。また、図１２の表は、たとえば、長距離レーダＥＳ１を含むレーダからのデータ取得など、他のタスク要求のレイテンシは、カメラＥＳ３やＬｉＤＡＲ（ＥＳ５）に関するタスク要求のレイテンシと比較して、無視できる程度に小さいことを示している。そのため、レーダのセンサデータを使用して、カメラＥＳ３のセンサデータをフィルタリングおよびサンプリングすることで、通信リソースの要求を低減することができる。

優先度生成部ＰＧは、たとえば、車載ＥＥシステムＳ１００のリソースすなわち演算リソースＡＲおよび通信リソースＣＲの可用性と、各種のタスク要求とのマッチングに基づいて、図１０に示す優先度要求を再計算する処理Ｐ１４を実行する。また、優先度生成部ＰＧは、たとえば、演算リソースＡＲの可用性と、ネットワーク帯域幅などの通信リソースＣＲの可用性とに基づいて、タスク要求のレイテンシを算出する。優先度生成部ＰＧは、たとえば、必要なリソースがより少ないタスク要求により高い優先度を付与して、先にスケジューリングする。優先度生成部ＰＧの計算結果は、たとえば、より多くのリソースを必要とするタスク要求のフィルタリングに用いることができる。

次に、実行管理部ＥＭは、たとえば、優先度生成部ＰＧによって生成されたタスク要求の優先度とレイテンシとに基づいて、タスク要求の実行可否を判定する処理Ｐ１５を実行する。実行管理部ＥＭは、タスク要求が実行可能（ＹＥＳ）と判定すると、優先度に従ってタスクを実行する処理Ｐ１６を行う。実行管理部ＥＭは、たとえば、車両制御システムＳ１１１の状態を確認して、すべてのタスクが実行されていることを確認する。一方、実行管理部ＥＭは、タスク要求が実行不可（ＮＯ）と判定すると、最小リスク操作を行う処理Ｐ１７を実行する。

次に、本実施形態の車両制御システムＳ１１１の他の動作の一例を、図１３および図１４を参照して説明する。図１３は、図９の車両制御システムＳ１１１の処理の流れの一例を示すフロー図である。図１４は、車両ＳＶの走行シナリオＤＳの一例を示す平面図である。

車両制御システムＳ１１１は、たとえば、図１３に示す処理フローを開始すると、まず、直前の時刻ｔ−１において選択中の車両ＳＶの走行シナリオＤＳを取得する処理Ｐ２１を実行する。次に、車両制御システムＳ１１１は、現在時刻ｔにおいて選択可能な車両ＳＶの走行シナリオＤＳと、各々の走行シナリオＤＳの優先度とを取得する処理Ｐ２２を実行する。車両制御システムＳ１１１は、たとえば、安全性や快適性などの判断基準に基づいて、各々の走行シナリオＤＳの優先度を決定する。

図１４に示すように、車両ＳＶは、たとえば、三車線の直線道路の中央車線を走行し、前方に複数の他の車両ＯＶが走行し、後方にも複数の他の車両ＯＶが走行している。車両制御システムＳ１１１は、処理Ｐ２２において、たとえば、外界センサＥＳを含むセンサシステムＳ１０１の検知結果に基づいて、車両ＳＶの同一車線内でのアダプティブ・クルーズ・コントロール（ＡＣＣ）または停車、左車線への車線変更、右車線への車線変更など、選択可能な複数の走行シナリオＤＳを取得する。

次に、車両制御システムＳ１１１は、たとえば、処理Ｐ２２で取得された選択可能な走行シナリオＤＳの各々について、タスク要求のリストを生成する処理Ｐ２３を実行する。ここで、タスク要求は、たとえば、図７に示すような各々のタスクが必要とする演算リソースや通信リソースの大きさすなわちリソース要求を含む。次に、車両制御システムＳ１１１は、たとえば、図３から図６に示すような車載ＥＥシステムＳ１００の演算リソースや通信リソースなどのリソースの可用性を取得する処理Ｐ２４を実行する。

次に、車両制御システムＳ１１１は、前の処理Ｐ２３で生成されたタスク要求と、前の処理Ｐ２４で取得されたリソースの可用性とをマッチングする処理Ｐ２５を実行する。次に、車両制御システムＳ１１１は、前の処理Ｐ２５のマッチングの結果に基づいて、リソースの可用性がタスク要求を満足するか否かを判定する処理Ｐ２６を実行する。

処理Ｐ２６において、リソースの可用性が、最も優先度の高い走行シナリオＤＳのタスク要求を満足する（ＹＥＳ）と判定された場合には、その走行シナリオＤＳに基づいて車両ＳＶを制御するためのタスクを実行する処理Ｐ２７を行う。一方、処理Ｐ２６において、リソースの可用性が、最も優先度の高い走行シナリオＤＳの最も優先度の高いタスク要求を満足しない（ＮＯ）と判定された場合には、リソースの可用性を満足するようにタスク要求の優先度を生成する処理Ｐ２８を実行して、処理Ｐ２５へ戻る。

なお、処理Ｐ２８においてタスク要求の優先度を生成した後、処理Ｐ２５、処理Ｐ２６を経て、再度、処理Ｐ２８が実行される場合が考えられる。この場合、車両制御システムＳ１１１は、前の処理Ｐ２２で取得した最も優先度が高い走行シナリオＤＳを、次に優先度の高い走行シナリオＤＳに変更することができる。これにより、リソースの可用性を満足する走行シナリオＤＳを選択することが可能になる。

図１５は、所与の走行シナリオＤＳにおいて車両ＳＶを安全にナビゲートするために、車載ＥＥシステムＳ１００によって実行されるいくつかのアプリケーションの順序の一例を説明するブロック図である。車載ＥＥシステムＳ１００は、まず、車両ＳＶの現在位置を取得して、グローバルマップにおける自車両の場所を特定するタスクＴ１を実行する。次に、車載ＥＥシステムＳ１００は、車両ＳＶに搭載されたマップを用い、グローバルマップ上の車両ＳＶの位置に基づいて、車両ＳＶをナビゲートすべき道路トポロジを導出するタスクＴ２を実行する。

次に、車載ＥＥシステムＳ１００は、走行シナリオＤＳの進展を予測するために、走行シナリオＤＳに関する情報を収集するタスクＴ３を実行する。これにより、特定された車両ＳＶの位置の誤差が、要求される誤差の範囲内であれば、車載ＥＥシステムＳ１００は、位置を特定するタスクＴ１の優先度を低下させ、外界認識を行うタスクＴ３に重点を置くことができる。この外界認識を行うタスクＴ３において、車載ＥＥシステムＳ１００は、カメラＥＳ３、ＬｉＤＡＲ（ＥＳ５）、長距離レーダＥＳ１などのいくつかの外界センサＥＳを使用することができる。

外界センサＥＳを用いて他の車両などを検知する外界認識タスクは、概して相補的タスクである。そのため、車載ＥＥシステムＳ１００は、レーダで検知した他の車両に対応するカメラＥＳ３のセンサデータのフィルタリングに、長距離レーダＥＳ１によって検知した対象物情報を使用することができる。このような工程を用いることで、カメラＥＳ３のセンサデータを取得するタスクによるネットワーク帯域幅の要求を減少させることができる。次に、車載ＥＥシステムＳ１００は、認識した対象物のクラスタリングと境界ボックスを生成するタスクＴ４と、画像パッチ・トリミングのタスクＴ５と、決定および伝送のタスクＴ６とを実行する。

以下、従来技術との対比に基づいて本実施形態の車両制御システムＳ１１１の作用を説明する。

高度自動運転車両に対する需要の背景にある最も有望な理由の一つは、衝突のリスクを予測して車両の挙動を安全な状態に戻すように変更する高度自動運転車両の宣伝された機能である。しかしながら、運転ミスを最小化することを目的として、人を運転の意思決定プロセスから除外する提案は、高度な自動運転車両を機械監視システムにする。そのため、高度自動運転車両が社会に受け入れられるためには、信頼することができ、かつ、人が監視するＡＤＳ／ＡＤＡＳの特徴を備えた車両よりも安全でなくてはならない。

特許文献１に記載されたシステムは、所与の走行シナリオにおいて車両を自動的にナビゲートすることができるＡＤＳ／ＡＤＡＳを備える車両を説明している。特許文献１によれば、ＡＤＳ／ＡＤＡＳは、高性能計算ユニットと安全計算ユニットの二つのユニットを備える。両方のユニットは、専用のバス監視部を有するセンサと、それらのユニットとセンサとのインタフェースとしての二つのスイッチと、に接続されている。両方のスイッチは、各々のセンサのバス監視部に接続され、上記計算ユニットへのセンサデータ伝送要求のための複数の冗長性を提供している。

計算システムは、伝送サイクルの多重インスタンスにおける計画された時間周期のそれぞれの発生頻度を調整するために、少なくとも部分的に伝送サイクルの長さに基づいて車両の通信ネットワークを構成する。計算システムは、ネットワーク帯域幅およびセンサデータ伝送遅延要求に基づいてセンサデータ伝送タスクを決定する。

しかしながら、特許文献１は、センサデータ伝送遅延とネットワーク可用性との間のルール・ベース・マッチングに主に焦点を当てている。危機的な走行シナリオの場合、最小リスク操作を実行ためにセンサデータ要求の多重インスタンスが存在し得る。上記シナリオにおけるネットワーク・リソースの非可用性は、所与の期限時間センサタスクの達成／実行を遅延させ、危機的な状況につながるおそれがある。特許文献１に基づいて、提案されたネットワーク管理部は、純粋にルールベースであり、状況適応型ではないと結論付けることができる。

新しいモジュール（スイッチのスイッチング周期を決定するネットワーク管理部）の主な貢献は、すなわち、計算システムの内部のネットワーク管理部が、ネットワーク帯域幅とセンサデータ伝送遅延要求のマッチングに基づいて、センサデータ伝送タスクを決定することである。センサデータは、種々のスイッチを経由して計算システムへ伝送されるので、この設計は、センサデータが計算ユニットに到達するための冗長化パスを提供するフェイル・オペレーショナル（故障時動作継続）の設計である。センサタスク期限／遅延要求およびスイッチ可用性に応じて、センサデータは、高性能計算ユニットまたは安全ユニットのいずれかに到達するために、スイッチ１または２を含むパスを取ることができる。特許文献１において、スイッチ１は、より小さい帯域幅の伝送路であることができ、スイッチ２は、より大きい帯域幅の伝送路であることができ、または、そのシステムの要求に応じてその逆であることができる。演算リソースの状態とスイッチに応じて、センサデータは様々な遅れで伝送される。

しかしながら、特許文献１に記載された発明の主な欠点は、センサデータ・タスク・スケジューラ／ネットワーク管理部がルールベース・システムであることにある。このタスク・スケジューラは、利用可能な車載ネットワークを最適に利用することができない。このシステムは、全体的に状況適応型でもなく、リソースの可用性から生成された規定されたルールのドメイン内で調整することができる。このシステムは、安全状態に到達するためのタスク優先度を再構成することもできない。

従来のタスク・プライオリタイズ／スケジューラは、タスクのリソース要求と、リソース可用性との間のマッチングを行う。リソース要求とリソース可用性とがマッチしない場合、タスク・スケジューラは、要求されたリソースが利用可能になるまで、そのタスクを停止する。そのため、ＡＤＳ／ＡＤＡＳに含まれる従来のタスク・スケジューリング・システムは、利用可能なリソースの最適な利用を保証できないと結論付けることができる。

ＡＤＳ／ＡＤＡＳのためのランタイム・ダイナミック・タスク・オーケストレータを実行するために、タスク・リソース要求と可用性は、一致する必要がある。本実施形態の車両制御システムＳ１１１は、タスクのリソース要求が充足できない場合には、利用可能なリソースを最適に使用して車両ＳＶが必要な最小リスク操作を常に実行できるようにするために、タスクの優先度を再構成することを提案する。すなわち、本実施形態に係る車両制御システムＳ１１１は、状況適応型のダイナミック・タスク・オーケストレータを含むことによって、特許文献１の上記の制限を克服することを意図している。

本実施形態の車両制御システムＳ１１１は、前述のように、要求生成部ＲＧと、可用性取得部ＡＡと、優先度生成部ＰＧと、実行管理部ＥＭとを備えることを特徴とする。要求生成部ＲＧは、車両ＳＶを走行シナリオＤＳに従って走行させるためのタスクの要求を生成する。可用性取得部ＡＡは、車載電気電子システムにおけるリソースの可用性を取得する。優先度生成部ＰＧは、タスクの要求とリソースの可用性とに基づいてタスクの優先度を生成する。実行管理部ＥＭは、優先度に従ってタスクを実行する。このような構成により、本実施形態の車両制御システムＳ１１１は、車載ＥＥシステムＳ１００のリソースを有効に活用して車両ＳＶを安全に走行させることができる。

また、本実施形態の車両制御システムＳ１１１において、実行管理部ＥＭは、たとえば図１０に示すように、タスクを実行不可と判定した場合に、車両ＳＶの最小リスク操作を実行する。このような構成により、本実施形態の車両制御システムＳ１１１は、車載ＥＥシステムＳ１００のリソースを有効に活用して車両ＳＶを安全に走行させることができる。

また、本実施形態の車両制御システムＳ１１１は、車載ＥＥシステムＳ１００のリソースの最適な使用のためのリカバリーステップとして、タスクの期限時間／実行時間を変更することもできる。すなわち、一実施形態において、利用可能な限られたリソースを前提とする最小リスク操作を実行するために、タスク実行時間も変更することができる。リソース要求を削減してタスクを実行するために、異なるリソース性能を要求する補完認識タスクの情報を使用することができる。本実施形態の車両制御システムＳ１１１は、利用可能な限定されたリソースのドメインに含まれるタスク・プライオリタイゼーション／スケジューリングの補完タスク要求の情報を使用することができる。

走行シナリオＤＳの情報を用いることで、理想的な優先度に基づくＡＤＳ／ＡＤＡＳのシステム・タスク要求を生成することができる。本実施形態の車両制御システムＳ１１１は、演算リソースとネットワーク帯域幅の可用性も考慮する。リソースの可用性を監視するために、本実施形態の車両制御システムＳ１１１は、各アプリケーションの実行管理部ＥＭを利用する。実行管理部ＥＭは、リソースの配分と所与のアプリケーションのプロセスのスケジューリングを担う。

各アプリケーションの実行管理部ＥＭは、アプリケーションの従属関係も管理するとともに、従属するプロセス状況の稼働状況を確認する。これにより、各アプリケーションの実行管理部ＥＭを監視することで、演算リソースのランタイムでの可用性およびネットワーク帯域幅の可用性が容易に監視できる。上述の二つの手順に従うことで、タスク要求とリソース可用性を適合させることができる。

しかしながら、タスク・リソース要求とリソース可用性との間のミスマッチにつながり、そのミスマッチに対処しなかった場合に危険をもたらす複数のシナリオ／条件があってもよい。タスク・リソース要求とリソース可用性との間のミスマッチの場合におけるほとんどの利用可能な状況において、タスク・スケジューリングは、要求されるリソースが利用可能になるまで遅延する。これは、動的で危機的な走行シナリオの場合に、危険な状況につながる可能性がある。

図４に示すゾーンベース車載アーキテクチャにおいて、ネットワークデータ伝送路のひとつが何らかの原因で故障した場合、限られたデータ伝送ネットワーク経路が利用できる。この場合、理想的な期限内にタスクが実行できないことが明らかである。これは、動的な危機的走行シナリオの場合に、危機的な状況につながりかねない。このような問題を解決するために、本実施形態の車両制御システムＳ１１１は、車両ＳＶの挙動を変更することにつながるタスク実行時間を変更する。しかし、ＡＤＳ／ＡＤＡＳは、危機的な走行シナリオにおいて、本実施形態の車両制御システムＳ１１１によるタスク実行時間に従うことで、最小リスク操作を実行することを保障できる。

以上、図面を用いて本開示に係る車両制御装置の実施形態を詳述してきたが、具体的な構成はこの実施形態に限定されるものではなく、本開示の要旨を逸脱しない範囲における設計変更等があっても、それらは本開示に含まれるものである。前述の実施形態の機能および方法は限定ではなく例示である。また、前述の実施形態の特定の態様は様々な他の構成との組み合わせが可能であり、それらは本開示に含まれる。たとえば、前述の本開示に係る車両制御装置の実施形態では、車両として自動車を例に挙げて説明した。しかし、本開示に係る車両制御装置は、バス、トラック、建設機械、地表ロボット、倉庫ロボット、航空機、ヘリコプター、ボート、船舶、農機具、サービスロボット、列車、ゴルフカートや、その他の車両に適用することが可能である。

前述の様々な実施形態は、たとえば、車両の自動運転システム（ＡＤＳ）または先進運転支援システム（ＡＤＡＳ）のためのランタイム・ダイナミック・タスクオーケストレータに関する。本開示の背景にある主な目的は、たとえば、センシングタスク、認識タスク、計画タスク、行動タスクなど、ＡＤＳまたはＡＳＡＳの様々なタスクによる演算リソースの要求および可用性に応じて、それらのタスクのランタイム・タスク・プライオリタイゼーションを行うことである。また、上記したＡＤＳまたはＡＳＡＳのいくつかのタスクが、車内のＥＥネットワークにおける一定のネットワーク帯域幅を必要とする場合には、ネットワーク帯域幅もタスク・プライオリタイゼーションのために考慮する。

本開示の主な貢献は、たとえば、所与の走行シナリオを安全にナビゲートするためのタスク／サービスの優先度および実行時間／期限時間の導出である。本実施形態に係る車両制御システムは、実行する必要があるタスク／サービスがリストアップされたら、運転シーンの要求から導出されたタスク／サービスによるネットワーク帯域幅および演算リソースの要求を確認する。その後、本実施形態に係る車両制御システムは、たとえば、タスク／サービス／アプリケーションの実行管理部により、ネットワーク帯域幅および演算リソースの可用性を確認する。この実行管理部は、タスク／サービスのスケジューリングとリソース配分を担う。最終的には、要求と可用性に基づいて、タスク／サービスの優先度が、ランタイムにおいて更新／再構成される。

利用可能なネットワーク帯域幅および演算リソースによってタスク／サービスの実行時間の要求が達成できない場合、たとえば、それらのリソースの可用性および要求に適合するように、タスク／サービスの実行時間が更新される。このタスク／サービスの実行時間の更新は、車両の挙動も変更する。このタスク／サービスの実行時間の更新の背景にある主な考えは、たとえば、ＡＤＳ／ＡＤＡＳの構成要素に障害が発生した場合に利用可能なリソースの最適に利用することである。車両が危険な状態または最悪の状態に陥ったときに、タスク／サービスの実行時間を変更するだけで安全性と快適性が保証できない場合には、安全な最小リスクの挙動、障害劣化挙動、または停止操作を保証するように、ＡＤＳ／ＡＤＡＳのタスク／サービスの優先度を再構成してもよい。

本開示は、ＡＤＳ／ＡＤＡＳの状態および条件によって動作するタスク・オーケストレータを含み、車載ＥＥネットワーク・アーキテクチャ（ドメインベースまたはゾーンベースのＥＥアーキテクチャ）に実装することができる。状態および条件によって動作する本実施形態のタスク・オーケストレータは、タスク・プライオリタイゼーションのために、他のドメインと連携する各ドメインにおいて分散システムとして使用することができる。

本開示は、状況適応型のランタイム・ダイナミック・タスク／サービスの実行時間／期限時間の変更によって、完全または半自動車両の安全操作を向上させる方法論を提供する。状況適応型のランタイム・ダイナミック・タスク／サービス・オーケストレーションを実行するために、車両は、たとえば、道路トポロジ、建造物などの静的運転ドメインの特徴、その他の静的な特徴など、静的な操作運転設計ドメイン知識ベースの知識ベースを有してもよい。同様に、車両は、環境の状態、環境認識アルゴリズム制約、および追加的なスループットのための要求など、動的な操作運転設計ドメイン知識ベースの知識ベースを有してもよい。静的および動的な操作運転設計ドメインに基づいて、車両は、所与の危機的な走行シナリオにおいて、車両を安全にナビゲートするのに要求される、状況的かつ車両制御システムの状況ベースのタスク／サービスを導出してもよい。

本実施形態の動的な状況適応型のタスク／サービス・オーケストレータは、最終的に、タスク／サービス・リソース要求と、車両制御システムのリソースの可用性とに基づいて、危機的な走行シナリオにおいて最小リスク操作を実行することが要求される車両の挙動の変更につながるタスク／サービスの優先度または実行時間／期限時間を変更する。主要目的は、いわば、自動運転システム（車両制御システム）が互いに頻繁に交信するいくつかのモジュールを備えることである。そのため、車両システムに含まれるいくつかのモジュールの統合と調整は、困難な課題である。さらに、各モジュールは、センサデータ、認識データ、計画データ、アプリケーション状況データなどを要求するいくつかのアプリケーションをさらに備えてもよい。このモジュールに含まれるすべてのアプリケーション、またはモジュール自体は、いくつかのリソース要求と、危機的な走行シナリオおよび車両制御システム状態を前提とする優先度とを有してもよい。これらのタスクの統合と調整の主な課題は、利用可能なリソースの状態を前提として、これらのタスク／サービスのランタイムの優先度と期限を適応させることである。

すべてのモジュールは、共通のリソースを共有し、リソースの可用性に制限がある場合に競合状態の影響を受ける。そのため、本実施形態の車両制御装置では、主な目的は、車載ＥＥリソースを最適に使用すること（高性能かつ最適なリソースの利用）である。また、広診断範囲および安全評価のためのサービス／データ伝送遅延の事前予測である。そして、最後に、タスクのランタイム中の動的な期限と優先度の調整である。たとえば、高速道路などの所与の走行シナリオにおいて、リソースの可用性応じて、車両は、自動走行、車線変更、低速自動走行、または安全停止などの機能を実行する。しかし、従来のタスク計画部では、リソースの可用性が制限されている場合、車両はルールに記述されたタスクを実行することができるだけである。しかし、本実施形態の車両制御システムは、制限されたリソースの可用性を前提とし、車載ＥＥリソースを最適に使用して最適な安全操作を提供する。

たとえば、車載ＥＥネットワークは、多重のデータ伝送ネットワーク伝送路を有してもよい。データ伝送ネットワーク伝送路のひとつに障害が発生した場合、すべてのタスク／サービスは、利用可能なネットワーク伝送路を取らなくてはならない。そのようなシナリオでは、タスク／サービスの期限／実行の遅延が増加し、エラー／異常信号の生成につながる。しかし、本実施形態の車両制御システムは、そのようなシナリオに対処し、車両制御システムの安全監視部にリソースの制限された可用性による追加の遅延を通知する。上述の解決手段を適用することで、車両制御システムは最適なリソースの利用を保証することができる。さらに、タスク／サービスの期限／実行／遅延のランタイムでの推定は、車両制御システムの診断範囲の拡大に寄与する。

本実施形態の車両制御システムの他の例では、異なるリソースを要求するいくつかの補完的なタスク／サービスを備える。たとえば、レーダ、ＬｉＤＡＲ、カメラなどを用いた車両検知は、必要なネットワーク帯域幅が異なる。データの大きさに応じて、所定の時間期限内にセンサデータを演算リソースへ伝送するためのレーダのネットワーク帯域幅は、カメラと比較して大幅に小さい。レーダおよびカメラに基づく対象物の検知は実際には相補的であり、レーダで検知された対象物の情報は、カメラによるセンサデータのフィルタリングとサンプリングに使用することができる。上述の解決策に従うことで、サンプリング、トリミング、およびフィルタリングされたセンサデータは、未加工のカメラによるセンサデータと比較して、大幅に小さいネットワーク帯域幅を必要とするようになる。

同様に、自動運転車両がいくつかのセンサ／情報を実際に相補的に使用する場合、リソースの可用性が制限されたシナリオでネットワーク帯域幅の要求を満足することができないタスク／サービスのネットワーク帯域幅の要求を、ネットワーク帯域幅を有効に利用して減少させることができる。他の例において、提案する最小限のリソースを要求する相補的なタスクの有効利用は、最適な電力利用にも使用することができる。高度自動運転車両の場合、フェイル・オペレーショナル（故障時動作継続）の車両制御システムを備えることができる。そのようなシステムは、常時動作することが要求される可能性がある全システムとしての追加の冷却装置を必要とする場合がある。

ＡＡ 可用性取得部
ＤＳ 走行シナリオ
ＥＭ 実行管理部
ＰＧ 優先度生成部
ＲＧ 要求生成部
Ｓ１００ 車載ＥＥシステム（車載電気電子システム）
Ｓ１１１ 車両制御システム
ＳＶ 車両

Claims (2)

1. 車両を走行シナリオに従って走行させるためのタスクの要求を生成する要求生成部と、
   車載電気電子システムにおけるリソースの可用性を取得する可用性取得部と、
   前記タスクの要求と前記リソースの可用性とに基づいて前記タスクの優先度を生成する優先度生成部と、
   前記優先度に従って前記タスクを実行する実行管理部と、
   を備えることを特徴とする車両制御システム。
2. 前記実行管理部は、前記タスクを実行不可と判定した場合に、前記車両の最小リスク操作を実行することを特徴とする請求項１に記載の車両制御システム。

Images