前言

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

你知道什么是SOME/IP嗎？

你知道為什么會產生SOME/IP即相關背景嗎？

你知道SOME/IP與SOA又有著哪些千絲萬縷的聯系呢？

SOME/IP在實踐中到底應該如何使用呢？

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

正文

總體介紹

車載以太網協議棧總共可劃分為五層，分別為物理層，數據鏈路層，網絡層，傳輸層，應用層，其中今天所要介紹的內容SOME/IP就是一種應用層協議。 SOME/IP協議內容按照AUTOSAR中的描述，我們可以更進一步的拆分為三類子協議：應用層的SOME/IP標準協議，SOME/IP-SD協議以及TP層的SOME/IP-TP協議，這三部分內容相輔相成，完整詳細的闡述了SOME/IP協議的全部內容，是研究SOME/IP協議的必經之路。 由于SOME/IP協議內容較多且關聯復雜，為了讓大家對SOME/IP有一個循序漸進的了解過程，限于篇幅本文將主要講解應用層的SOME/IP標準協議，其他協議內容會在下篇繼續給大家分享，敬請大家多多關注！

產生背景與動機

2011年寶馬公司開發設計了一套中間件，該中間件能夠實現以服務為導向的通信方式，該中間件區別于傳統以信號為導向的通信方式，不僅能夠大大減少網絡負載以提高通信雙方的效率，同時引入以太網通信也能夠大大滿足未來車輛不斷增長的通信需求。 面向信號的數據傳輸不管網絡需不需要始終會不斷循環發送，而面向服務的通信方式則不同，只有當網絡中至少存在一個接收方需要這些數據時，發送方才會發送數據，這是一種面向服務通信方式的顯著優點。 寶馬將該面向服務的通信方式叫做SOME/IP(全稱為：Scalable service-Oriented MiddlewarE over IP)。正如其名，可見該協議跟以太網密切相關。 沒錯！SOME/IP就是運行在車載以太網協議棧基礎之上的中間件，或者也可以稱為應用層軟件。 SOME/IP正由于其知名度逐漸被AUTOSAR接納并計劃納入其正式標準，并且在2014年集成進AUTOSAR 4.X中，幾個關鍵發展節點如下：

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

AUTOSAR 4.1 - 支持SOME/IP-SD及其發布/訂閱功能；

AUTOSAR 4.2 - 添加transformer用于序列化以及其他相關優化；

AUTOSAR 4.3 - 修復一些transformer bug同時添加針對大量UDP數據包的SOME/IP-TP協議以及其他SOME/IP-SD的優化工作；

持續優化中。。。。。。

什么是SOME/IP

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

Scalable 該協議設計的初衷之一就是為了實現不同硬件平臺、不同操作系統或嵌入式固件以及不同應用軟件的異構設備之間的可擴展性和互操作性。

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

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

over IP 它也是一個基于以太網的協議。它使用類似的硬件接口，確保高達 100Mbps 的帶寬。同時數據通過中間件（即應用層）通過網絡電纜使用 TCP/IP 或 UDP 協議進行通信。 當客戶端需要來自服務器的數據時，它可由客戶端使用 TCP 協議進行請求。如果服務器必須將數據傳送給所有活動的訂閱者，則可通過 UDP 協議傳輸。UDP 協議上的數據通信可以是單播、多播或廣播。

如下圖1所示，就十分清晰地展示了SOME/IP在車載以太網協議棧中的位置以及與其他模塊的關系： 圖1 SOME/IP 與車載以太網協議棧關系 那么在AUTOSAR協議棧中，SOME/IP協議又處于一個什么樣的位置呢？如下圖所示： 如上圖可知，SOME/IP協議涉及到與RTE，COM，PDUR以及SOAd這些AUTOSAR標準模塊的交互，而用于服務發現的SOME/IP-SD則涉及到BswM，SD以及SoAd模塊的交互。 SOME/IP協議與各個模塊的交互關系會在后續文章講到，提及于此讓大家對SOME/IP協議與AUTOSAR協議棧的關聯有個整體概念，此文中不做過多展開。 SOME/IP 最初是作為另一種 RPC 機制開發的，以確保與 AUTOSAR 設備的兼容性并提供汽車用例所需的最大功能，同時它也是專為ECU間客戶端-服務器序列化而設計的網絡層協議。 目前，該協議可以在多種不同的操作系統上實現，包括AUTOSAR、OSEK 和 GENIVI。它也可以在不運行操作系統的嵌入式固件上實現。 攝像頭、主機、遠程信息處理設備、AUTOSAR 設備，甚至信息娛樂系統等大型設備，都可以使用 SOME/IP 協議有效地交換 ECU 間消息。自Wireshark 3.2SOME/IP 發布以來，SOME/IP 支持就已公開，可以在 Wireshark 上解析SOME/IP數據。 綜上所述，我們便可以總結出SOME/IP作為一種面向服務的通信協議，一種基于車載以太網協議棧基礎上的應用層協議的基本特點有哪些，如下表1所示展現了SOME/IP協議的五大基本特點： ? 表1 SOME/IP協議五大基本特點

SOME/IP與SOA的關系

SOA SOA簡而言之就是一種面向服務的架構(Service-Oriented Architecture), 當然也是一種軟件設計的重要方式，IT研究與顧問咨詢公司 Gartner 在 1996 年提出的，其本身并不是新鮮概念，而且已經在IT互聯網領域風靡了20余年。 按照W3C對它的定義 : “SOA是一種應用程序架構，在這種架構中，所有功能都定義為獨立的服務，這些服務帶有定義明確的可調用接口，能夠以定義好的順序調用這些服務來形成業務流程。 服務：服務是一種比構件粒度更大的信息集合，實際是包含實現了多個關聯業務需求的邏輯組合，并且允許每個服務使用特定的平臺，架構或技術方案； 可調用接口：面向服務的接口不同于構件的接口，他的實現與特定語言無關，與特定的平臺也無關，可十分方便的實現不同異構平臺的交互； 聯系與區別：

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

由于SOME/IP本身也是一種面向服務的協議，所以一般認為SOME/IP只不過是一種實現SOA可行的協議選擇；

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

可以通過SOME/IP用來實現SOA，但SOA的實現卻不一定非得用SOME/IP;

SOME/IP協議解析

接下來就讓小T帶領大家通過解析SOME/IP一起來揭開SOME/IP的神秘面紗！，以便為后續車載以太網的學習打好基礎。

相關標識符與版本說明

如下圖2所示為SOME/IP協議的Header結構體： 圖2 SOME/IP協議Header 如上圖中標記的Message ID，Request ID, Protocal Version 以及Interface Version的詳細解釋如下表2所示： 表2 相關標識符與版本說明 ? Length Length正如上圖2所示，其涵蓋的范圍是Request ID開始至SOME/IP報文結束。

Message Type

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

Return Code

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

SOME/IP通信機制

認識完了SOME/IP協議標準的詳細定義內容之后，接下來就需要來探討車載ECU需要按照何種規則來實現數據的傳輸，因此熟悉這部分內容將對車載以太網SOME/IP的開發與測試至關重要。

服務發現(Service Discovery)

服務發現的通信機制是通過SOME/IP-SD協議實現的，主要是為了實現在車載以太網中告知客戶端當前服務實例的可用性及訪問方式，可通過Find Service 和Offer Service來實現。 在通過SOME/IP協議傳輸數據之前，我們需要知道當前整個車載網絡到底存在哪些服務，服務的可用性如何，客戶端如果訂閱服務端所提供的服務。 由于SOME/IP-SD協議也是一塊十分重要的內容，在此就不過多展開，僅簡要介紹其基本功能與作用機理，后續會單獨介紹SOME/IP-SD協議的具體內容，敬請關注！ 如下圖5所示即為SOME/IP-SD的基本功能，展現了Client與Server之間的交互關系。 ? 圖5 SOME/IP-SD Client與Server交互關系圖 由上圖可知，SOME/IP 服務發現流程可以分為以下三大基本步驟：

Client通過發送Find Service的報文去尋找車載網絡中可用的服務實例；

Server接收到Client的Find Server后通過UDP發送Offer Service響應；

Client通過發送Subcribe Event Group去訂閱相關Event；

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

Client成功訂閱相關事件后，Server會按照事件本身屬性來實現對已訂閱該事件的Client的發布；

遠程進程調用(RPC)

遠程進程調用主要可分為四種通信模式：

Request/Response通信模式，可歸納為Method中的一種；其基本通信模型如下圖6所示： Request-Response模型作為一種最為常見的通信方式，其主要任務就是客戶端發送請求信息，服務端接收到請求，進行相關處理之后進行相應的響應。

? 圖6 Request-Response通信模型

Fire&Forget通信模式，可歸納為Method中的一種； 該通信模型的主要任務就是客戶端向服務端發送請求，服務端無需進行任何響應，有點類似診斷服務中的抑制正響應。

圖7 Fire&Forget通信模型

Notification Event通信模式； 該通信模式主要描述了發布 /訂閱消息內容，主要任務就是為了實現客戶端向服務端訂閱相關的事件組，當服務端的事件組發生或者值發生變化時，就需要向已訂閱該事件組的客戶端發布更新的內容。

? 圖8 Notification event通信模型 ?

遠程進程控制(Field) 訪問進程通信機制主要是為了實現針對對應用程序的數據獲取與更改，主要任務就是實現客戶端通過Getter獲取Server的值，通過Setter設置Server的值。 Field就可理解為一個Service的基本屬性，可包含Getter，Setter，Notifier三種方式。其中Getter就是讀取Field中某個值的方法，Setter就是一種改變Field值的方法，而Notifier則是一種當Field中的值發生變化的觸發事件。 ? 圖9 Field的通信模型

由上圖可知，在Getter與Setter的方式中我們使用的Request/Response機制。在Getter的請求報文中是一個空的Payload，響應報文中的Payload才是需要獲取的值；使用Setter請求時，請求消息中的Payload則是要設置的值，如果設置成功，那么響應報文中Payload就是設定成功的值。 同時我們也可得出服務實體在SOME/IP協議中是一個十分重要的概念。一個服務實體可以是Field，Events以及Method的任意組合。

SOME/IP錯誤處理機制

在任何通信過程中總是會存在各種各樣的 錯誤，SOME/IP作為一種面向服務的應用協議也不例外，因此AUTOSAR為了更為高效的定位到通訊過程中的問題所在，因此制定了一套檢查SOME/IP協議格式內容的錯誤處理機制。 比如版本信息檢查，服務ID等，其他故障信息可以在Payload中進行詳細定義。目前SOME/IP支持以下兩種錯誤處理機制，這兩種uowu處理機制可以根據配置進行選擇。

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

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

如下圖10為SOME/IP處理一般性錯誤的基本流程： ? 圖10 SOME/IP錯誤處理流程 ? 如果大家想進一步學習SOME/IP協議棧內容具體如何實現，可以參考由BMW公司主導在GitHub上的開源代碼，在GitHub中搜索"vsomeip"關鍵字便可找到對應的開源代碼學習。 值得注意的是vsomeip是一種基于Linux平臺采用C++語言進行開發的SOME/IP協議棧。