RTM Model Extensions

From railTOPOMODEL® Wiki
Jump to navigation Jump to search

Overview of planned extensions

The model will be progressively enriched to support business usages. The next versions 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 (planned extension)

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

Theoretically the time dimension can be handled using any timestamp-accuracy one can think of.

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 (According railML® 2.2 format: yyyy-mm-dd).

Ravel Connectivity

Time-dependent changes in objects and (utilization) characteristics in many cases will have impact on their environment because these objects or characteristics have a relationship with other (unchanged) objects. These affected relationships (ravels) have to be restored.
When a complete dataset of a coherent area is replaced (according the above drawing) as a whole, these “ravels” occur on the borders of the area and are usually of various natures.

In summary:

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

This applies significantly for linear objects or -phenomena crossing the boundaries of new dataset(s) into the (invariant) data of the adjacent topology.

The simplest example of such an object in the topology is the trail in the micro-topology; but also the catenary or the set of demarcations of an operational point.

What can be the cause of ravels:

  • Different time validities in one and the same cross-border relationship between two or more involved objects inside and outside an area. These relationships not only concern topology but a broad set of other domain data-items( see below which possible domains). This makes the ravel issue to a multi-disciplinary and a multi-dimension problem.
  • Multi-layer approach (= different thematic views) on infrastructure data:
    Excisions are made in one thematic view of the rail infrastructure (the one with the topology and the rail-technical constituents), while the characteristics of other thematic domains don’t fit correctly with the borders of the excision.
    For example: the rail-topology doesn’t have a 1:1 match with the catenary topology (energy domain). Also the interlocking objects (like TVD-sections) cover the rail-topology independent of the shape of the excision. The same holds for the safety system (signal-aspect relationships) and the routes.

In both cases there are derived data which are affected in the relationship between two (or more) objects: think for example the recalculation of intrinsic positions of objects on trails which cross the border(s) of changed area’s (excisions).

One can think of the next thematic layers in the (data) representation of the rail infrastructure:

  • Rail- & civil technical construction
  • Topology (schematic and geographical in more than 1 aggregation levels)
  • Utilization restriction/requirements (like RINF parameters)
  • Energy supply and re-routing scheme’s
  • Safety & detection system(s)
  • Traffic control (routes & route settings in coherence with safety)
  • Installation systems (network of substations, receptors and integrating computers)
  • Object registration in asset management

All these layers are linked together in reality and have to be mutual consistent in data at any time, both inside an excision and all its cross border relationships regarding above entities.


To avoid unnecessary complexity it is recommended NOT to solve ravel issues inside the exchange formats but in the applications and algorithms of the data management where it comes together.

This implies requirements for the exchange format itself: see notes in the paragraph below.

Exchange format and file (XSD/XML)

After the above analyses, the question arises how to cover a certain data extract in an exchange file (XML) and how to describe its structure elements (XSD).

An XML file exists globally of a header and a content partition.

In the header all types of references are mentioned. The content part contains the values of all requested parameters, well organized according their mutual dependencies and coherence.

With respect to the time dimension, the header can contain:

  • time-stamp of the creation of the file,
  • the time-interval (FROM <time-stamp> TO <time-stamp>) that is used as selection criterion for the extraction of the content; this determines the data perspective of the exchange set.
  • the utterly expiration date for the content

In the content we can distinguish between:

  • Per object:
    • Design date of its (functional) place holder (design reality).
    • Placing into service date of its physical realization
    • Current state: single selection from the list “concept, planned, under construction, in service, non-active, dismantled”. This goes along with the above mentioned dates.
      Note: states should not have time-overlap; also state transitions are bound to some business rules: follow the chain of the described list.
    • As far as known: end date(s) both for functional placeholder and physical realization
  • Notes:
    • If one constituent of a composite object is outside the time-interval (see header) but the other(s) are inside, it belongs as well to the set of the content (e.g. this can be the case if one node-port of a trail is outside (earlier creation date) but the other one is (newer) inside the time-interval.
      Even more (ravel connectivity): if an edge (trail or SoL) only partial passes the inside of an excision, where both end points (node-ports) of that edge are outside that excision, then this edge is part of the selection. See figure below in time frame t1.
      So the edge itself has to have a time validity, which on its turn has to be compliant with the time validity of the end points. This enables applications to solve ravel issues outside the exchange format on either side of the interface.
    • Also the data-technical aspect of referential integrity has to be respected in the time dimension: internal object-references have to match according their common time frame. E.g.: a train of tomorrow should not refer to an OP that is dismantled (or non-active) since yesterday, although that OP is still in the source data set (including its validity limitations).
    • These ravel and referential-integrity problems arise especially in interlocking-, detection systems (TVD-sections)-, ERTMS-, and catenary phenomena. But also at the demarcation of tracks and trails.

What you should have learned
Please, enter a summary!
Chapter RailTopoModel® Use Cases and Application Examples RailTopoModel® Model Extensions
Section Planned extensions