青岛地铁2号线车地上传数据解析技术的研究与应用

尹星、左元堃、刘祖聪、于浩

（青岛地铁运营有限公司，山东 青岛 266000）

1 技术背景

车地上传是一项使用计算机技术将列车关键信息发送至地面进行解析的技术，其中车指的是城轨车辆，通常以列为单元。地指的是地面用于数据接收与解析的工作站，通常部署在调度中心、运维中心等场所。上传指的是列车数据发送至地面的过程，因地面工作站往往是一台，在通信过程中担任服务器角色，而列车数量为多列，担任客户端的角色，所以列车至地面的数据发送称为上传。

列车数据以列车通信网络（TCN）上传输的数据为主，以青岛地铁2 号线电客车为例。列车通信网络采用多功能车辆总线（MVB），MVB 硬件层及链路层遵循IEC61375 标准，列车各个系统间均使用MVB 进行数据交互，并具有良好的信号屏蔽，传输速率为1.5Mbit/s[1]，数据格式因机车厂与车型的不同均有差别，但所有MVB 数据均包含列车关键的运行信息，若MVB 网络瘫痪则将直接导致列车无法正常运行。

由于MVB 网络数据具有重要意义，所以列车运行中就需要对其内容进行解析，常见的方法为使用司机显示器（DDU），DDU 将MVB 中的故障数据、状态数据进行图形化处理并显示，司机通过DDU 内容可了解列车当前状态。但这一方法存在局限性，列车相对于地面高速运动，运行距离较远，且通常一列车配备一名司机，列车在正线运营过程中出现故障的概率较大，司机无法全面地了解列车状态，所以在列车遇到突发情况时，司机处置往往无法做到迅速准确。车辆专业工程师也无法及时地了解车辆状态，这样就容易导致信息不对称，延误处置。

2 系统原理

2.1 车地上传系统实现方式

列车控制与监控系统(TCMS)主要对MVB 数据进行管理，人机交互仍通过DDU 进行，同时列车TCMS因稳定性需要，性能受到限制，通常只处理列车运行逻辑，并对部分状态量、模拟量进行监控，想要实现列车MVB 数据全面监控则需要引入一套独立于列车控制系统的计算设备，该设备需要具备单向传输的特性，即设备仅接受MVB 数据并不参与控制，这套计算设备可称为服务器、工作站。

为了全面地掌握上线列车的运行状态、所有列车数据应集中管理，处理数据的工作站设置在地面控制中心。但列车MVB 网络数据通过双绞线传输，列车位置不固定，无法直连到地面，这就需要引入一种无线传输方式。过去射频通信方式稳定性较差，民用移动以太网带宽不高，但随着4G 等无线通信技术的普及，使用4G 技术实现高速、大带宽以太网通信成为解决这一问题的最佳方案[2]。

2.2 车地上传系统运行原理

实现车地上传的第一步是建立MVB 与以太网的通道，青岛地铁2 号线列车使用信号系统网络通道传送数据，PIDS 系统MVB 板卡接入列车MVB 网络，接收MVB 网络上特定端口的数据。参考《列车控制监控系统(TCMS)与乘客信息系统（PIS）通信接口协议》，2 号线PIDS 系统与TCMS 系统通信共使用18 个端口，端口地址详见表1。

表1 TCMS 系统（CCU）与PIS 之间通信端口分配表

以0x0A0 端口为例，A0 端口数据长度为32 字节，轮询周期为256 毫秒，轮询周期决定数据的刷新速度。

A0 端口数据含义见图1，此处注意区分数据类型，上表内字偏移指的是双字偏移，双字（WORD16）又称DWORD，长度为两个字节（BYTE），字偏移起始0，结束15，共16 个双字，32 个字节。表中BitNo 为二进制偏移，一个双字有16 个二进制位，每一位可表示不同的数据。高位在前二进制位偏移见表2。

图1 TCMS 发送给PIS 数据图

表2 二进制位偏移数据

通过二进制偏移可提取每个二进制位的含义，提取、存储、分析数据的过程称为数据的解析。在此之前MVB 板卡还需将数据发送至以太网，数据组合（打包）的过程由MVB 板卡内部程序负责，本文不再叙述。

MVB 板施工以太网接口将数据发送至车载信号交换机，交换机使用无线方式接入整个信号网络，车地网络通道拓扑图2如下：

图2 车地网络通道拓扑图

2.3 车地上传系统功能实现原理

地面工作站通过解析软件进行数据包解析，同时进行图形化显示与存储。解析软件主要实现以下几个功能：

2.3.1 列车数据本地定义

解析软件需要判断数据来源，即列车号，通常使用两个方式进行判断，一是通过数据包内，MVB 总线上的ATC Train ID 数据进行判断，二是通过来源IP地址进行判断，列车数据包是以UDP 广播的形式发送，接收端可识别到发送端的IP 地址通过IP 地址，可区分数据的来源。通过本地数据库（SQLite）预先定义车号与IP 地址的关联，解析软件启动后加载到内存链表内，在接收数据时按车号进行数据包分类。

2.3.2 关键字定义

解析软件在接收到某一列车数据后，会对数据包进行解析，解析过程依赖数据位置与数据含义的对照关系，正如《列车控制监控系统(TCMS)与乘客信息系统（PIS）通信接口协议》中定义的那样，数据含义以端口、双字偏移、位偏移共同组成。以门全关闭信号为例，该信号数据定义见图3，数据解释名为“1 车DIM1列车门全关闭状态”，端口号为10，数据包状态为1，双字偏移为2，比特偏移为7，需要查询“1 车DIM1 列车门全关闭状态”这个状态量时，可读取端口10，第1状态，第2 个双字节的第7 个比特位，因为该数据是二进制存储，1 代表有效，0 表示无效。

图3 1 车DIM1 列车门全关闭状态数据定义图

如果该数据为故障数据，则需要特别表示以司机室多主控故障为例，该信号数据定义见图4，0 或1 两种状态必须设定何为故障状态，何为正常状态，在本地数据库中需要定义其故障标识位，Fault 字段为1 则表示数据为故障数据，FaultValue 为故障值亦为1，表示该数据为1 时故障，0 表示正常，没有该故障。

图4 司机室多主控故障数据定义图

解析软件启动时加载关键字定义表到内存链表，在查找指定数据的值时，程序可通过解析名直接获取。以获取车号为例，调用find_target 函数，函数内部进行查表，如图5所示。

图5 find_target 函数程序示例图

2.3.3 故障处理原理

在读取关键字时，每种数据就可以根据Fault 值判断是否为故障数据，以及判断是否发生故障的FaultValue 数据。故障数据约为2000 个以上，每秒都会接收到列车数据，数据包大小为520 字节，到达后逐位进行IF 判断则会消耗大量性能。所以程序在加载时首先筛选全部故障数据的位置，并生成掩码，在接收数据后首先将数据与掩码进行与计算，剔除无用的数据位，随后仍为1 的位与FaultValue 进行异或计算，从而筛选出有效的故障位。目前普遍采用的64 位CPU 与64 位系统可高效地进行故障判断，一条运算指令可处理8 字节即4 个双字，一个32 字节的端口数据最少执行4 次就可以判断是否存在故障，使用合理的算法提高了处理性能。随后将故障显示在界面上，并伴随语音提示，同时将故障数据存储在数据库内，此时SQLite 数据库性能已无法满足要求，需要使用性能更好的MySQL 数据库，故障数据存储后，程序实现了查询接口，检索历史故障。

3 系统应用

该系统已在青岛地铁2 号线投入使用，车辆专业工程师可根据系统主界面显示，获取当日所有上线列车的运行状态、当前故障等信息，主界面如图6所示。当列车发生故障时，会触发弹窗提醒工程师第一时间关注，缩短了故障信息以各种形式上报至车辆专业、乘务专业的时间。双击主界面可进入单列车界面，单列车界面可分类显示列车各系统的故障、状态。

图6 系统主界面图

4 结语

青岛地铁2 号线电客车通过运用车地上传数据解析技术，将列车关键运行数据同步至地面终端，缩短了故障响应时间，提高了故障处置效率，验证了该线路电客车向数字化、智能化运维过渡的可行性，为后续数据深度运用奠定基础