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

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

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

4. A general view of the railway network A B S1 S2S4 S3 T1 T2 SB2 SB1 T1 ROUTE-SEGMENTS: (S1,  ), (S2,  ), (S4,  ) ROUTE-SBs: SB1, SB2, … DIR:  POS: S1 RESERVATIONS: [SB1:{S1,S2}] [SB2: {S2}] LOCKS: SB1 T2 ROUTE-SEGMENTS: (S3,  ), (S1,  ) ROUTE-SBs: SB1, … DIR:  POS: S3 RESERVATIONS: [SB1:{S3}] LOCKS: none SB1 CONNECTED: S1  S2 LOCKED_BY: T1 SENSOR: passive RES S1: T1 DIR S1:  RES S2: T1 DIR S2:  RES S3: T2 DIR S3:  ACTION: none SB2 CONNECTED: S3  S4 LOCKED_BY: none SENSOR: passive RES S4: -- DIR S4:  RES S2: T1 DIR S2:  RES S3: n.a. DIR S3:  ACTION: none

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

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

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

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

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

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

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

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

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

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

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

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

17. 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, …))

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

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