01

利点は、標準化されたアクセス手法が使用されることです。 唯一の前提条件は診断ドライバーが完全に統合されていることですが、これは現在のECUならほぼ問題ありません。その一方で診断では、必要な値以外の診断プロトコル情報が大量に伝送されるという欠点があり、それによりネットワークシステムの インターフェイス負荷が大きくなります。また、多くの値のデータフロー分析を行うことは不可能で、これは測定値にタイム スタンプ情報が含まれていないためです。

ほとんどの場合はECUの入出力を点検すれば、デバイスの機能 テストには十分です（図1）。ところが、ECU内でステートマシンが使用されている場合には、それが困難になります。ステート マシンの状態は、そのステートマシンがECUの出力に与えて いる影響を調べることで間接的に知るほかありません。値が ネットワークシステムで伝送されないセンサーの場合も、ソフトウェアインターフェイスのどこでエラーが発生しているのかを テストエンジニアが特定するのは非常に困難です。センサーの値が正しく処理されていない箇所は、ECUの外部から見ても 正確には分かりません。ECUの内部データにアクセスする方法は、ECUの開発フェーズによって異なります。たとえば開発の初期段階では、内部ECU値は通常「開発用の予約メッセージ」で出力されます（図1）。 サプライヤーの機能開発者は、このターゲット用特定メッセージを使用して、効果的かつ迅速に値を確認できます。ただし、 そのような付加的なメッセージは、開発後期には削除しなければなりません。システム統合と量産工程の妨げになるからです。それらのメッセージはバス負荷を増やし、最悪の場合には他のシステムデバイスのメッセージと衝突することさえあります。内部ECU値にアクセスするもう1つの方法は診断です（図1）。診断では、たとえばフォールトメモリーにアクセスし、特定の 情報を直接得ることが可能で、メモリーから必要な値を読み 取るための専用診断サービスも提供されています。この方法の

ブラックボックステストは一般的に、ECUの開発プロセスの一部として、あるいはECUの動作異常を解析するために実施されます。 テストでは刺激入力と測定のために、ECUの入出力をテストシステムに接続します。この方法は広範囲にわたる解析を可能にしますが、テストによっては直接ECU内部にアクセスする必要があります。これを行うことなしに、有意義なテスト結果を得ることはできず、テスト工数の削減もできません。

XCPを用いたECUテスト

シーケンスの詳細を探る

図1：従来型のECUテストシステム。診断機能や、開発者が作成した専用 メッセージを通じて、ECUの内部値に限定的にアクセス

02

Technical Article / January 2019

XCPによるテストアクセス

ネットワークインターフェイスの負荷を低く維持する必要が ある場合は、上記の方法の代わりにキャリブレーションプロトコルを使用できます。そのようなプロトコルは元来、ECUの キャリブレーションエンジニアのために開発されました。キャリブレーションプロトコルを使用することで、エンジニアはECU内のパラメーターや特性マップに変更を加え、アルゴリズムを 最適化できます。ASAMで標準化されたキャリブレーション プロトコル｢XCP｣では、ECUからを必要に応じて個々の値を 直接読み取ることができます。さらにDAQ（Data Acquisition）と呼ばれるデータ収録リストを通じて、定義済みの測定値セットをECUから定期的に取得することも可能です。XCPプロトコルは、ネットワーク媒体経由でのデータ伝送の効率化を目的として定義されています。したがって、DAQリストの設定後にテストシステムから識別子を1つ渡せば、それに応じたデータを伝送 できます。DAQリストの測定タイミングをECU内部のプロセスに対して同期させることもできます。自動テストシステムでも、システムに対する要件は同様です。XCPプロトコルを使用すれば、ECUやネットワークシステムに過剰な負荷をかけること なく、テストシーケンスで内部値を統合できます。XCPのように広く使用されている標準規格は、ツールチェーン内での設定がきわめて容易という点でも理想的です。内部プログラムメモリー内での位置、それらの位置の名称、通信パラ メーターなど、必要なすべての情報が、あらかじめA2Lファイルに収められています。A2Lファイルは開発環境に応じて、自動的に生成されます。または、リンカーマップの情報とは別の手順で生成させる可能性があります。A2Lファイルの設定は、テスト ツールで対象のECUごとに1回ずつ行うだけです。その後、テストシーケンスに必要なシンボルをA2Lファイルから選択します。

CANoeオプションAMD/XCP

CANoeオプションAMD/XCPは、ベクターの車載ネットワーク開発ツール｢CANoe｣にECU内部の値の読取・書込に役立つ 機能を追加したオプション製品です。このオプションはXCP 規格に対応しているだけでなく、XCPの前身プロトコルであるCCPにも対応しています。A2Lファイルを設定して必要なパラメーターを選択すると、CANoeが値を自動的に取得してシス テム変数に割り当てます。値が割り当てられた変数は、テストのあらゆるタスクで使用できます。ECUの入出力へのアクセスのほか、これらの変数ではECUのメモリーの詳細情報も得られ ます（図2）。シンプルな解析では、トレースWindowやグラフィックWindowにデータを表示し、パネルを使用して結果を評価できます。 CANoeのテスト機能セットは、テストケースを作成して自動 評価するための幅広いなオプションが含まれており、ネット ワークマネジメントステートマシンが正しく機能しているかどうかのチェックなど、より複雑なテストシーケンスも実装でき ます。必要な刺激入力はCANoeの残りのバスシミュレーション内で実行され、ECUの反応をネットワーク上だけでなく、XCPを使用してECU内でも直接測定できます。テストケースの実行に伴う工数も大幅に軽減されます。たとえば、センサーを使用

するテストケースの場合、テストシステムがXCPを使用してセンサーの値をECU内のメモリーセルに直接書き込みます。した がって、センサーをECUの入力に接続して制御するという、手間のかかる作業は必要ありません。ECUには、センサーと関連 ハードウェアドライバーが値を正しく測定したことが通知されます。同じアプローチは他の方向にも応用できます。一例として、出力ステージとアクチュエーターがテストされ、評価される状況を想定してみましょう。この場合、アプリケーションがXCPを使用してドライバーステージに指定する値を、テストシステムが測定します。

大量のデータを伴うアクセス

テストシステムとECUの間で大量のデータを交換したり、処理速度が特に速いプロセスをモニターする必要があるテストケースには、CANネットワーク上のXCP接続は利用できません。 そのような場合に推奨されるのが、ECUのデバッグインター フェイスに直接アクセスする手法です。この手法を実装するには、NEXUSやJTAGをインターフェイスとして使用します。これらのプロトコルは、一部のマイクロコントローラーに負荷をかけずに、ECUのメモリーに直接アクセスします。その結果、ネットワークやECUの負荷を高めることなく、膨大な量のデータを システムから迅速に読み取ることが可能です。 ベクターのVXハードウェアには、ECUのNEXUSやJTAGの インターフェイスに直接アクセスする機能があります（図2）。 このハードウェアはXCPを使用し、Ethernet経由でテストシステムと通信するため、CANoeとの統合もCAN経由のXCPアクセスと同様に容易です。VXハードウェアとCANoeテストシステムを組み合わせると、通信バスに何ら悪影響を与えることなく、テストシステムのパフォーマンスを一段と高めることができ ます。

図2：AMD/XCPオプションを使用して、ECUの内部値に直接アクセスする CANoeテストシステム

03

Technical Article / January 2019

本稿は、2010年6月にドイツで発行されたAutomobil Elektronikに掲載のベクター執筆による記事の和訳を更新したものです。

画像提供元：Vector Informatik

■ 本件に関するお問い合わせ先ベクター・ジャパン株式会社 営業部E-Mail: sales@jp.vector.com

Oliver Falknerドイツのシュトゥットガルト大学にて電気工学を専攻。 同大学卒業後、1999年にベクターに入社。現在はネットワークおよび分散システム製品シリーズのプロダクト マネージャーを務める。