The present invention relates to railway systems in general, and, more particularly, to train control systems.
Mandatory directives include the required enforceable “Train Control Data” for a train operating on controlled track. The Train Control Data includes information such as movement authorities, speed restrictions, and the like. This data must be transmitted from the controlling entity to the train both at the trip origin and while the train is en route.
Since this is critical train control data, the exchange of the data must be performed in a “vital” (i.e., safety critical) manner. Failure to deliver vital data can result in unsafe operation of a train. Furthermore, the data on-board must be verified as being current at a frequent rate to avoid operating with stale or missing data.
Transmission of this data occurs over a communications path that typically has a relatively limited bandwidth, yet must accommodate data exchanges between the controlling entity and all operating locomotives and equipped wayside devices. Furthermore, to react quickly to changes in the operating environment, it is important that communications latency is kept as low as possible.
The prevent invention provides a method for delivering and maintaining mandatory directives data from a central office server to an on-board system in an efficient and vital manner. In the illustrative embodiment, the method is applied to the central server architecture and requires no human intervention (e.g., a user controlling a locomotive by remote control, etc.). The method is implemented in software that is stored in computer-accessible memory and that is suitable for running on a general purpose processor at the central office as well as on-board a train.
The method thereby enables:
In accordance with the illustrative embodiment, the set of mandatory directives, which represents a significant quantity of data, is sent to the train only once, typically at the trip origin. Rather than re-transmitting the entire command data set at regular intervals for the purpose of updating and verifying the mandatory directives, the present method sends an error detection code, such as cyclical redundancy checks (“CRCs”) over data structures, at a fixed interval. In other words, the command data set is not resent. Rather, the current set of data identifiers and the associated error detection code are sent. Sending the error detection code instead of the large data set of mandatory directives requires significantly less bandwidth, while still validating the vitality of the on-board data. Also, since the error detection code comprises a much smaller data set than the entire command data set (i.e., the mandatory directives), a reduction in communications latency is expected as well.
In the illustrative embodiment, the on-board system checks for any inconsistency between its data (as previously transmitted) and the required data, as per the error correction code. If the on-board system detects an inconsistency, it will enter into a restrictive operating mode and report that condition to the controlling entity. Upon receiving such a report, the central server at the controlling entity (e.g., central control center, regional control center, etc.) initiates a synchronization sequence to update any necessary data on the train. Once the train's data is updated, the train is directed to return to a normal operating mode.
The error correction code is sent to the train on a regular basis in a “heartbeat” message that originates from the central server at the controlling entity. Since the heartbeat is sent on a regular basis, the timeliness of the data is ensured.
In addition to verifying the heartbeat data, the on-board system monitors for the absence of the heartbeat itself to detect communications outages. Since messaging is closed-loop, lack of a response by the train to the controlling entities' heartbeat alerts the controlling entity to any communications failure. The central server will time-out any message after a given amount of time (based on message type) and act appropriately. Denial of Service (“DOS”) attacks will cause the train to fail safely, since the heartbeat would be lost.
It is notable that the illustrative method ensures the integrity of data over the airways between two vital systems. Each system (i.e., the on-board system and the centralized server) is responsible for maintaining the integrity of data locally. But to the extent that data has been tampered with, the on-board system would detect a mis-compare between that data and the heartbeat error correction code and the system would fail safely.
This method does not address issues such as secrecy and authentication in conjunction with the transmission of the data between the controlling entity and the train. It is to be understood that encryption and authentication techniques can be used in conjunction with the present disclosure to address such issues. Those skilled in the art will know how to apply to implement encryption and authentication to the present method.
A method in accordance with the present invention comprises:
The following terms are defined for use in this disclosure and the appended claims as follows:
In operation 102 of method 100, the train monitors for a heartbeat message, which is transmitted over a wireless communications channel by the controlling entity. The heartbeat is transmitted at some frequent interval based on the allowed window of jeopardy for safety hazards and communications channel latency. The heartbeat includes error correction code for all vital data.
A variety of error correction codes are available for use in conjunction with the illustrative embodiment. One such code is a “cyclical redundancy check” or “CRC.” A CRC is a type of function that takes as input a data stream of any length, and produces as output a value of a certain space, commonly a 32-bit integer. The term “CRC” denotes either the function or the function's output. A CRC can be used as a checksum to detect accidental alteration of data during transmission or storage. CRCs are particularly good at detecting common errors caused by noise in transmission channels. CRCs are not standardized, although the CRC-32 polynomial, recommended by the IEEE and used by V.42, Ethernet, FDDI and ZIP and PNG files among others, is the generating polynomial of a Hamming code and is used for its error detection performance on communication channels.
If the heartbeat message is received, the on-board system transmits an acknowledgement of receipt to central server, as per operation 104. The on-board system then checks, in accordance with operation 106, the version of the mandatory directives that are stored on-board the train against the error correction code received in the heartbeat message. A discrepancy would indicate that there has been some data corruption and/or that the data is stale, due to transmission failures or communications outages.
Method 100 queries, at operation 108, whether there are any discrepancies. If there are no discrepancies, processing returns to operation 102 wherein the train waits to receive the next heartbeat message.
If the train does not receive the heartbeat message (operation 102) or discovers a discrepancy between the on-board version of the mandatory directives and the error correction code, the onboard system downgrades the train's operational status to a restricted mode (e.g., speed restrictions, altered permissions, etc.), as per operation 110.
The train transmits a message to the central server/controlling authority reporting the session failure, in accordance with operation 112. Assuming that there is a data discrepancy, the central server determines which data is responsible for the discrepancy and transmits this vital train control data to the on-board system. This transmission is not part of a heartbeat message. Thus, at operation 114, the train receives (re)synchronized data. Acknowledgement of receipt of the synchronized data is transmitted to the central server, as per operation 116.
Upon receiving confirmation from the train that the vital train control data has been synchronized, the central server will issue an authorization to resume normal operation. This may be transmitted with the heartbeat message. Thus, at operation 118, the train receives authorization to return to normal operating mode. The method then loops back to operation 102 wherein the train waits to receive the next heartbeat message.
It is to be understood that the disclosure teaches just one example of the illustrative embodiment and that many variations of the invention can easily be devised by those skilled in the art after reading this disclosure and that the scope of the present invention is to be determined by the following claims.
This case claims priority of U.S. Provisional Patent Application 61/021,847, which was filed on Jan. 17, 2008 and is incorporated by reference herein.
Number | Date | Country | |
---|---|---|---|
61021847 | Jan 2008 | US |