【CTOブログ】自律走行車両カバレッジとパフォーマンス評価

2021.04.21

ブログ

自律走行車両カバレッジとパフォーマンス評価

by Yoav Hollander | 13 September, 2019 

概要:AV (Autonomous Vehicle、自律走行車両) の検証に携わる人は、遅かれ早かれ、カバレッジ、KPI (Key Performance Indicators)、パフォーマンス評価がどのように関係しているかという難しいテーマに遭遇します。また、「このシナリオは起こったのか」と「このシナリオでAVはうまく機能したのか」が混同されることもよくあります(「KPI」が両方の文脈で使われることがあるのも、さらに問題を大きくしています)。この記事では、これらすべてを明確にし、いくつかの(できれば有用な)用語を提案しようとしています。

シナリオに基づいて重大なAVの検証を行う際には、「現在の状況」を把握したいと思うことがあります。これには大きく分けて2つの部分があります。

  • カバレッジの評価。「シナリオ空間」のどの部分でAVを試行したのか。これはカバレッジと総合カバレッジ評点で表現されます。
  • パフォーマンスの評価。シナリオの中でAVがどのように動作したか?これは生の KPI (Key Performance Indicators) とコンテキストに依存したパフォーマンスグレードで表現されます。

カバレッジとパフォーマンスの評価指標はやや似ています(そのため、混同しやすい)。それゆえ、この記事を書いています。 

その前に、コンテキストを整理しておきます。

全体像

この記事では、ダイナミックな(主にシミュレーションベースの)AV検証について説明します。これは、検証作業を計画し、(通常は制約付きランダム手法を用いて)膨大な量のシナリオを実行し、その結果を分析し、それに応じてAVや検証環境を修正し、このプロセスを繰り返すというものです。 

なお、AVの安全性については、他にももっと多くのことがあります(セーフティケースの構築など、別記事 の最終章を参照)。単純化して言えば、安全担当者は単一の「残留リスク」の数値(例えば、1事故に対する重み付けされたマイル尺度)を導き出そうとしますが、これは非常に難しいことです。 

しかし、この記事はそのことについてではありません。ここでは、日々のAV検証のフローに焦点を当てます。 Figure 1は、その流れを1つの(少し密な)絵で表したものです。

カバレッジ全体像

Figure 1:検証実行フロー

各テスト (テストケースとも呼ばれます) は、実行する 1 つ以上のシナリオを指定することに注意してください。ランとは、テスト/実行プラットフォーム(SWシミュレーション、Hardware In the Loop、テストトラックなど)上で、(特定のランダムシードを使って)テストを実行したときに起こることです。 

後ろ向きの破線の矢印は、システムをより高いカバレッジとより多くのバグに向かわせる、人間による(そして時には部分的に自動化された)フィードバックループを表しています。 

このような全体像を理解した上で、カバレッジとパフォーマンスの測定基準に戻ってみましょう。

カバレッジ評価

 カバレッジ(特にシナリオ・ファンクショナル・カバレッジ)は、「これまでに何をテストしたか」、つまり、どのシナリオを実際にテストしたのか、そしてそのシナリオごとに様々なパラメータの値はどうだったのか、を測定するものです。 

なお、カバレッジを定義する際には、カバレッジ項目(パラメータ)を何にするか、各項目をどのバケット(値のグループ)に分けるか、どの項目をクロスさせるか、各バケットにどのような重みを与えるかを決めます。これらはすべて、何をテストする必要があるかを記述したトップダウンの検証計画に反映されます。 

カバレッジは通常、バケットあたりのヒット数で測定され、バケットあたりの希望ヒット数と比較されます。これを多数の実行で集計し、検証計画の階層でボトムアップ的に集計することで、0(何もカバーしていない)から1(完全にカバーしている)の間のトータルカバレッジグレードが得られます。

例えば、追い越しシナリオを2000回実行したものの、そのうち「overake_side == right」にヒットしたのは500回、「overtake_speed in [70..80]kph」にヒットしたのは90回で、これら2つのバケットのクロスバケット(sideがright、speedが[70..80]kphの追い越しシナリオ)にヒットしたものはなかったかもしれません。これらのバケットに与える重みによっては、これでは十分ではないと判断するかもしれず、その場合、そのカバレッジホール(テストギャップ)を埋める必要があります。 

さらに、入力カバレッジと出力カバレッジの項目がありますが、その区別はコンテキストに依存することに注意してください。例えば、他の車が私たちのAVを追い越す場合、overtake_sideとovertake_speedはどちらも入力項目です。しかし、自分のAVが他の車を追い越す場合(AVをコントロールできないと仮定した場合)、これらは出力項目となります(ただし、様々な方法で影響を与えることができるかもしれません)。 

カバレッジの定義(特にカバレッジバケットの定義)は、規律と直感を伴うマイナーなアートフォームです。目標は、与えられた(充実しているがまだまだ有限な)人的リソースおよびコンピュータリソースを利用し、運行設計領域 (ODD) で定義されたシナリオ空間の「検証」を最大化することです。これは、ODDの理解、「何が間違っているか」についてのこれまでの知識、その他多くの要素から得られるはずです。もし他にすることがなければ、この記事を読んでみてください。

パフォーマンス評価

パフォーマンス評価の目的は、(安全性、快適性など複数のパフォーマンス特性に沿って)そのランでAVがどれだけの性能を発揮したかを見ることです。 

また、多くの場合、 pass/failの指標が必要です。「十分に悪い」と思われるランに対しては、DUT (Device Under Test) に問題がある可能性を示すようなエラーメッセージを示したい、そのためには誰かがこのランをデバッグし、何かをする必要があるかどうかを決定する必要があります。 

KPI (Key Performance Indicators) とは、AVの性能を確認するために測定したい生の指標のことです。安全性に関するKPI(衝突までの時間を秒単位で表した min-Time-To-Collision (最小TTC) など)や、快適性に関するKPI(最大減速度をメートル毎秒毎秒単位で表したmax-decelerationなど)などがあります。

ここでは、様々なAV関連のKPIに関する多くの調査の1つを紹介します。なお、この分野ではいくつかの用語の違いがあります(例えば、安全関連のKPIに「クリティカリティ指標」という用語を使う人もいます)。 

あるシナリオを2000回実行したところ、 何らかの最小TTC の分布が得られたとします。最悪(最短)の最小TTC は0.7秒で、これはそのうち50回の実行で発生しました。この50回の実行でDUTエラーが発生するのでしょうか? 

必ずしもそうではありません。これはコンテキストによります。今回のシナリオが、非常に困難な状況下でAVの動作を試すものであれば、最小TTC が0.7秒というのは、実際にはかなり良い結果と言えるでしょう。逆に、まったく課題のないシナリオであれば、0.7秒はDUTエラーになるでしょう。

これにより、生のKPIからパフォーマンスグレードへと移行します。パフォーマンスグレード(「正規化された KPI」とも呼ばれる)は、コンテキストに依存した 0(「本当に悪い」)から 1(「優れている」)の間の数値で、DUT の動作のある部分に割り当てられます。このグレードは、1つ以上の生のKPIをコンテキストに依存した方法でグレードに変換するグレード計算式を使用して計算されます。これは大変な作業です。誰かが、検証タスクの仕様と関連する「コンテキストパラメータ」を考慮して、この式を書かなければなりません。 

シナリオランを、最小TTC、一般的な安全性(最小TTCグレードと他の安全性グレードの組み合わせ)、最大減速度、一般的な快適性などで採点したい場合があります。また、特定のグレードを組み合わせた総合的なパフォーマンスグレードをつけたいと考える人も多いです。 

そして、これらの各評点には(状況に依存した)閾値があり、これを下回るとDUTエラーとなります。

パフォーマンスの採点は以下にある様々なことに左右されます。 

  • KPIが測定されたシナリオ(上記の通り)。
  • テストの目的(例えば、SWの変更に関する開発者テストであれば、その変更に関連すると思われる劣化についてエラーメッセージを表示させたいと思うかもしれません)。
  • テスト対象のシステムの成熟度。一晩に1万回の失敗がある場合、「最悪の違反者」を最初に処理するために、閾値を高くしたいと思うかもしれません。
  • 安全性、合法性、快適性などの相対的な重み。
  • どの国にいるのか。 
  • 1本のランを採点できるのか(それともMCMCのような手法を使って多数のランを統合する必要があるのか)?
  • などなど 

AVのパフォーマンス評価は本当に難しいです。シナリオに依存しないインシデントアナライザーを使って、危機的な状況が回避可能かどうかを判断することもあります。また、確率的な要素をチェックすることには固有の難しさがあります(こちらの記事を参照)。しかし、誰かがやらなければなりません。

カバレッジとパフォーマンスの分析

これまで見てきたように、カバレッジとパフォーマンスの測定基準は異なるものですが、類似しています。テストの実行ごとに、以下のような詳細な情報をどこかに保存しておく必要があります。 

  • どのカバレッジバケットにヒットしたか? 
  • (生の、あるいは正規化された)様々なパフォーマンスパラメータの値はどうだったのか?

最後に(Fig. 1に示すように)、例えば先週末の100万回の実行で収集された以下のような測定基準を集約して表示する、複数ランの分析ツールが必要になります。

  • カバレッジ。
  • 現在のカバレッジグレードは(全体的に、特にシナリオSについて)?
  • シナリオSの主なカバレッジホールは何か?それらはどのように集まっているか(つまり、大きなカバーされていないエリアがあるか)?
  • パフォーマンス。
  • 最小TTC KPIの値は(全体的に、特にシナリオSについて)?それらは何か興味深い様子で集まっているか?
  • 最小TTCのグレードはどうか(全体的に、シナリオSについて)?前回のSWリリースと比較して、どこが悪いのか、どこが良いのか?
  • 実際にDUTエラーで失敗したラン(すなわち、グレードが閾値を下回ったラン)は何本あるか?それらはどのように集まっていますか?
  • これらすべての傾向は(前週に比べて)どうか?どの指標が向上し、どの指標が低下したか?

もちろん、カバレッジとパフォーマンスの指標については、もっとたくさんのことが言えますが、この記事は主に用語を明確にすることを目的としています。


この記事は、Foretellixによるブログ記事を、株式会社バーチャルメカニクスにて翻訳加筆修正したものです。原文はこちら

Foretellix製品についてはこちら

デモやお見積もりのご依頼はこちらから


※ 記載された会社名・商品名・製品名は、各社の登録商標または商標です

一覧へ戻る

ページトップへ