ana madalena de sistema de divulga˘c~ao e monitoriza˘c~ao ...§ão.pdf · rtmp real-time...

Universidade de AveiroDepartamento deElectronica, Telecomunicacoes e Informatica,

2017

Ana Madalena deAlmeida GomesBarbosa

Sistema de divulgacao e monitorizacao paraaquarios

Aquarium disclosure and monitoring system

Universidade de AveiroDepartamento deElectronica, Telecomunicacoes e Informatica,

2017

Ana Madalena deAlmeida GomesBarbosa

Sistema de divulgacao e monitorizacao paraaquarios

Aquarium disclosure and monitoring system

Dissertacao apresentada a Universidade de Aveiro para cumprimento dosrequisitos necessarios a obtencao do grau de Mestre em Engenharia de Com-putadores e Telematica, realizada sob a orientacao cientıfica do ProfessorDoutor Joaquim Manuel Henriques de Sousa Pinto, Professor Associado doDepartamento de Eletronica, Telecomunicacoes e Informatica da Universi-dade de Aveiro

o juri / the jury

presidente / president Professor Doutor Jose Luis Guimaraes OliveiraProfessor Associado da Universidade de Aveiro

vogais / examiners committee Professor Doutor Fernando Joaquim Lopes MoreiraProfessor Associado da Universidade Portucalense

Professor Doutor Joaquim Manuel Henriques de Sousa PintoProfessor Auxiliar da Universidade de Aveiro

agradecimentos A minha famılia e amigos, uma agradecimento especial.Um obrigada ao meu orientador, professor Joaquim Sousa Pinto.Ainda aos professores Claudio Teixeira do DETI e Rui Rocha do DBio.

palavras-chave Internet das Coisas, Ambientes Inteligentes, Monitorizacao de Aquario, Sen-sores

resumo Com a constante evolucao do desenvolvimento tecnologico surge a necessi-dade de criar meios que nos permitam automatizar alguns dos mecanismosaliados as tarefas do dia-a-dia. E cada vez mais frequente depararmo-noscom cenarios monitorizados e controlados remotamente, aumentando a co-modidade e a interacao entre humanos e objetos. O Laboratorio para aInovacao e Sustentabilidade dos Recursos Biologicos Marinhos, Ecomare,contem aquarios com diversas especies que vao ser alvo de estudo. Umdesses aquarios foi o cenario para o desenvolvimento desta dissertacao,sendo o objetivo principal a sua divulgacao, monitorizacao e controlo. O sis-tema desenvolvido e composto por duas componentes, uma plataforma webe uma aplicacao movel. Ambas as plataformas permitem ter acesso aos val-ores lidos, relativamente ao aquario, recolhidos pelos sensores disponıveis.Sao emitidos alarmes quando os valores nao correspondem aos esperados,de modo a que seja possıvel uma rapida atuacao sobre o aquario. O sistemafoi desenvolvido para permitir aos tratadores do aquario terem um acom-panhamento permanente sobre o mesmo sem terem de se preocupar comuma presenca fısica no local.

keywords Internet of Things, Smart Environments, Aquarium Monitoring, Sensors

abstract With the constant evolution of technological solutions arises the exigency tocreate approaches that allow us to automate some of the processes associ-ated to our daily lives. Nowadays, it is more frequent to find many remotelymonitored and controlled scenarios, increasing the convenience and inter-action between humans and “things”. The Laboratory for Innovation andSustainability of Marine Biological Resources, Ecomare, has multiple aquari-ums with several species under study. One of those aquariums is the scenarioto this dissertation’s development, which main goal is the disclosure, mon-itoring and control of that aquarium. The solution has two components, aweb’s platform and a mobile application. Both platforms allow access tothe read values, related to the aquarium, collected by the available sensors.When values are not within a pre-defined threshold, alarms are triggered inorder to enable a quick response over the aquarium. The solution’s aim isto allow the handlers a permanent monitoring over the aquarium, withoutthe need of a physical presence in the facilities.

Contents

1 Introduction 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Software Development Methodology . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Document Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 State-of-the-Art 5

2.1 Water Quality Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Potential of Hydrogen . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.2 Temperature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.3 Conductivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.4 Dissolved Oxygen (DO) . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Internet of Things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.2 IoT Communication Protocols . . . . . . . . . . . . . . . . . . . . . . 10

LoRa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Sigfox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Zigbee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Wi-Fi vs Zigbee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Radio Frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.3 IoT Data Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Message Queuing Telemetry Transport (MQTT) . . . . . . . . . . . . 13

Constrained Application Protocol (CoAP) . . . . . . . . . . . . . . . . 16

Advanced Message Queuing Protocol (AMQP) . . . . . . . . . . . . . 17

Extensible Messaging and Presence Protocol (XMPP) . . . . . . . . . 18

2.2.4 Node-RED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.3.1 Database analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4 Web Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.4.1 Web Framework Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 24

i

ii Contents

Flask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Model-View-Controller Architecture . . . . . . . . . . . . . . . . . . . 24ASP.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Django . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.5 Mobile Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.5.1 Mobile Frameworks Analysis . . . . . . . . . . . . . . . . . . . . . . . 28

Ionic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28PhoneGap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.6 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.6.1 Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Camera Module v2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Camera Module NoIR v2 . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.6.2 Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.6.3 Radio Frequency Module . . . . . . . . . . . . . . . . . . . . . . . . . 332.6.4 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Temperature and Humidity . . . . . . . . . . . . . . . . . . . . . . . . 34Brightness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.7 Web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.8 Web servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.9 WSGI servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3 Requirements and System Design 393.1 Functional Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.1.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 393.1.2 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . 423.1.3 Use Cases Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.2 Adopted Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.3 Techinal Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.3.1 Architecture Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.3.2 Database Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4 Implementation 514.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.2 Aquarium Disclosure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.3 Web Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.3.1 Sensors Communication . . . . . . . . . . . . . . . . . . . . . . . . . . 544.3.2 Application Programming Interface (API) . . . . . . . . . . . . . . . . 554.3.3 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.3.4 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.4 Mobile Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.4.1 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5 Conclusions and Future Work 73

A Appendix 81

List of Figures

2.1 Aquatic pH levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Water temperature influence . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Water temperature’s influence in metabolic rate . . . . . . . . . . . . . . . . . 72.4 Salinity tolerance in species . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5 IoT applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.6 Characteristics Zibgee vs Wi-Fi vs Bluetooth . . . . . . . . . . . . . . . . . . 132.7 Message Queuing Telemetry Transport (MQTT) communication . . . . . . . 142.8 MQTT Publisher-Subscriber Model . . . . . . . . . . . . . . . . . . . . . . . . 152.9 Constrained Application Protocol (CoAP) mechanism . . . . . . . . . . . . . 172.10 Advanced Message Queuing Protocol (AMQP) publish-subscribe mechanism . 172.11 Node-RED nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.12 Node-RED dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.13 PostgreSQL features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.14 Model-Template-View Architecture . . . . . . . . . . . . . . . . . . . . . . . . 262.15 Raspberry Pi 3 Model B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.16 Camera Module v2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.17 Camera Module Noir v2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.18 Arduino Nano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.19 Radio Frequency Module HC-12 . . . . . . . . . . . . . . . . . . . . . . . . . 342.20 RHT03 Temperature and Humidity Sensor . . . . . . . . . . . . . . . . . . . . 342.21 Mini Photocell Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.22 Proxy server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.23 Reverse proxy server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.24 Green Unicorn (Gunicorn) used along with Nginx . . . . . . . . . . . . . . . . 38

3.1 Web Platform Use Cases Diagram . . . . . . . . . . . . . . . . . . . . . . . . 433.2 Mobile Platform Use Cases Diagram . . . . . . . . . . . . . . . . . . . . . . . 443.3 Architecture Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.4 Database’s Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.1 Application Programming Interface (API) example for GET requests . . . . . 554.2 API - Values read from sensors . . . . . . . . . . . . . . . . . . . . . . . . . . 554.3 API - Existing sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.4 API - Detected alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.5 API - Values read from temperature sensor . . . . . . . . . . . . . . . . . . . 574.6 Dashboard page - Last alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

iii

iv List of Figures

4.7 Dashboard page - Last sensor values . . . . . . . . . . . . . . . . . . . . . . . 584.8 Dashboard page - Last sensor values . . . . . . . . . . . . . . . . . . . . . . . 584.9 Statistics page - Temperature . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.10 Statistics page - pH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.11 Statistics page - Temperature graphic with zoom . . . . . . . . . . . . . . . . 604.12 Statistics page - Daily Temperature . . . . . . . . . . . . . . . . . . . . . . . . 604.13 Statistics page - Monthly Average Temperature . . . . . . . . . . . . . . . . . 604.14 Alarms page - Alarms list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.15 Alarms page - Alarms list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.16 Alarms page - Alarms list filter and Export report . . . . . . . . . . . . . . . 624.17 Alarms page - Alarms list with filter . . . . . . . . . . . . . . . . . . . . . . . 624.18 Gallery page - Live stream video . . . . . . . . . . . . . . . . . . . . . . . . . 634.19 Settings page - Sensors list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.20 Settings page - Add sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.21 Settings page - Values range for each sensor . . . . . . . . . . . . . . . . . . . 644.22 Settings page - Edit range of values for a sensor . . . . . . . . . . . . . . . . . 654.23 Django admin page - Database, Users and Groups . . . . . . . . . . . . . . . 654.24 Django admin page - Users management . . . . . . . . . . . . . . . . . . . . . 664.25 Application Main Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.26 Last Values Page with Last Alarms . . . . . . . . . . . . . . . . . . . . . . . . 704.27 Last Values Page with Last Values collected . . . . . . . . . . . . . . . . . . . 704.28 Potential of Hydrogen (pH) statistics . . . . . . . . . . . . . . . . . . . . . . . 714.29 pH statistics (with zoom) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.30 Temperature statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.31 Alarms Page - List of alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.32 Gallery Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.33 About Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

A.1 Database Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81A.2 Database Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

List of Tables

2.1 Internet of Things (IoT) protocols comparison (adapted from [1] [2]) . . . . . 192.2 Mobile cross-platforms comparison [3] . . . . . . . . . . . . . . . . . . . . . . 29

v

vi List of Tables

Acronyms

AJAX Asynchronous Javascript and XML

AMQP Advanced Message Queuing Protocol

API Application Programming Interface

BLE Bluetooth Low Energy

BLOB Binary Large Object

BSON Binary JSON

CoAP Constrained Application Protocol

CPU Central Processing Unit

CSI Camera Serial Interface

CSS Cascading Style Sheets

DO Dissolved Oxygen

DSI Display Serial Interface

GPIO General-Purpose Input/Output

GPS Global Positioning System

Gunicorn Green Unicorn

HDMI High-Definition Multimedia Interface

HTML HyperText Markup Language

HTTP Hypertext Transfer Protocol

IoT Internet of Things

IP Internet Protocol

JS JavaScript

JSON JavaScript Object Notation

vii

viii Acronyms

LoRa Low-Range Technology

LoRaWAN Low-Range Wide Area Network

LPWAN Low-Power Wide Area Network

MQTT Message Queuing Telemetry Transport

MTV Model-Template-View

MVC Model-View-Controller

M2M Machine To Machine

NLOS Non-Line-Of-Sight

NoSQL Not Only SQL

ORDBMS Object Relational Database Management System

ORP Oxidation Reduction Potential

pH Potential of Hydrogen

QoS Quality of Service

RAM Random Access Memory

REST Representational State Transfer

RF Radio Frequency

RFID Radio Frequency Identification

RPi Raspberry Pi

RTMP Real-Time Messaging Protocol

SASL Simple Authentication and Security Layer

SD Secure Digital Card

SOAP Simple Object Access Protocol

SQL Structured Query Language

TCP Transmission Control Protocol

TLS Transport Layer Security

UDP User Datagram Protocol

URI Uniform Resource Identifier

URL Uniform Resource Locator

USB Universal Serial Bus

ix

WAN Wide Area Network

WLAN Wireless Local Area Network

WSGI Web Server Gateway Interface

WSN Wireless Sensor Network

XML Extensible Markup Language

XMPP Extensible Messaging and Presence Protocol

x Acronyms

1

Introduction

The IoT presented an exponential growth over the last years. In our daily routine it ismore common to find connection between all types of objects and “things”. This is the realitywe live in and it has a trend to increase as our future will depend on it.

The need to connect a large number of objects of our days brought the ability to reactremotely over those devices. This capacity to control the devices in such an easy way is anasset in cases of extreme urgent actuation or in a simple ordinary situation.

1.1 Motivation

Ecomare, which was recently inaugurated, is the Laboratory for Innovation and Sustain-ability of Marine Biological Resources of Aveiro’s University. This laboratory combines theCentro de Extensao e de Pesquisa Ambiental e Marinha (CEPAM) and Centro de Pesquisa eReabilitacao de Animais Marinhos (CPRAM).

This center works as a veterinary unit to treat animals at risk and has a component ofinvestigation and technology transference related to the sea under scientific orientation of theUniversity of Aveiro and Sociedade Portuguesa de Vida Selvagem.

This center is equipped with a few aquariums so that some species and environment condi-tions could be studied. One of these aquariums works as a tester to the work developed. Theaquarium will be equipped with sensors to measure some chemical and physical parametersrelated to the water control system.

The parameters and their range of values can change according to the different species.Variations on these values can lead to dramatic consequences for the animals and this is thebiggest motivation for this project.

1

2 Chapter 1. Introduction

1.2 Objectives

The work presented in this dissertation took into account the involvement and importanceof IoT and consisted on the development of a functional platform to control a set of sensorsrelated to an aquarium.

There are many parameters to consider concerning aquarium species. In this specificcase, the aquarium not only has several fish species, but also corals and echinoderms and hascapacity to uphold around 1500L of water. The values in each sensor need to be checked inshort periods of time to ensure there are no problems with the different species.

Despite the sensors’ monitoring purpose, this platform plays an important role whenconsidering sensors’ control. For each sensor it is necessary to establish a range of values thatare considered normal and, when one of those values is outside the pre-defined range, an alarmmust be triggered and an action should be performed to control the anomalous situation.

Another objective of this work was the aquarium’s promotion to the general public bymaking live video streaming available on Youtube.

In specific, the web’s platform should allow the access to the values read from the aquar-ium’s sensors, and the readings outside the established range should be displayed with greateremphasis, so the handler can pay attention over these values.

Furthermore, the platform should allow access to statistical data achieved through valuesregistered over the time. This information should be shown with the help of line graphics.

A list of alarms must be displayed considering all the values that were recognized asunusual, allowing the user to check them as seen, so that they are not shown again.

The web’s platform should have a section to watch the live video streaming. A page ofsettings should be available so that the authorised users can access and change the internalinformation of the system, such as sensors and alarms.

A mobile application should be developed in order to show not only the last alarms andlast values read but also some statistics, considering the existent sensors and its readingsalong the current day.

1.3 Software Development Methodology

The methodology adopted in the beginning of this dissertation was based in AGILE, whichimplements an alternative approach to the traditional methods of software development.

This type of method has a few rules instigating the developer to achieve the final objectiveand guarantee the possibility of improvement along the several steps. For that, AGILEimplements a set of principles for software development under some requirements that leadto successful products [4].

The main essence according to this method pursues the following steps: Conception,Initiation, Analysis, Design, Construction, Testing and Deployment.

The first step taken was the product’s conception, where the idea of the product needsto be clearly defined to be able to carry onto the next steps successfully. Initiation andAnalysis are two processes that can occur simultaneously. In these stages, we can considerthe requirements’ analysis, use cases and apply the ideas set in the conception phase. Whenboth phases were surpassed, the following two were Design and Construction, which canalso have a parallel execution. The mock-up of the application needs to be slightly definedbefore the construction starts, however some details may change during the development

1.4. Document Organisation 3

process. Finally, the Tests and Deployment were gathered. In fact, for the final process to becompleted, all tests must be running successfully and only then is the product finished andready for production.

1.4 Document Organisation

This document presents all the research, implementation and conclusions related to thework developed and is divided in five different chapters:

• The first and current chapter presents the motivation, objectives and main idea behindthis dissertation.

• The second chapter, State-of-the-Art, presents the results of the research, the frame-works and technologies used, as well as all the related themes.

• The third chapter, Requirements and System Design, reveals the architecture under-lying the building system and the requirements around it.

• The fourth chapter, Implementation, describes the several steps to achieve the finalsolution referring the challenges and all the decisions that were taken.

• The fifth chapter, Conclusions and Future Work, presents the final considerationsabout all the work developed and provides suggestions for the future.

4 Chapter 1. Introduction

2

State-of-the-Art

This chapter has a summary of important measured water parameters and it also presentsthe written result of the research on web and mobile frameworks and Internet of Thingsfundamentals applied in this dissertation.

2.1 Water Quality Monitoring

Aquarium monitoring implies the control of several parameters that are significant tothe living species [5]. According to this, the next sections will explain and present someconsiderations about the important parameters to be measured.

2.1.1 Potential of Hydrogen

The pH is a scale used to measure the acidity/basicity of a solution. The scale used has arange from zero (0) to fourteen (14) and the number seven (7) represents a neutral solution.Considering the previous scale, values below seven represent acid solutions and values aboveseven, basic solutions.

Figure 2.1 shows a graphical representation of the pH scale and its influence in a fewspecies.

Most fish species live in environments with a pH between 6.5 and 9.0, which is consideredtheir ideal pH. However, this number varies according to several conditions in and outside theaquatic environment and some species do not cope well with aggressive variations, as thesespecies are sensitive to pH’s fluctuations. Moreover, the values can increase stress in speciesand reduce the chances of reproduction and ultimately, may compromise their survival [6].

A pH below 5.0 affects fishes’ reproduction and one below 4.0 is even life threatening. Asin with low levels of pH fishes are more susceptible to get diseases considering they are moresensitive. Also, low values of pH can lead to solubility of heavy metals which increase theconcentration of metals in the water and also its toxicity. These metals are absorbed by fishesduring their respiration and that can cause physical damages [6].

On the other hand, high levels of pH cause skin and gills problems and levels above 10culminate in death [6].

5

6 Chapter 2. State-of-the-Art

Figure 2.1: Aquatic pH levels [6]

2.1.2 Temperature

The water temperature is one of the most important parameters to quantify consideringits influence on the other ones.

Figure 2.2: Water temperature’s influence [7]

The temperature, as shown in Figure 2.2, affects parameters related to water conditionssuch as pH, conductivity and salinity, Dissolved Oxygen (DO), toxicity and Oxidation Re-duction Potential (ORP) [7].

The variation of temperature can lead to metabolic rate increase of animals, unfortunatelysome of them can not handle this forceful change [7].

It has been proven that each 10° C increase in water temperature raises the metabolicrate to double, as seen in Figure 2.3.

Temperature is implied in solubility gases and they decrease with higher temperatures.Cold environments have more dissolved gases, including oxygen, rather than hot ones. If thewater is too hot, there is not enough oxygen for species to survive [7].

2.1. Water Quality Monitoring 7

Hotter water is usually more dangerous than colder water. The unusual levels are associ-ated with problems in growth, reproduction and survival of the species. Cold water can affectbiological and metabolic processes, while hot water is responsible for excessive respirations,increasing the species’ stress [7].

Figure 2.3: Water temperature influence in metabolic rate [7]

2.1.3 Conductivity

Conductivity is related to water’s capability to conduct an electric flow. This is associatedwith the concentration of ions found in the water. These ions come from dissolved salts andinorganic materials and these values are indicators of water changes. Therefore, the moreexistence of ions, the more conductive is the water. Otherwise, the less ions, the lower is theconductivity [8].

Salinity is the total concentration of dissolved salts in water. According to this definition,salinity contributes to conductivity. Salinity can be measured through chemical methods,although in this case it is not viable. This point is where conductivity gets to help findsalinity values. The derivation of salinity from the conductivity values is called practicalsalinity [8].

The salinity affects the dissolved oxygen levels directly, which implies a higher salinitylevel and a lower dissolved oxygen concentration [8].

The species’ capacity to respond to salinity is related to osmotic processes and variesaccording to the several species [8].

Figure 2.4 shows the different salinity levels according to three species of fishes.The alteration of conductivity in a certain environment can produce negative effects in the

organisms’ metabolism. These alterations can be caused by different temperatures or salinitylevels [8].

Most fishes are adapted to a fixed salinity value and several changes can result in deathdue to alterations in dissolved gases and osmotic regulation [8].


Figure 2.4: Salinity tolerance in species [8]

2.1.4 Dissolved Oxygen (DO)

DO is the free oxygen present in water. Free oxygen (O2) is the oxygen that is notconnected to other elements, i.e., the free molecules of oxygen. This enters the water throughthe air or the plants’ process of photosynthesis [9].

DO is essential to species’ survival considering its use in respiration. The changes in thisparameter is noticed through the loss of species and diseases. A low level of DO leads todeath and its high level develops gas bubble disease and consequently results in death [9].

2.2. Internet of Things 9

2.2 Internet of Things

Throughout the times our connection to the Internet and its relations has been increasingand becoming stronger so that we can no longer live without the resources it provides.

The need to be connected every time and everywhere is clearly a signal that things aregoing to evolve and our daily lives will be entirely surrounded by technological solutions,which help us take our decisions and make our life easier. The IoT is one of those solutions,which is growing faster as it promises to connect all things around us.

2.2.1 Definition

“The term “Internet of Things” was popularized by the work of Auto-ID Center at theMassachusetts Institute of Technology (MIT), which in 1999 started to design and propagatea cross-company Radio Frequency Identification (RFID) infrastructure.” [10] Although theterm started at Auto-ID Center, it quickly expanded and by 2005 it was already spreadworldwide.

The concept of IoT appeared combined with the ubiquitous computing concept thatemerged from Weiser in the early 90’s. This vision revealed the interconnection of smalldevices that used sensors to monitor fixed parameters and actuators to remotely control thesame parameters. [11]

“The IoT aims at enabling the interconnection and integration of the physical world andthe cyber space.”[12]

Figure 2.5: IoT applications

The frequent connection of physical things to a network brought the manipulation of severaltype of data. This communication makes us reflect upon a few aspects, such as data collecting,data storage and analysis.

Despite the points previously mentioned there is also the need to provide “services forinformation transfer, applications and communications” [13].


The demand for several sensors operating for different measures and their low capacity,made us consider elements as memory, processor, power, among others, which led to theimplementation of wireless communication to obtain a better performance.

The set of sensors operating together to monitor a region is called Wireless Sensor Network(WSN) [14]. These sensors have the capacity to communicate between them using theirwireless interfaces forming a network and this introduces the concept of WSN in IoT.

A WSN can have two possible layouts according to its infrastructure: structured andunstructured.

A structured network considers a pre-designed arrangement form for displaying the sensors(all or some of them). This type of structure assists in management and maintenance costssince the nodes are presented in specific places to cover the predicted area.

An unstructured network has a different layout and the sensors are displayed in ad-hocmode, meaning that each sensor is installed at a random position. This kind of networkincludes a higher number of sensors, guiding to a greater expense and a harder networkmanagement [14].

A WSN has several useful “applications in scenarios such as military target tracking andsurveillance, natural disaster relief, biomedical health monitoring and hazardous environmentexploration and seismic sensing” [14].

IoT has grown since its appearance and it is estimated that within a few years the majordevices, known as “things” in this context, are connected to the Internet and with each othermaking global communication possible.

A lot of applications with this concept are already visible around us (as seen in Figure2.5) like smart fridges, which display their contents and alert for the lack of some essentialsproducts; smart houses with windows, doors, garages and lights remotely controlled; smartfarms with controlled dosage of watering or organic fertilizer. The list of scenarios continuesand in a near future it will definitely increase.

The IoT application in the context of this dissertation brings the possibility to havea frequent control over the physical and chemical water parameters to prevent and avoidanomalous situations with the aquarium and its species.

2.2.2 IoT Communication Protocols

There are several types of communication protocols related to IoT. The defined standardfor IoT communication is not clear about the best protocol to use is. Wi-Fi, Zigbee, Bluetooth,Radio Frequency, are among some of the most used protocols.

The communication used in WSN has some constraints considering the low consumption,short communication range, limited storage and processing and low bandwidth [14]. Accord-ing to previous conditions, this type of network needs specific attributes to operate properly.

The characteristics of the protocols used in this type of networks are presented below.

LoRa

Low-Range Technology (LoRa) is a low-power and long-range wireless communicationtechnology thought to Wide Area Network (WAN). This technology’s modulation is chirpspread spectrum based which preserves the low-power characteristics, increasing the commu-nication range. The chirp spread spectrum is an approach that uses chirp pulses to encode


information. A chirp is a signal that increases or decreases over the time, according to thefrequency [15] [16] [17].

Low-Range Wide Area Network (LoRaWAN) is the LoRa applied to a WAN. While LoRaphysical layer enables the long-range communication, LoRaWAN “defines the communicationprotocol and system’s architecture for the network, and behaves as a media access control layerprotocol for managing communication between Low-Power Wide Area Network (LPWAN)gateways and end-node devices” [15].

“The network capacity, the quality of service, battery lifetime of a node, the securityand the variety of applications served by the network” are the main focus of the LPWAN’sprotocol and architecture [15].

Sigfox

Sigfox is a technology with a modulation based on ultra-narrow band with a limited uplinkconnection. This type of modulation allows achieving at a maximum data rate of 100 bps bytransmitting messages with 12 bytes of maximum payload length [18] [19].

This technology implements a lightweight protocol to adopt a battery saving mechanism.This is achieved considering that less data to send implies less energy consumption. Sigfoxhas a star network architecture where a device can connect to any base station within a rangeof 3 base stations. This technology was designed to return a “long device battery life-cycle,low device cost, low connectivity fee, high network capacity and long range” [18].

Bluetooth

Bluetooth for IoT is also known as Bluetooth Low Energy (BLE) or Smart Bluetooth andit is based on IEEE 802.15.1 standard. In comparison to the original Bluetooth, this one hasa reduced cost and power consumption with a very similar communication range.

This type of communication operates in 2.4 GHz frequency and supports data transmissionrates up to 1Mbps and a distance range around 100 meters. [20]

Wi-Fi

Wi-Fi is based on IEEE 802.11 standard and is a wireless network technology. Some ofthe characteristics of this type of network are bandwidth of 2.4 or 5 GHz; it has a maximumbit rate of 54 Mbps in physical layer and 24.7 Mbps as the limit for data transfer; it allowsstar and ad-hoc typology; it admits encryption and authentication mechanisms [21].

Besides the previously listed Wi-Fi features, it also has “high rate and bandwidth andlarge-scale data collection” [22].

Zigbee

Zigbee is based on IEEE 802.15.4 specification used for many scenarios placed in WSN.It is defined by low power consumption, low data rate (250 kbps) and short range.

Addressing and routing for tree and mesh topologies are supported for Zigbee. This isused essentially in applications for home automation and smart energy solutions [23].

This technology is different from Bluetooth and Wi-Fi because it is simpler and lessexpensive, considering its capability to start sleep mode according to traffic presence [20]. Itis mainly used for low data rate applications working as a secure network. Despite all the


pros, this technology transmits only to limited distances and the capacity to cross barriers iscompromising [22].

Wi-Fi vs Zigbee

In addition to the attributes mentioned before around Wi-Fi and Zigbee, and consideringthe relevance of both communication protocols, some advantages specifying the preference ofWi-Fi over Zigbee are presented [22]:

• High Bandwidth - while data transfer with latest Wi-Fi technology (802.11n) can reach300Mbps, Zigbee can only get a maximum rate of 250 Kbps. This leads to a betterperformance with a reduced delay.

• Non-Line-Of-Sight (NLOS) Transmission - Wi-Fi has the capability to communicatethrough obstacles.

• Large Coverage Area - Zigbee can cover a range from 10 to 75 meters while Wi-Fi cancover to an extent of 300 meters outdoor and 100 meters indoor.

• Cost-effective - a wireless sensor network built over the existing Wi-Fi network canreduce the costs.

• Easy Expansion - Wi-Fi sensor nodes can support up until 100 wireless connectionswhich is considered more indicated for further scalability.

• Strong Robustness - the tree topology used in Wi-Fi makes the network more reliablein case of failures.

Radio Frequency

Radio Frequency (RF) represents the oscillation rate of electromagnetic radiation spec-trum that can have a range starting in 9 KHz and achieving frequencies of 300 GHz.

This type of communication uses antennas and transmitters to be able to send and receivethe communication signals.

The RF module is used to send and receive radio signals between two devices. This sortof communication is known for travel large distances which is convenient for longer rangeapplications. RF signals can navigate with obstacles in the line of sight between transmitterand receiver.


Technologies comparison

Figure 2.6: Characteristics Zibgee vs Wi-Fi vs Bluetooth [24]

2.2.3 IoT Data Protocols

Regarding IoT data protocols, we should focus our attention first on the main commu-nication protocols used on the Internet, which act as an interaction mean between com-puter networks. Therefore, we suggest a brief introduction of the two leading base protocols:Transmission Control Protocol (TCP) and User Datagram Protocol (UDP).

“The TCP is a protocol for packet-switched computer communication networks and in-terconnected system of such networks, designed to be reliable” [25]. This protocol providesreliability, packets ordering and error-checked packets delivery.

Otherwise, UDP uses messages to communicate between hosts known as datagrams. Theyuse a connectionless transmission model and it provides checksums to guarantee data integrity.On the other hand, there are no handshake dialogues which lead to a lack of reliability of thisprotocol. There are no delivery confirmation, packet ordering or duplication protection [26].

Message Queuing Telemetry Transport (MQTT)

MQTT was invented by Andy Stanford-Clark of IBM and Arlen Nipper of Arcom (nowEurotech), in 1999 [27]. This is a messaging protocol based on publish-subscribe patterndesigned to be used in devices with high-latency and low-bandwidth and run over TCP/IPprotocol. The principles used in MQTT make it an ideal protocol to use in IoT and MachineTo Machine (M2M) 1 applications considering the category of devices used.

1M2M - communication between devices using any communications channel, including wired and wireless.


This messaging protocol uses clients as publishers and subscribers to produce the messageexchange. This communication also needs a broker to process the messages.

When a client intends to send a message, it establishes the connection with the brokerand then sends the information.

The first message exchanged between client (publisher or subscriber) and broker is a“CONNECT” message that contains some parameters. One of them is the Client ID, so thebroker knows which client is connected to. Despite the recognition’s purpose, this ID is alsoused to guarantee the Quality of Service (QoS) level when a potential network failure occurs.

When the connection between the two entities takes place, the information sent by theclient (publisher) is always added to a specific topic it defined. On the other hand, a subscriberis a client who requires receiving messages from a specific publisher, or in this case, from aparticular topic. To do that, the client needs to subscribe the topic from which it wants toreceive information from. This is the basic process of publish-subscribe pattern consideringthe entity which sends and the one that receives the information from as it can be seen infigure 2.7.

Figure 2.7: MQTT communication [28]

All messages are followed by an acknowledge to guarantee the delivery’s success.

The middle agent in all this procedure is the broker. It has the function of connectingthe publishers and subscribers to the topics in question and has to ensure this connectionthrough a ““keep-alive” timer which defines the maximum time interval that may elapsebetween two messages received from that client” [29]. If during this time there are no messagestransmitted, the client sends a PING to the broker and this can detect an eventual failureon the communication process. The PING messages are split in PINGREQ and PINGRESP,respectively meaning, ping request and ping response [28].

MQTT has three levels of QoS according to the reliability of messages delivered [29]. Thelower level is zero and considers a service delivery with no guarantee that the messages reachtheir destination, i.e., without acknowledgement or retransmission. This QoS type can delivera message only once or even not at all.

Level one is more reliable considering the retransmission of the information until an ac-knowledge message is received from the destination. This level has an adjacent problem thatis the risk of several repeated messages being delivered due to the retransmission.


The highest level is the QoS level two that ensures the reception of the messages only onceby the destination.

According to Hunkeler, Truong and Stanford-Clark’s article [29], “a temperaturemonitoring application could decide to use QoS level zero for the publication of normal andregular measurement reports, but QoS level one for transferring alarm messages when thetemperature exceeds a certain threshold”. All things considered, the QoS level must bechosen according to the used application in order to obtain the best outcome for the aimedeffect.

MQTT Brokers

As mentioned before, a broker is required to handle the communication between publishersand subscribers. “MQTT broker acts like a filter allowing only the requested data therebysaving the flow of ambiguous data” [30].

Figure 2.8 shows how a broker works as middle mediator between publishers and sub-scribers.

Then, two broker options that can be used along with MQTT will be presented.

Figure 2.8: MQTT Publisher-Subscriber Model (adapted from [31])

Mosquitto

Mosquitto is an iot.eclipse.org project and it is an open source MQTT broker. Thistechnology implements the MQTT protocol using version 3.1. [32].

Mosquitto broker supplies a lighter implementation of MQTT that can be applied to lowor high power devices.

HiveMQ

HiveMQ is a MQTT broker belonging to HiveMQ company and was thought to enterprisescenarios. It integrates MQTT 3.1 and MQTT 3.1.1 to be compatible with MQTT [31]. Someof its features are [31]:

• Great performance - allowing real-time communication between applications and de-vices.

• Elastic clustering - clusters with high availability to guarantee a good reliability.


• Enterprise grade security - existent mechanisms of authorization, authentication andTransport Layer Security (TLS) encryption.

• Extensions - HiveMQ allows the creation of extensions or using its owns.

• 100% MQTT compliant - supports all the MQTT versions.

All the characteristics described before are relevant in a broker. Despite that, this one isthought for enterprise context and so,it is not a free tool.

MQTT Clients

A MQTT client is responsible for collecting information from a device, connecting to thebroker, that acts as an intermediary between both edges entities (publisher and subscriber),and also for using a topic to publish the information obtained from the device mentioned.This time, another client, a subscriber can get the published information [33].

The topics below describe two types of MQTT clients.

Paho-MQTT

Paho-MQTT is a Python library which implements versions 3.1 and 3.1.1 of MQTT proto-col. This library provides a class client to allow applications to be published to and subscribedfrom topics, respectively [34].

HiveMQ Websocket Client

HiveMQ Websocket Client is a tool created by HiveMQ to work as a MQTT client and“supports all common protocol features except persistent session” [31].

It has an interface that allows publishing or subscribing by following some clicks throughthe default’s options. It allows connection with local brokers using an Internet Protocol (IP)address or hostname.

Constrained Application Protocol (CoAP)

CoAP is an application layer protocol developed to be used by devices with constrainedresources to communicate. It is based on Representational State Transfer (REST) technologyand considering its execution over Hypertext Transfer Protocol (HTTP), it allows a request-response model.

CoAP supports a publish-subscribe pattern but in contrast with MQTT (2.2.3), the pub-lication of the information is not in topics but based on an Uniform Resource Identifier (URI).An URI is a string of characters to identify a resource, allowing interaction over network usingspecific protocols, in this case, the CoAP. This works as follows: when a publisher wants topublish information, it publishes to the URI X; on the other hand, the subscriber subscribesa particular resource, in this case, the URI X; from here, the subscriber, connects to the URIunder discussion, it receives a notification of new data published and can access it [36].


Figure 2.9 represents the main idea about CoAP operation.

Figure 2.9: CoAP mechanism [35]

Advanced Message Queuing Protocol (AMQP)

The initial concept of AMQP came out in London in 2003 by John O’Hara. This protocolis identified by message orientation, queuing, routing, security and reliability [37].

This is an application layer protocol for message-oriented middleware and assumes TCPas the base transport layer protocol.

Figure 2.10: AMQP publish/subscribe mechanism [35]

To guarantee the interoperability between systems, AMQP defines two sides: networkingprotocol and server-side services. The points referred to before are ensured by the followingcharacteristics [38]:

• “a set of defined messaging capabilities called Advanced Message Queuing ProtocolModel (AMQ model)”. This model combines a set of components responsible for mes-sage routing and storage and also rules to wire these components.

• “a network wire-level protocol, AMQP” that allows communication between clients andserver and provide an interaction with AMQ model.


The AMQ model has three main components: “exchange”, “message queue” and “bind-ing” (figure 2.10). “Exchange” has as the role of receiving messages from publishers androute them to “message queues” according to some criteria like messages content and prop-erties. “Message queues” supports the storage of all the messages received by “exchange”,until they are available to be processed. “Binding” is responsible for criteria creation used by“exchange” to send messages to “message queue” [38].

Extensible Messaging and Presence Protocol (XMPP)

Originally named Jabed, Extensible Messaging and Presence Protocol (XMPP) was de-veloped by Jabed open-source community in 1999 to obtain near real-time Instant Messaging(IM) between several network entities [39]. This was created to contribute as alternative tothe services existent in those times.

Although developed for instant messaging, XMPP was used also for presence informationand contact lists.

One of the advantages of this protocol consists on its decentralized architecture. Thisleads anyone to have the power to run their own XMPP server, assuming the total controlover the communications.

Confine the XMPP server from the public network and use Simple Authentication andSecurity Layer (SASL) 2 and TLS3 is the security’s purpose. Also, it is been developed aend-to-end encryption in order to increase the security around this protocol [39].

Among the previous mentioned attributes, XMPP is open-source and it is a standardprotocol. It is been proven to have a good performance and it is used by several companieswith success. Also, is an extensible protocol by the use of Extensible Markup Language (XML)4, allowing to build functionalities over the core protocols [39].

Finally, the flexibility allowed by XMPP is recognised and that is seen in its application on“network management, content syndication, collaboration tools, file sharing, gaming, remotesystems monitoring, web services, lightweight middleware and cloud computing” [39].

Although not developed to be used in IoT, XMPP extensibility and flexibility, that canlead to its application in different scenarios, can drive this protocol to be appropriate for theIoT, in the future.

2SASL - framework for authentication and data security in Internet protocols.3TLS - cryptographic protocol that provide communications security over a computer network.4XML - markup language that defines a set of rules for encoding information in a specific format. XML is

essentially used to represent data structures, namely in web services.


Protocols comparison

Table 2.1 shows a comparison between the IoT protocols described before.

MQTT CoAP AMQP XMPP

Publish/Subscribe Yes Yes Yes Yes

Request/Response No Yes No Yes

Transport TCP UDP TCP TCP

SecurityMedium/ Medium/ High/ High/Optional Optional Mandatory Mandatory

QoS Yes Yes Yes No

Dynamic Discovery No Yes No Yes

Encoding Binary Binary Binary Plaintext

Real time No No No Near Real Time

Table 2.1: IoT protocols comparison (adapted from [1] [2])

2.2.4 Node-RED

Node-RED is a tool for building IoT applications by wiring all the blocks together. Thisway they can be related to an intelligent system and hide some of the complexity attached tothem.

There are code blocks called ’nodes’ that can be connected. This way, the tool allowsthe developer to create a connect input, output and processing nodes by just configuring afew parameters that are required, enabling a full connectivity between the endpoints in thesystem [40].

The approach of Node-RED is based on a more visual vision over the interconnectionbetween the several nodes, taking advantage of the code abstraction and only some essentialconfigurations were required to make the connection happen. When all this nodes get together,they are called flows.

This product was created by IBM in 2013 for their own benefit, but it quickly proved tobe a very useful tool for general users and was extended to a larger range of applications,other than IoT [40].

This tool was created to be powerful and flexible and for that, two main factors wereconsidered essential [40]:

• Flow-based programming model - describes the application’s behaviour as a network ofnodes, where their real complexity is not obvious. Some data arrives at each node andafter performing its function, the data follows the flow’s direction.

• Set of built-in nodes - allows the use of nodes with ability to do complex tasks yet thedeveloper does not need to concern about the complexity of those tasks.


“Node-RED consists of a Node.js-based runtime that can be pointed to a web browserto access the flow editor [40]”. After having the access, the nodes are available to createflows. They are shown, dragged and dropped to a central workspace, where we start to buildour system flow. In addition to the existing nodes, others can be added by installing somepackages on the Node-RED running space.

After all the nodes were wired together, the application is compiled and deployed. Theresults can be seen at runtime. A dashboard can be also accessed to see some graphics withthe processed data [40].

In figure 2.11 and 2.12 we can see an example of nodes’s flow and dashboard results.

Figure 2.11: Node-RED nodes [40] Figure 2.12: Node-RED dashboard [40]

2.3. Database 21

2.3 Database

One of the requirements to support all the incoming data from sensors is a database. Thedata is collected and saved on a relational database.

There are two main database types: relational and non-relational, also known as Not OnlySQL (NoSQL). MySQL and PostgreSQL are two examples from relational database. On theother hand, MongoDB is a non-relational database.

The essential difference between both types is the use of tables and rows in relationaldatabase versus documents with JavaScript Object Notation (JSON) 5 format innon-relational database.

It is also important to emphasize that data manipulation in relational databases is madethrough Structured Query Language (SQL) queries while in non-relational databases, object-oriented APIs 6 are used .

2.3.1 Database analysis

The current and next sub-section analysis intends to show the differences between someof the existing databases.

The analysed relational databases were MySQL and PostgreSQL and the non-relationalwas MongoDB.

MySQL

MySQL is an open-source relational database management system owned by Oracle Cor-poration. Besides this open-source component, there is also an enterprise edition with morefeatures available and directed to companies.

This database was created to support a larger amount of data and faster than the existentdatabases. This brought the need of MySQL to become faster, reliable and scalable [42].

MySQL is still under improvement, but offers an important set of functions and aspectsas speed, security and connectivity that provides reliability to the user [42].

As a client-server system, MySQL has a “multi-threaded SQL server that supports dif-ferent back ends, several different client programs and libraries, administrative tools, and awide range of application programming interfaces (APIs)” [42].

As an open-source system, MySQL has a set of features available for the users and alarge number of applications that can easily be combined with this system [42]. Also, theinformation available about this database management system is enormous considering itslarge community of users.

MongoDB

MongoDB is an open-source non-relational database and it is based on the principlesmarked by the NoSQL databases. They do not use the relational database managementsystem principles and, as mentioned before, tables and rows are not used to save the data.

5JSON - lightweight format for data exchange. JSON is an independent text format language, based onsome conventions used by some languages such as C, C++, C#, Java, JavaScript, Perl, Python. This textformat is built under two structures: key-value pairs and ordered list of values [41].

6API - set of protocols and tools to build application’s software, that defines methods for communicationbetween different components.


Instead, it uses pairs of key-value. The key works as the unique identifier of the data and thevalue, in this case, is the saved data [43].

Despite using the key-value pairs, there are three different ways to save data in a non-relational database: document, column and graphic-oriented. If we take into account thatMongoDB is under study, the focus will be on explaining the operation mode for this typeof database. Therefore, the data persistence is based on documents. This provides us witha flexible database considering there are no pre-defined schema and there are different typesof documents available to work with: JSON, XML, Binary JSON (BSON) and Binary LargeObject (BLOB) [43].

JSON and XML were already explained before.

BSON is a binary-encoded format that MongoDB uses behind the scenes to representJSON documents [44]. It is used to store documents and make remote procedure calls.

BLOB is a collection of binary data stored as a single entity in the database.

The different types described are a specialization of key-values databases. This kind ofdatabase is more flexible with attributes’ addition or removal because there is not a fixedschema [43].

PostgreSQL

PostgreSQL is an Object Relational Database Management System (ORDBMS) developedby a team from California University at Berkeley [45].

A ORDBMS is a very similar system compared to a relational database but it has anobject-oriented database model. This system explored the use of classes and inheritance toblock the difference between conceptual data modelling techiques and object relation mapping.

Initially, PostgreSQL did not support SQL and it was only in 1994 that that featurewas implemented. Nowadays, PostgreSQL supports many features that do not exist in otherDBMS. These features include triggers, procedures, views, indexes beyond private and foreignkeys and atomic operations [45].

Figure 2.13 shows some of the features supported by PostgreSQL.

Figure 2.13: PostgreSQL features [45]

Some of the advantages of PostgreSQL’s usage are [45]:

• Immunity to over-deployment - the use of the software is free and there is no need forlicensing.

• Better support than the proprietary vendors - existence of several experts in this areato answer the questions.

2.3. Database 23

• Significant saving on staffing costs - the lower maintenance reduces the costs.

• Legendary reliability and stability - there are no indications of failures.

• Extensible - the code is available for everyone to be completed.

• Cross platform - available for different platforms.

• Designed for high volume environments - use MVCC strategy to obtain good responsesin situations with more volume of information. MVCC (Multiversion Concurrency Con-trol) is a control method to avoid several accesses at the same time to the same infor-mation, i.e., a concurrent strategy.

• GUI database design and administration tools - there are many interfaces to deal withPostgreSQL.

• ACID (Atomicity, Consistency, Isolation, Durability) compliant - Atomicity to guaran-tee that a transaction is made from the beginning to the end without failures; if there isa failure, the transaction will not be executed. Consistency to guarantee that databasegoes from a stable state to another. Isolation to prevent access at the same time fromdifferent entities. Durability for when a transaction is committed remains the same way,despite external events.


2.4 Web Frameworks

Some web frameworks were addressed along this section and studied within the scope ofthis dissertation. There is a performance and features’ analysis in order to realize which thebest framework to fit this work specifications is.

A web framework is a software developed to support web applications development that in-cludes web resources, services and APIs. Web frameworks plan to automate web application’sdevelopment providing means, including libraries, to achieve a better and faster solution.

2.4.1 Web Framework Analysis

The frameworks chosen to be a comparison target were Flask, ASP.NET and Django.The next paragraphs will explain a software architecture model used frequently and eachframeworks’ characteristics with more detail.

Flask

Flask is a microframework for web application development that uses Python. A mi-croframework is a web framework that rules by the minimum conditions to act as one. Thismeans that a microframework has lack of features that are present on other frameworks such asauthentication, authorization, database abstraction or input validation. This type of frame-work is more indicated to handle HTTP requests and give response to APIs requirements[46].

A microframework is lighter than other frameworks considering the small number of as-sociated dependencies. On the other hand, the developer has more work to be done, addingthe list of plugins and dependencies needed to build the application [46].

The ASP.NET and Django frameworks use the same architecture. In that way, it will bedescribed in the following lines.

Model-View-Controller Architecture

Some frameworks use an architecture that make a clearly separation between three es-sential components related to the web’s development. The Model-View-Controller (MVC)architecture split up the concepts of models, views and controllers.

The MVC design pattern is based on the division between the data layer and its repre-sentation to the final user. Taken this model into account, it is more straightforward to builda project which can easily be adapted to the existing needs without drastic changes. All thisis consequence of the layer independences presented previously.

The ’model’ includes all the interaction to the database without considering any parame-ter related to the data’s visualisation. The database is the beginning of every application. Itis at the database level that all the needed information is presented so that everything worksproperly and accomplishes a successful interaction. A well-structured database can preventseveral problems and inconsistencies along the application’s development process. The sepa-ration of this part from the logic one revealed to be essential. This way, it will not allow anycritical changes that can trigger serious faults on an application.

2.4. Web Frameworks 25

The ’views’ have as main goal the interface creation for the user’s interaction. Thiscomponent defines the way that information is shown to the user, whose definition comesfrom the MVC model. Through the views it is possible to make controlled changes over thecreated model, i.e., over the database. As mentioned before, although the data modificationis possible, that is not an operation executed with a high independence level due to the factthat the views are kept away from the models.

Through the inputs received, the ’controllers’ have the capability to allow the users tocommunicate with the model and return possible results by the defined views.

This is one of the design patterns with a high attendance in many web’s applications.

ASP.NET

ASP.NET is an open-source web development model and it is part of .NET framework,including its inherent services.

C# is used to develop the web’s application and benefits from type safety and inheritance,among others characteristics. For the visualisation’s purpose, HyperText Markup Language(HTML) 7, Cascading Style Sheets (CSS) 8 and JavaScript (JS) 9 were adopted [47] [48].

ASP.NET includes three types of web frameworks to build web applications: ASP.NETWeb Forms, ASP.NET MVC and ASP.NET Web Pages [47]. The choice must settle upon therequirements and the final result intended for the application.

The focus will be on the ASP.NET MVC considering MVC usage both by ASP.NET andDjango.

ASP.NET MVC

ASP.NET MVC follows patterns and principles based on “test-driven development, sep-aration of concerns, inversion of control and dependency injection” and it is proposed fordevelopers who look for a separation between the business logic and the presentation layer.

The concept of MVC is based on models, views and controllers and this separation canlead to a lower building complexity.

When compared to Web Forms, MVC has a better control over HTML and HTTP con-tents, enabling us to understand how the application works and what is its behaviour in theweb environment is [47].

Django

Django is a free and open-source web framework developed in Python, which follows thearchitecture Model-Template-View (MTV), originated from the MVC model.

This framework is known for having a lot of characteristics that facilitates the web’sdevelopment. Some of those attributes are defined as [49]:

• Speed - the design of Django was thought to build quick web applications withoutmany complications.

7HTML - standard markup language frequently used to build web pages and handle their visual aspect.8CSS - style sheet language used for describing the style used when elements are written using a markup

language, such as HTML.9JS - dynamic programming language used together with HTML and CSS to build web applications/pages.

It is used to provide an interactive side to the web pages.


• Fully loaded - has extras to help handle some essential tasks in web’s developmentlike user’s authentication, administration, maps, among others.

• Secure - guarantees a good level of security to avoid attacks as cross-site scripting andrequest forgery and SQL injection. The user’s authentication system ensures a securemanagement for user’s accounts and passwords.

• Scalable - can handle large data traffic quickly using the system’s flexibility.

• Versatile - several type of platforms can be developed using this framework.

These are the main points that characterize Django as a web framework.Django’s architecture is based on the MVC pattern, yet there are some changes to consider

and that should be emphasized.Django’s model is MTV, as seen in figure 2.14. This model has controllers being replaced

by templates.

Figure 2.14: Model-Template-View Architecture

The logic around the views and models are the same described before about MVC.Considering the templates, these allow the wanted appearance for the web’s application

pages that show the information hold by the database using views. The files used are usuallyHTML and describe the structure presented to the user. The place, where the informationshown is kept, can be previously defined. The templates make the communication with theviews and its result is placed in the template in a way to display the correct information.

According to Django’s conditions, the models do the interaction with the database usingPython,without the need to query execution. The views combine Python files that describethe way the information will be displayed and consequently communicate with the databaseand eventually with the templates.

2.5. Mobile Frameworks 27

2.5 Mobile Frameworks

Along this section some mobile frameworks were addressed and studied within the scopeof this dissertation. There is a performance and features analysis in order to realize whichthe best framework to fit with this work specifications is.

A mobile framework is a software developed to support mobile application’s developmentand plan to automate all the process providing means, including libraries, to achieve a betterand faster solution.

There are two types of mobile frameworks: native and cross-platform. Platforms such asAndroid, iOS and Windows Phone have their own features allowing access to specific hardwareand characteristics in the mobile phone. Each platform has a different way to handle its ownstructure and for its developers, it is a challenge to build applications that run in all platformsequally [50] [51].

Therefore, building an application using the native solution may not be the right approach.This would involve development of a different code for each platform, which is not efficientregarding costs and resources.

The solution found to outline this problem was the development of cross-platform appli-cations, that implies building an application consistent with most platforms. The code baseis the same for all the applications and according to the platform where it runs, the nativefeatures are applied without the developer’s effort [50].

Inside cross-platform frameworks there are four types to consider: web, hybrid, interpretedand cross compiled approaches.

Web approach is thought to execute the application in the web browser of the device andthe languages used are HTML, CSS and JS. Considering the browser based application, itwill be independent from the platform [50].

Hybrid is the balance between web and native platforms, where the development isachieved through web technologies. The result is executed inside a native container of themobile device. A browser is used to render and display the HTML pages and the mobiledevice runs an abstraction layer that allows the access to its capabilities as JS APIs [50].

An interpreted applications code is deployed on mobile device and interpreted thereafter,i.e., the interpreter executes the code during runtime. Native features are accessed throughan abstraction layer to get native APIs for further use [50].

Cross compiled platforms convert the source code into native binaries to a specific plat-form. Any language is supported, and as soon as the development finishes, the cross compilercompiles the code to native to be ready to run in different platforms [50].

Assuming the importance of having applications with the widest range of platforms andpeople possible, the frameworks studied were cross-platform.


2.5.1 Mobile Frameworks Analysis

The frameworks under study were Ionic and PhoneGap. The next paragraphs will thor-oughly explain the characteristics of each.

Ionic

Ionic is an open-source mobile framework used to build hybrid applications that will runas natives over the different operating systems.

Some characteristics of this framework go through free and open-source, fully cross-platform, which have native plugins and great support documentation.

Ionic is a project under Massachusetts Institute of Technology (MIT) available to all thecommunity. This framework allows development for several types of operating systems usingthe same code base, saving some hard work. The code used is based in HTML, CSS and JS.Ionic has native plugins such as Bluetooth or finger print authentication which is suitable foreach of the platforms it proposes to serve. There are also several examples, tutorials and fulldocumentation available about the Ionic way of working that will help in mobile development[52].

About performance, Ionic is known for having great performance power on the latestdevices, having “efficient hardware accelerated transitions and touch-optimized gestures” [52].

This framework combines the standard and features of native applications to the web’sflexibility. It also has a clean, simple and functional design as a benefit [52].

Currently, Ionic requires Angular JS to get a full advantage of its capabilities. This allowsus to have access to the user’s interface interactions, gestures, animations, among others.

PhoneGap

“PhoneGap is an open-source mobile development tool developed by Adobe System Inc.under Apache 2.0 license” [53]. This tool allows developers to build free applications with nolicenses needed.

One of the several advantages of this tool is the ability to build cross-platform applicationswith support for Android, iOS, Windows Phone, BlackBerry, Bada, Symbian and webOS [53].

The usage of PhoneGap brings the need to use more recent web programming languagessuch as HTML, CSS and JS allowing a cross programming instead of a native one, whichleads to an easy integration when we consider different operating systems [53]. This toolworks as a “wrapper” and that allows developers to include applications written in web tonative languages. The applications are written using the previously mentioned languages andthe code is built only once and is made available for all the accessible platforms.

PhoneGap includes several components and extensions to allow a better experience to thedevelopers. The outcome applications are called hybrid since they are structured using bothweb and native languages [53].

Among several other associated advantages, some of them are [54]:

• Cross-platform development - leads to a greater reach in terms of operating sys-tems. Building applications with native languages have many limitations considering,for example, the market commercialisation. Limiting an application to just one marketdecreases the population’s reach. But this is not the only advantage when talking about

2.5. Mobile Frameworks 29

cross-platform; the base code needs to be written just once and there is no concern aboutspecifications for each supported platform.

• Open source - this tool remains free and for that reason, accessible to a enormousnumber of developers. This huge community provides a big support.

• Native APIs - the development is done by using web languages, but this is not asynonym of resignation from native functionalities available in each device. Phone-Gap allows developers to access to native APIs like Global Positioning System (GPS),accelerometer, camera, among others.

• Rapid development - resulting in better applications. The development facility alliedto the web’s development skills ends in better and quicker applications results in happierclients.

Frameworks comparison

According to the analysis produced in “Comparative analysis of tools for development ofnative and hybrid mobile applications” [3], it is possible to counterbalance Ionic and Phone-Gap in some parameters such as supported platforms and operating systems, programminglanguages and complexity of installation or development.

Both frameworks are cross-platform and work with a hybrid approach and showed somesimilar characteristics related to the parameters mentioned before. These parameters arereferred to in table 2.2:

Ionic PhoneGap

Supported computer Windows, Linux, Windows, Mac OSXoperating systems Mac OSX

Supported mobile Android, iOS Android, iOS,platforms BlackBerry 10,

Windows and Windows Phone,Firefox OS, Ubuntu,

Tizen, Amazon Fire OS

Programming JavaScript JavaScriptlanguages

Official documentation and 5 5community (1-5)

Speed and complexity 5 5of installation (1-5)

Complexity of 5 5development (1-5)

Table 2.2: Mobile cross-platforms comparison [3]


PhoneGap does not support Linux as operating system but has the others in commonto Ionic. According to supported platforms, Ionic is limited only to Android and iOS whilePhoneGap allows a lot of other platforms like BlackBerry or Windows Phone.

The three last parameters are classified in a 1 to 5 scale, and both frameworks are rated asa 5 in all of them. Official documentation and community categorized with a 5 rate means thesupport is clear, detailed and easy to find and understand, which help newcomers and evenmore experienced developers to find answers for the existing questions. Speed and complexityof installation with a 5 rate, shows these tasks are easy and do not take much time. Finally,the development complexity is also rated with 5, showing the frameworks are intuitive andthe languages used are straightforward [3].

2.6. Hardware 31

2.6 Hardware

To achieve the desired goal with this dissertation some hardware was necessary. Sensorsand a computer to connect them were the main requirements for this work.

The computer used was a Raspberry Pi and the sensors applied were for temperature,humidity and brightness measurement.

An Arduino and a RF module were used to obtain the communication between the sensorsand the system.

This was the available hardware and it will be described in the next subsections.

2.6.1 Raspberry Pi

Raspberry Pi (RPi) is a small low cost high performance single-board computer developedby Raspberry Pi Foundation in United Kingdom [55]. The main objective of this product wasto encourage computer science teaching in schools, but it quickly proved to be interesting inother areas.

Figure 2.15: Raspberry Pi 3 Model B [55]

The newest version, Raspberry Pi v3 Model B (figure 2.15), was used in this dissertationwith Raspbian as operative system. It has the following specifications [55]:

• Quad Core 1.2GHz Broadcom BCM2837 64bit Central Processing Unit (CPU)

• BCM43438 Wireless Local Area Network (WLAN) and BLE on board

• 1GB Random Access Memory (RAM)

• 40-pin extended General-Purpose Input/Output (GPIO)

• 4 Universal Serial Bus (USB) 2 ports

• 4 Pole stereo output and composite video port

• Full size High-Definition Multimedia Interface (HDMI)

• Camera Serial Interface (CSI) camera port for connecting a RPi camera


• Display Serial Interface (DSI) display port for connecting a RPi touchscreen display

• Micro Secure Digital Card (SD) port for loading operating system and storing data

• Upgraded switched Micro USB power source up to 2.5A (Amps).

Camera Module v2

“The Raspberry Pi Camera Module version 2 (figure 2.16) has a Sony IMX219 8-megapixelsensor” [55]. This camera is used both for high-definition video or photography .

It has a better image quality than the earlier model, “colour fidelity and low-light perfor-mance”. It supports 1080p definition with 30 frames per second and 720p with 60 frames persecond [55].

Figure 2.16: Camera Module v2 [55]

The camera can be accessed by an existent API and by using the Picamera Python library.

It is known for capturing wildlife and home security and in this context it is used tocapture video streaming from the aquarium during daylight hours.

Camera Module NoIR v2

“The infrared Camera Module version 2 (Pi NoIR - No Infrared) (figure 2.17) has a SonyIMX219 8-megapixel sensor” [55]. This camera is used both for high-definition video andphotography but does not use the infrared filter. This kind of camera is useful for recordingdark environments.

Figure 2.17: Camera Module Noir v2 [55]

The camera can be accessed by an existent API and by using the Picamera Python library.

2.6. Hardware 33

It is known for capturing nocturnal wildlife in order to be able to intercept the animalbehaviour. In this context it is used to capture video streaming from the aquarium duringthe night.

2.6.2 Arduino

“Arduino (figure 2.18) is an open-source electronics platform based on easy-to-use hard-ware and software”. This board was created at the Ivrea Interaction Design Institute consid-ering the students with no knowledge in electronics [56].

Over time, the Arduino concept has grown and the board was adapted to support new fea-tures and be able to deal with different kind of scenarios such as “IoT applications, wearable,3D printing, and embedded environments” [56].

This product is open-source which encourages people to use it according to their needs.Some of the specifications of this board are [56]:

• Microcontroller - ATmega328

• Electrically Erasable Programmable Read-Only Memory (EEPROM) - 1 KB

• Flash Memory - 32 KB of which 2 KB used by bootloader

• Architecture - AVR

• Operating Voltage - 5 Volts

• Power Consumption - 19 mA (miliAmps)

Figure 2.18: Arduino Nano [56]

2.6.3 Radio Frequency Module

HC-12 Module (figure 2.19) is a RF module used to wireless serial port communication.This module is known for having a long distance transmission reaching to 1000 meters in

open space and with a baud rate in the air of 5000 bps [57].The frequency range is 433.4 to 473.0 MHz and allows multiple channels configuration (up

to 100 channels). The maximum transmission power is 100 mW [57].


Figure 2.19: Radio Frequency Module HC-12 [57]

2.6.4 Sensors

A set of sensors were initially predicted for this dissertation, however they were not avail-able during the development of the system.

Sensors like Waspmote Smart Water Kit, water conductivity, pH and conductivity cali-bration kits, ORP sensor and calibration solutions for DO and ORP were part of this set.

These sensors and solutions were not accessible and in order to work around this situation,other sensors, which will be presented below, were made available by the department.

Temperature and Humidity

The sensor responsible for measuring the environment’s temperature and humidity si-multaneously was a RHT03. This is a low cost calibrated sensor and does not need extracomponents to obtain the values measured [58].

Figure 2.20: RHT03 Temperature and Humidity Sensor [58]

Figure 2.20 shows the sensor under discussion. Some of its features are [58]:

• 3.3-6V Input

• 1-1.5mA measuring current

• 40-50 uA standby current

• Humidity from 0-100% RH

2.6. Hardware 35

• -40 to 80 degrees C temperature range

• +-2% RH accuracy

• +-0.5 degrees C.

Brightness

The sensor responsible for controlling the brightness is a mini photocell. This type ofsensor changes resistance depending on the quantity of light present [59].

Figure 2.21 shows the sensor under discussion. Some of its features are [59]:

• Light resistance: 1k Ohm

• Dark resistance: 10k Ohm

• Maximum voltages: 150V

• Maximum power: 100mW

• Dimensions: 2 x 4 x 5mm

• Dimensions: 4mm between pins

• Dimensions: 31mm lead length.

Figure 2.21: Mini Photocell Sensor [59]


2.7 Web services

A web service is a software planned to support interaction between machines over a net-work. The HTTP is used for communication and file transfer between machines. It usesformats like XML or JSON.

There are two main types of web services: Simple Object Access Protocol (SOAP) andRESTful.

SOAP is a protocol specification designed to exchange information between machines overa network. This protocol is based on messages composed by envelope, header and body [60].The documents used are defined using XML.

The protocol is divided in three interconnecting parts represented by an envelope, a set ofrules and a convention. The envelope defines the framework to describe what is in a messageand how to process it. The set of encoding rules is to “express instances of application-defineddatatypes”. The convention aims to represent remote procedure calls and responses [61].

REST is a way to provide communication between machines over the Internet. Thismethod has a client-server architecture, where the client sends the request to server and ithandles the request and obtains a response in return. This response is built considering“transfer of representation of resources” [60].

A resource is identified by URI and uses nouns and verbs instead of a message structure,like SOAP. Taking this into account, XML is not needed and that leads to less bandwidthuse [60].

Every request is independent both from the previous and the following ones, i.e., datarequired in each request is not kept on the server’s side. That makes REST simpler andlightweight [60].

In order to achieve the required information, methods like GET, PUT, POST andDELETE over HTTP are used to retrieve, create, update and delete data [60].

2.8 Web servers

A web server is a program that uses HTTP to process requests in order to serve files, tobuild and publish web pages for the final users.

The choice of a web server should be based on the working mode according to the operatingsystem and its ability to handle server-side programming and security.

Two of the main web servers that have higher recognition are Apache and Nginx.Apache, also known as Apache HTTP Server, is a web server software that is free and

open-source, and was released under the leadership of Apache License 2.0. The main goal ofApache is to have a “secure, efficient and extensible server running over HTTP standards”[62].

The Apache web server has many features and advantages that may be considered [63]:

• is a powerful, flexible, HTTP/1.1 compliant web server

• implements the latest protocols, including HTTP/1.1 (RFC2616)

• is configurable and extensible to other modules

• runs over several operating systems

• has a large support community.

2.9. WSGI servers 37

On the other hand, there is Nginx, that is constantly rising. Nginx is an open-sourcefree high performance HTTP server. The main characteristics of this web server undergoesthrough its simple configuration, low resource consumption, high performance and stability[64].

2.9 WSGI servers

Web Server Gateway Interface (WSGI) consists on a description of how the communicationof a web server and a web application work.

As the traditional web server has not the accurate tools to run Python code, the WSGIis needed in order to facilitate the previous mentioned integration. The main goal providesa simple but complete interface, capable of supporting all interactions between a web serverand a web application.

This WSGI server is a standard for Python’s web applications and is detailed describedin PEP 3333 [65].

Two advantages of the use of WSGI are its flexibility and scalability. The first advantageits an uncomplicated form to change from a specific WSGI to another without modifying theapplication or framework that implements WSGI. According PEP 333 [65]: “The availabilityand widespread use of such an API in web servers for Python [...] would separate choice offramework from choice of web server, freeing users to choose a pairing that suits them, whilefreeing framework and server developers to focus on their preferred area of specialisation”.

The second advantage, i.e. scalability, is handled by WSGI servers considering their largecapacity to support a huge number of requests for dynamic content at the same time [65].

There are two WSGI considered: Gunicorn and mod wsgi.Gunicorn is strongly advised to be used together with a Nginx web server. This server is

consistent with several web frameworks, it is of easy implementation, with a significant speedand light on server resources [66].

Gunicorn is generally used behind a HTTP proxy server, which is recommended to be theNginx. This will work as reverse proxy server to a Gunicorn server running in localhost port8000.

While a proxy is an intermediary server that handles requests from clients to differentservers across the Internet, a reverse proxy is kept “behind firewall of a private network anddirects client’s requests to the appropriate backend server”. This type of proxy provides a“smooth flow of network traffic between clients and servers through an extra control andabstraction level” [67].

Beyond the extra level mentioned before, a reverse proxy also provides load balancing -by distributing requests for several servers in order to keep the speed and capacity withoutaffecting the system’s performance; web acceleration - by compressing inbound and outbounddata; security and anonymity - acting as an extra defence method against security attacks[67].


Figures 2.22 and 2.23 show the differences between both servers.

Figure 2.22: Proxy server

Figure 2.23: Reverse proxy server

The recommendation on Nginx used along with Gunicorn is based on the requirement ofa proxy server which “make sure that it buffers slow clients when are used default Gunicornworkers. Without this buffering, Gunicorn will be sensitive to denial-of-service attacks” [68].

Figure 2.24 shows an example of the beginning of the Gunicorn with Nginx usage.

Figure 2.24: Gunicorn used along with Nginx [66]

3

Requirements and System Design

The current chapter presents the functional and technical design of the proposed solution.

The use cases, functional and non-functional requirements and several diagrams, includ-ing architecture diagram, are presented and described in order to understand the problem’smodulation.

3.1 Functional Design

This section describes the functional design of the proposed solution to combine the inter-action with all the processing between sensors and user’s applications. Along this section, thefeatures of the system are explained using functional and non-functional requirements anduse cases.

3.1.1 Functional Requirements

Functional requirements are based in criteria that should be followed to evaluate specificbehaviour or functions of the system to solve a problem. These requirements can be allocatedin several classes [69] as:

• Data requirements - describes how information is stored and administrated by the ap-plication; these type of requirements include conceptual, content and storage functions.

• Interface requirements - explains how the user is going to interact with the application.

• Navigational requirements - describes the users’ navigation over the application.

• Personalisation requirements - explains how the application responds according to theuser’s profile.

• Transactional requirements - describes what operations are done internally by the ap-plication using some abstraction concerning interface and interaction operations.

39

40 Chapter 3. Requirements and System Design

Taking into consideration the earlier functional requirements’ division, those fitting in thedeveloped web application were:

• The system’s interface should allow the user to log into the system as anadministrator or a regular user. The common user can access main data presentin the platform yet it is unable to perform any changes, otherwise the system’s admin-istrator has access to the entire platform and is able to add sensors, change alerts andcontrol the regular users.

• The system’s interface should allow the user to log out of the system. Besidesallowing the user to login, the logout option is also made available once he has performedall the intended actions over the platform.

• The system’s interface should allow the user to see the last values read byeach sensor. The system displays a page with the last values read by each existentsensor so that the user could be able to control the aquarium’s values.

• The system’s interface should allow the user to see the last alarms detectedby each sensor. When unusual values are read, the system is responsible for addingthose records as alerts to the database and the interface will show the last alarms of thesensors.

• The system’s interface should allow the user to see the list of all alarmsdetected. For a better comparison between the current and the previous alarms, a listof all alarms registered is displayed.

• The system’s interface should allow the user to check an alarm as seen. Assoon as the user (administrator) is able to solve the alarm, he/she can check the alarmas seen and this is archived and removed from the interface.

• The system’s interface should allow the user to see the list of available sen-sors. The user can see the sensors connected and their type in order to have a broadview of the working system.

• The system’s interface should allow the user to see the values’ history relatedto each one of the sensors along the time. In a more graphical way, values readalong the time are displayed over a line chart with possible interaction with them.

• The system’s interface should allow the user to watch live stream from theaquarium. For a visual control of the aquarium, cameras were installed with a livestream running, making it possible to watch this stream on the platform.

• The system’s interface should allow the user to download an Excel sheet withalarms presented on the platform. For archiving purposes or simply to obtain adifferent analysis, the user can download the alerts’ list on an Excel sheet form.

• The system’s interface should allow the administrator to add new sensorsor remove them. Only the administrator is able to execute functions outside thevisualisation field such as adding or removing a sensor.

3.1. Functional Design 41

• The system’s interface should allow the administrator to replace the values’range for alerts. There is a fixed range of values assigned for each sensor and theadministrator, according to his knowledge and duty, is allowed to change those intervalsof values, so they can fit according to the external conditions.

• The system should allow an administrator to add new users. To guarantee thesystem is used by authorised users, only the administrator is able to add new ones.

• The system should allow an administrator to remove users. To guarantee thesystem is used by authorised users, only the administrator is able to remove existingones.

Considering the mobile application and its visualisation’s purpose, the functional require-ments followed were:

• The system’s interface should allow the user to log into the system as anadministrator or a regular user. The common user and administrator can accessmain data present in the platform, however they are unable to perform any changes.

• The system’s interface should allow the user to log out of the system. Besidesallowing the user to login, the logout option is also made available once he has performedall the intended actions over the platform.

• The system’s interface should allow the user to see the last values read byeach sensor. The system displays a page with the last values read by each existentsensor so that the user could be able to control the aquarium’s values.

• The system’s interface should allow the user to see the last alarms detectedby each sensor. When unusual values are read, the system is responsible for addingthose records as alerts to the database and the interface will show each sensor’s lastalarms.

• The system’s interface should allow the user to see the list of all alarmsdetected. In order to allow a better comparison between the current and the previousalarms, a list of all alarms registered is displayed.

• The system’s interface should allow the user to see the list of available sen-sors. The user can see the sensors connected and their type in order to have a broadview of the working system.

• The system’s interface should allow the user to see the values’ history relatedto each one of the sensors of the current day. Values read along the day aregraphically displayed over a line chart with possible interaction with them.

• The system’s interface should allow the user to watch live stream from theaquarium. For a visual control of the aquarium, cameras were installed with a livestream running, making it possible to watch this stream on the platform.


3.1.2 Non-Functional Requirements

Non-functional requirements are not concerned about system’s functionalities but withcriteria to evaluate the operation of the system. They usually consider reuse, usability, avail-ability and performance requirements, among others.

In this dissertation context, the non-functional requirements revealed were:

• The data’s access through the application should be almost immediate. Thedata showed to the user must be displayed in a few seconds, so that the applicationcould be considered to provide a good response time. They are both available for weband mobile applications.

• The application should be intuitive for an efficient use. Exploring through theseveral pages of the application must be intuitive to grant the user a better experience.They are both available for web and mobile applications.

• The application should be flexible and scalable. This implies that the applicationmust support new integrations as adding new sensors and actuators and portrait thecapability to handle these changes.

• The application should allow different users to access at the same time andobtain the same information. Several users will have access to the same dataeven in different accesses. Unlike common users, the administrator has access to extrafunctionalities (only featured on the web application).

3.1.3 Use Cases Diagram

In order to produce a better understanding of system’s features two use cases diagramsare presented in figure 3.1 and figure 3.2 which reveal the main functions of web and mobileplatforms, respectively.

Considering that this platform was build for aquarium’s handlers, the users defined werethe usual user, with access to the data, and the administrator, who will access all the imple-mented features.

Login/Logout

The user can login by entering his email and password. An authentication is consideredsuccessfully when the combination of both inputs matches, giving the user access to theplatform.

The logout is then allowed. A Login is always required in case of a repeated access.This feature is available on the web and mobile platforms.

Read last sensors values

The user can access the last values read by each sensor on the web’s front page. Thevalues are displayed in boxes with the value read by the sensor and its identification as wellas the date associated with each reading.


This feature is available on the web and mobile platforms.

Read last detected alarms

The user can access the last alarms detected on the web’s front page. Those values displaythe last data associated to each sensor, which slips from the range assigned for them, i.e., ifthe value is above or below the pre-defined value for that sensor, it will be displayed in thealarms section.


Figure 3.1: Web Platform Use Cases Diagram

Access to sensors’ values history

The user can access full information related to measures made for each sensor over time.Records read are saved and displayed on the statistics’ page through line charts. Thesegraphics show all the history related to values read by each sensor and allow the user tounderstand the several changes which occurred since the beginning of the measurements untilthe current date.

This feature is available on the web platform.

Access to sensors’ daily history


The user can access full information related to measures made for each sensor consideringthe current day. Records read are saved and displayed on the statistics’ page through linecharts. This graphics show all the history related to values read by each sensor and allow theuser to understand the several changes which occurred since the beginning until the end ofthe day.

Showing the entire values would become difficult for visualisation’s purpose taking intoaccount the amount of existing data.

This feature is available on the mobile platform.

Access to alarms’ list

The user can access all alarms detected by each sensor. In the ’Alarms’ section, a listof alarms with related relevant information as date, sensor, value read and minimum andmaximum values admitted is showed.


Figure 3.2: Mobile Platform Use Cases Diagram

Check an alarm as seen

The user (administrator) can choose an option to declare the alarm as seen and this way itwill be removed from the list of alarms detected. This option is useful when the user alreadysolved the alarm in question and does not want it in the list of relevant alarms.

This feature is available on the web platform only.

Export alarms list to Excel sheet

For a more careful analysis, the user can download a list of detected alarms. The list ofalarms displayed on the web page is written in an Excel sheet where the important fields’


names are defined as columns and the read values as rows. This can be useful for futurereports of the aquarium’s maintenance.

This feature is available on the web platform only.

Access to aquarium live stream

The user can access the cameras connected to the aquarium to see the current state ofspecies living on it. The live video stream is transmitted to Youtube and can be accessedthrough the ’Gallery’ page.

This sort of monitoring complements the quantitative type that considers the values as-sociated with the state of water in the aquarium in a more visual and less technical method.


Access list of sensors

The user has access to the detailed sensors’ list which includes sensor’s name and minimumand maximum value accepted for that sensor. This allows the user to attain information aboutthe sensors in use.

This feature is available on the web and mobile platform.

Add sensor

The user (administrator) can add a sensor to the list of sensors in use. Therefore, a nameand type is assigned to the sensor, which is intended to be added.


Delete sensor

The user (administrator) can delete a sensor from the list of sensors. The removal of asensor can lead to loss of information. As it is known, that is not adequate to an informationsystem. As a result, the sensor is removed from the list of sensors when deleted, yet not fromthe database.

The ’deleted’ sensor is considered as inactive in the database and data related to it is keptfor a possible future use.


Edit alarm values range

The user (administrator) can change the range of values assigned to each sensor type.This gives the aquarium’s handler the opportunity to settle down the values according toyear seasons, so he/she can have a better control over the environment.



3.2 Adopted Technologies

Considering all the technologies and frameworks studied on chapter 2, some decisionsneeded to be taken to accomplish the objectives and requirements of this dissertation.

The data collected was viable through the appliance of the accessible hardware that in-cluded a RPi, RPi cameras, RF modules, one of them connected to the RPi and the otherembedded with an Arduino and the sensors (temperature, brightness and humidity) in abreadboard.

After the data collected and received in the RPi, it must proceed, using a data protocoluntil all data reaches the system and is able to be used for analysis.

The introduced data protocols were MQTT, CoAP, AMQP and XMPP. All of them areapplied in scenarios of IoT, yet MQTT and CoAP are the most commonly used [70] concerningconstrained devices.

According to the comparison, MQTT and CoAP are both lightweight, but the MQTT wasthe protocol chosen considering its publish-subscribe model. This model brings advantagesover other approaches in applications like this one. This way, devices can subscribe differenttopics receiving information that is shared between multiple devices.

Compared to the other three technologies related, MQTT has a simpler architecture andfor that reason it was the protocol used for this IoT application.

After the communication between the sensors and the system, the data must be saved forfurther usage. This is achieved through the data preservation on a database.

The databases shown were MySQL, MongoDB and PostgreSQL. PostgreSQL was chosenand the main reason for it, was the support from Django. According to [49], Django is notprepared to support NoSQL, also known as non-relational databases. On the other hand,Django is prepared to handle PostgreSQL databases more easily than other databases.

Taking into account the platforms development, some web and mobile frameworks wereanalysed. Flask, ASP.NET and Django were the web frameworks considered. To the mobileapplication, the frameworks studied were Ionic and PhoneGap.

Among the described technologies, Django was the elected framework to develop the web’splatform along this dissertation.

Its use by the several developers, the many facilities provided by the framework, the largecommunity support and the architecture followed, proved to be the best mean for the finalsoftware.

With a global vision over the two mobile frameworks and considering that both havecharacteristics alike, the option for this dissertation fell on the one that showed a higherrange of supported platforms, getting to a higher number of users. PhoneGap filled thisrequirement and therefore was the chosen framework.

The demand in have some retrieved information related to the system to produce itsimproved usage, introduced the SOAP and the RESTful web services.

According to the literature [60], in terms of response time and message size, it is provedthat REST services have a better performance over SOAP. Considering this information,RESTful services were chosen to develop the API service.

Considering now the web servers to support the deployment of the web’s platform, Nginxand Apache were evaluated.

Over time, Nginx has gained ground contrasting with Apache. Considering some marketshares [71] [72], it is possible to verify the growth of Nginx’s use. Apache is still the main

3.2. Adopted Technologies 47

web server used and it has several advantages yet these are being achieved by other type ofweb servers, namely Nginx.

Considering Nginx as the ascending technology and its nearness to Apache’s features, theNginx was the selected web server.

Finally, along with the web’s server, a WSGI server is also a requirement. Gunicorn andmod wsgi were the WSGI servers under study, bearing in mind that they are directly relatedto Nginx and Apache web servers, respectively.

Considering the Apache web server, the option recommended is mod wsgi. This is apackage that provides an Apache module that implements a WSGI compliant interface forhosting Python’s web applications over Apache server [73].

Despite that, and considering Nginx as the web server chosen, the WSGI server handledwas Gunicorn which is advised to be used along with Nginx.


3.3 Techinal Design

This section describes the technical design of the solution proposed to combine the in-teraction and all the processing between sensors and user applications. The components ofthe system are explained for a better perception of the technologies used and the featuresimplemented.

3.3.1 Architecture Definition

Considering the technologies studied and referred to on the second chapter and the onesthat have been chosen, figure 3.3 shows the general architecture for the entire project devel-oped during this dissertation.

Figure 3.3: Architecture Diagram

For a better understanding and contextualisation of the adopted solution, this architecturewas divided in four layers.

It all starts with the data collected from the sensors. The sensors used were those thatwere available and consisted in temperature, humidity and brightness. The values gathered

3.3. Techinal Design 49

from them were sent to the RPi through a radio frequency module.

As soon as the RPi receives the values, it works both as MQTT client and broker. Theclient sends values received using JSON format to a predefined topic in the broker.

All the data is needed on the server’s side, so the input published by the MQTT clienthas to be consumed by a subscriber in order to collect all the information to portrait later.Taking this scenario into account, the server has to behave as a subscriber of the topic wherethe information is published, in order to access to it. To achieve this connection betweenMQTT broker and the server, i.e., for the broker to be able to connect the subscriber to sendthe information published on the topic under discussion, Node-RED was used for an easierconnection using the abstraction allowed by this tool.

Node-RED runs over RPi and does the connection between the broker and the subscriberand the information needed arrives to the server (subscriber). At this stage, the values readby the sensors are on the server’s side and can be saved to the PostgreSQL existing databasefor further use on web and mobile applications.

The deployment of web platform was made in the server and for that to happen, a NGINXweb server was installed in order to handle all the operations of the platform. Besides theweb server, a Python WSGI HTTP server called Gunicorn, was also installed to support thepython code in which the application was written.

The previous steps were the main actions to deploy and to be able to run successfullyon the web’s application. This application was developed using the Django framework thatuses Python as language. Django is based on the MTV model and for the graphical interfaceHTML, CSS and JS was used.

The mobile application was build using PhoneGap framework that allows a cross-platformdevelopment. This framework shares the HTML, CSS and JS technologies used for the web’sapplication.

Simultaneously with the web’s application, a Django REST API was developed to givesupport to the mobile application, providing all the required information to display to theapplication’s user.

3.3.2 Database Diagram

Considering the need to control both sensors and actuators it is important to do a clearseparation of both elements in the database model.

The main difference between these two components is the type of function. While a sensoris used only to monitor the scenario in question, an actuator intends to react according tosome rules defined by the administrator.

In this specific context, an actuator will act when some of the aquarium’s values measuredare lower or higher than the pre-established range of values to the parameter under study.This remote control can make a difference when considering living beings since a late responsecan lead to death.

In figure 3.4 there is a representation of the data model used in this dissertation.

The model has several blocks but the main structure is presented on tables like ’Sensor’,’Actuator’, ’Value’ and ’Alarm’. When this is defined, there are other tables that complementthe previously mentioned by adding some connections for a better description in order to savethem for further usage.


The sensors are defined by an ID, name, ID for an eventual alarm and also an ID of thesensor type.

Actuators are defined by an ID, name, an ID for the actuator type and also a state, sothat we can realize if the actuator is active or not.

When values are read, they are inserted on ’Value’ table to be kept. On the ’Alarm’ tablea few range of values are defined for each sensor and when a value is above or below thepre-defined selection, there is a new insertion on another table called ’Detected Alarms’ thatconsiders the unusual values read by the sensors.

For this to happen, a trigger was inserted in the database to process the irregular valuesand add them to the ’Detected Alarm’ table. This trigger is represented in the appendix byfigure A.1 and A.2.

Figure 3.4: Database’s Diagram

4

Implementation

On the previous chapter, the architecture and model design for this solution was pre-sented and the main components and technologies used were illustrated . Moreover, the mainfunctionalities of the system were described through a thorough analysis of the use cases.

The current section will report the implementation steps and the application of the meth-ods adopted and described in chapter 3.

4.1 Overview

The implementation of this solution was divided in two phases. The first one consisted inweb’s application development that involved data sensors collection, database managementand front-end development in order to exemplify all data necessary for the aquarium’s controlto the user.

A system for visualisation’s control over the aquarium was also implemented and it isincluded on web and mobile applications.

The mobile application was the second phase and its development included just visualisa-tion features. An API was created to make GET requests for usage on the mobile application.

The steps to achieve the final solution are described in the following sections.

4.2 Aquarium Disclosure

This aquarium is placed in Ecomare and one of the objectives was its disclosure for thegeneral public. This was obtained through the implementation of a system with cameras toallow the aquarium’s display on the Internet.

The main publishing platform used was Youtube, by using its option for live video stream-ing.

The hardware used was the RPi Camera Module v2 and the RPi infrared Camera Modulev2 (also known as Pi NoIR - No Infrared) connected to a RPi. The first camera is used fordisplaying image during the day while the second is suitable for pictures captured during thenight. Both cameras take into account the lighting conditions.

After using

51

52 Chapter 4. Implementation

$ sudo rasp i−c o n f i g ,

the RPi camera is able to start and ready to capture pictures or video. This can be doneby using the following lines respectively,:

$ r a s p i s t i l l −v −o imageName . jpg$ r a s p i s t i l l −o imageName . jpg$ r a s p i v i d −o videoName . h264 −t 10000

The first and second line are the commands to take pictures. The raspistill command isused for capturing still pictures with the camera. The raspivid command on the third lineis the tool for capturing video.

In all the commands, the option -o specifies the output filename and if it is non-existent,the file will not be saved.

The -v option is for verbose and it is used to get information while the command isrunning.

Considering the video capture, one of the options used is -t followed by a number thatrepresents the timeout, i.e., the length of time the camera is recording. In this case it wasrepresented as 10000 milliseconds (10 seconds); if this value is not passed as argument, thedefault time is 5 seconds.

Codecs, compression technologies that encode (to compress files) and decode (to decom-press files), are used for data, audio, still images and video. In this case, the still image usedjpg and for video, h.264 , but other types could have been used.

These are just a few options from the many available for these commands. They can befound in [74].

So as to obtain the live video streaming for Youtube, installing in RPi, a free software thatproduces libraries and programs for handling multimedia data, in this case, video streaming,was the next step.

This framework allows encode/decode and stream, among others. It runs over severalsystems and it was the solution adopted for this work.

To record the video and display it on the Youtube page created for that same effect, thefollowing command was used:

$ r a s p i v i d −o − −t 0 −vf −hf −f p s 30 −b 6000000 | f fmpeg−re −ar 44100 −ac 2 −acodec pcm s16le −f s 1 6 l e −ac 2 − i/dev/ zero −f h264 − i − −vcodec copy −acodec aac −ab 128k−g 50 − s t r i c t exper imenta l −f f l vrtmp :// a . rtmp . youtube . com/ l i v e 2 / [ channel−s e c r e t−key−here ]

The next lines explain the several options included in this command to achieve the finalresult [74] [75].

raspivid

-o -: as the output filename is not specified and the option is followed by a ’-’, the videodata is saved to stdout to get piped into ffmpeg.

-t 0 : recording until the program stopped manually.

4.2. Aquarium Disclosure 53

-vf -hf : flips the image horizontally and vertically.-fps 30 : sets frames per second to 30.-b 6000000 : output bit rate limit to 600 kbps; for Youtube it is recommended 400 to

600 kbps.By not using -w and -h in raspivid , the resolution is full 1920x1080 High Definition

(HD).

ffmpeg

-re : informs the ffmpeg to slow down the input reading to the native frame rate of theinput.

-ar 44100 -ac 2 -acodec pcm s16le -f s16le -ac 2 -i /dev/zero and -acodecaac -ab 128k and -strict experimental : adds a dummy audio channel filled with zerodata because Youtube rejects streams without an audio channel.

-g 50 : adds a keyframe every 50 frames.-f h264 and -f flv : tells ffmpeg it is receiving h.264 input and that should mux it into

video format flv (Flash Video) ouput.

The protocol used by Youtube to receive stream is Real-Time Messaging Protocol (RTMP).RTMP is a protocol for streaming media (data, audio and video) over the Internet betweena Flash player and a server [76]. This protocol has several variations but the one used byYoutube is based on the plain protocol that works over TCP and uses 1935 as default port.

The stream Uniform Resource Locator (URL) from the channel, like this,rtmp://a.rtmp.youtube.com/live2/ is found in settings, as well as the secret key thatmust be used to enable the URL and consequently, the live streaming to the channel.

After all the previous steps, the camera is ready to record and to send the video directlyto Youtube channel. This live video streaming is also incorporated in one of the web andmobile’s platform pages.


4.3 Web Application

This web application aims to present the data collected from each sensor, considering notonly the values classified as normal, but also values, which are outside a previously definedrange, and which are not considered acceptable.

Despite that, this platform also gathers the information received from the sensors anddraws graphics for the user to display in order to have an easier view of the data over time.

The platform also has a page that includes the live video streaming of the aquarium as apromotion of Ecomare.

4.3.1 Sensors Communication

Initially, the sensors idealized for this dissertation were Waspmote Smart Water Kit anda few other including oxidation reduction potential and water conductivity. These sensorswere not available in scheduled time, so the sensors used for the implementation were theones available in the department.

The sensors employed were from temperature, humidity and brightness. These sensorswere provided already connected in a breadboard with an Arduino and the code required togather the read values.

A RF module both placed in breadboard and in the RPi was used for the communicationbetween the sensors and the RPi.

The RPi runs a script to receive the data from the Arduino and the values collected willbe accepted in a scale from zero to one hundred percent (0%-100%).

When the values arrived at the RPi, it applies the MQTT protocol to communicate withthe server and be able to save the read values to the database for further visualisation in thedashboard.

In this scenario, RPi function is to act both like MQTT client and broker. The clientcreates a specific topic to publish the information that arrives from sensors and consequently,acts like the broker which handles the communication between publishers and subscribers.The broker is responsible for receiving the information from the client and send it to thetopic’s subscribers.

The responsible for the communication between the broker and the subscriber, in thiscase the server, where the web application and database were running, was Node-RED. Thistool is a wrapper of the complexity around the connection between the two entities. Theconfiguration of both entities (IP address and port) are needed as well as the topic in use sothat it is able to communicate.

Meanwhile, on the server’s side, another script is running where the data is collected andsaved onto the database. The web’s application accesses the database along the time and newinformation present in the database is shown on the dashboard pages, where the user has thepossibility to control the incoming data from the sensors.

The two essential points to retain when we talk about sensors’ communication is the typeof communication used, RF, and the plan followed to make the data reach its destination,i.e., the server and consequently, the database.

4.3. Web Application 55

4.3.2 Application Programming Interface (API)

An API was built to support GET requests for further use on mobile application.

The web service chosen was REST and the framework used to its implementation wasDjango REST framework.

When a user wants to access specific information, a GET request is sent from the HTTP’sclient with the information required in the URI, as seen in figure 4.1.

Figure 4.1: API example for GET requests

The request arrives to the web server that manages it so the information can be gatheredfrom tables’ content. If data required exists, then it is sent back through the web server untilit arrives to the client, complying JSON format (but it can also be represented by XML). Italso sends a HTTP 200 OK message to confirm the correct request. In case of error, a HTTPstatus correspondent to the problem found is raised. In case of a bad request, the messagesent is HTTP 400 BAD REQUEST.

Figure 4.2: API - Values read from sensors


In figure 4.2, the response to a GET request with values from all sensors follows the JSONstructure seen. In this response, we see one of the returned objects (figure 4.2, right side)that includes the record ID, read value and associated date, and consequently the informationrelated to the sensor in study such as type, name, minimum and maximum values related.

Figure 4.3: API - Existing sensors

Figure 4.4: API - Detected alarms

In figures 4.3 and 4.4 other requests are shown, such as in this particular case, the listof existent sensors and the detected alarms. This is used forward in mobile application forvisualisation’s purpose.

A more specific request made by sensor type or date is allowed too. The web serveraccesses the database and executes a particular query where the clause ’WHERE’ or ’LIKE’can be presented and the result is returned to the client.


When the URI contains ’api/temperature’, similiar to the one shown in figure 4.5, a queryis executed considering the type of sensor, i.e., temperature, and the returned results onlyhave the values associated with temperature sensors. The same happens when we search fora specific date, where the values returned are a combination of values registered in the datareferred to in the request.

Figure 4.5: API - Values read from temperature sensor

4.3.3 Interface

The web’s application interface can be split in five main sections: dashboard, statistics,alerts, gallery and settings.

Figure 4.6: Dashboard page - Last alarms

To provide an easier interaction on the user’s side, the most important information is im-mediately presented after the user executes the login on the platform. This page is defined asdashboard and contains at first sight the last alarms (figure 4.6) registered into the database.


These alarms refer to the last irregular values read by the sensors. As mentioned onchapter 3, each sensor has a range of values associated and when the recorded value exits thisinterval, an alarm is triggered. The last alarms detected by each sensor are presented in thedashboard frontline, so the aquarium handler can act quickly in case it is necessary. Fromthe alarms’ section, it is possible to access the alarms’ page, referred to below.

Figure 4.7: Dashboard page - Last sensor values

Figure 4.8: Dashboard page - Last sensor values

This page also contains the last values read by each sensor, its type and the date of datacollection (figures 4.7 and 4.8).

Statistics are divided according to the available type of sensors. For this dissertation, therewere considered five types of sensors: temperature (figure 4.9), pH (figure 4.10), salinity,


dissolved oxygen and oxidation reduction potential. The previous sensors, according to lit-erature [5], were defined as the main parameters to measure when talking about aquarium’swater control. Like it was described in subsection 4.3.1, the sensors used do not support allthese parameters and some of the values showed on the platform were random data.

Figure 4.9: Statistics page - Temperature

In each one of these pages a graphic of all data collected along the time for each type ofsensor is shown. There are options available to allow access to daily (figure 4.12) or monthlydata. The graphics have zoom option (figure 4.11). Besides that, a monthly average graphic(figure 4.13) is also presented in order to allow an average values’ comparison of each sensor.

Figure 4.10: Statistics page - pH


Figure 4.11: Statistics page - Temperature graphic with zoom

Figure 4.12: Statistics page - Daily Temperature

Figure 4.13: Statistics page - Monthly Average Temperature


The last alarms detected are displayed on the dashboard page as a danger indicator, forthe aquarium’s handler to be alerted. Despite this, all the alarms are kept on the databaseand can be accessed through the alarms’ page.

This page presents the list of all alarms on the database with detailed information such asdate, sensor type, read value, minimum and maximum values allowed (figures 4.14 and 4.15).

Figure 4.14: Alarms page - Alarms list

Figure 4.15: Alarms page - Alarms list

It is possible to send an alarm to the archive (figure 4.14a)). This feature was created tofacilitate the user’s interaction. When the handler had already seen and solved the alarm,he/she can archive it to avoid excess of information. This alarm is kept on the database withthe field ’seen’ checked as true and it will never show up again on the alarms’ page.

On this page a functionality to filter the alarms by sensor type is also available, using


the options found on a drop-down menu (figure 4.16a)). Figure 4.17 shows the filter appliedaccording to the choice that was made, in this case, for the salinity sensor.

The last functionality accessible is the alarms’ list download for an Excel sheet (figure4.16b)). This can be used for an analysis outside the platform or even for report means andregistry.

Figure 4.16: Alarms page - Alarms list filter and Export report

Figure 4.17: Alarms page - Alarms list with filter

Gallery is a page where it is possible to watch the live stream video (figure 4.18) recordeddirectly from the aquarium under analysis. A few day and night cameras were installed tokeep the aquarium’s under control 24 hours a day. These cameras report the occurrences inreal time and despite the disclosure purpose, it provides a constant visual control over what


is happening to the species in the aquarium.

Figure 4.18: Gallery page - Live stream video

Settings page contains information related to sensors in the system. This page is onlyaccessible for administrators, considering the sensibility of the data. It is possible to haveaccess to the list of connected sensors (figure 4.19) and the range of values associated to eachone of them.

Figure 4.19: Settings page - Sensors list


This way, it is also possible to add or remove sensors. To add a sensor (figure 4.20), a nameand type is needed and the sensor is added to the database with an unique identifier. Afterthis, the administrator is redirected to settings’ page where he can see the refreshed sensors’list.

Figure 4.20: Settings page - Add sensor

Figure 4.21: Settings page - Values range for each sensor

The list of range of values for each sensor (figure 4.21) is also shown and the administratorhas privileges to change the minimum and/or the maximum values assigned to each sensortype (figure 4.22). The administrator can always check the changes on settings’ page.


Figure 4.22: Settings page - Edit range of values for a sensor

This platform was developed considering two types of users: the regular user and theadministrator. The first has only access for visualisation’s purpose and cannot practise anyaction. On the other hand, the administrator has full access to the platform, includingto actions that can change the system’s behaviour. The last one, has also access to theadministrator’s default platform created by Django, where he can control database (figure4.23), users’ admission, its removal (figure 4.24) and groups formation with restricted access.

Figure 4.23: Django admin page - Database, Users and Groups


Figure 4.24: Django admin page - Users management

4.3.4 Deployment

Project deployment was made available through a virtual machine with Ubuntu 14.04.5LTS (Long Term Support) as operating system to work as a virtual private server. Thismachine suffered some configurations and packages installation in order to be able to handlethe web platform operation.

When running the application locally, the command

$ python manage . py runse rve r

handled everything, but when the application is deployed to production, there are a fewsteps that must be accomplished to get the final result so functional as when running locally.

To achieve this, some aspects should be dealt with using a different approach. AccessingDjango, files location, system configurations and daemon were the main changes that had tobe made.

To access Django, port 8000 or 127.0.0.1:8000 was used, but in production, a web serveris needed to be used as proxy request to Django.

To get the static files location, like images, CSS and JS files, a web server was also needed.Initially, the files were inside Django project, but this cannot happen in production.

To have full functionality, some configurations were required, such as database credentialsand paths to static files.

Finally, a daemon was required for the application to run on the background without theneed of a developer’s intervention.

The next steps will describe the approach taken for all the parameters described before.

To handle server files and proxy the incoming requests, Nginx (section 2.8) was the webserver used. The database, PostgreSQL (section 2.3.1) and Gunicorn (section 2.9) to deployDjango.

Looking at good practices, an update was considered to make sure all the packages wereup-to-date.


$ sudo apt−get update

Then, a database was created and configured. The installation of database and requiredpackages was achieved by the commands:

$ sudo apt−get i n s t a l l l ibpq−dev python−dev$ sudo apt−get i n s t a l l p o s t g r e s q l po s tg r e sq l−cont r i b

With the previous steps, the installation was concluded and then, followed the databaseand credentials creation. This was done using:

$ sudo su − pos tg r e s$ createdb <database name>$ c r e a t e u s e r −P <username>

The access to PostgreSQL command line interface was obtained by typing

$ psq l

and to get full access to database for the user created:

$ GRANT ALL PRIVILEGES ON DATABASE <database name>$ TO <username>;

The web server installed to handle the static files and work as proxy for requests to Django,was Nginx. To install it,

$ sudo apt−get i n s t a l l nginx

A configuration file was created to support the configuration of public location for staticfiles, so they could be handled by the web server (Nginx) and not by Django. It also containedthe set up proxy to transfer request to Django. This file was placed in /etc/nginx/sites-available directory.

The file content was:

s e r v e r {server name <s e r v e r i p a d d r e s s >;# Nginx w i l l e x e c u t e the s e t t i n g on ly f o r t h i s

a c c e s s l o g o f f ;# No one l o g s on product ion

# S t a t i c f i l e sl o c a t i o n / s t a t i c / {# Location f o r s t a t i c f i l e s handled by Nginxa l ias / var /www/html/ s t a t i c ;}

# Proxy r e q u e s tl o c a t i o n / {

proxy pass http : / / 1 2 7 . 0 . 0 . 1 : 8 0 0 0 ;p roxy se t heade r Host $host ;p roxy se t heade r X−Forwarded−For$proxy add x fo rwarded fo r ;


}}

A symbolic link was defined in /etc/nginx/sites-enabled directory in order to point to theconfiguration file previously defined, advising the Nginx to use that file.

This was done by using the command

$ ln −s . . / s i t e s−a v a i l a b l e/< s e t t i n g s f i l e n a m e >

After the changes, the Nginx service was restarted so the alterations could be applied.

$ s e r v i c e nginx r e s t a r t

A virtual environment (virtualenv) was used to produce an isolated Python environmentand guaranteed no conflicts related to application packages.

$ sudo apt−get i n s t a l l python−v i r t u a l e n v

After located in directory where the project will live, the virtual environment was createdand activated.

$ v i r t u a l e n v virtua lenv name$ source venv/ bin / a c t i v a t e

All the packages installation needed in the project were installed inside this environmentin order not to interfere with other packages in the system.

The web’s platform was cloned to virtual environment’s directory and the configurationfor the database and static files were completed.

Database in the settings.py file was configured with the previously register and the rootto static files was changed for the path considered in the earlier configuration file.

The database migration, i.e., the migration of tables from models to the real database,was applied using

$ python manage . py migrate

After this, static files were gathered and collected to the path defined above, where all thestatic files must remain and so the web server can handle them, when needed.

$ python manage . py c o l l e c t s t a t i c

Finally, a daemon was used to keep the application running on the background in port8000. Gunicorn was installed

$ pip i n s t a l l gunicorn

and after placed in the application’s root directory, the command

$ gunicorn <app name>. wsgi 0 . 0 . 0 . 0 : 8 0 0 0 −−daemon

was used to bind Gunicorn. This is running using WSGI and the IP address and port0.0.0.0:8000 is the defined for Django.

4.4. Mobile Application 69

4.4 Mobile Application

This mobile application aims to present the data collected from the sensors. This appli-cation has visualisation’s purpose only and does not allow any operations over the availabledata.

With the purpose of creating a better understanding for the user, the last values readwere presented and graphics were drawn.

4.4.1 Interface

This mobile application has an initial page that contains multiple options. The menu(figure 4.25) includes pages that present the previous values from sensors, alarms, statistics,gallery and video.

Figure 4.25: Application Main Page

The latter values page shows first the last alarms detected by each sensor (figure 4.26) todraw the user’s attention to those values. If they prove to be critical, they may lead to severeconsequences. Then, the last values read from each sensor are displayed (figure 4.27).


Figure 4.26: Last Values Page with LastAlarms

Figure 4.27: Last Values Page with Last Valuescollected

The graphics displayed on this page only present values from the current day. Consideringthis is an application to run on a mobile device, the surface available to exhibit a large numberof data is restricted. Therefore, the data showed is only from the present day, yet, it is enoughinformation for the handler to check the aquarium’s status.

Figures 4.28 and 4.30 show statistics of two of the sensors available in the system. Thesegraphics are displayed with a scale considering the reading date of records and the range ofvalues covered by each type of sensor. Figure 4.29 displays the pH graphic shown in figure4.28, but this time with zoom, so that the user can analyse carefully some of the peaksexistent, for example.

The page of alarms (figure 4.31) displays a list of values that were considered as dangerousinside a pre-defined scale of values. These values are presented in a list form along with somedetailed information about them such as date, sensor type, minimum and maximum valuesacceptable for that sensor.

The video page shows the video stream that is displayed live on Youtube. This is thevideo recording produced with the aquarium’s disclosure system described in 4.2.

The gallery page displays a few pictures from the aquarium’s species, as shown in figure4.32.

A page with information about the application and its context is also made available(figure 4.33).

4.4. Mobile Application 71

Figure 4.28: pH statistics Figure 4.29: pH statistics (with zoom)

Figure 4.30: Temperature statistics Figure 4.31: Alarms Page - List of alarms


Figure 4.32: Gallery Page Figure 4.33: About Page

5

Conclusions and Future Work

The IoT exponential evolution along the times forces us to reflect upon the dependencybetween several entities in a closer future. The connection between devices and people hasbeen evolving. Consequently, our behaviour and routines will be affected as well.

One of the IoT’s fields that has been extensively explored is the smart automation, i.e.,the remote control and intelligence related to devices in our homes, stores, schools.

This work began over this concept of smart environment, bringing along the possibility ofmonitoring and controlling an aquarium.

The implementation of a system like this one, can influence people’s lives. In this specificcase, it will bring a job improvement to the person responsible for the aquarium as it willallow him/her to check and monitor the aquarium’s real time conditions remotely.

The final result achieved during this dissertation met the initial main objectives and aplatform for monitoring the aquarium is now made available.

Despite the few existent platforms to control sensors and to connect IoT devices, thisplatform was thought, developed and created bearing in mind this specific environment, theEcomare aquarium.

Although it was developed within the scope of the aquarium’s monitoring system, it isflexible and can, therefore, be applied to any other type of sensors’ control system. Homeautomation, agriculture, greenhouses, garages and parking, among others. The modificationsrely essentially on the communication mode and used sensors.

Still some points should be taken into consideration for further improvement.An important task to have a real control over the aquarium and the most important

water parameters is in fact the full integration with predicted sensors for a successful speciessurvival.

Furthermore, it is highly significant to have other communication’s modules, mainly Wi-Fi, considering the straightforward access and the ubiquitous technology.

Other features can be added to enhance the platform. A fish wikipedia or a virtual visitto the aquarium and surrounding space could represent a future improvement.

Finally, the web and mobile applications should be tested by ordinary users in order toexamine if the features and the flows implemented are intuitive and user friendly.

73

74 Chapter 5. Conclusions and Future Work

Bibliography

[1] Helder Moreira. Sensor Data Integration and Management of Smart Environments. Uni-versidade de Aveiro, 2015.

[2] IEEE Standard University. https://www.standardsuniversity.org. [Online; accessed30-October-2017].

[3] Tena Vilcek and Tomislav Jakopec. Comparative analysis of tools for development ofnative and hybrid mobile applications. 2017 40th International Convention on Informa-tion and Communication Technology, Electronics and Microelectronics (MIPRO), pages1516–1521, 2017.

[4] AGILE methodology. http://agilemethodology.org. [Online; accessed 28-July-2017].

[5] Reefkeeping, an online magazine for the marine aquarist. http://reefkeeping.com/

issues/2004-05/rhf. [Online; accessed 21-February-2017].

[6] Fondriest Environmental, Inc. “pH of Water.” Fundamentals of Environmental Measure-ments, 2013.

[7] Fondriest Environmental, Inc. “Water Temperature.” Fundamentals of EnvironmentalMeasurements, 2014.

[8] Fondriest Environmental, Inc. “Conductivity, Salinity and Total Dissolved Solids.” Fun-damentals of Environmental Measurements, 2014.

[9] Fondriest Environmental, Inc. “Dissolved Oxygen.” Fundamentals of EnvironmentalMeasurements, 2013.

[10] Friedemann Mattern and Christian Floerkemeier. From the internet of computers to theinternet of things. In Lecture Notes in Computer Science (including subseries LectureNotes in Artificial Intelligence and Lecture Notes in Bioinformatics), volume 6462 LNCS,pages 242–259, 2010.

[11] Jalil Yahya, Ahmad. The definition and characteristics of ubiquiteous learning. Inter-national Journal of Education and Development using Information and CommunicationTechnology, 6(1):117–127, 2010.

[12] Hua Dong Ma. Internet of things: Objectives and scientific challenges. Journal ofComputer Science and Technology, 26(6):919–924, 2011.

75

https://www.standardsuniversity.org

http://agilemethodology.org

http://reefkeeping.com/issues/2004-05/rhf

http://reefkeeping.com/issues/2004-05/rhf

76 Bibliography

[13] Jayavardhana Gubbi, Rajkumar Buyya, Slaven Marusic, and Marimuthu Palaniswami.Internet of Things (IoT): A vision, architectural elements, and future directions. FutureGeneration Computer Systems, 29(7):1645–1660, 2013.

[14] Jennifer Yick, Biswanath Mukherjee, and Dipak Ghosal. Wireless sensor network survey.Computer Networks, 52(12):2292–2330, 2008.

[15] LoRa Technology. https://www.lora-alliance.org. [Online; accessed 28-October-2017].

[16] Konstantin Mikhaylov, Juha Petajajarvi, and Tuomo Hanninen. Analysis of Capacity andScalability of the LoRa Low Power Wide Area Network Technology. European Wireless2016, pages 119–124, 2016.

[17] Juha Petajajarvi, Konstantin Mikhaylov, Matti Hamalainen, and Jari Iinatti. Evalu-ation of LoRa LPWAN technology for remote health and wellbeing monitoring. 201610th International Symposium on Medical Information and Communication Technology(ISMICT), pages 1–5, 2016.

[18] Sigfox Technology. https://www.sigfox.com. [Online; accessed 28-October-2017].

[19] Ramon Sanchez-Iborra and Maria Dolores Cano. State of the art in LP-WAN solutionsfor industrial IoT services. Sensors (Switzerland), 16(5), 2016.

[20] ITU. The Internet of Things. Itu Internet Report 2005, page 212, 2005.

[21] The New Mainstream Wireless LAN Standard, Broadcom. http://www.dell.com/

downloads/global/shared/broadcom_802_11_g.pdf. [Online; accessed 07-July-2017].

[22] Li Li, Xiaoguang Hu, Ke Chen, and Ketai He. The applications of WiFi-based WirelessSensor Network in Internet of Things and Smart Grid. In Proceedings of the 2011 6thIEEE Conference on Industrial Electronics and Applications, ICIEA 2011, pages 789–793, 2011.

[23] Luca Mainetti, Luigi Patrono, and Antonio Vilei. Evolution of wireless sensor networkstowards the Internet of Things: A survey. SoftCOM, pages 1–6, 2011.

[24] Rui L. Aguiar. Lecture notes in mobile networks. November 2016.

[25] IETF. Transmission control protocol. January 1980.

[26] J. Postel. User datagram protocol. August 1980.

[27] Message Queuing Telemetry Transport Organisation. http://mqtt.org. [Online; ac-cessed 12-July-2017].

[28] Aleksandar Antonic, Martina Marjanovic, Pavle Skocir, and Ivana Podnar Zarko. Com-parison of the CUPUS middleware and MQTT protocol for smart city services. In Pro-ceedings of the 13th International Conference on Telecommunications, ConTEL 2015,2015.

https://www.lora-alliance.org

https://www.sigfox.com

http://www.dell.com/downloads/global/shared/broadcom_802_11_g.pdf

http://www.dell.com/downloads/global/shared/broadcom_802_11_g.pdf

http://mqtt.org

Bibliography 77

[29] Urs Hunkeler, Hong Linh Truong, and Andy Stanford-Clark. MQTT-S — A publish/-subscribe protocol for Wireless Sensor Networks. 2008 3rd International Conference onCommunication Systems Software and Middleware and Workshops (COMSWARE ’08),pages 791–798, 2008.

[30] Yuvraj Upadhyay, Amol Borole, and D. Dileepan. MQTT based secured home automa-tion system. 2016 Symposium on Colossal Data Analysis and Networking, CDAN 2016,2016.

[31] HiveMQ Broker. http://www.hivemq.com. [Online; accessed 16-August-2017].

[32] Mosquitto Organisation. https://mosquitto.org. [Online; accessed 12-July-2017].

[33] Valerie Lampkin, Weng Tat Leong, Leonardo Olivera, Sweta Rawat, Nagesh Subrah-manyam, and Rong Xiang. Building Smarter Planet Solutions with MQTT and IBMWebSphere MQ Telemetry. IBM Redbooks, page 270, 2012.

[34] Paho-MQTT Client. http://www.eclipse.org/paho/clients/python. [Online; ac-cessed 16-August-2017].

[35] Ala Al-Fuqaha, Mohsen Guizani, Mehdi Mohammadi, Mohammed Aledhari, and MoussaAyyash. Internet of Things: A Survey on Enabling Technologies, Protocols, and Appli-cations. IEEE Communications Surveys and Tutorials, 17(4):2347–2376, 2015.

[36] Dinesh Thangavel, Xiaoping Ma, Alvin Valera, Hwee Xian Tan, and Colin Keng YanTan. Performance evaluation of MQTT and CoAP via a common middleware. IEEEISSNIP 2014 - 2014 IEEE 9th International Conference on Intelligent Sensors, SensorNetworks and Information Processing, Conference Proceedings, (April):21–24, 2014.

[37] John O’Hara. Toward a commodity enterprise middleware. Queue, 5(4):48–55, 2007.

[38] Carl Trieloff, John O Hara, Mark Atwell, and Jpmorgan Chase. AMQP Advanced Mes-sage Queuing Protocol. (November):1–58, 2006.

[39] XMPP Standard. https://xmpp.org. [Online; accessed 30-October-2017].

[40] Node-RED. https://nodered.org. [Online; accessed 12-September-2017].

[41] JavaScript Object Notation (JSON). http://www.json.org. [Online; accessed 16-August-2017].

[42] MySQL Database. https://dev.mysql.com. [Online; accessed 23-August-2017].

[43] Cornelia Gyorodi, Robert Gyorodi, George Pecherle, and Andrada Olah. A comparativestudy: MongoDB vs. MySQL. 2015 13th International Conference on Engineering ofModern Electric Systems, EMES 2015, pages 0–5, 2015.

[44] MongoDB. https://www.mongodb.com. [Online; accessed 15-August-2017].

[45] PostgreSQL. https://www.postgresql.org. [Online; accessed 22-June-2017].

[46] Flask Framework. http://flask.pocoo.org. [Online; accessed 24-August-2017].

http://www.hivemq.com

https://mosquitto.org

http://www.eclipse.org/paho/clients/python

https://xmpp.org

https://nodered.org

http://www.json.org

https://dev.mysql.com

https://www.mongodb.com

https://www.postgresql.org

http://flask.pocoo.org

78 Bibliography

[47] Microsoft Developer Network - ASP.NET Web Framework. https://msdn.microsoft.com/en-us/library/4w3ex9c2.aspx. [Online; accessed 18-August-2017].

[48] ASP.NET Web Framework. https://www.asp.net. [Online; accessed 18-August-2017].

[49] Django Project. https://docs.djangoproject.com. [Online; accessed 08-August-2017].

[50] C. P. Rahul Raj and S. B. Tolety. A study on approaches to build cross-platform mo-bile applications and criteria to select appropriate approach. 2012 Annual IEEE IndiaConference, INDICON 2012, pages 625–629, 2012.

[51] Andre Charland and Brian Leroux. mobile application Development : Web vs. native.Communications of the ACM, 54:0–5, 2011.

[52] Ionic Framework. https://ionicframework.com. [Online; accessed 23-August-2017].

[53] Manuel Palmieri, Inderjeet Singh, and Antonio Cicchetti. Comparison of cross-platformmobile development tools. 2012 16th International Conference on Intelligence in NextGeneration Networks, ICIN 2012, pages 179–186, 2012.

[54] PhoneGap Community. https://phonegap.com. [Online; accessed 08-August-2017].

[55] Raspberry Pi Organisation. https://www.raspberrypi.org. [Online; accessed 18-July-2017].

[56] Arduino. https://www.arduino.cc. [Online; accessed 16-August-2017].

[57] HC-12 Wireless Serial Port Communication Module. https://www.elecrow.com/

download/HC-12.pdf. [Online; accessed 16-August-2017].

[58] Temperature and Humidity Sensor Datasheet. https://cdn.sparkfun.com/

datasheets/Sensors/Weather/RHT03.pdf. [Online; accessed 16-August-2017].

[59] Brightness Sensor Datasheet. https://cdn.sparkfun.com/datasheets/Sensors/

LightImaging/SEN-09088.pdf. [Online; accessed 16-August-2017].

[60] Snehal Mumbaikar and Puja Padiya. Web Services Based On SOAP and REST Princi-ples. International Journal of Scientific and Research Publications, 3(5):3–6, 2013.

[61] W3C. Simple object access protocol (SOAP) 1.1. W3C Working Group, (May), 2000.

[62] Apache HTTP Server. https://httpd.apache.org. [Online; accessed 14-August-2017].

[63] Apache HTTP Server Features. https://wiki.apache.org/httpd/FAQ. [Online; ac-cessed 14-August-2017].

[64] Nginx HTTP Server. https://www.nginx.com/resources/wiki. [Online; accessed 14-August-2017].

[65] PEP 3333 - WSGI Python Standard. https://www.python.org/dev/peps/pep-3333.[Online; accessed 14-August-2017].

[66] Gunicorn. http://gunicorn.org. [Online; accessed 14-August-2017].

https://msdn.microsoft.com/en-us/library/4w3ex9c2.aspx

https://msdn.microsoft.com/en-us/library/4w3ex9c2.aspx

https://www.asp.net

https://docs.djangoproject.com

https://ionicframework.com

https://phonegap.com

https://www.raspberrypi.org

https://www.arduino.cc

https://www.elecrow.com/download/HC-12.pdf

https://www.elecrow.com/download/HC-12.pdf

https://cdn.sparkfun.com/datasheets/Sensors/Weather/RHT03.pdf

https://cdn.sparkfun.com/datasheets/Sensors/Weather/RHT03.pdf

https://cdn.sparkfun.com/datasheets/Sensors/LightImaging/SEN-09088.pdf

https://cdn.sparkfun.com/datasheets/Sensors/LightImaging/SEN-09088.pdf

https://httpd.apache.org

https://wiki.apache.org/httpd/FAQ

https://www.nginx.com/resources/wiki

https://www.python.org/dev/peps/pep-3333

http://gunicorn.org

Bibliography 79

[67] Nginx Proxy Server. https://www.nginx.com/resources/glossary/

reverse-proxy-server. [Online; accessed 14-August-2017].

[68] Gunicorn Deploy. http://docs.gunicorn.org/en/latest/deploy.html. [Online; ac-cessed 14-August-2017].

[69] Nora Koch and M. Jose Escalona. Requirements engineering for web applications – acomparative study. Journal of Web Engineering, 2(3):193–212, 2004.

[70] Priyanka Thota and Yoohwan Kim. Implementation and Comparison of M2M Protocolsfor Internet of Things. Proceedings - 4th International Conference on Applied Comput-ing and Information Technology, 3rd International Conference on Computational Sci-ence/Intelligence and Applied Informatics, 1st International Conference on Big Data,Cloud Computing, Data Science and Engineering, ACIT-CSII-BCD 2016, pages 43–48,2017.

[71] Market share comparison between Apache and Nginx. https://www.similartech.com/compare/apache-vs-nginx. [Online; accessed 14-August-2017].

[72] Market share comparison between web servers. https://news.netcraft.com/

archives/2017/02/27/february-2017-web-server-survey.html. [Online; accessed14-August-2017].

[73] Apache mod wsgi. https://pypi.python.org/pypi/mod_wsgi. [Online; accessed 14-August-2017].

[74] Raspberry Pi Camera Options. https://www.raspberrypi.org/documentation/

raspbian/applications/camera.md. [Online; accessed 11-September-2017].

[75] FFmpeg framework. https://www.ffmpeg.org. [Online; accessed 12-September-2017].

[76] Pengyu Zhao, Jianwei Li, Jianxiao Xi, and Xuerong Gou. A mobile real-time video systemusing RTMP. Proceedings - 4th International Conference on Computational Intelligenceand Communication Networks, CICN 2012, pages 61–64, 2012.

[77] JqPlot - Pure JavaScript Plotting. http://www.jqplot.com. [Online; accessed 15-September-2017].

[78] jQuery. https://jquery.com. [Online; accessed 15-September-2017].

[79] jQuery Mobile. https://jquerymobile.com. [Online; accessed 15-September-2017].

https://www.nginx.com/resources/glossary/reverse-proxy-server

https://www.nginx.com/resources/glossary/reverse-proxy-server

http://docs.gunicorn.org/en/latest/deploy.html

https://www.similartech.com/compare/apache-vs-nginx

https://www.similartech.com/compare/apache-vs-nginx

https://news.netcraft.com/archives/2017/02/27/february-2017-web-server-survey.html

https://news.netcraft.com/archives/2017/02/27/february-2017-web-server-survey.html

https://pypi.python.org/pypi/mod_wsgi

https://www.raspberrypi.org/documentation/raspbian/applications/camera.md

https://www.raspberrypi.org/documentation/raspbian/applications/camera.md

https://www.ffmpeg.org

http://www.jqplot.com

https://jquery.com

https://jquerymobile.com

80 Bibliography

A

Appendix

Trigger for alarms

Trigger used to treat unusual values read from the sensors referred in chapter 3.

Figure A.1: Database Trigger

81

82 Appendix A. Appendix

Figure A.2: Database Trigger

Packages

To build the applications within this dissertation, some packages were used to obtain someof the results achieved. The following lines will present the packages used for the web andmobile applications.

Along with Django framework, the packages needed were:

• Django-1.10.6 - web framework;

• djangorestframework-3.6.3 - web API’s for Django;

• jquery.jplot-1.0.9 - charting plugin for the jQuery Javascript framework [77];

• psycopg-2.2.7 - enables the use of PostgreSQL with Django;

• XlsxWriter-0.9.8 - enables the use of Excel;

• setuptools-34.3.0 - facilitates packaging Python projects such as Python support,platform-specific details, project installation, among others;

• wheel-0.29.0 - allows support in case of need to install an artifact that does not requirebuilding or compilation;

• six-1.10.0 - provides compatibility between Python 2 and 3;

• pkg resources - provides an API for Python libraries to access their resource files.Through this package, the plugins are automatically detected by frameworks and ex-tensible applications;

• pip-9.0.1 - facilitates the packages installation for Django and Python environment;

• appdirs-1.4.2 - determinates the suitable platform-specific directories.

83

Along with PhoneGap framework, the packages needed were:

• jQuery-2.2.4 - JavaScript library to get along with HTML manipulation, animation,event handling and Asynchronous Javascript and XML (AJAX) 1 [78];

• jquery.mobile-1.3.0 - HTML5-based user interface system designed to make responsiveapplications [79];

• jquery.jplot-1.0.9 - charting plugin for the jQuery JavaScript framework [77].

API

• GET /api/sensors/ - returns the list of available sensors;

• GET /api/actuators/ - returns the list of available actuators;

• GET /api/sensorvalues/ - returns the list of all values read by the sensors;

• GET /api/lastvalues/ - returns the list of last values read from each sensor;

• GET /api/lastalarms/ - returns the list of last alarms detected by the system, foreach sensor;

• GET /api/detectedalarms/ - returns the list of all alarms detected by the system;

• GET /api/<date>/ - returns the list of values read for the date passed as argument.

• GET /api/<sensorType>/ - returns the list of values read for the sensor type passedas argument.

1AJAX - set of techniques used to build interactive applications for the web, processing the requestsimmediately. This method uses tools such as JS, dynamic HTML and XML.

84 Appendix A. Appendix

ana madalena de sistema de divulga˘c~ao e monitoriza˘c~ao ...§ão.pdf · rtmp real-time...

Documents