Techniques for modelling and verifying railway interlockingscsfm/Rail/Pubs/sttt14.pdf2 Railway...

28
uncorrected proof Int J Softw Tools Technol Transfer DOI 10.1007/s10009-014-0304-7 FMRCS Techniques for modelling and verifying railway interlockings Phillip James · Faron Moller · Hoang Nga Nguyen · Markus Roggenbach · Steve Schneider · Helen Treharne © Springer-Verlag Berlin Heidelberg 2014 Abstract We describe a novel framework for modelling 1 railway interlockings which has been developed in con- 2 junction with railway engineers. The modelling language 3 used is CSP||B. Beyond the modelling we present a vari- 4 ety of abstraction techniques which make the analysis of 5 medium to large scalemedium- to large-scalenetworks fea- 6 sible. The paper notably introduces a covering technique 7 that allows railway scheme plans to be decomposed into a 8 set of smaller scheme plans. The finitisation and topologi- 9 cal abstraction techniques are extended from previous work 10 and are given formal foundations. All three techniques are 11 applicable to other modelling frameworks besides CSP||B. 12 Being able to apply abstractions and simplifications on the 13 domain model before performing model checking is the key 14 strength of our approach. We demonstrate the use of the 15 framework on a real-life, ✭✭ medium sizemedium-sizescheme 16 plan. 17 1 Introduction 18 Formal verification of railway control software has been iden- 19 tified as one of the “grand challenges” of ✭✭ Computer Sciencecomputer 20 science[13] . This challenge comes in two parts. The first 21 addresses the question of whether theproposed mathematical 22 models faithfully represent the railway domain; verifications 23 must translate to guarantees in the real world. The second 24 addresses the question of how to employ available technolo- P. James · F. Moller · H. N. Nguyen · M. Roggenbach Swansea University, Wales, UK S. Schneider · H. Treharne (B ) University of Surrey, Surrey, UK e-mail: [email protected] gies effectively; analyses must be doable in practice and not 25 just in theory. 26 In a series of papers [2326] we have been developing 27 a new modelling approach for railway interlockings. This 28 work is carried out in conjunction with railway engineers 29 drawn from our industrial partner. By involving the rail- 30 way engineers from the start, we benefit twofold: they pro- 31 vide realistic case studies; and—more importantly—they 32 guide the modelling approach, ensuring that it is natural 33 to the working engineer and incorporates all relevant con- 34 cerns. Our approach thus addresses the first part of the grand 35 challenge. 36 We base our modelling approach on CSP||B[34] , which 37 combines event-based with state-based modelling. This 38 reflects the double nature of railway systems, which involves 39 events such as train movements and—in the ✭✭ interlocking—state basedinter 40 state-basedreasoning. In this sense, CSP||B offers the means 41 for the natural modelling approach we strive for. The for- 42 mal models are, by design, close to the domain models; 43 to the domain expert, this provides traceability and ease of 44 understanding. Our industrial partners can use our modelling 45 approach, and readily recognise it to be fully faithful to their 46 ✭✭ real worldreal-worldconcerns. 47 In addressing the second part of the grand challenge, we 48 face the wider challenge for formal methods of overcoming 49 state space explosion. Having rendered a real-world problem 50 into a modelling language, it remains a mystery in general 51 as to how to decompose a verification problem into tractable 52 pieces whose solutions can be composed together to provide 53 a solution to the initial problem. Our approach is to carry out 54 abstractions at the domain level, thus avoiding the lack of 55 general compositional techniques in modelling languages. 56 123 Journal: 10009 MS: 0304 TYPESET DISK LE CP Disp.:2014/3/4 Pages: 28 Layout: Large

Transcript of Techniques for modelling and verifying railway interlockingscsfm/Rail/Pubs/sttt14.pdf2 Railway...

  • unco

    rrec

    ted

    proo

    f

    Int J Softw Tools Technol TransferDOI 10.1007/s10009-014-0304-7

    FMRCS

    Techniques for modelling and verifying railway interlockings

    Phillip James · Faron Moller · Hoang Nga Nguyen ·Markus Roggenbach · Steve Schneider ·Helen Treharne

    © Springer-Verlag Berlin Heidelberg 2014

    Abstract We describe a novel framework for modelling1railway interlockings which has been developed in con-2junction with railway engineers. The modelling language3used is CSP||B. Beyond the modelling we present a vari-4ety of abstraction techniques which make the analysis of5

    ��������

    �medium to large scalemedium- to large-scalenetworks fea-6sible. The paper notably introduces a covering technique7that allows railway scheme plans to be decomposed into a8set of smaller scheme plans. The finitisation and topologi-9cal abstraction techniques are extended from previous work10and are given formal foundations. All three techniques are11applicable to other modelling frameworks besides CSP||B.12Being able to apply abstractions and simplifications on the13domain model before performing model checking is the key14strength of our approach. We demonstrate the use of the15framework on a real-life, ����

    ��medium sizemedium-sizescheme16plan.17

    1 Introduction18

    Formal verification of railway control software has been iden-19tified as one of the “grand challenges” of����

    ����Computer Sciencecomputer20science[13] . This challenge comes in two parts. The first21addresses the question of whether theproposed mathematical22models faithfully represent the railway domain; verifications23must translate to guarantees in the real world. The second24addresses the question of how to employ available technolo-

    P. James · F. Moller · H. N. Nguyen ·M. RoggenbachSwansea University, Wales, UK

    S. Schneider · H. Treharne (B)University of Surrey, Surrey, UKe-mail: [email protected]

    gies effectively; analyses must be doable in practice and not 25just in theory. 26

    In a series of papers [23–26] we have been developing 27a new modelling approach for railway interlockings. This 28work is carried out in conjunction with railway engineers 29drawn from our industrial partner. By involving the rail- 30way engineers from the start, we benefit twofold: they pro- 31vide realistic case studies; and—more importantly—they 32guide the modelling approach, ensuring that it is natural 33to the working engineer and incorporates all relevant con- 34cerns. Our approach thus addresses the first part of the grand 35challenge. 36

    We base our modelling approach on CSP||B [34] , which 37combines event-based with state-based modelling. This 38reflects the double nature of railway systems, which involves 39

    events such as train movements and—in the����

    �������

    interlocking—state basedinter40state-basedreasoning. In this sense, CSP||B offers the means 41for the natural modelling approach we strive for. The for- 42mal models are, by design, close to the domain models; 43to the domain expert, this provides traceability and ease of 44understanding. Our industrial partners can use our modelling 45approach, and readily recognise it to be fully faithful to their 46�����real worldreal-worldconcerns. 47

    In addressing the second part of the grand challenge, we 48face the wider challenge for formal methods of overcoming 49state space explosion. Having rendered a real-world problem 50into a modelling language, it remains a mystery in general 51as to how to decompose a verification problem into tractable 52pieces whose solutions can be composed together to provide 53a solution to the initial problem. Our approach is to carry out 54abstractions at the domain level, thus avoiding the lack of 55general compositional techniques in modelling languages. 56

    123

    Journal: 10009 MS: 0304 TYPESET DISK LE CP Disp.:2014/3/4 Pages: 28 Layout: Large

  • unco

    rrec

    ted

    proo

    f

    P. James et al.

    We have developed three abstraction techniques which57have proven successful in practice, both in isolation and taken58together:59

    1. Finitisation reduces the number of trains that need to60be considered ����in orderto prove safety for an unbounded61number of trains;62

    2. Covering decomposes the network into a set of sub-63networks in a compositional fashion: proving correctness64results for the sub-networks suffices to infer the correct-65ness of the whole network; and66

    3. Topological abstraction reduces the number of tracks67in the topology of the network, so as to minimise68the size and complexity of the network prior to its69analysis.70

    The second abstraction technique is a particular strength of71our approach. Winter [38] ����theorizedtheorisedon the possi-72bility of such compositional proof strategies for the railway73domain, but to our knowledge there has since been no prac-74tical solution. This is the notable contribution of this paper75which has not been presented in our previous work. The other76techniques in this paper build upon their presentation in [24] .77Firstly, we further reduce the number of trains that need to be78considered during analyses. Secondly, we improve upon the79topological abstraction technique as a consequence of having80more detailed CSP||B models in this paper.81

    The verification that we focus on in this paper is the safety82verification of three safety conditions: collision freedom ,83run-through freedom and no derailment . Our verification84extends beyond checking the correctness of the configura-85tion data of an interlocking. We address behavioural safety86since we concern ourselves with train movements in our87CSP||B models. Nonetheless, our modelling abstracts from88the����realtimereal-timebehaviour of the interlocking and of the89network as a train passes through it.90

    The paper is organised as follows. In ����Section Sect. 2 ,91we introduce the traditional engineer’s view of railway con-92cepts, including a presentation of a complex real-life exam-93ple which we shall use as a case study. We also outline three94safety conditions that we will concentrate on verifying. In95����Section Sect. 3 , we outline our approach to verification in96general terms independent of any modelling language, as97well as then outline a domain-specific modelling language98on which we will base our modelling. In����Section Sect. 5 , we99present our specific modelling language CSP||B, and apply100this language to the railway domain in ����Section Sect. 6 .101

    Having outlined the modelling framework, the next102three sections of the paper outline our abstraction tech-103niques: ����Section Sect. 7 presents finitisation, ����Section Sect. 8104presents covering and ����Section Sect. 9 presents topological105abstraction. In ����Section Sect. 10 , we present experimental106results demonstrating the effectiveness of the abstractions.107

    In ����Section Sect. 11 , we discuss related approaches to the 108railway verification problem. Finally, in ����Section Sect. 12 , 109we���recaprecapitulateour achievements and outline directions 110of future research. 111

    2 Railway systems 112

    Together with railway engineers, we have developed a com- 113mon view of the information flow in railways. In physical 114terms, a railway consists of ( at least ) the four different com- 115ponents shown in ����Figure Fig. 1 . 116

    – The controller selects and releases routes for trains. 117– The interlocking serves as a safety mechanism with 118

    ��������

    ��regards to the Controllerregard to the controllerand, in 119addition, controls and monitors the���Tracktrackequipment. 120

    – The track equipment consists of elements such as sig- 121nals,���points,pointsand track circuits. Signals can show the 122aspects green or red ; points can be in normal position ( 123leading trains straight ahead ) or in reverse position ( lead- 124ing trains to a different line ) ; and track circuits detect if 125there is a train on a track. 126

    – Finally, Trains have a driver who determines their behav- 127iour. 128

    For the purposes of modelling, we have made the simplifica- 129tion to only consider two aspect ���

    ��signalling,signalling;we do 130not consider the additional aspects of caution or speed lim- 131its. We also make the assumption that track equipment reacts 132instantly and is free of defects. We furthermore assume that 133trains are shorter than the track segments in the network. In 134[15] , we address the question of how to extend our modelling 135framework ����

    �����in order to deal withtodeal with lengths of track 136segments and trains. 137

    The information flow shown in����Figure Fig. 1 is as follows: 138the controller sends a request message to the interlocking 139to which the interlocking responds; the interlocking sends 140signalling information to the track equipment and receives 141

    Fig. 1 Information flow

    123

    Journal: 10009 MS: 0304 TYPESET DISK LE CP Disp.:2014/3/4 Pages: 28 Layout: Large

  • unco

    rrec

    ted

    proo

    f

    Techniques for modelling and verifying railway interlockings

    Fig. 2 Track plan based on Langley Station

    Fig. 3 Control table and release tables for Langley Station track plan

    information from track sensors on whether a track element is142occupied. The interlocking and the trains interact indirectly143via the track equipment only. The interlocking serves as the144system’s clock: in a cycle the status of all the track sensors145are read then the interlocking reacts to all of them with one146change of state. Routes cannot be in conflict since requests to147select and release routes are sequentialised. In our modelling148we will abstract away from modelling the track equipment149explicitly.150

    In this paper, we analyse a track layout based on Langley151Station, a nontrivial station just to the west of London which152is used by over 700,000 people each year [31] , and con-153sidered to be a ����

    ��medium sizemedium-sizestation in the UK.154Figures 2 and 3 depict the scheme plan for the station com-155

    prising��ofa track plan, a control���table,tableand release tables. 156The track plan is publicly available from [29] ; however, 157as signalling rules are confidential, our control and release 158tables are of our own design, though they have been attested 159by our industrial partners as being realistic. 160

    We explain our modelling approach here with reference to 161our Langley Station example. In general, we adhere closely 162to the established principles laid out in [30] . Following the 163approach of Bjø rner [4] , we view a track plan as being built 164from tracks, connectors, signals and points. Each track is 165associated with two connectors ( or three if the track contains 166a point ) . Two tracks are attached together if they share 167a connector. Each track is also associated with a direction 168consisting of a ( directed ) pair of their associated connectors ( 169

    123

    Journal: 10009 MS: 0304 TYPESET DISK LE CP Disp.:2014/3/4 Pages: 28 Layout: Large

  • unco

    rrec

    ted

    proo

    f

    P. James et al.

    or two pairs if the track contains a point ) . Thus a pair (c1, c2)170in the direction of a track indicates that trains can travel on171that track from c1 to c2, c1 being the connector linking the172track to the previous track and c2 being the connector linking173the track to the subsequent track. For example, the Langley174���stationStationtrack plan of����Figure Fig. 2 consists of 49 tracks175(��e.g.,e.g.the tracks EN1 and DA ) , 61 connectors (��e.g.,e.g.the176connector c2 attaching the track EN1 and DA ) , 16 signals177( ��e.g.,e.g.S10 and S12 ) , and 16 points ( ��e.g.,e.g.P101 and178P102 ) . Note that the tracks include entry and exit tracks on179which trains can “appear” and “disappear” ( ��e.g.,e.g.EN1,180EX1 ) . These two kinds of tracks are specially treated during181verification.182

    An interlocking system gathers train�����locations,locationsand183

    sends out commands to control signal aspects and point posi-184tions. The control table determines how the station interlock-185ing system sets signals and points. For each route of a signal,186there is one row describing the condition under which the187signal can show proceed. There are two rows for signal S12:188one for route R12A and one for route R12B where, for exam-189ple, signal S12 can only show proceed when points P101190and P202 are in the normal ( straight ) position and tracks191DC, DD, DE, DF are all clear.192

    The normal direction of a point in a track plan is indicated193by an uninterrupted line ( from connector c5 to connector c6 ) ,194the reverse direction with an interrupted line ( from connector195c5 to connector c12 ) .196

    Note that we do not assume that trains are equipped with197an Automatic Train Protection system which prevents trains198from moving over a red light; thus overlaps are needed,199��e.g.,e.g.the overlap for ���RouterouteR12A is DF, and hence200DF is included in the control table. Trains are assumed to201overrun a red signal by maximally one track. In case that202such an overrun has happened, trains are assumed to halt.203

    The interlocking also allocates locks on points to particu-204lar route requests to keep them locked in���

    �position,positionand205releases such locks when trains have passed. For exam-206ple, the setting of ���RouterouteR12A obtains a lock on point207���P101,P101and sets it to normal. The lock is released after208the train has passed the point. This mechanism allows for the209implementation of flank protection. The release tables store210the relevant track, which is the track after the point.211

    In this setting, we consider three safety properties:212

    1. Collision freedom excludes two trains occupying the213same track;214

    2. Run-through freedom says that whenever a train enters215a point, the point is set to cater for this; ��e.g.,e.g.when a216train travels from track DF to track DG, point P102 is set217so that it connects DF and DG ( and not UJ and DG ) ;218

    3. No derailment says that whenever a train occupies a point,219the point does not move.220

    Fig. 4 Verification����workflow.workflow

    The correct design for the control table and release tables is 221

    ������safety-critical:safety critical:mistakes can lead to a violation 222

    of any of the three safety properties. 223

    3 Verification workflow 224

    In����Figure Fig. 4 we depict the verification workflow employed 225by our approach. Starting from a scheme plan of a railway 226

    system represented in a����

    ��������

    Domain Specific Languagedomain 227specific language ( DSL ) [8,21] —bottom left—we trans- 228form this scheme plan into a concrete specification SPC— 229bottom right. This may be in any of a number of spec- 230ification languages ( ��e.g.,e.g.CASL, CSP, Timed CSP, 231����

    ��CSP||B, etc.CSP||B) depending on the approach. However, 232regardless of the formalism, the specification will inevitably 233be too complex for analysis. To remedy this, some form 234of abstraction is applied to the scheme plan to produce 235an abstract scheme ����

    ������

    plan – top left – whichplan—top left— 236whichis then transformed into an abstract specification 237SPA—top right. With appropriate abstraction correctness 238results, verification proofs carried out on the abstract spec- 239ification SPA imply the relevant correctness of the concrete 240specification SPC . For example, we have used this approach 241with topological abstractions in the context of CASL [14] 242and CSP||B [24] �;,with a covering abstraction in the context 243of CSP [22] �;,and with a finitisation abstraction in the context 244of Timed CSP [12] . 245

    4 A railway DSL 246

    Here, we present a general ( mathematical ) model of rail- 247way networks inspired by the work of Bjø rner [4] . We 248implemented this model in our tool OnTrack [17] which also 249includes an automated transformation of this model into a 250CSP||B specification. 251

    A railway network is provided by a scheme plan SP = 252(Top, CT, RTs) which ����

    ���is comprised ofcomprisesa track plan 253Top defining the topology of the railway ���

    �network;network,a 254control table CT and a set RTs of release tables. Note that 255our model is a loose specification of a railway scheme plan. 256

    123

    Journal: 10009 MS: 0304 TYPESET DISK LE CP Disp.:2014/3/4 Pages: 28 Layout: Large

  • unco

    rrec

    ted

    proo

    f

    Techniques for modelling and verifying railway interlockings

    Fig. 5 A point example

    For our purposes, this under-specification has proven to be257sufficient.258

    4.1 Topology259

    Let Track and Point denote two disjoint, finite sets of tracks260and points, respectively. Tracks and points are collectively261referred to as units, and we let Unit = Track � Point. There262is a set Connector whose elements serve as glue between263nodes. A track t, having two endpoints, has two distinct264�����connectorsconnectors,whereas a point p, having three end-265points, has three distinct connectors; we write connectors(u)266to denote the set of all connectors of a unit u. A pair267(c1, c2) ∈ Connector×Connector indicates that a train can268travel on a unit u from c1 to c2, where c1, c2 ∈ connectors(u).269In our setting, a track t can be passed in one direction270only; in contrast, a point p is associated with two direc-271tions where opposing directions and movement between two272specific branches are excluded, e.g. in ����Figure Fig. 2 move-273ment between connector c6 and c12 is not permitted. The274two positions that a point can have are called normal and275reverse where directions(p) = normal(p) � reverse(p). The276direction of a unit can be read as the “intended use” of the277unit, which the signal engineer provides when designing278the routes, the control ���table,tableand release tables. Given279a direction d = (c1, c2) ∈ directions(t) of a track or point t,280we denote from(d) = c1, to(d) = c2.281

    A path P = 〈(u1, d1), . . . , (uk, dk)〉, k ≥ 1, in a railway282���

    �topologytopology,is a non-empty sequence of units and their283directions without direct repetitions: to(di) = from(di+1)284and ui �= ui+1 for all 1 ≤ i < k. As usual, hd(P) = u1 and285last(P) = uk , and u ∈ P if u = ui for some 1 ≤ i ≤ k. When286the connectors are clear, we also write 〈u1, . . . , uk〉 for P.287

    Note that the composition of two paths is not necessarily288a path as direct repetitions are excluded. A typical example289is shown in ����Figure Fig. 5 .290

    Here, 〈A, C〉 is a path and 〈C, B〉 is a ������path, howeverpath;291however,〈A, C, C, B〉 is not a path. Note however that any292non-empty subsequence of a path is a path.293

    For convenience, we define two functions successor :294Unit → ℘(Unit) and predecessor : Unit → ℘(Unit) as295follows:296

    • successor(u) = {x ∈ Unit | ∃ c1, c2, c3 ∈ Connector :297〈(u, (c1, c2)), (x, (c2, c3))〉 is a path}, and298

    • predecessor(u) = {x ∈ Unit | ∃ c1, c2, c3 ∈ Connector : 299〈(x, (c1, c2)), (u, (c2, c3))〉 is a path}. 300

    Units without predecessors are called����entries,entries andunits 301without successors are called exits. In the context of this 302paper, we consider only track plans where entries and exits 303are tracks, and denote the set of entry and exit tracks as 304

    – Entry = {t ∈ Track | predecessor(t) = ∅} and 305– Exit = {t ∈ Track | successor(t) = ∅}. 306

    We assume a set Signal of signals, along with a labelling 307function signalAt : Signal → Track indicating tracks at 308which signals are placed. Each track may be labelled by at 309most one signal: for each t ∈ Track, signalAt(s) = t for at 310most one s ∈ Signal. Signals are placed at the end of a track 311����in orderto protect the successor track. We require that there 312is a signal at every entry track. Without such an entry sig- 313nal, trains could unrestrictedly enter the scheme plan. This 314would cause collision on the successor of an entry track. 315Note that the typing of the function signalAt ensures that sig- 316nals are never placed at a����

    ��point – whichpoint—whichfollows 317standard practice in railway engineering. 318

    As we deal with open railway topologies, we need to 319give two different definitions of what a route is: the first 320definition caters for the case in which the route is com- 321pletely within the railway topology, while the second def- 322inition caters for the case in which a route ends at the border 323of the ����

    ������

    topology – see Figure topology—see Fig. 6 . A path 324r = 〈u1, . . . , uk〉 is a topological route if one of the following 325holds: 326

    – there is a unit u0 such that 327

    〈u0, u1, . . . , uk〉 328

    is a path in which u0 and uk−1 are labelled with 329���signalssignals,but there are no signals on u1, . . . , uk−2. 330In this case, uk is called the overlap of r; or 331

    – there are units u0 and uk+1 such that 332

    〈u0, u1, . . . , uk, uk+1〉 333

    is a path, u0 is labelled with a signal, there are no signals 334on u1, . . . , uk and uk+1 is an exit track. 335

    In both cases, we define topoUnits(r) = {u1, . . . , uk} and 336topoSignal(r) = s where signalAt(s) = u0. Finally, we let 337TopoRoute denote the set of all topological routes in the rail- 338way topology, so that topoUnits : TopoRoute → ℘(Unit) 339and topoSignal : TopoRoute→ Signal. 340

    123

    Journal: 10009 MS: 0304 TYPESET DISK LE CP Disp.:2014/3/4 Pages: 28 Layout: Large

  • unco

    rrec

    ted

    proo

    f

    P. James et al.

    Fig. 6 An illustration of the route definition

    4.2 Control table341

    The control table determines the logic for controlling sig-342nals and points in the railway network. It specifies conditions343when routes can be set which effectively leads to the control344of signals’ aspects and of points’ positions.345

    Let Route be a set of route names and topoRoute :346Route → TopoRoute a function associating topological347routes to route names. The function topoRoute is not neces-348sarily surjective as there can be topological routes which a349signaller cannot control. ����

    ���E.g., in Figure For e.g. in Fig. 3 ,350the control table does not include a route corresponding to351the topological route in ����Figure Fig. 2 from the signal S12352to the exit track EX1—from track DB down to track DRG353( points P101, P202, P203 and P303 all in reverse posi-354tion ) and then again up to track DH ( points P304, P204,355P205 and P102 all in reverse position ) . We allow for sev-356eral entries in the control table that are associated with one357topological route. The function signal : Route → Signal358gives the entry signal of the corresponding topological route,359

    ��i.e.,i.e.signal(r) = topoSignal(topoRoute(r)). The function360units : Route→ ℘(Unit) gives the set of units of the corre-361sponding topological route, ��i.e.,i.e.362

    units(r) = topoUnits(topoRoute(r)).363

    The control table specifies, for each route r ∈ Route: a364set clear(r) of tracks and points to be clear; a set normal(r)365of points to be in the normal position; and a set reverse(r)366of points to be in the reverse position. Informally, when all367units in clear(r) are unoccupied, all points in normal(r) are368in the normal position, and all points in reverse(r) are in the369reverse position, route r can be set which effectively changes370the aspect of signal(r) to “proceed”.371

    Note that there are in general no restrictions on how a372control table looks, ��i.e.,i.e.signalling engineers are allowed373to write down anything. We define the clear, normal and374reverse tables to be the columns of a control table.375

    4.3 Release tables 376

    Each point is associated with a release table which specifies 377when to remove a lock from this point. Release tables are 378mappings release : Point → ℘(Route × Unit). Given an 379entry (r, t) ∈ release(p), informally, when a train reaches 380the unit t, the lock r is released from the point p, ��i.e.,i.e.the 381point can be moved again, provided there is no other lock on 382it. 383

    4.4 Well-formedness conditions 384

    We postulate some conditions on a scheme plan formulated 385in our DSL. These conditions ensure a minimal consistency 386between the signalling of routes in the control and release 387tables on the one hand, and their topological extent as defined 388by the railway topology on the other hand. These conditions 389allow for simple static checks. 390

    Definition 1 A scheme plan is well formed if the following 391conditions hold: 392

    1. ( Release-Table condition ) Locks of a route can only be 393released by a train movement on that route: 394

    ∀ r ∈ Route, p ∈ Point, t ∈ Track : 395(r, t) ∈ release(p)⇒ t ∈ units(r). 396

    2. ( Clear-Table condition ) The clear table of a route con- 397tains at least the tracks of this route: 398

    ∀ r ∈ Route : {t | t ∈ units(r)} ⊆ clear(r). 399

    3. ( Normal/Reverse-Table condition ) Every point on a route 400is in either the normal table or the reverse table of that 401route: 402

    ∀ r ∈ Route : {p ∈ Point | p ∈ units(r)} 403⊆ normal(r) ∪ reverse(r). 404

    4. ( Route condition ) Topologically different routes that 405share some points are distinguishable by at least one point 406position of these shared points: 407

    ∀ r1, r2 ∈ Route :r1 �= r2 ∧ sharedPoints(r1, r2) �= ∅ ⇒∃ p ∈ sharedPoints(r1, r2) :p ∈ reverse(r1) ∩ normal(r2) ∨p ∈ reverse(r2) ∩ normal(r1)

    408

    where sharedPoints(r1, r2) = units(r1) ∩ units(r2) ∩ 409Point. 410

    123

    Journal: 10009 MS: 0304 TYPESET DISK LE CP Disp.:2014/3/4 Pages: 28 Layout: Large

  • unco

    rrec

    ted

    proo

    f

    Techniques for modelling and verifying railway interlockings

    All scheme plans that we looked at together with our411industrial partners were fulfilling these conditions.412

    5 Background to CSP||B413

    The CSP||B approach allows us to specify communicating414systems using a combination of the B-Method [1] and the415process algebra communicating sequential processes (CSP416

    ��������

    ��������

    ( Communicating Sequential Processes) [11] . The speci-417fication of a combined communicating system comprises418two separate specifications: one given by a number of CSP419process descriptions and the other by a collection of B420machines. Our aim when using B and CSP is to factor out421as much of the “data-rich” aspects of a system as possible422into B machines. The B machines in our CSP||B approach423are classical B machines, which are components containing424state and operations on that state. The CSP||B theory [34]425allows us to combine a number of CSP processes Ps in par-426allel with machines Ms to produce Ps ‖ Ms which is the par-427allel combination of all the controllers and all the underlying428machines. Such a parallel composition is meaningful because429a B machine is itself interpretable as a CSP process whose430����

    �event-tracesevent tracesare the possible execution sequences431of its operations. The invoking of an operation of a B machine432outside its precondition within such a trace is defined as diver-433gence [27] . Therefore, our notion of consistency is that a434combined communicating system Ps ‖ Ms is divergence free435. We do not consider ����

    ����deadlock-freedomdeadlock freedomin436this paper as it is concerned with liveness, and the focus of437the paper is on safety.438

    A B machine clause declares a machine and gives it a439name. The variables of a B machine define its state. The440invariant of a B machine gives the type of the variables, and441more generally it also contains any other constraints on the442allowable machine states. There is an initialisation which443determines the initial state of the machine. The machine con-444sists of a collection of operations that query and modify the445state. Operations take one of two forms:446

    • Preconditioned operation —pre P then S end : if this is447called when P holds then it will execute S, otherwise it448will diverge.449• Guarded event —select P then S end : this will execute450

    S when P holds, and will block when P is false.451

    Besides this kind of����machinemachine,we also define static452B machines that provide only sets, constants and properties453that do not change during the execution of the system.454

    The language we use to describe the CSP processes for B 455machines is as follows: 456

    P ::= c?x!y→ P(x) P1 � P2 P1 � P2if b then P1 else P2 end N(exp)P1 ‖ P2 P1 A‖B P2 P1 ||| P2

    457

    The process c?x!y → P(x) defines a channel communi- 458cation where x represents all data variables on a chan- 459nel, and y represents values being passed along a chan- 460nel. Some of these channels match with operations in a 461corresponding B machine with the signature x ←− c(y). 462Therefore the input y of the B operation c corresponds to 463the output from the CSP, and the output x of the B oper- 464ation to the CSP input. ���HereHere,we have simplified the 465communication to have one output and one ���inputinput,but 466in general there can be any number of inputs and out- 467puts. The external choice, P1 � P2, is initially prepared 468to behave either as P1 or as P2, with the choice being 469made on occurrence of the first event in the environment. 470The internal choice, P1 � P2, is ����similar,similar;however, 471the choice is made by the process rather than the environ- 472ment. Another form of choice is controlled by the value of 473a ����booleanBooleanexpression in an if expression. The syn- 474chronous parallel operator, P1 ‖ P2, executes P1 and P2 475concurrently, requiring them to ����

    ��synchronizesynchroniseon 476all events. The ����

    ��alphabetizedalphabetisedparallel operator, 477P1A‖BP2, requires synchronisation only in A ∩ B, allowing 478independent performance of events outside this set. The inter- 479leaving operator, P1 ||| P2, allows concurrent processes to 480execute completely independently. Finally, N(exp) is a call to 481a process where N is the process name and exp is an expres- 482sion. 483

    For reasoning of CSP||B ����modelsmodels,we require the 484following notation. A system run σ ( of a CSP||B model ) of 485length n ≥ 0 is a finite sequence 486σ = 〈s0, e1, s1, e2, . . . , en, sn〉 487where the si, i = 0 . . . n, are states of the B����machine,machineand488the ei, 1 ≤ i ≤ n, are events. ���HereHere,we assume that s0 489is a state after initialisation. Given a system run σ , we can 490extract its trace of events: 491

    events(σ ) = 〈e1, . . . , en〉. 492

    6 Modelling railway systems in CSP||B 493

    As outlined in [25] , CSP||B caters for the double nature of 494railways by addressing the state and data aspects separately: 495the interlocking as the “data-rich” component is modelled 496as a single, dynamic B machine, the Interlocking machine. 497It represents the �����centralizedcentralisedcontrol logic of a rail 498

    123

    Journal: 10009 MS: 0304 TYPESET DISK LE CP Disp.:2014/3/4 Pages: 28 Layout: Large

  • unco

    rrec

    ted

    proo

    f

    P. James et al.

    Fig. 7 Relationship between DSL terminology and CSP||B terminol-ogy

    node, which reacts to its environment without taking any ini-499tiative. The Interlocking machine offers to perform events in500the form of operations to the two active system components:501the controller and the trains, both of which are modelled as502CSP processes. The full CSP||B model is given in Appendix503A.504

    To tailor the CSP||B model to the ProB [19] tool which505we are using for analysis, we put the DSL model of506����Section Sect. 3 into a particular form. For example, in the507DSL the release table is given by release : Point →508℘(Route × Unit). However, when considering the move-509ment of trains it is more efficient to capture the information510indexed by the track, so the locks released on any partic-511ular move are given directly by the position the train has512moved to. In the B description we use the name releaseTable513for explicitness. The relationship between the DSL terminol-514ogy and the CSP||B terminology is given in ����Figure Fig. 7 .515The main difference is the use of Point as the name of the516point ( ��e.g.,e.g.P101 ) rather than the unit associated with it517( ��e.g.,e.g.DD ) , and the use of Track to cover both kinds of518units. However, this is mainly a matter of convenience and it519is straightforward to translate between the two approaches.520For the purposes of this paper we consider tracks to be uni-521directional.522

    The ���������Trains and Controllertrains and controllerprocesses523

    run independently of each other, on the CSP level expressed524with an interleaving����

    �����

    operator – see Figure operator—see Fig. 8525( lines 20 and 21 ) . It is a decision of the controller which526routes are requested to be set or to be released ( lines��2-42–4)527. Similarly, it is a decision of the train to move through a528red light by maximally one track and subsequently stop or to529wait for a signal change ( lines ���13-1513–15) . This logic is530sometimes referred to as the driving rules of a train.531

    The Interlocking machine captures information about the532location of trains on tracks using the function pos : Train→533AllTrack where pos(t) gives the location of the train t. The534position of a train consists of exactly one track. It is here we535assume that the train’s length is smaller than that of a track.536

    The set AllTrack represents all the tracks and the special537nullTrack which denotes a ����non validnonvalidtrack used for538

    Fig. 8 CSP control processes for ��������Controller and Trainscontroller and

    trains

    Fig. 9 Release operation from Interlocking

    modelling �����runthrough.run-through.The machine also cap- 539

    tures the current information about successor tracks through 540a dynamic function nextd : AllTrack → AllTrack which is 541dependent upon the position of the points. Furthermore, the 542machine captures information about signal settings using the 543function signalStatus, last moved points using the set moved- 544Pointsand point settings using the sets normalPointsand 545reversePoints. Finally, the current locks on points are mod- 546elled using currentLocks. The initial state of the model sets all 547tracks to being empty, all signals to red, all points to the nor- 548mal position and no locks are made on points. This dynamic 549state is then updated and queried, respectively, in the six 550operations of the Interlocking machine. 551

    Figure 9 shows the full B code of a typical operation of the 552Interlocking machine. It describes how a release request from 553the controller is processed. The release is granted provided 554

    123

    Journal: 10009 MS: 0304 TYPESET DISK LE CP Disp.:2014/3/4 Pages: 28 Layout: Large

  • unco

    rrec

    ted

    proo

    f

    Techniques for modelling and verifying railway interlockings

    Fig. 10 Architecture

    a number of conditions�isarefulfilled ( the signal of the route555is green, line 6, there are points locked for the route, line 8,556etc. ) . In such a case, a number of state changes are made557( the signal of the route is set to red, line 16, etc. ) and the558controller is notified with a “yes” ( line 20 ) . Otherwise, the559state does not change and the controller is notified with a560“no”.���Note,Notethat the a signal of a route may also be set to561red when a train occupies the first track section of the route,562����in orderto avoid several trains to enter the route.563

    Figure 10 shows the overall architecture of our modelling.564The CSP controller and the Interlocking machine are inde-565pendent of any particular scheme plan. They are supported566by a Topology , a ControlTable , a ReleaseTable �,and a Con-567text machine. These four machines encode the scheme plan568and are the parameters in our generic approach. Seen as B569machines, these four supporting machines are stateless. A570typical example from the ControlTable machine which splits571up the modelling of a control table into two relations and one572function is given as follows:573

    normalTable ∈ Route↔ Point ∧reverseTable ∈ Route↔ Point ∧clearTable ∈ Route→ P(Track)

    574

    A predicate is used to define the relationship between the575Interlocking machine and the CTRL process relates the train576parameter t and the train position pos of the TRAIN CTRL577process to the pos function within the Interlocking machine.578This control loop invariant predicate must hold at each recur-579sive call, and hence the system is����

    ���divergence-free.divergence580free.581

    The Interlocking machine uses guarded events to model582the safety properties. The guards are enabled in unsafe states583which will violate our safety properties. Use of these guarded584events does not impact on the divergence freedom require-585ment of a CSP||B model since they have no affect on the state586and do not themselves diverge.587

    In ����Section Sect. 2 we introduced the collision freedom588property. In our B ����machinemachine,we encode an operation589which captures the notion of a collision, as follows:590

    5911592

    2 5933 5944 5955 5966 5977 5988 5999 600

    10 60111 60212 603604

    ���HereHere,collision is detected when two different trains t1 605and t2 occupy the same track segment ( different from the Exit 606and Entry tracks ) . This is recognised in the pos function 607which maps trains to the track segments they occupy; the 608collision condition will be enabled when the two trains are 609at the same position. 610

    Collision freedom can then be established by model 611checking the validity of the following CTL formula: 612

    AG(not(e(collision))) 613

    This formula is false if collision is enabled. In the CTL variant 614of ProB AG stands for “on all paths it is globally true that”, 615and e(a) stands for “event a is enabled”. 616

    7 Finitisation 617

    In this section, we develop a theory of how to reduce the prob- 618lem of verifying of scheme plans for safety (��i.e.,i.e.freedom 619from collision,

    ��������

    ����derailment, and runthroughderailment and 620

    run-through) for any number of trains to that of a two-train 621scenario. We introduced this idea first for run-through free- 622dom in [24] . Here, we give full proofs on a slightly more 623involved CSP||B model and generalise it to collision freedom 624and derailment freedom. 625

    Finitisation requires scheme plans to fulfil a number of 626well-formedness conditions as outlined in ����Section Sect. 4.4 627�����.In Section . In Sect. 7.1 we establish a reduction theorem 628( Theorem 3 ) for such well-formed scheme plans w.r.t. the 629number of trains involved in a system run. If we are only inter- 630ested in the movements of a finite set of trains in a given sys- 631tem����run – sayrun—sayin the movements of two trains which 632collide in this system �����run – thenrun—thenwe can define a 633new system run with “exactly the same movements” for just 634this selected set of trains. 635

    Finitisation works for well-formed scheme plans as it is 636possible to simulate the influence that one train can have on 637other trains by suitable route request and release commands. 638The validity of this finitisation argument for safety is demon- 639strated in ����Section Sect. 7.2 . 640

    Given a scheme plan SP, and an unlimited collection Train 641of trains, we write CSP ||B(SP, Train) for the instantiation 642of our generic CSP||B model with SP and Train. Note that 643CSP ||B(SP, Train) in general is an infinite state system due 644

    123

    Journal: 10009 MS: 0304 TYPESET DISK LE CP Disp.:2014/3/4 Pages: 28 Layout: Large

  • unco

    rrec

    ted

    proo

    f

    P. James et al.

    to the inclusion of train identifiers into events and states. We645call our theory “finitisation”, as it reduces the safety problem646over an infinite state system to a safety problem over a finite647state system, namely to CSP || B(SP, Train) where the set648Train of trains contains two elements only.649

    7.1 A reduction theory650

    We start the development of our reduction theory with a sim-651ple observation on our CSP||B models. If a signal shows652green in a state of a system run, then there exists a uniquely653determined route for which, in the past, a route request must654have been granted by the interlocking.655

    Theorem 1 Let σ be a system run of CSP || B(SP, Train)656for a scheme plan SP and a set Train of trains. Prior to any657state in which a signal sig ∈ Signal shows green, there is a658uniquely determined event in σ of the form request.r.yes for659some r ∈ Route which caused that signal to become green.660We sometimes speak of the uniquely determined route r that661has been granted.662

    Proof By definition of the B machine Interlocking, a signal663is set to green only by the event request (��i.e.,i.e.when a route664is successfully requested ) . Conversely, a signal is set to red665only by the events move and release ( ��i.e.,i.e.when a train666passes a signal and when a route is successfully released ) .667Analysing a system run where sig is green in the last state668yields that the route is uniquely determined. ��669

    In the following we show that for every system run σ670involving a set A � B of trains there exists a system run σ ′671which involves trains only from A, and where the trains from672A move identically to σ . In particular: if trains from A collide673in σ , then they collide in σ ′; if a train in A derails in σ , then674it derails in σ ′; and if a train has a �����runthroughrun-throughin675σ, then the same happens in σ ′. We obtain σ ′ constructively676from σ by defining a replacement function on events. To this677end, we first identify those events which are related to B.678

    Definition 2 Given a set B of train identifiers, we define the679set E(B) of events of B as680

    E(B) = {enter.b | b ∈ B} ∪{exit.b | b ∈ B} ∪{nextSignal.b | b ∈ B} ∪{move.b.cp.np | b ∈ B ∧ cp, np ∈ AllTrack}

    681

    The next step is to define the replacement function which682is dependent on the current state.683

    replaceB(S, e) =684685 • e, if e /∈ E(B);686• release.r.yes, if e = move.b.cp.np for some b ∈ B and687∃ s ∈ Signal such that688

    – homeSig(s) = cp, 689– signalStatusS(s) = green, 690– ∃!r ∈ Route : signal(r) = s, and 691– currentLocksS(r) = lockTable(r); 692

    • idle, otherwise. 693

    Note that, in the above definition, when we replace a for- 694ward move event move.b.cp.np in front of a green signal by a 695route release event release.r.yes, Theorem 1 guarantees the 696existence of such a unique route r. 697

    �����In order toTocater for this model transformation, we 698enriched our CSP||B model with an event idle that does noth- 699ing. On the CSP side, this means the addition of a new process 700IDLE = idle → IDLE to the controller; on the B side, this 701means the addition of a new operation idle = movedPoint := 702∅.. This process is only needed for the justification of our 703model����

    ���transformation,transformation;it is not required for the 704verification of 705safety. 706

    Removing the trains in the set B from a system run also 707affects the states of the B machine. For example, one com- 708ponent of a B machine state S is the mapposS : Train → 709AllTrack which stores for each train the track it occupies 710and the direction it moves. Recall from ����Section Sect. 6 711that AllTrack contains the special nullTrack for modelling 712����

    �runthrough.run-through.If we remove the trains in B, we 713would hope that for the corresponding state T the follow- 714ing relation holds: 715

    posT = posS|(Train\B). 716

    That is, the mapping posT should be the same as posS, but 717be defined over the restricted domain Train \ B. The corre- 718spondence between states may, however, be more than just 719a projection onto the remaining trains. This consideration 720motivates the following definition. 721

    123

    Journal: 10009 MS: 0304 TYPESET DISK LE CP Disp.:2014/3/4 Pages: 28 Layout: Large

  • unco

    rrec

    ted

    proo

    f

    Techniques for modelling and verifying railway interlockings

    Definition 3 Let S and T be states of the B machine of CSP ||722B(SP, Train) and let B ⊆ Train be a set of trains. State T723is in B-correspondence to state S, written T ≤B S, iff the724following nine conditions are fulfilled.725

    f.1: posT = posS|(Train\B).726f.2: nextdT = nextdS .727f.3: signalStatusT = signalStatusS .728f.4: normalPointsT = normalPointsS .729f.5: reversePointsT = reversePointsS .730f.6: movedPointsT = movedPointsS .731f.7: ∀ r ∈ Route.732

    currentLocksT [{r}] = currentLocksS[{r}] or733currentLocksT [{r}] = ∅.734( The run without the trains of B either has the same locks735for a route or none at all. )736

    f.8: ∀ s ∈ Signal . if signalStatusS(s) = green then there is737a unique r ∈ Route such that738

    signal(r) =�s,s,739currentLocksS(r) = lockTable(r), and740

    currentLocksT (r) = lockTable(r).741

    ( If a signal is green, then there exists exactly one route742associated with that signal which is set. )743

    f.9: ∀ b ∈ B, r ∈ Route . if posS(b) ∈ units(r) then744currentLocksT (r) = ∅.745( The locks of any route that contains a track segment746occupied by a train b ∈ B in state S have been released747in state T . )748

    With the above correspondence in place, we want to establish749the following simulation properties:750

    ( a ) For states S and T with T ≤B S, if event e is enabled in751S, then replaceB(S, e) is enabled in T ;752

    ( b ) furthermore, the states S′ and T ′ which result from per-753forming these events are themselves in B correspondence,754

    ��i.e.,i.e.T ′ ≤B S′.755

    The following diagram illustrates this situation:756

    757

    We establish these two properties under a condition on the758set B. We say that the trains in B never cause a collision in a759system run, if in this run the collision event is never enabled760with a train t ∈ B as a witness, ��i.e.,i.e.if there is no state in761

    which ∃ t1, t2 ∈ Train : t1 �= t2 ∧ ({pos(t1)} ∩ {pos(t2)}) \ 762(Exit ∪ Entry ) �= ∅ ∧ (t1 ∈ B ∨ t2 ∈ B). 763Lemma 1 Given a scheme plan SP and a set Train of trains 764containing B ⊆ Train, if σ is a system run of CSP || 765B(SP, Train) in which trains in B do not cause a colli- 766sion, then replaceB(σ ) is a system run of the B machine of 767CSP ||B(SP, Train \ B). 768Proof The proof is by induction on the length of σ . The 769base case is trivial, and the induction cases are generally 770unproblematic. �� 771

    Lemma 1 allows us to extend the function replaceB to 772system runs σ = 〈S0, e1, S1, . . . , ek, Sk〉 as follows. 773replaceB(σ ) = 〈T0, replaceB(S0, e1), . . . , 774

    Tk−1, replaceB(Sk−1, ek), Tk〉 775���HereHere,T0 = S0 ( the initial state ) . Lemma 1 guarantees 776

    that for all 1 ≤ i ≤ k, replaceB(Si−1, ei) is enabled in Ti−1 777and leads to Ti with Ti ≤ Si. 778

    With this result in place, we show that the events of 779replaceB(σ ) give a trace of the CSP controller. 780

    Lemma 2 Given a scheme plan SP and a set Train of trains 781containing B ⊆ Train, if σ is a system run of CSP || 782B(SP, Train), then events(replaceB(σ )) is a trace of the CSP 783controller CTRL(SP, Train \ B). 784Proof Using process algebraic laws, one shows that pro- 785jections of the trace events(replaceB(σ )) are traces of the 786individual processes out of which the controller process 787CTRL(SP, Train \ B) is built. �� 788

    Combining these two lemmas gives the following result. 789

    Theorem 2 Given a scheme plan SP and a set Train of 790trains containing B ⊆ Train, if σ is a system run of CSP || 791B(SP, Train) in which trains in B do not cause a collision, 792then replaceB(σ ) is a system run of CSP ||B(SP, Train \ B). 793Proof Let σ be a system run of CSP || B(SP, Train). By 794Lemma 1 we know that replaceB(σ ) is a run of the B machine 795M of CSP || B(SP, Train \ B), and in particular we have 796that events(replaceB(σ )) ∈ traces(M). By Lemma 2 we 797know that replaceB(σ ) ∈ tracesCTRL(SP, TRAIN). Thus, 798by the semantics of CSP||B, replaceB(σ ) is a system run of 799CSP ||B(SP, Train \ B). �� 800

    7.2 Verification for safety 801

    Safety in the models is dependent on the number of trains 802which are introduced into the model. This motivates the fol- 803lowing definition. 804

    123

    Journal: 10009 MS: 0304 TYPESET DISK LE CP Disp.:2014/3/4 Pages: 28 Layout: Large

  • unco

    rrec

    ted

    proo

    f

    P. James et al.

    Definition 4 Let805

    ERROR = {collision, derailment, run− through}806be the set of error events of interest.807

    – A scheme plan SP is n-e-free ( for n ∈ N>0 and e ∈808ERROR ) iff e is never enabled in any state of any σ ∈809CSP ||B(SP, Train) with |Train| = n.810

    – A scheme plan SP is safe iff it is n-e-free for all n ∈ N>0811and e ∈ ERROR.812

    We can now turn Theorem 2 into a proof method. The813following Corollary is the basis of finitisation.814

    Corollary 1 A scheme plan SP is safe if it is 2-collision free,8151-derailment free and 1-run− through free.816Proof Assume that SP is not safe, ����i.e., thati.e.it is not n-e-817safe for some n ∈ N>0 and e ∈ ERROR. This means that818there is a run σ of CSP ||B(SP, Train) with |Train| = n such819that e is enabled in some state of σ .820

    Let σ = 〈S0, e1, S1, . . . , ek, Sk〉. Without loss of general-821ity, let us assume that822

    • ( C1 ) e is enabled in Sk ; and823• ( C2 )∀ e′ ∈ ERROR : e′is not enable in S0, . . . , Sk−1.824

    We consider each error type in turn.825

    Case 1: e = collision.826

    – By ( C1 ) , ∃ t1, t2 ∈ Train, t ∈ Track such that t =827posSk (t1) ∧ t = posSk (t2);828

    – by ( C2 ) , ek is a move of t1 or t2;829– trains in Train \ {t1, t2} do not cause collision in σ ;830– by Theorem 2, replaceTrain\{t1,t2}(σ ) is a run of CSP ||831

    B(SP, {t1, t2});832– Tk ≤Train\{t1,t2} Sk , where Tk is the last state in833

    replaceTrain\{t1,t2}(σ );834– By ( f.1 ) , t = posTk (t1) ∧ t = posTk (t2);835– collision is enabled in Tk ;836– SP is not 2-collision free.837

    Case 2: e = derailment.838

    – By ( C1 ) , ∃ t ∈ Train, p ∈ movedPointsSk such that839homePt(p) = posSk (t);840

    – by ( C2 ) , ek is a request.r.yes;841– trains in Train do not cause collision in σ ;842– by Theorem 2, replaceTrain\{t}(σ ) is a run of CSP ||843

    B(SP, {t});844– Tk ≤Train\{t} Sk , where Tk is the last state in845

    replaceTrain\{t}(σ );846

    – By ( f.6 ) and ( f.1 ) , p ∈ movedPointTk ∧ homePt(p) = 847posTk (t); 848

    – derailment is enabled in Tk ; 849– SP is not 1-derailment free. 850

    Case 3: e = run− through. 851

    – By ( C1 ) , ∃ t ∈ Train such that nullTrack = posSk (t); 852– By ( C2 ) , ek is a move of t; 853– trains in Train do not cause collision in σ ; 854– by Theorem 2, replaceTrain\{t}(σ ) is a run of CSP || 855

    B(SP, {t}); 856– Tk ≤Train\{t} Sk , where Tk is the last state in replaceTrain\{t} 857

    (σ ); 858– By ( f.1 ) , nullTrack = posTk (t); 859– run− through is enabled in Tk ; 860– SP is not 1-run-through free. 861

    �� 862Corollary 1 works with different numbers of trains: two 863

    trains are needed in the case of collision, one train is needed 864otherwise. �����In order toTobe able to check safety for all three 865properties in one go, we prove the following. 866

    Theorem 3 If a scheme plan SP is n-e-free, then SP is k-e- 867free for any k < n. 868

    Proof If SP is not k-e-safe, then there exists a run σ ∈ CSP || 869B(SP, Train) with |Train| = k such that e is enabled in some 870state of σ . But σ is also a run of CSP ||B(SP, Train′) where 871Train ⊆ Train′, with ∣∣Train′∣∣ = n. � 872

    8 Covering 873

    In the following, we develop a theory of covering a scheme 874plan with a set of smaller sub-scheme plans in such a way that 875safety of all sub-scheme plans implies safety of the original 876scheme plan. 877

    The fundamental idea of covering is that any violation 878of a safety property happens at a specific location. We 879can ��say,sayat which ( set of ) locations L a collision, a 880����

    �runthrough,run-throughor a derailment happens in the track 881plan. A set of locations L can be influenced in two different 882ways: ( i ) a train reaches a location in L or ( ii ) a train 883releases a lock of a point which lies on a route towards L. In 884����SectionSect.8.1 we provide a construction that, given a set 885L, computes a set L∞ which is closed under both influences 886listed above and includes L. The construction is described 887using our DSL for the ����

    ����Railway Domain,railway domain;see 888����Section Sect. 4 . Thus, it is part of the domain. Consequently, 889the construction is open for re-use in any modelling formal- 890ism. 891

    123

    Journal: 10009 MS: 0304 TYPESET DISK LE CP Disp.:2014/3/4 Pages: 28 Layout: Large

  • unco

    rrec

    ted

    proo

    f

    Techniques for modelling and verifying railway interlockings

    In����Section Sect. 8.2 we prove in the context of our CSP||B892modelling that safety of all sub-scheme plans implies safety893of the original scheme plan. First we prove: for any run σ in894the CSP||B model of the original scheme plan and for any set895L there is a corresponding run σL in the CSP||B model of the896sub-scheme plan constructed for L. From this result, we prove897as corollary: if the CSP||B models of the sub-scheme plans898are safe for all sets L to be considered for a specific safety899property, then the CSP||B model of the original scheme plan900is safe as well. Our proofs in ����Section Sect. 8.2 are tightly901bound to the language ����CSP||B,CSP||B;however, in the con-902text of modelling scheme plans in CSP [22] , we proved as903well that the covering construction of����Section Sect. 8.1 allows904compositional verification.905

    8.1 Domain inherent covering construction906

    Given a scheme plan SP = (Top, CT, RTs) as described in907����Section Sect. 4 and a set L ⊆ Track \ (Entries ∪ Exits) of908“critical tracks”, we describe the construction of a scheme909plan SPL = (TopL, CTL, RTsL). The scheme plan SPL will910be used to investigate safety at tracks in L.911

    In a first step, we consider all tracks over which a train912can travel on the topology towards a track in L. Figure 11913provides an illustration for all notions introduced below.914

    First, we give a construction that collects the tracks of L915together with all tracks over which a train can travel on the916topology towards a track in L:917

    Cone(L)�= = {u ∈ Unit | ∃ path p : hd(p) ∈ Entries,918last(p) ∈ L, u ∈ p}.919

    One can think of each element of L as the apex of a cone and920of Cone(L) as the union of these����

    ����cones – see Figure cones—921see Fig. 11 ���( a ) .a.922

    Then, we define the set of all topological routes that share923a unit with L:924

    Routes(L) = {r ∈ TopoRoute |∃ u ∈ L : u ∈ topoUnits(r)}925

    The Region of L consists of those units which are on a926route directly leading to L—see Fig. 11 ���( b ) :b:927

    Region(L) = Cone(L) ∩⎛

    ⎝⋃

    r∈Routes(L)topoUnits(r)

    ⎠928

    We close the region by adding suitable entry and exit units:929

    Entries(L) = (predecessor(Region(L)) \ Region(L))∩ Cone(L)

    Exits(L)={u ∈ successor(Region(L)) \ Region(L) |∃ path p :

    hd(p) ∈ Entries(L) ∧ last(p) = u}

    930

    where the successor and predecessor functions are applied 931point-wise to the set. The ClosedRegion—see Fig. 11 932

    ������( c ) – finallyc—finallyis 933

    ClosedRegion(L) = Region(L) ∪ Entries(L) ∪ Exits(L) 934We illustrate this construction by an example: 935

    Example 1 [ Closed region of track DF ] For track DF of the 936scheme plan shown in ����Figure Fig. 2 , we compute: 937

    – Cone({DF}) = {EN1, DA, DB, DC, DD, DE, DF}, 938– Routes({DF}) = 939{〈DC, DD, DE, DF〉 , 〈DF, DG, DH〉}, 940

    – Region({DF}) = {DC, DD, DE, DF}, 941– Entries({DF}) = {DB}, 942– Exits({DF}) = {DG, UE}, and 943– ClosedRegion({DF}) = 944{DB, DC, DD, DE, DF, DG, UE}. 945

    Note that we include the units of two routes into the Routes 946of DF. This is the case as trains are allowed to overrun a red 947signal by one track; thus 〈DC, DD, DE, DF〉 is included. UE 948is an exit as there is a path from the entry DB to UE. 949

    In the second step, we take the release tables into account 950for our construction. Here, we want to include all tracks that 951can release a point in ClosedRegion(L). 952

    Given a route r ∈ Routes(L), the signal topoSignal(r) can 953control further routes which not necessarily share a unit with 954L. �����In order toTocollect these routes, we define 955

    Signals(L) = {s ∈ Signal | ∃ r ∈ Routes(L) :topoSignal(r) = s} 956

    and 957

    RouteNames(L) = {r ∈ Route | signal(r) ∈ Signals(L)} 958Note that RouteNames(L) consists of names defined in the 959control table rather than of topological routes. 960

    We are now ready to define the influence zone on a track 961by closing under topological influence and point releases. To 962this end, we define the following iteration: 963

    – We set L0 = L. 964– For i ≥ 0, let 965

    Li+1 = Li ∪ {t ∈ Unit \ ClosedRegion(Li) |∃ p ∈ Point ∩ Region(Li),∃ r ∈ RouteNames(Li) :

    (r, t) ∈ release(p)}966

    Here, we increase the set Li of critical tracks by those 967tracks in the release tables RTs which refer to a point in 968Region(Li) and belong to a route which is controlled by a 969signal in Signals(Li). 970

    123

    Journal: 10009 MS: 0304 TYPESET DISK LE CP Disp.:2014/3/4 Pages: 28 Layout: Large

  • unco

    rrec

    ted

    proo

    f

    P. James et al.

    (a) (b) (c)

    Fig. 11 Influence region ( all track directions are left to right )

    Let L∞ be the smallest fixed point of the iteration,��i.e.,i.e.the971first appearance of Li = Li+1. As the topology consists of972finitely many tracks and points, the iteration terminates.973

    Example 2 ( Continuation of Example 1 ) P101 is the974only point in Region(L0). In the release table of P101, we975find {(R12A, DE), (R12B, UE)} ⊆ release(p101) for route976names in RouteNames(L0) = {R12A, R12B, R14}. Thus, DE977and UE are the potential candidates to be added to L0. As978DE, UE ∈ ClosedRegion(L0), we have L1 = L0.979

    Note that EntriesL ⊆ Track thanks to the condition that980signals are never located at points. To increase the readability981of our proofs in the next section, concerning Exits(L) we add982the slightly weaker exit condition : for any point p ∈ Exits(L)983it holds that p shares exactly one connector with Region(L).984

    Given a set L∞ for which the exit conditions holds, we985construct a new scheme plan SPL = (TopL, CTL, RTsL) as986given in ����Figure Fig. 12 . The tracks of SPL are all the tracks987in the closed region of L∞ together with those points of the988closed region which are used in one direction only and thus989can be turned into tracks. The points of SPL are all points990within the closed region of L∞ which have not been turned991into tracks. For ease of construction we keep the old set of992connectors. The connectivity of the new topology is given by993choosing appropriate connectors and directions for the tracks994in TrackL and the points in PointL .995

    For t ∈ TrackL , we define:996

    – If t ∈ Track, nothing changes, ��i.e.,i.e.c1L(t) = c1(t) and997c2L(t) = c2(t); and directionsL(t) = directions(t).998

    – If t ∈ Point such that t ∈ Exits(L∞) we know that999t shares only one connector, say c, with Region(L∞).1000In this case we turn the point into a track. We keep1001the connector where the point joins Region(L∞) and1002allow travel out of the region, ��i.e.,i.e.we set c1L(t) = c1003and ���chosechoosefor c2L(t) one of connectors(t) \ {c};1004directions(t) = (c1L(t), c2L(t)).1005

    – If t ∈ Point with t ∈ Region(L∞) such that one arm1006of t ends outside,��i.e.,i.e.predecessor(t) ∪ successor(t) �⊆1007ClosedRegion(L∞), we turn the point into a track. We1008

    Fig. 12 The scheme plan SPL = (TopL, CTL, RTsL)

    keep those connectors which are on a path towards 1009a unit in L∞ and allow travel along this path. Let 1010c ∈ connectors(t) be the connector leading out of 1011the region, ��i.e.,i.e.for all u ∈ ClosedRegion(L∞) \ {t}: 1012c /∈ connectors(u). Then, choose as c1L(t) one of 1013connectors(t) \ {c} and define c2L(t) to be the one ele- 1014ment in connectors(t) \ {c, c1L(t)}; set directionsL(t) = 1015directions(t) ∩ {(c1L(t), c2L(t)), (c2L(t), c1L(t))}. 1016

    For p ∈ PointL nothing������changes, i.e.,changes; i.e.c1L(p) = 1017c1(p), c2L(p) = c2(p) and c3L(p) = c3(p); and directionsL(p) =1018directions(p). 1019

    8.2 Correctness proof of covering in CSP||B 1020

    Our encoding method for scheme plans into CSP||B is 1021generic,��i.e.,i.e.given a scheme plan SP, we obtain an encod- 1022ing CSP ||B(SP). Similarly, given a set L of critical units, we 1023obtain an encoding CSP ||B(SPL) of the above constructed 1024scheme plan SPL . In the following, we show that any run σ 1025on CSP ||B(SP) corresponds to a run σL on CSP ||B(SPL), 1026where σL is obtained from σ by renaming of events and 1027abstraction on the B states. 1028

    123

    Journal: 10009 MS: 0304 TYPESET DISK LE CP Disp.:2014/3/4 Pages: 28 Layout: Large

  • unco

    rrec

    ted

    proo

    f

    Techniques for modelling and verifying railway interlockings

    For ease of readability, we present our correctness proof1029for convex scheme plans SPL only. SPL is convex, if in1030SP trains cannot travel from a unit u ∈ Exits(L) to a unit1031v ∈ Entries(L). In our proof practice, all scheme plans SPL1032have turned out to be convex. The results presented can eas-1033ily be adapted to non-convex plans by either changing the1034construction of the closed region or by adding a renaming1035function on train identifiers that gives a fresh identifier to a1036train that enters the units of SPL a second time. Both changes,1037however, lead to a plethora of notations that obscure the proof1038idea.1039

    8.2.1 Run construction1040

    Let SP be a scheme plan, let L be a set of critical units, and1041let σ be a run on CSP ||B(SP). On the states of the B machine1042we define a function πL to project states of CSP ||B(SP) into1043states of CSP ||B(SPL). Let S be a state of CSP ||B(SP), then1044the projection of S on CSP ||B(SPL) is a state T , written as1045πL(S) = T where:1046

    cv1: posT = posS ∩ (Train× AllTrackL)1047cv2: nextdT = nextdS ∩ (UnitL × AllTrackL)1048cv3: signalStatusT = signalStatusS ∩ (SignalL × Aspect)1049cv4: normalPointsT = normalPointsS ∩ PointL1050cv5: reversePointsT = reversePointsS ∩ PointL1051cv6: movedPointsT = movedPointsS ∩ PointL1052cv7: currentLocksT = currentLocksS ∩ (RouteL × PointL)1053

    This projection has some simple but important properties:1054

    – emptyTracksT = emptyTracksS ∩ AllTrackL and1055– unlockedPointsT = unlockedPointsS ∩ PointL .1056

    In the following, we construct a sequence σL that we1057will prove to be a run of CSP || B(SPL). The sequence1058σL is defined using the function replace(S, e). replace1059takes a state S of the B machine and an event e as1060

    �����arguments,argumentsand returns an event. The result of this1061function is defined according to the table in ����Figure Fig. 131062: we match the structure of e against the patterns given in1063the first column—e being an event of the CSP||B encoding1064of our scheme

    ��������

    ��������

    plan – evaluate the condition – statedplan—1065evaluate the condition—statedin our ����

    ���DSL – in orderDSL—1066to obtain the replacement event e′. Roughly speaking, we1067keep all events that are within the scope of the scheme plan1068SPL , andreplace all events out of the scope of the scheme1069plan SPL with idle.1070

    Given a run σ = 〈S0, e1, S1, . . . , Sk−1, ek, Sk〉, k ≥ 0, we1071extend the above functions πL and replaceL to sequences:1072

    replaceL(σ ) = 〈πL(S0), replaceL(S0, e1), . . .πL(Sk−1), replaceL(Sk−1, ek), πL(Sk)〉1073

    Then, we define σL = replaceL(σ ). ���Note,Notethat states in 1074σL are gained by projection. This is in contrast to our con- 1075struction for finitisation. The difference between the con- 1076structions is that in the case of finitisation we have a relation 1077between states, while in the case of covering we project states 1078from the original run. 1079

    8.2.2 Proving the run in CSP||B 1080

    It remains to show that σL is actually a system run on CSP || 1081B(SPL). To this end we want to mimic train movements on the 1082original scheme plan by entering of a train into the scheme 1083plan SPL—see the last row of the table in ����Figure Fig. 13 , 1084condition cp /∈ UnitL, np ∈ Entry L . This is only possible 1085for runs where the ����

    ��pre-conditionspreconditionsof the enter 1086operation in the B machine are true, ��i.e.,i.e.the following 1087enter property holds. For all tracks t ∈ Entry L , events e = 1088move.id.x.t ∈ σ , id ∈ Train, x ∈ Track, states S ∈ σ where 1089S is the state before e in σ , we have: 1090

    ({t} ∪ successor(t)) ∩ dom(ran(posS)) = ∅, 1091��i.e.,i.e.there is no train on t or the successor of t. 1092

    Lemma 3 Given a scheme plan SP, a set L of critical units 1093and a run σ ∈ CSP ||B(SP) with the enter property, then 1094

    1. σL is a run of the B machine of CSP ||B(SPL). 10952. events(σL) is a trace of the CSP controller of CSP || 1096

    B(SPL). 1097

    Proof The proof is by induction on the length of σ and case 1098distinction on the operations. The result w.r.t. the CSP con- 1099troller uses process algebraic laws to decompose the con- 1100troller and then ���

    ��explicitelyexplicitlyshows that ( projections 1101) of the given trace are in the trace sets of the components. �� 1102Corollary 2 Given a scheme plan SP, a set L of critical units 1103and a run σ ∈ CSP ||B(SP) with the enter property, then σL 1104is a run of CSP ||B(SPL). 1105Proof By Lemma 3 and the definition of the semantics of 1106CSP||B. �� 1107

    8.2.3 Application to safety 1108

    It remains to utilize the above result for compositional rea- 1109soning concerning safety: 1110

    Corollary 3 Let SP be a scheme plan, then the following 1111holds: 1112

    1. If CSP || B(SPL) is collision free for all L = {u} where 1113u ∈ Unit\(Entries∪Exits), then CSP ||B(SP) is collision 1114free. 1115

    123

    Journal: 10009 MS: 0304 TYPESET DISK LE CP Disp.:2014/3/4 Pages: 28 Layout: Large

  • unco

    rrec

    ted

    proo

    f

    P. James et al.

    Fig. 13 Definition of thereplaceL function on events forcovering

    2. If CSP ||B(SPL) is�����runthroughrun-throughfree for all L =1116{u}where u ∈ Point, then CSP ||B(SP) is�����runthroughrun-1117throughfree.1118

    3. If CSP ||B(SPL) is derailment free for all L = {u} where1119u ∈ Point, then CSP ||B(SP) is derailment free.1120

    Proof Ad 1., collision freedom: assume that1121CSP ||B(SP) �|� AG(¬ e(collision)). Then, according to1122

    Corollary 1, there exists a shortest run σ of CSP || B(SP)1123involving only two distinct trains id1 ∈ Train and id2 ∈1124Train such that the last state of σ , say S, enables the collision1125operation. Let u = posS(id1) be the track or point where1126the collision occurs. Note that u /∈ Entry ∪ Exit thanks to1127the precondition of the B event collision. By construction of1128SP{u}, u cannot be an entry track of SP{u} or the successor of1129an entry track of SP{u}. Therefore,σ has the enter property. By1130Corollary 2, we know that σ{u} is a run of CSP ||B(SP{u}). By1131construction of σ{u}, its last state is T = π{u}(S). By definition1132of π{u}, equation cv1, we have posT (S) = posS \ {id �→1133t | t /∈ Unit{u}}. As u ∈ Unit{u}, posT (id1) = posT (id2),1134��i.e.,i.e.trains id1 and id2 collide in the run σ{u} of CSP ||1135B(SP{u}).1136

    Ad 2.,�����runthroughrun-throughfreedom: assume that in the1137model CSP ||B(SP) �|� AG(¬ e(�����runthroughrun− through)).1138Then, according to Corollary 1, there exists a shortest run σ1139of CSP || B(SP) involving only one train such that the last1140state of σ , say S, enables the run − through operation. For1141this train with id ∈ Train it holds that posS(id) = nullTrack1142in S, ��i.e.,i.e.train id has run through a point which was not1143set for the train’s direction. The last move of id in σ is of the1144form e = move.id.cp.nullTrack. Let S′ be the state before e1145in σ and let cp = posS′(id). Then, nextdS′(cp) is not defined.1146Thus, successor(cp) ∈ Point. As any connector can belong1147to at most two units, successor(cp) is uniquely defined. Let1148p be this point successor(cp). Let σ ′ be the prefix of σ up to1149S′ e S′′. The run σ ′ has the enter property because at most one1150

    track is occupied in any state of σ . By Corollary 2, we know 1151that σ{u} is a run of CSP ||B(SP{u}). By definition of π{p}, part 1152cv1, we have posT ′′ = posS′′ \{id �→ d | t /∈ Unit{u}}), there- 1153fore posT ′′(id) = nullTrack, ��i.e.,i.e.train id has run through 1154the point p which was not set for the train’s direction. 1155

    Ad 3., derailment freedom: assume that in the model 1156CSP || B(SP) �|� AG(¬ e(derailment)). Then, according 1157to Corollary 1, there exists a shortest run σ of CSP ||B(SP) 1158involving only one train such that the last state of σ , say S, 1159enables the derailment ����

    ���operation. I.e.,operation, i.e.for the 1160train with id ∈ Train it holds in S: 1161

    posS(id) ∈ homePoint(movedPoints) 1162

    ��i.e.,i.e.train id has derailed at the point u = posS(id). 1163The run σ has the enter property because at most one track 1164

    is occupied in any state of σ . Thus, by Corollary 2, we know 1165that σ{u} is a run of CSP ||B(SP{u}). By construction of σ{u}, 1166its last state is T = π{u}(S). By definition of π{u}, part cv1, 1167we have posT (S) = posS \ {id �→ d | t /∈ Unit{u}}. As u ∈ 1168Unit{u}, posT (id) = posS(id). By definition of π{u} part 6, 1169we have movedPointsT = movedPointsS \ {p | p /∈ PointL}. 1170As u ∈ Point{u}, we have u ∈ movedPointsT . This means 1171train id has derailed. �� 1172

    Remark 1 ( Localised safety ) We work here with the safety 1173properties as originally defined in ����Section Sect. 6 . In our 1174proof practice, this approach has been always successful. 1175However, it is possible to define localised safety properties. 1176For instance, one can define the localised safety property “no 1177collision at unit u”. The corollary above can be established 1178with such localised safety properties which are weaker than 1179the ones we work with. 1180

    123

    Journal: 10009 MS: 0304 TYPESET DISK LE CP Disp.:2014/3/4 Pages: 28 Layout: Large

  • unco

    rrec

    ted

    proo

    f

    Techniques for modelling and verifying railway interlockings

    9 Topological abstraction1181

    In the following we define a theory for the abstraction of1182a scheme plan in such a way that safety of the abstraction1183implies the safety of the concrete scheme plan. This is moti-1184vated by [24] where we introduced an abstraction technique1185which allows the transformation of complex CSP||B models1186of scheme plans into less involved ones.1187

    In this paper, as described in����Section Sect. 3 , the topology1188of the railway network has been enriched with connectors1189����in orderto be able to capture the dynamic direction of the1190points; therefore the CSP||B models are also more detailed.1191This means that we need to define an improved notion for the1192abstraction of scheme plans which reflects the fact that the1193topology of the railway network now contains connectors.1194

    In this section the complex CSP||B models are formal1195representations of concrete scheme plans SP, referred to as1196SPC = CSP || B(SP), whereas the less involved CSP||B1197models are referred to as SPA. More formally, consider two1198scheme plans SPC and SPA. An abstraction (abst, absc) from1199SPC to SPA consists of1200

    – a total function1201

    abst : AllTrackC → AllTrackA1202

    satisfying1203

    abst[TrackC] = TrackA,1204abst(e) = efore ∈ ENTRYC ∪ EXITC, and1205abst(nullTrack) = nullTrack;1206

    and1207– a partial function1208

    absc : AllConnectorC → AllConnectorA1209

    satisfying1210

    absc(C0) = C0and1211absc[ConnectorC] = ConnectorA1212

    such that the following 18 properties are satisfied:1213

    a.1: Entry A = Entry C (= Entry )1214a.2: Exit A = Exit C (= Exit )1215a.3: PointA = PointC (= Point)1216a.4: ∀ p : Point . (homePtA(p) = abst(homePtC(p)))1217a.5: if 〈t1, t2〉 is a path in SPC , then abst(t1) = abst(t2) or1218

    〈abst(t1), abst(t2)〉 is a path in SPA1219a.6: ∀ at : TrackA . abs−1[{at}] is connected.1220

    a.7: if 〈at1, at2〉 is a path in SPA, then ∃ t1, t2 : TrackC . 1221t1 ∈ abs−1[{at1}], t2 ∈ abs−1[{at2}] and 〈t1, t2〉 is a 1222path in SPC . 1223

    a.8: ∀ p : Point . dynamicDirectionA(p) 1224= absc(dynamicDirectionC(p), 1225where absc(c1, c2) = (absc(c1), absc(c2)) 1226

    a.9: SignalA = SignalC 1227a.10: ∀ s : Signal . (homeSigA(s) = abst(homeSigC(s))) 1228

    (= homeSig) 1229a.11: if 〈t1, t2〉 is a path in SPC , and signalAtC(s) = t1 for 1230

    some signal s, then 〈abst(t1), abst(t2)〉 is a path in SPA 1231a.12: RouteA = RouteC (= Route) 1232a.13: ∀ r :����Route .Route. 1233

    (abs−1t [clearTableA(r)] = clearTableC(r)) 1234a.14: ∀ e :����Entry .Entry . 1235

    (abs−1t [entryTableA(e)] = entryTableC(e)) 1236a.15: normalTableA = normalTableC (= normalTable) 1237a.16: reverseTableA = reverseTableC (= reverseTable) 1238a.17: releaseTableA = 1239

    {(abst(t), (r, p)) | (t, (r, p)) ∈ releaseTableC}) 1240a.18: if 〈t1, t2〉 is a path in SPC , and 1241

    t2 ∈ dom(releaseTableC) then 〈abst(t1), abst(t2)〉 is a 1242path in SPA 1243

    Conditions a.1, a.2, a.3, a.9 and a.12 simply state that 1244the entry and exit tracks, points, signals and routes remain 1245unchanged in an abstraction. The only condition that makes 1246use of the absc function is a.8, which ensures that the direc- 1247tion of the points are maintained in an abstraction. All the 1248other conditions map tracks, points and signals through the 1249abstraction function abst . Conditions a.5, a.6 and a.7 are the 1250interesting ones because these are the ones that constrain how 1251tracks can collapse and how abstract and concrete paths map 1252to each other. Finally, conditions a.13–a.18 ensure that the 1253abstracted topology is correctly reflected in the control and 1254release tables. 1255

    Theorem 4 provides the justification that it is enough to 1256model check the abstract scheme plan SPA to ensure that the 1257required safety properties of the interlocking system hold, 1258and then infer that the same properties hold for the concrete 1259scheme plan SPC . 1260

    Theorem 4 If there is an abstraction from SPC to SPA, then: 1261

    1. if SPA is������collision-free,collision free,then SPC is����

    ��collision-free;collision1262free; 1263

    2. if SPA is �������derailment-free,derailment free,then SPC is 1264

    �������derailment-free;derailment free;and 1265

    3. if SPA is �������runthrough-free,run-through free,then SPC is 1266

    �������runthrough-free.run-through free. 1267

    Proof ( sketch ) The conditions a.1–a.18 on the abst and 1268absc functions are sufficient to ensure that concrete transi- 1269

    123

    Journal: 10009 MS: 0304 TYPESET DISK LE CP Disp.:2014/3/4 Pages: 28 Layout: Large

  • unco

    rrec

    ted

    proo

    f

    P. James et al.

    Fig. 14 Topological abstraction: relating concrete to abstract events

    Fig. 15 Langley concrete sub-scheme plan SPC ( resulting from covering for track UC )

    tions can be matched with abstract ones. In more detail, any1270move that changes state—clearing a region; passing a signal;1271releasing a lock—will be matched by an abstract move given1272in ����Figure Fig. 14 ( or idle if the train remains on the same1273abstract track ) �;,and conditions for granting and releasing1274routes are1275matched.1276

    The proof proceeds by setting up a linking relation1277between CSP||B (SPC) and CSP||B (SPA) to show that con-1278crete runs are matched by abstract runs. Two states are1279linked if their signals, points and locks all match, and if1280the abstract train positions match the concrete train posi-1281tions under abst . Given a matching pair of states, a con-1282crete event transition to a concrete state can be matched1283by an abstract event transition to a matching abstract1284state. The proof establishes this by a case analysis on the1285events.1286

    This means that any concrete run can be matched by1287an abstract run. ���HenceHence,any concrete run containing1288collision, derailment or run−through can be matched by an1289abstract run containing the same event. It follows that if no1290abstact run contains such events, then no concrete run can1291contain them either. ��1292

    If we consider SPC to be the station based on Langley as1293shown in����Figure Fig. 2 ,there are no opportunities for abstrac-1294tion to reduce tracks which satisfy the above conditions. This1295is not unusual in practice for large scheme ��

    �plansplans,since1296there are limited opportunities to perform abstraction due1297to the lack of sequences of collapsible sequential tracks,1298

    ��i.e.,i.e.ones that do not contain signals and are not used in the 1299release tables. However, the benefit of our abstraction tech- 1300nique becomes clear when we apply this technique after we 1301apply the covering technique, introduced in����Section Sect. 8 . 1302After applying the covering technique the set of sub-scheme 1303plans derived from SPC will each contain many opportuni- 1304ties for abstraction. This is because some points in a sub- 1305scheme plan are only considered in one direction, and so 1306are treated as tracks. This gives rise to sequences of tracks 1307which can then be collapsed. For example, ����Figure Fig. 15 1308illustrates an example sub-scheme plan for Langley, which 1309focuses on track UC and contains the opportunity to abstract 1310tracks UE/EF and DRD/DRE. It shows that abst(DRD) = 1311abst(DRE) = a DRD, abst(UE) = abst(UF) = a UE, and 1312maps t to a t for all other track names t. absc is the corre- 1313sponding mapping on connectors. Figure 16 illustrates the 1314abstraction for this sub-scheme plan. 1315

    10 Experiments 1316

    In this section we outline various experimental results car- 1317ried out on our models. We use the CTL model checker pro- 1318vided by ProB tool [32] ( version 1.3.6-final )��– on— 1319ona standard PC with a quad-core����3.2GHz3.2 GHzCPU and 1320

    ��������8GB memory – to8 GB memory—tocheck the validity of the 1321

    following CTL formula: 1322

    AG(

    not(

    e(collision) ∨ e(run− through) 1323∨ e(derailment) ) ) 1324

    123

    Journal: 10009 MS: 0304 TYPESET DISK LE CP Disp.:2014/3/4 Pages: 28 Layout: Large

  • unco

    rrec

    ted

    proo

    f

    Techniques for modelling and verifying railway interlockings

    Fig. 16 Langley abstractsub-scheme plan SPA

    This formula is false if one of our ERROR events is enabled.1325In the CTL variant of ProB, AG stands for “on all path it is1326globally true that”, and e(a) stands for “event a is enabled”.1327

    After summarising our proof method, we report on safety1328verification results for two case studies: a simple station1329which we have studied previously, and the complex Lang-1330ley Station. Though we do not do so here, the production of1331

    �������counter examplecounter-exampletraces for a single, unsafe1332

    CSP||B model is possible and is discussed in detail in [25] .1333

    10.1 Proof method using abstractions1334

    Utilising our three abstraction principles, we apply the fol-1335lowing proof method to analyse a scheme plan SP for safety:1336for all units u ∈ Unit of a scheme plan SP,1337

    1. we first construct the scheme plan SP{u} and encode it as1338a model CSP ||B(SP{u});1339

    2. we then apply a topological abstraction function abs to1340obtain abs

    (

    CSP ||B(SP{u}))

    ;13413. we then prove that abs

    (

    CSP ||B(SP{u}))

    is safe for two1342trains using the ProB model checker.1343

    In case that the proof in step 3 is successful for all u ∈ Unit,1344the design SP is guaranteed to itself be safe.1345

    This procedure is sound: by Theorem 4 on topological1346abstraction we know that CSP || B(SP{u}) is safe for two1347trains for all u ∈ Unit; by Corollary 1 and Theorem 3 con-1348cerning finitisation we have that CSP ||B(SP{u}) is safe for1349any numbers of trains for all u ∈ Unit; and by Corollary 3 on1350covering we have that CSP ||B(SP) is safe for any number1351of trains. As we argue that our CSP||B modelling is faithful,1352we conclude that SP is safe.1353

    10.2 Verifying a simple station example1354

    In [24] we studied the simple station case study presented in1355

    ����Figure Fig. 17 .1356We reconsider this example here to text the effectiveness1357

    of our abstraction techniques. However, unlike in [24] , here1358we consider overlaps ( ��i.e.,i.e.the ability of trains to overrun1359

    red lights ) which were not permitted in the earlier study due 1360to the assumed use of Automatic Train Protection ( ATP ) . 1361

    Overall, an example of this small size and low complexity 1362can be directly verified without applying covering and topo- 1363logical abstraction. The successful verification using finiti- 1364sation to two trains but without covering and without topo- 1365logical abstraction takes 1m56s and produces a state space 1366containing 8394 states and 83279 transitions. 1367

    We have also verified the station example using our proof 1368method as outlined in ����Section Sect. 10.1 . Figure 18 gives 1369an overview of the state space required to verify each sub- 1370scheme plan. The table shows that the number of states and 1371transitions required for each of the 8 sub-plans is much 1372smaller than the number of states and transitions required 1373for the whole scheme plan. The total time to complete the 1374verification of all these sub-plans is 1m11s, i.e. 39 % faster 1375than verifying the full scheme plan. Furthermore, if we con- 1376sider the total number of states verified, we can see that in 1377total our new method inspects 7,181 states, which is fewer 1378than the number of states needed for the verification of the 1379full scheme plan. 1380

    10.3 Verifying the Langley-based example 1381

    Direct verification ( with finitisation ) of the full scheme 1382plan for Langley is not possible due to the complexity of 1383the scheme plan, which consists of 49 tracks ( including 4 1384entries and 4 exists ) , 16 points, 12 signals and 16 routes. 1385However, the proof method from ����Section Sect. 10.1 enables 1386its successful verification. Figure 19 summarises the number 1387of states and transitions that are to be considered for the ver- 1388ification of each of the 41 sub-scheme plans of the Langley 1389example, though without topological abstraction. 1390

    In����Figure Fig. 20 we categorise our verification in terms of 1391the numbers of states involved. Over half ( 51.2 % ) of the 41 1392proofs are trivial and can be conducted within ∼10 s, whilst 139315 of the 41 (��36.636.6 ) take around∼1 min to complete. The 1394remaining����5 ( 12.2five ( 12.2 ) of the proofs require longer to 1395complete, with sub-plans for UI and UJ being particularly 1396large and taking up to 2 h each to complete. This is due to UI 1397and UJ being part of a large number of routes, which give 1398rise to large influence zones. 1399

    123

    Journal: 10009 MS: 0304 TYPESET DISK LE CP Disp.:2014/3/4 Pages: 28 Layout: Large

  • unco

    rrec

    ted

    proo

    f

    P. James et al.

    Fig. 17 Station scheme plan

    Fig. 18 Verifying the stationexample via finitisation andcovering

    Fig. 19 Verification results viafinitisation and covering

    To consider the effect of topological abstraction, we1400demonstrate its application to sub-plans of the Langley Sta-1401tion����

    ���example.Figure example. Figure 21 gives an illustration1402of the reduction in terms of sizes of state spaces gained from1403applying topological abstraction to these sub-scheme plans.1404Our results shows that a reduction of up to 50 % is possible.1405In the examples considered, topological abstraction reduces1406the number of tracks by about the same amount.1407

    Overall, our experiments demonstrate that the proof 1408methodology from ����Section Sect. 10.1 : 1409

    – reduces the verification time significantly for rail net- 1410works of small size and low complexity; and 1411

    – enables verification for rail networks of large size and 1412high complexity. 1413

    123

    Journal: 10009 MS: 0304 TYPESET DISK LE CP Disp.:2014/3/4 Pages: 28 Layout: Large

  • unco

    rrec

    ted

    proo

    f

    Techniques for modelling and verifying railway interlockings

    Fig. 20 Categories of sub-plan veri