The present invention relates to railways in general, and, more particularly, to a method for controlling train transitions between regional control centers.
Large networks, be they transportation networks or telecommunications networks, often span great distances (e.g., across the U.S., etc.). Due to their size, these networks typically comprise multiple instances of control centers, each of which has a specific geographic or regional zone of influence. A given regional controller is responsible for controlling traffic (e.g., airplane, train, wireless handset, etc.) that is within its zone of influence.
An issue that arises in all such networks is the transfer or “hand-off” of control responsibilities from one regional control center to the next in conjunction with the migration of the traffic.
Due to the nature of wireless communications and our very mobile society, hand-off from one wireless “base station” to the next must be computer-controlled and seamless. In transportation networks, the nature of the problem is somewhat different and hand-off is handled with far more operator intervention. In fact, in rail systems, hand off from one controller to the next involves virtually no automation. Furthermore, in rail systems, failover to a redundant system has been handled manually.
The present invention provides a way to automate the hand-off of control in a rail system and handle failover.
The inventors recognized that the issues of hand-off and failover are best treated as a single problem; that is, how does a vehicle vitally know with which control center it should be communicating?
The methods disclosed herein operate within the transportation server of each control center. In other words, the method is implemented as software suitable for running on the processor of a transportation server. In accordance with the illustrative embodiment, all relatively static data is stored redundantly at each control center, such that every center has a complete view of the transportation network. This reduces downtime and increases the probability that data is not corrupted in transit. This data is periodically validated between control centers and any modification of the data is immediately transferred to the others, with a positive acknowledgement required.
Dynamic data that is shared between the control center and train is stored only at the responsible control center and on the train itself. If the division between control centers is geographically based, any data that spans the border between control centers is tagged appropriately (e.g., an authority can be granted to a vehicle which exceeds the nominal territory handled by the control center, but it is tagged as “suspect” until validated by the next control center). Any valid control center can send a train the dynamic data so that the train acts independently of the control center with which it communicates. As a consequence, if control moves to a different center, the train will not be affected. An aspect of the illustrative embodiment is to embed information in the messages that are transmitted between a train and control centers so that positive identification is inherent to the messaging (prevents spoofing).
In case of a failure of a control center, the other control centers will notice the failure during periodic validation. Once failure is noticed, the other control centers take over control (upon human confirmation, if so configured). The control centers first determine which vehicles are affected (the vehicles will start to look for another control center when it's health check fails) and then by uploading all the dynamic data from those vehicles.
The terms below are defined for use in this disclosure and the appended
Each network control center 104 and 108 stores all relatively static data, such as the track database, etc. The purpose for this is to minimize downtime and increase the probability that such data is not corrupted in transit (i.e., if the data were not redundantly stored as described herein). This data is periodically synchronized and validated between the control centers (and other control centers that are not depicted in
Train 110 is provided with identifying codes for network control centers 104 and 108 (e.g., at installation, etc.). Likewise, the network control centers are provided with an identifying code for train 110. Imbedding the identifying codes in messages between the train and network control centers (or between network control centers) prevents spoofing.
Dynamic data that is shared between the control center and train is stored only at the responsible control center and on the train itself. This is distinct from the treatment of relatively static data, which is stored at all control centers, as disclosed above. If the division between control centers is geographically based, any data that spans the border between control centers is tagged appropriately. That is, an authority can be granted to a vehicle by a control center for territory that exceeds the nominal territory handled by that control center. But if such authority is granted, it is tagged as “suspect” until validated by nominal control center for the territory in question. Any valid control center can send a train the dynamic data so that the train acts independently of the control center with which it communicates. As a consequence, if control moves to a different center, the train will not be affected.
If and when a control center fails, other control centers will notice the failure during a periodic validation process. Once failure is noticed, the other control centers take over control (upon human confirmation, if so configured) what would otherwise be the failed controller's territory. The control centers first determine which particular vehicles are affected and then upload all the dynamic data from those vehicles. Identification of the affected vehicles is based on the fact that it is those vehicles that will start to look for another control center when its health check of the formerly-controlling control center fails.
The dynamic data is stored on both the train and at the first control center, as per operation 204. In accordance with operation 206, a second control center is notified that the train is in the first territory, wherein the second control center is responsible for controlling traffic within a second territory that is adjacent to the first territory. In the illustrative embodiment, the first control center notifies the second control center of the presence of the train in the first territory.
In operation 208, the first control center issues a grant of provisional authority to enter the second territory. This grant is considered suspect until validated by the second control center, which nominally controls the second territory.
In operation 210, the second control center grants the train full authority to enter the second territory when it is determined that it is safe to do so. At this point, the train will still be in the first territory. The second control center issues no other control messages until the train enters the second territory.
Furthermore, network control centers 104 and 106 communicate. In particular, and among any other messages, control center 104 advises control center 106 of the existence of train 110 in territory 102. Furthermore, control center 104 sends a message to control center 106 advising that it (control center 104) granted provisional authority to train 110 to enter territory 106. The purpose for the provisional grant is to reduce the likelihood that train 110 will be forced to stop before the “handoff” to control center 106 occurs.
Additional communications between the control centers 104 and 106, and between the control centers and a train, include the transmission of a “heart beat.” The heart beat is intended to gauge the health of the control center.
In accordance with operation 402, a first signal is transmitted from a first control center to a second control center, wherein the first signal is indicative of the operational status of the first control center.
A second signal is transmitted from the first control center to a train, wherein the second signal is indicative of the operational status of the first control center, as per operation 404.
A third signal is transmitted from the second control center to the first control center, wherein the third signal is indicative of the operational status of the second control center, in accordance with operation 406.
A fourth signal is transmitted from the second control center to the train, wherein the fourth signal is indicative of the operational status of the second control center, as per operation 408.
Using this method, it can be determined which, if any, of the first or second control center is having operational difficulties. This is discussed further in conjunction with
In
It is notable that train 110 might not be directly aware of the failover of control center 104 since the train simply validates messages that come from valid control centers; it does not have knowledge, per se, of the control center that originates the 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 Ser. No. 61/021,855, which was filed on Jan. 17, 2008 and is incorporated by reference herein.
Number | Date | Country | |
---|---|---|---|
61021855 | Jan 2008 | US |