前言

首先，請問大家?guī)讉€小小問題，你清楚：

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

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

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

SOME/IP-SD內(nèi)部狀態(tài)機轉(zhuǎn)換又是如何？

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

正文

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

SD Entry Type總結(jié)

Service Entries 通用需求

Service Entry使用的Type ID為0x00，0x01，使用的Entry報文格式為Format Type 1，其中Service Entries包含F(xiàn)indService，OfferService，StopOfferService三種。

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

圖1 Service Entries共性

Find Service Entry設(shè)置

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

圖2 FindService Entry 配置

OfferService Entry設(shè)置

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

圖3 OfferService Entry 配置

StopOfferService設(shè)置

為了通知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設(shè)置

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

圖6 SubscribeEventGroup配置

StopSubscribeEventgroup設(shè)置

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

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

圖7 StopSubscribeEventGroup配置

SubscribeEventgroupAck設(shè)置

當(dāng)Client 通過SubcribeEventgroup Entry來訂閱相關(guān)事件組時，如果Server確認(rèn)滿足訂閱條件，那么就會通過SubcribeEventGroupAck來回復(fù)正響應(yīng)，表示成功接受該訂閱，Client此次訂閱成功。

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

圖8 SubscribeEventGroupAck配置

SubscribeEventgroupNack設(shè)置

當(dāng)處在以下幾種情況下時，Client請求的SubcribeEventGroup將得不到正響應(yīng)，而是會回復(fù)SubcribeEventGroupNack：

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

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

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

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

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

圖9 SubscribeEventGroupAck配置

SD Message

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

Tx Path

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

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

S2：如果是單播，則通過調(diào)用SoAd_SetRemoteAddr設(shè)置目標(biāo)地址；如果是多播，則需要先通過通過調(diào)用函數(shù)SoAd_GetLocalAddr獲得本地地址，然后通過SoAd_SetRemoteAddr函數(shù)設(shè)置目標(biāo)地址；

S3：最后通過調(diào)用SoAd_IfTransmit將SD報文發(fā)送至總線上；

如下圖10為SD Message的發(fā)送時序圖，便于大家對SD的報文發(fā)送的各個環(huán)節(jié)有個直觀的認(rèn)識與理解。

圖10 SD報文發(fā)送時序圖

Rx Path

同理，對于SD報文的接收也需要經(jīng)歷以下幾個基本環(huán)節(jié)才能夠獲取到數(shù)據(jù)至SD模塊并得到正確處理。

S1：當(dāng)SoAd模塊接收到來自總線的SD報文時，就會調(diào)用SD模塊的回調(diào)函數(shù)Sd_RxIndication來通知SD模塊來處理數(shù)據(jù)；

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

S3：通過調(diào)用函數(shù)SoAd_GetRemoteAddr并結(jié)合上述的SoConId來獲取遠(yuǎn)程Server的地址；

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

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

如下圖11為SD Message的接收時序圖，便于大家對SD的報文接收的各個環(huán)節(jié)有個直觀的認(rèn)識與理解。

圖11 SD報文接收時序圖

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

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

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

SD狀態(tài)機解析

SD狀態(tài)機可分為兩種：Server端狀態(tài)機與Client狀態(tài)機，每種狀態(tài)機均可以分為兩種狀態(tài)：Down State與Available State。其中Available State可再進(jìn)一步細(xì)分為Initial Wait Phase， Repetition Phase， Main Phase。

Server SD狀態(tài)機

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

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

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

圖13 Server SD狀態(tài)機轉(zhuǎn)換圖

Client SD狀態(tài)機

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

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

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

圖14 Client SD狀態(tài)機轉(zhuǎn)換圖

審核編輯：郭婷