画像
Vito Colagiacomo
Vito Colagiacomo
Staff Engineer

1.    ECU統合の動向と仮想化の効果

IVIやADASなどの新機能が車に追加されるにつれ、車両に搭載されるECU数も増加する可能性あります。単純なECU数の増加は、デバイスの複雑な管理、重量、消費電力など、マイナス面もあります。このため、車載業界でも、単一ECU単一機能から、単一のECUが複数の機能を提供するという統合アプローチへ転換していく動向があります。

画像
ECU consolidation

図1: ECU の統合は、単一機能ECU アプローチ(左) から多機能ECU (右) の移行

このような多機能ECUへのマイグレーションを試みる場合、新たな課題が生じます。各機能は、CPU、メモリ、ペリフェラルなどの異なるオペレーティングシステムおよびハードウェアリソースで実行される必要がある場合があります。さらに、各機能間においてFFI(Freedom From Interference)の確保が必要とされます。

幸いなことに、仮想化技術は、複数のゲストOS(仮想マシンまたはVMとも呼ばれます)が独立かつ安全な方法で機能を実行できるインフラストラクチャを提供するのに役立ちます。

2.    車載イーサネット

ECUに実装される機能がより複雑になるにつれて、柔軟な接続とより高いデータ転送速度が必要とされます。その中でも、車載イーサネットは、車載ネットワーキングソリューションの基幹として優れた候補であると見込まれています。イーサネットは、帯域幅、軽量ケーブル(例えばシールドなしのシングルツイストペア)、ソフトウェアインフラ、それらを組み合わせたエコシステム提供など、大きな将来性を持っています。さらに、スケーラビリティ、TSN (Time Sensitive Network) による時刻同期機構、低レイテンシおよび信頼性を提供します。

多機能なECUが仮想化を使用して複数のオペレーティングシステムを実行する場合、同じ物理イーサネットネットワークに接続されているかのように、VMを動作させる必要があります。イーサネットインターフェイスが1つしかない場合、 ハイパーバイザはVM間でインターフェイスを共有するメカニズムを提供し、通常は仮想ネットワークスイッチがソフトウェアで実装されます。この際オーバヘッドが大きく、半導体ベンダは、ハイパーバイザの介入なしにデータ共有が行えるように、ハードウェアによる仮想化支援機能をデバイスに追加する場合があります。本ブログでは、ソフトウェアスイッチに対し、ハードウェアスイッチを共有する2つのVMの利点を比較するPoC(Proof of Concept)をご紹介します。

3.    ハードウェア構成

このPoCはルネサスの車載SoC(R-CarH3)と車載TSNイーサネットスイッチを搭載したビークルコンピュータ3(VC3)をベースにしています。イーサネットスイッチは、PCIe を介してR-CarH3に接続されたFPGA にされています。

TSNイーサネットスイッチには4 つの外部ポート(1G-T1 コネクタ) と1 つの内部ポート(CPU ポート) があります。CPUポートはSoC内のCPUシステムとつながっています。TSNイーサネットスイッチとCPU間のインタフェースにより、R-Car上で動作するオペレーティングシステムをイーサネットフレームの送信元または宛先に指定することができます。

TSNイーサネットスイッチ とCPU 間のデータは、複数のキューによってやりとりされます。各キューはディスクリプタのリストで表され、メインメモリに存在し、CPU上で実行されるソフトウェアによって設定可能です。

  • RX キュー内のディスクリプタは、CPU の受信イーサネットフレームをメインメモリ内でコピーする場所をTSNイーサネットスイッチに伝えます。
  • TX キュー内のディスクリプタは、CPU が送信するフレームを配置した場所をTSNイーサネットスイッチに伝えます。これにより、ハードウェアはメインメモリ内のどこからデータをフェッチするかを知ることができます。

CPU 上でハイパーバイザが実行されている場合、独立したデータ処理のために特定のゲストOS にキューを割り当てることが可能です。

4.    ソフトウェア構成

このPoCのために、ハイパーバイザとしてXen v4.14を使用しました。一般的なXen ブリッジネットワーク(詳細については(here)をご参照ください)の代替手段としてTSNイーサネットスイッチを用い、データ共有するために、追加のフロントエンドドライバとバックエンドドライバを試作しました。Xen で2つのゲストOS (ドメインとも呼ばれる)を実行しています:

  • dom0: ほとんどのSoC周辺機能とTSNイーサネットスイッチに直接アクセスできる特権ドメイン
  • domU: 特定のハードウェアデバイスに直接アクセスできない非特権ドメイン。ただし、domU は2 つのTSNイーサネットスイッチ内のキュー(1 つのRX と1 つのTX) にアクセスできます。

以下図2 にこの構成を示します。

画像
POC sw configuration

図2 PoC用のソフトウェア構成

フロントエンドドライバとバックエンドドライバ間の通信は、次の場合にのみ使用されます。

  • 初期化時に、フロントエンドは2 つのキュー(1 TX および1 RX) を予約する要求を送信します。
  • フロントエンドは実行時にこの通信チャネルを使用して、バックエンドを介してTSNイーサネットスイッチにTXキューの処理準備ができていることを通知します。また、domU のRX キューで新しいデータが使用可能になるたびにフロントエンドに通知するためにバックエンドによって使用されます。

domU のキューのセットアップに必要な最初のハンドシェイクの後、フロントエンドドライバは、dom0 側からの最小限の介入で、TSNイーサネットスイッチによって処理される同じキューに直接アクセスするだけで、フレームを送受信できることに注目してください。これは、通常domU のフレームがバックエンドドライバと共有され、dom0 のネットワークスタックによって再ルーティングされる仮想マシンにおけるソフトウェアネットワーキングソリューションと比較した場合のメリットです。

たとえば、domU がネットワーク経由でいくつかのフレームを送信する場合、TSNイーサネットスイッチを用いた場合の手順は次のようになります。(図3参照)

  1. domU はデータを独自のTX キューに書き込み
  2. domU は、キューが処理可能であることをTSNイーサネットスイッチ (バックエンド経由) に通知
  3. R-Switch2 HW は、domU キューから直接データをフェッチ

 

画像
rswitch tx steps

図3 domU からのパケット送信例(TSNイーサネットスイッチによる共有)

他方、Xen ブリッジネットワークを使用する場合、domU からフレームを送信するときの手順は次のとおりです (図4 参照)

  1. domUは送信するデータをメモリに書き込む
  2. メモリはdom0 のバックエンドと共有される
  3. バックエンドは、パケットをXen ブリッジに転送
  4. パケットはdom0 ネットワークスタックを介してルーティングされ、最終的にはネットワークインターフェイスドライバにルーティングされる
  5. ドライバーはパケットのデータをNIC キューにコピー
  6. NIC はメモリからデータにアクセス
画像
xenbr tx steps

図4 domU (Xen Bridged Network)からのパケット送信例

5.    パフォーマンスの比較

システムの性能は、domUから/からdomUへ向け定レートのUDPストリームを生成し、同時にdom0とdomUの両方のCPU負荷を測定した。

ネットワークフレームがdomU から送受信されているにもかかわらずdom0 のCPU 使用率を測定する理由は、domU パケットをdom0 のネットワークスタックによって再ルーティングする必要があるため、仮想スイッチがソフトウェアで実装されている場合に、より高い負荷が見込まれるためです。

次に、このPOC に実装されているソリューションを、仮想スイッチを実装し、複数の仮想マシンを同じネットワークに接続できるようにする一般的なソフトウェアソリューションであるXen ブリッジネットワークと比較しました。

結果を図5と図6に示し、仮定を確認します。TSNイーサネットスイッチを用いて共有を行う場合、dom0 のCPU 負荷はXen ブリッジネットワークと比較して約50% 低くなりますが、domU のCPU 負荷はほぼ同じです。

 

画像
domu recv test

図5 domU 受信テスト時のCPU 負荷(1Gbps 固定レート)

画像
domu xmit test

図6 domU 送信テスト時のCPU 負荷(600 Mbps 固定レート)

TSNイーサネットスイッチにおける残りのdom0 CPU 負荷は、domUとのイベント通知によって発生します。つまり、dom0は新しい受信データが使用可能になるとdomU に通知したり、dom0 がdomU からの要求をTSNイーサネットスイッチに転送してTX キューの処理を開始したりします。

Xen Bridge のようなソフトウェアベースのスイッチの場合、dom0 にはdomU パケットをルーティングするための追加の処理が発生し、これがシステムのボトルネックになる可能性があります。ハードウェアソリューションにおいては、domUパケットのルーティングは、統合ネットワークスイッチによってハードウェアで行われ、CPUリソースを解放し、2つのドメイン間のアイソレーションを改善します。

6.    まとめ

統合ハードウェアスイッチにより、ソフトウェアスイッチを簡素化したり、冗長化することによって、自家管理タスクではなくアプリケーション処理のためにリソースを解放できます。評価により、ハードウェア支援仮想化を使用する場合、貴重なCPUリソースの50%以上が節約されていることがわかりました。ルネサスの車載TSNイーサネットスイッチは、複数の受信および送信キューのサポートが、仮想化によるECU統合の流れにおいて明確な利点であることをご紹介いたしました。この機能は、L2 およびL3 ルーティングとTSN 拡張のHW サポートとともに、将来のECU の実装に最適な候補となります。

リンク:
•    Vehicle Computer 3 
•    R-Car H3
当ブログシリーズ
•    Part 1
•    Part 2

この記事をシェアする

Log in or register to post comments

この記事をシェアする