SOME/IP in AUTOSAR Classic

SOME/IP

Reception: from the wire to the SWC

On the way up, each module removes its own header, sorts the content by one more key, and drops what it cannot place. Follow the event BrakeEvent arriving at the brake ECU.

A series of checks

Checks from bottom to top: EthIf checks the frame type and VLAN tag and hands the frame to its frame owner; TcpIp checks the own IP address and UDP port; SoAd picks the socket connection and applies the message acceptance filter, finds the socket route by the header ID, and checks that its routing group is enabled; COM or LdCom stores the data and notifies the RTE; the SOME/IP transformer checks versions and Message Type and deserializes the payload. A failing check drops the message to the side; passing all checks delivers the value to the SWC. SWC gets the value versions, Message Type, payload OK? COM / LdCom: store, notify the RTE routing group of the socket route enabled? header ID (Message ID) → socket route? socket connection? sender accepted? own IP address? UDP port → socket frame type IPv4? VLAN tag? to another frame owner, or dropped dropped silently message acceptance filter:not accepted, dropped dropped, runtime error reported routing group disabled: dropped not delivered; the SWC gets thetransformer error, nothing sent back EthIf TcpIp SoAd SOME/IP transformer
Figure 1. Read from the bottom. Each check uses one more key: frame type, IP address and port, sender, header ID, routing group, SOME/IP header. A message that fails a check leaves to the right and never reaches the SWC.

EthIf hands each received frame to its frame owner (the upper module registered for the frame type, here TcpIp for IPv4). SoAd picks the socket connection that best matches the sender's address and port, and its message acceptance filter (a check that the sender is a remote address this socket connection allows) drops messages from anyone else. It then reads the header ID (the first 32 bits of the SoAd PDU header, for SOME/IP the Message ID) and finds the socket route (the way of a received message from a socket connection up to a module). From module to module the data goes up by an RxIndication (the callback that tells the module above that a PDU has been received).

The routing group check is where Sd shows its power. A routing group works like a switch for a set of routes in SoAd, and Sd turns it on and off: the socket route for BrakeEvent is only enabled after the SubscribeEventgroupAck arrived. Until then, even a correctly addressed event is dropped.

One datagram, several messages

A single UDP datagram may carry several SOME/IP messages back to back. SoAd reads the length in each SoAd PDU header (for SOME/IP the Length field) to find where one message ends and the next begins, and passes each one up separately. If the rest of the datagram is shorter than a PDU header or than the length it gives, SoAd stops and ignores the rest. A stricter setting makes SoAd drop the whole datagram when the lengths do not add up exactly.

Try it

Step up through the stack and watch the headers come off.

The message at this point

Things to notice. The receiving SoAd removes the SoAd PDU header (Message ID and Length) and passes on only the rest; inside the ECU the Message ID survives only as the PDU ID of the I-PDU. The SOME/IP transformer is the first module that looks at versions; every module below sorts only by addresses and IDs.

Check yourself optional

New terms in this lesson

TermMeaning
frame ownerThe upper module EthIf hands a received frame to, chosen by the frame type (TcpIp for IPv4)
message acceptance filterSoAd check on reception: only messages from the remote address the socket connection allows are accepted
routing groupA set of routes in SoAd that is enabled or disabled as a whole; Sd controls it
RxIndicationCallback to the module above: a PDU has been received, here is its data

Source: R20-11 specifications of Ethernet Interface (frame owner), TCP/IP (7.6), Socket Adaptor (7.4–7.6, 7.9), RTE (4.10) and SOME/IP Protocol (4.2.1, several messages per datagram).