1 汽車電子電氣架構設計

1.1 架構設計原則

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

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

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

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

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

圖2 架構設計示意圖

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

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

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

圖3 SOME/IP在車載以太網7層模型的位置

圖4 SOME/IP報頭格式

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

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

2 測試平臺構建

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

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

圖5 平臺整體結構示意圖

表2 網關與通信網絡轉向燈部分通信報文格式

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

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

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

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

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

圖6 架構功能驗證示意圖

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

圖7 網關程序接收到的報文

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

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

圖8 中央網關上抓取到的Request包和Response包

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

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

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

3.2 單條報文跨域實現功能性能驗證

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

3.2.1 單項功能場景

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

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

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

3.2.2 多項功能場景

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

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

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

3.2.3 實驗結果分析

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

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

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

4 結論

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