SOME/IP in AUTOSAR Classic

SOME/IP

Who writes which header field

The SOME/IP header is written by two modules far apart in the stack: the SOME/IP transformer near the top and SoAd near the bottom. For segmented messages (SOME/IP TP) and for SOME/IP-SD messages, two more modules join in.

The split

The SOME/IP header fields coloured by their writer: Message ID and Length by SoAd; Request ID, Protocol Version, Interface Version, Message Type and Return Code by the SOME/IP transformer, or by Sd for SD messages. SOME/IP TP sets the TP flag in the Message Type and adds the SOME/IP TP header with Offset and More Segments flag. 1 · Message ID (Service ID + Method ID or Event ID) 2 · Length 3 · Request ID (Client ID + Session ID) 4 · ProtocolVersion 5 · InterfaceVersion 6 · Message Type+ TP flag: SOME/IP TP 7 · ReturnCode SOME/IP TP header, segments only: Offset · More Segments flag payload green: SoAd · purple: SOME/IP transformer (Sd for SD messages) · orange: SOME/IP TP
Figure 1. Two colours cover a normal message: green on top, purple below. The orange row exists only in the segments of a segmented message.

SoAd

Message ID and Length

Each PDU route in SoAd has a configured header ID (the 32-bit ID that SoAd writes in front of the PDU; for SOME/IP it is the Message ID). SoAd writes it and the Length in front of the PDU as its SoAd PDU header when sending, and uses it to pick the route when receiving.

SOME/IP transformer

Request ID to Return Code

Written during serialization. For a REQUEST and its RESPONSE, the Client ID and Session ID come from the RTE's transaction handle. For events and fire&forget calls the transformer counts the Session ID itself, or writes 0 if session handling is off. The Message Type and the Interface Version come from the transformer configuration of the signal.

SOME/IP TP

TP flag and SOME/IP TP header

Only for segmentation: SOME/IP TP sets the TP flag (a bit in the Message Type that marks a segment) and adds the SOME/IP TP header (where the segment starts, and whether more follow). On the receiving side it removes both after reassembling the message.

Sd

Its own messages

For SOME/IP-SD messages, Sd writes the header fields from the Request ID to the Return Code, and the content; SoAd adds the Message ID and the Length with the fixed header ID 0xFFFF8100 (Service ID 0xFFFF, Method ID 0x8100).

Why the split? It lets SoAd sort and route messages by header ID without knowing anything about SOME/IP data, and it keeps the ID configuration in one place, next to the socket connections. It also explains a gap noted in lesson 9: SoAd does not check versions and cannot answer an unknown Message ID; the transformer checks versions but never sees a message whose ID SoAd could not place.

Try it

Pick a kind of message, then click a header field to see who writes it and who checks it.

Click a header field.

Things to notice. The Message ID and the Length are always green, whatever the kind. The Request ID changes source with the kind: RTE values for a REQUEST, copied for a RESPONSE, the transformer's own Session ID counter for a NOTIFICATION. A segment keeps all header fields of the original message except the Length and the TP flag.

Check yourself optional

New terms in this lesson

TermMeaning
header IDThe 32-bit ID that SoAd writes in front of a PDU and routes by; for SOME/IP it is the Message ID

Source: SOME/IP Transformer, R20-11, sections 7.2.3 and 7.3; Socket Adaptor, R20-11, sections 4.1 and 7.3; SOME/IP TP, R20-11, section 7.2.2; Service Discovery, R20-11, section 7.2.4.