Patent Application
20150307119
1. Field of the Invention
This invention relates generally to train control systems, and more specifically to an auxiliary train control system that can be integrated with a primary train control system to provide a backup mode of operation during primary system failures. The auxiliary train control system is based on a generic architecture that employs a configuration of conventional train control equipment.
During the Twentieth Century, train control systems evolved from the early fixed block, wayside technologies, to various fixed block, cab-signaling technologies, and in recent years to communications based train control (CBTC), A.K.A. moving block technologies. In a CBTC system, a train receives a movement authority from a wayside device, and generates a stopping profile that governs its movement from its current position to the limit of the movement authority. Although CBTC can operate independent of fixed block train detection, it does require external means for detecting trains during CBTC system initialization, train initialization, as well as during CBTC system failures if a backup mode of operation (degraded mode of operation) is desired.
The current industry practice is to use an auxiliary wayside signal (AWS) system based on a secondary train detection system (track circuits or axle counters configured to detect trains within a fixed block). The functions of the AWS system could range from secondary train detection to providing safe train separation and in some cases limited over-speed protection. When integrated with CBTC, AWS is used during CBTC system initialization to detect unequipped and non-communicating trains. AWS is also used during the initialization of a train in CBTC operation to sweep the territory in front of the train before the train is issued a movement authority limit.
However, the current architecture for an AWS system has a number of disadvantages. First, the use of fixed block detection in conjunction with CBTC has the disadvantage of interrupting CBTC operation during a fixed block detection failure. Normally, a restricted movement authority (a movement authority with restricted speed) is used to operate a train through a failed train detection block. Second, if wayside signals with automatic train stops are used to provide safe train separation function during CBTC system failures, it is the custom and practice to override wayside signal aspects and associated automatic stops during normal CBTC operation. This practice increases the cost of CBTC installations, and introduces additional interruptions in CBTC operation during failures associated with wayside signals and associated automatic train stops. Also, while CBTC operation is normally automated, operation under AWS protection is normally manual. This results in operational constraints during certain failure modes (for example) of driverless systems.
Alternatively, if CBTC is installed without an auxiliary wayside system, it is very difficult to maintain train service during CBTC failures. It is also very challenging to initialize CBTC without AWS. Normally, the initialization is performed manually under operating rules and procedures. Accordingly, there is a need for a new architecture for an auxiliary wayside system that can be integrated with CBTC, and which provides compatible distance-to-go operation without the additional high capital & maintenance costs, and the operational disadvantages of the current industry practice.
2. Description of Prior Art
In a fixed block wayside signal system, the tracks are divided into a plurality of blocks, wherein each block includes a train detection device such as a track circuit or axle counters to detect the presence of a train within the block. Vital logic modules employ train detection information to activate various aspects at a plurality of wayside signals in order to provide safe train separation between trains. An automatic train stop is normally provided at each wayside signal location to enforce a stop aspect.
Cab-signaling technology is well known, and has evolved from fixed block, wayside signaling. Typically, a cab-signal system includes wayside elements that generate discrete speed commands based on a number of factors that include train detection data, civil speed limits, train characteristics, and track geometry data. The speed commands are injected into the running rails of the various cab-signaling blocks, and are received by trains operating on these blocks via pickup coils. A cab-signal system also includes car-borne devices that present the speed information to train operators, and which ensure that the actual speed of a train does not exceed the safe speed limit received from the wayside.
CBTC technology is also known in the art, and has been gaining popularity as the technology of choice for new transit properties. A CBTC system is based on continuous two-way communications between intelligent trains and Zone controllers on the wayside. An intelligent train determines its own location, and generates and enforces a safe speed profile. There are a number of structures known in the art for a train to determine its own location independent of track circuits. One such structure uses a plurality of passive transponders that are located on the track between the rails to provide reference locations to approaching trains. Using a speed measurement system, such as a tachometer, the vital onboard computer continuously calculates the location and speed of the train between transponders.
The operation of CBTC is based on the moving block principle, which requires trains in an area to continuously report their locations to a Zone Controller. In turn, the Zone Controller transmits to all trains in the area a data map that contains the topography of the tracks (i.e., grades, curves, super-elevation, etc.), the civil speed limits, and the locations of wayside signal equipment. The Zone controller, also, tracks all trains in its area, calculates and transmits to each train a movement authority limit. A movement authority is normally limited by a train ahead, a wayside signal displaying a stop indication, a failed track circuit, an end of track, or the like. Upon receiving a movement authority limit, the onboard computer generates a speed profile (speed vs. distance curve) that takes into account the limit of the movement authority, the civil speed limits, the topography of the track, and the braking characteristics of the train. The onboard computer, also, ensures that the actual speed of the train does not exceed the safe speed limit.
The current invention provides a new architecture for an auxiliary wayside signal system that can be integrated with CBTC. The new architecture is based on a generic installation that does not employ train detection blocks, requires minimum application design efforts, provides operation compatible with CBTC, enables the initialization of CBTC equipment, provides a backup mode of operation during CBTC failures, and is transparent to CBTC operation (i.e. its operation is autonomous and its failure modes have no impact on CBTC operation).
This invention relates to train control systems, and in particular to an auxiliary wayside signal (AWS) system that can be integrated with CBTC to provide a backup mode of operation during CBTC system failures. The new AWS system employs a generic signal structure (or generic signal assembly), defined as an Absolute Block Signal Unit (“ABSU”), which has an architecture that is based on conventional signal equipment. Accordingly, it is an object of the current invention to provide a method for an auxiliary wayside signal system that is founded on a plurality of a generic signal structure located along the track (or right of way), and which are linked by a data communication network.
It is another object of this invention to provide an auxiliary wayside signal system that is based on a generic signal structure that is located at a plurality of locations along the track, wherein said signal structure includes a data radio to communicate with CBTC equipped trains.
It is a further object of this invention to provide an auxiliary wayside signal system that is based on a generic signal structure that is located at a plurality of locations along the track, wherein said signal structure includes a communication module, which operates over a fiber optic network, to exchange data with similar structures.
It is also an object of this invention to provide an auxiliary wayside signal system that is based on a generic signal structure that is located at a plurality of locations along the track, wherein said signal structure includes means for detecting certain attributes associated with passing trains.
It is a further object of the current invention to provide an auxiliary train control system, which is based on a generic signal structure that is located at a plurality of locations along the track, wherein the auxiliary train control system employs a unique “signature” for each train that includes the number of axles on the train and a unique train identification, and wherein said generic signal structure is designed to detect said unique signature.
It is also an object of this invention to provide a train control system, which is based on a generic signal structure that is located at a plurality of locations along the track, wherein the train control system employs a unique “signature” for each train provided by a plurality of tags (transponders) mounted on the train that provide in turn a unique train identification, and wherein said generic signal structure is designed to detect said unique signature.
It is another object of this invention to provide an auxiliary wayside signal system, which is based on a generic signal structure that is located at a plurality of locations along the track, wherein the auxiliary train control system employs a unique “signature” for each train that includes the number of axles on the train and a unique train identification, wherein the unique train identification is based on a plurality of transponders, wherein the configuration of axle counters and transponders is provided to achieve detection and correction of certain failures/errors, and wherein said generic signal structure is designed to detect said unique signature.
It is a further object of this invention to provide an auxiliary wayside signal system that is based on a generic signal structure that is located at a plurality of locations along the track, wherein said structure is designed to detect the crossing of a train past its location, and wherein the function of detecting the crossing of a train is performed in to presence of certain failure conditions.
It is still an object of this invention to provide an auxiliary wayside signal system that is based on a generic signal structure that is located at a plurality of locations along the track, wherein said generic structure can generate a movement authority limit (MAL) and transmit it to an approaching train, and wherein the MAL is based on the absolute permissive block signaling concept.
It is a further object of this invention to provide an auxiliary wayside signal system that tracks the number of axles of a train as it moves throughout the AWS territory.
It is another object of this invention to provide an auxiliary wayside signal system that is based on a generic signal structure that is located at a plurality of locations along the track, wherein said generic structure can provide a signal indication to an approaching train.
It is also an object of this invention to provide an auxiliary wayside signal system that is based on a generic signal structure that is located at a plurality of locations along the track, wherein said generic structure can provide automatic train stop enforcement for an approaching train.
It is yet another an object of this invention to provide an auxiliary wayside signal system that is based on a generic signal structure that is located at a plurality of locations along the track, wherein said generic structure is implemented by a generic absolute block signal unit, wherein the signal unit includes an axle counter, a data radio, an active transponder, a transponder reader, a signal and associated automatic train stop.
It is still an object of this invention to provide an auxiliary wayside signal system that can be integrated with a CBTC system, and which can operate in a standby mode of operation and in an active mode of operation, wherein during standby mode the AWS is transparent to CBTC operation, and wherein during active mode the AWS provides certain functions in support of CBTC operation.
It is a further object of the invention to provide an auxiliary wayside signal system that can be integrated with a CBTC system, wherein during normal CBTC operation the AWS system operates in a standby mode.
It is also an object of this invention to provide an auxiliary wayside signal system that can be integrated with a CBTC system, wherein upon the detection of a CBTC failure, the AWS system operates in an active mode.
It is another object of this invention to provide an auxiliary wayside signal system that can be integrated with a CBTC system, and which is based on a generic signal structure that is located at a plurality of locations along the track, wherein upon the failure of a signal structure at one of said plurality of locations, the AWS system is automatically reconfigured without the failed signal structure, and with or without functional assistance of the CBTC system.
It is still an object of this invention to provide an auxiliary wayside signal system that is based on a generic signal structure that is located at a plurality of locations along the track, wherein a generic signal structure includes a radio module to communicate with other generic signal structures, with approaching trains, and with CBTC zone controllers.
It is a further object of this invention to provide an auxiliary wayside signal system that is based on a generic signal structure that is located at a plurality of locations along the track, wherein a generic signal structure includes an axle counter (or a wheel detector) to count the number of axles of a passing train.
It is still also an object of this invention to provide an auxiliary wayside signal system that is based on a generic signal structure that is located at a plurality of locations along the track, wherein a generic signal structure includes an active transponder that transmits control data to an approaching train.
It is also an object of this invention to provide an auxiliary wayside signal system that is based on a generic signal structure that is located at a plurality of locations along the track, and which provides a degraded mode of operation for a CBTC installation, wherein the auxiliary wayside signal system operates autonomously of CBTC and has no impact on CBTC operation.
It is another object of this invention to provide an auxiliary wayside signal system that is based on a generic signal structure that is located at a plurality of locations along the track, wherein a generic signal structure includes a transponder reader that detects the train identification of a passing train.
It is yet another object of this invention to provide an auxiliary wayside signal system that is based on a generic signal structure that is located at a plurality of locations along the track, wherein a generic signal structure includes a visual display that provides a signal aspect indication to an approaching train, wherein said signal aspect indication is based on color light and/or position light.
It is also an object of this invention to provide an auxiliary wayside signal system that is based on a generic signal structure that is located at a plurality of locations along the track, wherein a generic signal structure includes an automatic train stop mechanism that enforces a “stop” aspect, and wherein said train stop mechanism is of the mechanical type, magnetic type, or is based on a transponder type operation.
It is a further object of this invention to provide an auxiliary wayside signal system that operates based on monitoring and/or processing a stack of trains within a section of the railroad.
It is still another object of this invention to provide an auxiliary wayside signal system that communicates with an interlocking control device to receive information related to the statuses of interlocking equipment.
It is yet another object of this invention to provide an auxiliary wayside signal system that is installed in a rail section that includes an interlocking installation, and which is based on a generic signal structure that is located at a plurality of locations along the track, wherein the interlocking installation performs certain functions of the generic signal structure.
It is also an object of this invention to provide an auxiliary wayside signal system that is integrated with a CBTC system, which is based on a generic signal structure that is located at a plurality of locations along the track, and which interfaces with an Automatic Train Supervision (ATS) subsystem.
It is another object of this invention to provide an auxiliary wayside signal system that is integrated with a CBTC system, which is based on a generic signal structure that is located at a plurality of locations along the track, and which is coordinated with traffic direction on said rack.
It is a further object of this invention to provide a primary train control system, which is based on a generic signal structure that is located at a plurality of locations along the track, and which operates using the absolute permissive block signaling concept.
It is yet another object of this invention to provide an auxiliary train control system, which is based on a generic signal structure that is located at a plurality of locations along the track, and which employs the absolute permissive block signaling concept to control the movement of a manual train through the territory.
It is still an object of the current invention to provide an auxiliary train control system, which is based on a generic signal structure that is located at a plurality of locations along the track, wherein said generic signal structure is designed to fail in alternate failure states depending on certain attributes of the train approaching the location of the generic signal structure.
It is also an object of the current invention to provide an auxiliary train control system, which is based on a generic signal structure that is located at a plurality of locations along the track, wherein said generic signal structure is designed to fail in a “stop” failure state if the approaching train is a manual train operating without speed restriction, and wherein in this failure state, the signal structure displays a “stop” aspect and controls its automatic train stop to the tripping position.
It is a further object of the current invention to provide an auxiliary train control system, which is based on a generic signal structure that is located at a plurality of locations along the track, wherein said generic signal structure is designed to fail in an “override” failure state if the approaching train is an equipped train, and wherein in this failure state, the signal structure displays an “override” aspect and controls its automatic train stop to the clear position.
It is another object of the current invention to provide an auxiliary train control system, which is based on a configuration of a plurality of generic signal structures that are located at a plurality of locations along the track, wherein the design of said auxiliary train control system includes a self-healing feature that would reconfigure said plurality of generic signal structures during a failure.
It is also an object of the current invention to provide an auxiliary train control system, which is based on a configuration of a plurality of generic signal structures that are located at a plurality of locations along the track, wherein the design of said auxiliary train control system includes an overlap section at each ABSU location, wherein the overlap section is implemented using a second set of wheel detector (axle counter)/transponder reader configuration to detect the crossing of a train at a “release” point past the ABSU location, and wherein the distance between the ABSU location and the release point location represent an overlap distance to protect against a manual train violating a stop aspect at the ABSU location.
The foregoing and other objects of the invention are achieved in accordance with a preferred embodiment of the invention that provides an auxiliary wayside signal (AWS) system that is based on a generic Absolute Block Signal Unit (ABSU) that is installed at a plurality of locations along the track. The spacing between consecutive ABSUs is a design choice, and is based on the desired headway (or throughput) needed from the AWS installation. The AWS can be integrated with a CBTC system to provide a number of CBTC related functions including initialization of zone controllers, initialization of CBTC equipped trains into CBTC operation, as well as a backup mode of operation during CBTC failures. The ABSU provides operation that is compatible with CBTC operation (i.e. distance-to-go operation).
The ABSU operates based on the absolute permissive block concept, wherein a train is given a movement authority to proceed through a block from the entering boundary of the block to its exit boundary provided that the entire block is vacant. Conventional signaling installations use a plurality of track circuits or other means of train detection within an absolute block to determine the status of the absolute block, i.e. vacant or occupied. During CBTC operation, trains operate close together and it is likely that a plurality of trains operate within an area defined as an absolute permissive block. While CBTC tracks the number of trains and the location of each train operating within an area, this tracking function is lost during a CBTC failure. Conventional technologies that employ fixed block train detection are not able to determine the exact number of trains within an area impacted by a CBTC failure. The proposed AWS system has the capability to determine the number of trains operating within an area or section of the railroad.
The proposed AWS system employs a unique “signature” for each train. A signature is defined as one or a plurality of attributes that are associated with a train. Although a single attribute is sufficient to operate the proposed AWS system, it is desirable to use two attributes to define a signature for an equipped train. Accordingly, the preferred embodiment uses the number of axles in a train, and a unique train ID embedded in a tag or transponder to define the signature of an equipped train. A tag or a transponder could be a passive transponder that stores a fixed train ID, or could be an active transponder that stores a variable train ID (i.e. the train ID is different for each train trip). Another design alternative is for the train ID to include two parts: a fixed part and a variable part that is based on the train trip. What is important is that the train ID remains fixed during a trip from an originating terminal to a destination terminal.
For the preferred embodiment, wherein the AWS system is integrated with CBTC, and in order to facilitate CBTC system initialization, the CBTC system stores a train signature as part of the train consist information. The on-board CBTC equipment also includes a structure that determines the number of axles in the train consist, and provisions for storing the train signature (the number of axles and the train ID). Further each CBTC train is able to communicate and verify its signature to zone controllers. Also, each zone controller tracks the signatures of the CBTC trains within its territory.
It should be noted that for an application wherein the ABSUs are used to provide a primary train control system and wherein trains could include freight trains, there is a need to provide an alternate way other than the number of axles in a train to identify trains and track them as they move past each ABSU. An alternate structure is based on using plurality of transponders installed on the train consist to form a unique pattern that can be used as a train signature. Each transponder holds part of a train signature code, and collectively the plurality of transponders provide the unique train signature.
It should also be noted that another design choice for train signature is to use a configuration of number of axles and two tags (transponders), such that one transponder is located on the first car of the train consist, and the second transponder is located on the last car of the train consist. The purpose of the second transponder is to provide a confirmation that the entire train has passed an ABSU location. Although detecting the number of axles in a train provides such assurance, the second transponder can provide a self-correcting mechanism in the event of an error in detecting an axle of the train crossing an ABSU location. Similarly, detecting the full complement of axles included in a train signature can provide assurance that the entire train has crossed an ABSU location even though the ABSU reader may have missed or misread one of the two transponders. In effect the configuration of number of axles and the two transponders provides redundant/fault tolerant means for detecting the crossing of a train by an ABSU location. Conversely, in the event the full number of axles and at least one transponder are not detected, this will indicate a potential problem with train integrity, i.e. a train losing one or more cars from its consist.
The ABSU has two modes of operation: a “standby” mode and an “active” mode. During the standby mode, the ABSU monitors the number of trains within an absolute block section. Then during the active mode, the ABSU controls the movement of an approaching train into the absolute block section. Under normal CBTC operating conditions, the ABSUs operate in the standby mode. Alternatively, when CBTC experiences a zone controller or a train failure, the ABSUs operate in the active mode. One main characteristic of an ABSU is that it operates autonomously of the CBTC system. During the “standby” mode, the ABSU is simply monitoring CBTC train movements and is tracking the relative positions of CBTC trains. Further, during the “active” mode, the ABSU employs the information compiled during the “standby” mode to control train movements. In both the standby and active modes, the ABSU operates independently of the CBTC system.
In general, the ABSU performs three main functions. The first function is performed during both the “standby” and “active” modes to detect that a train has completely crossed over the point where the ABSU is located. As part of this function, the ABSU confirms that a specific train identified by a train signature has crossed its location. In the event that a train without a train signature crosses the ABSU location, it is detected and is assigned a provisional train signature by the ABSU. However, if the ABSU is operating in the active mode, and if it cannot confirm that the train is an equipped train, it considers such train to be a manual train operating without speed restriction, and triggers an ABSU overlap function to provide sufficient breaking distance to the manual train.
The second function is also performed when the ABSU is operating either in the “standby” or active” mode. Upon detecting a crossing of a train at its location, the ABSU updates the number of trains within its absolute permissive block, and tracks the associated train signatures within that block section. The third function is performed only when the ABSU is operating in the active mode. Under this function, the ABSU controls the movement of an approaching train into the associated absolute permissive block section. More specifically, when in the active mode, and if the approaching train is an equipped train, the ABSU permits the approaching train to enter the absolute permissive block section if it is vacant. Alternatively, if the approaching train is unequipped and operating in a manual mode, the ABSU permits the approaching train to enter its absolute permissive block section only if the two permissive blocks ahead of its location are vacant.
To accomplish these functions, an ABSU communicates with adjacent ABSUs as follows: First, it receives the signature of an approaching train from the ABSU in the approach to its location (“Approach ABSU”). Second, it transmits to the “Approach ABSU” that a specific train (defined by its signature) has completely crossed the ABSU location. Third, it transmits to the ABSU ahead of its location (“Ahead ABSU”) the signature of the train approaching the Ahead ABSU. Fourth, it receives from the Ahead ABSU that a specific train (defined by its signature) has completely crossed the location of the Ahead ABSU.
Additional functions performed by an ABSU include sending a movement authority limit to an approaching train (when operating in the active mode). Further, for certain applications, when a failed train is approaching an ABSU location, the ABSU transmits to the train a civil speed limit that must not be exceeded when the train operates within the absolute permissive block limits. In addition, an ABSU communicates with associated zone controller to exchange operating data, as well as with the ATS subsystem to provide status information.
When an ABSU is located in the approach to an interlocking, it is necessary to provide additional operating data to the ABSU. First, the interlocking needs to confirm to the ABSU that a route has been established for the approaching train. Second, the interlocking must provide the destination track to the ABSU in order to establish communication with the correct ABSU ahead. To accomplish these requirements, it is necessary that the interlocking maintains communication with the ABSU at all times. In the event of a loss of communication between the ABSU and the interlocking, the ABSU is not able to issue a movement authority to an approaching train. Further, if a train has already received a movement authority limit prior to the loss of communication between the ABSU and the interlocking, it is very difficult to rescind or cancel such movement authority, especially if there is no radio communication established with the train.
In view of the objective to simplify the architecture of the proposed AWS system, and because of the design and operating challenges associated with issuing a train a movement authority limit that overlaps an interlocking, the preferred embodiment is designed such that the ABSU functions are integrated with the interlocking functions. This should not be difficult, since it is customary to replace or modernize the interlocking controls as part of a new CBTC project.
In a conventional interlocking with wayside signals, the ABSU functions are made effective at the home signal located on the various tracks at the boundaries of the interlocking. In effect, each of these home signals incorporates ABSU functions in addition to performing the functions normally associated with a home signal. As such, each home signal location includes an axle counter, an active transponder and a transponder reader. However, since the ABSU control logic is implemented as part of the interlocking control logic, only one radio module is needed for the entire interlocking (a plurality of radios could be provided if needed for availability). In that respect, to the AWS, the interlocking appears as a single ABSU logical entity (“ABSU-IXL”), with one geographical address location for each entrance to, and exit from the interlocking. For an ABSU in the approach to the interlocking, the ABSU-IXL functions as the “ABSU Ahead.” Alternatively, for an ABSU ahead of the interlocking, the ABSU-IXL functions as the “Approach ABSU.” As such, the ABSU-IXL detects the crossing of a specific train twice. The first crossing is when the train exits the absolute permissive block in the approach to the interlocking and enters the interlocking territory at a home signal location. The second crossing is when the train exits the interlocking territory and enters the absolute permissive block ahead of the interlocking. The ABSU-IXL maintains a protected stack for each route, and keeps track of a specific train (as defined by the train signature) exiting the interlocking. Further, the ABSU-IXL generates and sends a MAL to an approaching train to enable the train to move along a protected route within the interlocking limits. The ABSU-IXL uses either the radio module or an active transponder to transmit a MAL to an approaching train. The functions performed by the ABSU are implemented in the interlocking control device. As such, any route from a home signal entering the interlocking through a home signal exiting the interlocking is considered an internal absolute block. The interlocking control device then performs additional logic functions for each route (i.e. internal absolute block), relying on the ABSU equipment installed at the entry and exit points of the interlocking (axle counters, transponder readers and active transponders), wherein the logic functions include detecting a train crossing an entry point of the interlocking, detecting a train crossing an exit point of the interlocking, determining the number of trains within an internal route, and tracking the signatures of all trains operating at the interlocking.
It should be noted that the integration of the ABSU functions with the interlocking functions has the benefits of simplifying the architecture of the ABSU and its functionality. A generic ABSU can be used at any location on a line, including locations in the approach to an interlocking. Also, the functions performed by the ABSU are independent of the internal interlocking routes. It should also be noted that this integration approach is being set forth for the purpose of describing the preferred embodiment, and is not intended to limit the invention hereto.
To perform the above described ABSU functions, the ABSU architecture for the preferred embodiment is based on a configuration of conventional train control equipment that include axle counter to detect the crossing of a train, a transponder reader to read the ID of a passing train, an active transponder to transmit data to an approaching train, a wayside signal module and associated automatic train stop to control the movement of an approaching train into an absolute permissive block, and a radio module to communicate with adjacent ABSUs, zone controllers, approaching trains, ATS subsystem (if required), and an interlocking control device (if required).
It should be noted that the above architecture is set forth herein for the purpose of describing the preferred embodiment and is not intended to limit the invention hereto. As would be understood by a person with ordinary skills in the art, the ABSU could be based on a different architecture and/or different set of train control equipment. For example, optical detectors could be used in lieu of axle counters. Also, a data communication module operating over a fiber optic communication network could be used in lieu of a radio module to communicate with adjacent ABSUs, zone controllers, ATS subsystem and interlocking control devices. Further, an ABSU can be located at a CBTC radio location, and can leverage the CBTC communication resources at that radio location to satisfy its data communication needs. This will reduce the cost of an ABSU implementation. In addition, the use of a wayside signal as part of the ABSU could be optional. An on-board indicator could be activated through the active transponder at the ABSU location.
As indicated above, when integrated with CBTC, the ABSU is used to initialize zone controllers and CBTC equipped trains into CBTC operation. During normal CBTC operation, the ABSUs included in the AWS system operate in a standby mode, and keep track of the number of trains and the sequence of train signatures within each absolute block. Upon a failure of a zone controller, the ABSUs in the AWS continue to track of the number of trains and their signatures within each absolute block. Further, the ABSUs control train movements to an eventual operational configuration of a single train per absolute block. Upon the re-initialization of the failed zone controller, the ABSUs within the AWS provide the current train operational data to the zone controller (i.e. data related to the number of trains and their signatures within each absolute block). For the preferred embodiment the number of trains and their signatures within each absolute block is defined as the “protected stack.”
The zone controller uses data included in the protected stack to verify that there is no undetected non-communicating train within its territory. During the initialization process, and upon establishing communication with CBTC trains, the Zone controller compares the signatures of communicating trains with the data provided by the ABSUs to determine if there are trains included in the protected stacks that have not established communication with the zone controller. The zone controller can also determine the positions of non-communicating trains relative to the trains that did establish communication. In the event of detecting a non-communicating train within a protected stack, the zone controller will not issue a movement authority limit to the train that is located behind the non-communicating train. However, when and where the protected stack data confirms that all trains within a stack have established communications with the zone controller, the initialization process becomes simple. Upon the localization of a communicating CBTC train, the zone controller can issue a movement authority limit to the train based on the location of the train ahead.
There are two main operating scenarios associated with the initialization of the proposed AWS system that employs a plurality of ABSUs. In the first scenario, it is assumed that the CBTC system is operating without a failure at the time when the AWS is initialized. Under this scenario, the CBTC operating data is used to initialize the various ABSUs. More specifically, train tracking data within zone controllers is used to initialize the protected stacks data, including the number of trains within a stack and associated train signatures. In addition, the data needed to customize the ABSUs to geographic locations could be uploaded from the zone controllers to the ABSUs.
During the second operating scenario, it is assumed that the CBTC system is not operational. Under this scenario, the initialization process is based on at least one train sweeping the territory of the absolute block in order to initialize the associated ABSU. Once an ABSU is initialized, it can operate in an active mode to control the movement of trains, or in a standby mode as described above.
One of the main objectives of the preferred embodiment is to minimize the application engineering effort to customize an ABSU to a particular geographic location. In that respect, the proposed ABSU architecture is based on a generic operational approach that detects train movements at discrete points rather than continuous monitoring of train movements throughout an entire section of the railroad. As such, the proposed architecture requires a very limited set of geographical data to customize an ABSU to a particular geographic location. More specifically, each ABSU requires the geographical locations data for the two ABSUs ahead of its own location, as well as the ABSU in the approach to it. The ABSU also requires the lowest civil speed limit data within the boundaries of the absolute block it protects. All other data needed for ABSU functionalities is dynamically acquired during the standby and active modes of operation. This simple customization process enables easy initialization of the AWS system, and allows for a simple procedure to reconfigure an AWS installation in the event of an ABSU failure. As a consequence of the above described ABSU characteristics, the proposed AWS is totally independent of, and transparent to CBTC operation.
In the event an ABSU fails while it is operating in a standby mode, and in accordance with the preferred embodiment, the CBTC system detects such failure, and removes the failed ABSU from the AWS configuration. In effect, the protected stack of the failed ABSU is combined with the protected stack of the “Approach ABSU.” The reconfiguration of the AWS results in a longer absolute permissive block that maps the territories of the two absolute permissive blocks in the approach to and ahead of the failed ABSU. It should be noted that this reconfiguration process is transparent to, and has no impact on CBTC operation. It should also be noted that one of the main benefits of the proposed AWS architecture is that during normal CBTC operation, the ABSUs have no impact on the reliability and availability of CBTC operation, even when a component of an ABSU or an entire ABSU location fails. This is accomplished without the use of any redundancies within the AWS system. Further, it should be noted that another design alternative is to perform the reconfiguration of the ABSUs without using data from the zone controller. This is possible by establishing communication between the ABSU ahead of, and the ABSU in the approach to the failed ABSU. However, under such design alternative, each ABSU communicates all data related to the trains in its protected stack to the ABSU Ahead.
Alternatively, if the ABSU fails while it is in the active mode, trains located within its protected stack will continue to operate under previously issued operating parameters (i.e. movement authority limit and/or speed restriction). However, trains approaching the failed ABSU will not receive updated operating parameters at the failed ABSU location. This means that if the first approaching train has a MAL, it will stop at the failed ABSU location. Alternatively, if the first approaching train is operating under a restricted speed, it can continue to move passed the failed ABSU location if the signal and associated automatic train stop at the failed ABSU location permit such restricted speed movement.
To manage this failure scenario, the design of the ABSU incorporates a failure management feature that is associated with active mode operation, and which enables trains to continue to move with minimum interruption to service in the event of an ABSU failure. The preferred embodiment provides a unique ABSU design feature that, while in the active mode, it pre-conditions the device to transition into one of two failure states in the event of a failure. The first failure state is identified as an “override” failure state, and is selected if the train approaching the ABSU is an equipped train. Under this failure state, the ABSU is designed to automatically display an “override” aspect and to drive the automatic stop to a clear position. Further, the active transponder defaults to transmitting a special failure code to an approaching train. The second failure state is identified as “stop” failure state, and is selected when the ABSU cannot determine if the approaching train is equipped. Under this failure state, the ABSU is designed to automatically display a “stop” aspect and to drive the automatic stop to a tripping position.
It should be noted that under normal AWS operating conditions, an equipped train approaching an ABSU is operating under the protection of either a MAL or a restricted speed. This is the case because when a CBTC element fails, affected trains, including a failed train, operate with restricted speed until the failure is corrected or an affected train is given a movement authority by an ABSU. Further, an equipped train normally has a train signature and is able to communicate with the ABSUs. As such, when the ABSU fails in the “override” failure state, it allows an approaching train with a speed restriction to continue to move past its location with the restricted speed. In the event the approaching train has a MAL that ends at the location of the failed ABSU, the default code generated at the active transponder of the failed ABSU authorizes the approaching train to move under a speed restriction.
Under rare operating conditions, a manual train may operate in the ABSUs territory without a speed restriction. The preferred embodiment includes a design feature that enables the manual train to move with limited signal protection by providing an overlap distance at each ABSU location. As such, when an ABSU is not able to determine that an approaching train is equipped, it preconditions its internal logic to fail in the “stop” fail state. This ensures that the approaching manual train stops at the failed ABSU location. There are two design choices for providing said overlap distance at each ABSU location. The first design choice is based on using the ABSU ahead as a “release” point for the manual train. A “release” point is defined as the location at which a train operating ahead of a manual train must be detected before allowing the approach ABSU to release the manual train to move past its location. The second design choice is to install a second configuration of axle counter/transponder reader ahead of the ABSU location to detect the crossing of the train ahead of the manual train. In this case, the location of the second configuration is the “release” point, and the distance between the ABSU location and the release point represents the needed overlap distance. It should be noted that the overlap distance is based on the breaking distance for the manual train under worst operating conditions (i.e. maximum attainable speed, low adhesion condition, etc.)
Upon the occurrence of an ABSU failure, it is assumed that communication is interrupted between the failed ABSU and the Approach ABSU, as well as with the ABSU Ahead. When communication is lost with an adjacent ABSU, the Approach ABSU is designed to establish communication with the next ABSU in an AWS configuration. This means that when an ABSU fails, the Approach ABSU and the ABSU Ahead establish communication together. Then upon establishing such communication, the Approach ABSU receives from the ABSU Ahead the train signature of the train approaching its location if any. Upon receiving said train signature, the Approach ABSU inserts a predefined number of “provisional” trains in its protected stack, and continues to provide the ABSU Ahead with train signatures from its protected stack, starting with the provisional trains until it receives confirmation that a train on the original protected stack has reached the ABSU Ahead. Accordingly, the main approach of this failure recovery technique is to provide a transition period during which affected trains maintain status quo and continue to operate, or are authorized to operate with a speed restriction. After the completion of this transition period, normal AWS operation resumes. In effect, the above described failure management process enables the AWS to “self-heal” from an ABSU failure by combining the absolute permissive blocks in the approach to, and ahead of the failed ABSU into a longer absolute permissive block, by introducing “provisional” trains as place holders for train data lost as a result of the ABSU failure, and by overriding the failed ABSU to enable trains to pass its location.
It should be noted that the above description of a failure recovery approach for the AWS system is being disclosed herein for the purpose of describing the preferred embodiment, and is not intended to limit the invention hereto. As would be understood by a person with ordinary skills in the art, a number of variations/modifications can be implemented in the proposed failure recovery process. For example, the signatures data associated with the trains within a protected stack can be transmitted to the ABSU Ahead in order to facilitate the processing of these trains during an ABSU failure. In effect, under this design choice, each ABSU includes a protective stack and an approach stack. Also, in lieu of displaying an overridden aspect upon a failure, the ABSU can display a “call-on” aspect that requires action by the approaching train in order to drive the automatic train stop to the clear position.
The disclosed AWS configuration, together with the architecture, design features and operation of the Absolute Block Signal Unit demonstrate the advantages of the proposed AWS system. The new structure and configuration for the AWS system when integrated with a CBTC installation provide a backup mode of operation without interfering with normal CBTC operation or degrading the availability of the CBTC system. Other advantages of the proposed AWS system include providing an operation compatible with CBTC (i.e. distance-to-go operation), a generic structure that can be easily customized to geographical locations without extensive application engineering requirements, and a self-healing configuration that enables train service to continue during certain AWS failures. Further, the proposed AWS system simplifies the initialization of CBTC installations and can leverage the CBTC infrastructure.
It should be noted that while the preferred embodiment employs a wayside signal module and an associated automatic train stop to provide certain signal functions, the ABSU can be designed without the wayside signal and associated automatic train stop. Under such alternate simplified design, the ABSU continues to track train movements through the CBTC territory, and generates and communicates a MAL to an approaching train only if its associated absolute block area is vacant. The MAL is limited to a single absolute permissive block, and a train must receive a new MAL to proceed past the end of the absolute block. If a train operating with a speed restriction does not stop at an ABSU location to receive a MAL, it can continue to operate with the speed restriction through the new absolute block, which movement has no impact on safety of operation. Obviously, a continuing movement with speed restriction will have an adverse impact on performance. Also, under such simplified ABSU design, the AWS is not capable of supporting the movement of a manual train throughout the CBTC territory. Similarly, it should also be noted that while the preferred embodiment employs a transponder reader at each ABSU location to capture the train ID of a passing train, the ABSU can be designed without the use of a transponder reader. Under such alternate design, train ID data is transmitted from a train to the ABSUs via radio communication. Further, if this alternate design is used, then it is not necessary to equip each train with a transponder that includes the train ID fields. The train ID data can be stored within the on-board computer and transmitted to the ABSUs as part of a radio communication.
These and other more detailed and specific objectives will be disclosed in the course of the following description taken in conjunction with the accompanying drawings wherein:
The present invention describes a new structure, and/or a new method to implement an Auxiliary Wayside Signal (AWS) system. This new structure is based on the concept of absolute permissive block, and uses an architecture that includes conventional train control equipment to provide the required AWS functions. The proposed AWS system can be integrated with a CBTC installation to provide backup modes of operation, as well as to facilitate the initialization of CBTC equipment (zone controllers and on-board controllers) into CBTC operation. In addition, one of the main characteristics of the proposed AWS system is to be transparent to CBTC operation, and to operate without any impact on CBTC functionalities and availability. Another characteristic of the AWS is to provide a self-healing feature that enables train service to continue in the event of certain AWS failures. The proposed AWS system can also be used as a primary signaling system for simple train control applications, and is designed to provide limited signal protection to manual trains operating without a speed restriction.
To implement the absolute permissive block concept, a new generic structure defined as an Absolute Block Signal Unit (ABSU) is proposed. The architecture of the ABSU employs a number of conventional train control devices that provide basic functions for the operation of the ABSU. These functions include the detection of a train crossing a specific location, communicating with other elements of the AWS system as well as elements of an associated CBTC installation, controlling the movement of a train into an associated absolute permissive block, communicating a movement authority limit (MAL) and/or a civil speed restriction to an approaching train, and detecting certain attributes associated with a train crossing its location.
The preferred embodiment is based on a specific ABSU design that includes a processor module, an axle counter, a transponder reader, an active transponder, a data radio communication module, a wayside signal and associated automatic train stop. Further, the preferred embodiment employs a train identification system that is based on a unique attributes for each train. More specifically, each train is identified by the number of axles in the train consist and an alphanumeric code that includes a fixed field and/or a variable field based on the train's current trip.
The disclosure of the various concepts used by the preferred embodiment is based on a number of operating hypothesis and assumptions. More specifically, it is assumed that under the primary CBTC operation, all trains operating in the CBTC territory are equipped CBTC trains, and that upon a failure of a zone controller, all affected trains will operate with a speed restriction. Also, if a CBTC equipped train fails, it is assumed that it will operate with a speed restriction. The restricted speed is a design choice, but typically train operates at a restricted speed of 10 to 20 mph during a CBTC failure. It is also assumed that under rare operating conditions, a manual train may operate through the CBTC territory without speed restriction and using an absolute block protection from interlocking to interlocking. The safety of operation of the manual train is dependent on compliance with operating rules and procedures, especially the compliance with civil speed limits within the territory. The preferred embodiment includes a design feature that provides a limited protection for a manual train.
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,
Communications between adjacent ABSUs could be through data radio communication, or via a backbone fiber optic network that also interconnect the ABSUs with elements of the CBTC installation, including zone controllers, an ATS subsystem, interlocking control devices, etc. For the preferred embodiment, communications between the ABSUs is via data radio communication. As indicated above, the ABSU can be located at a CBTC radio location in order to leverage the CBTC communication infrastructure (i.e. both radio and fiber optic data communication).
It should be noted that the transponder antenna 14 is physically located in the approach to the ABSU location to enable the processing of train information by the ABSU as the train is approaching its location. Similarly, the active transponder 8 is physically located in the approach to the ABSU location, and could be supplemented by additional transponders or an inductive loop to maintain continuous and smooth train operation. It should also be noted that once a train is identified to an ABSU, its signature will propagate along the line via ABSU to ABSU communication. The data received from the transponder antenna 14 acts as confirmation of the train signature received through ABSU to ABSU communication.
The absolute permissive block concept is based on providing a movement authority to a particular train at a specific location to move for a specific distance or to a specific location. To facilitate the implementation of this concept, the preferred embodiment employs a train identification system that is based on a unique “signature” for each equipped CBTC train. Since it is anticipated that non-equipped trains may operate in the territory, the signature includes two elements, and one of these elements is also present in non-equipped trains. More specifically, the train signature includes a first element that consists of the number of axles in the train consist, and a second element that comprises an alphanumeric code embedded in a transponder mounted on the train. For the preferred embodiment, the alphanumeric code includes two fields, the first field contains a fixed train ID, and the second field includes a trip ID that changes for each train trip. Therefore, for a non-equipped train, only one field (# of train axles) is present in the train signature. The use of the train signature enables the implementation of a number of safety functions, including ensuring that all the cars within a particular train have passed a specific location, tracking a specific train among a “stack” of trains, and facilitating the interfaces with the CBTC installation.
Although the Auxiliary Wayside Signal system operates independently and autonomously of a CBTC system, it is primarily designed to support the operation of a communication based train control installation. As such, it is desirable that the CBTC installation incorporates certain features to facilitate the interfaces with the proposed AWS. More specifically, it is desirable that each CBTC train be equipped with an active transponder that stores a fixed train ID and a variable trip ID. It is also desirable that the train tracking algorithm within the zone controller tracks the number of axles within each train consist. It should be noted that while it is desirable to incorporate the above features into a CBTC system, the proposed AWS system can function without these features. In such case, the train signature will include one element, namely the number of axles in the train consist.
In order to distinguish a failed non-communicating train from a manual unequipped train, the preferred embodiment includes a data field within the variable trip ID that reflects the operating conditions on the train. Information stored in the data field identify if the train is operating with a speed restriction, or operating with a MAL. The absence of proper code in this data field, or the absence of an entire train signature indicates to the ABSUs that the train must be processed as a manual train. Since the train ID is tracked by the AWS system and is communicated from one ABSU to the next, an ABSU can ascertain the operating status of the approaching train upon receiving a communication from the Approach ABSU.
The AWS system includes a plurality of ABSUs that are installed on the right of way, and are interconnected by a fiber optic data communication network, or through data radio communications. The number and spacing between ABSUs is a design choice, and is dependent on the desired operating headway for the AWS system.
Each ABSU includes a data stack defined as “protected stack” that stores the number of trains as well as the signature of each train operating within the associated absolute permissive block. The stack is of the first-in-first-out type, and is used to control the movements of trains during CBTC failures. As such, protected stack 42 is associated with ABSU-126, protected stack 44 is associated with ABSU-224, and protected stack 46 is associated with ABSU-322. In addition, each ABSU includes an “Approaching Train” data field that stores the signature information associated with the first train approaching the ABSU location. As such approaching train data field 32 includes the signature information for the train approaching ABSU-126, approaching train data field 34 includes the signature information for the train approaching ABSU-124, and approaching train data field 36 includes the signature information for the train approaching ABSU-122. It should be noted that the use of a data field to store the signature of the train approaching an ABSU location is disclosed for the purpose of describing the preferred embodiment and is not intended to limit the invention hereto. Another, design choice is for each ABSU to include a second stack that stores the number and signatures of trains approaching the ABSU location (i.e. operating within the absolute block in the approach to the ABSU location). During the standby mode of operation, an ABSU displays a permissive signal indication, and the associated automatic train stop is in the clear position. Further, the ABSU performs three (3) main tasks or functions: First, the ABSU detects the crossing of the train approaching its location. The ABSU uses its axle counter and tag reader to verify that the train identified by the train signature stored in its approaching train data field has completely crossed its location. Upon such verification, the ABSU places the train signature at the bottom of its protected train stack. Second, the ABSU sends a message to the Approach ABSU to indicate that a specific train (as defined by a train signature) has crossed its location. Third, upon receiving a message from the ABSU Ahead that the train at the top of its protected stack has crossed the location of the ABSU Ahead, it removes that train from the stack, and sends a message to the ABSU Ahead to provide the signature of the next train in the stack that will be approaching the location of the ABSU Ahead. In the event, the protected stack is empty, then the ABSU sends a message to the ABSU Ahead indicating that no train is approaching its location.
The ABSU active mode of operation is triggered when the associated CBTC system experiences a failure. During the active mode, and if the protected stack of an ABSU includes any trains, then the ABSU displays a stop aspect, and the associated automatic train stop is set to the tripping position. The ABSU will continue to process the trains in the protected stack similar to the standby mode, and upon verifying that the stack is empty, and depending on operating conditions, it will issue a movement authority limit or a restricted speed for the approaching train to operate through the associated absolute permissive block. In that respect, the operating conditions depend on the nature of the CBTC failure. For example, a zone controller failure causes all trains within its span of control to stop, and then proceed at restricted speed under operating rules and procedures. In such a case, the train signatures will reflect the operation with speed restrictions. A second example, is a single CBTC train failure that results in that train operating at restricted speed under operating rules and procedures. Accordingly, when describing the operation of the ABSUs in active mode, it is necessary to identify the operational assumptions associated with the CBTC failure. It is also important to note that one of the main assumptions related to CBTC and AWS operations is that there is no common failure mode that causes simultaneous failures in both CBTC and AWS. For example, it assumed that a CBTC communication failure will not impact communications between the ABSUs.
It should be noted that the block diagram of
A second AWS operating scenario is related to a failure of a single CBTC train, and is demonstrated in
For the preferred embodiment, ABSU-IXL 152 is designed to support bi-directional traffic on both TK1175 and TK2177. As such, each signal location (S2, S4, S6 and S8) includes an axle counter, a transponder reader and an active transponder 154, 155, 156 & 157. Further, the interlocking control module includes four data fields to store the signatures of trains approaching signal locations S-2180, S4182, S-6184 and S-8186. In addition, the interlocking control module includes four (4) protected stacks 190, 192, 194 and 196 (one protected stack for each destination ABSU 170, 172, 174 and 176). Further, the interlocking control module includes internal tracking stacks 200 to track train movements within the interlocking limits. As such, for the preferred embodiment, the train tracking stacks include TS-3A 202, TS-5A 206, TS-3B 204 & TS-5B 208. The communications between ABSU-IXL 152 and adjacent ABSUs 170, 172, 174 & 176 is provided by the Data Communication Network 20 that provides communications between the zone controller 30 and CBTC equipped trains 171.
Alternatively, in
At a high level within the AWS system, the external operation and functions provided of the ABSU-IXL are similar to the operation and functions provided by any other ABSU. This means that the internal functions of the ABSU-IXL associated with routes within the interlocking, and tracking of trains and their signatures along those routes, are transparent to the AWS.
It should be noted that the demonstrations shown in
As such,
Upon receiving communication from an approaching train that it was issued a movement authority by the zone controller, the associated ABSU displays a clear aspect, and switches its mode of operation to the “standby” mode. As such,
It should be noted that the zone controller initialization process demonstrated in
As indicated in the summary section herein, in the event an ABSU fails while it is operating in a standby mode, the CBTC system detects such failure, and removes the failed ABSU from the AWS configuration.
An alternate ABSU failure scenario can occur when the ABSUs are operating in the active mode. In such scenario, the zone controller is not available to affect the reconfiguration of the ABSUs during an ABSU failure. It should be noted that an ABSU failure while operating in the active mode constitutes a double failure (since the ABSU would fail at the same time when the zone controller has also failed), which is very unlikely. It should also be noted that an ABSU failure while operating in active mode would involve multiple operating scenarios related to the operating condition of the train approaching the failed ABSU. For example, an approaching train could be operating with a movement authority limit, operating with a restricted speed, or could be operating manually pursuant to operating rules and procedures. As disclosed above, a data field within the train signature reflects the operating condition of the train (train status). In view of such multiple operating scenarios, the preferred embodiment provides a unique design for the ABSU that controls the failure state of the ABSU if the failure occurs during an active mode operation. This design is related to the aspect that is displayed at the failed ABSU and the status of the automatic train stop.
More specifically, and as shown in
Under normal AWS operating conditions, an equipped train (with a proper train status reflected in its signature) approaching an ABSU is operating under the protection of either a MAL or a restricted speed. Alternatively, a train without a signature or without a proper train status is considered to be a manual train with no speed restrictions. Accordingly, the failure recovery process when an ABSU that fails while operating in the active mode is as follows: Upon the occurrence of an ABSU failure, it is assumed that communication is interrupted between the failed ABSU and the Approach ABSU, as well as with the ABSU Ahead. In accordance with the preferred embodiment, the ABSU is designed to establish communication with the next ABSU in an AWS configuration when communication is lost with an adjacent ABSU. As such, when an ABSU fails, the Approach ABSU and the ABSU ahead establish communication together as adjacent ABSUs. After such communication is established, the Approach ABSU receives from the ABSU Ahead the train signature of the train approaching its location. Then upon receiving such train signature, the Approach ABSU places the received train signature at the top of its protected stack. However, since the Approach ABSU has no current information related to the trains that were included in the protected stack of the failed ABSU, it inserts additional “provisional” train signatures between the train signature received from the ABSU Ahead and the train signature that was originally at the top of its protected stack. The number of provisional train signatures is a design choice, and is resolved when the train that was originally at the top of said protected stack reaches the ABSU Ahead.
An example of the above disclosed process is provided in
With respect to the failure mode of ABSU-224, and because prior to its failure it received data that approaching train T-256 is an equipped train with proper status, ABSU-2 has failed in the “override” failure state. This means that train T-256 will receive a default code as it reaches the location of ABSU-2, and will continue to operate with speed restriction until it reaches ABSU-322. With respect to train T-754, it will also continue to operate with speed restriction past ABSU-224 until it reaches ABSU-322. In effect, the above described failure management process enables the AWS to “self-heal” from the ABSU-2 failure by combining the absolute permissive blocks of ABSU-126 and ABSU-224 into a longer absolute permissive block.
It should be noted that the premise of selecting an ABSU failure mode based on the operating condition of the approaching train, and without consideration of the operating conditions of trains following the approaching train within the same absolute permissive block, is based on the assumption that the zone controller and the AWS will not permit a manual train (i.e. without speed restriction) to operate following another train within an absolute permissive block. It should also be noted that if a train without a manual train was approaching ABSU-2 prior to its failure, then ABSU-2 will fail in the “stop” failure state. In such case, ABSU-224 will require a manual override to permit the train to proceed to ABSU-3.
In general, the AWS system can be designed to provide protection to manual trains that operate within the AWS territory without speed restrictions. This requires each ABSU to provide an overlap past its location to account for the breaking distance for the manual train tripping at the ABSU location at maximum attainable speed. To implement such design without adding more wayside equipment, and to maintain the generic approach for the ABSU design, the overlap distance is provided by a second absolute permissive block. This means that for a manual train to proceed past an ABSU, the protected stack of two consecutive ABSUs must be empty. As such, the operation of a manual train without speed restriction is demonstrated in
As would be understood by those skilled in the art, alternate embodiments could be provided to implement an auxiliary train control system based on the absolute permissive block concept, and using the new concepts described herein. For example, each ABSU can communicate all the signatures data of the trains within its protected stack to the ABSU Ahead. This will simplify the AWS reconfiguration process in the event of an ABSU failure. Further, the overlap function could be provided via the installation of an auxiliary set of axle counter ahead of the ABSU location to ensure that sufficient braking distance is provided at each ABSU for the operation of a manual train. 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.
Also, it should be noted that the ABSU and the interlocking control device 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. In addition, it is 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 embodiment 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.
This utility application benefits from provisional application of U.S. Ser. No. 61/995,982 filed on Apr. 25, 2014.
| Number | Date | Country | |
|---|---|---|---|
| 61995982 | Apr 2014 | US |
