From railML 2 Wiki
Jump to navigation Jump to search
🗒️ This page is mirrored from page UC:IL:EulynxDataPreparationInterlocking in The railML® 3 wiki.
Subschema: Interlocking
Reported by: EULYNX
Stift.png (version(s) not yet specified)
For general information on use cases see UC:Use cases

UnderConstruction.png This page is under construction since June 30th 2016. Task: Adjust layout. Sorry for temporary problems. See the discussion page to find a summary of the tasks and to coordinate the work on this page. Recognize that the content of this page may change quickly. Vivian Augele (Diskussion) 08:14, 30. Jun. 2016 (CEST)


Infrastructure Managers (IM) wish to represent their railway system in terms of standardised data types. Eulynx collects the types and attributes of objects, or track assets, that are found on Europe’s railways. Eulynx also analyses the logical relations that exist between elements in terms of routes, flank protection<br />The result of this analysis is called a data platform, for it is more than a simple static data dictionary, that acts as input to the railML interlocking model. By adopting the objects and object-relations described in this data platform railML gains acceptance by IM's and ensures completeness of the model.<br />

Eulynx distinguishes conventional and ERTMS interlocking whilst recognising that there is overlap.

The reason for standardising data types and relations between objects is

  1. Exchange of asset information, e.g. with the Registry of Infrastructure (link to RINF Use Case)
  2. Exchange of asset information with signalling industry (link to IS:UC:InterlockingEngineering)

The planning of the interlocking and signalling systems for individual yards is and remains within the scope of the Infrastructure Managers. Extracts of the data set describing the yard flows to the suppliers who customise their signalling system to that particular yard. This is the To Build data subset. The supplier enriches or modifies the data subset according to the As Built situation. This As Built dataset then flows back to the IM who incorporates the data in his asset information system. Traceability between Eulynx data dictionary and the railML IL model allows a cross-check of completeness.

Eulynx describes the use case in a concept document (external link) as follows:<br /> Eu.Con.97 - Data Preparation delivers a standard data format for conventional and Level 1 and Level 2 ERTMS-compliant interlockings to support the exchange of interlocking planning data between infrastructure managers and external parties, such as engineering firms and suppliers.<br /> and Eu.Con.98 - The standard data format can be filled with the data from databases, and / or converted from the other specific data formats from tooling of infrastructure managers. Infrastructure managers have already invested in developing own data formats and tooling, therefore it is a precondition that they maintain to use their previous investments. This leads to requirements for conversion to the standard way of description.<br /> <br /> The IM transfers data in railML format to the signalling supplier for use in the production process. After completing the process, the supplier (or engineering subcontractor) returns railML data to the IM with enriched detail asset information. The IM updates his asset database to reflect the as-built situation. Please refer to the linked use cases that cover the Eulynx use case.

For detailed information please refer to the website https://eulynx.eu (external link)