SOME/IP 协议介绍（二）

1. SOME/IP header

出于互操作性的原因，所有SOME/IP的实现都应具有相同的标头布局如图1中显示。字段按传输顺序呈现，即左上方的字段首先进行传输。在接下来的章节中，将描述不同的标头字段及其用途。

1.1. IP地址/端口号

图1中的布局显示了在IP和所使用的传输协议上的基本头部布局。这种格式也可以很容易地在AUTOSAR中实现。有关套接字处理的详细信息，请参阅AUTOSAR Socket Adaptor SWS。

1.1.1. IP地址和端口的映射

对于响应和错误消息，传输协议的IP地址和端口号应与请求消息相匹配。这意味着：

• 响应的源IP地址 = 请求的目标IP地址。

• 响应的目标IP地址 = 请求的源IP地址。

• 响应的源端口 = 请求的目标端口。

• 响应的目标端口 = 请求的源端口。

• 传输协议（TCP或UDP）保持不变。

1.1.2. 消息ID [32位]

消息ID是一个32位标识符，用于将RPC调用分派给应用程序的方法并标识通知。消息ID必须能够唯一标识一个方法。

消息ID的分配由用户自行决定；然而，消息ID必须在整个系统（即车辆）中是唯一的。消息ID可以最好地与CAN ID进行比较，并应使用类似的处理过程进行处理。下一节将描述如何构造消息ID的结构，以便简化消息ID的组织。

1.1.2.1. 消息ID的结构

为了对不同的方法和事件进行结构化，它们被分组成服务。服务包括一组方法和事件，以及一个仅用于该服务的服务ID。事件还可以被分组成事件组，以简化事件的注册过程。
对于RPC调用，我们将ID结构化为2^16个服务，每个服务有2^15个方法：

Service ID [16 Bit]

0 [1 Bit]

Method ID [last 15 Bit]

使用16位的服务ID和以0位开始的16位的方法ID，这样可以支持最多65536个服务，每个服务最多有32768个方法。

由于事件（参见通知或发布/订阅）使用RPC进行传输，因此事件的ID空间进一步进行了结构化：

Service ID [16 Bit]

0 [1 Bit]

Event ID [last 15 Bit]

1.2. 长度 [32 位]

Length是一个32位字段，包含以请求ID/客户端ID开头的有效载荷的字节长度。长度不包括包含消息ID和长度字段的头部部分，因为它基于AUTOSAR Socket Adaptor的功能。

1.3. 请求ID [32位]

请求ID允许客户端区分对同一方法的多个调用。因此，请求ID必须在单个客户端和服务器组合中是唯一的。在生成响应消息时，服务器必须将请求ID从请求复制到响应消息中。这使得客户端可以将响应映射到已发出的请求，即使存在多个未完成的请求。

请求ID可能在响应到达或不再预期到达（超时）后被重新使用。在大多数汽车应用场景中，预计只会有很少数量的未完成请求。对于没有并行请求可能性的小型系统，请求ID可能始终设置为相同的值。
对于AUTOSAR系统，请求ID需要按照下一节所示的结构进行组织。即使对于非AUTOSAR系统，建议按照下一节所示的方式对调用者的客户端ID进行编码。

1.3.1. 请求ID的结构

在AUTOSAR中，请求ID由客户端ID和会话ID构成：

Client ID [16 Bits]

Session ID [16 Bits]

客户端ID是ECU内部调用客户端的唯一标识符。会话ID是由客户端为每个调用选择的唯一标识符。如果不使用会话处理，会话ID应设置为0x0000。

1.4. 协议版本号 [8位]

协议版本是一个8位字段，包含当前的SOME/IP协议版本，应设置为0x01。

1.5. 接口主版本号 [8位]

接口主版本号是一个8位字段，包含服务接口的主版本号。
原因：这是为了捕获服务定义中的不匹配，并且如果使用版本号，它允许调试工具识别使用的服务接口。

1.6. 消息类型 [8位]

消息类型字段用于区分不同类型的消息，可以包含以下值：

Number	Value	Description
0x00	REQUEST	请求 - 期望获得响应（即使是void）
0x01	REQUEST_NO_RETURN	请求无返回 - 一次性请求
0x02	NOTIFICATION	通知 - 请求通知/事件回调，不期望有响应
0x40	REQUEST ACK	请求确认 - REQUEST（可选）
0x41	REQUEST_NO_RETURN ACK	请求无返回确认 -  REQUEST_NO_RETURN（信息性）
0x42	NOTIFICATION ACK	通知确认 - NOTIFICATION（信息性）
0x80	RESPONSE	响应 - 响应消息
0x81	ERROR	错误 - 响应包含错误信息
0xC0	RESPONSE ACK	响应确认 - RESPONSE（信息性）
0xC1	ERROR ACK	错误确认 - ERROR（信息性）

常规请求REQUEST（消息类型0x00）在没有错误发生时将由响应消息RESPONSE（消息类型0x80）进行回答。如果发生错误，将发送错误消息ERROR（消息类型0x81）。还可以发送没有响应消息的请求REQUEST_NO_RETURN（消息类型0x01）。对于通过通知NOTIFICATION进行值更新，存在一个回调接口（消息类型0x02）。

对于所有的消息，都存在可选的确认（ACK）。这些可以在传输协议（例如UDP）不确认接收到的消息的情况下使用。只有当接口规范要求时，才会传输ACK。目前，本文档仅指定了使用REQUEST_ACK。所有其他ACK目前仅作为信息提供，无需实现。

1.7. 返回码 [8位]

返回码用于指示请求是否成功处理。为了简化头部布局，每个消息都传输返回码字段。
类型为REQUEST、REQUEST_NO_RETURN和Notification的消息必须将返回码设置为0x00（E_OK）。特定消息类型的允许返回码如下：

Message Type	Allowed Return Codes
REQUEST	N/A (无需设置)设置为0x00 (E_OK)
REQUEST_NO_RETURN	N/A (无需设置)设置为0x00 (E_OK)
NOTIFICATION	N/A (无需设置)设置为0x00 (E_OK)
RESPONSE	详细的描述将在后面的博客中介绍
ERROR	详细的描述将在后面的博客中介绍，不得为0x00 (E_OK)

确认消息类型应从待确认的消息中复制返回码。

1.8. 负载 [可变大小]

参数被携带在负载字段中。参数的序列化将在下一部分中进行规定。
负载字段的大小取决于所使用的传输协议。在UDP中，负载大小可以在0到1400字节之间。将负载限制为1400字节是为了允许将来对协议栈进行更改（例如切换到IPv6或添加安全手段）。由于TCP支持负载的分段，因此自动支持更大的大小。