車載以太網SOME/IP應用研究

摘 要：概述了車載以太網應用背景;介紹了SOME/IP協議的原理、報文格式和交互方式。通過導航功能服務的設計，文章介紹SOME/IP在ECU之間的使用方式。使用測試工具測試儀表和多媒體系統之間的導航服務，驗證設計的可行性。

引言

隨著汽車邁向智能化、網聯化、信息化的發展方向，汽車功能普遍增加，高性能的硬件平臺被用于車型的域控制器或中央域控制器。整車電子電氣架構邁向域控制器架構方向。整車通信信號數量大幅增加到5-10Mbps，導致傳統的CAN總線通信已經不能滿足整車通信帶寬。整車網絡架構不在單一地采用CAN/LIN總線進行通信，而是轉向高帶寬的CANFD和Ethernet通信。

基于車載以太網的網絡通信已經被明確為下一代網絡核心架構。目前越來越多的OEM選擇使用車載以太網。不同的應用場景選擇不同的應用協議進行適配才能滿足相關功能需求。而且基于TCP/IP的底層協議棧的穩定性和兼容性，也是OEM考慮的首要因素。綜合上述考慮，越來越多的OEM和供應商選擇加入AUTOSAR聯盟，使用AUTOSAR協議棧[1]。

AUTOSAR規范的核心目標是實現汽車電子軟件的可復用性，通過規范內的分層架構對軟件開發過程進行分層分工，各個層次之間的接口部分按照統一規范開發，而層次內部則可由開發人員自由發揮。以此提高軟件復用率，降低開發成本，方便軟件的更新和維護。在AUTOSAR協議設計過程中，寶馬公司開發了SOME/IP（Scalable service-Oriented Middleware over IP）協議，該通信協議是面向服務的通信協議，不同ECU之間通過Client /Server的方式進行通信，數據只在有需要的時候進行傳輸，有效降低了總線負載[2]。

1SOME/IP簡介

1.1SOME/IP協議位置

SOME/IP本身屬于車載以太網通信協議架構中應用程序與傳輸層協議之間的中間件（Middleware），起源于復雜的軟件系統開發，并涉及“服務”所需的所有功能以實現其他軟件組件之間數據交換，這種數據交換需要經由網絡，中間件的任務就是確保需要交換數據的軟件組件在網[3]。其在車載以太網通信協議模型的位置如圖1 所示。

ECU通信根據功能需求的不同，劃分為Client（客戶端）和Server（服務器）。Server通過SOME/IP的服務接口Service Interface向Client提供服務。Client也通過服務接口向Server請求服務。

1.2SOME/IP交互方式

SOME/IP的通訊方式與傳統CAN總線方式不同。CAN總線的通信主要采用定時發送的周期型發送，不論接收方是否有需求，發送方都會發送此幀報文。這樣對于總線帶寬是有一定的浪費。但是考慮到傳統嵌入式資源有限，這種簡單的交互方式往往提高了資源利用率，降低了開發成本。SOME/IP的通信方式主要是由Client向Server索取，如果Client有需求則向Server發送請求，服務提供相關服務數據。如果Client沒有需求，則Server停止響應。具體的交互方式如下：

1）請求響應：Request-Response

2）有請求無響應：Fire&Forget

3）訂閱：Notification

4）數據訪問：Setter/Getter

Request-Response的數據發送方式主要由Client在有工作需求時，向Server發送Request請求報文，該請求報文包含請求的服務ID和相關參數。Server將回復的響應裝載到Response的有效載荷，回傳給Client，最終實現2個ECU的遠程調用。如果Response不帶有任何有效載荷，該響應只表達Server收到Client的請求。此類發送方式，多用于車載ECU之間的功能交互，功能設定的場景下。

Fire&Forget的數據發送方式主要有客戶端發送請求，但不需要服務回復應答。此類發送方式，多用于對車載ECU進行設置但不需要反饋結果的場景下，例如開關打開、配置激活等功能。

Notification的數據發送方式主要為發布和訂閱。Server啟動后，將自身可以提供的服務，通過SOME/IP-SD發布。Client啟動后，將自身需要查找的服務通過SOME/IP-SD發布，同時Client通過SOME/IP-SD完成訂閱。訂閱完成后，Server會將client需要的信息封裝在event中，多個event組成eventgroup，Server將eventgroup周期的發送Client。當Client不在需要此eventgroup時，可以通過SOME/IP-SD停止發送訂閱Server的消息。Server停發相關的服務消息。此類發送方式，多用于車載ECU將傳感器、執行器等運行狀態通知其它ECU的場景下，例如環境溫度、當前時間、續航里程等等。

Setter/Getter的數據發送方式實質上Request-Response的發送方式，但使用場景不同。Setter用于設置對端ECU的參數，通過Setter request的有效載荷發送設置的參數，Setter response的有效載荷反饋設置結果。而Getter用于獲取對端ECU的參數，通過Getter request請求服務ID，Getter response反饋參數結果。

1.2SOME/IP報文格式

SOME/IP的報文包含SOME/IP報頭和有效載荷。SOME/IP的報頭，如下圖所示，包含7個字段。

1）Message ID唯一確定了服務的信息。包括16bit的Service ID和16bit的Method ID。Service ID用于定義每個功能服務，Method ID是服務中具體的功能或方法。每個Method ID代表了該服務的一個功能交互或實現方法。

2）Length表示其后所有字節的長度。

3）Request ID分為Client ID和Session ID。Client ID唯一定義了服務的請求方的身份標識。Session ID可以相同在訂閱構成服務的調用次數。

4）Protocol Version表示SOME/IP協議的版本，目前默認為0x1。

5）Interface Version表示服務接口的更新版本，可以根據實際應用隨著版本變更進行累計。

6）Message Type表示SOME/IP的報文類型。包括Request（0x00），Response（0x80），Request_NoReturn（0x01），Notification（0x02）和Error（0x81）。

7）ReturnCode表示錯誤代碼類型，此字段與MessageType=Error配合使用，用于說明交互過程中的錯誤。

1.3SOME/IP-SD報文格式

SOME/IP-SD是服務發現報文。報文格式如下圖所示。

SOME/IP-SD作為特殊的SOME/IP報文，其報頭采用固定的0xFFFF 8100作為Message ID。Protocol Version固定為0x1，Interface Version固定為0x1，Message Type固定為0x2，Return Code固定值為0x00。

在SOME/IP-SD報頭后具有8個bit的Flags標志位，該信號用于描述重置狀態和單播狀態。

條目數組（Entries Array）和其長度字段描述該ECU支持的服務列表，包括可以提供（Offer）的服務和需要訂閱（Find）的服務。

選項數組（Options Array）是為條目數組中的服務列表提供詳細描述信息的，例如提供節點選項信息，描述該服務的發送IP地址和發送的端口號等。

車載ECU在啟動運行后，Server發布SOME/IP-SD的消息提供其全部的服務列表。而Client在啟動后也會發布其需要訂閱的項目列表。并且在收到Server的服務列表后，發送訂閱請求，實現服務的注冊。

2SOME/IP服務設計

面向服務的設計是指將各種功能以服務的形式提供給最終用戶或者其他服務。將相關聯的一組信號或者功能執行所需要的參數合集，整體定義為一個服務。取代CAN總線的面向單個信號傳輸，通過以太網將所有功能執行需要的信息全部封裝在一個服務中。上層應用只要調用此服務接口，即可實現對功能控制。

以儀表顯示導航信息為例，解釋具體服務設計過程。如下圖所示，導航功能位于車載多媒體系統IVI中，液晶儀表IP可以顯示建議導航信息，提示駕駛員方向。

功能描述：方向盤開過按鍵觸發導航功能，通過語音設置目的地，激活導航功能，IVI向IP發送導航信息服務NAVIService，IP收到NAVIService后，切換導航界面，顯示導航數據。

導航功能是有IVI提供和實現的，所以對于此功能IVI是服務提供方，也視為服務發送方。而IP顯示導航信息，是該服務的消費方。根據功能交互場景進行分析，功能激活后由Server將數據推送給Client，所以需要Client提前實現訂閱，實現NAVIService的注冊。

通過訂閱的方式，IP可以獲取IVI的導航信息。由于IVI的導航信息的時效性較高，按照100ms周期發送給IP。其交互等內容如下圖所示。

NAVIService定義如下：

3SOME/IP測試驗證

通過使用Vector公司的VN5640工具，測試IP和IVI系統在導航激活過程的數據傳輸。IP和IVI在整車上連接到交換機SWITCH的端口1和端口2，為了不破壞鏈路，將VN5640連接到交換機的第3路端口，配置交換機，將端口1和端口2的數據轉發到端口3上。

系統上電運行后，IVI發送0xFFFF 8100的SOME/IP-SD報文，提供了ServiceID=0x100E的服務。通過IPv4 Endoption字段描述可以看出，該服務位于IP地址為172.16.100.119，傳輸協議采用UDP，端口號為30501。該消息清楚的描述了IVI可以提供的服務ID和該服務的位置。

IP收到此消息后，立刻發送Subscribe的SOME/IP-SD報文，請求在IVI的注冊中心實現訂閱注冊。而IVI收到此消息后，通過Subscribe Acknowledge回復IP，成功完成訂閱。

激活IVI的導航功能，從下圖中可以看出，IVI的周期100ms向IPK發送消息。該消息的ServiceID=0x100E，Method ID=8007，與設計要求相同。

從數據長度可以看出，SOME/IP報文可以裝置更多的字節，相比CAN總線大大提升了傳輸效率。

4 結論

車載以太網通過SOME/IP的通信方式，將多個數據封裝為服務，通過訂閱和發布的方式，或者請求/響應的方式，實現靈活的調度。每個ECU定義好服務接口，任何控制器都可以實現對此服務的調用和控制，簡化了設計方法，便于后期功能的擴展。通過面向服務的設計方法，使車載ECU通信設計提升到了新的高度，

參考文獻：

[1]張海濤，胡勝，仇林至.基于AUTOSAR的SOME IP通信及其多核應用的實現[J].上海汽車.2021，（01）：17-22.

[2]張弛，吳志紅，朱元，等.基于AUTOSAR標準的ETH基礎通信及SOME/IP通信實現[J].信息通信，2020（2）：7-12.

[3]李陽春.基于SOME/IP的整車電氣通信網絡設計研究[J].汽車文摘，2020（08）：32-37.

[4]AUTOSAR.SOME/IP Specification of Transformer， Release version 4.3.1[EB/OL].[2020-2-29].https：//www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_SOMEIPTransformer.pdf

[5]AUTOSAR_SWS_ServiceDiscovery.pdf[EB/OL].https：//www.autosar.org/fileadmin/user_upload/standards/classic/4-2/AUTOSAR_SWS_ServiceDiscovery.pdf

作者簡介：

鄧戩（1987- ），女，遼寧沈陽人，工程師，碩士，研究方向為車輛工程。