Systems and methods for test scenario generation in train operations

Abstract

Methods for generating train test scenarios and corresponding systems and computer-readable mediums. A method includes identifying train logs corresponding to a conflict between trains. The method includes identifying, from the train logs, trains that are involved in the conflict and identifying messages of specific types in the train logs. The method includes ordering the identified messages to produce a test scenario corresponding to the conflict and validating the test scenario in a simulation to determine whether the conflict has occurred. The method includes, when the computer system determines that the conflict has not occurred in the test scenario, then adding and / or removing messages from the test scenario and repeating the ordering and validating steps. The method includes, when the computer system determines that the conflict has occurred in the validated test scenario, storing the test scenario for use in testing a train planning system.

Description

SYSTEMS AND METHODS FOR TEST SCENARIO GENERATION IN TRAIN OPERATIONSTECHNICAL FIELD

[0001] The present disclosure is directed, in general, to systems and methods for generating test scenarios for planning train operations.BACKGROUND OF THE DISCLOSURE

[0002] Train planning systems (TPS) are used to dispatch and control train operations. Significant TPS functions include timetable management, runtime calculation, conflict detection and resolution, new operational planning, etc. These functions need to be sufficiently performant for the dispatcher to provide a new plan, detect conflicts, and see current train positions and forecasts in “real-time.” While most operations are prescheduled and pre-planned, unforeseen events can require ad hoc dispatching or routing to maintain schedules, avoid delays, and avoid causing a “domino effect” of additional issues. It can be helpful to execute test scenarios in a TPS to reveal performance issues with a TPS function such as conflict detection and resolution. Systems and methods for developing such test scenarios are desirable.SUMMARY OF THE DISCLOSURE

[0003] Various disclosed embodiments include systems and methods for generating train test scenarios. A disclosed method can be performed by a computer system and includes identifying train logs corresponding to a conflict between trains. The method includes identifying, from the train logs, trains that are involved in the conflict and identifying messages of specific types in the train logs. The method includes ordering the identified messages to produce a test scenario corresponding to the conflict and validating the test scenario in a simulation to determine whether the conflict has occurred. The method includes, when the computer system determines that the conflict has not occurred in the test scenario, then adding and / or removing messages from the test scenario and repeating the ordering and validating steps. The method includes, when the computer system determines that the conflict has occurred in the validated test scenario, storing the test scenario for use in testing a train planning system.

[0004] Some embodiments also include generating a temporal scale map corresponding to the validated test scenario.

[0005] In various embodiments, adding and / or removing messages from the test scenario includes creating a dependency map of messages. In various embodiments, adding and / or removing messages from the test scenario includes identifying messages that have an impact on a train.

[0006] In various embodiments, identifying messages of a specific type is performed by an analyzer component. In various embodiments, ordering the identified messages is performed by an analyzer component and a permutator component. In various embodiments, validating the test scenario in a simulation is performed by scenario validator component.

[0007] Some embodiments also include receiving freeze data and using the freeze data to identify the train logs in which the conflict is detected.

[0008] In various embodiments, the messages of specific types include Type 1 messages that are messages that have a direct relation to a train. In various embodiments, the messages of specific types include Type 2 messages that are messages that indirectly impact a train.

[0009] In various embodiments, adding and / or removing messages from the test scenario, and repeating the ordering and validating steps, includes identifying Type 3 messages that have an impact on a train but a dependency or impact on the train is not easily resolvable.

[0010] Some embodiments include a computer system having a processor and an accessible memory, particularly configured to perform processes as disclosed herein. Some embodiments include a non-transitory computer-readable medium encoded with executable instructions that, when executed, cause one or more computer systems to perform processes as disclosed herein.

[0011] The foregoing has outlined rather broadly the features and technical advantages of the present disclosure so that those skilled in the art may better understand the detailed description that follows. Additional features and advantages of the disclosure will be described hereinafter that form the subject of the claims. Those skilled in the art will appreciate that they may readily use the conception and the specific embodiment disclosed as a basis for modifying or designing other structures for carrying out the same purposes of the present disclosure. Those skilled in the art will also realize that such equivalent constructions do not depart from the spirit and scope of the disclosure in its broadest form.

[0012] Before undertaking the DETAILED DESCRIPTION below, it may be advantageous to set forth definitions of certain words or phrases used throughout this patent document: the terms “include” and “comprise,” as well as derivatives thereof, mean inclusion without limitation; the term “or” is inclusive, meaning and / or; the phrases “associated with” and “associated therewith,” as well as derivatives thereof, may mean to include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicable with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, or the like; and the term “controller” means any device, system or part thereof that controls at least one operation, whether such a device is implemented in hardware, firmware, software or some combination of at least two of the same. It should be noted that the functionality associated with any particular controller may be centralized or distributed, whether locally or remotely. Definitions for certain words and phrases are provided throughout this patent document, and those of ordinary skill in the art will understandthat such definitions apply in many, if not most, instances to prior as well as future uses of such defined words and phrases. While some terms may include a wide variety of embodiments, the appended claims may expressly limit these terms to specific embodiments.BRIEF DESCRIPTION OF THE DRAWINGS

[0013] For a more complete understanding of the present disclosure, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, wherein like numbers designate like objects, and in which:

[0014] Figure 1 illustrates a block diagram of a computer system in which an embodiment can be implemented;

[0015] FIG. 2 illustrates a test scenario generation system in accordance with disclosed embodiments;

[0016] FIG. 3 illustrates a flowchart of a process in accordance with disclosed embodiments;

[0017] FIG. 4 illustrates an example of message dependency in accordance with disclosed embodiments; and

[0018] FIG. 5 illustrates an example of time delay and temporal scale computation in accordance with disclosed embodiments.DETAILED DESCRIPTION

[0019] FIGURES 1 through 5, discussed below, and the various embodiments used to describe the principles of the present disclosure in this patent document are by way of illustration only and should not be construed in any way to limit the scope of the disclosure. Those skilled in the art will understand that the principles of the present disclosure may be implemented in any suitably arranged device. The numerous innovative teachings of the present application will be described with reference to exemplary non-limiting embodiments.

[0020] Train planning systems are typically real-time distributed event systems that can be used for ad-hoc dispatching trains in case of unforeseen events that would otherwise cause delays. In such cases, the dispatchers can plan or replan trains while considering the current railroad network operations. The dispatcher decisions are translated into train messages for communication with train control and scheduling applications. Train messages are dependent on the order they are sent. For example, a train plan must first be authorized first before it is be instantiated.

[0021] TPS functions provided to a dispatcher can include timetable management, runtime calculation, conflict detection, and conflict resolution (which can be manual, semi-automatic, or automatic) and creation of a new operational plan.

[0022] Each of the above-mentioned functions must be efficient and effective for the dispatcher to provide a new plan, detect conflicts, and to see current train positions and forecasts in real-time. Conflict detection can be the critical function of the system since train collisions can potentially occur if these conflicts are not resolved on time. There is a large amount of operation data (hundreds of trains, infrastructure, etc.) and the system must project train positions leek hours ahead in order to detect a conflict.

[0023] TPS systems can be realized as rule-based systems which utilize a rule inference engine to detect conflicts. The large amount of operation data results in a vast number of rule-based constraints. The more constraints required to be resolved by the rule inference engine, the more likely it is that the system runs into performance bottlenecks. The goal of testing is to create test train scenarios with conflicts that need to be resolved by the TPS to reveal any performance issues.

[0024] Train scenarios with conflicts are currently only available from recorded realtime operation data (also called freeze data). One set of freeze data is generally limited to a certain time window of X hours being recorded. Multiple batches of freeze data can be recorded. Each set of freeze data acts as a “snapshot” of the train system state and messages for a specific time window.

[0025] However, those freeze data cannot be easily modified and replayed as test scenarios for several reasons. The freeze data does not represent a complete scenario of train messages as starting and ending messages of a train plan can be outside the time window of a specific set of freeze data. Each message contains real-time dates and times which become obsolete. The freeze data contains messages that are not even relevant to a given train plan. In a given set of freeze data, there may be no direct relationship between the included messages and the trains being impacted.

[0026] Current approaches do not enable one to create a valid test scenario with regard to real- world conditions. Further, current approaches are unable to generate test scenarios from real-time data that will detect non- functional requirement bottlenecks of an underlying system function, such as performance bottlenecks for conflict detection in TPS.

[0027] One approach is to construct test scenarios manually based on the test engineer’s domain knowledge. However, these scenarios are too simplistic to be able to identify performance issues in the system. For example, two trains - T1 and T2 can be created which run on different track profiles. A conflict can be induced at some point in time when T1 meets T2. Such scenarios are good for functional testing but are too simplistic in nature and do not reflect the complexity of real world scenarios. Hence it is important to generate scenarios from real-time data.

[0028] Another approach is to use a simulation tool that can replay real-time data to identify performance issues with the system, but these approaches have the same issues as described above related to freeze data. This approach also fails to provide additional information on system performance and is very time-consuming.

[0029] Other manual approaches are time-consuming as well since it is almost impossible to identify all data objects (also referred to as messages) and theirdependencies that affect the system behavior. Typically, a user interface (UI) is used to identify potential causes of train conflicts on a map to then introduce train delays to replicate a conflicting train scenario. Just modifying and re-sending the messages to the system would not guarantee that it would result in the same type of system / train behavior.

[0030] To address these issues, disclosed embodiments can create test scenarios from real-time unstructured data to detect performance bottlenecks of an underlying train planning system function, providing a distinct technical advantage over known systems.

[0031] Disclosed systems can generate test scenarios that are complex enough to identify performance bottlenecks in TPS as it utilizes real-time data from operation recordings. Disclosed embodiments can also validate the generated scenario ensuring that the same type of system behavior is achieved every time the test scenario is run. A TPS can include a number of components such as a real-time calculator, an appserver, and others that each generate logs. These logs can be used as one of the inputs to a test scenario generation system as disclosed herein.

[0032] FIG. 1 illustrates a block diagram of a data processing system or computer system 100 in which an embodiment can be implemented, for example as a computer system particularly configured by software or otherwise to perform the processes as described herein, and in particular as each one of a plurality of interconnected and communicating systems as described herein. The data processing system depicted includes a processor 102 connected to a level two cache / bridge 104, which is connected in turn to a local system bus 106. Local system bus 106 may be, for example, a peripheral component interconnect (PCI) architecture bus. Also connected to local system bus in the depicted example are a main memory 108 and a graphics adapter 1 10. The graphics adapter 110 may be connected to display 111.

[0033] Other peripherals, such as local area network (LAN) / Wide Area Network / Wireless (e.g. WiFi) adapter 112, may also be connected to local system bus 106. Expansion bus interface 114 connects local system bus 106 to input / output (I / O) bus 116. I / O bus 116 is connected to keyboard / mouse adapter 118, disk controller 120, and I / O adapter 122. Disk controller 120 can be connected to a storage 126, which can be any suitable machine usable or machine readable storage medium, including but notlimited to nonvolatile, hard-coded type mediums such as read only memories (ROMs) or erasable, electrically programmable read only memories (EEPROMs), magnetic tape storage, and user-recordable type mediums such as floppy disks, hard disk drives and compact disk read only memories (CD-ROMs) or digital versatile disks (DVDs), and other known optical, electrical, or magnetic storage devices.

[0034] Also connected to I / O bus 116 in the example shown is audio adapter 124, to which speakers (not shown) may be connected for playing sounds. Keyboard / mouse adapter 118 provides a connection for a pointing device (not shown), such as a mouse, trackball, trackpointer, touchscreen, etc.

[0035] Storage 126 can store any data necessary or useful for performing processes as described herein. For example, storage 126 can store simulation 152, freeze data 154, logs 156, dependency maps 158, messages 160, constraints 162, scenarios 164, program code 166 for implementing any processes described herein, and other data 168, which can include any other data or data objects usable for the processes described herein.

[0036] Those of ordinary skill in the art will appreciate that the hardware depicted in FIG. 1 may vary for particular implementations. For example, other peripheral devices, such as an optical disk drive and the like, also may be used in addition or in place of the hardware depicted. The depicted example is provided for the purpose of explanation only and is not meant to imply architectural limitations with respect to the present disclosure.

[0037] A data processing system in accordance with an embodiment of the present disclosure includes an operating system employing a graphical user interface. The operating system permits multiple display windows to be presented in the graphical user interface simultaneously, with each display window providing an interface to a different application or to a different instance of the same application. A cursor in the graphical user interface may be manipulated by a user through the pointing device. The position of the cursor may be changed and / or an event, such as clicking a mouse button, generated to actuate a desired response.

[0038] One of various commercial operating systems, such as a version of Microsoft Windows™, a product of Microsoft Corporation located in Redmond, Wash, may beemployed if suitably modified. The operating system is modified or created in accordance with the present disclosure as described.

[0039] LAN / WAN / Wireless adapter 112 can be connected to a network 130 (not apart of computer system 100), which can be any public or private data processing system network or combination of networks, as known to those of skill in the art, including the Internet. Computer system 100 can communicate over network 130 with server system 140, which is also not part of computer system 100, but can be implemented, for example, as a separate computer system 100.

[0040] FIG. 2 illustrates a test scenario generation system 200 in accordance with disclosed embodiments, that can be implemented by one or more computer systems 100 to create test scenarios usable by a train planning system. The test scenario generation system 200 consists of several components, described below, and each component generates logs 202, which can include, for example, app server logs, real-time calculator logs, etc. Logs 202 can also include any logs generated by a train planning system, which can be used with freeze data 206 (below) to generate test scenarios 210.

[0041] Test scenario generation system 200 operates simulation 250 to generate and validate executable test scenarios 210 and corresponding temporal scale maps 212. Inputs to the test scenario generation system 200 include messages 204a, constraints 208, logs 202, freeze data 206, and setup data 252. Messages 204a and constraints 208 can be received by constraint solver 214, which uses them to interact with scenario validator to ensure that test scenarios conform to all required constraints. Constraint solver 214 can pass messages 204a and constraints 208 on to scenario validator 216, which can further pass the messages to message framework 218. Message framework 218 can send both received messages 204a and ordered messages 204b to simulation 250. Messages 204a and ordered messages 204b can be, for example, structured XML messages.

[0042] Executable test scenarios 210 can be processed by message dependency mapper 220 to create dependency maps 222, using test scenarios 210 and / or outputs of either or both of analyzer 224 and permutator 226. Dependency maps 222 can be provided to analyzer 224 and permutator 226. Analyzer 222 can analyze dependency maps 222, with freeze data 206 and / or logs 202 to produce ordered messages 204b, and can returnanalysis results to message dependency mapper 220 to update dependency maps 222 as necessary. Permutator 226 can receive scenarios 210 from scenario validator 216 when re-permutation or reordering of the messages 204a or 204b is needed to produce a valid scenario 210. Reordering of the messages 204a or 204b may be required, for example, to ensure correct dependency between messages.

[0043] In various embodiments, received messages 204a, freeze data 206, and logs 202 can be received from a TPS, reflecting actual historical train operations data, to be used as a basis for generating the test scenario 210. Test scenario generation system 200 is capable of capturing all the messages, including received messages 204a and ordered messages 204b, that were exchanged between the components of a TPS within a certain period of time. These messages are continuously stored, during operation of the TPS, as real-time freeze data 206. Some examples of messages are train profiles, train activation, and track infrastructure.

[0044] These messages can be categorized into four types for the purpose of various embodiments.

[0045] Message Type 1 are messages that have a direct relation to a train. These types of messages can be identified as the train identifier and will be used as a parameter in the message. These can include, for example, train position messages, train activation messages, and others. An example of a train activation message (message type 1) is below, and the structure and elements of such a message can be found at time of filing at wiki .openraildata, com / index .php / Train_ Activation"header" : {"msg_type" : " 00000001" ," source_dev_id" :" user_id" :" original_data_source" : " s ome source" ,"msg_queue_t imest mp " 1511524534000" ," source_sy stem_id" : " s ome id"} ,"body" : {" schedule_source " : " D" ,"t rain_f ile_addres s" : nul l ," schedule_end_date " : " 2023 -12-08 " ," t rain_id" : " 775F25MP23 " ,"tp_or igin_t imestamp " 2023 -11-24 " ," creat ion_t ime stamp" : " 1512328234000" ,"tp_origin_stanox" :" o r i g i n_dep_t ime s t amp " 1512535420000 " ,"t rain_service_code" : " 25470023" , "toc_ id" : " 21" , "dl266_record_number " : " 00000" , "t rain_cal l_type" : "AUTOMATIC" , "train_uid" : " C21233 " , "t rain_cal l_mode" : "NORMAL" , " schedule_type " : " 0" , " sched_origin_stanox” : " 78301" , " schedule_wtt_ld" : " 5F25L" , " schedule_st rt_date " 2023 -12- 12 " } }

[0046] Message Type 2 are messages that indirectly impact a train. These can include, for example, a speed restriction message.

[0047] Message Type 3 are messages that have an impact on a train, but the dependency or impact on the train is not easily resolvable.

[0048] Message Type 4 are message that have no impact on the train.

[0049] While messages of type 1-3 are of interest to transfer freeze data 206 into a test scenario 210, type 4 messages can be ignored and are deleted.

[0050] FIG. 3 illustrates a flowchart of a process 300 in accordance with disclosed embodiments that can be performed, for example, by a test scenario generation system 200 implemented by one or more computer systems 100 (together referred to generically as the “system” below) to generate a valid test scenario with train conflicts.

[0051] At 302, the system receives real time freeze data 206 and train logs 202 (or simply “logs”). The train logs 202 can include train message logs, train application logs, or any other logs created by a TPS system during operation.

[0052] At 304, the system identifies, in the freeze data 206, at least one conflict C between trains. This step may include using logs 202 to identify the conflict C.

[0053] At 306, the system identifies all logs 202 corresponding to the conflict C, which can include any logs having data related to the conflict C or its cause. That is, while the conflict C may occur or be originally detected in a certain set of freeze data 206, the conflict C and its causes may be reflected in the data found in logs 202 and messages 204a. This step can include identifying times relevant to the trains and the conflict in order to identify other logs 202 or freeze data 206 that should be inspected.

[0054] At 308, the system sets up an initial simulation 250. The test scenario generation system 200 in simulation mode is capable of controlling the clocks of its components. For example, it can execute scenarios and make them happen immediately. The system can process messages immediately so that there is no delay between messages in the simulation. Simulation 250 configured with the initial setup data 252, which can include train infrastructure data.

[0055] In various embodiments, simulation 250 can be implemented in a train planning system that is configured in simulation mode. The TPS in simulation mode is capable of controlling the clocks of its components; for example, it can execute scenarios and make them happen immediately and can process messages immediately making it look like there is no delay between messages.

[0056] At 310, the system identifies the trains that are involved in a conflict from the logs 202.

[0057] At 312, the system can also identify all the Type 1 messages, of messages 204a, for each train from the freeze data 206. This step can be performed by analyzer 224.

[0058] At 314, the system identifies all the Type 2 messages, of messages 204a, for each train. For example, the system can gather all the restriction messages that are valid at the time of the conflict from freeze data 206. This step can be performed by analyzer 224. At 312 and 314, the system identifies messages of specific types in the train message logs.

[0059] At 316, the system orders the messages to produce ordered messages 204b. This step can be performed by analyzer 224 and permutator 226.

[0060] At 318, the ordered messages are used to produce scenario 210, corresponding to the conflict, that can be validated in simulation 250. These messages can be sent via message framework 208 to the simulation 250.

[0061] At 320, the system validates the scenario 210 in simulation 250 to determine if conflict C has occurred. This can be performed by scenario validator 216.

[0062] At 322, if the conflict has not occurred, the system, such as by using permutator 226, iteratively adds and / or removes messages to the scenario with the help of messagesfrom the freeze data. As part of this step, the system can identify the Type 3 messages. Since Type 3 messages are messages that have an impact on a train, but the dependency or impact on the train is not easily resolvable, this iterative process of adding and removing messages may identify Type 3 messages that have an impact on the trains involved in the collision by produce effects in the validation simulation. The system returns to 316 until it confirms that conflict C has occurred at validation step 316.

[0063] As a part of adding and / or removing messages to the scenario 210, the system can create dependency maps 222 of messages using the message dependency mapper 220. This can enable the system to identify the dependency between messages. The dependency maps 222 can be later used to reduce the number of loops between the analyzer 224, permutator 226, message framework 218, and scenario validator 206. In each iteration, the system may update the dependency maps 222 since each time a message is added or removed, and the validation simulation is re-run, the system may leam more about the dependency between messages.

[0064] FIG. 4 illustrates an example of message dependency. For example, in FIG. 4, message M4 408 cannot be sent unless M 1 402, M2 404, and M3 406 are sent in the illustrated order.

[0065] Returning to the process of FIG. 3, at 324, when the scenario has been validated, the system can generate a temporal scale map 212 corresponding to the test scenario 210. For example, the constraint solver 214 can use constraints 208 as input to generate a temporal scale map 212 for the scenario 210. The temporal scale map 212 can include delays that are required to be maintained between messages 204b, which can be important to ensure consistency and repeatability of the conflict in the test scenario. Constraint solver 214 can also add messages or requirements to the test scenario so that the physical requirements are not violated.

[0066] FIG. 5 illustrates an example of time delay and temporal scale computation between Train Profile message 502 and Train Position message 504. Note that the time delay can be defined in various scales, such as minutes, seconds, or generic “units.” The system can adjust the temporal scale map 212 to ensure that the message timing is such that the test scenario can be executed by the TPS.

[0067] In order for the test scenario to be executed as fast as possible, the trains should run faster as well in simulation 250. Constraint solver 214 can include required messages to make sure the physical requirements are not violated. If the contraints are not solved there can be message failures when messages are sent to simulation 250. For example, increasing the speed of the train would not be possible when a contraint defines that the track has a certain speed restriction. The constraint 208 can be solved by adding a speed restriction to the scenario 210 that would let the train run as fast as possible within the bounds of the simulation 250.

[0068] Returning to the process of FIG. 3, at 326, the system stores the test scenario 210 and can store the corresponding temporal scale map 212. The test scenario 210, along with temporal scale map 212 and / or any of the other data discussed herein, can then be used to test a train planning system.

[0069] Disclosed embodiments can generate test scenarios that are complex enough to identify performance bottlenecks in the system under test (SUT) as it utilizes real-time data from the operation. Various embodiment can further utilize simulation to validate the generated scenario. Furthermore, disclosed embodiments can automatically identifies the dependencies between data objects (messages).

[0070] Disclosed embodiments include a unique process of determining the order of messages that are needed to create a real and valid scenario, such as by using the analyzer 224, permutator 226, and constraints solver 214.

[0071] Disclosed embodiments provide a number of technical advantages. For example, the disclosed embodiments enable reuse of real-time data logs which enables a more efficient and cost-effective test scenario generation. Disclosed embodiments enable transition and adaptation of test scenarios from real-time data logs to derive test cases with increased likelihood of revealing performance bottlenecks, which enables much more effective test generation and testing. The use of verified test scenarios produced by disclosed embodiments enables TPS systems to be stress-tested using realistic, complex test scenarios derived from real-world data.

[0072] Disclosed embodiments enable multiplication of test scenarios with different message sequences and message content through permutation.

[0073] Disclosed embodiments can use the simulator in every loop / iteration to validate whether the scenario is valid. A process as disclosed can generates a time scale map and resolve constraints so that the test scenarios can be used repeatedly for performance testing, ensuring correct system behavior.

[0074] Of course, those of skill in the art will recognize that, unless specifically indicated or required by the sequence of operations, certain steps in the processes described above may be omitted, performed concurrently or sequentially, or performed in a different order.

[0075] Those skilled in the art will recognize that, for simplicity and clarity, the full structure and operation of all data processing systems suitable for use with the present disclosure is not being depicted or described herein. Instead, only so much of a data processing system as is unique to the present disclosure or necessary for an understanding of the present disclosure is depicted and described. The remainder of the construction and operation of computer system 100 may conform to any of the various current implementations and practices known in the art.

[0076] It is important to note that while the disclosure includes a description in the context of a fully functional system, those skilled in the art will appreciate that at least portions of the mechanism of the present disclosure are capable of being distributed in the form of instructions contained within a machine-usable, computer-usable, or computer-readable medium in any of a variety of forms, and that the present disclosure applies equally regardless of the particular type of instruction or signal bearing medium or storage medium utilized to actually carry out the distribution. Examples of machine usable / readable or computer usable / readable mediums include: nonvolatile, hard-coded type mediums such as read only memories (ROMs) or erasable, electrically programmable read only memories (EEPROMs), and user-recordable type mediums such as floppy disks, hard disk drives and compact disk read only memories (CD- ROMs) or digital versatile disks (DVDs).

[0077] Although an exemplary embodiment of the present disclosure has been described in detail, those skilled in the art will understand that various changes, substitutions, variations, and improvements disclosed herein may be made without departing from the spirit and scope of the disclosure in its broadest form.

[0078] None of the description in the present application should be read as implying that any particular element, step, or function is an essential element which must be included in the claim scope: the scope of patented subject matter is defined only by the allowed claims. Moreover, none of these claims are intended to invoke 35 USC §112(f) unless the exact words "means for" are followed by a participle. The use of terms such as (but not limited to) “mechanism,” “module,” “device,” “unit,” “component,” “element,” “member,” “apparatus,” “machine,” “system,” “processor,” or “controller,” within a claim is understood and intended to refer to structures known to those skilled in the relevant art, as further modified or enhanced by the features of the claims themselves, and is not intended to invoke 35 U.S.C. § 112(f).

Claims

WHAT IS CLAIMED IS:

1. A method for generating train test scenarios, the method performed by a computer system and comprising: identifying, by the computer system, train logs corresponding to a conflict between trains; identifying, by the computer system and from the train logs, trains that are involved in the conflict; identifying, by the computer system, messages of specific types in the train logs; ordering the identified messages, by the computer system, to produce a test scenario corresponding to the conflict; validating the test scenario in a simulation, by the computer system, to determine whether the conflict has occurred; when the computer system determines that the conflict has not occurred in the test scenario, then adding and / or removing messages from the test scenario, by the computer system, and repeating the ordering and validating steps; and when the computer system determines that the conflict has occurred in the validated test scenario, storing the test scenario, by the computer system, for use in testing a train planning system.

2. The method of claim 1, further comprising generating a temporal scale map corresponding to the validated test scenario.

3. The method of claim 1 , wherein adding and / or removing messages from the test scenario includes creating a dependency map of messages.

4. The method of claim 1 , wherein adding and / or removing messages from the test scenario includes identifying messages that have an impact on a train.

5. The method of claim 1, wherein identifying messages of a specific type is performed by an analyzer component.

6. The method of claim 1 , wherein ordering the identified messages is performed by an analyzer component and a permutator component.

7. The method of claim 1, wherein validating the test scenario in a simulation is performed by scenario validator component.

8. The method of claim 1, further comprising receiving freeze data, by the computer system, and using the freeze data to identify the train logs corresponding to the conflict between trains.

9. The method of claim 1 , wherein the messages of specific types include Type 1 messages that are messages that have a direct relation to a train.

10. The method of claim 1, wherein the messages of specific types include Type 2 messages that are messages that indirectly impact a train.

11. The method of claim 1 , wherein adding and / or removing messages from the test scenario, and repeating the ordering and validating steps, includes identifying Type 3 messages that have an impact on a train but a dependency or impact on the train is not easily resolvable.

12. A computer system having a processor and an accessible memory, the computer system particularly configured to perform a method as in any of claims 1-11.

13. A non-transitory computer-readable medium encoded with executable instructions that, when executed, cause one or more computer systems to perform a method as in any of claims 1-11.

Images