自動運転車両は、センサを使用して周囲の情況を認識します。早期の段階で車両の機能を効率的に検証するには、環境、センサ、および車両を仮想的な走行テストで現実的にシミュレートしテストする必要があります。この目的のため、dSPACEでは強力なハードウェアおよびソフトウェアで構成された統合ツールチェーンを提供しています。
自動運転車両が道路交通の一部として機能する可能性については、もはや疑問の余地はありません。それがいつ実現されるかの方がより大きな問題です。レベル4車両の量産準備が整うのは、2020年から2021年と予想されています。この目標を達成するためには、運転機能をまだ開発中の段階から妥当性確認もできるようにすることが不可欠です。つまり、開発者は運転機能と（カメラ、LiDAR、レーダーなどの）環境センサを組み合わせて疑似現実をラボで作り出し、その中のトラフィックシナリオでシミュレーションを行うことが必要です。これに代わる選択肢は実際の路上でのテストドライブとなりますが、この場合、すべての必須シナリオをカバーするためには実車で何百万キロメートルも走行することが必要になります。つまり、不可能という単純な理由から実行できません。
妥当性確認プロセスの条件
自動運転機能の妥当性を確認する場合の重要な条件は、多数存在します。
- 多数の（時には40以上の）異なるセンサ（カメラ、LiDAR、レーダーなど）から計測された値を同時に考慮する必要があることからも分かるように、高度に自動化された自動運転機能は極めて複雑です。
- テスト対象の各種のトラフィックシナリオ（車両、歩行者、道路標識など）はほぼ無限であるため、テストには複雑な仮想3Dシーンが必要となります。
- 光パルス、マイクロ波などの放出または捕捉に伴う物理的なプロセスは、非常に演算負荷の高い物理環境およびセンサモデルとして統合しなければなりません。これには、誘電率や粗度など、オブジェクトの材料特性の影響も含まれます。
- ISO 26262規格（道路車両 - 機能安全性）への適合性を保証するため、何百万キロメートルものテストドライブに対応する必要があります。また、重大な運転状況には特に注意を払い、必要に応じて走行距離が適正であるか確認することも必要です。
dSPACEでは、ハードウェアとソフトウェアを組み合わせることにより、センサシミュレーションのすべての前提条件を開発プロセス全体を通じて考慮できるようにする強力なツールチェーンを構築しています。これを使用することで、開発者は早期の段階でエラーを特定できるようになり、極めて効率性の高いテストプロセスを設計できるようになります。
シミュレーションの必然性
妥当性確認プロセスで求められる要件を満たすには、運転機能の検証と妥当性確認を開発プロセスのすべての段階で行うことが必要です。シミュレーションは、これを実践するための最も効率的な方法です。自動運転機能は非常に複雑です。そのため、MIL（Model-in-the-Loop）からSIL（Software-in-the-Loop）およびHIL（Hardware-in-the-Loop）に至るまでの開発プロセスのすべての段階において、すべてのプラットフォームで関連するテストケースを再現し再利用できることが不可欠となりますが、これを実現できるのは、統合型のツールチェーンのみです。
dSPACEツールチェーンは、開発プロセス全体を通じて高精度のセンサシミュレーションをサポートしています。
シミュレーション環境の構造
クローズドループシミュレーションの構造は、MIL/SILやHILの構造と同じです（図1）。このシミュレーションでは、基本的に車両、トラフィック、環境、およびセンサのシミュレーションに対応しています。インターフェースは、センサシミュレーションとテスト対象デバイス（自動運転用の制御ユニットまたは機能ソフトウェア）の接続に使用します。また、シミュレーションモデルの設定、テストの実行、シーンのビジュアル表示などを選択できるオプションも必要です。さらに、FMI、XIL-API、OpenDrive、OpenCRG、OpenScenario、Open Sensor Interfaceなどの一般的なインターフェースや規格をサポートしていることも重要です。これらは、German In-Depth Accident Study（GIDAS：ドイツ事故詳細調査）の事故データベースのデータを実装したり、協調シミュレーションなどのトラフィックシミュレーションツールを統合する際に必要となります。
車両、トラフィック、および環境のシミュレーション
センサシミュレーションの基本は、さまざまな道路利用者が相互に作用するトラフィックシミュレーションです。dSPACEでは、これに対応するため、Automotive Simulation Models（ASM）ツールスイートを提供しています。ASMを使用すると、仮想環境上で仮想テストドライブを定義することができます。ASM Trafficモデルでは、道路利用者の動きを計算できるため、追い越し運転、車線変更、交差点の交通などをシミュレートできます。ここでは、センサモデルが車両と仮想環境との相互作用における重要な役割を果たします。
センサの構造と機能
センサを使用する目的は、センサの生データによってターゲットをまず特定し、オブジェクトを検出することです。データには、一定の相対速度で記録される局所的に集積した反射点などを含めることができます。次に、これらの反射点の特徴的な配置から、（車両、歩行者、道路標識などの）分類されたオブジェクトを識別します。カメラ、レーダー、およびLiDARセンサは基本的なデザインがよく似ており、一般的にフロントエンドでデータのプリプロセス処理を行う構成となっています。その後、データ処理ユニットが生のデータストリームを生成してターゲットリストを出力し、別のユニットがオブジェクトリストを生成して位置データを供給します。さらに、アプリケーションロジックとネットワーク管理などのフローが続きます。
センサシミュレーションで使用されるセンサの統合オプション
種類が異なっていても同様の構造を持つセンサは、シミュレーションにそれぞれ容易に統合することが可能です。また、適切に準備されたシミュレーションデータを必要に応じて個々のデータ処理ユニットに挿入することも容易です（図4）。どのような統合オプションが適切かは、シミュレーションでセンサの特性をどの程度完全かつ現実的に再現する必要があるかや、センサのどの部分をテストするかによって異なります。環境シミュレーションをカメラベースの制御ユニット（オプション4）などに供給する場合には、無線（OTA）でのスティミュラス信号入力を使用します。カメラセンサでは、周囲のアニメーションシーンを表示するモニタの画像を取得します。この手法では、カメラレンズや画像センサを含めた処理チェーン全体をテストすることができます。デジタルセンサデータ（オプション3）は、生のセンサデータ、すなわちデータのプリプロセス処理（オプション3b）の直後に返されるデータと、ターゲットリスト（オプション3a）とに分類することができます。たとえば、カメラセンサの場合、これは画像データストリーム（生データ）または検出されたターゲット（ターゲットリスト）になります。次のレベルは、分類されたターゲットとトランザクションデータが含まれたオブジェクトリストです（オプション2）。センサと関係のないテストには、レストバスシミュレーションを使用します（オプション1）。オブジェクトリストとターゲットリスト、および生データを使用したシミュレーションがHILおよびSILの両シミュレーションに対応したアプリケーションシナリオであるのに対し、OTAスティミュラス信号入力およびレストバスシミュレーションはHILのみで使用できます。
物理的／現象的モデル
dSPACEは、生データやターゲットリストを一般的に供給するカメラ、レーダー、およびLiDARセンサをシミュレートするための極めて高精度な物理センサ環境モデルを開発しました。これらは画像演算処理装置（GPU）での計算を考慮して設計されています。
カメラモデル
カメラベースの運転支援または自動運転機能の妥当性確認を行う場合、基本的に、異なるレンズタイプだけでなく、レンズの色収差や口径食などの光学的効果も考慮する必要があります。また、パノラマビューでさまざまな画像センサ（モノ／ステレオカメラ）や複数のカメラをシミュレートできるオプションも必要です。さらに、妥当性確認では、センサの特性、色（単色表現、ベイヤーパターン、HDRなど）、ピクセルエラー、および画像ノイズが重要な要素になります。
LiDARモデル
LiDARシステムでは、レーザーパルスを放射し、オブジェクトから反射した光を計測します。これにより、オブジェクトまでの距離を経過時間から導き出します。また、このシステムでは距離だけでなく、オブジェクトの表面状態によって変化する反射光の強さも計測されます。これにより、ポイントクラウドの形で環境を記述できるようになるため、データを距離や強度に関する情報を含むターゲットリストとして利用できるようになります。ただし、LiDARモデルでは、角度分解能を含めたセンサの特定の動作モードを光波に合わせて設定できることや、3Dシーンで使用されるオブジェクトに反射率などの表面特性が設定されていることが不可欠です。また、光の散乱が雨、雪、または霧によって変化することや、1本の光線が複数のオブジェクトによって反射される可能性があることも考慮する必要があります。これらの状況により、センサ表面全体に振幅分布が生じ、それがさらに（ムービングオブジェクト、静止オブジェクトなどの）環境や時間によって変化します。LiDARモデルは、ポイントクラウドから生データに至るまでの幅広いアプローチに対応しています。
レーダー環境モデル
レーダーは、雨、雪、霧などの悪天候条件や極端な照明条件でも確実に使用できるため、ADAS/AD運転機能において重要な役割を果たします。レーダーセンサを使用すると、オブジェクトの種類、すなわち車両、歩行者、自転車などを特定するだけでなく、それらの距離、垂直および水平方向の角度、さらには相対速度や絶対速度も計測することができます。おそらく、最も重要なレーダーテクノロジの1つは、周波数変調信号を使用する周波数変調連続波レーダー（FMCW）です。これは、連続波レーダーとも呼ばれます。最新のレーダシステムは、１計測周期で約128の周波数変調信号を送信します。レーダーは、オブジェクトによって反射された信号（エコー信号）を検出します。ここでは、周波数の変化と生成された信号を使用して、オブジェクトの距離を計測します。オブジェクトの速度はドップラー周波数によって特定することができます。dSPACEのレーダーモデルを使用すると、たとえば、モデリングにおいて多重伝播、反射、および散乱を考慮することができるため、センサ経路の挙動を現実的に再現できます。
センサモデリングの種類
さまざまなセンサ統合オプションのそれぞれには、適切に処理されたデータを提供するためのセンサモデルが必要です。基本的に、センサシミュレーションのモデルは、その複雑さや現実との近似性によって分類することができます（図3）。オブジェクトリストまたはターゲットリストを返すのは、実際の参照データに基づいたグラウンドトゥルースモデルと、イベントまたは状態の発生確率に基づいた確率モデルという2種類のモデルです。一般的に、生データは現象的（すなわちイベントや状態のパラメータに基づく）モデル、または物理的（すなわち数学的に定式化された法則に基づく）モデルによって供給されます。開発する運転機能の妥当性確認を行う場合は、開発の用途や時期に応じて適切なモデルを使用します。
グラウンドトゥルースモデルと確率モデル
ASM Trafficシミュレーションモデルには、SILまたはHILの用途でオブジェクトリストレベルでテストを行うための多数のセンサが含まれています。
- 3Dレーダーセンサ
- 2D/3Dオブジェクトセンサ
- カスタムセンサ
- 道路標識センサ
- 車線区分線センサ
これらのセンサモデルは、VEOSまたはSCALEXIOプラットフォームを使用したCPUベースのシミュレーション用に設計されています。確率モデルを使用すると、オブジェクトリストに基づいて、検出されたオブジェクトごとに霧や雨の環境条件などの現実的な影響を複数のターゲットに重ね合わせることができます。これらをすべて使用してレーダーの特性をエミュレートし、ターゲットリストを計算します。
SIL（Software-in-the-Loop）シミュレーションによる妥当性確認
SIL（Software-in-the-Loop）シミュレーションを使用すると、標準的なPCテクノロジを用いてセンサベースの制御ユニット向けソフトウェアを仮想的に検証することができます。ハードウェアプロトタイプがまだ入手できない早期の段階では、シミュレーションを用いることにより、アルゴリズムをテストできます。また、VEOS（図1）とその対応するモデルを使用すると、リアルタイムよりも高速な計算が可能になります。スケーラブルなPCクラスタで演算を行うオプションを追加すれば、速度はさらに向上します。これにより、極めて幅広い多数のテストケースを管理できるようになります。また、何百万キロメートルものテストドライブをタイムリーにカバーする必要のあるテストも実行できます。SILシミュレーションでは、VEOSを使用することにより、車両、環境、およびトラフィックシミュレーション、さらには（該当する場合は）仮想制御ユニットも計算します。また、グランドトゥルースモデルや確率モデルをベースとしたシミュレーションでは、モデルはVEOSにも統合されます。現象的または物理的なセンサモデルを使用する場合、GPU上で計算を行うセンサシミュレーション（カメラ、レーダー、LiDAR）用のアプリケーションは、常にVEOSと同じプラットフォームで実行されます。環境シミュレーションのモーションデータがセンサシミュレーションに転送されると、レーダー、LiDAR、またはカメラセンサのモデルが計算されます。つまり、生データのシミュレーションは、センサの物理的特性を考慮しながら、現実的な環境や複雑なオブジェクトを含む複雑な3Dシーンおよびモーションデータに基づいて行われます。この演算は高性能グラフィックスプロセッサ上で実行され、それにより、レーダーやLiDARなどの環境モデルを計算するための光線追跡アルゴリズムがシミュレートされます。このセンサシミュレーションの結果は、さらにセンサベースの仮想制御ユニットに送信されます。この通信は、Ethernetまたは仮想Ethernetを介して行われます。このテクノロジは、センサベースの仮想制御ユニットと車両シミュレーションのやり取りにも使用されます。
HIL（Hardware-in-the-Loop）シミュレーションによる妥当性確認
HIL（Hardware-in-the-Loop）シミュレーションを使用すると、記録されたデータまたは人工的なテストデータに基づいてスティミュラス信号を入力することにより、ラボで実際のECUをテストできます。SILシミュレーションとは異なり、HILシミュレーションでは制御ユニットの正確な時間的挙動を調査することができます。dSPACE SCALEXIO HILプラットフォームでは、トラフィック、ビークルダイナミクス、および環境シミュレーションを行います。CANやEthernetなどを介して車両シミュレーションを車両ネットワークに接続すると、レストバスシミュレーションが可能になります。車両や他のオブジェクトのモーションデータは、カメラ、LiDAR、レーダーのセンサ環境モデルを計算できる高性能なグラフィックプロセッサを搭載した強力なPCにEthernet経由で送信されます。各種のセンサから取得されたこのデータ（生データまたはターゲットリスト）は集約され、ディスプレイポートを介して環境センサインターフェース（ESI）ユニットに送信されます。ESIユニットは、関連するすべてのプロトコルやインターフェースに対応できるよう、高度にモジュール型の設計となっています。ESIユニットの高性能FPGAでは、すべてのセンサからのデータストリームを専用センサの個々のデータストリームに変換し、それらをさまざまなインターフェースを介して対応するカメラ、LiDAR、またはレーダー制御ユニットに送信します。
dSPACEの物理センサモデルを使用すると、カメラ、LiDAR、およびレーダーセンサの生データを最高の精度でシミュレートできます。
無線スティミュラス信号入力による妥当性確認
無線（OTA）スティミュラス信号入力は従来型のセンサテスト手法であり、センサベースの制御ユニット全体を制御ループに統合します（図5）。この設計は、カメラのレンズや画像センサなど、センサのフロントエンドをテストする場合に最適です。ここでは、SCALEXIOを使用して車両、環境、およびトラフィックシミュレーションの計算を行っています。カメラセンサのテストでは、SCALEXIOシミュレータとMotionDeskを使用して、トラフィックシーンをシミュレートし、画面に表示します。カメラの場合、実際の街路の場面が仮想シーンで再現されます。また、dSPACE Automotive Radar Test System（DARTS）により、レーダーエコーがSCALEXIOシミュレータで計算された運転シナリオと協調した形でレーダーセンサに渡されます。これにより、ACC（アダプティブクルーズコントロール）やAEB（自動緊急ブレーキ）などの運転機能の検証も可能になります。
まとめ
自動運転車両が道路状況を考慮しながら安全に走行するためには、ADAS/AD機能によって、あらゆる運転シナリオで正しい判断を下さなければなりません。ただし、考えられる運転シナリオの数は事実上無限です。そのため、ラボでのADAS/AD機能要件のテストは非常に複雑なものになります。これらのテストは、すでに単一のテスト手法だけでは実施できなくなっており、さまざまなテスト手法を組み合わせることが重要です。これらの手法には、MIL、SIL、HIL、オープンループテスト、クローズドループテスト、さらには実際のテストドライブなどがあります。この複雑なテストおよびツール環境を考慮した場合、妥当性確認プロセスの信頼性向上の鍵となるのは、柔軟性に優れた統合ツールチェーンを構築し、シミュレーションモデルとテスト対象のデバイスに汎用性の高いインターフェースと統合オプションを提供できるようにすることです。つまり、センサおよび環境シミュレーションに対応したdSPACEツールチェーンこそ、非常に便利かつ有効なソリューションであると言えます。このツールチェーンでは、シングルソースからさまざまなツールを提供できるため、ツール間のスムーズな相互連携が実現し、妥当性確認プロセスの大幅な効率化が可能です。
dSPACE MAGAZINE、2019年5月発行
