Sistema de automação residencial de baixo custo utilizando web service

(1)

DEPARTAMENTO ACAD ˆ

EMICO DE COMPUTAC

¸ ˜

AO

CURSO DE CI ˆ

ENCIA DA COMPUTAC

¸ ˜

AO

TIAGO MIGUEL REICHERT

SISTEMA DE AUTOMAC

¸ ˜

AO RESIDENCIAL DE BAIXO CUSTO

UTILIZANDO WEB SERVICE

TRABALHO DE CONCLUS ˜

AO DE CURSO

MEDIANEIRA

2016

(2)

SISTEMA DE AUTOMAC

¸ ˜

AO RESIDENCIAL DE BAIXO CUSTO

UTILIZANDO WEB SERVICE

Trabalho de Conclusão de Curso apresentado ao Departamento Acadêmico de Computação da Universidade Tecnológica Federal do Paraná como requisito parcial para obtenção do t´ıtulo de “Bacharel em Ciência da Computação”.

Orientador: Prof. Dr. Pedro Luiz de Paula Filho

Co-orientador: Prof. Me. Hamilton Pereira da Silva

MEDIANEIRA

2016

(3)

Câmpus Medianeira

Departamento Acadêmico de Computação

Coordenação Curso Bacharelado em Ciência da Computação

Câmpus Medianeira Avenida Brasil, 4232 85884-000 - Medianeira - Paraná - Brasil Fone: (45) 3240-8000 www.utfpr.edu.br/medianeira

TERMO DE APROVAÇÃO

Sistema de Automação Residencial Utilizando Web Service Por

Tiago Miguel Reichert

Este Trabalho de Conclusão de Curso (TCC) foi apresentado às 13:00h do dia 07 de Junho de 2016 como requisito parcial para a obtenção do título de no Curso Bacharelado em Ciência da Computação, da Universidade Tecnológica Federal do Paraná, Câmpus Medianeira. O candidato foi arguido pela Banca Examinadora composta pelos professores abaixo assinados. Após deliberação, a Banca Examinadora considerou o trabalho aprovado.

Prof. Pedro Luiz de Paula Filho UTFPR – Câmpus Medianeira

(Orientador)

Prof. Marcio Angelo Matté UTFPR – Câmpus Medianeira

(Convidado)

Prof. Ricardo Sobjak UTFPR – Câmpus Medianeira

(Convidado)

Prof. Jorge Aikes Junior UTFPR – Câmpus Medianeira (Responsável pelas atividades de TCC)

(4)

REICHERT, Tiago Miguel. SISTEMA DE AUTOMAÇ ÃO RESIDENCIAL DE BAIXO CUSTO UTILIZANDO WEB SERVICE. 57 f. Trabalho de Conclusão de Curso – Curso de Ciência da Computação, Universidade Tecnológica Federal do Paraná. Medianeira, 2016. Com a busca por comodidade e segurança residencial, foi desenvolvido um sistema de automação visando facilitar o controle de diversos dispositivos e o gerenciamento de recursos energéticos e h´ıdricos, além de um módulo responsável por segurança. O sistema de automação foi embarcado em um Raspberry Pi, este por sua vez controla um Arduino e oferece interfaces de comunicação implementadas em formato de um web service REST (transferência de estado representacional). A interface humana que fornece os componentes necessários para o controle e gerenciamento do sistema de automação por parte do usuário, foi disponibilizado para plataforma Android. Com este sistema foram atendidos os requisitos relevantes para automação residencial de forma eficiente e com tecnologias e ferramentas gratuitas, disponibilizando ainda a possibilidade de futuras extensões, como por exemplo, outras plataformas para gerenciamento e controle do sistema embarcado pelo usuário.

Palavras-chave: domótica, REST, serviço web, android, arduino, raspberry pi, segurança, comodidade

(5)

REICHERT, Tiago Miguel. LOW COST HOME AUTOMATION SYSTEM USING WEB SERVICE. 57 f. Trabalho de Conclusão de Curso – Curso de Ciência da Computação, Universidade Tecnológica Federal do Paraná. Medianeira, 2016.

With the request for convenience and home security, was developed an automation system to facilitate the control of some devices and the management of energy and water resources, as well as a module to increase the security. The automation system was embedded on a Raspberry Pi, there controls an Arduino and offers communication interfaces implemented in form of a REST (representational state transfer) web service. The interface that provides the components for the user to control and management the automation system is available for Android platform. In this system all relevant requirements for home automation were efficiently attended and with free technologies and tools, still providing the possibility of further expansion, such as other platforms for management and control of the embedded system by the user.

(6)

Agradec¸o a todos os professores pelo conhecimento repassado durante o percorrer do curso, e principalmente aos meus orientadores Dr. Pedro Luiz de Paula Filho e Me. Hamilton Pereira da Silva, assim como, ao professor Esp. Marcio Angelo Matt´e que me auxiliaram no desenvolvido deste projeto.

Ressalto também um agradecimentos aos colegas que fizeram parte desta trajetória, na qual adquirimos conhecimento e certamente novas amizades com momentos de estudos e descontração.

(7)

(8)

–

FIGURA 1 Funcionamento b´asico de um web servive . . . 21 –

FIGURA 2 Arquitetura Cliente / Servidor . . . 22 –

FIGURA 3 Arquitetura de Sistema em Camadas . . . 22 –

FIGURA 4 Arquitetura do Sistema Android . . . 25 –

FIGURA 5 Mensagem no Formato JSON . . . 30 –

FIGURA 6 Diagrama de Implantac¸˜ao . . . 32 –

FIGURA 7 Sensor de Umidade e Temperatura DHT11 . . . 34 –

FIGURA 8 Sensor de movimento/presenc¸a PIR . . . 34 –

FIGURA 9 M´odulo rel´e com 2 canais . . . 35 –

FIGURA 10 Solenoide . . . 36 –

FIGURA 11 Raspberry Pi 2 - Modelo B . . . 37 –

FIGURA 12 Protocolo de Comunicac¸˜ao Serial . . . 37 –

FIGURA 13 Dados do Protocolo de Comunicac¸˜ao Serial . . . 38 –

FIGURA 14 Diagrama de Sequencia - Ligando uma Lˆampada X . . . 39 –

FIGURA 15 Instalação F´ısica - Acionamento de uma Lâmpada . . . 39 –

FIGURA 16 Maquete Utilizada para Experimentos . . . 44 –

FIGURA 17 Configurações da Aplicação Android . . . 45 –

FIGURA 18 Cadastrando Dispositivo pela Aplicac¸˜ao Android . . . 46 –

FIGURA 19 Telas da Aplicac¸˜ao Android . . . 46 –

FIGURA 20 Sub-menu Iluminac¸˜ao . . . 47 –

FIGURA 21 Controles da Aplicac¸˜ao Android . . . 48 –

FIGURA 22 Telas da Aplicac¸˜ao Android . . . 49 –

FIGURA 23 Telas de Agendamentos . . . 49 –

(9)

AC Corrente Alternada

API Application Programming Interface

CI Circuito Integrado

CPU Central Processing Unit

DC Corrente Cont´ınua

DEX Dalvik Executable

EEPROM Electrically Erasable Programmable Read-Only Memory

EPROM Erasable Programmable Read-Only Memory

GPIO General Purpose Input/Output

HTTP Hypertext Transfer Protocol

IDE Ambiente de Desenvolvimento Integrado

IP Internet Protocol

JEE Java Enterprise Edition

JME Java Micro Edition

JRE Java Runtime Enviroment

JSE Java Standard Edition

JSON JavaScript Object Notation

JSP JavaServer Pages

MVC Model, View, Controller

NDK Native Development Kit

OSI Open Systems Interconnection

RAM Random Access Memory

REST Transferˆencia de Estado Representacional REST Transferˆencia de Estado Representacional

RF Requisitos Funcionais

ROM Read-Only Memory

SBC Single-board Computer

SD Sistema Distribu´ıdo

SDK Software Development Kit

SOA Service-Oriented Architecture

SOAP Protocolo Simples de Acesso a Objetos

SO Sistema Operacional

UC Unidade de Controle

UDDI Universal Description, Discovery and Integration

ULA Unidade L´ogica Aritm´etica

URI Uniform Resource Identifier

USB Universal Serial Bus

WSDL Web Service Description Language

(10)

1 INTRODUÇ ÃO . . . 10 1.1 OBJETIVO GERAL . . . 11 1.2 OBJETIVOS ESPECÍFICOS . . . 11 1.3 JUSTIFICATIVA . . . 11 2 FUNDAMENTAÇ ÃO TE ÓRICA . . . 13 2.1 AUTOMAÇ ÃO RESIDENCIAL . . . 13 2.2 SISTEMAS EMBARCADOS . . . 15 2.2.1 Microprocessador . . . 15 2.2.2 Microcontroladores . . . 16 2.2.3 Arduino . . . 17 2.3 SINGLE-BOARD COMPUTER . . . 17 2.3.1 Raspberry Pi . . . 17 2.4 COMPUTAÇ ÃO DISTRIBUÍDA . . . 18 2.4.1 HTTP . . . 19 2.4.2 Web Service . . . 20 2.4.2.1 SOAP . . . 20 2.4.2.2 REST . . . 21

2.4.2.3 Comparac¸˜ao entre SOAP e REST . . . 23

2.5 DESENVOLVIMENTO PARA DISPOSITIVOS M ´OVEIS . . . 23

2.5.1 Sistema Operacional Android . . . 24

2.6 TECNOLOGIAS E FERRAMENTAS . . . 26

2.6.1 Java . . . 26

2.6.2 VRaptor . . . 27

2.6.3 Maven . . . 28

2.6.4 Raspbian Wheezy . . . 28

2.6.5 Ambiente de Desenvolvimento Integrado . . . 29

2.6.6 JSON . . . 29 3 MATERIAL E M ÉTODOS . . . 31 3.1 ARQUITETURA DO SISTEMA . . . 31 3.1.1 Diagrama de Implantação . . . 32 3.1.2 Requisitos do Sistema . . . 32 3.2 EQUIPAMENTOS . . . 33 3.2.1 Sensores . . . 33 3.2.2 Atuadores . . . 35 3.3 SISTEMA EMBARCADO . . . 36 3.4 SISTEMA CONTROLADOR . . . 37 3.5 APLICAÇ ÃO ANDROID . . . 38

3.6 SISTEMA DE AUTOMAC¸ ˜AO RESIDENCIAL . . . 39

4 RESULTADOS EXPERIMENTAIS . . . 44

5 CONCLUS ˜AO . . . 52

(11)

(12)

1 INTRODUC¸ ˜AO

Na sociedade de maneira geral é poss´ıvel observar a busca por comodidade, de modo com que uma pessoa não utilize muito tempo na resolução de problemas cotidianos, possibilitando assim uma melhor qualidade de vida. Um sistema condicionador de ar, por exemplo, pode ser entendido como uma tecnologia voltada a comodidade, pois contém funcionalidades que permitem ao seu utilizador o controle de alguns elementos como a temperatura em seu ambiente. Esse cenário pode ser melhorado aplicando-se “inteligência” ao equipamento, de modo com que seja poss´ıvel o controlar remotamente assim que sair de sua residência, para que quando chegue em casa o ambiente já esteja na temperatura desejada.

Considerando as facilidades provenientes desses mecanismos de comodidade é poss´ıvel pensar na sua aplicação junto a segurança residencial, tendo em vista que a segurança é um item indispensável. Alguns equipamentos de segurança residencial são sensores de feixe infravermelho, câmeras de v´ıdeo e sensores de presença, porém geralmente não é poss´ıvel acessar estes equipamentos remotamente para verificar se houve algum incidente de segurança. Com o avanço e popularização em sensores e componentes eletrônicos, vem sendo cada vez mais viável o desenvolvimento e implantação de sistemas automatizados residenciais, por meio de microcomputadores baseados em SBC (Single-board Computer) de baixo custo.

Conforme GVcia (2015), a quantidade de smartphones no Brasil já ultrapassou a quantidade de computadores, com a mobilidade e facilidade de utilização destes aparelhos, se torna muito cômodo a possibilidade de gerir praticamente todos os equipamentos eletrônicos por meio de um aparelho, sendo poss´ıvel ter diversos destes “controles universais”.

A proposta deste trabalho é implementar um esquema de automação que aumente a comodidade/segurança residencial por meio da integração de diversos equipamentos utilizando um microcomputador baseado em SBC. O mesmo deve ainda disponibilizar uma interface para o usuário por meio de um aplicativo mobile, melhorando a usabilidade destes equipamentos e tornando-os acess´ıveis de qualquer lugar com conexão a Internet.

(13)

1.1 OBJETIVO GERAL

Desenvolver um esquema de automação residencial visando proporcionar segurança e comodidade aos moradores.

1.2 OBJETIVOS ESPEC´IFICOS

Para atingir o objetivo geral ´e necess´ario o atendimento aos seguintes objetivos espec´ıficos:

• Elaborar o referencial teórico sobre automação residencial; • Projetar e implementar o sistema embarcado;

• Projetar e implementar o sistema de comunicac¸˜ao; • Projetar e implementar o sistema controlador;

• Projetar e implementar o sistema de interface para interação do usuário com o sistema; • Testar e conduzir experimentos de funcionalidade.

1.3 JUSTIFICATIVA

Segundo Sebrae (2015), no Brasil a automação residencial está em forte expansão, impulsionada pela procura de segurança e conforto por parte dos consumidores.

Conforme Aureside (2013), citado por Pauli (2014), alguns equipamentos como projetor multim´ıdia, ar-condicionado, televisão, são instalados impulsionados pela onda mercadológica do momento e acabam resolvendo alguns problemas, porém, a falta de integração de tais equipamentos acaba gerando frustrações. Por exemplo, televisão, DVD player, home theater e receptor de tv a cabo geralmente estão muito próximos e acaba sendo necessário interagir com praticamente todos eles, porem cada um possui o seu controle. Todos estes equipamentos e muitos outros podem ser controlados por meio de um smartphone, sem

(14)

haver necessidade de procurar pelos diversos controle remotos.

Um dos desafios a ser atingidos é a diminuição no custo destes sistemas, pois após realizar uma pesquisa de preços de sistemas de automação residencial dispon´ıveis no mercado1, foi poss´ıvel constatar que o valor destes, giram em torno de R$6.000,00. Outro ponto a ser observado é interface com o usuário a qual se da somente via painéis instalados na casa ou aplicativos para uma plataforma espec´ıfica.

As residências inteligentes possibilitam um uso mais apropriado do tempo, tornando as tarefas mais prazerosas e ágeis, tendo em vista que podem realizar o serviço repetitivo do dia a dia, além disso proporcionam um melhor controle da utilização de fontes de energia e fontes h´ıdricas por exemplo, possibilitando um consumo mais racional (BOLZANI, 2004).

1_{Levantamento de prec¸os realizado nos seguintes enderec¸os: http://goo.gl/WRUOeb, http://goo.gl/CwJosP e}

(15)

2 FUNDAMENTAÇ ÃO TE ÓRICA

Este cap´ıtulo aborda o embasamento teórico relacionado às tecnologias aplicadas ao presente trabalho. Serão descritos conteúdos relacionados a automação residencial, sistemas embarcados, computação distribu´ıda e desenvolvimento para dispositivos móveis.

2.1 AUTOMAC¸ ˜AO RESIDENCIAL

Segundo Bolzani (2014), a automação residencial também é conhecida por domótica, que origina-se do latim domus (casa) e do termo robótica. Com domótica pretende-se criar sistemas controladores que realizam os processos repetitivos de forma automatizada, integrar os diversos dispositivos presentes em uma residência em uma plataforma única, controlar sistemas de segurança, disponibilizando maior conforto e segurança para os moradores por meio de uma residência inteligente.

Para um melhor entendimento do que a automação residencial é capaz, basta analisar uma situação em que após um dia exaustivo de trabalho, tem-se apenas vontade de descansar, porém ao chegar em frente de casa percebe-se que o controle do portão eletrônico foi esquecido no trabalho, e que será necessário voltar para buscá-lo. Isso não seria necessário caso houvesse um sistema de domótica na residência, somente seria preciso acionar o portão e desativar o sistema de segurança por meio de um aplicativo instalado em um smartphone se autenticando com uma senha (seja ela numérica, uma combinação de toques ou até mesmo um comando de voz). Após adentrar na casa o sistema aciona o ar-condicionado na temperatura pré-programada e acende as luzes da sala de entrada.

Além disso, o sistema pode armazenar as atividades corriqueiras do usuário, conseguindo assim, deduzir que ao entrar na sala de entretenimento será ligada a televisão no canal desejado, ativado o home theater, fechando as persianas e diminu´ıdo a luminosidade das lâmpadas. Tudo isso programado conforme o usuário desejar, podendo ser tudo de modo

(16)

automático ou o sistema pode solicitar a confirmação do usuário antes de realizar qualquer operação. Pode-se observar que o proprietário ganha em segurança, comodidade e economia energética tendo em vista que o mesmo pode desligar as luzes e outros equipamentos eletrônicos automaticamente assim que detectar que não estão sendo utilizados. Esse exemplo não é ficção cientifica, já se pode obter isso e muito mais com um sistema de automação residencial.

Segundo Aldrich (2003), a tendência é que os equipamentos de uma residência, sejam conectados em rede, de forma que possam ser gerenciados por meio de comandos e monitoramentos remotos, tanto internos quanto externos à habitação, além disso o sistema pode ser capaz de aprender as preferências dos operadores. Isso permitirá o aumento da qualidade de vida para seus moradores e usuários, utilização eficaz dos recursos com sustentabilidade, proporcionando lazer, comunicação, racionalização de energia, segurança e conforto.

O significado da palavra conforto no idioma português está relacionado à sensação de bem-estar, porém pelo fato de depender muito do meio cultural e de cada individuo é dif´ıcil defini-la objetivamente, por exemplo, para uma pessoa o simples fato de possuir uma residência significa conforto, já para outra, tem-se a necessidade de uma casa inteligente que realize as atividades mecânicas e repetitivas que ele teria que exercer (SANTOS DA SILVA; OLIVEIRA SANTOS, 2012).

Para Baumann (2008), a preocupação com a segurança residencial é cada vez maior, tendo em vista o crescimento da violência, abuso sexual e furtos. Existem inúmeras maneiras de aumentar a segurança residencial, seja com uso de câmeras, alarmes ou vigilantes. Porém a maioria dos sistemas de segurança, dispon´ıveis no mercado, funcionam de forma especifica não integrando a segurança com a comodidade, por exemplo, será necessário uma aplicação para visualizar imagens de uma câmera de segurança e outra para acionar o ar condicionado.

Os invasores comumente evitam residencias que aparentam ter movimentação de pessoas, e tendem a escolher casas desertas e/ou com pouca ou nenhuma iluminação. Segundo Paraná Seguro (201?), a melhor forma de se proteger é a vigilância natural, quando o invasor acredita estar sendo vigiado e assim se desencoraja e procura outro local para agir. Uma forma de simular a vigilância natural seria por meio de um sistema de automação residencial, no qual é poss´ıvel ligar/desligar lâmpadas e um sistema de som ambiente, remotamente, aparentando a presença de pessoas. Outra forma de melhorar a segurança é, assim que detectar alguma movimentação estranha, seja por câmera ou sensores, ser alertado por um smartphone informando que houve alguma intrusão, assim, podendo ligar para a pol´ıcia diretamente por meio de um botão no aplicativo que lhe alertou.

O módulo responsável por gerir os diversos atuadores e sensores necessários em sistema de automação residencial pode estar implantado em um sistema embarcado tendo em

(17)

vista a sua praticidade.

2.2 SISTEMAS EMBARCADOS

Sistemas embarcados geralmente estão atribu´ıdos a um hardware limitado e, realizam atividades bem espec´ıficas. Estes sistemas estão cada vez mais presentes na vida das pessoas, e são encontrados em equipamentos eletrodomésticos ou até mesmo em sistemas automotivos, por exemplo. Conforme os processadores utilizados se tornam mais sofisticados e potentes, torna-se viável o uso de sistemas operacionais para auxiliar o desenvolvimento de software embarcado, além disso o preço do hardware torna-se mais baixo e o custo final do sistema é cada vez mais influenciado pelo custo de desenvolvimento do software (GALLASSI; MARTINS, 2014).

2.2.1 Microprocessador

Um microprocessador é uma CPU (Unidade Central de Processamento) constru´ıda em um único CI (Circuito Integrado). Este, precisa de outros periféricos para formação de um computador, tais como, memória e unidade de entrada e sa´ıda. A organização básica destes dispositivos pode ser dividida em unidade de controle, unidade lógica aritmética e registradores. • Unidade de Controle (UC): A UC é responsável pela decodificação e execução das instruções, também fornece os sinais de temporização adequados para o processador e para o próprio computador (CAMPOS, 2008);

• Unidade Lógica Aritmética (ULA): A ULA faz parte do processador e é responsável por executar as operações lógicas aritméticas, todas operações realizadas são baseadas na operação de adição. O desempenho da ULA influencia diretamente o desempenho do processador (OLIVEIRA et al., 2013);

• Registradores: S˜ao usados para o armazenamentos internos da CPU, constru´ıdos como flip-flops, que podem armazenar dados. Existem diversos registradores na CPU e o principal deles ´e chamado de acumulador (OLIVEIRA et al., 2013).

(18)

2.2.2 Microcontroladores

Para Assis (2004), um diferencial entre microcontroladores e microprocessadores é o fato do microcontrolador possuir todos os periféricos necessários em um único CI, tais como UC, ULA, registradores, memória e unidade de entrada e sa´ıda. Estes controladores são geralmente utilizados em aplicações espec´ıficas, como por exemplo, monitoramento de sensores, controle de relés e outros. Porém quando se deseja trabalhar com câmeras de v´ıdeo ou algo que exija um processamento maior deve-se recorrer aos SBC pelo fato de terem um poder de processamento muito superior aos microcontroladores, na Tabela 1, é poss´ıvel visualizar a comparação entre um Arduino Mega 2560, baseado em microcontrolador, e um Raspberry Pi 2, baseado em SBC.

• Memória: As memórias podem ser divididas em dois grupos, RAM (Random Access Memory) e ROM (Read-Only Memory). A memória RAM permite a leitura e gravação de dados durante a execução de programas, e a memória ROM permite somente a leitura dos dados e em alguns modelos e com técnicas espec´ıficas é poss´ıvel regravar a memória, por exemplo, a EPROM (Erasable Programmable Read-Only Memory) permite que seu conteúdo seja deletado expondo a mesma à luz ultravioleta por cerca de 10 minutos, porém é necessário uma voltagem cada vez maior para reescrever os dados, o que torna limitado a quantidade de vezes que pode ser reescrita. Já a EEPROM (Electrically Erasable Programmable Read-Only Memory) permite apagar e regravar os dados inúmeras vezes (MONTEIRO, 2007);

• Unidade de Entrada e Sa´ıda: Para permitir o contato com outros dispositivos, é necessário a unidade de entrada e sa´ıda, a qual dispõe de diversas “portas” de entrada, sa´ıda e entrada/sa´ıda no microcontrolador. Quando se trabalha com essas “portas” primeiramente é necessário escolher qual será utilizada e em seguida enviar ou receber dados nela (MONTEIRO, 2007).

Caracter´ısticas Microcontrolador Single-board Computer

Modelo Arduino Mega 2560 Raspberry Pi 2 – Modelo B

Clock Speed 16 MHz 4x 900Mhz

Mem´oria RAM 8 KB 1 GB

Armazenamento Interno - 256KB Externo - MicroSD e USB Tabela 1 – Comparativo entre microcontrolador e SBC

(19)

2.2.3 Arduino

Conforme Arduino (2016), esta placa possui o microcontrolador ATmega25601, detêm 54 pinos GPIO (General Purpose Input/Output) os quais podem ser utilizados, por exemplo, para leitura de sensores digitais e acionar atuadores. Possui também 16 pinos de entrada analógica os quais podem ser utilizados para leitura de sensores cuja operação e analógica. Além disso dispõem de 256KB de memória flash e um clock speed de 16 MHz (ARDUINO, 2016).

A placa pode ser alimentada através da conexão USB ou com uma fonte de alimentação externa a qual é selecionada automaticamente.

2.3 SINGLE-BOARD COMPUTER

Conforme Rasmussen (1989), um SBC é um computador montado em uma placa de circuito, contendo todos os componentes necessários para seu funcionamento, tais como, microprocessador, unidade de entrada e sa´ıda e memória. Geralmente, um SBC representa uma solução de baixo custo para controle e processamento de diversos elementos. Entre os seus principais representantes, pode-se citar o Raspberry Pi, Banana Pi, Intel Edson, Intel Galileo, entre outros.

2.3.1 Raspberry Pi

Conforme Raspberry Pi Foundation (2015), Raspberry Pi é um SBC desenvolvido no Reino Unido pela Fundação Raspberry Pi, em 2006 buscou-se criar um pequeno computador de baixo custo para incentivar o ensino de computação nas escolas, já em 2008 os microprocessadores desenhados para dispositivos móveis começaram a se popularizar tornando-os mais acess´ıveis e, segundo tornando-os autores, com um processamento alto o suficiente para

1_Datasheet _{dispon´ıvel em}

(20)

aplicações multim´ıdia, porém, somente em 2012 começam as primeiras vendas do Raspberry Pi Modelo A com 256 MB de memória RAM. Na Tabela 2, pode-se observar a diferença entre os modelos do Raspberry Pi.

Tendo em vista que o Raspberry Pi é um computador, ele possui um SO (Sistema Operacional) que gerencia os seus recursos, tais como memória, processador, rede, dentre outros. Existem diversos sistemas operacionais compat´ıveis com o Raspberry Pi, porém o mais utilizado é o Raspbian2, o qual é uma distribuição do Debian, otimizado para o Raspberry Pi. Outra possibilidade de SO é o Windows 10 IoT3, que é uma distribuição Windows, dispon´ıvel a partir do Raspberry Pi 2.

Caracater´ıstica Modelo A Modelo A+ Modelo B Modelo B+ 2 Modelo B

Processador 1x 700MHz 1x 700MHz 1x 700MHz 1x 700MHz 4x 900MHz

Mem´oria RAM 256 MB 256 MB 512 MB 512 MB 1 GB

Armazenamento Full SD Micro SD Full SD Micro SD Micro SD

Porta Ethernet N˜ao N˜ao Sim Sim Sim

GPIO 17 26 17 26 40

Tabela 2 – Comparativo dos diversos modelos de Raspberry Pi Fonte: Adaptado de Raspberry Pi Foundation (2015)

Porém em automação residencial o sistema embarcado precisa se comunicar de alguma forma com a aplicação a qual o usuário utiliza, para realizar esta comunicação é poss´ıvel utilizar computação distribu´ıda.

2.4 COMPUTAÇ ÃO DISTRIBUÍDA

Em um SD (Sistema Distribu´ıdo), máquinas distintas se comunicam via rede de modo que pareçam somente uma máquina. As aplicações de SD podem compartilhar dados, arquivos, executar códigos em máquinas remotas dentre outras funcionalidades. Conforme Silva e Lovatti (2009), as principais vantagens de um SD em relação a sistemas centralizados, nos quais cada máquina distinta se comporta de forma independente, são: desempenho, escalabilidade, conectividade, segurança, confiabilidade, tolerância a falhas e transparência. Os autores ainda descrevem estes comportamentos da seguinte forma:

2_{Dispon´ıvel em https://www.raspbian.org/}

(21)

• Desempenho e Escalabilidade: As requisições feitas pelos clientes podem ser enviadas a diferentes servidores, não sobrecarregando um servidor e assim aumentando o desempenho. Escalabilidade é a possibilidade de um sistema crescer sem afetar as aplicações e os usuários já existentes;

• Conectividade e Segurança: Fornecer interfaces comuns a todas as máquinas do sistema, omitindo assim problemas de conectividade devido a particularidades de uma máquina. Caso o recurso que se deseja acessar for um sistema de arquivos globalmente compartilhado, os usuários remotos poderão acessá-lo como acessariam um sistema de arquivos local, privado. Estes sistemas devem permitir acesso somente a usuários autorizados e garantir que a informação transmitida pela rede somente possa ser lida pelo usuário que a solicitou;

• Confiabilidade e Tolerância a Falhas: Realizar replicação de recursos, trazendo uma maior confiabilidade e disponibilidade destes recursos para os usuários. SD possuem mecanismos que detectam e reagem quando são encontradas falhas no sistema, assegurando a consistência das informações, eles ainda precisam conseguir reintegrar os recursos que falharam, assim que reparados;

• Transparência: Ocultar a localização de recursos dos usuários que estão os acessando, dando a impressão de estar acessando arquivos remotos como se fossem locais.

Dentre as tecnologias para comunicação baseadas em SD pode-se citar o web service o qual oferece um meio de comunicação entre máquinas de forma eficiente e genérica.

2.4.1 HTTP

HTTP (Hypertext Transfer Protocol) é um protocolo contido na camada de aplicação do modelo OSI (Open Systems Interconnection), conforme Kurose e Ross (2006), HTTP consiste em uma arquitetura de duas camadas, na qual existe uma parte no cliente e outra no servidor. Estas duas camadas se comunicam por mensagens cuja estrutura e modo de comutação é definido pelo protocolo HTTP.

O HTTP possui diversos métodos que o lado do cliente solicita ao servidor, dentre eles pode-se citar GET, POST, PUT e DELETE. Estes métodos podem ser executados todos na mesma URI (Uniform Resource Identifier) porém no lado do servidor serão interpretados de forma diferenciada. O GET é comumente utilizado para solicitar algo, o POST para criar

(22)

algo no lado do servidor, PUT para atualizar e por fim o DELETE para excluir (BELSHE et al., 2015).

2.4.2 Web Service

Conforme W3C (2004), o web service foi estruturado com o intuito de disponibilizar a interação entre máquinas, de forma independente de hardware e software utilizados em cada máquina, conseguindo assim integrar sistemas heterogêneos. Este serviço geralmente possui interfaces baseadas em XML (Extensible Markup Language), disponibilizadas na rede por meio do protocolo HTTP. Existem dois tipos de web services amplamente utilizados, o SOAP (Protocolo Simples de Acesso a Objetos) e o REST (Transferência de Estado Representacional), cada um com suas particularidades e aplicações, porém ambos são derivados da arquitetura SOA (Service-Oriented Architecture), na qual as funcionalidades do sistema são desenvolvidas em forma de serviços.

2.4.2.1 SOAP

O web service SOAP faz uso de trˆes tecnologias, SOAP, WSDL (Web Service Description Language) e UDDI (Universal Description, Discovery and Integration) (SILVA; LOVATTI, 2009).

• SOAP: Protocolo que possui as chamadas e retornos dos web services, ele permite a troca de informac¸˜oes em ambientes distribu´ıdos;

• WSDL: Linguagem de descrição dos web services, onde estão descritas as informações como a localização, operações dispon´ıveis e assinaturas de funções do web service; • UDDI: Gerencia informação sobre provedores, implementações e metadados de serviços.

Além disso, contém informações sobre os serviços e funcionalidades que os serviços web oferecem, permitindo uma associação desses serviços com suas informações técnicas.

Na Figura 1 é demonstrado o funcionamento básico de um web service SOAP, em que o cliente faz uma requisição ao servidor e o mesmo retorna os dados em formato XML para o cliente.

(23)

Figura 1 – Funcionamento b´asico de um web servive Fonte: Adaptado de Silva e Lovatti (2009)

O web service é acessado pelos seus clientes usando mensagens formatadas em XML. O SOAP encapsula essas mensagens e as transmite por HTTP, ou por outro protocolo, por exemplo, TCP ou SMTP. Os serviços (operações, mensagens, parâmetros etc) são descritos na WSDL. O processo de publicação/pesquisa/descoberta utiliza o UDDI. Os web services podem ser ativados por demanda ou podem funcionar continuamente.

2.4.2.2 REST

Visando reunir as melhores práticas nos estilo de arquitetura já existentes, Fielding (2000), propôs um novo estilo de arquitetura que reúne as melhores práticas identificadas em sua pesquisa. Este estilo é composto pelas seguintes estruturas: cliente/servidor, sistema em camadas, cache e sem estado.

• Cliente/Servidor: Basicamente composto por duas partes, o cliente e o servidor. Os clientes solicitam serviços e recursos disponibilizados pelo servidor, esta comunicação pode ocorrer em máquinas distintas por meio da rede (na qual o servidor está em uma máquina e o cliente em outra), como pode ser visto na Figura 2, ou o cliente e servidor podem estar em uma só máquina (LIMA, 2012).

• Sistemas em Camadas: A Figura 3 representa a arquitetura de um sistema em camadas. ´

E poss´ıvel observar que esta arquitetura ´e composta por diversos n´ıveis hier´arquicos, em que cada n´ıvel corresponde a uma camada, e esta por sua vez conhece somente as

(24)

Figura 2 – Arquitetura Cliente / Servidor Fonte: Adaptado de Lima (2012)

Figura 3 – Arquitetura de Sistema em Camadas Fonte: Adaptado de IBM (2015)

interfaces da camada superior, conseguindo assim restringir o acesso de uma camada somente com as camadas diretamente interligadas (TOBALDINI, 2007).

• Cache: Segundo Lima (2012), a arquitetura cache evita desperd´ıcio de banda, pois armazena os dados que não sofrem constante alterações na máquina do cliente, e quando estes dados são solicitados, comparam-se os dados presentes na máquina do cliente com o servidor (este procedimento pode ser feito por meio de comparação de hash). Caso estes sejam idênticos pode-se determinar que não houve alteração e assim utilizar os dados presentes na máquina do cliente, caso contrário deve-se baixar os dados atualizados do servidor. Esta arquitetura provem diversas vantagens, como diminuição de transferências de arquivos, e maior performance, já que o servidor fica menos carregado (FIELDING, 2000).

• Sem Estado: Na arquitetura sem estado, o servidor não possui nenhuma informação de contexto, toda requisição ao servidor deve conter as informações necessárias para aquela requisição. Dessa forma o servidor não precisa lidar com diversos contextos (estados), levando em conta o contexto atual para tomar suas decisões, isso o torna mais simples (FIELDING, 2000).

(25)

2.4.2.3 Comparac¸˜ao entre SOAP e REST

Segundo Lima (2012), as principais vantagens e desvantagens do REST sobre o SOAP s˜ao:

• Vantagens

– Utiliza todos os m´etodos do HTTP, como por exemplo, GET, POST, PUT, DELETE, dentre outros. J´a o SOAP utiliza somente o POST;

– É muito trabalhoso criar uma interface WSDL e UDDI que o SOAP necessita; – Não é necessário utilizar mensagens formatadas em XML, trazendo melhor

performance em redes mais lentas; – Curva de aprendizado menor. • Desvantagens

– Ocupa somente o protocolo HTTP ao contr´ario do SOAP que pode ser transportado em qualquer protocolo, como por exemplo: HTTP, SMTP, TCP, etc;

– Os conceitos sobre transação são melhores especificados para o protocolo SOAP.

2.5 DESENVOLVIMENTO PARA DISPOSITIVOS M ´OVEIS

Conforme Oliveira (2011), com a necessidade de agilizar a comunicação, foram desenvolvidos vários equipamentos, como por exemplo, o telefone, que ao longo dos anos foi aprimorado. No ano de 1947 as companhias Bell e AT&T criaram o primeiro sistema telefônico de alta capacidade, interligado por diversas antenas, que além de proporcionar agilidade na comunicação, também fornecia mobilidade ao usuário.

O computador surgiu e evoluiu seguindo a mesma ideologia dos telefones, e em 1980 o primeiro computador port´atil (notebook) foi apresentado, pesando aproximadamente doze quilogramas, j´a nos dias atuais estes dispositivos podem chegar a pesar menos de dois quilogramas.

A evolução dos telefones e computadores acarretou nos smartphones, os quais possuem diversas funcionalidades e aplicações (OLIVEIRA, 2011).

Para ter essas funcionalidades ´e primordial um sistema que gerencie os recursos de hardware, para tanto foram desenvolvido diversos sistemas operacionais, tais como, Android,

(26)

Windows Phone, iOS, dentre outros. Segundo Kantar Worldpanel (2016), o SO Android detém 92,4% do marcado Brasileiro e é o mais utilizado mundialmente, tendo isso em vista, ele será melhor explanado.

2.5.1 Sistema Operacional Android

Conforme Bordin (2012), Android é um sistema operacional baseado em Linux, otimizado para dispositivos móveis, desenvolvido pelo Open Handset Alliance, liderada pela Google. A linguagem de programação padrão de aplicativos para Android é Java, utilizando o Android Software Development Kit(SDK), porém o mesmo possui suporte para as linguagens C e C++, por meio do Android Native Development Kit (NDK).

Para um melhor entendimento de como o sistema operacional Android é estruturado, na Figura 4 é mostrada sua arquitetura. Para um desenvolvimento de aplicações mais robustas e de alto n´ıvel é necessário conhecer todas as camadas do sistema, podendo assim tirar maior proveito das vantagens que elas oferecem (PASSOS, 2009).

As camadas da arquitetura do sistema operacional Android s˜ao kernel linux, bibliotecas, runtime Android, framework nativo e aplicativos:

• Kernel Linux: O Kernel Linux é utilizado para abstrair toda parte de hardware, realizando todos os serviços que o núcleo de um sistema operacional deve realizar como segurança, gerenciamento de memória, gerenciamento de processos, rede, drivers, entre outros. Vale ressaltar que foram feitas melhorias no kernel visando um melhor desempenho em dispositivos móveis (PASSOS, 2009);

• Bibliotecas: A camada das bibliotecas foi totalmente escrita em C e C++, as principais bibliotecas do Android são o Bionic Libc o qual foi desenvolvido pensando na otimização para sistemas embarcados e possui uma implementação um pouco diferente do Libc encontrado em sistemas Linux, como o Fedora, o WebKit que é um engine de browser o qual faz o processo de renderização das páginas web para apresentar no navegador, o Media Framework baseado no pacote de v´ıdeos OpenCore responsável por oferecer o suporte a diversos tipos de arquivos de m´ıdia e o SQLite, um banco de dados otimizado para dispositivos móveis (PASSOS, 2009);

• Runtime Android: Componente que permite executar programas complexos com memória, bateria e processamento limitado. O ambiente de execução é composto

(27)

Figura 4 – Arquitetura do Sistema Android Fonte: Adaptado de Bordin (2012)

pela máquina virtual Dalvik a qual oferece a portabilidade dos aplicativos para diversos aparelhos distintos. Porém estas aplicações devem estar no formato DEX (Dalvik Executable), ou seja, caso seja necessário executar alguma aplicação Java, esta primeiramente será convertida em DEX. Além da máquina virtual existem as core librariesas quais oferecem para DEX as mesmas funcionalidades básicas dispon´ıveis em Java. (PASSOS, 2009);

• Framework Nativo: Totalmente escrito em Java, um framework visa facilitar e aumentar a produtividade no desenvolvimento por meio de re-utilização de código. No Android existem implementações para localização e telefonia dentre várias outras que podem ser visualizadas na Figura 4, estas funcionam como uma API (Application Programming Interface) a qual pode ser utilizada nas aplicações (PASSOS, 2009);

• Aplicativos: O Android funciona com diversas aplicações em seu core (núcleo), incluindo calendário, mapas, navegador, contatos, entre outros. Além destas aplicações nativas nesta camada também executam as aplicações de terceiros, vale ressaltar que todas estas aplicações são escritas em Java (PASSOS, 2009).

(28)

2.6 TECNOLOGIAS E FERRAMENTAS

Diversas tecnologias e ferramentas podem ser utilizadas em projetos de software, visando tornar-los mais robustos e confiáveis, pois pode-se utilizar tecnologias e ferramentas amplamente difundidas e testadas diminuindo assim a probabilidade de bugs. Além disso, facilitam o desenvolvimento em alguns aspectos os quais serão citados em cada item desta seção.

2.6.1 Java

Java é uma linguagem de programação orientada a objetos, projetada para ter diversas dependências, não sendo necessário re-implementar um módulo que já foi implementado uma vez, tendo em vista que este possui interfaces oferecidas e requeridas genéricas. Além disso, é poss´ıvel executar a aplicação em qualquer máquina, independente de seu hardware e sistema operacional, desde que a mesma possua o JRE (Java Runtime Enviroment), que funciona praticamente como uma máquina virtual para rodar aplicações desenvolvidas em linguagem Java (GOSLING et al., 2000). É importante ressaltar que existem diferentes plataformas nesta linguagem, as quais são JSE (Java Standard Edition), JEE (Java Enterprise Edition) e JME (Java Micro Edition):

• JSE: É a base das outras plataformas e também a mais utilizada, pois seu uso é voltado para computadores pessoais e servidores. Esta plataforma contém todos os requisitos necessários para desenvolver em linguagem Java (GOSLING et al., 2000).

• JEE: Foi desenvolvida pensando em comunicação, voltada para internet, intranet, conexão com banco de dados, dentre outros. Além de possuir todas as funcionalidades da JSE, a JEE detêm bibliotecas para acesso a banco de dados, servidores web e diversas outras aplicações baseadas em rede (GOSLING et al., 2000).

• JME: Uma versão mais compacta e utilizada em desenvolvimento de aplicações para dispositivos móveis, anteriores aos smartphones, tendo em vista que a capacidade de processamento e armazenamento destes dispositivos era bem reduzida, quando comparados com um computador (GOSLING et al., 2000).

(29)

Além das diversas plataformas, a linguagem Java utiliza diversos frameworks, visando facilitar o desenvolvimento, pois eles podem ser entendidos como módulos desenvolvidos de forma genérica possibilitando adapta-los para o fim desejado. Dentre os diversos frameworks pode-se citar o VRaptor.

2.6.2 VRaptor

Segundo Freire e Silveira (2004), o VRaptor é um framework MVC (Model, View, Controller) para web, que oferece uma biblioteca com um conjunto de classes para auxiliar o desenvolvimento, rápido e simples, de aplicações baseadas em MVC, além de facilitar a manutenção do código. Para que isso ocorra algumas boas práticas são aplicadas, como injeção de dependências e REST (Transferência de Estado Representacional), VRaptor é um framework de iniciativa brasileira com código aberto e documentação em português, atualmente mantido pela Caelum4, porém pelo fato de ser um projeto de código aberto, o mesmo conta com o apoio de uma extensa comunidade em seu desenvolvimento. É poss´ıvel visualizar vários tutoriais e exemplos no site5do VRaptor na aba “Documentação”.

“O framework VRaptor é um controlador MVC desenvolvido por alunos da Universidade de São Paulo (USP) para web focado no desenvolvimento ágil. Através da inversão de controle e injeção de dependências, ele elimina o tempo de trabalho que seria perdido com o código repetitivo: validações, conversões, direcionamentos e lookups (ANTONIO; FERRO, 2009).”

Ainda segundo Antonio e Ferro (2009), “Ele se adapta perfeitamente para trabalhar com o JSP (JavaServer Pages) na camada de apresentação e com o Hibernate na persistência. Totalmente baseado em anotações do Java 5.0. As anotações garantem uma maneira simples de trabalhar com programação para a web.”

4_{Caelum é uma instituição que oferece diversos cursos em áreas relacionadas a desenvolvimento de sistemas} 5_{Dispon´ıvel em http://www.vraptor.org/pt/docs/guia-de-1-minuto/}

(30)

2.6.3 Maven

Para Dias e Junior (2013), o Maven é uma ferramenta que visa automatizar a compilação em projetos da linguagem Java. Maven é constru´ıdo utilizando uma arquitetura baseada em plug-ins, isso permite o uso de qualquer aplicação controlável por meio da entrada padrão. Algumas das principais vantagens de se usar o Maven, são estruturas padronizadas de diretório, arquitetura de plug-ins, gerenciamento de dependências e gerenciamento de escopo (MARTINS, 2009).

• Estrutura Padronizada de Diret´orio: Todos projetos que fazem uso do Maven possuem a mesma estrutura de projeto.

• Arquitetura Plug-in: As funções do Maven são efetuadas por plug-ins, assim quando o projeto é testado ou utilizado pela primeira vez, o Maven faz o download dos plug-ins necessários automaticamente e os armazena em um repositório comum.

• Gerenciamento de Dependências: Quando alguma dependência for descrita no arquivo de configuração XML (pom.xml) do Maven, ela será acessada de um repositório local caso já tenha sido feito o download da mesma, caso contrário, será feito o download e armazenado no repositório local.

• Gerenciamento de Escopo: O pacote final de distribuição contém somente os arquivos necessários, deixando de fora os arquivos referente aos códigos de teste, e dependências não utilizadas ou desnecessárias para o pacote final.

2.6.4 Raspbian Wheezy

Raspbian Wheezy é um SO otimizado para o hardware do Raspberry Pi, Raspbian Wheezy foi baseado em Debian e conta com mais de 35 mil pacotes. A construção inicial destes pacotes foi terminado em junho de 2012, porém continua em atualização constante, visando disponibilizar a maior quantidade poss´ıvel de pacotes para o sistema operacional Raspbian Wheezy. Este SO é recomendado para a maioria dos usuários de Raspberry Pi, a única exceção é para os usuários dependentes de software ainda não presente ou funcional do Raspbian Wheezy (BARROS, 2013).

(31)

2.6.5 Ambiente de Desenvolvimento Integrado

O ambiente de desenvolvimento integrado, conhecido pelo acrônimo do inglês IDE é um ambiente utilizado para aumentar a produtividade dos desenvolvedores de software, porém segundo Boudreau et al. (2002), o intuito do IDE não é tornar a programação fácil, pois isso depende da habilidade do programador. No desenvolvimento deste projeto foram utilizados três IDEs, o NetBeans, o Android Studio e o Arduino Software.

• NetBeans: Para Boudreau et al. (2002), NetBeans ´e um projeto open source criado pela Sun Microsystem, que pode ser utilizado para aumentar o desempenho no momento de programar em linguagens como Java, C, C++, PHP, dentre outras. Este IDE foi utilizado no desenvolvimento de todo sistema embarcado, desde a parte de sensores e atuadores at´e o web service;

• Android Studio: Segundo Barros (2013), Android Studio é um ambiente de desenvolvimento para Android, baseado no IntelliJ IDEA. O IDE foi anunciada em 16 de maio de 2013 na conferência Google I/O e disponibilizado a versão beta em julho de 2013. O Android Studio foi utilizado para desenvolver a aplicação mobile que realiza o gerenciamento e controle do sistema embarcado;

• Arduino Software: utilizado para desenvolvimento de sketch’s Arduino os quais são baseados em linguagem Wiring. Estes sketch’s são posteriormente compilados em código de máquina para o Arduino.

2.6.6 JSON

De acordo com ECMA International (2013), JSON (JavaScript Object Notation) foi derivado da linguagem ECMAScript e consiste em uma estrutura de dados, está estrutura é composta por pares (chave-valor), separados um do outro por virgula, todos estes dados ficam dentro de chaves. JSON tem grande semelhança com XML, porém, é mais leve por ter uma estrutura mais simples, tendo isso em vista, ele é utilizado em várias aplicações nas quais é necessário transmitir dados pelo protocolo HTTP, porém não se restringindo somente a essa função. A Figura 5 mostra uma mensagem no formato JSON, na qual "usuario" é uma chave e "reichert" é o valor associado a esta chave, logo após, têm-se uma virgula separando o

(32)

pr´oximo par chave("senha")-valor(123456).

Figura 5 – Mensagem no Formato JSON Fonte: Autoria Pr´opria

(33)

3 MATERIAL E M ´ETODOS

Com o intuito de desenvolver um sistema de automação residencial, proporcionando comodidade e segurança, foi implementado um sistema de automação residencial embarcado no Raspberry Pi, responsável pelo controle do Arduino. E neste, estão ligados os sensores para coleta de informações (tais como temperatura, umidade e poss´ıveis intrusões) e atuadores os quais realizam alguma tarefa espec´ıfica (tais como acionar uma lâmpada, ligar a irrigação ou ligar uma televisão).

Esse sistema foi desenvolvido em linguagem Java, utilizando o IDE (Ambiente de Desenvolvimento Integrado) Netbeans. O sistema comporta também um web service REST o qual foi utilizado o framework VRaptor para construção. Este web service possibilita a comunicação com qualquer cliente, porém para demonstração foi desenvolvido um aplicativo Android com a IDE Android Studio, espec´ıfico para consumir os dados deste serviço na web.

As próximas seções detalham melhor cada uma das tecnologias e seus procedimentos de aplicação.

3.1 ARQUITETURA DO SISTEMA

A arquitetura do sistema é composta pelo Raspberry Pi, Arduino, sensores, atuadores e usuários (smartphone, desktop e website), uma listagem completa dos periféricos utilizados no sistema de automação pode ser visualizada no Apêndice A. O sistema de automação residencial foi embarcado no Raspberry Pi o qual é responsável por monitorar as requisições dos usuários e controlar os pinos GPIO do Arduino, onde estão ligados os sensores e atuadores. Mantém ainda as credenciais dos usuários, poss´ıveis agendamentos e disponibiliza uma interface de comunicação baseada em web service REST para troca de informações por meio do protocolo HTTP entre o Raspberry Pi e os usuários.

(34)

3.1.1 Diagrama de Implantac¸˜ao

O diagrama de implantação representado na Figura 6 demonstra a arquitetura básica do sistema, a qual foi sub-dividida em 3 categorias, visando melhor entendimento do sistema como um todo.

Figura 6 – Diagrama de Implantação Fonte: Autoria Própria

3.1.2 Requisitos do Sistema

O sistema atende os seguintes RF (Requisitos Funcionais): • RF1 - Controlar Iluminac¸˜ao (Interna e Externa);

• RF2 - Controlar Irrigac¸˜ao do Jardim;

• RF3 - Gerenciar Agendamentos (Iluminação e Irrigação); • RF4 - Monitorar Temperatura e Umidade do Ambiente; • RF5 - Controlar Sensores de Intrusão;

• RF6 - Controlar Equipamentos por meio de Infra-Vermelho (ar condicionado, televis˜ao, etc.);

(35)

• RF7 - Disponibilizar Sistema de Alarme (sirene, notificac¸˜ao no smartphone, etc.).

3.2 EQUIPAMENTOS

Em relação ao conjunto de hardware, foram utilizados para desenvolvimento do sistema, um notebook Acer modelo Aspire 4752 com processador Intel i5 e 4GB de memória RAM, para teste em dispositivo móvel o smartphone Blue Studio Energy 2 com Android versão 5.0, Roteador Wireless TP-Link, Raspberry Pi 2 Modelo B, Arduino Mega 2560, fonte de alimentação de 5 volts Micro USB (Universal Serial Bus), sensores e atuadores além de fios e dispositivos encontrados em uma residência, como televisão, home theater, lâmpadas, sistema de irrigação e eletrodomésticos em geral.

3.2.1 Sensores

Sensores s˜ao dispositivos utilizados para coletar dados, como por exemplo, temperatura, umidade, identificar movimentos, imagens dentre outros.

• Sensor de Umidade e Temperatura DHT11: Conforme (D-Robotics UK, 2015), o sensor DHT11 que pode ser visualizado na Figura 7(a), é capaz de medir a temperatura e umidade de um ambiente com grande precisão, de forma rápida e com baixo custo de aquisição. Este sensor consegue medir a umidade dentro de uma variação de 20-90%RH (Umidade Relativa - Relative Humidity) com precisão de ±5% e a temperatura entre 0-50oC com precisão de ±2oC.

(36)

(a) Sensor (b) Aplicac¸˜ao T´ıpica

Figura 7 – Sensor de Umidade e Temperatura DHT11 Fonte: Adaptado de D-Robotics UK (2015)

Conforme pode ser observado na Figura 7(a), o sensor possui 4 pinos. Porém foi utilizado somente 3 deles, o pino 1 para a alimentação, o pino 2 para coleta de dados por parte do Arduino e o pino 4 para o neutro (GND). Vale ressaltar que o pino 2 deve estar ligado a um resistor de 5K Ohms e na alimentação conforme Figura 7(b);

• Sensor de Movimento/Presença PIR: O sensor PIR consegue detectar movimentação em um ambiente, ele basicamente é composto por um sensor pyroelectric que pode ser visualizado na Figura 8(a), resistores, capacitores, potenciômetros para ajuste de sensibilidade, um BISS0001 (CI de detecção de movimento PIR de baixa potência) e 3 pinos, dos quais um é a alimentação, um o neutro e o outro de dados, estes por sua vez podem ser observados na Figura 8(b) (ADAFRUIT, 2015).

(a) Frente (b) Verso

Figura 8 – Sensor de movimento/presenc¸a PIR Fonte: Adaptado de Adafruit (2015)

(37)

3.2.2 Atuadores

Atuadores são dispositivos que realizam alguma ação, como por exemplo, sirene, motor, emissor infravermelho, relé e outros.

• Módulo Relé: O módulo relé visto na Figura 9, é composto por diversos componentes, como transistores, conectores, LED’s, diodos e relés. Cada relé possui um LED o qual indica se o mesmo está acionado. Quando energizado um pino com 5v o relé comuta o seu circuito interno e deixa a energia passar em seu lado oposto, o qual suporta 250/125V AC (Corrente Alternada) ou 30/28V DC (Corrente Cont´ınua) ambos com intensidade de corrente máxima de 10A (FILIPEFLOP, 2015).

Figura 9 – M´odulo rel´e com 2 canais Fonte: Filipeflop (2015)

Este m´odulo foi utilizado para possibilitar o acionamento de dispositivos que necessitam corrente e/ou tens˜ao maior que o suportado pelos pinos GPIO do Arduino;

• LED Emissor Infravermelho: O LED emissor infravermelho é necessário para simular o controle remoto de dispositivos que possuem um receptor infravermelho, este LED emite sinais de luz da mesma forma que o controle original do dispositivo. Dessa forma é poss´ıvel controlar estes dispositivos sem qualquer tipo de modificação f´ısica. Para realizar tal procedimento primeiramente deve-se ler as funções do controle remoto original, que basicamente é composto por diversos pulsos de luz infravermelho, depois de ter lido a sequência emitida pelo controle original, basta emitir esta mesma sequência com o Arduino;

• Sirene: Sirene é um dispositivo que emite uma frequência sonora, tendo isso em vista a sirene foi utilizada em conjunto com o sistema de segurança visando alertar quando houver algum incidente;

(38)

enrolado em um cilindro. Ao aplicar uma certa corrente elétrica que varia em diversos modelos, é gerado uma força na bobina solenoide e consequentemente o pino que está trancando a passagem da água é puxado para o centro da bobina permitindo a passagem da água, como pode ser visto na Figura 10(a).

Quando a bobina solenoide estiver sem energia o pino n˜ao permite que a ´agua passe, conforme Figura 10(b).

(a) Aberta (b) Verso

Figura 10 – Solenoide

Fonte: Adaptado de Manutenc¸˜ao & Suprimentos (2015)

Está válvula foi utilizada para controlar a irrigação, possibilitando liberar e cessar a passagem da água de forma automática.

3.3 SISTEMA EMBARCADO

O sistema embarcado foi implantado no Raspberry Pi 2 Modelo B, que pode ser visto na Figura 11, e realiza o controle do Arduino o qual aciona e monitora os sensores (DHT11 e PIR) e os atuadores (módulo relé, emissor infravermelho e sirene) por meio da linguagem Java, atendendo todos os requisitos do sistema. Além deste controle o sistema embarcado disponibiliza uma interface de comunicação genérica baseada em web service REST, com o framework VRaptor oferecendo simplicidade e praticidade caso haja necessidade futura de outras plataformas para o controle por parte do usuário.

(39)

Figura 11 – Raspberry Pi 2 - Modelo B Fonte: Raspberry Pi Foundation (2015)

3.4 SISTEMA CONTROLADOR

O sistema controlador consiste no acionamento e leitura de sensores efetuados pelo Arduino. Ele simplesmente cumpre ordens do sistema embarcado (Raspberry Pi), por exemplo, o sistema embarcado ordena ao sistema controlador para mudar o status do pino 10 para HIGH (ligado) e o controlador mesmo sem saber o que ele está acionando, executa o comando solicitado. Esta comunicação com o sistema embarcado é feita via serial, para o qual foi concebido um protocolo de comunicação possibilitando que ambos possam se comunicar sem confusão na identificação das mensagens enviadas/recebidas.

Este protocolo de comunicação consiste em informações separados pelo caractere -, na Figura 12, é poss´ıvel observar uma mensagem enviada do sistema embarcado ao sistema controlador, pode-se identificar qual a ordem em que os dados estão dispostos na mensagem.

Figura 12 – Protocolo de Comunicação Serial Fonte: Autoria Própria

Sendo que na primeira posição é informado o tipo de pino, que pode ser digital (1), emissor infravermelho (2), sensor (3) ou receptor infravermelho (4), já a segunda posição do protocolo representa a localização f´ısica do pino no sistema controlador, a ação informa se será

(40)

ligado (1) ou desligado (0), ou seja, se o pino será configurado em HIGH ou LOW caso ele seja digital. Por fim, a quarta e última posição contém os dados necessários em um acionamento por infravermelho, estes dados também possuem um separador.

Na Figura 13, é poss´ıvel observar os dados de uma solicitação de acionamento por infra-vermelho, o primeiro campo representa a codificação que será utilizada para emitir os pulsos, o segundo campo contém o código em hexadecimal dos pulsos, já a terceira posição informa a taxa de bits a ser utilizada e a quarta posição traz os pulsos em si, este último campo não foi mostrado por completo pois o mesmo contém em torno de 243 números para uma requisição de acionamento infra-vermelho de um ar condicionado.

Figura 13 – Dados do Protocolo de Comunicação Serial Fonte: Autoria Própria

3.5 APLICAC¸ ˜AO ANDROID

A aplicação Android disponibiliza ao usuário a interface gráfica, para gerenciamento e controle do sistema embarcado. Esta aplicação funciona como um controle remoto universal ao qual o usuário terá acesso a todos os dispositivos ligados ao sistema de automação residencial, tudo isso pode ser feito estando na residência ou em qualquer lugar do planeta, desde que haja conexão com a internet e IP (Internet Protocol) público na residência. Já no dispositivo que está executando a aplicação do usuário, basta ter acesso a internet. As telas do sistemas assim como sua respectiva funcionalidade são apresentados no Cap´ıtulo 4.

(41)

3.6 SISTEMA DE AUTOMAC¸ ˜AO RESIDENCIAL

Para melhor visualização de como o sistema de automação residencial completo funciona, nesta seção é demonstrado um exemplo de acionamentos e o que acontece no sistema após o usuário fazer uma requisição. A Figura 14, mostra o diagrama de sequência que representa a comunicação dentre as diversas partes do sistema quando o usuário solicita que uma lâmpada X seja ligada.

Figura 14 – Diagrama de Sequencia - Ligando uma Lˆampada X Fonte: Autoria Pr´opria

Já a Figura 15, representa a instalação f´ısica dos componentes para que este exemplo possa ser executado.

Figura 15 – Instalação F´ısica - Acionamento de uma Lâmpada Fonte: Autoria Própria

(42)

Quando o usuário abre a listagem de dispositivos, é realizado uma requisição para o sistema embarcado, conforme Código 1, com o comando descrito na linha 1, e o retorno desta requisição é convertido para um ArrayList<Pino> na linha 3.

1 S t r i n g r e t o r n o = new H t t p C o n n e c t i o n () . e x e c u t e (" h t t p :// " + s e r v i d o r + " / tcc / p i n o s ", H t t p C o n n e c t i o n . GET ) . get () ; 2

3 List < Pino > p i n o s = H t t p C o n n e c t i o n . g s o n . f r o m J s o n ( retorno , new T y p e T o k e n < A r r a y L i s t < Pino > >() {}. g e t T y p e () ) ;

Código 1 – Requisição de pinos para o sistema embarcado Fonte: Autoria Própria

Já no sistema embarcado está solicitação é recebida no método do Código 2.

1 @ G e t (" / p i n o s ") 2 p u b l i c v o i d g e t A l l P i n s () { 3 try { 4 r e s u l t . use ( R e s u l t s . j s o n () ) . w i t h o u t R o o t () . f r o m ( p i n o D B . g e t A l l () ) . s e r i a l i z e () ; 5 r e s u l t . use ( R e s u l t s . h t t p () ) . s e t S t a t u s C o d e ( 2 0 0 ) ; 6 } c a t c h ( E x c e p t i o n ex ) { 7 ... 8 } 9 }

Código 2 – Método do sistema embarcado para retornar todos os pinos Fonte: Autoria Própria

Os dados s˜ao recuperados de um arquivo de texto no formato JSON e transformados em um ArrayList<Pino> (C´odigo 3): 1 p u b l i c A r r a y L i s t < Pino > g e t A l l () t h r o w s F i l e N o t F o u n d E x c e p t i o n { 2 A r r a y L i s t < Pino > l i s t P i n o s ; 3 F i l e R e a d e r r e a d F i l e = new F i l e R e a d e r ( p a t h + " p i n o s . j s o n ") ; 4 l i s t P i n o s = g s o n . f r o m J s o n ( r e a d F i l e , new T y p e T o k e n < A r r a y L i s t < Pino > >() {}. g e t T y p e () ) ; 5 r e t u r n l i s t P i n o s ; 6 }

C´odigo 3 – Recuperando todos os dispositivos cadastrados e persistidos no arquivo de texto Fonte: Autoria Pr´opria

(43)

Após estes dados terem sidos retornados para a aplicação mobile, eles serão filtrados de acordo com a categoria que o usuário selecionar. Seguindo o exemplo citado anteriormente será mostrado somente os dispositivos da categoria Ilumina¸c~ao, o C ódigo 4 mostra como isso é realizado.

1 Map < Integer , A r r a y L i s t < Pino > > d a d o s = new HashMap < >() ; 2 d a d o s . put ( C a t e g o r i a . I L U M I N A C A O , new A r r a y L i s t < Pino >() ) ; 3 4 for ( P i n o p : p i n o s ) { 5 s w i t c h( p . g e t C a t e g o r i a () ) { 6 c a s e C a t e g o r i a . I L U M I N A C A O : 7 d a d o s . put ( C a t e g o r i a . I L U M I N A C A O , d a d o s . get ( C a t e g o r i a . I L U M I N A C A O ) ) . add ( p ) ; 8 b r e a k; 9 } 10 } 11 12 s w i t c h ( t e l a ) { 13 c a s e C a t e g o r i a . I L U M I N A C A O : 14 t e x t o . s e t T e x t (" I l u m i n a ¸c ~a o ") ; 15 l i s t v i e w . s e t A d a p t e r (new P i n o V i e w A d a p t e r ( M a i n A c t i v i t y . g e t A p p C o n t e x t () , d a d o s . get ( C a t e g o r i a . I L U M I N A C A O ) ) ) ; 16 b r e a k; 17 }

Código 4 – Filtrando os dispositivos retornados conforme solicitado pelo usuário Fonte: Autoria Própria

Após executar o método setAdapter do listview passando por parâmetro um novo PinoViewAdapter, o listview será populado com os dispositivos, seguindo o modelo definido no método getView da classe PinoViewAdapter que pode ser visualizado no Código 5, mostrando um ´ıcone referente ao status do dispositivo, o qual possui a cor verde caso o dispositivo esteja ligado e vermelho caso esteja desligado. Além do ´ıcone, é mostrado a descrição do dispositivo. 1 @ O v e r r i d e 2 p u b l i c V i e w g e t V i e w (int p o s i t i o n , V i e w c o n v e r t V i e w , V i e w G r o u p p a r e n t ) { 3 ... 4 I m a g e V i e w img = ( I m a g e V i e w ) vi . f i n d V i e w B y I d ( R . id . i m g L i s t V i e w P i n o ) ;

(44)

5 if( d a t a . get ( p o s i t i o n ) . i s L i g a d o () ) { 6 img . s e t I m a g e R e s o u r c e ( R . m i p m a p . on ) ; 7 } e l s e { 8 img . s e t I m a g e R e s o u r c e ( R . m i p m a p . off ) ; 9 } 10 T e x t V i e w t e x t = ( T e x t V i e w ) vi . f i n d V i e w B y I d ( R . id . t x t L i s t V i e w P i n o ) ; 11 t e x t . s e t T e x t ( d a t a . get ( p o s i t i o n ) . g e t D e s c r i c a o () ) ; 12 13 r e t u r n vi ; 14 }

Código 5 – Listando os dispositivos da categoria ilmunição com seus respectivos status Fonte: Autoria Própria

Por fim o usuário verá no aplicativo uma tela parecida com a Figura 20(a), onde é poss´ıvel ver todos os dispositivos da categoria Ilumina¸c~ao cadastrados no sistema embarcado. Ao clicar sobre um dispositivo será realizada a requisição do Código 6 na aplicação Android.

1 new H t t p C o n n e c t i o n () . e x e c u t e (" h t t p :// "+ s e r v i d o r +" / tcc / p i n o /

u p d a t e ", H t t p C o n n e c t i o n . POST , H t t p C o n n e c t i o n . g s o n . t o J s o n ( p i n o ) ) ;

Código 6 – Requisição para alterar o status do dispositivo selecionado Fonte: Autoria Própria

O sistema embarcado recebe a solicitação no método do Código 7.

1 @ P o s t (" / p i n o / u p d a t e ") 2 @ C o n s u m e s ( v a l u e = M e d i a T y p e . A P P L I C A T I O N _ J S O N , o p t i o n s = W i t h o u t R o o t .c l a s s) 3 p u b l i c v o i d u p d a t e ( P i n o p i n o ) { 4 try { 5 p i n o D B . u p d a t e ( p i n o ) ; 6 s w i t c h ( p i n o . g e t C a t e g o r i a () ) { 7 ... 8 c a s e C a t e g o r i a . D I G I T A L : 9 S e r i a l P o r t F a c t o r y . g e t I n s t a n c e () . g e t S e r i a l P o r t () . w r i t e S t r i n g ( p i n o . g e t T i p o () + " - " + p i n o . g e t P o s i c a o () + " - " + p i n o . i s L i g a d o () + " - " + p i n o . g e t D a d o s () ) ;

(45)

10 b r e a k;

11 }

12 }

13 ...

14 }

Código 7 – Método no sistema embarcado que recebe a solicitação de atualização Fonte: Autoria Própria

O m´etodo update da classe PinoDAO pode ser visualizado no C´odigo 8.

1 p u b l i c v o i d u p d a t e ( P i n o p ) t h r o w s F i l e N o t F o u n d E x c e p t i o n { 2 List < Pino > l i s t P i n o s = g e t A l l () ; 3 l i s t P i n o s . set ( l i s t P i n o s . i n d e x O f ( p ) , p ) ; 4 5 S t r i n g j s o n = g s o n . t o J s o n ( l i s t P i n o s ) ; 6 try { 7 F i l e W r i t e r w r i t e F i l e = new F i l e W r i t e r ( p a t h + " p i n o s . j s o n ") ; 8 w r i t e F i l e . w r i t e ( j s o n ) ; 9 w r i t e F i l e . c l o s e () ; 10 } c a t c h ( I O E x c e p t i o n e ) { 11 ... 12 } 13 }

C´odigo 8 – Atualizar o status do dispositivo no arquivo de texto Fonte: Autoria Pr´opria

Após atualizar o dispositivo no arquivo de texto localizado no sistema embarcado, e solicitar ao sistema controlador para que seja alterado o status do pino, ligando a lâmpada, é retornado para aplicação Android que ocorreu tudo bem e o usuário recebe uma notificação que a lâmpada foi ligada.

(46)

4 RESULTADOS EXPERIMENTAIS

Tendo em vista que todos os requisitos do sistema foram atendidos com ˆexito. Optou-se por montar uma maquete (Figura 16), e realizar testes de deOptou-sempenho e usabilidade visando ter resultados mais palp´aveis quanto ao funcionamento do sistema.

Figura 16 – Maquete Utilizada para Experimentos Fonte: Autoria Pr´opria

A aplicação desenvolvida para plataforma Android tem um visual a contento e funcional, a seguir serão demonstradas as principais telas e suas funcionalidades.

No menu de configuração do sistema que pode ser acessado no botão destacado na Figura 17(a), têm-se dois itens: adicionar dispositivo e alterar senha, que podem ser vistos na Figura 17(b).

Ao clicar na opção adicionar dispositivo, é aberto uma nova tela para cadastrá-los (18), nesta tela são solicitadas informações das quais algumas são utilizadas somente em casos espec´ıficos. O item A é a descrição do dispositivo, esta será utilizada para posterior identificação do mesmo, o item B é referente ao pino que este dispositivo está ligado fisicamente no sistema controlador, o item C traz algumas opções de tipos de dispositivos, os quais são: Sensor, Infra-vermelho e Digital, deve-se selecionar a opção correspondente ao dispositivo que está sendo

(47)

(a) Acessando as Configurac¸˜oes

(b) Opções de Configuração

Figura 17 – Configurações da Aplicação Android Fonte: Autoria Própria

cadastrado. O item D é ativado somente caso no item C for selecionado a opção Infra-vermelho, pois é necessário informar o padrão de pulsos do equipamento que está sendo cadastrado, já o item E é acionado caso no item C for escolhido a opção Digital, neste caso é facultativo informar em qual pino do sistema controlador está ligado o interruptor f´ısico para o dispositivo. Por fim, o item F representa a categoria do dispositivo, existem cinco categorias, as quais são: Ar Condicionado, Iluminação, Irrigação, Multim´ıdia e Outros, está categoria será utilizada para organizar os dispositivos na aplicação do usuário.

Já ao clicar em alterar senha é aberto a tela (Figura 19(a)), na qual é poss´ıvel alterar a senha de acesso ao sistema, é necessário digitar a senha antiga, uma nova senha e a confirmação desta nova senha. A senha será alterada somente caso a senha antiga esteja correta e a senha nova e confirmação estejam iguais.

Na Figura 19(b), é mostrado a aba principal da aplicação. Na marcação A, pode-se ativar/desativar o pode-sensor de prepode-sença e a sirene do alarme. Na marcação B, é poss´ıvel observar o endereço do servidor ao qual está conectado atualmente. Além disso, na marcação C, têm-se acesso aos sub-menus referente ao seguintes módulos: Iluminação, Multim´ıdia, Ar Condicionado, Irrigação, Outros e Segurança. Por fim, a marcação D mostra o botão para fazer logout.

Para ser mais fácil entender o funcionamento da aplicação, é interessante visualizar o funcionamento de cada um dos sub-menus citados anteriormente. É importante ressaltar que

(48)

Figura 18 – Cadastrando Dispositivo pela Aplicação Android Fonte: Autoria Própria

(a) Alterando a Senha (b) Aba com o Menu Principal

Figura 19 – Telas da Aplicação Android Fonte: Autoria Própria

ao adentrar cada um dos sub-menus, à aplicação solicita os equipamentos daquela categoria ao sistema embarcado, e este por sua vez, retorna os dispositivos.

• Iluminação: ao acessar o sub-menu iluminação, é listado todos os equipamentos desta categoria cadastrados no sistema com o seu status atual, conforme pode ser visto na Figura

(49)

20(a), o dispositivo Lâmpada do Quarto está ligado e o dispositivo Lâmpada da Sala está desligado. Para alterar o status basta clicar sobre o mesmo, conforme Figura 20(b), que será feito uma requisição ao servidor embarcado, alterando o status do dispositivo fisicamente e no arquivo de configuração;

(a) Um dispositivo ligado e outro desligado

(b) Ligando um dispositivo

Figura 20 – Sub-menu Iluminação Fonte: Autoria Própria

• Multim´ıdia: neste sub-menu estão listados os dispositivos de multim´ıdia com seu respectivo status, do mesmo modo que no sub-menu de iluminação. Porém, ao clicar sobre um dispositivo deste sub-menu é aberto uma tela com um controle, idêntico a Figura 21(a), pelo qual é poss´ıvel ter acesso a algumas funções de um controle remoto de um dispositivo de multim´ıdia, tais como volume e canal. Para alterar alguma destas configurações, basta clicar sobre o botão correspondente;

• Ar Condicionado: o sub-menu é bem parecido com o sub-menu multim´ıdia. Porém, a tela do controle remoto é diferente conforme pode ser visto na Figura 21(b), nela fica armazenado todas configurações atuais do dispositivo. Esta diferença ocorre pois o funcionamento do controle remoto do ar condicionado é diferente do controle de algum dispositivo de multim´ıdia. No ar condicionado, toda vez que é enviado algum comando pelo controle, são enviados pulsos para o dispositivo correspondente a todas as configurações vis´ıveis no controle, tais como, modo de funcionamento, temperatura e ligado. Já em um dispositivo multim´ıdia, é enviado somente o comando solicitado, como