Interoperable train control (ITC)—positive train control (PTC) systems include on-board units (OBUs). The OBU provides 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 can be used to physically isolate a malfunctioning OBU from a locomotive's brake system.
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.
A software cutout can address the erroneous enforcement issue. However, a software cutout is not tied to any operational condition and thus is not limited in its effect. An example of a conventional software cutout use case is as follows:
Software cutout functionality can 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:
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.
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:
It is assumed that hazard detectors are treated as signal devices in both approaches.
Override WIU Approach
The override WIU approach may disable enforcement of signals from 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 WIU 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. In 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 WIU 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.
If the override prompt is confirmed, the OBU may disable enforcement of signals from all wayside devices associated with WIU 160 for which the OBU has not received status or has received incorrect status, for example all wayside devices in the area 130 served by the WIU 160. The OBU may know which wayside devices are associated with the WIU 160 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 WIU 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
If the OBU receives status from the WIU 160 for which the OBU has disabled enforcement (e.g., signal received 270 of
Override Wayside Device Approach
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 re-initialization.
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
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.
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 initialization data that may need not be entered 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.
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
As shown in
As shown in
As shown in
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.
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.
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.
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).
Number | Name | Date | Kind |
---|---|---|---|
5340062 | Heggestad | Aug 1994 | A |
5533695 | Heggestad | Jul 1996 | A |
5978718 | Kull | Nov 1999 | A |
5995881 | Kull | Nov 1999 | A |
6459965 | Polivka | Oct 2002 | B1 |
7236860 | Kane et al. | Jun 2007 | B2 |
7731129 | Stull | Jun 2010 | B2 |
20040069909 | Kane et al. | Apr 2004 | A1 |
20040102877 | Kane | May 2004 | A1 |
20040124315 | Kane | Jul 2004 | A1 |
20080103648 | Kanner | May 2008 | A1 |
20120323411 | Whitwam | Dec 2012 | A1 |
20140052315 | Isailovski | Feb 2014 | A1 |
20140114507 | Kernwein | Apr 2014 | A1 |
20150225003 | Morton | Aug 2015 | A1 |
20150232110 | Ghaly | Aug 2015 | A1 |
20150307119 | Ghaly | Oct 2015 | A1 |
20160257325 | Kernwein | Sep 2016 | A1 |
Number | Date | Country |
---|---|---|
3023409 | Jan 1982 | DE |
2505452 | Oct 2012 | EP |
Entry |
---|
Hann, Greg, “Incremental Train Control System”, IEEE Vehicular Technology Magazine, Dec. 2010, 6 pages. |
FTA Research, “Rail Transit Shared Use and Control Systems Study”, Final Report, Mar. 2014, FTA Report No. 0062, prepared by Lawrence E. Light, P.E., et al., 204 pages. |
Schmelzer, C., “Standardization of Cbtc Systems—Mixed Operation on Shared Lines in accordance with ERTMS/ETCS Standards”, Published in: 8th World Congress on Railway Research, May 18-22, 2008, COEX, Seoul, Korea, 12 pages. |
Ansaldo STS TPWS Training Module for Loco Pilots, 2010, 74 pages, downloaded from: http://elocos.railnet.gov.in/Study_Material/TPWS/LPs'Training%20Module.pdf. |
EPO machine translation of DE 3023409 (original German document published Jan. 14, 1982). |
ERTMS-ETCS Functional Requirements Specification (FRS, Mar. 12, 1999, 196 pages). |
UX Design Edge, “Are you sure? How to write effective confirmations”, Blog post be Everett McKay on Jun. 21, 2010, 6 pages, downloaded from: http://www.uxdesignedge.com/2010/06/are-you-sure-how-to-write-effective-confirmations/. |
Wikipedia article, Train Protection & Warning System, old revision dated Mar. 6, 2015, 6 pages. |
PCT International Search Report dated Apr. 7, 2017 corresponding to PCT International Application No. PCT/US2016/058609 filed Oct. 25, 2016 (20 pages). |
PCT Invitation to Pay Additional Fees dated Feb. 16, 2017 corresponding to PCT Application No. PCT/US2016/058609 filed Oct. 25, 2016 (8pages). |
Number | Date | Country | |
---|---|---|---|
20170113708 A1 | Apr 2017 | US |