Defining and Model Checking Abstractions of Complex Railway

Defining and Model Checking Abstractions of Complex Railway

Defining and Model Checking Abstractions of Complex Railway Models using CSPjjB Faron Moller1, Hoang Nga Nguyen1, Markus Roggenbach1, Steve Schneider2, and Helen Treharne2 1 Swansea University, Wales, UK 2 University of Surrey, England, UK Abstract. The safety analysis of interlocking railway systems involves verifying collision and derailment freeness. In this paper we propose a structured way of refining track plans, in order to expand track segments so that they form collections of track segments. We show how the abstract model can be model checked to ensure the safety properties, which must also hold in the corresponding concrete track plan, so that we will never need to model check the concrete track plan directly. We also identify the minimal number of trains that needs to be considered as part of the model checking, and we demonstrate the practicality of the approach on various scenarios. 1 Introduction Formal verification of railway control software has been identified as one of the \Grand Challenges" of Computer Science [9]. As is typical with Formal Methods, this challenge comes in two parts: the first addresses the question of whether the mathematical models considered are legitimate representations of the physical systems of concern. The modelling of the systems, as well as of proof obligations, needs to be faithful. The second part is the question of how to utilize available technologies, for example model checking or theorem proving. Whichever verifi- cation process is adopted, it needs to be both effective and efficient. In [11, 10] we propose a new modelling approach for railway interlockings. We use CSPjjB [13], which combines event-based with state-based modelling. This reflects the double nature of railway systems, which involves events such as train movements and, in the interlocking, state based reasoning. In this sense, CSPjjB offers the means for the natural modelling approach we strive for: the formal models are close to the domain models. To the domain expert, this provides traceability and ease of understanding. This addresses the first of the above stated challenges: faithful modelling. In this paper, we address the question of how to effectively and efficiently ver- ify various safety properties within our CSPjjB models. To this end we develop a set of abstraction techniques for railway verification that allow the transfor- mation of complex CSPjjB models into less involved ones, prove that they are correct, and demonstrate that they allow one to verify a variety of railway sys- tems via model checking. The first set of abstractions reduces the number of 2 Moller, Nguyen, Roggenbach, Schneider, Treharne trains that need to be considered in order to prove safety for an unbounded number of trains. Their correctness proof involves slicing of event traces. The second set of abstractions simplifies the underlying track topology. Here, the correctness proof utilizes event abstraction specific to our application domain similar to the ones suggested by Winter in [15]. Outline We first introduce our modelling language CSPjjB. In Section 3 we summarise our generic railway modelling approach using CSPjjB, as described in [11, 10]. In Section 4, we present our first set of abstraction techniques based on event traces. Then in Section 5 we present our data abstraction techniques. The application of the abstraction results is presented via a set of example scenarios in Section 6. In Section 7 we put our contribution in the context of related approaches. 2 Background to CSPjjB The CSPjjB approach allows us to specify communicating systems using a com- bination of the B-Method [4] and the process algebra CSP (Communicating Sequential Processes) [7]. The overall specification of a combined communicat- ing system comprises two separate specifications: one given by a number of CSP process descriptions and the other by a collection of B machines. Our aim when using B and CSP is to factor out as much of the \data-rich" aspects of a sys- tem as possible into B machines. The B machines in our CSPjjB approach are classical B machines, which are components containing state and operations on that state. The CSPjjB theory [13] allows us to combine a number of CSP pro- cesses Ps in parallel with machines Ms to produce Ps k Ms which is the parallel combination of all the controllers and all the underlying machines. Such a par- allel composition is meaningful because a B machine is itself interpretable as a CSP process whose event-traces are the possible execution sequences of its op- erations. The invoking of an operation of a B machine outside its precondition within such a trace is defined as divergence [12]. Therefore, our notion of consis- tency is that a combined communicating system Ps k Ms is divergence-free and also deadlock-free. AB machine clause declares a machine and gives it a name. The variables of a B machine define its state. The invariant of a B machine gives the type of the variables, and more generally it also contains any other constraints on the allowable machine states. There is an initialisation which determines the initial state of the machine. The machine consists of a collection of operations that query and modify the state. Besides this kind of machine we also define static B machines that provide only sets, constants and properties that do not change during the execution of the system. The language we use to describe the CSP processes for B machines is as follows: P ::= e?x!y ! P(x) j P1 2 P2 j P1 u P2 j if b then P1 else P2 end j N (exp) j P1 k P2 j P1 AkB P2 j P1 jjj P2 Model Checking Abstractions of Complex Railway Models 3 The process e?x!y ! P(x) defines a channel communication where x repre- sents all data variables on a channel, and y represents values being passed along a channel. Channel e is referred to as a machine channel as there is a corre- sponding operation in the controlled B machine with the signature x − e(y). Therefore the input of the operation y corresponds to the output from the CSP, and the output x of the operation to the CSP input. Here we have simplified the communication to have one output and one input but in general there can be any number of inputs and outputs. The other CSP operators have the usual CSP semantics. For reasoning of CSPjjB models we require the following notation. { Since a B machine is interpretable as a CSP process, the various CSP refine- ments also apply to CSPjjB. In this paper we focus on trace refinement where P vT Q if traces(Q) ⊆ traces(P). This refinement preserves safety proper- ties, such as collision freedom or derailment freedom as we shall discuss in Section 3. { Furthermore, we apply CSP renaming f (P) and CSP hiding P n A to CSP processes, B machines and to CSPjjB models, which all semantically repre- sent sets of traces. Given a set of traces T , f (T ) represents the set of all traces tr 2 T where the events are replaced point-wise by the function f ; T n A to represent the set of all traces tr 2 T where the events from the set A are removed from tr. { A system run σ (of a CSPjjB model) of length n ≥ 0 is a finite sequence σ = hs0; e0; s1; e1;:::; en−1; sn i where the si ; i = 0 ::: n; are states of the B machine, and the ei ; 1 ≤ i ≤ n − 1; are events { either controlled by CSP and enabled in B when called, or B events. Here we assume that s0 is a state after initialisation. Given a system run σ, we can extract its trace of events: events(σ) = he0;:::; en−1i: 3 Modelling and safety verification of railway systems using CSPjjB Together with railway engineers we developed a common view on the information flow in railways. In physical terms a railway consists of, at least, four different components. These components are shown in Figure 1. The Controller selects and releases routes for trains. The Interlocking serves as a safety mechanism with regards to the Controller and, in addition, controls and monitors the Track equipment. The Track equipment consists of elements such as signals, points, and track circuits (logical names for tracks and points from the track plan as discussed above; in the railway domain, tracks and track circuits are often con- fused): signals can show the aspects green or red; points can be in normal position (leading trains straight ahead) or in reverse position (leading trains to a different 4 Moller, Nguyen, Roggenbach, Schneider, Treharne line) and track circuits detect if there is a train on a track. Finally, Trains have a driver who determines their behaviour. For the purposes of modelling, we make the assumption that track equipment reacts instantly and is free of defects. The information flow shown in Figure 1 is as follows: the controller sends a request message to the interlocking to which the interlocking responds; the interlocking sends signalling information to the trains; and the trains inform the interlocking about their movements. The interlocking serves as the system's clock: messages can be exchanged once per cycle. In this paper, we study various track plans, one of which is a station illustrated in Fig- ure 2(b). It depicts the scheme plan for the Controller station, which comprises a track plan, a con- Route request, Request response, trol table, and release tables. (We will discuss Route release Release response Figure 2(a) in Section 6). Interlocking The track plan provides the topological in- Signal and point settings Track occupation formation of the station which consists of 16 Track tracks (e.g., the track c TAA), three signals equipment (e.g., S1), and two points (e.g., P1).

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    15 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us