期待される機能安全シナリオライブラリの複雑な定量化手法に関する研究
Pegasus シーン階層化システムに基づいて、シーン データの品質を評価するためのシーンの複雑さの定量的方法が提案されています。この方法では、各層の要素の行列式を求め、その行列式に基づいて各層の要素の複雑度を求め、各層の要素の複雑度の和を計算することでシーンデータの総複雑度を求める。また、「複雑すぎる」現象を防ぐために、シーン要素の複雑さに要素の出現確率を乗じて計算する「母子ライブラリ」手法や「システムシナリオ確率」手法が提案されている。修正された複雑さを取得します。研究結果は、この方法によって合理的で使用可能なシーン ライブラリを構築できることを示しています。
自動運転車の安全上の問題によって引き起こされる危険の主な理由には、次の 2 つの側面が含まれます。 (1) 電子的および電気的な故障またはソフトウェア システムの故障によって引き起こされる危害。このため、ISO は ISO26262「道路車両 - 機能安全規格」を提案し、中国は対応する GB/T 34590「道路車両 - 機能安全規格」を提案しました。 (2) 不十分なシステムパフォーマンスまたは合理的に予見可能な人間の誤用によって引き起こされる損害。このため、ISO は、SOTIF 標準と呼ばれる ISO/PAS 21448 意図された機能の安全性を提案しました。
SOTIF 規格では、自動運転車が走行中に直面するシナリオは、既知の安全なシナリオ、既知の危険なシナリオ、未知の安全なシナリオ、未知の危険なシナリオの 4 つのカテゴリに分類されています。図1。既知のセキュリティ シナリオと未知のセキュリティ シナリオについては、SOTIF 標準では考慮されていません。既知の危険なシナリオに対して、SOTIF 標準は方法論を提案しています。目的は、自動運転車関連システムの性能向上や関連システムの動作領域の縮小、関連シナリオライブラリに基づくテスト・検証、つまり既知の危険なシナリオを既知の安全なシナリオに変換することです。
未知の危険なシナリオについては、シナリオ ライブラリに基づいて多数の実験を実行して、関連システムの潜在的な安全上の危険シナリオを発見して検出できます。つまり、未知の危険なシナリオを次のようなシナリオに変換できます。危険な場面。最後に、上記の方法論に基づいて、既知の危険なシナリオが既知の安全なシナリオに変換されます。つまり、SOTIF規格の目標は、自動運転車関連システムが走行時に直面する既知の安全性シナリオと未知の安全性シナリオの範囲を可能な限り拡大し、それによって既知の危険と未知の危険シナリオの範囲を可能な限り狭めることです。 、図 2 に示すように。上記の目標を達成するために、重要な要素の 1 つは、予想される機能安全シナリオの高品質なライブラリを構築することです。
現在、多くの企業や組織が、予想される機能安全シナリオの独自のライブラリを構築しています。例: Kitti シーン ライブラリ、NuScenes[6] シーン ライブラリ、Lyft 自動運転車シーン ライブラリなど。ほとんどの企業や組織は、シーン ライブラリの構築プロセス中にシーン ライブラリ データの収集に重点を置いていますが、収集されたシーン データの品質についての合理的な定量的指標が不足しています。
これは間違いなく 2 つの問題を引き起こします:
(1) シーン ライブラリには、大量の重複した低品質のシーン データが含まれる可能性があります。その結果、シーンライブラリに基づくテスト時間が長すぎ、自動運転車の性能欠陥さえも発見できず、テスト結果の信頼性が低下します。
(2) 異なるシーン ライブラリの長所と短所を比較することができないため、自動運転車シーン ライブラリ テストに最適なシーン ライブラリ データを選択できません。したがって、シーンライブラリの品質を定量化するために科学的かつ合理的な方法を採用することが非常に必要です。シーンデータが複雑になればなるほど、関連するシステムに対する課題が大きくなり、関連するシステムのパフォーマンス欠陥が検出される可能性が高くなります。したがって、シーン データの複雑さは、シーン ライブラリの品質に影響を与える重要な要素の 1 つであると考えられます。
この記事では、シーン データの複雑さを定量化する方法を提案します。この手法は、ドイツの Pegasus プロジェクトのシーン階層化システムに基づいており、シーン内の要素を分類およびカウントすることで、シーン データ内の要素の複雑さを計算し、シーン データの品質を評価します。
1 Pegasus シーン レイヤリング システム
Pegasus プロジェクトは、自動運転に関連する一連のテスト標準を開発するために、ドイツの自動車業界の関連企業と研究機関によって共同で開始されました。目的のための車両。このプロジェクトは、シーン階層化システムを提案します。つまり、シーンは、さまざまなシーン要素に従って 6 つのシーンのレイヤーに分割されます (表 1 を参照)。
シーン データを図 3 に示します。 Pegasus シーン階層化システムに基づいて、表 2 に示すようにシーン データを階層化できます。
Pegasus シーン レイヤ化システムレイヤーシーン要素。この記事では、各層の要素をさらに分析し、要素の各層の複雑さを定量化します。
道路レイヤーの複雑さは、主に車線の可視性によって決まります。表 3 を参照してください。明確な車線の場合、複雑さは 1 に設定されます。車線の詰まりや磨耗は車線の認識に影響し、複雑さは 2 に設定されます。道路の水の蓄積や車線を覆う氷は、車線の認識に影響するだけでなく、運転の原因にもなります。困難、複雑さ 3; 不規則な車線は車線の誤認識を引き起こし、車両が間違った方向に移動する可能性があります (複雑さ 4); 車線のないシナリオは車両の進行方向に影響を与える可能性があります、複雑さ 4 4の5です。
交通施設レイヤーの複雑さは、主に交通施設の可視性によって決まります。表 4 を参照してください。交通機関のないシーンの複雑さは 1、明確な交通機関のあるシーンの複雑さは 2、遠すぎて明確に識別できない交通機関のあるシーンの複雑さは 3、交通機関は反射しており、特定が困難なシナリオの複雑さレベルは 4、交通施設が不規則であり、誤認を引き起こし、赤信号の走行などの危険行為につながる可能性があり、複雑さレベルは 5 です。
#一時的な交通イベント レイヤーの複雑さは、主にイベントの偶発性と予測可能性によって決まります。表5を参照してください。一時的な交通事故がない場合、複雑さは 1、交通規制などの一時的な交通事故があり、現場を維持する専任の人員がいる場合、複雑さは 2、警告のある道路工事などの一時的な交通事故がある場合、複雑さは 2標識の複雑さは 3、交通事故など 運転に大きな影響を与える一時的な交通事象の複雑さは 4、落石や車輪の脱落など、非常に散発的で予測が困難な一時的な交通事象の複雑さは 1複雑さは5。
トラフィック参加者層の複雑さは、参加者の共通性とコンプライアンスによって決まります。表 6 を参照してください。交通参加者がいない場合、複雑さは 1、シーンに車両のみが含まれている場合、複雑さは 2、歩行者や自転車などの一般的な参加者が含まれており、規制で指定された場所 (歩道、自転車レーンなど) に位置している場合、複雑さは 2 です。 、など)の場合、複雑度は 3 ; 歩行者や自転車などの一般的な参加者が含まれており、規制で指定された位置にいない場合(道路を横断する歩行者、自動車専用道路を走行する自転車など)、複雑度は 4;珍しい交通参加者(象を引きずるトラックなど)、馬に乗った歩行者など)、その複雑さは 5 です。
環境条件レイヤーの複雑さは主に可視性によって決まります。表 7 を参照してください。晴れた日の高い視認性の複雑さは 1、雨の日と夕方の中程度の視認性は複雑さ 2、夜間は環境光があり、その複雑さは 3、夜間は環境光がなく、視認性が低い、複雑さは 4; 濃霧 空の可視性は非常に低く、複雑さは 5 です。
情報層の複雑さは、主に交通情報があるかどうかによって決まります。表を参照してください。 8.高精度地図がある場合、または V2X が交通情報を提供する場合、複雑度は 1、高精度地図がない場合、または V2X が交通情報を提供する場合、複雑度は 2 になります。
上記の階層化手法と各階層の複雑度定量化手法により、単一のシーンデータの複雑度、つまり各階層の複雑度の合計を計算することができます。たとえば、図 3 のシーン データの複雑さは 18 です (各レイヤーの複雑さについては、表 9 を参照してください)
シーン ライブラリ全体について、各シーン データの複雑さを追加します。次に、それをシーン ライブラリ内のシーン データの総数で割って、シーン ライブラリ全体の複雑さを取得します。さまざまなシーン ライブラリの品質は、シーン ライブラリの複雑さに基づいて比較できます。
スペースの制限により、上記の各レベルの複雑さの表にはすべての要素がリストされ、カバーされているわけではないことに注意してください。列挙またはカバーされていない要素の場合、その複雑さは、それらが配置されているレイヤーの複雑さを決定する要因に基づいて決定される必要があります。たとえば、環境条件レイヤーの複雑さの決定要因は可視性であり、リストにない低濃度の霧の日の場合、可視性は夜間の環境光の可視性と同等であるため、複雑さは 3 になります。
3 シーン データの複雑さの修正
上記の複雑な定量化手法を使用してシーン ライブラリを構築すると、「過度の複雑さ」という現象が発生します。つまり、シーン ライブラリの複雑さを追求するために、シーン ライブラリは複雑度の高いシーンのみを収集しており、その結果、シーン ライブラリの複雑さは非常に高いものの、発生確率は非常に高くなります。結局、システムのパフォーマンス上の欠陥を発見することはできません。 「過度の複雑さ」現象を回避するために、この記事では「母子ライブラリ」と「システムシナリオ確率」という 2 つの概念を提案します。
3.1 母子図書館実際の現場の図書館収集プロセスでは、ランダムな場所、ランダムな期間、ランダムな気候、ランダムな収集方法によってデータが収集されます。等が「マザーライブラリー」を構成します。そして、当該システムの特性や動作領域に基づいて、「マザーライブラリ」から「サブライブラリ」を抽出する。例:高速道路のみに適用可能な自動運転システムの場合、高速道路のシーンデータを「親ライブラリ」から抽出して「サブライブラリ」とします。たとえば、特定の都市向けに開発された自動運転システムの場合、その都市のシーン データが「マザー データベース」から抽出され、システムの「サブ データベース」が形成されます。
注目に値します: 理論的には、最初に「マザー ライブラリ」を構築してから「サブ ライブラリ」を抽出することも、最初に「サブ ライブラリ」を構築することもできます。それを「マザーライブラリ」に集めます。ただし、この記事では「母親が第一、息子が二番目」のアプローチを推奨しています。 「マザーライブラリ」の構築はランダムであるため、「マザーライブラリ」から抽出された「子ライブラリ」もランダムな属性を持ちます。 「サブライブラリ」が最初に構築される場合、また「サブライブラリ」はシステム固有であるため、構築プロセスで完全なランダム性を達成することは困難です。
3.2 システムシナリオの確率「マザーライブラリ」から抽出した「サブライブラリ」について、システム実行中にシナリオの各層の要素をさらに分析します。発生確率はシステムシナリオ確率です。例: 高速道路のみに適した自動運転システムの場合、交通参加者層に車両のみが含まれる確率 (複雑さ 2) は、歩行者と自転車が含まれる確率 (複雑さ 3) よりもはるかに高くなります。したがって、この層の要素の複雑さを評価するときは、この層の最終的な複雑さを取得するために、複雑さに確率係数を乗算することも必要です。式は次のとおりです:
#
式内: C はシーン データの最終的な複雑さ、 は
レイヤー シーン要素の複雑さ、
は、当該システムの実行時に出現する
# 層のシーン要素の確率係数です。
3.3 「複雑すぎる」現象の防止
「母子ライブラリ」と「システム シナリオの確率」によって「複雑すぎる」現象を回避できます。 。主な理由は次のとおりです。 (1) 「マザーライブラリ」を建設する際、「マザーライブラリ」の収集プロセスにおける人的要因を減らすために、ランダムな場所、ランダムな期間、ランダムな気候などのランダムな収集方法が使用されます。 (2) 特定のシステムに対して、「マザーライブラリ」から該当する「サブライブラリ」を抽出することで、「サブライブラリ」における人的要因を間接的に回避します。 (3) システム稼働時のシーンの発生確率と複雑度に基づいて、最終的なシーンの複雑度を計算します。複雑さと確率という客観的要因を組み合わせることで、人的要因の影響を回避できます。たとえば、複雑度が高く確率が低いシーン要素、または複雑度が低く確率が高いシーン要素の場合、最終的なシーンの複雑さの値は低くなる可能性があります。
3.4 確率係数の値
確率係数はシステムごとに異なります。例: 高速道路での使用に限定されたシステムの場合、交通参加者レイヤーに表示される車両のみの確率係数は、歩行者や自転車の確率係数より大きくなります。都市交通シナリオで使用できるシステムの場合、確率係数は、交通参加者層に出現する歩行者と自転車の確率係数は、車両のみの確率係数よりも大きくなります。さらに、同じシステムでも、自動運転開発プロセスの異なる段階では、その確率係数も異なる可能性があります。例: この段階では、情報層に高精度マップまたは V2X を備えたシステムの確率係数は、高精度マップまたは V2X を持たないシステムの確率係数よりも低くなります。自動運転開発の後期段階では、高精度地図や V2X を備えたシステムの確率係数が、高精度地図や V2X を備えていないシステムよりも高くなる可能性があります。
したがって、さまざまなシステムについて、その運用範囲、場所、時間、ターゲット市場、市場全体のレベルなどの多くの側面を考慮して、さまざまなシナリオの確率を決定する必要があります。要素、係数。
4 結論
ISO/PAS 21448 の要件を満たすためには、予想される機能安全シナリオのライブラリを構築する必要があります。ただし、シーン ライブラリの構築品質には、対応する定量的な指標がありません。この記事では、Pegasus シーン階層化システムに基づいて、要素の各層の複雑さを定量化し、シーン ライブラリの品質を評価します。同時に、「過度の複雑さ」現象を回避するために、「母子ライブラリ」と「システムシナリオ確率」という 2 つの概念が提案され、「母子ライブラリ」をどのように構築するか、およびどのように構築するかが提案されます。 「システムシナリオの確率」を計算する方法について説明し、これに基づいて最終的な複雑度の計算方法を説明します。この記事で述べた定量化手法と「過度の複雑さ」を防ぐ手法は、期待される機能安全シナリオ ライブラリの確立と推進において示唆的な役割を果たします。
以上が期待される機能安全シナリオライブラリの複雑な定量化手法に関する研究の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

AI Hentai Generator
AIヘンタイを無料で生成します。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック











昨日の面接で、ロングテール関連の質問をしたかと聞かれたので、簡単にまとめてみようと思いました。自動運転のロングテール問題とは、自動運転車におけるエッジケース、つまり発生確率が低い考えられるシナリオを指します。認識されているロングテール問題は、現在、単一車両のインテリジェント自動運転車の運用設計領域を制限している主な理由の 1 つです。自動運転の基礎となるアーキテクチャとほとんどの技術的問題は解決されており、残りの 5% のロングテール問題が徐々に自動運転の開発を制限する鍵となってきています。これらの問題には、さまざまな断片的なシナリオ、極端な状況、予測不可能な人間の行動が含まれます。自動運転におけるエッジ シナリオの「ロング テール」とは、自動運転車 (AV) におけるエッジ ケースを指します。エッジ ケースは、発生確率が低い可能性のあるシナリオです。これらの珍しい出来事

先頭と開始点に書かれている エンドツーエンドのパラダイムでは、統一されたフレームワークを使用して自動運転システムのマルチタスクを実現します。このパラダイムの単純さと明確さにも関わらず、サブタスクにおけるエンドツーエンドの自動運転手法のパフォーマンスは、依然としてシングルタスク手法に比べてはるかに遅れています。同時に、以前のエンドツーエンド手法で広く使用されていた高密度鳥瞰図 (BEV) 機能により、より多くのモダリティやタスクに拡張することが困難になります。ここでは、スパース検索中心のエンドツーエンド自動運転パラダイム (SparseAD) が提案されています。このパラダイムでは、スパース検索は、高密度の BEV 表現を使用せずに、空間、時間、タスクを含む運転シナリオ全体を完全に表します。具体的には、統合されたスパース アーキテクチャが、検出、追跡、オンライン マッピングなどのタスク認識のために設計されています。さらに、重い

目標検出は自動運転システムにおいて比較的成熟した問題であり、その中でも歩行者検出は最も初期に導入されたアルゴリズムの 1 つです。ほとんどの論文では非常に包括的な研究が行われています。ただし、サラウンドビューに魚眼カメラを使用した距離認識については、あまり研究されていません。放射状の歪みが大きいため、標準のバウンディング ボックス表現を魚眼カメラに実装するのは困難です。上記の説明を軽減するために、拡張バウンディング ボックス、楕円、および一般的な多角形の設計を極/角度表現に探索し、これらの表現を分析するためのインスタンス セグメンテーション mIOU メトリックを定義します。提案された多角形モデルの FisheyeDetNet は、他のモデルよりも優れたパフォーマンスを示し、同時に自動運転用の Valeo 魚眼カメラ データセットで 49.5% の mAP を達成しました。

純粋に視覚的な注釈ソリューションでは、主に視覚に加えて、GPS、IMU、および車輪速度センサーからのデータを動的注釈に使用します。もちろん、量産シナリオでは、純粋な視覚である必要はありません。一部の量産車両には固体レーダー (AT128) などのセンサーが搭載されています。大量生産の観点からデータの閉ループを作成し、これらすべてのセンサーを使用すると、動的オブジェクトのラベル付けの問題を効果的に解決できます。しかし、私たちの計画には固体レーダーはありません。したがって、この最も一般的な量産ラベル ソリューションを紹介します。純粋に視覚的な注釈ソリューションの中核は、高精度のポーズ再構築にあります。再構築の精度を確保するために、Structure from Motion (SFM) のポーズ再構築スキームを使用します。でもパスする

以上、筆者個人の理解 近年、自動運転はドライバーの負担軽減や運転の安全性の向上につながる可能性があるため、注目が高まっています。ビジョンベースの 3 次元占有予測は、自動運転の安全性に関する費用対効果の高い包括的な調査に適した新たな認識タスクです。オブジェクト中心の知覚タスクと比較して 3D 占有予測ツールの優位性は多くの研究で実証されていますが、この急速に発展している分野に特化したレビューはまだあります。このホワイトペーパーでは、まずビジョンベースの 3D 占有予測の背景を紹介し、このタスクで直面する課題について説明します。次に、現在の 3D 占有予測手法の現状と開発傾向を、機能強化、展開の容易さ、ラベル付けの効率という 3 つの側面から包括的に説明します。やっと

上記と著者の個人的な理解: この論文は、自動運転アプリケーションにおける現在のマルチモーダル大規模言語モデル (MLLM) の主要な課題、つまり MLLM を 2D 理解から 3D 空間に拡張する問題の解決に特化しています。自動運転車 (AV) は 3D 環境について正確な決定を下す必要があるため、この拡張は特に重要です。 3D 空間の理解は、情報に基づいて意思決定を行い、将来の状態を予測し、環境と安全に対話する車両の能力に直接影響を与えるため、AV にとって重要です。現在のマルチモーダル大規模言語モデル (LLaVA-1.5 など) は、ビジュアル エンコーダーの解像度制限や LLM シーケンス長の制限により、低解像度の画像入力しか処理できないことがよくあります。ただし、自動運転アプリケーションには次の要件が必要です。

中国科学院オートメーション研究所の深層強化学習チームは、Li Auto氏らとともに、マルチモーダル大規模言語モデルMLLM(PlanAgent)に基づく自動運転のための新しい閉ループ計画フレームワークを提案した。この手法は、シーンの鳥瞰図とグラフベースのテキスト プロンプトを入力として受け取り、マルチモーダル大規模言語モデルのマルチモーダル理解機能と常識推論機能を利用して、シーンの理解から生成までの階層的推論を実行します。水平移動と垂直移動の指示を作成し、プランナーが必要とする指示をさらに生成します。このメソッドは、大規模で困難な nuPlan ベンチマークでテストされており、実験では、PlanAgent が通常のシナリオとロングテール シナリオの両方で最先端 (SOTA) のパフォーマンスを達成することが示されています。従来の大規模言語モデル (LLM) メソッドと比較して、PlanAgent

1 意思決定制御と動作計画の概要 現在の意思決定制御方法は、逐次計画、行動認識型計画、およびエンドツーエンド計画の 3 つのカテゴリに分類できます。逐次計画: 最も伝統的な方法であり、認識、意思決定、制御の 3 つの部分が比較的明確です。行動を意識した計画: 最初の方法と比較して、ハイライトは人間と機械の共同運転、車両と道路の導入です。外部動的環境のコラボレーションと車両リスク推定。エンドツーエンドの計画: DL および DRL テクノロジーは、画像やハンドルのコーナーなどの感覚情報を取得するために大量のデータ トレーニングを使用します。
