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),并按照顺序进行检查。
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: 目前定义了以下返回代码,应按如下描述进行实施:
ID
Name
Description
0x00
E_OK
No
error occurred
0x01
E_NOT_OK
An
unspecified error occurred
0x02
E_UNKNOWN_SERVICE
The
requested Service ID is unknown.
0x03
E_UNKNOWN_METHOD
The
requested Method ID is unknown. Service ID is known.
0x04
E_NOT_READY
Service
ID and Method ID are known. Application not running.
0x05
E_NOT_REACHABLE
System
running the service is not reachable (internal error code only).
0x06
E_TIMEOUT
A
timeout occurred (internal error code only).
0x07
E_WRONG_PROTOCOL_
VERSION
VersionofSOME/IPprotocolnotsupported
0x08
E_WRONG_INTERFACE_
VERSION
Interface
version mismatch
0x09
E_MALFORMED_MESSAGE
Deserialization
error, so that payload cannot be deserialized.
0x0a
E_WRONG_MESSAGE_TYPE
An
unexpected message type was received (e.g. REQUEST_NO_RETURN for a method
defined as REQUEST.)
0x0b – 0x1f
RESERVED
Reserved
for generic SOME/IP errors. These errors will be specified in future versions
of this document.
0x20 – 0x3f
RESERVED
Reservedforspecificerrorsofservicesand
methods. These errors are specified by the interface specification.
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. 这可用于处理服务器中可能发生的所有不同应用程序错误。 另外,可能出现通信介质或中间组件(例如,开关)的问题,这些问题必须处理,例如, 通过可靠的传输方式。
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向服务器进行申请。
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规则。