一种基于全局的现车管理系统及其方法与流程

本发明属于铁路管理系统领域，特别涉及一种基于全局的现车管理系统及其方法。

背景技术：

铁路现车管理系统用于管理铁路货运车辆信息，包括每节车厢的位置追踪信息，货物装卸信息，车辆运行状态信息等。

目前市面上具备现车管理系统功能的信息系统主要有cips系统（编组站综合集成自动化系统），smis系统（车站综合管理信息系统），集中式现在车系统，运输全过程系统等，按照可同时管理的车站数量可分为单站现车管理系统与多站现车管理系统。

单站类型现车管理系统中具有代表性且市场占有量较大的是cips系统。cips由北京全路通信信号研究设计院有限公司研发，该系统已经在新建和既有编组站以及厂矿企业站开始大面积推广。cips系统与控制系统相连接，给联锁系统发送始终端命令并接受处理反馈信息，并且根据反馈信息自动调整决策，从而实现了编组站内的全面信息化与自动化。

cips信息系统采用c/s结构，即客户端/服务器结构。客户端程序向服务器发送命令，服务器接收客户端命令，处理相应的业务逻辑并将处理结果返回给客户端，同时将最新的数据进行广播并保存数据库。在该局域网内的其他客户端接收到最新的广播数据，更新界面，从而实现所有客户端的数据同步更新。cips系统中现车位置及状态变化通过车辆操作流程进行推算，根据已经完成作业的车辆操作流程和为完成作业的车辆操作流程实时推算实际现车与计划现车。当前虽然cips在编组站上取得了成功，但局限于单个编组站。每个车站需要部署一套独立的服务器、数据库、客户端，各车站之间无法实现数据共享，无法对车辆进行全线乃至全局的车辆信息全程追踪，同时需要对每台机器安装部署客户端程序，且仅支持windows操作系统，增加了整个系统的安装、部署与维护的复杂度。

多站类型现车管理系统中具有代表性且市场占有量较大的是smis系统。smis由铁科院研发，该系统已经在铁路局技术作业站大面积推广。smis将运输管理、调度监督、车号识别、无线调车单传送、机车定位五大项有机结合，实现多站现车并行管理。smis系统采用b/s结构，即浏览器/服务器结构。用户通过浏览器进行访问，并行服务发送访问请求，服务器接收浏览器请求，处理相应的业务逻辑并将处理结果返回给浏览器，同时将最新的数据进行广播并保存数据库。smis系统中现车状态通过接收修改请求进行变更，现车位置通过接发车确报及调车计划进行推算。当前smis在铁路调度层面应用广泛且支持多站管理，但可同时管理的车站数量有限，受限于传统b/s架构制约其大数据量的并行运算，smis系统仅支持推算单个调车计划，车站调度人员无法提前预编多个调车计划，无法实现超前的计划现车推算。

综上所述，现有铁路现车管理系统主要存在以下缺点：

1.单站现车管理系统无法实现多站现车数据共享。

2.单站现车管理系统需要配备各自服务器、数据库、客户端，设备及系统运维成本较高。

3.多站现车管理系统受限于系统架构，可同时支持的车站数量有限。随着车站数量与数据运算量的增大，较难保证现车数据的实时性及准确性。

因此现在迫切的需要一种基于全局的现车管理系统来解决上述问题。

技术实现要素：

针对上述问题，本发明公开了一种基于全局的现车管理系统，所述基于全局的现车管理系统包括客户端、应用聚合服务层、应用内核服务层和数据库层；

所述客户端用于对所述基于全局的现车管理系统的人机交互工作；

所述应用内核服务层用于实现核心业务逻辑，并通过应用聚合服务层对外提供服务；

所述应用聚合服务层用于所述应用内核服务层的所有微服务，解耦客户端、内核服务层和外部系统；

所述数据库层与所述应用内核服务层进行通信，为所述应用内核服务层提供数据存储和数据调用。

进一步的，所述客户端基于浏览器实现，采用webui框架。

进一步的，所述客户端包括现在车分布界面、调车计划管理界面、技术作业图表、接发车表、统计分析界面和系统维护界面。

进一步的，所述应用聚合服务层包括web应用聚合服务和接口微服务平台；

所述web应用聚合服务用于为所有pc端和app端提供统一的服务api；

所述接口微服务平台用于将外部系统的接口部分抽象为单独的接口层，与业务层分离。

进一步的，所述外部系统包括计划调度信息系统、机务段信息系统、车辆调度信息系统、货运调度信息系统、车号识别系统和施工管理信息系统。

进一步的，所述应用内核服务层包括多个内核服务，每个所述内核服务之间相对独立，内核服务相互之间松耦合，通过resful和/或消息中间件的方式进行通信。

进一步的，多个所述内核服务层包括现车服务、行车服务、统计决策分析、权限管理服务、基础数据管理和日志管理。

进一步的，所述内核服务采用基于springboot框架的单体程序形式，对外独立发布服务接口，并通过服务接口调用方式获取其他单体内核程序的服务。

进一步的，所述内核服务层在服务规模低于第一设定值，未采用分布式部署的情况下，采用文档约定方式管理服务接口；在服务规模高于第一设定值，接口数量大于第二设定值时，采用部署服务发现实现服务自动注册和发现功能并简化微服务之间的调用。

进一步的，所述应用内核服务层与公共组件连接，所述公共组件用于通用功能在业务组件间的复用。

进一步的，所述公共组件包括认证授权模块、用户操作记录、通用实体对象、通用工具类。

进一步的，所述基于全局的现车管理系统采用soa的b/s微服务架构。

本发明还公开了一种基于全局的现车管理方法，所述现车管理方法包括以下步骤：

s1：使用应用内核服务层实现核心业务逻辑，并通过应用聚合服务层对外提供服务；

s2：使用应用聚合服务层聚合所述应用内核服务层所有的微服务，并解耦客户端、内核服务层和外部系统；

s3：使用数据库层与所述应用内核服务层进行通信，为所述应用内核服务层提供数据存储和数据调用；

s4：使用客户端对所述基于全局的现车管理系统进行人机交互操作。

进一步的，步骤s1中所述内核服务采用基于springboot框架的单体程序形式，对外独立发布服务接口，并通过服务接口调用方式获取其他单体内核程序的服务。

进一步的，所述步骤s2中所述应用聚合服务层包括web应用聚合服务和接口微服务平台；

所述web应用聚合服务用于为所有pc端和app端提供统一的服务api；

所述接口微服务平台用于将外部系统的接口部分抽象为单独的接口层，与业务层分离。

进一步的，所述内核服务层在服务规模低于第一设定值，未采用分布式部署的情况下，采用文档约定方式管理服务接口；在服务规模高于第一设定值，接口数量大于第二设定值时，采用部署服务发现实现服务自动注册和发现功能并简化微服务之间的调用。

进一步的，步骤s4中所述客户端基于浏览器实现，采用webui框架。

本发明的优点是可以实现多车站数据的现车数据实时共享，实现多车站现车协同管理。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所指出的结构来实现和获得。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出了根据本发明实施例中现车管理系统的技术架构图；

图2示出了根据现有技术中cips系统的数据模型；

图3示出了根据本发明实施例中数据模型的数据模型图；

图4示出了根据本发明实施例中现车分布推算方法的流程图；

图5示出了根据本发明实施例中调车计划列表的示意图；

图6示出了根据本发明实施例中现车分布切面的推导示意图；

图7示出了根据本发明实施例中新建调车计划时，计划现车分布切面推算的流程图；

图8示出了根据本发明实施例中新建调车计划时，计划现车分布切面推算的流程示意图；

图9示出了根据本发明实施例中调车计划报点时实际现车分布切面推算的流程示意图；

图10示出了根据本发明实施例中不按照调车计划列表报点时，实际现车分布切面推算的流程示意图；

图11示出了根据本发明实施例中0001号车根据调车计划在股道间移动示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地说明，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明公开了一种现车管理系统，图1示出了所述现车管理系统的技术架构图。如图1所示，所述现车管理系统包括客户端、应用聚合服务层、应用内核服务层和数据库层。

示例性的，所述现车管理系统采用基于soa的b/s微服务框架，通过采用基于soa的b/s微服务架构可以简化人机交互端的安装部署和系统维护工作，也可以将各业务逻辑处理分散于各微服务中，提高所述现车管理系统的并行计算能力以及数据吞吐量。

进一步的，所述客户端与应用聚合服务层以及应用内核服务层之间通信采用restful风格的轻量级api。通过restful风格的轻量级api可以使得所述现车管理系统可以跨平台使用，例如可以同时提供网页，ios，android使用；另外所述现车管理系统可有效解耦前后台，前台只需要根据通用的状态码便可判断返回结果。例如传统的网页api返回的状态码只有200，需要开发人员定制服务器与客户端之间的通信状态。而使用restful风格的接口，可以返回不同的状态码，如比如最常用的200表示成功，500表示server内部错误，403表示badrequest等。

所述客户端用于对所述现车管理系统的人机交互工作。示例性的，所述客户端为手机app端和/或pc端。优选的，所述客户端基于浏览器实现，并且采用webui框架。基于浏览器实现能够简化客户端的安装部署和系统维护工作，采用webui框架能够保障用户界面风格的友好以及后续软件迭代升级的便利。所述用户界面用于显示现车分布界面、调车计划管理界面、技术作业图表、接发车表、统计分析界面和系统维护界面。通过所述客户端可以实现对现车分布进行实时查看，所述现车管理系统所生成的技术作业图表和统计分析模型都能够通过所述客户端进行呈现，并且能够通过所述客户端对所述现车管理系统发送调车计划，也可以通过所述客户端对所述现车管理系统进行系统维护。

所述应用聚合服务层用于聚合应用内核服务层的所有微服务，为外部系统提供统一的访问接口；还用于解耦客户端、接口层、应用内核服务层与外部系统；所述应用内核服务层用于通过应用聚合服务层对外提供服务。

具体的，所述应用聚合服务层包括web应用聚合服务和接口微服务平台。所述web应用聚合服务用于为所有pc端和app端提供统一的服务api，使得所述现车管理系统仅需开发一版服务程序，便可适用于网页，安卓。无需单独开发安卓版、网页版；所述接口微服务平台将外部系统的接口部分抽象为单独的接口层，与业务层分离，避免与业务逻辑耦合，在所述应用聚合服务层与外部系统的交互过程中出现问题时不会影响系统业务功能。

所述应用聚合服务层承担服务网关的功能，但是无状态持久化处理，以方便做负载提高吞吐能力。所述应用聚合服务层不仅用于承担服务网关的功能，还用于负载均衡。负载均衡指的是将大量用户访问需求平均分摊到各个服务器上。

所述现车管理系统通过所述接口微服务平台与所述外部系统对接，所述接口微服务平台的每一个接口服务均为独立的微服务，通过所述应用聚合服务层与外部系统进行交互。

示例性的，所述外部系统包括计划调度信息系统、机务段信息系统、车辆调度信息系统、货运调度信息系统、车号识别系统和施工管理信息系统。

所述应用内核服务层用于实现核心业务逻辑，并通过所述应用聚合服务层对外提供服务。具体的，所述应用内核服务层包括多个内核服务，每个内核服务之间相互独立，内核服务与内核服务之间松耦合，并通过restful或消息队列的方式进行通信。

两种通信方式的应用场景不同。

具体的，restful通信方式是发送请求，等待反馈，得到反馈并处理反馈信息。也就是说内核服务a向内核服务b请求数据然后等待内核服务b的返回，直到得到内核服务b的返回值才算完成一次通信。这种场景适用于用户访问网页，等待服务器将网页信息返回才行。或者内核服务a在进行运算，在运算过程中必须要用到内核服务b的某个数据才能完成计算，因此需要用restful通信方式请求内核服务b，内核服务a得到内核服务b返回的数据，才能继续运算。这种方式的好处是，内核服务a想要某个数据，可以实时向其他服务获取，实现方式简单。缺点是与其他服务的耦合性太强，一旦无法获取其他服务的数据，则内核服务a只能等待。

具体的，消息队列通信方式是，直接将消息抛入消息队列中，消息队列中的信息对其他内核服务可见，其他内核服务从该消息队列中将该消息取走进行相关计算。因此耦合性低，无需互相等待，但是不适用于网页访问等情况。

示例性的，所述内核服务层包括现车服务、行车服务、统计决策分析、权限管理服务、基础数据管理和日志管理。每一个内核服务均采用springboot框架的单体程序形式，对外独立发布服务接口，并通过服务接口调用方式获取其他单体内核程序的服务。进一步的，在服务规模较低，未采用分布式部署的情况下，采用文档阅读方式管理接口。优选的，所述内核服务层随着服务规模扩大，接口数量增加，可以通过部署服务发现实现服务自动注册和发现功能来简化微服务之间的调用。

具体的，内核服务要被使用，需要对外提供服务的位置信息，所述位置信息通常是一个ip地址和端口信息。在内核服务只有单个使用并且地址不会动态变化的情况下，内核服务的位置在使用端可以通过配置文件或代码等方式固定生成。这种情况下采用文档阅读方式管理接口，将服务地址连接参数等信息写入文档，各个内核服务按照文档中预设的连接方式去连接。在服务规模较低、未采用分布式部署时，采用文档阅读的管理方式更加便捷。

具体的，当内核服务为多台服务器同时提供服务时，会出现不同的访问地址及访问参数，所述访问地址和访问参数甚至会出现变化。服务自动注册就是当某一个微服务扩容新的服务地址或者变更地址，自动将新地址注册到注册中心，当某一个服务地址因机器故障等原因导致服务地址失效，自动向注册中心注销该地址。服务发现是指客户端在访问某个服务时，通过注册中心，自动获取可用的访问地址。因此使用微服务架构开发的应用，必须通过服务注册和发现技术解决此问题。

所述应用内核服务层与公共组件连接，所述公共组件用于通信功能在业务组件间的复用。具体的，所述公共组件包括授权模块、用户操作记录、通用实体对象和通用工具类。示例性的，所述授权模块可以为各个微服务提供授权功能。

所述数据库层与所述应用内核服务层通信，为所述用于内核服务层提供数据存储和数据调用。

本发明还公开了一种基于全局的现车管理方法，所述现车管理方法包括以下步骤：

s1：使用应用内核服务层实现核心业务逻辑，并通过应用聚合服务层对外提供服务；

s2：使用应用聚合服务层聚合所述应用内核服务层所有的微服务，并解耦客户端、内核服务层和外部系统；

s3：使用数据库层与所述应用内核服务层进行通信，为所述应用内核服务层提供数据存储和数据调用；

s4：使用客户端对所述基于全局的现车管理系统进行人机交互操作。

进一步的，步骤s1中所述内核服务采用基于springboot框架的单体程序形式，对外独立发布服务接口，并通过服务接口调用方式获取其他单体内核程序的服务。

进一步的，所述步骤s2中所述应用聚合服务层包括web应用聚合服务和接口微服务平台；

所述web应用聚合服务用于为所有pc端和app端提供统一的服务api；

所述接口微服务平台用于将外部系统的接口部分抽象为单独的接口层，与业务层分离。

所述内核服务层在服务规模低于第一设定值，未采用分布式部署的情况下，采用文档约定方式管理服务接口；在服务规模高于第一设定值，接口数量大于第二设定值时，采用部署服务发现实现服务自动注册和发现功能并简化微服务之间的调用。

进一步的，步骤s4中所述客户端基于浏览器实现，采用webui框架。所述客户端包括现在车分布界面、调车计划管理界面、技术作业图表、接发车表、统计分析界面和系统维护界面。

本发明还公开了一种基于全局现车管理系统的数据模型，图3示出了所述数据模型的数据模型图。如图3所示，所述数据模型包括车站车辆数据集、车站数据集和在途车辆数据集，所述车站车辆数据集用于存储停留在车站内的车辆详细信息，所述车站数据集用于存储调车计划和股道现车分布数据，所述股道现车分布数据记录股道内按照顺序排列的车辆数据指针，所述车辆数据指针指向所述车站车辆数据集中的车辆详细信息，所述在途车辆数据集用于存储在途中开行的车辆详细信息。

具体的，所述车站车辆数据集以哈希表结构存储车辆详细信息，哈希表中key值存储每辆列车的车号，并且要求不可重复，value值存储车辆其他信息。具体的，所述车辆详细信息包括车号、车型、货物、载重和车辆状态等信息。通过哈希表结构存储车辆详细信息，当需要对车辆信息进行修改时，仅需根据车号便可直接从哈希表中直接获取车辆数据，算法复杂度为0（1），大大节约了系统的运算过程，节约了系统算力。

所述车站数据集中包括实际现车数据、计划现车数据和调车计划数据。所述实际现车数据和计划现车数据中均包括了股道与车辆关系集合，该集合中存储的并不是真实的数据，而是数据指针有序列表，所述数据指针指向车站车辆数据集中的车辆详细信息。当所述车站车辆数据集中的车辆详细信息发送改变时，通过所述数据指针所述实际现车数据和计划现车数据也会及时发生改变，无需重新推算实际现车数据与计划现车数据。所述调车计划数据用于存储调车计划单，实际现车数据根据调车计划数据进行推导得出计划现车数据。

进一步的，所述数据模型还包括在途数据集模型，所述在途车辆数据集模型用于存储列车编组信息。具体的，所述列车编组信息包括列车编组目录信息和列车编组内容信息。所述列车编组目录记录了列车车次、列车运行线、列车到发类型和列车到发站等。所述列车编组目录指向列车编组内容信息，所述列车编组内容信息包括了当前列车所携带的所有车辆详细信息以及车辆排列顺序。所述排列顺序指的是该列车中所携带的所有车辆的排列顺序。示例性的，当前车站有三条股道，每条股道上都停留有车辆，所述车站车辆数据集中记录了三条股道与车辆关系数据，每条股道与车辆关系数据中存放了车辆数据指针的有序列表。当其中提条股道的车辆发车时，所述在途车辆数据集中将生成一条列车编组信息目录及一份列车编组内容，列车编组目录信息记录了列车车次、列车到发类型、列车发车股道、列车发车股道等信息，列车编组内容记录了发车股道上的所有车辆详细信息及排列顺序。同时车站车辆数据集中删除该股道上已经发走的车辆数据，清空车站数据集中该股道与车辆关系数据。当列车进入下一个车站时，根据列车编组信息及接车股道，向所述车站车辆数据集中添加车辆信息，同时向对应车站实际现车数据中添加接车轨道与车辆关系数据，根据所述调车计划重新推算计划现车数据。本发明的基于全局现车管理系统的数据模型相比较起图2中示出的cips系统的数据模块运行速度更快，节约了系统的运算过程，节约了系统算力。

基于上述基于全局现车管理系统的数据模型，本发明还公开了一种基于全局现车管理系统的数据模型的建设方法，所述数据模型建设方法包括以下步骤：

s1：建设车站车辆数据集合车站数据集。

s2：将车辆详细信息存储于车站车辆数据集中。

具体的，所述车辆详细信息包括车号、车型、货物、载重和车辆状态。

优选的，步骤s2中所述车辆详细信息以哈希表结构存储于所述车站车辆数据集中，其中哈希表中key值存储车号，并且不可重复，value值存储车辆其他信息。

s3：将车辆数据指针存储于车站数据集中，所述车辆数据指针指向所述车站车辆数据集中的车辆详细信息。具体的，所述车站数据集包括实际现车数据和计划现车数据；所述实际现车数据和计划现车数据中存储的是股道与车辆关系集合，所述股道与车辆关系集合中存储的是车辆数据指针。

s4：使用客户端对所述基于全局的现车管理系统进行人机交互操作。

进一步的，所述数据模型还包括在途车辆数据集模型；

所述在途车辆数据集模型用于存储列车编组信息，所述列车编组信息包括列车编组目录和列车编组内容；

所述列车编组目录指向的列车编组内容记录了该列车中携带的所有车辆详细信息和排列顺序。

基于全局现车管理系统的数据模型的数据运转过程包括以下步骤：

s1：车站数据模型中存放有实际现车、计划现车以及调车计划数据。

所述实际现车与计划现车中存放的是股道与车辆数据指针关系表。车辆数据指针指向车站车辆数据集。车站车辆数据集中存放所有停靠在车站内的车辆信息。

s2：发车站发车时，生成列车编数据存入在途车辆数据集，删除发车站发车股道现车数据，删除车站车辆数据集中发走的车辆数据。

根据发车股道，发车车次信息生成列车编组数据。列车编组数据包括列车编组目录及列车编组内容，将列车编组数据存放入在途车辆数据集。

所述删除发车站发车股道现车数据是指，发车站车站数据集中的实际现车存放了发车股道与车辆数据指针有序列表数据，找到该数据并清空，清空后实际现车发车股道上现车被删除。根据调车计划集合与实际现车推算得到新的计划现车，通过推算，新的计划现车中发车股道上现车被删除。

到车站车辆数据集中找到发走的车辆数据并删除。

s3：列车到达接车站，提取列车编组数据，向车站车辆数据集添加接入的车辆数据，向接车站的车站数据集添加现车数据。

所述提取列车编组数据向车站车辆数据集添加接入的车辆数据是指，根据到达列车信息，向在途车辆数据集中提取列车编组信息，根据列车编组信息中的编组内容，向车站车辆数据集中添加车辆的详细数据。

所述向接车站的车站数据集添加现车数据是指，根据到达列车进入车站的接车股道，找到接车站车站数据集实际现车中的接车股道，根据到达列车编组内容向该接车股道添加车辆数据指针列表，添加后实际现车的接车股道上添加了现车信息。根据实际现车与调车计划推算得到本站新的计划现车，推算出的计划现车的接车股道上出现了接入的现车信息。

综上所述，通过本数据模型的数据运转过程推理，实现了车辆在各个车站间的运转。

本发明还公开了一种现车分布推算方法。图4中示出了实际现车分布切面推算的流程图，步骤如下所示：

s1：读取实际现车分布切面及调车计划列表数据；

s2：将调车计划列表中对应的调车计划设置为报点状态；

s3：根据原实际现车切面及报点的调车计划推算新的实际现车切面；

s4：如果实际现车切面推算失败，撤回调车计划报点状态；

如果实际现车切面推算成功，根据新的实际现车切面及所有未报点的调车计划推算新的计划现车切面；

s5：如果计划现车切面推算失败，撤回调车计划报点状态；如果计划现车切面推算成功，更新实际现车切面，更新计划现车切面，即报点成功。

具体的，所述实际现车切面指的是当前车站内在此时刻车辆在各个股道上的分布情况，每个股道上显示不同车辆排列顺序，每个车辆都有唯一车号，同时还会显示车辆的型号及装载的货物信息。

所述调车计划列表指的是车站调度人员编制的调车机甩挂并移动车辆的工作计划列表。在货运站时由于需要对货车车辆进行上下货、将车辆进行不同股道间转移以及同一股道内车辆顺序调整等一系列的操作。为完成这一系列的操作，车站调度人员会提前按照顺序编制多个调车计划，多个调车计划按照编制的顺序排列成调车计划列表，如图5所示，上方为车站调度员编制的调车计划列表，列表里面有3个调车计划。下方显示的是选中的第1个调车计划的具体内容，作业内容分为两步：（1）调车机从i-1号股道的东边挂64辆车（2）调车机在i-iia号股道东头甩下64辆车。从而实现将i-1号股道内的64辆车移动至i-iia号股道。

具体的，所述调车计划包括未报点调车计划和已报点调车计划。未报点调车计划指的是车站现场未开始作业的调车计划，实际现场股道内车辆还未发生移动。已报点调车计划指的是车站现场已经完成作业的调车计划，户外现场调车作业人员（调车长，摘勾员，机车司机等人员）首先获取到未报点调车计划，根据该调车计划内容进行现场作业，当完成调车作业后会上报该调车计划的作业完成时间点，此时未报点调车计划变为已报点调车计划。

具体的，所述计划现车切面指的是系统根据未报点的调车计划推算的未来时刻车辆在各个股道上的分布情况。通常车站调度员会根据现场作业情况提前编制好一系列调车计划，系统根据实际现车切面按照调车计划列表顺序依次推算未报点的调车计划，获得计划现车切面。如图6所示，p1~pn为已经报点的调车计划，pn+1~pn+m为未报点调车计划，realtracks为实际现车切面，plantracks为计划现车切面。系统推算计划现车切面，可帮助车站调度员提前掌握未来调车计划执行后的车站内现车分布情况，并根据计划现车切面继续编制后续的调车计划。

示例性的，如图9所示，所述调车计划列表由p1、p2至pn、pn+1、pn+2至pn+m组成。此时调车计划pn之前的调车计划已经全部完成报点，实际现车分布切面为pn，值得解释的是实际现车分布切面为pn指的是完成调车计划pn后的现车实际分布切面，下文中同理，不再解释。此时需要对调车计划pn+1进行报点。根据调车计划pn+1得到推导新的实际现车分布切面pn+1。需要对计划现车分布切面重新推算并验证，才能保证报点的准确性。

示例性的，根据实际现车切面依次推算未报点的调车计划pn+1、pn+2至pn+m得到新的计划现车切面，如果能够成功推算出新的计划现车切面，则判定报点成功。

进一步的，步骤s1中读取的实际现车分布切面以及调车计划列表数据的具体步骤如下：

从数据库读取实际现车切面及调车计划列表数据，将数据加载入系统内存；

具体的，数据库用于持久化实际现车切面及调车计划数据，系统初始化启动时将数据库中数据加载入系统内存并推算计划现车切面数据存入内存，因此系统运行时系统内存中存放实际现车切面、计划现车切面以及调车计划列表数据。内存数据根据用户操作实时推算更新，内存中实际现车分布与调车计划数据更新后实时同步到数据库。

在系统内存中，根据实际现车分布切面按照调车计划列表中未报点调车计划依次推导，得到计划现车分布切面并存放入系统内存。

在实际工作过程中，步骤s1中调车计划列表为不断更新的过程，在报点的同时会新增调车计划。图7中示出了新建调车计划时现车分布推算流程图，步骤如下所示：

s11：将新建调车计划放入调车计划列表末位。

s12：根据原计划现车切面及新建的调车计划推算新的计划现车切面。

示例性的，如图8所示，pn+m+1为新增的调车计划，plantracks1为原计划现车切面，原计划现车切面根据pn+m+1可推算出新的计划现车切面plantracks2。

s13：如果推算成功，将计划现车切面更新为新的计划现车切面；如果推算失败，不更新计划现车分布，同时将新建的调车计划从调车计划列表中删除。

具体的，推算成功的标准是系统根据调车计划内容去股道中查找是否存在对应的车辆，且车辆的排序必须与调车计划中指定的车辆排序一致。

进一步的，操作人员根据现场实际情况为了操作方便和节省时间，有时候不会按照调车计划列表一步一步的进行现场作业，可能会跳过某一项调车计划，先执行下一项调车计划，再进行跳过的调车计划，即不严格的按照调车计划列表按顺序进行报点。

示例性的，当未严格按照调车计划列表顺序进行报点时，推算步骤同上，首先根据原实际现车切面及上报的报点调车计划推算新的实际现车切面，然后根据新的实际现车分布切面按照调车计划列表中调车计划排列顺序，依次推算未报点的调车计划得到新的计划现车分布切面。

示例性的，如图10所示。当前的实际现车分布切面为pn，跳过调车计划pn+1，先对调车计划pn+2进行报点。此时，原实际现车切面依据调车计划pn+2进行推导，忽略调车计划pn+1，得到新的实际现车切面。接着根据新的实际现车切面及调车计划列表中所有未报点的调车计划，按照计划排列顺序依次推算pn+1、pn+3至pn+m到新的计划现车切面，如果能够成功推算出计划现车切面，则判定报点成功，更新实际现车分布切面，更新计划现车切面，反之则判定报点失败。

示例性的，例举调车报点时根据新的实际现车切面推算新的计划现车切面来校验调车计划报点是否正确的必要性。如图11所示，当前实际现车切面，0001号车在1g，车站调度员依次编制3个未报点的调车计划p1、p2、p3。调车计划内容如下：

（1）p1将车辆从1g移动至2g。

（2）p2将车辆从2g移动回1g。

（3）p3将车辆从1g移动至3g。

经过推算p1、p2、p3，计划现车切面上，0001号车辆最终被移动至3g。现场根据调车计划进行作业，完成p1。如果现场工作人员正确报点p1。此时新的实际现车切面上，0001号车辆被移动至2g。新的实际现车切面继续推算p2、p3可正常推算出计划现车切面。如果现场工作人员操作失误，没有报点p1，而是错误报点了p3，系统首先推算新的实际切面将车辆移动至3g，然后根据新的实际切面按照顺序依次推算p1、p2，当推算p1时发现新的实际现车切面上1g不存在0001号车（此时车辆在3g），因此推算错，系统判断现场操作人员报点错误，从而有效防止现场人员误操作。

本发明还公开了一种现车分布推算系统，所述现车分布推算系统包括存取模块和推算模块。所述存取模块用于读取实际现车分布切面和调车计划列表。所述推算模块用于根据调车计划列表中调车计划从实际现车分布切面按顺序推导得到新的实际现车分布切面，并继续根据所有未报点的调车计划从新的实际现车分布切面推导得到计划现车切面。

具体的，所述存取模块包括数据库及系统内存。数据库用于保存实际现车分布切面及调车计划列表数据，可持久化数据，系统初始化启动时可从数据库加载数据进入系统内存；系统内存存放实际现车分布切面和调车计划列表数据，所述推导模块根据所述实际现车分布切面和电车计划列表推算出计划分布切面，并存储到系统内存中。由于内存数据读取速度快，可根据用户操作实时推算更新数据，保证系统实时性，当内存中实际现车分布切面与调车计划数据更新后同步到数据库，保证系统内存数据与数据库数据的一致性。所述推算模块用于根据调车计划列表中调车计划数据推算并更新实际现车分布切面。

具体的，所述调车计划列表包括未报点调车计划和已报点调车计划。

新增调车计划需要更新计划现车分布切面时，所述推算模块用于将新建调车计划放入调车计划列表末位；根据原计划现车切面及新建的调车计划推算新的计划现车切面；如果推算成功，将计划现车切面更新为新的计划现车切面；如果推算失败，不更新计划现车分布，同时将新建的调车计划从调车计划列表中删除。

调车计划报点时推算新的实际现车分布切面具体包括：将调车计划列表中对应的调车计划设置为报点状态；根据原实际现车切面及报点的调车计划推算新的实际现车切面；根据新的实际现车切面及所有未报点的调车计划推算计划现车切面；如果计划现车切面推算失败，撤回调车计划报点状态。如果计划现车切面推算成功，更新实际现车切面，更新计划现车切面。如果实际现车切面推算失败，撤回调车计划报点状态；如果实际现车切面推算成功，则进一步推算新的计划现车分布切面。

当未按照调车计划列表顺序进行报点时，具体推导步骤包括如下：根据原实际现车切面及上报的报点调车计划推算新的实际现车切面；根据新的实际现车分布切面依次推算未报点的调车计划得到新的计划现车分布切面。

尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。