車載以太網SOME/IP 測試的研究與分析

李志濤， 姬志博， 耿偉峰

（長城汽車股份有限公司技術中心， 河北 保定 071000）

隨著汽車電子技術的發展與智能網聯汽車產業大變革，汽車硬件體系逐漸趨于一致， 軟件定義汽車的趨勢逐步被行業認可， 軟件成為汽車開發的關鍵。 汽車高級駕駛輔助系統 （ADAS）、 高性能車載娛樂系統、 車聯網系統及云服務等新技術已在車輛上應用， 使得車輛上的軟件變得越來越復雜。 而傳統汽車采用的分布式E/E架構因計算能力不足、 通信帶寬不足、 不便于軟件升級等瓶頸， 已經不能滿足現階段汽車發展的需求， 需要一種新的軟件開發方法來打破僵局， 于是， SOA設計理念應用于軟件開發中， 新型的車載通信架構由傳統的CAN/LIN 總線向車載以太網總線方向發展， 以滿足車輛高速、 低延遲等性能需求。 同時，汽車行業對可靠性和安全性要求越來越高， 車載以太網在應用的過程中， 為了保證其可靠性與安全性， 就迫切需要對其開展測試工作。

1 SOME/IP協議概述

在IT行業， SOA軟件開發方式已經很普及， 用來滿足用戶的多樣化需求及敏捷開發的要求。 在汽車行業， 隨著車輛功能的持續增加， 功能開發需更加高效， 功能集成需更加便捷， 功能增加及升級更加靈活， 因此引入SOA軟件開發方式， 來滿足日益復雜的功能增長的需求。

SOA即面向服務的架構， 是一種軟件架構設計的模型和方法論， 它將應用程序的不同功能單元 （服務， 包含各種控制算法和應用程序）， 通過服務之間定義良好的接口和契約聯系起來， 通過服務訂閱與推送的方式建立動態的通信關系。 在汽車軟件開發中， 通過基于軟件的模塊化和以太網的通信， 提供標準的服務組件， 使軟件與硬件解耦，從而可以靈活地設計和擴展上層的應用。 總之， 通過構建靈活可變的平臺系統， 實現服務間松耦合、 無狀態、 無依賴； 服務內高內聚且完整、 可復用、 可靈活重組； 服務通信標準化。 從中可看到服務通信標準化是SOA實現的重要環節， 而SOME/IP是實現服務通信標準化的一個中間件協議， 也是車載以太網技術中的核心內容。

SOME/IP 全稱為Scalable service-Oriented MiddlewarE over IP， 是一種面向服務的可伸縮的協議。 寶馬公司開發了SOME/IP協議并在AutoSar標準中進行了車載應用的相關規范定義， 該通信協議是面向服務的通信協議， 不同ECU之間通過Client/Server的方式進行通信， 數據只在有需要的時候進行傳輸， 有效降低了總線負載， 其適配不同規模的操作系統且具備輕量化特性， 在車載以太網協議中得到廣泛應用。

2 SOME/IP協議解析

車載以太網協議架構對應OSI參考模型， 主要分為物理層、 數據鏈路層、 網絡層、 傳輸層、 應用層， 每一層都有各自的功能， 車載以太網及其支持的上層協議的技術架構見圖1。

圖1 車載以太網協議技術架構

SOME/IP協議位于OSI 7層模型的應用層。 該協議存在于操作系統和用戶軟件之間， 將操作系統提供的接口重新封裝， 并添加一些實用功能， 可用于控制消息及應用數據傳輸， 提供給用戶軟件更好的服務， 是SOA架構的重要支撐。

基于SOME/IP協議通信的電氣架構， ECU根據功能需求的 不 同， 劃 分 為Client （客 戶 端） 和Server （服 務 器）。Server 通過SOME/IP 的服務接口Service Interface 向Client提供服務， Client也通過服務接口向Server請求服務。 SOME/IP通信機制大致可以劃分為服務發現、 遠程過程調用、 訪問進程數據。

2.1 服務發現

服務發現的通信機制是通過SOME/IP-SD來實現的， 主要是為了在車載通信中告知服務實例的可用性及其訪問方式， 通過Find Service和Offer Service 消息實現，見圖2。 服務發現通信機制的主要作用， 用于客戶端尋找、 了解可訂閱或調用的服務實例狀態、 服務實例訪問信息等內容； 同時服務器端， 可告知其它節點它可以提供的服務， 以及檢測到提供的服務出現問題時， 告知接收方做出相應的處理。

圖2 Find與Offer Service

2.2 遠程過程調用

遠程過程調用機制分為Method、 Event， 見圖3。 Request/Response通信是最常見的通信模式之一， 通過SOMEI/IP協議實現， 主要用于實現客戶端發送請求消息， 服務器端收到請求， 處理后進行響應； Fire&Forget通信是一種請求但不需要回復的機制， 也是通過SOME/IP協議實現， 實現客戶端向服務端發送請求， 服務端接收請求并進行處理， 不返回響應消息。 Notification Events通信主要描述了發布/訂閱消息內容， 用于實現客戶端向服務端訂閱需要的事件組，當事件發生或值更新時， 服務器端需要向客戶端發送更新的內容。

圖3 Method與Event

2.3 訪問進程通信

訪問進程通信機制主要是對應用程序數據 （Field） 的配置， 見圖4。 客戶端進行數據的獲取和設置， 客戶端可以遠程訪問的服務端中的變量， 通過SOME/IP協議實現， 實現客戶端通過Getter方法獲取值， 通過Setter方法設置值。Getter/Setter使用的是請求/響應機制調用。 使用Getter時， 請求消息中是空的有效載荷， 響應消息中的有效載荷是獲取的值， 使用Setter時， 請求消息中的有效載荷是需要設置的值， 響應消息中的有效載荷是設置成功的值。 與Event相比而言， Field是一個持續存在的變量， 而Event指的是一個事件， 事件沒有發生就不存在。

圖4 Field配置

SOME/IP通信機制主要定義了車載ECU信息交互的收發邏輯、 數據傳輸規則， 在測試階段需依據通信協議、 功能規范等內容來確定消息的收發邏輯， 數據交互行為是否正確， 故熟悉SOME/IP的通信過程與通信機制對車載以太網測試至關重要。

3 SOME/IP協議測試

對于整車測試來說， 最常采用的是V模型的驗證方式。參 考V 模 型， SOME/IP 協 議 測 試 劃 分 為3 個 層 級， 分 別 為ECU級測試、 系統級測試與實車級測試。 在ECU級測試，主要開展SOME/IP協議一致性測試， 驗證ECU協議的符合性； 系統及實車級測試， 主要開展SOME/IP系統通信測試， 驗證SOME/IP系統配置需求的正確性及自定義需求的符合性。

3.1 SOME/IP協議一致性測試

車載以太網控制器的SOME/IP協議一致性測試， 主要基于OPEN Alliance中的TC8規范開展。 測試內容分為兩大部分： SOME/IP Server測試和SOME/IP ETS 測試， 協議一致性測試示意見圖5。

圖5 協議一致性測試

SOME/IP Server 測試依賴于被測DUT的SOME/IP應用功能， 從中選取一些典型的服務、 方法， 在測試中， 應用測試系統仿真客戶端發送請求， 接收DUT的響應。 除此之外， 在觸發應用產生特定行為時， 部分測試可能需要某些特殊手段， 如觸發DUT發送Event報文時， 需要I/O仿真輸入等。 SOME/IP Server主要測試內容為驗證被測控制器是否具備最基本的offer報文發送和響應請求的能力， 服務發現報文的報頭格式、 服務報文載荷中的選項排列格式、 各種服務報文及其功能、 控制器建立連接后的各階段的通信行為， SOME/IP的基本功能定義與線性格式、 遠程調用協議機制等。

SOME/IP本身只是中間件， 它提供了若干接口， 運行在其上的應用可以使用這些接口來完成通信， 為驗證SOME/IP協議的一致性， 需要依賴應用觸發SOME/IP產生特定的行為。 SOME/IP ETS這部分測試需要借助TC8定義的ETS （Enhanced Testability Service） 服 務， 補 充SOME/IP Service 測試中的未覆蓋的測試需求。 在ETS 中包含各種Method、 Event、 Field等， 覆蓋了SOME/IP所支持的全部數據類型， 被測控制器集成了ETS 后， 能夠對SOME/IP 及SOME/IP-SD進行充分而且全面的的驗證， 對SOME/IP服務發現、 序列化等進行測試， 驗證不同類型數據長度異常處理、 字節順序與位域的發送接收、 不同類型數據相應參數的發送和接收、 通信行為的處理機制等。

SOME/IP協議的一致性測試， 是SOME/IP通信測試的基礎， 各種數據類型及通信行為的符合性及一致性， 利于后續服務功能的擴展及配置， 是實現功能服務通信及系統交互的關鍵。

3.2 SOME/IP通信測試

SOME/IP 通信測試迥異于SOME/IP 協議一致性測試。SOME/IP通信測試， 基于應用SOME/IP協議通信的功能系統開展測試， 側重于通信接口、 信息交互行為等方面的測試。SOME/IP通信測試對應用SOME/IP通信的功能服務開展測試驗證， 依據OEM定義的SOME/IP接口矩陣與服務功能的流程圖， 在系統或實車環境下， 采用Vector公司的VN5640工具監測系統中各個以太網鏈路的通信數據， 進行測試數據分析與測試結果的判定。 SOME/IP通信測試連接示意見圖6。

圖6 SOME/IP通信測試連接示意圖

SOME/IP系統測試時， 通過人工操作用戶功能， 觸發被測ECU發送SOME/IP通信信息， 驗證SOME/IP協議通信服務的接口、 發送時序、 發送數據值、 時間參數的正確性，系統交互時的SOME/IP通信交互邏輯、 性能要求等。

SOME/IP協議測試， 各層級測試內容與測試目標不同，同時與傳統總線測試方面也有一定的差異。 SOME/IP協議一致性測試在測試條件和方法上與傳統車載通信測試迥然，而且TC8測試規范以及測試工具鏈都處于迭代和完善中， 測試過程中的問題需要結合數據進行分析， 需不斷積累實踐經驗。 SOME/IP系統通信測試， 重在服務功能應用的測試，測試過程中需要從功能使用的角度， 觸發SOME/IP通信報文， 驗證SOME/IP信息交互行為、 機制， 對于功能邏輯，觸發方式需要熟悉， 同時需掌握SOME/IP報文數據類型及理解參數含義。

4 SOME/IP通信測試實例

SOME/IP協議一致性測試， 參照TC8規范， 同時可添加OEM自定義測試項開展測試， 在此不再贅述。 SOME/IP通信測試， 該部分測試與功能應用緊密相關， 將各種功能以服務的形式提供給最終用戶或者其他服務， 將相關聯的一組信號或者功能執行所需要的參數合集， 整體定義為一個服務。 通過以太網將所有功能執行需要的信息全部封裝在一個服務中。 上層應用只要調用此服務接口， 即可實現對功能控制。

以T_BOX緊急救援電話功能為例， T_BOX為服務提供方 （Server）， HUT為服務訂閱方 （Client）。 系統啟動后，HUT訂閱T_BOX緊急救援電話功能服務， 實現服務的注冊。當緊急救援開關按鍵觸發緊急救援服務后， T_BOX發送緊急救援電話信息 至HUT， 按2s 周期持續發送 給HUT， 在HUT 屏幕上顯示緊急救援電話信息界面，直至緊急救援事件退出或電話掛斷， 取消屏幕上的信息顯示， 緊急救援功能信息交互示意見圖7。

圖7 緊急救援功能信息交互示意圖

通過使用Vector公司的VN5640測試工具， 測試HUT和T_BOX的通信機制及在緊急救援激活的數據傳輸。系統上電運行后，T_BOX發送MessageId為0xFFFF 8100的SOME/IP-SD（Offer） 報文， 提供了ServiceID=0x0201的服務， 從此報文的IPv4 Endoption字段描述可以看出， 該服務位于IP 地址為172.16.12.97， 傳輸協議采用UDP， 端口號為55000， 該消息清楚地描述了T_BOX可以提供的服務ID和該服務的位置。HUT收到此消息后， 立刻發送Subscribe的SOME/IP-SD報文，請求在T_BOX的注冊中心實現訂閱注冊， T_BOX收到此消息 后， 通 過Subscribe Acknowledge 回 復HUT， 成 功 完 成 訂閱。 服務發布訂閱測試結果見圖8。

圖8 服務發布訂閱測試結果

激活緊急救援電話功能， 觸發緊急救援按鍵開關，T_BOX 發出緊急救援電 話信息 （T_BoxCallState） 至HUT，T_BoxCallState以2s周期持續向HUT發送該信息， 直至救援電話掛斷或再次按鍵退出。 該消息的ServiceID=0x0201，Method ID=0x8001， 相關參數與設計要求相同， SOME/IP通信測試結果見圖9。

圖9 SOME/IP通信測試結果

車載以太網通過SOME/IP的通信方式， 將功能轉化為服務， 以服務形式進行數據的傳遞， 通過訂閱和發布的方式或者請求/響應的方式， 實現靈活的調度。 因此， SOME/IP通信測試， 既要測試人員掌握SOME/IP協議通信機制、 交互行為， 還要熟悉車輛功能邏輯， 同時具備相應的功能感知、 評價等綜合能力。

5 結束語

車載以太網推進了車輛智能化的發展。 未來， SOME/IP在車載以太網方面的應用將越來越廣泛。 車載以太網SOME/IP測試， 涵蓋總線協議、 系統通信， 關聯車輛電器性能、 功能等多個方面， 其測試工作是一個系統、 龐大的工程， 需要測試工程師具備多種專業知識、 測試理論與技能。 因此， 需對車載以太網SOME/IP協議的測試進行深入研究， 構建相應的測試能力與測試體系。