research-article

Open access

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

Authors:

Alexander Romanovsky,

Paulius StankaitisAuthors Info & Claims

Formal Aspects of Computing, Volume 35, Issue 1

Article No.: 3, Page 1

https://doi.org/10.1145/3524052

Published: 12 January 2023 Publication History

PDF eReader

Abstract

For years, formal methods have been successfully applied in the railway domain to formally demonstrate safety of railway systems. Despite that, little has been done in the field of formal methods to address the cyber-physical nature of modern railway signalling systems. In this article, we present an approach for a formal development of cyber-physical railway signalling systems that is based on a refinement-based modelling and proof-based verification. Our approach utilises the Event-B formal specification language together with a hybrid system and communication modelling patterns to developing a generic hybrid railway signalling system model that can be further refined to capture a specific railway signalling system. The main technical contribution of this article is the refinement of the hybrid train Event-B model with other railway signalling sub-systems. The complete model of the cyber-physical railway signalling system was formally proved to ensure a safe rolling stock separation and prevent their derailment. Furthermore, the article demonstrates the advantage of the refinement-based development approach of cyber-physical systems, which enables a problem decomposition and in turn reduction in the verification and modelling effort.

1 Introduction

Over the past few decades, developments in communication and computing technologies have made it possible for railway engineers to develop novel railway signalling systems. These modern railway signalling systems (e.g., European Train Control System (ETCS) [17] or Communication-based Train Control (CBTC) [23]) are safety-critical cyber-physical transportation systems that aim to improve the capacity, interoperability, and reliability of railway networks. In these modern signalling systems, a train continuously receives a permitted travelling distance via a wireless communication, and an on-board train computer calculates the fitting speed profile. The calculated speed profile of a train is then dynamically followed and supervised by a driver or a computer-based speed controller. The increased dependability on the on-board computers and algorithms for computing, controlling, and monitoring the speed profile of a train requires the highest level of system assurance and poses new challenges to signalling engineers on ensuring the safety of the cyber-physical railway signalling systems.

To achieve such a high-level of safety assurance of those complex signalling systems, scenario-based testing methods are far from being sufficient, despite that they are still widely used in the industry. Alternatively, formal methods have been successfully applied in the railway domain [6, 9] and seem quite fitted for dealing with railway signalling systems. However, little has been done in the field of formal methods to address the cyber-physical nature of modern railway signalling systems. One of the main challenges of model-based cyber-physical signalling system development stems from the necessity to capture and formally reason at a system-level as, for example, safety of these systems heavily depends on correct interactions between interlocking, communication centres and rolling stock [7]. Therefore, the formal modelling language that would be used in the model-based development should be expressive enough to support a system-level modelling and verification. Furthermore, cyber-physical systems have both discrete and continuous behaviours that are best captured by hybrid models. A formal verification of hybrid systems have been a major challenge and an active research area. The challenges of formally verifying hybrid systems arise mainly due to real-valued state variables and systems with non-linear dynamics [3, 30]. The algorithmic verification of hybrid models with available model checking tools are limited even under severe restrictions. An alternative proof-based verification approach that is not limited by the state-space and combined with computer algebra systems can deal with non-linear dynamics [27]. Despite that an automated hybrid system deductive verification is still a major challenge and for an industrial application, an interactive proof effort should be dramatically reduced.

In this work, we present a formal development approach of cyber-physical railway signalling systems that makes it possible to capture and reason about safety of railway signalling systems at a system-level. The proposed approach also supports a verification of properties that are related to continuous rolling stock behaviour. Our introduced approach is based on the Event-B modelling language [2], which supports a refinement-based model development and proof-based model verification. The main contribution of this work is an Event-B model of a cyber-physical railway signalling system that is developed by utilising Event-B patterns for modelling hybrid [15] and communication [32] systems. The cyber-physical railway signalling system model is built upon our previous paper [31] in which we formally developed a speed controller that ensures a train stays within a permitted travelling distance. In this work, we refine the speed controller Event-B model by formally introducing other railway signalling sub-systems that are responsible for computing and communicating safe travelling distances to the rolling stock. The other sub-systems and signalling communication protocol are formally modelled by following the communication modelling patterns that were introduced in our previous work [32]. This article also evaluates our proposed formal development methodology of cyber-physical systems and demonstrates the key benefits of its refinement-driven modelling for a system complex development.

Related Work. In the work by Berger et al. [10], the authors use a real-time modelling approach to developing and verifying the ERTMS model. A multifaceted formalism is introduced in Reference [22] to reason about real-time systems with a case study on railway crossings. In the work by Cimatti et al. [14], the authors propose a different logic based on the temporal logic with regular expressions and use it for requirement validation of hybrid railway systems. Their verification approach, based on a state-exploration, is used to demonstrate the desired and safe behaviour of the model. Halchin et al. [19, 20] propose a certified translation from B formal language to HLL for developing railway software. In this work, the Isabelle/HOL theorem prover is used to check the correctness of the translation process, and the train localization in a CBTC system is used to illustrate the overall approach and the developed tool B2HLL. Even though, the model-checking approaches are desirable due to their push-button verification advantage, the approach rarely scales for realistic scenarios, particularly in the hybrid domain. In the other strand of works, an alternative to model checking—proof-based modelling—is used to verify European and Chinese Train Control Systems Level 3 [8, 28, 34]. These studies are more related to our work as the authors not only formally model rolling stock but also capture other sub-systems of the signalling system (only level crossings [22]) and validate systems through proofs. However, in contrast to these papers, our work considers a more complex and realistic physical model of a train and other signalling sub-systems are modelled at a lower abstraction level. Last, we note that our approach is based on stepwise refinement, which reduces proof effort and makes it possible to systematically refine the model to a specific signalling configuration (or a protocol).

Article Structure. In Section 2, we provide preliminary information about the Event-B specification language and Event-B modelling patterns of hybrid systems. Section 3 describes the proposed method for a formal development of cyber-physical railway signalling systems. Section 4 semi-formally specifies the communication-based railway signalling system, which will be formally developed with Event-B. In this section, we provide a description of each signalling subsystem, signalling communication protocol and rolling stock model specifications. In Section 5, we discuss the process of formally modelling and verifying communication-based railway signalling system Event-B model. The final section discusses modelling and verification challenges of this work, and outlines future work directions.

2 Background

In this section, we provide preliminary information about the Event-B modelling language, which is at the core of our proposed formal development method of cyber-physical railway signalling systems. This section also describes Event-B modelling patterns of hybrid systems that were used in a development of a hybrid train model.

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.

Listing. 1.

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.

Table 1.

Theorems	\(\mathsf {A(s, c) \Rightarrow T_{c}(s, c)}\)
Invariant Preservation	\(\mathsf {A(s, c) \wedge I(s, c, v) \wedge G(s, c, v, x) \wedge BAP(s, c, v, x, v^{\prime }) \Rightarrow I(s, c, v^{\prime }) }\)
Event Feasibility	\(\mathsf {A(s, c) \wedge I(s, c, v) \wedge G(s, c, v, x) \Rightarrow \exists v^{\prime } \cdot BAP(s, c, v, x, v^{\prime }) }\)
Variant Progress	\(\mathsf {A(s, c) \wedge I(s, c, v) \wedge G(s, c, v, x) \wedge BAP(s, c, v, x, v^{\prime }) \Rightarrow V(s, c, v^{\prime }) \lt V(s, c, v) }\)

Table 1. Event-B Proof Obligations

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.1 Continuous Variables.

Discrete variables in Event-B models are associated with instantaneous, point-wise assignment (the before-after predicate). Continuous variables, however, represent a continuous behaviour on a specific time interval, rather than on a single point. For this reason, continuous variables (denoted \(x_p\) in the following) are modelled using functions of time, and they are updated using the special continuous before-after predicate (CBAP) operator:

\begin{align} x_p :|_{{t}\rightarrow{t'}} \mathcal{P}(x_p,x_p^\prime)\; \& \; H\; \equiv\; [0,t[ \lhd x_p^\prime = [0,t[ \lhd x_p \end{align}

(PP)

\begin{align} &\wedge \mathcal{P}([0,t] \lhd x_p, [t,t'] \lhd x_p^\prime) \end{align}

(PR)

\begin{align} &\wedge \forall t^\ast \in [t,t'], x_p(t^\ast) \in H. \end{align}

(LI)

Informally, the continuous before-after predicate allows to describe a change in the behaviour of a continuous variable so that:

•

the variable’s “past,” i.e., its value on \([0,t[\), is preserved (1),

•

the variable’s behaviour on \([t,t^{\prime }]\) is given by a predicate (2),

•

the variable remains in an evolution domain \(H\) (4).

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.

listing. 2.

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.

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

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.

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 Methodology

This section describes a formal engineering methodology for the top-down development of cyber-physical railway signalling systems. In following sections, we describe two main steps of the methodology steps: system specification and a functional Event-B model development.

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.

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.

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.

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 Communication-based Railway Signalling System

In this section, we describe an abstract hybrid railway signalling Event-B model, which can be refined to capture a specific signalling configuration. First, this section revisits a generalised communication-based railway signalling model, including major railway signalling sub-systems and their communication relations. The following section then describes continuous model aspects of the rolling stock that will be used to form a generic Event-B theory describing continuous behaviour of railway rolling stock.

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.

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.

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:

—

Points or switches (\(\mathsf {P_1}\) in Figure 7) are mechanical railway devices that make it possible for rolling stock to change tracks.

—

Markers (\(\mathsf {M_{1..3}}\) in Figure 7) for marking a spatial beginning and ending of railway sections.

—

Track clear detection systems (track circuits) are railway devices that make it possible to detect presence and absence of the trains.

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:

(1)

A \(\mathsf {position \; report}\) message is sent periodically to the communication centre to update its position.

(2)

A \(\mathsf {extension \; request}\) message is sent to the communication centre when a train approaches the end of its movement authority (allowed travelling distance).

(3)

Train sends a \(\mathsf {release}\) message to the interlocking informing that it has left the junction area (crossed points).

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:

(1)

When a communication centre receives an \(\mathsf {extension \; request}\) message from a train with extension path requiring locking railway points. A communication centre sends a \(\mathsf {lock \; point}\) message to the interlocking (if that point status is free) to set a point to the right direction and lock it.

(2)

Once a point has been locked (or else it was not necessary) a communication centre sends a \(\mathsf {movement \; authority}\) \(\mathsf {extension}\) message to the train containing a permitted travelling distance, which is computed by considering other trains and point positions.

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:

(1)

An interlocking sends a \(\mathsf {lock \; acknowledgement}\) message when it receives a \(\mathsf {lock \; point}\) message, to inform the communication centre that a point has been adjusted and locked.

(2)

An interlocking sends an \(\mathsf {update \; free \; map}\) message to a communication centre when it received a \(\mathsf {release point}\) message from a train indicating that a train left the locked junction and now it can be set to free.

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]:

\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}

(1)

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).

Table 2.

\(\mathsf {SAF_1}\) \(\|\)	The train must remain within the issued movement authority at all times.
\(\mathsf {SAF_2}\) \(\|\)	The train’s speed must remain positive at all time.
\(\mathsf {SAF_3}\) \(\|\)	A point must be reserved only to a single train and locked when train is passing over.
\(\mathsf {PHY_1}\) \(\|\)	Traction force will remain within the minimum and maximum interval.

Table 2. Safety and Physical Requirements of the Train

5 Event-B Model of A Cyber-physical Railway Signalling System

This section describes the formal Event-B model development of a cyber-physical railway signalling. First, the section revisits our previous work [31] on a formal development of the hybrid Event-B model of the rolling stock model for which we used hybridised Event-B (described in Section 2.2). The following section describes the Event-B model of a cyber-physical railway signalling system that was developed by refining of the hybrid rolling stock Event-B model. The refined Event-B model formally models other signalling sub-systems (e.g., communication centres, interlocking boxes), infrastructure elements and a signalling communication protocol. In this refinement level, we prove that the issued movement authority distance to rolling stock is ensures safe rolling stock separation and prevents derailment.¹

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Table 3.

Refinement	PO Type	\(\|\)POs \(\|\)	Auto.	Inter.
Speed Controller		55	36	19
	Well-Definedness	12	12	0
	Guard Strengthening	11	11	0
	Invariant Preservation	18	10	8
	Feasibility	8	0	8
	Simulation	6	3	3
Communication and Signalling		85	71	14
	Well-Definedness	31	31	0
	Guard Strengthening	12	7	5
	Invariant Preservation	42	33	9
	Feasibility	0	0	0
	Simulation	0	0	0
Total		140	119	21

Table 3. Proof Statistics of the Event-B Model of Cyber-physical Railway Signalling

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].

6 Conclusions and Future Work

In this research, we attempted to address the challenges of applying formal methods for a model-based development of cyber-physical systems. In particular, the research described in this article focused on a formal development and the safety verification of heterogeneous cyber-physical railway signalling systems. The difficulty of a model-based cyber-physical system development stems from the complex nature of cyber-physical systems, which have deeply intertwined physical processes, computation, and networking system aspects that have to be captured by a system-level formal model.

The overall objective of this research was to address the challenge of applying formal methods to designing cyber-physical railway signalling systems by formulating a formal development methodology of cyber-physical railway signalling systems. It was essential that the methodology not only reduces the effort of applying formal methods but also facilitates a rigorous and systematic model-based signalling system development.

The main technical objective of our work was developing a generic hybrid signalling model that could be further refined to capture a specific signalling configuration. Or to enable modelling and verification of signalling communication aspects, for instance, protocols such as the one used for a radio-block handover. Our model can be divided into three main parts. The generic hybrid model is refined with train-/railway-specific attributed, including the new continuous theory, which defines the train plant by the Davis equation and a context for the other aspects such as stopping distance function. The dynamic part of the model refines the generic events to capture the train speed controller. As stated before, the main invariants we need to prove are that the train must remain within its movement authority and that the plant variables must remain within their limits. One of the future work directions is to address the verification problem by exploiting the previously developed Rodin verification extension based on the Why3 umbrella prover [24]. To achieve that, a new real theory together with definitions of operator used in this work could be re-defined in a new Why3 theory. Another direction for the hybrid model validation we would like to explore is co-simulation of discrete-continuous models via Functional Mock-up Interface [11].

Footnotes

The complete Event-B model can be found online at http://stankaitis.uk/2019/06/faoc/.

Note: new continuous variables, replacing \(\mathsf {f, tp, ta, tv}\) have been introduced to capture multiple trains in the system \(\mathsf {ntp, nta, ntv}\)

Supplementary Material

fac-2021-0013-File002 (fac-2021-0013-file002.zip)

Supplementary material

Download
243.08 KB

References

[1]

J.-R. Abrial. 1996. The B-book: Assigning Programs to Meanings. Cambridge University Press, New York, NY.

Abstract

1 Introduction

2 Background

2.1 Event-B

2.2 Modelling Hybrid Systems in Event-B

2.2.1 Continuous Variables.

2.2.2 Embedding Continuous Features in Event-B.

2.2.3 Generic Hybrid System Model.

3 Methodology

3.1 Methodology Overview

3.2 System Specifications and Requirements

3.3 Event-B Model

4 Communication-based Railway Signalling System

4.1 Informal Communication-based Railway Signalling Model

4.2 Continuous Rolling Stock Model

5 Event-B Model of A Cyber-physical Railway Signalling System

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

5.1.1 Train Domain Theory.

5.1.2 Train Model Static Informations.

5.1.3 Hybrid Rolling Model.

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

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

6 Conclusions and Future Work

Footnotes

Supplementary Material

References

Cited By

Index Terms

Recommendations

Specifying and Modeling Railway Cyber Physical Systems by the Extension of AADL

Aspect-Oriented Approach to Modeling Railway Cyber Physical Systems

Formal Distributed Protocol Development for Reservation of Railway Sections

Comments

Information

Published In

Publisher

Publication History

Permissions

Check for updates

Author Tags

Qualifiers

Funding Sources

Contributors

Other Metrics

Bibliometrics

Article Metrics

Other Metrics

Citations

Cited By

View options

PDF

eReader

Login options

Full Access

Figures

Other

Share

Share this Publication link

Share on social media

Affiliations