付与されるデータID

intdash Edge Agent 2がデバイスコネクターから受け取ったデータポイントには、intdashサーバーへ送信される際に、iSCP仕様に沿ったデータIDが付与されます。

データポイントへのID付与

注釈

ここでは、アップストリームの場合を例にして、FIFO用データフォーマット→iSCPの方向で説明しますが、ダウンストリームの場合も対応関係は同様です。

iSCPのデータIDは、データ型とデータ名称により構成されます。 デバイスコネクターからデータを取得すると以下のようにデータIDが付与されます(推奨されるiscp-v2-compat形式のFIFO用データフォーマットを使用する場合)。

  • iSCPのデータ型としては、FIFO用データフォーマット内のData Typeフィールドの値が使用されます。

  • iSCPのデータ名称としては、デバイスコネクターの設定に含まれる data_name_prefix と、FIFO用データフォーマットに含まれるData Nameを / で結合したものが使用されます。

例えば、デバイスコネクター設定の data_name_prefix として abc が設定され、FIFO用データフォーマット内のData Typeフィールドが string 、Data Nameが def だった場合、iSCPでのデータ型は string 、データ名称は abc/def となります。

注釈

FIFO用データフォーマットとしてlogger-msg形式(非推奨)を使用する場合、上記とは異なります。

  • データ型は、logger-msg形式のデータイプに一対一で対応する所定のiSCPのデータ型として扱われます。logger-msgのデータタイプとiSCPのデータ型の対応については以下の表を参照してください。

  • データ名称は、ストリーマーにて以下の対応表のように生成されます(logger-msgフォーマットにはData Nameフィールドがないため)。 NMEA、CAN/CAN-FD、String等ではペイロード内の情報を使ってデータ名称が生成されます。

logger-msgのデータタイプ

付与されるiSCPのデータID

データ型

データ名称

NMEA (0x10)

string/nmea

<data_name_prefix>/<トーカ>/<メッセージ>

ペイロード内のNMEAセンテンス(例:「$GNRMC,..」)から 、2~3文字目のトーカ(例:「GN」)と、4~6文字目のメ ッセージ(例:「RMC」)が抽出されます。

CAN/CAN-FD (0x11)

can_frame

<data_name_prefix>/<CAN ID>

ペイロード内のCANフレームからCAN IDが抽出されます。

JPEG (0x12)

jpeg

<data_name_prefix>

H264 (0x1C)

h264_annex_b

<data_name_prefix>

String (0x1D)

string

<data_name_prefix>/<logger-msgのIDフィールド>

Float (0x1E)

float64

<data_name_prefix>/<logger-msgのIDフィールド>

Int (0x1F)

int64

<data_name_prefix>/<logger-msgのIDフィールド>

Bytes (0x20)

bytes

<data_name_prefix>/<logger-msgのIDフィールド>

PCM (0x22)

pcm

<data_name_prefix>

iSCP v1互換のデータID

iSCP v2とiSCP v1とでは、データを特定する方法が異なります。 iSCP v1にはチャンネルがありますが、v2にはチャンネルがありません。 また、データIDの仕組みも異なります。

しかし、iSCP v2でアップストリームを行う際に以下のようなデータ名称を付与してサーバーに送信すると、サーバー側の仕組みにより、そのデータはiSCP v1でダウンストリームすることができます。

iSCP v2のデータ型

iSCP v1と互換性を持たせるためのデータ名称

データ名称例

string/nmea

v1/<チャンネル>/<トーカ><メッセージ>

v1/1/GPRMC

can_frame

v1/<チャンネル>/<CAN ID(最上位ビットはIDE)>

v1/1/80000001

jpeg

v1/<チャンネル>/jpeg

v1/1/jpeg

h264_annex_b

v1/<チャンネル>/<iSCP v1のH.264データのタイプ>

v1/1/01

string

v1/<チャンネル>/<iSCP v1のデータID>

v1/1/hello

float64

v1/<チャンネル>/<iSCP v1のデータID>

v1/1/hello

int64

v1/<チャンネル>/<iSCP v1のデータID>

v1/1/hello

bytes

v1/<チャンネル>/<iSCP v1のデータID>

v1/1/hello

pcm

v1/<チャンネル>/pcm

v1/1/pcm

<チャンネル> は、10進数0~255で指定してください。

注釈

intdashサーバーは、データ名称の最初が v1/<10進数0~255> になっている場合、10進数の部分をiSCP v1用のチャンネル番号として解釈します。また、 v1/<10進数0~255>/ の後の文字列を、データ型に応じて、トーカ、メッセージ、CAN ID、またはiSCP v1のデータIDとして解釈します。

iSCP v1互換のデータ名称

intdash Edge Agent 2において、上の表のようにiSCP v1と互換性を持たせるためのデータ名称を与えるためには、デバイスコネクターに関する設定で、 data_name_prefixv1/<チャンネル> としてください。 その後ろの部分については、以下のとおりです。

重要

ただし、iscp-v2-compat形式でh264_nal_unit型のデータを送信したい場合は、 data_name_prefix<チャンネル番号> とし( v1/ は不要)、iscp-v2-compatのData Nameフィールドを h264_nal_unit としてください。 h264_nal_unit型はiSCP v1に存在しないデータ型であるため、特別な指定方法となっています。

iscp-v2-compat使用時

string/nmea、can_frame、jpeg、h264_annex_b、pcm型の場合、 data_name_prefix と、 iscp-v2-compatフォーマットのData Nameフィールドを / (スラッシュ)で結合した文字列の先頭が v1/<チャンネル> であるとき 1 、ストリーマーにて以下のように特別な処理が行われます。

1

以下の場合はいずれも該当します。

  • data_name_prefixv1/1 で、iscp-v2-compatフォーマットのData Nameフィールドが abc である場合 → v1/1/abc

  • data_name_prefixv1 で、iscp-v2-compatフォーマットのData Nameフィールドが 1 である場合 → v1/1

  • data_name_prefixv1 で、iscp-v2-compatフォーマットのData Nameフィールドが 1/abc である場合 → v1/1/abc

string/nmea型

ペイロード内のNMEAセンテンス(例:「$GNRMC,..」)から2~3文字目のトーカ(例:「GN」)と、4~6文字目のメッセージ(例:「RMC」)が抽出され、データ名称 v1/<チャンネル>/<トーカ><メッセージ> が付与されます。

can_frame型

ペイロード内からCAN IDが抽出され、データ名称 v1/<チャンネル>/<CAN ID(最上位ビットはIDE)> が付与されます。

jpeg型

常にデータ名称 v1/<チャンネル>/jpeg が付与されます。

h264_annex_b型

ペイロード内からH.264データのタイプが抽出され、データ名称 v1/<チャンネル>/<iSCP v1のH.264データのタイプ> が付与されます。

pcm型

常にデータ名称 v1/<チャンネル>/pcm が付与されます。

string、float64、int64、bytes型の場合、ストリーマーでの特別な処理は行われません。 アップストリーム時のデータ名称は <data_name_prefix>/<iscp-v2-compatフォーマットのData Nameフィールド> のようになりますので、iscp-v2-compatフォーマットのData Nameフィールドに、iSCP v1のデータIDとして使用したい文字列を指定してください。

例えば、 data_name_prefixv1/1 とし、iscp-v2-compatフォーマットのData Nameを abc とすれば、 v1/1/abc としてアップストリームが行われ、これをiSCP v1でダウンストリームする場合は、チャンネル 1 、データID abc を指定すればよいことになります。

logger-msg(非推奨)使用時

string/nmea、can_frame、jpeg、h264_annex_b、pcm型の場合、 data_name_prefixv1/<チャンネル> になっていると、ストリーマーにて以下のように特別な処理が行われます。

string/nmea型

ペイロード内のNMEAセンテンス(例:「$GNRMC,..」)から2~3文字目のトーカ(例:「GN」)と、4~6文字目のメッセージ(例:「RMC」)が抽出され、データ名称 v1/<チャンネル>/<トーカ><メッセージ> が付与されます。

can_frame型

ペイロード内からCAN IDが抽出され、データ名称 v1/<チャンネル>/<CAN ID(最上位ビットはIDE)> が付与されます。

jpeg型

常にデータ名称 v1/<チャンネル>/jpeg が付与されます。

h264_annex_b型

ペイロード内からH.264データのタイプが抽出され、データ名称 v1/<チャンネル>/<iSCP v1のH.264データのタイプ> が付与されます。

pcm型

常にデータ名称 v1/<チャンネル>/pcm が付与されます。

string、float64、int64、bytes型の場合、ストリーマーでの特別な処理は行われません。 アップストリーム時のデータ名称は <data_name_prefix>/<logger-msgフォーマットのIDフィールド> のようになります。

例えば、 data_name_prefixv1/1 とし、logger-msgフォーマットのIDフィールドを abc とすれば、 v1/1/abc としてアップストリームが行われ、これをiSCP v1でダウンストリームする場合は、チャンネル 1 、データID abc を指定すればよいことになります。