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

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

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

基于域集中電子電氣架構(gòu)設(shè)計時，功能域的劃分應(yīng)當(dāng)符合如下原則：1）域內(nèi)信號根據(jù)實時性或可靠性，信號相似的服務(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è)計

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

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

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

SOA架構(gòu)是車載以太網(wǎng)的重要特征，通過提供服務(wù)的方式實現(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 進行答復(fù)；Event 與CAN 總線的通信模式比較相近，Server 周期性向整個架構(gòu)發(fā)送服務(wù)提供的消息，對該服務(wù)有需求的Client 響應(yīng)后獲得該服務(wù)，但不會對Server進行回復(fù)。Field通信模式與Event類似，除了獲取通知消息之外，還能對Server進行Getter和Setter操作，即向服務(wù)器請求數(shù)據(jù)與主動修改服務(wù)器的數(shù)據(jù)，報頭格式見圖4。以轉(zhuǎn)向燈功能服務(wù)為例，采用Method通信方式，定義Payload報文格式如下：

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

圖4 SOME/IP報頭格式

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

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

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

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

仿真平臺分為前端汽車模型和后端電子電氣架構(gòu)兩部分，搭建通信網(wǎng)關(guān)以完成前后端通信。后端能搭建各類電子電氣架構(gòu)，前端能根據(jù)通信總線上的報文完成動作顯示。通信網(wǎng)關(guān)負(fù)責(zé)完成前后端之間的數(shù)據(jù)交換，前后端通信內(nèi)容全部經(jīng)過通信網(wǎng)關(guān)，通信接口預(yù)留為統(tǒng)一格式，完成解耦合設(shè)計。平臺整體結(jié)構(gòu)見圖5。前端設(shè)計為網(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)部分實現(xiàn)了集中域控式的電子電氣架構(gòu)，各域控制器與中央網(wǎng)關(guān)分別利用Docker 進行封裝打包形成鏡像，生成的容器通過SOME/IP協(xié)議進行通信。通信網(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é)議之間互不影響，實現(xiàn)了前后端的解耦合。部分通信接口報文格式見表2，SOME/IP協(xié)議定義的部分服務(wù)報文見表3。

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

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

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

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

3.1 自動駕駛域與車身域通信功能驗證

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

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

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

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

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

過程②：自動駕駛域控制器經(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 報文，報文內(nèi)各屬性值及Payload部分與上文中的定義一致，見圖8a。

過程③：提供轉(zhuǎn)向燈服務(wù)的車身域控制器接收到請求后，以SOME/IP協(xié)議返回Response包至自動駕駛域控制器，告知該域控服務(wù)已成功調(diào)用。2個報文中對應(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的報文，前端根據(jù)報文內(nèi)容點亮左轉(zhuǎn)向燈。實驗中觀察到通信網(wǎng)關(guān)接收到1條id為2、value為1的JSON字符串如圖7所示，同時前端車輛模型完成了左轉(zhuǎn)向燈的點亮狀態(tài)顯示。

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

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

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

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

3.2.1 單項功能場景

設(shè)計實驗1：自動駕駛模塊/域控制器調(diào)用左轉(zhuǎn)向功能測試。自動駕駛模塊或域控制器向車身控制器、電機控制器及轉(zhuǎn)向控制器發(fā)送車輛減速及向左轉(zhuǎn)向的報文。傳統(tǒng)CAN總線架構(gòu)下，3個執(zhí)行單元分別為車身控制器BCM、電機控制器MCU 及轉(zhuǎn)向控制器EPS，自動駕駛決策模塊使用3條周期發(fā)送的CAN 報文發(fā)送至各執(zhí)行器完成左轉(zhuǎn)向功能；SOA 架構(gòu)下，3 個執(zhí)行單元為車身域控制器BDC、動力總成域控制器下的MCU 單元與底盤域控制器下的EPS單元，整個左轉(zhuǎn)向功能定義為1個服務(wù)及3個子服務(wù)，自動駕駛域控制器只需請求單個服務(wù)，各執(zhí)行器接收服務(wù)請求報文并完成左轉(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)在單報文跨域?qū)崿F(xiàn)單條功能的場景下，最大吞吐量均為16 kb·s?1左右，傳統(tǒng)CAN 總線架構(gòu)的報文持續(xù)占用總線，SOA架構(gòu)的報文僅在周期性發(fā)送時占用總線。傳統(tǒng)CAN總線架構(gòu)對CPU的占用率為30%～35%，SOA架構(gòu)對CPU占用率約15%。

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

3.2.2 多項功能場景

設(shè)計實驗2：充電時充電口及電池狀態(tài)的人機交互界面（human machine interface,HMI）顯示功能測試。充電設(shè)備向電池管理系統(tǒng)發(fā)送充電口電流及電壓報文，電池管理系統(tǒng)將車載電池的溫度、電壓及電量與充電口電流及電壓報文發(fā)送至信息娛樂系統(tǒng)的HMI。傳統(tǒng)CAN 總線架構(gòu)下，該功能由電池管理系統(tǒng)BMS 及HMI 之間通信實現(xiàn)，BMS 周期性發(fā)送3 條CAN 報文至HMI；SOA 架構(gòu)下，該功能由動力總成域控制器PDC與信息娛樂域控制器IDC 之間通信實現(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)在單報文跨域?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 實驗結(jié)果分析

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

實驗2 的SOA 報文設(shè)計中，2 個功能域通過1條報文傳輸多個服務(wù)。實驗2 中傳統(tǒng)CAN 總線架構(gòu)的網(wǎng)關(guān)吞吐量及CPU 占用率與實驗1 的同指標(biāo)相比幾乎沒有變化，這是由于其通信報文數(shù)目不變，不存在功能域的概念，本質(zhì)上還是3 個電控單元進行通信。SOA 架構(gòu)的網(wǎng)關(guān)吞吐量及CPU 占用率則明顯優(yōu)于實驗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)能夠為車載CPU節(jié)省更多資源。

4 結(jié)論

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