Railway single vehicle station scheduling optimization method and system

Abstract

The present application relates to the field of railway transportation dispatch automation and intelligent optimization, in particular to a railway single station dispatch optimization method and system. The method comprises: obtaining the attributes and operation data of trains and tracks; screening candidate tracks based on physical compatibility and business rules; constructing binary variables representing track allocation, operation start time variables and binary variables representing track operation sequence; establishing a mixed integer linear programming model with the goal of minimizing total in-station time, integrating resource capacity, time-space mutual exclusion, direction rules, special restrictions and other constraints; using a rolling horizon optimization strategy to decompose and solve the model, and outputting the final allocation track and operation schedule for each train. The present application converts complex scheduling problems into computable optimization models, realizes automatic and global optimization generation of scheduling schemes, ensures that the schemes meet the requirements of safety, efficiency and all operation rules, and significantly improves the efficiency and intelligence level of station operations.

Description

Technical Field

[0001] This invention relates to the field of railway transportation scheduling automation and intelligent optimization technology, specifically to a method and system for optimizing scheduling within a single railway station. Background Technology

[0002] As a crucial node in the railway network, one of the core functions of railway stations is the efficient technical operation and scheduling of arriving and departing trains. Traditional station scheduling operations heavily rely on the personal experience of dispatchers. Dispatchers must simultaneously consider train physical attributes (such as length and weight), direction of travel, track resource capacity (such as effective length and load-bearing capacity), various safety regulations and operational rules (such as track opening windows and directional isolation), and real-time operational status, mentally planning the track occupancy and operation sequence for each train. This method exposes many inherent flaws when dealing with large marshalling yards or section stations with dense traffic and complex train types. First, manual layout is difficult to optimize globally, often only achieving local feasibility or empirical optimality, leading to uneven track utilization and longer train dwell times, affecting station throughput and vehicle turnaround efficiency. Second, the human brain is prone to errors or omissions when processing numerous multi-dimensional constraints simultaneously, potentially resulting in safety hazards such as insufficient track length, excessive load-bearing capacity, or operation time conflicts, and the stability of the solution is poor. Furthermore, when operational plans are temporarily adjusted or delays occur, manually re-compiling scheduling plans is time-consuming, labor-intensive, and slow to respond, making dynamic adjustments difficult. Although some existing automated auxiliary systems exist based on fixed rules, first-come-first-served, or simple priority ranking, these methods are essentially heuristic or rule-driven local decision-making processes. They cannot seek optimal solutions for time or resource utilization from a global perspective while satisfying all complex constraints, resulting in limited intelligence and underutilized optimization potential. Therefore, the railway transportation sector urgently needs a technical solution that can automatically, quickly, and globally optimize train scheduling schemes within stations while ensuring absolute compliance with all safety and operational rules.

[0003] Therefore, the existing technology still needs further development. Summary of the Invention

[0004] The purpose of this invention is to overcome the above-mentioned technical deficiencies and provide a method and system for optimizing scheduling within a single railway station, so as to solve the problems existing in the prior art.

[0005] To achieve the above-mentioned technical objectives, according to a first aspect of the present invention, the present invention provides a method for optimizing scheduling within a single railway station, comprising: S1. Obtain the physical attribute data and dynamic operation data of the train to be dispatched, as well as the resource attribute data of each track in the station; S2. Based on the physical attribute data and resource attribute data, select a set of physically compatible candidate tracks for each train; S3. Construct allocation variables for deciding train track allocation, and order variables for deciding the order of train operations within the same track; S4. Based on the allocation variables, order variables, dynamic operation data and preset operation time, construct a mixed integer linear programming (MILP) model with the objective of minimizing the total time spent by trains at the station or the average dwell time. The model includes order constraints to ensure that the operation time windows of trains on the same track do not overlap. S5. Solve the MILP model and output the final track allocation and operation schedule for each train.

[0006] Specifically, in step S2, the physical attribute data includes at least the train length and the total train weight, and the resource attribute data includes at least the effective track length and the maximum track load capacity; physical compatibility means that the train length is not greater than the effective track length and the total train weight is not greater than the maximum track load capacity.

[0007] Specifically, step S2 further includes: Based on preset business rules, the candidate track set is further filtered. The business rules include matching rules between train operation direction and track number, or binding rules between specific train type and designated track.

[0008] Specifically, the sequence constraint in step S4 is implemented by introducing a large constant M and using the sequence variable for logical control, so as to ensure that for any two trains assigned to the same track, the end time of one train's operation is no later than the start time of the other train's operation.

[0009] Specifically, the value of the large constant M is set to be greater than the sum of the possible job times.

[0010] Specifically, the MILP model constructed in step S4 also includes external operational constraints, which include at least one of the following: sunroof time and section speed limit.

[0011] Specifically, step S5 uses a rolling time-domain optimization strategy to solve the problem. All trains to be scheduled are divided into consecutive batches according to their arrival time. The optimization solution is performed on each batch of trains in turn, and the release time of the track resources occupied by the trains in the solved batches is used as a known condition for the optimization of subsequent batches.

[0012] Specifically, the work schedule output in step S5 includes the start and end times of the work for each train on the final assigned track.

[0013] Specifically, the method further includes step S6: The final track allocation and work schedule will be visualized in the form of a Gantt chart.

[0014] According to a second aspect of the present invention, a railway single-station scheduling optimization system is provided, comprising: The data acquisition and processing module is used to execute steps S1 and S2, acquire and process train and track data, and generate a candidate track set; The model building module is used to execute steps S3 and S4 to build the mixed integer linear programming (MILP) model. The optimization solution module is used to execute step S5 and solve the MILP model; The output module is used to output and display the obtained scheduling scheme.

[0015] Beneficial effects: Compared with existing technologies, the railway single-station scheduling optimization method and system provided by this invention realizes a fundamental shift from relying on manual experience to model-based automatic optimization, bringing significant technological progress and many beneficial effects.

[0016] First, it automates and optimizes scheduling decisions. By precisely modeling the scheduling problem as a mixed-integer linear programming model with the objective of minimizing total time spent at the station, and using a mathematical programming solver to solve it, this invention can automatically output a mathematically globally optimal or near-optimal scheduling scheme. This fundamentally overcomes the shortcomings of manual scheduling, such as strong subjectivity and low optimization level, and significantly improves station operation efficiency and vehicle turnaround speed.

[0017] Secondly, it ensures the absolute safety and compliance of the scheduling scheme. This invention creatively encodes complex physical constraints (length, load-bearing capacity), operational rules (direction matching, special track restrictions, track openings), and business logic (job type matching) into hard constraints or soft rules in a mathematical model. The optimization solver searches only in the solution space that fully satisfies all these constraints, thus guaranteeing that any generated scheme is 100% compliant with safety procedures and operational requirements, completely eliminating compliance oversights that may occur in manual scheduling.

[0018] Third, it possesses a powerful ability to handle complex constraints and make real-time dynamic adjustments. The rolling time-domain optimization strategy it adopts decomposes the large-scale scheduling problem into continuous time batches for sequential solution. This allows the system to handle large-scale traffic flows while naturally incorporating the latest train arrival information and resource status through batch rolling. This enables rapid response and dynamic rescheduling to unplanned disturbances (such as delays), greatly enhancing the robustness and practicality of the scheduling system.

[0019] Fourth, it enhances the transparency of the scheduling process and the operability of the results. The system's final output includes not only a list of instructions but also a clear track-time Gantt chart, visualizing the complex spatiotemporal arrangements. This allows schedulers to intuitively understand and verify the plans, facilitating human-machine collaboration and instruction issuance, and improving the overall controllability and executability of the operation.

[0020] In summary, this invention, through intelligent modeling and optimization, minimizes train dwell time at stations while ensuring safety and adhering to regulations, thereby improving the overall operational efficiency of stations. It is a core technology driving railway station scheduling towards intelligence and precision. Attached Figure Description

[0021] Figure 1 This is a flowchart illustrating the railway single-station scheduling optimization method provided in a specific embodiment of the present invention. Detailed Implementation

[0022] To enable those skilled in the art to better understand the technical solutions of the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Based on the embodiments in this application, other similar embodiments obtained by those skilled in the art without creative effort should all fall within the scope of protection of this application. Furthermore, directional terms mentioned in the following embodiments, such as "up," "down," "left," and "right," are only for reference to the directions in the accompanying drawings; therefore, the directional terms used are for illustrative purposes and not for limiting the invention.

[0023] The present invention will be further described below with reference to the accompanying drawings and preferred embodiments.

[0024] Please see Figure 1 This invention provides a method for optimizing scheduling within a single railway station, comprising: S1. Obtain the physical attribute data and dynamic operation data of the train to be dispatched, as well as the resource attribute data of each track within the station.

[0025] It should be further explained that the specific implementation process of step S1 above is as follows: two types of basic data are collected from the railway information system or sensor network. The first type is train data, including its static physical parameters and dynamic operating parameters. Static physical parameters include at least the train length. (in (For train index), total train weight Train type (e.g., "Pu-Lie", "10,000-ton", "railcar"); dynamic operating parameters include the train's estimated arrival time. (in For train The first category is arrival time at the station. The second category is station track data, including the arrival time of each track. (in The resource attribute parameters for the stock index must include at least the effective length of the stock. Maximum load-bearing capacity of the stock track Stock market types (For example, "arrival / departure lines", "main line", and "dedicated railcar line"). These data form the basic inputs for subsequent optimization decisions.

[0026] S2. Based on the physical attribute data and resource attribute data, select a set of physically compatible candidate tracks for each train.

[0027] It should be further explained that the specific filtering logic of step S2 above is as follows: for each train Traversing all stock channels Check physical compatibility one by one. Physical compatibility must meet two hard conditions simultaneously: (1) The length of the train shall not exceed the effective length of the track, i.e. ; (2) The total weight of the train shall not exceed the maximum load-bearing capacity of the track, i.e. Only stocks that simultaneously meet both of these conditions... Only then will it be included in the train. Candidate Stock Channel Set This multi-dimensional joint restriction eliminates physically infeasible scheduling schemes at the source, such as preventing overly long trains from entering tracks with insufficient effective length, or overweight trains from entering tracks with insufficient load-bearing capacity.

[0028] S3. Construct allocation variables for deciding train track allocation, and order variables for deciding the order of train operations within the same track.

[0029] It should be further explained that in step S3 above, two types of core binary decision variables are defined. The first type is the assignment variable. When the train Assigned to the stock track The value is 1 if the condition is met, and 0 otherwise. The second type is ordinal variables. When the train and train Assigned to the same track And the train The work is arranged on the train The value is 1 if it is true, otherwise it is 0.

[0030] S4. Based on the allocation variables, order variables, dynamic operation data and preset operation time, construct a mixed integer linear programming (MILP) model with the objective of minimizing the total time spent by trains at the station or the average dwell time. This model includes order constraints to ensure that the operation time windows of trains on the same track do not overlap.

[0031] It should be further explained that in step S4 above, the core objective function of the constructed MILP model is to minimize the total dwell time of all trains at the station, i.e. ,in For train In the stock market The start time of the task (a continuous decision variable). For train In the stock market The preset operation processing time (a known parameter) is specified. The model must include the following constraints: each train is assigned to one and only one track, i.e. The train's operation must begin later than its arrival time, that is... And most importantly, the mutual exclusion constraint of the order of operations on the same track.

[0032] The sequence constraint in step S4 above is achieved by introducing a large constant. (Big-M) technology is used to ensure that time windows do not overlap. Its specific mathematical expression is: for any two trains... and ( ), and any stock track The following two sets of constraints must be met: 1. 2. in, This should be a sufficiently large constant, its value greater than the sum of all possible operation times within the entire scheduling cycle. When the train... and Not simultaneously assigned to a track Time (i.e.) ), constraint conditions due to large constants The automatic relaxation fails due to the presence of both trains; when both trains are assigned to the track. When, ordinal variables This will determine which time sequence constraint to enforce, thus achieving "either..." exist Complete before, or exist The logic of "completing before".

[0033] S5. Solve the MILP model and output the final track allocation and operation schedule for each train.

[0034] It should be further noted that in step S5 above, solving the MILP model can be performed using a commercial or open-source mixed integer programming solver (such as CPLEX, Gurobi, or the CBC solver built into the PuLP library). The solver output includes all decision variables. , and The optimal value can be used to generate detailed scheduling instructions, specifying the details for each train. The allocation of the stock lane (satisfy ) and its start time and end time .

[0035] Understandably, this method transforms the complex station scheduling problem into a computable optimization problem by establishing a unified mathematical model. Compared to manual scheduling, it can simultaneously process massive amounts of train and track characteristic information while strictly meeting physical and safety constraints. This systematically avoids station congestion and track allocation conflicts, significantly improves station operational efficiency and resource utilization, and ultimately minimizes the average train dwell time at the station.

[0036] Specifically, in step S2, the physical attribute data includes at least the train length and the total train weight, and the resource attribute data includes at least the effective track length and the maximum track load capacity; physical compatibility means that the train length is not greater than the effective track length and the total train weight is not greater than the maximum track load capacity.

[0037] It should be further noted that physical compatibility checks are a prerequisite for safe dispatching. Train length With the effective length of the track The comparison ensured that the train could be safely stopped on the track without exceeding the warning mark. Total train weight Maximum load-bearing capacity of the stock track The comparison ensures that the track structure can withstand train loads, guaranteeing infrastructure safety. These two checks constitute the most basic "track-train" compatibility filter.

[0038] Understandably, by implementing this hard physical constraint check, safety hazards such as "long trains on short tracks" or "heavy trains on light tracks" can be eliminated from the source of decision-making, ensuring that any scheduling scheme generated is feasible and safe at the physical level. This is a key link that is easily overlooked or prone to errors in manual scheduling.

[0039] Specifically, step S2 further includes: further filtering the candidate track set based on preset business rules, wherein the business rules include matching rules between train operation direction and track number, or binding rules between specific train type and designated track.

[0040] It should be further noted that after meeting basic physical compatibility requirements, a secondary screening is necessary based on station operation rules. Common business rules include: 1. Direction matching rules: For example, it is stipulated that up-line trains can only access even-numbered tracks (such as 6, 8, 10, ...), and down-line trains can only access odd-numbered tracks (such as 3, 5, 7, ...). Main lines (such as "One" tracks and "Four" tracks) may only allow through operations or restrict stopping time.

[0041] 2. Type Binding Rules: For example, specific types of work vehicles (such as "railcars") must be assigned to a specific dedicated track (such as track 22). These rules are reflected in step S2 by the selection of candidate track sets. Further screening is needed for the trains. Check its direction attribute or type property If the stock market Functional attributes Or direction attribute If it does not meet the requirements of the train, even if it is physically compatible, the track will be... from Excluded from the list. This logic can be achieved by adding the following constraint to the optimization model: For all trains that do not conform to the business rules... With Stock Market The combination of these directly forces the assignment of variables. .

[0042] Understandably, the introduction of business rule filtering enables the optimization model to closely match the actual operation scenario, ensuring that the generated scheduling scheme is not only theoretically optimal, but also fully complies with the station's existing train operation regulations and special operation requirements, greatly improving the availability and executability of the scheme.

[0043] Specifically, the sequence constraint in step S4 is implemented by introducing a large constant M and using the sequence variable for logical control, so as to ensure that for any two trains assigned to the same track, the end time of one train's operation is no later than the start time of the other train's operation.

[0044] It should be further explained that the order constraint is the core of this method for resolving spatiotemporal conflicts. Its basic principle is to utilize binary order variables. As a "switch", it is used in conjunction with a large constant. In mathematical models, this precisely expresses the logic of "mutual exclusion." Specifically: when When, constraint 1: Being activated means the train The end time must be earlier than the train's. The start time; at the same time, constraint 2 is due to The term becomes ineffective due to relaxation. Conversely, when... When constraint 2 is activated, constraint 1 is relaxed. In this way, the model enforces a strict sequential relationship between the operation time windows of any two trains on the same track, avoiding time overlap.

[0045] Understandably, this mechanism enables the serialized planning of the use of key resources (tracks) within the station, providing a mathematical guarantee for preventing operational conflicts and ensuring the safety and feasibility of scheduling schemes. It transforms the dispatcher's empirical rule of "not occupying the same track simultaneously" into a mathematical inequality that can be rigorously solved by a computer, which is key to achieving automated intelligent scheduling.

[0046] Specifically, the value of the large constant M is set to be greater than the sum of the possible job times.

[0047] It should be further explained that large constants The value of must be large enough to ensure that the inequality always holds when the order constraints need to be "closed" (i.e., relaxed), without affecting the validity of the solution. A reliable and simple setting method is to let Greater than the maximum possible sum of all train operation times within the entire planning area. For example, if there are... The maximum operating time for each train is Then you can set ,in This is a sufficiently large positive margin. In rolling time-domain optimization, It can be dynamically set based on the total operation time of trains in the current batch, such as... This setup ensures the rigor of the mathematical model.

[0048] Understandably, reasonable settings The value of is a prerequisite for the correct application of the Big-M method. A value that is too small may cause constraints to take effect unexpectedly, incorrectly excluding feasible solutions; a value that is too large, while not affecting logical correctness, may increase the numerical difficulty of the solver. Using an estimation method based on total operation time can achieve a good balance between ensuring logical correctness and maintaining numerical stability.

[0049] Specifically, the MILP model constructed in step S4 also includes external operational constraints, which include at least one of the following: sunroof time and section speed limit.

[0050] It should be further noted that, to improve the overall feasibility of the scheduling plan, the model needs to incorporate operational constraints from outside the station. For example: 1. Skylight Time Constraint: During the specified skylight time period Within certain tracks or sections of the line, certain types of work are prohibited. This can be achieved by regulating the relevant trains. Homework start time or end time This can be achieved by adding inequality constraints, such as requiring the job to finish before the start of the window or start after the end of the window.

[0051] 2. Impact of section speed limits: Section speed limits will affect the actual arrival time of trains. The section speed limit function can be used as input to correct the train's estimated arrival time through simulation calculations or pre-estimation. This indirectly affects scheduling decisions. These external constraints are integrated into the MILP model as boundary conditions, making the optimization results more consistent with the actual road network operation.

[0052] Understandably, by integrating external operational constraints, station-level scheduling decisions are no longer isolated but are coordinated with macro-level scheduling such as the entire line's timetable and maintenance plans. This helps reduce the risk of conflicts between station-level optimization schemes and actual external conditions, and improves the feasibility and robustness of scheduling schemes at the entire railway network level.

[0053] Specifically, step S5 uses a rolling time-domain optimization strategy to solve the problem. All trains to be scheduled are divided into consecutive batches according to their arrival time. The optimization solution is performed on each batch of trains in turn, and the release time of the track resources occupied by the trains in the solved batches is used as a known condition for the optimization of subsequent batches.

[0054] It should be further noted that when the number of trains scheduled at one time is too large (e.g., more than 60 trains), directly solving the global MILP model may be too computationally complex to complete within an acceptable timeframe. Therefore, a rolling time-domain optimization strategy can be adopted. The specific steps are as follows: 1. Arrange all trains according to their scheduled arrival times. Sort in ascending order.

[0055] 2. Set a fixed time window or a fixed batch size for the number of trains, for example, optimize the scheduling of 15 future trains each time.

[0056] 3. Starting with the first vehicle, take the first batch (e.g., vehicles 1-15) to form the current optimization problem.

[0057] 4. Solve the MILP model for the current batch to obtain the track allocation and precise start and end times for each train in the batch.

[0058] 5. Update each track based on the solution results. Resource release time This refers to the end time of the last train scheduled to operate on that track.

[0059] 6. As known parameters, these are incorporated into the optimization model for the next batch (e.g., cars 16-30). The start time of the operation for the next batch of trains... Not only later than its own arrival time It must also be later than the current allocation of the track. This is achieved by adding constraints. accomplish.

[0060] 7. Repeat steps 4-6 until all batches are scheduled. Batch size is an adjustable parameter. Experience shows that when a single solution is too large and causes timeouts (e.g., exceeding 16 hours), a rolling strategy with a batch size of 15 can obtain high-quality sub-optimal solutions within approximately 10 minutes, balancing solution efficiency and global optimization performance.

[0061] Understandably, the rolling time-domain optimization strategy is an effective engineering approach for handling large-scale, complex scheduling problems. It decomposes a global problem that is difficult to solve directly into a series of moderately sized, quickly solvable subproblems, and approximates the global optimization objective through iterative advancement and state propagation. This significantly improves the algorithm's practicality and timeliness in real-world large-scale scenarios.

[0062] Specifically, the work schedule output in step S5 includes the start and end times of the work for each train on the final assigned track.

[0063] It should be further noted that the solver's direct output is the numerical value of each decision variable. This needs to be converted into human-readable and executable scheduling instructions. The output timetable should at least include the following fields: Train ID, assigned track ID, planned start time, planned processing duration, and planned end time. Additionally, the station dwell time for each train (EndTime - ArrivalTime) can be calculated and output. For example, an output entry could be: Train "TrainC70(Pu)02", assigned to track "20", arrival time 15, start time 21:80, processing duration 26:70, end time 48:50, total time 33:50.

[0064] Understandably, a clear and accurate timetable is the direct embodiment of the scheduling plan. It provides station duty officers, shunting operators, and others with clear operational instructions, including train route arrangements, arrival and departure track occupancy plans, and loading and unloading operation start and end times, and is a key output for realizing the automatic compilation and issuance of station operation plans.

[0065] Specifically, the method further includes step S6: visualizing the output final allocation of tracks and work schedule in the form of a Gantt chart.

[0066] It should be further explained that step S6 is the visualization stage of the results. Using a plotting library (such as matplotlib in Python), a horizontal bar chart (Gantt chart) is created, with time as the horizontal axis and track number as the vertical axis, depicting the work period (from start time to end time) of each train on its assigned track. Different trains can be distinguished by different colors. Train IDs can be labeled inside or above the bars. Through this chart, dispatchers can intuitively observe: the changes in track resource occupancy over time, the work sequence of different trains on the track, the existence of time gaps, and the overall picture of the dispatching plan. This greatly facilitates manual verification and interactive adjustments.

[0067] Understandably, visualization transforms abstract numerical results into intuitive graphical interfaces, lowering the barrier to understanding scheduling schemes and making it easier for non-technical personnel (such as managers) to quickly grasp the overall situation. It also facilitates manual fine-tuning and confirmation based on automatically generated schemes, making it an important part of human-machine collaborative decision-making.

[0068] The present invention will be described in detail below with reference to preferred embodiments. Those skilled in the art should understand that the embodiments described are for illustrative purposes only and do not constitute a limitation thereof.

[0069] Example 1: Implementation of the Basic Method This example uses a simulated station scenario to illustrate the implementation process of this method in detail. The station has 21 tracks and requires the scheduling of 31 trains of different types.

[0070] First, perform step S1, data acquisition. Train data is read from the simulated "trains.csv" file, and track data is read from the "tracks.csv" file. Train attributes include train ID (train_id), length, weight, arrival time, processing time, assignment type (e.g., "regular train", "10,000 tons"), and direction (e.g., "up", "down"). Track attributes include track ID (track_id), length, weight limit, and functional description (assignment). Further, step S2 is executed: physical compatibility and rule filtering. The system traverses all tracks for each train. For example, for a train of length... meters, weight The "TrainC80 (30,000 tons)" system checks the length of each track. and load-bearing capacity Meanwhile, according to the operational rules, this train is a downhill through train and may be restricted to using only track "one" on the main line (marked as infinitely long and infinitely heavy for through operations). Therefore, only track "one" is included in its candidate set. For a "railcar" (Train Railcar 03), according to the special rules, its candidate set is locked to contain only track "22".

[0071] Further, steps S3 and S4 are executed to construct the model. The system defines allocation variables for 31 trains and 21 tracks. and ordinal variables The objective function is set to minimize the total dwell time: The added constraints include: each train must select one track. Start time not earlier than arrival time constraint ; Length and weight compatibility constraints (if or ,but ); Direction and track matching constraints (e.g., only allowing upward trains to...) when Special vehicle binding constraints (e.g., for trains with "Rail-car" in their ID, only...) ), and Big-M sequence constraints to prevent time conflicts on the same track. Among these, the large constant... It was set to a value much larger than the planned range, for example .

[0072] Further, step S5 is executed: model solving and output. A mixed-integer linear programming solver (such as the CBC solver called through the PuLP library) is invoked to solve the model. After calculation, the optimal solution is obtained, and the objective function value (total weighted time at the station) is 1865.90. Detailed scheduling plans for each train are output, for example: "Train C70 (regular train) 02" arrives at 15:00, is assigned to track 20, starts operation at 21:80, operation duration is 26:70, and total time is 33:50. Step S6: result visualization. The system automatically generates a Gantt chart, with time on the horizontal axis and the 21 tracks on the vertical axis. The chart shows that the operation time bars (bars) for multiple trains on the same track (e.g., track 20) ​​are arranged sequentially without overlap, visually verifying conflict-free scheduling.

[0073] Example 2: Implementation of Rolling Time-Domain Optimization When the scheduling scale increases, for example, the number of trains increases to 64, a one-time solution may encounter computational bottlenecks. This example demonstrates the implementation details of rolling time-domain optimization. Specifically, the batch size is set to 15. All 64 trains are sorted according to their arrival times. Sort.

[0074] First, a MILP model is constructed and solved for the first batch (vehicles 1 to 15) to obtain the scheduling scheme for these 15 vehicles. The details of each track are recorded. The end time of the last vehicle scheduled to board is used as the "release time" for the next batch on that track. .

[0075] Then, the second batch (cars 16 to 30) is processed. When building the model for this batch, in addition to the usual constraints, for each train within the batch... and each track Add constraints: This constraint ensures that if train batch 2... Assigned to the stock track Its start time must be later than the release time of the previous batch on that track. This is also used here for logic relaxation, when the train Not assigned to a track hour( This constraint becomes invalid. Next, the second batch of models is solved, and the values ​​for each track are updated. Repeat this process until all batches have been scheduled.

[0076] Understandably, in this embodiment, by adopting a rolling strategy, the scheduling scheme for 64 vehicles can be calculated in a relatively short time, avoiding the problem of "not being completed for 16 hours" that may occur with a single solution. A batch size of 15 is an empirically optimal value, balancing the difficulty of solving subproblems (moderate scale, fast solution) with the utilization of global information (optimizing the interaction of 15 vehicles within a batch). The reason for choosing this value is that it is usually less than the solver's processing capacity threshold, ensuring that a single batch is solved within tens of seconds to several minutes; at the same time, it is large enough to consider the complex interactions of multiple workshops (such as competing for the same track) within a window, avoiding short-sighted decisions due to an excessively small window.

[0077] It should be further explained that the following provides a specific code example for implementing the core optimization process of this invention. This code is a specific, runnable software embodiment of the railway single-station scheduling optimization method described in this invention. It uses the Python programming language and utilizes the PuLP library to construct a mixed-integer linear programming model, calling the CBC solver for optimization calculations. The code fully implements the entire process from raw data reading, data preprocessing, model construction and solving based on a rolling time-domain strategy, result parsing, to visualization. The core algorithm idea is to model the complex station scheduling problem as an optimization problem with the objective of minimizing the total station time, and automatically solve it using mathematical programming methods. The code is mainly divided into the following ten sections: 1. First paragraph: Library import and environment initialization import pulp import pandas as pd import matplotlib.pyplot as plt import random import os import numpy as np # Set random seed random.seed(0) This code snippet first imports the necessary Python libraries. `pulse` is the core library for building and solving linear programming and mixed-integer linear programming models. `pandas` is used for efficiently reading and processing tabular data (such as CSV or Excel files). `matplotlib.pyplot` is used to visualize the results by plotting Gantt charts at the end. `random`, `os`, and `numpy` are auxiliary libraries used to set the random seed, check file paths, and perform numerical calculations, respectively. The `random.seed(0)` statement is used to fix the seed of the random number generator, ensuring that any operation involving randomness (if present) yields consistent results each time the code runs. This enhances the reproducibility of the code and is crucial for debugging and experimentation.

[0078] 2. Second paragraph: General data reading function def read_data(file): if not os.path.exists(file): raise FileNotFoundError(f\"Missing required file: {file}\") if file.endswith(".xlsx"): return pd.read_excel(file) else: df = pd.read_csv(file) # 1. Remove leading and trailing spaces in column names df.columns = df.columns.str.strip() # 2. Remove leading and trailing spaces in all string data df = df.apply(lambda x: x.str.strip() if x.dtype == "object" else x) return df This function read_data encapsulates the data reading logic, improving the robustness and maintainability of the code. It first checks if the specified file exists, and if not, throws a clear error. Then, according to the file extension (.xlsx or.csv), it uses the corresponding functions in pandas to read the data. For CSV files, it performs two key data cleaning operations: removing the spaces in the column names (headers), and removing the leading and trailing spaces in each data value of all string-type columns. These operations can effectively avoid subsequent data matching failures caused by inadvertent spaces in the source data file (e.g., misjudging " Pu Lie " as a different string from "Pu Lie").

[0079] 3. Third paragraph: Loading and preliminary processing of train and track data train_file = "trains.csv" track_file = "tracks.csv" print(f"Loading data from {train_file} and {track_file}...") train_df = read_data(train_file) track_df = read_data(track_file) The code specifies the trains.csv file storing train information and the tracks.csv file storing track information, and calls the above read_data function to load them as pandas DataFrame objects train_df and track_df. This is the data basis for all optimization calculations.

[0080] train_df[\'length\'] = pd.to_numeric(train_df[\'length\'], errors=\'coerce\').fillna(0.0) track_df[\'length\'] = pd.to_numeric(track_df[\'length\'], errors=\'coerce\').fillna(0.0) Because numeric columns read from a file might be misinterpreted as strings, this section forces the `length` column in the DataFrame to be converted to a numeric type. The `pd.to_numeric` function sets invalid values ​​to NaN (Not a Number) when the conversion fails (errors='coerce'), and the subsequent `.fillna(0.0)` replaces all NaN values ​​with 0.0. This step is crucial, ensuring that subsequent numeric comparisons (such as length checks) can proceed correctly and preventing program crashes due to incorrect data types.

[0081] Trains = train_df[\"train_id\"].astype(str).tolist() Tracks = track_df[\"track_id\"].astype(str).tolist() These two lines of code extract the unique identifier list Trains for all trains and the unique identifier list Tracks for all tracks from the DataFrame, and explicitly convert them into string types, which serve as the core index set for all subsequent modeling and looping operations.

[0082] 4. Fourth paragraph: Establishing a train parameter mapping dictionary lengths = dict(zip(train_df[\"train_id\"].astype(str), train_df[\"length\"])) alpha = dict(zip(train_df[\"train_id\"].astype(str), train_df["arrival"])) Two dictionaries (key-value mappings) are created here for easy subsequent lookups. The `lengths` dictionary has train IDs as keys and train lengths as values. The `alpha` dictionary has train IDs as keys and train estimated arrival times as values. `alpha` is used as the arrival time parameter for each train in the optimization model.

[0083] if \'assignment\' in train_df.columns: else: raise ValueError(\"Column \'assignment\' missing in trains.csv\") This logic is used to retrieve the train's "operation type" or "demand" information (e.g., "regular train," "10,000 tons"). It first checks if a column named `assignment` exists in the data table. If it exists, it cleans the data and creates a `train_assignments` mapping dictionary. If it doesn't exist, it tries using the `weight` column as an alternative. If neither exists, it throws an error, as this is necessary information for implementing vehicle-track function matching constraints.

[0084] ptime_col = next((col for col in train_df.columns if \"time\" incol.lower() or \"duration\" in col.lower()), None) if ptime_col: else: raise ValueError(\"Could not find a processing time column intrains.csv\") This section intelligently searches the train data table for columns representing "processing time" or "operation duration". It iterates through all column names, looking for columns containing the keywords "time" or "duration" (case-insensitive). Once found, its data is converted to numeric type, and a two-level dictionary p[(t, r)] is created. The code assigns the same processing time value, time_val, to every combination of train t and track r. This means that in the current model, it is assumed that the technical operation time of a train is independent of the specific track assigned. This is a simplification, but the model structure supports expansion to track-dependent time p_{t, r}.

[0085] dir_col = next((col for col in train_df.columns if \"direction\" incol.lower()), None) if dir_col: else: This code looks up the train direction column (e.g., "direction") and builds a `train_directions` mapping dictionary. If the direction column is not found, it sets the direction of all trains to "unknown" and skips the direction constraint in subsequent logic. This provides flexibility, allowing for direction-independent optimization even when direction data is lacking.

[0086] 5. Fifth paragraph: Establishing a stock path parameter mapping dictionary track_length = dict(zip(track_df[\"track_id\"].astype(str),track_df[\"length\"])) if \'assignment\' in track_df.columns: else: raise ValueError(\"Column \'assignment\' missing in tracks.csv\") Similar to train data, a track length dictionary `track_length` and a track function description dictionary `track_assignments` are established here. The track function description (e.g., "general train, 10,000 tons") is a key field used to match with train demand to determine whether the track can meet the operation type requirements of a particular train.

[0087] 6. Paragraph Six: Preparatory Work for Optimizing the Main Loop in the Scrolling Time Domain Trains.sort(key=lambda x: alpha[x]) BATCH_SIZE = 15 track_free_time = {r: 0.0 for r in Tracks} final_results = [] total_objective_value = 0.0 Before optimization begins, the code first sorts all trains in ascending order according to their expected arrival time alpha[t] to ensure that the optimization proceeds chronologically. The batch size BATCH_SIZE for the rolling time domain is set to 15, an empirically preferred value used to balance the complexity of a single solution with the global optimization effect. A dictionary track_free_time is initialized to record the earliest time that each track r can be used by a new train, with initial values ​​of 0.0 for each track. The final_results list is used to accumulate the final scheduling results for all batches, and total_objective_value is used to accumulate the objective function value.

[0088] 7. Seventh paragraph: Rolling time-domain batch loop and problem definition for i in range(0, len(Trains), BATCH_SIZE): current_batch = Trains[i: i + BATCH_SIZE] prob = pulp.LpProblem(f\"Batch_{i}\", pulp.LpMinimize) This for loop implements rolling time-domain optimization. It takes a sublist containing BATCH_SIZE trains from the sorted train list Trains and uses it as the current batch (current_batch). For each batch, a new PuLP linear programming problem prob is created with the objective LpMinimize.

[0089] x = pulp.LpVariable.dicts(\"x\", (current_batch, Tracks), cat=\"Binary\") s = pulp.LpVariable.dicts(\"s\", current_batch, lowBound=0) y = {} for t1 in current_batch: for t2 in current_batch: if t1 == t2: continue for r in Tracks: y[(t1, t2, r)] = pulp.LpVariable(f\"y_{t1}_{t2}_{r}\", cat=\"Binary\") In each batch of questions, three types of decision variables are defined: x[t][r]: A binary variable. It indicates whether train t is assigned to track r. A value of 1 indicates yes, and 0 indicates no.

[0090] s[t]: A continuous variable with a lower bound of 0. It represents the time when train t begins operation on the assigned track.

[0091] y[(t1, t2, r)]: A binary variable. This is an order variable used to handle the scheduling of multiple trains on the same track. When y[(t1, t2, r)] = 1, it means that on track r, the operation of train t1 is scheduled before that of train t2.

[0092] batch_max_p = sum(max(p[(t, r)] for r in Tracks) for t incurrent_batch) current_horizon_base = max(track_free_time.values()) if track_free_time else 0 M = current_horizon_base + batch_max_p + 10000 # C is set to 10000 as a safety margin This section calculates the "Big M" constant M, a common technique in linear programming for handling logical constraints (such as if-then conditions). `batch_max_p` is the sum of the longest possible operating times for all trains in the current batch. `current_horizon_base` is the latest idle time for all tracks at the current moment. M is set to a number much larger than the sum of these two (with an additional 10,000 as a safety margin). The value of M must be large enough to ensure that, in constraints, when a specific binary variable is 0, the relevant constraints can be effectively "closed" or "relaxed" without affecting the feasible region.

[0093] prob += pulp.lpSum([s[t] for t in current_batch]) + pulp.lpSum([x[t][r] p[(t, r)] for t in current_batch for r in Tracks]) This line defines the objective function for the current batch optimization problem: minimizing the total time spent at the station. It consists of two parts: the sum of all train start times (pulp.lpSum([s[t] for t in current_batch]) and the sum of all train operation processing times (pulp.lpSum([x[t][r]))). p[(t, r)] for ...]). Since x[t][r] is either 0 or 1, and each train can only choose one track, the total processing time is the sum of the individual processing times of all trains. Minimizing this objective means that the system will start the train's operation as early as possible and minimize the total operation time.

[0094] 8. Section 8: Constraint Construction (Core Part) Constraint 1: Assigning Uniqueness Constraint.

[0095] for t in current_batch: prob += pulp.lpSum([x[t][r]for r in Tracks]) == 1 For each train t in the current batch, the sum of the decision variables for assigning it to all tracks must equal 1. This forces that each train must be assigned to one and only one track. Constraint 2: Time feasibility constraint.

[0096] for t in current_batch: prob += s[t]>= alpha[t] # Start time >= Arrival time for r in Tracks: available_time = track_free_time[r] prob += s[t]>= available_time - M (1 - x[t][r]) The first inequality, s[t] >= alpha[t], ensures that the train's start time is no earlier than its arrival time at the station. The second inequality is a typical application of the "Big M" method, expressing that "if train t is assigned to track r (i.e., x[t][r] == 1), then its start time s[t] must not be earlier than the current available time of that track, available_time". When x[t][r] == 1, the inequality becomes s[t] >= available_time; when x[t][r] == 0, the inequality becomes s[t] >= available_time - M. Since M is very large, this constraint is actually automatically satisfied (relaxed) and does not impose a restriction on s[t]. Constraint 3: Physical compatibility and functional matching constraints.

[0097] if lengths[t]>track_length[r]: prob += x[t][r]== 0 continue t_assign = train_assignments[t].strip() r_assign = track_assignments[r].strip() if r_assign == \"\" or r_assign.lower() == \"nan\": prob += x[t][r]== 0 continue if t_assign not in r_assign: prob += x[t][r]== 0 This is a composite constraint. First, a length hard check is performed: if the length of train t is greater than the effective length of track r, the assignment is directly prohibited (x[t][r] = 0). Second, a function matching check is performed: the train's operational requirement t_assign (e.g., "general train") and the track's function description r_assign (e.g., "general train, 10,000 tons") are obtained. If the track's function description is empty or NaN, it is considered unavailable. Finally, it is determined whether the train's requirement is contained in the track's function description string. For example, t_assign="general train" is in r_assign="general train, 10,000 tons", so it matches; if r_assign="10,000 tons", it does not match. Unmatched assignments are also prohibited (x[t][r] = 0). Constraint 4: Mainline usage restrictions.

[0098] restricted_tracks_ids = [\'one\', \'four\'] for t in current_batch: check_time = p[(t, Tracks[0])] if check_time>5: for r in restricted_tracks_ids: if r in Tracks: prob += x[t][r]== 0 This constraint simulates station operation rules: if a train's technical operation processing time exceeds 5 minutes, it is not allowed to be assigned to the mainline tracks numbered 'one' and 'four'. This is to prevent trains with long operation times from occupying the mainline and affecting the passage of other trains. Constraint 5: Direction and Special Train Rules.

[0099] allowed_down = [\'one\', \'3\', \'5\', \'7\', \'9\', \'11\', \'13\', \'15\', \'19\', \'2\'] allowed_up = [\'four\', \'6\', \'8\', \'10\', \'12\', \'14\', \'16\',\'18\', \'20\', \'22\'] special_train_id = \"Rail-car\" for t in current_batch: d_val = train_directions.get(t, \"unknown\") allowed_set = set() if t.startswith(special_train_id): allowed_set = {'22'} else: if d_val == \'down\': allowed_set = set(allowed_down) elif d_val == \'up\': allowed_set = set(allowed_up) for r in Tracks: if r is not in allowed_set: prob += x[t][r]== 0 This constraint implements track allocation rules based on the direction of travel. A set of tracks is predefined that allows trains traveling in different directions, such as down, up, and originating. For each train in the current batch, an allowed track set `allowed_set` is determined based on its direction `d_val`. For special trains whose identifier begins with "Rail-car", their allowed set is forced to be only {'22'}. Then, for any track `r` not in the allowed set `allowed_set`, train `t` is prohibited from being assigned to that track (`x[t][r] = 0`). This ensures that the scheduling scheme conforms to the station's direction of travel regulations. Constraint 6: Same Track Operation Sequence Constraint (the core of the core).

[0100] for r in Tracks: for t1 in current_batch: for t2 in current_batch: if t1 == t2: continue prob += s[t1] + p[(t1, r)]<= s[t2] + M (1 - y[(t1, t2, r)]) + M (2 -x[t1][r]- x[t2][r]) prob += s[t2] + p[(t2, r)]<= s[t1] + M y[(t1, t2, r)] + M (2 - x[t1][r]- x[t2][r]) prob += y[(t1, t2, r)] + y[(t2, t1, r)]<= x[t1][r] prob += y[(t1, t2, r)] + y[(t2, t1, r)]<= x[t2][r] This set of constraints is crucial to ensuring that train operation time windows on the same track do not overlap, and the classic "Big M" method is used for modeling. For any track r and any two different trains t1, t2: The first two inequalities are mutually exclusive time constraints. The sequence variable y[(t1, t2, r)] acts as a switch.

[0101] If y[(t1, t2, r)] = 1, and both trains are assigned to track r (i.e., x[t1][r] = 1 and x[t2][r] = 1), then the first inequality takes effect, forcing the end time s[t1] + p[(t1,r)] of t1 to be less than or equal to the start time s[t2] of t2; the second inequality becomes ineffective due to the large size of M.

[0102] If y[(t1, t2, r)] = 0, the opposite is true, forcing t2 to complete before t1.

[0103] If at least one of the two trains is not assigned to track r, then (2 - x[t1][r] - x[t2][r]) is at least 1, such that a large number M is added to the right side of both inequalities, the constraint automatically relaxes and no order requirement is imposed.

[0104] The last two inequalities are logical coupling constraints, ensuring that the sequence variable y takes the value 1 only when all relevant trains are assigned to the track. If x[t1][r]=0, then y[(t1, t2, r)] and y[(t2, t1, r)] must both be 0.

[0105] 9. Paragraph Nine: Model Solving and Result Update solver = pulp.PULP_CBC_CMD(msg=True, timeLimit=60) prob.solve(solver) This section calls the PuLP-integrated CBC solver to solve the MILP model for the current batch. `msg=True` allows the solver to output some log information. `timeLimit=60` sets the maximum solution time for a single batch to 60 seconds to prevent the entire process from being blocked due to a particularly difficult batch.

[0106] status = pulp.LpStatus[prob.status] print(f\">>>Batch {batch_id} Result: {status}\") if status != \'Optimal\' and status != \'Feasible\': print(\"[Error] Infeasible batch! Check if Assignment matchesexist.\") break After the solution is completed, check the status. 'Optimal' indicates that the optimal solution has been found, and 'Feasible' indicates that a feasible solution has been found (but may not have been optimal due to time constraints). If the status is neither optimal nor feasible, it means that there is no solution for this batch of models, the program will terminate and prompt you to check data matching and other constraints.

[0107] for t in current_batch: assigned_r = None for r in Tracks: if pulp.value(x[t][r]) is not None and pulp.value(x[t][r])>0.9: assigned_r = r break if assigned_r: start_val = pulp.value(s[t]) duration = p[(t, assigned_r)] end_val = start_val + duration ts_val = start_val + duration - alpha[t] total_objective_value += ts_val final_results.append((t, assigned_r, start_val, duration)) if end_val>track_free_time[assigned_r]: track_free_time[assigned_r] = end_val This code parses the solution returned by the solver. For each train t in the current batch, it iterates through all tracks and finds the track assigned to the train whose decision variable x[t][r] value is greater than 0.9 (approximately 1). Then, it obtains the train's start time start_val and calculates the end time end_val and station time ts_val by combining it with the processing time duration. The results (t, assigned_r, start_val, duration) are stored in the final_results list. Finally, it updates the idle time track_free_time[assigned_r] of the assigned track assigned_r to the end time end_val of this train's operation (updating only if end_val is later). This update step is the essence of rolling time-domain optimization; it "passes on" the resource usage of trains in the solved batch to subsequent batches, ensuring the consistency of the global timeline.

[0108] 10. Tenth Section: Final Result Output and Visualization print("\n\" + \"=\" 50) print(\"FINAL ROLLING SCHEDULE\") for (t, r, start, dur) in final_results: t_a = train_assignments.get(t, \"\") r_a = track_assignments.get(r, \"\") print(f\"{t:<20} {t_a:<10} {r:<8} {r_a:<10} {start:<8.2f} {dur:<6.2f}\") After all batches have been solved, the program outputs the final scheduling summary table. The table is sorted by start time and clearly lists the ID, demand type, assigned track, track function, start time, and processing time for each train. `total_objective_value` provides a measure of the total time all trains are in the station.

[0109] if len(final_results)>0: fig, ax = plt.subplots(figsize=(15, 8)) for (t, r, start, dur) in final_results: ax.barh(y_pos, dur, left=start, height=0.6, color=color_dict[t],edgecolor=\'black\', alpha=0.8) ax.text(start + dur / 2, y_pos, t, va=\'center\', ha=\'center\',fontsize=7, color=\'white\', fontweight=\'bold\') plt.show() Finally, the code uses matplotlib to create a Gantt chart for visualization. The Y-axis represents the track number, and the X-axis represents time. On each track, the operation process of each train is represented by a horizontal bar: its left end is at the start time (`start`), its length is equal to the processing time (`dur`), and the train ID (`t`) is labeled inside the bar. Different trains are distinguished by different colors. This chart makes the operation arrangements of all tracks and all trains in the entire station clear at a glance, allowing dispatchers to intuitively check the rationality of the plan and identify conflicts.

[0110] In summary, this code example provides a complete, clear, and operable demonstration of how to transform the complex operational problem of scheduling within a single railway station into a computable mathematical optimization model, and how to obtain a high-quality automated scheduling solution through an efficient solution strategy. Those skilled in the art can directly run this code to obtain optimization results after preparing input data files that meet the required format.

[0111] This invention provides another embodiment, which provides a railway single-station scheduling optimization system, the railway single-station scheduling optimization system comprising: The data acquisition and processing module is used to execute steps S1 and S2, acquire and process train and track data, and generate a candidate track set; The model building module is used to execute steps S3 and S4 to build the mixed integer linear programming (MILP) model. The optimization solution module is used to execute step S5 and solve the MILP model; The output module is used to output and display the obtained scheduling scheme.

[0112] It should be further explained that the data acquisition and processing module is responsible for interfaceing with external data sources (such as the TDCS / CTC system and the station's current train management system), reading static and dynamic data of trains and tracks, and performing cleaning, formatting, and compatibility pre-calculation to generate internal data structures for optimization. The model building module dynamically generates mathematical expressions for the MILP model based on current scheduling requirements and constraints, including defining decision variables, setting objective functions, adding all physical constraints, business rule constraints, temporal conflict constraints (Big-M constraints), and state inheritance constraints in the rolling time domain. The optimization solution module encapsulates the calling interface with the underlying mathematical programming solver (such as CBC and Gurobi), responsible for passing the mathematical model generated by the model building module to the solver, monitoring the solution process, and processing the solution results (optimal solution, feasible solution, or no solution). The output module converts the decision variable values ​​returned by the solver into a business-level scheduling plan table and a visual Gantt chart, and provides them to the station scheduling command terminal or printouts.

[0113] Understandably, this system modularizes and integrates the various steps of the method, forming a complete automated pipeline from data input to dispatch instruction output. It standardizes and automates the dispatch decision-making process, enabling it to replace or assist human dispatchers, quickly respond to changes in traffic flow, and generate safe, efficient, and compliant in-station dispatching solutions. It is a core software system for the transformation and upgrading of railway freight stations towards intelligence and automation.

[0114] In a preferred embodiment, this application also provides an electronic device, the electronic device comprising: The computer device includes a memory and a processor, wherein the memory stores computer-readable instructions that, when executed by the processor, implement the railway single-station scheduling optimization method. The computer device can be broadly categorized as a server, terminal, or any other electronic device with the necessary computing and / or processing capabilities. In one embodiment, the computer device may include a processor, memory, network interface, communication interface, etc., connected via a system bus. The processor of the computer device can be used to provide the necessary computing, processing, and / or control capabilities. The memory of the computer device may include a non-volatile storage medium and internal memory. The non-volatile storage medium may store an operating system, computer programs, etc. The internal memory can provide an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface and communication interface of the computer device can be used to connect and communicate with external devices via a network. When the computer program is executed by the processor, it performs the steps of the method of the present invention.

[0115] This invention can be implemented as a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, causes the steps of the methods of embodiments of the invention to be performed. In one embodiment, the computer program is distributed across multiple network-coupled computer devices or processors, such that the computer program is stored, accessed, and executed in a distributed manner by one or more computer devices or processors. A single method step / operation, or two or more method steps / operations, may be executed by a single computer device or processor or by two or more computer devices or processors. One or more method steps / operations may be executed by one or more computer devices or processors, and one or more other method steps / operations may be executed by one or more other computer devices or processors. One or more computer devices or processors may execute a single method step / operation, or execute two or more method steps / operations.

[0116] Those skilled in the art will understand that the method steps of this invention can be performed by a computer program instructing related hardware, such as a computer device or processor, to perform the steps of this invention when executed. Depending on the context, any references herein to memory, storage, databases, or other media may include non-volatile and / or volatile memory. Examples of non-volatile memory include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, magnetic tape, floppy disk, magneto-optical data storage device, optical data storage device, hard disk, solid-state drive, etc. Examples of volatile memory include random access memory (RAM), external cache memory, etc.

[0117] The technical features described above can be combined arbitrarily. Although not all possible combinations of these technical features are described, any combination of these technical features should be considered to be covered by this specification, provided that such combination does not contain contradictions.

[0118] The specific embodiments of the present invention described above do not constitute a limitation on the scope of protection of the present invention. Any other corresponding changes and modifications made in accordance with the technical concept of the present invention should be included within the scope of protection of the claims of the present invention.

Claims

1. A method for optimizing scheduling within a single railway station, characterized in that, Includes the following steps: S1. Obtain the physical attribute data and dynamic operation data of the train to be dispatched, as well as the resource attribute data of each track in the station; S2. Based on the physical attribute data and resource attribute data, select a set of physically compatible candidate tracks for each train; S3. Construct allocation variables for deciding train track allocation, and order variables for deciding the order of train operations within the same track; S4. Based on the allocation variables, order variables, dynamic operation data and preset operation time, construct a mixed integer linear programming (MILP) model with the objective of minimizing the total time spent by trains at the station or the average dwell time. The model includes order constraints to ensure that the operation time windows of trains on the same track do not overlap. S5. Solve the MILP model and output the final track allocation and operation schedule for each train.

2. The method according to claim 1, characterized in that, In step S2, the physical attribute data includes at least the train length and the total train weight, and the resource attribute data includes at least the effective track length and the maximum track load capacity; physical compatibility means that the train length is not greater than the effective track length and the total train weight is not greater than the maximum track load capacity.

3. The method according to claim 2, characterized in that, Step S2 further includes: Based on preset business rules, the candidate track set is further filtered. The business rules include matching rules between train operation direction and track number, or binding rules between specific train type and designated track.

4. The method according to claim 1, characterized in that, The sequence constraint in step S4 is implemented by introducing a large constant M and using the sequence variable for logical control, so as to ensure that for any two trains assigned to the same track, the end time of one train's operation is no later than the start time of the other train's operation.

5. The method according to claim 4, characterized in that, The value of the large constant M is set to be greater than the sum of the times of all possible jobs.

6. The method according to claim 1, characterized in that, The MILP model constructed in step S4 also includes external operational constraints, which include at least one of the following: sunroof time and section speed limit.

7. The method according to claim 1, characterized in that, Step S5 employs a rolling time-domain optimization strategy to solve the problem. All trains to be scheduled are divided into consecutive batches according to their arrival time. The optimization solution is performed on each batch of trains in turn, and the release time of the track resources occupied by the trains in the solved batches is used as a known condition for the optimization of subsequent batches.

8. The method according to claim 1, characterized in that, The work schedule output in step S5 includes the start and end times of the work for each train on the final assigned track.

9. The method according to any one of claims 1-8, characterized in that, The method further includes step S6: The final track allocation and work schedule will be visualized in the form of a Gantt chart.

10. A railway single-station scheduling optimization system, used to implement the method according to any one of claims 1-9, characterized in that, include: The data acquisition and processing module is used to execute steps S1 and S2, acquire and process train and track data, and generate a candidate track set. The model building module is used to execute steps S3 and S4 to build the mixed integer linear programming (MILP) model. The optimization solution module is used to execute step S5 and solve the MILP model; The output module is used to output and display the obtained scheduling scheme.

Images