Time management aspects

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.

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.