1.什么是someip？

2011年，寶馬提出和設計了Someip，SOME/IP全稱Scalable service-Oriented Middleware over IP，即基于IP的可擴展面向服務的中間件。因此，從Someip的名字出發，有三個典型要素：

因此，要了解Someip，首先得理解Someip為什么要具備三個典型要素。

1.1 面向服務

提到面向服務，很多人會聯想到面對對象編程的C++與python語言，someip的面向服務與python語言中的“類”是一致的，即把方法以及數據抽象出來，供多方使用。

即someip通信的本質是：一個控制器通過服務的方式使用另一個控制器的方法或者數據。

以車內溫度值獲取方式為例：

在基于can通信的電器架構中，一個特定的功能就需要一個人特定的信號。比如對于車窗控制功能，就需要一個can信號來表示車窗的上升與下降。當需要控制車窗上升時，對應的can信號的將設置為上升，并且周期發送。

基于can信號開啟車窗

在基于Someip通信的電器架構中，一個特定的功能將被抽象成“服務”。這服務中可以有多種不同的方法，比如：車燈控制器服務，喇叭控制服務等。當需要控制車窗上升時，只需要通過將服務中的車窗控制方法設置為上升，并且只需要發送一次即可。

基于Someip信號開啟車窗 那基于服務的通信方式有什么優勢呢？

基于服務的通信方式的最大優勢在于可擴展性強，便于更新。舉個例子：

如果在車內有另一個控制器ECU3也需要對車窗升降進行控制，比如語音控制車窗。

1）如果使用Can通信，那么需要增加哪些工作呢？

l整車通信設計：增加Can網段或者Can信號（修改硬件或者修改通信矩陣），提供另一個車窗指令信號給ECU3使用。

lECU2軟件設計：ECU2需要專門為了ECU3設計對應的車窗控制邏輯，因此需要修改軟件。

2）如果使用Someip為基礎的面向服務的通信，需要增加哪些工作呢？

l整車通信設計：只需要在整車通信設計層面，增加ECU3消費ECU2車窗服務。

面向服務是將功能抽象成服務，如ECU2將車窗功能抽象成車窗控制服務，車內任意節點需要使用車窗控制服務，只需要給ECU2發送對應的服務someip報文，而ECU2對應的車窗邏輯代碼完全不需要修改。即面向服務的通信與信號完全解耦，擴展性強。 綜上所述，面向服務的通信將原子功能服務化，軟件功能邏輯與信號解耦，具有更強的可擴展性，降低修改需求時的成本。

1.2基于IP之上的協議

以太網是一種使用十分廣泛的協議，由標準的七層架構組成，但CP中的以太網其實僅用了5層協議，Someip為第5層協議。

以太網第一層是物理層，既可以理解為硬件層，在MCU的軟硬件系統中由Phy芯片完成。Phy芯片能對模擬信號與數字信號進行轉換，接收報文時，將模擬信號轉換成數字信號給MCU芯片處理；發送報文時，將數字信號轉換成模擬信號發送至以太網總線上。

以太網第二層是數據鏈路層。鏈路層即Mac層，規定了數據幀能被網卡接收的條件，最常見的方式是利用利用網卡的MAC 地址，發送方會在欲發送的數據幀的首部加上接收方網卡的MAC 地址信息，接收方只有監聽到屬于自己的MAC 地址信息后，才會去接收并處理該數據。以太網第三層是網絡層。每一臺搭載了以太網的ECU都需要定義ip地址，主機的網絡地址該如何定義，以及如何在網絡地址和MAC 地址之間進行映射，即ARP 協議；網絡層實現了數據包在ECU之間的傳遞。

以太網第四層是傳輸層。傳輸層主要是實現UDP以及TCP協議功能，在一個ECU內可能存在不同的應用程序，這些程序可能會使用到不同的IP地址，那么傳輸層就能區分數據包是屬于哪個應用程序的，即傳輸層可以實現數據包端到端的傳遞，即ECU1的應用程序至ECU2的應用程序。

Someip，Someipsd，Doip位于以太第五層應用層：Someip協議，，Someipsd協議，doip協議本質上是規定了對網絡層傳遞的數據的處理，適應了不同的應用場景。在CP中，實際上Soad，SD，Doip，Soemipxf都是在實現應用層功能。

1.3 通信中間件

中間件本來是在互聯網行業十分流行的術語，是基礎軟件一類，位于操作系統，網絡，數據庫之上，應用軟件的下層。作用是為處于自己上層的應用軟件提供運行與開發的環境，幫助用戶靈活、高效地開發和集成復雜的應用軟件。在不同的技術之間共享資源并管理計算資源和網絡通信。

中間件的核心思想在于“統一標準、分散實現、集中配置”。Someip這套協議具備了中間件的顯著特征，能夠運行于車內不同的操作系統之上，并且能滿足同一套標準協議。

2.SOMEIP服務化通信

在面向服務的Someip通信中，Someip提供了三種接口將幫助使用者將原子功能服務化：

事件Events:事件通知主要提供事件型的接口，該事件可以是突發型的事件，也可以是周期性的事件。

方法Methods:遠程過程調用, 主要用于遠程調用方法。

字段Fields:訪問進程數據（Field）。訪問進程通信機制主要是為了實現針對對應用程序的數據獲取與更改

看完上面對于someip接口的解釋，相信很多人還是對這些官方的抽象解釋一臉疑惑，接下來為大家提供接地氣的描述。

2.1 設定不同Someip接口的目的

本質上一個服務抽象的是一個大功能，每個功能會有不同的子功能以及不同的應用場景，所以就需要不同的接口滿足不同場景需求。

以上文中提到的車窗服務為例，如果車窗服務有如下使用需求：

需求1：某ECU需要ECU2周期性提供車窗開度狀態信息。

需求2：某ECU需要ECU2在車窗開度信息有變化時提供車窗開度信息。

需求3：某ECU在有需要時遠程單次獲取車窗開度信息。

需求4：某ECU需要設置當前的車窗開度信息

需求5：某ECU需要直接開關車窗

上面的不同功能需求都可以通過Someip提供的三種接口實現。

需求1：該需求為需要提供周期性事件信息，選Event接口。

需求2：該需求為需要提供突發型事件型的數據，選Event接口。

需求3：有需要時獲取數據，即訪問進程中的內容，選Field接口。

需求4：設置當前的車窗開度信息，也是訪問進程中的內容，選Filed接口。

需求5：直接開關車窗，實現車窗的遠程控制，需要遠程調用開關服務，這是典型的遠程調用，選Method接口。

看到這兒，大家是否對Someip接口有所認識，本質上Method/Event/Filed都是上層的概念，用以體現服務中子功能的特征，根據子功能的特點選擇合適的接口。

比如事件型的子功能選Event，過程訪問（比如車輛運行過程中獲取空調溫度，設置空調溫度）選Filed，遠程調用（比如App遠程直接控制空調開關）選Method。

2.2 Someip服務的通信機制

Method/Event/Filed三個接口只是上層概念，是對于功能層面概念的抽象，在整車架構中實現這幾種概念，還需要通信機制的支撐。

比如：打工仔有很好的針對業務上的建議（Method/Event/Filed），需要獲取領導的資源支持，那么就需要使用PPT進行匯報，PPT就是底層的通信機制。

Someip提供了三種通信方式：

l請求/響應

l請求不響應

l服務發現/訂閱發布

上述三種方式對應著四種真正的通信機制：

lRequest/response

lFire&Forget

lNotification

lGetter/Setter

通信方式描述的是通信機制的特點，通信機制是支撐Someip接口功能實現的底層通信機制。

通信機制有如下圖中的對應關系，下面將介紹各接口中的通信機制。

1）Method

Method的特點是遠程調用，根據是否需要服務端發出響應報文可以分為兩類：

1.請求響應，即Request/Response機制

簡而言之，Client端（某個ECU）有需求的時候，向Server端（某個ECU）發送Request請求Someip報文，Server接收報文后處理該請求，并向Client端發送響應Someip報文，響應Someip報文中將攜帶請求處理結果。

2.請求不響應，即Fire/Forget機制

Fire/Forget機制相對于Request/Response機制，區別在于前者不需要Server端發送響應報文，而后者需要。

2）Event

Event服務接口支持的通信機制是Notification，有如下特性：

l由Server向Client發送報文

l可周期性發送或者根據事件狀態（值改變或者特定條件滿足）發送通知類消息。

l在Server端發送報文之前，需要Client端先對服務進行訂閱。

3）Field

Field訪問進程通信支持了三種通信機制，Notification，Getter，Setter三種。

1.Notification

Filed支持Notification時，具有如下特性：

1）由Server端主動發送報文

2）在Server端提供的服務整個生命周期中，即在服務上線后的任意時刻，Server端可以Filed數據報文發送給Client端。Filed強調的是全生命周期的數據，Event強調的是變化的事件。

3）在Server端發送報文之前，需要Client端先對服務進行訂閱。

2.Getter

Client主動從Server端獲取field數據。

3.Setter

Client主動設置Server端的Field數據。

3.Someip的軟件實現

在AUTOSAR架構中，Someip服務化通信的實現需要依賴于底層以太協議棧與應用層的共同完成。

如上文所描述，服務接口的抽象由應用層完成，即Event，Filed,Method的抽象，具體的通信機制由以太棧支持。

即以太協議棧與Rte將完成數據的序列化與反序列化，報文的組裝與分解以及notify，RR，Getter/Setter等通信機制。

應用層SWC將完成Event與Method或者Filed特性的實現。

3.1 Method請求代碼實現

下圖為Method接口請求/響應中請求的代碼實現方式。

Request/Response中Request即是典型的請求。

實際上，Method接口中請求在AUTOSAR架構中體現為函數調用。Client向Server端通過Method接口請求車窗開啟，本質上就是，Client端向Server端請求調用對應的車窗控制函數，只不過函數調用請求需要通過Someip報文從Client端發送至Server端實現。

如下圖，Client端Rte_Call_OpenTheWindowMethod(State)執行后，Someip報文將此請求傳輸至Server端，Re_OpenTheWindowMethod被調用。

注意：Request/Response中Response的實現方式與Request一致，不同點在于變為Server端請求調用Client端中的函數。

3.2 Event主動發送代碼實現

下圖為Event服務接口在代碼中的實現方式。

在AUTOSAR架構中，Event實現的即為ECU間的數據傳輸。

Server端使用Rte_Write_WindowStateEvent(State)接口，通過Someip報文將State數據傳送給Client端，Client端通過Rte_read_WindowStateEvent(State)獲取數據。

注意：Fire/Forget.Field之notifation的實現機制與Event一致。

總結

本文對Someip的來源本質，Someip的服務化通信，以及Someip服務化通信在AUTOSAR中代碼實現方式做了詳細的介紹，如果需要深入了解Someip，還需要對Someip的報文格式，SomeipSD的機制以及AUTOSAR的以太棧模塊進行學習。

審核編輯：劉清