Formal Development and Verification of Distibuted Railway Control System –

Haxthausen&Peleska• To allow for private companies to be key players in the railway

networks of Europe, the train interlocking systems must change from being centralized to being distributed

• In this paper the key idea is that a railway network contains SWITCH BOXES at each railway junction and each train is equipped with a TCC (Train Control Computer) which makes the actual go-no go decision

• The design of such distributed systems is much more complicated than the design of centralized control systems. Thus additional rigor is needed in the development phase

Engineering Concepts

• Each switch box (SB) contains local information – i.e. state of the traffic lights guarding the railway crossing, and information about trains approaching the junction.

• To pass a railway crossing or to enter a new track segment, a train’s TCC communicates with the relevant SB’s to reserve relevant track segments. The knowledge of which SB’s to contact is based on GPS information.

• When the TCC has collected all the replies from the SB’s, a go-no go decision is made. If the engineer is not willing to stop the train, emergency brakes will fire.

Basic Safety Requirements

To guarantee safety for the train at its local position, two conditions must be fulfilled:

1) The train direction must be consistent with the direction associated with the local track segment

2) Each train must have a reservation for its local track segment at the next switch box to be approached by the train

To enter the next segment, three safety conditions must be fulfilled:

1) The train direction must be consistent with the direction of the segment to be entered

2) The next SB must be locked for the train

3) The train must have a reservation for the next segment at every switch box where this segment is an approaching segment

A general view of the railway network

A B

S1 S2 S4

S3

T1

T2

SB2SB1

T1ROUTE-SEGMENTS:(S1, ), (S2, ), (S4, )ROUTE-SBs:SB1, SB2, …DIR: POS: S1RESERVATIONS:[SB1:{S1,S2}] [SB2: {S2}]LOCKS: SB1

T2ROUTE-SEGMENTS:(S3,), (S1, )ROUTE-SBs:SB1, …DIR: POS: S3RESERVATIONS:[SB1:{S3}]LOCKS: none

SB1CONNECTED: S1S2LOCKED_BY: T1SENSOR: passiveRES S1: T1 DIR S1: RES S2: T1 DIR S2: RES S3: T2 DIR S3: ACTION: none

SB2CONNECTED: S3S4LOCKED_BY: noneSENSOR: passiveRES S4: -- DIR S4: RES S2: T1 DIR S2: RES S3: n.a. DIR S3: ACTION: none

Domain Model – Static Part

• To model the system accurately, we divide it into a static part and a dynamic part. Each part is described in the sequel

All of trains, points, segments have unique identifiers, that make them globally accessible. Hence the following definitions:

type TrainId;

type PointId;

type Segment

The topology of the railway network is determined by segments and we need two further definitions:

value are_neighbours: SegmentEnd x SegmentEnd Bool

Type SegmentEnd = Segment x End, End == a_end | b_end

Domain Model – Dynamic Part

• To represent the ”State” of the system, a type is defined as

type State

• Trains also have dynamic properties – especially position and direction

type

Position ==

single(seg_of: Segment) | double(fst: Segment, snd: Segment) | error

• The railway network is directed, and trains have two possible directions

type Direction == DirAB | DirBA

• To observe the mentioned properties we define functions

Value position: State x TrainId Position

direction: State x TrainId Direction

Dynamic Properties

• Points may be switched over time, so we have to make a time-dependent function describing what segment ends are connected

value are_connected: State x SegmentEnd x SegmentEnd Bool

• When a rail network is in operation, two dynamic changes may take place: first, trains move from one position to the next, and points may be switched. These are defined as follows:

value

move: State x TrainId State

switch: State x PointId x SegmentEnd State

Axioms for events

axiom (moving a train doesn’t change segment connections)

[are_connected_move]

ForAll st: State, t: TrainId, se1, se2 : SegmentEnd:

are_connected(move(st,t), se1, se2) = are_connected(st, se1, se2)

[position_move] (moving a train affects the position of the train itself)

ForAll st: State, t1, t2: TrainId:

position(move(st, t1), t2) =

if t2 = t1 then

next_position(st, position(st, t2), direction(st, t2))

else position(st, t2) end

pre safe(st)

Axioms for events - 2

value

next_position: State x Position x Direction Position

Axiom

ForAll st: State, s1, s2: Segment, dir: Direction

next_position(st, double(s1,s2), dir) = single(s2)

ForAll st: State, s1, s2: Segment, dir: Direction

are_connected (to_end(s1, dir), from_end(s2, dir))

next_position (st, single(s1), dir) = double (s1, s2)

Axioms for Events - 3

ForAll st: State, s1: Segment, dir: Direction

(ForAll s2 : Segment:

NOT (are_connected(to_end(s1, dir), from_end(s2, dir))

) next_position(st, single(s1), dir) = error

The to_end is defined as

Value

to_end: Segment x Direction SegmentEnd

to_end(s, dir) = if dir = dirAB then (s, b_end) else (s, a_end) end

Safety Requirements

The goal is to develop a train control & interlocking system that satisfies the following requirements:

No Collision: Two trains must not reside on the same segment

No Derailing: Trains must not derail

Value

safe: State Bool

safe(st) = no_collision(st) AND no_derailing(st)

No_collision : State Bool

No_collision(st) = (ForAll t1, t2: TrainId and t1, t2 distinct

segments(position(st, t1)) INTERSECT segments(position(st, t2)) = EMPTY)

Safety Requirements - 2

no_derailing: State Bool

No_derailing(st) =

(ForAll t: TrainId AND

NOT (position(st, t) = error),

(ForAll s1, s2: Segment: position(st, t) = double(s1, s2)

are_connected(st, to_end(s1, direction(st, t)), from_end(s2, direction(st,t)))))

First Stage of Verification

• Our model must satisfy strong safety requirements:

1. States satisfying the state invariant must also be safe.

2. Any state transition made by a state constructor must preserve the state invariant when the associated guard is true.

3. If the guards for two different events are both true in a state satisfying the state invariant, then a state change made by one of the events must not make the guard for the other event false.

We define two constructs

1. A state invariant consistent(st), and

2. For each constructor con, a guard (condition) can_con(st, …) which can be used by the controller to decide whether it should allow events (corresponding to application of that constructor) to happen

First Stage of Verification - 2

The strong safety requirements can be formalized by the following theories:

[consistent_is_safe]

ForAll st: State: consistent(st) safe(st)

[safe_con]

ForAll …. consistent(st) AND can_con(st, …) consistent(con(st, …))

[safe_con1_con2]

ForAll …. consistent(st) AND can_con1(st, x) AND can_con2(st,y)

can_con2(con1(st,x), y)

First Specification

The first specification is an abstract, algebraic specification which extends the domain model with the following:

Value

consistent: State Bool

Value

can_move: State x TrainId Bool

can_switch: State x PointId x SegmentEnd Bool

Two further axioms are introduced as requirements

Axiom [can_con_implication1]

ForAll …. can_con(st, …) AND consistent(st) …

Axiom [consistent_implication]

ForAll st: State consistent(st) p1(st)

Second to Fifth Specification

• In the second specification two concepts are introduced: segment registrations for trains and segment directions

• In the third specification, segment reservations at switch boxes is introduced and segment registrations are defined in terms of that. A train must LOCK a point in order to pass it, and when a train has locked a point, the point cannot be switched before the train passes the point.

• In the fourth specification, train routes are introduced and sensors at the switch boxes sense when the trains are passing

• In the fifth specification a concrete state space consisting of a state space for each train and a state space for each switch box is introduced.

Verification

• To go from one stage of specification to the next we have used an implementation relation to show that each phase is a refinement of the previous one.

• We refine the model until the fifth specification and then prove

ForAll …. consistent(st) AND can_con(st, …) (p1(con(st, …)) AND …

AND (p5(con(st, …))

Implementation

• To model the actual system we must use ideas of compositionality. We get:

Value

controller: State in any out any Unit

controller (st_t, st_s) =

(|| { TCC[t].main(st_t(t)) | t: TrainId})

||

(|| { SB[s].main(st_s(s)) | s: SwitchboxId}

This in effect a parallel composition of mutually communicating processes. The state space of the controller is the global state space of the system.

Discussion

• This method allows one to start with a highly abstract algebraic definition and refine it stepwise.

• The verification concept is general – i.e. it can be applied to arbitrary networks irrespective of topology. This is a definite improvement over the use of model checkers.

• The method allows us to start from a trace in the abstract model and to see how it is implemented in later specifications