OA21013A - Present car global management system and method thereof. - Google Patents

Abstract

The present disclosure belongs to a field of railway management systems, and more particularly, relates to a present car global management system and a method thereof. The present car global management system includes a client, an application aggregation service layer, an application kernel service layer, and a database layer. The client is configured to perform humancomputer interaction on the present car global management system; the application kernel service layer is configured to implement kernel business logic and provide services to the outside through the application aggregation service layer; the application aggregation service layer is configured to supply all micro-services of the application kernel service layer, decouple the client, a kernel service layer and an external system; the database layer communicates with the application kernel service layer, and provides data storage and data calling for the application kernel service layer. The present disclosure can implement multi-station present car data sharing and collaborative management.

Description

DETAILED DESCRIPTION

[0055] In order to make objectives, technical details and advantages of the embodiments of the présent disclosure apparent, the technical solutions according to the embodiments of the présent disclosure will be described in a clearly and fully understandable way in connection with drawings of the embodiments of the présent disclosure. It is obvious that the described embodiments are just a part but not ail of the embodiments of the présent disclosure. Based on the described embodiments herein, those ordinarily skilled in the art can acquire other embodiment(s), without any inventive operation, which should be within the scope of the présent disclosure.

[0056] The présent disclosure discloses a présent car management System, and FIG. 1 shows a technical architecture diagram of the présent car management System. As shown in FIG. 1, the présent car management System includes a client, an application aggregation service layer, an application kernel service layer and a database layer.

[0057] Exemplarily, the présent car management System adopts an SOA-based B/S micro-service framework; by adopting the SOA-based B/S micro-service architecture, installation, deployment and System maintenance of a human-computer interaction terminal may be simplified, and respective items of business logic processing may also be dispersed in respective micro-services, which improves parallel computing capability and data throughput of the présent car management System.

[0058] Further, communication between the client and the application aggregation service layer as well as the application kernel service layer adopts a RESTful-style lightweight API. The RESTful-style lightweight API may enable the présent car management System to be used across platforms, for example, may provide web pages, ios, and android at a same time for use; in addition, the présent car management System may effectively découplé a frontend and a backend; and the frontend may judge a retum resuit only according to a general State code. For example, the State code retumed by a traditional web page API only includes 200, and needs a developer to customize a communication State between the server and the client. When the RESTfùl-style interface is used, different State codes may be retumed, for example, the most commonly used 200 represents success, 500 represents internai Server internai error, and 403 represents Bad Request, etc.

[0059] The client is configured to perform human-computer interaction on the présent car management System. Exemplarily, the client is a mobile phone APP terminal and/or a PC terminal. Preferably, the client is implemented based on a browser and adopts a WebUI framework. The browser-based implémentation may simplify installation, deployment and System maintenance of the client; and the WebUI framework may ensure a friendly style of the user interface and convenience of subséquent software itérative upgrades. The user interface is configured to display a présent car distribution interface, a shunting plan management interface, a technical operation chart, a receiving-departure list, a statistical analysis interface and a System maintenance interface. The client may view présent car distribution in real time, may présent both a technical operation chart and a statistical analysis model generated by the présent car management System; may send a shunting plan to the présent car management System; and may also perform System maintenance on the présent car management System.

[0060] The application aggregation service layer is confïgured to aggregate ail micro-services of the application kernel service layer, and provide a unified access interface for an extemal System; and is further confïgured to découplé the client, the interface layer, the application kernel service layer and the extemal System; wherein, the application kemel service layer is confïgured to provide services to the outside through the application aggregation service layer.

[0061] Specifically, the application aggregation service layer includes a Web application aggregation service and an interface micro-service platform. The Web application aggregation service is confïgured to provide a unified service API for ail PC terminais and APP terminais, so that the présent car management System only needs to develop one version of service program applicable to web pages and Android, without separately developing an Android version and a web version; the interface micro-service platform abstracts the interface portion of the extemal System into an individual interface layer, which is separated from the business layer and avoids coupling with business logic, so that the System business functions will not be affected when problems occur in the interaction process of the application aggregation service layer and the external System.

[0062] The application aggregation service layer undertakes a function of a service gateway, without state persistence processing, so as to facilitate serving as a load and improving throughput. The application aggregation service layer is not only confïgured to undertake the function of the service gateway, but also confïgured for load balancing. Load balancing refers to evenly distributing access requirements of a large number of users to respective servers.

[0063] The présent car management System docks with the extemal System through the interface micro-service platform; each interface service of the interface micro-service platform is an independent micro-service, and interacts with the extemal System through the application aggregation service layer.

[0064] Exemplarily, the external System includes a planning and dispatching information System, a depot information System, a car dispatching information System, a freight dispatching information System, a car number identification System and a construction management information system.

[0065] The application kernel service layer is configurée! to implement kernel business logic, and provides services to the outside through the application aggregation service layer. Specifically, the application kernel service layer includes a plurality of kernel services; the kernel services are independent of each other; and the kernel services are loosely coupled with each other, communicating through RESTful or message queues.

[0066] Application scénarios of the two communication modes are different.

[0067] Specifically, the RESTful communication mode is: sending a request, waiting for feedback, obtaining feedback and processing feedback information. That is to say, kernel service A requests data from kernel service B and then waits for retum from kernel service B, and a communication is not completed until a retum value from kernel service B is obtained. Such a scénario is applicable to a user accessing a web page and waiting for the server to return web page information. Or kernel service A is performing an operation, and must use a certain piece of data from kemel service B to complété the operation; therefore, it is necessary to use the RESTful communication mode to request kemel service B, and kemel service A is able to continue the operation only after obtaining the data retumed by kemel service B. An advantage of the mode is that, if kemel service A wants a certain piece of data, it may acquire from other services in real time, so the implémentation mode is simple. A disadvantage is that, intensive coupling with other services is required; and once the data of other services cannot be obtained, kemel service A may only wait.

[0068] Specifically, the message queue communication mode is: directly throwing a message into a message queue; information in the message queue is visible to other kemel services; and other kemel services take the message from the message queue and perform related calculations. Therefore, coupling is less intensive, and there is no need to wait for each other, but it is not applicable to web page access and other situations.

[0069] Exemplarily, the kemel service layers include présent car service, traffic service, statistical decision analysis, authority management service, basic data management and log management. Each kemel service adopts a single program form based on a SpringBoot framework, independently publishes a service interface to the outside, and acquires services of other single kemel programs in a service interface calling mode. Further, in a case where a service scale is low and distributed deployment is not adopted, the interface is managed by document reading. Preferably, as the service scale expands and the number of interfaces increases, the kernel service layer may implement service automatic registration and discovery functions by adopting deployment service discovery to simplify calling between micro-services.

[0070] Specifically, to use the kernel service, position information of the service needs to be provided to the outside, and the position information is usually information of IP address and port. In a case where only a single kernel service is used and an address does not change dynamically, location of the kernel service may be fixedly generated by configuring a file or a code, etc. on the user side. In this case, the document reading mode is adopted to manage the interface, to write information such as service address connection parameter into the document; and respective kernel services are connected in a connection mode preset in the document. When the service scale is low and distributed deployment is not adopted, it is more convenient to use the document reading management mode.

(0071] Specifically, when the kernel service simultaneously provides services for a plurality of servers, different access addresses and access parameters may appear, and the access addresses and access parameters may even change. Automatic service registration refers to that, when a certain micro-service expands a new service address or changes the address, the new address is automatically registered to a registration center; and when a certain service address fails due to machine failure, etc., the address is automatically deregistered from the registration center. Service discovery refers to that, when a client accesses a certain service, it automatically acquires an available access address through the registration center. Therefore, applications developed by using the micro-service architecture must solve the problem through service registration and discovery technologies.

[0072] The application kemel service layer is connected with a common component; and the common component is configured to multiplex communication functions among business components. Specifically, the common component includes an authorizing module, a user operation record, a general entity object, and a general tool class. Exemplarily, the authorizing module may provide authorization functions for respective micro-services.

[0073] The database layer communicates with the application kemel service layer, il and provides data storage and data calling for the kernel service layer.

[0074] The présent disclosure further discloses a présent car global management method, wherein, the présent car management method includes steps of:

[0075] SI: using an application kernel service layer to implement kernel business logic, and provide services to the outside through an application aggregation service layer;

[0076] S2: using the application aggregation service layer to aggregate ail micro-services of the application kernel service layer, and découplé a client, a kernel service layer and an extemal System;

[0077] S3: using the database layer to communicate with the application kernel service layer, and provide data storage and data calling for the application kernel service layer;

[0078] S4: using the client to perform human-computer interaction on a présent car global management System.

[0079] Further, the kernel service as described in step SI adopts a single program form based on a SpringBoot framework, independently publishes service interfaces to the outside, and acquires services of other single kernel programs in a service interface calling mode.

[0080] Further, the application aggregation service layer as described in step S2 includes a Web application aggregation service and an interface micro-service platform;

[0081] The Web application aggregation service is configured to provide a unified service API for ail PC terminais and APP terminais;

[0082] The interface micro-service platform is configured to abstract an interface portion of the extemal System into an individual interface layer, which is separated from a business layer.

[0083] When a service scale is lower than a first set value and distributed deployment is not adopted, the kernel service layer manages a service interface by document convention; when the service scale is higher than the first set value, and the number of interfaces is greater than a second set value, the kernel service layer implements service automatic registration and discovery functions by adopting deployment service discovery to simplify calling between micro-services.

[0084] Further, the client as described in step S4 is implemented based on a browser and adopts a WebUI framework. The client includes a présent car distribution interface, a shunting plan management interface, a technical operation chart, a receiving-departure table, a statistical analysis interface and a system maintenance interface.

[0085] The présent disclosure further discloses a data model based on a présent car global management system; and FIG. 3 shows a data model diagram of the data model. As shown in FIG. 3, the data model includes a station car dataset, a station dataset and an in-transit car dataset; the station car dataset is configured to store detailed information of cars staying in the station; the station dataset is configured to store a shunting plan and on-track présent car distribution data; the on-track présent car distribution data records car data pointers arranged in sequence in the track; the car data pointer points to the car detailed information in the station car dataset; and the in-transit car dataset is configured to store detailed information of a car in transit.

[0086] Specifically, the station car dataset stores car detailed information in a hash table structure; a Key value in the hash table stores a car number of each train, and is required to be non-repeatable; and a Value value stores other information of the car. Specifically, the car detailed information includes information such as car number, car model, cargo, load, and car State, etc. The car detailed information is stored in the hash table structure; when the car information needs to be modified, the car data may be directly acquired from the hash table only according to the car number, so that algorithm complexity is 0 (1), which greatly saves operation procedures of the system, and saves computing power of the system.

[0087] The station dataset includes real présent car data, plan présent car data, and shunting plan data. The real présent car data and the plan présent car data each include a collection of track-car relationships; what is stored in the collection is not real data, but an ordered list of data pointers; and the data pointers point to the car detailed information in the station car dataset. When the car detailed information in the station car dataset is changed, the real présent car data and the plan présent car data will also change in time through the data pointer, without re-estimating the real présent car data and the plan présent car data. The shunting plan data is configured to store the shunting plan list; and the real présent car data is deduced according to the shunting plan data to obtain the plan présent car data.

[0088] Further, the data model further includes an in-transit dataset model; and the in-transit car dataset model is configured to store train marshalling information. Specifically, the train marshalling information includes train marshalling directory information and train marshalling content information. The train marshalling directory records train number, train running line, train receiving-departure type, train receiving-departure station, etc. The train marshalling directory points to the train marshalling content information; and the train marshalling content information includes detailed information of ail cars carried by a current train and an arrangement order of the cars. The arrangement order refers to an arrangement order of ail cars carried in the train. Exemplarily, there are three tracks at the current station; each track has cars staying thereon; the station car dataset records relationship data between the three tracks and the cars; and relationship data of each track and a car stores an ordered list of car data pointers. At departure of a car on one track, a train marshalling information directory and a copy of train marshalling content will be generated in the in-transit car dataset; the train marshalling directory information records information such as train number, train receiving-departure type, train departure track, and train receiving track, etc.; the train marshalling content records detailed information and an arrangement order of ail cars on the departure track. Meanwhile, data of the car that has departed on the track is deleted from the station car dataset; and relationship data between the track and the car in the station dataset is cleared. When the train enters a next station, car information is added to the station car dataset according to the train marshalling information and the receiving track; meanwhile, relationship data between the receiving track and the car is added to the real présent car data at the corresponding station; and the plan présent car data is re-estimated according to the shunting plan. As compared with the data module of the CIPS System shown in FIG. 2, the data model of the présent car global management System according to the présent disclosure runs faster, which saves an operation procedure of the System and saves computing power of the System.

[0089] Based on the above-described data model of the présent car global management System, the présent disclosure further discloses a construction method of a data model of a présent car global management System, wherein, the data model construction method includes steps of:

[0090] SI : constructing a station car dataset and a station dataset.

[0091] S2: storing car detailed information in the station car dataset.

[0092] Specifically, the car detailed information includes car number, car model, cargo, load, and car State.

[0093] Preferably, the car detailed information as described in step S2 is stored in the station car dataset in a hash table structure, wherein, a Key value in the hash table stores the car number and is non-repeatable; and a Value value stores other information of the car.

[0094] S3: storing a car data pointer in the station dataset, wherein, the car data pointer points to the car detailed information in the station car dataset. Specifically, the station dataset includes real présent car data and plan présent car data; what is stored in the real présent car data and the plan présent car data is a track-car relationship set; and what is stored in the track-car relationship set is the car data pointer.

[0095] S4: using the client to perform human-computer interaction on the présent car global management system.

[0096] Further, the data model further includes an in-transit car dataset model;

[0097] The in-transit car dataset model is configured to store train marshalling information; and the train marshalling information includes a train marshalling directory and a train marshalling content;

[0098] The train marshalling content pointed to by the train marshalling directory records detailed information and an arrangement order of ail cars carried in the train.

[0099] A data operation procedure of the data model of the présent car global management system includes steps of:

[00100] SI: storing real présent car, plan présent car and shunting plan data in the station data model.

[00101] What is stored in the real présent car and the plan présent car is a track-car data pointer relationship table. The car data pointer points to the station car dataset. The station car dataset stores information of ail cars parked in the station.

[00102] S2: generating, at departure in the departure station, the train marshaling data to store in the in-transit car dataset, deleting présent car data on the departure track in the departure station, and deleting, from the station car dataset, data of the car that has departed.

[00103] Train marshalling data is generated according to information of departure track and departure train number. The train marshalling data includes the train marshalling directory and the train marshalling content; and the train marshalling data is stored in the in-transit car dataset.

[00104] The deleting présent car data on the departure track in the departure station refers to, finding ordered list data of the departure track and the car data pointer stored by the real présent car in the station dataset at the departure station, and clearing the same, so that after clearing, the présent car on the real présent car departure track is deleted. According to the shunting plan set and the real présent car, a new plan présent car is estimated; and through estimation, the présent car on the departure track among the new plan présent cars is deleted.

[00105] Data of the car that has departed is found in the station car dataset and is deleted.

[00106] S3: the train arriving at the receiving station, extracting the train marshalling data, adding the received car data to the station car dataset, and adding the présent car data to the station dataset of the receiving station.

[00107] The extracting the train marshalling data and adding the received car data to the station car dataset refers to: extracting the train marshalling information from the in-transit car dataset according to the arriving train information, and adding detailed data of the car into the station car dataset according to the marshaling content in the train marshalling information.

[00108] The adding the présent car data to the station dataset of the receiving station refers to: finding the receiving track in the real présent car in the station dataset of the receiving station according to the receiving track of the arriving train entering the station, and adding a car data pointer list to the receiving track according to the arriving train marshalling content, so that after the addition, the présent car information is added to the receiving track of the real présent car. According to the real présent car and the shunting plan, a new plan présent car at the présent station is estimated, and the received présent car information appears on the receiving track of the estimated plan présent car.

[00109] To sum up, through reasoning of the data operation procedure of the data model, operation of cars between respective stations is implemented.

[00110] The présent disclosure further discloses a présent car distribution estimating method. FIG. 4 shows a flow chart of estimation of a real présent car distribution section, including steps of:

[00111] SI : reading a real présent car distribution section and shunting plan list data;

[00112] S2: setting a corresponding shunting plan in the shunting plan list to a point report State;

[00113] S3: estimating a new real présent car section according to the original real présent car section and the shunting plan having point report implemented;

[00114] S4: if estimation of the real présent car section fails, withdrawing the shunting plan point report State;

[00115] If estimation of the real présent car section succeeds, estimating a new plan présent car section according to the new real présent car section and ail shunting plans having point report unimplemented;

[00116] S5: if estimation of the plan présent car section fails, withdrawing the shunting plan point report State; if estimation of the plan présent car section succeeds, updating the real présent car section, and updating the plan présent car section, that is, point report succeeds.

[00117] Specifically, the real présent car section refers to a distribution situation of cars on respective tracks at the présent moment in the current station; wherein, each track displays a different car arrangement order; each car has a unique car number; and meanwhile, information of car model and loaded cargo is also displayed.

[00118] The shunting plan list refers to an operation plan list for a shunting locomotive to couple, uncouple and move cars as formulated by a station dispatcher. At a freight station, a sériés of operations such as loading and unloading of freight cars, transferring cars between different tracks, and adjusting an order of cars in a same track are required. In order to complété the sériés of operations, the station dispatcher will formulate a plurality of shunting plans in advance according to an order, and arrange the plurality of shunting plans into a shunting plan list in the formulation order; as shown in FIG. 5, the upper diagram is a shunting plan list formulated by a station dispatcher, and there are 3 shunting plans in the list. The lower diagram shows a spécifie content of a first shunting plan selected, having an operation content divided into two steps: (1) a shunting locomotive hangs 64 cars from the east of track No. 1-1; and (2) the shunting locomotive unhangs 64 cars form the east end on track No. I-IIA. In this way, the 64 cars in track No. 1-1 are moved to track No. I-IIA.

[00119] Specifically, the shunting plan include a shunting plan having point report unimplemented and a shunting plan having point report implemented. The shunting plan having point report unimplemented refers to a shunting plan that operation has not started at the station site, and cars in the real on-site track hâve not moved. The shunting plan having point report implemented refers to a shunting plan that operation has completed at the station site; outdoor on-site shunting operators (a yardmaster, an uncoupling operator, a locomotive driver, etc.) firstly acquire the shunting plan having point report unimplemented, and carry out on-site operation according to the shunting plan content; when the shunting operation is completed, an operation completion time point of the shunting plan will be reported; at this time, the shunting plan having point report unimplemented becomes the shunting plan having point report implemented.

[00120] Specifically, the plan présent car section refers to a distribution situation of cars on respective tracks at a future moment as estimated by the system according to the shunting plan having point report unimplemented. Usually, the station dispatcher will formulate a sériés of shunting plans in advance according to on-site operation situations; and the system sequentially estimâtes shunting plans having point report unimplemented in an order of the shunting plan list according to the real présent car section, to obtain the plan présent car section. As shown in FIG. 6, Pi to P_n are shunting plans having point report implemented, P_n -i to P_n+_m are shunting plans having point report unimplemented; realTracks is a real présent car section, and planTracks is a plan présent car section. The system estimâtes the plan présent car section, which may help the station dispatcher to grasp in advance présent car distribution situation in the station after implémentation of the future shunting plan, and continue to formulate a subséquent shunting plan according to the plan présent car section.

[00121] Exemplarily, as shown in FIG. 9, the shunting plan list is composed of Pi, P2 to P_n, Pn+i, and P_n+2 to Pn+m. At this time, ail the shunting plans before the shunting plan P_n hâve point report completed, and the real présent car distribution section is P_n; it is worth explaining that, that the real présent car distribution section is P_n refers to the présent car real distribution section after completion of the shunting plan P_n; the same is true hereinafter, and no explanation will be repeated. At this time, it is necessary to report point for the shunting plan Pn+i. According to the shunting plan P_n+i, a new real présent car distribution section P_n+i is derived. It is necessary to re-estimate and verify the plan présent car distribution section in order to ensure accuracy of point report.

[00122] Exemplarily, shunting plans P_n+i, Pn+2 to P_n+m having point report unimplemented are sequentially estimated according to the real présent car section to obtain a new plan présent car section; if the new plan présent car section can be successfully estimated, then it is determined that point report succeeds.

[00123] Further, the reading a real présent car distribution section and shunting plan list data in step SI has spécifie steps of:

[00124] Reading the real présent car section and the shunting plan list data from the database, and loading the data into a System memory;

[00125] Specifically, the database is configured to persist the real présent car section and the shunting plan data; when the System is initialized and started up, the data in the database is loaded into the System memory, and the plan présent car section data is estimated and stored in the memory. Therefore, when the System is running, the System memory stores data of the real présent car section, the plan présent car section and the shunting plan list. The memory data is estimated and updated in real time according to user operation; and real présent car distribution and shunting plan data in the memory are updated and then synchronized to the database in real time.

[00126] In the System memory, according to the real présent car distribution section, shunting plans having point report unimplemented are estimated sequentially in the shunting plan list, to obtain and the plan présent car distribution section and store the same in the System memory.

[00127] In the real operation process, the shunting plan list in step SI is subjected to a continuous updating procedure, and a new shunting plan will be added while reporting point. FIG. 7 shows a flow chart of estimation of présent car distribution when building a new shunting plan, having steps of:

[00128] SI 1 : putting the newly built shunting plan at the end of the shunting plan list.

[00129] S12: estimating a new plan présent car section according to the original plan présent car section and the newly built shunting plan.

[00130] Exemplarily, as shown in FIG. 8, P_n+m+i is a newly added shunting plan, planTracksl is the original plan présent car section; and with respect to the original plan présent car section, a new plan présent car section planTracks2 may be estimated according to Pn+m+1·

[00131] S13: if estimation succeeds, updating the plan présent car section into a new plan présent car section; if estimation fails, not updating plan présent car distribution, and meanwhile, deleting the newly built shunting plan from the shunting plan list.

[00132] Specifically, a criterion for estimation success is that, the System retrieves the track according to the shunting plan content, to fmd out whether there are corresponding cars, and an order of the cars must be consistent with the order of cars designated in the shunting plan.

[00133] Further, in order to facilitate operation and save time according to the on-site real situation, the operator sometimes does not follow the shunting plan list step by step to carry out on-site operation; he/she may skip a certain shunting plan and execute a next shunting plan firstly, and then carry out the skipped shunting plan, that is, point report does not follow a strict order of the shunting plan list.

[00134] Exemplarily, when point report does not follow a strict order of the shunting plan list, the estimation steps are the same as above: firstly, estimating a new real présent car section according to the original real présent car section and the shunting plan having point report implemented, and then sequentially estimating the shunting plan having point report unimplemented, according to the new real présent car distribution section and following the shunting plan arrangement order in the shunting plan list, to obtain a new plan présent car distribution section.

[00135] Exemplarily, as shown in FIG. 10, the current real présent car distribution section is P_n, the shunting plan P_n+i is skipped, and point report is firstly performed on the shunting plan P_n+2. At this time, the original real présent car section is derived according to the shunting plan P_n+2, the shunting plan P_n+i is ignored, and a new real présent car section is obtained. Next, according to the new real présent car section and ail shunting plans having point report unimplemented in the shunting plan list, P_n+i, Pn+3 to P_n+m are sequentially estimated to the new plan présent car section according to the plan arrangement order; if the plan présent car section can be successfully estimated, then it is determined that point report succeeds, the real présent car distribution section is updated, and the plan présent car section is updated, otherwise, it is determined that point report fails.

[00136] Exemplarily, necessity of checking whether the shunting plan point report is correct by estimating the new plan présent car section according to the new real présent car section during shunting point report is illustrated. As shown in FIG. 11, on the current real présent car section, car No. 0001 is at IG, and the station dispatcher successively formulâtes 3 shunting plans Pi, P2 and P3 having point report unimplemented. The shunting plans are as follows:

[00137] (1) PI moves the car from IG to 2G.

[00138] (2) P2 moves the car from 2G back to 1 G.

[00139] (3) P3 moves the car from IG to 3G.

[00140] After estimating Pi, P2 and P3, on the plan présent car section, car No. 0001 is eventually moved to 3 G. Operation is performed on site according to the shunting plan to complété Pi. If the on-site staff correctly report point for Pi, at this time, on the new real présent car section, car No. 0001 is moved to 2G. The new real présent car section continues to estimate P2 and P3, and the plan présent car section may be estimated normally. In a case of operation errors of the on-site staff who fails to report point for Pi but reports point for P3 by mistake, the System firstly estimâtes that the new real section moves the car to 3G, and then sequentially estimâtes Pi and P2 following an order according to the new real section; when it is found that car No. 0001 does not exist on IG of the new real présent car section (the car is at 3G at this time) when estimating Pi, estimation is thence wrong, and the System judges that there is a point report error of the on-site operator, thereby effectively preventing the on-site personnel from misoperation.

[00141] The présent disclosure further discloses a présent car distribution estimating System; and the présent car distribution estimating System includes an access module and an estimating module. The access module is configured to read a real présent car distribution section and a shunting plan list. The estimating module is configured to sequentially dérivé from the real présent car distribution section according to a shunting plan in the shunting plan list, to obtain a new real présent car distribution section, and continue to dérivé from the new real présent car distribution section according to ail shunting plans having point report unimplemented, to obtain the plan présent car section.

[00142] Specifically, the access module includes a database and a system memory. The database is configured to save data of the real présent car distribution section and the shunting plan list, and may persist the data; when the system is initialized and started up, the data may be loaded from the database into the system memory; the system memory stores data of the real présent car distribution section and the shunting plan list; the estimating module estimâtes a plan distribution section according to the real présent car distribution section and the shunting plan list, and stores the same in the system memory. Due to a fast reading speed of the memory data, the data may be estimated and updated in real time according to user operation to ensure real-time performance of the system; when the data of the real présent car distribution section and the shunting plan in the memory is updated, it is synchronized to the database to ensure consistency between the system memory data and the database data. The estimating module is configured to estimate and update the real présent car distribution section according to the shunting plan data in the shunting plan list.

[00143] Specifically, the shunting plan list includes a shunting plan having point report unimplemented and a shunting plan having point report implemented.

[00144] When the newly added shunting plan needs to update the new plan présent car distribution section, the estimating module is configured to put the newly built shunting plan at the end of the shunting plan list; estimate a new plan présent car section according to the original plan présent car section and the newly built shunting plan; if estimation succeeds, update the plan présent car section to the new plan présent car section; if estimation fails, not update plan présent car distribution, and delete the newly built shunting plan from the shunting plan list.

[00145] The estimating a new real présent car distribution section while reporting point for the shunting plan specifically includes: setting a corresponding shunting plan in the shunting plan list to a point report State; estimating a new real présent car section according to the original real présent car section and the shunting plan having point report implemented;

estimating a plan présent car section according to the new real présent car section and ail shunting plans having point report unimplemented; if estimation of the plan présent car section fails, withdrawing the shunting plan point report State; if estimation of the plan présent car section succeeds, updating the real présent car section, and updating the plan présent car section; if estimation of the real présent car section fails, withdrawing the shunting plan point report State; and if estimation of the real présent car section succeeds, further estimating a new plan présent car distribution section.

[00146] When point is reported without following the order of the shunting plan list, spécifie dérivation steps include: estimating a new real présent car section according to the original real présent car section and the shunting plan having point report implemented; and then sequentially estimating, according to the new real présent car distribution section, the shunting plan having point report unimplemented, to obtain a new plan présent car distribution section.

[00147] Although the présent disclosure is explained in detail with reference to the foregoing embodiments, those ordinarily skilled in the art will readily appreciate that many modifications are possible in the foregoing respective embodiments, or équivalent substitutions are made for part of technical features; however, these modifications or substitutions are not intended to make the essences of the corresponding technical solutions départ from the spirit and the scope of the technical solutions of the respective embodiments of the présent disclosure.

Claims (17)

1. A présent car global management system, wherein, the présent car global management system comprises a client, an application aggregation service layer, an application kernel service layer and a database layer;

the client is configured to perform human-computer interaction on the présent car global management system;

the application kernel service layer is configured to implement kernel business logic and provide services to the outside through the application aggregation service layer;

the application aggregation service layer is configured to supply ail micro-services of the application kernel service layer, découplé the client, a kernel service layer and an extemal system;

the database layer communicates with the application kernel service layer, and provides data storage and data calling for the application kernel service layer.

2. The présent car global management system according to claim 1, wherein, the client is implemented based on a browser and adopts a WebUI framework.

3. The présent car global management system according to claim 2, wherein, the client comprises a présent car distribution interface, a shunting plan management interface, a technical operation chart, a receiving-departure table, a statistical analysis interface and a system maintenance interface.

4. The présent car global management system according to claim 1, wherein, the application aggregation service layer comprises a Web application aggregation service and an interface micro-service platform;

the Web application aggregation service is configured to provide a unified service API for ail PC terminais and APP terminais;

the interface micro-service platform is configured to abstract an interface portion of the extemal system into an individual interface layer, which is separated from a business layer.

5. The présent car global management system according to claim 4, wherein, the extemal System comprises a planning and dispatching information system, a depot information system, a car dispatching information system, a freight dispatching information system, a car number identification system and a construction management information system.

6. The présent car global management system according to claim 1, wherein, the application kemel service layer comprises a plurality of kemel services; the kemel services are relatively independent of each other; and the kemel services are loosely coupled with each other, communicating through RESTful and/or message middleware.

7. The présent car global management system according to claim 6, wherein, the plurality of kernel service layers comprise présent car service, traffic service, statistical decision analysis, authority management service, basic data management and log management.

8. The présent car global management system according to claim 6, wherein, the kemel service adopts a single program form based on a SpringBoot framework, independently publishes service interfaces to the outside, and acquires services of other single kemel programs in a service interface calling mode.

9. The présent car global management system according to claim 6, wherein, when a service scale is lower than a first set value and distributed deployment is not adopted, the kemel service layer manages a service interface by document convention; when the service scale is higher than the first set value, and the number of interfaces is greater than a second set value, the kemel service layer implements service automatic registration and discovery functions by adopting deployment service discovery to simplify calling between micro-services.

10. The présent car global management system according to claim 1, wherein, the application kemel service layer is connected with a common component; and the common component is configured to multiplex general functions among business components.

11. The présent car global management system according to claim 10, wherein, the common component comprises an authenticating and authorizing module, a user operation record, a general entity object, and a general tool class.

12. The présent car global management system according to claim 1, wherein, the présent car global management system adopts a B/S micro-service architecture of

SOA.

13. A présent car global management method, wherein, the présent car management method comprises steps of:

SI: using an application kemel service layer to implement kemel business logic, and provide services to the outside through an application aggregation service layer;

S2: using the application aggregation service layer to aggregate ail micro-services of the application kemel service layer, and découplé a client, a kemel service layer and an extemal system;

S3: using the database layer to communicate with the application kemel service layer, and provide data storage and data calling for the application kemel service layer;

S4: using the client to perform human-computer interaction on a présent car global management system.

14. The présent car global management method according to claim 13, wherein.

the kemel service as described in step SI adopts a single program form based on a SpringBoot framework, independently publishes service interfaces to the outside, and acquires services of other single kemel programs in a service interface calling mode.

the client as described in step S4 is implemented based on a browser and adopts a WebUI framework.

15. The présent car global management method according to claim 13, wherein, the application aggregation service layer as described in step S2 comprises a Web application aggregation service and an interface micro-service platform;

the Web application aggregation service is confïgured to provide a unified service APf for ail PC terminais and APP terminais;

the interface micro-service platform is confïgured to abstract an interface portion of the extemal system into an individual interface layer, which is separated from a business layer.

16. The présent car global management method according to claim 13, wherein, when a service scale is lower than a first set value and distributed deployment is not adopted, the kemel service layer manages a service interface by document convention; when the service scale is higher than the first set value, and the number of interfaces is greater than a second set value, the kemel service layer implements service automatic registration and discovery fonctions by adopting deployment service discovery to simplify calling between micro-services.

17. The présent car global management method according to claim 13, wherein,

Client

Statistical analysis interface

Shunting plan management interface (Receiving-departure _ table

DRAWINGS

External System

Car dispatching information \ | svstem /

Freight dispatching t I information System I I

Construction management information System

Interface micro-service platform

Car number identification \ ¹

System f |

| Depot information

Common corn

Authenticating and authorizing module

Technical operation chart

System maintenance interface i Planning and dispatching ' information System

Web application aggregation ¹ service

/ Application aggregation service layer

/Application kernel service layer

Présent car service

Traffic service

Statistical decision analysis

User operation record

Authority * management service

Basic data management

Log management

General entity object

Database layer

FIG. 1

General tool class

FIG. 2

Car data | Car information hash table î

LJ

I*

Departure Receiving

TI (^In-transit car data module^s

Train marshalling | Train marshalliÎ^ dataset j

FIG. 3

FIG. 4

Shunting plan A Shunting New shunting plan B plan

Serial No. Train No. Type Shunting plan Formulator Yardmaster Date » 1 Whole station Shunting pian A 2021-05-19

2 Marshalling Shunting plan A 2021-0549

3 Break-up Shunling plan A 2021*05*19

No. 1 Shunting whole station a © K a © ©- e © © * 0 o

Serial No. Yard Track Method Direction Number of cars Plan start time Plan end time Real start time Real end time Remai rang

Yard 1 East ¢4

2 Yard l ί -ΠΑ Easl G

FIG. 5

FIG. 6

SI 1 : putting the newly built shunting plan at the end of the shunting plan list.

S12: estimating a new plan présent car section according to the original plan présent car section and the newly built shunting plan.

S13 : if estimation succeeds, updating the plan présent car section into a new [ plan présent car section; if estimation fails, not updating plan présent car distribution, and meanwhile, deleting the newly built shunting plan from the shunting plan list.