Abstract
As the nationwide installation of positive train control (PTC) technology has recently been completed, freight railroads are searching for ways to leverage the technology to improve their operations beyond increasing safety. One commonly discussed possibility is developing and installing PTC-based virtual or moving block control systems to increase the capacity of railroad mainlines as a lower-cost alternative to adding costly track infrastructure. Considering that demand for freight rail transportation is expected to increase by 24% by 2045, and that most major mainline routes are operating at their maximum capacity, substantial capacity improvements will become necessary very soon. Since U.S. Class I railroads are for-profit companies, choosing the most cost-efficient way to increase network capacity is a primary objective. Thus, the potential capacity and performance benefits of virtual and moving block train control systems should be evaluated in realistic scenarios. This study utilized a novel dispatching algorithm and detailed railroad corridor simulator to evaluate fixed, virtual, and moving block systems over the full length of a 2,000-mi long U.S. Class I railroad mainline corridor composed of a mix of single- and double-tracks. Moving blocks were found to have the potential to maintain current average train speed under a 40% increase in train traffic, and that five virtual blocks per fixed block achieved most of the performance benefits of moving block control.
Keywords
By 2045, freight rail transportation demand in the United States is projected to increase by 24% from the 1.6 billion tons of freight shipped in 2019 ( 1 , 2 ). As U.S. Class I railroads are for-profit companies, they will continually work to match their network capacity to the ever-increasing freight rail demand. Recently installed positive train control (PTC) technology has given U.S. railroads an opportunity to develop virtual and moving block train control systems to handle more traffic without costly track infrastructure investment. Although the virtual coupling of closely following trains could potentially provide even greater benefits over moving block, it sacrifices some of the safety guarantees of a moving block system based on absolute braking distance ( 3 – 9 ). This is a major issue because the purpose of PTC is to increase the safety of train operations. Specifically, PTC is a technology designed to prevent train-to-train collisions, over-speed derailments, incursions into work zones, and the movement of trains through misaligned turnouts, as mandated by the Rail Safety Improvement Act of 2008 ( 10 ). This legislation also specifies several scenarios in which PTC must be implemented, including lines with scheduled passenger service, sufficient toxic inhalation hazard chemical traffic, and all rail lines with sufficiently high yearly tonnage. These criteria fortunately overlap substantially with the portions of the U.S. rail network that are most in need of capacity improvements.
Previous Research
PTC and advanced variations that have virtual and moving block functionality have been studied for several decades. Throughout its development, PTC has been described as having both safety and business benefits ( 11 ). Real-time train location information can improve train dispatching and rail traffic management decisions with the potential to increase system performance ( 12 ). Whereas some researchers have claimed that improved dispatching decisions will lead to increased capacity in an overlay application ( 13 ), others have claimed that any capacity benefits of a PTC overlay will be offset by the uncertainty in the train braking algorithm and the initialization time of the system ( 14 ).
Xishi et al. was one of the first to evaluate the capacity of moving block systems, finding that capacity could be increased by 20% to 30% compared with fixed block systems ( 15 ). However, they studied the Chinese railway system, which has a higher proportion of passenger trains and is much more scheduled than the U.S. freight rail system. Lee et al. evaluated moving block control for South Korean high-speed rail and found similar results ( 16 ). In Europe, the Institute of Transport Science RWTH Aachen conducted a study for the International Union of Railways to evaluate the capacity effects of the European Train Control System (ETCS) ( 17 ). Wendler also wrote a section in the Compendium on ERTMS, European Rail Traffic Management System, describing the effect of ETCS Level 3 (moving block) on rail line capacity ( 18 ). Mikulčić and Mlinarić ( 19 ) and Corman and Henken ( 20 ) thoroughly describe all the moving block research that came after this point
Recent studies on moving block have focused more on evaluating specific corridors. Van der Meulen developed a novel method to estimate moving block benefits that uses historic trajectory data from the existing fixed block control system, and used it to analyze various Dutch railway corridors ( 21 ). Dedik et al. analytically compared ETCS Level 3 with existing automatic blocks and lower levels of ETCS on a section of the Slovak railway network, finding that ETCS Level 3 has the substantial capacity benefit of handling double the number of trains ( 22 ). Qian et al. found that utilizing moving block increased the express passenger train capacity on the Qinghai-Tibet railway by 15% ( 23 ).
Although these results and methodologies are informative, the rail systems analyzed feature substantially different infrastructure and train operating patterns to the U.S. freight rail system, making it difficult to draw definitive inferences. Dick evaluated PTC and moving blocks in the context of U.S. freight rail, finding that benefits were largest for double track and that moving blocks could achieve a capacity increase of over 50% relative to fixed block systems in the absolute best-case scenarios ( 24 ). Moore Ede found a larger maximum benefit of decreasing headways by approximately 50%, and determined that even larger benefits are possible for trains that have much higher braking performance than the design train used to place the comparative wayside signals ( 25 , 26 ). Additionally, Moore Ede et al. evaluated the effect of implementing moving block systems on a single-track corridor, finding that a 25% increase in average train speed could be achieved compared with a fixed block centralized traffic control (CTC) system ( 27 ).
Importantly though, the fixed block systems evaluated in these papers are not entirely representative of current PTC-equipped fixed block systems, as the technology has changed substantially in the last two decades. Specifically, current fixed-block PTC systems provide cab signal functionality and enable the utilization of train-specific braking distances, reducing the incremental benefit of changing to a moving block system. Another limitation of this previous research is that it typically evaluates idealized moving block systems over short track segments.
PTC Research After Mandate
After the Rail Safety Improvement Act ( 10 ) of 2008 was passed, which mandated the installation of PTC systems on all major rail corridors in the United States, railroads and researchers focused on finding possible improvements not mandated by law that could be added to PTC systems for the economic benefit of the railroads. Dingler et al. evaluated the effects of moving block communications-based train control (CBTC) and electronically controlled pneumatic brakes on railroad capacity ( 14 ). They found that fully integrated CBTC systems have the potential to increase line capacity and that implementing a system that only satisfies the PTC mandate may reduce capacity.
Because moving block systems were far from commercial implementation on U.S. freight railroads, commercial railway simulation tools did not have the capability to simulate these systems. Thus, researchers utilized analytical capacity analysis or developed their own custom simulations. Within the past 5 years however, virtual and moving block development has progressed enough that existing commercial railway simulation tools have added the capability of simulating rudimentary versions of moving blocks.
With this new capability, researchers have begun using these commercial simulation tools to determine the potential capacity benefits of virtual and moving block systems. Dick et al. examined moving blocks across a variety of corridors from full single- to full double-track under a variety of traffic compositions, considering different proportions of high and low priority trains, as well as testing with and without a small number of passenger trains ( 28 ). A few different traffic volumes were also simulated. They found that moving block did increase capacity in all scenarios, though the largest effects were seen for corridors with a higher percentage of double track and a higher traffic volume. Diaz de Rivera et al. evaluated the effect of different operating procedures on the capacity of single-track corridors with moving block ( 29 , 30 ). Although previous research had shown that single-track corridors benefit the least from moving block, they developed a strategy to fleet shorter trains along the corridor, which would specifically take advantage of moving block functionality. They found that this new operating strategy only produced benefits when trains adhered to their schedule quite strictly. However, these benefits were also found to be no larger than the baseline effect of implementing moving block on the corridor.
In all this past research, the representative corridors evaluated were no longer than about 250 mi. However, virtual and moving block systems have the potential to fundamentally change train traffic flows by producing platoons of closely following trains ( 31 ). Thus, the often-arbitrary boundary conditions that are introduced when only simulating segments of larger mainline corridors should be avoided. For instance, to simulate a portion of a single-track corridor, it must be cut either at a single-track section or at a siding. If a single-track section is cut such that the facing turnout leg of the first unsimulated siding is touching the cut point, platoons of trains infeasibly large for the actual network in the unsimulated portion may arrive and depart. Cutting instead in the middle of a siding (leaving one turnout within the simulation and one outside it) is even worse, as the unsimulated portion effectively operates as double-track territory that can resolve conflicts between train platoons, which would actually create infeasible deadlock scenarios if operated across actual single tracks beyond the simulation boundary. These effects can be eliminated by simulating corridors that are sufficiently long for trains to depart and arrive at their origin and destination terminals within the simulation boundaries. This is especially critical for train platooning scenarios that arise under virtual and moving blocks due to the higher maximum train density.
Building on recent advances in automated train-dispatching logic ( 32 ), this research develops a full-length rail corridor simulator and uses it to make a novel comparison between the performance of fixed, virtual, and moving block control systems over a >2,000-mi long mixed single- and double-track U.S. freight rail corridor. Thus, this paper makes two important contributions: (1) it is the first known paper to compare virtual and moving block to fixed blocks in the North American freight operating context; and (2) it extends the analysis to full-length mainline corridors, removing the limitations of boundary conditions typically present in previous studies over short mainline segments.
The remainder of this paper is structured as follows. The second section introduces the novel corridor simulation methodology, including the input data, dispatching algorithm, train performance calculations, and overall simulator architecture and function. This section also introduces the key assumptions required to simulate the fixed, virtual, and moving block systems. The third section introduces the experimental design for a case study comparison of the control systems on an actual Class 1 mainline corridor. The fourth section presents the results of the case study simulations. The final section summarizes the case study conclusions, limitations of the study, and possibilities for future research.
Methodology
The simulation model developed in this research is composed of various input data plus three major modules: dispatching logic (with an internal train travel time estimator), an individual train simulator (that calculates train performance), and an event-based rail network simulator (that manages train occupancy and enforces sufficient train separation). This simulation model architecture is detailed in Figure 1. The following sections explain each of these model components.

Rail corridor simulation model architecture.
Input Data
The input data are composed of the topology and topography of the railroad corridor, the set of fixed signal aspects currently in use on the corridor, a set of virtual signal locations (unique to each virtual block scenario), and all planned train movements. Each planned train movement specifies the origin, destination, and all necessary train consist parameters (length, weight, max tractive power, max tractive effort, and train resistance parameters detailed below) to be used by the train performance calculator. These data will vary considerably depending on the corridor being evaluated and are explained in more detail in the section on experimental design.
Dispatching Algorithm
The simulation framework uses a deadlock avoidance heuristic-based train-dispatching algorithm to automatically route and schedule all trains planned to run over the network. The algorithm requires all trains to have a free (unobstructed) path from their current location to their destination at each valid intermediate step. A train traveling in the same direction as a free path is allowed and not considered an obstruction, but free paths may never pass through a train traveling in the opposite direction. Therefore, at all valid intermediate steps, a routing procedure can operate by advancing the train that has been waiting the longest until reaching a valid intermediate step, and by rewinding and advancing a different train if the first train advanced into a same-direction train before reaching a valid intermediate step. This procedure will always successfully route all trains through the network so long as the starting state is a valid intermediate step. The valid starting state used is where there are no trains on the network. Roscoe provides a complete description of this novel dispatching algorithm ( 32 ). The output from the dispatching algorithm is the order in which trains should pass each turnout and the planned path for each train across the rail corridor.
Individual Train Simulation
To accurately simulate train operations, a detailed and fast individual train simulator was developed. All forces acting on the simulated train were calculated at 1-s intervals, and train control actions were selected to minimize running time, subject to speed-limit profiles and train characteristics. Each train was modeled as a uniformly distributed mass “strap,” such that its total weight and curving characteristics were spread evenly over its length. Thus, grade and curve resistance could be calculated knowing only the track properties at the front and rear of the train. Speed and position were derived from the discrete time force calculation using total train mass and Euler integration. More complex integration schemes that involve analytical integration (e.g., Gaussian integration) would require numerical approximation of the grade and curve profiles, eliminating any major advantages ( 33 ).
For each train, five forces were calculated at each 1-s time step: rolling resistance, aerodynamic resistance, grade resistance, curve resistance, and maximum locomotive tractive effort at the rail. The maximum possible acceleration of the train at each time step was calculated with Equation 1,
where
Tractive effort plus each of the resistance terms has a more detailed expression. Starting with rolling resistance,
where
Aerodynamic resistance is calculated using Equation 3,
where
The
Grade resistance is calculated with the following equation:
where
The fractional term in the equation is the average gradient over the train length. Thus, as stated earlier, this equation assumes that train mass is evenly distributed along the length of the train.
To calculate curve resistance, coefficients for resistance versus degree of curvature and truck (bogie) type were taken from the Association of American Railroads’ train energy model ( 34 ). A quadratic least squares regression was used to determine coefficients for curve resistance as a function of degree of curvature. Unique coefficients were determined for each truck type. Linear combination was used to allow the train to have multiple truck types, but assumed that each type was uniformly distributed along the length of the train. Cumulative length and degree of curvature values were added to the rail corridor such that curve information at the front and back of the train were sufficient to calculate total curve resistance. The curve resistance equation in matrix form is,
where
A dot product is used to determine the final scalar value of curve resistance.
The equation for maximum locomotive tractive effort at the rail is
where
To simplify train control, acceleration was the only control variable and can be changed instantaneously to any value achievable by the train. The actual control algorithm is as follows:
• A train accelerates at its maximum rate until
○ It would exceed the current speed limit in the next time step:
▪ Acceleration is reduced to the value where the train perfectly matches the speed limit after the next time step
○ It is unable to sufficiently decelerate (using a rate of −0.18 mph/s) in time for an upcoming speed restriction (including those for stop signals):
▪ Equation 7 is used to calculate the acceleration value.
where
By triggering the train to decelerate whenever a deceleration of 0.18 mph/s would be insufficient, the actual train deceleration rate never exceeded 0.2 mph/s. This value is conservative and achievable by typical trains in real operations regardless of the actual track and train characteristics. Even on a steep downgrade, all trains obeying the speed limit with functional braking systems should be able to achieve this deceleration. These control algorithm simplifications were made to avoid the complexities of properly controlling fleets of trains with substantially different performance characteristics in moving block without substantially affecting the results for overall corridor performance.
Rail Corridor Simulator
The rail corridor simulation engine was at the core of the model, directing trains across the network using the dispatching algorithm results subject to the rail traffic control system being evaluated. The simulator also gathered the performance statistics of interest shown in the results section.
For both fixed block and virtual signals, the corridor simulator monitored the position and direction of all trains to determine whether each block was occupied or unoccupied. Based on the occupancy status of their protected blocks, fixed block and virtual signals were set to provide protection against following trains. Each time any train cleared any block (i.e., block became unoccupied after being occupied), the simulation engine updated the aspects of all connected fixed block and virtual signals. In contrast, the moving block system tracked the end of each train as a stop location, eliminating the need for signal aspects entirely.
For all traffic control systems, the simulator also tracked the movement authority from the dispatching logic result that was granted to each train at that time. Planned conflicting routes and not-yet-granted movement authority can cause the track ahead to effectively be occupied even though no train may be present. To handle these cases, the appropriate fixed block and virtual signals were set to stop and, for moving block simulation, a stop point was added at the end of each movement authority.
To monitor train occupancy, the front and rear locations for each train (distance offsets within each occupied block) were stored for each time step in an array. This representation corresponded to the information known by a moving block system operating synchronously with a time step interval of 1 s. For fixed and virtual block systems, all signals were checked along their active signal block at each time step. If any trains were present, the signal was set to its most restrictive aspect (i.e., stop or stop and proceed depending on the signal type). Otherwise, the signal was set using the aspect of the next signal using signal control line logic. The signal aspect and train occupancy data were used by the individual train simulator to maintain safe train operation.
The individual train simulator was run asynchronously for each train until its operation was restricted by the end of its movement authority to improve model running time. The end of movement authority may be located ahead of the train’s destination owing to train following or dispatching plan (i.e., train meet or pass conflicts) constraints. To ensure that this asynchronous simulation methodology matched the real-world synchronous system, the individual train simulator updated the occupancy of the train it was simulating through time in the global occupancy table whenever nearing the end of its movement authority, and scheduled itself to continue running after the restricting train was updated.
The following sections detail the specific modeling approach for each of the control systems. As an overview and comparison between these systems, Figure 2 shows the block layout, signal aspects, and theoretical minimum spacing of each train control system ( 28 ).
Fixed Block
In the simulation model, the fixed block control system utilized existing wayside signals included in the route data. A preprocessing algorithm was used to iteratively route through the network to define the fixed signal blocks and create the signal “control line” logic. Control line logic links the signal aspect displayed by one signal to that displayed by the next.

(a) Four-aspect fixed, (b) virtual blocks (N = 2), and (c) moving block train control system block spacing and theoretical minimum train spacing.
For this research, the simulation assumed that all existing wayside signals could display all possible aspects, except for those associated with restricting, stop and proceed, and stop. These three aspects were excluded because the appropriate aspect was selected based on signal type information available in the route data. For simplicity in control line logic, a four-aspect-based system with no repeated aspects was assumed to be in place over the entire corridor, regardless of signal spacing. The standard four-aspect sequences were defined by the signal rules of the corridor owner. For simplicity, a small number of signal aspects with very similar behavior were combined into one aspect.
Signals were integrated into the simulation calculations as speed restrictions with the speed limit, start location, and end location defined by the currently displayed aspect. Specifically, each signal aspect had specified “hold,”“immediate,” and “next” target speeds. For confidentiality, the specific aspect to speed mapping was not shown. A description of each signal speed type is as follows:
Hold speed is used when a train is taking the diverging route, ensuring that the train does not exceed the specified speed through all diverging turnouts following the specified signal. This speed is thus only applicable for diverging aspects.
Immediate speed is used to ensure that a train immediately starts slowing down to the specified speed on passing a signal. For example, the difference in speeds specified between the approach medium aspect (next speed of 40 mph) and the approach aspect (immediate speed of 30 mph) will result in a train beginning to slow to the immediate speed of the approach aspect as it passes.
Next speed and “nth next” signal parameters are used to specify the speed that the train must be traveling when passing the nth next signal. For example, this pair of parameters is used for the advance approach aspect, which requires that the passing train stops at the second signal. Since no aspects specify train behavior at multiple upcoming signals, this pair of parameters is sufficient to capture the logic for all aspects that define behavior at upcoming signal locations.
Virtual Block
The virtual block control system was constructed by altering the fixed block signal logic and subdividing the signal blocks. The signal logic was altered by,
(1) Simplifying the fixed block system to have only two aspects (restricting and clear);
(2) Changing part of the signal speed restriction code to have knowledge of all nearby signals (as is possible under PTC); and
(3) Ensuring that signal updates are immediately propagated to the train (as under cab signals and PTC).
To support the new logic, each of the existing signal blocks determined for the baseline fixed block system were split into

Examples of virtual signal placement on a fixed block signaled line: (a) fixed wayside signals, (b) virtual signals (N = 2), and (c) virtual signals (N = 5).
Moving Block
The moving block system enforced an absolute braking distance to the train ahead. An absolute braking distance approach requires that each following train can always brake to a stop before reaching the position occupied by its preceding train when braking begins. This differs from the relative braking distance approach used in “virtual coupling,” in which trains can follow at closer headways so long as they can brake to a stop before the location where the end of the preceding train would be if the preceding train decelerated at its maximum achievable rate ( 3 , 35 ). The relative braking distance approach is also used by roadway vehicle drivers. The absolute braking approach follows PTC requirements by providing sufficient train separation to prevent a collision in the case that a lead train derails or otherwise stops instantaneously. Since the single train simulator assumed that trains could always decelerate at 0.2 mph/s, the train control logic defined in part by Equation 7 ensured safe train separation according to absolute braking distances.
The moving block control system logic was constructed by ignoring the signal aspects and instead relying on the underlying train occupancy representation. The occupancy representation contained all train head and tail locations along the route at each time step. Since a time step of 1 s was used, moving block was simulated with a 1-s update interval.
Experimental Design
The detailed rail corridor simulation model was used to evaluate the performance of fixed, virtual, and moving block control systems on a >2,000-mi long mixed single- and double-track U.S. freight rail corridor. This corridor was analyzed under realistic traffic conditions with trains operating between many origin–destination pairs. Each control system was tested under several levels of projected traffic increases to evaluate the capability of each to manage future traffic growth. The simulated mainline corridor was approximately 2,000 mi long and was composed of single track with sidings except for two approximately 400-mi long sections of double track. The existing train traffic control system over the entire route was fixed block CTC.
Traffic Data
The first factor in the experimental design was the level of train traffic. For each scenario, operations were simulated based on actual train data from September 15 to October 14, 2017, but only the 21 days from September 18 to October 8 were used for analysis to allow time for simulation warmup and cooldown. The baseline traffic data derived from actual train operations in this timeframe were composed of 2,148 train starts. No intermediate planned train stops were explicitly included in this traffic, so none of the simulated train runs included planned intermediate stops. Because the existing fixed block corridor was already operating near its maximum capacity, the experimental design only included traffic volume increments from 100% to 160% of the baseline traffic volume. Preliminary simulations showed that average train speed dropped substantially for all control systems at the 160% of current volume scenario, indicating that the corridor was over capacity. To increase traffic volume in a realistic manner, a list of all trains sorted by scheduled origination time was created. To increase traffic volume by 10%, one out of every 10 trains was duplicated with its departure time offset by 12 h. For a 20% increase, two out of every 10 trains were duplicated. By this method, the added trains were evenly distributed over the 21 simulated days of train operations and randomly across the numerous origin–destination pairs.
Traffic Control System
The second factor in the experimental design was the traffic control system. Because a virtual block system can be implemented by dividing existing blocks into any arbitrary number (
FB: existing fixed block signal system,
VB1: existing fixed block signal system converted to virtual blocks (
VB2: two virtual blocks per existing fixed signal block (
VB5: five virtual blocks per existing fixed signal block (
VB10: 10 virtual blocks per existing fixed signal block (
MB: moving blocks.
Overall Design and Performance Metrics
The simulation scenarios in the experimental design included all combinations of the six control systems and seven traffic volumes (100% to 160% of current levels in 10% increments), for a total of 42 simulation scenarios. Note that the currently installed PTC systems in the United States operate as either FB or VB1 depending on whether the operating railroad has changed its rules to allow the complete use of train-specific braking distance (removing all signal speeds other than “stop” and “restricting”) and to allow PTC signal indications to be used as cab signals. For this research, the assumed baseline was FB. However, because the upgrade from FB to VB1 may be accomplished for the cost of issuing new rulebooks and a minimal amount of crew training, railroads may consider using VB1 as a secondary baseline for their cost–benefit analyses.
The key output metric from each simulation scenario was average train speed, which was used to compare performance across control systems for a given traffic volume. Average train speed was calculated by dividing the total train-miles accumulated on a mainline segment by the total train-hours operated over the same segment, excluding all time spent in yards and terminals. Average train speed was selected as the key performance metric for several reasons, the primary being that most U.S. Class I railroads view maximizing average train speed as highly important ( 36 ). Faster average train speeds help reduce the number of railcar and locomotive assets required to transport a given volume of freight. On a major Class 1 railroad, each 1 mph decrease in average train speed requires an additional 200 locomotives to transport the same volume of freight and increases operating expenses by over $200 million per year ( 37 , 38 ). Average train speed is also used as a proxy measure of network capacity. A widely used approach to determine North American railway line capacity is to define capacity as the maximum achievable train flow rate while maintaining a required level of service (LOS) performance ( 39 ). Establishing a minimum LOS defined by a maximum allowable train delay allows line capacity to be estimated from a delay-volume curve. Delay was defined as the difference between a particular train’s minimum free running time and its actual running time across a mainline segment. However, when examining historical performance, the minimum free running time for a train may not be available and can be difficult to calculate. In these situations, practitioners are likely to define mainline performance by average train speed. As mainline train delay increases, average train speed decreases. Thus, setting a minimum allowable average train speed allows line capacity to be estimated from speed-volume curves, such as those presented later in this paper.
Simulation Results
To assess and compare the performance of each control system, average train speed was plotted by traffic level and control system (Figure 4). Average speed dropped by approximately 5 mph when transitioning from the baseline (100%) traffic volume to a 160% traffic volume no matter the control system. Additionally, fixed block performed markedly worse than the other five control systems tested. However, the speed differentials were sufficiently small that it was difficult to make detailed comparisons between each of the other control systems.

Average train speed for various control systems at different relative traffic levels.
To make these speed differences more apparent, the incremental average speed benefit relative to fixed block for each of the other control systems was plotted (Figure 5). From this figure, the incremental benefit of switching to a more advanced control system was greater with higher traffic volume. Because higher traffic volumes require more meets and incentivize fleeting trains, it was expected that control systems such as moving and virtual block, which utilize higher block densities to enable following trains to run closer together, would show higher performance.

Incremental average train speed benefit relative to fixed block versus traffic level and control system.
It is important to note that the expected average speed benefits were not realized across-the-board in all simulations. The primary reason for this was that the train-level greedy heuristic used by dispatching logic will result in suboptimal decisions being made. In single-track territory, dispatching logic may choose to meet three trains at two sidings rather than at one. In double-track territory, the greedy heuristic may cause trains to continually alternate between main tracks to avoid all oncoming trains. Because of these issues, a moderately high level of variance was expected around all data points, even when averaging over full simulations.
In addition to overall average speed, daily average speed was recorded by the simulation model. The absolute average speeds and incremental average speed benefit, broken out by simulation day, were plotted versus control system for the 130% traffic volume scenarios (Figures 6 and 7).

Daily average train speed for various control systems at 130% baseline traffic.

Daily incremental average train speed benefit relative to fixed block for various control systems at 130% baseline traffic.
As might be expected from dispatching logic heuristic variability, the daily average speeds and speed benefits showed substantially more noise as compared to the average values in Figure 5. The data in Figure 5 for the 130% volume scenarios corresponded well to the expected behavior of the control systems, in which each upgrade from FB to VB1, VB2, VB5, VB10, and MB showed an incremental improvement. However, Figure 7 shows that even when the overall 21-day averages matched expectations, the daily average train speed benefits were inconsistent.
Another way to interpret this phenomenon is to consider that moving block and high-density virtual block control systems only handle trains substantially better on some portions of the corridor. As such, these control systems will push train platoons with higher densities forward into single-track bottlenecks, causing increased delays and lower average speeds on later simulation days while improving average speed on earlier days. However, Figure 6 does not show clear signs of this behavior, indicating that it occurs on timescales smaller than 1 day or that the primary underlying cause was simply variability in dispatching decisions. Overall, the daily train speed plots generally showed the expected trend of incremental benefits for each control system upgrade, though not as clearly as the overall average plots.
An alternative way to evaluate the performance benefit of these control systems would be to compare the average speed benefit of each individual train in the simulation. Unfortunately, these data were substantially noisier than those for the daily speed benefit, primarily because the dispatching logic did not contain any provisions for train prioritization. Thus, each control system would arbitrarily expedite and delay different trains. Figure 8 shows the cumulative distribution of incremental train average speed benefit on a train-by-train basis versus fixed block for each control system under the same 130% baseline traffic scenario. These data were created by examining each individual train (i.e., train number or “symbol”) within the full train plan, and subtracting its average speed under fixed blocks from its average speed under each advanced control system.

Cumulative distribution of incremental train-by-train average speed benefit over fixed block for each control system at 130% baseline traffic.
From Figure 8 it can be observed that, while most trains exhibited an average speed increase in the range of zero to 10 mph, a minority of trains experienced a decrease in average speed. These negative incremental average speed benefits occurred because the dispatching pattern resulting from adopting different control systems changed the particular number and location of train meet conflicts to the detriment of some trains (and to the large benefit of other trains in the right-hand tail of the cumulative distribution) even though the overall corridor performance improved. Although all tested virtual and moving block control systems provided an overall improvement over fixed block, the differences between each advanced control system were less pronounced. However, VB1 was generally the leftmost curve and MB was generally the rightmost curve, matching expectations for best and worst advanced control system.
Conclusions
On the corridor tested, implementation of moving blocks was found to increase average train speeds by approximately 2.5 mph or 6% relative to fixed blocks for the baseline (fall 2017) traffic volume. However, much of this same benefit could be realized by installing a virtual block system instead. For baseline traffic, virtual block systems with two and five virtual blocks per existing fixed block had comparable performance to moving blocks. However, at higher traffic volumes, the differences between the various control systems became more apparent. The benefits of moving and virtual blocks both increased as traffic volume increased and the corridor became more congested, approaching an increase in average train speed of 4 mph for moving blocks relative to the existing fixed block system at 160% baseline traffic. These incremental increases in train speed corresponded to capacity for long-term traffic growth. Although a 40% increase in traffic caused the existing fixed block system to experience a 3 mph decrease in average train speed, moving blocks could facilitate the same average train speed as the fixed block baseline traffic scenario at 140% baseline traffic. In this manner, moving blocks could be used to preserve existing performance under future traffic volume increases, providing an alternative to the infrastructure investments required to maintain train speed for an equivalent traffic increase under fixed blocks. On a day-to-day basis, variations in train count and type caused variations in average train speed, though the general trends of the scenario averages were matched.
For future research, there are several improvements that should be made to the model. Firstly, the dispatching algorithm should be tightly integrated with the railroad corridor simulator so that the estimated arrival times used by the dispatching logic more closely match the most accurate and up-to-date conditions on the corridor. The methodology used in this research of running the dispatching logic fully before simulating the rail corridor allowed for minor divergences in train performance to have large impacts specifically for long simulations. Severalsimulated train running times deviated from the dispatching logic predictions by about 45 min. Although this was small relative to the total simulation time of 21 days, it was consistent across all control systems and so was a straightforward way to improve the dispatching logic output in all situations. Secondly, the dispatching algorithm should be improved to enable running trains that reverse direction mid-route. These trains, though typically low priority and rarely the cause of mainline congestion, had to be excluded from the traffic data in this research. Lastly, intermediate work events (crew changes, setouts, pickups, etc.) should be added to the dispatching logic and the rail corridor simulation. Adding these work events will also allow train parameters to change mid-route, ensuring that the train performance characteristics are as accurate as possible over long corridors. Finally, this model made important simplifying assumptions about the ability of trains to follow at their minimum safe braking distance under moving blocks. Based on recent research examining the practicalities of the freight train throttle and brake control required to maintain these tight headways ( 40 ), slightly longer minimum headways may need to be enforced by the corridor simulation model.
With or without these improvements, there are several other topics to consider for future experiments: (1) evaluate the improvement in accuracy from simulating complete mainline corridors compared with simulating smaller portions and aggregating the results afterwards, (2) investigating scenarios in which individual segments of each corridor have different virtual block lengths based on performance and capacity requirements, (3) directly investigating the additional resiliency of moving and virtual blocks by simulating various operational disruption and recovery scenarios, (4) evaluating more corridors to determine the effects of network configuration, and (5) developing a complete parametric railroad mainline capacity model that includes virtual block and moving block control systems.
Footnotes
Acknowledgements
The authors thank an unnamed U.S. Class I railroad for sponsoring this research. The authors also thank Stan Chang, James Chan, Jiaxi Zhao, Daniel Holmes, Haolin Yang, Yanfang Ouyang, and Chris Barkan of the University of Illinois Urbana-Champaign, as well as Will Barbour and Dan Work of Vanderbilt University for their contributions to this research.
Author Contribution
The authors confirm contribution to the paper as follows: study conception and design: G. Roscoe, C. T. Dick; data collection: G. Roscoe; analysis and interpretation of results: G. Roscoe; draft manuscript preparation: G. Roscoe, C. T. Dick. All authors reviewed the results and approved the final version of the manuscript.
Declaration of Conflicting Interests
The authors declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
Funding
The authors received financial support from an unnamed U.S. Class I railroad for the research presented in this article. The authors received no financial support for the authorship and/or publication of this article.
