BACKGROUND

[0001] Interoperable train control (ITC) - positive train control (PTC) systems may include on-board units (OBUs). The OBU may provide a safety overlay for railroad operations through brake enforcement. However, in some cases a malfunctioning OBU cannot or does not release the brakes and thus disallows train movement. In order to overcome such situations, a hardware cutout switch may be used to physically isolate a malfunctioning OBU from a locomotive's brake system.

[0002] Situations may occur where the erroneous enforcement is not the result of a malfunctioning OBU, but is the consequence of another faulty element within the ITC-PTC system (e.g., a wayside interface unit (WIU) that is unable to communicate). Utilizing the hardware cutout in such cases may be ill-advised, since the fault does not originate within the OBU and therefore prohibiting OBU operation may decrease operational safety. On the other hand, resolving the situation may require a considerable amount of time and thus a substantial loss of revenue for the railroads.

[0003] A software cutout may address the erroneous enforcement issue. However, a software cutout may not be tied to any operational condition and thus is not limited in its effect. A conventional software cutout use case may proceed as follows:

• OBU is in a state providing PTC functionality where the crew determines a need to cutout the OBU without using the hardware cutout switches.

• Crew selects the cutout softkey.

• OBU prompts for confirmation.

• Crew confirms prompt.

• OBU transitions to the cut-out mode (with appropriate display changes and back office server (BOS) report messages) and disables PTC enforcement.

• Crew can then proceed to operate the train on PTC track without PTC enforcement.

• When crew determines PTC should be re-engaged the crew selects the cut in softkey. • The OBU performs an abbreviated initialization to ensure data is up-to-date and transitions back to active (with appropriate display changes and BOS report messages) and enables PTC enforcement.

[0004] Software cutout functionality may often be employed during operational scenarios involving the loss of communication with a WIU which is monitoring a wayside device (e.g., a signal device, a switch/point, or a hazard detector), for example. Some specific example procedures implemented by the railroads are as follows:

• Signal at STOP is covered within ITC-PTC using communication between the

dispatcher and the train engineer, a special form of movement authority and communication between the office- and locomotive segments.

• Switch is covered by procedure where the train engineer can manually enter the position of the switch on the human-machine interface (HMI) of the OBU after he/she verified that the switch is properly aligned.

• Hazard Detectors may be integrated with a signal system or in a standalone

configuration. The former case is covered by signal at STOP (if a hazard is detected). The latter is covered by procedures using communication between the dispatcher and the train engineer and allows movement at restricted speed.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005] FIGS. 1A-1B show a train proceeding along a track using a first override approach according to an embodiment of the invention.

[0006] FIG. 2 shows a first override approach according to an embodiment of the invention.

[0007] FIGS. 3A-3B show a train proceeding along a track using a second override approach according to an embodiment of the invention.

[0008] FIG. 4 shows a second override approach according to an embodiment of the invention.

[0009] FIG. 5 shows a third override approach according to an embodiment of the invention.

[0010] FIG. 6 shows a train control system according to an embodiment of the invention. DETAILED DESCRIPTION OF SEVERAL EMBODIMENTS

[0011] Systems and methods described herein may provide cutout functionality called Override' which may specifically and temporarily overcome issues arising from a faulty component of the ITC-PTC system while continuously providing the maximum available level of safety. Override may be accompanied by applicable corrective actions and may satisfy the mandated reporting responsibilities of railroads.

[0012] The systems and methods described herein may provide cutout functionality not only for the situations described in the background, but also for additional situations.

Specifically, these approaches may handle the case where there is no wayside status received for a wayside device in a configurable amount of time, for example. In such a case, if no wayside status is received (e.g., signal device status not received), the OBU may assume the wayside device must be indicating a STOP. This assumption may be made in order to provide a maximum level of safety. The approaches described herein may override specific aspects of PTC enforcement within the OBU related to failures in other PTC subsystems without a significant decrease in the operational safety provided by the OBU. The approaches may include the following:

• An override WIU approach that disables enforcement of wayside devices associated with a specific WIU; and

• An override wayside device approach that disables enforcement for a single wayside device.

[0013] It is assumed that hazard detectors are treated as signal devices in both approaches.

Override WIU Approach

[0014] The override WIU approach may disable enforcement for all wayside devices associated with a specific WIU with which the OBU has communication failures. It should be understood that a single WIU may be associated with (configured to transmit status for) one or multiple wayside devices of the same or different types. As used herein, "wayside device" includes a wide variety of devices for which it may be desirable to transmit a status including, without limitation, signal devices (i.e., a device located on a side of the track with colored lights that indicate how a train may proceed along a section of track associated with the device), crossing gates, track switches/points, avalanche detection circuits, track integrity circuits, bridge alignment circuits and the like. This approach may address the use case where the crew can see that a wayside device indicates that it is safe to proceed yet, since the wayside device status is unknown to the OBU (e.g., no wayside status message (WSM) received for that signal), the OBU may enforce a stop and hold the train until the WI U communication failure is resolved. An example of this may be a signal device indicating clear but the OBU preventing the train from passing the signal device. I n this case it may be inappropriate for railroad operations to issue an authority to pass signal at stop to continue operation of the train because the signal device is not at stop. Further, issuing authority to pass signal at stop may require the train to proceed past the clear signal device at restricted speed, while the override WI U approach may allow traversal at track speed. The override WIU approach may provide a high degree of operational safety with smooth movement, limited user interaction, and no need for re-initialization.

[0015] FIGS. 1A and IB illustrate an example of the override WIU approach, and FIG. 2 illustrates the override WIU approach procedure. A train may approach a wayside device of unknown state 110, which may be a wayside device for which the OBU has not received WI U status in a configurable time (e.g., no status received 210 of FIG. 2), or incorrect state (e.g., the received data does not match the visual indication provided by the signal device, such as a STOP received when the signal device visually indicates it is safe to proceed; or the received data and/or visual indication indicate that a wayside device is configured in a manner inconsistent with the train's intended route, such as received status indicating that a switch is set to put the train on a portion of the track outside of the planned route, or a grade crossing gate alongside a section of track to be passed by the train is in the up or raised position). The train may come to a stop at a position 120 in front of the wayside device of unknown or incorrect state 110 (e.g., stop train 220 of FIG. 2). The crew may stop the train due to the unknown or incorrect status from the WI U. The OBU may prompt the crew to ask whether they want to disable enforcement for the wayside devices associated with the WI U for which the OBU has not received status or has received incorrect status (e.g., prompt crew for override 230 of FIG. 2). In some embodiments, the OBU may prompt the crew without waiting for the crew to stop the train. I n this case, the OBU may send the prompt 230 when the train reaches a configurable distance from the wayside device of unknown or incorrect state 110. This embodiment may allow the override WI U approach to be performed without requiring a train stoppage by the crew. In either case, the crew may determine that it is safe to proceed despite a WI U status indicative of the contrary (e.g., override selected 240 of FIG. 2), so the crew may confirm the prompt. For example, the crew may determine that the track ahead is safe despite a received STOP status, or the crew may determine that the train can proceed on an unplanned portion of the track when a switch is set incorrectly. If the wayside device indicates otherwise (e.g., STOP) (e.g., override not selected 240 of FIG. 2), the crew may follow the well-defined procedure to pass signal at stop (PSS) under restricted speed (e.g., perform standard procedures 250 of FIG. 2).

[0016] If the override prompt is confirmed, the OBU may disable enforcement of all wayside devices associated with WI U for which the OBU has not received status or has received incorrect status, for example all wayside devices in the area served by the WIU 130. The OBU may know which wayside devices are associated with the WIU by checking a database that may be part of the OBU or in communication with the OBU (e.g., on the train or elsewhere). The database may contain data associating each WI U along the track with specific wayside devices (e.g., signals, switches, hazard detectors, etc.). Thus, as the train passes additional wayside devices without status or with incorrect status 140, the train may proceed without enforcement of unknown or incorrect status (e.g., proceed without enforcement of signals 260 of FIG. 2). The OBU may remain in the active mode and may continue to enforce all other speed restrictions and field elements (e.g., track speeds, wayside devices associated with other WIUs along the train's route, temporary speed restrictions, end of authority limits, etc.). Thus, PTC rules may be enforced generally, and only the messages specific to the overridden WI U may be ignored. The OBU may continue to process messages from the BOS and WIUs. Display of disabled signals may be indicated on the human-machine interface (HMI). If the train crew encounters a signal device at STOP, the crew may follow the well-defined procedure to pass signal at stop (PSS) under restricted speed, despite the disabled enforcement for that specific signal device.

[0017] If the OBU receives status from the WI U for which the OBU has disabled enforcement (e.g., signal received 270 of FIG. 2), the OBU may re-enable the enforcement of the wayside devices 150 based on the updated WI U status (e.g., resume enforcement of signals 280 of FIG. 2). Should the communication fail again, or should an incorrect status be encountered again, the OBU may re-prompt the crew to disable enforcement after stopping in front of the next wayside device with unknown or incorrect status. After a preconfigured amount of time (e.g., a default of 1 hour), the OBU may enable the enforcement of the wayside devices that were previously disabled for enforcement if no WIU status is received for those wayside devices (e.g., reset after set time elapses 290 of FIG. 2).

Override Wayside Device Approach

[0018] The override wayside device approach may override the speed restriction associated with an individual wayside device where WIU status has not been received for that wayside device in a configurable time, or where incorrect status has been received. The override wayside device approach may be similar to the override WIU approach in that it addresses the use case where the crew can see that a wayside device indicates clear, yet the OBU prevents movement due to a WIU communication failure. However, unlike the override WIU approach, the override wayside device approach may override PTC enforcement for a single individual wayside device. The override wayside device approach may provide a high degree of operational safety with moderate user interaction and no need for reinitialization.

[0019] FIGS. 3A and 3B illustrate an example of the override wayside device approach, and FIG. 4 illustrates the override wayside device approach procedure. A train may approach a wayside device of unknown or incorrect state 310 (e.g., no signal received 410 of FIG. 4). When the train is within a configurable distance 320 (i.e., viewable distance) of the wayside device (e.g., train reaches configurable distance 420 of FIG. 4), the OBU may prompt the crew to indicate whether it is safe to proceed (e.g., prompt crew for override 430 of FIG. 4). The OBU may also wait for the train to stop to prompt the crew in some embodiments. In either case, if the wayside device indicates it is safe to proceed, the crew may observe this indication and confirm the prompt (e.g., override selected 440 of FIG. 4). If the wayside device indicates otherwise (i.e., STOP) (e.g., override not selected 440 of FIG. 4), the crew may follow the well-defined procedure to pass signal at stop (PSS) under restricted speed (e.g., perform standard procedures 450 of FIG. 4). If the override prompt is confirmed, the OBU may release the speed restriction of the wayside device and allow the train to proceed at track speed (e.g., proceed without enforcement of specific signal 460 of FIG. 2). The OBU may remain in the active mode and may continue to enforce all other speed restrictions (e.g., track speeds, temporary speed restrictions, end of authority limits, etc.). The OBU may continue to process messages from the BOS and WIUs. Display of overridden wayside devices may be indicated on the train HMI. If the train encounters another wayside device of unknown or incorrect status 340 along the route (e.g., in an area of wayside device outage 330), the OBU may perform the prompt procedure again.

[0020] The override WIU approach and the override wayside device approach may allow trains to pass wayside devices without stopping at each wayside device and allow trains to pass wayside devices at track speed (not restricted speed as with pass signal at stop). Each approach may allow the OBU to remain in the active mode and provide near full PTC protection. Each approach may only be triggered in case of failed communication with a wayside device or incorrect wayside device state identified by the crew, thus allowing safe and normal WIU communication when available. The override WIU approach and the override wayside device approach may limit the need for crew interaction in these situations, as the crew may not have to explicitly cut the OBU back in through the HMI. Each approach may be used without abbreviated initialization, as the OBU may maintain messaging with the BOS, other WIUs, and its own datasets. This may reduce errors which can occur during abbreviated initialization that would force a full train initialization.

Timer-Based Override Approach

[0021] At any time while the OBU is providing PTC functionality, the train crew may be able to initiate a temporary override. Once a temporary override is initiated, PTC

functionality may be disabled for a specified amount of time indicated by a timer. When the timer expires, the OBU may automatically return to a state providing full PTC functionality. FIG. 5 illustrates an example of the timer-based approach procedure. The procedure may begin when the OBU is in a state providing PTC and the crew determines a need to temporarily cut out the OBU. The crew may initiate a temporary override on the HMI, and their override request may be received by the OBU 510. The OBU may prompt for confirmation to cut out PTC for a preconfigured number of minutes (e.g., 30 minutes may be a default value in some embodiments), and the prompt may be communicated to the crew via the HMI 520. The crew may confirm the prompt via the HMI 530. The OBU may disable PTC enforcement 540 and operate in a PTC override mode. The OBU may provide a countdown display indicating when the temporary cut-out expires via the HMI 550. While PTC is not being enforced, the crew may control train operations without PTC restrictions imposed by the OBU (e.g., speed limits, etc.). While operating in the PTC override mode, the OBU may continue to process PTC messages from the WIU and the railroad's back offices 560 so that on a return to a state where PTC enforcement is provided, no additional crew and/or back office tasks (e.g., initialization) are required. The OBU may also continue to maintain its navigation 570, so that on return from cut-out it can enforce any PTC restrictions based on the location of the train. Once the temporary cutout time expires, the OBU may transition back to full PTC enforcement 580. Because PTC messages were processed in the background during cutout, and OBU navigation monitoring was maintained in the background during cutout, the OBU may transition back to PTC enforcement without performance of crew and/or back office tasks such as initialization.

[0022] By processing PTC messages and monitoring train movement while operating in the PTC override mode, the OBU may allow PTC operation to resume promptly upon expiration of the timer, because the scope of allowable operations for the location in which the train is operating will be known. The OBU may not need to receive updated information from the crew and/or railroad back office to resume PTC enforcement. Instead, the OBU may be able to effectively resume PTC enforcement from before PTC override occurred, taking into account PTC changes based on received wayside device statuses and/or train progress, without reentering information that was used to initialize the OBU at the start of the trip. Examples of tasks that may need not be performed upon return to PTC operation may include crew member employee name and ID number entry, clearance number, train ID, etc.; train makeup, manifest, type, etc.; trip information (times, route, etc.); route information, track database, etc. from back office; back office verification of information entered by crew; system tests; etc.

[0023] In the timer-based approach, the OBU may always automatically transition back to PTC after the cutout period elapses. Thus, the OBU cannot be left indefinitely in a state where PTC is disabled. Also, the crew may not have to explicitly cut back to PTC in the OBU through the HMI. The OBU may maintain communication with all external systems (e.g., WIU, back offices) and may maintain navigation so no additional crew tasks are required on PTC cut-in. Train Control

[0024] FIG. 6 shows a train control system 600 according to an embodiment of the invention. The system 600 may include an OBU 610, transceiver 620 (e.g., wireless transceiver, rail signal transceiver, etc.), HMI 630, and train systems (e.g., throttle, brakes, etc.) 640. The system 600 may control a train. For example, the OBU 610 may receive user commands via the HMI 630 and control the train systems 640 based on the user commands (e.g., a user instruction to slow the train may cause the system 600 to apply the brakes and/or reduce the throttle). Additionally, the OBU 610 may receive data from WIUs via the transceiver 620 and use this data to control the train (e.g., a WSM from a WIU may direct the system 600 to stop the train). The OBU 610 may include or be in communication with positioning systems (e.g., GPS) and/or may determine track position via statuses received from the transceiver 620. The system 600 may perform the override WIU approach 200 and/or the override wayside device approach 400 as described above.

[0025] As shown in FIGS. 1-2, in the override WIU approach, the transceiver 620 may receive no indication that it is safe to proceed from a WIU 110. Thus, the OBU 610 may control the train systems 640 to stop the train 120. The crew may use the HMI 630 to indicate that it is safe to proceed 130, and the OBU 610 may control the train systems 640 to move the train. As other wayside devices with unknown statuses are passed 140, the train may proceed without enforcement of unknown statuses 150. When the transceiver 620 receives a known status from a WIU 160, the OBU 610 may resume PTC enforcement for the train systems 640 normally and in accordance with the wayside device statuses.

[0026] As shown in FIGS. 3-4, in the override wayside device approach, the transceiver 620 may receive no indication that it is safe to proceed from a WIU 310. When the train reaches a configurable distance from the WIU 320, the OBU 610 may prompt the train crew for input via the HMI 630 as to whether the signal is clear 330. The crew may use the HMI 630 to indicate whether it is safe to proceed. If so, the OBU 610 may permit control of the train systems 640 to move the train 340. If not, the OBU 610 may cause the train systems 640 to stop the train. As other WIUs with unknown signals are approached 350, the prompting may be repeated. When the transceiver 620 receives a known signal from a WIU, the OBU 610 may resume PTC enforcement for the train systems 640 normally and in accordance with the WIU signals.

[0027] As shown in FIG. 5, in the timer-based override approach, the crew may use the HMI 630 to request and confirm a temporary PTC override. The OBU 610 may enable the override and provide a timer display via the HMI 630, indicating when the override will expire. During the override, train systems 640 may be controlled without PTC restrictions. During the override, the OBU 610 may receive PTC communications via the transceiver 620 and process the received communications. The OBU 610 may also continue to monitor train location during the override. When the override expires, the OBU 610 may resume PTC enforcement for the train systems 640 normally and in accordance with the PTC

communications received during the override, as well as any ongoing and future PTC communications.

[0028] While various embodiments have been described above, it should be understood that they have been presented by way of example and not limitation. It will be apparent to persons skilled in the relevant art(s) that various changes in form and detail can be made therein without departing from the spirit and scope. In fact, after reading the above description, it will be apparent to one skilled in the relevant art(s) how to implement alternative embodiments.

[0029] In addition, it should be understood that any figures that highlight the

functionality and advantages are presented for example purposes only. The disclosed methodology and system are each sufficiently flexible and configurable such that they may be utilized in ways other than that shown.

[0030] Although the term "at least one" may often be used in the specification, claims and drawings, the terms "a", "an", "the", "said", etc. also signify "at least one" or "the at least one" in the specification, claims, and drawings.

[0031] Finally, it is the applicant's intent that only claims that include the express language "means for" or "step for" be interpreted under 35 U.S.C. 112(f). Claims that do not expressly include the phrase "means for" or "step for" are not to be interpreted under 35 U.S.C. 112(f).