CN117744947A - 城轨运维数据管理系统及方法 - Google Patents

Abstract

本申请提供一种城轨运维数据管理系统及方法，包括多源数据接入模块、数据分析模块和分析结果输出模块，其中，所述多源数据接入模块包括实时数据接入模块、离线数据接收模块和业务系统数据接入模块；所述数据分析模块基于所述车载实时数据、所述原始状态数据以及所述维修作业数据判断城轨车辆的运维状态，基于各城轨车辆的运维状态生成分析结果，并将所述分析结果传递至分析结果输出模块；所述分析结果输出模块用于输出所述分析结果。本申请通过将管理系统接入地铁运行线网，通过系统接收各城轨车辆相关数据，根据接收到的数据判断城轨车辆的运维状态，自动对运维状态进行分析，生成分析结果，避免了维修人员面对过多报警信息无法处理的情况。

Description

城轨运维数据管理系统及方法

技术领域

本申请涉及城市轨道交通技术领域，尤其涉及一种城轨运维数据管理系统及方法。

背景技术

由于城市轨道交通具有运量大、速度快、节能环保、安全便捷等特点，能有效缓解城市交通拥堵和扩大城市规模的作用，城市轨道交通已成为城市交通的主要载体。地铁运行线网规模不断扩大，随之而来的是城轨地铁车辆数量迅速增加，而且车辆运行状况越来越复杂，速度也越来越快，使得车辆运营时间变长，运行频率更高，同时产生的故障类型更多，交通系统也更大更复杂。这给车辆运维带来更大压力，使得地铁自身发展面临安全与高效的矛盾也越来越突出，导致轨道交通的快速发展和乘客日益增长的需求不相匹配，城轨地铁车辆的运行与维护面临难题。

现有的城轨运维数据管理技术，例如基于商业软件或基于开源软件的大数据平台能够提供通用的面向海量数据接入和数据存储分析的功能，但现有技术仍不能对地铁车辆智能运维涉及的系统单元划分问题、多源数据采集协议规范问题、海量数据有效存储以及处理分析问题进行有效解决，并且，面对繁多的报警信息，运维人员无法及时分析处理。

发明内容

本申请提供一种城轨运维数据管理系统及方法，用以解决现有城轨运维数据管理技术难以对多源数据产生的大量警报进行有效分析的问题。

第一方面，本申请提供一种城轨运维数据管理系统，包括多源数据接入模块、数据分析模块和分析结果输出模块，其中，

所述多源数据接入模块包括实时数据接入模块、离线数据接收模块和业务系统数据接入模块；所述实时数据接入模块用于接入城轨车辆的车载实时数据，所述离线数据接收模块用于接收城轨车辆回库后发送的原始状态数据，所述业务系统数据接入模块用于从不同业务数据源中将维修作业数据同步至城轨运维数据系统；

所述数据分析模块基于所述车载实时数据、所述原始状态数据以及所述维修作业数据判断城轨车辆的运维状态，基于各城轨车辆的运维状态生成分析结果，并将所述分析结果传递至分析结果输出模块；

所述分析结果输出模块用于输出所述分析结果。

可选地，如上所述的系统，所述数据分析模块基于所述车载实时数据、所述原始状态数据以及所述维修作业数据判断城轨车辆的运维状态，包括：

所述数据分析模块采集多源数据接入模块中的所述车载实时数据，根据所述车载实时数据对城轨车辆中的静置车辆进行标记；

所述数据分析模块从多源数据接入模块中获取所述静置车辆的所述原始状态数据，将所述原始状态数据和预设城轨车辆标准数据进行比对，判断所述静置车辆是否需要维修保养；

将需要维修保养的静置车辆作为目标静置车辆，所述数据分析模块根据所述目标静置车辆的维修作业数据判断目标静置车辆的运维状态为已完成或未完成。

可选地，如上所述的系统，所述多源数据接入模块与现有线网平台进行对接，通过预设的采集频率采集所述线网平台的车载数据，并将所述不同业务数据源中数据同步到所述线网平台。

可选地，如上所述的系统，所述实时数据接入模块通过实时流式数据接收方式接收车载数据，其中，所述实时数据接入模块接收的数据以socket数据流形式发送Kafka，Kafka将数据流整理为数据流序列，并有序的提供至所述数据分析模块。

可选地，如上所述的系统，所述离线数据接收模块通过文件传输协议接收列车回库后打包的原始状态数据，所述原始状态数据包括所述城轨车辆运行过程中的车辆状态数据；

在所述离线数据接收模块接收所述原始状态数据的过程中，利用数据传输日志记录数据条数、开始时间、完成时间以及错误信息。

可选地，如上所述的系统，所述业务系统包括车联网系统、轨旁综合检测系统、网络文件共享系统；所述业务系统数据接入模块定期通过结构化查询语言从所述业务系统中抽取并更新业务数据，并通过数据交互工具将业务数据同步至车辆智能运维平台。

可选地，如上所述的系统，所述数据同步的触发模式包括手动执行和自动触发，所述数据抽取包括全量抽取和增量抽取。

第二方面，本申请提供一种城轨运维数据管理方法，包括：

获取城轨车辆的车载实时数据，接收城轨车辆回库后发送的原始状态数据，并从从不同业务数据源中获取维修维修作业数据；

基于所述车载实时数据、所述原始状态数据以及所述维修作业数据确认城轨车辆的运维状态，基于各城轨车辆的运维状态生成分析结果；

输出所述分析结果。

可选地，如上所述的方法，所述基于所述车载实时数据、所述原始状态数据以及所述维修作业数据确认城轨车辆的运维状态，包括：

根据所述车载实时数据判断城轨车辆是否为静置车辆，对所述静置车辆进行标记；

将所述静置车辆的原始状态数据和预设城轨车辆标准数据进行比对，判断所述静置车辆是否需要维修保养；

将需要维修保养的静置车辆作为目标静置车辆，根据所述目标静置车辆的维修作业数据判断目标静置车辆的运维状态为已完成或未完成。

可选地，如上所述的方法，所述将所述静置车辆的原始状态数据和预设城轨车辆标准数据进行比对，判断所述静置车辆是否需要维修保养，包括：

计算所述原始状态数据和所述城轨车辆标准数据之间的差值；

若所述差值符合预设误差范围，判断所述静置车辆不需要维修保养，否则，所述静置车辆需要维修保养。

第三方面，本申请提供了一种电子设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机执行指令，所述处理器执行所述计算机执行指令时实现上述第一方面中任一项所述的城轨运维数据管理方法。

第四方面，本申请提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述第一方面中任一项所述的城轨运维数据管理方法。

本申请提供的一种城轨运维数据管理系统及方法，包括多源数据接入模块、数据分析模块和分析结果输出模块，其中，所述多源数据接入模块包括实时数据接入模块、离线数据接收模块和业务系统数据接入模块；所述实时数据接入模块用于接入城轨车辆的车载实时数据，所述离线数据接收模块用于接收城轨车辆回库后发送的原始状态数据，所述业务系统数据接入模块用于从不同业务数据源中将维修作业数据同步至城轨运维数据系统；所述数据分析模块基于所述车载实时数据、所述原始状态数据以及所述维修作业数据判断城轨车辆的运维状态，基于各城轨车辆的运维状态生成分析结果，并将所述分析结果传递至分析结果输出模块；所述分析结果输出模块用于输出所述分析结果。本申请通过将管理系统接入地铁运行线网，通过系统接收各线路车辆的相关数据，从而根据接收到的数据判断城轨车辆的运维状态，自动对运维状态进行分析，生成分析结果，避免了维修人员面对过多报警信息无法处理的情况。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1为本申请实施例提供的城轨运维数据管理方法的应用场景示意图。

图2为本申请实施例提供的一种城轨运维数据管理系统的示意图。

图3为本申请实施例提供的城轨运维数据管理方法的流程图。

图4为本申请实施例提供的适用于城轨运维数据管理方法实现的电子设备的结构示意图。

通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

地铁运行线网规模不断扩大，随之而来的是城轨地铁车辆数量迅速增加，而且车辆运行状况越来越复杂，速度也越来越快，使得车辆运营时间变长，运行频率更高，同时产生的故障类型更多，交通系统也更大更复杂。这给车辆运维带来更大压力，使得地铁自身发展面临安全与高效的矛盾也越来越突出，导致轨道交通的快速发展和乘客日益增长的需求不相匹配，城轨地铁车辆的运行与维护面临难题。面对繁多的报警信息，运维人员无法及时分析处理，故障发生时，难以迅速定位问题根源等问题亟待解决。

在相关技术中，有的城市轨道数据管理系统包括用于搭建私有云集群的基础设施模块、用于将原始数据解析转换为报文数据的数据解析与接入模块、用于建立存储报文数据的数据表的异构数据存储模块等，能够对海量结构化/非结构化数据进行有效存储和处理，但面对繁多的报警信息，运维人员无法及时分析处理，也就是说，无法确认城轨车辆是否处于维修状态，其运维作业是否已经完成，导致运维的工作效率较低。

针对上述技术问题，本申请实施例旨在提出一种城轨运维数据管理系统及方法，本申请的发明构思主要是：通过将管理系统接入地铁运行线网，通过系统接收各线路车辆的相关数据，从而根据接收到的数据判断城轨车辆的运维状态，自动对运维状态进行分析，生成分析结果，避免了维修人员面对过多报警信息无法处理的情况。

为了更好地理解本申请实施例的方案，下面先对本申请实施例所涉及的一种应用场景进行介绍。

请参阅图1，图1为本申请实施例提供的城轨运维数据管理方法的应用场景示意图，如图1所示，包括数据源100、服务器200和运维客户端300，其中，服务器200中包括城轨运维数据管理系统。

数据源100可以是现有的城市轨道交通网络平台，也就是说，将城轨运维数据管理系统接入线网平台，因此数据源100包括车载实时数据，车载实时数据可以通过移动通信网络发送至服务器，例如，可以车载实时数据通过长期演进(Long Term Evolution，LTE)网络发送至服务器。数据源100还可以包括城轨车辆回库后打包上传的原始状态数据，以及各业务系统(例如车联网系统、轨旁综合检测系统等)的业务数据源。

服务器200可以通过不同的数据接入模块接收或采集数据源100中的数据，从而基于获取的车载实时数据、原始状态数据和维修作业数据确认城轨车辆的运维状态，基于各城轨车辆的运维状态生成分析结果，进而将分析结果输出至运维客户端300，以便于运维工作人员能够直接了解各城轨车辆的运维状态。运维客户端300可以为个人计算机、移动手机、穿戴设备如智能手表等，本申请对此不做限定。

下面以具体的实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

请参阅图2，图2为本申请实施例提供的一种城轨运维数据管理系统的示意图，如图2所示，城轨运维数据管理系统包括多源数据接入模块、数据分析模块和分析结果输出模块。

其中，所述多源数据接入模块包括实时数据接入模块、离线数据接收模块和业务系统数据接入模块；所述实时数据接入模块用于接入城轨车辆的车载实时数据，所述离线数据接收模块用于接收城轨车辆回库后发送的原始状态数据，所述业务系统数据接入模块用于从不同业务数据源中将维修作业数据同步至城轨运维数据系统；

所述数据分析模块基于所述车载实时数据、所述原始状态数据以及所述维修作业数据判断城轨车辆的运维状态，基于各城轨车辆的运维状态生成分析结果，并将所述分析结果传递至分析结果输出模块；

所述分析结果输出模块用于输出所述分析结果。

可以理解的是，城轨运维数据管理系统需要接入多源数据，支持高性能计算的工作负载，以及高并发、高吞吐、读写密集型等应用场景，并且，城轨运维数据管理系统可以发挥硬件资源平台服务器的运算和处理能力，开放硬件资源平台支持，计算与存储量可根据使用情况进行扩展，可接收各个线路车辆智慧运维数据，满足不低于2年的数据存储需求。

对于多源数据接入模块而言，其支持多源数据接入，包括但不限于时序数据、关系数据和非关系数据，并基于接入的数据形成资产目录，并根据接入的多源数据根据不同的应用场景选择不同的存储形式进行数据存储。进一步地，多源数据融合涉及到数据的流、批处理，提供任务调度、监控管理功能，因此，多源数据接入模块支持数据清洗规则自定义和导入导出功能。

具体地，城轨运维数据管理系统的采集频率可以设置为100-500毫秒，高并发地将车载数据接入到线网平台，以及通过接口对接的方式将业务系统中数据同步到线网平台。

进一步地，支持数据接入类型包括：车辆类(车辆以及各系统产生的状态数据)、检修类(检修工单、轨旁检测设备、施工作业、物资消耗)、乘务类(人员信息)、故障类(故障/预警信息查询)、视频类(车辆、地铁段场历史视频调看)等。

可以理解的是，通过对多源数据的采集和比对，可以利用大数据模型或人工智能算法对相关的数据进行分析，例如，可以通过实时车载数据分析出城轨车辆处于运行状态或静置状态，还可以通过维修作业数据分析出相应的城轨车辆是否已经完成维修，或是部分完成维修。将分析后的内容汇总为分析结果，分析结果可以发送至系统管理员，系统管理员具有普通用户的权限和应用平台的系统管理权限，具有用户管理、授权管理、日志管理、功能配置管理权限；分析结果可以发送至系统运维管理员的客户端，系统运维管理员具有最高级别的普通用户权限用于系统功能运维时的测试以及系统运维模块中的系统响应异常分析功能权限。

本实施例中，通过将管理系统接入地铁运行线网，通过系统接收各线路车辆的相关数据，从而根据接收到的数据判断城轨车辆的运维状态，自动对运维状态进行分析，生成分析结果，避免了维修人员面对过多报警信息无法处理的情况。

在一种可能的设计中，数据分析模块基于所述车载实时数据、所述原始状态数据以及所述维修作业数据判断城轨车辆的运维状态，包括：所述数据分析模块采集多源数据接入模块中的所述车载实时数据，根据所述车载实时数据对城轨车辆中的静置车辆进行标记；所述数据分析模块从多源数据接入模块中获取所述静置车辆的所述原始状态数据，将所述原始状态数据和预设城轨车辆标准数据进行比对，判断所述静置车辆是否需要维修保养；将需要维修保养的静置车辆作为目标静置车辆，所述数据分析模块根据所述目标静置车辆的维修作业数据判断目标静置车辆的运维状态为已完成或未完成。

可以理解的是，车载实时数据中可以包括城轨车辆的实时运行状态数据，由此，可以判断出城轨车辆是处于正在运行的状态或是处于静置状态。对于正在运行的城轨车辆，可以通过车载实时数据分析其是否出现严重故障，但更普遍的情况下，可以通过其回库后(也就是对于处于静置状态)上传的原始状态数据分析其运行期间的车辆状态，从而判断是否需要进行维修保养。因此对于处于静置状态的城轨车辆，可以进行标记，从而进一步确认静置车辆需要维修保养。

具体地，可以将城轨车辆的原始状态数据和预存的城轨车辆运行时的标准状态数据进行比对，若比对结果不符合预设的条件，例如运行时长超出规定时长的范围，则可以认为该城轨车辆需要进行维护，从而将其作为目标静置车辆。

可以理解的是，城轨车辆的原始状态数据和标准状态数据进行的比对可以是多维的，可以通过故障分析算法(例如聚类算法，或专家规则等)对目标静置车辆的问题进行初步分析，因此，对于目标静置车辆，可以根据比对结果确定其维修项目。再接入维修作业数据，则可以判断出该目标静置车辆是否已经完成运维，更详细地，其运维状态还可以是已完成、已部分完成或未开始运维。

在一种可能的设计中，所述多源数据接入模块与现有线网平台进行对接，通过预设的采集频率采集所述线网平台的车载数据，并将所述不同业务数据源中数据同步到所述线网平台。

作为示例而非限定的，预设的采集频率可以是100-500毫秒，多源数据接入模块可以通过高并发的形式将车载数据接入到线网平台。

在一种可能的设计中，所述实时数据接入模块通过实时流式数据接收方式接收车载数据，其中，所述实时数据接入模块接收的数据以socket数据流形式发送Kafka，Kafka将数据流整理为数据流序列，并有序的提供至所述数据分析模块。

可以理解的是，车载实时数据可以通过LTE网络将数据发送至地面，城轨运维数据管理系统通过实时流式数据接收方式接收车载数据，具体如下：

基于socket作为底层数据传输协议，地面提供接收服务器对应的IP地址、端口、用户名和密码，车载和地面确定认证策略及口令，由地面服务器实时接收发送的车载数据，数据以socket数据流形式发送Kafka，Kafka将数据流整理为数据流序列，并有序的提供给后端实时数据处理程序进行数据解析。

在一种可能的设计中，所述离线数据接收模块通过文件传输协议接收列车回库后打包的原始状态数据，所述原始状态数据包括所述城轨车辆运行过程中的车辆状态数据；在所述离线数据接收模块接收所述原始状态数据的过程中，利用数据传输日志记录数据条数、开始时间、完成时间以及错误信息。

在本实施例中，列车回库后，可以手动将原始状态数据打包上传地面服务器。以文件传输协议(File Transfer Protocol，FTP)实现数据从数据源端经过采集、转换、加载至数据管理平台。

具体地，FTP对非结构化文件如视频、图片进行采集，存放在ftp指定目录下，由城轨运维数据管理系统制定目录名称、访问权限、文件命名方式等统一标准。

进一步地，离线接收完数据后，城轨运维数据管理系统支持数据源与预设的车辆标准运行数据库的对比，发现并解决采集过程产生的错误。在数据传输的过程中全程记录数据传输日志，可以包括：数据记录条数、开始时间、完成时间，错误信息等。

在一种可能的设计中，所述业务系统包括车联网系统、轨旁综合检测系统、网络文件共享系统；所述业务系统数据接入模块定期通过结构化查询语言从所述业务系统中抽取并更新业务数据，并通过数据交互工具将业务数据同步至车辆智能运维平台。

所述数据同步的触发模式包括手动执行和自动触发，所述数据抽取包括全量抽取和增量抽取。

在本实施例中，城轨运维数据管理系统可以通过关系型数据库接入的方式，或者可以采用专门与关系型数据库进行数据交互的ETL工具对已有的业务系统接入(如手工建立故障处理记录、测量数据)。城轨运维数据管理系统所需数据源自于多个现存业务系统(如IFS、OA、IOR、SMIT等)的关系型数据库，利用数据交互工具可以通过从现有业务系统中定期通过SQL语句抽取并更新所需的数据。除此之外，系统主数据也来自业务系统的关系型数据库，同理也可以使用数据交互工具将数据同步至车辆智能运维平台。

进一步地，数据同步功能具备从不同数据源(例如Oracle数据库、DB2数据库、Hadoop、FTP文件、消息等)中进行指定规则的数据提取作业，实现各域数据的统一集成。

进一步地，数据同步过程中的数据存储支持落地与不落地二大类进行，也就是说，抽取后的数据可以为数据清洗环节进行处理提供输入，也可以直接进行处理或者加载。从抽取支持的方式上来看，主要包括全量抽取和增量抽取两种方式，其中全量抽取可将所有历史数据一次性抽取完成；单次抽取根据规则要求进行抽取。并且，在数据同步触发模式上支持自动触发与手工执行的二大类型。

应该理解，上述的装置实施例仅是示意性的，本申请的装置还可通过其它的方式实现。例如，上述实施例中单元/模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。例如，多个单元、模块或组件可以结合，或者可以集成到另一个系统，或一些特征可以忽略或不执行。

另外，若无特别说明，在本申请各个实施例中的各功能单元/模块可以集成在一个单元/模块中，也可以是各个单元/模块单独物理存在，也可以两个或两个以上单元/模块集成在一起。上述集成的单元/模块既可以采用硬件的形式实现，也可以采用软件程序模块的形式实现。

图3为本申请实施例提供的城轨运维数据管理方法的流程图。如图3所示，本实施例的方法，包括：

S301：获取城轨车辆的车载实时数据，接收城轨车辆回库后发送的原始状态数据，并从从不同业务数据源中获取维修维修作业数据；

S302：基于所述车载实时数据、所述原始状态数据以及所述维修作业数据确认城轨车辆的运维状态，基于各城轨车辆的运维状态生成分析结果；

S303：输出所述分析结果。

本申请实施例的执行主体可以是服务器，也可以是服务器中的城轨运维数据管理系统，其中，城轨运维数据管理系统可以通过软件实现。

下面对上述城轨运维数据管理方法的技术方案进行详细介绍。

具体地，基于所述车载实时数据、所述原始状态数据以及所述维修作业数据确认城轨车辆的运维状态，包括：根据所述车载实时数据判断城轨车辆是否为静置车辆，对所述静置车辆进行标记；将所述静置车辆的原始状态数据和预设城轨车辆标准数据进行比对，判断所述静置车辆是否需要维修保养；将需要维修保养的静置车辆作为目标静置车辆，根据所述目标静置车辆的维修作业数据判断目标静置车辆的运维状态为已完成或未完成。

具体地，可以计算所述原始状态数据和所述城轨车辆标准数据之间的差值；若所述差值符合预设误差范围，判断所述静置车辆不需要维修保养，否则，所述静置车辆需要维修保养。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于可选实施例，所涉及的动作和模块并不一定是本申请所必须的。

进一步需要说明的是，虽然流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

图4为本申请实施例提供的适用于城轨运维数据管理方法实现的电子设备的结构示意图。如图4所示，该实施例的电子设备包括：至少一个处理器40(图4中仅示出一个)处理器、存储器41以及存储在存储器41中并可在至少一个处理器40上运行的计算机程序，处理器40执行计算机程序时实现上述任意各个方法实施例中的步骤。

该电子设备可包括，但不仅限于，处理器40、存储器41。本领域技术人员可以理解，图4仅仅是电子设备的举例，并不构成对电子设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如还可以包括输入输出设备、网络接入设备等。

所称处理器40可以是中央处理单元(Central Processing Unit，CPU)，该处理器40还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(FieldProgrammable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

处理器401的具体实现过程可参见上述方法实施例，其实现原理和技术效果类似，本实施例此处不再赘述。

存储器41在一些实施例中可以是电子设备的内部存储单元，例如电子设备的内存。存储器41在另一些实施例中也可以是电子设备的外部存储设备，例如电子设备上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。进一步地，存储器41还可以既包括电子设备的内部存储单元也包括外部存储设备。存储器41用于存储操作系统、应用程序、引导装载程序(BootLoader)、数据以及其他程序等，例如计算机程序的程序代码等。存储器41还可以用于暂时地存储已经输出或者将要输出的数据。

本申请实施例还提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被处理器执行时实现可实现上述各个方法实施例中的步骤。

上述的计算机可读存储介质，上述可读存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。可读存储介质可以是通用或专用计算机能够存取的任何可用介质。

一种示例性的可读存储介质耦合至处理器，从而使处理器能够从该可读存储介质读取信息，且可向该可读存储介质写入信息。当然，可读存储介质也可以是处理器的组成部分。处理器和可读存储介质可以位于专用集成电路(Application Specific IntegratedCircuits，简称：ASIC)中。当然，处理器和可读存储介质也可以作为分立组件存在于上述电子设备中。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。上述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求书指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。

Claims (10)

1.一种城轨运维数据管理系统，其特征在于，包括多源数据接入模块、数据分析模块和分析结果输出模块，其中，

所述多源数据接入模块包括实时数据接入模块、离线数据接收模块和业务系统数据接入模块；所述实时数据接入模块用于接入城轨车辆的车载实时数据，所述离线数据接收模块用于接收城轨车辆回库后发送的原始状态数据，所述业务系统数据接入模块用于从不同业务数据源中将维修作业数据同步至城轨运维数据系统；

所述数据分析模块基于所述车载实时数据、所述原始状态数据以及所述维修作业数据判断城轨车辆的运维状态，基于各城轨车辆的运维状态生成分析结果，并将所述分析结果传递至分析结果输出模块；

所述分析结果输出模块用于输出所述分析结果。

2.根据权利要求1所述的系统，其特征在于，所述数据分析模块基于所述车载实时数据、所述原始状态数据以及所述维修作业数据判断城轨车辆的运维状态，包括：

所述数据分析模块采集多源数据接入模块中的所述车载实时数据，根据所述车载实时数据对城轨车辆中的静置车辆进行标记；

所述数据分析模块从多源数据接入模块中获取所述静置车辆的所述原始状态数据，将所述原始状态数据和预设城轨车辆标准数据进行比对，判断所述静置车辆是否需要维修保养；

将需要维修保养的静置车辆作为目标静置车辆，所述数据分析模块根据所述目标静置车辆的维修作业数据判断目标静置车辆的运维状态为已完成或未完成。

3.根据权利要求1所述的系统，其特征在于，所述多源数据接入模块与现有线网平台进行对接，通过预设的采集频率采集所述线网平台的车载数据，并将所述不同业务数据源中数据同步到所述线网平台。

4.根据权利要求1所述的系统，其特征在于，所述实时数据接入模块通过实时流式数据接收方式接收车载数据，其中，所述实时数据接入模块接收的数据以socket数据流形式发送Kafka，Kafka将数据流整理为数据流序列，并有序的提供至所述数据分析模块。

5.根据权利要求1所述的系统，其特征在于，所述离线数据接收模块通过文件传输协议接收列车回库后打包的原始状态数据，所述原始状态数据包括所述城轨车辆运行过程中的车辆状态数据；

在所述离线数据接收模块接收所述原始状态数据的过程中，利用数据传输日志记录数据条数、开始时间、完成时间以及错误信息。

6.根据权利要求1所述的系统，其特征在于，所述业务系统包括车联网系统、轨旁综合检测系统、网络文件共享系统；所述业务系统数据接入模块定期通过结构化查询语言从所述业务系统中抽取并更新业务数据，并通过数据交互工具将业务数据同步至车辆智能运维平台。

7.根据权利要求6所述的系统，其特征在于，所述数据同步的触发模式包括手动执行和自动触发，所述数据抽取包括全量抽取和增量抽取。

8.一种城轨运维数据管理方法，其特征在于，包括：

获取城轨车辆的车载实时数据，接收城轨车辆回库后发送的原始状态数据，并从从不同业务数据源中获取维修维修作业数据；

基于所述车载实时数据、所述原始状态数据以及所述维修作业数据确认城轨车辆的运维状态，基于各城轨车辆的运维状态生成分析结果；

输出所述分析结果。

9.根据权利要求8所述的方法，其特征在于，所述基于所述车载实时数据、所述原始状态数据以及所述维修作业数据确认城轨车辆的运维状态，包括：

根据所述车载实时数据判断城轨车辆是否为静置车辆，对所述静置车辆进行标记；

将所述静置车辆的原始状态数据和预设城轨车辆标准数据进行比对，判断所述静置车辆是否需要维修保养；

将需要维修保养的静置车辆作为目标静置车辆，根据所述目标静置车辆的维修作业数据判断目标静置车辆的运维状态为已完成或未完成。

10.根据权利要求9所述的方法，其特征在于，所述将所述静置车辆的原始状态数据和预设城轨车辆标准数据进行比对，判断所述静置车辆是否需要维修保养，包括：

计算所述原始状态数据和所述城轨车辆标准数据之间的差值；

若所述差值符合预设误差范围，判断所述静置车辆不需要维修保养，否则，所述静置车辆需要维修保养。