Projets-2016-2017-Station de pompage connectée - SRS

From air
Revision as of 12:15, 4 February 2017 by Heloise.Fernandes-De-Almeida (talk | contribs) (Created page with "=Introduction= ==Purpose of the requirements document== This Software Requirements Specification (SRS) was created as part of an engineer school fourth year project on a conne...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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

//TODO - main page of the project link

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

//TODO-annexe

Index

//TODO-image table