This is a client-server command line interface for the SWTbahn. The server is connected to the BiDiB interface and provides a REST API. The client side provides a command line interface which connects to the web service to execute the commands. The command line interface was developed by Nicolas Gross as part of his work for the libbidib project.
kico.jar
has to be defined in the environment variable KIELER_PATH
bahnc
has to be defined in the environment variable BAHNDSL_PATH
pip3 install click requests pyaml
)ldconfig
after make install
for libbidib if you are on Linux)cmake <path-to-project-root>/server
make
To run the unit tests, execute make test
from within the build directory. Each unit test can be executed to display more detailed test results, e.g., ./server_bahn_util_tests
.
dmesg | grep tty
<project-root>/client/swtbahn
--help
flag to get information about parameters, options, ...Now you can use the commands from the categories swtbahn admin
,
swtbahn controller
, swtbahn driver
and swtbahn monitor
. If the system was
not started by swtbahn admin startup
, all the other commands won't work.
For example:
./swtbahn admin startup
./swtbahn monitor get_segments
./swtbahn monitor get_trains
./swtbahn driver grab cargo
./swtbahn driver set_dcc_speed -b 5
swtbahn admin shutdown
<IP>:<port>/assets/client.html
master
).Startup
button.Grab
button.
Enter a speed between 0
(stop) and 127
(max speed), and click the Drive
button.Set
button.Set
button.Use ssh
to the log in remotely. Suppose the Raspberry Pi is located at 141.13.106.30
.
Then use the command ssh pi@141.13.106.30
.
There are two Raspberry Pis with the hostnames raspberrypi1
and raspberrypi2
.
The Raspberry Pi documentation
lists several strategies for finding the IP address of a Raspberry Pi.
If you change the Raspberry Pi's hostname, e.g., by editing /etc/hostname
or by using
the Raspberry Pi Configuration application, Avahi will automatically change the .local mDNS address.
The MAC address of all Raspberry Pis begin with b8:27:eb
.
macOS: Try and resolve the Raspberry Pi's hostname, e.g., raspberrypi1.local, with multicast DNS:
ping raspberrypi1.local
If this fails, try the strategy for Linux.
Linux:
Use ifconfig
to find your subnet, e.g., 192.168.1._
.
Use the nmap
command to scan your subnet for connected devices,
and look for the Raspberry Pi's hostname in the results:
nmap -sn 192.168.1.0/24
Windows:
Use ipconfig
to find your subnet, e.g., 192.168.1._
.
Install nmap and open the command line
as an administrator for nmap to display the hostnames in its results.
Use the nmap
command to scan your subnet for connected devices, and
look for the Raspberry Pi's hostname in the results:
nmap -sn 192.168.1.0/24
Use the command nmap -sn 192.168.1.0/24 | findstr /i "b8:27:eb"
to quickly
see a list of Raspberry Pis (MAC addresses only).
Use scp
on your client computer. For example, suppose the Raspberry Pi is located at
141.13.106.30
and has the user pi
. To copy the the file /var/log/syslog
from the
Raspberry Pi via the user pi
, use the command scp pi@141.13.106.30:/var/log/syslog syslog
Train engines (and ther plugins) defined as SCCharts (*.sctx) files can be verified against certain
properties before they are uploaded to the sever. Verification is on by default and
can be configured to true
(On) or false
(Off) via the /admin/set-verification-option
endpoint.
For the command line client, use the command swtbahn admin set-verification-option <true/false>
.
When verification has been turned on and an SCCharts file is uploaded, the server sends a request to SWTbahn Verifier (SWT internal repository), which...
If all safety properties hold, the server processes the SCCharts file, e.g., by compiling and loading the file as a plugin. Otherwise, if any safety property does not hold, the server does not process the SCCharts file any further and reports the failure to the client.
The sever communicates with SWTbahn Verifier via websockets with JSON messages. A typical verification session is as follows:
Grab-ids are used as tokens for trains. A client needs to grab a train before he
can invoke commands for controlling the train. A train could only be grabbed by
one client at a time.
Session-ids are used to check wether a grab-id was given out to the client on
the current session or on a previous session.
When is a new session-id created?
swtbahn admin startup
and the system is not running alreadyWhen is the session-id invalidated?
swtbahn admin shutdown
When is a grab-id created?
swtbahn driver grab <train>
and the train is availableWhen is a grab-id invalidated?
swtbahn driver release
and the train was grabbed by this
clientWhen is the session-id fetched?
swtbahn driver grab <train>
and the train is available and
the client has not already grabbed a trainWhen is the session-id reset?
swtbahn driver release
swtbahn driver
command and the session-id or grab-id
is not the same as the one at the serverswtbahn admin shutdown
and the system was runningswtbahn config
When is a grab-id fetched?
swtbahn driver grab <train>
and the train is available and
the client has not already grabbed a trainWhen is a grab-id reset?
swtbahn driver release
swtbahn driver
command and the session-id or grab-id
is not the same as the one at the serverswtbahn admin shutdown
and the system was runningswtbahn config
We try to use a consistent logging format in all request handlers. General workflow of how request handlers generate log messages:
ERROR
level and stop processing.NOTICE
that represents the start of processing, with - start
at the end of the log.ERROR
or WARNING
log level with - abort
at the end of the log and stop processing.- finish
instead of - start
at the end.For request handlers that barely do any "processing" at all; e.g. where only a status variable is updated, they only generate one log message that ends with - done
.
Request handlers that only return information (getters) also use the - done
pattern instead of start
and finish
, and use the log level INFO
for the - done
log.
As an example, when a request is made to set point10 to the normal state, the request handler (handler_set_point
) generates the following log messages when the processing is successful:
LOG_NOTICE:
Request: Set point - point: point10 state: normal - start
Intervening log messages from internal processing
LOG_NOTICE:Request: Set point - point: point10 state: normal - finish
If the above request was instead made with an unsupported state, e.g., foobar
, then the request handler would generate the following log messages to say that the processing was stopped because of invalid parameters:
LOG_NOTICE:
Request: Set point - point: point10 state: foobar - start
Intervening log messages from internal processing
LOG_ERR:Request: Set point - point: point10 state: foobar - invalid parameters - abort
If the above request forgot to specify the state, i.e., the state parameter is null
, then the request handler would only generate the following log message to say that the parameter validation failed:
LOG_ERR:
Request: Set point - invalid parameters