This article is structured according to the dialogue fields - but when it comes to getting started and constructing the very first timetables, then the "cookbook" is recommended first: Cookbook: Creating a Simple Timetable
Timetables are made up of the following components:
- Wagon sequences: Definition of vehicles (either concrete vehicles or trains or groups from which vehicles and/or trains are randomly selected); you can see how these work exactly in the linked article.
- Stations: Grouping of several stops and tracks with "the same name", i.e. which belong together because they are part of the same station, together form a bus and/or tram node - or simply two stops are connected in opposite directions. Stations usually include bus and tram stops, whereas metros and possibly light rail have their own stations, as do suburban, regional and mainline trains, which are usually organised in the same station. In addition, stations are also defined as stations or points that are used exclusively for operational purposes, e.g. marshalling yards and depots, block stations, junctions, etc., i.e. in the case of railways everything that is not an "open track".
- Days of operation: In order to have the possibility of different tours taking place on different days, it is possible to specify for tours and courses on which days they should be active. In order not to have to explicitly select all possible days in all possible places, these are combined into respective "sets", the so-called operation days, e.g. "Mon-Fri without public holidays". This makes it possible to quickly access these traffic days later and to be sure that the same thing is meant each time.
Routes: In order to define trips later, a framework of individual routes is first put together. Parallels should and can be dispensed with here, as the concrete journeys can also be travelled along several different route sections one after the other and only parts of a route need to be used in the process. Routes already contain information about the tracks usually to be used and transit times for the individual stations for any number of profiles (e.g. time periods) (in each case for both directions).
Example: The Berlin underground lines U1 (Uhlandstraße <=> Warschauer Straße) and U3 (Krumme Lanke <=> Wittenbergplatz) could each be created as a route. However, it is not necessary to define a separate route for a continuous trip from Warschauer Straße to Krumme Lanke, as these journeys simply use part of the U1 route first, namely from Warschauer Straße only to Wittenbergplatz, and then the entire route from Wittenbergplatz to Krumme Lanke. Incidentally, this is also directly an example of the fact that although tracks can also be defined within routes, these can also be changed when defining the individual journeys later. Otherwise it would not be possible to find a common track at the transition of the U3 to the U1 (U1 eastbound runs on a different track than the U3 at Wittenbergplatz).
- Ways: A way defines the concrete guidance of trips through the previously defined routes. Here, the tracks to be used and the passage times can be adjusted again.
- Trips: A trip is the combination of route and first departure time under selection of one or more profiles. Such a trip represents a separate and independent unit, can be given a name or number, among other things, and can be equipped with vehicle/train parts, which then define which type of vehicle(s) are used.
- Lines/courses: In local transport, it is common to combine trips into lines with courses. In particular, the registration and identification with the control centre with the corresponding device in the vehicle is also carried out and organised via this specification. A course consists of a series of consecutive trips in the way they are usually carried out by a specific vehicle. Nevertheless, it is possible that a specific vehicle or train (part) leaves the course and, if necessary, the line and performs another journey. This brings us thematically to...
- Tour: A tour describes the exact and concrete sequence of trips that a specific part of the vehicle has to make. The emphasis here is actually on "part", because even if a trip is carried out with a double traction or similar, it can happen that this traction is split up at some point and travels along different routes - and thus both must of course be planned separately from each other. The individual tours are combined into tour plans, which are created per vehicle section and per traffic day combination: If, for example, a "shopping bus line" runs from Monday to Saturday and another, a school bus line, only from Monday to Friday, and if both lines are operated by the same vehicles with possible line changes, then there are a total of three combinations of traffic days, for each of which circulation schedules are created: Monday to Friday (both bus routes must be scheduled), Saturday (only the shopping bus route must be scheduled) and Sunday (there are no trips at all).
The timetable planning ends with the definition of the tours; all information is now available to carry out timetabled traffic, both for real players and for AI vehicles.
2 First of all: The button "Refresh ways and trips"
In order to avoid constant long waiting times with more extensive timetables, certain properties of the lower levels (e.g. station tracks of paths) are not immediately copied to the higher levels (especially trips) when making changes.
To be on the safe side and at the latest in case of irregularities of any kind, the button "Refresh ways and trips" should therefore be clicked at the end in cases of such changes!
The list of stations can be found in the MapEditor on the left in the "Stations" section. From there, further stations can be created with "+". Both then and by double-clicking on a station or clicking on the button with the rectangle, the station dialogue box is opened and at the same time the 2D map appears on which all tracks and road paths as well as points and stops can be seen. The 2D map can be closed independently of the dialogue box and reopened with "Call up map..." at the bottom of the dialogue box.
3.1 Basic settings
The following basic settings are at the top:
- Internal name: Name under which the station appears primarily in the MapEditor, but also in operational areas in the simulator.
- Public name: The station always appears under this name in the simulator when it appears publicly to passengers. If no name is entered here, the internal name is used. In simple cases, therefore, a public name can be dispensed with.
- Abbreviation: In reality, stations and operating points are almost always provided with abbreviations and in the MapEditor - if specified - these are also often used if it is useful for clarity. If no abbreviation is given here, the internal name is used if necessary.
- ID for PIS: Whenever a link to PIS groups is necessary, for example when passengers are to compare the connection between the station and the described destination, this ID is used. If the entries in the PIS group are identical to the internal name or no connection to the PIS group needs to be established, this entry can also remain empty. If necessary, the internal name is used here as well.
- Public priority: For appropriate purposes, LOTUS and the MapEditor should know to which category this station belongs. These are described accordingly in brief, starting with the highest priority stations ("most important long-distance stations") and ending with the lowest priority for stations with passenger service and finally the variant that it is not a station with passenger service at all (e.g. for service stations or block stations etc.). However, this setting has no influence on the generated traffic demand and thus the number of passengers to be transported. For bus, tram and underground only the last categories "public transport node", "important for public transport" and "normal public transport stop" should be selected; if, on the other hand, the S-Bahn stops at a very large long-distance station, this is of course included accordingly and thus also operates at a station of the highest category (e.g. Berlin Hbf.).
- Protocol: Errors or implausible data are output here.
Below this is the section in which the individual tracks or stops are defined. This includes:
- Individual bus stops, e.g. a specific direction of travel or a specific bus platform
- Platform tracks of the road, underground, urban railway or railways
- Stabling and shunting tracks in a railway station
- Entry and exit tracks of a station, i.e. the transition from the station area to the open track, usually restricted by the entry signals and signs "Stop for shunting movement".
In the further course, only "tracks" will be referred to for the sake of simplicity, but the procedures shown apply equally to the bus trips (if sensible).
Tracks are defined by first clicking on "Add" under the track list. If an entry is then marked, track paths can be added as follows: First the button "Add elements on map" under the stop list must be clicked. This highlights the button. Now all paths belonging to the track can be clicked on in the map window (if necessary, open by clicking on the "Open map..." button); clicking again resets the selection. For bus stops, the corresponding street paths are selected and the associated bus stop is also selected. Depending on whether only track paths or street paths plus bus stops are selected, a [T] or a [B] appears at the front of the track entry in the track list. However, if a ?[T][B]? appears there, then a mixture of both has been selected and LOTUS cannot classify whether it is a road stop or a railway track. At the end, the process can be completed by clicking again on "Add elements to map".
During the construction of the station track, the selected tracks are provided with a direction arrow. This is the orientation of the track, relative to which all specifications are made that refer to the direction, in particular the platform side, as well as the cardinal direction that is specified in the track list. This construction direction can be reversed by clicking on "Reverse direction" to the right of the list.
Also to the right of the list are the other properties of the selected track, which can be edited directly:
- Internal designation: This is how the track appears in internal documents of all kinds. Mostly, however, it is only a number. Prefixes such as "Gl. ..." should be avoided.
- Public designation: If different, a separate non-business designation for the public can be entered here. Otherwise, nothing has to be entered here; the internal designation is then used.
- ID for PIS: Sometimes it happens that a certain stop has its own name in public, so that, for example, the vehicle displays show a different text. In this case, an alternative ID can be entered here, otherwise the field should remain empty so that the station-wide PIS ID is used.
- Platform left/right: For tracks with the possibility of passenger entry and exit, it can be ticked here whether the exit is on the left and/or right, whereby the construction direction of the track is taken as a basis here.
Especially for stations where entry and exit is via a concrete entry/exit track as a transition to the open track, but also for operational processes within the station, it may be necessary to specify via which route the ride is made from one track to the other. This is done via the "Connections" list located in the lower area of the dialogue box. The functionality corresponds exactly to that of the tracks. The respective connection must always start with the last track section of the starting track and end at the first track section of the destination track. If this is done correctly, the start and destination track appear in the list entry of the connection. With the check mark "Auto-complete", LOTUS tries to complete the route itself as far as possible if the route is unique.
A map can have any number of timetables. A timetable is a self-contained package of routes, paths/routes, trips, lines/courses, tours and traffic days. The validity period of timetables can be limited. Several timetables can also be "active" at the same time, in which case the tours of all active timetables are displayed together when they are selected in the simulator.
The numbers in brackets before the names of the respective groups indicate the usual order in which the timetable data is entered.
In this window, the traffic days, routes, lines, tour plans, paths/routes and trips are managed, whereby all are summarised in a list in which they can be added, deleted and copied depending on their type. By double-clicking or using the "Edit" button, you can reach the respective "sub-window", which is then used for concrete editing of the respective element.
Apart from this, this window also has the following elements:
- Validity period (s.o.)
- ITCS/RBL server name: Since it is conceivable that different control centre systems operate in parallel and independently of each other on one map (e.g. bus vs. tram vs. underground), different ITCS servers can also be created for different timetables. For this purpose, a name is assigned, which must then match the ITCS/RBL server name specified in the PIS group so that the respective vehicle can log on to the ITCS server. Different timetables can be assigned to the same server by entering the same name here. All vehicles of all corresponding timetables are then registered on one AVLC server.
All operation day combinations: Displays a list of all combinations of traffic days that are valid simultaneously in the validity period.
Example: If there are the traffic days "Sat", "Sun", "Mon-Sat" and "Wednesday from June to August", and the validity period of the timetable is only in winter, then the following traffic day combinations appear: "Mon-Sat" (on weekdays), "Sat + Mon-Sat" (on Saturdays) and "Sun" (on Sundays).
"Wednesday from June to August" does not occur at all because the timetable is not valid in summer, "Sat" never occurs alone because "Mon-Sat" is always valid on Saturdays and such combinations as "Sun" and "Mon-Sat" never occur simultaneously, etc.
5 Days of operation
In the context of the LOTUS timetable module, "days of operation" always means a concrete definition that describes whether a certain day belongs to this "operational day" or not, or whether the day pf operation is "valid". Simple example: The day of operation with the name "Mo-Fr" is always "valid" if the current weekday is a Monday, Tuesday, Wednesday, Thursday or Friday. The configuration of these days is then done in this window:
Apart from the name, which serves to uniquely assign this day later, there are two blocks on the left and right that define on which days of the week the day is valid and when it should explicitly not be valid. The right-hand block "overwrites" the left-hand block if necessary.
Example: If, as shown, "Working days" is selected on the left and "Saturday" on the right, this means "Working days without Saturdays", i.e. the traffic day is valid from Monday to Friday, but not (!) if this day is a public holiday!
Below this are three lines in which a range of calendar data can be entered. This consists of any number of "blocks" separated by spaces and/or commas, each defining a single day or a range (separated by a hyphen). The blocks may or may not be annotated with years. If the entry is invalid, the respective field turns yellow.
Example: '2.3., 4.5.-7.6., 2.7.1991-5.7.1991,4.4.19-3.4.20' - this means: 2 March each year, the days from 4 May to 7 June each year, from 2 July 1991 to 5 July 1991 and from 4 April 2019 to 3 April 2020.
These three lines can be assigned to the days previously defined via the weekdays.
- Add more days (other weekdays) (1st line)
- explicit days are taken away (2nd line, overwrites 1st line if necessary)
- in principle, a limitation of all days should be made (3rd line)
Or in other words: The traffic day is basically only valid if the current day is in the area of the 3rd line (if something has been entered there). If this is fulfilled, then it must under no circumstances fall in an area of the 2nd line. If this is also the case, then it must either be in the left weekday block and not in the right weekday block at the same time or lie in the area of the 1st line.
The window is rounded off by a calendar in which you can read on which dates the traffic day is actually valid.
Routes are defined as a list of stations along which the route is to run. Accordingly, the first tab of the route window looks like this:
At the very top, outside the tabs, you can first enter the name and abbreviation and specify whether the route is to be defined in one direction only (so there are neither track details nor times for the return direction).
At the top of the "Stations" tab is the list of stations that are to be passed through or stopped at one after the other. The list is managed via the buttons below. A new station is first added with "+" and can be edited directly below it after selection:
First, the station itself can be selected, then it is specified through which tracks the trip should run: The "Stop" track is the primary track, e.g. the platform track. Often only the "stop" track is selected, for example at stops along the free route, at bus or simple tram stops. For stations, the entry or exit track is needed to define the transition to the open track. All track information must be defined for both directions, unless of course it is a one-way line.
Important: Entrance and exit tracks are not to be confused with reversing or break tracks! If a trip starts on a reversing track, then the station must be inserted twice, once specifying the reversing track as "stop", once specifying the platform track!
In the bottom right-hand corner - as in the station properties - concrete connections between any tracks of any stations can be defined, which the MapEditor uses when determining routes in the future. These connections overwrite, if possible, any automatically generated routes. Important! Connections can also be created between tracks that have not been selected in the route, e.g. if certain routes or journeys use deviating tracks and in that case the connection is to be adjusted.
6.2 Travelling time
On the second tab "Travel time profiles", any number of travel time profiles can be created for the entire route, which of course must also be defined in both directions (if it is not a set-up route). A route always needs at least one profile!
After creating and naming a new profile above, it is best to start by defining the last arrival time of the outward direction in the left block at the bottom and the last arrival time of the return direction in the right block at the top. By default, these are the only two fields that initially allow an entry, the remaining times are then interpolated depending on the distance between the stations. However, if you also want to adjust the times in between, you must first uncheck the box in front of it.
The last column in each case defines whether and how stops are to be made at the stations:
- If necessary, that is, only if someone wants to get on or off.
- Always - when the stop is completed, the journey continues again regardless of the time
- If necessary + wait for departure time: If the vehicle is late, it stops only if someone wants to get on or off. Otherwise, it stops and waits until the departure time.
- Always + wait for departure time: The vehicle stops in any case, regardless of whether someone wants to get on or off or whether it is delayed. It then waits until the departure time has come.
- Service stop - when the stop is completed, the journey continues again regardless of the time
- Service stop + wait for departure time: The departure time is waited for.
Way is a term for the "spatial" basis of the concrete trips.
The trails correspond to the routes of the PIS groups, which is why you can also assign PIS line and route numbers to trails. No leading zeros are to be entered here! Even if "02" is entered into the IBIS as a route, you only have to enter "2" as the "PIS route number".
Sections are "assembled" from route sections on the first tab:
Each section must first be created via "+" and can then be edited below: First the route is selected and then the station from which this route is to be travelled in this section is selected. Depending on which stations are selected here, the MapEditor automatically determines the direction in which the route will be travelled, which in turn is used to preselect the tracks and profile times.
On the next tab, the tracks are defined that are to be driven through in each case:
As long as the checkboxes are ticked, the tracks from the route definitions are automatically used here. As soon as you uncheck the box, an alternative track can be selected here.
The specific route is determined automatically in each case, using the connections defined in the routes if necessary.
7.3 Travelling time
The driving times are configured on the third tab:
For concrete ways, any number of profiles can also be created, which are later used by the trips. To do this, the respective profiles must first be created and named above.
Below this is the list of sections that make up this route. For each section, one of the profiles of the associated route can be selected. The MapEditor then automatically calculates the travel times along the entire route based on these settings and lists them below. However, the travel times can still be adjusted manually there.
7.4 Signal routes
The fourth tab shows the signal routes that correspond to the course of the way:
Thus, if the corresponding route is set in an appropriately scripted IBIS and the vehicle drives over a corresponding trigger, LOTUS uses the associated path to determine whether a route can be selected at this trigger that corresponds to the path. This calculation is done automatically, which is why this is purely a display field with which this function is cross-checked.
A trip "consists" of a route with a concretely selected profile and a departure time as well as information about the vehicle deployment. At the top of the window, a name is first assigned, whereby in public transport usually no names or numbers are assigned and in the "big" railway only (train) numbers are assigned. No class (IC, R, S, U...) is to be entered here!
The category is selected from the list. If other genus names are used internally, these can be entered in the free text to the right. Normally, however, nothing should be entered there.
8.2 Way and train part
On the first tab, the path and train sections are defined:
At the top, the route must first be entered and a tick can be placed to indicate whether it should be an AI-only trip.
Below this, the train parts are configured:
Vehicle deployment is managed in train parts, whereby train parts themselves cannot be separated operationally and their deployment is planned "inseparably". However, each train section can be coupled and uncoupled independently of other train sections, run on other days or only be used for part of the trip. The sequence at the start of the trip corresponds to the sequence of the train sections in the list. As soon as a station requires a change of direction, the order is reversed, of course.
Each train part has:
- a name (usually a lower case letter),
- a vehicle/train type (defined via a wagon order sub-list),
- the direction in which the vehicle or train is to be arranged (either forwards, backwards or "regardless"),
- first and last station, between which the vehicle is to be included,
- on which days of the week this part of the train is to run and
- Limits for tour planning, if applicable
A word about the operational days: There are two ways to ensure that a trip is only carried out on certain days - either a operational day is set in the train parts or the course is configured accordingly (if the trip belongs to a course). In case of doubt, however, the information in the train section overwrites the information in the course.
8.3 Tracks and profiles
On the next tab "Tracks" - as with paths - the track details that take over the trips from the paths can be adjusted manually.
On the third tab, the exact, absolute travelling times can now be configured:
First you can select one of the travel time profiles stored in the route at the top left and enter the start time to the right. Based on this, the concrete, absolute travelling times are then calculated below.
In addition, it is possible to select several of the profiles of the route in the middle area of the window and to provide them with a start time, so that the calculation is no longer based on just one profile, but a profile change takes place during the trip as soon as the corresponding time is exceeded.
8.4 Copy trips & interval group
In the main window (and also in the line window, see below), trips can be copied:
If the exit trip has a pure number as name, the MapEditor offers that the copies each get numbers that are incremented by a certain interval.
Copied trips can be created in a interval group. If a trip of the group is then edited, LOTUS offers that the remaining trips of the group are aligned. However, if this is denied, the trip is removed from the interval group.
9 Lines and course
Important: In contrast to the previous windows, the Line and Course windows are only closed by "Close" - all changes are applied immediately! (Apart from the fact that cancelling the timetable main window still leads to discarding all changes since opening the timetable main window).
The line window is structured as follows:
First: The right part of the window is zoomed by mouse wheel and moved to the left or right by keeping the mouse wheel pressed. Vertically, the display is automatically centred on the selected course. A course is selected by left-clicking on it (it must be clicked outside a trip).
The line can be named at the top and courses can be added or deleted below it. The name of the course itself can be edited underneath.
Line and course should be exclusively a number without leading zeros so that the common ITCS/RBL devices can call up this course!
On the left is a list of all trips that have not yet been assigned to a line. As soon as at least one course is available, rides can be dragged and dropped from there onto the course. Within the line/course display, the trips can be moved vertically on the courses with the mouse. By holding down the Ctrl-key, the trips can also be shifted to the left and right in time.
It is also possible to select a traffic day for a course. Attention: As mentioned above, this setting only affects train sections that do not have their own traffic day regulation! Trips that have their own traffic day regulation are marked with a small calendar symbol.
Trips can be clicked on the line/course display with the right mouse button, whereby the following options are then offered:
- Remove trip from course: The trip is removed from the course, but continues to exist and is again on the left in the list.
- Delete trip completely: The trip is completely deleted and therefore no longer appears anywhere.
- Copy trip to the currently marked course: Activates the copy function already described above, whereby the new rides are then placed on the currently centred course
- Edit trip...: Opens the window for editing the trip.
- Copy the trip to the next group: The trip itself is not copied! Instead, the trip is additionally placed on the next course, but can also be moved from this course to a completely different course. Nevertheless, both "bars" are still linked to one and the same trip.
10 Tour plan
The timetables are automatically generated by the MapEditor from the existing trips. As long as an existing timetable has not been changed, it will be completely changed again or even deleted when the journeys are changed. However, as soon as changes are made, a pencil symbol appears behind the line of the timetable. In this case, only the following is done instead of a completely dynamic change:
- if it is unnecessary (omission of entire vehicle/train types or omission of certain operational days) its name is bracketed in the list, i.e. it can be deleted in the same way, unless further changes to the trip make it necessary again
- If trips are omitted, they are only shown as chequered in the tour display.
- if trips are added, these are added in such a way that no existing tours are destroyed - if an existing tour allows the new trip to be added at the end, this is done, alternatively a new tour is created
The tour window of a concrete tour plan looks like this:
The navigation in the tour display is similar to that in the line/course display; only the vertical shifting is done by means of the vertical scroll bar.
At the top left, empty tours can be added, empty tours can be deleted and invalid trips can be deleted. Below this are options with which the display can be configured.
Each tour plan has a randomly assigned colour and on each tour is the row of trips drawn as blocks. Below the trips are the minutes of the departure and arrival time and above that the abbreviation of the departure and final stop, above that is the train number with the name of the train section. If there are trips with several train sections, stripes symbolising the neighbouring train sections are also shown above and/or below the trip bars.
In this example, trip 100 consists of two train parts, a and b. a is part of the first tour. Under the bar there is still the thin bar that represents the train part b. In the second round you can see the train part b in "wide" and above it the narrow strip of a in black. It is easy to see that train part a goes as far as "Y", but train part b only goes as far as "D".
Between them are connection lines whose appearance provides information about whether the connection is error-free or whether there are problems. If you move the mouse over a neighbouring trip, it is labelled what the problem is:
- Thick red line: Different stations
- Thin red line: Different track or incompatible train direction
- Thin blue line: the orientation of the previous trip is arbitrary, but the orientation of the next trip is not, so compatibility is not guaranteed
- Black line: Everything ok
In addition, a turn arrow ( ↩ ) appears if the direction of travel changes between trips.
If a train section has been configured to compulsorily start or end the round trip, then the start or end of the trip bar is marked in red.
If you right-click on a trip bar, you can define the subsequent trips in a dialogue box.
11 Scheduled AI
By default, ways, trips, courses and tours are configured during creation so that no AI traffic takes place. How this can be changed is now described here.
11.1 Settings - how much AI traffic should there be?
The schedule AI lever in the options in the simulation works stepwise and can be set to the following positions:
- only most important
- only important
- unimportant, too
Accordingly, there are the following priorities to set the AI in the timetable:
- None (never add AI vehicles)
- Very unimportant (AI vehicles are only added on lever position "all")
- Unimportant (AI vehicles are only added on lever positions "all" and "unimportant, too")
- Important (AI vehicles are only added on lever positions "all", "unimportant, too" and "only important")
- Very important (AI vehicles are added on lever positions "all", "unimportant, too", "only important", and "only very important")
Accordingly, of course, regardless of the priority, AI vehicles are never placed when "Off" is set in the simulator.
11.2 Effects of the priorities on the tour planning
First of all, it is very important to know that the decision whether AI will take place on the trips or not is ultimately made in the level of the turns! There can be no tour within which there are trips that have different AI priorities!
It is therefore very important to know that for this reason the preselection of the priority on the lower levels (way, trip and course) have accordingly effects on the tour planning!!!
Accordingly, already edited tours ("pencil" symbol) "keep" their priority even if the priorities in the lower levels have been changed. If a tour has been edited, it is only possible to set which AI priority it belongs to in its configuration!
The automatic tour schedules fetches the AI priority hierarchically from the settings of ways, trips and lines:
- If the trip belongs to a course, the system first checks what the setting there is. This is taken over directly, unless...
- ...the setting of the course is "like trips" or the trip does not belong to any course, then the setting of the trip is taken over directly, unless...
- ...the setting of the trip is "like way", then the setting of the associated way is used directly.
Once everything has been configured and the automatic tour planning is carried out, the trips are distributed among the tours in such a way that the individual tours only have trips with the same priority. If you are not careful, this may tear apart the tour planning, but this can of course be repaired immediately by setting the ways / trips / courses to the same priority. If, for example, different courses should have different priorities, then this can be easily corrected in the line/course dialogue.