• The TCP binding of SOME/IP is heavily based on the UDP binding. In contrast to the UDP binding, the TCP binding allows much bigger SOME/IP messages and uses the robustness features of TCP (coping with loss, reorder, duplication, etc.).
  SOME / IP的TCP绑定很大程度上基于UDP绑定。 与UDP绑定相比，TCP绑定允许更大的SOME / IP消息并使用TCP的鲁棒性（应对丢失，重新排序，复制等）。
• Every SOME/IP payload shall have its own SOME/IP header.
  每个SOME / IP payload都应具有自己的SOME / IP hearder。
• In order to lower latency and reaction time, Nagle’s algorithm shall be turned off (TCP_NODELAY).
  为了降低延迟和反应时间，应关闭Nagle算法（TCP_NODELAY）。
• When the TCP connection is lost, outstanding requests shall be handled as timeouts. Since TCP handles reliability, additional means of reliability are not needed.
  当TCP连接丢失时，未完成的请求应作为超时处理。 由于TCP的可靠性，因此不需要额外的可靠性手段。
• The client and server shall use a single TCP connection for all methods, events, and notifications of a service instance. When having more than one instance of a service a TCP connection per services instance is needed.
  客户端和服务端应对服务实例的所有method，event和notification使用一个TCP连接。 当具有多个服务实例时，则每个服务实例需要一个TCP连接。
• The TCP connection shall be used for as many services as possible to minimize the number of TCP connections between the client and the server (basically only one connection per TCP port of server).
  TCP连接应该用于尽可能多的服务，以最小化客户端和服务端之间的TCP连接数（基本上每个服务端的TCP端口只有一个连接）。
• The TCP connection shall be opened by the client, when the first method call shall be transport or the client tries to receive the first notifications.
  当发送第一个method调用或者客户端打算接收第一个notification，客户端应该负责打开TCP连接。
• The client is responsible for reestablishing the TCP connection whenever it fails.
  客户端负责在失败时重新建立TCP连接。
• The TCP connection shall be closed by the client, when the TCP connection is not required anymore.
  当不再需要TCP连接时，客户端应关闭TCP连接。
• The TCP connection shall be closed by the client, when all Services using the TCP connections are not available anymore (stopped or timed out).
  当使用TCP连接的所有服务不再可用（停止或超时）时，客户端应关闭TCP连接。
• The server shall not stop the TCP connection when stopping all services the TCP connection was used for but give the client enough time to process the control data to shutdown the TCP connection itself.
  当服务器停止使用某TCP连接的所有服务时，服务器不应停止该TCP连接，但是给客户端足够的时间来处理控制数据以关闭TCP连接。
• Rational合理性:
  When the server closes the TCP connection before the client recognized that the TCP is not needed anymore, the client will try to reestablish the TCP connection.
  当服务器关闭TCP连接而客户端并不清楚不需要该TCP了，客户端将尝试重新建立TCP连接。

• The UDP binding of SOME/IP is straight forward by transporting SOME/IP messages in UDP packets. The SOME/IP messages shall not be fragmented. Therefore care shall be taken that SOME/IP messages are not too big, i.e. up to 1400 Bytes of SOME/IP payload. Messages with bigger payload shall not be transported over UDP but with e.g. TCP.
  通过在UDP数据包中传输SOME / IP消息，SOME / IP的UDP绑定是直接的。 SOME / IP消息不应该被分段。 因此，应注意SOME / IP消息不要太大，即SOME / IP payload最多1400字节。 payload较大的消息不得通过UDP传输但是可以通过TCP传输。

• The header format allows transporting more than one SOME/IP message in a single UDP packet. The SOME/IP implementation shall identify the end of a SOME/IP message by means of the SOME/IP length field. Based on the UDP length field, SOME/IP shall determine if there are additional SOME/IP messages in the UDP packet.
  Header格式允许在单个UDP数据包中传输多个SOME / IP消息。 SOME / IP实现应通过SOME / IP length字段识别SOME / IP消息的结束。 根据UDP length字段，SOME / IP应确定是否有其他SOME / IP消息在UDP数据包中。

• Each SOME/IP payload shall have its own SOME/IP header.
  每个SOME / IP payload都应有自己的SOME / IP header。

• In order to transport SOME/IP messages of IP different transport protocols may be used. SOME/IP currently supports UDP and TCP. Their bindings are explained in the following sections.
  为了传输SOME / IP消息，可以使用不同的传输协议。 SOME / IP目前支持UDP和TCP。它们的绑定在以下部分中进行了解释。
• If a server runs different instances of the same service, messages belonging to different service instances shall be mapped to the service instance by the transport protocol port on the server side.
  如果服务端运行相同服务的不同实例，则属于不同服务实例的消息应通过服务端的传输协议端口映射到服务实例。
• All Transport Protocol Bindings shall support transporting more than one SOME/IP message in a Transport Layer PDU (i.e. UDP packet or TCP segment).
  所有传输协议绑定应支持在传输层PDU（即UDP数据包或TCP段）中传输多个SOME / IP消息。
• The receiving SOME/IP implementation shall be capable of receiving unaligned SOME/IP messages transported by UDP or TCP.
  接收SOME / IP的实现，应能够接收由UDP或TCP传输的未对齐SOME / IP消息。
• Rationale合理性:
  When transporting multiple SOME/IP payloads in UDP or TCP the alignment of the payloads can be only guaranteed, if the length of every payloads is a multiple of the alignment size (e.g. 32 bits).
  当以UDP或TCP传输多个SOME / IP payload时，如果每个payload的长度是对齐大小的倍数（例如: 32位），则仅可以保证有效载荷的对齐。

Basic Data types
The following basic datatypes shall be supported:

The Byte Order is specified for each parameter by the interface definition.
In addition, uint64 and sint64 types shall be supported at least on infotainment ECUs.

Structured Datatypes (structs)

String

• Serialization of string (fixed length)

• Serialization of string (dynamic length)

Arrays (fixed length)

• One-dimensional array, fixed length: a[n]

• Multi-dimensional array, fixed length: a[n][m]

Dynamic Length Arrays / Variable Size Arrays

• One-dimensional array, dynamic length

• Multi-dimensional array, dynamic length

Union

• The default serialization layout of unions in SOME/IP is shown as following.
  SOME / IP中 union的默认序列化布局。
• SOME/IP allows to add a length field of 8, 16 or 32 bit in front of unions.
  SOME / IP允许在union前添加8,16或32位的长度字段。
• The length field of a union describes the number of bytes in the union. This allows the deserializer to quickly calculate the position where the data after the union begin in the serialized data stream. This gets necessary if the union contains data which are larger than expected, for example if a struct was extended with appended new members and only the first “old” members are deserialized by the SOME/IP transformer.
  union的长度字段描述联合中的字节数。 这允许deserializer快速计算串行数据流中union开始后的数据的位置。 如果联合包含比预期更大的数据，则这是必要的，例如，如果一个结构体扩展了附加的新成员，并且只有第一个“旧”成员被SOME / IP transformer反序列化。

• Example:
  Union of uint8/uint16 both padded to 32 bit.
  uint8 / uint16的联合都填充为32位。
  In this example a length of the length field is specified as 32 bits. The union shall support a uint8 and a uint16 as elements. Both are padded to the 32 bit boundary (length=4 Bytes).
  在这个例子中，长度字段的长度被指定为32位。 union应支持uint8和uint16作为元素。 两者都填充到32位边界（长度= 4字节）。
  

A uint8 will be serialized like this:
uint8将会像这样被序列化：

A uint16 will be serialized like this:
uint16将会像这样被序列化：

Payload [variable size]

• In the payload field the parameters are carried.
  Parameter被携带于Payload字段中 。
• The size of the SOME/IP payload field depends on the transport protocol used. With UDP the SOME/IP payload shall be between 0 and 1400 Bytes. The limitation to 1400 Bytes is needed in order to allow for future changes to protocol stack (e.g. changing to IPv6 or adding security means). Since TCP supports segmentation of payloads, larger sizes are automatically supported.
  SOME / IP payload字段的大小取决于使用的传输协议。 对于UDP，SOME / IP有效载荷应该在0到1400字节之间。限制为1400字节是为了允许将来对协议栈进行更改（例如更改为IPv6或添加安全机制）。 由于TCP支持有效载荷的分段，所以自动支持更大的尺寸。

Return Code [8 Bit]

• The Return Code is used to signal whether a request was successfully been processed. For simplification of the header layout, every message transports the field Return Code.
  Return Code用于表示request是否已成功处理。 为了简化header布局，每条消息都传输Return代码。
• Messages of Type REQUEST, REQUEST_NO_RETURN, and Notification have to set the Return Code to 0x00 (E_OK). The allowed Return Codes for specific message types are:
  类型为REQUEST, REQUEST_NO_RETURN和Notification的消息必须将返回码设置为0x00（E_OK）。 允许的特定消息类型的返回码是：

• Note注意：
  The Return Code is is not applicable for SOME/IP-SD.
  Return Code不适用于SOME / IP-SD。

Protocol Version [8 Bit]
Protocol Version is an 8 Bit field containing the SOME/IP protocol version, which currently shall be set to 0x01.
Protocol Version是一个8位字段，其中包含SOME/IP的协议版本，目前应该被设置为0x01 。

Interface Version [8 Bit]
Interface Version is an 8 Bit field that contains the Major Version of the Service Interface.
Interface Version是一个8位字段，其中包含Service Interface的Major Version 。

Rationale合理性：
This is required to catch mismatches in Service definitions and allows debugging tools to identify the Service Interface used, if version is used.
这是捕捉服务定义中的不一致所必需的，并且允许调试工具识别使用的服务接口（如果使用了版本）。

SOME/IP报文格式-Message Type

Message Type [8 Bit]

The Message Type field is used to differentiate different types of messages and shall contain the following values：
Message Type用来区别不同类型的message，且应当包含如下的值：

 •Regular request (message type 0x00) will be answered by a response (message type 0x80), when no error occurred. If errors occur an error message (message type 0x81) will be sent. It is also possible to send a request that does not have a response message(message type 0x01). For updating values through notification a callback interface exists (message type 0x02). 
 常规request （消息类型0x00）将在未发生错误时由response （消息类型0x80）应答。 如果发生错误，则会发送error消息（消息类型0x81）。 也可以发送不需要响应消息的请求（消息类型0x01）。 为了通过notification更新值，存在一个callback接口（消息类型0x02）。
 
 •For all messages an optional acknowledgment (ACK) exists. These care is defined for transport protocols (i.e. UDP) that do not acknowledge a received message. ACKs are only transported when the interface specification requires it. Only the usage of the REQUEST_ACK is currently specified in this document. All other ACKs are currently informational and do not need to be implemented.
 对于所有消息，存在可选的acknowledgment 报文（ACK）。 这是为那些并不告知收到消息的某些传输层协议（如UDP）而定义的。 ACK只在interface specification要求时才被传输。 本文档中仅规定了REQUEST_ACK的用法。 所有其他ACK现在都是信息性的，不需要实施。 

SOME/IP报文-Request ID

Request ID [32 Bit]

The Request ID allows a client to differentiate multiple calls to the same method. Therefore, the Request ID has to be unique for a single client and server combination only. When generating a response message, the server has to copy the Request ID from the request to the response message. This allows the client to map a response to the issued request even with more than one request outstanding.
Request ID允许客户端区分相同的Method的多个call 。 Request  ID对于客户端和服务器的一个组合来说，需要时唯一的。 在生成响应消息时，服务器必须将请求中的Request ID复制到response消息中。 这允许客户将响应映射到发出的请求，即使有多个请求未完成。

Request ID might be reused as soon as the response arrived or is not expected to arrive anymore(timeout). In most automotive use cases a very low number of outstanding requests are expected. For small systems without the possibility of parallel requests, the Request ID might always set to the same value.
只要响应已经接收到或者不再期望这个响应（超时），就可以重新使用Request ID。 在汽车使用案例中，只有很少数量的未完成的请求在被继续等待。 小型系统里在没有并行请求的可能性的情况下， Request ID可能总是设置为相同的值。

For AUTOSAR systems the Request ID needs to be structured as shown in the next section. Even for non-AUTOSAR systems it is required to encode the callers Client ID as shown in the next section.
在AUTOSAR 架构下, Request ID需要结构化。 即使对于非AUTOSAR系统，也需要对调用者的客户端ID进行编码

Client ID [16 Bit]

In AUTOSAR the Request ID is constructed of the Client ID and Session ID:

Note注意：
This means that the implementer of an ECU can define the Client-IDs as required by his implementation and the Server does not need to know this layout or definitions because he just copies the complete Request-ID in the response.
这意味着ECU的实施者可以按照他的实施要求来定义Client ID，并且服务器不需要知道这个布局或定义，因为他只是将整个Request-ID复制到Response中。

The Client ID is the unique identifier for the calling client inside the ECU. The Session ID is a unique identifier chosen by the client for each call. If session handling is not used, the Session ID shall be set to 0x0000.
Client ID是ECU内Call客户端的唯一标识符。 Session ID是客户端为每个call选择的唯一标识符。 如果不需要进行Session处理，则Session ID应设置为0x0000。

The Client ID shall also support being unique in the overall vehicle by having a configurable prefix or fixed value (e.g. the most significant byte of Client ID being the diagnostics address or a configured Client ID for a given application/SW-C).c()
Client ID还应通过具有可配置前缀或固定值支持其在整个车辆中唯一性（例如，Client ID的最高位是诊断地址或为特定应用程序/SWC配置专门Client ID)

Client  ID不用于Service Discovery

Session ID [16 Bit]

Request/Response methods shall use session handling with Session IDs starting with 0x0001.
Request/Response method需要使用以ID以0x0001开头的session 来处理

Events,notification events,and Fire&Forget methods shall use session handling if required by the application. This could be for example because of functional safety reasons.
Event, notification event和Fire&Forget methods 需要使用session处理，如果应用需要的话。比如因为功能安全的需要

For events,notification events,and Fire&Forget methods the Session ID should start with 1 and be incremented for every message sent.
对于events,notification events,和 Fire&Forget methods ,Session ID需要以0x0001开头，且每次message发出的时候递增。

When the Session ID reaches 0xFFFF, it shall start with 0x0001 again.
当Session ID达到0xFFFF,则其回到0x0001重新开始