前言

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

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

SOME/IP-SD有何作用呢？

SOME/IP-SD 包含哪些內容呢？

SOME/IP-TP 為什么會存在？

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

正文

總體介紹

車載以太網協議?？偣部蓜澐譃槲鍖樱謩e為物理層，數據鏈路層，網絡層，傳輸層，應用層，其中今天所要介紹的內容SOME/IP就是一種應用層協議。 SOME/IP協議內容按照AUTOSAR中的描述，我們可以更進一步的拆分為三類子協議：應用層的SOME/IP標準協議，SOME/IP-SD協議以及TP層的SOME/IP-TP協議，這三部分內容相輔相成，完整詳細的闡述了SOME/IP協議的全部內容，是研究SOME/IP協議的必經之路。 通過上篇《一網打盡車載以太網之SOME/IP(上)》我們全面講解了SOME/IP標準協議的全部內容，想必大家已經對SOME/IP有了一個較為基礎的了解，接下來本文將著重講解剩余的兩部分協議內容：SOME/IP-SD協議以及TP層的SOME/IP-TP協議。 有關SOME/IP序列化內容限于篇幅有限，請聽下回分解，敬請關注！

SOME/IP-SD 主體功能

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

對于需要服務的Client而言，通過FindService方式來發現當前網絡中存在的服務；

如果Server存在服務就會通過Offer Service方式來廣播通知自身存在的服務；

Client根據已發現的服務中通過Subcribe EventGroup的方式來訂閱相關事件，同時在Server段發現Client的訂閱滿足條件則會回復正確的肯定響應；

當Client訂閱成功后，Server端便會按照服務的基本屬性來事件型或者周期性提供Client端相關的服務；

總而言之，SOME/IP-SD就是用于定位服務，檢查服務可用性以及部署與發布服務句柄的一種應用層協議，該協議只能運行在UDP之上，服務發現報文格式與SOME/IP標準協議一致，且Message ID固定為0xFFFF8100，其中Service ID是0xFFFF，Method ID為0x8100。

SOME/IP-SD協議解析

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

Service Type：用于FindService，OfferService，StopOfferService這幾種場景；

EventGroup Type：用于 SubscribeEventgroup， StopSubscribeEventgroup，SubscribeEventgroupAck，SubscribeEventgroupNack這幾類場景。

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

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

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

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

Configuration Options 接下來我們來對這三種Option進行一一解讀。首先來看看Configuration Option的字段定義： 圖5 Configuration Option 字段定義 ? 注意：configuration options僅適用于任意Service ID的Service Entry Array以及Service ID為0xFFFE的EventGroup Entry Array。 針對上述字段解釋如下表4所示： 表4 Configuration Option Array 字段解釋說明 對于那些非標準的SOME/IP 服務，由于不能夠被Service ID進行標識，此時就需要通過一個key “otherserv”的值來進行標識，這類服務則可通過使用0xFFFE作為Service ID同時附帶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各字段內容定義： 圖8 IPv4 Multicast Option ? IPv6 Multicast Option 如下圖8為IPv6的Multicast Option各字段內容定義： 圖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字段內容大體結構一致，因此我們將該兩者放在一起來對各字段內容進行解釋說明： 表5 IPv4/IPv6 六類Option字段解釋說明 ?

SD 狀態機

SD狀態機狀態機這部分由于涉及的內容細節較多且較為獨立，同時限于篇幅有限，后期會專門針對SD狀態機，SD報文接收發送等環節給大家單獨分享，敬請期待SOME/IP-SD狀態機專題篇！

SOME/IP-TP主體功能

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

SOME/IP-TP協議解析

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

當且僅當TP-Flag==1時，OffsetField，Reserved Field以及More Segement Flag才會存在；

當TP-Flag == 1時，表示當前SOME/IP報文為被分割的報文，即Segement報文；

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

應用層調用Rte_Send函數來實現數據SOME/IP序列化；

通過LdCom模塊間接調用SomeIpTp_Transmit來開啟發送；

通過循環調用SOME/IP-TP的主函數來遍歷發送每一個Segement；

同時發送出去的報文也會回復Txconfirmation中斷最終傳遞至RteLdCom模塊；

具體發送流程中的函數調用關系如下圖15所示： 圖15 Tx Path函數調用關系圖 ? Rx Path 針對被分割的segment，接收方需要通過下列幾個步驟進行接收：

通過SoAd模塊來獲取來自總線的SOME/IP數據；

PDUR模塊接收到來自SoAd模塊的數據后會觸發SomeIpTp_Rxindicaion表明存在segement數據，準備開啟接收；

SOME/IP-TP模塊通過調用PDUR_SomeIpTpStartOfReception開啟接收第一個Segement；

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

當最后一個segment被接收到后，則通過調用函數PduR_SomeIpRxIndication來完成最終的接收并使得RTE反序列化給到應用層讀?。?/p>

具體接收流程的函數調用關系如下圖16所示： 圖16 Rx Path函數調用關系圖??