Digital Modelling in the Railways

Abstract

The railways have a quite long modelling history, covering many technical aspects from infrastructure to rolling stock, train movement, maintenance, etc. These models are mostly separate and operated independently by various stakeholders and with diverse objectives. This article presents some of the various digital modelling activities, including formal ones, that are undertaken by the railway industry, for design, development, validation, qualification, and exploitation. It also introduces trends toward regrouping models to obtain more significant results together with a larger scope, prefiguring digital twins.

Full text

Digital Modelling in the Railways
Thierry Lecomte1
ClearSy, 320 avenue Archim`ede, Aix en Provence, France
thierry.lecomte@clearsy.com
Abstract. The railways have a quite long modelling history, covering
many technical aspects from infrastructure to rolling stock, train move-
ment, maintenance, etc. These models are mostly separate and operated
independently by various stakeholders and with diverse objectives. This
article presents some of the various digital modelling activities, including
formal ones, that are undertaken by the railway industry, for design, de-
velopment, validation, qualification, and exploitation. It also introduces
trends toward regrouping models to obtain more significant results to-
gether with a larger scope, prefiguring digital twins.
Keywords: railways, digital modelling, formal methods
1 Introduction
Modelling activities are central to the railways, mainly in the form of separate
models of diverse natures. Very early in a development, train manufacturers
and operators need to assess and verify that a metro line or a main line will
fulfil expectations in term of performance, number of passengers transported,
operation costs, power consumed, etc. Most of these models (data and related
tooling) are often developed to cover one verification activity, for historical rea-
sons, for regulation reasons (qualification model should be independent from
design model), for organisational/political reasons (different services of a same
company prefer to develop their own solution), or for technical reasons (models
reconciliation/connection requires excessive investment). Initiating a new prod-
uct line is a good occasion to initiate a new model, distinct from the existing
ones, and to contribute to increase their population. Of course, the situation
depends on the company developing / operating trains but it is common trend
observed during the last decades. However, with the increasing complexity of
the systems developed and the competition on the railway market, modelling is
going global, including more aspects to obtain more effective results.
Based on a non-exhaustive picture of the use of models for the trains/metros
manufacture and operation, this article tentatively outlines what could be the
integration of the digital twin concept in the railways. It presents some of the
current digital modelling activities, including formal ones, that are undertaken
by the railway industry, for design, development, validation, qualification, and
exploitation. It also introduces trends toward regrouping models to obtain more
significant results together with a larger scope, prefiguring digital twins.

This paper is structured in 6 parts. Section 2 introduces the terminology. Sec-
tion 3 presents how the infrastructure is modelled. Modelling safety is exposed
in Section 4. Section 5 presents some new modelling directions in relation with
emerging paradigms. Section 6 sketches some pros and cons arguments concern-
ing the adoption of the digital twin concept in the railways before concluding in
section 7.
2 Terminology
This section contains specific definitions, concepts, and abbreviations used through-
out this paper.
Formal methods refers to mathematically rigorous techniques for the spec-
ification, development and verification of software and hardware systems. [9]
identifies a collection of formal methods and tools to be applied in railways.
PLC put for programmable logic controller[21], is an industrial digital com-
puter which has been ruggedized and adapted for the control of any activity
that requires high reliability control and ease of programming and process fault
diagnosis.
Safety refers to the control of recognised hazards in order to achieve an
acceptable level of risk.
Reliability is the ability of a system to perform its required functions under
stated conditions for a specified time.
3 Modelling Infrastructure
This section introduces some important notions about the railway elements sub-
ject to modelling.
3.1 Categories
Railways are divided into two main areas: metro lines and main lines. Below is
a summary of the main differences between the two kinds:
– metro lines: installed in and around cities, the lines are tens of kilometres
long. Except if the line is circular, trains are operated on a carousel: when
they reach the end of a line (forward movement), they fallback using another
set of rails associated to the back movement. Metro stations are usually close
to the next one (around 500m in Paris): the train spends the same time in
station and travelling between stations. The interval between trains is a key
performance factor: at rush hour, when a train leaves a platform, another one
is going to enter. Only trains from a line are operated on this line, even if the
number of trains is likely to vary to match passengers flow. One signalling
system is installed on board and on the tracks. The train order is fixed as
all trains stop to all successive stations.

– main lines: they cover large areas, possibly several countries. Lines are
up to thousands of kilometres long. Trains move from point A to point B,
with zero / some stops / all stops. Trains may gain / lose cars in station.
Additional trains may be injected in the flow, coming from other countries
/ operated by different companies. Signalling systems change when crossing
national borders.
3.2 Rails
Rails are common equipment among metros and main lines. As such they are
first class citizens: they are the first elements modelled in a project. The network
is called scheme plan or track plan (Fig. 1). These plans contain mainly:
–rails or tracks, made of connected circuits,
–switches, to guide the train from one track to another,
–optical signals, that display instruction or warning to the driver,
–balises/beacons: signals could be duplicated / replaced by electronic equip-
ment in case of (partial) automation.
–axle counters, track circuits to detect the presence of a train,
–interlocking,
–rail crossings.
Modelling items have attributes like position, length, gradient (slope), max-
imum speed.
Fig. 1: Scheme plan of the Taita metro station, New Zealand.
Many track plan editor tools are available. Some examples are given below.
They are either developed by:
–train manufacturers (SIGART by Alstom, TMDS by Wabtec),
–software/services companies (ERSA traffic simulator, iFrank by iRFP, Fer-
rovia by CGS Labs, Anylogic, Track Editor Tool by SA Transurb, OpenRail
by Bentley, OpenTrack),
–or universities (SafeCap by University of Newcastle).

These tools have specific GUIs with different graphical representations. For
data persistence/exchange, they rely on either:
–RailML[5]: based on XML to describe tracks and signalling equipment, timeta-
bles, vehicles (rolling stock) and signalling routes (interlocking),
–RailTopoModel[13]: promoted by the International Union of Railways, is a
systemic, general, standard model for describing the topology-based railway
infrastructure, able to take into account many non-standard descriptions
needed for addressing specific needs.
Other proprietary formats (mostly closed specification) are also available like
Siemens Infrastructure Format, Infraspeed Infrastructure Format, Bentley Rail
Track, or OpenTrack.
The modelling of the tracks and related equipment is central as it provides
a basis for forthcoming engineering activities. An overall system deployment is
in five steps:
–capture of the railway environment and infrastructure,
–develop railway infrastructure data and generate track plan,
–prepare and compile data necessary for configuration of equipment (beacons,
telecommunication, PLCs, interlocking, etc.),
–validation of data by check or automatic methods (Section 4.3),
–validation by simulation including train environment.
The drawing of the track and the positioning of the equipment have to comply
with rules (issued from the train manufacturer, from the train operator, and from
regulations). Engineering also includes the design of the technical rooms (where
equipment is installed), the cable layout and its estimated length.
3.3 Dynamics
Modelling the rails and related equipment provides a static view of the network.
The dynamic view is obtained with:
– a model of the driver. The driver is able to accelerate, decelerate, and
brake (as well as open and close doors). The driving behaviour has to be
somehow optimal by complying with several, sometimes antagonist, require-
ments:
•the time to travel from one station to another has to be minimal,
•the train speed has to be lower than speed limits,
•the train speed has to be lower than its braking curve, taking into account
the minimum train braking capability,
•train acceleration/deceleration has to be kept within bounds, ensuring a
comfortable travel to passengers.
Such an acceleration profile is given in Fig. 2.

Fig. 2: An example of speed profile. X axis represents the train position, red
curve is breaking curve, blue curve is speed limit, black curve is train speed,
beige curve is train acceleration.
– a model of the train. Reacting to the acceleration/braking of the driver,
this model includes technical characteristics like tractive effort/speed dia-
grams, load, length, adhesion factor, and power systems. It also takes into
account track gradients (Fig. 3) that make the computation of the train
dynamics more complicated [2]:
•positive gradient slows down the train and reduces travel performances,
•negative gradient has to be taken into account for the safety braking
curves in relation with the minimal braking capabilities,
•bathtub curve gradient combines both effects. In case of a train at stand-
still in such a place, an oscillation movement could be observed.
Fig. 3: Paris Metro line 14 tunnel depth.
The wheel-rail interface is also a complex domain to model [1][15]. Wheel
slipping occurs when tractive effort exceeds adhesive weight whereas sliding
occurs when braking effort exceeds adhesive weight. In both the situations, it
is the adhesive weight playing the most important role. When tractive effort

is more than adhesive weight, difference in power accelerates the wheel which
results into grinding action on the rail. In the similar manner, when braking
effort exceeds the adhesive weight, extra braking force prevents its rota-
tion but with continuation of linear motion which results rubbing of wheel
at one location on the circumference and called development of wheel flat.
Both these conditions create unsafe situation. Weather and environmental
conditions, including dry leaves, play a vital role in reducing adhesion.
Fig. 4: Maximum actionable adhesion in function of speed and rail state.
Slipping and sliding have a dramatic impact on the safety:
•braking distances may be greater than expected, leading to a potential
collision with a train.
•train position is deduced from a number of inputs sources (beacons,
odometer, GPS). In a tunnel, the position between two beacons is esti-
mated with the rotation of the wheels - sliding may bias the precision of
the position and lead to a collision if the train is ahead of its estimated
position.
Many other aspects, not listed here, have an impact on the behaviour of
the train. For example, strong wind (Mistral wind in Provence) implies a speed
restriction because of important windward grip (strong side wind may lead to
train rollover [18]).
3.4 Timetables
With several trains being operated on a line, a timetable specifies where each
train is located at given times over a certain period and is often presented as
a graphical space-time diagram (Fig. 5). That the timetable is feasible means
that it should be free of conflicts between trains and satisfy certain functional
constraints given by the railway system, such as the track capacity resulting
from the physical infrastructure and the signalling system.

The timetable stores information for each train at each station, including
arrival and departure times, minimal stop time, and connections to other trains.
It can be computed from the static model (routes) and from the dynamic model.
Simulation tools (like OpenTrack or SafeCap) could be used to evaluate
timetables by introducing random delays. Predefined trains run according to
the timetable on a railway network. During the simulation, train movements are
calculated under the constraints of the signalling system and timetable.
Traffic is:
–cyclic (or not): all train services are operated with some fixed interval time
–homogeneous (or not): trains have the same profile (speed, running time,
stop patterns).
–passengers traffic or freight traffic or mixed.
Fig. 5: Diagram of a single route timetable [20]
After a simulation run, train graphs, occupation diagrams and statistics are
used for assessment. In particular, the headway between two successive trains is
used to identify critical block sections. Simulation may be used to:
–compute real-time optimum strategies for traffic flow,
–explore the design space by modifying the track plan and the signalling
parameters,
–minimise energy usage: when employing rheostatic braking, a train could
provide energy to the network that could be used by another close acceler-
ating train.
In [8], the automation of a large part of the ETCS rail track planning process
is addressed by the algorithmic sequencing of formalized planning rules based on
the knowledge and some best practices obtained from experienced track planners.

Simulation may also be used to assess compliance to standards. For exam-
ple, the ERSA traffic simulator implements the ERTMS principles1that are
explained in 700 pages (Fig. 6).
Fig. 6: Transitions between ERTMS driving modes (matrix 17x17 !). White cells
represent conditions and priorities for feasible transitions. Priorities enable avoid-
ing conflict between simultaneously actionable transitions.
4 Modelling Safety
Models are also developed and used to ensure safety.
4.1 Automatic pilot - braking
The automatic train protection (ATP for the metro) is a system on-board the
train which continually checks that the speed of a train is compatible with the
permitted speed allowed by signalling, including automatic stop at certain signal
aspects.
If it is not, ATP activates an emergency brake to stop the train. The braking
curve is calculated based on the track topology (including gradient), the distance
1https://www.era.europa.eu/content/set-specifications-3-etcs-b3-r2-gsm-r-b1 en

Fig. 7: Top-level specification of an ATP main loop (excerpt) written in B. For
each cycle, the software has to verify all conditions to either enable a permissive
behaviour or stop the train.
to go to the next red signal (including a safety margin), the guaranteed train
braking capability and the estimated train localisation (section 3.3).
Around 30% of the automatic metros ATP specification are modelled with
the B language (Fig. 7). Their implementation are proved[3] to be correct refine-
ments (no contradiction wrt specification). The model is huge, representing more
than 50,000 lines of specification. The overall model requires to mathematically
demonstrate 23,000 proof obligations to ensure its correctness.
4.2 Estimating maintenance periods
The rail integrity is a critical subject for train control as well as for maintenance
strategies. Over all the possible rail flaws, a broken rail is obviously the most
sensitive point. Typically, flaws are detected with special ultrasound monitoring
trains and with unusual noise reports from drivers.
Two facts have a strong influence on the availability and safety of the railway
system:
–the occurrence of critical defects of infrastructure subsystems,
–false alarms for instance triggered by monitoring devices designed for the
defect detection.
For these two points, the railway operators need a degradation model of
the rail and, as accurate as possible, an estimated rate of good detection of
defects by their measuring devices. Then, various maintenance strategies can
be simulated and their impact on the broken rail monitoring process can be
completely estimated. In [4], dynamic Bayesian networks theory are introduced

for the rail degradation and for the broken rail monitoring process model. The
objective is keep (or improve) the ability to detect flaws when automating metros
(the driver’s feedback is not available anymore).
4.3 Formal data validation
Data validation consists in the verification and validation of the static data (sec-
tion 3.2) against railways signalling rules (that are specific to every country or
even each company in a single country), on rolling stock features (constant or
variable train size or configuration) and operating conditions. By data valida-
tion, we mean the validation of the parameters (i.e. constants) that determine
a specific behaviour of a software/system over a wide range of possible sets of
values. Microsoft Excel defines data validation in terms of type checking: a cell
may contain a date, an integer, a string or a floating point number. In our case,
the data to validate are not only scalar but also represent more complex struc-
tures like graphs. A metro line is seen as a graph, made of connected tracks
with distributed signals and switches implementing signalling rules. Graphs are
encoded through a large number of tables.
Fig. 8: Example of verification rule. Signals belonging to an interlocking territory
are searched (clause WHERE); such signals have to be linked to this interlocking
(clause VERIFY). If not, an error message is displayed for each faulty signal
found (clause MESSAGE).
Formal data validation consists in:
–formalising the verification rules,
–formally proving that the data to verify comply with the formal rules.

In [14], rules are formalised with the B language (Fig. 8) and the proof is
performed with the ProB model checker. Formal data validation has been ap-
plied to complete metro lines / main lines interlocking systems, demonstrating
its applicability to large systems. In [17], configuration rules for interlocking are
specified by temporal logic formulas interpreted on Kripke structure representa-
tions of the interlocking configuration.
4.4 Proving interlocking (model-checking, installation-based)
An interlocking is the safety-critical system that controls the movement of trains
in a station and between adjacent stations. The interlocking monitors the status
of the objects in the railway yard and allows or denies the routing of trains in
accordance with the railway safety and operational regulations that are generic
for the region or country where the interlocking is located. Verification of cor-
rectness of control tables has always been a central issue for formal methods
practitioners, and the literature counts the application of several techniques to
the problem. It is a well known fact that interlocking systems, due to their
inherent complexity related to the high number of variables involved, are not
amenable to automatic verification, typically incurring in state space explosion
problems. Model-checking[10][11] has been exercised with considerable success
for specific implementation and up to a certain complexity measured by a num-
ber of managed Boolean equations.
4.5 Modelling Design Reasoning
A railway system is often huge and very difficult to assess as structural modelling
is not able to scale up properly. For example, a RER A regional train simulator
modelling all track-side equipment (including wires, relays, etc.) contains more
than 2,000,000 variables and requires seven computer to simulate simplified traf-
fic scenarios on the central sector of the line. In [16], structural formal modelling
is applied to an existing interlocking specification, but the results are a single
error (“well known” by the customer) and an Event-B model refined 15 times,
unreadable/unusable by the recipients.
A different formal methodology was then invented[19][6] where the design
reasoning is modelled and proved against properties, based on assumptions ad-
mitted by all experts. Fig. 9 below illustrates its different stages, which can be
called “the ideal formal world” and which makes it possible to obtain a system
that is guaranteed to be zero-defect:
–The left side of the diagram represents the “formal proof of correct interop-
erability”. The aim is to ensure that if the individual sub-systems making
up the overall solution are implemented in accordance with their specifica-
tions, then the safety of the overall system is guaranteed. This proof enables
the entity responsible for the integrated system to ensure that there are no
hidden safety bugs in the subsystem breakdown.

Fig. 9: The complete picture of the formal approach for safe systems).
–The right side of the schema could be named “formal proof of correct design”.
It is a question of guaranteeing that a given implementation is designed in
such a way that the safety expectations expressed in the specifications are
effectively met.
The by-product of this methodology is a book, written in natural language,
providing an irrefutable mathematical demonstration that the various subsys-
tems meet the expected refined properties[7].
5 Convergence and Relevance
The previous sections show that many railway activities are now subject to
modelling. The complete picture of the situation is difficult to obtain as many
of them are not publicly disclosed, for various reasons (competitiveness, secrecy,
insufficient maturity, etc.) or are more a marketing by-product unable to survive
the demonstration/prototyping phase.
Several initiatives to combine / associate theses modelling activities have
been launched in order to address larger engineering problems or new paradigms
like AI, hybrid modelling2, and model-in-the-loop. Among them, we may notice:
–MegaM@RT3project, with the analysis of traces at execution time by com-
parison with system-level models (search for patterns, AI)
–Shift2Rail4improved train localisation with the formal modelling of the
forthcoming Moving Block specification and the fusion of diverse data (GPS,
odometer, kinematics, digital maps) to get rid of most track-side signalling.
–Simulating ERTMS Hybrid level 3 specification [12], a novel approach be-
tween ETCS level 2 fixed blocks and full moving blocks. Fig. 10 shows the
formal B model being executed in real-time, along with a visualisation of the
model’s state: over 40 issues were identified.
2The combination of continuous and discrete models to associate a logic controller to
the physics of a controlled system described with differential equations.
3https://megamart2-ecsel.eu/
4Call for Project 2R-OC-IP2-01-2020

–SNCF R´eseau5is developing a digital mock-up of its network to provide
valuable input for scheduling predictive maintenance operations, foresee be-
haviour, train teams and test-drive strategic solutions.
–Alstom6develops a rail network digital twin for railway yard design and
predictive fleet maintenance based on AnyLogic.
–On-going autonomous train projects7are integrating AI for decision and
diverse sensors for detection, while ensuring a human remote control in case
of unexpected situation.
Fig. 10: Formal B model of Hybrid Level 3 Principles running in real-time.
Besides the fact of using state-of-the-art techniques, how relevant the concept
of digital twin is in the railways ? Due to the different domains, timescales, and
objectives8covered by the modelling activities listed above, having a digital twin
of a whole railway system does not seem much adequate.
A digital twin would probably find a more suitable usage for a restricted
domain/timescale/objective combination like training simulation or validation
test bench 9. More precise results are expected with the integration of addi-
5https://www.sncf-reseau.com/en/entreprise/newsroom/sujet/the-digital-twin
6https://www.anylogic.com/digital-twin-of-rail-network-for-train-fleet-maintenance-
decision-support/
7https://tech.sncf.com/dossier/train-autonome/
8For example, respectively functional vs safety, seconds for slipping vs thousands
years for rail maintenance, and development vs certification.
9SNCF test bench BATIR enabling the real-time functional simulation, including
HiL, of full high speed trains to validate embedded software.

tional modelling dimensions. However tool/model integration costs are a high
barrier as there are many tools, specific to a line/model/plant, for which source
code / (design, interface) documentation is often hardly available. The combi-
nation of these tools/models, developed separately, would induce extra effort to
validate their semantic and pragmatic consistency, especially if used for safety
certification. Moreover developing new tools/models for legacy systems already
in exploitation requires a sound justification (exploitation/maintenance costs
saving, solving design issues uncovered lately).
Digital twin is probably more adequate to address newer systems (new base-
line) or new themes like:
–ERTMS: its evolving specification and the lack of feedback (compared to his-
torical national signalling which have been designed over decades/century),
difficult to deploy10 and enabling the late discovery of errors through hybrid
modelling[12].
–Cyber security: critical transportation infrastructure is facing increasing se-
curity risks given that many systems are (going to be) connected to the
Internet, while related standards are as of today being written (hence not
ready for deployment). In particular, joint security and safety modelling are
closely related and are good candidates to populate a digital twin.
–Terrorism: At the highest level, there is a clear need for the combination of
models from different transportation systems11 , to take into account multi-
modalities, especially with respect to the terrorist risk and the way indepen-
dent transportation infrastructures will manage security.
–Autonomy: automating trains requires to consider more aspects than for au-
tomated metros, as the environment is more complex with more elements,
interfaces, and interactions. The variety of scenarios and situations met re-
quires precise models of the system and its environment to ensure AI con-
sistency.
6 Conclusion and Perspectives
Railways are heavy modelling providers and users. Most models are:
–separate;
–have different natures and objectives: logic, physical world, performances,
safety, etc.
–have different subjects: infrastructure, rolling stocks, environment;
–used for different activities (specification, development, validation, qualifica-
tion/certification, exploitation/maintenance);
10 ”Bring in the disruptors to drive rail innovation”, Stuart Calvert, Digital Rail, Tran-
sCityRail North conference, London, 06/10/2017
11 H2020 Call SU-INFRA-01-2020: Prevention, detection, response and mitigation of
combined physical and cyber security threats to critical infrastructure in Europe

The on-going tendency is to support more engineering activities with mod-
elling or cross-modelling (either by combining modelling to obtain an augmented
one, or by exercising modelling with the support of another one). For example,
slipping/sliding physical modelling provides outputs (i.e. tables) for the esti-
mation of the train localisation precision, but is not included into train traffic
simulation per se.
However it seems unreasonable to imagine a model of a complete railway
system (a metro line) shared among different stakeholders, as the range of uses is
quite large and the systems considered made of many equipment/subsystems/parts.
Applications to new themes (AI for autonomy, cyber security, terrorist risks,
etc.) might constitute a suitable entry point for digital twins in the railways.
References
1. Alacoque, J.C., Chapas, P.: Traction ferroviaire adh´erence par commande d’effort.
Techniques de l’ing´enieur Infrastructure ferroviaire et mat´eriel roulant base
documentaire : TIB576DUO.(ref. article : d5535) (2005), https://www.techniques-
ingenieur.fr/base-documentaire/ingenierie-des-transports-th14/infrastructure-
ferroviaire-et-materiel-roulant-42576210/traction-ferroviaire-d5535/, fre
2. Banach, R.: Issues in automated urban train control: ‘tackling’ the rugby club
problem. In: Butler, M., Raschke, A., Hoang, T.S., Reichl, K. (eds.) Abstract State
Machines, Alloy, B, TLA, VDM, and Z. pp. 171–186. Springer International Pub-
lishing, Cham (2018)
3. Behm, P., Benoit, P., Faivre, A., Meynadier, J.M.: Meteor: A successful application
of b in a large project. pp. 369–387 (01 1999)
4. Bouillot, L.: Dynamic bayesian networks modelling maintenance strategies: Pre-
vention of broken rails. In: WCCR’08, 2008, Seoul, South Korea. (2008)
5. Ciszewski, T., Kornaszewski, M., Nowakowski, W.: Railml application for descrip-
tion of railway interlocking systems 19, 373–377 (12 2018)
6. Comptier, M., D´eharbe, D., Perez, J., Mussat, L., Pierre, T., Sabatier, D.: Safety
analysis of a cbtc system: A rigorous approach with event-b. pp. 148–159 (10 2017)
7. Comptier, M., Leuschel, M., Mejia, L.F., Perez, J., Mutz, M.: Property-Based
Modelling and Validation of a CBTC Zone Controller in Event-B, pp. 202–212 (01
2019)
8. Dillmann, S., H¨ahnle, R.: Automated planning of etcs tracks. In: Collart-Dutilleul,
S., Lecomte, T., Romanovsky, A. (eds.) Reliability, Safety, and Security of Railway
Systems. Modelling, Analysis, Verification, and Certification. pp. 79–90. Springer
International Publishing, Cham (2019)
9. Ferrari, A., ter Beek, M.H., Mazzanti, F., Basile, D., Fantechi, A., Gnesi, S., Piat-
tino, A., Trentini, D.: Survey on formal methods and tools in railways: The astrail
approach. In: Collart-Dutilleul, S., Lecomte, T., Romanovsky, A. (eds.) Reliabil-
ity, Safety, and Security of Railway Systems. Modelling, Analysis, Verification, and
Certification. pp. 226–241. Springer International Publishing, Cham (2019)
10. Ferrari, A., Magnani, G., Grasso, D., Fantechi, A.: Model Checking Interlocking
Control Tables, pp. 107–115 (01 2011)
11. Halchin, A., Feliachi, A., Singh, N.K., A¨ıt-Ameur, Y., Ordioni, J.: B-PERFect
- Applying the PERF Approach to B Based System Developments. In: Interna-
tional Conference Reliability, Safety, and Security of Railway Systems. Modelling,

Analysis, Verification, and Certification (RSSRail 2017). vol. 10598, pp. 160–172.
Pristoia, Italy (Nov 2017), https://hal.archives-ouvertes.fr/hal-02451007
12. Hansen, D., Leuschel, M., K¨orner, P., Krings, S., Naulin, T., Nayeri, N., Schneider,
D.M., Skowron, F.: Validation and real-life demonstration of etcs hybrid level 3
principles using a formal b model. International Journal on Software Tools for
Technology Transfer 22, 315 – 332 (2020)
13. Hlubuˇcek, A.: Railtopomodel and railml 3 in overall context. Acta Polytechnica
CTU Proceedings 11, 16 (08 2017)
14. Lecomte, T., Mottin, E.: Formal data validation in the railways. In: Safety Critical
Symposium, 2016, Brighton, UK. (2016)
15. Malvezzi, M., Pugi, L., Papini, S., Rindi, A., Toni, P.: Identification of a wheel–rail
adhesion coefficient from experimental data during braking tests. Proceedings of
the Institution of Mechanical Engineers, Part F: Journal of Rail and Rapid Transit
227, 128 – 139 (2013)
16. Metayer, C., Clabaut, M.: Dir 41 case study. In: Abstract State Machines, B and
Z, First International Conference, ABZ 2008, London, UK, September 16-18, 2008.
Proceedings. pp. 1–16 (2008)
17. Peleska, J., Krafczyk, N., Haxthausen, A.E., Pinger, R.: Efficient data validation
for geographical interlocking systems. In: Collart-Dutilleul, S., Lecomte, T., Ro-
manovsky, A. (eds.) Reliability, Safety, and Security of Railway Systems. Mod-
elling, Analysis, Verification, and Certification. pp. 142–158. Springer International
Publishing, Cham (2019)
18. Quost, X.: Mod´elisation de l’effet du vent sur les trains `a grande vitesse. Ph.D.
thesis, Ecole Centrale de Lyon (2005)
19. Sabatier, D.: Using formal proof and b method at system level for industrial
projects. pp. 20–31 (06 2016)
20. Wikipedia contributors: Fundamentals of transporta-
tion/timetabling and scheduling — wikibooks (2020),
https://en.wikibooks.org/wiki/Fundamentals of Transportation/
Timetabling and Scheduling, [Online; accessed 05-June-2020]
21. Wikipedia contributors: Programmable logic controller — Wikipedia, the free en-
cyclopedia (2020), https://en.wikipedia.org/wiki/Programmable logic controller,
[Online; accessed 08-May-2020]