SOME/IP in AUTOSAR Classic

SOME/IP

Methods: request and response

A client sends a REQUEST, the server runs the method and sends back a RESPONSE that carries the same Request ID, so the client knows which request it belongs to.

REQUEST and RESPONSE

Sequence: the brake ECU sends a REQUEST for the method Calibrate with Client ID 0x10 and Session ID 7; the radar ECU runs Calibrate and sends a RESPONSE with Client ID 0x10, Session ID 7 and Return Code E_OK. Brake ECU (client) Radar ECU (server) REQUEST · Calibrate · Client ID 0x10 · Session ID 7 payload: the input arguments runs Calibrate RESPONSE · Calibrate · Client ID 0x10 · Session ID 7 · E_OK payload: the output arguments Session ID 7 matches: done
Figure 1. Compare the two arrows: everything that identifies the call (Service ID, Method ID, Client ID, Session ID) is the same in both. Only the Message Type, the Return Code and the payload differ.

client

The REQUEST

Message Type REQUEST. The payload holds the input arguments in the order the method lists them. The Session ID takes the next value.

server

The RESPONSE

Built from the SOME/IP header of the request: same Message ID, same Client ID and Session ID. Message Type RESPONSE, the Return Code E_OK, the output arguments as payload.

client

The match

A response whose Request ID does not match an open request is ignored. A response to a request that was not completely sent yet is ignored too.

Waiting has a limit

Over UDP (connectionless transport, lesson 22) a message can get lost and nobody repeats it. SOME/IP calls this reliability "maybe". So the client side waits only for a set time. If no matching response arrives, the call ends with E_TIMEOUT (no response in time; in the RTE the call returns RTE_E_TIMEOUT) instead of a result, and whether to try again is up to the application.

Over TCP (connection-oriented transport that repeats lost data) a request and its response arrive "exactly once". If the TCP connection breaks, every request still waiting is treated as timed out.

State diagram of the client: from idle, sending a REQUEST enters waiting for the RESPONSE; a matching RESPONSE returns to idle with a result; the timeout returns to idle with E_TIMEOUT. idle waiting for RESPONSE send REQUEST, start the timeout matching RESPONSE → result timeout expires → E_TIMEOUT
Figure 2. The client side has only two states per request. Follow the red path: a lost response never blocks the client for longer than the timeout allows.

Who does what in the Classic Platform

The SWC calls a ClientServerOperation (a function of a client-server interface, with its IN, INOUT and OUT arguments) through the RTE, as for any client-server call. For each call the RTE keeps a transaction handle (client ID and sequence counter, which become the Client ID and Session ID on the wire) and monitors the timeout. On the network side it allows only one open request per client and operation at a time, so a response can always be matched; the sequence counter also lets it recognise a stale response that arrives after a timeout.

The Client ID names the calling client inside its ECU. It can carry a fixed prefix so that it is unique in the whole vehicle.

Try it

Pick a story and step through it.

Things to notice. In "RESPONSE lost" the server did its work, yet the client reports E_TIMEOUT: the client cannot tell a lost request from a lost response. In "Late RESPONSE" the old response still arrives, but its Session ID no longer matches the open request, so it is ignored.

Check yourself optional

New terms in this lesson

TermMeaning
request/responseA method call with an answer: REQUEST from the client, RESPONSE (or ERROR) from the server
REQUEST, RESPONSEMessage Types of the call and of its answer
Request ID = Client ID + Session IDWho calls and which call; copied unchanged into the response
ClientServerOperationThe function an SWC calls through the RTE; on the network it becomes a method
transaction handleClient ID and sequence counter the RTE keeps per call to match the response
E_TIMEOUTNo response in time; in the RTE RTE_E_TIMEOUT

Source: SOME/IP Protocol Specification, R20-11, sections 4.1.2.5, 4.2.1.2, 4.2.2 and 4.2.6.4; RTE specification, R20-11, section 4.3.2 (timeout monitoring, response-to-request mapping).