a uml approach for modeling and verifying of railway ... · 10th international conference on...

$: A UML APPROACH FOR MODELING AND VERIFYING OF RAILWAY ... · 10th International Conference on MOdeling, Optimization and SIMlation - MOSIM14 - November 5-7-2014- Nancy - France \Toward$
HAL Id: hal-01166630https://hal.archives-ouvertes.fr/hal-01166630

Submitted on 23 Jun 2015

HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, estdestinée au dépôt et à la diffusion de documentsscientifiques de niveau recherche, publiés ou non,émanant des établissements d’enseignement et derecherche français ou étrangers, des laboratoirespublics ou privés.

A UML APPROACH FOR MODELING ANDVERIFYING OF RAILWAY SIGNALLING SYSTEMS

SPECIFICATIONSZaibi Kais, Mohamed Sallak, Walter Schon, Subeer Rangra, Roberto Sacile

To cite this version:Zaibi Kais, Mohamed Sallak, Walter Schon, Subeer Rangra, Roberto Sacile. A UML APPROACHFOR MODELING AND VERIFYING OF RAILWAY SIGNALLING SYSTEMS SPECIFICATIONS. MOSIM 2014, 10ème Conférence Francophone de Modélisation, Optimisation et Simulation, Nov2014, Nancy, France. �hal-01166630�

https://hal.archives-ouvertes.fr/hal-01166630

https://hal.archives-ouvertes.fr

10th International Conference on MOdeling, Optimization and SIMlation - MOSIM14 - November 5-7-2014-Nancy - France “Toward circular Economy”

A UML approach for modeling and verification of Railway

signalling Systems specifications

Z. KAIS, M. SALLAK, W. SCHON, S. RANGRA R. SACILE

Heudiasyc CNRS UMR 7253 University of Genova

Compiegne University of Technology (UTC) Department of Computer science, Bioengineering,

60200 Compiegne - France Robotics and Systems engineering (DIBRIS)

mohamed.sallak,walter.schon,[email protected] 16145 Genova - Italy

[email protected]

ABSTRACT: This paper proposes a UML based approach for the modeling and the verification of Rail-way signalling Systems specifications. Particularly, we consider the European Rail Traffic ManagementSystem (ERTMS) and the European Train Control System (ETCS) specifications. First, the architectureof ERTMS/ETCS is described. The validation and verification procedure is also introduced. Then, class,sequences and use case diagrams related to the technical specifications of ERTMS/ETCS are presented. Acase study from the technical specification of ERTMS/ETCS which represents the operation of ”Establishinga communication session” between ERTMS/ETCS On-board equipment and RBC (Radio Block Center) toinitiate a communication session is also proposed. Finally, a formal verification using B method is proposedto show how to verify some safety properties of railway signalling systems and to complete the verificationprocedure performed using UML.

KEYWORDS: Railway signalling systems, ERTMS/ETCS, UML, verification.

1 Introduction

European Rail Traffic Management Sys-tem/European Train Control System(ERTMS/ETCS) is a widely implemented rail-way signalling system in Europe. ERTMS/ETCS isa platform to guarantee the interoperability acrossdifferent countries and manufacturers by creating asingle Europe-wide standard for train control andcommand systems. It has two components, the firstcomponent being ETCS, which is a standard fortrain control systems, and the second componentbeing the Global System for Mobile communications-Railways (GSM-R), which is an international wirelesscommunications standard for railway communicationand applications. ERTMS/ETCS has three levels.ERTMS/ETCS Level 1 and ERTMS/ETCS Level 2are widely applied in Europe. ERTMS/ETCS Level3 is currently under development.

The railway standards (EN50126 2000,ERTMS/ETCS 2010b, ERTMS/ETCS 2010a)define the procedure for verification and validation ofrailway systems. Particularly, the System Require-ments Specification (SRS) (ERTMS/ETCS 2010a)developed by the European Railway Agency(ERA) defines the system requirements for theERTMS/ETCS. This specification often offers

multiple solutions on how to implement a specificfunction. It therefore contains both mandatory andoptional requirements. Particularly, the Chapter3 in (ERTMS/ETCS 2010b) specifies the systemprinciples and specifications of ETCS/ERTMSapplied to software used in On-board and tracksidesubsystems. However, the ERTMS/ETCS SystemRequirements Specification (ERTMS/ETCS 2010b)and the ERTMS/ETCS Functional RequirementsSpecification (ERTMS/ETCS 2010a) are writtenin natural language. This is a major issue whendealing with such systems since, by nature, literalspecifications often hold ambiguities as they can besubject to different interpretations.

Several methods were proposed to model railwaysystems in order to verify their compliance withspecifications defined in standard (EN50126 2000,ERTMS/ETCS 2010b, ERTMS/ETCS 2010a). Mostof the modelling representations for ETRMS/ETCSwere made in B language (Fantechi, Fokkink &Morzenti 2013) or using Petri nets (Barger, Schon& Bouali 2009) which are difficult methods to under-stand by railway engineers and need some theoreticalbackground. The Unified Modeling Language (UML)is a well known recognized, powerful and leading di-agrammatic modeling language. Nowadays, UML isbecoming a standard modeling language for the hard-

MOSIM14 - November 5-7-2014 - Nancy - France

ware and software Industries. However, few workswere proposed to model railway systems using UML.In (Zimmermann & Trowitzsch 2009), the authors de-scribed behavioral modeling of systems with UMLState Machines and a transformation method intocorresponding Stochastic Petri Nets to perform reach-ability analysis. They consider a part of the com-munication between trains and RBC. The methodshave been implemented as a prototype extension ofthe TimeNET tool including a specific graphical ed-itor for UML State Machine models. In (Bernardi,Flammini, Marrone, Mazzocca, Merseguer, Nardone& Vittorini 2013), the authors addressed the defini-tion of a Model-Driven approach for the evaluation ofRAM (Reliability, Availability, Maintainability) at-tributes in railway applications to automatically gen-erate formal models. The approach is based on theusage of UML profiles at the conceptual representa-tion level of the system for the automatic generationof formal models. In (Jabri, El koursi, Lemaire &Bourdeaud’huy 2009), the authors presented meth-ods dedicated to the generation of tests scenarios forthe validation of ERTMS communication componentsbased on functional requirements, UML models andPetri nets. In (Mecitoglu & Soylemez 2013), UMLformalism was employed to design a railway signallingsystem simulator and a SCADA system. The devel-oped simulator can also help to validate a formal de-sign based on automata. In (Ghazel 2014), the au-thor proposed a mechanizable formalization of a sub-set of ERTMS/ETCS specifications relative to ETCSmodes and transitions based on class diagram modeland formal SMV model.

The present work is an attempt of to apply UMLmethodology to formalize and verify specifications re-lated to the functioning of principal systems used inERTMS/ETCS. UML class, sequence and activity di-agrams related to ERTMS/ETCS will be designed.The originality of this work is that first it proposesa real case study concerning a specification from theUNISIG standard (ERTMS/ETCS 2010b). Secondly,the UML proposed methodology introduces severaltypes of diagrams for modeling ERTMS/ETCS (bothOn-board and trackside subsystems). Finally, theverification of specifications is based on verificationtools used in UML without using other formal meth-ods such as Petri nets or B method. In this work,we argue that ERTMS/ETCS and railway systemsin general can benefit from the introduction of aformal modelling approach. Thus, we propose thatUML would be a suitable paradigm for modellingERTMS/ETCS.

2 Architecture and environment ofERTMS/ETCS

The European Railway Traffic Management System(ERTMS) is a major industrial project developedin order to enhance cross-border inter-operabilitythrough Europe by creating a single standard forrailway signalling. This project was developed by 8UNIFE (Association of the European Rail Industry)members: Alstom Transport, Ansaldo STS, AZDPraha, Bombardier Transportation, Invensys RailGroup, Mermec, Siemens Mobility, and Thales. Itwas also supported by the European Union (EU),railway stakeholders and the GSM-R industry. Bythe end of 2012, more than 62000 km of railwaytracks and 7500 vehicles are either already running orbeing equipped with ERTMS in 38 countries aroundthe world.

ERTMS has two basic components:

• European Train Control System (ETCS) whichis an automatic train protection system (ATP)to replace the existing national ATP-systems.

• GSM-R which is a radio system for providingvoice and data communication between the trackand the train, based on standard GSM using fre-quencies specifically reserved for rail application.

The architecture and the environment of theERTMS/ETCS are defined in the the UNISIGSUBSET-026-02 (ERTMS/ETCS 2010b) which amandatory document related to ERTMS/ETCS re-quirement specification.

2.1 ERTMS/ETCS Levels

ERTMS/ETCS has three levels. ERTMS/ETCSLevel 1 (Fig. 1) is superimposed on the existingsignalling system. The transmission of informationfrom the track to the train-borne system is totallydependent on balises which are installed in the track.The driver controls the train according to the line-side signals. In ERTMS/ETCS Level 2 (Fig. 2), theinformation is transmitted by radio. The authorityand track description are displayed directly in thecab for the driver, so lineside signals are no longerneeded. Balises are used as positioning beacons tohelp the train to determine its position via sensors.In ERTMS/ETCS Level 3 (Fig. 3), the train integritychecking is done by the train itself, so track circuitsare no longer needed. Balises are used to update posi-tion information and transmit position and integritydata back to the interlocking via GSM-R.


Figure 1: ERTMS/ETCS Level 1



2.2 Architecture of ERTMS/ETCS

Due to the nature of the required functions, the pro-posed architecture of ERTMS/ETCS system definedin (ERTMS/ETCS 2010b) has two sub-systems:

• On-board sub-system.

• Trackside sub-system.

Figure 4 represents the architecture of theERTMS/ETCS. The interfaces in brackets arenot required for interoperability.

Figure 4: UNISIG ERTMS/ETCS reference architec-ture

2.2.1 Trackside subsystem

Depending of the ERTMS/ETCS level, the tracksidesub-system can be composed of:

• Balises: are electronic beacons or transpondersplaced between the rails in order to send mes-sages from trackside to the on-board sub-systemand are based on existing Eurobalise specifica-tions. Each balise transmits a telegram and thecombination of all telegrams defines the messagesent by the balise group.

• Lineside electronic unit: generates telegrams tobe sent by balises on basis of information receivedfrom external trackside systems.

• Radio communication network (GSM-R): is usedfor the bi-directional exchange of messages be-tween on-board sub-systems and RBC or radioinfill units.

• Radio Block Centre (RBC): is a computer-basedsystem that elaborates messages to be sent to thetrain on basis of information received from exter-nal trackside systems and on basis of informationexchanged with the on-board sub-systems.

• Euroloop: operates only on ERTMS/ETCSLevel 1 lines. It provides signalling informationin advance as regard to the next main signal inthe train running direction.


• Radio infill unit: operates only onERTMS/ETCS Level 1 lines. It providessignalling information in advance as regardto the next main signal in the train runningdirection.

2.2.2 On-board sub-system

Depending of the ERTMS/ETCS level, the on-boardsub-system can be composed of:

• The ERTMS/ETCS on-board equipment: isa computer-based system that supervises themovement of the train to which it belongs, onbasis of information exchanged with the track-side sub-system. It is composed of:

– Kernel which comprises the whole Eurocab,the interface equipment with the GSM-R,the data transmission equipment with Eu-robalise, Euroloop and Euroradio, and theinterface with the lineside signalling sys-tems (interlocking, signals) and other on-board systems (braking systems).

– BTM (Balise Transmission Module) whichis an interface used to receive telegramsfrom balises and to provide power to balises.

– RTM (Radio Transmission Module) whichprovides a bidirectional interface with theTrackside system via a mobile terminal.

– DMI (Driver Machine Interface) or MMI(Man Machine Interface) which provides abidirectional interface with the train driver.It displays information and instructions tothe driver, and the driver reacts to them.

– TIU (Train Interface Unit) which provides abidirectional interface with the train-borneequipment.

– Odometer which measures train speed anddistance since last balise. In order to controltrain movement, the kernel has to interfacewith odometer.

• The on-board part of the GSM-R system: TheGSM Radio system is neither developed nor stan-dardized within the frame of the UNISIG require-ments specifications (ERTMS/ETCS 2010b).

• Specific transmission modules for existing na-tional train control systems.

2.3 ERTMS/ETCS environment

The environment of ERTMS/ETCS system is com-posed of:

• the train, which will then be considered in thetrain interface specification;

• the driver, which will then be considered via thedriver interface specification;

• other onboard interfaces.

• external trackside systems (interlockings, controlcentres, etc.), for which no interoperability re-quirement will be established.

3 RAMS requirements specification forERTMS

The RAMS (Reliability, Availability, Maintenabilityand Security) requirements specification for ERTMSare defined in the RAMS requirement specification- Chapter 2 (ERTMS/ETCS 1998) developed bythe ERTMS User Group. These RAMS requirementare based on the requirements defined in the CEN-ELEC EN50126 (EN50126 2000) and adapted tothe ERTMS/ETCS requirement system specificationdefined by the UNISIG (ERTMS/ETCS 2010b).

The conformity of ERTMS/ETCS to the RAM re-quirements is performed in 4 steps:

• The identification of the mission Profile.

• The definition of RAM Requirements.

• The definition of criteria of RAM V&V.

• The definition of requirement for theERTMS/ETCS RAM programme.

3.1 Mission Profile identification

The mission profile of ERTMS/ETCS introducesthe conditions corresponding to the accomplish-ment of the system mission. The mission of theERTMS/ETCS is to supervise the movement oftrains for each application level, and to ensure theirsafety. It should be noted that the considered sys-tem for these RAMS requirement is composed of theERTMS/ETCS which equipped the train and theERTMS/ETCS trackside and lineside equipment en-countered during 1 hour of trip in the worst case.

3.2 The definition of RAM Requirements

The ERTMS/ETCS RAMS Requirements Specifica-tion (ERTMS/ETCS 1998) provides the RAM re-quirement for the whole ERTMS/ETCS and the 3subsystems: Onboard, Trackside and Lineside. Be-cause no experiences are at present recognizable inEuropean Railways at an acceptable experience level,there is no related data on GSM-R in this specifica-tion.


3.3 The definition of criteria of RAM V&V(Verification and Validation)

The RAM V&V is based on the evaluation of theRAM Demonstration Test results or, where testing isnot applicable for practical or economic reasons, ofthe documental proof of the fulfilment of RAM tar-gets, in order to establish the compliance with theSystem RAM Requirements. Particularly, The ac-ceptance criteria are conditioned to the adequacy ofthe RAM Validation Report, which purpose is to doc-ument the success, or the unsuccess, of the ReliabilityDemonstration Tests or of the documental proof.

3.4 The definition of requirement for theERTMS/ETCS RAM programme

The ERTMS/ETCS RAM Programme is a set of ac-tivities to be performed along the ERTMS/ETCSLifecycle for ensuring that the RAM Requirementsstated for the system are fulfilled at each develop-ment phase. The RAM Programme aims to identifythe system RAM Requirements and the activities ofanalysis, verification and demonstration, to be devel-oped by the subjects responsible for performing activ-ities related to one or more ERTMS/ETCS Lifecyclephases, for ensuring the compliance with the aboverequirements.

4 UML models of ERTMS/ETCS ans formalverification

4.1 UML Diagrams

UML is a visual modeling language. It has beenimplemented to simplify and consolidate the manyobject-oriented methods. The object-oriented analy-sis (OOA) uses object modeling techniques to analyzesystem requirements. It considers the world as a setof objects with data structures and behaviors. In-deed, the idea that a system can be regarded as apopulation of interacting objects, each of which is anatomic unit of data and functionality is the founda-tion of object technology. The object-oriented worldis based on the following concepts: objects, classes,inheritance and aggregation. For example:

• An object has a state that is not a set of circum-stances describing it.

• A class is a collection of similar objects with thesame attributes and the same methods.

For a given class, the created objects are called in-stances of the class. Each instance will have its ownidentity. It is possible for objects to be composed ofother objects; it is an aggregation or composition re-lationship. When the destruction of the compound

results in the destruction of the components, it is astrong aggregation that is the composition. However,the aggregation is not the only way in which two ob-jects may be linked. An object can be a specializationof another object by inheritance. In addition, UMLoffers a variety of diagrams to express different viewsof the system:

• a static view of the system through the class di-agram, the object diagram, the component dia-gram and deployment diagram.

• a dynamic view through the sequence diagram,the state machine diagram, the activity diagramand the collaboration diagram.

• a functional view through the diagram use case.

4.2 Formal verification

Formal methods are increasingly becoming necessaryand in some cases mandatory for developing safetycritical software of railway signaling systems. For-mal specifications allow for a mathematical definition,manipulation and reasoning, facilitating the rigoroustesting procedures. In our opinion, whereas UML di-agrams allow us to verify at each step of constructiondiagrams that all the diagrams are free from syntaxerrors and are coherent, formal methods can be usedfor the verification of some safety properties of railwaysignaling systems. Thus, the purpose of our work,in addition of the verification performed when con-structing UML diagrams, is the use of B method asanother support tool to express and verify some ofthe safety properties relevant to the railway signalingsystems.

B is a formal method introduced by J-R. Abriel(Abrial 1996) that covers the complete life cycle ofsoftware development. The main feature of a B de-velopment process is that it proves that the final codeimplements its formal specification. The B notationsare based on set theory and generalised substitutions.The B method enables an incremental developmentprocess which consists of an abstract specification,followed by some refinement steps. The final refine-ment corresponds to an implementation. The cor-rectness of the construction is obtained by the veri-fication of the proof obligations (POs) associated toeach step of the development. The abstract machineis composed of a set of variables, invariant propertiesof those variables, and operations. The set of variablevalues represents the state of the system, and can bemodified by operations which must preserve its invari-ant (see (Abrial 1996), for more details). The POsare generated automatically by software tools such asAtelier B, B4free, B-Toolkit, etc. The check of thesePOs is performed using the same tools either throughan automatic or an interactive proof.


4.3 ERTMS modeling with UML

Modeling ERTMS/ETCS involves several actors. Inorder to model a process or a scenario, it is neces-sary to model the behavior of each object involvedin a given operating procedure. The identification ofstakeholders to define use cases knowing that UMLuse case determines an action performed by the sys-tem and producing an observable result by one ofthe actor’s sequence. An operating procedure of theERTMS system corresponds to a UML use case. Fur-thermore, the verification of a component such as theEuropean Vital Computer (EVC) as a reactive com-ponent interacting with the external environment re-quires modeling the behavior of each object commu-nicating with it. The UML sequence diagram identi-fies the different interactions between objects. TheUML class diagram models the static structure ofthe system by identifying the properties of each ob-ject. In the sequel, ERTMS/ETCS systems will bedescribed with UML through their static structuresand dynamic behaviors.

4.3.1 UML Static Diagrams

In order to validate and verify the ERTMS/ETCSspecifications, we have first to construct a staticglobal view of the ERTMS/ETCS and its envi-ronment. The class diagram is the main buildingblock of static diagrams used in UML. Indeed, theconsidered class diagram, in this section, repre-sents the static structure of ERTMS/ETCS thatdescribes the structure of ERTMS/ETCS by show-ing the ERTMS/ETCS’s classes, their attributes,operations, and the relationships (composition,aggregation and inheritance) among objects. Theoverall diagram of the whole ERTMS/ETCS was notpresented here because of its huge structure. Wechoose only to represent in Figure 5 a class diagramwith principal components.

We provide the classes, attributes and operationsof EVC, control center, interlocking system, FPGA,voter, GSM-R card, WAN card, CPU, bus, powersupply, and Triple Modular Redundancy (TMR) ar-chitecture for the RBC. The top part of the classescontains the name of the class. The middle partcontains the attributes of the class. The bottompart gives the methods or operations the class cantake or undertake. For example, in the RBC class,the attributes (Id-RBC, Name-RBC, etc.) and op-erations (Accept-Opening-Session(), Close-Session(),etc.) of RBC are defined. The relationships betweenthe RBC and its components (CPU, TMR, Voter,FPGA, Bus, WAN Card, GSM-R Card, and powersupply) are based on compositions whereas the rela-tionships between the RBC, control center, EVC andinterlocking are based on associations. Each compo-

Figure 5: Class diagram of ERTMS architecture

sition is as a filled diamond shape on the containingclass end of the tree of lines that connect containedclass to the containing class. Each association is rep-resented as a line. The ends of these associationsare adorned with role names and multiplicity. Therelationships between the TMR architecture and itscomponents (CPU, Voter, FPGA) are based on aggre-gations. Each aggregation is represented by a hollowdiamond shape on the containing class end of the treewith a single line that connects the contained class tothe containing class.

4.3.2 UML Dynamic Diagrams

The use cases are used to represent ERTMS/ETCSat a higher level. They represent the user’s interac-tion with the ERTMS/ETCS subsystems. They canportray the different types of users of ERTMS/ETCSsubsystems and the various ways that they interactwith the system. In Figure 6, we present a usecase of a managing traffic demand. The actors areEVC, Interlocking, Control center and RBC. Then,we present a sequence and an activity diagrams inFigures 7 and 8.

The sequence diagrams show how ERTMS/ETCSsubsystems operate with one another and in whatorder. They are a construct of a Message SequenceChart and shows ERTMS/ETCS subsystems in-teractions arranged in time sequence. In Figure7, we represent the sequence digram of the pro-cedure initiated by the driver in order to receivea MA (Movement Authority) from the control center.

The activity diagrams represent workflows of step-


Figure 6: A use case of managing traffic demand

wise activities of traffic permit request and the cor-responding actions of ERTMS/ETCS procedures. InFigure 7, we present an activity diagram of trafficpermit request. The rounded rectangles representthe following actions: Logon processing, Verificationof the itinerary, etc. The diamonds represent deci-sions about state track. The black circle representsthe start (initial state) of the workflow which corre-sponds to the Opening session received. The encircledblack circle represents the end (final state) which cor-responds to closing session or reservation of track.

4.3.3 Verification of UML models

All the diagrams of his work were performed us-ing ArgoUML. We then use the modules ”Designcritics” of ArgoUML. They are simple agents thatcontinuously execute in a background thread ofcontrol. They analyze the design of each diagramof ETRTMS/ETCS as we are working and suggestpossible improvements. These suggestions rangefrom indications of syntax errors, to reminders toreturn to parts of the design that need finishing, tostyle guidelines, to the advice of expert designers.

Many critics offer to automatically improve the de-sign. Critics are controlled so that their suggestionsare relevant and timely to the design task at hand,based on information in Argo’UMLs user model.Critics never interrupt the designer, instead they posttheir suggestions to the designer’s ”to do”list. This al-lows us to verify at each step of construction diagramsthat all the diagram are free from syntax errors.

5 Case Study: Management of Radio Com-munication

5.1 Description of the case study

In this case study, we consider the operationof ”Establishing a communication session” betweenERTMS/ETCS On-board equipment and RBC to ini-

Figure 7: A sequence diagram of managing trafficdemand

tiate a communication session. This specification ispresented in the ERTMS/ETCS requirements spec-ification - Chapter 3 (ERTMS/ETCS 2010b). Weaim to model and formalize the above specificationusing UML models. It should be noted that the ra-dio In-fill Unit shall never initiate a communicationsession. Furthermore, only communication sessionsbetween an ERTMS/ETCS On-board equipment anda trackside equipment (RBC or Radio In-fill Unit)are considered here. The on-board shall establish acommunication session:


Figure 8: Activity diagram of Traffic permit request

• At Start of Mission only if level 2 or 3.

• If a mode change, not considered as an End ofMission, has to be reported to the RBC only iflevel 2 or 3.

• If the driver has manually changed the level to 2or 3.

• When a Start of Mission procedure, during whichno communication session could be established,is completed in level 2 or 3.

The order to contact an RBC shall include:

• The identity of RBC.

• The telephone number of RBC.

• The action to be performed (establish/terminatethe session).

If the order to establish a communication session withan RBC is received and accepted by ERTMS/ETCSOn-board equipment already in session with anotherRBC, the existing communication session shall be ter-minated and the new one shall be established. Theorder to contact an Accepting RBC shall be part ofthe RBC transition order and shall include:

• The identity of the Accepting RBC.

• The telephone number of the Accepting RBC.

• Whether this applies also to Sleeping unit.

The order to contact a Radio In-fill Unit shall include:

• The identity of Radio In-fill Unit.

• The telephone number of Radio In-fill Unit.

• The action to be performed (establish/terminatethe session).

If the establishment of a communication session is ini-tiated by On-board, it shall be performed accordingto the following steps:

• The On-board shall request the set-up of a saferadio connection with the trackside. If this re-quest is part of an on-going Start of Mission pro-cedure, it shall be repeated until successful or adefined number of times.

• As soon as the safe radio connection is set-up,the On-board shall send the message Initiationof communication session to the trackside.

• When the on-board receives the system versionit shall consider the communication session es-tablished and:

– If one of its supported system versions iscompatible with the one sent by trackside,it shall send a session established report, in-cluding its telephone numbers, to the track-side.

– If none of its supported system versions iscompatible with the one sent by trackside,it shall send a version independent mes-sage indicating ”No compatible version sup-ported”. It shall inform the driver and thenshall terminate the communication session.

• When the trackside receives the session estab-lished report or the information that no compat-ible system version is supported by the on-board,it shall consider the communication session es-tablished.

If the establishment of a communication session isinitiated by RBC, it shall be performed according tothe following steps:

• The trackside shall request the set-up of a saferadio connection with the on-board.

• As soon as the safe radio connection is set-up,the trackside shall send the message Initiation ofcommunication session to On-board.


• When the on-board receives the information, itshall consider the communication session estab-lished and send a session established report tothe trackside.

• When the trackside receives the session estab-lished report, it shall consider the communica-tion session established.

• In case the RBC is the initiator, the first mes-sage from RBC to On-board shall have the time-stamp set to ”unknown”;

• In the case the RBC is the initiator, there is noneed to verify the compatibility of the systemversions and for the on-board to send its tele-phone numbers, because the on-board is obvi-ously already known to RBC.

• An order to contact RBC may contain a specialvalue for the RBC identity indicating that theon-board shall contact the last known RBC (i.e.,using the stored RBC ID/phone number, if any);the phone number indicated in the order shall beignored by the on-board equipment.

• If there is no RBC ID/ phone number stored on-board, the order to contact RBC shall be ignored.

5.2 UML models

The class diagram shown in Figure 9 represents RBC,Radio, On-board subsystems, and their main at-tributes and methods which are required to estab-lish a communication between RBC and On-boardvia Radio. So each subsystem should have a uniquereference (Id-Subsystem) to be identified and to avoidambiguity; they also have their own methods and at-tributes. The class association ”Connection” whichis represented by the dotted line is a part of anassociation relationship between RBC, Radio, andOn-board. It provides additional information (Id-connection and Data-connection) about the relation-ship between RBC, Radio, and On-board in order toestablish connection. Particularly, we show that theconnection can’t be established if one of the threesubsystems is missing.

As shown in the sequence diagram of Figure 10, sinceRBC already knows the Identifier of On-board, thecommunication has been established for RBC whichsends a timestamp ”unknown” to EVC located in On-board. Then, EVC has to search RBC phone num-ber in its memory card and sends a request to Con-trol center to get authorization to move, if On-boarddidn’t find the phone number, the communicationsession is not established because EVC is not au-tonomous in the situation of contact a new RBC. Inthis case, On-board needs to receive an order to senda request for recovering RBC phone number. Then,

Figure 9: Class diagram of ”Establishing a communi-cation session”

RBC verifies the itinerary and validate or not the re-quest in the form of movement authorized.

To establish a communication initiated by On-boardwith Trackside (cf. Figure 11), On-board sends firsta message. Then, RBC transmit his version withRBC phone number. In case of compatible version,the communication session is established. Otherwise,On-board sends a message to inform RBC that ”Nocompatible version supported”. When session is vali-dated, On-board sends a request to get authorizationto move and RBC verifies the itinerary and validate ornot the request in the form of movement authorized.

UML models allow one to detect the errors in theprocedure through class diagrams and sequence dia-grams. As shown in this case study, if we make anerror in the identifier of on-board. A failure in theconnection procedure will occur because On-boardcannot initiate communication and each connectionis defined by a date and association identifier RBCRadio and on-board. In the case, when RBC initi-ates communication, On-board searches in its mem-ory the number of RBC and if it cannot find it or getsa wrong Identifier number, it cannot contact RBCand returns a report to the Control Center. Then,if a message cannot be sent, the connection will benot established. Different kinds of verifications werepossible on the proposed UML diagrams of the casestudy: for instance, the verification that a function-ality specified in the sequence diagram of ”Establish-ing a communication session” is present in class dia-grams, or on the contrary that no functionality notrequired by all the specification is present in the classdiagrams. In practice, we discovered some methodsrelated to never activated functions or useless state-ments, which were inherited from an early specifi-cation in the class diagram. Moreover, at a glanceverifications on UML models were straightforward: asequence diagram should contain only the processesthat are involved in that function, as specified by high


Figure 10: Sequence diagram of ”Establishing a com-munication session” initiated by RBC

Figure 11: Sequence diagram of ”Establishing a com-munication session” initiated by the On-borad

level requirements. Such kind of analyses was per-formed informally, exploiting the know-how and skillof railway experts.

Figure 12: Illustration of example 1

6 Formal verification of an ERTMS/ETCSlevel 1

In this section, we consider two examples of specifica-tion of an ERTMS/ETCS level 1 to explain how to usethe set theory in order to convert some safety infor-mal railway specifications into formal ones. Then, weconstruct the abstract machine, the refinement andthe implementation of an example of a safety railwayspecification using B method. Finally, we generatethe POs and prove them using the Atelier B tool.Note that the formal specifications are based on thenotation defined in (Abrial 1996).

Example 1

Let us consider the following informal railway safetyspecification for an ERTMS/ETCS level 1 (cf. Figure12):

If the train enters the forbidden zone called ”zoneinterdite”, then emergency braking called ”Freinurgence” must be triggered.

The formal specification using the set theory is:

P osition train ⊆ P OSIT IONS∧Zone interdite ⊆ P OSIT IONS∧P osition train ∩ Zone interdite 6= ∅ =⇒F rein urgence = T RUE

Example 2

Let us consider another following informal railwaysafety specification for an ERTMS/ETCS level 1 (cf.Figure 13):

The railway line is divided into elementary fixedareas called block sections. Each block section can beoccupied by at most one train.

The formal specification using the set theory is:

Est occupe par ∈ CANT ONS +− > T RAINS

The notation +− > means that the applicationEst occupe par is a partial function from the set


Figure 13: Illustration of example 2

Figure 14: Detailed illustration of example 2

”CANTONS” to the set ”TRAINS”. In other words,an element of ”CANTONS” may not have an image,and all the elements of ”CANTONS” have at mostone image.

The safety properties defined in examples 1 and 2,which must be always respected are called ”INVARI-ANTS”. Indeed, safety properties can always betranslated in the form of ”INVARIANTS” expressedas logical statements called predicates. The firststep is the formal translation of the requirementsfrom informal specifications. This step is crucial be-cause any error or omission at this stage is clearlynot covered by the following formal process. How-ever any property expressed correctly enters a pro-cess to demonstrate mathematically that the wholedevelopment respect it, making the initial specifi-cation all the more crucial. The state of the sys-tem is described by ”VARIABLES” which are subjectto change. The ”VARIABLES” involve also option-ally constants (CONSTANT) and sets (SETS) whichmay remain at the abstract formal specification. Thechanges are related to the services provided by thesystem, formalized by ”OPERATIONS”. ”OPERA-TIONS”are also described in a formal language called”SUBSTITUTIONS”. In the example 2, in which wehave added block sections n and n+1 (cf. the detailedFigure 14), we consider the following operation:

OP ERAT IONS

Avance train =n := n + 1||In + 1 := ROUGE||In− 1 := V ERT

Where || design the parallel ”SUBSTITUTION”. Theprocess of proof is to show that any ”OPERATION”respects the ”INVARIANT”. That is what we callproof obligations (POs). We have to demonstratethat each PO is true like the mathematical proof

Figure 15: Abstract machine, refinement and imple-mentation of example 1

of a theorem. A PO mathematically translates thefollowing statement:

”If the INVARIANT is TRUE before the OPERA-TION, it will be TRUE after the OPERATION”.

We show in Figure 15, the B abstract machine,the refinement and the implementation of the ex-ample 1 written using the ASCII notation of B(AtelierB 2014). Note that the refinement machineadds the explicit definition of the variable Frein ur-gence. A graphical visualisation of the fourth gener-ated POs is shown in Figures 16 and 17. As we cansee, all the four POs of the implementation machineZI i were proven. Thus, we have proven that the fi-nal code, which will be generated automatically fromthe implementation machine ZI i using the Atelier Btool, implements the formal specification of example1.

7 Conclusion

In this paper, we have shown how to construct UMLmodels of ERTMS/ETCS in order to formalize andverify functional and systems requirements. We havealso explain how to make formal verification using Bmethod in order to proof safety properties of rail-


Figure 16: AtelierB user interface showing the gener-ated and proven POs of example 1

Figure 17: Detailed descriptions of POs of example 1

way signalling systems and to complete the verifi-cation procedure performed using UML. The casestudy presented here is part of a real specificationof ERTMS/ETCS where the approach was success-fully applied. The proposed method enables tech-niques that can be used by manufacturers to formal-ize and check automatically the conformance of theirequipment (on-board, track-side) to their functionaland systems requirements.Our futures work will focus on directly convertingUML models to formal languages that can ensure for-mal verification of safety specifications.

Acknowledgment

This work was carried out and funded by the FrenchNational Research Agency, through the project ANR-13-JS03-0007 RECIF.

References

Abrial, J.-R. (1996). The B-Book: Assigning pro-grams to meanings, Cambridge University Press.

AtelierB (2014). Ascii notation for b.http://www.atelierb.eu/ressources/symboles1.8.6.uk.pdf,

Technical report.

Barger, P., Schon, W. & Bouali, M. (2009). A study ofrailway ERTMS safety with Colored Petri Nets,European Safety and Reliability Conference, ES-REL’09, Prague, Czech Republic.

Bernardi, S., Flammini, F., Marrone, S., Mazzocca,N., Merseguer, J., Nardone, R. & Vittorini, V.(2013). Enabling the usage of UML in theverification of railway systems: The DAM-railapproach, Reliability Engineering and SystemSafety 120: 112 – 126.

EN50126 (2000). Railway Applications - The Speci-fication and Demonstration of Reliability, Avail-ability, maintainability and Safety (RAMS),Technical report, CENELEC.

ERTMS/ETCS (1998). RAMS Requirements Speci-fication, Reference EEIG : 96S126.

ERTMS/ETCS (2010a). ERA, Func-tional Requirements Specification, Ref:ERA/ERTMS/003204, Technical report.

ERTMS/ETCS (2010b). ERA, System Require-ments Specification, UNISIG SUBSET - 026,Ref: Index004-SUBSET-026, Technical report.

Fantechi, A., Fokkink, W. & Morzenti, A. (2013).Formal Methods for Industrial Critical Systems:A Survey of Applications, Wiley-IEEE, chapterSome trends in formal methods applications torailway signaling, pp. 63–84.

Ghazel, M. (2014). Formalizing a subset ofERTMS/ETCS specifications for verificationpurposes, Transportation Research Part C:Emerging Technologies 42: 60 – 75.

Jabri, S., El koursi, E., Lemaire, E. & Bourdeaud’huy,T. (2009). Modelling of the European Rail Traf-fic Management System (ERTMS) for CheckingObjectives, 12th IFAC Symposium on Control inTransportation Systems, US.

Mecitoglu, F. & Soylemez, M. T. (2013). A UMLModelling Approach for a Railway SignalizationSystem Simulator and SCADA System, 1st IFACWorkshop on Advances in Control and Automa-tion Theory for Transportation Applications.

Zimmermann, A. & Trowitzsch, J. (2009). Relia-bility Evaluation of Distributed Embedded Sys-tems With UML State Charts and Rare EventSimulation, Dagstuhl-Workshop MBEES: Mod-ellbasierte Entwicklung eingebetteter Systeme V,Schloss Dagstuhl, Germany, pp.128-139.

a uml approach for modeling and verifying of railway ... · 10th international conference on...

Documents