The train model describes all physical parameters of the train, that are necessary to calculate the brake intervention limits and derived limits.
For trains that usually operate in a foreseeable train configuration with known brake characteristic (like EMUs or DMUs), these parameters can be determined in the development phase and stored in the ERTMS/ETCS on-board. Those trains are called fixed trains. The values AD(V ) are calculated and measured in the design phase of the train, whereupon the limits V 1, …, V m can be selected in such way, that the actual deceleration curve a(v) is best approximated. The brake model defined like this does not yet consider
Let’s call this brake model the Nominal Brake Model. The particular nominal brake model for the brake system being completely operating is called Master Nominal Brake Model.
The effects of point 1 and 2 are modelled in correction factors Kdry_rst, that need to be defined for each speed range and ten Emergency Brake Confidence Levels, EBCL0 to EBCL9, leading to Kdry_rst(V,EBCL). Thus there is in fact not only one brake model but ten for the same physical train configuration. The brake model for EBCL=0 is the nominal brake model, the brake models for EBCL>0 are called Safe Brake Models. Which of the ten models is to be used is determined by the track-side, sending the required confidence level in variable M_NVEBCL.
In [Subset 026-3] no correction factor is defined for the brake build-up time Tbu, nevertheless some parts of the brake system (namely the ep-brake system) only effect the build-up time. Therefore it makes sense to correct also this parameter by a factor KT_rst(EBCL).
To make things even more complicated, the brake model can change while running not only due to a change of the EBCL, but also because some special brakes can be inhibited and re-enabled by track-side command. Therefore multiple brake models need to be defined for the different configurations of the train brake system, out of them exactly one needs to be selected by the vehicle control (or brake control) while running according to the status of the special brakes.
Thus in fact an ”overall brake system status” needs to be determined by the vehicle and to be handed over to the ERTMS/ETCS on-board. This is done by the Brake Model Index (BMI). The BMI needs to reflect the status of the special brakes (as required in [Subset 026-3]), but obviously it can also encode additional information such as unavailable parts of the brake system that are already known (e. g. as the result of the start-up brake test), or the train configuration (one consist, two consists coupled etc.).
The lower bits of the brake model index have a fixed meaning, since they shall always code the status of the special brakes as defined in [Subset 034]. Therefore their name, sequence and size (1 bit) cannot be changed. All other bits of the brake model index can be used without restrictions in principle. Nevertheless it makes sense to arrange the information represented by the BMI in a specific manner for two reasons:
To get complete here, it shall be mentioned, that also the effects of point 3 are considered in the calculation of braking distance, therefore correction factors Kwet_rst(V) are defined for each speed range. In contrary to the Kdry_rst(V, EBCL) they do not depend on the EBCL and thus Kwet_rst(V) is identical for each nominal brake model and the related 9 safe brake models.
Thus finally the deceleration used in the calculation of the braking distance is given according to [Subset 026-3], paragraph 3.13.6.2.1.4 as
A_brake_safe(V, d) = | A_brake_emergency(V, d) ⋅ Kdry_rst(V, M_NVEBCL) | ||
⋅![]() ![]() |
All values used for the calculation of the braking distance except of the so called ’national values’ M_NVEBCL and M_NVAVADH need to be calculated in the engineering process.
Each ETCS emergency brake model in fact consists of 10 brake models:
The brake model index (BMI) is the same for EBCL=0…9.
The Master Nominal Brake Model is the brake model for EBCL=0 and all brakes available. It has no specific meaning outside the engineering process, thus it is not noticeable in the set of brake models or the brake model index. In the set of brake models created by ETCS Brake Model Tool, it will be the one with the highest BMI.
The brake model can change while running due to change of EBCL or BMI. The BMI can change while running for different reasons, e. g. due to inhibition/re-enabling of special brakes or brake failures. ERTMS/ETCS on-board will not stop the train if the brake model changes, except if there is no brake model available for the new BMI (should not happen), or the new brake model cannot ensure sufficient deceleration for the given EBCL and the track profile. If someone sees a need to stop the train for the driver to do something, this is outside the scope of ETCS, thus the brake system or vehicle control must stop the train if necessary.
ETCS Brake Model Tool is able to calculate all nominal brake models, all safe brake models (the Kdry_rst values for each EBCL) and the Kwet_rst values based on the master nominal brake model and some information related to brake failures, given by brake component models, see section 4.2.
All properties of the fix train model are stored in the train model file (extension .fix). A fix train model that has not been saved after the latest modification is marked with an asterisk ’*’ in its title in the tab pane.
This data is necessary for both fix and flexible train models. It is described in section 3.1.1.
The nominal braking capacity and the differences caused by brake failures can be entered in two ways: as deceleration values or as brakes forces. If ”deceleration” is selected, the braking capacity is entered in terms of decelerations. If ”brake forces” is selected, the braking capacity is entered in terms of brake forces. Since finally always decelerations are needed, also the train mass and the equivalent train rotating mass must be given in case ”brake forces” is selected in order to convert the input to decelerations. If the train mass or the train rotating mass is changed, the deceleration values will be recalculated accordingly. Thus don’t change the train masses after you entered the correct decelerations.
The train model prefix is used to distinguish the brake models created by multiple independent fix train models. It is part of the brake model index of each created brake model, located in the bits above the sections needed for the coding of the brake status.
In the first line the nominal parameters are entered — either decelerations or brake forces. All values are positive values. The deceleration is limited to 2.55m∕s2. The nominal brake build up time has to be stated as well.
Both decelerations and brake build up time depend on a lot of actual physical parameters of a lot of components. Due to the central limit theorem, the overall distribution function will be close to the standard distribution therefore. The related standard deviations are entered in the second line.
The upper speed limits of the seven speed sections. The last speed section has no upper speed limit. If you need less than seven sections, type ’i’ into the speed limit text field(s) that you want to set to ”infinity” (see figure 5).
A brake component model contains all data related to the unavailability of a certain part of the train brake system, that is necessary to consider its effect to the braking capacity of the train:
Since the effect to braking distance is identical, independent from if the unavailability is known before or not, this data is also necessary (except of the probability) and sufficient to calculate all nominal brake models. Thus a brake component model does not exclusively describe the functional safety parameters but also the operational effects. Therefore the inhibition of a special brake is also modelled by a brake component model. If the inhibition and re-enabling would be perfectly safe, the probability of this failure would be zero. But in fact it can never be excluded that the command or status signal fails, so there is always a probability, that the special brake will not work as assumed by the ERTMS/ETCS on-board.
An unavailability that is known early enough (e. g. due to a brake test at start of mission or due to a track-side inhibition) doesn’t contribute to this probability. So if the complete system is tested at start-up and the test has a good fault detection and is sufficiently reliable, only those failures have to be considered, that occur within some few hours. Thus this probability is highly depending on the specific train.
All brake component models related to a fix train model are presented in the brake components table in the middle of the graphics panel.
This table displays all values of the brake component models. If a brake component model is selected in this table, its properties can be changed in the properties panel on the left.
A user defined name of the brake component model. The name must be unique within the fix train model.
A user defined description of the brake component model.
Describes the probability of a failure on demand, given by the unavailability Q.
The effect if this component is not available. Most unavailabilities will affect the deceleration (equivalent to the brake forces). Some components will only or in addition affect the brake build-up time. Since deceleration will always decrease, only negative values are allowed for the changes of deceleration or brake forces. The unavailability of some components might also lead to a decrease of the resulting overall mean brake build-up time , therefore positive and negative values are possible.
The number of physical or logical elements in the train, that can fail by this failure mode.
Complete independence is assumed between these elements. For global failures, e. g. common cause failures, failures of the overall control system, failures of command or status signals etc., set this value to 1.
Distinguished numbers of available elements. In order to decrease the number of brake models it makes sometimes sense not to assign a separate brake model to each and every possible brake system state, but to group some states. For example if the train has 20 bogies whose pneumatic brakes can fail independently, it makes sense not to have a separate brake model for: no (known) unavailable bogies, for 1, for 2 etc. up to maybe 10, but only one for 0 or 1 unavailable bogies (19 avail.), one for 2 to 4 unavailable bogies (16 avail.), and one for 4 to 10 unavailable bogies (10 avail.). Thus only the states ”at least 10 bogies available”, ”at least 16 bogies available” and ”at least 19 bogies available” are distinguished.
In order to add or remove a single number, press the ”Ctrl” key while clicking the number you want to add or remove.
Tell the algorithm that some other failure (or known unavailability) will have no additional effect if this failure (or known unavailability) occurs.
Only elements existing once per train can include other failures. If the failures of only some elements related to another failure are superseded by this failure, e. g. if a failure of this component affects only 5 out of 10 local elements, create two separate brake component models of this type (with number of elements per train = 1 for each), and two seperate local element components (with number of elements per train = 5 for each).
Activate the checkbox if the brake force created by this component doesn’t depend on wheel-rail adhesion.
If the checkbox is deactivated, the decrease of deceleration (corresponding to the increase of braking distance according to EN 15595, see [Subset 040]) shall be entered as well.
Activate the checkbox if the component is used also for service brake.
Each brake model consists of
Internally the safe values are stored as absolute values, not as correction factors. When exported to a file, the absolute values can be converted to correction factors, see section 2.4 and 9.5.1.
Brake models are created when the Calculate command is executed and a fix train model is active. If the brake models of the fix train model are valid, the tab ’Brake models’ can be selected. All brake models related to the fix train model will be presented in a table in the graphics panel. This table displays all values of all brake models either as absolute values or as correction factors, see 2.4.
The brake model index (BMI) is a 16 bit value. This 16 bit value is divided up into sections representing the status (availability) of certain parts (components) of the train brake system, including non-friction brakes such as regenerative brakes.
Each section typically corresponds to one brake component model. The only exception is, if the effect of a brake component model is included in another brake component model, see the example below. The length of each section is determined by the number of distinguished states to be encoded in this section. The sequence of sections is identical to the sequence of brake component models in the fix train model.
For example a failure of the (global) command signal for the magnetic shoes brakes (Mg brakes) will result in all Mg brakes not applied on demand. Thus the brake component model for the command signal includes (supersedes) the brake component model for local failures of the Mg brakes. Let’s further assume that there are 5 Mg brakes installed. The global command failure will result in all Mg brakes failing. The probability of this failure is usually much higher than the independent sporadic failure of 2 (or more) local Mg brakes. Thus it usually makes sense to define the standard case (all elements available) as one state, a sometimes needed partial defect state as a second state, and the complete loss as a third state.
By this the number of brake models can be drastically reduced compared to coding each possible number of available Mg brakes (0-5) as a separate state. Since state 1 is already included in the global failure, if the global failure is described in the third brake component model of the fix train model and the local failure in the sixth, the brake model index will be composed like this (assumed the fourth and fifth brake failure model is encoded in one bit):
with G being the bit for the global failure, L the bit for the local failure.
The resulting encoding is shown in table 2, ”d” means ”don’t care”.
If 3 and 4 available Mg brakes shall be encoded separately, the encoding will be like this:
with states listed in table 3.
No of avail. elem. | L L | G |
0, 1, 2 | d d | 0 |
3 | 0 0 | 1 |
4 | 0 1 | 1 |
5 | 1 0 | 1 |
The tab ’Brake model index sections’ shown in figure 8 provides information about the bits in the brake model index, so that the vehicle side train control software can be developed correctly.
In order to facilitate and ensure correct creation of the brake model index by a train control software, ETCS Brake Model Tool can create a C-code template, that will correctly reflect the content of the brake model index, see section 4.7.
The resulting brake distances for each brake model and each EBCL can be visualized after calculation by Calculate – Show Chart. A separate window will open, see figure 9.
All axis can be scaled and zoomed.
The presented graphics can be exported to a vector graphic (.svg) or a bitmap (.png) file, select File – Export ... in the menu of the chart. Note that in vector graphics format, the graph data is exported with original resolution, so a later printout will have a very high quality (if not reduced by the later processing).
The brake model for which the distances shall be shown is selected by its brake model index. The distances for different EBCL will be marked by different color. The scaling of both axes can be adjusted.
By Export – Export Brake Models all brake models of the active fix train model will be saved in an XML file with extension .ebm. Depending on the result mode either absolute values are written for all EBCL’s, or for EBCL > 0 the correction factors will be written.
In addition a list of the brake model index sections of the fix train model is stored in a XML file with extension .ebi.
Finally a C / C++ file (extension .c) is created, that should be used in the vehicle control or brake control in order to calculate the brake model index according to the currently available elements of each kind.
All files have the same name and are stored in the same directory as the train model file (.tm).