eur -interlocking focus - uic - international … · atthethresholdfromtheeuro-interlocking...

12
UNION INTERNATIONALE DES CHEMINS DE FER - INTERNATIONALER EISENBAHNVERBAND - INTERNATIONAL UNION OF RAILWAYS FOCUS 1 MAY 2008 1 EDITORIAL 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-7 Baseline 8.0 P. 7-8 History of the Euro-Interlocking project: 1999-2008 P. 8-11 1 CONTENTS 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 this domain 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, member of the Euro-Interlocking steering group and the INESS steering board INESS, an important milestone on the way from national signalling to European unification Since 1990, the European Union has promoted the reform of Rail Traffic Management under the ERTMS programme, which is driven by the need for interoperability, the opening of procurement markets, increased efficiency and harmonised safety levels across the European railway system. To date, extensive and successful efforts have been undertaken in the field of train control – ETCS – and train communication - GSM-R. In terms of the Traffic Management Layer, the Eur-Optirail project has developed solutions for intercon- necting the various national high-level traffic management IT systems. However, these European projects do not yet cover the signalling system and its main component, interlockings. Interlockings, including line block systems, are the traditional instrument in the signalling sub-system used to interconnect information on the status of elements and commands issued to various control devices. Over the decades, an evolution has taken place from manual to automated functioning, with a move from mechanical, electro- mechanical or relay-based systems to electronic computer-based technology. Extremely high safety and reliability levels have always been key requirements. In many European railway networks, there is a huge potential need for renewal of heritage signalling installations, including their interlockings. However, an economic analysis of several railways show that a renewal at current cost levels for planning, procurement and implementation is no longer affordable. The INESS project will bridge the divide as regards harmonised specifications within the ERTMS framework, as shown in the following figure, which outlines the functional structure of the Rail Traffic Management System (left) and the associated European projects (right). R AT THE THRESHOLD FROM THE EURO-INTERLOCKING PROJECT TO THE INESS PROJECT continued page 11 111 By Peter Winter UIC/SBB Consulting INESS in the ERTMS context

Upload: ngomien

Post on 18-Aug-2018

274 views

Category:

Documents


3 download

TRANSCRIPT

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

FOCUS1MAY 2008

1 EDITORIAL

At the threshold from the Euro-Interlockingproject to the INESS project P. 1; 11-12

Standardising functional requirementsfor Interlocking Systems P.2-3

A common format for graphical userinterface data P. 4

Railway perspective on requirementdevelopment P.4

Extending the testing environment forthe ULM Interlocking simulator P. 5-7

Baseline 8.0 P. 7-8

History of the Euro-Interlockingproject: 1999-2008 P. 8-11

1 CONTENTS

continued page 2 111

EUR -INTERLOCKING

DBNetzhas highexpectationsof the INESSproject

For DB Netz,the renewalof signallinginstallationsand their coreelement,interlockings,

is an issue of the highest importance.Technical and economic studies haveclearly shown that the traditionalprocedures and technical solutionswill not allow the assets in thisdomain to be maintained inacceptable condition. In order toguarantee a high quality network ofits current size, new cost-effectivemethods and technologies are vital.For this reason, the project “Neupro”which aims to reduce costs throughstandardisation and technicalinnovation has been launched atnational level.

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

INESS, an importantmilestone on the wayfrom national signallingto European unification

Since 1990, the European Union has promotedthe reform of Rail Traffic Management 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 traincommunication - 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 thesignalling sub-system used to interconnect

information on the status of elements andcommands issued to various control devices.Over the decades, an evolution has takenplace from manual to 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 for renewal of heritage signallinginstallations, including their interlockings.However, an economic analysis of severalrailways show that a renewal at currentcost 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 the functionalstructure of the Rail Traffic ManagementSystem (left) and the associated Europeanprojects (right).

RATTHETHRESHOLDFROMTHEEURO-INTERLOCKINGPROJECTTOTHE INESSPROJECT

continued page 11 111

By PeterWinter 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 termvision of generating a large common core 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 onthe current Euro-Interlocking results to realizeone of its major objectives - to define acommon kernel of standardised functionalitiesfor future interlockings, including functio-nalities specially required by ERTMS.

Functional requirements have been capturedand developed on a common platform,with the use of a standardised glossary,standardised commands and statuses aswell as standardised requirement structures.The requirements are written in Englishand are apportioned to individual railwaysthrough the process of tagging.

The environment for thiswork is the requirementsmanagement tool DOORS,which enables precise tra-cking, change managementand good traceability.The DOORS tool permitsthe identification andextraction of individualrailway requirements, aswell as of a common coreof requirements, whichconsists of shared requi-

rements of all participating railways. Acomplete database of requirements is set andregularly 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 tomanage 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. This has enabled direct compar-ison of requirements from various railways,and has given common understanding of therequirements for all railways and suppliers.

RSTANDARDISING FUNCTIONALREQUIREMENTSFOR INTERLOCKING SYSTEMS

02 FOCUS

Standardised commands in DOORS

In cooperation with the supplyindustry, some promising initial resultshave been achieved with respect tomore flexible, modular and scalablesystem architectures and innovativecooperation processes. The initial pilotprojects demonstrate that significantcost reductions can be achieved.

However, we at DB Netz are aware thatefforts at national level alone are notsufficient to achieve the necessaryturnaround in the area of signallingand interlocking. Pan-European oreven worldwide pre-competitivecooperation is a must in order to openup procurement markets. That is whywe have participated from the outsetin Euro-Interlocking work focussingon user-related issues in the field offunctional requirements and datapreparation. Over the last two years,we have actively influenced andsupported the initiation of the INESSproject together with colleagues fromother railway networks and from thesupply industry. We are convincedthat this joint undertaking betweenrailways, manufacturers anduniversities, backed by considerablefinancial support from the EC, willachieve the required breakthroughtowards state of the art processesfor the whole life cycle, and towardsfuture-oriented modular systemarchitectures in line with the variousETCS application levels.

DB Netz is keen to use the outcomesof the INESS project, and its precursorEuro-Interlocking, as soon as possiblein its strategy to modernise signallingand interlocking. This will contribute toswift and efficient implementation ofERTMS with its benefits for trans-European passenger and freight trainoperation. Let us collectively take upthis challenge for the benefit of thewhole rail sector and its customers! �

(continued)111

1 EDITORIAL

Functional requirements databasein DOORS

ByMirko Blazic

However, there are still many differences infunctions among the various railways.Main reason for this is individual historicaldevelopment by different suppliers. Eachhad developed a solution of their own, thathas only been built on over time. Thuscurrent interlocking system requirementscarry a lot of history – and still includefunctions that were once used to overcomelimits of the available technology (mechanical,electro-mechanical, relay...). Therefore acritical review is required to define a newstandard for future interlocking systems.

Common core of functionality

The envisioned process will involve developinga common core of functionality, which willbe followed by extending the core toinclude a wide array of required functions,needed by railways across Europe in orderto successfully operate their railway. Themost crucial part of the harmonisationprocess will require the omission of specialand historic functions from the interlockingsystems. These will be either removedentirely or harmonised and thus mergedinto the common core.

Extending the core will require that addi-tional functions are added to the commoncore, adding on to those that are commonto all railways. That means the extendedfunctions would not be used by all railways,and would be redundant in the system.Illustrative examples of such functions areshunting routes, overlaps or local shuntingareas. Many railways use such functions,but not all.

The criteria for selecting the extendingfunctions: the function must be used bymany railways, traffic operation wouldbecome too complex without such functions,

and functions lead to increase in availabilityand performance.

Extending the core will be successful if aconsensus is reached among the railwaysto accept the new functionality in theirsignalling systems, which may or may notbe used. Furthermore, the use of redundantfunctions, or even contradicting functions,which wouldn’t be used by all railways, hasto be resolved.

Minimising the individual functionswill requirethat some functions become harmonised andare thus moved into the common core, andthat special individual functions are removedcompletely. Examples for harmonising aremany various ways of blocking routes (allintended to prevent route setting). Forremoving individual functions, the functionfor removing power from points is a goodexample, as it is used mainly to preventpoint movement via power removal.

The criteria for selecting a function thatwould be harmonised and moved to thecore: the function is used by few railways andin a similar way, the function has existingalternatives which achieve the same result,the function can be harmonised in ERTMSenvironment.

The criteria for selecting a function whichshould be removed: the function compen-sates for the use of outdated or specialisedequipment, the function compensates for

outdated regulations, the function is notsafety relevant and can be moved toanother system, the function becomesredundant in ERTMS environment.Minimising the individual functions willsucceed if there is a possibility to changethe regulations which will enable the useof alternative functions. Alternativefunctionality should not lead to majorchanges in operation. A railway shouldhave the possibility to replace outdated orspecialised equipment.

Conclusion

With the INESS project, the resultingcommon core of functionality will probablybecome a standard for future interlockingsystems, and will provide - in combinationwith harmonised system architecture -open interfaces and full ETCS compatibilitythe basis for future signalling systems inEurope. All involved parties will have animportant role. Railways will have tocritically analyse their operations, omit theredundant and special functionality andadjust their operation and regulations tomatch the agreed future functionality. Thesignalling industry will have to providecreative solutions for the future signallingsystems, enabling modularity, versatilityand compatibility that will be required forbroad implementation at various levelsacross Europe. �

03EUR -INTERLOCKING

Extending andminimising the common core of functionality

Example of domain knowledge

The Human Machine Interface file format(HMIFF) has been developed in order toallow 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 toredraw 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-Interlocking and 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 providingmore automated ways to parameterise theinterlocking system. Already on the pilotproject year 2006, processing from theCAD-file to the programme of an interlockingsite happened almost automatically 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 isprovided 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. �

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-formalrequirements.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, resulting in 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 hugereplacement 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 smoother implementationof 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 has asked SNCF to prepare requirementsfor a call for tender 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 weconsider this tender very successful; it hasset the beginning of a new tenderingprocess with “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 phasewas launched in 2007 for the Lahti-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 ERTMSPlan - tendering process preparation phase;Progressive Migration of the remainingRequi-rements Documents (EI functionaland interface requirements) to TechnicalDocuments of REFER. �

RA COMMONFORMAT FORGRAPHICAL USER INTERFACE DATA

04 FOCUS

RRAILWAYPERSPECTIVE 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 the railways. 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 mostadministrations think that large 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 proves impossible to either abandonor popularise a function, to place them in anational subset. Regardless of whicheverprocess occurs, it remains important for eachrailway to be able to experience the 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 environment in which all functionalitycould be tested at least once. Now that therequirements database has grown to incorporatethefunctionalityofanumberofcountries,wefeelthat it is important that the testing 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 much easier not only to populatethe fixed layout with the necessary parametersfor differing railway’s use of it, but also to createentirely new railway layouts; thus enablingadministrations to better control their testing.Given the fact that the project aims to promotegeneric functional requirements, the expandedtesting environment has a third fortunateby-product, which is to enable the genericismof 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 interlockingconfiguration 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 pursue our goalincrementally 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 toenable it to receive data from differing sourcesand to display them accordingly.

Originally both the layout of the track elementsand the depiction of their statuses was‘hard-wired’ in the application, as our initialgoal was merely to be able to show simulatedinterlocking 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 configuration to the simulator, it seemedthe obvious choice to merely add the userinterface data (pixel position, orientationinformation etc.) to the spreadsheet. Thismeans that in addition to specifyingwhat kindof 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 should be sent to the simulator 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 onlycommands applicable to the railway under testwill 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 warninglights 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 on the panel 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 handlingandicon libraryaspectsofthemodular interfaceare now well-advanced, our suspicions havebeen confirmed that defining pixel positionsfor the layout interface via an Excel spreadsheetis a laborious process.In fact, it was only ever expected that usingExcel for this process would be a temporarysolution to enable us to verify that all thenecessary information had been identified andextracted from the old ‘hard-wired’ interfaceto enable the easy creation of new simulatorinterfaces.

Graphically-defined Layouts

The project is relying on the railways to performthe validation work of the requirements, asonly the national domain experts can confirmif the captured functionality is correct. Tomaximisethechancesofsuccess, 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 weareadamantthattheexchangeof informationat 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 todrive the simulator from the old interface, ouraim was to migrate it to a format whichwould enable as much of it as is sensible tobe 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 be used to populate the parametric valuesfor the track element to be displayed. In otherwords, when choosing where to place a set ofpoints on the interface, it would be 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 the drop-down menuand placing them appropriately on the layout.The usability is such that level crossings canbe extended to cover multiple tracks andpoints and signals can be 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 the ability to couple shunt and main signalsthat 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. The naming conventions forall trackelementsarefree,as is thepositioningof 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 railwayprovides 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-tion timer, fouling TVP, 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. Thisnow 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 genericapplication has been loaded, different layoutscan be hot-swapped, thus enabling thegenericism of the model to work on differentspecific applications to be verified. This willprobably also lead to the creation of a numberof test layouts by each railway, each of whichis designed to enable validation of the modelin a particular area of the requirements.

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 the field are bro-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 inputs from these objects are available,it was imperative to model them.

06 FOCUS

RouteConfiguration

HardwareConfiguration

InterfaceConfiguration

Graphical Editor

Conclusions

All of this work has been undertaken with theintention of simplifying the procedure forincreasing the compatibility of functionalrequirements between the European railways.With the conclusion of a graphically-drivendata preparation tool the project has nowreached an important milestone, wherebyboth the input of data to the interlocking andthe testing of the simulated interlocking canbe done graphically. More advances could stillbe made, especially in the area of automatedtesting, but before the project moves on, itwould be best to await the railway’s feed-back as to what to do next. �

07EUR -INTERLOCKING

RBASELINE8.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 mostrecent 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-cate the project’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.Version 8.0 willbe the last oneissued withinthe context ofEuro-Interlocking,which will bereplaced by theINESS project at theend of this year.Baseline 8.0 was definedfollowing 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 classifiedby 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 not

been 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, studies on standardisa-tion in 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 theEuro-Interlocking database”: a documentdescribing the contents and the structureof the database, and how to use itappropriately. 111

RHISTORYOF 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 ResearchInstitute 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 the world’srailway signalling systems, but theirdevelopment has never been consistent.Principles in different railway administrationshave emerged separately through theinterplay of tradition and evolution. …

Certainly, it is perceived that the majority ofinterlocking 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 the change broughtabout by privatisation and the broadeningof supplier bases. …”

1 “Results and benefits: The main aimbehind the work of A 201 was to realisepotential 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 “Common Core” 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, theNetherlands, 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.

1 Modelling 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. �

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 201group 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 InfrastructureCommission 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 controlcentre 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 the contextof 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 andradio 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 and industry: … It seems highly desirableto 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). The coreteam 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 inreviews. 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 mainly in 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 ahuge market demand for renewal ofinterlockings and therefore also considerablepotential for cumulative cost savings. Moredetailed analysis and estimations were thenmade on the effect of harmonised functional

requirements and on the standardisation ofinterfaces.

• SELRED guideline, Glossary of Terms,Domain Knowledge/Context DiagramThese high-level requirements and documentsensure 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 engineering requires a huge amount ofdata 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 AnalysisThe backbone of the validation and verificationprocess 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 astudy 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 the various participating railways by meansof the DOORS requirements managementtool. To this end, the functionalities wereallocated to generic “blocks of minimumsize corresponding to a single function”. Acommon functional frame structure withstandardised requirements templates, 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 modulesand concepts: the general interlocking system,route, point, signal, lockable and detectiondevices, powered moveable elements, trackvacancy proving systems, line block, levelcrossing, local shunting area, command andstatus.

• Preliminary to create a commonfunctional coreThe next step in the process was to create abroad common European or even global coreout of the various national sets of interlockingfunctions. Two opposing objectives therebyhad to be reconciled: ideally, the commoncore should contain only the basic minimalfunctions required to operate rail traffic- onthe other hand it also needed to include ahigh percentage of individual nationalrequirements for each railway. This wasessentially achieved by extending the commoncore to include certain functions not used byall railways, and by minimising the individualfunctions. 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 movethem 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 aim of themodelling 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 simulated with thetrack and route data from any given layout, itwas 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 processingcommands and for issuing statuses.

The process enabled the specified functiona-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 railwaysandmanufacturers

In 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 in the context of a new follow-upEuropean research and development project.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 wasdecided to postpone work on the interlockingsystem 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 projecthad 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 the topic of “DeliveringERTMS-compliant interlockings”. The workwas expected to include:

1 The definition of a common core of func-tionalities, with agreement between railwaysand signalling suppliers on shared allocationof functions to subsystems and/or to adjacentsystems such as traffic management systemsof radio block centres.1 Interfaces to be standardised in 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, the results have been used by somerailways for procurements, as illustrated bythe following examples.

Austria ÖBBThe Austrian railways have been pioneers,especially in the development and earlyapplication of the standardised tools andmethods for data preparation. They undertookverification 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 interlockingsystem in Ringsted (medium to large station

10 FOCUS

11EUR -INTERLOCKING

INESS is becoming of the highest relevanceat 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 currentconstituent 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 50126in line with the various life cycle phasesas shown in the following figure.

Essentially for the phases 1-4 in the upperpart, 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 projectmembers. 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 projectand 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 levelshas not yet been fully taken into account.The following considerations are intend-ed as an initial contribution and input fora broader examination of the systemaspects within the INESS project.

RATTHETHRESHOLDFROMTHEEURO-INTERLOCKINGPROJECTTOTHE INESSPROJECT(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 has asked 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 for 10 years. The developmentof these systems by the 3 suppliers is inprogress. The safety process is wellengaged. The first PAI 2006 built byTHALES (PIPC 2006) will be placed in servicein Longueau (near Amiens) in 2009, the firstone 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 (EIfunctional 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 SBBThe 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

UIC

Com

mun

icat

ion

/D.

Tess

èdre

–Em

prei

nte

Grap

hiqu

e-2

008

PeterWinter 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 and that the new 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 interlockingsvia 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 traffic management.UIC and its member railways will continueto work hard to ensure the success of thechallenge that is the INESS project. �

Functional architecture of ETCSand INESS at the three application levels

Modular structure of INESS adapted to the ETCS application levels