Close
必数百万ものシナリオをどのようにして作成するか？
テスト数の爆発的増大を避けるには？
テストの合格・不合格をどのように見分けるか？
必数百万ものシナリオをどのようにして作成するか？
テスト数の爆発的増大を避けるには？
テストの合格・不合格をどのように見分けるか？
必数百万ものシナリオをどのようにして作成するか？
自動運転のバリデーションが仮想環境上でしかテストできないほどに大量のシナリオを要することは既に認知されています。そしてこれだけの量のシナリオを手動で作成することが現実的でないことも明白です。
解決策の一つとして、現実世界のシナリオのレコーディングは助けになるでしょう。しかし必要なシナリオを全てレコーディングすることは経済的な観点から不可能です。また、多くの重要なシナリオはセーフティクリティカルな状況を含むため、現実世界で安全にレコーディングするのは困難です。
こういった課題を解決するためにOpenSCNERIO2.0等で言及された分類のシナリオ記述を目的とする高級言語の導入が試みられていますが、こういった言語の多くはテキストベースであるため、理解と利用が難しいことが問題となっています。
BTC Embedded Systemsは高度に抽象化されたトラフィックシナリオ向けの直感的かつグラフィカルな言語を使用して前述の課題に対処します。この言語は複数のフェーズで抽象的なシナリオを記述します。位置と距離を含むすべてのパラメータはその他の交通参加者との絶対値または相対値でパラメータ範囲として定義できます。グラフィカルな環境はシナリオの作成とレビュープロセスに多くの利点をもたらします。この言語は柔軟なツールの相互運用性のために今後のASAM Open SCENARIO 2.0 [6]規格との互換を目指しています。
これらの抽象シナリオは具体シナリオの自動生成および自動シナリオオブザーバを含む検証プロセスのサブシーケンスのすべてのステップの基礎となります。
シミュレーション環境にシナリオを持ち込む前に強力な制約ソルバを用いて定義されたシナリオの実現可能性を確認します。このプレシミュレーションにより、シナリオの動的な振舞いを可視化できます。もしシナリオの具体的なインスタンスを作成できない場合、パラメータ値と範囲の間の競合の可能性がレポートされます。その結果、実現不可能なシナリオが実行される前の非常に速い段階で検出され、時間とコストの節約に繋がります。
下図の例では自車が 40 km/h から 60 km/h の速度で走行しているフェーズを示しています。
フェーズ中、相手車両は自車の後方 0 m から 10 m の初期距離と自車の前方 0 m から 10 m の目標距離で右車線を通過します。
次に、それぞれが独自の最小の持続時間と最大の持続時間を持つ複数のフェーズが、1 つの抽象トラフィック シナリオに接続されます。 すべてのパラメータは値の範囲で定義できるため、各抽象シナリオは考えられる具体的なシナリオとシミュレーション実行のほぼ無限のセットを記述します。
上位の抽象シナリオからシミュレーション可能な具体シナリオに移行するには、抽象トラフィックシナリオに限定されない数多くのパラメータの値を定義しなければなりません。その対象は抽象シナリオに記載されたパラメータに限られません。他にもODD（Operational Design Domain）の適用範囲です。ODD は道路の種類や気象条件など、車両が運用されることになっている特定の運用条件を記述します。 しかし、どうすれば適切なテスト シナリオを生成できるのでしょうか?
Copyright © 2022 BTC Embedded Systems & BTC Japan
