Virtual block runstate control system and method with long block time delay

Abstract

The invention provides a virtual block running state control system and method with long block time delay. By determining the normal state of the virtual block, the capacity and safety of the existing railway track infrastructure of a railway company can be effectively improved. The long block pattern may provide coarse-grained information about the presence of the train. In the virtual block mode, the system can realize finer granularity, so that the virtuality of the sub-blocks can be realized. The present disclosure provides a long block mode that can provide a system with a potential tradeoff opportunity between analysis granularity and reliability by determining which mode (virtual block or long block) is most suitable for utilization in a particular case. The system may default to run in a long block mode and ignore virtual block functions until absolute needs.

Description

Technical Field

[0001] The present invention generally relates to railway signal systems, and more particularly to normal signaling of railway virtual track block systems. Background Art

[0002] Block signaling is a common technique used in rail transport to maintain spacing between trains and thus avoid collisions. Generally, rail lines are divided into track blocks, and automated signals (usually red, yellow, and green lights) are used to control the movement of trains between blocks. On one-way tracks, block signaling allows trains to follow each other and minimizes the risk of rear-end collisions.

[0003] However, conventional block signaling systems have at least two significant drawbacks. First, track capacity cannot be increased without additional track infrastructure (e.g., additional signals and associated control equipment). Second, conventional block signaling systems cannot identify broken rails within an occupied block.

[0004] Standard practices for the design and function of railway signaling systems are based on the concept of "critical systems." Critical systems are typically fail-safe and adhere to the closed-loop principle. A system is considered fail-safe if it can automatically recover to its safest state if any component in the system fails. For railway wayside systems, fail-safe design requires that the system automatically recover to its safest state if any component critical to safety and normal operation fails to perform its intended function. Critical systems adhere to the closed-loop principle because system components do not share components that could provide alternative energy sources or logic paths, which would violate the fail-safe principle.

[0005] Mobile high-density block systems transmit voltage and current along the track to measure track resistance. When a train approaches a track segment being measured, the axle connecting the two wheels effectively shunts the track circuit, allowing the train's position within the measured physical segment to be determined. However, track circuit shunts can indicate not only the train's specific location but also the location of hazards, such as broken track or other types of hazards.

[0006] The current Onboard Movement Authority (OMA)-Virtual Block System (VBS) Train Control (PTC) (OMA-VBS PTC) track database requires that hazards be paired with opposing hazards. Due to limitations, the locomotive onboard computer cannot perform logical "OR" operations on virtual track segments; the locomotive can only perform logical "AND" operations. This problem arises when a train first occupies a physical track circuit. Virtual track segments within the train's own route change to a "FALSE" state from the near-end perspective. When the locomotive onboard computer performs an "AND" operation with the far-end perspective of the same virtual track segment, a "FALSE" state is generated for these track segments on the onboard display, requiring the train to slow down or stop. These unnecessary slowdowns or stops negatively impact railroad operational efficiency.

[0007] The virtual block system is powerful because it allows for a finer granularity in determining the location of trains than a physical block system. However, certain issues can arise due to the greater potential for false positives or health issues at the virtual block level. Summary of the Invention

[0008] The present disclosure provides a virtual block system and method with long block time delay, which achieves technical advantages. The present disclosure provides a system that is integrated into a practical application with meaningful limitations that can advantageously increase the capacity and safety of existing railway track infrastructure used by railways by determining whether virtual blocks are normal. In one example, long block mode can provide coarse-grained information about the presence of trains. In another example, in virtual block mode, the system can achieve finer granularity, thereby enabling virtuality of sub-blocks. The present disclosure solves the technical problems of virtual block systems by providing a long block mode, which can provide the system with an opportunity to analyze potential trade-offs between granularity and reliability by determining which mode (virtual block or long block) is best utilized in a given situation. The system can default to running in long block mode and ignore virtual block functionality until absolutely needed.

[0009] Thus, the present disclosure discloses concepts that are inseparable from computer technology, such that the present disclosure provides technical advantages by default operating in long block mode, because if the normal condition of the virtual block is unknown and a failure occurs, it may be too late to prevent the train from entering the danger zone. The train must be transferred to an emergency operation state, which may cause additional dangers and damage to the locomotive. Therefore, the system may not rely on the normal state until it is confident in such reliance, and the specific details will be discussed further below. Advantageously, the system can make decisions before broadcasting data to the train. Therefore, the on-board computer can remain unchanged, because if the on-board computer is to receive any other type of data, the on-board computer will need to be redesigned, thereby increasing the expenditure of money and time. The present disclosure utilizes existing infrastructure to improve capacity and safety.

[0010] The present disclosure provides a technical solution lacking in conventional systems by, in at least one embodiment, providing virtual block health as a condition for the system's ability to utilize virtual block states (e.g., status). For example, certain checks and balances must be established before the system can act on these states. In one embodiment, the system can provide a single-bit discrete state indicating whether a virtual block is healthy from both the east and west perspectives of each wayside machine room. The system can utilize this state and define the current operating mode for each machine room. In one embodiment, the system can analyze the trade-offs to maintain full speed for the first train while maintaining at least a slightly greater distance for the second train and being able to utilize virtual block states when available. Specifically, if both critical application software (trackside) and execution software (onboard) are in virtual block mode, and the system is unable to enter long block mode (e.g., after the virtual block state cannot be determined) when the train occupies the first virtual block, additional safety measures and restrictions will be required on the train route ahead of the moving train. Because this restriction will be implemented as a full-scale application of the train's braking system, it will result in a significant reduction in speed. By not upgrading critical application software to virtual block mode until subsequent trains are available, the execution of software failure modes does not result in additional hazards or restrictions on the train's route ahead. The present disclosure offers additional technical advantages such as increasing rail capacity without increasing infrastructure, reducing maintenance costs for asset-intensive signaling systems, and leveraging significant investments in existing Positive Train Control (PTC) onboard systems.

[0011] The present disclosure improves the performance and functionality of the system by implementing a specialized algorithm that is adapted to determine the true state of a virtual block based on multiple inputs. In one embodiment, the system may be in long block mode when the wayside system critical application software is in a quiescent state and during a first time period (e.g., the first 10 seconds after the first train enters the physical block). A normal system may be in a resting state executing software, but in virtual block mode unless a fault is detected after a train occupies the physical block. The first time period (e.g., a 10-second interval) may provide sufficient time for the executing software to perform a check to determine whether it is safe to continue in virtual block mode or switch to long block mode.

[0012] The present disclosure provides a system for controlling the operating state of a virtual block. A further object of the present disclosure is to provide a method for controlling the operating state of a virtual block. These and other objects of the present disclosure are provided by at least the following embodiments.

[0013] In one embodiment, a system for virtual block operating status control may include: a memory containing a first database storing operating status or specifications associated with a vehicle or at least a portion of a railway track; and a processor operably coupled to the memory, the processor capable of executing machine-readable instructions to perform program steps, the program steps comprising: generating a plurality of virtual blocks within a physical block; generating a long block within the physical block; operating in a long block mode until virtual block occupancy is detected; determining whether the first set of virtual blocks is normal from a perspective of a first wayside machine room; when the first set of virtual blocks is normal, operating in a virtual block mode and identifying the occupancy status of each normal virtual block from the perspective of the first wayside machine room; and when the first set of virtual blocks is abnormal, operating in a long block mode and identifying the occupancy status of the long block from the perspective of the first wayside machine room. The first set of virtual blocks is from the eastbound perspective of the first wayside machine room. The program steps further include: determining whether a second set of virtual blocks is normal from the perspective of the first wayside machine room. The second set of virtual blocks is from the westbound perspective of the first wayside machine room. The program steps further include: generating a virtual block normal status indication. The program steps further include: performing a check within a first time period after detecting occupation of the virtual block to determine whether it is safe to maintain virtual block mode. The first time period is a 10-second interval. When the virtual block becomes abnormal or its normal status is uncertain, operation in virtual block mode may fail and enter long block mode. The normal status of the virtual block is represented by a single bit. The physical block may be a section of track between insulating joints.

[0014] In another embodiment, a method for controlling the operating status of a virtual block may include: generating, via control logic, multiple virtual blocks within a physical block; generating, via control logic, a long block within the physical block; operating in long block mode until virtual block occupation is detected; determining, via control logic, whether a first set of virtual blocks is normal from the perspective of a first wayside machine room; when operating in virtual block mode, when the first set of virtual blocks is normal, calculating the occupation status of each normal virtual block from the perspective of the first wayside machine room; and when operating in long block mode, when the first set of virtual blocks is abnormal, calculating the occupation status of the long block from the perspective of the first wayside machine room. The method further includes: determining whether a second set of virtual blocks is normal from the perspective of the first wayside machine room. The second set of virtual blocks is from the westbound perspective of the first wayside machine room. The method further includes: generating a virtual block normal status indication. The method further includes: performing, via control logic, a check within a first time period after detecting virtual block occupation to determine whether it is safe to maintain virtual block mode. The first time period is a 10-second interval. When a virtual block becomes abnormal or its normal state is uncertain, operations in virtual block mode may fail and enter long block mode. The normal state of a virtual block is represented by a single bit. A physical block can be a section of track between insulating joints. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The present disclosure will be readily understood by the following detailed description in conjunction with the accompanying drawings, which illustrate the principles of the present disclosure by way of example. The accompanying drawings illustrate the design and practicality of one or more exemplary embodiments of the present disclosure, wherein like elements are represented by like reference numerals or symbols. Objects and elements in the drawings are not necessarily drawn to scale, ratio, or exact positional relationship. Instead, emphasis is placed on illustrating the principles of the present disclosure.

[0016] Figure 1 A schematic diagram illustrating a representative number of unoccupied physical railroad track blocks and associated signal (control or wayside) rooms, wherein each physical track block is divided into a selected number of virtual track blocks, and a listing of certain messages and their corresponding values, consistent with one or more exemplary embodiments of the present disclosure;

[0017] Figure 2 Shown Figure 1 a schematic diagram of the system shown, including authorized lines to a leftmost signal room and corresponding message values, consistent with one or more exemplary embodiments of the present disclosure;

[0018] Figure 3 Shown Figure 1A schematic diagram of a system shown with a westbound train approaching a rightmost signal room and displaying corresponding message values, consistent with one or more exemplary embodiments of the present disclosure;

[0019] Figure 4 Shown Figure 1 A schematic diagram of the system shown, with a westbound train entering the H3 virtual block and corresponding message values ​​displayed, consistent with one or more exemplary embodiments of the present disclosure;

[0020] Figure 5 Shown Figure 1 A schematic diagram of the system shown, with a westbound train entering the G3 virtual block and corresponding message values ​​displayed, consistent with one or more exemplary embodiments of the present disclosure;

[0021] Figure 6 Shown Figure 1 A schematic diagram of the system is shown, with a westbound train entering the F3 virtual block and corresponding message values ​​displayed, consistent with one or more exemplary embodiments of the present disclosure.

[0022] Figure 7 Shown Figure 1 A schematic diagram of the system shown, with a westbound train entering the E3 virtual block and corresponding message values ​​displayed, consistent with one or more exemplary embodiments of the present disclosure;

[0023] Figure 8 Shown Figure 1 A schematic diagram of the system shown, with a westbound train entering the D3 virtual block area, with known and unknown virtual block area normal states and corresponding message values ​​displayed, consistent with one or more exemplary embodiments of the present disclosure;

[0024] Figure 9 Shown Figure 1 a schematic diagram of the system shown, with a westbound train entering the D3 virtual block area, having a known virtual block area normal state, and displaying corresponding message values, consistent with one or more exemplary embodiments of the present disclosure; and

[0025] Figure 10 A flow chart is shown, which exemplarily illustrates a control logic including a long block logic in a method for controlling a virtual block operation state according to one or more exemplary embodiments of the present disclosure. DETAILED DESCRIPTION

[0026] The disclosure and its various features and advantageous details set forth in the following written description will be more fully explained with reference to the non-limiting examples included in the accompanying drawings and the content detailed in the specification. Descriptions of well-known components are omitted herein so as not to unnecessarily obscure the main features described herein. The following examples are intended to facilitate an understanding of how the disclosure may be implemented and practiced. One of ordinary skill in the art will understand that the disclosure means that any suitable combination of the following functions or exemplary embodiments may be combined to achieve the claimed subject matter. The disclosure includes the number of representative species within the genus, or structural features common to members of the genus, so that one of ordinary skill in the art can identify members of the genus. Therefore, these examples should not be construed as limiting the scope of the claims.

[0027] A person of ordinary skill in the art will understand that any system claim set forth herein encompasses all elements and limitations disclosed therein, and therefore each system claim is required to be considered as a whole. Any reasonably foreseeable item that has a functional relationship with the claim also falls within the relevant scope. After thoroughly understanding the disclosure and claims in the application as filed, the examiner searched for prior art disclosed in patents and other published documents (i.e., non-patent literature). Therefore, as evidenced by the issuance of this patent, the prior art fails to disclose or teach the elements and limitations set forth in the claims supported by the specification and drawings, and therefore the claims as filed are patentable under the applicable laws and rules of this jurisdiction.

[0028] Generally speaking, track circuits are used to provide train and broken rail detection, and may also transmit data from one machine room to another. In one embodiment, the boundaries of a two-mile physical track segment may be separated from an adjacent two-mile track segment by an insulating joint (e.g., a clear plastic joint within the track). Importantly, not all track circuits are 2 miles, but they may be divided into segments. Although the embodiments of the disclosure herein show the physical track divided into 25% increments, any track increment percentage may be used. For example, the concepts disclosed in this disclosure apply regardless of whether the physical track is divided into three 33% track segments, two 50% track segments, irregular track segments, or other suitable track segments. Furthermore, the concepts disclosed herein apply regardless of the number of virtual blocks or the length of the physical blocks (e.g., 1 mile, 5 miles, N miles, etc.).

[0029] The system disclosed herein may include a transceiver located near a wayside machine room that can transmit signals along the rails and receive them at a second machine room. For example, when a block is occupied by a train, the transmitted signals can be redirected back to the transceiver. In one embodiment, the system may include a transmission circuit that transmits signals along one track through a train axle and receives them at a second track. The current resistance circuit may determine the actual position of the axle based on, for example, resistance measurement, time delay, or other suitable methods. The system may also include components such as a chassis, a key logic controller located in each wayside machine room, and contact devices for occupied blocks. Furthermore, states can be defined in a ladder logic application. The ladder logic can be implemented in the key controller in the machine room and use these inputs to determine the content broadcast to the onboard computer. The ladder logic program can determine the joystick value and bit number based on the chassis measurement input signals and, based on this, determine the state of the virtual block. The system may also utilize the PTC interoperability messaging standard to enable information exchange between wayside equipment and onboard equipment. In another embodiment, the messaging standard may include a railway-defined payload portion to convey additional information. The fields, characteristics, and values ​​detailed below may be transmitted as part of this payload.

[0030] The normal state of a virtual block can be represented by a single bit stored in an important logic controller or system. Similarly, the ladder logic can include multiple normal states or variables that can be referenced by the system. The normal state of a virtual block can be a variable with a logic "0" or logic "1" value. For example, a logic "1" value can represent a normal block, while a logic "0" value can represent an abnormal block. In another embodiment, during the normal check of the virtual block, the virtual block can be identified as abnormal. The normal state of the virtual block can be dynamically determined and decided by a variety of real-time algorithms (sub-second processing speed) deployed on the safety logic controller or remote server.

[0031] For example, when a train enters a track circuit, it first shunts off the chassis, requiring a moment for the system to determine and analyze the track resistance along the entire length of the track. In another embodiment, the system can measure the resistance of a track section and analyze the resistance by comparing the measured resistance value with historical resistance values ​​for the measured track section over time. By correlating the measured resistance value with historical resistance values ​​stored in memory, the system can determine whether the resistance is normal or abnormal based on deviations from the historical values. This analysis allows the system to determine whether the abnormal value is due to a broken track or other reasons for varying track conditions (e.g., wear, local weather, or aging). The system can also plot the historical distance traveled for the analyzed railroad section. For example, if the system measures a resistance that is 50% of the track section's historical resistance—for example, a resistance of 3 ohms is exactly half the resistance of the physical block—the system can determine based on this analysis that two virtual blocks are unoccupied and two are occupied. However, unless the measurements are calibrated when the train starts (e.g., during initial movement) so that the added resistance is within a known tolerance (e.g., stored in system memory), the system may not be able to reliably evaluate the measured data against the known resistance curve.

[0032] Figures 1 to 9 The track segments shown represent physical track blocks 101a, 11b, 11c, and 101d, with physical track blocks 101a and 101d shown partially, and physical track blocks 101b and 101c shown fully. Physical track blocks 101a-101d can be separated by conventional insulating joints 102a, 102b, and 102c. Signal control rooms 103a (#1), 103b (#2), and 103c (#3) can be associated with corresponding insulating joints 102a-102c. Each signal room 103 can be equipped with corresponding insulating joints 102 on both sides of the track for transmission.

[0033] In one embodiment, each physical track block 101a-101d can be divided into multiple virtual track blocks or "virtual track blocks." In the illustrated embodiment, these virtual track blocks can each represent one-quarter (25%) of each physical track block 101a-101d, although as described above, in alternative embodiments, the number of virtual track blocks per physical track block can vary. In Figures 1-9, machine room #1 (103a) can be associated with virtual track blocks A1-H1 (shown as C1-H1), machine room #2 (103b) can be associated with virtual track blocks A2-H2, and machine room #3 (103c) can be associated with virtual track blocks A3-H3 (shown as A3-F3). The track can continue in this manner in both directions indefinitely to accommodate more machine rooms and more track blocks. For example, machine room #4 (not shown) can be associated with virtual track blocks A4-H4 (shown as A4-B4). Furthermore, since the virtual block overlap can theoretically continue indefinitely on either side, only a section of track is presented where the machine room #2 has a complete virtual block, thereby truncating the two non-overlapping blocks of machine rooms #1 and #3. These examples are intended to help understand how the present disclosure may be implemented and practiced, and the present disclosure should not be limited to these examples.

[0034] In other words, in the embodiment shown, each room 103 can be associated with four (4) virtual track blocks (e.g., virtual track blocks A1-D1) to the left of the corresponding isolating joint 102 (e.g., from a westbound perspective), and four (4) virtual track blocks (e.g., virtual track blocks E1-H1) to the right of the corresponding isolating joint 102 (e.g., from an eastbound perspective), for a total of eight virtual blocks (A1-H1). In this configuration, the virtual track blocks can overlap. In one embodiment, the eastbound perspective virtual track block of room #1 103a can overlap with the westbound perspective virtual track block of room #2 103b, such that each overlapping virtual block can have two variables representing it, based on the perspective - room #1 or room #2. For example, virtual track block E associated with room #1 l-H1 can overlap with virtual track block A2-D2 associated with room #2, such that virtual block F1 (from the perspective of room #1) and virtual block B2 (from the perspective of room #2) correspond to the same virtual block from the perspectives of different rooms. This provides the advantage of being able to have two views of the same virtual block, so if one view is blocked (e.g., due to a diversion of an adjacent virtual block), the other view can provide a view of the overlapping virtual block. For the purposes of this disclosure, a particular virtual block can be represented as a virtual block from the perspective of each room, where a logical AND operator (·) is used between each variable (e.g., F1·B2, F2·B3, etc.). To leverage existing on-board functionality, the system can also implement a logical AND of virtual block states. However, in another embodiment, the system can implement a logical OR operation for each virtual block state bit.

[0035] The system can measure rail resistance and can take into account many other safety-critical calculations, such as nonlinear rail resistance, rail temperature variations, and rail stress variations. In one embodiment, the system can also determine the distance of the rail shunting (e.g., the distance from the machine room 103) and normalize it to, for example, one of four locations within the track circuit (e.g., corresponding to a specific virtual block).

[0036] The four virtual track blocks may correspond to 25% of the physical length, thus providing four bits for a particular track circuit - one for each virtual block. The system can determine and set the state of these bits (e.g., high (1) or low (0)) based on the known train position at that time. These four bits can define the state of these known track segments. In another embodiment, the system can define the state of these four virtual blocks from the perspective of two machine rooms, because the virtual blocks of two machine rooms will overlap with any given track segment. Thus, these four bits can represent the state of, for example, a two-mile track section from the perspective of the east and west, so that both ends have a specific state. It is the responsibility of the onboard computer to act on these two states.

[0037] Each Figure 1-9A table is included that has different message types and corresponding values ​​for each message type based on the events shown in the figure. A virtual logic controller can be set up at each machine room 103a-103c to receive messages to create a virtual block. In one embodiment, each of these important logic controllers can receive all states sent or received. In another embodiment, all states that do not indicate PTC or onboard can be received by the important logic controller. The state indicating PTC or onboard can be the output signal being transmitted by the virtual logic controller. The system can measure and provide the state as an input signal, for example, the ladder logic in the important logic controller. The state indicating PTC can be transmitted from the important logic controller to the train. Most other states can be understood from the perspective of the important logic controller. In another embodiment, the ladder logic within the important logic controller can determine how the system uses these inputs under these conditions and what data is transmitted to the train.

[0038] Figure 1-9 The table in the table includes messages and the data corresponding to these messages. For example, "vehicle signal" refers to virtual block status information sent to the vehicle computer, as described in detail below. PTC Virtual Block Hazard Signal (PTC VBHaz) represents a PTC message whose specific payload is the device type hazard identifier and uses a single-bit data format. PTC Authentication (PTC Auth) represents a PTC message whose specific payload is the device type authorized by the signal and is a 5-bit status representing a message. Virtual Block (VB) is the status of each virtual block in a specific computer room (for example, the occupied or unoccupied status of a specific virtual block). PTC Long Block Hazard (PTC LB Haz) represents a PTC message whose specific payload is the device type hazard and uses a single-bit data format. Each critical logic controller in the computer room can receive these signals. In one embodiment, the critical logic controller can be aggregated or subordinate to another virtual logic controller. In another embodiment, the critical logic controller can transmit the message to the vehicle computer.

[0039] Each Figure 1-9Also included are indications of the normal status of virtual blocks on the west side 104a-104c of the computer rooms 103a-103c and indications of the normal status of virtual blocks on the east side 105a-105c of the computer rooms 103a-103c. The west side virtual block normal indications 104a-104c and the east side virtual block normal indications 105a-105c may have associated messages, bits, flags, or other suitable mechanisms to indicate the normal status of the virtual blocks from the perspective of the computer room 103. For ease of explanation, the normal status of the virtual blocks in the figures is indicated by a "check mark" above the VB with a heart icon, indicating a normal virtual block, and an "X" above the VB with a heart icon, indicating an abnormal virtual block. The system may maintain a high level state (e.g., a logical "1") for a normal virtual block and a low level state (e.g., a logical "0") for an abnormal virtual block.

[0040] In one embodiment, the table may also include an indication of the current operating mode (e.g., virtual block mode (VB) or long block mode (LB)) of the west track circuit (WB) and east track circuit (EB) of each machine room 103. In one embodiment, the WB may be the physical track circuit on the west side of the machine room 103, from an isolation joint 102 (e.g., 102c) adjacent to the machine room 103 to a corresponding isolation joint 102 (e.g., 102b) in an adjacent machine room 103. In another embodiment, the following table shows the current operating modes of the WB and EB track circuits of three machine rooms, where only the EB track circuit of machine room #3 is operating in VB mode:

[0041] In one embodiment, a low state (abnormal) can be configured as a safe state. Assuming a block is abnormal when it might actually be normal is much safer than assuming it is normal when it might be abnormal, so the system must assume a block is abnormal unless otherwise specified. In another embodiment, the safe state can indicate that the block is abnormal as a failure mode. In traditional signaling terminology, the term "stick" can be used to define a variable that remains in a specific state after a pattern is established. Additionally, a variable can "hold" a predetermined value (e.g., high or low) due to a known condition.

[0042] In one embodiment, to prevent problems at the head end of the train, the system defaults to LB mode instead of VB mode. In addition to broadcasting the virtual block status, the system can also broadcast two additional data bits representing the status of the entire virtual block track on both sides of the machine room (e.g., two physical track miles). For example, one bit can represent two miles west of the machine room, and the other bit can represent two miles to the right of the machine room. Therefore, at this time, the physical track circuit status is good because the system receives code 1 and code 2 from the distant machine room (e.g., machine room #3). If the system can receive the code, the virtual block is not occupied, so it can broadcast "1" to the trains for the entire virtual block. The system can also broadcast the PTC status "1" to the trains. Therefore, these bits together determine the overall status of this 2-mile segment.

[0043] Figure 1 A track section with no train nearby is shown. All machine rooms 103a-103c can generate and maintain a virtual block (VB) value '11111111', representing the corresponding virtual track block A. i -H i (e.g., i=0, 1, 2, 3, 4, etc.). When a train enters a virtual block area and shunts the circuit, the VB value of the virtual block area may change from logic "1" to logic "0" or any suitable value. The virtual block is normal, as shown by the west side virtual block normal indications 104a-104c and the east side virtual block normal indications 105a-105c, which have a "check mark" above the VB with a heart icon, which may correspond to a high level state (e.g., logic "1") stored and transmitted by the system. Reference Figure 1 In the bottom table, the system is in long block mode (LB) and is quiescent.

[0044] exist Figure 1In this example, there is no train on the track, and no train is detected in either the long block or the virtual block. Therefore, Engine Room #1 103a, Engine Room #2 103b, and Engine Room #3 103c can generate and maintain a virtual block (VB) value of "11111111" via the system (e.g., one or more local or remote VLCs), indicating that no virtual blocks are occupied from their perspective. In one embodiment, the system can monitor the LB mode state and mask the VB mode state. At this point, the onboard system may not know whether the system is operating in LB mode or VB mode (operating state). In another embodiment, both states can be communicated to the train at all times, with the train being responsible for ensuring that the trackside equipment correctly broadcasts one state or the other. In another embodiment, the backend (e.g., a virtual logic controller) can determine whether the train receives the LB mode state or the VB mode state. In another embodiment, the train can receive both the LB mode state and the VB mode state, but can ensure that the system does not mask these states regardless of the mode the train is operating in. For example, the operational state is independent (e.g., not maintained at one) and is allowed to drop to zero based on the system operating mode defined in the logic of the virtual logic controller. In another embodiment, the system may mask one or the other operating state at any given time. In another embodiment, when in a quiescent state, the track circuit may include a PTC LB HAZ identifying no track circuit shunting. For example, the PTC LB HAZ may list "1------1" for room #1, "1------1" for room #2, and "1------1" for room #3, indicating that from the perspective of any room (e.g., rooms #1-#3), there are no virtual block track sections that are shorted (e.g., occupied) on either the WT or ET. In another embodiment, the system operates in the LB state when quiescent (e.g., unoccupied).

[0045] refer to Figure 2 , the system 100 can authorize movement authority 202 to a first location, such as room #1. In one embodiment, the PTC authorization can be set to indicate passing through one or more rooms #1-#3. For example, when movement authority is granted through room #3 and room #2 to room #1, a westbound flag (e.g., 1) can be set for the PTC authorization value of room #3 and room #2. Because the train will be traveling from east to west on the track. Since the train only has travel authority to room #1 (and cannot exceed that authority), the westbound flag is not set for room #1. The virtual blocks are still normal, as shown by the west side virtual block normal indication 104a-104c and the east side virtual block normal indication 105a-105c, which have a "check mark" above the VB with a heart icon, which can correspond to a high level state (e.g., logic "1") stored and transmitted by the system. Reference Figure 1In the bottom table, the system is still in quiescent state in Long Block Mode (LB).

[0046] refer to Figure 3 When train 104 enters physical block 101d on its way to a first location (e.g., engine room #1), train 104 may occupy and shunt the first-stage virtual block (e.g., H3 of engine room #3) by setting the H3 VB variable to "0." Engine rooms #1 and #2 may generate and maintain a virtual block (VB) value of "11111111" through the system, indicating that all virtual blocks are unoccupied from their perspective, while engine room 3 may generate and maintain a virtual block (VB) value of "111111110" through the system, indicating that one of the virtual blocks is occupied from their perspective. In another embodiment, upon detecting a virtual block shunt, a PTC authorization may be set in LB mode to indicate the occupancy of train 104 on the ET from the perspective of engine room #3. For example, the system may set PTC LB HAZ to "1------0" to indicate a shunt on the ET from the perspective of engine room #3.

[0047] In one embodiment, the system may monitor the LB mode state and mask the VB mode state. In another embodiment, when a virtual block shunt is detected, the system wishes to transition the operating mode from LB mode to VB mode to provide more refined train location information. However, despite the shunt, the system may not have verified that the virtual block is normal and cannot transition the operating mode to VB, so the operating mode remains in LB. The PTC VB Haz H3 virtual block variable is in the "don't care" state because it is farthest from machine room #3. In another embodiment, the don't care state can be displayed in the diagram as a circle with a slash superimposed on the specific virtual block identifier, or as a "-" in the message or bit representation. Reference Figure 1In the bottom table, the system remains in a static state in long block (LB) mode. For LB mode, a train shunts 204 to the EB of room #3, and the PTC LB Hazard Status for the ET track of room #3 can transition from "1" to "0." For example, the PTC LB HAZ may list "1------1" for room #1, "1------1" for room #2, and "1------0" for room #3, indicating a shunt east of room #3. The virtual block west of room #3 remains normal, as shown by west virtual block normal indicators 104a-104c and east virtual block normal indicators 105a-105b, which each have a "check mark" above the VB with a heart icon. However, after detecting the east bypass of room #3, the system verifies the VB normal status of the EB virtual block via east virtual block normal status indicator 105c, which has a question mark and a heart icon above the virtual block. In another embodiment, during virtual block checking, the system may identify the virtual block as abnormal by default regardless of the actual status.

[0048] In one embodiment, the system cannot determine whether the virtual block is normal when the train 104 enters, so it can perform an analysis to determine the normal state of the virtual block. For example, the resistance of the rails can be affected by temperature, age, ballast (gravel under the railroad ties), humidity, or other conditions that may cause the rail resistance value to increase or decrease. In another embodiment, the resistance measurement and analysis can determine the confidence level that the virtual block is normal when the train enters. In another embodiment, the normality check can be performed from the perspective of the near-side machine room, the perspective of the far-side machine room, or an appropriate combination or distribution of the two. In another embodiment, an equipment failure or the presence of an obstruction on the track may trigger the system to indicate that the virtual block is abnormal.

[0049] At this point, switching from LB mode to VB mode has no practical significance. The main advantage of using VB mode is to improve the operating efficiency of subsequent trains. Therefore, when a virtual block is abnormal or the normal status of VB is unknown, the system can allow the train to enter the virtual block. In another embodiment, because the system is in LB mode instead of VB mode, the system can disconnect the entire physical track circuit. In another embodiment, the onboard computer can have the same geographical perspective as the physical track. For example, because the onboard computer knows the geographical coverage area represented by the virtual block and knows that it is currently occupying a geographical coverage area when the virtual block is shunted (for example, changed to "0"), it can determine that the shunting state is caused by the train itself, and the system will not mistakenly judge it as a track obstacle. Therefore, in this mode, the train can travel at full speed. In another embodiment, when the train itself does not occupy a virtual block, the system will determine that there is an obstacle in that block.

[0050] refer to Figure 4 In one embodiment, once the system performs a virtual block health check and identifies the virtual block health status of the EB virtual block as "normal," the EB virtual block indicated by the east virtual block health indicator 105c may be changed to a "check mark" with a heart icon above VB. In another embodiment, after a predetermined period of time (e.g., 10 seconds after the train enters VB), the application may change from long block mode to virtual block mode on the east track circuit of machine room #3.

[0051] In one embodiment, after determining that the virtual block's normal indication is normal and the virtual block is shunted, the operating mode can be immediately set to VB mode and the train can continue to pass through the virtual block. In another embodiment, if a virtual block is determined to be abnormal when the train 104 passes through the virtual block, the system can determine that the train is allowed to safely pass through the virtual block that was recently in an abnormal state because the system knows that the virtual block is idle as of the current moment. In another embodiment, the system can continuously or at set time intervals determine whether each virtual block is normal. In another embodiment, when a virtual block becomes abnormal, the system can discard all normal states and assume that all virtual blocks are abnormal.

[0052] When the train 104 mobilizes the virtual block H3 and determines that the VB is normal, the system can identify the following status of each virtual block in each machine room:

[0053] Specifically, the operating mode of the EB track of machine room #3 is set to VB mode, and the PTC LB hazardous status can be converted from "0" back to "1". For example, the system can set the PTC LB HAZ to "1------0" to indicate a diversion on the ET from the perspective of machine room #3. This is an example of the system hiding the status based on the operating mode. Once the VB normal check is completed and the location is upgraded to VB mode, the system can restore the track circuit by keeping the VB status at a high level. In another embodiment, the normal status check may only be performed at the initial diversion of the virtual block. If the system does not determine whether the VB mode is normal when the train enters, the system may not be able to upgrade again until the train completely leaves the virtual block. Therefore, for example, if possible, the system may need to upgrade the VB mode when the train enters so that the system can take advantage of the upgrade when the virtual block is cleared.

[0054] The final decision on when to transition from LB mode to VB mode can be made by the control logic based on an analysis of the conditions of the various virtual blocks or operating states. The system can receive a confidence indication of the virtual block state. Even if the system is confident in the state of its virtual block, the system can choose to operate in LB mode because it can recognize that neither is occupied, but the logic itself can be in long block mode at this time, even if the health of the chassis' virtual blocks is still being evaluated. The system can always operate in VB mode unless a fault occurs. LB mode is the safest mode because it protects the entire track circuit regardless, but if the virtual block is healthy, the system will benefit from more granular information while maintaining safety.

[0055] refer to Figure 5 As train 104 continues west, it occupies a section of track and diverts virtual block G3. Machine rooms #1 and #2 can generate and maintain a virtual block (VB) value of "11111111" through the system, indicating that from their perspective, all virtual blocks are unoccupied, while machine room #3 can generate and maintain a virtual block (VB) value of "11111100" through the system, indicating that from their perspective, two virtual blocks are occupied. The system can broadcast the diversion at VB G3 to the train. Although virtual block H3 is no longer visible, the system can determine that a diversion exists at virtual block G3. PTC VBHAZ can list "-111110-", indicating that virtual block G3 of machine room #3 is diverted. Virtual block H3 from machine room #3 can be identified as being in a "don't care" state because the machine room with more EBs will have a better understanding of the status of the virtual block.

[0056] refer to Figure 6 As train 104 continues west, it occupies a portion of track 204 and shunts the F3·B4 virtual block area. Machine rooms #1 and #2 can generate and maintain a virtual block (VB) value of "11111111" through the system, indicating that from their perspective, all virtual blocks are unoccupied, while machine room #3 can generate and maintain a virtual block (VB) value of "11111000" through the system, indicating that from their perspective, three virtual blocks are occupied. In one embodiment, virtual block G3 is no longer visible from the perspective of machine room #3, and a PTC hazardous state may be triggered. The PTC VB HAZ may list "-111101-," indicating that virtual block F3 of machine room #3 is shunt. Virtual block G3 from machine room #3 can be marked as unoccupied (e.g., "1"), while virtual block H3 from machine room #3 can be marked as "don't care" because the machine room with a higher EB has better information about the state of the virtual block.

[0057] refer to Figure 7As train 104 continues west, it occupies a portion of track 204 and shunts virtual block E3·A4. Machine rooms #1 and #2 can generate and maintain a virtual block (VB) value of "11111111" through the system, indicating that from their perspective, all virtual blocks are unoccupied. Machine room #3 can generate and maintain a virtual block (VB) value of "11110000" through the system, indicating that from their perspective, two virtual blocks are occupied. In one embodiment, virtual blocks F3 and G3 are no longer visible from the perspective of machine room #3, and therefore the PTC hazardous state of F3 and G3 may be triggered. The PTCVB HAZ may list "-111011-," indicating that virtual block E3 of machine room #3 has been shunt. Virtual blocks F3 and G3 in machine room #3 can be marked as unoccupied (e.g., "1"), while virtual block H3 in machine room #3 can be marked as "don't care" because the machine room with a higher EB has better knowledge of the state of this virtual block.

[0058] refer to Figure 8As train 104 continues westbound, it passes through engine room #3 and occupies a portion of track 204, shunting virtual blocks H2 and D3. Engine room #1 can generate and maintain a virtual block (VB) value of "11111111" through the system, indicating that from its perspective, all virtual blocks are unoccupied. Engine room #2 can generate and maintain a virtual block (VB) value of "111111110" through the system, indicating that from its perspective, one of the virtual blocks is occupied. Engine room #3 can generate and maintain a virtual block (VB) value of "00000000" through the system, indicating that from its perspective, all virtual blocks are occupied. In one embodiment, when the train shuns on a section of track circuit 802 between engine rooms #2 and #3, the system can be in a stationary LB mode. In another embodiment, because the system is in LB mode for the WB track of engine room #3, all virtual blocks on the WB track can be displayed as shunted (e.g., "00000000"). In another embodiment, upon detecting a virtual block shunt, a PTC authorization can be set in LB mode to indicate the occupancy of train 104 on the ET from the perspective of machine room #2. For example, the system can set the PTC LB HAZ to "1------0" to indicate a shunt on the ET from the perspective of machine room #2. In another embodiment, since track circuit 802 between machine rooms #2 and #3 is shunted, the VB health status of track circuit 802 is marked as unknown ('?' 105b and '?' 104c) and is again queried by the system. The system can then perform a virtual block health check to determine whether the track circuit virtual block is normal and upgrade the operating state from LB mode to VB mode. In another embodiment, the PTC hazardous state of F3 and G3 may be triggered. The PTC VBHAZ may lieh "-110011-", indicating that virtual block E3 of machine room #3 is shunted. Virtual blocks F3 and G3 in machine room #3 can be marked as unoccupied (e.g., "1"), while virtual block H3 in machine room #3 can be marked as "don't care" because the machine room with a higher EB has better knowledge of the state of the virtual block. In another embodiment, as the train gradually passes through the block, a diversion is detected. Because both ends of the particular block are operating in LB mode and the system performs a health check, the entire physical track circuit can be disconnected from both perspectives. In another embodiment, even if the entire track section 802 is in a fault state, the train 104 can still continue to travel safely.

[0059] In one embodiment, for LB mode purposes, the PTC LB Hazard Status for the ET track of room #2 and the WT track of room #2 may be switched from "1" to "0" due to the shunting of the new track circuit 802 between rooms #2 and #3. For example, the PTC LB HAZ may be listed as "1------1" for room #1, "1------0" for room #2, and "0------1" for room #3, thereby indicating the shunting between rooms #2 and #3. The virtual blocks west of room #2 and east of room #3 remain normal, as shown by the west virtual block normal indicators 104a, 104b and the east virtual block normal indicators 105a, 105c, which each have a "check mark" above the VB with a heart icon. However, after detecting the diversion between machine rooms #2 and #3, the system can verify the VB normal status of the EB virtual block indicated by the east virtual block normal indication 105b and the west virtual block normal indication 104c, where there is a "question mark" with a heart icon above the VB. Therefore, the system can query and indicate the virtual block normal status indication for any number of machine rooms, track circuits, or virtual blocks.

[0060] refer to Figure 9 As the train continues westbound, it occupies a portion of track 204 and diverts the H2·D3 virtual block area. Engine room #1 can generate and maintain a virtual block (VB) value of "11111111" through the system, indicating that from its perspective, all virtual blocks are unoccupied; Engine room #2 can generate and maintain a virtual block (VB) value of "11110000" through the system, indicating that from its perspective, the EB virtual block is occupied; and Engine room #3 can generate and maintain a virtual block (VB) value of "00000000" through the system, indicating that from its perspective, all virtual blocks are occupied. In one embodiment, all virtual blocks remain normal, as shown by virtual block normal indications 104a-104c, 105a, and 105c, which each have a "check mark" above the VB with a heart icon. However, if the VB normal status of any virtual block in a particular engine room fails, the corresponding virtual block normal status indication can indicate the failure via a graphic, icon, or notification. For example, the virtual block normal indication 105 b may be an “exclamation mark,” “X,” or other suitable icons or graphics.

[0061] In one embodiment, since the system is in LB mode for the EB track in engine room #2, all virtual blocks in the WB track can be displayed as shunts (e.g., "11110000"). Specifically, the operating mode of the WB track in engine room #3 is set to VB mode, and the PTC LB Hazard Status can be switched back from "0" to "1." For example, the system can set the PTC LB HAZ to "1------0" to clear the shunt on the WT from the perspective of engine room #3. This can be an example of the system hiding states based on operating mode. In one embodiment, after completing the normal status check, the system can determine that the virtual block is abnormal from the perspective of engine room #2. In another embodiment, the system can discard the abnormal status and selectively maintain LB mode on engine room #2. In another embodiment, even if engine room #3 is in VB mode and the system stops the track circuit, train 104 can still proceed through these virtual blocks even if they are identified as abnormal. For example, the virtual block normal condition fault mode can be masked at the head end of train 104 to be irrelevant to the movement of train 104. However, it may be relevant to the rear end of train 104. In another embodiment, the rear end of train 104 may hold the entire physical block below for use by a second train behind it. This may simply cause the second train to slow down for a specific distance or duration (e.g., about a mile and a half). However, advantageously, when the virtual block status is abnormal, the system operates in LB mode rather than VB mode, while still ensuring continued movement of the train.

[0062] In one embodiment, because the system may be in VB mode from the perspective of room #3, the system may maintain the PTC LB HAZ WT for room #3 at a "high level" (e.g., "1------1") and rely on these states. For example, a safe state indicating occupied (e.g., "0") may be the safest for the virtual block. However, if the state is identified as unoccupied (e.g., "1") while in LB mode, the system may automatically check for a healthy state because the system will not transition it to VB mode even if the track circuit is occupied. In another embodiment, the system may mask one or the other state at any given time based on the condition. The system may determine the operating state as a granular issue or as a priority issue, where the system may recognize that train 104 is not in a particular virtual block and there is a negative healthy state indicator for one of the virtual sections, so the system may override the operating mode. For example, the system may operate in LB mode until the issue is resolved. In another embodiment, LB mode may help prioritize which of the two states needs to be exposed from a safety perspective.

[0063] In one embodiment, because train 104 is occupying a virtual block, even if the virtual block is down due to a normal issue, this is not a problem. Because train 104 is occupying the virtual block, if the system does not need to maintain the occupied state high, it will not do so. In another embodiment, the onboard computer may not distinguish between LB mode and VB mode. For example, the onboard computer may be primarily concerned with determining whether there are potential obstacles in the path of train 104 and whether these obstacles are safe. In another embodiment, the system can selectively mark certain virtual blocks as safe or unsafe at the trackside, ensuring that at any given time, at least one unmasked condition is present in our logic to ensure accurate and safe operation of the train.

[0064] Figure 10 A flowchart is shown that illustrates control logic 1000 for implementing a virtual block operational state control method including long block logic according to an exemplary embodiment of the present disclosure. The VB operational state control logic 1000 can be implemented as an algorithm, machine learning module, or other suitable system or combination thereof on a computer processor (e.g., a life logic controller, an onboard computer, a server). Furthermore, the VB operational state control logic 1000 can be implemented via software, hardware, an application programming interface (API), a network connection, a network transmission protocol, HTML, DHTML, JavaScript, JSON, Ruby, Rails, other suitable applications, or a suitable combination thereof. The VB operational state control logic 1000 (e.g., a computer processor) is capable of executing machine-readable instructions to perform program steps and is operably coupled to a memory having a first database containing a plurality of information, signal values, and specifications related to the vehicle and at least a portion of the track. These messages may include Onboard PTC LB Haz, PTC VB Haz, VB, PTC Auth, EC Rate, TX, RX, PTC LB Haz, or other suitable messages. The messages may include fields and data associated therewith.

[0065] The VB operating state control logic 1000 can leverage the capabilities of the computer platform to generate multiple processes and threads by processing data simultaneously. By instantiating multiple processes to facilitate virtual block operating state control, the speed and efficiency of the VB operating state control logic 1000 can be greatly improved. However, those skilled in the art of programming will recognize that a single processing thread can also be used and is within the scope of the present disclosure. The VB operating state control logic 1000 can also be distributed among multiple networked computer processors. The computer processors can be located in the trackside machine room 103 or on the train 104.

[0066] The VB operating state control logic 1000 process flow of this embodiment begins at step 1002, where the control logic 1000 may determine that the virtual block is normal and the system is in a quiescent state in long block mode. In one embodiment, the control logic 300 may be configured to receive data from sensors or other data collectors on and / or alongside the railway track. Instantiating the control logic 1000 in step 1002 may prepare the control logic 1000 to receive, process, and store the data. The control logic 1000 then proceeds to step 1004.

[0067] At step 1004, control logic 1000 may prioritize the authorization. For example, control logic 1000 may send a PTC authorization message to the relevant trackside machine room to ensure authorization to move along the track. In another embodiment, control logic 1000 may indicate the direction of travel. Control logic 1000 then proceeds to step 1006.

[0068] In step 1006, control logic 1500 may detect a shunt in the track circuit, assign a shunt value to a first virtual block (e.g., VB H3 (not shown)), and perform a virtual block health check. In one embodiment, control logic 1000 may determine a shunt based on an electrical signal transmitted along the track. In another embodiment, a shunt may be determined based on a measured resistance or signal reception time. In another embodiment, control logic 1500 may identify the location of the shunt in the first virtual block based on one or more measurements taken in a trackside machine room (e.g., machine room #3 103c). Control logic 1500 may assign a low-level status value (e.g., 0) to indicate that the virtual block is shunted and therefore occupied by a train or hazard. For example, the value of the relevant bit of the PTC VB Haz, PTC LB Haz, or VB message may be assigned by control logic 1000. In another embodiment, a shunt may be detected when a train occupies the monitored virtual block and an electrical signal transmitted on one track propagates along the train's axis and returns on a second track. In another embodiment, the control logic 1000 may determine the status of a virtual block monitored by the particular wayside machine room from the perspective of the virtual block. The control logic 1000 may also initiate a re-acquisition or calibration of the status of one or more virtual blocks. The control logic 1000 then proceeds to step 1008.

[0069] At step 1008 , the control logic 1000 may determine that the VB health check is good and after a predetermined period of time (eg, 10 seconds after train entry), the control logic 1000 may change to the VB operating mode. The control logic 1000 then proceeds to step 1010 .

[0070] At step 1010, control logic 1500 may assign a shunt value to a second virtual block (e.g., VB G3) of the first wayside machine room. In one embodiment, control logic 1500 may determine the shunt based on an electrical signal sent along the track. In another embodiment, the shunt may be determined based on a measured resistance or signal reception time. In another embodiment, control logic 1500 may identify the location of the shunt in the third virtual block based on one or more measurements taken by the wayside machine room (e.g., machine room #3 103c). Control logic 1500 may assign a low status value (e.g., 0) to indicate that the virtual block is shunted and therefore occupied by a train or hazard. For example, the bit values ​​of the PTC VB Haz, PTC LB Haz, or relevant bits of the VB message may be assigned by control logic 1000. Control logic 1000 may assign values ​​to status bits associated with a particular virtual block. For example, control logic 1000 may maintain PTC VB Haz at a high level (e.g., 1) by assigning a logic "1" value to the bit of the relevant virtual block. In one embodiment, when or after the train enters a particular virtual block, the control logic 1000 may assign a diversion value. The control logic 1000 then proceeds to step 1012 .

[0071] In step 1012, the control logic 1000 may determine that the train has diverted the third virtual block (e.g., VBF3). However, since the second virtual block (e.g., VB G3) is not visible from the perspective of the first wayside machine room, the PTC VB hazardous status bit value for the second virtual block may be triggered. From the perspective of machine room #3 103c, the diversion in the second virtual block is not visible to machine room #3 103c because the train is traveling west and the fourth virtual block diverts any signals transmitted west. In another embodiment, the bit values ​​of the relevant bits of the PTC VB Haz, PTC LB Haz, or VB messages may be assigned by the control logic 1000. The control logic 1000 may "stick" the bit value of a particular virtual block to a particular value regardless of its measured value. In one embodiment, the control logic 1000 may assign a value to the status bit associated with a particular virtual block. The control logic 1000 may maintain the PTC VB Haz message bit value at a high level (e.g., 1) by assigning a logic "1" value to the bits of the associated virtual block. For example, the control logic 100 may identify the PTC VB HAZ message as '-111101-' and maintain the PTC VB hazardous state bit value at a high level (up) for the second virtual block, even though it may be occupied by a train. The control logic 1000 then proceeds to step 1014.

[0072] At step 1014, control logic 1000 may assign a diversion value to the fourth virtual block (e.g., VB E3). In one embodiment, control logic 1000 may determine the diversion based on electrical signals transmitted along the track. In another embodiment, the diversion may be determined based on measured resistance or signal reception time. In another embodiment, control logic 1000 may identify the location of any diversion based on one or more measurements taken from the perspective of a trackside machine room (e.g., machine room #3 103c). Control logic 1500 may assign a low-level status value (e.g., 0) to indicate that the virtual block is diverted and therefore occupied by a train or hazard. For example, the value of the relevant bit of the PTC VB Haz, PTC LB Haz, or VB message may be assigned by control logic 1000. From the perspective of machine room #3 103c, machine room #3 103c cannot see the diversion in the third virtual block because the train is traveling west and the fourth virtual block diverts any signals transmitted eastward. The control logic 1000 can also "stick" the bit value of a particular virtual block to a specific value, regardless of its measured value. In one embodiment, the control logic 1000 can assign a value to a status bit associated with a particular virtual block. For example, the control logic 1000 can maintain the PTC VB Haz message bit value at a high level (e.g., 1) by assigning a logic "1" value to the bit of the associated virtual block. The control logic 1000 then proceeds to step 1016.

[0073] At step 1016, control logic 1000 may determine that the track circuit is in a static LB mode, shunting the track circuit between the first and second trackside machine rooms, and performing a second VB health check. In one embodiment, as train 104 continues westbound, it passes machine room #3 and occupies a portion of track 204, shunting the H2·D3 virtual block. Machine room #1 may generate and maintain a virtual block (VB) value of "11111111" through the system, indicating that from its perspective, all virtual blocks are unoccupied; machine room #2 may generate and maintain a virtual block (VB) value of "111111110" through control logic 1000, indicating that from its perspective, one of the virtual blocks is occupied; and machine room #3 may generate and maintain a virtual block (VB) value of "00000000" through the system, indicating that from its perspective, all virtual blocks are occupied. In one embodiment, when the train shuns on a section of track circuit 802 between machine rooms #2 and #3, the track circuit may be in a static LB mode. In another embodiment, upon detecting a virtual block shunting, a PTC authorization can be set in LB mode to indicate the occupancy of train 104 on the ET from the perspective of machine room #2. For example, control logic 1000 can set PTC LB HAZ to "1------0" to indicate a shunting on the ET from the perspective of machine room #2. In another embodiment, since track circuit 802 between machine rooms #2 and #3 is shunted, the VB normality of track circuit 802 is marked as unknown ('?' 105b and '?' 104c) and is again queried by control logic 1000. Control logic 1000 can then perform a virtual block normality check to determine whether the track circuit virtual block is normal and upgrade the operating state from LB mode to VB mode. In another embodiment, control logic 1000 can trigger a PTC hazardous state for F3 and G3. The PTC VB HAZ can be "-110011-," indicating that virtual block E3 of machine room #3 is shunted. Virtual blocks F3 and G3 in machine room #3 can be marked as unoccupied (e.g., "1"), while virtual block H3 in machine room #3 can be marked as "don't care" because the machine room with a higher EB has better knowledge of the state of the virtual block. In another embodiment, as the train gradually passes through the block, a diversion is detected. Because both ends of the particular block are operating in LB mode and the control logic 1000 can perform a normal status check, the entire physical track circuit can be disconnected from both perspectives. In another embodiment, even if the entire track section 802 is in a fault state, the train 104 can still continue to travel safely. The control logic 1000 then proceeds to step 1018.

[0074] In step 1018, the control logic 1500 may determine that the second trackside machine room has failed the VB normal status check and maintain the operating state in LB mode. In one embodiment, almost all virtual blocks are still normal, as shown by virtual block normal indications 104a-104c, 105a, and 105c, which have a "check mark" above the VB with a heart icon. However, if the VB normal status of any virtual block of a particular machine room fails, the corresponding virtual block normal status indication may indicate the failure through a graphic, icon, or notification. For example, the virtual block normal failure indication for the track direction (e.g., 105b) may display an "exclamation point," "X," or other suitable icon or graphic. The control logic 1000 then proceeds to step 1020.

[0075] In step 1020, control logic 1000 may determine that the second trackside machine room has failed the VB health check. Control logic 1000 may also maintain the LB mode operating state, maintaining the EB virtual block at a high level from the perspective of the second trackside machine room, and maintaining the ET at a low level from the perspective of the second trackside machine room. Control logic 1000 then proceeds to step 1022.

[0076] In step 1022, control logic 1000 may instruct the onboard computer to continue without restriction and with explicit instructions. When the train receives a second movement authorization to a second location, control logic 1000 may terminate or repeat the above steps.

[0077] The present disclosure achieves at least the following advantages: 1. Improve the capacity and safety of existing railway track infrastructure used by railways by determining whether virtual blocks are normal; 2. Long block mode can provide a coarse granularity of train existence, while virtual block mode can achieve a finer granularity, thus realizing the virtual aspects of sub-blocks; 3. Providing a long block mode, which provides the system with an opportunity to analyze potential trade-offs between granularity and reliability by determining which mode (virtual blocks or long blocks) is best to utilize in a specific situation; 4. Run in long block mode by default and ignore the virtual block feature until absolutely needed.

[0078] Those skilled in the art will readily appreciate that the above advantages and purposes would not be possible without the specific combination of computer hardware and other structural components and mechanisms assembled in the system of the present invention and described herein. In addition, the algorithms, methods, and processes disclosed herein improve and convert any general-purpose computer or processor disclosed in this specification and the accompanying drawings into a special-purpose computer that is programmed to execute the disclosed algorithms, methods, and processes to achieve the above functions, advantages, and goals. It should also be understood that for those skilled in the art, there are a variety of programming tools available for generating and implementing the functions and operations described above. In addition, the selection of a particular programming tool may be determined by the specific goals and constraints of implementing these concepts, which are selected to implement the concepts set forth herein and in the appended claims.

[0079] The descriptions in this patent document should not be construed as implying that any particular element, step, or function is essential or critical to be included within the scope of the claims. Furthermore, unless the precise words "means for" or "step for" are expressly used in a particular claim and followed by a participle phrase identifying the function, no claim is intended to invoke 35 U.S.C. §112(f) with respect to any additional claim or claim element. Terms used in the claims (such as, but not limited to, "mechanism," "module," "device," "unit," "component," "element," "member," "means," "machine," "system," "processor," "processing device," or "controller") should be understood and intended to refer to structures known to one skilled in the relevant art, as further modified or enhanced by the features of the claims themselves, and are not intended to invoke 35 U.S.C. §112(f). For example, the terms "processor" and "controller" may refer to a class of structures rather than a specific structure and may be defined in functional terms, but this does not necessarily mean that they are means-plus-function. Even under the broadest reasonable interpretation, in the absence of the specific language described above, the claims are not intended to invoke 35 U.S.C. §112(f) under this paragraph of the specification.

[0080] The present disclosure may be embodied in other specific forms without departing from its spirit or essential characteristics. For example, each new structure described herein may be modified to accommodate specific local changes or requirements while retaining their basic configuration or structural relationship to each other, or while performing the same or similar functions described herein. Therefore, the present embodiments should be considered in all respects to be illustrative and not restrictive. Therefore, the scope of the present disclosure may be determined by the appended claims rather than the above description. Therefore, all changes within the meaning and range of equivalence of the claims should be included in the claims. In addition, the various elements in the claims are not well-known, conventional or traditional. Instead, the claims are directed to the unconventional inventive concepts described in the specification.

Claims

1. A system for controlling the operating status of a virtual block, comprising: a memory having a first database containing operating conditions or specifications associated with a vehicle or at least a portion of a railroad track; as well as A processor operatively coupled to a memory and capable of executing machine-readable instructions to perform program steps comprising: Generate multiple virtual blocks within one physical block Generate long blocks within physical blocks; Run in long block mode until virtual block occupation is detected; Determine whether the first set of virtual blocks is normal from the perspective of the first trackside machine room; Operating in virtual block mode, when the first set of virtual blocks is normal, the occupancy status of each normal virtual block is identified from the perspective of the first trackside machine room; Operating in long block mode, when the first set of virtual blocks is abnormal, the occupancy of the long block is identified from the perspective of the first trackside machine room.

2. The system of claim 1, wherein the first set of virtual blocks is from an eastbound perspective of the first trackside machine room.

3. The system of claim 1 , wherein the program steps further comprise: Determine whether the second set of virtual blocks is normal from the perspective of the first trackside machine room.

4. The system of claim 3, wherein the second set of virtual blocks is from a westbound perspective of the first trackside machine room.

5. The system of claim 1 , wherein the program steps further comprise: Generate a virtual block normal status indication.

6. The system of claim 1 , wherein the program steps further comprise: A check is performed within a first period of time after detecting occupation of the virtual block to determine whether it is safe to maintain the virtual block mode. The system of claim 6 , wherein the first time period is a 10 second interval.

8. The system of claim 6, wherein when a virtual block becomes abnormal or its normal status is uncertain, operation in the virtual block mode may fail and enter the long block mode.

9. The system of claim 1, wherein the normal state of the virtual block is represented by a single bit.

10. The system of claim 1, wherein the physical block is a section of track between insulating joints.

11. A method for controlling the operating state of a virtual block, comprising: Generate multiple virtual blocks within the physical block through control logic; Generate long blocks within physical blocks through control logic; Run in long block mode until virtual block occupation is detected; Determine through control logic whether the first set of virtual blocks is normal from the perspective of the first trackside machine room; Operating in virtual block mode, when the first set of virtual blocks is normal, the occupancy status of each normal virtual block is identified from the perspective of the first trackside machine room; Operating in long block mode, when the first set of virtual blocks is abnormal, the occupancy of the long block is identified from the perspective of the first trackside machine room.

12. The method of claim 11, wherein the first set of virtual blocks is from an eastbound perspective of the first trackside machine room.

13. The method according to claim 11, further comprising: Determine whether the second set of virtual blocks is normal from the perspective of the first trackside machine room.

14. The method of claim 13, wherein the second set of virtual blocks is from a westbound perspective of the first trackside machine room.

15. The method according to claim 11, further comprising: Generate a virtual block normal status indication.

16. The method according to claim 11, further comprising: A check is performed by the control logic, within a first period of time after detecting occupation of the virtual block, to determine whether it is safe to maintain the virtual block mode. The method of claim 16 , wherein the first time period is a 10 second interval.

18. The method of claim 16, wherein when a virtual block becomes abnormal or its normal status is uncertain, operation in the virtual block mode may fail and enter the long block mode. The method according to claim 11 , wherein the normal state of the virtual block is represented by a single bit.

20. The method of claim 11, wherein the physical block is a section of track between insulating joints.

Images