Abstract
We demonstrate refinement-based formal development of the hybrid, ‘fixed virtual block’ approach to train movement control for the emerging European Rail Traffic Management System (ERTMS) level 3. Our approach uses iUML-B diagrams as a front end to the Event-B modelling language. We use abstraction to verify the principle of movement authority before gradually developing the details of the Virtual Block Detector component in subsequent refinements, thus verifying that it preserves the safety properties. We animate the refined models to demonstrate their validity using the scenarios from the Hybrid ERTMS Level 3 (HLIII) specification. We reflect on our team-based approach to finding useful modelling abstractions and demonstrate a systematic modelling method based on the state and class diagrams of iUML-B. The component and control flow architectures of the application, its environment and interacting systems emerge through the layered refinement process. The runtime semantics of the specification’s state-machine behaviour are modelled in the final refinements. We discuss how the model could be used to generate an implementation using code generation tools and techniques.
Highlights
The Hybrid European Rail Traffic Management System (ERTMS) Level 3 (HLIII) specification [1] concerns the control of trains moving on a linear track and communicating by radio and trackside equipment
Example: as we modelled the flow of information through the control components, we found it difficult to reconcile the reported train positions and controlled Movement Authority (MA) with the safety properties of the abstract environment
The Virtual Block Detector (VBD) is responsible for deciding which Virtual Sub-Section (VSS) are free based on information it receives from the TTD and from Positive Train Detection (PTD) communications received from communicating trains
Summary
The Hybrid ERTMS Level 3 (HLIII) specification [1] concerns the control of trains moving on a linear track and communicating by radio and trackside equipment. Example: as we modelled the flow of information through the control components, we found it difficult to reconcile the reported train positions and controlled MA with the safety properties of the abstract environment. Validation Once the model had been refined to include the operational details of the VBD, the model was animated to validate it against the example scenarios given in the specification For this validation stage, we created a BMotionStudio visualisation of the railway system and developed a new ‘scenario checker’ plug-in that automatically animates internal processes of the model and records/replays scenarios involving the external interfaces. The VBD is responsible for deciding which VSS are free based on information it receives from the TTD and from Positive Train Detection (PTD) communications received from communicating trains.
Sign-in/Register to view highlights & summary Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callMore From: International Journal on Software Tools for Technology Transfer
Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
