Formalising the Hybrid ERTMS Level 3 specification in iUML-B and Event-B
- 135 Downloads
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.
KeywordsERTMS Event-B iUML-B Refinement Validation
Abstract Data Type
Event Refinement Structure
Communications-based Train Control
European Rail Traffic Management System
Hybrid ERTMS Level 3
Virtual Block Detector
Radio Block Centre
Trackside Train Detection
Positive Train Detection
Start of Mission
End of Mission
Train Integrity Monitoring System
Full Supervision Movement Authority
On-Sight Movement Authority
The Hybrid ERTMS Level 3 (HLIII) specification  concerns the control of trains moving on a linear track and communicating by radio and trackside equipment. A train movement controller called the Radio Block Centre (RBC) manages the Movement Authority (MA) granted to each train in mission. The focus of this work, called the Virtual Block Detector (VBD), conservatively estimates train locations to a finer granularity than physically detected track sections, and thus reports free virtual track sub-sections available for train movement. Trains and trackside report location data to the VBD. In turn, the VBD reports free track sections to RBC. The MA granted to each train consists of a set of sections that the train is permitted to move into. An MA can be extended by adding further contiguous sections, or trimmed by removing sections that the train has passed through. A controlled train is instructed that the sections in its MA are free, allowing it to travel at full speed. A trusted train is given a special on-sight MA allowing it to move cautiously through sections that are not guaranteed to be free; the driver is trusted to avoid collisions. The key safety property which we verify is that controlled trains do not run into trains that are ahead of them.
The refinement-based Event-B modelling method  is an appropriate choice since it allows us to verify key properties while leaving certain features, and interacting components, abstract and underspecified. The architecture can be layered through the refinement: each layer can focus on an abstract component interface, the environment, or a specific feature of the target system. In their evaluation of seven competing state-based formal methods,  judge Event-B favourably, and among the best for verification and tool support. They also find Event-B, while less expressive in refinement modelling than ASMs  and Z , to be superior ‘when it comes to (mechanically) proving and verifying refinement’, i.e. in proof support. The Rodin  toolkit includes theorem provers and model-checkers. Integration of diagrammatic UML modelling with Formal Methods is well established, e.g. [7, 8]. Rodin plugins include diagrammatic modelling notations and tools; we use UML-like iUML-B class diagrams and state-machines [9, 10, 11]. iUML-B leads to a readable formal specification which is easier for domain experts to validate [12, 13]. For validation of scenarios, we used the ProB  model checker with BMotionStudio  visualisation.
Formal models are often presented as if they were developed in perfect inexorable steps when, in practice, they never are. We give an overview of our informal team-based process illustrating the iterations that involved many misunderstandings, failures and rework. The team consisted of research and academic staff who had some experience of formal modelling of railway applications such as interlockings and crossings, but no previous experience of communications-based, virtual section train control. Although there were frequent and extensive discussion between the three original team members (Dghaym, Poppleton and Snook), the main model entry and validation and verification (V , V) activities were carried out by one team member (Dghaym). Improved team-working facilities for Event-B are currently under development to alleviate this. One team member (Dalvandi) was added for specialist advice on developing an implementation from the model.
Our previous models have been revised to reflect the new version of the specification .
The model is refined to cover more operational details of the system.
The model has now been validated using the scenarios from the specification.
We propose methods to generate an implementation from the model.
We reflect on the process in a more accessible way.
Structure The paper is structured as follows. Section 2 describes our requirements and modelling strategy, giving a summary of the methods and process we used and recalling Event-B and iUML-B basics. Section 3 describes the results of our analysis of the system to derive and clarify the requirements. Section 4 presents the details of our modelling including refinement strategy (Sect. 4.1) followed by a detailed account of modelling (Sect. 4.2). Section 5 describes our verification by theorem proof (Sect. 5.1) and validation by scenario animation (Sect. 5.2). Section 6 discusses ways to derive an implementation from the model. Section 7 provides observations about the specification and reflections on the modelling methods arising from the development. Section 8 compares our development with other ABZ 2018 publications about the same case study as well as some other related work. Section 9 concludes by reviewing the work, its increment over  and required future work and tool improvements.
2 Requirements , modelling strategy
The HLIII specification focusses on the operational details of the VBD component, whereas a formalisation of safety properties requires an abstract system level description. Therefore, our first stage was to derive requirements via a systems analysis which is described in Sect. 3. We then proceeded to model the system starting with the environment (ENV) and specifying what we mean by safety before introducing the concept of movement authority from the RBC and then VBD operation to ensure safety. Further details of the model structure are given in Sect. 4. We have not provided traceability from requirements to the formalisation. This would be useful further work. The primary aim and result of our solution is that the safety properties are clearly formalised and the principle of movement authority is proven to be safe (with some caveats) before the operational details of the VBD are proven to maintain this safety while also being demonstrated to satisfy the scenarios given in the specification (again with some caveats). We modelled the requirements fully except that we abstracted away from length measurements such as ‘minimum safe distance’. This affects the accuracy of one transition in the operational state-machine. We also abstracted away from an interval measurement of time and therefore do not incorporate any notion of clock in our model. Although the specification involves a number of time deadlines, each one is a simple expiry event which can be fully modelled via arbitrary expiry events without a measure of time. The remainder of this section summarises the steps of the process that we followed in developing the model.
While the HLIII specification [1, 17] is well presented in terms of explanatory scenarios, its focus makes it a detailed requirements specification for the VBD. It does not explain the overall system aims and principles so well. We therefore started by reverse engineering our understanding of the system in order to understand its purpose and the concepts on which it is based. This involved analysis of the information in the specification, discussions and sketching whiteboard diagrams such as components, entity relationship and state-machine diagrams. The diagram-based analysis naturally led into the iUML-B modelling. The systems analysis identifies the main components in the system and the information flow between them. This is necessary for the model to reflect the appropriate responsibilities of the VBD versus assumptions it makes upon other components. As with most stages of the modelling process, the analysis was iterative. The modelling improved our understanding of the system, and our new understanding helped us choose better abstractions for modelling. For example, initially we assumed that only connected trains were in mission. However, when modelling we realised that when a connection is lost the system relies on the fact that the train will continue to respect its MA and this implies that the train is still in mission. This new understanding of the system led us to revise our models so that the ‘in-mission’ state-machine was independent of (i.e. parallel with) the connected state-machine.
Refinement Strategy The refinement strategy provides a plan for building the model; choosing abstractions, adding details in refinement steps and introducing invariant properties at appropriate stages. We considered two alternative approaches: a) start from an abstract safe system or b) start from an unsafe system and make it safe. In this work, we chose the second approach. While the first approach is perhaps more traditional, in this case, the safety properties were not so obvious and were complicated by unsafe, albeit mitigated, scenarios. So we wanted to capture the essence of train movement before introducing assumptions and progressing towards details that can distinguish between safe scenarios and mitigated unsafe scenarios. Again, the refinement strategy evolved as we discovered difficulties and adapted our approach.
Modelling with Event-B and iUML-B Event-B [2, 18] is a refinement-based formal method for system development. An Event-B model contains two parts: contexts for static data and machines for dynamic behaviour. The dynamic behaviour is specified by variablesOpen image in new window , invariant predicates Open image in new window that constrain the variables, and events. An event comprises a guard denoting its enabling condition and an action describing how the variables are modified when the event is executed. In general, an event Open image in new window takes the form of the following definition, where Open image in new window are the event parameters, Open image in new window is the guard of the event, and Open image in new window is the action of the event. Open image in new windowOpen image in new window
Event-B is supported by the Rodin Platform , an extensible toolkit which includes facilities for modelling, verifying the consistency of models using theorem proving and model checking techniques, and validating models with simulation-based approaches.
iUML-B [9, 10, 11] provides a diagrammatic modelling notation for Event-B in the form of state-machines and class diagrams. The diagrammatic elements share the repository of an Event-B model, and contribute to that model. For example, a state-machine will automatically generate the Event-B data elements (sets, constants, axioms, variables, and invariants) to implement the states, and transitions contribute additional guards and actions to existing events. Class diagrams provide a way to visually model data relationships providing an object-oriented style ‘lifting’ which is absent from standard Event-B. Classes, attributes and associations are linked to Event-B data elements (carrier sets, constants, or variables) and generate constraints on those elements while class methods contribute additional guards and actions to existing events. Note that iUML-B is designed to be a diagrammatic representation of Event-B and is syntactically and semantically different from UML. For example, there is no notion of triggers or ‘run to completion’ in iUML-B, transitions are enabled and may fire when their source state is active and their guard is true. Where several transitions and/or methods are linked (i.e. contribute) to the same event, they must all fire together. This gives a way to synchronise transitions in different state-machines.
For modelling, we used iUML-B for its diagrammatic notation which follows on from the diagrams used in our analysis and review stages. We used automatic theorem provers to verify our Event-B models and the ProB model checker to find counter examples when the theorem provers could not discharge proof obligations.
We cannot prove this proof obligation (PO)—look for a better modelling approach. Example: Contiguity of next_VSS relationship. We found it difficult to prove contiguity properties about Virtual Sub-Section (VSS) using properties of the sequence, the obvious Abstract Data Type model;  discusses some of the difficulties of modelling with such ADTs. To avoid such effort, we used numeric indexing of VSS , thus relying on the contiguity of a range of integers. We retained the next function for elegance of expression in guards and actions. Figure 2a of Sect. 4.2.1 presents the VSS class properties.
This is not a useful refinement—change refinement strategy. Example: we wished to introduce features such as timers as soon as it was possible to do so (i.e. when the triggering functionality was available). However, we had not yet introduced the relevant VSS state changes to utilise the timeout. To rectify this, we altered our refinement strategy to introduce abstract versions of VSS states and associated transitions before introducing timers. This is explained in more detail in Sect. 4.2.2.
This is not a true data refinement—change systems analysis. 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. It seemed that we would need to introduce some form of responsiveness assumptions to limit the difference between actual and control variables. However, the specification implied that the VSS states were asynchronously updated. As our understanding of the MA principle improved, we realised that the position inaccuracy is of no consequence and we adjusted our systems description accordingly.
3 Requirements resulting from system analysis
The HLIII specification is a detailed description of one component (the VBD) of a wider system that controls train movements. The other components involved in the system are the trains and trackside equipment, which we refer to as ENV, and the RBC that calculates movement authorities limiting the movement of trains.
The VBD receives messages from trains and train detectors. It also receives information about the output of the RBC. It calculates a range of sections that it believes to be free of any trains and sends these to the RBC. The RBC sends to each train, a movement authority consisting of a range of sections that the train may move into. The train is instructed either that the sections are all free or that they might not be free. We wish to model and verify item 3, the VBD. To do this, we also need to consider (and model) the other 2 items.
their current position (more precisely than track sections),
the length of the train,
whether the train is confirmed as integral (i.e. the carriages are still all connected together).
The RBC grants movement authority (permissions) to the communicating trains. The RBC uses information it receives from the VBD about which VSS are free. An MA consists of a range of track sections that the train is allowed to move through. Under RBC control, an MA is dynamically extended from the front VSS, and trimmed from the rear VSS. The train is also instructed as to whether it needs to be responsible for avoiding collisions with trains in front (On-Sight Movement Authority (OSMA)) or whether it can assume the track sections are free (Full Supervision Movement Authority (FSMA)). Note that the specification makes the assumption that OSMA is safe. It is not within the scope of this study to consider whether this is justified. We assume the RBC always issues safe FSMA in accordance with the information it receives from the VBD. That is, all sections in an FSMA are ones that the VBD has calculated to be free.
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. It sends information about which VSS it believes are free to the RBC. Since PTD reports may be intermittent or interrupted and some trains do not communicate at all, the estimate of free VSS is cautious in these circumstances.
The positions of trains that are communicating are known fairly accurately (subject to some lag in communications) from the PTD data sent by the train (position, length and integrity) as well as physical limits on possible train movement in between communications. The position of the train is defined by the range of sections from that occupied by the rear to that occupied by the front; this may be a single section. Some robustness is necessary to accommodate limitations of the communication mechanisms such as temporary loss of communication, etc.
its last known position (from a PTD or a loss of integrity),
how far it could possibly have travelled since its position was known,
information from trains and free TTD that delimits its movement range.
For loss of integrity, a ghost train is created just behind the communicating train to represent the detached section of carriages. A communicating train is converted to a ghost train if the train’s mute timer expires (after communication is lost) or if it sends a mission-end message and terminates communication. A ghost train is removed (i.e. destroyed) by sweeping. Sweeping is the movement of a trusted train (with OSMA) through the sections where the ghost train may be. If the trusted train is able to pass through these sections, the ghost train is judged not to exist. A ghost train may also be converted to a communicating train if it starts communicating with the VBD (either by sending a mission start communication or by re-starting previous communication).
4 Model details
Our formalisation of the requirements uses iUML-B which imparts a modelling style into the generated Event-B. Our strategy for developing the refinements is shown in Sect. 4.1 Further details of the strategy and modelling style are shown in Sect. 4.2 which illustrates how we modelled (a) the ENV (Sect. 4.2.1), (b) the RBC and (c) the VBD (Sect. 4.2.2).
4.1 Refinement strategy
ENV-M00Trains This is the abstract level of the model. It defines a linked list of trains to keep track of train order and prevent overtaking. Trains are created at the rear of the linked list and removed from its front. We also allow adding a new train in the middle of the linked list as a result of train split.
ENV-M0Train movement, VSS Introduces the train movement in terms of VSS section updates, where a VSS section is either free or occupied by a train. The train movement is modelled as an update of the position of either the train front or the rear.
ENV-M1 Ghost vs connected trains Distinction between connected and ghost (i.e. non-connected) trains, where all new trains join as ghost.
ENV-M2TTD Introduces TTD sections which can be either free (no train on any of its VSS) or occupied (a train on at least one of its VSS). The TTD state is immediately updated by train movement events.
RBC-M3 RBC RBC can grant trains MA. We call a train with MA inMission, where the RBC may extend its MA while connected.
VBD-M4Position reporting Introduces the reported versus actual train position with the associated MA trimming. We also introduce the memorised location of a train resulting from communication loss.
VBD-M5Controlled vs trusted trains Introduces the concept of available VSS as an abstraction to the detailed VSS state transitions table presented in . Fully supervised FS (controlled) vs on-sight OS (trusted) trains are also introduced. An OS train has unsafe MA (i.e. can include not available VSS) but is assumed not to crash into the back of other trains. An FS train has safe MA and therefore cannot crash into the back of other trains.
VBD-M6Integrity loss If a train reports integrity loss as a result of either train split or changed length, the train is considered non-integral.
VBD-M7Waiting timers Defines three different states for timers: Open image in new window , Open image in new window or Open image in new window . Waiting timers apart from the shadow train timer B are introduced at this level.
VBD-M8VSS State-machine Distinguishes three different types of trigger that initiate the VSS state-machine: TTD information, position reports (PTD) and timer expiry. The abstract VSS state-machine is refined to the four states: Open image in new window , Open image in new window , Open image in new window and Open image in new window . The propagation timers and any remaining timers are modelled at this level.
VBD-M9Lower levels Full VSS state transition as per specification, where transitions from one state to the other are refined to model the different alternatives.
The model consists mainly of three parts: the ENV, RBC and VBD. Compared to our HLIII model presented in , the ENV part has not changed much. Since we abstract away the details of how the RBC calculates a movement authority, it is dealt with in a single refinement which is not changed in this version. The VBD is modified to conform to the new version of the specification document  and to complete the modelling of the VSS operational state-machine.
4.2.1 Modelling the environment
In the first refinements, we focus on modelling the ENV and the possible trackside events, such as train movement, splitting and loss of communication.
Entering and Leaving HLIII Area In the previous version of the specification , the entry/exit of a HLIII area was not mentioned. In our ABZ paper , at the abstract level we introduced how trains can join and leave the network. This is similar to the updated specification , which includes a new section to describe how trains can enter/exit a HLIII area. Compared to , we only updated the event names to conform to the specification.
Trackside and Train Movement In the context, we model the network topology using iUML-B class diagrams (Fig. 2). First, we introduce the Open image in new window class (not shown in figures), then the Open image in new window with their linear layout enforced by indexing via attribute Open image in new window , as shown in Fig. 2a.
Next, we introduce the Open image in new window which groups sets of contiguous Open image in new window via association Open image in new window (Fig. 2b). Class Open image in new window , which is a sub-class of Open image in new window , represents those TTD that have at least one of their VSS occupied by a train. At this level, we distinguish two cases when a train is leaving the last VSS of the TTD: i) no other train occupies the TTD and the TTD becomes free (and is removed from Open image in new window ) or ii) it remains occupied and not free. The same applies to a train exiting a HLIII area which can also free a TTD.
We also split each of the radio connection/disconnection transitions in Fig. 3 into two cases to distinguish between SoM and reconnection vs connection loss and EoM. The transitions Open image in new window and Open image in new window are common to both state-machines. Note that when a train first enters a HLIII area, it enters as a ghost train with no mission, and when leaving the HLIII area it also has to exit as a ghost train with no mission.
When a train performs SoM, it is immediately granted an MA for the VSS it occupies. However, this does not allow the train to move to new VSS sections. In order to move forward, the RBC should extend the MA as shown by the self-transition Open image in new window of the Open image in new window state in Fig. 4. Our assumption that trains with a mission respect their MA is enforced by the Open image in new window class invariant: Open image in new window3.
4.2.2 Modelling the VBD
Movement Authority , VSS Availability In the next refinement of the VBD, we distinguish between the two different modes of MA: FSMA and OSMA. In FSMA mode, the RBC only uses free VSS to extend Open image in new window . In OSMA mode, the RBC can extend Open image in new window with any VSS since we trust the OSMA trains not to crash into the rear of the next train. This behaviour is modelled in Fig. 5 by partitioning Open image in new window into two different sub-states, Open image in new window and Open image in new window representing FSMA and OSMA modes, respectively. The choice between the two transitions, Open image in new window and Open image in new window , is non-deterministic and determines the mode of the train.
Note that when a train performs a SoM, it is granted OSMA ( Open image in new window ). This is a design decision we took in , to ensure safety, since a train is initially not connected when it first enters a HLIII area. In the new version , a new section (188.8.131.52.2) is added which notes the risk and suggests the use of the ATAF method which uses the OSMA profile to start the mission.
We can now introduce a safety invariant concerning the separation of controlled trains; the Open image in new window of controlled trains do not overlap:
Hence, the RBC can only extend the Open image in new window of Open image in new window trains using VSS sections that are free and not part of any Open image in new window . We introduce a sub-class Open image in new window of Open image in new window to represent the free VSS sections. This will be refined to the VSS state Open image in new window in future refinements as we introduce the state-machine of the specification. However, extending the Open image in new window for trusted trains does not have these restrictions.
At this level (VBD-M5), we model an abstraction of the VSS state-machine as shown in the top (m5) part of Fig. 6. We add events to add and remove Open image in new window by generalising the conditions that apply for the VSS state transitions. Therefore, for adding an Open image in new window , it either belongs to a free TTD or no train has reported its position in this VSS, while for now the only condition for removing a VSS from Open image in new window is that it belongs to an occupied TTD. We also add an event to model ‘no change in the availability of the VSS’.
The semantics of the VSS state-machine is a form of run-to-completion where a trigger event (e.g. receiving new TTD/PTD information or timer expiry) results in all the consequently enabled transitions of the VSS state-machine being fired to update the affected VSS states before another trigger event is considered. Later, we introduce the notion of triggers explicitly as a scheduling mechanism for the events that require running the VSS state-machine.
The mute and wait integrity timers (inv1, , inv2) are total functions from Open image in new window to TIMER_STATUS, so are assigned to every train entering a HLIII area. In the case of Open image in new window trains that never establish a connection with the trackside, these timers will remain Open image in new window and will never be started. While the shadow train timer A (inv3) is a total function from TTD to TIMER_STATUS, it is associated with every TTD section.
Invariant inv4 ensures that a train with a memorised location is either a train with expired mute timer (i.e. a train that lost its connection with trackside) or a train that ended its mission. Invariant inv5 ensures that the state of a train with expired wait integrity timer is Open image in new window .
At the next VBD-M8 level, we introduce the full VSS state-machine from the specification document, as shown in Fig. 7. The Open image in new window state refines the previous Open image in new window , and the three states Open image in new window , Open image in new window , Open image in new window correspond to non-available VSS sections. Therefore, all the transitions going to the Open image in new window state will refine Open image in new window , and all the transitions leaving the Open image in new window state will refine Open image in new window , and finally the remaining transitions will refine Open image in new window .
In Fig. 7, we model the abstract 12 transitions of the VSS state-machine with additional self-loops for each of the four states. The numbers in front of the transition names correspond to the transition numbers shown in m8 of Fig. 6 and the transitions described in the specification document.
We also introduce the concept of triggers, which explicitly initiate the running of the VSS state-machine. The presence of a trigger is a guard for Open image in new window in Fig. 6. We extend the context to distinguish between PTD, TTD, timer expiry and startup triggers. (The startup trigger is only used for the initial state to update the VSS sections starting initially as unknown.) The state-machine cannot start dealing with another trigger until it completes updating all the VSS states. To simplify the model, we only allow one trigger at a time. This has the disadvantage of always giving some triggers priority over others. In our case, TTD triggers have a higher priority. We also introduce the propagation timers and the remaining waiting timer. When the state-machine completes the VSS state update ( Open image in new window ), it will reset the trigger and the propagation timers.
In the last VBD-M9 refinement, we decompose the state-machine transitions to model the different alternatives as presented in the specification table of the VSS state-machine, and add all the remaining details.
5 Verification and validation
In our modelling approach, we start by verifying safety at the earlier stages of the model and then later focus on validating the VBD system. We prove safety using the MA concepts, where in  we show that revoking MA can result in an unsafe state. However, in the latest version of the specification , the notion of revoking MA is removed. Therefore, we remove the Open image in new window event from our model. However, there remain questions about how MA can be impacted and the conditions that can result in its change. MA is an essential part of the system and to prove safety of the model, more details should be provided.
After verifying system safety, we focus on introducing the details that help us in modelling the VBD state-machine, which is the main concept in the specification document. The table describing the state transitions of the VBD state-machine is very difficult to follow, hence the provided operational scenarios play a major role in validating the model. For validation, we use ProB and BMotionStudio to run the scenarios. We use BMotionStudio to display the main variables in a tabular format. This provides the criteria for validating the scenarios. For example, we present the VSS state, the actual position of the trains and their reported positions, as shown by the upper left part of Fig. 8. We have also used the CODA Oracle Simulator  to record and replay the event traces when running the scenarios. This is shown in the lower left part of Fig. 8.
Proof statistics: customised auto-tactics
When defining the variable types, we try to apply total functions instead of partial functions as much as possible, e.g. Open image in new window and timers; this improves discovering missing guards and actions. Moreover, we ‘lift’ the state-machine to a set of instances ( Open image in new window ). Therefore, the generated state-machine-type invariants are based on subsets of the instance set ( Open image in new window ), which makes it easier to define the whole domain of the functions.
5.1.1 Proof statistics
In Table 1, we present the proof statistics of our model. Our modelling resulted in 621 proof obligations. The number that is discharged automatically varies depending on the proof tactic profile used and the machine. Our best results were obtained using a proof tactic profile that includes the ‘relevance filter’ RF (using ML and PP from the AtelierB provers) and then runs the SMT solvers (CVC4 and Z3). The relevance filter is a meta-prover that improves the efficiency of the selected theorem provers by localising relevant theorems. In the best case, we achieved 95% automatic proof but this dropped to about 88% on slower machines. For comparison, the best result using the default prover configuration of Rodin (after installing AtelierB provers) was 47%.
5.2 Validation: role of ERTMS operational scenarios
Scen. 1 A normal scenario for integrity confirmation. Pass after updating #6A guards as a result of running step 4. In the specification, #6A states a VSS changes from occupied to free if an integral train leaves the evaluated VSS. We added to the Event-B model an additional condition to take into account a free TTD.
Scen. 2 Train splitting with confirmed integrity. Pass after updating #11A as a result of running step 7. We add a guard to transition #11A that takes into consideration that an integral train has left the rear TTD. This condition is explicitly mentioned in the reference section 184.108.40.206 of the specification.
Scen. 3 Shadow train scenario. Partial pass, we do not model travel distance, hence shadow train timer B is started resulting in enabling #11B in step 7.
Scen. 4 Start and end of mission. Pass, similar to scenario 2 because it runs steps 6 to 8 of scenario 2.
Scen. 5 Integrity loss. Partial pass, we have different states in steps 3 and 7. The main reason of the discrepancy is that we do not model delay in TTD communication and always give priority to TTD triggers over PTD.
Scen. 6 Train disconnecting and reconnecting. Partial pass, resulted in updating #1B, changing the state of a VSS from Open image in new window to Open image in new window , to start the ghost propagation timer.
Scen. 7 Connection loss and reconnection with VSS release. Partial pass, resulted in updating transitions related to #8 (changing the state from Open image in new window to Open image in new window ), by adding the guard that TTD is occupied. The additional condition is not described in the specification table. Moreover, fixing the priority guards of #12 ( Open image in new window to Open image in new window ) over #5( Open image in new window to Open image in new window ). We model transition priorities by negating the guards of the higher priority transition. Discrepancies in step 6 because we do not run the state-machine twice and separate the update of the front and rear positions of the train.
Scen. 8 Sweeping the track and the jumping train effect. Fail, step 4 demonstrates the need to separate front and rear position updates by running the state-machine twice.
Scen. 9 Ghost train. Partial pass, requires strengthening self-transitions to make the state-machine deterministic, this is left for the next iteration when an automatic tool is developed to generate the run-to-completion conditions. For now, we always give normal transitions a priority over self-transitions when running the scenarios.
In Fig. 8, we show how running step 4 of scenario 8 results in an event error. This problem is captured by the provers (Fig. 9), where we cannot prove the contiguity guard in Open image in new window because of a weakened guard between VBD-M5 and VBD-M6 in the case of integrity loss. When decomposing the position reporting event to distinguish between the integrity cases in VBD-M6, we introduce a new parameter Open image in new window which is contiguous but the witness replacing Open image in new window is not. In this case, running scenario 8 has highlighted a problem in our model, helped us to understand why we could not discharge the proof obligation, and why we actually need to run the state-machine twice to update the VBD position. The solution is to make a clear distinction between three types of positions: the environment position, which we modelled as Open image in new window , the position reports and the VBD position ( Open image in new window ) which requires running the state-machine twice in case of PTD and TTD triggers. Since we need to separate the VBD position update into two steps, modelling the position report as a parameter ( Open image in new window ) in the position reporting events is not enough, and it needs to be recorded as a variable. This update requires another iteration of the model. After this, we will be able to prove that the VBD positions are contiguous, but the position reports in comparison with previous reports are not necessarily contiguous (i.e. jumping train effect).
6 Towards implementation of VBD
We previously mentioned that the focus of this work is on modelling and verification of VBD. However, in order to be able to model and verify different safety requirements such as no-collision, we also had to model other parts of the system, i.e. ENV and RBC. In this section, we briefly explore some of the possible options for generating executable code from our model and introduce a new approach for generating code using an experimental tool.
One of the possible approaches for code generation is to use Tasking Event-B  code generation tool. To be able to use Tasking Event-B, we will need to refine the VBD model further until we have concrete data structures and events. Due to this, the first step for using the tool and also tackling the complexity of the model (through separating different components of the system) could be model decomposition . Decomposing VBD from the rest of the model will allow us to focus on this component and refine it towards a concrete level. At the most concrete level, we should provide explicit control flow for the model. The tool is able to generate code for a number of different target languages based on the provided control structure and the model. The tool has been used with Rodin 3.3 for generation of executable code from an Event-B model of an intelligent runtime management software for multi-core embedded platforms .
Tasking Event-B has some limitations that makes it difficult to use in some cases. For instance, the tool facilities for defining program structure is restricted (e.g. nested structures are not supported) and only supports concrete structures .
Since the gap between the abstract data structures used in our model and concrete data structures that should be used in an efficient implementation is rather large, and due to the aforementioned limitations, Tasking Event-B could not be used until the model is further refined. Based on this, we decided to use a new experimental tool called SEB-CG  for providing some suggestions on how we can derive code from our abstract model.
SEB-CG implements the ideas presented in  and  where Event-B models are augmented with a schedule. The schedule makes the control flow between events explicit from the abstract level by allowing schedule refinement along with the Event-B refinement. Similar to Tasking Event-B, generating executable code with SEB-CG can be done if the model is refined to a concrete level. However, the SEB-CG support for abstract control structures (i.e. iterations and choices) in addition to concrete ones (i.e. loops and branches) and its flexibility in defining nested program structures makes it useful for deriving the algorithmic structure of the model even if the final concrete model is not constructed yet.
The above schedule refinement refines the abstract choice given in schedule code0 to concrete if..else branches. The explicit branch conditions are extracted from the respective event guards. Since the model is still abstract, some of the computations required for deciding which case should be executed are specified using event parameters and guards. At this stage, we translate those parameters and their guards to an existential quantifier. These existential quantifications can be seen as the specification of other procedures, so if there is a procedure that satisfies this existential quantification then the quantification in the branch condition can be replaced by a procedure call to that procedure (which should return a boolean value) in code level. Using an approach similar to , it is possible to transform the guards to a set of pre- and post-conditions in a language which is supported by a static verifier and then implement and verify the aforementioned procedures there.
Using the above approach, we can gain insight into the structure of the final implementation even though the model is not refined to a concrete level yet. The difficulty of refining the Event-B model of a complex example, such as the one in this paper, to a level where all the event parameters and abstract data structures can be replaced by concrete variables, suggests the need for a combinational approach where high-level properties are specified and verified in Event-B and low level code-oriented properties are verified using a program verifier.
7 Other observations
In this section, we identify some ambiguities and limitations in the HLIII specification document and suggest improvements. We also suggest some improvements to the tools based on our experience of modelling the HLIII, some of which are already in progress.
SpecificationsThe specification document  mentions several times, ‘while the MA is still valid’; however, the document does not explain when an MA becomes invalid. As we have shown in , revoking an MA can lead to an unsafe state. Similarly, the specification mentions that the MA can be ‘impacted’, but does not explain how. In some scenarios (e.g. scenario 6), the MA has changed between steps. We assume this is a mistake in the specification since otherwise the MA appears to have been revoked. As mentioned earlier in Sect. 5.2, the rationale for running the VSS state-machine twice in the case of TTD and PTD trigger events should have been explained and emphasised more. This led to us making incorrect assumptions about the behaviour of our model. In the VSS state-machine transitions table , the condition for #6A is ‘integral train has left the evaluated VSS’. When modelling the conditions for the transitions, we missed the case where TTD is free. Although this is covered by an integral train leaving the VSS, it was only discovered by running the scenarios. It would be better to present this condition clearly as a separate transition (i.e. introduce new condition #6B: TTD is free). Moreover, transition #7A changing the state of a VSS from Open image in new window to Open image in new window , if the evaluated VSS is part of a train memorised location with an expired mute timer or no communication session, has a priority over #6A which changes the state of the VSS from Open image in new window to Open image in new window . Does this priority still hold if TTD is free?
In scenario 6, which covers the case of a train losing its radio communication and later reconnecting, there is a discrepancy with Sec. 220.127.116.11.2 in p.16 of , which describes the change in the VSS state-machine to free as one of the stopping events for the disconnect propagation timer. On the other hand, in steps 4 , 5, when vss12 becomes free the timer should be stopped according to p.16. Hence, it cannot expire in step 5. The scenario also did not mention the start of the propagation timer for vss21 and vss22, because both sections are part of a train MA for which the mute timer has expired. In this case, one of these timers can expire and the transition should be #1C instead of #1D in step 5 of scenario 6, i.e. the VSS state will become Open image in new window due to the expiry of a propagation timer on the same TTD (#1C) rather than a different TTD (#1D).
The iUML-B diagrammatic notation helped us to express and communicate the models between the team members and followed naturally from our system analysis and review meetings. In later stages when substantial reworking of the model was required, the diagrams somewhat hindered progress because changes often have to be repeated throughout the refinement chain. As a result, we intend to improve the refactoring features of iUML-B tooling.
It would have been useful to be able to structure the model into components for VBD, RBC and ENV. Model composition tools, based on inclusion of machines , are available but are not yet compatible with iUML-B. We are developing a containment mechanism so that iUML-B can be used with inclusion. In future work, we will re-structure the model to assess these composition techniques.
Our experiences of replaying large and detailed scenarios gave us strong motivation to improve tool support for running scenarios. The CODA Oracle Simulator has some useful features but still requires each event of the system and controller to be manually selected in the correct sequence. When replaying scenarios, any differences in state or enabledness due to a change in the model are discovered and halt the reply. This could be improved if the user was able to configure which are the important observable variables and events that should match the recording and which are internal detail that may be allowed to vary.
Our work on the HLIII specification began in the case study track of the ABZ 2018 conference. In this section, we compare our approach  with the six other contributions to the ABZ 2018 Case study track.
Three of these approaches [31, 32, 33] are based on Event-B and use theorem proving to verify the main principles behind the specification irrespective of scenarios. These contributions, like ours, are based on abstraction and refinement rather than the operational details of the VBD scenarios. Of these theorem proving contributions, Mammar et al.  covered the most detail including the VBD state-machine behaviour, albeit in a rather cumbersome last refinement with a single update event. Fotso et al.  use a goal structured analysis (KAOS) to drive the refinement structure but do not model the closed system (i.e. including environment). Abrial’s Event-B contribution  focuses on synthesising a clearer statement of the requirements and consequently does not progress beyond the first abstract model. The model does, however, include a substantial, though simplified, subset of the requirements which prove the main principle of the VBD. We agree with Abrial that the specification is operational (or analytic) in nature. Hence, our systems analyses to extract the requirements of the VBD subsystem and our reports of increasing our understanding through iterative modelling attempts.
The remaining three contributions do not attempt any abstraction but model the concrete specification as faithfully as possible in order to model check or animate it to discover bugs against the scenarios. Cunha et al.  do this using Electum (an extension of Alloy) and the Analyzer model checker, and Arcaini et al.  use Promela with the Spin model checker. Hanson et al. use ProB to execute ‘classical’ B  to demonstrate the specification controlling an actual (test) railway system. This contribution does not need to model the environment since it validates via ‘Model-in-the-loop’.
Although our ABZ contribution lacked the VBD state-machine behaviour needed to validate scenarios, we have now ‘caught up’ by making further refinements to model the state-machine via a triggering process. In this paper, we attempt to achieve the best of both: the proof of the abstract principles of safe operation and the validation of the operational specification against its scenarios.
Train control is a familiar domain for Formal Methods, and specifically for B and Event-B-based approaches. Butler et al.  give a methodical treatment of the diagrammatic modelling of the rail interlocking system Railground with both iUML-B and Event Refinement Structures . In , the authors present the Event-B development of a Communications-based Train Control (CBTC) system from Hitachi Ltd. Their focus is on the use of Abstract Data Types (ADTs) to manage the complexity of modelling a graph-based rail network and its dynamics. This example is comparable to European Rail Traffic Management System (ERTMS) Level 3 and uses moving blocks. The authors further proposed  the extension of iUML-B to support diagrammatic modelling of ADTs, using the same Railground case study as .
Other related work such as  on Hybrid ERTMS Level 3 is based on moving blocks. These models are hybrid, being concerned with continuous modelling of exact train position and speed reporting. This ABZ2018 case study is the first formal examination of fixed virtual blocks that we are aware of.
Systems analysis to synthesise requirements from a detailed operational specification.
Iterative formal modelling to develop our understanding of the requirements.
Abstraction of the environment and important safety properties as a formal model.
Refinement to introduce an abstract model of the VBD control component.
Refinement to introduce operational details of the VBD control component.
Use of diagrammatic modelling notations to increase understanding and structuring of the models.
Validation of the models by animation of the given scenarios.
Preliminary work towards generating an implementation.
Our formal verification using theorem provers, of the safety of the HLIII specification, has been extremely beneficial in identifying potential problem areas. While industry experts are aware of the engineering decisions behind the specification, unverifiable safety requirements have encouraged re-consideration of some critical behaviours in the specification. To influence a major European standard is a significant achievement. Our model captures the abstract principles behind HLIII and refines them with the full operational details of the specified state-machine behaviour.
For validation, we used a ‘scenario checker’ plug-in tool to enhance ProB animation and BMotionStudio to visualise the state being checked. We discovered one area in the scenarios, where our model deviates from the expected behaviour. The failure of the ‘jumping trains’ scenario requires a new iteration of the model, where we will mainly focus on updating the VBD front and rear position separately.
Controlled and trusted (trains) are terms that we have introduced, they are not terms from the specification.
Where \(\sim \) is an inverse relation and [ ] are relational image. A concise summary of Event-B syntax is available at http://wiki.event-b.org/images/EventB-Summary.pdf.
Note that class invariants are implicitly quantified over instances of the class, hence the antecedent Open image in new window is added automatically.
This work has been conducted within the ENABLE-S3 project that has received funding from the ECSEL Joint Undertaking under Grant Agreement no. 692455. This Joint Undertaking receives support from the European Union’s HORIZON 2020 research and innovation programme and Austria, Denmark, Germany, Finland, Czech Republic, Italy, Spain, Portugal, Poland, Ireland, Belgium, France, Netherlands, UK, Slovakia, and Norway.
- 1.EEIG ERTMS Users Group.: Principles: Hybrid ERTMS/ETCS Level 3, 1c edition, July (2018). https://ertms.be/sites/default/files/2018-07/16E0421C_HL3-clean.pdf. Accessed 24 Jan 2019
- 8.Beato, M.E., Barrio-Solórzano, M., Cuesta, C.E., de la Fuente, P.: Formal methods for UML. In: Gabbar, H.A. (ed.) Modern Formal Methods and Applications. Springer, Dordrecht (2006)Google Scholar
- 10.Snook, C.: iUML-B statemachines. In: Proceedings of the Rodin Workshop 2014, pp. 29–30, Toulouse, France http://eprints.soton.ac.uk/365301/ (2014). Accessed 7 Nov 2019
- 12.Kossak, F., Mashkoor, A., Geist, V., Illibauer, C.: Improving the understandability of formal specifications: an experience report. In: Proceedings of the 20th International Working Conference on Requirements Engineering: Foundation for Software Quality—Volume 8396, REFSQ 2014, pp. 184–199. Springer, Berlin (2014)CrossRefGoogle Scholar
- 13.Pang, C., Pakonen, A., Buzhinsky, I., Vyatkin, V.: A study on user-friendly formal specification languages for requirements formalization. In: 14th IEEE International Conference on Industrial Informatics, INDIN 2016, Poitiers, France, July 19–21, 2016, pp. 676–682. IEEE (2016)Google Scholar
- 17.EEIG ERTMS Users Group.: Principles: Hybrid ERTMS/ETCS Level 3. http://www.southampton.ac.uk/assets/sharepoint/groupsite/Academic/ABZ-Coneference-2018/Public. Accessed 18 Jan 2018
- 18.Hoang, T.S.: An introduction to the Event-B modelling method. In: Industrial Deployment of System Engineering Methods, pp. 211–236. Springer, Berlin (2013)Google Scholar
- 22.Edmunds, A., Butler, M.: Tasking Event-B: an extension to Event-B for generating concurrent code. In: PLACES2011 April (2011)Google Scholar
- 23.Butler, M.: Decomposition structures for Event-B. In: International Conference on Integrated Formal Methods, pp. 20–38. Springer, Berlin (2009)Google Scholar
- 24.Dalvandi, M., Fathabadi, A.S., Butler, M.: A report on PRiME code generation activities. In: 7th Rodin Workshop (05/06/18), June (2018)Google Scholar
- 25.Dalvandi, M., Butler, M., Fathabadi, A.S.: SEB-CG: Code generation tool with algorithmic refinement support for Event-B. In: Workshop on Practical Formal Verification for Software Dependability (AFFORD’19) (2019)Google Scholar
- 27.Dalvandi, M., Butler, M., Rezazadeh, A., Fathabadi, A.S.: Verifiable code generation from scheduled Event-B models. In: International Conference on Abstract State Machines, Alloy, B, TLA, VDM, and Z, pp. 234–248. Springer (2018)Google Scholar
- 28.Dalvandi, M., Butler, M., Rezazadeh A.: Transforming Event-B models to Dafny contracts. In: Electronic Communications of the EASST, vol. 72 (2015)Google Scholar
- 29.Eysholdt, M., Behrens, H.: Xtext: Implement your language faster than the quick and dirty way. In: Proceedings of the ACM International Conference Companion on Object Oriented Programming Systems Languages and Applications Companion, OOPSLA ’10, pp. 307–309. ACM, New York, NY, USA (2010)Google Scholar
- 30.Hoang, T.S., Dghaym, D., Snook, C., Butler, M.: A composition mechanism for refinement-based methods. In: Proceedings 2017 22nd International Conference on Engineering of Complex Computer Systems: ICECCS 2017. IEEE (2018)Google Scholar
- 32.Fotso, S.J.T., Frappier, M., Laleau, R., Mammar, A.: Modeling the Hybrid ERTMS/ETCS Level 3 standard using a formal requirements engineering approach. In: Butler, M., Raschke, A., Hoang, T.S., Reichl, K. (eds.) Abstract State Machines, Alloy, B, TLA, VDM, and Z, pp. 262–276. Springer International Publishing, Cham (2018)CrossRefGoogle Scholar
- 33.Mammar, A., Frappier, M., Fotso, S.J.T., Laleau, R.: An Event-B model of the Hybrid ERTMS/ETCS Level 3 standard. In: Butler, M., Raschke, A., Hoang, T.S., Reichl, K. (eds.) Abstract State Machines, Alloy, B, TLA, VDM, and Z, pp. 353–366. Springer International Publishing, Cham (2018)CrossRefGoogle Scholar
- 36.Hansen, D., Leuschel, M., Schneider, D., Krings, S., Körner, P., Naulin, T., Nayeri, N., Skowron, F.: Using a formal B model at runtime in a demonstration of the ETCS Hybrid Level 3 concept with real trains. In: Butler, M., Raschke, A., Hoang, T.S., Reichl, K. (eds.) Abstract State Machines, Alloy, B, TLA, VDM, and Z, pp. 292–306. Springer International Publishing, Cham (2018)CrossRefGoogle Scholar
- 37.Butler, M., Dghaym, D., Fischer, T., Hoang, T.S., Reichl, K., Snook, C., Tummeltshammer, P.: Formal modelling techniques for efficient development of railway control products. In: RSSRail 2017, Pistoia, Italy, 2017, volume 10598 of LNCS, pp. 71–86. Springer (2017)Google Scholar
- 39.Hoang, T.S., Snook, C., Dghaym, D., Butler, M.: Class-diagrams for Abstract Data Types. In: ICTAC 2017, Hanoi, Vietnam, 2017, Proceedings, volume 10580 of LNCS, pp. 100–117. Springer (2017)Google Scholar
- 40.Platzer, A., Quesel, J.-D.: European Train Control System: a case study in formal verification. In ICFEM 2009, Rio de Janeiro, Brazil, 2009. Proceedings, volume 5885 of LNCS, pp. 246–265. Springer (2009)Google Scholar
Open AccessThis article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.