前言

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

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

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

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

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

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

正文

總體介紹

正如之前文章一文入門車載以太網(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é)議的全部內(nèi)容，是研究SOME/IP協(xié)議的必經(jīng)之路。

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

產(chǎn)生背景與動機

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

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

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

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

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

• 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同時添加針對大量UDP數(shù)據(jù)包的SOME/IP-TP協(xié)議以及其他SOME/IP-SD的優(yōu)化工作；

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

什么是SOME/IP

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

• Scalable

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

• service-Oriented

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

• MiddlewarE

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

• over IP

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

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

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

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

如上圖可知，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é)議與各個模塊的交互關(guān)系會在后續(xù)文章講到，提及于此讓大家對SOME/IP協(xié)議與AUTOSAR協(xié)議棧的關(guān)聯(lián)有個整體概念，此文中不做過多展開。

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

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

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

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

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

SOA

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

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

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

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

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

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

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

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

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

SOME/IP協(xié)議解析

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

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

如下圖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開始至SOME/IP報文結(jié)束。

Message Type

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

Return Code

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

SOME/IP通信機制

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  

• Notification Event通信模式；

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

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

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

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

  

  圖9 Field的通信模型

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

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

SOME/IP錯誤處理機制

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

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

• 消息類型0x80，Response信息，即可以通過Response Message中的Return Code來定位到問題所在；

• 消息類型0x81，顯式的錯誤信息；

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

Entry Array

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

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

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

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

對上述Service Entry Array定義的各個Field解釋說明如下表2所示：

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

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

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

Option Array

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

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

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

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

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

Configuration Options

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

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

針對上述字段解釋如下表4所示：

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

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)一致，因此我們將該兩者放在一起來對各字段內(nèi)容進(jìn)行解釋說明：

SD 狀態(tài)機

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

SOME/IP-TP主體功能

我們知道CAN-TP是用來對當(dāng)總線CAN數(shù)據(jù)過大時，就需要對CAN整包數(shù)據(jù)進(jìn)行分割拆包進(jìn)行發(fā)送，這個時候發(fā)送方的TP層就起作用，同理對于接收方而言，也需要將分割的數(shù)據(jù)包進(jìn)行組包完成整包數(shù)據(jù)的重組還原。

因此，舉一反三，我們便可以知道SOME/IP-TP模塊的主體功能就是為了實現(xiàn)對應(yīng)用層發(fā)送數(shù)據(jù)過大時進(jìn)行的必要拆包與組包的工作，進(jìn)而完成大量數(shù)據(jù)包的發(fā)送與接收。

SOME/IP作為一種應(yīng)用層協(xié)議，既可以運行在TCP之上，也可以運行在UDP之上，由于TCP協(xié)議本身支持發(fā)送大量數(shù)據(jù)同時還支持流控等特點因此無需用到SOME/IP-TP,該協(xié)議僅針對運行在UDP協(xié)議基礎(chǔ)上的SOME/IP協(xié)議。

該模塊作為AUTOSAR中定義的標(biāo)準(zhǔn)模塊，在AUTOSAR中與各個模塊的交互關(guān)系又是如何的呢？

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

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

對于接收方而言，則是接收來自PDUR的報文，通過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報文的一種，因此前面的SOME/IP Header則保持一致，只是SOME/IP-TP存在自身的協(xié)議頭，讓我們一起來學(xué)習(xí)一下。

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

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

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

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

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

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

其中Offset Field 表示當(dāng)前已發(fā)送或者接收的數(shù)據(jù)量，其基本單位為16Byte，如該值等于92，表示截至目前為止已發(fā)送了92X16=1472字節(jié)長度的Payload。同時該長度并不包含SOME/IP header的長度。

其中Reserved Field為未來預(yù)留，目前默認(rèn)為0即可；

其中More Segments Flag用來表示是否還有Segement報文，當(dāng)其值為1時表示還有剩余的Segement，當(dāng)其值為0時則表示沒有剩余的Segement，當(dāng)前Segement就是最后一條。

Tx Path

對于發(fā)送一個基于UDP完整的SOME/IP報文而言，報文的發(fā)送需要經(jīng)歷以下幾個模塊：

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

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

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

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

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

Rx Path

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

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

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

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

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

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

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