Patent Application
20170197646
The present disclosure relates generally to a train system and, more particularly, to a train system having automatically-assisted trip simulation.
Rail freight transport is generally a more efficient method of hauling bulk goods over long distances on a weight per-mile per-unit of energy basis than other delivery methods, such as by truck or by plane. Advances in locomotive technologies allow trains to haul larger and more valuable payloads with less fuel and on more demanding schedules. Yet, it is not uncommon for a train to experience a component malfunction during completion of a trip, which can cause a delay in the trip or, in extreme situations, cause the trip to abort. Delays or cancellations of rail deliveries due to malfunctions can incur financial penalties and have a rippling effect throughout a supply chain, which can increase operating costs and reduce productivity.
In most situations, when a component malfunction occurs onboard a train, the train is shut down and a manual evaluation is carried out with the result being to continue the trip as-is, to abort the trip, or to make a repair or adjustment to the train so that the trip may continue. But manual evaluations can be labor intensive, slow, and error-prone, and could possibly result in further delays. Some electronic simulation systems have been developed to help perform evaluations and compare a train's post-malfunction power capability to how much power the train will need to complete the mission. However, performing simulations with known systems can be time intensive and require significant operator input, which could lead to further delays.
A method of optimizing train operation is described in U.S. Pat. No. 6,587,764 of Nickles et al. that issued on Jul. 1, 2003 (“the '764 patent”). Specifically, the method described in the '764 patent includes determining a location of a train, a profile of a track to be traversed by the train, current conditions of the train, operational constraints, a dynamic interaction between cars of the train, and a goal for the train. The method further includes performing calculations based on the goal, the location, the track profile, the current conditions, and the dynamic interaction to simulate whether sufficient locomotive power is available to achieve the goal at the current location and over the ensuing track profile. If sufficient power is available, a determination may be made to shut down additional locomotives to reduce fuel consumption. If sufficient power is not available, the determination process is restarted.
While the method disclosed in the '764 patent may improve operation of a fully functional train, it may still be less than optimal. In particular, the method does not address malfunctions of train components, or how to determine if, when, or how a train can complete an assigned mission given the malfunctions. Further, the method discloses shutting down or starting up additional locomotives, but does not address other aspects of the train relating to power consumption.
The disclosed train system is directed to overcoming one or more of the problems set forth above.
In one aspect, the present disclosure is directed to a system for simulating operation of a train. The system may include at least one sensor configured to generate a signal indicative of an operating status of a component of the train during completion of an assigned trip, a display device, and a controller in communication with the at least one sensor and the display. The controller may be configured to generate on the display device a graphical user interface having a plurality of data fields configured to contain simulation data, retrieve from memory first data associated with the train and the assigned trip, and automatically populate the plurality of data fields with the first data. The controller may also be configured to simulate completion of a remainder of the assigned trip based on the signal and at least a portion of the first data and cause simulation results to be shown on the display.
In another aspect, the present disclosure is directed to a method simulating operation of a train. The method may include receiving a signal indicative of an operating status of a component of the train during completion of an assigned trip, generating on a display device a graphical user interface having a plurality of data fields configured to contain simulation data, retrieving from memory first data associated with the train and the assigned trip, and automatically populating the plurality of data fields with the first data. The method may further include simulating completion of a remainder of the assigned trip based on the signal and at least a portion of the first data and causing simulation results to be shown on the display.
In yet another aspect, the present disclosure is directed to another system for simulating operation of a train. The system may include at least one sensor configured to generate a signal indicative of an operating status of a component of the train during completion of an assigned trip, a display device, an input device configured to receive user inputs, and a controller in communication with the at least one sensor, the display, and the input device. The controller may be configured to generate on the display device a graphical user interface having a plurality of data fields configured to contain simulation data, retrieve from memory first data associated with the train and the assigned trip, and automatically populate the plurality of data fields with the first data. The controller may be further configured to receive via the input device second data associated with at least one of the train and the assigned trip and repopulate one or more of the plurality of data fields with the second data. The controller may be further configured to simulate completion of a remainder of the assigned trip based on the signal and at least a portion of the first and second data and cause simulation results to be shown on the display, wherein the display is located remote from or onboard the train.
Each locomotive 12 may be connected to an adjacent locomotive 12 and/or to tender car 14 in several different ways. For example, locomotives 12 and tender car 14 may be connected to each other via a mechanical coupling, one or more fluid couplings, and one or more electrical couplings. These couplings are represented together by a single coupling 16 in
Each locomotive 12 may include a car body 18 supported at opposing ends by a plurality of trucks 20 (e.g., two trucks 20). Each truck 20 may be configured to engage tracks 22 via a plurality of wheels 24, and to support car body 18. Each truck 20 may have two or more axles that are each configured to rigidly support wheels 24 at opposing ends thereof, such that wheels 24 and the axles rotate together. A traction motor 25 may be disposed at a lengthwise center of each axle, connected to an associated truck 20, and configured to drive paired wheels 24 via the axle.
Any number of engines 26 may be mounted to car body 18 and drivingly connected to a generator 28 to produce electricity that propels wheels 24 of each truck 20 via traction motors 25. Engines 26 may be internal combustion engines configured to combust a mixture of air and fuel. The fuel may include a liquid fuel (e.g., diesel) provided to engines 26 from a tank 30 located onboard each locomotive 12, a gaseous fuel (e.g., natural gas) provided by tender car 14 via the fluid couplings, and/or a blended mixture of the liquid and gaseous fuels.
Tender car 14, like locomotives 12, may also be equipped with a body 18 that is supported by two or more trucks 20. Tender car 14 may further include one or more tanks 32 mounted to body 18 that are configured to store liquefied gaseous fuel (e.g., liquefied natural gas or LNG). The liquefied gaseous fuel may be gasified and then fed in series or parallel to all locomotives 12 of train 10 for combustion within engines 26. In the disclosed embodiment, a single insulated tank 32 is used to store the liquefied gaseous fuel at low temperatures, such as below about −160° C. In some embodiments, tank 32 may be integral with body 18 of tender car 14.
Additional fuel delivery components (not shown) may be associated with tender car 14 and used to gasify and/or transport the fuel from tender car 14 to locomotives 12. These components may include, among other things, one or more fuel pumps, one or more heat exchangers, one or more accumulators, one or more regulators, and associated conduits that condition, pressurize or otherwise move fuel, as is known in the art. The pump(s) may pressurize the liquefied gaseous fuel to a desired operating pressure and push the fuel through the heat exchanger(s) to the accumulator(s). The heat exchanger(s) may provide heat sufficient to gasify the fuel as it moves therethrough. Upon vaporization, the fuel may be transported to and stored within the accumulator(s). Gaseous fuel may then be directed from the accumulator(s) to engines 26 via the regulator(s).
As also shown in
Any number of sensors 38 may be included within system 36, and configured to generate operational data associated with any component of any part of train 10. For example, one or more sensors 38 could be associated with engine 26 and configured to monitor a cylinder pressure, an oil pressure, a fuel pressure, a water temperature, an exhaust temperature, an intake air pressure or temperature, a speed, a vibration level, etc., and to generate corresponding signals. In another example, one or more sensors 38 could be associated with each traction motor 25, with each wheel 24 (e.g., with a bearing of each wheel 24), with generator 28, with tank 30, with tank 32 (and/or with the other fuel handling components of tender car 14), with coupling 16, etc., and configured to generate corresponding pressure signals, temperature signals, speed signals, or other types of signals indicative of the performances of the associated components. When values of the signals generated by sensors 38 deviate from expected values or ranges, the signals may be correlated to a status of the associated component. For example, when the value of a particular signal exceeds or falls below a corresponding threshold value, the associated components may be determined to be malfunctioning. The signals generated by sensors 38 may be directed to controller 46 for further processing.
Locating device 40 may be configured to generate signals indicative of a geographical position and/or orientation of train 10 relative to a local reference point, a coordinate system associated with a region, a coordinate system associated with Earth, or any other type of 2-D or 3-D coordinate system. For example, locating device 40 may embody an electronic receiver configured to communicate with satellites or with a local radio or laser transmitting system and to determine a relative geographical location of itself. Locating device 40 may receive and analyze high-frequency, low-power radio or laser signals from multiple locations to triangulate a relative 3-D geographical position and orientation. Signals generated by locating device 40 may be directed to controller 46 for further processing.
Communicating device 42 may be configured to facilitate data communication between different components (e.g., between sensors 38 and controller 46, between controller 46 and user interface 44, and/or between controller 46 and other components) of system 36 or between components of system 36 and entities off-board train 10. Communicating device 42 may include hardware and/or software that enable the sending and/or receiving of data messages through a communications link. The communications link may include satellite, cellular, infrared, radio, and any other type of wireless communications. Alternatively, the communications link may include electrical, optical, or any other type of wired communications, if desired. In one embodiment, user interface 44 and/or controller 46 may be located off-board train 10, and may communicate directly with the other onboard components of system 36 via communicating device 42, if desired. Other means of communication may also be possible.
User interface 44 may be or include one or more display devices 48 (e.g., a liquid crystal display (LCD), a cathode ray tube (CRT), a personal digital assistant (PDA), a plasma display, a touch-screen, a portable hand-held device, or any such display device known in the art) configured to actively and responsively show trip simulation results to the user of system 36. User interface 44 may also include, be connectable to, or otherwise be associated with an input device 50 configured to receive user inputs. Input device 50 may be or include one or more components, such as buttons, knobs, switches, dials, levers, touch-screens, soft keys, a keyboard, a mouse, and/or other components configured to allow a user to provide inputs to or operate an electronic device. In some embodiments, user interface 44 may be disposed in close proximity to the cabin of train 10 and within the view of the operator of train 10. In other embodiments, as described above, user interface 44 could be located offboard train 10. User interface 44 may be connected to controller 46, and controller 46 may execute instructions to render graphics and images on display device 48 that are associated with a simulated trip.
Controller 46 may embody a single microprocessor or multiple microprocessors that include a means for operating and/or controlling system 36 based on information obtained from any number of train components via sensors 38, from locating device 40, and/or from communications received via communicating device 42. Numerous commercially available microprocessors can be configured to perform the functions of controller 46. Controller 46 may include a memory, a secondary storage device, a processor, and any other components for running an application. Various other circuits may be associated with controller 46 such as power supply circuitry, signal conditioning circuitry, solenoid driver circuitry, and other types of circuitry.
Wayside systems 56 may include sensory and/or signaling equipment positioned throughout railroad network 52 and configured to collect and display information about various railroad operations. For instance, wayside systems 56 may include sensors and other devices that are configured to detect information pertaining to asset maintenance (e.g., asset operating parameters and usage statistics), track maintenance (e.g., track conditions and track usage statistics), route signaling and interlocking (e.g., presence, speed, and/or location of trains and assets), and or other railroad operations. In some embodiments, wayside systems 56 may be configured to use collected data to generate signals for railroad operators indicative of route permissions, speed limits, and or other information. Signals may be displayed in various ways, including by wayside signaling devices (e.g., lights) and through automatic train protection (ATP) systems accessible from onboard train 10, for example, via user interface 44.
Business systems 58 may include one or more devices or systems configured to manually and/or automatically track, receive, and/or store data relating to operations of railroad network 52. Business systems 58 may be located off-board train 10, such as at a management office 64. In some embodiments, business systems 58 may be located at least in part onboard train 10. Business systems 58 may include computers, data storage devices, computer executable programs, electronic files or filing systems, spreadsheets, databases, servers, network interfaces; hardware interfaces, and or other devices configured to collect, process, and/or store data.
For example, business systems 58 may include logistics systems configured to track the movements of materials, personnel, transportation vessels, and equipment throughout railroad network 52. For example, logistics systems may include tracking equipment, such as global positioning systems (GPS), radio frequency identification (RFID), barcode scanning devices, etc. Logistics systems may be configured to store and maintain data relating to units of materials and/or personnel that are yet to be shipped, in transit, or have been shipped. Such data may include quantity information, origination and destination information, delivery dates, estimated time in transit, estimated time of arrival, size information, mode of transportation, shipping costs, carrier service information, etc. It is understood that other or additional types of information and data may be gathered by logistics systems.
Business systems 58 may also include SCADA systems configured to carry out automated tasks within railroad network 52. SCADA systems may include various types of industrial automated systems associated with transferring payload into and/or out of rolling stock assets of train 10. For example, automated systems may include automatic payload dumping and filling systems for wagons and systems configured to facilitate automated movement of rolling stock from one location to another (e.g., within a yard). SCADA systems may receive or detect information relevant to such automated processes, which may include, for example, payload statistics (e.g., weight, volume, quantity, size, type, etc.), numbers and types of assets in train 10, location information, and/or other information. Other or additional types of information and data may be gathered and other types of tasks may be performed by SCADA systems.
Business systems 58 may also include maintenance systems configured to detect and store data relating to maintenance issues of trains 10, tracks 22, and or other aspects of railroad network 52. For example, maintenance systems may work in connection with sensors 38 and/or controller 46 to monitor and record operational data of train 10 and generate fault codes when operating parameters exceed threshold or limit values, such as when train 10 experiences a malfunction. Maintenance systems may also monitor operating conditions of tracks 22 in connection with wayside systems 56 and/or as indicated by performance data of train 10 (e.g., wheel slip, vibrations, etc.). Fault codes may be correlated with other information, such as GPS location, train ID, etc., to help identify locations of tracks 22 that may be of particular interest. Other or additional types of information and data may be gathered by maintenance systems.
Business systems 58 may also include asset management systems configured to track usage data of rolling stock assets (e.g., locomotives 12, tender cars 14, wagons, etc.). For example, asset management systems may track when each asset goes into service, how long each asset has been in service, and when each asset is taken out of service. Asset management systems may also track historic data of payload that has been handled by each asset (e.g., weight, volume, quantity, type, etc.). Data gathered by asset management systems may also be correlated with positioning data (e.g., GPS data) to track the distance traveled by each asset and the locations visited by each asset. It is understood that other or additional types of information and data may be gathered by asset management systems.
Business systems 58 may also include financial forecasting systems configured to analyze and/or generate data relating to the effects of financial parameters on the operations of railroad network 52. For example, financial forecasting systems may generate data pertaining to stock market behaviors of financial instruments relating to goods hauled on railroad network 52, consumer demand statistics, sales numbers, corporate earnings statements, related market trends (e.g., of fuel markets, of currency markets, of raw material markets, etc.), and/or other information. Financial forecasting systems may also generate data relating to customer trends and habits, such as shipping volumes as a function of calendar date, weather patterns, cycle period (e.g., weekly trends, monthly trends, quarterly trends, etc.), etc. This information may be indicative of anticipated shipping volumes, and therefore indicative of potential asset requirements, manpower requirements, maintenance requirements, track usage, scheduling requirements, etc. It is understood that other or additional types of information and data may be gathered by financial forecasting systems.
Business systems 58 may also include yard scheduling systems configured to organize and coordinate usage of resources within yards. For example, yard scheduling systems may be configured to facilitate the allocation of siding space, material storage space, asset storage space, loading and unloading time, and/or other aspects of yard operations. Yard scheduling systems may receive information, such as shipping schedules (e.g., incoming and outgoing), train information (e.g., number and type of assets, payload information, origination and destination information, etc.), layover time, train building information, and/or other information, and facilitate the allocation of time and space in and around yard for carrying out loading and unloading tasks, as needed. It is understood that other or additional types of information and data may be gathered by yard scheduling systems.
Business systems 58 may also include enterprise resource planning (ERP) systems configured to track and/or aggregate information relating to business parameters and operational parameters associated with railroad network 52. For example, ERP systems may track inventories of parts, assets, payload, personnel, and or other information at various locations throughout railroad network 52, and facilitate restocking of such inventories. ERP systems may track quantities, types, prices, availability, and/or other statistics for each stock item and allow a user to generate orders for additional units of such items. Warehouse locations, estimated time of delivery, shipping information (e.g., cost, weight, size, special requirements, etc.) may be listed for each inventory item. Pending orders and associated information (e.g., estimated dates of delivery, shipping routes, origination and destination information, etc.) may also be listed. It is understood that other or additional types of information and data may be gathered and maintained by ERP systems.
It is noted that any information received or generated by business systems 58 may be communicated to controller 46 or other components of system 36 and/or railroad network 52 via communications network 62. Each piece of data received or generated by business systems 58 may be utilized by controller 46 as a simulation input or for another purpose, as desired. That is, simulations performed by controller 46 may be based on or incorporate any available data received by or generated by business systems 58.
Back offices 60 may include locations where personnel and/or computerized systems are stationed to monitor and control train 10 and/or other aspects of railroad network 52. For example, back offices 60 may include management office 64, trackside buildings, maintenance buildings, engineering offices, and/or other locations. Back offices 60 may alternatively embody mobile devices equipped with combinations of hardware and software configured to allow users to monitor or control aspects of train 10 and/or railroad network 52, such as smartphones, personal digital assistants, tablets, laptop computers, dedicated mobile devices, etc. Back offices 60 and/or associate devices may be equipped with communication equipment configured to connect to and transfer data via communications network 62.
As mentioned above, controller 46 may be configured to perform simulations of trips to be completed by train 10. More specifically, controller 46 may be configured to perform simulations of a remainder of a trip assigned to train 10, following malfunction of a component of train 10 during the trip. The simulations may be performed based on operational data associated with railroad network 52, such as a known profile of tracks 22 (e.g., horizontal track changes, vertical track changes, track quality and/or friction, speed limits, road crossings, and other trip-related data) yet to be traversed by train 10, supply chain data (e.g., supplier scheduling, delivery quantities, delay costs, etc.), resource availability (e.g., numbers of available rolling stock assets, available manpower, maintenance capabilities, etc.), environmental conditions (e.g., precipitation, temperature, etc.), desired goals (e.g., time of arrival, operational cost, etc.), and/or other information known in the art. The simulations may also or alternatively be based on data associated with train 10, such as length, weight, pulling capacity, available power, a fuel consumption, a thermal characteristic, a cargo type and value, a failure cost, a locomotive configuration and performances, a braking capacity, a rolling resistance, desired goals (e.g., fuel consumption, operational cost, etc.) and other train-related data known in the art. The simulations may be performed using maps, equations, graphs, tables, scales, and other preprogrammed algorithms stored in the memory or otherwise communicated to controller 46.
The results of the simulation may include static results and dynamic results. The static results may consist of either a positive response or a negative response regarding the desired goals. For example, if the desired goal is to reach a destination, the static results of the simulation performed by controller 46 may simply indicate that train 10 will or will not reach the destination. Similarly, if the desired goal is a time of arrival, the static results of the simulation may simply indicate that train 10 will or will not reach the destination on time. Dynamic results may consist of an anticipated performance value associated with a particular operation of train 10, indexed to any given time, location, or distance along the remainder of the trip. For example, the dynamic result could include an anticipated location, speed, fuel consumption, temperature, pressure, etc., for given intervals of time, location, or distance.
The results of the simulation may be used by the back office, by controller 46, and/or by the onboard operator of train 10 in making decisions regarding the given malfunction. For example, based on the simulation results, a decision may be made to shut down train 10 at its current location, to continue to a better location for repairs before shutdown, to complete the assigned trip, to dispatch a repair vehicle, to modify train operation and continue, to dispatch replacement or supplemental equipment (e.g., replacement or supplemental locomotives 12) etc.
Simulations may include any number of inputs relating to train 10 and/or railroad network 52. As simulation complexity increases (e.g., to produce more accurate results), the simulation may include more inputs of various types, which may not always be readily available to train operators or other personnel performing the simulation. To reduce the time needed to perform simulations and make operational decisions after malfunctions have been detected, controller 46 may be configured to automatically assist the set up simulations by preloading the simulation with inputs received from onboard data system 36 and off-board data systems 54.
As shown in
A second data field 72 of GUI 66 may provide a summary associated with train 10 and/or the assigned trip. For instance, data field 72 may show an identification of train 10, an identification of locomotives 12 in train 10, a number of cars (a.k.a., wagons) connected to locomotives 12, a weight of train 10, a length of train 10, a type of payload carried by train 10, a travel direction, a payload source, a destination, a scheduled time of arrival (STA), an expected time of arrival (ETA), an earliest possible time of arrival, and a crew identification. This information may be manually entered into system 36 prior to a start of the assigned trip, and/or automatically looked up and/or collected from any number of different sources and databases, as desired.
A third data field 74 of GUI 66 may be an alert area. In particular, when controller 46 determines that a value of one or more of the signals generated by sensor(s) 38 have deviated from an acceptable value or range, controller 46 may generate an error flag corresponding to the deviation. For example, controller 46 may provide a visual alert within data field 74, making the user of system 36 aware of a corresponding component malfunction. In the disclosed example, the depicted alert indicates that a locomotive 12 identified as #1 is experiencing low-fuel pressure, and has been shut down. A fourth data field 76 may provide an illustration of the offending component and/or part of train 10 that is experiencing the malfunction.
A fifth data field 78 of GUI 66 may be configured to illustrate the static results of a trip simulation run by controller 46. As stated above, the static results may include the simple positive/negative answer regarding train 10 being able to achieve the desired goal, given the current malfunction. In some instances, the static results may also show some calculated values corresponding to the anticipated performance of train 10. These values may include, for example, a maximum amount of tractive force that can be applied by the remaining locomotives 12 after locomotive #1 is shut down, a maximum wheel adhesion, an amount of fuel anticipated to be consumed, and a time required to complete the assigned trip given the derated performance of train 10. It is understood that additional and/or other data fields may be included on GUI 66. It is also noted that data fields may embody singular or plural text boxes, dropdown menus, radio buttons, and/or other known graphical field forms that may be configured to receive and/or display information.
As the amount of data that may be input or displayed via GUI 66 can be numerous, controller 46 may be configured to retrieve from memory first data associated with the train and the assigned trip and automatically populate data fields 70-78 with the first data prior to commencement of the simulation. That is, when the user activates GUI 66, controller 46 may automatically prepopulate data fields 70-78 with data received from onboard data system 36 and off-board data systems 54. The first data that is preloaded into data fields 70-78 may represent current data relating to train 10 and/or railroad network 52. That is, the first data may correspond to current operating conditions, fault statuses, locomotive power capacity, and any other available data reflecting the current state of train 10 and/or railroad network 52. The first data may be any amount of data generated or accessible by system 36 and/or off-board systems 54, such as a number of locomotives 12 associated with train 10, a number of cars associated with train 10, a train weight, a train length, a route, a track grade, a track curvature, an ending point location (i.e., trip destination) of train 10, or any other available data that may be used in the simulation. Once the first data is preloaded into data fields 70-78, the user may manually or controller 46 may automatically initiate the simulation of the completion of the remainder of the assigned trip, causing simulation results to be shown on display device 48.
The ensuing simulation may be based on the signal(s) from sensor(s) 38 and at least a portion of the first data. That is, in some cases, after the first data is preloaded into data fields 70-78, the simulation may be run based on the first data. In other cases, some or all of the first data that was preloaded into data fields 70-78 may be altered by the user prior to initiating the simulation. For instance, controller 46 may be configured to receive user inputs (e.g., via user interface 44) indicative of second data relating to train 10 and/or railroad network 52 and repopulate one or more of data fields 70-78 with the second data.
Controller 46 may be configured to allow users to select data fields 70-78 via user interface 44 and GUI 66, and replace the contents (e.g., the first data) of each data field 70-78 with second data. The second data may be of the same type as the first data (e.g., with respect to a given data field 70-78), but the particular data values entered by the user to replace the values of the first data may be different. Controller 46 may be configured to then simulate the completion of the remainder of the assigned trip based further on the second data, thereby allowing the user to observe any effects of the alteration on the simulation results. With this functionality, users may be able to repeat simulations with iteratively different inputs until a desired outcome has been achieved, which may serve as a basis for making a decision about how to proceed with the mission of train 10.
Controller 46 may be configured to repopulate data fields 70-78 after the completion of a first simulation to allow simulations to be quickly repeated. In some embodiments, controller 46 may be configured to automatically repopulate data fields 70-78 with the first data after a prior simulation is complete. In some cases, repopulating data fields 70-78 with the first data may include repopulating fields 70-78 with the same first data that was used to prefill data fields 70-78 prior to the previous simulation (i.e., prior to the replacement of the first data with second data, if any such replacement occurred). In other cases, repopulating data fields 70-78 with the first data may include repopulating fields 70-78 with current first data (i.e., current data generated by onboard data system 36 and/or off-board data systems 54). In this way, if the user made multiple changes to the first data in the prior simulation, those changes may be undone to allow for quick return to previous simulation data.
In other embodiments, controller 46 may be configured to preserve the simulation data in the in data fields 70-78 after a first simulation is complete to allow for quick simulation repetitions, even after several changes have been made to the simulation data. That is, after each simulation is complete, controller 46 may maintain the data contained within each data field 70-78 to allow the user to make iterative changes to the simulation after seeing the results of the previous simulation. In some embodiments, controller 46 may display an option (e.g., a button, a menu option, etc.) on GUI 66 that allows the user to select how data fields 70-78 will be repopulated after each simulation. In this way, users may be able to perform several successive simulations without having to reload each and every data field 70-78, investigate a plurality of available options for completing the mission, and resolve malfunction situations expediently.
The disclosed system can be applicable to any train that includes components that could malfunction during completion of a trip. The disclosed system may provide a way to quickly and easily determine if the train is able to successfully complete the trip, given the malfunction. Specifically, the disclosed system may automatically preload trip simulations with many pieces of current, relevant data for determining whether and/or how a train can complete the remainder of a mission. The disclosed system may also allow users to quickly and easily modify the preloaded information before running multiple simulations, which may aid in making decisions regarding the status of the train and the malfunctioning component. An exemplary operation of system 36 will now be explained.
Controller 46 may monitor operational conditions of the different components of train 10 during the course of a mission or trip. As described above, the condition of these components may be monitored by way of sensors 38. Specifically values of the signals generated by sensors 38 may be continuously compared to operational thresholds and/or ranges. Based on the comparison of these values, controller 46 may determine if an abnormal (e.g., malfunction) condition has been detected, and then determine if the abnormal condition could affect success in train 10 achieving the desired goal (e.g., reaching its destination within a desired window of time). It may be possible, in some situations, for a first component (e.g., an air conditioner) to malfunction without affecting the success of the trip, while malfunction of a second component (e.g., engine 26) could make it less likely or, in some situations, impossible for train 10 to complete the trip. Accordingly, controller 46 may make such a determination based on the type and/or identification of the component determined to be malfunctioning, based on the results of the values comparison, and based on one or more maps, equations, tables, and/or algorithms stored in memory.
When controller 46 determines that the malfunctioning component should not have a significant effect on the successful nature of the trip, controller 46 may log a fault and allow train 10 to complete the trip without intervention. However, when controller 46 determines that the detected malfunction of the offending component could have a significant impact on completion of the trip, the user (e.g., the operator of train 10, management personnel, maintenance personnel, etc.) may manually or controller 46 may automatically trigger a simulation of the remainder of the trip, taking into account the detected abnormal condition and based on preloaded track profile and train information. The results may thereafter be shown on display device 48.
When the simulation is triggered, controller 46 may preload data fields 70-78 of GUI 66 with first data (e.g., data generated by onboard data system 36 and/or off-board data systems 54) stored by or otherwise accessible by controller 46. The user may then be able to review the simulation data prior to commencement of the simulation. Based on the results of the simulation, the user may wish to modify the simulation to determine if there are any changes that can be made to train 10 that will allow it to complete the mission. The user may then change some of the simulation data, such as the number of rolling stock (e.g., wagons, locomotives, etc.) attached to train 10, the route, the average speed, and/or other parameters, prior to rerunning the simulation. The user may modify the simulation data and rerun the simulation any number of times before making a decision about how to proceed with the mission.
After each simulation, controller 46 may repopulate data fields 70-78 with the first data from the previous simulation, updated first data, or the same simulation data from the previous simulation. The repopulation method may be selected by the user via a button or other feature associated with GUI 66. The user may run a plurality of simulations and decide on a course of action for completing the mission based on the results of the simulations.
For example, if the initial simulation shows that completely shutting down locomotive #1 (from the above GUI 66 example) to mitigate all further damage makes it impossible for train 10 to complete its assigned trip within the desired window of time, controller 46 may try to determine if the engine of locomotive #1 could instead be run at ½ throttle (e.g., at notch setting 3 or 4) to complete the trip in a timely manner without causing excessive collateral damage (e.g., without destroying engine 26). If adjustment options are available, the user or controller 46 may implement corresponding virtual adjustments to the simulation model by replacing data in fields 70-78 with second data corresponding to the adjustment. If no feasible adjustment options exist that are likely to improve the results of the simulation, additional simulations corresponding to more drastic modifications may be made.
For example, subsequent simulations may test whether the mission could continue if a certain number of rolling stock assets, such as a number of wagons, were uncoupled from train 10. With fewer wagons, train 10 may require less power from malfunctioning engine 26 in order to travel at a suitable speed over the remaining portion of tracks 22. If the simulation results indicate that engine 26 has enough available power to pull a reduced number of wagons, personnel may decide uncouple enough wagons to allow train 10 to continue and return for them at a later time. If the results of the simulation indicate that uncoupling wagons will not be sufficient to allow the mission to continue, additional simulations may be run to test whether rearranging the position other locomotives 12 or calling for supplemental locomotives 12 can permit the mission to continue. When the user observes acceptable simulation results, a plan to continue the mission may be implemented in accordance with the results.
It will be apparent to those skilled in the art that various modifications and variations can be made to the disclosed system without departing from the scope of the disclosure. Other embodiments of the system will be apparent to those skilled in the art from consideration of the specification and practice of the system disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope being indicated by the following claims and their equivalents.
