安全性を保証し、消費者の信頼を得る自動運転システムを開発するには、膨大な量のデータを使用したアルゴリズムのトレーニング、検証、およびテストが必要です。業界全体を見渡しても、起こりうるすべての事象に対応するシステムをトレーニングするのに十分なデータ量についての定義は存在しません。走行テストとシミュレーションの両方で生成される大量のデータは、非バイナリの性質と自動運転車のデバッグの複雑さのためデータの分析はより複雑となります。
いくつかの企業は、データウェアハウジングとインフラストラクチャ(例：BMW’s High Performance D3 platform) をより効率的にすることで、大量の自動運転システムのデータを管理するという課題に対処しようとしています。このブログでは、走行テストとシミュレーションのデータを使用して要件の特定および追跡、そしてデータのギャップを埋めるためのベストプラクティスに焦点を当てていきます。
進捗状況の測定：最も重要なことは何か？
走行テストとシミュレーションのデータ分析から明らかにする最も重要なことは、自動運転システムのプログラムが一貫して進捗しているか、または週ごとに進歩しているかどうかです。これを明確化するには、次の2つの質問を考えてみてください。
1）自動運転システムは既知の要件に対してどの程度機能していますか？
2）次に解決すべき未知のシナリオは何ですか？
既知の測定：自動運転に特有の KPI を追跡する
組織は、快適さ（例: 最大躍度 (max jerk)）、衝突までの時間、特定のシナリオで必要な安全性など、さまざまな側面で一連の開発主要業績評価指標（KPI）を追跡する必要があります。これらの KPI は、自動運転システムの安全性と望ましい快適性を測定するように設計されています。 KPI に対するパフォーマンスを測定するには、開発チームは運転データとシミュレーションテスト結果を既知の要件にマッピングし、システムが目的のしきい値を満たしているかどうかを評価する必要があります。たとえば、高速道路の車線維持 ODD (運行設計領域)の場合、組織は自動運転車横方向制御システムのエラーと、道路のカーブがこれらのエラーにどのように影響するかを追跡するかもしれません。その場合組織は、道路の曲率ごとにすべてのデータを集約し、エラーが定めたしきい値を超えないデータを引き出す必要があります。 KPI を追跡するには、同じシナリオを使用して週ごとに KPI を測定するか、新しいドライブデータと比較するのではなく、古いドライブデータの KPI を再計算して、落ち葉や路面の状態などの外部要因による差異の影響を最小限に抑えることをお勧めします。
カスタム KPI に加えて、自動運転システム業界で広く採用されている安全性を評価するモデルがあります。たとえば、Mobileye のオープンソースのResponsibility Sensitive Safety（RSS）は、自動運転車が人間の直感に対して安全に動作するかどうかを評価するための数学モデルです。このモデルを使用すると、「目の前の車で安全な距離を維持する」などの抽象的な安全概念に従う能力を評価できます。これらの KPI のスコアは、すべてのデータにわたって特定のシナリオで計算できます。
組織の自動運転プログラムが進行し、車両の安全性が向上するにつれて、KPI のしきい値を調整し、より厳しくすることが重要になります。チームは、時系列変化と共に許容可能と見なされる動作の基準を徐々に引き上げることで、既存機能のパフォーマンスを低下することなく、将来の機能開発をすることができます。
ほとんどの自動運転システム開発プログラムは「この自動運転システムは安全ですか？」の問いに答える準備ができていないかもしれませんが、自動運転システムが先週よりも今週安全かどうかを定量化することは依然として重要です。 KPI を追跡することで、自動運転システム開発プログラムの進捗状況を定量化できます。
不明な点を見つける：カバレッジギャップ
自動運転システム開発では、多くのシナリオが事前にわかっていないため、依然として死角があります。ドメインカバレッジに関する過去の投稿で、SOTIF とそれに対応するカバレッジアプローチについて説明しました。
ドライブデータのギャップを特定するには、いくつかのアプローチがあります。最も明白なアプローチは、システムがどのタイプの動作と相互作用したか（または相互作用しなかったか）、マップのどの領域でシステムが駆動したか（または駆動しなかったか）などの詳細を可視化するレポートを作成することです。地理的な地図の範囲に加えて、既存のデータを交差点のタイプ、道路のサイズ、出口ランプなどの特定の地図の特徴と比較することもできます。このタイプの分析では、一般的な問題が発生する場所を明確化し、既存のデータにギャップがある場所を明確にする必要があります。
もう一つのアプローチは、認識自動運転システムの出力を使用して、システムが「混乱している」場所を見つけることです。このアプローチは、対象が不確実でも分類およびラベル付けされている場合、役立つ可能性があります。
ドライバーによる介入 (intervension) と自動運転解除 (disengagement) は、カバレッジギャップのシグナルの一つです。 自動運転システム内モジュールの任意の組み合わせからエラーが伝播する可能性があるため、自動運転システム全体の障害の原因を特定するのは困難な場合があります。根本原因を明らかにするためには、センサーフュージョン後のバウンディングボックス、および関連する自動運転システムモジュールから生成されたメトリックやログ、そしてセンサーデータの可視化結果が必要になります。異なる自動運転システムバージョンでの再シミュレーションは、現実世界での障害のデバッグにも役立つ可能性があります。また、新たな要件はイベントを元に定義することが重要です。このように定義した要件は、組織の要件として追加しましょう。
データギャップを埋める
これらのギャップを特定することは、機能開発、データ収集、合成データ生成、およびデータアノテーション全体で開発チームの焦点を優先するために重要です。既知のギャップを埋めるために、現実世界で走行テストを実施してデータを収集することはできますが、このアプローチはスケーラブルではありません。欠落しているデータの種類によっては、ごく稀のケースのためデータに遭遇するのは運次第かもしれません。
合成シナリオを作成することは、よりスケーラブルなアプローチです。センサーシミュレーションに関して過去の投稿で説明したように、手続き的な生成プロセスを活用することで、さまざまな入力を使用して、フォトリアリスティックな環境を迅速かつ安価に作成できます。欠落しているデータを現実世界で入手するのが難しい場合、または同じシナリオの複数のバリエーションで自車両をテストする必要がある場合に特に役立ちます。認識トレーニングデータのギャップは、付加情報付きの合成データで埋められる可能性があります。認識システムの開発に役立つ合成データの要件についてはこちらの投稿よりご覧ください。
データのアノテーションに関して、収集された全てのデータに付加情報を付けることはいかに困難か気付くでしょう。
トレーニングデータセットのサイズを削減するための一般的なアプローチはアクティブラーニングです。アクティブラーニングでは、アルゴリズムが運転データをインタラクティブにクエリし、認識システムで混乱を引き起こしている興味深い事象や珍しい事象を引き出せます。収集されたデータは、モデル埋め込み比較を使用して、対象の検出と同様のデータサンプルをクエリすることによって引き出すこともできます。収集されたデータは手動でラベル付けすることにより、トレーニングデータセットとして追加されます。このアプローチでは、最も影響の大きいデータに費用のかかるラベル付を制限することによって、トレーニングセット内の「紛らわしい」データの割合は増えるかもしれません。
ギャップが特定されたら、開発チームはギャップを埋めるための機能を構築し、将来的に修正が発生しないようにする必要があります。これには、カスタムダッシュボードでターゲット要件、それに関連する機能シナリオと共に KPI を追跡することから始め、焦点を絞りその機能だけに集中することで実現できます。ダッシュボードは、作業後の回帰分析の一部として使用することもできます。
現状での自動運転システム性能最大のギャップが判明すれば、それらを軸にデータ収集と機能開発を推進できます。開発作業を推進するためのギャップを特定するこのプロセスは、システム性能を向上させるための残存作業を最適化し、継続的に分析しながら、周期的に繰り返すことができます。
当社のアプローチ
何が最善のアプローチかは、状況やチームごとに異りますが、Applied Intuition のツールでは、シナリオ要件とのギャップを特定し、数千時間のドライブログの異常を検出することで、開発者が目標に向けた進捗状況を測定するのに役立ちます。分析および可視化ツールは、即時回帰分析および根本原因分析を可能にし、大規模なドライブログから自動で見識を提供することでエンジニアリングチームから経営幹部までの組織全体のコミュニケーションを促進します。既存案件やこれからの案件など特定のアプローチについて興味がある場合は、弊社のエンジニアまでご連絡ください。
.webp)
.webp)
