5. アプリケーションプロトコルの概要

それぞれのアプリケーションプロトコルは他と区別できるようにユニークなプロトコル ID を持っています。 将来のデバイスは新しいデータ型を転送するための追加のプロトコルを導入したり、既存プロトコルの 改訂版を提供するかもしれません (例えばプロトコル A101 はプロトコル A100 の改訂版として導入される かもしれません)。 新しいプロトコルが導入される時は必ずホストソフトウェアが新しいプロトコルに対応するためにアップデート されなければならないと予想されます。 しかし、新しいデバイスは以前のプロトコルのいくつかをサポートし続けるかもしれないので、以前の ソフトウェアでも完全または部分的に通信可能かもしれません。 この能力をよりうまくサポートするために、新しいデバイスはそれらがサポートしているプロトコルを ホストに報告する事が出来ます (6.2章参照)。 さもなくば、ホストはデバイス型に対してどのプロトコルが使用されているかを決定するための 検索テーブルを含まなければいけません (8.2章参照)。

5.1 ドキュメントされていないアプリケーションパケット

デバイスはこの仕様で文書化されていないパケット ID を含んだアプリケーションパケットを送る可能性が あります。 これらのパケットは内部テストの目的で Garmin の技術者によって使用されます。 これらの内容はいつでも変更の可能性があるため、いかなる目的でもサードパーティアプリケーションで 使用すべきではありません。 それらはこの仕様で記述される物理プロトコルでハンドルされ、破棄されなければいけません。

5.2 パケット順序

それぞれのアプリケーションプロトコルはパケット順序に基づいて定義されています。 それらは二つのデバイス間で交換されるパケットのパケットの方向、パケット ID、パケットデータ型を含む 順序と型を定義しています。 パケット順序の例を以下に示します:

Table 7 – Example Packet Sequence
N方向パケット IDパケットデータ型
0Device1 to Device2Pid_FirstFirst_Data_Type
1Device1 to Device2Pid_Secondignored
2Device1 to Device2Pid_Third<D0>
3Device2 to Device1Pid_Fourth<D1>
4Device2 to Device1Pid_Fifth<D2>

この例では交換される 5 つのパケットが存在し、3 つは Device1 から Device2 へ、2 つは反対の方向です。 これら 5 つのパケットは応答 (acknowledge) されなければいけませんが、明快さのため応答パケットは テーブルから省略されます。 大部分のプロトコルは対称型です。 ある方向へ転送するためのプロトコル (例えばホストからデバイスへ) は他方へ転送するためのプロトコル (例えばデバイスからホスト) と同じ意味を持ちます。 対称型のプロトコルに対して、デバイスまたはホストは Device1 または Device2 の役割を担います。 非対称型のプロトコルに対して、順序テーブルでは Device1, Device2 を示す代わりにデバイスとホストの 役割を明確に示しています。

テーブルの最初の列はパケット番号を表しています (参照のために使用されるだけでこの番号はパケット には埋め込まれません)。 2 列目はそれぞれのパケットの移動方向を示します。 3 列目はパケット ID 列挙名を示します (パケット ID の実際の値を知るには 3.2.3章を参照してください)。 最後の列はパケットデータ型を示します。

5.3 パケットデータ型

パケットデータ型はいくつかの方法で表記されています。 第一に、明確な名前を付けられたデータ型 (例えば "First_Data_Type") として指定されます。 明確な名前を付けられたデータ型は全てこの文書で定義されています。 第二に、パケットデータが使用されていない事を示します (例えば "ignored")。 この場合、パケットデータは 0 バイトのサイズとなります。 最後に、パケットに対するデータ型に角括弧表記 (例えば <D0>) を使用した指定です。 この表記方法はデータ型がデバイス固有であることを示します 上記の例ではデバイス固有のデータ型が 3 つ (<D0>, <D1>, <D2>) 存在しています。

これらのデバイス固有のデータ型は、現在接続されているデバイスのタイプに依存するホストによって動的に 決定されます。 古いデバイスに対してのこの決定はホストに検索テーブルを持たせる事によってなされます (8.2章参照) が、 新しいデバイスは動的のそれらのプロトコルとデータ型を報告する事が出来ます (6.2章参照)。

5.4 パケットの標準的な開始と終了

多くのアプリケーションプロトコルはそれぞれ Pid_Records, Pid_Xfer_Cmplt と呼ばれる以下の表に示すような標準的な開始と終了のパケットを使用します:

Table 8 – Standard Beginning and Ending Packets
N方向パケット IDパケットデータ型
0Device1 to Device2Pid_RecordsRecords_Type
n-1Device1 to Device2Pid_Xfer_CmpltCommand_Id_Type

最初のパケット (パケット 0) は続くデータパケットの数から Pid_Xfer_Cmplt を除外した 数を Device2 に示します (パケット 1 から n-2)。 これにより Device2 は転送の進捗状況を監視できるようになります。 最後のパケット (パケット n-1) は転送が完了したことを示します。 この最後のパケットも転送のどれが完了したかを示すためのデータを Pid_Xfer_Cmplt に含んで います (6.3章参照)。

転送のそれぞれに対する Command_Id_Type 値は転送それぞれを開始するために使用した コマンド ID と一致します (6.3章参照)。 結果的に、実際の Command_Id_Type 値はデバイスがどのデバイスコマンドプロトコルを実装 しているかに依存します。 この依存性のため、この文書では Command_Id_Type に対する (値ではなく) 列挙名を用いて 後述のアプリケーションプロトコルそれぞれで説明しています。

5.4.1 Records_Type

Records_Type は続くデータパケットの数から Pid_Xfer_Cmplt を除いた数を 示す 16 ビット整数です。この Records_Type に対する型定義は以下のように表されます:

typedef uint16 Records_Type;

5.5 名前で識別されるデータのデバイス側での上書き

ホストからデータを受け取る時、いくつかのデバイスは名前で識別されるデータを消去し、ホストから受信 した新しいデータをそこへ配置するでしょう。 例えばホストが XYZ と名付けられたウェイポイントを送信すると、デバイスはデバイスの メモリに保存されている XYZ と名付けられていた以前のウェイポイントを上書きします。 名前で識別されるデータを上書きする前にデバイスから警告は送信されません。

そのほかのデバイスは名前で識別されるウェイポイントに対して特別な扱いを行います。 例えば、これらのデバイスは到着したウェイポイントと既存のウェイポイントの位置を比較する事が出来ます (注意:比較に高度は考慮されません)。 位置が同じであればデバイスは同じ名前の既存のウェイポイントを消去しホストから受け取った新しい ウェイポイントと入れ替えます。 位置が異なるなら、デバイスは受け取ったウェイポイントに対して新しいユニークな名前を作成して 既存のウェイポイントをそのまま残すでしょう。 デバイスがウェイポイントを扱う方法 (上書き vs. ユニーク名) をホストから知る有効なメカニズムは ありません。