Proj-2016-2017-IndoorGeoloc/SRS: Difference between revisions

From air
Jump to navigation Jump to search
 
(10 intermediate revisions by 2 users not shown)
Line 23: Line 23:
* https://en.wikipedia.org/wiki/OpenStreetMap
* https://en.wikipedia.org/wiki/OpenStreetMap
* http://www.st.com/web/en/home.html
* http://www.st.com/web/en/home.html
* http://openlevelup.net/
* https://www.tutorialspoint.com/spring/spring_web_mvc_framework.htm


==1.5 Overview of the remainder of the document==
==1.5 Overview of the remainder of the document==
In the rest of the document, we will describe our objectives, the way the system is supposed to work and the constraints the project implies.
In the rest of the document, we will describe our objectives, the way the system is supposed to work and the constraints the project implies.


Editing Proj-2015-2016-IndoorGeoloc/SRS (section)
Bold textItalic textInternal linkExternal link (remember http:// prefix)Level 2 headlineEmbedded fileFile linkMathematical formula (LaTeX)Ignore wiki formattingYour signature with timestampHorizontal line (use sparingly)


=2. General description=
=2. General description=
==2.1 Product perspective==
==2.1 Product perspective==
The product is meant to be enabling people to locate things into a building. The user interface will contain a list of emitting beacons, a map where these beacons are located. The hardware interface contains a flow of data that a server receives and use in order to mesure the RSSI distance of the object. The freshly computed position is saved into a databased which is accessible from another side of the server. That server will send the data to Android clients via the MQTT protocol.
The product is meant to be enabling people to locate things and to be located into a building. The user interface will contain a list of emitting beacons, a map where these beacons are located. The hardware interface contains a flow of data that a server receives and use in order to mesure the RSSI distance of the object. The freshly computed position is saved into a databased which is accessible from another side of the server. That server will send the data to Android clients via the MQTT protocol.


==2.2 Product functions==
==2.2 Product functions==
Line 39: Line 37:
* Locate people on a map
* Locate people on a map
* Find a way to get to the located object
* Find a way to get to the located object
* Find a way to get to the located place in the building


==2.3 User characteristics==
==2.3 User characteristics==
Line 55: Line 54:
* emergent system properties and quality characteristics.
* emergent system properties and quality characteristics.


==3.1 Requirement 1 : acquisition of data with computation of distance ==
==3.1 Requirement 1 : Detecting advertising packets ==
'''Function''': Detecting advertising packets
'''Function''': measuring, computing and storing of the data received from the STM32 boards into distance saved in a database.


'''Description''': Centrals (STM32, Genuino) receives advertising packets emitted by beacons.
'''Description''': all the signals received from the BLE emitting beacon are used to compute a distance for a given beacon. The distance is then stored into a databse where an identifier, a date and the location of the object are added.


'''Inputs''': BLE signals
'''Inputs''': BLE signals
Line 64: Line 63:
'''Source''': TI beacons, iTag
'''Source''': TI beacons, iTag


'''Outputs''': database with distance computation for a beacon
'''Outputs''': Packet content : String(not parsed) containing information about the source beacon and signal strength.


'''Destination''': the database will be used by a server which will send the last position (or any position at a given time) to an android client
'''Destination''': A local application which will parse the received string into a beacon object.


'''Action''':
'''Action''':
* Detection of BLE signal
* acquisition of data with computation of distance


'''functional requirements''': Centrals must detects advertising packets.


'''Pre-condition''': Centrals must use passive listening mode. Centrals must use BLE technology. Packet must be on and emit advertising packet.
'''Non functional requirements''': none

'''Pre-condition''': identifiers between beacons must be unique


'''Post-condition''':
'''Post-condition''':
Line 80: Line 78:
'''Side-effects''':
'''Side-effects''':


==3.2 Requirement 2 : Sending the location of a device from the server to the Android client ==
'''Function''': fetching data from the database, sending it to the rightful device


'''Non functional requirements''': Identifiers between beacons must be unique. Packet must contain signal strength.
'''Description''': using MQTT, the server access the database in order to fetch the last or any position at a given date, it then publishes the position of a beacon on a specified topic permitting the clients subscribing to the topic to receive the location.


'''Pre-condition''': Packet must be able to emit BLE signals.
'''Inputs''': computed distance


'''Post-condition''':
'''Source''': Database containing every the location of all the beacons


'''Side-effects''':
'''Outputs''': Every location of the beacons are delivered to the right topics.


==3.2 Requirement 2 : Transferring data between centrals and local application ==
'''Destination''': The Android clients
'''Function''': Content of advertising packet is transferred.


'''Description''': The "string" received by centrals is sent to the local application via USB
'''Action''':
* Fetching and sending the location to the Android devices


'''Inputs''': String (content of BLE signals)


'''Source''': Centrals (STM32, Genuino 101)
'''Non functional requirements''':


'''Outputs''': Same string, no loss of information
'''Pre-condition''': The database in non empty, the android clients are connected to internet

'''Destination''': Local application on a local machine (written in java)

'''Action''':
* Physical data transfert

'''functional requirements''': Requirement 1.

'''Pre-condition''': Centrals must be connected via USB to local application. local application must be launched.


'''Post-condition''':
'''Post-condition''':
Line 105: Line 111:
'''Side-effects''':
'''Side-effects''':


==3.3 Requirement 3 : Rendering the received data on a map on Android smartphones ==
'''Function''': using the received data in order to display the information into a map


'''Non functional requirements''': none.
'''Description''': The Android client receives locations of beacons thanks to the subscribe method. It uses the OSMDroid API tu display the items on a map.


'''Pre-condition''':
'''Inputs''': Beacons location as markers


'''Post-condition''':
'''Source''': The server publishing the locations on the different topics.


'''Side-effects''':
'''Outputs''': A map displaying every beacon



'''Destination''': The Android smartphone
==3.3 Requirement 3 : acquisition of data by local application ==
'''Function''': getting, parsing and sending the data received from the STM32 boards to a PostGres database.

'''Description''': The local application parse the data received from centrals into beacon object and send it.

'''Inputs''': BLE signals (string format)

'''Source''': centrals

'''Outputs''': Beacon object encapsulated in a RestTemplate object in order to be sent to cloud database through POST HTTP request.

'''Destination''': the database will be used by a server which will send the last position (or any position at a given time) to an android client


'''Action''':
'''Action''':
* acquisition of data with computation of distance
* Rendering the beacons on the map by marking them in an overlay.


'''functional requirements''': Signal strength must be received.


'''Pre-condition''': Local application must listen port event in order to detect when data is coming.
'''Non functional requirements''':


'''Pre-condition''': The positions are not ambiguous, not duplicated.
'''Post-condition''':


'''Side-effects''':
'''Post-condition''': Every beacon has its representative figure on the screen

'''functional requirements''': Received string must be parsed into beacon object.

'''Pre-condition''': Received string must be in the right format.

'''Post-condition''':

'''Side-effects''':

'''functional requirements''': Beacon object must be sent via POST HTTP request.

'''Pre-condition''': received string must be parsed into beacon object + Beacon object must be encapsulated in a RestTemplate object

'''Post-condition''':

'''Side-effects''':

'''Non functional requirements''': none

'''Pre-condition''':

'''Post-condition''':


'''Side-effects''':
'''Side-effects''':


=3.Specific requirements, covering functional, non-functional and interface requirements=
* document external interfaces,
* describe system functionality and performance
* specify logical database requirements,
* design constraints,
* emergent system properties and quality characteristics.


==3.1 Requirement 1 : acquisition of data with computation of distance ==
==3.4 Requirement 4 : Compute the location of beacons ==
'''Function''': measuring, computing and storing of the data received from the STM32 boards into distance saved in a database.
'''Function''': Calculate the location of the beacons and save it in the PostGres Database.


'''Description''': The location of the beacon who emitted the signal is computed thanks to the signal strength(measurement) of the beacon object saved in database (Beacon table).
'''Description''': all the signals received from the BLE emitting beacon are used to compute a distance for a given beacon. The distance is then stored into a databse where an identifier, a date and the location of the object are added.


'''Inputs''': BLE signals
'''Inputs''': Beacon object


'''Source''': TI beacons, iTag
'''Source''': database : Beacon Table


'''Outputs''': database with distance computation for a beacon
'''Outputs''': JSON Object representing the location of the beacon.


'''Destination''': Database. Saved in LOCATION_HISTORY table.
'''Destination''': the database will be used by a server which will send the last position (or any position at a given time) to an android client


'''Action''':
'''Action''':
* computation of beacon location
* acquisition of data with computation of distance


'''functional requirements''': Beacon object must be saved in database.


'''Non functional requirements''': none
'''Pre-condition''':


'''Pre-condition''': identifiers between beacons must be unique
'''Post-condition''':

'''Side-effects''':


'''functional requirements''': Three different signal strength must be at minimum saved in database in order to compute location (triangulation).

'''Pre-condition''': In database there are three save of the same beacon object but with different signal strength (called measurement in database).


'''Post-condition''':
'''Post-condition''':
Line 162: Line 203:
'''Side-effects''':
'''Side-effects''':



==3.2 Requirement 2 : Sending the location of a device from the server to the Android client ==
'''Non functional requirements''': none

'''Pre-condition''':

'''Post-condition''':

'''Side-effects''':



==3.5 Requirement 5 : Sending the location of a device from the server to the Android client ==
'''Function''': fetching data from the database, sending it to the rightful device
'''Function''': fetching data from the database, sending it to the rightful device


'''Description''': using MQTT, the server access the database in order to fetch the last or any position at a given date, it then publishes the position of a beacon on a specified topic permitting the clients subscribing to the topic to receive the location.
'''Description''': using MQTT, the server access the database in order to fetch the last or any position at a given date, it then publishes the position of a beacon on a specified topic permitting the clients subscribing to the topic to receive the location.


'''Inputs''': computed distance
'''Inputs''': computed location


'''Source''': Database containing every the location of all the beacons
'''Source''': Database containing every the location of all the beacons
Line 181: Line 233:
'''Non functional requirements''':
'''Non functional requirements''':


'''Pre-condition''': The database in non empty, the android clients are connected to internet
'''Pre-condition''':The database in non empty, the android clients are connected to internet


'''Post-condition''':
'''Post-condition''':
Line 187: Line 239:
'''Side-effects''':
'''Side-effects''':



==3.3 Requirement 3 : Rendering the received data on a map on Android smartphones ==
==3.6 Requirement 6 : Rendering the received data on a map on Android smartphones ==
'''Function''': using the received data in order to display the information into a map
'''Function''': using the received data in order to display the information into a map


Line 211: Line 264:


'''Side-effects''':
'''Side-effects''':

==3.7 Requirement 7 : Rendering user position on an indoor map ==
'''Function''': using android GPS tools in order to display the position of the user on an indoor map.

'''Description''': The Android client determine the coordinates of the user. It uses the openlevelup.net API which is an OSM API to display the position of the user on an indoor map.

'''Inputs''': User coordinates

'''Source''': Android GPS tools enable people to get located.

'''Outputs''': An "indoor" map made of custom tiles

'''Destination''': The Android smartphone

'''Action''':
* Rendering the user on the map by marking him in an overlay.

'''functional requirements''':

'''Pre-condition''': User must have location enabled on his smartphone. Android app must have the right to enable user location.

'''Post-condition''':

'''Non functional requirements''':

'''Pre-condition''': Map tiles are saved in the server, the android clients are connected to internet, enough points for the rendering of indoor maps

'''Post-condition''':

'''Side-effects''': distorted rendering if not enough points.


=4. Product evolution=
=4. Product evolution=


* Having a better rendering of the map, more interactive
* Having a better rendering of the map, more interactive
* Using different detecting sensors
* Using different detecting sensors and centrals
* Improving the localisation (more precise)
* Improving the localisation (more precise)
* Finding a way to putting up with signal mitigations
* Finding a way to putting up with signal mitigations
* Ios portability

Latest revision as of 10:41, 13 March 2017

1. Introduction

1.1 Purpose of the requirements document

This Software Requirements Specification (SRS) is designed to identify the requirements for our project called "GeoLoc Indoor". The main goal of the project is to provide a solution to indoor geolocalisation problem. We are bound to develop an application able to locate BLE beacon in a building. This is an open source project so that maybe people find an interest in our app in order to make it take a step further. This document is a guideline listing the functionalities offered by our application and the solutions that the system provides.


1.2 Scope of the product

Geoloc Indoor is a project with several possibilities of use. One of them could be when someone, equipped with the app on its smartphones, is looking for an object (emitting bluetooth) or a person in a building where each room contains sensors. Those sensors are linked to server computing the distance from the emitting beacons to the sensors and gives a location (room, distance, route) to the user.


1.3 Definitions, acronyms and abbreviations

  • OpenStreetMap (OSM) : is a collaborative project to create a free editable map of the world.
  • STM32 is a family of 32-bit microcontroller integrated circuits by STMicroelectronics. The STM32 chips are grouped into related series that are based around the same 32-bit ARM processor core, such as the Cortex-M7, Cortex-M4F, Cortex-M3, Cortex-M0+, or Cortex-M0. Internally, each microcontroller consists of the processor core, static RAM memory, flash memory, debugging interface, and various peripherals.
  • Arduino : Programmable microcontroller able to generate and analyse electric signals. The Arduino measures the BLE signals. Data is sent to a server which will compute a distance.
  • Raw data : Data returned by the sensor sent to the server computing the distance.

1.4 References

1.5 Overview of the remainder of the document

In the rest of the document, we will describe our objectives, the way the system is supposed to work and the constraints the project implies.

2. General description

2.1 Product perspective

The product is meant to be enabling people to locate things and to be located into a building. The user interface will contain a list of emitting beacons, a map where these beacons are located. The hardware interface contains a flow of data that a server receives and use in order to mesure the RSSI distance of the object. The freshly computed position is saved into a databased which is accessible from another side of the server. That server will send the data to Android clients via the MQTT protocol.

2.2 Product functions

  • Locate objects on a map
  • Locate people on a map
  • Find a way to get to the located object
  • Find a way to get to the located place in the building

2.3 User characteristics

The application can be used by anyone who wants to locate things emitting bluetooth (BLE) waves. The user has to be connected to internet. The user must have an Android smartphone (version 4.4.4 KitKat minimum), but we hope that in the future this application can be developped for any smartphone OS.

2.4 General constraints

  • The use of the STM32 board are a constraint, they can detect only BLE waves.
  • Developped in Java
  • Network connexion strong and unfiltering the opening of ports

3.Specific requirements, covering functional, non-functional and interface requirements

  • document external interfaces,
  • describe system functionality and performance
  • specify logical database requirements,
  • design constraints,
  • emergent system properties and quality characteristics.

3.1 Requirement 1 : Detecting advertising packets

Function: Detecting advertising packets

Description: Centrals (STM32, Genuino) receives advertising packets emitted by beacons.

Inputs: BLE signals

Source: TI beacons, iTag

Outputs: Packet content : String(not parsed) containing information about the source beacon and signal strength.

Destination: A local application which will parse the received string into a beacon object.

Action:

  • Detection of BLE signal

functional requirements: Centrals must detects advertising packets.

Pre-condition: Centrals must use passive listening mode. Centrals must use BLE technology. Packet must be on and emit advertising packet.

Post-condition:

Side-effects:


Non functional requirements: Identifiers between beacons must be unique. Packet must contain signal strength.

Pre-condition: Packet must be able to emit BLE signals.

Post-condition:

Side-effects:

3.2 Requirement 2 : Transferring data between centrals and local application

Function: Content of advertising packet is transferred.

Description: The "string" received by centrals is sent to the local application via USB

Inputs: String (content of BLE signals)

Source: Centrals (STM32, Genuino 101)

Outputs: Same string, no loss of information

Destination: Local application on a local machine (written in java)

Action:

  • Physical data transfert

functional requirements: Requirement 1.

Pre-condition: Centrals must be connected via USB to local application. local application must be launched.

Post-condition:

Side-effects:


Non functional requirements: none.

Pre-condition:

Post-condition:

Side-effects:


3.3 Requirement 3 : acquisition of data by local application

Function: getting, parsing and sending the data received from the STM32 boards to a PostGres database.

Description: The local application parse the data received from centrals into beacon object and send it.

Inputs: BLE signals (string format)

Source: centrals

Outputs: Beacon object encapsulated in a RestTemplate object in order to be sent to cloud database through POST HTTP request.

Destination: the database will be used by a server which will send the last position (or any position at a given time) to an android client

Action:

  • acquisition of data with computation of distance

functional requirements: Signal strength must be received.

Pre-condition: Local application must listen port event in order to detect when data is coming.

Post-condition:

Side-effects:

functional requirements: Received string must be parsed into beacon object.

Pre-condition: Received string must be in the right format.

Post-condition:

Side-effects:

functional requirements: Beacon object must be sent via POST HTTP request.

Pre-condition: received string must be parsed into beacon object + Beacon object must be encapsulated in a RestTemplate object

Post-condition:

Side-effects:

Non functional requirements: none

Pre-condition:

Post-condition:

Side-effects:


3.4 Requirement 4 : Compute the location of beacons

Function: Calculate the location of the beacons and save it in the PostGres Database.

Description: The location of the beacon who emitted the signal is computed thanks to the signal strength(measurement) of the beacon object saved in database (Beacon table).

Inputs: Beacon object

Source: database : Beacon Table

Outputs: JSON Object representing the location of the beacon.

Destination: Database. Saved in LOCATION_HISTORY table.

Action:

  • computation of beacon location

functional requirements: Beacon object must be saved in database.

Pre-condition:

Post-condition:

Side-effects:


functional requirements: Three different signal strength must be at minimum saved in database in order to compute location (triangulation).

Pre-condition: In database there are three save of the same beacon object but with different signal strength (called measurement in database).

Post-condition:

Side-effects:


Non functional requirements: none

Pre-condition:

Post-condition:

Side-effects:


3.5 Requirement 5 : Sending the location of a device from the server to the Android client

Function: fetching data from the database, sending it to the rightful device

Description: using MQTT, the server access the database in order to fetch the last or any position at a given date, it then publishes the position of a beacon on a specified topic permitting the clients subscribing to the topic to receive the location.

Inputs: computed location

Source: Database containing every the location of all the beacons

Outputs: Every location of the beacons are delivered to the right topics.

Destination: The Android clients

Action:

  • Fetching and sending the location to the Android devices


Non functional requirements:

Pre-condition:The database in non empty, the android clients are connected to internet

Post-condition:

Side-effects:


3.6 Requirement 6 : Rendering the received data on a map on Android smartphones

Function: using the received data in order to display the information into a map

Description: The Android client receives locations of beacons thanks to the subscribe method. It uses the OSMDroid API tu display the items on a map.

Inputs: Beacons location as markers

Source: The server publishing the locations on the different topics.

Outputs: A map displaying every beacon

Destination: The Android smartphone

Action:

  • Rendering the beacons on the map by marking them in an overlay.


Non functional requirements:

Pre-condition: The positions are not ambiguous, not duplicated.

Post-condition: Every beacon has its representative figure on the screen

Side-effects:

3.7 Requirement 7 : Rendering user position on an indoor map

Function: using android GPS tools in order to display the position of the user on an indoor map.

Description: The Android client determine the coordinates of the user. It uses the openlevelup.net API which is an OSM API to display the position of the user on an indoor map.

Inputs: User coordinates

Source: Android GPS tools enable people to get located.

Outputs: An "indoor" map made of custom tiles

Destination: The Android smartphone

Action:

  • Rendering the user on the map by marking him in an overlay.

functional requirements:

Pre-condition: User must have location enabled on his smartphone. Android app must have the right to enable user location.

Post-condition:

Non functional requirements:

Pre-condition: Map tiles are saved in the server, the android clients are connected to internet, enough points for the rendering of indoor maps

Post-condition:

Side-effects: distorted rendering if not enough points.

4. Product evolution

  • Having a better rendering of the map, more interactive
  • Using different detecting sensors and centrals
  • Improving the localisation (more precise)
  • Finding a way to putting up with signal mitigations
  • Ios portability
Retrieved from "https://air.imag.fr/index.php?title=Proj-2016-2017-IndoorGeoloc/SRS&oldid=34452"