Difference between revisions of "Projets-2016-2017-Station de pompage connectée - SRS"

From air
Jump to navigation Jump to search
Line 22: Line 22:
   
 
=References=
 
=References=
  +
Le sujet du projet : [[http://air.imag.fr/index.php/Station_de_pompage_connect%C3%A9e| Sujet Station de pompage connectées]]
//TODO - main page of the project link
 
   
 
==Overview of the remainder of the document==
 
==Overview of the remainder of the document==

Revision as of 12:32, 4 February 2017

Introduction

Purpose of the requirements document

This Software Requirements Specification (SRS) was created as part of an engineer school fourth year project on a connected solar pump station. This document go through the description of the project and the different requirements needed to realise it.

The intended audience of this description are the client or the analysts of needs and tasks, the testers, documentation writers for the user and project managers.

Project name
“Station de pompage connecté”
Supervisor
Nicolas Palix
School
Polytech Grenoble
Product designer/manufacturer Team
Maxime Chevalier, Qianqian Fu, Héloïse Fernandes
Customers
Saint-Matins d’Hères city hall

Scope of the product

The aim of this project is to carry out an application to check the water level of a solar pump station, built by students from Grenoble IUT, for the Saint Martin d’Hères city hall.

Glossary

LoRA : Low Power Wide Area Network (LPWAN) that use LoRAWan protocole

Water Monitoring (app / web):A website and / or mobile application that controls the actuators and accesses of water information in distance

Independence Module:In the software system, each module only relates to specific sub-functions according to software requirements, and the interfaces with other modules in this software system are also simple.

References

Le sujet du projet : [Sujet Station de pompage connectées]

Overview of the remainder of the document

The document is divided in three main part. The aim of the first part is to describe the product fonctions, caractéristics and constraints. Next in a second part, the document lists the different requirement of the product. Eventually, in the last part some evolution of the product are addressed.

General description

Product perspective

In aim to water the public garden, gardeners/subscribers use a pump station. The pump is composed of a tank connected to a groundwater. The groundwater allow to fill the tank when it be pumped. When the garden is watered the water level in the tank decrease. If the level fall to zero gardens can’t be watered. Thus gardeners must often check the water level of the tank. The project must allow gardeners to check the pump level remotely at any moment.

Product functions

The application must provides some functionalities :

  • check the water level of the tank
  • check the state of the tank(switch on / switch off)
  • (check level of the groundwater)
  • (switch on/off the pump station remotely)

\*functions between parentheses are optionals functions

User characteristics

The final user of the product are subscribers from the Saint Martin d’Hères city hall. There are two majors characteristics that we must take account :

  • They aren’t specialized in computer science. There are common users
  • They have a medium/high acknowledge on the pump station and know how it work

General constraints

Pump constraint
tank 1000L
groundwater under 5 meters
Hardware constraints
12 or 14V battery
Nucléo(c++)
Maximum number of measure
waterproof sensors
Communication protocole constraints
LoRA
low flow
watch out the low
Software constraint
mobile application or web application

Assumptions and dependencies

In a first time, we can ignore the archiving of data. We must include configuration file for calibration, and suppose that our sensor can communicate through analog or digital. We suppose that the LoRA transmitter is in range of the LoRA receiver (we will not use a gateway). In this report we supposed that sensors are already installed and compatible with the system below.

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

Requirement 1 : Measurement System

Description
Sensors which measure :
- the water level in the tank
- the water level in the groundwater
- the state of the pump
Inputs
Volts values / Digital values
Source
Sensor
Outputs
digital meter value
Destination
Database
Action
- Each measure corresponds to a sensor
- Volts values are send by the sensors and convert into digital meter value (if necessary)
Non functional requirements
- Small consumption of energy
- Reliable values
Pre-condition
Sensors are installed
Post-condition
Side-effects

Requirement 2 : Control System

Description
The pump must be remotely controlled
Inputs
a new state
Source
User
Outputs
User is notified
Destination
pump
Action
Install a remotely control on the pump which turn off or on the pump and inform the user of the new state.
Non functional requirements
Reliability : the control of the pump must be accurate and secure
Pre-condition
Check if:
- The tank isn’t already full
- The user has the rights
- The groundwater isn’t empty
Post-condition
The system is in a new state and the tank don’t overflow
Side-effects

Requirement 3 : HTTP Server

Description
The HTTP server link the database, the communication system and the user application
Inputs
Http request
Source
User or communication system
Outputs
Http answer
Destination
User, pump
Action
- Listen the user and send him data or send order to the communication system
- Check if the user has the rights
Non functional requirements
- Reliable : the server must be available at any moment
- Security : the user data must be safe
Pre-condition
Post-condition
Side-effects

Requirement 4 : Database

Description
A database will be use to store the different data
Inputs
measure, state pump, user data(login and password)
Source
User or measurement system
Outputs
if the source is the user and it’s a registration then send him a notification
Destination
Database
Action
- Register measures and state of the pump
- Register or check data user
Non functional requirements
- Reliable : the base must be available at any moment
- Security : the user data must be safe
Pre-condition
Post-condition
Data are saved into the database
Side-effects

Requirement 5 : Communication system

Description
The data from the pump must be send to the user and order from the user must be send to the pump. The communication system link the pump and the server system.
Inputs
Data
Source
User or pump
Outputs
Data
Destination
User or pump
Action
- Send measure of the pump for the user
- Send order(switch on/off) from the user to the pump
Non functional requirements
Reliable : the system must be available at any moment and data mustn't be corrupted.
Pre-condition
- The systeme use LoRA
- The system is allowed to communicate(868 MHz and LoRA 1% law)
Post-condition
Users are supposed to know the state of the system and the pump is supposed to know users’ order
Side-effects

Requirement 6 : User Application

Description
The user can access to the different functionality through an application
Inputs
Data
Source
Database
Outputs
order or none
Destination
pump
Action
- display data
- send order to the pump
Non functional requirements
- Ease of use : the application must be ease to use and intuitive
- Reliable : data must be displayed correctly
- Security : user must be identified.
Pre-condition
user must be identified
Post-condition
Side-effects

Product evolution

Evolution hardware

Change due to evolution of hardware

NarrowBand IoT (NB-IoT) for Long Term Evolution (LTE)
This is because by upgrading existing networks with an easy software upgrade, it provides optimized device KPIs, battery life, coverage and cost, along with the expected benefits from the use of licensed spectrum, such as no coexistence issue with other cellular networks. Based on an LTE narrowband evolution, this is designed to operate in a 200kHz carrier refarmed from GSM but has the further advantage of being able to operate in shared spectrum with an existing LTE network, thus requiring no additional deployment of antennas, radio or other hardware. The solutions for LTE-M and NB-IoT will equally operate in spectrum shared with existing LTE network - LTE-M and NB-IoT would be supplementary solutions addressing different use cases, with higher capacity on LTE-M and slightly lower cost and better coverage on NB-IoT. Reusing LTE for narrowband IoT systems (eMTC and NB-IoT) takes advantage of existing technology as well as the installed system base. It is possible to reuse the same hardware and share spectrum by making LTE-M and NB-IoT compatible with LTE, without running into coexistence.The LTE evolution for LTE-M and NB-IoT will enable cellular IoT for low cost, low power and wide area deployments that provide:
  • Long battery life through power saving mode and eDRX
  • Low device cost by using simpler devices
  • Low network deployment cost by enabling shared carrier capacity
  • Full coverage via new coding, repetition and boosting power spectral density
  • Optimized core network for IoT.

New user

The project is for subscribers from the Saint Martin d’Hères city hall. However this project can be useful for other type of pump. Thus the project must be flexible in aim to be use on every type of pump.

Appendices

Index