前言

首先，請問大家幾個小小問題，你清楚：

你知道什么是SOME/IP SD嗎？

SOME/IP-SD報文是如何發送與接收的呢？

SOME/IP-SD 存在哪幾種Entry Type呢？

SOME/IP-SD內部狀態機轉換又是如何？

今天，我們就來一起探索并回答這些問題。為了便于大家理解，以下是本文的主題大綱：

正文

通過之前的文章我們了解到了SOME/IP協議的基本組成與SOME/IP的具體工作過程，同時也提到了SOME/IP-SD在SOME/IP協議中所扮演的重要角色：發現服務與訂閱服務。鑒于SOME/IP-SD的重要性，本文將著重講解下SOME/IP-SD的幾類Entry Type的具體定義說明，SD報文的發送與接收流程，SD的狀態機解析，讓大家對SOME/IP-SD協議有個更為清晰的了解與認識。

SD Entry Type總結

Service Entries 通用需求

Service Entry使用的Type ID為0x00，0x01，使用的Entry報文格式為Format Type 1，其中Service Entries包含FindService，OfferService，StopOfferService三種。

如下圖1所示展示了Serve Entries的通用需求，該需求是針對接下來要講述的FindService，OfferService，StopOfferService的共性需求。

圖1 Service Entries共性

Find Service Entry設置

如下圖2所示為FindService Entry的各個Filed配置注意事項：

圖2 FindService Entry 配置

OfferService Entry設置

如下圖3所示為OfferService Entry的各個Filed配置注意事項：

圖3 OfferService Entry 配置

StopOfferService設置

為了通知Offer Service，必須使用StopOfferService Entry 必須使用，如下圖4為StopOfferService配置：

圖4 StopOfferService Entry 配置

EventGroup Entries通用需求

EventGroup Entries 目前僅用到Type ID為0x06， 0x07，使用的EventGroup Entry為Type 2。同時EventGroup Entries 包含SubscribeEventgroup，StopSubscribeEventgroup，SubscribeEventgroupAck以及SubscribeEventgroupNack四種。

如下圖5所示展示了EventGroup Entries的通用需求，該需求是針對接下來要講述的FindService，OfferService，StopOfferService的共性需求。

圖5 EventGroup Entry通用需求

SubscribeEventgroup設置

如下圖6為SubscribeEventGroup的配置注意事項：

圖6 SubscribeEventGroup配置

StopSubscribeEventgroup設置

如果需要停止訂閱EventGroup，那么就需要調用StopSubscribeEventGroup的Entry來停止。

如下圖7為StopSubscribeEventGroup的配置注意事項：

圖7 StopSubscribeEventGroup配置

SubscribeEventgroupAck設置

當Client 通過SubcribeEventgroup Entry來訂閱相關事件組時，如果Server確認滿足訂閱條件，那么就會通過SubcribeEventGroupAck來回復正響應，表示成功接受該訂閱，Client此次訂閱成功。

如下圖8為SubcribeEventGroupAck的配置注意事項：

圖8 SubscribeEventGroupAck配置

SubscribeEventgroupNack設置

當處在以下幾種情況下時，Client請求的SubcribeEventGroup將得不到正響應，而是會回復SubcribeEventGroupNack：

Service ID，Instance ID，EventGroup ID的組合未知；

需要的Tcp連接并沒有被客戶端發起；

Server端的資源使用過度問題；

參考的Option Entries存在錯誤，丟失，或者互相矛盾的點；

如下圖9為SubcribeEventGroupNack的配置注意事項：

圖9 SubscribeEventGroupAck配置

SD Message

了解了上述SD所有Entry Type的設置注意事項，那么也就意味著接下來就要知道如何將這些打包的SD報文發送出去以及如何接收并解析這些SD報文，接下來我們就來了解下SD Message 的發送與接收流程。

Tx Path

正如之前的SOME/IP相關文章所述，SD模塊無論是發送還是接收，都需要與一個十分重要的以太網上層抽象模塊SoAd打交道，自然其發送與接收報文的過程也就會涉及到兩個模塊間的函數調用關系，具體的發送流程如下：

S1：SD報文已按照SD報文格式組包成功；

S2：如果是單播，則通過調用SoAd_SetRemoteAddr設置目標地址；如果是多播，則需要先通過通過調用函數SoAd_GetLocalAddr獲得本地地址，然后通過SoAd_SetRemoteAddr函數設置目標地址；

S3：最后通過調用SoAd_IfTransmit將SD報文發送至總線上；

如下圖10為SD Message的發送時序圖，便于大家對SD的報文發送的各個環節有個直觀的認識與理解。

圖10 SD報文發送時序圖

Rx Path

同理，對于SD報文的接收也需要經歷以下幾個基本環節才能夠獲取到數據至SD模塊并得到正確處理。

S1：當SoAd模塊接收到來自總線的SD報文時，就會調用SD模塊的回調函數Sd_RxIndication來通知SD模塊來處理數據；

S2：通過接收到的RxPduId便可以為SD實例對象獲取對應的SoConId；

S3：通過調用函數SoAd_GetRemoteAddr并結合上述的SoConId來獲取遠程Server的地址；

S4：存儲報文與地址信息以便下一步處理；

S5：最后調用函數SoAd_ReleaseRemoteAddr（）來重置SoConID以便下一次使用，同時接收到的Entry均會按照接收到的順序依次進行處理；

如下圖11為SD Message的接收時序圖，便于大家對SD的報文接收的各個環節有個直觀的認識與理解。

圖11 SD報文接收時序圖

對于接收環節如果是采用多播模式接收時，那么AUTOSAR規定為了防止由于各個接收節點幾乎同時的發送Response至總線所引起的總線負載突然猛增，因此通過一種延遲機制來防止現象的出現：

對于ServerServices，即接收到FindService回復OfferService的時刻可以通過SdServerTimerRequestResponseMinDelay與SdServerTimerRequestResponseMaxDelay參數來控制；

對于ConsumedEventGroup，即接收到OfferService回復SubcribeEventGroup的時刻可通過SdClientTimerRequestResponseMinDelay與SdClientTimerRequestResponseMaxDelay來控制；

SD狀態機解析

SD狀態機可分為兩種：Server端狀態機與Client狀態機，每種狀態機均可以分為兩種狀態：Down State與Available State。其中Available State可再進一步細分為Initial Wait Phase， Repetition Phase， Main Phase。

Server SD狀態機

首先我們來看下Server端的四種狀態機的轉換過程，如下圖12為Server端的通信階段總體review：

圖12 Server端的通信階段總體Review

如下圖13我總結了Server端SD各個狀態機的轉換關系以及轉換之間的若干條件，其中條件1與條件2為“或”的關系，并不是”與“的關系，每個Phase階段中發生的行為均體現在Action下面。

圖13 Server SD狀態機轉換圖

Client SD狀態機

首先我們來看下Client端的四種狀態機的轉換過程，如下圖14為Client端的通信階段總體review：

圖14 Client端的通信階段總體Review

如下圖13我總結了Client端SD各個狀態機的轉換關系以及轉換之間的若干條件，其中條件1，條件2，條件3為“或”的關系，并不是”與“的關系，每個Phase階段中發生的行為均體現在Action下面。

圖14 Client SD狀態機轉換圖

審核編輯：郭婷