EULYNX was launched by 10 European infrastructure managers (IMs) in 2014 to standardise signalling interfaces and elements. The first phase produced a full set of specifications, and Eulynx has now evolved into a permanent body for the standardisation of interfaces, based on a full baseline, with the publication in December 2017 of Baseline 2.
The Eulynx project was an answer to the difficulties IMs were facing with ageing command and control signalling (CCS) installations, combined with the continual squeezing of budgets which together made a toxic combination. Clear examples are DB Network’s so-called “signalling zoo” where tens of different technologies must live together with serious implications for maintenance and knowledge management. Combined with a much shorter lifecycle for modern computer-based installations, this means that very old mechanical interlockings still perform their function while recently-installed computer-based systems must be replaced due to the obsolescence of the processor and other electronic parts.
The replacement bow wave is becoming higher every year. The lack of human resources for designing, building and maintaining adds to that, given that most of the IMs have the same problem: 10 to 20% of their staff will retire in the next 5-10 years. Finding replacements is difficult due to the fierce competition that already exists in the job market for highly-educated personnel.
How can we reduce this pressure? The first thing to look at is life cycle cost. Why should the complete interlocking be replaced when only part of it has become obsolete? Due to different financing models, where funding for the up-front costs (Capex) often comes from a different source than the maintenance and operational cost (Opex), life cycle costs were often not considered. Focus on the lowest possible Capex often led to a much higher Opex, making life even harder for IMs.
Reducing the number of often-incompatible technologies installed is also necessary. The more technologies there are to maintain the greater the variety of spare parts is needed creating a logistical and financial problem.
As more than 70% of the cost of an interlocking resides in engineering, approval and installation of cables and field equipment, it does make sense to decouple the operational life expectancy of different elements. This means that when the interlocking core is replaced while the field equipment is retained, the opportunity should be taken to break the so-called vendor lock where a monolithic system from a single supplier can only be maintained or updated by that supplier.
The IMs taking part in Eulynx believe the answer lies in standardisation. This was the thinking of the 10 original IMs when in 2013 they discussed the launch of an initiative around the standardisation of CCS interfaces and elements to produce a more modular system.
A clear decision at the outset was to decouple the interlocking core from its surroundings. This allows the core to be replaced without the need to replace other signalling and control elements. All the interfaces the core has should therefore be standardised which means that the allocation of functions to the different elements of the CCS should be clear and that the interfaces should have a common communication stack. The first step was to agree on a standard reference architecture, function allocation and communications protocol. It was also clear that we should follow the V-model of Cenelec 50126, as the end result should be a full set of standards covering the phases up to 4/5 of the V-cycle. This means that for system definition and risk analysis documents, for example, an assurance process and interface specification should by delivered by the project.
However, as a function allocation to system parts is needed, the most difficult step was how to capture functions of the CCS system. As rail operation has evolved differently in each country, often within a different legal environment, a standard set of functions does not exist. A good example is the reset procedure of axle counter sections where in some parts of Europe a direct reset by the operator is possible but in other countries a so-called conditional reset is required followed by a train “sweeping” the section to clear it.
Many of these differences have been discovered and a solution called variability was agreed. In the table of functions for each interface some functions are marked as common while others are marked for a single IM or multiple IMs. Discussions by signalling experts led in many cases to an understanding of those differences, which in several instances were only there because different names were being used.
As functions are static while an interlocking is dynamic, it is therefore necessary to describe, in time, the interactions between system elements. Using model-based system engineering, the concept of use cases was adopted as a way forward. Formal descriptions of interactions and reactions were documented and agreed upon. But even if these Use Cases seem to be more formal than text-based functional requirements, there is still room for interpretation. The requirements should be more formal hence a model should be developed; a model that could be verified and validated against the signalling expertise held by the experts. Executable state machines† were the desired output. The whole process for developing the requirements is described in other outputs in the system engineering document and the modelling standard. The models are based on a subset of SYSML, a formal modelling language used extensively in the scientific world. In this, Eulynx followed steps taken by the aviation industry.
In December 2017 Eulynx published its first full baseline under an EU Public Licence. This means that while the intellectual property rights (IPR) remains with the IMs, the resulting specifications can be used freely by any interested party, and the documents can be downloaded from the Eulynx website.
The end of 2017 was also the moment that the main objectives of the project phase were achieved. But, as with any set of specifications, the documents are not error free and progressive insight may lead to other ideas. It was therefore decided to make Eulynx a permanent organisation, open to other IMs to join. Eulynx currently has 12 members and Austrian Federal Railways (ÖBB) is considering joining.
Last year, the executable state machines were completed, and extensive validation of the standards conducted, resulting in the publication of a new Baseline set 3 in December.
To address uncoordinated developments in the CCS environment, 2018 was also the year during which a memorandum of understanding [MB4] was signed with the ERTMS Users Group to coordinate and cooperate on the future CCS architecture. As part of the CCS environment is very closely allied with ETCS, an agreement was reached to combine both parts of the CCS world in a single architecture as the basis for future development. Game changers such as ETCS Level 3 and the achievement by Eulynx of an IP-based distributed intelligence environment will introduce the concept of “CCS of Things” to the signalling world.
As a result, Eulynx and the ERTMS Users Group have formed the Reference CCS Architecture (RCA) initiative to coordinate and harmonise future developments and digitalisation programmes. RCA will provide a path to migrate from today’s architecture towards the digital CCS of the future.
Another important development was the award by Bane Nor of a contract for the total renewal of its signalling assets that mandates the use of the Eulynx specifications. Other IMs have started proof of concept phases, some of which were successfully demonstrated at InnoTrans in Berlin in September 2018. DB Network is preparing a first roll out phase, in preparation for a major wave of signalling renewals.
This year will be dedicated to updating the releases of Baseline 3, which will include the requirements of other IMs and incorporate feedback from the first implementations. Follow-up releases of Baseline Set 3 are planned this year. 2019 will also see the expansion of the data exchange model, a requirement set used for the exchange of engineering data. Implementation of any system requires application engineering and asset capture. The initiatives around BIM have led to the adoption of the Eulynx data model as a basic exchange set of data. The Eulynx data model is linked to the UIC RailTopoModel, thereby further increasing standardisation.
ProRail and DB Network are partnering with the Dutch universities of Twente and Eindhoven whereby two post-graduate students will work on a PhD thesis to prove mathematically the completeness and correctness of the models. This is another step towards the creation of a formal environment.
A certification process is being discussed, which will integrate a network of laboratories for compliance testing, based on standard test scenarios published by Eulynx.
Eulynx has faced many challenges, not least due to a lack of expertise by the IMs. Outsourcing, which was a buzz word in the 1980s, led to an expertise drain, leaving the IMs as only caretakers of the specifications. As a result, expertise had to be rebuilt and the lack of understanding of model-based system engineering corrected. External modelling expertise was sought and had to be incorporated into railway signalling.
Management also had to be persuaded to invest a relatively small amount of money in Eulynx and to dedicate resources to the initiative. But, as we now can see, the idea has taken hold, including among our partners in the supply industry, and many IMs are now saying that becoming Eulynx compliant is the way forward.
† An executable state machine is a model of computation based on a hypothetical machine made of one or more states. Only one state can be active at the same time, so the machine must transition from one state to another in order to perform different actions. STMs are commonly used to organise and represent an execution flow, which is useful to implement functions and step through them in time. The object controller for a point machine, for instance, can be implemented using a STM: every state represents an action, such as move left or move right.
Bane Nor, Norway
DB Network, Germany
Finnish Transport Infrastructure Agency (Väylä)
French National Railways (SNCF)
Italian Rail Network (RFI)
Luxembourg Railways (CFL)
Network Rail, Britain,
Slovenian Railways (SZ)
Swiss Federal Railways (SBB), and