1 汽車電子電氣架構設計

1.1 架構設計原則

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

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

圖1 域集中式汽車電子電氣架構

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

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

圖2 架構設計示意圖

1.3 基于SOA的汽車通信服務架構設計

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

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

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

圖4 SOME/IP報頭格式

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

表1 各功能域SOME/IP部分服務

2 測試平臺構建

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

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

圖5 平臺整體結構示意圖

表2 網(wǎng)關與通信網(wǎng)絡轉向燈部分通信報文格式

表3 架構上部分SOME/IP服務

3 集中域式電子電氣架構功能驗證

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

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

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

圖6 架構功能驗證示意圖

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

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

過程②：自動駕駛域控制器經(jīng)過架構中央網(wǎng)關向車身域控制器發(fā)送轉向燈服務請求，請求包使用SOME/IP協(xié)議，包內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，即需要響應的器件為左轉向燈，status 值為1，即狀態(tài)為亮起。觀察到中央網(wǎng)關接收到了Request 報文，報文內各屬性值及Payload部分與上文中的定義一致，見圖8a。

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

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

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

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

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

3.2 單條報文跨域實現(xiàn)功能性能驗證

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

3.2.1 單項功能場景

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

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

圖11 單功能場景2種架構的指標對比

3.2.2 多項功能場景

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

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

圖12 多功能場景2種架構的指標對比

3.2.3 實驗結果分析

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

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

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

4 結論

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