U.S.

Department of
Transportation Development of an Operationally Efficient
Federal Railroad PTC Braking Enforcement Algorithm for
Administration Freight Trains

Office of Research
and Development
Washington, DC 20590

DOT/FRA/ORD-13/34 Final Report

August 2013
 NOTICE
This document is disseminated under the sponsorship of the
Department of Transportation in the interest of information
exchange. The United States Government assumes no liability for
its contents or use thereof. Any opinions, findings and
conclusions, or recommendations expressed in this material do not
necessarily reflect the views or policies of the United States
Government, nor does mention of trade names, commercial
products, or organizations imply endorsement by the United States
Government. The United States Government assumes no liability
for the content or use of the material contained in this document.

NOTICE
The United States Government does not endorse products or
manufacturers. Trade or manufacturers’ names appear herein
solely because they are considered essential to the objective of this
report.
 REPORT DOCUMENTATION PAGE Form Approved
OMB No. 0704-0188
Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources,
gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this
collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson
Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188), Washington, DC 20503.

1. AGENCY USE ONLY (Leave blank) 2. REPORT DATE 3. REPORT TYPE AND DATES COVERED
August 2013 Technical Report
4. TITLE AND SUBTITLE 5. FUNDING NUMBERS
Development of an Operationally Efficient PTC Braking Enforcement Algorithm for Freight
Trains DTFR53-00-C-00012
6. AUTHOR(S) and FRA COTR Task Order 242
Joe Brosseau, Bill Moore Ede, Shad Pate, RB Wiley, and Joe Drapa
7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION
Transportation Technology Center, Inc. REPORT NUMBER
P.O. Box 11130
Pueblo, CO 81001
9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSORING/MONITORING
U.S. Department of Transportation AGENCY REPORT NUMBER
Federal Railroad Administration
Office of Railroad Policy and Development
DOT/FRA/ORD-13/34
Washington, DC 20590
11. SUPPLEMENTARY NOTES
COTR: Terry Tse, Jared Withers
12a. DISTRIBUTION/AVAILABILITY STATEMENT 12b. DISTRIBUTION CODE
This document is available to the public through the FRA Web site at http://www.fra.dot.gov.

13. ABSTRACT (Maximum 200 words)

Software algorithms used in positive train control (PTC) systems designed to predict freight train stopping distance and enforce a
penalty brake application have been shown to be overly conservative, which can lead to operational inefficiencies by interfering
with normal train operations. Federal Railroad Administration contracted Transportation Technology Center, Inc. to investigate
approaches to improve these algorithms and to reduce the associated operational inefficiencies. As part of this program, several
new approaches to PTC enforcement were introduced and were shown, through simulations and field testing, to improve the
operational efficiency of the algorithm. An appropriate safety objective for these algorithms was established from a fault-tree
analysis of the accidents PTC was conceived to prevent. A standard methodology was also established by which any PTC
enforcement algorithm can be evaluated against design safety and performance measures. This methodology involves a statistical
evaluation of the algorithm by means of a Monte Carlo simulation process, as well as limited, focused field testing, which
provides more confidence in the safety and performance of the software at less cost than traditional field testing methods. This
methodology was then used to evaluate PTC supplier algorithms that incorporate concepts introduced in this project.
14. SUBJECT TERMS 15. NUMBER OF PAGES
Braking algorithm, enforcement algorithm, positive train control, PTC, train control, simulation, 314
Monte Carlo simulation, adaptive enforcement algorithm, emergency brake backup 16. PRICE CODE

17. SECURITY CLASSIFICATION 18. SECURITY CLASSIFICATION 19. SECURITY CLASSIFICATION 20. LIMITATION OF ABSTRACT
OF REPORT OF THIS PAGE OF ABSTRACT
Unclassified Unclassified Unclassified
NSN 7540-01-280-5500 Standard Form 298 (Rev. 2-89)
Prescribed by ANSI Std. 239-18
298-102

i
 METRIC/ENGLISH CONVERSION FACTORS

ENGLISH TO METRIC METRIC TO ENGLISH

LENGTH (APPROXIMATE) LENGTH (APPROXIMATE)
1 inch (in) = 2.5 centimeters (cm) 1 millimeter (mm) = 0.04 inch (in)
1 foot (ft) = 30 centimeters (cm) 1 centimeter (cm) = 0.4 inch (in)
1 yard (yd) = 0.9 meter (m) 1 meter (m) = 3.3 feet (ft)
1 mile (mi) = 1.6 kilometers (km) 1 meter (m) = 1.1 yards (yd)
1 kilometer (km) = 0.6 mile (mi)

AREA (APPROXIMATE) AREA (APPROXIMATE)

2 2
1 square inch (sq in, in ) = 6.5 square centimeters (cm ) 1 square centimeter (cm2) = 0.16 square inch (sq in, in2)
2 2
1 square foot (sq ft, ft ) = 0.09 square meter (m ) 1 square meter (m2) = 1.2 square yards (sq yd, yd2)
2 2
1 square yard (sq yd, yd ) = 0.8 square meter (m ) 1 square kilometer (km2) = 0.4 square mile (sq mi, mi2)
2 2
1 square mile (sq mi, mi ) = 2.6 square kilometers (km ) 10,000 square meters (m2) = 1 hectare (ha) = 2.5 acres
1 acre = 0.4 hectare (he) = 4,000 square meters (m2)

MASS - WEIGHT (APPROXIMATE) MASS - WEIGHT (APPROXIMATE)

1 ounce (oz) = 28 grams (gm) 1 gram (gm) = 0.036 ounce (oz)
1 pound (lb) = 0.45 kilogram (kg) 1 kilogram (kg) = 2.2 pounds (lb)
1 short ton = 2,000 pounds = 0.9 tonne (t) 1 tonne (t) = 1,000 kilograms (kg)
(lb) = 1.1 short tons

VOLUME (APPROXIMATE) VOLUME (APPROXIMATE)

1 teaspoon (tsp) = 5 milliliters (ml) 1 milliliter (ml) = 0.03 fluid ounce (fl oz)
1 tablespoon (tbsp) = 15 milliliters (ml) 1 liter (l) = 2.1 pints (pt)
1 fluid ounce (fl oz) = 30 milliliters (ml) 1 liter (l) = 1.06 quarts (qt)
1 cup (c) = 0.24 liter (l) 1 liter (l) = 0.26 gallon (gal)
1 pint (pt) = 0.47 liter (l)
1 quart (qt) = 0.96 liter (l)
1 gallon (gal) = 3.8 liters (l)
1 cubic foot (cu ft, ft3) = 0.03 cubic meter (m3) 1 cubic meter (m3) = 36 cubic feet (cu ft, ft3)
1 cubic yard (cu yd, yd3) = 0.76 cubic meter (m3) 1 cubic meter (m3) = 1.3 cubic yards (cu yd, yd3)

TEMPERATURE (EXACT) TEMPERATURE (EXACT)

[(x-32)(5/9)] °F = y °C [(9/5) y + 32] °C = x °F

QUICK INCH - CENTIMETER LENGTH CONVERSION

0 1 2 3 4 5
Inches
Centimeters 0 1 2 3 4 5 6 7 8 9 10 11 12 13

QUICK FAHRENHEIT - CELSIUS TEMPERATURE CONVERSIO

°F -40° -22° -4° 14° 32° 50° 68° 86° 104° 122° 140° 158° 176° 194° 212°

°C -40° -30° -20° -10° 0° 10° 20° 30° 40° 50° 60° 70° 80° 90° 100°

For more exact and or other conversion factors, see NIST Miscellaneous Publication 286, Units of Weights and
Measures. Price $2.50 SD Catalog No. C13 10286 Updated 6/17/98

ii
Contents
Executive Summary ........................................................................................................................ 1
1. Introduction ................................................................................................................. 6
1.1 Background ................................................................................................................. 6
1.2 Objectives .................................................................................................................... 8
1.3 Overall Approach ........................................................................................................ 8
1.4 Scope ........................................................................................................................... 9
1.5 Organization of the Report ........................................................................................ 10
2. Development of Enforcement Algorithm Evaluation Tools and Methodology ....... 12
2.1 Overview of Enforcement Algorithm Evaluation Approach .................................... 12
2.2 Simulation Testing .................................................................................................... 13
2.3 Field Testing .............................................................................................................. 32
2.4 Analysis of Test Results ............................................................................................ 37
3. Analysis of Enforcement Algorithm Safety Objective.............................................. 41
3.1 Background and Implications of Enforcement Algorithm Safety Objective ............ 41
3.2 Analysis of Enforcement Algorithm Safety Objective.............................................. 41
3.3 Recommendation for Enforcement Algorithm Safety Objective .............................. 45
4. Base Braking Enforcement Algorithm ...................................................................... 47
4.1 Source and Development of Base Braking Enforcement Algorithm ........................ 47
4.2 Base Enforcement Algorithm Evaluation.................................................................. 48
4.3 Issues Identified with Base Enforcement Algorithm ................................................ 51
5. Revisions to Base Enforcement Algorithm ............................................................... 53
5.1 Addition of Train Types ............................................................................................ 53
5.2 Assumptions for Unknown Parameters ..................................................................... 54
5.3 Improved Target Offset Function .............................................................................. 58
5.4 Modeling of the Air Brake System............................................................................ 61
6. Adaptive Functions .................................................................................................... 63
6.1 Overview of Adaptive Functions .............................................................................. 63
6.2 Brake Pipe Propagation Time Adaptive Function ..................................................... 64
6.3 Brake Efficiency Adaptive Function ......................................................................... 66
6.4 Field Testing Adaptive Functions ............................................................................. 67
7. Emergency Brake Backup ......................................................................................... 69
7.1 Overview of Emergency Brake Backup Concept...................................................... 69
7.2 Implementation Considerations for Emergency Brake Backup Function ................. 70
7.3 Evaluation of Safety Considerations Regarding Use of Emergency Braking ........... 72
7.4 Development of Initial Emergency Brake Backup Function .................................... 75
7.5 Field Testing Emergency Brake Backup Function.................................................... 76
7.6 Development of Improved Emergency Brake Backup Function .............................. 77
8. Distributed Power ...................................................................................................... 79
8.1 Overview of Enforcement Algorithm Issues Associated with Distributed Power .... 79

iii
 8.2 Evaluation of Safety Considerations Regarding Distributed Power Communications
Failures ...................................................................................................................... 80
8.3 Development of Enforcement Algorithm Modifications for Trains with Distributed
Power......................................................................................................................... 82
8.4 Field Testing Distributed Power Function ................................................................ 84
9. Evaluation of Phase 1 Developmental Algorithm ..................................................... 86
10. Locomotive Braking .................................................................................................. 87
10.1 Background on Use of Locomotive Brakes during PTC Enforcement ..................... 87
10.2 Development of Methodology for Handling Use of Locomotive Brakes ................. 88
10.3 Field Testing Locomotive Brake Function ................................................................ 89
11. Dynamic Braking....................................................................................................... 91
11.1 Overview of Issue with Assumption on Use of Dynamic Braking During PTC
Enforcement .............................................................................................................. 91
11.2 Safety Considerations Regarding Dynamic Brake Failure........................................ 92
11.3 Development of Modifications for Handling Use of Dynamic Brake ...................... 94
11.4 Field Testing Dynamic Brake Function .................................................................... 96
12. Evaluation of Phase 2 Developmental Algorithm ..................................................... 99
13. Manifest Freight and Intermodal Freight ................................................................ 100
13.1 Assumptions for Unknown Parameters for Manifest Freight and Intermodal Freight
Equipment ............................................................................................................... 100
13.2 Development of Target Offset Functions for Manifest Freight and Intermodal Freight
................................................................................................................................. 102
13.3 Field Testing with Manifest Freight Equipment ..................................................... 103
14. Research on Available Locomotive Data and Interfaces ........................................ 105
14.1 Identification of Locomotive Data and Interfaces for Improved Enforcement
Algorithm ................................................................................................................ 105
14.2 Definition of Classes of Locomotives for PTC Enforcement Algorithms .............. 106
14.3 Field Testing to Verify Potential Tractive Effort and Dynamic Brake Data........... 108
14.4 Conclusions and Other Considerations Regarding Locomotive Tractive
Effort/Dynamic Brake Data .................................................................................... 113
15. Evaluation of Final Developmental Enforcement Algorithm ................................. 115
16. Evaluation of Wabtec Enforcement Algorithm ....................................................... 117
16.1 Development Support .............................................................................................. 117
16.2 Simulation Testing .................................................................................................. 118
16.3 Field Testing at TTC ............................................................................................... 119
17. Development and Testing of V-PTC Enforcement Algorithm................................ 123
17.1 Development and Simulation Test Support............................................................. 123
17.2 Field Testing at TTC ............................................................................................... 124
18. Conclusions ............................................................................................................. 127
19. References ............................................................................................................... 129

iv
Appendix A. Enforcement Algorithm Evaluation Methodology Document ............................. 131
Appendix B. Enforcement Algorithm Evaluation Process Overview and Communications
Interface Specification ................................................................................................................ 155
Appendix C. Simulation Test Matrix Details ............................................................................ 171
Appendix D. Distributions Used for Variable Parameters in Simulation Testing ..................... 200
Appendix E. Test Implementation Plans (TIP) and Test Logs for Field Tests .......................... 223
Appendix F. Developmental Enforcement Algorithm Definition Document ............................ 296
Appendix G. Detailed Simulation Results from Evaluation of Base Enforcement Algorithm . 348
Appendix H. Detailed Simulation Results from Evaluation of Phase 1 Developmental
Enforcement Algorithm .............................................................................................................. 432
Appendix I. Detailed Simulation Results from Evaluation of Phase 2 Developmental
Enforcement Algorithm .............................................................................................................. 490
Appendix J. Detailed Simulation Results from Evaluation of Phase 3 Developmental
Enforcement Algorithm .............................................................................................................. 548
Appendix K. Detailed Simulation Results from Evaluation of Wabtec Enforcement Algorithm
with Brake Force Provided ......................................................................................................... 676
Appendix L. Detailed Simulation Results from Evaluation of Wabtec Enforcement Algorithm
with Assumed Brake Force ......................................................................................................... 848
Abbreviations and Acronyms ................................................................................................... 1032

v
Illustrations
Figure 1. Illustration of Potential Difference between Predicted and Actual Freight
Train Stopping Location .............................................................................................. 7
Figure 2 Illustration of the Use of a Target Offset to Compensate for Uncertainty in
Stopping Distance Prediction ...................................................................................... 7
Figure 3. Organization of Simulations ...................................................................................... 14
Figure 4. Simulation Testing Components................................................................................ 15
Figure 5. Summary of Boundary Operating Conditions on Declining Grades ......................... 21
Figure 6. Fault Tree for Accidents from Authority Violations in CTC .................................... 42
Figure 7. Fault Tree for Accidents from Authority Violations with PTC ................................. 44
Figure 8. Base Enforcement Algorithm Target Offset Function............................................... 59
Figure 9. Emergency Brake Backup Concept ........................................................................... 70
Figure 10. Maximum Coupler Forces Resulting from Brake Applications ................................ 74
Figure 11. Comparison of Penalty Braking Distance with Head End Power and Distributed
Power for Loaded 135-car Unit Aluminum Coal Train on Flat Grade...................... 80
Figure 12. Comparison of Stopping Locations with Distributed Power
Communications Failure and Emergency Brake Backup .......................................... 81
Figure 13. Comparison of Stopping Profiles for Normal Braking with Use of Dynamic
Brake and Penalty Braking without Use of Dynamic Brake ..................................... 92
Figure 14. Comparison of Stopping Locations with Dynamic Brake Failure and
Emergency Brake Backup ......................................................................................... 93
Figure 15. Example Dynamic Brake Curve for AC Locomotive................................................ 95
Figure 16. Example Dynamic Brake Curve for DC Locomotive................................................ 96
Figure 17. Comparison of Instrumented Coupler and Computed Tractive Effort Data
for FAST Train over One Hour of Operation .......................................................... 110
Figure 18. Comparison of Instrumented Coupler and Computed Tractive Effort Data
for FAST Train over One Lap of the HTL .............................................................. 111
Figure 19. Comparison of Instrumented Coupler and Computed Tractive Effort Data for
UP3886 (EMD SD70M) .......................................................................................... 112
Figure 20. Comparison of Instrumented Coupler and Computed Tractive Effort Data for
CSX4762 (EMD SD70MAC) .................................................................................. 113

vi
Tables
Table 1. Train Consist Parameters for Simulation Testing...................................................... 19
Table 2. Speed/Grade Configurations for Simulation Testing ................................................ 22
Table 3. Train and Environmental Parameters that can Affect Freight Train
Stopping Distance ...................................................................................................... 23
Table 4. Car Parameters that can Affect Freight Train Stopping Distance ............................. 24
Table 5. Stopping Distance Test Comparison Results ............................................................. 34
Table 6. Stopping Distance Repeatability Test Results ........................................................... 36
Table 7. Symbols used in Fault Tree Analysis ........................................................................ 42
Table 8. Probability and Years between Accidents from Authority Violations ...................... 45
Table 9. Tolerable Hazard Rate for Various SIL ..................................................................... 45
Table 10. Base Enforcement Algorithm Simulation Test Results ............................................. 48
Table 11. Base Enforcement Algorithm Field Test Results ...................................................... 49
Table 12. Additional Base Enforcement Algorithm Field Test Results .................................... 50
Table 13. Revised Nominal Car Brake Force for Unit Trains ................................................... 57
Table 14. Adaptive Function Field Test Results........................................................................ 68
Table 15. Emergency Brake Backup Function Field Test Results ............................................ 77
Table 16. Simulation Tests to Determine Effect of Number of Locomotive
Consists on Brake Pipe Propagation Time ................................................................ 82
Table 17. Simulation Tests to Determine Effect of the Location of Locomotive
Consists, within the Train, on Brake Pipe Propagation Time.................................... 83
Table 18. Distributed Power Function Field Test Results ......................................................... 85
Table 19. Phase 1 Algorithm Simulation Test Results .............................................................. 86
Table 20. Locomotive Brake Function Field Test Results ........................................................ 90
Table 21. Dynamic Brake Function Field Test Results ............................................................. 97
Table 22. Dynamic Brake Function with Simulated DB Failure Field Test Results ................. 98
Table 23. Phase 2 Algorithm Simulation Test Results .............................................................. 99
Table 24. Revised Nominal Car Brake Force for Unit Trains ................................................. 101
Table 25. Manifest Freight Field Test Results ......................................................................... 104
Table 26. Data Elements/Interfaces Affected by Locomotive Characteristics ........................ 107
Table 27. Locomotive Data Test Scenarios ............................................................................. 109
Table 28. Phase 3 Algorithm Simulation Test Results ............................................................ 115
Table 29. Wabtec Algorithm Simulation Test Results (Brake Force Provided) ..................... 118

vii
Table 30. Wabtec Algorithm Simulation Test Results (Brake Force Not Provided) .............. 119
Table 31. Field Test Summary of Wabtec Algorithm with Unit Freight Train ....................... 120
Table 32. Field Test Summary of Wabtec Algorithm with Manifest Freight Train ................ 121
Table 33. Field Test Summary of LMC V-PTC Algorithm .................................................... 125

viii
Executive Summary
Predictive enforcement of authority limits and other stop targets by means of a penalty air brake
application is the means by which Positive Train Control (PTC) systems achieve enhanced safety
of the railroad operation. Predictive penalty brake enforcement is conceived as the final
opportunity to stop the train safely in situations where the train crew has failed to act to do so.
Software algorithms designed to predict the stopping distance of freight trains and enforce a
penalty application have been tested in freight service in early pilot and production PTC systems
and shown to be overly conservative to ensure the train will stop short of the given target;
however, they have led to operational inefficiencies by enforcing trains to a stop unnecessarily
interfering with the normal operation of the train, which can lead to reduced line capacity. To
investigate approaches to improve PTC enforcement algorithms and to reduce the associated
operational inefficiencies, the Federal Railroad Administration (FRA) contracted Transportation
Technology Center, Inc. (TTCI) to identify, develop, simulate, and test concepts and methods for
improving the accuracy of the stopping distance prediction and improving the operational
performance of the system.
Through this program, several significant accomplishments have been achieved. First, several
new approaches to PTC penalty enforcement have been demonstrated to be useful in improving
the operational efficiency of the enforcement algorithm. These concepts are already beginning to
be employed by railroads and suppliers in PTC system designs and implementations, proving
their worth in a very short time.
Second, a standard methodology was established by which any PTC enforcement algorithm can
be evaluated to demonstrate that it meets certain design objectives, such as safety and
performance measures. This methodology makes use of Monte Carlo simulation techniques to
statistically evaluate the performance characteristics of the enforcement algorithm coupled with
small samples of field testing used to validate the results achieved from the simulation modeling
process. This methodology is now being used to verify the performance of production-level
enforcement algorithms within the industry, to provide better safety and performance data for the
system with reduced time and costs associated with the lengthy field testing processes that have
traditionally been required.
The methodology developed under this program makes use of the Train Operations and Energy
Simulator (TOESTM), originally developed by the Association of American Railroads (AAR).
The TOES model is a validated industry-standard software application used for performing a
wide range of modeling exercises associated with train-level dynamics. The detailed fluid-
dynamics model of the brake system and the flexibility for modeling any train and car type over
any track profile make it an ideal tool for evaluating predictive braking routines. In the
simulation test methodology, the model is used to perform PTC brake enforcement tests on a
large scale for a broad range of operating scenarios. Each operating scenario is simulated
multiple times, whereas parameters that affect the train stopping distance are varied according to
distributions representing their actual, real-world variability in a Monte Carlo method. This
allows for evaluation of the full range of potential outcomes from a PTC penalty enforcement in
each of the operating scenarios tested, providing a complete statistical view of the safety and
performance characteristics of the algorithm.
The research and development of improved techniques for PTC enforcement algorithms was
divided into three phases of development, as guided by an industry advisory group made up of

1
representatives from four U.S. Class I railroads: Burlington Northern and Santa Fe Railway
Company (BNSF), CSX, Norfolk Southern Corporation (NS), and Union Pacific Railroad
(UPRR). The intent of the phased approach was to release the concepts and methods to the
industry in a more timely fashion, as opposed to waiting until all of the research was complete.
In the first phase, the highest priority concepts were addressed, including an evaluation of the
safety objective of the PTC enforcement function, investigating the issues with legacy
enforcement algorithms, and developing the functions with the most potential for improvement
of algorithm performance.
The primary purpose of reviewing the safety requirement of the PTC enforcement function was
to analyze its impacts on the overall safety and performance of the operation and to recommend a
revised requirement that meets the need of the safety requirement while, at the same time, not
adversely affecting operational performance unduly. The research used data available from the
railroads and FRA to perform a fault tree analysis relating to PTC-preventable authority
violations and the mechanisms in place to protect against them. It was shown, through this
analysis, that a safety objective of stopping a given train short of a given stop target 99.5 percent
of the time would result in a significant improvement over the train control system in place
today, and provide a substantial level of safety in terms of years between PTC-preventable
accidents.
Through investigation of a legacy enforcement algorithm, specifically the algorithm used in the
North American Joint Positive Train Control (NAJPTC) project, a number of improvements
were identified. These included modifications to the logic within the enforcement algorithm,
changes to some of the assumptions, and mostly notably, the development of an improved target
offset function. The target offset function is used to provide a cushion to ensure the appropriate
level of confidence in the stopping distance prediction. Thus, the stopping prediction is offset
from the target by a distance calculated from the characteristics of the situation. In the case of
the improved target offset function developed under this program, these characteristics include
train makeup, track grade, and train speed. A multiple-variable regression analysis was
performed using the results of hundreds of thousands of stopping distance simulations to develop
functions for computing the target offset necessary for any operating scenario. The techniques
established in this project made it possible to generate a target offset function that is no more
conservative than the stated safety objectives, which can, and was shown to, have a significant
impact on the operational performance of the enforcement algorithm.
The functions identified by the industry advisory group to include in the first phase of algorithm
development were adaptive, emergency brake backup, and distributed power functions. In the
case of the adaptive functions, a previous project, undertaken by TTCI for the FRA, had
investigated and proved the concept. In this project, further refinement to improve the accuracy,
as well as modifications needed to cover the full range of operating conditions were incorporated
to complete the functions [1]. Two primary adaptive functions were developed and incorporated
into a base algorithm in this project. In the first, the propagation time of the train is measured
and the algorithm adapted accordingly. In the second, the braking efficiency of the train is
measured and used in the stopping distance prediction within the algorithm. These two functions
reduced the uncertainty of some variables affecting braking distance. Thus, the use of the
adaptive functions provides a more accurate stopping distance prediction, which reduces the
potential variability in stopping distance, allowing for a less conservative algorithm. This ability

2
was demonstrated through field testing of the algorithm with the adaptive functions incorporated
and compared against the base enforcement algorithm.
The emergency brake backup function concept is to monitor the stopping of the train following
the initial PTC penalty application and apply the emergency brake if the initial PTC penalty is
not sufficient for stopping the train short of the target. This improves the safety of the system by
providing an additional means for providing more brake force if there is any fault in the initial
penalty stopping distance prediction. It also allows for the algorithm to be less conservative,
because the worst-case trains will be handled by the emergency brake backup function. This
concept was developed and tested to demonstrate that it can be implemented in such a way that
the emergency is only utilized when it is necessary to do so, without applying the emergency
when it is not. Analysis of the in-train forces associated with using the emergency as a backup to
the primary penalty enforcement showed no increased risk or safety concerns with use of
emergency braking. A discussion on potential implementation concerns is also included in the
main body of the report.
The distributed power function is designed to make use of the improved brake pipe propagation
time that comes with operating a train with distributed power. Previous algorithms did not
consider this reduced propagation time, resulting in overly conservative stopping distance
predictions for these train types. This function was shown through field testing to result in far
better stopping distance predictions for these trains, resulting in better performance. The key to
implementing this function is in providing a safe way to handle the potential, albeit rare,
situation where the communications link to the remote locomotives fails at the time of the PTC
penalty enforcement. The analysis presented in this report shows that the emergency brake
backup function can be used to mitigate this risk, because the emergency applied from the head
end only will stop the train faster than the penalty applied from both ends, in all cases.
In the second phase of development, two additional functions were investigated. The first is a
function to use the effect of locomotive engineer applied dynamic braking during PTC penalty
enforcement to predict the stopping point. Since dynamic braking is used in many cases to
control the speed of the train and will continue to be applied following a PTC penalty
application, not including the effects of dynamic braking in the stopping distance prediction can
result in excessively long stopping distance predictions, forcing the train crew to apply the air
brakes in scenarios they may otherwise not, and potentially resulting in unnecessary service
interruptions. The risk of the dynamic brake failing, or being disengaged by the train crew, can
be handled effectively by the emergency brake backup function. Field testing of this function
showed considerable improvement over the base algorithm for cases where dynamic brakes are
exclusively used to control the speed of the train on down grades.
The second function developed and tested in the second phase of development relates to the use
of locomotive air brakes during PTC enforcement. Traditionally, enforcement algorithms have
assumed that the automatic application of the locomotive brakes during a PTC penalty
enforcement will be bailed off by the train crew, in accordance with typical operating
procedures. In the case of very short trains and light engines, it is traditionally assumed that the
locomotive brakes will not be bailed, to prevent excessive stopping distance predictions in these
cases. This presents a potential risk, in the case the locomotive brakes are bailed and the
locomotive independent brake is reapplied to a lesser extent to stop the train. Although this is
considered to be a low-risk scenario, because the locomotive engineer has the tools to stop these
trains very quickly if necessary (independent, dynamic, emergency brake), a method for

3
eliminating this risk was nevertheless considered. The method involves modifying the brake
system to prevent a full bail of the automatic application on the locomotives, ensuring some level
of braking in these cases. This has the advantage of preventing excessive stopping distance
predictions with the assumption of a full bail, but also prevents the train crew from inadvertently
causing a target overrun by bailing. Although this function was shown to have potential, the
additional costs associated with the modifications to the locomotive combined with the relative
low risk of the scenario it is designed to prevent may eliminate it from further consideration.
The third phase of development involved expanding the concepts and functions investigated in
the first two phases of development to function on additional train types and locomotives.
Specifically, modifications to the algorithm logic, assumptions, and target offset functions were
designed and implemented for manifest freight and intermodal freight train types. The functions
developed in the previous research phases were tested on these types of equipment to
demonstrate their potential to satisfy the safety and performance objectives. An investigation of
the data and interfaces available to the enforcement algorithm component of the PTC onboard
system were also investigated, and a summary of this analysis is presented within the report.
The final version of the developmental enforcement algorithm produced in this project was
evaluated using the established simulation test methodology. Overall, the algorithm was shown
to have a probability of stopping short of the target of 98.91 percent, which fell just short of the
safety objective of 99.5 percent. TTCI knows where the area of improvements need to be and
has fixes for these areas that will be implemented and tested as part of the follow on work.
However, the probability of stopping excessively short (> 500 ft for speeds < 30 mph, > 1,200 ft
for speeds ≥ 30 mph) was reduced to 8.24 percent from a probability of 75.06 percent
demonstrated for the base algorithm. This shows the significant reduction in the impact on the
operational performance of the system than can be achieved through the use of the techniques
developed in this project.
A final component of the project involved working with the railroads on the advisory group and
their PTC onboard system supplier, Wabtec Railway Electronics (Wabtec), to support Wabtec’s
implementation of some of the concepts developed and evaluate their proprietary enforcement
using the methodology developed in this project. In addition to implementing some of the
concepts investigated in this project, Wabtec also worked with BNSF Railway to implement a
process whereby the braking force assumed by the algorithm is improved through a calculation
preformed in the back office server that is provided to the onboard enforcement algorithm
software.
The Wabtec algorithm was tested both with the brake force provided through this process, as
well as without. With the brake force provided from the back office server process, the Wabtec
algorithm was shown to have a probability of stopping short of the target of 99.03 percent and a
probability of stopping excessively short (as defined above) of 32.31 percent. Without the brake
force provided, the algorithm was shown to have a probability of stopping short of the target of
99.66 percent and a probability of stopping excessively short of 40.27 percent. These numbers
show considerable improvement over the base algorithm, clearly demonstrating the effectiveness
of the improvements made by Wabtec to the current algorithm. It should be noted that these
performance numbers for the Wabtec algorithm do not represent the final state as development
will continue to achieve the required 99.5 percent probability of stopping short of the target.

4
This project effectively showed that it is possible to develop a safe braking enforcement
algorithm for PTC systems, without being so conservative as to interfere with the normal
operation of the railroad. Although it will take years of operation with these improved
algorithms to empirically prove their effectiveness, the simulation and field testing results
presented within provide a very strong case that they indeed will. As the industry continues to
resolve issues associated with the implementation of PTC on a large scale, and as older cars with
poorer braking performance are replaced with newer, it may be relevant to continue to evolve the
braking enforcement algorithm over time, to continue to reduce the negative operational impact
and realize the full benefits of the PTC system.

5
1. Introduction
A critical task for the railroad industry in the effort to implement PTC technology on a large
scale is the development of a braking enforcement algorithm that enables the system to achieve
the stated safety objectives, while maintaining the efficiency of the current freight railroad
operation. Research and testing of prototype PTC systems designed for use on North American
freight railroads has demonstrated the difficulty these systems face in meeting safety objectives
without negatively impacting railroad operation. Additionally, no practical, reliable method has
yet been established to demonstrate the safety and performance characteristics of the braking
enforcement function of these systems. In order to address these issues, FRA funded a research
project aimed at improving PTC braking enforcement algorithm performance and developing a
practical methodology to demonstrate it. TTCI was contracted to perform the research and
conduct the testing activities associated with the project.

1.1 Background
PTC is a form of communications-based train control (CBTC) intended to improve the safety of
the railroad operation through the enforcement of movement authority limits, civil and temporary
speed limits, work zone limits, and by preventing train movement through a switch left in the
wrong position. In a PTC system, movement authority and speed limit information is transmitted
digitally to a locomotive onboard computer. The locomotive onboard computer is capable of
accurately determining the speed and location of the train in real time; it also contains a braking
enforcement algorithm, which predicts the stopping distance of the train and enforces limits by
automatically initiating a penalty brake application to prevent a violation. Braking enforcement
is considered the final opportunity to safely prevent a violation when the locomotive crew has
failed to do so.
The braking enforcement function of the system is critical to ensuring that trains comply with
movement authorities and speed limits. A number of parameters can affect the braking distance
of a freight train and it is not practical, or even possible, to provide the onboard system with all
the information required to predict the stopping distance with absolute certainty. Many of the
necessary data elements are not provided to the onboard system, and there is a level of
uncertainty in those that are. Thus, there can be a significant difference between the stopping
distance predicted by the braking enforcement algorithm and the actual stopping distance of a
given train. This difference can be described by a statistical distribution of potential stopping
locations about the predicted stopping location, as Figure 1 illustrates.

6
 Figure 1. Illustration of Potential Difference between Predicted and
Actual Freight Train Stopping Location

The braking enforcement algorithm must compensate for these unknowns and uncertainties so
that it can safely stop the train short of a given target location with a specified statistical
probability and confidence. Typically, this is achieved by offsetting the predicted stopping
distance by some margin, related to the level of uncertainty in the stopping distance prediction.
This uncertainty is in turn related to the level of uncertainty in the data provided and the
characteristics of the scenario (e.g., train speed at the initiation of enforcement). This offset is
typically referred to as the target offset, or safety offset. Figure 2 illustrates the target offset
concept.

Figure 2. Illustration of the Use of a Target Offset to Compensate for

Uncertainty in Stopping Distance Prediction

Braking enforcement algorithms using this target offset concept have been shown to be
successful in stopping trains short of the target location as designed, but the conservative nature
of these algorithms can, and has been shown to, lead to operational inefficiencies. The target
offset for these algorithms can be significant, so much so that the braking enforcement algorithm
will issue warnings of impending penalty brake applications in advance of where the locomotive
engineer would normally start applying the brakes in accordance with standard operating
practices, and in some cases the algorithm forces the train to a stop unnecessarily, Which in turn
forces the train crews to operate trains in an operationally inefficient manner.
These large target offsets can be attributed to a variety of factors. First, the width of the
distribution of potential stopping locations can be significant, because of the number of
parameters affecting the stopping distance and the uncertainty of each. Second, the methods and

7
assumptions typically used for PTC braking enforcement are limited and not typical of normal
train crew operating practices. Finally, a statistically significant amount of braking enforcement
data is not practically available for the breadth of possible scenarios to precisely meet the safety
requirements without significant conservatism.
A previous research effort addressed the first factor by investigating methods to reduce the
uncertainty of some of the key parameters in predicting train stopping distance; the methods
included measuring brake performance characteristics on the actual train and adapting the
algorithm to the specific measured characteristics [1]. This research effort expanded on that
concept by addressing all of the factors that contribute to excessive target offsets, as well as other
contributors to inefficiencies in the braking enforcement function of the PTC system.

1.2 Objectives
The primary objective of the project was to identify, develop, simulate, and test methods to
improve predictive braking enforcement algorithms for freight trains in a PTC system design.
Other components of this main objective were to (1) identify and document appropriate safety
and performance objectives for the braking enforcement function, (2) develop a practical
methodology for statistically demonstrating the safety and performance characteristics of a
braking enforcement algorithm, and (3) work with PTC system suppliers to implement the
concepts developed and evaluate the performance of the resulting braking enforcement algorithm
using the established methodology.

1.3 Overall Approach

The following research focus areas were identified as having the potential to improve both the
safety and operational efficiency of the enforcement algorithm:
• A safety objective for the enforcement function of the system that offers a high level of
safety, without being unduly restrictive;
• A target offset function related to the statistical variance of freight train stopping distance
for the range of potential operational scenarios;
• Adaptive functions that measure the braking performance characteristics of the train and
adapt the algorithm to these characteristics to improve the prediction;
• Use of emergency braking as a backup for cases where the penalty brake is insufficient
for stopping the train short of a target location;
• Methodology for improving the prediction with trains using distributed power;
• Methodology for including dynamic brakes already in use in the stopping distance
prediction; and
• Use of locomotive brakes during PTC braking enforcement to improve safety with short
trains and light locomotives.
The project was organized into three research and development phases, with the objective of
releasing concepts and methods to the industry in a more timely fashion. Within each project
phase, several new methods were researched and incorporated into a developmental braking
enforcement algorithm software test application. Each of these methods was then tested, using a

8
combination of simulation and field testing, to demonstrate the potential safety and performance
benefits. The complete developmental braking enforcement algorithm logic was then
documented and provided to railroads and PTC system suppliers.
The algorithm development was supported by an industry advisory group, which helped to
organize the potential new methods into the appropriate phases of development. The major tasks
associated with each phase of development are outlined below:
• Phase 1
▬ Develop approach/methodology for evaluation of PTC braking enforcement
algorithms.
▬ Research appropriate safety objective for braking enforcement function.
▬ Evaluate base enforcement algorithm.
▬ Refine assumptions and logic in base enforcement algorithm, including revised target
offset function related to statistical regression of simulation tests.
▬ Refine adaptive methods developed in the previous research effort.
▬ Develop emergency brake backup functionality and research on safety considerations
regarding use of emergency braking.
▬ Modify algorithm to handle trains operating with distributed power.
• Phase 2
▬ Modify algorithm prediction logic to include estimation of dynamic brake force in
use.
▬ Research and develop use of locomotive automatic and independent brakes.
• Phase 3
▬ Modify algorithm assumptions and target offset function for manifest freight
equipment.
▬ Modify algorithm assumptions and target offset function for intermodal equipment.
▬ Research data and interfaces available on various types of locomotives.
In addition to the research and development tasks listed above, the project also included
evaluation of PTC supplier algorithms with the objective of demonstrating the safety and
performance characteristics to support necessary additional development and provide data to
support documentation of the safety case for the PTC system.

1.4 Scope
This document describes the research, development, and test efforts conducted as part of the
subject project. Documentation of the enforcement algorithm evaluation methodology and the
enforcement algorithm definition are included in separate documents, attached as appendices to
this report.

9
The project scope includes research, development, and evaluation of improved logic for a
predictive braking enforcement algorithm for use in PTC applications for freight trains.
Considerations for passenger trains are outside the scope of the project.
Although test software applications implementing the algorithm logic were developed during this
project for purposes of test and evaluation, development of source code for use in a safety critical
application was outside the scope of work. Some implementation details were considered in
certain cases, but were largely not included within the project scope. Documentation of the logic
and methods developed was included, but development of software requirements specifications
and design documents were not included in the project scope.

1.5 Organization of the Report

The report is organized into sections defined by the various tasks of the project. Section 2
describes the development of a methodology that relies on a combination of simulation and field
testing to evaluate PTC braking enforcement algorithms in order to increase confidence in the
safety and performance of the algorithm, while reducing the dependency on costly field testing.
Section 3 discusses the criteria for a safe braking enforcement algorithm and provides an analysis
for developing appropriate criteria. Section 4 describes the algorithm used as the base algorithm
for development and provides a summary of the performance characteristics of the base
algorithm from both simulation and field tests. Section 5 identifies a number of modifications
made to the base algorithm before proceeding with the development of new functions to improve
the performance-related issues identified during the evaluation of the base enforcement
algorithm.
Sections 6, 7, 8, and 9 describe the first phase of development and testing of new functions to
improve the performance of the enforcement algorithm. Section 6 discusses the adaptive
functions, originally investigated as part of an FRA-funded proof-of-concept project. Section 7
describes the development and testing of an emergency brake backup function, and Section 8
describes the modifications developed for handling trains operating with distributed power.
Section 9 provides a summary of the results of the evaluation of the enforcement algorithm with
the new functions developed during Phase 1.
The second phase of development and testing is the subject of Sections 10, 11, and 12. Section
10 discusses considerations for the use of locomotive braking during PTC enforcement and the
associated hardware and software modifications required. Section 11 details the development of
a function for incorporating the use of dynamic braking into the enforcement algorithm to
improve the stopping distance prediction on decline grades and other scenarios where dynamic
braking is used to control the speed of the train. Section 12 provides a summary of the results of
the evaluation of the enforcement algorithm following the developments from Phase 2.
The third and final phase of development is described in Sections 13, 14, and 15. Section 13
describes modifications necessary to expand the scope of the enforcement algorithm to handle
additional train types. Section 14 describes a research task to investigate the data and interfaces
available to the PTC enforcement algorithm, with particular focus on those that have not
typically been used with previous enforcement algorithms. Section 15 provides a summary of
the results of the evaluation of the final developmental algorithm with all functions implemented.
Sections 16 and 17 discuss the evaluation of PTC enforcement algorithms from two different
PTC suppliers. Section 16 discusses the development support and testing activities associated

10
with evaluating the enforcement algorithm developed by Wabtec for use in the Interoperable
Electronic Train Management System (I-ETMS®) PTC system. Section 17 describes the
implementation of the Phase 1 enforcement algorithm by Lockheed Martin Corporation (LMC)
for use in the developmental Vital Positive Train Control (V-PTC) system.

11
2. Development of Enforcement Algorithm Evaluation Tools
and Methodology
The braking enforcement function enables the safety benefit of the PTC system by forcing the
train to a stop whenever a limit is predicted to otherwise be exceeded. It also has the potential to
severely impact the railroad operation by forcing trains to slow or stop in situations where it
would not otherwise be necessary. For these reasons, it is essential that the braking enforcement
function be rigorously evaluated against a variety of operating scenarios to ensure that it meets
the system specifications and expectations of the railroad. To perform such an evaluation, a test
methodology must be developed that satisfies the objectives of quantifying the safety and
performance of the enforcement algorithm and that is also practical in terms of cost and time.
The primary objective of the enforcement algorithm evaluation methodology is to demonstrate a
high degree of confidence that any given train, in any given operational scenario, will stop short
of a given target stopping location as a result of PTC brake enforcement. Historically, this
objective has been expressed as a probability that a train will stop short of a target stopping
location with a given confidence level. This implies that the system specification defines both
the probability limit and confidence level for the given probability limit. Section 3 describes the
research to identify an appropriate safety objective. For the purposes of the test methodology, it
is simply assumed that the safety objective is defined in this manner.
Traditionally, it has been assumed that evaluation of the braking enforcement algorithm would
be achieved through a large number of full-scale tests performed on revenue lines with a variety
of train configurations and test conditions. This method of evaluation, however, is neither
practical, nor does it provide a statistically high level of confidence in the safety and
performance of the algorithm. This type of testing is both costly and time consuming, and it also
has the potential to affect capacity and cause interference to revenue service traffic. There is
limited control over test conditions, in terms of boundary condition (e.g., worst-case) scenarios
and, while specific operating conditions such as track grades and train speeds may be possible, it
is unlikely that a given test train will exhibit boundary condition characteristics. The potential
for repeatability testing is also very limited, and the quantity of field tests practically achievable
generally falls short of what is needed for adequate statistical significance.
For these reasons, an enforcement algorithm evaluation methodology that provides a higher level
of statistical confidence in a more practical manner was conceived. Appendix A provides
documentation of the enforcement algorithm evaluation methodology. The development of the
methodology and the tools used are described in this section.

2.1 Overview of Enforcement Algorithm Evaluation Approach

The enforcement algorithm evaluation methodology combines computer simulation testing in a
lab environment and field testing in a controlled test environment to achieve the objective of
providing a high level of statistical confidence in the result in a more practical and efficient
manner. The purpose of the simulation component of the methodology is to statistically quantify
the safety and performance of the enforcement algorithm. This is achieved by running large
batches of braking enforcement simulations with Monte Carlo variation of train and
environmental characteristics that affect train stopping distance over a wide range of operational

12
scenarios. A limited amount of field testing then provides validation of the simulation results
using actual hardware inputs to the enforcement algorithm.
This testing methodology provides the capability to test the enforcement algorithm over a wide
range of operating scenarios, including boundary conditions, in a safe and efficient manner,
through the use of simulations. To rely on simulation data as the primary component of the
evaluation process, it is necessary to use a validated mathematical model that accurately
represents the response of the train to a wide range of practical inputs and to provide adequate
empirical data to demonstrate that the simulation properly represents how the enforcement
algorithm will perform in the field.

2.2 Simulation Testing

The simulation testing component of the enforcement algorithm evaluation methodology makes
use of a set of computer software tools to employ a Monte Carlo simulation process, which
results in a set of output data that can be analyzed to identify the statistical probability and
confidence that the algorithm will meet the specified safety and performance criteria. The Monte
Carlo method involves running large numbers of simulations with inputs to the simulations
randomly assigned on the basis of the practical and physical distributions and limits that define
the system. Because of the wide range of parameters that affect the stopping distance of a freight
train and the interdependence of these parameters, a deterministic evaluation is not feasible,
making the Monte Carlo simulation process the preferred method of evaluating the enforcement
algorithm.

2.2.1 Overview of Simulation Testing Process

The simulation testing process is intended to evaluate the enforcement algorithm over the full
range of operating scenarios that the system is expected to encounter and considering the
practical variability of the parameters that can have a significant effect on the stopping distance
of the train. The simulations are organized into test scenarios, each of which represents a
potential operating scenario for the system to encounter. The test scenario is defined by the
nominal train consist, the nominal track profile, the initial speed and location of the train, and the
target stopping position.
Multiple braking enforcement simulations are run for each test scenario. The values of the
parameters that can have a significant effect on train stopping distance are randomly selected for
each simulation from distributions that represent the practical range of values for the given
parameter. In some cases, the distribution of values for a parameter is affected by the value
randomly selected for a different, related parameter.
The test scenarios that make up the complete simulation test matrix are intended to include the
boundary operating conditions and represent the full range of conditions that can be experienced.
To make the simulation process more efficient, the test scenarios are organized into batches that
are executed together. A batch could contain any number of test scenarios, each representing a
different nominal operating scenario, and each test scenario could contain any number of
individual simulations, each representing a potential specific instance of the test scenario. Figure
3 illustrates the relationship between batches, test scenarios, and simulations.

13
 Figure 3. Organization of Simulations

For each individual simulation test, the train is modeled approaching the target at the defined
initial speed. The enforcement algorithm triggers a brake application to prevent a violation of
the stop target, and the response of the train is modeled. The result of the individual simulation
represents a single possible stopping location for the given test scenario with the given
enforcement algorithm. The aggregate result of the simulations for the entire test scenario then
defines the distribution of possible outcomes. This data is analyzed to determine the safety and
performance characteristics of the enforcement algorithm for the given test scenario. These
characteristics can then be analyzed together to quantify the overall safety and performance
characteristics of the enforcement algorithm.

2.2.2 Simulation Testing Tools

The simulation testing portion of the enforcement algorithm evaluation methodology requires the
following three components, as Figure 4 illustrates:
• A proven, validated train action simulation model that accurately models the response of
a given train under given conditions, with the ability to modify train, track, and
environmental characteristics that can affect the stopping distance of the train;
• A test controller/logger (TCL) software application that can generate the simulation
inputs to the model from input provided by the user, run large batches of simulations
using Monte Carlo simulation techniques, and log the required output; and
• The enforcement algorithm under evaluation, implemented as a standalone software
application incorporating a common interface to the simulation test components to
receive train status and command brake enforcement applications.

14
 Test Controller
Enforcement
and Logger
Algorithm
Figure 4. Simulation Testing Components

Simulation Model
To model any given braking enforcement scenario, the chosen simulation model must accurately
model the response of the train to given inputs, be capable of modeling the specific
characteristics of each component of each car within the train and the specific characteristics of
the track, and be capable of reporting train status data at regular, frequent intervals. Therefore,
TOES™ was the simulation model selected for enforcement algorithm evaluation. TOESTM is a
longitudinal train dynamics model developed by the AAR that models the status of every car in a
given train at every time step of the simulation. Car status data includes location, velocity,
acceleration, forces acting on the car, and brake system component status.
The model allows the user to enter specific characteristics for each car in the train, including car
weights and dimensions, aerodynamic properties, truck characteristics, coupler and draft gear
characteristics, and brake system components and characteristics. This flexibility essentially
allows the user to model any currently used freight rail cars and arrange them into any train
consist desired. The model also allows the user to enter track characteristics (e.g., track grade
and curve) that affect the longitudinal motion of the train, allowing any section of track to be
modeled. Finally, the model allows the user to enter environmental conditions, such as ambient
temperature and the coefficient of friction between the wheels and brake shoes, that can affect
the longitudinal motion of the train. The TOESTM model allows the user to enter train handling
commands, such as throttle and brake settings, at any time step in the simulation and models how
the train reacts to these commands.
The components that make up the TOESTM model include some of the most accurate and proven
models currently available to the railroad industry. These include a variety of draft gear models,
multiplatform cars, an aerodynamic drag routine, and a variety of user-customizable car
components. TOESTM also includes a theoretical fluid dynamics model of the air brake system.
This model has been shown to be a significant improvement over similar models empirically
derived from test data. The air brake model within TOESTM can simulate the automatic and
independent air brakes, a range of brake valve and brake shoe types, any length of brake pipe,
brake cylinder dimensions, and reservoir volumes.

15
Test Controller/Logger Software
In order to manage the vast number of simulations required to generate the necessary statistical
significance for the safety and performance of the enforcement algorithm over the entire range of
potential operating scenarios, a custom software application was necessary. To support the
industry in the development and testing of a safe and operationally efficient braking enforcement
algorithm, TTCI developed (using internal research and development funds) a TCL software
application with the capability to generate and execute thousands of braking enforcement
simulations using a Monte Carlo method that uses operating scenarios and parameter variation
distributions entered by the user.
The TCL application performs the following three major functions:
• Generation of random simulation inputs
• Execution of individual simulations
• Logging of output data
To generate simulation input data, the user sets up a batch of test scenarios to be evaluated. The
user selects a train consist and track profile and enters the initial train speed and location, as well
as the target stopping location for each test scenario in the batch.
The user defines the train consists by selecting the desired cars and arranging them in the desired
order. Each car is defined by the nominal components and characteristics of the car and the
potential variation of these components and characteristics, also defined by the user. The
variation of the car components and characteristics can be represented by a variety of
distributions that allow the user to define the variability of a given parameter to match its actual,
real-world variation. The user also defines the potential variation of environmental
characteristics and the variation because of errors in reported data regarding track characteristics,
train speed, and location.
The user selects how many simulations the TCL software will run for each test scenario in the
Monte Carlo process. The TCL software then generates the simulation input data for each
simulation within each test scenario by randomly selecting values for the variable parameters
from the input distributions defined by the user.
Once the simulation input data is generated, the user can run the batch through the TCL software.
The TCL application runs each simulation for each test scenario individually in the simulation
model by advancing the train toward the target at the given speed. At each second of simulation
time, the simulation model reports train status data to the TCL, which then passes the
information along to the enforcement algorithm. When the enforcement algorithm predicts an
impending target overrun, it sends a command to the TCL application to initiate a penalty brake
enforcement, which executes the penalty in the simulation model. The TCL continues to
advance the simulation until the train is stopped. The enforcement algorithm can also send a
command to initiate an emergency brake enforcement, which TCL then executes in the
simulation model.
Once the train has stopped, the simulation is complete, and the TCL software logs the output data
in a database for post-process analysis.

16
Interface to Enforcement Algorithm
The enforcement algorithm evaluation methodology can be applied to evaluate any enforcement
algorithm for any North American freight PTC implementation. The methodology treats the
software implementation of the enforcement algorithm as a black box that communicates with
the simulation testing components over an open communications interface. A document that
details the communications process and protocols was prepared for use by developers of
enforcement algorithm software to be evaluated using the methodology. This document is
attached as Appendix B.
To allow for the most flexibility in the test setup, the interface was designed with
communications over transmission control protocol/internet protocol (TCP/IP). This allows for
the enforcement algorithm to be implemented as an executable software application running on
the same machine as the TCL software, as a virtual machine with a separate IP address, but
operating on the same hardware as the TCL software, or as software running on separate
hardware that communicates over TCP/IP.
The interface was also designed with flexibility for initializing the simulation test process to
allow for more efficient execution of the simulations. The TCL software can execute the
enforcement algorithm software directly, if it is run on the same machine as the TCL software.
Alternatively, an enforcement algorithm initialization module was developed that sends an
initialization message to the enforcement algorithm software, indicating that the previous
simulation is complete and the new simulation is beginning. This allows the enforcement
algorithm software to re-initialize internal parameters for the new simulation.
To ease the integration of an untested enforcement algorithm with the TCL software setup, a
protocol test application was developed. The protocol test application replicates the
communications to and from the TCL software with the current protocols, but without all of the
other functionality of the TCL software. This allows the developer of the enforcement algorithm
software to test its communications interface and debug any issues locally, resulting in reduced
time and cost associated with the integration process. The source code for the protocol test
application is also available to support the development of the interface on the enforcement
algorithm side without releasing the proprietary TCL software source code.

2.2.3 Simulation Test Matrix

To effectively evaluate the safety and performance of the enforcement algorithm for
implementation in North American freight service, the test matrix must include an adequate
number of simulation test scenarios to provide confidence that the algorithm will perform
according to the specifications under virtually any practical conditions that may be encountered.
The test matrix was therefore designed to include test scenarios that define the boundaries of
practical operating conditions.
Each test scenario is defined by the train, track profile, and operating speed. In order to define
the test scenarios to be included in the simulation test matrix, the practical ranges of each of
these were researched, using recent consist data, timetables, and operating rules provided by the
railroads through the advisory group. This information was used to identify the logical
boundaries on operating conditions from which the test matrix was developed. The final version
of the simulation test matrix included review and input from the advisory group.

17
Train Consists
The train consists included in the simulation test matrix represent a range of nominal train
consists that are regularly and frequently run by the railroads. Each consist is made up of an
arrangement of nominal cars, each with a given load. The specific car characteristics that affect
braking performance are set to nominal values, which are then varied in the Monte Carlo
simulation process. From information provided by the railroads, the following three groups of
train consists were identified:
• Unit freight—Trains consisting entirely of a single car type that are typically all loaded to
capacity or empty. These are typically bulk commodity trains such as coal or grain
trains.
• Manifest freight—Trains consisting of a mix of car types and loads.
• Intermodal freight—Trains consisting entirely of intermodal cars that are typically all
loaded or empty, although the weight of the loads varies considerably.
A number of specialty train types were identified (e.g., RoadRailer™, high and wide load, extra
heavy load requiring speed restrictions, and others), but the frequency with which these trains are
run is limited. These train types were outside the scope of the enforcement algorithm evaluation
methodology.
For each train type, a range of train makeups, train lengths, train loading conditions, and
locomotive arrangements were identified. Table 1 summarizes these for each of the three train
types. In most cases, 6-axle, high-horsepower locomotives were used in the arrangement
indicated. For the shorter manifest freight trains (light locomotives, 3-car, 10-car), where the
type of locomotive may have a significant effect on the train stopping distance, both 4-axle and
6-axle locomotives were included. In all cases, the number of locomotives was selected on the
basis of the required horsepower, to maintain track speeds on the various track sections selected
for the given train type.
For both the manifest freight and intermodal trains, a pseudo-random process for generating train
makeup and car loading was developed. Samples of recently run consist lists from each of the
railroads represented on the advisory group were used, and the following probabilities were
identified:
• Probability that each car type exists in a given randomly generated train;
• Probability that the following car is of the same car type (i.e., a block of cars of similar
type within the train); and
• Distribution of nominal load for each car type.
Using these probabilities, a semi-automated process was developed to assign cars to a consist,
given the length of the consist, and to assign loads to each car selected.

18
 Table 1. Train Consist Parameters for Simulation Testing
Unit Freight Manifest Freight Intermodal Freight
Homogenous makeup of: Pseudo-random mix of: Pseudo-random mix of:
• Aluminum hoppers • Box cars • Single-platform
• Steel hoppers • Covered hoppers intermodal well cars
• Covered hoppers • Gondolas • Three-pack intermodal
• Tank cars • Flat cars well cars
Train • Five-pack intermodal
• Refrigerated box cars • Open-top hoppers
Makeup well cars
• Multilevels (vehicular • Aluminum coal gondolas
flat cars) • Tank cars
• TOFC/COFC flats
• Multilevel cars
(vehicular flats cars)
• 100 cars • Light locomotives (4- • Short (~ 5,000 ft)
• 135 cars axle and 6-axle) • Medium (~ 7,500 ft)
• 200 cars • 3 cars (w/4-axle and 6- • Long (~ 10,000 ft)
• 260 cars (aluminum and axle locomotives) • Very long (~ 15,000 ft)
steel hopper trains) • 10 cars (w/4-axle and 6-
Train Length axle locomotives)
• 40 cars
• 100 cars
• 150 cars
• 200 cars
• Fully loaded Pseudo-random loading from • Loaded with pseudo-
• Fully empty historical consist data random loading from
Train Loading historical consist data
Condition • Empty with pseudo-
random loading from
historical consist data
• Head end (100-car • Head end (0-car, 3-car, • Head end (short and
trains only) 10-car, 40-car, and 100- medium trains)
• Head and rear (100-car, car trains) • Head and rear (short,
Locomotive 135-car, and 200-car • Head and rear (100-car, medium, and long
Arrangement trains) 150-car, and 200-car trains)
• Head, mid, and rear trains) • Head, mid, and rear
(135-car, 200-car, and • Head, mid, and rear (long and very long
260-car trains) (150-car, 200-car trains) trains)

The complete matrix of train consists includes a specific combination of train makeup, train
length, train loading condition, and locomotive arrangement described in Table 1.
For manifest freight trains, 10 specific consists are included, using the pseudo-random car type
selection process for each combination of train length, power arrangement, and locomotive type.
Of these, one consist contains all fully loaded cars, one contains all empty cars, and the
remaining eight contain cars loaded according to the pseudo-random car load selection process.
For the case of light locomotives, train makeup and car loads do not apply, so there are only two
consists for each locomotive type—one with a single locomotive and the other with three
locomotives.

19
For intermodal freight trains, five unique consists are included, using the pseudo-random car
type selection process for each combination of train length, base loading condition, and power
arrangement. For the cases where the base loading condition is met, one of the five consists
contains all fully loaded cars, and the remaining four contain cars loaded from the pseudo-
random car load selection process for loaded intermodal consists. For the cases where the base
loading condition is empty, one of the five consists contains all empty cars, and the remaining
four contain cars loaded from the pseudo-random car load selection process for empty
intermodal consists (In many cases, trains are designated empty, but actually contain variations
in loading because of empty containers, etc.).
Appendix C includes a table with descriptions of the entire list of test consists. Each of these
nominal test consists is made up of an arrangement of nominal car types, from the specifics of
the consist. The nominal cars that make up each of the test consists were selected from data
from Universal Machine Language Equipment Register (UMLER) and from the advisory group
to represent a typical instance of each of the given car type. The specific characteristics of each
car type that affect braking performance were varied during the Monte Carlo simulation process
to represent the range of possible instances of each car type. Appendix C also includes
descriptions and references for each of the nominal car types used.

Track Profiles and Operating Speeds

The operating conditions under which the train consists in the test matrix are run are designed to
include the boundary of practical conditions for each train type. These boundary conditions were
determined from timetables and operating rules provided by the advisory group.
The operating conditions are defined by the track profile (grade and curvature) and the operating
speed of the train. The range of track grades was identified first. In most cases, the tests were
run on a sustained track grade, with the exception of test cases run over undulating grades (crest
or trough). Although there are sections of track with more extreme grades for short sections, the
most severe sustained track grade was identified as 2.8 percent.
Data from the advisory group was reviewed to determine the rules governing operation over
sustained grades within the identified range. It was observed that, in many cases, characteristics
of the train operating over the terrain had an impact on the maximum speed allowed. The
consists were therefore divided into the following groups with the following characteristics:
• Loaded intermodal freight trains less than 8,500 ft in length
• Loaded intermodal freight trains greater than 8,500 ft in length
• Empty intermodal freight trains
• Manifest freight trains with less than or equal to 14,000 tons trailing weight
• Manifest freight trains with greater than 14,000 tons trailing weight
• Loaded unit freight trains
• Empty unit freight trains
The data was then analyzed to identify sustained grades and their associated maximum allowable
speeds for the various groups of train types. The data was analyzed according to whether a train
could be run on a given grade at a given speed, regardless of whether trains of that type were

20
necessarily run on the territory in question. The analysis revealed the maximum percent grade
over which a given train type could operate at a given speed. Figure 5 shows a summary of the
results of the analysis. The shaded areas of the chart indicate allowable operating speeds for
various train types over various grades. Figure 5 is intended to provide a concise summary in a
single chart to illustrate the boundary operating conditions; therefore, not all the specific train
type groups identified above are displayed. Rather, the train types are sorted into three general
groups.

Figure 5. Summary of Boundary Operating Conditions on Declining Grades

As Figure 5 shows, there are natural breaks in the maximum allowable speed as the percent
grade increases. These breaks define the boundaries of allowable operating conditions.
Although it is conceivable that a certain train type could safely descend a grade at a speed higher
than indicated, no such areas were identified in the analysis. The “X” marks in Figure 5 indicate
conditions that were selected for simulation on descending grades to cover the boundary
operating conditions in terms of maximum allowable speed, medium speed (30 mph), and low
speed (10 mph).
In addition to the descending grades, simulations were selected to be run on 0.5 and 1.5 percent
ascending grades and 1 percent crest and trough scenarios at the maximum allowable speeds for
those grades. In all cases, the maximum allowable speeds were adjusted to the maximum
achievable speed for cases where the given train could not maintain the given allowable speed.
Table 2 displays a summary of the simulation test speeds for each group of train types on each
grade. Appendix C provides a more detailed table with each consist and the allowable speed on
each grade in the test matrix.

21
 Table 2. Speed and Grade Configurations for Simulation Testing
Grade
0% 0.5% 1.5% -0.5% -1.1% -1.7% -2.2% -2.8% 1% 1%
Crest Trough
Loaded 70, 70, 10 25 70, 30, 70, 30, 25 20 15 70 70
Intermodal 30, 10 10
<= 8500 ft 10
Loaded 60, 60, 10 25 60, 30, 60, 30, 25 20 15 60 60
Intermodal 30, 10 10
>8500 ft 10
Empty 60, 60, 10 25 60, 30, 60, 30, 25 20 20 60 60
Intermodal 30, 10 10
10
Manifest 60, 60, 10 25 60, 30, 45, 30, 25 20 15 45 45
Freight <= 30, 10 10
14,000 tons 10
Manifest 60, 60, 10 25 60, 30, 45, 30, 25 20 0 45 45
Freight > 30, 10 10
14,000 tons 10
Loaded 50, 50, 10 25 50, 30, 45, 30, 25 0 0 45 45
Unit 30, 10 10
10
Empty Unit 60, 60, 10 25 60, 30, 55, 30, 25 20 0 55 55
30, 10 10
10

2.2.4 Identification and Quantification of Variable Parameters

The Monte Carlo simulation technique employed in the simulation testing component of the
enforcement algorithm evaluation methodology involves randomly assigning values to the
various input parameters to the simulation model, according to the practical variability of each
parameter, for each simulation within each test scenario. This is achieved by defining the
distribution of possible values for each parameter, including train-level and environmental
parameters, for each car type and using the TCL software to randomly assign values from these
distributions.
The parameters to include in this process are those that can have a significant effect on the
stopping distance of the train and can be practically modeled. Research conducted to identify
these parameters included discussion with experts in the air brake field, review of literature on
train stopping distance calculations and air brake systems, and review of parameters included in
the TOESTM model. In total, 28 parameters were identified as having the potential to
significantly affect the stopping distance of a freight train. These parameters are sorted into
those that apply to the entire train (train and environmental parameters), listed in Table 3, and
those that apply to each car in the train individually (car parameters), listed in Table 4.

22
 Table 3. Train and Environmental Parameters that can Affect Freight Train
Stopping Distance
PARAMETER UNITS SOURCE
Ambient Pressure psi Historical NOAA* weather data for United States
Ambient Temperature deg F Historical NOAA weather data for United States
Brake Pipe Leakage Rate psi/min Expert opinion and limited measured data
Expert opinion and data from AAR Reports R-469,
Coefficient of Friction Between
N/A “Brake Shoe Performance Evaluation” [2] and R-565A,
TRAIN AND EVNIRONMENTAL PARAMETERS

Brake Shoe and Wheel

“Brake Shoe Performance Test II” [3]
Length of Time of Distributed
Power Communications Link seconds Expert opinion and information provided by railroads
Outage
Error in End-of-Train Pressure
as Reported by End-of-Train psi Accuracy of +/-3 psig per AAR Standard S-5701 [4]
Device
Error in Head-of-Train Pressure Variability as specified by accuracy of Dynisco Model
psi
as Reported by Pressure Sensor PT311JA pressure transducer
Error in Reported Head End
ft V-PTC Build 1A testing results [5]
Location
Percent Operable Brakes percent Expert opinion and information provided by railroads
Error in Reported Train Speed mph V-PTC Build 1A testing results [5]
percent
Error in Reported Track Grade According to accuracy of grade data in track database
grade
Error in Reported Degree of degree Not varied — Variability not found to significantly affect
Track Curvature curvature results
Not varied — Slight variation expected and taken care of
Nominal Brake Pipe Pressure psi
with other brake pipe pressure parameters (e.g., leakage)
Not varied — Variability not found to significantly affect
Wind Speed mph
results
*NOAA = National Oceanic Atmospheric Administration

23
 Table 4. Car Parameters that can Affect Freight Train Stopping Distance
PARAMETER UNITS SOURCE
Historical consist data provided by railroads and Wheel
Car Tare Weight lb
Impact Load Detector (WILD) data
Davis resistance equation
Expert opinion, data from energy testing, and Modified
aerodynamic coefficient (v2 lb/mph2
Davis Equation
dependent term)
Davis resistance equation
bearing resistance coefficient Expert opinion, data from energy testing, and Modified
lb/axle
(number of axles dependent Davis Equation
term)
Davis resistance equation rolling
Expert opinion, data from energy testing, and Modified
resistance coefficient (constant lb/ton
Davis Equation
term)
Davis resistance equation rolling
Expert opinion, data from energy testing, and Modified
resistance coefficient (v lb/ton*mph
Davis Equation
dependent term)
Brake Force Per Brake Shoe UMLER (combination of car build date and whether or
CAR PARAMETERS

with 50 psi Brake Cylinder not car is empty or load equipped), AAR Manual of
lb
Pressure, when empty/loaded Standards and Recommended Practices (S-401) [6], and
equipped Carlson [7]
Brake Force Per Brake Shoe UMLER (combination of car build date and whether or
with 50 psi Brake Cylinder not car is empty or load equipped), AAR Manual of
lb
Pressure, when not empty or Standards and Recommended Practices (S-401), and
load equipped Carlson [7]
percent Historical consist data provided by railroads and WILD
Car Load
error data
Measurements provided by railroads and performed by
Brake Cylinder Piston Stroke inches
TTCI
UMLER (using car build date in relation to year when
Control Valve Type N/A each model brake valve was introduced), Air Brake
Association Proceedings
Percent empty or load valve
N/A UMLER
equipped
Not varied — Variability not found to significantly affect
Brake Rigging Type N/A results and taken care of in other parameters (e.g., Brake
Force Per Brake Shoe)
Not varied — Variability not found to significantly affect
Brake Pipe Length ft
results
Not varied — Variability not found to significantly affect
Car Length ft
results

Each of the identified parameters was evaluated at a high level to determine if the variability
would have a reasonably significant effect on the stopping performance during PTC
enforcement. Of the 28 parameters identified, 6 were determined to have such a slight effect that
they were not included further in the process:
• Error in reported degree of track curvature — Track curvature is determined by data in
the track database, which includes track centerline survey data at intervals of

24
 approximately 30 ft. With this level of precision, the error in track curvature is expected
to be considerably smaller than the level that would have any appreciable effect on
stopping distance prediction.
• Nominal brake pipe pressure — The nominal brake pipe pressure (brake pipe pressure
when the brakes are fully released) is set using the feed valve on the locomotive.
Although this is adjustable, it is unlikely to vary much from the standard 90 pounds per
square inch (psi) pressure. Other brake pipe parameters such as brake pipe pressure
leakage will far outweigh the effect of any slight variation in the nominal brake pipe
pressure.
• Wind speed and direction — Although wind speed and direction can have a significant
effect on energy consumption for freight trains, the effect on stopping distance is minimal
because of the large magnitude of the other forces involved (e.g., braking force and grade
force).
• Brake rigging type — Differences in brake rigging primarily affect the piston travel of
the brake cylinder(s) and the net brake shoe force acting on the wheel. Since each of
these parameters is varied independently of brake rigging type, this parameter does not
need to be varied.
• Brake pipe length — Although varying the brake pipe length can have a significant effect
on the propagation time of the brake signal, and the level of brake pipe length variability
between car types can be significant, the variability of brake pipe length for a given
specific car type and length is very small, resulting in almost no appreciable added
uncertainty in train stopping distance.
• Car length — Total train length is reported to the onboard system using the consist data
available. Error in individual car lengths can result in error in this value, which can result
in error in calculating grade and curvature forces. However, the magnitude of the
potential error is small, and the effect on calculating stopping distance is even smaller.
In order to accurately model the variability in stopping locations using the Monte Carlo process,
it was necessary to quantify the variability of each of the remaining 22 parameters according to
the actual, real-world variability of the parameter. A variety of sources were used to quantify the
variability of the parameters, and these are listed in Tables 3 and 4 for each parameter. The
variability of each parameter is described by one of four different types of distributions:
• Continuous uniform (flat or rectangular) distribution, where all values within an interval
are equally probable;
• Normal (Gaussian) distribution, where the mean and standard deviation are defined;
• Discrete distribution, where a number of discrete values are possible, each with a defined
probability; and
• Discrete continuous uniform distribution, where a discrete number of continuous uniform
distributions, each with relatively small defined intervals, are used to describe the
probability of each value, to estimate more complex distributions.
The distributions used to describe each parameter and the development of these distributions is
described in the following subsections.

25
Ambient Pressure
Changes in the ambient atmospheric pressure can have an effect on the amount of pressure in the
air brake system, leading to an effect on the braking performance of the train. The average sea
level pressure of 1013.25 mb8 was converted to psi, yielding 14.7 psi, which was designated as
the mean for the half normal distribution. Adjusting the average sea level pressure value for an
altitude of 10,000 ft, representing the highest altitude a train may likely encounter in the United
States, yielded a pressure of 10.2 psi. Using 10.2 psi as a point three standard deviations away
from the mean gives the standard deviation a value of 1.5 psi. The effect of the half normal
distribution is that the probability of any value above the mean is zero, resulting in only half of
the distribution being used to describe the variability of this parameter.

Ambient Temperature
The ambient air temperature can significantly affect the flow of air in the air brake system. The
NOAA historical weather data [9] was used to quantify the variability in ambient temperature
during a PTC enforcement scenario. The variability is defined by a normal distribution with a
mean of 54.1 °F and a standard deviation of 10.8 °F.

Brake Pipe Leakage Rate

Brake pipe leakage occurs when air leaks out of the brake pipe at pipe and hose connections,
which can result in differences in brake pipe pressure throughout the train and can affect the
application and recharge time of the air brake system. The distribution of variability in brake
pipe leakage, as well as a limited set of measurements, was developed from discussions with
railroad personnel and experts in the field of air brake systems. The variability is defined by a
normal distribution with a mean of 2.5 psi/minute and a standard deviation of 0.83 psi/minute.

Coefficient of Friction between Brake Shoe and Wheel

The brake shoe force is applied normally to the wheel tread and relies on the friction between the
brake shoe and the steel wheel to retard the rotational motion of the wheel. As the friction
between the two changes, so does the ability to slow the car, making this a key parameter in
determining train stopping performance. In the TOESTM model, coefficient of friction between
the brake shoe and wheel is determined from the type of brake shoe and the speed for each car
individually. The coefficient of friction between the brake shoe and wheel can be modified by a
percentage to represent variations in the calculated coefficient of friction related to a variety of
factors, including weather, wheel temperature, and differences arising from the specific condition
and composition of a given brake shoe. Studies conducted by AAR on the variation of the
coefficient of friction between the brake shoe and the wheel, [2, 3] along with discussions with
experts in the field, were used as a basis for defining the variability of this parameter. From this
data, the variability is defined by a normal distribution with a mean of 0 percent and a standard
deviation of 6.67 percent, resulting in an equal probability that the coefficient of friction is less
than or greater than the nominal calculated coefficient of friction.

Length of Time of Distributed Power Communications Link Outage

The propagation time of the brake signal through the brake pipe is related to the number of
locations that the air can exhaust. In a distributed power configuration, air from the brake pipe is
exhausted from both the head end and the remote locomotive consist(s). There is some delay

26
from the initiation of the brake application on the head end to the initiation of the brake
application on the remote locomotive consist(s) related to the time it takes to transmit the signal
via radio. In certain geographical areas (e.g., mountainous areas or tunnels), the communications
may be interrupted at the time the brake application is initiated, resulting in further delay to the
application on the remote locomotive consist(s). Although there is little data available on the
frequency and amount of time these communications outages occur, discussions with appropriate
railroad personnel provided a reasonable basis for quantifying this variability. The distribution
of delay between application of the brakes on the head end and the remote locomotive consist(s)
is defined by a half normal distribution with a mean of 2 seconds and standard deviation of 2
seconds. The effect of the half normal distribution is that any value below the mean has a
probability of zero, resulting in only half of the distribution being used to describe the variability
of this parameter.

Error in Head-of-Train Pressure as Reported by Pressure Sensor

The braking enforcement algorithm uses pressure data from the brake pipe to determine the state
of the brake system at any given time. Error in the pressure reported to the system can vary from
one sensor to the next, resulting in potential error in the stopping distance prediction. The head
end brake pipe pressure is measured by a pressure transducer inserted into the brake pipe. The
potential variability of the pressure reported by this transducer was quantified from the
manufacturer specifications for a sample transducer that could be used in a PTC application [10].
The variability is defined by a continuous uniform distribution over a range of +/- 0.5 psi from
the actual pressure.

Error in End-of-Train Pressure as Reported by End-of-train Device

In addition to the brake pipe pressure on the head end, the brake pipe pressure on the rear end of
the train is also used to determine the state of the brake system at any given time. The rear end
brake pipe pressure is measured by an end-of-train device and communicated over a radio
frequency link to the system onboard the lead locomotive. AAR specification S-5701 defines the
accuracy of the brake pipe pressure reported by the end-of-train device [4]. Therefore, the
variability is defined by a continuous uniform distribution over a range of +/- 3 psi from the
actual pressure.

Error in Reported Head End Location

Application of the air brake enforcement by the PTC system requires knowing the current
location of the train and comparing this against a given stop target. The accuracy with which the
system can identify the actual location of the train can therefore have an effect on when the
application occurs, which in turn affects the safety and performance of the system. The accuracy
of the location is generally determined by the onboard system using a combination of data from
the Global Positioning System (GPS), locomotive tachometer, and other sources. Although the
specific design could differ from one system to the next, a reasonable quantification of the
variability in the error in reported location can be derived from test data reported in the vital
positive train control research project [5]. Using this data, the variability in the error in reported
location is defined by a normal distribution with a mean of 0 and a standard deviation of 3.6 ft.

27
Error in Reported Train Speed
The enforcement algorithm depends on knowing the current speed of the train at any given time
in predicting the stopping distance of the train. The current speed of the train is generally
determined by the onboard system using a combination of data from the GPS, locomotive
tachometer, and potentially other sources. Although the specific design could differ from one
system to the next, a reasonable quantification of the variability in the error in reported speed can
be derived from test data reported in the V-PTC research project [5]. Using this data, the
variability in the error in train speed is defined by a normal distribution with a mean of 0 mph
and a standard deviation of 0.16 mph.

Percent Operable Brakes

Before a train leaves a terminal, an air brake test is performed to ensure that the brake system on
all cars is operational. After the train leaves a terminal, if there are issues with the air brake
system on certain cars, the train crew is permitted to cut out the brakes on up to 15 percent of the
cars in the train. Although it is conceivable that the system could allow the crew to enter the
number of cars with brakes cut out, there is a possibility of error, both in the initial train
departure test and the reporting of cars cut out en route. There is limited, if any, data available
on the probability that any brakes are cut out on any given train at any given time. However,
discussions with railroad personnel indicate that it is rare for brakes to be cut out. Therefore, the
percentage of operational brakes at the time enforcement occurs is defined by a normal
distribution with a mean of 99 percent and a standard deviation of 0.33 percent.

Error in Reported Track Grade

The system uses a track database to determine the track grade over the section of track the train
is occupying during a stopping distance prediction. Error in the reported grade can therefore
affect the safety and performance of the system. The track grade data in the track database is
generally defined as the percent grade over a given section of track, with a precision of one-tenth
of a percent. Therefore, the potential error in track grade over any section of track can be
described by a continuous uniform distribution over a range of +/- 0.05 percent.

Car Tare Weight and Car Load

Train weight is provided to the enforcement algorithm from data supplied by the railroad
operating the train. In some cases (e.g., unit coal operations), the weight provided is very
accurate, although in other cases (e.g., intermodal operations), the error in reported train weight
can be significant. The nominal tare weight and load on each car in the test consist represents
this reported weight. Variations from the nominal, reported weight can result in inaccuracies in
the stopping distance prediction.
The error in reported train weight is applied by randomly varying the tare weight and load of
each car from the nominal tare weight and load for the given car. The basis for the distributions
used for this variation is an analysis of a sample of train consist lists provided by the railroads
compared against wheel impact load detector (WILD) data for those consists, which provide the
actual weight of each car. The variation in tare weight and load is defined, using the analysis, by
a different distribution for each nominal car type used in the simulation test consists. In many
cases, a different distribution is used, depending on whether the car is reported to be loaded or

28
empty. Appendix D provides a table of the distributions used for the error in tare weight and
load for each nominal car type.

Percent Empty or Load Valve Equipped

Empty and load valves reduce the amount of brake cylinder pressure that builds on a car when
the load on the car is less than a specified level. They are generally used to provide a sufficient
level of braking when the car is loaded, without providing excessive braking when the car is
empty. Data on whether the cars within a given train consist are empty or load equipped is
generally not provided for the enforcement algorithm and this can have a significant effect on the
stopping distance prediction.
A discrete uniform distribution was developed to represent the probability that each car type in
the simulation test matrix is empty or load equipped, using data in UMLER for the given car
type. Appendix D provides a table of the distribution used for each nominal car type.

Net Brake Force per Brake Shoe

The net brake force provided by the brake shoes on a given car is a result of the air pressure in
the brake cylinder providing a force on the brake cylinder piston, which drives a system of levers
and rods known as the brake rigging to produce a force on the wheels. The net brake shoe force
on a given car is required to be within a given range, per AAR specifications for the allowable
net brake ratio [6]. Net brake ratio is generally defined as the ratio between the total brake shoe
force acting on the wheels of a given car at a given brake cylinder pressure and the total weight
of the given car. Net brake ratio is typically broken into loaded net brake ratio (the ratio of the
total brake shoe force acting on the wheels when the car is loaded and the maximum gross
weight of the car) and empty net brake ratio (the ratio of the total brake shoe force acting on the
wheels when the car is empty and the tare weight of the car).
A variety of factors—for example, car design brake ratio, efficiency of the brake rigging,
alignment of the brake shoes, and general wear on the brake system components—can affect the
net brake shoe force at a given brake cylinder pressure. The potential range in the values for the
net brake shoe force on each car within a train can give rise to a great deal of variability in the
stopping distance of the train. However, there is very little data available on the measured net
brake shoe force on cars, except during initial acceptance tests or when there is an issue with the
brake system. Therefore, to quantify the variability in net brake shoe force, a variety of data
sources and assumptions was used.
It can be assumed that any given car was designed with a net brake shoe force that provides a net
brake ratio within the range of allowable net brake ratios specified in the AAR standard at the
time the car was built. Since the AAR specification for net brake ratios has changed over time,
data in the UMLER database was used to identify the probability that a car of a given type was
built in each of the date ranges when the specification was changed. Research conducted on the
reduction in net brake ratio because of wear suggests that a 1 percent reduction in net brake ratio
is reasonable over time [7, 11]. Therefore, the range of potential net brake ratios for a given car
is defined by the upper limit of the AAR specification at the time the car was built and the lower
limit of the AAR specification at the time the car was built minus 1 percent.

29
Using the above assumption, the distribution of possible net brake shoe forces at a given brake
cylinder pressure for a given car type and build date were defined as a continuous uniform
distribution, with limits defined as follows:
• For cars that are empty or loaded equipped:
▬ The lower limit of the range is defined by the lower limit of the AAR standard for
loaded net brake ratio at the time the car was built minus 1 percent.
▬ The upper limit of the range is defined by the upper limit of the AAR standard for
loaded net brake ratio at the time the car was built.
• For cars not empty or loaded equipped:
▬ The lower limit of the range is defined by the lower limit of the AAR standard for
loaded net brake ratio at the time the car was built minus 1 percent.
▬ The upper limit of the range is defined by the smaller of:
 The upper limit of the AAR standard for empty net brake ratio at the time
the car was built.
 The upper limit of the AAR standard for loaded net brake ratio at the time
the car was built.
Appendix D provides a table of the distribution used for net brake shoe force for each nominal
car type.

Train Resistance
In addition to tractive forces, brake forces, and forces arising from the track profile (grade and
curvature), there are a number of forces that act to resist the motion of a freight train, including
aerodynamic resistance, bearing friction resistance, and rolling resistance at the wheel-rail
interface. The magnitude of these resistive forces is generally relatively small in comparison
with the other forces present during a penalty braking scenario, but the variability of these forces
can have a minimal effect on the stopping distance of the train.
Train resistive forces can be quantified according to a formula known as the Davis resistance
formula [12], which estimates the resistive forces acting on a given car at a given speed,
according to coefficients that represent the characteristics of the given car:
𝑅 = 𝐴𝑤 + 𝐵𝑛 + 𝐶𝑤𝑣 + 𝐷𝑣 2 (1)

In the above equation, R is the resistance in lb, w is the weight of the car in tons, n is the number
of axles on the car, v is the velocity of the car in mph, and A, B, C, and D are the coefficients
that define the characteristics of the car. The coefficients for a generic modern freight car are
defined by the Modified Davis Equation, as follows:
𝐴 = 0.6
𝐵 = 20
𝐶 = 0.01
𝐷 = 0.07

30
The variability for these generic coefficients was derived from a combination of results from
energy tests and discussions with experts in the area of train energy testing and modeling. Based
on these results, the variability of each of the coefficients is represented by a normal distribution,
with the mean and standard deviation specific to the car type. Appendix D provides a table of
the distributions used for each nominal car type.

Brake Cylinder Piston Stroke

As air pressure builds in the brake cylinder, a piston is extended until the brake shoes contact the
wheels. The stroke length of the piston is dependent on wear of the brake shoes and wheels, as
well as characteristics of the brake rigging and automatic slack adjuster. As the piston stroke
changes, the volume of air in the brake cylinder also changes, which affects the pressure in the
brake cylinder. Thus, the brake cylinder piston stroke can affect the level of brake shoe force
during penalty brake enforcement and, ultimately, the stopping distance of the train.
To quantify the variability of brake cylinder piston stroke, measurements were taken by both
TTCI and several of the railroads on the advisory group on a random sample of cars equipped
with standard body-mounted 10-inch by 12-inch brake cylinders. The results of the
measurements showed that the variability of brake cylinder piston stroke for these cars followed
a normal distribution with a mean of 7.58 inches and a standard deviation of 0.8 inch. According
to the AAR Field Manual, the allowable range for these types of brake cylinders is 6 to 9 inches
[13]. The center of this range is 7.5 inches, which correlates well with the mean of the measured
values. The absolute range of values correlates to approximately two standard deviations from
the mean.
Because there are a wide variety of brake cylinder types and sizes, this correlation formed the
basis for defining the variability in piston stroke for all brake cylinder types. Using this
correlation, the distributions used to model the variability in brake cylinder piston stroke were
defined by a normal distribution with a mean at the center of the range of allowable piston stroke
for the given brake cylinder type, with a standard deviation of half of the difference between the
center and the extreme value of the allowable range. Appendix D provides a table of the piston
stroke distributions used for each nominal car type.

Control Valve Type

The control valve is the component of the air brake system on each car that determines whether
the brakes are applying, releasing, or lapped, depending on the relative pressures in the brake
pipe and auxiliary reservoir(s). Advances in air brake technology over the years have improved
the response of the control valves throughout the train, reducing the time it takes for the air brake
signal to propagate through the length of the train.
It is recognized that a range of control valves, with varying performance characteristics, are still
used in service today. To estimate the probability that a given car is equipped with a given brake
valve type, the year in which each type of control valve was introduced was cross-referenced
with UMLER build date data for the given car type, with the assumption that the car was
equipped with the most technologically advanced control valve at the time it was built. Although
control valves can be changed throughout the life of a car, replacing a control valve with a less-
capable valve is not allowed, making this a conservative assumption.

31
The variability in control valve type is therefore represented by a discrete distribution, where
each potential control valve is assigned a probability for the given car type. Appendix D
provides a table of the probability of each control valve type for each nominal car type.

2.3 Field Testing

The field testing component of the enforcement algorithm evaluation methodology is intended to
provide confidence in the results of the simulation testing component by
1. Verifying the accuracy of the model used in the simulation testing;
2. Verifying that the variability in stopping distance is accounted for in the simulation
testing; and
3. Verifying that the algorithm responds the same whether tested in the field or simulation
environment.
The first two objectives can be satisfied independently of the actual enforcement algorithm, but
the third requires testing with the enforcement algorithm under evaluation. The majority of the
field testing can be performed in a controlled test environment, which is more practical than
testing on revenue service lines. In some cases, testing on revenue service lines may be required
for scenarios that cannot be tested in the controlled test environment.

2.3.1 Overview of Field Testing Process

The field testing process is designed to support the simulation testing component of the
enforcement algorithm evaluation process by evaluating both the model used for simulation
testing and the enforcement algorithm itself, for a limited number of tests, with actual hardware
and equipment. The field testing component includes three types of tests.
In the first type of field testing, stopping distance tests are performed with measurements—that
can be practically measured—of all parameters that can affect stopping distance. These
measurements can then be input to the model, and stopping distance simulations can be run to
verify that the modeled results correlate well with the field tests.
In the second type of field testing, stopping distance tests are repeated multiple times without
changing any parameters. These results are used to verify that the parameters included in the
simulation testing component represent the range of parameters that actually affect stopping
distance, or if additional variability can be expected.
Finally, in the third type of field testing, the enforcement algorithm is implemented in field
hardware, and enforcement tests are run. In this type of testing, consist data, track data, and a
stop target are provided to the enforcement algorithm. The train then approaches the stop target
at a given test speed, and the enforcement algorithm is responsible for enforcing a brake
application to stop the train short of the given stop target. The results from these tests can be
compared with simulation test results to verify that the enforcement algorithm responds and
performs the same, regardless of whether it is evaluated in a simulation or field environment.

2.3.2 Field Testing Tools

The field testing component requires test locomotives equipped with onboard hardware to
provide the data necessary to the enforcement algorithm and the interface to the brake system to

32
apply the air brakes upon command from the enforcement algorithm. In a complete PTC
implementation, the onboard hardware would include the enforcement algorithm software and all
necessary interfaces to the locomotive. For development and test purposes, however, the test
locomotives were equipped to provide the necessary interfaces to a standalone enforcement
application running on a separate laptop computer.
Three test locomotives were set up for enforcement algorithm testing at the Transportation
Technology Center (TTC). All three included onboard hardware to interface any developmental
enforcement algorithm over TCP/IP, using the same protocol and message structures as specified
for simulation testing. In this way, it is possible to evaluate the enforcement algorithm as a black
box application in both the simulation and field test environments, without having to make any
modifications to the enforcement algorithm software. Appendix B is a document that describes
the interface and test setup.
The onboard test hardware includes a location determination system developed by LMC for the
V-PTC project, which is used to provide accurate location and speed data to the enforcement
algorithm. The onboard hardware also includes a pressure transducer to provide head end brake
pipe pressure data and an end-of-train telemetry head end unit to provide tail end brake pipe
pressure from an end-of-train device. Finally, the onboard hardware includes interfaces to the
locomotive to provide throttle control settings, dynamic brake status data, and to the air brake
system to apply penalty and emergency brake applications.
In addition to the onboard hardware designed to evaluate an enforcement algorithm as a
standalone software application, two of the three test locomotives were also equipped with
Wabtec I-ETMS® hardware. This allows for testing the I-ETMS® enforcement algorithm
developed by Wabtec using the complete onboard hardware and software planned for
implementation.
Both the V-PTC hardware and the I-ETMS® hardware were installed on the test locomotives
with funding from other FRA-sponsored projects.
The field testing performed on this project made use primarily of the test consist used at the
Facility for Accelerated Service Testing (FAST) at TTC. At FAST, a heavy-axle load train is
run over a 2.7-mile section of track known as the high-tonnage loop (HTL), where a number of
experimental track components and wayside systems, as well as certain car and locomotive
onboard systems, are evaluated. In service at FAST, the train continually laps the track, testing
the components and systems in an accelerated manner. The train itself is made up of aluminum
coal gondolas loaded to 315,000-pound gross weight. The availability of this test consist makes
it the ideal test train for evaluating enforcement algorithms under this effort.
In addition to the FAST train, which is representative of loaded unit operations, some tasks in
this project required testing with manifest freight equipment. In order to accomplish these tasks,
a number of empty manifest freight cars were borrowed from the Union Pacific Railroad
(UPRR). By combining some of the loaded FAST cars with these empty manifest freight cars, a
reasonably representative manifest freight train was assembled.
The field testing also made use of the Railroad Test Track (RTT) at TTC. It is a 13.5-mile track
loop with a variety of grades and curves, making it an appropriate test track for enforcement
algorithm testing. The maximum grade on the RTT is 1.47 percent. The RTT track profile data

33
was converted into a track database format for use in both the LMC location determination
system and the Wabtec I-ETMS® hardware.

2.3.3 Field Testing Comparison to Simulation Testing

Comparison between simulation and field data is intended to verify that the TOESTM model used
for simulation testing accurately represents the response of a freight train to a penalty brake
application under various operating scenarios. By measuring all of the parameters—that can be
practically measured—that affect stopping distance and applying these measurements to the
model, it should be possible to replicate the field test results in the model very closely.
Demonstrating that the model closely matches the field data when all the inputs are accurately
measured supports use of the model to evaluate the enforcement algorithm.
Five test scenarios were identified on which to run these comparisons to demonstrate the
accuracy of the model for a variety of train lengths, speeds, and track grades. Measurement of
the train consist parameters discussed in Section 2.2.4 was performed to the extent practical.
Because the FAST train, which is made up of very similar cars (in effect, a unit train), was used,
a number of simplifications were possible. In the case of car weights, the most recent scaled
weight of the cars in the train was used. The average weight for all cars was used in the model
for simplicity, because these weights were consistent on a per car basis. Brake cylinder piston
travel was measured for all brake cylinders in the train, but again, the average was used in the
model for simplicity. Measurement of car brake shoe force is a costly and time-consuming
process, making it impractical to measure more than a few cars. Therefore, three random cars
were measured, and the average of these was assumed for every car in the model.
After the field tests were run, the model of the train consist was simulated for each test scenario
using the actual location and speed of the train where the penalty was applied, as well as the
actual brake pipe pressures and other test-specific data. The resultant modeled stopping profiles
were compared with those from the field data to evaluate the error inherent in the model. Table
5 shows the results of the field and modeled stopping distance tests.

Table 5. Stopping Distance Test Comparison Results

Test Conditions
Measured Modeled
Error Percent
Speed Track Stopping Stopping
Consist (ft) Error
(mph) Grade Distance (ft) Distance (ft)

2 Locomotives,
30 Flat 1,510 1,739 229 15.2
10 Cars
4 Locomotives,
30 Flat 2,015 1,947 -68 -3.4
40 Cars
4 Locomotives,
50 Flat 5,051 5,055 4 0.1
40 Cars
4 Locomotives,
10 Flat 464 461 -3 -0.6
90 Cars
4 Locomotives,
30 Decline 3,690 3,800 110 3.0
90 Cars

34
Table 5 shows that the model calculated stopping distances that were very close to the stopping
distances measured in the field tests, with the exception of the short train test, which was off by
15.2 percent. A number of factors could explain this discrepancy. First, since average numbers
were used for a number of the car parameters, it is possible that the short train contained one or
two cars that exhibited outlying values for some of these parameters (e.g., a light car or a car
with higher than average brake shoe force). These cars have less of an effect in the longer
consists where the number of cars is large enough that one or two outliers will not have a
significant impact on the overall stopping distance. It is also possible that errors in locomotive
characteristics (e.g., weight), which were not measured, had an effect on these cases. Again, the
effect of errors in locomotive characteristics is more profound for shorter consists.
With the exception of the short train case, the results showed that the model very closely
matched the field test data for a range of speeds and grades. Were it practical to measure every
characteristic of the test with even more precision, the results could have been closer still. Given
the number of parameters that can affect freight train stopping distance, the range of errors
reported here indicate that the model is very accurate in predicting stopping distances.

2.3.4 Field Repeatability Testing

The objective of field repeatability testing is to identify the amount of variability in freight train
stopping distance, given identical input conditions. In particular, by fixing all of the parameters
that are to be varied in simulation testing, any additional variability because of other factors can
be identified and accounted for. Demonstrating that the variation in stopping distance, with all
of the parameters fixed, is insignificant can also show that those parameters varied in simulation
testing represent the significant contributors to the variability in stopping distance, which
supports the findings of the Monte Carlo simulation process.
To assess the repeatability of stopping distances under a variety of fixed combinations of real
train operating conditions and configurations, a series of train stopping experiments were run.
Six different scenarios were selected to be tested, representing a range of train speeds, train
lengths, and track grades, each using the loaded FAST test train described in Section 2.3.2.
Table 6 lists the scenarios. The desired sample size is from six to ten stops for each test scenario
(sample set). It takes time to test with long trains; therefore, more samples were gathered from
the short train tests. However, the minimum desired six tests were achieved for all but one test
scenario, as shown in Table 6.
To ensure consistency in stopping location, automatic location detector (ALD) tags were placed
on the track at the desired brake locations and an ALD tag reader was installed on the
locomotive. The ALD tag reader was wired to the brake system to initiate a penalty brake
application when the locomotive crossed the ALD tag on the track. For each test, the locomotive
engineer accelerated the train as closely as possible to the desired test speed at the ALD tag, at
which point the brakes were applied and the stopping distance was measured.

35
 Table 6. Stopping Distance Repeatability Test Results
Test Conditions Standard Average Standard
No. of Average
Deviation Stopping Deviation of
Speed Track Test Speed
Consist of Speed Distance Stopping
(mph) Grade Runs (mph)
(mph) (ft) Distance (ft)

4 Locomotives,
10 Flat 7 10.2 0.11 559 13
90 Cars
4 Locomotives,
30 Flat 6 29.8 0.24 2,409 10
90 Cars
4 Locomotives,
30 Decline 2 28.7 0.14 3,622 59
90 Cars
2 Locomotives,
10 Flat 10 10.1 0.09 240 6
10 Cars
2 Locomotives,
30 Flat 8 30.0 0.16 1,515 19
10 Cars
2 Locomotives,
30 Decline 8 30.0 0.17 3,322 51
10 Cars

Table 6 shows the average and standard deviation of the speed, as well as the average and
standard deviation of the stopping distance for each of the six test scenarios. As the table shows,
the tests were highly consistent. The standard deviations were relatively low compared with the
stopping distances, and the longer stopping distances generally correlated to the higher speeds,
whereas the shorter stopping distances generally correlated to the lower speeds.
The sample sets were evaluated individually for homogeneity of stopping distance variation.
The initial comparison tests evaluated the relative variance of each sample’s stopping distance
from the mean (Levene test) or median (Brown-Forsythe test) for that sample set. Stopping
distances by sample set were shown as statistically different, as expected. However, differences
from the stopping distance mean, by sample set, were shown not to have statistically significant
differences.
Further statistical tests were run that directly compared the mean or median differences. Given
the small sample sizes, both parametric (t-test and ANOVA) and nonparametric (K-S, W-W,
Man-Whitney) comparison tests were used. All of these tests agree that there are no statistically
significant differences between sample sets. The conclusion is that field tests of train stops are
highly repeatable with very low variation.

2.3.5 Enforcement Algorithm Field Testing

The purpose of enforcement algorithm field testing is to verify that the enforcement algorithm
performs satisfactorily for a sample range of operating conditions and to verify that the
enforcement algorithm does not perform differently when implemented in the actual field
hardware and when tested in the simulation environment. Statistical justification of the safety
and performance of the enforcement algorithm is not a direct objective of the field testing
because of the wide range of scenarios and large test sample sizes required. Rather, field testing

36
verifies the statistical justification provided by the simulation testing. In order to provide this
verification, a practical range of operating conditions must be evaluated in the field.
Because the test conditions that define the test scenarios are not dependent on specific locations
or railroads, but rather on train makeup, track profile, and train speed, it is possible to perform
the testing in a controlled test environment, and the results will be equivalent to a test on revenue
track, given identical test conditions. This allows for a number of tests to be performed in a
controlled test environment to verify the enforcement algorithm performance for those scenarios
tested, independent of location or railroad.
There are no criteria for the specific enforcement algorithm field tests that must be run to verify
the simulation test process. However, it is important to evaluate a variety of test scenarios that
cover a range of practical combinations of train makeup, track profile, and train speed. Although
it may be desirable to test boundary conditions such as steep grades, high and low speeds, and
long or heavy trains, it is not necessary to test the absolute boundary conditions; test scenarios
that are more typical should also be tested.
The enforcement algorithm field testing performed at each stage of development for this project
focused on scenarios that exercised each of the new functions developed. These test matrices are
described later in this report in the field test sections for each developmental function. A more
general field test matrix was developed for evaluating the final developmental algorithm, as well
as the algorithm developed by Wabtec. This test matrix was designed to cover a range of
operating scenarios that could practically be tested with the equipment and track available at
TTC, and it is described in more detail later in this report.
For each of the field tests conducted as part of this project, a test implementation plan (TIP) was
developed to describe the test activities, and custom test logs were developed for logging the
field test data. Appendix E contains the TIPs for each set of field tests and a sample test log.

2.4 Analysis of Test Results

The final component of the enforcement algorithm evaluation methodology is the analysis of the
results of the simulation and field testing to quantify the safety and performance of the
enforcement algorithm. In order to provide meaningful results from the evaluation, two key
parameters were identified that describe the safety and performance characteristics of the
enforcement algorithm:
• Probability of Target Overshoot — The probability that a given train overshoots the
target stopping location for a given test scenario, with 99 percent confidence. This is the
primary output of the analysis, as it demonstrates whether or not the enforcement
algorithm under evaluation meets the safety objective of the system.
• Probability of Excessive Target Undershoot — The probability that a given train
undershoots the target stopping location by more than:
▬ 500 ft, if the initial train speed at enforcement is < 30 mph
▬ 1,200 ft, if the initial train speed at enforcement is ≥ 30 mph
This probability provides an indication of the operational impact of the enforcement
algorithm. Ultimately, the operational impact is defined by whether the enforcement
algorithm forces the train crew to slow the train earlier than they would otherwise, and

37
 what impact that has on other trains on the network as a whole. However, this is
impractical to quantify, given the tools and data available. The probability of excessive
target undershoot provides an indication of the operational impact that can be analyzed
for each scenario individually and for all of the scenarios combined.
These parameters are determined for each test scenario from the results of the simulation tests.
A two-phase analysis method is employed, with the first phase being an exploratory data analysis
(EDA) where data augmentation and validation, data consistency checking, and data cleanup is
performed, and the second phase being the specific statistical analysis, where the probabilities
for the above parameters are estimated.
The EDA phase provides insight into the dataset from common descriptive statistics and
graphical analysis outputs. The primary objective is to ensure that the dataset is complete, and
that there are no anomalies in the data, which would indicate an error in the simulation test
process. For example, deviations in the speed at the point of enforcement are identified, which
may indicate that the given train could not maintain the specified speed for the given scenario.
Outliers are investigated to determine if they are reliable, or if they are generated from an error in
the process. Other statistical anomalies, such as odd shaped distributions (e.g., bimodal), are also
investigated. Additional data elements computed from the raw data that are required for
subsequent analyses are also computed and validated during the EDA.
A number of techniques are employed during the EDA. Data consistency is evaluated using
breakdown tables to isolate the simulations by scenario from the characteristics that make up
each scenario (e.g., train type, length, speed, track profile) and observing standard statistical
parameters that are generated for each scenario. Graphical outputs such as box plots, histograms,
and quantile-quantile (Q-Q) plots are also generated to quickly identify potential data anomalies,
and to observe expected trends in the data. The EDA is performed primarily using the data
analysis software system Statistica, Version 10 [14].
The specific statistical analysis phase generates the estimated values for the probability of target
overshoot and the probability of excessive target undershoot. These are considered specialized
statistical parameters because of the uncertainty in their determination. The uncertainty comes
from the fact that the estimation of the probability of target overshoot requires parts-per-
thousand precision on the basis of a parts-per-hundred data sample, meaning the estimated
quantile (e.g., 0.995 probability of target overshoot) is beyond the observed sample data range
(100 samples).
For the specific statistical analysis phase, the probabilities are estimated both empirically and via
extreme quantile estimation methods [15]. The empirical probability is directly calculated from
the sample. A long-term probability is estimated from observations of the distribution tail
characteristics using the peaks-over-threshold method as defined by Rychlik and Rydén to be a
Generalized Pareto Distribution (GPD). If the right distribution tail is upward-turning, as
observed in a Q-Q plot, then the empirical probability will be an underestimate of the true
probability [16,17]. For these cases, the extreme quantile estimate is made using a modified
peaks-over-threshold method. A more specific and reliable distribution function is substituted
following a direct data fitting evaluation. EasyFit Professional, Version 5.5, is used for data fit
evaluation and distribution function and parameter generation [18].

38
A number of additional parameters are computed for each test scenario, in addition to the key
parameters identified above. Using the specific simulations run, the following can provide
additional insight into the safety and performance of the enforcement algorithm:
• Average and Maximum Target Overshoot — The average and maximum distance beyond
the target stopping location for those simulations where the target stopping location was
exceeded. These statistics provide an indication of how extreme the observed target
overshoots were, which can be useful for additional algorithm development, or to
demonstrate how far beyond the target the stopping location can be expected, in the event
a target overshoot occurs.
• Average and Earliest Enforcement Location — The average and earliest location, relative
to the target, where enforcement occurred for each scenario. This demonstrates how far
ahead of the target stopping location the enforcement algorithm will typically enforce for
each scenario, which can be compared to where a train crew would initiate braking for
the scenario, to identify potential operational performance issues.
• Percent Enforcements Resulting in an Emergency Application — The percentage of the
tests where an emergency brake application was used in the enforcement of the target
stopping location. For enforcement algorithms that include an emergency brake backup
function, this provides an indication of how much the enforcement algorithm relies on the
emergency brake, which may be of interest.
In addition to evaluating the probability of target overshoot and the probability of excessive
target undershoot for each scenario individually, an estimate of the overall probability of target
overshoot and the overall probability of excessive target undershoot are also generated for all
scenarios combined. This provides a quick, high-level view of the safety and performance
characteristics of the enforcement algorithm without having to dig into the specifics of every test
scenario. Additionally, the location relative to the target where the probability of target
overshoot is equal to the specified safety requirement is identified. For example, if the
enforcement algorithm is determined to have a probability of overshoot that is greater than the
specified safety probability limit of 0.005, this would identify the point beyond the target where
the probability of overshoot is equal to 0.005. This can be useful for determining how close the
enforcement algorithm is to meeting the safety objective or identifying if the enforcement
algorithm is too conservative.
The results from the analysis of the simulation test results are confirmed by an analysis
comparing these results with the results of the field enforcement tests, for those scenarios where
field tests were performed. The approach for this comparison is to support a null hypothesis of
no difference, where the field test sample stopping locations cannot be proven to be from a
different distribution than that of the sample of simulation stopping locations. This method is
well established for cases such as this, where the sample of field test results for each scenario is
not large enough to provide statistical significance for comparison with the simulated sample.
The comparison is to hypothesize that the field test result is not different from the distribution of
the simulations. This general hypothesis goes for both the single and the small sample case. The
approach involves making a statistical test comparison of the single sample value against the
mean of the simulation sample (assuming normality). The proof uses a one-sample t-test (or the
nonparametric equivalent to compare with the median, if non normal). In general, if the single

39
field test value is within the main body of the distribution of the simulation sample, then the test
is satisfied. The closer it is to the mean of the simulation sample, the stronger the significance.
For a small sample of field tests, all of the above discussion holds, except that a two-sample t-
test (or nonparametric equivalent) is used. In this case, the means (or medians) of both samples
are compared.
The simulation, testing, and analysis described here demonstrate that the model accurately
represents the response of a freight train to a penalty brake application for any practical scenario,
and that the parameters varied in the Monte Carlo simulation process represent the significant
contributors to the variability of the stopping distance. Further, if a given enforcement algorithm
can be shown to meet the safety and performance criteria from the simulation testing and
analysis, and the field tests of this enforcement algorithm can be shown to correlate to the
simulation testing results, it should be considered acceptable for use in PTC systems.

40
3. Analysis of Enforcement Algorithm Safety Objective
The primary objective of the enforcement algorithm component of the PTC onboard system is to
force the train to a stop short of a given stop target. To ensure that modern PTC systems can
achieve the expected safety benefits, without presenting any negative operational effects, a safety
objective probability limit and confidence level must be determined that provides a high, but
realistic, level of safety. The purpose of this component of the research program was to evaluate
potential safety objectives and identify an appropriate level of safety for the enforcement
function of a PTC system.

3.1 Background and Implications of Enforcement Algorithm Safety Objective

In order for the system to ensure a sufficient level of safety, a probability limit is typically
specified to satisfy the safety objective of the system that defines the probability that a given
train will stop short of a given target stopping location. For the NAJPTC program, a safety
objective probability limit of 0.999995 was specified. This means that the system will enforce a
train to stop short of a given target stopping location 99.9995 percent of the time. Little
documentation exists on the history of this safety objective probability limit, and no statistical
justification could be found for it.
Because the actual probability that any given train will stop short of any given target stopping
location cannot be measured or computed deterministically, a confidence level must also be
specified. The probability limit is an estimate of the probability that a given train will stop short
of a given stopping location on the basis of a sample of tests. The confidence level is from the
same sample of tests used to determine the probability limit and represents the probability that
the estimated probability limit is the actual probability limit. No documentation of a confidence
level could be identified for the NAJPTC program.
Although the primary purpose for PTC systems is to provide an added level of safety to the
railroad operation by enforcing authority and speed limits (among others), it must be understood
that authority violations are rare events, and incidents resulting from authority violations are
even more so. The PTC system is conceived to force the train to a stop only in these rare cases
where an authority violation is imminent (i.e., the crew has not taken proper action to prevent the
violation). Therefore, care must be taken in specifying a safety objective probability limit and
confidence level such that it prevents the large majority of the potential authority violations
without resulting in excessive enforcements for cases where the crew has the opportunity to take
proper action to prevent the violation.

3.2 Analysis of Enforcement Algorithm Safety Objective

To illustrate the effect of the safety objective probability limit on incidents resulting from
authority violations, a basic fault tree analysis was performed. The objective of the analysis was
to demonstrate the effect on safety and operational performance of several potential safety
objective probability limits. The result of the analysis could then be used to determine a
statistically appropriate safety objective for the PTC enforcement function.
A fault tree is used to identify the probability of an event, using the probability of each individual
initiating and contributing event that results in the ultimate fault event. Table 7 describes the
symbols used in the fault tree analysis.

41
 Table 7. Symbols used in Fault Tree Analysis
Symbol Description

Initiating Event — Event that initiates a leg of the fault

tree that leads to the fault event

Intermediate Event — Event resulting from initiating

events below

Contributing Event — Event that contributes to the

ultimate fault event, but is conditional on prior events

And — All events below must occur to result in the

event above (probability of resulting event is the product
of the contributing events)

Or — Any one event below must occur to result in the

event above (probability of the resulting event is the sum
of the contributing events)

To begin the analysis, a fault tree was constructed to express the probability of an accident
resulting from an authority violation in centralized traffic control (CTC) territory. Figure 6
shows this fault tree.

Figure 6. Fault Tree for Accidents Resulting from Authority Violations in CTC

42
As Figure 6 shows, the initiating event is the locomotive engineer failing to heed the approach
signals leading up to the end of the authority, which results in an intermediate event of an
authority violation. Every authority violation does not result in an accident, however. The
probability of an accident resulting from an authority violation is the probability that there is an
authority violation and the probability that the violation causes an accident. The product of these
individual probabilities is the probability that an accident results from an authority violation.
For this analysis, the probabilities of each event were identified on a per-train-mile basis. The
probability that a locomotive engineer fails to heed the approach signals, leading to an authority
violation, was determined from the number of authority violations and the number of train-miles
traveled for the four railroads represented on the advisory group over a 2-year period (2007–
2008). Data provided by the railroads indicates that in those 2 years, a total of 1,002,737,271
train-miles were traveled, and 820 authority violations were reported. From estimates provided
by the railroads, it was assumed that 85 percent of the train-miles were traveled on signaled
territory. Using this data, the probability that a locomotive engineer fails to heed the approach
signals was determined: 820/(0.85 x 1,002,737,271) = 9.62E-7/train-mile.
The probability that an authority violation results in an accident was determined from the number
of authority violations and the number of accidents resulting from authority violations over the
same 2 years (2007–2008). Data provided by the railroads indicates that during those 2 years
820 authority violations occurred, and data from the FRA Web site shows that 12 accidents
occurred as a result of authority violations. The probability that an authority violation results in
an accident was then determined from this data: 12/820 = 1.46E-2.
Finally, the probability of an accident resulting from an authority violation is computed as the
product of these two probabilities: 9.62 E-7 x 1.46E-2 = 1.4E-8/train-mile. This can be
expressed in terms of the probability of an accident resulting from an authority violation per year
by multiplying by the average number of train-miles over the 2-year period: 1.4E-8 x 0.85 x
501,368,635.5 = 6/year. The inverse of this number, 0.167, is the number of years between
accidents resulting from authority violations with traditional signaling systems in CTC territory,
assuming the yearly average train-miles from 2007–2008.
With PTC, there are a number of functions that contribute to mitigating these faults. First, there
is an onboard display, which provides a constant display of the current position of the train and
the end of the authority for the train. The onboard display also provides a warning to the
locomotive engineer when the train is approaching the end of the authority. Second, the PTC
system provides an audible warning inside the locomotive cab when the train is approaching the
end of the authority and the locomotive engineer has failed to act to bring the train to a stop.
Finally, the PTC system enforces a brake application and brings the train to a stop if the
locomotive engineer has failed to respond to either the onboard display or the audible warning.
Therefore, in order for an authority violation to occur with PTC, the locomotive engineer must
fail to heed the approach signals AND must fail to respond to the onboard display and warning
AND must fail to respond to the audible warning AND the enforcement must fail to stop the
train short of the authority limit. This scenario is illustrated by the fault tree shown in Figure 7.

43
 (1)

Figure 7. Fault Tree for Accidents Resulting from Authority Violations with PTC

The probability that the locomotive engineer fails to respond to the onboard display and the
probability that the locomotive engineer fails to respond to the audible warning are related to
human factors that are difficult to estimate precisely. The data available is limited because of the
infrequency of these types of events and the difficulty in correlating related events. However, an
analysis of the root causes of 27 railroad accidents resulting from human factors errors was
performed, using data collected as part of a comparative risk assessment relating to technology
driven operations by the AAR [19]. From this data, the probability that the locomotive engineer
fails to respond to the onboard display was estimated at 0.4, and the probability that the
locomotive engineer also fails to respond to the audible warning was estimated at 0.2. Although
these estimates are considered to be conservative, it is recognized that they may be higher.
The probability that the enforcement fails to stop the train short of the target stopping location is
equal to 1 minus the specified safety objective probability limit for the PTC enforcement
function. For the NAJPTC program, this was specified as 0.999995, meaning the probability that
an enforcement would fail to stop the train short of the target stopping location is 0.000005.
Using these numbers, the probability of an authority violation with PTC can be determined:
9.62E-7 x 0.4 x 0.2 x 0.000005 = 3.85E-13. The probability of an accident resulting from an
authority violation can then be determined: 3.85E-13 x 1.46E-2 = 5.63E-15/train-mile.
Expressed in terms of number of years between accidents resulting from authority violations
with PTC, this becomes 416,667 years, assuming annual train-miles from 2007 to 2008.
Although the objective of PTC is to improve safety, it is clear that this is an overwhelming
reduction in the probability of accidents and is a contributor to the conservative nature of the
systems experienced to date.

44
3.3 Recommendation for Enforcement Algorithm Safety Objective
The fault tree analysis described in the previous subsection was repeated assuming safety
objective probability limits of 0.9995, 0.995, and 0.95. Table 8 shows the probability of an
accident and the number of years between accidents (assuming yearly train-miles from 2007 to
2008) resulting from an authority violation with each of the probability limits evaluated.
Table 8. Probability and Years between Accidents Resulting from Authority Violations
Enforcement Algorithm Probability of Accident Number of Years Between
Safety Objective Probability resulting from Authority Accidents resulting from
Limit Violation per Train-Mile Authority Violations*
Without PTC 1.4E-8 0.167
0.999995 5.63E-15 416,667
0.9995 5.63E-13 4,167
0.995 5.63E-12 417
0.95 5.63E-11 42
* Assuming annual train-miles from 2007-2008

From Table 8 results, a PTC system with a safety objective probability limit of 0.995 would
reduce the probability of an accident resulting from an authority violation by a factor of 2,500
from current train control systems and would result in an estimated 417 years between accidents
resulting from authority violations, assuming annual train-miles from 2007 to 2008.
Safety integrity levels (SIL) are used in certain industries to quantify the relative level of risk
reduction with a particular function of a system. Systems can be designed to a SIL between 1
and 4, with 4 being the highest level achievable. Table 9 shows the tolerable hazard rate (THR)
for the various SILs [20]. Although PTC systems in North America are not designed using this
methodology, it can be used to provide context for the level of safety of a system designed to
meet a particular probability limit of stopping short of a target.
Table 9. THR for Various SIL
SIL THR per hour per function
4 1E-9 ≤ THR < 1E-8
3 1E-8 ≤ THR < 1E-7
2 1E-7 ≤ THR < 1E-6
1 1E-6 ≤ THR < 1E-5

In the case of the enforcement function of a PTC system, the probability of a hazardous event is
the probability of an authority violation. For a system with a probability limit of 0.995, this is
3.85E-10 per train-mile. Data from the railroads indicates that the average train speed is 21.9
mph, meaning that the probability of a hazardous event is 3.85E-10 x 21.9 = 8.4E-9 per hour,
which is decidedly into the SIL 4 level. As mentioned, this does not mean that the system is
designed as a SIL 4 system, but it does provide a useful comparison for the level of safety for a
system designed with a 0.995 probability of stopping short of a target stopping location.

45
In addition to specifying the probability that a train stops short of a target, it is necessary to
establish a confidence level associated with this probability. Three values are commonly used to
measure statistical significance in terms of the confidence level. The confidence level is defined
as P(1-a), a defining the critical value or, the probability (P) that the result is false by chance
[25]. The commonly used a values are 0.05, 0.01 and 0.001 or confidence levels of 0.95, 0.99
and 0.999. The value 0.95 is considered ‘borderline statistically significant’, .99 is ‘statistically
significant’ and .999 is ‘highly statistically significant’ [26]. Thus, 0.95 was considered
insufficient with 0.99 an acceptable level of confidence for the PTC braking enforcement
function.
Using the analysis performed, it is recommended that the PTC enforcement function be designed
to stop a given train short of a given stopping location with a 0.995 probability and a 0.99
confidence. This provides a significant reduction in the probability of a hazardous event from
current train control systems and allows for less operational impact resulting from the PTC
system. This also provides a quantifiable safety objective that a PTC enforcement algorithm can
be evaluated against, using the evaluation methodology presented in Section 2.

46
4. Base Braking Enforcement Algorithm
A base braking enforcement algorithm is used in two ways in the research and development of
methods for improving the safety and performance of PTC braking enforcement algorithms:
1. As a point of reference to measure improvements against
2. As a starting point for development of test software to be used to evaluate the logic for
newly developed functions
Once the base enforcement algorithm was selected, the logic was implemented in a test software
application that could interface with the test environment. The algorithm was evaluated using
the simulation test methodology described in Section 2.2 to develop the reference data for
comparison with future developments. The base algorithm logic and assumptions were then
reviewed, and issues were identified to be resolved before proceeding with the research and
development of new functions. This section details the tasks associated with the base
enforcement algorithm and the results of the evaluation of the algorithm.

4.1 Source and Development of Base Braking Enforcement Algorithm

The requirements for selecting a base braking enforcement algorithm were that the enforcement
algorithm be nonproprietary so that the logic could be accessed for implementation in the test
software and be generally accepted as being representative of the performance available in the
industry. Using these requirements, the enforcement algorithm selected as the base enforcement
algorithm was one designed by Wabtec and implemented by Wabtec and LMC for the Illinois
Department of Transportation (IDOT) PTC project, as part of the NAJPTC program. The
algorithm logic is described in the report “Braking and Prediction Algorithm Definition” [21].
The braking enforcement algorithm estimates a conservative stopping distance for the train
assuming a penalty brake application is initiated under the conditions at the moment the
calculation is made. This estimate is made using a numerical integration method from a force-
acceleration model of the train. With this method, the forces acting on the train are estimated at
each time step following the penalty brake application; the results are then used to estimate the
acceleration of the train. The acceleration is used to predict the velocity and position of the train
for the next time step. The process is repeated until the predicted velocity of the train is zero,
and then the predicted stopping distance is determined. The stopping distance is then biased
using a safety offset determined by the speed of the train at the initial conditions, to ensure an
acceptable probability of stopping short of the target. If the stopping location determined from
this method is beyond the authority limit of the train, a penalty brake application is enforced.

As part of the proof-of-concept project that preceded this effort [1], this braking enforcement
algorithm was implemented in a test software application. The source code from the NAJPTC
IDOT project was used to develop this implementation of the algorithm, with some distinct
modifications to allow the algorithm to operate as a standalone application and to interface the
simulation and field test equipment.

Additional refinement of the base enforcement algorithm test software implementation was
performed as part of this research effort. The software was ported from the original C++ code
into C# code and many of the initialization and prediction logic routines were broken up and

47
reorganized to prime the code to allow for easier implementation of the functions to be
developed as part of this project. Modifications to the interface of the evaluation test
environment were also made to allow for more simulations to be run in a shorter period of time
than in the previous project.

4.2 Base Enforcement Algorithm Evaluation

Following the additional development of the base enforcement algorithm and the development of
the complete enforcement algorithm evaluation methodology and test environment, the base
enforcement algorithm was evaluated to provide a baseline level of performance with which to
compare new developments, as well as other PTC supplier implementations. The base
enforcement algorithm was evaluated with simulations from the enforcement algorithm
evaluation methodology described in Section 2.2, as well as a number of field tests, some of
which were performed as part of the proof-of-concept project that preceded this effort [1].

4.2.1 Simulation Testing

Simulation testing and analysis was performed on the base enforcement algorithm using the
methodology described in Section 2.2. However, the base enforcement algorithm did not include
provisions for multiple-platform cars typical of intermodal trains. Therefore, the simulation
evaluation was performed using only unit and manifest freight trains. Table 10 shows the overall
results of the simulation testing for these train types, in terms of the key parameters, the
probability of stopping short of the target, and the probability of stopping short of the
performance limit of 500 ft short of the target for speeds < 30 mph and 1,200 ft short of the
target for speeds ≥ 30 mph. Appendix G contains the detailed results from simulation testing of
the base enforcement algorithm.
Table 10. Base Enforcement Algorithm Simulation Test Results
Probability of Stopping Short Probability of Stopping Short
Train Type
of Target of Performance Limit
Unit Freight >99.999% 83.57%
Manifest Freight 99.99% 70.89%
Overall 99.994% 75.06%

As the results in Table 10 indicate, the base enforcement algorithm meets the safety objective of
stopping the train short of the target with at least a 99.5 percent probability. However, the
probability of stopping short of the performance limit is extremely high. This is confirmation of
the operational inefficiencies that are inherent in the base enforcement algorithm due to the
requirements imposed upon it by the NAJPTC program.

4.2.2 Field Testing

Field testing of the base enforcement algorithm was performed as part of the initial enforcement
algorithm development proof-of-concept project that preceded this effort [1]. In this effort, two
of the assumptions from the base enforcement algorithm were removed, to provide a better

48
comparison against the proof-of-concept developmental enforcement algorithm. First, the
assumption of 85 percent operable brakes was changed to 100 percent. Second, the target offset
was removed because the focus of the original project was on improving the prediction with
adaptive functions. With these assumptions removed, the results of the base enforcement
algorithm field testing do not match the results of the simulation testing because the simulation
testing used the base enforcement algorithm without any modifications. Still, these results
provide a good indication of how conservative the prediction logic in the base enforcement
algorithm is and it provided baseline data that will be used to show improvements with the
developmental algorithm.
The base enforcement algorithm was tested during the initial, proof-of-concept effort with the
train used at FAST, which, at the time, was made up of primarily steel hopper cars loaded to
315,000 lb gross weight. Table 11 shows the results from the field tests performed. The base
enforcement algorithm was tested in seven different scenarios, covering a range of train lengths,
speeds, and track grades, as indicated in the table. Each test scenario was run three times, and
the average stopping location relative to the target stopping location is reported in Table 11.

Table 11. Base Enforcement Algorithm Field Test Results

Test Conditions Average Stopping
Location Relative to
Consist Speed (mph) Track Grade Target (ft)
40 Cars – Loaded 40 Flat -1,294
40 Cars – Loaded 60 Flat -1,673
40 Cars – Loaded 40 Incline -479
40 Cars – Loaded 40 Crest -923
10 Cars – Loaded 40 Flat -1,397
75 Cars – Loaded 10 Flat -146
75 Cars – Loaded 40 Decline -3,895

The results indicate that the base enforcement algorithm, even without the target offset function
and the 85 percent operative brake assumption, generally stops the train well short of the target.
The results show that algorithm performed more efficiently in the incline and crest grades. This
is logical because the effect of gravity helps to slow the train in these cases, making the stopping
distance generally more consistent and predictable. The algorithm was also more efficient for
the slow speed (10 mph) case, which is also logical. These results provide a good indication of
the performance that can be expected for the base algorithm with the single train that was
available.
Since the initial proof-of-concept effort, the cars in the FAST train were replaced with newer,
aluminum coal gondolas, loaded to 315,000 lb gross weight. Although these cars are newer than
those previously used for testing, it was observed anecdotally that the braking capability of the
newer cars appeared to be less than that of the older cars. The new train offered an opportunity
to test the base enforcement algorithm with a different train of the same type, with presumably
different characteristics.

49
Additionally, one of the functions of the base enforcement algorithm was not evaluated as part of
the proof-of-concept effort: the ability to predict the stopping distance in cases where the brake
system is in a state other than fully charged (i.e., applying or releasing). To provide test data for
this functionality, additional testing of the base enforcement algorithm was performed.
Four brake state conditions were identified for the testing. The first three of these are to verify
that the enforcement algorithm will activate the brakes, and the fourth is to verify that it will not
activate the brakes if the locomotive engineer has the train under control.
• Fully charged — No brakes applied and brake pipe and reservoirs charged
• Brakes set — Brake application set, but not sufficient to stop the train short of the target
• Brakes set and released — Brake application set and released, but the system is still in the
recharging state
• Brakes set to stop — Brake application set sufficient to stop the train short of the target
Although some variations are to be expected, the enforcement algorithm will ideally stop the
train at the same location relative to the target, regardless of the state of the brake system, if all
else is equal. The only exception is that the enforcement algorithm should not apply a penalty in
the last case (brakes set to stop) because it should recognize that the brake application is
sufficient to stop the train short of the target without enforcement.
Seven test scenarios were included in the testing, with all four brake states tested under each test
scenario. Multiple tests were conducted for each test scenario and brake state. Table 12 shows
the test scenarios as well as the average stopping location relative to the target for each of the
four brake states in each test scenario.

Table 12. Additional Base Enforcement Algorithm Field Test Results

Test Conditions Average Stopping Location Relative to Target (ft)

Speed Track Brakes Fully Brakes Set Brakes Set
Consist Brakes Set
(mph) Grade Charged and Released to Stop
40 Cars – Loaded 30 Flat -370 0 -350 -730
40 Cars – Loaded 50 Flat -850 180 -850 -440
80 Cars – Loaded 30 Decline -1,930 -410 -1,770 -1,520
80 Cars – Loaded 10 Flat -140 20 -120 -260
10 Cars – Loaded 30 Flat -580 -170 -660 -270
28 Cars – Empty 30 Flat -460 N/A -420 -440

28 Cars – Empty 30 Decline -780 N/A -750 -530

The results in Table 12 indicate that the stopping location for the case where the brakes are set
was consistently further down the track than the fully charged case. Post-test analysis of the test
results indicates that this is primarily because of a difference in the assumption for brake pipe
propagation time between these two cases. This highlights a potential issue with the model of
the brake system within the algorithm and is further discussed in Section 4.3.

50
Table 12 shows that the results for the case where the brakes are set and then released were
consistent with the results for the fully charged case. This indicates that the algorithm effectively
models the response of the brake system to a brake release and also accurately models the
amount of braking capability with a train that has less than a full charge when the brakes are not
currently set.
The engineer stopped the train short of the target, closer in some cases than others, for the case
where a brake set was made sufficient to stop the train prior to the train reaching the target.
However, in all cases, the enforcement algorithm did not apply a penalty brake enforcement,
which indicates that the enforcement algorithm properly handled these cases.

4.3 Issues Identified with Base Enforcement Algorithm

In addition to evaluating the base enforcement algorithm with simulation and field testing, a
thorough review of the logic contained within the algorithm was completed to identify potential
issues and areas of improvement within the original functionality. These issues could then be
resolved before proceeding with the development of new functionality throughout the remainder
of the project.
One observation from the results of the base enforcement algorithm evaluation is that the results
vary dramatically for various types of trains. This is the result of the base enforcement algorithm
assuming that the characteristics of the cars are the same for all train types, when they actually
can vary significantly from one train type to another, as observed during the development of the
enforcement algorithm evaluation methodology discussed in Section 2.2.
The results of the simulation and field testing also illustrate one of the primary issues with the
base enforcement algorithm, which is that the algorithm enforces the train far too early in a large
number of scenarios, which can lead to operational inefficiencies. One of the primary reasons
for this excessive conservatism was identified when reviewing the logic of the base algorithm.
The purpose of the target offset function, as discussed in Section 1.1, is to offset the nominal
prediction to ensure a sufficient probability of stopping short of the target stopping location.
However, in the case of the base enforcement algorithm, many of the assumptions are worst-case
assumptions, rather than nominal assumptions. This is the case for the assumption of car brake
ratios, brake pipe propagation time, and percent operable brakes. These conservative
assumptions, when combined with the target offset, result in an additional layer of conservatism
that negatively impacts the operational performance of the enforcement algorithm.
The target offset function in the base enforcement algorithm is a function of train speed,
exclusively. Observations from the simulation and field testing indicate that the variability in
stopping distance is largely affected by other factors, such as track grade and train consist
parameters, in addition to train speed. Additionally, the target offset function computes
excessive (greater than 1,000 ft) target offsets for speeds greater than 40 mph, as shown in Figure
8. These observations indicate that the target offset function needs to be improved.
One of the primary components of the enforcement algorithm is the model of the air brake
system. The enforcement algorithm uses brake pipe pressure input to determine the state of the
air brake system, including the average level of air pressure in the auxiliary reservoirs and brake
cylinders in the train, at any given time. This data is then used to determine the amount of air
brake force acting on the train at any given time. The air brake model is used to determine the

51
actual state of the air brake system at regular intervals, as well as predict the state of the air brake
system throughout the stopping distance prediction loop.
Brake pipe, brake cylinder, and auxiliary reservoir pressures measured during simulation and
field testing were compared with the pressures predicted by the base enforcement algorithm,
which identified a number of issues with the base enforcement algorithm air brake model. For
charging the brake system, the base algorithm brake model predicts very long recharge times that
are inconsistent with the test results. The base algorithm brake model also does not incorporate
the faster rate of application that occurs with modern control valves at the beginning of a service
brake application. There were also a number of scenarios that were modeled where the base
algorithm brake model did not react properly; for example, when a service brake application was
made, then released, and then another service application was made before the system completed
recharging. In addition to these issues, the logic of the base algorithm air brake model was
reviewed, and some potential improvements were identified.

52
5. Revisions to Base Enforcement Algorithm
One of the objectives of this project was to develop PTC enforcement algorithm logic that is
ready for implementation by PTC system suppliers. Although the relative safety and
performance improvements that can be obtained with the newly developed functions can be
demonstrated by comparison with the baseline level of performance, the resulting algorithm
logic may still contain deficiencies in the base logic, which could be unacceptable for
implementation in a functional PTC system. Therefore, as part of the first phase of development
for this project, a number of revisions were made to the base enforcement algorithm logic, using
the issues identified with the base enforcement algorithm. The completed revised base
enforcement algorithm logic was organized and documented in an algorithm definition document
for review by railroads and PTC suppliers. The revisions to the base enforcement algorithm
were also implemented in the test software application so that, because the new functions were
implemented, the tests would be representative of the revised logic. This section details the
revisions to the base enforcement algorithm.

5.1 Addition of Train Types

The results of the simulation testing of the base enforcement algorithm indicated that there is
significantly different braking performance among train types. If the enforcement algorithm
assumes all trains to behave the same, it must be overly conservative for certain train types in
order to maintain the specified level of safety for others. Entering the train type in the
enforcement algorithm allows the algorithm to assume the braking performance more
appropriately for each train type. This logic can be taken to an extreme level, where the braking
performance of every car in every train is specified; but this is not practical, given the
availability of the information and the timeliness that is required. The train types were therefore
divided into a few broad categories that can be easily determined and supplied to the
enforcement algorithm, but that also separate the various trains into groups with similar braking
performance.
Using this logic, the following train types were defined for the enforcement algorithm:
• Unit aluminum coal — Unit coal train operations where the trains are made up of
exclusively aluminum cars (coal gondolas and/or hopper cars). These cars are becoming
increasingly popular for unit coal operations because they have large gross weight to tare
weight ratios, meaning they can haul more coal in each car. Because of their high gross
weight to tare weight ratios, these cars are all equipped with empty and load devices,
making their braking performance significantly different from other train types where the
percentage of cars equipped with empty and load devices is much smaller.
• Unit freight — Trains with a homogenous car type throughout that are either all loaded or
all empty. This includes unit tank trains, unit grain trains, and unit multilevel trains, as
examples. Unit train operations exhibit similar braking performance and can therefore be
grouped together under these terms. Since these trains are loaded with the same bulk
commodity, the variation in actual train weight from the reported weight is small, making
the variability in stopping distance less than that for other train types.
• Manifest freight — Trains with a mix of car types and loads. This type of train includes
the largest variety of car types and vintages, and the cars are generally loaded differently,

53
 making the variability in braking performance significant. By separating these train types
from other more specifically defined train types, it is possible to reduce the conservatism
of the braking distance prediction for those train types, while keeping the conservative
assumption for the braking performance necessary to maintain the specified level of
safety for these trains.
• Intermodal freight — Trains made up of exclusively intermodal cars. The base
enforcement algorithm does not have provisions for handling intermodal cars, which can
have significantly different braking performance than other types of cars. In many cases,
the cars are articulated, meaning the brake force is higher for the overall car, because
there are more axles to which to apply brake force. Many of these car types have high
gross weight to tare weight ratios, requiring them to be equipped with empty and load
devices, and the loading characteristics can vary significantly from car to car, making the
variability in braking performance unique compared with the other car types.
Each of the train types was added to the enforcement algorithm, as part of the first phase of
algorithm development, to allow for more specific braking performance characteristics and
variability to be assumed, as discussed above. However, modifications to the enforcement
algorithm for handling manifest and intermodal freight trains were not included until the third
phase of algorithm development. Therefore, the other modifications to the base algorithm that
are discussed in the following sections apply only to the unit freight train types. The
modifications for manifest freight and intermodal freight are discussed in Section 13.

5.2 Assumptions for Unknown Parameters

One of the issues identified with the base enforcement algorithm logic is that some of the key
assumptions about parameters that affect the stopping distance of the train use worst-case, rather
than nominal, assumptions. This results in a conservative prediction, which is then further offset
by the target offset function. By performing a nominal stopping distance prediction, the target
offset function can be designed to offset the prediction using the statistical variance in stopping
distance for the current conditions, which then results in an enforcement point that is no more
conservative than necessary. The three following key assumptions were identified as being
worst-case in the base enforcement logic:
• Nominal car brake force
• Brake pipe propagation time
• Percent operable brakes

5.2.1 Nominal Car Brake Force

The nominal car brake force is the amount of force applied by the brake shoes after the brake
cylinder pressure has built to its maximum level during a penalty brake application. The
enforcement algorithm is provided with the number of loaded and the number of empty cars in
the train, which are used to determine the nominal car brake force. The base enforcement
algorithm assumes, if not given additional detail on the car types within the train, that all loaded
cars in the train are 100-ton cars with a gross rail load (GRL) of 131.5 tons (263,000 lb). The
base enforcement algorithm further assumes that the brake force for all loaded cars at 50 psi
brake cylinder pressure is 17,548 lb. A brake cylinder pressure of 50 psi is that which would be

54
achieved at equalization (full penalty brake application) if the nominal (released) brake pipe
pressure was 70 psi. The AAR specifies loaded net brake ratio as the brake force achieved with
a 30 psi brake pipe pressure reduction (to ensure equalization) from a nominal brake pipe
pressure of 90 psi divided by the GRL of the car [6]. If the nominal (released) brake pipe
pressure was 90 psi, which is typical of North American freight operations and aligns with the
AAR definition for loaded net brake ratio, the brake cylinder pressure at equalization would be
greater by a factor of 90/70 (approximately 64 psi). At this brake cylinder pressure, the brake
force would also be greater by a factor of approximately 90/70 (a brake force of approximately
22,562 lb). For this type of car, the loaded net brake ratio would therefore be 22,562 lb / 263,000
lb x 100 = 8.6 percent, which is slightly more than the minimum allowable net brake ratio of 8.5
percent, according to the AAR standard S-401 [6]. Although it is recognized that older cars,
designed to older AAR net brake ratio standards, may have been designed to a lower net brake
ratio, and car net brake ratios may fade over time, this assumption is still considered to be worse
than nominal for many car types.
For empty cars, the enforcement algorithm must consider that the car may be equipped with an
empty and load device. Empty and load devices reduce the amount of brake cylinder pressure to
reduce the amount of brake force on the car when the load is below a specified level (typically 20
percent of the GRL when fully loaded). However, because the enforcement algorithm models
the air brake system for the train as a whole, it is more appropriate to model empty cars equipped
with empty and load devices as having the same brake cylinder pressure, but with reduced
nominal brake force. Typically, empty and load devices will reduce the brake cylinder pressure
to between 40 and 60 percent of that which would be achieved without the empty and load
device. If the empty and load net brake ratio is defined as the ratio of the net brake force when
the car is empty to the loaded GRL, it should be approximately 50 percent of the loaded net
brake ratio on average for a car equipped with an empty and load device. Since the base
enforcement algorithm assumes a loaded net brake ratio of 8.6 percent, it should then assume an
empty and load net brake ratio of 4.3 percent for cars equipped with an empty and load device
and 8.6 percent for cars not so equipped. The base enforcement algorithm assumes that the brake
force for all empty cars at 50 psi brake cylinder pressure is 12,390 lb. This equates to 15,930 lb
at a brake cylinder pressure of 64 psi. The empty and load net brake ratio for a 100-ton car with
a GRL of 263,000 lb would therefore be 15,930 lb/263,000 lb x 100 = 6.1 percent. This works
out to an assumption that 58 percent of the cars are equipped with empty and load devices. For
certain train types (e.g., unit aluminum coal trains), where the cars are all equipped with empty
and load devices, this is an unsafe assumption, whereas for other train types (e.g., manifest
freight), where, on average, very few cars are equipped with empty and load devices, this is an
overly conservative assumption. On average, for all cars, this assumption is considered to be
conservative and a better approach is needed.
To provide a more nominal assumption for the nominal car brake force, the average car net brake
ratio for each train type was used. To determine this, the car type that makes up each of the
types of unit trains were each examined individually. For each type of car, bins were defined for
the different ranges of brake ratios that a given car of that type could have been designed to. The
bins were defined using the range of car build dates that a particular version of the AAR standard
for brake ratio was in effect for. For each bin, the mean brake ratio was calculated, using the
range of brake ratios for the bin, and the assumption that the brake ratio can fade by 1 percent
over time [7, 11]. UMLER data was used to identify the probability that a given car of that type
could fit into each bin, both for cars of that type equipped with empty and load devices and for

55
those not equipped with empty and load devices. The average net brake ratio was then
calculated by averaging the mean net brake ratios for all of the bins, weighted by the
probabilities identified by the UMLER data.
When a unit train is identified as being loaded, the cars within the train are, by the definition of a
unit train, all loaded to capacity. Because of this, it is possible to assume the nominal car brake
force for loaded unit trains, FB,NOM,LOADED, using the average net brake ratio, NBRAVG, the total
gross trailing weight, WCARS, and the total number of loaded cars, NCARS, according to the
following formula:
𝑁𝐵𝑅𝐴𝑉𝐺 ∗ 𝑊𝐶𝐴𝑅𝑆 (2)
𝐹𝐵,𝑁𝑂𝑀,𝐿𝑂𝐴𝐷𝐸𝐷 =
𝑁𝐶𝐴𝑅𝑆

For the unit aluminum coal train type, the average net brake ratio is simply the average net brake
ratio for aluminum coal cars. For the other unit freight train type, the average net brake ratios for
all of the other unit car types, which include steel coal cars, covered hoppers, tank cars,
multilevels, and refrigerated box cars, are averaged together to determine the overall unit freight
average net brake ratio.
Using the average net brake ratio to determine the nominal car brake force, as opposed to
defining the nominal car brake force directly, means that the enforcement algorithm has to
assume the GRL of the cars that make up the train. This can only be done on loaded unit trains
where the total trailing weight of the train divided by the number of cars in the train is equal to
the GRL of each of the cars in the train. For empty unit trains and other train types, this cannot
be assumed, so the nominal car brake force must be assumed, rather than using the average net
brake ratio.
For empty unit trains, the nominal car brake force was determined by multiplying the average net
brake ratio for each car type by the average tare weight for that car type. Since there are two unit
train types, unit aluminum coal and unit freight, there are two different empty brake force values.
In the case of the unit aluminum coal train type, the nominal car brake force was equal to the
average net brake ratio multiplied by the average tare weight for unit aluminum coal cars. In the
case of the other unit freight train type, these values were averaged for all of the other unit car
types to determine the nominal car brake force. It was observed that the brake force values were
exceptionally high for the refrigerated box car and the multilevel car, whereas the average tare
weights were much higher than for other cars. So, it was determined that these cars would be left
out of the average for the unit freight train type, which results in some additional conservatism
for these trains, but maintains the safety required for the other unit freight trains. Table 13 shows
the revised assumption for the nominal car brake force for unit trains.

56
 Table 13. Revised Nominal Car Brake Force for Unit Trains
Nominal Loaded Car Brake Nominal Empty Car Brake
Train Type
Force Force

0.11 ∗ 𝑊𝐶𝐴𝑅𝑆
Unit Aluminum Coal 15,900 lb
𝑁𝐶𝐴𝑅𝑆

0.093 ∗ 𝑊𝐶𝐴𝑅𝑆
Unit Freight 19,850 lb
𝑁𝐶𝐴𝑅𝑆

5.2.2 Brake Pipe Propagation Time

The brake pipe propagation time is the time it takes for the average auxiliary reservoir pressure
to reach equalization pressure following a service brake application from a fully charged brake
pipe. The brake pipe propagation time is affected primarily by the length of the brake pipe, the
location and type of control valves and vent valves along the length of the brake pipe, and the
ambient air conditions (temperature and pressure). This data is not provided to the enforcement
algorithm, although a reasonable assumption can be made about the relationship between the
length of the brake pipe and the length of the train, which is provided to the enforcement
algorithm. Therefore, the assumption for the brake pipe propagation time is based exclusively on
the train length. For the base enforcement algorithm, the following formula is used:
𝑇𝐴𝑃𝑃𝐿𝑌 = 12.22 + 0.0156𝐿𝑇𝑅𝐴𝐼𝑁 − 0.000000278𝐿2𝑇𝑅𝐴𝐼𝑁 Accide

Using the results of the simulation and field tests, it was determined that this formula produces a
brake pipe propagation time that is generally longer than the actual brake pipe propagation time.
To develop a formula that produces a more nominal assumption of the brake pipe propagation
time, a number of simulations were conducted for each unit train type over a variety of train
lengths. For each train type and length, the types of control valves on the cars and the ambient
air conditions were randomly varied according to the distributions developed for the enforcement
algorithm evaluation methodology. The results of these simulations were analyzed using train
length, and a best fit regression line was developed. From this analysis, the formula for
estimating brake pipe propagation time was revised from that in the base enforcement algorithm
to the following:
𝑇𝐴𝑃𝑃𝐿𝑌 = 13 + 0.01179𝐿𝑇𝑅𝐴𝐼𝑁 + 0.000000256𝐿2𝑇𝑅𝐴𝐼𝑁 (3)

5.2.3 Percent Operable Brakes

The assumption for percent operable brakes in the base enforcement algorithm uses the
minimum allowable percent operable brakes, 85 percent, per FRA regulation. This is a worst-
case assumption because trains with less than 85 percent operable brakes cannot be operated.
Before a train leaves its origin, a brake test is performed and if there are any inoperable brakes,
they must be repaired, or the offending car must be removed from the consist before it departs.
Thus, the minimum allowable percent operable brakes at the time the train departs from its origin

57
is 100 percent. If, along the train route, problems occur with the brakes on certain cars (e.g.,
stuck brakes, etc.), the crew is permitted to cut the brakes for up to 15 percent of the cars.
However, it is rare that any brakes are cut en route, and extremely unlikely that 15 percent of the
cars would have their brakes cut. Given this low probability, the assumption for percent
operable brakes was revised from 85 to 100 percent, which represents the nominal level. It
should also be noted that the adaptive brake efficiency routine, defined in Section 6.3, can
compensate for brakes cut in the train.

5.3 Improved Target Offset Function

The target offset function is used to add margin to the nominal stopping distance prediction to
ensure that the train will stop short of the target stopping location according to the statistical
probability and confidence specified. The amount of margin required to meet the specification is
dependent on the amount of variability in stopping distance for the given scenario, which is
further dependent on the characteristics of the specific scenario (e.g., train makeup, train speed,
etc.) Since these characteristics are constantly changing, it is not practical, nor feasible, to
compute the potential variability in stopping distance in real time each time a stopping distance
prediction is performed. Therefore, a target offset function is used to estimate the variability,
using the known characteristics of the scenario.
The following is the target offset function used in the base enforcement algorithm:
𝑂𝑓𝑓𝑠𝑒𝑡 = 145 + 0.025𝑉 + 0.5188𝑉 2 (4)

V is the current velocity of the train in mph. This target offset function has two primary
shortcomings. First, it does not take into account several factors, such as train makeup and track
grade, that can have a significant effect on the variability of stopping distance. This results in
excessive target offsets for scenarios where the variability may be much less, but for which the
function does not compensate. The other primary shortcoming is that the function generally
computes target offsets that are excessively large. Figure 8 shows a plot of the target offset
computed by the base enforcement algorithm target offset function against train speed. As the
plot shows, at a speed of 40 mph, the base enforcement algorithm will generate a target offset of
approximately 1,000 ft. This means that the algorithm will enforce an air brake application
1,000 ft prior to where it predicts a brake application is necessary to stop the train at the target
stopping location. Because the function is quadratic, the target offsets get even more excessive
as train speeds increase; at 60 mph, the target offset is approximately 2,000 ft.

58
 Figure 8. Base Enforcement Algorithm Target Offset Function

To compute the target offset to better represent the variability of the stopping distance for any
given scenario, Monte Carlo simulation techniques were used to quantify the variability of
stopping distance for a range of specific scenarios. Statistical analysis techniques were then used
to determine the target offset necessary to meet the safety objective probability limit of 99.5
percent for each of the specific scenarios, and these results were combined using multivariable
regression techniques to generate a function that estimates the required target offset for any
scenario.
For this process to be successful, it was necessary for the matrix of test scenarios to cover a
range of train types, train lengths, train loading conditions, train speeds, and track grades. The
simulation test matrix included 5 different types of trains, both loaded and empty, with head end
only and distributed power configurations, 10 different train speeds, and 8 different track grades.
The total number of test scenarios was 2,160, and 100 simulations were run for each scenario
with Monte Carlo variance of the parameters discussed in Section 2.2.4.
From the stopping distance simulation data, the target offset for each scenario was computed
using the mean of the distribution and the 99.5 percent quantile, one of the class of values of a
variate that divides the total frequency of the population into a given number of equal
proportions, as follows:
𝑇𝑎𝑟𝑔𝑒𝑡 𝑂𝑓𝑓𝑠𝑒𝑡 = 99.5% 𝑄𝑢𝑎𝑛𝑡𝑖𝑙𝑒 − 𝑀𝑒𝑎𝑛 (5)

Direct computation (empirical determination) of the 99.5 percent quantile for each scenario in
terms of parts-per-thousand was not possible given that the sample for each scenario was only of
100 data points. When estimating quantiles beyond the limit of the observed dataset, so-called,
extreme quantiles are found by use of the peaks-over-threshold method [15]. The tail of the

59
sample distribution is expanded via Monte Carlo simulation after fitting the tail to an appropriate
distribution.
To visualize the process of the peaks-over-threshold method, first, a lower limit is applied to the
upper tail of the distribution (in this case, the 90 percent quantile). This assigns 10 percent of the
data (10 data points of the 100 output per scenario) to the tail as the source of the Monte Carlo
expansion. The resultant required large sample size (in this case, 5,000 simulated sample points)
provides the statistical granularity that allows the desired extreme quantile to be estimated by
direct calculation. In short, the 95 percent quantile of the simulated 5,000 points (the tails’ 10
percent over the threshold) is equivalent to the 99.5 percent quantile of the original distribution.
This high-level overview of the peaks-over-threshold method gives the main steps of the process,
but it should be understood that there are further details to the steps which ensure its effective
application.
The Winsorized mean was used to calculate the target offset for each scenario because it reduces
the effect of the data in the distribution tail and provides a more accurate estimate of the true
mean, using the main body of the distribution [14]. Winsorizing is accomplished by changing
the highest and lowest x percent to the next smallest or highest value in the distribution,
respectively; 5 percent was selected as the “trimming” threshold. In this case, the Winsorized
mean with a 5 percent threshold was found by replacing the bottom 5 percent of the ranked
values (s1, s2, s3, s4, and s5) with the next higher adjacent value in the distribution (s6). Likewise,
the top 5 percent (s96, s97, s98, s99, s100) were replaced with the next lower adjacent value (s95).
After determining the target offset values for each of the simulated scenarios, regression models
were built to predict the target offset for any scenario, using those simulated. Regression models
are a method of expressing the underlying statistical relationships between two or more
independent variables (predictors or contributors) in predicting a dependent (response) variable.
Thus, certain aspects of a specific train type and configuration were used as significant
contributors for predicting the dependent target offset value. Specifically, multiple linear
regression models were determined from the related independent variables (e.g., train speed,
track grade, and train weight), which provide for relatively uncomplicated models to predict the
target offset by train type, loading condition, locomotive arrangement within the train consist,
etc.
Multiple linear regression models reflect the tendency of the dependent variable (target offset) to
vary linearly with two or more of the predictor variables in such a way that a scattering of points
randomly about a regression curve denotes an inherent relationship between such variables. The
optimum model is fit to the data using a least squares method (multiple commercial software
packages are available to accomplish this). The process also determines the significant
contributor variables, input variable interactions, and their order of importance. This prevents
the use of redundant factors that complicate the model without improving prediction accuracy
[22]. For example, train length, train weight, and number of axles are generally redundant,
particularly for unit train types, where the trains are either fully loaded or empty.
The usual application of regression modeling estimates the mean performance of a stochastic
dependent output variable given the input variables. Because the output of interest is the 99.5
percent quantile for target offset, these are the input dependent values for which the regression fit
is calculated. The mean prediction for the 99.5 percent quantile of the target offset is the result

60
of applying the model. A 95 percent confidence or prediction interval band was calculated for
the regression line, giving quantifiable confidence evaluations for the model.
Using this process, several functions were developed to define the best fit overall target offset
function, dependent on loading condition and power configuration. Each is a function of train
velocity, v, the equivalent constant grade over the predicted stopping distance, g, the trailing
weight in tons, WCARS, and the total length of the train in feet, LTRAIN. The equivalent constant
grade over the predicted stopping distance is a computed value to convert undulating grades into
an equivalent constant grade, to simplify the target offset function.
For empty unit freight trains, the target offset, TO, is equal to:
𝑇𝑂 = (0.326𝑣 − 1.358𝑔 + 0.000573𝑊𝐶𝐴𝑅𝑆 + 0.000103𝐿𝑇𝑅𝐴𝐼𝑁 − 0.891)2 (6)

For loaded unit freight trains, the function used to determine the target offset is dependent on the
power configuration. For loaded unit freight trains with distributed power, the target offset, TO,
is equal to:
𝑇𝑂 = (0.465𝑣 − 2.071𝑔 + 0.0000287𝑊𝐶𝐴𝑅𝑆 + 0.000145𝐿𝑇𝑅𝐴𝐼𝑁 + 0.709)2 (7)

For loaded unit freight trains with head end power, the target offset, TO, is computed from one
of three equations, depending on the equivalent constant percent grade over the predicted
stopping distance, g:
𝑇𝑂𝐷𝐸𝐶 , 𝑖𝑓 𝑔 ≤ 0
𝑔 𝑔 (8)
𝑇𝑂 = ��1 − 0.5� ∗ 𝑇𝑂𝐷𝐸𝐶 + 0.5 ∗ 𝑇𝑂𝐼𝑁𝐶 , 𝑖𝑓0 < 𝑔 < 0.5
𝑇𝑂𝐼𝑁𝐶 , 𝑖𝑓 𝑔 ≥ 0.5

Where the values for incline and decline are determined from the following two equations:
𝑇𝑂𝐷𝐸𝐶 = (0.536𝑣 − 2.97𝑔 − 0.000147𝑊𝐶𝐴𝑅𝑆 + 0.0013𝐿𝑇𝑅𝐴𝐼𝑁 − 3.698)2
(9)
𝑇𝑂𝐼𝑁𝐶 = 𝑒 0.0774𝑣−0.911𝑔+0.0000104𝑊𝐶𝐴𝑅𝑆 +0.0000566𝐿𝑇𝑅𝐴𝐼𝑁 +2.933

The use of this target offset function results in a target offset that is more closely related to the
specific characteristics of the scenario at the time the stopping distance prediction is made. The
target offset function is also designed to produce a result that will ensure the 0.995 probability of
stopping short of the target, without additional unnecessary conservatism. In many of the cases
tested, the resulting target offset is significantly smaller than the target offset produced by the
base enforcement algorithm, further indicating the inefficiency of the original target offset
function.

5.4 Modeling of the Air Brake System

As identified in Section 4.3, the logic in the air brake model of the base enforcement algorithm
produces results that are inconsistent with some of the observed simulation and field testing

61
results. Therefore, a thorough review of all of the logic within the air brake model was
performed, and a variety of improvements were made.
The logic in the air brake model seeks to estimate the amount of force applied by the brake shoes
in the train at any given time, both in real time and in the stopping distance prediction routine.
The logic uses modeling the air brake system as a state machine, where the state of the brake
system is determined from the previous state and changes to the inputs and the computed air
brake parameters. From the state of the air brake system, the air brake parameters, such as
average auxiliary reservoir pressure and average brake cylinder pressure, are computed and used
to determine the brake shoe force. In general, this design was kept intact, but many of the
methods for computing the air brake parameters using simulation and test results were modified,
with the objective of making the logic more accurate, as well as simpler and easier to follow. In
certain cases, empirically derived formulas were replaced by more deterministic mathematical
models, and unnecessary intermediate parameters were eliminated. The redesigned air brake
model can be found in the algorithm definition document (Appendix F).

62
6. Adaptive Functions
The first of the developmental functions researched in this project were adaptive functions. One
of the primary issues with the base enforcement algorithm that contributes to the operational
inefficiencies experienced is the reliance on assumed data for items that are not known by the
enforcement algorithm. The objectives of the adaptive functions are to improve the stopping
distance prediction and reduce the variability of the stopping location from that prediction by
measuring key performance characteristics of the train and adapting the algorithm to predict the
stopping distance from these characteristics rather than relying on the assumed values.
When train crews slow a train to a stop, they generally will start with a minimum level of
braking to get a feel for how the train responds to the brake application and then supplement with
additional brakes, as necessary, to bring the train to a safe stop. With PTC brake enforcement,
this gradual stop is not an option because the system waits until a full penalty brake application
is necessary to stop the train short of the target. The adaptive functions therefore allow the
enforcement algorithm to get a “feel” for how the train responds to a brake application before the
penalty enforcement occurs.
The concept of using adaptive functions was initially investigated in a previous work effort
reported to FRA [1]. At the conclusion of that project, issues with, and potential improvements
to, the concepts developed were identified. In this project, the functions developed were
enhanced and implemented in the improved base enforcement algorithm and tested to
demonstrate the improvement achieved.

6.1 Overview of Adaptive Functions

The adaptive functions are intended to provide more accurate data to the stopping distance
prediction than is initially provided for some of the assumptions that can vary the most
significantly. From research conducted in the previous proof-of-concept project, the following
three areas were identified:
• Brake pipe propagation time — This is defined as the time from when the penalty air
brake application is initiated to when all cars in the train have reached equalization
pressure, or full penalty brake force. This can vary widely from the assumed value, with
varying brake pipe lengths and control valve types.
• Train weight — The weight of the train can be determined in various ways prior to
initializing the enforcement algorithm, but rarely is a scaled weight used. This
inaccuracy can lead to significant errors in estimating the resistance of the train.
• Brake efficiency — This is defined generally as the ability to stop the train during a
penalty brake application, and it is specified in the enforcement algorithm by the nominal
brake shoe force at a given brake cylinder pressure. Varying car brake system designs
and wear on the brake system components can contribute to significant variations from
the assumed values.
Although there are a number of other parameters that can vary from assumed values, as
discussed in Section 2.2.4, these three represent the most significant parameters that can be
practically measured. These parameters also compensate for a number of the other parameters
identified in Section 2.2.4. For example, the brake efficiency adaptive function not only corrects

63
for errors in the nominal brake shoe force, but also compensates for errors in the percentage of
operable brakes, among others.
Each of these three train characteristics can be measured using data generally available to the
enforcement algorithm. By interpreting the data in certain situations, it is possible for the
algorithm to use the response of the train to estimate characteristics used in the stopping distance
calculation. The variability of each of these characteristics from the assumed value can be
considerable. The variability of each of these characteristics from the value measured by the
adaptive functions can be significantly less, because the variability depends on the accuracy of
the measurement, as opposed to the full range of possible values. In addition to improving the
nominal stop distance prediction, this reduction in variability can also work to reduce the amount
of target offset necessary.
The previous proof-of-concept research project demonstrated the merit of using the adaptive
functions to improve the operational efficiency of the enforcement algorithm. A number of
simulations and field tests executed during this effort demonstrated the potential benefits of
using these functions to improve the prediction and to reduce the variability in the resulting
distribution of stopping locations.
The project also concluded that the train weight adaptive function was superfluous, given that the
brake efficiency adaptive function could compensate for errors in train weight. During the
project, it was observed that if an overestimate of the train weight was provided, the brake
efficiency adaptive algorithm would estimate more brake force, which would balance the effect
of the overestimate of the train weight, and the resulting stop distance prediction would be very
close to that which would result if the correct train weight had been provided. One of the major
areas of concern regarding the train weight adaptive function was that it relied on an accurate
measure of tractive effort produced by the locomotives, which was identified as being difficult to
obtain. By eliminating the train weight algorithm and allowing train weight to be compensated
for by the brake efficiency adaptive function, this concern could also be eliminated. On the basis
of that conclusion, the train weight adaptive function was not used in the enforcement algorithm
developed in this project.

6.2 Brake Pipe Propagation Time Adaptive Function

The brake pipe propagation time adaptive function uses brake pipe pressures from the head and
rear of the train during a service brake application to estimate the actual brake pipe propagation
time for a PTC penalty enforcement. During the previous proof-of-concept project, it was
observed that there were many similarities in the response of the brake pipe pressure between a
service brake application and a penalty brake application, and these similarities were used to
define the algorithm. However, there were several issues with this algorithm that were identified
at the conclusion of the previous research effort, which were addressed in this project.
At the most fundamental level, the propagation time adaptive function measures two things:
• The delay between the initial brake pipe pressure reduction on the head end and the initial
brake pipe pressure reduction on the rear end
• The rate of brake pipe pressure reduction on the rear end, from the initial reduction until
the brake application is complete (i.e., when the brake pipe pressure at the rear end has
reached steady state)

64
It then calculates the PTC penalty enforcement brake pipe propagation time by assuming the
same initial delay between the head end reduction and rear end reduction and using the rate of
brake pipe pressure reduction on the rear end to determine the length of time before the rear end
brake pipe pressure would get to the point at which equalization would occur on the last car.
One of the challenges with the brake pipe propagation time adaptive function is in determining
when the brake application is complete, specifically when measuring the rate of brake pipe
pressure reduction on the rear end. If this is done improperly, the rate of rear end brake pipe
pressure reduction, and therefore the brake pipe propagation time, cannot be accurately
estimated. The brake pipe propagation time adaptive function developed in the previous project
assumed that, since the rear end brake pipe pressure is only reported when a reduction of 2 psi is
measured, if the rear end brake pipe pressure did not change for a period of 10 seconds after the
initial reduction, the brake application was complete. This resulted in several issues that were
not immediately identified. First, the time between 2 psi reductions in rear end brake pipe
pressure could be more than 10 seconds during a brake application for long trains. Second, in
certain ambient conditions, such as cold temperatures, the propagation of the brake signal is
slowed significantly, which can result in the time between 2 psi reductions in rear end brake pipe
pressure during the brake application. In either of these cases, the function would consider the
brake application to be complete and attempt to calculate the rate of rear end brake pipe pressure
reduction with an incomplete set of data, which generally leads to a poor estimation of the brake
pipe propagation time.
To correct this issue, the function was modified to identify the point at which the rate of rear end
brake pipe pressure changes from a constant rate of reduction to a constant brake pipe pressure.
This was done by comparing the time elapsed for the most recent 2 psi reduction against the
overall rate of reduction measured for the previous reductions. Using this methodology, the
point at which the brake application is complete is based on when the rate changes, and it is not
related to the rate of change itself. Therefore, even in extreme conditions, such as long trains or
cold temperatures, the function will correctly determine the point at which the brake application
is complete.
Another issue with the brake pipe propagation time adaptive function from the previous project
was that the rate of rear end brake pipe pressure reduction was calculated solely on the basis of
the point of the initial reduction in rear end brake pipe pressure and the point when the brake
application is complete, without using any of the points between. The issue is that the rate of
rear end brake pipe pressure reduction is not constant over the full range of the brake application.
The rate of reduction does not instantly change at either the beginning or end of the brake
application, but instead slowly transitions to a constant rate of reduction and then slowly levels
off at the completion of the application. By using only the first and last points of the reduction,
the rate of reduction may be estimated improperly. By using a least-squares line regression
method on all of the points throughout the rear end brake pipe pressure reduction, a more
accurate estimation of the rate of reduction can be obtained.
The final issue identified with the original brake pipe propagation time adaptive function relates
to how the brake pipe pressure levels off differently for a service brake application than for a
penalty brake application. During a service brake application, the locomotive engineer sets the
target brake pipe pressure by moving the automatic brake handle to the desired position. This
sets the pressure in the equalizing reservoir to the target brake pipe pressure, and the brake pipe
is then exhausted to match the target pressure in the equalizing reservoir. As the brake pipe

65
pressure approaches the target pressure, the rate of brake pipe pressure reduction slows and
tapers off. This means that there is some additional time for the brake cylinder pressure to reach
the target brake cylinder pressure. During a penalty brake application, the target brake pipe
pressure is atmospheric pressure, meaning the rate of brake pipe pressure reduction does not
slow and taper off until well past the point when the brake cylinder pressure reaches the target
brake cylinder pressure (equalization pressure). The additional time needed for the brake
cylinder pressure to reach the target for the service brake application does not occur with the
penalty application. To compensate for this, the rate of brake pipe pressure reduction measured
during a service brake application is adjusted by a slight factor before it is used to estimate the
propagation time for the penalty brake application. This additional adjustment factor was
developed from brake pipe pressure measurements taken for both service and penalty brake
applications for a number of different configurations.
Each of the modifications discussed in this section was documented in the enforcement
algorithm definition document and implemented in the test enforcement algorithm software for
testing and evaluation. The final definition of the function is included in the enforcement
algorithm definition document in Appendix F.

6.3 Brake Efficiency Adaptive Function

The brake efficiency adaptive function characterizes the response of the train to a service brake
application to better predict the response of the train to a PTC penalty enforcement. In
particular, it measures the acceleration of the train and uses it, along with assumed values for the
other forces acting on the train, in solving the equation of motion to estimate the amount of brake
force acting on the train. It then uses this estimated brake force to predict the amount of brake
force available for a PTC penalty enforcement. Although the function technically estimates the
train brake force, if there are errors in the other assumed forces acting on the train (e.g., resistive
force), the function will naturally compensate for these by predicting a larger or smaller brake
force, as appropriate.
There are several critical components to properly estimating the brake force using this
methodology. Measuring the acceleration accurately is the primary challenge to estimating the
brake force. The acceleration is calculated using measured speed data for the locomotive only.
Therefore, forces from slack action within the train can result in the calculated acceleration not
being representative of the acceleration of the train as a whole. Additionally, the speed data is
reported at infrequent intervals (1 Hz), meaning that the acceleration must be filtered to eliminate
spikes in the data, which requires that the brake application be held constant for long enough to
allow the filter to provide a good estimation of the actual acceleration.
Several modifications were made to the brake efficiency adaptive function from the previous
research project. The filter for the acceleration data was changed from a low-pass Butterworth
filter to a two-step averaging smoothing filter. The Butterworth filter implemented in the
original function produced undesirable end effects on the acceleration data. The acceleration
data used at the beginning and end of the dataset produced brake shoe force values that diverged
significantly from the mean value for the entire dataset because of the effect of the filter on these
end points. Initially, to handle this issue, the data at either end of the dataset were removed.
However, this resulted in additional acceleration data being required to have the same amount of
data for processing. Instead, the acceleration dataset was artificially extended, both by adding
samples with the mean value, and by adding samples extending the trend at the end of the data

66
sample. Neither of these techniques provided the desired result, so a new filter was designed that
averages the acceleration data in two steps. In the first step, the acceleration data is averaged
over the previous three data points to handle short-term spikes in the data. The averaged
acceleration dataset is then filtered according to a least-squares line regression method to further
smooth over the entire set of data. This method of filtering resulted in a far better estimation of
the actual acceleration over the entire dataset, and required less data to be collected to provide
the same level of confidence in the resulting brake force estimation.
The algorithm was also modified to take into account the relative efficiency of the brake rigging.
As brake cylinder pressure increases, the efficiency of the rigging also increases as the slack in
the rigging is taken up. This results in a nonlinear relationship between brake cylinder pressure
and brake shoe force. The relative efficiency of the brake rigging is the ratio of the efficiency at
a given brake cylinder pressure to the efficiency of the brake rigging at the penalty brake
cylinder pressure of 64 psi. This factor results in a more accurate prediction of penalty brake
shoe force from the estimated brake shoe force at any other given brake cylinder pressure.
The other modifications to the brake efficiency adaptive function were related to using the other
functions within the enforcement algorithm to provide better estimates to the function. For
example, in the original function, brake cylinder pressure was estimated from a simplistic model
using the current brake pipe pressure. Since brake cylinder pressure is already calculated in the
enforcement algorithm according to a more sophisticated model of the air brake system, this
value was incorporated to provide a better estimate of the current level of braking. Similarly, the
original function determined that the brake application is being held by waiting for 10 seconds
since the last change to the brake pipe pressure. Again, since the enforcement algorithm already
determines the state of the air brake system according to a more sophisticated model, the new
function simply waits until the enforcement algorithm determines that the brake system is in the
holding application state.
Finally, the brake efficiency adaptive function was modified to refine the brake efficiency
estimate using all data collected from any brake application, rather than only on a set number of
data points. This allows for the estimate to be improved upon as additional data becomes
available. The final function was documented in the enforcement algorithm definition document,
in Appendix F, and implemented in the test software application.

6.4 Field Testing Adaptive Functions

To evaluate the performance of the enforcement algorithm with the adaptive functions, the
enforcement algorithm was tested under a variety of scenarios, both with the base algorithm and
with the adaptive algorithm. Table 14 shows the test scenarios as well as the resulting average
stopping location, relative to the target, for both the base and adaptive algorithms. The
algorithms were tested without the target offset function, and without the other modifications to
the base algorithm, in order to provide a good indication of the improvement in the prediction
due solely to the adaptive functions.
As Table 14 shows, the train stopped closer to the target stopping location in all cases, but still
stopped short of the target in all cases. This indicates that the train used exhibited better braking
characteristics than indicated by the assumptions in the base algorithm. The adaptive functions
properly accounted for these characteristics and allowed the train to proceed closer to the target
before enforcing a penalty application.

67
 Table 14. Adaptive Function Field Test Results
Average Stopping Location Relative to Target
Test Conditions
(ft)
Speed
Consist Track Grade Base Algorithm Adaptive Algorithm
(mph)

74 Cars – Loaded 30 Decline -1,709 -1,182

74 Cars – Loaded 10 Flat -182 -87

40 Cars – Loaded 50 Flat -573 -191

28 Cars – Empty 30 Flat -459 -246

28 Cars – Empty 30 Decline -783 -399

68
7. Emergency Brake Backup
One of the highest priority developments for the enforcement algorithm, as expressed by the
railroad advisory group, was the emergency brake backup. This concept was seen by the
industry as having the greatest potential benefit to the operational efficiency of the enforcement
algorithm. One of the fundamental difficulties with PTC braking enforcement is that there is no
opportunity for feedback and adjustment to the braking process once it has been initiated. With
the concept of PTC braking enforcement, the enforcement algorithm must predict the stopping
distance of the train in the given scenario, using limited data and a wide range of unknowns, and
wait until the last moment before applying a full penalty brake application to stop the train short
of the limit. If the concept instead allowed for a brake application to be initiated, but then
allowed the system to use the feedback from the initial application to determine if additional
braking is needed, it would be possible to improve both the safety and operational efficiency of
the system. This is precisely the objective of the emergency brake backup function.

7.1 Overview of Emergency Brake Backup Concept

The benefit of incorporating emergency brake backup into the enforcement algorithm is that the
initial penalty brake enforcement does not need to be as conservative in order to meet the same
safety objective probability of stopping short of the target. If the enforcement algorithm assumes
some probability of enforcements will use an emergency brake application in addition to the
penalty brake application, it can assume that the probability of enforcements will not stop short
of the target stopping position with a penalty brake application alone. The benefit of
incorporating emergency brake backup into the enforcement algorithm is that the initial penalty
brake enforcement does not need to be as conservative in order to meet the same probability of
stopping short of the target. If the enforcement algorithm assumes some probability of
enforcements will use an emergency brake application (in addition to the penalty brake
application), it can assume that this probability of enforcements will not stop short of the target
stopping position with a penalty brake application alone. The target offset can therefore be
reduced. Although this would result in a higher probability of overshoot with a penalty
application alone, the emergency brake will be used to mitigate these overshoots. Figure 9
illustrates this concept.
The first (top) illustration in Figure 9 illustrates the target offset necessary to meet the safety
objective probability limit with penalty braking alone. The second (middle) illustration shows
the same distribution with a reduced target offset, resulting in the distribution shifting relative to
the target stopping location, with a larger probability of overshooting the target with penalty
braking alone. The third (bottom) illustration shows the distribution with the target offset used in
the second illustration, but with the emergency brake used to stop short of the target those that
overshot in the second illustration, resulting in the same probability of overshooting the target
stopping location as in the first illustration. As Figure 9 shows, the emergency brake backup
concept allows for the safety objective probability limit to be met, but with a reduced target
offset, and therefore, a less conservative enforcement algorithm than without it.

69
 Figure 9. Emergency Brake Backup Concept

The emergency brake backup function also improves the safety of the enforcement algorithm.
The emergency brake backup function is designed to apply the emergency brake any time the
penalty brake enforcement does not appear sufficient for stopping the train short of the target
stopping location. In essence, this provides a redundant check, with a different calculation
method, that the train is going to stop short of the target, which provides additional confidence
that the train will stop short of the target because the emergency brake will apply and add
additional brake force to the train if there is a situation where the train is going to overrun the
target with the penalty brake application.

7.2 Implementation Considerations for Emergency Brake Backup Function

The concept of adding an emergency brake backup to the traditional penalty brake enforcement
introduces some new implementation factors that must be considered. The first is the amount of
brake pipe pressure required to apply the emergency brake. When a service or penalty brake
application is made, air exhausts from the brake pipe at what is known as a service rate. The
brake pipe pressure is reduced at a relatively slow rate, and each control valve in the air brake
system responds by allowing air in the auxiliary reservoir to flow into the brake cylinder. When
an emergency brake application is made, air exhausts from the brake pipe at a much faster rate,
and it is this faster rate that triggers each control valve to allow air from both the auxiliary and
emergency reservoirs to flow into the brake cylinder, resulting in increased brake force. In order
for the control valves to recognize the brake pipe pressure exhausting at the faster rate, there
must be a sufficient amount of air in the brake pipe to exhaust. Although the exact amount of
pressure required could vary from one scenario to the next, tests with a small sample of train
consists indicate that the control valves could detect an emergency application reliably with 40
psi brake pipe pressure. Since a traditional penalty brake application exhausts the air in the
brake pipe all the way to atmospheric pressure, it is conceivable that, following the initial penalty

70
enforcement, there would not be enough air in the brake pipe to make an emergency brake
application when needed.
Although the brake pipe pressure exhausts all the way to atmospheric pressure during a penalty
brake application, because of the concept of equalization the brake cylinder pressure does not
continue to increase past a certain point. At the point the pressure in the brake cylinder equalizes
with that in the auxiliary reservoir, no additional air will flow from the auxiliary reservoir to the
brake cylinder. Because of the volume relationship between the auxiliary reservoir and the brake
cylinder, this will occur at a pressure greater than atmospheric pressure. The equalization
pressure can be identified using Boyle’s Law, which states that the product of the volume and the
pressure of a system must remain constant:
𝑉 𝑃 +𝑉 𝑃 =𝑉 𝑃 +𝑉 𝑃 (10)
𝐴𝑅 𝐴𝑅,1 𝐵𝐶 𝐵𝐶,1 𝐴𝑅 𝐴𝑅,2 𝐵𝐶 𝐵𝐶,2

Where:
• VAR: Volume of auxiliary reservoir
• PAR: Pressure in the auxiliary reservoir
• VBC: Volume of the brake cylinder
• PBC: Pressure in the brake cylinder

Assuming the system is initially fully charged, meaning the initial brake cylinder pressure is
zero, and assuming that the final pressure is the pressure at which the auxiliary reservoir and
brake cylinder equalize, this equation simplifies to:
𝑉 𝑃 =𝑉 𝑃 +𝑉 𝑃 (11)
𝐴𝑅 𝐼𝑛𝑖𝑡 𝐴𝑅 𝐸𝑞𝑢𝑎𝑙𝑖𝑧𝑎𝑡𝑖𝑜𝑛 𝐵𝐶 𝐸𝑞𝑢𝑎𝑙𝑖𝑧𝑎𝑡𝑖𝑜𝑛

Where:
• Pinit: Initial pressure in the system
• PEqualization: Equalization pressure

Substituting the volume of the auxiliary reservoir to be 2.5 times that of the brake cylinder
results in:
2.5𝑉𝐵𝐶 𝑃𝐼𝑛𝑖𝑡 = 2.5𝑉𝐵𝐶 𝑃𝐸𝑞𝑢𝑎𝑙𝑖𝑧𝑎𝑡𝑖𝑜𝑛 + 𝑉𝐵𝐶 𝑃𝐸𝑞𝑢𝑎𝑙𝑖𝑧𝑎𝑡𝑖𝑜𝑛 (12)

Dividing both sides of this equation by the volume of the brake cylinder gives the relationship
between the initial auxiliary reservoir pressure and the pressure where the two will equalize as
follows:
2.5 5
𝑃𝐸𝑞𝑢𝑎𝑙𝑖𝑧𝑎𝑡𝑖𝑜𝑛 = 3.5 𝑃𝐼𝑛𝑖𝑡 = 7 𝑃𝐼𝑛𝑖𝑡 (13)

According to this equation, because of the volume relationship between the auxiliary reservoir
and the brake cylinder, the pressure in the two will equalize when it reaches 5/7 of the initial
pressure in the auxiliary reservoir. Exhausting the pressure in the brake pipe past this point will,
therefore, not result in any additional brake cylinder pressure or brake force.
To ensure enough air remains in the brake pipe for an emergency brake application, it would be
logical, from this analysis, to limit the penalty brake pipe pressure reduction to 5/7 of the fully

71
charged brake pipe pressure. However, if a case is considered where a service brake application
is made and then released, it can be seen that there are cases where the equalization pressure
could be lower than 5/7 of the fully charged brake pipe pressure.
When the brakes are released, the air compressor on the locomotive begins to charge the pressure
in the brake pipe. At each control valve, the air pressure in the brake cylinder is exhausted as
soon as the brake pipe pressure rises above the auxiliary reservoir pressure. However, it takes
much longer for the pressure in the brake pipe and auxiliary reservoir to build all the way back
up to the fully charged level. This could result in the system being less than fully charged at the
time the penalty brake is applied. The worst case would be to assume that the brake cylinder
pressure was exhausted instantaneously when the brakes were released following a full service
brake application. In this case, the pressure in the auxiliary reservoir would be at the
equalization pressure of 5/7 of the fully charged brake pipe pressure, and the brake cylinder
pressure would be zero. The equalization pressure from a penalty application at this point would
be 5/7 of the initial auxiliary reservoir pressure, which is already at 5/7 of the fully charged
auxiliary reservoir pressure:
5 5 5 1
𝑃𝐸𝑞𝑢𝑎𝑙𝑖𝑧𝑎𝑡𝑖𝑜𝑛 = 7 𝑃𝐼𝑛𝑖𝑡 = 7 ∗ 7 𝑃𝐹𝑢𝑙𝑙 ≈ 2 𝑃𝐹𝑢𝑙𝑙 (14)
Where:
• PFull: Pressure in the auxiliary reservoir when fully charged

Therefore, to ensure that (a) equalization pressure is reached from the penalty brake application
in any scenario and (b) there is enough brake pipe pressure remaining to initiate an emergency
brake application if needed, the brake pipe pressure reduction for a PTC penalty enforcement
should be limited to 1/2 of the fully charged brake pipe pressure. For a standard fully charged
brake pipe pressure of 90 psi, this would mean limiting the brake pipe pressure for a PTC penalty
enforcement to 45 psi, which is enough to initiate an emergency brake application, should it be
required.
The second implementation area for consideration with regard to the use of emergency brake as a
backup is the interface to the emergency brake. With the penalty brake, a brake test is performed
as part of the PTC system initialization to ensure the interface is operating properly. An
initialization test requiring an application of the emergency brake is not practical because the
time required to recharge the train from the emergency brake application would result in
significant operational delays. Currently, trains are dispatched with the assurance that the
emergency brake is operational; this assurance is provided by locomotive inspections that are
performed regularly by qualified locomotive technicians. It may be appropriate to inspect the
PTC system interface to the emergency brake as part of these inspections to ensure the
emergency brake is available when needed.

7.3 Evaluation of Safety Considerations Regarding Use of Emergency Braking

When the concept of using the emergency brake as a backup to the penalty was first introduced,
there was concern from some of the railroad community that use of the emergency brake as a
form of PTC enforcement could result in an increased probability of derailment during a PTC
enforcement. According to the figures in Section 3, there are approximately 410 authority
violations per year that would result in a PTC enforcement, which, using human factors analyses,
should be reduced to, conservatively, 32.8 per year with the addition of the onboard display and

72
audible warning. With the concept being that only a fraction of these enforcements would result
in an application of the emergency brake, this is a relatively small number of emergency brake
applications related to PTC enforcement, considering emergency brake applications occur on the
railroad every day for a variety of other reasons. Nevertheless, an analysis was performed to
evaluate any potential risks associated with use of the emergency brake.
The analysis consisted of modeling coupler forces throughout the train for a variety of scenarios,
using the TOES model to identify where the magnitude of those forces may be of concern. The
following three different operating scenarios were investigated during this analysis:
• Flat grade
• 1 percent constant decline grade
• Valley with undulating 1 percent grade
The flat grade provides a case where the locomotives are in throttle at the time of the brake
application, whereas the 1 percent constant decline provides a case where the locomotives are in
dynamic brake at the time of the brake application. For the valley case, the enforcement
application occurs with the front half of the train decelerating up the hill with dynamic brake in
use, while the back half of the train is in process of accelerating down the hill. This type of
scenario is expected to result in the most significant compressive (buff) forces, with potentially
the highest risk of causing a derailment.
The following five different train types were used in the modeling analysis:
• Loaded unit coal with distributed power, 130 cars, 4 locomotives
• Empty unit coal with distributed power, 130 cars, 4 locomotives
• Intermodal with head end power, 100 platforms, 3 locomotives
• Loaded mixed freight with head end power, 99 cars, 4 locomotives
• Empty mixed freight with head end power, 99 cars, 4 locomotives
In the case of the unit freight trains, the brakes were applied from both ends of the train with the
use of distributed power. In the other cases, with head end power only, the penalty was applied
from the head end, while the emergency was applied from both ends through the two-way end-
of-train device. In the case of the loaded mixed freight train, a mix of loading conditions was
used, and a significant number of cars were equipped with end of car cushioning draft gear
devices in both mixed freight trains, which can contribute significantly to longitudinal motion,
increased coupler forces, and derailment risk.
For each train and operating scenario discussed above, three different types of brake applications
were modeled, as follows:
• Penalty brake application
• Emergency brake application
• Penalty brake application followed by emergency brake application after 25 seconds
The penalty brake application provides a baseline level of coupler forces against which to
compare the emergency scenarios, since this form of enforcement is generally accepted from the

73
standpoint of increased risk of derailment related to PTC enforcement. The emergency brake
application is intended to demonstrate the worst potential scenario, and the penalty brake
application followed by an emergency brake application after 25 seconds is intended to
demonstrate a probable scenario where the emergency brake would be used as a backup to
prevent a target overrun.
Figure 10 shows the maximum compressive (buff) force in the train for each combination of
train, operating scenario, and type of brake application. It can be quickly observed from Figure
10 that the highest buff forces resulted from operating with dynamic brakes through the valley
grade at the time the brake application was made. It can also quickly be observed that of the five
different train types, the intermodal trains exhibited the lowest coupler forces. This is logical,
given that the intermodal train consists of a large number of longitudinally rigid (solid),
rotationally free connections (between the platforms of each articulated car), resulting in far less
free slack than in the other train types.

Figure 10. Maximum Coupler Forces Resulting from Brake Applications

Figure 10 also shows that, for the coal trains, the emergency application resulted in the highest
coupler forces, whereas the penalty application resulted in the highest coupler forces for the
other train types. This is a result of the two-way activation of the emergency brake. In the case
of the unit trains, both the penalty and emergency brake applications occur from both ends, with
the use of distributed power. In the case of the other train types, the penalty occurs from the
head end only, but the emergency occurs from both ends, with the use of a two-way end-of-train
device. Applying the brakes from both ends helps to control the slack in the train, particularly
for the valley case, where the head-end application of the brakes helps to decelerate the train
faster, while the rear of the train continues to accelerate, creating a run-in event. Because of the

74
two-way application of the emergency brake, the coupler forces generated were shown to be
generally smaller with the application of the emergency brake than with the application of the
penalty brake from the head end only.
The largest coupler forces observed from the brake applications modeled were just over 300,000
lb (311,479 lb was the overall maximum, which occurred with an emergency brake application
with the loaded coal train operating through the valley grade), which is not an overly alarming
level of compressive force on the coupler. To put this in perspective, modern locomotives can
apply approximately 100,000 lb of dynamic brake force each, which means if three locomotives
were operating at the head end of a train, the first coupler in the train would see approximately
the same coupler force of 300,000 lb.
There is no specific coupler force threshold above which derailment can occur. Rather, there are
a number of contributing conditions that will result in a derailment. For example, if an empty car
were to see a high coupler force while negotiating a relatively sharp curve or through a turnout, it
could result in the car being forced off the rail or into a wheel-climb situation. However, the risk
of derailment for a loaded car in the same situation, or the empty car on a tangent section of
track, may be relatively low, despite experiencing the same coupler force. The results of the
analysis performed do not show any indication that the use of the emergency brake as a backup
to the penalty brake during a PTC enforcement scenario will result in increased risk of
derailment or other safety issues.

7.4 Development of Initial Emergency Brake Backup Function

Initially, the emergency brake backup concept was designed to monitor the stopping progress of
the train by measuring the acceleration of the train and using it to determine if the train would
overshoot the target stopping location with the penalty brake application alone. In this design,
the acceleration of the train is measured as the penalty brake is applied and is used to predict the
acceleration profile for the remainder of the train stop. The acceleration profile is then used to
predict where the train will stop with the current penalty brake application. If this prediction
indicates that the train is still going to overshoot the target, the emergency brake is applied.
As with the brake efficiency adaptive function, the first challenge with this design is accurately
measuring the acceleration of the train. In order to develop an accurate prediction of the
stopping profile of the train, the raw acceleration data must be filtered to smooth out the spikes in
the data related to the resolution and low frequency of data acquisition. The same method of
filtering that was applied to the brake efficiency adaptive function was also applied to the
emergency brake backup function. The most recent 3 raw acceleration data points are averaged
and then the most recent 16 averaged acceleration data points are subjected to a least-squares
regression method to determine the current acceleration of the train.
The next challenge is to predict the acceleration profile of the train going forward, given the fact
that the brakes on the train are still in the act of applying, meaning the full force of the brakes has
not yet been attained. In order to do this, the brake shoe force is calculated at each of the most
recent 10 data samples, using the filtered acceleration and the estimated other forces acting on
the train. The rate of change of the brake shoe force over this period is then determined using a
simple linear regression formula. The brake shoe force profile is assumed to follow this rate of
change up to the point where the brakes are fully applied. This brake shoe force profile is then
used to predict the acceleration and speed profile for the rest of the penalty brake application.

75
Because this method of predicting the stopping location of the train is subject to various
anomalies in the measured data, the emergency brake was designed only to apply when the
average position for the most recent five predictions is beyond the target, and those predictions
are within 200 ft. This method was tested using TOES simulations and was shown to have
reasonable results. In all cases tested, the emergency brake was applied when necessary, and it
was not applied when the penalty brake application was sufficient to stop the train. The function
was documented and implemented in the test enforcement algorithm software for field
evaluation.

7.5 Field Testing Emergency Brake Backup Function

To verify the proper operation of the emergency brake backup function with field testing, special
field test procedures were necessary. The emergency brake backup function is designed to apply
the emergency brake only in cases where the penalty brake application alone is not sufficient to
stop the train short of the target. Typically, this will occur when conditions are extreme; for
example, a train with braking characteristics far worse than typical. Given that the equipment
available for field testing does not exhibit these worst-case type characteristics, the response of
the train to the penalty application would be sufficient to stop the train without an emergency
brake application. Therefore, to test the emergency brake backup function, the assumption
within the enforcement algorithm for the amount of brake force available on the train was raised
to a value far higher than that actually available on the test train. This resulted in the
enforcement algorithm delaying the application of the penalty brake, such that an emergency
brake application was necessary to prevent a target overrun.
The key criteria for evaluating the emergency brake backup function is that it (a) applies the
emergency brake to stop the train short of the target when the penalty brake application would
otherwise not, and (b) does not apply the emergency brake when the penalty brake application
will stop the train short of the target without an emergency brake application. Therefore, two
types of field tests were conceived:
• Overshoot — The brake force assumption within the enforcement algorithm was
modified so that the train would stop approximately 200 ft beyond the target following a
penalty brake application. This test is designed to address the first criteria.
• Undershoot — The brake force assumption within the enforcement algorithm was
modified so that the train would stop approximately 200 ft short of the target following a
penalty brake application. This test is designed to address the second criteria.
The value to which to set the brake force assumption in each case was determined through
simulations conducted prior to executing the field tests.
Given the two types of tests, the emergency brake backup function was evaluated for a number
of operating scenarios and compared against the results with the base enforcement algorithm.
Table 15 provides a list of the test scenarios and the results of each. The base enforcement
algorithm results indicate where the train stops in each test scenario without the emergency brake
backup function. The base algorithm stopped beyond the target in all of the overshoot cases and
stopped short of the target in all of the undershoot cases, as designed.
Table 15 shows that the emergency brake backup function applied the emergency brake in all of
the overshoot cases. In all but one case, the train stopped short of the target when the emergency

76
brake was applied. In the case that failed to stop the train short of the target, a run-in event
occurred at the point at which the algorithm would have initiated an emergency brake
application. This run-in caused severe fluctuations in the acceleration and in the predicted
stopping distance. Because the algorithm could not get a fix on the actual stopping location of
the train during this time, the application of the emergency brake was delayed until the
acceleration settled, resulting in the emergency being applied too late. This issue, among others
associated with the emergency brake backup function, is addressed in Section 7.6.
Table 15 also shows that the emergency brake was not applied in any of the undershoot cases.
This indicates that the function only utilizes the emergency brake when the penalty application is
not sufficient to stop the train short of the target, and not in other cases where it is unnecessary.

Table 15. Emergency Brake Backup Function Field Test Results

Average Stopping Location Relative to
Test Conditions
Target (ft)
Speed Track Emergency Brake
Consist Test Case Base Algorithm
(mph) Grade Backup

40 Cars – Loaded 30 Decline Overshoot 100 -600

40 Cars – Loaded 30 Decline Undershoot -200 -200*

40 Cars – Loaded 50 Flat Overshoot 200 -40

40 Cars – Loaded 50 Flat Undershoot -200 -200*

90 Cars – Loaded 30 Decline Overshoot 200 -200

90 Cars – Loaded 30 Decline Undershoot -175 -175*

90 Cars – Loaded 30 Flat Overshoot 200 120

90 Cars – Loaded 30 Flat Undershoot -200 -200*

* Emergency brake was not applied

7.6 Development of Improved Emergency Brake Backup Function

Although the results from both simulation and field testing indicated reasonable performance,
several issues were identified with the initial emergency brake backup design. First, because of
the initial time it takes for the brakes to begin to apply, the rate of change of the brake shoe force
cannot be reliably measured until several seconds after the penalty brake application. Second,
because of the filtering necessary on the acceleration data, the function cannot begin to predict
whether an emergency brake application is necessary or not until well into the penalty
application. Third, because of slack run-in events that are typical following a penalty brake
application for many scenarios, the acceleration data many times exhibits large anomalies that
require sophisticated methods to identify and handle. Finally, because the function is designed to
apply the emergency as soon as it is confident the penalty application is not sufficient, in many
cases the emergency was applied so early that the train stopped well short of the target. Because

77
of these deficiencies, the emergency brake backup function was redesigned using a different
overall concept.
In the original concept, the function attempted to refine the stopping distance prediction with the
penalty brake application, using empirically measured data. In the redesigned concept, the
emergency brake profile of the train is computed and the stopping location is compared with the
target to determine if the emergency brake is necessary. Because emergency braking can stop
the train much faster than penalty braking, a more conservative emergency brake profile can be
used to ensure that it will stop the train short of the target, without being applied when the
penalty alone is sufficient. Using this concept, there is no dependency on measuring and
filtering data, and the emergency will not be applied until it is absolutely necessary, resolving the
issues identified with the original concept.
The development of the improved emergency brake backup function parallels many of the
functions of the penalty brake prediction function. As with the penalty brake prediction, the
function estimates the forces acting on the train at each time step of the prediction loop, which
are then used to estimate the acceleration, velocity, and location. For the emergency brake
prediction, the brake pipe pressure is assumed to reduce by 40 psi each second of the prediction.
This forces the air brake model in the enforcement algorithm to respond as if an emergency
brake application is underway, modeling the brake force accordingly.
To ensure that the emergency brake prediction is conservative, the brake force estimated by the
air brake model is adjusted to 90 percent of the estimated value at each time step of the
prediction loop. This adjustment value is intended to be system configurable, so that it and the
penalty prediction target offset function can be adjusted to allow a higher or lower percentage of
penalty brake enforcements that result in an emergency brake application, using simulation or
empirical data. The 90 percent value results in a conservative prediction that ensures the
emergency brake application is sufficient to stop the train short of the target.
The improved emergency brake backup function is documented in the enforcement algorithm
description document in Appendix F. This function was also implemented in the test software
for evaluation. In the initial project plan, it was expected that any modifications to any of the
functions would be made prior to field testing the function. However, in the case of the
emergency brake backup function, many of the deficiencies were not identified until analyzing
the results of the field testing. Therefore, the project budget could not support an additional field
test period dedicated to evaluating the improved function. However, the improved function was
evaluated in the simulation test process for all three phases of development, as discussed in
Sections 9, 12, and 15. The improved emergency brake backup function was also implemented
in the software used during the field tests for each of the functions developed during Phases 2
and 3, which allowed for some level of indirect evaluation. As described in the sections for field
testing each of these functions, the emergency brake backup did not apply when not necessary
and was used successfully to mitigate certain other system faults, such as a failure of the
dynamic brakes at the time the penalty brake was enforced.

78
8. Distributed Power
A significant percentage of freight trains operate with distributed power today. Distributed
power refers to arranging groups of locomotives, known as locomotive consists, in various
locations throughout the train. For example, a common distributed power configuration is to
have one locomotive consist located at the head end of the train and another locomotive consist
located at the rear end of the train. The locomotive engineer will typically operate the train from
the lead locomotive at the head end of the train. The lead locomotive in the remote (distributed
power) locomotive consist(s) receives control setting and brake system commands from the lead
locomotive of the head end locomotive consist via signals over a radio frequency link. The other
locomotives in each locomotive consist receive control setting commands from the lead
locomotive in the locomotive consist via the 27-pin multiple-unit (MU) cable, and the brake
systems are set up to operate as trailing units, as in typical operations. The remote (distributed
power) locomotives can be set up to operate synchronously, meaning they follow the same
control and brake settings as the lead locomotive, or asynchronously, meaning the locomotive
engineer gives the remote locomotives commands independent of the commands given to the
lead locomotive. When a PTC penalty brake enforcement is initiated at the head end, the brakes
are applied at each locomotive consist, regardless of the mode of operation.
Distributed power offers several operational advantages over operating with head end power
only, including improved control of the slack action within the train, reducing force on the
couplers at the head end of the train, the capability to operate longer trains, and improved brake
application and recharge times. With distributed power, the brakes are applied by exhausting the
pressure from the brake pipe at each locomotive consist, rather than only from the lead
locomotive. This results in a faster propagation of the air brake signal to the cars, and, therefore,
a faster application of the brakes, which can have a significant effect on the stopping distance of
the train. Understanding the effect of distributed power on the braking performance and
incorporating this into the enforcement algorithm is crucial to reducing operational inefficiencies
associated with PTC enforcement for these types of trains.

8.1 Overview of Enforcement Algorithm Issues Associated with Distributed

Power
Traditionally, the reduction in brake application time for trains operating with distributed power
has not been incorporated into PTC enforcement algorithms, meaning they assume the
propagation time from the head end only. This can result in a significantly conservative
prediction of the train braking distance for trains operating with distributed power. Figure 11
illustrates this issue with the results of TOES simulations for a typical example, a loaded, 135-
car unit aluminum coal train operating on flat grade at 50 mph. The blue curve shows the
stopping distance for this train operating with four locomotives at the head end only, a distance
of 5,208 ft. The red curve shows the stopping distance for the same scenario, but operating with
two locomotives at the head end and two locomotives at the rear end, a distance of 4,208 ft,
1,000 ft shorter than the case with head end power only. If the enforcement algorithm assumes
for this train operating with distributed power that the brake pipe pressure is exhausted from the
head end only, the prediction will be 1,000 ft more conservative than necessary, assuming all
other assumptions within the algorithm are accurate. As this example shows, the assumption that

79
all brake applications are propagated from the head end only contributes significantly to the
operational inefficiency of the enforcement algorithm.

Figure 11. Comparison of Penalty Braking Distance with Head End Power and
Distributed Power for Loaded 135-Car Unit Aluminum Coal Train on Flat Grade

8.2 Evaluation of Safety Considerations Regarding Distributed Power

Communications Failures
One of the reasons that PTC enforcement algorithms may traditionally not have incorporated the
benefit of distributed power is because the distributed power communications link can fail in
certain circumstances, resulting in a potentially unsafe scenario if the enforcement algorithm
assumes the distributed power link is active. This issue is manageable, however, by using
feedback on the distributed power communications link status from the locomotive, and with the
addition of the emergency brake backup function. If the enforcement algorithm uses the status of
the distributed power communication link, it can assume distributed power propagation time if
the status is active and the head end only propagation time if the status is inactive for any reason.
The only remaining issue arises in a situation where the distributed power communications status
changes from active to inactive after the enforcement algorithm would have initiated a penalty if
the status had been inactive at the time. In this case, the penalty would be initiated as quickly as
is practical, but may be insufficient for stopping the train short of the target, if the distributed
power communications link is not quickly restored. However, the emergency brake backup
function, which would consider that the distributed power link is inactive, would apply the
emergency brake to stop the train safely short of the target.
Figure 12 illustrates conceptually how the emergency brake backup function can be used to
mitigate the safety concern with distributed power communications link failure with the results
of TOES simulations for a typical example, a loaded, 135-car unit aluminum coal train operating

80
on flat grade at 50 mph with distributed power. In the figure, the blue curve shows the stopping
profile for this train if the algorithm assumes no distributed power even though the train is
actually operating with distributed power, as traditionally assumed by PTC enforcement
algorithms. The red curve shows the stopping profile if the algorithm assumes the train is
operating with distributed power. In this case, the PTC enforcement would take place
approximately 1,000 ft later than if no distributed power is assumed by the algorithm. The green
curve shows the stopping profile if the algorithm assumes the train is operating with distributed
power, but the distributed power communications link fails right at the point of enforcement. In
this case, the point of enforcement is the same as the red curve, but the stopping distance is the
same as in the blue curve. The result is that the train stops approximately 1,000 ft further than
the algorithm predicted because it incorrectly assumed that distributed power would be active.
Finally, the purple curve in the figure shows the stopping profile of the train if the algorithm
assumes the train is operating with distributed power; the distributed power communications link
fails right at the point of enforcement, but the algorithm uses the emergency brake to stop the
train at the point it originally predicted. In this case, the emergency brake was applied 23
seconds after the penalty brake was applied, in order to stop the train at approximately the same
location as if the distributed power communications link had been active.

Figure 12. Comparison of Stopping Locations with Distributed Power

Communications Failure and Emergency Brake Backup

The key to using the emergency brake as mitigation for the safety concern with cases where the
distributed power communications link fails is that the emergency brake applied from the head
end only will always stop the train at a shorter distance than the penalty brake applied from
multiple locations within the train, and this is because an emergency brake application is
approximately 5 times quicker than a penalty brake application. Therefore, if the communication
link for distributed power fails after the location of enforcement for a head end only train, the
emergency brake will apply and still stop the train short of the target.

81
8.3 Development of Enforcement Algorithm Modifications for Trains with
Distributed Power
To develop a function for properly handling the improved brake pipe propagation time with
distributed power, the relationship between the propagation time and the arrangement of the
locomotives within the train consist must be understood. The following two characteristics of
the arrangement of locomotives were identified as having the potential to affect the brake pipe
propagation time:
• Number of locomotive consists in the train — This defines the number of locations where
the air in the brake pipe is exhausted from during a penalty brake application.
• Distance between locomotive consists in the train — This defines the length of brake pipe
that the air must travel through to get to an exhausting locomotive during a penalty brake
application.
Parametric simulations with the TOES model were used to identify the relationships between
these characteristics and the brake pipe propagation time for a penalty brake application. Table
16 shows the TOES simulations run to determine how the brake pipe propagation time is
affected by the number of locomotive consists in the train. In each of the cases, a nominal train
was built consisting of identical standard 50-foot hopper cars, equipped with ABDW type control
valves. The number of cars, as well as the number and location of locomotive consists in the
train were varied according to the values indicated in Table 16. For each test case, a penalty
brake application was initiated at all locomotive consists, and the brake pipe propagation time
was measured.
Table 16. Simulation Tests to Determine Effect of Number of Locomotive Consists on
Brake Pipe Propagation Time
Train
Number of Location of Ratio of Train Length to Brake Pipe
Test Length
Locomotive Locomotive Number of Locomotive Propagation
Case (number of
Consists Consists Consists Time(s)
cars)
1 50 cars 1 Head End 50 41
2 100 cars 2 Head/Rear 50 41
3 150 cars 3 Head/Mid/Rear 50 41
4 100 cars 1 Head End 100 70
5 200 cars 2 Head/Rear 100 70

The results shown in Table 16 indicate that the brake pipe propagation time is directly related to
the ratio of the length of the train to the number of locomotives in the train, if the locomotive
consists are evenly distributed throughout the length of the train, and all else being equal. In
other words, the propagation time for a train operating with distributed power is equal to the
propagation time of an identical train, except shorter by a factor of the number of locomotive
consists, operating with head end power only.

82
The conclusions drawn from the results shown in Table 16 are intuitive. If there are locomotives
located only at the head end, the air has to travel the length of the train to exhaust from a single
location. If there are locomotives located at the head and rear of the train, the air can exhaust
twice as fast, as there are two exhausting locations. Finally, if there are locomotives located at
the head, middle, and rear of the train, the air can exhaust three times as fast, as there are three
exhausting locations, spaced evenly throughout the train. Although this is a significant
conclusion, the tests described in Table 16 do not cover cases where the locomotive consists are
not distributed evenly throughout the length of the train.
To evaluate the effect of the location of the locomotive consists within the train on propagation
time, the TOES simulations shown in Table 17 were run. For these tests, a nominal train was
built consisting of 100 identical standard 50-foot hoppers equipped with ABDW type control
brake valves. For one case, only locomotives at the head end were used, and for the other cases
two locomotive consists were used. The location of one of the locomotive consists was varied
from 10 cars behind the head end to the rear end of the train in 10 car increments, as indicated in
table 17. As before, a penalty brake application was initiated at all locomotive consists and the
brake pipe propagation time was measured.

Table 17. Simulation Tests to Determine Effect of the Location of Locomotive Consists,
within the Train, on Brake Pipe Propagation Time
Brake Pipe Propagation
Test Case Location of Locomotive Consists
Time (s)
1 Head End Only 70
2 Head End and 10 Cars Back 58
3 Head End and 20 Cars Back 56
4 Head End and 30 Cars Back 53
5 Head End and 40 Cars Back 50
6 Head End and 50 Cars Back 46
7 Head End and 60 Cars Back 44
8 Head End and 70 Cars Back 41
9 Head End and 80 Cars Back 41
10 Head End and 90 Cars Back 41
11 Head End and Rear End 41

The results in Table 17 indicate that there is a benefit to having multiple locomotive consists,
even if they are located very close together, but the benefit is greatest when they are separated by
70 percent or more of the train. Practically speaking, it is extremely unlikely that a train with
two locomotive consists would be assembled with the locomotive consists closer than 50 percent
of the length of the train, so test cases 2, 3, 4, and 5 are purely academic. With the locomotive
consists separated by half of the length of the train, the propagation time is approximately 12
percent greater than with the locomotive consists separated by the full length of the train.
Although this is not a trivial difference, this level of error in propagation time is far less than the

83
level of potential error in propagation time attributed to differences in control valves, ambient
temperature, and other factors. Because of this, combined with the fact that this configuration of
locomotive consists is rare, it was determined that the propagation time for trains operating with
distributed power could be estimated using the standard brake pipe propagation time formula for
a train with a length equal to the train length divided by the number of locomotive consists.
For trains operating with distributed power, it is still desirable to utilize the brake pipe
propagation time adaptive function to more accurately predict the brake pipe propagation time
for a penalty brake application. However, because the brake pipe pressure exhausts from
multiple locations, the rear of the train is not necessarily the point where equalization will occur
the latest, as in the case with head end power only. Therefore, the brake pipe propagation time
adaptive routine, which measures the brake pipe propagation time from the brake pipe pressure
at the rear of the train, cannot reliably be used to estimate the brake pipe propagation time with
distributed power being active.
If the brake pipe propagation time function is run with the distributed power cut out, however, a
measurement can be made, and then an adjustment factor applied when the distributed power is
cut in. Since it is envisioned that the brake pipe propagation time function would be run at train
initialization, during a departure brake test, such a measurement could be made prior to cutting in
distributed power. The brake pipe propagation time function would simply need to detect
whether or not distributed power is cut in and only perform the brake pipe propagation time
correction if it is cut out. When distributed power is cut in, the function would then apply the
distributed power correction factor and proceed with the corrected propagation time.
The correction factor is derived by assuming that the ratio between the measured propagation
time and the nominal estimated propagation time is the same for the same train operating with or
without distributed power. Using this assumption, the propagation time with distributed power
can be calculated as the nominal estimated propagation time with distributed power multiplied
by the ratio of the measured propagation time to the nominal estimated propagation time without
distributed power. For example, for a unit train with two locomotive consists that is 6,000 ft
long, the nominal estimated propagation time without distributed power would be 93 seconds
and the nominal estimated propagation time with distributed power would be 51 seconds
(according to the new equation in Section 5.2.2). If the adaptive function measures a
propagation time of 78 seconds for the train with distributed power cut out, the adaptive
propagation time for the train with distributed power cut in would be 51 x (78/93) = 43 seconds.
This method of calculating the correction factor was evaluated with TOES simulations for a
number of cases and was shown to provide a good estimate of the actual brake pipe propagation
time for these cases.

8.4 Field Testing Distributed Power Function

To verify the safety and performance of the distributed power function, a number of field tests
were conducted. The field tests covered a range of operating scenarios and were executed with
the base algorithm, the distributed power algorithm with assumed propagation time, and the
distributed power algorithm with adaptive propagation time. The tests were run without the
target offset function or the other modifications to the base algorithm, to provide an indication of
the improvement in the prediction between the three versions of the algorithm.

84
Table 18 shows the test scenarios as well as the average stopping location relative to the target
for each case and each version of the algorithm. The distributed power algorithm more
accurately predicted the propagation time for the train in all cases, which resulted in the train
stopping closer to the target, as shown in Table 18.

Table 18. Distributed Power Function Field Test Results

Test Conditions Average Stopping Location Relative to Target (ft)

Distributed Distributed Power

Speed Track Base
Consist Power Function with Adaptive
(mph) Grade Algorithm
Function Function

78 Cars – Loaded 30 Flat -786 -201 -2

78 Cars – Loaded 50 Flat -1188 -231 101

78 Cars – Loaded 10 Flat -150 -26 70

78 Cars – Loaded 30 Decline -1000 -254 272

60 Cars – Loaded 30 Flat -273 18 172

60 Cars – Loaded 30 Decline -949 -158 122

In some cases, target overshoots were observed, particularly when the adaptive propagation time
was used in conjunction with the new distributed power function, because neither the target
offset function nor the brake efficiency adaptive function was used, which would bias the
prediction accordingly. It is expected that, had the brake efficiency adaptive function be used in
these tests, the stopping location would have been much closer to the target, because the
prediction would have been much more accurate. It is also expected that, had the target offset
been used, the train would have stopped safely short of the target, as this train did not represent a
worst-case train. Finally, had the emergency brake backup function been used, the emergency
would have been applied to stop the train short of the target. These functions were removed to
provide a result that indicates the accuracy of the prediction related to the distributed power
function. All tests with the distributed power function were shown to stop within 300 ft of the
target; showing it more accurately represented the propagation time of the train than the base
algorithm did.

85
9. Evaluation of Phase 1 Developmental Algorithm
The Phase 1 developmental algorithm consists of all the modifications and additions to the base
algorithm described in Sections 5, 6, 7, and 8. This includes addition of train type input,
modification of key assumptions, improvement of the target offset function, modification of the
air brake model, and incorporation of adaptive, emergency brake backup, and distributed power
functions. Appendix F defines each of the Phase 1 algorithm functions, within the context of the
final developmental algorithm. Although the document included in Appendix F also includes
modifications and new functions developed in Phases 2 and 3, these were not in place during the
evaluation of the Phase 1 algorithm.
Simulation testing and analysis was performed on the Phase 1 algorithm using the methodology
described in Section 2.2. The Phase 1 algorithm was only tested with unit trains, because
improvements for manifest freight and intermodal freight trains were not incorporated until the
third phase of development. Table 19 shows the overall results of simulation testing for unit
trains with the Phase 1 algorithm. It shows the probability of stopping short of the target and the
probability of stopping short of the performance limit, defined as stopping short of the target by
less than 500 ft for speeds < 30 mph and 1,200 ft for speeds ≥ 30 mph. Appendix H contains the
detailed results from simulation testing of the Phase 1 algorithm.
Table 19. Phase 1 Algorithm Simulation Test Results
Probability of Stopping Short of Probability of Stopping Short of
Train Type Target Performance Limit

Unit Freight 99.69% 31.98%

The data in Table 19 shows the Phase 1 developmental algorithm maintains a probability of
stopping short of the target greater than the objective of 99.5 percent and reduces the probability
of stopping short of the performance limit to 31.98 percent from 83.57 percent in the base
algorithm. This demonstrates the positive improvement in the operational efficiency of the
enforcement algorithm, without impacting the level of safety, achieved through the modifications
and new functions incorporated during the first phase of development.

86
10. Locomotive Braking
When a penalty brake application is initiated, the brake pipe pressure is reduced to atmospheric
pressure at a service rate, which triggers the control valve on each car in the train to apply the
brakes on that car. On locomotives there is an additional feature known as the actuating feature,
which allows the locomotive engineer to release, or bail off, the locomotive brakes.
Locomotives produce far more brake force than a typical freight car during a penalty brake
application. As full application of the locomotive brakes can have undesirable effects, such as
high coupler forces and the potential to slide locomotive wheels, locomotive engineers are
trained to bail off the locomotive brakes to limit the amount of braking on the locomotives.
Bailing of the locomotive brakes becomes a reflex reaction when the train brakes apply.
Locomotives are also capable of independent braking, allowing the locomotive engineer to apply
some amount of locomotive brakes independently from the rest of the train, which can be useful
in certain scenarios. The combination of bailing off the automatic brakes and applying the
independent brakes on a locomotive allows the locomotive engineer the ability to very explicitly
control the amount of locomotive braking to a desired level.
Although the locomotive brake force is only a small fraction of the total amount of brake force
applied by the whole train during a penalty application for long trains, whether or not the
locomotive engineer bails the locomotive automatic brake and applies the locomotive
independent brake can have a significant effect on the stopping distance of short trains and light
locomotives. How these scenarios are handled by the enforcement algorithm can be an
important aspect of the system performance.

10.1 Background on Use of Locomotive Brakes during PTC Enforcement

The enforcement algorithm has no way of knowing what actions the locomotive engineer will
take following a PTC penalty brake enforcement. However, because of the potential risks with
allowing locomotive brakes to fully apply, it is common for locomotive engineers to reflexively
bail off the locomotive brakes when the automatic air brakes are applied. It is also reasonable to
assume that if the train were short enough to require locomotive brakes to stop the train in a
practical distance, the locomotive engineer would either not bail the locomotive brakes or would
apply some level of locomotive independent brakes. These assumptions form the basis for how
PTC enforcement algorithms have traditionally handled locomotive brakes.
In the base algorithm, there is a configurable parameter that defines the number of cars for a
“short” train. This number is used to determine whether locomotive braking will be assumed or
not during PTC enforcement. The value suggested in the base case documentation for this
parameter is eight cars. For trains with greater than eight cars, the enforcement algorithm
assumes that the locomotive brakes will be fully bailed and no brake force will be contributed
from the locomotives. For trains with eight or fewer cars, the enforcement algorithm assumes
that the locomotive brakes will be fully applied, with no bail.
Although the assumptions used for the base algorithm are reasonable in terms of predicting what
the locomotive engineer might do, there are obviously potential issues on short trains or light
locomotives if the locomotive engineer bails the locomotive brakes reflexively. Additionally, in
longer trains, if the locomotive brakes are not used to supplement the brakes on the trailing cars,
there is some level of braking available that is not being used (or assumed), which contributes to

87
additional algorithm conservatism. It should also be noted that, given the level of braking
available to the locomotives, scenarios with short trains and light locomotives are historically not
areas of high concern with regard to authority violations.

10.2 Development of Methodology for Handling Use of Locomotive Brakes

In order to ensure safe handling of short train and light locomotive scenarios, and provide
additional braking to help reduce the operational inefficiencies associated with early warnings
and enforcement for all trains, a consistent level of locomotive brakes must be applied for all
PTC enforcements. Using this logic, a method for ensuring a consistent level of locomotive
braking during PTC enforcement was conceived. In this concept, an appropriate level of
locomotive braking is selected, below which the locomotive engineer cannot bail the locomotive
automatic air brake application during a PTC enforcement. This requires either hardware and/or
software modifications to the locomotive brake system to implement, but allows the enforcement
algorithm to reliably predict the level of locomotive braking during the stopping distance
prediction to provide a more accurate prediction, and safely delay the point of enforcement to
give the locomotive engineer ample time to respond.
The key to this concept, other than the implementation challenge, is selecting an appropriate
level of locomotive brake cylinder pressure to limit the bailing to. The level of brake cylinder
pressure selected should be high enough that the operational impact to short trains and light
locomotives is minimal, but also low enough to not impact braking performance for longer
trains, or substantially increase the risk of locomotive wheel slide. It was determined that the
most logical solution was to select a locomotive brake cylinder pressure that would result in a
similar level of braking for the locomotives as for a typical freight car, relative to their weight.
Although the overall average net brake ratio for a freight car varies between the train types, the
need to get the level of locomotive braking to that level of precision is not necessary. Rather, it
is important to get the level of locomotive braking close to the level of braking for the freight
cars. Since a large majority of freight cars were designed to a loaded net brake ratio of between
8.5 percent and 13 percent, and it can be assumed that the net brake ratio can fade by up to 1
percent over time [7, 11], it is reasonable to select a nominal brake ratio of 10 percent for the
purposes of aligning the level of locomotive braking to the level of freight car braking.
The AAR specifies a minimum net brake ratio for locomotives equipped with single high-friction
composition brake shoes of 20 percent at 50 psi brake cylinder pressure [23]. Review of
locomotive brake rigging designs for various locomotives and discussions with experts in the
area of locomotive brake system design indicate that the gross brake ratio for a locomotive at 50
psi brake cylinder pressure can be as high as 30 percent, and that the efficiency of the locomotive
brake rigging can generally be assumed at 80 percent. The net brake ratio is the gross brake ratio
multiplied by the efficiency of the brake rigging. By taking the 80 percent efficiency factor into
account the resulting maximum net brake ratio is equal to 24 percent at 50 psi brake cylinder
pressure. The nominal net brake ratio can be assumed as the center of the range from the
minimum of 20 percent to the maximum of 24 percent, which is 22 percent at 50 psi brake
cylinder pressure. This equates to approximately a 28 percent net brake ratio at 64 psi brake
cylinder pressure. This value was assumed to be the nominal net brake ratio for a locomotive at
64 psi brake cylinder pressure.
Using the assumption of the nominal locomotive net brake ratio of 28 percent at 64 psi and the
nominal loaded net brake ratio of 10 percent at 64 psi for freight cars, a reasonable value for the

88
brake cylinder pressure below which the locomotive engineer cannot bail during a PTC penalty
application was selected as 10/28 x 64 ≈ 23 psi brake cylinder pressure. With the proper
hardware and/or software modifications made to the locomotive brake system, the system would
therefore not allow the locomotive engineer to bail the brakes to a brake cylinder pressure below
23 psi during a PTC penalty brake application. The brake system modifications would be
designed to still allow a full bail of the locomotive brake cylinder pressure during brake
applications initiated by the locomotive engineer or sources other than the PTC system. These
modifications allow the train to be handled as currently done in normal operating conditions, but
force a minimum level of locomotive braking during PTC enforcement, which improves the
accuracy of the stopping distance prediction, allows additional time for the locomotive engineer
to react before a PTC penalty enforcement occurs, and ensures that short trains and light
locomotives will not violate the target stopping location during PTC enforcement because of
reflexive actuation (bailing) of the locomotive brakes.

10.3 Field Testing Locomotive Brake Function

To test the concept of limiting the ability to bail the locomotive brakes during a PTC penalty
application, modifications were made to the braking system on one of the test locomotives. The
test locomotive was equipped with a pneumatic, 26-L brake system, allowing for hardware
modifications to be made to the pneumatic system. For test purposes, the brake system was set
up to automatically bail the locomotive brakes during the penalty brake application and reapply
the independent brake with a limiting valve controlling the amount of independent brake cylinder
pressure. Although actual implementations would still allow the locomotive engineer the ability
to bail, forcing an automatic bail allowed for test consistency.
The limiting valve on the brake system was set up to allow adjustment for varying levels of
brake cylinder pressure resulting from the application of the independent brake. A variety of
brake cylinder pressure settings were evaluated during some of the tests, to determine if there
were advantages or disadvantages to each. The following four locomotive brake cylinder
pressure settings were used:
• 12 psi — corresponds to a brake ratio of ~ 5.25 percent
• 18.5 psi — corresponds to a brake ratio of ~8.1 percent
• 25 psi — corresponds to a brake ratio of ~10.9 percent
• 35 psi — corresponds to a brake ratio of ~15.3 percent
The tests were performed using a short train consist with a single locomotive and four loaded
cars from the FAST train as well as a light engine consist with two locomotives. For each test
case, the base algorithm was compared against the developmental algorithm. For the base
algorithm tests, the locomotive brake cylinder setting was set to the 18.5 psi setting, which
represents a conservative nominal level of braking that a locomotive engineer might use to stop a
short train or light engine consist. For the developmental algorithm tests, the locomotive brake
cylinder setting was set to one of the four settings listed above, and the algorithm software was
adjusted to match.
Table 20 shows each of the test cases from the locomotive brake testing as well as the resulting
average stopping location relative to the target for each. The results in the table show the train
stopped further down the track with the base algorithm than with the developmental algorithm in

89
all cases, because the base algorithm assumes full automatic brake cylinder pressure for the
locomotive(s) during the penalty application when, in fact, the brake cylinder pressure was less
because of the partial bail. In some cases, this resulted in a target overrun. For the
developmental algorithm, which assumes the level of brake cylinder pressure selected by the
automatic bail function, the train always stopped short of the target.
For the cases where multiple locomotive brake cylinder pressures were tested, the stopping
location was consistent, regardless of which brake cylinder pressure was used. However, the
higher the brake cylinder pressure, the longer the algorithm could wait before applying the
penalty brake application. This suggests that a higher brake cylinder pressure would be desirable
to delay the application of the penalty. This may be appropriate for shorter trains, but for longer
trains, this higher brake force generated from the locomotives could result in undesirable train
action. Additionally, higher brake forces on the locomotive increase the risk of damage to
equipment, such as wheel flats from sliding wheels.

Table 20. Locomotive Brake Function Field Test Results

Test Conditions Average Stopping Location Relative to Target (ft)

Speed Track Base Loco Brake Function

Consist
(mph) Grade Algorithm 12 psi 18.5 psi 25 psi 35 psi

1 Locomotive,
4 Cars 60 Flat 45 -1425
1 Locomotive,
4 Cars 30 Flat -289 -586 -614 -620 -575
1 Locomotive,
4 Cars 10 Flat -163 -198 -201
2 Locomotives,
0 Cars 30 Flat -50 -336 -596 -596 -622
1 Locomotive,
4 Cars 30 Decline 27 -1227
2 Locomotives,
0 Cars 30 Decline 272 -855

This testing showed that this concept has merit for providing a safe method for ensuring that
short trains and light engine consists stop short of the target, even when the locomotive engineer
attempts to bail the automatic application. However, the complexities of implementing this type
of functionality in the various locomotive braking systems (both pneumatic and electronic)
combined with the relatively low risk associated with trains of this type, may mean that this
functionality is not practical or necessary to provide a safe system.

90
11. Dynamic Braking
Dynamic braking refers to the use of the locomotive traction motors to assist with slowing the
train. In essence, the traction motors are set to operate as generators with a large resistor grid
acting as a load to provide resistance to the rotation of the motor, which slows the locomotive.
The energy generated by the traction motors during dynamic braking is then dissipated as heat in
the resistor grid. Dynamic braking is generally available on road locomotives in the railroad
industry today and is used to supplement air braking during normal operations for a vast range of
operating conditions. Dynamic braking offers several benefits, including reductions in wear on
air brake system components such as brake shoes, consistent level of braking force on long
grades where the air brake force may fade as the wheels and brake shoes heat up, faster
application of the brakes, and improved control of the train.
The level of dynamic braking available is not consistent throughout the range of typical train
operating speeds. As the train speed increases past approximately 25–30 mph, the level of
dynamic braking available slowly decreases, and at low speeds the level of dynamic braking
available drops dramatically. More recently, what is known as extended range dynamic brakes
has been developed, which maintains a higher level of available dynamic braking force down to
approximately 5 mph, before it drops off. Dynamic braking is also not considered a fail-safe
form of braking, as air brakes are. With these deficiencies, dynamic braking has not replaced air
braking, but the benefits of dynamic braking, particularly with the advent of extended range,
have made it the primary method for slowing trains in the railroad industry today. In some cases,
dynamic braking is essential for trains descending extended grades, and by operating practice the
dynamic brakes must be checked prior to descending severe grades.

11.1 Overview of Issue with Assumption on Use of Dynamic Braking During

PTC Enforcement
Because the use of dynamic braking is so prevalent, the PTC enforcement algorithm must
consider that dynamic brakes may be in use to hold a train at a constant speed on a grade or to
stop a train short of a given target stopping location before determining that a penalty air brake
application is required. However, PTC enforcement algorithms to date have not considered that
dynamic brakes may be in use at the time of potential enforcement. Figure 13 illustrates the
issue without the use of dynamic brake when determining if a penalty brake application is
necessary to stop the train short of a given stopping target.
In the figure, braking profiles produced from TOES simulations are shown for a loaded, 135-car
unit aluminum coal train operating on a 1.1 percent decline at 25 mph. On this grade at this
speed, the train speed is maintained with the use of dynamic brakes. The blue curve in the figure
shows the stopping profile for this train if a locomotive engineer were to use additional dynamic
brake supplemented with split service brake pipe pressure reductions to stop the train, as would
typically be done. In this case, the locomotive engineer can bring the train to a stop in 2,920 ft.
The red curve in the figure shows the stopping profile for this train calculated by the enforcement
algorithm if it does not take into account the current state of the dynamic brake. Because of the
time it takes for the air brake signal to propagate the length of the train and the brakes to apply,
the force computations show acceleration, until enough brake force is supplied to begin
decelerating the train to a stop. In this case, a train would have accelerated to 29 mph before

91
decelerating to a stop over the course of 3,464 ft, which is 544 ft longer than the locomotive
engineer would take to stop the train under the same circumstances.

(15)

(16)

Figure 13. Comparison of Stopping Profiles for Normal Braking with

Use of Dynamic Brake and Penalty Braking without Use of Dynamic Brake

Figure 13 shows that, by not taking dynamic brakes into account, the enforcement algorithm
must enforce the train to a stop well before the locomotive engineer would begin to initiate the
braking process under normal operating practice. With the additional target offset necessary to
ensure the safety objective and the additional time for providing warning to the locomotive
engineer, the additional distance required to stop the train could be significant, clearly
contributing to the operational inefficiency of the system.

11.2 Safety Considerations Regarding Dynamic Brake Failure

The reason that PTC enforcement algorithms have traditionally not considered the use of
dynamic brake is that, unlike the air brake system, there is the potential that the dynamic brake
system would fail to a state where it would provide no braking. This is logical if no dynamic
brake is being used prior to the PTC enforcement, where depending on the dynamic brake to be
available for use as a method of enforcement could result in a significant risk. However, if the
dynamic brakes are already being used to maintain the speed of the train on a decline grade, the
likelihood of the dynamic brakes failing right at the point of PTC enforcement is extremely low.
For this reason, it is practical to assume that any dynamic brake currently being used will remain
following the PTC penalty enforcement, but that no additional dynamic brake will be assumed
than is currently being used. For the example illustrated in Figure 13, it takes 1,901 ft to stop the
train with a penalty brake application, if the dynamic brake setting is not changed from the
setting required to maintain the speed on the grade, a distance 920 ft less than the locomotive
engineer would take to stop the train using normal braking procedures.

92
Despite how unlikely it may be, it is still possible for the dynamic brake to fail, or for the
locomotive engineer to release the dynamic brake right at the point of PTC enforcement.
However, with the addition of the emergency brake backup function, the train can still be
stopped short of the target stopping location in these unlikely scenarios. Using the example of a
loaded, 135-car unit aluminum coal train operating on a 1.1 percent decline at 25 mph, the TOES
simulation results demonstrate that this risk is mitigated with the emergency brake backup
function as illustrated in Figure 14.

Figure 14. Comparison of Stopping Locations with Dynamic

Brake Failure and Emergency Brake Backup

The blue curve shows the stopping profile for this scenario if the level of dynamic braking
currently used to maintain the speed of the train is assumed to remain after the penalty brake
enforcement. The red curve shows the stopping profile if the level of dynamic braking currently
used to maintain the speed of the train is assumed to remain after the penalty brake enforcement,
but the actual level of dynamic braking is zero, either from dynamic brake failure or from the
locomotive engineer manually releasing the dynamic brake right at the point of penalty
enforcement. In this case, the point of enforcement is the same as for the blue curve, but the
stopping location is 1,564 ft past the stopping location if the dynamic braking had remained. The
green curve shows the stopping profile if the level of dynamic braking falls to zero immediately
following the penalty brake enforcement and the emergency brake function takes over. In this
case, the emergency brake was applied 13 seconds after the initial penalty application to stop the
train at approximately the same location as if the dynamic brake had been maintained.
Feedback from the locomotive on the status of the dynamic brake circuit is readily available,
because it is passed from trailing locomotives using the 27-pin MU cable. If, for any reason, the
dynamic brake circuit goes inactive after the penalty, the enforcement algorithm could enforce an
emergency brake application before the train began accelerating uncontrollably. Furthermore,

93
since the emergency brake backup function predicts the stopping location with an emergency
brake application given the current conditions, it would still apply the emergency brake backup
to stop the train safely short of the target stopping location even in the event the dynamic brake
fails and the feedback from the locomotive indicates it is still active.

11.3 Development of Modifications for Handling Use of Dynamic Brake

Using the logic and rationale discussed above, a function was developed to estimate the current
level of dynamic braking in use and use it in the stopping distance prediction of the enforcement
algorithm. To develop the methodology for estimating the current level of dynamic braking in
use, several options were considered, from the availability and accuracy of data that could be
used. Data on the status of the dynamic brake circuit, as well as the dynamic brake control
voltage are readily available, because they are transferred on the 27-pin MU cable. Estimated
dynamic brake effort and/or traction motor current are more difficult to obtain, particularly from
trailing or remote (distributed power) locomotives (the subject of available locomotive data and
interfaces is discussed more thoroughly in Section 14). Because of this, it was determined that a
function that could estimate the level of dynamic braking currently in use on the basis of the
status of the dynamic brake circuit and the forces and acceleration of the train would be best
suited.
The method for estimating the current acceleration of the train was designed from the
development work performed on the brake efficiency adaptive function, discussed in Section 6.3.
Similar to this function, the raw acceleration data is prone to noise from both the method and
frequency of measurement. Therefore, the two-step averaging filter used in the brake efficiency
adaptive function was implemented here to ensure a sufficient level of accuracy in the estimation
of the acceleration. As described in Section 6.3, the acceleration data is averaged over the
previous three data points to handle short-term spikes in the data as the first step in filtering. The
averaged acceleration dataset is then filtered according to a least-squares line regression method
to further smooth over the entire set of data. In the case of the brake efficiency adaptive
function, data is collected over the entire time a brake application is held, to estimate the level of
braking available for later stopping distance predictions. In the case of the dynamic brake
estimation function, the data is used to estimate the level of dynamic braking at that point in time
for use in the current stopping distance prediction. Therefore, the data collection period was
minimized, so that the data could be available as soon as possible. It was determined that 10 data
points were necessary to compute a reasonably accurate estimate of the actual train acceleration.
The current acceleration is then used, along with estimates of the other forces currently acting on
the train, determined elsewhere in the enforcement algorithm, to compute any additional resistive
force that is unaccounted for in the equation of motion. If the feedback from the locomotive
indicates that the dynamic brake circuit is active, this additional resistive force can be attributed
to the level of dynamic braking currently in use.
The setting of the dynamic brake is assumed to remain constant throughout the penalty stopping
distance prediction, but the actual dynamic brake force varies as the speed changes. This is
because the response of the dynamic brake system is not constant across all speeds. Figure 15
shows an example of the dynamic brake force produced over a range of speeds by a typical
alternating current (AC) locomotive with extended range dynamic brakes, and Figure 16 shows
an example of the dynamic brake force produced over a range of speeds by a typical direct
current (DC) locomotive with extended range dynamic brakes. As both figures show, the

94
dynamic brake force is zero at zero speed, but rises to a maximum level at a relatively low speed.
For the AC locomotive in Figure 15, this level of dynamic brake force is maintained as speed
increases until approximately 20 mph, at which point the dynamic brake force decays
exponentially as speed increases. For the DC locomotive in Figure 16, there is a saw-tooth shape
to the curve until approximately 25 mph, at which point the dynamic brake force decays
exponentially as speed increases.

Figure 15. Example Dynamic Brake Curve for AC Locomotive

To properly estimate the amount of dynamic brake force in the stopping distance prediction, it is
necessary to model the dynamic brake force response with regard to train speed at each time step
in the prediction. The specific dynamic brake curves vary from one locomotive to another, but
they all follow the same general shapes shown in Figures 15 and 16 for locomotives with
extended range dynamic brakes. For locomotives without extended range dynamic brakes, the
curves increase linearly from zero to the maximum point where the curve begins to decay
exponentially. Because the vast majority of road locomotives today are equipped with extended
range dynamic brakes, those without were not included in the development of the function.

95
 Figure 16. Example Dynamic Brake Curve for DC Locomotive

Using a set of best fit curves for a sample of dynamic brake curves from various different
locomotive types, a dynamic brake force shape function was developed to scale the estimated
dynamic brake force currently in use according to the predicted speed of the train at each time
step in the prediction. The function assumes zero dynamic brake force up to 5 mph, a constant
level of dynamic brake force between 5 and 20 mph, and an exponentially decaying level of
dynamic brake force as speed increases beyond 20 mph. The dynamic brake force currently in
use is divided by the value of this dynamic brake force shape function at the current train speed
to generate a dynamic brake calculation coefficient. This coefficient is then multiplied at each
time step of the stopping distance prediction by the value of the dynamic brake force shape
function for the train speed at the given time step of the stopping distance prediction, to estimate
the level of dynamic brake force at that time step of the prediction.
To ensure the function developed performed reasonably well in predicting the amount of
dynamic brake force throughout the range of speeds, the function was tested using the TOES
model for a variety of locomotive types, speed ranges, and dynamic brake settings. For each
configuration, the train was stopped in the TOES model using locomotive dynamic brake only,
and the function was used to determine the stopping distance with dynamic brake only. The two
were compared and the function closely predicted the stopping distance in each case. Where
there was error between the two, the dynamic brake force shape function always predicted less
dynamic brake force for a longer stopping distance, showing that the function is a conservative
estimate of the dynamic brake force actually produced throughout the stopping profile.

11.4 Field Testing Dynamic Brake Function

Field tests were performed using both the base enforcement algorithm and the developmental
algorithm with the dynamic brake function, in order to demonstrate the performance benefits that
can be seen by using the current dynamic brake status in the enforcement algorithm. Because

96
dynamic brake is typically used to control the speed of the train on decline grades, all of these
tests were performed on the decline grade on the RTT. In each case, the train was accelerated to
the test speed and the dynamic brake notch was increased to that necessary to maintain the speed
of the train with no use of the air brakes.
The following two types of tests were performed during the dynamic brake testing:
• Safety — These tests are designed to demonstrate that the algorithm safely stops the train
short of the target. In these tests, the train is allowed to proceed toward the target with no
intent to stop, such that the enforcement algorithm must enforce a penalty brake
application to stop the train short.
• Performance — These tests are designed to demonstrate how the algorithm does or does
not interfere with normal crew actions to stop the train safely short of the target. In these
tests, the locomotive engineer stops the train short of the target using normal operating
procedures, including the use of dynamic brake.
Table 21 shows the test cases that were used in the field testing of the dynamic brake function as
well as the resulting stopping locations and penalty enforcement locations for both the base
algorithm and the developmental algorithm with the dynamic brake function included.
Table 21. Dynamic Brake Function Field Test Results
Average Stopping Average Enforcement
Test Conditions Location Relative to Location Relative to
Target (ft) Target (ft)
Dynamic Dynamic
Speed Base Base
Consist Test Type Brake Brake
(mph) Algorithm Algorithm
Function Function

10 Cars – Loaded 30 Safety -3,013 -888 -5,489 -3,286

10 Cars – Loaded 30 Performance -3,656 -655 -5,462 -955

40 Cars – Loaded 30 Safety -2,360 -810 -5,114 -2,887

40 Cars – Loaded 50 Safety -3,371 -1,640 -9,879 -7,115

80 Cars – Loaded 10 Safety -1,169 -597 -1,950 -1,430

80 Cars – Loaded 10 Performance -873 -243 -1,450 N/A

80 Cars – Loaded 30 Safety -2,092 -1,137 -4,984 -4,045

As the data in Table 21 shows, the algorithm equipped with the dynamic brake function enforced
the train later and stopped the train closer to the target in all cases, and dramatically so in many
cases. For example, in the case with 40 cars traveling 50 mph, the developmental function
enforced a penalty brake application over 2,700 ft later than the base algorithm, but still stopped
the train safely short of the target. In an actual operation, this would give the train crew an
additional 38 seconds to start acting to slow the train down before being enforced, which can
have a significant impact on the line capacity. Additionally, in the slow speed (10 mph)
performance case with 80 cars, the dynamic brake function did not interfere with the locomotive

97
engineer, who stopped the train 243 ft short of the target, but enforced a penalty brake
application nearly 1,500 ft short of the target with the base enforcement algorithm.
In addition to the test results shown in Table 21, each of the safety test scenarios was run with
the development algorithm and simulating a failure of the dynamic brake at the point of
enforcement. In each of these tests, the dynamic brake was reduced to idle directly following the
penalty application. Table 22 shows the results of these tests. In all of these tests, the
emergency brake backup function responded by applying the emergency brake and stopping the
train safely short of the target. These tests both illustrate the need to consider dynamic brake in
the enforcement algorithm and show that it can be done safely.

Table 22. Dynamic Brake Function with Simulated DB Failure Field Test Results

Average Average
Test Conditions Stopping Enforcement
Location Location
Speed Relative to Relative to
Consist Target (ft) Target (ft)
(mph)

10 Cars – Loaded 30 -415 -3,744

40 Cars – Loaded 30 -554 -2,856

40 Cars – Loaded 50 -294 -7,573

80 Cars – Loaded 10 -147 -1,321

80 Cars – Loaded 30 -772 -3,769

98
12. Evaluation of Phase 2 Developmental Algorithm
The Phase 2 developmental algorithm consists of all the modifications and additions to the base
algorithm from the first phase of development, discussed in Sections 5, 6, 7, and 8, with the
additional functions from the second phase of development, discussed in Sections 10 and 11.
These additional functions include the dynamic brake and locomotive brake functions.
Appendix F defines each of the Phase 2 algorithm functions within the context of the final
developmental algorithm. Although the document included in Appendix F also includes
modifications developed in Phase 3; these were not in place during the evaluation of the Phase 2
algorithm.
Simulation testing and analysis was performed on the Phase 2 algorithm using the methodology
described in Section 2.2. As with the Phase 1 algorithm, the Phase 2 algorithm was only tested
with unit trains, because improvements for manifest freight and intermodal freight trains were
not included until the third phase of development. Table 23 shows the overall results of the
simulation testing for unit trains with the Phase 2 algorithm. This table includes the probability
of stopping short of the target and the probability of stopping short of the performance limit,
defined as stopping short of the target by less than 500 ft for speeds < 30 mph and 1,200 ft for
speeds ≥ 30 mph. Appendix I contains the detailed results from simulation testing of the Phase 2
algorithm.
Table 23. Phase 2 Algorithm Simulation Test Results
Probability of Stopping Short of Probability of Stopping Short of
Train Type Target Performance Limit

Unit Freight 99.57% 7.59%

The data in Table 23 shows that the Phase 2 developmental algorithm meets the safety objective
of stopping short of the target more than 99.5 percent of the time, and the probability of stopping
short of the performance limit was reduced to 7.59 percent from 31.98 percent in the Phase 1
algorithm. A look into the details of the results of the analysis indicates that the improvement in
the performance objective can be attributed primarily to incorporation of the dynamic brake
function. This is apparent from the reduction in the probability of stopping short of the
performance limit for scenarios on descending grades, where the dynamic brake is used to
control the speed of the train. With the addition of this function, along with those developed in
the first phase, the operational efficiency of the algorithm can improved to the point where trains
will stop short of the performance limit only in very few circumstances.

99
13. Manifest Freight and Intermodal Freight
Having developed functionality to improve the safety and operational efficiency of the
enforcement algorithm and demonstrated the improved performance for unit trains, the next task
was to expand the scope of the enforcement algorithm to handle other typical train types
including manifest freight and intermodal freight trains. The majority of the prediction logic
remains the same for all train types; however, the braking performance and the variability in
braking performance for these other train types can be significantly different than for unit trains.
Additionally, more car types, including multiple-platform articulated cars must be handled by the
enforcement algorithm for these train types.

13.1 Assumptions for Unknown Parameters for Manifest Freight and Intermodal
Freight Equipment
The enforcement algorithm must make assumptions for some of the unknown parameters in
predicting the stopping distance of the train, as discussed in Section 5.2. In the case of the base
enforcement algorithm, these assumptions were generally more conservative, and modifications
to these assumptions were made for unit trains to provide a more nominal prediction. Two of
these assumptions, the nominal car brake force and the brake pipe propagation time, were
modified to assume the center of the range of possible values. This same logic was applied to
manifest freight and intermodal freight train types, as well.

13.1.1 Nominal Car Brake Force

In the case of nominal car brake force, several assumptions were made in the unit train analysis
that do not necessarily apply to manifest freight and intermodal freight cars. First, the
assumption that for a loaded train, every car is loaded to the maximum allowable GRL does not
apply to train types other than unit freight. Many times, cars in these other train types are
partially loaded, or the maximum volume is reached before the maximum weight is. Therefore,
the average net brake ratio for the train type cannot be used to determine the nominal car brake
force, because the trailing weight of the train may not be the maximum allowable GRL. Instead,
the average net brake force for the possible car types must be assumed. However, with the
introduction of multiple-platform articulated cars, assuming the average net brake force for the
car can lead to problems as well. This is because the average net brake force for a multiple-
platform articulated car may be much higher than a typical single-platform car, because of the
increased load it can handle with the additional axles and platforms. Assuming the nominal
brake force per axle, rather than by car, eliminates this problem, and the same assumption can
apply to both single-platform and multiple-platform cars. Using this logic, the assumption for
nominal brake force was changed from the nominal car brake force to the nominal axle brake
force.
To determine the value for the nominal axle brake force for manifest freight and intermodal
freight train types, the same basic process used for unit freight trains was followed. First, the
average loaded net brake force for each train type was determined by individually examining
each of the car types that can make up the given train type. For each of these car types, bins
were defined according to the date ranges that a particular version of the AAR standard for net
brake ratio was in effect for. For each of these bins, the minimum and maximum loaded net
brake force per axle was determined, both for cars equipped with empty/loaded devices and for

100
cars not equipped with empty/loaded devices, using the range of brake ratios allowed by the
given version of the AAR standard, the assumption that the brake ratio can fade by 1 percent
over time [7, 11], the average GRL and tare weight for the car type, and the number of axles for
the car type.
For each car type, the average loaded net brake force per axle was determined by combining the
average loaded net brake force per axle for each bin, using UMLER data for the probability that
a given car of that type fits into each bin and the probability that the given car type is equipped
with an empty/loaded device. The average empty net brake force was determined the same way,
except that the loaded net brake force per axle was divided in two for the case where the car is
equipped with an empty/loaded device, representing a 50 percent reduction in brake shoe force
from the empty/loaded device when the car is empty.
Finally, to determine the nominal loaded and empty net brake force per axle for each train type,
the average loaded and empty net brake force per axle were each averaged for all of the car types
that could make up the given train type. In some cases, certain car types were left out of the
average because they had an average net brake force per axle that was significantly higher than
the other car types for the train type. These values were left out to ensure a safe assumption for
all of the car types that make up the train type. For consistency, the loaded and empty nominal
car brake forces for unit trains were converted into loaded and empty nominal brake forces per
axle by dividing the nominal car brake forces determined earlier in the project (see table 13 in
Section 5.2.1) by the number of axles on the unit car types, 4. Table 24 shows the final, revised
assumption for the nominal brake force per axle for each train type, with 𝑊𝐶𝐴𝑅𝑆 equal to the
weight of the cars in lb and 𝑁𝐴𝑋𝐿𝐸𝑆 equal to the total number of car axles.

Table 24. Revised Nominal Car Brake Force for Unit Trains
Nominal Loaded Car Brake Nominal Empty Car Brake
Train Type
Force Force
0.11 ∗ 𝑊𝐶𝐴𝑅𝑆 3,975
Unit Aluminum Coal
𝑁𝐴𝑋𝐿𝐸𝑆
0.093 ∗ 𝑊𝐶𝐴𝑅𝑆 4,962
Unit Freight
𝑁𝐴𝑋𝐿𝐸𝑆
Manifest Freight 5,870 5,044
Intermodal Freight 6,895 3,746

13.1.2 Brake Pipe Propagation Time

As discussed in Section 5.2.2, the brake pipe propagation time is determined using a function of
the length of the train. For unit trains, this function was determined by running a series of TOES
simulations for each unit train type for a variety of train lengths. For each series of simulations,
the control valve types and ambient conditions were varied according to the distributions of
possible values for the given train type. This methodology was applied to manifest freight and
intermodal freight train types as well. For these cases, a wider range of simulations were
performed, however, to account for the wider variations in train makeup.

101
As with the development of the brake pipe propagation time for unit trains, the results of these
simulations were analyzed using train length, and a best fit regression curve was developed. The
final, revised brake pipe propagation time for all train types is:

13 + 0.01179𝐿 𝑇𝑅𝐴𝐼𝑁 + 0.000000256𝐿2𝑇𝑅𝐴𝐼𝑁 𝑓𝑜𝑟 𝑈𝑛𝑖𝑡 𝑇𝑟𝑎𝑖𝑛𝑠

𝑇𝐴𝑃𝑃𝐿𝑌 = �15.6 + 0.0084792𝐿 𝑇𝑅𝐴𝐼𝑁 + 0.000000801𝐿2𝑇𝑅𝐴𝐼𝑁 𝑓𝑜𝑟 𝑀𝑎𝑛𝑖𝑓𝑒𝑠𝑡 𝐹𝑟𝑒𝑖𝑔ℎ𝑡 𝑇𝑟𝑎𝑖𝑛𝑠 Enforc

16.66 + 0.006871𝐿 𝑇𝑅𝐴𝐼𝑁 + 0.0000001331𝐿2𝑇𝑅𝐴𝐼𝑁 𝑓𝑜𝑟 𝐼𝑛𝑡𝑒𝑟𝑚𝑜𝑑𝑎𝑙 𝑇𝑟𝑎𝑖𝑛𝑠

13.2 Development of Target Offset Functions for Manifest Freight and Intermodal
Freight
An improved function for estimating the target offset necessary to offset the nominal stopping
distance prediction to achieve the safety objective for unit trains was developed using Monte
Carlo simulation techniques and statistical regression methods, as discussed in Section 5.3. This
same process was used to develop similar functions for the manifest freight and intermodal
freight train types.
As with the Monte Carlo simulation process for unit trains, a large test matrix covering a wide
range of scenarios was necessary for manifest freight and intermodal freight train types, as well.
Because of the wider variation of train makeup and loading conditions for these train types, the
number of simulations was even greater than for unit train types. For manifest freight, the
simulation test matrix included 114 different train makeup and loading conditions, 10 different
train speeds, and eight different track grades, with a total of 4,207 test scenarios. For intermodal
freight, the simulation test matrix included 70 different train makeup and loading conditions, 12
different train speeds, and eight different track grades, with a total of 3,570 test scenarios. For
each scenario, 100 simulations were run with Monte Carlo variance of the parameters that can
affect train stopping distance.
As for the unit train types, statistical analyses were used to identify the target offset necessary to
achieve the safety objective for each manifest freight and intermodal freight test scenario
simulated. A multiple-variable regression technique was then employed to develop the functions
to estimate the target offset for any given scenario for all train types.
For manifest freight and intermodal freight trains, two functions were developed for each,
depending on whether the train is operating with head end power only or distributed power.
Each is a function of the velocity, v, the equivalent constant grade over the predicted stopping
distance, g, the trailing weight in tons, WCARS, the total number of axles on the train, nTOTAL, the
number of loaded cars, NLOAD, and the number of empty cars, NEMPTY.
For manifest freight trains operating with distributed power, the target offset, TO, is equal to:
𝑇𝑂 = 𝑒 0.0457𝑣−0.36𝑔+0.0000278𝑊𝐶𝐴𝑅𝑆 −0.00795𝑛𝑇𝑂𝑇𝐴𝐿+0.03364𝑁𝐿𝑂𝐴𝐷+0.03223𝑁𝐸𝑀𝑃𝑇𝑌+3.568 Start

For manifest freight trains with head end power, the target offset, TO, is computed from one of
three equations, depending on the equivalent constant percent grade over the predicted stopping
distance, g:

102
 𝑇𝑂𝐷𝐸𝐶 , 𝑖𝑓 𝑔 ≤ −0.5
𝑔 𝑔
𝑇𝑂 = ��1 + 0.5� ∗ 𝑇𝑂𝐼𝑁𝐶 − 0.5 ∗ 𝑇𝑂𝐷𝐸𝐶 , 𝑖𝑓 − 0.5 < 𝑔 < 0 (17)
𝑇𝑂𝐼𝑁𝐶 , 𝑖𝑓 𝑔 ≥ 0

Where the values for incline and decline are determined from the following two equations:
𝑇𝑂𝐷𝐸𝐶 = (0.475𝑣 − 1.03𝑔 + 0.0004𝑊𝐶𝐴𝑅𝑆 + 0.0031𝑛𝑇𝑂𝑇𝐴𝐿 )2 (18)
𝑇𝑂𝐼𝑁𝐶 = (0.436𝑣 − 2.12𝑔 + 0.00011𝑊𝐶𝐴𝑅𝑆 + 0.0037𝑛𝑇𝑂𝑇𝐴𝐿 )2 (19)

For intermodal freight trains with distributed power, the target offset, TO, is equal to:
𝑇𝑂 = (0.338𝑣 − 2.031𝑔 + 0.0000475𝑊𝐶𝐴𝑅𝑆 + 0.00605𝑛𝑇𝑂𝑇𝐴𝐿 )2 (20)

For intermodal freight trains with head end power, the target offset, TO, is equal to:
𝑇𝑂 = (0.335𝑣 − 2.412𝑔 + 0.0000415𝑊𝐶𝐴𝑅𝑆 + 0.00445𝑛𝑇𝑂𝑇𝐴𝐿 + 2.024)2 (21)

13.3 Field Testing with Manifest Freight Equipment

To verify the performance of the final developmental enforcement algorithm with train types
other than unit, field testing was performed using manifest freight equipment. Unit freight
equipment is generally available for testing at TTC, from the train used in the FAST program.
However, manifest freight and intermodal equipment is not generally available as a complete
train. Therefore, 74 empty general freight cars were sent to TTC by the UPRR to support this
testing. The cars were a mix of covered hoppers, box cars, flat cars, gondolas, and refrigerated
box cars used in general freight service. These cars had a variety of braking system components
and configurations, making for a good range of car types to be included in the test consist.
Because manifest freight trains generally have a mix of loaded and empty cars, some of the cars
from the FAST train were used in combination with the empty manifest freight cars to create
more realistic consists.
The enforcement algorithm was tested using the manifest freight train covering a wide range of
test scenarios to demonstrate its safety and performance characteristics. The test scenarios
included a range of train lengths, train speeds, track grades, as well as brake system states. Each
of the test scenarios was repeated multiple times to demonstrate the consistency of the
enforcement algorithm. Table 25 shows the test scenarios and resulting average stopping
location relative to the target for each.
As the data in the table indicates, the train stopped short of the target stopping location in all test
cases. Additionally, the train stopped within the performance target of stopping within 500 ft of
the target when the train speed is < 30 mph and within 1,200 ft of the target when the train speed
is > 30 mph in all test cases. Both the safety and performance characteristics of the enforcement
algorithm with the manifest freight test train was shown to be acceptable, and far better than that
of the base algorithm.

103
 Table 25. Manifest Freight Field Test Results
Test Conditions
Stopping Location Relative
Brake
Speed Track to Target (ft)
Consist System
(mph) Grade
State

94 Cars – Fully
10 Flat -57
20 Loaded, 74 Empty Charged

94 Cars – Fully
30 Flat -334
20 Loaded, 74 Empty Charged

94 Cars – Fully
50 Flat -783
20 Loaded, 74 Empty Charged

94 Cars – Fully
30 Decline -230
20 Loaded, 74 Empty Charged

94 Cars –
30 Decline Applied -233
20 Loaded, 74 Empty
94 Cars – Fully
30 Incline -125
20 Loaded, 74 Empty Charged

94 Cars – Fully
30 Crest -163
20 Loaded, 74 Empty Charged

40 Cars – Fully
30 Flat -267
10 Loaded, 30 Empty Charged

40 Cars – Fully
50 Decline -719
10 Loaded, 30 Empty Charged

10 Cars – Fully
30 Flat -304
3 Loaded, 7 Empty Charged

10 Cars – Fully
30 Decline -700
3 Loaded, 7 Empty Charged

104
14. Research on Available Locomotive Data and Interfaces
The enforcement algorithm software is contained within the locomotive onboard component of
the PTC system. In order to function, the onboard component must interface with the
locomotive in near real time to provide a variety of data elements to the enforcement algorithm.
These data elements are required for stopping distance prediction and to initiate air brake
applications when triggered by the enforcement algorithm to enforce an authority or speed limit.
Although many of the data elements and interfaces required have been addressed by those
involved with PTC system development and deployment, many of the functions proposed for
improving the safety and operational performance of the enforcement algorithm involve
additional data elements and interfaces that may not have been planned for.
Additionally, it is recognized that various types of locomotives of various vintages may be
required to have PTC onboard equipment operating on them. Although some of the data
elements and interfaces required by the enforcement algorithm may be readily available on
certain types of locomotives, access to the information or system on other locomotives may
require additional hardware or software components. In addition, some data elements must also
be acquired from trailing or distributed power remote locomotives.
The purpose of this task was to identify the locomotive data elements and interfaces, both
required and optional, for implementation of an improved enforcement algorithm, to define
classes of locomotives using the availability of these data elements and interfaces, and to
research and test methods for acquiring and using the identified data elements and interfaces on
the various classes of locomotives defined.

14.1 Identification of Locomotive Data and Interfaces for Improved Enforcement

Algorithm
The first component of this task was to identify which locomotive data elements are required for
the enforcement algorithm, and which locomotive data elements could potentially be used to
improve the performance of the enforcement algorithm, should they be available. The following
elements were identified as being required by the enforcement algorithm:
• Head-end train location — Required for predicting the stopping location of the train
• Tail-end train location — Required for estimating the grade and curvature forces acting
on the train throughout the predicted stopping profile of the train
• Train speed — Required in predicting the stopping location of the train
• Head-end brake pipe pressure — Required for determining the current state of the air
brake system
• Tail-end brake pipe pressure — Required for estimating the pressure available in the air
brake system
The following locomotive data elements were identified as having the potential to improve the
enforcement algorithm performance, should they be available:
• Locomotive throttle notch — Could potentially be used to estimate tractive effort
produced, which could be used to estimate train resistance

105
 • Dynamic brake status — Could be used to determine if the dynamic brakes are active,
which is necessary if the algorithm assumes that dynamic brakes will remain active after
PTC enforcement
• Dynamic brake control voltage — Could potentially be used to estimate dynamic brake
effort, which could be used to estimate train resistance, as well as to estimate the level of
dynamic braking that will remain after PTC enforcement if the algorithm assumes such
• Tractive and dynamic brake effort — Could be used to estimate train resistance and to
estimate the level of dynamic braking that will remain after PTC enforcement if the
algorithm assumes such
• Status of distributed power communications — Necessary if the algorithm assumes faster
propagation time when distributed power communication is active
In order to acquire the data elements listed above, and to initiate air brake applications, the
following interfaces to the locomotive are, or may be, required:
• Brake system — Required for initiating PTC penalty brake application, emergency brake
application (if the algorithm uses an emergency brake backup function), and for
providing head-end brake pipe pressure
• End-of-train head end unit — Required for providing tail-end brake pipe pressure
• 27-pin MU cable data — Required for providing locomotive throttle notch, dynamic
brake status, and dynamic brake voltage
• Location determination system — Required for providing accurate head-end location and
train speed
• Locomotive computer — Required for providing current tractive effort and dynamic
brake data, as well as train speed
• Locomotive traction motor electrical data — Required for estimating current tractive
effort and dynamic brake data
• Distributed power communications status — Required for determining whether
distributed locomotives will assist with propagation of brake signal

14.2 Definition of Classes of Locomotives for PTC Enforcement Algorithms

It was recognized that PTC onboard systems and enforcement algorithms may be required on a
variety of types of locomotives, with potentially different data elements and interfaces available.
The objective of this component of the research task was to identify the distinguishing features
of the various locomotive types that define the different classes of locomotives with regard to
data and interfaces available for PTC enforcement algorithms.
The following primary distinguishing features of locomotives currently in use by North
American freight railroads were identified:
• Type of traction system, AC or DC
• Type of brake system, electronic or pneumatic

106
 • Type of control system, computer-controlled (digital logic) or module-controlled (analog
logic)
Each of these distinguishing features was considered with regard to each of the data elements
and interfaces listed in the previous section to determine what, if any, implication the feature
may have on the given data element or interface. Table 26 shows which of the data elements and
interfaces are affected by each of the distinguishing locomotive characteristics. For the majority
of the data elements, it was determined that the various locomotive distinguishing characteristics
did not affect them measurably, with the exception of tractive effort/dynamic brake effort. In
this case, the type of locomotive control system will affect the type of data available. For newer,
computer-controlled (digital logic) locomotives, the locomotive computer measures and
calculates the current tractive or dynamic brake effort, which could be used directly by the
enforcement algorithm. For older, module-controlled (analog logic) locomotives, only the
traction motor electrical data (e.g., traction motor current) is available for estimating tractive and
dynamic brake effort. This difference has the potential to affect the performance of the
enforcement algorithm, if the data is required.

Table 26. Data Elements/Interfaces Affected by Locomotive Characteristics

Type of Traction Type of Brake Type of Control
Data Element/Interface System System System
Head-end train location
Tail-end train location
Train speed
Head-end brake pipe pressure
Tail-end brake pipe pressure
Throttle notch
Dynamic brake status
Dynamic brake voltage
Tractive effort/dynamic brake Type of data
effort available is different
Distributed power
communications status
Brake system interface Interface is different
End-of-train head end unit Interface may be
interface different
Interface may be
27-pin MU cable data interface
different
Location determination system
interface
No interface on
Locomotive computer interface module-controlled
locomotives
Locomotive traction motor data
interface
Distributed power Interface may be
communications status interface different

107
In the case of the interfaces, many are affected by the type of control system. The interface to
the end-of-train head end unit, 27-pin MU cable data, and distributed power communication
status may all be different on computer-controlled (digital logic) locomotives than on module-
controlled (analog logic) locomotives, because these functions may be integrated into the
locomotive computer on computer-controlled (digital logic) locomotives. Additionally, the
interface to the brake system is different depending on the type of brake system (electronic or
pneumatic). Although the specific interfaces may be different in all of these cases, which will
affect implementation of the onboard hardware, none of these differences are expected to have
any effect on the performance of the enforcement algorithm.
From this analysis, there are effectively four classes of locomotives with regard to PTC
enforcement algorithms, as follows:
• Computer-controlled (digital logic) locomotives with electronic brake systems
• Computer-controlled (digital logic) locomotives with pneumatic brake systems
• Module-controlled (analog logic) locomotives with electronic brake systems
• Module-controlled (analog logic) locomotives with pneumatic brake systems

14.3 Field Testing to Verify Potential Tractive Effort and Dynamic Brake Data
From the research described in the previous sections, the only data element with the potential to
affect the performance of the enforcement algorithm using the class of locomotive it is operating
on is tractive and dynamic brake effort data. To provide an indication of the accuracy of the
tractive and dynamic brake effort data available with each of the types of locomotive control
systems, field tests were performed at the TTC on a small sample of locomotives. The objective
of the testing was to collect tractive and dynamic brake effort data and compare these to
instrumented coupler data to quantify the accuracy of the available data. The test was not
intended to fully evaluate the various options, but rather to qualitatively investigate their
applicability to improve the accuracy of stopping distance predictions. This was a high-level
study intended to identify what may be available to the braking enforcement algorithm, and how
it may be used.
The three following Electro-Motive Diesel, Inc. (EMD) locomotives were selected for the field
testing:
• UP3886, an EMD SD70M
• NS2595, an EMD SD70M
• CSX4762, an EMD SD70MAC
With the support of EMD, the computers on each of these locomotives were set up to record the
computed tractive and dynamic brake effort data. Additionally, an instrumented coupler was
installed in a freight car to measure the coupler force between the last locomotive coupler and the
first coupler in the trailing consist.
The testing consisted of two components. In the first component, data was collected from the
test locomotives during normal operations at FAST. The FAST train consists of the three
locomotives and 80–115 loaded hopper/gondola cars. The FAST train operates on a 2.7-mile
loop known as the HTL. The data collected during this component of testing was intended to

108
identify a general level of accuracy, given multiple locomotives, including various types, in a full
train application over multiple hours of continuous operation.
The second component consisted of collecting data under specific operating conditions with
specific locomotives. In this component, each locomotive was evaluated separately, in operating
scenarios including continuous pulling up a grade (measuring tractive effort), and constant
braking down a grade (measuring dynamic brake effort). This component of testing was
performed on the train dynamics track (TDT) at the TTC. The consist included a single
locomotive and 25 loaded cars from the FAST consist. The data collected during this component
of testing was intended to identify a general level of accuracy for a single locomotive in a
specific operating scenario to help provide a high-level view of the relative accuracy from
locomotive to locomotive, as well as to identify any significant differences between AC and DC
locomotives. Each test scenario was run multiple times to provide repeatability data for
comparison and to increase the overall dataset.
The test scenarios are listed in Table 27.

Table 27. Locomotive Data Test Scenarios

Test Case Locomotives Consist Track
All FAST Full FAST
1 HTL
Locomotives Consist
2 1 SD70M (DC) 25 FAST cars TDT (incline)
3 1 SD70MAC (AC) 25 FAST cars TDT (incline)
4 1 SD70M (DC) 25 FAST cars TDT (decline)
5 1 SD70MAC (AC) 25 FAST cars TDT (decline)

Following testing, the data from the locomotives and the instrumented coupler was downloaded
and some post processing was performed. Specifically, the data from the instrumented coupler
exhibited a reasonable level of high frequency noise that was digitally filtered to provide a better
comparison to the computed tractive and dynamic brake effort data. Figure 17 shows a
comparison of the filtered instrumented coupler data and the tractive effort data computed by
each of the three locomotives in the FAST train for approximately one hour of operation on the
HTL. The data shows the train starting from a stop and accelerating over the course of several
laps around the HTL to a steady-state operational cycle that repeats approximately every four
minutes, as the train completes each lap. During each lap, the locomotives pull in throttle notch
8 for approximately 60 percent of the lap, before slowly notching down to throttle notch 4 as the
train descends a hill and then notching back up to throttle notch 8 again. These changes in
throttle notches account for the large variations in tractive effort throughout each lap. The more
subtle variations are the result of the changing speed of the locomotives, where the tractive effort
increases gradually as the train ascends the hill and the speed gradually decreases. As Figure 17
shows, the sum of the computed tractive effort for all of the locomotives correlates closely and
repeatedly with the filtered instrumented coupler data.

109
 Figure 17. Comparison of Instrumented Coupler and Computed
Tractive Effort Data for FAST Train over One Hour of Operation

The only exception to the close correlation is near the locations where the locomotive throttle is
notched up or down, where there is a slight difference between the two sets of data. Figure 18
shows the same data as Figure 17, but for a single lap around the HTL. Figure 18 shows a
distinct variance between the two datasets at these locations. This is likely the result of
differences in the methodology in data acquisition, processing, and filtering that were not taken
into account as part of this high-level effort. These differences are relatively small and of
relatively short duration, meaning that, should the enforcement algorithm use a sample of data,
rather than just a single data point, they should not cause significant issues with calculations
from this data. On average, the two datasets are within 3 percent of each other across the range
of the datasets that were compared, which is reasonable, given the high-level nature of the data
acquisition and processing. The instrumented coupler itself has an accuracy of +/-1 percent of
the full scale of 1,000,000 lb, meaning the majority of the differences are within the accuracy of
the coupler.

110
 Figure 18. Comparison of Instrumented Coupler and Computed
Tractive Effort Data for FAST Train over One Lap of the HTL

Figure 19 shows the filtered instrumented coupler data compared with the computed tractive and
dynamic brake effort data for the UP3886 locomotive as it pulls 25 FAST cars over the hill on
the TDT and slows the train to a stop. The UP3886 is an EMD SD70M locomotive equipped
with a DC traction system. Figure 19 shows the tractive effort with the locomotive throttle notch
gradually increasing as the train accelerates up to speed and then gradually increasing as the
speed slowly decreases with the train ascending the hill. Near the end of the dataset, the tractive
effort falls off quickly as the locomotive throttle notch is decreased to idle, and then dynamic
brake is used to slow the train to a stop. The shape of the dataset through the dynamic braking
section (the “saw-tooth” shape) is distinctive of the dynamic braking system of a DC locomotive
across the speed range.
As with the data from Figure 17, Figure 19 shows good correlation between the instrumented
coupler data and the tractive and dynamic brake effort data computed by the locomotive. The
only area of any real discrepancy is when the locomotive is in idle at around the 500-second
point on the graph. Here, the locomotive correctly shows no tractive effort produced, but the
instrumented coupler shows some minimal amount of force. This is likely because the train was
cresting the top of the hill at this point, meaning the locomotives were pulling down the hill,
while some of the trailing cars were still being pulled up the other side, resulting in some amount
of force between the locomotives and the trailing cars.

111
 Figure 19. Comparison of Instrumented Coupler and Computed
Tractive Effort Data for UP3886 (EMD SD70M)

Figure 20 shows a comparison of the filtered instrumented coupler data compared with the
computed tractive and dynamic brake effort data for the CSX4762 locomotive over the same
operation. The CSX4762 is an EMD SD70MAC locomotive equipped with an AC traction
system. The data in Figures 19 and 20 are very similar, with two exceptions. One difference is
the lack of the “saw-tooth” shape for the dynamic brake effort in figure 20. Extended range
dynamic brakes exhibit a “flat-top” characteristic curve for AC traction systems. The other
difference is there is some discrepancy between the computed dynamic brake effort and the
filtered instrumented coupler data during dynamic braking in Figure 20. The reason for this
difference is not immediately understood, and because of the high-level nature of this effort, it is
not known whether it would occur on all AC locomotives or occurs only with this locomotive.
Should this data be necessary for use in a PTC onboard braking enforcement algorithm
application, further research should be done to identify implications of the difference observed
here.

112
 Figure 20. Comparison of Instrumented Coupler and Computed
Tractive Effort Data for CSX4762 (EMD SD70MAC)

14.4 Conclusions and Other Considerations Regarding Locomotive Tractive

Effort/Dynamic Brake Data
To summarize the results of the field testing, the tractive and dynamic brake effort computed by
the locomotive computer was shown to be a very good representation of the actual pulling or
resisting force of the locomotives. From this result, this data could be used in the enforcement
algorithm for computer-controlled locomotives, if needed. However, to be effective, the data for
all locomotives, including trailing locomotives and remote distributed power locomotives, would
need to be sent to the onboard system in the lead locomotive. Presently, there is no method for
achieving this. There is, however, a federal mandate that all new and rebuilt locomotives must
report dynamic brake effort to the lead locomotive. As a result of this mandate, the AAR has
developed Standard S-5509, for reporting both locomotive tractive and dynamic brake effort data
to the lead locomotive for all trailing locomotives and remote distributed power locomotives in
the consist [24]. As new locomotives are phased in and older ones replaced, this functionality
will gradually become available.
For module-controlled locomotives where tractive and dynamic brake effort is not computed
onboard, the tractive and dynamic brake effort could be estimated from the measured traction
motor electrical data that is generally available. Module-controlled locomotives generally report
the traction motor current for the second axle of the locomotive to a gauge in the cab, for use by
the locomotive engineer during operation of the locomotive. If it is assumed that the same
current applies to all traction motors on the locomotive, this value could be multiplied by the
number of traction motors on the locomotive to estimate the total traction motor current.
Multiplying this value by the main generator voltage will produce an estimate of the total power
produced by the traction motors, in watts, when the locomotive is in a throttle notch. When the
locomotive is in dynamic brake, the dynamic brake excitation voltage is multiplied by the total

113
traction motor current to estimate the total resistive power of the traction motors, also in watts.
Given that 746 watts = 1 horsepower = 550 ft-lb/s, it is possible to determine the force from the
estimated power and speed of the locomotive as:
𝑃
550∗
𝐹= 746
5280 (22)
𝑉∗
3600

Where F is tractive or dynamic brake force in lb, P is the power in watts, and V is the locomotive
speed in mph. Using this methodology, it is conceivable that the tractive or dynamic brake effort
for a module-controlled locomotive could be estimated. However, the difficulty of passing this
data from trailing and remote distributed power locomotives to the lead locomotive is even more
pronounced, because there are no current plans to provide this type of data for these older types
of locomotives.
Locomotive tractive effort and dynamic brake effort data has been shown in an earlier study to
be useful in estimating the resistance, or weight, of the train [1]. In this study, it was observed
that accurately estimating the tractive and dynamic brake effort is the difficulty in performing
this estimation. Additionally, if an accurate measure of dynamic brake effort could be made, it
could be useful for estimating the level of dynamic braking during the stopping distance
prediction.
The techniques researched as part of this task have shown that it is possible to accurately
estimate tractive and dynamic brake effort data, particularly with newer computer-controlled
locomotives, but that there is still some difficulty in acquiring the data from trailing and/or
remote distributed power locomotives. However, it has also been determined, through other
tasks of the research program, that the train resistance can be accounted for in the measurement
of train braking efficiency, and that the level of dynamic brake effort can be estimated from train
acceleration data. With these new developments, the need for accurately estimating the tractive
and dynamic brake effort of the locomotive may be unnecessary. However, if future research
and development in the area of PTC enforcement algorithms shows a need for this data, the
results here indicate a path forward for acquiring it.

114
15. Evaluation of Final Developmental Enforcement Algorithm
The final developmental algorithm consists of all the modifications and additions from the first
two phases of development, discussed in Sections 5-8 and 10-11, with additional modifications
to handle manifest and intermodal freight trains. Appendix F defines the complete, final Phase 3
algorithm.
Simulation testing and analysis was performed on the final Phase 3 algorithm using the
methodology described in Section 2.2. The final Phase 3 algorithm was tested with all freight
train types, including unit, manifest, and intermodal freight trains. However, since none of the
additional modifications made during the third phase apply to unit trains, the results of the
analysis for the unit train type match those from the analysis completed for the Phase 2
algorithm. Table 28 shows the overall results of the simulation testing for all train types, both
individually and combined into an overall result. This table includes the probability of stopping
short of the target and the probability of stopping short of the performance limit, defined as
stopping short of the target by < 500 ft for speeds < 30 mph and 1,200 ft for speeds ≥ 30 mph.
Appendices I and J contain the detailed results from simulation testing of the final Phase 3
algorithm.

Table 28. Phase 3 Algorithm Simulation Test Results

Probability of Stopping Short of Probability of Stopping Short of
Train Type
Target Performance Limit
Unit Freight 99.57% 7.59%

Manifest Freight 97.49% (99.34%) 13.44% (12.62%)

Intermodal Freight 97.85% 3.26%

Overall 98.73% (98.91%) 9.77% (8.24%)

The results of the evaluation for manifest freight trains showed poor results in terms of the
probability of stopping short of the target for light engine consists and very short trains (i.e., < 10
cars). An analysis of these cases indicated that an error in the final target offset function was the
likely cause. It is recommended that the target offset be modified for these cases and the
evaluation repeated as follow-on work to this project. So as not to skew the results of the
evaluation for the rest of the analysis, the manifest freight results and overall results are
presented in Table 28 without including the light locomotive or 3-car consists, in parentheses.
Table 28 shows that the algorithm ultimately fell short of the safety objective of stopping short of
the target 99.5 percent of the time for both manifest and intermodal freight trains. To
demonstrate how close the algorithm was to meeting the safety objective for these two train
types, an additional metric was calculated to show the location at which there was a 99.5 percent
probability of stopping short of, relative to the target. For the manifest freight trains, there was a
99.5 percent probability of stopping short of a location 6 ft past the target. For the intermodal
freight trains, there was a 99.5 percent probability of stopping short of a location 31 ft past the
target.

115
A more detailed look at the results reveals there are a few concentrated areas where the
probability of overrun was greater than desired that will need to be addressed in order to meet the
safety objective. A significant number of overruns occurred with longer trains, which were
ultimately attributed to the adaptive brake pipe propagation time function. In these cases, the
function calculated a brake pipe propagation time that was well short of the actual brake pipe
propagation time. A closer look revealed that this was because the function calculates the brake
pipe propagation time with the remote distributed power locomotives cut out, resulting, for these
cases, in extreme brake pipe pressure differentials from head end to rear end (i.e., greater than 20
psi), which had unpredictable effects on the function. In actual railroad operations, a train is not
allowed to depart the terminal with a brake pipe pressure differential of this magnitude; however,
when run with distributed power cut in, the brake pipe pressure differential for these cases was
acceptable. This presents an interesting case, where the brake pipe propagation time adaptive
function cannot properly calculate the propagation time, because the magnitude of the brake pipe
pressure differential is too large with distributed power cut out, yet the train can still operate with
distributed power cut in. It is recommended that these issues be looked at and addressed as
follow-on work to this project.
The data in Table 28 also shows the operational efficiency of the final developmental
enforcement algorithm, with manifest freight trains having a 12.62 percent probability of
stopping short of the performance limit and intermodal freight trains having a 3.26 percent
probability of stopping short of the performance limit. Although there are a few issues that need
to be investigated further, this evaluation shows that the algorithm developed comes very close
to meeting both the safety and performance objectives for all cases in the evaluation matrix.
This illustrates that a PTC braking enforcement algorithm that is both safe and results in minimal
impact on railroad operations is technically feasible.

116
16. Evaluation of Wabtec Enforcement Algorithm
The primary objective of this program was to develop techniques for an improved braking
enforcement algorithm for PTC systems with the goal of applying these techniques to production
systems planned for implementation in the North American freight rail industry. As such, one of
the tasks of the project was to support implementation of the techniques and evaluation of the
resulting enforcement algorithm for a cooperating railroad and their suppliers. BNSF Railway’s
Electronic Train Management System (ETMS) is a PTC system that has been functioning in both
pilot and production modes on select territories for many years. Wabtec, the supplier of the
onboard component of ETMS, has also developed the onboard component for what is known as
the I-ETMS®, which is currently the PTC system planned for implementation by all of the major
Class I railroads in the United States. Therefore, the railroad advisory group and Wabtec
supported the effort for implementation of improved methods for predictive braking enforcement
and evaluation of the algorithm.

16.1 Development Support

Throughout the project, TTCI, Wabtec, and the railroad advisory group worked together to
implement concepts developed to improve the performance of the braking enforcement
algorithm. However, because Wabtec is working to develop production software and hardware
for supporting PTC implementation on a large scale in accordance with a Federal mandate, the
techniques chosen for near-term implementation included only those with a high level of support
from railroads and regulators alike. These included a modified target offset function, emergency
brake backup, and a function for handling trains with distributed power. It is recognized that
other methods may be implemented in time, but these were seen as having the most significant
impact on the performance, enabling the successful implementation of the technology while also
supporting the implementation schedule.
In parallel with, and independent of TTCI’s algorithm research, Wabtec implemented techniques
to improve the target offset, add emergency brake backup, and improve distributed power
support for use in I-ETMS. With the use of TTCI’s recently published research, Wabtec intends
to review its algorithm for the potential of additional improvements. Through the course of
development at both TTCI and Wabtec, open discussion on performance requirements,
conceptual implementation solutions, and design recommendations between TTCI, Wabtec, and
the railroad advisory group members worked to contribute to an improved solution.
In addition to supporting the development of new functionality through these discussions, TTCI
worked to support Wabtec and the railroads by providing essential feedback on new enforcement
algorithm software builds through informal simulation testing. As new functions and
modifications to the algorithm logic were made, a number of interim software builds were
produced by Wabtec and provided as black box software applications to TTCI for checkout. By
running these interim builds through a relatively small batch of simulations representing a
variety of operating scenarios, it was possible to provide quick, higher-level feedback on the
safety and performance characteristics of the algorithm. The batch of simulations was small
enough to be run and produce results quickly, but was broad enough to highlight areas of
potential concern. As these areas were identified, more focused batches of simulations could be
run to help diagnose and address these concerns. This process of black box simulation testing to

117
support development and troubleshooting was identified as an important benefit of the simulation
environment and test process developed from this work.
Initially, the intent was to support implementation of the functions and evaluation of the
algorithm following each phase of development. However, because only some of the functions
were implemented and because the timing associated with getting the algorithm software
application and the test environment working, it was not useful or practical to perform
evaluations on multiple versions of the software. However, a new feature added to the Wabtec
algorithm offered the opportunity to provide useful data from multiple evaluations of the
algorithm. This new feature allows the train brake force to be provided to the onboard system at
train initialization. The concept is that information available in the back office server, but not to
the onboard system could be used to provide a more accurate estimate of brake force. If this data
is not provided, the algorithm reverts to using the original internal assumptions for brake force.
It was decided that evaluation of the algorithm both with this data provided, as well as without,
would provide the most useful data to the industry.

16.2 Simulation Testing

Simulation testing and analysis was performed on two different configurations of the Wabtec
algorithm for unit trains, manifest trains, and intermodal freight trains. The methodology
described in Section 2.2 was used to test and analyze both simulation sets. The first set of
simulation testing included providing the algorithm with an externally calculated value for the
estimated brake force of the train. Table 29 shows the summary results for these simulations and
the detailed results are provided in Appendix K. The second set of simulation testing was
performed without providing the algorithm with the externally calculated value for brake force.
Table 29 shows the summary results for these simulations, and Appendix L provides the detailed
results. The summary tables include the probability of stopping short of the target and the
probability of stopping short of the performance limit, defined as stopping short of the target by
less than500 ft for speeds < 30 mph and 1,200 ft for speeds ≥ 30 mph.

Table 29. Wabtec Algorithm Simulation Test Results (Brake Force Provided)
Probability of Stopping Short of Probability of Stopping Short of
Train Type Target Performance Limit
Unit Freight 99.00% 25.30%
Manifest Freight 98.51% 29.66%
Intermodal 99.87% 41.67%
Overall 99.03% 32.31%

The data in Table 29 shows that the algorithm met the safety objective of stopping short of the
target 99.5 percent of the time for intermodal freight trains, but fell short for both unit and
manifest freight trains. To demonstrate how close the algorithm was to meeting the safety
objective for these two train types, an additional metric was calculated to show the location at
which there was a 99.5 percent probability of stopping short of, relative to the target. For unit
freight trains there was a 99.5 percent probability of stopping short of a location 11 ft past the
target. For the manifest freight trains, there was a 99.5 percent probability of stopping short of a
location 34 ft past the target.

118
From the detailed results of the simulations where brake force was provided to the algorithm, a
few concentrated areas can be identified where a high probability of overrun was observed for
both unit and manifest freight trains. Wabtec is presently addressing the changes required to
reach the safety objective of 99.5 percent, but the simulation data with those changes was not
available at the time of publication of this report. From Table 29 it can also be shown that the
probability of stopping short of the performance objective for unit and manifest freight trains has
improved greatly over the base algorithm. For unit freight trains, the algorithm had a probability
of stopping short of the performance limit of 25.30 percent compared to 83.57 percent for the
base algorithm and for manifest freight trains, the algorithm had a probability of stopping short
of the performance limit of 29.66 percent compared to 70.89 percent for the base algorithm.
The second set of simulation testing was with the algorithm calculating a value for the estimated
brake force of the train. Table 30 shows the summary results for these simulations and the
detailed results are provided in Appendix L.

Table 30. Wabtec Algorithm Simulation Test Results (Brake Force Not Provided)
Probability of Stopping Short of Probability of Stopping Short of
Train Type Target Performance Limit
Unit Freight 99.4276% 38.75%
Manifest Freight 99.6711% 38.88%
Intermodal 99.8190% 43.60%
Overall 99.6620% 40.27%

The data in Table 30 shows that, overall, the algorithm met the safety objective of stopping short
of the target 99.5 percent of the time. The algorithm met the safety objective for manifest freight
and intermodal trains, but fell just short of the objective for unit freight trains. For the unit
freight trains, there was a 99.5 percent probability of stopping short of a point located 2 ft past
the target. The probability of stopping short of the performance limit was greater when brake
force was not provided to the algorithm. This was not unexpected, because the consist
information available to the algorithm is not as detailed as that which is available in the back
office server; therefore, this calculation must be more conservative. However, the probability of
stopping short of the performance level is still significantly better than that observed with the
base algorithm.

16.3 Field Testing at TTC

Field tests were performed with unit freight trains and manifest freight trains, in order to
demonstrate the performance of the current Wabtec algorithm. The field test setup included a
locomotive equipped with a Wabtec I-ETMS® onboard system, which housed the enforcement
algorithm, and a laptop used as a back office server simulator, which was used to send consist
and authority information to the onboard system. As with simulation testing, two configurations
of the algorithm were tested during this field test, as follows:
1. Brake force provided from off-board processor
2. Brake force calculated by onboard system
Three types of tests were performed during the testing of the Wabtec algorithm:

119
 • Safety — These tests are designed to demonstrate that the algorithm safely stops the train
short of the target. In these tests, the train is allowed to proceed toward the target with no
intent to stop, such that the enforcement algorithm must enforce a penalty brake
application to stop the train short.
• Safety with Application — These tests are designed to demonstrate that the algorithm
safely stops the train short of the target when a brake application is applied, which is
insufficient for stopping the train before the target. In these tests, the train is allowed to
proceed toward the target and a brake application is made that will not bring the train to a
stop before the target, such that the enforcement algorithm must enforce a penalty brake
application to stop the train short.
• Performance — These tests are designed to demonstrate whether the algorithm does or
does not interfere with normal crew actions to stop the train safely short of the target. In
these tests, the locomotive engineer stops the train short of the target using normal
operating procedures, including the use of dynamic brake.
Tables 31 and 32 show each of the test scenarios and the resulting average stopping locations
relative to the target for the unit freight test and the manifest freight test, respectively.
Table 31. Field Test Summary of Wabtec Algorithm with Unit Freight Train
Average Stopping Location Relative to Target
Test Conditions
(ft)

Speed Track With Brake Force Without Brake Force

Consist Test Type
(mph) Grade Provided Provided

90 Loaded Cars 10 Flat Safety -70 -140

90 Loaded Cars 10 Flat Performance -100 N/A

90 Loaded Cars 30 Flat Safety -226 -491

90 Loaded Cars 50 Flat Safety -590 -1095

90 Loaded Cars 30 Decline Safety -1183 -1890*

Safety with
90 Loaded Cars 30 Decline -586 N/A
Application

90 Loaded Cars 30 Decline Performance N/A -250

40 Loaded Cars 30 Flat Safety -80* -335*

40 Loaded Cars 30 Decline Performance -385 N/A

40 Loaded Cars 50 Decline Safety -265 -3170*

16 Loaded Cars 30 Flat Safety -65* -300*

16 Loaded Cars 30 Flat Performance -221 N/A

16 Loaded Cars 30 Decline Safety -580 N/A

*Emergency Brake Applied

120
 Table 32. Field Test Summary of Wabtec Algorithm with Manifest Freight Train
Average Stopping Location Relative to
Test Conditions
Target (ft)
Speed Track With Brake Force Without Brake Force
Consist Test Type
(mph) Grade Provided Provided
96 Cars –
10 Flat Safety -184 N/A
20 Loaded, 76 Empty
96 Cars –
10 Flat Performance -84 -56
20 Loaded, 76 Empty
96 Cars –
30 Flat Safety -660 -1,106
20 Loaded, 76 Empty
96 Cars –
50 Flat Safety -1,219 -1,219
20 Loaded, 76 Empty
96 Cars –
30 Decline Safety -1,203 -2,139
20 Loaded, 76 Empty
96 Cars – Safety with
30 Decline -583 N/A
20 Loaded, 76 Empty Application
96 Cars –
30 Flat Performance -250 N/A
20 Loaded, 76 Empty
96 Cars –
30 Incline Safety -315 -582
20 Loaded, 76 Empty
96 Cars –
30 Crest Safety -495 -911
20 Loaded, 76 Empty
40 Cars –
30 Flat Safety -273 -580
10 Loaded, 30 Empty
40 Cars –
30 Decline Performance -109 N/A
10 Loaded, 30 Empty
40 Cars –
50 Decline Safety -1,145 N/A
10 Loaded, 30 Empty
16 Cars –
30 Flat Safety -202 -575
4 Loaded, 12 Empty
16 Cars –
30 Flat Performance -98 N/A
4 Loaded, 12 Empty
16 Cars –
30 Decline Safety -770 -2,293
4 Loaded, 12 Empty

As the data shows in Tables 31 and 32, the Wabtec algorithm stopped the train short of the
target in all of the safety cases that were performed. It also shows that the algorithm is more
conservative if brake force is not provided to the system, which is consistent with expectations
and the results seen in the simulation data. Also, the Wabtec algorithm did not enforce a penalty
application during any of the performance test cases.

121
Overall, the field evaluation of the Wabtec algorithm was shown to compare well with the
simulation testing. The results showed that the algorithm stops the train safely short of the target
for a broad range of test cases, and it does not adversely interfere with the locomotive engineer
during normal operations. The performance of the algorithm overall was shown to be far better
than the base algorithm, demonstrating the improvement achieved with the concepts
implemented for improving the accuracy and operational efficiency of the algorithm.

122
17. Development and Testing of V-PTC Enforcement Algorithm
One of the objectives of this effort was to develop enforcement algorithm logic that is ready for
implementation in a PTC system. To support this objective, the complete enforcement algorithm
logic was documented in an enforcement algorithm description document at the completion of
each phase of development. Near the completion of the first phase of enforcement algorithm
development, there was an opportunity to implement and test this enforcement algorithm logic in
a developmental PTC system to the mutual benefit of this project and another FRA project: the
V-PTC Research and Development project [5].
The objective of the V-PTC Research and Development project was to develop, test, and
demonstrate a V-PTC system with a centralized architecture and moving-block capability. As
part of this project, FRA funded the development of system specifications as well as testing and
demonstration activities, and LMC provided in-kind services to design and develop the system
components. The system development was organized into a number of functional builds to
incrementally demonstrate system functionality. One of these builds included predictive
enforcement of authority and speed limits, which requires a braking enforcement algorithm.
Evaluation of the developmental enforcement algorithm logic implemented in the V-PTC
onboard system was conceived to benefit the V-PTC project as well as the enforcement
algorithm research and development project by demonstrating the safety and performance
characteristics of the enforcement algorithm logic implemented in a functional PTC system. As
such, FRA provided funding to support the development and evaluation of the Phase 1
enforcement algorithm logic in the V-PTC system.

17.1 Development and Simulation Test Support

The schedule for development and testing of the enforcement algorithm in the V-PTC system
was driven by the V-PTC project. In order to support the schedule for that project, development
efforts had to begin before the Phase 1 enforcement algorithm developmental logic was
completed. The development and testing efforts were broken into the following four stages to
allow development efforts on the V-PTC software to begin prior to completing the Phase 1 logic:
• Stage 1 — Development and simulation testing of the revised base enforcement
algorithm
• Stage 2 — Development and simulation testing of the Phase 1 enforcement algorithm
• Stage 3 — Field testing of the Phase 1 enforcement algorithm with externally supplied
stopping targets
• Stage 4 — Field testing of the Phase 1 enforcement algorithm with system generated
stopping targets from authorities provided by a simulated dispatch system
The four stages offered a progressive buildup of functionality, allowing development to begin
while the algorithm logic, as well as supporting system functionality was completed, and testing
of each of the progressively more complex builds was conducted.
To begin implementation of the enforcement algorithm in the V-PTC system, a draft version of
the developmental enforcement algorithm definition document was provided to LMC with only
the revisions to the base enforcement algorithm logic included. LMC implemented this

123
functionality into a standalone brake enforcement algorithm application that could interface the
simulation test environment according to the communications protocol specified in the document
included in Appendix B. TTCI supported the implementation by providing source code snippets
and further descriptions where necessary to clarify specific items in the documentation. This
feedback from a PTC supplier was also used to improve the algorithm definition document.
Throughout the development process, simulations were run for a wide variety of test cases to
verify that the enforcement algorithm was functioning as expected. The simulation results were
compared against the results with the developmental test version of the algorithm software to
ensure that the algorithm logic was implemented consistent to the test application. This provided
a redundant check to ensure that the test software developed by TTCI matched the documented
logic and the software developed by LMC.
After the design and documentation of the Phase 1 functions was complete, the updated
document was provided to LMC for implementation in the V-PTC software. Again, a standalone
brake enforcement algorithm application was developed for verification with simulation testing.
The enforcement algorithm was also implemented in the V-PTC onboard system software for
field testing.

17.2 Field Testing at TTC

After the Phase 1 developmental algorithm was implemented in the V-PTC onboard software, a
series of field tests were performed to verify the performance of the algorithm logic as
implemented in a functional PTC onboard system. The field tests were run using the algorithm
incorporated in the V-PTC onboard system, with the algorithm developmental test application
running in the background on a separate computer for comparison purposes.
Three types of tests were performed during the testing of the V-PTC algorithm, as follows:
• Safety — These tests are designed to demonstrate that the algorithm safely stops the train
short of the target. In these tests, the train is allowed to proceed toward the target with no
intent to stop, such that the enforcement algorithm must enforce a penalty brake
application to stop the train short.
• Safety emergency brake backup — These tests are designed to demonstrate that the
algorithm safely stops the train short of the target by using the emergency brake backup
function when the initial penalty brake application is insufficient for stopping the train
before the target. In these tests, the train is allowed to proceed toward the target with no
intent to stop, such that the enforcement algorithm must enforce a penalty brake
application. At this point, the test crew controls the trailing locomotives to power against
the penalty brake application, simulating a train that is not stopping as expected, such that
the enforcement algorithm must enforce an emergency brake application to stop the train
short.
• Performance — These tests are designed to demonstrate whether the algorithm does or
does not interfere with normal crew actions to stop the train safely short of the target. In
these tests, the locomotive engineer stops the train short of the target using normal
operating procedures, including the use of dynamic brake.
Table 33 shows each of the test scenarios and the resulting average stopping locations relative to
the target.

124
 Table 33. Field Test Summary of LMC V-PTC Algorithm
Test Conditions
Average Stopping Location
Speed Track Relative to Target (ft)
Consist Test Type
(mph) Grade
40 Loaded Cars 30 Flat Safety -418
40 Loaded Cars 30 Flat Performance -171
Safety -424
40 Loaded Cars 30 Flat Emergency
Brake Backup
40 Loaded Cars 60 Flat Safety -86*
40 Loaded Cars 30 Decline Safety -675
40 Loaded Cars 30 Decline Performance 499*
40 Loaded Cars 60 Decline Safety 1,880* (-1,051)
40 Loaded Cars 30 Varying Safety -171
90 Loaded Cars 10 Flat Safety -151
90 Loaded Cars 10 Flat Performance -139
90 Loaded Cars 30 Flat Safety -447
90 Loaded Cars 10 Decline Safety -376
90 Loaded Cars 30 Decline Safety -1,121
90 Loaded Cars 30 Varying Safety -366
10 Loaded Cars 30 Flat Safety -751
10 Loaded Cars 30 Flat Performance -681
10 Loaded Cars 30 Decline Safety -1,858
* Hardware on locomotive prevented proper application of emergency brake
(the stopping location relative to the target with the emergency applied)

The V-PTC implementation of the Phase 1 algorithm correlated well to the developmental test
application of the algorithm running in the background on a separate computer. The
enforcement locations for each test case were, in most cases, at the exact same time for both
applications, and within a few seconds of each other for the rest. For some of the test cases,
there was an issue with the hardware on the locomotive that prevented proper application of the
emergency brake, although the algorithm attempted to apply it. These cases are indicated in
Table 33 with an asterisk next to the value for the average stopping location relative to the target.
In two of these cases, the train exceeded the target stopping location, and in the third case, the
train stopped very close to the target, particularly given the test speed (i.e., 86 ft short of the
target from 60 mph), indicating that the emergency brake application was indeed justified for
these cases. The hardware issue was resolved and the emergency brake properly applied on the

125
remaining cases. Time and budget allowed for the one of these test cases (the 40-car, 60 mph,
decline grade case) to be rerun after the issue was resolved to demonstrate the stopping location
was short of the target when the emergency was properly applied. For this case, the stopping
location relative to the target with the emergency applied is indicated in parentheses.
The field testing of the V-PTC braking enforcement algorithm implemented by LMC
successfully demonstrated the safety and performance characteristics of the Phase 1
developmental enforcement algorithm as implemented in a functional PTC onboard component.
This supports the applicability of the algorithm developed in a fully functional PTC system, as
opposed to operating as a standalone application. The testing also demonstrated that the
documentation of the developmental algorithm was sufficient for developing a working
implementation of the algorithm logic matching that intended during the development of the
algorithm. Overall, this task helps to demonstrate the feasibility of developing these techniques
as an implementation ready set of logic to improve the operational performance of the algorithm
for an independently developed PTC system.

126
18. Conclusions
Throughout the course of the project, several techniques for improving the safety and
performance of enforcement algorithms for PTC systems were researched and tested. Results of
these tests showed that improvements in operational performance are indeed possible, without
negatively affecting the safety of the system. Further, a formal methodology was developed for
demonstrating the safety and performance characteristics of any PTC enforcement algorithm,
which will allow for future versions of algorithms from various sources to be reliably tested to
confirm their suitability for use in a functional system without the expense of lengthy field test
processes.
In the first phase of the project, it was shown that the safety objective for the enforcement
function of a PTC system need not be excessive. The safety benefits of PTC not related to the
enforcement function, combined with the already safe nature of the railroad operation, lessen the
need for an excessively conservative enforcement algorithm. The analysis presented allows for a
probability of 99.5 percent for stopping the train short of the target, which can ultimately result
in a significant reduction in early warnings and enforcements over the previously suggested
99.9995 percent probability and still provide considerable improvement in safety over the
traditional signal systems used today. The impact of this analysis can be shown with the
dramatic reduction in target offset levels used in the developmental algorithm as compared with
the base algorithm.
Enforcement algorithm development in the first phase included improvements to the base
algorithm logic, an improved target offset function, adaptive features, emergency brake backup,
and functionality for handling trains with distributed power. The second phase expanded further
with functions for handling use of locomotive braking, including dynamic braking and
independent/automatic braking during PTC penalty enforcement. Finally, in the third phase, the
functions previously developed were expanded to work on all train types. Each of these
functions was shown to improve the performance of the algorithm individually through field
testing, as well as aggregately through simulation testing. Although simulation testing of the
final version of the developmental algorithm showed that it falls just short of the objective for
stopping short of the target (98.91 percent), TTCI knows the minor modifications and tweaks
required to bring the algorithm into conformance with the requirements. These will be done as
part of the follow-on work.
The safety of the algorithm is paramount, but the operational performance improvements seen
from the developments employed cannot be overlooked. The base enforcement algorithm had an
overall probability of stopping short of the performance limit of 75.06 percent. Although this
measure is not a precise indication of the level of operational impact the algorithm will
ultimately have, it can be generally stated that the lower this probability, the less impact the
algorithm will have. The final developmental algorithm had a probability of stopping short of
the performance limit of just 8.24 percent, a tremendous improvement over the base algorithm.
This shows the enormous potential the concepts and techniques researched here can have on PTC
systems and their impact on railroad operations.
Each of the techniques researched has its own pros and cons, but it is apparent from this project
that some have more potential to improve the safety and performance of the system, with
potentially less effort, than others. For example, the emergency brake backup function

127
significantly improves the performance of the algorithm, and it also has safety benefits.
Furthermore, it enables many of the other functions developed. For instance, the distributed
power function relies on the emergency brake backup function to mitigate the risk of overrun in
the case the distributed power communications link fails at the point of enforcement. This
enabling feature of the emergency brake backup function makes it an almost essential
improvement to the algorithm. The only drawback of this function is the requirement of an
additional interface to the brake system, but this is a minor drawback, considering the amount of
additional hardware that already needs to be installed on locomotives for PTC to function.
It is expected that railroads and their suppliers may initially adopt only some of the concepts
introduced in this project. This has been shown to be the case to date with the algorithm Wabtec
is developing for the I-ETMS® system. However, the concepts added to this algorithm have also
shown dramatic improvement over the base algorithm. The algorithm developed by Wabtec was
shown to have a probability of stopping short of the performance limit of 40.27 percent. The
operational areas where the algorithm performed less efficiently were primarily those on steep
downgrades, where dynamic brake is used extensively to control the speed of the train. As PTC
system deployment is continued, this may be an area where further improvement can be seen by
adopting other concepts investigated under this project.
Although many of the techniques developed as part of this project have not yet been adopted into
systems currently in use, the results of this project are significant, because they have advanced
the state of PTC enforcement algorithm technology and have shown the potential for
improvement over traditional methods. The groundwork laid here will set the expectations for
the level of performance for PTC enforcement algorithms as the technology continues moving
forward.

128
19. References

1. Brosseau, J., Moore Ede, B. (June 2009) “Development of an Adaptive Predictive Braking
Enforcement Algorithm,” DOT-FRA-ORD-09/13, U.S. Department of Transportation,
Federal Railroad Administration, Office of Research and Development, Washington, D.C.
2. Manos, W.P., Hawthorne, K.L., Misner, G., Brown, T. (April 1981) “Brake Shoe
Performance,” Research Report R-469, AAR Technical Center, Chicago, IL
3. Anderson, G.B., Manos, W.P., Wilson, N.G. (December 1983) “Brake Shoe Performance
Test II: 1982-83 Pueblo, Colorado Test Series,” Research Report R-565A, AAR Technical
Center, Chicago, IL
4. Association of American Railroads. (2002) AAR Manual of Standards and Recommended
Practices. Section K. “End-of-Train Communications.” Standard S-5701, Washington, D.C.
5. Morgan, R., Mauger, D., Brosseau, J. (March 2011) “Vital-Positive Train Control Research
and Development Final Report.” DOT/FRA/ORD-11/14, U.S. Department of Transportation,
Federal Railroad Administration, Office of Research and Development, Washington, D.C.
6. Association of American Railroads. (2007) AAR Manual of Standards and Recommended
Practices. Section E. “Brake Design Requirements.” Standard S-401, Washington, D.C.
7. Carlson, F. (October 2002) “Body-mounted Brake Rigging.” Technology Digest TD-02-022.
Association of American Railroads, Transportation Technology Center, Inc., Pueblo, CO.
8. Grenci, L. and Nese, J. (2001) A World of Weather: Fundamentals of Meterology. Dubuque:
Kendall/Hunt. p. 95
9. National Oceanic Atmospheric Administration.
http://ols.nndc.noaa.gov/plolstore/plsql/olstore.prodspecific?prodnum=C00095-PUB-A0001.
Climatological normals for 1971-2000.
10. Dynisco. (2012) Dynisco Model PT311JA Flush Diaphragm Pressure Transducer Datasheet.
Franklin, MA.
11. Carriere, K., Gallagher, B. (2011) “What’s the Force? Degradation of Brake Forces.” Proc.
103rd Annual Convention and Technical Conference of Air Brake Association.
12. Hay, William W. (1982) Railroad Engineering. Second Edition, John Wiley & Sons, Inc.
13. Association of American Railroads (2012) Field Manual of the AAR Interchange Rules.
Washington, D.C.
14. Statsoft. (2011) STATISTICA. Version 10. Tulsa, OK.
15. Rychlik, I. Ryden, J. (2006) Probability and Risk Analysis: An Introduction for Engineers.
Heidelburg: Springer.
16. Annapurva, R. Butar, F.B. (2010) “An Insight into Heavy-Tailed Distribution.” Journal of
Mathematical Sciences and Mathematical Education. Vol. 5.

129
17. Conort, X. (2010 Jan.-Jun.) “Quantile Estimation of Heavy Tail Distributions and Model
Risks of EVT Techniques.” Bulletin Facais D’ Actuariat. Vol. 10, n19, pp. 63-109.
18. MathWave Technologies. (2010, Dec 3) Easy Fit Professional. Version 5.5. Spokane, WA
19. ICF Consulting (2006) “Technology Driven Operations Comparative Risk Assessment.”
Report to Association of American Railroads, Washington, D.C.
20. IEC 61508. “Functional Safety of Electrical/Electronic/Programmable Electronic Safety-
related Systems.” International Standard of Rules.
21. Wabtec Railway Electronics. (2003, Jan. 10) “IDOT PTC Project Braking and Prediction
Algorithm Definition.” Revision C. Cedar Rapids, IA.
22. Kutner, M.H., Nachtscheim, C.J., Neter, J. (2004) Applied Linear Regression Models. 4th
Edition. Chicago: McGraw Hill/Irwin.
23. Association of American Railroads. (2010) AAR Manual of Standards and Recommended
Practices, Section M. “Braking Ratios for Locomotives.” Standard RP-509 and “Basic
Brake Design Data for Freight Locomotives.” Standard RP-5209, Washington, D.C.
24. Association of American Railroads. (2010) AAR Manual of Standards and Recommended
Practices, Section M. “Locomotive Dynamic Brake Status Reporting.” Standard S-5509,
Washington, D.C.
25. Montgomery, Douglas C. and Runger, George C. (2007) Applied Statistics and Probability
for Engineers. Fourth Edition, John Wiley & Sons, Inc.
26. StatSoft, Inc. (2013). Electronic Statistics Textbook. Tulsa, OK: StatSoft. WEB:
http://www.statsoft.com/textbook/

130
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

Appendix A.
Enforcement Algorithm Evaluation Methodology Document

Methodology for Evaluation of

PTC Freight Train Braking
Enforcement Algorithms
Version 1.2

9/1/2011

Prepared by:

Transportation Technology Center, Inc.

a subsidiary of the Association of American Railroads

With funding from:

Federal Railroad Administration

131
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

Revision History

Date Revision Description

8/4/11 1.0 Initial draft
8/5/11 1.1 Incorporated comments from internal review
9/1/11 1.2 Incorporated comments from advisory group

132
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

Table of Contents

1 Introduction ......................................................................................................................... 134

1.1 Purpose .................................................................................................................... 134
1.2 Intended Audience ................................................................................................... 134
1.3 Definitions and Acronyms....................................................................................... 134
2 Overview ............................................................................................................................. 136
3 Simulation Testing............................................................................................................... 140
3.1 Overview of Simulation Testing Process ................................................................ 140
3.2 Simulation Testing Operating Scenarios ................................................................. 141
3.3 Simulation Testing Variable Parameters ................................................................. 145
4 Field Testing ........................................................................................................................ 147
4.1 Enforcement Algorithm Field Testing .................................................................... 147
4.2 Repeatability Field Testing ..................................................................................... 149
4.3 Field Testing for Comparison against Simulation Results ...................................... 149
5 Analysis and Reporting ....................................................................................................... 150
5.1 Simulation Testing Analysis ................................................................................... 150
5.2 Comparison of Field and Simulated Enforcements ................................................. 152
5.3 Analysis of Stopping Distance Repeatability .......................................................... 153
5.4 Comparison of Identical Field and Simulated Stopping Distance Tests ................. 153
5.5 Reporting ................................................................................................................. 153
6 References ........................................................................................................................... 154

133
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

A1. Introduction

A1.1 Purpose
The purpose of this document is to provide a technical description of the proposed methodology
for evaluation of braking enforcement algorithms for positive train control (PTC) applications.
The intent of this methodology is to specify the empirical and analytical processes of generating
and analyzing data in support of the comprehensive safety and performance analysis of a
particular PTC implementation.

A1.2 Intended Audience

This document is intended for developers, suppliers and end users of positive train control
systems that require data generation and analysis to verify the safety and performance of the
enforcement function of the system as well as for regulators responsible for the approval and
acceptance of these systems.

A1.3 Definitions and Acronyms

A1.3.1 Definitions
The following terms are used in the document:
• Degree of curvature – The central angle turned over a 100 foot chord length, expressed in
degrees.
• Distributed power – A descriptive term for a train that includes more than a single group
of locomotives distributed throughout the train, separated by groups of non-powered cars
• Emergency air brake application – A rapid reduction of the brake pipe pressure to
atmospheric pressure. An emergency brake application results in higher brake force as a
result of the control valve directing air from both the auxiliary and emergency reservoirs
to the brake cylinder.
• Monte Carlo simulation method – A method of modeling physical systems with many
coupled degrees of freedom through the use of repeated random sampling and analysis of
the combined results.
• Onboard computer – The computer onboard the locomotive used for collecting train
status and enforcement test target information and applying brake enforcements.
• Penalty air brake application – A reduction of the brake pipe pressure at a service rate
that results in the control valve directing air from the auxiliary reservoir to the brake
cylinder until equalization is reached.
• Positive Train Control (PTC) – A form of train control where train movement authorities
and speed limits are transmitted electronically and automatically enforced to prevent
violations. FRA has defined four minimum requirements for a PTC system. The system
must prevent:
▬ Train-to-train collisions,
▬ Over-speed derailments,
▬ Incursions into established work zone limits, and
▬ Movement of a train through a switch left in the wrong position.

134
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

• Predictive braking enforcement algorithm – A computational algorithm that predicts the

braking profile of a train and, if necessary, enforces a penalty brake application to prevent
a violation of a movement authority or speed limit. Also described as “enforcement
algorithm” or simply “algorithm”.
• Target – A location where the train must be at or below a given speed. The target
locations are used by the enforcement algorithm to determine if a penalty air brake
application is necessary.

A1.3.2 Acronyms
The following is a list of acronyms used within this document:
• AAR – Association of American Railroads
• ALD – Automatic Location Detector
• COFC – Container on Flat Car
• EDA – Exploratory Data Analysis
• GPD – Generalized Pareto Distribution
• POT – Peaks-over-Threshold
• PTC – Positive Train Control
• TCL – Test Controller/Logger
• TOES – Train Operations and Energy Simulator
• TOFC – Trailer on Flat Car

135
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

A2. Overview
Successful implementation of positive train control demands a safe and operationally efficient
braking enforcement algorithm. In order to verify that a braking enforcement algorithm meets
specified safety and performance objectives, a test methodology must be defined to quantify the
safety and performance of the algorithm according to defined measures.
From a safety standpoint, the objective of such a methodology is to demonstrate a high degree of
confidence that any given train, in any given operational scenario, will stop short of a given
target stopping location as a result of PTC brake enforcement. Historically, this objective has
been expressed as a probability that a train will stop short of a target stopping location with a
given confidence level, as shown in figure 1. Research has shown an appropriate safety
objective as a 0.995 probability of stopping short of the target with a 0.99 confidence level. As
such, the methodology described within this document aims to quantify the probability of
stopping short of the target for the particular PTC braking enforcement algorithm under
evaluation for comparison against this objective, among other performance measures.

136
Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

137
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

Figure A21: PTC Predictive Braking Enforcement Algorithm Safety Objective

Evaluation of PTC braking enforcement algorithms has generally been accomplished through
field testing of the enforcement function on revenue service track. While this may be appropriate
for final verification of the enforcement function, it presents several disadvantages. First, it is
costly and time-consuming. It impacts the operation of the railroad, in terms of affecting
capacity and causing interference to other revenue traffic. It also does not provide the highest
level of statistical confidence in the safety and performance of the algorithm, as it is not possible
to perform a sufficient number of live field tests within the timeframe required for system
deployment. There is limited control over test conditions, in terms of boundary condition (e.g.
worst-case) scenarios. While specific operating conditions, such as track grades and train speeds
may be possible, it is unlikely that a given test train will exhibit boundary condition
characteristics. The potential for repeatability testing is also very limited, and the quantity of
field tests practically achievable generally falls short of what is needed for adequate statistical
significance.
The methodology presented within this document seeks to overcome these disadvantages,
through a combination of computer simulation testing in a lab environment and field testing in a
controlled test environment, resulting in a reduced amount of revenue service field testing. As
part of this methodology, the simulation testing is used to statistically quantify the safety and
performance of the enforcement function by running large batches of simulations with Monte
Carlo variation of train and environmental characteristics that affect train stopping distance.
Limited field testing in a controlled environment provides validation of the simulation results
using actual hardware inputs to the enforcement algorithm. The final verification of the
enforcement algorithm safety and performance is provided on only the necessary boundary
conditions (e.g. steep grades) through revenue service testing.
The focus of this evaluation methodology is on the results of the simulation testing. This testing
provides the capability to test the enforcement algorithm over a wide range of operating
scenarios, including boundary conditions, in a safe and efficient manner. It also provides more
comprehensive statistical data on the safety and performance of the enforcement algorithm when
compared to the alternative.
The key to using the simulation data as the core of the evaluation is to provide adequate
empirical data to ensure that it properly represents how the enforcement algorithm will perform
in the field. The evaluation methodology provides this verification through three types of field
testing. The first is enforcement field testing, both in a controlled environment and revenue
service, which is compared to results of simulation testing. The second is repeatability testing to
establish the consistency in freight train stopping distance for a given set of conditions, which is
used to verify the parameters selected for Monte Carlo variation in the simulation testing process
and quantify any variability in stopping distance not captured through the Monte Carlo variation.
The final type of field testing is stop distance testing where all practical parameters are precisely
measured for direct comparison to simulation testing, to verify the accuracy of the model used,
and quantify any systematic error between the model and the actual performance of the field
hardware.
The results of the enforcement algorithm simulation testing are combined with the results from
the enforcement algorithm field testing, repeatability testing, and stop distance testing and
analyzed to quantify the safety and performance of the enforcement algorithm. Finally, the
138
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

results are compared against pass/fail criteria to demonstrate the safety and performance of the
enforcement function.
The specific details of each of the components of the enforcement algorithm evaluation
methodology are further described in the remaining sections of this document.

139
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

A3. Simulation Testing

The objective of the simulation testing portion of the enforcement algorithm evaluation
methodology is to provide data for statistically quantifying the safety and performance of the
enforcement algorithm being evaluated. This is achieved by running large batches of
enforcement simulations that are representative of the distribution of possible enforcement
outcomes for a range of operating conditions.

A3.1 Overview of Simulation Testing Process

Figure 2 shows a conceptual diagram of the components used for simulation testing. The
simulation testing process makes use of the Train Operations and Energy Simulator (TOESTM), a
longitudinal train dynamics and energy model developed and fully validated by the Association
of American Railroads (AAR). The TOESTM model includes a complete fluid dynamics model
of the air brake system, which allows for accurate modeling of a wide variety of air brake
equipment, making it the ideal tool for performing braking enforcement algorithm testing.

Figure A2: Simulation Testing Components

The simulation testing process also makes use of a test controller and logger (TCL) software
component, which sets up and executes batches of TOESTM simulations. Each batch of
simulations represents a single operating scenario and each simulation within the batch
represents a possible random outcome of the given operating scenario. The operating scenarios
are defined by the train make-up, longitudinal track profile (i.e., grade and curvature), and initial
train speed. Each unique simulation within the batch is defined by randomly varying the key
parameters that affect the train stopping distance, according to predefined input distributions, in a
Monte Carlo process.
The TCL software executes each simulation within the TOESTM model by approaching the given
target location at the test speed and providing feedback from TOESTM to the enforcement
algorithm, implemented as a black-box software component. TCL provides the enforcement
algorithm with the required data over a pre-defined interface at regular simulated time intervals.
The enforcement algorithm commands a penalty brake enforcement to TCL, over the pre-defined
interface, to prevent a violation of the target stopping location provided. The enforcement is
initiated in the TOESTM model by the TCL software and the simulation continues until the train
is stopped. In some cases, the enforcement algorithm may also command an emergency brake

140
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

enforcement, also initiated in the TOESTM model by the TCL software. The output of each
simulation is logged by the TCL software for later analysis.
There are a total of 4286 batches (operating scenarios) in the simulation testing methodology.
100 unique simulations are run for each of these batches (operating scenarios), where the key
parameters that affect the stopping location of the train are varied randomly for each simulation,
for a total of 428,600 simulations. The results of each individual simulation are combined for all
the simulations within each batch (operating scenario) and used to determine the safety and
performance characteristics of the enforcement algorithm for each given operating scenario.
These results can then be combined to determine the overall safety and performance
characteristics of the enforcement algorithm.

A3.2 Simulation Testing Operating Scenarios

The operating scenarios defined for simulation testing are intended to capture the range of
operating conditions that the PTC system will regularly and frequently encounter. It is
recognized that it is neither possible nor necessary to simulate or test every possible operating
scenario, and specific scenarios that vary greatly from those defined may need additional focus
beyond what is defined in this methodology. The operating scenarios are defined by the test
consist and the operating conditions, as described in the following sections.

A3.2.1 Test Consists

Simulation testing is performed using a range of test consists, based on railroad historical data on
revenue service train consists. These are broken down into three logical groups:
1. Unit freight trains
2. Manifest freight trains
3. Intermodal freight trains

Unit Freight Trains

Unit freight trains are defined as those consisting entirely of a single car type. There are a total
of 60 unit train consists. Each unit train consist represents a unique combination of train
makeup, length, loading condition and power arrangement.
There are six types of unit trains, defined by the car type, as follows:
• Unit aluminum hopper
• Unit steel hopper
• Unit covered hopper
• Unit tank
• Unit refrigerated boxcar
• Unit multilevel (vehicular flat car)
There are four train lengths defined for unit freight operations, as follows:
• 100 cars
• 135 cars
• 200 cars (unit aluminum hopper and unit steel hopper trains only)
• 260 cars (unit aluminum hopper and unit steel hopper trains only)
141
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

There are two types of loading conditions defined for unit freight trains:
• Fully loaded
• Fully empty
There are three types of power arrangements defined for unit freight trains:
• Head end power only (100-car trains only)
• Head and rear end distributed power (100-car, 135-car, and 200-car trains only)
• Head, mid, and rear end distributed power (135-car, 200-car, and 260-car trains only)

Manifest Freight Trains

Manifest freight trains are defined as having a mix of car types and loads throughout the train.
There are a total of 114 manifest freight train consists. The number of manifest freight train
consists represents a unique combination of train length, power arrangement, locomotive type,
and train make-up/loading.
There are seven train lengths defined for manifest freight operations:
• 0 cars (light locomotives)
• 3 cars
• 10 cars
• 40 cars
• 100 cars
• 150 cars
• 200 cars
There are three types of power arrangements defined for manifest freight trains:
• Head end power only (0 car, 3-car, 10-car, 40-car, and 100-car trains only)
• Head and rear end distributed power (100-car, 150-car, and 200-car trains only)
• Head, mid, and rear end distributed power (150-car, and 200-car trains only)
For short trains, where locomotive weight becomes a significant factor and locomotive brakes
may be applied, it is necessary to test the algorithm performance with various locomotive types.
There are two types of locomotives for manifest freight trains:
• 4000-horsepower, 6-axle SD70MAC locomotives
• 3000-horsepower, 4-axle GP40-2 locomotives (0-car, 3-car, and 10-car trains only)
The manifest freight trains are made up of a pseudo-random mix of potential car types and
contain varying loading conditions throughout the train, based on actual railroad train manifest
data. The car types include:
• Box cars
• Covered hoppers
• Gondolas
• Flat cars
• Open-top hoppers
• Aluminum coal gondolas
• Tank cars
142
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

• TOFC/COFC flat cars

• Multilevels
For each combination of train length, power arrangement, and locomotive type, ten unique
consists are generated using the pseudo-random car type selection process. Of these, one consist
contains all fully loaded cars, one contains all empty cars, and the remaining eight contain cars
loaded based on the pseudo-random car load selection process. For the case of light
locomotives, train make-up and car loads do not apply, so there are only two consists for each
locomotive type; one with a single locomotive, and the other with three locomotives.

Intermodal Freight Trains

Intermodal freight trains are defined as being made up entirely of intermodal well cars. There
are a total of 70 intermodal freight train consists. The number of intermodal freight train consists
represents a unique combination of train length, base loading condition, power arrangement, and
train make-up/loading condition.
There are four train lengths defined for intermodal freight operations:
• Short – approximately 5,000 feet
• Medium – approximately 7,500 feet
• Long – approximately 10,000 feet
• Very long – approximately 15,000 feet
There are two types of base loading conditions defined for intermodal freight trains:
• Loaded
• Empty
There are three types of power arrangements defined for intermodal freight trains:
• Head end power only (short and medium length trains only)
• Head and rear end distributed power (short, medium, and long train lengths only)
• Head, mid, and rear end distributed power (long and very long train lengths only)
The intermodal trains are made up of a pseudo-random mix of potential car types and contain
varying loading conditions throughout the train, based on actual railroad train manifest data. The
car types include:
• Single platform intermodal well cars
• Three-pack intermodal well cars
• Five-pack intermodal well cars
For each combination of train length, base loading condition, and power arrangement, five
unique consists are generated using the pseudo-random car type selection process. For the cases
where the base loading condition is loaded, one of the five consists contains all fully loaded cars,
and the remaining four contain cars loaded based on the pseudo-random car load selection
process for loaded intermodal consists. For the cases where the base loading condition is empty,
one of the five consists contains all empty cars, and the remaining four contain cars loaded based
on the pseudo-random car load selection process for empty intermodal consists (in many cases,
trains are designated empty, but actually contain variations in loading due to empty containers,
etc.).
143
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

A3.2.2 Operating Conditions

Each test consist is simulated under a number of operating conditions. Each operating condition
represents a unique combination of train speed, track grade, and track curvature. The operating
conditions are based on the boundary conditions of allowable operating conditions. Figure 3
illustrates how the boundary speed/grade conditions were determined based on the allowable
speeds for various train types on various sustained grades. The X’s in figure 3 show speed/grade
combinations that are simulated on declining grades.

Figure A3: Boundary Operating Conditions for Simulation Testing

In addition to the decline grades, simulations are run on inclines and undulating (crest and
trough) grades. Table 1 shows the test speeds for simulation testing for each of the grade
scenarios and train types. In some cases, two speeds are shown, indicating that the test speed is
based on the specific consist.
Table A1: Simulation Testing Speeds by Track Grade and Train Type

These operating scenarios represent all of the practical consist, speed, and grade combinations on
tangent track. In addition, to evaluate the ability of the enforcement algorithm to properly handle
operating scenarios on curved track, a subset of the consist, speed, and grade combinations are
144
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

run on curves. This subset represents the three train types over a variety of grades and speeds,
and is tested on 2-degree, 4-degree, 8-degree, and 15-degree curves, as allowable for the specific
test speed.

A3.3 Simulation Testing Variable Parameters

There are a number of parameters that affect the stopping distance of a train in a PTC
enforcement scenario. Simulation testing is used to quantify the variability in train stopping
location during a PTC enforcement scenario by varying these parameters using a Monte Carlo
method, according to input distributions that are representative of their actual, real-world
variability. These parameters and associated input distributions are based on a combination of
research, literature review, field measurements, and expert opinion, in order to represent reality
as accurately as possible.
A total of 28 parameters have been identified as having an impact on train stopping location
during a PTC enforcement scenario. Of these, 22 have been identified as having the potential to
have a significant effect on train stopping location. Input distributions have been defined for
these 22 parameters, which are varied in simulation testing. The remaining six parameters have
been determined to have a relatively insignificant effect and may be impractical to vary in the
simulation. Table 2 shows all 28 parameters, along with the source of their input distribution for
the 22 parameters that are varied in simulation testing. The six parameters that are not varied in
simulation testing are indicated in the table, as well.

145
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

Table 2: Varied Parameters for Simulation Testing

146
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

A4. Field Testing

The objectives of the field testing portion of the enforcement algorithm evaluation methodology
are to:
(a) provide enforcement test data to demonstrate the safety and performance of the
enforcement algorithm using actual PTC hardware and railroad equipment
(b) verify that the parameters varied in simulation testing are appropriate by demonstrating
the level of repeatability in stopping distance, given identical inputs for the parameters
varied in simulation testing
(c) verify that the simulation results are representative of actual, real-world enforcement
results
Each of these objectives is achieved through a different set of field tests. The first objective aims
to provide additional data used in the verification of the enforcement algorithm safety and
performance, and needs to be included in evaluating any particular enforcement algorithm. The
second two objectives are aimed at providing the necessary justification for the simulation
testing results. Since they are not tied to a specific version of a specific enforcement algorithm,
these tests need only be performed a single time.

A4.1 Enforcement Algorithm Field Testing

The purpose of enforcement algorithm field testing is to supplement the simulation testing results
with enforcement data using actual PTC hardware in a field implementation on actual railroad
equipment. This will occur in two stages, as necessary. In the first stage, the enforcement
algorithm, implemented as a black-box software application is integrated with field test hardware
in a highly controlled test environment where specific conditions can be tested and tests can be
repeated to show consistency. In the second stage, the enforcement algorithm, implemented in a
complete PTC system is tested on revenue track where conditions not found in the controlled test
environment can be tested.

A4.1.1 Stage 1 – Testing in a Controlled Environment

The purpose of the first stage of enforcement algorithm field testing is to evaluate the
enforcement algorithm, under a practical range of conditions, using real-world inputs on actual
railroad equipment in a controlled environment, where repeatability tests can be performed at
relatively low cost with no impact to railroad operations. The intent is not to perform the
quantity of enforcements necessary to statistically evaluate the safety and performance of the
enforcement algorithm, as this is only practical to demonstrate through the results of the
simulation testing. The intent is also not to verify the accuracy of the model used or the
parameters varied in simulation testing, as these are achieved through other field tests (although
these tests may be used to provide additional confidence in the simulation testing results).
For the first stage of enforcement algorithm field testing, the enforcement algorithm is
implemented as a black-box software application, just as for the simulation testing. The
enforcement algorithm is initialized for each test by manually providing train and target stop
location data to the software. The test hardware is set up to provide those inputs required by the
enforcement algorithm (e.g. location, speed, brake pipe pressures, etc.) at regular time intervals
over the identical interface used in simulation testing. The test train is operated towards the
147
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

given target stopping location at the given test speed and the enforcement algorithm commands a
penalty air brake application to prevent a violation of the given stopping target location. The
enforcement algorithm may also command an emergency brake enforcement, as necessary,
following the initial penalty brake enforcement. The test hardware is set up to initiate both the
penalty and emergency application on the test locomotive. Enforcement of the air brakes brings
the train to a stop, which completes the test.
Due to the practical availability of equipment, the specific test scenarios cannot be precisely
defined for the first stage of enforcement algorithm field testing. However, it is expected that a
range of operating conditions will be covered, as follows:
• Train make-up. If practical, multiple train types and loading conditions will be used,
however, it may only be practical to test with loaded unit train equipment. It may be
practical to test with some amount of manifest freight equipment.
• Train length. If practical, various train lengths will be tested, up to 100 cars. In some
cases, shorter trains may be tested, in order to allow for more test cases to be practically
evaluated.
• Train speed. A range of test speeds will be tested, up to 70 mph, if practical.
• Track grade. A range of track grades will be tested, up to -1.47%.
Additionally, a variety of the test cases will be repeated up to three times to demonstrate the
consistency of the safety and performance of the enforcement algorithm in a field environment.
It is expected that approximately 30-40 enforcement tests will be performed.

A4.1.2 Stage 2 – Testing in Revenue Service

The purpose of the second stage of enforcement algorithm field testing is to provide additional
confidence, as necessary, in the safety and performance of the enforcement algorithm under
specific conditions, as in the implemented PTC system. The second stage of enforcement
algorithm field testing will occur on revenue track, using PTC-equipped, test trains.
For the second stage of enforcement algorithm field testing, the enforcement algorithm is
implemented in the onboard component of the PTC system. For each test, initialization is
performed to include train, track, and authority information. The train is then operated towards
the boundary of an artificial work zone, with the onboard system providing the required data to
the enforcement algorithm. The enforcement algorithm commands a penalty air brake
application to prevent a violation of the given stopping target location. The enforcement
algorithm may also command an emergency brake enforcement, as necessary, following the
initial penalty brake enforcement. The onboard system initiates the penalty and, if necessary,
emergency applications and the train is brought to a stop.
The specific test scenarios will be generally defined, as necessary, following the first stage of
enforcement algorithm field testing, to provide any additional field test data required. The
precise test consists, speeds and grades will depend on the practically available locations and test
trains at those locations, based on the generally defined test scenarios. It is expected that a total
of approximately 20 enforcement tests will be performed that will cover the range of boundary
conditions found on all freight railroads that cannot be performed in the controlled test
environment.

148
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

A4.2 Repeatability Field Testing

The purpose of repeatability testing in the field is to demonstrate consistency in freight train
stopping distance, given that the key varied parameters from simulation testing are held constant.
This will verify that the variation in freight train stopping distance is due primarily to the
parameters varied in the simulation testing, and the effects of the parameters not varied is
minimal and, therefore, do not need to be considered. Because this testing is not associated with
a specific enforcement algorithm, it only needs to be performed one time.
The repeatability field testing provides data on the variation in freight train stopping distance by
repeating each test case multiple times with identical conditions, as practical. A minimum of six
test runs for each test case provides statistical significance. Consistent location of the penalty
brake application is ensured through the use of an automatic location detector (ALD) system. An
ALD tag is placed on the track at the desired location of the penalty brake application and the
ALD tag reader, installed on the locomotive, is wired to trigger a penalty brake application when
it senses the ALD tag on the track.
For each test run, the train crew operates the train, with a fully charged air brake system, to
achieve the given test speed at the location of the ALD tag. The system triggers the penalty
brake application, the train is brought to a stop, and stopping distance data is recorded. The test
cases for repeatability field testing represent a mix of train length, train speed, and track grade.

A4.3 Field Testing for Comparison against Simulation Results

The purpose of performing stopping distance field tests and comparing against simulation results
is to demonstrate the accuracy of the model used for simulation testing and to quantify any
systematic error in the model. Because this testing is not associated with a specific enforcement
algorithm, it only needs to be performed one time.
Stopping distance field tests are performed to determine the actual stopping performance of the
given test train. For each test case, the train is operated to the test speed and a penalty brake
application is initiated at a pre-defined point. The train is brought to a stop and the dynamic
speed and location data are recorded. Prior to testing, measurements of all of the key parameters
that affect stopping distance are performed on the train to be used as inputs to the model. For
parameters where measurement of every car in the train is impractical, measurements are
performed on a sample of cars in the train, to provide statistical data to be used in the model.
Each stopping distance field test is replicated in the TOESTM model to determine the simulated
stopping performance for the given test train. The exact measurements for each parameter from
the field test are input and the exact operating control settings are replicated in the simulation.
The results from the field tests and the simulation tests are then compared to demonstrate the
accuracy of the model, given the accuracy of the inputs. The test cases for stopping distance
field and simulation testing comparisons represent a mix of train length, train speed, and track
grade.

149
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

A5. Analysis and Reporting

The data produced from the testing methodology described in the previous sections is analyzed
to demonstrate the safety and performance of the enforcement algorithm under evaluation. The
primary output of this analysis is the probability that a given train will stop short of a given target
stopping location. This output, along with a number of other performance characteristics, is
quantified through a statistical analysis of the results of the simulation testing. Analysis of the
field testing results is used to support the conclusions drawn from the analysis of the simulation
testing.
There are four components to the test data analysis:
• Statistical evaluation of the simulation data to quantify the safety and performance
characteristics of the enforcement algorithm
• Comparison of field enforcement tests to simulated enforcement tests to demonstrate
correlation
• Analysis of field stopping distance repeatability tests to evaluate consistency in freight
train stopping distance
• Comparison of field stopping distance tests to simulated stopping distance tests to verify
accuracy of model used for simulation testing
These components are described in further detail in the following sub-sections.

A5.1 Simulation Testing Analysis

The analysis of the results from the simulation testing is intended to statistically quantify the
safety and performance characteristics of the enforcement algorithm for each scenario tested,
based on the simulation results. There are a number of key safety and performance
characteristics that are evaluated:
• Probability of target overshoot. The maximum statistical probability that the given train,
under the given operating conditions, will stop beyond the given stopping target,
following an air brake enforcement by the enforcement algorithm under evaluation.
• Average target overshoot. The expected average distance, in feet, beyond the given
stopping target that the given train, under the given operating conditions, will stop, for
those situations where the train stops beyond the stopping target
• Standard deviation of target overshoot. The expected standard deviation, in feet, of the
stopping location for the given train, under the given operating conditions, for those
situations where the train stops beyond the stopping target, following an air brake
enforcement by the enforcement algorithm under evaluation.
• Probability of excessive target undershoot. The statistical probability range that the given
train, under the given operating conditions, will stop short of the target, following an air
brake enforcement by the enforcement algorithm under evaluation, by greater than:
o 500 feet, if the initial speed at enforcement is < 30mph, or
o 1200 feet, if the initial speed at enforcement is ≥ 30mph

150
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

• Probability of emergency brake application. The expected statistical probability that the
enforcement algorithm under evaluation will apply an emergency air brake application,
following the initial penalty air brake application for the given train, under the given
operating conditions.
• Average enforcement location. The average location, in feet, relative to the given target
stopping location, that the enforcement algorithm under evaluation will initiate a penalty
air brake application for the given train, under the given operating conditions.
• Standard deviation of enforcement location. The standard deviation, in feet, of the
location the enforcement algorithm under evaluation will initiate a penalty air brake
application for the given train, under the given operating conditions.
The above characteristics are estimated, using a variety of statistical evaluation methods. The
statistical evaluation process can be described generally as a two part analysis method. These
parts are differentiated as being an objective analysis phase, followed by a subjective analysis
phase.

A5.1.1 Exploratory Data Analysis (objective analysis phase)

Exploratory Data Analysis (EDA) is termed “an approach/philosophy for data analysis that
employs a variety of techniques (mostly graphical) to:
1. maximize insight into a data set;
2. uncover underlying structure;
3. extract important variables;
4. detect outliers and anomalies;
5. test underlying assumptions.” (NIST, 2010)

Often, 80% of the desired results are determined during EDA. The data are characterized by
generating common descriptive statistics plus a variety of graphical analysis outputs. Graphical
outputs include box plots, scatter (runs) plots, histograms and quantile-quantile (Q-Q) plots. The
primary software tool used to perform all analyses is Statistica, Version 10 (Statsoft, 2011).

One of the tasks of EDA is data augmentation and validation. This portion of EDA assures
completeness of the expected datasets and that no extraneous data were unintentionally extracted
from the simulation result database. Certain required data for subsequent analysis steps must be
generated (computed or derived) from the simulation results. These data field additions are
completed and verified as part of the validation process. Simulated as well as generated numeric
variables are evaluated to assure that the analyses are not done while data are missing or
extraneous. Frequency tables, cross-tabulations and dot plots reveal all expected combinations
and/or unexpected data presence.

Data consistency is confirmed using a combination of breakdown tables and various plots.
Statistica breakdown tables can isolate unique combinations of factors that match each batch or
operating scenario (i.e., each set of 100 simulated enforcements). The statistical parameters
generated for these tables can include all standard parameters (mean, standard deviation, min,
max, median, quartiles) plus variation evaluation parameters (skewness, kurtosis, standard errors,

151
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

normality test statistics, variance, mean confidence interval, standard deviation confidence
interval, trimmed mean, etc.).

Should any data cleanup be required, such actions are completed and the data validation outputs
are rerun. Should the data prove to be reliable with review but certain characteristics remain that
stand out, these are noted. Such characteristics include: outliers that are deemed reliable data;
bimodal distribution patterns; and large numbers of repeated values (typical of very low speed,
short trains).

A5.1.2 Specific Statistical Analysis (subjective analysis phase)

Analytical methods applied during this phase produce any statistical characteristics, parameters
or outcomes not available from the EDA. Typical outputs may include results such as difference
tests, regressions, correlations or specialized statistical parameters. For evaluation of the
enforcement algorithm, several probabilities are generated. These are considered specialized
statistical parameters given the uncertainty in their determination. The problem of uncertainty in
extreme quantile estimation exists where the estimated quantile (i.e. 0.995) is beyond the
observed sample data range (Mhamed-Ali El-Arouia, 2002). In this case, parts-per-thousand
precision is required from parts-per-hundred-sized data samples.
Probabilities are estimated both empirically and via extreme quantile estimation methods (Igor
Rychlik and Rydén, 2006). The empirical probability is directly calculated from the sample. A
long term probability is estimated based on observations of the distribution tail characteristics
using the Peaks-over-Threshold (POT) method as defined by Rychlik and Rydén to be a
Generalized Pareto Distribution (GPD). If the right distribution tail is upward-turning as
observed in a Q-Q plot then the empirical probability will be an underestimate of the true
probability (Ravi Annapurva and Butar, 2010), (CONORT, 2010). For these cases, the extreme
quantile estimate is made using a modified POT method. A more specific and reliable
distribution function is substituted following a direct data fitting evaluation. EasyFit
Professional, Version 5.5 is used for data fit evaluation and distribution function and parameter
generation (MathWave, 2010).

A5.2 Comparison of Field and Simulated Enforcements

Enforcement tests evaluate the performance of the enforcement algorithm in stopping the train
short of the target stopping location. The specific purpose of this analysis is to assess a sample
of stopping locations achieved by the algorithm, relative to a given target location across the
varied set of operating scenarios (combinations of train, speed, and track profile).
Difficulties with this analysis are in comparing the sample size of one stopping distance data
point produced from a field test, to a simulated stopping distance sample set of 100 data points.
The uncertainty in this comparison is that, with a sample size of one, no variation exists for
comparison to the simulated sample. The number of difference tests available for making this
one-sample type of comparison is limited. However, using a properly defined hypothesis
statement, the method used is well established. The approach is to support a null hypothesis of
No Difference where the field test sample stopping distance cannot be proven to be from a
different distribution than that of the simulated sample.

152
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

A5.3 Analysis of Stopping Distance Repeatability

Stopping distance repeatability tests evaluate field test data gathered while actually stopping
trains representing a cross-section of potential operating scenarios. This analysis determines the
consistency and variation in stopping distance, given identical conditions. This verifies that
these field test stopping distance data are suitable for comparing with simulated stopping
distance data. The possibility of any causes of variation that are not considered in the
simulations would be revealed and assessed.
In addition to the descriptive statistics provided by the EDA, tests for homogeneity of variance
are made to assess the suitability of the data for establishing a conclusion of being repeatable.
The simple definition of this result is that the data come from the same distribution (are
repeatable), given a high level of confidence (Montgomery, 2003). If it is true that all causes of
variation are controlled or accounted for (typically, velocity, load, track grade, etc.) then the data
will pass this test. If some cause of variation exists that is not considered or accounted for, the
test will fail; ergo, the stopping distance data are not repeatable.

A5.4 Comparison of Identical Field and Simulated Stopping Distance Tests

Stopping distance comparisons between field tests and simulations show how closely the overall
simulated results represent reality. The comparisons (statistical difference tests applied) are not
between individual simulated stopping distance outcomes vs. the relative field test result. The
evaluation is of the aggregate performance of the field tested enforcement algorithm vs. the
aggregate performance of the simulations for the scenarios tested.
The comparison’s null hypothesis is that there is no difference when comparing the differences
between the pairs of the respective data sets. The relatively small sample sizes acquired from
field testing add some analysis limitations in that the difference tests to be applied must be
tolerant of small sample sizes. The EDA establishes the likely distribution identification for
differences which, in turn, establishes the acceptable assumptions for choosing which statistical
tests to use (Montgomery, 2003 and Statsoft, Inc., 2011). The primary consideration is whether
the difference data are normally distributed or not. To allow additional tests to be applied, the
data can be transformed to a normal distribution (NIST, 2010). A useful practice is to perform
multiple, suitable tests to build a case toward supporting or rejecting the null hypothesis.

A5.5 Reporting
The final component of the test methodology is the reporting of the conclusions drawn from the
analysis of the test data. The statistical measures of performance, described in section 5.1 are
reported for each of the simulated test scenarios. Overall measures of performance are also
reported, by combining the results of the individual test scenarios. This combination can be
weighted by the likelihood of encountering each test scenario, although the weighting process
can be subjective. Finally, the supporting conclusions from the analysis of the field test data are
reported to demonstrate the validity of the conclusions drawn from the analysis of the simulation
test data.

153
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

A6. References
1. Conort, X. (2010). “Quantile Estimation Of Heavy Tail Distributions And Model Risks Of
Evt Techniques.” Bulletin Français D’Actuariat, Vol. 10, n°19 , 63-109.
2. Rychlik, I. and Rydén, J. (2006). Probability and Risk Analysis: An Introduction for
Engineers. Heidelburg: Springer.
3. MathWave. (2010, Dec 3). EasyFit Professional, Version 5.5 (Released 2010-12-03) .
4. Mhamed-Ali El-Arouia, J. D. (2002). “On the use of the peaks overthresholds method
forestimating out-of-sample quantiles.” Computational Statistics & Data Analysis, 453-475.
5. NIST, D. o. (2010, 03 23). NIST/SEMATECH e-Handbook of Statistical Methods. Retrieved
01 17, 2009, from Engineering Statistics Handbook:
http://www.itl.nist.gov/div898/handbook/
6. Annapurva, R. and Butar, F. B. (2010). An Insight into Heavy-Tailed Distrution. Journal of
Mathematical Sciences and Mathematical Education, Vol. 5 .
7. StatSoft, Inc. (2011). STATISTICA, version 10 . Tulsa, OK.

154
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

Appendix B.
Enforcement Algorithm Evaluation Process Overview and
Communications Interface Specification

Enforcement Algorithm
Evaluation Process Overview
and
Communications Interface Specification

Revision 6
January 25, 2011

Transportation Technology Center, Inc.

A subsidiary of the Association of American Railroads

155
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

Modification Log

Description Date
Revision 2 - First Draft June 2010
Revision 3 – Changes to termination logic August 24, 2010
Revision 4 – Formatting and restructuring; added data message September 13,
specification and field testing overview 2010
Revision 5 – Added target speed to init message September 15,
2010
Revision 6 – added description of installation test procedures in January 25, 2011
Appendix B.

156
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

Document Description
This document describes the concept of operations for the evaluation of PTC braking
enforcement algorithm (EA) software in both a simulation and field test environment. The
document also includes interface protocol specifications for the integration of supplier provided
EA software into the TTCI testing environment.

157
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

Definitions and Acronyms

Definitions:
• Enforcement Algorithm (EA) - software designed to predict train stopping distance to
enforce externally defined limits on train movement.
• Test Controller and Logger (TCL) –software used to evaluate PTC enforcement
algorithm performance in a simulation test environment by running batches of simulation
tests using the Train Operations and Energy Simulator (TOESTM) software. The TCL
software manages execution of the EA and TOESTM components and acts as a gateway
between the two applications during each simulation. TCL determines consist, track, and
target stopping location inputs for each test. Simulated train inputs are passed from
TOESTM to EA via TCL at regular time intervals throughout the simulation and TCL
initiates a penalty brake application in TOESTM upon receiving the command from EA.
• EA Initialization Module (EA-Init) – A software application used to initialization the test
process with EA software. This module is started by TCL at the beginning of each
simulation, or manually at the beginning of each field test. The purpose of this module is
to transmit consist, track, and target stopping location data to the EA software using a
TCP/IP connection.
• Virtual Machine (VM) – virtual machine software containing the supplier’s EA software.
Acronyms:
• BPP – Brake Pipe Pressure
• EA – Enforcement Algorithm
• IP – Internet Protocol
• OBC – Onboard Computer
• RAM – Random Access Memory
• TCL – Test Controller/Logger
• TCP – Transmission Control Protocol
• TOESTM – Train Operations and Energy Simulator
• TTCI – Transportation Technology Center, Inc.
• VM – Virtual Machine

158
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

B1. Concept of Operations

This section describes the concept of operations for enforcement algorithm evaluation in both a
simulation and field test environment.

B1.1 Simulation Testing

This section describes the simulation test process and required interfaces. The simulation testing
process flow is illustrated in Figure B1. To start the process, TCL is configured to execute a
batch of simulations and the EA application is started and configured to communicate with TCL
and EA-Init using a specified IP address and two distinct ports. The simulation testing then
proceeds as follows:
1. TCL starts EA-Init and TOESTM at the beginning of each simulation.
2. EA-Init sends an initialization message to EA over TCP/IP using the admin port.
3. EA sends a status message to TCL over TCP/IP using the data port.
4. TCL propagates the TOESTM simulation by one second, receives train status data and
sends this data to EA over TCP/IP using the data port.
5. Steps 3 and 4 are repeated until EA determines a penalty brake application is necessary.
At this time EA updates the status code in the status message sent in Step 3 to instruct
TCL to apply the penalty brake. TCL then initiates the penalty application in TOESTM
and steps 3 and 4 continue until the train speed is less than 0.5 mph.
6. EA sends a terminate message to both TCL (using the data port) and EA-Init (using the
admin port).
7. EA-Init shuts down and TCL proceeds with the next test until the end of the test batch.

159
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

The TCL software has the ability to run multiple simulations on a single test machine. For this
reason, the supplier EA software should have the ability to set both the admin port and data port
using configuration files.

B1.2 Field Testing

This section describes the field test process and required interfaces. The general process flow for
field testing is designed to be very similar to simulation testing and the interfaces are identical.
The process flow for field testing is illustrated in Figure B2. The primary difference is that,
during field testing, the EA software and the EA-Init application reside on a test computer that is
connected through an Ethernet cable to the locomotive onboard computer (OBC). As in
simulation testing, the EA is started and configured to interface the EA-Init application and the
locomotive OBC through a specified IP address and two distinct ports.
The EA-Init application is then started and used to send an initialization message to the EA
software over TCP/IP using the admin port. Once initialized, EA sends a status message to the
locomotive OBC application over TCP/IP using the data port. The test is then run, with the
160
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

locomotive OBC application sending data to the EA software at 1 Hz frequency and the EA
software responding with a status message using the data port. When the EA software
determines a penalty application is necessary, it sends the appropriate status message to the
locomotive OBC, which then initiates the penalty application on the train. When the train comes
to a stop, the EA software sends a terminate message to the locomotive OBC (using the data
port) and to the EA-Init application (using the admin port).

B1.3 Track Data

TTCI and the EA supplier will coordinate the development of track data that will be used by the
supplier provided EA software. TTCI will provide track profile data for each track section that
will be utilized in testing. The supplier will use this track profile data to generate the track data

161
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

store to be used by their EA software. Specific track sections for each individual test will be
identified in the initialization message using an agreed upon identifier.

B1.4 Machine Configuration

Supplier provided EA software shall be delivered in one of three forms:
• as a virtual machine image that can be run on the test machines, or
• as a software executable that can run on the test machines, or
• as hardware that can be installed in the TTCI test environment (note that for simulation
testing, multiple simulations are planned to be run concurrently)
The current test machines run Windows XP operating system with 4GB of RAM. TTCI and the
EA supplier shall create a mutually agreeable machine configuration for running the provided
EA software.

B1.4.1 Protocol Test Application

TTCI will provide a protocol test application for the EA supplier to use in development of
software that can communicate using protocols developed by TTCI (See Appendix BA).

162
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

B2. Interface Specifications

This section specifies the format for the various messages used in the enforcement algorithm
evaluation processes described in the previous section.

B2.1 Initialization Message Specification

Table B1 specifies the format for the initialization message to be sent from the EA-Init
application to the supplier’s EA application at the beginning of each simulation and field test.
Table B34 - Initialization Message
Data
Field Name Description Data Type Notes
Length
START_BYTES Bytes for Framing 2 bytes 21930 Static
(0x55aa)
MESSAGE_ID Message Identifier 1 byte 3 (0x03) Static
TRACK_FILE_ID The track file number 2 bytes unsigned None
short
TARGET_LOCATI The Target stopping Location 4 bytes unsigned None
ON (footage) Integer
TARGET_SPEED The target speed (mph) 1 byte Unsigned None
integer
START_LOCATION The initial starting track 4 bytes Unsigned None
location (in feet) Integer
TRAIN_TYPE Train Type 1 byte UINT 0-6
0 – Unknown
1 – General Freight
2 – Unit Freight
3 – Intermodal
4 – Passenger
5 – High speed Passenger
6 – Tilt train
ORIENTATION Lead Loco Orientation 1 byte UINT 0-2
0 – Unknown
1 – Front
2 – Back
TRAILING_TONS Trailing Tonnage 2 bytes unsigned 0-30000
(cars only) short
CARS_NO_BRAKE Number of cars with 2 bytes unsigned 0-999
S inoperative brakes short
AXLES Number of axles 2 bytes unsigned 0-3996
(cars and locomotives) short
TOTAL_LENGTH Train length (feet) – including 2 bytes unsigned 60-15000
locomotives short
LOADS Loaded car count 2 bytes unsigned 0-999
short
EMPTIES Empty car count 2 bytes unsigned 0-999
short
CAR_BRAKE_FOR Car Braking Force (lb) 4 bytes unsigned 0-2000000
CE (optional) – not including integer
locomotives
LOCOMOTIVES The number of locomotives 1 byte UINT 0-24

163
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

Data
Field Name Description Data Type Notes
Length
For each Loco
POSITION The locomotive position in the 2 bytes unsigned 0-999
train short
TONNAGE The tonnage of the locomotive 2 bytes unsigned 20-300
short
STATUS Locomotive Status 1 byte UINT 0-2
0 – Unknown
1 – Run
2 – Isolated
LENGTH The length of the locomotive 1 byte UINT 60-90
(feet)
HORSEPOWER Locomotive Horsepower 2 bytes unsigned 0-10000
short
End For
CRC 32 CRC32 over data 4 bytes UINT Not used
(not implemented)
END_BYTES Bytes for Framing 2 bytes 30875 Static
(0x789b)

The TRACK_FILE_ID field identifies the section of track according to an agreed upon
identifier.
The TARGET_LOCATION field specifies the target stop position in feet from the beginning of
the track section for the simulation. The track section for the simulation is defined in the track
file indicated by the TRACK_FILE_ID field, as discussed above.
The CAR_BRAKE_FORCE field is an optional input designed for cases when the RR customer
plans to supply the enforcement algorithm with a total train braking force that is calculated
offline by a preprocessor. In these cases, the RR or EA supplier can provide the algorithm for
calculating the total train braking force and this field can be populated. Otherwise, this field can
be ignored.

B2.2 Train Data Message Specification

Table B2 specifies the format for the train data message that is sent to the EA software. This
message is sent from the TCL application during simulation testing and from the locomotive
OBC application during field testing. In simulation testing, this will occur at 1 Hz frequency
simulation time (i.e. faster than real time) and in field testing, this will occur at 1 Hz frequency
real time.
Table B35 – Train Data Message
Data
Field Name Description Data Type Notes
Length
START_BYTES Bytes for Framing 2 bytes 21930 Static
(0x55aa)
TRN_LOC Current Train Location 8 bytes Double Sent as feet,
(footage) must be within
limits defined in
track data file
TRN_SPD Current Train Speed (mph) 8 bytes Double MPH
164
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

Data
Field Name Description Data Type Notes
Length
0 to 999.99
BPP_HEAD Current Brake Pipe Pressure at 8 bytes Double Range from 0 to
Head of train (psi) 999.99
BPP_END Current Brake Pipe Pressure at 8 bytes Double Range from
End of Train (psi) 0 to 999.99
NOTCH Current locomotive throttle 8 bytes Double 0-8
position
DYN_BRAKE_V Dynamic Braking Voltage 8 bytes Double 0 to 80V
HW_DISC1 Hardware Discrete Byte 1 1 byte Byte HGFEDCBA
• Bit A: TL01 - Slow Speed (LSB)
• Bit B: TL03 - Throttle D 1 = High
• Bit C: TL06 - Generator 0 = Low
Field
• Bit D: TL07 - Throttle C
• Bit E: TL08 - Fwd Ctl
• Bit F: TL09 - Rev Ctl
• Bit G: TL10 - Wheel Slip
• Bit H: TL12 - Throttle B
HW_DISC2 Hardware Discrete Byte 2 1 byte Byte HGFEDCBA
• Bit A: TL15 - Throttle A (LSB)
• Bit B: TL16 - Engine Run 1 = High
• Bit C: TL17 - Dyn Brake 0 = Low
Setup
• Bit D: TL21 - Dyn Brake
Circuit Active
• Bit E: TL05 - Emg Sand
• Bit F: Alternator (Engine
Running)
• Bit G: TL23 Sand
• Bit H: ISOLATE
HW_DISC3 Hardware Discrete Byte 3 - 1 byte Byte HGFEDCBA
(spare) (LSB)
• Bit A: (NOT SUPPLIED) 1 = High
• Bit B: (NOT SUPPLIED) 0 = Low
• Bit C: (NOT SUPPLIED)
• Bit D: (NOT SUPPLIED)
• Bit E: (NOT SUPPLIED)
• Bit F: (NOT SUPPLIED)
• Bit G: (NOT SUPPLIED)
• Bit H: Brakes Cut Out
SPARE (not used) 1 byte Byte Not used
CRC 32 CRC32 over data 4 bytes UINT32 Not used
(not required in V3.4)
END_BYTES Bytes for Framing 2 bytes 30875 Static
(0x789b)

B2.3 EA Status Message Specification

Table B3 specifies the format for the EA status message. This message is sent by the EA
software to the TCL application (simulation testing) or the locomotive OBC application (field
165
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

testing) once at the beginning of the test and then again after each time a train data message is
received.
Table B36 – EA Status Message
Data
Field Name Description Data Type Notes
Length
START_BYTES Bytes for Framing 2 bytes Byte Static
(0x55aa)
STATUS Health Status 2 bytes short Values
00 – OK 0 thru 2
01 – Error
02 – Completed
APPLY_BR Apply service brake 1 byte Boolean 0 – false
1 – true
APPLY_EB Apply emergency brake 1 byte Boolean 0 – false
1 – true
CRC 32 CRC32 over data 4 bytes UINT32 Not used
(not required in V3.4)
END_BYTES Bytes for Framing 2 bytes 30875 Static
(0x789b)

166
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

B.3 Protocol Test Application

The protocol test application is provided to EA developers to assist in the development of
interfaces to the TCL and locomotive OBC software. The protocol test application has the
following features:
• Simulates TCL/Locomotive OBC inputs
• Uses current TTCI EA protocol specifications
• Allows the user to test input values
• Sends sample initialization message to EA software
The Microsoft Visual C# 2008 source code for this application will be provided to the EA
supplier to assist in development and testing.
The following two figures illustrate the operation of the test application. The first shows the
train data message screen and the second shows the initialization message screen.

Figure B22 - EA Protocol Test Application – Data Message Tab

167
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

Figure B23 – EA Protocol Test Application – Initialization Message Tab

168
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

B.4 Installation and Setup Testing

This section describes how the protocol test application is used to validate the machine setup and
to ensure that the EA software is installed and configured properly. The process is described as
follows:
1) There are several test scenarios described in this section. These scenarios match test
scenarios in the TTCI simulation environment.
2) Using the protocol test app the input parameters are entered by selecting a setup test
using the EA Comms test application. This causes the loading of parameters to the
screen fields.

3) Then after starting the simulation test, the application sends test date to the EA software,
and the EA software should trigger a brake application this is displayed on the EA Data
message tab.

4) The brake position should be recorded for each of the test scenarios in the test matrix.
5) After installation of the VM image or EA software at the TTCI test lab the test matrix is
executed to validate the installation process.
6) As a final step a TCL test batch matching the test matrix is executed and the results are
compared to those supplied in step 4. The test results should be similar to those in step 4,
but will vary slightly due to TOES variations and TCL’s use of the cruise control feature
to maintain train speed.

169
 Positive Train Control Braking Enforcement Algorithm Evaluation Methodology
Version 1.2

Setup Test Matrix

Test 1 Unit Coal – 100 cars, 2 locomotives, 30 mph, flat
track,
Test 2 Unit coal – 100 cars (empty), 2 locomotives, 50
mph, flat track
Test 3 General freight – 20 loads, 20 empty, 2
locomotives, 40 mph, 1.5 percent decline
(TrackId = 8034)
Test 4 General freight – 20 loads, 2 locomotives, 20
mph, 1.5 percent incline (TrackId= 8036)

This test must match a test batch in the TTCI test environment.

170
Appendix C.
Simulation Test Matrix Details
Table C-1 describes the test consists generated for simulation testing as part of the enforcement
algorithm evaluation methodology. The consist name is a unique identifier for each consist.
Figures C-1, C-2, and C-3 show the naming conventions for unit, manifest freight, and
intermodal trains, respectively.

Consist Naming Convention - Unit Train

Example: U100LCWHE

U Unit Train
110 Number of Cars
L Loaded (E = Empty)

CW Coal [Western] (CE = Coal [Eastern], CH = Covered Hopper, TK = Tank, RB =

Refrigerated Boxcar, ML = Multilevel)

HE Head-end Power (DE = DP with units at end of train, DM = DP with units at

head, mid, and end of train)

Figure C-1. Unit Train Consist Naming Convention

Consist Naming Convention - Manifest Train

Example: M040AHE

M Manifest Train
040 Number of Cars
A Consist identifier
(10 unique consists will be tested for each length of train)

HE Head-end Power (DE = DP with units at end of train, DM = DP with units at

head, mid, and end of train)

Figure C-2. Manifest Freight Train Consist Naming Convention

171
Consist Naming Convention - Intermodal Train

Example: ISLAHE

I Intermodal Train

S Short [5,000 ft] (M = Medium [7,500 ft], L = Long [10,000 ft], V = Very Long
[15,000 ft])
L Loaded (E = Empty)
A Consist identifier

(5 unique consists will be tested for each length/load combination)

HE Head-end Power (DE = DP with units at end of train, DM = DP with units at head,
mid, and end of train)

Figure C-3. Intermodal Freight Train Consist Naming Convention

Table C-1. Simulation Test Consist Descriptions

Trailing Number of
Consist Name Type Length Makeup Loading Power Tonnage Locomotives
DP -
IVEADM Intermodal Very Long A Empty H/M/E 5169 10
DP -
IVEBDM Intermodal Very Long B Empty H/M/E 5398 10
DP -
IVECDM Intermodal Very Long C Empty H/M/E 5536 10
DP -
IVEDDM Intermodal Very Long D Empty H/M/E 5512 10
DP -
IVEEDM Intermodal Very Long E Empty H/M/E 5361 10
DP -
IVLADM Intermodal Very Long A Loaded H/M/E 20743 15
DP -
IVLBDM Intermodal Very Long B Loaded H/M/E 12105 10
DP -
IVLCDM Intermodal Very Long C Loaded H/M/E 13336 10
DP -
IVLDDM Intermodal Very Long D Loaded H/M/E 13517 10
DP -
IVLEDM Intermodal Very Long E Loaded H/M/E 11947 10
DP -
ILEADE Intermodal Long A Empty H/E 3437 7
DP -
ILEADM Intermodal Long A Empty H/M/E 3437 7
DP -
ILEBDE Intermodal Long B Empty H/E 3614 7
DP -
ILEBDM Intermodal Long B Empty H/M/E 3614 7

172
 Trailing Number of
Consist Name Type Length Makeup Loading Power Tonnage Locomotives
DP -
ILECDE Intermodal Long C Empty H/E 3687 7
DP -
ILECDM Intermodal Long C Empty H/M/E 3687 7
DP -
ILEDDE Intermodal Long D Empty H/E 3613 7
DP -
ILEDDM Intermodal Long D Empty H/M/E 3613 7
DP -
ILEEDE Intermodal Long E Empty H/E 3630 7
DP -
ILEEDM Intermodal Long E Empty H/M/E 3630 7
DP -
ILLADE Intermodal Long A Loaded H/E 14858 11
DP -
ILLADM Intermodal Long A Loaded H/M/E 14858 11
DP -
ILLBDE Intermodal Long B Loaded H/E 9160 7
DP -
ILLBDM Intermodal Long B Loaded H/M/E 9160 7
DP -
ILLCDE Intermodal Long C Loaded H/E 9987 7
DP -
ILLCDM Intermodal Long C Loaded H/M/E 9987 7
DP -
ILLDDE Intermodal Long D Loaded H/E 9077 7
DP -
ILLDDM Intermodal Long D Loaded H/M/E 9077 7
DP -
ILLEDE Intermodal Long E Loaded H/E 9592 7
DP -
ILLEDM Intermodal Long E Loaded H/M/E 9592 7
DP -
IMEADE Intermodal Medium A Empty H/E 2658 5
Head
IMEAHE Intermodal Medium A Empty End 2658 5
DP -
IMEBDE Intermodal Medium B Empty H/E 2781 5
Head
IMEBHE Intermodal Medium B Empty End 2781 5
DP -
IMECDE Intermodal Medium C Empty H/E 2648 5
Head
IMECHE Intermodal Medium C Empty End 2648 5
DP -
IMEDDE Intermodal Medium D Empty H/E 2738 5
Head
IMEDHE Intermodal Medium D Empty End 2738 5
DP -
IMEEDE Intermodal Medium E Empty H/E 2681 5
Head
IMEEHE Intermodal Medium E Empty End 2681 5
173
 Trailing Number of
Consist Name Type Length Makeup Loading Power Tonnage Locomotives
DP -
IMLADE Intermodal Medium A Loaded H/E 10447 9
Head
IMLAHE Intermodal Medium A Loaded End 10447 9
DP -
IMLBDE Intermodal Medium B Loaded H/E 6846 5
Head
IMLBHE Intermodal Medium B Loaded End 6846 5
DP -
IMLCDE Intermodal Medium C Loaded H/E 6397 5
Head
IMLCHE Intermodal Medium C Loaded End 6397 5
DP -
IMLDDE Intermodal Medium D Loaded H/E 5891 5
Head
IMLDHE Intermodal Medium D Loaded End 5891 5
DP -
IMLEDE Intermodal Medium E Loaded H/E 6414 5
Head
IMLEHE Intermodal Medium E Loaded End 6414 5
DP -
ISEADE Intermodal Short A Empty H/E 1770 4
Head
ISEAHE Intermodal Short A Empty End 1770 4
DP -
ISEBDE Intermodal Short B Empty H/E 1793 4
Head
ISEBHE Intermodal Short B Empty End 1793 4
DP -
ISECDE Intermodal Short C Empty H/E 1793 4
Head
ISECHE Intermodal Short C Empty End 1793 4
DP -
ISEDDE Intermodal Short D Empty H/E 1822 4
Head
ISEDHE Intermodal Short D Empty End 1822 4
DP -
ISEEDE Intermodal Short E Empty H/E 1842 4
Head
ISEEHE Intermodal Short E Empty End 1842 4
DP -
ISLADE Intermodal Short A Loaded H/E 7002 6
Head
ISLAHE Intermodal Short A Loaded End 7002 6
DP -
ISLBDE Intermodal Short B Loaded H/E 5129 4
Head
ISLBHE Intermodal Short B Loaded End 5129 4
DP -
ISLCDE Intermodal Short C Loaded H/E 3937 4
Head
ISLCHE Intermodal Short C Loaded End 3937 4
174
 Trailing Number of
Consist Name Type Length Makeup Loading Power Tonnage Locomotives
DP -
ISLDDE Intermodal Short D Loaded H/E 4736 4
Head
ISLDHE Intermodal Short D Loaded End 4736 4
DP -
ISLEDE Intermodal Short E Loaded H/E 4328 4
Head
ISLEHE Intermodal Short E Loaded End 4328 4
Manifest Light
M0AHE Freight Locomotive A N/A N/A 0 1
Manifest 3 Light
M0BHE Freight Locomotives B N/A N/A 0 3
Manifest Light
M0AHEG Freight Locomotive A N/A N/A 0 1
Manifest 3 Light
M0BHEG Freight Locomotives B N/A N/A 0 3
Manifest Head
M3AHE Freight 003 A N/A End 398 1
Manifest Head
M3BHE Freight 003 B N/A End 99 1
Manifest Head
M3CHE Freight 003 C N/A End 384 1
Manifest Head
M3DHE Freight 003 D N/A End 107 1
Manifest Head
M3EHE Freight 003 E N/A End 381 1
Manifest Head
M3FHE Freight 003 F N/A End 380 1
Manifest Head
M3GHE Freight 003 G N/A End 360 1
Manifest Head
M3HHE Freight 003 H N/A End 222 1
Manifest Head
M3IHE Freight 003 I N/A End 136 1
Manifest Head
M3JHE Freight 003 J N/A End 117 1
Manifest Head
M3AHEG Freight 003 A N/A End 398 1
Manifest Head
M3BHEG Freight 003 B N/A End 99 1
Manifest Head
M3CHEG Freight 003 C N/A End 384 1
Manifest Head
M3DHEG Freight 003 D N/A End 107 1
Manifest Head
M3EHEG Freight 003 E N/A End 381 1
Manifest Head
M3FHEG Freight 003 F N/A End 380 1
Manifest Head
M3GHEG Freight 003 G N/A End 360 1
Manifest Head
M3HHEG Freight 003 H N/A End 222 1
175
 Trailing Number of
Consist Name Type Length Makeup Loading Power Tonnage Locomotives
Manifest Head
M3IHEG Freight 003 I N/A End 136 1
Manifest Head
M3JHEG Freight 003 J N/A End 117 1
Manifest Head
M10AHE Freight 010 A N/A End 1315 2
Manifest Head
M10BHE Freight 010 B N/A End 344 2
Manifest Head
M10CHE Freight 010 C N/A End 560 2
Manifest Head
M10DHE Freight 010 D N/A End 921 2
Manifest Head
M10EHE Freight 010 E N/A End 1072 2
Manifest Head
M10FHE Freight 010 F N/A End 800 2
Manifest Head
M10GHE Freight 010 G N/A End 686 2
Manifest Head
M10HHE Freight 010 H N/A End 389 2
Manifest Head
M10IHE Freight 010 I N/A End 1379 2
Manifest Head
M10JHE Freight 010 J N/A End 1005 2
Manifest Head
M10AHEG Freight 010 A N/A End 1315 2
Manifest Head
M10BHEG Freight 010 B N/A End 344 2
Manifest Head
M10CHEG Freight 010 C N/A End 560 2
Manifest Head
M10DHEG Freight 010 D N/A End 921 2
Manifest Head
M10EHEG Freight 010 E N/A End 1072 2
Manifest Head
M10FHEG Freight 010 F N/A End 800 2
Manifest Head
M10GHEG Freight 010 G N/A End 686 2
Manifest Head
M10HHEG Freight 010 H N/A End 389 2
Manifest Head
M10IHEG Freight 010 I N/A End 1379 2
Manifest Head
M10JHEG Freight 010 J N/A End 1005 2
Manifest Head
M40AHE Freight 040 A N/A End 5131 4
Manifest Head
M40BHE Freight 040 B N/A End 1318 2
Manifest Head
M40CHE Freight 040 C N/A End 3741 3
Manifest Head
M40DHE Freight 040 D N/A End 5026 4
176
 Trailing Number of
Consist Name Type Length Makeup Loading Power Tonnage Locomotives
Manifest Head
M40EHE Freight 040 E N/A End 4090 3
Manifest Head
M40FHE Freight 040 F N/A End 2909 2
Manifest Head
M40GHE Freight 040 G N/A End 2505 2
Manifest Head
M40HHE Freight 040 H N/A End 4183 3
Manifest Head
M40IHE Freight 040 I N/A End 2174 2
Manifest Head
M40JHE Freight 040 J N/A End 2958 2
Manifest DP -
M100ADE Freight 100 A N/A H/E 13290 9
Manifest Head
M100AHE Freight 100 A N/A End 13290 9
Manifest DP -
M100BDE Freight 100 B N/A H/E 3338 4
Manifest Head
M100BHE Freight 100 B N/A End 3338 4
Manifest DP -
M100CDE Freight 100 C N/A H/E 6810 5
Manifest Head
M100CHE Freight 100 C N/A End 6810 5
Manifest DP -
M100DDE Freight 100 D N/A H/E 11500 7
Manifest Head
M100DHE Freight 100 D N/A End 11500 7
Manifest DP -
M100EDE Freight 100 E N/A H/E 8382 5
Manifest Head
M100EHE Freight 100 E N/A End 8382 5
Manifest DP -
M100FDE Freight 100 F N/A H/E 8709 5
Manifest Head
M100FHE Freight 100 F N/A End 8709 5
Manifest DP -
M100GDE Freight 100 G N/A H/E 8918 5
Manifest Head
M100GHE Freight 100 G N/A End 8918 5
Manifest DP -
M100HDE Freight 100 H N/A H/E 9069 5
Manifest Head
M100HHE Freight 100 H N/A End 9069 5
Manifest DP -
M100IDE Freight 100 I N/A H/E 10007 6
Manifest Head
M100IHE Freight 100 I N/A End 10007 6
Manifest DP -
M100JDE Freight 100 J N/A H/E 10462 6
Manifest Head
M100JHE Freight 100 J N/A End 10462 6
177
 Trailing Number of
Consist Name Type Length Makeup Loading Power Tonnage Locomotives
Manifest DP -
M150ADE Freight 150 A N/A H/E 19748 9
Manifest DP -
M150ADM Freight 150 A N/A H/M/E 19748 9
Manifest DP -
M150BDE Freight 150 B N/A H/E 4942 6
Manifest DP -
M150BDM Freight 150 B N/A H/M/E 4942 6
Manifest DP -
M150CDE Freight 150 C N/A H/E 13891 7
Manifest DP -
M150CDM Freight 150 C N/A H/M/E 13891 7
Manifest DP -
M150DDE Freight 150 D N/A H/E 10796 6
Manifest DP -
M150DDM Freight 150 D N/A H/M/E 10796 6
Manifest DP -
M150EDE Freight 150 E N/A H/E 9753 6
Manifest DP -
M150EDM Freight 150 E N/A H/M/E 9753 6
Manifest DP -
M150FDE Freight 150 F N/A H/E 12542 6
Manifest DP -
M150FDM Freight 150 F N/A H/M/E 12542 6
Manifest DP -
M150GDE Freight 150 G N/A H/E 10884 6
Manifest DP -
M150GDM Freight 150 G N/A H/M/E 10884 6
Manifest DP -
M150HDE Freight 150 H N/A H/E 16043 7
Manifest DP -
M150HDM Freight 150 H N/A H/M/E 16043 7
Manifest DP -
M150IDE Freight 150 I N/A H/E 13721 7
Manifest DP -
M150IDM Freight 150 I N/A H/M/E 13721 7
Manifest DP -
M150JDE Freight 150 J N/A H/E 14991 7
Manifest DP -
M150JDM Freight 150 J N/A H/M/E 14991 7
Manifest DP -
M200ADE Freight 200 A N/A H/E 26535 12
Manifest DP -
M200ADM Freight 200 A N/A H/M/E 26535 12
Manifest DP -
M200BDE Freight 200 B N/A H/E 7108 8
Manifest DP -
M200BDM Freight 200 B N/A H/M/E 7108 8
Manifest DP -
M200CDE Freight 200 C N/A H/E 18565 9
Manifest DP -
M200CDM Freight 200 C N/A H/M/E 18565 9
178
 Trailing Number of
Consist Name Type Length Makeup Loading Power Tonnage Locomotives
Manifest DP -
M200DDE Freight 200 D N/A H/E 15649 8
Manifest DP -
M200DDM Freight 200 D N/A H/M/E 15649 8
Manifest DP -
M200EDE Freight 200 E N/A H/E 17315 8
Manifest DP -
M200EDM Freight 200 E N/A H/M/E 17315 8
Manifest DP -
M200FDE Freight 200 F N/A H/E 19152 9
Manifest DP -
M200FDM Freight 200 F N/A H/M/E 19152 9
Manifest DP -
M200GDE Freight 200 G N/A H/E 20566 9
Manifest DP -
M200GDM Freight 200 G N/A H/M/E 20566 9
Manifest DP -
M200HDE Freight 200 H N/A H/E 19139 9
Manifest DP -
M200HDM Freight 200 H N/A H/M/E 19139 9
Manifest DP -
M200IDE Freight 200 I N/A H/E 20049 9
Manifest DP -
M200IDM Freight 200 I N/A H/M/E 20049 9
Manifest DP -
M200JDE Freight 200 J N/A H/E 17541 8
Manifest DP -
M200JDM Freight 200 J N/A H/M/E 17541 8
Coal - DP -
U100ECEDE Unit 100 Eastern Empty H/E 2955 4
Coal - Head
U100ECEHE Unit 100 Eastern Empty End 2955 4
DP -
U100ECHDE Unit 100 Grain Empty H/E 3125 4
Head
U100ECHHE Unit 100 Grain Empty End 3125 4
Coal - DP -
U100ECWDE Unit 100 Western Empty H/E 2120 4
Coal - Head
U100ECWHE Unit 100 Western Empty End 2120 4
DP -
U100EMLDE Unit 100 Multilevel Empty H/E 5200 4
Head
U100EMLHE Unit 100 Multilevel Empty End 5200 4
Refrigerated DP -
U100ERBDE Unit 100 Box Empty H/E 5115 4
Refrigerated Head
U100ERBHE Unit 100 Box Empty End 5115 4
DP -
U100ETKDE Unit 100 Tank Empty H/E 3100 4
Head
U100ETKHE Unit 100 Tank Empty End 3100 4
179
 Trailing Number of
Consist Name Type Length Makeup Loading Power Tonnage Locomotives
Coal - DP -
U100LCEDE Unit 100 Eastern Loaded H/E 14300 4
Coal - Head
U100LCEHE Unit 100 Eastern Loaded End 14300 4
DP -
U100LCHDE Unit 100 Grain Loaded H/E 14300 4
Head
U100LCHHE Unit 100 Grain Loaded End 14300 4
Coal - DP -
U100LCWDE Unit 100 Western Loaded H/E 14300 4
Coal - Head
U100LCWHE Unit 100 Western Loaded End 14300 4
DP -
U100LMLDE Unit 100 Multilevel Loaded H/E 11000 4
Head
U100LMLHE Unit 100 Multilevel Loaded End 11000 4
Refrigerated DP -
U100LRBDE Unit 100 Box Loaded H/E 14300 4
Refrigerated Head
U100LRBHE Unit 100 Box Loaded End 14300 4
DP -
U100LTKDE Unit 100 Tank Loaded H/E 13150 4
Head
U100LTKHE Unit 100 Tank Loaded End 13150 4
Coal - DP -
U135ECEDE Unit 135 Eastern Empty H/E 3989 6
Coal - DP -
U135ECEDM Unit 135 Eastern Empty H/M/E 3989 6
DP -
U135ECHDE Unit 135 Grain Empty H/E 4219 6
DP -
U135ECHDM Unit 135 Grain Empty H/M/E 4219 6
Coal - DP -
U135ECWDE Unit 135 Western Empty H/E 2862 6
Coal - DP -
U135ECWDM Unit 135 Western Empty H/M/E 2862 6
DP -
U135EMLDE Unit 135 Multilevel Empty H/E 7020 6
DP -
U135EMLDM Unit 135 Multilevel Empty H/M/E 7020 6
Refrigerated DP -
U135ERBDE Unit 135 Box Empty H/E 6905 6
Refrigerated DP -
U135ERBDM Unit 135 Box Empty H/M/E 6905 6
DP -
U135ETKDE Unit 135 Tank Empty H/E 4185 6
DP -
U135ETKDM Unit 135 Tank Empty H/M/E 4185 6
Coal - DP -
U135LCEDE Unit 135 Eastern Loaded H/E 19305 6
Coal - DP -
U135LCEDM Unit 135 Eastern Loaded H/M/E 19305 6
180
 Trailing Number of
Consist Name Type Length Makeup Loading Power Tonnage Locomotives
DP -
U135LCHDE Unit 135 Grain Loaded H/E 19305 6
DP -
U135LCHDM Unit 135 Grain Loaded H/M/E 19305 6
Coal - DP -
U135LCWDE Unit 135 Western Loaded H/E 19305 6
Coal - DP -
U135LCWDM Unit 135 Western Loaded H/M/E 19305 6
DP -
U135LMLDE Unit 135 Multilevel Loaded H/E 14850 6
DP -
U135LMLDM Unit 135 Multilevel Loaded H/M/E 14850 6
Refrigerated DP -
U135LRBDE Unit 135 Box Loaded H/E 19305 6
Refrigerated DP -
U135LRBDM Unit 135 Box Loaded H/M/E 19305 6
DP -
U135LTKDE Unit 135 Tank Loaded H/E 17753 6
DP -
U135LTKDM Unit 135 Tank Loaded H/M/E 17753 6
Coal - DP -
U200ECEDE Unit 200 Eastern Empty H/E 5910 8
Coal - DP -
U200ECEDM Unit 200 Eastern Empty H/M/E 5910 8
Coal - DP -
U200ECWDE Unit 200 Western Empty H/E 4240 8
Coal - DP -
U200ECWDM Unit 200 Western Empty H/M/E 4240 8
Coal - DP -
U200LCEDE Unit 200 Eastern Loaded H/E 28600 8
Coal - DP -
U200LCEDM Unit 200 Eastern Loaded H/M/E 28600 8
Coal - DP -
U200LCWDE Unit 200 Western Loaded H/E 28600 8
Coal - DP -
U200LCWDM Unit 200 Western Loaded H/M/E 28600 8
Coal - DP -
U260ECEDM Unit 260 Eastern Empty H/M/E 7683 12
Coal - DP -
U260ECWDM Unit 260 Western Empty H/M/E 5512 12
Coal - DP -
U260LCEDM Unit 260 Eastern Loaded H/M/E 37180 12
Coal - DP -
U260LCWDM Unit 260 Western Loaded H/M/E 37180 12

181
Table C-2 lists the maximum operating speed for each consist on each grade used in the
simulation test matrix. A “*” in the table indicates that an air brake application is required to
maintain the given speed, in addition to use of dynamic brake. A “^” in the table indicates that
the maximum operating speed is less than the maximum allowable speed, for cases where it is
not possible to maintain the maximum allowable speed.
Table C-2. Maximum Speeds

1% 1%
Consist Name Flat 0.5% 1.5% -0.5% -1.1% -1.7% -2.2% -2.8% Crest Trough
IVEADM 60 60 25 60 60 25 20 15 52^ 60
IVEBDM 60 60 25 60 60 25 20 15 52^ 60
IVECDM 60 60 25 60 60 25 20 15 52^ 60
IVEDDM 60 60 25 60 60 25 20 15 52^ 60
IVEEDM 60 60 25 60 60 25 20 15 52^ 60
IVLADM 60 50^ 21^ 60 60 25 20 15* 30^ 60
IVLBDM 60 50^ 21^ 60 60 25 20 15* 30^ 60
IVLCDM 60 50^ 21^ 60 60 25 20 15* 30^ 60
IVLDDM 60 50^ 21^ 60 60 25 20 15* 30^ 60
IVLEDM 60 50^ 21^ 60 60 25 20 15* 30^ 60
ILEADE 60 60 25 60 60 25 20 20 53^ 60
ILEADM 60 60 25 60 60 25 20 20 53^ 60
ILEBDE 60 60 25 60 60 25 20 20 53^ 60
ILEBDM 60 60 25 60 60 25 20 20 53^ 60
ILECDE 60 60 25 60 60 25 20 20 53^ 60
ILECDM 60 60 25 60 60 25 20 20 53^ 60
ILEDDE 60 60 25 60 60 25 20 20 53^ 60
ILEDDM 60 60 25 60 60 25 20 20 53^ 60
ILEEDE 60 60 25 60 60 25 20 20 53^ 60
ILEEDM 60 60 25 60 60 25 20 20 53^ 60
ILLADE 60 48^ 20^ 60 60 25 20 15* 30^ 60
ILLADM 60 48^ 20^ 60 60 25 20 15* 30^ 60
ILLBDE 60 48^ 20^ 60 60 25 20 15* 30^ 60
ILLBDM 60 48^ 20^ 60 60 25 20 15* 30^ 60
ILLCDE 60 48^ 20^ 60 60 25 20 15* 30^ 60
ILLCDM 60 48^ 20^ 60 60 25 20 15* 30^ 60
ILLDDE 60 48^ 20^ 60 60 25 20 15* 30^ 60
ILLDDM 60 48^ 20^ 60 60 25 20 15* 30^ 60
ILLEDE 60 48^ 20^ 60 60 25 20 15* 30^ 60
ILLEDM 60 48^ 20^ 60 60 25 20 15* 30^ 60
IMEADE 60 60 25 60 60 25 20 20 52^ 60
IMEAHE 60 60 25 60 60 25 20 20 52^ 60
IMEBDE 60 60 25 60 60 25 20 20 52^ 60

182
 1% 1%
Consist Name Flat 0.5% 1.5% -0.5% -1.1% -1.7% -2.2% -2.8% Crest Trough
IMEBHE 60 60 25 60 60 25 20 20 52^ 60
IMECDE 60 60 25 60 60 25 20 20 52^ 60
IMECHE 60 60 25 60 60 25 20 20 52^ 60
IMEDDE 60 60 25 60 60 25 20 20 52^ 60
IMEDHE 60 60 25 60 60 25 20 20 52^ 60
IMEEDE 60 60 25 60 60 25 20 20 52^ 60
IMEEHE 60 60 25 60 60 25 20 20 52^ 60
IMLADE 70 50^ 25 70 70 25 20 15* 33^ 70
IMLAHE 70 50^ 25 70 70 25 20 15* 33^ 70
IMLBDE 70 50^ 25 70 70 25 20 15* 33^ 70
IMLBHE 70 50^ 25 70 70 25 20 15* 33^ 70
IMLCDE 70 50^ 25 70 70 25 20 15* 33^ 70
IMLCHE 70 50^ 25 70 70 25 20 15* 33^ 70
IMLDDE 70 50^ 25 70 70 25 20 15* 33^ 70
IMLDHE 70 50^ 25 70 70 25 20 15* 33^ 70
IMLEDE 70 50^ 25 70 70 25 20 15* 33^ 70
IMLEHE 70 50^ 25 70 70 25 20 15* 33^ 70
ISEADE 60 60 25 60 60 25 20 20 57^ 60
ISEAHE 60 60 25 60 60 25 20 20 57^ 60
ISEBDE 60 60 25 60 60 25 20 20 57^ 60
ISEBHE 60 60 25 60 60 25 20 20 57^ 60
ISECDE 60 60 25 60 60 25 20 20 57^ 60
ISECHE 60 60 25 60 60 25 20 20 57^ 60
ISEDDE 60 60 25 60 60 25 20 20 57^ 60
ISEDHE 60 60 25 60 60 25 20 20 57^ 60
ISEEDE 60 60 25 60 60 25 20 20 57^ 60
ISEEHE 60 60 25 60 60 25 20 20 57^ 60
ISLADE 70 55^ 25 70 70 25 20 15* 35^ 70
ISLAHE 70 55^ 25 70 70 25 20 15* 35^ 70
ISLBDE 70 55^ 25 70 70 25 20 15* 35^ 70
ISLBHE 70 55^ 25 70 70 25 20 15* 35^ 70
ISLCDE 70 55^ 25 70 70 25 20 15* 35^ 70
ISLCHE 70 55^ 25 70 70 25 20 15* 35^ 70
ISLDDE 70 55^ 25 70 70 25 20 15* 35^ 70
ISLDHE 70 55^ 25 70 70 25 20 15* 35^ 70
ISLEDE 70 55^ 25 70 70 25 20 15* 35^ 70
ISLEHE 70 55^ 25 70 70 25 20 15* 35^ 70
M0AHE 60 60 25 60 55 25 20 20 55 55
M0BHE 60 60 25 60 55 25 20 20 55 55

183
 1% 1%
Consist Name Flat 0.5% 1.5% -0.5% -1.1% -1.7% -2.2% -2.8% Crest Trough
M0AHEG 60 60 25 60 55 25 20 20 55 55
M0BHEG 60 60 25 60 55 25 20 20 55 55
M3AHE 60 60 25 60 45 25 20 15 45 45
M3BHE 60 60 25 60 45 25 20 15 45 45
M3CHE 60 60 25 60 45 25 20 15 45 45
M3DHE 60 60 25 60 45 25 20 15 45 45
M3EHE 60 60 25 60 45 25 20 15 45 45
M3FHE 60 60 25 60 45 25 20 15 45 45
M3GHE 60 60 25 60 45 25 20 15 45 45
M3HHE 60 60 25 60 45 25 20 15 45 45
M3IHE 60 60 25 60 45 25 20 15 45 45
M3JHE 60 60 25 60 45 25 20 15 45 45
M3AHEG 60 60 25 60 45 25 20 15 45 45
M3BHEG 60 60 25 60 45 25 20 15 45 45
M3CHEG 60 60 25 60 45 25 20 15 45 45
M3DHEG 60 60 25 60 45 25 20 15 45 45
M3EHEG 60 60 25 60 45 25 20 15 45 45
M3FHEG 60 60 25 60 45 25 20 15 45 45
M3GHEG 60 60 25 60 45 25 20 15 45 45
M3HHEG 60 60 25 60 45 25 20 15 45 45
M3IHEG 60 60 25 60 45 25 20 15 45 45
M3JHEG 60 60 25 60 45 25 20 15 45 45
M10AHE 60 60 25 60 45 25 20 15 45 45
M10BHE 60 60 25 60 45 25 20 15 45 45
M10CHE 60 60 25 60 45 25 20 15 45 45
M10DHE 60 60 25 60 45 25 20 15 45 45
M10EHE 60 60 25 60 45 25 20 15 45 45
M10FHE 60 60 25 60 45 25 20 15 45 45
M10GHE 60 60 25 60 45 25 20 15 45 45
M10HHE 60 60 25 60 45 25 20 15 45 45
M10IHE 60 60 25 60 45 25 20 15 45 45
M10JHE 60 60 25 60 45 25 20 15 45 45
M10AHEG 60 60 25 60 45 25 20 15 45 45
M10BHEG 60 60 25 60 45 25 20 15 45 45
M10CHEG 60 60 25 60 45 25 20 15 45 45
M10DHEG 60 60 25 60 45 25 20 15 45 45
M10EHEG 60 60 25 60 45 25 20 15 45 45
M10FHEG 60 60 25 60 45 25 20 15 45 45
M10GHEG 60 60 25 60 45 25 20 15 45 45

184
 1% 1%
Consist Name Flat 0.5% 1.5% -0.5% -1.1% -1.7% -2.2% -2.8% Crest Trough
M10HHEG 60 60 25 60 45 25 20 15 45 45
M10IHEG 60 60 25 60 45 25 20 15 45 45
M10JHEG 60 60 25 60 45 25 20 15 45 45
M40AHE 60 46^ 20^ 60 45* 25* 20* 15* 28^ 45
M40BHE 60 46^ 20^ 60 45* 25* 20* 15* 28^ 45
M40CHE 60 46^ 20^ 60 45* 25* 20* 15* 28^ 45
M40DHE 60 46^ 20^ 60 45* 25* 20* 15* 28^ 45
M40EHE 60 46^ 20^ 60 45* 25* 20* 15* 28^ 45
M40FHE 60 46^ 20^ 60 45* 25* 20* 15* 28^ 45
M40GHE 60 46^ 20^ 60 45* 25* 20* 15* 28^ 45
M40HHE 60 46^ 20^ 60 45* 25* 20* 15* 28^ 45
M40IHE 60 46^ 20^ 60 45* 25* 20* 15* 28^ 45
M40JHE 60 46^ 20^ 60 45* 25* 20* 15* 28^ 45
M100ADE 60 45^ 18^ 60 45* 25* 20* 15* 26^ 45
M100AHE 60 45^ 18^ 60 45* 25* 20* 15* 26^ 45
M100BDE 60 45^ 18^ 60 45* 25* 20* 15* 26^ 45
M100BHE 60 45^ 18^ 60 45* 25* 20* 15* 26^ 45
M100CDE 60 45^ 18^ 60 45* 25* 20* 15* 26^ 45
M100CHE 60 45^ 18^ 60 45* 25* 20* 15* 26^ 45
M100DDE 60 45^ 18^ 60 45* 25* 20* 15* 26^ 45
M100DHE 60 45^ 18^ 60 45* 25* 20* 15* 26^ 45
M100EDE 60 45^ 18^ 60 45* 25* 20* 15* 26^ 45
M100EHE 60 45^ 18^ 60 45* 25* 20* 15* 26^ 45
M100FDE 60 45^ 18^ 60 45* 25* 20* 15* 26^ 45
M100FHE 60 45^ 18^ 60 45* 25* 20* 15* 26^ 45
M100GDE 60 45^ 18^ 60 45* 25* 20* 15* 26^ 45
M100GHE 60 45^ 18^ 60 45* 25* 20* 15* 26^ 45
M100HDE 60 45^ 18^ 60 45* 25* 20* 15* 26^ 45
M100HHE 60 45^ 18^ 60 45* 25* 20* 15* 26^ 45
M100IDE 60 45^ 18^ 60 45* 25* 20* 15* 26^ 45
M100IHE 60 45^ 18^ 60 45* 25* 20* 15* 26^ 45
M100JDE 60 45^ 18^ 60 45* 25* 20* 15* 26^ 45
M100JHE 60 45^ 18^ 60 45* 25* 20* 15* 26^ 45
M150ADE 60 40^ 15^ 60 45* 25* 20* 0 23^ 40^
M150ADM 60 40^ 15^ 60 45* 25* 20* 0 23^ 40^
M150BDE 60 40^ 15^ 60 45* 25* 20* 0 23^ 40^
M150BDM 60 40^ 15^ 60 45* 25* 20* 0 23^ 40^
M150CDE 60 40^ 15^ 60 45* 25* 20* 0 23^ 40^
M150CDM 60 40^ 15^ 60 45* 25* 20* 0 23^ 40^

185
 1% 1%
Consist Name Flat 0.5% 1.5% -0.5% -1.1% -1.7% -2.2% -2.8% Crest Trough
M150DDE 60 40^ 15^ 60 45* 25* 20* 0 23^ 40^
M150DDM 60 40^ 15^ 60 45* 25* 20* 0 23^ 40^
M150EDE 60 40^ 15^ 60 45* 25* 20* 0 23^ 40^
M150EDM 60 40^ 15^ 60 45* 25* 20* 0 23^ 40^
M150FDE 60 40^ 15^ 60 45* 25* 20* 0 23^ 40^
M150FDM 60 40^ 15^ 60 45* 25* 20* 0 23^ 40^
M150GDE 60 40^ 15^ 60 45* 25* 20* 0 23^ 40^
M150GDM 60 40^ 15^ 60 45* 25* 20* 0 23^ 40^
M150HDE 60 40^ 15^ 60 45* 25* 20* 0 23^ 40^
M150HDM 60 40^ 15^ 60 45* 25* 20* 0 23^ 40^
M150IDE 60 40^ 15^ 60 45* 25* 20* 0 23^ 40^
M150IDM 60 40^ 15^ 60 45* 25* 20* 0 23^ 40^
M150JDE 60 40^ 15^ 60 45* 25* 20* 0 23^ 40^
M150JDM 60 40^ 15^ 60 45* 25* 20* 0 23^ 40^
M200ADE 60 38^ 14^ 60 45* 25* 20* 0 21^ 36^
M200ADM 60 38^ 14^ 60 45* 25* 20* 0 21^ 36^
M200BDE 60 38^ 14^ 60 45* 25* 20* 0 21^ 36^
M200BDM 60 38^ 14^ 60 45* 25* 20* 0 21^ 36^
M200CDE 60 38^ 14^ 60 45* 25* 20* 0 21^ 36^
M200CDM 60 38^ 14^ 60 45* 25* 20* 0 21^ 36^
M200DDE 60 38^ 14^ 60 45* 25* 20* 0 21^ 36^
M200DDM 60 38^ 14^ 60 45* 25* 20* 0 21^ 36^
M200EDE 60 38^ 14^ 60 45* 25* 20* 0 21^ 36^
M200EDM 60 38^ 14^ 60 45* 25* 20* 0 21^ 36^
M200FDE 60 38^ 14^ 60 45* 25* 20* 0 21^ 36^
M200FDM 60 38^ 14^ 60 45* 25* 20* 0 21^ 36^
M200GDE 60 38^ 14^ 60 45* 25* 20* 0 21^ 36^
M200GDM 60 38^ 14^ 60 45* 25* 20* 0 21^ 36^
M200HDE 60 38^ 14^ 60 45* 25* 20* 0 21^ 36^
M200HDM 60 38^ 14^ 60 45* 25* 20* 0 21^ 36^
M200IDE 60 38^ 14^ 60 45* 25* 20* 0 21^ 36^
M200IDM 60 38^ 14^ 60 45* 25* 20* 0 21^ 36^
M200JDE 60 38^ 14^ 60 45* 25* 20* 0 21^ 36^
M200JDM 60 38^ 14^ 60 45* 25* 20* 0 21^ 36^
U100ECEDE 60 60 25 60 55 25 20 0 46^ 55
U100ECEHE 60 60 25 60 55 25 20 0 46^ 55
U100ECHDE 60 60 25 60 55 25 20 0 45^ 55
U100ECHHE 60 60 25 60 55 25 20 0 45^ 55
U100ECWDE 60 60 25 60 55 25 20 0 52^ 55

186
 1% 1%
Consist Name Flat 0.5% 1.5% -0.5% -1.1% -1.7% -2.2% -2.8% Crest Trough
U100ECWHE 60 60 25 60 55 25 20 0 52^ 55
U100EMLDE 60 50^ 25 60 55 25 20 0 34^ 55
U100EMLHE 60 50^ 25 60 55 25 20 0 34^ 55
U100ERBDE 60 50^ 25 60 55 25 20 0 34^ 55
U100ERBHE 60 50^ 25 60 55 25 20 0 34^ 55
U100ETKDE 60 60 25 60 55 25 20 0 47^ 55
U100ETKHE 60 60 25 60 55 25 20 0 47^ 55
U100LCEDE 50 27^ 10^ 50 45* 15*^ 15 0 15^ 24^
U100LCEHE 50 27^ 10^ 50 45* 15*^ 15 0 15^ 24^
U100LCHDE 50 26^ 10^ 50 45* 15*^ 15 0 14^ 23^
U100LCHHE 50 26^ 10^ 50 45* 15*^ 15 0 14^ 23^
U100LCWDE 50 26^ 10^ 50 45* 15*^ 15 0 14^ 23^
U100LCWHE 50 26^ 10^ 50 45* 15*^ 15 0 14^ 23^
U100LMLDE 50 34^ 13^ 50 45* 25* 15*^ 0 19^ 33^
U100LMLHE 50 34^ 13^ 50 45* 25* 15*^ 0 19^ 33^
U100LRBDE 50 30^ 11^ 50 45* 15*^ 15 0 16^ 26^
U100LRBHE 50 30^ 11^ 50 45* 15*^ 15 0 16^ 26^
U100LTKDE 50 30^ 10^ 50 45* 20*^ 15 0 15^ 25^
U100LTKHE 50 30^ 10^ 50 45* 20*^ 15 0 15^ 25^
U135ECEDE 60 60 25 60 55 25 20 0 50^ 55
U135ECEDM 60 60 25 60 55 25 20 0 50^ 55
U135ECHDE 60 60 25 60 55 25 20 0 47^ 55
U135ECHDM 60 60 25 60 55 25 20 0 47^ 55
U135ECWDE 60 60 25 60 55 25 20 0 55 55
U135ECWDM 60 60 25 60 55 25 20 0 55 55
U135EMLDE 60 53^ 25 60 55 25 20 0 36^ 55
U135EMLDM 60 53^ 25 60 55 25 20 0 36^ 55
U135ERBDE 60 52^ 25 60 55 25 20 0 35^ 55
U135ERBDM 60 52^ 25 60 55 25 20 0 35^ 55
U135ETKDE 60 60 25 60 55 25 20 0 48^ 55
U135ETKDM 60 60 25 60 55 25 20 0 48^ 55
U135LCEDE 50 30^ 11^ 50 45* 25* 15 0 16^ 27^
U135LCEDM 50 30^ 11^ 50 45* 25* 15 0 16^ 27^
U135LCHDE 50 30^ 11^ 50 45* 25* 15 0 15^ 27^
U135LCHDM 50 30^ 11^ 50 45* 25* 15 0 15^ 27^
U135LCWDE 50 30^ 11^ 50 45* 25* 15 0 15^ 27^
U135LCWDM 50 30^ 11^ 50 45* 25* 15 0 15^ 27^
U135LMLDE 50 37^ 14^ 50 45* 25* 15*^ 0 21^ 37^
U135LMLDM 50 37^ 14^ 50 45* 25* 15*^ 0 21^ 37^

187
 1% 1%
Consist Name Flat 0.5% 1.5% -0.5% -1.1% -1.7% -2.2% -2.8% Crest Trough
U135LRBDE 50 31^ 12^ 50 45* 25* 15 0 17^ 30^
U135LRBDM 50 31^ 12^ 50 45* 25* 15 0 17^ 30^
U135LTKDE 50 31^ 12^ 50 45* 25* 15 0 16^ 30^
U135LTKDM 50 31^ 12^ 50 45* 25* 15 0 16^ 30^
U200ECEDE 60 60 25 60 45 25 20 0 45 45
U200ECEDM 60 60 25 60 45 25 20 0 45 45
U200ECWDE 60 60 25 60 45 25 20 0 45 45
U200ECWDM 60 60 25 60 45 25 20 0 45 45
U200LCEDE 50 27^ 10^ 50 45* 20*^ 15 0 15^ 27^
U200LCEDM 50 27^ 10^ 50 45* 20*^ 15 0 15^ 27^
U200LCWDE 50 26^ 10^ 50 45* 20*^ 15 0 14^ 25^
U200LCWDM 50 26^ 10^ 50 45* 20*^ 15 0 14^ 25^
U260ECEDM 60 60 25 60 45* 25 20 0 45 45
U260ECWDM 60 60 25 60 45* 25 20 0 45 45
U260LCEDM 50 31^ 12^ 50 45* 20*^ 15 0 17^ 28^
U260LCWDM 50 30^ 11^ 50 45* 20*^ 15 0 16^ 27^

Below are the intermodal cars used to make up the intermodal consists and their nominal values
Car Parameter Nominal Value

Weight GRL 220,000 lb

Intermodal Tare Weight 71,596 lb

Single
Platform

Brake Force 25,060 (Loaded)

(64psi) 13,673 (Empty)

Piston Travel 7.5"

Length 71.69'

188
 Car Parameter Nominal Value

Weight GRL 486,000 lb

Intermodal Tare Weight 159,569 lb

3-Pack

Brake Force 55,471 (Loaded)

(64psi) 30,316 (Empty)

Piston Travel 7.5"

Length 203.98'

Car Parameter Nominal Value

Weight GRL 801,200 lb

Intermodal Tare Weight 212,142 lb

5-Pack

Brake Force 89,864 (Loaded)

(64psi) 48,394 (Empty)

Piston Travel 7.5"

Length 265.13'

Below are the manifest cars used to make up the manifest consists and their nominal values
189
 Car Parameter Nominal Value

Weight GRL 263,000 lb

Covered Tare Weight 65,750 lb

Hopper Cars

Brake Force 24,128 (Loaded)

(64psi) 20,039 (Empty)

Piston Travel 7.5"

Length 65.08'

Car Parameter Nominal Value

Weight GRL 286,000 lb

Equipped Tare Weight 51,200 lb

Hopper
Cars

Brake Force 31,630 (Loaded)

(64psi) 15,815 (Empty)

Piston Travel 7.5"

Length 53.04

190
 Car Parameter Nominal Value

Weight GRL 286,000 lb

Refrigerator Tare Weight 102,300 lb

Box Cars

Brake Force 29,097 (Loaded)

(64psi) 28,437 (Empty)

Piston Travel 7.5"

Length 83.75'

Car Parameter Nominal Value

Weight GRL 263,000 lb

Tank Tare Weight 62,000 lb

Cars

Brake Force 23,136 (Loaded)

(64psi) 20,669 (Empty)

Piston Travel 7.5"

Length 43.06'

191
 Car Parameter Nominal Value

Weight GRL 263,000 lb

Equipped Tare Weight 84,000 lb

Box Cars

Brake Force 26,153 (Loaded)

(64psi) 25,418 (Empty)

Piston Travel 7.5"

Length 68.06'

Car Parameter Nominal Value

Weight GRL 222,000 lb

Unequipped Tare Weight 61,600 lb

Box Cars

Brake Force 19,993 (Loaded)

(64psi) 19,608 (Empty)

Piston Travel 7.5"

Length 55.42'

192
 Car Parameter Nominal Value

Weight GRL 263,000 lb

Equipped Tare Weight 67,000 lb

Gondola

Brake Force 23,192 (Loaded)

(64psi) 21,763 (Empty)

Piston Travel 7.5"

Length 58.13'

Car Parameter Nominal Value

Weight GRL 263,000 lb

Tare Weight 75,122 lb

Flat Cars

Brake Force 25,678 (Loaded)

(64psi) 21,596 (Empty)

Piston Travel 7.5"

Length 66.00'

193
 Car Parameter Nominal Value

Weight GRL 263,000 lb

Unequipped Tare Weight 58,500 lb

Hopper

Brake Force 22,501 (Loaded)

(64psi) 19,014 (Empty)

Piston Travel 7.5"

Length 53.08'

Car Parameter Nominal Value

Weight GRL 220,000 lb

Conventional Tare Weight 66,900 lb

Intermodal
Cars

Brake Force 22,589 (Loaded)

(64psi) 19,515 (Empty)

Piston Travel 7.5"

Length 92.75'

194
 Car Parameter Nominal Value

Weight GRL 220,000 lb

Vehicular Tare Weight 104,000 lb

Flat Cars

Brake Force 22,374 (Loaded)

(64psi) 22,374 (Empty)

Piston Travel 7.5"

Length 93.83'

Car Parameter Nominal Value

Weight GRL 286,000 lb

Gondola Tare Weight 42,400 lb

Cars

Brake Force 31,104 (Loaded)

(64psi) 15,552 (Empty)

Piston Travel 7.5"

Length 53.08'

195
 Car Parameter Nominal Value

Weight GRL 263,000 lb

Equipped Tare Weight 67,800 lb

Gondola

Brake Force 24,450 (Loaded)

(64psi) 21,021 (Empty)

Piston Travel 7.5"

Length 57.04'

Below are the unit cars used to make up the unit consists and their nominal values
Car Parameter Nominal Value

Weight GRL 286,000 lb

Unit Tare Weight 42,400 lb

Aluminum
Hoppers

Brake Force 31,801 (Loaded)

(64psi) 15,901 (Empty)

Piston Travel 7.5"

Length 53.08'

196
 Car Parameter Nominal Value

Weight GRL 286,000 lb

Unit Tare Weight 63,790 lb

Covered
Hopper

Brake Force 27,903 (Loaded)

(64psi) 19,148 (Empty)

Piston Travel 7.5"

Length 59.00'

Car Parameter Nominal Value

Weight GRL 220,000 lb

Unit Tare Weight 102,170 lb

Multilevel

Brake Force 22,489 (Loaded)

(64psi) 22,489 (Empty)

Piston Travel 7.5"

Length 93.83'

197
 Car Parameter Nominal Value

Weight GRL 286,000 lb

Unit Tare Weight 103,548 lb

Refrigerated
Boxcar

Brake Force 29,120 (Loaded)

(64psi) 28,460 (Empty)

Piston Travel 7.5"

Length 83.75'

Car Parameter Nominal Value

Weight GRL 286,000 lb

Unit Steel Tare Weight 64,360 lb

Hopper

Brake Force 25,619 (Loaded)

(64psi) 20,018 (Empty)

Piston Travel 7.5"

Length 48.71'

198
 Car Parameter Nominal Value

Weight GRL 263,000 lb

Unit Tank Tare Weight 64,641 lb

Cars

Brake Force 23,945 (Loaded)

(64psi) 20,386 (Empty)

Piston Travel 7.5"

Length 43.06'

199
Appendix D.
Distributions Used for Variable Parameters in Simulation Testing
The detailed distributions for each car are shown in the tables below.
Car Distribution Type Distribution Details

23% - 95% (3%)

95% - 100% (27%)

Weight 100% - 105% (55%)
Min: 42000 lb Discrete Uniform
Max: 289300 lb 105% - 110% (12%)

110% - 115% (2%)

115% - 170% (1%)

1808 - 3288 (10%)

1808 - 3288 (26%)

Brake Force
Empty Load Equipped: Discrete Uniform 1918 - 3324 (9%)
28%
2557 - 3324 (1%)

2557 - 3580 (54%)

1808 - 2491 (65%)

Brake Force
Not Empty Load Discrete Uniform 1808 - 2491 (24%)
Covered Hopper Equipped: 72%
Cars 1918 - 2454 (11%)

ABD (36%)

Brake Valve Discrete Uniform ABDW (19%)

ABDX (45%)

Piston Travel Normal Mean = 7.5" SD = 0.87"

Aerodynamic: Mean = 0.07 SD = 0

Nominal

Bearing Resistance: Mean = 18 SD = 3

Davis Equation Normal
Variables
Constant: Mean = 0.6 SD = 0.1
Normal

Velocity Dependent: Mean = 0.01 SD = .0017

Normal

200
 Car Distribution Type Distribution Details

86% - 90% (6%)

90% - 100% (42%)

Weight 100% - 105% (39%)

Min: 48000 lb Discrete Uniform
Max: 314600 lb 105% - 110% (9%)

110% - 125% (3%)

125% - 190% (1%)

1966 - 3575 (4%)

1966 - 3575 (26%)

Brake Force
Empty Load Equipped: Discrete Uniform 2085 - 3615 (18%)
100%
2781 - 3615 (3%)

2781 - 3893 (49%)

Equipped ABD (25%)

Hopper Cars
Brake Valve Discrete Uniform ABDW (15%)

ABDX (60%)

Piston Travel Normal Mean = 7.5" SD = 0.87"

Mean = 0.07 SD = 0
Aerodynamic:
Nominal

Mean = 18 SD = 3
Bearing Resistance:
Davis Equation Normal
Variables
Mean = 0.6 SD = 0.1
Constant:
Normal

Mean = 0.01 SD = .0017

Velocity Dependent:
Normal

201
 Car Distribution Type Distribution Details

35% - 85% (2%)

85% - 95% (21%)

Weight
Min: 74000 lb Discrete Uniform 95% - 105% (65%)
Max: 314600 lb
105% - 110% (9%)

110% - 270% (3%)

1966 - 3575 (18%)

Brake Force
Empty Load Equipped: Discrete Uniform 2085 - 3615 (6%)
4%
2781 - 3893 (76%)

1966 - 3575 (76%)

1966 - 3575 (2%)

Brake Force
Not Empty Load Discrete Uniform 2085 - 3615 (8%)
Equipped: 96%
2781 - 3615 (2%)

Refrigerator Box 2781 - 3221 (12%)

Cars
ABD (69%)

Brake Valve Discrete Uniform ABDW (8%)

ABDX (23%)

Piston Travel Normal Mean = 7.5" SD = 0.87"

Mean = 0.07 SD = 0
Aerodynamic:
Nominal

Mean = 18 SD = 3
Bearing Resistance:
Davis Equation Normal
Variables
Mean = 0.6 SD = 0.1
Constant:
Normal

Mean = 0.01 SD = .0017

Velocity Dependent:
Normal

202
 Car Distribution Type Distribution Details

80% - 95% (3%)

95% - 100% (18%)

Weight
Min: 52000 lb Discrete Uniform 100% - 105% (64%)
Max: 289600 lb
105% - 110% (12%)

110% - 175% (3%)

1808 - 3288 (4%)

1808 - 3288 (5%)

Brake Force
Empty Load Equipped: Discrete Uniform 1918 - 3324 (1%)
16%
2557 - 3324 (1%)

2557 - 3580 (85%)

1808 - 2394 (53%)

Brake Force
Not Empty Load Discrete Uniform 1808 - 2394 (31%)
Equipped: 84%
Tank Cars 1918 - 2358 (16%)

ABD (27%)

Brake Valve Discrete Uniform ABDW (18%)

ABDX (55%)

Piston Travel Normal Mean = 7.5" SD = 0.87"

Aerodynamic:
Mean = 0.07 SD = 0
Nominal

Bearing Resistance: Mean = 18 SD = 3

Davis Equation Normal
Variables

Constant: Mean = 0.6 SD = 0.1

Normal

Velocity Dependent: Mean = 0.01 SD = .0017

Normal

203
 Car Distribution Type Distribution Details

25% - 40% (1%)

70% - 95% (4%)

95% - 100% (19%)

Weight
Min: 50000 lb Discrete Uniform 100% - 105% (50%)
Max: 289300 lb
105% - 110% (22%)

110% - 120% (3%)

120% - 140% (1%)

1808 - 3288 (9%)

Brake Force 1918 - 3324 (34%)
Empty Load Equipped: Discrete Uniform
5% 2557 - 3324 (9%)

2557 - 3580 (48%)

1808 - 3207 (72%)

1808 - 3207 (10%)

Brake Force
Not Empty Load Discrete Uniform 1918 - 2358 (10%)
Equipped Box Equipped: 95%
Cars 2557 - 3159 (3%)

2557 - 2660 (5%)

ABD (54%)

Brake Valve Discrete Uniform ABDW (19%)

ABDX (27%)

Piston Travel Normal Mean = 7.5" SD = 0.87"

Aerodynamic: Mean = 0.07 SD = 0

Nominal

Bearing Resistance: Mean = 18 SD = 3

Davis Equation Normal
Variables
Constant: Mean = 0.6 SD = 0.1
Normal

Velocity Dependent: Mean = 0.01 SD = .0017

Normal

204
 Car Distribution Type Distribution Details

30% - 35% (2%)

80% - 95% (6%)

95% - 100% (27%)

Weight
Min: 50000 lb Discrete Uniform 100% - 105% (46%)
Max: 242000 lb
105% - 110% (15%)

110% - 120% (3%)

120% - 155% (1%)

1604 - 2781 (10%)

Brake Force
Empty Load Equipped: Discrete Uniform 2139 - 2781 (31%)
3%
2139 - 2994 (59%)

1513 - 2320 (70%)

Brake Force 1513 - 2320 (2%)

Not Empty Load Discrete Uniform
Equipped: 97% 1604 - 2285 (27%)
Unequipped Box
Cars 2139 - 2285 (1%)

ABD (38%)

Brake Valve Discrete Uniform ABDW (29%)

ABDX (23%)

Piston Travel Normal Mean = 7.5" SD = 0.87"

Aerodynamic: Mean = 0.07 SD = 0

Nominal

Bearing Resistance: Mean = 18 SD = 3

Davis Equation Normal
Variables
Constant: Mean = 0.6 SD = 0.1
Normal

Velocity Dependent: Mean = 0.01 SD = .0017

Normal

205
 Car Distribution Type Distribution Details

25% - 55% (2%)

70% - 95% (3%)

95% - 100% (22%)

Weight
Min: 50000 lb Discrete Uniform 105% - 105% (50%)
Max: 289300 lb
105% - 110% (14%)

110% - 120% (5%)

120% - 170% (4%)

1808 - 3288 (5%)

1808 - 3288 (33%)

Brake Force
Empty Load Equipped: Discrete Uniform 1918 - 3324 (20%)
10%
2577 - 3324 (2%)

2577 - 3580 (40%)

1808 - 2577 (72%)

Brake Force
Equipped Not Empty Load Discrete Uniform 1808 - 2577 (17%)
Gondola Equipped: 90%
1918 - 2539 (11%)

ABD (52%)

Brake Valve Discrete Uniform ABDW (15%)

ABDX (33%)

Piston Travel Normal Mean = 7.5" SD = 0.87"

Aerodynamic: Mean = 0.07 SD = 0

Nominal

Bearing Resistance: Mean = 18 SD = 3

Davis Equation Normal
Variables
Constant: Mean = 0.6 SD = 0.1
Normal

Velocity Dependent: Mean = 0.01 SD = .0017

Normal

206
 Car Distribution Type Distribution Details
20% - 30% (2%)
75% - 95% (6%)
95% - 100% (26%)
Weight
Min: 50000 lb Discrete Uniform 100% - 105% (46%)
Max: 289300 lb
105% - 110% (13%)
110% - 140% (3%)
140% - 210% (4%)
1808 - 3288 (5%)
1808 - 3288 (22%)
Brake Force
Empty Load Equipped: Discrete Uniform 1918 - 3324 (19%)
28%
2557- 3324 (7%)
2557 - 3580 (47%)
1808 - 2897 (63%)
Brake Force 1808 - 2897 (18%)
Flat Cars Not Empty Load Discrete Uniform
Equipped: 72% 1918 - 2859 (17%)
2557 - 2854 (2%)
ABD (39%)
Brake Valve Discrete Uniform ABDW (11%)
ABDX (50%)

Piston Travel Normal Mean = 7.5" SD = 0.87"

Aerodynamic: Mean = 0.07 SD = 0

Nominal

Bearing Resistance: Mean = 18 SD = 3

Davis Equation Normal
Variables
Constant: Mean = 0.6 SD = 0.1
Normal

Velocity Dependent: Mean = 0.01 SD = .0017

Normal

207
 Car Distribution Type Distribution Details

75% - 90% (6%)

90% - 95% (20%)

Weight 95% - 100% (41%)

Min: 48000 lb Discrete Uniform
Max: 289300 lb 100% - 110% (28%)

110% - 120% (4%)

120% - 131% (1%)

1808 - 3288 (23%)

Brake Force 1808 - 3288 (17%)

Empty Load Equipped: Discrete Uniform
24% 1918 - 3324 (8%)

2557 - 3580 (52%)

1808 - 2165 (93%)

Brake Force
Not Empty Load Discrete Uniform
Equipped: 76%
Unequipped 1808 - 2165 (7%)
Hopper
ABD (62%)

Brake Valve Discrete Uniform ABDW (20%)

ABDX (18%)

Piston Travel Normal Mean = 7.5" SD = 0.87"

Aerodynamic: Mean = 0.07 SD = 0

Nominal

Bearing Resistance: Mean = 18 SD = 3

Davis Equation Normal
Variables

Constant: Mean = 0.6 SD = 0.1

Normal

Velocity Dependent: Mean = 0.01 SD = .0017

Normal

208
 Car Distribution Type Distribution Details

20% - 30% (2%)

75% - 95% (6%)

95% - 100% (26%)

Weight
Min: 60000 lb Discrete Uniform 100% - 105% (46%)
Max: 242000 lb
105% - 110% (13%)

110% - 140% (3%)

140% - 210% (4%)

1513 - 2750 (21%)

Brake Force
Empty Load Discrete Uniform 2139 - 2781 (77%)
Equipped: 25%
2139 - 2781 (2%)

Brake Force
Not Empty Load Flat 1513 - 2750
Equipped: 75%
Conventional
Intermodal Cars
ABD (69%)

Brake Valve Discrete Uniform ABDW (15%)

ABDX (16%)

Piston Travel Normal Mean = 7.5" SD = 0.87"

Aerodynamic: Mean = 0.07 SD = 0

Nominal

Bearing Resistance: Mean = 18 SD = 3

Davis Equation Normal
Variables
Constant: Mean = 0.6 SD = 0.1
Normal

Velocity Dependent: Mean = 0.01 SD = .0017

Normal

209
 Car Distribution Type Distribution Details

49% - 85% (6%)

85% - 90% (20%)

Weight 90% - 105% (41%)

Min: 82000 lb Discrete Uniform
Max: 242000 lb 105% - 110% (28%)

110% - 115% (4%)

115% - 130% (1%)

1513 - 2750 (71%)

Brake Force 1513 - 2750 (6%)

Not Empty Load Discrete Uniform
Equipped: 100% 1604 - 2781 (15%)

2139 - 2994 (8%)

ABD (59%)
Vehicular Flat
Cars Brake Valve Discrete Uniform ABDW (14%)

ABDX (27%)

Piston Travel Normal Mean = 7.5" SD = 0.87"

Mean = 0.07 SD = 0
Aerodynamic:
Nominal

Mean = 18 SD = 3
Bearing Resistance:
Normal
Davis Equation Variables

Mean = 0.6 SD = 0.1

Constant:
Normal

Mean = 0.01 SD = .0017

Velocity Dependent:
Normal

210
 Car Distribution Type Distribution Details

30% - 85% (10%)

85% - 95% (13%)

95% - 100% (28%)

Weight
Min: 42000 lb Discrete Uniform 100% - 105% (19%)
Max: 314600 lb
105% - 110% (11%)

110% - 125% (14%)

125% - 155% (5%)

1966 - 3575 (11%)

1966 - 3575 (30%)

Brake Force
Empty Load Equipped: Discrete Uniform 2085 - 3615 (16%)
100%
2781 - 3615 (2%)

2781 - 3893 (41%)

Gondola
Cars ABD (33%)

Brake Valve Discrete Uniform ABDW (15%)

ABDX (42%)

Piston Travel Normal Mean = 7.5" SD = 0.87"

Aerodynamic: Mean = 0.07 SD = 0

Nominal

Bearing Resistance: Mean = 18 SD = 3

Davis Equation Normal
Variables

Constant: Mean = 0.6 SD = 0.1

Normal

Velocity Dependent: Mean = 0.01 SD = .0017

Normal

211
 Car Distribution Type Distribution Details

35% - 90% (20%)

90% - 95% (9%)

95% - 100% (19%)

Weight
Min: 48000 lb Discrete Uniform 100% - 110% (24%)
Max: 289300 lb
110% - 120% (10%)

120% - 185% (14%)

185% - 225% (4%)

1808 - 3288 (5%)

1808 - 3288 (33%)

Brake Force
Empty Load Equipped: Discrete Uniform 1918 - 3324 (20%)
24%
2557 - 3324 (2%)

2557 - 3580 (40%)

1808 - 2685 (72%)

Brake Force
Equipped Not Empty Load Discrete Uniform 1808 - 2685 (17%)
Gondola Equipped: 76%
1918 - 2645 (11%)

ABD (34%)

Brake Valve Discrete Uniform ABDW (13%)

ABDX (53%)

Piston Travel Normal Mean = 7.5" SD = 0.87"

Aerodynamic: Mean = 0.07 SD = 0

Nominal

Bearing Resistance: Mean = 18 SD = 3

Davis Equation Normal
Variables
Constant: Mean = 0.6 SD = 0.1
Normal

Velocity Dependent: Mean = 0.01 SD = .0017

Normal

212
 Car Distribution Type Distribution Details

Weight
Normal Mean = 101% SD = 0.03%
Loaded

Weight
Normal Mean = 100% SD = 0.03%
Empty

1966 - 3575 (3%)

1966 - 3575 (20%)

Brake Force
Empty Load Equipped: Discrete Uniform 2085 - 3615 (23%)
100%
2781 - 3615 (2%)

2781 - 3893 (52%)

Unit Aluminum ABD (27%)

Hoppers
Brake Valve Discrete Uniform ABDW (18%)

ABDX (55%)

Piston Travel Normal Mean = 7.5" SD = 0.87"

Mean = 0.07 SD = 0
Aerodynamic:
Nominal

Mean = 18 SD = 3
Bearing Resistance:
Davis Equation Normal
Variables
Mean = 0.6 SD = 0.1
Constant:
Normal

Mean = 0.01 SD = .0017

Velocity Dependent:
Normal

213
 Car Distribution Type Distribution Details
92.1% - 94.8% (1%)
94.8% - 100% (19%)

Weight 100% - 102.6% (22%)

Discrete Uniform
Loaded 102.6% - 105.2% (40%)
105.2% - 107.9% (17%)
107.9% - 113.1% (1%)
92.1% - 94.0% (1%)
94.0% - 95.9% (4%)

Weight 95.9% - 101.7% (73%)

Discrete Uniform
Empty 101.7% - 103.6% (12%)
103.6% - 109.3% (8%)
109.3% - 122.8% (2%)
1808 - 3288 (3%)
1808 - 3288 (3%)
Brake Force
Empty Load Equipped: Discrete Uniform 1918 - 3324 (6%)
23%
2557 - 3324 (1%)
Unit Tank Cars
2557 - 3580 (87%)
1808 - 2424 (50%)
Brake Force
Not Empty Load Discrete Uniform 1808 - 2424 (27%)
Equipped: 77%
1918 - 2388 (23%)
ABD (27%)
Brake Valve Discrete Uniform ABDW (18%)
ABDX (55%)

Piston Travel Normal Mean = 7.5" SD = 0.87"

Aerodynamic:
Mean = 0.07 SD = 0
Nominal

Bearing Resistance: Mean = 18 SD = 3

Davis Equation Normal
Variables
Constant: Mean = 0.6 SD = 0.1
Normal

Velocity Dependent: Mean = 0.01 SD = .0017

Normal

214
 Car Distribution Type Distribution Details
49% - 85% (6%)
85% - 90% (20%)

Weight 90% - 105% (41%)

Discrete Uniform
Loaded 105% - 110% (28%)
110% - 115% (4%)
115% - 130% (1%)
49% - 85% (6%)
85% - 90% (20%)

Weight 90% - 105% (41%)

Discrete Uniform
Empty 105% - 110% (28%)
110% - 115% (4%)
115% - 130% (1%)
1513 - 2750 (69%)
Brake Force 1513 - 2750 (2%)
Unit Multilevel Not Empty Load Discrete Uniform
Equipped: 100% 1604 - 2781 (19%)

2139 - 2994 (10%)

ABD (59%)
Brake Valve Discrete Uniform ABDW (14%)
ABDX (27%)

Piston Travel Normal Mean = 7.5" SD = 0.87"

Aerodynamic:
Mean = 0.07 SD = 0
Nominal

Bearing Resistance: Mean = 18 SD = 3

Davis Equation Normal
Variables
Constant: Mean = 0.6 SD = 0.1
Normal

Velocity Dependent: Mean = 0.01 SD = .0017

Normal

215
 Car Distribution Type Distribution Details
96.2% - 98.7% (22%)
98.7% - 101.3% (1%)
101.3% - 102.6% (8%)
Weight
Discrete Uniform 102.6% - 103.8% (16%)
Loaded
103.8% - 105.1% (33%)
105.1% - 106.4% (17%)
106.4% - 107.7% (3%)
93.08% - 95.04% (2%)
95.04% - 97% (16%)
97% - 98.96% (39%)
Weight
Discrete Uniform 98.96% - 100.92% (18%)
Empty
100.92% - 106.8% (18%)
106.8% - 115.61% (6%)
115.61% - 122.47% (1%)
1966 - 3575 (4%)
1966 - 3575 (18%)
Brake Force
Empty Load Equipped: Discrete Uniform 2085 - 3615 (12%)
Unit Covered
54%
Hopper 2781 - 3615 (1%)
2781 - 3893 (65%)
1966 - 2392 (14%)
Brake Force
Not Empty Load Discrete Uniform 1966 - 2392 (44%)
Equipped: 46%
2085 - 2357 (42%)
ABD (36%)
Brake Valve Discrete Uniform ABDW (19%)
ABDX (45%)

Piston Travel Normal Mean = 7.5" SD = 0.87"

Aerodynamic:
Mean = 0.07 SD = 0
Nominal

Bearing Resistance: Mean = 18 SD = 3

Normal
Davis Equation Variables
Constant: Mean = 0.6 SD = 0.1
Normal

Velocity Dependent: Mean = 0.01 SD = .0017

Normal

216
 Car Distribution Type Distribution Details
53.3% - 65.7% (3%)
65.7% - 75.1% (12%)
75.1% - 90.7% (23%)
Weight
Discrete Uniform 90.7% - 96.9% (19%)
Loaded
96.9% - 103.1% (31%)
103.1% - 106.2% (7%)
106.2% - 115.6% (5%)
89% - 95% (7%)
95% - 97% (9%)
Weight
Discrete Uniform 97% - 101% (26%)
Empty
101% - 107% (56%)
107% - 109% (2%)
1966 - 3575 (18%)
Brake Force
Empty Load Equipped: Discrete Uniform 2085 - 3615 (6%)
4%
2781 - 3893 (76%)
1966 - 3575 (75%)
Unit Refrigerated
Boxcar 1966 - 3575 (2%)
Brake Force
Not Empty Load Discrete Uniform 2085 - 3615 (8%)
Equipped: 96%
2781 - 3615 (2%)
2781 - 3221 (13%)
ABD (69%)
Brake Valve Discrete Uniform ABDW (8%)
ABDX (23%)

Piston Travel Normal Mean = 7.5" SD = 0.87"

Aerodynamic:
Mean = 0.07 SD = 0
Nominal

Bearing Resistance: Mean = 18 SD = 3

Davis Equation Normal
Variables
Constant: Mean = 0.6 SD = 0.1
Normal

Velocity Dependent: Mean = 0.01 SD = .0017

Normal

217
 Car Distribution Type Distribution Details
53.3% - 65.7% (3%)
65.7% - 75.1% (12%)
75.1% - 90.7% (23%)
Weight
Discrete Uniform 90.7% - 96.9% (19%)
Loaded
96.9% - 103.1% (31%)
103.1% - 106.2% (7%)
106.2% - 115.6% (5%)

Weight
Normal Mean = 64360 SD = 2679
Empty

1966 - 3575 (29%)

1966 - 3575 (25%)
Brake Force
Empty Load Discrete Uniform 2085 - 3615 (1%)
Equipped: 36%
2781 - 3615 (1%)
2781 - 3893 (44%)
1966 - 2414 (88%)
Unit Steel Hopper Brake Force
Not Empty Load Discrete Uniform 1966 - 2414 (11%)
Equipped: 64%
2085 - 2378 (1%)
ABD (62%)
Brake Valve Discrete Uniform ABDW (20%)
ABDX (18%)

Piston Travel Normal Mean = 7.5" SD = 0.87"

Aerodynamic:
Mean = 0.07 SD = 0
Nominal

Bearing Resistance: Mean = 18 SD = 3

Davis Equation Normal
Variables
Constant: Mean = 0.6 SD = 0.1
Normal

Velocity Dependent: Mean = 0.01 SD = .0017

Normal

218
 Car Distribution Type Distribution Details
60% - 90% (21%)
90% - 95% (11%)
95% - 100% (18%)
Weight
Discrete Uniform 100% - 105% (18%)
Loaded
105% - 110% (5%)
110% - 145% (12%)
145% - 165% (15%)
76.99% - 81.27% (5%)
81.27% - 85.54% (17%)
Weight 85.54% - 89.82% (50%)
Discrete Uniform
Empty 89.82% - 94.1% (14%)
94.1% - 136.87% (4%)
171.09% - 239.52% (10%)
1671 - 3038 (8%)

Brake Force 2278 - 3038 (22%)

Empty Load Discrete Uniform 2363 - 3072 (26%)
Equipped: 90% 2363 - 3072 (8%)
Intermodal 3-
Pack 2363 - 3308 (36%)
1671 - 2992 (43%)
Brake Force 2278 - 2992 (35%)
Not Empty Load Discrete Uniform
Equipped: 10% 2363 - 2948 (16%)
2363 - 2948 (6%)
ABD (12%)
Brake Valve Discrete Uniform ABDW (12%)
ABDXL (76%)

Piston Travel Normal Mean = 7.5" SD = 0.87"

Aerodynamic:
Mean = 0.07 SD = 0
Nominal

Bearing Resistance: Mean = 18 SD = 3

Davis Equation Normal
Variables
Constant: Mean = 0.6 SD = 0.1
Normal

Velocity Dependent: Mean = 0.01 SD = .0017

Normal

219
 Car Distribution Type Distribution Details

100% - 105% (15%)

Weight
Discrete Uniform 105% - 110% (57%)
Loaded
110% - 120% (28%)

80.92% - 85.18% (5%)

85.18% - 89.44% (73%)

Weight
Discrete Uniform 89.44% - 93.7% (9%)
Empty
93.7% - 97.96% (5%)

195.91% - 281.09% (8%)

1836 - 3338 (8%)

2504 - 3338 (22%)

Brake Force
Empty Load Discrete Uniform 2596 - 3375 (26%)
Equipped: 90%
2596 - 3375 (8%)

2596 - 3635 (36%)

Intermodal 5- Brake Force

Pack Not Empty Load Flat 1836 - 2652
Equipped: 10%

ABD (12%)

Brake Valve Discrete Uniform ABDW (12%)

ABDXL (76%)

Piston Travel Normal Mean = 7.5" SD = 0.87"

Aerodynamic:
Mean = 0.07 SD = 0
Nominal

Bearing Resistance: Mean = 18 SD = 3

Davis Equation Normal
Variables
Constant: Mean = 0.6 SD = 0.1
Normal

Velocity Dependent: Mean = 0.01 SD = .0017

Normal

220
 Car Distribution Type Distribution Details
60% - 90% (21%)
90% - 95% (11%)

Weight 95% - 100% (18%)

Discrete Uniform
Loaded 100% - 105% (18%)
105% - 110% (5%)
110% - 145% (12%)
72.98% - 76.82% (10%)

Weight 76.82% - 80.66% (33%)

Discrete Uniform
Empty 80.66% - 103.71% (43%)
153.64% - 230.46% (14%)
1836 - 3338 (8%)
2504 - 3338 (22%)
Brake Force
Empty Load Equipped: Discrete Uniform 2596 - 3375 (26%)
90%
2596 - 3375 (8%)
2596 - 3635 (36%)
Intermodal
Single Platform
Brake Force
Not Empty Load Flat 1836 - 2652
Equipped: 10%

ABD (12%)
Brake Valve Discrete Uniform ABDW (12%)
ABDXL (76%)

Piston Travel Normal Mean = 7.5" SD = 0.87"

Aerodynamic:
Mean = 0.07 SD = 0
Nominal

Bearing Resistance: Mean = 18 SD = 3

Davis Equation Normal
Variables
Constant: Mean = 0.6 SD = 0.1
Normal

Velocity Dependent: Mean = 0.01 SD = .0017

Normal

221
Below is the table of varied train parameters:
Distribution Type Distribution Details
Ambient Pressure Half Normal Mean = 14.7 psi SD = 1.5 psi
Ambient Pressure Normal Mean = 54.1°F SD = 10.8°F
Brake Pipe Pressure
Normal Mean = 2.5 psi/min SD = 0.83 psi/min
Leakage

Coefficient of Friction
between Brake Shoe Normal Mean = 0% SD = 6.67%
and Wheel
DP Comms Link
Train Half Normal Mean = 2 sec SD = 2 sec
Outage
Parameters
Reported HOT Pressure Flat (+/-) 0.5 psi

Reported EOT Pressure Flat (+/-) 3 psi

Location Error Normal Mean = 0' SD = 3.6'

Percent Operable
Normal Mean = 99% SD = 0.33%
Brakes
Speed Error Normal Mean = 0 mph SD = 0.16 mph
Track Grade Flat (+/-) 0.05°

222
Appendix E.
Test Implementation Plans (TIP) and Test Logs for Field Tests

Task Order 242: Development of a PTC Enforcement

Algorithm for Freight Trains
Enforcement with Brake System States Other Than
Fully Charged
Field Test Implementation Plan
November 2009

Approval:________________________________________
Terry Tse, COTM Date

Presented By:
Transportation Technology Center, Inc.
A Subsidiary of the Association of American Railroads
55500 D.O.T. Road
P.O. Box 11130
Pueblo, Colorado, USA 81001

223
1.0 Project Title
Development of an Implementation-Ready Enforcement Braking Algorithm for Freight Trains

2.0 Introduction
Positive Train Control (PTC) is an emerging train control technology intended to enhance safety
and possibly improve train performance and plant capacity. The underlying concept of the
technology is that movement authorities are transmitted digitally to the controlling locomotive of
each train. The locomotive tracks the train’s location with respect to its authority and speed
limits and the train’s stopping ability based on known train parameters and brake pipe pressure
and automatically applies brakes to prevent the train from violating any limit in the event of
human failure. Enforcement braking is an event of last recourse when the locomotive engineer
has failed to take adequate action. A full service brake application is used for enforcement in
today’s PTC systems.
The current enforcement algorithm takes the state of the train’s brake system into account and
uses that information to predict the stopping distance. The stopping point after enforcement
should not change for the same train with the brakes either fully charged or at states other than
fully charged unless there is some additional conservatism built in. Enforcement should also
happen sooner in trains with other than fully charged brakes if the current enforcement algorithm
performs correctly.
The objective of this test is to evaluate the existing enforcement algorithm at brake states other
than fully charged and compare the results with brakes fully charged to determine how the
current algorithm performs. The results will be used to determine what changes, if any, are
needed to improve the algorithm with brakes states other than fully charged.

2.1 Key Personnel

Customer Contact, Ruben Pena, Assistant Director, Business Acquisition / DC
Telephone: 719-584-0543
Fax: 719-584-0770
Email: [email protected]
Program Manager, Dingqing Li, Principal Investigator II / FRA Program Manager
Telephone: 719-584-0740
Fax: 719-584-0791
Email: [email protected]
Project Manager, Joe Brosseau, Senior Engineer I
Telephone: 719-584-7128
Fax: 719-584-0771
Email: [email protected]
224
Test Engineer, Shad Pate, Engineer
Telephone: 719-584-7116
Fax: 719-584-0771
Email: [email protected]

2.2 Responsibilities
The project manager for this project is Joe Brosseau. He is responsible for ensuring that the test
is completed on time, within budget, and will ensure all deliverables meet or exceed FRA
requirements. The test engineer for this test is Shad Pate. He will be responsible for ensuring
that the test is executed according to the test plan, that all data is collected properly, and that the
test is completed safely.

2.3 Documentation
The results of this test will be documented within the final report for this project.

3.0 Preparation
In preparation for field testing of the enforcement algorithm, the following tasks will be
completed:
• Test locomotive setup/checkout. This includes the installation of a locomotive control
unit (LCU) capable of determining locomotive location and speed, head end brake pipe
pressure, tail end brake pipe pressure from an end of train (EOT) device and throttle
notch. The LCU will be capable of interacting with the enforcement algorithm operating
on a separate test machine.
• Enforcement algorithm software setup/checkout. This includes software modifications
necessary for this test and testing of the software in a simulation environment to
determine that the algorithm will operate as expected.
• Test consist setup. This includes determining the specific consist to be used, making
measurements on the brake system components, scaling the test consist and installing the
test instrumentation.

4.0 Implementation

4.1 Constraints
None.

4.2 Operation Sequence

4.2.1 Track Testing

The field test configuration is shown in Figure 1. The lead locomotive of the test consist will
have a standard laptop PC containing the base case enforcement algorithm (EA). The lead
locomotive will also be instrumented with a Locomotive Control Unit (LCU) that communicates

225
train speed, position, head and tail end brake pipe pressure, and locomotive notch to the EA PC.
Head end brake pipe pressure is measured by a pressure transducer and the tail end brake pipe
pressure is measured using a two-way End-of-Train (EOT) device. The LCU and the EA PC
will be used to record speed, location, locomotive notch, and brake pipe pressure data throughout
each test for use in determining when the brakes were applied, where the train stopped, etc.
A track file loaded on the enforcement algorithm PC will contain surveyed grade and curve data
for the Railroad Test Track (RTT), and will be accessed by the enforcement algorithm as needed
for stopping distance prediction.
The enforcement algorithm PC will interface with the LCU over an Ethernet connection to
enforce a penalty brake application when necessary.

Tail End BPP

GPS Antennae

EOT
Device

Dynamic
Notch Brake

Speed/Location Misc. Hardware

Discrete Bits
Head End BPP Enforcement
Penalty Brake Algorithm PC
Application Tail End BPP

Emergency Head/Tail End BPP

Brake Application Notch/Speed
Location
Dynamic Brake

Heath Status
Penalty Brake Emergency Brake
Application Application

Figure 1 – Test Configuration

The field testing will test the base case enforcement algorithm at brake states other than fully
charged over a number of test scenarios, which will cover a range of operating conditions. The
test scenarios are determined by varying the following independent test variables:
• Train length
• Train speed
• Track grade
• State of brake system
For the state of the brake system, there are four possibilities:
• Charged – the brake system is fully charged to 90 psi.

226
 • Applied – a brake application has been made, but not sufficient to bring the train to a stop
before reaching the target.
• Releasing – A brake application has been made followed by a brake release, but the
system has not recharged completely.
• Applied to stop – a brake application has been made sufficient for stopping the train
before reaching the target. This case is to ensure that the algorithm will not enforce the
train if it is not necessary to.
The specific test scenarios are listed in table 1, below.
Table 1 – Test Scenarios
Test ID Train length Train speed Track grade Brake system
state
1a 40 cars 30 mph Flat Charged
1b 40 cars 30 mph Flat Applied
1c 40 cars 30 mph Flat Releasing
1d 40 cars 30 mph Flat Applied to stop
2a 40 cars 50 mph Flat Charged
2b 40 cars 50 mph Flat Applied
2c 40 cars 50 mph Flat Releasing
2d 40 cars 50 mph Flat Applied to stop
3a 80 cars 30 mph Decline Charged
3b 80 cars 30 mph Decline Applied
3c 80 cars 30 mph Decline Releasing
3d 80 cars 30 mph Decline Applied to stop
4a 80 cars 10 mph Flat Charged
4b 80 cars 10 mph Flat Applied
4c 80 cars 10 mph Flat Releasing
4d 80 cars 10 mph Flat Applied to stop
5a 10 cars 30 mph Flat Charged
5b 10 cars 30 mph Flat Applied
5c 10 cars 30 mph Flat Releasing
5d 10 cars 30 mph Flat Applied to stop

For each test scenario, a target stopping location will be selected on the RTT that will provide the
proper track grade for the scenario. This location will be entered into the enforcement algorithm,
along with the generic consist information and other required inputs. An appropriate starting
location will be determined, and the train will be moved to this location to start each test run.

227
The train will be accelerated to the specified test speed and the brakes will be applied by the
locomotive engineer based on the detailed test plan for that scenario. The train will proceed
towards the target stopping location, with the enforcement algorithm monitoring the speed,
location, and brake pipe pressure of the train. When the enforcement algorithm determines that
an enforcement brake application is necessary, it will send a signal to the LCU, which will drop
power to the locomotives and apply a penalty brake application. The locomotive engineer will
bail off the locomotive brakes as soon as the penalty application has been made.
Once the train has stopped, the absolute stopping location will be recorded and the location
relative to the target will be measured and recorded before resetting the train for the next test run.

4.2.2 Validation Testing

N/A

4.2.3 Endurance Testing

N/A

4.2.4 Safety Margin Tests

N/A

4.3 Operation Locations

The stop tests will occur between Post 100 and R-24 on the RTT. However, in some cases, the
entire RTT loop will be utilized to get the train up to speed for the test zone.

4.4 Special Support

N/A

4.5 Instrumentation Types

See section 5.0.

4.6 Measurement Definitions

The following measurements will be taken during the field test for each test run:
• Stopping location. The location in footage relative to a specific point on the track will be
measured by the LCU and recorded by the enforcement algorithm software once the train
has come to a stop.
• Stopping location relative to the target. The difference in footage between the stopping
location and the target location will be calculated in post-processing.
• Stopping distance. The difference in footage between the point of penalty brake
application and stopping location will be calculated in post-processing.

4.7 Data Collection Schematics

None.

228
5.0 Instrumentation Identification

5.1 On-Board Instrumentation List

The on-board instrumentation includes:
• Locomotive control unit (LCU)
• Laptop computer containing enforcement algorithm software
• Locomotive brake pipe pressure transducer
• Locomotive head end unit (HEU)
• GPS antennas
• Penalty brake valve
• End of train (EOT) unit
• Unmanned data acquisition computer (UDAC)
• Rear end brake pipe pressure transducer
• Rear end brake cylinder pressure transducer

5.2 Wayside Instrumentation List

None.

5.3 Special Instrumentation List

None.

6.0 Photography and Video

6.1 Photography Requirements

None.

6.2 Video Requirements

None.

7.0 Transportation Technology Center, Inc. Requirements

7.1 Facility Requirements

None.

7.2 Track Requirements

The enforcement algorithm will be tested at various locations around the 13.5 mile Railroad Test
Track (RTT) at the Transportation Technology Center (TTC). On days when multiple test
consists will be used, other tracks may be needed for switching and storage of test cars.

229
7.3 Labor/Personnel Requirements
The following personnel will be required to setup, perform, and analyze the results from the tests
planned:
• Test engineer(s): The test engineer(s) will be responsible for organizing and managing
the test activities, including providing test plans, procedures, and data sheets to test
personnel, and ensuring test activities can be performed in a safe manner. It will also be
the responsibility of the test engineer(s) to oversee setup of the instrumentation, running
the enforcement algorithm software, and recording or ensuring necessary data is
recorded. Post test, the test engineer(s) will analyze the data collected for use in other
tests and future developments of the enforcement algorithm.
• Test controller: The test controller will be in charge of the actual tests and all movements
of the test consist. This includes ensuring all safety rules, test plans, and other
instructions are followed by all test personnel. The test controller will be the point of
communication between the test engineers and the locomotive engineer and any other test
personnel. The test controller will coordinate all train moves with the proper personnel in
the Operations Control Center (OCC), and ensure safe test conditions at all times.
Finally, the test controller will keep a detailed log of the test activities.
• Locomotive engineer: The locomotive engineer will execute train moves as necessary for
test setup, switching, and test functions.
• Instrumentation engineer(s): The instrumentation engineer(s) will work closely with the
test engineer(s) to set up all test instrumentation, and ensure the proper operation of the
instrumentation and data collection system during testing.

7.4 Equipment Requirements

The following equipment will be required for the field tests:
• Four locomotives, including two GP40-2 and two SD60MAC locomotives
• 80 test cars from the Facility for Accelerated Service Testing (FAST) train

7.5 Material Requirements

None.

7.6 Special Requirements

None.

8.0 Restoration and/or Dismantling

8.1 Facility Restoration

None.

230
8.2 Track Restoration
Tribometer readings will be taken on the RTT following the field tests to ensure that lubrication
from the FAST cars does not affect the friction characteristics of the track. If any negative
effects are measured from the test, they will be remedied.

8.3 Equipment Disposition

None.

8.4 Material Disposition

None.

8.5 Special Equipment Disposition

None.

9.0 Data Requirements

9.1 Data Types

The following data will be collected during this field test:
• Locomotive location
• Locomotive speed
• Locomotive brake pipe pressure
• Tail end brake pipe pressure through an end of train (EOT) device
• Locomotive notch
• Tail end brake pipe pressure through a pressure transducer
• Tail end (last car) brake cylinder pressure

9.2 Recording Techniques

Locomotive location, speed, brake pipe pressure, EOT brake pipe pressure and locomotive notch
will be collected once per second by the locomotive control unit (LCU). Tail end brake pipe
pressure and brake cylinder pressure will be collected once per second using an unmanned data
acquisition computer (UDAC).

9.3 Data Analysis

The data collected will be used to evaluate the performance of the enforcement algorithm. For
all tests where enforcement occurs, the stopping location will be compared to the same test with
the brake system fully charged. The objective is for the train to stop at approximately the same
location, regardless of brake state.

231
The actual brake pipe and brake cylinder data, stop distance and stop time will also be compared
to the prediction data from the enforcement algorithm to determine the accuracy of the prediction
and identify any flaws in the algorithm logic that need to be investigated.

9.4 Reports
Documentation of the field test will be included in a final report for the project.

10.0 Safety
TTCI has a very successful safety record. Strict operating and safety rules will be followed
during the work described in this proposal.
A pre-test meeting will be held before any physical work is started. Safety and quality issues
will be addressed at this meeting.

11.0 Work Schedule

The field testing will occur during the week of November 23, 2009.

12.0 Quality Assurance

TTCI is committed to providing products and/or services that meet and/or exceed the customers’
specified contractual and project requirements. TTCI recognizes that in order to provide and
maintain a consistently high quality in the work it undertakes, an effective Quality Management
System is necessary so as to ensure that proper communication, work control and accountable
records are generated for all work undertaken.
It is the policy, therefore, of TTCI to control and conduct its business of consultancy and test
services in the railway transportation arena by means of a formalized system of modern quality
management that conforms to the requirements of ISO 9001–2000. Through the QMS, TTCI is
able to ensure that our products and services meet or exceed our customers’ expectations.
In order to ensure our entire organization supports the quality process, TTCI sponsors an
employee led Quality Resource Team (QRT). The mission of the QRT is to “To promote
customer satisfaction by providing effective training, education, and communication tools for
Team TTCI.” The QRT works directly with TTCI’s marketing team to identify customer
satisfaction issues and help resolve them. The QRT also provides period refresher training to
TTCI employees in science of Continuous Quality Improvement, Customer Satisfaction, and the
implementation of problem solving tools.

13.0 Support Specialties

N/A

232
Task Order 242: Development of a PTC Enforcement Algorithm
for Freight Trains

Enforcement with Distributed Power

Field Test Implementation Plan

December 2009

Approval:________________________________________
Terry Tse, COTM Date

Presented By:
Transportation Technology Center, Inc.
A Subsidiary of the Association of American Railroads
55500 D.O.T. Road
P.O. Box 11130
Pueblo, Colorado, USA 81001

233
1.0 Project Title
Development of an Implementation-Ready Enforcement Braking Algorithm for Freight Trains
2.0 Introduction
Positive Train Control (PTC) is an emerging train control technology intended to enhance safety
and possibly improve train performance and plant capacity. The underlying concept of the
technology is that movement authorities are transmitted digitally to the controlling locomotive of
each train. The locomotive tracks the train’s location with respect to its authority and speed
limits and the train’s stopping ability based on known train parameters and brake pipe pressure
and automatically applies brakes to prevent the train from violating any limit in the event of
human failure. Enforcement braking is an event of last recourse when the locomotive engineer
has failed to take adequate action. A full service brake application is used for enforcement in
today’s PTC systems.
The base case enforcement algorithm determines brake propagation time based on the length of
the train. The assumption is that the brake signal is propagated from the head end of the train
only. A new development of the algorithm uses the location of remote locomotives in addition
to the length of the train to estimate a more accurate propagation time for trains with distributed
power.
To further improve the accuracy of the propagation time used by the enforcement algorithm,
modifications to the propagation time adaptive routine allow for a propagation time measurement
to be used to more accurately estimate the propagation time.
The objective of this test is to evaluate the enforcement algorithm with the modifications made
for trains with distributed power against the base case algorithm.
2.1 Key Personnel
Customer Contact, Ruben Pena, Assistant Director, Business Acquisition / DC
Telephone: 719-584-0543
Fax: 719-584-0770
Email: [email protected]
Program Manager, Dingqing Li, Principal Investigator II / FRA Program Manager
Telephone: 719-584-0740
Fax: 719-584-0791
Email: [email protected]
Project Manager, Joe Brosseau, Senior Engineer I
Telephone: 719-584-7128
Fax: 719-584-0771
Email: [email protected]
234
Test Engineer, W. David Mauger, Engineer
Telephone: 719-584-0758
Fax: 719-584-0758
Email: [email protected]
2.2 Responsibilities
The project manager for this project is Joe Brosseau. He is responsible for ensuring that the test
is completed on time, within budget, and will ensure all deliverables meet or exceed FRA
requirements. The test engineer for this test is David Mauger. He will be responsible for
ensuring that the test is executed according to the test plan, that all data is collected properly, and
that the test is completed safely.
2.3 Documentation
The results of this test will be documented within the final report for this project.
3.0 Preparation
In preparation for field testing of the enforcement algorithm, the following tasks will be
completed:
• Test locomotive setup/checkout. This includes the installation of a locomotive control
unit (LCU) capable of determining locomotive location and speed, head end brake pipe
pressure, and throttle notch. The LCU will be capable of interacting with the
enforcement algorithm operating on a separate test machine.
• Enforcement algorithm software setup/checkout. This includes software modifications
necessary for this test and testing of the software in a simulation environment to
determine that the algorithm will operate as expected.
• Test consist setup. This includes determining the specific consist to be used, making
measurements on the brake system components, scaling the test consist and installing the
test instrumentation.
4.0 Implementation
4.1 Constraints
None.
4.2 Operation Sequence
4.2.1 Track Testing
The field test configuration is shown in Figure 1. The lead locomotive of the test consist will
have a standard laptop PC containing the enforcement algorithm (EA). The lead locomotive will
also be instrumented with a Locomotive Control Unit (LCU) that communicates train speed,
position, head end brake pipe pressure, and locomotive notch to the EA PC. The LCU and the
235
EA PC will be used to record speed, location, locomotive notch, and brake pipe pressure data
throughout each test for use in determining when the brakes were applied, where the train
stopped, etc.
A track file loaded on the enforcement algorithm PC will contain surveyed grade and curve data
for the Railroad Test Track (RTT), and will be accessed by the enforcement algorithm as needed
for stopping distance prediction.
The enforcement algorithm PC will interface with the LCU over an Ethernet connection to
enforce a penalty brake application when necessary. The penalty application will be transmitted
to the remote (distributed) locomotive, resulting in application of the penalty brake by both the
lead and remote (distributed) locomotives.

Supplier EA (running on virtual machine) Processing flow – During Simulation Test

1) Receive init message on admin port (consist, track, target, etc)
2) Send EA status message to TCL using TCP/IP data port
3) TCL replies with data message (BPP, location, etc)
TCP/IPEnforcement
4) Repeat steps 2-3 until train
Figure speed
B25using < 0.5mphProcess Flow
- Field
GPS Antennae
connection dataTest
port
5) Send EA-Init termination message on TCP/IP admin port
6) Wait TCP/IP Algorithm
for initconnection
message
EOT
Test
using
(step Controller
1)admin
Device TMport
EA-Init (running on test machine)
Supplier EA – (running onFigure B25 –TOES
virtual machine) and Logger
Simulation Test Process Flow Setup
1) Readsteps:
consist, target, etc.
Processing flow –init
1) Receive During Field
message onTest
admin port (consist, track, target, etc) 1)
2) SendEA
Start on virtual
message machine
to EA
2) Send EA status message to OBC using TCP/IP data port
Locomotive 2) Start
OBC Application EA-Init on test
3) Receive EA termination machine
message
Speed/Location
Setup steps:
3) OBC replies with data message (BPP, location, 5) etc)
Listen for EA on data port
4)(1-many)
Terminate
Notch
TCL - Start
1) Receive
Start EAsimulation
on virtual machine
4) Repeat steps 2-3 until train stops after enforcement
6)
Head End BPP EA status message
EA-Init
1) admin
2) EA-Init
Start port
TCL on
5) Sends EA-Init termination message on TCP/IP 7)
1) Send
Read train datatest
consist,
machine
message
target, etc.
6) Waits for init message (step 1) 2) Listen
Tail Endfor
BPPEA on data port
2)
3) Send
Receiveinit message
EA status to EA
message
TCP/IP3)connectionEA using admin port
4) Receive termination message
Terminate usingDistribution of Stopping Locations
TCP/IP Send train data message
4) connection data port

Figure 1 – Test Configuration

The field testing will test the both the base case and current enforcement algorithm with
distributed power in the consist over a number of test scenarios, which will cover a range of
operating conditions. The test scenarios are determined by varying the following independent
test variables:
• Train length
• Train speed
• Track grade
The specific test scenarios are listed in table 1, below.

236
 Table 1 – Test Scenarios
Test ID Train Length Train Speed Track Grade
1 80 cars 30 mph Flat
2 80 cars 50 mph Flat
3 80 cars 10 mph Flat
4 80 cars 30 mph Decline
5 80 cars 30 mph Incline
6 60 cars 30 mph Flat
7 60 cars 30 mph Decline

Each test scenario will be used to evaluate the base case algorithm, and the developmental
algorithm both with and without the adaptive function.
For each test scenario, a target stopping location will be selected on the RTT that will provide the
proper track grade for the scenario. This location will be entered into the enforcement algorithm,
along with the generic consist information and other required inputs. An appropriate starting
location will be determined, and the train will be moved to this location to start each test run.
The train will be accelerated to the specified test speed and the train will proceed towards the
target stopping location, with the enforcement algorithm monitoring the speed, location, and
brake pipe pressure of the train. When the enforcement algorithm determines that an
enforcement brake application is necessary, it will send a signal to the LCU, which will drop
power to the locomotives and apply a penalty brake application. The penalty application will be
transmitted to the remote (distributed) locomotive to apply the penalty brake from both locations.
The locomotive engineer will bail off the locomotive brakes as soon as the penalty application
has been made.
Once the train has stopped, the absolute stopping location will be recorded and the location
relative to the target will be measured and recorded before resetting the train for the next test run.
4.2.2 Validation Testing
N/A
4.2.3 Endurance Testing
N/A
4.2.4 Safety Margin Tests
N/A
4.3 Operation Locations
The stop tests will occur at various locations around the RTT.
4.4 Special Support
N/A
237
 4.5 Instrumentation Types
See section 5.0.
4.6 Measurement Definitions
The following measurements will be taken during the field test for each test run:
• Stopping location. The location in footage relative to a specific point on the track will be
measured by the LCU and recorded by the enforcement algorithm software once the train
has come to a stop.
• Stopping location relative to the target. The difference in footage between the stopping
location and the target location will be calculated in post-processing.
• Stopping distance. The difference in footage between the point of penalty brake
application and stopping location will be calculated in post-processing.
4.7 Data Collection Schematics
None.
5.0 Instrumentation Identification
5.1 On-Board Instrumentation List
The on-board instrumentation includes:
• Locomotive control unit (LCU)
• Laptop computer containing enforcement algorithm software
• Locomotive brake pipe pressure transducer
• GPS antennas
• Penalty brake valve
• Mid-Train test car with brake pipe pressure transducer
• Mid-Train test car with brake cylinder pressure transducer
• Unmanned data acquisition computer (UDAC)
5.2 Wayside Instrumentation List
None.
5.3 Special Instrumentation List
None.
6.0 Photography and Video
6.1 Photography Requirements
238
None.
6.2 Video Requirements
None.
7.0 Transportation Technology Center, Inc. Requirements
7.1 Facility Requirements
None.
7.2 Track Requirements
The enforcement algorithm will be tested at various locations around the 13.5 mile Railroad Test
Track (RTT) at the Transportation Technology Center (TTC). Other tracks may be needed for
switching and storage of test cars.
7.3 Labor/Personnel Requirements
The following personnel will be required to setup, perform, and analyze the results from the tests
planned:
• Test engineer(s): The test engineer(s) will be responsible for organizing and managing
the test activities, including providing test plans, procedures, and data sheets to test
personnel, and ensuring test activities can be performed in a safe manner. It will also be
the responsibility of the test engineer(s) to oversee setup of the instrumentation, running
the enforcement algorithm software, and recording or ensuring necessary data is
recorded. Post test, the test engineer(s) will analyze the data collected for use in other
tests and future developments of the enforcement algorithm.
• Test controller: The test controller will be in charge of the actual tests and all movements
of the test consist. This includes ensuring all safety rules, test plans, and other
instructions are followed by all test personnel. The test controller will be the point of
communication between the test engineers and the locomotive engineer and any other test
personnel. The test controller will coordinate all train moves with the proper personnel in
the Operations Control Center (OCC), and ensure safe test conditions at all times.
Finally, the test controller will keep a detailed log of the test activities.
• Locomotive engineer: The locomotive engineer will execute train moves as necessary for
test setup, switching, and test functions.
• Instrumentation engineer(s): The instrumentation engineer(s) will work closely with the
test engineer(s) to set up all test instrumentation, and ensure the proper operation of the
instrumentation and data collection system during testing.
7.4 Equipment Requirements
The following equipment will be required for the field tests:
• Four locomotives, including two SD70MAC locomotives equipped and capable of
operating with distributed power
• 80 loaded test cars from the Facility for Accelerated Service Testing (FAST) train
239
 7.5 Material Requirements
None.
7.6 Special Requirements
None.
8.0 Restoration and/or Dismantling
8.1 Facility Restoration
None.
8.2 Track Restoration
None.
8.3 Equipment Disposition
None.
8.4 Material Disposition
None.
8.5 Special Equipment Disposition
None.
9.0 Data Requirements
9.1 Data Types
The following data will be collected during this field test:
• Locomotive location
• Locomotive speed
• Locomotive brake pipe pressure
• Locomotive notch
• Mid-Train brake pipe pressure
• Mid-Train (test car) brake cylinder pressure
9.2 Recording Techniques
Locomotive location, speed, brake pipe pressure and locomotive notch will be collected once per
second by the locomotive control unit (LCU). Mid-train brake pipe pressure and brake cylinder
pressure will be collected at 256 Hz using an unmanned data acquisition computer (UDAC).
9.3 Data Analysis

240
The data collected will be used to evaluate the performance of the enforcement algorithm. For
each test, the stopping location with the current algorithm will be compared to the same test with
the base case enforcement algorithm. The objective is to determine the improvement in stopping
distance prediction for trains with distributed power. The results will also be compared against
the safety and performance objectives for each test scenario.
The actual brake pipe and brake cylinder data, stop distance and stop time will also be compared
to the prediction data from the enforcement algorithm to determine the accuracy of the prediction
and identify any flaws in the algorithm logic that need to be investigated.
9.4 Reports
Documentation of the field test will be included in a final report for the project.
10.0 Safety
TTCI has a very successful safety record. Strict operating and safety rules will be followed
during the work described in this proposal.
A pre-test meeting will be held before any physical work is started. Safety and quality issues
will be addressed at this meeting.
11.0 Work Schedule
The field testing will occur during the week of December 21, 2009.
12.0 Quality Assurance
TTCI is committed to providing products and/or services that meet and/or exceed the customers’
specified contractual and project requirements. TTCI recognizes that in order to provide and
maintain a consistently high quality in the work it undertakes, an effective Quality Management
System is necessary so as to ensure that proper communication, work control and accountable
records are generated for all work undertaken.
It is the policy, therefore, of TTCI to control and conduct its business of consultancy and test
services in the railway transportation arena by means of a formalized system of modern quality
management that conforms to the requirements of ISO 9001–2000. Through the QMS, TTCI is
able to ensure that our products and services meet or exceed our customers’ expectations.
In order to ensure our entire organization supports the quality process, TTCI sponsors an
employee led Quality Resource Team (QRT). The mission of the QRT is to “To promote
customer satisfaction by providing effective training, education, and communication tools for
Team TTCI.” The QRT works directly with TTCI’s marketing team to identify customer
satisfaction issues and help resolve them. The QRT also provides period refresher training to
TTCI employees in science of Continuous Quality Improvement, Customer Satisfaction, and the
implementation of problem solving tools.
13.0 Support Specialties
N/A

241
 Task Order 242: Development of a PTC Enforcement
Algorithm for Freight Trains

Enforcement with Emergency Brake Back-Up

Field Test Implementation Plan

July 2010

Approval:________________________________________
Terry Tse, COTM Date

Presented By:
Transportation Technology Center, Inc.
A Subsidiary of the Association of American Railroads
55500 D.O.T. Road
P.O. Box 11130
Pueblo, Colorado, USA 81001

242
1.0 Project Title
Development of an Implementation-Ready Enforcement Braking Algorithm for Freight Trains
2.0 Introduction
Positive Train Control (PTC) is an emerging train control technology intended to enhance safety
and possibly improve train performance and plant capacity. The underlying concept of the
technology is that movement authorities are transmitted digitally to the controlling locomotive of
each train. The locomotive tracks the train’s location with respect to its authority and speed
limits and the train’s stopping ability based on known train parameters and automatically applies
brakes to prevent the train from violating any limit in the event of human failure. Enforcement
braking is an event of last recourse when the locomotive engineer has failed to take adequate
action. A full service brake application is used for enforcement in today’s PTC systems.
The base case enforcement algorithm predicts train braking distance based on a number of
assumed or calculated train and environmental parameters, such as brake propagation time, brake
ratio, ambient temperature, etc. In order to achieve the safety objectives of the PTC system, a
target (safety) offset is added to the stopping distance prediction to ensure that a given train stops
short of the target, even if the assumptions in the prediction calculation are inaccurate and result
in a predicted stopping distance that is shorter than the actual stopping distance. However, by
adding this target (safety) offset, there is also the possibility of negatively affecting the
performance of the system in the case where the assumptions in the prediction calculation result
in a predicted stopping distance that is longer than the actual stopping distance.
A new development of the algorithm uses the input data from the onboard computer after an
enforcement has been initiated and monitors the actual stopping progress of the train. If it is
determined that the train is going to overrun the target the enforcement algorithm will then
initiate an emergency brake application to prevent a violation. This added capability allows for
less target (safety) offset to be used in the algorithm, thereby lessening the impact on system
performance without negatively affecting the safety objective.
The primary objective of this test is to evaluate the enforcement algorithm with the modifications
made for emergency brake back-up against the base case algorithm. Additional data collection
will also be performed during the test to support other enforcement algorithm developments.
2.1 Key Personnel
Customer Contact, Ruben Pena, Assistant Director, Business Acquisition / DC
Telephone: 719-584-0543
Fax: 719-584-0770
Email: [email protected]
Program Manager, Dingqing Li, Principal Investigator II / FRA Program Manager
Telephone: 719-584-0740
Fax: 719-584-0791

243
Email: [email protected]
Project Manager, Joe Brosseau, Senior Engineer II
Telephone: 719-584-7128
Fax: 719-584-0771
Email: [email protected]
Test Engineer, Shad Pate, Engineer
Telephone: 719-584-7116
Fax: 719-584-7116
Email: [email protected]
2.2 Responsibilities
The project manager for this project is Joe Brosseau. He is responsible for ensuring that the test
is completed on time, within budget, and will ensure all deliverables meet or exceed FRA
requirements. The test engineer for this test is Shad Pate. He will be responsible for ensuring
that the test is executed according to the test plan, that all data is collected properly, and that the
test is completed safely.
2.3 Documentation
The results of this test will be documented within the final report for this project.
3.0 Preparation
In preparation for field testing of the enforcement algorithm, the following tasks will be
completed:
• Test locomotive setup/checkout. This includes the installation of a locomotive control
unit (LCU) capable of determining locomotive location and speed, head end brake pipe
pressure, and throttle notch. The LCU will be capable of interacting with the
enforcement algorithm operating on a separate test machine.
• Enforcement algorithm software setup/checkout. This includes software modifications
necessary for this test and testing of the software in a simulation environment to
determine that the algorithm will operate as expected.
• Test consist setup. This includes determining the specific consist to be used, making
measurements on the brake system components, scaling the test consist and installing the
test instrumentation.
4.0 Implementation
4.1 Constraints
None.
244
 4.2 Operation Sequence
4.2.1 Track Testing
The field test configuration is shown in Figure 1. The lead locomotive of the test consist will
have a standard laptop PC containing the enforcement algorithm (EA). The lead locomotive will
also be instrumented with a Locomotive Control Unit (LCU) that communicates train speed,
position, head end brake pipe pressure, and locomotive notch to the EA PC. The LCU and the
EA PC will be used to record speed, location, locomotive notch, and brake pipe pressure data
throughout each test for use in determining when the brakes were applied, where the train
stopped, etc.
A track file loaded on the enforcement algorithm PC will contain surveyed grade and curve data
for the Railroad Test Track (RTT), and will be accessed by the enforcement algorithm as needed
for stopping distance prediction.
The enforcement algorithm PC will interface with the LCU over an Ethernet connection to
enforce a penalty brake application when necessary. The enforcement algorithm will then
continue to monitor the train’s stopping progress and enforce an emergency brake application
if/when necessary.

Penalty
Brake Speed/Location

Enforcement
Algorithm PC Headend
BPP
Algorithm PC
Head/Tail End BPP

Location
Heath Status
Application
Penalty Brake
Dynamic Brake
Notch/Speed

Application
Penalty Brake GPS Antennae
Location
Test Car Brake
Dynamic
Application
Penalty Brake Emergency
Application
Application Dynamic
Brake Application
Misc. Hardware Notch/Speed
Tail End BPP

Misc. Hardware Brake

Emergency Brake
EOT
Notch
Device
Head End BPP
Enforcement
Tail End BPP

GPS Antennae
Speed/Location
Discrete Bits
Dynamic Notch Discrete Bits
Brake Heath Status

Figure 1 – Test Configuration

The field testing will test both the base case and current enforcement algorithm with emergency
brake back-up over a number of test scenarios, which will cover a range of operating conditions.
The test scenarios are determined by varying the following independent test variables:
• Train length
• Train speed
245
 • Track grade
The specific test scenarios are listed in table 1, below.
Table 1 – Test Scenarios
Test ID Train length Train speed Track grade
1 40 cars 30 mph Decline
2 40 cars 30 mph Flat
3 40 cars 50 mph Decline
4 40 cars 30 mph Incline
5 100 cars 30 mph Decline
6 100 cars 30 mph Flat
7 10 cars 30 mph Decline
8 10 cars 50 mph Flat

For each of the above test scenarios, the emergency brake back-up algorithm will be evaluated
based on its ability to stop the train short of a target when the penalty is not sufficient, but also to
ensure that emergency applications are not unnecessarily initiated when the penalty is sufficient
for stopping the train short of the target.
For each test scenario, a target stopping location will be selected on the RTT that will provide the
proper track grade for the scenario. This location will be entered into the enforcement algorithm,
along with the generic consist information and other required inputs. The inputs to the
enforcement algorithm for the train will be modified in such a way that it will enforce the train to
stop approximately 200 feet short of the target or 200 feet beyond the target, as appropriate for
the test case. An appropriate starting location will be determined, and the train will be moved to
this location to start each test run.
The train will be accelerated to the specified test speed and the train will proceed towards the
target stopping location, with the enforcement algorithm monitoring the speed, location, and
brake pipe pressure of the train. When the enforcement algorithm determines that an
enforcement brake application is necessary, it will send a signal to the LCU, which will drop
power to the locomotives and apply a penalty brake application. The enforcement algorithm will
then monitor the stopping progress and determine if an emergency brake application in
necessary. The locomotive engineer will bail off the locomotive brakes as soon as the penalty or
emergency application has been made.
Once the train has stopped, the absolute stopping location will be recorded and the location
relative to the target will be measured and recorded before resetting the train for the next test run.
4.2.2 Validation Testing
N/A
4.2.3 Endurance Testing
N/A
246
 4.2.4 Safety Margin Tests
N/A
4.3 Operation Locations
The stop tests will occur at various locations around the RTT.
4.4 Special Support
N/A
4.5 Instrumentation Types
See section 5.0.
4.6 Measurement Definitions
The following measurements will be taken during the field test for each test run:
• Penalty enforcement location. The location in footage relative to a specific point on the
track will be measured by the LCU and recorded by the enforcement algorithm software
once the train has received a penalty application.
• Emergency enforcement location. The location in footage relative to a specific point on
the track will be measured by the LCU and recorded by the enforcement algorithm
software once the train has received an emergency application.
• Stopping location. The location in footage relative to a specific point on the track will be
measured by the LCU and recorded by the enforcement algorithm software once the train
has come to a stop.
• Stopping location relative to the target. The difference in footage between the stopping
location and the target location will be calculated in post-processing.
• Stopping distance. The difference in footage between the point of penalty brake
application and stopping location will be calculated in post-processing.
4.7 Data Collection Schematics
None.
5.0 Instrumentation Identification
5.1 On-Board Instrumentation List
The on-board instrumentation includes:
• Locomotive control unit (LCU)
• Laptop computer containing enforcement algorithm software
• Locomotive brake pipe pressure transducer

247
 • GPS antennas
• Penalty brake valve
• Emergency brake valve
• Three test cars with a brake pipe pressure transducer spaced throughout the train
• Three test cars with a brake cylinder pressure transducer spaced throughout the train
• Three Unmanned data acquisition computers (UDAC)
5.2 Wayside Instrumentation List
None.
5.3 Special Instrumentation List
None.
6.0 Photography and Video
6.1 Photography Requirements
None.
6.2 Video Requirements
None.
7.0 Transportation Technology Center, Inc. Requirements
7.1 Facility Requirements
None.
7.2 Track Requirements
The enforcement algorithm will be tested at various locations around the 13.5 mile Railroad Test
Track (RTT) at the Transportation Technology Center (TTC). Other tracks may be needed for
switching and storage of test cars.
7.3 Labor/Personnel Requirements
The following personnel will be required to setup, perform, and analyze the results from the tests
planned:
• Test engineer(s): The test engineer(s) will be responsible for organizing and managing
the test activities, including providing test plans, procedures, and data sheets to test
personnel, and ensuring test activities can be performed in a safe manner. It will also be
the responsibility of the test engineer(s) to oversee setup of the instrumentation, running
the enforcement algorithm software, and recording or ensuring necessary data is
recorded. Post test, the test engineer(s) will analyze the data collected for use in other
tests and future developments of the enforcement algorithm.

248
 • Test controller: The test controller will be in charge of the actual tests and all movements
of the test consist. This includes ensuring all safety rules, test plans, and other
instructions are followed by all test personnel. The test controller will be the point of
communication between the test engineers and the locomotive engineer and any other test
personnel. The test controller will coordinate all train moves with the proper personnel in
the Operations Control Center (OCC), and ensure safe test conditions at all times.
Finally, the test controller will keep a detailed log of the test activities.
• Locomotive engineer: The locomotive engineer will execute train moves as necessary for
test setup, switching, and test functions.
• Instrumentation engineer(s): The instrumentation engineer(s) will work closely with the
test engineer(s) to set up all test instrumentation, and ensure the proper operation of the
instrumentation and data collection system during testing.
7.4 Equipment Requirements
The following equipment will be required for the field tests:
• Four locomotives, including at least one of the three locomotives equipped with the
necessary LCU used for enforcement algorithm testing
• 100 loaded test cars from the Facility for Accelerated Service Testing (FAST) train
7.5 Material Requirements
None.
7.6 Special Requirements
None.
8.0 Restoration and/or Dismantling
8.1 Facility Restoration
None.
8.2 Track Restoration
None.
8.3 Equipment Disposition
None.
8.4 Material Disposition
None.
8.5 Special Equipment Disposition
None.
9.0 Data Requirements

249
 9.1 Data Types
The following data will be collected during this field test:
• Locomotive location
• Locomotive speed
• Locomotive brake pipe pressure
• Locomotive notch
• Train brake pipe pressure at three locations throughout the train (test cars)
• Brake cylinder pressure on three tests cars located throughout the train
9.2 Recording Techniques
Locomotive location, speed, brake pipe pressure and locomotive notch will be collected once per
second by the locomotive control unit (LCU) and transmitted to the enforcement algorithm PC,
which will keep a record of these data items. Train brake pipe pressure and brake cylinder
pressure from the test cars will be collected at 256 Hz using an unmanned data acquisition
computer (UDAC).
9.3 Data Analysis
The data collected will be used to evaluate the performance of the enforcement algorithm. For
each test, the stopping location with the current algorithm will be compared to the same test with
the base case enforcement algorithm. The objective is to determine the improvement in authority
violations for trains equipped with emergency brake back-up algorithm. The results will also be
compared against the safety and performance objectives for each test scenario.
The actual brake pipe and brake cylinder data, stop distance and stop time will also be compared
to the prediction data from the enforcement algorithm to determine the accuracy of the prediction
and identify any flaws in the algorithm logic that need to be investigated.
9.4 Reports
Documentation of the field test will be included in a final report for the project.
10.0 Safety
TTCI has a very successful safety record. Strict operating and safety rules will be followed
during the work described in this proposal.
A pre-test meeting will be held before any physical work is started. Safety and quality issues
will be addressed at this meeting.
11.0 Work Schedule
The field testing will occur during the week of July 12, 2010.
12.0 Quality Assurance

250
TTCI is committed to providing products and/or services that meet and/or exceed the customers’
specified contractual and project requirements. TTCI recognizes that in order to provide and
maintain a consistently high quality in the work it undertakes, an effective Quality Management
System is necessary so as to ensure that proper communication, work control and accountable
records are generated for all work undertaken.
It is the policy, therefore, of TTCI to control and conduct its business of consultancy and test
services in the railway transportation arena by means of a formalized system of modern quality
management that conforms to the requirements of ISO 9001–2000. Through the QMS, TTCI is
able to ensure that our products and services meet or exceed our customers’ expectations.
In order to ensure our entire organization supports the quality process, TTCI sponsors an
employee led Quality Resource Team (QRT). The mission of the QRT is to “To promote
customer satisfaction by providing effective training, education, and communication tools for
Team TTCI.” The QRT works directly with TTCI’s marketing team to identify customer
satisfaction issues and help resolve them. The QRT also provides period refresher training to
TTCI employees in science of Continuous Quality Improvement, Customer Satisfaction, and the
implementation of problem solving tools.
13.0 Support Specialties
N/A

251
 Task Order 242: Development of a PTC Enforcement
Algorithm for Freight Trains

Lockheed Martin Phase 1 Field Test

Field Test Implementation Plan

November/December 2010

Approval:________________________________________
Terry Tse, COTM Date

Presented By:
Transportation Technology Center, Inc.
A Subsidiary of the Association of American Railroads
55500 D.O.T. Road
P.O. Box 11130
Pueblo, Colorado, USA 81001

252
1.0 Project Title
Development of an Implementation-Ready Enforcement Braking Algorithm for Freight Trains
2.0 Introduction
Positive Train Control (PTC) is an emerging train control technology intended to enhance safety
and possibly improve train performance and plant capacity. The underlying concept of the
technology is that movement authorities are transmitted digitally to the controlling locomotive of
each train. The locomotive tracks the train’s location with respect to its authority and speed
limits and the train’s stopping ability based on known and assumed train parameters and brake
pipe pressure, and automatically applies brakes to prevent the train from violating any limit in
the event of human failure. Enforcement braking is an event of last recourse when the
locomotive engineer has failed to take adequate action. A full service penalty brake application
is used for enforcement in today’s PTC systems.
As part of the first phase of work under this task order, a number of new functions have been
developed and tested that are intended to improve the operational performance of the
enforcement algorithm without negatively affecting the safety performance. These
developments include:
• Modifications to the algorithm logic
• Modifications to the assumptions within the algorithm
• An improved target offset function
• Adaptive functions that adjust the assumed parameters based on measured braking
characteristics
• Distributed power function that adjusts the prediction for trains with distributed power
• Emergency brake back-up function that monitors the braking progress after the initial
penalty enforcement and applies the emergency brake if a target overrun is predicted
To evaluate the practical application of the functions and techniques developed in the first phase
of work, the enforcement algorithm will be tested as implemented in a functional PTC system
developed by Lockheed Martin. To fully quantify the performance of the enforcement algorithm
implemented by Lockheed Martin, a series of simulation and field tests will be performed. This
document describes the field test plan for this evaluation.
The objective of this test is to evaluate the Lockheed Martin implementation of the phase 1
enforcement algorithm. The results of this test will be used, in conjunction with the results of
simulation testing, to quantify the overall performance of the enforcement algorithm. The test
will be conducted in two stages. In the first stage, the PTC onboard system will receive stop
targets directly from the test personnel to evaluate the performance of the enforcement algorithm
as a standalone function. In the second stage, authorities will be provided to the PTC system
through a simulated dispatching system, and the PTC system will be responsible for generating
the stop targets to evaluate the performance of the enforcement algorithm as a component of the
overall PTC onboard system.

253
2.1 Key Personnel
Customer Contact, Ruben Pena, Assistant Director, Business Acquisition / DC
Telephone: 719-584-0543
Fax: 719-584-0770
Email: [email protected]
Program Manager, Dingqing Li, Principal Investigator II / FRA Program Manager
Telephone: 719-584-0740
Fax: 719-584-0791
Email: [email protected]
Project Manager, Joe Brosseau, Senior Engineer I
Telephone: 719-584-7128
Fax: 719-584-0771
Email: [email protected]
Test Engineer, Jeremy Dasher, Engineering Aid
Telephone: 719-584-0758
Fax: 719-584-0758
Email: [email protected]

2.2 Responsibilities
The project manager for this project is Joe Brosseau. He is responsible for ensuring that the test
is completed on time, within budget, and will ensure all deliverables meet or exceed FRA
requirements. The test engineer for this test is Jeremy Dasher. He will be responsible for
ensuring that the test is executed according to the test plan, that all data is collected properly, and
that the test is completed safely.
2.3 Documentation
The results of this test will be documented within the final report for this project.
3.0 Preparation
In preparation for field testing of the enforcement algorithm, the following tasks will be
completed:
• Test locomotive setup/checkout. This includes the installation of a PTC locomotive
control unit (LCU) that contains the Lockheed Martin (LM) implementation of the
enforcement algorithm. The LCU will also be capable of interfacing with the TTCI

254
 enforcement algorithm test application operating on a separate test machine. The TTCI
enforcement algorithm test application will primarily be used for data collection
purposes, but will also be used in selected test cases as an enforcement algorithm for
direct comparison to the LM implementation.
• Enforcement algorithm software setup/checkout. This includes testing of the
enforcement algorithm software in a simulation environment to determine that the
algorithm will operate as expected.
• Test consist setup. This includes determining the specific consist to be used and
installing the test instrumentation.
• Tribometer reading will be taken before and after testing to document track conditions.
4.0 Implementation
4.1 Constraints
None.
4.2 Operation Sequence
Track Testing
The test will be conducted in two stages. In the first stage, the PTC onboard system will receive
stop targets directly from the test personnel to evaluate the performance of the enforcement
algorithm as a standalone function. In the second stage, a simulated dispatching system will be
used to provide movement authorities to the onboard system to evaluate the performance of the
enforcement function as contained within the overall onboard system.
During the first stage of testing, the LM implementation of the enforcement algorithm will be
tested over a variety of test scenarios. For a select number of these test scenarios, the TTCI
implementation of the enforcement algorithm will also be tested to verify that the results are
consistent between the TTCI and Lockheed Martin implementations.
The field test configuration for the first stage of testing of the LM implementation is shown in
Figure 1. The lead locomotive of the test consist will house a Locomotive Control Unit (LCU)
and a standard laptop PC. The LCU will contain the Lockheed Martin implementation of the
enforcement algorithm (EA) and the laptop PC will contain the TTCI enforcement algorithm test
application.
The enforcement algorithm contained within the LCU will be initialized with consist data and
stop target data by test personnel prior to each test. Track data loaded on the LCU will contain
surveyed grade and curve data for the Railroad Test Track (RTT), to be accessed by the
enforcement algorithm during the test. The enforcement algorithm will then collect train status
data, including train speed, position, head end brake pipe pressure, tail end brake pipe pressure as
reported by an EOT device and locomotive notch, in real time as the test is run, and use this data
to enforce penalty and emergency brake applications, as necessary to avoid a target overrun.
The train status data will also be sent to the TTCI enforcement algorithm test application via an
Ethernet connection. The TTCI enforcement algorithm test application will be used to record
255
data throughout each test for use in determining when the brakes were applied, where the train
stopped, etc.

Head/Tail End BPP

GPS Antennae
Algorithm
Head EndPC
BPP Headen
d BPP
Enforcement
Algorithm PC
Location Bits
Discrete
Penalty
Application
Brake
Dynamic
Heath Status
Brake Notch/Spee
GPS
Penalty
Penalty
Brake
Brake
/
Application
Test Car
Location
Antennae
d
Dynamic
Penalty Application
Application Emergency Brake Emergency
Tail End BPP Brake
Notch/Speed
Misc. Hardware Application Brake
Misc. Hardware Emergency Brake
Dynamic
Notch Brake
HeadEnd
Tail EndBPP
BPP
Enforcement
Emergency Brake
Tail End BPP
Application
Speed/Location
Dynami Discrete Bits
cBrake Heath Status

Figure 1 – First Stage Test Configuration – LM EA

The test configuration for testing the TTCI implementation of the enforcement algorithm is
shown in Figure 2. For these cases, the TTCI implementation of the enforcement algorithm,
contained on the laptop PC, will be initialized with consist and target stop data. The enforcement
algorithm will then interface with the LCU over an Ethernet connection to receive train status
data and enforce penalty and emergency brake applications, as necessary to avoid a target
overrun.

Speed/Location
EOT
Test Car
GPS
EOTAntennae

Device
Tail End BPP
Dynamic
Brake
Notch
Head End BPPHardware
Brake
Misc.
Speed/Location
Notch Misc. Hardware
Discrete Bits
Discrete Bits
Notch/Speed
Enforcement
Head End BPP
Penalty Brake Algorithm PC
Application Tail TailBPP
End End BPP
Penalty Brake / Headend BPP
Emergency Head/Tail
Dynamic End BPP
Brake
Emergency Brake Notch/Speed
Location
Tail End BPP
Application GPS Antennae
Dynamic Brake

Location
Heath Status
Penalty
Dynamic
Brake Emergency Brake
Application Application

Figure 2 – First Stage Test Configuration – TTCI EA

256
The first stage of field testing will test enforcement algorithm over a number of test scenarios,
which will cover a range of operating conditions. The test scenarios are determined by varying
the following independent test variables:
• Consist – The field tests will use the consist from the Facility for Accelerated Service
Testing (FAST). The length of the consist is specified for each test scenario as one
of the following:
▬ Long – 85 to 90 cars (based on availability of cars)
▬ Medium – 40 cars
▬ Short – 10 cars
• Track – The approximate track grade over the braking distance:
▬ Flat – 0% grade
▬ Decline – 1.5% grade
▬ Incline – 0.7% grade
▬ Crest – 0.6 % incline and 0.6 % decline
▬ Varying – 0% to 0.7% incline
• Speed – The approximate train speed at enforcement. In some cases, two speeds are
listed, which indicates there will be a speed restriction in addition to an absolute stop
target or authority limit.
• Type of test – The system objective to be evaluated by the test scenario:
▬ Safety – Test to ensure the enforcement algorithm stops the train short of the
target or authority limit by running the train at the test speed toward the target
until enforcement stops the train.
▬ Performance – Test to ensure the algorithm does not interfere with normal
train handling by running the train at the test speed toward the target and
having the locomotive engineer bring the train to a stop using normal train
handling procedures.
Some of the tests will be run multiple times to evaluate repeatability, as indicated by the
“Number of Runs” column in the test matrix. The specific test scenarios are listed in Table 1.
Test cases sixteen and seventeen will test the performance of the enforcement algorithm with a
speed restriction in addition to an absolute stop target.
For test case 21, the emergency brake back-up function of the enforcement algorithm will be
evaluated. For this test case, the train will be artificially forced to overrun the target by a small
margin following the penalty enforcement to evaluate whether the emergency brake back-up
function enforces an emergency brake application to stop the train short of the target.

257
 Table 1 – First Stage Test Scenarios
Test Consist Track Speed Brake State Type of Target Number of Algorithm
Case Test Pt Runs

1 Long Flat 10 Fully Safety R24 3 LM

Charged

2 Long Flat 10 Fully Performance R24 2 LM

Charged
3 Long Flat 30 Fully Safety R24 3 LM
Charged
4 Long Flat 60 Fully Safety R24 1 LM
Charged
5 Long Decline 30 Fully Safety R14 3 LM
Charged
6 Long Decline 30 Fully Performance R14 2 LM
Charged
7 Long Varying 30 Fully Safety R27 1 LM
Charged
8 Med Decline 60 Fully Safety R14 1 LM
Charged
9 Med Decline 60 Fully Performance R14 2 LM
Charged
10 Short Flat 30 Fully Safety R24 3 LM
Charged
11 Short Flat 30 Fully Performance R24 2 LM
Charged
12 Long Flat 30 Applied Safety R24 3 LM
13 Long Incline 10 Fully Safety R48 1 LM
Charged
14 Long Incline 30 Fully Safety R48 3 LM
Charged
15 Long Crest 30 Fully Safety R69 1 LM
Charged
16 Long Flat 60,30 Fully Safety R30 1 LM
Charged 30 at
R24
17 Long Flat 60,30 Fully Performance R30 2 LM
Charged 30 at
R24
18 Long Flat 60 Fully Safety R24 1 TTCI
Charged
19 Short Flat 30 Fully Safety R24 1 TTCI
Charged
20 Med Decline 60 Fully Safety R14 1 TTCI
Charged
21 Long Flat 30 Fully Safety R24 2 LM
Charged

258
Each test case will begin with a standing air brake test, in which a 15 psi brake pipe pressure
reduction will be made by the locomotive crew to allow the enforcement algorithm an
opportunity to correct for the actual propagation time of the train. The train will then be
accelerated to a speed of approximately 30 mph, and a running brake test will be performed, in
which the locomotive crew will make a 15 psi brake pipe pressure reduction to allow the
enforcement algorithm an opportunity to correct for the actual braking efficiency of the train.
Following the standing and running brake tests, the enforcement algorithm test runs for the test
case will be executed. The train will be moved to the starting position appropriate for the
specific test case. The train will then be accelerated to the specified test speed and proceed
towards the target stopping location, with the enforcement algorithm monitoring the speed,
location, and brake pipe pressure of the train. When the enforcement algorithm determines that
an enforcement brake application is necessary, the LCU will drop power to the locomotives and
apply a penalty brake application. The locomotive engineer will bail off the locomotive brakes
as soon as the penalty application has been made.
For the performance tests, the locomotive crew will stop the train prior to the target using normal
train handling procedures. The enforcement algorithm may or may not enforce a penalty brake
application in these test cases.
Once the train has stopped, the absolute stopping location will be recorded and the location
relative to the target will be measured and recorded before resetting the train for the next test run.
For the second stage of testing, movement authorities will be provided to the PTC onboard
system through a simulated dispatching system, and the onboard system will be responsible for
generating the stop targets to evaluate the performance of the enforcement algorithm as a
component of the overall PTC onboard system. The field test configuration for the second stage
is shown in Figure 3.

Notch
Tail End BPP
Device
Speed/Locatio Notch
n
Tail End BPP
Speed/Location
Misc. Hardware
Algorithm
Headend PC Bits
BPP
Discrete
Penalty Brake / Emergency
Head
Head
EndEnd
BPP BPP Heath Status
Notch/Speed Brake
Penalty
Head/Tail
BrakeEnd
/ BPP PenaltyApplication
Brake
Penalty Brake Tail End BPP Location
Application Brake
Emergency Brake Dynamic
Brake
Application Application Application
DynamicDynamic
Brake Brake
GPS Antennae
Test Car GPS Antennae

EOT
Emergency
Location Tail End BPP
DeviceBrake
Emergency Dynamic

Figure 3 – Second Stage Test Configuration

The specific test scenarios for the second stage of testing are listed in Table 2.

259
 Table 2 – Second Stage Test Scenarios
Test Consist Track Speed Brake Type of Test Begin Target Number Algorithm
Case State Authority of Runs
Pt
1 Long Flat 10 Fully Safety R66 R24 3 LM
Charged
2 Long Flat 10 Fully Performance R66 R24 2 LM
Charged
3 Long Flat 30 Fully Safety R66 R24 3 LM
Charged
4 Long Flat 60 Fully Safety R66 R24 1 LM
Charged
5 Long Decline 30 Fully Safety R66 R14 3 LM
Charged
6 Long Decline 30 Fully Performance R66 R14 2 LM
Charged
7 Long Varying 30 Fully Safety R66 R27 1 LM
Charged
8 Med Decline 60 Fully Safety R66 R14 1 LM
Charged
9 Med Decline 60 Fully Performance R66 R14 2 LM
Charged
10 Short Flat 30 Fully Safety R66 R24 3 LM
Charged
11 Short Flat 30 Fully Performance R66 R24 2 LM
Charged
12 Long Flat 30 Applied Safety R66 R24 3 LM
13 Long Decline 10 Fully Safety R66 R14 1 LM
Charged
14 Med Flat 30 Fully Safety R66 R24 1 LM
Charged
15 Long Flat 30,20 Fully Safety R66 R30 1 LM
Charged
20 at
R24
16 Long Flat 30,20 Fully Performance R66 R30 2 LM
Charged 20 at
R24
17 Med Flat 60,30 Fully Safety R66 R30 1 LM
Charged 30 at
R24
18 Med Flat 60,30 Fully Performance R66 R30 2 LM
Charged
30 at
R24
19 Short Decline 30 Fully Safety R66 R14 1 LM
Charged
20 Long Flat 30 Fully Safety R66 R24 2 LM
Charged

260
4.2.1 Validation Testing
N/A
4.2.2 Endurance Testing
N/A
4.2.3 Safety Margin Tests
N/A
4.3 Operation Locations
The stop tests will occur at various locations, as per Tables 1 & 2, around the Railroad Test
Track (RTT), located at the Transportation Technology Center (TTC) in Pueblo, CO.
4.4 Special Support
N/A
4.5 Instrumentation Types
See section 5.0.
4.6 Measurement Definitions
The following measurements will be taken during the field test for each test run:
• Penalty enforcement location. The location in footage relative to a specific point on the
track will be measured by the LCU and recorded by the enforcement algorithm software
once the train has received a penalty application.
• Emergency enforcement location. The location in footage relative to a specific point on
the track will be measured by the LCU and recorded by the enforcement algorithm
software once the train has received an emergency application.
• Stopping location. The location in footage relative to a specific point on the track will be
measured by the LCU and recorded by the enforcement algorithm software once the train
has come to a stop.
• Stopping location relative to the target. The difference in footage between the stopping
location and the target location will be calculated in post-processing.
• Stopping distance. The difference in footage between the point of penalty brake
application and stopping location will be calculated in post-processing.
4.7 Data Collection Schematics
None.

5.0 Instrumentation Identification

261
5.1 On-Board Instrumentation List
The on-board instrumentation includes:
• Locomotive control unit (LCU)
• Laptop computer containing enforcement algorithm software
• Locomotive brake pipe pressure transducer
• GPS antennas
• Penalty brake valve
• Emergency brake valve
• Three test cars with brake pipe pressure transducers spaced throughout the train behind
the 10th, 40th and last car
• Three test cars with brake cylinder pressure transducers spaced throughout the train on
the 10th, 40th and last car
• Three unmanned data acquisition computers (UDAC)
5.2 Wayside Instrumentation List
None.
5.3 Special Instrumentation List
A hand-operated tribometer will be used for recording adhesion coefficients at test locations
around the RTT.
6.0 Photography and Video
6.1 Photography Requirements
None.
6.2 Video Requirements
None.
7.0 Transportation Technology Center, Inc. Requirements
7.1 Facility Requirements
None.
7.2 Track Requirements
The enforcement algorithm will be tested at various locations, as per Tables 1 & 2, around the
13.5 mile Railroad Test Track (RTT) at the Transportation Technology Center (TTC). Other
tracks may be needed for switching and storage of test cars.

262
7.3 Labor/Personnel Requirements
The following personnel will be required to setup, perform, and analyze the results from the tests
planned:
• Test engineer(s): The test engineer(s) will be responsible for organizing and managing
the test activities, including providing test plans, procedures, and data sheets to test
personnel, and ensuring test activities can be performed in a safe manner. It will also be
the responsibility of the test engineer(s) to oversee setup of the instrumentation, running
the enforcement algorithm software, and recording or ensuring necessary data is
recorded. Post test, the test engineer(s) will analyze the data collected for use in other
tests and future developments of the enforcement algorithm.
• Test controller: The test controller will be in charge of the actual tests and all movements
of the test consist. This includes ensuring all safety rules, test plans, and other
instructions are followed by all test personnel. The test controller will be the point of
communication between the test engineers and the locomotive engineer and any other test
personnel. The test controller will coordinate all train moves with the proper personnel in
the Operations Control Center (OCC), and ensure safe test conditions at all times.
Finally, the test controller will keep a detailed log of the test activities.
• Locomotive engineer: The locomotive engineer will execute train moves as necessary for
test setup, switching, and test functions.
• Instrumentation engineer(s): The instrumentation engineer(s) will work closely with the
test engineer(s) to set up all test instrumentation, and ensure the proper operation of the
instrumentation and data collection system during testing.
• Lockheed Martin test personnel: The Lockheed Martin test support personnel will be
responsible for ensuring the Lockheed Martin hardware and software operate properly
and will work with the Test engineer(s) to ensure that the test procedures are executed
properly.
7.4 Equipment Requirements
The following equipment will be required for the field tests:
• Four locomotives, including at least one of the three locomotives equipped with the
necessary LCU used for enforcement algorithm testing
• 85-90 loaded test cars from the Facility for Accelerated Service Testing (FAST) train
7.5 Material Requirements
None.
7.6 Special Requirements
None.

8.0 Restoration and/or Dismantling

263
8.1 Facility Restoration
None.
8.2 Track Restoration
None.
8.3 Equipment Disposition
None.
8.4 Material Disposition
None.
8.5 Special Equipment Disposition
None.
9.0 Data Requirements
9.1 Data Types
The following data will be collected during this field test:
• Locomotive location
• Locomotive speed
• Locomotive brake pipe pressure
• Locomotive notch
• Train brake pipe pressure at three locations throughout the train (test cars)
• Train brake cylinder pressure at three locations throughout the train (test cars)
• Specific test consist makeup
9.2 Recording Techniques
Locomotive location, speed, brake pipe pressure and locomotive notch will be collected once per
second by the locomotive control unit (LCU). Train brake pipe pressure and brake cylinder
pressure from three of the test cars will be collected at 256 Hz using an unmanned data
acquisition computer (UDAC).
9.3 Data Analysis
The data collected will be used to evaluate the performance of the enforcement algorithm. For
each test, the data collected will be reprocessed using the TTCI enforcement algorithm test
application. The stopping location and the time of the penalty application from the Lockheed
Martin algorithm will be compared to the results of reprocessing the data through the TTCI
enforcement algorithm test application. The objective is to determine how the Lockheed Martin
implementation compares to the test application of the enforcement algorithm.

264
The results will also be compared against the safety and performance objectives for each test
scenario, and used to validate the results of simulation testing that will support the evaluation of
the algorithm against these objectives.
The actual brake pipe and brake cylinder data, stop distance and stop time will also be compared
to the prediction data from the enforcement algorithm to determine the accuracy of the prediction
and identify any flaws in the algorithm logic that need to be investigated.
9.4 Reports
Documentation of the field test will be included in a final report for the project.
10.0 Safety
TTCI has a very successful safety record. Strict operating and safety rules will be followed
during the work described in this proposal.
A pre-test meeting will be held before any physical work is started. Safety and quality issues
will be addressed at this meeting.
A safety and job briefing will be held prior to start of testing each day, with subsequent job
briefings throughout the day if required by a change in the work plan.
11.0 Work Schedule
The first stage of field testing will occur during the week of November 29, 2010 and the second
stage will occur during the week of December 13, 2010.
12.0 Quality Assurance
TTCI is committed to providing products and/or services that meet and/or exceed the customers’
specified contractual and project requirements. TTCI recognizes that in order to provide and
maintain a consistently high quality in the work it undertakes, an effective Quality Management
System is necessary so as to ensure that proper communication, work control and accountable
records are generated for all work undertaken.
It is the policy, therefore, of TTCI to control and conduct its business of consultancy and test
services in the railway transportation arena by means of a formalized system of modern quality
management that conforms to the requirements of ISO 9001–2000. Through the QMS, TTCI is
able to ensure that our products and services meet or exceed our customers’ expectations.
In order to ensure our entire organization supports the quality process, TTCI sponsors an
employee led Quality Resource Team (QRT). The mission of the QRT is to “To promote
customer satisfaction by providing effective training, education, and communication tools for
Team TTCI.” The QRT works directly with TTCI’s marketing team to identify customer
satisfaction issues and help resolve them. The QRT also provides period refresher training to
TTCI employees in science of Continuous Quality Improvement, Customer Satisfaction, and the
implementation of problem solving tools.
13.0 Support Specialties
N/A

265
 Task Order 242: Development of a PTC Enforcement
Algorithm for Freight Trains

Enforcement with Dynamic Brake Field Test

Field Test Implementation Plan

April 2011

Approval:________________________________________
Terry Tse, COTM Date

Presented By:
Transportation Technology Center, Inc.
A Subsidiary of the Association of American Railroads
55500 D.O.T. Road
P.O. Box 11130
Pueblo, Colorado, USA 81001

266
1.0 Project Title
Development of an Implementation-Ready Enforcement Braking Algorithm for Freight Trains
2.0 Introduction
The objective of this test is to evaluate the performance of a PTC braking enforcement algorithm
modified to consider the use of dynamic brake applications made prior to the enforcement. The
modified algorithm will be compared to the base algorithm to demonstrate the potential safety
and performance benefits. This document describes the field test plan for this evaluation.
Positive Train Control (PTC) is an emerging train control technology intended to enhance safety
and possibly improve train performance and plant capacity. The underlying concept of the
technology is that movement authorities are transmitted digitally to the controlling locomotive of
each train. The locomotive tracks the train’s location with respect to its authority and speed
limits and the train’s stopping ability based on known and assumed train parameters and brake
pipe pressure, and automatically applies brakes to prevent the train from violating any limit in
the event of human failure. Enforcement braking is an event of last recourse when the
locomotive engineer has failed to take adequate action. A full service penalty brake application
is used for enforcement in today’s PTC systems.
Historically, PTC braking enforcement algorithms do not take the retarding force due to dynamic
brake into account during the stopping prediction. This is due to the fact that the dynamic brakes
are not designed for fail-safe operation. However, this has an adverse effect on the performance
of the braking prediction in cases where dynamic brake is being used to control the train. By
ignoring the force generated by the dynamic brake, enforcement occurs earlier than necessary,
resulting in unnecessary use of the air brakes, interference with normal, crew-initiated braking,
and potentially excessive warnings and enforcements.
To resolve these issues, the PTC braking enforcement algorithm needs to account for the
retarding force resulting from a dynamic brake application made prior to a PTC penalty
enforcement. The ability to account for this force is essential to achieving the performance goals
of the PTC system.
It is therefore desirable to design a system where the retarding force resulting from a dynamic
brake application is included in the calculation of the penalty enforcement location. The
algorithm will assume that the force due to dynamic brake that is present before an enforcement
occurs will remain throughout the penalty enforcement. If the dynamic brake fails during a PTC
penalty enforcement the emergency brake backup routine will trigger an emergency brake
application if it determines the train will not come to a stop before the target.
As part of the second phase of work under this task order, this dynamic brake subroutine has
been incorporated into the braking enforcement algorithm test application to evaluate the
practical application of this concept.

2.1 Key Personnel

Customer Contact, Ruben Pena, Assistant Director, Business Acquisition / DC
267
Telephone: 719-584-0543
Fax: 719-584-0770
Email: [email protected]
Program Manager, Dingqing Li, Principal Investigator II / FRA Program Manager
Telephone: 719-584-0740
Fax: 719-584-0791
Email: [email protected]
Project Manager, Joe Brosseau, Senior Engineer II
Telephone: 719-584-7128
Fax: 719-584-0771
Email: [email protected]
Test Engineer, Jeremy Dasher, Engineering Aid
Telephone: 719-584-0758
Fax: 719-584-0758
Email: [email protected]

2.2 Responsibilities
The project manager for this project is Joe Brosseau. He is responsible for ensuring that the test
is completed on time, within budget, and will ensure all deliverables meet or exceed FRA
requirements. The test engineer for this test is Jeremy Dasher. He will be responsible for
ensuring that the test is executed according to the test plan, that all data is collected properly, and
that the test is completed safely.
2.3 Documentation
The results of this test will be documented within the final report for this project.
3.0 Preparation
In preparation for field testing of the enforcement algorithm, the following tasks will be
completed:
• Test locomotive setup/checkout. This includes the installation of a PTC locomotive
control unit (LCU). The LCU will be capable of interfacing with the TTCI enforcement
algorithm test application operating on a separate test machine. The TTCI enforcement
algorithm test application will be used as an enforcement algorithm and for data
collection purposes.

268
 • Enforcement algorithm software setup/checkout. This includes testing of the
enforcement algorithm software in a simulation environment to determine that the
algorithm will operate as expected.
• Test consist setup. This includes determining the specific consist to be used and
installing the test instrumentation.
• Tribometer readings will be taken before and after testing to document track conditions.
4.0 Implementation
4.1 Constraints
None.
4.2 Operation Sequence
4.2.1 Track Testing
The field test configuration is shown in Figure 1. The lead locomotive of the test consist will
house a Locomotive Control Unit (LCU) and a standard laptop PC. The LCU will be used as
interface to the locomotive’s brake and computer systems. The laptop PC will contain the TTCI
enforcement algorithm test application.
The enforcement algorithm will collect train status data, including train speed, position, head end
brake pipe pressure, tail end brake pipe pressure as reported by an EOT device, dynamic brake
voltage, dynamic brake setup status, and locomotive notch. This train status data will be
collected by the enforcement algorithm application, in real time as the test is run, and used to
enforce penalty and emergency brake applications, as necessary, to avoid a target overrun. The
enforcement algorithm test application will also be used to record the data throughout each test
for use in determining when the brakes were applied, where the train stopped, etc.

Head End BPP

EOT
Head
Tail End BPP
Notch
End BPP
Tail EndSpeed/Location
BPP Notch
Discrete Bits
Headend
Head/TailNotch/Speed
BPP
athEnd BPP
Status
Test
Enforcement
Machine Notch/Speed
Location
Location
Tail End BPP
Penalty
Penalty
Brake
Brake
/
Application Application
Emergency Misc. Hardware
Emergency Brake
Brake Dynamic
Tail End BPP Application Penalty Brake
Authority Limits
GPS Antennae
Test Car
Speed Restrictions
GPS Antennae
Speed/Location

Simulated CAD System

Dynamic Brake
Emergency
Misc. Hardware
Brake Dynamic
Application Brake

Figure 1 – First Stage Test Configuration – TTCI EA

269
The field testing will test the enforcement algorithm over a number of test scenarios, which will
cover a range of operating conditions. The test scenarios are determined by varying the
following independent test variables:
• Consist – The field tests will use the consist from the Facility for Accelerated Service
Testing (FAST). The length of the consist is specified for each test scenario as one
of the following:
▬ Long – 85 to 90 cars (based on availability of cars)
▬ Medium – 40 cars
▬ Short – 10 cars
• Track – The approximate track grade over the braking distance:
▬ Flat – 0% grade
▬ Decline – 1.5% grade
• Speed – The target train speed at the time enforcement braking is activated.
• Type of test – The system objective to be evaluated by the test scenario:
▬ Safety – Test to ensure the enforcement algorithm stops the train short of the
target or authority limit by running the train at the test speed toward the target
until enforcement stops the train.
▬ Performance – Test to ensure the algorithm does not interfere with normal
train handling by running the train at the test speed toward the target and
having the locomotive engineer bring the train to a stop using normal train
handling procedures.
▬ EBB-Safety – Test to ensure that the emergency brake backup routine stops
the train short of the target when penalty braking is insufficient to do so. This
situation is forced by having some locomotives continue to apply tractive
effort after penalty braking is invoked.
▬ Safety w/ DB Failure – Test to ensure the emergency brake backup routine
stops the train short of the target if the dynamic brakes fail after a penalty
enforcement or if dynamic braking is reduced by the operator after penalty
enforcement is initiated. This situation is forced by having the locomotive
engineer remove dynamic braking once the penalty is enforced by the LCU.
The specific test cases are listed in Table 1. Tests will be run multiple times to evaluate
repeatability, up to three tests per test case. Each test case will be performed using the base case
algorithm as well as the current algorithm with the dynamic brake modifications. The level of
dynamic braking applied prior to enforcement will be determined by the locomotive engineer for
each of the test cases.
For the EBB-Safety test case, the emergency brake back-up function of the enforcement
algorithm will be evaluated. For this test case, the train will be artificially forced to overrun the
target by a small margin following the penalty enforcement to evaluate whether the emergency
brake back-up function enforces an emergency brake application to stop the train short of the
target.

270
 Table 1 –Test Scenarios

Target
Test Case Consist Track Speed Type of Test
Pt

1 Short Decline 30 Safety R14

2 Short Decline 30 Safety w/ DB Failure R14
3 Short Flat 30 Performance R24
4 Short Decline 30 Performance R14
5 Med Decline 30 Safety R14
6 Med Decline 30 Safety w/ DB Failure R14
7 Med Decline 50 Safety R14
8 Med Decline 50 Safety w/ DB Failure R14
9 Med Flat 30 Performance R24
10 Med Decline 30 Performance R14
11 Med Flat 30 EBB -safety R24
12 Long Decline 10 Safety R14
13 Long Decline 10 Safety w/ DB Failure R14
14 Long Flat 10 Performance R24
15 Long Decline 10 Performance R14
16 Long Decline 30 Safety R14
17 Long Decline 30 Safety w/ DB Failure R14

For each test, the train will be moved to the starting position appropriate for the specific test
case. The train will then be accelerated to the specified test speed and proceed towards the target
stopping location, with the enforcement algorithm monitoring the speed, location, dynamic brake
voltage, train acceleration, and brake pipe pressure of the train. When the enforcement algorithm
determines that a penalty brake application is necessary, the LCU will apply the penalty brake.
When this occurs, the locomotive engineer will bail off the locomotive brakes. In the case of the
safety with DB failure test cases, the locomotive engineer will also respond by removing the
dynamic brake. In all other cases, the dynamic brake will remain at its current setting for the
remainder of the test.
For the performance tests, the locomotive crew will stop the train prior to the target using normal
train handling procedures. The enforcement algorithm may or may not enforce a penalty brake
application in these test cases.
Once the train has stopped, the absolute stopping location will be recorded and the location
relative to the target will be measured and recorded before resetting the train for the next test run.
4.2.2 Validation Testing
N/A

271
 4.2.3 Endurance Testing
N/A
4.2.4 Safety Margin Tests
N/A
4.3 Operation Locations
The stop tests will occur at various locations, as per Table 1, around the Railroad Test Track
(RTT), located at the Transportation Technology Center (TTC) in Pueblo, CO.
4.4 Special Support
N/A
4.5 Instrumentation Types
See section 5.0.
4.6 Measurement Definitions
The following measurements will be taken during the field test for each test run:
• Penalty enforcement location. The location in footage relative to a specific point on the
track will be measured by the LCU and recorded by the enforcement algorithm software
once the train has received a penalty application.
• Emergency enforcement location. The location in footage relative to a specific point on
the track will be measured by the LCU and recorded by the enforcement algorithm
software once the train has received an emergency application.
• Stopping location. The location in footage relative to a specific point on the track will be
measured by the LCU and recorded by the enforcement algorithm software once the train
has come to a stop.
• Stopping location relative to the target. The difference in footage between the stopping
location and the target location will be calculated in post-processing.
• Stopping distance. The difference in footage between the point of penalty brake
application and stopping location will be calculated in post-processing.
4.7 Data Collection Schematics
None.
5.0 Instrumentation Identification
5.1 On-Board Instrumentation List
The on-board instrumentation includes:
• Locomotive control unit (LCU)
272
 • Laptop computer containing enforcement algorithm software
• Locomotive brake pipe pressure transducer
• GPS antennas
• Penalty brake valve
• Emergency brake valve
• Two test cars with brake pipe pressure transducers spaced throughout the train:
▬ 10-car train: at the 10th car
▬ 40-car train: at the 10th and 40th car
▬ 90-car train: at the 40th and 90th car
• Two test cars with brake cylinder pressure transducers spaced throughout the train:
▬ 10-car train: at the 10th car
▬ 40-car train: at the 10th and 40th car
▬ 90-car train: at the 40th and 90th car
• Two unmanned data acquisition computers (UDAC)

5.2 Wayside Instrumentation List

None.
5.3 Special Instrumentation List
A hand-operated tribometer will be used for recording rail adhesion coefficients at test locations
around the RTT.
6.0 Photography and Video
6.1 Photography Requirements
None.
6.2 Video Requirements
None.
7.0 Transportation Technology Center, Inc. Requirements
7.1 Facility Requirements
None.
7.2 Track Requirements

273
The enforcement algorithm will be tested at various locations, as per Table 1, around the 13.5
mile Railroad Test Track (RTT) at the Transportation Technology Center (TTC). Other tracks
may be needed for switching and storage of test cars.
7.3 Labor/Personnel Requirements
The following personnel will be required to setup, perform, and analyze the results from the tests
planned:
• Test engineer(s): The test engineer(s) will be responsible for organizing and managing
the test activities, including providing test plans, procedures, and data sheets to test
personnel, and ensuring test activities can be performed in a safe manner. It will also be
the responsibility of the test engineer(s) to oversee setup of the instrumentation, running
the enforcement algorithm software, and recording or ensuring necessary data is
recorded. Post test, the test engineer(s) will analyze the data collected for use in other
tests and future developments of the enforcement algorithm.
• Test controller: The test controller will be in charge of the actual tests and all movements
of the test consist. This includes ensuring all safety rules, test plans, and other
instructions are followed by all test personnel. The test controller will be the point of
communication between the test engineers and the locomotive engineer and any other test
personnel. The test controller will coordinate all train moves with the proper personnel in
the Operations Control Center (OCC), and ensure safe test conditions at all times.
Finally, the test controller will keep a detailed log of the test activities.
• Locomotive engineer: The locomotive engineer will execute train moves as necessary for
test setup, switching, and test functions.
• Instrumentation engineer(s): The instrumentation engineer(s) will work closely with the
test engineer(s) to set up all test instrumentation, and ensure the proper operation of the
instrumentation and data collection system during testing.
7.4 Equipment Requirements
The following equipment will be required for the field tests:
• Four locomotives, including at least one of the three locomotives equipped with the
necessary LCU used for enforcement algorithm testing
• 85-90 loaded test cars from the Facility for Accelerated Service Testing (FAST) train
7.5 Material Requirements
None.
7.6 Special Requirements
None.
8.0 Restoration and/or Dismantling
8.1 Facility Restoration
None.
274
 8.2 Track Restoration
None.
8.3 Equipment Disposition
None.
8.4 Material Disposition
None.
8.5 Special Equipment Disposition
None.
9.0 Data Requirements
9.1 Data Types
The following data will be collected during this field test:
• Locomotive location
• Locomotive speed
• Locomotive brake pipe pressure
• Locomotive notch
• Dynamic Brake Voltage
• Dynamic Brake Setup Status
• Train brake pipe pressure at three locations throughout the train (test cars)
• Train brake cylinder pressure at three locations throughout the train (test cars)
• Specific test consist makeup
9.2 Recording Techniques
Locomotive location, speed, brake pipe pressure, dynamic brake data, and locomotive notch will
be collected once per second by the locomotive control unit (LCU). Train brake pipe pressure
and brake cylinder pressure from three of the test cars will be collected at 256 Hz using an
unmanned data acquisition computer (UDAC).
9.3 Data Analysis
The data collected will be used to evaluate the performance of the enforcement algorithm. For
each test, the data collected will be reprocessed using the TTCI enforcement algorithm test
application. The results will be compared against the safety and performance objectives for each
test scenario, and used to validate the results of simulation testing that will support the evaluation
of the algorithm against these objectives.

275
The actual brake pipe and brake cylinder data, stop distance and stop time will also be compared
to the prediction data from the enforcement algorithm to determine the accuracy of the prediction
and identify any flaws in the algorithm logic that need to be investigated.
9.4 Reports
Documentation of the field test will be included in a final report for the project.
10.0 Safety
TTCI has a very successful safety record. Strict operating and safety rules will be followed
during the work described in this proposal.
A pre-test meeting will be held before any physical work is started. Safety and quality issues
will be addressed at this meeting.
A safety and job briefing will be held prior to start of testing each day, with subsequent job
briefings throughout the day if required by a change in the work plan.
11.0 Work Schedule
The field testing will occur during the week of April 18, 2011.
12.0 Quality Assurance
TTCI is committed to providing products and/or services that meet and/or exceed the customers’
specified contractual and project requirements. TTCI recognizes that in order to provide and
maintain a consistently high quality in the work it undertakes, an effective Quality Management
System is necessary so as to ensure that proper communication, work control and accountable
records are generated for all work undertaken.
It is the policy, therefore, of TTCI to control and conduct its business of consultancy and test
services in the railway transportation arena by means of a formalized system of modern quality
management that conforms to the requirements of ISO 9001–2000. Through the QMS, TTCI is
able to ensure that our products and services meet or exceed our customers’ expectations.
In order to ensure our entire organization supports the quality process, TTCI sponsors an
employee led Quality Resource Team (QRT). The mission of the QRT is to “To promote
customer satisfaction by providing effective training, education, and communication tools for
Team TTCI.” The QRT works directly with TTCI’s marketing team to identify customer
satisfaction issues and help resolve them. The QRT also provides period refresher training to
TTCI employees in science of Continuous Quality Improvement, Customer Satisfaction, and the
implementation of problem solving tools.
13.0 Support Specialties
N/A

276
 Task Order 242: Development of a PTC Enforcement
Algorithm for Freight Trains

Enforcement Testing with Manifest Freight Equipment

Field Test Implementation Plan

November 2011

Approval:________________________________________
Jared Withers, COTM Date

Presented By:
Transportation Technology Center, Inc.
A Subsidiary of the Association of American Railroads
55500 D.O.T. Road
P.O. Box 11130
Pueblo, Colorado, USA 81001

277
1.0 Project Title
Development of an Implementation-Ready Enforcement Braking Algorithm for Freight Trains
2.0 Introduction
The objective of this test is to evaluate the performance of a developmental PTC braking
enforcement algorithm with modifications designed specifically for use on manifest freight
equipment. The potential safety and performance benefits of the modified algorithm have been
demonstrated through field testing comparisons with the base algorithm using unit train
equipment. This test is designed to demonstrate similar safety and performance levels using
manifest freight equipment. This document describes the field test plan for this evaluation.
Positive Train Control (PTC) is an emerging train control technology intended to enhance safety
and possibly improve train performance and plant capacity. The underlying concept of the
technology is that movement authorities are transmitted digitally to the controlling locomotive of
each train. The locomotive tracks the train’s location with respect to its authority and speed
limits and the train’s stopping ability based on known and assumed train parameters and current
status, and automatically applies brakes to prevent the train from violating any limit in the event
of human failure. Enforcement braking is an event of last recourse when the locomotive
engineer has failed to take adequate action.
The primary objective of this research program is to identify and test methods for improving
enforcement algorithm performance. As such, a number of modifications to a base case
enforcement algorithm have been investigated and tested as part of this program. The process
began with a review of, and modifications to, the base logic of the algorithm, followed by the
addition of a number of new, developmental functions. The algorithm was exclusively designed
for, and tested on, unit train equipment.
As part of the third phase of work under this task order, modifications to the algorithm have now
been designed and implemented for expanding the scope of the algorithm to manifest freight
train equipment. These modifications include changes to some of the underlying assumptions, as
well as a change to the target offset function, which provides the enforcement algorithm with the
specified safety assurance.
2.1 Key Personnel
Customer Contact, Ruben Pena, Assistant Director, Business Acquisition / DC
Telephone: 719-584-0543
Fax: 719-584-0770
Email: [email protected]
Program Manager, Dingqing Li, Scientist and Chief Government Programs
Telephone: 719-584-0740
Fax: 719-584-0791
Email: [email protected]
278
Project Manager, Joe Brosseau, Senior Engineer II
Telephone: 719-584-7128
Fax: 719-584-0771
Email: [email protected]
2.2 Responsibilities
The project manager for this project is Joe Brosseau. He is responsible for ensuring that the test
is completed on time, within budget, and will ensure all deliverables meet or exceed FRA
requirements. He will also be responsible for ensuring that the test is executed according to the
test plan, that all data is collected properly, and that the test is completed safely.
2.3 Documentation
The results of this test will be documented within the final report for this project.
3.0 Preparation
In preparation for field testing of the enforcement algorithm, the following tasks will be
completed:
• Test locomotive setup/checkout. This includes the installation of a PTC locomotive
control unit (LCU). The LCU will be capable of interfacing with the TTCI enforcement
algorithm test application operating on a separate test machine. The TTCI enforcement
algorithm test application will be used as an enforcement algorithm and for data
collection purposes.
• Enforcement algorithm software setup/checkout. This includes testing of the
enforcement algorithm software in a simulation environment to determine that the
algorithm will operate as expected.
• Test consist setup. This includes acquiring the manifest freight cars to be used in the test
consist and installing the appropriate test instrumentation. It also includes documentation
of reporting marks, car type, dimensions, brake system information (including brake
rigging type, number of brake cylinders, control valve type, approximate brake cylinder
piston travel, and approximate brake pipe length), and coupler/draft gear types for each
car in the test consist. Finally, it includes documenting the scaled weight of each car in
the test consist.
• Tribometer readings will be taken before and after testing to document track conditions.
4.0 Implementation
4.1 Constraints
None.
4.2 Operation Sequence
279
 4.2.1 Track Testing
The field test configuration is shown in Figure 1. The lead locomotive of the test consist will
house a Locomotive Control Unit (LCU) and a standard laptop PC. The LCU will be used as
interface to the locomotive’s brake and computer systems. The laptop PC will contain the TTCI
enforcement algorithm test application.
The enforcement algorithm will collect train status data, including train speed, position, head end
brake pipe pressure, tail end brake pipe pressure as reported by an EOT device, dynamic brake
voltage, dynamic brake setup status, and locomotive notch. This train status data will be
collected by the enforcement algorithm application, in real time as the test is run, and used to
enforce penalty and emergency brake applications, as necessary, to avoid a target overrun. The
enforcement algorithm test application will also be used to record the data throughout each test
for use in determining when the brakes were applied, where the train stopped, etc.

Notch
EOT
Notch
Device
Speed/Locatio
n
Tail End BPP
Speed/Location
Misc. Hardware
Algorithm
Headend PC Bits
BPP
Discrete
Head
Head
End
EndBPP
BPP Heath Status
Notch/Speed
Penalty
Head/Tail
BrakeEnd
/ BPP
Penalty Brake Tail End BPP Penalty Brake
Application Brake
Emergency Brake
Dynamic Penalty Brake / Emergency
Application Application Application
Dynamic Brake
Dynamic
Brake Brake
Application
GPSEnd
Tail Antennae
BPP
Test Car
GPS Antennae

Location
Location
Emergency
Brake Tail End BPP
Emergency Brake Dynamic

Figure 1 –Test Configuration

The field testing will test the enforcement algorithm over a number of test scenarios, which will
cover a range of operating conditions. The test scenarios are determined by varying the
following independent test variables:
• Consist – The field tests will use a test consist made up of a combination of empty
manifest freight cars from the Union Pacific Railroad (UPRR) and loaded
hopper/gondola cars from the Facility for Accelerated Service Testing (FAST). The
length of the consist is specified for each test scenario as one of the following:
▬ Long – 90 to 100 cars (based on availability of cars)
▬ Medium – 40 cars
▬ Short – 10 cars
• Track – The approximate track grade over the braking distance:
▬ Flat – 0% grade

280
 ▬ Decline – -1.47% grade
▬ Incline – 0.34% – 1.01% grade
▬ Crest – 0.79% incline transitioning to a -0.62% grade
• Speed – The target train speed at the time enforcement braking is activated.
• Brake state – The state of the air brake system at the time of enforcement:
▬ Fully charged – the brake system is in the fully released/charged state
▬ Applied – a service application is made prior to the PTC penalty enforcement
• Type of test – The system objective to be evaluated by the test scenario:
▬ Safety – Test to ensure the enforcement algorithm stops the train short of the
target or authority limit by running the train at the test speed toward the target
until enforcement stops the train.
▬ Performance – Test to ensure the algorithm does not interfere with normal
train handling by running the train at the test speed toward the target and
having the locomotive engineer bring the train to a stop using normal train
handling procedures.
▬ EBB-Safety – Test to ensure that the emergency brake backup routine stops
the train short of the target when penalty braking is insufficient to do so. This
situation is forced by having some locomotives continue to apply tractive
effort after penalty braking is invoked.
The specific test cases are listed in Table 1. Tests will be run multiple times to evaluate
repeatability, up to three tests per test case. Each test case will be performed using the base case
algorithm as well as the developmental algorithm.
For the EBB-Safety test case, the emergency brake back-up function of the enforcement
algorithm will be evaluated. For this test case, the train will be artificially forced to overrun the
target by a small margin following the penalty enforcement to evaluate whether the emergency
brake back-up function enforces an emergency brake application to stop the train short of the
target. This is achieved by maintaining the throttle on the locomotives following the penalty
brake application.
Table 1 –Test Scenarios
Test Consist Track Speed Brake State Type of Target Number of
Case Test Runs
1 Long Flat 10 Fully Safety R24 3
Charged
2 Long Flat 10 Fully Performance R24 2
Charged
3 Long Flat 30 Fully Safety R24 3
Charged
4 Long Flat 60 Fully Safety R24 2
Charged
5 Long Decline 30 Fully Safety R14 3
Charged
6 Long Decline 30 Applied Safety R14 2
7 Long Decline 30 Fully Performance R14 2
Charged
8 Long Decline 10 Fully Safety R14 2
281
 Charged
9 Long Incline 30 Fully Safety R48 2
Charged
10 Long Crest 30 Fully Safety R69 2
Charged
11 Long Flat 30 Fully EBB -safety R24 3
Charged
12 Med Flat 30 Fully Safety R24 2
Charged
13 Med Decline 60 Fully Safety R14 2
Charged
14 Med Decline 60 Fully Performance R14 2
Charged
15 Short Flat 30 Fully Safety R24 3
Charged
16 Short Flat 30 Fully Performance R24 2
Charged
17 Short Decline 30 Fully Safety R14 3
Charged

For each test, the train will be moved to the starting position appropriate for the specific test
case. The train will then be accelerated to the specified test speed and proceed towards the target
stopping location, with the enforcement algorithm monitoring the speed, location, dynamic brake
voltage, train acceleration, and brake pipe pressure of the train.
For the safety tests, when the enforcement algorithm determines that a penalty brake application
is necessary, the LCU will apply the penalty brake. When this occurs, the locomotive engineer
will bail off the locomotive brakes. If the locomotive is in dynamic brake at the time the penalty
is applied, the locomotive engineer will maintain the setting of the dynamic brake throughout the
stop. If the locomotive is in throttle at the time the penalty is applied, the locomotive engineer
will move the throttle to idle. In the case of the emergency brake backup test, the locomotives
will maintain the throttle setting until the emergency brake is applied.
For the performance tests, the locomotive crew will stop the train prior to the target using normal
train handling procedures. The enforcement algorithm may or may not enforce a penalty brake
application in these test cases.
Once the train has stopped, the absolute stopping location will be recorded and the location
relative to the target will be measured and recorded before resetting the train for the next test run.
4.2.2 Validation Testing
N/A
4.2.3 Endurance Testing
N/A
4.2.4 Safety Margin Tests
N/A
4.3 Operation Locations
282
The stop tests will occur at various locations, as per Table 1, around the Railroad Test Track
(RTT), located at the Transportation Technology Center (TTC) in Pueblo, CO.
4.4 Special Support
N/A
4.5 Instrumentation Types
See section 5.0.
4.6 Measurement Definitions
The following measurements will be taken during the field test for each test run:
• Penalty enforcement location. The location in footage relative to a specific point on the
track will be measured by the LCU and recorded by the enforcement algorithm software
once the train has received a penalty application.
• Emergency enforcement location. If the emergency brake is enforced, the location in
footage relative to a specific point on the track will be measured by the LCU and
recorded by the enforcement algorithm software once the train has received the
emergency application.
• Stopping location. The location in footage relative to a specific point on the track will be
measured by the LCU and recorded by the enforcement algorithm software once the train
has come to a stop.
• Stopping location relative to the target. The difference in footage between the stopping
location and the target location will be calculated in post-processing.
• Stopping distance. The difference in footage between the point of penalty brake
application and stopping location will be calculated in post-processing.
4.7 Data Collection Schematics
None.
5.0 Instrumentation Identification
5.1 On-Board Instrumentation List
The on-board instrumentation includes:
• Locomotive control unit (LCU)
• Laptop computer containing enforcement algorithm software
• Locomotive brake pipe pressure transducer
• GPS antennas
• Penalty brake valve
283
 • Emergency brake valve
• Brake pipe pressure transducer located on the last car of the train
• Brake cylinder pressure transducer located on the last car of the train
• Unmanned data acquisition computer (UDAC) located on the last car of the train
5.2 Wayside Instrumentation List
None.
5.3 Special Instrumentation List
A hand-operated tribometer will be used for recording rail coefficient of friction at test locations
around the RTT.
6.0 Photography and Video
6.1 Photography Requirements
None.
6.2 Video Requirements
None.
7.0 Transportation Technology Center, Inc. Requirements
7.1 Facility Requirements
None.
7.2 Track Requirements
The enforcement algorithm will be tested at various locations, as per Table 1, around the 13.5
mile Railroad Test Track (RTT) at the Transportation Technology Center (TTC). Other tracks
may be needed for switching and storage of test cars.
7.3 Labor/Personnel Requirements
The following personnel will be required to setup, perform, and analyze the results from the tests
planned:
• Test engineer(s): The test engineer(s) will be responsible for organizing and managing
the test activities, including providing test plans, procedures, and data sheets to test
personnel, and ensuring test activities can be performed in a safe manner. It will also be
the responsibility of the test engineer(s) to oversee setup of the instrumentation, running
the enforcement algorithm software, and recording or ensuring necessary data is
recorded. Post test, the test engineer(s) will analyze the data collected for use in other
tests and future developments of the enforcement algorithm.
• Test controller: The test controller will be in charge of the actual tests and all movements
of the test consist. This includes ensuring all safety rules, test plans, and other
instructions are followed by all test personnel. The test controller will be the point of
284
 communication between the test engineers and the locomotive engineer and any other test
personnel. The test controller will coordinate all train moves with the proper personnel in
the Operations Control Center (OCC), and ensure safe test conditions at all times.
Finally, the test controller will keep a detailed log of the test activities.
• Locomotive engineer: The locomotive engineer will execute train moves as necessary for
test setup, switching, and test functions.
• Instrumentation engineer(s): The instrumentation engineer(s) will work closely with the
test engineer(s) to set up all test instrumentation, and ensure the proper operation of the
instrumentation and data collection system during testing.
7.4 Equipment Requirements
The following equipment will be required for the field tests:
• Four locomotives, including at least one of the three locomotives equipped with the
necessary LCU used for enforcement algorithm testing
• Approximately 80 empty manifest freight cars (mix of car types) borrowed from the
UPRR
• 20 loaded test cars from the Facility for Accelerated Service Testing (FAST) train
7.5 Material Requirements
None.
7.6 Special Requirements
None.
8.0 Restoration and/or Dismantling
8.1 Facility Restoration
None.
8.2 Track Restoration
None.
8.3 Equipment Disposition
None.
8.4 Material Disposition
None.
8.5 Special Equipment Disposition
None.
9.0 Data Requirements

285
 9.1 Data Types
The following data will be collected during this field test:
• Locomotive location
• Locomotive speed
• Locomotive brake pipe pressure
• Locomotive notch
• Dynamic Brake Voltage
• Dynamic Brake Setup Status
• Train brake pipe pressure at last car in train
• Train brake cylinder pressure at last car in train
• Specific test consist makeup
9.2 Recording Techniques
Locomotive location, speed, brake pipe pressure, dynamic brake data, and locomotive notch will
be collected once per second by the locomotive control unit (LCU). Train brake pipe pressure
and brake cylinder pressure from the last test car will be collected at 256 Hz using an unmanned
data acquisition computer (UDAC).
9.3 Data Analysis
The data collected will be used to evaluate the performance of the enforcement algorithm. The
results of each test will be compared against the safety and performance objectives for the test
scenario, and used to validate the results of simulation testing that will support the evaluation of
the algorithm against these objectives.
The actual brake pipe and brake cylinder data, stop distance and stop time will also be compared
to the prediction data from the enforcement algorithm to determine the accuracy of the prediction
and identify any flaws in the algorithm logic that need to be investigated.
9.4 Reports
Documentation of the field test will be included in a final report for the project.
10.0 Safety
TTCI has a very successful safety record. Strict operating and safety rules will be followed
during the work described in this proposal.
A pre-test meeting will be held before any physical work is started. Safety and quality issues
will be addressed at this meeting.
A safety and job briefing will be held prior to start of testing each day, with subsequent job
briefings throughout the day if required by a change in the work plan.

286
11.0 Work Schedule
The field testing is planned for the week of November 28, 2011. However, if the test cars are not
available at this time, the testing will occur in December, 2011.
12.0 Quality Assurance
TTCI is committed to providing products and/or services that meet and/or exceed the customers’
specified contractual and project requirements. TTCI recognizes that in order to provide and
maintain a consistently high quality in the work it undertakes, an effective Quality Management
System is necessary so as to ensure that proper communication, work control and accountable
records are generated for all work undertaken.
It is the policy, therefore, of TTCI to control and conduct its business of consultancy and test
services in the railway transportation arena by means of a formalized system of modern quality
management that conforms to the requirements of ISO 9001–2000. Through the QMS, TTCI is
able to ensure that our products and services meet or exceed our customers’ expectations.
In order to ensure our entire organization supports the quality process, TTCI sponsors an
employee led Quality Resource Team (QRT). The mission of the QRT is to “To promote
customer satisfaction by providing effective training, education, and communication tools for
Team TTCI.” The QRT works directly with TTCI’s marketing team to identify customer
satisfaction issues and help resolve them. The QRT also provides period refresher training to
TTCI employees in science of Continuous Quality Improvement, Customer Satisfaction, and the
implementation of problem solving tools.
13.0 Support Specialties
N/A

287
 Task Order 242: Development of a PTC Enforcement
Algorithm for Freight Trains

Testing of Available Locomotive Data and Interfaces

Field Test Implementation Plan

November 2011

Approval:________________________________________
Jared Withers, COTM Date

Presented By:
Transportation Technology Center, Inc.
A Subsidiary of the Association of American Railroads
55500 D.O.T. Road
P.O. Box 11130
Pueblo, Colorado, USA 81001

288
1.0 Project Title
Development of an Implementation-Ready Enforcement Braking Algorithm for Freight Trains
2.0 Introduction
The objective of this test is to evaluate the data and interfaces available on various types of
locomotives to determine their applicability to PTC enforcement algorithm stopping distance
prediction.
Positive Train Control (PTC) is an emerging train control technology intended to enhance safety
and possibly improve train performance and plant capacity. The underlying concept of the
technology is that movement authorities are transmitted digitally to the controlling locomotive of
each train. The locomotive tracks the train’s location with respect to its authority and speed
limits and the train’s stopping ability based on known and assumed train parameters and current
status, and automatically applies brakes to prevent the train from violating any limit in the event
of human failure. Enforcement braking is an event of last recourse when the locomotive
engineer has failed to take adequate action.
The primary objective of this research program is to identify and test methods for improving
enforcement algorithm performance. As such, a number of modifications to a base case
enforcement algorithm have been investigated and tested as part of this program.
Part of the third phase of work under this task order is a study of the data types and interfaces
available on various types of locomotives. It is recognized that the enforcement algorithm may
require certain data elements from the locomotive system, or that the performance of the
enforcement algorithm may be improved with these data elements. It is also recognized that
various types and vintages of locomotives are used in the industry, and that the enforcement
algorithm may need to work on any or all of these types of locomotives.
The study has identified a number of data elements and interfaces that are universally available
for all locomotives. These primarily consist of data and interfaces to the brake systems and data
signals available on the 27-pin MU cable. Two data elements that are not generally required by,
but may improve the performance of, the enforcement algorithm are tractive effort and dynamic
brake effort. On newer locomotives, this data is potentially available from the locomotive
computer, in various forms. The objective of this test is to collect this data and evaluate its
potential use in PTC enforcement algorithms.
2.1 Key Personnel
Customer Contact, Ruben Pena, Assistant Director, Business Acquisition / DC
Telephone: 719-584-0543
Fax: 719-584-0770
Email: [email protected]
Program Manager, Dingqing Li, Scientist and Chief Government Programs
Telephone: 719-584-0740

289
Fax: 719-584-0791
Email: [email protected]
Project Manager, Joe Brosseau, Senior Engineer II
Telephone: 719-584-7128
Fax: 719-584-0771
Email: [email protected]
2.2 Responsibilities
The project manager for this project is Joe Brosseau. He is responsible for ensuring that the test
is completed on time, within budget, and will ensure all deliverables meet or exceed FRA
requirements. He will also be responsible for ensuring that the test is executed according to the
test plan, that all data is collected properly, and that the test is completed safely.
2.3 Documentation
The results of this test will be documented within the final report for this project.
3.0 Preparation
In preparation for field testing of the enforcement algorithm, the following tasks will be
completed:
• Test locomotive setup/checkout. This task primarily consists of working with the
locomotive manufacturer to setup the each test locomotive computer to collect the
appropriate data elements.
• Test car setup. A test car will be equipped with an instrumented coupler to measure the
force on the coupler at the rear end of the locomotive consist. This task includes
installing the instrumented coupler, as well as setting up the data acquisition system to
collect the coupler force data.
4.0 Implementation
4.1 Constraints
None.
4.2 Operation Sequence
4.2.1 Track Testing
The goal of the on-track testing will be to collect tractive effort and dynamic brake effort data
from the test locomotives along with coupler force data from the trailing coupler of the
locomotive consist. The data collected can then be analyzed in various ways to determine how it
could potentially be used in enforcement algorithm stopping distance predictions.
The track testing will consist of two components. In the first component, data will be collected
from the test locomotives during normal operations at the Facility for Accelerated Service
290
Testing (FAST). The FAST train consists of three locomotives (an EMD SD70MAC and two
EMD SD70M) and 80 – 115 loaded hopper/gondola cars. The FAST train operates on a 2.7-mile
loop known as the high tonnage loop (HTL). The data collected during this component of testing
will be used to identify a general level of accuracy, given multiple locomotives, including
various types, in a full train application over multiple hours of continuous operation, and other
associated operating scenarios.
The second component will consist of collecting data under specific operating conditions with
specific locomotives. In this component, AC and DC locomotives will be evaluated separately,
in operating scenarios including continuous pulling up a grade (measuring tractive effort), and
constant braking down a grade (measuring dynamic brake effort). This component of testing
will be performed on the train dynamics track (TDT). The consist will include a single
locomotive and 30 loaded cars from the FAST consist. The data collected during this component
of testing will identify a general level of accuracy for a single locomotive in a specific operating
scenario. This will help to identify a high level view of relative accuracy from locomotive to
locomotive, as well as differences between AC and DC locomotives. Each test scenario will be
run multiple times to provide repeatability data for comparison and to increase the overall data
set.
The test scenarios are listed below in table 1, below.
Table 1 –Test Scenarios
Test Locomotives Consist Track
Case
1 All FAST Full FAST HTL
Locomotives Consist
2 1 SD70M (DC) 30 FAST cars TDT (incline)
3 1 SD70MAC (AC) 30 FAST cars TDT (incline)
4 1 SD70M (DC) 30 FAST cars TDT (decline)
5 1 SD70MAC (AC) 30 FAST cars TDT (decline)

4.2.2 Validation Testing

N/A
4.2.3 Endurance Testing
N/A
4.2.4 Safety Margin Tests
N/A
4.3 Operation Locations
The testing will occur at the Transportation Technology Center (TTC) in Pueblo, CO. The first
component will use the HTL, and the second component will use the TDT, as described in
section 4.2.1.

291
 4.4 Special Support
N/A
4.5 Instrumentation Types
See section 5.0.
4.6 Measurement Definitions
The following measurements will be taken during the field test for each test run:
• Tractive effort/dynamic brake effort. The computed pulling or braking force generated
by each locomotive.
• Coupler force. The draft or buff force at the lead coupler of the car immediately adjacent
to the locomotive consist.
4.7 Data Collection Schematics
None.
5.0 Instrumentation Identification
5.1 On-Board Instrumentation List
The on-board instrumentation includes:
• Onboard computer that computes tractive/dynamic brake effort on each locomotive
• Locomotive data acquisition system that collects tractive/dynamic brake effort data from
the onboard computer
• Instrumented coupler that measures coupler force on the lead coupler of the car
immediately adjacent to the locomotive consist
• Unmanned data acquisition computer (UDAC) located on the locomotive for collecting
instrumented coupler data
5.2 Wayside Instrumentation List
None.
5.3 Special Instrumentation List
None.
6.0 Photography and Video
6.1 Photography Requirements
None.
6.2 Video Requirements
None.
292
7.0 Transportation Technology Center, Inc. Requirements
7.1 Facility Requirements
None.
7.2 Track Requirements
The testing will utilize the HTL and the TDT at the Transportation Technology Center (TTC).
Other tracks may be needed for switching and turning the test consist.
7.3 Labor/Personnel Requirements
The following personnel will be required to setup, perform, and analyze the results from the tests
planned:
• Test engineer(s): The test engineer(s) will be responsible for organizing and managing
the test activities, including providing test plans, procedures, and data sheets to test
personnel, and ensuring test activities can be performed in a safe manner. It will also be
the responsibility of the test engineer(s) to oversee setup of the instrumentation, and
recording or ensuring necessary data is recorded. Post test, the test engineer(s) will
analyze the data collected.
• Test controller: The test controller will be in charge of the actual tests and all movements
of the test consist. This includes ensuring all safety rules, test plans, and other
instructions are followed by all test personnel. The test controller will be the point of
communication between the test engineers and the locomotive engineer and any other test
personnel. The test controller will coordinate all train moves with the proper personnel in
the Operations Control Center (OCC), and ensure safe test conditions at all times.
Finally, the test controller will keep a log of the test activities.
• Locomotive engineer: The locomotive engineer will execute train moves as necessary for
test setup, switching, and test functions.
• Instrumentation engineer(s): The instrumentation engineer(s) will work closely with the
test engineer(s) to set up test instrumentation, and ensure the proper operation of the
instrumentation and data collection system during testing.
7.4 Equipment Requirements
The following equipment will be required for the field tests:
• FAST locomotives
• Loaded cars from the FAST train
7.5 Material Requirements
None.
7.6 Special Requirements
None.
8.0 Restoration and/or Dismantling
293
 8.1 Facility Restoration
None.
8.2 Track Restoration
None.
8.3 Equipment Disposition
None.
8.4 Material Disposition
None.
8.5 Special Equipment Disposition
None.
9.0 Data Requirements
9.1 Data Types
The following data will be collected during this field test:
• Locomotive location
• Locomotive speed
• Locomotive notch
• Computed locomotive tractive effort
• Computed locomotive dynamic brake effort
• Coupler force at the lead coupler of the car adjacent to the locomotive consist
9.2 Recording Techniques
Locomotive location and speed will be determined using GPS and recorded by the UDAC at a
frequency of 1 Hz. Coupler force data will also be recorded by the UDAC at a frequency of 100
Hz. Locomotive notch, tractive/dynamic brake effort, and other associated data will be recorded
by the locomotive computer data acquisition system at a frequency of 10 Hz.
9.3 Data Analysis
The tractive/dynamic brake effort data will be analyzed against the coupler force data for each
test scenario to provide an indication of the level of accuracy, and associated potential benefits to
the stopping distance prediction, given the various test conditions. Comparisons will be made
between operating with multiple units, as well as with each unit individually. Comparisons will
also be made between the measurements on the AC locomotive and the DC locomotives. This
will not be a comprehensive analysis, but rather a conceptual look at the capabilities that may be
available.
9.4 Reports
294
Documentation of the field test will be included in a final report for the project.
10.0 Safety
TTCI has a very successful safety record. Strict operating and safety rules will be followed
during the work described in this proposal.
A pre-test meeting will be held before any physical work is started. Safety and quality issues
will be addressed at this meeting.
A safety and job briefing will be held prior to start of testing each day, with subsequent job
briefings throughout the day if required by a change in the work plan.
11.0 Work Schedule
The field testing is planned for the weeks of November 21, 2011 and November 28, 2011.
Scheduling of other test activities may alter the exact test dates.
12.0 Quality Assurance
TTCI is committed to providing products and/or services that meet and/or exceed the customers’
specified contractual and project requirements. TTCI recognizes that in order to provide and
maintain a consistently high quality in the work it undertakes, an effective Quality Management
System is necessary so as to ensure that proper communication, work control and accountable
records are generated for all work undertaken.
It is the policy, therefore, of TTCI to control and conduct its business of consultancy and test
services in the railway transportation arena by means of a formalized system of modern quality
management that conforms to the requirements of ISO 9001–2000. Through the QMS, TTCI is
able to ensure that our products and services meet or exceed our customers’ expectations.
In order to ensure our entire organization supports the quality process, TTCI sponsors an
employee led Quality Resource Team (QRT). The mission of the QRT is to “To promote
customer satisfaction by providing effective training, education, and communication tools for
Team TTCI.” The QRT works directly with TTCI’s marketing team to identify customer
satisfaction issues and help resolve them. The QRT also provides period refresher training to
TTCI employees in science of Continuous Quality Improvement, Customer Satisfaction, and the
implementation of problem solving tools.
13.0 Support Specialties
N/A

295
Appendix F.
Developmental Enforcement Algorithm Definition Document

296
Appendix G.
Detailed Simulation Results from Evaluation of Base Enforcement
Algorithm

348
Appendix H.
Detailed Simulation Results from Evaluation of Phase 1
Developmental Enforcement Algorithm

432
Appendix I.
Detailed Simulation Results from Evaluation of Phase 2
Developmental Enforcement Algorithm

490
Appendix J.
Detailed Simulation Results from Evaluation of Phase 3
Developmental Enforcement Algorithm

548
Appendix K.
Detailed Simulation Results from Evaluation of Wabtec Enforcement
Algorithm with Brake Force Provided

676
Appendix L.
Detailed Simulation Results from Evaluation of Wabtec Enforcement
Algorithm with Assumed Brake Force

848
Abbreviations and Acronyms
AAR Association of American Railroads
AC Alternating current
ALD Automatic location detector
BNSF BNSF Railway
CBTC Communications-based Train Control
CSX CSX Transportation
CTC Centralized Traffic Control
DC Direct current
EDA exploratory data analysis
EMD Electro-Motive Diesel Inc.
ETMS Electronic Train Management System
FAST Facility for Accelerated Service Testing
FRA Federal Railroad Administration
GPD Generalized Pareto distribution
GPS Global Positioning System
GRL gross rail load
HTL High Tonnage Loop
IDOT Illinois Department of Transportation
I-ETMS® Interoperable Electronic Train Management System (I-ETMS® is a
registered trademark of Wabtec
IP Internet protocol
IR&D internal research and development
LDS location determination system
LMC Lockheed Martin Corporation
MU multiple-unit
NAJPTC North American Joint Positive Train Control
NOAA National Oceanic and Atmospheric Administration
NS Norfolk Southern Corporation
PTC Positive Train Control
RTT Railroad Test Track
SIL safety integrity level

1032
TCL test controller/logger
TDT transmission control protocol
TE tractive effort
THR Tolerable Hazard Rate
TIP Test Implementation Plan
TOES™ Train Operations and Energy Simulator (TOES is a trademark of
TTCI)
TTC Transportation Technology Center (the site)
TTCI Transportation Technology Center, Inc. (the company)
UMLER Universal Machine Language Equipment Register
UPRR Union Pacific Railroad
V-PTC Vital-Positive Train Control
WILD wheel impact load detector
Wabtec Wabtec Railway Electronics

1033