无人车载网络高可靠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的设计及使用具有重要意义。