城市轨道交通车辆制动系统的车地无线通信数据传输各环节常见问题分析及解决方法

孙全涛 崔晓军 杜振振 赵 欣 张乾乾 秦培斌

(中车四方车辆研究所有限公司， 266031， 青岛∥第一作者， 工程师)

在城市轨道交通领域，车辆自身的自动化、信息化已经得到广泛应用，为智能运维发展提供了数据基础[1]。智能运维系统概念的出现，为高效的对车辆故障分析、故障预测进行及时诊断提供了途径。如对其健康状态进行评估，结合维修基地维修资源情况，给出合适的维修决策，以实现关键部件的状态修[2]。

为满足城市轨道交通智能运维的数据需要，本文以城市轨道制动系统为应用背景，以4G(第4代移动通信技术)或5G(第5代移动通信技术)为载体，讨论解决车地无线通信数据传输各环节相关问题，对数据收集的各环节相关策略进行思考、实践和分析。

车地无线通信数据传输环节主要包括车载维护系统终端的数据收集、4G或5G网络的数据无线传输及地面数据中心的数据解析与存储(见图1)。在制动系统的车地无线通信数据传输中：由车载维护系统终端负责收集并打包全列车制动系统的数据；由4G或5G网络，按约定的无线通信协议，将数据传输传回地面数据中心；由地面数据中心进行数据计算及数据分析。

1 车载维护系统终端数据的收集

假设列车为6节编组，且每节车厢长度约为25 m。在制动系统中，每节车辆装有1台或2台制动控制装置。设置于头车和尾车的车载维护系统终端可通过CAN(控制器区域网络)总线或以太网来收集并汇总各制动控制装置的数据信息。

1) CAN方式。如图2所示，CAN以总线形式贯穿全列车，每台制动控制装置采用T型分支连接到CAN。CAN总线需满足高速CAN 物理层规范ISO 11898-2要求[3]。CAN方式的通信波特率为250 kbit。在实际运用中，CAN方式能可靠地以1帧/ms速度传递报文。通过CAN总线，车载维护系统终端可按照一定的时间周期获取到每台制动控制装置的内部数据，形成有序和一定密度的数据。

图1 车地无线通信数据传输示意图

图2 CAN总线方案的T型网络Fig.2 T network of CAN bus scheme

2) 以太网方式。列车以太网方式是未来的发展趋势之一[4]。目前，列车以太网实时通信采用的TRDP(列车实时数据协议)由IEC 61375-2-3[5]定义。TRDP位于应用层，处于以太网传输层之上。车载维护系统终端可通过列车以太网获取到制动控制装置内部数据，并通过网络地址(IP)和网络身份标识进行特定系统数据收集[4]。

2 数据的无线传输

目前数据的无线传输运用4G或5G网络[6]。在实际运用中，CAN总线数据一般按照1 ms或2 ms的间隔对各CAN报文排队调度发送。按最大的通信量需求，车地无线通信数据传输能力要达到10 kB/s以上。此外，车地无线通信数据传输要配合一定策略将数据全部传回数据中心，要保证数据传输的完整性、数据密度的可分析性。

2.1 通信数据协议

对于城市轨道交通车地点对点的特定数据传输，4G或5G选用TCP/IP协议(传输控制协议/互联网协议)。在TCP/IP协议中，传输层选用TCP。车载维护系统终端将实时采集的制动系统数据，以1 s为周期上传到服务器。

如图3所示，4G或5G的TCP/IP协议包含4个操作：

1) TCP连接服务器——终端通过TCP连接命令确认与服务器通信网络的可用性。

2) 设备握手——终端向服务器发送含有设备信息的简单报文，提前从应用层快速确认网络的可用性，并通知服务器使之处于数据接收准备状态。

3) 数据发送——终端向服务器发送数据，并获得服务器确认；否则本次发送失败。

4) TCP断开连接——设备的110 V电源断电后，终端断开与服务器连接。维护终端的非断电情况数据发送完后，TCP不断开保持长连接。

图3 4G或5G的TCP/IP协议操作Fig.3 TCP/IP protocol process of 4G or 5G

对于车载维护系统和地面数据中心采用的TCP通信，每次设备握手所发送的数据量和所需验证时间如表1所示。

2.2 数据发送密度

城市轨道交通车辆制动系统故障分析往往对传输数据的发送密度有一定的要求。如数据发送密度过低，则数据发送时间间隔过长，无法准确分析部分的阀故障或者其他电气故障的原因。

为提高传输数据密度，现有通信方法往往追求极高的数据发送频率。这对地面数据中心的硬件性能和软件性能有很高的要求。随着列车的增多，地面数据中心的通信能力将很快达到饱和状态。

表1 发送特定数据量和所需验证时间

针对这一问题，通过4G或5G网络进行通信数据无线传输时，不再通过加快数据发送频率来满足数据密度的要求，而是将制动控制装置发送到车载维护系统的高密度数据以合理的数据排列形成较大数据包，并将此数据包发送时间周期间隔放缓至秒级。这样不仅能满足不丢包、高数据密度的要求，还能降低对地面数据中心硬件和软件性能要求。车载维护系统将报文内容以相同的时间周期进行打包，并写进时间戳；内部多包相同ID号的CAN数据给出排列序号。

2.3 数据的缓存与续传

在地铁4G网络中，隧道内往往存在通信信号弱或通信异常的情况，而各站点内的通信却能恢复正常。此时，需要采取一定措施，在不影响正常数据传输的情况下对数据进行缓存及续传处理。

当4G网络的无线通信数据传输出现异常时，可先将收到的CAN或TRDP总线数据存储到车载维护系统终端内部的大容量数据循环缓冲区域；当与服务器的网络连接恢复后，为不耽误正常的数据发送，也为了将缓存的数据发回服务器，可在正常数据发送间隔中插空把缓存数据发回服务器。如表1所示，发送1次数据所需的验证时间为100 ms左右，足以插空补发送缓存数据。地面数据中心收到数据后，会按照数据包中的时间戳对数据进行重新排序。

若车载维护系统终端在较长时间(如10 min)内都无法与服务器建立有效通信连接，则终端循环存储区域会将最新接收到的CAN总线或TRDP数据依次覆盖旧数据，并将此异常事件写入车载维护系统终端的日志系统中。在通信恢复后，车载维护系统终端只能发送当前循环缓冲区域中的数据，而无法发送已被覆盖的旧数据。车载维护系统终端收到的全部CAN总线或TRDP数据的副本会同步存储在终端的SD卡(Secure Digital Memory Card)中。如需读取丢失的数据，则可通过终端维护软件读出SD卡存储数据，并进行后续处理。

2.4 数据安全性

数据安全性主要从两个方面来保证：在网络层，通过通信公司专设的隧道技术来传输数据；在应用层采用对称加密技术，由车载维护系统终端在业务数据中使用加密算法，由地面数据中心在接收时进行解密。

3 地面数据中心的数据解析存储

地面数据中心的数据解析存储过程如图4所示。地面数据中心收到无线通信数据包后，可将数据包中的相关线路、车辆编号及设备等信息存入原始数据队列中，继而解析、存储可按线路、车辆编号及设备等区分处理，便于后续数据运用。

图4 地面数据中心的数据解析存储过程Fig.4 Data analyzing and storage process of ground datacenter

原始数据队列缓冲可通过缓存，以解决地面数据中心各个子系统的性能差异及延迟等问题。例如，通过Kafka分布式数据流处理系统对接收到的数据报文进行缓存，可有效解决各子系统数据处理速度差异及可靠性低等问题。

缓存后的数据可按需求解析成各物理量，也可直接按原始数据存储。

不同线路、不同系统的数据协议往往存在差异性。为能够在不同设备的不同协议下实现通用的数据解析和存储，可通过建立数据解析子系统来承载各系统不同线路的数据协议，并将设备和数据协议用模型表示。当数据报文进行解析时，可根据线路、车辆编号及设备去识别子系统中的协议模型，并按照协议模型的语言去解析和存储数据，以实现通用性。

即便数据协议后期增加内容，只要将拓展的数据协议和设备用模型来表示，就可以将增加的内容进行数据的解析存储。统一解析后的数据可按照时间序列进行数据排列，为同一物理量数据进行纵向对比和不同物理量间进行横向对比提供了时间排列基础。

人员对制动系统进行维护及相关故障分析可通过VPN(虚拟专用网络)技术访问地面数据中心，再根据线路、车辆编号及设备等信息进行数据实时监控或对历史数据进行数据查看分析。

4 结语

本文基于城市轨道交通车辆的制动系统，介绍了制动系统车地无线通信数据传输的流程，分析了数据传输各环节常见的问题，并给出了相应解决办法。车载维护系统终端数据收集的CAN总线方案已在实际中装车使用，验证了其有效性。针对无线通信数据传输信号弱与数据密度问题，提出了通过合理的数据排列，将数据发送时间间隔放缓至秒级的解决办法。地面数据中心应按相关线路、车辆编号及设备等信息，通过数据解析子系统来完成数据通用解析和存储。