A Refinement-based Formal Development of Cyber-physical Railway Signalling Systems

2.1 Event-B

The Event-B mathematical language used in the system development and analysis is an evolution of the classical B method [1] and Action Systems [5]. The formal specification language offers a fairly high-level mathematical language based on a first-order logic and Zermelo-Fraenkel set theory. The formalism belongs to a family of state-based modelling languages where a state of a discrete system is simply a collection of variables and constants whereas the transition is a guarded variable transformation.

A cornerstone of the Event-B method is the step-wise development that facilitates a gradual design of a system implementation through a number of correctness preserving refinement steps. The model development starts with a creation of a very abstract specification and the model is completed when all requirements and specifications are covered. The Event-B model is made of two key components—machines and contexts that, respectively, describe dynamic and static parts of the system (see Listing 1). The context contains modeler declared constants and associated axioms that can be made visible in machines. The dynamic part of the model contains variables that are constrained by invariants and initialised by an action. The state variables are then transformed in guarded events using a before-after predicate (BAP) linking the state of the variable before and after the event. The event’s guard determines when the event may be triggered.

Fig. 1.

View Figure

Listing. 1.

View Figure

The Event-B method is a proof driven specification language where model correctness is demonstrated by generating and discharging proof obligations—theorems in first-order logic and set theory. Table 1 shows the key proof obligations associated to any Event-B model, and constructed from that model’s axioms (\( A \)), theorems (\( T \)), invariants (\( I \)), guards (\( G \)), variants (\( V \)), and \( BAP \). The model is considered to be correct when all proof obligations are discharged.

Rodin [33] is an open source, Eclipse-based, integrated development environment (IDE) for Event-B model development. The Rodin is a core set of plug-ins for project management, formal development, syntactic analysis, proof assistance and proof-based verification. Moreover, it also allows for extension points to support a range of additional plugins to provide different functionalities and features related to model checking, animation, code generation, additional proof capabilities (including calls to SMTs or external provers such as Why3 or Isabelle), composition and decomposition, refactoring framework, and model editors.

Even though, the Event-B mathematical language is expressive enough for a lot of useful mathematical concepts it is still desirable to allow users extending the language. For that reason a theory extension process has been developed and realized as a Rodin platform plug-in. With the theory extension approach, new theories, which include datatypes, operators, and proof rules, can be defined and proved to be sound through generated proof obligations.

2.2 Modelling Hybrid Systems in Event-B

Event-B is particularly adapted to the development of discrete systems, thanks to its semantics. Since its expression language is based on first-order logic and set theory, however, it is possible to express continuous behaviours, as high-level mathematical constructs, and handle them in Event-B models.

The approach of Dupont et al. [15, 16] takes advantage of this to propose a generic and reusable modelling framework for designing hybrid systems in Event-B.

2.2.2 Embedding Continuous Features in Event-B.

Even though the Event-B mathematical language is expressive enough for a lot of useful mathematical concepts, it is still desirable to allow users extending the language. For that reason an extension process has been proposed, under the form of theories [13]. With the theory extension approach, new theories, which include data types, operators, and proof rules, can be defined and their correctness proved by discharging generated proof obligations.

Theories are used to define continuous constructs, required for hybrid system design, and, in particular, differential equations, as well as the continuous before-after predicate defined in Section 2.2.1. Listing 2 gives an excerpt of the theory defined and used throughout the Event-B development.

Fig. 2.

View Figure

listing. 2.

View Figure

In particular, it defines the following operator and expressions:

• \( \mathbf {ode}(F,\eta _0,t_0) \) is an ordinary differential equation (ODE) \( \dot{\eta }(t) = F(t,\eta (t)) \) with initial condition \( \eta (t_0) = \eta _0 \).

• \( \mathbf {DE}(S) \) is a set of differential equations with solutions valued in \( S \) (the continuous state space).

• \( \mathbf {solutionOf}(D, \eta ,eq) \), with \( D \subseteq \mathbb {R} \), \( \eta \in D \rightarrow S \) and \( eq \in \mathbf {DE}(S) \), is a predicate indicating that \( \eta \) is a solution of \( eq \) (on domain \( \mathsf {D} \)).

• \( \mathbf {Solvable}(D ,eq) \) is a predicate indicating that there exists a solution to equation \( eq \) on domain \( D \).

2.2.3 Generic Hybrid System Model.

The core of the methodology for designing hybrid system models using Event-B is a so-called generic model, encompassing both the discrete and the continuous part of the model, following the diagram presented in Figure 1. In this pattern, the discrete controller (Ctrl) controls a physical phenomenon (Plant). It may detect variations of the plant’s state through sensing, and may influence its behaviour with actuations. As a physical object, the plant is subject to its environment; meanwhile, the controller may be piloted through user commands.

The characteristics of this model are abstracted using event parameters (ANY clause). They can be given at any time during refinement using witnesses (instantiation).

Variables and State Spaces. A hybrid system is modelled through two variables: its discrete state \( x_\mathit {st} \) and its continuous state \( x_p \). Discrete state \( x_\mathit {st} \) is taken in the set of possible discrete states, \( \mathsf {STATES} \), which usually correspond to the possible modes of the controller. Continuous state \( x_p \) is a function of time and valued in state space \( S \) (usually a real vector space). As we will need it in subsequent proofs or properties, we also model time with a single read-only variable (\( t \)). By convention, this variable evolves in the set of positive or null reals (\( \mathbb {R}^+ \)), and starts at 0. Listing 3 gives the header of the generic model.

listing. 3.

View Figure

Discrete Behaviour. The behaviour of hybrid systems consists of a discrete and a continuous part. Discrete behaviour is captured by discrete events, that represent changes in the system’s discrete state (i.e., of the discrete variables). Transition events model internal controller changes, while Sense events model controller changes induced by the evolution of the continuous part, as denoted by a guard involving the continuous state \( x_p \) (see Listing 4).

Listing. 4

View Figure

Continuous Behaviour. Continuous behaviour is described by continuous events. These events update the system’s continuous variables using the CBAP operator (see Section 2.2.1), and add whole time intervals to the system’s trace.

Continuous events are split in two categories: Behave events capture spurious changes and perturbations in the plant, and are used to model the environment. At this level of abstraction, Behave are unconstrained, as symbolised by the use of \( \top \) (meaning the evolution domain is the whole space).

Actuate events model changes in the plant induced by the controller (i.e., actuation). Note, in particular, that actuation events are tied to a controller mode (see Listing 5).

Listing. 5.

View Figure

To establish that the CBAP use is correct, we need to ensure predicate \( \mathcal {P} \) is feasible, that is \( \begin{equation*} \begin{split} \exists x_p^\prime \cdot x_p^\prime \in \mathbb{R}^+ ⇸ S \wedge [t,t^\prime] \subseteq \text{dom}(x_p^\prime) \wedge & ([0,t] \lhd x_p) \mapsto ([t,t^\prime] \lhd x_p^\prime) \in \mathcal{P} \wedge \\ & \forall \hat t \cdot \hat t \in [t,t^\prime] \Rightarrow x_p^\prime(\hat t) \in H. \end{split} \end{equation*} \)

This is enforced by guard \( \mathsf {grd_2} \) using the \( \mathbf {Feasible} \) predicate. Upon refining the event, guard strengthening will require that the provided parameters (\( H \) and \( \mathcal {P} \)) satisfy this predicate and thus that the instantiation provides feasible behaviours.

3.1 Methodology Overview

The proposed methodology is a two-stage formal development methodology with the Event-B formal specification language at its core (illustrated in Figure 2). The main outcome of the methodology is a formal Event-B model of a signalling system that is developed by refining a provided generic communication-based signalling Event-B model \( {\mathcal {M}} \) with particular signalling system specifications (defined in the first step of the methodology). Safety system aspects are of the utmost importance and are ensured by mathematically proving an instantiated model with respect to user-defined safety requirements.

The proposed development methodology is built upon an established Event-B formal modelling environment. The development of the Event-B model of a cyber-physical signalling system is facilitated by the Rodin platform, which provides a graphical user interface to developing models, automated proof obligation generation, verification tools and other plug-ins. One of the essential Rodin extensions is the Theory plug-in [13], which makes it possible to extend the Event-B mathematical language with new mathematical theories. The developed Event-B model of a cyber-physical railway signalling depends on continuous system modelling theories and patterns introduced and implemented using the Theory plug-in by Dupont et al. [15]. One of our previous contributions [31] was developing an Event-B domain theory \( {\mathcal {T}} \), which formally defines dynamics of rolling stock by utilising hybrid modelling theories [15] and the Theory plug-in. The communication modelling patterns were developed and implemented without using the Theory plug-in.

The second group of Rodin extensions our methodology relies upon are concerned with the verification and validation of a model. To support a deductive model verification, Rodin provides extensions to a number of automated provers (e.g., Reference [24]) that attempt to automatically discharge generated proof obligations. Models developed in the Rodin platform can also be validated and animated using the ProB toolset, which can be particularly useful in early modelling stages where it could be too onerous to deductively verify a model. Furthermore, deductively proving properties like deadlock-freedom or liveness in the Event-B setting can be challenging. Therefore, in some instances ProB can provide a more pragmatic model-checking-based solution for validating properties properties that are not concerned with safety. The current Rodin version does not provide a practical method for reasoning about stochastic system properties. To meet a requirement for our methodology, we utilised a well-known probabilistic model checker PRISM [21] and prove probabilistic properties outside of the Rodin environment.

By using the Event-B our methodology aims to demonstrate that the cyber-physical signalling system satisfies the formulated safety requirements.

3.2 System Specifications and Requirements

The generally accepted approach to any system formal development is starting a development process by informally describing system specifications and requirements. Therefore, the first development step in our methodology is defining system specifications and requirements concerned with the specific cyber-physical railway signalling system configuration.

At this formal development stage, the proposed methodology requires labelling system specifications and requirements. By labelling requirements and specifications, we intend to ensure a traceability between informal and formal methodology artefacts. The traceability aspect guarantees the completeness of the model, meaning, that all informal specifications and requirements have been captured by the formal model. On the formal Event-B artefact side, methodology requires to annotate events and invariants of the Event-B model with labelled references to a specific informal artefact (Figure 3). The Rodin platform tools like ProR [25] or others [18, 26] exist for ensuring traceability between formal and informal artefacts. However, both the ProR tool is longer supported and specification approach [18, 26] was not realised as the Rodin plug-in.

Fig. 3.

View Figure

Furthermore, the cyber-physical railway signalling model we consider is a hybrid model, meaning, that system dynamics and physical aspects (e.g., rolling stock properties) must be defined. The generic theory of train dynamics we provide in a model theory \( \mathcal {T} \) extension is parametrised and can be instantiated with specific (e.g., train mass, rail resistance) constants.

3.3 Event-B Model

The formal development of a cyber-physical signalling system Event-B model is the central activity of the methodology. For the formal modelling, the methodology provides an Event-B model of cyber-physical railway signalling system, railway related Event-B theories and Event-B patterns for modelling protocols. To derive a cyber-physical signalling system Event-B model, a developer is required to refine a provided generic Event-B railway model with specific signalling system configurations by using the Event-B refinement mechanism (depicted in Figure 4).

Fig. 4.

View Figure

The generic railway signalling model provided by our methodology includes a new Event-B theory (\( \mathcal {T} \) in Figure 4), which defines continuous rolling stock dynamics with a parameterised first-order non-linear differential equation. Furthermore, the railway model also provides the Event-B context model (\( \mathcal {C} \) in Figure 4) with a pre-defined train stopping distance function, constants related to the engine traction effort and parameters for the equation of train dynamics. The context model of the rolling stock can be further extended by specifying new parameters of the train physical model and updating train speed controller modes.

The proposed development methodology enables extending a generic signalling system Event-B context model that introduces signalling sub-systems and field elements (e.g., communication centres, interlocking boxes, points) with signalling specifications defined in the first phase of the methodology. The system context model can be extended by including new axioms, for example, constraining the number of trains. The process of extending signalling context model with specific cyber-physical system aspects is visualised in Figure 5 as the first step.

Fig. 5.

View Figure

To model an inter-subsystem communication of heterogeneous railway signalling systems, our methodology provides Event-B modelling patterns for a systematic modelling of protocols with Event-B. For example, patterns make it possible to introduce signalling protocol messages and capture message sending/receiving events in the Event-B model (steps 2 and 3 in Figure 5). Communication modelling patterns are templates for defining Event-B variables, machine events, and context models. In the actual Event-B model, templates are instantiated, or in other words, replaced with variables, events, and context models, which represent the actual system and adhere to the rules and structure of the template.

4.1 Informal Communication-based Railway Signalling Model

As previously discussed, we base our railway signalling model on the radio-based communication and in-cab signalling systems, which generally contain three sets of objects: trains, interlocking boxes, and communication centres. On the infrastructure side, our railway model is made of railway tracks, which contain points (\( \mathsf {P1} \) in Figure 6) allowing trains to switch tracks and block markers (\( \mathsf {M_{1..3}} \) in Figure 6) for marking a spatial beginning and ending of railway sections (blocks).

Fig. 6.

View Figure

The objective of the abstract railway signalling model is ensuring a safe spatial separation of trains and preventing train derailment by guaranteeing only locked point crossing. Our abstract signalling model is based on a moving-block signalling principle with points protected with fixed-blocks to prevent a train derailment. In the following paragraphs, we specify the functionality of each object and communication relations with other objects (communication diagram of the signalling model is given in Figure 7).

Fig. 7.

View Figure

Field Elements. Field elements are railway infrastructure elements that make it possible to detect and direct rolling stock as well as transmit information to the train drivers. Examples of field elements include:

Rolling Stock. In our signalling model trains are modelled by their physical (continuous) state as well as the mode (discrete) of their on-board computer. The physical state of a train evolves according to some differential equations with equation parameters controlled by the discrete mode of the on-board computer. The signalling model also assumes that a train is able to self-localise and communicate with other objects. In our abstract signalling model a train can send three types of messages:

Communication Centres. In the communication-based signalling systems, a communication centre is a pivotal object that manages a part of a railway network by interacting with rolling stock and interlocking boxes. A communication centre uses information received from trains and interlocking boxes to issue allowed travelling distances to individual trains. A centre contains and continuously updates an internal railway network map with junction locations (also their status: free or locked) and rolling stock positions. The model assumes that a communication centre knows the destination of each train, so points can be locked in the correct direction. The communication centre can send the following messages:

Interlocking Boxes. An interlocking is a safety-critical object responsible for authorising rolling stock and infrastructure movement of infrastructure (e.g., points). In our signalling model, the function of an interlocking box is guaranteeing safety by preventing trains crossing the same junction at the same time (e.g., \( \mathsf {P1} \) in Figure 6). An interlocking can send the following messages to a communication centre:

4.2 Continuous Rolling Stock Model

In this section, we describe the mathematical model of rolling stock continuous dynamics, which will be used as a basis to modelling hybrid train dynamics in Event-B. The section begins by deriving a realistic acceleration differential equation from fundamental laws of physics and models of rolling bodies. In the following paragraph, we describe a hybrid train speed controller model, which will be used in the generic railway signalling Event-B model.

A driver or an automated train operation system can only control the train engine power (tractive force \( f \)), which eventually yields an acceleration, and is bounded by two constants \( f_\mathit {min} \) and \( f_\mathit {max} \). From Newton’s second law, we know that acceleration is proportional to a net force (tractive engines force) applied to the mass of that object. The train must also overcome a resistance force, which acts in the opposite direction to engines traction force and thus a total engines tractive force can be expressed as the difference between two forces. The total rolling stock resistance is comprised of the mechanical and air resistances, and commonly expressed as a second-order polynomial (Davis Resistance equation \( \mathsf {R_{tot.}(t)} \) in Equation (1)), where \( \mathsf {a, b, c} \) are fixed parameters and \( \mathsf {v(t)} \) is the speed of a train at time \( \mathsf {t} \) [29]: (1) \( \begin{equation} \left\lbrace \begin{array}{ccl} \dot{tv}(t) & = & f - (a + b\cdot tv(t) + c\cdot tv(t)^2), \\ \dot{tp}(t) & = & tv(t). \end{array}\right. \end{equation} \)

The train speed controller we consider is repeatedly issued with the end of movement authority (EoA), which is updated discretely in the time by the communication centre. We assume that the speed controller is able to sense its distance to \( \mathsf {EoA} \) and, in particular, determine if with a given current speed and acceleration it can stop before \( \mathsf {EoA} \). The stopping distance calculus is generally done by a complex algorithm on the on-board computer, whereas in our train model, we abstract the algorithm by a stopping distance function (StopDist), which takes the current acceleration and speed as parameters, and returns the distance needed by the train to stop.

The model we developed can be split in two parts. The first part captures the role of the on-board train computer, responsible for the train speed supervision. Particularly in the moving block signalling systems, the absence of head to tail train collisions rely not only on correctly issued movement authority but also on-board speed controller. One can express the safety property as follows: At all times the train must remain within the issued movement authority. Additionally, the system also observes some specific physical properties; in particular, a train cannot go backward, meaning its speed must remain positive (or null) all time (refer to Table 2).

5.1 Event-B Model of a Cyber-physical Railway Signalling System: Rolling Stock

The train speed controller controls the engine power (\( f \)) of the train, depending on its status (position, speed, acceleration) and, in particular, its distance to the \( \mathsf {EoA} \).

The train speed controller has two modes: \( \mathsf {free \; mode} \) and \( \mathsf {restricted \; mode} \). If the stopping distance (plus a safety offset) of the train is shorter than \( \mathsf {EoA} \), then the train is said to be in \( \mathsf {free \; mode} \) and it can choose arbitrary values for \( \mathsf {f} \). Whenever the stopping distance (\( \mathsf {+offset} \)) of the train becomes greater than \( \mathsf {EoA} \), the train enters \( \mathsf {restricted \; mode} \), and the controller is required to provide values for \( \mathsf {f} \) such that it can stop before \( \mathsf {EoA} \).

The train speed controller hybrid automaton model is visualised in Figure 8. In the following sections, we present a formal Event-B implementation of the informally presented hybrid signalling model.

Fig. 8.

View Figure

5.1.1 Train Domain Theory.

Common properties of the train are gathered in the Train domain theory, an extract of which is given in Listing 6. This theory mainly defines the Davis equation (\( \mathsf {DavisEquation} \)) of coefficient \( a \), \( b \), and \( c \) and for a traction force of \( f \), with initial condition \( p(t_0) = p_0 \) and \( v(t_0) = v_0 \). This equation corresponds to Equation (1).

Listing. 6.

View Figure

The theory also defines a few properties, that are useful when proving the models. In particular, a theorem is given that allows to deduce solvability of the Davis equation, which is crucial in establishing that the dynamics of the system are always feasible.

5.1.2 Train Model Static Informations.

In addition to the train’s dynamics, we gathered model-specific information in the TrainCtx context (see Listing 7). The context defines several constants of the system, as well as constraints on them. In particular, Davis coefficients are given (\( a \), \( b \), \( c \)), as well as the bounds on the train’s traction power (\( f_{min} \), \( f_{max} \)).

Listing 7.

View Figure

Furthermore, we define a train stopping distance function \( \mathsf {StopDist} \) as a function of the current speed and acceleration with associated function constraining axioms. Finally, we define train controller modes \( \mathsf {free\_move} \) and \( \mathsf {restricted\_move} \) by refining the \( \mathsf {STATES} \) set with an enumerated set.

5.1.3 Hybrid Rolling Model.

In the first refinement of the generic hybrid model, we introduce several new events that instantiate generic events presented in Section 2.2. Because of the similarity of events, we only provide a single event for each of the generic event type. As specified in the previous subsection, in this refinement, we model the speed controller where the end movement authority is regularly updated, without specifying exactly how it is issued at this level of abstraction.

Machine header. Listing 8 presents the train model header. The train model features five variables in addition to time. The train itself is modelled using its position, speed, and acceleration (\( tp \), \( tv \) and \( ta \), respectively), as well as its traction power (\( f \)). Additionally, the end of authority is modelled by a real variable, \( \mathsf {EoA} \). Each variable is associated to a number of constraints (invariants 1 to 4), plus a gluing invariant that links the concrete and abstract continuous states (\( \mathsf {inv_5} \)). In addition, both safety requirements proposed in Section 4.2 (invariants \( \mathsf {saf_1} \) and \( \mathsf {saf_2} \)).

Listing 8.

View Figure

Discrete events. The \( \mathsf {Transition\_restricted\_move} \) (see Listing 9) event models the change in the speed controller by adjusting trains traction effort when the train is in the restricted move mode. The event is simply guarded by a single predicate that enables event if and only if the status variable \( \mathsf {x_\mathit {st}} \) is set to \( \mathsf {restricted\_move} \). To control train’s speed, we created a variable \( f \) that denotes the traction force and is modified by the action such that the stopping distance would not overshoot the end of the movement authority. One must then prove an open proof obligation that such traction force value can be found.

Listing. 9.

View Figure

Another internal controller event that changes controllers mode based on the input from the plant is sense event—\( \mathsf {Sense\_to\_restricted} \) (see Listing 10). One of the two sense events will change the train state variable \( \mathsf {x_\mathit {st}} \) if the end of movement authority has not been extended and train must decelerate to remain within issued movement authority.

Fig. 10.

View Figure

Continuous Events. The \( \mathsf {Actuate\_move} \) event (see Listing 11) is the main continuous event of the model. It models the dynamics of the train, using the CBAP operator (see Section 2.2.1) together with the Davis equation defined in the Train theory (see Section 5.1.1). The proposed evolution domain ensures that (1) the train remains before the end of authority, and (2) the train’s speed remains positive, in accordance with the system’s safety invariants.

Listing. 11.

View Figure

Note that the parameters of the generic model are refined using witnesses (WITH clause) as to match the CBAP of \( \mathsf {act_1} \) and the gluing invariant (\( \mathsf {inv_5} \)).

5.2 Event-B Model of a Cyber-physical Railway Signalling System: Other Sub-Systems

To introduce other sub-systems and a communication protocol of the signalling system, the train speed controller model was further refined based on communication modelling patterns [32] (and diagram visualised in Figure 5) by introducing new context and machine models. According to the patterns, we first created a new context model (Listing 12) where new finite carrier sets representing trains (\( \mathsf {TRN} \)), communication centres (\( \mathsf {CCS} \)), interlocking boxes (\( \mathsf {IXL} \)), and points (\( \mathsf {PNT} \)) with their status were introduced. In the following paragraphs, we describe a part of the cyber-physical railway signalling model, which captures a train requesting movement authority extension and a communication-centre responding.

Listing. 12.

View Figure

Following the message modelling pattern (see Section IV.B of Reference [32]), for each type of protocol message, an individual context will be introduced that defines the new message type with constant functions defining source, destination and value of the message. In context excerpt (Listing 13), the \( \mathsf {ma\_extension} \) message is defined, which is sent by a communications centre to a train (\( \mathsf {movement\_authority\_extension} \) in Figure 7) with an updated movement authority. The constant (surjective) functions are used to select an appropriate message, which includes a source, destination and value of the message. In the case of \( \mathsf {movement\_authority\_extension} \) message: ranges of source \( \mathsf {exts} \) (\( \mathsf {axm_1} \)) and destination \( \mathsf {extd} \) (\( \mathsf {axm_2} \)) functions are, respectively, communication centre and range train sets, while the range of value function \( \mathsf {extv} \) is a set of real numbers (\( \mathsf {axm_3} \)).

Listing. 13.

View Figure

In the dynamic model (machine) part, we introduce communication channels for the new messages, which includes one for the \( \mathsf {movement\_authority\_extension} \) message \( \mathsf {ext} \) (see Listing 14). The model excerpt also contains another channel \( \mathsf {req} \) for requesting movement authority extension messages and a variable \( \mathsf {reqt} \). The latter variable is simply used to track sent messages locally as messages are added and removed from the channel. Once communication channel variables are introduced, events can be refined or new events introduced to capture the process of message sending and receiving.²

Listing. 14.

View Figure

The \( \mathsf {Trains\_sense\_to\_restricted} \) event (see Listing 15) which models the controller state change once the train enters the area where it must decelerate to stay within the movement authority. For a train to continue to travel, it must request the movement authority extension by sending a message to the communication centre. We model that by refining the \( \mathsf {Sense\_to\_restricted} \) event by first adding additional event parameters denoting a train \( \mathsf {tr} \), communication centre \( \mathsf {rb} \), and a request message \( \mathsf {rq} \). Then, we include new guards \( \mathsf {grd_{2..6}} \), which define variable types and state that \( \mathsf {rq} \) must be a new message with destination to specific communication centre \( \mathsf {rb} \) and source of the train of interest \( \mathsf {rq} \). The message \( \mathsf {rq} \) also includes the current position of the train at time \( t \) (\( \mathsf {grd_7} \)), which can be accessed via train position function \( \mathsf {ntp(tr)} \). New actions of the events \( \mathsf {act_{2..3}} \) add the new message to the request message channel \( \mathsf {req} \) and saves a sent message receipt locally.

Listing. 15.

View Figure

To model \( \mathsf {movement\_authority\_extension} \) message sending, we apply a reply message modelling pattern that adds a new message to the channel and removes the replied message. To avoid having a single super-event, it was decided to split message sending into two events that, respectively, model movement authority extension over a line and over a point. Listing 16 describes an event for movement extension over a line. First, the guards (\( \mathsf {grd_{1..6}} \)) check if an adequate request \( \mathsf {rq} \) message has been received and new extension message \( \mathsf {ex} \) will be sent to the source train \( \mathsf {grd_5} \). The value of the reply message contains a distance value, which is shorter than a distance to the next train and point (\( \mathsf {grd_{8..9}} \)), but greater than the current end of the movement authority (\( \mathsf {grd_7} \)). The event actions simply create a new extension message and remove the responded message. A similar event was created to capture the second branch when a point must be locked by communicating with an interlocking.

Listing. 16.

View Figure

The final event in the message exchange cycle for requesting movement authority extension is the refined event \( \mathsf {Trains\_transition\_eoa} \) (Listing 17). Originally, this event was introduced in modelling train speed controller to abstractly represent the internally updated movement authority. To introduce communication aspect to this event, we extend it with additional guards to check if an extension message \( \mathsf {ex} \) has been received to the specific train \( \mathsf {tr} \) (\( \mathsf {grd_{3..5}} \)). The new end of the movement authority value (\( \mathsf {nEoA} \)) is constrained by the value of extension message (\( \mathsf {grd_6} \)). The action of the event simply update trains end of authority variable \( \mathsf {EoA(tr)} \) and deletes the extension message \( \mathsf {ex} \).

Listing. 17.

View Figure

5.3 Event-B Model of a Cyber-physical Railway Signalling System: Proof Statistics

The generic model is proved once and for all, and in this work, we refined the abstract hybrid controller model. The hybrid railway signalling model is itself a reusable artefact, which could be further refined to capture a specific signalling configuration (e.g., by defining a specific railway schema) or modelling railway protocols (e.g., signalling handover).

As discussed by Alur in Reference [3], the verification of hybrid systems remains a challenge. The verification approaches based on the reachability analysis aim to provide a fully automatic verification approach, but due to the real-valued variables, these approaches are limited to linear systems. In this and other related works, authors have tried to address the verification scalability problem, by developing alternative proof-based verification approaches. Still, as our verification results suggest (Table 3) and also similar works [4, 12, 15], the proof automation of hybrid Event-B models is still low and must be improved for more practical applications. In spite of improved verification tools, a refinement plan for hybrid models should be reconsidered. Perhaps, a top-down approach (particularly, for this model), where continuous system’s aspects are introduced in later refinement steps is more suitable.

An important feature of this hybrid system development approach is the requirement of explicitly stating the system’s dynamic properties. In our opinion, this problem is often overlooked and could lead to miscommunication between, for instance, control engineers and software engineers. With our proposed approach, a formal hybrid artefact is created, which can be used between different types of engineers. However, the approach currently requires some understanding of formal methods (e.g., mathematical syntax) and could benefit with connection to more visual widely used tool like Simulink or other similar tools via Functional Mock-up Interface [11].