特開2021-195029(P2021-195029A)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社日立製作所の特許一覧

<>
  • 特開2021195029-車両制御システム 図000003
  • 特開2021195029-車両制御システム 図000004
  • 特開2021195029-車両制御システム 図000005
  • 特開2021195029-車両制御システム 図000006
  • 特開2021195029-車両制御システム 図000007
  • 特開2021195029-車両制御システム 図000008
  • 特開2021195029-車両制御システム 図000009
  • 特開2021195029-車両制御システム 図000010
  • 特開2021195029-車両制御システム 図000011
  • 特開2021195029-車両制御システム 図000012
  • 特開2021195029-車両制御システム 図000013
  • 特開2021195029-車両制御システム 図000014
  • 特開2021195029-車両制御システム 図000015
  • 特開2021195029-車両制御システム 図000016
  • 特開2021195029-車両制御システム 図000017
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】特開2021-195029(P2021-195029A)
(43)【公開日】2021年12月27日
(54)【発明の名称】車両制御システム
(51)【国際特許分類】
   B60W 50/06 20060101AFI20211129BHJP
   G08G 1/09 20060101ALI20211129BHJP
   G08G 1/16 20060101ALI20211129BHJP
【FI】
   B60W50/06
   G08G1/09 V
   G08G1/16 A
【審査請求】未請求
【請求項の数】2
【出願形態】OL
【全頁数】18
(21)【出願番号】特願2020-103389(P2020-103389)
(22)【出願日】2020年6月15日
(71)【出願人】
【識別番号】000005108
【氏名又は名称】株式会社日立製作所
(74)【代理人】
【識別番号】110002572
【氏名又は名称】特許業務法人平木国際特許事務所
(72)【発明者】
【氏名】ラトル スワラン シンガ
(72)【発明者】
【氏名】大塚 敏史
【テーマコード(参考)】
3D241
5H181
【Fターム(参考)】
3D241BA62
3D241CC01
3D241CC08
3D241CC11
3D241CC17
3D241CD09
3D241CE05
3D241DA39Z
3D241DA52Z
3D241DB20Z
3D241DC25Z
3D241DC33Z
3D241DC34Z
5H181AA01
5H181BB04
5H181CC04
5H181CC14
5H181FF22
5H181LL01
5H181LL02
5H181LL04
5H181LL09
(57)【要約】
【課題】車載電気電子システムのリソースを有効に活用して車両を安全に走行させることができる車両制御システムを提供する。
【解決手段】車両制御システムS111は、要求生成部RGと、可用性取得部AAと、優先度生成部PGと、実行管理部EMと、を備える。要求生成部RGは、車両を走行シナリオに従って走行させるためのタスクの要求を生成する。可用性取得部AAは、車載電気電子システムにおけるリソースの可用性を取得する。優先度生成部PGは、タスクの要求とリソースの可用性とに基づいてタスクの優先度を生成する。実行管理部EMは、優先度に従ってタスクを実行する。
【選択図】図9
【特許請求の範囲】
【請求項1】
車両を走行シナリオに従って走行させるためのタスクの要求を生成する要求生成部と、
車載電気電子システムにおけるリソースの可用性を取得する可用性取得部と、
前記タスクの要求と前記リソースの可用性とに基づいて前記タスクの優先度を生成する優先度生成部と、
前記優先度に従って前記タスクを実行する実行管理部と、
を備えることを特徴とする車両制御システム。
【請求項2】
前記実行管理部は、前記タスクを実行不可と判定した場合に、前記車両の最小リスク操作を実行することを特徴とする請求項1に記載の車両制御システム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、車両制御システムに関する。
【背景技術】
【0002】
従来から、車両のセンサからセンサデータを受信するコンピュータシステムが知られている(下記特許文献1を参照)。特許文献1に記載されたコンピュータシステムは、車両の一以上のセンサからセンサデータを受信し、受信したセンサデータに基づいて車両に関連する指標を測定し、その指標に基づいて車両の通信網における伝送サイクルの長さを決定する。この伝送サイクルは、通信網のそれぞれの第1ノードからデータを伝送するための一以上の予定された期間を含む。コンピュータシステムは、少なくとも部分的に、伝送サイクルの長さ基づいて、伝送サイクルの複数のインスタンスにおける予定された期間のそれぞれの発生頻度を調整するために、車両の通信網を構成する(同文献、要約等を参照)。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】米国特許出願公開第2019/0322288号明細書
【発明の概要】
【発明が解決しようとする課題】
【0004】
特許文献1に記載されたコンピュータシステムは、主に、センサデータの伝送レイテンシと、ネットワークの可用性との間のルールベースのマッチングに焦点を当てている。車両の自動運転システム(ADS)や先進運転支援システム(ADAS)における安全上重大な走行シナリオでは、安全な最小リスク操作を実行するための特定のセンサデータを要求する複数のインスタンスが存在する可能性がある。このような走行シナリオにおいて、ネットワーク・リソースの不足によるセンサタスクの達成または実行の遅延は、車両の危険な状態につながりかねない。
【0005】
本開示は、車載電気電子システムのリソースを有効に活用して車両を安全に走行させることができる車両制御システムを提供する。
【課題を解決するための手段】
【0006】
本開示の一態様は、車両を走行シナリオに従って走行させるためのタスクの要求を生成する要求生成部と、車載電気電子システムにおけるリソースの可用性を取得する可用性取得部と、前記タスクの要求と前記リソースの可用性とに基づいて前記タスクの優先度を生成する優先度生成部と、前記優先度に従って前記タスクを実行する実行管理部と、を備えることを特徴とする車両制御システムである。
【発明の効果】
【0007】
本開示によれば、車載電気電子システムのリソースを有効に活用して車両を安全に走行させることができる車両制御システムを提供することができる。
【図面の簡単な説明】
【0008】
図1】本開示の車両制御システムの一実施形態を示すブロック図。
図2図1のセンサシステムに含まれる外界センサの一例を示す平面図。
図3図1の車載電気電子システムの構成例を示すブロック図。
図4図1の車載電気電子システムの構成例を示すブロック図。
図5図3に示す車載電気電子システムのより詳細なブロック図。
図6図4に示す車載電気電子システムのより詳細なブロック図。
図7図3から図6に示す車載電気電子システムが実行するタスクの一例。
図8図5および図6の実行管理部の動作の一例を示すフロー図。
図9図5および図6の車両制御システムのブロック図。
図10図9に示す車両制御システムの処理の流れの一例を示すフロー図。
図11】車両に搭載されたカメラの画像の一例。
図12】タスク要求とリソースの可用性とレイテンシとの関係の一例を示す表。
図13図9の車両制御システムの処理の流れの一例を示すフロー図。
図14】車両の走行シナリオの一例を示す平面図。
図15】車載電気電子システムによるアプリケーションの実行順序を示すフロー図。
【発明を実施するための形態】
【0009】
以下、図面を参照して本開示に係る車両制御システムの実施形態を説明する。
【0010】
図1は、本開示の車両制御システムの一実施形態を示すブロック図である。本実施形態の車両制御システムS111は、たとえば、車載電気電子システム(以下、「車載EEシステム」と略称する。)S100に含まれる。車載EEシステムS100は、たとえば、自動車などの車両に搭載され、車両の自動運転システム(ADS)または先進運転支援システム(ADAS)を構成する。図1に示す車載EEシステムS100の各構成要素または各モジュールは、たとえば、ハードウェア、ソフトウェア、ネットワーク、ワイヤ・ハーネスなどによって構成されている。
【0011】
図1に示す車載EEシステムS100は、たとえば、車両制御システムS111の他に、センサシステムS101、外界認識システムS102、計画システムS103、無線通信システムS104、物理ネットワークS105、動作システムS106、を含む。また、車載EEシステムS100は、たとえば、車体制御システムS107、インフォテインメント・システムS108、ヒューマン・マシン・インタフェース(HMI)システムS109、運転者監視システムS110、V2XシステムS112を含む。さらに、車載EEシステムS100は、たとえば、運転者意図認識システムS113、車両診断・故障監視システムS114、駆動系システムS115を含む。なお、車載EEシステムS100は、図1に示す構成要素の一部を省略してもよく、他の構成要素を含んでもよい。
【0012】
図1に示すように、車載EEシステムS100は、たとえば、個々の構成要素間の通信を可能にする無線通信システムS104および物理ネットワークS105を備えている。また、車載EEシステムS100は、たとえば、高い冗長性とリソースの可用性を提供して、システムの信頼性を向上させる一以上の物理ネットワークS105または無線ネットワークを備えてもよい。センサシステムS101は、たとえば、外界センサ、車両センサ、位置測定センサなどを含む。車両制御システムS111は、たとえば、車両のステアリングホイール、スロットル、ブレーキ、ギアシフトなどを操作するためのアクチュエータを含む。
【0013】
図2は、図1のセンサシステムS101に含まれる外界センサESの一例を示す平面図である。外界センサESは、たとえば、車載EEシステムS100が搭載された車両SVの前方に測定範囲RM1,RM2を有する長距離レーダES1および赤外線レーザセンサES2と、車両SVの前後左右に測定範囲RM3を有する複数のカメラES3とを含む。また、外界センサESは、たとえば、車両SVの前後に測定範囲RM4を有する複数の短距離レーダES4と、車両SVの前後に測定範囲RM5を有する複数のLiDAR(ES5)とを含む。
【0014】
長距離レーダES1の測定距離は、たとえば、1[m]から280[m]程度であり、赤外線レーザセンサES2の測定距離は、たとえば、0.2[m]から120[m]程度であり、カメラES3の測定距離は、たとえば、0.2[m]から100[m]程度である。また、短距離レーダES4の測定距離は、たとえば、0.2[m]から60[m]程度であり、LIDAR(ES5)の測定距離は、たとえば、0.2[m]から80[m]程度である。
【0015】
図3および図4は、それぞれ、図1の車載EEシステムS100の構成例を示すブロック図である。より詳細には、図3は、ドメイン・アーキテクチャを採用した車載EEシステムS100の一例を示すブロック図であり、図4は、ゾーン・アーキテクチャを採用した車載EEシステムS100の一例を示すブロック図である。
【0016】
図3に示すドメイン・アーキテクチャを採用した車載EEシステムS100は、たとえば、複数の電子制御ユニット(ECU)を備えている。より具体的には、車載EEシステムS100は、たとえば、ゲートウェイECUと、このゲートウェイECUを介して相互に接続された複数のドメインECUとを備えている。複数のドメインECUは、たとえば、駆動系ECU、車体/快適性ECU、自動運転/先進運転支援(AD/ADA)ECU、インフォテインメントECU、接続性ECUなどを含む。各ドメインECUは、たとえば、さらに複数のECUを備えている。
【0017】
図4に示すゾーン・アーキテクチャを採用した車載EEシステムS100は、たとえば、エンジンルームやトランクルームなど、車両SVのゾーンごと配置された複数のゾーン・ゲートウェイECUを備える。各々のゾーン・ゲートウェイECUに対し、たとえば、駆動系、車体/快適性、AD/ADA、インフォテインメント、接続性など、複数のドメインが構築される。複数のゾーン・ゲートウェイECUは、ネットワーク伝送経路を介して相互に接続されるとともに、複数のネットワーク伝送経路を介して中央演算ECUに接続されている。すなわち、車載EEシステムは、各ゾーン・ゲートウェイECUと中央演算ECUとを接続する冗長な複数のネットワーク伝送経路を有している。
【0018】
図5は、図3に示すドメイン・アーキテクチャを採用した車載EEシステムのより詳細なブロック図である。なお、図5では、インフォテインメントECUと接続性EUCの図示を省略している。たとえば、駆動系ECU、車体/快適性ECU、AD/ADA・ECUなどの各ドメインECUは、それぞれのドメインに求められる判断を担う。ゲートウェイECUは、ドメインECU間のネットワーク通信を提供する。また、各ドメインECUは、たとえば、検知および検出を担う複数のセンサECUと、作動・動作を担う複数のアクチュエータECUとを備えている。
【0019】
より具体的には、図5に示すAD/ADA・ECUは、たとえば、図2に示す外界センサESを含む複数のセンサに接続された複数のセンサECUを有することができる。また、車体/快適性ECUは、たとえば、ステアリングやブレーキなどのアクチュエータに接続された複数のアクチュエータECUと、操舵角センサやブレーキ踏力センサなどに接続された複数のセンサECUを有することができる。駆動系ECUも同様に、スロットルのアクチュエータに接続されたECUを含む複数のアクチュエータECUと、複数のセンサECUを有することができる。
【0020】
また、図5に示すゲートウェイECUと各ドメインECUは、それぞれ、オペレーティングシステム(OS)と、種々のアプリケーションと、実行管理部EMと、可用性取得部AAとを有している。より具体的には、ゲートウェイECUと各ドメインECUは、それぞれ、記憶装置と中央処理装置を含む。OS、アプリケーション、実行管理部EM、および可用性取得部AAは、たとえば、各ECUの記憶装置に記憶されて中央処理装置によって実行されるソフトウェアやプログラムである。
【0021】
図5に示すゲートウェイECUと各ドメインECUにおいて、実行管理部EMは、たとえば、実行中のタスクを判定して可用性取得部AAへ出力し、可用性取得部AAは、実行管理部EMの出力である実行中のタスクに基づいてリソースの可用性を取得する。ここで、可用性取得部AAが取得するリソースの可用性は、たとえば、各ECUにおける演算リソースの可用性と、ネットワーク帯域幅などの通信リソースの可用性とを含む。
【0022】
図5に示すゲートウェイECUの可用性取得部AAは、たとえば、取得したリソースの可用性を各ドメインECUへ伝送する。また、各ドメインECUの可用性取得部AAは、たとえば、取得したリソースの可用性をゲートウェイECUへ伝送する。また、AD/ADA・ECUは、たとえば、要求生成部RGと、可用性取得部AAと、優先度生成部PGとを有し、本実施形態の車両制御システムS111として機能する。要求生成部RGと優先度生成部PGは、たとえば、AD/ADA・ECUの記憶装置に記憶されて中央処理装置によって実行されるソフトウェアやプログラムである。
【0023】
図6は、図4に示すゾーン・アーキテクチャを採用した車載EEシステムS100のより詳細なブロック図である。各々のゾーン・ゲートウェイECUは、たとえば、OSと、アクチュエータ状態取得部と、アクチュエータ指令生成部と、センサデータ取得部と、センサデータ処理部と、実行管理部EMと、可用性取得部AAと、その他の複数の処理部とを有している。これらゾーン・ゲートウェイECUのOSおよび各部は、たとえば、記憶装置に記憶されて中央処理装置によって実行されるソフトウェアやプログラムである。ゾーン・ゲートウェイECUのOSを除く各部は、同一のアプリケーションまたは異なるアプリケーションの一部であってもよい。車両SVのセンサおよびアクチュエータは、たとえば、ゾーン・ゲートウェイ・ECUに接続されている。
【0024】
図6に示すように、中央演算ECUは、たとえば、OSと、計画処理部と、動作処理部と、認識処理部と、走行シナリオ生成部と、複数のアプリケーションと、実行管理部EMと、要求生成部RGと、可用性取得部AAと、優先度生成部PGとを備えている。これら中央演算ECUのOSおよび各部は、たとえば、記憶装置に記憶されて中央処理装置によって実行されるソフトウェアやプログラムである。たとえば、中央演算ECUのOSを除く各部によって、本実施形態の車両制御システムS111を構成することができる。
【0025】
図7は、車載EEシステムS100が実行するタスクの一例を示す。車載EEシステムS100は、前述の構成により、検知タスク、動作タスク、推定タスクまたは認識タスク、診断タスク、計画タスク、および監視タスクなどの複数のタスクを実行することで、車両の自動運転や高度運転支援を実現する。各タスクは、たとえば、タスクID、実行周期または期間、実行時間、開始時間、期限または終了時間、および優先度などの属性を有する。なお、本実施形態の説明は、「タスク」を「サービス」または「タスク/サービス」に置き換えても成立する。
【0026】
検知タスクは、たとえば、外界認識タスクを含む。外界認識タスクは、車両制御システムが車両の安全なナビゲーションを行うための走行シナリオに基づく外界情報の要求に応じて種々の外界センサESを使用して、車両SVの周囲の物体を認識するタスクである。検知タスクは、たとえば、外界センサESの作動や、外界センサESの検知データの取得などを担ういくつかのタスクをさらに有する。
【0027】
同様に、動作タスク、推定タスクまたは認識タスク、診断タスク、計画タスク、および監視タスクは、たとえば、車載EEシステムの各構成要素または各モジュールの制御と統合を担ういくつかのサブタスクに分解することができる。各タスクの属性に基づいて各タスクを監視することで、タスクのスケジューリングの状況、実行の状況、終了の状況など、ランタイムでのタスクの監視を実現することができる。
【0028】
図8は、図5および図6の実行管理部EMの動作を示すフロー図である。実行管理部EMは、各ECUにおけるリソースの配分とタスクのスケジューリングを担う。これにより、ランタイムでのリソースの可用性と状態の監視を行うことができる。車両制御システムS111を構成するモジュール/アプリケーションは、それぞれ、実行管理部EMを備えてもよい。モジュール/アプリケーションのバイナリは、たとえば、いくつかのプロセスを含む。実行管理部EMは、たとえば、各プロセスの他のプロセスに対する従属関係を規定する。
【0029】
図8に示すように、実行管理部EMは、たとえば、要求されるリソースのアプリケーション(プロセス)への配分、ならびに、プロセスのスケジューリング、実行処理、終了処理、および、終了後のリソースの解放を担う。図8の上部に示すフローにおいて、遊休状態は、アプリケーションが実行される前の状態である。実行管理部EMがアプリケーションを実行して起動すると、プロセスの生成とリソースの配分、すなわちスケジューリングが行われる。具体的には、図8の左下のフローに示すように、OSを起動して実行管理部EMを起動すると、実行管理部EMは、アプリケーションの従属関係とリソースの要求を確認し、アプリケーションにリソースを配分する。これにより、配分されたリソースと空きリソースの知識ベースが作成される。
【0030】
さらに、図8の上部のフローに示すように、プロセスの実行処理が行われる。ここで、図8の左下のフローに示すように、実行管理部EMは、リソースの配分後に、インスタンスの作成を行う。より具体的には、実行管理部EMは、当初の順序またはスケジューリングされた順序に基づいて、アプリケーションの実行可能なプロセスのインスタンスを作成する。これにより、配分されたリソースと空きリソースの知識ベースに基づいて、データ伝送ネットワーク・リソースが利用される。以上のように、ランタイムの演算リソースおよびネットワーク・リソースの可用性および状態へのアクセスが行われる。
【0031】
以下、本実施形態の車両制御システムS111の動作の一例を、図9から図12を参照して説明する。図9は、本実施形態の車両制御システムS111のブロック図である。図10は、図9に示す車両制御システムS111の処理の流れを示すフロー図である。図11は、車両SVに搭載されたカメラES3の画像の一例である。
【0032】
本実施形態の車両制御システムS111は、たとえば、図5図6および図9に示すように、少なくとも、要求生成部RGと、可用性取得部AAと、優先度生成部PGと、実行管理部EMと、を備え、車載EEシステムS100の一部を構成する。車両制御システムS111が図10に示す処理を開始する前に、車載EEシステムS100は、走行シナリオDSを生成する。車載EEシステムS100は、たとえば、図1に示すセンサシステムS101、外界認識システムS102、および計画システムS103、もしくは、図5図6に示す走行シナリオ生成部によって、以下のような手順で走行シナリオDSを生成する。
【0033】
車載EEシステムS100は、たとえば、図11に示すカメラES3の画像データなど、外界センサESによって取得されたセンサデータに基づいて、車両SVの周囲の他の車両、障害物、道路、道路標示などを含む外部環境の認識結果を取得する。車載EEシステムS100は、たとえば、外部環境の認識結果に基づいて、車両SVの走行シナリオDSを生成する。走行シナリオDSは、たとえば、所定の速度での直進、先行車両との車間距離を維持した追従走行、先行車両の追い越し、障害物の回避、交差点の右左折、信号や道路標示による減速や停止などを含む。
【0034】
車両制御システムS111が図10に示す処理フローを開始すると、要求生成部RGは、車両SVを走行シナリオDSに従って走行させるためのタスク要求を生成する処理P11を実行する。タスク要求は、たとえば、図7に示す検知タスク、推定タスク、計画タスク、動作タスク、診断タスク、監視タスクなどの各種のタスクにおける要求を含む。次いで、優先度生成部PGは、たとえば、タスク要求の理想的な優先度要求を生成する処理P12を実行する。
【0035】
また、たとえば、要求生成部RGおよび優先度生成部PGによるタスク要求および優先度要求を生成する処理P11,P12と並行して、可用性取得部AAは、車載EEシステムS100のリソースの可用性を取得する処理P13を実行する。ここで、車載EEシステムS100のリソースは、車載EEシステムS100の演算リソースARの可用性と、車載EEシステムS100のネットワーク帯域幅などの通信リソースCRの可用性とを含む。より具体的には、可用性取得部AAは、たとえば、車載EEシステムS100の演算リソースARの状態と通信リソースCRの状態に基づいて、演算リソースARの可用性と通信リソースCRの可用性を算出する。
【0036】
図12は、タスク要求と、リソースの可用性と、レイテンシとの関係の一例を示す表である。図12の表は、たとえば、通信リソースCRの可用性としてのネットワーク帯域幅に基づくデータ速度が25[Gb/s]である場合、カメラES3とLiDAR(ES5)からデータを取得するタスク要求のレイテンシは、それぞれ10[ms]と1[ms]であることを示している。
【0037】
しかし、通信リソースCRの可用性が低下して、データ速度が5[Gb/s]に低下すると、上記データを取得するタスク要求のレイテンシは、それぞれ45[ms]と2[ms]に増加する。また、図12の表は、たとえば、長距離レーダES1を含むレーダからのデータ取得など、他のタスク要求のレイテンシは、カメラES3やLiDAR(ES5)に関するタスク要求のレイテンシと比較して、無視できる程度に小さいことを示している。そのため、レーダのセンサデータを使用して、カメラES3のセンサデータをフィルタリングおよびサンプリングすることで、通信リソースの要求を低減することができる。
【0038】
優先度生成部PGは、たとえば、車載EEシステムS100のリソースすなわち演算リソースARおよび通信リソースCRの可用性と、各種のタスク要求とのマッチングに基づいて、図10に示す優先度要求を再計算する処理P14を実行する。また、優先度生成部PGは、たとえば、演算リソースARの可用性と、ネットワーク帯域幅などの通信リソースCRの可用性とに基づいて、タスク要求のレイテンシを算出する。優先度生成部PGは、たとえば、必要なリソースがより少ないタスク要求により高い優先度を付与して、先にスケジューリングする。優先度生成部PGの計算結果は、たとえば、より多くのリソースを必要とするタスク要求のフィルタリングに用いることができる。
【0039】
次に、実行管理部EMは、たとえば、優先度生成部PGによって生成されたタスク要求の優先度とレイテンシとに基づいて、タスク要求の実行可否を判定する処理P15を実行する。実行管理部EMは、タスク要求が実行可能(YES)と判定すると、優先度に従ってタスクを実行する処理P16を行う。実行管理部EMは、たとえば、車両制御システムS111の状態を確認して、すべてのタスクが実行されていることを確認する。一方、実行管理部EMは、タスク要求が実行不可(NO)と判定すると、最小リスク操作を行う処理P17を実行する。
【0040】
次に、本実施形態の車両制御システムS111の他の動作の一例を、図13および図14を参照して説明する。図13は、図9の車両制御システムS111の処理の流れの一例を示すフロー図である。図14は、車両SVの走行シナリオDSの一例を示す平面図である。
【0041】
車両制御システムS111は、たとえば、図13に示す処理フローを開始すると、まず、直前の時刻t−1において選択中の車両SVの走行シナリオDSを取得する処理P21を実行する。次に、車両制御システムS111は、現在時刻tにおいて選択可能な車両SVの走行シナリオDSと、各々の走行シナリオDSの優先度とを取得する処理P22を実行する。車両制御システムS111は、たとえば、安全性や快適性などの判断基準に基づいて、各々の走行シナリオDSの優先度を決定する。
【0042】
図14に示すように、車両SVは、たとえば、三車線の直線道路の中央車線を走行し、前方に複数の他の車両OVが走行し、後方にも複数の他の車両OVが走行している。車両制御システムS111は、処理P22において、たとえば、外界センサESを含むセンサシステムS101の検知結果に基づいて、車両SVの同一車線内でのアダプティブ・クルーズ・コントロール(ACC)または停車、左車線への車線変更、右車線への車線変更など、選択可能な複数の走行シナリオDSを取得する。
【0043】
次に、車両制御システムS111は、たとえば、処理P22で取得された選択可能な走行シナリオDSの各々について、タスク要求のリストを生成する処理P23を実行する。ここで、タスク要求は、たとえば、図7に示すような各々のタスクが必要とする演算リソースや通信リソースの大きさすなわちリソース要求を含む。次に、車両制御システムS111は、たとえば、図3から図6に示すような車載EEシステムS100の演算リソースや通信リソースなどのリソースの可用性を取得する処理P24を実行する。
【0044】
次に、車両制御システムS111は、前の処理P23で生成されたタスク要求と、前の処理P24で取得されたリソースの可用性とをマッチングする処理P25を実行する。次に、車両制御システムS111は、前の処理P25のマッチングの結果に基づいて、リソースの可用性がタスク要求を満足するか否かを判定する処理P26を実行する。
【0045】
処理P26において、リソースの可用性が、最も優先度の高い走行シナリオDSのタスク要求を満足する(YES)と判定された場合には、その走行シナリオDSに基づいて車両SVを制御するためのタスクを実行する処理P27を行う。一方、処理P26において、リソースの可用性が、最も優先度の高い走行シナリオDSの最も優先度の高いタスク要求を満足しない(NO)と判定された場合には、リソースの可用性を満足するようにタスク要求の優先度を生成する処理P28を実行して、処理P25へ戻る。
【0046】
なお、処理P28においてタスク要求の優先度を生成した後、処理P25、処理P26を経て、再度、処理P28が実行される場合が考えられる。この場合、車両制御システムS111は、前の処理P22で取得した最も優先度が高い走行シナリオDSを、次に優先度の高い走行シナリオDSに変更することができる。これにより、リソースの可用性を満足する走行シナリオDSを選択することが可能になる。
【0047】
図15は、所与の走行シナリオDSにおいて車両SVを安全にナビゲートするために、車載EEシステムS100によって実行されるいくつかのアプリケーションの順序の一例を説明するブロック図である。車載EEシステムS100は、まず、車両SVの現在位置を取得して、グローバルマップにおける自車両の場所を特定するタスクT1を実行する。次に、車載EEシステムS100は、車両SVに搭載されたマップを用い、グローバルマップ上の車両SVの位置に基づいて、車両SVをナビゲートすべき道路トポロジを導出するタスクT2を実行する。
【0048】
次に、車載EEシステムS100は、走行シナリオDSの進展を予測するために、走行シナリオDSに関する情報を収集するタスクT3を実行する。これにより、特定された車両SVの位置の誤差が、要求される誤差の範囲内であれば、車載EEシステムS100は、位置を特定するタスクT1の優先度を低下させ、外界認識を行うタスクT3に重点を置くことができる。この外界認識を行うタスクT3において、車載EEシステムS100は、カメラES3、LiDAR(ES5)、長距離レーダES1などのいくつかの外界センサESを使用することができる。
【0049】
外界センサESを用いて他の車両などを検知する外界認識タスクは、概して相補的タスクである。そのため、車載EEシステムS100は、レーダで検知した他の車両に対応するカメラES3のセンサデータのフィルタリングに、長距離レーダES1によって検知した対象物情報を使用することができる。このような工程を用いることで、カメラES3のセンサデータを取得するタスクによるネットワーク帯域幅の要求を減少させることができる。次に、車載EEシステムS100は、認識した対象物のクラスタリングと境界ボックスを生成するタスクT4と、画像パッチ・トリミングのタスクT5と、決定および伝送のタスクT6とを実行する。
【0050】
以下、従来技術との対比に基づいて本実施形態の車両制御システムS111の作用を説明する。
【0051】
高度自動運転車両に対する需要の背景にある最も有望な理由の一つは、衝突のリスクを予測して車両の挙動を安全な状態に戻すように変更する高度自動運転車両の宣伝された機能である。しかしながら、運転ミスを最小化することを目的として、人を運転の意思決定プロセスから除外する提案は、高度な自動運転車両を機械監視システムにする。そのため、高度自動運転車両が社会に受け入れられるためには、信頼することができ、かつ、人が監視するADS/ADASの特徴を備えた車両よりも安全でなくてはならない。
【0052】
特許文献1に記載されたシステムは、所与の走行シナリオにおいて車両を自動的にナビゲートすることができるADS/ADASを備える車両を説明している。特許文献1によれば、ADS/ADASは、高性能計算ユニットと安全計算ユニットの二つのユニットを備える。両方のユニットは、専用のバス監視部を有するセンサと、それらのユニットとセンサとのインタフェースとしての二つのスイッチと、に接続されている。両方のスイッチは、各々のセンサのバス監視部に接続され、上記計算ユニットへのセンサデータ伝送要求のための複数の冗長性を提供している。
【0053】
計算システムは、伝送サイクルの多重インスタンスにおける計画された時間周期のそれぞれの発生頻度を調整するために、少なくとも部分的に伝送サイクルの長さに基づいて車両の通信ネットワークを構成する。計算システムは、ネットワーク帯域幅およびセンサデータ伝送遅延要求に基づいてセンサデータ伝送タスクを決定する。
【0054】
しかしながら、特許文献1は、センサデータ伝送遅延とネットワーク可用性との間のルール・ベース・マッチングに主に焦点を当てている。危機的な走行シナリオの場合、最小リスク操作を実行ためにセンサデータ要求の多重インスタンスが存在し得る。上記シナリオにおけるネットワーク・リソースの非可用性は、所与の期限時間センサタスクの達成/実行を遅延させ、危機的な状況につながるおそれがある。特許文献1に基づいて、提案されたネットワーク管理部は、純粋にルールベースであり、状況適応型ではないと結論付けることができる。
【0055】
新しいモジュール(スイッチのスイッチング周期を決定するネットワーク管理部)の主な貢献は、すなわち、計算システムの内部のネットワーク管理部が、ネットワーク帯域幅とセンサデータ伝送遅延要求のマッチングに基づいて、センサデータ伝送タスクを決定することである。センサデータは、種々のスイッチを経由して計算システムへ伝送されるので、この設計は、センサデータが計算ユニットに到達するための冗長化パスを提供するフェイル・オペレーショナル(故障時動作継続)の設計である。センサタスク期限/遅延要求およびスイッチ可用性に応じて、センサデータは、高性能計算ユニットまたは安全ユニットのいずれかに到達するために、スイッチ1または2を含むパスを取ることができる。特許文献1において、スイッチ1は、より小さい帯域幅の伝送路であることができ、スイッチ2は、より大きい帯域幅の伝送路であることができ、または、そのシステムの要求に応じてその逆であることができる。演算リソースの状態とスイッチに応じて、センサデータは様々な遅れで伝送される。
【0056】
しかしながら、特許文献1に記載された発明の主な欠点は、センサデータ・タスク・スケジューラ/ネットワーク管理部がルールベース・システムであることにある。このタスク・スケジューラは、利用可能な車載ネットワークを最適に利用することができない。このシステムは、全体的に状況適応型でもなく、リソースの可用性から生成された規定されたルールのドメイン内で調整することができる。このシステムは、安全状態に到達するためのタスク優先度を再構成することもできない。
【0057】
従来のタスク・プライオリタイズ/スケジューラは、タスクのリソース要求と、リソース可用性との間のマッチングを行う。リソース要求とリソース可用性とがマッチしない場合、タスク・スケジューラは、要求されたリソースが利用可能になるまで、そのタスクを停止する。そのため、ADS/ADASに含まれる従来のタスク・スケジューリング・システムは、利用可能なリソースの最適な利用を保証できないと結論付けることができる。
【0058】
ADS/ADASのためのランタイム・ダイナミック・タスク・オーケストレータを実行するために、タスク・リソース要求と可用性は、一致する必要がある。本実施形態の車両制御システムS111は、タスクのリソース要求が充足できない場合には、利用可能なリソースを最適に使用して車両SVが必要な最小リスク操作を常に実行できるようにするために、タスクの優先度を再構成することを提案する。すなわち、本実施形態に係る車両制御システムS111は、状況適応型のダイナミック・タスク・オーケストレータを含むことによって、特許文献1の上記の制限を克服することを意図している。
【0059】
本実施形態の車両制御システムS111は、前述のように、要求生成部RGと、可用性取得部AAと、優先度生成部PGと、実行管理部EMとを備えることを特徴とする。要求生成部RGは、車両SVを走行シナリオDSに従って走行させるためのタスクの要求を生成する。可用性取得部AAは、車載電気電子システムにおけるリソースの可用性を取得する。優先度生成部PGは、タスクの要求とリソースの可用性とに基づいてタスクの優先度を生成する。実行管理部EMは、優先度に従ってタスクを実行する。このような構成により、本実施形態の車両制御システムS111は、車載EEシステムS100のリソースを有効に活用して車両SVを安全に走行させることができる。
【0060】
また、本実施形態の車両制御システムS111において、実行管理部EMは、たとえば図10に示すように、タスクを実行不可と判定した場合に、車両SVの最小リスク操作を実行する。このような構成により、本実施形態の車両制御システムS111は、車載EEシステムS100のリソースを有効に活用して車両SVを安全に走行させることができる。
【0061】
また、本実施形態の車両制御システムS111は、車載EEシステムS100のリソースの最適な使用のためのリカバリーステップとして、タスクの期限時間/実行時間を変更することもできる。すなわち、一実施形態において、利用可能な限られたリソースを前提とする最小リスク操作を実行するために、タスク実行時間も変更することができる。リソース要求を削減してタスクを実行するために、異なるリソース性能を要求する補完認識タスクの情報を使用することができる。本実施形態の車両制御システムS111は、利用可能な限定されたリソースのドメインに含まれるタスク・プライオリタイゼーション/スケジューリングの補完タスク要求の情報を使用することができる。
【0062】
走行シナリオDSの情報を用いることで、理想的な優先度に基づくADS/ADASのシステム・タスク要求を生成することができる。本実施形態の車両制御システムS111は、演算リソースとネットワーク帯域幅の可用性も考慮する。リソースの可用性を監視するために、本実施形態の車両制御システムS111は、各アプリケーションの実行管理部EMを利用する。実行管理部EMは、リソースの配分と所与のアプリケーションのプロセスのスケジューリングを担う。
【0063】
各アプリケーションの実行管理部EMは、アプリケーションの従属関係も管理するとともに、従属するプロセス状況の稼働状況を確認する。これにより、各アプリケーションの実行管理部EMを監視することで、演算リソースのランタイムでの可用性およびネットワーク帯域幅の可用性が容易に監視できる。上述の二つの手順に従うことで、タスク要求とリソース可用性を適合させることができる。
【0064】
しかしながら、タスク・リソース要求とリソース可用性との間のミスマッチにつながり、そのミスマッチに対処しなかった場合に危険をもたらす複数のシナリオ/条件があってもよい。タスク・リソース要求とリソース可用性との間のミスマッチの場合におけるほとんどの利用可能な状況において、タスク・スケジューリングは、要求されるリソースが利用可能になるまで遅延する。これは、動的で危機的な走行シナリオの場合に、危険な状況につながる可能性がある。
【0065】
図4に示すゾーンベース車載アーキテクチャにおいて、ネットワークデータ伝送路のひとつが何らかの原因で故障した場合、限られたデータ伝送ネットワーク経路が利用できる。この場合、理想的な期限内にタスクが実行できないことが明らかである。これは、動的な危機的走行シナリオの場合に、危機的な状況につながりかねない。このような問題を解決するために、本実施形態の車両制御システムS111は、車両SVの挙動を変更することにつながるタスク実行時間を変更する。しかし、ADS/ADASは、危機的な走行シナリオにおいて、本実施形態の車両制御システムS111によるタスク実行時間に従うことで、最小リスク操作を実行することを保障できる。
【0066】
以上、図面を用いて本開示に係る車両制御装置の実施形態を詳述してきたが、具体的な構成はこの実施形態に限定されるものではなく、本開示の要旨を逸脱しない範囲における設計変更等があっても、それらは本開示に含まれるものである。前述の実施形態の機能および方法は限定ではなく例示である。また、前述の実施形態の特定の態様は様々な他の構成との組み合わせが可能であり、それらは本開示に含まれる。たとえば、前述の本開示に係る車両制御装置の実施形態では、車両として自動車を例に挙げて説明した。しかし、本開示に係る車両制御装置は、バス、トラック、建設機械、地表ロボット、倉庫ロボット、航空機、ヘリコプター、ボート、船舶、農機具、サービスロボット、列車、ゴルフカートや、その他の車両に適用することが可能である。
【0067】
前述の様々な実施形態は、たとえば、車両の自動運転システム(ADS)または先進運転支援システム(ADAS)のためのランタイム・ダイナミック・タスクオーケストレータに関する。本開示の背景にある主な目的は、たとえば、センシングタスク、認識タスク、計画タスク、行動タスクなど、ADSまたはASASの様々なタスクによる演算リソースの要求および可用性に応じて、それらのタスクのランタイム・タスク・プライオリタイゼーションを行うことである。また、上記したADSまたはASASのいくつかのタスクが、車内のEEネットワークにおける一定のネットワーク帯域幅を必要とする場合には、ネットワーク帯域幅もタスク・プライオリタイゼーションのために考慮する。
【0068】
本開示の主な貢献は、たとえば、所与の走行シナリオを安全にナビゲートするためのタスク/サービスの優先度および実行時間/期限時間の導出である。本実施形態に係る車両制御システムは、実行する必要があるタスク/サービスがリストアップされたら、運転シーンの要求から導出されたタスク/サービスによるネットワーク帯域幅および演算リソースの要求を確認する。その後、本実施形態に係る車両制御システムは、たとえば、タスク/サービス/アプリケーションの実行管理部により、ネットワーク帯域幅および演算リソースの可用性を確認する。この実行管理部は、タスク/サービスのスケジューリングとリソース配分を担う。最終的には、要求と可用性に基づいて、タスク/サービスの優先度が、ランタイムにおいて更新/再構成される。
【0069】
利用可能なネットワーク帯域幅および演算リソースによってタスク/サービスの実行時間の要求が達成できない場合、たとえば、それらのリソースの可用性および要求に適合するように、タスク/サービスの実行時間が更新される。このタスク/サービスの実行時間の更新は、車両の挙動も変更する。このタスク/サービスの実行時間の更新の背景にある主な考えは、たとえば、ADS/ADASの構成要素に障害が発生した場合に利用可能なリソースの最適に利用することである。車両が危険な状態または最悪の状態に陥ったときに、タスク/サービスの実行時間を変更するだけで安全性と快適性が保証できない場合には、安全な最小リスクの挙動、障害劣化挙動、または停止操作を保証するように、ADS/ADASのタスク/サービスの優先度を再構成してもよい。
【0070】
本開示は、ADS/ADASの状態および条件によって動作するタスク・オーケストレータを含み、車載EEネットワーク・アーキテクチャ(ドメインベースまたはゾーンベースのEEアーキテクチャ)に実装することができる。状態および条件によって動作する本実施形態のタスク・オーケストレータは、タスク・プライオリタイゼーションのために、他のドメインと連携する各ドメインにおいて分散システムとして使用することができる。
【0071】
本開示は、状況適応型のランタイム・ダイナミック・タスク/サービスの実行時間/期限時間の変更によって、完全または半自動車両の安全操作を向上させる方法論を提供する。状況適応型のランタイム・ダイナミック・タスク/サービス・オーケストレーションを実行するために、車両は、たとえば、道路トポロジ、建造物などの静的運転ドメインの特徴、その他の静的な特徴など、静的な操作運転設計ドメイン知識ベースの知識ベースを有してもよい。同様に、車両は、環境の状態、環境認識アルゴリズム制約、および追加的なスループットのための要求など、動的な操作運転設計ドメイン知識ベースの知識ベースを有してもよい。静的および動的な操作運転設計ドメインに基づいて、車両は、所与の危機的な走行シナリオにおいて、車両を安全にナビゲートするのに要求される、状況的かつ車両制御システムの状況ベースのタスク/サービスを導出してもよい。
【0072】
本実施形態の動的な状況適応型のタスク/サービス・オーケストレータは、最終的に、タスク/サービス・リソース要求と、車両制御システムのリソースの可用性とに基づいて、危機的な走行シナリオにおいて最小リスク操作を実行することが要求される車両の挙動の変更につながるタスク/サービスの優先度または実行時間/期限時間を変更する。主要目的は、いわば、自動運転システム(車両制御システム)が互いに頻繁に交信するいくつかのモジュールを備えることである。そのため、車両システムに含まれるいくつかのモジュールの統合と調整は、困難な課題である。さらに、各モジュールは、センサデータ、認識データ、計画データ、アプリケーション状況データなどを要求するいくつかのアプリケーションをさらに備えてもよい。このモジュールに含まれるすべてのアプリケーション、またはモジュール自体は、いくつかのリソース要求と、危機的な走行シナリオおよび車両制御システム状態を前提とする優先度とを有してもよい。これらのタスクの統合と調整の主な課題は、利用可能なリソースの状態を前提として、これらのタスク/サービスのランタイムの優先度と期限を適応させることである。
【0073】
すべてのモジュールは、共通のリソースを共有し、リソースの可用性に制限がある場合に競合状態の影響を受ける。そのため、本実施形態の車両制御装置では、主な目的は、車載EEリソースを最適に使用すること(高性能かつ最適なリソースの利用)である。また、広診断範囲および安全評価のためのサービス/データ伝送遅延の事前予測である。そして、最後に、タスクのランタイム中の動的な期限と優先度の調整である。たとえば、高速道路などの所与の走行シナリオにおいて、リソースの可用性応じて、車両は、自動走行、車線変更、低速自動走行、または安全停止などの機能を実行する。しかし、従来のタスク計画部では、リソースの可用性が制限されている場合、車両はルールに記述されたタスクを実行することができるだけである。しかし、本実施形態の車両制御システムは、制限されたリソースの可用性を前提とし、車載EEリソースを最適に使用して最適な安全操作を提供する。
【0074】
たとえば、車載EEネットワークは、多重のデータ伝送ネットワーク伝送路を有してもよい。データ伝送ネットワーク伝送路のひとつに障害が発生した場合、すべてのタスク/サービスは、利用可能なネットワーク伝送路を取らなくてはならない。そのようなシナリオでは、タスク/サービスの期限/実行の遅延が増加し、エラー/異常信号の生成につながる。しかし、本実施形態の車両制御システムは、そのようなシナリオに対処し、車両制御システムの安全監視部にリソースの制限された可用性による追加の遅延を通知する。上述の解決手段を適用することで、車両制御システムは最適なリソースの利用を保証することができる。さらに、タスク/サービスの期限/実行/遅延のランタイムでの推定は、車両制御システムの診断範囲の拡大に寄与する。
【0075】
本実施形態の車両制御システムの他の例では、異なるリソースを要求するいくつかの補完的なタスク/サービスを備える。たとえば、レーダ、LiDAR、カメラなどを用いた車両検知は、必要なネットワーク帯域幅が異なる。データの大きさに応じて、所定の時間期限内にセンサデータを演算リソースへ伝送するためのレーダのネットワーク帯域幅は、カメラと比較して大幅に小さい。レーダおよびカメラに基づく対象物の検知は実際には相補的であり、レーダで検知された対象物の情報は、カメラによるセンサデータのフィルタリングとサンプリングに使用することができる。上述の解決策に従うことで、サンプリング、トリミング、およびフィルタリングされたセンサデータは、未加工のカメラによるセンサデータと比較して、大幅に小さいネットワーク帯域幅を必要とするようになる。
【0076】
同様に、自動運転車両がいくつかのセンサ/情報を実際に相補的に使用する場合、リソースの可用性が制限されたシナリオでネットワーク帯域幅の要求を満足することができないタスク/サービスのネットワーク帯域幅の要求を、ネットワーク帯域幅を有効に利用して減少させることができる。他の例において、提案する最小限のリソースを要求する相補的なタスクの有効利用は、最適な電力利用にも使用することができる。高度自動運転車両の場合、フェイル・オペレーショナル(故障時動作継続)の車両制御システムを備えることができる。そのようなシステムは、常時動作することが要求される可能性がある全システムとしての追加の冷却装置を必要とする場合がある。
【符号の説明】
【0077】
AA 可用性取得部
DS 走行シナリオ
EM 実行管理部
PG 優先度生成部
RG 要求生成部
S100 車載EEシステム(車載電気電子システム)
S111 車両制御システム
SV 車両
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15