Stylianos Basagiannis

Transcription

1 Interlocking control by Distributed Signal Boxes Technical Report (TR) 4 Stylianos Basagiannis Supervisors: Dr Andrew Pombortsis, Dr Panagiotis Katsaros Aristotle University of Thessaloniki Department of Informatics 15/7/2006, Thessaloniki Greece 1

2 Interlocking control by Distributed Signal Boxes Stylianos Basagiannis 1 Panagiotis Katsaros 1 Andrew Pombortsis 1 1 Department of Informatics, Aristotle University of Thessaloniki, Thessaloniki, Greece {basags,katsaros,apombo}@csd.auth.gr Abstract. Life-critical control systems are required to comply with certain safety and liveness correctness properties. In most cases, such systems have an intrinsic degree of complexity and it is not easy to formally analyze them, due to the resulting large state space. Also, exhaustive simulation and testing can easily miss life-critical errors. In this work, we introduce an interlocking control approach that is based on the use of the so-called Distributed Signal Boxes (DSBs). The proposed control design is applied to a railway-interlocking problem and more precisely, to the Athens underground metro system. Signal boxes correspond to the network s interlockings and communicate only with their neighbor signal boxes. Communication takes place by the use of rendezvous communication channels. This design results in a simple interlocking control approach that compared to other centralized solutions produces a smaller and easier to analyze state space. Formal analysis and verification is performed with the SPIN model checker. 1 Introduction Interlocking control aims to prevent certain operations from occurring, unless preceded by certain events. Although interlocking control may also be used as a signaling technique in the design of complex communication networks, the term generally refers in a range of vehicular traffic control applications. Interlocking systems have been mainly developed and studied in the field of railway traffic control, where their task is to prevent trains from colliding and derailing, while at the same time allowing their movements. Whether interlocking systems are integrated in life-critical control systems or not, they are required to comply with certain safety and liveness correctness properties. This fact elevates formal modeling and model checking to the number one concern in the design and development of real-scale interlocking systems. However, in most cases, these systems have an intrinsic degree of complexity and it is not easy to fully analyze them, due to the resulting large state space. Usually, the control logic of the interlocking is not the single design concern that has to be checked with respect to the required safety and liveness properties. Complete system 2

3 designs have to include also an adequate representation of the communication between the system s components, as well as, the applied fault tolerance approach. This work introduces the control logic of a new interlocking approach that is based on the use of the so-called Distributed Signal Boxes (DSBs). The proposed interlocking control is applied to a real-scale system model and more precisely to the recently build Athens underground metro network. Signal boxes correspond to the network s stations and communicate only with their neighbors. Communication takes place by the use of rendezvous communication channels. The proposed interlocking control invests on design simplicity and avoids proprietary concept definitions and proprietary system requirements. It is not difficult to be generalized in networks with arbitrary topologies and compared to other centralized solutions produces a smaller and easier to analyze state space. Formal analysis and verification is performed with the SPIN model checker. Section 2 surveys recent research in interlocking control and attempts a comparison with the proposed solution. Section 3 introduces our interlocking approach and the use of the so-called Distributed Signal Boxes (DSBs). Section 4 refers to the formal verification of the proposed interlocking control. The paper ends with a discussion on our work s potential impact and comments interesting future research prospects. 2 Related work During our literature search, we came through a number of previous research efforts trying to verify safety critical systems concerning railway controlling systems. The majority of these works has to do with the formal verification of real-time industrial software systems using various model checkers and techniques, depending on the prerequisites of the project. Hartonas-Garmhausen, Campos, Cimatti, Clarke and Giunchiglia in [1] have described a formal verification technique being applied in medium and large-size railway stations. Although the technique is based on a previous real implementation of railway control software, the sequence of steps that is being followed is based on the verification tool Verus [2], combining symbolic model checking and quantitative timing analysis. The constructed model is being checked through his state space for meeting its defined specifications that its initial system creates, among with safety and liveness properties. The main work that we must refer to is from Cimatti, Giunchiglia, Mongardi, Romano, Torielli, Traverso in [3], in which they perform a model checking technique in the same real time system that the authors in [1] have implement to, using the SPIN model checker [5]. In this work the implemented model is designed with respect to a process based software architecture which basically implements all the logical functions requested by an external operator. The results of this verification have concluded into an erroneous behaviour of the model, obligating the model checker to provide the appropriate counter-example in order to solve the specified conflict. Gnesi, Lenzini, Latella, Abbaneo, Amendola and Marmo in [4], have constructed two models again for the same project, performing into them validation of safety and liveness properties both being specified with asser- 3

4 tions or temporal logic formulas. As we can see in [4], safety properties are being checked in respect of presence of Byzantine faults while liveness properties have been focused on a communication protocol used in the system. Finally in [8] by Winter, we observe a formal verification approach on railway interlocking systems using the CSP formal modeling language and FDR as the selected model checker. This work is also being based on the development of railway signaling project, trying to reduce possible errors of the system developed using a different formal method. While the number of works being implemented in the current research theme is quite large concerning the formal models developed in [3, 4, 5], the main characteristic of those is that they refer to a centralized structure of the model, trying to meet the safety specifications acquired from each industrial project. Safety properties being checked are not different moving through various formal analysis studies, as the models being developed meet specifications such as collision, derailing and abnormal movement of the trains. In this paper we implement a model representing a safety-critical railway controlling system with the use of a proposed technique called Distributed Signal Boxing (DSB). The basic idea of this technique is that every internal entity in the model has a corresponding signal box that communicates for it among its neighbours in a network system, exchanging signals of bytes. This technique has the advantages of reducing the safety critical system s complexity verified with the help of the SPIN model checker for safety and liveness properties. In order to introduce a new technique for applying formal methods to a safety-critical interlocking system, we have to prove the correctness and appliance of this through a case implementation of railway interlocking system. In the current work, performing the technique in a railway interlocking control system consider to be best case of testing the correctness of our methodology. Although previous works has shown to us a way of implementing representative models of similar railway control systems, complexity of those systems is often high enough contributing to an increase of the safety of the overall system [9, 10]. Having a model that reduces the state space of such a system, offering also proofs for validation of safety and liveness properties can become very useful foundation for the implementation of correct safety critical systems. While previous works [1, 3, 4, 5] have been focused on centralized railway interlocking control systems, in the current paper we look into a distributed way of communication between entities, making feasible to analyze fault tolerance and real time constaints for the implemented system According to the above we implement a PROMELA model that implements the distributed signalbox technique resulting in an error free verification result that the SPIN model checker return as output of our model. Describing the structure of this paper, in section 3 we present the Distributed Signal Box technique describing the mechanism of the algorithm referred to the advantages that this methodology offers while performed in software systems. To test and verify this technique we perform the mechanism in a safety critical railway signaling system based on real environment of the attico metro railway station. In section 4 we start to implement the model of the safety critical system of the Attico metro, in the input language PROMELA of the SPIN model checker trying to give detailed description of the steps being followed modeling the specific example and the verification results. In detail, at first we look through the structure and the imple- 4

5 mentation process of the model, while we verify its specifications using the formal tool. Main purpose of it to verify that the technique performed in a safety critical system obeys the safety and liveness properties that the specified system ought to validate. Finally in section 5 the conclusion and further future extensions of the specific survey are proposed summarizing also the outcomes of the current paper. 3 Distributed Signal Boxes Main target of this paper is the presentation of a new way of modeling a checking mechanism that will allow the construction of safe and easy to analyze safety critical control systems. Its advantage while functioning is based on the distributed architecture which is characterized as method of Distributed Signal Boxes (DSBs). DSBs are capable of functioning through direct communication points as seen in Figure 1a and 1b. Figure 1a: 1 st Communication Sample During the design phase of DSBs, the connection mode as seen in Figure 1 was taken into consideration trying to verify an entity that should move through nodes connected in a simple 1-1 topology, using a synchronized distributed validation methodology. Figure 1b: 2 nd Communication sample Later on, (as in a real time railway control system), topology as seen in Figure 1b, was introduced in a 1-2 topology, where from one node two choices of interaction are available. Combining these two types of connection, communication should involve more than the required one indicator (message) which will play the role of the control flag of the network s traffic. It must be added that as more indicators are being added into the control mechanism, the more complex and local-centralized the mechanism will become, driving the study beyond its initial purposes. Due to that we implement the DSBs, using two message indicators (referred as signals) which will control entity movement (allocation) in a network (such as a railway control system), exchanging their places of indication, as the entity acquires a resource. 5

6 Implementing the mechanism at first for simple direct communication points, the concept of labeling any insertion into the communication panel was the first to be constructed, letting the network know about the presence of an entity inside it. Due to its flexibility embedded, it is applicable in every kind of communication network, tree based or ring (according to systems combined from topologies of Figure 1a and 1b), and every entity has its own signal box communicating with it with synchronized channels exchanging a message. Entities do not communicate directly through each other but through their signal boxes. Each signal box communicates with its neighbors with synchronized communication channels, exchanging a message. Figure 1: Basic diagrammatic application of DSB The topology of the network and the correct application of the method depend on the connection of the entities as long as those entities have been properly declared among their neighbors. In the whole state space of the application of the mechanism there are two types of messages being exchanged, both characterized as indicators which controls the network resources and distributes them among the entities that requests them. The whole mechanism consists of three procedures: one for the entities called Station i, one for its signal box to the corresponding entity called Signalbox i and one initialize procedure that introduce the request of an entity to the network called Initialize(). Each entity must have its defined station and signal box while in every request the network suffers, the initialize procedure must be executed (considered as the entrance before a request enters the network). 6

7 Figure 2: DSB mechanism function In Figure 2, we observe the communication of the interlockings of the network, using signal exchanging with the help of synchronization channels, the PROMELA language offers. After passing through the Initiate() flag function, the entity (train) enters a stop-wait state which is controlled through the distributed signal boxes that are scattered in the network. The network realizes the entrance of the entity by the moment the entity passes the Initiate() function, as it will wait for a specific indicate msg2 to arrive. This indicator will be produced from the corresponding DSB execution, setting the mechanism in a checking state for releasing the entity (train) to the next resource (considered to be the next non empty tunnel, that the train wants to enter). The whole function scheme of DSB is described using PROMELA in figure 2, specifically created for the railway control system that it is going to be applied in. In order to validate the proposed mechanism we decided to perform the method to a real environment of a safety critical control system choosing the railway control system of the Attico metro (metro railway system of Athens). Considering the railway 7

8 system as a communicating network, marking entities as stations, creating their signal boxes and moving trains as requests for entering a tunnel (requesting from the station the tunnel resource) we attempt to perform the mechanism in PROMELA language; the input language for the SPIN model checker. Through it we can simulate and observe carefully the results of the safety critical system and moreover of the mechanism behavior on it, while the verification process will prove to us that the safety critical system will succeed its safety and liveness properties. 4 Model building and verification For the best testing of the mechanism through its application to a safety critical control system, we should validate the specifications that the real time safety control signaling system must meet. Safety and liveness properties should be verified in order for the proper function of system and the network in a broader view. We have chosen the SPIN model checker [ ] and PROMELA language as the tool for operating this study. Being more specific about the SPIN model checker and the reason why we have chosen it for formal analysis of the selected railway control system, the basic arguments are listed below, according to [ ]. These are: SPIN is created for efficient software verification, not hardware verification. That reason makes the tool an exceptional choice for simulating, verifying and finding errors among several software systems such as operating systems, data communication protocols switching systems, concurrent algorithms and railway signalling protocols. According to this, the SPIN model checker is consider to be the best choice while performing formal methods in a signalling railway control system such as AM. SPIN supports a high level language as input in order to specify systems descriptions. With the help of PROMELA, SPIN produces efficient results when checking the logical consistency of a specification. After applying SPIN on a pre-modelled safety critical systems, SPIN can provide us with reports on deadlocks, unspecified receptions, flag incompleteness, race conditions and unwanted assumptions about the relative speeds processes. The tool also can be used as full LTL (Linear Temporal Logic) model checking system supporting all the correctness requirements which are expressed in linear time temporal logic formulae, having the opportunity to check the model for safety and liveness properties. Finally, SPIN is a tool that supports both rendezvous and buffered message passing among processes that are synchronised, making the choice of applying SPIN to the specified signalling control system, ideal as far as verifying correctness of error free railway condition communication properties. This contributes to the argument for SPIN being the perfect solution in performing the formal method to the system we have developed according to our mechanism, for the desired system s properties. 8

9 We are going to separate the model construction into two subsections; first the implementation phase in which we will produce the model structure compared to the real time railway station of the AM and coding the whole network scheme among with our mechanism in PROMELA. After the completion of this phase we will simulate and verify our model with SPIN model checker, observing and explaining the returned results. a. Model Structure and Implementation Looking at the AM system, we observe that there are three railway lines with a number of stations connected by tunnels. Figure 3: Attico metro underground railway station architecture There are four points in which lines intersect with each other through their common stations. In this certain points the railway lines are in different level of operation without letting the train movement of different lines to interfere with them, as shown in Figure3. For this reason we consider each line independent from each other, leading us to the modeling of the bidirectional Line1. Trying to figure out a diagrammatic way of performing the DSBs method to the selected problem, we take into consideration the real connectivity of the stations between them, allowing us to define the topology of the network, as shown in the Figure 4. 9

10 Figure 4: DSB mechanism application 1 As we can see from Figure 4, each station (entity) is connecting through its identical through bidirectional tunnels allowing trains (requests) to move along them. Each station has its own signal box communicating with their neighbors through communication channels that we have created for checking the availability of the tunnel (resource), when a train (request) reaches the corresponding station. All these considerations are being taken according to the basic principles that we have defined in section 3, as we want the DSBs method principle steps to be followed. The structure of the model is based on the signal boxes their communication between them (neighbours) and between their stations, through channels with rendezvous communication. So except from the channels that first exist in our model to represent the tunnels of the AM control system, channels are being defined to represent not only a tunnel that will connect the station with its signal box, but also the signal-channels that would allow communication between the signal boxes (only with 10

11 the back and the front signal box). These additional tunnels of communication must be synchronized during their exchange of signals. For that reason these channels will have zero size in order not to store any signal. Continuing with the implementation of each procedure-proctype that is used in our model, it should be stated that signals are represented with messages (msg1 and msg2), corresponding to the signals that are being exchanged with the stations and the signal boxes and between the signal boxes. Figure 5: PROMELA model definition of signals, tunnels and signalboxes At first the station proctype is being defined having three channel parameters: in_track channel where it refers to the tunnel that is entrance for the corresponding station, out_track where it refers to the tunnel after the station and the track_signal which is going to deliver signals from the signal box. As a train reaches a station, the station sends message to its signal box and a second message (different from the first one) must be received in order the train to be released to the tunnel in front of the station. 11

12 Figure 6: PROMELA DSB implementation The setup proctype has also three parameters: a channel track which is actually the tunnel where at first the train is going to enter, a channel track_signal which is going to check whether the tunnel is empty or not, and of course the byte train (1 or 2).The signalbox proctype has also three channel parameters: the previous signal-channel (prev) of the signal box, the next signal-channel of the signal box, and the track_signal channel. Figure 7: Assertion definition ASR1 12

13 At this point we are going to have two different options; first a message (msg2) is being sent to the signal-next channel of the corresponding signal box where this channel is going now to wait for a message (msg1) from its station. In the second option, a message (msg1) must be received from the signal box, informing the previous channel with a message that the line is clear (and the train has gone). Finally, proctype monitor and the init process are defined. In the proctype monitor the assertion that must be always checked from the model is written, as shown in Figure 7 while in the init process all the proctypes are being started through the method run. Figure 8: Initiating the PROMELA model Figure 8 show to us a sample declaration of the initiation of the model executing simply the initiate, the station and the signal box procedure, necessary for the implementation of DSBs. In this point we have to take into consideration the basic properties that our model has to fulfill, in order for our method to succeed solving the safety conflicts that might arise in this safety critical system. 13

14 Figure 9: Detailed DSB instance operation for the Attico metro underground railway network As shown in Figure 9 in which the mechanism is examined deeply in comparison with the railway architecture, we see that the assertion procedure monitor() always active in our model, must not be violated at any time of the execution of our model, validating the safety properties of our safety critical system. b. Model Verification Having defined the PROMELA model of the selected safety critical system, we have to continue to the verification of the model which contributes to the proof of correctness of the DSB methodology. In detail, we are going to validate our model for safety and liveness properties, through the output that the SPIN model checker returns back. We use ASR1 (Assertion 1) and the monitor() proctype for assuring safety properties of the railway system though SPIN s verification output, while liveness property are verified through the examination of SPIN s simulation output and its feature of the linear time temporary manager (LTL), defining corresponding formulas. The safety property that is being verified is described below as ASR1: ASR1: A tunnel can only be occupied by one train at a time ASR1 is the modeled precisely as the Monitor() proctype that is executed in the background of our model, and through the entire execution time of it. Its basic operation would be that at no time must every tunnel of our network must be full. Meaning that at no time must the predefined tunnel with two bytes capacity must indeed have two entities. Combining all the non empty tunnels of the network, we construct the successful assertion of our model, waiting for the SPIN model checker to inform us 14

15 whether or not the assertion is violated, concluding consequently if the DSB mechanism is actually working. In order to ensure our model for the specific safety property, we have to include all the possible situations that the network can hold. For example the disaster situation for the specific safety critical system such as a railway station would be a collision between two trains in a certain tunnel of the network. We have to consider that each tunnel should allow two trains (entities) by definition of the type of it. This is implemented by defining each tunnel as channels that can hold two at the most entities (which is the disaster situation), one train (which is the situation that a train is moving through the tunnel), and none (which indicates that the channel is empty). We can observe this through Figure 5, where a simple definition of the network s channel is chan Tunnelij = [2] of {byte} The output that is been generated from SPIN is the following: Figure 10: SPIN verification output As we can see from the verification output, the SPIN model checker finds no error in its trying to find whether or not the given safety property (assertion) is never violated. That is been proved where errors are zero (0) meaning that the verification is valid. We can also see that in the simulation window or the MSC where no tunnel is been occupied by two trains at a time. Also we observe that the states generated is considered quite small for a complete railway interlocking control system (as in the current PROMELA model 48 communicating through Signal boxes stations have been created). Moving on to the verification procedure, we have to observe whether or not the model meets its liveness properties. As liveness property (LVN1) in the specific ap- 15

16 plication example, is thought to be the specification that every train eventually (if this is inserted into the network) will pass through all the lines (tunnels) of it. Considering the architecture of the Attico metro which is a cyclic graph, each train that we insert on it, will loop infinitely until we choose to stop the execution of the model. According to that we define LVN1 as: LVN1: Every train will eventually access every line of the network The proof of the following sentence consider to be given a) through the simulation output of the model, as we can see that every entity is consequently take access to all the predefined tunnels of the network b) from the Message Sequence Chart that the SPIN model checker creates, which show to us even the correct communication of DSB, allowing safely the trains to proceed and c) using Liner Time Logic formulae which according to the model checker, LTL formulae is translated to a negated claim which is validated either with the desired system-user behavior. In the following lines we are going to use the LTL verification procedure for verifuing both the main assertion of the problem ASR1 but also the liveness property LVN1. In order to verify our model using temporal properties, we have to verify our system using the LTL property manager from the XSPIN (the graphical user interface of the SPIN model checker). For ASR1, we have to write the above LTL formula for desired behaviour: []! p where p is defined in the symbol definitions as full(tunnelswa) full(tunnelab) full(tunnelbc) full(tunnelcd) full(tunnelde) full(tunnelef) full(tunnelfg) full(tunnelgh) full(tunnelhi) full(tunnelij) full(tunneljk) full(tunnelkl) full(tunnellm) full(tunnelmn) full(tunnelno) full(tunnelop) full(tunnelpq) full(tunnelqr) full(tunnelrs) full(tunnelst) full(tunneltu) full(tunneluv) full(tunnelvw) full(tunnelwx) full(tunnelxsw1) full(tunnelsw1x) full(tunnelxw) full(tunnelwv) full(tunnelvu) full(tunnelut) full(tunnelts) full(tunnelsr) full(tunnelrq) full(tunnelqp) full(tunnelpo) full(tunnelon) full(tunnelnm) full(tunnelml) full(tunnellk) full(tunnelkj) full(tunnelji) full(tunnelih) full(tunnelhg) full(tunnelgf) full(tunnelfe) full(tunneled) full(tunneldc) full(tunnelcb) full(tunnelba) full(tunnelasw) Trying to run the LTL property manager to verify our model where property should holds for error behaviour (no executions) the ltl formula should be: 16

17 p where p is defined the same as the above. The basic idea of the first LTL verification is that consider our predefined model, the desired behavior of it is that at no time any stated line of the control system would be full (considering that a line holds two mtypes, meaning at most two trains at a disaster situation). If the property holds, than the model would be free of collision problems, validating the main assertion (ASR1) of our problem. Verifying our model for the liveness property LVN1 we have to define the k LTL formula as: []!k Where k is defined in the symbol definitions as #define k (nempty(tunnelswa) && nempty(tunnelab) && nempty(tunnelbc) && nempty(tunnelcd) && nempty(tunnelde) && nempty(tunnelef) && nempty(tunnelfg) && nempty(tunnelgh) && nempty(tunnelhi) && nempty(tunnelij) && nempty(tunneljk) && nempty(tunnelkl) && nempty(tunnellm) && nempty(tunnelmn) && nempty(tunnelno) && nempty(tunnelop) && nempty(tunnelpq) && nempty(tunnelqr) && nempty(tunnelrs) && nempty(tunnelst) && nempty(tunneltu) && nempty(tunneluv) && nempty(tunnelvw) && nempty(tunnelwx) && nempty(tunnelxsw1) && nempty(tunnelsw1x) && nempty(tunnelxw) && nempty(tunnelwv) && nempty(tunnelvu) && nempty(tunnelut) && nempty(tunnelts) && nempty(tunnelsr) && nempty(tunnelrq) && nempty(tunnelqp) && nempty(tunnelpo) && nempty(tunnelon) && nempty(tunnelnm) && nempty(tunnelml) && nempty(tunnellk) && nempty(tunnelkj) && nempty(tunnelji) && nempty(tunnelih) && nempty(tunnelhg) && nempty(tunnelgf) && nempty(tunnelfe) && nempty(tunneled) && nempty(tunneldc) && nempty(tunnelcb) && nempty(tunnelba) && nempty(tunnelasw)) The basic idea of this second LTL verification is to try and ensure that every line of the railway network is going to be accessed if there is an entity (train) inserted to the network. To prove that we slightly change our model introducing train number one. We want, using the LTL verification methodology to validate the LVN1 for the train that we have into our network. Defining k as above, we reassure at no time that all the tunnels of the network would be empty, meaning that a the entity will eventually pass sequentially through the network. In Table 1 we report some significant results according to the properties verified. State vector Depth search SPIN s output 17

18 AM model Success ASR Success LVN Success Table 1: SPIN verification outputs 5 Conclusion In this paper we attempt the verification of a safety critical system using the newly created methodology of Distributed Signal Boxes. Based on a communication logic of each resource of the network is communicate only with its neighbors through the temporary created signal boxes, exchanging signal, while every entity requiring a resource of the network will call itself to it, moving the mechanism to allocate (depending the specifications) the resource that the entity requests. We tried to validate the mechanism by its application to a safety critical system such as the railway interlocking control system of the underground metro of Athens. According to mostly previous works, but also to the strictly successful verification that such a model would require to have, we construct a PROMELA model in precision with the real time operation scheme the specific railway station is based on. After modeling the station s topology and define their communication lines (tunnels), we insert to the model our mechanism, considering entities of the railway network as representatives of the entities that DSB requires. SPIN s output produced back to us, verifies correctly the model and consequently proving that the proposed DSB is successfully applicable. We have to add that in the biggest part of the study, DSB is considered to be applicable in every network topology, allowing secure resource allocation of it among entities. Moreover its application will reduce complexity of the system while control will pass from the centralized to the distributed more secure method (allowing checking the defined model for fault tolerance easily which concludes in parallel in finding possible errors). Tested through cyclic graphs using the specific safety control system and extended to tree non-intersected lines of railway control systems, DSB application to more complex network is required as future work in this computer system verification section. Accomplishing that, we expect by extending DSB to allow its application into communication protocols, network resource allocation algorithms and other synchronization problems meeting often today. References [1] V.H.Garmhausen, S.Campos, A.Cimatti, E.Clarke, F.Giunchiglia. Verification of a Safety-Critical Railway Interlocking System with Real time Constraints. IEEE Computer Society, p ,

19 [2] S.Campos, E.Clarke, M.Minea. The Verus tool: a quantitative approach to the formal verification of real-time systems. In Conference on Computer Aided Verification, [3] A.Cimatti, F.Giuchiglia, G.Mongardi, D.Romano, F.Torielli and P.Traverso. Model Checking Safety Critical Software with SPIN: an Application to a Railway Interlocking System. In Proceedings of 3 rd SPIN workshop, [4] S.Gnesi, D.Latella, G.Lenzini, C.Abbaneo, A.Amendola and P.Marmo. A Formal Specification and Validation of a Critical System in Presence of Byzantine Errors. In Proceedings of TACAS 2000, Lecture Notes in Computer Science, p , [5] A.Cimatti, F.Giunchiglia, G.Mongardi, D.Romano, F.Torielli and P.Traverso. Formal Verification of a Railway Interlocking System using Model Checking. Formal Aspect of Computing, v.10 (4), p , [6] G.J.Holzmann. The Model Checker SPIN. IEEE Transaction on Software Engineering, v.5 (23), p , [7] G.J.Holzmann. Design and Validation of Computer Protocols. PrentiseHall, [8] K.Winter. Model Checking for Abstract State Machines. Journal of Universal Computer Science, v.3 (5) p , 1997 [9] T. Hlavaty, L. Preucil, and P. Stepan. Formal methods in development and testing of railway interlocking systems. In International Conference Railway Traction Systems, p , Italy,