データポイントとそのメタ情報

iSCPバージョンによるメタ情報の違い

iSCPには、時系列データを表すデータポイントという単位があります。 データポイントは、データ本体を格納するペイロードと時刻（基準時刻からの経過時間で表現される）により構成されます。

iSCP 1.0

iSCP 1.0では、1つ1つのデータポイントがユニットという構造に格納されます。 ユニットは、データポイントに加えて以下のメタ情報を持ちます。

  • チャンネル番号

  • データID

  • データタイプ

../_images/iscp-1-unit.ja.png

図 4 iSCP 1.0のデータポイントが持つメタ情報

iSCP 2.0

iSCP 2.0では、同じメタ情報を持つ複数のデータポイントがデータポイントグループという構造に格納されます。 データポイントグループは、格納されたデータポイントのメタ情報を代表して持ちます。 iSCP 2.0のデータポイントグループが持つデータポイントのメタ情報は、 iSCP 1.0のユニットが持っていたメタ情報に相当する情報です。 iSCP 2.0のデータポイントグループは以下のメタ情報を持ちます。

  • データ名称

  • データ型

../_images/iscp-2-data-point-group.ja.png

図 5 iSCP 2.0のデータポイントグループが持つメタ情報

サーバーで永続化されたデータ

iSCP 2.0対応のintdashサーバーでデータポイントが永続化されると、永続化された各データポイントは、iSCP 2.0のデータポイントグループが持つメタ情報と同等のメタ情報を持ちます。

  • データ名称

  • データ型

../_images/iscp-2-persistent-data-point.ja.png

図 6 永続化されたデータポイントが持つメタ情報

データポイントのメタ情報に関する互換仕様

iSCP 1.0-iSCP2.0間の互換仕様では、iSCP 1.0におけるメタ情報（チャンネル番号、データID、データ型）と、iSCP 2.0におけるメタ情報（データ名称、データ型）とを以下のように対応付けます。

iSCP 1.0における「チャンネル番号」、「データID」

iSCP 1.0における「チャンネル番号」と「データID」を統合した概念として、iSCP 2.0では「データ名称」が使用されます。

iSCP 1.0では、データを特定するための識別子としてチャンネル番号とデータIDがありましたが、チャンネル番号は整数値で表現力に乏しく、データIDはデータタイプごとに型が異なり統一的に扱うことが難しい仕様でした。

iSCP 2.0では、どのデータ型であってもデータ名称は文字列で表現されるので、統一的な取り扱いが可能です。

iSCP 1.0における「データタイプ」

iSCP 1.0における「データタイプ」は、iSCP 2.0では「データ型」に相当します。

iSCP 1.0ではデータタイプは数値で表現されており、 どの数値がどのデータタイプに対応するか分かりにくい仕様でしたが、iSCP 2.0では、データ型は任意の文字列で表現されるようになりました。

iSCP 1.0アップストリーム → iSCP 2.0ダウンストリームの変換

iSCP 1.0でアップストリームされているデータを、iSCP 2.0でリアルタイムにダウンストリームする場合、データポイントは以下のルールでiSCP 2.0の形式に変換されます。

iSCP 2.0のデータ型への変換

iSCP 1.0のデータタイプが、iSCP 2.0のデータ型に一対一で対応します。 対応付けについては、 iSCP 1.0からiSCP 2.0への変換ルール を参照してください。

iSCP 2.0のデータ名称への変換

iSCP 1.0のデータポイントのチャンネル番号とデータIDは、以下のフォーマットでiSCP 2.0のデータ名称に変換されます。

  • v1/<10進数表記のチャンネル番号>/<データIDの文字列表現>

iSCP 1.0のデータIDの文字列表現は、データタイプにより異なります。 どのように文字列として表現され、iSCP 2.0のデータ名称に変換されるかについては、 iSCP 1.0からiSCP 2.0への変換ルール を参照してください。

iSCP 2.0では、データ名称に、ワイルドカード文字（#、+）を使用することができません。また、セパレータ文字（/）は特別な意味を持ちます。 これらの文字の混入を避けるために、iSCP 1.0のデータIDの文字列表現部分は、変換時にパーセントエンコーディングによるエスケープ処理が行われます（パーセントエンコーディングの対象となる文字は # / + : % です）。

iSCP 2.0のペイロードへの変換

iSCP 1.0のデータタイプにより、変換後のiSCP 2.0のペイロードに格納される情報が異なります。 どのように変換されるかは、 iSCP 1.0からiSCP 2.0への変換ルール を参照してください。

iSCP 2.0のチャンクへの変換

iSCP 1.0のユニットに格納されたデータポイントは、iSCP 2.0に変換される際に、チャンク内のデータポイントグループに格納されます。 データポイントがデータポイントグループに格納される際には、元のユニットに格納されたデータポイントを1つだけ含むチャンクが生成されます。

../_images/conversion-to-chunk.ja.png

図 7 iSCP 2.0のチャンクへの変換

この変換の際、生成されたチャンクのシーケンス番号は必ず0になります。 また、そのチャンクが持つアップストリーム情報のストリームIDはゼロ値（ 00000000-0000-0000-0000-000000000000 ）が設定されます。

注釈

iSCP 1.0でアップストリームされたデータがサーバーでの永続化されるときの処理については iSCP 1.0でアップストリームされたデータの永続化 を参照してください。

表 1 iSCP 1.0からiSCP 2.0への変換ルール
変換前 iSCP 1.0アップストリームでのデータ型
変換後 iSCP 2.0ダウンストリームでのデータ型
iSCP 1.0のデータIDの
文字列表現のフォーマット
データ名称への変換例 [1]
iSCP 2.0でのペイロードの内容 [2]

1 （CAN）

can_frame

%08x

00000001 → v1/1/00000001

(A)

2 （NMEA）

string/nmea

%s

GPRMC → v1/1/GPRMC

(B)

3 （General Senser）

general_sensor

%04x

0001 → v1/1/0001

(C)

4 （Control Pad）

controlpad

%02x

01 → v1/1/01

(C)

5 （MAVLink1 Packet）

mavlink1_packet

%02x-%02x-%02x-%02x

fe-01-01-1d → v1/1/fe-01-01-1d

(B)

9 （JPEG）

jpeg

jpeg （固定）

jpeg → v1/1/jpeg

(B)

10 （String）

string

%s

hello → v1/1/hello

(C)

11 （Float64）

float64

%s

hello-float64 → v1/1/hello-float64

(C) ただし、バイトオーダーがBig Endianに変換されます。

12 （Int64）

int64

%s

hello-int → v1/1/hello-int

(C) ただし、バイトオーダーがBig Endianに変換されます。

13 （H.264）

h264_annex_b

%02x

01 → v1/1/01

(C)

14 （Bytes）

bytes

%s

hello-bytes → v1/1/hello-bytes

(C)

15 （PCM）

pcm

pcm （固定）

pcm → v1/1/pcm

(B)

16 （AAC）

aac

aac （固定）

aac → v1/1/aac

(B)

17 （H.265）

h265_annex_b

%02x

01 → v1/1/01

(C)

18 （IVF）

ivf

%02x

01 → v1/1/01

(C)

127 （Generic）

generic

%08x

00000001 → v1/1/00000001

(C)

変換の例：

  • iSCP 1.0のデータタイプ 1 (CAN)の場合、データIDの文字列表現フォーマットは %08x （IDを8桁の16進文字列として表記したもの）です。

    そのため、iSCP 1.0のデータタイプ 1 (CAN)、チャンネル番号が 1 、データIDが 15 （数値、10進表記）のデータポイントは、変換後のiSCP 2.0では、 v1/1/0000000F （ v1/<10進数表記のチャンネル番号>/<データIDの文字列表現> ）というデータ名称を持つことになります。

  • iSCP 1.0のデータタイプ 12 (Int64)、チャンネル番号が 1 、データIDが abc/def のデータポイントは、変換後のiSCP 2.0では v1/1/abc%2Fdef というデータ名称を持つことになります。

iSCP 1.0でのペイロードのフォーマットについては、 詳説 iSCP 1.0 を参照してください。

iSCP 2.0アップストリーム → iSCP 1.0ダウンストリームの変換

iSCP 2.0でアップストリームされたデータポイントのデータ名称が v1/<10進数表記のチャンネル番号>/<データIDの文字列表現> というフォーマットに一致している場合にのみ、データポイントは以下のルールでiSCP 1.0の形式に変換されます。これによりiSCP 1.0でダウンストリームを行うことができるようになります。

iSCP 1.0のチャンネル番号への変換

<10進数表記のチャンネル番号> の部分は、iSCP 1.0のチャンネル番号として使用されます。

iSCP 1.0のデータIDへの変換

<データIDの文字列表現> の部分は、パーセントエンコーディングのデコードが行われたうえで、iSCP 1.0のデータIDとして使用されます。

データIDの文字列表現部分をどのように解釈するかは、iSCP 1.0のデータ型により異なります。 データIDの文字列表現部分の解釈方法は、 iSCP 2.0からiSCP 1.0への変換ルール を参照してください。

iSCP 1.0のデータタイプへの変換

iSCP 2.0のデータ型が、iSCP 1.0のデータタイプに一対一で対応します。 対応付けについては、 iSCP 2.0からiSCP 1.0への変換ルール を参照してください。

iSCP 1.0のペイロードへの変換

iSCP 2.0のデータタイプにより、変換後のiSCP 1.0のペイロードに格納される情報が異なります。 どのように変換されるかは、 iSCP 2.0からiSCP 1.0への変換ルール を参照してください。

一部のデータ型では、ペイロードの解釈結果と、解釈されたデータIDを組み合わせることで、iSCP 1.0のペイロードが構成されます。

iSCP 1.0のユニットへの変換

iSCP 2.0でチャンクに格納された複数のデータポイントは、iSCP 1.0に変換される際に、分解されて一つ一つのユニットに格納されます。

../_images/conversion-to-unit.ja.png

図 8 iSCP 1.0のユニットへの変換

表 2 iSCP 2.0からiSCP 1.0への変換ルール
変換前 iSCP 2.0アップストリームでのデータ型
変換後 iSCP 1.0ダウンストリームでのデータ型
データIDへの変換例 [3]
文字列表現をiSCP 1.0のデータIDとして解釈する際のフォーマット
iSCP 1.0でのペイロードの内容 [4]

can_frame

1 （CAN）

v1/1/00000001 → 00000001

%08x

(A)

string/nmea

2 （NMEA）

v1/1/GPRMC → GPRMC

%s

(B)

general_sensor

3 （General Senser）

v1/1/0001 → 0001

%04x

(C)

controlpad

4 （Control Pad）

v1/1/01 → 01

%02x

(C)

mavlink1_packet

5 （MAVLink1 Packet）

v1/1/fe-01-01-1d → fe-01-01-1d

%02x-%02x-%02x-%02x

(B)

jpeg

9 （JPEG）

v1/1/jpeg → jpeg

jpeg （固定）

(B)

string

10 （String）

v1/1/hello → hello

%s

(C)

float64

11 （Float64）

v1/1/hello-float64 → hello-float64

%s

(C) ただし、バイトオーダーがLittle Endianに変換されます。

int64

12 （Int64）

v1/1/hello-int → hello-int

%s

(C) ただし、バイトオーダーがLittle Endianに変換されます。

h264_annex_b

13 （H.264）

v1/1/01 → 01

%02x

(C)

bytes

14 （Bytes）

v1/1/hello-bytes → hello-bytes

%s

(C)

pcm

15 （PCM）

v1/1/pcm → pcm

pcm （固定）

(B)

aac

16 （AAC）

v1/1/aac → aac

aac （固定）

(B)

h265_annex_b

17 （H.265）

v1/1/01 → 01

%02x

(C)

ivf

18 （IVF）

v1/1/01 → 01

%02x

(C)

generic

127 （Generic）

v1/1/00000001 → 00000001

%08x

(C)

変換の例:

  • iSCP 2.0のデータ型 int64 、データ名称 v1/1/abc%2Fdef のデータポイントは、iSCP 1.0ではデータタイプ 12 (Int64)、チャンネル番号 1 データID abc/def （文字列）となります。

iSCP 1.0でアップストリームされたデータの永続化

iSCP 1.0でアップストリームされたデータポイントは、以下のルールで永続化されます。

永続化形式のデータ型への変換

iSCP 1.0のデータ型の数値が10進数表記の文字列として永続化されます。

永続化形式のデータ名称への変換

iSCP 1.0のデータポイントのチャンネル番号とデータIDは、以下のフォーマットでデータ名称として永続化されます。

  • <10進数表記のチャンネル番号>/<データIDの文字列表現>

iSCP 1.0では、データIDの文字列表現はデータ型により異なります。 データ型ごとにどのように変換されるかは、 iSCP 1.0永続化ルール を参照してください。

ペイロードの変換

ペイロードの変換は行われません。iSCP 1.0のペイロードはそのまま永続化されます。

表 3 iSCP 1.0永続化ルール
iSCP 1.0アップストリームでのデータ型
iSCP 1.0のデータIDの
文字列表現のフォーマット
データIDへの変換例 [5]

1 （CAN）

%08x

00000001 → 1/00000001

2 （NMEA）

%s

GPRMC → 1/GPRMC

3 （General Senser）

%04x

0001 → 1/0001

4 （Control Pad）

%02x

01 → 1/01

5 （MAVLink1 Packet）

%02x-%02x-%02x-%02x

fe-01-01-1d → 1/fe-01-01-1d

9 （JPEG）

jpeg （固定）

jpeg → 1/jpeg

10 （String）

%s

hello → 1/hello

11 （Float64）

%s

hello-float64 → 1/hello-float64

12 （Int64）

%s

hello-int → 1/hello-int

13 （H.264）

%02x

01 → 1/01

14 （Bytes）

%s

hello-bytes → 1/hello-bytes

15 （PCM）

pcm （固定）

pcm → 1/pcm

16 （AAC）

aac （固定）

aac → 1/aac

17 （H.265）

%02x

01 → 1/01

18 （IVF）

%02x

01 → 1/01

127 （Generic）

%08x

00000001 → 1/00000001

変換の例：

  • iSCP 1.0のデータタイプ 1 (CAN)の場合、データIDの文字列表現フォーマットは %08x （IDを8桁の16進文字列として表記したもの）です。

    そのため、iSCP 1.0のデータタイプ 1 (CAN)、チャンネル番号が 1 、データIDが 15 （数値、10進表記）のデータポイントは、永続化の際には、 1/0000000F というデータ名称を持つことになります。

iSCP 2.0でアップストリームされたiSCP 1.0互換データの永続化

iSCP 2.0でアップストリームされたデータポイントのデータ名称が v1/<10進数表記のチャンネル番号>/<データIDの文字列表現> というフォーマットに一致している場合（つまり、iSCP 1.0互換形式である場合）には、データはiSCP 1.0のデータポイントとして永続化されます。

この場合の変換は、iSCP 2.0でアップストリームされたデータポイントをiSCP 1.0でダウンストリームする場合に行われる変換と同様です。 iSCP 2.0アップストリーム → iSCP 1.0ダウンストリームの変換 を参照してください。

この方法で永続化されたデータポイントは、iSCP 1.0でアップストリームされたデータと同じ形式になるるため、あとで利用する際には、iSCP 1.0でアップストリームされたデータと同じように使用することができます。