Supporting Railway Infrastructure Managers with Formal Models and Analyses Bas Luttik Based on joint work with many people (to be mentioned later!) AlgoUK/BCTCS, April 6, 2020
European collaboration Standardisation 2 INTRODUCTION
train INTERLOCKING detection point signal free occupied level crossing block/section 3 RAILWAY SAFETY SYSTEMS
1. An application of FM in the development of EULYNX Collaboration with: a) EULYNX, FormaSig (general ideas) b) First case study: Point Mark Bouwman, Djurre van der Wal c) Next steps Jaco van de Pol, Arend Rensink, Marielle Stoelinga 2. An application of FM in the development of ERTMS-HL3 a) Principles of ERTMS Hybrid level 3 b) Formal analysis c) Next steps 4 PLAN FOR THIS PRESENTATION
Monolithic inflexible architecture VENDOR LOCK-IN INTERLOCKING Many Expensive different installations special hardware 5 LEGACY SIGNALLING SYSTEMS
standardised interface object controller electronic ERTMS → digital ready VENDOR LOCK-IN INTERLOCKING fibreglass network with IP-like protocol 13 European inframanagers 6 STANDARDISE ARCHITECTURE
OBVIOUSLY: Obviously: 1. Standard should be clear and unambiguous 2. Standard should be complete 3. Standard should guarantee correct system behaviour 4. Compliance to standard should be thoroughly tested BUT HOW TO ACHIEVE THIS FOR EULYNX? 7 QUALITY OF STANDARD IS CRUCIAL
• Growing interest in formal methods. • Funded two 4-year PhD projects to investigate the application of formal methods in their context. • PhD students spend considerable time at Railway Infrastructure manager’s premises. 8 FORMASIG PROJECT
Standardised interface spec TEST COMPLIANCE TO STANDARD Compliance verdict Model-based Formal formal Testing model Analysis stimuli Adapter observations Delivered IMPROVE QUALITY OF STANDARD component 9 FORMASIG PROJECT
Standardised interface spec TEST COMPLIANCE TO STANDARD Compliance verdict Model-based Formal formal Testing model Analysis stimuli Adapter observations Delivered IMPROVE QUALITY OF STANDARD component 10 FORMASIG PROJECT
https://www.mcrl2.org Simple, but expressive, process-algebra based modelling language • Rich data language (sets, lists, functions, integers, …) • Parallel composition of (recursively defined) sequential processes Analysis • Simulation • Model checking § First-order extension of the modal µ-calculus § Extensive counterexample facility § Behavioural equivalence checking 11 § Connection to model-based test tool JTorX
Standardised interface spec TEST COMPLIANCE TO STANDARD Compliance verdict Model-based Formal Testing Analysis stimuli Adapter observations Delivered IMPROVE QUALITY OF STANDARD component 12 FORMASIG PROJECT
Automatic TEST COMPLIANCE TO STANDARD Translation Compliance verdict Model-based Formal Testing Analysis stimuli Adapter observations Delivered IMPROVE QUALITY OF STANDARD component 14 FORMASIG PROJECT
FIRST CASE STUDY: POINT Manual Ma Automatic TEST COMPLIANCE TO STANDARD Translation Compliance verdict Model-based Formal Testing Analysis Input from om railwa way stimuli Adapter engi gineers needed observations SysML ML Delivered IMPROVE QUALITY OF STANDARD component simulator or 15 FORMASIG PROJECT
FIRST CASE STUDY: POINT Verification results: Manual Ma • 9 properties checked Automatic TEST COMPLIANCE TO STANDARD Translation • 1 false (deadlock due to overflowing buffer) Compliance verdict • (Interpretation) of SysML models under discussion with DB Model-based Formal Testing Test results: Analysis Input from om railwa way Offline testing → generated 82 tests • stimuli Adapter engi gineers needed observations SysML ML Delivered • All tests passed (24/82 ended prematurely) IMPROVE QUALITY OF STANDARD component simulator or 16 FORMASIG PROJECT
Point case study showed that FormaSig principle works Next steps: • Automate translation SysML → mCRL2 Ø Semantics? • Analyse correctness other object controllers Ø Requirements? • Online model-based testing, coverage-based testing • Test mutants, test real component 17 FORMASIG: NEXT STEPS
1. An application of FM in the development of EULYNX a) EULYNX, FormaSig (general ideas) b) First case study: Point c) Next steps 2. An application of FM in the development of ERTMS-HL3 Collaboration with: a) Principles of ERTMS Hybrid level 3 Maarten Bartholomeus b) Formal analysis Rick Erkens c) Next steps Tim Willemse 18 PLAN FOR THIS PRESENTATION
L2 L3 3 2 1 TTD 20 TTD 10 TTD 30 free occupied 38 ERTMS/ETCS
L2 L3 3 2 1 ERTMS LEVEL 3: ELIMINATE TRACKSIDE EQUIPMENT
L2 L3 3 2 1 ERTMS LEVEL 3
L3 promises considerable cost L3 reduction and capacity increase Train Integrity Monitoring SERIOUS DRAWBACKS: • All trains must have TIM • Not very tolerant for radio connection problems 3 2 1 ERTMS Hybrid Level 3 ERTMS LEVEL 3
Main ideas: • Partition TTDs into Virtual Sub-Sections (VSSs) • Multiple TIM-equipped trains can be on different VSSs of same TTD VSS 11 VSS 12 VSS 21 VSS 22 VSS 23 VSS 31 VSS 33 VSS 32 2 1 TTD 20 TTD 10 TTD 30 free occupied 42 ERTMS HYBRID LEVEL 3
Main ideas: • Trackside maintain info on VSS status, based on regular train reports and TTD information • Movement authorities issued based on VSS status VSS 11 VSS 12 VSS 21 VSS 22 VSS 23 VSS 31 VSS 33 VSS 32 2 1 TTD 20 TTD 10 TTD 30 free occupied 43 ERTMS HYBRID LEVEL 3
EEIG ERTMS Users Group 123-133 Rue Froissart, 1040 Brussels, Belgium Tel: +32 (0)2 673.99.33 - TVA BE0455.935.830 Website: www.ertms.be E-mail: info@ertms.be Principles H�b�id ERTMS/ETCS Le�el 3 Ref: 16E042 Version: 1A Date: 14/07/2017 Purpose of the specification is: • to describe how the trackside system should determine the status of each individual VSS (based observed events)… • …such that safe movement authorities can be issued… • …without unnecessarily restricting implementation freedom . 16E042 Hybrid ERTMS/ETCS Level 3 Page 1/48 1A 14/07/2017 44 ERTMS HL3 SPECIFICATION
VQ1: Does the specification guarantee that VQ 2: Does it matter how the EEIG ERTMS Users Group 123-133 Rue Froissart, 1040 Brussels, Belgium Tel: +32 (0)2 673.99.33 - TVA BE0455.935.830 Website: www.ertms.be E-mail: info@ertms.be issued movement authorities are safe? specification is implemented? ( no collisions ) ( robustness of specification ) Principles H�b�id ERTMS/ETCS Le�el 3 Ref: 16E042 Version: 1A Date: 14/07/2017 Purpose of the specification is: • to describe how the trackside system should determine the status of each individual VSS (based observed events)… • …such that safe movement authorities can be issued… • …without unnecessarily restricting implementation freedom . 16E042 Hybrid ERTMS/ETCS Level 3 Page 1/48 1A 14/07/2017 45 ERTMS HL3 SPECIFICATION
46 ERTMS HL3 SPECIFICATION
• Relevant data is easily modelled using mCRL2’s data language • Transition conditions can then be modelled as predicates. 47 ERTMS HL3 SPECIFICATION
Recommend
More recommend
