前言

首先，請(qǐng)問大家?guī)讉€(gè)小小問題，你清楚：

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

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

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

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

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

正文

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

SD Entry Type總結(jié)

Service Entries 通用需求

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

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

圖1 Service Entries共性

Find Service Entry設(shè)置

如下圖2所示為FindService Entry的各個(gè)Filed配置注意事項(xiàng)：

圖2 FindService Entry 配置

OfferService Entry設(shè)置

如下圖3所示為OfferService Entry的各個(gè)Filed配置注意事項(xiàng)：

圖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。同時(shí)EventGroup Entries 包含SubscribeEventgroup，StopSubscribeEventgroup，SubscribeEventgroupAck以及SubscribeEventgroupNack四種。

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

圖5 EventGroup Entry通用需求

SubscribeEventgroup設(shè)置

如下圖6為SubscribeEventGroup的配置注意事項(xiàng)：

圖6 SubscribeEventGroup配置

StopSubscribeEventgroup設(shè)置

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

如下圖7為StopSubscribeEventGroup的配置注意事項(xiàng)：

圖7 StopSubscribeEventGroup配置

SubscribeEventgroupAck設(shè)置

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

如下圖8為SubcribeEventGroupAck的配置注意事項(xiàng)：

圖8 SubscribeEventGroupAck配置

SubscribeEventgroupNack設(shè)置

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

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

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

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

參考的Option Entries存在錯(cuò)誤，丟失，或者互相矛盾的點(diǎn)；

如下圖9為SubcribeEventGroupNack的配置注意事項(xiàng)：

圖9 SubscribeEventGroupAck配置

SD Message

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

Tx Path

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

S1：SD報(bào)文已按照SD報(bào)文格式組包成功；

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報(bào)文發(fā)送至總線上；

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

圖10 SD報(bào)文發(fā)送時(shí)序圖

Rx Path

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

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

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

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

S4：存儲(chǔ)報(bào)文與地址信息以便下一步處理；

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

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

圖11 SD報(bào)文接收時(shí)序圖

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

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

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

SD狀態(tài)機(jī)解析

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

Server SD狀態(tài)機(jī)

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

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

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

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

Client SD狀態(tài)機(jī)

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

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

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

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

審核編輯：郭婷