INtegrated European Signalling System

Final Report Summary - INESS (INtegrated European Signalling System)

Executive Summary:
Since 1990, the European Commission, the European Railway Associations together with the Railway Supply Industries have agreed to work closely together to define a feasible migration strategy for ERTMS (European Rail Traffic Management System). Basically, ERTMS has been intended by the EU to create a European standard for railway signalling in order to allow cross-border interoperability.

The unique co-operation has offered the possibility to co-ordinate the implementation of the current constituent parts of ERTMS and from there it is becoming more and more evident that this process could be hampered by the lack of standardization of the signalling layer.

INESS has been a unique opportunity to bring together railways and signalling industry to develop specifications for a new generation of interlocking systems with its surrounding interfaces, and to extend and enhance the standardization process according to current European policies.

The project concentrated on research issues that contribute to the reduction of the Life Cycle cost (LCC) of signalling systems. The main objective of INESS has been to define and develop specifications for a new generation of interlocking with its surrounding interfaces in line with the relevant European norms addressing railway operation and safety systems to facilitate and foster the ERTMS rollout.

To reach this objective, INESS has incorporated the best State of the Art practises and projects in place in its development strategy. This was done for each Work streams and helped to foster the production of results to an exploitable state.

The approach taken to tackle this challenging goal is based on a joint technical and economical (business) approach that clusters the main activities of the CENELEC V cycle in INESS ones. In that context, the INESS consortium has defined a workflow of 8 Work streams as represented in the following picture:
The main research activities of INESS have been carried out in 6 subprojects called work streams (WS) B to G. Aside from those work streams, WS A and H ensured management, dissemination and exploitation of the project and project results.
WS D “Generic requirements”, WS E “Functional architecture and interfaces”, WS C “System design” and WS F “Testing & Commissioning” activities closely follow the CENELEC V-cycle.
Each of those WS are tightly interconnected.
WS D specified the INESS interlocking common kernel requirements (the WHAT functionality should such a system perform) using some of the results from a predecessor project named Eurointerlocking. In parallel, WS D has developed innovative methods for validation and verification of the INESS Kernel. Those methods could be applied to any other safety related system.
Based on the INESS interlocking kernel, WS E realised the functional apportionment to the considered subsystem and fed back valuable functional improvements to the kernel.
WS C had to define the HOW should the system be implemented. When trying to tackle this issue, it was decided not to reinvent a conventional interlocking that would have added some non-harmonised interfaces. Instead WS C was to provide a European harmonised data model, based on the INESS kernel from WS D and system architecture (and interfaces) from WS E . This data model will allow the transferring of railway data to the supplier in order to configure an INESS interlocking specific application. The data model that WS C specified is also called EUDRI (European Unified Description of Railway Infrastructure).
It was decided in INESS to capture the requirements in a manner that allowed them to be tested as requirements rather than only once the specified system had been implemented. This meant that the quality of the requirements could be improved and that input could be made to the later testing at the system level. It was the angle stone of WS F which developed a handbook on best practices for testing an interlocking and made recommendations for testing the INESS common kernel from WS D.

Aside from those 4 work streams, WS B constituted the Business component of the project as they evaluated the economic impacts of each work streams activities and drew out a cost efficient business and cooperation plan for supporting migration with INESS interlocking.
From his experience on safety related standards and on a complete formal modelling of the CENELEC 50126, 50128 and 50129 norms, WS G developed an open source support tool called INESS GSN (Goal Structuring Notation) Tool that allows reducing time and money for the safety case of any signalling project. The cost reduction expected form the use of the tool has been estimated up to 1% of the whole Life Cycle Cost (LCC) of the system.

The main outcome of INESS is a complete specification and tool suite directly exploitable for the implementation of an INESS interlocking prototype. It is a matter of the INESS consortium to decide how they will further apply its implementation. The short term agreement consists in elaborating a Technical Recommendation (Tec Rec) as a preliminary step to a TSI in order to later legally enforce INESS interlocking kernel with its interfaces as an “interoperability constituent”.

Besides that further step, all the foreground (software, databases and methodologies) developed in each work stream can be directly exploited. A summary is presented in the following table. The details can be consulted in the INESS plan for use of the foreground.

Main exploitable foreground Use Expected impact
INESS LCC model Specify a system and evaluate cost impact of each phases Common understanding of the business needs
INESS business model Simulate ERTMS migrations with or without INESS IxL’s Understanding the economic rationale and needs for ERTMS and non ERTMS migrations
INESS data model (EUDRI) Used for tendering a specific INESS compliant IxL Diminution of time needed to configure a specific IxL.
Cost reduction due to reduction of number of tools and interfaces
INESS unified glossary of terms Reference dictionary for signaling projects with or without databases Allowing the correct interpretation of terms and fostering harmonization of the signaling layer
INESS IxL common kernel of requirements Used in tendering a INESS generic IxL system Faster tenders suitable to the national requirements
INESS common kernel model Can be used to build an INESS IxL simulator or real INESS IxL and to automatically generate conformity tests cases Reduced development cost due to more exact specification
INESS V&V methods and tool chain Used to verify the IxL model and that the common kernel is consistent and complete Improve the quality of the models and their related specification
INESS system architecture and interfaces Specify interfaces between INESS IxL and all its surrounding subsystems Allow interoperability between various suppliers systems and INESS IxL
INESS IxL-RBC; IxL-IxL and IxL-CLC FFFIS Can be used to fully specify systems in conformity with the interfaces specifications Reduce CAPEX of suppliers for building an INESS IXL making them more competitive on the market
INESS fallback and migration reports To offer advice to the railways on their decisions on migration and fallback systems To realize intelligent and cost efficient migration decisions
INESS T&C handbook and product conformity To identify optimized and cost efficient testing methods applicable to any electronic interlocking system To reduce cost of testing by applying industrial methods (by moving testing from on-site to the factory)
Safety Case Process EPC model To model the CENELEC EN 5012x To guarantee a common understanding of the CENELEC EN 5012x
Safety Case Process tool (GSN tool) To support Safety case management in signalling projects To harmonize and foster safety cases of various signalling projects. Collection of key information in databases is supported.

Table 1: INESS exploitation and impact table
As INESS constitutes a huge signalling project of about the size and dimension of ETCS and due to its complexity, it is almost impossible to acquaint all the 100 deliverables, and more over databases and tools. Therefore, the UIC decided to produce a Concluding Technical Report (CTR) who will be a publically available document, which describe in a more easy to understand way the content and outcomes of each work streams. In addition, all the databases, tools and guidelines will be configured and maintained at the UIC and will be accessible (during a period of 5 years at least) and when necessary upgradable in accordance with their dissemination levels.

Project Context and Objectives:
4.1.2.1 Current European Framework for the Rail Industry

The railway industries throughout Europe face increasing competition with other modes of transport and with other manufacturers from Asia and Russia. They are therefore under constant pressure for cost-effective operations.

To find a way out of such a situation, the European Commission announced a set of new proposals to revitalise the rail transport. Top priority is to deal with the problems concerning the lack of infrastructure and of interoperability between networks and systems.

Moreover, the railway operators agreed on a Joint Strategy for European Rail Research 2020 Towards a single European railway system. In this document signed by the International Union of Railways (UIC), the Community of European Railways (CER), the International Union of Public Transport (UIPT) and the Union of European Railway Industries (UNIFE), the rail stakeholders agree on a number of ambitious objectives, to be achieved by 2020. Particular attention has been paid to a critical part of the overall rail system: the signalling system which is highly relevant for the performance and the safety of train operations.

4.1.2.2 Railway signalling systems transiting from traditional national solutions towards ERTMS compliance

Today there are more than 20 rail signalling and speed-control systems operating in Europe, all of which are completely incompatible with each other. This complexity leads to additional costs and increased risk of breakdowns. Promoted by the European Commission and driven by the need for interoperability, opening of procurement markets, increase of efficiency and harmonising of safety in the European railway system, the European Rail Traffic Management System (ERTMS) aims to remedy this lack of unification in the areas signalling and speed control.

The convergence of the ERTMS vision in the railway sector, with the accompanying European Train Control System (ETCS) and Global System for Mobile Communications – Railways (GSM-R) standards, has brought about a degree of cross border co-operation not previously seen. Railway Operators and Infrastructure Managers are now engaging with a united supply industry to achieve the common goal of an interoperable system, within the framework of European legislation, which potentially forms a set of legal obligations everybody has to comply with. A set of standards has been created within these obligations but, as with any standardisation process, joint efforts are needed from all parties to translate such work into tangible results.

Furthermore, the new Technical Specifications for Interoperability (TSI) related to Command/ Control/Signalling for Conventional Rail foresees that ERTMS will be rolled out over international corridors covering initial inception kernels (as well as on many other projects outside these kernels). The European Commission, the European Railway Associations together with the Railway Supply Industry have agreed to work closely together to define a realisable migration strategy for ERTMS. This unique co-operation has offered the possibility to co-ordinate the implementation of the constituent parts of ERTMS - the traffic-management layer, the train communication and train control system.
Further momentum can be added to this process by ensuring that the most significant sub-systems of railway command and control systems, such as interlockings are developed in line with this programme.
4.1.2.3 The importance of interlockings: Huge potential market for new interlockings

In many European railway networks, there is a huge need for renewal of heritage signalling installations and the interlockings on which they depend. However, economical analyses of several railways show that a renewal at current cost levels is becoming increasingly more difficult to justify in cost-benefit terms.

One important method for reducing the costs of signalling renewal is considered to be the introduction of a greater degree of standardisation, both in terms of determining the functionality of signalling systems, and in terms of enabling a more modular approach to the various parts of the signalling subsystems and enabling renewals to better take into account the differences in the life expectancy of the various in- and outdoor devices including cabling, point operating equipment etc.

For this reason, both UIC and UNIFE consider that it is now opportune to address these aspects within the context of the present INESS project.

The INESS project aims at contributing to the above mentioned European initiatives by defining and developing specifications for a new generation of interoperable interlocking systems suitable to be integrated in ERTMS systems, with the objective of making the migration to ERTMS more cost-effective. This approach is believed to have the potential to reduce costs, speed up the migration to ERTMS and therefore, help increasing the competitiveness of the railway transport.

Railway Operators, Infrastructure Managers and the signalling supply industry agree that the key scope of the INESS project should be exploring and standardising the interfaces between interlocking systems and the adjoining command and control sub-systems such as centralised traffic control, neighbouring interlockings, ETCS Radio-block centres and possibly - depending on the economic justification - outdoor devices.

4.1.2.4 INESS Main Objectives

The INESS project defined and developed specifications for a new generation of interlocking systems, and thus extended and enhanced the standardisation process according to the current European policies. It further lead to industry being more directly involved with Infrastructure Managers in developing innovative solutions for the future based on an enhanced and common understanding of the operational requirements that need to be delivered into the railway transportation system.

The main scientific and technological objectives of the INESS project were the following:

- To define a common kernel of validated standardised functionalities for future interlockings, including functionalities specially required by ERTMS and which will support the common operational requirements of the various railways.

- To define standardised and optimised methods and tools for requirements management and for verification and validation.

- To propose one or more standardised system architecture(s) and to specify the relevant interfaces between the interlocking and the adjacent subsystems.

- To develop a harmonised data file format and implementation of data flows compatible with supply industry design tools, enabling data transfer for description of railway infrastructure layouts linked with INESS system architecture (The Unified European Railway Infrastructures data model - EUDRI)

- To develop a common business model and the associated business cases and cooperation models to support intelligent migration strategies for ERTMS and therefore to accelerate the realization of European ETCS corridors and to realize cost reductions within the entire supply chain.

- To develop a road map (exploitation plan) towards interoperable, standardised interlocking platforms.

- To develop practical cost efficient methods and processes for testing & commissioning Interlockings and trial one or several methodologies to INESS.

- To identify an efficient way for an interpretation of the safety case process according to the relevant CENELEC standard and to develop improvement strategies coherent with the yet to be harmonised requirements of the various National Safety Authorities thus reducing time and money for the Safety Case in industry by avoiding unnecessary or redundant procedures. This activity has the potential to lead, in addition, to the facilitation of the development of a harmonised approach by all such authorities.

Project Results:
4.1.3.1 Work stream B: Business model: In a first step work stream B developed a Life Cycle Costing model (LCC-model), consisting of the three dimensions life cycle phases, product structure and cost categories (see figure 3). Based on this model a template has been set up which has been used to collect all relevant information at each partner side. As a result of this Europe-wide data collection, data in terms of cost figures have been collected. These data have been analysed afterwards and common cost drivers of an interlocking system were identified. These results provided an overview of where cost reduction potentials within the overall life cycle might exist. In addition, it was possible to give definitions for Signalling Equipment Units (SEU) and to set the identified costs in relation to the SEU. Furthermore, market segments have been defined so that the identified costs per SEU could be allocated to a specific market segment.
Based on the results of the data analysis the question has been raised if the working results of the technical work streams will lead to cost reduction potentials within the entire life cycle. To answer this question the results of the data analysis was further analysed within work stream B. As a result it was possible to set the identified cost reduction potentials in relation to the LCC-model and to the identified key cost driver. The interaction between work stream B and the technical work stream provided an important input for the development of a Business Model which helped to identify and evaluate cost reduction potentials in the entire life cycle of an interlocking and hence support intelligent migration strategies for ERTMS.
Due to the fact that the cost reduction potentials have to provide a benefit for the railway as well as for the industry the INESS Business Model had the obligation to consider all relevant parameters and their interrelationships of both market sides. Based on the different results achieved during the last three years work stream B has constructed two different models reflecting two different perspectives. The first model tries to picture the reality of the signalling market by integrating parameters which are based on the individual market experience of the Work stream partners (green field model). The second model implements company ratios and uses already proven parameters which are based on the experience of one Railway Company (brown field model). Both models provide a basis for a simulation of the market specific mechanisms and thus lead to a better understanding of the European signalling market. In addition to the INESS Business models a cooperation plan has been developed that describes how common standards can be established within a complex market and which conditions need to be fulfilled in order to reach that objective.
The INESS business model has been documented with the use of the VenSim tool (see Figure 4). Aside from visualization of the interdependencies, this tool also provides functionality to simulate the model. This makes it possible, for example, to change one of the parameters and then view how all the other parameters react.
4.1.3.2 Work stream C: System Design
INESS work stream C created a European Unified Data Model for Railway Infrastructures (EUDRI) for the data flow into an interlocking system. EUDRI is a harmonized data model compatible with existing design and interlocking configuration tools, enabling data transfer for invitation of tenders, production and implementation of an INESS compliant interlocking, thus supporting the data flows linked with the INESS system architecture. The contained data can also be used to maximise the knowledge base of owned assets within the railway infrastructure.
The EUDRI data model contains all objects relevant for an ERTMS compliant interlocking, which includes legacy areas like signals, points, and tracks, as well as infrastructure areas like length of tracks, gradients, positions. EUDRI has a backbone functionality, that means it links railways to suppliers (used in bids and contracts) and back (informing the railway about the installed assets) and even can link railways across borders by unified concepts. EUDRI uses open standards based on XML, enabling the use of most existing databases to export, share and import data in EUDRI format.
As there was no existing data model that served INESS’ needs, a list of requirements (an extract from the list of requirements is showed in figure 6 for the data model was collected. Then, after a thorough comparison of a multitude of different data models that are used in the railway sector, RailML was chosen as the best fitting data model. As RailML does not fulfil all requirements, a list of known gaps was created and the requirements were put to trial by suppliers and railway companies. The result of this is a very precise list of gaps and a verification of the work done so far, usable to implement the missing parts of the data model as needed. One important aspect concerning the future use of the RailML data model is maintenance. As mentioned before, it is important that the data model, except of being “standard”, also is used and maintained by independent organizations and institutes. RailML has the advantage of being already in industrial use, supported and developed by independent businesses and institutions from various European countries. This provides the highest potential concerning the exploitability of RailML.
Main aspects for further technical development and implementation of the RailML data model have been described in Section 6 of the report of work stream C.
As the data currently used to describe interlockings by usage or standards is defined by the railway infrastructure managers, it is up to them to keep their existing interface (whether it is on paper or already a national or railway specific data model) or to use an international or at least European standard. If they decide to use EUDRI, the benefit would be:
- A wider scope of tools, even from different markets, that can be used to build the interlocking description,
- a faster reaction on tenders,
- a faster implementation of interlockings,
- less mistakes in the implementation of interlockings,
- therefore reduced costs for tenders and implementation,
- better quality of data describing the used assets, and
- therefore reduced costs for maintenance.
All this can be achieved mainly because the suppliers do not need to rewrite the interlocking description in order to get it into their tools for calculation and implementation, and railway infrastructure managers do not need to rewrite the description of the assets used by the new interlocking to get those assets into their maintenance tools. It is up to the railway infrastructure managers to start using EUDRI and claiming the benefits.
4.1.3.3 Work stream D: Generic requirements
The main results for work stream D are:
- Definition of a common kernel of validated standardized functionalities for future interlockings, including functionalities specially required by ERTMS Level 1 and level 2, which will support the common operational requirements of the various railways.
- An executable model of the INESS interlocking kernel.
- Definition and usage of standardized and optimized methods and tools for requirements management and for verification and validation.
This work stream was mainly related to the first 4 phases of the CENELEC life cycle.
The Common Kernel consists of the former Euro-Interlocking model, extended by requirements concerning railways not yet covered. The total resulting number of requirements is about 1000. The operational rules that are related to the common kernel of functional requirements can be directly related to these requirements, and these can be identified by the users. The related requirements on their turn are part of the entire set of national rules. An extract of the common kernel database id showed in figure 7 hereafter.
The experience from railways and industry was collected to compose ERTMS (level 1 and 2) requirements for interlockings. The requirements are consistent with existing associated ERTMS operational rules and scenarios. The combination of both functional and operational issues was considered and a link was established between the INESS requirements and the already existing ERTMS operational rules (the operational rules themselves are not in the scope of INESS). This has led to a new extension of the set of requirements. In order to gain a significant improvement of the requirements, the common kernel has been translated in a (semi-)formal xUML model. This model is suitable as input for verification and validation activities of the requirements, but also for simulating real interlockings to facilitate the building of INESS interlockings. However, the biggest impact of the model came through the process of modelling itself, in which many gaps and ambiguities in the requirements could be found and corrected. An example screenshot of some of the translated requirements into xUML language is illustrated in figure 8. The impact of the modelling is showed in figure 9.
In deriving the set of functional requirements the guidelines and environment have been created to standardize and optimise method and tools for requirements management. The work stream has delivered for this purpose a signalling glossary, a catalogue of commands and statuses, a document of functional interfaces between interlockings and a complete requirements database.
To be able to retrieve a common method and set of tools for verification and validation of the functional requirements, a strategy for the verification and validation of a functional specification has been drafted; a methodology for the derivation of safety invariants has been established and applied. This led to a collection of safety invariants suitable for formal verification, which has been reviewed by the railway experts. A methodology allowing the formal expression of test cases has also been defined and the work on deriving generic test cases is finalized.
Finally, a prototype tool for the formal verification of a functional specification including safety requirements by means of the model checking technique has been developed. The main results achieved are a list of railway-specific safety invariants, a formal test cases expression method and a complete tool chain for verifying xUML models. The verification toolchain is illustrated in figure 10.
These results have been used together to discover incompleteness, inconsistencies and incorrectness in the model and in the requirements. This has led to the detection and removal of many inconsistencies. The final result is the identification of flaws and inconsistencies in the specifications. The potential impact of the validation and verification activities was an improvement of the quality of the specifications: the first using traditional railway methods, the second using more sophisticated ones. The methods and tools developed can be used to verify other systems of the railway domain and the generic test cases can provide a basis for more harmonised way of performing functional tests.
4.1.3.4 Work stream E: Functional architecture & interfaces
The main results that were produced by work stream E are:
- An harmonized interlocking architecture.
- FFFIS (Functional Form Fit Interface Specification) specifications for the Interlocking-RBC, Interlocking-Interlocking and Interlocking – Centralized LEU controller (CLC) interfaces. The specifications are based on the common kernel of requirements developed in WS D. FFFIS IxL-RBC is made in textual language while IxL-LEU and IxL-IxL has been developed using model based methods (UML state machines and state diagrams)
- A fallback method for evaluating different fallback solutions.
- Final recommendations for trackside migration and fallback.
The first task within work stream E was to create a questionnaire and send it to a chosen number of suppliers and infrastructure managers. The recipients were asked questions about the system architecture of their interlocking systems, interfaces and functional structures. The questionnaire also contained questions about strategies for migration and fallback. The objective was to assess and compare the different interlocking system architectures, interfaces and migration and fallback strategies from existing state of the art projects.
Three documents of work were written as deliverables, D.E.1.1 “Safety constrains from the interfaces point of view”, D.E.1.2 “Report on the information collected from various railways and/or suppliers about ETCS” and D.E.1.3 “Report on the current migration and fallback strategies”.
A second step was to define a harmonised architecture for an interlocking system, with defined interfaces and adjacent systems, based on the experience and information gathered. The resulting architecture is showed in figure 11.
In a third step FFFIS interface specifications were developed based on WS D harmonised functional for the following interfaces:
1. Interlocking–RBC
2. Interlocking–Centralized LEU Controller (CLC)
3. Interlocking– Interlocking
The interfaces and systems fully specified in INESS are marked in pink in the INESS system architecture (figure 11).
The first main step in these FFFIS specifications was to perform a harmonization of the FFFIS content in agreement between the railway and the suppliers. INESS succeeded in that challenge by creating the first FFFIS template. This template is also suitable for the specification of other interfaces than the 3 ones defined in INESS. The INESS FFFIS specification template (main structure) is showed figure 12:
As showed in the next diagram, the specification work is compliant with the OSI (Open System Interconnection) model. It has mostly consisted in fully specifying the application layer. The lower layers have mainly dealt with by reference in the INESS FFFIS.
The FFFIS for the three interfaces that are relevant for INESS share thus the same document structure and content (see INESS FFFIS template figure 12), but use a different method for describing the interface. In the interface specification IXL-RBC a traditional method based on EXCEL tables is used to describe the behaviour. This FFFIS is to be complemented by state machine diagrams in order to describe the behaviour in more detail.
The FFFIS for IXL-CLC and IXL-IXL use a consequent UML based documentation methodology, which is the state-of-the-art way of specifying interfaces. One big advantage is that the UML models of the interface behaviour can be used to automatically create conformity test cases and to facilitate the building of interlockings.
An example of the model based specification artefacts is showed figures 11, 12, 13 and 14 hereafter
The 3 INESS FFFI’s can be used by standard setting and regulatory bodies for future standardization of interlocking systems or as input to projects that intend to use the current specifications to develop INESS based systems/prototypes.
Lastly a method was developed to evaluate different fallback solutions. The method allows a comparison of two or more different and independent fallback solutions for a specific problem and it gives hints on the implementation of the solution.
Based on their experience, the involved partners found out that it is not possible to compare different fallback solutions based on only one specific parameter. Instead of that, it makes sense to consider the following different aspects:
Occurrence probability of failure, frequency of using the fallback solution
Impact of the fallback solution on infrastructure capacity
Costs for implementation and usage of the fallback solution
Mental stress of operator in case of fallback
A significant result from this work is that the definition of fallback solutions is not necessarily connected to technical systems, but can also be routines and work procedures of personnel, e.g. CTC-staff.
The method is fully explained in INESS WSE deliverable D.E.4.2 “Report on Fallback Possibilities and Benefit”.
Besides this fallback classification and evaluation method, WS E has analysed the migration scenarios of various railways. Based on this analysis and the results of the fallback analyses, they have provided a set of specific (INESS) and generic recommendation for ERTMS migration considering all ERTMS application levels.
The purpose of the recommendations is to support the railway in their decision on whether or not to migrate to a new system including an INESS IxL. It will also have a harmonization effect by fostering a common understanding of the criteria used for fallback and migration in the various railways. Finally, it will enable the evaluation of the cost impact of the decisions taken.
The recommendations on migration strategies including fallback are part of WS E deliverable D.E.4.1. This document is available to public.
4.1.3.5 Work stream F: Testing & Commissioning
INESS project has been formed to derive a new common European interlocking as part of the drive for interoperability in railways and a single market. The current view of the railway market is that the equipment is too expensive leading to railways being seen as an uncompetitive form of transport when compared with other transport modes. INESS is seen as a vehicle to help reduce equipment cost. To provide a cost effective solution the project has pursued a number of work streams, each looking at a particular aspect of an interlocking, functionality, architecture, et cetera each topic contributing to an overall cost reduction estimate as part of a business case.
Work stream F has been concerned with the Testing and Commissioning part of the interlocking lifecycle. This is particularly important for the deployment of the INESS product into the railway environment. Inefficiencies in this process will be multiplied by the number of application installations. In addition any modifications to applications will also incur extra costs arising through inefficiencies
The diagram above illustrates a simplified process for the production and installation of an interlocking. Workstream F has addressed the shaded areas of testing and commissioning and conformity of a manufactured INESS interlocking in the product selection.
The workstream has delivered three main deliverables to provide a fully scoped contribution to the subject area: a State of the Art report for background information, a Testing and Commissioning Handbook as the main deliverable and a Product Test and Commissioning report to illustrate conformity testing and data reduction techniques.
Testing and Commissioning Handbook: In developing the handbook the work stream has taken input from both industry and railways in an attempt to arrive at a position where both sides gain benefit through reduction of cost, uncertainty and time scales. It has been recognised by the contributors that if we continue with current practices and methods nothing significant will change and costs will remain stubbornly high. Therefore the handbook contains what some might describe as radical ideas, taking note of how other industries approach the task.
The handbook analyses the current practices, ‘state of the art’ as a starting point to provide an assessed reference point for the rest of the work.
The notion of removing/reducing to a minimum the state of on-site testing has been taken on board coupled with production testing techniques to improve the quality of the delivered product and reduce cost. A method is described within the handbook of how this can be achieved. Other influences have been taken into account by the work stream such as the adoption of methods originating from the ERTMS arena of automating the testing; again conclusions are drawn from this area and opportunities assessed. The idea of simplifying the application data by not necessarily utilising all the complex functionality of the interlocking is examined as a possible method of ‘productionising testing’ and achieving a ‘safe by design’ state where testing can be radically reduced.
State of the Art: Background
The workgroup dealing with the state of the art in testing and commissioning examined current practices through a series of structured interviews with manufacturers and railway administrations. These interviews were supported by a questionnaire provided to the partners before the interview. The objective of the work package was to produce a set of quantified key performance indicators. However, due to the diversity and commercial confidentiality of the European rail industry direct measures could not be distilled.
It was decided to review the output of the work package with the aim of producing qualitative data that could then be used as a benchmark reference to compare the newly developed methods. To achieve the objective the data was reviewed and supplementary data obtained from the participants.
Review: An examination of the raw data has been carried out and supplemented by further enquires to provide a considered view on the state of the art. The on-site testing plays an important role during the commissioning phase of an interlocking. All companies which were questioned perform testing work on the track before they put an interlocking system into operation, but the amount of testing varies considerably between the companies. There is a range of time for on-site testing between one weekend (SME supplier) and up to four months (UK). A partial explanation for this can be found in the approach to testing an interlocking system. SME suppliers do the whole functional testing in the laboratory within the Factory Acceptance Test. On-site testing was reduced to carrying out only the validation and allocation tests. The big supplier companies in contrast, do a lot of functional testing on-site, which is time consuming.
Suppliers have to be accredited by the railway administrations before they are able to provide interlocking systems. To achieve accreditation the suppliers work to CENELEC standards in particular EN 50126, 50128, 50129. It was noticeable that the suppliers still employed these standards even when not required for contracts outside Europe. Consequently it was concluded that as a framework this provided an efficient way of working.
It was found that it is common for suppliers to employ an independence safety assessor (ISA) to provide assurance to the railway administration. It was found that most use an internal ISA but do employ and independent one if requested by the railway administration.
Additionally as part of the accreditation process a quality process was generally required for the supplier to be accredited. These ranged from ISO to rail industry based schemes.
Railway administrations in addition to the CENELEC requirement sometimes place company requirements on the testing in the shape of standards. However, the more normal position is the additional requirements are specified for particular projects which drive additional costs
Cross acceptance was not seen as a way forward partly because of scope creep and variations introduced by the customers which necessitated re-testing and re-justification by the suppliers, negating previous approvals. Therefore standardisation of requirements is a key element to controlling the test culture.
It was evident that testing is a joint enterprise between the supplier and the railway administration with each having a particular interest. The supplier trying to demonstrate that the system conforms to the requirements and the railway administration wanting a demonstration that the equipment is fit for the purpose before taking possession and being liable for payment. Most of this joint testing takes place at the supplier’s premises before the equipment is moved to site.
Where on site testing has been reduced by the SME suppliers it appears that the reasoning has been that the interlockings concerned, on average are controlling no more than 10 devices, which varies considerably from the more complex installation provided by the major suppliers. For these complex installations there has been much more reliance placed on on-site testing due to the complexity of the data and the limitations of the testing tools in covering the full data domain.
In the case of on-site testing the suppliers have not provided any information pointing to the usage of automated tools, this has been interpreted as no automated tools are used during the on-site testing phase. Therefore the process is reliant on skilled on-site labour; this fact helps explain why the on-site testing is expensive.
In the end this leads to the conclusion that on-site testing of interlocking systems is not efficient with respect to the time and money as opposed to performing these tests in the laboratories/factories. The testing and commissioning process for interlocking systems offers many possibilities for optimization with respect to the assignment of personnel, tool support and implemented methodologies
Product testing & commissioning report
The complexity and volume of data is a key driver of the cost of testing an interlocking application. The normal design process considers test and commissioning as an end function which is fed with a product which is downstream of the design. From an application perspective this scheme is short sighted because complexity of functionality and data complicates the required testing regime. By designing applications with a restricted subset of elements complexity of the testing can be reduced.
Within the INESS context workstream D has been charged with delivering the functional requirements. This data was analysed from a testing cost perspective categorising by the following KPI:

- Easy to test
- Medium to test
- Hard to test
Key Process Indicators (KPI) are measures used to obtain information from processes, but can also be used in order to establish differences from estimations. KPIs have to be measurable in order to retrieve information. Since this WS has no relevant information regarding direct costs, efforts and timelines, the use of these indicators is a way to extract information from the available data. The range of the KPI has been chosen to facilitate a consistent estimation from all participants by making the categories clearly separated
An expert view was sought from the workstream which was conducted by splitting the spectrum of elements up into categories, distributing them between pairs of partner organisations and requesting an assessment. The results were process and aggregated to avoid bias from any particular partner. The categories are shown below: Route general requirements; Route initiation completion; Route locking proving; Route used cancelled; Monitoring; Signal; Local shunting area; Powered point; Lockable devices; Level crossing; TVP section; Interlocking system general; Commands; Statuses; Driving values; Detected values
The evaluations have been collated specifically to show the areas of functionality that can be simplified under certain application conditions. It was important to establish if there is a relationship between functionality and effort as well as where it could be reduced. Clearly the greatest benefit can be obtained by reducing those areas that are difficult and expensive to test. A sample scenario was constructed to demonstrate what could be achieved if an application used ETCS Level 2 with no additional requirements. This is relevant because an objective of this project is to promote the rollout of ERTMS.
Conclusions: The testing of the interlocking could be simplified by applying the functional reduction technique described. The example has shown that this is a practical technique. It also explains the concept of “safe by design”, an example of simplification. This is a supporting technique for the application testing methods.
4.1.3.6 Work stream G: Safety case process
To save time and money during the safety case process WS G produced a formal representation of the CENELEC norms EN 50126, 50128 and 50129 using event-driven process chains (EPC).
This model has already proven its usefulness in interviews with operators and suppliers, were problems and best practices of safety case process application were discussed and identified.
From the interviews and in workshop discussions the requirements for a supporting tool were generated.
As most required functionalities could be found in the existing document management systems (DMS), an evaluation of existing open-source DMS took place. The “Alfresco” DMS was chosen and the missing functionalities were implemented in a java based tool.
The goal structuring notation GSN is the background idea behind this tool. A safe system is designed by decomposing its safety argumentation into smaller sub-goals. The evidence for the proposed solution is linked from the GSN Tool to the documents in the DMS (using a standard CMIS (Content Management Interoperability Services) communication interface), thus providing instant access to all relevant information.
The method of structuring a safe system into goals and providing evidence for all stated claims proved successful in two WS G internal projects.
The feedback from different NSA/ISA gave WS G the confidence to present the GSN / DMS concept as a long term strategy to make the management of a safety case report to be certified by an NSA/ISA, easier to understand and less time consuming to produce.
Formalization of CENELEC norms: In WS G it could be shown, that a formalized version of processes described in a norm significantly enhances the understanding of that norm. It is still necessary to have a deep understanding of the concepts described, but a graphical representation of the underlying processes, in the case of WS G using event-driven process chains (EPC), provides a better overview and a better starting point to understand the norms.
In-depth interviews for problem identification: With the support of the formalized norm mentioned above it was possible to conduct interviews in a very clear and easy to understand way. Whenever a misconception was mentioned the formalized model could be used to underline what the current question is about. From this, it could be concluded that a formalized model of a complex norm or any complex process is a powerful tool to identify problems and misconceptions of that norm or process. Once the formalized model is present, discussions about specific problems are shorter, as it can always be shown what is being discussed about.
Document Management Systems (DMS): An evaluation of document management systems showed that different open source solutions are available. These systems provide all expected functionalities (searching, versioning, tagging) ready to deploy. For INESS one DMS was chosen to implement a prototype of a safety case management tool. DMS currently have the problem that they are very company specific. Once a system is present the company relies on the provider of the DMS. To overcome such problems WS G used the 2011 standardized CMIS (Content Management Interoperability Services) communication interface to get access to the underlying documents. The CMIS standard has the potential to be implemented into different DMS. Free, open source implementations of the CMIS standard are already available for different programming environments. In the future it is proposed to have different DMS “talk to each other” as all providers of DMS as well as the creators of CMIS realized that in a heterogeneous world most projects require access to different document repositories.
The Goal Structuring Notation (GSN) Methodology: GSN was identified as a easy to understand and easy to apply methodology by all 10 partners of WS G. GSN was used by two partners of WS G to design and analyse their systems. In addition to the main advantages of understanding and easy application a few more positive aspects have to be mentioned. GSN “forces” system engineers to think about their system design. In very early stages of a project safety relevant functions have to be identified and assigned to modules or components. Claims about a solution always need evidence to be valid. This rigid justification scheme helps detecting errors in system design and it becomes less likely to overlook a detail.
GSN Tool: To use the GSN methodology in a real industry project a GSN editing tool was developed. With this tool it is possible to draw all elements of GSN, connect them in an appropriate way and link documents behind the GSN elements. Additionally the Tool provides the ability to colour elements to represent the status of that element. With this feature project managers and system engineers can get an easy overview of what has already been achieved and what is still to be done.
CMIS standard: CMIS (Content Management Interoperability Services) is a new standard proposed by different vendors of DMS and is managed by OASIS (Organization for the Advancement of Structured Information Standards). The standard is endorsed by Cisco, Deutsche Telekom, EMC, Fujitsu, IBM, Microsoft, Nokia, Oracle, Quark, Red Hat, SAP, SAS, Siemens, Thales, Boeing and a number of universities (excerpt of the CMIS committee). The functionality of CMIS is described by the standard as follows:
“The Content Management Interoperability Services (CMIS) standard defines a domain model and Web Services and Restful AtomPub bindings that can be used by applications to work with one or more Content Management repositories/systems.
The CMIS interface is designed to be layered on top of existing Content Management systems and their existing programmatic interfaces. It is not intended to prescribe how specific features should be implemented within those CM systems, nor to exhaustively expose all of the CM system’s capabilities through the CMIS interfaces. Rather, it is intended to define a generic/universal set of capabilities provided by a CM system and a set of services for working with those capabilities”.
Tool Chain: The tool chain used during the INESS project consisted of a number of exchangeable components.
- A document management system (DMS) accessible via multiple standards (CMIS, WebDAV, FTP, Browser)
- A database (delivered with the DMS, but also exchangeable)
- A Java based stand-alone application to create and edit GSN diagrams with a CMIS connector to the document management system
To integrate (parts of) the tool chain into an existing environment there are multiple solutions.
DMS with CMIS: If the DMS provides a CMIS interface the GSN Tool can be connected directly to the DMS. A list of available CMIS enabled products is available on the OASIS website (http://wiki.oasis-open.org/cmis/CMIS 1.0 Products).
If no DMS is present, the proposed Alfresco DMS can be installed. Alfresco has the CMIS interface built-in.
Alfresco with existing database: Alfresco can be connected to Oracle, MS SQL, mySQL, POSTGRES and DB2 dtabase management systems.
Alternative GSN Tools: If you just need the GSN functionality you can use GSN Editors, which are available. For a simple solution a plug-in for Microsoft Visio exists (http://www.cs.york.ac.uk/~tpk/gsn/gsnaddoninstaller.zip). The company Adelard offers a commercial solution for GSN (http://www.adelard.co.uk/). Just recently the University of Tokyo released an Eclipse plug-in, where any file known to Eclipse can be linked into the GSN structure (http://www.il.is.s.u-tokyo.ac.jp/deos/dcase/).

Potential Impact:
Project level: From the specification and design point phases of an interlocking product, INESS has succeeded in tackling the main identified cost drivers identified in phases 1 and 2 of the INESS interlocking life cycle business case (see figure 25) like:
- No standard system architecture with harmonized functional allocation
- No standardized interfaces (FFFIS)
- No standard data format and planning rules
- No certified test cases for generic application
- No modular and formal system description
The first 3 cost drivers have been completely solved during INESS while the last 2 ones have been approached or need further development.
Furthermore, INESS has developed guidelines or tools like the testing & commissioning handbook and the INESS GSN tool that will mainly have a positive impact on the phase 2 and 3 as described above.
It is assumed that the harmonization level and methodologies used in INESS will significantly reduce the time to develop a generic product, therefore bringing a bit benefit for the signalling suppliers, mainly the smaller ones. Nonetheless, it is felt that a cost reduction can only be expected for the infrastructure managers if there is sufficient competition that brings a “new signalling system” into the market. It has been demonstrated in the work stream B business model that applying INESS product to the market will facilitate accessibility of the smaller suppliers therefore enhancing competition.
It is only the combination of those 2 factors: reduction of development time and increased competition that will finally lead to a reduction of the cost of an interlocking or in general a signalling system.
It is obvious that such a cost reduction aggregated among the life cycle of INESS or among an ERTMS interoperability constituent will lead to an acceleration of the signalling and ERTMS rollout.
Work stream level: The potential impact that is described for every work stream in the following can only be achieved if the INESS results are used to build real interlocking systems. The lessons learned from these implementation projects will finally bring about a strong push into the direction of a standardized European interlocking and thereby will also help to accelerate the rollout of ERTMS in Europe.
Work stream B: By the help of the INESS Business Model different market scenarios can be simulated. For example the consequences different changes of the market structure might have on the rollout of ERTMS can be simulated and afterwards analysed. The simulation supports a better understanding of how the European signalling market works and which market mechanism are of high importance.
In this context both the supplying industry and the European railway companies will benefit from this Business Model. In addition policy makers drawing up decisions regarding the future configuration of the European signalling market will have their profit from this model as well.
The Business model approach used in INESS is available for each partner interested in this research area. The datasets and equations used as an input for the model are confidential due to a confidentiality agreement between all INESS partners.
Work stream C: The use of EUDRI either internally or by a converter to a data model specific to one company, would bring the following benefit:
- a wider scope of tools, even from different markets, that can be used to build the interlocking description,
- faster reaction on tenders,
- faster implementation of interlockings,
- less mistakes in the implementation of interlockings,
- therefore reduced costs for tenders and implementation,
- better quality of data describing the used assets, and
- therefore reduced costs for maintenance.
All this can be achieved simply because the suppliers do not need to rewrite the interlocking description in order to get it into their tools for calculation and implementation, and railway infrastructure managers do not need to rewrite the description of the assets used by the new interlocking to get those assets into their maintenance tools. So it is up to the railway infrastructure managers to start using EUDRI (and claiming the benefits). The suppliers will support every data model that is requested to be used – and put the costs into the bids.
Work stream D: The main impact of WS D is that there is now a common kernel of requirements available. The impact is greatly increased due to the quality improvements derived from UML modelling and from the fact that the UML model of the requirements can be used as a simulator for an INESS interlocking. The Common Kernel gets even more useful because in work stream E three interfaces between the INESS interlocking and adjacent systems like RBC, CLC and neighbouring interlockings have been specified. These interfaces are closely linked, again by UML models, to the Common Kernel from work stream D.
Besides this the innovative methods for validation and verification can be used for improving requirements in general.
Work stream E: The harmonized interlocking structure and the FFFIS specifications compliant with WS D harmonised functionality can be used by standard setting and regulatory bodies for future standardization of interlocking systems, with the aim of creating TSI’s. This can lead to the opening of markets to new bidders and to a decrease of prices for interlocking systems.
Work Stream F: The testing and commissioning methods describes in the handbook can bring the cost saving potential to 25%. Furthermore it has a didactical effect on EU stakeholders who are not familiar with testing.
Work Stream G: The GSN methodology together with evidence stored in a document management system proved to be a very useful combination in managing the safety cases. The GSN tool developed in WS G can be used in any project using a CENELEC-like development process. Together with the formalized CENELEC norms EN 50126, EN 50128 and EN 50129 as a guideline through the safety case process this tool chain will lead to the saving of time and money in the safety process.
In INESS, it has been an objective to make as much of the results as possible publically
available. Public deliverables have been posted on the INESS public website
(www.INESS.eu) under the heading “Achieved results and Deliverbles open to public”. The efforts towards dissemination and implementation are described in detail in the concluding technical report. Two activities can be mentioned here: The INESS 3 day Training in March 2012 who was a real success with about 120 participant coming from all over the world and the INESS Final General Assembly who took place in February 2012 where all the INESS results were endorsed by the consortium.
List of scientific publications
INESS Bulletin Board; INESS Brochure; INESS Flyer

List of Websites:
Project web site and contact details
Consult our web site at: www.iness.eu
Emmanuel Buseyne
INESS Project Manager

INTERNATIONAL UNION OF RAILWAYS
16 rue Jean Rey - F-75015 Paris
Tel +33 (0)1 44 49 21 17 - Fax +33 (0)1 44 49 20 69
Mob + 33 (0) 6 12 62 05 70
Mob +32 (0) 4 95 51 18 59

Final Report Summary - INESS (INtegrated European Signalling System)

Share this page

Download