Automated testing methods and computer program products based on agent-based architecture models

Abstract

This application provides an automated testing method and computer program product based on an agent-based architecture large model. It can automatically generate test cases covering different constraint combinations, encompassing all stations, all directions of travel, and continuously divided time slices. The test cases drive the target urban rail transit scheduling optimization model to pre-calculate passenger demand across all stations and multiple directions within continuously divided time slices, obtaining the required number of trains for the corresponding passenger demand and determining the train set accordingly. Using the test cases and train set as input, it drives train operation scheduling simulation to obtain the scheduling decision variables for each train. Finally, the execution of constraint verification determines whether the test passes. This significantly improves testing efficiency and accuracy, ensuring that the test can meet complex constraints and complex rail transit networks. It possesses an efficient automated problem location and feedback mechanism, making it a core technology for improving the intelligence and optimization capabilities of rail transit scheduling.

Description

Technical Field

[0001] This application relates to the field of urban rail transit technology, specifically to an automated testing method and computer program product based on a large Agent architecture model. Background Technology

[0002] With the rapid development of urban rail transit, optimizing its scheduling, improving operational efficiency, and continuously adjusting to meet optimization goals have become crucial aspects of the transportation sector. Rail transit scheduling optimization involves numerous aspects and presents a highly complex scheduling structure for the entire rail transit network. How to optimize scheduling and automate the testing of these optimizations remains a significant challenge in urban rail transit scheduling optimization.

[0003] For testing the optimization of rail transit scheduling, on the one hand, it involves a very large number of input parameters, and once the input parameters change, a full regression modification is required; on the other hand, the complexity of the rail transit network leads to insufficient coverage of testing scenarios. For both scheduling optimization and its testing, it is difficult to rely on manual testing rule calculations, and it is also difficult to ensure efficient implementation in a large-scale, dynamically changing transportation system.

[0004] Therefore, there is an urgent need to conduct backend testing accurately and promptly for the optimization of scheduling in large-scale and dynamically changing traffic systems. Summary of the Invention

[0005] One objective of this application is to enable accurate and timely backend testing for scheduling optimization of large-scale and dynamically changing transportation systems.

[0006] According to one aspect of the embodiments of this application, an automated testing method based on a large Agent architecture model is disclosed, the method comprising:

[0007] Based on the Agent architecture model, test cases are automatically generated for the target urban rail transit scheduling optimization model to cover different combinations of scheduling constraints, and cover all stations, all directions of travel, and continuous time slices. The test cases are used to construct multi-time slice passenger demand scenarios. The target urban rail transit scheduling optimization model is a calculation model that generates train operation scheduling decision variables based on the urban rail transit network, passenger demand, and operational constraints.

[0008] For the test case, the target city rail transit scheduling optimization model is driven to initiate passenger demand pre-calculation for all stations and multiple travel directions of the target city rail transit in the continuously divided time slots, to obtain the number of trains required for each station in different travel directions and in each time slot corresponding to the passenger demand, and to determine the set of trains to carry the passenger demand in each waiting time slot accordingly.

[0009] Based on the Agent executor's control over the test execution process in the Agent architecture model, the test cases and the train set are input into the train operation scheduling simulation to drive the train operation scheduling simulation to obtain the arrival time of the train at each station and the scheduling decision variables representing the running trajectory.

[0010] The scheduling decision variables are evaluated by the Agent architecture model, and the constraints of the scheduling decision variables are verified for the train services. The results of the constraint verification are used to indicate the test results of the test run of the target urban rail transit scheduling optimization model.

[0011] According to one aspect of the embodiments of this application, a computer program product is disclosed, including a computer program that, when executed by a processor, implements the steps of the method as described in any of the preceding claims.

[0012] This application's embodiments utilize an automated testing method for large-scale models based on an Agent (an executor with autonomous decision-making and learning capabilities) architecture. This method can automatically generate test cases covering different combinations of scheduling constraints, encompassing all stations, all directions of travel, and continuously divided time slices. The test cases drive the target urban rail transit scheduling optimization model to pre-calculate passenger demand across all stations and multiple directions within continuously divided time slices. This yields the required number of trains for each station corresponding to passenger demand in different directions and time slices, and determines the set of trains capable of handling passenger demand. Using the test cases and the set of trains as input, the method drives train operation scheduling simulation execution to obtain the scheduling decision variables for each train. Finally, constraint verification determines whether the test passes. This significantly improves the testing efficiency and accuracy of the target urban rail transit scheduling optimization model, ensuring that the test meets complex constraints and complex target urban rail transit networks. It possesses an efficient automated problem location and feedback mechanism, making it a core technology for improving the intelligence and optimization capabilities of rail transit scheduling.

[0013] Specifically, firstly, this application embodiment automatically generates test cases covering all scenarios, namely different combinations of scheduling constraints, all train directions at all stations, and consecutively divided time slices, ensuring that the test covers all possible situations in the target city's rail transit scheduling optimization model. This comprehensiveness guarantees the integrity of the test, thereby effectively identifying potential defects, reducing the workload of manual testing, and improving the efficiency and accuracy of the test.

[0014] This enables efficient automated testing in large-scale model scenarios. Test cases can be quickly generated and executed in complex scheduling structures involving multiple train directions, departure stations, operating sections, and train services. Ultimately, this ensures that the target urban rail transit scheduling optimization model can continuously improve and approach its optimal state during testing. This mechanism enhances the adaptability and self-adjustment capabilities of the urban rail transit scheduling optimization model, enabling the system to operate stably even under complex constraints.

[0015] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0016] It should be understood that the above general description and the following detailed description are merely exemplary and do not limit this application. Attached Figure Description

[0017] The above and other objectives, features and advantages of this application will become more apparent from a detailed description of exemplary embodiments thereof with reference to the accompanying drawings.

[0018] Figure 1 A flowchart of an automated testing method based on an agent-based architecture large model according to an embodiment of this application is shown.

[0019] Figure 2 It is based on Figure 1 The corresponding embodiment shows a flowchart describing the steps of automatically generating test cases for the target urban rail transit scheduling optimization model based on the Agent architecture, with test coverage targets of different constraint combinations, covering all stations, all directions of travel, and continuously divided time slices.

[0020] Figure 3 It is based on Figure 2 The flowchart in the corresponding embodiment describes the execution process of generating rules for test cases by constructing constraint combinations in step S112.

[0021] Figure 4 It is based on Figure 2The execution process of generating test cases adapted to all scenarios by inputting test case generation rules, environmental information and parameter definition information of the target city rail transit scheduling optimization model into the Agent architecture big model in step S112 of the corresponding embodiment is described in a flowchart of an embodiment.

[0022] Figure 5 It is based on Figure 2 The execution process of generating test cases adapted to all scenarios by inputting test case generation rules, environmental information and parameter definition information of the target city rail transit scheduling optimization model into the Agent architecture big model in step S112 of the corresponding embodiment is described in another embodiment as a method flowchart.

[0023] Figure 6 It is a logic diagram for generating test cases based on a specific example.

[0024] Figure 7 This is a schematic diagram of the interface of the automated testing agent implemented in this application, which is a specific example.

[0025] Figure 8 Based on the urban rail transit scheduling model obtained from testing, and the intelligent operation diagram implemented in this application, the original operation diagram is compared with the existing one. Figure 2 A diagram showing the comparison of indicators between the participants. Detailed Implementation

[0026] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided to make the description of this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art. The drawings are merely illustrative of this application and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted.

[0027] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more exemplary embodiments. Numerous specific details are provided in the following description to give a full understanding of exemplary embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced with one or more of the specific details omitted, or other methods, components, steps, etc., can be employed. In other instances, well-known structures, methods, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0028] Some of the block diagrams shown in the accompanying drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0029] See Figure 1 , Figure 1 A flowchart illustrating an automated testing method for a large model based on an agent architecture according to an embodiment of this application is shown. An embodiment of this application provides an automated testing method for a large model based on an agent architecture, comprising:

[0030] Step S110: Based on the Agent architecture model, test cases are automatically generated for the target urban rail transit scheduling optimization model to cover different combinations of scheduling constraints as the test coverage target, and to cover all stations, all directions of travel and continuous time slices. The test cases are used to construct multi-time slice passenger demand scenarios. The target urban rail transit scheduling optimization model is a calculation model that generates train operation scheduling decision variables based on the urban rail transit network, passenger demand and scheduling constraints.

[0031] Step S120: For test cases, drive the target city rail transit scheduling optimization model to initiate passenger demand pre-calculation for all stations of the target city rail transit in multiple directions of travel in continuously divided time slices, obtain the number of trains required for each station in different directions of travel and in each time slice corresponding to passenger demand, and determine the set of trains to carry passenger demand in each waiting time slice accordingly.

[0032] Step S130: Based on the Agent Execution Body's control over the test execution process in the Agent architecture big model, the test cases and train set are input into the train operation scheduling simulation to drive the train operation scheduling simulation to obtain the arrival time of the train at each station and the scheduling decision variables representing the running trajectory.

[0033] Step S140: The scheduling decision variables are evaluated through the Agent architecture model, and the constraints of the scheduling decision variables are verified for the train numbers. The results of the constraint verification are used to indicate the test results of the test run of the target city rail transit scheduling optimization model.

[0034] This exemplary embodiment will now be described in detail.

[0035] First, it should be clarified that the target city rail transit scheduling optimization model used to optimize the scheduling of the target city rail transit is a computational model that generates the required scheduling decision variables in response to passenger demand. In the embodiments of this application, the computation of the target city rail transit scheduling optimization model in response to passenger demand will be automatically tested. Based on the agent architecture, a large model will be implemented to achieve automated testing with high reliability covering the entire scenario for complex scheduling structures, complex constraints and complex scheduling decision variables.

[0036] The Agent architecture model provided in this application embodiment includes at least a test case generation Agent for executing step S110, a scenario building Agent adapted to the test cases obtained in step S110 to build a scenario, an Agent execution body for driving and controlling the test execution process through test cases, and a constraint verification and evaluation Agent.

[0037] The Agent architecture model's agents work collaboratively to automate the testing of the target city's rail transit scheduling optimization model. This model, a computational model, outputs scheduling decision variables for train operations in response to passenger demand generated at different times along different travel directions from each station.

[0038] In step S110, test cases are generated covering different combinations of scheduling constraints, all stations, each direction of travel, and time slices. The batch-constructed test cases are used to obtain the full test scenario in subsequent scenario construction, and drive the train operation scheduling simulation under each scenario, so as to finally obtain a comprehensive and highly reliable test implementation.

[0039] For example, the target city rail transit scheduling optimization model is configured with numerous constraints, and different combinations of constraints can be constructed based on the dependencies between the decision scheduling variables involved.

[0040] The constraints configured in the target city's rail transit scheduling optimization model include rigid constraints and flexible constraints. Rigid constraints involve immutable constraints related to safety, vehicles, and operations, and are legalized constraints. Flexible constraints include demand constraints. Based on the type of scheduling decision variables involved, the constraints configured in the target city's rail transit scheduling optimization model can be divided into binary variable constraints and continuous variable constraints.

[0041] It should be understood that the constraints of the target city's rail transit scheduling optimization model, whether rigid or flexible, include constraints for binary variables and constraints for continuous variables. In other words, the space of binary and continuous variable constraints covers all rigid and flexible constraints. By configuring the space of binary and continuous variable constraints, the uniformly constructed constraints can be embedded into the computational model of the target city's rail transit scheduling optimization model, thus ensuring that the calculated scheduling decision variables can satisfy the constraints.

[0042] Legalization constraints are constructed based on constraints such as the line structure, station distribution, and available transport capacity of the rail transit network. They are used to provide constraints for decision variables such as optimizing train schedules and the originating and terminating stations of the scheduled trains.

[0043] For all constraints, as illustrated by the example, constraint combinations can be constructed based on the types of scheduling decision variables involved, resulting in combinations of driving interval constraints, arrival and departure time constraints, distance constraints between vehicles, vehicle turn-around constraints, and vehicle scheduling constraints.

[0044] Based on this, the constraints between different constraint combinations can also support each other to construct other constraint combinations, such as constraint combinations used to constrain train number configuration and the management of the operating trains, constraint combinations used to constrain train number operation and stopping scheduling, constraint combinations used to control the coupling of section capacity and train resources, constraint combinations used to implement safe interval control for train arrivals, constraints used to implement mandatory scheduling constraints for fixed train numbers, and constraint combinations used to control train reversal, etc.

[0045] The test cases, which cover different combinations of scheduling constraints and are generated in batches covering all stations, all directions of travel, and continuous time slices, are used to construct structured inputs in the spatial dimension (station / direction / route topology), the temporal dimension (time slice), and the constraint dimension, and will be used as parameters for the constructed scenario.

[0046] See Figure 2 , Figure 2 It is based on Figure 1 The corresponding embodiment shows a flowchart describing the steps of automatically generating test cases for the target urban rail transit scheduling optimization model based on the Agent architecture, with test coverage targets of different constraint combinations, covering all stations, all directions of travel, and continuously divided time slices.

[0047] The agent-based architecture model provided in this application provides step S110 for automatically generating test cases for the target urban rail transit scheduling optimization model, with different constraint combinations as the test coverage target, covering all stations, all directions of travel, and continuously divided time slices. This includes:

[0048] Step S111: Analyze all constraints configured in the target city rail transit scheduling optimization model, identify the dependencies between each constraint and the scheduling decision variables, implement constraint combinations based on the dependencies, and generate multiple sets of constraint combinations with correlation coverage.

[0049] Step S112: Construct test case generation rules for constraint combinations, and input the test case generation rules, environmental information and parameter definition information of the target urban rail transit scheduling optimization model into the Agent architecture big model as context to generate test cases adapted to all scenarios, including positive scenarios, boundary scenarios and abnormal scenarios.

[0050] The following is a detailed explanation of these two steps.

[0051] In step S111, constraint parsing and construction of associated covering constraint combinations are performed. First, the target urban rail transit scheduling optimization model is parsed and semantically extracted to identify all configured constraints, and the dependency relationship between each constraint and scheduling decision variables is determined.

[0052] For the target urban rail transit scheduling optimization model, constraints are extracted from the configured constraint expressions, including but not limited to: departure interval constraints, minimum turnaround time constraints, and passenger demand constraints. Each constraint expression has at least one scheduling decision variable. The dependency relationship between constraints and scheduling decision variables is constructed by identifying the scheduling decision variables in the constraint expressions.

[0053] In an exemplary embodiment, to facilitate calculation and processing, in the execution of step S111, a constraint-decision variable dependency graph is constructed based on the scheduling decision variables involved in the constraint expression. The nodes in the graph represent constraints or scheduling decision variables, and the edges represent the relationship between constraints and scheduling decision variables. This identifies strongly coupled constraint combinations, chained constraint paths, and key bottleneck variables, and then enables them jointly. Constraints related to key bottleneck variables are preferentially combined, and constraint combinations are constructed along chained constraint paths. By doing so, multiple sets of constraint combinations with correlation coverage can be constructed. Each constraint combination corresponds to a testable scenario. In this way, the combination explosion problem caused by simple enumeration can be avoided, while ensuring that key constraint relationships are covered, thus improving the effectiveness of testing.

[0054] In step S112, after obtaining the constraint combination, in order to make the test cases executable and scenario-diverse, test case generation rules are constructed for each constraint combination, and test cases are automatically generated through the Agent architecture big model.

[0055] Specifically, for each constraint combination, corresponding test case generation rules are generated. These rules include: station scope rules (full station or partial section), travel direction coverage rules (up / down), time slice granularity rules, resource disturbance rules (train resource constraints, warehouse constraints), and parameter boundary rules (minimum interval, etc.). The test case generation rules generated for each constraint combination will be used to generate the corresponding test cases for that constraint combination.

[0056] In addition to generating corresponding test case generation rules for each constraint combination, context construction will also be performed. The environmental information and parameter definition information of the target city rail transit scheduling optimization model will be used as context inputs. The environmental information includes the target city rail transit network topology information, line length and interval running time, station distribution parameters, train passenger capacity, etc.

[0057] This will generate test cases in batches under the test case generation rules and context, and the generated tests will cover all scenario types, such as positive scenarios with normal passenger flow distribution, boundary scenarios with minimum intervals, and abnormal scenarios limited by interval capacity or warehouses.

[0058] Test cases corresponding to a scenario will be used to construct the corresponding scenario, and then to perform pre-calculation of passenger demand for this scenario, and determine the set of train services that can carry the passenger demand, so as to facilitate simulation testing.

[0059] Therefore, under the action of steps S111 and S112, a series of execution processes, including constraint parsing, combination construction, and rule-driven execution, are linked together into an automated execution loop. This enables test cases to achieve systematic coverage starting from the model, rather than being constructed manually based on experience. This significantly improves the comprehensiveness and relevance of the scenarios, greatly reduces test design costs, and increases test efficiency.

[0060] See Figure 3 , Figure 3 It is based on Figure 2 The flowchart in the corresponding embodiment describes the execution process of generating rules for test cases by constructing constraint combinations in step S112.

[0061] The execution process of constructing test case generation rules for constraint combinations in step S112 provided in this application embodiment includes:

[0062] Step S201: Recall the standard test case generation rules related to the generation of test cases for the target city's rail transit scheduling optimization model;

[0063] Step S202: Constraint transformation rules are extracted from the constraint combination of the target city rail transit scheduling optimization model. The constraint transformation rules and the recalled standard use case generation rules form test case rules.

[0064] Standard use case generation rules are pre-built. When testing the target city rail transit scheduling optimization model, the Agent will recall the standard use case generation rules that match the target city rail transit scheduling optimization model.

[0065] For example, standard use case generation rules include, but are not limited to: passenger flow generation rules, time slice construction rules, and runtime constraint pressure rules. Among them, passenger flow generation rules are used to construct passenger demand under different scenarios, such as evenly distributed passenger demand and tidal passenger demand during morning and evening peak hours, while runtime constraint pressure rules are used to standardize the construction of scenario boundaries.

[0066] For the target urban rail transit scheduling optimization model to be tested, standard test case generation rules are matched based on the involved line rules, number of stations, and constraint combinations to recall standard test case generation rules that match this target urban rail transit scheduling optimization model. The recalled standard test case generation rules will serve as the basic template for subsequent test case generation.

[0067] To enable test cases to specifically trigger or cover constraints in a constraint combination, the corresponding constraint expressions need to be converted into constraint transformation rules that can drive the generation of test data.

[0068] In the constraint transformation rule generation performed in step S202, the constraint expression in the constraint combination is first parsed to extract the constraint object, scheduling decision variable, parameter threshold and mathematical relationship to form parameter definition information for constructing context. For example, the constraint object refers to any one or combination of the station, section, train number and time slot that the constraint applies to.

[0069] In addition to extracting constraint expressions, the constraint expressions will be transformed into constraint transformation rules. Finally, the standard test case generation rules for context and recall and the constraint transformation rules will be integrated to serve as input for the Agent architecture model, forming executable description files and configuration scripts, which are the test cases. These are used to drive the simulation and operation of the target city rail transit scheduling optimization model, effectively supporting automated testing of all scenarios and multiple constraint combinations.

[0070] In another exemplary embodiment, before step S112 is executed, parameter definition information is also generated for the target city rail transit scheduling optimization model.

[0071] Specifically, the process of generating parameter definition information includes: generating parameter definition information for the target city rail transit scheduling optimization model based on the input parameters defined in the target city rail transit scheduling optimization model and the scheduling decision variables to be output. Input parameters include name, type, whether they are required, and their own specific restrictions. For example, the specific restrictions of the input parameters themselves include format and value range, etc., which will not be listed one by one here.

[0072] For further details, please refer to [link / reference]. Figure 4 , Figure 4 It is based on Figure 2 The execution process of generating test cases adapted to all scenarios by inputting test case generation rules, environmental information and parameter definition information of the target city rail transit scheduling optimization model into the Agent architecture big model in step S112 of the corresponding embodiment is described in a flowchart of an embodiment.

[0073] Step S112, which uses test case generation rules, environmental information of the target city rail transit scheduling optimization model, and parameter definition information as context inputs to the Agent architecture model to generate test cases adapted to all scenarios, includes the following execution process:

[0074] Step S301: Based on the parameter definition information, determine the input parameters marked as mandatory for the target city rail transit scheduling optimization model;

[0075] Step S302: Combine all input parameters marked as required to obtain an input parameter combination suitable for each scenario.

[0076] Step S303: Using the test case generation rules and environment information as context, generate test cases suitable for all scenarios for each combination of input parameters according to the defined format and function call mechanism.

[0077] This exemplary embodiment realizes the automatic batch generation of test cases. The target urban rail transit scheduling optimization model has a large number of input parameters, and therefore there are many possible combinations, especially for the required fields. Therefore, it is necessary to test all possible cases to ensure robustness.

[0078] First, based on the parameter definition information, obtain all input parameters marked as required. It should be understood that for solving the target city rail transit scheduling optimization model, if there are no input parameters marked as required, it will return errors or fail to work during its operation. Therefore, the parameters that maintain the normal operation of the calculation model must be included in the test cases generated for each scenario.

[0079] For each input parameter marked as required, equivalence classes are expanded one by one. Each input parameter marked as required has a set of equivalence classes obtained from the partitioning, that is, similar input parameters.

[0080] To further explain, the equivalence class obtained for an input parameter includes at least valid input parameters and invalid input parameters, thereby providing valid input, too short input, too long input, and null input for the test, etc., which will not be listed here.

[0081] Once the equivalence class partitioning is complete, the input parameters for test cases can be generated, which are the combinations of equivalence classes between each input parameter. Then, the different values ​​of all equivalence classes are combined into complete test implementations, thus obtaining test cases for normal scenarios and various abnormal scenarios.

[0082] See Figure 5 , Figure 5 It is based on Figure 2 The execution process of generating test cases adapted to all scenarios by inputting test case generation rules, environmental information and parameter definition information of the target city rail transit scheduling optimization model into the Agent architecture big model in step S112 of the corresponding embodiment is described in another embodiment as a method flowchart.

[0083] Step S112, which uses test case generation rules, environmental information of the target city rail transit scheduling optimization model, and parameter definition information as context inputs to the Agent architecture model to generate test cases adapted to all scenarios, includes the following execution process:

[0084] Step S401: Determine whether the input parameters marked as required have a defined enumeration;

[0085] Step S402: If all input parameters are not enumerated, generate positive use cases for default parameters to adapt to the positive scenario.

[0086] Step S403: If there is an input parameter that defines an enumeration, then obtain the enumeration value for the input parameter that defines the enumeration.

[0087] Step S404: Using the obtained enumeration values ​​and the combination of input parameters adapted to each scenario, test cases adapted to all scenarios are generated in accordance with the limited format and function call mechanism, with the test case generation rules and environment information as the context.

[0088] In this exemplary embodiment, test cases are generated by enumerating input parameters. When an input parameter marked as required has an enumerated value defined, test cases can be generated by combining these enumerated values.

[0089] Furthermore, the enumerated values ​​and Figure 4 The equivalence classes shown in the corresponding embodiments will also be combined, and test cases will be generated for each combination. This increases scenario coverage performance and improves testing efficiency and reliability. Figure 6 As shown, this method will be based on N X group parameters generate N X use cases.

[0090] After generating test cases in batches through step S110, the passenger demand for all stations in multiple directions of travel in the scenario constructed by the test cases can be pre-calculated during the execution of step S120. The required number of trains corresponding to the passenger demand at each station in different directions of travel and at each time slot is obtained, and the set of trains used to carry the passenger demand is determined accordingly in each waiting time slot.

[0091] In the target city's rail transit network, the operation of each station is also divided into several consecutive time slots. These time slots, in terms of passengers and the resulting passenger flow, are called waiting time slots. During the waiting time slots, the station determines the required number of trains for different directions of travel. The required number of trains represents the passenger demand for each direction of travel within the waiting time slot at that station.

[0092] The required number of trains mapped to stations, directions of travel, and waiting time slots serves two purposes: firstly, to quantify passenger demand, and secondly, to indicate the number of trains needed to carry passenger flow at the mapped stations, directions of travel, and waiting time slots.

[0093] Passenger demand, as a personalized scheduling requirement, will be embedded in the scheduling optimization, thereby enabling the operation scheduling implemented by the target city rail transit scheduling optimization model to meet the passenger flow carrying capacity requirements of each station in each waiting time slot.

[0094] In order to adapt to the passenger demand generated by each train direction in each waiting time slot at each station during operation scheduling, it is first necessary to perceive and quantify the passenger demand, that is, to pre-calculate the passenger demand and obtain the required number of trains to represent the passenger demand. In an exemplary embodiment, the required number of trains determined by the station for different train directions in the waiting time slot is used to represent the passenger demand corresponding to each train direction in the waiting time slot at that station.

[0095] This calculation is performed at each station and within the consecutive time slots defined at each station. This yields the number of trains required at each station in different directions and time slots. Specifically, it represents the number of trains required at each station in each waiting time slot. The number of trains required at a station within a waiting time slot indicates the passenger demand at that station in the corresponding waiting time slot and direction. For example, for a single train line, the direction of travel often includes both up and down directions, but it is not limited to these. For train lines with extensions, branch lines, turnaround sections, or multiple branch structures, the direction of travel also includes the direction of travel along the extension, branch, or branch section.

[0096] In one exemplary embodiment, the pre-calculation of the required number of trains includes: first, aligning historical passenger flow data at stations and time slots for consecutively divided time slots after time discretization to obtain historical passenger flow data for each station in each consecutively divided time slot; then, splitting the historical passenger flow data for each station in each consecutively divided time slot according to the direction of travel to calculate the historical passenger flow for each station in each time slot along different directions of travel; finally, based on the historical passenger flow for each station in each consecutively divided time slot along the direction of travel, predicting the number of passengers for each station in the corresponding time slot and direction of travel, and converting it into the required number of trains.

[0097] In this exemplary embodiment, historical passenger flow data can come from the turnstiles, that is, the entry data of each station with a time stamp is used as historical passenger flow data. In addition, OD data (Origin-Destination Data) will be incorporated to determine the passenger flow of each station in each waiting time slot corresponding to the driving line and driving direction, thereby adapting to the complex scheduling structure under multiple lines and multiple driving directions, and accurately determining the passenger flow generated by each station in each driving direction in each time slot.

[0098] It should be understood that OD data, or OD data combined with arrival data, allows for the determination of passenger flow corresponding to the direction of travel in each waiting time slot at each station. For example, OD data describes passenger travel behavior from the originating station to the destination station. OD data includes at least the arrival station, departure station, arrival time, and departure time. The arrival time can be mapped to a time slot, and the arrival and departure stations are mapped to the travel route and the direction of travel along that route. Therefore, the passenger will be part of the passenger flow at that arrival station in the mapped time slot and direction of travel. Similarly, the historical passenger flow at a station corresponding to the travel route and direction of travel in each waiting time slot can be determined.

[0099] Based on the exit stations indicated in the historical passenger flow data, the assigned driving direction is determined; for the historical passenger flow data of each station in each consecutive time segment, the historical passenger flow data is classified and statistically analyzed according to the determined driving direction to obtain the historical passenger flow of each station along the driving direction in each time segment.

[0100] The historical passenger flow for each station is classified and statistically analyzed for the corresponding driving direction and time slot. The passenger count, and even the net flow, i.e. the number of passengers boarding, are obtained through statistical analysis.

[0101] Historical passenger flow is statistically analyzed for each station according to its corresponding travel direction and time slot. The number of passengers obtained from the statistics, or the net passenger flow obtained through further calculation, is used as the historical passenger flow of the station along the travel direction in the time slot. The net passenger flow is the difference between the number of passengers boarding and alighting at the station within the time slot.

[0102] For each time slot continuously divided by a station, the historical passenger flow in each direction of travel is predicted based on spatiotemporal characteristics to determine the number of passengers traveling in the corresponding direction of travel at that station during this time slot. The predicted number of passengers traveling in the corresponding direction of travel at that station during this time slot, along with the carrying capacity of a single train, is used to convert the predicted number of passengers into the required number of trains. The carrying capacity of a single train is determined by the target passenger load factor of the target urban rail transit system and the rated passenger capacity of the train.

[0103] In this exemplary embodiment, the spatiotemporal features include temporal features and spatial features. The temporal features include lag windows (past time slices), weekdays / hours / whether it is a holiday, and event identifiers. The spatial features include weather and neighboring station traffic, which will not be listed here.

[0104] The carrying capacity of a single train depends on the operational objectives. It should be understood that the carrying capacity of a single train is determined by the target load factor of the target urban rail transit system and the train's rated passenger capacity; that is, the product of the target load factor and the train's rated passenger capacity. If the operational objective is passenger experience, the carrying capacity of a single train will be reduced by controlling the target load factor, thereby increasing the number of trains. This ensures that passengers do not fill the entire train's capacity while still managing to transport the resulting passenger flow.

[0105] If the operational objective is to reduce operating costs, then the carrying capacity of a single train can be increased by improving the target occupancy rate, thereby ensuring that every train passing through is as full as possible.

[0106] After determining the carrying capacity of a single train in accordance with the operational objectives, the required number of trains can be obtained by calculating the quotient between the number of passengers at the station along the direction of travel in this time slice and the carrying capacity of a single train.

[0107] For a train's stop at a given station, that train is considered a transit train at that station. Based on the train's arrival time at the station, the waiting time slot into which the arrival time falls is first determined. This waiting time slot is then used as the basis for matching passenger demand with trains within that waiting time slot to determine the trains that meet the passenger demand. By repeating this process, a set of trains covering the corresponding travel direction for each waiting time slot at each station can be generated.

[0108] Based on the train numbers passing through each station and the waiting time slots to which the trains arrive at the station, a train arrival variable is established for each train at that station. The train arrival variable indicates the waiting time slot in which the trains arrive at the station in a specific direction. The waiting time slots are matched with the trains based on the train arrival variable for that station, and the trains are assigned to the waiting time slots to which their arrival times belong. In each direction of travel, the trains that match the required number of trains are selected as the set of trains to meet the passenger demand at the station in the corresponding waiting time slot.

[0109] For example, constructing train number and arrival station variables. By train number and arrival station variable The assignment of values ​​is used to allocate train numbers to waiting time slots, thereby matching train numbers with waiting time slots and determining the train numbers that will meet the passenger demand in the waiting time slots on this travel direction.

[0110] Furthermore, the arrival time of each train can be used as a reference to allocate trains to waiting time slots, thereby assigning values ​​to the corresponding train arrival variables. Each potential train, i.e., a train that may run, has a corresponding arrival time at each station it passes through. Based on the matching between train arrival times and passenger waiting time slots in each direction of travel, the matching between trains passing through each station in that direction of travel and waiting time slots is achieved, thereby determining the trains used to meet passenger demand in that direction of travel during the waiting time slots.

[0111] Therefore, based on the arrival time of each train, the arrival time of each train at the stations it passes through is determined, and the arrival time of the train at each station is established according to the arrival time of the train at each station.

[0112] In other words, based on the constraints of the required number of trains corresponding to the station's direction of travel and time slot, the train arrival variable is adjusted. The resulting train arrival variable indicates the train that arrives at station i in time slot t for the corresponding route and direction of travel. The train arrival variable achieves the matching of pre-calculated passenger demand to train numbers, thus enabling the construction of a system based on the constructed train arrival variable. The indicated train route is lno, the direction of travel is dir, and the train number k departs from the originating station m. Its arrival time at station i will fall into the waiting time slot t, and it will carry passenger flow during the waiting time slot t.

[0113] Therefore, for station i, for each direction of travel dir, the set of trains to accommodate passenger demand is determined within the corresponding waiting time slice t based on the established train arrival variables. For each train k included in this set, its train arrival variable... The value assigned is 1.

[0114] Once the set of train services is determined, a train operation scheduling simulation for the corresponding scenario can be implemented based on the determined set of train services, as in step S130. This process yields the arrival times of the trains at each station and the decision variables representing the operating trajectories, such as stop indication variables and train interval variables, obtained from the train operation scheduling simulation of the determined set of train services in the corresponding scenario. Then, the train arrival variables, train departure variables, and train interval variables mapped by the set of train services are entered into step S140 to perform constraint verification of the scheduling decision variables involved in the train services, in order to verify whether the scheduling decision variables satisfy all constraints of the constraint combination. If all constraints are satisfied, the automated test for the corresponding scenario passes.

[0115] In an exemplary embodiment, the execution process of step S140 includes: verifying the obtained scheduling decision variables by using the Agent architecture large model to verify the combination of constraints configured for each test case, and using the obtained constraint verification structure that passes all constraint verifications to indicate the test result of the target city rail transit scheduling optimization test run passing.

[0116] For the obtained scheduling decision variables, i.e., the scheduling decision variables generated under each test case, constraint verification is performed. The combination of constraints of the test cases constitutes the constraint verification list currently in use. The Agent executor in the Agent architecture model performs constraint verification on the constraint verification list item by item. During the verification process, if a constraint verification fails, a readable exception report and location description are generated to assist in the improvement of the target city rail transit scheduling optimization model. If all constraint verification results are passed, a verification result of all constraint verifications passing is generated, and it is determined that the scheduling optimization model test run corresponding to the current test case has passed.

[0117] If any constraint is not met, the test will be deemed a failure, and the corresponding test results will be output to evaluate the correctness, stability, and feasibility of the proposed urban rail transit scheduling optimization model.

[0118] The application of this application will be illustrated below with a specific implementation example.

[0119] See Figure 7 , Figure 7This is a schematic diagram illustrating the interface of the automated testing agent implemented in this application, as a specific example. It should be understood that the target urban rail transit scheduling optimization model to be tested will be uploaded through this interface, enabling the automatic generation of test cases and the automatic execution of tests. The success rate of the obtained test results will be displayed in a list on this interface, along with a corresponding report download button.

[0120] This will make the testing of urban rail transit scheduling optimization models, which involve massive data volumes, long business chains, complex calculations, and near-zero fault tolerance, observable and efficient.

[0121] Figure 8 Based on the target city rail transit scheduling optimization model obtained from testing, and based on the intelligent operation diagram implemented in this application and the original operation... Figure 2 A comparative diagram of indicators between the two systems is provided. Based on the intelligent operation diagram implemented in this application, compared to the currently used original operation diagram, significant reductions have been achieved in the number of trips, total network operating distance, parts wear and tear, number of vehicles used, and number of drivers, thereby significantly reducing operating costs. Under the same maximum passenger capacity and maximum waiting time conditions, the maximum waiting time remains essentially unchanged (controlling the worst-case experience), while energy consumption (equivalent to operating mileage and parts wear and tear) decreases by 13.24% and the number of trips decreases by 17.19%.

[0122] In one exemplary embodiment, this application also provides a computer device including a memory, a processor, and a computer program stored in the memory, the processor executing the computer program to implement the steps of the method as described above.

[0123] In one exemplary embodiment, this application also provides a computer program product including a computer program that, when executed by a processor, implements the steps of the method as described above.

[0124] In one exemplary embodiment, this application also provides a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the steps of the method as described above.

[0125] Furthermore, although the steps of the method in this application are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0126] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the appended claims.

Claims

1. An automated testing method based on a large agent architecture model, characterized in that, The Agent architecture model includes at least a test case generation Agent, a scenario construction Agent that adapts the obtained test cases to build scenarios, an Agent execution body, and a constraint verification and evaluation Agent. The method includes: For the target urban rail transit scheduling model to be tested, constraints are extracted from the configured constraint expression. The constraints are combined with the dependencies of the scheduling decision variables to construct constraint combinations. Based on the Agent architecture model, test cases are automatically generated for the target urban rail transit scheduling optimization model to cover different combinations of scheduling constraints as the test coverage target, and to cover all stations, all directions of travel, and continuous time slices. The test cases are used to construct multi-time-slice passenger demand scenarios corresponding to a combination of constraints. The target urban rail transit scheduling optimization model is a calculation model that generates train operation scheduling decision variables based on the urban rail transit network, passenger demand, and operation constraints. The target city rail transit scheduling optimization model is driven to initiate passenger demand pre-calculation for all stations and multiple travel directions of the target city rail transit in the continuously divided time slots. For the multi-time slot passenger demand scenario constructed by the test case, the number of passengers at each station corresponding to the time slot and travel direction is predicted. Based on the carrying capacity of a single train, the number of passengers is converted into the number of trains required at the station in the travel direction and time slot corresponding to the passenger demand. Based on this, the set of trains used to carry the passenger demand is determined in each waiting time slot. The set of trains is used as the input for train operation scheduling simulation. Based on the control of the test execution process by the Agent executor in the Agent architecture model, the test cases and the set of train numbers are input into the train operation scheduling simulation based on the target city rail transit scheduling model to drive the train operation scheduling simulation to obtain the arrival time of the train at each station and the scheduling decision variables that characterize the running trajectory. The scheduling decision variables are evaluated through the Agent architecture model, and the constraint combination configured by the test cases is used to verify the scheduling decision variables of the train. The constraint verification results are used to indicate the test results of the target urban rail transit scheduling optimization model test run.

2. The method according to claim 1, characterized in that, The time slot is a waiting time slot, and the number of trains required by the station for different directions of travel during the waiting time slot is used to characterize the passenger demand of the station for each direction of travel within the waiting time slot.

3. The method according to claim 1, characterized in that, The agent-based architecture model automatically generates test cases for the target urban rail transit scheduling optimization model, covering different combinations of constraints and encompassing all stations, all directions of travel, and continuously divided time slices. These test cases include: All constraints of the target city rail transit scheduling optimization model are analyzed and configured, the dependencies between each constraint and the scheduling decision variables are identified, and constraint combinations are implemented according to the dependencies to generate multiple sets of constraint combinations with correlation coverage. Test case generation rules are constructed based on the constraint combination, and the test case generation rules, environmental information and parameter definition information of the target urban rail transit scheduling optimization model are used as context inputs to the Agent architecture big model to generate test cases adapted to all scenarios, including positive scenarios, boundary scenarios and abnormal scenarios.

4. The method according to claim 3, characterized in that, The rule for generating test cases by constructing the constraint combination includes: Recall the standard test case generation rules related to the generation of test cases for the target city's rail transit scheduling optimization model; Constraint transformation rules are extracted from the constraint combination of the target city rail transit scheduling optimization model. The constraint transformation rules and the recalled standard test case generation rules form test case rules.

5. The method according to claim 3, characterized in that, Before generating test cases adapted to all scenarios by inputting the test case generation rules, environmental information and parameter definition information of the target city rail transit scheduling optimization model into the Agent architecture big model as context, the method further includes: The parameter definition information of the target city rail transit scheduling optimization model is generated based on the input parameters defined in the target city rail transit scheduling optimization model and the scheduling decision variables to be output. The input parameters include name, type, whether they are required, and their specific limitations.

6. The method according to claim 5, characterized in that, The process of inputting the test case generation rules, environmental information, and parameter definition information of the target city rail transit scheduling optimization model into the Agent architecture model as context to generate test cases adapted to all scenarios includes: Based on the parameter definition information, the input parameters marked as mandatory are determined for the target city rail transit scheduling optimization model; All input parameters marked as required are combined with each other to obtain input parameter combinations suitable for each scenario; Using test case generation rules and environmental information as context, test cases adapted to all scenarios are generated for each combination of input parameters according to a defined format and function call mechanism.

7. The method according to claim 6, characterized in that, The process of inputting the test case generation rules, environmental information, and parameter definition information of the target city rail transit scheduling optimization model into the Agent architecture model as context to generate test cases adapted to all scenarios includes: Determine whether the input parameters marked as required have a defined enumeration. If all input parameters are not enumerated, then default to the positive use cases of the parameters to adapt to the positive scenario.

8. The method according to claim 7, characterized in that, The process of using the test case generation rules, environmental information, and parameter definition information of the target city rail transit scheduling optimization model as context inputs to the Agent architecture big model to generate test cases adapted to all scenarios also includes: If an input parameter defines an enumeration, then retrieve the enumeration value for the input parameter that defines the enumeration. By acquiring enumerated values ​​and combining input parameters adapted to each scenario, test cases adapted to all scenarios are generated in accordance with the test case generation rules and environment information, following the defined format and function call mechanism.

9. The method according to claim 1, characterized in that, The evaluation of scheduling decision variables through the Agent architecture model, and the constraint verification of scheduling decision variables for the train services, with the resulting constraint verification results used to indicate the test results of the target urban rail transit scheduling optimization model test run, including: The large model of the Agent architecture verifies the constraint combinations configured for each test case on the obtained scheduling decision variables. The constraint verification results where all constraints pass are used to indicate the test results of the target city rail transit scheduling optimization model.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1-9.

Images