鄭 燚，張世民，陸云龍

（1. 寧波大學(xué)信息科學(xué)與工程學(xué)院，寧波 315211； 2. 浙江合眾新能源汽車有限公司，上海 201107）

前言

傳統(tǒng)的分布式汽車電子電氣架構(gòu)中，大量電子控制單元（electronic control unit，ECU）間交互鏈路繁雜低效，擴(kuò)展性低［1］。即使引入中央網(wǎng)關(guān)，集成度仍較低，難以更新功能［2］。為解決這一問題，汽車電子電氣架構(gòu)開始向集中式發(fā)展，以將相關(guān)功能歸并整合進(jìn)一個(gè)“域”的方式集中管理大量ECU。對單個(gè)功能域內(nèi)ECU 進(jìn)行管理的高性能ECU 即域控制器。域控制器的集成化設(shè)計(jì)大幅減少ECU 及交互鏈路數(shù)量，簡化硬件網(wǎng)絡(luò)。軟件架構(gòu)層面，為提高ECU軟件可移植性，促進(jìn)規(guī)范化，汽車開放系統(tǒng)架構(gòu)（AUTomotive open system architecture， AUTOSAR）應(yīng)運(yùn)而生。依此設(shè)計(jì)的軟件可快速移植到新硬件平臺，大大節(jié)省開發(fā)成本，規(guī)范化接口令軟件設(shè)計(jì)更加安全高效。經(jīng)長久發(fā)展，AUTOSAR 架構(gòu)趨于成熟，被廣泛應(yīng)用于ECU 軟件開發(fā)和汽車電子設(shè)計(jì)，如汽車底盤控制系統(tǒng)開發(fā)［3］、底層通信軟件設(shè)計(jì)［4］、整車電子電氣架構(gòu)設(shè)計(jì)［5］、汽車電子診斷系統(tǒng)開發(fā)［6］和電機(jī)控制系統(tǒng)設(shè)計(jì)［7］等領(lǐng)域。

AUTOSAR架構(gòu)和域控制器概念的引入，為滿足用戶日益增長的智能駕駛需求提供了新解決方案，也對ECU 性能尤其是通信性能提出了更高要求。傳統(tǒng)CAN 總線已無法滿足日益增長的智能駕駛通信需求和復(fù)雜功能調(diào)試需求，對下一代通信系統(tǒng)的開發(fā)迫在眉睫。因此，技術(shù)成熟、成本低廉、通信速率高的以太網(wǎng)逐漸被看好成為下一代車載通信主流［8］。面向服務(wù)的IP 中間件協(xié)議（scalable serviceoriented middle-ware over IP，SOME/IP）對AUTOSAR架構(gòu)兼容性好，逐漸成為車載以太網(wǎng)主流應(yīng)用層協(xié)議之一。國內(nèi)對SOME/IP 的研究仍處在起步階段，文獻(xiàn)［9］中設(shè)計(jì)了基于SOME/IP 協(xié)議的通信系統(tǒng)并驗(yàn)證了通信可用性，文獻(xiàn)［10］中嘗試在樣例小車上模擬SOME/IP 通信，文獻(xiàn)［11］中探究了SOME/IP 協(xié)議在整車通信網(wǎng)絡(luò)中應(yīng)用的可能性，文獻(xiàn)［12］中驗(yàn)證了SOME/IP 通信系統(tǒng)在多核處理器上的可用性，文獻(xiàn)［13］中對SOME/IP 協(xié)議的通信性能進(jìn)行了測試驗(yàn)證。

以太網(wǎng)通用測量校準(zhǔn)協(xié)議（XCP on ETH）可利用以太網(wǎng)的高帶寬滿足復(fù)雜調(diào)試需求。近年來，多種XCP 標(biāo)定系統(tǒng)逐步應(yīng)用于整車控制器標(biāo)定調(diào)試中［14-16］。

本文中基于AUTOSAR 架構(gòu)，設(shè)計(jì)實(shí)現(xiàn)了應(yīng)用于智能駕駛域控制器的車載以太網(wǎng)通信系統(tǒng)軟件，包括基于SOME/IP 協(xié)議的大流量通信系統(tǒng)和XCP on ETH 的標(biāo)定系統(tǒng)，并進(jìn)行了面向?qū)嵻噾?yīng)用場景的測試驗(yàn)證。

1 基于AUTOSAR 的域控制器軟件系統(tǒng)設(shè)計(jì)

1.1 AUTOSAR架構(gòu)簡介

AUTOSAR架構(gòu)具備硬件不敏感、模塊化程度高、安全性好等優(yōu)點(diǎn)，符合集中式架構(gòu)設(shè)計(jì)的需要。如圖1所示，AUTOSAR架構(gòu)將軟件拆分為基礎(chǔ)軟件（basic software， BSW）、運(yùn)行環(huán)境（runtime environment，RTE）和應(yīng)用軟件（application， APPL）3 層，分離應(yīng)用軟件與驅(qū)動，通過標(biāo)準(zhǔn)化接口進(jìn)行交互。這種交互方式在AUTOSAR 架構(gòu)下被廣泛應(yīng)用。在域控制器軟件系統(tǒng)中，應(yīng)用軟件部署在APPL 層，BSW 層提供應(yīng)用功能運(yùn)行的基礎(chǔ)軟件環(huán)境和服務(wù)，APPL層通過RTE層提供的標(biāo)準(zhǔn)化接口調(diào)用BSW層功能服務(wù)。

圖1 AUTOSAR軟件架構(gòu)［17］

1.2 域控制器軟件結(jié)構(gòu)設(shè)計(jì)

1.2.1 APPL和RTE設(shè)計(jì)

智能駕駛域控制器須在復(fù)雜路況下實(shí)現(xiàn)自動泊車、定速巡航、車道保持和碰撞預(yù)警等智能駕駛功能。各功能應(yīng)用場景不同，所需信號與產(chǎn)生的控車指令也相異。將使用場景相近、所需信息趨同的功能整合，可將域控制器應(yīng)用層劃分為若干軟件組件（software component，SWC）。域控制器應(yīng)用軟件架構(gòu)如圖2 所示。泊車輔助功能應(yīng)用于低速環(huán)境，處理行人躥出等緊急情況的概率較高，對車身周邊信息實(shí)時(shí)性要求高，故單獨(dú)設(shè)立泊車輔助SWC 并分配獨(dú)立信道，減少信號處理時(shí)間，增強(qiáng)安全性。碰撞預(yù)警功能對時(shí)效性要求極高，單獨(dú)設(shè)立碰撞預(yù)警SWC及相應(yīng)信道可簡化信息處理過程，避免延遲。定速巡航、車道保持等高速環(huán)境行車功能所需信息相似，如車速、車道線標(biāo)識和跟車目標(biāo)等，故整合為巡航輔助SWC，通過模式開關(guān)拆分整合信號，節(jié)約系統(tǒng)資源。冷卻液溫度、電源狀態(tài)、電池溫度等與智能駕駛功能無直接關(guān)系，但關(guān)乎行車安全的信息由車況監(jiān)控SWC 收集處理，判斷當(dāng)前整車狀態(tài)是否支持功能正常運(yùn)行，如檢測到嚴(yán)重故障，則立刻終止智能駕駛功能并記錄故障信息，以備維修人員查看。每個(gè)SWC 中包含若干運(yùn)行實(shí)體（runnable entity， RE），它們是SWC 的最小代碼片段，也是功能的具體實(shí)現(xiàn)，記錄著功能觸發(fā)條件和接口列表等信息。這些運(yùn)行實(shí)體分布在系統(tǒng)服務(wù)的任務(wù)（AUTOSAR OS task）中，以任務(wù)為單位進(jìn)行運(yùn)行調(diào)度。

圖2 應(yīng)用軟件結(jié)構(gòu)

RTE 層定義SWC 各模塊對外交互接口。接口分為單向的發(fā)送-接收接口和雙向的客戶端-服務(wù)端接口兩類［17］。APPL 所需輸入信號與輸出指令多為單向傳輸，使用發(fā)送-接收接口。故障處理等復(fù)雜場景則以客戶端-服務(wù)端接口進(jìn)行雙向交互。

1.2.2 BSW設(shè)計(jì)

BSW 層結(jié)構(gòu)如圖3所示。驅(qū)動代碼部署于微控制器抽象層（microcontroller abstraction layer，MCAL）。MCAL 隔離硬件資源與上層軟件，進(jìn)行軟件移植時(shí)只須適配MCAL，大大提升軟件可移植性。ECU 抽象層（ECU abstraction layer）承擔(dān)服務(wù)層與MCAL 間交互。服務(wù)層提供通信、存儲與系統(tǒng)服務(wù)等功能。AUTOSAR架構(gòu)中，所有軟件模塊部署在系統(tǒng)服務(wù)提供的任務(wù)中，在系統(tǒng)調(diào)度下分時(shí)運(yùn)行，占用CPU資源。單個(gè)CPU處理所有任務(wù)總耗時(shí)占總運(yùn)行時(shí)間比例即為CPU負(fù)載。出于系統(tǒng)安全性考慮，多核系統(tǒng)中常以最高的CPU負(fù)載值作為整個(gè)系統(tǒng)的負(fù)載參考。

圖3 基礎(chǔ)軟件層結(jié)構(gòu)框圖［18］

2 基于SOME/IP 協(xié)議的車載以太網(wǎng)通信系統(tǒng)設(shè)計(jì)

2.1 SOME/IP協(xié)議介紹

SOME/IP 協(xié)議是目前車載以太網(wǎng)通信的新興應(yīng)用層協(xié)議。它在OSI 7層模型中和DOIP 協(xié)議、XCP協(xié)議等均處于應(yīng)用層，如圖4 所示。它可適配不同傳輸層協(xié)議，且對AUTOSAR架構(gòu)兼容性良好。

圖4 常見車載以太網(wǎng)協(xié)議的OSI 7層模型圖［19］

不同于傳統(tǒng)的CAN 協(xié)議等汽車行業(yè)常用的面向信號與發(fā)送者的協(xié)議，SOME/IP 是面向服務(wù)的通信協(xié)議。它會在通信開始前預(yù)先建立好點(diǎn)對點(diǎn)的通信鏈路——即客戶端與服務(wù)器端的連接。僅當(dāng)客戶端產(chǎn)生通信需求時(shí)，通信才會在指定的客戶端與服務(wù)端中進(jìn)行，不會像面向信號的協(xié)議一樣向整條總線上所有節(jié)點(diǎn)發(fā)送。這種點(diǎn)對點(diǎn)通信方式可有效提高通信效率并降低總線占用率，減少冗余信息傳輸。

SOME/IP 協(xié)議的點(diǎn)對點(diǎn)鏈路建立，依賴一種建立在多播地址上的特殊服務(wù)——服務(wù)發(fā)現(xiàn)（SOME/IP service discovery，SOME/IP-SD）［20］。通過向多播地址——一種可被多個(gè)節(jié)點(diǎn)接收的IP 地址發(fā)信，SOME/IP 服務(wù)端與客戶端可匹配通信服務(wù)需求?？蛻舳讼蚍?wù)端訂閱服務(wù)后，點(diǎn)對點(diǎn)通信鏈路正式建立。

SOME/IP 協(xié)議的服務(wù)類型分為方法和通知兩類?？蛻舳讼蚍?wù)端請求，服務(wù)端根據(jù)請求決定是否響應(yīng)的服務(wù)被稱作方法（method）。方法報(bào)文，根據(jù)客戶端請求后服務(wù)端是否需要響應(yīng)，分為不需要響應(yīng)的開火&丟棄（fire&forget，F(xiàn)&F）類型和需要響應(yīng)的請求&響應(yīng)（request&response，R&R）類型。服務(wù)訂閱后，服務(wù)端自動向客戶端發(fā)布信息的服務(wù)被稱作通知（notification）。只反映服務(wù)端事件狀態(tài)快照，定周期由服務(wù)端向客戶端發(fā)送的通知被稱為事件型報(bào)文（Event）。允許客戶端對服務(wù)器端進(jìn)行數(shù)據(jù)讀寫的通知被稱為字段報(bào)文（field）［21］。

2.2 SOME/IP通信系統(tǒng)設(shè)計(jì)

用于智能駕駛域控制器的通信系統(tǒng)需要滿足：（1）有較高通信帶寬，適應(yīng)智能駕駛功能需求。（2）時(shí)延低，減小控車指令傳輸延遲。（3）系統(tǒng)負(fù)載較低，避免因系統(tǒng)負(fù)載過高導(dǎo)致故障。不同于傳統(tǒng)以太網(wǎng)流行的TCP協(xié)議，UDP協(xié)議作為輕量化傳輸層協(xié)議，不需要多次握手過程，傳輸時(shí)延更低，效率更高。此外，SOME/IP-SD需要服務(wù)端向多個(gè)節(jié)點(diǎn)共用的多播地址同時(shí)廣播服務(wù)信息，UDP 支持這一功能，但TCP不支持。因此，本文將基于SOME/IP 和UDP 協(xié)議設(shè)計(jì)基于AUTOSAR架構(gòu)的車載以太網(wǎng)通信系統(tǒng)。

針對域控制器的不同通信需求，本文在設(shè)計(jì)通信服務(wù)時(shí)采用不同種類SOME/IP報(bào)文作為相應(yīng)的傳輸載體。

選用Event 型報(bào)文負(fù)責(zé)行車軌跡、障礙物、車身運(yùn)動狀態(tài)等智能駕駛功能所需單向、大流量、定周期信息的傳輸，避免頻繁訂閱服務(wù)產(chǎn)生的額外通信負(fù)載。針對設(shè)置開關(guān)，ECU突發(fā)告警等觸發(fā)型、低頻率單向信息，本系統(tǒng)選用F&F 類型進(jìn)行傳輸以簡化傳輸鏈路。

對于重要的、需要域控制器立刻進(jìn)行處理的信息，如系統(tǒng)故障等，本系統(tǒng)選擇R&R 類型報(bào)文以確認(rèn)對端響應(yīng)，盡快完成故障處理。

通信系統(tǒng)架構(gòu)（以發(fā)送過程為例）如圖5 所示。原始數(shù)據(jù)的序列化（serialization）是將待發(fā)送的原始數(shù)據(jù)轉(zhuǎn)換成二進(jìn)制串的過程，可壓縮數(shù)據(jù)包的大小，節(jié)省傳輸帶寬，也能在傳輸時(shí)保證對象完整性與可傳遞性。接收端以反序列化（deserialization）將二進(jìn)制串恢復(fù)成原始數(shù)據(jù)。大數(shù)據(jù)通信管理模塊（large data communication， LDCom）負(fù)責(zé)將信號和協(xié)議數(shù)據(jù)單元（protocol data unit， PDU）進(jìn)行映射。協(xié)議數(shù)據(jù)單元路由（protocol data unit router，PDUR）將PDU向下層協(xié)議傳遞，接收信息也由PDUR 進(jìn)行提取與映射。

圖5 SOME/IP通信系統(tǒng)設(shè)計(jì)

UDP 協(xié)議單幀最大長度僅為1500 B。數(shù)據(jù)包過長時(shí)需要從PDUR 向SOME/IP-TP 發(fā)起拆包請求，將大數(shù)據(jù)包拆分成若干小包。同理，接收端也須進(jìn)行組包操作還原大數(shù)據(jù)包。

數(shù)據(jù)包由PDUR 下行到套接字轉(zhuǎn)換（socket adapter， Soad）模塊，將以太網(wǎng)概念中的套接字（socket）與PDU 對應(yīng)，為數(shù)據(jù)包打包協(xié)議包頭，如SOME/IP 包頭的信息標(biāo)識（message ID）和信息長度等［22］。TCPIP 模塊根據(jù)傳輸層協(xié)議進(jìn)一步封裝數(shù)據(jù)，以太網(wǎng)接口層（ETH interface，ETHIF）對接硬件驅(qū)動，向總線發(fā)信。接收鏈路逆發(fā)送鏈路進(jìn)行。當(dāng)數(shù)據(jù)鏈路層使用片外硬件時(shí)，須添加相應(yīng)驅(qū)動。

在這一系統(tǒng)中，Soad 層以下部分可根據(jù)不同傳輸協(xié)議分別設(shè)計(jì)，快速替換其他協(xié)議，大大增強(qiáng)軟件可移植性。

AUTOSAR 架構(gòu)下，CAN、ETH 等通信系統(tǒng)常共用PDUR 模塊進(jìn)行總線路由。傳統(tǒng)ECU 通信系統(tǒng)部署于多核硬件時(shí)，多將各類通信系統(tǒng)全部部署在單個(gè)內(nèi)核，避免系統(tǒng)內(nèi)部產(chǎn)生跨核通信。但域控制器以太網(wǎng)通信帶寬高、流量大，任務(wù)處理時(shí)間相比傳統(tǒng)通信系統(tǒng)大幅增加，單核集中部署會導(dǎo)致CPU 負(fù)載飆升。為降低負(fù)載，本系統(tǒng)將SOME/IP 通信部署在其他低負(fù)載內(nèi)核，分散單核過高負(fù)載，通過通信管理模塊收集通信需求。此外，序列化和反序列化過程常在中斷處理函數(shù)中執(zhí)行，在處理大數(shù)據(jù)包時(shí)會在中斷狀態(tài)中停留過久，進(jìn)而影響域控制器軟件正常運(yùn)行，尤其是對周期穩(wěn)定性有強(qiáng)要求的其他通信系統(tǒng)。本系統(tǒng)將大數(shù)據(jù)塊的序列化和反序列化從中斷處理程序移出，減少停留，保障其他功能周期穩(wěn)定。

3 基于XCP協(xié)議的標(biāo)定系統(tǒng)設(shè)計(jì)

3.1 通用測量校準(zhǔn)協(xié)議介紹

為避免頻繁燒寫程序?qū)е抡{(diào)試效率降低和可能的硬件損壞，需要一種可實(shí)時(shí)更改程序內(nèi)變量的手段，即標(biāo)定［23］。目前，標(biāo)定功能主流協(xié)議是通用測量校準(zhǔn)協(xié)議（universal measurement and calibration protocol，XCP，其中X 表示任意傳輸層）。XCP 協(xié)議由CAN 測量校準(zhǔn)協(xié)議（CAN calibration protocol，CCP）發(fā)展而來，主要用于ECU 數(shù)據(jù)獲取和校準(zhǔn)訪問，包括測量、標(biāo)定、刷新和旁路等方面。實(shí)際生產(chǎn)主要使用測量和標(biāo)定功能。

XCP 協(xié)議主要包含兩類報(bào)文：主機(jī)向從機(jī)發(fā)布的命令接收對象（command transformation object，CTO）和從機(jī)向主機(jī)回傳的數(shù)據(jù)傳輸對象（data transformation object，DTO）［24］。XCP 測量方式分為異步和同步兩種。如圖6 所示，異步模式需要上位機(jī)向從機(jī)頻繁輪詢并等待從機(jī)，總線負(fù)載占用較高，且無法使用時(shí)間戳，缺少時(shí)間一致性。而數(shù)據(jù)單向流動的同步測量有效降低了總線負(fù)載，提升了傳輸效率，也便于使用時(shí)間戳。

圖6 異步測量（左）與同步測量（右）原理圖

同步測量報(bào)文包含若干數(shù)據(jù)傳輸對象（data AcQuisition，DAQ），DAQ 由DTO 與內(nèi)存之間的映射關(guān)系（object descriptor table，ODT）組成，ODT 中包含待測地址與數(shù)據(jù)長度的配對，稱為條目（Entry）［15］。

如表1 所示，所有條目寫入從機(jī)內(nèi)存，編譯后不能修改的標(biāo)定方式為靜態(tài)DAQ 標(biāo)定，在標(biāo)定開始前由上位機(jī)計(jì)算完畢的稱動態(tài)DAQ 標(biāo)定。動態(tài)DAQ標(biāo)定不需要為單次調(diào)試中用不到的待測量固定內(nèi)存占用，可只尋址所需內(nèi)容，從而大大減少ECU 內(nèi)存消耗。

表1 動態(tài)與靜態(tài)DAQ比較

3.2 標(biāo)定系統(tǒng)設(shè)計(jì)

智能駕駛功能調(diào)試須同時(shí)觀測大量信號，如表2所示。待測量超過3000個(gè)，總數(shù)據(jù)量達(dá)3810 Kbps，僅10 ms 周期待測數(shù)據(jù)量就超過2 Mbps， CCP 協(xié)議1 Mbps的通信速率［16］無法滿足需求。存儲大量待測信號會大幅占用內(nèi)存。為節(jié)約內(nèi)存，本系統(tǒng)采用動態(tài)DAQ標(biāo)定。

表2 標(biāo)定系統(tǒng)通信數(shù)據(jù)統(tǒng)計(jì)

與SOME/IP 協(xié)議類似，XCP 協(xié)議位于OSI 模型應(yīng)用層。XCP 協(xié)議可兼容多種傳輸協(xié)議，為滿足智能駕駛標(biāo)定系統(tǒng)的高帶寬需求，出于節(jié)約資源考慮，本文選擇UDP 傳輸協(xié)議，與SOME/IP 通信系統(tǒng)共同使用相關(guān)驅(qū)動。

標(biāo)定系統(tǒng)結(jié)構(gòu)如圖7 所示。系統(tǒng)硬件由上位機(jī)、車載路由和域控制器組成。車載路由可通過無線網(wǎng)絡(luò)轉(zhuǎn)發(fā)域控制器和上位機(jī)數(shù)據(jù)，不需要5 類線接口，簡化了車載硬件。與SOME/IP通信系統(tǒng)不同，高度集成的XCP 模塊可以直接根據(jù)上位機(jī)需求實(shí)時(shí)取址，數(shù)據(jù)處理功能如拆組包等均集成到模塊內(nèi)，不需要額外設(shè)計(jì)。

圖7 標(biāo)定系統(tǒng)結(jié)構(gòu)圖

XCP 模塊所需PDU 同樣通過PDUR 模塊進(jìn)行數(shù)據(jù)路由，TCPIP 層以下驅(qū)動可與SOME/IP 通信系統(tǒng)兼容共用，不需要部署其他傳輸協(xié)議，節(jié)約系統(tǒng)資源。

智能駕駛域控制器標(biāo)定過程須觀測大量實(shí)時(shí)數(shù)據(jù)確定運(yùn)行狀態(tài)，待寫入?yún)?shù)在實(shí)時(shí)性和數(shù)量上則要求均較低。為確保數(shù)據(jù)實(shí)時(shí)性，待測量由運(yùn)行代碼直接取址得到，這些數(shù)據(jù)隨應(yīng)用代碼部署于離散內(nèi)存地址，因此，本系統(tǒng)需要較大XCP 模塊讀取范圍。待寫入?yún)?shù)可集中分配到同一內(nèi)存區(qū)域進(jìn)行編譯，以減小XCP 模塊的寫入取址范圍，避免誤操作寫入對智能駕駛功能的干擾。各類智能駕駛功能部署任務(wù)執(zhí)行周期不同，為降低系統(tǒng)負(fù)載，本系統(tǒng)依照功能運(yùn)行周期分別設(shè)計(jì)多條標(biāo)定事件，避免長周期待測量占用短周期通道，提升傳輸效率。

4 測試驗(yàn)證

4.1 SOME/IP通信系統(tǒng)測試

系統(tǒng)設(shè)計(jì)完成后，通過Davinci configurator 和developer 等規(guī)范化AUTOSAR 設(shè)計(jì)工具實(shí)現(xiàn)程序代碼，用HighTec 編譯器進(jìn)行集成編譯，生成可執(zhí)行文件?？蓤?zhí)行文件由Lautebach 調(diào)試器燒錄進(jìn)基于英飛凌TC397芯片的域控制器平臺。為獲取實(shí)車應(yīng)用數(shù)據(jù)，將平臺硬件裝車后啟動智能駕駛功能，實(shí)時(shí)獲取系統(tǒng)負(fù)載數(shù)據(jù)。測試環(huán)境如圖8所示。

圖8 智能駕駛域控制器實(shí)車測試環(huán)境（左）與硬件平臺（右）

車載以太網(wǎng)系統(tǒng)負(fù)載如圖9和圖10所示。基于UDP 傳輸協(xié)議的SOME/IP 以太網(wǎng)通信系統(tǒng)相比TCP傳輸協(xié)議大幅降低了CPU 負(fù)載，多核優(yōu)化策略也有效降低了域控制器系統(tǒng)負(fù)載。

圖9 車載以太網(wǎng)單核通信負(fù)載對比

圖10 多核負(fù)載優(yōu)化對比

為測試SOME/IP 通信系統(tǒng)實(shí)車運(yùn)行性能，使用Wireshark 軟件統(tǒng)計(jì)以太網(wǎng)通信數(shù)據(jù)，測試結(jié)果如圖11和圖12所示。在超過2000 s的長時(shí)通信測試中，系統(tǒng)平均接收速率2433 Kbps，發(fā)送速率1944 Kbps。合計(jì)4377 Kbps 的傳輸速率遠(yuǎn)高于車載CAN 總線500 Kbps 通信速率和CAN FD 總線1 Mbps 的常規(guī)通信速率，證明本系統(tǒng)通信性能良好。為驗(yàn)證系統(tǒng)能否滿足智能駕駛功能需求，分別測試泊車輔助、定速巡航、車道保持等功能。泊車場景根據(jù)車位與車身位置可分為水平車位與垂直車位，分別進(jìn)行泊入與泊出測試，如圖13 所示。對定速巡航與車道保持功能進(jìn)行整合測試，在高速路段同時(shí)開啟相應(yīng)功能，持續(xù)行駛152 km 并收集所有故障信息，如圖14 所示。開啟碰撞預(yù)警功能在高速路段持續(xù)行駛1318 km，共計(jì)出現(xiàn)9 次碰撞風(fēng)險(xiǎn)場景，場景下碰撞預(yù)警功能均正常運(yùn)行。在以上測試中，智能駕駛功能運(yùn)行穩(wěn)定，無通信系統(tǒng)故障，通信系統(tǒng)能夠滿足域控制器使用需要。

圖11 SOME/IP接收速率

圖12 SOME/IP發(fā)送速率

圖13 泊車輔助測試

圖14 定速巡航與車道保持測試

4.2 以太網(wǎng)XCP標(biāo)定系統(tǒng)測試

為檢驗(yàn)大容量標(biāo)定系統(tǒng)的可靠性與穩(wěn)定性，本系統(tǒng)在CANape 軟件中載入所有待測數(shù)據(jù)，運(yùn)行智能駕駛功能后建立標(biāo)定連接。在功能運(yùn)行中實(shí)時(shí)讀取數(shù)據(jù)與修改參數(shù)，觀察功能運(yùn)行是否正常，數(shù)據(jù)讀取是否穩(wěn)定，同時(shí)統(tǒng)計(jì)標(biāo)定功能CPU負(fù)載。

如圖15 所示，使用標(biāo)定系統(tǒng)調(diào)試過程中，標(biāo)定系統(tǒng)CPU 負(fù)載僅11.381%，滿足大流量標(biāo)定系統(tǒng)的高速率、低負(fù)載需求，系統(tǒng)功能穩(wěn)定。

圖15 標(biāo)定系統(tǒng)CPU負(fù)載

5 結(jié)論

基于AUTOSAR 架構(gòu)設(shè)計(jì)實(shí)現(xiàn)了智能駕駛域控制器車載以太網(wǎng)通信系統(tǒng)，包含基于SOME/IP 協(xié)議的應(yīng)用通信系統(tǒng)和基于XCP on ETH 的標(biāo)定調(diào)試系統(tǒng)。在基于英飛凌TC397芯片的域控制器硬件平臺上部署通信系統(tǒng)軟件后裝車，在實(shí)車條件下測試智能駕駛功能，并收集通信系統(tǒng)性能與負(fù)載數(shù)據(jù)。測試結(jié)果表明，本通信系統(tǒng)可滿足智能駕駛功能對大流量高速通信和對復(fù)雜功能進(jìn)行調(diào)測的需求，且系統(tǒng)負(fù)載低，傳輸穩(wěn)定。車載以太網(wǎng)通信性能相比上一代通信協(xié)議大大提高，可以滿足基于集中式汽車電子架構(gòu)的智能駕駛功能更強(qiáng)的通信需要，對智能駕駛功能進(jìn)一步迭代和實(shí)際應(yīng)用有重要意義。