SOME/IP-SD Special Issue of Automotive Ethernet

foreword

First of all, I would like to ask you a few small questions, you know:

• Do you know what SOME/IP SD is?
• How are SOME/IP-SD packets sent and received?
• What Entry Types exist in SOME/IP-SD?
• What about SOME/IP-SD internal state machine transitions?

Today, let's explore and answer these questions together. For ease of understanding, here is an outline of the topic of this article:

---

text

Through the previous article <SOME/IP>, we learned about the basic composition of SOME/IP protocol and the specific working process of SOME/IP, and also mentioned the important role SOME/IP-SD plays in SOME/IP protocol: Discovery Services and Subscription Services .

In view of the importance of SOME/IP-SD, this article will focus on explaining the specific definitions of several types of Entry Types of SOME/IP-SD, the sending and receiving process of SD messages, and the state machine analysis of SD, so that everyone can understand SOME/IP-SD. The IP-SD protocol has a clearer understanding and understanding.

SD Entry TypeSummary

Service Entries General Requirements

The Type ID used by the Service Entry is 0x00, 0x01, and the format of the Entry message used is Format Type 1. The Service Entries include FindService, OfferService, and StopOfferService.

As shown in Figure 1 below, the general requirements of Serve Entries are shown, which are the common requirements for FindService, OfferService, and StopOfferService to be described next.

Figure 1 Commonality of Service Entries

Find Service Entry settings

Figure 2 below shows the configuration considerations for each Field of FindService Entry:

Figure 2 FindService Entry configuration

OfferService Entry settings

Figure 3 below shows the configuration considerations for each Field of OfferService Entry:

Figure 3 OfferService Entry configuration

StopOfferService setting

In order to notify the Offer Service, the StopOfferService Entry must be used, as shown in Figure 4 below for the StopOfferService configuration:

Figure 4 StopOfferService Entry configuration

---

EventGroup Entries general requirements

EventGroup Entries currently only use Type ID 0x06, 0x07, and the EventGroup Entry used is Type 2. At the same time, EventGroup Entries include SubscribeEventgroup, StopSubscribeEventgroup, SubscribeEventgroupAck and SubscribeEventgroupNack.

As shown in Figure 5 below, the general requirements of EventGroup Entries are shown, which are the common requirements for FindService, OfferService, and StopOfferService to be described next.

Figure 5 General requirements for EventGroup Entry

SubscribeEventgroup settings

Figure 6 below shows the configuration considerations for SubscribeEventGroup:

Figure 6 SubscribeEventGroup configuration

StopSubscribeEventgroup setting

If you need to stop subscribing to the EventGroup, you need to call the Entry of StopSubscribeEventGroup to stop.

Figure 7 below shows the configuration considerations for StopSubscribeEventGroup:

Figure 7 StopSubscribeEventGroup configuration

SubscribeEventgroupAck settings

When the Client subscribes to the relevant event group through the SubscribeEventgroup Entry, if the Server confirms that the subscription conditions are met, it will reply a positive response through the SubscribeEventGroupAck, indicating that the subscription is successfully accepted, and the Client's subscription is successful.

Figure 8 below shows the configuration considerations for SubscribeEventGroupAck:

Figure 8 SubscribeEventGroupAck configuration

SubscribeEventgroupNack settings

In the following situations, the SubscribeEventGroup requested by the Client will not receive a positive response, but will reply to SubscribeEventGroupNack:

• The combination of Service ID, Instance ID, and EventGroup ID is unknown;
• The required TCP connection is not initiated by the client;
• The problem of excessive resource usage on the server side;
• The referenced Option Entries are wrong, missing, or contradicting each other;

Figure 9 below shows the configuration considerations for SubscribeEventGroupNack:

Figure 9 SubscribeEventGroupAck configuration

SD Message

Knowing the precautions for setting all SD Entry Types above means that you need to know how to send these packaged SD messages and how to receive and parse these SD messages. Next, let's learn about SD Message sending and receiving process.

Tx Path

As mentioned in the previous SOME/IP related articles, whether the SD module is sending or receiving, it needs to deal with a very important Ethernet upper abstraction module SoAd. Naturally, the process of sending and receiving messages will involve two The function calling relationship between modules, the specific sending process is as follows:

• S1: The SD message has been successfully packaged according to the SD message format;
• S2: If it is unicast, set the target address by calling SoAd_SetRemoteAddr; if it is multicast, you need to first obtain the local address by calling the function SoAd_GetLocalAddr, and then set the target address by the SoAd_SetRemoteAddr function;
• S3: Finally, send the SD message to the bus by calling SoAd_IfTransmit;

Figure 10 below is the sending sequence diagram of SD message, which is convenient for everyone to have an intuitive understanding and understanding of all aspects of SD message sending.

Figure 10 SD message sending timing diagram

Rx Path

In the same way, the reception of SD messages also needs to go through the following basic steps before the data can be obtained to the SD module and processed correctly.

• S1: When the SoAd module receives the SD message from the bus, it will call the SD module's callback function Sd_RxIndication to notify the SD module to process the data;
• S2: The corresponding SoConId can be obtained for the SD instance object through the received RxPduId;
• S3: Obtain the address of the remote server by calling the function SoAd_GetRemoteAddr and combining the above SoConId;
• S4: store the message and address information for further processing;
• S5: Finally, the function SoAd_ReleaseRemoteAddr() is called to reset the SoConID for the next use, and the received Entry will be processed in the order received;

Figure 11 below is the receiving sequence diagram of SD message, which is convenient for everyone to have an intuitive understanding and understanding of each link of SD message receiving.

Figure 11 Sequence diagram of receiving SD message

If the receiving link is received in multicast mode, then AUTOSAR stipulates that in order to prevent the sudden increase of the bus load caused by each receiving node sending Response to the bus at almost the same time, a delay mechanism is used to prevent the phenomenon from occurring:

• For ServerServices, the moment when FindService replies to OfferService can be controlled by the parameters SdServerTimerRequestResponseMinDelay and SdServerTimerRequestResponseMaxDelay;
• For ConsumedEventGroup, that is, the moment when the OfferService replies to SubscribeEventGroup can be controlled by SdClientTimerRequestResponseMinDelay and SdClientTimerRequestResponseMaxDelay;

State Machine Analysis

The SD state machine can be divided into two types: the server state machine and the client state machine. Each state machine can be divided into two states: Down State and Available State. The Available State can be further subdivided into Initial Wait Phase, Repetition Phase, Main Phase.

Server SD State Machine

First, let's look at the transition process of the four state machines on the server side. Figure 12 below is the overall review of the communication phase on the server side:

Figure 12 Overall Review of the Communication Phase on the Server Side

As shown in Figure 13 below, I summarize the transition relationship of each state machine of SD on the server side and several conditions between transitions. Among them, the relationship between condition 1 and condition 2 is "or", not "and", which occurs in each phase. The behavior is reflected in the Action below.

Figure 13 Server SD state machine transition diagram

Client SD state machine

First, let's take a look at the conversion process of the four state machines on the client side. Figure 14 below shows the overall review of the communication phase on the client side:

Figure 14 Overall Review of the Communication Phase of the Client

As shown in Figure 13 below, I summarize the transition relationship of each state machine of the client side SD and several conditions between the transitions. Among them, Condition 1, Condition 2, and Condition 3 are "or" relationships, not "and" relationships. Each Phase The behavior that occurs in the stage is reflected in the Action below.

Figure 14 Client SD state machine transition diagram

Overall review of the communication phase on the client side

As shown in Figure 13 below, I summarize the transition relationship of each state machine of the client side SD and several conditions between the transitions. Among them, Condition 1, Condition 2, and Condition 3 are "or" relationships, not "and" relationships. Each Phase The behavior that occurs in the stage is reflected in the Action below.

[External link image dumping...(img-esK7rDdV-1647873040828)]

Figure 14 Client SD state machine transition diagram

---

For more exciting content, please pay attention to the following public account " My View of ADAS and ECU "!