UNIVERSIDADE DE PERNAMBUCO

FACULDADE DE CINCIAS E TECNOLOGIA DE CARUARU

BACHARELADO EM SISTEMAS DE INFORMAO

DANIEL ROSENDO

INTEGRANDO FUNCIONALIDADES DO ARDUINO INTERNET ATRAVS DE

RECURSOS WEB

CARUARU

2014

DANIEL ROSENDO

INTEGRANDO FUNCIONALIDADES DO ARDUINO INTERNET ATRAVS DE

RECURSOS WEB

Monografia apresentada ao Curso de Sistemas de

Informao, Faculdade de Cincias e Tecnologia

de Caruaru da Universidade de Pernambuco, como

requisio parcial obteno do ttulo de Bacharel.

Orientadora: Prof. Msc. Patricia Takako Endo

CARUARU

2014

Dedico este trabalho aos meus pais e irmos.

AGRADECIMENTOS

Agradeo primeiramente a DEUS por proporcionar mais uma conquista na minha vida.

Por ter me abenoado a cada dia, por ter me dado sade, sabedoria, fora e pacincia durante

esta longa jornada que durou quatro anos e meio.

Agradeo minha famlia, meu pai (Djalma Rosendo) e minha me (Luzineide

Rosendo) por terem me educado e estarem sempre ao meu lado, cuidando e incentivando.

Agradeo ainda minha me pelas comidas deliciosas que s ela sabe fazer e que me deram

energia para a realizao deste trabalho. Agradeo aos meus irmos (Diomedes e Diogo

Rosendo) pelo apoio.

Agradeo minha grande orientadora Prof. Patricia Takako Endo, pela confiana

depositada e pela disponibilizao, ateno, competncia, pacincia e mensagens

motivacionais.

Agradeo aos meus primos e amigos que me acompanharam nesta jornada e que

contriburam indiretamente com este trabalho.

Por fim, agradeo todos os professores do curso de Sistemas de Informao da UPE

Caruaru, que tiveram um importante papel em minha formao acadmica proporcionando

grande parte do conhecimento necessrio para realizao deste trabalho.

RESUMO

Nos ltimos anos tem-se aumentado a quantidade de objetos inteligentes conectados

Internet. A tendncia que esta quantidade cresa consideravelmente nos anos seguintes. Isto

se deve ao surgimento e popularizao de dispositivos, tais como smartphones, tablets, sensores

sem fio, entre outros. A Web das Coisas utiliza protocolos e padres da Web que permitem a

integrao de objetos fsicos na Web, a fim de obter-se uma representao dos mesmos como

recursos na Web. Desta forma, torna-se possvel acessar e controlar remotamente estes objetos,

como tambm, armazenar, gerenciar e exibir os dados gerados em tempo real por eles. Neste

trabalho ser desenvolvido uma lmpada inteligente construda com hardware Arduino, como

tambm, uma aplicao Web baseado na Web das Coisas para disponibilizao na Web da

lmpada inteligente possibilitando o acesso s funcionalidades da mesma.

Palavras-chave: Internet das Coisas. Web das Coisas. Objetos Inteligentes. API Web. Arduino.

ABSTRACT

In the last years have increased the amount of smart objects connected to the Internet.

The trend is that this number will grow considerably in the following years. This is due to the

emergence and popularization of devices, such as smartphones, tablets, wireless sensors, among

others. The Web of Things uses Web standards and protocols that allow the integration of

physical objects on the Web, in order to obtain a representation of them as Web resources.

Therefore, it becomes possible to remotely access and control these objects, as well, store,

manage and display real-time data generated by them. In this work will be developed a smart

bulb built with Arduino hardware, as well, a Web application based on the Web of Things to

provide access to the smart bulbs functionalities on the Web.

Keywords: Internet of Things. Web of Things. Smart Objects. Web API. Arduino.

LISTA DE FIGURAS

Figura 1 - A Internet de Todas as Coisas rene Pessoas, Coisas, Dados e Processos. Fonte:

CISCO. ..................................................................................................................................... 13 Figura 2 - Tipos de conexes da IoE: M2M, P2M e P2P. Fonte: CISCO. .............................. 14 Figura 3 - A Internet das Coisas surgiu entre os anos de 2008 e 2009. Fonte: Cisco IBSG, 2011.

.................................................................................................................................................. 16 Figura 4 - Pgina Web da representao do objeto fsico na Web. Fonte: Compilado pelo autor.

.................................................................................................................................................. 24 Figura 5 - Requisio HTTP GET para obteno da representao do objeto. Fonte: Criado

pelo autor. ................................................................................................................................. 24

Figura 6 - Tabela de rotas da aplicao para o recurso objetos. Fonte: Elaborado pelo autor.25

Figura 7 - Classe ObjetosController e mtodos especificados no arquivo de configurao de

rotas da aplicao. Fonte: Elaborado pelo autor. ...................................................................... 26

Figura 8 - Requisio HTTP POST que envia os dados do sensor dht11 do Arduino. Fonte:

Criado pelo autor. ..................................................................................................................... 27 Figura 9 - Requisio HTTP PUT enviada ao Arduino para alterar o estado da lmpada. Fonte:

Criado pelo autor. ..................................................................................................................... 27

Figura 10 - Diagrama de classes do pacote controllers da aplicao Web. Fonte: Elaborado

pelo autor. ................................................................................................................................. 30

Figura 11 - Diagrama de classes do pacote models da aplicao Web. Fonte: Elaborado pelo

autor. ......................................................................................................................................... 31 Figura 12 - Principais classes executadas no Arduino Mega 2560. Fonte: Elaborado pelo autor.

.................................................................................................................................................. 32

Figura 13 - Hardware que compe o prottipo. Fonte: Compilado pelo autor. ...................... 34 Figura 14 - Pinos digitais e analgicos Arduino Mega 2560 R3 (imagem feita com Fritzing).

.................................................................................................................................................. 34

Figura 15 - Conectores de alimentao do Arduino Mega 2560 R3 (imagem feita com Fritzing).

.................................................................................................................................................. 35 Figura 16 - Arduino Ethernet Shield R3 (imagem feita com Fritzing). .................................. 37

Figura 17 - Pinos de comunicao do Arduino Mega 2560 com o chip W5100 e micro SD

(imagem feita com Fritzing). .................................................................................................... 37 Figura 18 - Breadboard (imagem feita com Fritzing). ........................................................... 38 Figura 19 - Sensor Shield Verso 4, adaptado de (SEEED, 2014). ......................................... 39 Figura 20 - Mdulo de reconhecimento de voz V2, adaptado de (SHEN, 2014).................... 40 Figura 21 - Mdulo conversor USB-TTL. Fonte: Compilado pelo autor. .............................. 41

Figura 22 - Sensor de temperatura e umidade DHT11, adaptado de (D-ROBOTICS, 2014). 42 Figura 23 - Mdulo Real-Time Clock DS1302, adaptado de (MAXIM, 2014). ..................... 43

Figura 24 - Display LED de 7 segmentos e 4 dgitos com seus respectivos pinos. Fonte:

Compilado pelo autor. .............................................................................................................. 44 Figura 25 - Mdulo rel isolado 5 volts. Fonte: Compilado pelo autor. ................................. 45 Figura 26 - Cabo USB A-B. Fonte: Compilado pelo autor. .................................................... 45 Figura 27 - Cabo de rede Ethernet categoria 5e. Fonte: Compilado pelo autor. ..................... 46

Figura 28 - Cabos fmea-fmea e cabos macho-fmea. Fonte: Compilado pelo autor. .......... 46 Figura 29 - Consumo das diferentes memrias do Arduino Mega 2560. Fonte: Arduino Builder.

.................................................................................................................................................. 48 Figura 30 - Consumo de memria para desempenhar cada funcionalidade da lmpada

inteligente. Fonte: Compilado pelo autor. ................................................................................ 49

Figura 31 - Tempo para executar cada funcionalidade da lmpada inteligente. Fonte:

Compilado pelo autor. .............................................................................................................. 50

LISTA DE ABREVIATURAS E SIGLAS

API Application Programming Interface

ARP Address Resolution Protocol

EEPROM Electrically-Erasable Programmable Read-Only Memory

HATEOAS Hypermedia as Engine Of Application State

HTTP Hipertext Transfer Protocol

I2C Inter-Integrated Circuit

ICMP Internet Control Message Protocol

IDE Integrated Development Environment

IGMP Internet Group Management Protocol

IoT Internet of Things

IP Internet Protocol

IPv4 Internet Protocol version 4

IPv6 Internet Protocol version 6

MEMS Microelectromechanical Systems

MISO Master Input, Slave Output

MOSI Master Output, Slave Input

NTC Negative Temperature Coefficient

OTP One Time Programmable

PPPoE Point-to-Point Protocol over Ethernet

PROM Programmable Read-Only Memory

PWM Pulse Width Modulation

REST Representational State Transfer

RFID Radio Frequency Identification

RH Relative Humidity

ROA Resource-Oriented Architecture

RTC Real-Time Clock

RX Receive

SCK, SCL, SCLK Serial Clock

SDA Serial Data

SOAP Simple Object Access Protocol

SPI Serial Peripheral Interface

SRAM Static Random Access Memory

SS Slave Chip Select

TCP Transmission Control Protocol

TTL Transistor-Transistor Logic

TWI Two Wire Interface

TX Transmit

UART Universal Asynchronous Receiver Transmitter

UDDI Universal Description, Discovery and Integration

UDP User Datagram Protocol

URI Uniform Resource Identifier

USB Universal Serial Bus

WoT Web of Things

WSDL Web Services Description Languages

SUMRIO

1 INTRODUO ................................................................................................................... 10

1.1 Problema ............................................................................................................................. 10

1.2 Objetivos ............................................................................................................................. 11

1.2.1 Geral ................................................................................................................................ 11

1.2.2 Especficos ....................................................................................................................... 11

1.3 Justificativa ......................................................................................................................... 11

1.4 Organizao do trabalho ..................................................................................................... 12

2 FUNDAMENTAO TERICA ...................................................................................... 13

2.1 Internet de Todas as Coisas ................................................................................................ 13

2.2 Internet das Coisas .............................................................................................................. 15

2.3 Web das Coisas ................................................................................................................... 17

2.4 REST .................................................................................................................................. 19

2.4.1 Princpios REST .............................................................................................................. 19

2.5 Plataforma Arduino ............................................................................................................ 21

3 INTEGRANDO FUNCIONALIDADES DO ARDUINO WEB .................................. 23

3.1 Aplicando os princpios REST para expor funcionalidades do Arduino na Web .............. 23

3.2 Arquitetura de software ...................................................................................................... 27

3.2.1 Aplicao Web para a Web das Coisas ........................................................................... 28

3.2.1.1 Framework Rails .......................................................................................................... 28

3.2.1.2 Servidor Web WEBrick ................................................................................................ 29

3.2.1.3 Banco de dados SQLite ................................................................................................ 29

3.2.1.4 Diagrama de classes...................................................................................................... 29

3.2.2 Lmpada inteligente construda com hardware Arduino ................................................ 31

3.2.2.1 IDE Arduino 1.0.5-r2 ................................................................................................... 31

3.2.2.2 AccessPort 1.37 ............................................................................................................ 32

3.2.2.3 Diagrama de classes...................................................................................................... 32

3.3 Arquitetura de hardware .................................................................................................... 33

3.3.1 O prottipo ....................................................................................................................... 33

3.3.2 Arduino Mega 2560 R3 ................................................................................................... 34

3.3.3 Ethernet Shield R3 ........................................................................................................... 36

3.3.4 Sensor shield verso 4 ..................................................................................................... 38

3.3.5 Mdulo de reconhecimento de voz V2 ............................................................................ 39

3.3.6 Mdulo conversor USB-TTL .......................................................................................... 41

3.3.7 Sensor de temperatura e umidade DHT11 ....................................................................... 41

3.3.8 Mdulo RTC DS1302 ...................................................................................................... 42

3.3.9 Display LED de 7 segmentos e 4 dgitos ......................................................................... 43

3.3.10 Mdulo rel DC/AC 220 volts....................................................................................... 44

3.3.11 Cabos ............................................................................................................................. 45

4 AVALIAO DE DESEMPENHO DAS FUNCIONALIDADES DO ARDUINO EM

TEMPO DE EXECUO ..................................................................................................... 47

4.1 Consumo de memria ......................................................................................................... 47

4.2 Tempo para executar funcionalidade .................................................................................. 49

5 CONCLUSES .................................................................................................................... 51

5.1 Trabalhos futuros ................................................................................................................ 52

REFERNCIAS BIBLIOGRFICAS ................................................................................. 53

10

1 INTRODUO

O conceito de Internet das Coisas (do ingls, Internet of Things - IoT) surgiu em 1999

no Massachusetts Institute of Technology, onde a ideia conectar qualquer objeto do dia a dia

com a Internet. Desta forma, surgiria uma rede mundial de objetos heterogneos e endereveis

interligados e se comunicando atravs de protocolos de comunicao padronizveis. Portanto,

segundo a IoT, cada objeto torna-se enderevel e controlvel (KARIMI, 2013).

Esses objetos, geralmente dispositivos embarcados, tais como eletrodomsticos,

sensores sem fio e mquinas podem estar conectados Internet. Exemplos desses dispositivos

so: Sun SPOTs (Sun 2011), Nabaztag (Nabaztag 2011), Poken (Poken 2011), Arduino

(Arduino 2005), etc. Neste trabalho ser utilizado o Arduino, uma plataforma de prototipagem

eletrnica de hardware livre que possibilita criar ferramentas que so acessveis, de baixo custo,

flexveis e fceis de usar.

Uma vez estes objetos conectados Internet, o prximo objetivo da Internet das Coisas

refere-se a capacidade de comunicao e controle de forma remota desses objetos fazendo com

que os mesmos realizem aes sem a interveno humana. Portanto, o prximo passo da

Internet das Coisas a Web das Coisas (GUINARD et al. 2010).

A Web das Coisas (do ingls, Web of Things - WoT) um paradigma de

desenvolvimento de aplicaes inspirado na Internet das Coisas, baseado no uso de protocolos

e padres j em uso na Web, como por exemplo HTTP (Hypertext Transfer Protocol) e URIs

(Uniform Resource Identifier). Seu objetivo proporcionar a conexo de diversos objetos

inteligentes Web, tornando-os parte da Web, de forma que possam ser acessados da mesma

forma que qualquer outro recurso disponvel na mesma (GUINARD et al. 2010).

Para que esta conexo seja possvel, a Web das Coisas faz uso dos princpios REST

(Representational State Transfer), proposto por Roy Fielding em 2000, juntamente com ROA

(Resource Oriented Architecture), uma a arquitetura orientada a recursos, proposta por

Richardson e Ruby em 2007. Objetivo da ROA evitar erros ao aplicar os princpios REST no

desenvolvimento de sistemas, j que este no trata-se de uma arquitetura. Sendo assim, ROA

especifica como utilizar os princpios REST juntamente com os padres Web HTTP e URI

(FRANA, 2011).

1.1 Problema

Objetos inteligentes ou smart objects so objetos que possuem processadores embutidos

(por exemplo: microcontrolador) juntamente com interfaces de usurio que permitem controlar

suas funcionalidades (KARIMI, 2013). Uma vez que, tem-se objetos inteligentes, o prximo

11

passo permitir uma conexo remota esses objetos a fim de poder control-los, facilitando a

vida das pessoas. Como por exemplo, apagar a lmpada da casa ou checar o fechamento da

porta ao sair, tudo atravs do computador, tablet ou smartphone (KARIMI, 2013).

Segundo estimativa realizada pela Cisco IBSG (Internet Business Solutions Group) foi

previsto que em 2015 tero 7.2 bilhes de pessoas vivendo no planeta e 25 bilhes de

dispositivos (smart objects) conectados Internet. E em 2020 tero 7.6 bilhes de pessoas e 50

bilhes de dispositivos conectados. Desta forma, haver mais dispositivos conectados que

pessoas no planeta, tendo em 2015 3.47 e em 2020 6.58 dispositivos conectados por pessoa

(EVANS, 2011).

Sendo assim, com bilhes de objetos inteligentes controlveis e conectados Internet,

pode-se agora disponibiliz-los na Web. Permitindo assim, o gerenciamento e armazenamento

de informaes em tempo real, como tambm interagir com os objetos e suas informaes.

Desta forma, de grande importncia saber quais arquiteturas, protocolos e padres

amplamente aceitos e j em uso na Web deve ser utilizado.

1.2 Objetivos

1.2.1 Geral

Desenvolver uma aplicao Web para a disponibilizao das funcionalidades de

dispositivo Arduino na forma de recursos Web.

1.2.2 Especficos

Identificar protocolos e padres j em uso na Web tradicional;

Apontar os princpios REST na criao de APIs RESTfull;

Analisar a arquitetura orientada a recursos ROA;

Analisar o desempenho dos componentes da plataforma Arduino;

1.3 Justificativa

Atualmente j se pode encontrar milhares de objetos do dia a dia conectados na Internet.

Com o barateamento de hardware e software, a tendncia que essa quantidade cresa

exponencialmente, de forma que tais objetos estaro cada vez mais presentes em residncias,

centros de sade, instituies de ensino, governo, companhias de energia, etc. (BRADLEY et

al. 2013b).

12

Desta forma, de extrema importncia saber fazer com que tais dispositivos trabalhem

colaborativamente, atravs da troca de informaes entre si, como tambm, tirar proveito desses

dispositivos inteligentes tornando-os acessveis na Web.

Do ponto de vista terico, este trabalho servir como fonte de pesquisa para os demais

trabalhos nesta rea, como tambm, auxiliar no entendimento de quais ferramentas,

arquiteturas e tecnologias podem ser utilizadas no ambiente da Web das Coisas.

Quanto ao ponto de vista prtico, contribuir para a concretizao do paradigma da Web

das Coisas, fazendo com que as funcionalidades do dispositivo Arduino estejam disponveis e

acessveis na Web.

1.4 Organizao do trabalho

Este trabalho est organizado em 5 captulos. O Captulo 2 apresenta os conceitos

relacionados a Internet de Todas as Coisas, Internet das Coisas, Web das Coisas, REST e seus

princpios e a plataforma Arduino. O Captulo 3 apresenta o emprego dos princpios REST na

abordagem ROA para integrao do objeto inteligente na aplicao Web desenvolvidos neste

trabalho. Ademais, apresenta-se a arquitetura de hardware e software dos mesmos. No Captulo

4 apresenta-se os resultados obtidos da avaliao de desempenho do Arduino em tempo de

execuo, referentes ao consumo de memria e tempo necessrio para executar cada uma das

funcionalidades do objeto inteligente. Por fim, no Captulo 5 apresentam-se as concluses e

sugestes de trabalhos futuros que possam aprimorar e expandir as funcionalidades da aplicao

Web e do objeto inteligente.

13

2 FUNDAMENTAO TERICA

2.1 Internet de Todas as Coisas

A Internet de Todas as Coisas (do ingls, Internet of Everything - IoE) consiste na

conexo em rede de pessoas, coisas, dados e processos, a fim de criar conexes de rede mais

relevantes e de grande valor. Cada um destes componentes possuem um papel especfico e

trabalham juntos, como mostrado na Figura 1 (MITCHELL et al. 2013).

Figura 1 - A Internet de Todas as Coisas rene Pessoas, Coisas, Dados e Processos. Fonte: CISCO.

A Internet de Todas as Coisas conectar as pessoas de forma eficaz, fazendo com que

cada um, passe a ser um n passivo ou ativo dentro da Internet. As pessoas sero capazes de

conectar-se Internet de vrias formas. Atualmente, a maioria delas conectam-se atravs de

dispositivos (tablets, smartphones, computador, televisores) e das redes sociais (Facebook,

Twitter, LinkedIn) (MITCHELL et al. 2013).

Mas na Internet de Todas as Coisas, as pessoas se conectaro de forma mais relevante,

como por exemplo: as pessoas tomaro uma plula que ter a capacidade de medir algumas

caractersticas do trato digestivo e enviar esta informao por Internet ao mdico. Outro

exemplo, seria o uso de sensores localizados na pele ou na roupa das pessoas, a fim de fornecer

informaes dos sinais vitais e enviar um mdico (MITCHELL et al. 2013).

Na IoE, os dados sero transformados em informao til no momento adequado para

a rpida tomada de decises inteligentes, como tambm, controlar o ambiente de forma mais

eficiente. Estes dados, sero proporcionados atravs dos milhares de sensores (MITCHELL et

al. 2013).

14

As coisas ou Internet das Coisas uma das transies de tecnologia que proporcionam

a Internet de Todas as Coisas. A IoT consiste em objetos fsicos (sensores e dispositivos)

conectados tanto Internet, quanto entre os mesmos, formando uma rede mundial de objetos

conectados. A Internet das Coisas ser abordada com mais detalhes na Seo 2.2 (MITCHELL

et al. 2013).

Os processos, referem-se como pessoas, coisas e dados, trabalham em conjunto para

oferecer valor no mundo conectado da Internet de Todas as Coisas. Os processos,

proporcionaro a informao correta pessoas ou mquinas conectadas no momento adequado.

Fazendo com que a informao chegue quem necessita, no momento em que precisa, e que

contenha a informao necessria (MITCHELL et al. 2013).

De acordo com pesquisa feita pela CISCO, a Internet de Todas as Coisas ter o potencial

de gerar cerca de 14.4 trilhes de dlares durante os anos de 2013 a 2020. Todo este valor,

refere-se apenas as organizaes do setor privado do mundo todo (BRADLEY et al. 2013a).

Como pode ser visto na Figura 2, a IoE inclui trs tipos de conexes: machine-to-

machine (M2M), person-to-machine (P2M) e person-to-person (P2P). As conexes P2M e P2P

representaro 55% dos 14.4 trilhes de dlares, enquanto as conexes M2M representaro 45%

(BRADLEY et al. 2013a).

Figura 2 - Tipos de conexes da IoE: M2M, P2M e P2P. Fonte: CISCO.

Os 14.4 trilhes de dlares, explica-se por duas razes: a primeira, ser resultado da

economia dos custos, j que sero mais produtivos e manusearo melhor a informao. O

segundo, refere-se a gerao de novos negcios, como por exemplo: edifcios inteligentes,

medicina conectada, merketing conectado, rede eltrica inteligente, entre outros (BRADLEY et

al. 2013a).

15

Portanto, percebe-se o grande potencial e efeito tanto do mbito econmico como social,

que poder ser proporcionado pela Internet de Todas as Coisas ao conectar tudo aquilo que

ainda no est conectado, ou seja, ao conectar pessoas, coisas, dados e processos. Visando

sobretudo benefcios para a humanidade, tornando a vida mais fcil e segura, como tambm

reduzindo os impactos no meio ambiente.

2.2 Internet das Coisas

O termo Internet das Coisas foi criado por Kevin Ashton, co-fundador do Centro de

Auto-ID do MIT (Massachusetts Institute of Technology) no ano de 1999, enquanto trabalhava

em um projeto no campo de RFID (Radio Frequency Identification) e tecnologias de sensores

emergentes. Com o passar dos anos, com a ideia de objetos do cotidiano possurem sensores

embutidos e chips, que permitiriam a comunicao entre esses objetos e com o ambiente, deram

origem a outros termos, tais como: computao ubqua e computao pervasiva

(WITCHALLS, 2013).

A Internet das Coisas consiste numa rede de objetos inteligentes (objetos que possuem

processamento embutido, tipicamente: microcontrolador ou MCU) conectados Internet que

interagem e comunicam-se com outros objetos, mquinas e ambiente, resultando na gerao e

processamento de grande volume de dados (EVANS, 2011).

De acordo com a Cisco IBSG, a Internet das Coisas surgiu entre os anos de 2008 e 2009,

perodo em que, o nmero de coisas e objetos conectados Internet ultrapassou o nmero de

pessoas no mundo. A pesquisa estima que em 2015 tero 25 bilhes de dispositivos conectados

Internet. J para 2020, a estimativa de 50 bilhes, como pode ser visto na Figura 3 (EVANS,

2011).

Alguns fatores tem contribudo para o surgimento e adoo da Internet das Coisas.

Como por exemplo, nos prximos anos, as atividades de IoT ser impulsionado pelo

barateamento de sensores (tags RFID, e MEMS - microelectromechanical systems, tais como:

acelermetros, giroscpios, sensores de presso, etc.), protocolo IPv6, computao em nuvem

(armazenamento e anlise dos dados; hospedagem e desenvolvimento de aplicaes que

manipulam as funcionalidades dos sensores), anlise de dados avanadas (Big Data) e

mobilidade (dispositivos smartphones e tablets) (WITCHALLS, 2013).

16

Figura 3 - A Internet das Coisas surgiu entre os anos de 2008 e 2009. Fonte: Cisco IBSG, 2011.

Segundo estimativas da Cisco 99,4% dos objetos fsicos presentes na terra ainda no

esto conectados. Tendo apenas 10 bilhes de objetos conectados, de um total de 1.5 trilhes

(BRADLEY et al. 2013a).

Sabe-se que tudo que est conectado Internet deve possuir um endereo IP, portanto,

deve-se ter uma quantidade suficiente de endereos IP para a conexo de todas essas coisas

(pessoas, coisas, dados e processos) Internet. Como dito anteriormente, a estimativa que em

2020 haja 50 bilhes de objetos fsicos conectados, sendo assim, o nmero de endereos do

IPv4 no ser suficiente, j que fornece apenas 4.294.967.295 ou aproximadamente 4.3 bilhes

de endereos IP (BRADLEY et al. 2013a).

Mas, isto no ser um problema, uma vez que, o IPv6 possui um espao de

endereamento de 128 bits, sendo possvel obter

340.282.366.920.938.463.463.374.607.431.768.211.456 ou 340.3 undecilho de endereos IP.

Uma quantidade suficientemente grande para enderear os estimados 1.5 trilhes de

dispositivos existentes no mundo inteiro, como tambm conectar pessoas, processos e dados

Internet (BRADLEY et al. 2013a).

Uma vez que, a Internet das Coisas tenha alcanado o objetivo de formar uma rede de

bilhes de objetos inteligentes interconectados, interagindo e gerando dados. O ltimo objetivo

das aplicaes da IoT refere-se capacidade de comunicao e controle manual de forma

remota a esses objetos, com o intuito de automatiz-los. Onde, baseando-se em configuraes

feitas pelo usurio e processamentos baseado em nuvem, faam com que tais objetos realizem

17

aes sem a interveno humana. Com o propsito de facilitar a vida das pessoas (KARIMI,

2013).

Desta forma, o prximo passo da Internet das Coisas a Web das Coisas que consiste

em disponibilizar objetos inteligentes na Web. Ou seja, fazer com que tais objetos forme parte

da Web, de forma que possam ser acessados da mesma forma que qualquer outro recurso

existente na mesma (EVRYTHNG, 2012).

Na Seo 2.3 a Web das Coisas ser abordada com mais detalhes, apresentando suas

caractersticas, as tecnologias que esto sendo utilizadas para tornar objetos inteligentes em

recursos Web, e algumas das aplicaes em nuvem j existentes para a WoT.

2.3 Web das Coisas

A medida que tem-se cada vez mais objetos fsicos inteligentes conectados Internet, e

sabendo que tais objetos podem ser controlados remotamente e que esto continuamente

gerando dados. de suma importncia utilizar tecnologias que permitiro desenvolver

aplicaes de forma rpida e flexvel para acessar estes objetos, como tambm, armazenar e

gerenciar seus dados (GUINARD et al. 2010).

Para isto, tais tecnologias devem respeitar certos requisitos, devendo ser: leve (objetos

inteligentes so dispositivos com restrio de recursos, como memria, processamento e

energia), fracamente acoplado (falhas em ns da rede no deve impactar no funcionamento

do sistema), escalvel (bilhes de objetos se comunicando uns com os outros e enviando

milhes de mensagens por segundo), flexvel (suporte para um conjunto de padres para troca

de dados) e padro (garantir a alavancagem mxima das ferramentas, servios e melhores

prticas construdas pela comunidade) (EVRYTHNG, 2012).

Sendo assim, a WoT prope que protocolos e padres da Web (HTTP, TCP, IPv6, XML,

JSON, RSS, ATOM, REST, WS-*, URI) sejam utilizados como linguagem comum para a

integrao de objetos inteligentes Web (GUINARD et al. 2010).

Tais protocolos, j em uso, com grande aceitao, e que fazem da Web um sucesso,

podem tambm ser utilizados para o desenvolvimento de aplicaes, a fim de servir como

plataforma para objetos inteligentes e torn-los em recursos Web (EVRYTHNG, 2012).

Os padres Enterprise Web Services (conhecidos como WS-*, como por exemplo:

UDDI, WSDL, SOAP, etc.), tem por objetivo facilitar o design e implementao de aplicaes

distribudas interoperveis (EVRYTHNG, 2012).

Tais tecnologias, adicionam uma camada de software nas aplicaes, resultando em

maior complexidade. Tornando-se desta forma uma barreira para o ambiente da Internet das

18

Coisas, uma vez que, tais padres tornam-se pesados e complexos, j que trata-se de objetos

simples e com recursos limitados (GUINARD et al. 2010).

Ao invs de usar tecnologias WS-*, estudos envolvendo projetos relacionados Web

das Coisas, tem explorado a implementao de servidores HTTP em dispositivos embarcados.

Como resultado, obteve-se baixo consumo dos recursos dos dispositivos inteligentes. Este

resultado, foi possvel devido a eficiente otimizao proporcionadas pelos protocolos HTTP e

TCP, das camadas de aplicao e transporte respectivamente (GUINARD et al. 2010).

Alm do protocolo HTTP, o estilo arquitetural REST est sendo aplicado em objetos

inteligentes. Seu uso devido s suas propriedades, pois este, respeita os requisitos citados

anteriormente necessrios para tornar possvel a integrao dos objetos na Web (GUINARD et

al. 2010).

O estilo arquitetural REST possui as seguintes propriedades: permite criar servios

fracamente acoplados na Web; implementado com HTTP e URI (identifica recursos na Web),

e pelos tipos de mdia padronizados, tais como: HTML e XML; fornece uma interface uniforme,

atravs dos mtodos HTTP (GET, POST, PUT e DELETE); e permite que clientes selecionem

a melhor opo para interao, sendo geralmente XML e JSON. Na Seo 2.4 a arquitetura

REST ser abordada com maior detalhes (FIELDING, 2000).

Tais caractersticas faz do REST a opo ideal para a construo de aplicaes Web

para objetos inteligentes, permitindo uma perfeita integrao dos mesmos Web, como

tambm, expor suas caractersticas e se comunicar com servios externos ou centralizados

(GUINARD et al. 2010).

Desta forma, devido simplicidade, fraco acoplamento e escalabilidade do estilo

arquitetural REST, como tambm da larga aceitao e disponibilidade de clientes e bibliotecas

HTTP, a arquitetura REST torna-se uma plataforma de integrao ubqua e leve (GUINARD et

al. 2010).

Atualmente, j encontram-se disponveis algumas plataformas para a Web das Coisas,

entre as mais populares tem-se: Xively, Nimbits, Evrythng, Thingspeak, Etherios, Sen.se,

Exosite e SensorCloud. Tais plataformas, foram desenvolvidas baseando-se no estilo

arquitetural REST, proporcionando fcil integrao de objetos fsicos Web, permitindo a

obteno de uma representao deste objeto na Web, conhecida como Web Object.

Estas plataformas, fornecem uma representao amigvel destes objetos, tornando

possvel interagir com os mesmos atravs de navegadores Web, como tambm, visualizar

atravs de pginas Web os dados gerados em tempo real pelos mesmos.

19

As plataformas citadas anteriormente, permitem a conexo de diferentes tipos de

dispositivos eletrnicos que tenha suporte TCP/IP, como por exemplo: Arduino, Raspberry Pi,

Sun SPOTs, ARM mbed, entre outros. A interao entre plataforma e objeto, independe da

forma de como objetos fsicos esto conectados Internet, que pode ser via HTTP sobre TCP/IP

ou gateways para dispositivos conectados por protocolos como Zigbee e Bluetooth, por

exemplo. Estas plataformas tambm podem ser acessadas por linguagens de programao que

possuam bibliotecas HTTP cliente, como: C, Ruby, Java, Python, e outros (GUINARD et al.

2010).

2.4 REST

O termo REST (do ingls, Representational State Transfer) foi definido por Roy

Thomas Fielding em sua tese de doutorado. Roy tambm contribuiu com a especificao do

protocolo HTTP e com o esquema de nomes global URI, e um dos fundadores do projeto

Servidor Apache HTTP (TILKOV, 2007).

REST no trata-se de uma arquitetura, e um estilo hbrido derivado de vrios estilos

de arquiteturas baseados na rede (FIELDING, 2000). Desta forma, a utilizao de seus

princpios podem ser empregados de forma incorreta no desenvolvimento de sistemas. Um

exemplo disto, seria o caso de aplicaes que resultaram em um hbrido de REST com RPC ao

adotarem os princpios REST, o que no desejvel (FRANA, 2011).

Desta forma, a Arquitetura Orientada a Recursos (ROA) proposta por Richardson e

Ruby, em 2007, define um conjunto de conceitos e propriedades que especificam como

empregar os princpios REST juntamente com os amplamente aceitos e j em uso protocolos e

padres da Web, tais como HTTP e URI (FRANA, 2011).

REST nos conceitos ROA, consiste em um conjunto de princpios que define como os

padres da Web, tais como HTTP e URI devem ser utilizados, e como tais princpios, podem

ser aplicados no desenvolvimento de sistemas com uma arquitetura orientada a recursos, ROA.

Sendo assim, aplicaes que adotem os princpios REST em seu projeto, estaro beneficiando-

se da arquitetura Web (protocolos e padres), e tero como resultado sistemas denominados

RESTful (TILKOV, 2007).

2.4.1 Princpios REST

Os princpios REST apresentados a seguir, baseiam-se nos conceitos especificados pela

Arquitetura Orientada a Recursos (ROA).

20

Identificao nica e global para os recursos: um recurso qualquer componente de

uma aplicao que seja importante o suficiente para ser identificado unicamente. Esta

identificao global na Web realizada atravs de URIs (FIELDING, 2000).

A grande vantagem de utilizar URIs na identificao dos componentes da aplicao,

que estar sendo utilizado um esquema de nomes amplamente aceito na Web, no havendo a

necessidade de apresentar um novo esquema. Para maiores informaes sobre URI, consultar a

RFC 3986 (TILKOV, 2007).

Interface uniforme de acesso aos recursos: em REST, a interao e recuperao da

representao de um recurso ocorre atravs de uma interface uniforme. Na Web, esta interface

uniforme definida pelos quatro principais mtodos do protocolo HTTP (GET, POST, PUT e

DELETE), e baseia-se em URIs, sendo a URI, o alvo da mensagem de requisio (FIELDING,

2000).

Estes quatro mtodos, podem esto referir-se ao CRUD (Create, Read, Update, Delete)

da aplicao, onde o GET utilizado para obteno da representao de um recurso. PUT para

atualizar um recurso existente. POST utiliza-se para criao de um novo recurso. E por fim, o

DELETE, utilizado para excluir um recurso. Ambos os mtodos PUT e POST podem ser

utilizados para criar e atualizar um recurso, mas geralmente utiliza-se PUT para atualizar e

POST para criar o recurso, como explicado anteriormente (GUINARD et al. 2010).

Caso o mtodo PUT seja utilizado para criar o recurso, deve-se fornecer o identificador

do mesmo (maiores informaes da especificao destes mtodos HTTP podem ser obtidas na

RFC 2616) (GUINARD et al. 2010).

Desta forma, atravs de uma interface uniforme, ao receber uma requisio HTTP e uma

URI, o servidor sabe o que fazer apenas observando o mtodo da requisio (FRANA, 2011).

Endereabilidade dos recursos: refere-se ao conceito de hipermdia, abordagem

HATEOAS (Hypermedia as Engine Of Application State), onde links so utilizados para a

vinculao de recursos que formam a Web, permitindo que certo recurso aponte para recursos

externos (de diferentes aplicaes ou servidores). Isto torna-se possvel devido a utilizao do

esquema de nomes padro de uso global URI. Outro aspecto importante, refere-se ao uso de

links, para tornar as aplicaes mais dinmicas, ou seja, o servidor fornece um conjunto de links

ao cliente, permitindo que o mesmo utilize-os para mudana de estado da aplicao (TILKOV,

2007).

Suporte a mltiplas e independentes representaes para o recurso: recursos no

esto vinculadas a nenhum tipo particular de representao. Sendo assim, um nico recurso

21

pode ser representado por vrios formatos, podendo ser: JSON, XML, HTML, CSV, etc., sendo

os dois primeiros os mais populares (GUINARD et al. 2010).

Quando uma requisio HTTP para o servidor mapeada por mltiplas representaes

(definidas atravs do cabealho Accept do HTTP), servidor e cliente negociam, entre os

formatos representativos disponveis para o recurso, aquele que melhor se adequa s

necessidades do cliente (GUINARD et al. 2010).

Interao sem manuteno de estado: nas aplicaes REST o servidor no tem que

manter nenhum tipo de estado das comunicaes com os clientes ao qual se comunica

(TILKOV, 2007). Isto significa que, cada requisio HTTP feita por um cliente ao servidor,

deve conter toda a informao necessria para que o mesmo entenda a requisio. Desta forma,

informaes sobre determinado recurso deve ser mantida no lado do cliente (FIELDING, 2000).

O maior benefcio deste princpio refere-se escalabilidade, j que, o desempenho do

servidor poderia ser afetado dependendo da quantidade de clientes que interage, uma vez que,

estivesse que manter estado dos clientes entre as requisies (FIELDING, 2000).

Outro benefcio, seria que o cliente no seria afetado em caso de mudanas de servidor

(falhas de hardware), ou seja, requisies consecutivas feitas por um cliente, no tem que

necessariamente serem destinadas ao mesmo servidor (TILKOV, 2007).

2.5 Plataforma Arduino

Arduino uma plataforma de prototipagem eletrnica open-source, fundada por

Massimo Banzi, David Cuartielles, Tom Igoe, Gianluca Martino, e David Mellis. Flexvel e de

fcil utilizao, destina-se artistas, designers, ou a qualquer pessoa interessada na criao de

objetos ou ambientes interativos (BANZI, 2011).

O microcontrolador presente nas diversas placas Arduino (Uno, Mega, Leonardo,

Micro, Mini, Nano, LilyPad, Fio, etc.) so programados utilizando a linguagem de programao

Arduino (baseada em Wiring, um framework de programao open-source para

microcontroladores), juntamente com sua IDE (baseada no Ambiente de Desenvolvimento

Processing) (BANZI, 2011).

Uma vez escrito o cdigo e realizado a transferncia do mesmo placa Arduino atravs

da IDE. Pode-se conectar sensores de temperatura, umidade, luminosidade, presena,

flexibilidade, gs, entre outros, fazendo com que tais sensores convertam aspectos do mundo

fsico em eletricidade. Pode-se tambm conectar-se atuadores, como por exemplo, luzes,

motores, autofalantes, displays e etc., estes, obtm eletricidade da placa e agem sobre o

22

ambiente. Desta forma, sensores e atuadores podem conectar-se placa Arduino para uma

maior interao com o mundo real (MARGOLIS, 2011).

H tambm os shields, que consiste em placas que podem ser facilmente encaixadas

encima das placas Arduino compatveis, ou at mesmo, encima de outros shields, com o

objetivo de fornecer funcionalidade extra placa Arduino, como por exemplo: conexo

Ethernet ou Wifi, receptor GPS, reproduzir udio (MP3, WAV, etc.), display LCD, etc.

(B2CQSHOP, 2011).

23

3 INTEGRANDO FUNCIONALIDADES DO ARDUINO WEB

Este Captulo explica como os princpios REST nos conceitos ROA foram empregados

para disponibilizar os recursos do objeto inteligente (lmpada inteligente construda com

hardware Arduino) na Web. Ademais, ser explicado como a aplicao Web para a Web das

Coisas, desenvolvida com framework Rails, utiliza REST para controle, e armazenamento,

gerenciamento e exibio dos dados gerados em tempo real pelo dispositivo inteligente.

Ao final, ser apresentado toda a arquitetura de hardware e software necessrios para a

construo do objeto inteligente, como tambm a arquitetura de software utilizada no

desenvolvimento da aplicao Web.

3.1 Aplicando os princpios REST para expor funcionalidades do Arduino na Web

Para que as funcionalidades do dispositivo inteligente pudessem ser expostas, foi

necessrio implementar um servidor Web embarcado no mesmo. A fim de poder receber e

enviar requisies HTTP que permitam o acesso s funcionalidades do dispositivo na forma de

recursos REST.

A lmpada inteligente para ser acessada, precisa primeiramente, ter uma representao

na Web. Isto faz-se atravs da aplicao Web desenvolvida para a Web das Coisas, onde aps

o registro do objeto, este pode receber e enviar requisies HTTP, e assim, ter seus recursos

disponibilizados.

Ter uma representao do objeto fsico na Web, significa que este objeto passa a ter um

identificador nico na Web, o que permite ser acessado como qualquer outro recurso existente

na Web. Como dito na Seo 2.4, na Web das Coisas essa identificao feita atravs de URIs,

estando assim, em conformidade com o princpio REST de identificao nica e global para os

recursos.

A URI de cada objeto gerada automaticamente pela aplicao aps o registro do

mesmo. Desta forma, cada URI possui o seguinte formato:

http://{endereo_do_servidor}/{recurso_objeto}/{identificador_do_objeto}

Sendo assim, uma vez que o usurio tenha realizado login, ao acessar um determinado

objeto, uma requisio HTTP enviada para o servidor, e como resposta, o usurio ser

redirecionado para uma outra pgina Web cujo contedo ser uma representao deste recurso

(objeto inteligente), como pode ser visto na Figura 4. Enquanto que a requisio HTTP ter o

formato mostrado na Figura 5.

24

Figura 4 - Pgina Web da representao do objeto fsico na Web. Fonte: Compilado pelo autor.

Figura 5 - Requisio HTTP GET para obteno da representao do objeto. Fonte: Criado pelo autor.

Quando a requisio exibida na Figura 5 chega no servidor, este chamar o controller

objetos e a action show especificada no arquivo de configurao de rotas gerado

automaticamente pelo framework (rota exibida na Figura 6), j que a requisio HTTP possui

a URL do recurso /objetos/1 e o mtodo GET (utilizado para obter o contedo de determinado

recurso).

Como pode ser visto na Figura 6, os caminhos da rota so definidos da seguinte forma,

sendo os campos em parnteses opcionais:

HTTP method ':controller(/:action(/:id(.:format)))'

A string segue um padro, sendo composta por trs segmentos particionado por barras

(/) e variveis para serem postas. Estas variveis so precedidas por dois pontos (:), sendo estas,

:controller, :action, e :id e :format. A varivel :format refere-se ao formato do contedo da

resposta, por padro, no Rails pode ser JSON (formato para aplicaes) ou HTML (formato

25

para humanos), aplicando-se neste caso, o principio REST de suporte a mltiplas e

independentes representaes para o recurso (GAMBLE et al. 2013).

Figura 6 - Tabela de rotas da aplicao para o recurso objetos. Fonte: Elaborado pelo autor.

De acordo com a tabela de rotas da aplicao, o controller do recurso objetos

(ObjetosController), ter a estrutura e mtodos exibido na Figura 7.

Como pode ser observado, os sete mtodos presente no controller e referenciados na

tabela de rotas, contm as quatro operaes bsicas CRUD (criar, ler, atualizar, e deletar). Alm

dos quatro mtodos bsicos citados, possui mtodos para listar recursos (index), e mais outros

dois mtodos auxiliares que retorna recursos novos (new) e existentes (edit), numa forma

adequada para edio do cliente (RUBY et al. 2012). Estando desta forma, em conformidade

com o princpio REST de interface uniforme de acesso aos recursos, em que utiliza-se os quatro

mtodos da requisio HTTP (GET, POST, PUT, DELETE) para interao e recuperao da

representao dos recursos.

Na pgina Web retornada pelo servidor como representao de determinado recurso

(objeto inteligente), mostrado na Figura 4, o grfico de temperatura e umidade exibido

alimentado atravs do envio de requisies HTTP do Arduino para o servidor da aplicao.

26

Estas requisies so enviadas automaticamente com periodicidade de um minuto entre cada

uma delas. Estas requisies possuem o formato apresentado na Figura 8.

Pode-se observar que no corpo da mensagem desta requisio enviado uma

representao do recurso dht11 (sensor de temperatura e umidade conectado ao Arduino) no

formato JSON. Neste caso, cliente (placa Arduino) e servidor (aplicao Web) devem estar de

acordo com este formato, o que aceitvel pela aplicao Web, j que a mesma, aceita os

formatos HTML e JSON.

Figura 7 - Classe ObjetosController e mtodos especificados no arquivo de configurao de rotas da

aplicao. Fonte: Elaborado pelo autor.

27

Figura 8 - Requisio HTTP POST que envia os dados do sensor dht11 do Arduino. Fonte: Criado

pelo autor.

A pgina Web da Figura 4, alm de permitir que o usurio visualize os dados de

temperatura e umidade gerados em tempo real pelo objeto inteligente, tambm permite que o

usurio controle/interaja remotamente com o mesmo. Como por exemplo, acender e apagar a

lmpada. Neste caso, a aplicao Web envia uma requisio HTTP para o objeto inteligente

(Arduino com servidor embarcado), em que o mesmo interpreta esta requisio para que o

Arduino saiba qual recurso (atravs da URI) e qual operao sobre o recurso (mtodo a ser

chamado para acionar a lmpada) deve ser realizada. A Figura 9 mostra o formato da requisio

HTTP enviada ao Arduino.

Figura 9 - Requisio HTTP PUT enviada ao Arduino para alterar o estado da lmpada. Fonte: Criado

pelo autor.

importante notar que, em todas as requisies mostradas anteriormente, todas elas

possuem toda a informao necessria para que a requisio seja entendida e processada pelo

servidor. Estando desta forma, de acordo com o princpio REST de interao sem manuteno

de estado.

3.2 Arquitetura de software

Esta seo abordar toda a arquitetura de software necessria para tornar possvel o

desenvolvimento deste trabalho. Isto inclui, tanto os softwares utilizados no desenvolvimento

28

da aplicao Web, como tambm, os softwares para implementao do prottipo (lmpada

inteligente construda com hardware Arduino).

Tambm ser apresentado o diagrama de classes tanto da aplicao Web como do

dispositivo inteligente, a fim de proporcionar um melhor entendimento da estrutura e

relacionamento das classes que compem os mesmos.

3.2.1 Aplicao Web para a Web das Coisas

A ideia do desenvolvimento da plataforma para a Web das Coisas, oferecer pginas

Web que permitam que os usurios integrem, gerenciem e criem uma representao na Web do

objeto fsico. A fim de, visualizar (por meio de uma interface amigvel voltada para o objeto

em questo lmpada inteligente) em tempo real atravs de um grfico interativo os dados

(temperatura e humidade ambiente) gerados pelo objeto. Como tambm permitir o controle de

forma remota do mesmo, que neste caso, refere-se ao acendimento e apagar da lmpada. Os

softwares utilizados foram: framework Rails, banco de dados SQLite, e o servidor Web

WEBrick.

3.2.1.1 Framework Rails

O framework Rails foi criado em 2003 por David Heinemeier Hansson. Trata-se de um

framework para aplicaes Web que utiliza a linguagem de programao Ruby (inventada por

Yukihiro Matsumoto em 1994). de cdigo aberto, multi-plataforma, com suporte a diversos

sistemas de banco de dados (SQLite, DB2, MySQL, Oracle, Postgres, Firebird, e SQL Server),

no requer editor ou IDE, e composto por vrias bibliotecas e ferramentas que facilitam o

desenvolvimento de aplicaes (GAMBLE et al. 2013).

Rails implementa o padro MVC (Model, View e Controller) atravs das bibliotecas

Active Record (responsvel pela interao e abstrao com o banco de dados), Action View

(sistema de templates que gera pginas HTML para o usurio como resultado de uma requisio

aplicao), e Action Controller (manipula o fluxo da aplicao, e os dados vindos do banco

de dados para serem exibidos na view) (GAMBLE et al. 2013).

Os benefcios da utilizao de um padro como o MVC, que cada parte que o compe

uma entidade separada, permitindo serem testadas de forma isolada. Outro benefcio, refere-

se as mudanas numa aplicao MVC, que tendem a ser localizadas e de baixo impacto,

significando que mudanas, por exemplo, na camada model no precisa afetar a camada view

(RUBY et al. 2012).

29

O framework Rails tambm implementa os princpios REST na camada controller,

baseando-se nos conceitos da arquitetura orientada a recursos (ROA). Desta forma, o controller

trata cada elemento da camada model como um recurso da aplicao (GAMBLE et al. 2013).

Consequentemente, Rails utiliza URIs para identificao destes recursos, como tambm

o protocolo HTTP para comunicao cliente-servidor. Cada requisio HTTP deve conter toda

a informao necessria para que o servidor possa compreende-la, j que atravs dela que a

aplicao definir qual controller e action (mtodo do controller) deve ser chamado (de acordo

com o arquivo de configurao de rotas do Rails), observando apenas a URI e o mtodo da

requisio HTTP (GET, POST, PUT e DELETE) (RUBY et al. 2012).

3.2.1.2 Servidor Web WEBrick

WEBrick um servidor HTTP Ruby que vem junto com o framework Rails, desta forma,

no h a necessidade de instalao e configurao de um servidor Web para a aplicao. Trata-

se de um servidor leve, e que pode ser configurado como um servidor HTTPS, servlet com

cdigo Ruby, servidor proxy, entre outros (RUBY et al. 2012).

3.2.1.3 Banco de dados SQLite

SQLite o banco de dados padro para desenvolvimento no Rails. Trata-se de um banco

de dados leve, de cdigo aberto, e ideal para dispositivos com pouca memria. SQLite realiza

operaes de leitura e escrita diretamente em arquivos no disco, como tambm mantm em um

nico arquivo um banco de dados completo (possuindo vrias tabelas, ndices, triggers e views)

(ABOUT, 2014).

3.2.1.4 Diagrama de classes

A Figura 10 apresenta as principais classes do pacote controllers da aplicao Web. A

classe ActionController implementa diversas funes (redirect_to, render, before_filter, entre

outros) que manipulam o fluxo da aplicao e os dados vindos do banco de dados para serem

exibidos na view. A nica classe da aplicao que herda de ActionController a classe

ApplicationController, as demais classes do controller herdam de ApplicationController.

Na classe ApplicationController encontram-se algumas variveis, cujo contedo

exibido na view, e tambm o mtodo check_login que retorna uma instncia do objeto Usuario,

uma vez que, obtem-se sucesso na validao do login e senha.

A classe SessionsController contm os mtodos create e destroy para gerenciar a seo

dos usurios da aplicao. O mtodo create recebe os dados de login e senha fornecidos pelo

usurio, atravs do formulrio da view. Em seguida, passa esses dados para o mtodo

30

validate_login da classe Usuario (model) e dependendo do retorno, o usurio tem acesso ou

no aplicao.

Nas classes UsuariosController e ObjetosController esto implementados os quatro

mtodos bsicos CRUD (create {mtodo create}, read {mtodo show}, update {mtodo

update}, e delete {mtodo destroy}), alm de mais outros trs mtodos auxiliares: index

(retorna uma lista de recursos), new (retorna a instncia do recurso), e edit (retorna os dados de

um dos recursos). J a classe Dht11sController, implementa-se apenas os mtodos index e

create, j que as demais operaes CRUD no aplica-se a este recurso.

Ademais, a classe ObjetosController implementa o mtodo mudarstatusluz, responsvel

por enviar uma requisio HTTP PUT para alterar o estado da lmpada acoplada na placa

Arduino, permitindo assim, que a mesma seja apagada ou acendida remotamente.

Figura 10 - Diagrama de classes do pacote controllers da aplicao Web. Fonte: Elaborado pelo autor.

A Figura 11 apresenta as principais classes do pacote models da aplicao Web. A classe

ActiveRecord implementa diversas funes (create, read, all, where, first, update, delete, save,

entre outros) que so responsveis pela interao e abstrao com o banco de dados. Todas

essas classes herdam de ActiveRecord e so mapeadas como tabelas no banco de dados.

31

Figura 11 - Diagrama de classes do pacote models da aplicao Web. Fonte: Elaborado pelo autor.

Na classe Usuario est implementado o mtodo validate_login, que busca no banco de

dados da aplicao um recurso usurio que possua os dados de login e senha, fornecidos pelo

usurio. Em caso de sucesso, retorna uma instncia do recurso encontrado.

A classe Dht11 implementa o mtodo valorMedio que tem a funo de buscar os dados

de temperatura e umidade (fornecidos pelo sensor no Arduino) de determinado dia e retornar o

valor mdio para este dia. Esta funo utilizada para alimentar o grfico de temperatura e

umidade dos ltimos sete dias, para serem exibidos ao usurio.

3.2.2 Lmpada inteligente construda com hardware Arduino

Os softwares necessrios para a implementao do prottipo foram: IDE Arduino 1.0.5-

r2 (utilizado para escrita e transferncia do cdigo para o microcontrolador Arduino), e

AccessPort137 (utilizado para gravao dos comandos de voz, e gerenciamento do hardware

de reconhecimento de voz).

3.2.2.1 IDE Arduino 1.0.5-r2

A IDE (do ingls, Integrated Development Environment) do Arduino foi necessria para

a escrita, edio e transferncia do cdigo para a placa Arduino. Tambm funo da IDE

realizar a converso do cdigo em instrues (linguagem de mquina) entendveis pelo

hardware Arduino (MARGOLIS, 2011).

32

3.2.2.2 AccessPort 1.37

O AccessPort uma ferramenta para monitoramento da porta serial, permitindo desta

forma, a debugao da mesma. O AccessPort foi utilizado para envio dos comandos

hexadecimais para configurao do mdulo de reconhecimento de voz, como tambm, para

visualizao dos dados retornados pelo mdulo.

3.2.2.3 Diagrama de classes

A Figura 12 apresenta as principais classes executadas no Arduino Mega 2560. As

classes EthernetClient e EthernetServer, esto includas na biblioteca Ethernet. Esta biblioteca

permite que a placa Arduino conecte-se Internet atravs do uso do shield Ethernet.

Figura 12 - Principais classes executadas no Arduino Mega 2560. Fonte: Elaborado pelo autor.

Como explicado anteriormente, para que o Arduino possa disponibilizar suas

funcionalidades como recursos REST, necessrio que o mesmo possua um servidor Web

embarcado. Desta forma, a classe EthernetServer desempenha esta funo, onde a placa

Arduino fica em um loop infinito, esperando pela chegada de clientes que enviam requisies

HTTP para acessar as funcionalidades do Arduino.

A classe EthernetClient responsvel pela criao de clientes. Sendo assim, um cliente

(placa Arduino) pode conectar-se um servidor (aplicao Web desenvolvida neste trabalho).

Portanto, atravs dessa classe que o Arduino envia as requisies HTTP, que contm as

informaes de temperatura e umidade, para o servidor da aplicao Web para que sejam

armazenados no banco de dados.

A classe Twitter instancia um cliente de EthernetClient para enviar requisies POST

contendo uma mensagem de texto, para o servidor do Twitter. O servidor, ao receber a

requisio exibe a mensagem de texto no Twitter.

33

A classe RestClient responsvel por enviar requisies HTTP para um determinado

servidor. Esta classe possui uma interface uniforme de acesso aos recursos, ou seja, nela esto

implementadas as funes get(), post(), put(), e delete(), referindo-se aos quatro principais

mtodos do protocolo HTTP (GET, POST, PUT e DELETE).

As classes virtuabotixRTC e dht11 so responsveis por acessar e fornecer os dados para

a placa Arduino do mdulo RTC (data e hora) e do sensor dht11 (temperatura e umidade),

respectivamente.

3.3 Arquitetura de hardware

Nesta seo sero abordados separadamente e com maior nvel de detalhes as partes

mais importantes dos componentes de hardware necessrios para a construo do prottipo.

Resumidamente, isto inclui a placa microcontroladora Arduino, sensores, atuadores, cabos e

shields.

3.3.1 O prottipo

O prottipo (Figura 13) consiste em uma lmpada inteligente, conectada via cabo de

rede Ethernet. Ela capaz de fornecer temperatura ambiente, data, hora e twittar. Todas suas

funcionalidades podem ser acessadas via pgina Web, ou seja, atravs de um computador,

smartphone ou tablet. E algumas delas por comandos de voz.

Os componentes de hardware necessrios para a construo do prottipo foram:

microcontrolador Arduino Mega 2560 R3, Ethernet Shield R3 juntamente com um cabo de rede

ethernet categoria 5e para conexo do Arduino Internet, Sensor Shield verso 4 juntamente

com cabos do tipo macho-fmea e fmea-fmea para conexo de sensores e atuadores, mdulo

de reconhecimento de voz V2 verso 2 e microfone para acionamento das funcionalidades do

dispositivo por comandos de voz, mdulo conversor USB-TTL para comunicao entre o

computador (USB) e o mdulo V2 (TTL), sensor de temperatura e umidade DHT11, mdulo

RTC DS1302 para fornecimento de data e hora real, display LED de 7 segmentos e 4 dgitos

para exibio de informaes ao usurio, um mdulo rel DC/AC 220 volts para acionamento

da lmpada e 2 baterias sendo uma de 3.3 volts para alimentar mdulo RTC e outra de 9 volts

para alimentar o Arduino.

34

Figura 13 - Hardware que compe o prottipo. Fonte: Compilado pelo autor.

3.3.2 Arduino Mega 2560 R3

O Arduino Mega 2560 (Figura 14) um microcontrolador baseado no ATmega2560. A

placa possui 54 pinos digitais de entrada/sada operando em 5 volts, e 16 pinos analgicos

de entrada. No caso dos pinos digitais, o que definir se ele ser de entrada ou sada, depender

do cdigo que foi escrito na IDE atravs da atualizao da funo pinMode().

Figura 14 - Pinos digitais e analgicos Arduino Mega 2560 R3 (imagem feita com Fritzing).

35

Destes 54 pinos, alguns possuem funes especficas, como por exemplo: 15 pinos

podem ser usados como sada PWM (pinos 2 a 13 e 44 a 46).

8 pinos so usados para receber (RX) e transmitir (TX) dados seriais TTL, portanto,

a placa Arduino pode enviar e receber dados de um computador ou outros mdulos ele

conectado. Estes pinos realizam comunicao serial por hardware construdo no chip, chamado

UART, isto permite que o chip Atmega receba dados seriais enquanto realiza outras tarefas,

desde que haja espao no buffer serial. Estes pinos so: Serial: 0 (RX) e 1 (TX), Serial 1: 19

(RX) e 18 (TX), Serial 2: 17 (RX) e 16 (TX), e por fim, Serial 3: 15 (RX) e 14 (TX). Os pinos

0 (RX) e 1 (TX) esto conectados aos correspondentes pinos do chip ATmega16U2 USB-para-

TTL Serial e so utilizados pela conexo USB da placa para upload de cdigo escrito na IDE.

Portando recomenda-se que nada esteja conectado nos pinos 0 e 1 no momento de upload do

cdigo (BANZI, 2011).

2 pinos so usados para comunicao TWI atravs da biblioteca Wire, que simplifica

o uso do bus TWI, so eles: 20 (SDA) e 21 (SCL).

4 pinos so usados para comunicao SPI atravs da biblioteca SPI, so eles: 50

(MISO), 51 (MOSI), 52 (SCK) e 53 (SS). 6 pinos podem ser configurados para disparar uma

interrupo, so eles: 2 (interrupo 0), 3 (interrupo 1), 18 (interrupo 5), 19 (interrupo

4), 20 (interrupo 3), e 21 (interrupo 2).

Os 16 pinos analgicos de entrada, so utilizados para a leitura de sensores que enviam

sinais contnuos, como por exemplo: sensores de luminosidade e potencimetros.

Diferentemente dos pinos digitais de entrada, que leem os estado de simples sensores, ON ou

OFF (BANZI, 2011).

Por fim, h os pinos AREF, que configura a voltagem usada pelos pinos analgicos de

entenda. E Reset, que quando pressionado reinicia a placa, e o programa armazenado no

microcontrolador executado novamente do incio (SCHMIDT, 2011).

Figura 15 - Conectores de alimentao do Arduino Mega 2560 R3 (imagem feita com Fritzing).

36

O fornecimento de energia pode ser tanto por conexo USB (5volts) como tambm

por uma fonte externa (adaptador AC-DC ou bateria, 7-12volts), e dar-se respectivamente,

atravs do conector USB, ou do conector DC power jack ou pelos pinos Gnd e Vin presentes

no conector POWER da placa, como pode ser visto na Figura 15 (RILEY, 2012).

A voltagem recomendada para operar de 7 a 12 volts e a fonte de energia (conexo

USB ou fonte externa) selecionada automaticamente, isto significa que, se no houver uma

fonte externa, a alimentao ser feita pela conexo USB, uma vez que, seja conectada uma

fonte externa, a placa automaticamente deixar de usar a conexo USB e passar a usar a fonte

externa (BANZI, 2011).

Quanto a memria, o chip ATmega2560 do Arduino Mega 2560 possui 256 KB de

memria flash para armazenamento do cdigo escrito com a IDE. Destes 256 KB, 8 KB usado

pelo bootloader. O bootloader um pequeno programa que permite o upload de cdigo sem o

uso de hardware adicional (KRINGEN, 2013). Alm disso, ele possui 8 KB de SRAM e 4 KB

de EEPROM.

3.3.3 Ethernet Shield R3

A placa Ethernet (Figura 16) baseada no chip Wiznet W5100. Este chip fornece pilha

TCP/IP, suportando: TCP, UDP, IPv4, ICMP, IGMP, ARP e PPPoE. Possui um buffer interno

de 16Kbytes para transmisso de dados e suporta at quatro conexes de socket simultneas

(WIZNET, 2014).

O shield Ethernet fornece funcionalidade extra placa Arduino, permitindo-a conectar-

se Internet. Para isso, basta encaix-lo acima da placa Arduino Mega 2560 em seus respectivos

pinos, conect-lo rede atravs de um cabo RJ45 e escrever o cdigo fazendo uso das

bibliotecas Ethernet e SPI.

A biblioteca Ethernet fornece as classes necessrias que permitir a conexo da placa

Arduino Internet, suportando at quatro conexes concorrentes, sendo estas conexes, de

entrada, sada ou ambas (RILEY, 2012).

J a biblioteca SPI, permite a comunicao da placa Arduino com o shield Ethernet, isto

inclui, o chip W5100 e o slot para carto micro SD, usando o bus SPI, atravs do cabealho

ICSP (RILEY, 2012).

37

Figura 16 - Arduino Ethernet Shield R3 (imagem feita com Fritzing).

Como o chip W5100 e o slot micro SD compartilham o bus SPI, apenas um pode estar

ativo/selecionado por vez. Para isso, utiliza-se os pinos 4 (SS para micro SD) ou 10 (SS para

controle Ethernet). O pino 53 (hardware SS), no usado para seleo entre W5100 ou SD,

mas este pino deve ser posto como output para que a interface SPI funcione (MARGOLIS,

2011).

Desta forma, caso ambos sejam utilizados (W5100 e SD) as bibliotecas correspondestes

sero responsveis pelo compartilhamento do bus SPI. Mas, caso apenas um dos dois seja

utilizado, quele que no for usado, deve explicitamente ser desativado, para isso, coloca-se o

pino correspondente como output e high.

Os pinos utilizados na comunicao do Arduino com o chip W5100 e o slot micro SD

do shield Ethernet, so: 50, 51 e 52. Como tambm os j citados anteriormente, pinos: 4 (SS

para micro SD), 10 (SS para controle Ethernet) e 53 (hardware SS), ilustrados na Figura 17.

Desta forma, estes pinos no podem ser utilizados como entrada/sada. Para que a comunicao

com o micro SD ocorra, necessrio o uso da biblioteca SD (MARGOLIS, 2011).

Figura 17 - Pinos de comunicao do Arduino Mega 2560 com o chip W5100 e micro SD (imagem

feita com Fritzing).

38

A alimentao do shield Ethernet proporcionada pela placa Arduino, operando com

uma voltagem de 5 volts e velocidade de conexo de 10/100Mb. No shield encontra-se LEDs

indicadores que fornecem informaes sobre alimentao e aspectos relacionados rede, so

eles: PWR (a placa e o shield esto alimentados), LINK (presena de cabo de rede e pisca

quando ocorre a transmisso ou recebimento de dados), FULLD (conexo de rede full duplex),

100M (presena de conexo de rede de 100 Mb/s), RX (pisca quando o shield recebe dados),

TX (pisca quando o shield envia dados) e COLL (pisca quando detecta-se coliso na rede)

(WIZNET, 2014).

3.3.4 Sensor shield verso 4

O sensor shield permite a fcil conexo de dispositivos de entrada e sada nas interfaces

I2C ou UART, analgicas e digitais do Arduino, necessitando apenas de cabos dedicados.

Como exemplo destes dispositivos, pode-se citar os sensores (temperatura, luminosidade,

acelermetro, etc.) e os atuadores (displays, autofalantes, motores, etc.).

Alm de facilitar a conexo de sensores e atuadores placa Arduino, este shield

evita/substitui a utilizao de uma placa breadboard/protoboard, para a conexo dos mesmos.

O breadboard ou protoboard, ilustrado na Figura 18, uma placa que permite a montagem de

circuitos experimentais, ou seja, sem que haja a necessidade de soldar os componentes do

circuito. Desta forma, erros na montagem do circuito podem ser facilmente corrigidos com a

mudana do circuito (OLSSON, 2012).

Figura 18 - Breadboard (imagem feita com Fritzing).

O sensor shield conecta cada pino (analgico ou digital) do Arduino com conectores do

shield que j esto preparados para conectar-se com sensores e atuadores, ou seja, cada conector

possui os pinos VCC (5 volts), GND (ground) e signal (SEEED, 2014).

No caso dos pinos analgicos, estes tambm esto conectados a conectores buckled que

tambm possuem os pinos VCC, GND e signal. Os conectores buckled possuem travas que

proporcionam maior segurana no encaixe/conexo, evitando que os cabos conectados aos

39

pinos soltem-se, o que pode ocorrer com os demais conectores que possuem apenas pinos

(SEEED, 2014).

Alm disso, o shield possui mais uma porta (conector buckled) para comunicao I2C

ou UART, que podem ser selecionados atravs de dois jumpers localizados atrs da mesma.

Esta porta de comunicao possui quatro pinos, so eles: VCC, GND, TX/SDA (transmisso)

e RX/SCL (recebimento) (KING, 2014). A Figura 19 mostra todo o esquema descrito

anteriormente.

Figura 19 - Sensor Shield Verso 4, adaptado de (SEEED, 2014).

3.3.5 Mdulo de reconhecimento de voz V2

O V2 opera entre 4.5 a 5.5 volts, possui interface digital TTL UART (comunicao

serial) e GPIO (GCH e GCL: para importao dos grupos / O1~O5: para sada do resultado de

comando de voz), interface analgica para conexo de microfone 3.5mm e pinos (GND e VOC)

para microfone. Dois LEDs, um laranja e outro vermelho, so usados como indicadores para os

modos de gravao, espera e reconhecimento, como mostra a Figura 20. Este mdulo

dependente de locutor, ou seja, pode no reconhecer a voz de outras pessoas (SHEN, 2014).

O mdulo de reconhecimento de voz V2, recebe comandos de configurao e responde

aos comandos de voz atravs da interface da porta serial. Os comandos enviados no sero

apagados quando no haja alimentao (SHEN, 2014).

40

Figura 20 - Mdulo de reconhecimento de voz V2, adaptado de (SHEN, 2014).

No total, permitido o armazenamento de at 15 comandos de voz. Estes, so divididos

em 3 grupos com 5 comandos de voz cada, podendo cada instruo de voz ter um comprimento

mximo de at 1300ms. A gravao feita em 1 grupo por vez, para isso necessrio o envio

do comando hexadecimal atravs da porta serial no formato Head + Key, sendo Head 0xaa

e Key uma lista de 47 comandos. Uma vez que, a gravao do grupo termine necessrio sua

importao para que o mdulo possa reconhecer os comandos de voz, para isso, envia-se atravs

da serial o comando correspondente (SHEN, 2014).

A lista dos 47 comandos so utilizados para realizao de configuraes do mdulo,

dentre elas, cita-se algumas: deletar, importar e iniciar gravao de instrues, alterar baud rate

(taxa de dados em bits por segundo para transmisso de dados na serial), eleio de modo

comum ou compacto, etc. Para maiores informaes sobre os comandos, consultar manual

Voice Recognition Module V2 disponvel no link da referncia (SHEN, 2014).

O V2, permite a importao de apenas 1 grupo por vez, ou seja, uma vez gravada as

instrues dos 3 grupos, o mdulo s reconhecer as 5 instrues de 1 grupo apenas. As

instrues dos outros dois grupos no sero reconhecidas, j que, necessrio a importao de

determinado grupo para que o mdulo realize o reconhecimento. Quando enviado e reconhecido

o comando de voz pelo mdulo, este, retorna pela porta serial por exemplo o resultado 11,

significando que foi reconhecido o primeiro comando (dos cinco existentes) do grupo 1 (SHEN,

2014).

41

3.3.6 Mdulo conversor USB-TTL

O mdulo conversor USB-TTL (Figura 21) foi utilizado para comunicao (envio e

recebimento de comandos seriais) entre o computador (USB) e o mdulo de reconhecimento

de voz V2 (TTL), uma vez que, este no tem suporte USB.

O mdulo USB-TTL contm um chip que converte o hardware da porta serial do chip

do mdulo V2 para USB. Desta forma, pode ser feita a conexo com o hardware da porta serial

(MARGOLIS, 2011).

Figura 21 - Mdulo conversor USB-TTL. Fonte: Compilado pelo autor.

Sendo assim, talvez, deva estar pensando: Se o Arduino Mega comunica-se (envia e

recebe dados atravs do hardware de porta serial) com o computador atravs de um cabo USB,

como ento possvel que ocorra a comunicao?.

simples, como mencionado na Seo 3.2.3 da arquitetura de hardware, o Arduino

Mega possui quatro hardwares de porta serial, sendo que, apenas o hardware da porta serial

(Serial: pinos, 0 (RX) e 1 (TX)) tem suporte USB, ou seja, realiza a converso USB-TTL

automaticamente. J os demais hardwares de porta serial (Serial 1: 19 (RX) e 18 (TX), Serial

2: 17 (RX) e 16 (TX), e Serial 3: 15 (RX) e 14 (TX)), no tem suporte USB, havendo desta

forma a necessidade de utilizao do mdulo conversor USB-TTL (MARGOLIS, 2011).

3.3.7 Sensor de temperatura e umidade DHT11

O DHT11 (Figura 22) um sensor digital de temperatura e umidade de baixo custo. Ele

monitora o ar do ambiente ao seu redor e emite sinais digitais atravs de seu pino signal, a

transmisso do sinal digital por fio pode chegar at 20 metros. Sua alimentao varia entre 3.5

at 5 volts DC (D-ROBOTICS, 2014).

As leituras podem ocorrer no mnimo a cada 2 segundos. Para temperatura, a variao

de leitura de 0 at 50C (celsius), com uma preciso de 2C para mais ou para menos. J em

relao umidade, a variao de 20 a 90% RH (Relative Humidity), com preciso de 5% RH

para mais ou para menos (D-ROBOTICS, 2014).

42

Este sensor possui um componente de resistncia de medio de umidade, como

tambm, um componente NTC (Negative Temperature Coefficient) de medio de temperatura.

Ambos esto conectados um microcontrolador 8-bit de alta performance. A calibrao dos

coeficientes de temperatura e umidade so armazenados como programas em sua memria OTP

(One Time Programmable) do tipo PROM (D-ROBOTICS, 2014).

Figura 22 - Sensor de temperatura e umidade DHT11, adaptado de (D-ROBOTICS, 2014).

Quando comunicao, as leituras realizadas pelo sensor DHT11 so enviadas pelo

pino de sada digital utilizando apenas um nico fio. A comunicao ocorre em trs estgios:

requisio, resposta e leitura de dados.

Os dados so enviados em um pacote de 5 segmentos com 8-bit cada um, totalizando

um pacote de 40 bits. Neste pacote, os 2 primeiros segmentos referem-se leitura da umidade,

sendo o 1 segmento a parte inteira e o 2 segmento a parte decimal do nmero que compe a

umidade (D-ROBOTICS, 2014).

O terceiro e quarto segmento, referem-se leitura da temperatura, sendo o 3 segmento

a parte inteira e o 4 segmento a parte decimal do nmero que compe a temperatura (D-

ROBOTICS, 2014).

O 5 e ltimo segmento, refere-se ao check sum, soma dos quatro primeiros segmentos,

utilizado para saber se os dados recebidos esto corretos (D-ROBOTICS, 2014). Para maiores

informaes sobre funcionamento do sensor DHT11, consultar manual disponvel no link da

referncia.

3.3.8 Mdulo RTC DS1302

O mdulo DS1302 um relgio/calendrio de tempo real que fornece segundos,

minutos, horas, data do ms, ms, dia da semana e ano, incluindo ano bissexto at 2100. Possui

31 bytes de memria RAM esttica e comunica-se com o microprocessador por interface serial

(MAXIM, 2014).

43

A comunicao entre o mdulo RTC e o Arduino ocorre atravs dos pinos CE, I/O e

SCLK, conhecido como 3-wire interface, como mostra a Figura 23. Os dados so transferidos

1 byte por vez, ou os 31 bytes de uma vez s, sendo esta ltima a opo recomendada, j que

evitaria dados errneos. Os pinos X1 e X2 esto conectados ao cristal de quartzo (MAXIM,

2014).

Figura 23 - Mdulo Real-Time Clock DS1302, adaptado de (MAXIM, 2014).

O DS1302 possui duas fontes de alimentao, uma primria e outra secundria, e dar-

se atravs dos pinos Vcc2 e Vcc1, respectivamente. A primria fornecida pelo Arduino,

operando em 5 volts, j a secundria por uma bateria de 3.3 volts que pode durar at 10 anos. A

fonte secundria s ser utilizada apenas quando no houver fornecimento de energia por parte

do Arduino (MAXIM, 2014). Para maiores informaes sobre o mdulo RTC DS1302

consultar manual disponvel no link da referncia.

3.3.9 Display LED de 7 segmentos e 4 dgitos

O display LED possui 4 dgitos com 7 segmentos cada um. Nele encontra-se 12 pinos,

onde cada um deles representam ou um dgito ou um segmento. Os pinos, 12, 9, 8 e 6

representam os dgitos 1, 2, 3 e 4, respectivamente. J os demais pinos, 11, 7, 4, 2, 1, 10, 5 e 3

representam os oitos segmentos que compem um dgito, so eles: A, B, C, D, E, F, G e DP

(decimal point), como exemplificado na Figura 24 (MARGOLIS, 2011).

44

Neste projeto, o display foi usado para exibio de informaes ao usurio, tais como:

data, hora e temperatura. Para a exibio dos nmeros, necessrio o acendimento de

combinaes de segmentos que representem um nmero (MARGOLIS, 2011).

Figura 24 - Display LED de 7 segmentos e 4 dgitos com seus respectivos pinos. Fonte: Compilado

pelo autor.

3.3.10 Mdulo rel DC/AC 220 volts

O mdulo rel utilizado para o acionamento de atuadores que necessitam de grande

quantidade de energia para funcionar. Estes, geralmente so alimentados por baterias ou at

mesmo por energia eltrica, ou seja, voltagens bem maiores que os 5 volts que o Arduino pode

oferecer (MARGOLIS, 2011).

O rel ativado/desativado atravs dos 5 volts do Arduino, quando isso ocorre, gera-se

um campo eletromagntico que faz com que a bobina contida no rel mova a armadura fazendo

com que o terminal comum entre em contato com o terminal normalmente aberto. Isto fechar

o circuito, e consequentemente, permitir a passagem de uma corrente maior at o atuador

(OSULLIVAN, 2004).

Mas, para que tudo ocorra de forma segura, sem que esta corrente maior possa danificar

a placa Arduino, necessrio a utilizao de componentes que iro isolar e proteger os circuitos.

45

Estes componentes so: transistor, resistor, diodo e fotoacoplador. Todos eles, j esto includos

no circuito do mdulo rel, como pode ser visto na Figura 25 (OSULLIVAN; IGOE, 2004).

Figura 25 - Mdulo rel isolado 5 volts. Fonte: Compilado pelo autor.

3.3.11 Cabos

Neste projeto foi necessrio a utilizao de alguns cabos, seja para comunicao entre o

computador e a placa Arduino, conexo do shield Ethernet rede, como tambm para a conexo

de sensores e atuadores ao Arduino.

O cabo USB A-B, mostrado na Figura 26, foi utilizado para comunicao entre o

Arduino e o computador, sendo necessrio para a transferncia do cdigo escrito na IDE para

o chip do microcontrolador. Utilizou-se tambm um cabo de rede ethernet categoria 5e (Figura

27) para conectar o Arduino Internet, atravs do shield Ethernet.

Os cabos utilizados para conexo dos sensores e atuadores ao Arduino, so de dois tipos.

O primeiro (lado esquerdo da Figura 28) possui conectores fmea em ambos os lados. J o outro

(lado direito) possui um conector macho e outro fmea em cada extremidade.

Figura 26 - Cabo USB A-B. Fonte: Compilado pelo autor.

46

Figura 27 - Cabo de rede Ethernet categoria 5e. Fonte: Compilado pelo autor.

Figura 28 - Cabos fmea-fmea e cabos macho-fmea. Fonte: Compilado pelo autor.

47

4 AVALIAO DE DESEMPENHO DAS FUNCIONALIDADES DO ARDUINO EM

TEMPO DE EXECUO

Este captulo apresenta os resultados obtidos na avaliao do consumo de memria e

tempo de execuo necessrios para desempenhar cada funcionalidade em condies normais

de uso. A lmpada inteligente possui um total de sete tarefas, umas so executadas

automaticamente pelo prprio microcontrolador, outras, solicitadas pelo usurio atravs de

comandos de voz, ou remotamente com o envio de requisies HTTP por meio da aplicao

Web desenvolvida neste trabalho.

As sete atividades em questo so: exibio da data, hora ou temperatura ambiente no

display LED; postar twitter contendo informaes de temperatura, umidade e estado da

lmpada; acender e apagar lmpada por comandos de voz, como tambm, de forma remota; e

por fim, enviar automaticamente dados de temperatura e umidade ambiente para o servidor da

aplicao Web.

As atividades de exibio da data, hora e temperatura ambiente no display LED so

realizadas atravs de comandos de voz. Enquanto que as atividades de postar twitter e controlar

a lmpada, que tambm so acionadas por comandos de voz, enviam requisies HTTP.

A primeira, envia requisies HTTP POST para o Twitter contendo no corpo da

mensagem da requisio informaes de temperatura e umidade ambiente, e estado da lmpada,

obtidos no momento da solicitao da funcionalidade pelo usurio.

A segunda, envia requisies HTTP PUT para o servidor da aplicao Web contendo

no corpo da requisio em formato JSON, o estado da lmpada, a fim de manter atualizado a

representao Web deste objeto.

A funcionalidade de controlar a lmpada tambm pode ser efetuada remotamente,

atravs do envio de requisies HTTP PUT pelo usurio da aplicao Web. Nesta requisio

informado o recurso que deseja ser acessado, como tambm, uma mensagem em formato texto

plano (text/plain) no corpo da mensagem, definindo se a lmpada deve ser acendida ou apagada.

Por fim, a funcionalidade de envio automtico da temperatura e umidade para o servidor

da Aplicao, consiste em enviar requisies HTTP POST contendo no corpo da mensagem da

requisio em formato JSON os dados em questo.

4.1 Consumo de memria

O Arduino Mega 2560 possui trs tipos de memria, so elas: flash, SRAM e EEPROM.

A memria flash onde fica armazenado o cdigo Arduino, sua capacidade total de 256

KBytes, sendo 8 KByte reservado para o bootloader (necessrio para upload de cdigo). A

48

memria EEPROM possui capacidade mxima de 4 KBytes e pode ser utilizada pelo

programador para armazenar informaes persistentes. Por fim, a memria SRAM com

capacidade de 8 KBytes, onde as variveis so criadas e manipuladas em tempo de execuo.

As memrias flash e EEPROM so do tipo no-voltil, significando que, as informaes nela

contidas persistiro quando no haja fornecimento de energia, ao contrrio da SRAM que

voltil.

A avaliao do consumo da memria utilizada para desempenhar cada funcionalidade

foi feita na SRAM do Arduino, visto que, esta a nica memria que apresenta variaes de

espaamento em tempo de execuo. A Figura 29 apresenta a quantidade de memria

consumida no Arduino, nos diferentes tipos de memria.

Figura 29 - Consumo das diferentes memrias do Arduino Mega 2560. Fonte: Arduino Builder.

Pode-se observar que na memria flash o cdigo do Arduino ocupa cerca de 22 KBytes,

o que representa 8.4% de espao da memria. J na memria SRAM, as variveis do cdigo

Arduino ocupam 1.8 KBytes, ou 22.5% da capacidade total, restando 6.3 KBytes para criao

e manipulao das variveis em tempo de execuo. Por fim, a memria EEPROM que no foi

utilizada para armazenar dados, resultando em 100% de espao livre.

O consumo de memria envolve todas as variveis, variveis de funes e objetos,

necessrios para a realizao da tarefa. Para realizar esta medio, utilizou-se a biblioteca

MemoryFree, que fornece a funo freeMemory(), para verificar em tempo de execuo a

quantidade de memria disponvel na SRAM do Arduino. Para a obteno dos valores

referentes a memria consumida, realizou-se o clculo da diferena entre a quantidade de

memria livre antes do incio da realizao da tarefa, com a quantidade de memria livre aps

a tarefa ser desempenhada por completo. A Figura 30 apresenta os resultados obtidos da

49

avaliao de consumo de memria em bytes para cada uma das sete funcionalidades executadas

pela lmpada inteligente.

Figura 30 - Consumo de memria para desempenhar cada funcionalidade da lmpada inteligente.

Fonte: Compilado pelo autor.

Observa-se que a quantidade de memria consumida para atender a cada uma das

atividades varia entre 27 para 108 bytes apenas. Sabendo que microcontroladores so

dispositivos com restries de memria, no caso do Arduin