中間者テストで車載イーサネットネットワークを検証する

車載イーサネットは、コントローラエリアネットワーク (CAN) やローカル相互接続ネットワーク (LIN) などのレガシープロトコルよりも複雑です。上位レベルのソフトウェア検証は一般的ですが、フレームの破損、タイミング違反、電気的ノイズなどの下位レベルの通信エラーは、商用NICによって除去され、検出されないことがよくあります。これらの障害は、ECUソフトウェアのロックアップ、原因不明のエラーメッセージ、レイテンシのスパイク、TC10などのスリープ/スリープ解除プロトコルの障害として発生する可能性があります。

信頼性と安全性を確保するには、これらの問題が発生したMACレイヤでテストを行えるツールが必要です。MitMテストは、破損したフレームチェックシーケンス (FCS) などの異常を含むライブトラフィックのアクティブな操作を有効にして、実際の条件下でシステムの堅牢性を評価することで、このギャップに対処します。この機能は、イーサネットが時間依存型で安全性が重要なアプリケーションをサポートする最新の車両にとって重要です。

中間者テストで車載イーサネットネットワークを検証する

自動車のコネクテッド化、自律化、ソフトウェアデファインド化が進むにつれて、車載イーサネットは車載通信のバックボーンとして台頭しつつあります。先進運転支援システム (ADAS) からインフォテインメント、車両とあらゆるモノ (V2X) まで、車載イーサネットは複雑化する電子制御ユニット (ECU) 間で高速かつ低レイテンシのデータ交換を可能にします。

しかし、従来の検証方法では、ソフトウェアのロックアップ、タイミングの問題、および予期しない動作を引き起こす可能性がある低レベルの通信障害を見過ごすことがよくあります。このホワイトペーパーでは、隠れた問題を明らかにし、車載イーサネットネットワークの堅牢性を検証するための強力な技術として中間者テスト（MitM）を紹介します。

モジュール式NIハードウェアプラットフォーム、特にNI PXIe-6592（MitMとパーソナリティ/Sim-DUTの両方に使用）を活用することで、エンジニアは実世界の障害をシミュレーションし、トラフィックを注入し、ECU応答を正確に監視することができます。

MitMテストでは、2つの通信デバイス（通常はECUまたはゲートウェイ）間にプログラム可能なテストシステムを挿入して、MACレイヤでネットワークトラフィックを傍受、操作、および解析します。パッシブ監視とは異なり、MitMを使用すると、エンジニアはアクティブなライブトラフィックを操作でき、制御された中断によって耐障害性とエラー処理メカニズムを検証することができます。

図1: MitMアーキテクチャ図

従来のNICは無効なフレームを破棄するため、障害注入は不可能です。PXIe-6592高速シリアルモジュールは、オペレーティングシステム (OS) およびネットワークインタフェースカード (NIC) レイヤをバイパスし、有効または破損したイーサネットフレームにマイクロ秒遅延およびサブマイクロ秒タイムスタンプ確度で直接アクセスできるようにします。エンジニアは、FCSの切断、ファイルまたはライブソースからのトラフィックの注入、TC10スリープ/ウェイクコマンドのトリガ、パケットキャプチャ（PCAP）ファイルへのトラフィックのログ、Googleリモートプロシージャコール（gRPC）アプリケーションプログラミングインタフェース（API）を使用したテストの自動化を行うことができます。

図2: MitMワークフロー図

大規模な中間者テストを可能にするために、NIモジュール式プラットフォームは車載イーサネットトラフィックの高性能で確定的な制御用に設計されています。従来のNICベースのソリューションとは異なり、このプラットフォームはFPGAレベルの柔軟性とPXIの同期および拡張性を兼ね備えているため、障害注入、タイミング解析、およびプロトコル検証に最適です。システムは、リアルタイムフレーム操作用の専用ハードウェアと、自動化、リモート制御、およびディープパケットインスペクションをサポートするソフトウェアスタックを中核に統合しています。

ハードウェア:100/1000BASE-T1およびその他のイーサネットバリアントをサポートする4つのSFPポートを備えたPXIe-6592。

ソフトウェア:自動化のためのNI LabVIEWおよびgRPC API、およびパケット解析のためのPCAP統合。

車載イーサネットのMitMテストでは、エンジニアがMACレイヤでネットワークトラフィックを操作および解析する方法を2つのコア機能で定義します。

• FCS 操作：イーサネット フレームのフレーム チェック シーケンスを変更して破損をシミュレーションし、エラー処理メカニズムを検証します。MitMにはいくつかのFCSブレークモードがあります。
• 注入方法―これらの方法は、合成または再生された追加のトラフィックを通信ストリームに導入して、現実的または極端な条件下でECUにストレステストを行う方法です。

これらの機能を組み合わせることで、エンジニアは、従来のNICやパッシブ監視では実現できなかった、フィールドの問題を再現し、制御された障害を注入し、さまざまなシナリオで堅牢性を検証することができます。

それぞれの特徴を掘り下げて分析してみましょう。

以下の図は、FCSブレーク機能（赤い四角形）が適用された場所を示します。ポート0で集録されたトラフィックはFCSブレーク機能に渡され、変更されたトラフィックはミキサに渡されます。

図3: MitM FCSブレーク機能の位置

MitMは複数のFCS操作モードをサポートしています。これらのモードはWireshark®*にロードされたPCAPファイルで示されており、一部の画面キャプチャは 付録Aで参照できます。

• すべて有効:すべてのフレームに不正なFCSがあります。
• すべて無効:すべてのフレームに正しいFCSがあります。
• 1サイクル―50%:フレームの半分に破損したFCSがあります。
• Nサイクル数―50%:すべてのフレームでFCSが壊れています。
• ランダム:ランダムなFCS破損。
• パーセント:破損したフレームのユーザ定義の割合。
• カスタム:正確な制御のために配列 (最大8,192要素) をアップロードします。
  

図4は、FPGAがFCSブレーク設定を着信トラフィックに適用する方法を示しています。

図4: FCS Break FPGAアルゴリズム

MitMは2つの注入方法をサポートしています。

フレーム発生器（DMA）はストレステスト用にフレームを生成し、ポート注入はポート1からのライブトラフィックを生成されたフレームと混合します。

挿入されたトラフィックはFCSで変更されたフレームと組み合わされ、実際のネットワーク状態をシミュレートします。図5の赤い四角形は、注入パスを示します。

図5: 注入

付録Bには、フレーム発生器（DMA）注入方法のテスト条件と結果が記載されています。

2台目のPXIe-6592を使用してMitMをテストします。「Sim/DUT」と呼ばれる別のFPGAパーソナリティを実行します。

図6: MitM (テスト設定) (Sim/DUT)

1.既知の障害の回帰テスト

フィールドの問題が特定の破損したフレームまたはタイミング異常によって発生した場合、MitMテストは障害シナリオの確定的再現を提供するため、エンジニアは以下のように対処できます。

• フィールドからキャプチャされた、不正なフレームやタイミングの不規則性を含む正確なトラフィックパターンを再生します。
• MACレイヤでECUの動作を監視し、エラー処理ルーチンとプロトコルスタック応答を確実に可視化します。
• 導入前に同一の条件下で修正ソフトウェアパッチを検証し、運用環境での後退のリスクを軽減します。

2.全バス負荷時のストレステスト

MitMシステムは、実際のトラフィックとシミュレーションされたトラフィックの両方を大量に混合することで、イーサネットバスの飽和を制御します。これにより、エンジニアは以下のことを実現できます。

• 帯域幅を理論上の制限値まで拡張し、最悪の条件下でスループットとレイテンシを検証します。
• フレームの優先順位付けやバッファ管理など、輻輳時のECUパフォーマンスを特性化します。
• セーフティクリティカルなアプリケーションにおける確定的通信を損なう可能性のあるタイミング違反とボトルネックを特定します。

3.スリープ/ウェイクプロトコル検証 (TC10)

電気自動車では、TC10プロトコルはアクティブ状態と低電力状態の間の遷移を制御します。MitMテストは、以下の方法でコンプライアンスと堅牢性を確保します。

• スリープ/ウェイクシーケンスをマイクロ秒の精度でトリガし、実際のタイミング制約をシミュレートします。
• 不完全なネットワーク状態に対するECUの復元性を検証するために、ノイズまたは遅延を制御します。
• レイテンシと電力遷移動作を測定し、OEM電源管理要件に準拠するための定量データを提供します。

イーサネット検証にMitMシステムを採用したことで、自動車ネットワークのテストと保証が大幅に向上しました。これらのソリューションは、トラフィック注入、障害シミュレーション、およびプロトコル検証を正確に制御することで、エンジニアは実際のネットワーク状態を再現し、ECUの動作を徹底的に評価し、厳しい業界要件への準拠を検証することができます。全バス負荷でのストレステストと厳密なスリープ/ウェイクプロトコル検証により、帯域幅、レイテンシ、電源管理などの重要なパラメータが測定されるだけでなく、安全性と信頼性も最適化されます。ボトルネック、タイミング違反、不完全な状態に対する復元力を特定する能力は、次世代の電気自動車やコネクテッドカーを開発するための強固な基盤となります。

車載イーサネットが進化し続ける中、FPGAベースのハードウェアや柔軟で自動化されたソフトウェアなどの高度な検証ツールの統合は、OEMおよびTier 1サプライヤにとって不可欠です。これらの技術は、開発プロセスを合理化するだけでなく、車両の安全性、接続性、効率性の基準も向上させます。今後、ますます複雑化する車両アーキテクチャの要求を満たし、将来のモビリティソリューションのシームレスな運用を確保するには、現実的なテストに基づいた包括的な検証戦略が不可欠です。

このセクションでは、MitMで使用できるさまざまなFCSブレークモードについて説明します。

メモ:以下のスクリーンショットのサンプルでは、Wireshark®が使用されています。

• FCSをチェックし、FCSを予期します。
• 無効なFCSで赤いフォントフレームで表示します。

すべて有効モード

すべて有効モードでは、すべてのフレームのFCSが壊れています。

図7: すべて有効のFCS遮断モードすべて有効のFCS遮断モード―キャプチャされたすべてのイーサネットフレームで、MitM破損による無効なFCSが表示されます。

すべて無効モード

全無効モードでは、FCSが壊れているフレームはありません。

図8: 全無効FCS切断モード―すべてのフレームを含む通常のイーサネットトラフィックを示すワイヤシャークキャプチャ

1 サイクル 50% モード

この例では、ブロックサイズは20フレームです。つまり、ブロックの50% (10フレーム) でFCSが壊れ、残り (10フレーム) でFCSが未処理であることを意味します。

図9: サイクル50% FCS切断モード―各ブロックのフレームの半分はFCSが壊れており、残りの半分は有効です。

Nサイクル50%モード

この例では、すべてのフレームでFCSが壊れています。

図10: Nサイクル50% FCS切断モード―他のすべてのイーサネットフレームでは、FCSが意図的に切断されています。

パーセント (%) モード

このモードでは、ブロックサイズは100フレームで、ユーザによって渡されたパーセンテージは80です。つまり、ブロックの80% (80フレーム) でFCSが壊れ、残り (20フレーム) でFCSが壊れていないことを意味します。

図11: 割合 (%) FCS Break Mode―フレームの 80% が意図的に FCS を壊し、20% が有効なままである 100 フレームの繰り返しブロック。

ランダムモード

この例では、ユーザがブロックサイズ（最大8,192）を定義し、ランダム値（TRUEまたはFALSE）が合成され、フレームFCSが壊れるタイミングを定義するために使用されます。そして、それが繰り返されます。

図12: ランダムFCSブレークモード – イーサネットフレームのFCSブレークは、ユーザ定義のブロックサイズ内のランダムパターンに従って周期的に繰り返されます。

このセクションでは、注入 (フレーム発生器 (DMA)) の使用法を説明します。

テスト条件

これは、1 Gb/sでのテスト結果です。

• MitMのポート0は、1000BASE-T1リンクを介してデータソースに接続されています。
• ポート2および3は、ダイレクトSFPケーブルを介して他のテストポートに接続されています。テストポートは、受信したフレーム数の測定に使用されます。
• PCAPスニファ機能を使用して、ミキサの出力トラフィック（MitM Txデータ）を集録します。これにより、操作のタイムスタンプが非常に正確になります。
• テストは3つの段階で行われます。
  • 第1段階:ポート0（MitM Rx）でトラフィックの適用を開始します。トラフィックは20ストリーム、100µs周期で構成されています。ストリームサイズは78～173 バイト x 5 バイト間隔です。MACソース:00:2F:80:17:29:68トラフィックは、SFP 1000BASE-T1アダプタで使用される別のFPGAベースのソースによって生成されます。
  • 第2段階:ポート0でトラフィックを適用している間に、フレーム発生器を起動します。発生器からのトラフィックは、ポート0に適用されるものと同じですが、MACソースが異なります。 00:2F80:11:25:34
  • フェーズ3:ポート0のトラフィックはなくなり、 注入フレーム発生器 のみになります。
• データ量は合計1,200,000フレームです。内訳:
  • MitM Rxに600,000フレーム (30,000フレーム/ストリーム、20ストリーム) を適用、MACソース:00:2F:80:17:29:68
  • フレーム発生器 (DMA)、MACソースによって生成された60万フレーム (30,000フレーム/ストリーム、20ストリーム)00:2F80:11:25:34

テスト結果

第1段階

MitM Rxのみがあります。図13は、ストリームと時間の関係を示しています。各バーの幅はストリームサイズに比例します。

図13: テスト結果 – フェーズ1 (MitM Rxのみ) – 相対ストリームサイズを示すバー幅で時間の経過とともにストリームアクティビティを表示します。

図14は、100µs周期で生成される20ストリームの各ブロックを示しています。同じ結果で、 1周期分拡大します。

図14: テスト結果 – フェーズ1 (ズーム表示) – 1つの100µs周期のズームイン表示で、20の受信ストリームが順番に発行されていることを示しています。

連続した2つのストリームの開始時間の間に4µsが必要です。

図15は、フェーズ1のデータのサブセットを示します。各ストリームの周期の平均、周期の標準偏差 (s) および分散 (s²) を計算します。ここでは、MACソース00:2F:80:17:29:68からのデータのみが表示され、フレーム発生器はまだ実行されていません。

図15: テスト結果フェーズ1サブセット: MAC 00:2F:80:17:29:68のストリーム周期ごとの統計 (平均、σ、σ²)、フレーム発生器無効。

もう1つの興味深い測定は、2つの連続したストリーム間の時間です。図16は、結合された周期のグラフを示します。4 µsを予想しています。

図16: テスト結果フェーズ1: 周期が結合されたストリーム間時間、連続するストリーム間で約4 µs。

第2段階

このフェーズでは、MitM Rxとフレーム発生器の両方でトラフィックが発生します。図17では、異なるトラフィックソースからのさまざまなストリームを見ることができます。

図17: テスト結果 – フェーズ2 – 複数のソースからの同時MitM Rxトラフィックとフレーム発生器トラフィックを示すストリームを時系列で表示します。

プレーンバーのプロットは、MitM Rxからのプロットです（MACソースは、00:2F:80:17:29:68)。その他のもの（非プレーン）は、注入（フレーム発生器）からのものです。MACソースは以下のとおりです。00:2F:80:11:25:34. MitM Rxからのトラフィックは注入トラフィックよりも優先されます。そのため、MitM Rxと注入の両方にフレームがある場合、MitM Rxからのフレームに優先度があります。

ミキサで、送信されるMitM Rxからのフレームではなく、送信される注入からのフレームがある場合、注入トラフィックはMitM Rxトラフィックタイミングに影響を与える可能性があります。MitM Rxからの注入中に利用可能な場合、その放射は時間内に遅延します。その位相間のストリーム間時間を見ると、このことが分かります。理論的には4µsです。

図18: テスト結果 – フェーズ2ストリーム間タイミング – MitM Rxに優先度があるにもかかわらず、注入トラフィックがミキサを占有している場合の遅延MtM Rxフレームを示すストリーム間時間。

テスト中にストリームの統計を見ると、平均値が100µsのままの場合、標準偏差（位相1と比較した場合）のタイミングへの影響も確認できます。

図19: テスト結果 – フェーズ2ストリーム統計 – 平均ストリーム周期は100 µsのままですが、標準偏差の増加により、同時注入トラフィックによって発生するタイミング変動が際立っています。

第3段階

この段階では、フレーム発生器からのトラフィックのみがあります。MACソースは00:2F:80:11:25:34です。

図20: テスト結果 – フェーズ3 – MACからのフレーム発生器トラフィックのみを示すストリームアクティビティ 00:2F:80:11:25:34。

位相 3 トラフィックの概要に続き、次に、MitM Rx トラフィックがない場合の個々のフレーム発生器ストリームの時間的分布をハイライトするために、より小さい時間ウィンドウにズームインします。

図21: テスト結果 – フェーズ3 (ズーム表示) – MitM Rx干渉のない一定のストリーム間隔を示すフレーム発生器ストリームの時間の経過に伴うズームインビュー。

時間領域の視覚化に加えて、フレーム間統計は、フレーム発生器トラフィックのみが存在する場合のタイミング動作をさらに詳細に把握し、MitM Rx干渉がない場合の安定した伝送間隔と低ジッタを確認します。

図22: テスト結果 – フェーズ3フレーム間統計 – フェーズ3中の注入専用トラフィックのストリームごとのフレーム間タイミングメトリック。

全体

最後に、すべてのフェーズの統計を集計して、すべてのストリームの全体的なスループットとタイミングの安定性を評価します。

図23: 全体的なテスト統計―キャプチャされた合計フレーム数1,200,000 (ストリームあたり30,000フレームに相当) を示す集計結果。

最後に、テスト全体にわたるグローバルストリーム間タイミングを検証して、アクティブなMitM受信トラフィック（位相 1および位相 2）と注入のみのトラフィックとの位相におけるシステム動作を比較し、コンカレントソースが全体的なタイミング特性にどのように影響するかを明らかにします。

図24: グローバルストリーム間時間プロットは、位相1では4µs間隔が平坦で、位相2ではタイミング変動が大きいことを示しています。位相3では注入のみのストリーム間データは表示されません。

• 車載イーサネットテストの詳細
• NI PXIベースの検証プラットフォーム
• NI Vehicle Communication Toolkitの詳細
• 「NI PXIe-8520およびNI PXIe-8523でのECUテスト」を参照
• 自動車システムのHILテストを理解する