WO2023280140A1

WO2023280140A1 - Global-based inventory management system and method

Info

Publication number: WO2023280140A1
Application number: PCT/CN2022/103810
Authority: WO
Inventors: 谢飞; 苏斌; 刘永壮; 燕翔; 龙昭
Original assignee: 北京全路通信信号研究设计院集团有限公司
Priority date: 2021-07-06
Filing date: 2022-07-05
Publication date: 2023-01-12
Also published as: CN113204444B; CN113204444A

Abstract

The present invention relates to the field of railway management systems, and in particular, to a global-based inventory management system and method. The global-based inventory management system comprises a client, an application aggregation service layer, an application kernel service layer, and a database layer. The client is used for human-computer interaction of the global-based inventory management system. The application kernel service layer is used for implementing core business logic, and providing external services by means of the application aggregation service layer. The application aggregation service layer is used for all micro-services of the application kernel service layer, and decoupling the client, the kernel service layer and external systems. The database layer communicates with the application kernel service layer to provide data storage and data invocation for the application kernel service layer. By means of the present invention, inventory data sharing and collaborative management of multiple stations can be realized.

Description

A global-based existing vehicle management system and its method

technical field

The invention belongs to the field of railway management systems, and in particular relates to a global-based existing vehicle management system and a method thereof.

Background technique

The railway vehicle management system is used to manage the information of railway freight vehicles, including the location tracking information of each carriage, cargo loading and unloading information, vehicle operation status information, etc.

At present, the information systems with the function of existing vehicle management system on the market mainly include CIPS system (Comprehensive Integrated Automation System for Marshalling Station), SMIS system (Station Integrated Management Information System), centralized existing vehicle system, and whole-process transportation system. The number of stations managed can be divided into single-station existing vehicle management system and multi-station existing vehicle management system.

Among the single-station existing vehicle management systems, the CIPS system is representative and has a large market share. CIPS was developed by Beijing Quanlu Communication Signal Research and Design Institute Co., Ltd., and the system has been widely promoted in new and existing marshalling stations and factories and mines. The CIPS system is connected with the control system, sends end-to-end commands to the interlocking system and receives processing feedback information, and automatically adjusts decisions according to the feedback information, thereby realizing comprehensive informationization and automation in the marshalling station.

CIPS information system adopts C/S structure, that is, client/server structure. The client program sends commands to the server, and the server receives the client commands, processes the corresponding business logic and returns the processing results to the client, and at the same time broadcasts the latest data and saves it in the database. Other clients in the local area network receive the latest broadcast data and update the interface, so that the data of all clients can be updated synchronously. In the CIPS system, the position and state changes of the existing vehicle are estimated through the vehicle operation process, and the actual existing vehicle and the planned existing vehicle are calculated in real time according to the vehicle operation process that has completed the operation and the vehicle operation process that has not completed the operation. Although CIPS has achieved success in marshalling yards at present, it is limited to a single marshalling yard. Each station needs to deploy a set of independent servers, databases, and clients. Data sharing between stations cannot be realized, and vehicle information cannot be tracked across the entire line or even globally. At the same time, client programs need to be installed and deployed on each machine. And it only supports the Windows operating system, which increases the complexity of the installation, deployment and maintenance of the entire system.

Among the multi-station existing vehicle management systems, the SMIS system is representative and has a large market share. SMIS was developed by the Academy of Railway Sciences, and the system has been widely promoted in the technical operation stations of the Railway Bureau. SMIS organically combines the five major items of transportation management, dispatching supervision, vehicle number identification, wireless shunting order transmission, and locomotive positioning to realize parallel management of existing vehicles at multiple stations. SMIS system adopts B/S structure, that is, browser/server structure. The user accesses through the browser, the parallel service sends the access request, the server receives the browser request, processes the corresponding business logic and returns the processing result to the browser, and at the same time broadcasts the latest data and saves it in the database. In the SMIS system, the state of the current vehicle is changed by receiving the modification request, and the position of the current vehicle is estimated by the confirmation report of the vehicle receiving and dispatching and the shunting plan. At present, SMIS is widely used in railway dispatching and supports multi-station management, but the number of stations that can be managed at the same time is limited. Limited by the traditional B/S architecture that restricts its large data volume parallel computing, the SMIS system only supports the calculation of a single shunting plan. Station dispatchers cannot pre-program multiple shunting plans in advance, and cannot realize advanced planning and current train calculations.

To sum up, the existing railway vehicle management system mainly has the following shortcomings:

1. The single-station existing vehicle management system cannot realize multi-station existing vehicle data sharing.

2. The single-station existing vehicle management system needs to be equipped with its own server, database, and client, and the equipment and system operation and maintenance costs are relatively high.

3. The multi-station existing vehicle management system is limited by the system architecture, and the number of stations that can be supported at the same time is limited. With the increase in the number of stations and the amount of data calculations, it is difficult to ensure the real-time and accuracy of existing vehicle data.

Therefore, there is an urgent need for a global existing vehicle management system to solve the above problems.

Contents of the invention

In view of the above problems, the present invention discloses a global-based existing vehicle management system, which includes a client, an application aggregation service layer, an application kernel service layer and a database layer;

The client is used for human-computer interaction work on the global-based existing vehicle management system;

The application kernel service layer is used to implement core business logic and provide external services through the application aggregation service layer;

The application aggregation service layer is used for all microservices of the application kernel service layer, decoupling the client, the kernel service layer and external systems;

The database layer communicates with the application kernel service layer to provide data storage and data call for the application kernel service layer.

Further, the client is implemented based on a browser and adopts a WebUI framework.

Further, the client includes the current vehicle distribution interface, the shunting plan management interface, the technical operation chart, the receiving and dispatching table, the statistical analysis interface and the system maintenance interface.

Further, the application aggregation service layer includes a Web application aggregation service and an interface micro-service platform;

The Web application aggregation service is used to provide a unified service API for all PCs and APPs;

The interface micro-service platform is used to abstract the interface part of the external system into a separate interface layer, which is separated from the business layer.

Further, the external system includes planning and dispatching information system, locomotive depot information system, vehicle dispatching information system, freight dispatching information system, vehicle number identification system and construction management information system.

Further, the application kernel service layer includes multiple kernel services, each kernel service is relatively independent, the kernel services are loosely coupled to each other, and communicate through RESful and/or message middleware.

Further, the multiple core service layers include existing vehicle service, driving service, statistical decision analysis, rights management service, basic data management and log management.

Further, the core service adopts the form of a single program based on the SpringBoot framework, independently publishes the service interface to the outside, and obtains the services of other single core programs by calling the service interface.

Further, when the service scale of the kernel service layer is lower than the first set value and distributed deployment is not adopted, the service interface is managed in a document-agreed manner; when the service scale is higher than the first set value, the number of interfaces is greater than In the second setting value, deployment service discovery is used to realize automatic service registration and discovery functions and simplify calls between microservices.

Further, the application kernel service layer is connected with public components, and the public components are used for multiplexing of common functions among business components.

Further, the public components include authentication and authorization modules, user operation records, general entity objects, and general tool classes.

Further, the global-based existing vehicle management system adopts SOA B/S micro-service architecture.

The present invention also discloses a global-based existing vehicle management method, which includes the following steps:

S1: Use the application kernel service layer to implement core business logic, and provide external services through the application aggregation service layer;

S2: Use the application aggregation service layer to aggregate all the microservices of the application kernel service layer, and decouple the client, kernel service layer and external systems;

S3: use the database layer to communicate with the application kernel service layer, and provide data storage and data call for the application kernel service layer;

S4: Use the client to perform human-computer interaction on the global-based existing vehicle management system.

Further, the core service described in step S1 adopts the form of a single program based on the SpringBoot framework, independently publishes service interfaces externally, and obtains services of other single core programs through service interface calls.

Further, the application aggregation service layer in the step S2 includes a web application aggregation service and an interface microservice platform;

Further, the client in step S4 is implemented based on a browser, using a WebUI framework.

The invention has the advantages of realizing real-time sharing of existing vehicle data of multi-station data and realizing collaborative management of multi-station existing vehicles.

Additional features and advantages of the invention will be set forth in the description which follows, and in part will be apparent from the description, or may be learned by practice of the invention. The objectives and other advantages of the invention may be realized and attained by the structure pointed out in the written description, claims hereof as well as the appended drawings.

Description of drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings that need to be used in the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description These are some embodiments of the present invention. Those skilled in the art can also obtain other drawings based on these drawings without creative work.

Fig. 1 shows a technical architecture diagram of an existing vehicle management system according to an embodiment of the present invention;

Fig. 2 shows the data model according to the CIPS system in the prior art;

Fig. 3 shows the data model diagram according to the data model in the embodiment of the present invention;

Fig. 4 shows the flow chart of the present vehicle distribution estimation method according to the embodiment of the present invention;

FIG. 5 shows a schematic diagram of a shunting plan list according to an embodiment of the present invention;

Fig. 6 shows a schematic diagram of derivation of an existing vehicle distribution section according to an embodiment of the present invention;

Fig. 7 shows a flow chart of calculating the tangent plane of the planned existing vehicle distribution when a new shunting plan is created according to an embodiment of the present invention;

Fig. 8 shows a schematic flow diagram of calculating the tangential plane of the planned existing vehicle distribution when a new shunting plan is newly established according to an embodiment of the present invention;

Fig. 9 shows a schematic flow chart of the calculation of the cut plane of the distribution of actual existing vehicles according to the shunting plan according to the embodiment of the present invention;

Fig. 10 shows a schematic flow chart of the calculation of the cut plane of the actual existing vehicle distribution when the points are not reported according to the shunting plan list according to the embodiment of the present invention;

Fig. 11 shows a schematic diagram of car No. 0001 moving between lanes according to the shunting plan according to the embodiment of the present invention.

detailed description

In order to make the purpose, technical solutions and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments It is a part of embodiments of the present invention, but not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by persons of ordinary skill in the art without making creative efforts belong to the protection scope of the present invention.

The invention discloses an existing vehicle management system, and Fig. 1 shows a technical framework diagram of the existing vehicle management system. As shown in FIG. 1 , the existing vehicle management system includes a client, an application aggregation service layer, an application kernel service layer and a database layer.

Exemplarily, the existing vehicle management system adopts the B/S microservice framework based on SOA, and the installation, deployment and system maintenance work of the human-computer interaction terminal can be simplified by adopting the B/S microservice framework based on SOA, and various business The logic processing is dispersed in each micro-service to improve the parallel computing capability and data throughput of the existing vehicle management system.

Further, the communication between the client and the application aggregation service layer and the application kernel service layer adopts a RESTful style lightweight API. Through the RESTful-style lightweight API, the existing vehicle management system can be used across platforms, for example, it can provide web pages, ios, android at the same time; in addition, the existing vehicle management system can effectively decouple the front and back. The general status code can judge the return result. For example, the status code returned by the traditional webpage API is only 200, requiring developers to customize the communication status between the server and the client. Using the RESTful interface, different status codes can be returned, such as the most commonly used 200 for success, 500 for internal server errors, and 403 for Bad Requests.

The client is used for man-machine interaction with the existing vehicle management system. Exemplarily, the client is a mobile phone APP and/or a PC. Preferably, the client is implemented based on a browser and uses a WebUI framework. Browser-based implementation can simplify the installation and deployment of the client and system maintenance work, and the use of the WebUI framework can ensure a friendly user interface style and the convenience of subsequent software iterative upgrades. The user interface is used to display an existing vehicle distribution interface, a shunting plan management interface, a technical operation chart, a dispatch table, a statistical analysis interface and a system maintenance interface. Real-time viewing of the existing vehicle distribution can be realized through the client, the technical operation chart and statistical analysis model generated by the existing vehicle management system can be presented through the client, and all the existing vehicles can be analyzed through the client The above existing vehicle management system sends the vehicle shunting plan, and the system maintenance of the above existing vehicle management system can also be performed through the client.

The application aggregation service layer is used to aggregate all microservices of the application kernel service layer, and provide a unified access interface for external systems; it is also used to decouple the client, interface layer, application kernel service layer and external systems; the application kernel The service layer is used to provide external services through the application aggregation service layer.

Specifically, the application aggregation service layer includes a Web application aggregation service and an interface micro-service platform. The Web application aggregation service is used to provide a unified service API for all PC terminals and APP terminals, so that the existing vehicle management system only needs to develop a version of the service program, which can be applied to web pages and Android. There is no need to develop the Android version and the web version separately; the interface micro-service platform abstracts the interface part of the external system into a separate interface layer, which is separated from the business layer and avoids coupling with business logic. When there is a problem in the interaction process, it will not affect the business function of the system.

The application aggregation service layer undertakes the function of the service gateway, but does not have state persistence processing, so as to facilitate the loading and improve the throughput. The application aggregation service layer is not only used to assume the function of the service gateway, but also used for load balancing. Load balancing refers to the even distribution of a large number of user access requirements to each server.

The existing vehicle management system is connected to the external system through the interface micro-service platform, and each interface service of the interface micro-service platform is an independent micro-service, and interacts with the external system through the application aggregation service layer .

Exemplarily, the external systems include planning and dispatching information system, locomotive depot information system, vehicle dispatching information system, freight dispatching information system, vehicle number identification system and construction management information system.

The application core service layer is used to implement core business logic and provide external services through the application aggregation service layer. Specifically, the application kernel service layer includes multiple kernel services, each kernel service is independent of each other, and the kernel services are loosely coupled with each other, and communicate through RESTful or message queue.

The application scenarios of the two communication methods are different.

Specifically, the RESTful communication method is to send a request, wait for feedback, get feedback and process the feedback information. That is to say, kernel service A requests data from kernel service B and then waits for the return of kernel service B, and the communication is not completed until the return value of kernel service B is obtained. This scenario applies to users who visit web pages and wait for the server to return the web page information. Or kernel service A is performing calculations. During the calculation process, certain data of kernel service B must be used to complete the calculation. Therefore, it is necessary to use RESTful communication to request kernel service B. Kernel service A can get the data returned by kernel service B to complete the calculation. Continue to operate. The advantage of this method is that if kernel service A wants certain data, it can obtain it from other services in real time, and the implementation method is simple. The disadvantage is that the coupling with other services is too strong. Once the data of other services cannot be obtained, the kernel service A can only wait.

Specifically, the message queue communication method is to directly throw messages into the message queue, and the information in the message queue is visible to other kernel services, and other kernel services take the message from the message queue to perform related calculations. Therefore, the coupling is low and there is no need to wait for each other, but it is not suitable for situations such as web page access.

Exemplarily, the core service layer includes existing car service, driving service, statistical decision analysis, authority management service, basic data management and log management. Each kernel service adopts the single program form of the SpringBoot framework, independently publishes the service interface externally, and obtains the services of other single kernel programs through the service interface calling method. Furthermore, when the service scale is low and distributed deployment is not adopted, the document reading method is used to manage the interface. Preferably, as the scale of the service expands, the number of interfaces of the kernel service layer increases, and service automatic registration and discovery functions can be implemented by deploying service discovery to simplify calls between microservices.

Specifically, to use the kernel service, location information of the service needs to be provided externally, and the location information is usually an IP address and port information. In the case that the kernel service has only one use and the address does not change dynamically, the location of the kernel service can be fixedly generated on the use side through configuration files or codes. In this case, the document reading method is used to manage the interface, and information such as service address connection parameters is written into the document, and each kernel service is connected according to the preset connection method in the document. When the service scale is low and distributed deployment is not adopted, the management method of document reading is more convenient.

Specifically, when the kernel service provides services for multiple servers at the same time, different access addresses and access parameters will appear, and the access addresses and access parameters may even change. Automatic service registration means that when a certain microservice expands the new service address or changes the address, it automatically registers the new address to the registration center. When a certain service address becomes invalid due to machine failure or other reasons, it automatically cancels the address to the registration center. Service discovery means that when a client accesses a service, it automatically obtains an available access address through the registration center. Therefore, applications developed using the microservice architecture must solve this problem through service registration and discovery technologies.

The application kernel service layer is connected with public components, and the public components are used for multiplexing of communication functions among business components. Specifically, the public components include authorization modules, user operation records, general entity objects and general tool classes. Exemplarily, the authorization module can provide authorization functions for each microservice.

When the service scale is lower than the first set value and the distributed deployment is not adopted, the kernel service layer manages the service interfaces in a document-agreed manner; when the service scale is higher than the first set value, the number of interfaces is greater than the second set value When setting the value, use deployment service discovery to realize automatic service registration and discovery functions and simplify calls between microservices.

Further, the client in step S4 is implemented based on a browser, using a WebUI framework. The client includes a current vehicle distribution interface, a shunting plan management interface, a technical operation chart, a dispatch table, a statistical analysis interface, and a system maintenance interface.

The invention also discloses a data model based on the global existing vehicle management system, and Fig. 3 shows a data model diagram of the data model. As shown in Figure 3, the data model includes a station vehicle data set, a station data set and an in-transit vehicle data set, the station vehicle data set is used to store detailed information on vehicles staying in the station, and the station data set is used for Store the shunting plan and the current vehicle distribution data of the stock lane, the stock track current vehicle distribution data records the vehicle data pointers arranged in order in the stock track, the vehicle data pointer points to the vehicle detailed information in the station vehicle data set, the The Vehicles in Transit dataset is used to store detailed information about vehicles traveling en route.

Specifically, the station vehicle data set stores vehicle detailed information in a hash table structure, and the Key value in the hash table stores the car number of each train, which is required to be non-repeatable, and the Value value stores other vehicle information. Specifically, the vehicle detailed information includes information such as vehicle number, model, cargo, load, and vehicle status. The detailed information of the vehicle is stored through the hash table structure. When the vehicle information needs to be modified, the vehicle data can be obtained directly from the hash table only according to the vehicle number. The algorithm complexity is 0(1), which greatly saves the system The calculation process saves system computing power.

The station data set includes actual existing vehicle data, planned existing vehicle data and shunting plan data. Both the actual existing vehicle data and the planned existing vehicle data include a collection of lanes and vehicle relationships. What is stored in this collection is not real data, but an ordered list of data pointers. The data pointers point to the station vehicle data set vehicle details. When the vehicle detailed information in the station vehicle data set is changed, the actual existing vehicle data and planned existing vehicle data will also be changed in time through the data pointer, without recalculating the actual existing vehicle data and planned existing vehicle data. The shunting plan data is used to store the shunting plan sheet, and the actual existing vehicle data is deduced according to the shunting plan data to obtain the planned existing vehicle data.

Further, the data model also includes an in-transit data set model, and the in-transit vehicle data set model is used to store train formation information. Specifically, the train formation information includes train formation catalog information and train formation content information. The train formation directory records train numbers, train running lines, train arrival and departure types, train arrival and departure stations, and the like. The train formation catalog points to the train formation content information, and the train formation content information includes the detailed information of all the vehicles carried by the current train and the sequence of the vehicles. The arrangement order refers to the arrangement order of all the vehicles carried in the train. Exemplarily, the current station has three lanes, and vehicles are parked on each lane. The vehicle data set of the station records the relationship data between the three lanes and vehicles, and the vehicle data pointer is stored in the relationship data between each lane and vehicles. an ordered list of . When the vehicle of which the track is mentioned departs, a train formation information catalog and a train formation content will be generated in the vehicle data set in transit. The train formation catalog information records the train number, train arrival type, train departure lane, Information such as the train departure track, the train formation content records the detailed information and arrangement order of all vehicles on the departure track. At the same time, the station vehicle data set deletes the vehicle data that has been sent away on the lane, and clears the relationship data between the lane and the vehicle in the station data set. When the train enters the next station, add vehicle information to the vehicle data set at the station according to the train marshalling information and the receiving track, and add the receiving track and vehicle relationship data to the actual existing vehicle data of the corresponding station at the same time, according to the The shunting plan recalculates the planned current vehicle data. Compared with the data module of the CIPS system shown in Fig. 2, the data model based on the global existing vehicle management system of the present invention runs faster, saves the calculation process of the system, and saves the computing power of the system.

Based on the above-mentioned data model based on the global existing vehicle management system, the present invention also discloses a construction method of a data model based on the global existing vehicle management system. The data model construction method includes the following steps:

S1: Construction of station vehicle data collection station data set.

S2: Store the vehicle detailed information in the station vehicle data set.

Specifically, the vehicle detailed information includes vehicle number, model, cargo, load and vehicle status.

Preferably, the vehicle detailed information in step S2 is stored in the station vehicle data set in a hash table structure, wherein the Key value in the hash table stores the vehicle number and cannot be repeated, and the Value value stores other information of the vehicle.

S3: Store the vehicle data pointer in the station data set, the vehicle data pointer pointing to the vehicle detailed information in the station vehicle data set. Specifically, the station data set includes actual existing vehicle data and planned existing vehicle data; what is stored in the actual existing vehicle data and planned existing vehicle data is a set of relationship between lanes and vehicles, and in the set of relationship between lanes and vehicles What is stored is the vehicle data pointer.

Further, the data model also includes an in-transit vehicle data set model;

The vehicle data set model in transit is used to store train formation information, and the train formation information includes train formation catalog and train formation content;

The content of the train formation pointed to by the train formation directory records the detailed information and sequence of all vehicles carried in the train.

The data operation process based on the data model of the global existing vehicle management system includes the following steps:

S1: The station data model stores the data of actual existing vehicles, planned existing vehicles and shunting plans.

The actual existing vehicle and the planned existing vehicle store a relationship table of stock lane and vehicle data pointers. The vehicle data pointer points to the station vehicle data set. The station vehicle data center stores all the information of the vehicles parked in the station.

S2: When the departure station departs, generate train number data and store it in the in-transit vehicle data set, delete the existing train data at the departure station, and delete the vehicle data sent out from the station vehicle data set.

Generate train marshalling data according to departure track and departure number information. The train formation data includes the train formation directory and the train formation content, and the train formation data is stored in the vehicle data set in transit.

The deletion of the current vehicle data of the departure lane at the departure station means that the actual existing vehicle in the departure station data set stores the ordered list data of the departure lane and vehicle data pointers, find the data and clear it, and the actual existing vehicle departure unit after clearing Existing vehicles on the road were removed. According to the shunting plan set and the actual existing vehicle calculation, the new planned existing vehicle is obtained. Through the calculation, the existing vehicle on the starting lane of the new planned existing vehicle is deleted.

Go to the station vehicle data set to find the sent vehicle data and delete it.

S3: The train arrives at the pick-up station, extracts the train marshalling data, adds the connected vehicle data to the station vehicle data set, and adds the current vehicle data to the station data set of the pick-up station.

The extracting train formation data and adding the accessed vehicle data to the station vehicle data set refers to extracting the train formation information to the in-transit vehicle data set according to the arriving train information, and adding the train formation information to the station vehicle data set according to the formation content in the train formation information. Detailed data of the vehicle.

Adding the current train data to the station data set of the receiving station refers to, according to the receiving train lane of the arriving train entering the station, find the receiving train lane in the actual existing train of the station data set of the receiving station, and add the data to the train according to the content of the arriving train marshalling The list of vehicle data pointers is added to the pick-up lane, and after the addition, the current vehicle information is added to the pick-up lane of the actual existing vehicle. According to the actual existing vehicle and shunting plan, the new planned existing vehicle of this station is calculated, and the received current vehicle information appears on the pick-up lane of the calculated planned existing vehicle.

To sum up, through the reasoning of the data operation process of this data model, the operation of vehicles between various stations is realized.

The invention also discloses a method for calculating the distribution of existing vehicles. Figure 4 shows the flow chart of calculating the cut plane of the actual existing vehicle distribution, and the steps are as follows:

S1: Read the actual vehicle distribution section and shunting plan list data;

S2: Set the corresponding shunting plan in the shunting plan list as the reporting state;

S3: Calculate the new actual vehicle section according to the original actual vehicle section and the shunting plan reported;

S4: If the calculation of the section of the actual existing vehicle fails, cancel the report point status of the vehicle return plan;

If the calculation of the actual existing vehicle section is successful, calculate the new planned existing vehicle section according to the new actual existing vehicle section and all unreported shunting plans;

S5: If the calculation of the planned existing vehicle section fails, withdraw the reporting status of the planned vehicle section; if the planned existing vehicle section calculation is successful, update the actual existing vehicle section and update the planned existing vehicle section, that is, the report is successful.

Specifically, the actual current vehicle section refers to the distribution of vehicles on each lane in the current station at this moment, and each lane displays different order of vehicles, each vehicle has a unique number, and also displays the vehicle The model and cargo information loaded.

The shunting plan list refers to the work plan list prepared by station dispatchers for the shunting machine to drop, hook and move vehicles. At the freight station, it is necessary to load and unload trucks and vehicles, transfer vehicles between different lanes, and adjust the order of vehicles in the same lane. In order to complete this series of operations, the station dispatcher will prepare multiple shunting plans in sequence in advance, and the multiple shunting plans will be arranged into a list of shunting plans according to the order of compilation, as shown in Figure 5, the upper part is prepared by the station dispatcher The shunting plan list, there are 3 shunting plans in the list. The following shows the specific content of the selected first shunting plan. The operation content is divided into two steps: (1) the shunting machine hangs 64 vehicles from the east of No. I-1 Stock Road (2) the shunting machine connects -IIA No. 1 stock road owner dropped 64 vehicles. Thereby realize that 64 cars in the I-1 No. stock track are moved to the I-IIA No. stock track.

Specifically, the shunting plan includes an unreported shunting plan and a reported shunting plan. The unreported shunting plan refers to the shunting plan that has not started operations at the station site, and the actual on-site vehicles in the lane have not yet moved. The reported shunting plan refers to the shunting plan that has completed operations on the station site. The outdoor on-site shunting operators (shunting chief, picker, locomotive driver, etc.) first obtain the unreported shunting plan, according to The content of the shunting plan is carried out on-site. When the shunting operation is completed, the completion time of the shunting plan will be reported. At this time, the unreported shunting plan becomes the reported shunting plan.

Specifically, the planned current vehicle section refers to the distribution of vehicles on each lane in the future calculated by the system based on the unreported shunting plan. Usually, the station dispatcher will prepare a series of shunting plans in advance according to the on-site operation situation, and the system will calculate the unreported shunting plans in sequence according to the order of the shunting plan list according to the actual current vehicle sections, and obtain the planned current vehicle sections. As shown in Figure 6, P ₁ ~ P _n is the shunting plan that has been reported, P _n+1 ~ P _n+m is the shunting plan that has not been reported, realTracks is the actual current vehicle section, and planTracks is the planned existing vehicle section . The system calculates and plans the section of existing vehicles, which can help station dispatchers to grasp the distribution of existing vehicles in the station after the implementation of the future shunting plan in advance, and continue to prepare subsequent shunting plans according to the planned section of existing vehicles.

Exemplarily, as shown in FIG. 9 , the shunting plan list is composed of P ₁ , P ₂ to P _n , P _n+1 , and P _n+2 to P _n+m . At this time, the shunting plan before the shunting plan P _n has all been reported, and the actual distribution section of existing vehicles is P _n . It is worth explaining that the actual distribution section of existing vehicles _is P _n . The actual distribution section of the current vehicle is the same as the following, and will not be explained again. At this time, it is necessary to report the shunting plan P _n+1 . According to the shunting plan P _n+1 , a new actual existing vehicle distribution section P _n+ 1 is derived. It is necessary to recalculate and verify the distribution of planned existing vehicles in order to ensure the accuracy of the reporting point.

Exemplarily, the unreported shunting plans P _n+1 , P _n+2 to P _n+m are sequentially calculated according to the actual existing vehicle section to obtain a new planned existing vehicle section. If the new planned existing vehicle can be successfully calculated If the section is cut, it is judged that the reporting point is successful.

Further, the specific steps of the actual existing vehicle distribution section and the shunting plan list data read in step S1 are as follows:

Read the actual vehicle section and shunting plan list data from the database, and load the data into the system memory;

Specifically, the database is used to persist the actual current vehicle section and shunting plan data. When the system is initialized, the data in the database is loaded into the system memory and the calculated and planned current vehicle section data is stored in the memory. Therefore, when the system is running, the system memory stores the actual data. Existing vehicle section, planned existing vehicle section and shunting plan list data. The memory data is calculated and updated in real time according to user operations, and the actual vehicle distribution and shunting plan data in the memory are updated and synchronized to the database in real time.

In the system memory, according to the actual existing vehicle distribution section, the unreported shunting plan in the shunting plan list is sequentially deduced, and the planned existing vehicle distribution section is obtained and stored in the system memory.

In the actual work process, the shunting plan list in step S1 is a process of continuous updating, and a shunting plan will be added at the same time as the point is reported. Figure 7 shows the flow chart of calculating the existing vehicle distribution when creating a new shunting plan, and the steps are as follows:

S11: Put the new shunting plan at the end of the shunting plan list.

S12: Calculating the new planned current vehicle section according to the original planned existing vehicle section and the new shunting plan.

Exemplarily, as shown in Figure 8, P _n _+m+1 is the newly added shunting plan, planTracks1 is the current vehicle section of the original plan, and the new plan can be calculated according to the current vehicle section of the original plan Existing car section planTracks2.

S13: If the calculation is successful, update the planned existing vehicle section to a new planned existing vehicle section; if the calculation fails, do not update the planned existing vehicle distribution, and delete the newly created shunting plan from the shunting plan list.

Specifically, the criterion for successful calculation is that the system searches the lanes for corresponding vehicles according to the content of the shunting plan, and the order of the vehicles must be consistent with the order of vehicles specified in the shunting plan.

Further, in order to facilitate operation and save time according to the actual situation on the site, sometimes the operator does not carry out on-site operations step by step according to the shunting plan list, and may skip a shunting plan and execute the next shunting plan first Plan, and then skip the shunting plan, that is, report the points in sequence according to the shunting plan list.

Exemplarily, when the reporting points are not strictly followed in the order of the shunting plan list, the calculation steps are the same as above. First, the new actual existing vehicle section is calculated according to the original actual existing vehicle section and the reported reporting point shunting plan, and then according to the new actual According to the sequence of the shunting plans in the shunting plan list, the current vehicle distribution section calculates the unreported shunting plan in turn to obtain a new planned existing vehicle distribution section.

Exemplarily, as shown in FIG. 10 . The current actual vehicle distribution section is P _n , the shunting plan P _n+1 is skipped, and the shunting plan P _n+2 is reported first. At this time, the original actual current vehicle section is derived according to the shunting plan P _n+2 , and the shunting plan P _n+1 is ignored to obtain a new actual current vehicle section. Then, according to the new actual existing vehicle section and all unreported shunting plans in the shunting plan list, calculate P _n+1 , P _n+3 to P _n+m to the new planned existing vehicle section according to the sequence of the plan , if the planned existing vehicle section can be successfully calculated, then it is judged that the reporting point is successful, the actual existing vehicle distribution section is updated, and the planned existing vehicle section is updated, otherwise, it is judged that the reporting point fails.

Exemplarily, the necessity of calculating the new planned current vehicle section according to the new actual current vehicle section to verify the correctness of the vehicle shunting plan report point is exemplified. As shown in Figure 11, the current actual current vehicle section, car No. 0001 is at 1G, and the station dispatcher sequentially compiles three shunting plans P ₁ , P ₂ , and P ₃ that have not been reported. The shunting plan is as follows:

(1) P ₁ moves the vehicle from 1G to 2G.

(2) P ₂ moves the vehicle from 2G back to 1G.

(3) P ₃ moves the vehicle from 1G to 3G.

After calculating P ₁ , P ₂ , and P ₃ , on the planned current vehicle section, vehicle No. 0001 was finally moved to 3G. Work on site according to the shunting plan and complete P ₁ . If the on-site staff reports point P ₁ correctly. At this time, on the new actual vehicle section, vehicle No. 0001 was moved to 2G. The new actual existing vehicle section continues to calculate P ₂ and P ₃ , and the planned existing vehicle section can be calculated normally. If the on-site staff makes a mistake and reports P ₃ instead of P ₁ , the system first calculates the new actual section to move the vehicle to 3G, and then calculates P ₁ and P ₂ sequentially based on the new actual section , when calculating P ₁ , it is found that No. 0001 car does not exist in 1G on the new actual current vehicle cut plane (the vehicle is at 3G at this time), so the calculation is wrong, and the system judges that the on-site operator reports a wrong point, thus effectively preventing the on-site personnel from misoperation.

The invention also discloses an existing vehicle distribution calculation system, which includes an access module and a calculation module. The access module is used to read the actual vehicle distribution section and the list of shunting plans. The calculation module is used to derive a new actual existing vehicle distribution section in order from the actual existing vehicle distribution section according to the shunting plan in the shunting plan list, and continue to obtain a new actual existing vehicle distribution section according to all unreported shunting plans. Cut planes are deduced to obtain planned current vehicle cut planes.

Specifically, the access module includes a database and system memory. The database is used to save the actual vehicle distribution section and shunting plan list data, and the data can be persisted. When the system is initialized and started, the data can be loaded from the database into the system memory; the system memory stores the actual vehicle distribution section and shunting plan list data, so The derivation module calculates the planned distribution section according to the actual existing vehicle distribution section and the tram plan list, and stores it in the system memory. Due to the fast reading speed of the memory data, the updated data can be estimated and updated in real time according to user operations to ensure the real-time performance of the system. When the actual vehicle distribution section in the memory and the shunting plan data are updated, they are synchronized to the database to ensure the consistency between the system memory data and the database data. sex. The calculation module is used to calculate and update the actual existing vehicle distribution section according to the data of the shunting plan in the shunting plan list.

Specifically, the list of shunting plans includes unreported shunting plans and reported shunting plans.

When the newly added shunting plan needs to update the planned existing vehicle distribution section, the calculation module is used to put the new shunting plan into the last position of the shunting plan list; calculate the new plan according to the original planned existing vehicle section and the newly created shunting plan Existing vehicle section; if the calculation is successful, update the planned existing vehicle section to the new planned existing vehicle section; if the calculation fails, do not update the planned existing vehicle distribution, and delete the newly created shunting plan from the shunting plan list.

Calculation of the new actual vehicle distribution section when the shunting plan is reported includes: setting the corresponding shunting plan in the shunting plan list as the report status; calculating the new section according to the original actual current vehicle section and the reported shunting plan Actual existing vehicle section; Calculate the planned existing vehicle section according to the new actual existing vehicle section and all unreported shunting plans; if the calculation of the planned existing vehicle section fails, cancel the reporting status of the return plan. If the calculation of the planned existing vehicle section is successful, the actual existing vehicle section is updated, and the planned existing vehicle section is updated. If the calculation of the actual existing vehicle section fails, the report point status of the return vehicle plan is withdrawn; if the calculation of the actual existing vehicle section is successful, the new planned existing vehicle distribution section is further calculated.

When reporting points are not carried out in accordance with the order of the shunting plan list, the specific derivation steps include the following: Calculate the new actual existing vehicle section according to the original actual existing vehicle section and the reported shunting plan; according to the new actual existing vehicle distribution section in order Calculating the unreported shunting plan to obtain a new planned distribution section of existing vehicles.

Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that: they can still modify the technical solutions described in the aforementioned embodiments, or perform equivalent replacements for some of the technical features; and these The modification or replacement does not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the various embodiments of the present invention.

Claims

A global-based existing vehicle management system is characterized in that,

The overall-based existing vehicle management system includes a client, an application aggregation service layer, an application kernel service layer and a database layer;

The client is used for human-computer interaction work on the global-based existing vehicle management system;

The application kernel service layer is used to implement core business logic and provide external services through the application aggregation service layer;

The application aggregation service layer is used for all microservices of the application kernel service layer, decoupling the client, the kernel service layer and external systems;

The database layer communicates with the application kernel service layer to provide data storage and data call for the application kernel service layer.
The existing vehicle management system based on overall situation according to claim 1, characterized in that,

The client is implemented based on a browser and uses a WebUI framework.
The existing vehicle management system based on overall situation according to claim 2, wherein,

The client includes a current vehicle distribution interface, a shunting plan management interface, a technical operation chart, a dispatch table, a statistical analysis interface, and a system maintenance interface.
The existing vehicle management system based on overall situation according to claim 1, characterized in that,

The application aggregation service layer includes a Web application aggregation service and an interface micro-service platform;

The Web application aggregation service is used to provide a unified service API for all PCs and APPs;

The interface micro-service platform is used to abstract the interface part of the external system into a separate interface layer, which is separated from the business layer.
The existing vehicle management system based on overall situation according to claim 4, characterized in that,

The external systems include planning dispatching information system, locomotive depot information system, vehicle dispatching information system, freight dispatching information system, vehicle number identification system and construction management information system.
The existing vehicle management system based on overall situation according to claim 1, characterized in that,

The application kernel service layer includes a plurality of kernel services, each of which is relatively independent, loosely coupled with each other, and communicates through RESful and/or message middleware.
The existing vehicle management system based on the overall situation according to claim 6, wherein,

The multiple core service layers include existing vehicle service, driving service, statistical decision analysis, authority management service, basic data management and log management.
The existing vehicle management system based on the overall situation according to claim 6, wherein,

The core service adopts the form of a single program based on the SpringBoot framework, independently publishes service interfaces externally, and obtains services of other single core programs through service interface calls.
The existing vehicle management system based on the overall situation according to claim 8, wherein,

When the service scale is lower than the first set value and the distributed deployment is not adopted, the kernel service layer manages the service interfaces in a document-agreed manner; when the service scale is higher than the first set value, the number of interfaces is greater than the second set value When setting the value, use deployment service discovery to realize automatic service registration and discovery functions and simplify calls between microservices.
The existing vehicle management system based on overall situation according to claim 1, characterized in that,

The application core service layer is connected with public components, and the public components are used for multiplexing of common functions among business components.
The existing vehicle management system based on the overall situation according to claim 10, wherein,

The public components include authentication and authorization modules, user operation records, general entity objects, and general tool classes.
The existing vehicle management system based on overall situation according to claim 1, characterized in that,

The global-based existing vehicle management system adopts the SOA B/S micro-service architecture.
A kind of existing vehicle management method based on overall situation, it is characterized in that,

The vehicle management method includes the following steps:

S1: Use the application kernel service layer to implement core business logic, and provide external services through the application aggregation service layer;

S2: Use the application aggregation service layer to aggregate all the microservices of the application kernel service layer, and decouple the client, kernel service layer and external systems;

S3: use the database layer to communicate with the application kernel service layer, and provide data storage and data call for the application kernel service layer;

S4: Use the client to perform human-computer interaction on the global-based existing vehicle management system.
The existing vehicle management method based on overall situation according to claim 13, characterized in that,

The core service described in step S1 adopts the form of a single program based on the SpringBoot framework, independently publishes the service interface externally, and obtains the services of other single core programs through the service interface call.
The existing vehicle management method based on overall situation according to claim 13, characterized in that,

The application aggregation service layer described in step S2 includes a Web application aggregation service and an interface microservice platform;

The Web application aggregation service is used to provide a unified service API for all PCs and APPs;

The interface micro-service platform is used to abstract the interface part of the external system into a separate interface layer, which is separated from the business layer.
The existing vehicle management method based on overall situation according to claim 13, characterized in that,

When the service scale is lower than the first set value and the distributed deployment is not adopted, the kernel service layer manages the service interfaces in a document-agreed manner; when the service scale is higher than the first set value, the number of interfaces is greater than the second set value When setting the value, use deployment service discovery to realize automatic service registration and discovery functions and simplify calls between microservices.
The existing vehicle management method based on overall situation according to claim 13, characterized in that,

The client in step S4 is implemented based on a browser, using a WebUI framework.