EULYNX: A route to standardisation

The eight members of the project include CFL (Luxembourg); DB Netz AG (Germany); Infrabel (Belgium); Jernbaneverket (Norway); Liikennevirasto (the Finnish Transport Agency); Network Rail (UK); ProRail B.V. (the Netherlands); and SNCF Reseau of France (formerly RFF). At the beginning of 2015 Trafikverket (Sweden) and SŽ (Slovenia) also joined the project.

The ‘back-office’ of the project is limited; based on a self-funding organisation around a very small core office offering project management support and some common tools. Most of the resources for the project come from the partners themselves as it is them who have the much needed domain knowledge to capture the functional requirements of signalling systems and are able to discuss the allocation of operational functionality to the different system elements.

Why EULYNX?

During INESS, the precursor of EULYNX, it became clear that although new computer-based interlockings (CBI) made new functionalities available, it was also evident that instead of lowering life cycle cost (as was the aim) it was rising in the case of interlockings. A major contributor to this increase was the much shorter operational life of the CBIs, especially when considering the interlocking core. This core, with a share of the CAPEX for a new interlocking including field elements and cables etc., of less than 10-15%, is subject to obsolescence due to the ever shorter availability period of its main components. The shorter operational life of the core has an impact on the whole interlocking, as core and field are highly interlinked in many solutions. Replacing the core meant, in many cases, renewing the whole interlocking.

Once this mechanism was understood – and being aware that in many cases the CAPEX is significantly lower than the operational cost (OPEX) to maintain the installation – a solution was found in which the life cycle of the interlocking core and field elements could be decoupled. Renewing the core while maintaining the field was, in many cases, difficult or expensive due to the fact that the only party able to replace the core was the original supplier: the so-called ‘vendor lock-in’.

EULYNX goals

The idea was born to decouple the core from the field by creating standardised interfaces (and field elements in the case of DB’s NeuPro project) making it possible to extract the core and replace it with a new core but leaving the standardised field elements intact, as their life cycle is significantly longer. As the architecture calls for IP-based communication between system elements, a safe communication protocol was based on the standardised RaSTA protocol. The connections of the core to the outside world are simple in term of physical connections. Standard network hardware and power supplies make it easy to build and test a new core and to commission its replacement in a very short time span.

The MoU of the project states: ‘In order to enable future partial replacement of system elements, the standardisation of the interfaces between these elements is seen as crucial. With these standardised interfaces some parts of an interlocking can be replaced without the need for a complete renewal of the interlocking, also reducing the demand for planning and approval resources which comes with a complete replacement’.

The MoU describes the intention to prove this need for standardisation and to agree on a common programme for interface definition for several elements: ‘The programme should not only include the standardisation work itself but also the related test and approval phases and tool development. Reference implementations are very much part of the scope. Reference implementations are those projects where the feasibility is tested for the first time and demonstrated and are supposed to be the validation phase of the standard’.

What is the EULYNX standardised architecture?

In order to achieve the goal of standardised interfaces, the first priority is to agree on the architecture of the signalling system and the corresponding allocation of functionality to the different subsystems. Some basic issues need to be agreed in advance, such as the communication infrastructure. Following a trend visible for several years, the communication is to be IP³-based as it allows the use of COTS products for the communications infrastructure. This, coupled with the agreement to use the RaSTA protocol as mandatory for all of the safety related interfaces, simplifies the architecture when it comes to addressing field elements, as these elements can then be subsystems with lower level functions allocated to them. 

Deliverables

The defined architecture provides the basis for EULYNX development throughout the full V-Cycle approach of CENELEC 50126. The deliverables of the EULYNX initiative are allocated to CENELEC Phases 1-5, in order to make a full set of specifications available. The documents will be made available for the signalling industry as the development of real equipment can only be based on a complete set of requirements. Partners have taken this to heart, aiming not only at providing a complete set, but also having this set formally written. The selected methodology allows for requirements to already be tested and validated before equipment is built. Modelling tools, together with executable state machines, based on formal use cases, will build a set of documents that goes beyond the previous way of describing requirements. Previously, these were often no more than a verbal description of functionality, leading to misunderstanding and different interpretations of the same requirements. System Engineering is vital in our approach and traceability is crucial right up to the customer requirements. Tools, such as IBM Rational DOORS for requirements management and PTC Integrity Modeler for modelling tools, are a key part of this; and are further supported with a document management system and workflow management system.

The journey so far

For each of the interfaces a dedicated cluster has been set up. What does this mean? As the functional requirements for the allocation of functions to a subsystem and the resulting flow of information across the interface is directly linked to the signalling philosophy of each infrastructure manager, the only way to gather this information is to bring together the experts of each infrastructure manager interested in using this interface. This group is a cluster of interested infrastructure managers.

For a typical cluster like TDS (Train Detection System) the work is carried out in phases. First, a list of functions is drawn up. Functions such as ‘Report TVP status upon request from ILS’ or ‘Failure status’, are listed in a spreadsheet, including the applicability of a certain function by each individual partner. Based on the agreed version of this function list, a set of use cases is developed.

It is in this phase that the discussions are really intense as it’s about signalling principles and the core knowledge of each signalling department. It is where different interpretations come together. The use cases are, in many instances, the first formal deliverable of the cluster.

After the use case development, the next phase begins where the modelling experts are carrying out the modelling. The resulting formal model will contain all the information, as in our process the model is the core information storage. The model is executable, enabling the simulation and validation of the modelled interfaces. An independent expert will test the model. This testing will be carried out with test scenarios developed by other experts, in order to validate the model. In a later phase of the life cycle, these test scenarios will also provide the basis for product acceptance and conformity tests.

Status and forecast

Currently 12 clusters have begun with several of them reaching the phase of releasing a first Cluster Baseline – a release that will take place in July 2016. These baselines will contain the approved set of uses cases. Also, some of the overall documents from CENELEC phases 1 and 2 will be released. The project expects to release a first complete Baseline Set in early-2017 with a second complete release by the end of 2017.

References

1. eulynx.eu
2. iness.eu
3. IP = Internet Protocol
4. Part of a non-approved document