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

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

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

0 引 言

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

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

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

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

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

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

1 無人車底盤網絡架構

1.1 基于TTP的車載底盤網絡

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

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

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

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

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

(1)

用或門連接的頂事件的發生概率為

(2)

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

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

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

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

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

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

1.2 基于HUB的底盤網絡

以時間觸發以太網TTE為基礎，底盤節點設計5 ms的周期發送指令幀，經交換機組播發送給4個HUB。HUB將指令幀中的控制字節進行提取，封裝成控制幀(本文將底盤節點發給HUB的以太網指令幀簡稱為指令幀，將HUB發給驅動設備的串口指令數據稱為控制幀)，通過串口通信模塊同時發送給6個驅動設備，完成控制過程，驅動設備在接收到控制幀間隔500 μs后發送反饋數據。HUB將6路反饋數據封裝成以太網幀發給底盤節點，完成反饋過程(本文中反饋幀特指HUB發給底盤節點的反饋數據)。控制信息收發過程與反饋數據收發過程一起完成整個的通信過程。驅動器包含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節點的設計

2.1 硬件平臺設計

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

圖5 HUB板卡硬件設計

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

圖6 通信電路設計

2.2 HUB節點整體軟件架構

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

圖7 HUB節點軟件構架

2.3 FPGA軟件架構

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

圖8 FPGA整體軟件構架

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

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

2.4 DSP軟件架構

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

圖9 DSP軟件架構

2.5 指令幀的組播功能設計

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

表3 HUB節點的組播號與IP地址

3 HUB節點通信功能測試

3.1 HUB節點通信功能測試

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

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

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

圖10 通信時間測試

3.2 HUB節點反饋幀丟幀測試

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

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

圖11 丟幀實驗測試

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

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

圖12 通信測試上位機界面

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

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

圖13 通信丟幀測試

4 結束語

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