Patent ID: 12187333

DESCRIPTION OF THE PREFERRED EMBODIMENT

The present invention describes a new structure, and/or a new method to implement train control installations. This new implementation approach is based on cloud computing, and takes advantage of virtualization in order to partition a train control installation into two main parts. The first part, which is defined as the physical part, includes the onboard train control devices and the trackside signaling and train control equipment such as train detection devices, signals, track switch control equipment, and the like. The second part is defined as the virtual train control system, and includes the processing resources and associated train control application platforms that implements both safety critical and non-vital train control functions. Further, the second part includes a virtualization of the physical components included in the first part, which act as logical elements that interact with the train application platforms to provide a complete train control system in the cloud environment. The logical elements are also used to provide the interfaces between the physical installation and the virtual train control system. As such, each of the logical (virtual) elements of the virtual train control system communicates with a corresponding physical element in the train control installation. For example, in a communication-based train control implementation, a virtual on-board train control module or computer communicates with the on-board train control module or computer for the corresponding physical train. In general, a physical element provides status information to, and receives control data from, the corresponding virtual element. In the above CBTC example, the virtual on-board train control computer receives train location and speed information from, and sends movement authority limit data to the on-board train control computer for the corresponding physical train.

The use of cloud computing and associated virtualization provides a secure, highly available, agile and versatile computing environment for train control applications. It is preferable that the train control supplier maintains jurisdiction over the cloud computing environment. This will enable the user/operator at the transit or rail property to take the benefits of new technologies, without the need for deep knowledge of the technologies, and without the burden, responsibility and expense of maintaining new technology installations. Additional benefits of this approach are identified in the Summary Section of this application.

The preferred embodiment applies this new implementation approach to communication based train control (CBTC) technology, wherein the train control installation is partitioned into a physical installation that includes vital on-board computers that control the physical trains operating on the system, and the trackside signaling devices, and a virtual train control system located in a cloud computing environment. For the preferred embodiment, the virtual train control system includes the CBTC zone controllers (ZC) application, the Solid State Interlocking (SSI) control application, the Automatic Train Supervision (ATS) application that provide route selection and other service delivery functions, and the interfaces between ZC, SSI and ATS subsystems. The virtual train control system also includes logical elements that represent and emulates the operation of physical onboard computers and physical trackside signal equipment. The cloud computing provides a secure, highly available (almost fault free), versatile, and maintenance free (for the transit operator) environment to implement vital CBTC and interlocking functions, as well as non-vital and ATS functions.

Referring now to the drawings where the illustrations are for the purpose of describing the preferred embodiment of the invention and are not intended to limit the invention hereto,FIG.1is a block diagram of the general architecture used to implement a train control installation. The physical installation includes the trains operating on the line, wherein each train is equipped with an onboard train control computer2, which controls the safe operation of the train; an interlocking4that comprises an interlocking interface module36and the physical trackside signal devices such as track switches and associated controls, signals, train detection equipment, etc.; ATS interface30that is connected to a user interface22at the cloud computing environment10through a secure network connection16, and which is also connected to dispatcher workstations37and display panels39for the operators to control and monitor service delivery; a traffic controller38that generates service schedules and time tables; and a train control interface34that connects to a machine interface32at the cloud computing environment10through a secure network connection16, and which provides the main interface between the virtual train control system and the onboard train control computers2& the interlocking interface36. The physical installation also includes a data communication network that provides two way wireless communications between the train control interface34, and the onboard train computers2& the interlocking interface36.

The cloud computing environment10includes the hardware resources20needed for the implementation of the vital train application platform26(zone controllers and solid state interlocking control devices), as well as the non-vital application platform24(ATS servers and other non-vital subsystems). The cloud computing environment10also includes the user interface22and the machine interface32.

It should be noted that the architecture shown inFIG.1is presented herein for the purpose of describing the preferred embodiment, and is not intended to limit the invention hereto. For example, a transit property could elect to include the ATS servers as part of the physical installation. Also, the interconnection between the train control interface and the interlocking interface could be implemented through wire connection rather than the indicated wireless connection. Another alternative is to integrate the interlocking interface within the train control interface. Further, depending on transit property preference and/or standards, the interlocking equipment could be limited to switch machines and associated controls, or could include traditional train detection equipment and wayside signals. In addition, the traffic controller could be integrated as part of the ATS subsystem either at the cloud computing environment or within the physical installation.

Although it is desirable to locate the cloud computing resources at the train control supplier's facility, it is a design choice, or based on the implementation requirements, to place the cloud computing resources at a different location. For example, the cloud could be located at a secure facility that belongs to the transit or rail property, or it could be located at a facility managed by a third party provider. Further, the type of cloud used is a design choice, and could include a private internal, a hybrid cloud or an external cloud. In addition, the level of control the user (transit property) has over an application running in the cloud is a design choice and is subject to the understanding and agreement between the transit or rail property and the train control supplier (host).

FIG.2shows the main physical elements of a CBTC implementation and the corresponding logical elements in the virtual system within the cloud computing environment. Both the physical train control system44and the corresponding virtual train control system40have an identical track configuration and an identical number of trains operating in the territory. Further, the trains are shown at the same track locations at both the physical and virtual systems. In that respect, physical trains P-1, P-2, P-3 and P-442correspond to virtual (logical) trains V-1, V-2, V-3 and V-455. Similarly, physical track side interlocking devices: train detection blocks64, switch control equipment66, and wayside signals62correspond to the virtual (logical) interlocking devices: train detection blocks58, switch control equipment60, and wayside signals56. The virtual train control system also includes the zone controller application platform V-ZC40and the interlocking control application platform V-IXL46. The physical train control system includes the interlocking interface module50.

In addition,FIG.2shows the communications between physical trains and corresponding virtual (logical) trains52, as well as communications between the physical interlocking devices and the virtual interlocking control platform66. The ATS physical and virtual elements are not shown inFIG.2. It should be noted thatFIG.2depicts a section of the operating railroad. Similar to conventional train control system implementations, to equip an entire line with a train control system using this approach, the line is divided into sections. For each section, the train control system is partitioned into a physical installation and a virtual train control system. Trains are tracked as they move from section to section in both the physical and virtual environments. However, as stated above, an entire line can share the same cloud computing resources.

FIG.3shows a block diagram of the CBTC implementation in a section of the railroad, and demonstrates how the CBTC system is partitioned into a physical CBTC installation44and a virtual train control system (CBTC)40. The physical CBTC installation44includes a train control interface82, a data communication network18, an interlocking interface module50, onboard train control computers (for trains P-1, P-2, P-3 & P-4)42, and trackside interlocking devices: train detection blocks64, switch control equipment66and wayside signals62. The virtual train control system40includes the hardware computing resources70for the various train control application platforms, including the zone controller application platform80, the solid state application platform76, and the application platform that emulates the onboard train control computers55. Since the number of trains operating in the territory can vary, the virtual train control system provides a plurality (k) of computing modules55that emulate the onboard train control computers. Therefore, the maximum number of trains that can operate in this section of the railroad is limited to k.

The virtual train control system40also includes a plurality of logical elements or modules73that act as incubators to initialize a new train detected in the physical installation into the virtual train control system. This initialization process is not applicable to trains moving from adjacent sections of the railroad into this section. Those train are tracked by the system, and move from one section into an adjacent section (in both physical and virtual environments) using a transition process. Rather, the incubator process is intended to initialize a physical train when it is first detected in the train control installation. As a new physical train (P-i) is detected in the section, it is necessary to establish a corresponding virtual train in the virtual train control system. For the preferred embodiment, which implements CBTC technology, the detection is through radio communication. The initial frequency or radio channel assigned to the train is designed and/or configured to establish communication with one of the plurality of incubators73. Upon establishing such communication, the incubator requests the zone computer80to initialize train P-i into the virtual system40. It should be noted that this initialization is different from the initialization of a train into CBTC operation. The preconditions for CBTC train initialization include train localization and sweeping of relevant track section. Upon receiving a request from the incubator, the zone controller assigns an available logical module (virtual train) V-i to P-i. Then upon establishing communication between P-i & V-i, and if the pre-conditions for CBTC train initialization are satisfied, the zone computer80will issue a movement authority limit to V-i, which in turn will relay the movement authority to P-i. After the completion of this initialization process for train P-i, the zone computer releases the incubator so that the process is repeated when a new train is detected in this railroad section. The above described initialization process is shown inFIG.7. It should be noted that if physical train P-i does not meet the pre-conditions for CBTC initialization, it will still communicate with virtual train V-i, but will not be assigned a movement authority.

The virtual train control system (CBTC)40also includes machine interfaces72&78that represent the demarcation points for communications with the physical train control installation through a secure network connection16. In that respect,FIG.4shows the main communication channels between the physical installation and the virtual train control systems for CBTC implementation as per the preferred embodiment. In general, two way communications is required between physical trains and virtual (logical) trains52, between new detected trains and incubators84, between physical and virtual interlocking elements67, and between the ATS of the physical installation and the user interface at the virtual train control system82.FIG.5shows the various status information and control data exchanged between physical train P-i and corresponding virtual train V-i. It should be noted that the specific status information and control data shown inFIG.5are set forth for the purpose of describing the preferred embodiment, and are not intended to limit the invention hereto. As would be understood by a person of ordinary skills in the art, additional or different status information and control data may be exchanged between a physical train and a corresponding virtual train depending on CBTC system requirements and design.

Similarly,FIG.6shows the various status information and control data exchanged between physical interlocking elements and corresponding virtual elements. It should be noted that although it is not shown inFIG.3, the preferred embodiment includes as part of the V-IXL application platform76individual logical elements that emulate the various trackside interlocking devices. These logical elements represent virtual interlocking devices and act as the interfaces between the signal control logic included in the V-IXL application platform76, and the IXL Interface50that connects to the trackside interlocking devices62,64and66. It should also be noted that the specific trackside interlocking equipment will vary from system to system and from location to location, and as such the specific status information and control data exchanged between the physical installation and the virtual system will vary from installation to installation. In addition, the V-IXL application platform76could be based on an interlocking rules approach or could employ Boolean equations to implement signal control logic. As such, the specific implementation approach may require different and/or additional status information and/or control data exchanged between the physical installation and the virtual system. All such variations described above are within the scope of this invention.

Further, it should be noted, and as would be understood by a person with ordinary skills in the art, the interlocking configuration depicted inFIGS.1,2&3could be different, and could include wayside signals between interlockings to provide an auxiliary wayside signal (AWS) system to enable train service with signal protection during CBTC failures. In such a case, the entire system (CBTC and AWS) will be partitioned into a physical installation and a virtual train control system as described above. For the preferred embodiment described inFIG.3, the interfaces81between CBTC80and the interlocking system76are implemented in the virtual train control system40. This will facilitate the integration of the interlocking functions into CBTC operation.

With respect to the main operation of the CBTC system described inFIG.3, after system and train initializations, each physical train P-i42transmits its location to the corresponding virtual train V-i55in the virtual train control system. In turn, each virtual train V-i55transmits its location to the zone computer80. The zone computer80issues movement authority limits to the virtual trains55based on the latest train locations data received. Each virtual train55then sends the received movement authority to the corresponding physical train42. Upon receiving a movement authority limit, a physical train P-i generates a stopping profile from its current location to the end of the received movement authority limit, using track topography data stored in its vital on-board data base, and taking into account any civil speed limits reflected in the data base. The onboard computer then ensures that the physical train does not exceed the speed and the movement authority limit defined by the stopping profile. As the physical trains move on the track, they update their locations to the corresponding virtual trains, which report their updated locations to the zone computer. In turn the zone computer updates the movement authority limits to the various trains operating on the system, and the cycle repeats. For movement through an interlocking route, the zone computer ensures that the interlocking route is clear and that the switches are properly aligned and locked before issuing a movement authority through the route.

One of the advantages of the proposed CBTC architecture described inFIG.3is that it enables the implementation of temporary train functions for selected physical trains by incorporating such functions in the corresponding logical modules (virtual trains) at the virtual CBTC train control system. Since the logical modules act as the interface between the zone computer in the virtual environment and the onboard computers for the physical trains, and since the status information and control data for a specific physical train are available at the corresponding logical element, it is desirable to include temporary functions within the logical modules. For example, it may be necessary to limit the movement authority for a particular train, or a group of trains, to a predefined distance from current train location. Generally, the zone computer issues a movement authority that extends from current train location to the location of a train ahead. If a generated movement authority is longer than said predefined distance, then the logical module will truncate the movement authority received from the zone computer to the predefined distance before transmitting it to the corresponding physical train. The logical module can then monitor the location of the train, and will periodically transmit the remainder of the movement authority received from the zone computer, one section at a time, until the train reaches the limit of the authority generated by the zone computer.

Another example of the use of a logical module to implement a temporary train control function is to limit the operation of a specific train to a particular mode, or to exclude a mode of operation for that train. In general, the logical modules can be programmed to include a plurality of additional train control functions that can be exercised for a specific train or a group of trains if service conditions require it.

In addition, in the case of driverless operation, and if a physical train fails in revenue service, the corresponding logical module could be interfaced with a train simulator that has provisions for manual train controls. The train simulator could then be used to remotely operate the disabled or failed train up to the next station, where the train could be taken out of service.

With respect to failure modes management for the preferred embodiment, the proposed architecture has the added benefit of providing an almost fault free cloud computing environment for CBTC and interlocking application platforms. As such, a total failure of a zone computer application or a solid state interlocking control application is very unlikely. Potential failures of the installation that are unique to the proposed architecture include a loss of communication between a physical train and a virtual train, a loss of communication between physical interlocking elements and corresponding virtual elements, or a total loss of communication within a section of the railroad. If a physical train loses communication with its corresponding virtual train, the physical train will come to a full stop, and can be operated in a restricted manual mode, wherein its speed is limited. The corresponding virtual train will lose its movement authority limit, and its location will not be updated until communication is re-established with the physical train. It should be noted that when a virtual train loses communication with a physical train, it remains assigned to the physical train until communication is re-established, or the virtual train is released for reassignment by the system administrator (case when the physical train is taken out of service or leaves the section of the railroad).

Similarly, if communication is lost between the physical interlocking elements and the corresponding virtual elements, the physical elements will revert to the safe state (wayside signals will display a “stop” aspect, and switches will remain in the last position). Within the virtual train control system, all affected virtual train detection blocks will reflect an “occupied” status, all affected virtual switches will reflect “out of correspondence,” and all affected virtual signals will reflect “stop” aspect. The zone computer application will then determine the impact of the loss of communications on any issued movement authority limits, and will cancel all movement authorities affected by this loss of communications. In turn, affected virtual trains will relay the cancellation of movement authorities to corresponding physical trains. In the unlikely event of a total loss of communications between the physical train control installation and the virtual train control system, all affected physical trains will be brought to a full stop, and all affected wayside signal will display a “stop” aspect. In the virtual system, all affected virtual trains will lose their movement authority limits, and all affected virtual interlocking devices will assume a safe state. Upon reestablishing communications, the system and all trains operating in the section need to be initialized before normal train operation can resume.

As would be understood by those skilled in the art, alternate embodiments could be provided to implement a CBTC system using new concepts described herein. For example, the interlocking application platform could be implemented as part of the physical installation. Also, alternate cloud computing architecture could be used to implement the virtual train control system. Further, a different communications configuration could be used to exchange status information and control data between the physical train control installation and the virtual train control system. It is also to be understood that the foregoing detailed description of the preferred embodiment has been given for clearness of understanding only, and is intended to be exemplary of the invention while not limiting the invention to the exact embodiments shown.

DESCRIPTION OF A FIRST ALTERNATE EMBODIMENT

The objectives of the invention could also be achieved by a first alternate embodiment that provides a train control installation, which employs cab-signaling technology. This embodiment takes advantage of cloud computing and virtualization in order to enhance the safety and performance of existing cab-signaling installation, or alternatively to provide a new train control installation. For the remaining description of this first alternate embodiment, it is assumed that the scope of the cloud computing implementation is to enhance the safety and performance of an existing cab-signaling installation. As such, the main objectives of this implementation include providing positive train control (PTC), and enhancing the track capacity of the existing installation (i.e. reduce the operating headway). Other objectives include protection against wrong-side track circuit failure (false clear), enforcement of civil speed limits and temporary speed restrictions, provide a CBTC type operation (distance-to-go operation), and modernization of existing interlocking control devices. It should be noted that the above scope of work and objectives are set forth herein for the purpose of describing the first alternate embodiment, and are not intended to limit the invention hereto. As would be appreciated by a person of ordinary skills in the art, if the scope of the cloud computing implementation includes providing a new train control installation based on cab-signaling technology, then the objectives of the implementation could include the same or different objectives as set forth herein.

Similar to the preferred embodiment, the train control installation for the first alternate embodiment is partitioned into two main parts. The first part includes the existing cab-signaling installation augmented by an independent train location determination subsystem, a wireless data network that provides two-way communications between physical trains and wayside interface modules, train control devices on-board physical trains that provide CBTC type operation (i.e. distance-to-go operation) in addition to cab-signaling operation during certain failure modes, and interlocking interface modules to monitor and control track side interlocking devices. The independent train location determination subsystem could be implemented using transponder based technology, wherein transponders are installed on the track bed to provide reference locations. Between transponders, trains continue to compute their locations and speeds using on-board odometry devices. The train location determination subsystem could also be based on global position satellite (GPS) technology,FIG.8loops, triangulation of radio signals, etc.

The second part of the installation is defined as the virtual train control system, and includes the processing resources and associated train control application platforms that provide the safety critical train control functions necessary to achieve the objectives of the first alternate embodiment. Further, the second part includes a virtualization of physical components included in the first part, which act as logical elements that interact with the train application platforms to provide a complete train control system in the cloud environment. The logical elements are also used to provide the interfaces between the physical installation and the virtual train control system. As such, each of the logical (virtual) elements of the virtual train control system communicates with a corresponding physical element in the train control installation. For example, a virtual on-board train control module (or computer) communicates with the on-board train control module or computer for the corresponding physical train. For the first alternate embodiment, virtual on-board train control computer receives train location and cab-signaling speed code information from, and sends movement authority limit data to, the on-board train control computer for the corresponding physical train.

The virtual train control system includes a MAL Conversion Processor (MCP), which includes a data base that stores information related to track topography (curves, grades, super elevation, etc.), locations and types of signal equipment on the track, including transponders, civil speed limits, cab-signaling blocks and their boundaries, and speed code charts that indicate the cab-signaling speed codes for each block for various traffic conditions (i.e. the block ahead where an obstacle is located. An obstacle includes a train ahead, a signal displaying a “stop” aspect, a switch out of correspondence, an end of track, etc.). The MCP converts speed codes generated by the physical cab-signaling speed codes, and transmitted from physical trains to virtual trains, into movement authority limits (MAL). The MCP also checks the integrity of the cab-signaling detection blocks by ensuring that there are no physical trains located within the boundaries of a generated MAL. In addition, based on the scope of work of the first alternate embodiment, the virtual train control system includes Solid State Interlocking (SSI) control application that provide the vital logic necessary to control the physical trackside interlocking devices. The virtual train control system also includes logical elements that represent and emulates the operation of on-board computers located at physical trains, and physical trackside signal equipment. The cloud computing provides a secure, highly available (almost fault free), versatile, and maintenance free (for the transit operator) environment to implement the enhancements to the existing cab-signaling installation and the required interlocking functions.

Referring now to the drawings where the illustrations are for the purpose of describing the first alternate embodiment of the invention and are not intended to limit the invention hereto,FIG.10shows the main physical elements of the cab-signaling installation and the logical elements for the overlay virtual system within the cloud computing environment. Both the physical cab-signaling system94and the overlay virtual train control system90have an identical track configuration and an identical number of trains operating in the territory. Further, the trains are shown within the same cab-signaling blocks at both the physical and virtual systems. In that respect, physical trains P-1, P-2, P-3 and P-492correspond to virtual (logical) trains V-1, V-2, V-3 and V-495. Similarly, physical track side interlocking devices: train detection blocks120, switch control equipment122, and wayside signals118correspond to the virtual (logical) interlocking devices: train detection blocks116, switch control equipment114, and wayside signals110. The virtual train control system also includes the MAL conversion processor application platform MCP104, which interface with the virtual trains95through a train interface module106. As disclosed above, the MCP104includes a data base that stores information related to track topography (curves, grades, super elevation, etc.), locations and types of signal equipment on the track, including transponders, civil speed limits, cab-signaling blocks and their boundaries, and speed code charts that indicate the cab-signaling speed codes for each block for various traffic conditions (i.e. the block ahead where an obstacle is located). In addition, the virtual train control installation includes the interlocking control application platform V-IXL108. The physical train control system includes the interlocking interface module124.

FIG.11shows the general process proposed by the first alternate embodiment to convert cab-signaling speed codes103to corresponding movement authority limits107. The prior art (U.S. Pat. No. 8,200,380) describes two main steps to convert cab-signaling speed codes to movement authority limits. The first step is to identify the cab-signaling block VT-k where a train V-i is located109using physical train location113(as calculated by the independent train location determination subsystem), and the cab-signaling block boundaries (stored in the data base of the MCP104). The second step is to convert the cab-signaling speed code Si received from the physical train into a movement authority limit MAL-i based on the block where the train is located VT-k and the traffic condition corresponding to said cab-signaling speed code111.

The MCP104of the first alternate embodiment implements the added safety function of ensuring that no train is present within a block included in a movement authority limit MAL-i115. The existing cab-signaling installation employs vital logic, which ensures that a cab-signaling speed code is generated only if the associated control line is clear. However, under very rare conditions, one of the cab-signaling detection blocks can fail to detect a train, resulting in a false clear, or the generation of a false cab-signaling speed code.

FIG.12demonstrates such rare condition (operational scenario) when a detection block fails to detect a train, and how the first alternate embodiment mitigates the safety risk associated with such unsafe failure. In the shown example, detection block T-5134fails to detect train P-1132. In the absence of any mitigation provision, train P-1132will be invisible to the cab-signaling installation, and as such the cab-signaling system will generate a speed code to train P-2130that will place it on a collision course with train P-1132. Pursuant to the design requirements of the first alternate embodiment, physical trains P-2130& P-1132communicate142&140their locations to corresponding virtual trains V-2136& V-1138. In addition, physical train P-2130communicates142its speed code to virtual train V-2136. The MCP104will then convert the speed code received from physical train P-2130into a corresponding movement authority limit. As shown inFIG.11, the MCP104will then validate that the detection blocks included in the movement authority limit are vacant115. Because train P-1132has communicated its location (that was determined independent of the failed detection block T-5134) to virtual train V-1138, the MCP104will prevent the transmission of a movement authority limit to physical train P-2130, thus mitigating the safety risks associated with the failure of detection block T-5134to detect physical train P-1132.

It should be noted that the MCP104relies on receiving the location of train P-1132through radio communication in order to perform the safety check115of validating that all blocks included in the movement authority limit are vacant. While such reliance is not considered fail-safe (if train P-1132fails to communicate with virtual train V-1138, then the MCP104will not be able to detect the presence of train P-1132within detection block T-5134), the probability of occurrence of such double failure condition is very low. This is the case because this double failure condition is based on an unlikely failure in detection block T-5134to detect train P-1132, and at the same time a failure in the communication link between physical train P-1132and virtual train V-1138. This would require two independent failures in two independent systems, affecting the same train, which is very unlikely.

FIG.13shows a block diagram of an overlay train control implementation to enhance the safety and operational performance of a cab-signaling installation in a section of the railroad. The block diagram demonstrates how the enhanced train control system is partitioned into a modified physical cab-signaling installation94and a virtual train control system (Cab-Signal)90. The modified physical cab-signaling installation94includes the original cab-signaling blocks and associated cab-signaling equipment, a train control interface117, a data communication network121, an interlocking interface module124, new onboard train control computers (for trains P-1, P-2, P-3 & P-4)92, and trackside interlocking devices: train detection blocks120, switch control equipment122and wayside signals118. The virtual train control system90includes the hardware computing resources109for the various train control application platforms, including the MAL Conversion Processor MCP application platform104, the solid state application platform131, and the application platform that emulates the onboard train control computers95. Since the number of trains operating in the territory can vary, the virtual train control system provides a plurality (n) of computing modules95that emulate the onboard train control computers. Therefore, the maximum number of trains that can operate in this section of the railroad is limited to n.

The virtual train control system90also includes a plurality of logical elements or modules103that act as incubators to initialize a new train detected in the physical installation into the virtual train control system. This initialization process is not applicable to trains moving from adjacent sections of the railroad into this section. Those train are tracked by the system, and move from one section into an adjacent section (in both physical and virtual environments) using a transition process. Rather, the incubator process is intended to initialize a physical train when it is first detected in the train control installation. As a new physical train (P-i) is detected in the section, it is necessary to establish a corresponding virtual train (V-i) in the virtual train control system. For the first alternate embodiment, which implements Cab-signaling technology, the detection is through radio communication. The initial frequency or radio channel assigned to the train is designed and/or configured to establish communication with one of the plurality of incubators103. Upon establishing such communication, the incubator requests the MCP104to assign a virtual train to physical train P-i, and initialize the virtual train into the virtual system90. The initialization process is coordinated with the MCP task to determine the cab-signaling block VT-k where V-i is located109(FIG.11). Upon receiving a request from the incubator, the MCP assigns an available logical module (virtual train) V-i to P-i. Then upon establishing communication between P-i & V-i, the MCP104will determine a movement authority limit to V-i, which in turn will relay the movement authority to P-i. After the completion of this initialization process for train P-i, the MCP releases the incubator so that the process is repeated when a new train is detected in the railroad section. The above described initialization process is shown inFIG.14.

The virtual train control system (Cab-Signal)90also includes machine interfaces107&119that represent the demarcation points for communications with the physical train control installation94through a secure network connection101. In that respect,FIG.15shows the main communication channels between the physical installation and the virtual train control systems for an overlay to a cab-signaling implementation as per the first alternate embodiment. In general, two way communications97is required between physical trains92and virtual (logical) trains95, between new detected trains and incubators133, between physical and virtual interlocking elements135, and between the ATS of the physical installation and the user interface at the virtual train control system137.FIG.16shows the various status information and control data exchanged between physical train P-i and corresponding virtual train V-i. It should be noted that the specific status information and control data shown inFIG.16are set forth for the purpose of describing the first alternate embodiment, and are not intended to limit the invention hereto. As would be understood by a person of ordinary skills in the art, additional or different status information and control data may be exchanged between a physical train and a corresponding virtual train depending on the requirements and design for the cab-signaling overlay system.

Similar to the preferred embodiment, the V-IXL application platform131could be based on an interlocking rules approach or could employ Boolean equations to implement signal control logic. In addition, the specific trackside interlocking equipment can vary from system to system and from location to location. As such, the specific status information and control data exchanged between the physical installation and the virtual system will vary from installation to installation All such variations described above are within the scope of this invention. With respect to the interfaces123between the V-IXL application platform131and the MCP104, the V-IXL provides the MCP with the status of interlocking equipment, including switch positions and signal status. In addition, as shown inFIG.15, the MCP receives data related to temporary speed restrictions and work zones from a user interface that communicates with an ATS subsystem137.

With respect to the main operation of the enhanced cab-signaling system described inFIGS.10&13, each physical train P-i92receives a cab-signaling speed code from the existing cab-signaling installation. In addition, each physical train P-i determines its own location using an independent location determination subsystem. Each physical train P-i then transmits its location and cab-signaling speed to the corresponding virtual (logical) train V-i95in the virtual train control system. In turn, each virtual train V-i95communicates its location and cab-signaling speed code to the MCP104. Using a data base that stores data related to the cab-signaling blocks, the MCP104converts cab-signaling speed codes into corresponding movement authority limits, and communicates the calculated movement authority limits to the virtual (logical) trains95. Each virtual train95then sends the received movement authority limit to the corresponding physical train92. Upon receiving a movement authority limit, a physical train P-i generates a stopping profile from its current location to the end of the received movement authority limit, using track topography data stored in its vital on-board data base, and taking into account any civil speed limits reflected in the data base. The onboard computer then ensures that the physical train does not exceed the speed and the movement authority limit defined by the stopping profile. As the physical trains move on the track, they update their locations and cab-signaling speed codes to the corresponding virtual trains, which report their updated information to the MCP. In turn the MCP updates the movement authority limits to the various trains operating on the system, and the cycle repeats. For movement through an interlocking route, the MCP ensures that any generated movement authority limit reflects switch positions within the interlocking, as well as the statuses of the wayside signals as they relate to the cab-signaling speed codes. For example, the MCP will resolve any uncertainty related to positive stop requirement by ensuring that a movement authority limit is not provided through an interlocking signal that displays a “stop” aspect.

Similar to the preferred embodiment, the logical modules (virtual trains) could be used to implement additional train control functions that can be exercised for a particular train or a group of trains if service conditions require it. The logical modules can also implement temporary train control functions that could limit the functions available onboard specific trains. In addition, in the case of driverless operation, and if a physical train is disabled or fails in revenue service, the corresponding logical module could be interfaced with a train simulator that has provisions for manual train controls. The train simulator could then be used to remotely operate the disabled or failed train up to the next station, where the train could be taken out of service.

With respect to failure modes management for the first alternate embodiment, the proposed architecture has the advantage of providing an almost fault free cloud computing environment for an overlay that enhances the safety and operational flexibility of an existing cab-signaling installation. As such, a total failure of a Mal Conversion Processor or a solid state interlocking control device is very unlikely. Potential failures of the installation include a loss of communication between a physical train and a virtual train, a loss of communication between physical interlocking elements and corresponding virtual elements, or a total loss of communication within a section of the railroad. If a physical train loses communication with its corresponding virtual train, the physical train can be operated in a cab-signaling mode of operation using cab-signaling speed codes. In such a case, the affected train will lose the safety and operational benefits provided by this overlay installation, but the train will continue to operate under cab-signaling protection. The corresponding virtual train will lose its movement authority limit, and its location will not be updated via information received from the corresponding physical train. However, the MCP can still track the physical train on a non-vital basis using data received from the ATS subsystem, or based on speed codes received from a following physical train. It should be noted that when a virtual train loses communication with a physical train, it remains assigned to the physical train until communication is re-established, or the virtual train is released for reassignment by the system administrator (case when the physical train is taken out of service or leaves the section of the railroad).

Similarly, if communication is lost between the physical interlocking elements and the corresponding virtual elements, the physical elements will revert to the safe state (wayside signals will display a “stop” aspect, and switches will remain in the last position). Within the virtual train control system, all affected virtual train detection blocks will reflect an “occupied” status, all affected virtual switches will reflect “out of correspondence.” and all affected virtual signals will reflect “stop” aspect. The MCP will then determine the impact of the loss of communications on any issued movement authority limits, and will cancel all movement authorities affected by this loss of communications. In turn, affected virtual trains will relay the cancellation of movement authorities to corresponding physical trains, which will then operate in cab-signaling mode.

In the unlikely event of a total loss of communications between the physical train control installation and the virtual train control system, all affected physical trains will operate in cab-signaling mode using cab-signaling speed codes. Also, all affected wayside signals will display a “stop” aspect. In the virtual system, all affected virtual (logical) trains will lose their movement authority limits, and all affected virtual interlocking devices will assume a safe state. Upon reestablishing communications, the system and all virtual trains operating in the section need to be initialized before the enhanced train operation can resume.

As indicated above, virtualization and cloud computing environment could be used to provide a new train control system based on cab-signaling technology. Two alternate design approaches are presented. InFIG.8, the physical train control installation includes the physical cab-signaling blocks, and a cab-signaling interface module that provides interconnections to inject cab-signaling speed codes into the rails. The virtual train control system (Cab-Signal) includes a virtual cab-signaling application platform that provides the vital logic to generate cab-signaling speed codes. The physical cab-signaling train detection blocks send the block occupancy information to corresponding logical (virtual) elements at the virtual train control system. In turn, these logical elements interface with the virtual cab-signaling application platform and provide the statuses of the physical train detection blocks. The cab-signaling application platform processes the statuses of the train detection blocks to generate a cab-signaling speed code for each block. The speed codes are communicated to the cab-signaling interface module in the physical installation, which in turn transmits them to the various blocks.

FIG.9demonstrates an alternate design to provide a new train control system based on cab-signaling technology. Under this architecture, speed codes are not injected into the rails of cab-signaling blocks, rather speed codes are communicated from logical (virtual) trains in the virtual train control system (cloud computing environment) to corresponding physical trains via a wireless data network. Also, physical trains have on-board equipment to determine train location independent of train detection blocks. The physical trains communicate their location to corresponding virtual (logical) trains. In turn, the virtual trains interface with the virtual cab-signaling application platform to provide the locations of the physical trains. Similar to the system described inFIG.8, the virtual cab-signaling application platform calculates cab-signaling speed codes based on statuses of physical train detection blocks. The virtual cab-signaling application platform then transmits the generated speed codes to the virtual trains based on the location information received from the physical trains. In turn the virtual trains send the speed codes to associated physical trains.

As would be understood by those skilled in the art, different alternate embodiments can be provided to implement or enhance a cab-signaling installation using the concepts described herein. For example, the interlocking application platform could be implemented as part of the physical installation. Also, alternate cloud computing architecture could be used to implement the virtual train control system. Further, a different communications configuration could be used to exchange status information and control data between the physical cab-signaling installation and the virtual train control system. It is also to be understood that the foregoing detailed description of the first alternate embodiment has been given for clearness of understanding only, and is intended to be exemplary of the invention while not limiting the invention to the exact embodiments shown.

DESCRIPTION OF A SECOND ALTERNATE EMBODIMENT

The objectives of the invention could also be achieved by a second alternate embodiment that provides a train control installation, which employs fixed block, wayside signals technology. This embodiment takes advantage of cloud computing and virtualization in order to provide an auxiliary wayside signal (AWS) system that operates either as a standalone installation or in conjunction with communications based train control (CBTC). A standalone AWS installation provides signal protection for unequipped trains operating in manual mode. The AWS installation can also provide distance-to-go operation for trains equipped with onboard CBTC equipment, and will provide shorter headways for such trains. When used in conjunction with either a CBTC system, or equipped CBTC trains, the combined CBTC & AWS installation will support mixed fleet operation, and will provide signal protection for both equipped and unequipped trains. As such, the main objective of this implementation is to provide a cost effective and functionally enhanced auxiliary wayside signal installation based on fixed block wayside technology. The enhanced AWS installation can provide positive stop enforcement, continuous over speed protection, increased track capacity, protection against wrong-side track circuit failure (false clear), enforcement of civil speed limits and temporary speed restrictions, protection of work zones and a distance-to-go operation (compatible with CBTC).

Similar to the preferred embodiment, the train control installation for the second alternate embodiment is partitioned into two main parts. The first part comprises the physical AWS installation that includes wayside signal equipment, a wireless data network that provides two-way communications between equipped physical trains and wayside interface modules, a two-way communications between wayside signal locations and signal interface units, and train control devices on-board equipped physical trains that provide CBTC type operation (i.e. distance-to-go operation). It should be noted that unequipped trains can also operate in a manual mode with wayside signal protection in this section of the railroad. Equipped trains employ an independent train location determination subsystem, which could be implemented using transponder based technology, wherein transponders are installed on the track bed to provide reference locations. Between transponders, trains continue to compute their locations and speeds using on-board odometry devices. The train location determination subsystem could also be based on global position satellite (GPS) technology,FIG.8loops, triangulation of radio signals, etc.

The second part of the installation is defined as the virtual train control system, is implemented in a cloud computing environment, and includes the processing resources and associated train control application platforms that provide the safety critical train control functions necessary to achieve the objectives of the second alternate embodiment. Further, the second part includes a virtualization of physical components provided in the first part, including virtual signal locations and virtual trains that correspond to physical equipped trains. These virtual components act as logical elements that interact with the train application platforms to provide a complete train control system in the cloud environment. The logical elements are also used to provide the interfaces between the physical installation and the virtual train control system. As such, each of the logical (virtual) elements of the virtual train control system communicates with a corresponding physical element in the train control installation. For example, a virtual on-board train control module (or computer) communicates with the on-board train control module or computer for the corresponding equipped physical train. For the second alternate embodiment, a virtual on-board train control computer receives train location information from, and sends movement authority limit data to, the on-board train control computer for the corresponding equipped physical train. Also, a virtual signal application processor communicates with a signal interface unit in the physical train control system to exchange data that include the statuses of signal equipment associated with wayside signal locations, and the controls for said signal equipment. In effect, and since the virtual signal locations act as interface modules for the corresponding physical signal locations, each physical signal location sends the statuses of associated signal equipment to, and receives control data from, the corresponding virtual signal location.

The virtual train control system includes a virtual signal application processor (VSAP) that provides the control logic for the wayside signal locations. The virtual train control system also comprises a MAL Conversion Processor (MCP), which includes a data base that stores information related to track topography (curves, grades, super elevation, etc.), locations and types of signal equipment on the track, including transponders, civil speed limits, fixed blocks and their boundaries, and control lines data for wayside signals. The virtual train control system further includes logical elements that represent and emulates the operation of on-board computers located at physical trains, and physical trackside signal equipment. The cloud computing provides a secure, highly available (almost fault free), versatile, and maintenance free (for the transit operator) environment to implement an auxiliary wayside signal installation.

A control line for a wayside signal identifies the train detection blocks that must be vacant before the signal can display a “clear” aspect. For the second alternate embodiment, the fixed block signal installation is based on a three-aspect operation that include a “red” aspect for stop, a “yellow” aspect for proceed with caution, and a “green” aspect for proceed at maximum allowable speed. As such, a “clear” aspect is defined as either a “yellow” or a “green” aspect. Further, a signal location includes an automatic train stop that enforces a “red” aspect. The control line normally includes at least one overlap block that provides sufficient breaking distance for a train to stop if it is “tripped” by the automatic train stop when travelling at maximum attainable speed. The term “tripped” means that the brake system on-board the train was activated by the automatic train stop on the wayside.

The MCP converts a clear signal aspect (“yellow” or “green”) for an approaching equipped train into a movement authority limit (MAL). Because an equipped train is continuously controlled by the on-board equipment (that also provides continuous over-speed protection), the limit of the movement authority can extend through the entire length of the control line, including the overlap block or blocks. As such, a MAL associated with a “yellow” signal extends from the location of the signal past at least one stop (“red”) aspect. Similarly, a MAL associated with a “green” signal extends from the location of the signal, through the “yellow” signal ahead, and past at least one “stop” aspect. This necessitates overriding the wayside signals and associated train stops at the signal locations included within the movement authority limit. For the second alternate embodiment, each signal location includes an additional aspect that displays an “X” to indicate to an approaching equipped train that the conventional wayside signal indication (red, yellow or green) has been overridden.

The MCP communicates the MAL to the virtual signal application processor that provides the control logic for the wayside signal locations. In turn, the VSAP activates the “X” aspect at the signal locations that are located within the MAL, and ensures that the automatic train stops at these locations are in the clear position. The VSAP will then send status data that reflects the clear position of these automatic train stops to the MCP. Upon receiving the automatic stop status data from the virtual signal application processor, the MCP transmits the MAL to the approaching virtual train, which in turn transmits the MAL to the associated physical train. The timing of transmitting a MAL to an approaching train takes into consideration the location of the approaching train relative to the wayside signal, and ensures that there is no short train between the approaching train and the signal at the time the MAL is transmitted to the train. The MCP also checks the integrity of the fixed train detection blocks by ensuring that there are no physical trains located within the boundaries of a generated MAL. It should be noted that the use of an “X” aspect to override a wayside signal location is a design choice. As would be appreciated by a person with ordinary skills in the art, a different aspect could be used to provide the override indication. For example, a flashing green aspect could be generated at a signal for an approaching equipped train with a MAL that overlaps the signal.

It should also be noted that the use of a centralized MCP is a design choice. As would be understood by a person with ordinary skills in the art, the MCP functions could be implemented at each of the logical elements that represent virtual trains. In such distributed architecture, each virtual (logical) train converts a clear signal aspect (“yellow” or “green”) of a signal ahead into a corresponding movement authority limit (MAL). Each virtual train then communicates the MAL to the virtual signal application processor that provides the control logic for the wayside signal locations. In turn, the VSAP activates the “X” aspect at the signal locations that are located within the MAL, and ensures that the automatic train stops at these locations are in the clear position. The virtual signal application processor will then send status data that reflects the clear position of these automatic train stops to the virtual train. Upon receiving the automatic stop status data from the VSAP, the virtual train will transmit the MAL to the associated physical train.

Referring now to the drawings where the illustrations are for the purpose of describing the second alternate embodiment of the invention and are not intended to limit the invention hereto,FIGS.17&18show the main physical elements of the AWS installation and the logical elements for the overlay virtual system within the cloud computing environment. Both the physical AWS system160and the overlay virtual train control system154have an identical track configuration and an identical number of trains operating in the territory. Further, the trains are shown within the same fixed blocks at both the physical and virtual systems. In that respect, physical trains P-1, P-2 and P-5168correspond to virtual (logical) trains V-1, V-2 and V-5156. Similarly, physical train detection blocks170, wayside signals184, and wayside automatic train stops164correspond to the virtual (logical) elements that include train detection blocks172, signals174, and automatic train stops173. The virtual train control system also includes a virtual signal application processor152that provides the control logic for the wayside signals174, the MAL conversion processor application platform (MCP)150, which interfaces with the virtual trains156through a train interface module186. As disclosed above, the MCP150includes a data base that stores information related to track topography (curves, grades, super elevation, etc.), locations and types of signal equipment on the track, including transponders, civil speed limits, fixed train detection blocks180and their boundaries, and control lines for the wayside signals166&186. An interface between the MCP150and the virtual signal application platform152allows for exchange of data required to override wayside signals174and provide status of automatic train stops182. The VSAP152also communicates with a signal interface module158within the physical train control installation to provide control data for the signal equipment at wayside signal locations162, and to receive status data from the signal equipment.

A typical signal location for the second alternate embodiment is shown inFIG.19, and includes a signal head200, an automatic mechanical train stop202, with associated circuit controller204(that provides the status of the train stop), a fixed block train detection module206, a radio communication module208with associated antenna184, an interface module209, related to fixed block train detection from the fixed block train detection module206, as well as the status of the automatic train stop202from its associated circuit controller204, via the radio communication module208. The VSAP152then generates control data for the wayside signal locations162using the status data received from the various signal locations162, control line information166&186, and data received from the MCP150. At each signal location162, a processor module210processes received control data to activate the appropriate aspects at the signal head200and the automatic train stop202. In the event of a failure, such as a loss of communication, the processor module210is programmed to enable trains to “key-by” the signal location. To use the “key-by” function, a train must proceed at a low speed (10 mph) into the block ahead of the signal, which will cause the automatic stop to drive to the clear position. Thus it allows the train to move past the red signal. The interface modules209include the necessary electrical circuits to interface with the signal equipment. It should be noted that it is a design choice to perform additional control logic at each signal location. For example, the processor210could be programmed to provide certain control and/or monitoring functions related to the associated signal equipment using data received from the VSAP152. The monitoring functions could include detection of failure conditions and maintaining statistics related to maintenance activities.

It should also be noted that the use of radio communication184to interconnect the wayside locations162with signal interface unit158is set forth herein for the purpose of describing the second alternate embodiment, and is not intended to limit the invention hereto. As would be understood by a person with ordinary skills in the art, other means of communication could be used. For example, a data network based on fiber optic technology could be used to interconnect the wayside locations162with the signal interface unit158.

FIG.17shows the wayside signal installation with manual train operation, wherein the aspects displayed at the various signal locations163are based on the control lines166&186and the locations of indicated trains168. This manual operation is based on the use of unequipped trains, or equipped trains operating in manual mode. As such, no conversions of signal aspects to movement authority limits take place.

FIG.18shows the wayside signal installation ofFIG.17with distance-to-go operation. During this type of operation, the MCP150converts wayside signal aspects163to corresponding movement authority limits175for approaching trains based on the control lines associated with wayside signals166&186. Further, the VSAP152overrides wayside signals to display an “X”174for approaching equipped trains. As disclosed above, a movement authority limit175enables trains to operate closer together, thus reducing the operating headway. For example, under a distance-to-go operation, train P-1168is permitted to proceed past the red aspect of Sig-3 to the end of block TC-3. This represents a reduction in train separation190that is equal to the length of fixed block TC-3.

FIG.20shows the general process proposed by the second alternate embodiment to convert clear signal aspects163to corresponding movement authority limits175. The first step is to identify the fixed detection block VTC-k where a train V-i is located209using physical train location Li213(as calculated by the independent train location determination subsystem), and the fixed detection block boundaries (stored in the data base of the MCP150). The second step211is to identify the closest wayside signal VSig-k ahead of train V-i. The next step215is to convert the clear aspect of VSig-k into a movement authority limit MAL-i based on the control line for signal VSig-k. In the following step217, the MCP150sends the movement authority limit MAL-i to the VSAP152in order to override the wayside signals within MAL-i, and to verify that the associated automatic stops are in the clear position. Upon receiving MAL-i, the VSAP152overrides219the appropriate wayside signals and sends the statuses of the associated automatic stops to the MCP150. In the next step221, the MCP150validates that blocks included in MAL-i are vacant. Upon confirmation that the blocks included in MAL-i are vacant, the MCP150sends MAL-i to V-i222. In turn, V-i sends224MAL-i to associated physical train P-i.

Similar to the first alternate embodiment, the MCP150of the second alternate embodiment implements the added safety function of ensuring that no train is present within a fixed detection block included in a movement authority limit MAL-i175. Although the VSAP employs vital logic, which ensures that a signal displays a clear aspect only if the associated control line is clear, under very rare conditions, one of the train detection blocks can fail to detect a train, resulting in a false clear. This could be due to a loss of shunt, equipment failure, human failure or the like.

The virtual train control system154performs two independent tasks to mitigate the safety risks associated with the failure to detect a train. First, the VSAP152continuously compares the statuses of the train detection blocks170received from the physical installation, with train locations received from the MCP150. Upon the detection of a discrepancy (i.e. for example train location received from the MCP150, falls within a train detection block with a “vacant” status), the VSAP152will activate the red aspect of all affected wayside signals, and will set all associated automatic stops to the tripping position. Further, the VSAP152will provide data to the MCP150indicating such discrepancy. In turn, the MCP150will cancel all movement authority limits impacted by the failure. Second, the MCP150will perform a safety check during the process to convert a clear signal aspect to movement authority limit. This safety check includes the detection of any communicating train located within the limits of a generated movement authority. Upon such detection, the MCP150will cancel all impacted movement authority limits, and will provide data to the VSAP152to activate the red aspects at all affected wayside signals.

FIG.21shows a block diagram of the AWS installation based on fixed block, wayside technology. The block diagram demonstrates how the AWS installation is partitioned into a physical train control installation250and a virtual train control system (Wayside)230. The physical train control installation250includes the fixed train detection blocks251, wayside signal equipment253, a train control interface247, a data communication network241, a signal interface module248, and onboard train control computers (for trains P-1, P-2 & P-5)168. The virtual train control system230includes the hardware computing resources239for the various train control application platforms, including the MAL Conversion Processor (MCP application platform)150, the virtual signal application processor (VSAP application platform)152, and the application platform that emulates the onboard train control computers156. Since the number of trains operating in the territory can vary, the virtual train control system provides a plurality (m) of computing modules156that emulate the onboard train control computers. Therefore, the maximum number of equipped trains that can operate in this section of the railroad is limited to m.

The virtual train control system230also includes a plurality of logical elements or modules233that act as incubators to initialize a new equipped train detected in the physical installation into the virtual train control system. This initialization process is not applicable to equipped trains moving from adjacent sections of the railroad into this section. Those trains are tracked by the system, and move from one section into an adjacent section (in both physical and virtual environments) using a transition process. Rather, the incubator process is intended to initialize a physical equipped train when it is first detected in the train control installation. As a new physical equipped train (P-i) is detected in the section, it is necessary to establish a corresponding virtual train (V-i) in the virtual train control system. For the second alternate embodiment, which implements wayside signaling technology, the detection is through radio communication. The initial frequency or radio channel assigned to the train is designed and/or configured to establish communication with one of the plurality of incubators233. Upon establishing such communication, the incubator requests the MCP150to assign a virtual train to physical train P-i, and initialize the virtual train into the virtual system230. The initialization process is coordinated with the MCP task to determine the fixed detection block VTC-k where V-i (P-i) is located209(FIG.20). Upon receiving a request from the incubator, the MCP150assigns an available logical module (virtual train) V-i to P-i. Then upon establishing communication between P-i & V-i, the MCP150identifies the closest signal VSig-k ahead of train V-i. The MCP150then determines a movement authority limit for V-i based on the control line for signal VSig-k (or the control line for the signal ahead of VSig-k if it is displaying a “green” aspect). The MCP150then transmits the movement authority limit to the VSAP152to override signals located within the movement authority limit and verify that the associated stops are in the clear position. Upon receiving a confirmation from the VSAP152that the stops for overridden signals are in the clear position, the MCP150transmits the movement authority limit to virtual train V-i, which in turn will relay the movement authority to P-i. After the completion of this initialization process for train V-i (P-i), the MCP150releases the incubator233so that the process is repeated when a new train is detected in the railroad section. The above described initialization process is shown inFIG.22.

The virtual train control system (Wayside)230also includes machine interfaces237&252that represent the demarcation points for communications with the physical train control installation250through a secure network connection231. In that respect,FIG.23shows the main communication channels between the physical installation and the virtual train control systems for an auxiliary wayside signal implementation as per the second alternate embodiment. In general, two way communications260is required between physical trains168and virtual (logical) trains156, between new detected trains and incubators262, between physical and virtual (logical) signal locations264, and between the ATS of the physical installation and the user interface at the virtual train control system265.FIG.24shows the various status information and control data exchanged between physical train P-i and corresponding virtual train V-i. Similarly,FIG.25shows the various status information and control data exchanged between a physical signal location Sig-i and the associated virtual signal location VSig-i. It should be noted that the specific status information and control data shown inFIG.24are set forth for the purpose of describing second alternate embodiment, and are not intended to limit the invention hereto. As would be understood by a person of ordinary skills in the art, additional or different status information and control data may be exchanged between a physical train and a corresponding virtual (logical) train depending on the requirements and design for the auxiliary wayside signal system.

The VSAP application platform152could be based on interlocking rules approach or could employ Boolean equations to implement control logic for the wayside signal locations. In addition, the VSAP application platform could be centralized or could be distributed of the architecture type described in U.S. Pat. No. 8,214,092. Further, the specific trackside signal equipment can vary from system to system and from location to location. For example, a fixed train detection block could be implemented using track circuits or axle counters. Also, an automatic train stop could be of the mechanical type or the magnetic type. As such, the specific status information and control data exchanged between each physical signal location and the corresponding virtual signal location (FIG.25) will vary from installation to installation All such variations described above are within the scope of this invention. With respect to the interfaces153between the VSAP152and the MCP150, the VSAP provides the MCP with the status of signal equipment, including positions of automatic train stops, signal aspects, statuses of fixed train detection blocks, and results of process that compares statuses of fixed train detection blocks with train locations. Similarly, the MCP provides the VSAP with train locations, movement authority limits, and the results of the process to check if a train is located within a block included in a movement authority limit. In addition, as shown inFIG.23, the MCP receives data related to temporary speed restrictions and work zones from a user interface that communicates with an ATS subsystem265.

With respect to the main operation of the auxiliary wayside signal installation described inFIGS.17,18&21, there are three different types of operation provided by this installation. The first type of operation occurs in the absence of equipped trains. Under such operating scenario, the unequipped trains operate manually under the protection of the wayside signals. Train detection is provided by the fixed train detection blocks, and train separation is based on the control lines of the wayside signals. The second type of operation occurs when equipped trains operate on the line. Each physical train P-i168determines its own location using an independent location determination subsystem, and then transmits its location to the corresponding virtual train V-i156in the virtual train control system. In turn, each virtual train V-i156communicates its location to the MCP150. Using a data base that stores data related to the fixed train detection blocks, the MCP150identifies the closest virtual signal ahead of the virtual train, and converts its clear aspect into corresponding movement authority limit based on its control line. The MCP150then communicates the movement authority limit to the VSAP152to override wayside signals located within the movement authority limit. In turn, the VSAP152confirms to the MCP150that these signals have been overridden, and that their automatic stops are in the clear position. The MCP150then verifies that the fixed train detection blocks included in the movement authority limit are vacant, and communicates the calculated movement authority limits to the virtual train156. Each virtual train156then sends the received movement authority limit to the corresponding physical train168. Upon receiving a movement authority limit, a physical train P-i generates a stopping profile from its current location to the end of the received movement authority limit, using track topography data stored in its vital on-board data base, and taking into account any civil speed limits reflected in the data base. The onboard computer then ensures that the physical train does not exceed the speed and the movement authority limit defined by the stopping profile. As the physical trains move on the track, they update their locations to the corresponding virtual trains, which report their updated information to the MCP150. In turn the MCP updates the movement authority limits for the various trains operating on the system as they approach the next wayside signals, and the cycle repeats. The third type of operation occurs when a mixed fleet of equipped and unequipped trains operate on the line. Under such condition, unequipped trains operate under the protection of the wayside signal installation, while equipped trains operate under the protection of the on-board equipment based on movement authority limits generated by the MCP in the virtual train control system. When an equipped train follows an unequipped train, its movement authority ends at the boundary of the block where the unequipped train is located (i.e. no overlap block is maintained). Conversely, when an unequipped train follows an equipped train, the train is stopped at the closest red signal (closest to the unequipped train) behind the equipped train such that at least one overlap block is maintained as a buffer between the two trains.

Similar to the preferred embodiment, and the first alternate embodiment, the logical modules (virtual trains) could be used to implement additional train control functions that can be exercised for a particular train or a group of trains if service conditions require it. The logical modules can also implement temporary train control functions that could limit the functions available onboard specific trains.

With respect to failure modes management for the second alternate embodiment, the proposed architecture has the advantage of providing an almost fault free cloud computing environment for the application platforms required for an auxiliary wayside signal system, including the application to convert manual operation into a distance-to-go operation. As such, a total failure of a MAL Conversion Processor or a virtual signal application processor is very unlikely. Potential failures of the installation include a loss of communication between a physical train and a virtual train, a loss of communication between physical wayside signal and corresponding virtual signal, or a total loss of communication within a section of the railroad.

If a physical train loses communication with its corresponding virtual train, the physical train can be operated in manual mode using wayside signal aspects. In such a case, the affected train will lose the ability to close in on a train ahead, but the train will continue to operate with signal protection. The corresponding virtual train will lose its movement authority limit, and its location will not be updated via information received from the corresponding physical train. However, the MCP can still track the physical train movement based on occupancy information provided by the VSAP. It should be noted that when a virtual train loses communication with a physical train, it remains assigned to the physical train until communication is re-established, or the virtual train is released for reassignment by the system administrator (case when the physical train is taken out of service or leaves the section of the railroad).

If communication is lost between a physical signal location and its associated virtual signal location, the physical signal will display a red (“stop”) aspect, and its corresponding stop will be in the tripping position. All trains (equipped and unequipped) will operate in a manual mode in the approach to the failed signal, and will be able to “key-by” the signal pursuant to operating rules and procedures. The “key-by” function is well known in the art, and is programmed locally in the processor210at each physical location (FIG.19). Within the virtual train control system, the failed signal location will display a red aspect, and a virtual train can move past the failed signal location only if the corresponding physical train is able to key-by the physical signal. Further, since the loss of communication between a physical signal location and the corresponding virtual signal location results in an unknown status for the train detection block associated with the failed signal location, the VSAP assumes that said train detection block is occupied, and all affected signals will display a “red” aspect.

In the unlikely event of a total loss of communications between the physical train control installation and the virtual train control system, all affected physical trains will operate in manual mode. Also, all affected wayside signal locations will display a “stop” aspect. In the virtual system, all affected virtual trains will lose their movement authority limits, and all affected virtual signal locations will display a stop aspect. All physical trains will operate passed wayside signals using the “key-by” function. Upon reestablishing communications, the system and all virtual trains operating in the section need to be initialized before the AWS system can resume normal operation.

As would be understood by those skilled in the art, different alternate embodiments can be provided to implement an auxiliary signal system based on wayside signaling technology. For example, the MCP and the VSAP could be combined into a single application platform. Also, alternate cloud computing architecture could be used to implement the virtual train control system. Further, a different communications configuration could be used to exchange status information and control data between the elements of the physical installation and the corresponding elements of the virtual train control system. It is also to be understood that the foregoing detailed description of the second alternate embodiment has been given for clearness of understanding only, and is intended to be exemplary of the invention while not limiting the invention to the exact embodiments shown.

It should be noted that the disclosed new process (apparatus and method) to convert manual operation based on fixed block wayside signaling into a distance-to-go operation can be implemented without the use of cloud computing environment and virtualization. As shown inFIG.26, a MAL Conversion Processor (MCP)300and a Signal Application Processor (SAP)302are used in a physical installation to convert the clear aspects at wayside signal locations304into movement authority limits306. In the shown architecture, the SAP302receives the statuses of the wayside signal equipment from a signal interface device308, which in turn communicates with wayside signal locations253via a wireless data communication network241. The SAP302processes the statuses information, and generates control data for the wayside signal equipment. The control data is transmitted to the wayside signal locations253via the wireless data communication network241.

Similarly, the MCP300communicates with the various trains168through the train control interface310and the wireless data communication network241. As described above in details, the MCP receives train location information and employs a database that includes information related to train detection block boundaries and the location of wayside equipment. The MCP then determines the train detection block where a train is located and the closest signal location ahead of the train. Using signal status information received from the SAP302, the MCP300converts a clear signal aspect into a corresponding movement authority limit. As described above, the MCP300sends the calculated MAL to the SAP302to override signals within the limits of the movement authority, and confirm that the associated automatic stops are in the clear position. The MCP300then verifies that train detection blocks included in the MAL are clear before sending the MAL to the train168. As described above, the controller onboard the train uses the MAL to generate a stopping profile that governs the movement of the train from its current location to the end of its movement authority limit.

As disclosed above in the preferred embodiment, the first alternate embodiment and the second alternate embodiment, the cloud computing environment and the virtualization process could be used to control signal and train control installations based on various technologies, including communications based train control, cab-signaling and fixed block, wayside signal technology. Further, the above disclosure describes the techniques that can be used to convert cab-signaling operation and manual operation based on fixed block, wayside signaling into distance-to-go type operation that is compatible with CBTC operation. The use of these techniques in combination with cloud computing environment and virtualization enables a railroad or a transit property to achieve interoperability between sections of the railroad that employ different signaling and train control technologies.

It should be noted that the processes disclosed in the various embodiments can utilize alternate vital programs to implement the described train control functions. Obviously these programs will vary from one another in some degree. However, it is well within the skill of the signal engineer to provide particular programs for implementing vital algorithms to achieve the functions described herein. It is also to be understood that the foregoing detailed description has been given for clearness of understanding only, and is intended to be exemplary of the invention while not limiting the invention to the exact embodiments shown. Obviously certain subsets, modifications, simplifications, variations and improvements will occur to those skilled in the art upon reading the foregoing. It is, therefore, to be understood that all such modifications, simplifications, variations and improvements have been deleted herein for the sake of conciseness and readability, but are properly within the scope and spirit of the following claims.