車載以太網(wǎng)SOME/IP 測試的研究與分析

李志濤， 姬志博， 耿偉峰

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

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

1 SOME/IP協(xié)議概述

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

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

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

2 SOME/IP協(xié)議解析

車載以太網(wǎng)協(xié)議架構(gòu)對應(yīng)OSI參考模型， 主要分為物理層、 數(shù)據(jù)鏈路層、 網(wǎng)絡(luò)層、 傳輸層、 應(yīng)用層， 每一層都有各自的功能， 車載以太網(wǎng)及其支持的上層協(xié)議的技術(shù)架構(gòu)見圖1。

圖1 車載以太網(wǎng)協(xié)議技術(shù)架構(gòu)

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

基于SOME/IP協(xié)議通信的電氣架構(gòu)， ECU根據(jù)功能需求的 不 同， 劃 分 為Client （客 戶 端） 和Server （服 務(wù) 器）。Server 通過SOME/IP 的服務(wù)接口Service Interface 向Client提供服務(wù)， Client也通過服務(wù)接口向Server請求服務(wù)。 SOME/IP通信機制大致可以劃分為服務(wù)發(fā)現(xiàn)、 遠程過程調(diào)用、 訪問進程數(shù)據(jù)。

2.1 服務(wù)發(fā)現(xiàn)

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

圖2 Find與Offer Service

2.2 遠程過程調(diào)用

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

圖3 Method與Event

2.3 訪問進程通信

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

圖4 Field配置

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

3 SOME/IP協(xié)議測試

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

3.1 SOME/IP協(xié)議一致性測試

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

圖5 協(xié)議一致性測試

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

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

SOME/IP協(xié)議的一致性測試， 是SOME/IP通信測試的基礎(chǔ)， 各種數(shù)據(jù)類型及通信行為的符合性及一致性， 利于后續(xù)服務(wù)功能的擴展及配置， 是實現(xiàn)功能服務(wù)通信及系統(tǒng)交互的關(guān)鍵。

3.2 SOME/IP通信測試

SOME/IP 通信測試迥異于SOME/IP 協(xié)議一致性測試。SOME/IP通信測試， 基于應(yīng)用SOME/IP協(xié)議通信的功能系統(tǒng)開展測試， 側(cè)重于通信接口、 信息交互行為等方面的測試。SOME/IP通信測試對應(yīng)用SOME/IP通信的功能服務(wù)開展測試驗證， 依據(jù)OEM定義的SOME/IP接口矩陣與服務(wù)功能的流程圖， 在系統(tǒng)或?qū)嵻嚟h(huán)境下， 采用Vector公司的VN5640工具監(jiān)測系統(tǒng)中各個以太網(wǎng)鏈路的通信數(shù)據(jù)， 進行測試數(shù)據(jù)分析與測試結(jié)果的判定。 SOME/IP通信測試連接示意見圖6。

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

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

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

4 SOME/IP通信測試實例

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

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

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

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

圖8 服務(wù)發(fā)布訂閱測試結(jié)果

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

圖9 SOME/IP通信測試結(jié)果

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

5 結(jié)束語

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