SOME/IP is an automotive middleware solution that can be used for control messages. It was designed from the beginning to fit devices of different sizes and different operating systems perfectly.

SOME/IP provides service-oriented communication over a network. In service-oriented data transmission, a sender only sends data when at least one receiver in the network needs this data. The advantage of this procedure is that the network and all connected nodes are not loaded with unnecessary data

SOME/IP is based on service definitions that list the service's functionality.

SOME/IP supports a wide range of middleware features:

• Serialization.
• Remote Procedure Call (RPC).
• Service Discovery (SD).
• Publish/Subscribe (Pub/Sub).

The task of the SOME/IP TP module is to segment SOME/IP packets, which do not fit into one single UDP packet. On the reception side, it assembles the received SOME/IP segments.
The SOME/IP TP module interacts with the PDU-R for both directions, the transmission and the reception path.

Figure 2: Page 12 in AUTOSAR_SWS_SOMEIPTransportProtocol R20-11

The above picture shows the communication partners of SOME/IP component. From the SWCs point of view, we can send/receive communication signals over the Ethernet network. Those signals will be encapsulated in I-Pdu and an additional SOME/IP header (N-PDU).

When sending a signal, we will use an interface from RTE to access LdCOM to assign I-PDU to sent data. That I-PDU will be routed to PDU-R which will route it to the SOME/IP to encapsulate its header to I-PDUand return N-PDU that will be routed from PduR to SoAd and Ethernet network. Vice-versa for receive path.

The structure of header layout is as shown in the figure below.

Figure 3: Page 19 in AUTOSAR_PRS_SOMEIPProtocol F0 R20-11

• Message ID (4 Bytes): The Message ID shall be a 32 Bit identifier that is used to identify the RPC call to a method of an application or to identify an event. The Message ID shall be unique for the whole system (i.e. the vehicle).
  • Service ID: unique identifier for each service.
  • Method ID: 0-32767 for methods, 32768-65535 for events
• Length (4 Bytes): length of the payload in bytes shall contain the length in Byte starting from Request ID/Client ID until the end of the SOME/IP message (covers also the next IDs, which means 8 additional bytes).
• RequestID (4 Bytes): The Request ID allows a provider and subscriber to differentiate multiple parallel uses of the same method, event, getter or setter. The Request ID shall be unique for a provider- and subscriber-combination (i.e. one subscription) only. In AUTOSAR the Request ID shall be constructed of the Client ID and Session ID as shown: 
  • Client ID: is the unique identifier for the calling client inside the ECU. The Client ID allows an ECU to differentiate calls from multiple clients to the same method.
  • Session ID: is a unique identifier chosen by the subscribers for each call. The Session ID allows a subscriber to differentiate multiple calls to the same method. Request/Response methods shall use session handling with Session IDs. Session ID should be incremented after each call. When the Session ID reaches 0xFFFF, it shall wrap around and start again. A subscriber has to ignore a response if the session id of the response does not equal the session id of the request.
• Protocol Version (1 Byte): Protocol Version shall be an 8 Bit field containing the SOME/IP protocol version.
• Interface Version (1 Byte): Interface Version shall be an 8 Bit field that contains the Major Version of the Service Interface
• Message Type (1 Byte): The Message Type field is used to differentiate different types of messages and shall contain the following values as shown below.
  • Regular request (message type 0x00) shall be answered by a response (message type 0x80), when no error occurred. If errors occur an error message (message type 0x81) is sent.
  • It is also possible to send a request that does not have a response message (message type 0x01). For updating values through notification a callback interface exists (message type 0x02).
  • The 3rd highest bit of the Message Type (0x20) shall be called TP-Flag and shall be set to 1 to signal that the current SOME/IP message is a segment. Segments of the Message Type Request (0x00) have the Message Type (0x20), segments of the Message Type Response (0x80) have the Message Type (0xa0), and so on.

Figure 4: Page 23 in AUTOSAR_PRS_SOMEIPProtocol F0 R20-11

• Return Code (RetCode - 1 Byte): The Return Code shall be used to signal whether a request was successfully processed. For simplification of the header layout, every message transports the field Return Code.

Figure 5: Page 24 in AUTOSAR_PRS_SOMEIPProtocol F0 R20-11

PRS_SOMEIP_00191 is shown below:

Figure 6: Page 24 in AUTOSAR_PRS_SOMEIPProtocol F0 R20-11

The AUTOSAR Service Discovery (SD) module offers functionality to detect and offer available services i.e. functional entities – within the vehicle network. To do so, it makes use of the IP Multicast and so-called SOME/IP-SD messages.

The main tasks of the SD Module are managing the availability of functional entities called services in the in-vehicle communication as well as controlling the sending behavior of event messages. This allows sending only event messages to receivers requiring them (Publish/Subscribe). The solution described here is also known as SOME/IP-SD.

Figure 7: Page 85 in AUTOSAR_TR_SomeIpExample_4.2.1

A local ECU needs to deal with two different kinds of services:

• Server Services – The local ECU offers Server Service Instances (i.e. located locally) to the rest of the vehicle and can be considered the server for this Service Instance.
• Client Services – The local ECU may use Server Service Instances offered by another ECU inside the vehicle and can be considered a client to this Service Instance.

For Server Services, the local ECUs SD module has to (server role):

• Offer the local service, when it is available; i.e. the SWC(s) offering the service are ready and the service is available in the current state of the ECU.
• Take back the offer of the local service (stop offer), when the service is no longer available.
• Answer and respond to finds of other ECUs.

For Client Services, the local ECUs SD module has to (client role):

• Listen for offers and finds depending on the configuration then store this information in volatile memory.
• Listen for stop offers and depending on the configuration store this information in volatile memory.
• Send finds depending on the state of the current ECU and its SWCs.

Figure 8: Page 8 in AUTOSAR_SWS_ServiceDiscovery

SOME/IP-SD uses services and these services are managed by BswM. When we start our system we should activate configured services for SD from BswM and after that communication will be handled from the SD component and its neighbors Pdu-R, SoAd, BswM and Ethernet network.

Figure 9: Page 7 in SDV-8201 - Service Discovery Extension Specification_27.27.171.r3

The big picture above shows SOME/IP-SD module in the AUTOSAR Architecture where it interacts with other BSW modules.

Figure 10: Page 7 in AUTOSAR_TR_SomeIpExample_4.2.1

For the control path, the SOME/IP-SD includes the SOME/IP headers without the Message-ID and Length field itself.

The following diagram depicts an example exchange of messages among a Client - Server entity using the SOME/IP-SD protocol.

In particular:

1. Client sends a FindService message requesting for a Service instance in multicast.
2. Server receives the multicasted FindService message and replies with a correspondent OfferService message to this particular instance.
   1. The message contains the service address and port for enabling unicast communication with the Client.
3. After the Client receives the OfferService message, the following routing groups specified in the Sd configuration are enabled with an open socket connection to the unicast address specified in the OfferService message:
   1. SdClientServiceActivationRef: for performing Remote Procedure Calls (ConsumedMethod)
   2. SdConsumedEventGroupUdpActivationRef: for receiving server Events (ConsumedEventGroup)
4. Client performs a Remote Procedure Call on the Server ProvidedMethod (using unicast, on the socket connection opened at 3.). The RPC could be fire & forget, or it could have a return value.
5. Client requests the subscription to a specific Eventgroup with the SubscribeEventgroup message.
6. Server acknowledges the subscription with the SubscribeEventgroup message.
7. Server sends an Event to the subscribed Client (could be in unicast or multicast depending on the configuration).

Figure 11: Page 19 in AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol F0 R20-11

The SOME/IP-SD Header Format shall follow:

• Message ID (Service ID/Method ID) [32-bit]: 0xFFFF 8100
  • The Service ID [16-bit]: shall be always set to 0xFFFF on service Discovery messages.
  • The EventID/MethodID [16 bit]: shall be always set to 0x8100 on service Discovery messages.
• Request ID [32-bit]:
  • The Client ID [32 bit]: shall be set statically to 0x0000.
  • The first SD message sent out to the multicast address has Session ID 0x0001, as well as the first SD message, sent out to any unicast communication partner has the Session ID 0x0001 as well.
• The value for the Protocol Version [8 bit] field shall be statically set to 0x01.
• The value for the Interface Version [8 bit] field shall be statically set to 0x01.
• The value for the Message Type [8-bit] field shall be statically set to 0x02.
• The Return Code field shall be statically set to 0x00.
• With the Flags [8-bit] field the SOME/IP-SD header starts. It is used to signal global Service Discovery information, which includes currently the state of the last reboot as well as the capability of receiving unicast messages. The Reboot Flag shall be set to ‘1’ for all messages after reboot until the Session ID of the Request ID field wraps and thus starts with 0x0001 again. After that the Reboot Flag shall be set to ‘0’.
  • bit 0: Reboot Flag
  • bit 1: Unicast Flag
  • bit 2: Explicit Initial Data Control Flag
  • bit 3: Reserved
  • bit 4: Reserved
  • bit 5: Reserved
  • bit 6: Reserved
  • bit 7: Reserved

• Length of Entries Array [32-bit]: The first field of the Entries Array shall carry the number of bytes of the Entries Array (excluding this 32-bit field carrying the length information).

• Entries Array Type 1

   Entries Array Type 1 - Service

  

  • The Type field of the Type 1 Entry format layout shall carry one of the following values
    • 0x00 to encode FindService
    • 0x01 to encode OfferService and StopOfferService
  • The “Index First Option Run” field of the Type 1 Entry format layout shall carry the index of the first option of the first option run of this entry in the option array.
  • The “Index Second Option Run” field of the Type 1 Entry format layout shall carry the index of the first option of the second option run of this entry in the option array.
  • The “Number of Option 1” of the Type 1 Entry format layout shall carry the number of options the first option run uses.
  • The “Number of Option 2” field of the Type 1 Entry format layout shall carry the number of options the second option run uses.
  • The Service ID field of the Type 1 Entry format layout shall carry the Service ID of the service (to Find, Offer or Stop Offering).
  • The Instance ID field of the Type 1 Entry format layout shall carry the Instance ID of the service (to Find, Offer or Stop Offering).
    • If not a single but all instances are addressed, the Instance ID field of the Type 1 Entry format layout shall be set to 0xFFFF.
  • The Major Version field of the Type 1 Entry format layout shall carry the Major version of the service.
  • The TTL field of the Type 1 Entry format layout defines the lifetime of the entry in seconds, except for Stop-Entries, which have a TTL of 0.
  • The Minor Version field of the Type 1 Entry format layout shall carry the Minor version of the service

• Entries Array Type 2

   Entries Array Type 2 - Eventgroups

  

  • The Type field of the Type 2 Entry format layout shall carry one of the following values, depending on the purpose of the message sent:
    • 0x06 to encode SubscribeEventgroup and StopSubscribeEventgroup
    • 0x07 to encode SubscribeEventgroupAck and SubscribeEventgroupNack
  • The “Index Second Option Run” field of the Type 2 Entry format layout shall carry the index of the first option of the second option run of this entry in the option array.
  • The “Number of Option 1” field of the Type 2 Entry format layout shall carry the number of options the first option run uses.
  • The “Number of Option 2” field of the Type 2 Entry format layout shall carry the number of options the second option run uses.
  • The Service ID field of the Type 2 Entry format layout shall carry the Service ID of the eventgroups service.
  • The Instance ID field of the Type 2 Entry format layout shall carry the Instance ID of the eventgroups service.
  • The Major Version field of the Type 2 Entry format layout shall carry the Sd Server Service Major Version.
  • The TTL field of the Type 2 Entry format layout defines the lifetime of the entry in seconds, except for Stop- or Nack-Entries, which use a TTL of 0.
  • The Reserved field, which follows the TTL field of the Type 2 Entry format layout, shall be statically set to 0x000.
  • The Counter field, which follows the Reserved filed of the Type 2 Entry format layout, is used to differentiate identical Type 2 Entries (e.g. multiple subscriptions to same Eventgroup).
• The Option array is the last part of the Service Discovery Message. The options in the options array carry additional information.

More detail please reference to AUTOSAR specification and CUBAS training slide mentioned above links.

• In System Description:

• In BSW Configuration (done by Confgen), which takes from System Description above.

From the sample project to see SdTxPduRef/SdRxPduRef:

• In System Description:

• In BSW Configuration (done by Confgen), which takes from System Description above.

From sample project:

Similar if you see the configuration for handing actual Methods/Events(via SdClientService) in Sd container.