Software Developer
Hardware Developer
Software Developer
Hardware Developer
It is designed for big buildings such as factories and especially public places like theaters or anything managed by the public administration, where a single functionary has to do the maintenance. Through a user-friendly UI, the functionary will be able to control every single duct covered by the WWW system.
What does WWW actually do It detects if a duct in the system is broken or, by detecting the flux of water, if there is any trouble in the pipes (for example, if it is obstructed). The HUD will inform the user, after evaluating and choosing the hypothesis with the highest probability between different choices, such as a broken duct, leak, obstructed duct and so on. It will detect which pipe is malfunctioning, so that the user can find it quickly.
Also, the WWW is modular. It means that you can install as many sensors as you need, you can use it in one area or in the whole building, and in one or more buildings, by adding sensors and control boxes linked to a single account and to the main system. These will be useful for the public administration because it must keep track of a big infrastructures under control.
The system can act instead of the user. If the functionary is far away or even can't reach the place in which he should operate, WWW is able to fix or minimize the damages while waiting for user intervention; it closes valves to block the leaks.
Evaluate the water flux difference between 2 or more duct checkpoint, to find damaged or obstructed (total or partial) ducts; sensing the local temperature to prevent freezes
Suggest different hypothesis, evaluated by the data captured by the sensors, of the most probable damage or issue, and the best course of action to solve the problem. Evaluate average daily consumption and, if possible, try to find a way to reduce it
Close broken valves that are detected by the sensors, warm pipes with a Thermo-box
Communicate to the user the location and the type of issue, allow the user to control different areas by an HUD, if chosen, could act without waiting for the user input
| AmI feature | Description |
|---|---|
| Sensitive | With a large amount of different sensors, it could detects water fluxes, temperature, leaks. They are autonomous, one kind is not necessary to make the others work. |
| Responsive | The system could act quickly instead of the user, and automatically (if this mode is previously chosen by the user) |
| Adaptive | Two ways of operating: as an assistant or in total autonomy |
| Transparent | The user is called only when necessary |
| Ubiquitous | A single system could manage one or more buildings, and be managed by one or more people |
| Intelligent | Suggest different solutions evaluating the data acquired |
The goal of the system is to prevent, find and contain water leaks avoiding water waste. As an intelligent system, Water Waste Watcher (WWW) is able to help the user in his daily work detecting possible leaks and damages on ducts and act on the water system to eliminate or, at least, limit the damages waiting for the user intervention.
For big buildings the difficulty on its control and management is also high becoming harder to find where and why water is being wasted. The WWW aims to contain the losses generated by damages on the water transport system. It is especially designed for buildings that need continuously maintainance and that offers difficulty to track broken ducts; That way, WWW system is meant to be used by the team responsible for the maintainance of these buildings.
The system is created for technicians involved in the maintenance of large buildings, such as schools or hospitals.
| ID | Functional Area | Description |
|---|---|---|
| 1 | User | User login, registration and logout |
| 2 | Preferences | Interface for setting user preferences |
| 3 | Notifications | Notifications sent by the system to user devices |
| 4 | Monitoring and Sensing | Receiving data from sensors and be capable to keep an area under control |
| 5 | Activation | Activation of the hardware |
The ID of the Functional Requirement is linked to the correspondent Functional Area of the Requirement. For example, the Functional Requirement 2.1 is the first requirement of the Functional Area number 2 (Preferences)
| ID | Title | Description | Priority |
|---|---|---|---|
| 1.1 | Login | User login to the private area | 3 |
| 1.2 | Logout | User logout of the private area | 3 |
| 1.3 | Sing-in | User Registration to save preferences on the cloud | 3 |
| 2.1 | Measure Unit | Choose the measuring unit | 2 |
| 2.2 | Box Name | Set the name of a single operative unit | 1 |
| 2.3 | Wait Time For Broken Ducts | Set the time that the system should wait until automatically act on broken ducts, closing the water flow | 2 |
| 2.4 | Wait Time For Obstructed Ducts | Set the time that the system should wait until automatically act on obstructed ducts, closing the water flow | 2 | 3.1 | Leaking Notification | Receive notifications about a leaking duct | 1 |
| 3.2 | Obstruction Notification | Receive notification about an obstructed duct | 2 |
| 3.4 | Data | Show data of wasted water | 2 |
| 3.5 | Acting Notification | Send the user a notification and the request for autonomous activation or user intervention | 1 |
| 4.1 | Broken Duct | Recognize a broken duct | 1 |
| 4.2 | Obstructed Duct | Recognize an obstructed duct | 2 |
| 4.3 | Water Waste | Evaluate the waste produced by a leak | 2 |
| 4.4 | Solution Checker | Check for a solution for the broken or obstructed duct | 1 |
| 5.1 | Brake Leak | Close the water flow of a leaking duct | 1 |
| 5.2 | Brake Obstruct | Close the water flow of an obstructed duct | 2 |
| ID | Description | Area |
|---|---|---|
| 1 | The system must be easy to use so that the user might be able to do the tasks with less than 4 steps | Usability |
| 2 | The system must run on a computer with access to the internet | Connectivity |
| 3 | The system should store all the information in a database | Data Integrity |
| 4 | The system should be developed using the Python3 programming language | Implementation |
| 5 | The system should be up and running without errors for more than 95% of the time for every user | Reliability |
| 6 | The system should have Electro-Valves, Thermo Boxes, Flux and Proximity sensors as part of its hardware components | Implementation |
| 7 | The system must be able to provide notifications to the user within 5 seconds of an occurrence, and if any action is possible, execute it | Efficiency |
| 8 | The user terminal must be able to interact with the physical system | Interoperability |
| 9 | The web-application should run on any of the given browsers: Google Chrome, Firefox, Internet Explorer, Edge, Safari and Opera | Portability |
| Number | Name | Description |
|---|---|---|
| 1 | Flow Sensors (Box) | Pixnor G34 External Thread Flow Sensor |
| 2 | Local Hub | Arduino UNO R3 |
| 3 | USB Cable | USB 2.0 Cable Type A/B |
| 4 | Main Hub | Client's Server |
| 5 | PC | User's personal computer |
All the items present on the Hardware Architecture are Off-the-Shelf components (OTS). Meaning that there were not necessity of building any hardware specific for this project. Only the assemble of the listed components.
Each component is used to achieve a specific Requirement (more details at the Functional Requirements section) and at the end of each description these requirements are presented.
Used to measure water flow in the water system's ducts. Composed by a rotor that detects the amount of water flowing by evaluating the number of RPM's (Rounds per minute). These sensors are distributed in the client's ducts after an evaluation of the WWW team to decide the sensors' positions. These sensors are directly connected with the functional requirements 4.1 and 4.2. These sensors had to be bought by the team and will be refund by the Ambient Intelligence Team later
This local computational node collects data from different sensors located on the influence area through an analog input. Than, this microcontroller will send the data collected to the server. In the prototype, two flux sensors are connected to a single Local Hub (Arduino) by a wire connecting directly the sensors to the Hub. To cover the entire water system of big buildings more than one Local Hub should be necessary as its number of ports are limited. On the prototype, there won't be electro-valves that make the automatic closure of the duct, but on the ideal project there would be these valves actived directly by some Local Hubs if configured so
On the prototype there will be used a USB Cable to make the connection between the Local Hub and the Main Hub (server). On a bigger project, there would be used a Wi-Fi port to make that communication
This server receives the data of Local Hubs (in the prototype situation, only one) and also hosts the web-application accessible by the user. The application uses the data provided to show the user the information about the water system. The Main Hub is also responsible to send the decisions made by the user back to the Actuators that would act on the water system to prevent damages. However, in the protype these actuators are not present because the Ambient Intelligence Team decided not to provide them and if the team decided to buy, they wouldn't arrive on time for the presentation
It is compulsory to have access to the internet in order to access the web-application available at the Server (Main Hub). This PC could be even a mobile phone, given that the application can be accessed by any browser. In the prototype the Main Hub and PC are represented by the same computer.
| Number | Name |
|---|---|
| 1 | Web Application |
| 2 | Flask Library |
| 3 | Bootstrap Library |
| 4 | SQLite Library |
| 5 | Arduino API |
| 6 | Arduino Software |
Developed in the Python language using the Flask framework
Hosted on the Main Hub, displays the information of the entire system (Functional Requirements ) and allows the user to take the desired decisions (Functional Requirements )
Can be run in any browser, including mobile phones (Non-Functional Requirement )
Responsible for the web framework. GET and POST requests.
Makes the website responsible and enhance desing
In charge of the communication with the database. As well as the DML (Data Modeling Language) to create and persist the data.
Library used to accomplish the communication between the Arduino and the web application
Runs on separate Arduino boards (Local Hubs) across the system. The software calls specific functions according to the main hub input.
This software allows the Arduino to process and send the collected data to the main hub and also act accordingly to the received data from the main hub.
In the prototype developed, the network required to the project involve:
On a bigger project the network required would be:
The network architecure on a bigger project were brought just for curiosity, as the requested one is for the demo project
Design of user interface
How to identify a single HW unit without a gps system
How to distribute the sensors along the water system
How to inform broken ducts to the user
What mecanism can help us on the acting of broken ducts