SOME/IP，全稱為Scalable service-Oriented MiddlewarE over IP，是用于控制消息的汽車中間件解決方案，是一種面向服務的可伸縮的協議。SOME/IP于2011年由BMW設計，2014年納入AUTOSAR規范。

SOME/IP的報文格式如下圖所示，由消息頭部(Header)和消息體(Payload)組成，Header主要包括以下字段：

Message ID，用于唯一標識消息，當消息為Method類型時，由Service ID和Method ID組成，當消息為Event類型時，由Service ID和Event ID組成，如下圖所示：

Length，消息長度(從Request ID開始到Payload結束)；

Request ID，服務提供者和調用者可用于區分相同消息的不同調用，由Client ID和Session ID組成，如下圖所示：

通常我們稱服務提供者為Service，服務調用者為Client，Service ID和Client ID用于區分，一般會在一個SOA架構中統一地配置這些ID的數值。

這里插播一點個人理解，在SOA中，每個服務就好像我們每一個人在社會中扮演的角色，在對別人提供著服務的同時，同時也享受著別人提供出來的服務，人與人之間，既是彼此獨立的，又是需要互相通訊的。服務提供者將功能具象為一組接口，這樣使用者就能知道如何調用服務，完成某件事情，得到某個結果。

Protocol Version，協議頭版本號，目前該值必須為1；

Interface Version，接口版本號，一般由服務提供者定義；

Message Type，用于標識消息的類型，如下圖所示：

消息類型和通信機制之間的映射關系，如下圖所示(靈魂畫手，將就看吧)，不難發現，Field結合了Method和Event，這也就理解了Message ID中為什么只有Method ID和Event ID，沒有Field ID。Field可以用于實現這樣一種通信場景：客戶端希望能夠獲取/設置/監聽服務端的某一個狀態值，圖中SOME/IP-SD

Return Code，用于標識請求是否成功處理，不同的消息類型，它們在傳輸時所攜帶的Return Code也不同：

具體返回值和錯誤碼定義如下：

Payload，也叫有效載荷，是消息內容，通常它的長度是可變的。SOME/IP協議在OSI七層網絡結構中位于應用層，它建立在TCP或者UDP傳輸層協議之上。當通過UDP傳輸時，由于UDP的限制，Payload的長度應該限制在1400字節以內，超了則要分組(SOME/IP-TP)，而當通過TCP傳輸時，可以傳輸更多的字節，理論上只要不超過Length字段的大小即可。

對于AUTOSAR系統，Payload要遵循AUTOSAR規范進行序列化，對于非AUTOSAR系統，可以遵循AUTOSAR規范進行序列化，也可以采用其他序列化方式如常用的Google Protocol Buffer、JSON等。

以上介紹了SOME/IP協議，可以發現，SOME/IP其實并不等同于SOA，只能說要實現SOA，SOME/IP是一個很不錯的協議選擇。

審核編輯：劉清