RTM quick start: Difference between revisions

From railTOPOMODEL® Wiki
Jump to navigation Jump to search
[checked revision][checked revision]
No edit summary
No edit summary
Line 42: Line 42:


== Goals ==
== Goals ==
The ultimate goal is to propose a standardized infrastructure master model which supports a common representation of a railway network and events, and facilitates the exchange of data within the rail sector.<br />
For this purpose, UIC proposes the use of a graph topological model, as such a model is commonly used to display networks for a range of sectors, including the railways. One of the main reasons that such a model has been so widely adopted is that it is systemic, i.e. it is independent of any particular use or application. This choice guarantees sustainability and scalability, meaning it can evolve as business needs change. It also ensures the integrity, quality and dimension of data is not compromised due to the usages and evolutions. <br />
The first objective is to ensure that this model supports the railway’s business needs, today and tomorrow. In order to achieve this, the model must fulfil the following criteria:
* Provide a topological representation of the iron network which is fully connected and can be visualised schematically. It must display the track location at the most detailed level and be able to view the connections which exist at other scales (levels of detail) such as line and corridor.
* Enable data to be aggregated and disaggregated, to ensure consistency is retained across all scales.
* Allow permitted routes to be identified, based on network topology and the location and rules of signaling assets etc.
* Support multiple referencing systems, ensuring consistency during transformation. Primary examples include:
* Linear referencing – using mileposts and ‘rail addresses’,
* Positioning using geographic reference systems,
* Screen (schematic) coordinates
* Locate point and linear entities, including:
* Points / nodes, such as any installation and equipment or event etc.
* Lines / edges, such as speed limits, slopes, platforms etc. (attributes which are the same along a linear feature).
*Areal objects, such as track circuits, tunnels etc.
Finally, it is important to future proof the model. This model is designed to be enriched progressively, per layer, with new concepts to support business usages as they evolve.


== History ==
== History ==


== RTM vs. other models ==
== RTM vs. other models ==

Revision as of 13:48, 16 March 2016

UnderConstruction blue.png This page is a draft and under construction. 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. If you find any copyright infringements, please contact us: Christian.rahmig@dlr.de.


Overview
This page give you an overview RailTopoModel. It is explained what RTM is, why and how it came to be and what it is for.


RTM components

UIC RailTopoModel, is a universal railway business model, which aims to define railway objects and events in a standard form (UML), to show how they interact with each other, and how they are expected to be used. As such, it aims to standardise the process for designing any business process, data structure, IT software and data flow in the railway industry.
The RailTopoModel is described in UML notation.
One of the first deliverables based on UIC RailTopoModel will be an enhanced version of the standard exchange format railML, with the announcement of railML3.0. Other deliverables will come, as SQL Format and loader, etc.

Motivation

Current national situation

One of the greatest challenges for today’s railway sector is to establish a format and mechanism to transfer data both internally across an organisation and externally between organisations. This has arisen from the lack of a standardised data exchange format and a single industry wide approach.
To date there has been little coordination or consensus within the railway community over a standard for the exchange of data. Thus multiple standards have been developed for specific purposes, each with its own data definition (model) and file format (2).
The consequences of this have been:

  • Laboured and repetitive developments in IT,
  • Long project lead times, and
  • Incompatibility between different standards, which has prevented the development of transformation software in a competitive market.

As such, each data model and format cannot be used for other purposes. Examples include formats designed for RINF, INSPIRE, ETCS projects, etc.

A standardised model

Ideal national situation with the UIC RailTopoModel and railML

The vision for a standardised data exchange process requires a number of components:

  • A logical model: to describe the topological relationship of infrastructure objects and their attributes.
  • An exchange format: to represent objects within a model as structured data, typically in text format with a defined schema.
  • An adaptor / translator: to restructure data from one format to another. Translators can be used to convert the output of platform specific data to a standardised format which can then be shared more readily with other applications.

Together these components will provide a data exchange tool that can facilitate the efficient transfer of data within the rail sector. They will allow users to exchange tabular and geographical data related to all aspects of the rail sector from infrastructure description and status, interlocking and routes, timetabling and traffic control etc. using a standardised format.
Considering the work done by the railML® initiative project in co-operation with this modelling work, there are currently two products available to facilitate the exchange of data in the domain of railway infrastructure.

Logical model The UIC RailTopoModel is a generic railway data model designed to support current and future business needs. It is particularly useful for:
  • Engineering activities – mainly based on installations and components, and
  • Circulation activities – mainly based on routing and scheduling.
railML railML 3 is the latest evolution of the format created by railML.org. RailML 3 was specifically developed to compliment the UIC’s RailTopoModel.

Thus, railML® can be viewed as the first benefit of RailTopoModel.

Benefits from a standardised model

Investing in a standardised railway data exchange format will provide multiple benefits for the sector, including:

  • Improved data quality,
  • More efficient business performance,
  • Streamlined and re-usable development,
  • Integrated IT systems, and
  • Return on investments.

Detailed Information about railML® can be found on the railML® website.

Goals

The ultimate goal is to propose a standardized infrastructure master model which supports a common representation of a railway network and events, and facilitates the exchange of data within the rail sector.
For this purpose, UIC proposes the use of a graph topological model, as such a model is commonly used to display networks for a range of sectors, including the railways. One of the main reasons that such a model has been so widely adopted is that it is systemic, i.e. it is independent of any particular use or application. This choice guarantees sustainability and scalability, meaning it can evolve as business needs change. It also ensures the integrity, quality and dimension of data is not compromised due to the usages and evolutions.
The first objective is to ensure that this model supports the railway’s business needs, today and tomorrow. In order to achieve this, the model must fulfil the following criteria:

  • Provide a topological representation of the iron network which is fully connected and can be visualised schematically. It must display the track location at the most detailed level and be able to view the connections which exist at other scales (levels of detail) such as line and corridor.
  • Enable data to be aggregated and disaggregated, to ensure consistency is retained across all scales.
  • Allow permitted routes to be identified, based on network topology and the location and rules of signaling assets etc.
  • Support multiple referencing systems, ensuring consistency during transformation. Primary examples include:
  • Linear referencing – using mileposts and ‘rail addresses’,
  • Positioning using geographic reference systems,
  • Screen (schematic) coordinates
  • Locate point and linear entities, including:
  • Points / nodes, such as any installation and equipment or event etc.
  • Lines / edges, such as speed limits, slopes, platforms etc. (attributes which are the same along a linear feature).
  • Areal objects, such as track circuits, tunnels etc.

Finally, it is important to future proof the model. This model is designed to be enriched progressively, per layer, with new concepts to support business usages as they evolve.

History

RTM vs. other models