For better understanding of the system, it would be nice to add some kind of instructions when you visit the simple driver client (also called "game" client in the past). Explanations should be displayed next to the interface elements they are referring to. Furthermore, the Emergency brake/auto-stop message should be improved to better convey why the train was stopped at this point.

• Destination Selection
• Destination/Signal symbol whilst driving
• Emergency Stop/signal overrun

• Make use of bidib_set_peripheral and bidib_get_peripheral in the server
• Add settings for peripherals in command line and web clients
• Add interlocker upload to client.html and command line client

File in question: server/src/handler_upload.c
Method: interlocker_is_unremovable(const char name[])

The char array being compared here is interlocker_deafault (unremovable), but it should be interlocker_default (unremovable).

File in question: server/src/handler_upload.c

Description: In the methods handler_remove_engine and handler_remove_interlocker, we want to NOT fulfill the request if the name of the object to remove is null OR the name equals the name of the default object which is supposed to be unremovable.

In handler_remove_engine, the check looks like this:
if (name == NULL && engine_is_unremovable(name)) { //not allowed, error message }
which means: If the name is null AND the name matches the name of the default object which shouldn't be removed. This should be an OR instead. Because the name of the default object is not 'null', this if condition can never evaluate to true.

The problem is pretty much the same in handler_remove_interlocker; a logical OR needs to be used instead of a logical AND.

Consequences: If this is not corrected, the default (supposedly unremovable) objects could maybe be deleted.

Fix: Switch && to ||.

Branch: game
In the source file handler_driver, in function is_forward_driving, on line 134, a bidib query is made: t_bidib_id_list_query rev_query = bidib_get_connected_reversers();.
The struct in question holds a member of type char**. Bidib documentation says that the caller shall free the memory allocated. This is not done (afaics). Same thing with the query on line 142/143 in the same function.

Driving with automatic interlocking -> after route has finished (client: drive_route), the route should be released.

Sometimes, the route is not released.
In such a case, where the route wasnt released, a subsequent shutdown command did not complete and blocked indefinitely.

The game destinations become unsorted after running the generator.py script.

• Update extra_config.yml with better orientation information for overlaps and signals involved
• Add a monitor function (get_block(block_id, orientation)) to return an array of signal and segments in their order of occurrence according to orientation
• Update YAML parser for interlocking table (signals) and extras (signals and segments)
• Implement bool is_type_segment(const char *id)
• Implement bool is_type_signal(const char *id)
• Extend the monitor with methods to query whether an id is a segment or signal

• server/src/dynlib.c
  • dynlib_load_interlocking: proper error checking
• interlocking_algorithm.c
  • No longer needed
• interlocking_bahndsl.c
  • Integrate into dynamic containers and handler_controller
• bahn_data_util.h
  • rename initialise_config, free_config, init_cached_track_state, free_cached_track_state with bahn_data_util namespace
• interlocking.c
  • remove uses of get_route_str
• Rename interlocking to interlocker
• Rename src/interlocking to src/interlockers
• Make sure that bin/engines and bin/interlockers are removed on "make clean"
• Fix whitespaces

The Python-client implements methods for most admin/controller/driver/monitor endpoints offered by the server. However, engine and interlocker upload and deletion is not implemented.

I will add engine upload/deletion to the Python client in a new development branch. I'll take a look if the same can be done for interlocker upload/deletion. Finally, I'll create a pull request once it is confirmed to work as expected.

Some .h files in the server source do not import/#include the headers where the types used are defined. This is completely fine for compilation, as the includes are dealt with as part of .c files and build setup.
However, language servers such as clangd will complain about missing type definitions when working on the codebase in, e.g., VSCode. A quality-of-life improvement would be to add the necessary imports to the headers.

The headers in question are, as far as I can see:

• dyn_containers
• track_config_parser
• handler_admin
• handler_controller
• handler_upload
• tick_data

I'm not sure if dyn_containers and tick_data don't have any includes for ForeC-toolchain related reasons.

Add a time tracker to the interface with the session time or the route driving time

In configurations/swtbahn-standard/bidib_track_config.yml, the assignment of values to platformlights' on/off ids are inconsistent to those used for the sync and lanterns.

Change the values for on/off below ...

SWTbahn Server crashes after Shutdown has been press, followed by a another Startup of the System.

This issue occured after the following input combination:
Ping (OK) -> Startup (OK) -> Shutdown (OK) -> Ping (OK) -> Grab Train (System not running or train not available!)
-> Startup (OK -> Server Crash) [GLib:ERROR:../../../glib/ghash.c:377:g_hash_table_lookup_node: assertion failed: (!g_atomic_ref_count_compare (&hash_table->ref_count, 0))
Aborted] {BIDIB Lights}

Fixed by @eyip002

Add an endpoint that returns the name of the model railway (e.g., swtbahn-full).

This name is currently not defined in the config files; one workaround could be to use the name of the folder the config files are located in.

When trains stop, their headlights no longer switch back to their physical forward direction. For example, when a train reverses and then stops, the train headlights remain in the reverse direction. Thus, it is no longer possible to know the physical direction of the train.

• Remove the backwards option when setting train speed
• Add option to swap the train head with its tail

Interlockers cannot be run continuously because they will keep granting the same routes according to their inputs.

• Don't execute an interlocker instance once its output_terminated == true && strncmp(interlocker_instance->output_return_code, "") != 0
• Reset interlocker instance before each route request

Signal and point lists have to be updated.

Give feedback to the user when their connection to the server is broken, either because of an internet disconnection or server restart:

• Client device has lost internet disconnection: Display modal warning dialog saying that their internet has been disconnected, with a Reconnect button to try and reconnect to the server
• Server restart (shutdown + startup): Session ID on the client becomes expired and the user has to reload the webpage. Display a modal warning dialog with a Reload button saying that the user has to reload the page.

Via the request on endpoint monitor/reversers, we should be able to get status information on the reversers. For this, the startup command must've been sent before, and there must exist at least one reverser on the track and in the config.

On our SWTbahn-Full, we only get the expected reply (containing the reverser status) iff a train is on the segments related to/wired to the reverser. If a train is somewhere else on the track, we get OCS_NOT_IMPLEMENTED (i.e. line 432) and the server logs Request: Get reversers - unable to request state update. In other words, the reversers_state_update call returns true.

From looking at the reversers_state_update implementation, the way that the return works does not reveal where exactly the error occurred. Either bidib_request_reverser_state returns the error, or all queries that succeed have the state value BIDIB_REV_EXEC_STATE_UNKNOWN.

My suspicion is that this is either due to libbidib, or the protocol working in a different way than expected.

Currently, for the swtbahn-cli web-client, the jQuery and Bootstrap dependencies are loaded from a CDN.

Firstly, this is problematic if the model railway is to be used with no internet connection, for example when the clients connect via a hotspot offered by the same device that the server is running on.

Secondly, it might be problematic regarding EU data protection laws.

To be on the safe side, we shall try serving Bootstrap and jQuery locally. For this, we have to test whether the page loading speed is negatively impacted, and whether this is legal/possible from a license standpoint.

The track layout for SWTbahn Standard as defined in the config.bahn with an anti-clockwise reading. This means that point1.straight should be connected to buffer3.up, rather than the following:

Make use of intermediate signals to turn them red during route driving

This issue concerns the drive_route function as present starting on line 107 in file server/src/handler_driver.c.

The loop commented with "// Wait until the next segment is entered" (Line 152) can only ever be exited if the server is being shut down or if the train enters one particular 'next' segment (path_item). When driving in practice, the train is sometimes lost or recognized as a different train for a few seconds. If the train passes over the expected next segment during this time, the loop will never be exited (until shutdown).

Outline for possible solution: Check for entering of any segments still "left" on the route. If a segment further ahead is entered, skip looking for the current segment. Note: This must be implemented with routes in mind that can enter the same segment twice along a route.

The simple web clients in /server/src/assets report a generic error message when the server encounters a problem. The server logs more detailed error messages to syslog, which should also be passed as a response to the web clients.

Use BahnDSL command line compiler to generate shared object file: https://github.com/trinnguyen/bahndsl/releases/

bahnc -m library -v default.bahn

• Clear out the engine and interlocker bin folders on startup
• When a model upload fails, delete the uploaded *.sctx file and intermediate compilation artefacts

Update to make use of intermediate signals and to check whether a path item is a segment or signal.

The Kehrschleifenmodul actively reverses the block's orientation, but the reversal is dependent on whether train exits the block from where it entered. There is no reliable method to correctly infer the train's orientation when it stops in the reversing loop.

Debugging an unresponsive swtbahn-server:

• Execute the server through a debugger:
  • gdb ./swtbahn-server and then run /dev/ttyUSB0 ../../configurations/swtbahn-standard/ localhost 8080, or
  • lldb ./swtbahn-server /dev/ttyUSB0 ../../configurations/swtbahn-standard/ localhost 8080
• Start the Python client: ./swtbahn config localhost 8080 master
• When the server becomes unresponsive, use the Python client to get debugging information about the dynamic train engine containers: ./swtbahn monitor get-debug-info
• Abort the server using ctrl-c
• bt for backtrace
• info threads to see all threads
• thread ID to switch to the backtrack of thread ID

Backtraces generated when swtbahn-server becomes unresponsive:

#3  0x0002981c in dyn_containers_set_train_engine_instance (grabbed_train=0x4a28c <grabbed_trains>, train=0xb2b64426 "cargo_db", engine=0xb2b64436 "libtrain_engine_default (unremovable)")
    at /home/pi/Desktop/SWTbahn/swtbahn-cli/server/src/dyn_containers_interface.c:388
#4  0x0002cae8 in grab_train (train=<optimized out>, engine=<optimized out>) at /home/pi/Desktop/SWTbahn/swtbahn-cli/server/src/handler_driver.c:287

#2  0x76a52fb0 in usleep (useconds=<optimized out>)
    at ../sysdeps/posix/usleep.c:32
#3  0x00019a80 in dyn_containers_set_train_engine_instance ()
#4  0x0001d7a4 in grab_train ()

#2  0x76a52fb0 in usleep (useconds=<optimized out>)
    at ../sysdeps/posix/usleep.c:32
#3  0x00019c2c in dyn_containers_free_train_engine_instance ()
#4  0x0001d2b0 in free_train ()

Probably fixed:

#1  0x76cb5f44 in __GI___pthread_mutex_lock (
    mutex=0x3d3e0 <grabbed_trains_mutex>) at pthread_mutex_lock.c:80
#2  0x0001d5e4 in grab_train ()

#1  0xb6cb9f44 in __GI___pthread_mutex_lock (mutex=0x3a3e#0  __lll_lock_wait (futex=futex@entry=0x3a3e8 <grabbed_trains_mutex>, private=0) at lowlevellock.c:438 <grabbed_trains_mutex>)
    at pthread_mutex_lock.c:80
#2  0x0001c6cc in train_grabbed (train=0xf9c06 "cargo_db")
    at /home/pi/Desktop/SWTbahn/swtbahn-cli/server/src/handler_driver.c:79

#1  0x76cb5f44 in __GI___pthread_mutex_lock (mutex=0x3e3bc <start_stop_mutex>)
    at pthread_mutex_lock.c:80
#2  0x0001b928 in handler_startup ()

#2  0x76a4ffb0 in usleep (useconds=<optimized out>) at ../sysdeps/posix/usleep.c:32
#3  0x0001aa80 in dyn_containers_free_interlocker_instance ()
#4  0x0001c30c in free_all_interlockers ()

File Upload failed after pressing file upload before startup, followed by a file upload after pressing the Startup button.

The Bug occured after the following inpuit combination.
Upload (Engine train_engine_eugene.sctx could not be compiled or loaded!) -> Startup (OK) -> Upload (Engine train_engine_eugene.sctx could not be compiled or loaded!) -> Startup (System already running!)

This bug could not be reproduced.

In dynlib.c, Kieler is referred to/found via the expected environment variable "KIELER_PATH": [..] java -jar \"$KIELER_PATH\"/kico.jar [...]
Meanwhile, BahnC is expected to be on the path: bahnc -o %s/bahnc [..].

This should be made consistent, and we should add this information (the need for these variables) to the README.

The peripherals should all be of type peripheral. Extend peripherals to support required GPIO port (high and low) address (0x????).

peripherals onecontrol1
  onebit sync1 0x06 port 0x0027
  onebit lanterns1 0x07 port 0x0018  # Exact port address is not essential
end

peripherals onecontrol2
  onebit sync2 0x06 port 0x0027
  onebit lanterns2 0x07 port 0x0018  # Exact port address is not essential
end

peripherals:
  - id: sync2
    number: 0x06
    port: 0x0027
    aspects:
      - id: on
        value: 0x00
      - id: off
        value: 0x01
    initial: on
    type: onebit
  - id: lanterns2
    number: 0x07
    port: 0x0018
    aspects:
      - id: on
        value: 0x00
      - id: off
        value: 0x01
    initial: on
    type: onebit

Feedback: Switch the color of not availiable trains red at SWTbahn drivers game

When startup is called for a running swtbahn-cli server, the default interlocker libraries and the default train-engine libraries are loaded dynamically. The lib files are located at server/src/interlockers and server/src/engines respectively (.so and .dylib files).

These shared libraries were compiled on a particular device at some point. Not sure exactly where/how. Regardless, the current precompiled libraries can't be loaded when running the swtbahn-cli server on an x86_64 linux device (in this case, running Kubuntu 22.04 with kernel 5.15.0-46). Loading them results in header/ELX (ELF?) conflicts, which is not particularly suprising, assuming that they were compiled on a different architecture and with a different kernel.

To be able to run the swtbahn-cli server on an x86_64 linux device, one has to re-compile new default engines and interlockers, and place them in the appropriate locations. Whilst that is technically possible, there is no source file for the default train engines, at least not in this repository. For the interlockers, there are two source files which can be used.

I see multiple possible solutions:

• Supply the source for default train engines and re-compile them on demand upon startup, should loading the default libraries fail
• Supply additional precompiled libraries explicitly for x86_64, that are loaded if loading the standard loading fails (or, smarter: use preprocessor to directly load the appropriate libraries).

Any changes to the handling of these libraries must be tested on Mac/Apple as well; if possible also with newer ARM based Macs.

Note: This is not a high-priority issue.

Implement the remaining interlocker instances to support multiple track controllers on the same railway platform.

For executing systematic tests with MBT-Tools, it is advantageous to be able to query the position of a train.

handler_driver already implements train_position_is_at, but there is no way to query it from outside.
Proposal: Implement a onion/http-requestable method for retrieving the current position of a train in handler_monitor. handler_monitor should be the right place, as it is already implementing handler_get_train_state, which goes in a similar direction. This could also be implemented in handler_driver, but that'd imply that only the driver is allowed to query the position of their train.

Alternative: Include the current position of a train in the method handler_get_train_state of handler_monitor, which currently only says if the train is on the track, but not where.

If there already is a way to get the segment/block that the train is on, this issue can be closed.

Two options:

• 1. Create a debug request handler that will dump the contents of dynamic container related data structures to the console.
• 2. Create an automatic tracing thread that periodically writes the contents of dynamic container related data structures to a file.

File in question: server/src/handler_upload.c
Method: handler_upload_engine

The compilation of a train engine could fail in the C compilation OR the shared library compilation. This is not reflected in the log message:

dynlib_status status = dynlib_compile_scchart(filepath, engine_dir);
if (status == DYNLIB_COMPILE_SCCHARTS_C_ERR || status == DYNLIB_COMPILE_SHARED_SCCHARTS_ERR) {
	syslog_server(LOG_ERR, "Request: Upload - engine file %s could not be compiled", filepath);
	[....]
}

Request: Note the reason which compilation failed in the log message.

Bahn configuration file has been updated with new signal types, peripherals, layout, and signal aspects.

• SWTbahn Lite
• SWTbahn Standard

(Feature Request)

The experimental feature for verification of train engines upon upload shall be integrated into the main branch.
With additional functionality: An Admin shall be able to enable or disable whether engines are verified upon upload. An Admin shall be able to do so via a web-interface akin to those existing for drivers and controllers. Furthermore, this shall be possible via the Python client as well.

I'll work on implementing this functionality. I'll do so on the verify_engine_models branch.

For automatic route driving, the driving direction is determined automatically.

When a train is on the reverser, this is not trivial. And there seems to be one scenario where we get the driving direction wrong.

Scenario where it works: Train is oriented/driving in a clockwise direction, on a route that has the destination signal 35a (on the reverser area). Train enters the reverser area from point 23. Is automatically stopped upon reaching the overlap at signal35a (T64). Now, selecting a new route from either signal35a or signal32 will result in the correct driving direction in automatic mode.

Scenario with the problem: Train is oriented/driving in a clockwise direction, on a route that has the destination signal 32 (on the reverser area). Train enters the reverser area coming from point 24. Is automatically stopped upon reaching the overlap at signal32 (T62). Now, selecting a new route from either signal35a or signal32 will result in the wrong (inversed) driving direction in automatic mode!
When the train reaches segment 62 (signal32), we can hear the click of the relais of the reverser.
If we drive the route to signal32 in manual mode and stop before reaching the overlap (and then manually release the route), the subsequent route direction is determined correctly.

So either this is...

• linked to issue #120, and the reverser status is read incorrectly when/after the train touches segment 62; or
• the code for determining direction is buggy in some other way.

Needs some more investigation on the implementation side.

When shutting down via the admin endpoint, the interlocking container is not released in some cases, potentially causing a segmentation fault on the next startup.
Missing in the log:

server: interlockerInstance0: Released container

Procedure using the python cmdline client:

1. driver grabs a train that is on the tracks
2. admin force-releases that train
3. driver tries to grab a new train -> "you can only grab one train!" (<- this is printed because the admin release does not reset the grab id that the python client has saved, thus it thinks the driver has already grabbed a train)
4. driver tries to release their current train -> "System not running!" (<- server rejects, and python client prints out completely incorrect error message in all cases)

There should to be a way to properly reset the grab_id on the python client side, i.e., to synchronize with the server to some degree.

Currently, the API returns results in a pure text-based manner, with some similar formats across different handler, but without a specification for it. This makes parsing a chore.
A common formatting standard (e.g., JSON) should help make parsing easier. However, which standard to choose and how to name its fields has to be discussed still.

Libbidib now has the option to be installed in a include directory such as usr/local/include. This allows the swtbahn-cli cmake setup to be (more) portable. However, it does require a change in the include paths in .c and .h files. Bidib now has to be included with <bidib/bidib.h>, not <bidib.h>. This new schema is consistent with how we include onion.

I'll add the required changes to the Cmake setup and the includes.

When train engine or interlocker models are uploaded, their safety properties shall be verified by an external application (swtbahn-verifier).
I shall start working on integration of the required changes (we need a websocket client) in an experimental/dev branch.