Trodomètre/SRS

=  Introduction=

Scope of the product
The goal of the “Trodometre” project is to provide a system to make accurate measurements during a journey. This system is able to calculate both indoor and outdoor measurements. In fact, it doesn’t use a localization system for its position in real time. Moreover, GPS is not available indoor and consumes a lot of energy which reduces the battery life of a system. Information collected by the program can be exported in XML format and used in OpenStreetMap. We can trace an itinerary everywhere precisely on the map. So, every circuit can be shared with everybody. The system is separated into two parts. The first part is the hardware. It is made up of sensors, based on ANT + technology (or BTLE), and moving means (scooter). Then, there is a second part with software which is based on Android an adaptability on every smartphone and mobile system. This system will be used by another project, Navigation of Visually Impaired People (http://autonomie.minalogic.net/index.en.html). This project is intended to facilitate mobility and independence of people with visual impairments. It works both indoors and outdoors, and facilitates access to public transport. Our system enables new itineraries to be created quickly and speeds up completion of those available.

Definitions, acronyms and abbreviations
Operating System

Android: Android is a Linux-based operating system designed primarily for touchscreen mobile devices such as smartphones and tablet computers. Initially developed by Android, Inc.

Communication System

ANT + : ANT is a proprietary wireless sensor network technology featuring a wireless communications protocol stack that enables semiconductor radios operating in the 2.4 GHz Industrial, Scientific and Medical allocation of the RF spectrum ("ISM band") to communicate by establishing standard rules for co-existence, data representation, signalling, authentication and error detection.

Bluetooth low energy : BLTE is a feature of Bluetooth 4.0 wireless radio technology, aimed at new, principally low-power and low-latency, applications for wireless devices within a short range (up to 50 metres / 160 feet -see table below). This facilitates a wide range of applications and smaller form factor devices in the healthcare, fitness, security, and home entertainment industries.

Product perspective
This system will be used by another project, Navigation of Visually Impaired People (http://autonomie.minalogic.net/index.en.html). This project is intended to facilitate mobility and independence of people with visual impairments. It works both indoors and outdoors, and facilitates access to public transport. Our system enables new itineraries to be created quickly and speeds up completion of those available.

Product functions
The system must provide solutions for the requirement stated below:


 * 1) Provide a way to create an itinerary from a departure point.
 * 2) The itinerary should be accurate (-50 cm / 20 inch)
 * 3) Show the current orientation and modification
 * 4) Record the user’s information, such as points of interest. These records are audio and textual.
 * 5) Backup the itineraries.
 * 6) Export data in XML file compatible with OpenStreetMap for other uses, such as Navigation of Visually Impaired People.
 * 7) Display itinerary on map.

User characteristics
We have an actor class, the user. The user represents the person who wants to interact with the system. This interaction is divided into different tasks that the user can carry out.

General constraints
Support of the project must be mobile, discrete and lightweight. We are able to travel long and short distances easily. In addition, it must provide for attachment points for the sensors, and cheerful smartphone software. Our system should be work even without connection to Internet. We can imagine it being used everywhere in the world. Thanks to this, it is possible to save measurements in a XML file in the smartphone.

Assumptions and dependencies
Our system has one dependency with XML format where are save the itinerary. It must respect this format for be read by other project.

=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.

Requirement specification


In Figure 1 all the basic features we will make can be seen. We have an actor class, the user. The user represents the person who wants to interact with the system. This interaction is divided into different tasks that the user can carry out:

Define a departure point
Description: This case corresponds to the definition of the starting point. Three different methods are possible: the first is to obtain the current position of the user, with a tracking system. The second method is to ask the user. The third method asks the user for latitude and longitude.

Inputs: GPS / USER (Map or manual input)

Outputs: Latitude/Longitude saved on the system.

Destination: System

Action: Select a departure point.

Pre-condition:

GPS : That needs to be outdoors and have a tracking module on the smartphone.

USER Map : An access map (online or local)

USER Manual : The User know the coordinates

Create an itinerary
Description: This case corresponds to the recorded itinerary with the system.

Inputs: Departure Point

Destination: System

Action: Record an itinerary

Pre-condition: Have a departure point

See orientation
Description: The user can see the current system’s orientation and its modification. The modifications appear when the user turns.

Inputs: Gyroscope

Destination: User

Action: Show the orientation

Pre-condition: Connetion with Gyroscope and the system must be in itinerary creation (case 2).

Read the current itinerary state
Description: The user can see the different measures step. For example, the first distance after the first turn, the first POI emplacement…

Destination: User

Action: Show the current itinerary

Pre-condition: The system must be in itinerary creation (case 2).

Record POI
Description: The user has the ability to save POI. To do this, after he has activated the function, it must name the POI. Then, optionally, the user can record a corresponding sound. This function allows you to add information about the route. For example, in a station, you can add POI to represent a lift, to warn the person following the route.

Inputs: Microphone/Text

Destination: System

Action: Save the POI

Pre-condition: The system must be in itinerary creation (case 2).

Backup the itineraries
Description: The user can save the current itinerary, and start a new measurement.

Destination: System

Action: Save the current itinerary

Pre-condition: The system must be in itinerary creation (case 2).

Export Data
Description: The user can export data. This export can be done in two ways: the first is to save it on a storage device, such as an SD card. The second method is to send the data via email.

Output: XML files

Destination: Card SD / EMail

Action: Export itineraries

Pre-condition: The software requires the user to connect to the internet.

Display an itinerary
Description: The user can display an itinerary in OpenStreetMap view.

Output: View on map

Destination: User

Action: Display itinerary

Pre-condition: The software requires the user to connect to the internet and the route should be saved.

Set option
Description: The user can display an itinerary in OpenStreetMap view.

Destination: System

Action: Set the system

= Product evolution=

=Appendices= Score Report