車載以太網(wǎng)系統(tǒng)測試的研究與分析

李志濤

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

隨著汽車電子技術(shù)的發(fā)展，人民生活品質(zhì)的需求日益增長，汽車網(wǎng)聯(lián)化悄然而至，汽車智能化、網(wǎng)聯(lián)化、擬人化成為汽車行業(yè)發(fā)展的必然趨勢。汽車科技化的發(fā)展，帶來的是汽車無人駕駛技術(shù)、高品質(zhì)車載影音、OTA升級、V2X、大數(shù)據(jù)、云計算等一系列技術(shù)在汽車上的應(yīng)用，同時帶也來了車載通信數(shù)據(jù)量的爆發(fā)式增長，巨大的數(shù)據(jù)通信容量顯然已經(jīng)超出CAN、Flexray等傳統(tǒng)總線的通信速率極限。現(xiàn)有車載總線無法滿足當前需求［1］，因此，一些新型的車載總線技術(shù)得到了快速發(fā)展、應(yīng)用。車載總線的發(fā)展歷程，如圖1所示。

車載以太網(wǎng)高速率傳輸特性，成為與智能網(wǎng)聯(lián)汽車深度集成的契機。以太網(wǎng)將在下一代汽車車載網(wǎng)絡(luò)中得到廣泛應(yīng)用［2］。由于車輛網(wǎng)聯(lián)化的推進，國內(nèi)、外相應(yīng)OEM為解決車輛內(nèi)、外通信互聯(lián)，把車載以太網(wǎng)技術(shù)列入需掌控的核心技術(shù)之一，并投入大量資源開展研發(fā)、測試工作。

1 協(xié)議架構(gòu)及測試概述

1.1 車載以太網(wǎng)協(xié)議架構(gòu)

車載以太網(wǎng)協(xié)議架構(gòu)參考OSI模型，結(jié)合汽車行業(yè)與傳統(tǒng)IT行業(yè),組建成基礎(chǔ)協(xié)議架構(gòu)模型，主要分為物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層以及4層以上的會話、表示、應(yīng)用層部分。基礎(chǔ)協(xié)議架構(gòu)如圖2所示。

圖1 車載總線發(fā)展歷程

圖2 基礎(chǔ)協(xié)議架構(gòu)

第1層為物理層，包含100Base-TX、100Base-T1、1000 Base-T1，通常可簡稱為“PHY”。物理層是OSI參考模型中的底層，主要實現(xiàn)拓撲和物理網(wǎng)絡(luò)設(shè)計、硬件規(guī)范的界定、編碼和信令、數(shù)據(jù)收發(fā)；第2層為數(shù)據(jù)鏈路層，主要涉及Ethernet的 MAC及VLAN需求，通常簡稱為DLL層，數(shù)據(jù)鏈路層主要實現(xiàn)邏輯鏈路控制、媒體接入控制、底層數(shù)據(jù)組幀，本地設(shè)備尋址、差錯檢測和處理、VLAN實現(xiàn)、服務(wù)品質(zhì)；第3層為網(wǎng)絡(luò)層，主要包含IPV4／6、ICMP、ARP協(xié)議，該層是OSI模型中一個重點關(guān)注數(shù)據(jù)交換的層，網(wǎng)絡(luò)層主要功能為邏輯尋址、數(shù)據(jù)報封裝、路由、分片和重組、診斷和輔助；第4層為傳輸層，主要包含TCP／UDP協(xié)議，傳輸層對于確保數(shù)據(jù)在設(shè)備之間準確傳遞有著重要作用，主要功能為進程尋址、多路復(fù)用和多路解復(fù)用、分段和重組、連接的建立、管理和終止、確認和重傳、流量控制；第5～7層主要涉及軟件應(yīng)用問題，而不是網(wǎng)絡(luò)實現(xiàn)細節(jié)，如會話層用于建立和管理會話，實現(xiàn)軟件進程之間持續(xù)的邏輯連接；表示層解決不同設(shè)備在應(yīng)用層傳送數(shù)據(jù)可能出現(xiàn)的任何問題，如處理數(shù)據(jù)轉(zhuǎn)換、數(shù)據(jù)壓縮、數(shù)據(jù)加密等；應(yīng)用層為OSI參考模型的頂層，該層具有多種不同的應(yīng)用層協(xié)議，如UDS／DOIP、UDPNM、SOME／IP、DHCP等，通過不同的各種應(yīng)用層協(xié)議的應(yīng)用，實現(xiàn)用戶通過網(wǎng)絡(luò)達成各項任務(wù)所執(zhí)行的功能。針對音視頻數(shù)據(jù)傳輸特性要求，采用AVB協(xié)議族，實現(xiàn)精確時鐘同步，流媒體傳輸格式，流量整形，從而實現(xiàn)數(shù)據(jù)量較大、實時性要求高的音視頻場景應(yīng)用。

協(xié)議架構(gòu)中所涉及相關(guān)協(xié)議的標準化方面，當前有4個標準化組織或聯(lián)盟起到了主要的推動作用［3］。主要由IEEE、OPEN、AVNU、Autosar組織聯(lián)盟開展協(xié)議的標準化和推動作用。IEEE規(guī)定了以太網(wǎng)的一些主要的、通用的協(xié)議標準；OPEN聯(lián)盟推進以太網(wǎng)在汽車行業(yè)的應(yīng)用及相關(guān)標準化工作；AVNU致力于推廣AVB及后續(xù)的TSN技術(shù)，為汽車內(nèi)低時延、高可靠性傳輸需求提供標準的實現(xiàn)方法；Autosar規(guī)定了基于服務(wù)的中間件SOME／IP（SD），可用于控制指令傳輸，為車載應(yīng)用量身定制的應(yīng)用層協(xié)議。OPEN和AVNU定義汽車行業(yè)的特有需求，而IEEE不區(qū)分行業(yè)應(yīng)用，為基本標準；OPEN和AVNU定義行業(yè)的一致性測試標準，可以進行測試認證。

1.2 車載以太網(wǎng)測試概述

測試是產(chǎn)品開發(fā)過程中的重要環(huán)節(jié)，期望通過測試驗證，以最少的資源投入，早期發(fā)現(xiàn)各種錯誤、潛在缺陷、失效，達成早期問題整改。在汽車電子電氣領(lǐng)域，典型的V模型在OEM電子電器產(chǎn)品開發(fā)中廣泛應(yīng)用。車載以太網(wǎng)的開發(fā)依據(jù)此V模型，左側(cè)為需求的開發(fā)設(shè)計工作，右側(cè)對應(yīng)相應(yīng)階段的測試工作，測試貫穿于整個開發(fā)設(shè)計工作中，車載以太網(wǎng)測試分別開展ECU級、系統(tǒng)級、實車級3個層級的測試驗證工作。

車載以太網(wǎng)ECU級別測試，主要依據(jù)TC8標準開展IOP、PMA、協(xié)議一致性、交換機測試等，用于驗證ECU互聯(lián)互通、物理層接口、協(xié)議一致性、兼容性、交換機特性需求等，同時參照RFC2544、2889開展車載交換機部分性能相關(guān)測試，依據(jù)OEM電子電器架構(gòu)及車載以太網(wǎng)系統(tǒng)設(shè)計需求，開展部分自定義需求測試，驗證設(shè)計需求；車載以太網(wǎng)系統(tǒng)級測試，依據(jù)以太網(wǎng)網(wǎng)絡(luò)拓撲圖，連接各個真實以太網(wǎng)ECU節(jié)點，構(gòu)建系統(tǒng)測試環(huán)境，在系統(tǒng)臺架上開展系統(tǒng)級別的測試驗證工作，在系統(tǒng)級驗證各協(xié)議基礎(chǔ)設(shè)計需求、系統(tǒng)穩(wěn)定性、系統(tǒng)性能、機制策略、多子系統(tǒng)之間的通信等；實車級測試需結(jié)合系統(tǒng)級測試結(jié)果與實車測試需求，基于實車測試環(huán)境，開展協(xié)議基礎(chǔ)點檢確認、重點測試驗證以太網(wǎng)功能相關(guān)需求、整車級通信機制、策略等。

針對車載以太網(wǎng)3個層級的測試驗證工作，ECU級別測試原則上由產(chǎn)品供應(yīng)商負責開展測試驗證工作、OEM一般可選擇性進行接收測試。整車廠需重點開展系統(tǒng)級測試與實車級測試。由于車載以太網(wǎng)節(jié)點連接采用點對點連接，一個鏈路上只連接2個車載以太網(wǎng)節(jié)點，非CAN總線共享介質(zhì)式連接方式，車載以太網(wǎng)系統(tǒng)級與實車級測試時，無法像CAN總線測試一樣，在總線傳輸介質(zhì)上連接測試設(shè)備，實現(xiàn)總線數(shù)據(jù)仿真發(fā)送與所有節(jié)點通信數(shù)據(jù)的監(jiān)測、采集。因此，為實現(xiàn)車載以太網(wǎng)數(shù)據(jù)監(jiān)測、采集、仿真發(fā)送，在系統(tǒng)級與實車級測試時，需依據(jù)測試需求，對以太網(wǎng)網(wǎng)絡(luò)中的交換機節(jié)點進行配置或應(yīng)用專業(yè)的測試設(shè)備，搭建系統(tǒng)測試環(huán)境。

2 系統(tǒng)級測試環(huán)境搭建

車載以太網(wǎng)系統(tǒng)測試前，參照總線拓撲定義，所有以太網(wǎng)節(jié)點連接完成，并且交換機節(jié)點需加入到每一條鏈路中，構(gòu)建完整的以太網(wǎng)系統(tǒng)鏈路。依據(jù)測試需求，搭建系統(tǒng)測試環(huán)境，主要通過“端口鏡像”與“動態(tài)TAP”方法實現(xiàn)車載以太網(wǎng)各節(jié)點數(shù)據(jù)監(jiān)控、采集、發(fā)送。

2.1 端口鏡像

借鑒傳統(tǒng)以太網(wǎng)測試技術(shù)，交換機節(jié)點需進行端口鏡像配置，系統(tǒng)上每一個經(jīng)過交換機節(jié)點的數(shù)據(jù)幀都可依據(jù)配置需求被鏡像到該交換機節(jié)點一個專門的調(diào)試端口或預(yù)留的常規(guī)端口。然后，這個調(diào)試或預(yù)留的端口連接到測試設(shè)備上，通過測試設(shè)備實現(xiàn)數(shù)據(jù)監(jiān)控、采集、仿真發(fā)送。端口鏡像連接如圖3所示。

圖3 端口鏡像連接

采用端口鏡像方法，通過交換機節(jié)點配置即可實現(xiàn)系統(tǒng)數(shù)據(jù)監(jiān)控、采集、發(fā)送，看似簡單易行，但卻存在著一些嚴重的缺陷，如下所述。

1）為了采集來自系統(tǒng)上全部端口的所有以太網(wǎng)幀，必須將幀從多個端口鏡像到調(diào)試端口，數(shù)據(jù)傳輸量巨大，除非調(diào)試端口的運行速度比其它端口快一個數(shù)量級，否則就有可能出現(xiàn)溢出，造成以太網(wǎng)數(shù)據(jù)幀丟失，這意味著測試工具無法采集到被丟棄的數(shù)據(jù)幀。

2）在系統(tǒng)網(wǎng)絡(luò)上傳輸?shù)膲牡囊蕴W(wǎng)幀會被交換機丟棄，不會通過配置端口轉(zhuǎn)發(fā)至測試工具，測試工具無法檢測壞幀。

3）在涉及到車載以太網(wǎng)數(shù)據(jù)仿真發(fā)送測試場景時，仿真的以太網(wǎng)幀需要一個源MAC地址，但同一條鏈路上不可以有2個相同的MAC地址，所以測試工具無法復(fù)制一個已經(jīng)存在于網(wǎng)絡(luò)上的MAC地址，端口鏡像技術(shù)無法實現(xiàn)車載以太網(wǎng)幀的仿真發(fā)送。

4）另外激活交換機節(jié)點數(shù)據(jù)鏡像模式，可能會對交換機節(jié)點功能、通信造成影響，一般情況下不建議在系統(tǒng)測試時對被測系統(tǒng)節(jié)點進行內(nèi)部變動。

5）調(diào)試端口的存在增加了交換機節(jié)點的成本，要使用調(diào)試端口，就必須在交互機節(jié)點上預(yù)留該端口，加裝相應(yīng)的物理層芯片，用于實現(xiàn)測試時的端口鏡像。量產(chǎn)汽車中增加此端口，直接導(dǎo)致整車成本的增加。

2.2 動態(tài)TAP

考慮端口鏡像技術(shù)缺陷，結(jié)合車載以太網(wǎng)數(shù)據(jù)監(jiān)測、采集、仿真發(fā)送需求，采用一種替代方法，即動態(tài)TAP方法。該方法長期用于開發(fā)和測試以太網(wǎng)網(wǎng)絡(luò)設(shè)備，動態(tài)TAP是一個插入到以太網(wǎng)鏈路以便接入網(wǎng)絡(luò)從而進行測試的設(shè)備。TAP不是簡單的連接到網(wǎng)絡(luò)的物理導(dǎo)線，而是一個插入鏈路的專業(yè)設(shè)備，如Technica公司的Media Gateway。連接TAP和交換機的導(dǎo)線與連接TAP和以太網(wǎng)節(jié)點的導(dǎo)線已被物理隔離。動態(tài)TAP連接如圖4所示。

相對于端口鏡像方法，TAP實現(xiàn)了以太網(wǎng)ECU節(jié)點與交換機節(jié)點的物理隔離，在TAP軟件配置中實現(xiàn)各鏈路數(shù)據(jù)的映射，數(shù)據(jù)全部傳輸至連接測試設(shè)備的端口，通過測試設(shè)備端口實現(xiàn)數(shù)據(jù)的監(jiān)控、采集、仿真發(fā)送，同樣采用TAP方法，也有其相應(yīng)的優(yōu)劣勢，如下所述。

圖4 動態(tài)TAP連接

1）TAP可將壞幀封裝到新幀中并通過標準以太網(wǎng)端口轉(zhuǎn)發(fā)至測試工具，從而可以在測試軟件中進行壞幀分析。

2）將測試軟件與動態(tài)TAP相結(jié)合，可以在測試軟件中仿真需發(fā)送的報文，發(fā)送MAC地址與相連節(jié)點相同的以太網(wǎng)幀，從此可以在鏈路上實現(xiàn)模擬發(fā)送以太網(wǎng)報文而無需引入外部MAC地址。

3）動態(tài)TAP方法需要把TAP接入各個以太網(wǎng)鏈路中，勢必會進行以太網(wǎng)線路連接處理、調(diào)整。

4）在端口之間復(fù)制以太網(wǎng)幀時會產(chǎn)生約2μs左右的延遲。

綜上所述，端口鏡像技術(shù)一般不會應(yīng)用于車載以太網(wǎng)系統(tǒng)集成測試，在各鏈路集成或調(diào)試過程中可選擇性應(yīng)用此方法。為確保車載以太網(wǎng)系統(tǒng)通信數(shù)據(jù)的監(jiān)控、采集、仿真發(fā)送，盡量不影響被測車載以太網(wǎng)節(jié)點，綜合考慮，通常應(yīng)用動態(tài)TAP方法完成系統(tǒng)測試環(huán)境的搭建。

3 系統(tǒng)測試內(nèi)容

車載以太網(wǎng)由于在車載環(huán)境中受溫度和震動等環(huán)境因素的影響，比民用以太網(wǎng)要求更加嚴格，因此，各個層級充分、深入的測試驗證非常有必要。車載以太網(wǎng)系統(tǒng)級測試主要進行車載總線系統(tǒng)設(shè)計需求的測試驗證，主要涉及車載以太網(wǎng)配置、系統(tǒng)性能、系統(tǒng)魯棒性、Some／IP測試等，主要測試內(nèi)容見表1。

表1 系統(tǒng)級相關(guān)測試內(nèi)容

車載以太網(wǎng)因使用的用戶層不同，通信條件也不同，必須選定滿足用戶層的協(xié)議［4］。OEM依據(jù)整車電子電氣架構(gòu)及所需實現(xiàn)的電器功能需求，選擇開發(fā)相應(yīng)的應(yīng)用層協(xié)議，如SomeIP／SD、DOIP、UDP-NM等，通過匹配相應(yīng)的應(yīng)用層協(xié)議實現(xiàn)電器功能需求，因此，系統(tǒng)級測試時，應(yīng)用層協(xié)議測試內(nèi)容需依據(jù)協(xié)議開發(fā)設(shè)計同步調(diào)整。同時，車載以太網(wǎng)系統(tǒng)級測試，需著重開展車載以太網(wǎng)系統(tǒng)級通信特性、機制策略、故障處理等系統(tǒng)層設(shè)計需求的驗證，關(guān)注車載通信與電器功能感知緊密相關(guān)點，外部環(huán)境與場景交互的通信性能等。

4 系統(tǒng)測試示例

本示例為測試以太網(wǎng)系統(tǒng)中各節(jié)點是否可正確地響應(yīng)回顯 （Ping）報文。測試前，參照圖4搭建系統(tǒng)測試環(huán)境，連接測試設(shè)備，配置測試軟件。查閱車載以太網(wǎng)系統(tǒng)IP地址列表，獲取各節(jié)點的IP地址信息，仿真需發(fā)送的Ping報文。

啟動車載以太網(wǎng)網(wǎng)絡(luò)通信，使車載以太網(wǎng)網(wǎng)絡(luò)處于正常運行模式中。操作測試工具，依次向IP地址列表中的每個以太網(wǎng)節(jié)點地址發(fā)送Ping報文，檢查是否每條Ping報文都得到了回應(yīng)，Ping報文中所攜帶數(shù)據(jù)是否正確。Ping報文測試分析如圖5所示，應(yīng)用網(wǎng)絡(luò)封包分析軟件WireShark，根據(jù)測試需求設(shè)置軟件的捕獲過濾器、顯示過濾器、著色規(guī)則等配置，完成Ping報文測試數(shù)據(jù)的抓取，協(xié)助測試數(shù)據(jù)的分析。

圖5 Ping報文測試分析

參見圖5，Ping報文測試過程大致為：IP地址為172.16.0.123測試設(shè)備仿真發(fā)送ping報文至IP地址為172.16.0.96的被測節(jié)點，被測節(jié)點收到Ping報文請求后，向測試設(shè)備發(fā)送了Ping回顯報文，采用wireshark軟件抓包分析，發(fā)送方收到了接收方發(fā)出的回顯Ping報文，請求ping報文與回顯的Ping報文中所攜帶的數(shù)據(jù)量一致、回應(yīng)數(shù)據(jù)正確，該節(jié)點的該項測試通過。同樣，按以上所述測試需求與步驟，完成車載以太網(wǎng)系統(tǒng)上各節(jié)點的回顯報文測試驗證與數(shù)據(jù)分析、判定。

5 結(jié)論

車載以太網(wǎng)在未來的20年隨著整車電子控制模塊的增多勢必會成為車載骨干網(wǎng)絡(luò)［5］，與此同時，車載以太網(wǎng)技術(shù)標準也由相應(yīng)的標準化組織不斷完善、推進，進一步促進了車載以太網(wǎng)的發(fā)展進程，有利于指導(dǎo)OEM開展以太網(wǎng)技術(shù)研發(fā)、測試工作。本文旨在描述車載以太網(wǎng)應(yīng)用趨勢、基礎(chǔ)協(xié)議架構(gòu)、系統(tǒng)級測試環(huán)境設(shè)計，系統(tǒng)測試相關(guān)范圍及測試方法等內(nèi)容，對車載以太網(wǎng)測試具有一定的指導(dǎo)意義。