The length of the Message Type field shall be 8 bits. 消息类型字段的长度应为8位。
The Message Type field is used to differentiate the types of SOME/IP messages. SOME/IP-SD uses only event messages; thus, it always uses the same type. 消息类型字段用于区分SOME / IP消息的类型。 SOME / IP-SD仅使用event消息; 因此，它总是使用相同的类型。
The value for the Message Type field shall be statically set to 0x02. 消息类型字段的值应静态设置为0x02。
Return Code [8 Bit]
The length of the Return Code field shall be 8 bits. 返回码字段的长度应为8位。
The Return Code is used to signal whether a request was successfully been processed. This is not applicable for SOME/IP-SD; 返回代码用于表示请求是否已成功处理。 这不适用于SOME / IP-SD;
The Return Code field shall be statically set to 0x00. 返回码字段应静态设置为0x00。
The length of the Protocol Version field shall be 8 bits. 协议版本字段的长度应为8位。
The Protocol Version field is used to describe the current version of SOME/IP. 协议版本字段用于描述SOME / IP的当前版本。
The value for the Protocol Version field shall be statically set to 0x01. 协议版本字段的值应静态设置为0x01
Interface Version [8 Bit]
The length of the Interface Version field shall be 8 bits. 接口版本字段的长度应为8位。
The Interface Version field is used to describe the current version of the SOME/IP service; i.e. the current version of SOME/IP-SD itself. 接口版本字段用于描述SOME / IP Service的当前版本; 即SOME / IP-SD本身的当前版本。
The value for the Interface Version field shall be statically set to 0x01. 接口版本字段的值应静态设置为0x01。
The Request ID field shall consist of a Client ID field [16 bits] and a Session ID field [16 bits]. Request ID 字段应由Client ID字段[16位]和Session ID 字段[16位]组成。
The Client ID is not used for Service Discovery, The Client ID shall be set statically to 0x0000. Client ID不用于Service Discovery ，Client ID 应静态设置为0x0000。
The Session ID is used to detect the reboot or restart of other Service Discovery instances in the vehicle in order to repair the local state of the Service Discovery module. Session ID用于检测车辆中其他服务发现实例的重新引导或重新启动，以修复服务发现模块的本地状态。
After initialization of the Service Discovery Module, the Session ID for messages sent by the local ECU shall be 0x0001. Service Discovery模块初始化后，本地ECU发送的消息的Session ID应为0x0001。
The Session ID shall be incremented and stored separately for multicast and every single unicast communication partner every time SoAd_IfTransmit() is called. 每次调用SoAd_IfTransmit()时，对于组播和单播通信伙伴，Session ID都会单独增加并单独存储。
Every time, the Session ID wraps around, the Session ID shall restart with the value 0x0001. 每次Session ID循环， Session ID需要从0x0001重新开始。
Note注意:
This means that the first SD message sent out to the multicast address has Session ID 0x0001 as well as the first SD message sent out to any unicast communication partner has the Session ID 0x0001 as well. 这意味着发送到多播地址的第一条SD消息具有会话ID 0x0001，并且发送给任何单播通信伙伴的第一条SD消息也具有会话ID 0x0001。
Wrap around means that the current value of the Session ID is the max value (0xFFFF) and the next increment would mean the counter must start again. 循环意味着会话ID的当前值是最大值（0xFFFF），再增加一次session意味着计数器必须重新启动。
The application can easily implement “at least once” reliability by using idempotent operations (i.e. operation that can be executed multiple times without side effects) and using a simple timeout mechanism. Figure 6.10 shows the state machines for “at least once” reliability using implicit acknowledgements. When the client sends out the request it starts a timer with the timeout specified for the specific method. If no response is received before the timer expires (round transition at the top), the client will retry the operation. A Typical number of retries would be 2, so that 3 requests are sent. 应用程序可以通过使用幂等操作（即可以多次执行且无副作用的操作）和使用简单的超时机制轻松实现“至少一次”可靠性。 图6.10显示了使用隐式确认“至少一次”可靠性的状态机。 当客户端发出请求时，它会启动一个定时器，并为特定方法指定timeout。 如果在计时器到期之前没有收到响应（顶部的圆形转换），则客户端将重试该操作。 典型的重试次数为2，因此发送3个请求。
The number of retries, the timeout values, and the timeout behavior (constant or exponential back off) are outside of the SOME/IP specification and may be added to the interface definition. retry次数，timeout值和timeout行为（常量或指数退避）不在SOME / IP规范范围之内，可以添加到接口定义中。
Communication Errors and Handling of Communication Errors
When considering the transport of RPC messages different reliability semantics exist: 通信错误和通信错误的处理在考虑RPC消息的传输时，存在不同的可靠性语义： • Maybe — the message might reach the communication partner 也许 – 消息可能会传达给通信伙伴 • At least once — the message reaches the communication partner at least once 至少一次 – 消息至少到达通信伙伴一次 • Exactly once — the message reaches the communication partner exactly once 恰好一次 – 消息恰好一次到达通信伙伴
When using these terms in regard to Request/Response the term applies to both messages (i.e. request and response or error). 在请求/响应方面使用这些术语时，该术语适用于两种消息（即请求和响应或错误）。
While different implementations may implement different approaches, SOME/IP currently achieves “maybe” reliability when using the UDP binding and “exactly once” reliability when using the TCP binding. Further error handling is left to the application. 虽然不同的实现可以使用不同的方法，但是当使用UDP绑定时SOME / IP当前实现“可能”可靠性并且在使用TCP绑定时“完全一次”可靠性。 进一步的错误处理留给应用程序。
For “maybe” reliability, only a single timeout is needed, when using request/response communication in combination of UDP as transport protocol. Following figure shows the state machines for “maybe” reliability. The client’s SOME/IP implementation has to wait for the response for a specified timeout. If the timeout occurs SOME/IP shall signal E_TIMEOUT to the client application. 对于“可能”的可靠性，当使用UDP作为传输协议的请求/响应通信时，仅需要单个超时。 下图显示了“可能”可靠性的状态机。客户端的SOME / IP实现必须等待指定超时的响应。 如果发生超时，SOME / IP将向客户端应用程序发送E_TIMEOUT信号。
For “exactly once” reliability the TCP binding may be used, since TCP was defined to allow for reliable communication. 对于“恰好一次”可靠性，可以使用TCP绑定，因为TCP被定义为允许可靠的通信。
Additional mechanisms to reach higher reliability may be implemented in the application or in a SOME/IP implementation. Keep in mind that the communication does not have to implement these features. Following slide describes such optional reliability mechanisms. 可以在应用程序或SOME / IP实现中实现达到更高可靠性的其他机制。 请记住，通信不必实现这些功能。 下一页描述了这种可选的可靠性机制。
