診断ツールとしての CANoe

診断ツールとしての CANoe
Version 1.2
2006/06/06
Application Note AN-JND-1-001
日本語版 Version 1.2J
著者
概要
Asa Forsberg, Thomas R. Schmidt
Public Document
本アプリケーションノートは、CANoe を用いて診断を行うための一般的な入門書となることを意
図しており、CANoe 診断機能セットの基本的な能力や技術的側面を説明しています。このドキ
ュメントは CANoe ヘルプファイルを補完しますが、チュートリアルとしても利用できます。
Table of Contents
1.0
概要 ..................................................................................................................................................................3
1.1
はじめに .........................................................................................................................................................3
1.2
診断コンポーネント..........................................................................................................................................4
1.3
CANoe 5.0 から CAnoe 5.1 への主要な変更点 ..............................................................................................4
1.4
CANoe 5.1 から CAnoe 5.2 への主要な変更点 ..............................................................................................4
2.0
CANoe での診断...............................................................................................................................................6
2.1
OSEK TP サポート .........................................................................................................................................6
2.2
診断詳細ファイル............................................................................................................................................6
2.2.1
トレース Window ..........................................................................................................................................6
2.2.2
診断機能セット .............................................................................................................................................6
2.2.3
CAPL ECU シミュレーション .........................................................................................................................7
2.2.4
CAPL でのテスター シミュレーションとテスト モジュール ................................................................................7
2.2.5
Physical Network Request とネットワーク CDD ...........................................................................................8
2.2.6
診断機能への COM 経由のアクセス.............................................................................................................8
2.2.7
診断オブジェクト、診断パラメータの記号選択ダイアログ................................................................................8
2.3
KWP2000 と UDS..........................................................................................................................................9
3.0
ファーストステップ ..............................................................................................................................................9
3.1
診断データベースファイルの利用 ..................................................................................................................10
3.1.1
CDD ファイルの追加 ..................................................................................................................................10
3.1.2
CDD ファイルの設定 ..................................................................................................................................10
3.2
診断コンソールとフォールト メモリーWindow の利用......................................................................................11
3.2.1
診断要求送信と応答受信 ...........................................................................................................................11
3.2.2
フォールト メモリーの読み込み....................................................................................................................11
3.2.3
Physical network requests ........................................................................................................................11
3.3
診断シミュレーションのための CAPL と CDD の利用 .....................................................................................11
3.3.1
CAPL ブラウザ...........................................................................................................................................11
3.3.2
ECU シミュレーションと非標準テスターに必要な CAPL 関数 .......................................................................11
3.3.3
必要な変数 ................................................................................................................................................12
3.3.4
デバッグ レベル..........................................................................................................................................12
3.3.5
TP 機能を持つシミュレーションモードの作成 ...............................................................................................12
3.3.6
診断ターゲット指定.....................................................................................................................................12
3.3.7
診断要求修飾子.........................................................................................................................................13
3.3.8
診断応答修飾子.........................................................................................................................................13
3.3.9
診断要求の作成.........................................................................................................................................13
3.3.10
診断応答の作成.........................................................................................................................................13
1
Copyright © 2006 - VecScan AB, Vector Informatik
Contact Information: www.vector-japan.co.jp or 03-5769-6970
診断ツールとしての CANoe
3.3.11
3.3.12
3.3.13
3.4
3.4.1
3.4.2
3.4.3
4.0
4.1
4.2
4.3
4.4
4.4.1
4.4.2
4.5
5.0
6.0
7.0
8.0
9.0
パラメータの取り扱い..................................................................................................................................14
タイムアウト処理.........................................................................................................................................15
Negative 応答の取り扱い...........................................................................................................................16
テスト機能セットと診断機能セットを組み合わせる ..........................................................................................16
CANoe シミュレーション ノード (ECU) とテストモジュール (テストノード) の違い ...........................................17
簡単な診断テスター....................................................................................................................................17
XML パターンによる診断テスター ...............................................................................................................18
高度な例 .........................................................................................................................................................19
"Resonse Pending" の ECU シミュレーション................................................................................................19
診断オブジェクトの長さの変更.......................................................................................................................21
診断全体の設定 ...........................................................................................................................................21
障害挿入 ......................................................................................................................................................21
診断要求を不正な長さとする ......................................................................................................................22
トランスポート プロトコル レベルのエラー挿入 .............................................................................................22
CAN-LIN ゲートウェイ シミュレーションを介した LIN ノードへのアクセス .........................................................22
よくある間違い.................................................................................................................................................24
略語 ................................................................................................................................................................26
参考文書.........................................................................................................................................................26
その他のリソース.............................................................................................................................................26
連絡先 ............................................................................................................................................................26
2
Application Note AN-JND-1-001
診断ツールとしての CANoe
1.0 概要
1.1 はじめに
診断は、ＥＣＵを車体などのシステムに組み込む前、または組み込んだ後に、設定やメンテナンス、サポート、制御、機能拡
張を行うために用いられます。診断は通常要求– 応答方式で実行されます: テスター (クライアント) が１つ (または複数) の
ECU に診断要求を送ると、その (またはそれらの) ECU は、要求された情報を含む「Positive 応答メッセージ」を応答として
送信するか、「Negative 応答」を理由とともに送信します。
本アプリケーションノートは、CANoe を用いて診断を行うための一般的な入門書となることを意図しており、CANoe 診断機
能セットの基本的な能力や技術的側面 (「ファースト ステップ」) を述べます。テスト エンジニアが CANoe を用いた診断テ
ストを開始できるような、具体例も含まれています。
このドキュメントは CANoe ヘルプファイルを補完し、診断機能セットの「ファースト ステップ」を学ぶためのチュートリアルと
して利用できます。診断機能セットについてのより詳細な情報は、CANoe ヘルプファイルおよび CANoe デモ アプリケーシ
ョンをご覧ください。両者とも、CANoe を標準インストールした際利用できます。
Note:
このドキュメントで説明されている機能は CANoe(/CANalyzer) version 5.2 のものです。古い version 向け
アプリケーションノートの入手については、ベクター社サポート (9.0節参照） にお問い合わせください。
3
Application Note AN-JND-1-001
診断ツールとしての CANoe
1.2 診断コンポーネント
以下の表で、CANoe 診断機能関連の機能コンポーネントと、その使用開始法および更なる情報の入手先を記述します。
コンポーネント
OSEK TP DLL
説明
CANoe シミュレーション ノード
用 ISO TP の実装
ISO TP オブザー
バ
ISO TP にて使用される CAN メ
ッセージのＴＰ情報の表示
KWP 2000 インタ
ープリタ
通信データを KWP 2000 に基
づき解釈するための、ISO TP
オブザーバ拡張機能
通信データを CDD に基づき解
釈するための、ISO TP オブザ
ーバ拡張機能
診断インタープリ
タ
診断コンソール
CDD にて定義された診断要求
の直接送信、応答の表示
フォールト メモリ
ーWindow
ECU のフォールト メモリーへの
直接アクセス
診断用 CAPL 拡
張機能
CDD にて定義された診断オブ
ジェクトへアクセスするための特
別な CAPL 関数
K-Line DLL
ECU に K-Line (Ser2K) を用い
てアクセスするための CAPL
DLL
使用開始法
データベース:
“NodeLayerModules”,
シミュレーション設定 Window:
ノードの[設定] 右クリックメニュ
ー選択後[モジュール] を選択
[設定] メニューから [診断/ISO
TP 設定...], [ISO TP オブザー
バ] を選択
上記 ISO TP オブザーバ設定
画面にて、 [KWP2000 により
解釈] チェックボックスをオン
[設定] メニューから [診断/ISO
TP 設定...], [診断設定] を選択
(CDD を割り当て)
[設定] メニューから [診断/ISO
TP 設定...], [診断設定] を選択
(CDD をバスまたはノードに割
り当て)
[設定] メニューから [診断/ISO
TP 設定...], [診断設定] を選択
(CDD をバスまたはノードに割
り当て)
(CAPL プログラムから利用可
能な) CDD のロード
CAPL DLL としてアクティベー
ト
更なる情報の入手先
CANoe インストールディレクトリ
の下の Doc\osek_tp_e.pdf
CANoe ヘルプの [CANoe] [診断] - [Diagnostics/ISO TP コ
ンフィギュレーション] - [標準]
CANoe ヘルプの [CANoe] [診断] - [Diagnostics/ISO TP コ
ンフィギュレーション] - [標準]
CANoe ヘルプの [CANoe] [診断] - [Diagnostics/ISO TP コ
ンフィギュレーション] - [診断詳
細]
CANoe ヘルプの [CANoe] [診断] - [診断コンソール: 概要]
CANoe ヘルプの [CANoe] [診断] - [フォールト メモリー コン
ソール: 概要]
CANoe ヘルプの[CAPL ブラウ
ザ] - [関数] - [特別な関数: 診
断] - [診断: 拡張された CAPL
の関数]
CANoe インストールディレクトリ
の下の
Doc/KLineCAPL_Manual.pdf
1.3 CANoe 5.0 から CAnoe 5.1 への主要な変更点
•
•
•
•
KWP2000.DLL の使用はもはや推奨しません。「標準 CDD」と CDD メカニズムを使用したほうが、より容易で柔
軟性に富むためです。 (2.3節)
ECU との通信に VW TP 2.0 を利用することが可能となりました。詳しくは VAG Addon パッケージに含まれる
"DiagnosticsInCANode.pdf"をご覧ください。
CAPL でテスターを実装する際、もしその CAPL で TP レベルのふるまいに影響をおよぼす必要が無い場合、
CAPL コールバック インターフェイスを実装しなくとも良くなりました。そのかわり、診断コンソールとフォールト メモ
リー Window 用の通信メカニズムが利用できます。 (3.3.2節)
CAPL ブラウザのコンテキスト メニューから、診断オブジェクトとパラメータ修飾子用の記号選択ダイアログを利用
できるようになりました。(2.2.7節)
1.4 CANoe 5.1 から CAnoe 5.2 への主要な変更点
•
CAPL コールバック インターフェイスが書き直され、3 つの関数だけでプロトコルに関する全設定をとりあつかうこ
とが可能になりました。詳細は、サンプル コードを参照ください。 (3.3.2節)
4
Application Note AN-JND-1-001
診断ツールとしての CANoe
•
•
•
•
•
•
•
診断機能が、オートメーション (COM) インターフェイスからアクセス可能になりました。 （詳しくはヘルプを参照くだ
さい。）
単純な診断テストを、XML パターンを用いて実装可能になりました。(3.4.3節)
診断コンソールとフォールト メモリー Window から、physical network requests を送信できるようになりました。
(2.2.5節)
診断用のグローバルなオプション ダイアログが追加されました。 (詳しくはヘルプを参照ください)
診断パラメータがデータ、グラフィックの各 Window に表示できるようになりました。 （詳しくはヘルプの「診断パラ
メータ」トピックをご覧ください。）
LIN ノードへのアクセスが可能となりました。 (詳しくはヘルプおよび本ドキュメント4.5節をご覧ください。)
(診断イベントを含む) TP レベル イベントを、測定設定 Window 上で処理、フィルタ可能になりました。 (詳しくは、
ヘルプを「CallbackTPDataIndication」で検索しご確認ください。(大文字、小文字を正確に入力して検索くださ
い。) )
5
Application Note AN-JND-1-001
診断ツールとしての CANoe
2.0 CANoe での診断
CANoe は、ECU 開発における診断実行に関わる全てのステップで利用することが出来ます:
•
•
•
•
•
•
診断機能の設計 (システム シミュレーション)
ECU での診断機能の実装 (残りのバスのシミュレーション＝バス上の通信相手のシミュレーション)
Æ OSEK TP DLL と、(標準) CDD を使用した診断用 CAPL 拡張機能とを利用
仕様テスト、統合テスト、回帰テスト
Æ (標準) CDD を利用した診断用 CAPL 拡張機能と CANoe テスト機能とを利用。TP への障害挿入をおこないた
い場合のみ、OSEK TP DLL が必要。
実 ECU 通信の解析
Æ ISO TP オブザーバ、KWP2000 インタープリタ、CDD を使用した診断インタープリタのいずれかを利用
(CANoe に統合された) 診断テスター機能による ECU の診断
Æ 診断コンソールを利用
エラー検索
Æ フォールト メモリーWindow を利用
2.1 OSEK TP サポート
CANoe は OSEK TP オブザーバにより、OSEK トランスポート プロトコル ISO/TF2 に従って CAN バスで送信されたメッセ
ージを解釈し、トレース Window に結果を表示します。また CANoe にはトランスポート プロトコルの実装も含まれており、
これにより診断オブジェクトを容易に送受信できます。この実装は、CANoe 標準インストールに含まれるノード レイヤー
DLL で実現されています。これにより、トランスポート レイヤー特有の機能であるセグメンテーション、フロー コントロールな
どの処理がおこなわれます。
トランスポート レイヤーの解釈を有効にするには、ISO TP オブザーバをアクティベートします。オブザーバのアクティベート
法は、CANoe のヘルプファイルを参照してください。
シミュレーション ノードの TP 機能を有効にする方法は、3.3.5 節をご覧下さい。
2.2 診断詳細ファイル
CANdela 診断詳細(CDD)ファイルは診断データのためのデータベースで、CAN メッセージやシグナルのための DBC ファ
イルと似た役割を持ちます。CDD ファイルは CANdelaStudio により作成され、CANoe や CANalyzer で診断サービスや
診断パラメータを記号でアクセス、解釈するために利用できます。
Note 1:
CANalyzer は解釈機能しか持ちません。
Note 2:
以下で述べる機能は、CDD ファイルを CANoe コンフィギュレーションに含んだときだけ利用できます。
2.2.1
トレース Window
CDD ファイルにより、診断サービス (診断要求/応答) とパラメータを記号を用いてトレースすることができます。診断要求/
応答を、(バス メッセージのシグナルを展開表示するのと同じ要領で) 展開表示することもできます。
2.2.2
診断機能セット
ベクター製品の診断機能セットには、ECU 診断機能の開発、テスト、利用や、診断を通じた ECU のテストのために必要な
機能が含まれています。
診断機能セットに含まれる診断コンソールでは、CANdela Studio の診断詳細ファイル (*.CDD) に基づいて、全ての診断
サービスにインタラクティブにアクセスできます。ここでは診断要求の選択、パラメータ設定が可能です。また診断要求を、
対応する応答とともに表示することも可能です。
フォールト メモリーWindow を使用すると、ECU のフォールト メモリーにすばやく簡単にアクセスできます。
6
Application Note AN-JND-1-001
診断ツールとしての CANoe
診断機能セットは CANoe 以外のベクター製品、CANape MC+D と CANdito にも含まれています。これら製品でも
CANoe 同様、開発プロセス全体がサポートされます。
診断コンソール
診断コンソールが CDD ファイルから情報を取り出し表示するので、ユーザーは診断要求の選択、そのパラメータの設定、
診断要求の送信を簡単に行うことが出来ます。応答はパラメータとともに、診断要求と同じ形式で表示されます。
図 1: 診断コンソール
フォールト メモリーWindow
フォールト メモリーWindow の[更新]ボタンを押すことにより、ECU のフォールト メモリー リストを読み込むことが出来ます。
CANoe 5.0 では、フォールト メモリーWindow の利用不可はカーOEM に依存していました。CANoe 5.1 から、KWP/UDS
標準ＣＤＤを利用して ECU のフォールト メモリーにアクセスできるようになりました。また ECU に送信する要求を、バイト列
で定義することができるようになりました。(フォールト メモリーWindow の画面は、2.2.5節を参照下さい。)
2.2.3
CAPL ECU シミュレーション
実 ECU が存在しないとき、ECU をシミュレートするため CAPL を使用できます。CANdela 診断詳細ファイルにて定義され
た記号名を用いて CAPL から診断サービスや診断データにアクセスするために、CAPL の診断コマンドが利用できます。こ
のシミュレーション ECU は、テスター (実際のテスターもしくは CANoe でシミュレーションしたテスター) からの診断要求を、
イベント プロシージャにて受け取り、適切な処理を行います。
2.2.4
CAPL でのテスター シミュレーションとテスト モジュール
CANoe を使って、ユーザーが GUI (パネル) 経由で ECU にアクセスできるインタラクティブなテスターを作成することがで
きます。これに加え、ユーザーからの操作無しに自動実行するテストを作成し、一連の診断要求と応答処理を実行すること
も可能です。このようなテストの結果を、(XML/HTML フォーマットの) レポートファイルに書き込むことも出来ます。
一般的なテストであれば、XML テスト仕様記述により (CAPL プログラミングをせずに) 作成することも可能です。
7
Application Note AN-JND-1-001
診断ツールとしての CANoe
2.2.5
Physical Network Request とネットワーク CDD
CANoe 5.1 から、CAN バスに対し１つの CDD を「ネットワーク CDD」として割り当てることができるようになりました。これ
により、そのバス上の全ての ECU が、その CDD 記述を共通のサブセットとして実装していることを示せます。このネットワ
ーク CDD を、CAPL プログラムのターゲットとして選択することが可能です。この場合 診断要求が送信されると、それは全
ての ECU に物理的に (physically) 送信されます。それら ECU からの応答は、テスターが個々に処理します。
CANoe 5.2 では、ネットワーク CDD 用の診断コンソールとフォールト メモリーWindow を開くことが出来るようになりました。
これは、CAN バス上の全ての ECU に診断要求を送るための簡単なインターフェイスとして利用できます。応答はコンソー
ルのトレース Window に表示され、DTC はその ECU 名とともに、フォールト メモリーWindow に表示されます。この後
DTC を個別に削除することも出来ますし、フォールト メモリーすべてのボタンを 1 回押すだけで削除することもできます。
図 2: フォールト メモリーWindow
2.2.6
診断機能への COM 経由のアクセス
CANoe 5.2 にて COM サーバーに追加されたインターフェイスにより、Visual Basic や VisualBasicScript などで記述され
た外部アプリケーションから、CANoe の診断機能にアクセスできるようになりました。これは、(例えば OEM 固有プロセス
に依存するような) 複雑な処理を簡単に実装するための手段となりえます。
2.2.7
診断オブジェクト、診断パラメータの記号選択ダイアログ
CDD で定義されたパラメータと診断オブジェクトを、CAPL エディタのコンテキストメニューから挿入できます。これは、診断
要求、応答、パラメータなどの診断修飾子を簡単に指定するための機能です。右マウスボタンを押し、 [CANdela からの診
断オブジェクト] または [CANdela からの診断パラメータ...] を選択すると、割り当てられた CDD のツリービューが表示され
ます。ここでサービスかパラメータを選択しダブルクリックする (または OK ボタンを押す) と、CAPL プログラムの現在のカ
ーソル位置に、オブジェクトまたはパラメータの修飾子パスが挿入されます。
8
Application Note AN-JND-1-001
診断ツールとしての CANoe
図 3: CAPL ブラウザでの診断オブジェクト、診断パラメータ用記号選択ダイアログ
CDD の内容は、 (図 3 の左図のようにクラス、インスタンス、サービスの順で) 階層表示できますし、また (図 3 の右図のよ
うに） アルファベット順のフラットな表示もできます。このダイアログは、データ Window やグラフィック Window に表示する
診断パラメータを選択する際にも利用します。
2.3 KWP2000 と UDS
Keyword Protocol 2000 (KWP2000, ISO 14230) と Unified Diagnostic Services (UDS, ISO 14229) は、多くの OEM
が使用する標準診断プロトコルです。ただしほとんどの OEM は、標準とは異なる診断仕様を使用していることにも注意し
てください。
CANoe 5.1 からは、これらプロトコルをサポートするための新しいアプローチをとるようになりました。これらを DLL としてコ
ーディングする替わりに、これら標準のレベルで診断を記述するための 2 つの「標準 CDD」が提供されるようになりました。
このアプローチには、以下のような利点があります:
•
個別 CDD 用に実装されている全てのメカニズムが、標準 CDD にも適用できます。ただし後者には、パラメータ定
義を個別 CDD ほど精密にできないなどの制限事項はあります。
• 通信パラメータを設定ダイアログから指定できます。以前のように、これらパラメータをデータベースに入力したり、
CAPL プログラムコードで指定したりする必要はなくなりました。
• 診断コンソールやフォールト メモリーWindow が利用可能となり、ECU へ簡単にアクセス可能となります。
• 送信データの解釈を、CDD でもパラメータ化することができます。
KWP2000 の解釈には、CDD、DLL とも必要ありません。 (が、標準 CDD を設定することを推奨します。) もし CAN データ
ベースから TP レベルの設定が読み込めるなら、 [ISO TP オブザーバ] 設定タブにて [KWP2000 により解釈] チェックボッ
クスをオンにするだけで、KWP2000 の解釈が出来ます。
このプロトコルサポートについてのさらなる詳細は、CANoe のヘルプをご覧下さい。標準 CDD [2] を CANoe に付属する
CANdela Studio Viewer アプリケーションで開くことで、標準定義を見ることも出来ます。
3.0 ファーストステップ
CANoe 診断機能は、バスの診断通信のトレースに利用できるほか、 (診断コンソールや CAPL を用いて) 診断テスターと
しても利用できます。さらに、ECU 診断サービスのシミュレーションのための機能も提供します。
9
Application Note AN-JND-1-001
診断ツールとしての CANoe
これらの使用例全てにおいて、CDD ファイル (診断データベース) が必要です。また、データ送信のために OSEK TP DLL
(または他の TP の実装) が必要となる場合もあります。
3.1 診断データベースファイルの利用
3.1.1
CDD ファイルの追加
CDD ファイルは、ベクター製品 CANdelaStudio により作成され診断データ (サービス、パラメータ) を記述する、診断デー
タベースです。
CDD ファイルは、CANoe の [設定] - [診断/ISO TP 設定] メニューから CANoe コンフィギュレーションに追加できます。
(CANoe 5.1 以降では) KWP、UDS 標準用に、ここに「標準 CDD」を追加できることにもご注意下さい。 [2]
CANoe コンフィギュレーションに CDD ファイルを追加すると、CAPL ブラウザに、Diagnostics request と Diagnostics
response という２つのイベント カテゴリが追加されます。
CANoe を診断通信している実際の自動車に接続している場合、上記設定により、トレース Window での記号による解釈
が可能になります。
CANoe コンフィギュレーションに CDD ファイルを追加すると、診断コンソールとフォールト メモリーWindow も現れます。こ
れらにより、診断要求の送信、応答の受信、パラメータの確認、(診断コンソールからの) サービスの選択が可能となります。
3.1.2
CDD ファイルの設定
[設定] - [診断/ISO TP 設定] メニューの選択により現れるダイアログにて CDD ファイルを選択し [設定] ボタンを押すと、
CDD の設定を変更することができます。
ECU シミュレーション (CAPL) を行う必要がある場合、CDD ファイルを、ファイル自身が記述している ECU に割り当てる
必要があります。ECU シミュレーションの必要が無く、診断コンソール/フォールト メモリーWindow のみが必要な場合、
CDD をデータ送信を行うバスに割り当てる必要があります。TP データの解釈のみが必要な場合、CDD を「 (解釈のみ) 」
に割り当てることができます。
CAN バスでは、バス毎に１つの CDD を「ネットワーク CDD」として割り当てることが出来ます。これは「<バス名>::*」という
エントリ (例：「CAN::*」) への割り当てにより実現でき、このバスに接続する全ての ECU が CDD の内容を共通のサブセッ
トとして実装していることを表します。この設定後、診断コンソールとフォールト メモリーWindow から、バス上の全 ECU に
対し「physical network request」として診断要求を送信することができるようになります。
この設定ダイアログでは、診断コンソールに表示されるサービス セットも決定できます。例えば「Common」バリアントが選
択された場合、ユーザーは他のバリアントにのみ存在するサービスを利用することができません。この設定ダイアログに対
するさらなる詳細は、オンライン ヘルプをご覧下さい。
このダイアログの「インターフェイス」コンボボックスでは、利用可能な TP パラメータを選択できます:
•
•
•
•
「インターフェイス」コンボボックスは、CDD 中に定義されたインターフェイスを表示します。各インターフェイスでは、
ISO TP アドレス指定モードと、アドレス パラメータのデフォルト値を定義しています。インターフェイスのアドレス指
定モードを変更できないことに注意してください。そのかわり、別のインターフェイスを選択してください。
ネットワーク CDD には、TP パラメータを設定してはいけません。個々の ECU の TP パラメータが使用されるべき
だからです。
「VAG Addon パッケージ」 (version 1.10 以降) がインストールされている場合、"VWTP 2.0 (CANoe)"というインタ
ーフェイスを選択できます。 この選択後、ダイアログの２つめのタブで正しい TP パラメータを入力する必要があり
ます。
LIN データベースからのノードを選択した場合、データベースにノード アドレスも定義されているため、TP パラメー
タを追加設定する必要はありません。
10
Application Note AN-JND-1-001
診断ツールとしての CANoe
3.2 診断コンソールとフォールト メモリーWindow の利用
3.2.1
診断要求送信と応答受信
CANoe コンフィギュレーションに CDD ファイルを追加し "OK" ボタンを押すと、その CDD の診断コンソールとフォールト メ
モリーWindow が自動的に現れます。診断コンソールのエクスプローラ ライクなツリービューから、診断要求を簡単に選択
し送信することができます。診断要求のパラメータの値も、ドロップダウン メニューからの選択や直接書き込みにより簡単に
設定できます。 (後者は、例えば ECU のシリアル ナンバーを指定する際便利です。)診断要求に対する応答も、診断コンソ
ールにて表示できます。
診断機能を実装した実 ECU が無い場合、CANoe のシミュレーション ノードを作成し、CAPL 診断機能を用いた適切な実
装を行う必要があります。 (3.3.5 節をご覧下さい。)
3.2.2
フォールト メモリーの読み込み
ECU のフォールト メモリーの内容を、フォールト メモリーWindow に簡単に読み込むことができます。DTC の読み込みに
は現在、KWP2000 標準での診断要求 ($18 02) が使用されますが、CDD に定義された OEM 固有方式が (修飾子によ
り) 正しく認識された場合は、そこで定義されたサービスが使用されます。また、ここで使用する診断要求を明示的に定義
することも可能です。
3.2.3
Physical network requests
CANoe 5.2 では、診断コンソールとフォールト メモリーWindow から CAN バス上に定義された全 ECU に対し physical
request を送信することが可能です。CDD が「ネットワーク CDD」として設定されていれば、つまり設定ダイアログで「<バス
名>::*」に割り当てられていれば、その CDD 用の診断コンソールとフォールト メモリーWindow が開きます。
3.3 診断シミュレーションのための CAPL と CDD の利用
3.3.1
CAPL ブラウザ
CDD ファイルを CANoe コンフィギュレーションに追加すると、CAPL ブラウザに Diagnostics request と Diagnostics
response という２つのイベント カテゴリが現れます。ここで個別の診断要求、応答を指定するためには、CDD ファイルに記
述された修飾子パスを使用します。
例:
diagRequest START_SESSION::DEFAULT_SESSION::StartSession request;
このコード断片では、デフォルト診断セッションを開始する診断要求の修飾子パスを用いて変数を初期化しています。
3.3.2
ECU シミュレーションと非標準テスターに必要な CAPL 関数
CANoe 5.1 以降、テスターノードから診断制御用標準通信チャンネルを利用できるようになりました。このため、テスター ノ
ード/モジュールがトランスポート レイヤーに直接アクセスしなくて良い場合、CAPL コールバック インターフェイスを実装す
る必要はありません。
また CAPL から、CAN フレーム１フレーム分を超えるサイズの診断オブジェクトを利用することも可能です。例えば 24 デー
タ バイトの診断応答を１つの診断オブジェクトとして扱うことができます。これは、CANoe 標準付属のビルト イン トランスポ
ート プロトコルを利用することで可能となります。 (さらなる詳細は、 [1] を参照下さい。)
CAPL で ECU や診断テスターをシミュレーションする場合、CANoe 診断レイヤーがトランスポート レイヤーへ正しくアクセ
スするために、特定のコールバック関数を実装する必要があります。
ISO/OSEK TP DLL で必要とされるコールバック関数は以下の通りです (この DLL が実装するトランスポート レイヤーが、
[1] で説明されているように診断レイヤーにイベント通知するため、これらコールバック関数を使用します):
OSEKTL_DataInd()
// 受信されたデータバイト数を返す
11
Application Note AN-JND-1-001
診断ツールとしての CANoe
OSEKTL_ErrorInd()
// トランスポート レイヤーからのエラー メッセージ
OSEKTL_DataCon()
// 送信成功したデータバイト数を返す
以下関数は、トランスポート プロトコル設定とデータ処理のために CANoe が自動的に呼び出します (診断レイヤーがこれ
ら CAPL を呼び、そこからトランスポート レイヤーが呼ばれます):
_Diag_DataRequest()
// 診断要求をおこなう
_Diag_SetChannelParameters() // CAPL ノードに TP レイヤー設定をおこなわせる
_Diag_SetupChannelReq()
Notes:
// テスターのみ: テスターは ECU の「チャンネル」をオープンしなければならない
もはや利用を推奨しない OSEK TP 固有コールバック インターフェイスもあります (_OSEKTL_... で始ま
る関数)
TP レイヤー パラメータ値は、DiagGetCommParameter() 関数で取得することが出来
ます。
利用する CANoe コンフィギュレーションにこれらの関数を含めるには、以下の２つの方法があります:
•
•
3.3.3
ヘルプファイルからサンプル CAPL をコピーする (英語版ヘルプ CANoe Help の検索タブから "reference
implementation" を検索してください)
"KWPSim" デモを開いてください。 (これは CANoe 通常インストール時にインストールされます。) シミュレーショ
ン 設 定 に て OSEK_TP と 表 示 さ れ て い る ノ ー ド を 開 き 、 必 要 な CAPL 関 数 を コ ピ ー す る か 、
Demo_CAN_CN\Diagnostics\KWPSim\Nodes\ecu.can ファイルをコピー (必要に応じリネーム) し、不要なコー
ドを削除してください。
必要な変数
トランスポート レイヤー インターフェイスのサンプル実装の中の CAPL では、グローバル変数 gECU を使用しています。ト
ランスポート レイヤー インターフェイス関数使用時、この変数は関数が実行するノードを指し示すため用いられます。この
ため、この変数をグローバル変数ペイン (variables 欄) で定義し、適切な値とする必要があります。
例:
a) char gECU[10] = "ECU";
b) char gECU[15] = "Tester node";
3.3.4
デバッグ レベル
OSEK 関数のデバッグレベルは、setWriteDbgLevel() 関数のパラメータにより設定できます。デバッグレベルを冗長
(verbose) とするには、setWriteDbgLevel(1) を呼び、サイレント (quiet) とするには setWriteDbgLevel(0) を呼んでくださ
い。
3.3.5
TP 機能を持つシミュレーションモードの作成
シミュレーション設定 Window にてノードを作成し、OSEK_TP.DLL を割り当ててください。割当ては DBC ファイルの
"NodeLayerModules" 属性値設定か、シミュレーション設定 Window でのノード設定によりおこなえます。シミュレーション
設定 Window にてノードを選択し、マウスボタンを右クリックしてコンテキスト メニューを表示してください。[設定] を選択し、
[モジュール] タブを選択してください。そこで OSEK_TP.DLL を追加してください。 (DLL は CANoe インストールディレクト
リの exec32 ディレクトリ以下にあります。)
3.3.6
診断ターゲット指定
CANoe で診断テスターをシミュレーションし、特定の (シミュレーションまたは実) ECU に診断要求を出しその応答を受信
する必要がある場合、テスターとなるノードの CAPL コードにて、ターゲットＥＣＵの名前を指定する必要があります。通常、
ターゲットは CAPL ブラウザの System/Start エントリにて指定しますが、後に変更することも出来ます。
例:
12
Application Note AN-JND-1-001
診断ツールとしての CANoe
on start
{
if( 0 != DiagSetTarget( "ECU")) write ( “Error setting target!");
}
文字列 "ECU" は、CDD に含まれる ECU 名に変更する必要があります。
3.3.7
診断要求修飾子
(シミュレーション ECU などに) 特定の診断要求のイベント プロシージャを追加する場合、CAPL ブラウザの左側タブで
Diagnostic request エントリを右クリックし [新規] を選択してください。すると以下のコードが作成されます:
on diagRequest <newRequest>
{
}
診断要求修飾子の入力には、診断記号選択ダイアログ (2.2.7節) を利用してください。
例:
on diagRequest START_SESSION::DEFAULT_SESSION::StartSession
{
}
3.3.8
診断応答修飾子
(テスターのシミュレーションなどのために) 特定の診断応答のイベント プロシージャを追加する場合、CAPL ブラウザの左
側タブで Diagnostic response エントリを右クリックし [新規] を選択してください。すると以下のコードが作成されます:
on diagResponse <newResponse>
{
}
診断要求修飾子の入力には、診断記号選択ダイアログ (2.2.7節) を利用してください。
3.3.9
診断要求の作成
(診断テスターなどから) 送信される診断要求を作成するために、CAPL 関数を利用できます。
例:
StartSession()
{
diagRequest START_SESSION::DEFAULT_SESSION::StartSession req;
// 診断要求を複合オブジェクトとして送信 (セグメント処理は TP が行う)
DiagSendRequest ( req );
}
3.3.10 診断応答の作成
この節の内容は、ECU シミュレーションにのみ適用できます。
通常、診断応答は "diagRequest" イベントの受け取り時（特定の診断要求の受信時）に送信されます。キーワード "this"
を使うことで、応答オブジェクトに要求オブジェクトの (修飾子を参照しその) 内容を反映させられます。診断応答が、１つま
13
Application Note AN-JND-1-001
診断ツールとしての CANoe
たは複数の CAN メッセージとしてではなく、1 つのオブジェクトとして扱われることに注意してください。TP 機能により、仮に
応答内容が CAN の 1 フレームに収まらない場合でも、診断応答を 1 つの関数呼び出しだけで送信できます。
例:
on diagRequest START_SESSION::DEFAULT_SESSION::StartSession
{
// この診断要求への応答を作成
diagResponse this resp;
// 応答を送信
DiagSendResponse( resp);
}
3.3.11 パラメータの取り扱い
CDD ファイルの記述をもとに、パラメータに記号でアクセス (読み書き) することができます。診断パラメータは、単純パラメ
ータと複合パラメータという、２つのグループに分けられます。２つのグループは、それぞれ対応する Set- 関数 Get- 関数
を持ちます。単純パラメータは、診断オブジェクト中でのオフセットが固定されているものをさします。複合パラメータは、コン
テナ パラメータに含まれているためオフセットが可変であるものをさします。(例: DTC / Diagnostic Trouble Code のリスト)
以下は単純パラメータの取り扱い例で、CDD ファイルに定義された "Voltage Terminal 15" (空白があることに注意!) とい
う名の単純パラメータに関するものです。こうした名前は使用言語に依存するため、CAPL では "Voltage_Terminal_15"
などの修飾子を使用します。 (修飾子は 2.2.7 節の記号選択ダイアログから選択できます。）
単純パラメータの例:
on diagRequest DEVICE_CONTROL::InputOutput::Set
{
diagResponse this resp;
// 応答の単純パラメータを 0 に設定
DiagSetParameter ( resp, "Voltage_Terminal_15", 0 );
DiagSetParameter ( resp, "Interior_Temperature", 0 );
DiagSendResponse ( resp );
}
以下は複合パラメータの取り扱い例で、DTC のリストに関するものです。この例が想定する CDD ファイルでは、DTC とそ
のステータス マスクが "List of DTC" リストとしてグループ化されています。
最初に、DTC を表すためのメモリ領域が必要となります。まず iteration counter 値 0 (ゼロ) の応答オブジェクトが作成さ
れますが、これは後に続く DTC がないことを表しています。次に、応答として返される DTC の数が iteration counter に設
定され、応答オブジェクトが拡大されます。なお CANoe 5.2 では、必要な領域が自動的に確保されるため、オブジェクトの
拡大、リサイズの必要はありません。
iteration counter が指定されていない場合もあることに注意してください。このような場合、後に続く DTC の数は実際の応
答の長さ、つまり全体のバイト長により決定され、これをもとにリサイズを行う必要があります。
必要なメモリの確保後、DTC はステップ バイ ステップで初期化されます。つまりシミュレーション ECU がテスターに報告し
たい DTC の値を 1 つ 1 つ設定していきます。
複合パラメータの例:
on diagRequest FAULT_MEMORY::FAULT_MEMORY::ReadAll
{
diagResponse this resp;
// 応答として返される DTC の数を設定
14
Application Note AN-JND-1-001
診断ツールとしての CANoe
DiagSetParameter( resp, “NUMBER_OF_DTC”, 2);
// DTC を保持するメモリ領域を確保
DiagResize( resp);
// CANoe 5.2 では不要 !
// 応答の複合パラメータを設定
// 最初の DTC に 16 進値を設定
DiagSetComplexParameter ( resp, "List_of_DTC", 0, "DTC", 0xFAFAF );
// DTC のステータス マスクを true に設定
DiagSetComplexParameter ( resp, "List_of_DTC", 0,
"DtcStatusDataType.ConfirmedDTC", 1 );
// 次の DTC を設定
DiagSetComplexParameter ( resp, "List_of_DTC", 1, "DTC", 0xCFCFC );
DiagSetComplexParameter ( resp, "List_of_DTC", 1,
"DtcStatusDataType.ConfirmedDTC", 1 );
…
DiagSendResponse ( resp );
}
以下は、CDD ファイルに "NUMBER_OF_DTC" パラメータが定義されていない場合の、応答オブジェクトのサイズ設定法
例です。この場合、必要なデータバイトを数え、その値を直接指定する必要があります。
複合パラメータの例 ２:
on diagRequest FAULT_MEMORY::FAULT_MEMORY::ReadAll
{
diagResponse this resp;
// 応答として返される DTC の数を設定
DiagResize( resp, 9)
// この例では、応答を送るのに 9 バイト必要
DiagSetComplexParameter ( resp, "List_of_DTC", 0, "DTC", 0xFAFAF );
…
}
3.3.12 タイムアウト処理
診断要求のタイムアウトは、CANoe 5.0 SP3 から加わった TestWaitForDiagResponse() 関数の戻り値により、自動的に
認識することができます。この SP から、この関数の利用法をデモする KWPSim デモ コンフィギュレーションの拡張版が付
属しています。
例:
TestWaitForDiagResponse( req, 5000 ); // 診断要求への応答を 5 秒待つ
15
Application Note AN-JND-1-001
診断ツールとしての CANoe
3.3.13 Negative 応答の取り扱い
ECU が診断要求に応じられないような場合などは、Negative 応答がかえってきます。この節では、このような状況の実装
法を説明します。
一般に診断要求のサービスは明確に定義できますが、応答へのサービス (特に Negative 応答へのサービス) は明確化で
きません。Negative 応答のあいまいさに対処するため、 "all-handler" の利用を推奨します。
例:
on diagResponse *
{
// Negative 応答のあいまいさに対処するため、応答全体を "*" で表現
if( DiagIsNegativeResponse ( this ) )
{
write( "Received negative response for service 0x%x, code 0x%x",
(long) DiagGetParameter( this, "SIDRQ_NR" ),
(long) DiagGetParameter( this, "NRC" ) );
}
}
Negative 応答の特殊例として、「忙しいので、後で応答する」ということを示すコードによる応答が考えられます。これは、
(おそらく) 診断要求に対する Positive 応答が後に帰ってくることを意味します。この特殊な Negative 応答をシミュレーショ
ン ECU で実装するために、タイマーを用いることを推奨します。シミュレーション ECU は最初に Negative 応答を送信し、
次にタイマーをスタートし、タイマー終了後 Positive 応答を送信します。
例:
on diagRequest FaultMemory::FaultMemory::ReportByStatusMask
{
// コード 0x78 の Negative 応答 (requestCorrectlyReceived-ResponsePending) を送信
DiagSendNegativeResponse(this, 0x78);
// Positive 応答をかえす時間までのタイマーをセット
setTimer(posReq, 1);
// 1 秒後 Positive 応答を返す
}
3.4 テスト機能セットと診断機能セットを組み合わせる
本ドキュメントでは、テスト機能セットの詳細説明はしません。テスト機能セットの詳細については、CANoe ヘルプをご覧下
さい。
通常の診断シーケンスでは、診断要求を送信し応答を待った後、次の要求を送信します。
テスター
ECU
診断要求送信
…
応答待ち
診断要求受信
要求処理
…
要求に応答
応答受信
16
Application Note AN-JND-1-001
診断ツールとしての CANoe
テスト機能セットと診断機能セットを組み合わせることで、診断テスターを表現するために、通常の CANoe シミュレーション
ノード (ECU) のかわりにテストモジュールを利用することが出来ます。テストモジュールから
TestWaitforDiagnosticResponse() などのテスト関数を利用することで、診断要求/応答フローを簡単に取り扱うことができ
ます。
3.4.1
CANoe シミュレーション ノード (ECU) とテストモジュール (テストノード) の違い
テストモジュール (テストノード) では通常の CANoe シミュレーション ノード (ECU) と違い、CAPL コードを Start セクション
ではなく TestControl/MainTest() セクションに記述する必要があります。 (テストモジュールには、Start セクションがありま
せん。)
例:
void MainTest()
{
DiagSetTarget( "ECU_name");
}
3.4.2
簡単な診断テスター
以下の例では Testcase セクションに tc_StartSession() テストケースを作成し、それを MainTest() から呼び出しています。
tc_StartSession() では、診断要求を作成しタイムアウトとなるまで応答を待っています。
診断テスターの例:
void MainTest ()
{
DiagSetTarget ( "Brake_Module" );
tc_StartSession ();
}
testcase tc_StartSession ()
{
// 修飾子を用いて診断要求を作成
diagRequest START_SESSION::DEFAULT_SESSION::StartSession req;
// 診断要求を送信
DiagSendRequest ( req );
// 応答を 5 秒間待ち、その内容を評価する
// テスト機能セット関数の戻り値は、ヘルプファイルに説明有り
if( 1 != TestWaitForDiagResponse ( req, 5000) )
{
// 応答が受信されなかった場合
TestStepFail( "Start Default Session", "No response received!");
} else
{
// ここで応答データの評価を行う
}
17
Application Note AN-JND-1-001
診断ツールとしての CANoe
}
診断テスターへの応答を行うための、別のノードも作成する必要があります。例えば Brake_Module というシミュレーション
ECU を作成し、そこに以下のようなコードを定義します。
シミュレーション ECU の例:
on diagRequest START_SESSION::DEFAULT_SESSION::StartSession
{
// この診断要求に対する応答を作成
diagResponse this resp;
// 応答を送信
DiagSendResponse( resp);
}
3.4.3
XML パターンによる診断テスター
一般的なテスト シーケンスであれば、CAPL テスター モジュールを書く必要はありません。そのかわりに XML テスト仕様
記述を利用した、テスト記述、テスト実行が可能です。テスト レポートも、自動的に作成されます。 (XML フォーマットで作成
され、HTML フォーマットに変換されます。) XML テスト仕様記述について詳しくは、ヘルプファイルの関連セクションをご覧
下さい。 (日本語版ヘルプの [CANoe] - [テスト] - [テスト機能セット] - [テスト モジュールの構造] にて、[XML テスト モジュ
ール: 構造]をクリック)
以下のテストケース例では、診断要求を指定された ECU に送信し、応答パラメータが期待値と合うかをチェックしています。
<testcase ident="Sample" title="Sample Diagnostics tests - EQ/NE">
<description>
This is a sample diagnostics XML test pattern.
</description>
<diagservicecheck timeout="2s" ecu="KWPSim"
class="IDENTIFICATION" instance="ECU_Identification" service="Read"
result="positive" title="Read Identification">
<diagvalue qualifier="Diagnostic_Identification">
<eq> 0x01 </eq>
</diagvalue>
</diagservicecheck>
<diagservicecheck timeout="2s" ecu="KWPSim"
class="IDENTIFICATION" instance="ECU_Identification" service="Read"
result="positive" title="Read Identification">
<diagvalue qualifier="Diagnostic_Identification">
<ne> 0x01 </ne>
</diagvalue>
</diagservicecheck>
18
Application Note AN-JND-1-001
診断ツールとしての CANoe
</testcase>
これら２つのチェックは互いに矛盾するため、どちらかひとつのチェックは、必ず失敗します。テスト結果は、以下のレポート
出力にあらわれています:
1.1 Test Case Sample: Sample Diagnostics tests – EQ/NE: Failed
This is a sample diagnostics XML test pattern.
Test case begin:
2005-08-04 15:53.13 (logging timestamp: 0.000000)
Test case end:
2005-08-04 15:53.15 (logging timestamp: 0.195000)
1. Read Identification: Passed
Timestamp
Test Stepp
0.000000
Description
Result
Test pattern begin
-
0.001500
Resume
reason
Resumed on AuxEvent 'DiagServiceCheck()' Reason:
RequestConfirmation Elapsed time=2ms (max=2000ms)
-
0.022000
Resume
reason
Resumed on AuxEvent 'DiagServiceCheck()' Reason:
ResponseIndication Elapsed time=20ms (max=2000ms)
-
0.022000
2
Positive response arrived.
pass
0.022000
3
Parameter "Diagnostic_Identification": "0x01" == "0x01"
pass
Test pattern end
-
Description
Result
Test pattern begin
-
0.022000
2. Read Identification: Failed
Timestamp
Test Stepp
0.022000
0.174500
Resume
reason
Resumed on AuxEvent 'DiagServiceCheck()' Reason:
RequestConfirmation Elapsed time=152ms (max=2000ms)
-
0.195000
Resume
reason
Resumed on AuxEvent 'DiagServiceCheck()' Reason:
ResponseIndication Elapsed time=20ms (max=2000ms)
-
0.195000
2
Positive response arrived.
pass
0.195000
3
Parameter "Diagnostic_Identification" does not meet
condition "0x01" != "0x01"
fail
Test pattern end
-
0.195000
4.0 高度な例
4.1 "Resonse Pending" の ECU シミュレーション
ECU が診断要求にすぐに応答できない場合、応答コード “requestCorrectlyReceived-ResponsePending” (RCR-RP,
0x78) の Negative 応答を送信し、最終的な応答が遅れることを伝えることができます。CAPL でこのふるまいをシミュレー
ションするために、例えば以下のようなコード パターンを利用できます:
例:
variables
{
// ...
19
Application Note AN-JND-1-001
診断ツールとしての CANoe
BYTE gDelayedResponse[ 500];
// 遅延する応答のためのグローバルなバッファ
dword gDelayedResponseLen = 0;
// 蓄えられた応答の長さ。そのような応答が無ければ、0
msTimer gDelayTimer;
// 応答遅延用のタイマー
}
on diagRequest Class1::Instance1::Action1
{
diagResponse this resp;
// 応答パラメータを設定
DiagSetParameter( resp, "Param1", 1);
DiagSetParameter( resp, "Param2", 2);
// 後の送信のため、応答データをグローバル バッファにコピー
gDelayedResponseLen =
DiagGetPrimitiveData( resp, gDelayedResponse, elcount( gDelayedResponse));
// "response pending" を送信
DiagSendNegativeResponse( resp, 0x78);
// 応答を実際に送信するために用いるタイマーをスタート
settimer( gDelayTimer, 100);
}
on timer gDelayTimer
{
diagResponse ClassX::InstanceX::ActionX dummy;
if( gDelayedResponseLen > 0)
{
DiagResize( dummy, gDelayedResponseLen);
DiagSetPrimitiveData( dummy, gDelayedResponse, gDelayedResponseLen);
// 診断オブジェクトの「型」が、ここで変わる可能性がある
DiagSendResponse( dummy);
gDelayedResponseLen = 0;
}
}
"on timer gDelayTimer" ハンドラでの応答オブジェクトの「型」が、そのオブジェクトに書き込まれたデータによっては、初期
化時の型から変わりうることにご注意下さい。なお上記例以外の実装法もありえます。例えばより精密な ECU シミュレーシ
20
Application Note AN-JND-1-001
診断ツールとしての CANoe
ョンとして、 "Response Pending" Negative 応答の送信、タイマーのスタート、タイマーハンドラでの応答オブジェクト設定、
という処理フローをとることもできます。
4.2 診断オブジェクトの長さの変更
(診断応答のような) 診断オブジェクトの長さを変更することができます。これは、シミュレーション ECU から DTC を含んだ
診断応答を送信するときなどに便利です。このような診断応答の長さは、DTC の数に依存して変化するためです。
("NumberOfDTC" のような）後に続く単純パラメータ数を指定するパラメータがあるなら、そのパラメータに必要な値を設定
してください:
例:
DiagResponse this resp;
DiagSetParameter( resp, "NumberOfDTC", 12); // 後に 12 続く
DiagResize( resp); // CANoe 5.2 では不要
上記例では、12 パラメータ分の領域を確保しています。
このようなパラメータが無い場合、確保すべきバイト数を指定する必要があります。
例:
DiagResize( resp, 20); // 応答を 20 バイトにリサイズ
4.3 診断全体の設定
診断パラメータを記号で設定することも出来ますが、生値 (バイト配列) で直接設定することも出来ます。これは (例えば診
断応答などの) エラーをシミュレーションする際に便利です。
例:
char ECUpartNo[25] = "030821111A";
byte inbuffer[25];
// char 配列を byte 配列に変換
for(i=0;i<25;i++) inBuffer[i] = ECUpartNo[i];
// 応答パラメータを byte 配列で設定
DiagSetParameterRaw(resp, "Partnumber_for_ECU", inBuffer, 25);
4.4 障害挿入
ECU が不正な診断要求などにどう反応するかを検証するため、DiagSetPrimitiveData() 関数により診断要求パラ
メータを操作できます。この関数は、ECU 実装エラーのシミュレーションのためパラメータ値を変更するためにも利用できま
す。
診断オブジェクトを以下のように宣言すると、
diagRequest STORED_DATA::Sinus::Read req;
オブジェクトは「バス メッセージ」全体(つまり、バス上で通信されるデータ、サービス ID、サブファンクション ID)用の領域を
確保します。DiagSetPrimitiveData を用いてこのオブジェクトに別のデータを入れた場合、それは STORED_DATA::...で
はなく、他の「型」の要求や、CDD で定義されていないオブジェクトなどになる可能性があります。
21
Application Note AN-JND-1-001
診断ツールとしての CANoe
4.4.1
診断要求を不正な長さとする
// ECU の反応をチェックするため、診断要求オブジェクトの長さを不正な値にする
// CDD 定義と異なる長さ
DiagResize( req, 2);
このような変更がなされた診断要求が送信されても、トランスポート レイヤーは正しく動作します。つまり、データは正しく通
信されます。
4.4.2
トランスポート プロトコル レベルのエラー挿入
ECU の、トランスポート レイヤー レベルのエラーへの対処能力をテストすることも可能です。
例:
テスターが （例えば 10 バイトの) データ全てを送信すると宣言するが、実際には最初のフレーム送信後に送信をやめる
(Consecutive Frame が送信されない) ことをシミュレーションする例:
_Diag_DataRequest( BYTE data[], DWORD count, long furtherSegments) {
if( gAbortAfterFF) {
OSEKTL_FI_Enable();
// 障害挿入実行有無を管理するフラグ
// _FI_ 関数 (障害挿入関数)をアクティブにするために呼ばなくてはならない関数
OSEKTL_FI_SendXByte( 1, 8, -1);
// First Frame (DLC 8 byte) 全体を送信するよう設定
gAbortAfterFF = 0; // この障害挿入は、一度しか実行しない（このためにフラグをクリア）
}
OSEKTL_DataReq( data, count);
}
OSEK_TP.DLL の障害挿入に関する詳細は、[1] の Appendix: Fault injection support を参照下さい。
4.5 CAN-LIN ゲートウェイ シミュレーションを介した LIN ノードへのアクセス
•
CANoe 診断機能を用いて LIN だけを使用したノードにアクセスするには、CANoe 上での TP レベルの CAN-LIN
ゲートウェイ シミュレーション設定を利用できます。CAN 上での標準 ISO TP データ通信を設定するため、診断詳
細ファイル (CDD) を利用できます。CDD を、ゲートウェイ ノードが接続している CAN バスに割り当ててください。
ただしゲートウェイ ノードそのものには割り当てないで下さい。
• シミュレーション設定 Window で、ゲートウェイ ノードが CAN 用 ISO TP DLL (OSEK_TP.DLL) と LIN 用 DLL
(LINtp.DLL) を使用するよう設定してください。この設定は、ノード設定ダイアログの [モジュール] タブで DLL を追
加するか、データベースを設定することにより可能です。
• ゲートウェイ シミュレーションでは、診断要求は CAN バスから (診断コンソール、フォールト メモリー Window、実
ノード、シミュレーション ノード、テストモジュールなどを用いて) 送信され、ゲートウェイを介して LIN バスに送信さ
れなければなりません。LIN から CAN への診断応答に関しても、同様のアプローチが必要です。
• データが受信されたバスの "bus context" が設定されることに注意してください。データをもう一方のバスに転送す
る前に、 "bus context" を切り替える必要があります。
• ゲートウェイ シミュレーション ノードは、LIN マスター ノードとして動作する必要があります。
以下の TP レベル ゲートウェイ シミュレーションを、例として使用できます。 (多くの場合、 "on start" セクションの設定を使
用環境にあわせこむ必要があります。)
variables
{
char gECU[10] = "Gateway";
22
Application Note AN-JND-1-001
診断ツールとしての CANoe
long gNAD; // LIN ネットワークにおけるターゲット ノードのノード アドレス
dword linBusContext;
dword canBusContext;
}
OSEKTL_DataInd(long count)
{
/* この関数は受信したデータ数を返す */
byte rxBuffer[4096];
writeDbgLevel(1,"%s: OSEKTL_DataInd", gECU);
OSEKTL_GetRxData(rxBuffer, count);
setBusContext(linBusContext);
LINtp_DataReq(rxBuffer, count, gNAD);
}
LINtp_DataInd(long count)
{
/* この関数は受信したデータ数を返す*/
byte rxBuffer[4096];
writeDbgLevel(1,"%s: LINtp_DataInd", gECU);
LINtp_GetRxData(rxBuffer, count);
setBusContext(canBusContext);
OSEKTL_DataReq(rxBuffer, count);
}
on start
{
// !!! 以下のパラメータを使用環境に合わせこむ必要有り !!!
OSEKTL_SetNrmlMode();
OSEKTL_SetTxId(0x400);
OSEKTL_SetRxId(0x200);
gNAD = 1;
23
Application Note AN-JND-1-001
診断ツールとしての CANoe
canBusContext = GetBusNameContext("CAN");
linBusContext = GetBusNameContext("LIN");
setWriteDbgLevel(0);
}
LINtp_ErrorInd(int error)
{
}
OSEKTL_ErrorInd(int error)
{
}
5.0 よくある間違い
使用している CAPL ブラウザに、Diagnostic request, Diagnostic response のイベント カテゴリが現れないのはなぜです
か？
解: CANoe コンフィギュレーションに、CDD ファイルを追加しなければなりません。追加法に関しては 3.1.1 節をご覧下さ
い。
(CAPL から) 送信した診断要求がトレース Window で見られないのはなぜですか？
解: 診断要求送信先の ECU (またはバス) に CDD ファイルを割り当てなければなりません。
診断コンソールを利用できるなら、CDD が正しく割り当てられているといえます。
出力 Window に、以下のシステム メッセージが現れるのはなぜですか？
„System OSEK_TP ECU: Could not find mandatory callback function OSEKTL_ErrorInd!“
解: シミュレーション ECU (ノード)に、必要なコールバック関数が定義されていないためです。
出力 Window に、以下のシステム メッセージが現れるのはなぜですか？
„System DiagCreate Request: Accessing CANdelaLib lead to an error, e.g. exception, not found.“
解: CDD ファイルに該当する診断要求が無いため、診断要求を作成できませんでした。おそらく CAPL 上で、誤った診断リ
クエストが使用されています。診断コンソールで要求修飾子をチェックし、CAPL にコピーしてください。 (ただし / は :: に置
き換えてください。) 将来 (CANoe 5.1 以降では) エラーメッセージがより分かりやすいものとなる予定です。
出力 Window に、以下のシステム メッセージが現れるのはなぜですか？
„System Request services with complex/uncertain parameters are not supported!“
解: 診断コンソール初期化の際、定義されているすべての診断要求がチェックされます。現在診断コンソールが複合パラメ
ータを持つ診断要求を作成できないため、このような診断要求は表示されず、コンソールから直接送信することもできませ
ん。 (ただし、コンソールの Edit Line (診断サービス名の表示、編集が可能な行) からバイト列を直接入力する形の設定、
送信は可能です。) なお CAPL からの診断要求送信にはこのような制限はありません。しかしこのような診断コンソールに
24
Application Note AN-JND-1-001
診断ツールとしての CANoe
表示されない診断要求の修飾子パスは、当然 CAPL にコピーすることが出来ません。 (ただし、記号選択ダイアログ(2.2.7
節)ではこのような診断要求やパラメータであっても表示、選択できることにご注意下さい。)
シミュレーション設定 Window で、シミュレーション ECU 上に "OSEK_TP" と表示されるのはなぜですか？
解: CANoe のトランスポート レイヤー機能 (一般的な診断で必要とされるセグメンテーションその他のトランスポート レイヤ
ー機能) を使用するノードには、このノード レイヤー モジュールを割り当てる必要があります。このトランスポート プロトコル
を実装した DLL を CANoe から使用するためには、この割り当て情報が必要です。この情報を CANoe に認識させるには、
DBC ファイルを使う方法 (詳細はヘルプファイルをご覧下さい) と、シミュレーション設定 Window にてノード設定ダイアログ
を使う方法があります。後者について詳しくは、3.3.5節をご覧下さい。
トレース Window が以下のような表示をするのはなぜですか？
Unknown action::Unknown instance
解: 送受信されるデータ バイトが CDD ファイルから見つからないためです。CAPL か CDD ファイルを修正してください。こ
の現象は、ECU の実装 (ソフトウェア) が仕様 (CDD) に一致しない場合、つまり ECU 診断応答が CDD ファイルに記述さ
れていないデータ バイトを含む場合、にも起こりえます。
診断パラメータの値が常に 0 と表示されるのはなぜですか？なお出力 Window には、"parameter not found" などの警告
は表示されていません。
解: 以下のような良くある表現では
Write( "%d", DiagGetParameter( object, "Parameter"));
CAPL 関数からの double 型の戻り値が long 型として扱われ、この結果多くの場合 0 と表示されます。 (該当 CAPL 関数
の詳細は、ヘルプのレファレンスを参照下さい。) このため、以下のように戻り値をキャストするか、float フォーマットを使う
必要があります:
Write( "%d", (long) DiagGetParameter( object, "Parameter"));
Write( "%g", DiagGetParameter( object, "Parameter"));
25
Application Note AN-JND-1-001
診断ツールとしての CANoe
6.0 略語
CAPL
CAN Access Programming Language
CDD
CANdela Diagnostic Description
DBC
DataBase for CAN
ECU
Electronic Control Unit
DLL
Dynamic Link Library
DTC
Diagnostic Trouble Code
OEM
Original Equipment Manufacturer
SP
Service Pack
TP
Transport Protocol
7.0 参考文書
以下ドキュメントは、CANoe の通常インストールとともにインストールされ、[スタートメニュー] - [プログラム] - [CANoe] [Help] からのアクセスか、ファイルを直接開くことでのアクセスが可能です。
[1]
ISO/DIS 15765-2 Transport Protocol documentation:
[2]
診断標準を実装した標準 CDD:
Doc/osek_tp_e.pdf
Exec32\StandardCDDs\GenericKWP.cdd
Exec32\StandardCDDs\GenericUDS.cdd
8.0 その他のリソース
VECTOR APPLICATION NOTE
AN-IND-1-002
Testing with CANoe
AN-ION-1-1050 Introduction to Vehicle Network Software Development
AN-AND-1-121 Introduction to Detroit’s CAN-based Physical Layers
9.0 連絡先
Vector Informatik GmbH
Ingersheimer Straße 24
70499 Stuttgart
Germany
Tel.: +49 711-80670-0
Fax: +49 711-80670-111
Email: [email protected]
Vector CANtech, Inc.
39500 Orchard Hill Pl., Ste 550
Novi, MI 48375
USA
Tel: +1-248-449-9290
Fax: +1-248-449-9704
Email: [email protected]
Vector France SAS
168 Boulevard Camélinat
92240 Malakoff
France
Tel: +33 (0)1 42 31 40 00
Fax: +33 (0)1 42 31 40 09
Email: [email protected]
ベクター･ジャパン株式会社
〒140-0002
東京都品川区東品川 2-3-12
シーフォートスクエア センタービル 18F
Tel.:03-5769-6970
Fax: 03-5769-6975
Email: [email protected]
VecScan AB
Lindholmspiren 5
402 78 Göteborg
Sweden
Tel: +46 (0)31 764 76 00
Fax: +46 (0)31 764 76 19
Email: [email protected]
26
Application Note AN-JND-1-001