Page no.
SPECIFICATION
Prepared by
Document number
Himzo Pettersson
PUS003
Document responsible
Date
Revision
Henrik Cosmo
2015-05-05
PA1
STLDD - Software Top Level Design Document: MVD
Contents
1
INTRODUCTION ..................................................................................................... 2
2
REFERENCE DOCUMENTS ................................................................................. 2
3
OVERVIEW .............................................................................................................. 2
3.1 SCAN APPLICATION .............................................................................................. 3
3.2 PUBLISH APPLICATION ......................................................................................... 3
3.3 MQTT BROKER ................................................................................................... 4
3.4 BACKEND SERVER ................................................................................................ 4
3.4.1 Receiver ....................................................................................................... 4
3.4.2 Database ...................................................................................................... 5
3.4.3 API ............................................................................................................... 6
1 (6)
Page no.
SPECIFICATION
Prepared by
Document number
Himzo Pettersson
PUS003
Document responsible
Date
Revision
Henrik Cosmo
2015-05-05
PA1
1
Introduction
This document describes the requirements for the MVD, with main
purpose to make MVD to act as a gateway between Bluetooth Low
Energy (BLE) devices and remote server.
2
Reference documents
SRS – Software Requirements Specification
3
Overview
The main purpose of a MVD is to collect the data from BLE advertising
devices (i.e. beacons), to process the data and send it to a remote server
via a MQTT broker.
In order to achive above, two application have been developed to run on
MVD, Scan and Publish applications.
Figure 1: System overview
The apps have familiar structure and are divided in one controller and
several modules. All modules are executing in service-threads that run as a
background-thread. The internal communication from modules to
2 (6)
Page no.
SPECIFICATION
Prepared by
Document number
Himzo Pettersson
PUS003
Document responsible
Date
Revision
Henrik Cosmo
2015-05-05
PA1
controllers and from Scan to Publish applictions is done using Androids
BroadcastReciever mechanism.
3.1
Scan application
Scan applications performs a scan for BLE advertising devices. Once a
BLE advertising device is found, the application will read the data from
the device transmitted in a advertisement. Thereafter, the application will
send the data to Publish application using Android BroadcastReceiver
mechanism.
Scan application consists of three modules:
1. Scan: Finds advertising devices through BLE and reads the data.
Data is a encrypted.
2. Decode: Decrypts the data.
3. Broadcast: Broadcasts the data using Androids BroadcastReceiver
mechanism.
Figure 2: Scan application modules
3.2
Publish application
Publishing application receives the data scaned by the Scan application
trhough the Androids BroadcastReceiver mechanism, processes the data
and sends it to the MQTT broker.
Publish application conists of trhee modules:
1. Receive broadcast: Receives the data using Androids
BroadcastReceiver mechanism.
2. Prepare message: Converts the data to a JSONObject.
3. Publish MQTT: Sends the the JSONObject to broker.
3 (6)
Page no.
SPECIFICATION
Prepared by
Document number
Himzo Pettersson
PUS003
Document responsible
Date
Revision
Henrik Cosmo
2015-05-05
PA1
Figure 3: Publish application modules
3.3
MQTT Broker
MQTT Broker acts like a router that is receiving MQTT messages and,
depending on topic, routes them to specific subscribers. All
communication between broker and backend server is encrypted using
TLS/SSL protocol. Publishers and subscribers must have valid SSL
certificates to connect to the broker. The Mosquitto broker is used.
Figure 4: Backend side architecture
3.4
Backend server
Backend server component has additional three subcomponents: receiver,
database and API.
3.4.1
Receiver
Receiver receives the messages MQTT Broker. When the message is
received, receiver extracts and processes the data saves it to the database.
The receiver is implemented using Paho Java Client.
4 (6)
Page no.
SPECIFICATION
Prepared by
Document number
Himzo Pettersson
PUS003
Document responsible
Date
Revision
Henrik Cosmo
2015-05-05
PA1
3.4.2
Database
MySQL database is used to store the received MQTT messages from the
MVD. MVD
Figure 5: ER diagram of the database
Tables of the database:
 Users - holds data about users. User can be a passenger in a bus,
tram or any other transportation vehicle. For now, table has only
two fields: id of the user and his name.
 Operators - holds data about operators of vehicles that are used
for transportation. Table has two fields: id of the operator and
name of the operator.
 Vehicles - holds vehicles that are used for transportation. Table has
three fields: id of the vehicle, type of the vehicle(bus,tram etc.) and
id of the operator.
 Sensors - holds data about sensors that are used by vehicles to
gather information about temperature, doors(open, closed),
seat(busy,open) etc. Table has four fields: id of the sensor, type of
the sensor(temperature,seat,door etc.), description of the
sensor(e.g. “Celsius” for temperature sensor gives description that
this sensor returns value whose unit measurement is in Celsius)
and id of the vehicle where sensor is located.
 Trips - holds data about trips of a user. When user enters vehicle it
will create new trip for him, when he leaves vehicle it will update
5 (6)
Page no.
SPECIFICATION
Prepared by
Document number
Himzo Pettersson
PUS003
Document responsible
Date
Revision
Henrik Cosmo
2015-05-05
PA1

3.4.3
existing trip with data that signalize that his trip has finished. Table
has six fields: id of the trip, gps location when user has entered
vehicle, time when user has entered vehicle, gps location when
user has left vehicle, time when user has left vehicle, line number
of a vehicle, id of the user and if of the vehicle.
SensorMessages - holds data about sensor messages. Every
message that sensor of any vehicle sends to the server is recorded
in this table. This table has six fields: id of the sensor message, id
of the sensor that sent message, value of the sensor, gps location
when sensor sent message, time when sensor sent message and line
number of the vehicle.
API
API is used for retrieving data from the database and presenting them to
user. User in this context is a member of an organization that manages
sensors. Backend side of the API will contain REST service, implemented
using dropwizard framework, who will enable users to add, modify and
delete data from the database, in addition of generating variety of reports
by combining data from different tables.
6 (6)