自動運転システムにおける視覚認識モジュールの安全性テストに関する1万語

近年、ディープラーニングに基づく視覚認識技術の発展により、自動車のインターネット分野での自動運転の繁栄が大きく促進されました。しかし、自動運転システムの安全性に関する問題が頻繁に発生し、自動運転の将来について人々が不安を抱いています。ディープラーニングベースの自動運転システムの安全性をテストすることは、その動作の説明可能性が欠如しているため、非常に困難です。現在、自動運転シナリオの安全性テスト作業が提案されていますが、これらの方法では、テストシナリオの生成、安全性の問題の検出、安全性の問題の説明に依然として欠点があります。視覚認識に基づく自動運転システム向けに、シナリオ主導型で解釈性に優れた効率的な安全性テスト システムが設計および開発されています。真実味と豊かさのバランスをとることができるシーン記述方法を提案し、リアルタイムレンダリングエンジンを使用して、運転システムの安全性テストに使用できるシーンを生成します。また、非線形システム用の効率的なシーン検索アルゴリズムを設計し、テスト対象のさまざまなシステムの検索スキームを動的に調整できます。同時に、テスト対象システムの安全性欠陥の原因を自動的に分析して特定する障害アナライザーを設計します。リアルタイムレンダリングエンジンに基づく既存の動的自動運転テストシステムを再現し、本システムと再現システムの両方を使用してCILRSシステムとCILシステムの安全性テストを実施しました。実験結果によると、本作業の安全性の問題発見率は、同じ時間内に再現されたシナリオ駆動型動的テスト方法の1.4倍でした。さらに実験を進めると、荒野、田舎、都市の 3 種類の環境で動的に生成された合計 3000 のシナリオから、代表的なディープラーニング自動運転システム CIL と CILRS のそれぞれ 1939 と 1671 の障害発生シナリオを検索できることが示されました。各障害シナリオの平均検索時間は 16.86 秒です。統計的な観点から、アナライザーは、CILRS システムが故障しやすいエリアは道路の両側にあり、雨の日や赤や黄色の物体があると自動運転システムが故障する可能性が高くなると判断しました。

コネクテッドビークルの分野は、モノのインターネットと輸送部門の深い統合により急成長しています。ディープラーニングの進歩により、車両ネットワーキング分野における自動運転技術は画期的な発展を遂げ、新たな自動車産業革命へと進化する傾向を示しています。テスラやNIOなどの新興自動車会社から、フォードやBMWなどの伝統的な自動車会社まで、次々と自動運転の路上試験ライセンスを取得し、深層自動運転技術の研究開発に注力している。急速に発展している高度自動運転技術は、徐々に車両のインターネットの分野における主要な支援技術の 1 つになりつつあり、輸送と旅行の未来を変えています。

視覚認識モジュールは、自動運転が環境を認識するための重要なコンポーネントであり、車両がインテリジェントな決定を下すための重要な基盤です。自動運転の分野で重要な企業であるテスラは、視覚認識モジュールを運転システムの唯一の環境認識モジュールとして使用しています。したがって、自動運転システムの視覚認識モジュールの安全性は、自動運転システムの正常な動作の鍵となります。深層視覚技術の発達により視覚認識モジュールの性能は着実に向上しているものの、運転環境から認識した特徴の意味を理解することは難しく、意思決定プロセスを説明することはできません。自動運転システムの視覚認識モジュールの安全性をいかにして十分にテストするかが、解決すべき差し迫った問題となっている。

確かに、ディープラーニングの解釈可能性に関する研究ではいくつかの進歩がありましたが、自動運転視覚認識モジュールのエラー伝達メカニズムを明確に分析できるようになるまでには、まだ長い道のりがあります。近年、ニューラル ネットワークに対するブラック ボックス攻撃手法の進歩により、シーン検索に基づく自動運転視覚認識モジュールの安全性テスト手法がいくつか提案されるようになりました。これらのシナリオ駆動型テスト方法は、ブラックボックステストの考え方を利用して、運転システムに可能な限り多くの運転シナリオデータを提供し、自動運転システムの出力とテストオラクル（TestOracle）の違いを観察し、自動運転システムの視覚認識モジュールの安全性を分析します。

我々は、深層学習の解釈可能性を明らかにする前に、シナリオ主導のブラックボックスセキュリティテストが視覚認識モジュールのセキュリティに対する最も重要なテスト方法であると考えています。ただし、生成されたシーンを視覚認識モジュールのテストに適用する際には、まだ 3 つの課題が残っています。

1)シーン描写の真実味と豊かさのバランスをとる。シナリオ生成ルールは、シナリオ駆動型テスト システムの重要な基盤です。保守的なルール設計ではシーンのカバレッジが不十分になり、過度に柔軟なルール設計ではオブジェクト間の相対的な関係が破壊され、シーンの信憑性が損なわれます。シーンの信憑性と豊かさの両方を考慮できるシーン生成ルールを探ることは、非常に困難です。

2)検索アルゴリズムの効率性と安定性を確保する。単一のオブジェクトのプロパティ (色、形状など) とオブジェクト間の関係 (位置、方向など) の組み合わせは非常に複雑です。システムの安全性の欠陥を効率的かつ安定的にテストできるようにするには、次のことが必要です。①さまざまな自動運転システムの視覚認識モジュールに合わせてパーソナライズされたシーン検索ソリューションを動的に生成し、検索プロセスのステップ数を減らすこと。②同時に、単一ステップの検索時間を可能な限り短縮すること。

3)テスト結果の解釈の正確性と自動化。これまでのテストシステムでは、欠陥の原因を分析するために手動による介入が必要でした。テスト結果を自動的に分析するには、システムがシナリオ内の各要素を細かく操作して、システム セキュリティの欠陥の原因を特定できる必要があります。

学術界では、シーン駆動型視覚認識モジュールのブラックボックス セキュリティ テストに関する予備調査がすでに実施されています。シーンテスト方法の中でも、リアルタイムレンダリングエンジンをベースにした一連のテスト方法は、シーン生成の柔軟性により広く注目を集めています。当初、リアルタイム レンダリング エンジンに基づくシナリオ駆動型セキュリティ テストでは、事前に決定されたシナリオに基づくテスト アプローチが採用されていました。その代表的なものがCARLA0.8です。 X、この作品では、UnrealEngine を使用して、システムをテストするための固定の走行ルートを作成します。その後、Scenic らは、このようなテスト手順をより体系的にするためのシナリオ生成プログラミング インターフェイスを提案し、静的シナリオベース テストの基礎を築きました。しかし、そのシミュレーション環境は比較的固定されており、動的な動作に欠けており、非物理的なオブジェクト（天気など）を記述する自由度が欠けています。リアルタイム レンダリング エンジンのシーン駆動型セキュリティ テストに関する最新の研究である Paracosm は、Scenic をベースに、視覚認識モジュールのセキュリティ テストを実行するためにランダム検索に基づく動的シーン生成方法を提案しました。動的シーン検索方法は比較的単純であり、テスト対象の視覚認識モジュールへの適応性が欠けているため、セキュリティ問題の検索プロセスは十分に効率的ではありません。上記の研究に基づいて、本論文では、結果のフィードバックに基づく動的シーン検索アルゴリズムを提案し、自動運転システムの視覚認識モジュールの安全性の問題テストの効率を向上させます。詳細についてはセクション 1.5 で説明します。

この研究では、ディープラーニングのブラックボックス攻撃戦略との類推とリアルタイムレンダリングエンジンのオープン性の助けを借りて、自動運転視覚認識モジュールのための信頼性が高く説明可能な安全性テストシステムを設計し、提案します。

主な貢献は次の 3 つの側面にあります。

1) 本研究では、車両のインターネットシナリオにおける自動運転システムの認識モジュールのセキュリティ問題に対処するために、シナリオ駆動型のブラックボックスセキュリティテストシステムを提案し、設計します。既存の作業と比較して、このシステムは結果のフィードバックに基づく動的テスト戦略を導入し、適応メカニズムを通じてループ内の入力データの生成を継続的に調整して、認識モジュールの効率的で安定した非侵襲的なセキュリティテストを実現します。

2) 自動運転視覚認識モジュールの動的テストの新しい要件を目指して、この研究では、きめ細かいシーン記述方法、適応型動的検索アルゴリズム、および自動システム欠陥分析のための動的テスト技術を設計しています。提案されたブラックボックス安全性テストシステムは、テストの粒度、フィードバックの適応性、説明可能性の3つの側面から最適化されています。

3) この研究では、代表的なオープンソースの自動運転システム 2 つでテスト システムの検証を実施し、3000 のシナリオを動的に生成し、それぞれ 1939 と 1671 の障害シナリオを発見しました。平均して 16.86 秒ごとに 1 つの障害シナリオが見つかりました。実験では、動的適応シーン検索方法のおかげで、この研究のセキュリティ問題発見率は、リアルタイム レンダリング エンジンに基づく既存のシーン駆動型動的テスト方向における最良研究の 1.4 倍であることが示されています。

関連研究

ニューロンカバレッジに基づく自動運転テスト

ニューロン カバレッジは、従来のプログラムのブランチ カバレッジと同様に設計されています。このタイプの作業では、テスト入力がニューロンを通過し、ニューロン出力が特定の状態を満たす場合、ニューロンはテストサンプルによってカバーされている（アクティブ化されている）と言われることを定義します。このタイプの作業では、ニューロンのカバレッジを最大化するという最適化目標を掲げて入力サンプルを検索します。 DepXplore がニューロン カバレッジの概念を導入し、それをビジョン ベースのディープ自動運転の分野にうまく適用して以来、ニューロン カバレッジに関する大量の研究が登場し、さまざまなカバレッジ標準が提案され、メタモルフォーシス テスト、ファズ テスト、シンボリック テストなどの従来のソフトウェア テスト方法がディープラーニング テスト タスクにうまく移行されました。しかし、このアナロジーは機械的なアナロジーであり、ニューロンの出力値の状態は、従来のソフトウェアテストにおけるブランチとはまったく異なる概念です。そのため、このアナロジー手法の有効性は常に疑問視されてきました。さらに、ニューロンカバレッジに基づく設計では、セマンティックベースのテストサンプルの障害原因を提供することも困難であり、自動運転システムの安全性のさらなる向上にはつながりません。

フォールトインジェクションに基づく自動運転テスト

AVFI はソフトウェア障害注入を使用して自動運転システムのハードウェア障害をシミュレートし、システムのフォールト トレランスをテストします。その後、DriveFI は Apollo と DriveAV を使用して CARLA シミュレーターと DriveSim で実験を行い、ベイジアン ネットワークを使用して自動運転システムをシミュレートし、エラー挿入後の検証プロセスを加速して、自動運転システムに影響を与える障害の発見を最大限に高めました。 Kayote は、上記の作業を基に、エラーの伝播を記述し、CPU と GPU にビット反転を直接挿入する機能を追加します。これらの研究では、自動運転システムの特性をフォールトトレランスの観点から検証し、自動運転システムのハードウェア障害を実際に検証します。この種の作業は、自動運転システム ソフトウェア、特にその視覚認識モジュールの安全性を研究する本作業で議論されているシナリオや問題とは直交しています。

検索ベースの自動運転テスト

探索ベースの自動運転安全性テストの核心的な考え方は次のとおりです。テスト対象の自動運転システムの入力空間が与えられ、テスト対象のシステムの特殊な入力状態が定義され、入力空間内を検索することで、どの入力がシステムに特殊な状態を出力するかを判断し、それによって入力空間の分割を実現します。 Abdessalem は、検索アルゴリズムを使用して入力空間内の入力にラベルを付け、ラベル付けされたデータを使用して分類器をトレーニングし、入力空間を決定境界に分割します。その後、彼は少数体問題の状態空間の探索プロセスを多体問題の状態空間の探索に拡張し、FITEST探索テスト法を提案しました。この方法の制限は、分類器の導入によって、入力空間が局所的に連続かつ線形であると暗黙的に想定されることです。たとえば、分割に決定木を使用する場合、2 つの正の例間の状態も正の状態であると想定される可能性があります。問題が線形領域で定義されている AEB システムなどのシステムの場合、分類器の設計は合理的ですが、高度に非線形なシステムを備えたディープラーニング システムの場合、このようなアプローチは明らかに適用できません。さらに、ウィッカー氏は、2人の間のゲームのアイデアを利用して、画像上のピクセルを操作し、モンテカルロ木探索ゲームの漸近最適戦略を使用して、モデルを誤らせる反例を見つけました。このような検索戦略の検索空間はピクセルレベルであり、検索結果は実際には本物ではありません。

実際のデータに基づくテスト方法

実際のデータに基づくテスト方法には、主に 2 つの種類があります。

1) テスラなどの大量のユーザー運転データを収集し、自動運転システムの品質を向上させる。

2) 実生活テスト：プロトタイプ車両を使用して実際の道路環境でテストを実施します。安全要因を考慮すると、この方法のテスト条件は比較的厳格です。これらの方法では、データ収集コストが高いだけでなく、収集したデータの配布範囲も非常に限られているため、テストシステムが新しい環境での自動運転システムの安全性を検知することが不可能になります。また、運転データの過剰な収集は、ユーザーのプライバシーを侵害するという問題も生じます。

生成されたデータに基づくテスト方法

生成されたデータに基づくテスト方法には、主に 2 つの種類があります。

1) DepRoadでは、生成的敵対ネットワーク（GAN）に基づいて、通常の天候の道路シーンを雨や雪の天候に変換し、雨や雪の天候でのシステムの安全性をテストします。ただし、その生成方法のシーンの豊富さは不十分であり、シーンコンテンツの柔軟な制御も実現できません。

2) リアルタイムレンダリングエンジンに基づいてテストシーンを作成します。 Richer はゲーム GTA-V を使用して自動運転データセットを作成し、Sythia は Unity エンジンを使用してデータセットを合成し、CARLA0.8.X は UnrealEngine を使用してシステムをテストするための運転ルートを作成しました。これらの作品の問題点は、テストシーンが事前に定義されており、調整できないか、非常に限られた方法でしか調整できないことです。このような作品では、シーンを動的に調整できるリアルタイムレンダリングの特性が十分に活用されていません。特に、テストに固定の運転シナリオを使用すると、考えられるすべてのシナリオをカバーすることが難しくなります。

Scenic は、自動運転視覚認識モジュールの安全性テスト用に事前定義されたルールに基づいていくつかのシナリオを生成できるシナリオ記述言語を設計しました。この記述言語は自由度が高い反面、天気や太陽などシーン内の非物理的な物体を記述することが難しく、シーンが変化する状況への適用は困難です。最新の研究では、Paracosm が自動運転テスト シナリオを生成するためのプログラム可能な方法を提案しました。この作業では、シーン内のオブジェクトと環境をパラメータ化し、テストシーン生成用のプログラミング インターフェイスのセットを提供します。この方法は、ランダム検索に基づいてシーンを生成し、自動運転における視覚認識モジュールをテストします。しかし、検索可能なパラメータ空間のサイズが非常に大きいことを考慮すると、ランダム検索によって知覚モジュールのセキュリティ問題を効率的に見つけることは困難です。詳細な比較と評価はセクション4.1で行います。

改良点は、より柔軟で豊富なシーン記述方式を採用したことです。この方式では、風景方式と比較して、非物理的なオブジェクトの記述が追加され、さまざまな気象条件での自動運転視覚認識モジュールの安全性を十分にテストできます。 2 番目の改善点は、適応型シーン検索アルゴリズムの提案です。Paracosm 法と比較して、本論文では適応型動的障害シーン検索を実現でき、これにより自動運転視覚認識モジュールにおける安全性の問題発見の効率が大幅に向上します。

システム設計

このセクションでは、安全性テスト システムの正式な説明、ワークフロー、シナリオ記述方法、動的シナリオ ジェネレーター、欠陥分析方法など、自動運転視覚認識モジュールの安全性テスト システムの具体的な設計を紹介します。その前に、この論文で使用されているいくつかの重要な変数を表 1 にまとめます。表1 この方法で使用される変数の説明

セキュリティテストシステムの正式な説明

自動運転システムは本質的に戦略πであり、環境情報シーケンスOが与えられた場合に制御命令Aにマッピングされます（π：O→A）。入力環境情報にはカメラ画像Iと現在の車速Vが含まれ、出力制御命令にはブレーキ、スロットル、ステアリング角度が含まれ、そのうちブレーキは逆スロットルとみなすことができるため、出力制御命令は（s、t）と表現できます。

シーン検索ベースのテストシステムは、まず特定のシーンw∈Wを生成し、そのシーンによって表される環境情報はo＝ϕ(w)∈Oです。自動運転モデル​​m = Mが与えられた場合、車両は次のようになる。

安全性試験システムのワークフロー

テスト システムのアーキテクチャ設計を図 1 に示します。シーン生成を正確に制御するために、本稿では、シーン内の個々のオブジェクトの属性と関係を制御する一連の属性構成スキームを設計します（セクション 2.3）。 1) 動的シーンジェネレーター（セクション2.4）は、まず構成ファイルを読み取り、シーン内のオブジェクトの分布関数を取得し、初期のシーン記述をランダムにサンプリングします。 2) リアルタイム レンダリング エンジン (UnrealEngine など) は、シーンの説明に基づいて、システム テスト用の運転シーンをレンダリングします。 3) テストする運転モデル​​を読み取ります。 4) 判定結果を欠陥解析装置に出力して解析します。 5) 欠陥アナライザー (セクション 2.5) は、モデル出力に基づいて制約を生成し、動的シナリオジェネレーターを適応的にガイドして、次のテストラウンドの新しいシナリオ記述を生成します。 6) 欠陥分析装置がテスト対象のシステムに安全上の問題を発見した場合、自動運転システムのその後の改善のために欠陥レポートを自動的に生成します。以下に、システムのコアテクノロジーとコンポーネントを紹介します。

図1. テストシステムのワークフロー

豊かでリアルなシーン描写

豊かでリアルなシーン記述を実現するために、オブジェクト プロパティ記述ファイルと環境構成スキームを設計し、アセット (assets) プロパティ、プロパティ分布、リアルタイム レンダリング エンジンに必要な新しいマップの追加を記述しました。同時に、シーン内のすべてのオブジェクトをパラメトリックに記述して、欠陥のあるシーンの自動検索を容易にしました。

オブジェクトの説明と環境構成

このシステムは、シーン内に表示されるオブジェクトを 5 つのカテゴリに分類します。

1) 環境 E は、シーン生成に使用されるプリセットの基本道路環境です。道路環境には、少なくとも道路と道路沿いの建物が含まれる必要があります。オブジェクトの適切な配置を制限するなど、描写されるシーンの信憑性を確保するために、環境を領域に分割しました。典型的な環境には、オフロードの非走行エリア、歩道、左車線と右車線、交差点などのエリアが含まれます。

2) 天気Wには太陽高度角、降雨量、霧濃度などが含まれ、その値は連続的に変化します。基本的な天気は、特定の範囲にわたる確率分布密度関数として表されます。気象条件間に相互作用があり、その結果、結合確率分布が生じる可能性があります。したがって、単一のシナリオに対して複数の気象分布を設定し、サンプリングには結合確率分布関数を使用する必要があります。気象分布と環境構成の相関は非常に低いです。気象分布と環境の相関を考慮すると、気象分布を直接変更する方が合理的です。たとえば、乾燥地域での大雨の確率は湿気の多い地域のそれよりもはるかに小さく、車両、歩行者、静止物体の分布は環境に依存します。

3) 車両Vは、車、自転車、バイクなどの環境における衝突シミュレーションや重力シミュレーションを行うための車両です。特に、自転車とバイクは現実的な観点から、車両にドライバーが追加されます。環境のさまざまな領域に車両が出現する確率は異なります。また、車両に正常と異常の 2 つの状態を設定し、さまざまなモードで各領域における車両の確率分布を制限します。たとえば、通常の状況では、車両が歩道や反対車線に現れることはありません。

4) 歩行者Pの説明は車両と似ていますが、デザイン上の違いは、歩行者にはカテゴリーの違いはなく、服装、体型、外見の違いのみであることです。

5) 静的アイテム G は、衝突シミュレーションや物理シミュレーションを使用しないソリッド オブジェクトです。相互作用を考慮せずに初期分布を取得するために直接サンプリングすると、貫通問題が発生する可能性が高くなります。そのため、ジオメトリ計算に基づく有向境界ボックス (OBB) 衝突検出アルゴリズムを使用します。アイデアは、空間内の各エンティティ オブジェクトを OBB で囲み、異なるエンティティ オブジェクト間の OBB が重なり合うかどうかを計算して衝突が発生するかどうかを判断するというものです。

具体的には、まずオブジェクトを地面に投影し、交差チェックには 3 次元オブジェクトの代わりに OBB を使用します。同時に、地面に垂直な次元における3次元オブジェクトの階層構造の損失を補うために、レイヤーの概念が導入されています（図2）。各レイヤーにはオブジェクトのOBB投影があり、オブジェクトの複数のレイヤーで同時に衝突検出を行う必要があります。シーンが生成されると、静的オブジェクトがランダムに選択され、環境に順番に追加されます。新しいオブジェクトが古いオブジェクトと衝突しない場合は、オブジェクトの生成は有効です。

図2. 多層投影OBBのパラメータ記述

同じエンティティ オブジェクトの場合、それらはマトリックス D 内の異なる行に配置されているため、自然に区別されます。つまり、複数の繰り返しオブジェクトは、表現では複数の行で表されます。

ダイナミックシーンジェネレーター

テスト システムでセキュリティ テストを適応的に実行できるようにするために、動的シナリオ ジェネレーターを設計しました。

ジェネレータの使用は 2 つの段階に分かれています。

1) シーン初期化フェーズ。各テスト ラウンドの前に、動的シーン ジェネレーターは、環境構成とオブジェクトの説明に従って、天候、車両、歩行者、静的オブジェクトを順番にサンプリングし、オブジェクトの分布関数を合成して、シーンの説明を生成します。

2) 使用フェーズ。動的シナリオジェネレーターは、欠陥アナライザーの出力に基づいて、テスト用の次のシナリオを動的に生成できます。動的シナリオジェネレーターの中核は適応型シナリオ検索アルゴリズムであり、テスト対象システムごとに異なる検索方法を生成できるため、テストシステムはテスト対象システムの欠陥を迅速かつ安定して見つけることができます。

変態試験に基づく評価方法

テスト予測は、テスト対象システムの出力が正しいかどうかを判断するために使用されます。自動運転システムの場合、特定のシナリオにおける正しい出力を定義することは困難です。自動運転システムの場合、一定範囲内の出力であれば運転ミスが発生しないからです。さらに、自動運転システムによって制御される車両は物理的に連続しているため、単一のシステムエラー出力によって重大な安全上の影響が生じる可能性はありません。したがって、特定の値をテストオラクルとして取得するのは不合理です。これまでの研究に倣い、メタモルフォーシステストを採用し、テスト予測として緩和します。異なるテスト シナリオには異なるテスト オラクルが必要なので、テスト システムを使用する際の経験に基づいて、異なるオラクル ルールを設計できます。ここでは、2 つのテスト予測を示します。通常、ディープ自動運転テストでは、出力ステアリング角度の正確さに重点が置かれます。ステアリング角度によって、システムが危険な結果を引き起こすかどうかが決まることが多いためです。予測 1 ではこのような設計を使用していますが、テスト車両の前に車両があるにもかかわらず、シーンの変化によりブレーキがかかっていない場合も、自動運転システムにエラーがあると判断する必要があります。予測 2 ではこの設計を使用しています。

適応シーン検索アルゴリズム

この検索アルゴリズムには 3 つの設計要件があります。

1) 検索アルゴリズムはシナリオに適したものでなければならず、環境構成とオブジェクト記述によって定義された合理的な状態を超えてはなりません。

2) 検索される 2 つの隣接するシーンは、同じ駆動セマンティクスを持つ必要があります。

3) 検索アルゴリズムは効率的で、1 回の検索に時間がかかりすぎないことが必要です。

サンプルを拒否することで、検索したシーンの合理性を確保します。つまり、シーンが変更されるたびに、シーンの合理性を検証する必要があり、元のオブジェクト属性ファイルで定義された分布に準拠していない場合は、再度変換する必要があります。運転の意味的不変性は、カメラが配置されている車両前方の一定距離にある物体の位置が変化しないように制御することで確保されます。たとえば、自動運転車の前に車があり、その車がブレーキをかける場合、検索プロセス中に車の空間位置を変更してはならず、車の方向角度と色のみを変更できます。最後に、アルゴリズムの効率は、可変ステップ サイズによるランダム検索設計によって保証されます。検索プロセス中、最後の検索プロセスが受け入れられたかどうかに基づいて、ステップ サイズの予算が調整されます。アルゴリズムの詳細な説明はアルゴリズム 1 に示されています。

図3は、テストシステムによって実行されるシーン検索プロセスの概略図である。図では、赤枠は動的に生成された車両、青枠は動的に生成された歩行者、緑枠は動的に生成された静的メッシュ オブジェクトを表しています。天候は、図 3 の建物や木の影、葉の揺れる角度など、グローバルなレンダリング効果に影響を与えます。テスト システムは、これらのオブジェクトの空間位置と内部プロパティを動的に調整し、レンダリング イメージを変更して、障害の原因となるシーンを探します。

図3: シーン検索の概略図

正確で自​​動的な欠陥分析

インジケーター関数の値が 1 になるシナリオでは、欠陥アナライザーは、どのオブジェクトまたは属性がシステム異常を引き起こしたかを分析して説明します。異常なモデル出力の原因は、特定の反復プロセスではなく、検索プロセスのパス全体であることに注意してください。高度に非線形なディープラーニングモジュールを備えたシステムの場合、パスを分析するだけでは、システム異常の正確な原因を特定することは困難です。

私たちは、天候をゼロにリセットしたり、現場から物理的な物体を除去したりしながら、自動運転システムの問題の原因を探りました。自動運転のエラーの原因は相互に関連している可能性があります。たとえば、霧の天候では、対向車を誤認して停止することがあります。エラーの原因となったオブジェクトのセットを見つけるために、反復的な貪欲探索戦略が採用され、δ0 を停止標識としてシーン検索が実行されます。アルゴリズムの詳細はアルゴリズム 2 に示されています。

システム実装

テスト対象システム

試験対象として、最優秀条件付き自動運転システム CILRS が選択されました。画像特徴抽出用の畳み込みニューラル ネットワークとして ResNet-34 を使用し、重みパラメータは CARLA の NoCrash データセットを使用してトレーニングされた事前トレーニング済みモデルでした。同時に、さまざまな自動運転システムに対するテストシステムの能力を示すために、基本的な条件付き自動運転システム CIL が比較のベースラインとして選択されました。最後に、CIL と CILRS がパッケージ化され、テスト システムに展開されました。

テストプラットフォーム

本稿では、プレハブアセットの豊富さとAPI利用の柔軟性の観点から、CARLA0.9.11をテストシステム開発プラットフォームとして選択しました。静的アセットとマップを簡単にインポートできるように、Unreal Engine 4.24 と CARLA 0.9.11 をソース コードからコンパイルし、Windows プラットフォームに展開しました。実行時に、UnrealEngine エディタから CARLA を起動して、ビルド環境をすばやく反復し、シーン生成アルゴリズムの正確性を確認します。

シーン構築

ディープラーニングモデル導出の効率の限界により、ディープラーニング自動運転で通常導入される CNN ネットワークの入力画像解像度はそれほど高くなく、カメラで撮影したデータは前処理して関心領域 (ROI) を切り取る必要があります。この場合、道路から遠く離れたシーンの他の部分はカメラで撮影されません。ただし、道路の両側にある比較的高いまたは比較的低い建物の高さは、実際に道路の照明効果に影響を与え、自律運転システムの予測に間違いなく影響します。この効果をテストするために、図4に示すように、非現実的な編集者を介して作成された、環境オブジェクトのさまざまな高さで、荒野、田舎、都市の3つの環境を設計しました。

図4 3つのタイプの環境

CARLA0.9.11がデフォルトで提供する10の気象パラメーター（太陽方位標高、太陽の高度、雲の覆い、降雨、蓄積降雨、空気湿度、霧濃度、霧の距離、霧密度）は、テストシステムで調整できる気象パラメーターとして選択されます。その中で、太陽方位角と太陽の高度は、さまざまなシナリオで必要な気象パラメーターです。霧濃度、霧の距離、霧の密度の間には相関があり、同時に存在する必要があります。

カーラが効果的に生成できる89の静的オブジェクト、28台の車両、26人の歩行者のオブジェクト特性を測定しました。 28台の車両のサイズ、形状、色が異なります。 26種類の歩行者には、男性と女性の2つの性別が含まれ、年齢は子供、若者、高齢者の3つの年齢層に分かれています。 89の静的オブジェクトの中には、いくつかの重複した内容があります。たとえば、6つのボックスがありますが、2つだけが大きく異なり、スイングなどのシーンの道路や歩道で動的に生成してはならないオブジェクトがあります。最後に、28種類の車両すべて、26種類の歩行者、15の代表的な静的オブジェクトが選択され、測定データはフォーマット要件に従ってオブジェクト属性ファイルに記述されました。

リアルタイムのレンダリングエンジンは、Carlaの車両の物理的なシミュレーションが実装と同じ青写真を使用するため、自動運転を制御するための車両とカメラセンサーを必要とします。テスラモデル3は、28種類の車両からのコントロール車両として選択されました。カメラでキャプチャされたシーンを図5に示します。

図5。田舎の環境で車のカメラでキャプチャされた画像

実験的評価における安全性発行検出機能の比較分析

最新の自律運転試験システムのパラコスムを再現し、自律駆動システムCILRSおよびCILで安全性テストを実施するために、再現されたパラコスムを作業とともに使用しました。 Carla0.9.11をパラコスムおよびこのシステムのシーン生成プラットフォームとして選択しました。 Paracosmが特定のセキュリティ問題検出基準を設定する方法を指定していないことを考慮して、その将来の作業セクションでは、この記事と同様のテストOracle Generationのアイデアについて説明しましたが、特定の方法とパラメーターの選択を指定しませんでした。したがって、このセクションの実験では、実験の公平性のために、この論文のように再現されたパラコスムシステムは、テスト予測メカニズムとして選択され、シーンが正しい出力に示されている前に自律運転システムによる結果出力を認めました。

パラメーターの選択部分では、検索シーンの天候のみが障害判断の基礎として予測1を選択し、つまり、元の出力に比べて車両のたわみ角度が15°を超えると、障害が発生していると考えられています。 1 = 0.17およびε2= 0.2。シーンにエンティティオブジェクトがある場合、エンティティの数は正規分布を使用してサンプリングされます。

Wilderness、Rural、Urbanの3種類の環境を選択し、CILRSシステムとCILシステムでそれぞれセキュリティテストを実施しました。 3つの環境の主な違いは、道路の両側の建物が高さが異なることであり、これが自律車両のカメラのROIの照明に影響を与えることです。現場のまっすぐな道路で車両を生成し、車両の運転枝を設定して、道路に沿って運転してテストを開始します。 2つのテストシステムが、さまざまなタイプの環境で300シーンを動的に検索します。この作業の安全性問題検出率と表2のパラコスムシステムを示します。検出速度の計算方法を式（2）に示します。

表2セキュリティ発行この作業とパラコスムシステムの発見率

3つの代表的な環境での300のシーン検索では、安全性の問題を検出する能力は、自律運転試験システムのパラコスムの能力よりも優れていました。全体として、2つのシステムでのこの作業のセキュリティ問題検出率は、パラコスムの1.4倍です。実験では、このシステムのテストオブジェクト向けに設計された適応検索アルゴリズムは、適応性のないアルゴリズムよりも効率的であることが示されています。

セキュリティ問題検出機能の特定の分析

このセクションでは、このペーパーで設計されたシステムの詳細な分析を提供します。他の要因の影響を排除するために、3つの設計された環境の中で荒野環境がテスト環境として選択されました。実験パラメーターは、セクション4.1のパラメーターと同じです。この設定に基づいて、実験はそれぞれCILとCILRで実施され、各システムに対して1000ラウンドのシーン検索が実行されました。故障率は式（2）を使用して計算され、結果を表3に示します。表3から、物理的なオブジェクトがある場合、シーンの変化によって引き起こされる故障率は、天候だけがある場合よりも高いことがわかります。天候とすべての物理的なオブジェクトを考慮すると、CILRの障害検出率は58.4％に達します。

表3自律運転システムの故障率

CILRの実験結果をCILの実験結果と比較すると、2つは天候のみが関係する場合に同様に機能することがわかりますが、シーンの混雑の程度を表す物理的なオブジェクトの場合、CILの故障率はCILRの故障率よりも高くなります。 CILRSは、CARLA100データセットで訓練されており、混雑したシナリオでの運転システムの正しい予測の問題を解決することに焦点を当てています。実験結果は、CILRが混雑したシナリオにおける自律運転システムの高い故障率の問題を軽減することを確認しています。言い換えれば、CILRの安全性はCILの安全性よりも優れています。

分解テストの緩和制限

セクション3.4のテスト予測の定義では、固定された真理値テストを回避するために緩和された変換テストを使用している場合、自律運転システムテストには多数の誤った陽性の問題がある可能性があります。セクション5.2では、ε= 0.17を使用して、物理的なオブジェクトを含まない天候シーンで実験を行うために使用され、ε1= 0.17およびε2= 0.2は、物理的なオブジェクトを含むシーンで実験を行うために使用されます。これらの2つの値は、経験に基づいて選択されます。このセクションでは、実験結果に対する緩和制限の値の影響を分析するために、εを調整することにより実験を実施します。 CILRSシステムの道路駆動モードは、まっすぐな道路でのテスト用に選択され、テストシステムはすべてのエンティティオブジェクトを生成することができました。実験は、それぞれε1= 0.17およびε2= 0.2で100回実行され、障害検出率を図6にプロットしました。

図6分解テストを使用した障害検出率と緩和制限の関係

図6では、破線ε1は、ε2= 0.2が固定され、ε1が値を取るときの障害検出率と緩和制限の関係です[0,0.5]。破線ε2は、ε1が0.17に固定され、ε2が値を取る場合、障害検出率と緩和制限の関係です[0,0.5]。 ε= 0の場合、障害検出率は100％ではないことに注意してください。これは、ε1とε2が同時に0ではないためです。図6から、緩和制限が徐々に増加するにつれて、障害検出率が低下し続けることが観察できます。緩和率が比較的小さい場合、システムは多数の誤検知を報告します。緩和率が大きい場合、システムは可能な危険なエラーを無視します。前に説明したように、自律的な運転試験の予測を設計することの難しさと緩和率を妥協する方法は、非常に複雑な問題であり、統計標準偏差は緩和の限界として使用されます。この数字によると、°検出率は0から0.1の範囲でεが増加すると急速に減少し、多数の偽陽性が除外され、緩和制限は0.1〜0.22の範囲で比較的滑らかであり、合理的な値の範囲と見なすことができます。さらに、自律的な運転タスクの場合、わずかに高い誤陽性は、障害シナリオの誤った除外を回避でき、実際のタスクには受け入れられないことがあります。これは、自律運転ミッションの失敗の有害性の程度によるものです。

シナリオカバレッジ分析

このセクションでは、さまざまな環境と駆動モードでの深い自律運転システムをテストして、テストシステムのカバレッジ機能を検証します。

環境テスト

私たちが提供する3つのテストシナリオは、荒野、田舎、都市の主な違いは、道路の両側の建物の高さが異なることであり、自律車のカメラのROIの異なる照明に影響を与えることです。マップのストレートパス領域では、それぞれCILとCILRをテストし、結果を表4に示します。

表4さまざまな環境での自律運転システムのテスト結果

表4から2つの結論を取得できます。

1）3つの異なる環境でテストされた場合、障害検出率は比較的近いです。これは、障害検出率に対する環境の影響が比較的小さいことを示しており、一方、異なる環境を設計するための基礎を確認します。

2）興味深いことに、私たちのビジョンでは、低光環境の都市での断層検出率は、直感によれば、夜間の運転が日中に運転するよりも発生する可能性が高いため、通常または高光の条件下で荒野や農村部の条件よりも高いはずです。ただし、表4のデータは予想される結果に反しており、低光条件での障害検索効率は実際には低くなっています。実験結果を観察することにより、通常の照明条件下では、自律運転車両のステアリング角は、一方の手の物理的なオブジェクトに依存し、他方では道路の中央の二重黄色のラインに依存すると推測します。二重黄色の線が部分的にブロックされると、運転出力の故障を引き起こす可能性が非常に高くなります。暗い点では、二重黄色の線は常に不明瞭になり、駆動出力は主にシーン内の他の物理的なオブジェクトに依存します。前の記事から、設計した駆動セマンティクスが維持されている方法が、変更せずに駆動セマンティクスの変更領域を決定するエンティティオブジェクトを作成し、代わりに障害の検索能力を弱めることがわかります。

運転モードテスト

条件付き自律駆動システムでは、オンボードカメラが撮影した画像に加えて、上層の制御コマンドは、現在の運転アクションで実行されるべきブランチアクションを決定します。自律運転システムには4つの運転モードがあります。つまり、道路に沿って運転し、左、右、まっすぐです。さまざまなシナリオで、道路に沿って運転モードをテストするためにまっすぐな道路を選択し、左、右、まっすぐ道路の3つの指示をテストするために交差点を選択しました。マップ上のさまざまな場所でテストする場合、シーンイニシャルイザーは、オンボードカメラの実際のFOVに合わせてサンプリングするためのエリア構成に応じてオブジェクト分布を再構成する必要があることに注意してください。テスト結果を表5に示します。 Cilrsは、異なる枝の下でCILよりも優れていることがわかります。

表5異なる枝の下での自律運転システムのテスト結果

CILRS駆動システムの脆弱性の分析

セクション2.5では、テストシステムで見つかったセキュリティの問題をさらに説明する方法について説明します。このセクションでは、CILRSシステムを例として使用して、次の質問に答えることにより、テストシステムの自動テスト機能を実証します。

質問1。CILRSシステムを失敗させる可能性が高い天候はどれですか？

すべてのオブジェクト制御機能を使用した実験の天気をゼロにするために、欠陥アナライザーを使用して、どの天気が自律運転システムを失敗させる可能性が高いかを判断します。

サンプリングによって異なる天候が得られるため、サンプルの数は異なるため、比較値が比較値として使用されるために発生しない天候の比率が図7に表示されます。

図7天候によって引き起こされるCILRSシステム障害の割合

欠陥分析器によって与えられる障害の原因は複数のオブジェクトである可能性があるため、この図の合計は100％を超えています。図7から、道路情報（特にぼやけた道路標識）を引き起こす蓄積された雨が自律運転システムの不安定性を引き起こす可能性が最も高いことがわかります。これに続いて、カメラセンサーの画面に干渉する降雨が続きます。風の強度は、主に降雨の傾向と道路の両側の葉の吹き付けに影響します。 CILRSシステムは、これらの気象条件での降雨環境からの干渉に最も影響を受けやすいことがわかります。

質問2。CILRS運転システムの重要な領域はどの領域ですか？

深い自律運転の重要な領域は、この領域に物理オブジェクトが現れると、自律運転の出力が不安定になる可能性が高いと定義されます。ストレートオブジェクトと物理オブジェクトに関する以前のテストの実験結果を分析しました。まず、障害を引き起こす検索シーンと元のシーンは、障害を引き起こすオブジェクトを分析するために処理のために欠陥分析装置に引き渡されます。次に、故障したオブジェクトの面積を図8にプロットし、水平座標は道路方向に沿ったX軸上にあり、垂直座標は道路の接線方向のy軸です。セットアップでは、自律車両の座標は（0、-2.27です。図8の統計結果は、CILRSシステムの敏感な領域が道路の両側の歩道にあることを示しています。

図8 CILRS運転システムの重要な領域の問題

3.どのオブジェクトがCILRSシステム障害を引き起こす可能性が高いですか？サンプルの数に対するシステム障害の比率は、CILRSシステム障害を引き起こすオブジェクトの確率を比較するための基準として使用されます。重複オブジェクトを削除し、エラー率が最も高い5つのエンティティオブジェクトを使用し、表6にオブジェクトと故障率をリストします。表6エンティティオブジェクトとその故障率

図8と表6から、2つのポイントを見つけることができます。

1）道路にある車両は、反対に不安定な原因ではない場合があります。 CARLA100データセットを観察すると、自律運転システムが複雑な道路状況のために訓練され、歩道のオブジェクトの複雑さを無視することがわかりました。

2）黄色と赤は、CILRSシステムの敏感な色です。これは非常に自然です。なぜなら、信号機の色は黄色と赤の音色になったとき、CILRはそれらを信号灯と誤解する可能性が高いからです。

テストシステムによって発見されたCILRの脆弱性は、このテストシステムを使用して、ネットワークトレーニング後のシステムのセキュリティを検証することができます。ネットワーク最適化ソリューションは、データ強化、構造最適化などになります。最適化後、テストシステムを使用して再度検証して、ディープネットワークがセキュリティニーズを満たしているかどうかを判断します。たとえば、CILRSシステムの場合、雨天のトレーニングデータを増やして、システムの安定性を改善し、黄色と赤のオブジェクトに対する感度を緩和するための二重保険メカニズムを設計することをお勧めします。

機能分析とインスピレーション

CILRSシステム障害の原因をさらに分析するために、CILRSシステムを開き、ResNetの特徴抽出層を観察しました。ほとんどの場合に見つかった障害シーンとオリジナルのシーンの機能抽出の結果は、一連の分析の間に特に明白ではなかったことがわかりました。

図9に示すように、環境は荒野に設定され、車両はストレートロードエリアにあり、駆動モードはテストに使用されます。自律型車両は、歩行者が配置されている異なる位置に従って、CILRSシステムによって予測される出力の変化を取得し、結果を図10に描画します。

図9障害分析の例：道路のそばを歩いている赤い服を着ている歩行者

図10図10によると、CILRSシステム出力の位置の変化は、歩行者が現れる前に比較的安定しています。歩行者が現れ始めると、CILRSシステムは影響を受け、変動しますが、常に断層範囲外です。車両センターの位置の約7.5m前に、予測される出力はブレーキスラムになります（ブレーキ効果は、ステアリング効果よりも優先されます）。その後、自律運転システムの出力は変動状態のままであり、車両の出力は歩行者が離れるまで安定化する傾向がありません（バイアス<0.1）。この動作は明らかに異常です。Cilrsがこの時点でブレーキをブレーキすることを決定した場合、歩行者が引き続き出力するべきではありません。 CILRS畳み込み層の最初の3層の出力は、車両中心の位置の前に7.5mの歩行者と歩行者がいない場合です。比較のために、歩道にベンチを配置すると、自律運転システムの出力が最大の変化をもたらします。図11では、ベンチを使用したシーンの3番目のレイヤーの畳み込み出力の結果は、オブジェクトのないシーンの畳み込み出力の結果と類似しており、歩行者のシーンの畳み込み出力は、オブジェクトのないシーンの畳み込み出力とは大きく異なります。

図11。最初の2つの列には、元の画像と特徴抽出の最初の2つの層に明らかな違いがありますが、3番目の層では比較的類似しています。最初の列と3番目の列の元の画像は、最初の3つのレイヤーとは大きく異なります。これは、写真の同じ場所にオブジェクトが表示されますが、機能から抽出されたコンテンツが異なることを示しています。これにより、1つまたは一部の機能レイヤーにモニターをセットアップし、モニターの変更を事前にシステムが失敗するかどうかを早期警告システムを分析するようになります。

図11 CILRS入力および畳み込み層出力

システム操作効率分析

このセクションでは、テストシステムの動作効率を分析します。テストシステムを展開するためのハードウェアプラットフォームはAMDR53600X + RTX3070であり、使用されるソフトウェアプラットフォームはWindows 10 + Unreal Engine 4.24.3 + Carla 0.9.11 + Python 3.9.1です。 動的シーンジェネレーターは、自律運転システムにエラーを引き起こすか、反復予算を超えるシナリオを検索するための最初のシーンに基づくテスト時間として定義されます。すべてのエンティティオブジェクトを考慮すると、オブジェクトの数は正規分布に基づいてサンプリングされ、レンダリングプロセスが含まれます。実験に費やされる平均時間は16.86です。レンダリングプロセスを除くと、平均値はモジュールテストを使用して各モジュールとその内部の詳細をテストします。

表7テストシステムの各モジュールの平均時間消費（MS）

10秒以上の単一の実験で費やした時間と比較して、各モジュールで費やされる時間は非常に低く、システムの主なパフォーマンスのボトルネックは、効率のレンダリングにあります。

自動車のシナリオで自律運転システムの安全性を確保するために、このペーパーでは、自律運転視覚認識モジュールのシナリオ駆動型安全テストシステムを設計および実装します。このシステムは、テストシステムのデータ分布を大幅に拡張することができます。この作業は、自律運転の認識モジュールのためのより多くのテストソリューションを刺激し、自動車インターネットのシナリオでの自律運転の分野の重要な安全基盤を提供すると考えています。