付与されるデータ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_prefix を v1/<チャンネル> としてください。 その後ろの部分については、以下のとおりです。

重要

ただし、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_prefix が v1/1 で、iscp-v2-compatフォーマットのData Nameフィールドが abc である場合 → v1/1/abc

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

• data_name_prefix が v1 で、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_prefix を v1/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_prefix が v1/<チャンネル> になっていると、ストリーマーにて以下のように特別な処理が行われます。

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