LUKS – Analysis of lines and junctions

The LUKS software tool is an integrated system for several types of railway operations research. 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.

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). It is used in Norway at Jernbanedirektoratet for simulation purposes as well as at Azerbaijan Railways CJSC for timetabling.

Overview and core features of LUKS

Individual approaches for different scopes

To validate and analyse the consequences of infrastructure and/or timetable changes, several approaches exists. LUKS supports the following established approaches.


Queuing (or the analytic approach) is applied to perform a long- to mid-term evaluations of infrastructure variants or timetable concepts. 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).



Simulation is applied to perform mid-term to short-term evaluations with comprehensive consideration of constraints. LUKS supports two modes of simulation:

  • 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 with random delays.



Timetabling 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).


Compression / UIC code 406

Based on a given timetable, the UIC 406 concatenation approach can be performed for several investigation and evaluation areas, time windows and under various parametric configurations. LUKS can therefore be considered as a generic toolbox implementing the concatenation approach but leaving wide flexibility to define infrastructure manager specific characteristics and rules.


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.

  • Extensive 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 and write different formats of infrastructure and timetables.

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.

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

Efficient infrastructure modification

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.

Interlocking routes are the basis for the train’s path.
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.

LUKS Calculation

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

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”:

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 timetabling and operation

LUKS-S – Simulation

LUKS-S offers simulation of timetabling and railway operation. Both simulation modes operate on the microscopic infrastructure and train data.

The simulation of timetabling provides information on whether a given operating schedule is viable, i.e. whether it is possible to construct a conflict-free timetable that contains the envisaged train movements.

The simulation of operations scrutinizes the ability of an existing timetable to deal with unforeseen disruptions. Train movements are simulated synchronously to be able to map any unforeseen disruptions. Conflicts are automatically detected and resolved to simulate the anticipatory dispatching at operation control centers.

Automatic conflict detection and resolution

The simulation in LUKS does not require the user to detect or solve conflicts manually in any way. It automatically detects any overlapping of two blocking-time and solve them with a number of possible conflict resolution options. The following courses of action are considered:

  • alter the route within one or more stations

  • alter the sequence of stations

  • change of running times (different speed profile)

  • alter the stopping time

  • insert passing and crossing stops

  • change of train’s start time

  • trimming

All potential conflicts resolutions are tested and evaluated with the microscopic data model. This allows a very realistic evaluation of the effects. The option with the best evaluation is then put to effect. The used objective function is highly configurable to model different conflict resolution strategies and goals.

Where conflicts arise between train movements of differing rankings, LUKS applies a partial priority approach. This permits reasonable consideration to be given in model form to the latitude exercised in real conflict resolution.


The simulation of timetabling turns a conflicted operating schedule into a conflict-free timetable using the automatic conflict detection and resolution. If the infrastructure does not have the capacity to handle all desired train trains, the simulation rejects some of them.


This simulation modes works on two levels to properly model railway operations.

On the field level, it synchronously simulates the work of the train driver and the interlocking system. It monitors the speed of train movements and memorizes their current location and status. It additionally simulates the setting of routes and signals and incorporates disturbances into the proceedings at random. There is no complex resolution of conflicts at this level; track-occupation conflicts are resolved by the simulated traffic protection system, i.e. by means of trimming.

On the traffic control level, the current status of all trains and the microscopic running time calculation are used to create a forecast of the future situation. Any conflicts arising in the forecast are handled by the automatic conflict detection and resolution. The anticipatory approach reduces the risk of deadlocks. This level regularly creates rescheduled timetable and forwards them to the field level.

This simulation mode also offers a batch mode. The batch mode allows the automatic simulation and evaluation of a large number of runs, each one with different random disturbances.


The simulation results can be evaluated inside and outside of LUKS. The build-in evaluations include:

  • All conflict resolution: What was done and why? It is also possible to take a look at all considered alternative solution including their evaluation.

  • Delays in each station: Average, quantiles and punctuality

  • Disturbances: All events that randomly occurred during the operations

  • Waiting time, changes in delay

  • Level of infrastructure utilization

  • Running time quotients

  • Rescheduled timetable: The actual trajectories and speed profiles of all trains

  • Detection of infrastructure bottlenecks

The results can also be exported to CSV (Excel/Access), OTT and railML-TT. This allows additional evaluation of the results outside of LUKS.


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.


Compression / UIC code 406

LUKS-C – Compression / UIC code 406

LUKS-C implements capacity evaluation functionalities following UIC Leaflet 406 “Capacity”. Starting with a timetable provided by LUKS-K, the UIC 406 concatenation approach can be performed for several investigation and evaluation areas, time windows and under various parametric configurations. LUKS-C can therefore be considered as a generic toolbox implementing the concatenation approach but leaving wide flexibility to define infrastructure manager specific characteristics and rules.


WordPress Appliance - Powered by TurnKey Linux