自動運転テストシステムを1つの記事で理解する

[[433515]]

自動運転のテストは非常に複雑なシステムです。この記事では、小さなものから大きなものまで、皆さんと一緒に整理していきます。

それを整理する前に、まずは質問しましょう。自動運転にはどのようなレベルのテストが必要なのでしょうか?

一般的な国際基準によれば、人間の運転手が1時間運転した後に死亡する確率は約1/10^6であり、世界中で毎年約125万人が交通事故で亡くなっています。自動運転車が開発されるなら、死亡確率はこの基準よりもはるかに低くなければなりません。調査によると、現在社会に受け入れられる自動運転の1時間あたりの死亡率は1/10^9を超えてはなりません。したがって、死亡率を 1/10^9 に減らすには、機能の信頼性を確保するために、ドライバーはソフトウェアが更新されるたびに 10^9 時間運転する必要があります。明らかに、実際の車両をテストするこの方法はお勧めできません。

実際のテスト システムでは、多くの場合、階層化された思考が活用され、さまざまなテスト方法とさまざまなコストやカバレッジ角度が組み合わされ、制御可能な時間とコストで実際の車両テストと同様の結果を達成できます。テスト方法によってコストは異なり、適切な反復回数も異なります。合理的なテスト システムを備えたプロジェクトの場合、モジュール ロジック テストで潜在的な問題の 60% 以上を回避する必要があり、シミュレーション機能パフォーマンス テストで残りの 30% の潜在的な問題を解決する必要があり、実際の車両の堅牢性テストでは最大 10% が残ります。各メソッド内で可能な限り潜在的な問題を発見し、後続のテストメソッドでの問題の数を制御するようにします。これらが合理的に一致していれば、非常に高いカバレッジを確保しながら、コストは制御可能な範囲になります。例えば、シミュレーションテストシステムが完備していれば、企画・開発において実車検証がほとんど不要となり、周辺サポートリソースを大幅に削減できます。

さまざまなテスト方法の比較

多段階のテスト方法を組み合わせるにはコストがかかります。特別なテストシステムを構築すると、構築サイクルが長くなったり、初期コストが高くなったりするなどの問題が発生することがよくあります。コンポーネントテストにおける CAE、DV、PV テスト、またはソフトウェアにおける静的、統合、シミュレーション テストのいずれの場合でも、進捗に追いつくために一部のテスト プロセスがバイパスされることがよくあります。

実際、これは経済的な説明です。特定のフロントエンド テスト プロセスを省略すると、フロントエンド プロセスから残された問題を解決するために高コストのバックエンド テスト プロセスによって消費されるリソースが、フロントエンド プロセスの設定コストよりも高くなると、テスト システム全体が不採算になり、その逆も同様です。

適切なレベルのテストもバランスを取る行為です。

しかし、一般的に言えば、継続性と成熟度の高い研究開発システムでは、より階層的で相互に直交するテスト システムと効率的な循環を組み合わせることで、より高い効率が達成されることが多いです。

本当に効果的なテストでは、多くの場合、特定のテスト ツールと特定のテスト ケースを使用して、テスト対象のオブジェクトの特定の側面における問題を確認します。特定の種類の潜在的な問題を対象とし、他の手段よりもコストが低く、他の手段よりも広範囲の問題をカバーしている限り、どのようなテスト システムでも良いテスト システムです。テスト システムの種類は関係ありません。これらは、後から人為的に強制的に分割される概念です。テストの設計においては、実用的であることが重要です。

エンジニアリング実務におけるテストプロセス

さらに、テスト パイプラインはトレーニング パイプラインの一部となることもよくあります。これまで、テスト システムの役割は、主に人為的エラーによって引き起こされる潜在的な製品リスクを排除することでした。

最もよく知られているのはテスト駆動開発 (TDD) です。これは、特定の機能のコードを書く前にテスト コードを記述し、その後テストに合格する機能コードのみを記述して、テストを使用して開発を推進する必要があります。

そして現在、自動運転は自己監視プロセスへと移行しており、機械間の相互作用が増えています。これには、テストのフィードバックやマシン間の開発調整も含まれます。これは、私たちがよく知っているディープラーニングです。人々にとって、テストとは、製品が目標と一致していることを確認することです。機械の場合も、トレーニングは同様の目標を達成することを目的としています。

上記はテストの基本的な考え方です。次に、インテリジェント運転の一般的なテスト プロセスを詳しく見てみましょう。下の図に示すように、異なる協力モデル、異なる分野の専門性、異なる技術セクションの3つの側面から体系的なレビューを実施できると個人的には考えています。

自動運転の一般的なテスト方法

異なる協力モデルの観点から、ブラックボックステスト、ホワイトボックステスト、グレーボックステストに分けることができます。

ホワイトボックステストは、内部構造の各パスが設計どおりに正常に動作するかどうかをチェックするもので、一般的には製品提供者の内部管理に使用されます。ブラックボックステストは、一般的には内部構造を考慮せず、製品機能が契約の技術要件に従って実装されているかどうかのみをチェックするもので、一般的には提供先の内部管理に使用されます。グレーボックステストは、上記の2つのレベルのテストの中間です。外部機能のテストに基づいて、重要なリンクを確認します。一般的には、提供者のリリーステストまたは提供先の受け入れテストに使用されます。具体的なレベルは、具体的な協力によって異なります。

さまざまな分野の観点から見ると、さまざまな分野には独自の問題とそれに対応するテストの次元があります。

ソフトウェアコードから、静的テスト、動的テストなどがあります。静的テストでは、プログラムの文構造、プログラミング仕様などに誤りや不適切さがないかを分析します。よく使用されるツールにはQAC / Converityなどがありますが、これらはテストシステム全体に占める割合は小さく、一般的にソフトウェアテストの最初のステップです。これに似たコードレビューでは、関連する専門家を組織してコードの静的設計を評価します。一方、動的テストでは、プログラムを実行した後の結果を期待と比較し、動作効率と堅牢性を分析します。現在、自動運転のソフトウェアテスト対象のほとんどは、パフォーマンステストやさまざまなインザループテストなど、動的テストのカテゴリに属しています。

さまざまな技術セクションから開始することは、すべての分割モードの中で最も複雑かつ重要です。

まず、セクションを設定する意味について説明します。複数の要因が絡む複雑なシステム問題に直面した場合、セクションを設定することで、影響する変数を分離し、複雑さをテスト可能なレベルまで簡素化できます。同時に、本来は連続的だったトラブルシューティングタスクを並列タスクに変換し、プロジェクトスケジュールを短縮できます。

下の図に示すように、最下層はユニットテスト、モジュールテスト、モジュール統合テストです。 R&Dプラットフォーム（X86）では、ソフトウェア機能の入出力、単一または複数のモジュールをセクションとして使用し、コードロジックの正確性を検証することが中心となります。 VectorCast や GTest などのツールを通じて、多数の誤った入力と少数の正しい入力がテスト対象オブジェクトに注入され、フィードバックが期待どおりであるかどうかが確認されます。このプロセスは通常、オープン ループです。

モジュールレベルのテストは、一般的にモデルインザループ (MIL) とも呼ばれます。部分的な正確性を考慮するだけでなく、認識モジュールの認識精度などのモデルパフォーマンス指標もいくつかあります。

ソフトウェアロジックレベルでのテスト方法

X86 上で安定して動作するソフトウェアでも、組み込み環境ではスタック オーバーフロー、スケジュールの混乱、不安定なタイムスタンプ、不十分なシステム コール サポート、メモリ読み取り例外、操作のブロックなど、一連の問題が発生する可能性があります。この矛盾を調査するため。下の図に示すように、ソフトウェア ロジック レベルより上位にターゲット ハードウェア次元、つまりプロセッサ イン ザ ループ (PIL) テストを導入できます。これは、コードの一部をターゲット プロセッサに配置して、コードの機能的正確性を検証し、そのパフォーマンスが要件を満たしているかどうかを確認するテストです。たとえば、ソフトウェアにかかる最長時間、システムコールの信頼性などです。ソフトウェアインザループ テストでは一般的に正確性を評価し、ハードウェアインザループ テストでは一般的に安定性を評価します。

PILテスト方法

下の図に示すように、上記のテストはすべて一般にオープンループであり、環境との相互作用は検証されません。ソフトウェアとハ​​ードウェアの次元で仮想環境または現実環境との相互作用を追加すると、ソフトウェアインザループテスト SIL (ソフトウェアインザループ) とハードウェアインザループテスト HIL (ハードウェアインザループ) の概念が作成されます。

環境要素を導入した後は、テストケースとしてシナリオライブラリも導入します。テストプロセスでは、基本ロジックの検証に加えて、インテリジェント運転の運用サービス指標のいくつかも評価します。

SIL テストは、対象ハードウェアを考慮せず、低コストでサーバー上に大量に導入できます。その主な機能は、インテリジェント運転機能のクローズドループ動作の正確性を検証することです。これは、セマンティック レベルのシミュレーション システムを使用した部分的なクローズド ループ テストと、環境レンダリング レベルのシミュレーション システムを使用したソフトウェアのフル機能のクローズド ループ テストに分けられます。

SILは現在最も有望なテスト方法の1つなので、簡単に紹介します。ユニットテストやモジュールテストなどの方法は自動化率が高いものの、インテリジェント運転システムの機能上の問題を直接発見することはできません。ハードウェア・イン・ザ・ループ・テストと実車テストではより直感的に問題を発見できますが、コストが高くなります。 SIL はこれらの方法のバランスが取れており、非常に費用対効果の高い手段です。 SIL システムは、内部から外部まで再現性を保証するように設計されています。テストで過去の実験結果を再現できない場合、その後の評価に大きな影響を与えます。マルチスレッド化などの理由により再現性を完全に維持できない場合は、そのばらつきと安定性を確認するために複数の実験が必要になります。テストシステム全体の視点で見ると、内部に近いほど（単体テストなど）、再現性を制御しやすく、外部に近いほど（実車テストなど）、制御が難しくなります。 SIL システムの外側から見ると、その核心は自動化率と大規模並列展開能力であり、これはテスト システム全体の包括的な分析という点では最大規模のテスト方法です。人員を削減し、同時展開機能を向上させることで、テスト コストを効果的に削減し、テスト効率を向上させることができます。インテリジェント運転のクローズドループ システムでは、SIL システムはテストに加えて、計画の反復トレーニングにも役立ち始めます。シミュレーション テストにおける安全性評価、機能評価、規制要件評価、快適性評価などで使用される指標とユース ケースは、実際には規制トレーニング プロセスにおける一種の「損失関数」です。

HIL テストは、ターゲット ハードウェアを考慮する必要があるという点で SIL とは異なり、コストが高いため、通常は大量に導入されません。その結果は SIL よりも実際の状態に近いだけでなく、ターゲット ハードウェア上のソフトウェアの全体的なパフォーマンス (実行スケジュール、メモリ呼び出し、コンピューティング パワー呼び出し) が期待どおりであるかどうかも評価できます。 HIL テストでは通常、テスト対象のコントローラをハードワイヤ (PWM、UART、CAN、GPIO など) を介して一連のアナログ デバイスに接続し、記録またはシミュレートされた生データを逆に実際の信号入力に構築して、対象ハードウェアのテストを完了します。実際には、フル機能のロングサイクル HIL ベンチにこだわるべきではないと個人的には考えています。軽量 HIL ベンチ (PIL ベンチ) 20 台の価格は、フル機能 HIL ベンチ 1 台の価格よりも安い可能性があります。両者の効果に大きな違いはありません。部分的に物理的な IO と部分的に機能的なシミュレーションは、多くの場合、より科学的です。HIL ベンチは通常、短いサイクルのクローズドループ テストにのみ使用され、長いサイクルのテストではエラーが大きくなることがよくあります。

SILおよびHILテスト方法

単一コントローラのテストが完了した後、下の図に示すように、インテリジェント運転テストは車両レベルに続きます。まず、車両インループテストVIL（Vehicle-in-Loop）または実車仮想注入テストを紹介します。つまり、ソフトウェア内の断面テストインターフェイスを構成することにより、閉じたテストフィールドの実車テスト環境で、一部の実際の感覚入力がシールドされ、テストフィールドのオープンエリアであらゆる形式の道路環境をシミュレートします。たとえば、存在しない車両を道路に追加したり、交差点での信号の切り替えをシミュレートしたりします。その他の試験要素は実際のコンテンツであるため、試験の信頼性が高く、閉鎖された試験場の環境資源を十分に活用できます。

VILテスト方法

VIL のもう 1 つの新しい形式は、屋内会場で周囲の環境と車両の動きの変化をシミュレートしてスマート運転車両をテストする車両交通環境インザループ テスト (VTEHIL) です。環境は完全に制御されており、気候変動の影響を受けないため、24時間連続テストが可能で、過酷な作業条件を効率的かつ完全にシミュレートできます。

VTEHIL試験方法

さらに下には、ロードインループテスト RIL (Road-in-Loop) またはクローズドフィールドテストがあります。環境参加者とドライバーを除いて、他のすべての要素は現実です。

従来の自動車試験システムでは、このような試験方法も日常的な作業となっています。しかし、これまでの手動による遠隔制御や配置による実施方法とは異なり、現在は自動化された試験ソリューションが登場しています。最新のダミーカー設備には、必要なセンサー、アクチュエータ、通信機器も装備されているため、クラウドに接続して集中的な指令やディスパッチを行うことができます。したがって、クラウド内のテストケースは、クローズドテストフィールドに同期され、スマートダミーや偽の車によって「実行」される可能性があります。テストを完了する効率が大幅に向上します。

RIL テスト方法

コントローラー レベルのテストと比較して、車両レベルのテストでは、テイクオーバー率、堅牢性、その他の指標などのエクスペリエンス指標に重点が置かれます。車両レベルのテストには、VIL と RIL に加えて、LabCar テストや大規模な実車テストも含まれ、これらは車両の他の従来のテスト プロセスと一緒に実行されます。

LABCAR テストベンチ

単一のインテリジェント ドライビング コントローラーのテストが完了したら、車両部門に渡して電子および電気アーキテクチャ全体のテストを行う必要があります。このテストは LABCAR テストと呼ばれます。LABCAR テストは、複数のコントローラーで構成されるハードウェア イン ザ ループ (HIL) テストとも呼ばれます。周辺センサーやアクチュエーターの情報をシミュレートすることで、電子・電気システム全体が正常に動作しているかどうかを検出できます。同時に、LABCARは故障（短絡、断線など）を人工的に注入して、異常状態での応答が期待どおりかどうかを検出することもできます。

システム テストと比較すると、車両テストでは個々の機能ではなく、複合的な影響をもたらす可能性のある共通の次元に重点が置かれることがよくあります。例えば、車両全体の異音性能試験など。関連する多くの問題では、関係するコンポーネントは、単体のベンチテストやシステムレベルのベンチテストでは再現できないことが多く、完成した車両状態で特定の特殊な動作条件下でのみ出現します。

車両テストの一般的な方法は、公道テストです。まず、パワー、経済性、ブレーキ、操縦安定性、追従性など、自動車の 6 つの基本性能には、定量分析のための標準的な客観的テストがあります。スムーズさはエンジニアによる調整が必要になる場合があり、スタイルによって若干異なります。さらに、さまざまな極限環境（高原、極寒、高温）での総合的なテストが実施されます。これが、「冬は黒河へ、夏は海南へ」という格言の由来です。一般的に言えば、すべてのテストのテスト条件は通常の車両の使用条件よりもはるかに厳しくなり、テストの効率を効果的に向上させることができます。もちろん、車両全体の環境でのみ実行できる、前述のNVH性能や耐久性能も含まれます。一般に、車両テストのコアロジックは、コンポーネントテストのコアロジックと似ています。テストにはライセンス、保険、ドライバー、その他多数の人的およびセキュリティ リソースが必要となるため、時間と費用が高くなります。したがって、車両テストはより洗練され、厳密に計画されることが多いです。実験条件の数とテストの数は正確に計算され、通常は理論と経験に基づいて推定されます。車両テストのもう一つの目的は、政府の承認を得ることです。中国では乗用車に対して40項目以上の検査基準が義務付けられており、市場で販売される車両はこれらの検査に合格しなければならない。

大規模な実車テスト

インテリジェント運転システムには、従来の道路テストとは少し異なる理由から、大規模な公道テストも必要です。実際の交通はより多様であり、運転シミュレーターや制御されたフィールドテストではそのごく一部しか再現できないため、評価結果が実際の状況から逸脱する可能性があります。そのため、交通環境全体におけるスマート運転車両の動作を検証するためには、大規模な路上テストが必要です。公道テストでは、機能データ、動作データ、環境データを同期的に収集する必要があります。機能データは、多くの場合、インテリジェント運転システム自体から取得されます。行動データの中核は、追加で設置された内部カメラ、視線追跡装置、生理学的検出装置から得られるドライバーの反応を監視することです。環境データは、車両自体の環境センサーと、レーザー、インストゥルメンタル、高解像度カメラなど、追加で設置された高性能の感知装置の両方から取得されます。もちろん、この方法はデータクローズドループに置き換えられました。

上記は、インテリジェント運転システムに関連するすべてのテスト方法の紹介です。個人がこれらすべてのタスクにアクセスするのは難しい場合が多いですが、全体像を理解することは、個人が研究開発における独自のテストタスクの重要性を理解するのに役立ちます。