A method and system for coordinated scheduling of railway transportation and track maintenance windows

Abstract

This invention relates to the field of railway transportation scheduling technology, specifically to a method and system for collaborative scheduling of railway transportation and maintenance windows. The method includes: a maintenance window intelligent agent actively submitting maintenance window applications; a scheduling negotiation platform dynamically determining the negotiation mode based on the coupling relationship of multiple applications and assigning tasks to the transportation intelligent agent; the transportation intelligent agent and the maintenance window intelligent agent engaging in multi-round game negotiation based on their respective maintained local constraint spaces to generate candidate solutions; and finally, the scheduling negotiation platform performing global consistency verification and submitting the solutions for approval. This invention, by constructing a three-layer architecture of transportation intelligent agent, maintenance window intelligent agent, and scheduling negotiation platform, and employing mechanisms such as constraint space intersection calculation, adaptive concession based on the Zeuthen criterion, dynamic breakpoint and utility function learning, achieves minute-level transparent and intelligent dynamic negotiation between transportation demand and maintenance windows, significantly improving the overall efficiency and precision of railway transportation organization.

Description

Technical Field

[0001] This invention relates to the field of railway transportation scheduling technology, specifically to a method and system for coordinated scheduling of railway transportation and track maintenance windows. Background Technology

[0002] In the existing railway transportation scheduling field, a "track window" refers to the time reserved for construction and maintenance work by not marking train running lines or adjusting / reducing train running lines in the train timetable. A three-tiered planning system of annual, monthly, and daily schedules is commonly used. The group company typically sets annual transport volume targets at the beginning of the year and breaks them down into monthly plans, which are then issued to each railway company. The railway company's dispatching office then prepares specific daily schedules based on these plans and organizes their execution. This traditional model has revealed a series of systemic and technical defects in long-term practice. From a systemic perspective, there is a significant information barrier between the group and the railway company. The group level struggles to grasp the complex constraints and dynamic changes in frontline micro-operations in real time and accurately (e.g., fluctuations in coal supply at specific stations, temporary limitations on port loading and unloading capacity, and hidden deterioration of equipment status), while the railway company cannot accurately know the group's flexible adjustment space while ensuring the overall transport volume target. This two-way information asymmetry leads to cross-level coordination heavily relying on inefficient meeting communication and document exchanges, resulting in long response cycles and decision-making based largely on the dispatcher's personal experience, making it difficult to achieve a refined dynamic balance between transport efficiency and track window operation assurance. Meanwhile, a wealth of valuable on-site coordination experience and on-the-spot decision-making logic (such as the priority of sunroof adjustments under specific weather conditions and risk trade-offs under critical equipment conditions) are scattered in emails or meeting minutes in an unstructured form, which cannot be effectively accumulated, quantified and passed on, thus restricting the systematic improvement of scheduling level.

[0003] From a technical perspective, while some optimization models and algorithms exist for single aspects such as train timetables, locomotive turnaround, and maintenance window plans, these models are mostly centralized, offline optimization solvers. They require integrating all constraints and objectives of transportation and maintenance into a massive mathematical model. This approach faces two major bottlenecks when frequent plan adjustments are needed to address disturbances: first, low solution efficiency. Each constraint change (such as the addition of an emergency task or sudden equipment malfunction) necessitates reconstructing and resolving the entire model, taking several hours and failing to meet the demands of real-time dispatch response; second, the model is rigid, making it difficult to flexibly express and adapt to "conditional" concession strategies based on specific scenarios in actual dispatch (such as being willing to moderately postpone non-critical maintenance windows under emergency supply tasks). Furthermore, existing optimization algorithms have high requirements for the structure of input data and cannot effectively handle empirical constraints described by dispatchers in natural language, such as "coal supply shortages" or "equipment status nearing critical levels." The output results also lack a clear explanation of the decision-making logic, leading to low trust and weak application willingness among frontline personnel, ultimately rendering the system largely useless.

[0004] Therefore, existing technologies still need further development. Summary of the Invention

[0005] The purpose of this invention is to overcome the above-mentioned technical deficiencies and provide a method and system for coordinated scheduling of railway transportation and track maintenance windows, so as to solve the problems existing in the prior art.

[0006] To achieve the above-mentioned technical objectives, according to a first aspect of the present invention, the present invention provides a method for coordinated scheduling of railway transportation and track maintenance windows, comprising: S1. Receive the skylight operation application submitted proactively by the skylight operation intelligent agent; S2. The scheduling and negotiation platform dynamically determines the negotiation and scheduling mode based on the coupling relationship between multiple track window operation applications and assigns negotiation tasks to the transportation intelligent agent. S3. The transportation agent and the sunroof operation agent engage in multiple rounds of game negotiation based on their respective maintained local constraint spaces to generate collaborative scheduling candidate schemes. S4. The scheduling and negotiation platform performs global consistency verification on the candidate solutions generated through negotiation, and submits the verified solutions to the decision-making and approval process.

[0007] Specifically, the multi-round game negotiation process in step S3 is controlled and executed by a preset negotiation state machine, which includes an initialization state, a proposal state, an evaluation state, a counter-proposal state, a convergence check state, and an equilibrium solution state; the negotiation process is recorded as a structured negotiation trajectory and stored in a case knowledge base.

[0008] Specifically, in the proposal state and the counter-proposal state, a concession decision algorithm based on the Zeuthen criterion is used to determine the conceding party and generate a new proposal. The concession decision algorithm compares the risk willingness index of both parties, which is calculated based on the difference between the current proposal utility and the break point.

[0009] Specifically, in the evaluation state, a constrained space intersection calculation algorithm is used to determine the joint feasible region between the transportation agent and the track maintenance agent. This algorithm is implemented by constructing an interval tree and performing query and intersection operations on the feasible time windows of the track maintenance agent. The specific steps include: 1) Construct the prohibited time windows of the transportation agent as an interval tree, with a time complexity of O(nlogn), where n is the number of prohibited windows; 2) For each feasible time window of the skylight operation agent, use interval tree to query overlapping prohibited time periods. The time complexity of a single query is O(logn+m), where m is the number of overlapping windows. 3) Use a sliding window to find time periods within the feasible time window that meet the job duration requirements and do not conflict with the time period.

[0010] Specifically, in the concession decision algorithm based on the Zeuthen criterion, the concession amount of the conceding party is dynamically adjusted according to the current negotiation round using an exponential decay function.

[0011] Specifically, the breakdown point is dynamically learned and updated based on the effectiveness of the downgrade schemes of each party in historical negotiation failure cases, and adaptively adjusted in combination with the characteristics of the current scenario during the update.

[0012] Specifically, the utility function weights of the transportation agent and the skylight operation agent are derived from historical successful negotiation cases through a maximum entropy-based inverse reinforcement learning algorithm.

[0013] Specifically, it also includes the steps of: in response to a new negotiation task, retrieving negotiation cases with similar scenario characteristics from the case knowledge base, and generating an initial proposal based on the negotiation strategies in the retrieved negotiation trajectory.

[0014] Specifically, it also includes the following steps: receiving the natural language constraint description input by the scheduler, extracting constraint elements through named entity recognition and dependency parsing, and converting the constraint elements into computable formal constraints based on a preset mapping rule base, which are used to update the local constraint space of the corresponding intelligent agent.

[0015] According to a second aspect of the present invention, a railway transportation and track maintenance window coordinated scheduling system is provided, comprising: The transportation agent module is used to maintain the transportation planning constraint space and represent the interests of the transportation sector in negotiations. Multiple intelligent agent modules for skylight maintenance are used to maintain the space constraints for equipment repair and to proactively submit skylight maintenance requests; The scheduling and negotiation platform module is used to receive requests for track maintenance windows, dynamically schedule and negotiate tasks, and perform global consistency verification. The distributed negotiation engine module is used to drive the transportation agent module and the track maintenance agent module to perform multi-round game negotiation.

[0016] Beneficial effects: The present invention provides a collaborative scheduling method and system for railway transportation and track maintenance based on hierarchical multi-agent negotiation. By constructing a distributed architecture in which a scheduling negotiation platform coordinates centrally and transportation agents and track maintenance agents engage in autonomous game, it fundamentally changes the traditional centralized and manual coordination-based scheduling mode, bringing about many significant benefits.

[0017] First, this invention significantly improves the transparency and collaborative efficiency of the decision-making process. Through automated negotiation between intelligent agents, micro-level operational constraints (such as specific equipment risks and local capacity bottlenecks) and macro-level control intentions (such as task priorities and acceptable adjustment thresholds), which were originally hidden within departments or the personal experience of dispatchers, are made explicit and structured within the negotiation process. The proposals, concession logic, and decision-making basis of each round of negotiation are traceable, enabling both parties (and higher-level decision-makers) to clearly understand the background and development of the solution, effectively eliminating information asymmetry. Compared to the traditional model that requires multiple rounds of manual coordination taking hours or even longer, the distributed negotiation engine of this invention can generate multiple coordination alternatives within minutes, achieving a dynamic response at the minute level, significantly improving the railway transportation system's ability to cope with emergencies and schedule fluctuations.

[0018] Secondly, this invention achieves the digital accumulation and intelligent reuse of scheduling experience. By structuring the entire negotiation process (including constraints, concession paths, final solutions, and execution effects) into case nodes in a knowledge graph, the system constructs a continuously enriched decision-making knowledge base. When facing new scheduling scenarios, the system can quickly retrieve similar historical cases and reuse successful negotiation strategies to generate high-quality initial proposals or guide concession directions. This case-based reasoning capability enables new schedulers to quickly learn from the experience of senior schedulers, shortening the talent development cycle and transforming scattered, unstructured individual experience into searchable, analyzable, and inheritable collective wisdom, thereby achieving the continuous accumulation and evolution of scheduling decision-making knowledge.

[0019] Finally, this invention significantly lowers the application threshold of optimization techniques and enhances their flexibility. By introducing a formal mapping mechanism for natural language constraints, dispatchers can directly issue instructions using their familiar business language (such as "Coal supply at Shenchi South Station is insufficient; daily transport volume cannot be less than 950 wagons"), and the system automatically converts these instructions into computational constraints that the agent can understand, greatly improving the system's usability. Simultaneously, the inverse reinforcement learning mechanism based on historical data can automatically deduce the true preference weights of each party from a large number of successful scheduling decisions, avoiding the subjectivity and inaccuracy of manually setting utility function weights. Combined with dynamically learning breakpoints from failed cases and an adaptive concession strategy based on the Zeuthen criterion, the negotiation process is not only efficient but also closely reflects the complex trade-off logic in actual business operations. The generated solutions are more easily accepted and implemented by all parties, thereby effectively improving the fulfillment rate of track maintenance windows and the timeliness of equipment maintenance while ensuring transportation safety and efficiency. Attached Figure Description

[0020] Figure 1 This is a hierarchical multi-agent system architecture diagram provided in a specific embodiment of the present invention; Figure 2 This is a multi-round negotiation flowchart based on a state machine provided in a specific embodiment of the present invention.

[0021] Figure 3 This is a flowchart illustrating the railway transportation and track maintenance collaborative scheduling 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-3 This invention provides a method for coordinated scheduling of railway transportation and track maintenance windows, comprising: S1. Receive the skylight operation application submitted by the skylight operation intelligent agent.

[0025] It should be further explained that this method constructs a hierarchical multi-agent system framework to solve the dynamic collaborative scheduling problem between railway transportation planning and track maintenance operations. (Reference) Figure 1 The system architecture diagram shown in this embodiment of the invention includes a scheduling and negotiation platform (macro-coordination layer) at the upper layer, multiple intelligent agents representing different business departments (negotiation and decision-making layer) at the middle layer, and data sources for various business systems at the bottom layer (data support layer). The maintenance window operation intelligent agents specifically correspond to different maintenance work areas or equipment management units, such as power supply section intelligent agents, signaling section intelligent agents, and track maintenance section intelligent agents. Each maintenance window operation intelligent agent independently maintains constraints such as equipment status, maintenance procedures, resource (personnel, equipment) availability, and safety procedures within its jurisdiction. These constraints collectively constitute its local constraint space, which is typically represented as a series of linear or nonlinear inequalities concerning time, space, and resources. The transportation intelligent agent represents the transportation scheduling department, and its local constraint space includes core constraints of the transportation plan such as train timetables, section throughput capacity, station arrival and departure capacity, and construction slow-moving restrictions. In step S1, the intelligent agent for track maintenance proactively generates a track maintenance application based on the equipment monitoring status, preventive maintenance plan, or temporary fault. The application includes key attributes such as the type of operation, the required section / station, the estimated operation duration, the earliest start time, and the latest end time.

[0026] For further details, please refer to Figure 1 , Figure 1 The overall hierarchical architecture of the system described in this invention is clearly illustrated, providing intuitive visual support for those skilled in the art to understand the hierarchical multi-agent framework described in the specific embodiments. For example... Figure 1 As shown, the entire system adopts a top-down three-layer design, reflecting the complete logic from global coordination to specific execution and data support. The top layer is the "Schedule Coordination Layer," corresponding to the "Schedule Negotiation Platform Module" described in the specific implementation. This layer contains the "Schedule Coordinator Intelligent Agent" as the core hub, responsible for receiving track maintenance window applications, dynamically scheduling negotiation tasks, and performing global consistency verification. This corresponds completely to steps S2 and S4 and the functions of the "Schedule Negotiation Platform Module." Its included "Third-Party Mediation Intelligent Agent (Started on Demand)" reflects the system's extended processing capabilities in complex conflict situations. The middle layer is the "Business Intelligent Agent Layer," corresponding to the "Transportation Intelligent Agent Module" and "Multiple Track Maintenance Window Intelligent Agent Modules." The diagram clearly shows that the "Transportation Intelligent Agent (1)" represents the interests of the transportation department and interacts with the "Track Maintenance Window Intelligent Agents (Multiple, divided by engineering section)," which perfectly illustrates the architecture of multiple intelligent agents representing different business departments negotiating as described in the specific implementation. The lowest layer is the "Data Service Layer," which provides data support to the upper-layer agents through the "Transportation Plan Database," "Equipment Status Database," and "Historical Case Database." The "Historical Case Database" directly corresponds to the "Case Knowledge Base" used in the specific implementation to store negotiation trajectories and support case reasoning. The bidirectional arrows between the layers indicate "Negotiation Request / Result Feedback" and "Constraint Query / Status Update," vividly illustrating how the multi-round game negotiation described in step S3 is initiated and conducted between the "Transportation Agent" and the "Skylight Operation Agent." It also demonstrates how the agents obtain constraint information (i.e., their respective local constraint spaces) from the underlying database to support negotiation calculations. Overall, this diagram systematically elucidates the components described in the specific implementation and their interaction relationships, enabling those skilled in the art to understand the system's operational basis without question.

[0027] S2. The scheduling and negotiation platform dynamically determines the negotiation and scheduling mode based on the coupling relationship between multiple track opening operation applications and assigns negotiation tasks to the transportation agent.

[0028] It should be further explained that in step S2, the scheduling and negotiation platform, acting as the central hub, receives multiple track maintenance window applications in real time. One of its core functions is to assess the coupling relationships between applications. These coupling relationships include: 1) spatiotemporal conflicts (overlapping work intervals and overlapping time windows); 2) resource competition (sharing maintenance equipment or personnel); and 3) safety exclusion (work types that cannot be carried out simultaneously during a specific time period). These coupling relationships are mainly quantified through dimensions such as spatiotemporal conflicts (e.g., overlapping work intervals and overlapping time windows), resource competition (e.g., sharing large maintenance equipment or special operation personnel), and safety exclusion (e.g., overhead contact line maintenance and track maintenance cannot be carried out simultaneously during a specific time period). Based on the strength of the coupling relationship (e.g., by calculating quantitative indicators such as the spatiotemporal overlap and resource demand conflict index between applications, and setting thresholds), the platform dynamically decides whether to adopt a "one-to-one sequential negotiation," "one-to-many parallel negotiation," or "many-to-many joint negotiation" mode, and assigns a transportation agent instance to each negotiation task.

[0029] S3, the transportation agent and the skylight operation agent, based on their respective maintained local constraint spaces, engage in multiple rounds of game negotiation to generate collaborative scheduling candidate schemes.

[0030] It should be further explained that step S3 is the core of the method, where the transportation agent and one or more track maintenance agents enter an automatic negotiation process based on game theory. The basis of the negotiation is the local constraint space that is publicly or partially publicly disclosed by both parties. The goal of the negotiation is to find a set of assignments for decision variables such as the specific start time, end time, occupied interval, and speed limit of the track maintenance operation within their respective constraint spaces, so that the joint solution is feasible and the sum (or weighted sum) of the utilities of both parties is as high as possible.

[0031] S4. The scheduling and negotiation platform performs global consistency verification on the candidate solutions generated through negotiation, and submits the verified solutions to the decision-making and approval process.

[0032] It should be further explained that in step S4, the scheduling negotiation platform performs a global verification of the local candidate scheme reached in step S3, checks whether it conflicts with other existing plans not involved in this negotiation (such as other approved maintenance windows and key train operation lines), and verifies whether it meets the global safety rules and operational indicators. After the verification is passed, a formal scheduling scheme draft is formed and pushed to the dispatcher terminal for final manual confirmation or adjustment.

[0033] Understandably, the aforementioned hierarchical multi-agent negotiation mechanism transforms the traditional centralized, sequential scheduling decision-making process into a distributed, parallel, autonomous negotiation process. This effectively solves the problem of low collaborative efficiency caused by information silos and departmental barriers, enabling track maintenance requests to be issued proactively and promptly, and to engage in dynamic game theory with the transportation plan. Thus, while ensuring transportation safety and order, it significantly improves the flexibility, response speed, and overall utilization efficiency of track maintenance plans, achieving a higher-level dynamic balance and optimization of the goals of both the transportation and maintenance systems.

[0034] Specifically, the multi-round game negotiation process in step S3 is controlled and executed by a preset negotiation state machine, which includes an initialization state, a proposal state, an evaluation state, a counter-proposal state, a convergence check state, and an equilibrium solution state; the negotiation process is recorded as a structured negotiation trajectory and stored in a case knowledge base.

[0035] It should be further noted that, in order to standardize and reliably drive bilateral or multilateral negotiation processes, this method designs a rigorous negotiation state machine (its state transition logic can be found in [reference needed]). Figure 2 (i.e., the schematic diagram of the negotiation state machine provided in the embodiments of the present invention). This state machine clearly defines the various stages and transition conditions within the negotiation lifecycle, and the specific design includes: (1) Negotiation initialization state: In this state, the negotiation participants (transportation agent T and skylight operation agent W_i) complete the preparation work, including loading the context of this negotiation task, retrieving similar historical cases from the case knowledge base to initialize the strategy (if applicable), setting the maximum negotiation round limit MAX_ROUND (a preferred value is 50 rounds), initializing their respective utility function parameters and breakpoint (Best Alternative to a Negotiated Agreement, BATNA), etc.

[0036] (2) Proposal state: The party that initiates the negotiation first (usually the window operation agent) enters this state and generates and issues the initial proposal P_init.

[0037] (3) Evaluation state: The receiver (such as the transport agent receiving the proposal from the skylight operation agent) enters this state, calls its own evaluation module, calculates the utility value U(P) of the proposal under its own utility function, and performs feasibility verification based on the constraint space.

[0038] (4) Counter-proposal state: If the evaluation determines that the other party's proposal is unacceptable (utility is below a certain threshold U_thresh or violates hard constraints), and the negotiation has not reached the maximum number of rounds, then the counter-proposal state is entered. In this state, a new proposal P_counter that is better for one's own side and compromises for the other party is generated according to the preset concession strategy (such as the Zeuthen criterion described later).

[0039] (5) Convergence check state: After each round of proposal or counter-proposal, the system enters this state to check whether the negotiation can be terminated. Termination conditions include: both parties' utility for the current proposal has reached their respective satisfaction thresholds (i.e., U_T(P)>=U_{T, satis} and U_W(P)>=U_{W, satis}), or the utility improvement of both parties is less than the minimum value ε (the preferred value of ε is 0.001) for N consecutive rounds, or the maximum number of negotiation rounds has been reached.

[0040] (6) Equilibrium Solution State: This state is triggered by the scheduling negotiation platform when the negotiation reaches a deadlock in the regular proposal / counter-proposal loop (e.g., the utility improvement is less than the threshold of 0.001 for three consecutive rounds). The state transition conditions include: a) From initialization state to proposal state: Negotiation task allocation completed; b) From proposal status to evaluation status: The proposal has been received from the other party; c) From evaluation state to counterproposal state: The proposal is unacceptable and has not reached the maximum round; d) From evaluation state to convergence check state: Proposal is acceptable; e) From the anti-proposal state to the convergence check state: New proposal generation complete; f) From convergence check state to equilibrium solution state: conventional negotiation reaches a deadlock; g) From Convergence Check State to End: Convergence condition met. This state is triggered when the negotiation reaches a deadlock in the regular proposal / counter-proposal loop (e.g., utility improvement stagnates but fails to reach the satisfaction threshold). In this state, both parties share some constraints and preference parameters to a limited extent, jointly construct a joint optimization model, and attempt to quickly solve a Nash bargaining solution or a Kalai-Smorodinsky solution as the final solution.

[0041] Furthermore, all data generated throughout the negotiation process, including the content of each round of proposals, sender / receiver, calculated utility values, evaluation results, triggered state transitions, and the final agreement (or reason for breakdown), is structured and recorded as a "negotiation trajectory." This trajectory is persistently stored in a case knowledge base. Each trajectory is indexed using a feature vector, which includes, but is not limited to: the type of maintenance window, the application time range, the involved area, the transportation density level, and the initial breakdown point for both parties. An example of the storage code is shown below (in Python pseudocode): class NegotiationTrace: def __init__(self, negotiation_id, participants, context_features): self.negotiation_id = negotiation_id # Unique identifier for the negotiation session self.participants = participants # List of participants, such as ['TransportAgent_01', 'MaintenanceAgent_05'] self.context_features = context_features # Negotiate context feature vectors self.round_records = [] # List of round records def add_round_record(self, sender, receiver, proposal, utility_sender, utility_receiver, assessment_result, next_state): record = { 'round_num': len(self.round_records) + 1, 'sender': sender 'receiver': receiver 'proposal': proposal, # The specific details of the proposal, such as {'start_time': 1020, 'duration': 120, ...} 'utility_sender': utility_sender, # The sender's calculated utility. 'utility_receiver': utility_receiver, # The receiver's calculated utility (may be empty, to be filled by the receiver after evaluation) 'assessment_result': assessment_result, # Assessment result, such as 'FEASIBLE', 'INFEASIBLE' 'next_state': next_state # The next state triggered by this round } self.round_records.append(record) Understandably, introducing a state machine model makes the complex multi-round negotiation process controllable, predictable, and easy to debug. The state machine clearly defines the responsibility and output of each stage, ensuring the rigor of the negotiation logic. Recording the entire negotiation process as a structured trajectory and storing it in a case knowledge base accumulates a high-quality data foundation for subsequent intelligent learning (such as case reasoning and strategy optimization), enabling the system to continuously learn and improve performance, thus achieving a transformation from one-time negotiation to experience accumulation and self-evolution.

[0042] For further details, please refer to Figure 2 , Figure 2 The state transition logic of the core negotiation process of this invention is described in detail. For example... Figure 2As shown, the negotiation process begins in the "S0: Initialization" state, which is completely consistent with the activities such as loading the task context and setting parameters during the "Initialization" state of the negotiation state machine described in the specific implementation. After "Negotiation Triggered", the process enters the "S1: Proposal Generation" state, corresponding to the "Proposal State" in the state machine and the step of generating the initial proposal. Subsequently, the process enters the "S2: Feasibility Assessment (Calculate Intersection)" state, which precisely corresponds to the "Assessment State". Its core is to use an algorithm to calculate the intersection of the constraint spaces of the transportation and skylight operations to determine the joint feasible region. According to the assessment results, the process branches: if the assessment is "successful but not converged", it enters the "S3: Utility Assessment Concession" state. This state perfectly corresponds to the "Counter-Proposal State" and the complete algorithm logic of comparing risk willingness based on the Zeuthen criterion and generating a new proposal based on the dynamic concession magnitude; the label "Generate New Proposal" in the figure also clearly indicates the core output of this state. After that, the process converges to the "S4: Convergence Check" state, which is the "Convergence Check State" in the state machine, to determine whether the negotiation meets the termination conditions. If the check result is "not converged," the process will return to S1 or S3, forming a multi-round iterative loop, reflecting the core characteristic of "multi-round game negotiation." If the check result is "converged," it will enter the "S5: Nash equilibrium solution" state, which is the "equilibrium solution state" in the state machine. When the conventional negotiation reaches a deadlock, both parties jointly solve a Nash bargaining solution through limited information sharing, serving as an alternative generation mechanism for the final solution. Finally, the process points to the "end" node. This diagram visualizes and connects the complex multi-round negotiation process, described in the text and controlled by the state machine, through clear state nodes and conditional transition arrows. This allows those skilled in the art to clearly understand the complete and closed-loop negotiation process from initialization, proposal, evaluation, counter-proposal (concession), convergence check to equilibrium solution.

[0043] Specifically, in the proposal state and the counter-proposal state, a concession decision algorithm based on the Zeuthen criterion is used to determine the conceding party and generate a new proposal. The concession decision algorithm compares the risk willingness index of both parties, which is calculated based on the difference between the current proposal utility and the break point.

[0044] It should be further explained that the Zeuthen criterion is a classic game-theoretic concession strategy, the core idea of ​​which is that the party with a lower risk appetite (i.e., a greater fear of a breakdown in negotiations) should make concessions. In this method, we concretize it into computable algorithmic steps, specifically designed as follows: First, define the key variable: Let the current round be... The current proposal for the transport agent T is... Its own utility is Its rupture point is (i.e., the best alternative utility that T can obtain when an agreement cannot be reached). Similarly, the current proposal of the sunroof operation agent W is... Its own utility is The rupture point is Then the risk appetite index of both parties. The calculation formula is as follows: in, Representing the transport agent T in the first Risk appetite index for the round The representative of the transport agent T made the current proposal. The utility value obtained from the evaluation The breakdown point utility represents the transport agent T. The intelligent agent W representing the sunroof operation is in the... Risk appetite index for the round The intelligent agent W representing the sunroof operation makes the current proposal to itself. The utility value obtained from the evaluation The breakpoint effect represents the intelligent agent W for the sunroof operation.

[0045] Furthermore, comparison and :if If the risk appetite of transport agent T is lower, meaning T is more afraid of a breakdown in negotiations, then T should make concessions in this round; otherwise, W should make concessions. Then, one party can be randomly selected to concede, or the party that "benefited" less in the previous proposal can concede (i.e., the party with the smaller utility increase). After determining the conceding party, a new proposal needs to be generated. The new proposal should search within the conceding party's local constraint space in a direction that appropriately reduces its own utility while maximizing the utility of the other party. A specific implementation is that the conceding party samples several candidate solutions in its feasible solution space and calculates its own utility corresponding to each candidate solution. And the other party's utility (calculated based on the other party's publicly disclosed or estimated utility function model) Then choose one that makes The largest candidate solution is proposed as the new solution, among which It is a small positive weighting coefficient (preferably 0.1) used to strike a balance between increasing the other party's utility and preserving one's own utility.

[0046] Understandably, employing a concession decision-making algorithm based on the Zeuthen criterion provides a rational and quantifiable basis for concessions in automated negotiation. It avoids blind or fixed concession strategies, instead dynamically determining who should concede and to what extent based on the negotiating parties' current "bottom line" (breakdown point) and the level of satisfaction with the current solution. This strategy simulates the rational decision-making process in human negotiation, effectively guiding negotiations towards Pareto improvement, increasing the probability and quality of reaching an agreement, while preventing excessive concessions from one party that could lead to a severely unfair outcome.

[0047] Specifically, in the evaluation state, a constrained space intersection calculation algorithm is used to determine the joint feasible region between the transportation agent and the track maintenance agent. This algorithm is implemented by constructing an interval tree and performing query and intersection operations on the feasible time windows of the track maintenance agent. The specific steps include: 1) Construct the prohibited time windows of the transportation agent as an interval tree, with a time complexity of O(nlogn), where n is the number of prohibited windows; 2) For each feasible time window of the skylight operation agent, use interval tree to query overlapping prohibited time periods. The time complexity of a single query is O(logn+m), where m is the number of overlapping windows. 3) Use a sliding window to find time periods within the feasible time window that meet the job duration requirements and do not conflict with the time period.

[0048] It should be further explained that the core of evaluating the feasibility of the other party's proposal is to check whether the proposal lies within the joint feasible region of both parties. Since the constraint spaces of both parties can be very complex, directly obtaining the analytical form of the joint feasible region is often difficult. This method employs an efficient numerical computation approach, focusing on the crucial constraint dimension of time. The local constraint space maintained by each window operation agent includes constraints related to the operation start time. and duration A set of constraints can be mapped to one or more continuous or discontinuous "feasible time windows." For example, a power supply maintenance operation might require it to be carried out between midnight and 4 a.m., lasting at least 90 minutes, which can be represented as a set of time windows. The constraint space of a transport agent also includes time constraints on the operation periods during maintenance windows. For example, if a high-speed train passes through a certain section during a specific time period, operations cannot be scheduled, which forms a "prohibited time window" on the transport side.

[0049] Furthermore, in the evaluation state, when the transport agent receives a specific proposal from the sunroof operation agent... (Includes suggested start time) and duration When it comes to the operation, it needs to quickly determine whether there exists a time arrangement that can both meet the proposed operation duration requirements and simultaneously avoid the prohibited windows on the transportation side, falling within the feasible window on the track operation side. To this end, the algorithm first identifies all relevant prohibited time windows of the transportation agent (represented as...). The interval is inserted into an IntervalTree data structure. IntervalTrees support efficient overlapping interval queries. Then, the algorithm calculates the interval based on the proposed duration. To determine the "query length," slide across the list of feasible time windows published by the skylight operation agent. For each feasible window on the skylight operation side... Consider all possible start times ∈ For each of these The corresponding working period is The algorithm utilizes a pre-constructed interval tree to quickly query the time period for the job. Is it related to any transport prohibition window? There is overlap (i.e., the intersection is not empty). If there exists a This makes the work period Completely included in the feasible window for skylight operation And it does not overlap with any transport prohibition windows, then this (and corresponding) This point belongs to the joint feasible region, and the proposal... It is feasible in terms of time. The algorithm code example is as follows (key parts): def is_proposal_feasible(proposal, maint_windows, forbid_tree, d): """ Check if the proposal is within the joint feasible domain.

[0050] Proposal: A suggestion from the other party, including the suggested start time, etc.

[0051] maint_windows: List of feasible time windows for the skylight operation agent.

[0052] forbid_tree: A forbidden time window interval tree constructed by the transportation agent.

[0053] d: Duration of assignment.

[0054] """ suggested_start = proposal['start_time'] # 1. Check if the proposal's start time is outside your (evaluator's) prohibition window (from the perspective of the transport agent). if forbid_tree.has_overlap(suggested_start, suggested_start + d): Return False, "Conflict with prohibited transport hours". # 2. Check whether the start time and duration of the proposal fall within the proposer's (the party proposing) feasible window. For Windows in maint_windows: if win[0]<= suggested_start and suggested_start + d<= win[1]: # If both 1 and 2 are satisfied, it means that at least one feasible point exists. # More stringent checks: It can check whether the entire time period [d] is feasible within the other party's window (considering that there may be finer-grained constraints within the other party's window). Return True, indicating "jointly feasible". Returning False indicates that the target is not within the other party's feasible time window. Understandably, by employing a constraint space intersection algorithm based on interval trees, the feasibility verification of complex multidimensional constraints is first focused on the most critical and common time conflict check, leveraging the O(logn+m) efficiency of interval trees in interval queries (where n is the number of forbidden windows and m is the number of query results). This allows the agent to complete a rapid initial screening of proposals within milliseconds, significantly improving the real-time performance of the negotiation process. This method provides a foundation for subsequent, more refined resource and space constraint checks, and is a crucial technical guarantee for achieving efficient automatic negotiation.

[0055] Specifically, in the concession decision algorithm based on the Zeuthen criterion, the concession amount of the conceding party is dynamically adjusted according to the current negotiation round using an exponential decay function.

[0056] It should be further explained that, in order to strike a balance between negotiation efficiency (fast convergence) and negotiation effectiveness (finding high-quality solutions), this method dynamically controls the concession magnitude. A simple fixed concession magnitude (e.g., a 5% reduction in utility each time) may lead to premature local optima or slow convergence. Therefore, we design the concession magnitude... As the negotiation rounds Dynamically changing. When the concessionary generates a new proposal, its utility target value is relative to the utility of the current proposal. The reduction rate was from Control. Let the new utility expected by the conceding party be... ,but Among them, the concession range The calculation formula is as follows: in, Representing the The concession range of the wheel, This represents the initial maximum concession (a preferred value is 0.15, or 15%). This represents the attenuation coefficient (a preferred value is 0.05). Represents the current negotiation round (counting from 1). This represents the natural exponential function. (Choose...) The rationale is that in the early stages of negotiations, the two sides may have significant differences, requiring a relatively substantial concession to break the deadlock and explore solutions. However, the concession should not be too large (e.g., exceeding 20%) to avoid losing too much of one's own interests. The reason is that it is necessary to ensure that the concessions decrease smoothly and relatively quickly with each round of negotiation, after approximately 20 rounds of negotiation ( The concession margin was reduced to about 37% of the initial value; after 50 rounds (the maximum number of rounds), it was reduced to about 8%. This allows for fine-tuning in the later stages of negotiation to approximate the Pareto front. When actually generating new proposals, the algorithm does not mechanically lower the utility target value. Instead, As a soft constraint or guide, the algorithm searches within its own constraint space for the solution that best approximates the utility objective and improves the utility of the other party. The search algorithm can be based on gradient-based local optimization (if the utility function is differentiable) or a combination of random sampling and evaluation.

[0057] Understandably, the exponentially decaying dynamic concession strategy simulates the "large-to-small" concession pattern commonly seen in human negotiations. In the early stages of negotiations, larger concessions help quickly bridge the gap between the two sides, demonstrate sincerity in cooperation, and broadly explore potential areas of agreement. As negotiations progress, smaller concessions allow both parties to refine the solution, avoiding skipping potential better equilibrium points due to excessive concessions, thus contributing to finding an agreement closer to Pareto optimality. This strategy enhances the intelligence of the negotiation process and the quality of the final agreement.

[0058] Specifically, the breakdown point is dynamically learned and updated based on the effectiveness of the downgrade schemes of each party in historical negotiation failure cases, and adaptively adjusted in combination with the characteristics of the current scenario during the update.

[0059] It should be further explained that the rupture point This is a key parameter in Zeuthen's risk calculation, and its accuracy directly affects the rationality of concession decisions. A static, overly optimistic, or pessimistic view... All of these factors can lead to negotiation behavior deviating from rationality. Therefore, this method designs a mechanism that dynamically learns from historical data. The mechanism involves several steps. First, defining a "degradation plan": when a negotiation ultimately breaks down (no agreement is reached), recording the alternative plans actually implemented by each party after the breakdown. For a transport agent, the degradation plan might be postponing the operation window to another less efficient (more impactful on transport) time period, or rejecting the operation application.

[0060] Furthermore, for the intelligent agent responsible for skylight operations, the degradation options might be to postpone maintenance (increasing equipment risk) or apply for shorter but more frequent skylights (increasing application and coordination costs). The utility value of these degradation options can be evaluated through a post-event feedback mechanism, denoted as... Fragmentation point The updates employ a case-based weighted average method. Assume the agent has... Each historical case of rupture The utility of a corresponding downgrade scheme and a scene feature vector (Including job type, time period, transportation busyness, urgency of application, etc.). The scenario feature vector of the current task to be negotiated is: The breakpoint estimated by the current task. The calculation is as follows: in, The representative estimates the breakdown point utility for the current negotiation task. The total number of historical rupture cases. Represents the feature vector of the current scene Historical Cases Scene feature vector Similarity functions between them (e.g., cosine similarity or Gaussian kernel function based on Euclidean distance). Representative historical cases The actual utility gained by the agent after implementing the degradation scheme. In this way, Instead of being a fixed value, it adaptively adjusts based on the specific context of the current negotiation task, referencing similar historical failures. This allows the agent to more realistically estimate its own negotiating bottom line, thus enabling more rational risk assessments and concession decisions.

[0061] Understandably, the dynamic learning and updating mechanism of the breakdown point endows the intelligent agent with the ability to "learn from its mistakes." By learning from past failures, the agent can more accurately assess "how bad the situation will be if negotiations fail," thereby setting more reasonable bottom lines in negotiations. Combining scene feature similarity weighting gives the learning process context-awareness, enhancing its effectiveness. The accuracy and generalization of the estimates. This fundamentally enhances the adaptability and intelligence of the negotiation strategy, enabling the system to continuously optimize its negotiation behavior over long-term operation.

[0062] Specifically, the utility function weights of the transportation agent and the skylight operation agent are derived from historical successful negotiation cases through a maximum entropy-based inverse reinforcement learning algorithm.

[0063] It should be further explained that the utility function is the core of the agent's scheme evaluation and decision-making. A well-designed utility function should accurately reflect the true preferences and trade-offs of the department represented by the agent. This method assumes that the utility function of each agent is a linear weighted sum of multiple attributes (i.e., features). The meanings of each dimension of the feature vector f are as follows: The features of the transportation agent include the total impact of the track closure on the scheduled train travel time (minutes), the proportion of mainline capacity occupied by the track closure (%), and the track closure opening period score (1-10 points); The features of the track closure operation agent include the degree of conformity between the operation completion time and the planned time (%), the deviation between the operation start time and the expected time (minutes), and the environmental safety score during the operation period (1-10 points). The preferred value of the feature dimension n is 3-8 dimensions. For example, the utility function of a transportation agent might consider features such as "the total impact of track closures on the travel time of scheduled trains," "the proportion of mainline capacity occupied by track closures," and "the timing of track closures (whether they occur during peak hours)." The utility function of a track closure operation agent might consider features such as "the degree of conformity between the operation completion time and the planned time," "the deviation between the operation start time and the expected time," and "the safety score of the operation environment during the operation period." Let the feature vector be... The weight vector is Then the utility Represented as: in, The utility value representing the agent, Represents the weight vector. Represents the eigenvector. Representing the The weights of each feature, Representing the The value of each feature, The total number of representative features, This represents the transpose of a vector. Weights are directly assigned manually. It is difficult and subjective. This method employs Maximum Entropy Inverse Reinforcement Learning to inversely deduce the optimal weights from historically successful negotiation cases (i.e., the scheduling schemes that are ultimately reached and adopted). Its core idea is that the expected value of expert behavior (i.e., the final solution chosen) represented by historical success stories in the feature space should be equal to the expected value of the optimal strategy learned (given by weights). The expected value of the behavior generated by the parameterization is matched, and among all policies that meet this matching condition, the one with the largest entropy (i.e., the least uncertain policy with the fewest additional assumptions) is selected. The specific steps of the algorithm are as follows: 1. Data Preparation: Collect a large number of successful historical negotiation cases, each case including: the final agreement proposal. And the set of all candidate solutions that have been evaluated by the agent in this case. (It can be extracted from the negotiation trajectory).

[0064] 2. Feature extraction: For each scheme Calculate its in The feature vector is obtained by taking values ​​from predetermined features. .

[0065] 3. Calculate the expected features of empirical characteristics: For all historical successful cases, calculate the average of the feature vectors of their final agreement schemes, as the expected features of "expert" behavior. .

[0066] in, The feature expectation vector representing expert behavior, The number of historical success cases Representing the The final agreement scheme from a historically successful case.

[0067] 4. Iterative optimization of weights: a. Initialize weights .

[0068] b. For each historical case Given the current weight Calculate each candidate solution in this case. The utility .

[0069] c. Transform utility into a probability distribution using the Softmax function, i.e., select a scheme according to the Boltzmann distribution. The probability of: .here Iterate through all candidate solutions for this case.

[0070] d. Calculate the expected features of the model under the current strategy. That is, the expected value of the feature vectors of all candidate solutions weighted by their probabilities.

[0071] e. Calculate the gradient: gradient Expected empirical features With model feature expectation difference.

[0072] f. Update weights using gradient ascent. : ,in The learning rate is 0.01 (preferred value).

[0073] g. Repeat step bf until the expected model features are sufficiently close to the expected empirical features, or the maximum number of iterations is reached (the maximum number of iterations is preferably 1000, and the convergence threshold is set to the Euclidean distance between the expected empirical features and the expected model features being less than 0.01). To prevent overfitting, an L2 regularization term can be used, with the regularization coefficient λ preferably set to 0.001.

[0074] 5. Output: Obtain the converged weight vector. , which is the learned utility function weight.

[0075] Understandably, by using maximum entropy-based inverse reinforcement learning to infer utility function weights from historical successes, subjective assumptions are avoided, ensuring that the agent's preference model is truly built upon a wealth of practical experience data. This method implicitly learns complex trade-offs from successful expert decisions (e.g., which is more important, "reducing train delays" or "ensuring maintenance windows"), thus making the agent's behavior closer to human expert decision-making patterns and improving the acceptability and rationality of negotiated solutions. This is a crucial step towards achieving intelligent and human-centered automated scheduling.

[0076] Specifically, it also includes the steps of: in response to a new negotiation task, retrieving negotiation cases with similar scenario characteristics from the case knowledge base, and generating an initial proposal based on the negotiation strategies in the retrieved negotiation trajectory.

[0077] It should be further noted that, in order to accelerate the negotiation process and improve the quality of the initial proposal, this method introduces a case-based reasoning (CBR) initialization mechanism. This step is triggered when the scheduling negotiation platform assigns a new negotiation task. First, the platform or agent extracts the scene feature vector of the current task. This vector should cover key dimensions related to the negotiation strategy, such as: type of maintenance window (e.g., overhead contact line maintenance, track grinding), application time period (e.g., daytime, nighttime), expected duration range (e.g., short <2h, long >4h), line congestion level, and whether it is an emergency repair. Then, using this feature vector... Use these search criteria to retrieve information from the case knowledge base. indivual( The preferred value is 5) the most similar historical negotiation case. Similarity can be calculated using Euclidean distance or cosine similarity, with cosine similarity (sim) being preferred. ) = ( ) / (|| || × || The case knowledge base uses a graph database storage structure. Each case node contains a scene feature vector, negotiation trajectory, final result, and timestamp. The Top-K value K is preferably 5, which can be adjusted according to the size of the case base and retrieval accuracy requirements. The similarity threshold is set to 0.7; cases below this threshold are not included in subsequent analysis. Next, the analysis... The negotiation trajectories of several similar cases are analyzed. The focus is on the "successful cases" within these trajectories where agreements were ultimately reached, detailing which party initiated the initial proposal, the specific content of the proposal (e.g., start time, duration), the main concessions made during the negotiation process, and the final agreement points. Based on this analysis, an initial proposal for the current task can be generated. Generation strategies may include: (1) Directly reuse the initial proposal of the most similar success case (if its scenario is highly matched); (2) Perform a weighted average or clustering of the initial proposal content (such as start time) of multiple similar cases to generate new proposals; (3) Analyze the other party's "acceptance pattern" in similar cases to generate a proposal that is more likely to be accepted quickly. For example, the code example is as follows: def generate_initial_proposal_from_cases(new_task_features, case_base, k=5): # 1. Calculate similarity and retrieve Top-K cases similarities = [] for case in case_base: sim = cosine_similarity(new_task_features, case['features']) similarities.append((sim, case)) similarities.sort(reverse=True, key=lambda x: x[0]) top_k_cases = [item[1] for item in similarities[:k]] # 2. Analyze the initial proposal patterns of successful cases successful_init_proposals = [] For case in top_k_cases: if case['outcome'] == 'SUCCESS': init_proposal = case['trace'].round_records[0]['proposal'] # Get the proposals from the first round. successful_init_proposals.append(init_proposal) # 3. Generate the current initial proposal (Example: take the median of the start time) if successful_init_proposals: start_times = [p['start_time'] for p in successful_init_proposals] median_start_time = np.median(start_times) # Adjustments can be made in conjunction with other constraints of the current task. initial_proposal = {'start_time': median_start_time, 'duration': new_task_features['est_duration'], ...} return initial_proposal else: return generate_default_proposal(new_task_features) # Revert to the default generation strategy Understandably, generating initial proposals based on case-based reasoning empowers the system with the ability to leverage historical experience. This allows negotiations to build upon past experience rather than starting from scratch each time. A high-quality initial proposal based on successful experiences can significantly reduce the number of negotiation rounds required to reach an agreement, improving negotiation efficiency. Furthermore, because the proposal is based on successful models from similar scenarios, it is more likely to be accepted by the other party, contributing to a positive negotiation atmosphere and increasing the overall negotiation success rate.

[0078] Specifically, it also includes the following steps: receiving the natural language constraint description input by the scheduler, extracting constraint elements through named entity recognition and dependency parsing, and converting the constraint elements into computable formal constraints based on a preset mapping rule base, which are used to update the local constraint space of the corresponding intelligent agent.

[0079] It should be further explained that, to make the system more flexible in human-computer interaction, dispatchers are allowed to temporarily add or modify scheduling constraints in the form of natural language (such as Chinese commands). For example, a dispatcher might enter: "From 9:00 AM to 11:00 AM tomorrow, no track maintenance work is allowed in the section between K500+000 and K505+000 on the Beijing-Guangzhou line (downward direction) because a superior is inspecting the train's passage." The system needs to understand and process such instructions. This step specifically includes: (1) Natural Language Processing: The input text is segmented and tagged with parts of speech. Named Entity Recognition (NER) model is used to identify key entities in the text, such as time entities ("from 9:00 to 11:00 tomorrow morning"), spatial entities ("between K500+000 and K505+000 on the Beijing-Guangzhou line"), work type entities ("any track maintenance window"), and cause entities ("superior leaders inspect the train passing through"). At the same time, dependency parsing is used to understand the relationships between entities. For example, it is analyzed that "prohibition" is the core predicate, its subject (or agent) may be the implicit "system" or "dispatcher", its object is "arrange any track maintenance window", and the time and location entities are adverbial modifiers of "prohibition".

[0080] (2) Constraint element extraction: Based on the results of NER and dependency analysis, structured constraint elements are extracted. For the example above, the following can be extracted: Constraint type: Prohibited, Operation type: All, Time: 2026-XX-XX 09:00:00 to 2026-XX-XX 11:00:00 ("tomorrow" needs to be combined with the system date parsing), Space: Beijing-Guangzhou line, Downward, Mileage range [500000, 505000].

[0081] (3) Formal Transformation: The system maintains a "mapping rule base from natural language constraints to formal constraints". This rule base consists of a series of if-then rules or templates. For example, a rule might be defined as: IF constraint type == "prohibited" AND job type == "all" THEN Generate formal constraint: FORBIDDEN_INTERVAL(time_range, location). Based on the extracted feature matching rules, the corresponding computable formal constraint expression is generated.

[0082] (4) Constraint Update and Distribution: The generated formal constraints are sent to the scheduling negotiation platform. The platform analyzes the agents affected by the constraint (mainly the transportation agent in this example) and adds the constraint as a temporary, high-priority hard constraint to the local constraint space of the corresponding agent. In all subsequent relevant negotiations, the agent's evaluation and proposal generation will be subject to this new constraint. In this way, the scheduler's experience and ad-hoc decisions can be seamlessly integrated into the automated negotiation process, realizing the collaboration and complementarity of human and machine intelligence.

[0083] Understandably, adding natural language constraint input and conversion capabilities greatly enhances the system's practicality and ease of use. It breaks down the barriers of traditional scheduling systems that require complex forms or configuration files to input constraints, allowing schedulers to express their intentions and make ad-hoc decisions in the most natural and direct way. This retains the advantages of human schedulers in handling emergencies and utilizing domain experience, while rapidly transforming this experience into machine-understandable and executable rules, enhancing the system's ability to cope with dynamic changes and complex scenarios, and achieving a seamless combination of automation and human intervention.

[0084] This invention provides another embodiment, which provides a railway transportation and track maintenance window collaborative scheduling system, the railway transportation and track maintenance window collaborative scheduling system comprising: The transportation agent module is used to maintain the transportation planning constraint space and represent the interests of the transportation sector in negotiations. Multiple intelligent agent modules for skylight maintenance are used to maintain the space constraints for equipment repair and to proactively submit skylight maintenance requests; The scheduling and negotiation platform module is used to receive requests for track maintenance windows, dynamically schedule and negotiate tasks, and perform global consistency verification. The distributed negotiation engine module is used to drive the transportation agent module and the track maintenance agent module to perform multi-round game negotiation.

[0085] It should be further explained that this system is a specific physical (or logical) implementation of the aforementioned method. The transportation intelligent agent module is a software agent running on a server or in the cloud, which encapsulates all business logic related to transportation planning, data models (such as train timetable models and section capacity models), and the learned utility function model as described in this invention. It communicates with the scheduling negotiation platform module and the distributed negotiation engine module through APIs or message middleware. Each of the multiple track maintenance intelligent agent modules can be deployed on the server of its corresponding equipment management unit (such as the engineering section or signaling section). Each module is responsible for obtaining information in real time from data sources such as the unit's maintenance management system and equipment health monitoring system, maintaining its own dedicated equipment maintenance constraint knowledge base, and proactively generating structured track maintenance application messages based on plans or alarms, and pushing them to the scheduling negotiation platform module. The scheduling negotiation platform module, as the core hub of the system, is typically deployed on the central server of a region or railway bureau, responsible for request access, task orchestration, global status monitoring, and final plan review and distribution. It implements state machine management, case retrieval, and a natural language constraint processing interface. The distributed negotiation engine module is a lightweight, high-concurrency service component that can be deployed alongside the transportation agent module and the track maintenance agent module, or as an independent service. Under the command of the scheduling negotiation platform module, it instantiates specific negotiation sessions, strictly follows the negotiation process described in this invention (initialization, proposal, evaluation, counter-proposal, convergence check, and equilibrium solution) to coordinate the interaction between the transportation and track maintenance agent modules, and records the complete negotiation trajectory. All these modules work collaboratively, loosely coupled through predefined communication protocols (such as HTTP RESTful APIs or message queues like RabbitMQ / Kafka), collectively forming a complete system capable of intelligent, dynamic, and collaborative scheduling of railway transportation and track maintenance.

[0086] Understandably, the modular architecture of this system clearly defines the responsibilities of each component, resulting in excellent scalability, maintainability, and reliability. The separation of transportation and maintenance agents aligns with the actual organizational structure of railway operation management, facilitating independent maintenance and upgrades of each business department's agent. The scheduling negotiation platform, acting as a centralized coordinator, ensures overall order and consistency. The distributed negotiation engine handles specific negotiation transactions, supporting high-concurrency negotiation sessions and enhancing the overall system processing capacity. This architecture enables the methods described in this invention to be implemented and deployed within a stable, efficient, and scalable software system, thereby transforming advanced scheduling concepts into practical productivity.

[0087] 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 described method for coordinated scheduling of railway transportation and track maintenance. 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.

[0088] 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.

[0089] 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.

[0090] 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.

[0091] 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 collaborative scheduling method for railway transportation and track maintenance windows based on hierarchical multi-agent negotiation, characterized in that, Includes the following steps: S1. Receive the skylight operation application submitted proactively by the skylight operation intelligent agent; S2. The scheduling and negotiation platform dynamically determines the negotiation and scheduling mode based on the coupling relationship between multiple track window operation applications and assigns negotiation tasks to the transportation intelligent agent. S3. The transportation agent and the sunroof operation agent engage in multiple rounds of game negotiation based on their respective maintained local constraint spaces to generate collaborative scheduling candidate schemes. S4. The scheduling and negotiation platform performs global consistency verification on the candidate solutions generated through negotiation, and submits the verified solutions to the decision-making and approval process.

2. The method according to claim 1, characterized in that, The multi-round game negotiation process in step S3 is controlled and executed by a preset negotiation state machine, which includes an initialization state, a proposal state, an evaluation state, a counter-proposal state, a convergence check state, and an equilibrium solution state. The negotiation process is recorded as a structured negotiation trajectory and stored in the case knowledge base.

3. The method according to claim 2, characterized in that, In the proposal and counter-proposal states, a concession decision algorithm based on the Zeuthen criterion is used to determine the conceding party and generate a new proposal. The concession decision algorithm compares the risk willingness indices of both parties, which are calculated based on the difference between the current proposal utility and the break point.

4. The method according to claim 3, characterized in that, In the evaluation state, a constraint space intersection calculation algorithm is used to determine the joint feasible region between the transportation agent and the track maintenance agent. This algorithm is implemented by constructing an interval tree and performing query and intersection operations on the feasible time windows of the track maintenance agent. Specific steps include: 1) Construct the prohibited time windows of the transportation agent as an interval tree, with a time complexity of O(nlogn), where n is the number of prohibited windows; 2) For each feasible time window of the skylight operation agent, use interval tree to query overlapping prohibited time periods. The time complexity of a single query is O(logn+m), where m is the number of overlapping windows. 3) Use a sliding window to find time periods within the feasible time window that meet the job duration requirements and do not conflict with the time period.

5. The method according to claim 4, characterized in that, In the concession decision algorithm based on the Zeuthen criterion, the concession amount of the conceding party is dynamically adjusted according to the current negotiation round using an exponential decay function.

6. The method according to claim 5, characterized in that, The breakdown point is dynamically learned and updated based on the effectiveness of the downgrade schemes of each party in historical negotiation failure cases, and adaptively adjusted in combination with the characteristics of the current scenario during the update.

7. The method according to claim 6, characterized in that, The utility function weights of the transportation agent and the skylight operation agent are derived from historical successful negotiation cases through a maximum entropy-based inverse reinforcement learning algorithm.

8. The method according to claim 7, characterized in that, It also includes the steps of: in response to a new negotiation task, retrieving negotiation cases with similar scenario features from the case knowledge base, and generating an initial proposal based on the negotiation strategies in the retrieved negotiation trajectories.

9. The method according to claim 8, characterized in that, It also includes the steps of: receiving a natural language constraint description input by the scheduler, extracting constraint elements through named entity recognition and dependency parsing, and converting the constraint elements into computable formal constraints based on a preset mapping rule base, which are used to update the local constraint space of the corresponding agent.

10. A railway transportation and track maintenance window collaborative scheduling system based on hierarchical multi-agent negotiation, used to implement the method of any one of claims 1 to 9, characterized in that, include: The transportation agent module is used to maintain the transportation planning constraint space and represent the interests of the transportation sector in negotiations. Multiple intelligent agent modules for skylight maintenance are used to maintain the space constraints for equipment repair and to proactively submit skylight maintenance requests; The scheduling and negotiation platform module is used to receive requests for track maintenance windows, dynamically schedule and negotiate tasks, and perform global consistency verification. The distributed negotiation engine module is used to drive the transportation agent module and the track maintenance agent module to perform multi-round game negotiation.

Images