UC:IL:Simulation

From wiki.railML.org
(Redirected from IL:UC:Simulation)
Jump to: navigation, search
Simulation
Subschema: Interlocking
Reported by: Jernbanedirektoratet
This page refers to version 3.1 of railML®.
Therefore the content is not yet finalized.
The current version is 2.4.
For general information on use cases see UC:Use cases

Use case / Anwendungsfall / Scénario d’utilisation

Simulation; Simulation; simulation de capacité du réseau

Description / Beschreibung / Description

Infrastructure Managers simulate traffic on increasingly realistic models of their networks to design and test timetables. Alternative route-setting is essential to model behaviour in case of disruptions. Simulation includes realistic interlocking routesetting behaviour. Simulation models include time-to-set and time-to-release parameters, restrictions due to flank protection, number of blocks reserved by trains due to the nature of the signalling system, alternative routes, mutually exclusive routes, etc.

Consider for instance routesetting. An interlocking is required to set and lock routes. A description of routes in terms of railML is of interest to both engineering and simulation. However, a simulation program will focus on the time it takes for a route to be set and released. This information is generally not of interest when engineering an interlocking for a particular site. Furthermore, timing, e.g. the time before a point is thrown and locked depends on the underlying hardware and software. In other words, this information depends on specific hardware which suggest that it has no place in a RailML model which by vocation is portable and system-independent. One would suggest that simulation users add specific extensions to suit their needs, e.g. add information about throwing delay to specific types of points. Simulation of an interlocking by nature replicates the behaviour of the interlocking. In other words, the interlocking model would require the functions. The Euro-Interlocking project (UIC, 2013) makes a stab at functional modelling. Several IM’s need interlocking data for modelling capacity (e.g. (Jernbaneverket, 2015)). Questions about the network and the signalling system need answering. How many extra trains can be squeezed in, given a legacy interlocking? What happens if we remove or add a signal? How many trains are affected by the loss of a neuralgic point?

Most capacity operational simulation tools use their own internal generic interlocking (table) model. Thus this use case does not require a interlocking table. This distinguishes this IL UC from other IL UC. A route description with attributes (primarily timings and speed) or route attributes on signal infrastructure objects is sufficient.

railML originated from the need to test timetables against realistic simulations. The railway network had to enter the model in terms of distances, gradients, curves, etc. The interlocking and signalling system adds time constraints to the model. Routes are slow to clear or set, points are slow to throw and so on. The timetable must resist perturbations by providing alternative routes. Capturing routes and timing parameters in railML will improve precision of the simulation and so produce more robust timetables.

Alternatively, Infrastructure Managers may be interested in improving the performance of signalling and interlocking. What happens if a signal is removed ? What if we release routes more quickly ? What happens if we introduce ETCS L3 ? Specialised designers of simulation software designed to answer such questions would find it highly helpful when uniform railML data are available to answer such what-if questions.

Data Flows and Interfaces / Datenflüsse und Schnittstellen / Flux de données et interfaces

A simulation program typically requires interlocking data:

Block Sections, Routes (OpenTrack uses the term Route for the Block Sections):

  • Start and end location of the block section (start signal, end signal)
  • Unique definition (sorted sequence of elements, switches, …)
  • Reservation point of the block section (optional)
  • Release point
  • Partial release groups
  • Reservation time
  • Release time
  • Switching time (of switches) (optional)
  • Signal aspect at the start signal (which signal aspect is provided when the block section is reserved)
  • Overlaps (optional)
  • Slow speed zone for restrictive signal aspects (e.g 40 km/h, from where to where is the speed restriction valid [e.g. from the first signal, from the first switch] and where does it end)
  • Additional signal aspects (e.g. to allow an entry into an occupied block section)

Itineraries:

  • Sequence of block sections, e.g. to define the complete journey of a train (optional)
Route elements

Route elements for use in the use case:

  1. approachPoint
  2. routeEntry
  3. switchPosition, TVDs grouped in release groups
  4. routeExit, overlap, overlapRelease (timer)
  5. overlap switchPosition
  6. overlap limitedBy
  • A: approachSpeed
  • B: proceedSpeed, releaseSpeed
  • C: overlapValidityTime
  • movableElement - max/average throwTime
  • route - releaseTime, reserveTime

Interference with other railML® schemas / Interferenz mit anderen railML®-Schemen / Interaction avec autres schemas railML®

Interlocking data rely heavily on infrastructure data. In fact, the interlocking data mostly are pointers to objects defined in the infrastructure Namespace. This implies that any modification of the IS model is likely to affect the interlocking model.

Additionally to infrastructure the rolling stock schema is required for running trains on the defined infrastructure with interlocking. This for amongst others technical minimum headway calculations in the simulation and timetable free capacity assessments.

Additionally to the infrastructure and rolling stock schemas the timetable schema is required for running multiple trains interactively in a defined timetable concept for timetable feasibility and robustness studies, amongst others through UIC406 method.


Characterizing Data / Charakterisierung der Daten / Caractérisation des données

This section serves to specify the required data regarding certain aspects.

How often do the data change (update)?

This use case is likely to occur in an iterative design process. For example, an IM requests external simulation specialists to optimise throughput of a busy yard. The IM exchanges the yard's railML data with the simulation specialists. The latter shift signals and points to find the optimal signalling and interlocking design. Then they return the railML data to the IM who may adapt according to their rules and regulations. The frequency of data exchange in such a design-Simulation cyclus can be high. Alternatively, railML data may be fixed. An IM would provide read-only railML interlocking data such that interested third parties may provide suggestions for improvement. One can imagine a open-data scenario where university students access railML data for modelling assignments (and come up with wonderful suggestions for improvement).

How big are the data fragments to be exchanged (complexity)?

Data fragments are likely to be range from yards to corridors, depending on the subnet under investigation.

Which views are represented by the data (focus)?

The data provide a more functional view with respect to their use in interlocking context, especially for train routes.

Which specific data do you expect to receive/send (elements)?