データID
iSCPのデータIDは、データ型とデータ名称により構成されます。
intdashサーバーとintdash Edge Agent2の間ではiSCPに沿ったデータフォーマットが使用されますが(A)、デバイスコネクターとintdash Edge Agent 2の間ではそれとは異なるFIFO用データフォーマットが使用されています(B)。
図 24 異なるフォーマット
そのため、デバイスコネクター→エッジ→サーバーの方向にデータが流れる際も、逆方向に流れる際も、intdash Edge Agent 2においてデータフォーマットの変換が行われます。この変換の際には、データIDの変換も行われます。
ここでは、FIFO用データフォーマットのどの値がどのようにiSCPのデータIDに変換されるのか（およびその逆方向）について説明します。
アップストリーム方向の場合
intdash Edge Agent 2がデバイスコネクターからデータを受信すると、データ型とデータ名称が以下のように決定され、データはサーバーに送信されます（推奨されるiscp-v2-compat形式のFIFO用データフォーマットを使用する場合）。
- iSCPのデータ型
FIFO用データフォーマット 内のData Typeフィールドの値が使用されます。
- iSCPのデータ名称
デバイスコネクターIPC設定に含まれる
data_name_prefixと、FIFO用データフォーマットに含まれるData Nameフィールドの値を結合したものが使用されます。
例えば、FIFO用データフォーマット内のData Typeフィールドが string 、デバイスコネクターIPC設定の data_name_prefix が abc 、Data Nameが def だった場合、iSCPでのデータ型は string 、データ名称は abcdef となります。
図 25 アップストリーム方向の場合
重要
FIFO用フォーマットのData Nameは基本的に空文字以外を設定してください。
Data Nameを空文字として、data_name_prefixも空文字とした場合、iSCPでのデータ名称も空文字になり、不正なデータ名称になります。 不正なデータ名称を持つデータポイントは、intdashサーバーへの送信でエラーになります。
計測内にエラーとなったデータポイントが含まれる場合、intdash Edge Agent 2は計測データが壊れていると判断し、それ以後、その計測について未送信データの遅延アップロードを行いません。
なお、iSCPデータ名称が v1/<チャンネル>/ から始まる場合、iSCP v1互換のための特別な処理が行われます。詳細については、 iSCP v1互換のデータID を参照してください。
注釈
FIFO用データフォーマットとしてlogger-msg形式（非推奨）を使用する場合は、上記とは異なります。
iSCPのデータ型は、logger-msg形式のデータが持つデータタイプによって一対一で決定されます。対応については以下の表を参照してください。
iSCPのデータ名称は、ストリーマーにて以下の表のように生成されます（logger-msgフォーマットにはData Nameフィールドがないため）。 NMEA、CAN/CAN-FD、String等ではペイロード内の情報を使ってデータ名称が生成されます。
logger-msgのデータタイプ |
変換後 |
|
|---|---|---|
iSCPのデータ型 |
iSCPのデータ名称 |
|
NMEA (0x10) |
string/nmea |
ペイロード内のNMEAセンテンス（例:「$GNRMC,..」）から 、2～3文字目のトーカ（例：「GN」）と、4～6文字目のメ ッセージ（例：「RMC」）が抽出されます。 |
CAN/CAN-FD (0x11) |
can_frame |
ペイロード内のCANフレームからCAN IDが抽出されます。 |
JPEG (0x12) |
jpeg |
|
H264 (0x1C) |
h264_annex_b |
|
String (0x1D) |
string |
|
Float (0x1E) |
float64 |
|
Int (0x1F) |
int64 |
|
Bytes (0x20) |
bytes |
|
PCM (0x22) |
pcm |
|
ダウンストリーム方向の場合
intdash Edge Agent 2がサーバーからデータを受信すると、データは以下のようにFIFO用データフォーマットに変換され、デバイスコネクターに送信されます（推奨されるiscp-v2-compat形式のFIFO用データフォーマットを使用する場合）。
- FIFO用データフォーマット内のData Type
iSCPのデータ型の値が使用されます。
- FIFO用データフォーマット内のData Name
デバイスコネクターIPC設定に含まれる
data_name_prefixの値によって以下のように決まります。data_name_prefixに空文字以外が設定されている場合は、データポイントに付与されているデータ名称から、data_name_prefixが除去されます。除去処理が行われたデータポイントのみがデバイスコネクターに送信されます。data_name_prefixが空文字の場合は、データポイントに付与されているデータ名称がそのまま使用されます。
例えば、デバイスコネクターIPC設定の data_name_prefix として abc が設定され、データポイントに付与されているデータ名称が abcdef だった場合、このデータポイントは abc に一致しますので、デバイスコネクターに送信されます。また、その際デバイスコネクターが受け取るデータポイントのData Nameフィールドは def となります。
図 26 ダウンストリームの場合のデータ名称（data_name_prefixに一致した場合）
図 27 ダウンストリームの場合のデータ名称（data_name_prefixが空文字の場合）
なお、iSCPデータ名称が v1/<チャンネル>/ から始まる場合、iSCP v1互換のための特別な処理が行われます。詳細については、 iSCP v1互換のデータID を参照してください。
注釈
FIFO用データフォーマットとしてlogger-msg形式（非推奨）を使用する場合は、上記とは異なります。iSCPのデータIDは以下のようにlogger-msgフォーマットに変換されます。
iSCPのデータ型 |
変換後 |
|
|---|---|---|
logger-msgのデータタイプ |
logger-msgのIDフィールド |
|
string/nmea |
NMEA (0x10) |
（IDフィールドなし） |
can_frame |
CAN/CAN-FD (0x11) |
iSCPのデータ名称から先頭の
|
jpeg |
JPEG (0x12) |
（IDフィールドなし） |
h264_annex_b |
H264 (0x1C) |
（IDフィールドなし） |
string |
String (0x1D) |
iSCPのデータ名称から先頭の
|
float64 |
Float (0x1E) |
iSCPのデータ名称から先頭の
|
int64 |
Int (0x1F) |
iSCPのデータ名称から先頭の
|
bytes |
Bytes (0x20) |
iSCPのデータ名称から先頭の
|
pcm |
PCM (0x22) |
（IDフィールドなし） |
iSCP v1互換のデータID
iSCP v2とiSCP v1とでは、データを特定する方法が異なります。 iSCP v1にはチャンネルがありますが、v2にはチャンネルがありません。 また、データIDの仕組みも異なります。
しかし、iSCP v2でアップストリームを行う際に以下のようなデータ名称を付与してサーバーに送信すると、サーバー側の仕組みにより、そのデータはiSCP v1でダウンストリームすることができます。
iSCP v2のデータ型 |
iSCP v1と互換性を持たせるためのデータ名称 |
データ名称例 |
|---|---|---|
string/nmea |
|
v1/1/GPRMC |
can_frame |
|
v1/1/80000001 |
jpeg |
|
v1/1/jpeg |
h264_annex_b |
|
v1/1/01 |
string |
|
v1/1/hello |
float64 |
|
v1/1/hello |
int64 |
|
v1/1/hello |
bytes |
|
v1/1/hello |
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互換のデータ名称
注釈
ここでは、アップストリームの場合を例にして、FIFO用データフォーマット→iSCPの方向で説明しますが、ダウンストリームの場合も対応関係は同様です。
intdash Edge Agent 2において、上の表のようにiSCP v1と互換性を持たせるためのデータ名称を与えるためには、デバイスコネクターIPC設定で、 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] 、ストリーマーにて以下のように特別な処理が行われます。
- 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 を指定すればよいことになります。