revista - ertms - iness - interlocking

7/27/2019 Revista - ERTMS - InESS - Interlocking

http://slidepdf.com/reader/full/revista-ertms-iness-interlocking 1/12

UNION INTERNATIONALE DES CHEMINS DE FER - INTERNATIONALER EISENBAHNVERBAND - INTERNATIONAL UNION OF RAILWAYS

FOCUS1MAY 2008

1EDITORIAL

At the threshold from the Euro-Interlocking

project to the INESS project P. 1; 11-12

Standardising functional requirements

for Interlocking Systems P.2-3

A common format for graphical user

interface data P. 4

Railway perspective on requirement

development P.4

Extending the testing environment for

the ULM Interlocking simulator P. 5-7Baseline 8.0 P. 7-8

History of the Euro-Interlocking

project: 1999-2008 P. 8-11

1CONTENTS

continued page 2 111

EUR -INTERLOCKING

DB Netz

has high

expectations

of the INESS

project

For DB Netz,

the renewal

of signalling

installations

and their core

element,

interlockings,

is an issue of the highest importance.

Technical and economic studies have

clearly shown that the traditional

procedures and technical solutions

will not allow the assets in thisdomain to be maintained in

acceptable condition. In order to

guarantee a high quality network of

its current size, new cost-effective

methods and technologies are vital.

For this reason, the project “Neupro”

which aims to reduce costs through

standardisation and technical

innovation has been launched at

national level.

Jens Hartmann, memberof the Euro-Interlockingsteering group and theINESS steering board

INESS, an importantmilestone on the way

from national signallingto European unification

Since 1990, theEuropean Union haspromotedthereform of Rail TrafficManagement underthe ERTMS programme, which is driven bythe need for interoperability, the opening ofprocurement markets, increased efficiencyand harmonised safety levels across theEuropean railway system. To date, extensiveand successful efforts have been undertakenin the field of train control – ETCS – and train

communication - GSM-R. In terms of theTraffic Management Layer, the Eur-Optirailproject has developed solutions for intercon-necting the various national high-level trafficmanagement IT systems. However, theseEuropean projects do not yet cover thesignalling system and its main component,interlockings.

Interlockings, including line block systems,are the traditional instrument in thesignal ling sub-system used to interconnect

information on the status of elements andcommands issued to various control devices.

Over the decades, an evolution has takenplace frommanualto automated functioning,with a move from mechanical, electro-mechanical or relay-based systems toelectronic computer-based technology.Extremely high safety and reliability levelshave always been key requirements. In manyEuropean railway networks, there is a hugepotential need forrenewal ofheritagesignallinginstallations, including their interlockings.However, an economic analysis of severalrailways show that a renewal at current

cost levels for planning, procurement andimplementation is no longer affordable.

The INESS project will bridge the divide asregards harmonised specifications withinthe ERTMS framework, as shown in thefollowing figure, which outlines thefunctionalstructure of the Rail Traffic ManagementSystem (left) and the associated Europeanprojects (right).

RAT THE THRESHOLDFROM THE EURO-INTERLOCKINGPROJECT TO THE INESS PROJECT

continued page 11 111

By Peter Winter UIC/SBB Consulting

INESS in the ERTMS context



The objectives and theprocess

The Euro-Interlocking project has set a goalto capture multiple sets of functionalrequirements for interlocking systems fromrailways across Europe, with a long term

vision of generating a large commoncore offunctional requirements, which will serveas basis for the future interlocking systems.This goal has now been transferred to theproject INESS, which will base its work onthecurrentEuro-Interlockingresultsto realizeone of its major objectives - to define acommonkernel of standardised functionalitiesfor future interlockings, including functio-nalities specially required by ERTMS.

Functional requirements havebeencapturedand developed on a common platform,

with the use of a standardised glossary,standardised commands and statuses aswell as standardisedrequirement structures.The requirements are written in Englishand are apportioned to individual railwaysthrough the process of tagging.

The environment for thiswork is the requirementsmanagement toolDOORS,which enables precise tra-cking,changemanagementandgoodtraceability.The DOORS tool permitsthe identification andextraction of individualrailway requirements, aswell as of a common core

of requirements, whichconsists of shared requi-

rements of all participating railways. Acomplete database of requirementsis setandregularly updated once new requirements arecaptured and tagged. The database isresident at the UIC headquarters in Paris,and permits also controlled external access.The related “DOORS database - use andmaintenance” leaflet has been published togive the railway members more insight intothe database and into the process set to

manage the database.

Current status shows that completerequirements have been captured from sixrailways, and partially from three railways.

Standardised functionalrequirements for futureinterlocking systems

With the use of standardised glossary, com-mands, statuses and requirement structures,

a large step has been made towards theachievement of standardised functionalrequirements.Thishas enabled direct compar-ison of requirements from various railways,and has given common understanding of therequirements forall railways andsuppliers.

RSTANDARDISING FUNCTIONAL REQUIREMENTSFOR INTERLOCKING SYSTEMS

02 FOCUS

Standardised commands in DOORS

In cooperation with the supply

industry, some promising initial resultshave been achieved with respect to

more flexible, modular and scalable

system architectures and innovative

cooperation processes. The initial pilot

projects demonstrate that significant

cost reductions can be achieved.

However, we at DB Netz are aware that

efforts at national level alone are not

sufficient to achieve the necessary

turnaround in the area of signallingand interlocking. Pan-European or

even worldwide pre-competitive

cooperation is a must in order to open

up procurement markets. That is why

we have participated from the outset

in Euro-Interlocking work focussing

on user-related issues in the field of

functional requirements and data

preparation. Over the last two years,

we have actively influenced and

supported the initiation of the INESSproject together with colleagues from

other railway networks and from the

supply industry. We are convinced

that this joint undertaking between

railways, manufacturers and

universities, backed by considerable

financial support from the EC, will

achieve the required breakthrough

towards state of the art processes

for the whole life cycle, and towards

future-oriented modular systemarchitectures in line with the various

ETCS application levels.

DB Netz is keen to use the outcomes

of the INESS project, and its precursor

Euro-Interlocking, as soon as possible

in its strategy to modernise signalling

and interlocking. This will contribute to

swift and efficient implementation of

ERTMS with its benefits for trans-

European passenger and freight trainoperation. Let us collectively take up

this challenge for the benefit of the

whole rail sector and its customers! I

(continued)111

1EDITORIAL

Functional requirements databasein DOORS

By Mirko Blazic



The Human Machine Interface file format(HMIFF) has been developed in order to

allow the transfer of signalling projectdata between railway and suppliers. Thegraphical data which is presented on thetrain dispatcher display system can bepresented in a common and standardisedEuro-Interlocking file format. The graphicalsymbols and parameters are able to bestored in electronic exchangeable media,so that it is easy and safe to transferinformation between different projectparties during the whole life cycle of asignalling project.

The pilot project for testing the developedsignalling file formats was created alreadyin 2004. Austrian Railways (ÖBB), theEuro-Interlocking Project and Funkwerkformer Vossloh agreed to use and evaluatethese file formats in a real environment.

During the test period the team wasconfirmed that one major task was to

redraw and determine the position ofsymbols on HMI display. This taskoccurred on several steps during thesignalling project. The redraw work was acost driver, but it could be easily eliminatedby new standardised file format. At thebeginning of 2007 was the first draft ofthe HMI-format developed and thenAustrian Railway started their trials ondeveloping the new data preparation formatfor Best data preparation tool. The projectteam(ÖBB, Euro-Interlockingand Funkwerk)

produced a reviewed German version ofthe HMI data file format on early 2008and the official UIC version has beenreleased during the spring 2008.

The new HMIFF will be an essential part ofthe family of Euro-Interlocking standardised

file formats, which reduce the time andefforts on signalling project on providing

moreautomated ways to parameterise theinterlocking system. Already on the pilotproject year 2006, processing from theCAD-fileto theprogramme of an interlockingsite happened almostautomatically withoutthe need to rewrite the data manually.This ÖBB pilot project already provedbenefits on cost reduction and time savingby using these standardised data exchangefiles formats in a data preparation project.Suppliers offered 5% discount in engineeringcost if the data preparation information is

provided in a standardised format.. In thefuture commonly accepted file standardswill allow different data preparation toolsto communicate easily together and willso shorten the time from planning tocommission of a signalling project. I

ProRail supports the Euro-Interlockingobjectives and has actively participated inthe project from the start. In theNetherlands we do not have nationalmanufacturers able to supply interlockingsystems, so we have to rely on internation-al suppliers. Therefore it is essential tohave a set of unambiguous specificationsat our disposal. That is the reason whythe ProRail specialists have long experi-ence writing textual and semi-formal

requirements.Increased value could be achieved by sharingthis experience with European colleagues,leading towards a standard to be used infuture projects. A lot of work has beencarried out and many requirements havealready been laid down, resultingin positivefeedback from manufacturers and otherrailway companies.In 2008 the result of the work documentedin Baseline 7.2 will be used in tender docu-ments that should spearhead a huge

replacement programme of aged relayinterlocking systems in the Netherlands.However, a lot of work still lies ahead ofus. In the Netherlands a migration can beexpected because of the increased needs

for interoperability and higher performancebeing made on the present network.This now requires the formalising ofrequirements for smootherimplementationof ERTMS. More work in the field ofmodelling, testing and checking mustalso be done. Much can be gained byharmonising as much as possible. Thiswill be our challenge in the near future.

Euro Interlocking standardsand documents baselinesutilisation, return ofexperience.

RFF hasasked SNCF to prepare requirementsfor a call fortender for interlocking systemsbased on the EI qualitative requirements.Even if it has been necessary to add a fewother qualitative requirements and tointroduce national functional requirementsto describe specific French needs we

consider this tender very successful; it hasset the beginning of a new tenderingprocesswith “standardised” documentationat European level. A ten-year interlockingprocurement phase has been started with

three European suppliers.RHK has used twice Euro-InterlockingStandards and Documents Baselines.In 2003 for procuring interlockings forKerava-Lahti line, Baseline 7.0 was used.The line was commissioned in March2006.The second interlocking procurement phasewaslaunchedin 2007 for theLahti-Luumäkiline. Baseline 7.2 with new functionalrequirements included was used.

Commissioning will be during summer2009.The fact of using unambiguous tender andstandards documents put all suppliersat the same level and will allow inframanagers to save time and money.

REFER is currently using EI baseline 7.2 inthe following fields:Applications of Qualitative Requirementsin Technical Documents of REFER;Use of Qualitative Requirements in ERTMS

Plan - tendering process preparation phase;Progressive Migration of the remainingRequi-rements Documents (EI functionaland interface requirements) to TechnicalDocuments of REFER.I

RA COMMON FORMAT FOR GRAPHICAL USER INTERFACE DATA

04 FOCUS

RRAILWAY PERSPECTIVE ON REQUIREMENTS DEVELOPMENT

by Daan van der Meij, ProRail



05EUR -INTERLOCKING

REXTENDING THE TESTING ENVIRONMENT FOR THE UML INTERLOCKINGSIMULATOR

In addition to the task of collecting functionalrequirements for interlockings from variousEuropean railway administrations, it is alsothe goal of the Euro-Interlocking project topromote the compatibility, and even theharmonisation of functional requirementsbetween therailways. To achieve this goal, it isclearly necessary that the project be able toguide each railway through the process, inorder that the implications of the changes insystem behaviour are clear. Although most

administrations think thatlarge proportions oftheir requirements are unique, in fact there isa large degree of communality, in at least thepurpose (if not always in the implementation)of most requirements. However, differencesdo exist and it is the aim of the project toreduce them by promoting harmonisation,eliminating implementation-led requirementsor, when it provesimpossibleto eitherabandonor popularise a function, to place them in anational subset. Regardless of whicheverprocess occurs, it remains important for each

railwaytobeable toexperiencethe functionalityof the specified system before tendering andthis can best be done through simulation.

Flexible Layouts

Until recently the testing of the requirementshad been performed on a fixed layout, whichwas agreed together with the railways severalyears ago. The two stations shown (see lastEuro-Interlocking Focus for details) aimed topresent an environmentin which allfunctionalitycould be tested at least once. Now that the

requirementsdatabase hasgrowntoincorporatethefunctionalityof anumberof countries, wefeelthat it is importantthat thetesting environmentof these requirements should also become morecomprehensive.

The two main aims of extending testing havebeen to improve the flexibility of the tools, sothat it is now mucheasier not onlyto populatethefixed layout with thenecessary parametersfordiffering railway’s useof it,butalsotocreateentirely new railway layouts; thus enablingadministrations to better control their testing.Given the factthat the project aimstopromotegeneric functional requirements, the expandedtesting environment has a third fortunateby-product, which is to enable the genericism

of the requirements and the model to bedemonstrated. Indeed, it is only by showingthat the requirements can provide the neces-sary functionality on a number of differinglayouts that can we prove that the modelreally is generic and not just particular to theoriginal fixed layout.

Prior to starting this work, we were unable toidentify an existing open-source, platform-independent tool currently in use by therailways for the exchange of interlocking

configuration data, which meant that wewould have to develop something ourselves.However, as no comparable generic toolexisted, we were also aware that anything weproduced could well have uses beyond thescope of this project. Consequently we havetried to design something which is bothintuitive to use and easy to extend.

Given both the huge size and delicate natureof the information in an interlocking dataconfiguration file, we chose to pursueourgoalincrementally in a number of steps.

The first release was described in the lastEuro-Interlocking Focus and it allowed eachrailway to configure their usage of the givenfixed layout. Since then we have split up thefunctionality of the graphic user interface toenableit to receive data from differing sourcesand to display them accordingly.

Originallyboththelayout of thetrack elementsand the depiction of their statuses was‘hard-wired’ in the application, as our initialgoal was merely to be able to show simulated

interlocking functionality.

However, we realised that the simulationinterface could also be modularised andsubsequently fully configured for each railway.

The first step in this process was to take thegeographical information out of the userinterface and to place it a configuration filewhich could be created from an externalsource. As we are currently using an Excelspreadsheet to provide the hardware androute configurationto thesimulator, itseemedthe obvious choice to merely add the userinterface data (pixel position, orientationinformation etc.) to the spreadsheet. Thismeansthat in addition to specifying what kind

of signal should be used (shunt or main), itbecame much easier to determine where itshould be placed.

The next module to emerge from the originaluser interface deals with event handling (howcommands shouldbe sent to thesimulator viathe panel). This specifies how commands areentered by the tester and passed on to therequirements simulator. These commands arealready filtered for each railway, so that onlycommandsapplicable to therailwayundertest

will ever be offered. The engine for displayingstatuses changes is generic to all railways andthis too has remained in the core of theinterface application.

The final component to be modularised is theicon library, which concerns the manner inwhich track elements are displayed on thesimulation interface. Currently, any given trackelement is shown in a pre-defined manner,and an interface symbol catalogue is availableto explain what each symbol means:

By Crispin de C. Bayley

* Graphical User Interface

*

level warning

lights active,barriers closed

pointimmobilised

main signal at'Proceed' for a‘drive- on- sight’route

111



However, as this part of the interface hasnow also been extracted from the core, itwould also be possible for it to becomerailway-specific; thus enabling how a par-

ticular track element appears onthepanel tobe configurable. In practice, this would meanthat once a railway has provided us its ownGUI catalogue, whenever a layout is createdfor the simulator, the correct icons would beused as specified by that railway.

While we think that the command handlingandiconlibraryaspects ofthemodularinterfaceare now well-advanced, our suspicions havebeen confirmed that defining pixel positionsforthe layoutinterfaceviaanExcelspreadsheet

is a laboriousprocess.In fact, it was only ever expected that usingExcel for this process would be a temporarysolution to enable us to verify that all thenecessaryinformation hadbeenidentifiedandextracted from the old ‘hard-wired’ interfaceto enable the easy creation of new simulatorinterfaces.

Graphically-defined Layouts

The projectisrelying ontherailways toperformthe validation work of the requirements, asonly thenationaldomain experts canconfirmif the captured functionality is correct. Tomaximisethechances ofsuccess,thevalidationprocess needs to occur in an environment asfamiliar as possible to the railways, thusenabling greater confidence in the processand the captured requirements.In addition, we are very conscious of thefact that there are two points at which therailways’ input touches the project and weareadamantthat theexchangeof information

at these stages should be as intuitive aspossible. Thus, just as the Doors data basehas been logically structured and can beexported in a clearly laid-out Word template,it is also crucial to the acceptance of thedata preparation tools that they should notbe excessively complicated to use.

Having isolated the data which is needed todrivethesimulatorfrom theold interface, ouraim was to migrate it to a format whichwould enable as much of it as is sensible to

be created by graphical means.While it had long been clear that it could bebeneficial to define the layout graphically,during the development of the tool alsobecame apparant that the same tool couldalso beused topopulatetheparametricvaluesfor thetrackelementto bedisplayed. In otherwords,when choosing where to place a set ofpointson theinterface, itwouldbe convenientto define things like the operation timer andthe fouling tracks for that point at the sametime.

Thus, for reasons of greater flexibilty, ease ofuse and the need to test that the modelledrequirements really are generic, a newprogram has been added to the simulationenvironment which enables any given railwaytopology to be created via a drop-and-drop menu.

To use the graphical editor, one first choosesthe size of the desired interface panel, thename of the railway and the name of thestation. Track elements can then be createdby dragging them from thedrop-downmenuandplacing themappropriately on thelayout.The usability is such that level crossings canbe extended to cover multiple tracks andpointsandsignals canbe rotated as required.

The angles of diamond crossings can bechanged as needed and their legs stretchedas as desired. The number and position ofkeys for key-locked points is configurable, asis theability tocoupleshunt andmainsignalsthat appear on the same post. To save time,points ends automatically associate withtheir nearest piece of track so that only thetrack next to the leg in the direction of thepoint will be shown as occupied when thetrack is occupied.Thenaming conventions foralltrackelementsarefree,asisthepositioning

of their name tags. Existing track sections caneasily be extended or modified, by bendingthem around their blue rotation points.

Just as each track element has a tab to

configure its graphical elements (name,display type), it also has a tab whereby it ispossible to enter the various engineeringconfiguration values which each railway

provides for the given track element, butwhich do not have global values within therailway as a whole. Currently this feature hasnot been finished and it is only possible todefine the type of point to be used; but intime this will be extended so that it is possi-ble to enter the configuration for the opera-tiontimer, foulingTVP, self-restoration timer,alternative flank protection element etc.directly from the property dialogue box.Once all this data has been entered, merelyclosing the application saves the data. This

now leaves only the logical concepts such asthe route information to be entered via theexisting excel sheet.We currently have no plans to migrate thisprocess to the graphical menu, as we thinkit would be very complicated and not beparticularly intuitive.

In practice this means that once the genericapplicationhas beenloaded, differentlayoutscan be hot-swapped, thus enabling thegenericism of the model to work on different

specific applications to be verified. This willprobably also lead to the creation ofa numberof test layouts by each railway, each of whichis designed to enable validation of the modelin a particular area of therequirements.

Extending Testing

The evolution of the model is being entirelydriven by the goal of being able to test allthe captured requirements in the DOORsdatabase. As certain requirements necessi-

tate inputs from objects outside the safetykernel, it has become necessary to simulatebehaviour of these elements in order to fullytest the captured functionality.To that end, virtual physical points, signals,tracks, level crossing etc. have now beenmodelled and their status/performance canbe driven directly from the simulator inter-face in order to assess how the systembehaves when elements in thefield arebro-ken, or responding too slowly to commandsfrom the interlocking.

These new objects are strictly speaking out-side the core of requirements, but as thesafety kernel can only be properly testedwhen inputsfrom theseobjects areavailable,it was imperative to model them.

06 FOCUS

Routeonfiguration

Hardwareonfiguration

Interfaceonfiguration

Graphical Editor



Conclusions

Allof this work hasbeenundertaken with theintention of simplifying the procedure forincreasing the compatibility of functionalrequirements between the Europeanrailways.With the conclusion of a graphically-drivendata preparation tool the project has nowreached an important milestone, wherebyboth theinput of data to theinterlocking andthe testing of the simulated interlocking can

be done graphically. More advances could stillbe made, especially in thearea of automatedtesting, but before the project moves on, itwould be best to await the railway’s feed-back as to what to do next.I

07EUR -INTERLOCKING

RBASELINE 8.0

The baseline CD is a deliverableproduced as part of the dissemi-

nation of the Euro-Interlockingproject. Since the beginning ofEuro-Interlocking, many baselineCDs containing all the documentsregarding the project have beenproduced on a regular basis. TheCD’s contents give an overviewof the project’s achievementssince its launch, and especiallythe changes since the last versionof the baseline. It complementsthis summary of the most

recent high-level developmentsin the project.

The aim of the previous baselines was tofreeze the documents at a certain point,and then to use them in order to communi-catetheproject’s most recent achievements.The last baseline (version 7.2)was created in early 2007,around a year-and-a-half ago.

The aim of thisnew baseline isquite different.Version8.0 willbe the lastoneissued withinthe context ofEuro-Interlocking,which wil l bereplaced by theINESS project at theend of this year.Baseline 8.0 was defined

following the Euro-InterlockingHandover Workshop (Paris, 30 May2008), and contains all the documentsthat will be transmitted to the INESSproject.

Contents of the baseline CD

The documents contained on this baselineCD can be divided into several categories.There are 4 types of document classified

by theme: Requirements (documentsdirectly extracted from the DOORSdatabase), Management (project decla-ration, business cases, studies, etc.),

Informative (methods, reports, etc.) andGuidelines (quality plans, use andmaintenance of the database, etc.).

A useful way of describing thedocuments contained in

baseline 8.0 is to con-sider that there are

“old” documents,

which have notbeen modifiedsince the lastbaseline, and“new” docu-ments, whichcan be either

completely newor updated ver-

sions of previousdocuments.

The documents whichhave not been modified

since the last baseline include,amongst others: project declaration, qualityplan, business cases, studieson standardisa-tionin other industries, documents regardinggeneric hazard lists, and the procurementdocumentation guidelines.

The main documents which have beencreated or modified since the lastbaseline are:1 An updated version of the document

entitled “Use and Maintenance of the

Euro-Interlocking database”: a documentdescribing thecontents andthestructureof the database, and how to use itappropriately. 111



RHISTORY OF THE EURO-INTERLOCKING PROJECT:1999 - 2008

08 FOCUS

The precursor project ERRIA 201: “Harmonisation offunctional conditions ofSignalling Systems”

For 15 years, the UIC Infrastructure Forum(formerly Commission) has been working toharmonise the specifications and design ofinterlockings to ensure full compliance withthe CENELEC standards. In 1993, the projectentitled A 201: “Harmonisation of FunctionalConditions of Signalling Systems” waslaunched by the European Rail Research

Institute ERRI, and delivered its final reportin December 1997. Hereafter are listed someof this document’s key points:

1 “Starting point of the work of A 201:Interlockings have always carried out acentral operational safety role in theworld’srailway signalling systems, but theirdevelopment has never been consistent.Principles in different railwayadministrationshave emerged separately through theinterplay of tradition and evolution. …

Certainly, it is perceived that the majority of

interlocking principles originate in eitherBritish, French or German signallingpractices, but each country has adoptedand modified these to suit its total system.… The demand for clear, unambiguousspecifications has probably never beengreater than today with thechange broughtabout by privatisation and the broadeningof supplier bases. …”

1 “Results and benefits: The main aimbehind the work of A 201 was to realise

potential savings for the end-user ofsignalling equipment, by encouraging ahealthy “Europe-wide”market in interlockingsystems. This aim has been furthered byestablishing a set of basic functionaldefinitions which are unambiguous andfree of technical solutions, establishing acomplete analysis of interlocking functionalrequirements in a common format, exposingthe functional discrepancies and harmonisinga “CommonCore”of basic requirements in acommon format. … The “Common Core” is

1 Functional Requirements for Inter-

locking Systems: a complete record ofthe functional requirements of all theparticipating railways (Finland, the

Netherlands, Norway, Poland, Portugaland Switzerland). The documents onthis CD are to be used as informative,and any specific subset for an individualrailway should be obtained directlyfrom the Euro-Interlocking DOORSdatabase.

1Modelling and Simulation: an explanationof the methodology used to modelthe functional requirements of theinterlocking, as well as a documentdescribing the platform tools. A presen-

tation of the strategy chosen to testthe model has also been added.

1 Common Core and Extended Core: aconsolidated draft of the common coreand the extended common core, as wellas an explanation of the process usedto create them.

1 A document describing the developmentof the Euro-Interlocking project sinceits beginning, focused on its mainphases.I



to be the basis for further harmonisationwithin a following project proposed for thenear future titled: “Euro-Interlocking”.Indeed, the final report of the ERRI A 201

group contains in its Annexe A a proposalfor a follow-up project entitled “Euro-interlocking”.

The UIC “Euro-Interlocking”project

Preparation during 1998

In May 1998 a letter was sent to themember railways of the then Infrastructure

Commission inviting them to supportthe proposed new voluntary project Euro-Interlocking. It was also announced that ausers group (later called steering group)would be created and start its workimmediately, on a voluntary basis.

A Euro-Interlocking Project Proposal wasattached to this letter, stating amongstother things:1 “Introduction:… Nowadays an interlockinghas in general a connection with a control

centre and interfaces with the tracksideequipment as well as with an ATP system.With the introduction of ERTMS/ETCS theinterlocking will share its functionality withthe Radio Block Centre (RBC). In thecontextof the ETCS project, the assumption wasmade that the functionality of the RBCwould depend on national solutions.However, when considering the life cyclecosts and possible economic benefits ofexchangeable system modules it is alsonecessary to analyse and harmonise thefuture interconnection of interlockings and

radio blocks. This is of particular relevanceto moving block operations (ETCS level 3).”

1 “Objectives, expected benefits: … Asignificant reduction of costs will resultfrom the standardisation of interfaces,simplified and standardised functionalities,open procurement markets, cost and timesavings thanks to cross-acceptance of safetyvalidation and the use of standardisedinformation technology.…”

1 “Future way of working, cooperation withEU andindustry: … It seems highlydesirableto find ways of reducing in particular thetime until market penetration. Discussionswith EU/DGVII have been started which

could lead to close cooperation with thesignalling industry under the patronage ofthe EU Commission.“

In June, the UIC Infrastructure Commissiongave the project its go-ahead (with 15Railways interested in participating) and inOctober, the UIC Board of Managementformally approved the project.

Main period of work, from 1999 to2005

A project office for Euro-Interlocking wasestablished in Zürich (Switzerland). Thecore

team generally comprised up to 10 peopledrawn from a wide range of railwayinfrastructure companies or supplierindustries (see appendix for the list ofnames).Attempts to attract manufacturers to theproject in the summer of 1999 were oflimited success, as manufacturing industrywas not committed as an entity (UNISIG orUNIFE) until later in the project. However,several suppliers delegated representativesto the meetings and participated actively in

reviews. Representatives of the EuropeanCommission (DG TREN) were regularlyinformed about the progress of work.

The Euro-Interlocking work complied fullywith the CENELEC systems engineeringapproach for safety-related railway sub-systems. It concerned essentially the fourphases of the life-cycle process mainlyin theresponsibility of users: “Concept”, “SystemDefinition and Application Conditions”, “RiskAnalysis” and “System Requirements”.

In comparison to earlier projects, significantprogress has been made regarding the useof state-of-the-art formal methods andtools for requirements engineering. Theresults of Euro-Interlocking’s work havebeen systematically documented anddisseminated by means of Baseline CDs(current version is 8.0). Hereafter follows aselection of highlights.

• Business Case for InterlockingsAn initial business case study showed a

huge market demand for renewal ofinterlockings andtherefore alsoconsiderablepotential for cumulative cost savings. Moredetailed analysisand estimations werethenmade on theeffectof harmonised functional

requirements and on the standardisation ofinterfaces.

• SELRED guideline, Glossary of Terms,

Domain Knowledge/Context DiagramThese high-level requirementsanddocumentsensure a systemised and harmonisedworking base focussing on the StructuredEnglish Language for RequirementsDevelopment (SELRED).

• Data PreparationAn important area of work has been thestandardisation of methods and tools forthe task of data preparation. Indeed, inter-locking engineeringrequiresa huge amountof

data for the description of the individual localenvironment (track lay out) and the specificfunctionality required for each individualapplication. Proposals for correspondingmethods and tools were created usingLocation Data Files and Interlocking DataFiles. The XML standard was chosen as thedata exchange format. Pilot applicationsconfirmed that harmonisation in this areabrings significant cost reductions for theplanning and engineering of individualinterlockings.

• Hazard/Risk AnalysisThebackboneof thevalidationandverificationprocess in the CENELEC safety standard isthe hazard analysis (within phase 3). Therailways were required to develop a hazardlist for their railway system in relation to theproduct to be procured.A Hazard List Methodology managed inDOORS was developed in conjunction withBraunschweig University. This list is linkedto the functional requirements. Thismethod has been further developed and a

study conducted to measure the existingsystem risk levels.

• Qualitative RequirementsMore than 30 non-functional requirementswere drafted to define values for reliability,safety and performance, environmentalconditions and electromagnetic compatibility(EMC). They concern the whole life cycleof an interlocking from installation to dis-assembling and include guidelines forfuture solutions.

• Functional Requirement Descriptionusing DOORSAnother of Euro-Interlocking’s tasks wasthe tagging of the functional requirements

09EUR -INTERLOCKING

111



of thevariousparticipating railways by meansof the DOORS requirements managementtool. To this end, the functionalities wereallocated to generic “blocks of minimum

size corresponding to a single function”. Acommon functional frame structure withstandardisedrequirementstemplates, syntaxrules, glossary for functions, commandsand statuses enables the details of nationalsets of requirements to be presented in asingle, transparent format. The FunctionalRequirementDomainKnowledgethuscontainsinformation regarding all the various modulesandconcepts:thegeneral interlocking system,route, point, signal, lockable and detectiondevices, powered moveable elements, track

vacancy proving systems, line block, levelcrossing, local shunting area, command andstatus.

• Preliminary to create a commonfunctional coreThe next step in the process was to create abroadcommon European or even globalcoreoutof thevariousnational sets of interlockingfunctions. Two opposing objectives therebyhad to be reconciled: ideally, the commoncore should contain only the basic minimal

functions required to operate rail traffic- onthe other hand it also needed to include ahigh percentage of individual nationalrequirements for each railway. This wasessentiallyachievedby extending thecommoncore to include certain functions notused byall railways, and by minimising theindividualfunctions. For functions to be added,even ifredundant and not used by some railways,these functions had to be used by manyrailways and/or had to enable a reduction inthe complexity of traffic operations. Toharmonise individual functions (and move

them to the CC or remove them), thesefunctions had to have existing alternativesand/or it had to be possible to harmonisethem in an ERTMS environment.

• Simulation and modelling of functionalrequirementsThe Euro-Interlocking project broke newground by developing a lucid methodenabling functionality to be captured,described and modelled independently fromits practical implementation. The aimof the

modelling style was to create a syntaxwhich was as close as possible to naturalEnglish, though which also maintained itsown formal features, and also to ensurethat the model itself did not add to the

difficulty of seeing the desired functionalitybehind it. In addition, by enabling therequirements model to be simulatedwiththetrack and route data from any given layout, it

was clear that it was really a generic modeland not layout-specific.

The model focused on the logical conceptlayer and the hardware abstraction layer ofthe interlocking context diagram. TheUnified Modelling Language (UML) wasused, drawing a distinction between aHardware Abstraction Layer (HAL) for phys-ical elements and the sending of steeringvalues, and a Logical Concepts Layer (LCL)for high level concepts and processing

commands and for issuing statuses.

Theprocess enabled thespecifiedfunctiona-lity for an individual interlocking applicationto be shown und tested by means of user-friendly Graphical User Interfaces for eachspecific national configuration.

Restructuring the Euro-Interlockingproject with a view to a further jointproject between European railways

and manufacturersIn spring 2005, the group of signallingsuppliers within UNIFE and UIC agreed toinitiate a new joint activity for the harmoni-sation and re-engineering of signalling andinterlockings inthecontext of a newfollow-upEuropean research and developmentproject.With this in mind, Euro-Interlocking’s workwas reviewed and the project structureadapted to secure the knowledge of theproject and ensure optimum support for thepreparation of the new project. It was

decided to postpone work on theinterlockingsystem architecture and interfaces (afeasibility study on “European SignallingInterface Specification (ESIS)” did notobtain the support of manufacturers). Froman administrative point of view, it wasdecided to close the project office in Zürichby mid-2006 and to transfer the core partof the IT platform with the associatedsoftware licences (DOORS, Artisan) to UICheadquarters in Paris. By the end ofSeptember the Euro-Interlocking project

had been restructured accordingly.

During 2006 and 2007, the Euro-Interlocking Project Director activelysupported the preparatory group for the

new European research and developmentproject, which the manufacturer projectpartners proposed calling INESS (IntegratedEuropean Signalling System). To this end,

UIC and UNIFE approved a “ProjectDeclaration for the joint continuation of theEuro-Interlocking Project”. In late 2006 theformal EC call for the 7th FrameworkProgramme for Research and Developmentwas issued, including thetopic of “DeliveringERTMS-compliant interlockings”. The workwas expected to include:

1 The definition of a common core of func-tionalities, withagreementbetween railwaysand signalling suppliers on shared allocation

of functionstosubsystems and/or toadjacentsystems suchas trafficmanagement systemsof radio block centres.1 Interfaces to be standardisedin areas withpotential for significant economic benefit (tobe justified by a cost/benefit analysis).1 Common procedures for the safety casefacilitating cross-acceptance as well asmethods and tools for data preparation.

In close cooperation with the signallingindustry and with the support of the spe-

cialised ALMA Consulting Group, the pro-posal for the INESS project was drawn up inline with the specific rules and submitted tothe EC in good time (mid-2007).

Examples of successfulapplications of Euro-Interlocking specifications

At all stages of the Euro-Interlockingproject, theresultshavebeen used by somerailways for procurements, as illustrated by

the following examples.

Austria ÖBBThe Austrian railways have been pioneers,especially in the development and earlyapplication of the standardised tools andmethods fordatapreparation. Theyundertookverification and validation of the dataexchange process based on real projectstogether with their suppliers, and demon-strated that engineering costs could beeffectively lowered.

Denmark BDIn 2005 the qualitative requirements wereused in the tender for a new interlockingsystemin Ringsted (medium to large station

10 FOCUS



11EUR -INTERLOCKING

INESS is becoming of the highest relevance

at present, because the TSI on Command/Control/Signalling for Conventional Railprovides for the rollout of ERTMS oninternational TEN corridors covering ini-tial inception kernels.The European Commission, the Europeanrailway associations and the railway sup-ply industry have agreed to cooperateclosely to define a feasible migrationstrategy for ERTMS. This unique coopera-tive arrangement has enabled coordina-tion of the implementation of the current

constituent parts of ERTMS. It is thusbecoming increasingly evident that thisprocess could be hampered by the lack ofstandardisation in the signalling layer.INESS is therefore urgently needed tosupport the development of a new gen-eration of interlocking systems with opti-mally-unified interfaces to adjacent sub-systems such as remote control, neigh-bour interlocking, outdoor equipment andin particular ETCS.

Preparation work forINESS conducted with theEuro-Interlocking project

The railways, led by UIC, understand andfully support that the INESS in terms ofits form is a self manageing project to beexecuted according to the relevant EUrules. It is also clear that the signallingand interlocking system is highly safe-ty-critical and must be engineeredaccording to the CENELEC norms 50126

in line with the various life cycle phasesas shown in the following figure.

Essentially for the phases 1-4 in the upper

part, which are the responsibility of theusers, UIC and the Euro-Interlocking projecthave made considerable efforts to analysethe needs of the various railways and devel-op harmonised and consensual approachesusing state-of-the-art methods for require-ment engineering and modelling as well asfor data preparation.

The Euro-Interlocking project deliverablesare documented in a CD ROM version8.0… which is available to INESS project

members. UIC, on behalf of its memberrailways, hopes that this contribution willsupport and accelerate the work of theINESS project, which essentially coverswith all phases of the life cycle.

Thesis regarding systemrequirements andarchitecture

One major challenge for the INESS project

and its partner railways and suppliers willbe to agree on and draw up unifiedrequirements and structures for thesystem architecture. In this field, theEuro-Interlocking project has achievedonly preliminary results, due amongstother things to the fact that the supplyindustry as a whole did not fully partici-pate in this work. Also, the relationshipwith ETCS at its three application levelshasnot yet been fully taken into account.The following considerations are intend-ed as an initial contribution and input for

a broader examination of the systemaspects within the INESS project.

RAT THE THRESHOLD FROMTHE EURO-INTERLOCKING PROJECT TO THE INESS PROJECT(CONTINUED FROM PAGE 1)

Life cycle phases defined by CENELECfor the engineering of railway safety systems

area). They concerned mainly the sectionsregarding documentation,EMC,performanceand recorders (juridical and diagnostics).

Finland RHKThe Euro-Interlocking specifications havebeen used twice. The first case was the pro-curement for the Kerava-Lahti line with 5interlockings in 2003. In this procurementBaseline 7.0 was used. The line was com-missioned in March 2006. The second casewas the procurement for the Lahti-Luumäkiline with 9 interlockings in 2007. In this caseBaseline 7.2 was used, with new functionalrequirements included. It will be commis-sioned in summer 2009.

France RFF/SNCFRFF hasasked SNCF to prepare requirementsfor a call for tender for interlocking systemsbased on the Euro-Interlocking qualitativerequirements. Three contracts (THALES,ANSALDO and ALSTOM) were signed byRFF in late 2005 to procure PAI 2006 inter-locking systems for10 years.The developmentof these systems by the 3 suppliers is inprogress. The safety process is wellengaged. The first PAI 2006 built by

THALES (PIPC 2006)will be placedin servicein Longueau (near Amiens) in 2009, thefirstone built by ANSLADO (SEI 2006) will beinstalled in Etaples (2010) and the first oneproduced by ALSTOM (SLOCK 2006) will beinstalled in 2011 in Perrigny (near Dijon).

Portugal REFERQualitative Requirements have beenapplied in REFER Technical Documentsand are used in the preparatory phase oftheir ERTMS Plan tendering process; theremaining Requirements Documents (EI

functional and interface requirements) arebeing gradually migrated to the status ofREFER Technical Documents.

The Netherlands ProRailThe Euro-Interlocking standards of Baseline7 have been used as the basis of a newframework contract for the procurement ofinterlocking systems on the Dutch networkwhich was signed in mid-2003.

Switzerland SBB

The previous version of Baseline 6.0 (May2002) was used as the basis for the SBBNew Industry Partnership (NIP) procure-ment framework contract for a 7–yearperiod.

111



12 FOCUS

U I C C o m m u n

i c a t i o n

/ D

. T e s s

è d r e –

E m p r e

i n t e G r a p

h i q u e -

2 0 0 8

Peter Winter Project Manager [email protected]

Khalid Agrou Simulation & Modelling [email protected]

Florian Lesné Requirements Engineering [email protected]

Ilkka Herttua Data Preparation [email protected]

Crispin de Courcey-Bayley Simulation & Modelling [email protected]

Mirko Blazic Functional Requirements [email protected]

Paolo de Cicco ERTMS Platform Coordinator [email protected]

Françoise El Alaoui ERTMS Platform Communications [email protected]

Helen Slaney Communications [email protected]

REURO-INTERLOCKING PROJECT

It is widely accepted that the INESS projecthas to consider ETCS as it is currentlyspecified andthat thenew unified structureof the signalling installations mustachieved an optimum fit with ETCS. Onemust be aware that the scope and theinterfaces of ETCS at trackside level varyconsiderably for the three application levels,as shown in the following figure. At level 1,essentially only Eurobalises are used forthe data transmission to the trains, whichare linked to the signals or interlockings

via LEUs. Lineside signals are generallyretained and block control is achieved inthe conventional manner by the interlock-ing, based on the information detected bytrack circuits or axle counters. At level 2,the transmission of variable data to thetrains is achieved by means of GSM-R.ETCS is enlarged by the Radio BlockCentre which basically delivers movementauthorities to the trains. Lineside signalsare no longer generally used. The RBC hasinterfaces to the interlocking as well as tothe remote control system. At level 3,

ETCS also fulfils the train positioning

functionality. To this end, the trains sendposition reports via GSM-R to the RBC.This redefines completely the scope ofblock control, which is no longer bound tothe devices verifying track section vacancy.Essentially, this opens the door for intro-ducing moving block control instead of thetraditional fixed block control.

The business case examination for the INESproject will most likely demonstrate thatsignalling installations, including the inter-

locking, must be upgradeable during theirlife cycle from lower to higher applicationlevel. This requires a corresponding functional

and architectural modularity. It is thereforesuggested to structure INESS similarly toETCS in three application levels, wherebylevel 3 is to be considered as target solution.

In the following figure, a level 0 is alsoadded which means according to the ETCSspecifications that the trackside is not(yet) fitted with ETCS. For each level, thefunctionalities should be apportioned tomodules in such a way that upwardsconversion during the life cycle is feasibleby deleting some modules withoutchanging the contents of the remainingmodules.

Outlook

Rail sector stakeholders are very satisfiedand grateful that the EC is supporting theINESS project with high priority. Thisproject has the potential to redefine andreengineer various key issues concerningERTMS trackside equipment which willenable full implementation of this newtechnology. The target solution, ETCS andINESS level 3 will bring about major evolutionin railway signalling and trafficmanagement.

UIC and its member railways will continueto work hard to ensure the success of thechallenge that is the INESS project.I

Functional architecture of ETCSand INESS at the three application levels

Modular structure of INESS adapted to the ETCS application levels