Calculating Train Braking Distance

David Barney, David Haley and George Nikandros

Signal and Operational Systems
Queensland Rail
PO Box 1429, Brisbane 4001, Queensland, Australia
david.barney@qr, com. au / david.haleyOqr, com. a u / george, nikandros@qr, com. a u

Despite the obvious criticality of the required braking

Abstract distance, the calculation process traditionally used within
The paper discusses the development of an IBM PC®l based QR, and for that matter most other railways, is not as
tool, for calculating train braking distances for various train robust as it perhaps should be.
classes on a rail network. There is discussion on current industry
practice and the limitations of that practice, the concept of the The purpose of this IBM PC ® based tool is to:
tool itself, including the assumptions made, the strategy adopted • assist the signal designer to provide an adequate
to minimise the risk of incorrect calculations, and the results of
adopting that strategy. distance for the safe stopping of trains operating on a
given line whilst at the same time maximising line
Keywords: train, braking, distance, calculation, railway. capacity;

• put in place controls to ensure that the data used for

1 Introduction
the calculation is verified and traceable, and any
For trains to safely travel on a railway, trains must be changes controlled;
provided with sufficient distance in which to stop.
Allowing too long a distance reduces the capacity of the • allow the ready evaluation of a new train by
line and hence the return on rail infrastructure investment. performing multiple calculations in one execution;
Too short a distance and collisions would occur, because • readily highlight those Limits of Authority that need
the train would not be able to stop within the available to be relocated to allow for changes in speed or train
distance and would therefore occupy a section of track braking performance.
that could be allocated to another train. Consequently it is
important that the distance be adequate, but not overly so. In Section 3 we describe common industry practices and
Figure 1 shows the relationship between braking distance the limitations of those practices. In Section 4 we provide
and "headway" which is a measure of capacity. an overview of the tool requirements and implementation
strategy. In Section 5 we conclude by discussing the
Traditionally, the calculation of the required braking effectiveness of that strategy.
distance is on a per Limit of Authority basis. The task is
further complicated if there are many trains with different
2 Definitions
braking and ride performance characteristics operating on
the same section of track, because for safety, the distance ATP - (Automatic Train Protection) is a predictive
needs to be the longest of all the different trains. The enforcement system which continuously monitors the
calculation needs to be repeated for every train type and speed of a train in relation to either a target speed, which
every approach path to that Limit of Authority. for a Limit of Authority would be zero, or a target
distance, and intervenes such that the train is prevented
Within Queensland Rail (QR), there are currently some
from passing a Limit of Authority or exceeding a speed
40 different train types defined and some 7000 locations
limit.
where trains may be required to stop. For some of those
7000 locations, there are many different approach paths. B r a k i n g D i s t a n c e - is the distance the train travels from
Every time there is a change involving an increase in train when the train driver makes a full-service brake
speed or a reduction in the train braking performance, the application to when the train stops (Fig 1).
calculation must be repeated for every signal involved for
C O T S - (Commercial Off the Shelf) - it is a phrase used
that train type. This often means thousands of
to refer to commercially available products being used
calculations.
"as is".
F u l l - S e r v i c e B r a k e - is the maximum deceleration rate
deceleration so as to minimise the risk of injury to
1 Registered trademark of International Business passengers or damage to goods or cause damage to the
Machines Corporation train.
Copyright © 2001, Australian Computer Society, Inc. This L i m i t o f A u t h o r i t y - is a location along the railway where
paper appeared at the 6 th A u s t r a l i a n W o r k s h o p on Safety
a train's current authority to move ends. It is usually
Critical Systems a n d Software ( S C S ' 0 1 ) , Brisbane. Conferences
in Research and Practice in Information Technology, Vol. 3. P. delineated by a signal, passive sign, or track kilometrage.
Lindsay, Ed. Reproduction for academic, non-for profit
purposes permitted provided this text is included.

23
 F-(X3O FOOO
I G Y I
R I
Sighting Braking Distance Braking Distance Overlap
Distance

Headway Distance

Figure 1 : - Standard 3 Aspect Sequencing used in QR

(The paper relates to the calculation of the distances labelled "Braking Distance")

Train Type - a train is characterised by its maximum the train's acceleration rate (a) (deceleration is negative
permissible speed, its deceleration rate, the time delay for acceleration) and the stopping distance (S).
the deceleration rate to become effective, its length and The change in 'kinetic' energy relates to the change in the
its permission to exceed certain classes of track speed train's speed i.e. the difference of the speed at which
restrictions. Passenger trains and bulk commodity trains deceleration began (U) and the 'at stop' speed i.e. 0.
e.g. coal, mineral, grain have certain nominal lengths
depending on where they operate. General freight trains The change in 'potential' energy relates to the change in
can be of any length up to a specified maximum for a height of the train's centre of mass due to the gradient of
particular line. To cater for this variation 'long' and the track i.e. the difference in height at which
'short' types are defined. Note: The brake delay time deceleration began (hi) and the its height at the stopping
varies with train length - the longer the train, the longer point (h2).
the delay. Mathematically this can be expressed as:
m*(a)*S + V2*m*(U2) + m*g*(hl-h2) = 0 (1),

3 Calculating Braking Distance where 'g' is the acceleration due to gravity and h2 > h~.
Mass is common in all the terms in the equation, and
3.1 Influencing Factors therefore can be cancelled out. This suggests that mass
has no direct effect on the stopping distance. However,
Braking distance depends on:
mass has an effect on the stopping distance as the location
• the speed of the train when the brakes are applied; of the train's centre of mass varies with the mass
distribution. Mass also affects the deceleration rate of a
• the deceleration rate available with a full-service particular item of rolling stock. For freight wagons, where
brake application, which varies according to the the mass can vary from no load to full load, there are two
coefficient of friction between wheel and rail; levels of brake force used i.e. "empty" and "loaded". The
• the delay from when the brakes are commanded by design of the brake system is such that as the load
the train driver to when they are actually become increases, there is a point where the force changes from
effective (brake delay time); "empty" to "loaded". For braking distance calculations
the lowest deceleration rate is used to calculate the
• the state of the wear of the brake pads and the air deceleration rate for the complete train.
pressure available in the brake cylinders;
The change in height relates to the track gradient. The
• the geography of the track, in particular the track track gradient is the change of vertical height over the
gradient the train travels over from when the brakes corresponding change in horizontal distance i.e. tan a
are commanded to where the front of the train stops; where a is the angle o f slope. For small ~t, which is the
case for railways (mountain rack railways aside), tan ct
• the mass distribution of the train.
equals sin a. Sin et is the change in height (h2-h,) over the
stopping distance (S):
3.2 The Effect of Train Mass
(h2-hl) = S ' s i n ct = S ' t a n c~ (2)
Stopping a train requires work. This work equals the
change in the train's kinetic energy plus the change in its Substituting (2) into (1) and rearranging:
potential energy (change in height due to the gradient of
the track). S = (-U2)/2(a-g*tan a), for a < 0 (3)

The 'work' is the energy in decelerating the train over the The term " - g ' t a n a" is the gravitational acceleration. For
stopping distance, i.e. the product of the train's mass (m), uphill track gradients i.e. h2 > hi, gravity assists
deceleration.

24
3.3 Calculation Method Authority, the braking distance required can be directly
read from these graphs.
It is impossible to calculate the precise stopping distance
as this distance can vary significantly due to the condition
3.4 Limitations
of the train and the environmental conditions at the time.
To take the conservative approach, i.e. allow for the worst
case conditions would grossly impact on track asset 3.4.1 Gradient averaging
utilisation. The industry approach is to assume that the Acceleration due to gravity is 9.79mg 2
train's brake system is healthy and that the specified
Using V2 = U 2 + 2aS, the speed of the
adhesion for that class of train is available when the train and the average gradient G,
brakes are required to be applied. the Braking Distance is:

G = 1500/( 12e0/50 +300/-50) = +83.33

Most railways do not take into account the brake delay
Distance to stop from 80km/h is:
time, and further simplify the calculation by using the 1200m 300m
S = (lY - (80/3.6)Z)l(2*a)
average gradient of the track on the approach side of the Train Parameters
where a = -0.3 + 9.79/83.33
= 591m
Limit of Authority. Length = l m
Max Speed= 80km/h
Decel= 0.3 ms"2
Delay=Os

~ Using V z = U 2 + 2aS
~ A v e r a g e gradient "'G" =
The speed of the train at the
D / ( d t / g t + d2/g 2 + ....+ddg n) change of gradient so as to stop

where D = d I + d 2 +.....+ d .
2,/ l 50 I I atthest°po°int
i.e. G = 1500/(1200/50 + 300/-50) I I ] U,oo = SQRT(-2*(-0.3+9.79/SI))*300)
r. ~1. ~ = 7.9ms-i
= +83.33 (1.2%)
d I = 1200m d2= 300m 1200m 300m
Distance to slow to 7.9ms -2 from 80km/h is:
Train Parameters Acceleration $3oo = (7.9 ~ - (80/3.6)2)/(2"a)
Figure 2 - Average gradient concept Length = 1 m due to gravity where a = -0.3 - 9.79/50
Max Speed= 80km/h is 9.79msz = 435m
Decel= 0.3 ms2
Delay= 0 s Braking Distance = 435 + 300 = 735m

To calculate braking distances it is therefore a matter of Figure 3 - Average gradient concept limitations
knowing the train braking parameters for each type of
train and the gradient of the track and apply Newtonian
physics (see equation (3)). From the two diagrams in Figure 3, the braking distance
However to compensate for these simplifications and the calculated using the average gradient approach is some
variable factors, an allowance of 15-20% is usually 144 metres short. It can also be easily demonstrated
added. where gradient averaging can lead to much larger braking
distances than necessary.
This distance is the minimum distance that needs to be
provided. Other factors that will further increase this 3.4.2 Brake delay time
distance are:
Allowing 15-20% does not compensate for ignoring the
• other design constraints e.g. the track layout brake delay time. For example, consider a train that has a
arrangement, level crossings etc; brake deceleration rate of lms 2, and a brake delay time
• the sighting distance to the first warning for the Limit of 5s. Assuming an initial speed of 100km/h and level
of Authority ahead; track, the required braking distance is 524m. Ignoring the
brake delay time, the braking distance would be 385m.
• access to the physical location for installation and Adding 20%, increases this to 462m, i.e. some 62m short.
future maintenance; This is much worse for long trains where the brake delay
time is much longer. A brake delay time of 28s is typical
• suitability of the site to erect its supporting structure.
for QR's coal trains.
There is of course the "last ditch" compensatory factor, in
For "shortish" brake delay times the error is not that
that the train driver is required to "know the road".
significant as there are other factors which compensate:
In the UK, metros and light rail systems aside, signal
• the train driver would normally initiate a brake
designers rely on braking distance speed graphs as
published by Railtrack (1996). These graphs provide the application on sighting the first warning to the Limit
of Authority ahead, which is well before the
braking distance required for a particular train speed over
calculated full-service braking distance location (a
a range of track gradients. These graphs are based on
full-service brake is a fairly severe brake application
specified train brake performance parameters provided by
and train driver's drive more conservatively);
rolling stock engineers. The signal designer merely needs
to determine the "average" gradient of the track on the • there is also retardation due to track curvature and
approach side of the Limit of Authority. Using this viscous drag which is ignored in the calculations.
gradient average value and the maximum speed the train
is allowed to travel on the track approaching the Limit of

25
 3.4.3 Introducing a new train from the Limit of Authority, taking into consideration the
location of the train's centre of mass and its length.
If it can be demonstrated that each of the new train's
parameters are on the "safer" side when compared to any The method of calculating braking distance had been used
other train for which the signalling was designed then the in a somewhat primitive tool for many years. Whilst this
new train can be introduced. "Safer" in this case means: method relies on some simplifying assumptions, in
particular a uniform train mass distribution, the extensive
• the maximum train speed is equal to or less; and experience to date has demonstrated that the results can
• the full-service deceleration rate is equal to or be trusted. This calculation method is fully specified in
greater; and the requirements specification for the PC tool.

• the brake delay time is equal to or shorter; and 3.5.1 Calculation Assumptions
• train length is equal. The method of calculation assumes the following:-
If any of the parameters are not "safer" e.g. the maximum . Gravitational acceleration is 9.79ms 2 for the entire
speed is higher or the brake delay time is longer, then a QR network.
re-calculation of all braking distances is required.
Depending on the intended operating routes, this could • The mass o f the train is uniformly distributed
involve thousands of calculations. throughout the length o f the train i.e. the centre o f
mass is longitudinally in the centre o f the train.
QR has previously not kept records of the data used (There has been some research to support this
braking distance calculations (only the physical location assumption. This has also been supported through
of the Limit of Authorities and the warning to those experience.)
authorities are documented on drawings). This meant that
all the data has to be regathered if calculations needed to • The braking coefficient is not a function o f speed and
be repeated. QR now has procedures to retain these is a constant for a specific train type.
calculation records.
• For the period of the brake delay, there is no
"acceleration" force from either gravity or the train's
3.5 QR brake acting on the train, and after this time has
Prior to the late 1980's, braking distances were calculated elapsed there is full train braking force applied.
as described in Section 3.3, and like most railways • Retardation due to track curvature and viscous drag
ignored the brake delay time. can be ignored.
QR is however somewhat unique, in that, trains with
grossly different performance characteristics operate on 4 Braking Distance Calculation Tool
the same section of track. In general railways, particularly
those in Europe, tend to limit the variability of train 4.1 ImplementationConcept
characteristics on a particular line and therefore can
maximise the capacity of that line. The tool is used in the design process for a railway
signalling application. It is only used when required to
The introduction of ATP in the late 1980's, forced QR to calculate train braking distances.
reconsider the method of determining braking distances,
because it was now necessary to provide sufficient The tool is intended to run on the IMB PC ® platform, the
distance for the ATP system to stop the train. Actually platform used by QR. Due the potential safety
train testing highlighted the inadequacy of previous consequences of an incorrect result, specifically a
practices. Since then, QR has refined the calculation distance that is too short, some diversity has been used as
method to take into account the brake delay time, mass a means of defence against the risk o f such errors due to
distribution and the actual track gradients (as opposed to factors outside of the tool's application. The extent of the
averaging track gradients). diversity is:

Assuming constant gradient track, the braking distance can be • There are two versions o f the tool; one for the
calculated using: Microsoft Windows ®2 environment, the other for the
IBM OS/2 ®3 environment.
S = -(U + b*td)2/2(a + b ) - U*t d - b*tf/2 Both versions are written using the C ++ language.
"U" is the speed of the train when the brake command was issued However C +÷ compilers from different suppliers are
"a" is the acceleration provided by the braking system used.
"b" is the acceleration provided by gravity
"td" is the train's brake delay time
The terms in italics allow for gravity effects during the brake delay.
Figure 4 - Braking distance equation with delay
2 W i n d o w s is a registered trademark of Microsoft
Separate calculations, solving for "S" or "U" as Corporation.
necessary, are done for each gradient working backwards 3 Operating System/2 and OS/2 are registered trademarks
of International Business Machines Corporation.

26
• The development of the each version was undertaken were actioned under a formal review and approval
by different organisations, albeit to a common process. It should be noted that not all requests for change
detailed and specific requirements specification. were accepted. In all those changes raised, there were no
adverse safety issues.
The two versions have been designated as "ISAAC" and
'+NEWTON". Issue 2.0 of the requirements specification was issued July
1998. The development by the undergraduate students
From the user's perspective, each version of the tool
ceased in July 1998.
operates in the same way:
Given the progress at the time, it was clear that
• Input data files (ASCII text) are prepared specifying professional resources were required if the tool was ever
the train performance ("Train" file) and the track to become a reality in the near future.
configuration ("Track" file).
Coincidentally, QR had introduced a process for
• A "Selection" file (ASCII text) is prepared undertaking research and development projects. A formal
nominating the specific train types from the Train research and development submission was prepared. This
file and the specific Limits of Authority from the submission was based on the fact that no such tool was
Track file for which the calculations are required, known to exist in the railway industry and the safety
and the name of the "Output" file. issues associated with such a tool. Suffice to say that the
• Assuming that the input files exist, they are submission was accepted.
syntactically and logically checked for correctness, Formal contracts were let to two different organisations.
and provided there were no errors, the tool will The organisations were 'different' in more than
perform the required calculations for the nominated ownership; one was a specialist software research
train types and limits of authority. organisation with limited railway domain knowledge; the
• The tool will create the output file with the specified other was railway domain research organisation, with
name containing the source listing of the input files some software engineering ability.
and the results. Whilst the tool requirements specification specified the
Both ISAAC and N E W T O N versions of the tool need to key requirements, the contract also specified key
be used before any calculated result can be accepted. The standards, which the developers were expected to observe.
process requires formal review of the input source data Specifically EN 50128 was specified. The contract also
and the results from both tools. This review also includes included the follow clause:
a 'reasonableness' test of the calculated result. "The C ++ language contains some features and
practices which should not be used for safety-
4.2 Implementation Experience related applications. One such reference is the
publication C ++ in Safety Critical Systems by
The project began with the production of the requirements
Binkley, David W., NISTIR 5769, November 1995.
specification. This largely involved documenting the
Such features and practices should not be used for
essential features of the latest evolved prototype and
this development. "
introducing features to overcome the severe limitations of
this prototype. Formal reviews were held involving From the contractor's perspective the compliance
appropriate subject matter experts. Issue 1.0 of the requirement with EN 50128 was very much limited to the
requirements specification was issued February, 1998. detailed design and coding phases. The safety case and
The requirements specification, did not specify the safety acceptance testing were excluded from the contracts.
requirements, but did specify the requirement for two
Acceptance testing was undertaken by QR. Tests were
diverse tools and the language C ++. At that stage no formal
devised to check each feature specified in the
safety analysis had been done, however based on the
requirements specification. In addition, simple scenarios
engineering judgement of those involved with reviewing
were devised to verify the correctness of the calculation.
the requirements specification at the time, it was clear that
The tool output was compared with hand calculated
diversity was the only practicable defence against the
results.
COTS products for the development and eventual use of
the tool. During this phase of the project six further Change
Requests were raised which resulted in Issues 3.0, 4.0 and
Due to resource constraints the development of the tool
5.0 of the requirements specification being issued. The
was deferred, although there was an ever-increasing need
changes arose during acceptance testing:
to progress it. This development was put forward and
accepted as an undergraduate software engineering • CR15 - this change related to the parameter range of
student project. Two students were engaged to develop, a user definable parameter.
independently, the two diverse tools. The development
process was managed under a Quality Management • C R I 6 - this change related to the method of
System (Certified to AS 9001). Whilst this did not lead to calculation where there were track related speed
the creation of the tool, it did highlight some errors and changes within braking distance to a target. (The
inconsistencies in the requirements specification. Fourteen specification was too conservative in this instance.)
formal "Change Requests" (CR's) were raised. These

27
 • CRI7, 18, 19 & 20 - change to correct inconsistency The analysis shows (Figure 5) that the diversity in the
and some ambiguity in relation to "errors" and tool virtually eliminates those results which are not the
"warnings". same from each tool. The major cause of the hazard stems
from when the results are the same.
Whilst there have been no adverse safety errors
identified, the identification of the error corrected by
Change Request CR16, did highlight the ease in which
errors in interpreting requirements specifications can
arise. One version of the tool agreed with the hand
calculated result; the other version of the tool did not. On
investigation, the tool which did not agree, had
interpreted the requirements specification as had been
intended, although in doing so failed to satisfy another
(conflicting) requirement. The other tool did not. The
hand calculation was based on the tester's opinion as to
what should be the correct result. In this case, the [] []
requirements specification was incorrect.
/ \ / \
Page 3 Page 8
4.3 Language Selection
The choice of C ++ was largely a matter of practicality. QR
has considerable in-house expertise as the language is
used for other applications. Its widespread use within the
Information Technology community also meant that there Page 4 Q=0.8
Q=O.8
would be a reasonable pool or resources available at least
for the foreseeable future.
Figure 5 - Top Event - Braking distance wrong.
The language 'C' is listed in standards such as
CENELEC EN 50128 as a useable language, albeit with Figure 6 shows that the major cause of the hazard stems
limitations. Whilst 'C' is very much a procedural from the accuracy of the raw track and train data. This is
language, C ++, being an object-orientated language, outside the scope of the tool, but it highlights the
allows for well-structured software. importance of having the correct raw data. The tool
Because of the popularity of C ++, there was a choice of provides little defence against incorrect raw data.
sources available for the intended operating systems. This Figure 6 also shows that it is unlikely that identical results
provided some confidence that the language compilers would occur due to different tool implementation errors.
would be somewhat diverse.
It was for these reasons that C ++ was selected.

4.4 The Hazards

Applying the calculated braking distances on a railway
provides the potential for hazards to exist. There are
essentially two "hazards"; one is safety related, the other
~ Page 2

commercial. The safety-related hazard is a calculation of

a braking distance which is shorter than required, whereas
the commercial hazard occurs in a calculation of a
braking distance which is much longer than required. In
essence a wrong braking distance is the common
"hazard". Isaac not
correct ~ Newtonhave

4.5 Causal Analysis

,saacWrong~] ~
Causal Analysis was performed for the hazard "Braking
distance wrong" using the Fault Tree Analysis technique, Q=O.01 Page7 Page6 Page5 O=l e-O06
Q=O.Ol Q=te-6
to identify the causes that have the greatest impact and to
provide some measure of the level of trust that one could Figure 6 - Gate "Results the same but wrong".
place on the tool's results.
The tool used was FaultTree+ for Windows ®. The Figure 7 shows the impact of having a common
modelling attempted to consider all plausible causes, requirements specification and the roles of the designer
including those external to the tool e.g. the accuracy of and design checker.
the raw input data, and the roles of the designer and
design checker.

28
 Inputdata • Ignoring the issue of the accuracy of the raw data, the
wrongbut probability of the hazard occurring increase by some 4
accepted i
orders of magnitude if there were no diversity. In fact the
-e- ! tool itself becomes the greatest cause contributor.
The analysis clearly shows that without diversity, it
would be difficult to trust the results of the tool.

5 Conclusion
Q=0.1 Q=O.01 Calculating train braking distance is not without some
Q=0.1 Q=O.01
Is~ Ion uncertainty. The complex nature of the many and varied
defenc ~=sfail defenc esfail
factors necessitates the making of simplifying
% E18
assumptions. However the limitations of those
assumptions need to be catered for.
The use of computers to perform design calculations is
Latent Isaac LatentNewton
~~implementation
defect implementation not new. Their limitations, other than perhaps their
numerical accuracy, is often not recognised.
There was significant effort in the formulation of the
Q=O.O001 Q=O.OJ Q=O.O001 Q=O.01 requirements specification. The process of formal reviews
and change management were effective. However, this
Figure 7 - Gate "Input data wrong and accepted" still resulted in a number of inconsistency errors. The
evolutionary process through numerous prototypes was a
major influence on the definition of the requirements.
Figure 8 is included to show the "non-common" mode Without that process, it would not have been possible for
causes of failure for a tool version considered in the the requirements specification to be as comprehensive.
analysis.
The Causal Analysis re-affirmed the need for diversity.
The implementation strategy in contracting out the
development of the two diverse tools to different
organisations was justified. Acceptance testing was made

~
much easier due to the fact that the same input data is
used for both versions, and that the error handling and
Page 3,4,8 output requirements were specified comprehensively.
Some implementation errors have been found in both
tools. However none were found to be exactly the same.
LatentI~aac saacoperating The fact that none of these errors were the same gives
~ ~ com
erlpi defect ~9/slernerror
~ some confidence in the degree of diversity of the tools.
The project timescales were much longer than envisaged.
This was largely due to there being no "formal" project
Q=O.01 Q=O.01 0=0.01 Q=O.O1
0=0.01 0=0.01 Q=-O.01 Q=O.01 and hence no funding until late in the tool's evolution.
The evolutionary process was essentially a "spare time"
Figure 8 - Gate "Isaac not correct". activity.

6 References
The quantification of basic events, particularly those that
RAILTRACK PLC (Safety & Standards Directorate),
relate specifically to each version of the tool e.g. Figure
Railway Group Standard (May 1996), Lineside Signal
8, was not based on any robust analysis process. Whilst
Spacing, GK/RT0034, Issue 1.0, May 1996, London.
these are potential sources of tool to 'failure', the
quantification relates only to those errors which actually
CENELEC (European Committee for Electrotechnical
allow the tool to execute to completion and produce Standization EN 50128, Railway Applications -
erroneous results. These erroneous results would only Software for Control and Protection Systems
manifest themselves when the input data evokes the
defect. Whilst each tool function was tested, the
combinational variation of train and track features made it
impossible to test exhaustively. The quantifications were
determined through peer discussion.

29