LUKS – Analysis of lines and junctions

The LUKS software tool is an integrated system for several types of railway operations research. Based on a common data basis, compilatory, analytical and simulative methods can be adopted for analyses of lines and junctions. [More about the different approaches.]

LUKS was developed in response to the plethora of programs available hitherto and the drawbacks this entails for the inputting and use of infrastructure and timetable data from the operative systems run by DB Netz AG. Right now, LUKS incorporates the current state of the art in railway operations research. Per year, two new versions of LUKS are released

During the last years, LUKS became the standard tool for capacity assessment of German DB Netz AG, the standard tools for simulation at INFRABEL as well as the default system to answer capacitive questions at EBA (German railway authority).

LUKS is modular in design and comprises several core components plus modules with which to compile timetables, subject lines and junctions to analytical examinations and simulate the timetabling and operational processes.

The different approaches of LUKS

Application: Individual approaches for different scopes

In railway operations research several approaches exist to validate and analyse the consequences of infrastructure and/or timetable changes. It is possible to classify the used methods into analytical, simulative methods or design-engineering. The appropriateness of an approach depends on the actual situation. The software tool LUKS combines all three approaches.

Analytic methods

Analytic methods are applied to perform a long- to mid-term appraisal of infrastructure variants. In general, the exact timetable which has to be faced by the infrastructure is not yet known in this situation. Instead, by means of queueing theory the operating programme is understood as “customers” wanting to be “served” by the infrastructure. This way, the capacity assessment is directly linked to the operation’s quality expressed in terms of scheduled and unscheduled waiting times. These performance indicators can be calculated for different parts of the infrastructure, which is decomposed into “servers”:

  • Lines

  • Stations heads (“gril”)

  • Serial route nodes

The usage of aggregated train types instead of an exactly given timetable allows a very quick setup, since there’s no need to compile the entire timetable for each infrastructure variant. Futhermore it permits the modelling of yet uncertain constraints (e.g. knowledge on the number of trains).


Simulative methods

Simulative methods should be applied to perform mid-term to short-term evaluations with comprehensive consideration of constraints. Two modes of simulation have to be distinguished:

  • Simulation of timetabling: The practicability of timetabling(!) for a given infrastructure is evaluated by an asynchronous simulation approch. As an input parameter, a rough train-path order needs to be given in advance.

  • Simulation of operation: The operation’s quality for a given timetable and infrastructure is evaluated by disturbing operating by primary delays.

In both cases the input parameters of a simulation can be easily derived by “enrichment” of analytic scenarios.


Deterministic methods (design-engineering)

Design-engineering is the appropiate approch for a profound evaluation of the correlations between an exact given timetable and the infrastructure. It permits a proof of feasibility of a timetable with consideration of additional constraints (e.g. train intervals, connections, turn-arounds).

A second field of application is the timetable-dependent compression according to UIC Code 406 (e.g. to detect, which share of capacity is bound by “grandfather” contracts).


LUKS basic

Infrastructure and train editor

LUKS basic – Infrastructure and train editor

General characteristics

  • Incorporated method is certified and required by German railway authority (EBA) to validate infrastructure actions.

  • Common successor of former tools STRELE, SPURPLAN, FAKTUS/RUT-0, ANKE and BABSI.

  • Recommended by UIC for capacity analysis of ETCS.

  • Applied for consulting work on networks inside and outside Europe.

  • Different import and export interfaces for infrastructure and timetable data.

Interfaces simplify both the import and export

To ensure an efficient integration into the workflow, LUKS offers various interfaces to read different formats of infrastructure and timetables. In certain cases, it’s also possible to export data from LUKS. Lists of the currently implemented interfaces are given below.

Interfaces simplify both the import and export

Infrastructure data

  • XML-ISS import and export (compatible to DaViT)

  • Import from RUT-0

  • Import from Artemis

  • Import from standardise XML

  • If no adaptable infrastructure graph is available yet, the elements (e.g. gradients, signals) of tracks can be imported from text-files

Timetable / operating programme

  • XML-KSS import and export (compatible to RUT-K)

  • Import from RUT-0 (former tools FAKTUS and ANKE)

  • Import from Viriato

  • Import from Paula-Z

  • Import from standard INFRABEL data

Infrastructure editor

It is usually the case that investigations of railway operations reveal a need to alter imported infrastructure data speedily and straightforwardly. But it must also be possible to completely recapture infrastructure without unreasonable effort.
The figure below shows the Infrastructure Editor’s standard view with the usual screen layout for LUKS: tracks can be seen on a one-to-one basis in the upper half, whilst details of the program module currently running are to be found in the bottom half.

In the case of the Infrastructure Editor, these include a list of infrastructure elements within the inter-S&C section currently selected, details of the current track-layout element an a number of buttons for rapid adjustment of the element’s values and the graphic display.

Great value was attached when developing the user interface to simplifying standard work steps and providing access to them within a low number of operator actions. The various Editors are accordingly configured in context-related fashion; little resort is had to dialogue boxes, which make processing rather heavy-going.

Routes and tracks

Building on a given infrastructure, use is made in LUKS of “control post routes” to map all running options admitted by the signalling system. A route of this kind defines the course of a train’s movement through a control post, described as a series of decisions taken at all S&C systems to be negotiated.

Platform tracks can also be entered in LUKS along with routes. They are likewise based on the infrastructure initially captured and are required for the track-occupation diagram, as a means of demarcating “track groups” in analytical studies or, in simulation exercises, of establishing spatial limits for various types of interconnection between train movements.

Running and blocking time calculation

Running and Blocking time calculation

Track-occupation is computed on the basis of the running time calculated. This involves forming blocking times along the line negotiated using distance/time curves. Blocking time is taken to mean the time during which a block section between two block signals is occupied by a train, inclusive of various prior and subsequent running times.

Calculation of running times always covers sophisticated calculation of blocking times.

As with the running time calculation, the blocking time units calculated by LUKS and RuT-K were found to be identical. A blocking-time series is the sum of all blocking-time units along the line negotiated. Further details are to be found in [3].

The distance/time curves and blocking-time series for all trains computed are represented in a track-occupation graph that also points up any conflicting moves. Such conflicts always arise when several train movements wish to use the same infrastructure simultaneously. They can be remedied either directly in the running-path definition, in the course of further processing, or when the timetable is fine-tuned.

Implemented train protection and supervision modes

  • Intermittent automatic train control (PZB 90 of Deutsche Bahn AG)

  • European Train Control system (ETCS Level 1, 2 and 3)

  • Semi-regular distance between signals

  • Reduced distance between multi-section signals

Open design

  • Software architecture is capable of additional train protection systems or individual modifications of the blocking time model.

Details on the modelling of PZB 90 / I60R

Under certain conditions, train supervision impacts capacity consumption

  • The running time is influenced by train supervision, if the next main signal is closed.

  • This impact arises in simulations or in a capacity assessment entering a scheduled stop.

  • The implementation of different interference strategies can be evaluated.

Details on the modelling of PZB 90 / I60R

Modelling of ETCS according to EEIG-97E881

Modelling of ETCS according to EEIG-97E881
  • Possibility to optimize ETCS installations to maximise capacity

  • Consideration of transmission times according to latest research


Analytic assessment of capacity and operation’s quality

Analytic assessment of capacity and operation’s quality

You will find further information about this topic soon.

Analytic dimensioning of lines, junctions and station track groups

LUKS-A – Analytic assessment

Analytic approach is based on decomposition of the infrastructure

Analytic approach is based on decomposition of the infrastructure
  • The network is automatically disjoint in single- or multi-channel servers.

  • For each server the arrival process is derived from aggregated train types.

Analytic approach is based on queueing theory

Differentiation between theoretical and practical capacity

  • Theoretical capacity Number of trains (nmax) with infinite waiting area

  • Practical capacity Number of trains (nopt), which leads to market-conform waiting times ETW,LOS

Evaluation of process states

  • Timetabling
    Independent path requests of TOCs result in scheduled waiting times.

  • Operation
    Conflict-free timetable is disturbed, thus unscheduled waiting times arise.

Analytic approach is based on queueing theory

The basic for the analytic approach is the minimum headway time calculation

  • Junction
    Minimum headway time of the adjacent overtaking section

  • Line
    Maximum of all minimum headway times of all overtaking sections along the investigated section

Capacity of junctions

  • Decomposition of infrastructure into servers (serial route nodes, SRN)

  • Calculation of minimum headway times for each SRN

  • Each SRN can be evaluated with focus on the quality of operation.

  • Station track-groups can be modelled as multi-channel servers.


Simulation of timetable compilation

Simulation of timetable compilation

You will find further information about this topic soon.

Simulation of operation with consideration of dispatching layer

LUKS-S – Simulation of timetabling and operation

Two modes of simulation

LUKS-S facilitates simulation of both timetabling and the running of traffic. Both simulation modes operate microscopically on the basis of the infrastructure and train data captured. It is possible with the aid of the two modes to conduct various forms of medium and short-term investigations.

Timetabling simulation leads to a feasible and operable timetable

The simulation of timetabling provides information on whether a predefined operating schedule is viable, i.e. whether it allows a conflict-free timetable to be compiled that contains the envisaged train movements. It proceeds hierarchically. The simulation begins with an empty timetable sheet on which only the highest-ranking train movements are initially entered in their requested slots. All equal-ranking train movements are entered at one time. Consideration is then given to the first track-occupation conflict to arise chronologically. The overlapping of two blocking-time units is deemed to constitute such a conflict. A number of possible conflict resolution options are identified and assessed, with the following courses of action being contemplated:

  • alter the route within one or more operating control points

  • alter the sequence of operating control points

  • modulate running times

  • alter the stopping time

  • insert passing and crossing stops

  • move entire train path

Any changes that make sense for either train movement are identified and the additional (scheduled) waiting time they give rise to is called up for evaluation purposes. The option with the best rating is then put to effect. Where it is not possible to identify a valid solution, one of the two train movements is rejected. All conflicts are gone through in this way in chronological order.

As soon as the timetable sheet is free of conflicts, all train movements with the next highest ranking are entered and any fresh conflicts arising are resolved as above. In this way, all train movements are timetabled by rank and a viable timetable is generated on the basis of paths ordered.
Where conflicts arise between train movements of differing rankings, LUKS-S allows for two different modes of procedure. A rigorously priority-based approach will only allow conflicts to be resolved by means of changes to the lower-ranking train movement. And a partial priority approach permits reasonable consideration to be given in model form to the latitude exercised in real timetabling.

Operation simulation models interaction of environment and dispatching

Simulation of the running of traffic scrutinises the ability of an already compiled timetable to deal with unforeseen disruptions. The timetable may be compiled manually by the operator, but there is also frequently scope in medium-term planning for importing a pre-compiled timetable from an external tool. It is also possible to use the outcome of a previous timetabling simulation as a basis. Conflicts are detected and resolved asynchronously as a means of mapping anticipatory dispatching at operation control centres. Train movements, by contrast, are simulated synchronously so as to be able to map any unforeseen disruptions.
The basic idea is the simulation of two independent agents referred to as “Environment” and “Dispatcher”. The two agents are simulated by two modules working in parallel whose data are kept separate.

“Environment” synchronously simulates the work of the train driver and traffic controller. It monitors the speed of train movements and memorises their current location. “Environment” additionally simulates the setting of routes and signals and incorporates disruptions into the proceedings at random. There is no complex resolution of conflicts at this level; track-occupation conflicts are exclusively resolved by the simulated traffic protection system, i.e. by means of stop/start driving.

The “Dispatcher” agent simulates the work of dispatchers at operation control centres. It does not have access to the Environment data and hence has no precise knowledge of the current status of train movements, being required instead to compute a forecast on the basis of telegrams sent by Environment. Any conflicts arising in the forecast are resolved by asynchronous means. Departing from the current operating situation, therefore, a rescheduled timetable is arrived at that is then forwarded to Environment.

Two agents incorporate strengths of asynchronous/synchronous worlds

Purely asynchronous procedures operate by definition without chronological constraints and allow train movements to be removed at any time. Any disruptions arising are known when simulation begins, therefore, and can be observed in their entirety. Disruptions do not arise unexpectedly as a result, thus being stripped of their most essential quality.

Purely synchronous methods, on the other hand, whilst being capable of portraying the unexpected occurrence of disruptions, are weaker when it comes to mapping anticipatory, wide-area dispatching.

So as to harness the strengths of the two approaches whilst avoiding their various weaknesses in reflecting reality as far as possible, LUKS-S adopts a novel procedure combining the synchronous and asynchronous approaches.

Merging synchronous and asynchronous strengths

The running of services consists of a cyclical interaction between these two agents and a model clock. The model clock advances by one second at the start of each cycle. The Environment agent then acts, allowing trains to negotiate the network for one second. It incorporates disruptions whilst at the same time using slack in the schedule to reduce delays. If any special events such as the restoration of a signal or the commencement of a train movement occur during this step, Environment sends a telegram to Dispatcher.

Dispatcher processes incoming telegrams and arrives at a forecast on their basis. Any conflicts arising are resolved taking account of the time on the model clock. raffic-regulation decisions such as changes to routes or stopping times are forwarded to Environment as commands. The cycle is completed upon this being done. It is repeated until the final train movement has reached its destination.

Forming the basis for the running of traffic is a conflict-free timetable. This must be either predefined by the operator or automatically generated with the aid of the timetable simulation facility. LUKS-S also provides the means for conducting dual-tier simulation exercises in which, first, a conflict-free timetable is designed to suit paths ordered and then its robustness is tested by actually running it.


Timetable construction and scheduling

LUKS-K – Timetable construction and scheduling

Based on the train movement information given in the train editor, the LUKS-K module facilitates the interactive fine-tuning of schedules and thus provides a convenient means of visualising and processing train movements, especially using the integrated conflict detection.

LUKS-K offers two different views towards the timetable construction

  • network view
  • track occupation plan.

Network view

Using the common layout of all former editors (e.g. infrastructure or train editor), the network view provides the visualisation of the time-space trajectories of train paths combined with the associated blocking-time sequences and buffer times. Of course, several detail information can be displayed for any blocking.

The intuitive interface allows different interactive tasks like

  • Variation of dwelling time by

    • Drag’n’drop shifting of departure
    • Direct entry of stopping time
    • Setting of departure time
  • Bending of path by

    • Drag’n’drop moving of path
    • Modification of absolute time supplement
    • Modification of relative time supplement
    • Setting of arrival time
  • Shifting of path by drag’n’drop moving

  • Changing of routing by

    • Graphical selection in infrastructure
    • Textual selection of route
  • Further possibilities

    • Addition of overtaking stop
    • Enlisting conflicts
    • Complex bending

Track occupation plan

Given the tracks defined in the appropriate editor, LUKS-K can also compile a view for station tracks, which provides a sophisticated way of timetable respectively train data editing while focusing on a single station.

Again, several (interactive) tasks like changing the arrival and/or departure time or the used track are supported, while the running and blocking time calculation foresees potentional conflicts even beyond the considered station.


WordPress Appliance - Powered by TurnKey Linux