Formal Development and Verification of Distibuted Railway Control System – Haxthausen&Peleska
description
Transcript of Formal Development and Verification of Distibuted Railway Control System – Haxthausen&Peleska
![Page 1: Formal Development and Verification of Distibuted Railway Control System – Haxthausen&Peleska](https://reader036.fdocuments.in/reader036/viewer/2022082517/56813ddc550346895da7a69e/html5/thumbnails/1.jpg)
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
![Page 2: Formal Development and Verification of Distibuted Railway Control System – Haxthausen&Peleska](https://reader036.fdocuments.in/reader036/viewer/2022082517/56813ddc550346895da7a69e/html5/thumbnails/2.jpg)
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.
![Page 3: Formal Development and Verification of Distibuted Railway Control System – Haxthausen&Peleska](https://reader036.fdocuments.in/reader036/viewer/2022082517/56813ddc550346895da7a69e/html5/thumbnails/3.jpg)
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
![Page 4: Formal Development and Verification of Distibuted Railway Control System – Haxthausen&Peleska](https://reader036.fdocuments.in/reader036/viewer/2022082517/56813ddc550346895da7a69e/html5/thumbnails/4.jpg)
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
![Page 5: Formal Development and Verification of Distibuted Railway Control System – Haxthausen&Peleska](https://reader036.fdocuments.in/reader036/viewer/2022082517/56813ddc550346895da7a69e/html5/thumbnails/5.jpg)
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
![Page 6: Formal Development and Verification of Distibuted Railway Control System – Haxthausen&Peleska](https://reader036.fdocuments.in/reader036/viewer/2022082517/56813ddc550346895da7a69e/html5/thumbnails/6.jpg)
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
![Page 7: Formal Development and Verification of Distibuted Railway Control System – Haxthausen&Peleska](https://reader036.fdocuments.in/reader036/viewer/2022082517/56813ddc550346895da7a69e/html5/thumbnails/7.jpg)
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
![Page 8: Formal Development and Verification of Distibuted Railway Control System – Haxthausen&Peleska](https://reader036.fdocuments.in/reader036/viewer/2022082517/56813ddc550346895da7a69e/html5/thumbnails/8.jpg)
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)
![Page 9: Formal Development and Verification of Distibuted Railway Control System – Haxthausen&Peleska](https://reader036.fdocuments.in/reader036/viewer/2022082517/56813ddc550346895da7a69e/html5/thumbnails/9.jpg)
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)
![Page 10: Formal Development and Verification of Distibuted Railway Control System – Haxthausen&Peleska](https://reader036.fdocuments.in/reader036/viewer/2022082517/56813ddc550346895da7a69e/html5/thumbnails/10.jpg)
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
![Page 11: Formal Development and Verification of Distibuted Railway Control System – Haxthausen&Peleska](https://reader036.fdocuments.in/reader036/viewer/2022082517/56813ddc550346895da7a69e/html5/thumbnails/11.jpg)
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)
![Page 12: Formal Development and Verification of Distibuted Railway Control System – Haxthausen&Peleska](https://reader036.fdocuments.in/reader036/viewer/2022082517/56813ddc550346895da7a69e/html5/thumbnails/12.jpg)
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)))))
![Page 13: Formal Development and Verification of Distibuted Railway Control System – Haxthausen&Peleska](https://reader036.fdocuments.in/reader036/viewer/2022082517/56813ddc550346895da7a69e/html5/thumbnails/13.jpg)
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
![Page 14: Formal Development and Verification of Distibuted Railway Control System – Haxthausen&Peleska](https://reader036.fdocuments.in/reader036/viewer/2022082517/56813ddc550346895da7a69e/html5/thumbnails/14.jpg)
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)
![Page 15: Formal Development and Verification of Distibuted Railway Control System – Haxthausen&Peleska](https://reader036.fdocuments.in/reader036/viewer/2022082517/56813ddc550346895da7a69e/html5/thumbnails/15.jpg)
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)
![Page 16: Formal Development and Verification of Distibuted Railway Control System – Haxthausen&Peleska](https://reader036.fdocuments.in/reader036/viewer/2022082517/56813ddc550346895da7a69e/html5/thumbnails/16.jpg)
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.
![Page 17: Formal Development and Verification of Distibuted Railway Control System – Haxthausen&Peleska](https://reader036.fdocuments.in/reader036/viewer/2022082517/56813ddc550346895da7a69e/html5/thumbnails/17.jpg)
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, …))
![Page 18: Formal Development and Verification of Distibuted Railway Control System – Haxthausen&Peleska](https://reader036.fdocuments.in/reader036/viewer/2022082517/56813ddc550346895da7a69e/html5/thumbnails/18.jpg)
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.
![Page 19: Formal Development and Verification of Distibuted Railway Control System – Haxthausen&Peleska](https://reader036.fdocuments.in/reader036/viewer/2022082517/56813ddc550346895da7a69e/html5/thumbnails/19.jpg)
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