协议规范

SOME/IP在网络上提供面向服务的通信。一个服务可以由0个或多个事件、方法和字段组成。

事件提供周期性发送的数据，或者是服务器数据发生改变时发送给订阅者的数据。

方法为订阅者提供了在程序端执行远程过程调用的可能性。

字段是下列三个中的一个或多个的组合：

一个notifier，它将数据从提供者发送到订阅者
一个getter，订阅者可以调用它来显式地查询提供者的值
一个setter，当订阅方想要更改提供者的值时，可以调用它

字段的notifier和事件（event)的主要区别在于，事件只在变化时发送，字段的notifier在订阅后直接发送数据。

协议格式(序列化)

序列化描述数据在协议数据单元(pdu)中表示的方式，作为UDP或TCP消息的有效负载，在基于ip的汽车车载网络上传输。

限制

不支持对SOME/IP消息的乱序段进行重新排序。

消息头

[PRS_SOMEIP_00030] Header 布局包括：

Message ID (Service ID/Method ID) [32 Bits]
Length [32 Bits] 长度包含：Request ID 及以后的字段的字节数
Request ID (Client ID/Session ID) [32 Bits]
Protocol Version [8Bits]
Interface Version [8 Bits]
Message Type [8 Bits]
Return Code [8 Bits]

消息头接下来就是Payload 数据了。

在应用端到端（E2E）通信保护的情况下，端到端报头（E2E header）被放置在返回代码Return Code之后，这取决于端到端报头所选择的偏移值。缺省偏移值是64位，将端到端报头置于返回代码和有效负载之间。

[PRS_SOMEIP_00031] 出于互操作性的原因，头部布局对于SOME/IP的所有实现应该是相同的。字段按传输顺序排列，即左上角的字段先传输。

Message ID (32bit)

[PRS_SOMEIP_00034] Messagge ID应该是一个32位的标识符，用于识别:

对某个应用的一个方法的远程过程调用（RPC)
特定的Event

NOTE:Message ID的分配由用户/系统设计人员决定。然而，消息ID对于整个系统(即车辆)是唯一的。

Method ID [15 Bit]

Method ID 如下表所示：

字段	字段	字段
service ID (16bit)	0 (1bit)	Method ID (15bit)

Event ID [15bit]

Event ID 如下表所示：

字段	字段	字段
service ID (16bit)	1 (1bit)	Event ID (15bit)

Eventgroup是服务中字段事件和通知事件的逻辑分组，以便允许订阅。
[PRS_SOMEIP_00365]空的事件组不能被使用。
[PRS_SOMEIP_00366]事件和字段通知至少映射到一个Eventgroup

Length [32 Bit]

[PRS_SOMEIP_00042]Length字段应该包含从Request ID/Session ID开始直到SOME/IP消息结束的字节长度

Request ID [32 Bit]

请求ID允许提供者和订阅者区分同一方法、事件、getter或setter的多个并行使用。

[PRS_SOMEIP_00043] 请求ID对于提供者和订阅者组合是唯一的。

[PRS_SOMEIP_00704] 在生成响应消息时，提供者应将请求ID从请求复制到响应消息。 Note:这允许订阅者将响应映射到已发出的请求，即使有多个未完成的请求。

[PRS_SOMEIP_00044] 在响应到达或预计不会再到达之前(超时)，不能重用请求ID。

[PRS_SOMEIP_00046]请求ID的结构:

字段	字段
Client ID (16bit)	Session ID(16bit)

NOTE:这意味着ECU的实现者可以根据其实现的要求定义client ID，而提供者不需要知道这个布局或定义，因为他只在响应中复制完整的请求ID.

[PRS_SOMEIP_00702] 客户端ID是ECU中调用客户端的唯一标识符。客户端ID允许ECU将多个客户端对同一方法的调用区分开来。

[PRS_SOMEIP_00703] 会话ID是唯一的标识符，用于区分来自相同发送方的顺序消息或请求。

[PRS_SOMEIP_00532] 客户端ID还应支持通过具有可配置的前缀或固定值在整个车辆中是唯一的(例如，客户端ID的最重要字节是诊断地址或应用程序（SW-C）配置的客户端ID）。

例如:

字段	字段	字段
client ID prefix(8bit)	client ID(8bit)	Session ID(16bit)

[PRS_SOMEIP_00932] 如果会话处理不活跃，会话ID应该设置为0x00。

[PRS_SOMEIP_00933] 当会话处理处于活动状态时，会话ID应设置为[0x1, 0xFFFF]范围内的值。

[PRS_SOMEIP_00934] 如果会话处理是活动的，会话ID应根据各自的用例增加（关于专用用例的详细信息包含在单独的规格项中）。

[PRS_SOMEIP_00533] 请求/响应方法应该使用会话处理机制处理会话ID。会话ID应该在每次调用后递增。

[PRS_SOMEIP_00521] 当会话ID达到0xFFFF时，它应该绕到0x01重新开始。

[PRS_SOMEIP_00739] 对于请求/响应方法，如果响应的会话ID与请求的会话ID不匹配，订阅者必须忽略响应。

[PRS_SOMEIP_00935] 对于通知消息，接收者应该忽略会话ID，当会话处理不活跃时。

[PRS_SOMEIP_00936] 对于通知消息，接收方应处理会话ID根据各自的用例（关于专用用例的详细信息包含在单独的规格项中）。

Protocol Version [8 Bit]

协议版本用来识别使用的SOME/IP报头格式(不包括有效载荷格式)。

[PRS_SOMEIP_00050] 对于SOME/IP报头中所有不兼容的更改，协议版本应该增加。如果基于旧协议版本的接收方不丢弃消息并不正确地处理它，则更改是不兼容的。

NOTE:协议版本本身是SOME/IP报头的一部分，因此协议版本在报头中的位置不能改变。

NOTE:仅影响有效负载格式的变更不应增加协议版本。

Interface Version [8 Bit]

[PRS_SOMEIP_00053] 接口版本应该是一个包含服务接口(service interface)的主版本Major version的8位字段。

Message Type [8 Bit]

[PRS_SOMEIP_00055] 消息类型字段用于区分不同类型的消息，应包含下表所示的值:

Number	Value	Description
0x00	REQUEST	A request expecting a response (even void)
0x01	REQUEST_NO_RETURN	A fire&forget request
0x02	NOTIFICATION	A request of a notification/event callback expecting no response
0x80	RESPONSE	The response message
0x81	ERROR	The response containing an error
0x20	TP_REQUEST	A TP request expecting a response (even void)
0x21	TP_REQUEST_NO_RETURN	A TP fire&forget request
0x22	TP_NOTIFICATION	A TP request of a notification/event callback expecting no response
0xa0	TP_RESPONSE	The TP response message
0xa1	TP_ERROR	The TP response containing an error

[PRS_SOMEIP_00701] 当没有错误发生时，常规请求(消息类型0x00)应由响应(消息类型0x80)响应。如果发生错误，将响应错误消息(消息类型0x81)。

也可以发送没有响应消息的请求message type 0x01；为了更新值，存在一个回调接口(消息类型0x02)

[PRS_SOMEIP_00367] 消息类型的第三高位(=0x20)应该被称为TP-Flag，并且应该设置为1来表示当前的SOME/IP消息是一个消息段(Segment)。消息类型的其他位按本节中指定的方式设置。

Return Code [8 Bit]

[PRS_SOMEIP_00058] 返回代码用于指示请求是否成功处理。为了简化Header布局，每个消息都传输字段返回代码。特定消息类型允许的返回代码如下表所示:

Message Type	Allowed Return Codes
REQUEST	N/A set to 0x00 (E_OK)
REQUEST_NO_RETURN	N/A set to 0x00 (E_OK)
NOTIFICATION	N/A set to 0x00 (E_OK)
RESPONSE	See Return Codes in [PRS_SOMEIP_00191]
ERROR	See Return Codes in [PRS_SOMEIP_00191]. Shall not be 0x00 (E_OK)

Payload [variable size]

载荷字段携带参数,参数的序列化将在后续章节说明。

SOME/IP有效载荷字段的大小取决于所使用的传输协议。UDP SOME/IP负载应该在0到1400字节之间。限制在1400字节是以便允许协议栈的未来更改（例如改成IPv6或增加安全手段）由于TCP支持有效负载分段，因此自动支持更大的负载。

有效负载可以由事件的数据元素或方法的参数组成。

Endianess

[PRS_SOMEIP_00368] 报头应该按照网络字节顺序进行编码（big endian）。

[PRS_SOMEIP_00369] 载荷内参数的字节顺序应由配置来定义。

2_SOMEIP 报文_消息头相关推荐

HTTP协议简介_请求消息/请求数据包/请求报文_响应消息/响应数据包/响应报文
文章目录 HTTP 介绍请求数据包/请求消息/请求报文请求数据包解析响应数据包/响应消息/响应报文 HTTP 介绍概念:Hyper Text Transfer Protocol 超文本传输协议 ...
Java包数据消息头消息尾_读Socket流时产生阻塞的解决方案（粘包拆包问题）
转自:https://www.cnblogs.com/qhyuan1992/p/5385289.html 其实最终讨论的是TCP通信过程中的粘包拆包(半包)问题. 在用socket写一个服务器时遇到了 ...
java socket发送定长报文_定长消息报文的组包与解包简单封装(Java实现)
报文组包解包在实际项目中经常会碰到不同系统之间的数据交换,有些是用webservice.有些则是使用发socket消息的方式,将需要发送的消息组装成特定格式的字符串或Xml格式的文件,再通过so ...
Netty详解（七）：Netty 编解码以及消息头编解码器
1. MessagePack 概述 MessagePack是一个高效的二进制序列化框架,像JSON一样支持不同语言间的数据交换,速度更快,序列化之后的码流更小. MessagePacke优点编解码高 ...
Linphone android去电增加自定义SIP消息头的流程分析
一.首先看一下如何在发起去电的sip请求中添加自定义的消息头增加自定义头消息发方法,so已经提供了native方法, 发起呼叫的示例如下: LinphoneCallParams params = l ...
理解HTTP消息头【很完整，例子也很丰富】
(一)初识HTTP消息头但凡搞WEB开发的人都离不开HTTP(超文本传输协议),而要了解HTTP,除了HTML本身以外,还有一部分不可忽视的就是HTTP消息头. 做过Socket编程的人都知道,当我 ...
SpringMVC返回json是设置编辑等消息头，消息头信息介绍（respone.setHeader,这个从网上获取）
1. SpringMVC中设置消息头,例子如下: @RequestMapping(value="/hasOperatePrivilege") @ResponseBody publ ...
深入掌握JMS（六）：消息头
一个消息对象分为三部分:消息头(Headers),属性(Properties)和消息体(Payload).对于StreamMessage和 MapMessage,消息本身就有特 ...
java消息头,Java网络编程从入门到精通：HTTP消息头字段
Java网络编程从入门到精通:HTTP消息头字段一.通用头字段 1. Connection 这个字段只在HTTP1.1协议中存在.它决定了客户端和服务器进行了一次会话后, 服务器是否立即关闭网络连接 ...

2_SOMEIP 报文_消息头