RTM Model Extensions

From wiki.railtopomodel.org
Revision as of 15:06, 17 March 2016 by Tobias Woitun (talk | contribs)
Jump to navigation Jump to search
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.

This page will concentrate on the RTM Model Extensions.

Planned extensions

Planned extensions

The model will be progressively enriched to support business usages. The next version will include:

  • Multiple times (horizons, creation and modification dates, validity dates,…)
  • Projects, versions and life cycle management
  • Requirements for Signalling and Interlocking

Following versions will also include:

  • Operational events
  • Traffic Management (commercial routes,…)
  • Asset Management

Time Management aspects

Definitions of the time aspect:
The time aspect in RailTopoModel is defined at the class “BaseObject” and refers to the time period for which a certain information object is valid in respect to availability for usage for train operations.

The attribute “validFrom” defines the point in time where the object in question is available for usage for train operations.

The attribute “validTo” defines the point in time where the object in question is no longer available for functional usage. The attribute “validTo” can be empty.

Handling time dimension:
The handling of the time dimension manifests during input of new-, adjusted- or deleted data and then storage and export of (subsets) of data. Especially the export functions can focus on specified time frames of specified subsets (topological areas) which can be (even partly) affected by different time validities of values for the same objects.

Time related dependencies can be handled on the level of:

  • Individual (data) objects: from birth to dismantling, both for the functional placeholder of an object (designed existence) and its physical realization(s) (reality outside in the field).
  • Coherent data sets on group- or area level of the topology (usually demarcated on the micro-topology)
  • Connectivity in time and space of data-entities (e.g. to secure overall referential integrity)

The last issue is secured the best if new topologically coherent datasets with a common time validity are inserted as a whole, with special care for ravel relationships with its topological environment. At the storage phase of data, this corresponds with the handling of precise demarcated and identified excisions in the original dataset in which the modifications will be applied.

Time granularity: The granular size of the time dimension has to be chosen in accordance with the frequencies of the design-, data maintenance-, and placing into service processes. In general this will be a calendar day.

Ravel connectivity: Ravel connectivity is the issue where changed objects/phenomena or topology constituents inside an area (and its dataset) will need restored relationships with unchanged objects in their direct environment outside that area (in the drawing these areas are shown as demarcated excisions).

Open issues

Open issues