什么是someip？如何發(fā)揮通信中間件的服務(wù)化作用呢？

1.什么是someip？

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

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

1.1 面向服務(wù)

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

即someip通信的本質(zhì)是：一個控制器通過服務(wù)的方式使用另一個控制器的方法或者數(shù)據(jù)。

以車內(nèi)溫度值獲取方式為例：

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

基于can信號開啟車窗

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

基于Someip信號開啟車窗 那基于服務(wù)的通信方式有什么優(yōu)勢呢？

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

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

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

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

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

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

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

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

1.2基于IP之上的協(xié)議

以太網(wǎng)是一種使用十分廣泛的協(xié)議，由標準的七層架構(gòu)組成，但CP中的以太網(wǎng)其實僅用了5層協(xié)議，Someip為第5層協(xié)議。

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

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

以太網(wǎng)第四層是傳輸層。傳輸層主要是實現(xiàn)UDP以及TCP協(xié)議功能，在一個ECU內(nèi)可能存在不同的應(yīng)用程序，這些程序可能會使用到不同的IP地址，那么傳輸層就能區(qū)分數(shù)據(jù)包是屬于哪個應(yīng)用程序的，即傳輸層可以實現(xiàn)數(shù)據(jù)包端到端的傳遞，即ECU1的應(yīng)用程序至ECU2的應(yīng)用程序。

Someip，Someipsd，Doip位于以太第五層應(yīng)用層：Someip協(xié)議，，Someipsd協(xié)議，doip協(xié)議本質(zhì)上是規(guī)定了對網(wǎng)絡(luò)層傳遞的數(shù)據(jù)的處理，適應(yīng)了不同的應(yīng)用場景。在CP中，實際上Soad，SD，Doip，Soemipxf都是在實現(xiàn)應(yīng)用層功能。

1.3 通信中間件

中間件本來是在互聯(lián)網(wǎng)行業(yè)十分流行的術(shù)語，是基礎(chǔ)軟件一類，位于操作系統(tǒng)，網(wǎng)絡(luò)，數(shù)據(jù)庫之上，應(yīng)用軟件的下層。作用是為處于自己上層的應(yīng)用軟件提供運行與開發(fā)的環(huán)境，幫助用戶靈活、高效地開發(fā)和集成復雜的應(yīng)用軟件。在不同的技術(shù)之間共享資源并管理計算資源和網(wǎng)絡(luò)通信。

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

2.SOMEIP服務(wù)化通信

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

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

方法Methods:遠程過程調(diào)用, 主要用于遠程調(diào)用方法。

字段Fields:訪問進程數(shù)據(jù)（Field）。訪問進程通信機制主要是為了實現(xiàn)針對對應(yīng)用程序的數(shù)據(jù)獲取與更改

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

2.1 設(shè)定不同Someip接口的目的

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

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

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

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

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

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

需求5：某ECU需要直接開關(guān)車窗

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

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

需求2：該需求為需要提供突發(fā)型事件型的數(shù)據(jù)，選Event接口。

需求3：有需要時獲取數(shù)據(jù)，即訪問進程中的內(nèi)容，選Field接口。

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

需求5：直接開關(guān)車窗，實現(xiàn)車窗的遠程控制，需要遠程調(diào)用開關(guān)服務(wù)，這是典型的遠程調(diào)用，選Method接口。

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

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

2.2 Someip服務(wù)的通信機制

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

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

Someip提供了三種通信方式：

l請求/響應(yīng)

l請求不響應(yīng)

l服務(wù)發(fā)現(xiàn)/訂閱發(fā)布

上述三種方式對應(yīng)著四種真正的通信機制：

lRequest/response

lFire&Forget

lNotification

lGetter/Setter

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

通信機制有如下圖中的對應(yīng)關(guān)系，下面將介紹各接口中的通信機制。

1）Method

Method的特點是遠程調(diào)用，根據(jù)是否需要服務(wù)端發(fā)出響應(yīng)報文可以分為兩類：

1.請求響應(yīng)，即Request/Response機制

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

2.請求不響應(yīng)，即Fire/Forget機制

Fire/Forget機制相對于Request/Response機制，區(qū)別在于前者不需要Server端發(fā)送響應(yīng)報文，而后者需要。

2）Event

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

l由Server向Client發(fā)送報文

l可周期性發(fā)送或者根據(jù)事件狀態(tài)（值改變或者特定條件滿足）發(fā)送通知類消息。

l在Server端發(fā)送報文之前，需要Client端先對服務(wù)進行訂閱。

3）Field

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

1.Notification

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

1）由Server端主動發(fā)送報文

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

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

2.Getter

Client主動從Server端獲取field數(shù)據(jù)。

3.Setter

Client主動設(shè)置Server端的Field數(shù)據(jù)。

3.Someip的軟件實現(xiàn)

在AUTOSAR架構(gòu)中，Someip服務(wù)化通信的實現(xiàn)需要依賴于底層以太協(xié)議棧與應(yīng)用層的共同完成。

如上文所描述，服務(wù)接口的抽象由應(yīng)用層完成，即Event，F(xiàn)iled,Method的抽象，具體的通信機制由以太棧支持。

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

應(yīng)用層SWC將完成Event與Method或者Filed特性的實現(xiàn)。

3.1 Method請求代碼實現(xiàn)

下圖為Method接口請求/響應(yīng)中請求的代碼實現(xiàn)方式。

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

實際上，Method接口中請求在AUTOSAR架構(gòu)中體現(xiàn)為函數(shù)調(diào)用。Client向Server端通過Method接口請求車窗開啟，本質(zhì)上就是，Client端向Server端請求調(diào)用對應(yīng)的車窗控制函數(shù)，只不過函數(shù)調(diào)用請求需要通過Someip報文從Client端發(fā)送至Server端實現(xiàn)。

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

注意：Request/Response中Response的實現(xiàn)方式與Request一致，不同點在于變?yōu)镾erver端請求調(diào)用Client端中的函數(shù)。

3.2 Event主動發(fā)送代碼實現(xiàn)

下圖為Event服務(wù)接口在代碼中的實現(xiàn)方式。

在AUTOSAR架構(gòu)中，Event實現(xiàn)的即為ECU間的數(shù)據(jù)傳輸。

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

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

總結(jié)

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

審核編輯：劉清