UC:IL:EulynxDataPreparationInterlocking: Difference between revisions

From railML 2 Wiki
Jump to navigation Jump to search
[checked revision][checked revision]
m (Coordination verschob die Seite IS:UC:EulynxAndInterlocking nach IL:UC:EulynxDataPreparationInterlocking, ohne dabei eine Weiterleitung anzulegen: Page accidentally sorted in IS:UseCase section)
(ruggedize the Information Life Cycle)
Line 3: Line 3:
Description:
Description:


Infrastructure Managers wish to represent their railway system in terms of standardised data types. Eulynx collects and analyses the types and attributes of objects, or track assets, that are found on Europe’s railways. The result of this analysis is a data dictionary that must fit the railML IL schema.
Infrastructure Managers (IM) wish to represent their railway system in terms of standardised data types. Eulynx collects and analyses the types and attributes of objects, or track assets, that are found on Europe’s railways.<br />The result of this analysis is a data dictionary that acts as ''input to the railML interlocking model''. By adopting the objects described in this data dictionary 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.
Eulynx distinguishes conventional and ERTMS interlocking whilst recognising that there is overlap.


Line 10: Line 11:
# Exchange of asset information with signalling industry (link to http://wiki.railml.org/index.php?title=IS:UC:InterlockingEngineering)
# Exchange of asset information with signalling industry (link to http://wiki.railml.org/index.php?title=IS:UC:InterlockingEngineering)


The planning of the interlocking and signalling systems for individual yards is and remains within the scope of the railways.  
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 a) customises 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 Build dataset then flows back to the IM who incorporates the data in his asset information system.  
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.


Rationale: ruggedize the Information Life Cycle
Eulynx describes the use case in a [http://eulynx.eu/index.php/documents/published-documents/open-availability/01-phase-1/25-20160712-eulynx-concept-v1-0/file concept document] as follows:<br />
The asset manager prepares data in a standardized format, this data is transferred to the supplier for use in the production process and delivered back in standardized format to the asset manager with enriched detail asset information
''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.
Please refer to the linked use cases that cover the Eulynx use case.
For detailed information please refer to the website [http://eulynx.eu eulynx.eu]

Revision as of 16:12, 10 August 2016

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)

Description:

Infrastructure Managers (IM) wish to represent their railway system in terms of standardised data types. Eulynx collects and analyses the types and attributes of objects, or track assets, that are found on Europe’s railways.
The result of this analysis is a data dictionary that acts as input to the railML interlocking model. By adopting the objects described in this data dictionary railML gains acceptance by IM's and ensures completeness of the model.

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

The reason for standardising data types 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 http://wiki.railml.org/index.php?title=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 as follows:
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.
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.

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 eulynx.eu