SOME/IP是一種都有所耳聞的以太網的上層協議，但是其誕生歷史和協議內容都知道的不多吧！ ? SOME/IP的誕生是在以太網引入汽車之后更深入的發展，因此我們需要從車載以太網的歷史開始講起。 ?

01.以太網引入汽車 ?

2004年，寶馬汽車的OBD診斷口采用的是高速CAN總線，速率為500kbit/s，除去CAN協議本身的開銷，通過OBD口升級控制器的凈升級速度降到200kbit/s。而它預計到2008年，軟件更新的數據量會達到1GB，按照現在CAN的速度來算，更新一次軟件要16個小時，這個肯定是不能接受的。經過內部討論，將升級1GB數據的性能參數設置為15min，轉換為速度約為9Mbit/s，因此開始考慮引入新的刷寫總線。 ? 從當時現有的選擇來看，只有MOST、USB可選，雖然Flexray的速度可達10Mbit/s，但是2004年還沒有推出，要到2006年才被推出。 ? MOST總線，2004年那會兒還是MOST25，速度約7Mbit/s，勉勉強強夠格。是在2001年引入寶馬汽車中的，主要用于同步音頻通信。但是其存在一些缺點：??

總線拓撲結構問題，由于MOST總線必須是環形拓撲，這意味在測試儀和網關之間必須添加另外一個拓撲環，或者在連接測試儀前接一個臨時的擴展環，這增加了復雜性。

較高的資源需求，要實現7Mbit/s的最大帶寬，需要使用1014B的數據包，而且需要64個包組成一個塊(這個是MOST-high協議的一部分)，也就意味著光數據包的接收就需要64KB的RAM，在當時這個資源占太多了。

新接口，MOST25做升級，屬于全新的接口，與現有的不兼容，需要另做一套診斷應用程序，這也意味著成本高昂的問題。

USB作為消費類設備接口，其在PC上非常常見，因此是適合外部測試儀的，而且通信速度高達480bit/s，遠遠高于需求，但是其缺點太明顯： ?

魯棒性和抗擾性不充分，想要保證信號的完整性，USB需要昂貴的電纜和連接器。

USB最大支持的線纜長度為4m，難以覆蓋使用場景。

必須為開發基于汽車的協議棧和驅動程序。

上面這些已有的無法滿足需求后，寶馬開始研究以太網，因為以太網是一種被充分驗證的技術，并且有良好的基礎設施以及足夠的傳輸速度。 ? 在評估以太網在汽車上的適用性時，最關鍵部分是物理層，剛開始預計會像USB一樣，為了滿足魯棒性，需要高昂的線纜和接插件，寶馬通過將以太網連接線換成非屏蔽雙絞線，進行抗擾度進行測試，結果表明，非屏蔽線也滿足要求，沒必要做任何修改。 ? 從而寶馬開始了將以太網應用到車上，包括組織聯盟建立車載以太網標準，例如OPEN聯盟，著手基于以太網的上層協議，比如下面要講的SOME/IP。 ? 02.什么是SOME/IP？ ? SOME/IP 是 Scalable Service-Oriented Middleware over IP 的縮寫，由寶馬于 2011 年開發。這個名字清楚地表明它是一種中間件解決方案，可以在控制器之間實現面向服務的通信。更具體地說，SOME/IP 提供了廣泛的中間件功能，如序列化、遠程過程調用 (RPC)、服務發現和訂閱，以使 ECU 軟件能夠相互通信。 ?

SOME/IP 的一些主要特點：

序列化和反序列化：將數據結構轉換成字節序列或者將字節序列轉換為數據結構，這樣有利于數據的高效傳輸。

遠程過程調用 (RPC)：它是客戶端在需要來自服務器的一些數據時采用的一種數據交換方法。RPC 可能有也可能沒有返回值，即客戶端可以請求數據作為響應，或者簡單地調用一個函數來在服務器端執行某些任務。

服務發現：服務發現 (SD) 協議是 SOME/IP 概念的支柱。在面向服務的架構中，服務（功能實體-方法、事件或字段）必須是可發現的。SOME/IP SD 協議管理這個方面——是提供服務還是阻止它可用。

發布/訂閱：客戶端可以訂閱服務器的內容，從而可以動態地接收來自服務器的更新數據。SOME/IP 的發布/訂閱功能推斷客戶需要哪些數據（事件/字段）并共享相同的數據。Pub/Sub 由 SOME/IP SD 管理。

在2014年，SOME/IP正式被集成進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報文格式(來源AUTOSAR) ?

Message ID ? Message ID又通常叫報文ID，長度為32bit，包 含 Service ID 和 Method ID，各16bit，?每一個SOME/IP報文有唯一的報文ID，類似于CAN ID。當定義為Method時，Method ID的最高有效位值為0，當定義為Event時，Method ID的最高有效位為1，此時的Method ID又叫做Event ID。每一個服務應該由唯一的 Service ID作為標識；在同一服務， 不同的Method和Event也有唯一的Method ID或Event ID作為標識。 ?

長度(Length) ? 長度字段的長度為32bit，指的是從Request ID到Payload的長度。? ?

請求 ID(Request ID) ? Request ID的長度為32bit，由Client ID和Session ID組成。Client ID是客戶端/服務器的唯一標識；Session ID是客戶端和服務器之間通信過程中每次調用的標識，可以根據不同的應用場景，決定是否使用Session ID。 ?

協議版本(Protocol Version) ? 該字段長度為8bit，用來表示當前使用的協議的類型，該字段當前固定為0x01。

Message Type

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

Message Type表(來源?ADAS與ECU之吾見)

Return Code

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

Return Code定義表(來源?ADAS與ECU之吾見) ?

Payload?：數據段，用于放置需要傳輸的數據。 ?

03.序列化

? AUTOSAR對SOME/IP傳輸數據的序列化(數據結構轉換成線性字節序列，或反之，如下圖所示)也進行了標準化，除了支持AUTOSAR規定的基本數據類型(布爾類型、uint8、uint16、uint32,、sint8、sint16、sint32、float32和float64)之外，還支持包括結構體、聯合體、字符串、數組等復雜的數據結構的傳輸 。 ?

序列化示例(來源AUTOSAR) ?

04.SOME/IP通信機制

SOME/IP的通信機制包含遠程過程調用、Event和Field。遠程過程調用是指一個節點向另一個節點發送請求服務，這種方式又稱為Method，多用于客戶端向服務器發送控制命令，根據服務器是否有反饋分為Request/Response(R/R)和通信Fire&Forget(F&F)通信。 ? Event類似于CAN報文，用以發布狀態，根據實際的應用場景，可以有不同的發送方式。 ? Field用以表示某一功能的狀態量。可以通過Method發布控制命令，即Setter；也可以通過Method去請求獲取狀態，即Getter；在狀態發生改變時也可以發送通知，即Notification。 ?

1.Request/Response(R/R)通信

? ? R/R是一種有請求和響應的Method，意味著客戶端發送請求之后，服務端需要返回響應報文。 ?

Request/Response通信方式(來源知網) ? 2. Fire&Forge(T&F)通信 ? 客戶端向服務器發送請求報文，服務器不會有響應報文反饋。F&F通信中與R/R通信中的客戶端行為一樣，不同的是F&F通信時，請求報文的報文類型為REQUEST_NO_RETURN，而R/R的報文類型為RESPONS。 ?

Fire&Forget通方式(來源知網)

? 3. Event

SOME/IP中定義了3種不同的Event方式，分別是周期發送、值改變觸發

和值大于某一閾值觸發。SOME/IP中的Event在網絡中的發送是基于事件組傳輸的，要為定義的每一個Event分配事件組，同一個Event可以存在于不同的事件組，但不能定義空的事件組。Event的收發基于SOME/IP的發布和訂閱行為，在SD通信時，客戶端訂閱服務器的事件組，在正常的SOME/IP通信時，依據定義的發送行為，周期或者值改變觸發Event的發送。 ?

Event通信方式(來源知網) ?

4. Field

Field表示一種功能的狀態，可以用來表示某一狀態量，如車門、車窗等，對于Setter來說，請求報文的有效載荷中存放設置Field表示狀態量的控制命令?，對于Getter來說，請求報文的有效載荷為空，服務器通過識別請求報文的報文ID，然后將Field表示的狀態量放在響應報文的有效載荷中。Notification指的是Field表示的狀態量值，當Field表示的狀態量值發生改變或被外界觸發時發送Notification。 ?

Field通信方式(來源知網) ?

05.SOME/IP SD

? SOME/IP SD報文是一種特殊的SOME/IP報文，其報文格式和SOME/IP報文是一樣的。不同的是SOME/IP SD報文的SOME/IP報頭字段的報文ID、接口版本、報文類型和返回碼的值是固定不變的，SOME/IP SD報文的SOME/IP SD部分又包含了標志字段、預留字段、Entry和Option等字段，SOME/IP SD報文格式如下圖所示： ?

SOME/IP SD報文(來源AUTOSAR) ?

Flags

Flags的第一個字節為標志字段，其高三位從高到低依次為重啟標志位、單播標志位和初始數據控制標志位，低五位為預留位。 ?

Entry 陣列

? 服務發現是通過SD報文中的Entry陣列字段攜帶的不同類型Entry來實現的，

Entry用來同步服務實例狀態和處理事件組的發布和訂閱。依據SD 報文中Entry的作用不同將SD的報文類型分為七種，其中Find報文、Offer報文和Stop Offer報文基于不同的機制周期發送，用于同步服務實例的狀態；訂閱事件組報文、停止訂閱事件組報文、訂閱ACK報文和訂閱NACK報文用于處理事件組的發布和訂閱。 ?

Option 陣列

SD報文中的Entry通過引用Option陣列中的Option攜帶其他信息，如配置信息、傳輸協議、端口號和IP地址等相關信息。根據Option的作用不同，一般將Option分為配置Option、單播IP地址Option、多播IP地址Option和SD通信IP地址Option。配置Option用來傳輸服務名稱、協議類型、實例名稱等信息，IP地址Option分別表明節點通信單播、多播的地址信息和SD通信地址信息。 ?

06.SOME/IP SD通信機制

? ? SD中，不管是客戶端還是服務端，通信行為分為Down和Available，在Available下又分為Initial Wait階段、Repetition階段和Main階段。 ? 在Down階段，服務不可用。服務可用后會立即進入Initial Wait階段，該階段的作用一是避免流量突發，防止擁堵；二是可以將多個Entry放到一個SD報文中，降低報文數量。在Repetition階段，客戶端和服務器通過快速的發送Find和Offer報文實現服務消費關系的快速同步， 在Main階段，SD通信處于穩定狀態，為了降低SD報文的數量，定義客戶端不發送Find報文，而服務器以相對較慢的周期發送Offer報文。 ? 對于服務端來說，在Initial Wait階段的時間是在INITIAL_DELAY_MIN和INITIAL_DELAY_MAX之前的隨機值，當計數器超時后，開始發送第一個offer報文，并且進入Repetition階段，在這個時候，會定期發送REPETITIONS_MAX次offer報文。然后進入Main階段，在Main階段會 以 周 期 時 間 CYCLIC_OFFER_DELAY 周 期 性 發 送Offer報文。若收到客戶端發送的Find報文，服務器單播響應Offer報文。 ?

服務端的狀態跳轉圖?(來源知網) ? 對于客戶端來說，客戶端在Down階段不請求服務。若收到服務器發送的Offer報文，客戶端存儲該服務實例的狀態，并啟動該Offer報文的TTL計時器，此時若客戶端請求服務，直接進入Main階段。 ? 在客戶端需要請求服務后，進入Initial Wait階段。若收到服務器發送的Offer報文，取消計時器，直接進入Main階段；若沒有收到服務器發送的Offer報文，等待INITIAL_DELAY(位于INITIAL_DELAY_MAX和INITIAL_DELAY_MIN之間的隨機值)，計時器超時后，發送一個Find報文，進入Repetition階段。 ? 客 戶 端 在Repetition階 段 定期快速發送REPETITIONS_MAX次Find報文，若收服務器發送的Offer報文，停止當前階段的計數和計時，進入Main階段。 ? 在Main階段，SD通信已進入相對穩定的狀態，這里定義客戶端不發送Find報文，以降低SD報文數量。 ?

客戶端狀態跳轉圖?(來源知網)

編輯：黃飛

?