AVやADASのシステムエンジニアが公道走行データを使って要求事項を自動検証する方法

2021年9月13日

自動運転システムの複雑化に伴い、システムエンジニアリングチームは多数の要件定義、検証作業、妥当性確認を実施する必要があります。これまで、公道走行データを使って要件を検証することは困難であったため、シミュレーションが一般的なアプローチとなっています。このブログ記事では、公道走行データを用いて要件を検証する既存の2つのアプローチについて説明し、エンジニアリングチームがこれらのアプローチを使用するのが難しいと感じた理由を説明します。そして、「シナリオサーチ」と呼ばれる新しい手法を紹介し、シナリオサーチが、既存のアプローチでエラーが発生しやすく、時間のかかる作業をどのように自動化するかを説明します。


なぜ公道走行データで要件を確認するのか?

自動運転車(AV)や自動運転支援システム(ADAS)の業界では、ほとんどの企業がテスト方法の一つとして公道走行を採用していますが、公道走行データを要件検証に使用することには消極的でした。シミュレーションツールを使えば、特定のシナリオを作成し、それに対してテスト/失敗基準を実行したり、同じシナリオのバリエーションを多数作成してロングテールイベントを確実に網羅することが簡単にできるため、要求事項の検証にはシミュレーションがより一般的な手法となっています。


システムエンジニアリングチームにとっては、シミュレーションだけでなく、公道での走行データを簡単に要件検証に利用できるようになることもメリットです。ほとんどのチームでは、公道走行データを大量に記録・保存していますが、ディスエンゲージメントなどの重要なイベントを分析する以外にはほとんど使用していません。ここでは、公道走行データを要件検証に利用する既存の2つの方法と、これらの方法が普及していない理由について説明します。

公道走行データを利用した要求事項の検証:2つのアプローチ

ヒューマン・オペレーター・タギング

ヒューマン・オペレーター・タギングとは、実際の公道走行時にどのような状況を確認すべきかをオペレーターに知らせ、オペレーターが走行中に遭遇したイベントにライブでタグ付けするという手法です。その後、システムエンジニアリングチームは、タグ付けされたイベントを初期要件と比較し、どのイベントが合格か不合格かを確認します。

図1:車両がカットインした公道走行データ (出典:nuScenes)

例えば、「遅い車両が前に割り込んできても、一定の距離を保つことに成功すること」という要件があったとします。この場合、オペレータは、自車の車線に他の車両が割り込んできた状況をタグ付けします(図1)。


残念ながら、ヒューマン・オペレーター・タギングは、システムエンジニアが公道走行前に要件を定義している場合にのみ、要件検証に有効です。事前に要件が定義されていない状態で、人間のオペレータが興味のある状況をタグ付けすると、関連するイベントを見逃してしまう可能性があります。自動運転システムの要件は常に進化・変化しているため、人間のオペレータによるタグ付けは、要件検証の信頼性に欠けるアプローチです。また、ヒューマンエラーが発生しやすい。オペレーターが状況を見逃したり、誤ってタグ付けしたりした場合、後から判断を覆したり、イベントにタグを付けたりすることはできません。 


マニュアル分析

公道走行データを使って要件を確認する方法としては、ヒューマン・オペレーター・タギングのほかに、マニュアル分析が一般的です。マニュアル分析では、AVやADASのエンジニアリングチームが、実際に公道を走行しながらドライブデータを記録・収集します。要件を確認するために、システムエンジニアは、ローカルに1つのドライブデータをダウンロードして、特定のイベントを検索するプログラムスクリプトを開発します。目的のイベントが見つかったら、その結果を手作業で確認し、要件を満たしているかどうかを検証しなければなりません。車両の割り込みの例に戻ると、システムエンジニアは、車両が走行中に遅い車両が前に割り込んでくるイベントを識別するスクリプトを開発する必要があります。そして、特定されたイベントを監視して、車両が毎回必要な距離を保っているかどうかを検証する必要があります。 


マニュアル分析の問題点は、エンジニアが何千時間ものドライブログをダウンロードし、スクリプトを開発し、結果を確認しなければならないことが多いことです。手作業での解析は、時間とリソースを必要とするアプローチです。


公道走行データを用いた自動要求検証のための「シナリオサーチ」という新しいアプローチ

公道走行データを要件検証に利用する新しいアプローチとして「シナリオサーチ」があります。シナリオサーチは、Applied のドライブデータ探索ツール Strada のクエリ機能です。システムエンジニアは、開発に必要な関連データを集めたり、安全上重要なイベントを見つけてトリアージしたりすることができます。また、シナリオサーチを使うと、公道走行データの中から特定のイベントを自動的に見つけて分析し、所定の要件を検証することができます。Stradaのシナリオサーチと Applied の検証ツール Basis を併用することで、チームは要件の定義と管理がより容易になり、スタック全体のパフォーマンスと検証に向けた進捗状況を把握することができます。


シナリオサーチの仕組み

図2:Strada における Applied シナリオサーチ ワークフローの5つのステップ

1.ドライブログの取り込み 

Strada は、公道でのドライブが終了するたびに、新しいドライブログを取り込み、安定したフォーマットに変換します。このフォーマットには、地図上での車両やアクターの位置を示す意味が含まれています。その後、利用可能なセンサーデータを処理して、ドライブ中に車両が遭遇した各イベントを分類します。 Strada は、データ・チャネルを調査し、一連のルールを適用して、シナリオ・タグを生成し、車両やアクターのさまざまな行動を表すシナリオ固有のメトリクスを抽出します。そして、これらのタグとメトリクスをアノテーションとしてログのタイムティックに添付します。これにより、エンジニアは指定された要件に基づいてイベントのサブセットを簡単に検索することができます。


2.要件の定義またはインポート

システムエンジニアリングチームは、Strada と直接統合されるBasisで要件を定義するか、または他のツールで要件を策定し、Strada にインポートすることができます。車両のカットインにおける要件とは、例えば、遅いアクター(他の車両)が自車両の車線に車線変更を行った後、衝突までの時間(TTC)が一定の閾値以内であれば、自車両は一定の距離を保つ必要があるというものです。


3.データソースの選択と一致するイベントの特定

次に、Strada はチームのドライブログの中から一致するイベントを自動的に特定します。マニュアル分析とは異なり、シナリオサーチはクラウド上でデータを処理します。これによりエンジニアは、各ドライブを1つずつ分析するのではなく、ドライブログライブラリ全体のイベントを検索することができます。Strada は、各要件に適したイベントを正確に検索して注釈を付けるために、異なるデータソースを組み合わせる必要があります。ある要件では、オフラインのコンピュータビジョンアルゴリズムなど、1つのデータソースで検索可能なイベントを求めています。他の要件では、車両のポーズ、車両のローカリゼーション情報、HD マップ、オープンソースマップ、車両のパーセプションシステム、外部のオフボードパーセプションシステムなどのデータソースの組み合わせを必要とするイベントにマッチします。

図3:停車中のバスの横を通過する車両 (出典:nuScenes)

例えば,停車中のバスの横を車両が通過するケース(図3)を見つけるためには,Strada は別のアクターがバスとしてタグ付けされているイベントを見つける必要があります。ここでは、車載システムのログデータを使用するか、車両の前方カメラでオフラインのコンピュータビジョンアルゴリズムを実行するのが最適です。


車両のカットインの例では、Strada はスタックの品質に応じて1つまたは複数のデータソースを見るかもしれません。スタックの品質が十分に高ければ、オフラインの知覚システムで、車両が走行中に遅い車両が前に割り込んでくるイベントを十分に検出することができます。他のケースでは、Strada は、オフラインの知覚システムからの情報を、車両とアクターのポーズに関する情報(両方の車両の位置と速度を知るため)、HD マップ情報(車両がどのレーンにいるかを知るため)と組み合わせる必要があるかもしれません。Strada はこれらのイベントを、TTC とアクターの相対速度が指定された閾値以下の場合に自動的にフィルタリングし、要件に適合させます。

図4:Stradaのシナリオサーチ機能は、指定された要件に合致するイベントを自動的に特定する。

4.イベントの処理と要件の確認

Strada は選択されたイベントを自動的に処理し(図4)、どのイベントが要件を満たしているか、あるいは満たしていないかを検証します。これは、イベントに関連する時系列データを見て、要件の基準を表す複雑なブーリアンロジックやシーケンシャルロジックを適用することで実現しています。この例では、合格・不合格の基準は、車両がブレーキをかけ、アクターとの間に一定のバッファ距離を維持することである。Strada は、このルールに従って選択されたイベントを処理し、各イベントの「合格」または「不合格」を自動的に計算します。


5.結果に基づく行動

システムエンジニアリングチームは、Stradaのシナリオサーチを使用して指定された要件の検証に成功した後、a) Strada で失敗事例のトリアージおよびデバッグを行い、b) セーフティケースの信頼性を高めるために肯定的な結果を使用し、c) Basis で要件間のカバレッジを確認し、検証に向けた進捗状況を把握し、d) Basisですべての要件と一致するイベントをリストアップした検証レポートを作成します。Strada のシナリオサーチ機能は、システムエンジニアリングチームが個々のイベントを見つけて処理するのに役立ちますが、Basis では、スタックのパフォーマンスの全体像を把握し、時系列で進捗状況を追跡することができます。どちらのツールも、既存のアプローチで確認された課題を軽減します。


結論

従来、公道走行データを要件検証に利用することは、信頼性が低く、時間のかかる手作業が必要であったため、困難でした。シナリオサーチは、公道走行データを利用して、信頼性が高く、時間とリソースを効率的に使って要件を検証する新しいアプローチです。システムエンジニアは、運転者がドライブ中にこれらのイベントにタグを付けていなくても、特定の機能の所有者に対する障害イベントを迅速かつ効率的に表面化することができます。これにより、システムエンジニアは、すでに収集しているにもかかわらず現在はほとんど使用していない豊富なデータを活用することができます。既存のデータを活用して要件を検証することで、システムエンジニアチームは、すべてのテスト環境におけるパフォーマンスの分析と検証をより効率的に行い、経時的な進捗を追跡し、セーフティケースを構築することができます。


StradaまたはBasisの製品デモをご希望の方は、エンジニアリングチームまでお問い合わせください。