自動運転システムのテスト言語は断片化されているため、自動車業界が協力して開発プロセスを加速することは困難です。オープンスタンダードは、安全性の懸念に対処しながら、OEM および自動運転プログラムの供給オプションを拡大します。オープンスタンダードのような標準がなければ自動車メーカーはベンダーとの連携に縛られる事になり、さらにツールの機能を拡張する際などにベンダー間でのシナリオ記述言語やデータ注釈形式が異なるため、課題に直面します。また、開発チームが安全性の期待に応えるために各ソフトウェアコンポーネントを評価する方法を個別に定義し、それを現実環境に対応した製品に変換する必要がある場合も、非常に非効率的です。 ADASや自動運転開発に時間とリソースを必要とする場合、開発者がセーフティクリティカル システムを評価するための共通スタンダードを持つことは理にかなっています。
オープンスタンダードは、システム間の相互運用性を保証することでより迅速な統合を可能にし、自動運転プログラムが同じ組織内のチーム間、および OEM、サプライヤー、規制当局などの異なる組織間で再利用、共有、およびコラボレーションできるようにします（表1）。
自動車業界は、オープンスタンダードのアイデアを受け入れているように思われます。近年、OpenX や OSI 標準などのシミュレーションのかなりの部分が、民間企業から将来に向けてこれらの基準の定義を推進する非営利団体 Association for Standardization of Automation and Measuring Systems (ASAM) に移管されました。これは、独立系企業に対する業界のサポートを示しています。
当社は、シミュレーションテストのオープンスタンダードのサポーターであり、ASAM スタンダードと緊密に連携しています。このブログでは、シミュレーションのオープンスタンダードの現在の状況、それらの制限、およびこれらのスタンダードの将来の範囲について述べています。また、当社のオープンスタンダードに関するツール開発へのアプローチも共有しています。
現状
ASAM OpenX スタンダードは、共同シナリオベースのテストワークフローを円滑に進めます。（図1）。目的は、シナリオの仕様、テストの説明、シミュレーション、シミュレーションテストからのオブジェクトデータのラベル付けなど、エンドツーエンドの検証ワークフローを促進し、データの取得を交換可能にすることです。さらに、これらのスタンダードは OpenX Ontology プロジェクトによってサポートされており、すべてのスタンダードが同じ言語で全体的なドメインモデルを作成します。
表2は、シミュレーションテストで一般的に使用される OpenX プロジェクトの概要を示しています。
.png)
現状のスタンダードの制限
現在 OpenX 標準のセットは、自動運転性の低いユースケースのニーズを満たすように設計されており、これらの標準が複雑なシステムアプリケーションに役に立つにはいくつかのギャップがあります。
たとえば、現在の OpenDRIVE 形式の標準には、使用を困難にするいくつかの不整合と未定義の変換ヒューリスティックがあります。たとえば、標準の車線定義スキーマでは、HD マップ形式を OpenDRIVE 形式に変換する際に、実際の道路の参照しているトラックを特定することが困難になります。現実的な道路（特に複雑なジャンクション）は、標準で利用可能なジオメトリの限られたサブセットのみで制限するのが難しい場合があります（図2）。このような場合、レーンを高解像度マップから OpenDRIVE が提供するジオメトリで厳密に近似できるチャンクに分割するには、広範囲での補間と最適化が必要です。ただし、補間以後は元の HD マップの各ポイントを正確に表さないため、OpenDRIVE 形式では車線表現の精度が失われ、シミュレーションでのマップの忠実度が低下します。道路の標高と交差点についても同様の問題が見られる場合があり、どちらも参照曲線に関連するパラメーター化された関数として表されます。
現在の OpenSCENARIO 1.0 は、シミュレーションツールの下層レベルの仕様フォーマットをサポートしています。現在の状態では抽象的な定義がなく、操作と認識が十分に指定されておらず、シナリオの成功基準の定義が欠落しているため、複雑な自動運転のユースケースにスタンダードを適用することは困難です。自動運転の今日のテスト要件では、ペガサスプロジェクトによって提案された機能から具体的なシナリオのワークフローを可能にするため、パラメータースペースを使用したより高いレベルのシーンの説明と表現が必要です。操縦に関しては、OpenSCENARIO 1.0 はビークルダイナミクスなどの領域で仕様が曖昧で、アルゴリズムとモデルの異なった忠実度が使用される可能性があるため、異なるシミュレーター間で同様の状態軌道を確保することは困難です。同様に、OpenSCENARIO の認識言語の仕様も不十分です。グラフィック、トラフィック、センサーなどの Visibility Action Class の既存のフィールドには、それらの使用目的についてほとんど説明がありません。認識モデルの仕様は、変化する環境やシーンに応じてアクターの一貫した動作を保証するために必要です。最後に、現在のシナリオには明確な成功基準がありません。これは、自動運転システム評価のコンテキストで定義する必要があります。シナリオテストの失敗は、問題のあるソフトウェアが実稼働車両に展開されるのを防ぎますが、シナリオの成功または失敗をエンコードするための言語がなければ、スタンダードの価値はかなり制限されたものになる可能性があります。
さらに、認識システムの基本的な構成要素であるトレーニングおよびテストデータセットの分類と説明にもかかわらず、業界で共通のオブジェクトまたはシナリオのラベル付けに対してのスタンダードはありません。標準化されていないため、さまざまな自動運転システムによる周囲の解釈の違い、組織間でデータを共有できない、データアノテーションの品質の低下など、さまざまな問題が発生します。 OpenLABEL は、アノテーションの方法論、構造、および記述言語を標準化するために開始された取り組みです。
今後の展開
シミュレーションテストの仕様基準を改善するための努力が進行中です。マクロレベルでは、プロジェクトチームは、より高いレベルの自動運転に必要な機能の改訂に取り組んでおり、シミュレーションベースのテストツールをさらに民主化するための新しいスタンダードと概念を模索しています（表3）。
当社のオープンスタンダードへの取り組み
当社のシミュレーションツールは、OpenDRIVE、OpenSCENARIO、OSI、FMI などの既存スタンダードの多くをサポートしています。前述のように、これらスタンダードの現在の範囲は特定のユースケースに焦点を合わせており、さまざまな ODD で動作する自動運転プログラムで安全ケースを作成するために必要なすべてのテストシナリオを網羅しているわけではありません。したがって、当社は、スタンダードが基準となるまでの間、幅広いユースケースをカバーするために現在のスタンダードを超えたサポートを開発しました。 これらのスタンダードの進化を綿密に追跡しており、スタンダードに対するサポートは、スタンダードがより明確になるにつれて拡大し続けます。さらに、当社のシナリオ API は、OpenScenario2.0 以降を含む機能的なシナリオ定義をサポートします。シナリオ API を含む当社のツールの詳細については、エンジニアリングチームまでご相談ください。
.webp)
.webp)
