TSMatch v1.0 middleware

TSMatch is a middleware that supports semantic matchmaking between IoT data sources (Things) and IoT services. The main goal of TSMatch is to automate the data exchange between IoT data sources and services, while satisfying the service needs. For that, release v1 of TSMatch follows a semantic similarity matchmaking approach.

The TSMatch is based on different code of which the key blocks are:

• TSMatch server-side (tsmatch_engine). Performs the semantic matchmaking and has the following Components ----- graphdb, storing Things descriptions, service descriptions, ontologies, and new data nodes (aggregated Things based on a category, e.g., temperature measurement)
• broker, Mosquitto (MQTT broker). TSMatch currently relies on an MQTT broker as message bus. The tsmatch client and engine interconnect to the MQTT broker.
• api_connector. Provides an external service connector via OpenAPI
• tsmatch_client. Corresponds to the end-user application. Currently can be used for environmental monitoring.
• thing. Provides a Thing description containing information about multiple sensors. The Thing integrates a Coaty agent. Coaty provides a way for IoT Things to advertise their semantic descriptions via multicast, notify subscribers when the IoT Thing is no longer available, by sending a deadvertized event.
• tsmatch_connector. provides an MQTT connector to easily use a TSMatch instance. This corresponds to an MQTT connector.
• efpf_connector. Connector to the European Factory Platform (EFPF) message bus, based on RabbitMQ.
• service_registry. Example for an external set of services. Currently holds environment monitoring service specification examples based on OWL and WSDL

Getting Started - Install TSMatch

Use the package manager npm for the installation of modules and packages.

database

The graphdb component is based on the latest Neo4j image. Run the container automatically with the provided script:

cd graphdb
chmod +x start_graphdb.sh
./start_graphdb.sh

MQTT broker

The MQTT broker uses Alpine image version 3.8: Run the container automatically with the provided script:

cd broker
chmod +x start_broker.sh
./start_broker.sh

Things

Run with NPM:

cd thing
npm install
npm run build
npm start 

Run with provided docker container runner script:

cd thing
chmod +x start_sensor.sh
./start_sensor.sh

TSMatch Engine

Run with NPM:

cd tsmatch_engine
npm install 
npm run build
npm run service

Run with provided docker container runner script:

cd tsmatch_engine
chmod +x start_tsmatch_engine.sh
./start_tsmatch_engine.sh

TSMatch client

There is currently an Android app that can be tested. The apk file is located under [TSMatchMobileApp/android/app/build/outputs/apk/release] Requirements:

• Minimum SDK version of the app is 16. This means it supports Android 4.1 and above.
• In case there is no file manager in the smart phone, install one from the google Play Store. Some popular ones: EZ File Explorer, File Manager.
• Installing unknown apps must be allowed on the smart phone, since the app is not in Play Store. The way to allow unknown apps on a smart phone changes according to android version. How to do it is explained here.

Installation:

• Connect your phone to a computer with a USB cable and move the APK file into your smart phone, or download it diretly from the git.
• With a file manager, move into the folder where the apk file is located.
• Click on apk file and follow the instructions of the apk installer on your smartphone.

EFPF Connector

Run with NPM:

cd efpf_connector
npm install 
npm run build
npm run service

Run with provided docker container runner script:

cd efpf_connector
chmod +x start_efpf_connector.sh
./start_efpf_connector.sh

Runtime

• Upon start, the sensors are registered in MQTT and advertised via coaty.io . The TSMatch component observe the registered sensors and store the sensor data (include sensor, thing, feature of interest description in the DB).
• Then, the TSMatch client (app) will ask you to fill in some basic service request through thecommand line, then the service request is advertised.
• The TSMatch engine then:

1. receives the service request and stores it in the graphDB.
2. Sensors are first selected based on the feature of interest specified by the user (e.g., temperature).
3. Sensors are grouped based upon an aggregation category defined by the user (e.g., per-room).
4. A new node (linked sensor descriptions) is stored in graphDB.
5. The average value of the linked sensors are then sent to the apk.

Contributing

• feel free to contribute to the current release. Please consider the guidelines in CONTRIBUTING.md.

License

Code and documentation copyright 2022 fortiss GmbH, under the MIT license.

Documentation is licensed under CC.

Credits

• Nisrine Bnouhanna
• Erkan Karabulut
• Jorge de Lima Tostes