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 プロジェクトのシーン階層化システムに基づいており、シーン内の要素を分類およびカウントすることで、シーン データ内の要素の複雑さを計算し、シーン データの品質を評価します。
Pegasus プロジェクトは、自動運転に関連する一連のテスト標準を開発するために、ドイツの自動車業界の関連企業と研究機関によって共同で開始されました。目的のための車両。このプロジェクトは、シーン階層化システムを提案します。つまり、シーンは、さまざまなシーン要素に従って 6 つのシーンのレイヤーに分割されます (表 1 を参照)。
シーン データを図 3 に示します。 Pegasus シーン階層化システムに基づいて、表 2 に示すようにシーン データを階層化できます。
道路レイヤーの複雑さは、主に車線の可視性によって決まります。表 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 になります。
上記の複雑な定量化手法を使用してシーン ライブラリを構築すると、「過度の複雑さ」という現象が発生します。つまり、シーン ライブラリの複雑さを追求するために、シーン ライブラリは複雑度の高いシーンのみを収集しており、その結果、シーン ライブラリの複雑さは非常に高いものの、発生確率は非常に高くなります。結局、システムのパフォーマンス上の欠陥を発見することはできません。 「過度の複雑さ」現象を回避するために、この記事では「母子ライブラリ」と「システムシナリオ確率」という 2 つの概念を提案します。
3.1 母子図書館実際の現場の図書館収集プロセスでは、ランダムな場所、ランダムな期間、ランダムな気候、ランダムな収集方法によってデータが収集されます。等が「マザーライブラリー」を構成します。そして、当該システムの特性や動作領域に基づいて、「マザーライブラリ」から「サブライブラリ」を抽出する。例：高速道路のみに適用可能な自動運転システムの場合、高速道路のシーンデータを「親ライブラリ」から抽出して「サブライブラリ」とします。たとえば、特定の都市向けに開発された自動運転システムの場合、その都市のシーン データが「マザー データベース」から抽出され、システムの「サブ データベース」が形成されます。
注目に値します: 理論的には、最初に「マザー ライブラリ」を構築してから「サブ ライブラリ」を抽出することも、最初に「サブ ライブラリ」を構築することもできます。それを「マザーライブラリ」に集めます。ただし、この記事では「母親が第一、息子が二番目」のアプローチを推奨しています。 「マザーライブラリ」の構築はランダムであるため、「マザーライブラリ」から抽出された「子ライブラリ」もランダムな属性を持ちます。 「サブライブラリ」が最初に構築される場合、また「サブライブラリ」はシステム固有であるため、構築プロセスで完全なランダム性を達成することは困難です。
3.2 システムシナリオの確率「マザーライブラリ」から抽出した「サブライブラリ」について、システム実行中にシナリオの各層の要素をさらに分析します。発生確率はシステムシナリオ確率です。例: 高速道路のみに適した自動運転システムの場合、交通参加者層に車両のみが含まれる確率 (複雑さ 2) は、歩行者と自転車が含まれる確率 (複雑さ 3) よりもはるかに高くなります。したがって、この層の要素の複雑さを評価するときは、この層の最終的な複雑さを取得するために、複雑さに確率係数を乗算することも必要です。式は次のとおりです:
#
式内: C はシーン データの最終的な複雑さ、
は 
レイヤー シーン要素の複雑さ、 
は、当該システムの実行時に出現する 
# 層のシーン要素の確率係数です。
「母子ライブラリ」と「システム シナリオの確率」によって「複雑すぎる」現象を回避できます。 。主な理由は次のとおりです。 (1) 「マザーライブラリ」を建設する際、「マザーライブラリ」の収集プロセスにおける人的要因を減らすために、ランダムな場所、ランダムな期間、ランダムな気候などのランダムな収集方法が使用されます。 (2) 特定のシステムに対して、「マザーライブラリ」から該当する「サブライブラリ」を抽出することで、「サブライブラリ」における人的要因を間接的に回避します。 (3) システム稼働時のシーンの発生確率と複雑度に基づいて、最終的なシーンの複雑度を計算します。複雑さと確率という客観的要因を組み合わせることで、人的要因の影響を回避できます。たとえば、複雑度が高く確率が低いシーン要素、または複雑度が低く確率が高いシーン要素の場合、最終的なシーンの複雑さの値は低くなる可能性があります。
確率係数はシステムごとに異なります。例: 高速道路での使用に限定されたシステムの場合、交通参加者レイヤーに表示される車両のみの確率係数は、歩行者や自転車の確率係数より大きくなります。都市交通シナリオで使用できるシステムの場合、確率係数は、交通参加者層に出現する歩行者と自転車の確率係数は、車両のみの確率係数よりも大きくなります。さらに、同じシステムでも、自動運転開発プロセスの異なる段階では、その確率係数も異なる可能性があります。例: この段階では、情報層に高精度マップまたは V2X を備えたシステムの確率係数は、高精度マップまたは V2X を持たないシステムの確率係数よりも低くなります。自動運転開発の後期段階では、高精度地図や V2X を備えたシステムの確率係数が、高精度地図や V2X を備えていないシステムよりも高くなる可能性があります。
したがって、さまざまなシステムについて、その運用範囲、場所、時間、ターゲット市場、市場全体のレベルなどの多くの側面を考慮して、さまざまなシナリオの確率を決定する必要があります。要素、係数。
ISO/PAS 21448 の要件を満たすためには、予想される機能安全シナリオのライブラリを構築する必要があります。ただし、シーン ライブラリの構築品質には、対応する定量的な指標がありません。この記事では、Pegasus シーン階層化システムに基づいて、要素の各層の複雑さを定量化し、シーン ライブラリの品質を評価します。同時に、「過度の複雑さ」現象を回避するために、「母子ライブラリ」と「システムシナリオ確率」という 2 つの概念が提案され、「母子ライブラリ」をどのように構築するか、およびどのように構築するかが提案されます。 「システムシナリオの確率」を計算する方法について説明し、これに基づいて最終的な複雑度の計算方法を説明します。この記事で述べた定量化手法と「過度の複雑さ」を防ぐ手法は、期待される機能安全シナリオ ライブラリの確立と推進において示唆的な役割を果たします。
以上が期待される機能安全シナリオライブラリの複雑な定量化手法に関する研究の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
