V-ECUとは

現在日常的に話題になっている、高度な自動運転において、自動運転機能の妥当性確認の新たな基準としてテストドライブの走行キロメートル（マイル）数という項目が注目されています。これは、最初にGoogle社が発表したシミュレーションのみで毎日8百万マイルを走行する手法からはじまり（ 「Inside Waymo's Secret World for Training Self-Driving Cars」を参照）、これはおそらくランド研究所などで算出された数値で収束することはありません。2016年の調査によると、事故関連の死亡者数を20%削減しようとするだけでも、各車両で50億マイルものテストドライブを行う必要があります（ 「Why It's Nearly Impossible to Prove Self-Driving Cars' Safety Without a New Approach」を参照）。

当然ですが、実際の実験車両でこの距離を運転することはできませんし、リアルタイムに近い条件でのシミュレーションでも、この膨大なテストドライブを走破できる者はいません。これは簡単な例で説明できます。たとえば、速度制限が時速50 kmの都市部でテストドライブを実施するとして、確認したい道路は約0.5 kmの距離であるとしましょう。それは「通常の運転」では1分の約半分（36秒）であるため、100万キロメートルを走破するとすれば、24時間稼働で1週間以上（200時間、すなわち8日と8時間）のシミュレーションが必要です。さらに、ここで言及しているのは準備や結果分析などのオーバーヘッドを除いた純粋なシミュレーション時間です。

では、完全装備のHIL（Hardware-in-the-Loop）システムを多数購入すれば、週末にシミュレーションを実行できるということになるのでしょうか。残念ながら、現実は私たちの計算に収まるほど単純ではありません。ここで登場するのがSIL（Software-in-the-Loop）シミュレーションです。SILを使用すると、HILセットアップの貴重な時間を使い始める前の段階で、可能な限りコードの品質を改善することができます。過去18ヶ月間において、SIL専門家の間では、バーチャルECU（V-ECU）をテスト対象デバイスとしてSILシミュレーションを行うという議論が頻繁に行われています。

私の経験では、エンジニアリング環境としてV-ECUを使用し、まっさらな状態から作業を開始することにより、多くの問題を解決することができます。問題は、実際にそれで何を行うかということです。

より正確を期すため、この1つの質問を3つに分割し、1つずつ回答したいと思います。

1. V-ECUとは何か
2. なぜ有用であるのか
3. どう取得するのか

V-ECUとは何か

簡潔に答えると、ハードウェアなしで実行できる任意のソフトウェア機能です。

もちろん、MIL（Model-in-the-Loop）テストの関係者であれば誰でも分かるように、これはあまり正確とは言えません。

V-ECUには最終的なECUと同様の未修正の量産コードが殆ど含まれています。これは、通常のMILテストと区別できるV-ECUの1つの重要な性質です。量産コードをSILシミュレーション環境で実行する方法は複数あります。ただし、V-ECUは実物に極めて近いものであるため、プロセスを容易に統合するという目標と、高速かつあらかじめ決められたスケジューリングに基づいて確実にシミュレーションを行うという目標を妥協なく実現することが可能です。この場合、高速とは、リアルタイムよりも速いという意味です。

V-ECUの重要な要素は次の通りです。

• 機能ごとに調整されたタイミング／トリガ情報に基づいて、現実的なスケジューリング動作を実行。これには、オペレーティングシステムのシミュレーションも含まれており、さまざまなサイクルや異なる優先順位でコードをトリガすることが可能なだけでなく、プリエンプションや割込みなどの期待されたあらゆる動作を正確に表示することも可能です。
• ソフトウェアアーキテクチャへのソフトウェア機能などの統合以上のことが可能。この段階で既に、インターフェースの互換性を検証したり、同僚が使用するソフトウェア機能における不足データ（またはソフトウェア機能との不一致）を発見したりすることが可能です。また、必要に応じてAUTOSARとの互換性を確保することもできます。
• 最後に、ECUはバスレベルで接続されています。そのため、シミュレートされたバスにV-ECUを接続してはいけない理由は一切ありません。また、COMスタックをテスト限定で使用するのを避けたい場合は、実際のスタックを生成するか、または実際のスタックに置き換えることも可能と考えられます。

AUTOSAR Classic Platformを使用している開発者の場合、V-ECUには少なくともアプリケーション層が含まれており、AUTOSAR Runtime Environment（RTE）およびオペレーティングシステム（OS）自体も搭載されています。ベーシックソフトウェアモジュール（BSW）などのその他のものはすべてオプションです。ただし、シミュレーションのためにBSWを統合または生成することもできる必要があります。

なぜV-ECUは有用であるのか

誰かからこの質問を受けるたびに、私は「どのような作業に取り組んでいるのですか」という質問を返します。有用性は常にタスクに左右されます。

V-ECUの良い点は、その利点が1つだけではないところです。

V-ECUとハードウェアのECUとを比較した場合、V-ECUを使用するメリットが大きいテスト構成は、仮想統合テストです。理由は簡単です。多くの場合、明らかにインターフェースの問題があるか、または使用しているすべてのECU間のバス通信が最新の状態ではないことのいずれかにより、ECUの通信が失敗すると統合テストがブロックされることがあります。

V-ECUを使用すると、これらの問題はすぐに検出することができます。実際のハードウェアの代わりに、V-ECUやシミュレートされたバスと同様にSILベースの統合セットアップを使用すれば、HILリソースを使用することなく、対象の開発バージョンを総合的に統合することができます。これにより、HILベースの統合テストの際には、同じ種類の問題に何度も時間を費やさなくてよいため、発見が比較的困難なバグへの対応に注力することができます。

V-ECUについては、機能開発者の立場からも考えてみてください。V-ECUは拡張することができます。たとえば、プログラミングしたばかりのコードを使用して簡単なランタイム環境とオペレーティングシステムを自動生成します。これによって作成されたV-ECUを小規模なSIL環境に統合します。それをHIL環境で使用するプラントモデルに接続したり、他の軽量のV-ECUと合わせて統合モデルを作成したり、さらには、COMスタックを生成してV-ECUをシミュレートされたバスに直接接続したりすることができます。

「追加のテスト成果物を使用する必要があるのはなぜですか。私は何年も単体テストやBack-to-Backテストを使用してきました。」との質問がまだ聞こえてきそうです。

その通りです。しかし、その場合、テスト対象デバイスを他のV-ECUと容易に統合することはできますか。おそらくできないでしょう。

dSPACE VEOSなどのV-ECU用のシミュレータには、V-ECUだけでなく、モーターモデル、ビークルダイナミクスモデル、完全な運転シナリオなどのプラントモデルや環境モデルも組み込むことができます。なお、これらはSCALEXIOシステムで実行するのと同じモデルです。さらに、PCベースのシミュレータでは、HILテストベンチで使用するのと同じツールを使用できるため、結果的に同じテストを行うことができます。

ただし、私はコンピュータ科学者であるため、2つの性質を何よりも重視しています。

• 最終的にソースコードのテストを行う際に、V-ECUおよびシミュレーションセットアップ全体をいつでも停止してデバッグすることができるという点です。最適なデバッガを接続し、ブレイクポイントを挿入し、重点的に取り組むことができます。私は、自動化されたテストとコードカバレッジ分析を使用していますが、正直に言えば、結局、問題の根底を突き止めたい場合に最も有用なツールはデバッガです。
• V-ECUやSILシミュレーションが単なるソフトウェアであるという点です。まず、これらでは時間がシミュレートされており（そのため、少なくともV-ECUにとっては時間は錯覚であり）、シミュレートされた時間は通常リアルタイムよりも高速に進みます。また、実際の時間に影響を与えることもできます。デスクの一番下の引き出しに入れて使用しなくなった5年前のノートパソコンは使用せず、通常の高性能ハードウェアのみを使用してください。純粋なソフトウェア的手法は、自動化されたテストを行う場合に最適です。品質保証で必要とされるテストスループットが向上すれば、シミュレーションセットアップ全体のコピーを使用するか、またはクラウドシステムに完全に移行することができます。この通り、これは単なるソフトウェアですよね。

V-ECUをどう取得するのか

つまり、どのようにしてV-ECUを作成するのかという最後の疑問が残ります。このブログ記事を書いている時点でV-ECUは（まだ）標準化されていません。そのため、V-ECUの作成方法は使用しているSILツールチェーンによって異なります。

dSPACEでは常にモジュール型のツールチェーンを推奨しているため、V-ECUについて述べる際には可能な限り規格に焦点を当てます。V-ECUの中身を見てみましょう。既に、車載ソフトウェアをモジュール型かつ交換可能な形式にするための AUTOSAR という規格が存在します。

たとえば、AUTOSARに従ってソフトウェアを開発（し、ARXMLファイルを使用してそれを指定）する場合は、AUTOSARオーサリングツールにそれを直接インポートすることができます。当社の場合、これはdSPACE SystemDeskです。ただし、AUTOSARを使用せずに作業する場合でも、Excelシートや他のツールで生成したXMLファイルなどを通じてソフトウェアのインターフェースを指定します。その後、SystemDeskを使用して、Excelシートを適切なAUTOSAR記述形式の仕様として使用してAUTOSARのラッパーを作成します。ここで私が「SystemDeskを使用して」というのは、「PythonスクリプトでExcelシートを処理し、SystemDeskを自動化して」という意味です。

つまり、ソフトウェア開発にAUTOSARを使用するかどうかにかかわらず、最終的にはARXMLファイルをインポートするか、独自のExcelシートをスクリプト化することにより、SystemDeskの中にAUTOSARソフトウェアアーキテクチャが自動生成されることになります。

また、もし私が同僚から最新の自動運転機能を搭載したAUTOSAR Adaptive Platformベースの新規のV-ECUを渡された場合にも、SystemDeskを使用してVEOS互換のファイル形式にラップします。

私が「スクリプト化」という言葉を使用したのは、私が再利用可能な成果物をどのように生成する場合でも、それを自動的に行いたいからです。これは、ソースコードを更新するたびに成果物を何度も生成する場合の唯一の方法です。これが、連続的な統合と供給です。

ソースコードや最初の記述形式とは関係なく、その結果はV-ECUインプリメンテーションとなります。これは、dSPACE VEOSに直接インポートしてシミュレートすることも、他のV-ECUや環境モデルに接続することもできます。

まとめ

V-ECUは、想像するほどミステリアスなものではありません。結局は、SIL（Software-in-the-Loop）環境で使用できるように自動生成されたランタイム環境とオペレーティングシステムを使用して、AUTOSARでもそれ以外の形式の場合でも、コードを拡張するということに尽きます。V-ECUは、デバッグでブレイクポイントに到達しない限り、高速に動作します。また、シミュレーション自体はハードウェアに依存しないため、一度設定すれば、コピーやクラウドシステムへの移動によって拡張することができます。

さらに、V-ECUには高い柔軟性があります。私は、 ゴールの法則 に従いたいと考えています。つまり、自分が書いているコードの一部分しか含まれていない最小限のものから必ず作業を開始します。そこからテスト環境を構築し、その後、V-ECUを拡張し、さらに機能を追加したうえで同僚に引き渡します。同僚は、SIL統合セットアップ上のレストバスシステムや制御モデルを、私が作成したV-ECUに含まれる実際の量産コードに置き換えることができるので、非常に便利です。

最終的に、V-ECUを使用したテストの対象となるのは量産コードです。そのため、シミュレーションのみで品質を改善し、何百万マイルものテストドライブに対応することができるのです。