面向集中域控的汽車電子電氣架構(gòu)技術(shù)研究

黎嘉晨，蘭建平，周海鷹

（湖北汽車工業(yè)學(xué)院汽車工程師學(xué)院，湖北十堰 442002）

隨著無人駕駛、車聯(lián)網(wǎng)、智能交通等技術(shù)的不斷引入，車載ECU 單元數(shù)量的不斷增加［1］，基于CAN 總線通信模式的網(wǎng)絡(luò)拓?fù)湓絹碓綇?fù)雜，對于汽車上新功能的增加及維護(hù)造成了較大的困難［2］，傳統(tǒng)的整車電子電氣架構(gòu)難以滿足汽車新興業(yè)務(wù)的快速發(fā)展技術(shù)需求。近年來，眾多汽車廠商對汽車電子電氣架構(gòu)的升級進(jìn)行研究，博世公司指出整車電子電氣架構(gòu)正從分布式向集中式發(fā)展，大眾、特斯拉［3］、華為［4］等公司也以集中化為方向提出了各自的架構(gòu)方案。在集中化發(fā)展的過程中，面向服務(wù)的軟件架構(gòu)（service-oriented architecture，SOA）逐漸獲得了重視。利用SOA架構(gòu)進(jìn)行軟件設(shè)計(jì)能使軟硬件解耦，促進(jìn)汽車電子電氣架構(gòu)進(jìn)一步向集中式發(fā)展，同時也能使車載軟件向多元化發(fā)展。

1 汽車電子電氣架構(gòu)設(shè)計(jì)

1.1 架構(gòu)設(shè)計(jì)原則

基于域集中電子電氣架構(gòu)設(shè)計(jì)時，功能域的劃分應(yīng)當(dāng)符合如下原則：1）域內(nèi)信號根據(jù)實(shí)時性或可靠性，信號相似的服務(wù)劃分在同一功能域下［5］。2）根據(jù)車輛現(xiàn)有的ECU 邏輯功能劃分功能域，將功能相近且經(jīng)常產(chǎn)生信號交互的服務(wù)劃分在同一功能域下，便于減少域間信號路由，降低網(wǎng)關(guān)負(fù)載［6］。

J1939標(biāo)準(zhǔn)［7］對OBD-Ⅱ的診斷提出了規(guī)范，定義的診斷信號碼將整車按功能劃分為5個域：動力總成域、底盤域、車身域、自動駕駛域和信息娛樂域［8］，汽車電子電氣架構(gòu)［9］如圖1所示。

圖1 域集中式汽車電子電氣架構(gòu)

1.2 基于骨干以太網(wǎng)與多域控制器的整車電子電氣物理架構(gòu)設(shè)計(jì)

以沙灘車為例采用域集中式方案構(gòu)造整車電子電氣架構(gòu)。使用以太網(wǎng)將5 個功能域與中央網(wǎng)關(guān)進(jìn)行連接，功能域內(nèi)通過域控制器控制其功能，域控制器之間通過中央網(wǎng)關(guān)進(jìn)行通信。使用Docker將各域控制器及中央網(wǎng)關(guān)封裝成鏡像，并根據(jù)各鏡像生成對應(yīng)的容器。Docker 可以指定各個容器的端口號映射，利用該特性可以在同一臺計(jì)算機(jī)上完成各域控制器與中央網(wǎng)關(guān)之間的以太網(wǎng)通信。域集中式整車電子電氣架構(gòu)如圖2所示。

圖2 架構(gòu)設(shè)計(jì)示意圖

1.3 基于SOA的汽車通信服務(wù)架構(gòu)設(shè)計(jì)

SOA架構(gòu)是車載以太網(wǎng)的重要特征，通過提供服務(wù)的方式實(shí)現(xiàn)功能，能夠降低通信網(wǎng)絡(luò)上的負(fù)載［10］。服務(wù)端將質(zhì)量、控制信息和其他關(guān)于服務(wù)的細(xì)節(jié)打包在1個服務(wù)內(nèi)為客戶端提供服務(wù)，客戶端在需要此服務(wù)的時候才會向服務(wù)端請求服務(wù)。

SOME/IP是面向服務(wù)的通信中間件，提供標(biāo)準(zhǔn)服務(wù)接口，廣泛應(yīng)用于車載以太網(wǎng)［11］。SOME/IP協(xié)議在車載以太網(wǎng)7 層模型的位置如圖3 所示。SOME/IP 支持3 種通信方式，即Method（方法）、Event（事件）和Field（字段）。Method 是發(fā)起-答復(fù)制，Client 向Server 請求數(shù)據(jù)時，Server 進(jìn)行答復(fù)；Event 與CAN 總線的通信模式比較相近，Server 周期性向整個架構(gòu)發(fā)送服務(wù)提供的消息，對該服務(wù)有需求的Client 響應(yīng)后獲得該服務(wù)，但不會對Server進(jìn)行回復(fù)。Field通信模式與Event類似，除了獲取通知消息之外，還能對Server進(jìn)行Getter和Setter操作，即向服務(wù)器請求數(shù)據(jù)與主動修改服務(wù)器的數(shù)據(jù)，報(bào)頭格式見圖4。以轉(zhuǎn)向燈功能服務(wù)為例，采用Method通信方式，定義Payload報(bào)文格式如下：

圖3 SOME/IP在車載以太網(wǎng)7層模型的位置

圖4 SOME/IP報(bào)頭格式

unsigned int position;//1：left,2：right,3：both

unsigned int status;//0：false,1：true}

利用SOME/IP 協(xié)議定義的各功能域的部分服務(wù)列表如表1 所示。整車信號矩陣的設(shè)計(jì)內(nèi)容較龐大，以車身域?yàn)槔?，選擇其中部分功能進(jìn)行定義說明。R/R Method 即請求-響應(yīng)方法，客戶端發(fā)送請求報(bào)文至服務(wù)端后，服務(wù)端將執(zhí)行服務(wù)的結(jié)果通過響應(yīng)報(bào)文反饋至客戶端；F&F Method即提出-遺忘方法，客戶端發(fā)送請求報(bào)文至服務(wù)端后，無需返回響應(yīng)報(bào)文；Event 為周期性事件，F(xiàn)ield 為字段通信，通信特征如前文所述。

表1 各功能域SOME/IP部分服務(wù)

2 測試平臺構(gòu)建

由于車載以太網(wǎng)處于研究階段，驗(yàn)證電子電氣架構(gòu)功能需要對應(yīng)的測試平臺［12］，因此設(shè)計(jì)了仿真平臺，完成功能驗(yàn)證及性能測試。

仿真平臺分為前端汽車模型和后端電子電氣架構(gòu)兩部分，搭建通信網(wǎng)關(guān)以完成前后端通信。后端能搭建各類電子電氣架構(gòu)，前端能根據(jù)通信總線上的報(bào)文完成動作顯示。通信網(wǎng)關(guān)負(fù)責(zé)完成前后端之間的數(shù)據(jù)交換，前后端通信內(nèi)容全部經(jīng)過通信網(wǎng)關(guān)，通信接口預(yù)留為統(tǒng)一格式，完成解耦合設(shè)計(jì)。平臺整體結(jié)構(gòu)見圖5。前端設(shè)計(jì)為網(wǎng)頁形式，包含汽車模型和詳細(xì)數(shù)據(jù)2 個操作界面。汽車模型界面為Unity 3D環(huán)境下的某模型汽車，詳細(xì)數(shù)據(jù)界面以列表形式展示車輛狀態(tài)及變化動態(tài)。后端分為集中域式電子電氣架構(gòu)和通信網(wǎng)關(guān)。架構(gòu)部分實(shí)現(xiàn)了集中域控式的電子電氣架構(gòu)，各域控制器與中央網(wǎng)關(guān)分別利用Docker 進(jìn)行封裝打包形成鏡像，生成的容器通過SOME/IP協(xié)議進(jìn)行通信。通信網(wǎng)關(guān)使用LCM與各域控制器通信，使用WebSocket協(xié)議向前端傳送數(shù)據(jù)；還能夠直接與架構(gòu)中的各域控制器通信，將模擬操作的控制指令發(fā)送至對應(yīng)的ECU 或域控制器上。所有通信數(shù)據(jù)都以標(biāo)準(zhǔn)接口經(jīng)過網(wǎng)關(guān)，前后端通信協(xié)議之間互不影響，實(shí)現(xiàn)了前后端的解耦合。部分通信接口報(bào)文格式見表2，SOME/IP協(xié)議定義的部分服務(wù)報(bào)文見表3。

圖5 平臺整體結(jié)構(gòu)示意圖

表2 網(wǎng)關(guān)與通信網(wǎng)絡(luò)轉(zhuǎn)向燈部分通信報(bào)文格式

表3 架構(gòu)上部分SOME/IP服務(wù)

3 集中域式電子電氣架構(gòu)功能驗(yàn)證

3.1 自動駕駛域與車身域通信功能驗(yàn)證

使用WireShark 對網(wǎng)絡(luò)報(bào)文進(jìn)行抓包，觀察報(bào)文是否合法、前端是否正常工作。以轉(zhuǎn)向燈服務(wù)為例，根據(jù)表1 定義，轉(zhuǎn)向燈服務(wù)的Method ID 為0x0361，Client ID 為0x0010，采用Request & Re?sponse 方案，Session ID 為0x0000。其Payload 報(bào)文為2個unsigned int格式的數(shù)據(jù)，分別代表轉(zhuǎn)向燈的左右位置及狀態(tài)。在通信網(wǎng)關(guān)定義的標(biāo)準(zhǔn)報(bào)文格式中，id 為2 的報(bào)文控制左轉(zhuǎn)向燈的狀態(tài)，value 值代表轉(zhuǎn)向燈狀態(tài)，0 為關(guān)、1 為開，id 為2001 的報(bào)文是轉(zhuǎn)向請求操作，value 值代表其請求操作，0 為無轉(zhuǎn)向請求，1為有左轉(zhuǎn)向請求，2為有右轉(zhuǎn)向請求。

以左轉(zhuǎn)向燈服務(wù)為例進(jìn)行域集中式架構(gòu)的通信功能驗(yàn)證，將前端與后端部署在服務(wù)器上，使用網(wǎng)關(guān)程序連接，操作汽車模型觀察架構(gòu)上的數(shù)據(jù)變化與網(wǎng)關(guān)接收到的消息。功能驗(yàn)證的流程見圖6。

圖6 架構(gòu)功能驗(yàn)證示意圖

過程①：在前端頁面中選擇車輛狀態(tài)為左轉(zhuǎn)向預(yù)設(shè)環(huán)境，前端發(fā)送id為2001，value為1的報(bào)文至后端網(wǎng)關(guān)程序，網(wǎng)關(guān)轉(zhuǎn)發(fā)至架構(gòu)中的自動駕駛域控制器上，如圖7 所示，觀察到網(wǎng)關(guān)程序接收到一條id為2001，value為1的JSON字符串。

企業(yè)要盡可能地提高會計(jì)信息的真實(shí)性和完整性，進(jìn)而提高企業(yè)決策的準(zhǔn)確性，就要加強(qiáng)企業(yè)財(cái)務(wù)管理，不斷完善企業(yè)內(nèi)控體系。一般來說，會計(jì)信息的真實(shí)性需要由內(nèi)部控制制度提供保障，財(cái)務(wù)管理又對內(nèi)部控制具有較大影響，所以，強(qiáng)化財(cái)務(wù)管理可以完善內(nèi)部控制制度，使財(cái)務(wù)數(shù)據(jù)更加準(zhǔn)確可靠，能在生產(chǎn)經(jīng)營決策中發(fā)揮更好的作用，能更有效地規(guī)避企業(yè)經(jīng)營風(fēng)險(xiǎn)。同時，企業(yè)內(nèi)控體系并不是一成不變的，它會隨著企業(yè)的發(fā)展不斷變化，財(cái)務(wù)管理可以通過財(cái)務(wù)數(shù)據(jù)發(fā)現(xiàn)內(nèi)控體系中的不足，從而依據(jù)這些信息對內(nèi)控體系進(jìn)行修改與完善，使內(nèi)部控制制度能與企業(yè)的發(fā)展相適應(yīng)。

圖7 網(wǎng)關(guān)程序接收到的報(bào)文

過程②：自動駕駛域控制器經(jīng)過架構(gòu)中央網(wǎng)關(guān)向車身域控制器發(fā)送轉(zhuǎn)向燈服務(wù)請求，請求包使用SOME/IP協(xié)議，包內(nèi)Service ID為0x1234、Method ID為0x0361，Request ID 中Client ID 為0x0010、Ses?sion ID 為0x0000。由Payload 定義可知，該包Pay?load部分由2個unsigned int格式數(shù)據(jù)組成，分別是position和status，position值為1，即需要響應(yīng)的器件為左轉(zhuǎn)向燈，status 值為1，即狀態(tài)為亮起。觀察到中央網(wǎng)關(guān)接收到了Request 報(bào)文，報(bào)文內(nèi)各屬性值及Payload部分與上文中的定義一致，見圖8a。

過程③：提供轉(zhuǎn)向燈服務(wù)的車身域控制器接收到請求后，以SOME/IP協(xié)議返回Response包至自動駕駛域控制器，告知該域控服務(wù)已成功調(diào)用。2個報(bào)文中對應(yīng)的所有ID 值、屬性值及Payload 均一致，Message Type 為Response。中央網(wǎng)關(guān)上抓取到該Response包，如圖8b所示。

圖8 中央網(wǎng)關(guān)上抓取到的Request包和Response包

過程④：車身域控制器提供轉(zhuǎn)向燈亮起的服務(wù)。根據(jù)標(biāo)準(zhǔn)服務(wù)接口定義，車身域控制器向前端發(fā)送1個id為2，value為1的報(bào)文，前端根據(jù)報(bào)文內(nèi)容點(diǎn)亮左轉(zhuǎn)向燈。實(shí)驗(yàn)中觀察到通信網(wǎng)關(guān)接收到1條id為2、value為1的JSON字符串如圖7所示，同時前端車輛模型完成了左轉(zhuǎn)向燈的點(diǎn)亮狀態(tài)顯示，如圖9所示。

圖9 仿真平臺前端汽車模型狀態(tài)更新

實(shí)驗(yàn)結(jié)果表明：域集中式電子電氣架構(gòu)能以SOA的形式完成車載以太網(wǎng)的數(shù)據(jù)通信，域控制器能正確提供服務(wù)，測試平臺能抓取到對應(yīng)的通信報(bào)文，前端車輛模型能根據(jù)對應(yīng)報(bào)文顯示狀態(tài)。

將該架構(gòu)置于沙灘車上進(jìn)行同一功能驗(yàn)證，自動駕駛域控制器及車身域控制器布置如圖10a 所示，A 為自動駕駛域控制器，B 為車身域控制器。自動駕駛域控制器與外界電腦相連，通過電腦手動發(fā)送轉(zhuǎn)向燈請求，驗(yàn)證結(jié)果如圖10b～c 所示：沙灘車能正確響應(yīng)架構(gòu)中的報(bào)文，域集中式電子電氣架構(gòu)在功能上能達(dá)到預(yù)期的需求。

圖10 沙灘車域控制器布置和車身域（車燈）狀態(tài)更新

3.2 單條報(bào)文跨域?qū)崿F(xiàn)功能性能驗(yàn)證

為了比較SOA架構(gòu)與傳統(tǒng)CAN總線架構(gòu)的性能，在Ubuntu下對2種類型的架構(gòu)進(jìn)行了不同場景的測試，對比網(wǎng)關(guān)吞吐量及CPU利用率2項(xiàng)指標(biāo)。

3.2.1 單項(xiàng)功能場景

設(shè)計(jì)實(shí)驗(yàn)1：自動駕駛模塊/域控制器調(diào)用左轉(zhuǎn)向功能測試。自動駕駛模塊或域控制器向車身控制器、電機(jī)控制器及轉(zhuǎn)向控制器發(fā)送車輛減速及向左轉(zhuǎn)向的報(bào)文。傳統(tǒng)CAN總線架構(gòu)下，3個執(zhí)行單元分別為車身控制器BCM、電機(jī)控制器MCU 及轉(zhuǎn)向控制器EPS，自動駕駛決策模塊使用3條周期發(fā)送的CAN 報(bào)文發(fā)送至各執(zhí)行器完成左轉(zhuǎn)向功能；SOA 架構(gòu)下，3 個執(zhí)行單元為車身域控制器BDC、動力總成域控制器下的MCU 單元與底盤域控制器下的EPS單元，整個左轉(zhuǎn)向功能定義為1個服務(wù)及3個子服務(wù)，自動駕駛域控制器只需請求單個服務(wù)，各執(zhí)行器接收服務(wù)請求報(bào)文并完成左轉(zhuǎn)向功能。測試所調(diào)用的3 個執(zhí)行模塊分別屬于3個不同的功能域。

設(shè)定此功能周期性調(diào)用，每100 ms 調(diào)用1 次。傳統(tǒng)CAN 總線架構(gòu)與SOA 架構(gòu)的網(wǎng)關(guān)吞吐量和CPU占用率對比如圖11所示。測試結(jié)果表明，2種架構(gòu)在單報(bào)文跨域?qū)崿F(xiàn)單條功能的場景下，最大吞吐量均為16 kb·s?1左右，傳統(tǒng)CAN 總線架構(gòu)的報(bào)文持續(xù)占用總線，SOA架構(gòu)的報(bào)文僅在周期性發(fā)送時占用總線。傳統(tǒng)CAN總線架構(gòu)對CPU的占用率為30%～35%，SOA架構(gòu)對CPU占用率約15%。

圖11 單功能場景2種架構(gòu)的指標(biāo)對比

3.2.2 多項(xiàng)功能場景

設(shè)計(jì)實(shí)驗(yàn)2：充電時充電口及電池狀態(tài)的人機(jī)交互界面（human machine interface,HMI）顯示功能測試。充電設(shè)備向電池管理系統(tǒng)發(fā)送充電口電流及電壓報(bào)文，電池管理系統(tǒng)將車載電池的溫度、電壓及電量與充電口電流及電壓報(bào)文發(fā)送至信息娛樂系統(tǒng)的HMI。傳統(tǒng)CAN 總線架構(gòu)下，該功能由電池管理系統(tǒng)BMS 及HMI 之間通信實(shí)現(xiàn)，BMS 周期性發(fā)送3 條CAN 報(bào)文至HMI；SOA 架構(gòu)下，該功能由動力總成域控制器PDC與信息娛樂域控制器IDC 之間通信實(shí)現(xiàn)，IDC 向PDC 訂閱充電時電池信息的服務(wù)。

設(shè)定此功能周期性調(diào)用，每100 ms 調(diào)用1 次。傳統(tǒng)CAN 總線架構(gòu)與SOA 架構(gòu)的網(wǎng)關(guān)吞吐量和CPU占用率對比如圖12所示。測試結(jié)果表明：2種架構(gòu)在單報(bào)文跨域?qū)崿F(xiàn)多條功能的場景下，傳統(tǒng)CAN總線架構(gòu)的最大吞吐量保持在16 kb·s?1左右，SOA架構(gòu)的最大吞吐量為6 kb·s?1左右。傳統(tǒng)CAN總線架構(gòu)對CPU 的占用率為30%～35%，SOA 架構(gòu)對CPU占用率為10%～15%。

圖12 多功能場景2種架構(gòu)的指標(biāo)對比

3.2.3 實(shí)驗(yàn)結(jié)果分析

傳統(tǒng)CAN總線架構(gòu)的通信總線上時刻存在報(bào)文，SOA架構(gòu)僅在周期性發(fā)送時才存在報(bào)文。這是由于傳統(tǒng)CAN 總線架構(gòu)是面向信號的，無論車輛狀態(tài)是否發(fā)生變化，總線上所有信號都需周期性發(fā)送，吞吐量幾乎保持不變；SOA架構(gòu)由于面向服務(wù)，每次周期性調(diào)用服務(wù)時才產(chǎn)生報(bào)文吞吐，因此傳統(tǒng)CAN 總線架構(gòu)的CPU 資源占用率始終較高，而SOA架構(gòu)的資源占用率低于傳統(tǒng)CAN總線架構(gòu)。

實(shí)驗(yàn)2 的SOA 報(bào)文設(shè)計(jì)中，2 個功能域通過1條報(bào)文傳輸多個服務(wù)。實(shí)驗(yàn)2 中傳統(tǒng)CAN 總線架構(gòu)的網(wǎng)關(guān)吞吐量及CPU 占用率與實(shí)驗(yàn)1 的同指標(biāo)相比幾乎沒有變化，這是由于其通信報(bào)文數(shù)目不變，不存在功能域的概念，本質(zhì)上還是3 個電控單元進(jìn)行通信。SOA 架構(gòu)的網(wǎng)關(guān)吞吐量及CPU 占用率則明顯優(yōu)于實(shí)驗(yàn)1，調(diào)用的多個服務(wù)由同一域控制器提供的，因此該服務(wù)所需的數(shù)據(jù)可封裝在1個結(jié)構(gòu)體內(nèi)，網(wǎng)關(guān)吞吐量及CPU的資源開銷會更小。

綜上所述，基于骨干以太網(wǎng)與多域控制器劃分方案及SOA的整車電子電氣架構(gòu)在性能上優(yōu)于傳統(tǒng)CAN 總線架構(gòu)，在同一域控下的服務(wù)調(diào)用開銷明顯低于傳統(tǒng)CAN總線架構(gòu)。SOA架構(gòu)能夠?yàn)檐囕dCPU節(jié)省更多資源。

4 結(jié)論

利用仿真平臺對基于骨干以太網(wǎng)及多域控制器的域集中式電子電氣架構(gòu)完成了功能測試及驗(yàn)證，結(jié)果表明該架構(gòu)能夠正確完成通信，網(wǎng)關(guān)吞吐量及資源占用率都優(yōu)于傳統(tǒng)CAN總線架構(gòu)。