1. 背景

SOME/IP是一種汽車中間件解決方案，其全稱是Scalable Service-Oriented Middleware over IP，即位于 IP 協議層以上的一種面向服務的可擴展的中間件。

• 中間件：該術語起源于復雜的軟件系統開發，用以實現軟件組件之間的數據交換，這種數據交換通常需要經由網絡，中間件的任務就是確保需要交換數據的軟件組件在網絡中透明地傳輸數據。SOME/IP 作為一種中間件負責組織傳輸復雜數據（消息傳遞）并約定軟件組件之間的函數調用（遠程過程調用，RPC）。
  如今汽車中的軟件數目十分龐大，并且還會隨著汽車內部功能和系統的分布擴張而不斷增加。這些分布式功能可能使用到一個 ECU 中的不同進程，也可能擴展到不同 ECU 的各種進程中去，隨著系統復雜度的增加，不可能僅僅將消息放入到網絡中傳輸就完成功能的實現，還需要使用 RPC 來正確控制這些分布式功能；另外，不同 ECU 可能使用不同的軟件架構以及操作系統，因此還需要中間件來橋接不同的便攜式操作系統接口（如 Linux 或 QNX 和 AUTOSAR 系統之間的銜接）。
• 可擴展性：表示 SOME/IP 能夠實現不同硬件平臺、不同操作系統或嵌入式固件以及不同應用軟件的異構設備之間的可擴展性和互操作性。
• 面向服務：面向服務通信的概念是與傳統汽車電子行業中的面向信號通信相對應的一個概念，面向服務通信是僅當客戶端請求或服務器通知特定訂閱者時，才在客戶端與服務器間交換數據。這確保了不會浪費帶寬，并且僅在需要的時間進行數據通信。
  高端信息娛樂系統最需要基于服務提供的復雜接口，如復雜的數據類型、對數據庫的訪問、列表的傳輸等。在其他使用車載網絡的系統中，CAN 總線的使用仍占主導地位，信息在網絡中傳輸，由接收器決定如何處理該信息。但是，在新型應用領域，如輔助駕駛領域，CAN 的通信方式越來越不適用。另外，在 CAN 中，數據長 8Byte，且沒有大量的頭信息，這些均限制了 RPC 或服務發現( Service Discovery , SD ）的使用。
• 位于 IP 協議層以上：這表明了 SOME/IP 協議在汽車以太網協議棧中所處的位置，汽車以太網協議棧總共可劃分為五層，分別為物理層、數據鏈路層、網絡層、傳輸層、應用層，SOME/IP 協議是一種應用層協議。
  SOME/IP 是一種汽車中間件解決方案。從一開始就被設計為能夠完美適配不同尺寸和不同操作系統的設備，像是小型 ECU 如攝像頭、 AUTOSAR ECU、以及信息娛樂 ECU 如車載信息娛樂系統（Head Units），還有遠程通信設備等，都可以使用 SOME/IP 協議有效地交換 ECU 間的消息。同時 SOME/IP 還支持信息娛樂領域的功能以及車輛中其他領域的功能，使 SOME/IP 能夠用于 MOST 以及更傳統 CAN 方案的替換方案。

2. SOME/IP協議

2.1 面向服務的通信

區別于傳統 CAN/LIN 等面向信號（Signal-Oriented）的通信方式，SOME/IP 提供面向服務（Service-Oriented）的通信方式。

• 面向信號的通信——為了將信號進行傳輸；
  • 基于信號的通信解決方案中的軟件和硬件緊密耦合，ECU 之間的通信是靜態定義的。
  • 基于信號的通信是一種根據發送者需求實現的通信過程，當發送者發現信號的值變化了，或者發送周期到了，就會發送信息，而不考慮接收者是否有需求。
• 面向服務的通信——為了對服務的相關信息進行傳輸。
  • 發送方僅在接收方需要時才發送數據。優點在于總線上不會出現過多不必要的數據，從而降低負載，不過這僅僅是基于服務通信的一方面。當談論到自動駕駛、ADAS、聯網汽車等時，面向服務的架構 (SOA) 是必不可少的。在以太網和 SOME/IP 的支持下，SOA 將整個系統建模為 service interface，可以輕松地將新軟件添加到系統中，而無需擔心與其他軟件的兼容性。
    

SOME/IP 為應用程序提供抽象的面向服務的接口，因此，應用程序不需要處理 IP 地址和端口，而只需要處理服務。Server 端提供了一個實現服務接口的服務實例（服務接口，直白理解就是服務與外界通信的接口，也就是服務模塊與外界溝通的基本出入口）。Client 端則通過SOME/IP 方式使用服務實例。

2.2 SOME/IP通信機制

• Request & Response Method（雙向方法）：客戶端發送請求，服務端回復響應，是一種有問有答的對話方式。
• Fire & Forget Method（單向方法）：客戶端發送請求，服務端不需要響應，是一種只問不答的對話方式。
• Event（事件）：客戶端首先使用了 SOME/IP-SD 訂閱（Subscribe）某一事件組（Event Group），當事件組中包含的事件發生之后，服務端就會自動給訂閱了該事件的客戶端發送相關的通知（Notification），Notification 消息不需要接收方進行回復。請注意，SOME/IP 協議中的 Event 總是分組在一個 Event Group 中,因此只能訂閱 Event Group 而不是Event本身。
• Fields（字段）：Field 表示可以遠程訪問的“屬性”，即客戶端可以遠程訪問的服務端中的變量。

2.3 SOME/IP協議報文格式

SOME/IP 協議在 OSI 七層網絡結構中位于應用層，從功能上講，SOME/IP是一種將服務接口進行打包或解包的中間件：從應用層發送的數據按照 SOME/IP 的格式打包后，再傳遞到下層的 TCP/IP 或 UDP/IP層，再進行逐層打包和封裝，最終通過物理層以比特流的形式進行傳輸；接收時則按照與打包相反的規則進行解包。

2.3.1 Message ID [32 Bit]

Message ID 用于唯一標識服務的 Method 或 Event，可區分不同的服務。Message ID 對于整個車輛系統來說必須是唯一的 。
Message ID 的結構：

• 前 16 位是 Service ID，每個服務需要有一個唯一的服務 ID，由系統集成商進行標識。
• 后 16 位是 Method ID。
  對于 Method ，Message ID 的結構如下：
  
  其中 Method ID 的第一個位（bit）是 0。使用 16 位的 Service-ID 和從 0 位開始的16位的 Method-ID (對于實際值，Method-ID中還剩下15位)，這將允許最多 65536個服務，每個服務最多 32768 個方法。
  對于 Events 和 Notifications ，Message ID 的結構如下：

對于 Events 來說，Method ID 的第一個位（bit）是 1。這意味著每個服務最多可以有32768 個事件或通知。

Method ID 的最高位可用來判斷具體的通信方式，即采用的是 Method 還是Event 。

2.3.2 Length [32 Bit]

Length 字段長度為 32位，包含從 Request ID 開始到 SOME/IP 消息結束的長度，長度是以字節為單位的。注意，Length 不包括 Message ID 和 Length 。

2.3.3 Request ID [32 Bit]

Request ID 是客戶端的唯一標識符，要能在響應到達前或超時前不被重用。

• 在生成響應消息時，服務器必須將 Request ID 從請求中復制到響應消息中去，這才使得客戶端可以將響應對應到發出的請求上。
  Request ID 前 16 位是 Client ID，用來區分特定的客戶端，在整車系統中該值必須唯一；后 16 位是 Session ID，用來標識同一客戶端的多次請求。
  

Session ID 主要用于 Request & Response 類型的多次調用，每調用一次，Session ID 增加 1。
如果會話不在活動狀態，Session ID 設置為 0x0000，當會話處于活動狀態時，Session ID 設置為 [0x0001, 0xFFFF] 范圍內的值。當 Session ID 為 0x0000 時，服務器并不會對這個請求作出反應。

2.3.4 Protocol Version [8 Bit]

該字段存放 SOME/IP 協議的版本號，用來識別使用的 SOME/IP 頭格式（不包括 payload 的格式）。目前固定為 1。

2.3.5 Interface Version [8 Bit]

該字段存放服務接口的版本號，用來識別服務接口的主版本號。

2.3.6 Message Type[8 Bit]

Message Type 字段用于區分不同類型的消息

2.3.7 Return Code [8 Bit]

Return Code 用來表示請求是否被成功處理。為了簡化 header 布局，每個消息中都會傳輸 Return Code 字段。

2.3.8 Payload [variable size]

Payload 由 Event 的數據元素或 Method 的參數組成，大小取決于所使用的傳輸層協議，對于UDP，payload 介于 0 到 1400個字節之間，由于 TCP 支持 payload 分段，所以支持更大的長度。
注意：SOME/IP 所有的 Header 字段必須以網絡字節順序(大端字節序)編碼。Payload 內參數的字節順序應由配置來定義。