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.

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:

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.

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.

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.

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.