Formal Model-Based Analysis of a
Signalling Application using SCADE
Alessandro Fantechi & Stefano Moretto,
DINFO - University of Florence
Jair Gonzalez
Esterel Technologies
Railway Signalling equipments and Formal Methods
Railway signaling is now since more than 25 years the subject of
successful industrial application of formal methods in the
development and verification of its computerized equipment.
One of the reason for this is the fact that railway signalling has
strict safety requirements, which require rigorous software
development (Formal Methods since then mentioned as Highly
Recommended in EN50128 safety guidelines)
However the evolution of the technology of railways signaling
systems in this long term has had a strong impact on the way
formal methods can be applied in their design and implementation.
At the same time important advances have been also achieved in
the formal methods area.
→ The scope of the formal methods discipline has enlarged from
the methodological provably correct software construction of the
beginnings
Railway Signalling equipments - The first days of Formal Methods
The B method has been successfully applied to railway signaling
systems, especially by MATRA Transport and ALSTOM, mainly in
France.
The first application has been at the end of the eighties,
concerning the SACEM system for the control of the A line of
Paris RER. B has been introduced when the project was already
progressing, in order to ensure the two railway companies
exploiting the line (SNCF e RATP) of the correctness of the
design.
On the basis of this first application the method has been
developed, accompanied by the realization of support tools, and
has been adopted for many later designs of similar systems by the
same companies (by the way, MATRA is now a Siemens
company. . . )
One of the most striking application has been for the Paris
METEOR metro line (n. 14), completely automated.
Railway Signalling equipments - The Model checking advent
Model checking has raised the interest of many railway signaling
industries, being the most lightweight from the process point of
view, and being rather promising in terms of efficiency.
Interlocking systems, appear to call for a direct application of
model checking, since their safety properties are "easily"
expressed in temporal logic.
However, due to the high number of boolean variables involved,
automatic verification of sufficiently large stations typically incurs
in combinatorial state space explosion problem.
The first applications of model checking have therefore attacked
portions of an interlocking system [Groote95, Bernardeschi98]
but even recent works [Winter03, FerrariMGF10] show that routine
verification of interlocking design for large stations is still out of
reach for symbolic model checker NuSMV and explicit model
checker SPIN, although specific optimizations can help.
SAT-based verification is currently the most promising option and
is used in industrial solutions.
Model Based Design
in the last decade, Formal and Semi-Formal Model Based Design
has been largely adopted in the railway signalling industry,
achieving lower costs and better quality software.
Simulink/Stateflow or SCADE have been used for modelling,
exploiting the offered possibilities of automatic code generation for
the production of high quality code. [Ferrari et al, IEEE SW 2013]
Model Based Testing has been adopted for verification, either
together with more traditional testing techniques, or with model
checking or abstract interpretation [Ferrari et al, SCP 2013].
Formal verification remains however the most challenging area,
with not so wide industrial acceptance due to poor scalability of
automated verification techniques.
CBTC
Subsystems:
on-board subsystem (BSS)
trackside subsystems (TSS)
1 instance per train
Board to ground communication
1 instance per track zone
Functions:
ATC (Automatic Train Control)
ATS (Automatic Train Supervision)
ATO (Automatic Train Operation)
IXL (Interlocking)
CBTC
Door
Control
(SIL4)
SIL4
Board to ground communication
SIL4
SIL4
CBTC
Formal modelling
the TraceIt project
Train scheduling Deadlock avoidance
by UMC model checking
(ISTI - FMICS2014)
Capacity analysis by SAN
(ISTI - SERENE2013)
Board to ground communication
ECM proprietary equipment
Modelling by UML Statecharts
+ Simulink for the control algorithms
Simulation
Auto-code generation
(UNIFI - ITSC2014)
CBTC
Formal modelling
other experiences
Several experiences of UNIFI, ISTI,
in collaboration with Ansaldo,
ALSTOM, GETS,…
Model checking, model based testing… Students’exercises on model
based development of a
distributed interlocking system
(SCADE, Simulink, UMC,
Rhapsody,…)
Board to ground communication
Model-based design and testing
UNIFI - GETS
IEEE Software 2013
Formal Modelling and Verification Project
Under the Academy Program of Esterel Technologies, we have
conceived a project aiming at observing the learning curve of a student
exposed to SCADE
- work done as a graduation thesis for a first-level student
- student not previously trained on formal methods,
nor on model-based development
(arguments taught at the Master classes)
- attacking an already SCADE-developed (interlocking) design of
medium size
- applying verification tools to improve the design
The Phases of the Formal Modelling and
Verification Project
• Initial personal study and exercises on SCADE
• Understanding the already developed project, also in
collaboration with ET staff
• Definition of safety requirements for the interlocking
• Expression of safety requirements as Design Verifier
observers
• Verification runs
• Improvements to the model, if any
The source model of an interlocking system
The system is composed, at the top level, by a
control part and a display part
The display part drives a display window that shows
the layout of the station.
The control part is composed, by a “Movement_Authority” part, that
models the movements of trains in the station, and a
“Station_State_Management” part that is the heart of the
interlocking systems, taht is, contains the interlocking rules
Geographic approach
•
•
•
•
Interlocking rules are not implemented by means of any kind of
“Control Tables” (boolean equations, ladder diagrams, etc…)
A “geographic approach”, is used instead: inheriting typical
modelling criteria from computer science, it can be considered
as a model-based approach, while control tables inherit the
criteria of relay-based functional definition:
The Interlocking logic is made up by composition of elements
that take care each of the control of a physical element (point,
track circuit, signal), connected by means of predefined
composition rules, mimicking the topology of the specific layout
This approach is apparent in the structure of the
“Station_State_Management” component
Agreed project Schedule
N°
Deliverable Title
Deliverable
Description
Resp
Schedule
[D1] Training on SCADE Suite
and SCADE Verifier
Webex sessions
As required
[D2] Safety system requirements
General safety
requirements
AF
April 14, 2015
[D3] Safety software
requirements
Specific safety
requirements (on the
basis of the model
SM, JG, AF
April 28, 2015
[D4] Safety properties models in
SCADE
SM, JG
May 5, 2015
[D5] Analysis and improvement
SM, JG
May 19, 2015
[D6] Report writing
SM, JG
May 26, 2015
Generic safety requirements
(Stated for a generic interlocking system).
1.
Route protection
When a route is reserved for a train, appropriate means are in place to prevent
another train to enter the route.
This requirement may be enforced by several mechanisms:
•
signals: the aspect of an entry signal to a route tells the driver
whether he is authorized to enter the route
•
signals: the aspect of an entry signal to a route tells the driver the
speed with which he is authorized to enter the route
•
Automatic Train Protection: an on-board system receives the
movement authority from the interlocking and automatically brakes of the
train in case of missing authority
•
Overlap: a safety zone of a certain distance after the route exit
signal, used to prevent a hazardous situation from occurring if a train is unable
to stop in front of the exit signal
•
Flank Protection: switches and signals not belonging to the route are
properly set in order to avoid hostile train movements into the route
Generic safety requirements
(Stated for a generic interlocking system).
1.
Route protection
When a route is reserved for a train, appropriate means are in place to prevent
another train to enter the route.
This requirement may be enforced by several mechanisms:
• signals: the aspect of an entry signal to a route tells the driver whether he is
authorized to enter the route
In the case of the system at hand, apparently only the first applies, that can
be expressed as:
1.1 an entry signal to a route can be green only if the protected route
is reserved.
Moreover, to avoid unintended movement of a following train:
1.2 a green entry signal shall be set to red as soon as a train has
entered the reserved route
Generic safety requirements
2. No-Collision
Once Route protection is established, two trains cannot collide if the following
holds:
2.1 Two routes that share a track element cannot both be reserved at
the same time.
3.
No-Derailment
While a train is crossing a point, the point shall not change its position.
Due to Route protection, this requirement can be expressed as:
3.1 While a route is reserved, any point on the route shall not change
its position.
The requirements should be verified for every applicable
route/signal pair, pair of routes , route/point pair
Specific safety requirements
1.
Signal aspects
ILCK_SAF_01
The aspect of the signal shall be green only if the protected point is reserved
at that moment.
ILCK_SAF_02
The aspect of the signal shall be set to red in the cycle in which the protected
point is occupied.
2.
No-Collision
ILCK_SAF_03
A Track or a Point shall not be reserved to different trains at the same time.
3.
No-Derailment
ILCK_SAF_04
A point shall not change his position if it is occupied
Observers:
ILCK_SAF_01
The aspect of the signal shall be green only if the protected point is
reserved at that moment.
(This Observer is put in a cycle that executes the control for every signal in the
project, and then checks if a single output can ever become false)
Observers:
ILCK_SAF_02
The aspect of the signal shall be set to red in the cycle in which the
protected point is occupied.
Observers:
ILCK_SAF_03
A Track or a Point shall not be reserved to different trains at the same time.
Note: three trains are explicitely modelled for simulation, so that a capacity saturation
scenario can be modelled: the three instances of “check” are related to the three trains
Observers:
ILCK_SAF_04
A point shall not change his position if it is occupied
Verification results -
ILCK_SAF_01
•
The property proved false at the first attempt.
•
Actually, a careful study of the operators inside the StationStateMgmt
component has revealed that of the various implemented signals, two
of them were protecting two points.
Although not seriously hurting the working of the system, this
implementation choice was in contrast with the expressed
requirements, so we had to modify the model by a total rebuild of the
involved operator (Simu_SignalRules, which receives as inputs the
points states, points positions and the track position, and emits a
Boolean output for each signal in the design).
The rebuild has simplified the association of signals to points, allowing
for the use of an array of elements that has simplified the design.
•
•
•
The property was proved on the modified model
This modification has required a modification to the display
component as well, to reflect the new association of signals to points.
Verification results •
ILCK_SAF_02
proved on the modified model at the first attempt
Verification results -
ILCK_SAF_03
•
Applying the Observer to the model was not simple, because the
observable variable that control the state of tracks and points is a
Boolean, so the problem was that it is not possible to know which train
is reserving which track.
•
A non-functional modification to the model was necessary, in order to
extract at the highest this information present at lower levels, in order to
make it observable.
•
After this modification, however, the attempt to verify the property since
we (presumably) hit the limitations of Design Verifier verification
capacity. Within the project, we had no more time available to further
investigate the reason for this behaviour, nor to attempt different
verification strategies allowed by Design Verifier. Hence the property
has remained unproven.
Verification results -
•
ILCK_SAF_04
proved on the modified model at the first attempt
Figures about the learning curve
Initial personal training and exercises on SCADE
2 months
Teleconferences with ET staff
8 telcos, total 10 hours
Exercising on SCADE, assisted by ET staff
7 hours
Analysis of the project
1 week
Properties definition, and first verirication phase
2 weeks
Improvements to the Design and 2nd Verification phase
2 weeks
Report writing
2 days
TOTAL
10 weeks
Lessons learned (by the academic partner)
• Mastering SCADE appears to be quite fast for the not skilled
• Modifying someone else’s design has proved quite natural,
thanks both to the expressive power of the graphical language
and to the usability of the development environment (not
dissimilar in many respects to common modern programming
environments familiar to the students)
• Using the same graphical language for expressing the
properties (by means of observers) does not add the difficulty
of mastering a separate ad hoc language.
• Simulation and Verification tools are fundamental in
understanding the technicalities of someone else’s design
• Verification tools are fundamental in refining the design so to
respect “independent” (safety) requirements
• Still, verification is challenging for certain properties
(improvement needed here!! - research is going on…)
THANKS FOR YOUR ATTENTION!!!
Alessandro Fantechi & Stefano Moretto,
DINFO - University of Florence