LUKS as an independent, encapsulated
central interface

Microscopic services for demand-oriented use by other tools

LaaS (Luks as a Service) provides known and proven functionalities of LUKS as an independent, encapsulated, and central interface, with which microscopic services such as microscopic routing, travel-time calculations and resulting occupancy calculations, and conflict detection can be implemented for simple and demand-oriented use by other tools.

LaaS uses microscopic databases from LUKS as a source of basic data, meaning that LUKS is a very powerful tool for maintaining and managing microscopic data, including various import interfaces in different formats, and can be used to provide data for LaaS. LaaS uses all the information for calculations that is also used in the LUKS interactive tool and it largely configurable.

LaaS offers the previously outlined microscopic functionalities as GUI-free services for use by IT clients, i.e. calling tools/applications. Following this paradigm, LaaS offers various dialects and interfaces that have been coordinated and developed with individual IT clients and also offer generic information services as a general service:

• “Info” dialect: this interface provides a large number of parameterizable query options that can be used to query various aspects of an addressed infrastructure or master data. For example, these include lists of existing operating locations with various detailed answers, available train types, train classes, traction units or route lists and more.
• “MoD” (Micros on Demand) dialect: this interface mostly offers macroscopic client applications – cooperation with Viriato (SMA+) in particular has been implemented and optimized here in recent years – the possibility of having detailed microscopic information calculated using context-free or macroscopic queries. This includes an efficient path finder with a routing algorithm that reallocates to microscopic infrastructure based on requests of very different granularity and reports this back in fine granularity, a subsequent travel time and occupancy calculation or – if several trains are requested – an evaluation of microscopic conflicts between the trains as well as detailed calculations of minimum train sequence times between them.
• “Timetable” dialect: this interface offers important functions of centralized timetabling. The contextual freedom of requests is removed for this dialect; trains with different requests interact with each other and may lead to conflicts. Based on this persistence of trains, further functionalities such as the search for conflict-free routes and the reservation and incorporation of found train routes into the existing timetable are possible.

All dialects described above run centrally or locally as services without user interfaces and therefore primarily represent functions used by third parties.