高度な自動運転のための機能はAIを用いて重要な交通状況を自動検出して生成

未来の自律走行車は、重要な瞬間に安全に反応できなければならない。そのため「ポルシェ・エンジニアリング」は、今日すでにそのようなシナリオで、集中的にシミュレーションしている。その際、エンジニアは車間距離を縮めるなどして、特にクリティカリティを高めている。

ポルシェ・エンジニアリングのAIおよびビッグデータ部門責任者であるヨアヒム・シャパー博士と、ポルシェ・エンジニアリングのシミュレーション部門責任者であるティレ・カロライン・ルップ氏は、「私たちは、高度な自動運転のためのドライバーアシスタンスシステムや機能の検証を可能にする、クリティカルなシナリオの完全なカタログを構築しています」と説明する。

「私たちは現在、道路利用者のカテゴリーが長い間目撃されていない場合でも、道路利用者を認識し続ける方法を開発しています」とは、ポルシェエンジニアリング博士候補生で、画像認識のスペシャリストのレオン・アイゼマン氏だ。

このバーチャルテストは、「AVEAS研究プロジェクト」、ドイツ語のAbsicherungsrelevante Verkehrssituationen erheben, analysieren, simulierenの頭文字をとったもので、「検証に関連する交通状況の収集、分析、シミュレーション」を意味する。テストはこの一環だ。ポルシェ・エンジニアリングのほか、フラウンホーファーの研究機関やカールスルーエの企業understand.aiなど、20のパートナーが参加している。

【写真12枚】テストドライブも自動に!?  技術が事故を無くしていく世界へ 

シミュレーション可能なシナリオ
AVEASは、データ不足という自律走行への大きなハードルを取り除くことを目的としている。高度な自動運転の機能を検証するためには、理論上、何十億キロものテスト走行が必要となる。これには膨大な時間と費用がかかるため、実際の走行はシミュレーションで補完される。

しかし、重要な交通状況では、シミュレーションのための実際の基礎データが不足しているため、これは特に困難である。AVEASはこのギャップを埋めることを目的としている。このプロジェクトの目的は、テストドライブを自動的に評価し、危機的な交通状況をシミュレーションシナリオとして用意することだ。

ポルシェエンジニアリングは、このプロジェクトに多くの重要なコンポーネントを提供している。たとえば「JUPITERテスト車両 (Joint User Personalized Integrated Testing and Engineering Resource)」が、テストドライブ用に提供されている。

JUPITERにはカメラ、レーダー、ライダーセンサーが装備され、計測したデータはクラウドに送信され、ポルシェ・エンジニアリングが評価も行うという。アルゴリズムが自動的に道路のコース、他の道路利用者の位置、道路利用者の行動を記録する。使用される機械学習手法は常に改良されている。

ポルシェ・エンジニアリングの画像認識のスペシャリストで博士課程に在籍するレオン・アイゼマン氏は、「私たちは現在、たとえばトラックの陰に隠れて長期間道路利用者の姿が見えない場合でも、道路利用者を認識し続ける手法を開発しています」と語る。

記録された交通イベントは、「ASAM OpenDRIVE (道路ネットワークの論理的記述)」や「ASAM OpenLABEL (オブジェクトとそのダイナミクス)」といった標準化されたファイル形式で保存される。そのためAVEASは、ルートモデリングなど、ほかのプロジェクトにもインプットを提供することができる。第2ステップでは、アルゴリズムがたとえば短いクリアランスや異常に強い減速力に着目して、重要な交通状況を選択する。

「私たちは、高度に自動化されたドライビングのためのドライバーアシスタンスシステムと機能の検証を可能にする、重要なシナリオの完全なカタログを構築しています」と、ポルシェエンジニアリングAI・ビッグデータ部門責任者であるヨアヒム・シャパー博士、ポルシェエンジニアリング シミュレーション部門責任者のティレ・カロライン・ルップ氏は言う。

「クリティカリティの度合いは、後でテストするドライビング機能によって異なります」と、ポルシェ・エンジニアリングのシミュレーション分野で博士課程に在籍するニコール・ナイスは強調する。たとえばアダプティブ・クルーズ・コントロール(ACC)を検証する場合、渋滞の最後尾に差し掛かる前に急ブレーキをかける必要があるかどうかが、クリティカルシナリオに該当する。

環境要因もクリティカル・シナリオの引き金になるからだ。たとえば、車両がトンネルの出口に近づくと、まぶしくて車載カメラが眩しくなることがある。しかし自律走行車は人間のドライバーと同じように冷静に反応する必要があり、たとえば速度を落としたり、ほかのセンサーを優先させたりする。

まず、(シミュレート可能な)走行シナリオは、道路利用者から時間をかけて得た位置データで構成される。専門家はこれを「軌跡ベース」の記述と呼ぶ。運転シナリオをシミュレーションの後半で変化させるためには、抽象的な用語で記述する必要がある。

このため「車両が交差点で停止し、再び発進する」といったように、個々の軌跡からメタ・プロセスが導き出される。このシナリオは、仮想コースの任意の出発点に追加することができ、後で修正することも可能である。

テスト空間の拡張
バーチャルテスト走行は、PEVATeC SimFramework(ポルシェエンジニアリングバーチャルADASテスティングセンターシミュレーションフレームワーク)として知られる、社内で開発されたシミュレーション環境で行われる。実際の走行を再現(シミュレート)し、特定の変更を加えた後に再生することができる。

「シナリオ・サンプリングと呼ばれる手法では、実際のクリティカルな状況を体系的に変更することで、仮想検証テスト空間を人工的に拡張します」とルップ氏は説明する。

たとえばカットイン操作では、より高いカットインスピード、より短いクリアランス(タイムヘッドウェイ)、あるいは濡れた路面などの悪環境条件など、さまざまなパラメータで何千回も繰り返すことができる。このようにパラメータを変化させることで、渋滞の最後尾にぶつからないように急ブレーキをかけるなど、安全上の理由だけで、実際には走行できないようなテストシナリオを作成することもできる。

最後のステップでは、合成限界シナリオを使用して、問題のドライビングファンクションを検証し、最適化。この目的のために、ポルシェ・エンジニアリングはJUPITERテスト車両のデジタル・ツインを構築している。「このデジタルJUPITER”には、実車と同じインターフェースとセンサーが搭載されています」と、ポルシェ・エンジニアリングの博士候補生であり、シミュレーション分野のスペシャリストプロジェクトエンジニアであるデイヴィッド・ヘルマン氏が説明する。

さらに「すべての機能を一対一でテストすることができます」とも説明する。ポルシェエンジニアリングは、AVEASの枠組みの中で、アダプティブクルーズコントロール機能とパーキング機能(リバースアシスト)の評価と最適化にデジタルJUPITERを使用する予定だ。

初の特許出願
実際のテストドライブとバーチャルなテストドライブを一致させるためには、多くの経験が必要となる。「必要なのは、現実のテクノロジーとシミュレーションがどのように関連しているかを深く理解することです」とシェーパー氏は強調する。

たとえばバーチャル車両は、アナログモデルと同じように異なる路面に反応しなければならない。2021年12月にスタートしたこのプロジェクトは、すでに最初の成果を出している。「プロセスチェーンには多くのリンクがあり、テストドライブが進行中で、すでにいくつかの特許が申請されています」とポルシェ・エンジニアリングのAVEAS参加をコーディネートするミヒャエル・シュトロベルト氏は言う。

しかし、基礎的な作業には課題もある。博士号候補者のアイゼマン氏が強調するように、「変動性の高い現実をマッピングするのは難しい」のだ。検出アルゴリズムは、ドイツの車両だけでなく、世界中の車両を識別できなければならないからだ。「インターフェイスの管理も大きな役割を果たします」と、同じく博士号取得を目指すナイス氏は付け加える。

AVEASのパートナーは異なる情報源からデータを提供しているため、情報の交換には正確な調整が必要である。例えば、ドイツ南部のカールスルーエ工科大学は道路の航空写真を提供しており、これらもデジタルシナリオの構築に組み込まれた。

AVEASは2024年末まで稼働する予定であり、その頃には走行シナリオ評価のためのスケーラブルなパイプラインが整備されているはずである。どちらも、将来の開発作業を大幅に加速させる可能性がある。ルップ氏は長期的なビジョンを次のように語った。「シナリオはテスト走行中に生成され、運転機能を最適化するためにシミュレーションで即座に使用されます」。検証後、無線アップデートで車両にシナリオを追加することができる。

ルートモデリング – 世界の正確なマッピング
シミュレーションには、道路利用者が移動でき、相互作用できる世界が必要となる。「ルートモデルがなければ、バーチャルテストドライブはできません」とポルシェ・エンジニアリングのシミュレーション担当、ティレ・カロライン・ルップ氏は言う。

ルートモデルは専門用語で”シーン”と呼ばれ、走行エリア(道路、駐車スペース)と周辺エリアの両方を描写する。ルートモデルは、OpenDRIVEフォーマットの道路ネットワークの数学的モデルと、オブジェクトの正確な外観と材質を記述する3Dモデルで構成される。市販のナビゲーション・システムで使用されているようなデジタル地図は、正確さや詳細さが十分ではないのだという。

「たとえば、車線の幅や道路標識に関する情報が不足しています」と、シミュレーション分野の開発エンジニアで、ルートモデリングを担当するトビアス・ワツル氏は説明する。タスクに応じて高解像度の地図、自由に利用できるOpenStreetMapの素材、標高モデルなどを組み合わせることができる。

「必要とされる大量のテストキロメートルを適切な時間枠でバーチャルにマッピングできるようにするため、高度に自動化された独自のルートモデリング・プロセスに取り組んでいます」とルップ氏は付け加える。作成プロセスにおける自動化の度合いは、常に高まっている。

AVEASプロジェクトの一環として、使用されているJUPITER試験車両は、測定データをルート・モデリング・プロセスに送り込んでいる。ライダーセンサーを使って周囲をスキャンし、得られた点群をクラウドに転送する。道路標示はアスファルトとは異なる反射をするため、ライダー・データで簡単に識別できる。

特別なアルゴリズムが、個々のマーカーから連続した全体のラインを計算する(このプロセスは、個々のマーカーが欠落している場合でも機能する)。その結果、OpenDRIVEフォーマットで、実際の道路の正確な地理参照画像が得られる。これは、特定の実際の道路(2車線の高速道路の10km、など)に基づいていない一般的な路線モデルと対照的だ。路線モデリングには高い精度が要求されるのだ。

決定された道路形状はセンチメートル単位まで正確でなければならず、そうでなければ、あとで車線変更をシミュレートするときに車間距離が正しくなくなる。OpenDRIVE形式の道路は数学的な関数として記述されるため、不連続な部分が生じ、それがシミュレーションでは道路の「急カーブ」として現れることがある。このような不連続面は補間しなければならないのだ。