SOME/IPのプロトコルを理解しよう　～SOME/IP-TP編～

前回に引き続き今回はSOME/IP-TPの通信について勉強していきます。

SOME/IPの基本フォーマット等については事前に以下を確認してください。

SOME/IPのプロトコルを理解しよう　～SOME/IPプロトコル基本編～

今回は業務関連でSOME/IPのプロトコルについて理解を深めていきます。なお、正式なAUTOSARの規格は以 ...

https://telecom-engineer.blog/blog/2023/02/10/someip/

Contents

概要

SOME/IPは現在、UDPとTCPをサポートしています。

今回紹介するSOME/IP-TPはUDPでSOME/IP通信を行う際、ペイロードサイズが一つのパケットに収まりきらない時に使用します。

なぜUDPだけSOME/IP-TPが必要かを説明するにあたり、まずはTCPとUDPの通信に関して極力専門用語を使わずに整理します。

TCPにはコネクションという一対の論理的なデータ伝送路を確立することで、送信データを相手に確実に届けられる仕組みがあります。

この仕組みによりTCPでは相手に渡したいデータを、複数フレームにわたって確実に渡すことが出来ます。

以下はコネクション確立済みの通信相手AとBにおいて、Ｂから複数フレームにわたってデータを渡す際のシーケンス図となります。

図において、仮に②、もしくは③のフレームに異常が見られたりフレーム自体が消失した場合TCPにはそれを検知して再送処理を行うことで解決する仕組みが存在します。

UDPにはTCPのようなコネクションはなく、送信者は一方的にフレームを投げるだけです。

フレーム同士のつながりを意識する仕組みがないため、受信者は受信データの組み立てが正常に行えていることを判断するすべがありません。

例えば以下の②と③を受信する順番が入れ替わってしまっていても、それに気づくことが出来ません。

そこで、SOME/IPにはUDPでもTCP同様確実に複数フレームに渡るデータを渡すための仕組みとしてSOME/IP-TPが存在します。

前置きが長くなりましたが、SOME/IP-TPのプロトコルを確認していきます。

SOME/IP-TPのヘッダフォーマットをみていきます。

基本フォーマットに加えてOffset、RES、MというパラメータがReturn Codeの後に続きます。

また、SOME/IP-TPを使用する際はMessage TypeのTP-Flagを1に設定することでSOME/IP-TPのメッセージであることを通知します。

（詳細については前回のMessage Type章を参照）

32bit中の上位28bitとして、ペイロードデータ全体におけるデータオフセットを表現します。

下位4bitは指定不可のため、実質的に指定できるオフセット値は16byte単位となります。

送信者によって必ず000の3bitが指定されますが、受信者はこの値を使用しません。

後続にまだフレームが続くことを意味するフラグです。

最後のフレームのみ0を、それ以外は1を設定します。

規格に記載のあるるSOME/IP-TPを使用した際の通信例を見ていきます。

前提として、5880byteのペイロードを分割送信する単位は1392(16で割り切れる値)とします。

そうすると、ペイロード長1392のフレーム4つと、ペイロード長312のフレーム1つの計5フレームを送信する必要があります。

設定値を整理すると以下のようになります。

フレーム送信順	Length (byte)	TP-Flag	オフセット	Offset （上位28bit設定値）	More Segment Flag
1	8 + 4 + 1392 = 1404	1	0	0x0000000	1
2	8 + 4 + 1392 = 1404	1	1392	0x0000057	1
3	8 + 4 + 1392 = 1404	1	2784	0x00000AE	1
4	8 + 4 + 1392 = 1404	1	4176	0x0000105	1
5	8 + 4 + 312 =324	1	5568	0x000015C	0