Taxi sign resource¶

Minimum Python 3.3 should be used for this software to run properly.

To find usage information on this (and other scripts mentioned in this section), use the -h command line switch:

$ python3 examples/taxisignservice/taxisignservice.py -h

The taxi sign service listens to this command:

command/taxisignservice/state True

and it will respond on the corresponding data topic.

To test the taxisign resource, run this in three different terminal windows:

$ mosquitto_sub -t +/#  -v
$ python3 examples/taxisignservice/taxisignservice.py -v -mode graphical
$ mosquitto_pub -t command/taxisignservice/state -m True

The last command will turn on the taxi sign. Using ‘False’ as payload will turn it off. This is how the taxi sign looks like when on, and off (and in addition disconnected from the broker) respectively:

As seen in the mosquitto_sub window, also availability data is sent upon startup:

resourceavailable/taxisignservice/presence True
commandavailable/taxisignservice/state True
dataavailable/taxisignservice/state True

data/taxisignservice/state False

Kill the taxisignservice process to see the last will being sent from the broker. The service manager will send out the presence information for the individual signals.

Try it using:

$ ps -ef
$ kill <PID for taxisignservice>

Taxi sign application¶

The taxi sign app (application) is a graphical program that is turning on or off the taxi sign (simulated or real hardware). The taxi sign app can also be used in command-line only mode (for use on Linux machines without graphics).

First test the taxi sign app standalone, with a broker only (make sure the broker is running). Start the taxi sign app in graphical mode:

$ python3 examples/taxisignapp/taxisignapp.py -mode graphical

In a separate terminal window, send information to the taxi sign app that the taxi sign resource is online and that the sign is lit up:

$ mosquitto_pub -t resourceavailable/taxisignservice/presence -m True
$ mosquitto_pub -t data/taxisignservice/state -m True

In yet another terminal window, listen to all MQTT commands:

$ mosquitto_sub -t +/#  -v

Then press the buttons on the taxi sign app. It will show something like this:

command/taxisignservice/state True
command/taxisignservice/state False

This is how the taxi sign app looks like, when the taxi sign is on, and when the taxi sign is disconnected from the broker:

Now it is time to test the taxi sign app and the taxi sign resource together. Run these in separate terminal windows:

$ python3 examples/taxisignapp/taxisignapp.py -v -mode graphical
$ python3 examples/taxisignservice/taxisignservice.py -v -mode graphical

Try for example to kill the broker and then start it again.

Help texts for the taxi sign resource and app¶

Details of usage for the taxi sign related examples are found here:

$ python3 examples/taxisignservice/taxisignservice.py -h
usage: taxisignservice.py [-h] [-v] [-host HOST] [-port PORT] [-cert CERT]
                          [-mode {hardware,commandline,graphical}]

optional arguments:
  -h, --help            show this help message and exit
  -v                    Increase verbosity level. Can be repeated.
  -host HOST            Broker host name. Defaults to localhost.
  -port PORT            Broker port number. Defaults to 1883.
  -cert CERT            Directory for certificate files. Defaults to not using
                        certificates.
  -mode {hardware,commandline,graphical}
                        Type of simulator to use. Depends on graphical display
                        or taxi sign hardware. Defaults to 'commandline'.

A taxi sign service example for the Secure Gateway concept architecture.

This is a "Resource" according to the Secure Gateway nomenclature. It registers on
the Secure Gateway network, and accepts commands to turn on or off a
hardware taxi sign. It is intended for running on Beaglebone with appropriate
electronics connected to a GPIO output pin to contol the taxi sign. Note that
root/sudo permissions typically are required to control GPIO pins.

This resource sends out on start-up:
  resourceavailable/taxisignservice/presence True
  commandavailable/taxisignservice/state True
  datavailable/taxisignservice/state  True

This resource is listening for:
  command/taxisignservice/state True/False

This resource sends out on state change:
  data/taxisignservice/state True/False

It can also be used in two different simulation modes. This is handy when no
taxisign hardware is available (or no sudo/root permission is available). The
command line mode simulator should always be available. The graphical mode
simulator requires Tk installed on the machine. This is typically installed with:
  sudo apt-get install python3-tk

This resource can connect to the broker in a secure or insecure way. The settings
of the broker determines what is allowed. To connect in the secure way,
the directory of the certificate files must be specified.

The certificate files should be named:
  CA file:          ca_public_certificate.pem
  Certificate file: public_certificate.pem
  Key file:         private_key.pem

$ python3 examples/taxisignapp/taxisignapp.py -h
usage: taxisignapp.py [-h] [-v] [-host HOST] [-port PORT] [-cert CERT]
                      [-mode {commandline,graphical}]

optional arguments:
  -h, --help            show this help message and exit
  -v                    Increase verbosity level. Can be repeated.
  -host HOST            Broker host name. Defaults to localhost.
  -port PORT            Broker port number. Defaults to 1883.
  -cert CERT            Directory for certificate files. Defaults to not using
                        certificates.
  -mode {commandline,graphical}
                        Type of use interface. Depends on graphical display.
                        Defaults to 'commandline'.

A taxi sign app example for the Secure Gateway concept architecture.

This is an "App" according to the Secure Gateway nomenclature. It registers on
the Secure Gateway network, and sends commands to turn on or off a hardware
taxi sign (or a simulated sign).

The corresponding taxisign resource must be online. This app listens for:
  resourceavailable/taxisignservice/presence True

This app is sending:
  command/taxisignservice/state True

This app is receiving:
  data/taxisignservice/state True

It can be used in two different modes. The command line mode should always
be available. The graphical mode requires Tk installed on the machine.
This is typically installed with:
  sudo apt-get install python3-tk

This app can connect to the broker in a secure or insecure way. The settings
of the broker determines what is allowed. To connect in the secure way,
the directory of the certificate files must be specified.

The certificate files should be named:
  CA file:          ca_public_certificate.pem
  Certificate file: public_certificate.pem
  Key file:         private_key.pem

Build your own Secure Gateway enabled taxi sign hardware¶

The taxisignservice resource software is handling turning on and off a digital output pin on a BeagleBone or Raspberry Pi embedded Linux computer board. Use the command:

$ sudo python3 taxisignservice.py -v -mode hardware -host 192.168.0.93

Replace the IP number with your broker’s IP number. Due to the hardware manipulation on the Beaglebone/Pi, you must run the program in ‘sudo’ mode.

Connect the output GPIO pin to a relay driver. The GPIO pin number to use is defined in the taxisigndriver file, and there is also more technical information in that file. A power supply and a lightbulb are connected to the relay. Cheap taxi sign fixtures are available on several of the common low-price marketplaces on the Internet.

Set the broker IP number manually when starting the taxisignservice, or write a small startscript that uses Avahi to find the broker IP number.

To test the GPIO output driver:

$ sudo python3 examples/taxisignservice/drivers/taxisign_driver.py

Certificate Authority¶

Generate a private key for the CA (certificate authority):

$ openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out ca_private_key.pem

Generate the public CA certificate:

$ openssl req -new -x509 -days 3650 -key ca_private_key.pem -subj "/C=SE/O=TEST" -out ca_public_certificate.pem

Server certificate¶

Generate a private key for the server:

$ openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out server_private_key.pem

The server certificate will have the host name as its CN (Common Name), and this must be the address that clients connects to. It can be for example “www.example.com”, “11.22.33.44” or “localhost”. When deploying the server in different locations you need to adapt this (the certificate must be re-generated if the broker IP-number is changed). A few examples are given below.

Request a server certificate from the CA:

$ openssl req -new -key server_private_key.pem -subj "/C=SE/O=TEST/CN=192.168.0.3" -out server_request.csr
$ openssl req -new -key server_private_key.pem -subj "/C=SE/O=TEST/CN=localhost"   -out server_request.csr

The CA issues a server certificate:

$ openssl x509 -req -in server_request.csr -CA ca_public_certificate.pem -CAkey ca_private_key.pem -days 3650 -CAcreateserial -out server_public_certificate.pem

Note that is the first time the CA generates a certificate. We ask it to create a file for keeping track of serial numbers (using the -CAcreateserial flag).

Now the .csr file can be removed.

Taxisign resource certificate¶

Generate a private key for the taxi sign:

$ openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out taxisign_private_key.pem

Request a (taxi sign) client certificate from the CA. The Common Name (CN) must be unique among the clients to the broker, as we use it as the username:

$ openssl req -new -key taxisign_private_key.pem -subj "/C=SE/O=TEST/CN=taxisign" -out taxisign_request.csr

The CA issues a (taxi sign) client certificate:

$ openssl x509 -req -in taxisign_request.csr -CA ca_public_certificate.pem -CAkey ca_private_key.pem -days 3650 -CAserial ca_public_certificate.srl -out taxisign_public_certificate.pem

Taxisign app certificate¶

Generate a private key for the taxi app:

$ openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out taxiapp_private_key.pem

Request a (taxi app) client certificate from the CA:

$ openssl req -new -key taxiapp_private_key.pem -subj "/C=SE/O=TEST/CN=taxiapp" -out taxiapp_request.csr

The CA issues a (taxi app) client certificate:

$ openssl x509 -req -in taxiapp_request.csr -CA ca_public_certificate.pem -CAkey ca_private_key.pem -days 3650 -CAserial ca_public_certificate.srl -out taxiapp_public_certificate.pem

Force the Mosquitto broker to use certificates¶

Use a modified mosquitto.conf file:

port 8883
cafile ca_public_certificate.pem
certfile server_public_certificate.pem
keyfile server_private_key.pem
require_certificate true
use_identity_as_username true

#acl_file acl.txt

#listener 1883
#allow_anonymous true

(If you un-comment the two last lines also non-encrypted connections are accepted)

Start Mosquitto from the directory with the configutation and certificate files:

SecureGateway/examples/servercertificates$ mosquitto -c mosquitto.conf

Testing the certificates from command line¶

For the clients, put the key and certificate files in a subfolder. Rename the files to:

• public_certificate.pem
• private_key.pem

Also put a copy of the ca_public_certificate.pem in each clients’ subfolders.

Test that the broker rejects communication without certificates:

$ mosquitto_sub -v -t +/#

The moquitto_sub command is accepting certificate files. When using it with certificates, the host IP address must be given exactly as in the certificate file. If not given, the mosquitto_sub will assume that the host is ‘localhost’ and thus the certificate must have been generated for this host name. Otherwise you must give the hostname/IPnumber explicitly to mosquitto_sub.

You can connect two clients to the broker like this, if you have ‘localhost’ as CN in the server/broker certificate:

SecureGateway/examples/taxisignapp/certificates$     mosquitto_sub -v -t +/# -h localhost -p 8883 --cafile ca_public_certificate.pem --cert public_certificate.pem --key private_key.pem
SecureGateway/examples/taxisignservice/certificates$ mosquitto_sub -v -t +/# -h localhost -p 8883 --cafile ca_public_certificate.pem --cert public_certificate.pem --key private_key.pem

With a broker running on a server with IP 192.168.0.3, and the server certificate has been generated for that IPnumber:

SecureGateway/examples/taxisignapp/certificates$     mosquitto_sub -v -t +/# -h 192.168.0.3 -p 8883 --cafile ca_public_certificate.pem --cert public_certificate.pem --key private_key.pem
SecureGateway/examples/taxisignservice/certificates$ mosquitto_sub -v -t +/# -h 192.168.0.3 -p 8883 --cafile ca_public_certificate.pem --cert public_certificate.pem --key private_key.pem

You can also use one mosquitto_pub and one mosquitto_sub to send command line messages between terminal windows.

If you do not want mosquitto_sub to check the server certificate to the server hostname, give the –insecure flag to mosquitto_sub. For example:

$ mosquitto_sub -v -t +/# -h localhost --insecure -p 8883 --cafile ca_public_certificate.pem --cert public_certificate.pem --key private_key.pem

With the setting “require_certificate false” in the mosquitto.conf file, do not give the –cafile –cert –key options to mosquitto_sub. (Otherwise it will give “Connection Refused: bad user name or password.”)

Run the taxisignservice and taxisign app using certificates¶

After starting the certificate-enabled broker, run this in two separate terminal windows:

SecureGateway/examples/taxisignapp$     python3 taxisignapp.py     -mode graphical -host localhost -port 8883 -cert certificates/
SecureGateway/examples/taxisignservice$ python3 taxisignservice.py -mode graphical -host localhost -port 8883 -cert certificates/

All distributed example apps and resources can use certificates.

Linux CAN command-line tools¶

In order to test the CAN communication, we are using the can-utils command line CAN tools. These are used similarly on real and simulated CAN buses. For example, one of the tools is candump which allows you to print all data that is being received by a CAN interface.

In order to test this facility, start it in a terminal window:

$ candump vcan0

From another terminal window, send a CAN frame with identifier 0x1A (26 dec) and 8 bytes of data:

$ cansend vcan0 01a#11223344AABBCCDD

This will appear in the first terminal window (running candump):

vcan0  01A   [8]  11 22 33 44 AA BB CC DD

To send large amount of random CAN data, use the cangen tool:

$ cangen vcan0 -v

In order to record this type of received CAN data to file (including timestamp), use:

$ candump -l vcan0

The resulting file will be named like: candump-2015-03-20_123001.log

In order to print logfiles in a user friendly format:

$ log2asc -I candump-2015-03-20_123001.log vcan0

Recorded CAN log files can also be re-played back to the same or another CAN interface:

$ canplayer -I candump-2015-03-20_123001.log

If you need to use another can interface than defined in the logfile, use the expression CANinterfaceToUse=CANinterfaceInFile. This example also prints the frames:

$ canplayer vcan0=can1 -v -I candump-2015-03-20_123001.log

The cansniffer command line application is showing the latest CAN messages. Start it with:

$ cansniffer vcan0

It shows one CAN-ID (and its data) per line, sorted by CAN-ID, and shows the cycle time per CAN-ID. The time-out until deleting a CAN-ID row is 5 seconds by default.

There is an example CAN log file distributed with the Secure Gateway. Download it, replay it, and study the result using cansniffer.

Also the Wireshark program can be used to analyse CAN frames.

There is a description on how to analyze CAN using Wireshark: https://libbits.wordpress.com/2012/05/07/capturing-and-analyzing-can-frames-with-wireshark/ Make sure to enable the CAN interface before starting the program.

Setting up CAN communication between two embedded Linux boards¶

In order to test real CAN communication, you need two embedded Linux machines, for example Raspberry Pi and Beaglebone. Both should be equipped with CAN interface boards, set to a speed of 500 kbit/s. The installation of software and hardware is described elsewhere in this documentation.

Test the communication using command line tools. Send a CAN frame from one of the machines:

$ cansend can0 01a#01020304

This will be repeatedly sent on the CAN bus until there is an acknowledgement from at least one other node.

For the CAN controller to be able to send a message, a CAN transceiver must be connected (as it senses the CAN bus voltage). Otherwise it will stop immediately after the first try.

To cancel this sending, you need to disable and re-enable the can0:

$ sudo ip link set can0 down
$ sudo ip link set can0 up

On the other machine receive the CAN frames using:

$ candump can0

Simulated climate node (which is a CAN simulator or vehicle simulator)¶

There is a vehicle simulator available among the Secure Gateway examples. It will send out CAN messages on a real or simulated CAN bus. The CAN messages contain signals describing the vehicle speed, the engine speed and the in-car temperature. The simulator listens to control signals on the CAN bus to turn on or off the simulated air condition (affects the in-car temperature).

The vehicle speed is increased in small, random steps. When reaching the maximum speed, it is instead decreased in small, random steps. The engine speed is calculated from the vehicle speed, as seen in this figure:

To test the vehicle simulator, run these commands in two different terminal windows:

$ candump vcan0
$ python3 examples/vehiclesimulator/vehiclesimulator.py -v

This will print out the simulated values, and the send CAN frames, respectively.

In order to turn on the simulated air condition, run this command from yet another terminal window:

$ cansend vcan0 007#8000000000000000

To turn off the air condition:

$ cansend vcan0 007#0000000000000000

Note the resulting changes in the simulated in-car temperature.

Climate resource (converts CAN messages to MQTT)¶

The climate resource converts data from CAN frames, and sends it to MQTT messages. It also converts commands in MQTT messages to CAN frames. The climate resource is implemented using the canadapter script with appropriate configuration files.

These MQTT topics are used by the canadapter (configured to run as a climate resource named climateservice):

command/climateservice/aircondition 1
data/climateservice/aircondition 1
data/climateservice/actualindoortemperature 27.5
data/engineservice/vehiclespeed 67.5
data/engineservice/enginespeed 2354

Basically it sends out MQTT data describing the vehiclespeed, enginespeed etc, and listens to MQTT commands to turn the air condition on and off.

In addition these availability topics are sent at startup:

resourceavailable/climateservice/presence True

dataavailable/climateservice/actualindoortemperature True
dataavailable/climateservice/vehiclespeed True
dataavailable/climateservice/enginespeed True

commandavailable/climateservice/aircondition True
dataavailable/climateservice/aircondition True

To test the canadapter, run these commands in three different terminal windows (from sgframework project root directory, after installation):

$ python3 examples/vehiclesimulator/vehiclesimulator.py -v
$ canadapter examples/configfilesForCanadapter/climateservice_cansignals.kcd -mqttfile examples/configfilesForCanadapter/climateservice_mqttsignals.json -mqttname climateservice -v
$ mosquitto_sub -t +/# -v

In order to turn on and off the air condition, run this command in yet another terminal window:

$ mosquitto_pub -t command/climateservice/aircondition -m 1

An example of data on the canbus (as printed by candump vcan0):

vcan0  009   [8]  03 32 00 00 00 00 00 00
vcan0  008   [8]  0F E9 17 24 00 00 00 00
vcan0  007   [8]  80 00 00 00 00 00 00 00
vcan0  009   [8]  03 2A 00 00 00 00 00 00
vcan0  008   [8]  10 0B 17 54 00 00 00 00

Note that the aircondition command is echoed back (as data) from the canadapter, not from the vehiclesimulator itself. This means that the data/climateservice/aircondition signal might be out of sync with the state of the vehicle simulator. A more advanced usage would be to echo the command in a separate CAN message from the vehiclesimulator, and convert that information to the mentioned MQTT message. This can easily be set for the canadapter by using the configuration file.

Several canadapters can be running in parallel, each handling a few CAN messages. These canadapters are then different resources on the Secure Gateway network, and could require different permission levels for usage.

Use as few CAN definition files as possible (in the KCD file format), as canadapter uses message filtering in the Linux kernel for the messages defined in the file.

Generate data in the ‘climatesimulationdata’ CAN frame (id 0x009, once per 100 ms):

$ cangen vcan0 -I 009 -L 8 -D i -g 100

Generate data in the ‘vehiclesimulationdata’ CAN frame (id 0x008, once per 100 ms):

$ cangen vcan0 -I 008 -L 8 -D i -g 100

Climate MQTT app¶

Distributed with the Secure Gateway is a climate app listening to the climate service and controlling the air condition. It has a graphical user interface, but can also be used from the command line (useful for embedded Linux boards).

Start the app:

$ python3 examples/climateapp/climateapp.py -mode graphical

To test the climate app standalone, with a broker only:

$ mosquitto_pub -t resourceavailable/climateservice/presence -m True
$ mosquitto_pub -t data/climateservice/vehiclespeed -m 27.1
$ mosquitto_pub -t data/climateservice/enginespeed -m 1719
$ mosquitto_pub -t data/climateservice/actualindoortemperature -m 31.6
$ mosquitto_pub -t data/climateservice/aircondition -m 1


$ mosquitto_sub -t +/#  -v

Or you can use a one-liner for the above mosquitto commands:

$ mosquitto_pub -t resourceavailable/climateservice/presence -m True && mosquitto_pub -t data/climateservice/vehiclespeed -m 27.1 && mosquitto_pub -t data/climateservice/enginespeed -m 1719 && mosquitto_pub -t data/climateservice/actualindoortemperature -m 31.6 && mosquitto_pub -t data/climateservice/aircondition -m 1 && mosquitto_sub -t +/#  -v

Next, the climate app should be tested together with the vehicle simulator and the canadapter. Then it will show the present in-car temperature and can control the air condition. Also the vehicle speed, engine speed, connection status to the broker and the presence information for the climateservice will be displayed.

This is how the climate app looks like when the air condition is on, and when the climate service is disconnected from the broker:

Instead of using the vehiclesimulator, the climateapp can be tested with the recorded CAN log file and the canadapter.

CAN communication using real CAN bus¶

Set up the CAN communication between the two embedded Linux machines as described earlier.

On the first machine run the vehicle simulator using the real CAN interface:

$ python3 examples/vehiclesimulator/vehiclesimulator.py -v -i can0

On the second machine, verify that it receives CAN data:

$ candump can0

To turn on the air condition in the vehicle simulator (on the first machine) run this on the second machine:

$ cansend can0 007#8000000000000000

Then on the second machine run the canadapter using the real CAN interface:

$ canadapter examples/configfilesForCanadapter/climateservice_cansignals.kcd -mqttfile examples/configfilesForCanadapter/climateservice_mqttsignals.json -mqttname climateservice -v -i can0

Note that the broker must be running.

On the second machine, verify that MQTT messages are sent:

$ mosquitto_sub -t +/# -v

Run the climate app (non-graphical mode) on the second machine (press and hold Enter key for continuous updates):

$ python3 examples/climateapp/climateapp.py

To run the climate app in graphical mode, use a laptop connected to the same network as the machine running the canadapter. Verify that the laptop receives the MQTT messages (use the IP number of the broker, typically on the second machine):

$ mosquitto_sub -t +/# -v -h IPNUMBER_OF_BROKER

Run the climate app in graphical mode on the laptop:

$ python3 examples/climateapp/climateapp.py -mode graphical -host IPNUMBER_OF_BROKER

Help texts for the vehicle simulator and the climate app¶

$ python3 examples/vehiclesimulator/vehiclesimulator.py -h
usage: vehiclesimulator.py [-h] [-v] [-i INTERFACE]

optional arguments:
  -h, --help    show this help message and exit
  -v            Increase verbosity level. Can be repeated.
  -i INTERFACE  CAN interface name. Defaults to vcan0.

$ python3 examples/climateapp/climateapp.py -h
usage: climateapp.py [-h] [-v] [-host HOST] [-port PORT] [-cert CERT]
                     [-mode {commandline,graphical}]

optional arguments:
  -h, --help            show this help message and exit
  -v                    Increase verbosity level. Can be repeated.
  -host HOST            Broker host name. Defaults to localhost.
  -port PORT            Broker port number. Defaults to 1883.
  -cert CERT            Directory for certificate files. Defaults to not using
                        certificates.
  -mode {commandline,graphical}
                        Type of use interface. Depends on graphical display.
                        Defaults to 'commandline'.

A vehicle app example for the Secure Gateway concept architecture.

This is an "App" according to the Secure Gateway nomenclature. It registers on
the Secure Gateway network, and receives vehicle data. It can also send commands
to the CAN-adapter to turn on the air condition.

It can be used in two different modes. The command line mode should always be
available. The graphical mode requires Tk installed on the machine.
This is typically installed with:
  sudo apt-get install python3-tk

This app can connect to the broker in a secure or insecure way. The settings
of the broker determines what is allowed. To connect in the secure way,
the directory of the certificate files must be specified.

The certificate files should be named:
  CA file:          ca_public_certificate.pem
  Certificate file: public_certificate.pem
  Key file:         private_key.pem

sgframework.framework module¶

class sgframework.framework.App(name, host, port=1883, certificate_directory=None)[source]¶

Bases: sgframework.framework.BaseFramework

App framework for the Secure Gateway

Sends commands to any resource. Handles incoming MQTT messages (data) from any resource.

It does not have any ‘last will’. Typically sends (non retained=non persistent) commands to:

command/resource_to_be_controlled/signalname

and listens to data on topic:

data/dataproducing_resource/signalname

Parameters:	name (str) – Name of the app/resource. For resources, it is also used in the MQTT topic hierarchy. host (str) – Broker host name. port (int) – Broker port number. certificate_directory (str or None) – Full path to the directory of the certificate files.

protocol¶

enum in the Paho module

MQTT protocol version, defaults to MQTTv31, as older versions of the Mosquitto broker can not handle MQTTv311.

tls_version¶

enum in the ssl module

SSL protocol version, defaults to ssl.PROTOCOL_TLSv1

qos¶

int

MQTT quality of service. 0, 1 or 2. See Paho documentation. Default value DEFAULT_QOS is set in sgframework.constants.

timeout¶

numerical

MQTT socket timeout, when running the loop() method. Default value DEFAULT_TIMEOUT.

keepalive¶

numerical

MQTT keepalive message interval. Default value DEFAULT_KEEPALIVE_TIME.

Also the parameters appear as attributes. The public attributes are used when calling start(). Any changes are valid from next start().

References to sub-objects:

• mqttclient (object): See Paho documentation
• logger (object): See Python standard library documentation
• userdata (whatever): Convenience object that is available for user code in callbacks. Not used by the framework itself.
• on_broker_connectionstatus_info: Implement this callback if you would like notifications on broker connection status changes. See below.

Callback to the user application on changed broker connection status:

on_broker_connectionstatus_info(app_or_resource, broker_connected)

Where app_or_resource is the app or resource object, and broker_connected (bool) is True if the user application is connected to the broker.

Callbacks to the user application on incoming information are registered using separate methods. The callbacks should have this interface:

callbackname(resource_or_app, messagetype, servicename, signalname, inputpayload)

where messagetype, servicename, signalname and inputpayload are strings. The callback is protected by try/except. The strings to the callback have been through .strip().

When using echo and the returnvalue of the callback is None, the command payload is used in the echo. For returnvalues other then None, the echo payload will be str(returnvalue). More than one input signal can use the same callback.

The certificate files should be named according to CA_CERTS, CERTFILE and KEYFILE.

class sgframework.framework.BaseFramework(name, host, port=1883, certificate_directory=None)[source]¶

Bases: object

Parameters:	name (str) – Name of the app/resource. For resources, it is also used in the MQTT topic hierarchy. host (str) – Broker host name. port (int) – Broker port number. certificate_directory (str or None) – Full path to the directory of the certificate files.

protocol¶

enum in the Paho module

MQTT protocol version, defaults to MQTTv31, as older versions of the Mosquitto broker can not handle MQTTv311.

tls_version¶

enum in the ssl module

SSL protocol version, defaults to ssl.PROTOCOL_TLSv1

qos¶

int

MQTT quality of service. 0, 1 or 2. See Paho documentation. Default value DEFAULT_QOS is set in sgframework.constants.

timeout¶

numerical

MQTT socket timeout, when running the loop() method. Default value DEFAULT_TIMEOUT.

keepalive¶

numerical

MQTT keepalive message interval. Default value DEFAULT_KEEPALIVE_TIME.

Also the parameters appear as attributes. The public attributes are used when calling start(). Any changes are valid from next start().

References to sub-objects:

• mqttclient (object): See Paho documentation
• logger (object): See Python standard library documentation
• userdata (whatever): Convenience object that is available for user code in callbacks. Not used by the framework itself.
• on_broker_connectionstatus_info: Implement this callback if you would like notifications on broker connection status changes. See below.

Callback to the user application on changed broker connection status:

on_broker_connectionstatus_info(app_or_resource, broker_connected)

Where app_or_resource is the app or resource object, and broker_connected (bool) is True if the user application is connected to the broker.

Callbacks to the user application on incoming information are registered using separate methods. The callbacks should have this interface:

callbackname(resource_or_app, messagetype, servicename, signalname, inputpayload)

where messagetype, servicename, signalname and inputpayload are strings. The callback is protected by try/except. The strings to the callback have been through .strip().

When using echo and the returnvalue of the callback is None, the command payload is used in the echo. For returnvalues other then None, the echo payload will be str(returnvalue). More than one input signal can use the same callback.

The certificate files should be named according to CA_CERTS, CERTFILE and KEYFILE.

CA_CERTS = 'ca_public_certificate.pem'¶

CERTFILE = 'public_certificate.pem'¶

KEYFILE = 'private_key.pem'¶

PAYLOAD_FALSE = 'False'¶

PAYLOAD_TRUE = 'True'¶

PREFIX_RESOURCEAVAILABLE = 'resourceavailable'¶

_on_connect(mqttclient, userdata, flags, rc)[source]¶

MQTT callback at connection attempts.

This callback is responsible for doing the subscriptions, and to publish capabilities and default values.

Method signature according to Paho documentation.

_on_disconnect(mqttclient, userdata, rc)[source]¶

MQTT callback at disconnect.

Method signature according to Paho documentation.

_on_incoming_message(mqttclient, userdata, message)[source]¶

MQTT callback at incoming messages.

Executes a preregistered callback, and publishes an echo (if configured).

Updates the default value for echoed signals if configured.

Method signature according to Paho documentation.

_on_mqttclient_log_event(mqttclient, userdata, level, buf)[source]¶

MQTT callback at log event.

Method signature according to Paho documentation.

_on_publish(mqttclient, userdata, mid)[source]¶

MQTT callback at publication confirmation.

Method signature according to Paho documentation.

_on_subscribe(mqttclient, userdata, mid, granted_qos)[source]¶

MQTT callback at subscribe.

Method signature according to Paho documentation.

_on_unsubscribe(mqttclient, userdata, mid)[source]¶

MQTT callback at unsubscribe.

Method signature according to Paho documentation.

_publish_capablities_and_defaultvalues()[source]¶

To be overrided

_register_inputsignal(messagetype, servicename, signalname, callback, callback_on_change_only=False, echo=False, send_echo_as_retained=False, defaultvalue=None)[source]¶

Register a callback for an incoming MQTT message.

Parameters:

messagetype (str) – One of the predefined message types (also known as prefix). servicename (str) – service name signalname (str) – signal name callback (function) – Callback that will be used when a signal is received. callback_on_change_only (bool) – Trigger callback only for changed payload. echo (bool) – True if the incoming signal should be echoed back (as “data”) send_echo_as_retained (bool) – True if the echo should be published as retained. defaultvalue – Value to be echoed on startup. Set to None to avoid sending. The value is converted to a string before sending. It will be updated by _on_incoming_message().

For details on the callback, see the class documentation.

Subscribes to: messagetype/servicename/signalname

The messagetype can be data, dataavailable, command, commandavailable, resourceavailable.

For example: data/climateservice/actualindoortemperature.

_register_outputsignal(messagetype, servicename, signalname, defaultvalue, send_as_retained)[source]¶

Registering outgoing MQTT messages.

This is typically used for automatically send availability information.

Parameters:	messagetype (str) – One of the predefined message types (also known as prefix), most often data. servicename (str) – service name, most often self.name. signalname (str) – signal name defaultvalue – Value to be sent on startup. Set to None to avoid sending. The value is converted to a string before sending. send_as_retained (bool) – True if the signal should be published as retained.

Publishes to: messagetype/servicename/signalname

for example: data/climateservice/actualindoortemperature.

There is also a mechanism to automatically publish availability topics, for example: dataavailable/climateservice/actualindoortemperature.

_set_broker_connectionstatus(broker_connected)[source]¶

Set information whether the broker is connected. This is triggering a callback to the user script.

The information is not stored in the framework, it is the responsibility of the user script.

Parameters:	broker_connected (bool) – Indicates whether the broker is connected or not

_subscribe_to_inputsignals()[source]¶

Do the subscription to input signals

get_descriptive_ascii_art()[source]¶

Display an overview with registered incoming and outgoing topics.

Returns:	A multi-line string.

loop()[source]¶

Run network activities.

This function needs to be called frequently to keep the network traffic alive, if not using threaded networking. It will block until a message is received, or until the self.timeout value.

If not connected to the broker, it will try to connect once.

Do not use this function when running threaded networking.

register_incoming_availability(prefix, servicename, signalname, callback)[source]¶

Register a callback for incoming availability information (incoming MQTT message).

Primarily useful for apps (but is useful for resources to receive data etc from other resources).

Parameters:	prefix (str) – one of PREFIX_COMMANDAVAILABLE, PREFIX_DATAAVAILABLE (or maybe PREFIX_RESOURCEAVAILABLE) servicename (str) – name of the service sending the availability info signalname (str) – name of the data or command callback (function) – Callback that will be used when availability information is received.

When registering a callback for RESOURCEAVAILABLE the actual value of the signalname is not used. Just pass in any string.

For details on the callback, see the class documentation.

Subscribes to: prefix/servicename/signalname

for example: dataavailable/climateservice/actualindoortemperature.

register_incoming_data(servicename, signalname, callback, callback_on_change_only=False)[source]¶

Register a callback for incoming data (incoming MQTT message).

Primarily useful for apps (but is useful for resources to receive data from other resources).

Parameters:	servicename (str) – name of the service sending the data signalname (str) – name of the signal callback (function) – Callback that will be used when data is received. callback_on_change_only (bool) – Trigger callback only for changed payload.

For details on the callback, see the class documentation.

Subscribes to: data/servicename/signalname

for example: data/climateservice/actualindoortemperature.

send_command(servicename, signalname, value, send_command_as_retained=False)[source]¶

Send a command.

Primarily useful for apps (but is useful for resources to control other resources).

Parameters:	servicename (str) – destination service name signalname (str) – destination signal name value – Value to be sent. Is converted to a string before sending. send_command_as_retained (bool) – Publish the command as retained.

Sends messages on topic: command/servicename/signalname

for example command/climateservice/aircondition.

Most often commands are sent as non-retained messages.

start(use_threaded_networking=False, use_clean_session=True)[source]¶

Connect to the broker.

Parameters:	use_threaded_networking (bool) – Start MQTT networking activity in a separate thread. use_clean_session (bool) – Connect to broker using a clean session.

If not using threaded networking, you need to call the loop() method frequently.

If using a clean session, also the client name is changed to include the process ID. This in order to avoid client name collisions in the broker.

stop()[source]¶

Disconnect from the broker

class sgframework.framework.Inputsignalinfo(messagetype, servicename, signalname, callback, callback_on_change_only, echo, send_echo_as_retained, defaultvalue)[source]¶

Bases: object

Object for storing configuration information about incoming MQTT messages.

Storage of incoming signal definitions that should be subscribed to. It can be data, dataavailable, command, commandavailable, resourceavailable. Also holds the callback to be used at incoming signals, and possibly a copy of last received payload.

Arguments are described in the BaseFramework._register_inputsignal() method.

For details on the callback signature, see the BaseFramework documentation.

TODO: .messagetype should be a property.

class sgframework.framework.Outputsignalinfo(messagetype, servicename, signalname, defaultvalue, send_as_retained)[source]¶

Bases: object

Object for storing configuration information about (some of the) outgoing MQTT messages, typically outgoing data (not outgoing commands).

Arguments are described in the BaseFramework._register_outputsignal() method.

TODO: .messagetype should be a property.

class sgframework.framework.Resource(name, host, port=1883, certificate_directory=None)[source]¶

Bases: sgframework.framework.BaseFramework

Resource framework for the Secure Gateway

Receives commands from apps (incoming MQTT messages). Sends data to apps (outgoing MQTT messages).

It can also recieve incoming data from other resources, and can send commands to other resources.

The resource name is typically part of incoming and outgoing message topics:

command/myresourcename/signalname

data/myresourcename/signalname

Also publishes availability of commands and data, using retained messages:

commandavailable/myresourcename/signalname

dataavailable/myresourcename/signalname

When starting up, it sends ‘True’ to the ‘last will’ topic in a retained message:

resourceavailable/myresourcename/presence

The broker is automatically broadcasting ‘False’ on ‘last will’ topic at lost connection.

Parameters:	name (str) – Name of the app/resource. For resources, it is also used in the MQTT topic hierarchy. host (str) – Broker host name. port (int) – Broker port number. certificate_directory (str or None) – Full path to the directory of the certificate files.

protocol¶

enum in the Paho module

MQTT protocol version, defaults to MQTTv31, as older versions of the Mosquitto broker can not handle MQTTv311.

tls_version¶

enum in the ssl module

SSL protocol version, defaults to ssl.PROTOCOL_TLSv1

qos¶

int

MQTT quality of service. 0, 1 or 2. See Paho documentation. Default value DEFAULT_QOS is set in sgframework.constants.

timeout¶

numerical

MQTT socket timeout, when running the loop() method. Default value DEFAULT_TIMEOUT.

keepalive¶

numerical

MQTT keepalive message interval. Default value DEFAULT_KEEPALIVE_TIME.

Also the parameters appear as attributes. The public attributes are used when calling start(). Any changes are valid from next start().

References to sub-objects:

• mqttclient (object): See Paho documentation
• logger (object): See Python standard library documentation
• userdata (whatever): Convenience object that is available for user code in callbacks. Not used by the framework itself.
• on_broker_connectionstatus_info: Implement this callback if you would like notifications on broker connection status changes. See below.

Callback to the user application on changed broker connection status:

on_broker_connectionstatus_info(app_or_resource, broker_connected)

Where app_or_resource is the app or resource object, and broker_connected (bool) is True if the user application is connected to the broker.

Callbacks to the user application on incoming information are registered using separate methods. The callbacks should have this interface:

callbackname(resource_or_app, messagetype, servicename, signalname, inputpayload)

where messagetype, servicename, signalname and inputpayload are strings. The callback is protected by try/except. The strings to the callback have been through .strip().

When using echo and the returnvalue of the callback is None, the command payload is used in the echo. For returnvalues other then None, the echo payload will be str(returnvalue). More than one input signal can use the same callback.

The certificate files should be named according to CA_CERTS, CERTFILE and KEYFILE.

_publish_capablities_and_defaultvalues()[source]¶

Sends ‘True’ to the topic: resourceavailable/myresourcename/presence

For data in outputsignal storage:

• Sends dataavailable/myresourcename/signalname
• If configured, sends defaultvalue data/myresourcename/signalname

For commands in inputsignal storage:

• Sends commandavailable/myresourcename/signalname
• If echo configured, sends dataavailable/myresourcename/signalname
• If configured, sends defaultvalue data/myresourcename/signalname

register_incoming_command(signalname, callback, callback_on_change_only=False, echo=True, send_echo_as_retained=False, defaultvalue=None)[source]¶

Register a callback for an incoming command (incoming MQTT message).

Parameters:

signalname (str) – command name callback (function) – Callback that will be used when a command is received. callback_on_change_only (bool) – Trigger callback only for changed payload. echo (bool) – True if the incoming command should be echoed back (as “data”) send_echo_as_retained (bool) – True if the echo should be published as retained. defaultvalue – Value to be echoed on startup and reconnect. Set to None to avoid sending. The value is converted to a string before sending. It will be updated by the internal _on_incoming_message() callback for incoming MQTT messages.

For details on the callback, see the class documentation.

Subscribes to: command/myresourcename/signalname

When the resource is starting, it is publishing a retained message to:

commandavailable/myresourcename/signalname

register_outgoing_data(signalname, defaultvalue=None, send_data_as_retained=False)[source]¶

Pre-register information on a outgoing data topic (MQTT messages). Note that the actual data sending is later done with the send_data() method.

Parameters:	signalname (str) – signal name defaultvalue – Value to be sent on startup and reconnect. Set to None to avoid sending. The value is converted to a string before sending. It will be updated by send_data(). send_data_as_retained (bool) – Whether the data should be published as retained

When the resource is starting, it is publishing a retained message to:

dataavailable/myresourcename/signalname

Upon sending data, the topic is: data/myresourcename/signalname

for example: data/climateservice/actualindoortemperature.

Typically the data is published using non-retained messages.

send_data(signalname, value)[source]¶

Send data on a pre-registered topic.

Parameters:	signalname (str) – signal name value – Value to be sent. Is convered to a string before sending.

Sends to the topic: data/myresourcename/signalname

for example: data/climateservice/actualindoortemperature.

Updates the defaultvalue for this signal.

Whether the signal should be sent as retained or not is set already during registration.

sgframework.exceptions module¶

exception sgframework.exceptions.SGFrameworkException[source]¶

Bases: Exception

Base exception for the SG framework

sgframework.constants module¶

sgframework.version module¶

Module contents¶

canadapter¶

canadapter.init_canadapter()[source]¶

Initialize the canadapter.

Returns a ‘resource’ in the sgframework terminology.

canadapter.loop_canadapter(resource)[source]¶

canadapter.main()[source]¶

canadapter.on_send_can_data(resource, messagetype, servicename, command_name_mqtt, command_payload_mqtt)[source]¶

Callback for use when receiving a MQTT message. Sends a CAN message.

For callback interface, see sgframework.BaseFramework() documentation.

canadapter.signal_handler(signum, frame)[source]¶

canadapterlib¶

class canadapterlib.Converter(can_config, mqttfile_path=None, sort_json_keys=False)[source]¶

Converter between CAN and MQTT.

Does not store any CAN or MQTT messages.

Parameters:	can_config (can4python.Configuration) – mqttfile_path (str or None) – Full path to the configuration (JSON) file sort_json_keys (bool) – Sort keys in resulting JSON strings.

If the mqttfile_path argument not is given, it listens to all CAN signals (without name or value conversion).

canframe_to_mqtt(frame)[source]¶

Parameters:	frame (can4python.CanFrame) – Incoming CAN frame with data.

Returns a list of MQTT messages, each represented as the tuple (MQTT signalname, MQTT payload). The payload is later converted to a string before sending.

mqtt_to_cansignals(command_name, command_payload)[source]¶

Parameters:	command_name (str) – Incoming MQTT command name (from the splitted MQTT topic) command_payload (str) – Incoming MQTT payload

Returns a dictionary with the signal values to send. The keys are the CAN signalnames (str), and the items are the CAN values (numerical or None). If the CAN value is None the default value is used.

get_definitions_incoming_mqtt_command()[source]¶

Find the incoming MQTT command signalnames etc.

Returns a list of dictionaries, each having the arguments for the resource.register_incoming_command() call.

Note that the ‘callback’ keyword argument not is set in the output from this function, but needs to be set separately.

get_definitions_outgoing_mqtt_data()[source]¶

Find the outgoing MQTT data signalnames etc.

Returns a list of dictionaries, each having the arguments for the resource.register_outgoing_data() call.

get_descriptive_ascii_art()[source]¶

Return a string describing the conversion between CAN and MQTT.

_get_incoming_cansignal_names()[source]¶

Return a list (str) of incoming cansignal names (according to the CAN configuration).

_get_node_incoming_can_frameids()[source]¶

Return a list (int) of all incoming CAN frame ids for this node, according to the CAN configutation.

_get_node_outgoing_can_frameids()[source]¶

Return a list (int) of all outgoing CAN frame ids for this node, according to the CAN configutation.

_get_canframe_id(can_signal_name)[source]¶

Find the CAN frame id for a CAN signal name.

Parameters:	can_signal_name (str) –

Returns the frame_id (int).

Raises:	KeyError if the can_signal_name not is found.

_precalculate_frame_id(translationinfo)[source]¶

Set the frame_id field of the translationinfo.

Does not return anything.

class canadapterlib.IndividualInfo(can_name, mqtt_name=None, send_can=False, echo_mqtt=False, receive_can=True, multiplier=1.0, frame_id=None, mqtt_type=<class 'float'>)[source]¶

A class for describing the translation between a CAN signal and an individual MQTT signal.

can_name¶

str

Signal name in the KCD file for CAN

mqtt_name¶

str or None

Signal name on MQTT (part of the topic). Defaults to None (use same name on MQTT as on CAN.

mqtt_type¶

type

Conversion function used to convert the value to correct type inside the MQTT message (which itself is a string). Defaults to float.

send_can¶

bool

Whether the signal should be sent to CAN. Defaults to False.

echo_mqtt¶

bool

Whether the incoming MQTT message should be echoed back. Defaults to False.

receive_can¶

bool

Whether the signal should be sent to MQTT. Defaults to True.

multiplier¶

float

Multiplier when converting a CAN signal to an MQTT signal. In the other direction is 1/multiplier used. Defaults to 1.0.

frame_id¶

int or None

The id of the CAN frame the signal is using

class canadapterlib.AggregateInfo(mqtt_name, send_can=False, receive_can=True, echo_mqtt=False, frame_id=None)[source]¶

A class for describing the translation between a CAN signal aggregate and a MQTT signal.

All CAN signals must be located in the same CAN frame. The send_can and receive_can fields of the subsignals are not used.

mqtt_name¶

str

Signal name on MQTT (part of the topic).

send_can¶

bool

Whether the subsignals should be sent to CAN. Defaults to False.

receive_can¶

bool

Whether the aggregate should be sent to MQTT. Defaults to True.

echo_mqtt¶

bool

Whether the incoming MQTT message should be echoed back. Defaults to False.

frame_id¶

int or None

The id of the CAN frame the aggregate data is using

subsignals¶

list of IndividualInfo

Definitions for the signals within the aggregate

canadapterlib.translationfile_read(filename)[source]¶

Read a translation file, having the CAN signal names and the MQTT signal names etc.

Parameters:	filename (str) – Full path to the input file.

The input file should be a valid JSON file, having a top object with the name ‘entities’ and the objects ‘aggregates’ and ‘signals’. Item inside ‘signals’ is a list of signaldefinition objects. Item in aggregates are several ‘signals’.

See the sgframework documentation for a more detailed discussion on the file format.

Returns a single list containing AggregateInfo and IndividualInfo. The order in the list is not relevant.

canadapterlib.parse_signal(json_signal, filename)[source]¶

Parse signal information from a JSON dict, and convert to an instance of IndividualInfo.

Parameters:	json_signal – a dict from a (part of a) parsed JSON file filename (str) – Filename (for use in error messages)
Returns:	An IndividualInfo instance

canadapterlib.parse_aggregate(json_aggregate, filename)[source]¶

Parse signal information from a JSON dict, and convert to an instance of AggregateInfo.

Parameters:	json_aggregate – a dict from a (part of a) parsed JSON file filename (str) – Filename (for use in error messages)
Returns:	An AggregateInfo instance

servicemanager¶

servicemanager.main()[source]¶

servicemanager.on_incoming_message(self, mqttclient, userdata, message)[source]¶

MQTT callback at incoming messages.

Method signature according to Paho documentation.

servicemanager.signal_handler(signum, frame)[source]¶

servicemanager.subscribe_to_inputsignals(self)[source]¶

Override the _subscribe_to_inputsignals method in sgframework.framework.BaseFramework

climateapp¶

class climateapp.CommandlineAppDisplay(app)[source]¶

Bases: object

_initialize_values()[source]¶

aircondition_state¶

broker_connectionstatus¶

close()[source]¶

enginespeed¶

indoortemperature¶

loop()[source]¶

redraw()[source]¶

resource_online¶

vehiclespeed¶

class climateapp.GraphicalAppDisplay(app)[source]¶

Bases: climateapp.CommandlineAppDisplay

DISPLAY_TITLE = 'Climate app'¶

TEMPLATE_AIRCONDITION = 'Air condition: {}'¶

TEMPLATE_CONNECTION = 'Connection status: {}'¶

TEMPLATE_ENGINESPEED = 'Engine speed: {:.0f} RPM'¶

TEMPLATE_TEMPERATURE = 'In-car temperature: {:.1f} deg C'¶

TEMPLATE_VEHICLESPEED = 'Vehicle speed: {:.1f} km/h'¶

_button_off_handler(event)[source]¶

_button_on_handler(event)[source]¶

close()[source]¶

Close the GUI

loop()[source]¶

Update the GUI

redraw()[source]¶

climateapp.init_climateapp()[source]¶

climateapp.loop_climateapp(app)[source]¶

climateapp.main()[source]¶

climateapp.on_broker_connectionstatus_info(app, broker_connected)[source]¶

Callback for use when the broker connection status info is available.

climateapp.on_incoming_data(app, messagetype, servicename, signalname, payload)[source]¶

Callback for use when receiving a MQTT message.

Sets display fields.

climateapp.on_resource_presence(app, messagetype, servicename, signalname, payload)[source]¶

Callback for use when receiving a MQTT message.

Sets the presence information (on the display) about the resource in use.

vehiclesimulator¶

vehiclesimulator.init_vehiclesimulator()[source]¶

Initialize the vehicle simulator.

Returns the tuple (temperature_simulator, speed_simulator, canbus)

vehiclesimulator.loop_vehiclesimulator(temperature_simulator, speed_simulator, canbus)[source]¶

vehiclesimulator.main()[source]¶

vehiclesimulation utilities¶

class vehiclesimulationutilities.CabinTemperatureSimulator[source]¶

Bases: object

Simulate the indoor temperature of a vehicle.

The temperature will increase to TEMPERATURE_HOT, but will decrease to TEMPERATURE_COLD when the air conditioner is turned on.

The warming and cooling speeds are affected by GAIN_WARMING and GAIN_COOLING. A random temperature noise is added to the measurement.

This class holds no timer or timing information, so the average rate of temperature change is dependent on how frequently you call getNewTemperature().

temperature¶

float

Indoor temperature in deg C

aircondition_state¶

bool

Boolean indicating whether the AC is on

GAIN_COOLING = 0.05¶

GAIN_WARMING = 0.02¶

TEMPERATURE_COLD = 18.0¶

TEMPERATURE_HOT = 32.0¶

TEMPERATURE_NOISE_DEVIATION = 0.03¶

aircondition_state

get_new_temperature()[source]¶

Calculate a new temperature.

Returns the new temperature in deg C.

class vehiclesimulationutilities.VehicleSpeedSimulator[source]¶

Bases: object

Simulate the speed of a vehicle.

The step size in the vehicle speed is calculated with a normalized distribution using the values:

• SPEED_STEPSIZE (Should be >0)
• SPEED_STEPDEVIATION (Should be >0)

When the speed reaches SPEED_MAX, the speed will start to decrease instead. Similarly it starts to increase again at SPEED_MIN.

This class holds no timer or timing information, so the average rate of speed change is dependent on how frequently you call getNewRandomizedSpeed().

currentspeed¶

float

Vehicle speed in km/h

SPEED_MAX = 110.0¶

SPEED_MIN = 3.0¶

SPEED_STEPDEVIATION = 0.9¶

SPEED_STEPSIZE = 0.3¶

get_new_randomized_speed()[source]¶

Calculate a new vehicle speed.

Returns the new value of currentspeed in km/h.

vehiclesimulationutilities.calculate_engine_speed(vehiclespeed)[source]¶

Calculate the simulated enginespeed.

Parameters:	vehiclespeed (float) – Speed in km/h

Returns: Engine speed (float) in RPM (revolutions per minute)

taxisignapp¶

class taxisignapp.CommandlineAppDisplay(app)[source]¶

Bases: object

TAXISIGN_STATUSTEXT_TEMPLATE = 'Taxi sign status: {:<8}'¶

broker_connectionstatus¶

close()[source]¶

loop()[source]¶

redraw()[source]¶

resource_online¶

taxisign_state¶

class taxisignapp.GraphicalAppDisplay(app)[source]¶

Bases: taxisignapp.CommandlineAppDisplay

DISPLAY_TITLE = 'Taxi app'¶

_button_off_handler(event)[source]¶

_button_on_handler(event)[source]¶

close()[source]¶

Close the GUI

loop()[source]¶

Update the GUI

redraw()[source]¶

taxisignapp.init_taxisignapp()[source]¶

taxisignapp.loop_taxisignapp(app)[source]¶

taxisignapp.main()[source]¶

taxisignapp.on_broker_connectionstatus_info(app, broker_connected)[source]¶

Callback for use when the broker connection status info is available.

taxisignapp.on_resource_presence(app, messagetype, servicename, signalname, payload)[source]¶

Callback for use when receiving a MQTT message.

Sets the presence information for the taxi sign.

taxisignapp.on_taxisign_state_data(app, messagetype, servicename, signalname, payload)[source]¶

Callback for use when receiving a MQTT message.

Sets the state of the taxi sign.

taxisignservice¶

class taxisignservice.CommandlineDummyTaxisign[source]¶

Bases: object

Taxi sign simulator for command line.

Prints out whether the taxi sign is on or off.

* state

bool

Set to True to turn on the taxi sign.

broker_connectionstatus¶

close()[source]¶

loop()[source]¶

redraw()[source]¶

state¶

class taxisignservice.GraphicalDummyTaxisign[source]¶

Bases: taxisignservice.CommandlineDummyTaxisign

Graphical taxi sign simulator.

Shows a dark or bright taxi sign image in the GUI.

* state

bool

Set to True to turn on the taxi sign.

BROKERTEXT_TEMPLATE = 'Broker: {:<7s}'¶

DISPLAY_TITLE = 'Taxi sign simulator'¶

FILENAME_TAXISIGN_OFF = '/home/docs/checkouts/readthedocs.org/user_builds/sgframework/checkouts/latest/examples/taxisignservice/images/taxi_sign_off_small.gif'¶

FILENAME_TAXISIGN_ON = '/home/docs/checkouts/readthedocs.org/user_builds/sgframework/checkouts/latest/examples/taxisignservice/images/taxi_sign_on_small.gif'¶

close()[source]¶

Close the GUI

loop()[source]¶

Update the GUI

redraw()[source]¶

taxisignservice.init_taxisignservice()[source]¶

Initialize the taxi sign service.

Returns ..

taxisignservice.loop_taxisignservice(resource)[source]¶

taxisignservice.main()[source]¶

taxisignservice.on_broker_connectionstatus_info(resource, broker_connected)[source]¶

Callback for use when the broker connection status info is available.

taxisignservice.on_taxisign_state_command(resource, messagetype, servicename, commandname, commandpayload)[source]¶

Callback for use when receiving a MQTT message.

Sets the state of the taxi sign.

Returns the payload (str) that should be included in the command echo MQTT message.

taxisign_driver¶

class taxisign_driver.Taxisign[source]¶

Bases: object

Taxi sign representation.

For controlling a Taxi sign from a Beaglebone. This is basically the Beaglebone output_pin_driver, together with hardware-describing constants.

Module constants describing the hardware:

• GPIO_NUMBER (int): GPIO number for pin connected to relay driver circuit.
• IS_INVERTED (bool): Set to True if the relay and its driver circuit are connected such that the taxi sign turns off for GPIO=high.

* state

bool

Set to True to turn on the taxi sign.

loop()[source]¶

state¶

output_pin_driver¶

class output_pin_driver.Outputpin(GPIO_number)[source]¶

Bases: object

GPIO output pin representation.

For controlling a GPIO output pin on a Beaglebone. Note that root permissions are required.

* state

bool

Turn on the GPIO output pin if the value is True.

state¶