Projets-2016-2017-Station de pompage connectée - SRS
| Version | Date | Authors | Description | Validator | Validation Date | |
|---|---|---|---|---|---|---|
| 0.1.0 | 05/02/2017 | Qianqian Fu, Maxime Chevalier, Héloïse Fernandes | TBC | TBC | TBC |
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 ( MJC : youth cultural center)
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 ( MJC : youth cultural center).
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 : [Connected pump station subject]
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 ( MJC : youth cultural center). 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 ( MJC : youth cultural center). 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.