Andreas Patzer | Rainer Zaiser
XCP - ECU 開発用標準プロトコル
基礎と応用分野
Andreas Patzer | Rainer Zaiser
XCP – ECU 開発用標準プロトコル
ベクター・ジャパン株式会社（〒140-0002 東京都品川区東品川2-2-20 天王洲郵船ビル 16F；
〒460-0008 愛知県名古屋市中区栄4-5-3 KDX名古屋栄ビル8F）の明示的な許可がある場合を除き、
掲載内容の無断複写・転載を禁じます。
本書は個人で使用することを前提としており、技術用途または販売用途には使用できません。
また、いかなる形態であっても契約の根拠として使用することを禁止します。
本書に記載のすべての情報は最大限の注意を払って編集されていますが、ベクター・ジャパン株式会社は 記載されている情報の正確性について、いかなる場合でも保証または補償する責任を負いません。
ベクター・ジャパン株式会社は法規により責任を負うことが規定されていない限り、
悪意または重過失のある場合を除き、賠償責任を負いません。
本書に記載の情報は著作権または特許権 、あるいはその両方により保護されます。
本書で使用されるソフトウェア、ハードウェア、その他の製品名は商標登録されたブランドであるか、
そうでない場合は 、商標登録されたブランドとして特定されるかどうかにかかわらず、
それ以外の方法で商標登録に関する法律によって保護されます。
©2016 ベクター・ジャパン株式会社
XCP - ECU 開発用標準プロトコル
基礎と応用分野
Andreas Patzer, Rainer Zaiser Vector Informatik GmbH
はじめに... 7
1 XCPプロトコルの基礎 ...13
1.1 XCPプロトコルレイヤー ... 19
1.1.1 識別フィールド ...21
1.1.2 タイムスタンプ ...21
1.1.3 データフィールド ... 22
1.2 CTOの交換 ... 22
1.2.1 XCPコマンド構造 ... 22
1.2.2 CMD ... 25
1.2.3 RES ... 28
1.2.4 ERR ... 28
1.2.5 EV ... 29
1.2.6 SERV ... 29
1.2.7 スレーブ内のパラメーターのキャリブレーション ... 29
1.3 DTOの交換 - 同期データ交換 ... 32
1.3.1 測定方法：ポーリングとDAQ ... 33
1.3.2 DAQの測定方法 ... 34
1.3.3 STIMキャリブレーション方法 ... 42
1.3.4 DAQとSTIMに対するXCPパケットアドレス指定 ... 43
1.3.5 バイパス = DAQ + STIM ... 45
1.3.6 時間相関と同期 ... 45
1.4 XCPトランスポートレイヤー ...49
1.4.1 CAN ... 49
1.4.2 CAN FD ... 52
1.4.3 FlexRay ... 54
1.4.4 Ethernet ... 57
1.4.5 SxI ... 59
1.4.6 USB ... 60
1.4.7 LIN ... 60
1.5 XCPサービス... 61
1.5.1 メモリーページ切替え ...61
1.5.2 メモリーページの保存 – データページ凍結 ... 63
1.5.3 フラッシュプログラミング ... 63
1.5.4 スレーブの自動検出 ... 65
1.5.5 アップロード、ダウンロード、フラッシュ書込みのためのブロック転送モード ...66
1.5.6 コールドスタート測定（起動中） ... 67
1.5.7 XCPによるセキュリティーメカニズム ...68
2 ECU記述ファイル A2L ...71
2.1 XCPスレーブのためのA2Lファイルのセットアップ ... 74
2.2 A2Lファイルの手動作成 ... 75
2.3 A2LコンテンツとECU実装の対比 ... 76
3 キャリブレーションコンセプト ... 79
3.1 フラッシュ内のパラメーター ... 80
3.2 RAM内のパラメーター ...82
3.3 フラッシュオーバーレイ ...84
3.4 動的フラッシュオーバーレイの割り当て ...85
3.5 AUTOSARによるRAMポインターベースキャリブレーションコンセプト ...86
3.5.1 シングルポインターコンセプト ...86
3.5.2 ダブルポインターコンセプト ...88
3.6 フラッシュポインターベースのキャリブレーションコンセプト ...89
4 XCPの応用分野 ... 91
4.1 Model in the Loop (MIL) ... 93
4.2 Software in the Loop (SIL) ... 94
4.3 Hardware in the Loop (HIL) ...95
4.4 ラピットコントロールプロトタイピング（RCP） ... 97
4.5 バイパス ...98
4.6 バーチャルECUによる繰り返しサイクルの短縮 ... 101
5 XCPの実装例 ...105
5.1 関数の説明 ...108
5.2 ドライバーのパラメーター化 ... 110
6 プロトコル開発の概要 ...111
6.1 XCPバージョン1.1 （2008） ... 112
6.2 XCPバージョン1.2 （2013） ... 112
6.3 XCPバージョン1.3 （2015） ... 113
執 筆 者...... 114
略語と頭字語 ... 116
参考文献 ... 117
Webアドレス ... 117
図の目次......118
付録−ベクターのXCPソリューション ...120
アルファベット順索引 ... 122
7 はじめに
はじめに
電子制御ECUのパラメーター化（キャリブレーション）を最適に行うには、システムのランタイムに、パラメー ター値のキャリブレーションを行うと同時にシグナル測定値を取得します。開発ツールとECU間の物理的な 接続は測定/キャリブレーションプロトコルによって行われ、XCPが標準規格として定着しています。
まず、XCPの基本とメカニズムを簡単に説明してから応用分野を説明し、ECUキャリブレーションの付加 価値について詳しくみていきます。
まず、XCPに関する基礎知識について説明します。
> XCPとは、「Universal Measurement and Calibration Protocol」の略で、測定とキャリブレーションの
ための汎用プロトコルです。「X」は可変/互換トランスポートレイヤーを表しています。
> これは、ASAM （自動化および測定システム標準化協議会）の作業部会が標準化したものです。ASAMは
自動車関連メーカー、サプライヤー、ツールメーカーから成る組織です。
> XCPは、CCP (CANキャリブレーションプロトコル) の後継プロトコルです。
> CANキャリブレーションプロトコルのコンセプトは、CAN上で内部ECUデータを読み書きできるように
するという目的から生まれました。XCPは、この機能を異なる伝送媒体を介して実装するために開発され、
「XCP on CAN」、「XCP on FlexRay」、「XCP on Ethernet」などと呼ばれます。
> XCPの主な用途は、内部ECUパラメーターの測定とキャリブレーションです。この場合、このプロトコルに
よって、ECU内のプロセスに「 イベントと同期して」測定値を取得できる機能が付加されます。これにより、
ECU間のデータの整合性が確保されます。
基本となる考え方をわかりやすく示すため、最初はECUとその内部で動作するソフトウェアをブラックボック スであるとします。ブラックボックスの中では、ECUへの入力（CANメッセージとセンサー値など）および ECUからの出力（CANメッセージとアクチュエータードライブ）が取得され、アルゴリズムの内部処理につい ての詳細はすぐに分かるものではありません。これは、入力データと出力データの解析によってのみ明らか にすることができるのです。
では、計算処理サイクルごとにECUの振る舞いを検証できるとしたらどうでしょう。アルゴリズムの動作 状態に関する詳細な情報はいつでも取得可能になります。これで、ECUはもはやブラックボックスではなく なり、内部プロセスを完全に監視することができる、言わばホワイトボックスとなりました。これがまさに、
XCPを使用して実現できることなのです。
XCPは開発プロセス全体に対してどのように貢献するのでしょうか。たとえば、完成した開発ステータスの 機能性を確認するために、開発者はコードを繰り返し実行することができます。これを行うことで、開発者は アルゴリズムの挙動と、最適化の余地がある箇所を見つけ出すことができます。この場合、コンパイルされた コードがどのハードウェアで実行されたか、あるいはコードがモデルベースで開発され、アプリケーションが モデルの形で実行されたかは関係ありません。
最も重視されるのは、アルゴリズムプロセスの評価の部分です。たとえば、そのアルゴリズムがMathWorks社 のSimulinkなどの開発環境内でモデルとして実行されている場合、開発者が自分のアプリケーションにも 中間結果を取得することができれば、他の変更についての検証結果を取得するのに役立ちます。最終的な解 析において、この方式はパラメーターへの読込みアクセスだけを可能にすることで、パラメーターの視覚化
図1：
ランタイム環境での 基本的な通信
Application Operating System Runtime Environment Communication
PC Tool
と解析ができるようにします。これはすべて、モデルの実行時、または遡って時限付テストランの完了後に 行われます。PIDコントローラーの比例要素を変更し、アルゴリズムの挙動を制御中のシステムに合わせる 場合など、パラメーター化が変更された場合は書込みアクセスが必要です。開発者がアプリケーションを 実行する場所に関係なく、アルゴリズムプロセスとパラメーター化への変更による最適化についての詳細な 解析に常に重点が置かれます。
これは次のようにして実現されます。アルゴリズムは、実行可能な形式（コードまたはモデル記述）なら どのような形でも存在することができます。ランタイム環境としてさまざまなシステムを使用できます
（Simulink、PCのDLL、高速プロトコル通信プラットフォーム、ECUなど）。プロセスフローは、データへ の読込みアクセスとタイムベースフローの取得によって解析されます。パラメーターセットは繰り返し変更 され、アルゴリズムが最適化されます。データの取得は外部PCベースツールに外部化することができますが、
説明を簡単にするために、ここではランタイム環境自体に解析機能を持たせることができると考えます。
ランタイム環境の種類と通信の形式は通常大きく異なります。その理由は、ランタイム環境を作成するメー カーが異なり、異なるソリューションの手法を使用しているからです。プロトコル、コンフィギュレーション、
測定データフォーマットなどの種類が異なっており、すべての開発ステップにおいて、パラメーターセットと 結果を交換しようとしてもうまくいきません。しかし、最終的にはこれらのソリューションをすべて減ら し、実行時の読込み/書込みアクセスを行うことができます。そして、これに対する標準規格がXCPなのです。
XCPはASAMの標準規格で、バージョン1.0は2003年にリリースされました。ASAMは、Association for Standardisation of Automation and Measuring Systemsの略で、自動化と測定システムの標準化の ための組織として設立されました。サプライヤー、車両メーカー、ツールメーカーは、ASAMワーキンググループ に参加しています。XCPワーキンググループの目的は、特定のデータ伝送媒体に依存しないで使用すること ができる汎用化された測定/キャリブレーションプロトコルを定義することです。CCP （CANキャリブレー ションプロトコル）による作業の結果得られた経験も開発に活かされました。
XCPは、ASAMインターフェイスモデルをベースに定義されました。図2は、XCPスレーブ、記述ファイル への測定/キャリブレーションツールの各インターフェイスと、より高いレベルの自動化システムへの接続を 示しています。
9 はじめに
Measurement and Calibration System
ASAM MCD-3 MC
ASAM MCD-1 MC
ASAM MCD-2 MC
ECU Description File
Upper Level Automation System
ECU
XCP Driver XCP Driver
*.A2L
図2：
ASAMのインターフェイス モデル
インターフェイス1：「ASAM MCD-1 MC」ECUと測定/キャリブレーションシステム間で使用 このインターフェイスには、物理的でプロトコル固有の部分が記述されています。厳密に言えば、これはイ ンターフェイスASAP1aとインターフェイスASAP1bに分かれます。しかし、ASAP1bインターフェイスは 現在一般的には普及しておらず、実務目的として妥当ではありません。XCPプロトコルは柔軟性が高いた め、実用上、一般的なメーカー専用インターフェイスの役割を担うことができます。たとえば、現在すべて の測定/キャリブレーションハードウェアメーカーは、Ethernet規格でXCPを経由して接続するシステム
（xETK、VX1000など）を供給しています。ASAP1bインターフェイス（以前使われていたCCP用）は もう必要ありません。
インターフェイス2：「ASAM MCD-2 MC」A2L ECU記述ファイル
すでに説明したとおり、XCPはアドレス指向の方式で動作します。オブジェクトへの読込みまたは書込み アクセスは、必ずアドレスエントリーに基づいて行われます。しかし、最終的にはユーザーがこのアドレス に基づく「 マスター」内で自分のECUオブジェクトを検索する必要があるということになります。これで は非常に不便です。しかし、ユーザーがシンボリックオブジェクト名を使えるようにするには、たとえば、
オブジェクト名とオブジェクトアドレス間の関係を記述するファイルが必要です。次の章で、このA2L記述 ファイルについて説明します。
インターフェイス3：「ASAM MCD-3 MC」自動化インターフェイス
このインターフェイスはテストベンチ自動化のためなど、測定/キャリブレーションツールを他のシステムに 接続するために使用します。XCPを理解するためには関係がないため、このインターフェイスについては これ以上本書では説明しません。
図3：
XCPマスターは複数のスレーブと 同時通信が可能
Master
Slave
Slave Slave Slave
Bus
XCPはマスター/スレーブ原理に基づいています。ECUがスレーブで、測定/キャリブレーションツール がマスターです。スレーブは規定の時間内には1つのマスターとしか通信できませんが、一方でマスターは 複数のスレーブと同時に通信できます。
開発プロセス全体においてデータとコンフィギュレーションにアクセスできるようにするためには、XCP はあらゆるランタイム環境内で使用されなければなりません。購入、操作、メンテナンスを必要とするツー ルがより少なくなれば、1つのツールから別のツールへコンフィギュレーションを手動コピー（エラーに繋 がるプロセス）する必要もなくなります。これにより、反復ループが簡素化され、その後の作業ステップの 結果がそれ以前の作業ステップにフィードバックして転送されます。
今、私たちが留意しておきたいことは、現在何ができるかではなく、今後何ができるか―つまり、何でも可 能になるかということでしょう。XCPソリューションは、すでにさまざまな作業環境で使用されています。
本書の目的は、測定/キャリブレーションプロトコルの主な特性について説明し、さまざまなランタイム環境 での使用法について紹介することです。ただし、本書では、XCP全体の詳細な仕様や特定のランタイム環境 にXCPドライバーを組み込むための具体的な指示は記載されていません。本書は、個別のプロトコルと実 装の詳細を説明するものではなく、その関係性についてを説明するものです。どのように実装するのかにつ いては、付録に記載されているインターネットリンクから、公開されている利用可能なXCPドライバーの ソースコードやサンプルの実装例をご参照くださればと思います。
本書に使用されるPCツールのスクリーンショットは、ベクターの提供するCANape測定/キャリブレーション ツールを使用して作成されました。A2Lファイルの作成方法や、それ以外のプロセスフローもCANapeを基に 説明しています。無料のデモバージョンはベクターのWebサイト（www.vector-japan.co.jp）内「 ダウン ロードセンター」よりダウンロード可能ですので、ご利用ください。
11
This page intentionally left blank.
This page intentionally left blank.
13
1 XCPプロトコルの基礎
1 XCP プロトコルの基礎
ASAMインターフェイスモデルのインターフェイス1は、スレーブとマスター間のコマンドとデータの 送受信を記述します。特定の物理トランスポートレイヤーからの独立性を実現するために、XCPをプロト コルレイヤーとトランスポートレイヤーに細分化しました
図4：XCPプロトコルのプロトコルレイヤーとトランスポートレイヤーへの細分化
CAN Ethernet FlexRay SxI USB ...
トランスポートレイヤーに応じて、XCP on CANやXCP on Ethernetと呼ばれています。新規トランス ポートレイヤーへの拡張性は、すでに2005年にXCP on FlexRayが登場したことで証明されました。XCP プロトコルの現行バージョンは1.3で、2015年に認証されました。
プロトコルの設計にあたっては、以下の原則に従うことが最優先となります。
> ECU内のリソースは最小限の使用
> 効率的な通信
> シンプルなスレーブ実装
> パラメーターをごく少数に抑えたプラグ＆プレイコンフィギュレーション
> スケーラビリティー
15
1 XCPプロトコルの基礎
XCPの主機能は、スレーブのメモリーへの読込み／書込みアクセスを可能にすることです。
読込みアクセスにより、ユーザーが内部ECUパラメーターの時間応答を測定することができます。ECU は個別の時間挙動を持つシステムで、そのパラメーターは特定の時間間隔（プロセッサーが値を再計算し、
RAM内で更新したとき）でしか変化しません。XCPの大きな特長の1つは、プロセスフローまたはECU 内のイベントに同期して変化するRAMからの測定値の取得にあります。これにより、ユーザーはECU内 のタイムベースのプロセスフローと変化する値の間の直接的な関係を評価できます。これらはイベント同期 測定値と呼ばれます。これに関連するメカニズムについては、後ほど詳しく説明します。
書込みアクセスにより、ユーザーはスレーブ内のアルゴリズムのパラメーターを最適化できます。アクセス はアドレス指向で、つまり、マスターとスレーブ間の通信がメモリー内のアドレスを参照します。このため、
パラメーターの測定は、基本的に「 メモリー位置0x1234の値を要求する」といったマスターのスレーブへ の要求として実行されます。パラメーターのスレーブへのキャリブレーション（書込みアクセス）は「 アド レス0x9876から5への値の設定を要求する」となります。
XCPスレーブは必ずしもECU内で使用される必要はありません。XCPは、モデルベース開発環境から Hardware-in-the-Loop (HIL) /Software-in-the-Loop (SIL) 環境、JTAG、NEXUS、DAPなどの デバッグインターフェイスによるECUメモリーへのアクセスに使用されるハードウェアインターフェイス まで、さまざまな環境に実装できます。
図5：
XCPスレーブはさまざまな ランタイム環境で使用可能 Slave
Slave
Slave Slave Slave
PC
Measurement/
Calibration Hardware*
* Debug Interfaces, Memory Emulator ...
HIL/SIL Systems EXE/DLL Prototype or ECU Hardware Simulink
Master
XCP
メモリーの基礎
現在、FLASHメモリーはたいていECUのマイクロコントローラーチップに組み込まれており、電源のない 状態でもコードとデータを長期間保存するために使用されています。FLASHメモリーの特殊な点は、個々の バイト単位のデータの読込み／書込みアクセスが常時可能ではあるが、新規データの書込みはブロック単位、
それも比較的大きなブロック単位でしか行うことができないということです。
FLASHメモリーの寿命は限られており、仕様により最大消去回数が決められています（具体的な技術に よって異なりますが、消去回数は最大100万回程度）。メモリーは必ずブロックを消去してからでなければ 再度書込みができないため、これは最大書込み回数でもあります。その理由はメモリー構造にあります。電子 はトンネルダイオードを経由して 取り出され ます。ビットデータは、電子が電気絶縁層の上からメモリー 位置に伝送され、メモリー位置に保存されます。そして電子が絶縁層の裏側に来ると、その電荷で電場を形成 し、それがメモリー位置を読み取る際に1として解釈されます。層の裏側に電子がないと、セル情報は0と して解釈されます。1は実際にこのような方法で設定できますが、0はできません。0の設定（= 1の消去）は 別の消去ルーチンで実行し、絶縁層裏側に存在する電子の電荷が放電されます。しかし、構造的な理由から、
そうした消去ルーチンは単一のバイトデータのみに作用させることができず、グループまたはブロックレベルに 作用します。構造に応じて、128バイトまたは256バイトが通常使用されます。そうしたブロック内の1バイ トデータを上書きしたい場合は、ブロック全体をまず消去しなければなりません。その後、ブロック全体の データ内容を書き戻します。
この消去ルーチンを複数回繰り返すと、絶縁層（「トンネル酸化物膜」）が損傷することがあります。これは電 子がゆっくりと漏れてしまう可能性があり、長時間経過すると、一部の情報が1から0に変化するということ です。したがって、ECU内では許容されるフラッシュ動作回数が厳しく制限されています。生産ECUでは、
これが10回未満に抑えられている場合が多くなっています。この制限はフラッシュブートローダーが監視し、
すでに実行されているフラッシュ動作の回数を記録するカウンターを使用します。規定の回数を超えると、
フラッシュブートローダーがそれ以上のフラッシュ動作要求を拒絶します。
RAM （Random Access Memory、ランダムアクセスメモリー）は常時電源を必要とし、電源が喪失する と内容が失われます。FLASHメモリーはアプリケーションの長期的な保存を目的としており、RAMは計算 済みデータとその他の一時的な情報のバッファリングに使用されます。電源を停止すると、RAM内のデータ 内容は失われることになります。FLASHメモリーとは違い、RAMの読込み／書込みは簡単です。
ECUへの読込み／書込みアクセスを使用してアルゴリズムを最適化する方法やメリットはどのようなも のでしょうか。各パラメーターをECU内での実行時に変更できるようにするには、パラメーターへのア クセスが必要です。すべての種類のメモリーでこのプロセスが可能なわけではなく、可能なのはRAM内 のメモリーアドレスに読込み／書込みアクセスを実行することだけです（ここではEEPROMは意図的に 除外しています）。以下に個々のメモリー技術間の差異を簡単に説明します。こうした差異を知ることは、
本書の内容をさらに深く理解するために大変重要です。
17
1 XCPプロトコルの基礎
実行時にパラメーターを変更する必要がある場合は、確実にRAM内に配置しなければなりません。この事実 を理解することはきわめて重要です。そのため、これから以下の例に基づき、ECU内のアプリケーションの 実行について説明していきます。
アプリケーション内では、「y」パラメーターはセンサー値「x」から算出されます。
// 擬似コードによる表現 a = 5;
b = 2;
y = a * x + b;
このアプリケーションがECUでフラッシュされる場合、起動後、コントローラーはパラメーター「x」がセ ンサー値に対応するように、このコードを取り扱います。したがって同じ時点で、このアプリケーション はセンサー値をポーリングし、次にその値をパラメーター「x」に割り当てられたメモリー位置に保存しな ければなりません。この値は実行時に常に再度書き込む必要があるため、メモリーの位置は絶対にRAM内 である必要があります。
パラメーター「y」が計算されます。値「a」と「b」（それぞれ係数とオフセット値）は情報としてFLASH メモリーに保存されます。FLASHメモリーの中では定数として保存されます。ここでも、RAMは書込み アクセスが可能な唯一の場所であるため、値「y」もRAMに保存される必要があります。RAM内でのパラ メーター「x」と「y」の正確な位置またはフラッシュ内での「a」と「b」の位置は、コンパイラー／リンカー 実行時に設定されます。これはオブジェクトが固有のアドレスに割り当てられる場所です。オブジェクト 名、データタイプ、アドレス間の関係は、リンカーマップファイル内に記録されます。リンカーマップファ イルはリンカーの実行によって生成され、さまざまなフォーマットで保存することができます。しかし、
オブジェクト名とアドレスを含むことは、最低でもすべてのフォーマットに共通の事項です。
この例では、オフセット「b」と係数「a」が特定の車両に依存している場合、「a」と「b」の値はそれぞれの 車両の状態に個別に合わせなければなりません。これは、アルゴリズムはそのまま同じですが、パラメー ター値は車両によって異なるということです。
ECUの通常動作モードでは、アプリケーションはFLASHメモリーから実行されます。アプリケーション は個別のオブジェクトへの書込みアクセスを許可しません。これは、フラッシュエリアにあるパラメーター 値が実行時には変更できないということです。実行時にパラメーター値を変更する必要がある場合は、変更 する対象のパラメーター値はフラッシュではなく、RAMに置かなければなりません。それでは、どのよう にしてパラメーターとその初期値をRAMに置くのでしょうか？同時にRAMに保存できる数よりも多い パラメーターを変更する必要がある場合、どうすればよいでしょうか？こうした問題については、キャリブ レーションコンセプト（本書の第3章）の内容を参照してください。
XCPの基礎のまとめ
メモリー内容への読込み／書込みアクセスには、XCPプロトコルのメカニズムを使用できます。アクセスは アドレス指向で行われます。読込みアクセスによりRAMからのパラメーターの測定を行い、書込みアクセス によりRAM内のパラメーターのキャリブレーションを行うことができます。XCPは、ECU内のイベントと 同期した測定の実行を許可します。これにより、測定値に相関性が与えられます。測定を再起動するたびに、
測定対象のシグナルを自由に選択できます。書込みアクセスの場合、キャリブレーション対象のパラメー ターはRAMに保存しなければなりません。これにはキャリブレーションコンセプトが必要です。
ここで、次のような2つの重要な疑問が生じます。
> XCPプロトコルのユーザーがRAM内の測定／キャリブレーションパラメーターの正しいアドレスを知る
方法は？
> キャリブレーションコンセプトとはどのような形式なのか？
最初の疑問については、本書の第2章「ECU記述ファイルA2L」に答えがあります。キャリブレーション コンセプトの内容は、第3章で取り扱います。
19
1.1 XCPプロトコルレイヤー
1.1 XCP プロトコルレイヤー
XCPデータはマスターとスレーブ間ではメッセージベースの方式で交換されます。「XCPメッセージフレー ム」全体は、トランスポートレイヤーのフレーム内に埋め込まれます（UDPパケット内のUDPによるXCP on Ethernetの場合）。フレームは、XCPヘッダー、XCPパケット、XCPテールの3つの部分に分かれています。
以下の図では、メッセージの一部が赤色で表示されています。これは現在のXCPフレームを送信するため に使用されます。XCPヘッダーとXCPテールはトランスポートプロトコルに依存します。
図6： XCPパケット XCP Header
XCP Message (Frame) XCP Packet PID
Identification
Field Timestamp
Field Data
Field FILL DAQ TIMESTAMP DATA
XCP Tail
XCPパケット自体は使用されるトランスポートプロトコルに依存しません。これには必ず「識別フィール ド」、「 タイムスタンプフィールド」、現在データのフィールドである「 データフィールド」の3つのコンフィ ギュレーション要素が含まれています。各識別フィールドはパケット識別子（PID）で始まり、パケットを 識別します。
以下の概要図は、すでに定義されているPIDを示しています。
0xFF
CMD
PID for frames
from Master to Slave PID for frames from Slave to Master
absolute or relative ODT number for STIM
0xC0 0xBF
0x00
...
absolute or relative ODT number for DAQ
0xFF 0xFE 0xFD 0xFC
RES ERR EV SERV
0xFB
0x00
....
図7：XCPパケット識別子（PID）の概要
XCPパケットによる通信は、コマンド領域 (CTO) と同期データ送信領域 (DTO) に細分化されます。
XCP Master
XCP Slave
CMD RES ERR EV SERV
CTO
STIM DTO
Command / Response / Error / Event / Service Request Processor
DAQ Processor
STIM Processor
DAQ STIM
PGM CAL
Bypass XCP Handler
Resources
DAQ XCP Driver
図8：
CTO/DTOを持つ XCP通信モデル
ここで使用する略語：
CMD
RES
ERR
EV SERV DAQ STIM
コマンドはCTO （Command Transfer Objects、コマンドトランスファーオブジェクト）により交換 されます。たとえば、マスターはこのようにしてコンタクトを開始します。スレーブはRESまたはERRを伴う CMDには必ず応答することになっています。その他のCTOメッセージは非同期で送信されます。DTO （Data Transfer Objects、データトランスファーオブジェクト）は、同期測定／スティミュレーションデータを 交換するために使用されます。
コマンドを送信 ポジティブレスポンス ネガティブレスポンス 同期イベント サービス要求
定期間隔での測定値送信
スレーブの一定間隔でのスティミュレーション コマンドパケット
（Command Packet） コマンドレスポンスパケット
（Command Response Packet） エラー
（Error） イベントパケット
（Event Packet） サービス要求パケット
（Service Request Packet） データ取得
（Data AcQuisition） スティミュレーション
（Stimulation）
21
1.1 XCPプロトコルレイヤー
1.1.1 識別フィールド
図9： メッセージ識別
XCP Packet
PID
Identification Field
FILL DAQ TIMESTAMP DATA
メッセージを交換する際は、マスターとスレーブの両方がお互いにメッセージを送信した側を判断できるよう にしなければなりません。これは識別フィールドで行います。そのため、各メッセージの頭にPID （Packet Identifier、パケット識別子）が付きます。
CTOを送信する際は、CMD、RES、またはその他のCTOパケットを識別するにはPIDフィールドで充分 です。図7では、マスターからスレーブへのコマンドが、0xC0から0xFFへのPIDを使用していることが 分かります。XCPスレーブは、0xFCから0xFFまでのPIDで、マスターへの応答または通知を行います。
これにより、個別に送信されたCTOへのPIDの一意の割り当てが行われます。
DTOが送信されると、識別フィールドの他の構成要素が使用されます（本書の1.3.4「DAQとSTIMに対する XCPパケットアドレス指定」の章を参照）。
1.1.2 タイムスタンプ
図10： タイムスタンプ
XCP Packet
TIMESTAMP
PID FILL DAQ DATA
DTOパケットはタイムスタンプを使用しますが、CTOメッセージの送信時には使用できません。スレーブ はタイムスタンプを使用して、時間情報に測定値を付加します。すなわち、マスターには測定値だけでなく、
測定値が取得された時点も送信されるということです。測定値と時点の関係はスレーブから直接送信される ため、マスターに測定値が到着するまでの時間の長さは重要ではなくなります。
スレーブからのタイムスタンプの送信はオプションです。この内容についての詳細は、「ASAM XCP パート2プロトコルレイヤー仕様（ASAM XCP Part 2 Protocol Layer Specification）」で説明され ています。
1.1.3 データフィールド
図11： XCPパケット内の データフィールド
XCP Packet
DATA Data Field
PID FILL DAQ TIMESTAMP
XCPパケットにはデータフィールド内に保存されたデータも含まれます。CTOパケットの場合、データ フィールドはさまざまなコマンドの特定のパラメーターで構成されます。DTOパケットにはスレーブか らの測定値が含まれ、STIMデータが送信されると、マスターからの値が含まれます。
1.2 CTO の交換
CTOは、マスターからスレーブへのコマンドとスレーブからマスターへのレスポンスの両方を送信する ために使用されます。
1.2.1 XCPコマンド構造
スレーブはマスターからのコマンドを受信すると、ポジティブレスポンスかネガティブレスポンスを返す ことでそれに反応しなければなりません。この場合、通信構造は必ず同じです。
コマンド（CMD）：
位置 タイプ 説明
0 バイト(BYTE) コマンドパケットコードCMD（Command Packet Code CMD） 1..MAX_CTO-1 バイト(BYTE) コマンド専用パラメーター（Command specific Parameters)
ポジティブレスポンス：
位置 タイプ 説明
0 バイト(BYTE) コマンドポジティブレスポンスパケットコード = RES 0xFF （Command Positive Response Packet）
1..MAX_CTO-1 バイト(BYTE) コマンド専用パラメーター（Command specific Parameters) 各コマンドには一意の番号が割り当てられます。さらに、その他の特定のパラメーターをコマンドと共に送 信できます。この場合、パラメーターの最大数はMAX_CTO-1として定義します。MAX_CTOはCTO パケットの最大長を示します（単位：バイト）。
23 1.2 CTOの交換
ネガティブレスポンス：
位置 タイプ 説明
0 バイト(BYTE) エラーパケットコード = 0xFE（Error Packet Code = 0xFE） 1 バイト(BYTE) エラーコード（Error code)
2..MAX_CTO-1 バイト(BYTE) コマンド専用パラメーター（Command specific Parameters） 特定のパラメーターをポジティブレスポンスの場合だけでなく、ネガティブレスポンスにも付加して追加情 報として送信することができます。1つの例は、マスターとスレーブ間で接続を行う場合です。マスターと スレーブ間の通信開始時に、マスターはスレーブに接続要求を送信し、スレーブはそれに応答して肯定レス ポンスを行うことになっており、これにより連続したポイント間接続が確立します。
マスター→スレーブ：接続
スレーブ→マスター：ポジティブレスポンス 接続コマンド：
位置 タイプ 説明
0 バイト(BYTE) コマンドコード=0xFF（Command code = 0xFF） 1 バイト(BYTE) モード（Mode)
00 = 標準（00 = Normal）
01 = ユーザー定義（01 = user defined）
モード00は、マスターがスレーブとXCP通信を行いたいということを示しています。マスターが接続を 行う際に0xFF 0x01を使う場合、マスターはスレーブとのXCP通信を要求しています。同時にマスター は、特定の (ユーザー定義の) モードに切り替える必要があることをスレーブに通知します。
スレーブのポジティブレスポンス：
位置 タイプ 説明
0 バイト(BYTE) パケットID：0xFF （Packet ID: 0xFF）
1
バイト(BYTE) リソース（RESOURCE） 2 バイト(BYTE) COMM_MODE_BASIC 3
バイト(BYTE) MAX_CTO、最大CTOサイズ（BYTE） 4 WORD MAX_DTO、最大DTOサイズ（BYTE） 6
バイト(BYTE) XCPプロトコルレイヤーバージョン番号（最も重要なバイトのみ）
（XCP Protocol Layer Version Number）
7 バイト(BYTE) XCPトランスポートレイヤーバージョン番号（最も重要なバイトのみ）
（XCP Transport Layer Version Number）
スレーブのポジティブレスポンスは、もう少し拡張した形式を含めることができます。スレーブは接続を行う 際、マスターにすでに通信専用情報を送信しています。たとえば、RESOURCEは、その機能をページ切替え としてサポートするかどうか、またはXCP上でフラッシュ動作が可能かどうかについて、スレーブによって 与えられる情報です。スレーブはMAX_DTOを使用して、マスターに測定値などの転送のために、スレーブが サポートする最大パケット長を通知します。パラメーターの詳細については、「ASAM XCPパート2プロト コルレイヤー仕様」で説明されています。
マスターとスレーブ間でコマンドと応答を交換するために、XCPは「標準」、「 ブロック」、「 インターリーブ」の 3つの異なるモードを許可します。
図12：XCPプロトコルのモードは、「標準」、「ブロック」、「インターリーブ」の3つ MIN_ST
MAX_BS
Time
Master Slave
Time
Master Slave
Time
Master Slave
Standard Mode Block Mode Interleaved Mode
Request k+1 Response k
Response k+1
Request k Request k
Request k+1
Response k Response k+1 Response k
Request k+1 Response k+1
Request k Part1 Part3 Part2
Part1 Part2 Part3
標準通信モデルでは、スレーブへの各要求の後に単一レスポンスが続きます。XCP on CANを除き、複数の スレーブがマスターからの1つのコマンドに応答することは許可されません。したがって、各XCPメッセー ジは常に一意のスレーブへ追跡可能です。このモードは通信において標準的なケースです。
ブロック転送モードはオプションで、大量のデータ転送時には転送時間の短縮が可能です（アップロードま たはダウンロード動作時など）。この場合でも、このモードではスレーブ方向のパフォーマンス問題を考慮 しなければなりません。したがって、2つのコマンド間の最低時間（MIN_ST）を維持し、コマンドの合計数 を上限値（MAX_BS）に制限しなければなりません。オプションで、マスターが GET_COMM_MODE_
INFO を使用してスレーブからこれらの通信設定を読み出すことができます。マスター方向でのブロック転 送モードでは前述の制限を守る必要はありません。それはPCが常にマイクロコントローラーからのデータを 受けるために充分な性能を備えているためです。
パフォーマンス上の理由からインターリーブモードも提供されます。しかし、この方式もオプションであり、
ブロック転送モードとは違い、実務的には妥当ではありません。
25 1.2 CTOの交換
1.2.2 CMD
図13：CTOパケット構造の概要
PID DATA
Data Field Identification Field
Timestamp Field empty for CTO
XCP CTO Packet
マスターはCMDにより、スレーブに一般要求を送信します。PIDフィールドにはそのコマンドの識別番号 が含まれます。追加詳細パラメーターはデータフィールドで伝送されます。次に、マスターは「RESponse
（レスポンス）」または「ERRor （エラー）」形式でのスレーブの応答を待ちます。
XCPはその実装においても非常にスケーラブルであるため、すべてのコマンドを実装する必要はありませ ん。A2Lファイルでは、利用可能なCMDはXCP IF_DATAという名前の場所に記載されています。A2L ファイルの定義とスレーブ内の実装に差異がある場合、マスターはスレーブの応答に基づき、スレーブがそ のコマンドに対応さえしていないと判断できます。マスターがスレーブ内に実装されていないコマンドを送 信した場合、スレーブはERR_CMD_UNKNOWNを返し、スレーブ内ではそれ以上の動作は開始されま せん。これによってマスターは、オプションコマンドがスレーブに実装されていないことを短時間で認識す ることができます。
コマンド内にはその他のパラメーターもいくつか含まれています。正確な詳細については「ASAM XCP パート2プロトコルレイヤー仕様」を参照してください。
コマンドは、標準、キャリブレーション、ページ、プログラミング、DAQ測定コマンドの各グループに分類 されています。あるグループをまったく必要としない場合、そのコマンドは実装する必要がありません。
そのグループが必要な場合、一部のコマンドは必ずスレーブ内で利用可能である必要がありますが、そのグ ループ内の他のコマンドはオプションです。
以下の概要は一例です。ページ切替えグループのSET_CAL_PAGEとGET_CAL_PAGEコマンドは、
オプションでないと識別されます。これはページ切替えをサポートするXCPスレーブ内では、最低これらの 2つのコマンドを実装しなければならないということです。スレーブ内でページ切替えサポートが必要とされ ない場合は、これらのコマンドを実装する必要はありません。同じことが他のコマンドにも当てはまります。
標準コマンド：
コマンド PID オプション
CONNECT 0xFF ×
DISCONNECT 0xFE ×
GET_STATUS 0xFD ×
SYNCH 0xFC ×
GET_COMM_MODE_INFO 0xFB ○
GET_ID 0xFA ○
SET_REQUEST 0xF9 ○
GET_SEED 0xF8 ○
UNLOCK 0xF7 ○
SET_MTA 0xF6 ○
UPLOAD 0xF5 ○
SHORT_UPLOAD 0xF4 ○
BUILD_CHECKSUM 0xF3 ○
TRANSPORT_LAYER_CMD 0xF2 ○
USER_CMD 0xF1 ○
キャリブレーションコマンド：
コマンド PID オプション
DOWNLOAD 0xF0 ×
DOWNLOAD_NEXT 0xEF ○
DOWNLOAD_MAX 0xEE ○
SHORT_DOWNLOAD 0xED ○
MODIFY_BITS 0xEC ○
標準コマンド：
コマンド PID オプション
SET_CAL_PAGE 0xEB ×
GET_CAL_PAGE 0xEA ×
GET_PAG_PROCESSOR_INFO 0xE9 ○
GET_SEGMENT_INFO 0xE8 ○
GET_PAGE_INFO 0xE7 ○
SET_SEGMENT_MODE 0xE6 ○
GET_SEGMENT_MODE 0xE5 ○
COPY_CAL_PAGE 0xE4 ○
27 1.2 CTOの交換
定期データ交換-ベーシック：
コマンド PID オプション
SET_DAQ_PTR 0xE2 ×
WRITE_DAQ 0xE1 ×
SET_DAQ_LIST_MODE 0xE0 × START_STOP_DAQ_LIST 0xDE ×
START_STOP_SYNCH 0xDD ×
WRITE_DAQ_MULTIPLE 0xC7 ○
READ_DAQ 0xDB ○
GET_DAQ_CLOCK 0xDC ○
GET_DAQ_PROCESSOR_INFO 0xDA ○ GET_DAQ_RESOLUTION_INFO 0xD9 ○
GET_DAQ_LIST_INFO 0xD8 ○
GET_DAQ_EVENT_INFO 0xD7 ○
定期データ交換-静的コンフィギュレーション：
コマンド PID オプション
CLEAR_DAQ_LIST 0xE3 ×
GET_DAQ_LIST_INFO 0xD8 ○
定期データ交換-動的コンフィギュレーション：
コマンド PID オプション
FREE_DAQ 0xD6 ○
ALLOC_DAQ 0xD5 ○
ALLOC_ODT 0xD4 ○
ALLOC_ODT_ENTRY 0xD3 ○
フラッシュプログラミング：
コマンド PID オプション
PROGRAM_START 0xD2 ×
PROGRAM_CLEAR 0xD1 ×
PROGRAM 0xD0 ×
PROGRAM_RESET 0xCF ×
GET_PGM_PROCESSOR_INFO 0xCE ○
GET_SECTOR_INFO 0xCD ○
PROGRAM_PREPARE 0xCC ○
PROGRAM_FORMAT 0xCB ○
PROGRAM_NEXT 0xCA ○
PROGRAM_MAX 0xC9 ○
PROGRAM_VERIFY 0xC8 ○
1.2.3 RES
スレーブがマスターの要求を完全に満たすことができた場合、スレーブはRESにより肯定的な確認を送 信します。
位置 タイプ 説明
0 バイト（BYTE） パケット識別子 = RES 0xFF（Packet Identifier = RES 0xFF） 1..MAX_CTO-1 バイト（BYTE） コマンドレスポンスデータ（Command response data） パラメーターの詳細な情報については「ASAM XCPパート2プロトコルレイヤー仕様」をご参照ください。
1.2.4 ERR
マスターからの要求が使用不可の場合、エラーメッセージERRとエラーコードで応答します。
位置 タイプ 説明
0 バイト（BYTE） パケット識別子 = ERR 0xFE（Packet Identifier = ERR 0xFE） 1 バイト（BYTE） エラーコード（Error code）
2..MAX_CTO-1 バイト（BYTE） オプションのエラー情報データ（Optional error information data） 使用される可能性のあるエラーコードは「ASAM XCPパート2プロトコルレイヤー仕様」に記載されています。
29 1.2 CTOの交換
1.2.5 EV
スレーブがマスターに非同期イベントを通知したい場合は、EVを送信して通知することができます。
この実装はオプションです。
位置 タイプ 説明
0 バイト（BYTE） パケット識別子 = EV 0xFD（Packet Identifier = EV 0xFD） 1 バイト（BYTE） イベントコード（Event code）
2..MAX_CTO-1 バイト（BYTE） オプションのイベント情報データ（Optional event information data） パラメーターの詳細な情報については、「ASAM XCPパート2プロトコルレイヤー仕様」をご参照くだ さい。
イベントについては、測定とスティミュレーション関連のところでさらに詳しく説明していきます。これ はEVENTの送信を開始するXCPスレーブの動作とはまったく関係がありません。関係があるのは、特定 の機能の不具合などの障害を報告するスレーブです。
1.2.6 SERV
スレーブはこのメカニズムを使用して、マスターによる任意のサービスの実行を要求できます。
位置 タイプ 説明
0 バイト（BYTE） パケット識別子 = SERV 0xFC（Packet Identifier = SERV 0xFC） 1 バイト（BYTE） サービス要求コード（Service request code）
2..MAX_CTO-1 バイト（BYTE） オプションのサービス要求データ（Optional service request data） サービス要求コード表は、「ASAM XCPパート2プロトコルレイヤー仕様」に記載されています。
1.2.7 スレーブ内のパラメーターのキャリブレーション
任意のXCPスレーブ内のパラメーターを変更するには、XCPマスターがパラメーターの位置と値自体を スレーブに送らなければなりません。
XCPは常にアドレスを5バイト（うち4バイトが実際のアドレス用、残り1バイトがアドレス拡張用）で 定義します。CAN送信の場合、XCPメッセージに利用可能なバイト数は7バイトのみです。たとえば、
キャリブレーション担当者が4バイト値を設定し 、1つのCANメッセージで両方のデータを送信した い場合は 、送信のための充分な領域がありません。アドレスと新規の値を送信するには合計で9バイト必 要なため、この変更は1つのCANメッセージ（利用可能バイト：7バイト）では送信できません。このた め、キャリブレーション要求はマスターからスレーブまで2つのメッセージで行います。スレーブは両方 のメッセージを確認しなければならないため、合計で4つのメッセージが交換されます。
以下の図は、マスターとスレーブ間の通信を示しています。これはパラメーター値の設定に必要です。
実際のメッセージは封筒アイコンが表示されている行にあります。メッセージの内容は、マウスで「拡張」
すると表示されます。
図14：CANapeでの適合プロセスにおけるトレースの例
マスターの最初のメッセージ（図14の青色表示部分）では、マスターはコマンドSET_MTAを新規の値を 書き込むべきアドレスと共にスレーブに送信します。2番目のメッセージでは、スレーブがそのコマンド にOk:SET_MTAで肯定確認を返します。
3番目のメッセージDOWNLOADは、16進値と有効なバイト数を送信します。この例では、値のため 有効なバイト数は4です。スレーブは4番目のメッセージでさらに肯定確認を返します。
これで、現在のキャリブレーションプロセスが完了します。トレース表示でSHORT_UPLOADの終了 を確認できます。これはベクターが提供する測定／キャリブレーションツール「CANape」の特長です。
キャリブレーションが完全に実行されたことを確認するため 、プロセス後にこの値が再度読み出され 、 表示が読み出し値で更新されます。これにより、ユーザーはキャリブレーションコマンドが実行されたか どうかを直接確認できます。このコマンドは、Ok:SHORT_UPLOADで肯定確認も取得します。
ECUのRAM内でパラメーターが変化すると、アプリケーションは新規の値を処理します。しかし、
ECUを再起動すると値は消去され、フラッシュからのオリジナル値でRAM内の値を上書きします（本 書の第3章「 キャリブレーションコンセプト 」を参照）。では、変更したパラメーターセットを恒久的に 保存するにはどうすればよいのでしょうか?
31 1.2 CTOの交換
基本的に以下の2つの選択肢があります。
A）パラメーターをECU内に保存する
たとえば、RAM内で変更されたデータは、ECUのランプダウン時に自動的に、またはユーザーが手動で ECUのEEPROMに保存します。この前提条件は、スレーブの不揮発性メモリー内にデータが保存可能で あるということです。ECU内では、これはEEPROMであったり、フラッシュであったりします。しかし、
パラメーターを何千も持つECUに、未使用のEEPROM空間が残っていることはほとんどないため、この 手法はあまり採られません。
あるいは、RAMパラメーターをECUのFLASHメモリーに書き戻す方法ですが、これは比較的複雑な手 法です。FLASHメモリーは、まず消去してからでなければ再度書込みはできず、ブロック単位でしか行う ことができません。したがって、これは単純に個別のバイトを書き戻せばいいというものではありません。
この内容についての詳細は、本書の第3章「 キャリブレーションコンセプト」で説明します。
B） PCにファイルとしてパラメーターを保存する
より一般的な方法は、PCにパラメーターを保存することです。すべてのパラメーター（またはそのサブセッ ト）がファイルとして保存されます。この場合、さまざまなフォーマットで保存できます。一番簡単なのは ASCIIテキストファイルで保存することです。この場合、オブジェクト名とその値のみが保持されます。他の フォーマットでは、パラメーターの完成度や変更履歴についてのコメントなど、その他の情報も保存できます。
[ある想定ケース]
キャリブレーションを担当するエンジニアも、業務終了後には自由な時間を楽しみたいものです。そこで、
ECUのRAM内の変更箇所をパラメーター設定ファイルとしてPCに保存しておきます。そして翌日に中 断した箇所から作業を続けたいとしましょう。ECUを起動すると、起動時にRAM内でパラメーターが初 期化されます。しかし、ECUはこれをフラッシュ内に保存されている値を使用して行います。つまり、前 日の変更はもうECU内に保存されていないということです。そこで、前日に中断した箇所から作業を続け るには、パラメーター設定ファイルの内容をXCPのDOWNLOADコマンドを使用して、ECUのRAM に転送します。
図15：パラメーター設定ファイルをECUのRAMへの転送
HEXファイル内へのパラメーター設定ファイルの保存とフラッシュ書込み
ECUのフラッシュ書込みも、フラッシュ内でパラメーターを変更するもう1つの方法です。この場合、
パラメーターはECUが起動する際に新規パラメーターとしてRAMに書き込まれます。パラメーター設 定ファイルはCファイルまたはHファイルに転送し、別のコンパイラー／リンカー実行時に新しいフラッ シュファイルに変更することができます。しかし、コードのパラメーターによっては、フラッシュ可能な HEXファイルの生成プロセスには非常に時間がかかることがあります。また、作業プロセスによっては キャリブレーション担当者が一切ECUソースコードを持っていないこともあります。この場合、キャリ ブレーション担当者がこの方法を使うことはできなくなります。
代替手段として、キャリブレーション担当者はパラメーター設定ファイルを既存のフラッシュファイルに コピーすることができます。
図16： 16進Window
フラッシュファイル内には、アドレスと値を両方含むHEXファイルがあります。ここでは、パラメーター ファイルをHEXファイルにコピーすることができます。これを行うため、CANapeがアドレスと値を パラメーター設定ファイルから取得し、そのパラメーター値をHEXファイル内の該当位置で更新します。
これによって新しいHEXファイルが作成され、変更したパラメーター値が保持されます。しかし、この HEXファイルをフラッシュ可能なファイルにするには、おそらく更なる手順を踏まなければなりません。
ここで再発する問題として考えられる1つに、チェックサムがあります。ECUは、データを正しく受信 していることを判断するためにチェックサムを確認します。フラッシュ可能なファイルが存在する場合、
ECU内にフラッシュすることが可能で、再起動後、新しいパラメーター値がECU内で利用可能になり ます。
1.3 DTO の交換 – 同期データ交換
図8で図示したとおり、DTO （Data Transfer Objects、データ転送オブジェクト）は同期された測 定／キャリブレーションデータの交換に利用可能です。スレーブからのデータは、DAQによって内部イ ベントに同期し、マスターに送信されます。この通信は以下の2つのフェーズに分けられます。
初期フェーズでは、スレーブがさまざまなイベントに対してどのデータを送信すべきかをマスターがス レーブに対して通信します。次のフェーズで、マスターがスレーブ内の測定を開始し、実際の測定フェー ズが開始します。この時間ポイントから、スレーブはマスターに必要なデータを送信し、マスターはス レーブに「 測定停止」を送信するまでの間だけ、スレーブの受信を継続します。測定データ取得と送信の 開始は、ECU内のイベントによって制御されます。
33 1.3 DTOの交換 – 同期データ交換
マスターはSTIMによってスレーブにデータを送信します。この通信は以下の2つのフェーズで構成されます。
初期化フェーズでは、マスターがどのデータを送信するかをスレーブと通信します。次のフェーズで、マス ターはスレーブにデータを送信し、STIMプロセッサーがデータを保存します。関連するSTIMイベントが起 動すると、データは直ちにアプリケーションメモリーへ転送されます。
1.3.1 測定方法：ポーリングとDAQ
イベント同期され、関連づけられたデータをスレーブから測定する方法を説明する前に、ポーリングと呼ば れる別の測定方法について簡単に説明します。これはDTOベースではなく、CTOベースです。本来なら この内容は別の章で説明すべきですが、ポーリングの説明はDTOベースの測定の必要性を非常に分かりや すく理解させてくれるため、本題からは少し逸れますが、理にかなっているといえるでしょう。
マスターはSHORT_UPLOADコマンドを使用して、スレーブからの測定パラメーターの値を要求できます。
これがポーリングと呼ばれるものです。測定のもっとも簡単なケースで、つまり、SHORT_UPLOADコマ ンドが受信され、実行された時点で、測定パラメーターの測定値を送信するということです。
以下の例では、測定パラメーター「Triangle」がスレーブから測定されます。
図17：
A2Lファイルからの パラメーター 「Triangle」の アドレス情報
アドレス「0x60483」は、CANフレーム内で5バイト（1バイトがアドレス拡張、4バイトが実際のアドレ ス）でアドレスとして表現されます。
