NI VCOM使用した確定ECU通信テストため信号ベースRestbusシミュレーション

概要

最近の自動車システムは、CAN、LIN、車載イーサネットなどのネットワークを介してデータを交換する分散ECUに依存しており、通信動作はシステム全体の機能にとって重要です。しかし、開発中、完全な車両システムが利用可能になることはめったになく、ECU間の相互作用を検証するエンジニアの能力が制限されます。このような状況では、統合が遅れ、テストカバレッジが減少し、後期の問題のリスクが増加することがよくあります。 

 

Restbusシミュレーションは、欠損しているネットワークノードの通信動作を再現することで、現実的で再現可能なテスト環境を実現することで、この課題に対処します。車両ネットワークが複雑化し、AUTOSARベースの通信を採用するにつれて、正確で信頼性の高いECU検証を行うためには、スケーラブルでデータベース駆動型のアプローチが不可欠になります。NI VCOMは、車両データベースから信号ベースのrestbusシミュレーションを直接実行することで、このニーズに対応し、CAN、LIN、および車載イーサネット環境でECU検証の一貫した保守可能な基盤を提供します。 

内容

通信データベースその役割

VCOMのrestbusシミュレーションの確度は、通信データの品質に直接依存します。VCOMは、手動で開発された通信モデルを必要とする代わりに、車両通信データベースから直接動作を実行し、データベースをテスト環境全体の基盤にします。

VCOMでのRestbusシミュレーションは、ネットワーク、ノード、プロトコルデータユニット(PDU)、フレーム、信号、タイミング、および保護ルールを定義する通信データベースによって完全に実行されます。VCOMは、DBC、LDF、AUTOSAR ARXML形式をサポートしています。

最近の車両プログラムでは、AUTOSAR ARXMLは車両ネットワーク上の通信関係を記述するため、レストバスシミュレーションの主要なソースです。正確なシミュレーションを行うためには、VCOMは関連するすべての通信参加者を含むシステムレベルの抽出を必要とします。通常、ECU抽出物だけでは不十分です。これは、restbusの動作が送信と受信の両方の関係に依存するためです。

実際には、ARXMLファイルを使用する前に確認とクリーンアップが必要になることがよくあります。VCOMは、これらのデータベース定義を実行可能なrestbus動作に変換するフレームワークを提供し、テスト環境と意図された車両通信アーキテクチャ間の一貫性を維持します。 

Vehicle Communication Software Suite詳細 

最近のECUは絶縁で動作することはほとんどありません。HILおよびベンチテストでは、実際の条件下でECU機能を検証するために、エンジニアは車両ネットワークの動作を再現する必要があります。

VCOMは、HILおよびベンチテストシステム用の信号ベースのrestbusシミュレーションを提供するソフトウェアパッケージです。NI-XNETドライバレイヤ上に構築されており、車両データベースから直接通信を実行します。これにより、ネットワークノードが見つからない場合の動作を再現できるため、エンジニアは車両システムが完成する前にECUの機能を検証できます。タイミング、メッセージパッキング、保護メカニズムなどのプロトコル特有の詳細を処理することで、エンジニアは通信実装ではなくECU検証に集中できます。

VCOMは、CAN、LIN、および車載イーサネット用のNI-XNETインタフェースを使用してMicrosoft Windows PCおよびNI Linux RTターゲットで実行し、開発ベンチ環境とラックベースのHIL環境の両方でデプロイできます。オプションの診断 (UDS) ツールキットおよび測定/キャリブレーション (CCP/XCP) ツールキットにより、テスト自動化機能がさらに拡張されます。

VCOMデータベース定義から通信実行する方法

VCOMは、カスタムコードの通信ロジックに依存するのではなく、インポートされたデータベースから直接すべての送受信動作を取得します。シミュレーションされた各ネットワークノードは、構成されたネットワーク、タイミングパラメータ、および保護ルールを使用して、エンジニアがプロトコル動作を手動で実装しなくても、定義されたとおりに動作します。

CANでは、出力フレームは、スケール、オフセット、ビットレイアウト、エンディアン、および関連するチェックサム、カウンタ、またはAUTOSARのエンドツーエンド保護に従って信号値をエンコードすることで生成されます。受信フレームは信号にデコードされ、テストロジック、スクリプト、またはオブザーバで使用可能になります。メッセージタイミングは、周期とオフセットが定義された周期的送信や、状態変化または外部要求によってトリガされるイベント駆動型送信など、明示的です。 

LINでは、フレームスケジュールはどのフレームがどのスロットにどのレートで表示されるかを制御します。車載イーサネットでは、VCOMはARXMLで定義されたSOME/IP通信 (サービス検出、イベント送信、および該当する場合の呼び出し方法を含む) を実行します。すべての場合において、VCOMは通信仕様を実行しますが、ECUの内部動作は実装しません。 

エンジンコントローラシナリオ

テスト中のエンジンコントローラが、通信仕様に従って静止バスからMotor_Speedを使用し、トルク要求とスロットル位置メッセージを送信する場合を考えてみます。 

ベンチでは、Motor_Speedはレストバスシミュレーションによってアイドル状態から赤線に駆動され、外部温度モデルはコールドスタートから通常の動作状態に遷移します。VCOMは、タイミング、スケール、カウンタ、保護など、データベースで定義されているとおりにすべてのrestbus通信をエンコードして転送します。 

ロバストネスを評価するために、このテストでは5%のMotor_Speedメッセージが1秒間ドロップされる制御外乱を導入します。成功基準は、通信レベルで厳密に観察できます。エンジンコントローラは、障害発生から100 ms以内に定義された安全な方法を入力し、有効なトラフィックが再開してから200 ms以内に通常の動作に戻る必要があります。回復後は、診断トラブルコードがアクティブでないようにします。 

このシナリオは、一般的なrestbusの使用例を示しています。VCOMは通信コンテキストと障害注入ポイントを提供し、ECUの動作と物理モデルはrestbusシミュレーションの範囲外のままです。  

VCOM実装れるプロトコル機能

VCOMは、現在の車両プログラムおよび新しい車両プログラムで一般的に使用されるプロトコルをサポートしています。このカバレッジにより、プロトコルごとに個別のツールを使用せずに、単一のrestbus環境で検査対象ECUに関連するネットワーク動作を再現できます。

サポートされているプロトコルには、CAN、LIN、および車載イーサネットがあります。車載イーサネットでは、SOME/IP通信は、必要なサービス検出メカニズムを含むARXMLで提供されるサービス定義に従ってサポートされています。J1939は、高負荷アプリケーションでの基本的な多重化およびネットワーク管理をサポートします。 

送信動作は、循環メッセージ、イベント駆動メッセージ、自発メッセージなど、データベース定義から自動的に取得されます。VCOMは、マルチプレクスPDU、コンテナPDU、AUTOSAR通信ストラクチャをネイティブに実行するため、複雑なシステム定義を手動でプロトコルコーディングすることなく実行できます。カウンタ信号、CRC、およびAUTOSARのエンドツーエンドの保護プロファイルは実行時に自動的に生成および評価され、カスタムユーザコードで一般的に発生するレイテンシ、CPU負荷、およびメンテナンスのオーバーヘッドを回避する確定的で高性能な実行を提供します。 

信号値はAPIを介して書き込むかオーバーライドしてテストシナリオを駆動できますが、保護メカニズムはシステムによって一貫して適用され続けます。  

セキュリティ保護

自動車プログラムでは、ECU検証中に通信整合性メカニズムが存在し、機能することが、本番環境だけでなくますます必要になっています。VCOMは、これらの要件を個別のエンジニアリングタスクとしてではなく、通常のrestbus実行の一部として処理します。

VCOMは、いくつかのOEMに組み込まれているセキュアオンボード通信 (SecOC) プロファイルを実装しています。必要に応じて、追加のプロファイルも利用可能です。チェックサム、カウンタ、AUTOSARエンドツーエンド保護プロファイルは、各PDUに添付されている通信仕様に基づいて自動的に計算されます。 

リンクレベルのセキュリティを必要とする車載イーサネット設定では、サポートされているNI XNETイーサネットインタフェースでMACsecを有効にできます。これらの構成では、VCOMはアプリケーションとPDUレベルで動作し続け、暗号化とリンク保護はドライバとハードウェアによって透過的に処理されます。 

ネットワーク管理状態

検査対象ECUが正しく動作するには、周囲のネットワークが現実的な状態遷移を反映する必要があります。スリープ、ウェイク、およびネットワークモードの遷移を考慮しない restbus 環境では、実際の車両にはないテスト条件が発生し、誤解を招く結果を招く可能性があります。

VCOMは、データベースで定義されたCANおよび車載イーサネットのAUTOSARネットワーク管理動作を実行し、ノードが状態間を遷移する際に検査対象ECUが一貫したシステム環境を認識するようにします。 

TC10などの車載イーサネットの物理的なスリープおよびウェイクメカニズムは、NI XNETドライバおよびサポートされているハードウェアによって処理されます。VCOMは、このレイヤよりも上で動作し、実際のウェイク動作を直接制御するのではなく、結果としてのネットワーク状態の変化に反応します。 

VCOM使用したシステムアーキテクチャ

VCOMは、既存のHILおよびベンチ環境を置き換えるのではなく、統合するように設計されています。通常のHILセットアップでは、VCOMはNI VeriStandまたはNI LabVIEWなどのシステムレベルのツールとともにデプロイされます。これらの環境は、テストの実行を制御し、VCOM APIを介して実行中のrestbusシミュレーションと対話します。操作には、シミュレーションの開始と停止、信号値の読み取りと書き込み、ネットワークイベントへの応答が含まれます。 

VCOMは、restbusシミュレーションレイヤとオプションの診断およびキャリブレーション機能を提供します。NI-XNETでは、DUTが車両と同じように接続されている、CAN、LIN、および車載イーサネットの物理インタフェースが提供されます。WebUIは、データベース検査とライブトラフィック監視をサポートしているため、ベンチの起動とトラブルシューティングが簡素化されます。 

NI Vehicle Communication (VCOM) Software Suite使用したスケールRestbusシミュレーション

車両通信ネットワークが複雑になるにつれ、restbusシミュレーションの開発と維持に必要な労力がボトルネックになることがよくあります。多くのテスト環境では、通信動作はカスタムスクリプトまたはアプリケーション固有のロジックによって実装されます。この方法は個々のベンチに対して効果的ですが、通信定義が進化するにつれて、複数のテストシステムにわたって一貫性を維持することが難しくなります。

VCOMは、データベース駆動型のアプローチでこの課題に対処します。通信動作は、信号符号化、タイミング、多重化、カウンタ、CRC、AUTOSAR保護メカニズムなど、DBC、LDF、およびAUTOSAR ARXML定義から直接実行されます。通信要件が変更された場合、エンジニアは複数のテストベンチ間で通信ロジックを変更するのではなく、データベース定義を更新します。

このアプローチは、検証アクティビティをスケールする場合に特に有効です。開発ベンチで検証されたレストバス構成は、同じ通信定義と動作を使用して追加のHILシステムにデプロイできます。通信実行はデータベースに接続されたままであるため、すべてのベンチは共通のソースから動作し、個別に保守されるスクリプトまたは構成によって生じる不整合のリスクを軽減します。 

VCOMプロジェクトはWindowsとNI Linuxの両方のRTターゲットで実行し、共通のAPIを介してLabVIEWおよびVeriStandと統合します。これにより、一貫したネットワーク動作を維持しながら、デスクトップ、ラックベース、および自動テスト環境で通信構成を再利用できます。

テスト容量が大きくなると、スループットが向上するだけでなく、再現性とトレーサビリティも向上します。エンジニアリングの労力は、複数のベンチ間で通信インフラストラクチャを維持するよりも、ECUの検証とテストカバレッジに集中できます。

ベンチ起動実装に関するヒント

新しいベンチにVCOMをデプロイするには、予測可能な一連の初期段階の検証ステップが必要です。以下のガイダンスは、一般的な起動パターンを反映しており、チームが初期構成から検証済みの通信動作に効率的に移行するのに役立ちます。

  • アンカー信号の短いリストと既知のペイロードを使用して、エンディアン、スケール、符号規則を早期に検証します。 
  • LINでは、スケジュールが明示的に構成され、プロジェクトロード後にアクティブ化されていることを確認してください。無音に見えるノードは、多くの場合、スケジュールが見つからないか非アクティブなために発生します。 
  • 検査対象ECUの診断ステートマシンをキャプチャします。診断セッションとセキュリティレベルは、メッセージの可用性と内容を変更する可能性があります。 
  • MACsecなどのリンクレベルセキュリティをインフラストラクチャとして扱います。キーと回転は、シナリオロジック内ではなく、インタフェースとドライバレベルで構成します。 
  • 長い回帰を実行する前にバス使用率を測定します。バースト、非同期診断、およびエラー処理トラフィックには余白を残します。 
  • AUTOSAR ARXMLを使用する場合、完全なシステム抽出が提供されていることを確認してください。VCOMでは、関連するすべてのエンドポイントを定義する必要があります。ECUのみの抽出物は、restbusシミュレーションには不十分で、通常ベンチで使用する前に統合する必要があります。 

まとめ

車両プログラム全体で正確で一貫性のあるrestbusシミュレーションを維持することは、通信定義の進化、テストベンチの増加、プロトコルの複雑さの増大に伴って増大する継続的なエンジニアリングの課題です。

通信プロトコル自体に問題があることはほとんどありません。シミュレーションロジックの維持、テストベンチの同期、データベースリビジョンの処理、および信号符号化、カウンタ、CRC、ネットワーク管理、保護メカニズムなどのプロトコル詳細の実装をプロジェクト全体で一貫して行うことにより、エンジニアリングに多くの労力が費やされます。

VCOMは、データベース駆動型の通信アーキテクチャを通じてこれらの課題に対処します。DBC、LDF、およびAUTOSAR ARXML定義から直接通信動作を実行することで、VCOMはCAN、LIN、車載イーサネット、SOME/IP、およびJ1939通信の統一されたフレームワークを提供すると同時に、タイミング、多重化、カウンタ、CRC、AUTOSARエンドツーエンド保護、およびサポートされているSecOCプロファイルなどのプロトコル特有の動作を自動的に管理します。エンジニアリングチームは、カスタム通信実装を開発および維持する代わりに、進化する車両ネットワーク定義に沿った単一の通信基盤で標準化することができます。

このアーキテクチャは、検証作業が複数のチーム、プロジェクト、およびテスト環境に拡大するにつれて、ますます価値が高まっています。同じ通信構成、API、および自動化ワークフローをデスクトップ開発システム、HILベンチ、および自動化されたテストインフラストラクチャ全体にデプロイできるため、重複を削減しながら検証プロセス全体で一貫性を維持できます。

実際には、これにより以下が可能になります。

  • 新しいテストベンチでのrestbusシミュレーションの迅速な展開
  • カスタム通信およびシミュレーションコードのメンテナンスを削減
  • CRC、カウンタ、保護メカニズムでの実装エラーのリスクを低減
  • データベースの更新と通信変更の管理を簡素化
  • 検証環境での通信構成の再利用の促進

この値は、ネットワークトラフィックのシミュレーションの範囲を超えています。VCOMは、拡張性と保守性に優れた通信基盤を提供し、エンジニアリングのオーバーヘッドを削減し、検証環境全体での一貫性を向上させ、通信インフラストラクチャの管理ではなくECU機能の検証に集中できるようにします。

ステップ

参考資料