Error Processing Overview错误处理一览

• The error handling of SOME/IP is shown as an example flow chart in Figure 6.8. This does not include the application based error handling but just covers the error handling in messaging and RPC.
  SOME / IP的错误处理如右图所示的示例流程图所示。 这不包括基于应用程序的错误处理，而只包括消息传递和RPC中的错误处理。

• Error handling shall be based on the message type received (e.g. only methods can be answered with a return code) and shall be checked in a defined.
  错误处理应基于收到的message type（例如，只有method才能回复return code），并按照顺序进行检查。

Return Code返回代码

• The Error Handling is based on an 8 Bit Std_returnType of AUTOSAR. The two most significant bits are reserved and shall be set to 0. The receiver of a return code shall ignore the values of the two most significant bits.
  错误处理基于AUTOSAR的8位Std_returnType。两个最高有效位保留，并应设置为0.接收返回代码时应忽略两个最高有效位的值。

• The system shall not return an error message for events/notifications.
  系统不应针对events/notification返回错误消息。

• The system shall not return an error message for fire&forget methods.
  系统不应针对fire＆forget method返回错误消息。

• The system shall not return an error message for events/notifications and fire&forget methods if the Message Type is set incorrectly to Request or Response.
  如果消息类型被不正确地设置为Request or Response ，则系统也不应返回错误消息给events/notification 和 fire&forget method。

• For request/response methods the error message shall copy over the fields of the SOME/IP header (i.e. Message ID, Request ID, and Interface Version) but not the payload. In addition Message Type and Return Code have to be set to the appropriate values.
  对于Request/Response method， error消息应复制SOME / IP header（比如消息ID，请求ID和接口版本），但不包括payload。此外，必须将Message Type 和Return Code设置为适当的值。

• The SOME/IP implementation shall not use an unknown protocol version but write a supported protocol version in the header.
  实施SOME / IP不应使用未知protocol version ，而是在header中写入支持的协议版本。

• Generation and handling of return codes shall be configurable.
  返回码的生成和处理应该是可配置的。

• Implementations shall not answer with errors to SOME/IP message already carrying an error (i.e. return code 0x01 – 0x1f).
  在实现上，不应用含有error的SOME/IP消息去回复已经携带了error的消息(比如. 返回码 0x01 – 0x1f)。

• The following Return Codes are currently defined and shall be implemented as described:
  目前定义了以下返回代码，应按如下描述进行实施：

Error Message Format错误消息格式

• For a more flexible error handling, SOME/IP allows the user to specify a message layout specific for errors instead of using the message layout for response messages. This is defined by the interface specification and can be used to transport exceptions of higher level programming languages.
  为了实现更灵活的error处理，SOME / IP允许用户指定专门的error message布局，而不是沿用response message的布局。 这由接口规范定义，可用于传输更高级编程语言的异常。

• The recommended layout for the exception message is the following:
  异常消息的推荐布局如下：

• -Union of specific exceptions. At least a generic exception without fields needs to exist.
  特定异常的union。至少存在一个没有字段的通用异常。

• -Dynamic Length String for exception description.
  动态长度字符串用于异常描述。

• The union gives the flexibility to add new exceptions in the future in a type-safe manner. The string is used to transport human readable exception descriptions to ease testing and debugging.
  union提供了以type-safe方式在将来添加新异常的灵活性。 该字符串用于传输具有可读性的异常描述，以便于测试和调试。

Transporting Application Error Codes and Exceptions传输应用程序错误代码和异常

• For the error handling two different mechanisms are supported.
  对于错误处理，支持两种不同的机制.
• All messages have a return code field to carry the return code. However, only responses (Message Types 0x80 and 0x81) use this field to carry a return code to the request (Message Type 0x00) they answer. All other messages set this field to 0x00.
  所有消息都有一个return code字段来携带返回码return code 。 但是，只有Response（消息类型0x80和0x81）使用此字段将return code返回给它们应答的request（消息类型0x00）。 所有其他消息都将此字段设置为0x00
• For more detailed errors the layout of the Error Message(Message Type 0x81) can carry specific fields for error handling, e.g. an Exception String. Error Messages are sent instead of Response Messages.
  对于更详细的错误，error消息（消息类型0x81）可以配置特定字段已进行error处理，例如，异常字符串。在这种情况下，发送error消息而不是response消息。
• This can be used to handle all different application errors that might occur in the server. In addition, problems with the communication medium or intermediate components (e.g. switches) may occur, which have to be handled e.g. by means of reliable transport.
  这可用于处理服务器中可能发生的所有不同应用程序错误。 另外，可能出现通信介质或中间组件（例如，开关）的问题，这些问题必须处理，例如， 通过可靠的传输方式。

Publish/Subscribe Handling

• In contrast to the SOME/IP request/response mechanism there may are cases in which a client requires a set of parameters from a server, but does not want to request that information each time it is required. These are called notifications and concern events and fields.
  与SOME / IP请求/响应机制不同，可能存在客户端需要来自服务器的一组参数但不希望每次需要时请求该信息的情况。 这些被称为notification和event和field。
• All clients needing events and/or notification events shall register using the SOME/IP-SD at run-time with a server.
  所有需要event和/或notification event的客户端都应在运行时使用SOME / IP-SD向服务器进行申请。

Fields

• A field shall be a combination of getter, setter and notification event.
  field应为getter，setter和notification事件的组合。
• A field without a setter and without a getter and without a notifier shall not exist. The field shall contain at least a getter, a setter, or a notifier.
  不存在没有setter且没有getter且没有notifier的field。 该field应至少包含一个getter，一个setter或一个notifier。
• The getter of a field shall be a request/response call that has an empty payload in the request message and the value of the field in the payload of the response message.
  field的getter应是一个请求/响应调用，其request消息中payload为空，response消息中payload中的值就是field的值。
• The setter of a field shall be a request/response call that has the desired value of the field in the payload of the request message and the value that was set to the field in the payload of the response message.
  field的setter应是一个请求/响应调用，其将field的期望值放在request消息的payload中，这个值被设置到response消息的payload中。
• Note注意：
  If the value of the request payload was adapted (e.g. because it was out of limits) the adapted value will be transported in the response payload.
  如果request消息中 payload的值被调整了（例如，因为它超出限制），则这个调整后的值将放在response消息的有效载荷中发送。
  The notifier shall send an event message that transports the value of a field on change and follows the rules for events.
  如果该field的值改变，notifier应发送一个event消息以传输该值，当然，要遵循event规则。

Notification Events 通知事件

• Notifications describe a general Publish/Subscribe-Concept. Usually the server publishes a service to which a client subscribes. On certain events the server will send the client a event, which could be for example an updated value or an event that occurred.
  Notification描述了一般的发布/订阅概念。通常，服务器端发布服务而客户端前来订阅。在某些事件上，服务器端向客户端发送event，该event可以是例如更新的值 或者发生的事件。

• SOME/IP is used only for transporting the updated value and not for the publishing and subscription mechanisms. These mechanisms are implemented by SOME/IP-SD.
  SOME / IP仅用于传输更新的值，而不用于发布和订阅机制。这些机制由SOME / IP-SD实现 。

• When more than one subscribed client on the same ECU exists, the system shall handle the replication of notifications in order to save transmissions on the communication medium. This is especially important, when notifications are transported using multicast messages.
  当同一ECU上有多个订阅客户端时，系统应对notification进行复制以便节省通信介质上的传输。当使用多播消息传输通知时，这尤其重要。

Strategy for sending notifications发送notification的策略

For different use cases different strategies for sending notifications are possible and shall be defined in the service interface. The following examples are common:
对于不同的用例，可以使用不同的发送通知策略，并且应在服务接口中定义。 以下是常见的例子： 

• Cyclic update循环更新
  send an updated value in a fixed interval (e.g. every 100 ms for safety relevant messages with Alive).
  以固定间隔发送更新值（例如，每100毫秒用于Alive的安全相关消息）。
• Update on change变化更新
  send an update as soon as a “value” changes (e.g. door open).
  一旦“值”发生变化（例如开门）就发送更新。
• Epsilon change Epsilon更改
  only send an update when the difference to the last value is greater than a certain epsilon. This concept may be adaptive, i.e. the prediction is based on a history; thus, only when the difference between prediction and current value is greater than epsilon an update is transmitted.
  仅当与最后一个值的差异大于某个阈值时才发送更新。 该概念可以是自适应的，比如预测是基于历史值; 因此，只有当预测值和当前值之间的差值大于epsilon时才发送更新。

Fire&Forget Communication

Requests without response message are called fire&forget.
请求但不需要回复的消息成为fire&forget 。

The implementation is basically the same as for Request/Response with the following differences:
其实现基本上和for Request/Response 一样，只有如下的区别:
•There is no response message.
没有response消息。
•The message type is set to REQUEST_NO_RETURN (i.e. 0x01).
message type设置为REQUEST_NO_RETURN (如0x01)。
•Fire & Forget messages shall not return an error. Error handling and return codes shall be implemented by the application when needed.
Fire & Forget消息不能返回error，如果需要的话，error处理和返回值由应用程序实施 。

Request/Response Communication请求/响应通信

One of the most common communication patterns is the request/ response pattern. One communication partner (in the following called the client) sends a request message, which is answered by another communication partner (the server).
最常见的通信模式之一是请求/响应模式。 客户端发送请求消息，服务器端应答。

Client

• Construct the payload
• Set the Message ID based on the method the client wants to call
• Set the Length field
• Optionally set the Request ID to a unique number
• Set the Protocol Version according
• Set the Interface Version according to the interface definition
• Set the Message Type to Request (i.e. 0x00)
• Set the Return Code to 0x00

Server

• builds it header based on the header of the client ,and in addition
• Construct the payload
• Set the length to the 8 Bytes + new payload size
• Set the Message Type to RESPONSE (i.e. 0x80) or ERROR (i.e. 0x81)
• Set the Return Code

Mapping
For the response and error message the IP addresses and port number of the transport protocol shall match the request message.
对于Response和Error message，传输层的IP Address和Port口需要和Request message匹配

Multiple Service-Instances多个服务实例

• Service-Instances of the same Service are identified through different Instance IDs. It shall be supported that multiple Service-Instances reside on different ECUs as well as multiple Service-Instances of one or more Services reside on one single ECU.
  同一服务的多个服务实例通过不同的Instance ID来识别。应支持多个服务实例驻留在不同的ECU上，以及一个或多个服务的多个服务实例驻留在一个ECU上。
• While different Services shall be able to share the same port number of the transport layer protocol used, multiple Service-Instances of the same service on one single ECU shall listen on different ports per Service-Instance.
  虽然不同的服务应能够共享所使用的传输层协议的相同端口号，但是在一个ECU上的同一服务的多个服务实例应在每个服务实例的不同端口上进行侦听。
• Rationale合理性:
  While Instance IDs are used for Service Discovery, they are not contained in the SOME/IP header.
  虽然 Instance ID用于服务发现，但它们不包含在SOME / IP header中。
• A Service Instance can be identified through the combination of the Service ID combined with the socket (i.e. IP-address, transport protocol (UDP/TCP), and port number). It is recommended that instances use the same port number for UDP and TCP. If a service instance uses UDP port x, only this instance of the service and not another instance of the same service should use exactly TCP port x for its services.
  可以通过 Service ID与套接字的组合（即IP地址，传输协议（UDP / TCP）和端口号）来识别服务实例。建议实例对UDP和TCP使用相同的端口号。如果服务实例使用UDP端口x，则只有该服务实例而不是同一服务的另一个实例应该使用TCP端口x作为其服务。