亚洲免费av电影一区二区三区,日韩爱爱视频,51精品视频一区二区三区,91视频爱爱,日韩欧美在线播放视频,中文字幕少妇AV,亚洲电影中文字幕,久久久久亚洲av成人网址,久久综合视频网站,国产在线不卡免费播放

        ?

        基于AUTOSAR的域控制器以太網(wǎng)通信系統(tǒng)設(shè)計(jì)實(shí)現(xiàn)

        2023-06-25 01:43:12張世民陸云龍
        汽車工程 2023年6期
        關(guān)鍵詞:域控制器服務(wù)端以太網(wǎng)

        鄭 燚,張世民,陸云龍

        (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)用有重要意義。

        猜你喜歡
        域控制器服務(wù)端以太網(wǎng)
        基于1500以太網(wǎng)養(yǎng)豬場的智能飼喂控制系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)
        處理域控制器時(shí)間誤差
        云存儲中基于相似性的客戶-服務(wù)端雙端數(shù)據(jù)去重方法
        新時(shí)期《移動Web服務(wù)端開發(fā)》課程教學(xué)改革的研究
        基于軟件定義網(wǎng)絡(luò)的分層式控制器負(fù)載均衡機(jī)制
        修復(fù)域控制器故障
        在Windows Server 2008上創(chuàng)建應(yīng)用
        談實(shí)時(shí)以太網(wǎng)EtherCAT技術(shù)在變電站自動化中的應(yīng)用
        電子制作(2017年24期)2017-02-02 07:14:44
        轉(zhuǎn)移域控角色到中轉(zhuǎn)服務(wù)器
        一種90W高功率以太網(wǎng)供電系統(tǒng)的設(shè)計(jì)
        两个人看的www中文在线观看| 亚洲va在线va天堂va四虎| 日本韩国黄色三级三级| 久久久精品亚洲人与狗| 东京热日本av在线观看| 人人澡人人妻人人爽人人蜜桃麻豆| 亚洲av乱码一区二区三区按摩 | 少妇被又大又粗又爽毛片| 人人添人人澡人人澡人人人人| 日韩一二三四精品免费| 亚洲一区二区三区免费的视频| 久草手机视频在线观看| aⅴ精品无码无卡在线观看| 天堂网www在线资源| 激情五月婷婷久久综合| 亚洲天堂一区二区偷拍| 麻豆精品国产精华液好用吗| 久久香蕉免费国产天天看| 中文字幕一区二区三区在线视频| 亚洲国产精品国自产拍性色| 亚洲av无码成h在线观看| 大陆极品少妇内射aaaaa| 久久精品成人免费观看97| 熟女少妇av一区二区三区| 国产果冻豆传媒麻婆精东| 亚洲性啪啪无码av天堂| 久久久久亚洲精品天堂| 精品中文字幕手机在线| 国产一区二区资源在线观看| 无码熟妇人妻av在线影片最多| 国产肉体ⅹxxx137大胆| 久久久久久国产精品免费网站| 国产精品一区又黄又粗又猛又爽| 久久综合另类激情人妖| 国产日产欧洲系列| 国产在线精品一区二区在线看| 精品人妻一区二区三区蜜桃| 不卡av一区二区在线| 精品国产乱码久久久久久郑州公司| 亚洲 欧美 国产 日韩 精品| 亚洲妇女av一区二区|