テクノロジプレビュー: 自動運転/ADASに向けたシナリオベースのバーチャルバリデーション

テクノロジプレビュー
自動運転/ADASに向けたシナリオベースのバーチャルバリデーション

Hans J. Holberg<br>Board Member<br>Business Development Autonomous Driving<br>BTC Embedded Systems AG
Hans J. Holberg
Board Member
Business Development Autonomous Driving
BTC Embedded Systems AG

過去数年にわたり、自動車産業はADAS/AD分野において自動運転レベル4及び5という目標の達成に向けた途方もない量の革新と発展を遂げました。しかしながら、特にシステムレベルのバリデーションに関しては、未解決の課題を残しています。

  1. 数百万にも及びシナリオを手動で作成することは現実的ではありません
  2. テストがどの程度完全であるかを評価するための手法、及び測定基準(メトリクス)が存在しません
  3. ホモロゲーションの課題に応える明確な戦略が存在しません

BTC Embedded Systems AGは同類の課題を"従来の"組み込みソフトウェア開発において解決して参りました。私たちはモデルチェッキング、自動テストケース生成、形式的要求記述、自動要求監視、といった技術のパイオニアです。これらの技術は今日において確立された手法として世界中のエンジニアの方々に利用されており、増大するシステムの複雑性に対処し、さらにISO26262を満たすことを可能にしています。

私たちはADASとADシステムのシステムレベル検証に対する同一のコアテクノロジの適用を進めています。抽象シナリオを定義するための直感的かつグラフィカルな言語に基づき、モデルチェッキングと人工知能(AI)を組み合わせて最適化された具体シナリオ群を生成します。生成された具体シナリオ群は仮想検証環境上で実行されます。さらに自動カバレッジ分析と自動合否判定はシナリオセットの完全性の測定を可能にし、ホモロゲーションプロセスに必要な論証の構築を補助します。

数百万にも及ぶシナリオを如何に作成するか?

自動運転産業において、自動運転のバリデーションが仮想環境上でしかテストできない大量のシナリオを要することは認知されています。しかし同時に、これだけの量のシナリオを手動で作成することが現実的でないことも明確です。

現実世界のシナリオのレコーディングは助けになるでしょう。しかし必要な量のシナリオをレコーディングすることは経済的な観点から不可能と言えます。そこでシナリオクラスの記述を可能にする高級言語の導入が試みられています。問題は、これらは通常テキストベースであるため、利用と理解が難しいことです。

この問題を解決するためにBTC Embedded Systems AGは直感的でグラフィカルな、抽象的な交通シナリオを記述するための高級言語を導入しました。この言語は抽象シナリオを複数のフェーズで表現します。それぞれのフェーズはグラフィカルな記法でモデリングされます。プリ・シミュレーション(pre-simulation)と呼ばれる機能は、記述されたシナリオが実現可能であることを確実にするためにシナリオの動的な振る舞いをビジュアル化します。これらの抽象シナリオはこの後に続く全ての段階のバリデーションプロセスの基礎となります。このプロセスには自動テストケース生成、自動シナリオ監視が含まれます。

独自仕様の言語であるにも関わらず、BTC Embedded Systems AGはOPENScenarioに完全互換の言語を目指し、関連するASAMグループの活動にも積極的に参加しています。

如何にして適切なテストケースを生成するか?

抽象的な上位のシナリオから具体的でシミュレーション可能なテストケースを得るために、私たちは大量のパラメータ群に対して値を決定しなければなりません重要な点の一つは、ODD(運航設計領域, Operational Design Domain)の網羅度です。ODDとは車両が運航されると想定される特定の運航条件(例えば、路面の種類、速度の範囲、天候条件、など)です。考えられるパラメータセットの量はほぼ無限であるため、全ての可能な組み合わせをテストすることはできません。一方で、ファジングのようなランダムアルゴリズムを用いたバリエーション戦略によって興味深くかつセーフティクリティカルなコーナーケースを網羅することはまず難しいと考えられます。

BTCはこの課題に対し、二つのアプローチを用いて対処しています。一つ目の段階は、パラメータ範囲の分割です。確率分布などのバリエーション戦略に従ってパラメータ範囲を管理し易いよう分割します。二つ目の段階では、これらの管理し易く分割されたパラメータ範囲をAIテクノロジを用いて探索します。この探索ではパラメータ制限範囲内でテスト対象のシミュレーションを繰り返し、テスト対象特有の"弱点"を検出します。この弱点探索の結果は、テスト対象をクリティカルな、または望まれない振る舞いへと導くテストケース、または確率論に基づく弱点不在レポートです。

このアプローチは余りクリティカルではない状況(例えば、全ての車両の距離が遠く離れている場合など)に対するテストケースの量を減らします。従って、テストケースの総量が爆発的に増えることはありません。

シミュレーションシナリオは本当に期待通りに振る舞うのか?

全ての交通参加者の振る舞いが事前に定義されているのであれば、シミュレーションが期待通りの振る舞いとなる可能性は非常に低くなります。これは、こういったシナリオはテスト対象及び他のトラフィック(例えば他の車両、歩行者、バイク、など)の軌道に関する推定や期待を含んでいるからです。一例は高度に自律的なシステムのバリデーションです。ここではテスト対象の軌道はテストケースで制御することはできません。期待する軌道と実際の軌道の間で生じるミスマッチは、これらの協調システムを意図した振る舞いに即して安定させるために、期待周囲のトラフィックの再調整を必要とします。

私たちはこの課題に対し、リアクティブ・トラフィック・コントロール(RTC)と呼ぶアプローチを用いて対処しています。RTCはソフトウェアのインテリジェントな部品です。RTCはテスト実行中にシミュレータによって実行され、トラフィックの振る舞いをエゴカーの振る舞いに合わせて調整します。これにより抽象的なシナリオで定義されたフェーズ群を全て確実に実現しようと試みます。

如何にしてテストの合格、不合格を知るのか?

従来の要求に基づくテストでは、テスト対象の入出力の振る舞いと期待値とを比較してチェックを行うことが一般的でした。それとは対照的に、ADAS/ADアプリケーションに対するシナリオベースのテストでは、トラフィックの状況とテスト対象の振る舞いをトラフィックルール、安全要求及びサービス品質ルール(例えば燃費に関する特定の目標)に基づいて監視するために、より洗練されたアプローチが求められます。テストが合格か、不合格かを判定するためには、これらのルールを組み合わせる(例えば、安全かつ法的責任に基づいているかを判断する)必要があります。

この問題を解決するために、BTCは必要なルールを直感的に記述するための専用のグラフィカル言語を提供します。この形式言語で記述されたルールからは、対応する監視ユニット(オブザーバ)を自動生成することが可能です。オブザーバはシミュレーション結果の自動分析に用いられます。

ホモロゲーションを可能にする十分なテストが実施されたか

自動運転車両に対するホモロゲーションを獲得するために、私たちはシナリオベースのバリデーション戦略の完全性を評価するための適切なメトリクスを必要としています。シミュレーションされた(または現実に運転された)総走行距離に基づくメトリクスは、経済的観点からも難しく、余り有用とは言えません。

代わりに、ADAS/ADシステムに求められる信頼性を示す実現可能な論法は、上述のメトリクスの複合に基づく必要があります。これにはシナリオカバレッジ、ODDや弱点検出のカバレッジが含まれます。

もし更なるお話にご興味がございましたら、お気兼ねなく私へご連絡ください。

Hans J. Holberg

holberg@btc-es.de
Connect with me on LinkedIn

日本語でのお問い合わせにも対応しております。

BTC Japan, 営業技術部 安藤 太一

taichi.ando@btcjapan.jp