XCP - ECU 開発用標準プロトコル 基礎と応用分野 Andreas Patzer, Rainer Zaiser Andreas Patzer | Rainer Zaiser XCP – The Standard Protocol for ECU Development 2014 年 9 月 ベクター・ジャパン株式会社（〒 140-0002 東京都品川区東品川 2-2-20 天王洲郵船ビル 16F； 〒 460-0008 愛知県名古屋市中区栄 4-5-3 KDX 名古屋栄ビル 9F ）の明示的な許可がある場合を除き、 掲載内容の無断複写・転載を禁じます。 本書は個人で使用することを前提としており、技術用途または販売用途には使用できません。 また 、いかなる形態であっても契約の根拠として使用することを禁止します。 本書に記載のすべての情報は最大限の注意を払って編集されていますが 、ベクター・ジャパン株式会社は 記載されている情報の正確性について、いかなる場合でも保証または補償する責任を負いません。 ベクター・ジャパン株式会社は法規により責任を負うことが規定されていない限り、 悪意または重過失のある場合を除き、賠償責任を負いません。 本書に記載の情報は著作権または特許権 、あるいはその両方により保護されます。 本書で使用されるソフトウェア、ハードウェア、その他の製品名は商標登録されたブランドであるか、 そうでない場合は 、商標登録されたブランドとして特定されるかどうかにかかわらず、 それ以外の方法で商標登録に関する法律によって保護されます。 ©2014 ベクター・ジャパン株式会社 XCP - ECU 開発用標準プロトコル 基礎と応用分野 Andreas Patzer, Rainer Zaiser 目次 はじめに 7 ■ 1 XCPプロトコルの基礎 12 ■ 1.1 XCPプロトコルレイヤー 1.1.1 識別フィールド 1.1.2 タイムスタンプ 1.1.3 データフィールド 17 ■ 19 ■ 19 ■ 20 ■ 1.2 CTOの交換 1.2.1 XCPコマンドの構造 1.2.2 CMD 1.2.3 RES 1.2.4 ERR 1.2.5 EV 1.2.6 SERV 1.2.7 スレーブ内のパラメーターのキャリブレーション 20 ■ 20 ■ 23 ■ 26 ■ 26 ■ 26 ■ 27 ■ 27 ■ 1.3 DTOの交換 – 同期データ交換 1.3.1 測定方法：ポーリングとDAQ 1.3.2 DAQ測定方法 1.3.3 STIMキャリブレーション方法 1.3.4 DAQとSTIMに対するXCPパケットアドレス指定 1.3.5 バイパス = DAQ + STIM 30 ■ 31 ■ 32 ■ 39 ■ 40 ■ 42 ■ 1.4 XCPトランスポートレイヤー 1.4.1 CAN 1.4.2 CAN FD 1.4.3 FlexRay 1.4.4 Ethernet 1.4.5 SxI 1.4.6 USB 1.4.7 LIN 43 ■ 43 ■ 46 ■ 48 ■ 51 ■ 53 ■ 53 ■ 53 ■ 1.5 54 ■ 54 ■ 56 ■ 56 ■ 58 ■ 59 ■ 60 ■ 61 ■ XCPサービス 1.5.1 メモリーページスワッピング 1.5.2 メモリーページの保存 – データページ凍結 1.5.3 フラッシュプログラミング 1.5.4 スレーブの自動検出 1.5.5 アップロード、ダウンロード、フラッシュ書込みのためのブロック転送モード 1.5.6 コールドスタート測定（起動中の測定の開始） 1.5.7 XCPによるセキュリティーメカニズム 2 ECU記述ファイルA2L 62 ■ 2.1 64 ■ 66 ■ 67 ■ XCPスレーブのためのA2Lファイルのセットアップ 2.2 A2Lファイルの手動作成 2.3 A2LコンテンツとECU実装の対比 3 キャリブレーションコンセプト 68 ■ 3.1 フラッシュ内のパラメーター AUTOSARによるRAMポインターベースキャリブレーションコンセプト 3.5.1 シングルポインターコンセプト 3.5.2 ダブルポインターコンセプト 3.6 フラッシュポインターベースのキャリブレーションコンセプト 68 ■ 70 ■ 72 ■ 73 ■ 74 ■ 74 ■ 76 ■ 77 ■ 4 XCPの応用分野 78 ■ 4.1 MIL: Model in the Loop 4.2 SIL: Software in the Loop 4.3 HIL: Hardware in the Loop 4.4 RCP: ラピッドコントロールプロトタイピング 4.5 バイパス 4.6 バーチャルECUによる繰り返しサイクルの短縮 79 ■ 80 ■ 81 ■ 83 ■ 84 ■ 87 ■ 5 XCPの実装例 90 ■ 5.1 関数の説明 92 ■ 94 ■ 3.2 RAM内のパラメーター 3.3 フラッシュオーバーレイ 3.4 動的フラッシュオーバーレイの割り当て 3.5 5.2 ドライバーのパラメーター化 執筆者 略語と頭字語 参考文献 Webアドレス 図の目次 付録 - ベクターのXCPソリューション アルファベット順索引 96 ■ 98 ■ 99 ■ 99 ■ 100 ■ 102 ■ 104 ■ はじめに はじめに 電子制御 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 などの開発環境内でモデルとして実行されている場合 、開発者が自分のアプリケーションにも中 間結果を取得することができれば 、他の変更についての検証結果を取得するのに役立ちます。最終的な解 析において 、この方式はパラメーターへの読込みアクセスだけを可能にすることで 、パラメーターの視覚化 7 はじめに 8 と解析ができるようにします。これはすべて 、モデルの実行時 、または遡って時限付テストランの完了後に 行われます。PID コントローラーの比例要素を変更し、アルゴリズムの挙動を制御中のシステムに合わせる 場合など、パラメーター化が変更された場合は書込みアクセスが必要です。開発者がアプリケーションを実 行する場所に関係なく、アルゴリズムプロセスとパラメーター化への変更による最適化についての詳細な解 析に常に重点が置かれます。 これは次のようにして実現されます。 アルゴリズムは、実行可能な形式（ コードまたはモデル記述）なら どのような形でも存在することができます。 ランタイム環境としてさまざまなシステムを使用できます （ Simulink 、PC の DLL 、高速プロトコル通信プラットフォーム、ECU など）。プロセスフローは、データへの 読込みアクセスとタイムベースフローの取得によって解析されます。パラメーターセットは繰り返し変更さ れ 、アルゴリズムが最適化されます。データの取得は外部 PC ベースツールに外部化することができますが 、 説明を簡単にするために、ここではランタイム環境自体に解析機能を持たせることができると考えます。 Runtime Environment PC Tool Communication Application Operating System 図1： ランタイム環境での 基本的な通信 ランタイム環境の種類と通信の形式は通常大きく異なります。その理由は、ランタイム環境を作成するメー カーが異なり、異なるソリューションの手法を使用しているからです。プロトコル、コンフィギュレーション、 測定データフォーマットなどの種類が異なっており、すべての開発ステップにおいて 、パラメーターセットと 結果を交換しようとしてもうまくいきません。しかし、最終的にはこれらのソリューションをすべて減らし、実 行時の読込み / 書込みアクセスを行うことができます。そして 、これに対する標準規格が XCP なのです。 XCP は ASAM の標準規格で 、バージョン 1.0 は 2003 年にリリースされました。ASAM は、Association for Standardisation of Automation and Measuring Systems の略で 、自動化と測定システムの標準化のため の組織として設立されました。サプライヤー、車両メーカー、ツールメーカーは、ASAM ワーキンググループ に参加しています。XCP ワーキンググループの目的は、特定のデータ伝送媒体に依存しないで使用すること ができる汎用化された測定 / キャリブレーションプロトコルを定義することです。CCP（ CAN キャリブレーショ ンプロトコル）による作業の結果得られた経験も開発に活かされました。 XCP は、ASAM インターフェイスモデルをベースに定義されました。図 2 は、XCP スレーブ、記述ファイルへの 測定 / キャリブレーションツールの各インターフェイスと、 より高いレベルの自動化システムへの接続を示して います。 はじめに 9 Upper Level Automation System ASAM MCD 3MC Measurement and Calibration System XCP Driver ASAM MCD 2MC *.a2L ECU Description File ASAM MCD 1MC XCP Driver ECU 図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 を理解するためには関係がないため 、このインターフェイスについてはこれ以 上本書では説明しません。 はじめに 10 XCP はマスター / スレーブ原理に基づいています。ECU がスレーブで 、測定 / キャリブレーションツールがマ スターです。スレーブは規定の時間内には 1 つのマスターとしか通信できませんが 、一方でマスターは複数 のスレーブと同時に通信できます。 Master Bus Slave Slave Slave Slave 図3： XCPマスターは複数のスレー ブと同時通信が可能 開発プロセス全体においてデータとコンフィギュレーションにアクセスできるようにするためには、XCP はあら ゆるランタイム環境内で使用されなければなりません。購入 、操作 、メンテナンスを必要とするツールがよ り少なくなれば 、1 つのツールから別のツールへコンフィギュレーションを手動コピー（エラーに繋がるプロセ ス）する必要もなくなります。これにより、反復ループが簡素化され 、その後の作業ステップの結果がそれ 以前の作業ステップにフィードバックして転送されます。 今 、私たちが留意しておきたいことは、現在何ができるかではなく、今後何ができるか ― つまり、何でも可 能になるかということでしょう。XCP ソリューションは、すでにさまざまな作業環境で使用されています。本 書の目的は、測定 / キャリブレーションプロトコルの主な特性について説明し、さまざまなランタイム環境で の使用法について紹介することです。ただし、本書では、XCP 全体の詳細な仕様や特定のランタイム環境に XCPドライバーを組み込むための具体的な指示は記載されていません。本書は、個別のプロトコルと実装の 詳細を説明するものではなく、その関係性についてを説明するものです。どのように実装するのかについ ては、付録に記載されているインターネットリンクから、公開されている利用可能な XCPドライバーのソース コードやサンプルの実装例をご参照くださればと思います。 本書に使用される PC ツールのスクリーンショットは、ベクターの提供する CANape 測定 / キャリブレーション ツールを使用して作成されました。A2L ファイルの作成方法や 、それ以外のプロセスフローも CANape を基 に説明しています。無料のデモバージョンはベクターの Web サイト（ www.vector-japan.co.jp ）内「 ダウン ロードセンター」よりダウンロード可能ですので 、ご利用ください。 はじめに 11 1 XCPプロトコルの基礎 12 1 XCPプロトコルの基礎 ASAM インターフェイスモデルのインターフェイス 1 は、スレーブとマスター間のコマンドとデータの送受信 を記述します。 特定の物理トランスポートレイヤーからの独立性を実現するために、XCP をプロトコルレイ ヤーとトランスポートレイヤーに細分化しました。 CAN Ethernet FlexRay SxI USB ... 図4：XCPプロトコルのプロトコルレイヤーとトランスポートレイヤーへの細分化 トランスポートレイヤーに応じて 、XCP on CAN や XCP on Ethernet と呼ばれています。新規トランスポートレ イヤーへの拡張性は、すでに 2005 年に XCP on FlexRay が登場したことで証明されました。XCP プロトコル の現行バージョンは 1.1 で 、2008 年に認証されました。 プロトコルの設計にあたっては、以下の原則に従うことが最優先となります。 > > > > > ECU 内のリソースは最小限の使用 効率的な通信 シンプルなスレーブ実装 パラメーターをごく少数に抑えたプラグ＆プレイコンフィギュレーション スケーラビリティー XCP の主機能は、スレーブのメモリーへの読込み／書込みアクセスを可能にすることです。 読込みアクセスにより、ユーザーが内部 ECU パラメーターの時間応答を測定することができます。ECU は個 別の時間挙動を持つシステムで 、そのパラメーターは特定の時間間隔（プロセッサーが値を再計算し、RAM 内で更新したとき）でしか変化しません。XCP の大きな特長の 1 つは、プロセスフローまたは ECU 内のイベン トに同期して変化する RAM からの測定値の取得にあります。これにより、ユーザーは ECU 内のタイムベース のプロセスフローと変化する値の間の直接的な関係を評価できます。これらはイベント同期測定値と呼ばれ ます。これに関連するメカニズムについては、後ほど詳しく説明します。 XCPプロトコルの基礎 13 書込みアクセスにより、ユーザーはスレーブ内のアルゴリズムのパラメーターを最適化できます。アクセス はアドレス指向で 、つまり、マスターとスレーブ間の通信がメモリー内のアドレスを参照します。このため 、 パラメーターの測定は、基本的に「 メモリー位置 0x1234 の値を要求する」といったマスターのスレーブへ の要求として実行されます。パラメーターのスレーブへのキャリブレーション ( 書込みアクセス ) は「 アドレ ス 0x9876 から 5 への値の設定を要求する」となります。 XCP スレーブは必ずしも ECU 内で使用される必要はありません。XCP は、モデルベース開発環境から Hardware-in-the-Loop (HIL) /Software-in-the-Loop (SIL) 環境 、JTAG 、NEXUS 、DAP などのデバッグイ ンターフェイスによる ECU メモリーへのアクセスに使用されるハードウェアインターフェイスまで 、さまざま な環境に実装できます。 Simulink Slave Slave XCP PC Master Slave Prototype or ECU Hardware Measurement/ Calibration Hardware* EXE/DLL Slave HIL/SIL Systems Slave * Debug Interfaces, Memory Emulator, ... 図5： XCPスレーブはさまざまな ランタイム環境で使用可能 ECU への読込み／書込みアクセスを使用してアルゴリズムを最適化する方法やメリットはどのようなもので しょうか。各パラメーターを ECU 内での実行時に変更できるようにするには、パラメーターへのアクセスが 必要です。すべての種類のメモリーでこのプロセスが可能なわけではなく、可能なのは RAM 内のメモリーア ドレスに読込み／書込みアクセスを実行することだけです（ここでは EEPROM は意図的に除外しています）。 以下に個々のメモリー技術間の差異を簡単に説明します。こうした差異を知ることは、本書の内容をさらに 深く理解するために大変重要です。 1 XCPプロトコルの基礎 14 メモリーの基礎 現在 、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 の読込み／書込みは簡単です。 実行時にパラメーターを変更する必要がある場合は、確実に RAM 内に配置しなければなりません。この事実 を理解することはきわめて重要です。そのため 、これから以下の例に基づき、ECU 内のアプリケーションの 実行について説明していきます。 1 XCPプロトコルの基礎 アプリケーション内では、 「 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 章）の内容を参照してください。 15 1 XCPプロトコルの基礎 16 XCP の基礎のまとめ メモリー内容への読込み／書込みアクセスには、XCP プロトコルのメカニズムを使用できます。アクセスはア ドレス指向で行われます。読込みアクセスにより RAM からのパラメーターの測定を行い 、書込みアクセスに より RAM 内のパラメーターのキャリブレーションを行うことができます。XCP は、ECU 内のイベントと同期し た測定の実行を許可します。これにより、測定値に相関性が与えられます。測定を再起動するたびに、測定 対象のシグナルを自由に選択できます。書込みアクセスの場合 、キャリブレーション対象のパラメーターは RAM に保存しなければなりません。これにはキャリブレーションコンセプトが必要です。 ここで 、次のような 2 つの重要な疑問が生じます。 > XCP プロトコルのユーザーが RAM 内の測定／キャリブレーションパラメーターの正しいアドレスを知る方法 は？ > キャリブレーションコンセプトとはどのような形式なのか？ 最初の疑問については、本書の第 2 章「 ECU 記述ファイル A2L 」に答えがあります。キャリブレーションコン セプトの内容は、第 3 章で取り扱います。 1.1 XCPプロトコルレイヤー 17 1.1 XCPプロトコルレイヤー 「 XCP メッセージフレー XCP データはマスターとスレーブ間ではメッセージベースの方式で交換されます。 ム」全体は、トランスポートレイヤーのフレーム内に埋め込まれます（ UDP パケット内の UDP による XCP on Ethernet の場合）。フレームは、XCP ヘッダー、XCP パケット、XCP テールの 3 つの部分に分かれています。 以下の図では、メッセージの一部が赤色で表示されています。これは現在の XCP フレームを送信するために 使用されます。XCP ヘッダーと XCP テールはトランスポートプロトコルに依存します。 XCP Message (Frame) XCP Packet XCP Header PID FILL DAQ Identification Field XCP Tail TIMESTAMP DATA Timestamp Field Data Field 図6： XCPパケット XCP パケット自体は使用されるトランスポートプロトコルに依存しません。これには必ず「 識別フィールド」、 「 タイムスタンプフィールド」、現在データのフィールドである「 データフィールド」の 3 つのコンフィギュレー ション要素が含まれています。各識別フィールドはパケット識別子（ PID ）で始まり、パケットを識別します。 以下の概要図は、すでに定義されている PID を示しています。 0xFF 0xFF 0xFE RES 0xFD EV 0xC0 0xFC SERV 0xBF 0xFB .... 0x00 図7：XCPパケット識別子（PID）の概要 CMD absolute or relative ODT number for STIM .... PID for frames from Slave to Master .... PID for frames from Master to Slave 0x00 ERR absolute or relative ODT number for STIM 1 XCPプロトコルの基礎 18 XCP パケットによる通信は、コマンド領域 (CTO) と同期データ送信領域 (DTO) に細分化されます。 XCP Master XCP Driver CTO CMD RES DTO ERR EV SERV Command / Response / Error / Event / Service Request Processor DAQ STIM DAQ Processor STIM Processor Bypass XCP Handler PGM CAL DAQ STIM Resources 図8： CTO/DTOを持つ XCP通信モデル XCP Slave ここで使用する略語： CMD コマンドパケット （ Command Packet ） コマンドを送信 RES コマンドレスポンスパケット （ Command Response Packet ） ポジティブレスポンス ERR エラー （ Error ） ネガティブレスポンス EV イベントパケット （ Event Packet ） 同期イベント SERV サービス要求パケット （ Service Request Packet ） サービス要求 DAQ データ取得 （ Data AcQuisition ） 定期間隔での測定値送信 STIM スティミュレーション （ Stimulation ） スレーブの一定間隔でのスティミュレーション コマンドは CTO（ Command Transfer Objects 、コマンドトランスファーオブジェクト）により交換されます。 たとえば 、マスターはこのようにしてコンタクトを開始します。スレーブは RES または ERR を伴う CMD には 必ず応答することになっています。その他の CTO メッセージは非同期で送信されます。DTO（ Data Transfer Objects 、データトランスファーオブジェクト）は、同期測定／スティミュレーションデータを交換するために 使用されます。 1.1 XCPプロトコルレイヤー 19 1.1.1 識別フィールド XCP Packet PID FILL DAQ TIMESTAMP DATA 図9： Identification Field メッセージ識別 メッセージを交換する際は、マスターとスレーブの両方がお互いにメッセージを送信した側を判断できるよう にしなければなりません。これは識別フィールドで行います。そのため 、各メッセージの頭に 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 タイムスタンプ XCP Packet PID FILL DAQ TIMESTAMP DATA 図10： タイムスタンプ DTO パケットはタイムスタンプを使用しますが 、CTO メッセージの送信時には使用できません。スレーブはタ イムスタンプを使用して 、時間情報に測定値を付加します。すなわち 、マスターには測定値だけでなく、測 定値が取得された時点も送信されるということです。測定値と時点の関係はスレーブから直接送信されるた め 、マスターに測定値が到着するまでの時間の長さは重要ではなくなります。 スレーブからのタイムスタンプの送信はオプションです。この内容についての詳細は、「 ASAM XCP パート 2 プロトコルレイヤー仕様（ ASAM XCP Part 2 Protocol Layer Specification ）」で説明されています。 1 XCPプロトコルの基礎 20 1.1.3 データフィールド XCP Packet PID FILL DAQ TIMESTAMP DATA Data Field 図11： XCPパケット内の データフィールド 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 ） 各コマンドには一意の番号が割り当てられます。さらに、その他の特定のパラメーターをコマンドと共に送信 できます。この場合 、パラメーターの最大数は MAX_CTO-1 として定義します。MAX_CTO は CTO パケットの 最大長を示します（単位：バイト）。 ポジティブレスポンス： 位置 タイプ 説明 0 バイト（ BYTE ） コマンドポジティブレスポンスパケットコード = RES 0xFF （ Command Positive Response Packet ） 1..MAX_CTO-1 バイト（ BYTE ） コマンド専用パラメーター （ Command specific Parameters ） 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 ） 21 1 XCPプロトコルの基礎 22 スレーブのポジティブレスポンスは、もう少し拡張した形式を含めることができます。スレーブは接続を行う 際 、マスターにすでに通信専用情報を送信しています。たとえば 、RESOURCE は、その機能をページスイッ チングとしてサポートするかどうか 、または XCP 上でフラッシュ動作が可能かどうかについて 、スレーブによっ て与えられる情報です。スレーブは MAX_DTO を使用して 、マスターに測定値などの転送のために、スレー ブがサポートする最大パケット長を通知します。パラメーターの詳細については、「 ASAM XCP パート 2 プロ トコルレイヤー仕様」で説明されています。 マスターとスレーブ間でコマンドと応答を交換するために、XCP は「 標準」、 「 ブロック」、 「 インターリーブ」 の 3 つの異なるモードを許可します。 Standard Mode Master Block Mode Interleaved Mode Slave Master Slave Master Request k Part1 Request k Part2 Part3 Slave Request k MIN_ST Request k+1 MAX_BS Response k Response k Response k Request k+1 Request k+1 Response k+1 Response k+1 Part1 Response k+1 Part2 Part3 Time Time Time 図12：XCPプロトコルのモードは、 「標準」、 「ブロック」、 「インターリーブ」の3つ 標準通信モデルでは、スレーブへの各要求の後に単一レスポンスが続きます。XCP on CAN を除き、複数の スレーブがマスターからの 1 つのコマンドに応答することは許可されません。したがって 、各 XCP メッセージ は常に一意のスレーブへ追跡可能です。このモードは通信において標準的なケースです。 ブロック転送モードはオプションで 、大量のデータ転送時には転送時間の短縮が可能です ( アップロードまた はダウンロード動作時など ) 。この場合でも 、このモードではスレーブ方向のパフォーマンス問題を考慮しな ければなりません。したがって 、2 つのコマンド間の最低時間（ MIN_ST ）を維持し、コマンドの合計数を上 限値（ MAX_BS ）に制限しなければなりません。オプションで 、マスターが GET_COMM_MODE_INFO を使 用してスレーブからこれらの通信設定を読み出すことができます。マスター方向でのブロック転送モードで は前述の制限を守る必要はありません。それは PC が常にマイクロコントローラーからのデータを受けるため に充分な性能を備えているためです。 パフォーマンス上の理由からインターリーブモードも提供されます。しかし、この方式もオプションであり、 ブロック転送モードとは違い 、実務的には妥当ではありません。 1.2 CTOの交換 23 1.2.2 CMD XCP CTO Packet PID Identification Field Timestamp Field empty for CTO DATA Data Field 図13：CTOパケット構造の概要 マスターは CMD により、スレーブに一般要求を送信します。PID フィールドにはそのコマンドの識別番号が含 まれます。追加詳細パラメーターはデータフィールドで伝送されます。次に、マスターは「 RESponse（レス ポンス）」または「 ERRor（エラー）」形式でのスレーブの応答を待ちます。 XCP はその実装においても非常にスケーラブルであるため 、すべてのコマンドを実装する必要はありません。 A2L ファイルでは、利用可能な CMD は XCP IF_DATA という名前の場所に記載されています。A2L ファイルの 定義とスレーブ内の実装に差異がある場合 、マスターはスレーブの応答に基づき、スレーブがそのコマンド に対応さえしていないと判断できます。マスターがスレーブ内に実装されていないコマンドを送信した場合 、 スレーブは ERR_CMD_UNKNOWN を返し、スレーブ内ではそれ以上の動作は開始されません。これによって マスターは、オプションコマンドがスレーブに実装されていないことを短時間で認識することができます。 コマンド内にはその他のパラメーターもいくつか含まれています。正確な詳細については「 ASAM XCP パー ト 2 プロトコルレイヤー仕様」を参照してください。 コマンドは、標準 、キャリブレーション、ページ、プログラミング、DAQ 測定コマンドの各グループに分類され ています。あるグループをまったく必要としない場合 、そのコマンドは実装する必要がありません。そのグ ループが必要な場合 、一部のコマンドは必ずスレーブ内で利用可能である必要がありますが 、そのグループ 内の他のコマンドはオプションです。 1 XCPプロトコルの基礎 24 以下の概要は一例です。ページスイッチンググループの SET_CAL_PAGE と GET_CAL_PAGE コマンドは、オプ ションでないと識別されます。これはページスイッチングをサポートする XCP スレーブ内では、最低これらの 2 つのコマンドを実装しなければならないということです。スレーブ内でページスイッチングサポートが必要と されない場合は、 これらのコマンドを実装する必要はありません。同じことが他のコマンドにも当てはまります。 標準コマンド： コマンド PID オプション CONNECT 0xFF × DISCONNECT 0xFE × GET_STATUS 0xFD × 0xFC × SYNCH 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 0xE4v ○ 1.2 CTOの交換 25 定期データ交換 - ベーシック： コマンド 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 XCPプロトコルの基礎 26 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 プロトコルレイヤー仕様」に記載されています。 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 プロトコルレイヤー仕様」をご参照ください。 1.2 CTOの交換 イベントについては、測定とスティミュレーション関連のところでさらに詳しく説明していきます。これは 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 つのメッセージが交換されます。 27 1 XCPプロトコルの基礎 28 以下の図は、マスターとスレーブ間の通信を示しています。これはパラメーター値の設定に必要です。実際 のメッセージは封筒アイコンが表示されている行にあります。メッセージの内容は、マウスで「 拡張」すると 表示されます。 図14：キャリブレーションプロセスからの追跡例 マスターの最初のメッセージ（図 14 のグレー表示部分）では、マスターはコマンド SET_MTA を新規の値を 書き込むべきアドレスと共にスレーブに送信します。 2 番目のメッセージでは、スレーブがそのコマンドに Ok:SET_MTA で肯定確認を返します。 3 番目のメッセージ DOWNLOAD は、16 進値と有効なバイト数を送信します。この例では、値のため有効なバ イト数は 4 です。スレーブは 4 番目のメッセージでさらに肯定確認を返します。 これで 、現在のキャリブレーションプロセスが完了します。トレース表示で SHORT_UPLOAD の終了を確認で きます。これはベクターが提供する測定／キャリブレーションツール「 CANape 」の特長です。キャリブレー ションが完全に実行されたことを確認するため 、プロセス後にこの値が再度読み出され 、表示が読み出し値 で更新されます。これにより、ユーザーはキャリブレーションコマンドが実行されたかどうかを直接確認でき ます。このコマンドは、Ok:SHORT_UPLOAD で肯定確認も取得します。 ECU の RAM 内でパラメーターが変化すると、アプリケーションは新規の値を処理します。しかし、ECU を再 起動すると値は消去され 、フラッシュからのオリジナル値で RAM 内の値を上書きします（本書の第 3 章「 キャ リブレーションコンセプト」を参照）。では、変更したパラメーターセットを恒久的に保存するにはどうすれば よいのでしょうか ? 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への転送 29 1 XCPプロトコルの基礎 30 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 内の イベントによって制御されます。 1.3 DTOの交換 – 同期データ交換 31 マスターは STIM によってスレーブにデータを送信します。この通信は以下の 2 つのフェーズで構成されます。 初期化フェーズでは、マスターがどのデータを送信するかをスレーブと通信します。次のフェーズで 、マス ターはスレーブにデータを送信し、STIM プロセッサーがデータを保存します。関連する STIM イベントが起動 すると、データは直ちにアプリケーションメモリーへ転送されます。 1.3.1 測定方法：ポーリングとDAQ イベント同期され 、関連づけられたデータをスレーブから測定する方法を説明する前に、ポーリングと呼ばれ る別の測定方法について簡単に説明します。これは DTO ベースではなく、CTO ベースです。本来ならこの内 容は別の章で説明すべきですが 、ポーリングの説明は DTO ベースの測定の必要性を非常に分かりやすく理解 させてくれるため 、本題からは少し逸れますが 、理にかなっているといえるでしょう。 マスターは SHORT_UPLOAD コマンドを使用して 、スレーブからの測定パラメーターの値を要求できます。 これがポーリングと呼ばれるものです。測定のもっとも簡単なケースで 、つまり、SHORT_UPLOAD コマンド が受信され 、実行された時点で 、測定パラメーターの測定値を送信するということです。 以下の例では、測定パラメーター「 Triangle 」がスレーブから測定されます。 図17： A2Lファイルからの パラメーター「 Triangle」の アドレス情報 アドレス「0x60483 」は、CAN フレーム内で 5 バイト（1 バイトがアドレス拡張 、4 バイトが実際のアドレス）で アドレスとして表現されます。 図18：CANapeトレースWindow内でのポーリング通信 1 XCPプロトコルの基礎 32 XCP 仕様は、「 各測定パラメーターの値は個別にポーリングされなければならない 」というポーリングの要件 を規定します。ポーリングによって測定すべき各値に対して 、2 つのメッセージ（ マスターのスレーブへの要 求およびスレーブのマスターへのレスポンス）がバス上を通過することになります。 これでバスへの負荷が加わることに加え、ポーリング方法には別のデメリットがあります。複数のデータ値を ポーリングする場合 、ユーザーは通常データをお互いに関連づけたいと考えます。しかし、ポーリングで連 続して測定される複数の値は、必ずしもお互いに関連づけられた状態で存在しない 、すなわち 、同一の ECU の計算サイクルからのデータではない可能性があるということです。 これが 、ポーリングが測定にあまり向かない理由です。ポーリングは不必要に高いデータトラフィックを生じ させ 、測定値が ECU 内のプロセスフローに関連して評価されることがないためです。 したがって 、2 つの課題を解決すれば 、最適化された測定を行うことができます。 > 測定中の帯域の最適化 > データ関連づけの確保 この課題は、すでに説明した DAQ 方法で処理することができます。DAQ はデータ取得の略で 、スレーブから マスターへ DTO を送信することで実装できます。 1.3.2 DAQ 測定方法 DAQ 方法は以下のようにポーリングの 2 つの問題を解決します。 > 測定値の関連づけは、ECU 内のイベントと測定値の取得をリンクさせることで実現します。測定値は、す べての計算が完了したと確認されるまで取得 、転送されません。 > バス負荷を低減するには、測定プロセスを次の 2 つのフェーズに分けます。コンフィギュレーションフェー ズでは、マスターはどの値に関心があるかをスレーブに伝え、第 2 フェーズでは、スレーブからマスターへ の測定値の転送のみを行います。 1.3 DTOの交換 – 同期データ交換 33 それでは、ECU 内のプロセスに測定値の取得をリンクさせる方法はどのようなものでしょうか ? 図 19 は、ECU 内の計算サイクルとパラメーター X および Y における変化の関係について示しています。 Calculation cycle n X 10 8 6 4 2 0 Y 10 8 6 4 2 0 Calculation cycle n+1 E1 Read sensor X Calculation cycle n+2 E1 Calculate Y = X time E1 図19： ECU内のイベント それでは ECU 内のシーケンスを見ていきましょう。イベント E1（ = 計算サイクルの終了）に達したときには、 すべてのパラメーターが取得され 、計算が完了しています。これは、すべての値がお互いに組み合わされ 、 この時点で関連づけられていなければならないということで 、イベント同期の測定方法を使用しているという ことになります。これは、DAQ メカニズムを利用して実装されているものとまったく同じです。スレーブ内の アルゴリズムが「 計算サイクル完了」イベントに達すると、XCP スレーブが測定パラメーターの値を収集し、 バッファーに保存してマスターに送信します。このことから、スレーブがどのイベントに対してどのパラメー ターを測定すべきか知っているということが推測できます。 イベントは完全に周期的なものである必要はありません。たとえばエンジンコントローラーの場合 、角度同 期であることもあります。この場合 、2 つのイベント間の時間間隔はエンジン回転数 (rpm) によって変化しま す。ドライバーのスイッチ操作など単動のイベントも 、決して時間的に等間隔ではないイベントです。 ユーザーがシグナルを選択します。実際の測定オブジェクトの他に、ユーザーは測定パラメーターに対して 潜在的なイベントを選択しなければなりません。イベントとイベントに対する測定オブジェクトの実行可能な 割り当ては、A2L ファイルに保存しなければなりません。 図20： A2L内のイベント定義 1 XCPプロトコルの基礎 34 通常は、測定値を複数のイベントに同時に割り当てられるようにすることには意味がありません。通常 、パラ メーターは単一のサイクル（例：10ms 間隔のみ ）で変更されるだけであり、複数のサイクル（例：10ms と 100ms 間隔）では変更されません。 図21： A2L内の可能性のある イベントへの「Triangle」の 割り当て 図 21 は、「 Triangle 」パラメーターが原則として 、1ms 、10ms 、100ms イベントで測定される場合があるこ とを示しています。デフォルト設定は 10ms です。 測定パラメーターは 、測定コンフィギュレーション中にユーザーによって ECU 内のイベントに割り当てられ ます。 図22： 各測定パラメーターに対する イベント（測定モード）の選択 測定されたシグナルのコンフィギュレーション後 、ユーザーが測定を開始します。XCP マスターは 、DAQ リ ストと呼ばれるリストの中で必要な測定パラメーターをリスト化します。これらのリストの中で 、測定され たシグナルがそれぞれ選択されたイベントに割り当てられます。このコンフィギュレーション情報がスレー ブに送信されてから 、実際の測定が開始されます。 次に 、イベントが発生した場合に読み出し、送信すべ きアドレスはどれであるかをスレーブが理解します。このように測定をコンフィギュレーションフェーズと測 定フェーズへ分けることについては 、この章の冒頭ですでに説明しています。 これにより、ポーリング時に発生する 2 つの問題を解決できます。 測定中にマスターがそれぞれの値を 個別にポーリングする必要がなくなり、測定値がお互いに関連づけられ 、帯域が最適に使用されます。 1.3 DTOの交換 – 同期データ交換 図23：DAQ測定のCANapeトレースWindowからの抜粋 図 23 は 、マスターとスレーブ間のコマンド／レスポンス通信（色の付いた部分）の例を示しています （大体においてこれより大幅に多く、ここではスペースの関係で一部しか表示されていません ）。これは DAQ コンフィギュレーションのスレーブへの送信に関連しています。 その後 、測定が起動され 、マスター が受信待機している間にスレーブが要求値を送信します。 これまで 、シグナルの選択について 、その名前と測定イベントへの割り当てに基づいて説明してきまし た。しかし、正確にはどのようにコンフィギュレーションは XCP スレーブに転送されるのでしょうか？ ECU 内のメモリー構造の観点から問題を見ていきましょう。 ユーザーがシグナルを選択し、それを測定 したいと考えています。 シグナル値を送信するためにメッセージ全体を使用しなくても済むように 、ス レーブからのシグナルはメッセージパケットに結合されます。 スレーブがこの結合の定義を独自に作成 することはありません。 そうでなければ 、マスターがメッセージを受信したときにデータの解釈ができな くなってしまいます。したがって 、スレーブは値をメッセージにどのように配分すべきかを記述した指示 データをマスターから受信します。 スレーブがバイトデータをメッセージに組み立てる際のシーケンスは 、オブジェクト記述テーブル ODT （ Object Description Table ）という名称で定義されます。アドレスとオブジェクト長は 、測定オブジェク トを一意に識別するために重要なものです。ODT は 、スレーブからの RAM 内容の割り当てを提供し、 バス上のメッセージを組み立てます。通信モデルに応じて 、このメッセージは DAQ DTO として送信されます。 35 1 XCPプロトコルの基礎 36 RAM Cells ODT address, length address, length address, length address, length ... 0 1 2 3 PID 0 1 2 3 ... 図24： ODT：DAQ DTOへの RAMアドレスの割り当て さらに正確に言えば 、ODT リスト内のエントリー項目はアドレスとオブジェクト長によって RAM 内のメモリー 領域を参照します。 測定開始コマンドの受信後 、任意の時点で測定に関連するイベントが発生します。XCP スレーブはデータ取 得を開始します。XCP スレーブは個々のオブジェクトをパケットに結合し、バス上で送信します。マスターは そのバスメッセージを読み取り、個々のデータの解釈を行うことができます。これは 、パケット自体への個々 のオブジェクトの割り当てがすでに定義されており、関係が分かっているためです。 しかし、各パケットには使用可能な最大バイト数があり、これは使用している伝送媒体によって異なります。 CAN の場合 、これは合計 7 バイトです。それ以上のデータを測定する必要のある場合は 、ODT では足りなく なります。 2 つ以上の ODT を使用して測定値を送信する必要がある場合は 、スレーブがデータを正しい ODT にコピーし、マスターが受信した ODT を一意に識別できなければなりません。ECU の測定間隔を複数使用 する場合は 、ODT と測定間隔の間の関係も一意に識別可能でなければなりません。 1.3 DTOの交換 – 同期データ交換 37 ODT は XCP プロトコル内の DAQ リストに結合されます。各 DAQ リストには複数の ODT が含まれており、イベ ントに割り当てられています。 ODT #2 0 address, length ODT #1 ODT #0 0 1 2 3 1 address, length 0 address, length 2 address, length 1 address, length address, length 3 address, 2 address, lengthlength address, length ... 3 address, length address, length ... address, length ... PID=2 0 PID=1 0 PID=0 0 1 1 2 1 2 3 2 3 3 ... ... ... 図25： 3つのODTを持つDAQリスト たとえば 、そのユーザーが 2 つの測定間隔（＝ ECU 内の 2 つの異なるイベント）を使用する場合は 、DAQ リ ストも 2 つ使用されます。使用するイベントごとに 1 つの DAQ リストが必要です。各 DAQ リストには ODT に 関するエントリー項目が含まれており、各 ODT には RAM セル内の値への参照が含まれています。 「 定義済み 」、 「 動的」の 3 つのタイプに分けられます。 DAQ リストは「 静的」、 静的 DAQ リスト： DAQ リストと ODT テーブルが通常どおり CCP から常時 ECU 内で定義される場合 、静的 DAQ リストとして参照 されます。ODT リスト内に存在する測定パラメーターの定義はなく、書き込むことのできるフレームワーク のみがあります（比較には 、定義済みの DAQ リストを参照）。 静的 DAQ リストでは 、この定義は ECU コード内に設定され 、A2L に記述されます。図 26 は 、その中に静的 DAQ リストが定義されている A2L の抜粋です。 図26： 静的DAQリスト 上記の例では 、番号「0 」の DAQ リストの場合 、10ms のイベントに割り当てられ 、最大 2 つの ODT を持つこ とができます。番号「1 」の DAQ リストには 4 つの ODT があり、100ms イベントにリンクされています。 1 XCPプロトコルの基礎 38 A2L は ECU のデータコンテンツを組み合わせます。静的 DAQ リストの場合 、それぞれに含まれる DAQ リスト と ODT リストの数は 、ECU へアプリケーションをダウンロードすることにより定義されます。この場合 、ユー ザーがあるイベントによるシグナルを 、割り当てられた DAQ リストに設定された数よりも多く測定しようとし た場合 、ECU 内のスレーブは要求を満たすことができず 、コンフィギュレーション試行はエラーで終了しま す。もう一方の DAQ リストがまだ完全に利用可能であり、まだ実際に送信能力があるかどうかは関係ありま せん。 定義済み DAQ リスト： 完全に定義済みの DAQ リストは 、ECU 内でもセットアップ可能です。しかし、この方法はユーザーにとって 自由度がないため 、実際に ECU 内で使用されることはほとんどありません。システムのデータ送信を XCP で行うアナログ測定システムの場合は違います。この場合 、自由度は必要ありません。それは測定システ ムの物理的構造が製品寿命の終わりまで変わらないためです。 動的 DAQ リスト : XCP プロトコルの特徴は 、動的 DAQ リストです。ここでは 、ECU コード内で恒久的に定義される DAQ リスト と ODT リストの絶対的なパラメーターではなく、単に DAQ リストに対して使用することのできるメモリー領 域のパラメーターです。DAQ リストをまとめる際の測定ツールの自由度が高いことがメリットで 、DAQ リスト の構造を動的に管理できます。 スレーブ内の DAQ リストの構造を定義するためにマスターが使用できる ALLOC_ODT など、この動的な管理 専用に設計されたさまざまな機能は XCP 内で利用可能です。 MIN_DAQ + DAQ_COUNT DAQ1 DAQ0 AQ _D OC ALL ALLOC_OD T_ENTRY ALLOC_ODT ODT_ENTERIES_COUNT GRANULARITY_ODT_ENTRY_SIZE_DAQ ODT_COUNT 図27： 動的DAQリスト DAQ リストをまとめる際には 、動的または静的 DAQ リストが使用されているかどうか 、DAQ リストのパラメー ターと構造の見かけはどうかなどを 、マスターが識別できなければなりません。 1.3 DTOの交換 – 同期データ交換 1.3.3 STIMキャリブレーション方法 XCP キャリブレーション方法については 、CTO 交換についての章ですでに紹介しました。このタイプのキャリ ブレーションはすべての XCPドライバーに存在し、ECU 内のオブジェクトをキャリブレートするための基礎を 形成しています。しかし、キャリブレーションコマンドの送信と ECU 内のイベント間には同期が存在しません。 これとは逆に、STIM の使用は CTO の交換をベースにしておらず 、スレーブ内のイベントに同期される通信に よる DTO の使用をベースにしています。したがって 、マスターは 、まったく同期ができないのはスレーブ内 のどのイベントであるかを認識しなければなりません。この情報も A2L 内に存在する必要があります。 図28：DAQとSTIMに対するイベント マスターが STIM によってスレーブにデータを送信する場合 、XCP スレーブにはキャリブレーションパラメー ターを見つけることのできるパケット内の位置が通知されなければなりません。この場合 、DAQ リストに対 して使用されるものと同じメカニズムが使用されます。 39 1 XCPプロトコルの基礎 40 1.3.4 DAQとSTIMに対するXCPパケットアドレス指定 XCP パケットのアドレス指定については 、この章の最初ですでに説明しました。そして 、DAQ 、ODT 、STIM の コンセプトについては紹介しましたので 、ここで XCP パケットアドレス指定について詳しく説明していきます。 CTO の送信中 、パケットを一意に識別するためには PID を使用するだけで充分ですが 、測定値を送信するに は充分ではありません。以下の図は 、DTO で発生する可能性のあるアドレス指定の概要を示しています。 XCP DTO Packet Identification Field Timestamp Field Data Field PID PID DAQ PID TS DAQ PID FILL TS DAQ TIMESTAMP DATA 図29： DTO送信に対する XCPパケットの構造 送信タイプ：「 絶対 ODT 番号」 絶対とは 、ODT 番号が通信全体 ( すなわち 、すべての DAQ リストにわたる ) を通じて一意であることを示し ています。これは 、絶対 ODT 番号を使用することが 、DAQ リストに対していわゆる FIRST_PID を用いた変 換ステップの役割を負っていることを示しています。 DAQ リストが PID j で始まる場合 、最初のパケットの PID は値 j を持ち 、2 番目のパケットは PID 値 j + 1、3 番 目のパケットは PID 値 j + 2 ( 以下続く) を持ちます。当然 、この場合スレーブは 、FIRST_PID + 相対 ODT 番 号の合計が次の DAQ リストの PID を下回っている状態を確実に保つ必要があります。 DAQ リスト：0 ≤ PID ≤ k ≤ PID ≤ m DAQ リスト：k + 1 DAQ リスト：m + 1 ≤ PID ≤ n など 1.3 DTOの交換 – 同期データ交換 41 この場合 、識別フィールドは非常に単純です。 Identification Field PID 図30： absolute ODT number 絶対ODT番号を持つ 識別フィールド 送信タイプ：「 相対 ODT 番号と絶対 DAQ リスト番号」 この場合 、DAQ リスト番号と ODT 番号は識別フィールド内で送信可能です。しかし、その情報に対して利用 可能なバイト数の中にはまだスペースが残っています。 Identification Field PID DAQ 図31： absolute DAQ List number relative ODT number 相対ODT番号と 絶対DAQ番号を持つ IDフィールド（1バイト） 図では 、DAQ 番号に 1 バイト、ODT 番号に 1 バイト利用可能です。 DAQ リストの最大番号は 2 バイトを使用して送信できます。 Identification Field PID DAQ 図32： absolute DAQ list number relative ODT number 相対ODT番号と 絶対DAQ番号を持つ IDフィールド（2バイト） 1 XCPプロトコルの基礎 42 3 バイトを送信することができない場合 、フィルバイトを使用して 4 バイトで対応することも可能です。 Identification Field PID FILL DAQ absolute DAQ list number for alignement relative ODT number 図33： 相対ODT番号と 絶対DAQ番号を持つ IDフィールドとフィルバイト （合計4バイト） では 、XCP マスターはどのようにしてスレーブが使用している方法を知るのでしょうか？ まず 、A2L 内のエン トリー項目によって知り、次にスレーブにどの通信バージョンを実装しているかを判断する要求を行うことに よって知ることができます。 GET_DAQ_PROCESSOR_INFO 要求へのレスポンスは 、スレーブが使用中の伝送タイプをマスターに通知す るために使用する DAQ_KEY_BYTE も設定します。DAQ だけでなく、STIM も使用されている場合 、マスター はスレーブが DAQ に対して使用する STIM と同じ方法を使用しなければなりません。 1.3.5 バイパス = DAQ + STIM バイパスは 、DAQ と STIM を併せて使用することで実装できる、ラピッドプロトタイピングソリューションの特 殊な形態を表しています（図 8 を参照）。しかし、より深く理解するためにはさらに詳しい情報が必要ですの で 、この方法については本書の第 4 章 5「 バイパス 」で説明します。 1.4 XCPトランスポートレイヤー 43 1.4 XCPトランスポートレイヤー プロトコルの設計における主要件は 、異なるトランスポートレイヤーのサポートです。本書の作成時点で定 義されているレイヤーは 、XCP on CAN 、FlexRay 、Ethernet 、SxI 、USB です。 ベクターが提供している e ラーニングでは 、CAN 入門 、LIN 入門 、FlexRay 入門 、AUTOSAR 入門といった e ラーニングモジュールを ご用意しております。詳しくは 、ベクターの下記 URL をご覧ください。 http://vector-elearning.com/vl_index_jp.html 1.4.1 CAN XCP は CCP の後継プロトコルとして開発され 、CAN バスの要件を完全に満たしています。CAN バスを経由す る通信は 、付随する記述ファイルによって定義されます。通常使用されるフォーマットは DBC ですが 、一部 単独の場合には AUTOSAR フォーマット ARXML がすでに使用されています。 CAN メッセージは一意の CAN 識別子によって識別されます。どの送信者がどのメッセージを送信したかや 使用中の CAN バスの 8 バイトの使用方法など、通信マトリクスは記述ファイル内で定義されます。以下の図 はプロセスを示しています。 Data Frame CAN Node A CAN Node B ID=0x12 Sender Receiver ID=0x34 Sender ID=0x52 Receiver ID=0x67 Receiver ID=0xB4 Receiver ID=0x3A5 Sender Receiver CAN Node C CAN Node D Receiver Receiver Sender Sender Receiver 図34： Sender Receiver Receiver どのバスノードが Receiver どのメッセージを送信するか についての定義 ID 0x12 を持つメッセージは CAN ノード A によって送信され 、バス上の他のすべてのノードがこのメッセージ を受信します。アクセプタンステストのフレームワークにおいて 、CAN ノード C と D はそのメッセージを必要 ないと判断し、拒否します。 一方で 、CAN ノード B は自己より上位のレイヤーがそのメッセージを必要とし ていると判断し、そのメッセージを Rx バッファーを経由して上位レイヤーに提供します。CAN ノードは以下 のように相互接続されます。 1 XCPプロトコルの基礎 44 CAN Node A CAN Node B Host Host CAN Interface Tx Rx Buffer Buffer CAN Interface Tx Rx Buffer Buffer Acceptance Test Acceptance Test Receive Send Receive Send CAN Send Receive Send Receive Acceptance Test Acceptance Test Rx Tx Buffer Buffer CAN Interface Rx Tx Buffer Buffer CAN Interface Host Host CAN Node C CAN Node D 図35： CANネットーワークの図解 XCP メッセージはこの通信マトリクスには記載されていません。測定値が XCP を使用するなど、動的 DAQ リ ストによりスレーブから送信される場合 、メッセージはユーザーが選択したシグナルにしたがって組み立てら れます。選択したシグナルが変更された場合 、メッセージ内容も変更されます。それでも 、通信マトリクス と XCP は関連しています。CAN 識別子は CAN を経由して XCP メッセージを送信するために必要です。使用 する CAN 識別子の数を最小限に抑えるには 、XCP 通信を制限して DBC 内で「 通常」通信に使用されていな い CAN 識別子を 2 つだけ使用します。 1 つの識別子は情報をマスターからスレーブに送信するために必要 で 、もう一方はスレーブがマスターに応答するために使用されます。 CANape のトレース Window からの抜粋（図 36 ）は 、「 ID 」カラムの下で使用される CAN 識別子を示してい ます。この例では 、2 つの異なる識別子だけが使用されています。それらは 、マスターからスレーブへメッ セージを送る （送信 (Tx) 方向） ための ID 554 と、スレーブからマスターへメッセージを送る （受信 (Rx) 方向） ための ID 555 です。 1.4 XCPトランスポートレイヤー 45 図36：XCP-on-CAN通信の例 この例では 、XCP 通信全体が 2 つの CAN 識別子 554 と 555 によって処理されます。これら 2 つの ID は 、こ のネットワーク内では他の目的に対して割り当てることができません。 CAN バスは 、使用可能なバイトを 1 メッセージあたり最大 8 バイト送信します。しかし、XCP の場合 、使用さ れるコマンドまたは送信されたレスポンスに関する情報が必要です。これは CAN の使用可能なデータの最 初のバイトに格納されています。これは 、使用可能なデータの送信のために 1CAN メッセージあたり 7 バイ トが利用できるということです。 XCP on CAN Message (Frame) XCP Header empty for CAN PID FILL DAQ Control Field empty for CAN XCP Packet TIMESTAMP XCP Tail DATA Fill Control Field for CAN 図37：XCP-on-CANメッセージの図示 CANape では 、仮想 XCPsim によって XCP-on-CAN のデモを見ることができます。規格の詳細については 、 「 ASAM XCP パート 3トランスポートレイヤー仕様」で確認できます。 1 XCPプロトコルの基礎 46 1.4.2 CAN FD CAN FD (CAN with flexible data rate) は 、Robert Bosch GmbH が開発した拡張 CAN プロトコルです。 CAN との主な違いは 、ユーザーデータを 8 バイトから 64 バイトに拡張していること、アービトレーション領 域では CAN と同じ転送速度 、その後のデータ領域では転送速度の高速化が可能であることです。CAN FD は 、ユーザーデータを CAN よりも高速なデータレートで送信でき 、CAN 開発経験を活かしながらも自動車 業界で求められている高帯域幅ネットワーク要件を満たすことができます。 XCP on CAN FD の仕様は 、XCP 規格 1.2.0（2013 年 6 月）の XCP on CAN の記述に定義されました。 アービトレーション領域 （ CAN と同様の転送速度） データ領域 （転送速度を高速化可能） EDL= Extended Data Length ドミナント (0) = CAN のデータフレーム レセッシブ (1) = CAN FD のデータフレーム アービトレーション領域 （ CAN と同様の転送速度） ESI = Error State Indicator ドミナント (0) = CAN FD ノードはエラーアクティブです。 レセッシブ (1) = CAN FD ノードはエラーパッシブです。 BRS = Bit Rate Switch CAN FD のデータ領域は BRS のサンプリングポイントから始まります。 ドミナント (0) = データ領域のビットレートは変わりません。 レセッシブ (1) = データ領域のビットレートは高速ビットレートに変わります。 図38：CAN FDのデータフレーム CAN FD は CAN と同種の機能を多数装備していますが 、プロトコルの拡張への対応とハードウェア／ソフト ウェアに対する適合作業は 、やはり必要です。特に、CAN FD のコントロール領域には 、下記の 3 つのビット が新たに採用されています。 > EDL（ Extended Data Length ） > BRS（ Bit Rate Switch ） > ESI（ Error State Indicator ） 1.4 XCPトランスポートレイヤー EDL ビットは従来の CAN フォーマットのフレームと CAN FD フォーマットのフレームを識別するビットで 、CAN FD フレームではレセッシブに、CAN フレームではドミナントに設定されています。同じくBRS ビットがレセッ シブの場合は 、データフィールド送出時のビットレートが高速に切り替わります。 ESI ビットは CAN FD ノードのエラー状態の識別に使われます。さらに、DLC (Data Length Code) として データ長の拡張分をカバーする 4 ビット構成が追加されており、これを使用して 12、16、20、24、32、48、 64 バイトのいずれかの値を設定します。 XCP on CAN FD を使用することで 、A2L ファイルの重要なデータのための第 2 の転送レートが定義されま す。 ユーザーは A2L がパラメーター化されるのを確認することができます。XCP マスターが測定コンフィ ギュレーションを最大パケット長で考慮するため 、ユーザーは他の設定を行う必要はありません。 CAN FD は CANape バージョン 12.0 以降で対応しています。製品名が「 VN 」で始まるベクターの CAN ハー ドウェア製品はどれも 、CAN FD のトランスポートプロトコルに対応しています。 47 1 XCPプロトコルの基礎 48 1.4.3 FlexRay FlexRay の開発における基本的な考え方は 、決定論的時間挙動による冗長システムを実装することでした。 接続の冗長性は 、チャンネル A とチャンネル B の 2 つのチャンネルを使用することで実現しました。 複数の FlexRay ノード（ = ECU ）が冗長的に相互接続されている状態で 、1 つのブランチに不具合が生じた場合 、 ノードが他のチャンネルに切り替わり、接続の冗長性を利用できます。 Node K Node L Node M Node N Node O CH A CH B 図39：ノードKとLが冗長的に相互接続された状態 決定論的挙動は 、規定のタイムスロット内でデータ送信を行うことで実現します。どのノードが 、どのデー タ内容を 、どのタイムスロットに送信するかもここで定義されます。これらのタイムスロットは結合されて 1 つのサイクルを形成します。この場合 、サイクルはバスが有効である限り繰り返されます。タイムスロット とそのトランスポートコンテンツの組立（何が何をどのタイミングで送信するか ）はスケジューリングと呼ば れています。 Node K Slot 1 3 Node L Direction Frame a Tx Rx x Frame: a Frame: b Slot 1 t1 Slot 1 3 Frame: a Slot 3 t3 Communication Cycle 図40：スロット定義による通信 Direction Frame Tx a Rx b Frame: x Slot 2 t2 Node M Slot 1 3 Frame: b Slot 1 t4 Direction Frame Tx a Rx x Frame: x Slot 2 t5 ... t6 Next Communication Cycle Real-time 1.4 XCPトランスポートレイヤー 49 最初の通信サイクルでは 、ノード K がフレーム a をスロット 1 に送信します。スケジューリングもノード L と M のソフトウェア内に保存されます。したがって 、フレーム a のコンテンツは次に高い通信レベルまで渡さ れます。 スケジューリングは記述ファイル内で一元管理されます。これは DBC ファイルではなく、CAN の場合と同じ くFIBEX ファイルです。FIBEX は 、「 フィールドバス交換フォーマット（ Field Bus Exchange Format ）」の 略で 、他のバスシステムに対しても使用できます。FIBEX は XML フォーマットで 、XCP-on-FlexRay の仕様 Static Segment は FIBEX バージョン 1.1.5 と FlexRay 仕様バージョン 2.1 に関連しています。 Slot ECU 1 Node K 2 Node M 3 Node L 4 Dynamic Segment 5 6 Cycles Channel 0 1 2 3 4 5 6 A b [rep : 1 ] b [rep : 1 ] b [rep : 1 ] b [rep : 1 ] b [rep : 1 ] b [rep : 1 ] b [rep : 1 ] ... b [rep : 1 ] 63 B b [rep : 1 ] b [rep : 1 ] b [rep : 1 ] b [rep : 1 ] b [rep : 1 ] b [rep : 1 ] b [rep : 1 ] b [rep : 1 ] A c [rep : 4 ] x [rep : 2 ] y [rep : 4 ] x [rep : 2 ] c [repc : 4 ] x [rep : 2 ] y [rep : 4 ] x [rep : 2 ] B A a [rep : 1 ] a [rep : 1 ] a [rep : 1 ] a [rep : 1 ] a [rep : 1 ] a [rep : 1 ] a [rep : 1 ] a [rep : 1 ] B d [rep : 1 ] d [rep : 1 ] d [rep : 1 ] d [rep : 1 ] d [rep : 1 ] d [rep : 1 ] d [rep : 1 ] d [rep : 1 ] Node L A n [rep : 1 ] n [rep : 1 ] n [rep : 1 ] n [rep : 1 ] n [rep : 1 ] n [rep : 1 ] n [rep : 1 ] n [rep : 1 ] Node O B m [rep : 1 ] m [rep : 1 ] m [rep : 1 ] m [rep : 1 ] m [rep : 1 ] m [rep : 1 ] m [rep : 1 ] m [rep : 1 ] A r [rep : 1 ] r [rep : 1 ] r [rep : 1 ] r [rep : 1 ] r [rep : 1 ] r [rep : 1 ] r [rep : 1 ] r [rep : 1 ] o [rep : 1 ] o [rep : 1 ] o [rep : 1 ] o [rep : 1 ] o [rep : 1 ] o [rep : 1 ] o [rep : 1 ] o [rep : 1 ] t [rep : 2 ] p [rep : 4 ] t [rep : 2 ] t [rep : 2 ] p [rep : 4 ] t [rep : 2 ] Node N B A Node K B Node M A B 7 Node L A Node L B Node O B u [rep : 4 ] u [rep : 4 ] v [rep : 8 ] A 図41: w [rep : 4 ] w [rep : 4 ] FlexRay 通信マトリクスの図解 AUTOSAR ソリューションの開発の結果 、バス通信を記述するための別のフォーマット、AUTOSAR 記述ファ イル（ XML フォーマットで利用可能）も定義されています。AUTOSAR 4.0 仕様では 、XCP-on-FlexRay の 定義が考慮されています。しかし、本書の発行時点ではこの仕様は正式に認証されていなかったため 、詳 細については説明しません。 FlexRay バスのその他の特性により、コンテンツのリファレンスとしてスロット番号を与えるだけでは充分で はありません。 その理由の 1 つは 、多重化がサポートされているためです。 サイクルが繰り返される場合 はいつも 、送信されたコンテンツが必ずしも同じであるわけではありません。多重化によって 、特定の情報 が通過 2 回に 1 回の割合でのみスロットに送信されるよう指定される場合があります。 1 XCPプロトコルの基礎 50 純粋なスロット番号を示す代わりに、「 FlexRay データリンクレイヤープロトコルデータユニット識別子」 （ FLX_LPDU_ID ）が使用されます。これは一般化されたスロット ID のタイプとして理解できます。そのよ うな LPDU を記述するには 、以下の 4 つの情報が必要です。 > > > > FLX_SLOT_ID：FlexRay スロット識別子 (FlexRay Slot Identifier) OFFSET：サイクルカウンターオフセット (Cycle Counter Offset) CYCLE_REPETITION：サイクルカウンター繰り返し (Cycle Counter Repetition) FLX_CHANNEL：FlexRay チャンネル (FlexRay Channel ) Cycle ID LPDU_ID .. . .. . .. . .. . .. . .. . .. . .. . .. . ... Channel A ... ... Channel B ... .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . ... ... ... ... ... ... Slot ID 図42： FlexRay LPDU の図解 スケジューリングもまた 、何が送信されるかを正確に定義するため 、XCP on FlexRay の使用に影響を与え ます。測定実行時に値を測定したユーザー定義が合成シグナルにより送信されるまで 、XCP では定義され ません。これは 、XCP 通信のどの特徴（ マスターからスレーブまたはスレーブからマスターへの CTO または DTO ）を 、どの LPDU で使用できるかのみを選択できるということを示しています。 以下の例はこのプロセスを示しています。XCP マスターがコマンド (CMD) をスロット n に送信すると、ス レーブ A がレスポンス (RES) をスロット n + 2 に返します。XCP-on-FlexRay は常に LPDU を使用して定義 されます。 A2L 記述ファイルは 、内部 ECU パラメーターへのアクセスに必要です。また 、ECU 内のアドレスを持つオブ ジェクトはこのファイル内で定義されます。さらに FIBEX ファイルが必要です。このファイルによって XCP マスターは 、どの LPDU に送信可能か 、XCP スレーブが自己のレスポンスをどの LPDU に送るべきかを知る ことができます。XCP マスターと XCP スレーブ間の通信は 、この 2 つのファイルの組み合わせ 、すなわち A2L ファイルが FIBEX ファイルを参照するようにすることでのみ機能します。 1.4 XCPトランスポートレイヤー 51 XCP-on-FlexRay パラメーター設定を持つ A2L の抜粋： … /begin XCP_ON_FLX … "XCPsim.xml" "Cluster_1" … この例では 、 「 XCPsim.xml 」は A2L ファイルから FIBEX ファイルへのリファレンスです。 Cycle ID XCP-dedicated LPDU_IDs .. . .. . .. . .. . .. . .. . .. . .. . .. . ... Channel A ... ... Channel B ... .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . ... ... ... ... ... ... Slot ID 図43： XCP 通信のLPDU への 割り当て XCP on FlexRay の詳細については 、CANape のオンラインヘルプに記載されています。CANape には FIBEX ビューアーが添付されており、ユーザーはスケジューリングを容易に確認できます。CANape 内に XCP on FlexRay デバイス用のドライバー設定を行うことで 、簡単に XCP メッセージを LPDU に割り当てるこ とができます。 プロトコルについては 、 「 ASAM XCP on FlexRay パート 3 トランスポートレイヤー仕様」で詳しく説明してい ます。CANape では 、仮想 ECU の XCPsim によって XCP on FlexRay のデモを見ることができます。このデ モには 、実際のベクター FlexRay ハードウェアが必要です。 1.4.4 Ethernet XCP on Ethernet は 、TCP/IP と UDP/IP のどちらでも使用可能です。TCP/IP は保護された Ethernet 上の トランスポートプロトコルで 、ハンドシェイク方式を使用してパケットの損失をすべて検知します。パケット が損失した場合 、TCP がパケットの繰り返しを制御します。UDP はこの保護メカニズムをサポートしません。 パケットが損失した場合でも 、UDP にはプロトコルレベルで損失したパケットを繰り返し送信するためのメカ ニズムは一切ありません。 XCP on Ethernet は実際の ECU で使用できるだけでなく、仮想 ECU の測定とキャリブレーションにも使用 できます。この場合 、仮想 ECU は 、PC 上の実行可能プログラム（ DLL ）として ECU 内で別の形で実行さ れるコードの使用として認識されます。この場合 、ECU と比較してまったく別のリソースが利用可能です （ CPU 、メモリーなど）。 1 XCPプロトコルの基礎 52 しかし、まず実際のプロトコルについて説明していきます。IP パケットには必ず 、送信元と受信先のアドレ スが含まれています。IP パケットを視覚化するもっとも簡単な方法は 、受信先と送信元のアドレスを含む文 字の一種として扱うことです。個別ノードのアドレスは必ず一意でなければなりません。一意のアドレスは 、 IP アドレスとポートナンバーで構成されています。 XCP on Ethernet (TCP/IP and UDP/IP) Message (Frame) XCP Header LEN CTR XCP Packet PID FILL Control Field for Ethernet (TCP/ IP and UDP/IP) DAQ TIMESTAMP DATA Length (LEN) XCP Tail empty for Ethernet (TCP/IP and UDP/IP) Control Field empty for Ethernet (TCP&IP and UDP&IP) 図44：TCP/IP またはUDP/IP によるXCP パケット ヘッダーは 2 ワードのインテルフォーマット（ = 4 バイト）の制御フィールドで構成されます。これらのワード には 、長さ (LEN) とカウンター (CTR) が含まれます。LEN は XCP パケット内のバイト数を示します。CTR は パケット損失の検出に使用されます。UDP/IP は保護されたプロトコルではありません。パケットが損失した 場合 、これはプロトコルレイヤーでは認識されません。パケット損失はカウンター情報によって監視されま す。マスターが最初のメッセージをスレーブに送信すると、カウンター番号が生成されます。この番号はフ レームの伝送が新たに行われるたびに増えていきます。スレーブは同じパターンで応答し、自己が送信する フレームが増えるたびに自己のカウンターを増やします。スレーブとマスターのカウンターはお互いに独立 して作動します。UDP/IP は測定値の送信に非常に適しています。パケット損失があると、そこに含まれる 測定値は失われ 、測定ギャップが生じます。パケット損失の発生がまれである場合 、その損失は無視しても かまいません。しかし、測定値を高速制御のベースとして使用しなければならない場合は 、TCP/IP を使用 することをお勧めします。 Ethernet パケットは複数の XCP パケットを伝送できますが 、XCP は UDP/IP パケットの制限を超えることは 絶対にできません。XCP on Ethernet の場合 、 「 テール (Tail) 」(= 空の制御フィールド ) はありません。 プロトコルの詳細な情報については 、 「 ASAM XCP on Ethernet パート 3 トランスポートレイヤー仕様」に記 載されています。CANape には 、仮想 ECU XCPsim または DLL 形式の仮想 ECU による XCP on Ethernet デ モもあり、Simulink モデルと Simulink Coder によって実装されています。 1.4 XCPトランスポートレイヤー 53 1.4.5 SxI SxI は 、SPI または SCI の総称です。これらはバスではなく、コントローラーインターフェイスであるためポ イント間接続にしか適しておらず 、このタイプの送信におけるアドレス指定はありません。任意の 2 つのノー ド間の通信は 、同期または非同期で実行されます。 XCP on Sxl Message (Frame) XCP Header LEN CTR XCP Packet PID FILL Control Field for SxI DAQ TIMESTAMP Length (LEN) XCP Tail DATA FILL CS Control Field for SxI Checksum (CS) 図45：XCP-on-SxI パケット XCP ヘッダーはコントロールフィールドで構成され 、長さ (LEN) とカウンターの 2 つの情報があります。こ れらのパラメーターの長さは 、バイトまたはワード（インテルフォーマット）で表現できます。LEN は XCP パ ケットのバイト数を示します。CTR はパケット損失の検出に使用されます。これはカウンター情報を使用し て 、XCP on Ethernet の場合と同じ方法で監視されます。SPI が WORD または DWORD モードで使用される 場合 、またはメッセージが最小パケット長未満になることを避けるためなど、一部の状況ではパケットにフィ ルバイトを追加する必要がある場合があります。これらのフィルバイトは制御フィールドに追加されます。 プロトコルの詳細な情報については 、「 ASAM XCP on SxI パート 3 トランスポートレイヤー仕様」に記載さ れています。 1.4.6 USB 現在 、XCP on USB には実用上の重要性はありません。したがって 、この内容についてはこれ以上言及しま せん。その規格の説明については ASAM 文書の「 ASAM XCP on USB パート 3 トランスポートレイヤー仕 様」をご参照ください。 1.4.7 LIN 現時点で 、ASAM はまだ XCP-on-LIN 規格を定義していません。しかし、ベクターではソリューションをご 用意しています（ XCP on LIN ドライバーおよび XCP on LIN マスターとしての CANape ）。これらはいずれ も LIN または XCP 仕様には違反しておらず 、一部の顧客プロジェクトですでに使用されています。詳しくは 、 ベクターにお問い合わせください。 1 XCPプロトコルの基礎 54 1.5 XCP サービス この章では 、XCP 上で実現できるその他のサービスについて項目を挙げ 、説明します。 それらはすべて 、 すでに説明した CTO と DTO を利用した通信メカニズムをベースにしています。同期データ取得／スティミュ レーションおよびデバイスメモリーへの読込み／書込みアクセスなどの一部の XCP サービスについてはす でに説明しました。 XCP 仕様は実にさまざまなサービスを一意的に定義すると同時に、そのサービスが常に実装する必要があ るものなのか 、またはオプションなのかについて示しています。たとえば 、マスターが接続を設定するため には XCP スレーブが「 Connect 」をサポートしていなければなりません。一方で 、XCP 上でのフラッシュ書 込みは必ず必要なわけではなく、XCP スレーブはそれをサポートする必要はありません。これは単純にプロ ジェクトとソフトウェアの要件に応じて異なります。この章に記載のサービスは 、すべてオプションです。 1.5.1 メモリーページスワッピング キャリブレーションコンセプトの記述ですでに説明したように、パラメーターは通常 FLASH メモリー内にあ り、必要に応じて RAM にコピーされます。キャリブレーションコンセプトの中には 、RAM とフラッシュからメ モリーセグメントページをスワップするオプションを提供するものがあります。XCP はもう少し一般的で汎用 的な手法を提供します。XCP の中では 、メモリーセグメントに複数のスワップ可能なページを含むことが可 能です。通常 、これは RAM ページとフラッシュページで構成されます。しかし、複数の RAM ページを持つ ことやフラッシュページを持たないことも考えられます。 ページスワッピングに対する XCP コマンドの理解を深めるため 、セクター、セグメント、ページのコンセプト をここで再度説明していきます。 Segment 1 Page 0 Segmemt 1 Sector 2 XCP access Segment 1 Page 1 Segment 1 Page 2 Sector 0 Segment 0 Page 0 Segmemt 0 Sector 1 ECU access address 図46： メモリーの図解 1.5 XCPサービス XCP の観点からすると、スレーブのメモリーは 40 ビット幅でアドレス指定される連続メモリーで構成されてい ます。メモリーの物理レイアウトはセクターをベースにしています。フラッシュ書込みを行う場合には、フラッ シュセクターを必ず理解しておく必要があります。FLASH メモリーは一度に 1 ブロック単位でしか消去するこ とができないためです。 論理構造は、いわゆるセグメントをベースにしており、セグメントはキャリブレーションデータのメモリー内 の位置を記述します。セグメントの開始アドレスとパラメーターは、物理セクターの開始アドレスおよびパラ メーターと一致している必要はありません。各セグメントは複数ページに細分化されます。セグメントのペー ジは同じアドレスに同じパラメーターを記述します。これらのパラメーターの値と読込み／書込み権は各ペー ジに対して個別に制御可能です。 セグメント内のページに対するアルゴリズムの割り当ては、常に一意でなければなりません。ある一定の時 間においては、1 つのセグメントで有効なのは 1 つのページだけです。このページは「 このセグメント内の ECU の有効ページ (active page for the ECU in this segment) 」という名称です。ECU と XCPドライバーが アクセスする有効な特定のページは個別に切り替えることができます。これらの設定間に相互の依存性は存 「 このセグメント内の 在しません。ECU に対する命名規則と同様に、XCP アクセスに対する有効なページは、 XCP アクセスに対する有効なページ (active page for XCP access in this segment) 」として参照されます。 また 、これは各個別セグメントに適用されます。セグメントは A2L ファイル内にリストアップされなければな らず 、各セグメントはそのセグメントを参照するために使用されている番号を取得します。XCP スレーブ内で は、SEGMENT_NUMBER は必ず 0 で始まり、その後 1 ずつ連続して増加していかなければなりません。各セ グメントには 1 つ以上のページがあります。これらのページも番号で参照されます。最初のページは PAGE0 です。番号に対しては 1 バイトが利用可能で 、1 セグメントあたり最大 255 ページを定義することができます。 スレーブは全セグメントの全ページを初期化します。マスターはコマンド GET_CAL_PAGE を使用して 、ス レーブに、現在 ECU に対して有効なページはどれか 、XCP アクセスに対して有効なページはどれかを問い合 わせます。アクセスに対して相互ブロックが必要であるという場合もあります。たとえば 、このページが ECU に対して現在有効である場合 、XCP スレーブはページにアクセスすることができません。上述のように、依 存性がある場合もありますが 、必ずしもそうではありません。これはスレーブがどのように実装されているか の問題です。 スレーブがオプションコマンド GET_CAL_PAGE と SET_CAL_PAGE をサポートする場合 、ページスワッピング と呼ばれる機能もサポートします。これらの 2 つのコマンドは、現在どのページが使用中であるかをマスター にポーリングさせ 、必要に応じて ECU と XCP アクセス用のページをスワップすることができます。XCP マス ターはページのスワッピングに対して完全な制御権を持っています。XCP スレーブが自分自身でスワッピング を開始することはできません。しかし、マスターはスレーブ実装のすべての制限を守らなければなりません。 スワッピングのメリットは何でしょうか？まず、スワッピングでは、パラメーターセット全体の変更を非常に短時 間で行うことができます。基本的に事前事後の比較です。次に、キャリブレーション担当者が ECU の別のペー ジに大幅なパラメーター変更を行っている間 、装置が安定した状態で維持されます。これにより、パラメー ター設定中の不完全なデータセットなど、危機的または不安定な状態にならないようにします。 55 1 XCPプロトコルの基礎 56 1.5.2 メモリーページの保存 ‒ データページ凍結 担当者があるページのパラメーターをキャリブレートする際 、XCP には RAM ページのデータを不揮発性メ モリーに保存するといった、ECU 内にデータを直接保存するための概念的能力があります。不揮発性メモ リーがフラッシュの場合、セグメントの開始アドレスとセグメントサイズはフラッシュセクターと必ずしも 合っていない場合があるため 、FLASH メモリーの消去と再書込みに問題が生じることを考慮しなければな りません（「 ASAM XCP パート 2 プロトコルレイヤー仕様」を参照）。 1.5.3 フラッシュプログラミング フラッシュ書込みとは 、FLASH メモリーの領域にデータを書き込むことです。これにはメモリーの配置方 法に関する正確な知識が要求されます。FLASH メモリーは複数のセクターに細分化され（物理的セクショ ン）、スタートアドレスと長さによって記述されます。それぞれを区別するために 、セクターには連続した 識別番号が付けられています。この番号には 1 バイトが利用可能で、最大で 255 セクターとなっています。 SECTOR_NUMBER [0, 1, 2 … 255] フラッシュセクターについての情報も A2L データセットの中に含まれています。 図47: フラッシュエリアの ドライバー設定の図解 1.5 XCPサービス フラッシュ書込みの実行は 、 「 フラッシュカーネル」と呼ばれるコードで行います。フラッシュカーネルは 、 実際のフラッシュ書込みスレーブの RAM に送信される実行可能コードで、送信されたカーネルが XCP マス ターとの通信を処理します。これには FLASH メモリーの消去を担当するアルゴリズムが含まれる場合があ ります。セキュリティーと容量の問題から 、このコードが ECU の FLASH メモリー内に恒久的に保存されな いことが頻繁にあります。一部の状況下では 、チェックサムや同様の計算の実行が必要な場合などに 、コ ンバーターが使用されることがあります。 XCP によるフラッシュ書込みは 、フラッシュプロセス全体をおおまかに下記 3 つの領域に細分化します。 > 準備（ バージョンコントロールにより、新しいコンテンツでもフラッシュ書込みができるかどうかを確認す ること等） > 実行（新しいコンテンツが ECU に送信される） > 事後処理（チェックサム確認等） XCP 規格では 、実際のフラッシュ書込みの実行に主眼が置かれています。この動作を診断プロトコルへの フラッシュ書込みと比較すれば 、必ずメタデータによるシリアル番号処理などプロセス特有の要素が XCP 内で比較的質素な形でサポートされることに気づきます。開発フェーズでのフラッシュ書込みは 、明らかに その定義において一番重要でしたが、エンドオブライン（ EOL 、開発の検査段階）でのフラッシュ書込み時 に必要な複雑なプロセスステップではありませんでした。 したがって、この準備フェーズで重要なことは 、新しいコンテンツが ECU に適切であるかどうかを判断する ことでした。バージョンコントロールには特殊なコマンドは必要ありません。正確には 、作業はプロジェク ト専用のこれらのコマンドをサポートすることでした。 以下の XCP コマンドが利用可能です。 PROGRAM_START：フラッシュ手順の開始 このコマンドはフラッシュプロセスの開始を示しています。ECU がフラッシュ書込みのできない状態にある 場合（車速が 0 であるなど）、XCP スレーブは「 ERRor 」によって確認を返さなければなりません。実際のフ ラッシュプロセスは 、PROGRAM_START がスレーブによって正常に確認されるまで開始できません。 PROGRAM_CLEAR：現在の FLASH メモリーの消去ルーチンの呼出 FLASH メモリーを新しいコンテンツで上書きできるようにする前に 、まず消去しなければなりません。こ のコマンドによる消去ルーチンの呼出は ECU 内で実装するか、またはフラッシュカーネルを使用して ECU が利用できるようにしてください。 PROGRAM_FORMAT：フラッシュデータ用のデータフォーマットの選択 XCP マスターはこのコマンドを使用して、データをスレーブに送信する場合のフォーマット（圧縮または暗 号化など） を定義します。このコマンドが送信されない場合のデフォルト設定は非圧縮 、非暗号化送信です。 57 1 XCPプロトコルの基礎 58 PROGRAM：XCP スレーブへのデータ伝送 （ 診 断 に よ るフ ラッ シュ書 込 み に 精 通 して い る ユー ザ ー の 場 合 ）こ の コ マ ンド は 診 断 に お ける TRANSFERDATA に対応しています。このコマンドを使用して、データが XCP スレーブに送信され 、FLASH メモリーに保存されます。 PROGRAM_VERIFY：新しいフラッシュコンテンツの確認要求 マスターは 、新しいコンテンツが正常であるかを判断するためのスレーブによる内部確認の実行を要求す ることができます。 PROGRAM_RESET：スレーブへのリセット要求 マスター によるスレ ーブへ のリセット 実 行 要 求。そ の 後、スレ ーブへ の 接 続 は 必ず 終了し、新しい CONNECT を送信しなければなりません。 1.5.4 スレーブの自動検出 XCP プロトコルにより、マスターはプロトコル固有特性をスレーブに確認します。これには多くのコマンド が利用可能です。 GET_COMM_MODE_INFO このコマンドへのレスポンスにより、マスターは 、スレーブがブロック転送またはインターリーブモードを サポートしているかどうか、またはマスターがこれらのモードの要求間で維持しなければならない最低時 間間隔など、スレーブのさまざまな通信オプションについての情報を受け取ります。 GET_STATUS この要求へのレスポンスは 、現在のスレーブの状態に関する以下のような情報をすべて返します。 サポートされているリソース （キャリブレーション、フラッシュ書込み、測定など）はどれか？ 現在まだ実行 中のメモリー動作（ DAQ リストコンフィギュレーションなど）の種類は何か？ DTO（ DAQ 、STIM ）は現在交 換中か？ GET_DAQ_PROCESSOR_INFO マスターは 、定義済みの DAQ リスト、利用可能な DAQ リスト、イベントの数など、スレーブの制限について 認識する必要のある一般情報を取得します。 GET_DAQ_RESOLUTION_INFO スレーブの DAQ 機能 (DAQ と STIM に対する ODT のパラメーターの最大数、ODT エントリーの精度、タイム スタンプ送信のバイト数など ) についてのその他の情報は 、このコマンドにより交換されます。 GET_DAQ_EVENT_INFO このコマンドを使 用する場合、ECU イベント 1 回当たり、呼び出しが 1 回行われます。イベントが DAQ 、 STIM 、または DAQ/STIM で使用可能かどうか、イベントが定期的に発生するかどうか、その場合にイベン トの持つサイクルタイムの長さなどの情報がここで送信されます。 1.5 XCPサービス 59 1.5.5 アップロード、ダウンロード、フラッシュ書込みのためのブロック転送モード 「 通常の」通信モードでは 、マスターからの各コマンドがスレーブのレスポンスによって確認応答されます。 しかし、場合によっては 、性能上の理由からブロック転送モードと呼ばれるものを使用することが望まし い場合もあります。 Slave Master Request k Part1 Part2 Part3 MIN_ST MAX_BS Response k Request k+1 Time 図48: ブロック転送モードの図解 この方法を使用することで、大量のデータ送信を行う場合のプロシージャー (UPLOAD 、SHORT_UPLOAD 、 DOWNLOAD 、SHORT_DOWNLOAD 、PROGRAM) が短時間で行われるようになります。マスターは要求 GET_COMM_MODE_INFO により、スレーブがこの方法をサポートするかどうかを判断することができます。 詳細については 、 「 ASAM XCP パート 2 プロトコルレイヤー仕様」に記載されています。 1 XCPプロトコルの基礎 60 1.5.6 コールドスタート測定（起動中の測定の開始） ここまで記載してきた XCP の機能を使用しても 、ECU の起動フェーズの初期段階で実際に実行されるイベ ントドリブンな測定を実行することはできません。なぜなら 、実際の測定が開始される前に測定を構成し なければならないためです。もしこれを行おうとするならば 、最初の測定値が送信されるタイミングのかな り前に ECU の起動フェーズを終了させておかねばなりません。この問題を解決するための手法は 、ある簡 単な考えに基づいています。 これを行うには 、コンフィギュレーションと測定を時間の観点で分離します。コンフィギュレーションフェー ズの後、測定は直ちに開始されず、ECU がシャットダウンされます。再起動後、XCP スレーブは既存のコン フィギュレーションに直接アクセスし、直ちに最初のメッセージの送信を開始します。しかし、この作業に は困難が伴うことが明白です。なぜなら 、DAQ リストのコンフィギュレーションは RAM に保存されている ため 、再起動後にはその情報がもう存在していないからです。 コールドスタート測定を可能にする RESUME（再開）モードと呼ばれる機能を有効にするには 、XCP スレー ブ内に 、電源供給が行われていない間のデータ保存を行うための不揮発性メモリーが必要です。この方 法では 、EEPROM を使用します。この場合、実際の EEPROM であるか、または FLASH メモリーがエミュレー トする機能であるかは関係ありません。 詳細については 、 「 ASAM XCP パート 1 概要仕様」の 1.4.2.2「 詳細機能」の章に記載されています。 1.5 XCPサービス 1.5.7 XCPによるセキュリティーメカニズム 権限のないユーザーが ECU へ接続できないように 、可能な限りの対策を行ってください。接続試行が許可 されるかどうかを確認するためには 、 「 シード & キー」方式を利用できます。シード & キーで保護される アクセスタイプには 、測定／スティミュレーション、キャリブレーション、フラッシュ書込みの 3 種類があり ます。 シード & キー方式は次のように機能します。マスターが接続要求を行うと 、スレーブはランダムな番号 （ = シード）をマスターに送信します。ここで、マスターはレスポンス（ = キー）を生成するためのアルゴリ ズムを使用します。このキーがスレーブに送信されます。スレーブも期待されるレスポンスを計算し、マス ターのキーをスレーブ自身の計算結果と比較します。2 つの結果が符合すると、マスターとスレーブの両 方が同じアルゴリズムを使用したことになります。次に 、スレーブがマスターへの接続を受け入れます。符 合しない場合は 、スレーブがマスターとの通信を拒否します。 通常 、このアルゴリズムはマスター内の DLL として利用できます。このため 、ユーザーが「 シード & キー」 DLL と A2L ファイルを持っている場合、ECU メモリーへのアクセスを阻害する要因はまったくありません。 ECU が生産開始に近づくと、多くの場合 XCPドライバーは無効にされます。XCP の ECU へのアクセスを復元 するには 、通常 、個別の診断コマンドの専用シーケンスを使用します。これにより、生産車両でも XCPドラ イバーが広く利用可能になりますが、通常は ECU の権限のない操作を防止するために無効になっています （「 ASAM XCP パート 2 プロトコルレイヤー仕様」を参照）。 あるプロジェクトでシード & キーが使用されているか、または XCP の無効化が使用されているかについて は 、実装に応じて異なり、XCP 仕様とは関係ありません。 61 2 ECU記述ファイルA2L 62 2 ECU記述ファイルA2L A2L ファイルが必要な理由の 1 つ 、つまり、シンボル名をアドレスに割り当てることについてはすでに説明し ました。たとえば 、ソフトウェア開発者が PID コントローラーを実装し、P1、I1、D1 という名前を自分の比例 要素 、積分要素 、微分要素のアプリケーションに割り当てた場合 、キャリブレーション担当者はそのシンボリッ ク名でこれらのパラメーターにアクセスできることになります。以下の図を例として見てみましょう。 図49: キャリブレーションWindow内の パラメーター ユーザーは、シンボリック名を用いて簡単に値を変更することができます。この例では、ECU から測定された シグナル変数を確認できます。 図50: 時間軸でみたシグナルレスポンス 凡例内では、ユーザーがシグナルの論理名を確認できます。ECU 内のパラメーターのあった位置のアドレス は、値のオフライン解析時において二次的には重要です。当然 、ECU 内の値を要求するためには正確なアド レスが必要ですが 、アドレス自身の数値はユーザーにとって重要ではありません。ユーザーは選択と可視化 のために論理名を使用する、すなわち 、ユーザーがオブジェクトの名称によりオブジェクトを選択し、XCP マ スターが A2L 内で関連するアドレスとデータタイプを検索するということです。 2 ECU記述ファイルA2L パラメーターのもう 1 つの属性は、最小値または最大値の定義であると言えるかもしれません。この場合 、 オブジェクトの値はこれらの制限値の範囲内である必要があります。ソフトウェア開発者である自分が 、電 源出力段に直接影響のあるパラメーターを定義する場合を想像してみてください。この場合 、ユーザーが ( ユーザーの理由がどんなものであっても ) 出力段を構成することで 、破壊的な損傷を生じさせることのない ようにしなければなりません。これは、A2L 内に最小値と最大値を定義して許容値を制限することで行います。 物理値と生値間の変換規則も A2L 内で定義します。このようなセンサー内の 8 ビット値を持つ変換規則の簡 単な例を視覚化できます。センサーが出力する数値は 0 ∼ 255 ですが 、実際には割合（ % ）での値の表示 が望まれます。センサー値の [0 ∼ 255] から [0 ∼ 100%] へのマッピングは、任意の変換規則で実行してか ら A2L 内に保存されます。ECU 内に生値として存在するオブジェクトを測定し、そのまま送信する場合 、測定 ／キャリブレーションツールは保存された公式を使い 、物理値を視覚化します。 スカラーパラメーターの他に、特性カーブとマップがよく使われます。開発者の中には磁界強度の関数とし て距離を決定するホールセンサーなどの近接センサーを使用し、この距離を自分のアルゴリズムに使用した いと考える人もいます。磁界と距離値は線形相関がありません。この非線形性がアルゴリズムの公式化を不 必要に難しくすることがあります。ここで特性カーブを使うことで 、まず値をリニアライズ（線形化）してから アルゴリズムに入力変数として入力できます。 特性マップのその他の応用分野は、複雑な計算に対する代用機能としての使用です。たとえば 、y = f(x) と いう関係があり、関数 f に多大な計算作業が付随している場合 、x の可能性のある範囲について値を事前に 単純に計算し、テーブルの形式（特性カーブ ）で計算結果を保存すると単純化されることが多くあります。 値 x が現在 ECU 内にある場合 、値 y をコントローラーの実行時点で計算する必要はなく、マップは結果 y を入 力変数 x に返します。 2 つの値の間を保管する必要がある場合もありますが 、それは計算の延長です。 メモリー内に保存されたこの特性カーブはどのようになっていますか？ すべての x 値が最初に入力されてか ら、すべての y 値が入力されていますか？ あるいはストレージが x1、y1、x2、y2、x3、y3... のパターンにした がっていますか？ さまざまなオプションが利用可能であることから、メモリーストレージのタイプは A2L 内の ストレージスキームに定義されます。 パラメーターのシンボリック名と連携する機能 、物理値を直接参照する機能 、複雑なストレージスキームを考 えることなく、特性マップなどの複雑な要素にアクセスする機能などにより、ユーザーの労力を抑えることが できます。 通信パラメーターは、A2L 内でも定義されます。測定／キャリブレーションツールと ECU 間の通信では、A2L からのパラメーターセットを使われ 、A2L には測定／キャリブレーションツールが ECU と通信するのに必要な ものすべてが含まれています。 63 2 ECU記述ファイルA2L 64 2.1 XCPスレーブのためのA2Lファイルのセットアップ A2L ファイルは ASCII テキスト形式ファイルで 、キーワードを使用して下記の内容が記述されます。 > 測定／キャリブレーションツールと A2L ファイル間のインターフェイス固有パラメーター（この記述は A2L ファイルの冒頭に置かれ 、AML ツリーとして参照される項目の中にあります ） > ECU への通信 > 特性カーブとマップのストレージスキーム（ キーワード：RECORD_LAYOUT ） > 生値の物理値への変換用変換規則（ キーワード：COMPU_METHOD ） > 測定パラメーター（ キーワード：MEASUREMENT ） > キャリブレーションパラメーター（ キーワード：CHARACTERISTIC ） > 測定を開始するために適切なイベント（ キーワード：EVENT ） パラメーターと測定パラメーターのまとめはグループ（キーワード：GROUP ）を使用して行います。 ： 測定パラメーターの例（名称「 Shifter_B3 」） /begin MEASUREMENT Shifter_B3“Single bit signal (bit from a byte shifting ）” UBYTE HighLow 0 0 0 1 READ_WRITE BIT_MASK 0x8 BYTE_ORDER MSB_LAST ECU_ADDRESS 0x124C02 ECU_ADDRESS_EXTENSION 0x0 FORMAT“ %.3” /begin IF_DATA CANAPE_EXT 100 LINK_MAP“ byteShift ”0x124C02 0x0 0 0x0 1 0x87 0x0 DISPLAY 0 0 20 /end IF_DATA /end MEASUREMENT 2.1 XCPスレーブのためのA2Lファイルのセットアップ パラメーターマップの例（名称：KF1 ） ： /begin CHARACTERISTIC KF1“8*8 BYTE no axis ” MAP 0xE0338 __UBYTE_Z 0 Factor100 0 2.55 ECU_ADDRESS_EXTENSION 0x0 EXTENDED_LIMITS 0 2.55 BYTE_ORDER MSB_LAST BIT_MASK 0xFF /begin AXIS_DESCR FIX_AXIS NO_INPUT_QUANTITY BitSlice.CONVERSION 8 0 7 EXTENDED_LIMITS 0 7 READ_ONLY BYTE_ORDER MSB_LAST FORMAT“ %.0” FIX_AXIS_PAR_DIST 0 1 8 /end AXIS_DESCR /begin AXIS_DESCR FIX_AXIS NO_INPUT_QUANTITY BitSlice.CONVERSION 8 0 7 EXTENDED_LIMITS 0 7 READ_ONLY BYTE_ORDER MSB_LAST FORMAT“ %.0” FIX_AXIS_PAR_DIST 0 1 8 /end AXIS_DESCR /begin IF_DATA CANAPE_EXT 100 LINK_MAP“map3_8_8_uc ”0xE0338 0x0 0 0x0 1 0x87 0x0 DISPLAY 0 0 255 /end IF_DATA FORMAT“ %.3” /end CHARACTERISTIC ASCII テキストを理解するのは容易ではありません。その構造については、「 ASAM XCP パート 2 プロトコル レイヤー仕様」の第 2 章で説明されています。 以下のセクションでは、A2L の作成方法について説明します。A2L の実際の内容とその意味について重点を 置き、エディターへの A2L 記述言語の詳細は簡単に説明するに留めます。CANape で提供される A2L エディ ターはここで用いられます。 65 2 ECU記述ファイルA2L 66 2.2 A2Lファイルの手動作成 A2L は、主に XCP スレーブのメモリーの内容を記述します。この内容は C コードで開発されたスレーブ内のア プリケーションによって異なります。アプリケーションコードのコンパイラー／リンカー実行後 、A2L ファイル の重要な要素（オブジェクト名 、そのデータタイプ、メモリーアドレス）はすでにリンカーマップファイル内に 存在しています。この時点では、XCP マスターとスレーブ間の通信用パラメーターは存在しません。通常 、 パラメーターの最小／最大値 、変換規則 、特性マップのストレージスキームなどの他の情報が必要です。 では、空の A2L と通信パラメーターの作成から始めましょう。たとえば 、XCP-on-CAN インターフェイスを 持つ ECU を記述する A2L を作成したければ 、CANape 内に新規デバイスを作成し、インターフェイスとして XCP-on-CAN を選択します。そうすれば 、これを他の通信固有情報（CAN 識別子など）で補完できます。ファ イル保存後 、A2L の通信コンテンツ全体を含む A2L が作成されます。この時点では、実際の測定／キャリブ レーションパラメーターの定義は存在しません。 A2L エディター（ CANape の一部として 、または別個のツールとして利用可能）内では、リンカーマップファ イルが A2L に関連しています。選択ダイアログ内では、A2L 内で必要なこれらのパラメーター（スカラー測 定／キャリブレーションパラメーター、特性カーブ、マップ）をマップファイルから選択できます。ユーザーは 必要なパラメーターを段階的に少しずつ追加し、それらをグループ分けすることができます。その他のオブ ジェクト固有情報もエディターを使用して追加できます。 自分のコードを変更するとき、どのようにすべきでしょうか。再コンパイルしてリンクしますか？オブジェクト のアドレスが変わる可能性は大です。基本的に、新規の A2L を生成する必要はありません。A2L 内でも利用 可能なコードに追加されたオブジェクトを得たいなら、当然それらを A2L に追加しなければなりません。A2L 内ではアドレス更新が常に必要で 、それはエディターで行います。エディターは、A2L オブジェクトの名称に 基づきリンカーマップファイル内の該当エントリーを検索し、アドレスを読み出して A2L 内でこれを更新し ます。 オブジェクト名の変更 、データタイプの適合 、パラメーターの削除と別のパラメーターの追加など、作成した アプリケーションが動的に変わる場合は、手動での作業は実用的ではありません。C コードから A2L を生成す るには、自動処理を行うための他のツールが利用できます。 ベクターの「 ASAP2 Tool-Set 」は、バッチプロセスでソースコードから A2L の自動生成を行うことができま す。詳しくは、ベクターまでお問い合わせください。 2.3 A2LコンテンツとECU実装の対比 2.3 A2LコンテンツとECU実装の対比 XCP マスターツールが ECU に完全に合致しない A2L で読込みを行うと、通信内での解釈違いが生じる可能性 があります。たとえば 、タイムスタンプの分解能に関連する別の値が 、ECU 内に実装される値と異なる A2L ファイル内にあることがあります。この場合 、問題を検出し、解決しなければなりません。ユーザーは、プロ トコル経由でスレーブに対してポーリングが可能なマスターの力を借りて 、スレーブ内に実際に何が実装さ れているかを判断します。 XCP は、スレーブの自動検出用に開発された複数の機能を提供します。もちろん 、これは自動検出がスレー ブ内に実装されていることを前提とします。マスターがスレーブに対してポーリングを行い 、スレーブのレス ポンスが A2L 記述ファイルのパラメーターセットと一致しない場合 、マスターは使用する設定を判断しなけれ ばなりません。CANape では、スレーブが読み取るこの情報は、A2L からの情報よりも高い優先順位が与えら れています。 以下に示すのは、スレーブ内の XCP 実装についての説明を行うために使用される可能性のあるコマンドの概 要です。 GET_DAQ_PROCESSOR_INFO DAQリストの一般情報を返す：MAX_DAQ 、MAX_EVENT_CHANNEL 、MIN_DAQ GET_DAQ_RESOLUTION_INFO DAQ/STIM 、タイムインターバル情報に対する ODT エントリーの最大パラメーター GET_DAQ_EVENT_INFO (Event_channel_number) 特定のタイムインターバルに対する情報を返す：タイムインターバルの名称と分解能 、このタイムインター バルへ割り当てられる可能性のある DAQ リストの数など GET_DAQ_LIST_INFO (DAQ_List_Number) 選択した DAQ リストの情報を返す：MAX_ODT 、MAX_ODT_ENTRIES は定義済み DAQ リストとして存在する 67 3 キャリブレーションコンセプト 68 3 キャリブレーションコンセプト ECU パラメーターは、ECU または ECU バリアントの開発中に採用され 、最適化される定数パラメーターです。 これは反復プロセスで 、測定と変更を繰り返すことでその間にパラメーターの最適値を見つけ出します。 キャリブレーションコンセプトは、ECU の開発／キャリブレーションフェーズにおいて 、ECU 内のパラメーター がどのようにして変更可能かという疑問に答えるものです。キャリブレーションコンセプトは 1 つだけでなく 複数存在し、どのコンセプトを使用するかは、通常 、使われるマイクロコントローラーの性能とリソースによ ります。 通常 、パラメーターは生産 ECU の FLASH メモリーに保存されます。基本となるプログラム変数はソフトウェ ア内の定数として定義されます。ECU 開発中に、実行時にパラメーターを変更可能にするには、RAM メモ リーを追加する必要があります。 キャリブレーションコンセプトは、以下のような疑問と関係があります。 パラメーターが最初にフラッシュから RAM への経路を見つける方法は？ マイクロコントローラーの RAM へのアクセス経路を変更する方法は？ RAM に同時に保存できる数より多いパラメーターが存在する場合のソリューションの形態は？ パラメーターをフラッシュへ再度コピーして書き戻す方法は？ パラメーターへの変更は恒久的なものか？ すなわち ECU の電源がオフになったときに保存されるか？ キャリブレーションコンセプトは、トランスペアレントと非トランスペアレントに区別されます。トランスペアレ ントでは、すべての必要なメカニズムは ECU 内に実装されているためキャリブレーションツールは上記の疑問 に関与する必要がないとされます。 以下にいくつかの手法を簡単にご紹介します。 3.1 フラッシュ内のパラメーター ソフトウェア開発者は、ソースコード内にあるパラメーターが可変か定数か（すなわち 、あるパラメーターが フラッシュに保存されるか 、RAM メモリーに保存されるか）を定義します。 C コードの例： const float factor = 0.5; 「 factor（因子）」パラメーターが 、値 0.5 で一定であることを示します。コードのコンパイル／リンク動作 中に、「 factor 」オブジェクトに対してメモリー空間がフラッシュ内に用意されます。このオブジェクトには FLASH メモリーのデータ領域内にあるアドレスが割り当てられます。値 0.5 は HEX ファイル内の該当するア ドレスにあり、このアドレスはリンカーマップファイルに存在します。 3.1 フラッシュ内のパラメーター 考え得るもっともシンプルなキャリブレーションコンセプトは、C コードで値の変更や新規 HEX ファイルの生成 とフラッシュ書込みに関するものです。しかし、この手法は非常に手間が掛かります。なぜなら、値の変更 はすべてコードで行わなければならず 、あとでフラッシュ書込みにおけるコンパイラー／リンカーの実行が必 要となるからです。代替的な手法は、HEX ファイル内の値変更のみを行い 、そのファイルをリフラッシュする ことでしょう。これはどのキャリブレーションツールでも可能であり、HEX ファイルの「オフラインキャリブレー ション」と呼ばれ 、非常に一般的に使用される手法です。 たとえば 、特定のコンパイラーの場合 、パラメーターも FLASH メモリーに必ず保存され 、コードに組み込ま れないようにして 、リンカーマップファイルに存在しないようにする必要があります。通常 、FLASH メモリー で定数が生成される場所に規則性がないことは好ましくありません。これを行うための必要な手段は、ほぼ 必ずと言っていいほどコンパイラー固有のプラグマ指示によるものです。コンパイラーがコード内にそれら を埋め込まないようにするには、通常は定数パラメーターに対して「 揮発」属性を使用すれば充分です。フ ラッシュ定数の一般的な定義は以下の例のように表示されます。 C コードの例： #pragma section“FLASH_Parameter” volatile const float factor = 0.5; 通常 、オンラインでフラッシュ内のパラメーターをキャリブレートすることはできません。実際 、大半のマイ クロコントローラーはフラッシュを自分自身でプログラムすることができ、これはそのフィールド内で再プログ ラミングを行うために必要です。それでも 、FLASH メモリーには大きなブロック（セクター）にデータがまと められ 、ブロック全体でしか消去できないという特性があります。ECU には通常 、残りのセクターをバッファー してそれを再プログラムするためのリソースはないため 、個別のパラメーターだけをフラッシュすることは実 際上不可能です。また 、このプロセスには大変時間が掛かります。 ECU の中には、EEPROM メモリーと呼ばれる、メモリー内にデータを保存する機能を持つものがあります。 FLASH メモリーと違い 、EEPROM メモリーは各メモリーセルを個別に消去およびプログラムすることができま す。利用できる EEPROM メモリーの量は常に、利用可能な FLASH メモリーよりも大幅に少なく、通常 、わず か数キロバイトに制限されます。EEPROM メモリーは、プログラム可能パラメーターをサービスショップで保 存するために、または ECU 内でオドメーターなど長期的に使用されるメカニズムの実装のために使用される ことが多くあります。オンラインキャリブレーションはここでも想定されますが 、ほとんど使われません。そ の理由は、EEPROM セルへのアクセスが比較的遅く、起動プロセス中に EEPROM パラメーターは通常 、RAM メモリーにコピーされ 、そこに直接アクセスできるためです。EEPROM メモリーを持たない ECU は、EEPROM エミュレーションと呼ばれる機能を実装している場合がよくあります。この方式では、複数のコンパクトなフ ラッシュセクターを交互に使用してパラメーターの変更を記録し、最後の有効な値を常に判断できるように なっています。この方式でもオンラインキャリブレーションが想定できます。 いずれの場合でも 、該当するメモリーアクセスが XCPドライバーのソフトウェアコンポーネント内で傍受さ れ 、EEPROM または EEPROM エミュレーションのソフトウェアルーチンにより実装されます。ベクターの XCP プロフェッショナルドライバーは、これに必要なソフトウェアフックを提供します。 69 3 キャリブレーションコンセプト 70 3.2 RAM内のパラメーター 実行時のパラメーター変更（「 オンラインキャリブレーション」）にもっとも頻繁に使用される手法は、利用可 能な RAM メモリー内でパラメーターを作成することです。 C コードの例： #pragma section“RAM_Parameter” volatile float factor = 0.5; これにより、パラメーター「 factor（因子）」が初期値 0.5 の RAM 変数として定義されます。コードのコンパ イルおよびリンク中 、メモリー空間が RAM 内のオブジェクト「 factor 」に対して予約され 、対応する RAM アド レスがリンカーマップファイル内に作成されます。初期値 0.5 は FLASH メモリー内で 、HEX ファイルの該当 する位置に保存されます。FLASH メモリー内の初期値のアドレスはリンカーのパラメーター化によって定義 されますが 、リンカーマップファイル内には作成されません。 ECU の起動中 、すべての RAM 変数は、FLASH メモリーからの初期値により1 回初期化されます。これは通 常 、コンパイラープロデューサーの起動コード内で実行され 、アプリケーションプログラマーがこれを考慮 する必要はありません。このアプリケーションは RAM 内にあるパラメーターの値を使用し、この値は通常の XCP メモリーアクセスにより変更できます。 ECU ソフトウェアの観点からは、RAM 内のキャリブレーションパラメーターは依然として変更されません。す なわち 、アプリケーション自体はキャリブレーションパラメーターを変更しません。多くのコンパイラーはこ の事実をコード解析により発見し、単純に必要な RAM メモリー空間を最適化により除去します。したがって 通常 、コンパイラーが「 不揮発性」の属性を使用して最適化しないようにする必要があります。 キャリブレーションツールの観点からは、パラメーターが配置されている RAM 領域はキャリブレーション RAM （キャリブレーション可能なメモリー）として参照されます。 FLASH RAM Calibration RAM Parameters 図51: RAM内の初期パラメーター設定 3.2 RAM内のパラメーター キャリブレーション RAM は完全に連続した RAM 領域で構成される必要はなく、複数領域に分散されたり、任 意の希望する方法で分散したりしてもかまいません。それでも 、パラメーターを数か所だけの連続 RAM 領 域に抑えて配置し、状態変数や中間結果の変更など他の RAM パラメーターと分けることで 、大きなメリット があります。これは、HEX ファイルによるキャリブレーション RAM のオフラインキャリブレーションを有効にす る場合に、特に重要です。ユーザーの要求により、キャリブレーションツールは、オフラインキャリブレーショ ンからオンラインキャリブレーションへの移行中に、オフラインに変更したパラメーターを ECU へロードでき るようにしなければなりません。 このケースは頻繁に発生します。たとえば 、キャリブレーション担当者が次の日に ECU と再接続する際 、前日 の夜に作業を終了した箇所から作業を再開したいとしましょう。しかしこの場合 、ECU を起動すると、フラッ シュしたコンテンツが初期データセットとして RAM にコピーされてしまいます。担当者が前日に終わった作業 を再開できるようにするには、前日夜に ECU の RAM に保存したパラメーターセットファイルをロードしなけれ ばなりません。このローディングプロセスは、必要な伝送数を最小限に制限することで時間を最適化するこ とができます。この場合 、ツールが広範囲の連続領域にチェックサムを形成することで差異の有無を短時間 で確実に判断できるとすれば便利です。ECU 内のキャリブレーション RAM のコンテンツと、ツールで変更した ファイルに差異がない場合は、この領域を転送する必要はありません。キャリブレーションパラメーターを持 つメモリー領域が明確に定義されていない場合 、または ECU ソフトウェアが変更したパラメーターを含んで いる場合は、必ずチェックサム計算によって差異が示され 、ECU から XCP マスターに、またはその反対方向に パラメーター値が転送されます。転送速度とデータ量によっては、この転送に数分かかることがあります。 さらに、明確に定義されたメモリーセグメントには、FLASH メモリー内の初期値に対するメモリー領域をオフ ラインキャリブレーションで使用できるというメリットもあります。FLASH メモリーのコンテンツは、フラッシュ 可能 HEX ファイルを使用して定義します。キャリブレーションツールが HEX ファイル内のパラメーターの位置 を知っていれば 、変更された HEX ファイルをフラッシュすることでその値を変更し、ECU 内に新しい初期値を 適用することができます。 キャリブレーションツールは、RAM 内のパラメーターの位置だけでなくフラッシュ内の初期値を知る必要が あります。RAM メモリーセグメントは、大半のコンパイラー／リンカーにおける通常の動作と同じく、フラッ シュ内にまったく同じように展開されたメモリーセグメントからのコピーによって初期化されなければなりませ ん。RAM 内のパラメーターのアドレスが A2L ファイル内にある場合 、必要なのはツールにキャリブレーション RAM の開始アドレスへのオフセットを通知することだけです。このオフセットは関連するフラッシュ領域の開 始アドレスに到達するために追加されなければなりません。次に、このオフセットが A2L 内の個別の各パラ メーターに適用されます。 その後 、キャリブレーションツールはこの領域自体に対するフラッシュ可能な HEX ファイルを生成するか 、ま たはリンカーの元の HEX ファイルに直接ファイルを配置し、HEX ファイル内のパラメーターの初期値を変更 することができます。 71 3 キャリブレーションコンセプト 72 3.3 フラッシュオーバーレイ 多くのマイクロコントローラーには、メモリー領域を内部または外部 RAM でオーバーレイするためのオプショ ンが用意されています。このプロセスはフラッシュエミュレーションまたはフラッシュオーバーレイと呼ばれ ています。メモリー管理ユニットの使用からこの目的に正確に合った専用メカニズムまで 、多くのことが可能 です。この場合 、パラメーターはキャリブレーションコンセプト 1（本書の第 3 章 1「 フラッシュ内のパラメー ター」）にあるように、フラッシュ内のパラメーターとして生成されます。この方法には、すでに説明したキャ リブレーションコンセプト 2（本書の第 3 章 2「 RAM 内のパラメーター」）に比べ 、以下のような非常に大きな メリットがあります。 > フラッシュアドレスと RAM アドレス間に区別は設けられず 、フラッシュアドレスは常に A2L ファイルや HEX ファイル、リンカーマップファイル内にあります。これによって明確な関係が生まれます。HEX ファイル は直接フラッシュすることができ 、A2L ファイルはそれと完全に一致します。 > オーバーレイは全体として有効化または無効化が可能で 、フラッシュ内の値と RAM 内の値を超短時間で スワップできるようになります。これはメモリーセグメントの RAM ページおよびフラッシュページと呼ば れています。XCP は 、メモリーページスワッピングの特殊コマンドによる制御をサポートしています。 > メモリーページは個別に（ XCP アクセスと ECU アクセス用など）スワップできる場合もあります。すなわ ち 、XCP は ECU ソフトウェアがもう一方のページの作業を行っている間にメモリーページにアクセスでき るということです。これにより、ECU がまだフラッシュデータの作業を行っている間に、RAM へのオフラ インキャリブレーションデータのダウンロードなどの操作を行うことが可能になり、ECU 実行中に問題とな る可能性がある不整合を回避できます。 > RAM とのオーバーレイは完全である必要はなく、適用ケースに合わせることができます。フラッシュより も RAM との連動した動作を少なくすることも可能です。これについてはこの後で詳しく説明します。 キャリブレーションツールを ECU へ接続し、オフラインでキャリブレートされた値のダウンロードを行うための 一般的な手順は、以下のとおりです。 ECU に接続 CONNECT XCP マスターを RAM ページに接続 SET_CAL_PAGE XCP to RAM チェックサム計算 CALC_CHECKSUM RAM 領域に対するチェックサム計算で差異が検出された場合 、通常はまず 、どのような処理を行うかをユー ザーに問い合わせます。ECU RAM のコンテンツをマスターに送信するか 、またはマスターページのファイル のコンテンツを ECU の RAM に送信するか？ ユーザーがオフライン変更を ECU へ書き込むと決定した場合 、次 に行うプロセスは以下のとおりです。 ECU がフラッシュページのデータセットを使用 SET_CAL_PAGE ECU to FLASH マスターから RAM ページにファイルをコピー DOWNLOAD … ECU が RAM ページのデータセットを使用 SET_CAL_PAGE ECU to RAM その後 、メモリーページはパラメーターが変更できるよう、常に RAM に切り替わります。しかし、ユーザー は ECU 内で有効にするメモリーページを明示的に示すこともできます。たとえば 、RAM パラメーターセット の挙動はフラッシュパラメーターセットの挙動と比較するか 、または緊急の場合にはきわめて短時間でフラッ シュ内の実証済みのパラメーターセットに切り替えて戻すことができます。 3.4 動的フラッシュオーバーレイの割り当て 3.4 動的フラッシュオーバーレイの割り当て これまで説明したキャリブレーション RAM のコンセプトは、すべてのパラメーターに対して充分な RAM が利 用可能であれば不具合は生じません。しかし、パラメーターの総数が利用可能な RAM 領域と合わない場合 はどうなるでしょうか？ この場合 、RAM によるフラッシュのオーバーレイを動的に行い 、パラメーターへの実際の書込みアクセスが 発生するまで 、該当する FLASH メモリーを RAM でオーバーレイしないよう推奨します。この手順は一定の時 間間隔で発生することがあり（実装によって異なる）、XCP の観点からは、キャリブレーションツールに対して トランスペアレントでかまいません。変更に繋がる可能性のあるフラッシュへの書込みアクセスを XCPドライ バーが ECU 内で検出する場合 、キャリブレーション RAM の一部によってフラッシュの該当部分にコピーされ 、 その部分に対するオーバーレイメカニズムが有効になります。これは RAM の割り当て（ = 固定された配置） を必要とし、使用済みとして識別されます。しかし、キャリブレーション RAM のリソースは限られています。 キャリブレーションプロセスの間 、すでに割り当てられている RAM 領域が開放されることはなく、さらに要求 が繰り返されると利用可能なキャリブレーション RAM は次第に少なくなります。RAM リソースがすべて使用 され 、新規の割り当てが要求されると、ユーザーに RAM リソースの枯渇が通知されます。ユーザーにはそ の時点までに行われた変更をフラッシュするか 、保存するかの選択肢が提示されます。これにより、割り当て られた RAM 領域が再び開放され 、ユーザーは再度キャリブレートすることができます。ECU がそれまで変更 されたパラメーターを自発的にフラッシュするバージョンは、キャリブレーションコンセプト「 フラッシュ内の パラメーター」ですでに説明した理由により、通常ここでは除外されます。 一部のケースでは、オフラインで生成されたパラメーターセットのダウンロードは RAM リソースが充分でな いことから実行不可能である場合もあります。唯一の代替手段はそれをフラッシュすることです。ユーザー は常にツールからその変更をキャンセルすることができ、これにより、割り当てられた RAM ブロックが再度開 放されます。 このコンセプトでは、RAM ページとフラッシュページ間のページスワッピングも制限なく行うことができます。 パラメーターは、利用可能な RAM ブロックを可能な限り効率的に使用できるように、機能に応じてフラッシュ 内でまとめて整理されていることが必要です。次に、ソフトウェア開発者は同じテーマに属するパラメーター も連続したメモリー領域に配置されるように指定します。RAM へのコピー後 、特定の機能のチューニングに 必要なパラメーターが完全に使用準備完了の状態になります。 73 3 キャリブレーションコンセプト 74 3.5 AUTOSARによるRAMポインターベースキャリブレーションコンセプト このコンセプトには、AUTOSAR オペレーティングシステムの使用が絶対に必要というわけではありません。 異なる環境（オペレーティングシステムがない場合など）であっても使用することができます。このコンセ プトはこれまでのコンセプトと基本的には似ていますが 、大きく違うのは、RAM に対するフラッシュの置換が ハードウェアメカニズムによってではなく、ソフトウェアメカニズムによって行われるということです。キャリ ブレーションパラメーターは常に、ECU ソフトウェアからのポインターによって参照されます。フラッシュコン テンツまたは RAM コンテンツには、このポインターを変更することでアクセスします。変更対象のフラッシュ パラメーターは、利用可能な RAM により定義されたブロックにコピーされます。この方法は、これまでの方 法とまったく同様に、XCP の観点からは完全にトランスペアレントな形で実装することができます。その代わ りの手段としては、キャリブレーションツールのユーザーが必要なパラメーターをあらかじめ選択しておくこ とで 、明示的に変更対象のパラメーターを選択することができます。これのメリットは、ユーザーはリソース の使用とローディングが視覚化できることで 、これにより、ユーザーは作業途中でメモリー不足に驚かされる ことがなくなります。 3.5.1 シングルポインターコンセプト このポインターテーブルは RAM 内にあります。ECU の起動時、すべてのポインターがフラッシュ内のパラ メーター値を示します。キャリブレーション R AM の位置とパラメーターは実際には分かっていますが 、 この時点では起動後まではパラメーター値が一切含まれていません。アプリケーションはまず、完全にフ ラッシュから動作します。 FLASH Pointertable Parameters RAM 図52: 起動後の初期状況 起動後、初めてユーザーが A2L ファイルからパラメーターを選択し、それに書込みアクセスしようとしたと きに 、まず ECU 内でのコピー動作を起動します。XCP スレーブはアクセス対象のアドレスがフラッシュ領域 にあると判断し、パラメーター値をキャリブレーション RAM にコピーします。アプリケーションがフラッ シュからパラメーター値をそれ以上取得せず、代わりに RAM 領域から取得するようにするため 、ポイン ターテーブルにも変更を行います。 3.5 AUTOSARによるRAMポインターベースキャリブレーションコンセプト FLASH Pointertable 75 RAM 図53: ポインター変更と Parameters RAMへのコピー アプリケーションは 、パラメーター値をポインターテーブルから引き続き取得します。しかし、ポインター は RAM アドレスを示すため 、値はここから取得されます。その結果 、ユーザーは XCP によりパラメーター 値を変更し、測定時に変更がもたらす効果を観察することができます。この方法のデメリットは 、ポイン ターテーブル内のエントリーが各パラメーターに対して利用可能でなければならず、この方法はポインター テーブルに対する RAM メモリー要件を大幅に増加させるということです。 次の図はこの問題について示しています。PID コントローラーの 3 つのパラメーター (P 、I 、D) が、ECU のフ ラッシュデータ内にあります。RAM 内の RAM アドレスとパラメーター値もすでにポインターテーブル内で 変更されています。 Parameter Flash Pointertable RAM Addr. Content Addr. Addr. Content P 0x0000100A 0x11 0x000A100A 0x000A100A 0x44 I 0x000012BC 0x22 0x000A100B 0x000A100B 0x55 D 0x00007234 0x33 0x000A100C 0x000A100C 0x66 図54: 個別パラメーターのポインターテーブル RAM リソースは限られているため 、キャリブレーションコンセプトは非常に重要です。RAM ポインターテー ブルを大きくすると、コンセプトの自滅を招くことがあります。 各個別パラメーターに対してポインターを作成したり、そのように使用する必要をなくすため 、パラメー ターを構造に結合することができます。これには構造 1 つにつき 1 つのポインターのみ必要となります。 ユーザーがパラメーターを選択する際は 、このパラメーターが RAM にコピーされるだけでなく、関連する 構造全体がコピーされます。この場合、構造の精度が重要性を持ちます。大きな構造であっても 、必要な ポインターはわずかです。またこれは 、特定のパラメーターを使用しようとする場合に 、比較的大きなサイ ズの関連構造が RAM 領域にコピーされることで、キャリブレーション RAM 空間の制限に短時間で達してし まうことを意味します。 3 キャリブレーションコンセプト 76 例： キャリブレーション RAM のサイズは 400 バイトとします。下記のパラメーターを持つソフトウェアで 4 つの 構造が定義されています。 構造 A：250 バイト（ byte ） 構造 B：180 バイト（ byte ） 構造 C：120 バイト（ byte ） 構造 D：100 バイト（ byte ） ユーザーがパラメーターを構造 A より選択すると、フラッシュからキャリブレーション RAM へ 250 バイト がコピーされ 、ユーザーは構造 A 内にあるすべてのパラメーターへの XCP アクセスを取得します。キャリブ レーションタスクがこの構造のパラメーターに限定される場合、キャリブレーション RAM は完全に充足さ れています。ただし、ユーザーが別の構造にある他のパラメーター、たとえば構造 C を選択する場合、これ らの 120 バイトもキャリブレーション RAM にコピーされます。キャリブレーション RAM が対応できるのは 400 バイトであるため 、ユーザーは構造 A と構造 C のすべてのパラメーターに同時にアクセスが可能です。 選択した別のパラメーターが構造 C にはなく構造 B にある場合、構造 A の 250 バイトに加え、構造 B の 180 バイトを RAM にコピーする必要があります。しかし、RAM 空間がこれに足りない場合は ECU がコピーコマ ンドを実行できないため 、ユーザーは構造 A のパラメーターにはアクセスできますが、構造 B のデータに はアクセスできません。 本件に関する CANape でのアプローチ方法についての詳細は 、CANape で「 AUTOSAR シングルポインター デモ 」というプロジェクトを立ち上げていただき、 「 イントロダクション」のページでご覧ください。 ベクター Web サイト内「 ダウンロードセンター」の種類項目より「 デモ 」をお選びいただきますと、ソース コードサンプルがございます。キャリブレーションコンセプトの使用法に関するコード例は「 XCP Sample Implementation 」にあります。 3.5.2 ダブルポインターコンセプト シングルポインターコンセプトのデメリットは 、メモリーページスワッピングの実装が簡単ではないという ことです。キャリブレーションツールはページスワッピングに対して完全なポインターテーブルを簡単に記 述することはできますが、一時的な不整合や副作用なく短期間で実現するのは無理です。ツールトランス ペアレントな実装は 、そのポインターテーブルに対するメモリー空間要件を倍加させることがあります。そ れはメモリーページをスワップする際に 、それまでのポインターテーブルのコピーを RAM ポインターで作成 する必要があるためです。 大きなポインターテーブル、トランスペアレントな実装、または完全に安定したスワッピングを持つアプリ ケーションの場合、その方法をダブルポインターコンセプトに拡張するオプションがあります。これを行う 方法を説明するため 、再度ここで初期 RAM 設定の話に戻ります。 3.6 フラッシュポインターベースのキャリブレーションコンセプト 77 図 55 はポインターテーブルを表しています。これは RAM 内にあります。すでに説明したように 、このテー ブルはフラッシュから RAM へコピーしなければなりません。その結果 、このテーブルは FLASH メモリー内 に置かれます。ここで、RAM 内またはフラッシュ内いずれかのポインターテーブルを指す別のポインター を使用する場合（ テーブルポインター）、それがダブルポインターソリューションとなります。 FLASH Pointertable FLASH RAM Pointertable RAM Tablepointer 図55: ダブルポインターコンセプト パラメーター値は最初はテーブルポインターによりアクセスします。テーブルポインターが RAM 内のポイン ターテーブルを示す場合、アプリケーションは基本的に 、RAM ポインターテーブルのコンテンツにより実際 のパラメーターにアクセスします。アクセス速度が低いことと、プログラムコードの作成量が増えることが このソリューションのデメリットです。 3.6 フラッシュポインターベースのキャリブレーションコンセプト この方法は 、ZF 社が「 InCircuit2 」の名称で数年前に特許を取得しており、AUTOSAR のポインターベース コンセプトに非常によく似ています。ここでも 、ECU 内のアプリケーションがポインターテーブルを使用し てパラメーターデータにアクセスします。しかし、このポインターテーブルは RAM 内にはなく、フラッシュ 内にあります。したがって、ポインターテーブルへの変更はフラッシュプログラミングでのみ行うことがで きます。ツールトランスペアレントな実装は行うことができません。RAM メモリーにはポインターテーブル がすでに含まれていないため 、メリットは保存された RAM メモリー内にあります。 本件の CANape でのアプローチ方法についての詳細は 、CANape で「 InCircuit2 」というプロジェクトを立 ち上げていただき、 「 イントロダクション」のページでご覧ください。 4 XCPの応用分野 78 4 XCPの応用分野 ECU キャリブレーション担当者が XCP の使用を考える場合 、それは通常 、ECU 内のプロトコルの使用に限定さ れます。 Simulink Slave Slave XCP PC Slave Master Prototype or ECU Hardware Measurement/ Calibration Hardware* EXE/DLL Slave HIL/SIL Systems Slave * Debug Interfaces, Memory Emulator, ... 図56: 応用分野と応用ケース 開発プロセスにおいて 、電子機器とソフトウェア開発のためのソリューション手法にはさまざまなものがあり ます。この場合 、HIL (Hardware-in-the-Loop) 、SIL (Software-in-the-Loop) 、ラピッドプロトタイピング がキーワードで 、それぞれに異なるシナリオがあります。共通で必ず 、 「 プラント」と「 コントローラー」があ ります。 Offset Reference Variable (Set Value) Manipulated Variable Controller Disturbance Variable Plant Controlled Variable (Actual Value) 図57: プラントとコントローラー 自動車開発で使われる場合 、コントローラーは ECU のことであり、プラントはトランスミッション、エンジン、 サイドミラーなどの制御される物理的なシステムのことです。 コントローラーまたはプラントが実際に実行されるのか 、またはシミュレーションモードで実行されるのかに応 じて 、さまざまな開発手法の中におおまかな分類があります。いくつかの組み合わせを詳しく説明します。 4.1 MIL：Model in the Loop 79 4.1 MIL：Model in the Loop Simulink Controller Model Plant Model 図58: Simulink環境でのMIL この開発環境では、コントローラーとプラントがモデルとしてシミュレートされます。図の例では、両方のモ デルがランタイム環境として Simulink 内で実行されています。Simulink ランタイム環境で 、振る舞いを解 析することができます。 開発の初期段階で XCP スレーブをコントローラーモデル内に統合すれば 、CANape のような測定／キャリブ レーションツールの便利さを実感することができるでしょう。オーサリングステップでは、スレーブはモデル に合った A2L を生成し、ユーザーはグラフィック Window でプロセスフローを見ながら特性カーブやマップな どにアクセスでき、あらゆる種類の便利な操作が可能です。 Simulink CANape A2L Controller Model Simulink XCP Server Plant Model 図59: Simulinkモデルを持つ測定／ キャリブレーションツール としてのCANape コード生成作業もモデル動作ハードウェアも必要ありません。XCP を介した送信にはタイムスタンプも含ま れています。CANape は、Simulink のランタイム環境の時間挙動にも完全に適応します。モデルがリアル タイムよりも速く、あるいは遅く動作していても関係ありません。たとえば 、もし機能の開発者がモデルに Simulink Debugger を使用していても 、CANape は参照時間として XCP 経由で時間同期を行い 、送信し ます。 4 XCPの応用分野 80 4.2 SIL：Software in the Loop Simulink Controller Model Plant Model Code generation Controller Model Windows DLL 図60: Simulink環境でのSIL この開発ステップでは、コードがコントローラーのモデルから生成され 、PC ベースのランタイム環境内で使 用されます。当然 、コントローラーもモデルベースの手法を使用しないで開発されたものかもしれません。 プラントはシミュレーションされ続けます。XCP は、コントローラーの測定／キャリブレーションに使用するこ とができます。コントローラーが Simulink モデルをベースにしている場合 、コード生成ステップ（ターゲッ ト「 CANape 」による Simulink Coder ）を使用して 、DLL と関連する A2L 用の C コードを生成します。コント ローラー開発が人間の手で書かれたコードをベースにして行われる場合 、CANape に添付されている C++ プ ロジェクト内に埋め込まれます。 コンパイル／リンク後 、その DLL は CANape のコンテキスト内で使用されます。XCP 接続をサポートしている ため 、アプリケーションがすでに ECU 内に統合されていたかのように、DLL 内のアルゴリズムを正確に測定／ キャリブレートできます。 Simulink Controller Model Plant Model Code generation A2L CANape Controller Model Windows DLL 図61: SIL開発プラットフォームとして のCANape 4.3 HIL：Hardware in the Loop 81 4.3 HIL：Hardware in the Loop HIL システムには、さまざまな種類が用意されています。非常にシンプルで低コストのシステムから、大規模 で高価な拡張ステージまで広い範囲に及びます。以下の図はおおまかなコンセプトを示しています。 Controller Model HIL Platform I/O Plant Model 図62: ECU HILソリューション コントローラーアルゴリズムは、マイクロコントローラープラットフォーム（ ECU など）の中で実行されます が 、プラントはシミュレーションされ続けます。パラメーターやプラントおよび必要な I/O の複雑さに応じて 、 HIL プラットフォームの要件と付随するコストが急激に上がることがあります。ECU はリアルタイムで実行さ れるため 、プラントのモデルもリアルタイムで計算しなければなりません。 この場合 、最適化のために XCP を導入することは、別の ECU が追加されているために重要でないように見え ます。全体システムは図 63 のようになります。 A2L Controller Model HIL Platform I/O CANape Plant Model ECU 図63: 測定／キャリブレーション ツールとしての CANape付きHIL ユーザーは、CANape から XCP 上の ECU 内のアルゴリズムにアクセスできます。 4 XCPの応用分野 82 ベクターツール CANoe も HIL システムとして多くのお客様に使用されています。CANoe を使用する場合 、 HIL システムは図 64 のようになります。 CANoe RT User PC Ethernet CANoe RT Server CAN Plant Model Digital I/O Analog I/O LIN A2L MOST FlexRay XCP ECU CANape 図64: HILシステムとしてのCANoe テスト目的で CANoe から直接 XCP データにアクセスする機能の場合 、図 65 のような組み合わせにもなり ます。 CANoe RT User PC A2L Ethernet CANoe RT Server CAN Plant Model Digital I/O Analog I/O LIN MOST XCP FlexRay 図65: ECU HILシステムとしての CANoe （ECUへのXCPアクセス付き） この場合 、プラントのモデルが CANoe リアルタイムサーバー上で実行されます。同時に、ECU への XCP アク セスも CANoe から実現します。これにより、プラントとコントローラーへの同時アクセスができるツールが利 用できるようになります。 4.4 RCP：ラピッドコントロールプロトタイピング 83 仕上げに、もう 1 つのソリューションオプションに言及しなければなりません。プラントが CANape 内の DLL と して実行されることもあります。これにより、ユーザーはプラントとコントローラーに XCP 上でフルアクセス できます。 ECU A2L CANape Plant Model Windows DLL XCP Plant 図66: A2L XCP ECU HILソリューションとしてのCANape 4.4 RCP：ラピッドコントロールプロトタイピング この開発フェーズでは、コントロールアルゴリズムが ECU ではなく、リアルタイムハードウェア上で実行され ます。この状態は、必要な ECU ハードウェアがまだ利用できない場合によく起こります。簡単な評価ボード から特殊な自動車レベルのハードウェアソリューションまで 、実施する必要がある追加要件に応じて適切な ハードウェアとして考慮できるプラットフォームがいくつかあります。ここでも 、XCP による統合はメーカーに 依存しないツールチェーンをセットアップする場合に役立ちます。 Controller Model A2L CANape EVA Board XCP I/O Plant 図67: RCPソリューション 「 ラピッド」と「 プロトタイピング 」というコンセプトがこのタスクを非常によく表しています。正常に機能す るプロトタイプをできるだけ短時間で開発し、それをランタイム環境で使用し、テストすることが目的です。 これには、全体プロセスを通してシンプルな作業ステップのみを必要とします。 4 XCPの応用分野 84 RCP 手法は文字通り、フルパスとバイパスの 2 つの領域に細分化されることがよくあります。 図 67 に示されているとおり、コントローラー全体が独立したリアルタイムハードウェア上で実行されます。こ の方法は、コントローラー全体がコントローラーハードウェア上で実行されるため 、フルパスと呼ばれていま す。この場合 、必要な I/O をプラントとインターフェイス接続できるようにしなければなりません。ほとんど の場合 、適切な電源機器がなければ 、この I/O に対する技術要件を満たすことができません。 難しいのは I/O だけではありません。多くの場合 、複雑なネットワークで機能させるためには、ECU ソフトウェ アの機能要素（ネットワーク管理など）が必要です。しかし、ラピッドコントロールプロトタイピングに、一般 的なコントローラープラットフォームではなくECU 本体を使用する場合 、フラッシュプロセスの複雑さ、全体 ソフトウェアのサイズなどすべてが「 ラピッド ( 短時間 ) 」な開発の要件に反することになります。 まとめると、そのコントローラーに対するランタイム環境として ECU 本体を使用すると、そのプラントに対し て必要なハードウェアおよびソフトウェアインフラストラクチャーが存在するというメリットが生まれます。デ メリットは複雑さが増すということです。 バイパスのコンセプトは、複雑さが増すというデメリットに苦しめられることなく、ECU インフラストラクチャー のメリットを活用するために開発されました。 4.5 バイパス 図 68 では、ECU はプラントに接続されています。必要な I/O とソフトウェアコンポーネントは ECU 内で利用 可能です。バイパスするハードウェア内では、アルゴリズム A1 が実行され 、これが ECU のバージョン A 内で 存在します。A1 はアルゴリズムの新しいバージョンで 、ここで実際のプラント上で試してみる必要があります。 ECU Bypassing Hardware A2L CANape XCP Bypassing Hardware A2L XCP I/O Controller Model ECU 図68: バイパスの基本原理 Plant 4.5 バイパス 85 バイパスするハードウェア（図 68 ではベクターの VN8900 ）と ECU は XCP 上で相互接続されます。ここでの 目標の 1 つは、DAQ により ECU からアルゴリズム A1 に必要なデータを取得することであり、もう 1 つの目標 は A1 の結果を ECU にスティミュレートすることです。以下の図はフローの概要を示しています。 Bypassing Hardware Bypassing Coordinator 2. Algorithm A1 3. 1. XCP 4. Algorithm A ECU 図69: バイパスフロー ECU 内に図示されているのは青色の機能ブロックで 、その中でアルゴリズム A が実行されています。ここで A1 を使用可能にするために、データが入力変数としてアルゴリズム A に入り、DAQ によりECU から測定され ます。ステップ 1 では、バイパスコーディネーターがデータを受け取り、ステップ 2 でそのデータをアルゴリ ズム A1 に渡します。A1 はバイパスハードウェアによって計算され 、ステップ 3 でその結果がバイパスコーディ ネーターに戻され 、ステップ 4 でそれが STIM によって ECU に転送されます。このデータはスレーブ内の次の 機能ブロックが入力変数を待ち受ける「 位置」に書き込まれます。これにより、ECU の全体制御プロセス内で アルゴリズム A によるものではなく、アルゴリズム A1 により計算された値を使用できるようになります。この 方法によって 、I/O と ECU のベーシックソフトウェアが含まれるバイパスハードウェア上でアルゴリズムの短時 間での置き換えの組み合わせが使用できるようになります。 4 XCPの応用分野 86 XCP-on-CANドライバーの性能限界も当然 、バイパスに影響を与えます。バイパス時間を短くする必要があ る場合 、DAQ と STIM による ECU へのアクセスもコントローラーのデバッグインターフェイスまたはトレースイ ンターフェイスにより実行することができます。ベクター VX1000 測定／キャリブレーションハードウェアは、 データをコントローラーインターフェイスから XCP-on-Ethernet データストリームに変換します。このプロセ スにおいて 、ECU に最大で 1MB のデータを伝送することができます。 Bypassing Hardware A2L CANape XCP Bypassing Hardware XCP Measurement & Calibration Hardware VX1000 Debugging and Trace Interface I/O Controller Model ECU 図70: リアルタイムバイパスハードウェアと高速ECUアクセスによるバイパス Plant 4.6 バーチャルECUによる繰り返しサイクルの短縮 87 4.6 バーチャル ECU による繰り返しサイクルの短縮 データによるスティミュレーションは、XCP を使用して ECU 内のアルゴリズムを最適化するために必要です。 これは、テストドライブのフレームワーク内の ECU で行うことができます。 他にも 、XCP で利用可能なソ リューションがあります。たとえば 、アルゴリズムは ECU 上で実行せず 、実行可能なコード形式または「 仮想 ECU 」の形式で Simulink 内のモデルとして PC 上で実行されます。この場合 、実際のシステムに接続しない ため 、この仮想 ECU はリアルタイムで実行される必要はありません。これは、PC の処理能力に応じて非常に 高速で実行させることができます。 このアルゴリズムは以前に記録された測定ファイルによってスティミュレートされ 、そのファイルにはアルゴリ ズムの入力シグナルとして必要な 、すべてのシグナルが含まれています。CANape への接続は XCP 上でセッ トアップされます。ユーザーは、パラメーター化と測定コンフィギュレーションを行うことができます。その 後 、実行が開始されます。そして 、テストドライブからのデータがスティミュレーションとしてアルゴリズムに 入力され 、アプリケーションからの必要な測定パラメーターが同時に測定 、出力されて測定ファイルに保存 されます。 Parameter MDF test drive Application 5. Analyze 1. Set parameters 2. Start CANape 3. Send test drive data Simulink/ DLL 4. Measurement data Slave New MDF 図71: 仮想ECUによる短い キャリブレーションサイクル 4 XCPの応用分野 88 計算の完了後 、新しい測定ファイルが利用可能になり、ユーザーが ECU の振る舞いの解析を行うことができ ます。新しい測定ファイルの時間の長さは、入力測定ファイルの長さと正確に一致します。テストドライブの 時間の長さが 1 時間の場合 、PC 上のアルゴリズムはわずか数秒間でテストドライブ全体を計算できる場合も あります。これで 、1 時間のテストに相当する測定結果が得られます。このデータ解析に基づき、ユーザー はパラメーター化と繰り返しサイクルの反復についての判断を行います。 CANape Application as EXE or DLL on PC Parameterization via XCP Set values in workspace Start Start Send measurement data Calculate model Receive new measurement data Send measurement values from the model Analyze the new data End model calculation 図72: New software version 仮想ECUによる プロセスフロー 4.6 バーチャルECUによる繰り返しサイクルの短縮 繰り返しサイクルを短縮するために、アルゴリズムは常に同じデータでスティミュレートされます。これによ り、異なるパラメーターを持つ結果を比較しやすくなります。その結果が異なるパラメーターによってのみ 、 影響を受けているからです。 このプロセスはもちろん自動化できます。CANape の統合スクリプト言語がこの測定結果の解析を行い 、そ の結果からパラメーターキャリブレーション設定が取得され 、自動的に実行されます。CANape 自動インター フェイス上の MATLAB などの外部最適化ツールにより、プロセスを制御させることも可能です。 89 5 XCPの実装例 90 5 XCPの実装例 ECU が XCP 上で通信できるようにするためには、ECU のアプリケーション内に XCPドライバーを統合する必要 があります。以下は、ベクター Web サイト (www.vector-japan.co.jp/xcp-driver) のダウンロードセンター から無償でダウンロードできる XCPドライバーの例です。このパックには、各種トランスポートレイヤーとター ゲットプラットフォームの実装例も数種類含まれています。このドライバーは、測定／キャリブレーションに必 要な基本機能を持つプロトコルレイヤーで構成されています。これには、コールドスタート測定 、スティミュ レーション、またはフラッシュ書込みなどの機能は含まれていません。完全な実装をご希望の方は、ベクター の CANbedded または AUTOSAR 環境に統合される製品としてご購入いただけます。 XCP プロトコルレイヤーは XCPトランスポートレイヤーの上に位置し、トランスポートレイヤーは実際のバ ス通信に基づいています。XCP プロトコルレイヤーの実装は、単一の C ファイルといくつかの H ファイル (xcpBasix.c 、xcpBasic.h 、xcp_def.h and xcp_cfg.h) のみで構成されています。この例には、Ethernet や RS232 などの各種トランスポートレイヤーの実装が含まれています。通常 、CAN の場合 、トランスポート レイヤーは非常にシンプルで 、各種 XCP メッセージタイプが直接 CAN メッセージにマッピングされます。ま た 、Tx と Rx 方向には独立した固定識別子があります。 トランスポートレイヤーとプロトコルレイヤー間のソフトウェアインターフェイスは非常にシンプルで 、以下の ように、わずか数種類の機能しかありません。 > スレーブが XCP メッセージをバス上で受信すると、まず通信ドライバーに到達し、そこから XCPトランス ポートレイヤーへとメッセージが転送されます。トランスポートレイヤーは関数呼び出し XcpCommand() により、プロトコルレイヤーにメッセージに関する情報を通知します。 > XCP プロトコルレイヤーがメッセージを送信したい場合は（ マスターから XCP コマンドへのレスポンスまた は DAQ メッセージ）、ApplXcpSend() 関数を呼び出すことでメッセージがトランスポートレイヤーに転送 されます。 > トランスポートレイヤーは関数呼び出し XcpSendCallBack() により、プロトコルレイヤーにメッセージの 送信が完了したことを通知します。 5 XCPの実装例 91 XcpSendCallback XcpCommand ApplXcpSend XCP Protocol Layer Application - XCP Transport Layer Interface ApplXcpGetPointer XcpBackground XcpInit XcpEvent Application XCP Transport Layer Physical Layer 図73: Bus XCPスレーブの ECUコード内への組込 アプリケーションとプロトコルレイヤー間のインターフェイスは 、下記 4 つの関数によってのみ実装でき ます。 > XcpInit（ ）を使用して 、アプリケーションが XCPドライバーを有効にします。この呼び出しは起動プロセ ス時に 1 回行われます。 > XcpEvent（ ）を使用して 、アプリケーションが XCPドライバーに何らかのイベントが発生したことを通知し ます（「 計算サイクルの最後に達した 」など）。 > 呼び出し XcpBackground（ ）により、XCPドライバーは何らかのアクティビティーをバックグラウンドで実 行します（チェックサムの計算など）。 > A2L ファイル内のアドレスは常に 40 ビット値 (32 ビットアドレス、8 ビットアドレス拡張 ) として定義される ため 、XCPドライバーは関数 ApplXcpGetPointer（ ）を使用して 、A2L 対応アドレスからポインターを取 得します。 これらのインターフェイスで充分に測定／キャリブレーションの基本機能を統合することができます。ページ スワッピング、識別 、シード & キーなどの拡張機能には、その他のインターフェイスが必要です。これに関し ては、ドライバーのマニュアルに詳細が記載されています。 5 XCPの実装例 92 5.1 関数の説明 void XcpInit (void) タスク： XCPドライバーの初期化 説明： XcpInit() を使用して 、アプリケーションが XCPドライバーを有効にします。このコマンドは、XCPドライバー 関数を呼び出す前に 1 回だけ実行しなければなりません。 void XcpEvent (BYTE イベント ) タスク： アプリケーションは 、どのイベントが発生したかを XCPドライバーに通知します。ここでの各イベントには 一意のイベント番号が割り当てられます。 説明： 測定／キャリブレーションツールの測定コンフィギュレーションのセットアップにおいて 、ユーザーがどの測定 値をどのイベントと同時に取得すべきか選択します。測定値とイベントについての情報は A2L からのもので す。必要な測定コンフィギュレーションは、DAQ リストの形で XCPドライバーに送信されます。 エンジンコントローラーのイベント定義の例： XcpEvent (1); // Event 1 は 10ms のタスクを表す XcpEvent (2); // Event 2 は 100ms のタスクを表す XcpEvent (5); // Event 5 は 1ms のタスクを表す XcpEvent (8); // Event 8 はイグニション角同期測定に使用される BYTE XcpBackground (void) タスク： XCPドライバーのバックグラウンドアクティビティーを実行します。 説明： この関数は、バックグラウンドまたはアイドルタスクで定期的に呼び出す必要があります。たとえば 、チェッ クサムの計算などで XCPドライバーがこれを使用します。XcpCommand（ ）において長いチェックサムの計 算があると、許容範囲外の長い時間がかかることがあるためです。XcpBackground（ ）が呼び出されるた びに、256 バイトの部分的なチェックサムが計算されます。したがって 、チェックサム計算の時間の長さは XcpBackground（ ）の呼び出し頻度に応じて変わります。呼び出し頻度または間隔についてのその他の要件 はありません。戻り値 1 はチェックサム計算が現在実行中であることを示します。 5.1 関数の説明 void XcpCommand (DWORD* pCommand) タスク： XCP コマンドを解釈します。 説明： この関数はトランスポートレイヤーが XCP フレームを受信するごとに毎回呼び出さなければなりません。この パラメーターはフレームへのポインターです。 void ApplXcpSend (BYTE len, BYTE *msg) タスク： トランスポートレイヤーに送信すべきフレームを転送します。 説明： この呼び出しを使用して 、プロトコルレイヤーはトランスポートレイヤーにマスターへの送信のためのメッ セージを送信します。呼び出し XcpSendCallBack により、プロトコルとトランスポートレイヤー間のハンド シェイク動作が実行されます。 BYTE XcpSendCallBack (void) タスク： プロトコルレイヤーはこの呼び出しを使用して 、ApplXcpSend() に転送された最後のメッセージが正常に送 信されたことをトランスポートレイヤーに通知します。 説明： プロトコルレイヤーは、XcpSendCallBack() がそれ以前のメッセージが正常に送信されたことを示すま では ApplXcpSend() コマンドを呼び出しません。XcpSendCallBack() は、XCPドライバーがアイドル状 態にある場合に値 0 (FALSE) を返します。 送信対象のフレームがまだある場合は、ApplXcpSend() が XcpSendCallBack() から直接呼び出されます。 BYTE *ApplXcpGetPointer (BYTE addr_ext, DWORD addr) タスク： A2L 対応アドレスをポインターに変換します。 説明： この関数は、XCP マスターによって有効なポインターに送信された 40 ビット A2L 対応アドレス (32 ビットアド レス 、8 ビットアドレス拡張 ) をマッピングします。異なるアドレス領域またはメモリータイプを見分けるなど のために、アドレス拡張を使用することができます。 93 5 XCPの実装例 94 5.2 ドライバーのパラメーター化 多くの点で 、XCPドライバーはスケーラブルかつパラメーター化が可能で 、さまざまな種類の関数コンテン ツ、トランスポートプロトコル、ターゲットプラットフォームを正しく取り扱うことができます。すべての設定は パラメーターファイル xcp_cfg.h で行われます。もっともシンプルなケースでは、以下のように表現されます。 /* Define protocol parameters */ #define kXcpMaxCTO 8 /* Maximum CTO Message Length */ #define kXcpMaxDTO 8 /* Maximum DTO Message Length */ #define C_CPUTYPE_BIGENDIAN /* byte order Motorola */ /* Enable memory checksum */ #define XCP_ENABLE_CHECKSUM #define kXcpChecksumMethod XCP_CHECKSUM_TYPE_ADD14 /* Enable calibration */ #define XCP_ENABLE_CALIBRATION #define XCP_ENABLE_SHORT_UPLOAD /* Enable data acquisition */ #define XCP_ENABLE_DAQ #define kXcpDaqMemSize (512) /* Memory space reserved for DAQ */ #define XCP_ENABLE_SEND_QUEUE CANトランスポートレイヤーの場合 、8 バイトの適切な CTO および DTO パラメーターが設定されます。 Motorola-CPU (Big Endian) の場合 、ドライバーはこれがモトローラとインテルのどちらのバイトオーダー で 、プラットフォーム上で実行中であるかを知る必要があります。残りのパラメーターは、測定 、キャリブレー ション、チェックサム計算の各機能を有効にします。チェックサム計算のためのアルゴリズムが構成され ( こ の場合 、すべてのバイトの合計を DWORD に格納 ) 、利用可能なメモリーのパラメーターが測定のために示 されます ( この場合 、512 バイト ) 。メモリーは、主に DAQ リストを保存し、測定中のデータをバッファーする ために必要です。したがって 、パラメーターは測定シグナルの最大可能数を判断します。ドライバーのマニュ アルには、必要なパラメーターの設定についての詳しい情報が記載されています。 5.2 ドライバーのパラメーター化 95 執筆者 96 執筆者 Andreas Patzer ドイツの Technical University of Karlsruhe にて電気工学を専攻し、測定 、制御工学のほか 、情報 や産業工学を中心に研究。 2003 年 、シュツットガルトの Vector Informatik GmbH に入社し、XCP が ASAM e.V. によって規格化された頃から XCP 関連プロジェクトに携わる。現在 、Vector Informatik にて測定およびキャリブレーションのプロダクトラインでカスタマーリレーションおよびサービスの チームリーダーを務める。 執筆者 Rainer Zaiser ドイツ の University of Stuttgart にて 電 気 工 学 を 専 攻し、1988 年 、卒 業して すぐに Vector Informatik GmbH に入社。それ以来 、DBC 、MDF 、CCP 、A2L 、そして XCP といった自動車業界で確 立された多くの規格作りに携わり、入社当初から現在に至るまで測定およびキャリブレーションやネッ トワークインターフェイスのプロダクトラインで率先的役割を果たしている。 97 略語と頭字語 98 略語と頭字語 A2L AML ASAM BYP CAL CAN CCP CMD CS CTO CTR DAQ DTO ECU ERR EV FIBEX LEN MCD MTA ODT PAG PGM PID RES SERV SPI STD STIM TCP/IP TS UDP/IP USB XCP Download Upload ASAM 2MC 言語ファイルのファイル拡張子 ASAM 2 Meta Language Association for Standardisation of Automation and Measuring Systems Bypassing Calibration Controller Area Network CAN Calibration Protocol Command Checksum Command Transfer Object Counter Data Acquisition, Data Acquisition Packet Data Transfer Object Electronic Control Unit Error Packet Event Packet Field Bus Exchange Format Length Measurement Calibration and Diagnostics Memory Transfer Address Object Descriptor Table Paging Programming Packet Identifier Command Response Packet Service Request Packet Serial Peripheral Interface Standard Data Stimulation Packet Transfer Control Protocol/Internet Protocol Time Stamp Unified Data Protocol/Internet Protocol Universal Serial Bus Universal Measurement and Calibration Protocol Sending of data from Master to Slave（ データのマスターからスレーブへの送信） Sending of data from Slave to Master（ データのスレーブからマスターへの送信） 参考文献、Webアドレス 参考文献 XCP は ASAM（自動化および測定システム標準化協議会）が規定する規格です。 プロトコルと ASAM についての詳細：www.asam.net（英語版サイト） Web アドレス 標準化委員会： > ASAM 、XCP プロトコル詳細文書 、A2L 仕様 www.asam.net（英語版サイト） 開発ソフトウェアのサプライヤー： > MathWorks 、MATLAB 、Simulink/Simulink Coder に関する情報 www.mathworks.co.jp > ベクター、CANape のデモバージョン、無償／オープンソースの XCPドライバー（基本バージョン ）、 ECU キャリブレーション、ECU テスト、シミュレーションに関する情報 www.vector-japan.co.jp 99 図の目次 100 図の目次 図 1: ランタイム環境での基本的な通信 図 2: ASAM のインターフェイスモデル 図 3: XCP マスターは複数のスレーブと同時通信が可能 図 4: XCP プロトコルのプロトコルレイヤーとトランスポートレイヤーへの細分化 図 5: XCP スレーブはさまざまなランタイム環境で使用可能 図 6: XCP パケット 図 7: XCP パケット識別子（ PID ）の概要 図 8: CTO/DTO を持つ XCP 通信モデル 図 9: メッセージ識別 図 10: タイムスタンプ 図 11: XCP パケット内のデータフィールド 図 12: XCP プロトコルのモードは、 「 標準」、 「 ブロック」、 「 インターリーブ 」の 3 つ 図 13: CTO パケット構造の概要 図 14: キャリブレーションプロセスからの追跡例 図 15: パラメーター設定ファイルを ECU の RAM への転送 図 16: 16 進 Window 図 17: A2L ファイルからのパラメーター「 Triangle 」のアドレス情報 図 18: CANapeトレース Window 内でのポーリング通信 図 19: ECU 内のイベント 図 20: A2L 内のイベント定義 図 21: A2L 内の可能性のあるイベントへの「 Triangle 」の割り当て 図 22: 各測定パラメーターに対するイベント（測定モード）の選択 図 23: DAQ 測定の CANapeトレース Window からの抜粋 図 24: ODT：DAQ DTO への RAM アドレスの割り当て 図 25: 3 つの ODT を持つ DAQ リスト 図 26: 静的 DAQ リスト 図 27: 動的 DAQ リスト 図 28: DAQ と STIM に対するイベント 図 29: DTO 送信に対する XCP パケットの構造 図 30: 絶対 ODT 番号を持つ識別フィールド 図 31: 相対 ODT 番号と絶対 DAQ 番号を持つ ID フィールド（1 バイト） 図 32: 相対 ODT 番号と絶対 DAQ 番号を持つ ID フィールド（2 バイト） 図 33: 相対 ODT 番号と絶対 DAQ 番号を持つ ID フィールドとフィルバイト（合計 4 バイト） 図 34: どのバスノードがどのメッセージを送信するかについての定義 図 35: CAN ネットーワークの図解 図 36: XCP-on-CAN 通信の例 図 37: XCP-on-CAN メッセージの図示 図 38: CAN FD のデータフレーム 図 39: ノード K と L が冗長的に相互接続された状態 8 9 10 12 13 17 17 18 19 19 20 22 23 28 29 30 31 31 33 33 34 34 35 36 37 37 38 39 40 41 41 41 42 43 44 45 45 46 48 図の目次 図 40: スロット定義による通信 図 41: FlexRay 通信マトリクスの図解 図 42: FlexRay LPDU の図解 図 43: XCP 通信の LPDU への割り当て 図 44: TCP/IP または UDP/IP による XCP パケット 図 45: XCP-on-SxI パケット 図 46: メモリーの図解 図 47: フラッシュエリアのドライバー設定の図解 図 48: ブロック転送モードの図解 図 49: キャリブレーション Window 内のパラメーター 図 50: 時間軸でみたシグナルレスポンス 図 51: RAM 内の初期パラメーター設定 図 52: 起動後の初期状況 図 53: ポインター変更と RAM へのコピー 図 54: 個別パラメーターのポインターテーブル 図 55: ダブルポインターコンセプト 図 56: 応用分野と応用ケース 図 57: プラントとコントローラー 図 58: Simulink 環境での MIL 図 59: Simulink モデルを持つ測定／キャリブレーションツールとしての CANape 図 60: Simulink 環境での SIL 図 61: SIL 開発プラットフォームとしての CANape 図 62: HIL ソリューション 図 63: 測定／キャリブレーションツールとしての CANape 付き HIL 図 64: HIL システムとしての CANoe 図 65: HIL システムとしての CANoe（ ECU への XCP アクセス付き） 図 66: HIL ソリューションとしての CANape 図 67: RCP ソリューション 図 68: バイパスの基本原理 図 69: バイパスフロー 図 70: リアルタイムバイパスハードウェアと高速 ECU アクセスによるバイパス 図 71: 仮想 ECU による短いキャリブレーションサイクル 図 72: 仮想 ECU によるプロセスフロー 図 73: XCP スレーブの ECU コード内への組込 101 48 49 50 51 52 53 54 56 59 62 62 70 74 75 75 77 78 78 79 79 80 80 81 81 82 82 83 83 84 85 86 87 88 91 付録 − ベクターのXCPソリューション 102 付録 − ベクターの XCP ソリューション ベクターは XCP 規格の実現に多くの努力を重ねてきました。ベクターは、豊富なノウハウと幅広い経験を基 に、総合的な XCP サポートをご提供しています。 ツール > CANape が主に使用される領域は 、ECU パラメーターの最適化（ キャリブレーション）の部分です。シス テムの実行中 、パラメーター値をキャリブレートし、同時に測定シグナルを取得します。CANape と ECU の物理的なインターフェイスは 、XCP（ すべての標準化されたトランスポートプロトコル用）または CCP 上 にあります。 > 必要な A2L 記述ファイルの生成と管理のための完全なツールチェーン（ ASAP2 Tool-Set およびスタンド アローンツールとしても利用可能な ASAP2 Editor 付き CANape ）。 > 内部 ECU 値にアクセスし、テスト／解析タスクを行うための CANoe.XCP を使用可能。 ECU インターフェイス ベクターの測定／キャリブレーションハードウェア「 VX1000 」は、XCP on Ethernet を使用して PC に接続 し、ECU とツール間のインターフェイスとなります。コントローラーに直接接続する際 、VX1000 は Plug on Device（ POD ）で ECU と接続できます（例：DAP, JTAG, Nexus 経由など）。POD はベースモジュールにデー タを送って XCP スレーブとしての役割を果たし、XCP on Ethernet 経由で PC 上の XCP マスターにデータを提 供します。 そのため 、ECU に XCP スレーブを備える必要はありません。 最大 30MB/s の高い測定データス ループットと最短 15μ s の短い測定間隔が可能です。 組込ソフトウェア CAN 、FlexRay 、Ethernet 用の独立したトランスポートレイヤーを持つ通信モジュール群： > XCP Basic – 基本的な XCP 機能のみを含みます。www.vector-japan.co.jp/xcp-driver より無償ダウン ロード可能です。XCP プロトコルのコンフィギュレーションとトランスポートレイヤーの修正はソースコー ド内で手動で実行します。ユーザーは自分のプロジェクトに XCP Basic を統合する必要があります。 > XCP Professional – ASAM 仕様の便利な拡張を含み 、ツールベースのコンフィギュレーションを可能に します。ベクターの CANbedded ソフトウェア用に利用可能。 > MICROSAR XCP – XCP Professional の関数機能を含み 、AUTOSAR 仕様をベースにしています。ベク ターの MICROSAR ソフトウェア用に利用可能。 サービス > プロジェクトにおける XCP 使用についてのコンサルティング > 自社 ECU に XCP を統合する際のサポート 付録 − ベクターのXCPソリューション CANape による XCP サポート CANape は XCP 1.0 仕様に対応する初めての MCD ツールでした。また 、初めて市販された XCP on FlexRay マスターでもありました。 XCP on FlexRay の技術的な特長は、動的な帯域幅の管理です。ここでは、CANape が FlexRay ClusterP 内 で XCP に提供される利用可能な帯域幅を識別し、この帯域幅を連続したアプリケーションデータトラフィック に動的かつ非常に効率的に割り当てます。こうして 、XCP 通信用に利用可能な帯域幅が最適に使用されます。 さらに、CANape には DLL インターフェイスがあります。CANape は、必要な ( ユーザー定義の ) 任意のトラ ンスポートレイヤー上で XCP のサポートを可能にします。これにより、CANape に必要なテスト装置または自 社プロトコルの統合が可能になります。ユーザーは、コード生成機能でそのようなドライバーの XCP 固有部 分の作成が可能です。 103 アルファベット順索引 104 アルファベット順索引 A D A2L 9, 10, 23, 33, 37, 38, 39, 42, 47, DAQ 18, 23, 30, 31, 32, 33, 34, 35, 50, 51, 55, 56, 61, 62, 63, 64, 65, 66, 67, 71, 37, 38, 39, 40, 41, 42, 44, 58, 60, 67, 85, 86, 72, 74, 79, 80, 91, 92, 93, 98, 99 90, 92, 94, 98 Adress extension（アドレス拡張） AML ASAM 27, 31, DBC 43, 44, 49 91, 93 DOWNLOAD 28, 29, 59 64, 98 DTO 18, 19, 20, 22, 30, 31, 32, 35, 39, 40, 50, 54, 58, 94, 98 7, 8, 9, 12, 53, 98 ASAP2 Tool-Set 66, 102 E B ECU 9, 64, 82, 84, 85, 98 Bandwidth optimization（帯域の最適化） 32 EEPROM Bus load（バスへの負荷） ERR 18, 26, 98 EV 18, 26, 98 Bypassing（バイパス） 32 42, 84, 85, 86, 98 Event（イベント） 13, 29, 60, 69 33, 37, 39, 58, 60, 64, C 91, 92 CAN 7, 8, 12, 22, 27, 31, 36, 43, 44, 45, 46, 47, 49, 66, 90, 94, 98 CAN FD 46, 47 CANape 10, 28, 30, 44, 45, 47, 51, 52, F FIBEX 49, 50, 51, 98 Flash memory（FLASH メモリー） 53, 65, 66, 67, 76, 77, 78, 80, 81, 83, 87, 89, 14, 15, 29, 54, 55, 56, 57, 58, 60, 68, 69, 70, 99, 102, 103 71, 73, 77 82 FLX_CHANNEL 50 102 FLX_LPDU_ID 50 CCP 7, 8, 9, 37, 43, 98, 102 FLX_SLOT_ID 50 CMD 18, 19, 20, 23, 50, 98 Fullpassing（フルパス） 84 CANoe CANoe.XCP Compiling（コンパイル） 7, 68, 70, 80 CTO 18, 19, 20, 31, 39, 40, 50, 54, 94, 98 CTR 52, 53, 98 CYCLE_REPETITION 50 G GET_CAL_PAGE GET_DAQ_PROCESSOR_INFO 24, 55 42, 58, 67 アルファベット順索引 105 H S HIL 13, 78, 81, 82 Segment（セグメント） SEGMENT_NUMBER L 55, 56 55 SERV 27, 98 24, 55 Linking（リンク） 68, 80 SET_CAL_PAGE LPDU 50, 51 SHORT_UPLOAD 28, 31, 59 SIL 13, 78, 80 M STIM MIL 79 MTA 28, 98 18, 20, 31, 39, 40, 42, 58, 67, 85, 86, 98 Stimulation（スティミュレーション） 27, 61, 87 O ODT 35, 36, 37, 38, 40, 41, 42, 58, 67, 98 OFFSET 50 T Task（タスク） TCP/IP P PAG 98 Page（ページ） U 23 UDP/IP PGM 98 USB PID 15, 31, 32, 34, 55, 67 R 14, 15, 16, 28, 29, 35, 36, 37, 56, 60, 68, 70, 73, 74, 76 Reboot（再起動） RES 51, 52, 98 51, 52, 98 53, 98 8, 17, 19, 23, 40, 62, 75, 98 Polling（ポーリング） RAM 92 30 19, 20, 26, 50, 98 V VN8900 85 VX 86 VX1000 9, 86, 102 V1.0/2014-09 www.vector-japan.co.jp
© Copyright 2024 ExpyDoc
