基于SOME/IP 的整車電氣通信網絡設計研究

李陽春

（華晨汽車工程研究院，沈陽 110141）

主題詞：車載以太網 中間件 服務發現

縮略語

SOME/IP Scalable service-Oriented MiddlewarE over IP（車載以太網協議的，可擴展的面向服務的中間件）

SD Service Discovery（服務發現）

ADAS Advanced Driver Assistance Systems（高級駕駛輔助系統）

OTA Over the Air(遠程升級)

V2X Vehicle To X（車聯網）

ECUElectronic Control Unit（電控單元）

CAN Controller Area Network（控制器局域網絡）

LIN Local Interconnect Network（局域網）

AUTOSAR Automotive Open System Architecture（汽車開放系統構架）

SOA Service Oriented Architecture（面向服務的架構）

ISO/OSI IOS Open System Interconnection（ISO開放系統互聯）

RPCRemote Procedure Call（遠程過程調用）

OSEK Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug（Open System and Corresponding Interfaces for Automotive Electronics）

MOST Media Oriented System Transport（面向媒體的系統傳輸總線）

TTL Time To Live（生存時間）

CRC Cyclic Redundancy Check（循環冗余校驗）

1 概述

汽車智能化、網聯化、自動駕駛大浪已經來臨，浪潮帶來的是ADAS技術的不斷革新、高品質車載娛樂影音的推進以及遠程升級（Over the Air，OTA）、V2X、大數據、云計算等一系列技術的發展，這些均促進車內控制器運算能力和硬件的高速發展，最明顯的體現于越來越復雜和多樣的車載電子系統，大量的傳感器和執行器被用在車輛的不同系統實現相應的功能。在不斷的演進過程中，每增加一個新的傳感器或應用程序需要通過增加一個新的獨立的電子控制單元（ECU）設備及其關聯的傳感器電路來實現，這種做法是非常低效的，因為隨著點對點鏈接，需要增加連接的數量與安裝在車內的ECU數量呈指數上升。為了克服這個問題，建立相關的ECU之間的通信鏈路，允許ECU彼此使用更高級的功能和共享數據，這種增長逐漸發展成了現在復雜的、異構的車載網絡。相對于點對點的鏈路系統，提出使用基于總線的網絡是一種進步，但隨著時間增加，新的子系統會被添加到車輛中，ECU數量的增加帶來的是帶寬消耗的顯著增加。傳統的車輛控制應用所需帶寬普遍較低，帶寬問題并未引起廣泛的關注。當引入信息娛樂系統和基于視頻的高級駕駛輔助系統（ADAS）后，這些應用程序相比傳統控制系統的數據傳輸帶寬需求有顯著增長，現有車載網絡傳輸帶寬不足的問題凸顯，因此迫切需求下一代的車載網絡技術及架構。車載網絡容量需求的爆發式發展，顯然這已經超出了CAN總線等傳統車載網絡的能力。這也正是以太網與汽車深度融合和集成的契機。

近些年來，基于車載以太網設計電氣通信網絡已經被明確為下一代車載電子電氣架構的發展方向，且受到了各大整車廠研發設計部門的廣泛關注。在車載以太網領域，有眾多協議可供選擇，從而導致一種錯誤的印象，即現有協議可以直接用于車內所有可想象到的應用程序。但是，車載網絡并非從零開始，所選用的協議也要能滿足特定的需求。比如，新的協議要能很好地適配于當前的車載網絡系統，特別是涉及到AUTOSAR架構的良好集成以及在出現通信錯誤情況下如何確保時間延遲的快速反應機制。SOME/IP（Scalable service-Oriented MiddlewarE over IP）這樣基于服務的通信模式，是一種可以滿足汽車使用需求的開放式協議。但是當前汽車軟件數目十分龐大，且隨著車輛功能與系統的分布擴展而不斷增加。這些分布功能可能使用一個ECU中的不同進程，也可能擴展到不同ECU的不同進程中去，隨著系統的復雜程度增加，不能僅僅將消息放入網絡中傳輸便完成了功能的實現。另外，不同ECU可能使用不同的軟件架構，甚至是不同的操作系統。所以如何合理的基于SOME/IP設計整車電子電氣通信網絡是非常關鍵的，不僅影響著車輛的開發驗證和量產，成本也影響著車輛網絡功能的穩定性、后續車型功能拓展的可行性一系列問題。隨著汽車綠色智能互聯的快速發展，對汽車運行時的高靈活性、車輛內部與外部服務的可關聯、服務和軟件的擴展與升級需求都提出了更高的要求，此時面向服務架構（Service Oriented Architecture）的優勢也變得越來越凸顯。SOME/IP作為面向服務架構的通信基礎，將會得到越來越多的應用。

2 SOME/IP

SOME/IP，即 Scalable service-Oriented MiddlewarE over IP protocol，是一種靈活的，基于車載以太網協議的，面向服務的中間件。SOME/IP是一種專門運用于汽車領域的中間技術，主要用于控制報文通信。雖然SOME/IP協議冗余繁瑣，但從網絡通訊層面來看，還是能保證基本的穩定與效率。從整車角度，其提供通信方式是面向服務的，就是功能實現，這也是其關鍵特性與優勢。

區別于傳統CAN/LIN等總線面向信號（Signal-Oriented）的通信方式，SOME/IP用于面向服務（Service-Oriented）的通信，這也是以太網在汽車領域應用的最大優勢所在。面向服務的通信傳輸是服務的相關信息，汽車以太網應用方面最重要的是面向服務的架構，簡稱為 SOA（Service Oriented Architecture）。SOA的核心是服務，服務可以簡單理解為是實現某種功能的函數或算法。面向服務的通信，顧名思義，這種通信是為了對服務的相關信息進行傳輸。比如在餐廳點餐，服務員(Server)就提供了一種“點餐”的服務(Service)，作為一個客戶(Client)，就能夠使用這些服務。服務的相關信息就是各種屬性信息、控制信息等內容。如果服務與服務使用者同在一臺電腦上，那么可以直接通過程序接口實現過程調用。但是如果服務與服務使用者位于不同的電腦，則需要進行遠程調用。在遠程調用時，就需要借助中間件及網絡傳輸實現信息傳輸，這種通信就是面向服務的通信，就是要通過一定的方式對服務的相關信息進行打包，打包后再把這些信息在網絡上進行傳遞。

2.1 中間件(MiddlewarE)

“中間件（Middleware）”起源于復雜的軟件系統開發，并涉及“服務”所需的所有功能以實現其他軟件組件之間數據交換，這種數據交換需要經由網絡，中間件的任務就是確保需要交換數據的軟件組件在網絡中透明地傳輸數據，如圖1所示，中間件在ISO/OSI層的較高層運行。其組織傳輸復雜數據（消息傳遞）并調節軟件組件之間的函數調用（遠程過程調用RPC），服務提供者作為服務端（Server），服務消費者作為客戶端（Client），服務實現是借助于遠程過程調用機制（RPC），客戶端和服務端通過中間件進行信息的傳輸，而中間件是應用層軟件和底層硬件之間的軟件統稱。

圖1 ISO/OSI模型[1]

2.2 SOME/IP特點

SOME/IP(Scalable service-Oriented MiddlewarE over IP)是車載以太網通信引入的一個概念，位于OSI 7層模型的層4之上。在以CAN總線為主的車載網絡中，通信過程是面向信號的（除了診斷通信之外），這是一種根據發送者需求實現的通信過程，當發送者發現信號的值變化了，或者發送周期到了，就會發送信息，而不考慮接收者是否有需求。而SOME/IP則不同，它是在接收方有需求的時候才發送，這種方法的優點在于總線上不會出現過多不必要的數據，從而降低負載。在車載網絡中，某個ECU有時會需要調用實現在其他ECU上的服務，這個時候它倆就分別扮演了Client和Server的角色，而SOME/IP就是實現這種遠程服務調用的接口，如下圖2所示。

SOME/IP提供面向服務的通信接口，與當前汽車主要總線CAN的面向信號的通信方式有很大不同。SOME/IP可以大致分為3個部分：服務發現（Service Discovery，SD），遠程過程調用（Remote Procedure Call，RPC）和訪問進程數據。ECU通過SD在網絡中查找服務或者提供服務，客戶端（Client）通過RPC去調用SD提供的方法。此外，ECU還可以將特定事件設置為通知，由服務端（Server）ECU自動向客戶端ECU發送服務內容。客戶端ECU的應用程序也可通過讀寫函數去訪問任意特定進程的數據。SOME/IP期望以一種最優的方式利用帶寬并實現靈活的通信方式。

圖2 服務的遠程調用[2]

SOME/IP滿足車用要求的特性如下：

（1）基于服務的通信方式；

（2）占用空間小；

（3）與AUTOSAR兼容（其他中間件均不兼容）；

（4）可伸縮性，小平臺或超大平臺均可以使用；

（5）兼容性，可用于車用的各種操作系統，如AUTOSAR，OSEK和Linux。

2.3 SOME/IP消息格式

圖3是SOME/IP數據在以太網報文中位置，SOME/IP其實是構架在傳輸層之上的應用層通信協議，它的內容雖然很多很雜，但本質上也就是定義了SOME/IP報頭和數據的內容而已。

圖3 SOME/IP數據在以太網報文中位置[1]

（1）Message ID：Message ID的前16 bit表示所使用的服務ID，服務是通信總體類別（圖4）。每個服務需要一個唯一的服務ID，有系統集成商進行標識。其后的16 bit是方法ID，用于表示構成服務的方法、時間與字段。相比之下，CAN很少使用基于服務的通信。不過SOME/IP里面的Message ID的基本思想與CAN的Message ID類似，因此可使用相同的進程來處理SOME/IP的Message ID，這只是對CAN中的處理方法進行增強或者采用即可。

圖4 SOME/IP消息頭格式[1]

（2）Length：長度字段共32 bit，表示包括有效載荷，報頭消息和請求/客戶端ID在內的字節長度。

（3）Request ID：用于區分同一處理方式的多次調用，其前16 bit為Client ID并標識特定的客戶端，其后16 bit代表Session ID，Request ID來源于AUTOSAR的客戶端與服務器端（控制器之間）的通信。

（4）Protocol Version：表示SOME/IP協議版本，長度為8 bit，此一般情況為1。

（5）Interface Version：表示服務接口版本，長度為8 bit，此接口的定義與版本均有接口設計方提供，若定義了新的版本，則該字段自動檢測接口的兼容性。

（6）Message Type：用于區分不同的消息類型，如表1所示，列舉了所有SOME/IP版本1.0中包含的消息類型。

表1 SOME/IP消息類型[1]

（7）Return Code：用于表示消息的反饋（接收方是否成功處理消息）。

（8）Payload：有效載荷包含SOME/IP消息的參數，SOME/IP有效負載字段的長度取決于使用的傳輸協議，對于UDP而言，SOME/IP有效載荷的范圍為0～1 400 Byte，該上限主要是為日后協議更改而設定（如使用IPv6或者添加安全協議），由TCP可以將數據進行分段，因此TCP支持更大的有效負載。UDP同樣支持有效負載分段。

2.4 服務和RPC機制

SOME/IP根據服務接口來定義一系列服務，服務接口為依據已有的通信原則定義的客戶和服務器的行為。

服務接口(Service Interface)就是服務與外界通信的接口，也就是說服務模塊與外界溝通的基本出入口。通俗地理解為你問服務員，我要點一份蛋炒粗面。服務員反饋，沒有粗面。這種對話方式及內容就是服務接口。而至于為什么沒有，那就是服務員在接收到客戶端的信息后，根據服務員的大腦分析得到的結果，也就是服務的內部代碼處理的結果。在通信方面，更多關注的是服務接口，而不是服務的內部代碼分析過程。

圖5SOME/IP中通信原理實例[1]（C為Client，S為Server）

圖5 概述了SOME/IP支持的不同通信原則，服務接口包括：

（1）具有響應（Request/Response）或者沒有響應（Fire&Forget）的方法。

Request/Response：描述具體請求消息與響應消息的通信方案，請求是客戶端向服務器發送的調用方法的消息，響應則是服務器反饋客戶端調用結果的消息。

Fire&Forget：描述僅存在請求消息的通信方式，與Request/Response相同，同樣方法向客戶端向服務器發送請求調用，不同的是，此情況下，客戶端并不期待來自服務器的回復響應。

（2）事件（Event），即觸發事件時，服務器向客戶端發送的消息。

服務器會周期性地或在情況發生變化（事件）時向客戶端發送具有特定內容的消息，前提是客戶端告訴服務器它希望接收此類消息，這也就是“訂閱”。此情況下，客戶端不會發送回應服務器的消息。這種通信方式對于服務器而言也遵循“Fire&Forget”的原則，Event消息與CAN消息類似。

（3）字段（Field），用于獲得、設置或通知性能或者狀態。

Field表示可以遠程訪問的屬性，它可以由客戶端設置。獲取Field的溝通原則與Event一致，不同的是，系統在任何時候都可以獲取“Field”，而Event只是在事件發生的時間內有效，因此，“屬性”可以視為一種可以從外部接口尋址的軟件變量，Field類似MOST總線中的“屬性”。

（4）事件組（Event groups），是用于發布與訂閱處理的時間和字段的邏輯組。

3 SOME/IP SD服務發現

車載以太網可以為車內通信網絡提供更高的傳輸速率，且它基于傳統以太網，提供了面向服務的通信方式。在引入以太網之前，MOST是唯一一個支持面向服務的車載網絡技術，因為，只有使用MOST的整車廠的信息娛樂系統才會使用面向服務的通信方式。高端信息娛樂系統最需要基于服務提供的復雜接口，MOST也首先在信息娛樂系統中需要進行遠程過程調用（RPC）。

目前，CAN總線仍為電子電氣通信主流總線，即信息在網絡中傳輸，由接收器決定是否以及如何處理該信息。但是如駕駛輔助領域，“CAN-approach”的通信方式越來越不適用。另外，CAN數據長度為8字節，且沒有大量的報頭信息，這些均限制了RPC或服務發現（SOME/IP SD）的使用，為滿足未來的車載通信需求，通信方式將轉換為面向服務的通信。通信不僅是通過廣播的方式，同時也使用單播，因此尋址方式也很重要。對于單播而言，只有在通信伙伴真正可用時才有尋址意義。

用于協助客戶端去尋找可用服務的一種機制，服務(Service)部署在服務器端（Server），在具體實現時（實例化）有些參數可能會發生變化，比如網絡地址。為了能夠讓客戶端隨時找到服務器上的服務，因此需要這種服務發現機制。可以簡單理解為服務發現(SD)是Service的秘書。SD清楚的知道Service的地址、狀態等內容。舉例說明，員工要找大領導簽字，得先問一下秘書，領導在嗎、什么時間有空。秘書會告訴你，領導今天在哪個會議室開會，什么時間段有空。在SOME/IP SD包含了發現服務、提供服務、停止提供服務、訂閱事件組、停止訂閱事件組型的服務發現相關報文。

通過SD，SOME/IP可以確定服務是否可用。然而，服務發現機制（SD）在電氣網絡設計時仍存在歧義，主要問題在于車載網絡和功能均偏靜態。

合理使用SD，是能夠解決看似靜態的網絡不斷增長的動態問題。

此外，SD可結合單獨可調節的生存時間（TTL），用以表示參數輸入的有效時間，一旦TTL過期，SD則可用于需要進行參數與服務更新。如果更新消息未能到達，用戶也可分析對方的故障行為，且可以開始特定的故障處理。這有助于網絡的穩定性。但這不能替代安全應用程序發送的循環消息。帶有應用程序循環冗余校驗（CRC）的循環消息通常用于端到端的安全應用程序。

車載網絡越復雜，越能體現基于服務的通信方式與SD的優勢，如沒有基于服務的通信，車載以太網網絡的復雜度就會更高。在網絡中應用SD時，有2種方法。

（1）集中式：一個ECU監視和維護網絡的服務信息，每個參與者只將相應的信息發給這個ECU，且僅向這個ECU做相應的請求。

（2）分散式：所有參與通信的成員都遵守以下規則，每個節點通過多播和廣播的方式宣告可用服務，且每個節點通過多播或者廣播請求其他節點的可用服務。如果服務請求找到了服務提供方，他們則可以建立一對一通信。這種方式的優勢在于，啟動延遲非常小，主要取決于物理網絡的啟動時間，不需要單獨的ECU對此過程進行控制，且此過程存在多個數據源，這意味著沒有單個節點需要處理所有數據，此方式分散了負載和故障風險，簡言之，不存在單一故障點。

4 實際設計應用

上述篇幅介紹了SOME/IP(SD)特點和應用原理，下面根據實際功能來介紹SOME/IP(SD)在整車電子電氣通信網絡設計中的應用。

4.1 SOME/IP實際應用

以CD播放器（CD_Player）服務為例說明如何基于實際功能應用SOME/IP和RPC，每個服務都必須在開發過程中通過其服務接口定義，這通常使用接口描述語言完成。

Service CD_player

{

Track_number-----------------------//Field

{unsigned int track------------------//the track number

Set(track)--------------//Method for setting the track(uses a request/response method)()

Get()；----------//Method for getting the actual track number played

}

Tray.eject()；-------//Event that is triggered if the eject button is pressed

Boolean tray_state；-//Status OPEN or CLOSED when tray is open or closed respectively

Tray_state:open_tray-//Method(for open the tray)，the return value of this method is

()；

}

在定義了上述接口后，假設此時用戶希望將CD設置為10（track number），那么用戶將會向CD（服務器）發命令CD_player，Track_number.set(10)。該服務的方法為track_number.set，set值為10。此命令設置的通信方式為request/response，即該命令設置后希望接收到回應。

假設另一種使用情況，用戶希望打開CD某一個通道，并反饋完成情況，則上述命令中，用戶將向CD發送設置指令，且希望得到反饋（當用戶接收到CD_Player.open_Tray()===opens時，說明發出的命令已經成功執行）。在基于服務的通信中，選擇的關鍵在于數據類型清晰的定義，數據結構以及使用方案和通信原則。在上述功能情形中，還可向CD發送read（get Field）指令，接收CD track狀態信息。也可以訂閱CD track狀態信息，每當CD狀態改變時會自動發送通知（event）。還有一條命令，“subscribe.CD_player.event()”，當CD打開后，CD會向所有訂閱用戶發送此命令。

該設計與功能驗證是基于Technica公司的Andi軟件進行的。

4.2 SOME/IP SD 實際應用

SD（Service Discovery）是服務的信息清單及管理機制，也是一種服務，主要實現服務尋址及事件訂閱2種功能。SD用來對服務進行尋址時，服務提供者（Server端）通過服務發現（SD）通知其他ECU（Client端）某服務可用，并間接地通知該服務的地址（Server端地址）；服務消費者（Client端）了解到某服務狀態后，能夠調用該服務的相關內容。SD用來事件訂閱時，專門針對Event類型的接口，可以通過SD實現對Event所在的Event group進行訂閱、停止訂閱等操作。

4.2.1 車輛起動

車輛起動是電氣系統設計中最復雜的任務之一，啟動時每個ECU均有不同的行為。有些ECU啟動速度快，有些慢，有些ECU電壓低至3.5 V仍然可啟動，有些則到8 V也是不夠的。因此，啟動時各個功能就緒所需要的時間不同，如果不使用服務發現（SD），則需要規定一個確定所有功能就緒的時間點，這需要根據花費最長啟動時間的功能的或者ECU定義。如使用SD，則每個功能或ECU都可以在準備就緒時候宣布其可用性，且通常可以提前提供用戶功能，在起動過程中，SD在交換式以太網網絡中，交換機可以直接通過SD消息建立地址表。

4.2.2 功能變更

大量的功能選擇意味著OEM根據客戶要求來進行功能配置，如沒有SD，每個ECU執行靜態配置確定其他ECU功能可用性。但是通過SD、ECU則可以自行建立車輛可用功能列表，而不需要任何特定組合的預配置，這一方式更為可靠。車輛電氣功能越復雜變化越多，SD優勢越大，越可靠。

5 結論與總結

SOME/IP相關參數的設計是汽車以太網面向服務的架構SOA設計中的主要設計內容，在本文中介紹的服務、服務的提供者、消費者、服務接口的各種方法、事件、字段等內容，以及TCP/IP通信中的配置信息，都是以太網SOA設計中的主要內容，因此對SOME/IP中各種參數的理解，對于整個架構和通信設計都非常重要。

車載以太網中SOME/IP強調了基于服務的通信方式，與CAN總線傳輸簡單消息的Fire&Forget的通信原則有所不同。SOME/IP的序列化確保消息向所有其他流量一樣適合現有的數據包格式，而SOME/IP的內容則確保了通信雙方之間約定履行的服務類型。隨著汽車功能配置越來越復雜，客戶在購車時，汽車廠商向客戶提供了很多選擇，汽車越大，價格越高，可供選擇的功能就越多，電氣架構及越復雜，合理正確運用SOME/IP可以保證整車電氣系統功能實現的同時，也可以降低未來車型改款或者升級時所帶來的開發和管理成本。隨著汽車綠色智能互聯的快速發展，對汽車運行時的高靈活性、車輛內部與外部服務的可關聯、服務和軟件的擴展與升級等需求都提出了更高的要求，此時面向服務架構（SOA）的優勢也變得越來越凸顯。SOME/IP作為面向服務架構的通信基礎將會得到越來越多的應用。