Abbreviations
Term | Definition |
---|
SOME/IP | Scalable service-Oriented MiddlewarE over IP |
SOME/IP-SD | SOME/IP Service Discovery |
N-PDU | Network Layer Protocol Data Unit which is used by transport protocol modules to fragment an I-PDU |
I-PDU | Interaction Layer Protocol Data Unit which is used for the data exchange of the modules directly above the PDU Router, e.g. AUTOSAR COM and AUTOSAR DCM. |
SrvcMgr | Services Manager |
SoAd | Socket Adaptor |
Sd | Service Discovery Module in AUTOSAR |
SD | Service Discovery |
RPC | Remote Procedure Call |
LdCOM | Large Data COM |
Scope
In this part, we will investigate the functionalities of SOME/IP-SD and how it works. From that know how to integrate and configure them in a project as well.
From the SUM's point of view, ideally, we can identify the parts of SOME/IP-SD needed for SUM SrvcMgr development in the future.
First of all, from the AUTOSAR big picture, we know that SOME/IP and SD are two different components. However, they collaborate with each other across various other components like RTE, LdCom, SoAd, BswM, PduR,.., and we should take care of their relationship in the configuration needed.
In general, SOME/IP-SD depends on SOME/IP. SOME/IP itself supports both TCP and UDP communications but SOME/IP SD is constraint to use SOME/IP only over UDP
Figure 1: Page 7 in AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol R20-11
1. SOME/IP Protocol Overview
Protocol Introduction
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).
SOME/IP TP module overview and BSW modules dependency
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.
Header format of Original SOME/IP message
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
2. SOME/IP-SD Module Overview
Module Introduction
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.
BSW modules dependency
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.
Client-Server communication example
The following diagram depicts an example exchange of messages among a Client - Server entity using the SOME/IP-SD protocol.
In particular:
- Client sends a FindService message requesting for a Service instance in multicast.
- Server receives the multicasted FindService message and replies with a correspondent OfferService message to this particular instance.
- The message contains the service address and port for enabling unicast communication with the Client.
- 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:
- SdClientServiceActivationRef: for performing Remote Procedure Calls (ConsumedMethod)
- SdConsumedEventGroupUdpActivationRef: for receiving server Events (ConsumedEventGroup)
- 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.
- Client requests the subscription to a specific Eventgroup with the SubscribeEventgroup message.
- Server acknowledges the subscription with the SubscribeEventgroup message.
- Server sends an Event to the subscribed Client (could be in unicast or multicast depending on the configuration).
Message Structure
Figure 11: Page 19 in AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol F0 R20-11
The SOME/IP-SD Header Format shall follow:
More detail please reference to AUTOSAR specification and CUBAS training slide mentioned above links.
BSWM State Handling for SD Services
4. Hint for integration in RTA-CAR
The Sd and SoAd should be configured, some hints as below:
1. In SoAd, create different RoutingGroups and PDURoute/SocketRoute for handling Sd (control) messages and actual Methods/Events.
Sample Project Configuration
- In BSW Configuration (done by Confgen), which takes from System Description above.
- In SoAd, create different SoAdSocketConnectionGroup for handling Sd (control) messages (via SdTxPduRef/SdRxPduRef) and actual Methods/Events(via SdClientService).
Sample Project Configuration
From the sample project to see SdTxPduRef/SdRxPduRef:
- In BSW Configuration (done by Confgen), which takes from System Description above.
- In Sd, configure PDU reference for receiving/transmitting SD messages.
Sample Project Configuration
From sample project:
Similar if you see the configuration for handing actual Methods/Events(via SdClientService) in Sd container.
- The SoAdHeaderId should be enabled, and the header IDs of Sd control messages should be set to the value of 0xFFFF 8100
5. Need for SUMs development
SrvcMgr
For applications to control the Service Discovery behavior in any arbitrary time, the BswM needs to be configured to control the Service Discovery behavior for every service.
The BswM provides the capabilities to:
- Offer/Stop Offer a service.
- Request/ Release a service.
- Subscribe to Service events.
- Query the status of the subscription at the server and client.
- Query the status of the service availability.
SUM SrvcMgr provides a central location for managing the service offering and subscriptions at any point in time by automating the BswM configuration/interaction and abstracting the application SWCs that provide or consume the services from managing the service discovery aspect of the services and only handle the service data transmission and reception.
Related to the SD, SUM SrvcMgr shall implement for:
- Supporting of persisting learning table: Use of SD extension APIs for triggering a learning session and retrieve learning session status.
- Supporting of Calibration Capabilities: Provide the possibility of calibrated off some services before or after a learning session. Interaction with SD extension APIs and BswM
- Service Management: Change the status of services provided/consumed by the ECU at runtime according with project specific conditions. Interaction with SD standard APIs and BswM.
SSFM
- Loss of Function: SSFM will monitor the active services and detect their availability. SSFM will retrieve the IPaddress of the node associated to the service not available by using SD module and set the DTC accordingly.
- Invalid Data Handling DTC: DTC setting of Invalid Data while dealing with services on Ethernet. SSFM will retrieve the IPaddress of the node associated by using SD module and set the DTC accordingly.
- Handling of “Unable to Authenticate Serial Data Message” DTC: Set the DTC according with the MAC verification failure for SOME/IP traffic. SSFM will receive the notification about the MAC verification failure from SSC together with the IP address of the node associated to the MAC verification failure. SSFM will set the DTC.
SSC
- Handling of “Unable to Authenticate Serial Data Message” DTC: SSC will create a mapping between KeySlot and IP address of the node associated to such key slot. The IP address will be retrieved by using the SD module. In case of MAC verification failure, SSC will notify SSFM through a port/interface passing also the IP associated.