城市轨道交通列车实时数据处理与应用研究

曾高平，王 磊

（株洲中车时代电气股份有限公司，湖南 株洲 412001）

0 引言

2020年，中国城市轨道交通协会发布了《中国城市轨道交通智慧城轨发展纲要》[1]。纲要明确了以云计算、大数据[2]等新兴信息技术与城市轨道交通（简称“城轨”）深度融合为主线，推进城轨信息化、发展智能系统、建设智慧城轨的发展路径[3-4]。随着运营线路和运营里程的增加，运营规模的持续增长给城轨运营单位带来了一系列的挑战，如对设备状态评估、故障诊断、故障预测及维修模式等提出了更多、更高的要求[5]。列车状态在途监测属于车辆运维中的一个重要板块，其主要通过采集列车的实时数据对列车的行驶状态、关键系统运行状态进行监测，实现对列车的状态感知。城轨运营单位通过借助车辆的实时数据，实现对车辆的实时监测、故障预警、应急响应、维修决策等目标[6-7]，构建智能运维体系[8-9]以提升列车运营[10]的质量。因此，基于列车数据并结合运营实际需求，构建一套列车实时数据处理及快速应用的架构尤为重要。本文通过对实时数据的特征进行深入分析，基于大数据、微服务等技术，构建一套高效、轻量的实时数据处理架构，并支撑对城轨列车的实时监测，应急响应等应用功能，进而提升地铁公司对列车的掌控能力。

1 实时数据处理

在列车运营过程中，车载设备周期性地采集列车上各子系统的实时运行数据，通过数据传输网络发送到地面数据处理平台；地面系统接收到车载设备下发的实时数据后，对其进行并发处理、数据解析、报文统计等各项处理，解析后的数据经业务整合后形成可视化应用展示界面。本节主要从车地系统架构、实时数据分类处理两个方面进行介绍。

1.1 车地系统架构简介

整个车地系统主要包括列车上车载系统、无线传输通道、地面系统3部分，如图1所示。

图1 实时数据处理系统架构Fig.1 Real-time data processing system architecture

车载系统负责周期性地采集列车总线数据，按照既定的通用数据报文协议组成数据包，并借助无线传输通道（如4G/5G、WLAN、乘客信息系统等）将原始数据包周期性地向地面发送。数据报文协议包括3个部分：报文头、数据区及校验和。基于城轨项目实施经验，报文头一般包括报文长度、线路号、车型、车号、车厢、协议版本、设备时间、通道标志、压缩标志、加密标志、站点及速度等信息，基本能覆盖城轨项目应用需求；数据区由每个项目所采集的数据内容确定；校验和用来保证报文的完整性和正确性，并采用循环冗余校验（cyclic redundancy check，CRC）的方法校验。

地面系统对车辆数据处理后以可视化的方式呈现来指导运营，主要包括数据接收、解析、存储、推送及应用等程序。

1.2 实时数据分类

根据数据处理的时效性，数据可分为批式（batch）数据和流式（streaming）数据2类。其中，批式数据又被称为历史数据，流式数据又被称为实时数据。根据城轨列车的具体业务数据产生方式，实时数据又可分为实时状态数据与实时故障数据。

实时状态数据是车载系统通过定期采集车辆总线数据实时产生的，并且由车载系统以一定的频率将数据包周期性地下发到地面服务器。

实时故障数据是由车辆发生故障时触发产生的，发生时间具有不确定性，触发后车载系统会立即下发数据包到地面服务器。

下面针对周期性数据与触发式数据分别说明数据处理流程。其中，周期性数据以实时状态报文为例，触发式数据以实时故障报文为例。

1.2.1 实时状态数据处理

由图1可知，车载系统下发的实时数据包到达地面系统后，前置服务器根据数据包频率、大小及服务器硬件配置情况做相应策略的负载均衡调度。一般情况下，采用高性能代理服务器Nginx的流代理模块将数据包转发到相同服务器的不同端口，或者转发到后置不同服务器后再进行处理。数据包到达数据解析程序后的处理流程如下：

（1）数据解析程序的设计基于异步、事件驱动的高性能并发框架。数据接收后，先根据校验信息验证数据的合法性和完整性，并将合法的车载原始二进制数据流写入一种高吞吐量的分布式订阅消息队列（如Kafka）主题中，不同的数据包被写入到不同的消息主题上。在消息队列组件层实现数据的共享，具有如下优势：第一，充分利用该组件的异步、缓冲、高吞吐量等特性，减少实时数据时延；第二，隔离数据的生产与消费，有效降低数据处理平台与各子系统地面的耦合性，在任何一方数据接口出现问题时，不影响整体数据链路，保证整个平台的运行安全；第三，可提升数据平台接入类型的横向扩展能力。

（2）针对不同消息队列中的原始二进制数据流，流式计算引擎根据数据报文协议模板对报文数据的内容进行解析，并将解析后为轻量级格式的点位键值对写回到消息队列的另外一个消息队列主题中，供流式存储引擎或其他程序使用；同时将解析后的数据键值对按照一定格式写入基于内存的实时数据库（如Redis）中，供不同的应用程序对实时数据进行共享读取时使用。实时数据库中的数据组织方式一般按照车号-业务场景归类分组。如果车地原始消息队列数据区的协议格式不公开，那么对应的二进制数据流无法被解析，只有拥有原始数据协议才可知道数据区原始二进制的含义，从而可以在车地通道中起到数据透传与保护私有数据区的作用。

（3）流式存储引擎程序通过消费消息队列解析后的数据流，将全量数据存入分布式文件系统（如Hbase）中，为后续数据关联分析、挖掘提供数据支撑。少量结构化的业务数据将存储到关系型数据库（如Mysql）中，供应用系统快速查询。

（4）对于绝大部分状态点位数据而言，应用程序功能需求一般只依赖最新的数据，如实时显示车辆的站点、速度及网压等信息，实时数据库有一个全量点位数据的键用于存放最新的数据。对于少数应用场景而言，需要借助一部分点位在一段时间内的数据，通过后台并行计算方式，从全量点位数据的键里面抽取所需要的点位到新的业务键中，并指定业务键的失效时间或者长度。

1.2.2 实时故障数据处理

故障数据的下发包括故障发生、故障消除、定期刷新等过程，前后数据包具有关联性，故障更新逻辑较为复杂。因此，鉴于故障数据的特殊性，其不能与状态数据采用相同的处理方式。

（1）实时故障包通过地面服务器负载均衡调度后被转发给数据解析程序。解析程序根据相应的协议解析出故障信息，包括故障码、故障变化时间及故障状态等。如果是故障发生，则将故障码、故障发生时间等新增信息记录存入数据库中进行归档；如果是故障结束，则添加信息，更新原有的故障记录条目。另外，故障信息也被同步存入到实时数据库中供应用系统使用。

（2）故障数据的处理机制比状态数据的复杂，需要根据故障包中每个故障的状态标记做不同处理，进而维护每节车辆的故障列表。

（3）为了进一步提升故障数据的及时性与准确性，一般会增加一个故障刷新报文，用于记录当前时间未结束的全部故障列表，如图2所示。

图2 故障报文处理机制Fig.2 Fault package processing mechanism

2 实时数据应用

地面系统应用后台定时任务对实时数据库进行监听，当数据库全景点位数据的键取值发生变化时，从全量数据中获取不同的数据并分别存储到对应的业务键以满足不同的应用需求。可以根据业务功能展示的需要保存实时数据量的大小，如运营指标某些功能只需保存最新的一条信息，应急响应某些功能只需最新10 s内的记录。借助实时数据库特性，不仅能够便捷地实现对实时数据的失效时间或者数据量大小的管控，还能在实时数据库层面实现不同专业实时数据的快速共享。下面主要从实时监测、应急响应和日检项点3个方面分别进行介绍。

2.1 实时监测

用户通过使用应用系统的实时监测功能，可获取全部列车的位置、速度及载客量等实时状态信息，并可查看列车是否发生故障，及时指导列车司机进行故障处置，提升运营质量。

实时监测能够可视化地展示包括当前线路全部站点信息的模拟地图及各节车辆的实时数据。在模拟线路地图中，根据实时下发的站点信息以及列车运行方向，显示列车在相应的站点位置；根据故障信息以不同颜色展示列车的健康状态；根据载荷信息计算并展示当前列车载客情况。在单车界面中，详细展示当前列车的行驶基本信息、实时故障、司控台指示灯状态、司机屏信息等数据，远程复现列车当前的运行状态。实时监测web应用界面如图3所示。

图3 实时监测web应用界面Fig.3 Real-time monitoring web application interface

2.2 应急响应

应急响应功能是针对正线的列车关键应急事件提供应急响应与指导。应急事件主要包括高压成立条件、紧急制动条件、牵引指令条件、门控制回路等。借助此功能，地面人员可以快速指导司机进行应急操作，降低晚点和救援事故概率，从而减少应急事件对正线的影响。借助点位实时数据与点位组合逻辑条件设计子应急应用，每组应急事件主要包括以下3项功能：

（1）应急提示。在每个监测的条件下面，当对应应急逻辑触发时，显示对应应急处置信息。

（2）条件成立监测。针对开关监测点的点位组合逻辑，条件成立则开关闭合；条件不成立则断开。

（3）控制回路电流状态监测。对于每组应急事件中各个条件，如果前一个节点有电流，但本级节点条件不成立，则显示橙色；如果前一个节点有电流，且本级节点条件成立，则显示绿色；如果前一个节点无电流，则本级节点显示灰色。

前端页面用开关图片模拟每个对应条件是否成立，圆点模拟电路节点连通性。根据每个条件回路实际情况，设计应用响应（图4），其能够监测当前车辆是否发生应急事件，并能标注出异常出现的电路节点，以达到快速指导现场人员进行应急处置的效果。

图4 应急响应web应用Fig.4 Emergency response web application

2.3 列车日检项点

车辆检修人员从日检检修单出发，并结合车辆落地数据内容，梳理出可以根据实时数据判断的检修项点。由于项点功能的验证依赖数据在时序上的变化情况，因此此项功能对实时数据连续性的质量要求较高。一般列车检修存在以下检查项点：

（1）开、关门功能检查；

（2）空调温度检查；

（3）蓄电池输出电压检查；

（4）高速断路器分、合功能检查；

（5）施加、缓解停放制动功能检查。

由于此类功能对实时性要求不高，且涉及的数据量较大，一般常见的做法是从消息队列或者分布式文件系统中获取最近一段时间（如15 min）内的数据，并以时间顺序正排，所有项点共享此份全集数据，并行计算每个项点的业务逻辑，业务处理流程如图5所示。

图5 列车日检项点业务处理流程Fig.5 Business process of train daily inspection point

每个检查项点业务从全集数据中筛选出项点，判断所依赖的点位值集合，并针对有序值集合进行步骤设计。下面以开门功能检查为例进行详细阐述：

（1）找到前置条件点位值满足的入口逻辑时刻，如顺序搜索门开请求信号有效的时刻t1。

（2）判断是否需要延时，假设门从接收“开信号”到门开到位最多需要4 s，那么下一步就从（t1+4）时刻后开始判断结果点位值。

（3）判断结果点位值是否正确变化，如“门开到位”信号有效，代表此次开门功能检查正常。

3 结语

针对轨道交通领域日益增长的数字化运营需求，本文提出了一种基于大数据、微服务等技术的实时流式数据处理架构，其能够实现实时数据的高效处理与灵活应用，并在实时监测、应急响应、日检项点等业务中应用。

截至目前，本文所提供的实时数据处理架构与应用功能已经在国内多条城轨线路实施验证，基本能满足常见线路级车辆智能运维系统建设的需要，解决了传统数据处理架构无法支撑多并发数据的实时处理和海量数据存储的问题；通过状态监视、应急响应的应用功能，实现了地铁公司对运行列车的全方位远程动态监测，进而实现对列车运行状态的态势感知。

下一步可以结合高并发异步IO框架来提升数据接收的并发量，数据包间隔时间从现有的500 ms缩短到100 ms，适应后续更多子系统数据、更多线网级车辆数据的场景。