一、乙太網引入汽車

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。

二、什麼是SOME/IP？

SOME/IP 是 Scalable Service-Oriented Middleware over IP 的縮寫，由寶馬於 2011 年開發。這個名字清楚地表明它是一種中介軟體解決方案，可以在控制器之間實現面向服務的通訊。更具體地說，SOME/IP 提供了廣泛的中介軟體功能，如序列化、遠端過程呼叫 (RPC)、服務發現和訂閱，以使 ECU 軟體能夠相互通訊。

SOME/IP 的主要特點：

1、序列化和反序列化：將資料結構轉換成位元組序列或者將位元組序列轉換為資料結構，這樣有利於資料的高效傳輸。

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

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

4、釋出/訂閱：客戶端可以訂閱伺服器的內容，從而可以動態地接收來自伺服器的更新資料。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報文格式

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表

Return Code

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

定義表

Payload ：資料段，用於放置需要傳輸的資料。

三、序列化

AUTOSAR對SOME/IP傳輸資料的序列化(資料結構轉換成線性位元組序列，或反之，如下圖所示)也進行了標準化，除了支援AUTOSAR規定的基本資料型別(布林型別、uint8、uint16、uint32,、sint8、sint16、sint32、float32和float64)之外，還支援包括結構體、聯合體、字串、陣列等複雜的資料結構的傳輸 。

序列化示例

四、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通訊方式

五、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報文

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通訊地址資訊。

六、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報文數量。