無人車載網絡高可靠HUB的設計

楊嘉睿，婁岱松，許志偉，汪 震，毛漢領+，朱紀洪

(1.廣西大學 機械工程學院，廣西 南寧 530004；2.清華大學 精密儀器系，北京 100084)

0 引 言

無人車的主要系統(tǒng)由感知、決策和控制等子系統(tǒng)組成。其中控制系統(tǒng)的好壞決定了無人車的性能優(yōu)劣。主控節(jié)點對各執(zhí)行機構的有力控制都依賴于日趨智能化、多用途的車載數(shù)據鏈[1]，要求車載網絡向著高可靠、高帶寬和抗干擾能力強等方面發(fā)展[2]。

車載網絡經過多年發(fā)展，已經集合了包括CAN總線[3]、LIN總線[4]、FlexRay總線[5]等網絡技術，近年來，TTP總線[6]因其具有高安全性、高確定性的技術特點，越來越多的應用在車載網絡當中。但隨著車載系統(tǒng)的數(shù)據量劇增，這些網絡暴露出帶寬不高的特點，例如FlexRay總線總傳輸速率為20 M/s[7]，這使得一般的網絡技術逐漸不再適應車載網絡的發(fā)展。

另外，總線型網絡的任一節(jié)點故障都將引起整個網絡失效。例如CAN總線短路會影響總線差分電平，總線將無法正常工作；斷路會使得斷路節(jié)點以外的節(jié)點脫離總線，影響實時通訊[8]；過長的總線會影響傳輸效率，在實際應用中具有一定的局限性[9]。

基于此，研究人員不斷探索優(yōu)化總線通信的方法。例如面對1553B總線存在的通信速率低、故障隔離困難等問題[10]，采用雙冗余通信裝置設計，發(fā)生故障時進行余度切換，提高網絡可靠性[11]。但類似方法多是通過冗余設計提高可靠性，未根本解決總線型通信的帶寬和可靠性問題。

時間觸發(fā)以太網TTE[12]速率高、可靠性高，帶寬可達10 Gb/s，通信的實時性好[13]。另外，在TTP總線中設計星型架構，以點對點的連接代替總線結構，即使一點斷開，整體網絡不會失效。例如有研究人員根據星型TTP總線提出了HUB的設計架構[14]，為總線型網絡的升級提供了新的思路。

本文設計了一種車載網絡HUB集線器，作為主控節(jié)點和驅動設備的中間節(jié)點，設計“時間觸發(fā)以太網(TTE)+星型TTP總線”的通信架構，提高了網絡帶寬和可靠性。

1 無人車底盤網絡架構

1.1 基于TTP的車載底盤網絡

圖1為基于TTP的車載底盤網絡，由4余度總線主網、3余底盤控制主節(jié)點和多個驅動設備組成，其中包括8個輪轂電機、8個懸掛和8個剎車驅動器，使用時間觸發(fā)總線將各個節(jié)點進行時間同步，根據協(xié)議進行調度和控制[15]。

圖1 基于TTP的車載底盤網絡

采用故障樹分析方法研究底盤網絡的可靠性和失效概率。圖2為單余度總線網絡故障樹，其中A1代表底盤節(jié)點失效的底事件，B1、B2表示底盤子網中TTP鏈路失效的底事件，B3代表主網鏈路失效的底事件。由經驗可得，硬件節(jié)點的故障失效率為1×10-5次/h，數(shù)據傳輸鏈路的故障失效率取1×10-6次/h，依據此進行量化分析。

圖2 單鏈路總線網絡故障樹

圖2的故障樹中，各基本事件相互獨立，根據故障樹結構進行概率求解，其中用與門連接的頂事件發(fā)生概率為

(1)

用或門連接的頂事件的發(fā)生概率為

(2)

根據式(1)和式(2)計算失效概率，得到1-4余度總線網絡失效概率見表1。

表1 不同余度下總線網絡失效的概率

由表1可知，總線與板卡都為雙余度時，失效概率為1.020×10-10次/h，滿足機載/車載網絡失效概率為1×10-9次/h的指標要求。但是考慮到總線性網絡一點斷開，整體失效的特點，還需增加余度設計。板卡3余度、總線3余度時的失效概率比都為雙余度時小50%，4余度總線可靠性與3余度基本一致，若按照3余度進行設計，會產生主從節(jié)點對帶寬的搶占問題，并增加設計難度。故采用4余度設計，增加一條總線供主控節(jié)點使用。

通信質量方面，為了保證控制精度，并且24個驅動器的反饋數(shù)據在同一周期上傳至總線，網絡使用的波特率為6.25 M。使用高波特率進行數(shù)據傳輸，雖然滿足了網絡的功能要求，但隨著波特率增大，數(shù)據波形每一位的持續(xù)時間變短，受到無人車內多有高壓電磁環(huán)境的干擾，很有可能改變數(shù)據波形，從而引起了誤碼率的增大[9]。

故障安全方面，總線型通信架構由于其本身的特點，一點發(fā)生故障，可能會造成整體網絡的失效。例如總線中一點斷路，整條總線會失效，一點短路，會危及到整條總線的安全。

維護升級方面，總線型網絡發(fā)生故障時，需要檢測每一個設備節(jié)點和通信線路，才能發(fā)現(xiàn)所以失效節(jié)點，維護較為困難。除此以外，總線性網絡帶寬較低，不支持在網絡中使用交換技術，網絡無法采用分層結構，限制了開發(fā)人員進行拓展，在升級空間方面存在較大的限制。

1.2 基于HUB的底盤網絡

以時間觸發(fā)以太網TTE為基礎，底盤節(jié)點設計5 ms的周期發(fā)送指令幀，經交換機組播發(fā)送給4個HUB。HUB將指令幀中的控制字節(jié)進行提取，封裝成控制幀(本文將底盤節(jié)點發(fā)給HUB的以太網指令幀簡稱為指令幀，將HUB發(fā)給驅動設備的串口指令數(shù)據稱為控制幀)，通過串口通信模塊同時發(fā)送給6個驅動設備，完成控制過程，驅動設備在接收到控制幀間隔500 μs后發(fā)送反饋數(shù)據。HUB將6路反饋數(shù)據封裝成以太網幀發(fā)給底盤節(jié)點，完成反饋過程(本文中反饋幀特指HUB發(fā)給底盤節(jié)點的反饋數(shù)據)。控制信息收發(fā)過程與反饋數(shù)據收發(fā)過程一起完成整個的通信過程。驅動器包含8個輪轂、8個懸掛、8個剎車，每個HUB與兩個剎車、兩個懸掛、兩個輪轂電機驅動器相連接。基于HUB的雙余度底盤網絡連接方式如圖3所示。

圖3 基于HUB的雙余度的底盤網絡

根據網絡拓撲結構，進行故障樹分析，圖4為單鏈路HUB底盤網絡故障樹，其中，A0代表交換機板卡失效；A1代表底盤板卡失效；A2、A3、A4和A5代表4個HUB板卡失效；B1代表底盤與交換機之間的通信鏈路失效；B2、B3、B4和B5代表4個HUB與交換機之間的通信鏈路失效；C1到F6分別代表4個HUB與24個驅動器之間的星型TTP鏈路失效。

圖4 單鏈路HUB底盤網絡故障樹

根據式(1)和式(2)可得單鏈路HUB底盤網絡故障概率為1.000×10-5次/h，表2中列出1至4余度鏈路下網絡的失效概率。可以看到，此種底盤網絡設計在雙余度時的故障率滿足1為1×10-9次/h的指標要求，并且低于1.1中雙余度總線型網絡故障率。為滿足車載網絡的使用要求并兼顧質量和成本，采用雙余度設計。

表2 1至4余度下網絡失效的概率

2 HUB節(jié)點的設計

2.1 硬件平臺設計

HUB板卡的設計方案如圖5(a)所示，采用“核心架構+底板功能模塊”的設計。核心架構設計為FPGA+DSP，采用創(chuàng)龍公司的SOM-TL2837xF核心板，上有Xilinx公司的Spartan6芯片和TI公司的F28377芯片，兩者可通過EMIF模塊進行數(shù)據交互；設計電源模塊用于核心板及底板供電；JTAG模塊用于FPGA與DSP程序燒寫；GPIO管腳引出測試信號，方便板卡調試；以太網通信模塊和串口通信模塊用于數(shù)據交互。HUB板卡PCB如圖5(b)所示，由于單塊底板空間資源限制，HUB板卡設計為“底板+拓展蓋板”，底板上的B2B連接器安置核心板，排針用于連拓展蓋板，4路串口與網口安置在底板上，另外4路串口設計在拓展蓋板上，圖5(c)為HUB節(jié)點實物圖。

圖5 HUB板卡硬件設計

RS485通訊具有兼容性高，抗干擾性好的特點[16]，星型TTP協(xié)議根據RS485接口設計。采用一塊隔離式RS-485收發(fā)器ADM2582E芯片實現(xiàn)通信協(xié)議，它能夠對信號和電源隔離，抗干擾性強。ADM2582E芯片的TXD和RXD引腳連接到FPGA芯片分配的數(shù)據信號接口相連接，F(xiàn)PGA_DE_E與FPGA_RE_E為發(fā)送與接收端的使能信號。采用ACT45B-220-2P共模濾波器連接在A、B和Z、Y兩端，用于濾除共模干擾，提高通信質量。通過是否保留A、Y和B、Z引腳間連接的0 Ω電阻，可以對電路進行RS485/422模式切換。建立A、B、C、D、E、F、G、H這8路收發(fā)器，其中六路串口與6個驅動器通信，另兩路做冗余備用設計。串口通信電路設計如圖6(a)所示。以太網協(xié)議規(guī)定，每臺設備的物理地址唯一，故只在板卡上設計一個網口模塊，物理層設計PHY芯片和千兆網口用于數(shù)據吞吐，其中PHY芯片采用Realrek公司的RTL821F1EGMII芯片，支持10/100/1000 Mbps的網絡傳輸速率，滿足數(shù)據量增加對帶寬的要求。網口通信電路設計如圖6(b)所示。

圖6 通信電路設計

2.2 HUB節(jié)點整體軟件架構

整體軟件架構為FPGA+DSP的模式，F(xiàn)PGA進行數(shù)據吞吐，包括以太網模塊和TTP總線模塊；DSP對應用數(shù)據進行解析處理。FPGA與DSP在物理層通過EMIF接口連接，設計EMIF讀寫控制模塊和EMIF數(shù)據交互模塊實現(xiàn)板卡內數(shù)據互通。HUB節(jié)點軟件架構如圖7所示。

圖7 HUB節(jié)點軟件構架

2.3 FPGA軟件架構

FPGA軟件架構為基于自定義以太網協(xié)議的以太網通信模塊、基于SCI協(xié)議的TTP通信模塊和EMIF讀寫控制模塊。以太網數(shù)據模塊負責收發(fā)以太網數(shù)據，按照協(xié)議進行解析；SCI模塊進行串口數(shù)據幀的收發(fā)；EMIF讀寫控制模塊通過控制EMIF數(shù)據總線和EMIF地址總線使FPGA與DSP進行數(shù)據交互。FPGA整體軟件架構如圖8所示。

圖8 FPGA整體軟件構架

以太網部分采用PHY芯片連接到FPGA芯片Spartan6的IO接口的設計方案，通過GMII接口網速可達千兆。通過自主設計的以太網模塊，自下而上完成以太網幀的解析和應用數(shù)據的提取，數(shù)據鏈路層到網絡層解析使用以太網協(xié)議的CRC32校驗；除此之外，在數(shù)據幀的應用數(shù)據段尾部加入CRC-32/MPEG-2校驗進一步增加網絡的檢錯能力。

TTP部分軟件基于SCI協(xié)議制定，共有6路。本設計中，考慮到FPGA資源消耗情況并留下升級空間，并不是每個SCI模塊都設計收發(fā)功能。只在E路設計SCI_TXE，發(fā)送輪轂剎車指令幀，即將輪轂和剎車的指令放在同一數(shù)據段，一分四發(fā)給E、F、A、B路，驅動器根據協(xié)議自行解析提取。同理，用SCI_TXG發(fā)送懸掛控制幀給G、H路，用一幀數(shù)據進行多路轉發(fā)代替重復設計相同的通信鏈路，提高了芯片資源的利用率。在每一路SCI模塊中，采用CRC-32/MPEG校驗并提前20 μs拉高發(fā)送使能，數(shù)據發(fā)送完畢后20 μs拉低發(fā)送使能，進一步提高可靠性與通信質量。

2.4 DSP軟件架構

DSP程序主要負責數(shù)據處理，當HUB節(jié)點接收指令幀時，DSP通過EMIF接口輪詢FPGA寫過來的計數(shù)更新字節(jié)。若計數(shù)更新加一，將指令幀中與末端驅動器對應的指令字節(jié)保存至對應的結構體，DSP調用串口數(shù)據發(fā)送函數(shù)通過EMIF將數(shù)據段寫入FPGA中SCI模塊對應的RAM。反饋數(shù)據發(fā)送時，DSP同樣根據計數(shù)更新讀入反饋數(shù)據，寫入到以太網反饋數(shù)據幀中，調用以太網幀發(fā)送函數(shù)通過EMIF寫入FPGA的以太網模塊對應的RAM。DSP軟件架構如圖9所示。

圖9 DSP軟件架構

2.5 指令幀的組播功能設計

HUB節(jié)點指令幀的發(fā)送設計為組播方式，5 ms為周期定時發(fā)送。以HUB_A1至HUB_A4為例，HUB節(jié)點的組播號、IP地址和組播IP見表3。底盤節(jié)點發(fā)送指令幀時，DSP將組播IP地址傳遞給FPGA，F(xiàn)PGA程序根據組播IP將指令幀的目的MAC地址封裝為48’h7f_ff_ff_ff_ff_ff，交換機根據組播MAC地址同時向其它端口發(fā)送指令幀，HUB節(jié)點中的FPGA程序通過組播MAC地址接收指令幀，并且當目的IP地址為組播IP地址時，才將數(shù)據幀中的應用字段傳遞給DSP，保證了數(shù)據幀傳輸?shù)臏蚀_性。

表3 HUB節(jié)點的組播號與IP地址

3 HUB節(jié)點通信功能測試

3.1 HUB節(jié)點通信功能測試

設計實驗，對HUB節(jié)點通信功能進行測試。以交換機為中心，連接底盤節(jié)點、HUB節(jié)點與PC端，設計交換機的端口1為組播端口，底盤節(jié)點通過網線連接到交換機的組播端口。再使用輪轂一個驅動器連接HUB節(jié)點，進行通信鏈路搭建，引出串口數(shù)據至示波器進行觀察記錄，并使用PC端監(jiān)測以太網幀，若串口數(shù)據異常，檢查以太網幀數(shù)據。

實驗原理及數(shù)據流向為底盤板卡按照5 ms的周期通過網口發(fā)送指令幀，通過交換機的組播端口將指令幀轉發(fā)到其它端口，HUB接收指令幀后會在FPGA內部校驗組播MAC地址，符合設計要求才繼續(xù)上傳以太網幀，在DSP中將以太網幀解析處理成串口控制幀通過FPGA發(fā)送到串口E，通過底盤集線器發(fā)送給輪轂驅動器E，輪轂驅動器接收到數(shù)據后相隔500 μs會向HUB節(jié)點發(fā)送串口反饋幀。實驗中，HUB節(jié)點與輪轂驅動器通過RS485方式連接，將差分電平引出接示波器進行觀察。

由圖10(a)可得，示波器截取28組指令幀與反饋幀，每一幀指令數(shù)據之后都跟著一幀反饋數(shù)據，可以初步驗證通信鏈路的穩(wěn)定性。由10(b)可得，兩個指令幀發(fā)送之間的時間間隔為5 ms，由圖10(c)可得，兩個反饋幀之間的時間間隔為5 ms，數(shù)據幀的時間間隔正確。由圖10(d)可得，指令幀與反饋的時間間隔為494 μs，約為500 μs，滿足設計要求。如圖10(e)所示，通信一次的總時間約為2.132 ms，相對于5 ms一次的通信過程，占比時間在50%以下，對信道的壓力不大，數(shù)據幀之間也不會因為相隔過近產生干擾。如圖10(f)所示，為原總線型架構時，底盤節(jié)點和兩個懸掛驅動器的通信情況，在100 ms內僅有26組指令幀與反饋幀時，發(fā)生兩次丟幀情況，通信質量低于HUB構型網絡。

圖10 通信時間測試

3.2 HUB節(jié)點反饋幀丟幀測試

底盤網絡是無人車能否正常行駛的基礎，HUB節(jié)點在功能上經過測試，可以初步完成底盤網絡通信過程，但通信時若有丟幀現(xiàn)象發(fā)生，即不能及時的將狀態(tài)信息反饋給底盤節(jié)點，底盤節(jié)點不能及時根據車輛狀態(tài)進行控制，會造成車輛行駛或姿態(tài)控制的閉環(huán)控制功能受到影響，嚴重時可能導致車輛行駛失控，故對網絡的可靠性，即是否丟幀進行測試十分重要。

實驗采用一個底盤節(jié)點板卡、一個HUB節(jié)點板卡、一個交換機板卡、兩個輪轂驅動器、兩個懸掛驅動器、兩個剎車驅動器，連接設備所用的網線等器材。使用示波器和PC端觀察數(shù)據的傳輸情況，并且在PC端采用QT上位機軟件接收HUB板卡發(fā)送的280字節(jié)以太網反饋幀。丟幀測試設備連接方式與示意圖如圖11(a)所示。根據連接示意圖，使用實物搭建丟幀測試設備如圖11(b)所示，底盤節(jié)點、HUB_A1和PC端通過千兆網線連接至交換機；HUB_A1板卡上的E、F、G、H這4路串口通過專用集線器與末端驅動設備連接。集線器一端為DB37插頭連接HUB_A1，另一端為4路DB9插頭連接末端驅動器，中間為屏蔽型雙絞線，可以在物理層進一步防止干擾；A、B兩路串口信號由底部插座引出，物理層同樣使用DB9插頭和雙絞線設計。如圖11(c)和圖11(d)所示，通過wireshark抓包軟件觀察數(shù)據流向、相關參數(shù)及數(shù)據包結構，可以看到指令幀發(fā)送后和反饋幀按照設計要求進行傳輸，相關參數(shù)例如組播IP結果滿足設計要求。

圖11 丟幀實驗測試

實驗原理為在驅動器的反饋數(shù)據中的保留位設置相鄰兩字節(jié)為計數(shù)字節(jié)，每發(fā)送一幀數(shù)據，計數(shù)位加1，這些計數(shù)位會和反饋數(shù)據段一起封裝在反饋幀里，上位機接收反饋數(shù)據并保存，用MATLAB軟件對數(shù)據幀進行處理，第一步先將HUB反饋幀以太網首部字節(jié)中的計數(shù)位進行依次相減，驗證以太網數(shù)據傳輸?shù)目煽啃裕^察差值是否為1，若為1，證明沒有丟幀，若差值為0，說明有重復幀，若差值大于1，說明有丟幀情況。再對反饋幀中儲存各驅動器反饋信息字段中的計數(shù)字節(jié)進行處理，處理方法與首部計數(shù)位一致，計數(shù)位連續(xù)才能說明反饋數(shù)據的傳輸是可靠的。

如圖12所示，本文使用QT軟件設計通信測試上位機，QT是QT Company公司研發(fā)的可支持跨平臺的C++圖形用戶界面，編寫完成后可以在不同的平臺下編譯[17，18]。本上位機可以通過靈活設置IP地址和端口號，接收不同通信節(jié)點發(fā)送的以太網幀，并將其以TXT文件格式自動保存，設計UI界面顯示UDP接收次數(shù)，便于實驗觀察。由于要將PC端作為數(shù)據的接收方，所以在實驗前，將HUB板卡發(fā)送反饋幀的目的地址由192.168.10.7改為192.168.10.188，即將本機的IP地址設為192.168.10.188，遠程IP地址設為192.168.10.60，本機端口號設為61441(目的端口號)，遠程端口號設為61440(源端口號)。連接后，PC端會接收數(shù)據并保存，本實驗的樣本容量為一萬幀數(shù)據，在UDP接收次數(shù)窗口顯示數(shù)值超過一萬時，結束數(shù)據接收。若連續(xù)一萬幀數(shù)據無丟幀，重復幀現(xiàn)象，即故障率至少小于10-4，可以達到使用要求。

圖12 通信測試上位機界面

在MATLAB中對收到的數(shù)據幀進行16進制轉十進制的操作，將其分為280字節(jié)一組，由于采取小端序傳輸數(shù)據，將相鄰兩字節(jié)置位并拼接為兩字節(jié)的數(shù)據，得到若干組數(shù)據，每一組數(shù)據為140個，對每個數(shù)據進行編號。

如圖13(a)所示，首先分析反饋幀首部的計數(shù)位，檢查發(fā)送過程中是否丟幀，計數(shù)位依次相減的值為縱坐標，以太網幀數(shù)量為橫坐標，可以得到實驗結果如圖13所示。由實驗結果可得，連續(xù)一萬幀數(shù)據的以太網首部計數(shù)位依次相減的結果為1，沒有大于1或小于1的情況出現(xiàn)，說明無丟幀和重復幀的情況。如圖13(b)所示，另外對反饋幀中6個驅動器的反饋數(shù)據進行丟幀測試，監(jiān)測末端驅動設備向HUB節(jié)點反饋數(shù)據是否有丟幀或重復幀產生。實驗結果如圖13所示。由圖可得，6個數(shù)據段的計數(shù)位差值都等于1，說明無丟幀和重復幀現(xiàn)象，可以認為末端驅動器與HUB之間的通信鏈路的可靠性是有保證的。

圖13 通信丟幀測試

4 結束語

本文通過對總線型通信模式存在的通信質量和可靠性問題的總結，對時間觸發(fā)以太網TTE和星型TTP總線進行研究，在軟硬件層面上設計了一種HUB，并且設計了基于HUB的底盤網絡，可以對總線型通信架構進行替代，網絡帶寬可達千兆，提高了可靠性，對通信質量有好的改進，并且便于故障檢測與排除。除此之外，本文設計實驗對HUB網絡與總線式網絡的通信情況進行對比測試，驗證HUB網絡有效提高了通信質量。伴隨著無人車系統(tǒng)的不斷升級，此HUB的設計及使用具有重要意義。