6
Modeling and Formal Specification of Automated Train Control System using Z Notation Nazir Ahmad Zafar Department of Computer and Information Sciences Pakistan Institute of Engineering and Applied Sciences Islamabad, PAKISTAN Abstract: In this paper, formal methods which are advanced software engineering techniques, in term of Z notation, are applied for the specification of critical m X components of automated train control system. At first graph gr"n theory is used for modeling of static components of the 1 system and then integrated with Z notation to describe its ge n l entire state space. At first real topology is transferred to model topology in graph theory and then switches, crossings, X2 and level crossing are formalized. At the end, these components are composed to define the entire interlocking b3 system. Formal specification of the system is described in Z notation and the model is analyzed using ZIEVES Tool. Pin* 1iyg,r h nrk intgalnrkinn c/ctim I. INTRODUCTION Railway interlocking system is a safety critical system because its incorrect functioning may have very serious consequences such as loss of human life, large scale environmental damages, or considerable economical penalties. As the use of computers in safety critical systems has been increased, concern for the safety of those systems has also grown up. As formal methods are a promising way of giving increased confidence in safety critical systems that is why the system under development is modeled using these formal approaches. Primarily, the task of railway interlocking is preventing trains from collisions and derailing while at the same time allowing normal train movements. There are two, most common, existing technologies, i.e., fixed block interlocking and moving block interlocking systems. Moving block interlocking is getting more important in railway industry due to some disadvantages in fixed block interlocking system. In fixed block interlocking system, the railway network is divided into fixed blocks which are separated by signals as shown in Fig. 1. At one time, only one train can move in a block and can enter into a block only if the next is clear. For example, in Fig. 1, the train tl can enter block b2 only when train t2 has cleared the block b3. It means, there is always a distance of more than one block between two trains. As a result, the biggest disadvantage of the system is that a long distance is required between two trains which limits the capacity of railway line and speed of a train. In reality, the safe distance between two trains is the distance needs for a train to come to a complete stop which is much less than the length of a fixed block and even shorter if a train is moving at a low speed. The idea of moving block is based on this concept, i.e., keeping only safe distance between two trains. Instead of cutting piece of railway line into fixed blocks, train's occupying area and some distance in front of it becomes the moving block in which no other train can enter as in Fig. 2. The area in front of a train is, at least, its braking distance in which no other train can enter. In this way, trains can move much closer to each other making possible to operate at higher speeds and frequencies. Previous work [8,9,10] of the author was on safety analysis of railway interlocking system using VDM-SL. In this paper, an abstract model is proposed using Z notation which is based on the model [8] described in VDM-SL. The main objectives of this paper are: (i) applying formal methods to complex systems, (ii) integration of Graph Theory with Z notation, and (iii) proposing an abstract model insuring correctness of formal specification of the system. Fig. 2. Moving block interlocking system 1-4244-0794-X/06/$20.00 ©2006 IEEE *- -- - 4 - i.- ..iii. -4 Am Aw 11 \A., rig. 1. riXceu DIOCKrlelslrysylr 438

[IEEE 2006 IEEE International Multitopic Conference - Islamabad, Pakistan (2006.12.23-2006.12.24)] 2006 IEEE International Multitopic Conference - Modeling and Formal Specification

Embed Size (px)

Citation preview

Page 1: [IEEE 2006 IEEE International Multitopic Conference - Islamabad, Pakistan (2006.12.23-2006.12.24)] 2006 IEEE International Multitopic Conference - Modeling and Formal Specification

Modeling and Formal Specification of AutomatedTrain Control System using Z Notation

Nazir Ahmad ZafarDepartment of Computer and Information Sciences

Pakistan Institute of Engineering and Applied SciencesIslamabad, PAKISTAN

Abstract: In this paper, formal methods which areadvanced software engineering techniques, in term of Znotation, are applied for the specification of critical m Xcomponents ofautomated train control system. Atfirst graph gr"n

theory is used for modeling of static components of the 1system and then integrated with Z notation to describe its

ge n

lentire state space. At first real topology is transferred tomodel topology in graph theory and then switches, crossings, X2and level crossing are formalized. At the end, thesecomponents are composed to define the entire interlocking b3system. Formal specification of the system is described in Znotation and the model is analyzed using ZIEVES Tool. Pin* 1iyg,r h nrk intgalnrkinn c/ctim

I. INTRODUCTION

Railway interlocking system is a safety critical systembecause its incorrect functioning may have very seriousconsequences such as loss of human life, large scaleenvironmental damages, or considerable economical penalties.As the use of computers in safety critical systems has beenincreased, concern for the safety of those systems has alsogrown up. As formal methods are a promising way of givingincreased confidence in safety critical systems that is why thesystem under development is modeled using these formalapproaches.

Primarily, the task of railway interlocking is preventingtrains from collisions and derailing while at the same timeallowing normal train movements. There are two, mostcommon, existing technologies, i.e., fixed block interlockingand moving block interlocking systems. Moving blockinterlocking is getting more important in railway industry dueto some disadvantages in fixed block interlocking system.

In fixed block interlocking system, the railway network isdivided into fixed blocks which are separated by signals asshown in Fig. 1. At one time, only one train can move in ablock and can enter into a block only if the next is clear. Forexample, in Fig. 1, the train tl can enter block b2 only whentrain t2 has cleared the block b3. It means, there is always adistance of more than one block between two trains. As aresult, the biggest disadvantage of the system is that a longdistance is required between two trains which limits thecapacity of railway line and speed of a train.

In reality, the safe distance between two trains is thedistance needs for a train to come to a complete stop which ismuch less than the length of a fixed block and even shorter if atrain is moving at a low speed. The idea of moving block isbased on this concept, i.e., keeping only safe distance betweentwo trains. Instead of cutting piece of railway line into fixedblocks, train's occupying area and some distance in front of itbecomes the moving block in which no other train can enter asin Fig. 2. The area in front of a train is, at least, its brakingdistance in which no other train can enter. In this way, trainscan move much closer to each other making possible tooperate at higher speeds and frequencies.

Previous work [8,9,10] of the author was on safety analysisof railway interlocking system using VDM-SL. In this paper,an abstract model is proposed using Z notation which is basedon the model [8] described in VDM-SL. The main objectivesof this paper are: (i) applying formal methods to complexsystems, (ii) integration of Graph Theory with Z notation, and(iii) proposing an abstract model insuring correctness of formalspecification of the system.

Fig. 2. Moving block interlocking system

1-4244-0794-X/06/$20.00 ©2006 IEEE

*- - - - 4 - i.- ..iii.-4Am Aw 11\A.,

rig. 1. riXceu DIOCKrlelslrysylr

438

Page 2: [IEEE 2006 IEEE International Multitopic Conference - Islamabad, Pakistan (2006.12.23-2006.12.24)] 2006 IEEE International Multitopic Conference - Modeling and Formal Specification

There exists much work on modeling of interlockingsystem. A list [3] of 299 publications, addressing variousissues on this topic, proves its importance. Most of thepublications are on traditional fixed block while this work onmoving block interlocking reflects a different approach. Thework [1] of A. Simpson is close to this in which he uses Z,CSP and FDR2 and his work is a starting point for us. Hansen[7] uses VDM to model concepts of railway topology. Safetycriteria are defined and validated through simulation but againhis work is for fixed block interlocking.

II. FORMAL METHODS

Formal methods are approaches, based on the use ofmathematical techniques and notations, for describing andanalyzing properties of software systems [6]. That is,descriptions of a system are written using notations which arebased on mathematical expressions rather than informalnotations. These mathematical notations are typically drawnfrom areas of discrete mathematics, such as logic, set theory,or graph theory. There are several ways in which formalmethods may be classified. One frequently-made distinction isbetween model oriented and property oriented methods [6].Model oriented methods are used to construct a model of asystem's behavior. State transition diagrams, for example, areused to model the behavior of a system as a set of states andtransitions between them. Property oriented methods are usedto describe software in terms of a set of properties, orconstraints, that must be satisfied. The Z notation [5] is amodel oriented approach, which is based on set theory and firstorder predicate logic. It is also used for specifying the behaviorof abstract data types and sequential programs. Z notation isused in our research for the specification of train controlsystem because it describes a state space of a system and a setof operations that may be performed on it.

III. MODEL IN GRAPH THEORY

The railway network is modeled in graph theory and formalspecification is described in Z notation.

A. Real Topology

Railway network, real topology, is composed of tracksegments as shown in Fig. 3. A track segment is connectedwith, at most, three track segments. A track segment is switchif it is connected with three track segments otherwise a lineartrack segment. Crossing is composed of two linear tracksegments having a certain relation between the track segments.

4 5 16 17 18 19 20 21

13 14 7 8 9 10 11 12

Fig. 4. Model in graph theory

B. Model Topology

A track segment in real topology is represented by a node inmodel topology as in Fig. 4. The connectivity of a tracksegment si with track segment s2 means that a train can move

from sl to s2 directly and is denoted by (sl,s2). The modeltopology is defined by a Connections relation on the tracksegments. The interpretation of the relation is that each pair oftrack segments in the relation is physically connected. TheConnections relation is modeled by a graph as in Fig. 4. Thisgraph is defined by: Connections = {(4, 5), (5, 4), (5, 6), (6, 5),..

IV. FORMAL SPECIFICATION

A. Static Model

Connections. A Track segment is specified by Track, andthe entire network in Fig. 4 is described by Connectionsrelation. Formal specification of the Connections relationis described using Z notation.

[Track], Connections == I x, y. Track x X y * (x, y) }

Switches: The switches are specified by Switches, a settype, because ordering is not required. A switch is specified bya record Switch with three fields: switch, a switchidentifier, root which represents stem and controlmapping. The control describes control of a switch, eitherin left or right.

SwitchControl::= LEFT RIGHT; Switches == P Switch

-Switchswitch: Trackroot. Connectionscontrol: Track x Track -- SwitchControl

Vs], s2. Track (s], s2) E dom control(control (si, s2) = LEFT> (3s3, s4. Track (s3, s4) E dom control

* s3= si Acontrol (s3, s4) = RIGHT))A(control (si, s2) = RIGHT> (3s3, s4. Track (s3, s4) E dom control

s3 s=s Acontrol (s3, s4) = LEFT))Vs], s2. Track (si, s2) E {root} u dom control

switch = sI A switch s2

Fig. 3. Real railway network

439

I ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~i

Page 3: [IEEE 2006 IEEE International Multitopic Conference - Islamabad, Pakistan (2006.12.23-2006.12.24)] 2006 IEEE International Multitopic Conference - Modeling and Formal Specification

Invariants over Switch:

1. If control mapping results <LEFT> acting on any branchof switch then it results <RIGHT> acting on the otherbranch and vice versa.

2. The ordered pairs defining root and both branches ofswitch are related to switch identifier where switchidentifier is the first element in the ordered pairs.

Railway Crossings. A crossing is specified by crossingwhich is constituted by cross as an identifier, crossoverlas one crossover and crossover2 as the other crossover ofthe crossing.

Crossings == P CrossingCrossing

cross: Track x Trackcrossover]: P Connectionscrossover2. P Connections

cross. 1 X cross. 2Vs3, s4. Track (s3, s4) E crossover]

* (cross.1 = s3 v cross. 1 = s4) A(cross 2 X s3 Across 2 s4)Vs5, s6. Track (s5, s6) E crossover2

* (cross 2 = s5 v cross. 2 = s6) A (cross. 1 s5 Across 1 X s6)Vs3, s4. Track (s3, s4) E crossover2

* (cross.1 = s3 v cross. 1 = s4) A(cross 2 X s3 Across 2 s4)Vs5, s6. Track (s5, s6) E crossover]

* (cross 2 = s5 v cross. 2 = s6) A (cross. 1 s5 Across 1 X s6)Vs], s2. Track * (s], s2) E crossover] u crossover2 > (s2, sl) E

crossover] u crossover2

Invariants over Railway Crossing:

1. The segments identifying crossing are different.2. The crossing identifier is related with both of the

crossovers. The segment related with any one of thecrossovers has no relation with the other crossover.

3. If an ordered pair (sl, s2) is in any crossover of acrossing then (s2, sI) is also in the same crossover.

4. A segment of crossing identifier is connected with twotrack segments. It proves that the track segments ofcrossing identifier are not at the end of the topology.

Level Crossings. Due to similar reasoning as in case ofswitches and railway crossings, level crossings are defined asset type and specified by Track.

l.evelCrossinglevelCrossing. Track

LevelCrossings == P LevelCrossing

Model Topology. Model topology is composed of fourcomponents, i.e., connections, switches, crossingsand level crossings.

taticModelconnections: P Connectionsswitches: Switchescrossings: Crossingslevelcrossings: LevelCrossings

Vsw. Switch sw E switches * {sw. root} u dom sw. control cconnectionsVswl, sw2. Switch swl E switches A sw2 E switches

* swl X sw2 > (swl switch, sw2. switch) X connectionsVswl, sw2. Switch swl E switches A sw2 E switches

* swl switch X sw2. switchVcr: Crossing cr E crossings . cr. cross X connectionsVcr: Crossing cr E crossings

* Vs], s2: Track (s], s2) E cr. crossover] u cr. crossover2 * (sl,s2) E connections

Vcr], cr2. Crossing cr] E crossings A cr2 E crossings* cr] X cr2> (cr] cross. 1, cr2. cross. 1) X connectionsA (cr] cross. 1, cr2. cross 2) X connectionsA (crl cross. 2, cr2. cross. 1) X connectionsA (cr] cross. 2, cr2. cross 2) X connections

Vcr], cr2. Crossing cr] E crossings A cr2 E crossings* cr] cr2 > {cr] cross. 1, cr] cross. 2} n{cr2. cross. 1, cr2.

cross 2} 0Vcr: Crossing; sw: Switch cr E crossings A sw E switches

* (sw. switch, cr. cross. 1) X connectionsA (sw. switch, cr. cross. 2) X connections

VIx.: LevelCrossing Ix E levelcrossings* 9s], s2: Track (s], s2) E connections

Ix. levelCrossing = sl v Ix. levelCrossing = s2Vix: LevelCrossing; sw: Switch Ix E levelcrossings A sw E switches

* Ix. levelCrossing X sw. switchVcr: Crossing; Ix. LevelCrossing cr E crossings A Ix E levelcrossings

* Ix. levelCrossing X cr. cross. 1 A Ix. levelCrossing X cr. cross 2

Invariants over Model Topology:

1. If a track segment is not a switch identifier then it isconnected with, at most, two track segments.

2. Switches are not connected in the Connectionsrelation. It was also assumed for the simplicity of themodel.

3. Different switches have different identifiers, i.e., switchidentifier is unique.

4. The identifier of a crossing is not in the Connectionsrelation.

5. Both crossovers of a crossing are in the Connectionsrelation.

6. Crossings are not connected in Connectionsrelation. It was assumed for simplicity of the model.

7. A track segment of a crossing identifier is not in anyother crossing identifier.

8. A switch identifier is not connected to a track segmentof a crossing identifier.

9. Level crossings are related with Connections.

440

Page 4: [IEEE 2006 IEEE International Multitopic Conference - Islamabad, Pakistan (2006.12.23-2006.12.24)] 2006 IEEE International Multitopic Conference - Modeling and Formal Specification

10. The track segment of a level crossing can not be aswitch identifier.

I1. The track segment of a level crossing can not be a tracksegment of a crossing identifier.

B. Dynamic Model

Tracks States. TrackStates is defined by a mappingfrom Track segment to TrainInfo where TrainInfo isa schema consisting of train identifier and train type.TrainType ::= FIXEDROUTE AUTONOMOUSTrackStates == Track-- TrainInfo, [TrainId]

TrainInfotrainld. TrainldtrainType. TrainType

Switches States. The SwitchStates is defined by amapping from Track segment to SwitchState whereSwitchState consists of four components i.e. its state,switch identifier, switch control and train occupying theswitch. Two types of train, fixed route and autonomous trains,are assumed in our model. It is supposed that system can beoperated manually in case of any failure.

witchStateswitchState. StateoccupiedBy. TrainldswControl. SwitchControloperation: Operation

State::= CLEAR OCCUPIEDOperation::= INTERLOCK MANUALSwitchStates ==Track-- SwitchState

Crossing and Level Crossing States. The state of a crossingis specified by it state and identifier of train occupying it.Level crossing state is defined by its state, train occupying thelevel crossing and barriers. Barriers have only two states,either open or closed, which are used controlling the roadtraffic.

CrossStoatecrossState. StateoccupiedBy. Trainld

CrossStates == Track x Track -- CrossStateBarriers::= CLOSED OPENLevelStates == Track -- LevelState

IevelStatelevelState. StateoccupiedBy. Trainldbarriers. Barriers

Network state space is generated by putting formalization ofstates of tracks, switches, crossings and Level crossings toobtain the dynamic model.

DynamicModeltrackStates. TrackStatesswitchStates. SwitchStatescrossStates: CrossStateslevelStates: LevelStates

Trains: Trains is a mapping from train identifier toTrain. The Train is specified by a schema having fourcomponents, i.e. moving block, destination, current speed andspeed limit of a train. Although the order is required indefining the moving block of a train for which sequences weregood choice for modeling it but, on the other hand, we do notrequire duplication of elements in the moving block and hencewe have chosen set data type to be used for specification of amoving block.

MovingBlock == P ConnectionsTrains == Trainld -- Train

TrainmovingBlock. MovingBlockdestination: TrackcurrentSpeed. NspeedLimit. N

Vs], s2. Track (si, s2) E movingBlock. destination X slcurrentSpeed < speedLimit

Invariants over Train:

1. The destination of a train may not be in the movingblock of the train. If it is then it should be at the end ofthe moving block. This is because destination of a trainmust be added in the moving block of a train at the end.

2. Current speed of train cannot exceed its speed limit.This is a kind of safety requirement.

3. The moving block of train is non-empty because a trainoccupies some track segments even it is at rest.

4. All elements in moving block are different. Thisconstraint is put because we require moving block of atrain to be a path. And, all edges in a path must beconnected and distinct as it is required for well defined-ness of a moving block.

Controls: Controls is a mapping from control identifier toControl, which is composed of four components, i.e.,section for track segments in section, states describingits state, trains moving in that section and capacity,maximum number of trains, which can move in a section.

Controls == ControlId-- Control

441

Page 5: [IEEE 2006 IEEE International Multitopic Conference - Islamabad, Pakistan (2006.12.23-2006.12.24)] 2006 IEEE International Multitopic Conference - Modeling and Formal Specification

[Controlld]Section == P TrackStates ==Track-- State

Controlsection: Sectionstates: Track -- Statetrains: Trainscapacity: N

Vs: Track s E section . s E dom statesVs: Track s E dom states * s E sectionVt: Trainld t E dom trains

*train: Train * trains t = trainA (Vs], s2. Track (si, s2) E train. movingBlock

. (si E section A s2 E section))

Invariants over Control

1. The track segments in section are in the domain ofstates mapping.

1. The track segments in the domain of states mappingare in the section.

2. Moving block of a train is contained in section.3. The number of trains moving under a control cannot be

increased by its capacity.

C. Railway Interlocking System (RIS)

Finally, we obtain a formal definition for the interlockingsystem by putting the formalization of network topology,network state, trains and controls.

IrdISSystem| StaticModelBDynamicModeltrains: Trainscontrols: Controls

Vs], s2. Track (s], s2) E connections . sl E dom trackStatesVs: Track s E dom trackStates

* 9s], s2. Track (si, s2) E connections . s = sl v s = s2Vs: Track s E { sw. Switch sw E switches * sw. switch }

* s E dom switchStatesVs: Track s E dom switchStates

* s E I sw. Switch sw E switches . sw. switch IVx: Track x Track x E xng. Crossing xng E crossings . xng.

cross }

* x E dom crossStatesVx: Track x Track x E dom crossStates

* x E { xng. Crossing xng E crossings . xng. cross }V.l Track

I E I lev: LevelCrossing lev E levelcrossings * lev.levelCrossing I

* I E dom levelStatesV/1. Track 1 dom levelStates

| eI lev. LevelCrossing lev e levelcrossings * lev.levelCrossing I

Vtid. Trainld tid E dom trains*train. Train trains tid = train

9s], s2. Track (si, s2) E connections* train. destination = sl v train. destination

Vs], s2. Track (si, s2) E connections*cid. Controlld cid E dom controls

*control. Control controls cid = control* sl E control. section A s2 E control. section

Vs], s2. Track3cid. Controlld cid E dom controls

*control. Control controls cid = control* sl E control. section A s2 E control. section

(s], s2) E connectionsVcid. Controlld cid E dom controls

*control: Control controls cid = control* dom control. trains c dom trains

Vtid. Trainld tid E dom trains*cid. Controlld cid E dom controls

*control. Control controls cid = control* dom trains c dom control. trains

s2

Invariants over RIS System

1. All segments in the network topology are in networkstate and the segments in network state are also in thetopology.

2. All the switches in the network topology are in thenetwork state and all the switches in the network stateare in the network topology.

3. The crossings in the network topology are in networkstate and all the crossings in network state are also inthe network topology.

4. The level crossings in the network topology arecontained in the network state.

5. The level crossings in the network state are contained inthe network topology.

6. The destination of a train must be in the topology.7. A track segment in the network topology must be in

some one section under a control.8. Every track segment of the section under a control must

be in the network topology.9. A train must be under some one control.10. Every train under a control must be in the entire system.

D. Path Analysis

In this section, connectivity of trains and well defined-nessof the positions of trains are presented. We have defined thattrains are connected if the track segments occupied by a traingenerate a path in the network topology. The position of a trainis well defined if the track segments occupied by a trainrespect the topology. At first, track segments occupied by atrain are searched and then following properties are analyzed.

442

Page 6: [IEEE 2006 IEEE International Multitopic Conference - Islamabad, Pakistan (2006.12.23-2006.12.24)] 2006 IEEE International Multitopic Conference - Modeling and Formal Specification

Positions ==TrackStates x (Trainld -- P Track) -- Trainld P Track

athtrackset. P Tracktrackseq. seq Trackconnections: P Connectionstried. P Track

if trackset = f then tried =telse 3s. Track s E trackset

if (s, head trackseq) E connectionsthen trackset trackset I{s} u tried

A trackseq =sk trackseqA connections = connections A tried tried

else if (s, head trackseq) E connectionsthen trackset trackset I{s} u tried

A trackseq trackseqAskA connections = connections A tried = tried

else trackset = trackset I{s} Atrackseq = trackseq A

connections = connections A

tried = tried u {s}

general principals and concepts of an interlocking system, notfor a particular system, and presented an abstract model whichcan be implemented for any interlocking system.

Our Formal specification is based on a model in graphtheory by which objective of integrating graph theory with Z isachieved. But formalizing graph theory is not easy, as therehas been little tradition of formalization in it due to theconcreteness of the graphs [2]. Finally specification isanalyzed using Z EVES Tool [4].

REFERENCES

[1] A. Simpson, "Towards the mechanical verification of moving blocksignaling systems," Technical Report CMS-TR-99-06, School ofComputing and Mathematical Sciences, Oxford Brookes University,(1999).

[2] C.T. Chou, "A formal theory of undirected graphs in Higher OrderLogic," 7th Int'l Workshop on Higher Order Logic Theorem Provingand Application, pp.144-157, (1994).

[3] D. Bjorner, "The FME rail annotated rail bibliography, Department ofInformation Technology," Technical University of Denmark, (1998).

[4]

[5]

V. CONCLUSION

Applications of formal methods in complex systems wasone of the objectives of this research because power of formalmethods cannot be realized when theses are applied to verysimple cases. Modeling railway interlocking system at abstractlevel, using Z notation, was another objective of this paper. Asmoving block interlocking is an emerging technology andthere does not exist any real formal model for it, which provesoriginality of this research.

Although this work does not represent a real world problembut is useful for researchers interested in formal methods andtheir applications because of the successful use of Z notation ina complex safety critical system. It is believed that thisresearch is useful for railway industry because it is focused on

I. Meisels, and M. Saaltink, "The Z/EVES Reference Manual," TR-97-5493-03, ORA Canada, CANADA, (1997).J. M. Spivey, "The Z notation: A Reference Manual," EnglewoodCliffs, NJ, Prentice-Hall, (1989).

[6] J.M. Wing, "A Specifier's introduction to formal methods," IEEEComputer, Vol.23, No.9, pp.8-24, (1990).

[7] K.M. Hansen, "Validation of railway interlocking model," FME'94:Industrial Benefits of Formal Methods, (1994).

[8] N.A. Zafar, and K. Araki, "Formalizing moving block railwayinterlocking system for directed network," Research Reports onInformation Science and Electrical Engineering, Kyushu University,Japan, (2003).

[9] N. A. Zafar, and K. Araki, "Formal model for moving block railwayinterlocking system using VDM-SL," International Symposium onInformation Science and Electrical Engineering, Japan, (2003).

[10] N.A. Zafar, and K. Araki, "Formalizing safety properties preventingcollisions and derailing in moving block railway interlocking systemusing VDM-SL," Asian Journal of Information Technology, Vol.3,No.5, Pakistan, (2004).

443