前言

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

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

• 你知道為什么會(huì)產(chǎn)生SOME/IP即相關(guān)背景嗎？

• 你知道SOME/IP與SOA又有著哪些千絲萬(wàn)縷的聯(lián)系呢？

• SOME/IP在實(shí)踐中到底應(yīng)該如何使用呢？

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

正文

總體介紹

正如之前文章一文入門車載以太網(wǎng)，吐血整理! 不看可惜！中所介紹的那樣，車載以太網(wǎng)協(xié)議?？偣部蓜澐譃槲鍖樱謩e為物理層，數(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)之路。

由于SOME/IP協(xié)議內(nèi)容較多且關(guān)聯(lián)復(fù)雜，為了讓大家對(duì)SOME/IP有一個(gè)循序漸進(jìn)的了解過(guò)程，限于篇幅本文將主要講解應(yīng)用層的SOME/IP標(biāo)準(zhǔn)協(xié)議，其他協(xié)議內(nèi)容會(huì)在下篇繼續(xù)給大家分享，敬請(qǐng)大家多多關(guān)注！

產(chǎn)生背景與動(dòng)機(jī)

2011年寶馬公司開(kāi)發(fā)設(shè)計(jì)了一套中間件，該中間件能夠?qū)崿F(xiàn)以服務(wù)為導(dǎo)向的通信方式，該中間件區(qū)別于傳統(tǒng)以信號(hào)為導(dǎo)向的通信方式，不僅能夠大大減少網(wǎng)絡(luò)負(fù)載以提高通信雙方的效率，同時(shí)引入以太網(wǎng)通信也能夠大大滿足未來(lái)車輛不斷增長(zhǎng)的通信需求。

面向信號(hào)的數(shù)據(jù)傳輸不管網(wǎng)絡(luò)需不需要始終會(huì)不斷循環(huán)發(fā)送，而面向服務(wù)的通信方式則不同，只有當(dāng)網(wǎng)絡(luò)中至少存在一個(gè)接收方需要這些數(shù)據(jù)時(shí)，發(fā)送方才會(huì)發(fā)送數(shù)據(jù)，這是一種面向服務(wù)通信方式的顯著優(yōu)點(diǎn)。

寶馬將該面向服務(wù)的通信方式叫做SOME/IP(全稱為：Scalable service-Oriented MiddlewarE over IP)。正如其名，可見(jiàn)該協(xié)議跟以太網(wǎng)密切相關(guān)。

沒(méi)錯(cuò)！SOME/IP就是運(yùn)行在車載以太網(wǎng)協(xié)議棧基礎(chǔ)之上的中間件，或者也可以稱為應(yīng)用層軟件。

SOME/IP正由于其知名度逐漸被AUTOSAR接納并計(jì)劃納入其正式標(biāo)準(zhǔn)，并且在2014年集成進(jìn)AUTOSAR 4.X中，幾個(gè)關(guān)鍵發(fā)展節(jié)點(diǎn)如下：

• AUTOSAR 4.0 - 完成寶馬SOME/IP消息的初步集成；

• AUTOSAR 4.1 - 支持SOME/IP-SD及其發(fā)布/訂閱功能；

• AUTOSAR 4.2 - 添加transformer用于序列化以及其他相關(guān)優(yōu)化；

• AUTOSAR 4.3 - 修復(fù)一些transformer bug同時(shí)添加針對(duì)大量UDP數(shù)據(jù)包的SOME/IP-TP協(xié)議以及其他SOME/IP-SD的優(yōu)化工作；

• 持續(xù)優(yōu)化中。。。。。。

什么是SOME/IP

正如上節(jié)所提到SOME/IP的全稱，接下來(lái)我們就來(lái)通過(guò)其全稱一起來(lái)了解下SOME/IP到底是個(gè)什么東西：

• Scalable

  該協(xié)議設(shè)計(jì)的初衷之一就是為了實(shí)現(xiàn)不同硬件平臺(tái)、不同操作系統(tǒng)或嵌入式固件以及不同應(yīng)用軟件的異構(gòu)設(shè)備之間的可擴(kuò)展性和互操作性。

• service-Oriented

  表明它是一種面向服務(wù)的基本協(xié)議。因此僅當(dāng)客戶端請(qǐng)求或服務(wù)器通知特定訂閱者時(shí)，才在客戶端-服務(wù)器配置中交換數(shù)據(jù) ，這就確保了永遠(yuǎn)不會(huì)浪費(fèi)帶寬，并且僅在需要的時(shí)間和地點(diǎn)進(jìn)行數(shù)據(jù)通信/交換。

• MiddlewarE

  它也是一種中間件。即其位于應(yīng)用層，有自己的通用協(xié)議層來(lái)處理更具體的操作及應(yīng)用；

• over IP

  它也是一個(gè)基于以太網(wǎng)的協(xié)議。它使用類似的硬件接口，確保高達(dá) 100Mbps 的帶寬。同時(shí)數(shù)據(jù)通過(guò)中間件（即應(yīng)用層）通過(guò)網(wǎng)絡(luò)電纜使用 TCP/IP 或 UDP 協(xié)議進(jìn)行通信。

  當(dāng)客戶端需要來(lái)自服務(wù)器的數(shù)據(jù)時(shí)，它可由客戶端使用 TCP 協(xié)議進(jìn)行請(qǐng)求。如果服務(wù)器必須將數(shù)據(jù)傳送給所有活動(dòng)的訂閱者，則可通過(guò) UDP 協(xié)議傳輸。UDP 協(xié)議上的數(shù)據(jù)通信可以是單播、多播或廣播。

如下圖1所示，就十分清晰地展示了SOME/IP在車載以太網(wǎng)協(xié)議棧中的位置以及與其他模塊的關(guān)系：

那么在AUTOSAR協(xié)議棧中，SOME/IP協(xié)議又處于一個(gè)什么樣的位置呢？如下圖所示：

如上圖可知，SOME/IP協(xié)議涉及到與RTE，COM，PDUR以及SOAd這些AUTOSAR標(biāo)準(zhǔn)模塊的交互，而用于服務(wù)發(fā)現(xiàn)的SOME/IP-SD則涉及到BswM，SD以及SoAd模塊的交互。

SOME/IP協(xié)議與各個(gè)模塊的交互關(guān)系會(huì)在后續(xù)文章講到，提及于此讓大家對(duì)SOME/IP協(xié)議與AUTOSAR協(xié)議棧的關(guān)聯(lián)有個(gè)整體概念，此文中不做過(guò)多展開(kāi)。

SOME/IP 最初是作為另一種 RPC 機(jī)制開(kāi)發(fā)的，以確保與 AUTOSAR 設(shè)備的兼容性并提供汽車用例所需的最大功能，同時(shí)它也是專為ECU間客戶端-服務(wù)器序列化而設(shè)計(jì)的網(wǎng)絡(luò)層協(xié)議。

目前，該協(xié)議可以在多種不同的操作系統(tǒng)上實(shí)現(xiàn)，包括 AUTOSAR、OSEK 和 GENIVI。它也可以在不運(yùn)行操作系統(tǒng)的嵌入式固件上實(shí)現(xiàn)。

攝像頭、主機(jī)、遠(yuǎn)程信息處理設(shè)備、AUTOSAR 設(shè)備，甚至信息娛樂(lè)系統(tǒng)等大型設(shè)備，都可以使用 SOME/IP 協(xié)議有效地交換 ECU 間消息。自 Wireshark 3.2 SOME/IP 發(fā)布以來(lái)，SOME/IP 支持就已公開(kāi)，可以在 Wireshark 上解析SOME/IP數(shù)據(jù)。

綜上所述，我們便可以總結(jié)出SOME/IP作為一種面向服務(wù)的通信協(xié)議，一種基于車載以太網(wǎng)協(xié)議?；A(chǔ)上的應(yīng)用層協(xié)議的基本特點(diǎn)有哪些，如下表1所示展現(xiàn)了SOME/IP協(xié)議的五大基本特點(diǎn)：

SOME/IP與SOA的關(guān)系

SOA

SOA簡(jiǎn)而言之就是一種面向服務(wù)的架構(gòu)(Service-Oriented Architecture), 當(dāng)然也是一種軟件設(shè)計(jì)的重要方式，IT研究與顧問(wèn)咨詢公司 Gartner 在 1996 年提出的，其本身并不是新鮮概念，而且已經(jīng)在IT互聯(lián)網(wǎng)領(lǐng)域風(fēng)靡了20余年。

按照W3C對(duì)它的定義 : “SOA是一種應(yīng)用程序架構(gòu)，在這種架構(gòu)中，所有功能都定義為獨(dú)立的服務(wù)，這些服務(wù)帶有定義明確的可調(diào)用接口，能夠以定義好的順序調(diào)用這些服務(wù)來(lái)形成業(yè)務(wù)流程。

服務(wù)： 服務(wù)是一種比構(gòu)件粒度更大的信息集合，實(shí)際是包含實(shí)現(xiàn)了多個(gè)關(guān)聯(lián)業(yè)務(wù)需求的邏輯組合，并且允許每個(gè)服務(wù)使用特定的平臺(tái)，架構(gòu)或技術(shù)方案；

可調(diào)用接口： 面向服務(wù)的接口不同于構(gòu)件的接口，他的實(shí)現(xiàn)與特定語(yǔ)言無(wú)關(guān)，與特定的平臺(tái)也無(wú)關(guān)，可十分方便的實(shí)現(xiàn)不同異構(gòu)平臺(tái)的交互；

聯(lián)系與區(qū)別：

• 首先需要明確的是SOME/IP不是SOA，SOA也不是SOME/IP；

• 由于SOME/IP本身也是一種面向服務(wù)的協(xié)議，所以一般認(rèn)為SOME/IP只不過(guò)是一種實(shí)現(xiàn)SOA可行的協(xié)議選擇；

• 一般而言，基于消息的通信與RPC(Remote Procedure Call 遠(yuǎn)程過(guò)程調(diào)用)通信都可以實(shí)現(xiàn)SOA，而SOME/IP就是一種基于RPC框架的協(xié)議；

• 可以通過(guò)SOME/IP用來(lái)實(shí)現(xiàn)SOA，但SOA的實(shí)現(xiàn)卻不一定非得用SOME/IP;

SOME/IP協(xié)議解析

接下來(lái)就讓小T帶領(lǐng)大家通過(guò)解析SOME/IP一起來(lái)揭開(kāi)SOME/IP的神秘面紗！，以便為后續(xù)車載以太網(wǎng)的學(xué)習(xí)打好基礎(chǔ)。

相關(guān)標(biāo)識(shí)符與版本說(shuō)明

如下圖2所示為SOME/IP協(xié)議的Header結(jié)構(gòu)體：

如上圖中標(biāo)記的Message ID，Request ID, Protocal Version 以及Interface Version的詳細(xì)解釋如下表2所示：

Length

Length正如上圖2所示，其涵蓋的范圍是Request ID開(kāi)始至SOME/IP報(bào)文結(jié)束。

Message Type

用來(lái)識(shí)別不同的消息類型，目前存在的類型如下圖3所示，其中TP表示分包的報(bào)文,按照AUTOSAR標(biāo)準(zhǔn)(R21-11)定義如下：

Return Code

Return Code用來(lái)指示Message是否被成功處理了，或針對(duì)請(qǐng)求中的錯(cuò)誤內(nèi)容進(jìn)行反饋，如下圖4為AUTOSAR(R21-11)中定義的Return Code類型：

SOME/IP通信機(jī)制

認(rèn)識(shí)完了SOME/IP協(xié)議標(biāo)準(zhǔn)的詳細(xì)定義內(nèi)容之后，接下來(lái)就需要來(lái)探討車載ECU需要按照何種規(guī)則來(lái)實(shí)現(xiàn)數(shù)據(jù)的傳輸，因此熟悉這部分內(nèi)容將對(duì)車載以太網(wǎng)SOME/IP的開(kāi)發(fā)與測(cè)試至關(guān)重要。

服務(wù)發(fā)現(xiàn)(Service Discovery)

服務(wù)發(fā)現(xiàn)的通信機(jī)制是通過(guò)SOME/IP-SD協(xié)議實(shí)現(xiàn)的，主要是為了實(shí)現(xiàn)在車載以太網(wǎng)中告知客戶端當(dāng)前服務(wù)實(shí)例的可用性及訪問(wèn)方式，可通過(guò)Find Service 和Offer Service來(lái)實(shí)現(xiàn)。

在通過(guò)SOME/IP協(xié)議傳輸數(shù)據(jù)之前，我們需要知道當(dāng)前整個(gè)車載網(wǎng)絡(luò)到底存在哪些服務(wù)，服務(wù)的可用性如何，客戶端如果訂閱服務(wù)端所提供的服務(wù)。

由于SOME/IP-SD協(xié)議也是一塊十分重要的內(nèi)容，在此就不過(guò)多展開(kāi)，僅簡(jiǎn)要介紹其基本功能與作用機(jī)理，后續(xù)會(huì)單獨(dú)介紹SOME/IP-SD協(xié)議的具體內(nèi)容，敬請(qǐng)關(guān)注！

如下圖5所示即為SOME/IP-SD的基本功能，展現(xiàn)了Client與Server之間的交互關(guān)系。

由上圖可知，SOME/IP 服務(wù)發(fā)現(xiàn)流程可以分為以下三大基本步驟：

• Client通過(guò)發(fā)送Find Service的報(bào)文去尋找車載網(wǎng)絡(luò)中可用的服務(wù)實(shí)例；

• Server接收到Client的Find Server后通過(guò)UDP發(fā)送Offer Service響應(yīng)；

• Client通過(guò)發(fā)送Subcribe Event Group去訂閱相關(guān)Event；

• Server檢查是否滿足Client是否滿足訂閱條件，如果滿足回復(fù)ACK，如果不滿足，則回復(fù)NACK；

• Client成功訂閱相關(guān)事件后，Server會(huì)按照事件本身屬性來(lái)實(shí)現(xiàn)對(duì)已訂閱該事件的Client的發(fā)布；

遠(yuǎn)程進(jìn)程調(diào)用(RPC)

遠(yuǎn)程進(jìn)程調(diào)用主要可分為四種通信模式：

• Request/Response通信模式，可歸納為Method中的一種；其基本通信模型如下圖6所示：

  Request-Response模型作為一種最為常見(jiàn)的通信方式，其主要任務(wù)就是客戶端發(fā)送請(qǐng)求信息，服務(wù)端接收到請(qǐng)求，進(jìn)行相關(guān)處理之后進(jìn)行相應(yīng)的響應(yīng)。

• Fire&Forget通信模式，可歸納為Method中的一種；

  該通信模型的主要任務(wù)就是客戶端向服務(wù)端發(fā)送請(qǐng)求，服務(wù)端無(wú)需進(jìn)行任何響應(yīng)，有點(diǎn)類似診斷服務(wù)中的抑制正響應(yīng)。

  

• Notification Event通信模式；

  該通信模式主要描述了發(fā)布 /訂閱消息內(nèi)容，主要任務(wù)就是為了實(shí)現(xiàn)客戶端向服務(wù)端訂閱相關(guān)的事件組，當(dāng)服務(wù)端的事件組發(fā)生或者值發(fā)生變化時(shí)，就需要向已訂閱該事件組的客戶端發(fā)布更新的內(nèi)容。

• 遠(yuǎn)程進(jìn)程控制(Field)

  訪問(wèn)進(jìn)程通信機(jī)制主要是為了實(shí)現(xiàn)針對(duì)對(duì)應(yīng)用程序的數(shù)據(jù)獲取與更改，主要任務(wù)就是實(shí)現(xiàn)客戶端通過(guò)Getter獲取Server的值，通過(guò)Setter設(shè)置Server的值。

  Field就可理解為一個(gè)Service的基本屬性，可包含Getter，Setter，Notifier三種方式。其中Getter就是讀取Field中某個(gè)值的方法，Setter就是一種改變Field值的方法，而Notifier則是一種當(dāng)Field中的值發(fā)生變化的觸發(fā)事件。

  

  圖9 Field的通信模型

由上圖可知，在Getter與Setter的方式中我們使用的Request/Response機(jī)制。在Getter的請(qǐng)求報(bào)文中是一個(gè)空的Payload，響應(yīng)報(bào)文中的Payload才是需要獲取的值；使用Setter請(qǐng)求時(shí)，請(qǐng)求消息中的Payload則是要設(shè)置的值，如果設(shè)置成功，那么響應(yīng)報(bào)文中Payload就是設(shè)定成功的值。

同時(shí)我們也可得出服務(wù)實(shí)體在SOME/IP協(xié)議中是一個(gè)十分重要的概念。一個(gè)服務(wù)實(shí)體可以是Field，Events以及Method的任意組合。

SOME/IP錯(cuò)誤處理機(jī)制

在任何通信過(guò)程中總是會(huì)存在各種各樣的 錯(cuò)誤，SOME/IP作為一種面向服務(wù)的應(yīng)用協(xié)議也不例外，因此AUTOSAR為了更為高效的定位到通訊過(guò)程中的問(wèn)題所在，因此制定了一套檢查SOME/IP協(xié)議格式內(nèi)容的錯(cuò)誤處理機(jī)制。

比如版本信息檢查，服務(wù)ID等，其他故障信息可以在Payload中進(jìn)行詳細(xì)定義。目前SOME/IP支持以下兩種錯(cuò)誤處理機(jī)制，這兩種uowu處理機(jī)制可以根據(jù)配置進(jìn)行選擇。

• 消息類型0x80，Response信息，即可以通過(guò)Response Message中的Return Code來(lái)定位到問(wèn)題所在；

• 消息類型0x81，顯式的錯(cuò)誤信息；

如下圖10為SOME/IP處理一般性錯(cuò)誤的基本流程：

Entry Array

如上表1中所述，Entry Array按照SD的定義可分為以下兩種：

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

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

如下圖12所示，首先我們介紹下為Service Entry Array中定義的各個(gè)字段內(nèi)容：

對(duì)上述Service Entry Array定義的各個(gè)Field解釋說(shuō)明如下表2所示：

介紹完Service Entry Array，相比之下EventGroup Entry Array又存在哪些差異呢？

如下圖13為EventGroup Entry Array的各個(gè)字段內(nèi)容的定義：

相比Service Entry Array，EventGroup Entry少了Minor Version，但是多出了Counter以及EventGroup ID內(nèi)容，接下來(lái)我們將對(duì)上述EventGroup Entry Array定義的各個(gè)Field解釋說(shuō)明如下表3所示：

Option Array

Option Array作為SOME/IP-SD報(bào)文最后的部分，其主要作用就是為了提供在通信的過(guò)程中提供下附加信息，如配置信息，IP地址，端口號(hào)等。不過(guò)其作為SD報(bào)文的一部分也存在著自身的字段內(nèi)容。

AUTOSAR將Option Array主要分為以下三種：

• Configuration Options：用于配置通信過(guò)程的必要的信息

• 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

接下來(lái)我們來(lái)對(duì)這三種Option進(jìn)行一一解讀。首先來(lái)看看Configuration Option的字段定義：

注意：configuration options僅適用于任意Service ID的Service Entry Array以及Service ID為0xFFFE的EventGroup Entry Array。

針對(duì)上述字段解釋如下表4所示：

對(duì)于那些非標(biāo)準(zhǔn)的SOME/IP 服務(wù)，由于不能夠被Service ID進(jìn)行標(biāo)識(shí)，此時(shí)就需要通過(guò)一個(gè)key “otherserv”的值來(lái)進(jìn)行標(biāo)識(shí)，這類服務(wù)則可通過(guò)使用0xFFFE作為Service ID同時(shí)附帶otherserv的value的configuration option來(lái)完成雙方的通信。

IPV4 Endpoint Option

如下圖15為IPV4 Endpoint Option的字段定義：

IPV6 Endpoint Option

如下圖16為IPV6 Endpoint Option的字段定義：

IPv4 Multicast Option

如下圖17為IPv4的Multicast Option各字段內(nèi)容定義：

IPv6 Multicast Option

如下圖18為IPv6的Multicast Option各字段內(nèi)容定義：

IPv4 SD Endpoint Option

如下圖19為IPv4 SD Endpoint Option的字段定義：

IPv6 SD Endpoint Option

如下圖20為IPv6 SD Endpoint Option的字段定義：

由于上述六種IPV4與IPV6字段內(nèi)容大體結(jié)構(gòu)一致，因此我們將該兩者放在一起來(lái)對(duì)各字段內(nèi)容進(jìn)行解釋說(shuō)明：

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是用來(lái)對(duì)當(dāng)總線CAN數(shù)據(jù)過(guò)大時(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ù)過(guò)大時(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)系又是如何的呢？

如下圖21所示，則較為清晰的表明了SOME/IP-TP在CP AUTOSAR的具體位置以及與其他模塊的交互關(guān)系：

從圖中可以直接看出SOME/IP-TP直接與PDUR層進(jìn)行交互，當(dāng)上層應(yīng)用模塊發(fā)送大量數(shù)據(jù)時(shí)，會(huì)通過(guò)PDUR發(fā)送數(shù)據(jù)給到SOME/IP-TP模塊進(jìn)行拆包，拆分的包將按照協(xié)議格式再通PPDUR模塊依次發(fā)送。

對(duì)于接收方而言，則是接收來(lái)自PDUR的報(bào)文，通過(guò)SOME/IP-TP模塊進(jìn)行組包，組包后的結(jié)果給到PDUR，然后由PDUR再傳輸至上層應(yīng)用模塊。

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

了解了SOME/IP-TP的主體功能以及大概的工作過(guò)程，接下來(lái)我們一起解析下SOME/IP-TP協(xié)議。

SOME/IP-TP作為SOME/IP報(bào)文的一種，因此前面的SOME/IP Header則保持一致，只是SOME/IP-TP存在自身的協(xié)議頭，讓我們一起來(lái)學(xué)習(xí)一下。

SOME/IP-TP協(xié)議頭

如下圖22為SOME/IP-TP層的協(xié)議頭字段內(nèi)容：

針對(duì)上圖中每個(gè)字段內(nèi)容地詳細(xì)解釋請(qǐng)參考上篇鏈接《一網(wǎng)打盡車載以太網(wǎng)之SOME/IP(上)》

其中Message Type更為細(xì)節(jié)地定義如下圖23所示：

• 當(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為未來(lái)預(yù)留，目前默認(rèn)為0即可；

其中More Segments Flag用來(lái)表示是否還有Segement報(bào)文，當(dāng)其值為1時(shí)表示還有剩余的Segement，當(dāng)其值為0時(shí)則表示沒(méi)有剩余的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ù)來(lái)實(shí)現(xiàn)數(shù)據(jù)SOME/IP序列化；

• 通過(guò)LdCom模塊間接調(diào)用SomeIpTp_Transmit來(lái)開(kāi)啟發(fā)送；

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

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

具體發(fā)送流程中的函數(shù)調(diào)用關(guān)系如下圖24所示：

Rx Path

針對(duì)被分割的segment，接收方需要通過(guò)下列幾個(gè)步驟進(jìn)行接收：

• 通過(guò)SoAd模塊來(lái)獲取來(lái)自總線的SOME/IP數(shù)據(jù)；

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

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

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

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

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