點擊上方藍字談思實驗室

獲取更多汽車網絡安全資訊

SOME/IP（Scalable service-Oriented MiddlewarE over IP）基于IP的可擴展的面向服務的中間件協議。唯一有效的縮寫是SOME/IP，其他縮寫（如Some/IP）是錯誤的，注意規范書寫。

1、本質是中間件

位于應用層和底層操作系統之間的服務軟件，提供標準的API接口來滿足不同APP間的通信，且不受底層硬件差異的影響。

2、基于IP的

在車載以太網OSI模型中，SOME/IP是基于IP網絡層之上的應用層協議，傳輸層依賴于TCP/UDP的以太網傳輸。

3、可擴展的

SOME/IP具有從小型到大型平臺的可擴展性，即支持不同的操作系統（如AUTOSAR、GENIVI和OSEK）甚至沒有操作系統的設備上，體現出SOME/IP協議的強大適用性。

4、面向服務的

把車輛的功能抽象為獨立的、可復用的服務，通過標準化接口來被其他應用調用（或發現）。

SOME/IP是一種基于網絡的服務導向型的通信方式，一個服務可以由零個或多個事件Event、方法Method、字段Field的組合構成，服務所提供的功能就體現在其中。

Event：強調先訂閱數據，服務端主動向所有訂閱者推送/通知消息，客戶端只監聽事件，不發起調用。兩種方式：

Cyclically周期性推送某個事件

如：儀表盤上的信息更新

On change數據變化時推送某個事件（數值改變或差值超出范圍）

如：車門開關狀態變化

既然是推送/通知消息，就是單向通信，且是可以發送給一個或多個ECU。

Method：客戶端向服務器發送報文請求，提供遠程過程調用RPC功能，服務端回復or不回復響應報文。

RR（Request/Response）請求后有響應

如：（請求）語音指令打開內循環，（響應）中控屏內循環圖標亮起。

FF（Fire&Forget）請求后無響應（發后即忘）

如：（請求）語音指令播放下一首歌曲，直接執行播放動作，而不會回復你“好的，下一首已播放”

RPC 機制是實現車內ECU之間基于客戶端-服務器模型的定向、有狀態、可確認的通信，與傳統CAN總線基于廣播、無狀態、不可確認的信號傳輸有本質區別。就像語音控制打開內循環，客戶端是中控屏，服務端是空調控制器。

Field：包括以下1個或多個通信方式組合而成：

• Getter獲取，客戶端向服務端明確請求獲取某個值

• Setter設置，客戶端向服務端請求修改某個值

• Notifier通知，將服務端的數據發送給客戶端來進行更新通知

以汽車自定義尾燈圖案為例：

• Getter獲取：你去中控屏看（讀取）圖案是不是“愛心相伴”。

• Setter設置：你在中控屏改（設置）圖案為“雙喜臨門”。

• Notifier通知：當你更改成功后，綁定的手機收到推送（通知）“尾燈圖案設置成功”。（更改消息會廣播給相關ECU去執行尾燈變化）

Field是一個能夠讀、寫、監聽其變化的狀態值，圍繞的是一個狀態，就像尾燈圖案這個狀態可以查看、修改、變化時推送消息。

注意：

• Event通知與Field通知的區別在于：Event僅在發生更改時發送，Field還會在訂閱后直接發送數據。

• Field中的getter和setter本質上也屬于RR，是客戶端發起的一種請求。

這三種服務類型涵蓋了幾乎所有的交互模式，來提供適用于汽車應用場景所需的功能。最終目的是實現汽車EE架構從面向信號的架構轉向面向服務的架構，提供標準化的、可擴展的、動態的通信方法。

• 基于CAN總線的信號通信方式，一個信號改變后其他ECU自己去監聽讀取，沒有明確的服務接口概念，因此也欠缺對功能層面的封裝和復用；且一個信號定義或頻率的改變，往往所關聯的收發ECU的軟件都需要同步修改，耦合性較高。

• SOME/IP通過上述3種服務類型在客戶端和服務端定義標準化的服務接口，只要接口不變，雙方即可獨立開發與升級；不在網絡設計階段定死，服務部署更靈活；通過功能抽象，上層軟件不需要關心底層硬件實現，這也提升了OEM與不同供應商的合作效率。因此，Event、Method、Field是實現SOA的基石。

來源：乙乙的車COOL