SOME/IP-SD有何作用

前言

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

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

SOME/IP-SD有何作用呢？

SOME/IP-SD 包含哪些內(nèi)容呢？

SOME/IP-TP 為什么會(huì)存在？

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

正文

總體介紹

車載以太網(wǎng)協(xié)議?？偣部蓜澐譃槲鍖?，分別為物理層，數(shù)據(jù)鏈路層，網(wǎng)絡(luò)層，傳輸層，應(yīng)用層，其中今天所要介紹的內(nèi)容SOME/IP就是一種應(yīng)用層協(xié)議。 SOME/IP協(xié)議內(nèi)容按照AUTOSAR中的描述，我們可以更進(jìn)一步的拆分為三類子協(xié)議：應(yīng)用層的SOME/IP標(biāo)準(zhǔn)協(xié)議，SOME/IP-SD協(xié)議以及TP層的SOME/IP-TP協(xié)議，這三部分內(nèi)容相輔相成，完整詳細(xì)的闡述了SOME/IP協(xié)議的全部?jī)?nèi)容，是研究SOME/IP協(xié)議的必經(jīng)之路。 通過上篇《一網(wǎng)打盡車載以太網(wǎng)之SOME/IP(上)》我們?nèi)嬷v解了SOME/IP標(biāo)準(zhǔn)協(xié)議的全部?jī)?nèi)容，想必大家已經(jīng)對(duì)SOME/IP有了一個(gè)較為基礎(chǔ)的了解，接下來本文將著重講解剩余的兩部分協(xié)議內(nèi)容：SOME/IP-SD協(xié)議以及TP層的SOME/IP-TP協(xié)議。 有關(guān)SOME/IP序列化內(nèi)容限于篇幅有限，請(qǐng)聽下回分解，敬請(qǐng)關(guān)注！

SOME/IP-SD 主體功能

SD(Service Discovery)顧名思義為服務(wù)發(fā)現(xiàn)，具備發(fā)現(xiàn)服務(wù)的基本功能，這是從節(jié)點(diǎn)作為Client來考慮的，需要找到網(wǎng)絡(luò)上對(duì)應(yīng)的服務(wù)；對(duì)應(yīng)地，網(wǎng)絡(luò)中必然存在至少提供該服務(wù)的節(jié)點(diǎn)，該節(jié)點(diǎn)可被稱Server，因此這樣的供需場(chǎng)景就是SD協(xié)議工作的場(chǎng)景。 在這種供需場(chǎng)景中我們看到了提供服務(wù)，訂閱服務(wù)的過程，該過程如果用專業(yè)術(shù)語(yǔ)來講可稱為Subcribe/Publish模型，該模型涉及到Client與Server兩方，交互過程如之前文章所描述如下圖1所示： 圖1 SOME/IP-SD 交互過程 由上圖可知，Subribe/Publish的過程主要經(jīng)歷以下四個(gè)階段：

對(duì)于需要服務(wù)的Client而言，通過FindService方式來發(fā)現(xiàn)當(dāng)前網(wǎng)絡(luò)中存在的服務(wù)；

如果Server存在服務(wù)就會(huì)通過Offer Service方式來廣播通知自身存在的服務(wù)；

Client根據(jù)已發(fā)現(xiàn)的服務(wù)中通過Subcribe EventGroup的方式來訂閱相關(guān)事件，同時(shí)在Server段發(fā)現(xiàn)Client的訂閱滿足條件則會(huì)回復(fù)正確的肯定響應(yīng)；

當(dāng)Client訂閱成功后，Server端便會(huì)按照服務(wù)的基本屬性來事件型或者周期性提供Client端相關(guān)的服務(wù)；

總而言之，SOME/IP-SD就是用于定位服務(wù)，檢查服務(wù)可用性以及部署與發(fā)布服務(wù)句柄的一種應(yīng)用層協(xié)議，該協(xié)議只能運(yùn)行在UDP之上，服務(wù)發(fā)現(xiàn)報(bào)文格式與SOME/IP標(biāo)準(zhǔn)協(xié)議一致，且Message ID固定為0xFFFF8100，其中Service ID是0xFFFF，Method ID為0x8100。

SOME/IP-SD協(xié)議解析

SOME/IP-SD協(xié)議頭 首先，依照慣例我們先來看下SOME/IP-SD的報(bào)文格式如下圖2所示： 圖2 SOME/IP-SD Message Format 一般而言，如果沒有特別要求，在SD報(bào)文格式中的內(nèi)容均按照大端方式傳輸。 由于SOME/IP-SD報(bào)文實(shí)際上也只是SOME/IP報(bào)文的一種，只不過是在SOME/IP標(biāo)準(zhǔn)協(xié)議的基礎(chǔ)上擴(kuò)展了Entry，Option等字段，其中Entry用于同步服務(wù)實(shí)例的狀態(tài)以及發(fā)布/訂閱關(guān)系的管理，Options則用于傳輸Entry的附加信息。 接下來，我們將針對(duì)上述的協(xié)議中各種字段為大家一一解釋如下表1： 表1 SOME/IP-SD 協(xié)議內(nèi)字段解釋 ? Entry Array 如上表1中所述，Entry Array按照SD的定義可分為以下兩種：

Service Type：用于FindService，OfferService，StopOfferService這幾種場(chǎng)景；

EventGroup Type：用于 SubscribeEventgroup， StopSubscribeEventgroup，SubscribeEventgroupAck，SubscribeEventgroupNack這幾類場(chǎng)景。

如下圖3所示，首先我們介紹下為Service Entry Array中定義的各個(gè)字段內(nèi)容： 圖3 Service Entry Array定義 對(duì)上述Service Entry Array定義的各個(gè)Field解釋說明如下表2所示： 表2 Service Entry Array字段解釋說明 介紹完Service Entry Array，相比之下EventGroup Entry Array又存在哪些差異呢？ 如下圖4為EventGroup Entry Array的各個(gè)字段內(nèi)容的定義： 圖4 EventGroup Entry Array定義 相比Service Entry Array，EventGroup Entry少了Minor Version，但是多出了Counter以及EventGroup ID內(nèi)容，接下來我們將對(duì)上述EventGroup Entry Array定義的各個(gè)Field解釋說明如下表3所示： 表3 EventGroup Entry Array字段解釋說明 ? Option Array Option Array作為SOME/IP-SD報(bào)文最后的部分，其主要作用就是為了提供在通信的過程中提供下附加信息，如配置信息，IP地址，端口號(hào)等。不過其作為SD報(bào)文的一部分也存在著自身的字段內(nèi)容。 AUTOSAR將Option Array主要分為以下三種：

Configuration Options：用于配置通信過程的必要的信息

Endpoint Options(IPV4/IPV6):用于傳遞IPV4或者IPV6的Endpoint信息(IP地址+Port號(hào))以及使用的傳輸層協(xié)議；

Multicast Options(IPV4/IPV6):用于廣播IPV4或者IPV6的IP地址及Port號(hào)，其中傳輸層協(xié)議只能使用UDP協(xié)議；

Configuration Options 接下來我們來對(duì)這三種Option進(jìn)行一一解讀。首先來看看Configuration Option的字段定義： 圖5 Configuration Option 字段定義 ? 注意：configuration options僅適用于任意Service ID的Service Entry Array以及Service ID為0xFFFE的EventGroup Entry Array。 針對(duì)上述字段解釋如下表4所示： 表4 Configuration Option Array 字段解釋說明 對(duì)于那些非標(biāo)準(zhǔn)的SOME/IP 服務(wù)，由于不能夠被Service ID進(jìn)行標(biāo)識(shí)，此時(shí)就需要通過一個(gè)key “otherserv”的值來進(jìn)行標(biāo)識(shí)，這類服務(wù)則可通過使用0xFFFE作為Service ID同時(shí)附帶otherserv的value的configuration option來完成雙方的通信。 IPV4 Endpoint Option 如下圖6為IPV4 Endpoint Option的字段定義： 圖6 IPV4 Endpoint Option字段定義 IPV6 Endpoint Option 如下圖7為IPV6 Endpoint Option的字段定義： 圖7 IPV6 Endpoint Option字段定義 ? IPv4 Multicast Option 如下圖8為IPv4的Multicast Option各字段內(nèi)容定義： 圖8 IPv4 Multicast Option ? IPv6 Multicast Option 如下圖8為IPv6的Multicast Option各字段內(nèi)容定義： 圖9 IPv6 Multicast Option定義 ? IPv4 SD Endpoint Option 如下圖10為IPv4 SD Endpoint Option的字段定義： 圖10 IPv4 SD Endpoint Option定義 ? IPv6 SD Endpoint Option 如下圖11為IPv6 SD Endpoint Option的字段定義： 圖11 IPv6 SD Endpoint Option定義 由于上述六種IPV4與IPV6字段內(nèi)容大體結(jié)構(gòu)一致，因此我們將該兩者放在一起來對(duì)各字段內(nèi)容進(jìn)行解釋說明： 表5 IPv4/IPv6 六類Option字段解釋說明 ?

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

SD狀態(tài)機(jī)狀態(tài)機(jī)這部分由于涉及的內(nèi)容細(xì)節(jié)較多且較為獨(dú)立，同時(shí)限于篇幅有限，后期會(huì)專門針對(duì)SD狀態(tài)機(jī)，SD報(bào)文接收發(fā)送等環(huán)節(jié)給大家單獨(dú)分享，敬請(qǐng)期待SOME/IP-SD狀態(tài)機(jī)專題篇！

SOME/IP-TP主體功能

我們知道CAN-TP是用來對(duì)當(dāng)總線CAN數(shù)據(jù)過大時(shí)，就需要對(duì)CAN整包數(shù)據(jù)進(jìn)行分割拆包進(jìn)行發(fā)送，這個(gè)時(shí)候發(fā)送方的TP層就起作用，同理對(duì)于接收方而言，也需要將分割的數(shù)據(jù)包進(jìn)行組包完成整包數(shù)據(jù)的重組還原。 因此，舉一反三，我們便可以知道SOME/IP-TP模塊的主體功能就是為了實(shí)現(xiàn)對(duì)應(yīng)用層發(fā)送數(shù)據(jù)過大時(shí)進(jìn)行的必要拆包與組包的工作，進(jìn)而完成大量數(shù)據(jù)包的發(fā)送與接收。 SOME/IP作為一種應(yīng)用層協(xié)議，既可以運(yùn)行在TCP之上，也可以運(yùn)行在UDP之上，由于TCP協(xié)議本身支持發(fā)送大量數(shù)據(jù)同時(shí)還支持流控等特點(diǎn)因此無(wú)需用到SOME/IP-TP,該協(xié)議僅針對(duì)運(yùn)行在UDP協(xié)議基礎(chǔ)上的SOME/IP協(xié)議。 該模塊作為AUTOSAR中定義的標(biāo)準(zhǔn)模塊，在AUTOSAR中與各個(gè)模塊的交互關(guān)系又是如何的呢？ 如下圖12所示，則較為清晰的表明了SOME/IP-TP在CP AUTOSAR的具體位置以及與其他模塊的交互關(guān)系： 圖12 SOME/IP-TP在AUTOSAR的位置及交互關(guān)系 從圖中可以直接看出SOME/IP-TP直接與PDUR層進(jìn)行交互，當(dāng)上層應(yīng)用模塊發(fā)送大量數(shù)據(jù)時(shí)，會(huì)通過PDUR發(fā)送數(shù)據(jù)給到SOME/IP-TP模塊進(jìn)行拆包，拆分的包將按照協(xié)議格式再通PPDUR模塊依次發(fā)送。 對(duì)于接收方而言，則是接收來自PDUR的報(bào)文，通過SOME/IP-TP模塊進(jìn)行組包，組包后的結(jié)果給到PDUR，然后由PDUR再傳輸至上層應(yīng)用模塊。

SOME/IP-TP協(xié)議解析

了解了SOME/IP-TP的主體功能以及大概的工作過程，接下來我們一起解析下SOME/IP-TP協(xié)議。 SOME/IP-TP作為SOME/IP報(bào)文的一種，因此前面的SOME/IP Header則保持一致，只是SOME/IP-TP存在自身的協(xié)議頭，讓我們一起來學(xué)習(xí)一下。 SOME/IP-TP協(xié)議頭 如下圖13為SOME/IP-TP層的協(xié)議頭字段內(nèi)容： 圖13 SOME/IP-TP 協(xié)議頭字段內(nèi)容 針對(duì)上圖中每個(gè)字段內(nèi)容地詳細(xì)解釋請(qǐng)參考上篇鏈接《一網(wǎng)打盡車載以太網(wǎng)之SOME/IP(上)》 其中Message Type更為細(xì)節(jié)地定義如下圖14所示： 圖14 Message Type 字段內(nèi)容 ?

當(dāng)且僅當(dāng)TP-Flag==1時(shí)，OffsetField，Reserved Field以及More Segement Flag才會(huì)存在；

當(dāng)TP-Flag == 1時(shí)，表示當(dāng)前SOME/IP報(bào)文為被分割的報(bào)文，即Segement報(bào)文；

其中Offset Field表示當(dāng)前已發(fā)送或者接收的數(shù)據(jù)量，其基本單位為16Byte，如該值等于92，表示截至目前為止已發(fā)送了92X16=1472字節(jié)長(zhǎng)度的Payload。同時(shí)該長(zhǎng)度并不包含SOME/IP header的長(zhǎng)度。 其中Reserved Field為未來預(yù)留，目前默認(rèn)為0即可； 其中More Segments Flag用來表示是否還有Segement報(bào)文，當(dāng)其值為1時(shí)表示還有剩余的Segement，當(dāng)其值為0時(shí)則表示沒有剩余的Segement，當(dāng)前Segement就是最后一條。 Tx Path 對(duì)于發(fā)送一個(gè)基于UDP完整的SOME/IP報(bào)文而言，報(bào)文的發(fā)送需要經(jīng)歷以下幾個(gè)模塊：

應(yīng)用層調(diào)用Rte_Send函數(shù)來實(shí)現(xiàn)數(shù)據(jù)SOME/IP序列化；

通過LdCom模塊間接調(diào)用SomeIpTp_Transmit來開啟發(fā)送；

通過循環(huán)調(diào)用SOME/IP-TP的主函數(shù)來遍歷發(fā)送每一個(gè)Segement；

同時(shí)發(fā)送出去的報(bào)文也會(huì)回復(fù)Txconfirmation中斷最終傳遞至RteLdCom模塊；

具體發(fā)送流程中的函數(shù)調(diào)用關(guān)系如下圖15所示： 圖15 Tx Path函數(shù)調(diào)用關(guān)系圖 ? Rx Path 針對(duì)被分割的segment，接收方需要通過下列幾個(gè)步驟進(jìn)行接收：

通過SoAd模塊來獲取來自總線的SOME/IP數(shù)據(jù)；

PDUR模塊接收到來自SoAd模塊的數(shù)據(jù)后會(huì)觸發(fā)SomeIpTp_Rxindicaion表明存在segement數(shù)據(jù)，準(zhǔn)備開啟接收；

SOME/IP-TP模塊通過調(diào)用PDUR_SomeIpTpStartOfReception開啟接收第一個(gè)Segement；

剩余的Segment則可以通過不斷觸發(fā)PDUR_SomeIpTpCopyRxData來接收，最終傳送至RTE層；

當(dāng)最后一個(gè)segment被接收到后，則通過調(diào)用函數(shù)PduR_SomeIpRxIndication來完成最終的接收并使得RTE反序列化給到應(yīng)用層讀取；

具體接收流程的函數(shù)調(diào)用關(guān)系如下圖16所示： 圖16 Rx Path函數(shù)調(diào)用關(guān)系圖??