FORMAL VERIFICATION OF ERTMS EURORADIO SAFETY CRITICAL PROTOCOL

Esposito Rosaria, Lazzaro Armando, Marmo Pietro, Sanseviero Angela

Ansaldo Segnalamento Ferroviario S.p.A. Address: Via Argine, 425 80147 Napoli ITALY Phone: +39.081.243.2981 Fax: +39.081.243.7089 E-mail: {esposito.rosaria, lazzaro.armando, marmo.pietro, sanseviero.angela}@asf.ansaldo.it

Abstract: This paper shows how an extension of UML methodology has been applied to model and verify the ERTMS EURORADIO protocol against the CENELEC requirements for protocol safety (CENELEC 50159) and assessment methodology (CENELEC 50128). The use of UML allows a rigorous formalization of specifications keeping all the benefits of a language that is not complex and widely supported. Even if the specifications are stable and widely accepted this formal verification activity has discovered some inconsistencies that, however, affect the availability and not the safety of the system. Keywords: CENELEC requirements, formal verification, statecharts, sequence diagrams.

1. INTRODUCTION Modern digital systems are characterized by a high rate of growth in functionalities and complexity; unfortunately, this growth has not been followed by equal improvement in technologies and methods to develop and assess these systems. This is particularly true for realtime, safety critical systems, for which logical and temporal correctness should be validated against strict safety requirements. International committees, like CENELEC, have faced these difficulties producing standards that define appropriate life cycle for dependable systems and techniques to be used in all the phases of development and V&V process. In particular CENELEC standards stress the relevance of the validation activities performed in the early phases of the development recommending the use of formal methods in the specification formalization. These methods are based on rigorous mathematical and logical rules allowing a high degree of precision and completeness in the specification, efficiency and automatization in the assessment. Despite the advantages and the strong scientific support, formal methods are not widely used in the industry for their inherent complexity

and the difficulties to apply them to large-scale problems. This paper shows how an extension of UML methodology has been applied to model and verify the ERTMS EURORADIO protocol against the CENELEC requirements for protocol safety (CENELEC 50159) and assessment methodology (CENELEC 50128). The ERTMS consortium has defined a set of specifications for a high-speed train line in which traditional signaling has been replaced by radio signaling via GSM-R (Global System MobileRailway): trains separation is managed by a RBC (Radio Block Center) that transmits, via radio, authorizations (regarding speed, conditions of railway line, etc.) to trains. Since GSM itself is not able to guarantee acceptable levels of safety for the transmission of critical data, a safety protocol, EURORADIO, has been defined in ERTMS specifications. EURORADIO specifications have been formalized by Ansaldo Segnalamento Ferroviario using UML Statecharts (derived by Harel Statecharts). The use of UML (a standard language for system modeling) allows a rigorous formalization of specifications keeping all the benefits of a language that is not complex and widely supported.

Even if the specifications are stable and widely accepted this formal verification activity has discovered some inconsistencies that, however, affect the availability and not the safety of the system. 1.1 Deeper introduction Modern digital systems are characterized by a high rate of growth in functionalities and complexity; unfortunately, this growth has not been followed by equal improvement in technologies and methods to develop and assess these systems. This is particularly true for realtime, safety critical systems, for which logical and temporal correctness should be validated against strict safety requirements. A typical field of application of dependable real-time systems is represented by modern control systems for railway and metro lines, based on microprocessor logic. In previous generations, based on relay logic (characterized by lower complexity and univocally defined fault modes), it was relatively easy to guarantee correctness and accomplishment of safe state even in case of failure (fail-safe behavior). Microprocessor system, instead, are characterized by very complex failure modes thus the verification of correctness is critical both in terms of effort (from 30 to 60 percent of development time) and efficiency. The first stage of the project, such as definition of specifications, are particularly critical: an error made in this phase, in fact, needs a big effort to be corrected (when possible) in terms of modifications at software and hardware level. In recent years many methodologies and techniques have been investigated to support the development of railway dependable systems at every step, from the definition of specifications to testing of the product. Starting from these analyses international committees, like CENELEC, have produced standards that define appropriate life cycle for dependable systems and techniques to be used. CENELEC 50126 standard, in fact, requires a process of verification and validation through the whole life cycle of the systems in which evidences of the respect of requirements should be provided with different level of details, depending on the safety criticality of the system. In CENELEC 50128 it is recommended (Annex A table-2) that systems specifications should be

appropriately formalized to guarantee correctness and completeness. In Ansaldo Segnalamento Ferroviario (ASF) experience on application of formal methods on system specification has been gathered through several European research projects (USEGAT, GUARDS, FAST). While a full approach to the formalization of specification has fallen short due to high level of expertise required and lack of stable tools, several successful applications have been experienced for the demonstration of safety requirements of critical part of the system. An example of these applications is the formal verification of the voting mechanism for the Roma Termini central station interlocking system that was modeled using Promela language and verified with the SPIN tool (Abbaneo et al, 2000). The present paper shows the results of a further step forward the full formalization of the specifications. The methodology is based on finite-state machines formalism inserted in an Object Oriented framework to verify EURORADIO protocol specifications against CENELEC safety requirements. The EURORADIO protocol is used for the communication between level 2 ERMTS (European Railway Traffic Management System) devices. The ERTMS consortium has defined a set of specifications for a high-speed train line in which traditional signaling has been replaced by radio signaling via GSM-R (Global System MobileRailway): train separation is managed by a RBC (Radio Block Center) that transmits, via radio, authorizations (regarding speed, conditions of railway line, etc.) to trains. Since GSM itself is not able to guarantee acceptable levels of safety for the transmission of critical data, a safety protocol, EURORADIO, has been defined in ERTMS specifications. Because of the critical role played by the EURORADIO protocol it is necessary to perform an accurate analysis of the specifications. In particular, the CENELEC 50159-2 standard defines a set of properties a safety protocol must satisfy. The approach to verify EURORADIO specifications is based on the formalization through finite-state machines to obtain an executable model. This model was used to: Verify correctness of specifications against deadlocks, parts of model never executed, reception of unexpected messages, generation of

messages without receiver, control of types of data exchanged; Validate expected behavior of the protocol against CENELEC requirements; Generate test cases and evaluate the achieved coverage level of model components. Verification and validation activities on the protocol has therefore been divided into the following steps: a) Translation of specifications from textual to formal; b) Execution of specifications in different scenarios and data collection; c) Analysis of output and comparison with expected results. The translation of the specifications has been carried out using a variant of modeling language UML (OMG). UML, by now become the standard de facto of software modeling, is a semi-formal language, therefore unfit to a rigorous formalization of the specifications. At the same time, the UML standard provides some extensions in order to adapt it to different environments and problems. In this work the Real Time (Selic B. et al) extension has been used; it allows obtaining executable specifications and clear separation between interface and implementation of module components. The formalization activity, in particular, is based on UML statecharts (derived from Harel statecharts) allowing rigorous formalization of specifications with a language that is widely supported and not particularly complex. The paper is organized as follows: Section 2 provides a brief description of CENELEC 50159-2 standard and its safety requirements; Section 3 summarizes EURORADIO protocol specifications and their use in ERTMS systems. Section 4 details the methodology for the specification modeling while Section 5 describes model and verification activities. Section 6 summaries results and future applications. 2. CENELEC 50159-2: SAFETY RELATED COMMUNICATION IN OPEN TRANSMISSION SYSTEMS CENELEC 50159-2 standard deals with characteristics of communication under safe conditions. In particular, the first part deals with failure modes of communication in closed transmission systems while second part concerns

open transmission systems, affected by data corruption as well as unauthorized access. The normative defines an open transmission system as a transmission system with an unknown number of participants, having unknown, variable and non trusted properties, used for unknown telecommunication services and for which the risk of unauthorized access shall be assessed. The normative identifies the possible threats affecting an open transmission system and the corresponding techniques of defense that should be implemented; possible threats are: Repetition, when a message is received more than once; Deletion, when a message is removed from a message stream; Insertion, when a new message is implanted in the message stream; Resequencing, when messages are received in an unexpected sequence; Corruption, when the information contained in a message is changed, casually or not; Delay, when messages are received at a time later than intended; Masquerade, when a non-authentic message is designed thus to appear to be authentic (an authentic message means a valid message in which the information is certificated as originated from an authenticated data source). In order to reduce the risk related to these threats, this normative prescribes to insert a Safety Functional Module between transmission system and application. This Module should provide the following safe services: - Message authenticity: a message in which the information is valid and known to have been originated from a stated source; - Message integrity: a message in which the information is complete and not altered; - Message timeliness: a message in which the information is available at the right time according to requirements; - Message sequence: messages are received from the application in the same order in which they are transmitted. CENELEC 50159-2 normative also provides indications of possible defense techniques realizing these safe services (Tab. 1):

Sequence Number Time Stamp Time-out Feedback Messages Source and Destination Identifier Message Identification Procedure

Safety Code Cryptographic Techniques

Every message has a data field containing a number changing in a predefined way from message to message A temporal information (time stamp) is added at every message A timeout timer is used to control the timeliness of message Its the confirmation of correct reception of the message sent by source An identifier is assigned to each entity. This identifier can be a name, number or arbitrary bit pattern. Messages may contain a unique source identifier, or a unique destination identifier, or both. Open transmission systems may receive messages from other (unknown) users confusing them with information originating from an intended source. The message identification procedure allows for the identification of received message Can detect the eventual corruption of data. Redundant data based on cryptographic functions are included in messages to allow for detection of data corruptions and unauthorized access.

3. ERMTS\ETCS PROTOCOL

EURORADIO

Levels 2 and 3 of ERTMS European specifications prescribe the replacement of traditional lateral signaling with radio transmission via GSM-R networks; because GSM-R is an open network, with poor characteristics of security and safety, an appropriate protocol has been added to the communication stack Train-Track side. This protocol ensures that data exchanged between train and RBC, critical for the correct train separation, are safe following CENELEC 50159-2. Non-ambiguity and correctness of the protocol specifications are, therefore, fundamental to guarantee appropriate levels of safety for trains circulation.
R T #1 EE

Tab. 1: Defense Technique Every defense technique is able to provide protection against one or more possible threats to the safety transmission listed upon as described in Tab. 2:

RBC M C BC S RB RC

BC S BC S

MC S

Source and Destination Identifier

NS S

Message Identification Proc

BS S

R T #2 EE

Cryptographic Techniques

Fig. 1: Radio signaling system Figure 1 shows the general architecture of the radio signaling system. It is possible to distinguish: - RBC, managing train separation - GSM-R System (MSC, Mobile Switching Center; BSC, Base Station Center) - Train The protocol is positioned between Transport level and Application level of the ISO/OSI stack and its aim is to protect data from modifications during transmission (corruption and masquerade), either intentionally made by hackers, or accidentally caused by errors. The protocol doesnt cover threats related to wrong order of arrival (repetition, deletion, insertion, resequencing) and delay of the messages. Higher levels of the protocol stack should provide protection against them, checking the order of arrival (using sequence numbers) and the temporal validity of data (through elaboration numbers or timestamps). The protocol guarantees

Feed-back Message

Sequence Number

Time Stamp

REPETITION DELETION INSERTION RESEQUENCING CORRUPTION DELAY MASQUERADE

X X X X

X X X X

X X X

Safety Code

Time Out

X Tab.2: Threats/Defenses Matrix

recognition of senders identity adding a signature, which is function of the transmitted data and a cryptographic key, known only by sender and receiver. Consequently the protocol requires both sender and receiver share a secret key to sign and verify exchanged data. Since the security of a key depends on its length and number of uses, a new key is generated at the beginning of every new session. The protocol prescribes an initial phase for the set up of the connection, during which two SLE devices (Safety Layer EURORADIO users) recognize themselves and generate the key. The new key, called session key, is obtained from two random numbers (Ra and Rb) and from a starting key (Kab), shared by the devices and used only during the set up phase. The recognition of the two devices is made following a Challenge/Response protocol, which is composed of several phases (Fig. 2). Upon receiving a connection setup request from the protocol services user (SaS), the SLE A initializes the timer to verify maximum connection establishment delay and sends first authentication message AU1 (AU1SaPDU) to
Safety layer Safety layer

SLE B. AU1 contains SLE A id and the first of random numbers used for session key generation. SLE B replies sending AU2 to SLE A; AU2 contains the SLE A id, a second random number and the MAC (Message Authentication Code) generated with the new session key. When the SLE A receives AU2, it can check the SLE B identity with AU2-MAC, but SLE B cant be sure of SLA A identity, so a third message (AU3) is sent by SLE A to SLE B. If the AU3MAC is correct the SLE informs the SaS user of pending request and waits for SaS user response. In case of positive response the last connection message (AR) is sent to SLE A. The scenario for data transmission is much simpler (Fig. 3): after the reception of transmission request coming from its SaS user, the SLE creates the data PDU, adding a header and the MAC to the data.
Safety layer
Sa.DAT A.req TDATA.r eq

Safety layer

DT SaPDU

TDATA.i nd

SaDATA.in d

Sa-CONN.request T-CONN.req
Set Testab

AU1SaPDU T-CONN.ind

T-CONN.resp AU2 SaPDU T-CONN.conf

Fig. 3 Data Transfer ERMTS specifications define protocol behavior mainly by means of a state machine; the definition is nevertheless incomplete, since only a subset of possible transitions are defined, while the management of error is described in separate sections.
Sa-CONN.ind Sa-CONN.resp T-DATA.req

T-DATA.request AU3 SaPDU T-DATA.ind

4. METHODOLOGY The formal activity described in this paper aims to complement traditional verification, based on manual and semiautomatic techniques (visual inspection and extensive testing). It uses formal methods, based on rigorous mathematical and logical techniques, as they enable a high degree of efficiency, completeness and automatization. One common approach is to represent the system as a finite-state machine (FSM): requirements

AR SaPDU T-DATA.ind Sa-CONN.conf

Stop T estab

Logical data flow (Safety PDU) Physical data flow (service primitive)

Fig. 2 : Message sequence of connection set up

are described as relations between the states, the input and the output parameters. The methodology developed by ASF is based on modeling of specification using UML statecharts. UML statecharts are derived from Harel statecharts (Harel 1987) that overcome the limitations of traditional FSMs, while retaining the benefits of finite state modeling. In particular, statecharts include nested hierarchical states and concurrency and extend the notion of actions to allow for a reduction of the state space explosion, typical of real systems modeled with traditional FSMs. Because statecharts require a precise specification of behavior, it is possible to execute the model before the design of actual system is completed. This capability allows detecting errors in complex specifications where conflicting or incomplete requirements usually occur. In the proposed methodology the execution of the statecharts is used to show that the specification is correct and to generate a set of testing vectors, to be applied to the real system, to ensure it meets initial requirements. The following section gives a brief description of main components of system model. The first step in the modeling activity is the definition of use cases, and relative scenarios, of the system. A scenario is a sequence describing interactions between system and its user (either another system or a person); a use case is a set of scenarios linked by a common objective. Typically, for each use case it is possible to specify a main scenario, in which everything works correctly, and a series of extensions for possible failures. The traditional way to represent use cases is based on natural language description as a sequence of steps; the alternative way adopts sequence diagrams (also named MSC - Message Sequence Chart) representing interactions between objects through the temporal sequence of exchanged messages. However, they are suitable to describe only allowed sequences of actions; a better description of all the interactions can be achieved through state machines. Besides the preliminary analysis phase, sequence diagrams are very useful in testing phase; as shown later, the proposed methodology makes wide use of them to verify specifications and validate the model. In our approach a class diagram describes the type of objects that compose the system and the main static relations between them:

Associations with different degrees of connection or aggregations between objects (e.g. a library is composed by books) Subtypes, an object is a particular type of another one (e.g. a motorcycle is a particular type of vehicle)
<<Caps e>> ul Sl e + / PoraUp~ t + / PoraDown t # / Ti mer # /l og # / Eror r <<Capsul e>> Tr por ans t + / Pora_SLE~ t + / Pora_Peer t ~

<<Caps e>> ul SaS_User + / Pora_SLE t

+ / Pora_SLE~ t + / PoraDown t <<Pr ocol ot >> SaSAP SaDi _i ( sc nd ) SaCo nn_i ( nd ) SaCo nn_conf( ) SaRe t nd ( por_i ) SaDa a_i ( t nd ) SaCo nn_r ( eq ) SaCo nn_r p ( es ) SaDi _r ( sc eq ) SaDa a_r ( t eq ) + / PoraUp~ t <<Pr ocol ot >> sl r e_taspor t Tconn_conf( ) Tconn_i ( nd ) Tdat nd ( a_i ) Tdat aHP_i ( nd ) Tdi nd ( sc_i ) Tconn_r ( eq ) Tdat eq ( a_r ) Tdi eq ( sc_r ) Tconn_r p ( es ) Tdi eq_NO_DI( sc_r )

+ / Pora_SLE t

The Real Time extension (Selic B. et al) introduces two new stereotypes of class: the capsule and the protocol. The capsule has all the properties of a class, including the possibility to define the class behavior through a statechart. Moreover they communicate between themselves through some ports to which protocols are associated. This allows a strict control on signals and data exchanged. The protocol defines a set of signals, divided in input and output, with an associated type (a base data, as for example an integer, or a class). Information transported by signals should include only objects of the related types.
< < P ro t o c o l> > s a i_ s le S a D a t a _ i n d ( D a ti _ S a D a t a ) S S S S S a a a a a H D C C R P D a t a _ in d ( b y t e [ ] ) i s c _ i n d ( D a t i _ S a D is c ) o n n _ in d ( D a t i _ S a C o n n I n d ) o n n _ c o n f ( D a ti _ S a C o n C n f ) e p o r t_ in d ( )

Fig. 4 Class Diagram

S a C o n n _ re q ( D a t i_ S a C o n R e q ) S S S S a a a a C D D H o n n _ r e s p ( D a ti _ S a C o n R s p ) i s c _ r e q ( D a ti _ S a D i s c ) a t a _ r e q ( D a t i _ S a D a ti ) P D a t a _ re q (b y t e )

< < P r o to c o l> > s l e _ t ra n s p o r t T T T T T co n n _c o nf (A U 2 ) c o n n _ in d ( A U 1 ) d a ta _ in d ( D T ) d a t a H P _ i n d (D a t a ) d i s c _ in d (D I )

T co n n _re q (A U 1 ) T T T T d a ta _ re q (D T ) d i s c _ re q ( D I ) co n n _re sp (A U 2) d i s c _ re q _ N O _ D I ( )

Fig. 5 Protocol Class

Structure diagrams capture communication patterns among capsules showing channels and internal structure. Every capsule, in fact, can contain other capsules, thus allowing decomposing a system in subsystems up to single components. State diagrams are used to model dynamics of the system: in fact, they describe the behavior of classes and capsules. A state diagram is composed by a set of states and the transitions from one state to another one. As already stated, the formalism adopted in UML is based on David Harels statecharts. Specification execution starts from an initial point and automatically evolves into the creation of capsules in their initial state; any evolution can take place only as a consequence of the arrival of a signal at one of the ports of the capsule. Each transition has firing conditions (events with or without guards) and the related action (an atomic elaboration that is executed if the transition is fired). Therefore, for each state, the following actions are possible: Entry actions executed every time a state is reached; Exit actions executed every time a state is left; Do actions that are typically cyclical and executed continually as long as the capsule remains in that state. The use of state machines and signals make UML-RT model event driven; in other words, it is reactive to external events. 5. MODEL AND VERIFICATION OF EURORADIO SPECIFICATION This section describes the specification model and the verification activities performed. 5.1 Model of EURORADIO Specifications As shown in the class diagram (Figure 4) of the EURORADIO model, two protocol elements are present; the first, sle_trasport, is used by Safety Layer to communicate with the Transport Layer, the other, SaSAP, to communicate with SLE user (named SaS user). The ports of SLE capsule are of two types: the first includes two ports used by SLE to communicate with upper and lower layers of protocol stack; the second comprises the service port, managing the timer (used in the verification

of connection setup timeout), the error and the log. The ISO/OSI layer 3 (Network), 2 (Data Link) and 1 (Physical) are not included in the model to avoid details not relevant at system level. In Fig. 5 the protocol elements of two SLE interfaces are shown, with signals divided in two sets (input and output). Every signal is linked to the type of data that it transports, in order to check coherency of data exchanged in a session. The model allows controlling not only data type, but also every field of the Sa-PDU (Safety Protocol Data Unit), e.g. the MAC field containing the message authorization code. Every layer of the protocol stack is implemented by a state machine; in particular, the Safety Layer state machine (see fig. 6) has six states: IDLE, the initial state: the safety connection is closed or non existent; WFTC, Wait For Transport Connection, the SLE starting connection set-up phase waits for the confirmation of transport connection from the other SLE. WFAR, Wait For Authentication Response SaPDU, the initiator SLE waits for the last authentication message; DATA, the safety connection is established and ready to send/receive data; WFAU3, Wait For Third Authentication message, SLE waits for the message AU3 from the SLE initiator; WFRESP, Wait For SaCONNECT.response, SLE waits for the response to connection request from the SaS User. The described model is an extension of the state machine presented in EURORADIO FIS (Functional Interface Specification) (Unisig, section 7.2.5) to solve two important limitations: a) in FIS, state machine transitions are specified only for main scenarios and b) error transitions are merged. In fact the model combines more section of FIS (Unisig) (in particular section 7.2.5 State table and 7.3.3 Error management) to check for possible incoherence and define a complete and executable state machine. The modeling tool adopted is Rose Real Time from Rational (http://www.rational.com) that is able to execute a model written in UML-RT language. 5.2 Validation activities

I ii l n ta

B a d _C o nn _ r q e

B a d_ C o n n _ i d n

I LE D N O _A U 2 C o nn _ r q e C o nn _ r q e B a d_ A U 2 T i e ou t m W FT C D i _r q sc e D i sc D i _i sc nd B ad _ A U 3 N O _A U 3 W FA U 3 A U 1 _ T C o nn _ i d n

D i c _ind s B a d_ A R A U 2 _ T C on n _ co n f A U 2 _ T C on n _ co n f N O _A R T i eo u t m D i _r q sc e W FA R D i _ re q sc N O _D A T A D i _i d sc n W FR E S P AR D ATA S a C on n _ r sp e N O _ R e sp B ad _ D a t a D i _i d sc n D i _r q sc e AU 3

D a ta _ i d n D at _r q a e

Fig. 6 State Machine Validation activities were based on specification execution. A set of tests was run to exhaustively verify behavior of system at the reception of unexpected messages or with corrupt data. Moreover all states and conditions were considered to identify parts of the specification never executed. To achieve this level of coverage the generation of scenarios is based on the construction of a condition tree for every use case. The success scenario is the principal branch and for every possible ramification a related scenario is generated. The finite nature of protocol (as number of states and possible events) guarantees the limited dimension and the completeness of the tree. For every scenario the model has been tested starting from initial input (the safety layer user primitive) and letting the model freely run, or injecting error conditions (at transport layer level, as data corruption etc.). The data obtained are successively gathered in sequence diagram (see figure 7) and compared with use cases built in the analysis phase. During the simulation all the transmitted information (direction flag, data transported, eventual error code etc.) is recorded in order to check, together with the correctness of message type, also message values coherency. Scenarios identified in this simulation activity have been used to define the test set to verify software that will implement the EURORADIO FIS. The formalization of the specifications makes them unambiguous and removes eventual contradictions, with benefits both for the implementation and the testing phases. 6. RESULTS AND FUTURE WORKS The execution of all the scenarios on the model has revealed a series of incoherencies in the original specifications. In particular problems discovered are: Deadlocks Incomplete specification of the behavior in case of failure Incoherencies between different sections of the FIS Even if none of these errors could lead the system in unsafe state this work has stressed the importance of the formal verification and the efficiency of the proposed methodology to fulfill CENELEC requirements. As future activity we plan to extend the approach to other layers of the protocol stack and to functional specification of the whole system behavior.

/ S a S U se r_ In i a to r ti : S ai

/ S L E _ In i a to r ti :S l e

/ tra n sp T O tra n sp : T ra n sp o rt

/ S L E _ R e sp o n d e r :S l e

/ S a S U s er_R e s p on d e r :S ai

ID L E 1 : S a C o n n _ re q 2 : S ta rt T e s ta b

ID L E

C o stru i i A U 1 sc 3 : T c o n n _ re q (A U 1 ) W FT C 3 .1 : T c o n n _ind (A U 1) C heck A U 1 C o stru i i A U 2 sc 4 : T c o n n _ re sp (A U 2 ) 4 .1 : T c o n n _ c o n f ( U 2 ) A C heck A U 2 C o stru i i A U 3 sc 5 : T d a ta _ re q (A U 3 ) W FAR 5 .1 : T d a ta _ i d (A U 3 ) n C heck A U 3 6 : S a C o n n_ i d n W FR ESP 6 .1 : S a C o n n _ re sp W FA U 3

C o stru i i A R sc 7 : T d a t _ re q (A R ) a 7 . : T da t _ i d ( R ) 1 a n A D ATA C heck A R 8 : S to p T e sta b

9 :S a C o n n _ c o n f D ATA

Fig 7 Sequence diagram of connection set up As final result of this experience we can affirm that formal methods have proved to be valuable as validation techniques. However they could be even more profitable if used in design methodology. Development environments using formal languages like UML (where verification activities require little technical knowledge of formal methods) show all the signs to be a valuable solution. REFERENCES Unisig: SUBSET-037 2.2.0 EURORADIO FIS CENELEC: EN 50159-2 Railways Applications: Signalling and Communications - SafetyRelated Communication in Open Transmission Systems CENELEC: EN 50126 Railways Applications The specification and demonstration of Reliability, Availability, Maintainability and Safety (RAMS) CENELEC: EN 50128 Railways Applications: Communications, signalling and processing systems -Software for railway control and protection systems Abbaneo, Amendola, Gnesi, Latella, Lenzini, Marmo (2000) An Automatic SPIN Validation of a Safety Critical Control System in Proc. of FTCS-30, New York Harel D. (1987) Statecharts: a Visual Formalism for Complex Systems, Science of Computer Programming 8 Object Management Group: OMG Unified Modeling Language Specification 1.4 Selic , B., J. Rumbaugh Using UML for Complex Real-Time Systems http://www.rational.com