ギャップを埋める：自動運転車の安全性を高めるスマートなODD カバレッジ

運用設計領域 (ODD) は、自動運転車が安全に走行できる正確な条件セットを定義します。これには天候、照明、道路タイプ、速度制限などが含まれます。ODD は自動運転車技術の検証と妥当性確認における中核概念であり、エンジニアにシステム能力と安全保証の明確な境界線を提供します。

以前のブログ記事で、Applied Intuition は ASAM OpenODD や Pegasus といった標準規格からの知見を活用し、実世界でのテストから学びながら、チームが ODD を作成・改良する方法を説明しました。その記事では、ODD は静的なものではなく、新たなデータが収集され、予期せぬ事象が発生するにつれて、現実世界に追いつくために進化しなければならない点が強調されました。更新を重ねるごとに、日常の運転の複雑さや自動運転車が直面する運用上の実態をより的確に捉えられるようになります。

しかし、ODD の定義は始まりに過ぎません。自動運転車のテストを進める中で、重大な課題が生じます。ODD 内の重要なシナリオがすべて確実に網羅されていることの確認と、テストが十分であることの判断です。これにより、二つの重要な疑問が浮かび上がります：

• 「どこでもっとテストするべきか？」
• 「いつテストが十分と言えるのか？」

これらの疑問は ODD カバレッジ分析の核心であるため、今回のブログで詳しくカバーします。

ODD カバレッジ分析の理解

ODD カバレッジ分析とは、自動運転車のテストにおいて、ODD で定義された条件と状況がどの程度探索的に検証されているかを評価するプロセスです。単に車両の走行想定範囲を列挙するだけでなく、システムが実際にそれらの状況すべてにおいて検証されているかどうかを検証します。この分析は安全性にとって極めて重要であり、一般的なケースだけでなく、ODD のエッジケースやコーナーケースにおいても、車両が期待どおりに動作することを保証する上で役立ちます。

効果的な ODD カバレッジ分析は、一度きりの作業ではなく、循環的なプロセスです。実車走行、シミュレーション、またはクローズド トラック テストの各ラウンドでデータが生成され、エンジニアはそれをレビューしてカバレッジのギャップや未検証の属性と条件の組み合わせを特定します。ODD が進化するにつれて、カバレッジ分析の焦点も変化し、新たなテストキャンペーンや改良が促されます。この継続的なループにより、チームは環境、法規、またはシステム機能の変化に適応することができます。

このプロセスの中核となるのは、実際の走行とシミュレーション走行のデジタル記録である走行ログです。これらのログに ODD 属性 (天候、照明、道路形状、周囲の状況など) をタグ付けすることで、チームは ODD のどの部分がカバーされ、どの部分がカバーされていないかをマッピングできます。このデータドリブンのアプローチは、将来のテストと分析の優先順位について、スマートかつ的を絞った意思決定を行うための基盤となり、包括的かつ妥当な安全性ケースを確保します。

ODD カバレッジの拡大

カバレッジ ギャップの特定

ODD カバレッジ分析を開始した後、最初のタスクとなるのはテストの欠陥箇所を明らかにすることです。ギャップは、ODD 属性の「組み合わせ空間」、つまり雨天時の都市部の交差点や、晴天時のトラック交通量の多い地方の高速道路などの組み合わせに現れます。これらのギャップは、タグ付けされた走行ログとシミュレーション結果を ODD 定義全体と相互参照することで可視化されます。ダッシュボード ツールとカスタマイズ可能なレポートにより、ODD のどの部分のデータが欠落しているか、またはまばらな例しか存在しないかを簡単に確認できます。

統計的かつデータに基づいたレビューが不可欠です。走行データがまれな組み合わせや異常な組み合わせをカバーできない場合、チームは合成シナリオ (テストカバレッジの「穴」を意図的に埋めるために作成された状況のシミュレーション) を使用できます。このアプローチにより、システムは一般的な設定だけでなく、まれなイベントの「ロングテール」においても堅牢であることが保証されます。分析対象となる典型的な ODD 属性には、天候、時間帯、アクターの種類 (トラック、自転車、歩行者) などがありますが、多くのプログラムは道路の形状、交通量、工事などの一時的なイベントも追跡します。

カバレッジ拡大のための統計的手法

連続的な属性 (車両速度、照明の強度、温度など) の場合、すべての値をテストすることはできません。そのため、値は代表的なグループに分割されます。例えば、車両速度を低速、中速、高速に離散化することができます。その後、チームは統計的信頼区間 (テストされたケースのサンプリングに基づいて全体的な安全性とパフォーマンスを推定する数学的ツール) を使用できます。これにより、エンジニアは限られたテスト データを使用して、テストされていないが類似したシナリオ全体でシステムがどのように動作するかを推測し、限られた時間で無限に多くのシナリオをカバーできます。

継続的な改善とは、これらのギャップを定期的に再検討し、改善していくことを意味します。新しい道路データとテスト結果が流入するにつれて、分析ループが繰り返され、ODD の関連領域がすべて検査されたという信頼性が徐々に強化されます。

十分なテスト実施の判断

テストが十分に実施されたか否かの判断は、技術的かつ戦略的な課題です。現実世界では時間、コスト、リソースに制約があるため、ODD (設計・開発・工程) の100%カバレッジを達成することはほとんど不可能であり、また必要でもありません。そのため、チームはリスク評価と様々な ODD セグメントの重要性に基づき、テストの完全性と現実的な実現可能性のバランスを取ります。

NCAP 規格やシナリオベース安全フレームワークといった規制ベンチマークは、「十分」とみなされるテスト実施の基準を策定する上で重要な役割を果たします。これらのベンチマークは、カバレッジとパフォーマンスに関する最低限の期待値を定義し、社内の安全性ケースや規制当局の承認のための枠組みを提供します。しかし、真の完全性は、単にチェック ボックスをチェックする以上の意味を持つことがよくあります。カバレッジの決定が現実世界のリスクと運用ニーズにどのように対応するかを、思慮深く正当化することが求められます。

業界慣行 vs 標準

業界慣行と正式な標準の間には、大きな隔たりがあります。 Pegasus のようなフレームワークは、ODD の定義とシナリオ選択のための構造化されたレイヤーを提供しますが、特定の変数をどの程度深く掘り下げるか、あるいは歩行者の動きといった行動を ODD 自体に含めるべきかどうかについては、多くの場合明確にされていません。実際には、多くの組織が標準規格を適応させ、自社のビジネスモデル、地理、あるいは車両設計に合わせて属性や挙動に関する考慮事項を追加しています。例えば、アクターの行動を主要な ODD 属性として扱うプロジェクトもあれば、静的な環境条件に主に焦点を当てるプロジェクトもあります。

こうした乖離は、柔軟なツールとワークフローの必要性を浮き彫りにしています。業界は依然としてベストプラクティスに向けて進化を続けており、安全性は固定されたチェックリストではなく、適応性が高く、状況に応じた目標なのです。

Applied Intuition のアプローチ

Applied Intuition のソリューションは、多様性と変化が求められるこの環境に対応して構築されています。Validation Toolset モジュールは、ODD を任意の詳細度で定義し、ODD タクソノミーをインポートまたは更新し、使いやすいダッシュボードと高度なデータ サイエンス ノートブックの両方を使用してカバレッジを分析する機能を提供します。

ドライブデータとシミュレーション成果物は、環境の詳細、道路の特徴、さらにはプログラムで要求された場合はアクターの行動など、正確な ODD 属性で自動または手動でタグ付けできます。カバレッジ分析はカスタマイズ可能で、チームはシンプルなマトリクスチェック、詳細な統計分析、または高リスクの組み合わせに的を絞ったレポートを実行できます。

Applied Intuition は、幅広い業界経験に基づき、いくつかのベストプラクティスを推奨しています。

• 天候、照明、交通弱者など、安全性が最も重要となる属性から開始します。
• システムと ODD 定義の両方が進化するにつれて、定期的に再分析を行い、カバレッジを拡大します。
• 可能な場合は、合成シナリオを活用して、フリートログに現れる可能性の低い稀な組み合わせやエッジケースを埋めます。
• 透明性を最優先に考え、カバレッジ決定がどのように行われたかを文書化し、規制要件やビジネス要件に直接関連付けます。
• 信頼区間と統計的サンプリングを活用し、きめ細かな調査はリスクが最も高い領域や規制当局の精査が必要な領域に限定します。

ODD カバレッジ分析は、安全で信頼性の高い自動運転車開発の中核を成します。ギャップを特定し、統計的手法と合成的手法を活用し、テストプログラムを継続的に改良することで、チームは現実世界の複雑さと規制要件に耐えうる堅牢な安全性ケースを構築できます。Applied Intuition の柔軟なツールは、このプロセスのあらゆる段階をサポートするように設計されており、「テストは完了したか？」だけでなく、「システムは本当に準備ができているか？」という問いにも答えることができます。

ODD カバレッジ分析へのよりスマートで的確なアプローチについては、Validation Toolset とインサイト モジュールをご覧ください。