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

01.以太網(wǎng)引入汽車 ?

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

總線拓撲結(jié)構(gòu)問題，由于MOST總線必須是環(huán)形拓撲，這意味在測試儀和網(wǎng)關(guān)之間必須添加另外一個拓撲環(huán)，或者在連接測試儀前接一個臨時的擴展環(huán)，這增加了復雜性。

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

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

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

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

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

必須為開發(fā)基于汽車的協(xié)議棧和驅(qū)動程序。

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

SOME/IP 的一些主要特點：

序列化和反序列化：將數(shù)據(jù)結(jié)構(gòu)轉(zhuǎn)換成字節(jié)序列或者將字節(jié)序列轉(zhuǎn)換為數(shù)據(jù)結(jié)構(gòu)，這樣有利于數(shù)據(jù)的高效傳輸。

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

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

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

在2014年，SOME/IP正式被集成進AUTOSAR 4.X，并且得到了持續(xù)的發(fā)展和完善：

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

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

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

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

SOME/IP協(xié)議

? SOME/IP協(xié)議首先定義了報文的格式，如下圖所示。 ?

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是客戶端和服務器之間通信過程中每次調(diào)用的標識，可以根據(jù)不同的應用場景，決定是否使用Session ID。 ?

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

Message Type

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

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

Return Code

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

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

Payload?：數(shù)據(jù)段，用于放置需要傳輸?shù)臄?shù)據(jù)。 ?

03.序列化

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

序列化示例(來源AUTOSAR) ?

04.SOME/IP通信機制

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

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

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

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

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

? 3. Event

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

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

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

4. Field

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

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

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的第一個字節(jié)為標志字段，其高三位從高到低依次為重啟標志位、單播標志位和初始數(shù)據(jù)控制標志位，低五位為預留位。 ?

Entry 陣列

? 服務發(fā)現(xiàn)是通過SD報文中的Entry陣列字段攜帶的不同類型Entry來實現(xiàn)的，

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

Option 陣列

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

06.SOME/IP SD通信機制

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

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

客戶端狀態(tài)跳轉(zhuǎn)圖?(來源知網(wǎng))

編輯：黃飛

?