SOME/IP in AUTOSAR Classic

SOME/IP

Return codes and errors

Problems with a REQUEST travel back in the Return Code of the answer: an ERROR message, or a RESPONSE when the server method itself reports the error. Some problems are caught before the server method even runs, and some can only show up as a timeout.

Two ways to report, one used here

SOME/IP knows two ways for a server to report a problem: the Return Code in the SOME/IP header of the answer, or an explicit error message that also carries details (exception data, such as a text) in its payload. The SOME/IP transformer of the Classic Platform uses the Return Code. The explicit error message with exception data is not supported by it.

The general return codes

Return CodeMeans
E_OKNo problem.
E_NOT_OKA problem without further detail.
E_UNKNOWN_SERVICE, E_UNKNOWN_METHODThe Service ID, or the Method ID within a known service, is unknown.
E_NOT_READYService and method are known, but the application behind them is not running.
E_NOT_REACHABLE, E_TIMEOUTUsed only inside the client side; never sent on the wire.
E_WRONG_PROTOCOL_VERSION, E_WRONG_INTERFACE_VERSIONThe receiver does not support the Protocol Version or the Interface Version in the header.
E_MALFORMED_MESSAGEThe payload cannot be deserialized.
E_WRONG_MESSAGE_TYPEUnexpected Message Type, for example a REQUEST_NO_RETURN for a method that needs a response.
E2E return codesProblems found by end-to-end protection, if it is used.

On top of these, a method can report its own errors: each ApplicationError (an error the method itself defines; it is listed for the ClientServerOperation). They travel in the same Return Code, moved into a range of values reserved for them so they never clash with the general return codes. The answer stays a normal RESPONSE: the Message Type is not changed to ERROR, and the payload still carries the outputs of the method.

Three rules that always hold

rule 1

Only REQUESTs get errors

No ERROR is ever sent back for an event or for a fire&forget call.

rule 2

No error for an error

A message that reports an error is never itself answered with an ERROR.

rule 3

Same IDs, empty payload

An ERROR copies the Message ID, the Request ID and the Interface Version from the REQUEST. Its payload is empty.

Where each problem is caught

A REQUEST arrives at the server ECU. SoAd drops it if it has no route for the Message ID. The SOME/IP transformer checks versions, Message Type and payload; a failure gives an ERROR with E_WRONG_INTERFACE_VERSION, E_MALFORMED_MESSAGE and so on. Otherwise the server method runs and returns E_OK or an ApplicationError, which goes back in the Return Code of a RESPONSE. a REQUEST arrives SoAd: is there a routefor this Message ID? transformer: versions,Message Type, payload?(deserializing the REQUEST) server method runsE_OK or an ApplicationError yes OK no dropped silently, no answer at allthe client will see E_TIMEOUT problem ERROR · E_WRONG_INTERFACE_VERSION,E_MALFORMED_MESSAGE …with autonomous error reaction; otherwisethe server application is told and decides RESPONSE · E_OK or an ApplicationError,with the outputs
Figure 1. Follow the REQUEST down the left column. Only the top exit is silent: SoAd routes messages by their Message ID and has no way to answer one it cannot place.

SoAd reads only the first part of the SOME/IP header: the Message ID and the Length. It does not check versions; that is done by the SOME/IP transformer when it deserializes. If the transformer is set to an autonomous error reaction (the transformer sends the ERROR on its own, without the server SWC), the client gets the ERROR at once. (The R20-11 transformer specification writes Message Type RESPONSE into this answer; the protocol specification asks for ERROR, and this course follows the protocol specification.) And because the transformer of the client also checks each RESPONSE it receives, a client can likewise detect a broken RESPONSE.

Try it

Pick a problem and step through the story.

Things to notice. Three of the four problems end with an answer the client can read: an ERROR, or a RESPONSE for the ApplicationError. The unknown Method ID ends with silence and E_TIMEOUT, because nobody on the server side may answer it. In every answer, the Client ID and Session ID are those of the REQUEST.

Check yourself optional

New terms in this lesson

TermMeaning
Return CodeHeader field: E_OK or the code of the problem
ERRORThe Message Type of an answer that reports a problem
E_NOT_OK, E_UNKNOWN_SERVICE, E_UNKNOWN_METHOD, E_NOT_READY, E_NOT_REACHABLE, E_TIMEOUT, E_WRONG_PROTOCOL_VERSION, E_WRONG_INTERFACE_VERSION, E_MALFORMED_MESSAGE, E_WRONG_MESSAGE_TYPEThe general return codes (table above)
ApplicationErrorAn error the method itself defines, carried in the Return Code of a RESPONSE
autonomous error reactionThe transformer, not the server SWC, sends the ERROR on its own

Source: SOME/IP Protocol Specification, R20-11, section 4.2.6; SOME/IP Transformer, R20-11, sections 7.3.1, 7.3.4 and Appendix B; Socket Adaptor, R20-11, section 4.1.