OpenSCENARIO V2.0は、2021年11月のリリースを予定しています。ASAM（Association for Standardization of Automation and Measuring Systems）は、先進運転支援システム（ADAS）や自律走行車（AV）の開発において、動的な内容のシナリオを記述するための規格として、OpenSCENARIO V2.0を開発しています。以下のブログ記事では、抽象的なシナリオ、論理的なシナリオ、具体的なシナリオの違いや、OpenSCENARIO V2.0とは何か、なぜAVやADASの開発に重要なのかを説明しています。また、Applied Intuitionの検証ツールValidation Toolset*により、シミュレーション運用・テスト・検証チームが、OpenSCENARIO V2.0の抽象的なシナリオを編集したり、論理的なシナリオを作成したりできるようになることも説明しています。
はじめに
抽象的、論理的、具体的なシナリオ
シナリオとは、ADASやAVの試験・開発におけるシミュレーションの動的な内容のことです。シナリオは、自動運転システムの安全性をテストし、検証し、認証する上で重要な役割を果たします。機能要件を検証するためには、シミュレーションの運用・テスト・検証チームは、膨大な数のパラメータ空間に対してテストを行う必要があります。このパラメータ空間を自律走行システムのオペレーショナルデザインドメイン（ODD）に限定することで、システムの完全なテスト空間を定義することができます。PEGASUSメソッドでは、自律システムを十分にテストするために、抽象度の異なるシナリオを使用することを推奨しています。
例えば、「対向車が来ているにもかかわらず、自律走行車（自車両）が一時停止のない左折を成功させる」という機能要件があります。この要件を検証するために、チームはまず、いくつかの抽象的なシナリオを作成します。抽象的なシナリオとは、人間や機械が読める高レベルのシナリオの記述です。例えば，一時停止のない左折を行う抽象的なシナリオでは，「自車両は1〜3車線の直線的な交差点にいて，一番左の車線に位置しており，その速度は周囲の交通よりも速いか遅いかのどちらかである」という内容になっています（図1）．
次に、シミュレーションの運用・テスト・検証チームは、パラメータの分布を示す論理的なシナリオを用いて、関連するシナリオパラメータの完全なテスト空間を定義します。例えば、一時停止をしないで左折する際の車両の速度は10～20m/s、交通速度も10～20m/s、自車と対向車との間隔は20～40mであるという論理的なシナリオを設定します。
最後に、シミュレーションの運用・テスト・検証チームは、各論理シナリオから具体的なシナリオを導き出す必要があります。具体的なシナリオとは、定義されたパラメータ値の範囲内で実行可能なテストであり、チームはこれをシミュレーションして、テスト基準の合否を判断します（図2）。具体的なシナリオとは、例えば、「自車両と交通速度がともに13m/sで、自車両と対向車の間の距離が30m」というようなものです。
抽象的なシナリオと論理的なシナリオを作成することのメリットとデメリット
上記のようなアプローチには利点と欠点があります。抽象的なシナリオを作成し、それらの抽象的なシナリオから論理的で具体的なシナリオを導き出すことは、高速でスケーラブルですが、しばしばノイズが発生します。別のアプローチとして、抽象的なシナリオの作成を省略する方法があります。ここでは、シミュレーションの運用、テスト、または検証チームが直接、論理的なシナリオを作成し、そこから具体的なシナリオを導き出します。このアプローチでは、より正確で詳細な情報を得ることができますが、拡張性は高くありません。
抽象的なシナリオを作ることのメリット
- スピード：要件をフルテストスペースでテストするのは、時間とリソースがかかります。高レベルの抽象的なシナリオを作成し、その抽象的なシナリオから検証・妥当性確認（V&V）ツールが論理的で具体的なシナリオを自動的に生成することで、ADASやAV企業は要件検証プロセスを高速化することができます。
- スケーラビリティ：高レベルの抽象的なシナリオを作成することで、シミュレーションの運用、テスト、検証チームは、特定の要件のパラメータ空間全体を容易にカバーし、他の多数の要件に対してもプロセスを繰り返すことができます。
論理的なシナリオを直接作成することのメリット
- 精度。論理的なシナリオを作成する際、シミュレーションの運用、テスト、検証チームは、正確なパラメータ空間を定義し、きめ細かな調整を行うことができます。この高い精度は、作成されたシナリオが決定論的であることを保証します。また、現実の世界でテストしたり、再現したりしたい特定のシナリオのバリエーションを作成することもできます。
- コントロール。論理的なシナリオを直接作成することで、チームは無効なシナリオや非現実的なシナリオ、つまり現実には起こり得ないシナリオを除外することができます。また、考慮しなくてもよいシナリオの組み合わせを避けることもできます（図3）。抽象的なシナリオによって生成されたパラメータ空間全体を実行することは、特に多くのシナリオがノイズだらけで考慮しなくてもよい組み合わせである場合には、計算効率が悪いので、これは有益です。
ADASやAV業界で成功している企業は、この2つのアプローチを適切に使い分けています。抽象的なシナリオ作成と論理的なシナリオ作成に関するApplied Intuitionの考え方については、このブログの後半で紹介します（「Applied Intuitionの考え方」参照）。
適切な手法を手に入れたとしても、シナリオの作成とテストで最も困難なことの一つが残っています。多くのADAS/AV企業は、要求検証のワークフローの各部分に異なるツールを使用しています。例えば、システムエンジニアチームは機能要件を定義するために1つのツールを使用し、シナリオ作成者は抽象的または論理的なシナリオを書くために別のツールを使用し、テストエンジニアは具体的なシナリオをシミュレートするために3つ目のツールを使用する場合があります。異なるツール間でシナリオを移行・翻訳することは、非常に困難で時間のかかる作業です。ASAMのOpenSCENARIO規格は、この問題を軽減します。
ASAM OpenSCENARIO V1.0の制限事項
2020年3月にOpenSCENARIO V1.0がリリースされました。これは、シミュレーションの運用、テスト、検証の各チームが、動的な内容を持つ具体的なシナリオを、XML形式を用いて標準的な方法で記述できるようにする規格です。OpenSCENARIO V1.0は、ベンダーを問わず、ツール間での具体的なシナリオの移行を容易にするため、これらのチームにとって有用なものとなっています。
しかし、OpenSCENARIO V1.0では、ADASやAV企業は具体的なシナリオを記述することしかできず、抽象的なシナリオや論理的なシナリオは記述できないため、その恩恵は低レベルのオートノミーのユースケースに限られていました。シミュレーションの運用、テスト、検証チームは、OpenSCENARIO V1.0を使用して、1回限りの具体的なシナリオをゼロから作成し、それを実行して機能要件の合否をテストすることができます。しかし、テスト範囲を拡大し、自動運転システムのセーフティケースを構築するためには、テスト空間全体をカバーする可能なすべての具体的シナリオを手動で作成する必要があります。これには時間がかかり、ミスも起こりやすく、実際には不可能です。結局、抽象的なシナリオから具体的なシナリオをプログラムで導き出すか、論理的なレベルでシナリオを定義するかのどちらかしか実行可能なソリューションはありません。OpenSCENARIO V1.0は、抽象的なシナリオと論理的なシナリオの標準を提供していないため、企業は上述したようなツール間の移行問題に直面します。
OpenSCENARIO V1.0のもう一つの欠点は、人間の読みやすさに最適化されていないXML形式を採用していることです（図4a）。そのため、多くのシミュレーション・ソフトウェア・プロバイダーは、より読みやすい独自のシナリオ言語を開発しています（図4b）。
ASAM OpenSCENARIO V2.0：高い抽象度とツール間の互換性
OpenSCENARIO V2.0は、2021年11月のリリースを予定しています。OpenSCENARIO V2.0は、OpenSCENARIO V1.Xと並行して存在し、将来的には両者を統合する予定です。OpenSCENARIO V2.0は、OpenSCENARIO V1.0が抱えているツール間の互換性や可読性の限界を緩和することを目的としています。
ツール間の互換性を高めるために、OpenSCENARIO V2.0は抽象的、論理的、具体的なシナリオをサポートします。これにより、異なる抽象度のシナリオをツール間で容易に移行できるようになります。また、OpenSCENARIO V2.0は、より幅広いAV開発のユースケースをカバーすることができるようになります。シミュレーション運用、テスト、検証チームは、抽象的なシナリオを定義し、その抽象的なシナリオから論理的、具体的なシナリオを導き出すことで、機能要件を検証できるようになります。すべての抽象化レベルは、同じ標準化された言語を使用し、ツール間で簡単に移行できるようになります。
OpenSCENARIO V2.0では、シナリオを読みやすくするために、DSL（Domain Specific Language）を提供します。DSLとは、表現力が制限された、特定のドメインに特化したプログラミング言語のことです。OpenSCENARIO V2.0では、従来のようにXMLフォーマットに従う必要はなく、シナリオを記述するために特別に設計・最適化された言語を使用します。
Applied Intuitionの取り組み
OpenSCENARIO V2.0がリリースされると、Applied Intuitionのエンド・ツー・エンドV&VツールであるValidation Toolsetは、シミュレーション・オペレーション、テスト、検証チームがOpenSCENARIO V2.0の抽象的シナリオを作成、閲覧、編集できるようになります。これにより、OpenSCENARIO V2.0の抽象的シナリオの作成を計画しているシミュレーション運用・テスト・検証チームや、ツール間での抽象的シナリオの移行方法を探しているチームをサポートします。Validation ToolsetはOpenSCENARIO V2.0に対応することで、OpenSCENARIO V2.0規格に対応したシミュレータなどの他のツールとも互換性があります。
Validation Toolsetは、OpenSCENARIO V2.0の抽象的なシナリオをサポートするとともに、シミュレーションの運用、テスト、検証チームが、Applied Intuitionのシナリオ言語Object Sim*を使用して、自動生成された論理的および具体的なシナリオを編集できるようにします。また、抽象的なシナリオを事前に作成することなく、論理的、具体的なシナリオをゼロから作成することも可能になります。
ここでは、Validation ToolsetでOpenSCENARIO V2.0のアブストラクト・シナリオを作成するためのワークフローを紹介します（図5）。
- システムエンジニアは、Validation Toolsetで機能要件を定義することができます。
- シナリオ作成者は、機能要件からOpenSCENARIO V2.0の抽象的なシナリオを作成・生成することができます。
- これらの抽象的なシナリオから、Validation Toolsetは論理的、具体的なシナリオを自動的に生成します。論理的、具体的なシナリオを作成するために、Validation ToolsetはObject Simシナリオ言語をサポートしています。
- テストエンジニアは、自動生成された具体的なシナリオをObject Simのシナリオ言語を使って簡単に編集することができます。
- Validation Toolsetは、自動生成された具体的なシナリオを機能要件にリンクし、エンドツーエンドのトレーサビリティを実現します。
- Applied IntuitionのVerification Packsは、一般的なシナリオや規制要件に関連するシナリオを容易にカバーし、特定のODDで自律システムを検証するためのプロセスを補完します。
OpenSCENARIO V2.0をサポートするためのApplied Intuitionの計画については、エンジニアリングチームにお問い合わせください。
*注：Validation Toolsetは以前はBasis、Object Simは以前はSimianと呼ばれていました。
.webp)
.webp)
