UC:IL:Simulation

Use case / Anwendungsfall / :

Simulation; Simulation;

Description / Beschreibung /

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?

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.

Data Flows and Interfaces / Datenflüsse und Schnittstellen /

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)

Interference with other railML^® schemas / Interferenz mit anderen railML^®-Schemen /

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.

Characterizing Data / Charakterisierung der Daten /

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 external Simulation specialists. The latter shift signals and Points and 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 restricted to yards and corridors under investigation.

Which views are represented by the data (focus)?

no information available

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

no information available