さまざまなツールを組み合わせてadasをテストする - ツール ... · 2018. 11....
TRANSCRIPT
01
AD機能の検証方法
AD機能の検証には数百万km、あるいは数十億kmのテスト走行が必要とされています。しかもその大部分は一般の車両が走る 高速道路での走行です。他の道路使用者へのリスクや、テストの再現性といった他の側面も考慮するとすれば、テストやプロトタイプ用の車両を使い、実際の交通環境でこのテストのスコープをすべてカバーするのは事実上不可能です。そのため、そういった テストをラボ、すなわちテスト対象のシステムに適した仮想環境に移す必要が生じます。しかし、高速道路での実際のテストも 一緒に廃止してしまうのは誤りです。なぜならラボ内で使用されるシミュレーションモデルはあくまでも現実の世界を模したものに過ぎないからです。路上からラボにテストを移行するには、さまざまな手順と方法が使われます。実際のECUを、おそらくは実際のセンサーも一緒に車両のシミュレーション環境に統合する（Hardware-in-the-Loop）には、それらのECU／センサーと、それに対応する、ベク ターのVTシステムなどの高性能のリアルタイムシミュレーションシステムとを電気的に接続する必要があります。ECUソフトウェアはADシステムでは特に重要であるため、それ 以降主眼を置いて検討されるのがECUハードウェアなしでのソフトウェアテスト（Software-inthe-Loop）です。このアプローチ
自動車セクターのECU開発における革新技術と手法にとって、 自動運転（AD）は大きな追い風となっています。現在、自動車にはカメラ、レーダー、LIDARなどのさまざまなタイプの高機能 センサーが搭載されるようになっており、その多くが車両の環境を最大限正確に、しかもあらゆる（気象）条件下で把握するのに必要とされています。これらのセンサーから生成されるデータはリアルタイムで処理されますが、最近ではこれもセンサーデータを統合してから処理するケースが増えており、高性能のプロセッサーとグラフィックチップがそれを支えています。 このようなタイプのAD用ECUは、一般にQNX、PikeOS、 INTEGRITY OSといったPOSIXオペレーティングシステム下で動作しています。これらのプラットフォームは、これまで車載ECUの 開発には使われてこなかった、他のIT分野に属するソフトウェア環境の使用を可能にします。たとえば現在では、自動運転機能を実装する際に、TensorFlowやROS (Robot Operating System) といった人工知能や機械学習のフレームワークを使用することも可能となりました。このような複雑なハードウェア／ソフトウェア環境では、ADシステムのリリースプロセスをどのように構成するかが問題となり ます。ソフトウェア本体、これにはAD機能も含まれますが、それだけにすら、普段のレベルをはるかに超えたテストや検証の手続きが必要になるのです。
新たなADAS（先進運転支援システム）の世界にフルスピードで突き進んでいくというときに、誰もリスクを負わずに済むのであれば、 それに越したことはありません。今日のようなITのパラダイムシフトの中で、真に信頼できる形ですべての機能のテストを行うには、 私たちはどうすればよいのでしょうか。もっと複雑な、あるいはまったく別なツールが必要なのでしょうか。それとも、既存のツールを うまく使うのがよいアプローチなのでしょうか。
ツールボックスの有効活用
さまざまなツールを組み合わせてADASをテストする
02
Technical Article / September 2018
では並行したテストの実行やテストの自動化が容易に行える ため、夜間や週末にテストを実行することも可能になります。ECUソフトウェアをラボ内の机上でテストするには、ECUソフトウェアを実際のハードウェアがない状態で実行する必要がある 一方、テスト対象となるソフトウェアの環境、すなわち車両とその挙動のほか、車両や採用されているセンサーを取りまく環境を シミュレーションすることも必要です。さらに、たとえばテストの自動化などのその他の要求にも対応しなければなりません。こういった個々のサブタスクについては多様なメーカーから専用の ツールが出されており、それらには膨大な経験と専門知識が盛り込まれています。そのため、それらの専用ツールを組み合わせて完全なテスト環境を構築するのが賢い方法といえそうです。これらのツール同士のリンクには、Functional Mock-up Interface (FMI) を始めとする標準化されたインターフェイスが大いに威力を発揮しますが、何よりも重要なのは、これによってツール間の通信に関する細かい技術的な設定をユーザーがせずに済むようになることです。以下に示すのは試験対象システム（SUT: System Under Test）を仮想環境でシミュレーションする際の典型的な設定で、これらの目的に使用される機能やツールが記載されています。このテスト設定は緊急ブレーキ機能をテストする際の各種シナリオを踏まえて作成されたものです。ベクターのプロセス統合開発ツールであるPREEvisionは、 要求／テストデータ管理に適したソリューションの1つです。これはテストの仕様とテスト結果を管理しますが、実際のテスト 設計、つまりテストケースの作成は、vTESTstudioを使用して 行います。これを使用して生成される実行可能なテストユニットがCANoeにロードされ、実行されます。このランタイム環境は テスト用ですが、CANoeではターゲットに対する残りのバス シミュレーションも可能です。テストが完了するとテストレポートが作成され、テストデータ管理システムに保存されます。このアプローチによって、要求からテスト結果に至る、エンドツーエンドのトレーサビリティーが約束されます（図1）。このSUTは緊急ブレーキ機能が実装されるECUです。これは センサーやアクチュエーターとSOME/IPを介して通信し、Linux下ではAUTOSAR Adaptive ECUとして存在します。全体的な システムは緊急ブレーキ用ECUとSOME/IP経由で通信する
センサーのゲートウェイで構成されています。このセンサーゲートウェイは速度センサーや距離センサーからデータを受け取り ます。緊急ブレーキ用ECUは、ブレーキやアクセルのペダルを 制御するアクチュエーターのゲートウェイともSOME/IPを使用して通信します（図2）。センサーゲートウェイとアクチュエーター ゲートウェイは、CANoeシミュレーションではいずれもシミュ レーションノードとして存在します。
緊急ブレーキ機能のテストケース
ADASテスト環境は仮想のテスト車両と仮想のテストドライバーで構成され、それらがシミュレーション上の直線のテストコースを走行します。テストドライバーは平坦な道を20秒間走行します。 ステアリング操作は行いません。運転は初期速度が26m/s （～93km/h）、アクセルペダルを50%踏み込んだ状態で行い ます。テスト走行を開始する際、テスト車両のレーダー範囲外に別の 車両が障害物として置かれます。障害物となる車両は最初は停止していますが、テスト車両の速度が0m/sに到達すると、アクセル
図2： ECUエミュレーション、センサー／ アクチュエーターのシミュレーション、 環境／シナリオのシミュレーションから なるシステム設定
図1： 要求およびテスト管理システムへの接続も含めた、ADASシステムの テストのためのツールチェーン
Insert figure
03
Technical Article / September 2018
は、テスト車両がブレーキで停止すると、障害車両が走行を開始します。この3番目のフェーズでは、テスト車両は最初のフェーズ と同様の、アクセルペダルは50%、ブレーキ圧は0barの設定で走行を継続します。緊急ブレーキはアクティブ化されません。
ツール間の相互作用
これらのタスクは、TASSのPreScanツールからのシナリオを 使用して環境シミュレーションを提供しつつ、CANoeがECUと通信しながらテストを実行するというように、これに関与する ツール間で分担されます。シミュレーション時間はタイミングマスターとして振る舞うCANoeによって与えられます。車両環境、車両、ドライバーのより詳しいモデルがPreScanで算出され、それを一貫した基盤として、距離検出用のレーダーセンサーがシミュレーションされます。ここでは、理想的なレベルから現実的なレベルまで、さまざまな詳細度のセンサーモデルを選択できます。さらに、このシナリオ全体をPreScanで視覚化できます（図3）。このコンフィギュレーションではvTESTstudioツールも使用されます。これはテスト設計の開発環境で、これを使用することにより、 CAPLや.NETを使用して、あるいはグラフィカルにテストを開発できます。CANoeとPreScanの間の通信にはFunctional Mock-up Inter-face (FMI) に基づくアプローチが採用されています。実際の通信レイヤーはWindows名前付きパイプを通じて実装されますが、それがこのアプローチによってカプセル化されます。1つの独立 したプログラムをさまざまなFunctional Mock-up Unit (FMU) 用のコンテナや、Windows名前付きパイプのサーバーとして動作させることができますが、この、個々のFMUはPreScanでの実験に相当し、それらは対応するFMUを読み込むことで簡単に切り 替えることができます（図4）。FMIソリューションの魅力は、CANoeとPreScanの標準の機能の範囲でFMUをロードし、それらをそれぞれのプロセッサー空間で実行できる点にあります。FMUコンテナはこのようなプロジェクトに特化して考案された唯一のコンポーネントです。
ペダルが完全に踏み込まれます。この「障害車両」はテスト車両と同じ方向に走行します。このテストでは以下の期待値が設定されています。
1. 20秒内に衝突は発生しない2. テスト車両が停止する前：
> テスト車両が障害物から「危機的な」距離よりも離れて いる場合、アクチュエーターゲートウェイが受信するブレー キ圧シグナルは0barで、アクセルペダルシグナルは50%で ある
> テスト車両が危機的な距離の範囲に入ると、ブレーキ圧 シグナルは150bar、アクセルペダルシグナルは0%になる （緊急ブレーキ機能がドライバーの制御シグナルよりも優先 される）
3. テスト車両が停止した後： > テスト車両が障害物から危機的な距離の範囲内の場合、 引き続きブレーキ圧シグナルは150barで、アクセルペダル シグナルは0%である
> テスト車両と障害物の間の距離が危機的な距離を超える と、ブレーキ圧シグナルは0bar、アクセルペダルシグナルは 50%になる（ドライバーからの制御シグナル）
これらの期待値を、今度は実行可能なテストステップに変換し、 上に示したフレームワーク条件下でテストしなければなりません。そのために、テスト全体を3つのフェーズに分けます。最初の フェーズを支配する制約は、障害物までの距離が危機的な距離 よりも大きいことです。この文脈でいう危機的な距離とは、緊急ブレーキが作動しなければ衝突が発生する距離を意味します。 このフェーズのテストの記述は、「車両はアクセルペダルを50%踏み込み、ブレーキ圧は0barの状態で走行する。緊急ブレーキはアクティブ化されていない」となります。次のフェーズは、障害物までの距離が危機的な距離よりも小さいケースをカバーします。この場合、テスト車両にはブレーキが掛かりますが、その際のブレーキ圧は150barになります。アクセルペダルシグナルは0%で、緊急ブレーキがアクティブ化されます。3番目のフェーズで
図3： PreScanによる運転状況および 環境の視覚化
04
Technical Article / September 2018
展望
ADAS/ADシステムの仮想テストのニーズが高まるのに伴い、 それに必要なセンサーやアクチュエーターのデータがシミュレーションの形で求められるようになりました。このようなシステムでは処理すべきデータの種類が極めて多く、そのため効率性と信頼性を備えたツールのカップリングが欠かせません。さらに、ADAS/AD機能は複数のECUに分けて実装される場合もあります。テストエンジニアの観点からいえば、これはソフト ウェア、すなわちアプリケーションにますます注意が向けられ、 閉じられたブラックボックスであるECUの扱いは透過的になっていくことを意味します。サービス指向アーキテクチャー（SOA）は、このような機能に関わる個々の要素が通信するためのインフラストラクチャーを提供します。これからのツールにとって、 こういったシステムをテストすることが非常に重要になります。SOAによって、従来のネットワークにおける「残りのバスシミュ レーション」を、「残りのシステム全体のシミュレーション」に することができます。相互サービスのプロバイダーまたはコン シューマー、複雑なデータ型のサポート、異なるプロトコル （Ethernet）でのシリアル化のモックアップだけでなく、最終的には従来のネットワークのシミュレーションのモックアップも 必要です。
本稿は2018年9月にドイツで発行された『Elektronik autmotive』 に掲載された記事内容を和訳したものです。
画像提供元図1、2、4：Vector Informatik図3：TASS International
■ 本件に関するお問い合わせ先ベクター・ジャパン株式会社 営業部E-Mail: [email protected]
図4： テスト実行用プラットフォームのCANoe、 ECUエミュレーション、環境シミュレーション用の PreScan、各シナリオを切り替えるための 名前付きパイプサーバーからなるソフトウェア アーキテクチャー
Dominik Skanda ハイデルベルク大学で物理を学び、2016年以降は、ベクターの組込ソフトウェア部門で特にADAS関係のトピックをテーマとする研究開発に従事。
Francisco Gonzálezドイツのシュツットガルト大学で組込システムの修士号を取得し、ベクターにて組込ソフトウェア／ADAS関連のトピックに主眼を置いた研究開発に従事。
Jochen Neuffer ドイツのEsslingen University of Applied Sciencesで電気通信技術を学び、2002年よりネットワークおよび分散システム分野のツールを担当 するプロダクト管理エンジニアとしてベクターに勤務。
Oliver PhilippTASS Internationalに勤務。ダルムシュタット工科大学で数理工学を 学ぶ。以来、自動車、環境、センサーシミュレーションなどの分野でさまざまな役職を歴任し、2018年現在はTASS Internationalのマーケット開発マネージャー。