SOME/IP
The SOME/IP header
Every SOME/IP message starts with the same SOME/IP header. It says which service and which method or event the message is about, what kind of message it is, and which request it belongs to.
Seven fields in a fixed order
Whatever the message carries, the header has the same fields in the same places, so every receiver can read it. After the header comes the payload (the serialized data of the message).
32 bits
Message ID
The Message ID (what the message is about) is the Service ID plus the Method ID or Event ID. Together they name exactly one method or event in the whole vehicle.
32 bits
Length
The Length (the number of bytes that follow it) lets a receiver find the end of this message. Several messages can share one UDP datagram; each keeps its own header.
32 bits
Request ID
The Request ID (which request this message belongs to) is a Client ID (tells apart the clients on one ECU) plus a Session ID (a running counter). The server copies both into the response, so the client can match response to request.
8 bits each
Versions, type, result
A receiver checks the Protocol Version (the version of SOME/IP itself) and the Interface Version (the major version of the service interface) before trusting the data. The Message Type says what kind of message this is. The Return Code (the result) is only meaningful in responses and errors.
The Message Types
| Message Type | Sent by | Means |
|---|---|---|
REQUEST | client | A method call that expects a response, even when the response carries no data. |
REQUEST_NO_RETURN | client | A fire&forget method call: no response will come. |
NOTIFICATION | server | An event: a new value or something that happened. No response. |
RESPONSE | server | The result of a REQUEST. |
ERROR | server | A response that reports a failure instead of a result. |
Each Message Type has a twin with the TP flag set (a bit that marks one segment of a large message cut up by SOME/IP TP, lesson 23).
The Session ID
The Request ID has two halves. The Client ID names the client inside the calling ECU. The Session ID counts: every new request gets the next number, and after the highest number it starts again at 1, never at 0. This counting is called session handling (the Session ID goes 1, 2, … wrapping to 1). Notifications may count too, or may keep the Session ID at 0 when session handling is off for them.
Try it
Pick a Message Type and press "Send". Watch which header fields change. Send the same type twice to see the Session ID move.
| Header field | Value | Why |
|---|
Things to notice. A RESPONSE never makes up its own Request ID: it copies the one of its REQUEST. A NOTIFICATION from the server has no client, so the Client ID is 0. Only RESPONSE and ERROR can carry a real Return Code; every other type sends E_OK (0x00, no error). Message ID, Protocol Version and Interface Version stay the same for every message of one method or event.
Check yourself optional
New terms in this lesson
| Term | Meaning |
|---|---|
| Message ID | Service ID plus Method ID or Event ID: what the message is about |
| Length | Number of bytes that follow the Length field: rest of the header plus payload |
| Request ID | Client ID plus Session ID; a response copies it from its request |
| Client ID | Tells apart the clients of a method on one ECU |
| Session ID | Running counter of requests or notifications |
| session handling | Counting the Session ID up with every message, wrapping to 1; off means always 0 |
| Protocol Version | Version of the SOME/IP protocol, 0x01 |
| Interface Version | Major version of the service interface |
| Message Type | Kind of message: REQUEST, REQUEST_NO_RETURN, NOTIFICATION, RESPONSE, ERROR |
| Return Code | Result of a request: E_OK or an error code |
| payload | The serialized data after the header |
Source: SOME/IP Protocol Specification, R20-11, section 4.1.2 (header) and 4.2.1 (several messages in one UDP datagram).