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

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

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

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

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

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

以沙灘車為例采用域集中式方案構(gòu)造整車電子電氣架構(gòu)。使用以太網(wǎng)將5 個(gè)功能域與中央網(wǎng)關(guān)進(jìn)行連接，功能域內(nèi)通過(guò)域控制器控制其功能，域控制器之間通過(guò)中央網(wǎng)關(guān)進(jìn)行通信。使用Docker將各域控制器及中央網(wǎng)關(guān)封裝成鏡像，并根據(jù)各鏡像生成對(duì)應(yīng)的容器。Docker 可以指定各個(gè)容器的端口號(hào)映射，利用該特性可以在同一臺(tái)計(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)的重要特征，通過(guò)提供服務(wù)的方式實(shí)現(xiàn)功能，能夠降低通信網(wǎng)絡(luò)上的負(fù)載［10］。服務(wù)端將質(zhì)量、控制信息和其他關(guān)于服務(wù)的細(xì)節(jié)打包在1個(gè)服務(wù)內(nèi)為客戶端提供服務(wù)，客戶端在需要此服務(wù)的時(shí)候才會(huì)向服務(wù)端請(qǐng)求服務(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 請(qǐng)求數(shù)據(jù)時(shí)，Server 進(jìn)行答復(fù)；Event 與CAN 總線的通信模式比較相近，Server 周期性向整個(gè)架構(gòu)發(fā)送服務(wù)提供的消息，對(duì)該服務(wù)有需求的Client 響應(yīng)后獲得該服務(wù)，但不會(huì)對(duì)Server進(jìn)行回復(fù)。Field通信模式與Event類似，除了獲取通知消息之外，還能對(duì)Server進(jìn)行Getter和Setter操作，即向服務(wù)器請(qǐng)求數(shù)據(jù)與主動(dòng)修改服務(wù)器的數(shù)據(jù)，報(bào)頭格式見(jiàn)圖4。以轉(zhuǎn)向燈功能服務(wù)為例，采用Method通信方式，定義Payload報(bào)文格式如下：

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

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

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

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

2 測(cè)試平臺(tái)構(gòu)建

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

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

圖5 平臺(tái)整體結(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 自動(dòng)駕駛域與車身域通信功能驗(yàn)證

使用WireShark 對(duì)網(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個(gè)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 為開(kāi)，id 為2001 的報(bào)文是轉(zhuǎn)向請(qǐng)求操作，value 值代表其請(qǐng)求操作，0 為無(wú)轉(zhuǎn)向請(qǐng)求，1為有左轉(zhuǎn)向請(qǐng)求，2為有右轉(zhuǎn)向請(qǐng)求。

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

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

過(guò)程①：在前端頁(yè)面中選擇車輛狀態(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)中的自動(dòng)駕駛域控制器上，如圖7 所示，觀察到網(wǎng)關(guān)程序接收到一條id為2001，value為1的JSON字符串。

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

過(guò)程②：自動(dòng)駕駛域控制器經(jīng)過(guò)架構(gòu)中央網(wǎng)關(guān)向車身域控制器發(fā)送轉(zhuǎn)向燈服務(wù)請(qǐng)求，請(qǐng)求包使用SOME/IP協(xié)議，包內(nèi)Service ID為0x1234、Method ID為0x0361，Request ID 中Client ID 為0x0010、Ses?sion ID 為0x0000。由Payload 定義可知，該包Pay?load部分由2個(gè)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部分與上文中的定義一致，見(jiàn)圖8a。

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

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

過(guò)程④：車身域控制器提供轉(zhuǎn)向燈亮起的服務(wù)。根據(jù)標(biāo)準(zhǔn)服務(wù)接口定義，車身域控制器向前端發(fā)送1個(gè)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所示，同時(shí)前端車輛模型完成了左轉(zhuǎn)向燈的點(diǎn)亮狀態(tài)顯示。

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

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

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

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

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

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

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

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

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

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

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

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

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

傳統(tǒng)CAN總線架構(gòu)的通信總線上時(shí)刻存在報(bào)文，SOA架構(gòu)僅在周期性發(fā)送時(shí)才存在報(bào)文。這是由于傳統(tǒng)CAN 總線架構(gòu)是面向信號(hào)的，無(wú)論車輛狀態(tài)是否發(fā)生變化，總線上所有信號(hào)都需周期性發(fā)送，吞吐量幾乎保持不變；SOA架構(gòu)由于面向服務(wù)，每次周期性調(diào)用服務(wù)時(shí)才產(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 個(gè)功能域通過(guò)1條報(bào)文傳輸多個(gè)服務(wù)。實(shí)驗(yàn)2 中傳統(tǒng)CAN 總線架構(gòu)的網(wǎng)關(guān)吞吐量及CPU 占用率與實(shí)驗(yàn)1 的同指標(biāo)相比幾乎沒(méi)有變化，這是由于其通信報(bào)文數(shù)目不變，不存在功能域的概念，本質(zhì)上還是3 個(gè)電控單元進(jìn)行通信。SOA 架構(gòu)的網(wǎng)關(guān)吞吐量及CPU 占用率則明顯優(yōu)于實(shí)驗(yàn)1，調(diào)用的多個(gè)服務(wù)由同一域控制器提供的，因此該服務(wù)所需的數(shù)據(jù)可封裝在1個(gè)結(jié)構(gòu)體內(nèi)，網(wǎng)關(guān)吞吐量及CPU的資源開(kāi)銷會(huì)更小。

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

4 結(jié)論

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