Daniel Rosendo

UNIVERSIDADE DE PERNAMBUCO
FACULDADE DE CIÊNCIAS E TECNOLOGIA DE CARUARU
BACHARELADO EM SISTEMAS DE INFORMAÇÃO
DANIEL ROSENDO
INTEGRANDO FUNCIONALIDADES DO ARDUINO À INTERNET ATRAVÉS DE
RECURSOS WEB
CARUARU
2014
DANIEL ROSENDO
INTEGRANDO FUNCIONALIDADES DO ARDUINO À INTERNET ATRAVÉS DE
RECURSOS WEB
Monografia apresentada ao Curso de Sistemas de
Informação, Faculdade de Ciências e Tecnologia
de Caruaru da Universidade de Pernambuco, como
requisição parcial à obtenção do título de Bacharel.
Orientadora: Profª. Msc. Patricia Takako Endo
CARUARU
2014
Dedico este trabalho aos meus pais e irmãos.
AGRADECIMENTOS
Agradeço primeiramente a DEUS por proporcionar mais uma conquista na minha vida.
Por ter me abençoado a cada dia, por ter me dado saúde, sabedoria, força e paciência durante
esta longa jornada que durou quatro anos e meio.
Agradeço à minha família, meu pai (Djalma Rosendo) e minha mãe (Luzineide
Rosendo) por terem me educado e estarem sempre ao meu lado, cuidando e incentivando.
Agradeço ainda à minha mãe pelas comidas deliciosas que só ela sabe fazer e que me deram
energia para a realização deste trabalho. Agradeço aos meus irmãos (Diomedes e Diogo
Rosendo) pelo apoio.
Agradeço à minha grande orientadora Profª. Patricia Takako Endo, pela confiança
depositada e pela disponibilização, atenção, competência, paciência e mensagens
motivacionais.
Agradeço aos meus primos e amigos que me acompanharam nesta jornada e que
contribuíram indiretamente com este trabalho.
Por fim, agradeço à todos os professores do curso de Sistemas de Informação da UPE
Caruaru, que tiveram um importante papel em minha formação acadêmica proporcionando
grande parte do conhecimento necessário para realização deste trabalho.
RESUMO
Nos últimos anos tem-se aumentado a quantidade de objetos inteligentes conectados à
Internet. A tendência é que esta quantidade cresça consideravelmente nos anos seguintes. Isto
se deve ao surgimento e popularização de dispositivos, tais como smartphones, tablets, sensores
sem fio, entre outros. A Web das Coisas utiliza protocolos e padrões da Web que permitem a
integração de objetos físicos na Web, a fim de obter-se uma representação dos mesmos como
recursos na Web. Desta forma, torna-se possível acessar e controlar remotamente estes objetos,
como também, armazenar, gerenciar e exibir os dados gerados em tempo real por eles. Neste
trabalho será desenvolvido uma lâmpada inteligente construída com hardware Arduino, como
também, uma aplicação Web baseado na Web das Coisas para disponibilização na Web da
lâmpada 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 bulb´s 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 reúne Pessoas, Coisas, Dados e Processos. Fonte:
CISCO. ..................................................................................................................................... 13
Figura 2 - Tipos de conexões 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 - Página Web da representação do objeto físico na Web. Fonte: Compilado pelo autor.
.................................................................................................................................................. 24
Figura 5 - Requisição HTTP GET para obtenção da representação do objeto. Fonte: Criado
pelo autor. ................................................................................................................................. 24
Figura 6 - Tabela de rotas da aplicação para o recurso objetos. Fonte: Elaborado pelo autor.25
Figura 7 - Classe ObjetosController e métodos especificados no arquivo de configuração de
rotas da aplicação. Fonte: Elaborado pelo autor. ...................................................................... 26
Figura 8 - Requisição HTTP POST que envia os dados do sensor dht11 do Arduino. Fonte:
Criado pelo autor. ..................................................................................................................... 27
Figura 9 - Requisição HTTP PUT enviada ao Arduino para alterar o estado da lâmpada. Fonte:
Criado pelo autor. ..................................................................................................................... 27
Figura 10 - Diagrama de classes do pacote controllers da aplicação Web. Fonte: Elaborado
pelo autor. ................................................................................................................................. 30
Figura 11 - Diagrama de classes do pacote models da aplicação Web. Fonte: Elaborado pelo
autor. ......................................................................................................................................... 31
Figura 12 - Principais classes executadas no Arduino Mega 2560. Fonte: Elaborado pelo autor.
.................................................................................................................................................. 32
Figura 13 - Hardware que compõe o protótipo. Fonte: Compilado pelo autor. ...................... 34
Figura 14 - Pinos digitais e analógicos Arduino Mega 2560 R3 (imagem feita com Fritzing).
.................................................................................................................................................. 34
Figura 15 - Conectores de alimentação 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 comunicação 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 Versão 4, adaptado de (SEEED, 2014). ......................................... 39
Figura 20 - Módulo de reconhecimento de voz V2, adaptado de (SHEN, 2014).................... 40
Figura 21 - Módulo conversor USB-TTL. Fonte: Compilado pelo autor. .............................. 41
Figura 22 - Sensor de temperatura e umidade DHT11, adaptado de (D-ROBOTICS, 2014). 42
Figura 23 - Módulo Real-Time Clock DS1302, adaptado de (MAXIM, 2014). ..................... 43
Figura 24 - Display LED de 7 segmentos e 4 dígitos com seus respectivos pinos. Fonte:
Compilado pelo autor. .............................................................................................................. 44
Figura 25 - Módulo 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 fêmea-fêmea e cabos macho-fêmea. Fonte: Compilado pelo autor. .......... 46
Figura 29 - Consumo das diferentes memórias do Arduino Mega 2560. Fonte: Arduino Builder.
.................................................................................................................................................. 48
Figura 30 - Consumo de memória para desempenhar cada funcionalidade da lâmpada
inteligente. Fonte: Compilado pelo autor. ................................................................................ 49
Figura 31 - Tempo para executar cada funcionalidade da lâmpada inteligente. Fonte:
Compilado pelo autor. .............................................................................................................. 50
LISTA DE ABREVIATURAS E SIGLAS
API
ARP
EEPROM
HATEOAS
HTTP
I2C
ICMP
IDE
IGMP
IoT
IP
IPv4
IPv6
MEMS
MISO
MOSI
NTC
OTP
PPPoE
PROM
PWM
REST
RFID
RH
ROA
RTC
RX
SCK, SCL, SCLK
SDA
SOAP
SPI
SRAM
SS
TCP
TTL
TWI
TX
UART
UDDI
UDP
URI
USB
WoT
WSDL
Application Programming Interface
Address Resolution Protocol
Electrically-Erasable Programmable Read-Only Memory
Hypermedia as Engine Of Application State
Hipertext Transfer Protocol
Inter-Integrated Circuit
Internet Control Message Protocol
Integrated Development Environment
Internet Group Management Protocol
Internet of Things
Internet Protocol
Internet Protocol version 4
Internet Protocol version 6
Microelectromechanical Systems
Master Input, Slave Output
Master Output, Slave Input
Negative Temperature Coefficient
One Time Programmable
Point-to-Point Protocol over Ethernet
Programmable Read-Only Memory
Pulse Width Modulation
Representational State Transfer
Radio Frequency Identification
Relative Humidity
Resource-Oriented Architecture
Real-Time Clock
Receive
Serial Clock
Serial Data
Simple Object Access Protocol
Serial Peripheral Interface
Static Random Access Memory
Slave Chip Select
Transmission Control Protocol
Transistor-Transistor Logic
Two Wire Interface
Transmit
Universal Asynchronous Receiver Transmitter
Universal Description, Discovery and Integration
User Datagram Protocol
Uniform Resource Identifier
Universal Serial Bus
Web of Things
Web Services Description Languages
SUMÁRIO
1 INTRODUÇÃO ................................................................................................................... 10
1.1 Problema ............................................................................................................................. 10
1.2 Objetivos............................................................................................................................. 11
1.2.1 Geral ................................................................................................................................ 11
1.2.2 Específicos ....................................................................................................................... 11
1.3 Justificativa ......................................................................................................................... 11
1.4 Organização do trabalho ..................................................................................................... 12
2 FUNDAMENTAÇÃO TEÓRICA ...................................................................................... 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 Princípios REST .............................................................................................................. 19
2.5 Plataforma Arduino ............................................................................................................ 21
3 INTEGRANDO FUNCIONALIDADES DO ARDUINO À WEB .................................. 23
3.1 Aplicando os princípios REST para expor funcionalidades do Arduino na Web .............. 23
3.2 Arquitetura de software ...................................................................................................... 27
3.2.1 Aplicação 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 Lâmpada inteligente construída 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 protótipo....................................................................................................................... 33
3.3.2 Arduino Mega 2560 R3 ................................................................................................... 34
3.3.3 Ethernet Shield R3 ........................................................................................................... 36
3.3.4 Sensor shield versão 4 ..................................................................................................... 38
3.3.5 Módulo de reconhecimento de voz V2 ............................................................................ 39
3.3.6 Módulo conversor USB-TTL .......................................................................................... 41
3.3.7 Sensor de temperatura e umidade DHT11 ....................................................................... 41
3.3.8 Módulo RTC DS1302...................................................................................................... 42
3.3.9 Display LED de 7 segmentos e 4 dígitos ......................................................................... 43
3.3.10 Módulo relé DC/AC 220 volts....................................................................................... 44
3.3.11 Cabos ............................................................................................................................. 45
4 AVALIAÇÃO DE DESEMPENHO DAS FUNCIONALIDADES DO ARDUINO EM
TEMPO DE EXECUÇÃO ..................................................................................................... 47
4.1 Consumo de memória ......................................................................................................... 47
4.2 Tempo para executar funcionalidade .................................................................................. 49
5 CONCLUSÕES.................................................................................................................... 51
5.1 Trabalhos futuros ................................................................................................................ 52
REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................. 53
10
1 INTRODUÇÃO
O conceito de Internet das Coisas (do inglês, 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 heterogêneos e endereçáveis
interligados e se comunicando através de protocolos de comunicação padronizáveis. Portanto,
segundo a IoT, cada objeto torna-se endereçável e controlável (KARIMI, 2013).
Esses objetos, geralmente dispositivos embarcados, tais como eletrodomésticos,
sensores sem fio e máquinas podem estar conectados à Internet. Exemplos desses dispositivos
são: Sun SPOTs (Sun 2011), Nabaztag (Nabaztag 2011), Poken (Poken 2011), Arduino
(Arduino 2005), etc. Neste trabalho será utilizado o Arduino, uma plataforma de prototipagem
eletrônica de hardware livre que possibilita criar ferramentas que são acessíveis, de baixo custo,
flexíveis e fáceis de usar.
Uma vez estes objetos conectados à Internet, o próximo objetivo da Internet das Coisas
refere-se a capacidade de comunicação e controle de forma remota desses objetos fazendo com
que os mesmos realizem ações sem a intervenção humana. Portanto, o próximo passo da
Internet das Coisas é a Web das Coisas (GUINARD et al. 2010).
A Web das Coisas (do inglês, Web of Things - WoT) é um paradigma de
desenvolvimento de aplicações inspirado na Internet das Coisas, baseado no uso de protocolos
e padrões já em uso na Web, como por exemplo HTTP (Hypertext Transfer Protocol) e URIs
(Uniform Resource Identifier). Seu objetivo é proporcionar a conexão de diversos objetos
inteligentes à Web, tornando-os parte da Web, de forma que possam ser acessados da mesma
forma que qualquer outro recurso disponível na mesma (GUINARD et al. 2010).
Para que esta conexão seja possível, a Web das Coisas faz uso dos princípios 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 princípios REST no
desenvolvimento de sistemas, já que este não trata-se de uma arquitetura. Sendo assim, ROA
especifica como utilizar os princípios REST juntamente com os padrões Web HTTP e URI
(FRANÇA, 2011).
1.1 Problema
Objetos inteligentes ou smart objects são objetos que possuem processadores embutidos
(por exemplo: microcontrolador) juntamente com interfaces de usuário que permitem controlar
suas funcionalidades (KARIMI, 2013). Uma vez que, tem-se objetos inteligentes, o próximo
11
passo é permitir uma conexão remota à esses objetos a fim de poder controlá-los, facilitando a
vida das pessoas. Como por exemplo, apagar a lâmpada da casa ou checar o fechamento da
porta ao sair, tudo através do computador, tablet ou smartphone (KARIMI, 2013).
Segundo estimativa realizada pela Cisco IBSG (Internet Business Solutions Group) foi
previsto que em 2015 terão 7.2 bilhões de pessoas vivendo no planeta e 25 bilhões de
dispositivos (smart objects) conectados à Internet. E em 2020 terão 7.6 bilhões de pessoas e 50
bilhões 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 bilhões de objetos inteligentes controláveis e conectados à Internet,
pode-se agora disponibilizá-los na Web. Permitindo assim, o gerenciamento e armazenamento
de informações em tempo real, como também interagir com os objetos e suas informações.
Desta forma, é de grande importância saber quais arquiteturas, protocolos e padrões
amplamente aceitos e já em uso na Web deve ser utilizado.
1.2 Objetivos
1.2.1 Geral
Desenvolver uma aplicação Web para a disponibilização das funcionalidades de
dispositivo Arduino na forma de recursos Web.
1.2.2 Específicos

Identificar protocolos e padrões já em uso na Web tradicional;

Apontar os princípios REST na criação 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 tendência é que essa quantidade cresça
exponencialmente, de forma que tais objetos estarão cada vez mais presentes em residências,
centros de saúde, instituições de ensino, governo, companhias de energia, etc. (BRADLEY et
al. 2013b).
12
Desta forma, é de extrema importância saber fazer com que tais dispositivos trabalhem
colaborativamente, através da troca de informações entre si, como também, tirar proveito desses
dispositivos inteligentes tornando-os acessíveis na Web.
Do ponto de vista teórico, este trabalho servirá como fonte de pesquisa para os demais
trabalhos nesta área, como também, auxiliará no entendimento de quais ferramentas,
arquiteturas e tecnologias podem ser utilizadas no ambiente da Web das Coisas.
Quanto ao ponto de vista prático, contribuirá para a concretização do paradigma da Web
das Coisas, fazendo com que as funcionalidades do dispositivo Arduino estejam disponíveis e
acessíveis na Web.
1.4 Organização do trabalho
Este trabalho está organizado em 5 capítulos. O Capítulo 2 apresenta os conceitos
relacionados a Internet de Todas as Coisas, Internet das Coisas, Web das Coisas, REST e seus
princípios e a plataforma Arduino. O Capítulo 3 apresenta o emprego dos princípios REST na
abordagem ROA para integração do objeto inteligente na aplicação Web desenvolvidos neste
trabalho. Ademais, apresenta-se a arquitetura de hardware e software dos mesmos. No Capítulo
4 apresenta-se os resultados obtidos da avaliação de desempenho do Arduino em tempo de
execução, referentes ao consumo de memória e tempo necessário para executar cada uma das
funcionalidades do objeto inteligente. Por fim, no Capítulo 5 apresentam-se as conclusões e
sugestões de trabalhos futuros que possam aprimorar e expandir as funcionalidades da aplicação
Web e do objeto inteligente.
13
2 FUNDAMENTAÇÃO TEÓRICA
2.1 Internet de Todas as Coisas
A Internet de Todas as Coisas (do inglês, Internet of Everything - IoE) consiste na
conexão em rede de pessoas, coisas, dados e processos, a fim de criar conexões de rede mais
relevantes e de grande valor. Cada um destes componentes possuem um papel específico e
trabalham juntos, como mostrado na Figura 1 (MITCHELL et al. 2013).
Figura 1 - A Internet de Todas as Coisas reúne 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 serão capazes de
conectar-se à Internet de várias formas. Atualmente, a maioria delas conectam-se através 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 conectarão de forma mais relevante,
como por exemplo: as pessoas tomarão uma pílula que terá a capacidade de medir algumas
características do trato digestivo e enviar esta informação por Internet ao médico. Outro
exemplo, seria o uso de sensores localizados na pele ou na roupa das pessoas, a fim de fornecer
informações dos sinais vitais e enviar à um médico (MITCHELL et al. 2013).
Na IoE, os dados serão transformados em informação útil no momento adequado para
a rápida tomada de decisões inteligentes, como também, controlar o ambiente de forma mais
eficiente. Estes dados, serão proporcionados através dos milhares de sensores (MITCHELL et
al. 2013).
14
As coisas ou Internet das Coisas é uma das transições de tecnologia que proporcionam
a Internet de Todas as Coisas. A IoT consiste em objetos físicos (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 Seção 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,
proporcionarão a informação correta à pessoas ou máquinas conectadas no momento adequado.
Fazendo com que a informação chegue à quem necessita, no momento em que precisa, e que
contenha a informação necessária (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 trilhões de dólares durante os anos de 2013 a 2020. Todo este valor,
refere-se apenas as organizações do setor privado do mundo todo (BRADLEY et al. 2013a).
Como pode ser visto na Figura 2, a IoE inclui três tipos de conexões: machine-tomachine (M2M), person-to-machine (P2M) e person-to-person (P2P). As conexões P2M e P2P
representarão 55% dos 14.4 trilhões de dólares, enquanto as conexões M2M representarão 45%
(BRADLEY et al. 2013a).
Figura 2 - Tipos de conexões da IoE: M2M, P2M e P2P. Fonte: CISCO.
Os 14.4 trilhões de dólares, explica-se por duas razões: a primeira, será resultado da
economia dos custos, já que serão mais produtivos e manusearão melhor a informação. O
segundo, refere-se a geração de novos negócios, como por exemplo: edifícios inteligentes,
medicina conectada, merketing conectado, rede elétrica inteligente, entre outros (BRADLEY et
al. 2013a).
15
Portanto, percebe-se o grande potencial e efeito tanto do âmbito econômico como social,
que poderá ser proporcionado pela Internet de Todas as Coisas ao conectar tudo aquilo que
ainda não está conectado, ou seja, ao conectar pessoas, coisas, dados e processos. Visando
sobretudo benefícios para a humanidade, tornando a vida mais fácil e segura, como também
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 possuírem sensores
embutidos e chips, que permitiriam a comunicação entre esses objetos e com o ambiente, deram
origem a outros termos, tais como: “computação ubíqua” e “computação 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, máquinas e ambiente, resultando na geração 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,
período em que, o número de coisas e objetos conectados à Internet ultrapassou o número de
pessoas no mundo. A pesquisa estima que em 2015 terão 25 bilhões de dispositivos conectados
à Internet. Já para 2020, a estimativa é de 50 bilhões, como pode ser visto na Figura 3 (EVANS,
2011).
Alguns fatores tem contribuído para o surgimento e adoção da Internet das Coisas.
Como por exemplo, nos próximos anos, as atividades de IoT será impulsionado pelo
barateamento de sensores (tags RFID, e MEMS - microelectromechanical systems, tais como:
acelerômetros, giroscópios, sensores de pressão, etc.), protocolo IPv6, computação em nuvem
(armazenamento e análise dos dados; hospedagem e desenvolvimento de aplicações que
manipulam as funcionalidades dos sensores), análise de dados avançadas (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 físicos presentes na terra ainda não
estão conectados. Tendo apenas 10 bilhões de objetos conectados, de um total de 1.5 trilhões
(BRADLEY et al. 2013a).
Sabe-se que tudo que está conectado à Internet deve possuir um endereço IP, portanto,
deve-se ter uma quantidade suficiente de endereços IP para a conexão de todas essas coisas
(pessoas, coisas, dados e processos) à Internet. Como dito anteriormente, a estimativa é que em
2020 haja 50 bilhões de objetos físicos conectados, sendo assim, o número de endereços do
IPv4 não será suficiente, já que fornece apenas 4.294.967.295 ou aproximadamente 4.3 bilhões
de endereços IP (BRADLEY et al. 2013a).
Mas, isto não será um problema, uma vez que, o IPv6 possui um espaço de
endereçamento
de
128
bits,
sendo
possível
obter
340.282.366.920.938.463.463.374.607.431.768.211.456 ou 340.3 undecilhão de endereços IP.
Uma quantidade suficientemente grande para endereçar os estimados 1.5 trilhões de
dispositivos existentes no mundo inteiro, como também conectar pessoas, processos e dados à
Internet (BRADLEY et al. 2013a).
Uma vez que, a Internet das Coisas tenha alcançado o objetivo de formar uma rede de
bilhões de objetos inteligentes interconectados, interagindo e gerando dados. O último objetivo
das aplicações da IoT refere-se à capacidade de comunicação e controle manual de forma
remota a esses objetos, com o intuito de automatizá-los. Onde, baseando-se em configurações
feitas pelo usuário e processamentos baseado em nuvem, façam com que tais objetos realizem
17
ações sem a intervenção humana. Com o propósito de facilitar a vida das pessoas (KARIMI,
2013).
Desta forma, o próximo 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 Seção 2.3 a Web das Coisas será abordada com mais detalhes, apresentando suas
características, as tecnologias que estão sendo utilizadas para tornar objetos inteligentes em
recursos Web, e algumas das aplicações em nuvem já existentes para a WoT.
2.3 Web das Coisas
A medida que tem-se cada vez mais objetos físicos inteligentes conectados à Internet, e
sabendo que tais objetos podem ser controlados remotamente e que estão continuamente
gerando dados. É de suma importância utilizar tecnologias que permitirão desenvolver
aplicações de forma rápida e flexível para acessar estes objetos, como também, armazenar e
gerenciar seus dados (GUINARD et al. 2010).
Para isto, tais tecnologias devem respeitar certos requisitos, devendo ser: leve (objetos
inteligentes são dispositivos com restrição de recursos, como memória, processamento e
energia), fracamente acoplado (falhas em nós da rede não deve impactar no funcionamento
do sistema), escalável (bilhões de objetos se comunicando uns com os outros e enviando
milhões de mensagens por segundo), flexível (suporte para um conjunto de padrões para troca
de dados) e padrão (garantir a alavancagem máxima das ferramentas, serviços e melhores
práticas construídas pela comunidade) (EVRYTHNG, 2012).
Sendo assim, a WoT propõe que protocolos e padrões da Web (HTTP, TCP, IPv6, XML,
JSON, RSS, ATOM, REST, WS-*, URI) sejam utilizados como linguagem comum para a
integração de objetos inteligentes à Web (GUINARD et al. 2010).
Tais protocolos, já em uso, com grande aceitação, e que fazem da Web um sucesso,
podem também ser utilizados para o desenvolvimento de aplicações, a fim de servir como
plataforma para objetos inteligentes e torná-los em recursos Web (EVRYTHNG, 2012).
Os padrões Enterprise Web Services (conhecidos como WS-*, como por exemplo:
UDDI, WSDL, SOAP, etc.), tem por objetivo facilitar o design e implementação de aplicações
distribuídas interoperáveis (EVRYTHNG, 2012).
Tais tecnologias, adicionam uma camada de software nas aplicações, resultando em
maior complexidade. Tornando-se desta forma uma barreira para o ambiente da Internet das
18
Coisas, uma vez que, tais padrões tornam-se “pesados” e complexos, já que trata-se de objetos
simples e com recursos limitados (GUINARD et al. 2010).
Ao invés de usar tecnologias WS-*, estudos envolvendo projetos relacionados à Web
das Coisas, tem explorado a implementação de servidores HTTP em dispositivos embarcados.
Como resultado, obteve-se baixo consumo dos recursos dos dispositivos inteligentes. Este
resultado, foi possível devido a eficiente otimização proporcionadas pelos protocolos HTTP e
TCP, das camadas de aplicação e transporte respectivamente (GUINARD et al. 2010).
Além 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 necessários para tornar possível a integração dos objetos na Web (GUINARD et
al. 2010).
O estilo arquitetural REST possui as seguintes propriedades: permite criar serviços
fracamente acoplados na Web; é implementado com HTTP e URI (identifica recursos na Web),
e pelos tipos de mídia padronizados, tais como: HTML e XML; fornece uma interface uniforme,
através dos métodos HTTP (GET, POST, PUT e DELETE); e permite que clientes selecionem
a melhor opção para interação, sendo geralmente XML e JSON. Na Seção 2.4 a arquitetura
REST será abordada com maior detalhes (FIELDING, 2000).
Tais características faz do REST a opção ideal para a construção de aplicações Web
para objetos inteligentes, permitindo uma perfeita integração dos mesmos à Web, como
também, expor suas características e se comunicar com serviços externos ou centralizados
(GUINARD et al. 2010).
Desta forma, devido à simplicidade, fraco acoplamento e escalabilidade do estilo
arquitetural REST, como também da larga aceitação e disponibilidade de clientes e bibliotecas
HTTP, a arquitetura REST torna-se uma plataforma de integração ubíqua e leve (GUINARD et
al. 2010).
Atualmente, já encontram-se disponíveis 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 fácil integração de objetos físicos à Web, permitindo a
obtenção de uma representação deste objeto na Web, conhecida como Web Object.
Estas plataformas, fornecem uma representação amigável destes objetos, tornando
possível interagir com os mesmos através de navegadores Web, como também, visualizar
através de páginas Web os dados gerados em tempo real pelos mesmos.
19
As plataformas citadas anteriormente, permitem a conexão de diferentes tipos de
dispositivos eletrônicos que tenha suporte TCP/IP, como por exemplo: Arduino, Raspberry Pi,
Sun SPOTs, ARM mbed, entre outros. A interação entre plataforma e objeto, independe da
forma de como objetos físicos estão 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 também podem ser acessadas por linguagens de programação que
possuam bibliotecas HTTP cliente, como: C, Ruby, Java, Python, e outros (GUINARD et al.
2010).
2.4 REST
O termo REST (do inglês, Representational State Transfer) foi definido por Roy
Thomas Fielding em sua tese de doutorado. Roy também contribuiu com a especificação do
protocolo HTTP e com o esquema de nomes global URI, e é um dos fundadores do projeto
Servidor Apache HTTP (TILKOV, 2007).
REST não trata-se de uma arquitetura, e é um estilo híbrido derivado de vários estilos
de arquiteturas baseados na rede (FIELDING, 2000). Desta forma, a utilização de seus
princípios podem ser empregados de forma incorreta no desenvolvimento de sistemas. Um
exemplo disto, seria o caso de aplicações que resultaram em um híbrido de REST com RPC ao
adotarem os princípios REST, o que não é desejável (FRANÇA, 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 princípios REST juntamente com os amplamente aceitos e já em uso protocolos e
padrões da Web, tais como HTTP e URI (FRANÇA, 2011).
REST nos conceitos ROA, consiste em um conjunto de princípios que define como os
padrões da Web, tais como HTTP e URI devem ser utilizados, e como tais princípios, podem
ser aplicados no desenvolvimento de sistemas com uma arquitetura orientada a recursos, ROA.
Sendo assim, aplicações que adotem os princípios REST em seu projeto, estarão beneficiandose da arquitetura Web (protocolos e padrões), e terão como resultado sistemas denominados
RESTful (TILKOV, 2007).
2.4.1 Princípios REST
Os princípios REST apresentados a seguir, baseiam-se nos conceitos especificados pela
Arquitetura Orientada a Recursos (ROA).
20
Identificação única e global para os recursos: um recurso é qualquer componente de
uma aplicação que seja importante o suficiente para ser identificado unicamente. Esta
identificação global na Web é realizada através de URIs (FIELDING, 2000).
A grande vantagem de utilizar URIs na identificação dos componentes da aplicação, é
que estará sendo utilizado um esquema de nomes amplamente aceito na Web, não havendo a
necessidade de apresentar um novo esquema. Para maiores informações sobre URI, consultar a
RFC 3986 (TILKOV, 2007).
Interface uniforme de acesso aos recursos: em REST, a interação e recuperação da
representação de um recurso ocorre através de uma interface uniforme. Na Web, esta interface
uniforme é definida pelos quatro principais métodos do protocolo HTTP (GET, POST, PUT e
DELETE), e baseia-se em URIs, sendo a URI, o alvo da mensagem de requisição (FIELDING,
2000).
Estes quatro métodos, podem estão referir-se ao CRUD (Create, Read, Update, Delete)
da aplicação, onde o GET é utilizado para obtenção da representação de um recurso. PUT para
atualizar um recurso existente. POST utiliza-se para criação de um novo recurso. E por fim, o
DELETE, utilizado para excluir um recurso. Ambos os métodos 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 método PUT seja utilizado para criar o recurso, deve-se fornecer o identificador
do mesmo (maiores informações da especificação destes métodos HTTP podem ser obtidas na
RFC 2616) (GUINARD et al. 2010).
Desta forma, através de uma interface uniforme, ao receber uma requisição HTTP e uma
URI, o servidor sabe o que fazer apenas observando o método da requisição (FRANÇA, 2011).
Endereçabilidade dos recursos: refere-se ao conceito de hipermídia, abordagem
HATEOAS (Hypermedia as Engine Of Application State), onde links são utilizados para a
vinculação de recursos que formam a Web, permitindo que certo recurso aponte para recursos
externos (de diferentes aplicações ou servidores). Isto torna-se possível devido a utilização do
esquema de nomes padrão de uso global URI. Outro aspecto importante, refere-se ao uso de
links, para tornar as aplicações mais dinâmicas, ou seja, o servidor fornece um conjunto de links
ao cliente, permitindo que o mesmo utilize-os para mudança de estado da aplicação (TILKOV,
2007).
Suporte a múltiplas e independentes representações para o recurso: recursos não
estão vinculadas a nenhum tipo particular de representação. Sendo assim, um único recurso
21
pode ser representado por vários formatos, podendo ser: JSON, XML, HTML, CSV, etc., sendo
os dois primeiros os mais populares (GUINARD et al. 2010).
Quando uma requisição HTTP para o servidor é mapeada por múltiplas representações
(definidas através do cabeçalho Accept do HTTP), servidor e cliente negociam, entre os
formatos representativos disponíveis para o recurso, aquele que melhor se adequa às
necessidades do cliente (GUINARD et al. 2010).
Interação sem manutenção de estado: nas aplicações REST o servidor não tem que
manter nenhum tipo de estado das comunicações com os clientes ao qual se comunica
(TILKOV, 2007). Isto significa que, cada requisição HTTP feita por um cliente ao servidor,
deve conter toda a informação necessária para que o mesmo entenda a requisição. Desta forma,
informações sobre determinado recurso deve ser mantida no lado do cliente (FIELDING, 2000).
O maior benefício deste princípio 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 requisições (FIELDING, 2000).
Outro benefício, seria que o cliente não seria afetado em caso de mudanças de servidor
(falhas de hardware), ou seja, requisições consecutivas feitas por um cliente, não tem que
necessariamente serem destinadas ao mesmo servidor (TILKOV, 2007).
2.5 Plataforma Arduino
Arduino é uma plataforma de prototipagem eletrônica open-source, fundada por
Massimo Banzi, David Cuartielles, Tom Igoe, Gianluca Martino, e David Mellis. Flexível e de
fácil utilização, destina-se à artistas, designers, ou a qualquer pessoa interessada na criação de
objetos ou ambientes interativos (BANZI, 2011).
O microcontrolador presente nas diversas placas Arduino (Uno, Mega, Leonardo,
Micro, Mini, Nano, LilyPad, Fio, etc.) são programados utilizando a linguagem de programação
Arduino (baseada em Wiring, um framework de programação open-source para
microcontroladores), juntamente com sua IDE (baseada no Ambiente de Desenvolvimento
Processing) (BANZI, 2011).
Uma vez escrito o código e realizado a transferência do mesmo à placa Arduino através
da IDE. Pode-se conectar sensores de temperatura, umidade, luminosidade, presença,
flexibilidade, gás, entre outros, fazendo com que tais sensores convertam aspectos do mundo
físico em eletricidade. Pode-se também conectar-se à atuadores, como por exemplo, luzes,
motores, autofalantes, displays e etc., estes, obtêm eletricidade da placa e agem sobre o
22
ambiente. Desta forma, sensores e atuadores podem conectar-se à placa Arduino para uma
maior interação com o mundo real (MARGOLIS, 2011).
Há também os shields, que consiste em placas que podem ser facilmente encaixadas
encima das placas Arduino compatíveis, ou até mesmo, encima de outros shields, com o
objetivo de fornecer funcionalidade extra à placa Arduino, como por exemplo: conexão
Ethernet ou Wifi, receptor GPS, reproduzir áudio (MP3, WAV, etc.), display LCD, etc.
(B2CQSHOP, 2011).
23
3 INTEGRANDO FUNCIONALIDADES DO ARDUINO À WEB
Este Capítulo explica como os princípios REST nos conceitos ROA foram empregados
para disponibilizar os recursos do objeto inteligente (lâmpada inteligente construída com
hardware Arduino) na Web. Ademais, será explicado como a aplicação Web para a Web das
Coisas, desenvolvida com framework Rails, utiliza REST para controle, e armazenamento,
gerenciamento e exibição dos dados gerados em tempo real pelo dispositivo inteligente.
Ao final, será apresentado toda a arquitetura de hardware e software necessários para a
construção do objeto inteligente, como também a arquitetura de software utilizada no
desenvolvimento da aplicação Web.
3.1 Aplicando os princípios REST para expor funcionalidades do Arduino na Web
Para que as funcionalidades do dispositivo inteligente pudessem ser expostas, foi
necessário implementar um servidor Web embarcado no mesmo. A fim de poder receber e
enviar requisições HTTP que permitam o acesso às funcionalidades do dispositivo na forma de
recursos REST.
A lâmpada inteligente para ser acessada, precisa primeiramente, ter uma representação
na Web. Isto faz-se através da aplicação Web desenvolvida para a Web das Coisas, onde após
o registro do objeto, este pode receber e enviar requisições HTTP, e assim, ter seus recursos
disponibilizados.
Ter uma representação do objeto físico 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 Seção 2.4, na Web das Coisas essa identificação é feita através de URIs,
estando assim, em conformidade com o princípio REST de identificação única e global para os
recursos.
A URI de cada objeto é gerada automaticamente pela aplicação após o registro do
mesmo. Desta forma, cada URI possui o seguinte formato:
http://{endereço_do_servidor}/{recurso_objeto}/{identificador_do_objeto}
Sendo assim, uma vez que o usuário tenha realizado login, ao acessar um determinado
objeto, uma requisição HTTP é enviada para o servidor, e como resposta, o usuário será
redirecionado para uma outra página Web cujo conteúdo será uma representação deste recurso
(objeto inteligente), como pode ser visto na Figura 4. Enquanto que a requisição HTTP terá o
formato mostrado na Figura 5.
24
Figura 4 - Página Web da representação do objeto físico na Web. Fonte: Compilado pelo autor.
Figura 5 - Requisição HTTP GET para obtenção da representação do objeto. Fonte: Criado pelo autor.
Quando a requisição exibida na Figura 5 chega no servidor, este chamará o controller
objetos e a action show especificada no arquivo de configuração de rotas gerado
automaticamente pelo framework (rota exibida na Figura 6), já que a requisição HTTP possui
a URL do recurso /objetos/1 e o método GET (utilizado para obter o conteúdo de determinado
recurso).
Como pode ser visto na Figura 6, os caminhos da rota são definidos da seguinte forma,
sendo os campos em parênteses opcionais:
HTTP method ':controller(/:action(/:id(.:format)))'
A string segue um padrão, sendo composta por três segmentos particionado por barras
(/) e variáveis para serem postas. Estas variáveis são precedidas por dois pontos (:), sendo estas,
:controller, :action, e :id e :format. A variável :format refere-se ao formato do conteúdo da
resposta, por padrão, no Rails pode ser JSON (formato para aplicações) ou HTML (formato
25
para humanos), aplicando-se neste caso, o principio REST de suporte a múltiplas e
independentes representações para o recurso (GAMBLE et al. 2013).
Figura 6 - Tabela de rotas da aplicação para o recurso objetos. Fonte: Elaborado pelo autor.
De acordo com a tabela de rotas da aplicação, o controller do recurso objetos
(ObjetosController), terá a estrutura e métodos exibido na Figura 7.
Como pode ser observado, os sete métodos presente no controller e referenciados na
tabela de rotas, contém as quatro operações básicas CRUD (criar, ler, atualizar, e deletar). Além
dos quatro métodos básicos citados, possui métodos para listar recursos (index), e mais outros
dois métodos auxiliares que retorna recursos novos (new) e existentes (edit), numa forma
adequada para edição do cliente (RUBY et al. 2012). Estando desta forma, em conformidade
com o princípio REST de interface uniforme de acesso aos recursos, em que utiliza-se os quatro
métodos da requisição HTTP (GET, POST, PUT, DELETE) para interação e recuperação da
representação dos recursos.
Na página Web retornada pelo servidor como representação de determinado recurso
(objeto inteligente), mostrado na Figura 4, o gráfico de temperatura e umidade exibido é
alimentado através do envio de requisições HTTP do Arduino para o servidor da aplicação.
26
Estas requisições são enviadas automaticamente com periodicidade de um minuto entre cada
uma delas. Estas requisições possuem o formato apresentado na Figura 8.
Pode-se observar que no corpo da mensagem desta requisição é enviado uma
representação do recurso dht11 (sensor de temperatura e umidade conectado ao Arduino) no
formato JSON. Neste caso, cliente (placa Arduino) e servidor (aplicação Web) devem estar de
acordo com este formato, o que é aceitável pela aplicação Web, já que a mesma, aceita os
formatos HTML e JSON.
Figura 7 - Classe ObjetosController e métodos especificados no arquivo de configuração de rotas da
aplicação. Fonte: Elaborado pelo autor.
27
Figura 8 - Requisição HTTP POST que envia os dados do sensor dht11 do Arduino. Fonte: Criado
pelo autor.
A página Web da Figura 4, além de permitir que o usuário visualize os dados de
temperatura e umidade gerados em tempo real pelo objeto inteligente, também permite que o
usuário controle/interaja remotamente com o mesmo. Como por exemplo, acender e apagar a
lâmpada. Neste caso, a aplicação Web envia uma requisição HTTP para o objeto inteligente
(Arduino com servidor embarcado), em que o mesmo interpreta esta requisição para que o
Arduino saiba qual recurso (através da URI) e qual operação sobre o recurso (método a ser
chamado para acionar a lâmpada) deve ser realizada. A Figura 9 mostra o formato da requisição
HTTP enviada ao Arduino.
Figura 9 - Requisição HTTP PUT enviada ao Arduino para alterar o estado da lâmpada. Fonte: Criado
pelo autor.
É importante notar que, em todas as requisições mostradas anteriormente, todas elas
possuem toda a informação necessária para que a requisição seja entendida e processada pelo
servidor. Estando desta forma, de acordo com o princípio REST de interação sem manutenção
de estado.
3.2 Arquitetura de software
Esta seção abordará toda a arquitetura de software necessária para tornar possível o
desenvolvimento deste trabalho. Isto inclui, tanto os softwares utilizados no desenvolvimento
28
da aplicação Web, como também, os softwares para implementação do protótipo (lâmpada
inteligente construída com hardware Arduino).
Também será apresentado o diagrama de classes tanto da aplicação Web como do
dispositivo inteligente, a fim de proporcionar um melhor entendimento da estrutura e
relacionamento das classes que compõem os mesmos.
3.2.1 Aplicação Web para a Web das Coisas
A ideia do desenvolvimento da plataforma para a Web das Coisas, é oferecer páginas
Web que permitam que os usuários integrem, gerenciem e criem uma representação na Web do
objeto físico. A fim de, visualizar (por meio de uma interface amigável voltada para o objeto
em questão – lâmpada inteligente) em tempo real através de um gráfico interativo os dados
(temperatura e humidade ambiente) gerados pelo objeto. Como também permitir o controle de
forma remota do mesmo, que neste caso, refere-se ao acendimento e apagar da lâmpada. 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 aplicações Web que utiliza a linguagem de programação Ruby (inventada por
Yukihiro Matsumoto em 1994). É de código aberto, multi-plataforma, com suporte a diversos
sistemas de banco de dados (SQLite, DB2, MySQL, Oracle, Postgres, Firebird, e SQL Server),
não requer editor ou IDE, e é composto por várias bibliotecas e ferramentas que facilitam o
desenvolvimento de aplicações (GAMBLE et al. 2013).
Rails implementa o padrão MVC (Model, View e Controller) através das bibliotecas
Active Record (responsável pela interação e abstração com o banco de dados), Action View
(sistema de templates que gera páginas HTML para o usuário como resultado de uma requisição
à aplicação), e Action Controller (manipula o fluxo da aplicação, e os dados vindos do banco
de dados para serem exibidos na view) (GAMBLE et al. 2013).
Os benefícios da utilização de um padrão como o MVC, é que cada parte que o compõe
é uma entidade separada, permitindo serem testadas de forma isolada. Outro benefício, referese as mudanças numa aplicação MVC, que tendem a ser localizadas e de baixo impacto,
significando que mudanças, por exemplo, na camada model não precisa afetar a camada view
(RUBY et al. 2012).
29
O framework Rails também implementa os princípios 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 aplicação (GAMBLE et al. 2013).
Consequentemente, Rails utiliza URIs para identificação destes recursos, como também
o protocolo HTTP para comunicação cliente-servidor. Cada requisição HTTP deve conter toda
a informação necessária para que o servidor possa compreende-la, já que é através dela que a
aplicação definirá qual controller e action (método do controller) deve ser chamado (de acordo
com o arquivo de configuração de rotas do Rails), observando apenas a URI e o método da
requisição 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,
não há a necessidade de instalação e configuração de um servidor Web para a aplicação. Tratase de um servidor leve, e que pode ser configurado como um servidor HTTPS, servlet com
código Ruby, servidor proxy, entre outros (RUBY et al. 2012).
3.2.1.3 Banco de dados SQLite
SQLite é o banco de dados padrão para desenvolvimento no Rails. Trata-se de um banco
de dados leve, de código aberto, e ideal para dispositivos com pouca memória. SQLite realiza
operações de leitura e escrita diretamente em arquivos no disco, como também mantém em um
único arquivo um banco de dados completo (possuindo várias 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 aplicação Web. A
classe ActionController implementa diversas funções (redirect_to, render, before_filter, entre
outros) que manipulam o fluxo da aplicação e os dados vindos do banco de dados para serem
exibidos na view. A única classe da aplicação que herda de ActionController é a classe
ApplicationController, as demais classes do controller herdam de ApplicationController.
Na classe ApplicationController encontram-se algumas variáveis, cujo conteúdo é
exibido na view, e também o método check_login que retorna uma instância do objeto Usuario,
uma vez que, obtem-se sucesso na validação do login e senha.
A classe SessionsController contém os métodos create e destroy para gerenciar a seção
dos usuários da aplicação. O método create recebe os dados de login e senha fornecidos pelo
usuário, através do formulário da view. Em seguida, passa esses dados para o método
30
validate_login da classe Usuario (model) e dependendo do retorno, o usuário tem acesso ou
não à aplicação.
Nas classes UsuariosController e ObjetosController estão implementados os quatro
métodos básicos CRUD (create {método create}, read {método show}, update {método
update}, e delete {método destroy}), além de mais outros três métodos auxiliares: index
(retorna uma lista de recursos), new (retorna a instância do recurso), e edit (retorna os dados de
um dos recursos). Já a classe Dht11sController, implementa-se apenas os métodos index e
create, já que as demais operações CRUD não aplica-se a este recurso.
Ademais, a classe ObjetosController implementa o método mudarstatusluz, responsável
por enviar uma requisição HTTP PUT para alterar o estado da lâmpada acoplada na placa
Arduino, permitindo assim, que a mesma seja apagada ou acendida remotamente.
Figura 10 - Diagrama de classes do pacote controllers da aplicação Web. Fonte: Elaborado pelo autor.
A Figura 11 apresenta as principais classes do pacote models da aplicação Web. A classe
ActiveRecord implementa diversas funções (create, read, all, where, first, update, delete, save,
entre outros) que são responsáveis pela interação e abstração com o banco de dados. Todas
essas classes herdam de ActiveRecord e são mapeadas como tabelas no banco de dados.
31
Figura 11 - Diagrama de classes do pacote models da aplicação Web. Fonte: Elaborado pelo autor.
Na classe Usuario está implementado o método validate_login, que busca no banco de
dados da aplicação um recurso usuário que possua os dados de login e senha, fornecidos pelo
usuário. Em caso de sucesso, retorna uma instância do recurso encontrado.
A classe Dht11 implementa o método valorMedio que tem a função de buscar os dados
de temperatura e umidade (fornecidos pelo sensor no Arduino) de determinado dia e retornar o
valor médio para este dia. Esta função é utilizada para alimentar o gráfico de temperatura e
umidade dos últimos sete dias, para serem exibidos ao usuário.
3.2.2 Lâmpada inteligente construída com hardware Arduino
Os softwares necessários para a implementação do protótipo foram: IDE Arduino 1.0.5r2 (utilizado para escrita e transferência do código para o microcontrolador Arduino), e
AccessPort137 (utilizado para gravação 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 inglês, Integrated Development Environment) do Arduino foi necessária para
a escrita, edição e transferência do código para a placa Arduino. Também é função da IDE
realizar a conversão do código em instruções (linguagem de máquina) entendíveis 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 debugação da mesma. O AccessPort foi utilizado para envio dos comandos
hexadecimais para configuração do módulo de reconhecimento de voz, como também, para
visualização dos dados retornados pelo módulo.
3.2.2.3 Diagrama de classes
A Figura 12 apresenta as principais classes executadas no Arduino Mega 2560. As
classes EthernetClient e EthernetServer, estão incluídas na biblioteca Ethernet. Esta biblioteca
permite que a placa Arduino conecte-se à Internet através 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, é necessário que o mesmo possua um servidor Web
embarcado. Desta forma, a classe EthernetServer desempenha esta função, onde a placa
Arduino fica em um loop infinito, esperando pela chegada de clientes que enviam requisições
HTTP para acessar as funcionalidades do Arduino.
A classe EthernetClient é responsável pela criação de clientes. Sendo assim, um cliente
(placa Arduino) pode conectar-se à um servidor (aplicação Web desenvolvida neste trabalho).
Portanto, é através dessa classe que o Arduino envia as requisições HTTP, que contém as
informações de temperatura e umidade, para o servidor da aplicação Web para que sejam
armazenados no banco de dados.
A classe Twitter instancia um cliente de EthernetClient para enviar requisições POST
contendo uma mensagem de texto, para o servidor do Twitter. O servidor, ao receber a
requisição exibe a mensagem de texto no Twitter.
33
A classe RestClient é responsável por enviar requisições HTTP para um determinado
servidor. Esta classe possui uma interface uniforme de acesso aos recursos, ou seja, nela estão
implementadas as funções get(), post(), put(), e delete(), referindo-se aos quatro principais
métodos do protocolo HTTP (GET, POST, PUT e DELETE).
As classes virtuabotixRTC e dht11 são responsáveis por acessar e fornecer os dados para
a placa Arduino do módulo RTC (data e hora) e do sensor dht11 (temperatura e umidade),
respectivamente.
3.3 Arquitetura de hardware
Nesta seção serão abordados separadamente e com maior nível de detalhes as partes
mais importantes dos componentes de hardware necessários para a construção do protótipo.
Resumidamente, isto inclui a placa microcontroladora Arduino, sensores, atuadores, cabos e
shields.
3.3.1 O protótipo
O protótipo (Figura 13) consiste em uma lâmpada inteligente, conectada via cabo de
rede Ethernet. Ela é capaz de fornecer temperatura ambiente, data, hora e twittar. Todas suas
funcionalidades podem ser acessadas via página Web, ou seja, através de um computador,
smartphone ou tablet. E algumas delas por comandos de voz.
Os componentes de hardware necessários para a construção do protótipo foram:
microcontrolador Arduino Mega 2560 R3, Ethernet Shield R3 juntamente com um cabo de rede
ethernet categoria 5e para conexão do Arduino à Internet, Sensor Shield versão 4 juntamente
com cabos do tipo macho-fêmea e fêmea-fêmea para conexão de sensores e atuadores, módulo
de reconhecimento de voz V2 versão 2 e microfone para acionamento das funcionalidades do
dispositivo por comandos de voz, módulo conversor USB-TTL para comunicação entre o
computador (USB) e o módulo V2 (TTL), sensor de temperatura e umidade DHT11, módulo
RTC DS1302 para fornecimento de data e hora real, display LED de 7 segmentos e 4 dígitos
para exibição de informações ao usuário, um módulo relé DC/AC 220 volts para acionamento
da lâmpada e 2 baterias sendo uma de 3.3 volts para alimentar módulo RTC e outra de 9 volts
para alimentar o Arduino.
34
Figura 13 - Hardware que compõe o protótipo. 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/saída operando em 5 volts, e 16 pinos analógicos
de entrada. No caso dos pinos digitais, o que definirá se ele será de entrada ou saída, dependerá
do código que foi escrito na IDE através da atualização da função pinMode().
Figura 14 - Pinos digitais e analógicos Arduino Mega 2560 R3 (imagem feita com Fritzing).
35
Destes 54 pinos, alguns possuem funções específicas, como por exemplo: 15 pinos
podem ser usados como saída PWM (pinos 2 a 13 e 44 a 46).
8 pinos são usados para receber (RX) e transmitir (TX) dados seriais TTL, portanto,
a placa Arduino pode enviar e receber dados de um computador ou outros módulos à ele
conectado. Estes pinos realizam comunicação serial por hardware construído no chip, chamado
UART, isto permite que o chip Atmega receba dados seriais enquanto realiza outras tarefas,
desde que haja espaço no buffer serial. Estes pinos são: 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) estão conectados aos correspondentes pinos do chip ATmega16U2 USB-paraTTL Serial e são utilizados pela conexão USB da placa para upload de código escrito na IDE.
Portando recomenda-se que nada esteja conectado nos pinos 0 e 1 no momento de upload do
código (BANZI, 2011).
2 pinos são usados para comunicação TWI através da biblioteca Wire, que simplifica
o uso do bus TWI, são eles: 20 (SDA) e 21 (SCL).
4 pinos são usados para comunicação SPI através da biblioteca SPI, são eles: 50
(MISO), 51 (MOSI), 52 (SCK) e 53 (SS). 6 pinos podem ser configurados para disparar uma
interrupção, são eles: 2 (interrupção 0), 3 (interrupção 1), 18 (interrupção 5), 19 (interrupção
4), 20 (interrupção 3), e 21 (interrupção 2).
Os 16 pinos analógicos de entrada, são utilizados para a leitura de sensores que enviam
sinais contínuos, como por exemplo: sensores de luminosidade e potenciômetros.
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 analógicos de
entenda. E Reset, que quando pressionado reinicia a placa, e o programa armazenado no
microcontrolador é executado novamente do início (SCHMIDT, 2011).
Figura 15 - Conectores de alimentação do Arduino Mega 2560 R3 (imagem feita com Fritzing).
36
O fornecimento de energia pode ser tanto por conexão USB (5volts) como também
por uma fonte externa (adaptador AC-DC ou bateria, 7-12volts), e dar-se respectivamente,
através 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 (conexão
USB ou fonte externa) é selecionada automaticamente, isto significa que, se não houver uma
fonte externa, a alimentação será feita pela conexão USB, uma vez que, seja conectada uma
fonte externa, a placa automaticamente deixará de usar a conexão USB e passará a usar a fonte
externa (BANZI, 2011).
Quanto a memória, o chip ATmega2560 do Arduino Mega 2560 possui 256 KB de
memória flash para armazenamento do código escrito com a IDE. Destes 256 KB, 8 KB é usado
pelo bootloader. O bootloader é um pequeno programa que permite o upload de código sem o
uso de hardware adicional (KRINGEN, 2013). Além 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 transmissão de dados e suporta até quatro conexões de socket simultâneas
(WIZNET, 2014).
O shield Ethernet fornece funcionalidade extra à placa Arduino, permitindo-a conectarse à Internet. Para isso, basta encaixá-lo acima da placa Arduino Mega 2560 em seus respectivos
pinos, conectá-lo à rede através de um cabo RJ45 e escrever o código fazendo uso das
bibliotecas Ethernet e SPI.
A biblioteca Ethernet fornece as classes necessárias que permitirá a conexão da placa
Arduino à Internet, suportando até quatro conexões concorrentes, sendo estas conexões, de
entrada, saída ou ambas (RILEY, 2012).
Já a biblioteca SPI, permite a comunicação da placa Arduino com o shield Ethernet, isto
inclui, o chip W5100 e o slot para cartão micro SD, usando o bus SPI, através do cabeçalho
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), não é usado para seleção 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
serão responsáveis pelo compartilhamento do bus SPI. Mas, caso apenas um dos dois seja
utilizado, àquele que não for usado, deve explicitamente ser desativado, para isso, coloca-se o
pino correspondente como output e high.
Os pinos utilizados na comunicação do Arduino com o chip W5100 e o slot micro SD
do shield Ethernet, são: 50, 51 e 52. Como também 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 não podem ser utilizados como entrada/saída. Para que a comunicação
com o micro SD ocorra, é necessário o uso da biblioteca SD (MARGOLIS, 2011).
Figura 17 - Pinos de comunicação do Arduino Mega 2560 com o chip W5100 e micro SD (imagem
feita com Fritzing).
38
A alimentação do shield Ethernet é proporcionada pela placa Arduino, operando com
uma voltagem de 5 volts e velocidade de conexão de 10/100Mb. No shield encontra-se LEDs
indicadores que fornecem informações sobre alimentação e aspectos relacionados à rede, são
eles: PWR (a placa e o shield estão alimentados), LINK (presença de cabo de rede e pisca
quando ocorre a transmissão ou recebimento de dados), FULLD (conexão de rede full duplex),
100M (presença de conexão 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 colisão na rede)
(WIZNET, 2014).
3.3.4 Sensor shield versão 4
O sensor shield permite a fácil conexão de dispositivos de entrada e saída nas interfaces
I2C ou UART, analógicas e digitais do Arduino, necessitando apenas de cabos dedicados.
Como exemplo destes dispositivos, pode-se citar os sensores (temperatura, luminosidade,
acelerômetro, etc.) e os atuadores (displays, autofalantes, motores, etc.).
Além de facilitar a conexão de sensores e atuadores à placa Arduino, este shield
evita/substitui a utilização de uma placa breadboard/protoboard, para a conexão 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
mudança do circuito (OLSSON, 2012).
Figura 18 - Breadboard (imagem feita com Fritzing).
O sensor shield conecta cada pino (analógico ou digital) do Arduino com conectores do
shield que já estão 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 analógicos, estes também estão conectados a conectores buckled que
também possuem os pinos VCC, GND e signal. Os conectores buckled possuem “travas” que
proporcionam maior segurança no encaixe/conexão, evitando que os cabos conectados aos
39
pinos soltem-se, o que pode ocorrer com os demais conectores que possuem apenas pinos
(SEEED, 2014).
Além disso, o shield possui mais uma porta (conector buckled) para comunicação I2C
ou UART, que podem ser selecionados através de dois jumpers localizados atrás da mesma.
Esta porta de comunicação possui quatro pinos, são eles: VCC, GND, TX/SDA (transmissão)
e RX/SCL (recebimento) (KING, 2014). A Figura 19 mostra todo o esquema descrito
anteriormente.
Figura 19 - Sensor Shield Versão 4, adaptado de (SEEED, 2014).
3.3.5 Módulo de reconhecimento de voz V2
O V2 opera entre 4.5 a 5.5 volts, possui interface digital TTL UART (comunicação
serial) e GPIO (GCH e GCL: para importação dos grupos / O1~O5: para saída do resultado de
comando de voz), interface analógica para conexão de microfone 3.5mm e pinos (GND e VOC)
para microfone. Dois LEDs, um laranja e outro vermelho, são usados como indicadores para os
modos de gravação, espera e reconhecimento, como mostra a Figura 20. Este módulo
dependente de locutor, ou seja, pode não reconhecer a voz de outras pessoas (SHEN, 2014).
O módulo de reconhecimento de voz V2, recebe comandos de configuração e responde
aos comandos de voz através da interface da porta serial. Os comandos enviados não serão
apagados quando não haja alimentação (SHEN, 2014).
40
Figura 20 - Módulo de reconhecimento de voz V2, adaptado de (SHEN, 2014).
No total, é permitido o armazenamento de até 15 comandos de voz. Estes, são divididos
em 3 grupos com 5 comandos de voz cada, podendo cada instrução de voz ter um comprimento
máximo de até 1300ms. A gravação é feita em 1 grupo por vez, para isso é necessário o envio
do comando hexadecimal através da porta serial no formato “Head + Key”, sendo Head 0xaa
e Key uma lista de 47 comandos. Uma vez que, a gravação do grupo termine é necessário sua
importação para que o módulo possa reconhecer os comandos de voz, para isso, envia-se através
da serial o comando correspondente (SHEN, 2014).
A lista dos 47 comandos são utilizados para realização de configurações do módulo,
dentre elas, cita-se algumas: deletar, importar e iniciar gravação de instruções, alterar baud rate
(taxa de dados em bits por segundo para transmissão de dados na serial), eleição de modo
comum ou compacto, etc. Para maiores informações sobre os comandos, consultar manual
Voice Recognition Module V2 disponível no link da referência (SHEN, 2014).
O V2, permite a importação de apenas 1 grupo por vez, ou seja, uma vez gravada as
instruções dos 3 grupos, o módulo só reconhecerá as 5 instruções de 1 grupo apenas. As
instruções dos outros dois grupos não serão reconhecidas, já que, é necessário a importação de
determinado grupo para que o módulo realize o reconhecimento. Quando enviado e reconhecido
o comando de voz pelo módulo, 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 Módulo conversor USB-TTL
O módulo conversor USB-TTL (Figura 21) foi utilizado para comunicação (envio e
recebimento de comandos seriais) entre o computador (USB) e o módulo de reconhecimento
de voz V2 (TTL), uma vez que, este não tem suporte USB.
O módulo USB-TTL contém um chip que converte o hardware da porta serial do chip
do módulo V2 para USB. Desta forma, pode ser feita a conexão com o hardware da porta serial
(MARGOLIS, 2011).
Figura 21 - Módulo conversor USB-TTL. Fonte: Compilado pelo autor.
Sendo assim, talvez, deva estar pensando: “Se o Arduino Mega comunica-se (envia e
recebe dados através do hardware de porta serial) com o computador através de um cabo USB,
como então é possível que ocorra a comunicação?”.
É simples, como mencionado na Seção 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 conversão 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)), não tem suporte USB, havendo desta
forma a necessidade de utilização do módulo 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 através de seu pino signal, a
transmissão do sinal digital por fio pode chegar até 20 metros. Sua alimentação varia entre 3.5
até 5 volts DC (D-ROBOTICS, 2014).
As leituras podem ocorrer no mínimo a cada 2 segundos. Para temperatura, a variação
de leitura é de 0 até 50°C (celsius), com uma precisão de 2°C para mais ou para menos. Já em
relação à umidade, a variação é de 20 a 90% RH (Relative Humidity), com precisão de 5% RH
para mais ou para menos (D-ROBOTICS, 2014).
42
Este sensor possui um componente de resistência de medição de umidade, como
também, um componente NTC (Negative Temperature Coefficient) de medição de temperatura.
Ambos estão conectados à um microcontrolador 8-bit de alta performance. A calibração dos
coeficientes de temperatura e umidade são armazenados como programas em sua memória OTP
(One Time Programmable) do tipo PROM (D-ROBOTICS, 2014).
Figura 22 - Sensor de temperatura e umidade DHT11, adaptado de (D-ROBOTICS, 2014).
Quando à comunicação, as leituras realizadas pelo sensor DHT11 são enviadas pelo
pino de saída digital utilizando apenas um único fio. A comunicação ocorre em três estágios:
requisição, resposta e leitura de dados.
Os dados são 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 número que compõe 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 número que compõe a temperatura (DROBOTICS, 2014).
O 5° e último segmento, refere-se ao check sum, soma dos quatro primeiros segmentos,
utilizado para saber se os dados recebidos estão corretos (D-ROBOTICS, 2014). Para maiores
informações sobre funcionamento do sensor DHT11, consultar manual disponível no link da
referência.
3.3.8 Módulo RTC DS1302
O módulo DS1302 é um relógio/calendário de tempo real que fornece segundos,
minutos, horas, data do mês, mês, dia da semana e ano, incluindo ano bissexto até 2100. Possui
31 bytes de memória RAM estática e comunica-se com o microprocessador por interface serial
(MAXIM, 2014).
43
A comunicação entre o módulo RTC e o Arduino ocorre através dos pinos CE, I/O e
SCLK, conhecido como 3-wire interface, como mostra a Figura 23. Os dados são transferidos
1 byte por vez, ou os 31 bytes de uma vez só, sendo esta última a opção recomendada, já que
evitaria dados erróneos. Os pinos X1 e X2 estão conectados ao cristal de quartzo (MAXIM,
2014).
Figura 23 - Módulo Real-Time Clock DS1302, adaptado de (MAXIM, 2014).
O DS1302 possui duas fontes de alimentação, uma primária e outra secundária, e darse através dos pinos Vcc2 e Vcc1, respectivamente. A primária é fornecida pelo Arduino,
operando em 5 volts, já a secundária por uma bateria de 3.3 volts que pode durar até 10 anos. A
fonte secundária só será utilizada apenas quando não houver fornecimento de energia por parte
do Arduino (MAXIM, 2014). Para maiores informações sobre o módulo RTC DS1302
consultar manual disponível no link da referência.
3.3.9 Display LED de 7 segmentos e 4 dígitos
O display LED possui 4 dígitos com 7 segmentos cada um. Nele encontra-se 12 pinos,
onde cada um deles representam ou um dígito ou um segmento. Os pinos, 12, 9, 8 e 6
representam os dígitos 1, 2, 3 e 4, respectivamente. Já os demais pinos, 11, 7, 4, 2, 1, 10, 5 e 3
representam os oitos segmentos que compõem um dígito, são 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 exibição de informações ao usuário, tais como:
data, hora e temperatura. Para a exibição dos números, é necessário o acendimento de
combinações de segmentos que representem um número (MARGOLIS, 2011).
Figura 24 - Display LED de 7 segmentos e 4 dígitos com seus respectivos pinos. Fonte: Compilado
pelo autor.
3.3.10 Módulo relé DC/AC 220 volts
O módulo relé é utilizado para o acionamento de atuadores que necessitam de grande
quantidade de energia para funcionar. Estes, geralmente são alimentados por baterias ou até
mesmo por energia elétrica, ou seja, voltagens bem maiores que os 5 volts que o Arduino pode
oferecer (MARGOLIS, 2011).
O relé é ativado/desativado através dos 5 volts do Arduino, quando isso ocorre, gera-se
um campo eletromagnético 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
(O´SULLIVAN, 2004).
Mas, para que tudo ocorra de forma segura, sem que esta corrente maior possa danificar
a placa Arduino, é necessário a utilização de componentes que irão isolar e proteger os circuitos.
45
Estes componentes são: transistor, resistor, diodo e fotoacoplador. Todos eles, já estão incluídos
no circuito do módulo relé, como pode ser visto na Figura 25 (O´SULLIVAN; IGOE, 2004).
Figura 25 - Módulo relé isolado 5 volts. Fonte: Compilado pelo autor.
3.3.11 Cabos
Neste projeto foi necessário a utilização de alguns cabos, seja para comunicação entre o
computador e a placa Arduino, conexão do shield Ethernet à rede, como também para a conexão
de sensores e atuadores ao Arduino.
O cabo USB A-B, mostrado na Figura 26, foi utilizado para comunicação entre o
Arduino e o computador, sendo necessário para a transferência do código escrito na IDE para
o chip do microcontrolador. Utilizou-se também um cabo de rede ethernet categoria 5e (Figura
27) para conectar o Arduino à Internet, através do shield Ethernet.
Os cabos utilizados para conexão dos sensores e atuadores ao Arduino, são de dois tipos.
O primeiro (lado esquerdo da Figura 28) possui conectores fêmea em ambos os lados. Já o outro
(lado direito) possui um conector macho e outro fêmea 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 fêmea-fêmea e cabos macho-fêmea. Fonte: Compilado pelo autor.
47
4 AVALIAÇÃO DE DESEMPENHO DAS FUNCIONALIDADES DO ARDUINO EM
TEMPO DE EXECUÇÃO
Este capítulo apresenta os resultados obtidos na avaliação do consumo de memória e
tempo de execução necessários para desempenhar cada funcionalidade em condições normais
de uso. A lâmpada inteligente possui um total de sete tarefas, umas são executadas
automaticamente pelo próprio microcontrolador, outras, solicitadas pelo usuário através de
comandos de voz, ou remotamente com o envio de requisições HTTP por meio da aplicação
Web desenvolvida neste trabalho.
As sete atividades em questão são: exibição da data, hora ou temperatura ambiente no
display LED; postar twitter contendo informações de temperatura, umidade e estado da
lâmpada; acender e apagar lâmpada por comandos de voz, como também, de forma remota; e
por fim, enviar automaticamente dados de temperatura e umidade ambiente para o servidor da
aplicação Web.
As atividades de exibição da data, hora e temperatura ambiente no display LED são
realizadas através de comandos de voz. Enquanto que as atividades de postar twitter e controlar
a lâmpada, que também são acionadas por comandos de voz, enviam requisições HTTP.
A primeira, envia requisições HTTP POST para o Twitter contendo no corpo da
mensagem da requisição informações de temperatura e umidade ambiente, e estado da lâmpada,
obtidos no momento da solicitação da funcionalidade pelo usuário.
A segunda, envia requisições HTTP PUT para o servidor da aplicação Web contendo
no corpo da requisição em formato JSON, o estado da lâmpada, a fim de manter atualizado a
representação Web deste objeto.
A funcionalidade de controlar a lâmpada também pode ser efetuada remotamente,
através do envio de requisições HTTP PUT pelo usuário da aplicação Web. Nesta requisição é
informado o recurso que deseja ser acessado, como também, uma mensagem em formato texto
plano (text/plain) no corpo da mensagem, definindo se a lâmpada deve ser acendida ou apagada.
Por fim, a funcionalidade de envio automático da temperatura e umidade para o servidor
da Aplicação, consiste em enviar requisições HTTP POST contendo no corpo da mensagem da
requisição em formato JSON os dados em questão.
4.1 Consumo de memória
O Arduino Mega 2560 possui três tipos de memória, são elas: flash, SRAM e EEPROM.
A memória flash é onde fica armazenado o código Arduino, sua capacidade total é de 256
KBytes, sendo 8 KByte reservado para o bootloader (necessário para upload de código). A
48
memória EEPROM possui capacidade máxima de 4 KBytes e pode ser utilizada pelo
programador para armazenar informações persistentes. Por fim, a memória SRAM com
capacidade de 8 KBytes, é onde as variáveis são criadas e manipuladas em tempo de execução.
As memórias flash e EEPROM são do tipo não-volátil, significando que, as informações nela
contidas persistirão quando não haja fornecimento de energia, ao contrário da SRAM que é
volátil.
A avaliação do consumo da memória utilizada para desempenhar cada funcionalidade
foi feita na SRAM do Arduino, visto que, esta é a única memória que apresenta variações de
espaçamento em tempo de execução. A Figura 29 apresenta a quantidade de memória
consumida no Arduino, nos diferentes tipos de memória.
Figura 29 - Consumo das diferentes memórias do Arduino Mega 2560. Fonte: Arduino Builder.
Pode-se observar que na memória flash o código do Arduino ocupa cerca de 22 KBytes,
o que representa 8.4% de espaço da memória. Já na memória SRAM, as variáveis do código
Arduino ocupam 1.8 KBytes, ou 22.5% da capacidade total, restando 6.3 KBytes para criação
e manipulação das variáveis em tempo de execução. Por fim, a memória EEPROM que não foi
utilizada para armazenar dados, resultando em 100% de espaço livre.
O consumo de memória envolve todas as variáveis, variáveis de funções e objetos,
necessários para a realização da tarefa. Para realizar esta medição, utilizou-se a biblioteca
MemoryFree, que fornece a função freeMemory(), para verificar em tempo de execução a
quantidade de memória disponível na SRAM do Arduino. Para a obtenção dos valores
referentes a memória consumida, realizou-se o cálculo da diferença entre a quantidade de
memória livre antes do início da realização da tarefa, com a quantidade de memória livre após
a tarefa ser desempenhada por completo. A Figura 30 apresenta os resultados obtidos da
49
avaliação de consumo de memória em bytes para cada uma das sete funcionalidades executadas
pela lâmpada inteligente.
Consumo de memória por tarefa
Tarefa desempenhada
Controlar luz remotamente
108
Enviar temperatura e umidade para servidor
62
Twittar
53
Controlar luz por voz
27
Exibir temperatura
49
Exibir hora
59
Exibir data
60
0
20
40
60
80
100
120
Consumo de memória (bytes)
Figura 30 - Consumo de memória para desempenhar cada funcionalidade da lâmpada inteligente.
Fonte: Compilado pelo autor.
Observa-se que a quantidade de memória consumida para atender a cada uma das
atividades varia entre 27 para 108 bytes apenas. Sabendo que microcontroladores são
dispositivos com restrições de memória, no caso do Arduino que possui 8 KBytes de memória
SRAM, a execução destas atividades não causam grandes impactos no consumo de memória,
visto que, ainda restam 6.3 KBytes. Consequentemente não afetarão no desempenho das
atividades executadas pelo microcontrolador em tempo de execução.
A funcionalidade de controle remoto da lâmpada que consumiu maior quantidade de
memória para ser realizada, 108 bytes, explica-se pelo fato da necessidade de estanciar objetos
EthernetServer e EthernetClient para obtenção do cliente remoto. Também foi necessário
estanciar objetos String para tratar as requisições HTTP enviadas pelo cliente, a fim de obter
método, recurso e corpo da mensagem contidos na requisição HTTP para saber qual recurso e
ação sobre o mesmo deve ser desempenhada para atender de forma correta a solicitação do
cliente.
4.2 Tempo para executar funcionalidade
O tempo para executar determinada funcionalidade consiste na diferença entre o tempo
em que a mesma é finalizada, e o momento em que a tarefa se inicia. Como exemplo, a tarefa
de controle remoto da lâmpada inicia quando o servidor Arduino recebe um cliente externo, e
finaliza quando o recurso (neste caso a lâmpada) é acessado e o Arduino encerra a conexão com
este cliente.
50
Para realização dos cálculos, utilizou-se a função millis(), da biblioteca Time do
Arduino. A função millis() quando invocada retorna o número de milissegundos deste que o
Arduino iniciou sua execução. A Figura 31 apresenta os resultados obtidos da avaliação de
tempo de execução em milissegundos necessários para desempenhar cada uma das sete
funcionalidades.
Tempo para executar tarefa
Tarefa desempenhada
Controlar luz remotamente
328,82
Enviar temperatura e umidade para servidor
1517,55
Twittar
320,45
Controlar luz por voz
1506,45
Exibir temperatura
3987,36
Exibir hora
5300,09
Exibir data
5180,09
0
1000
2000
3000
4000
5000
6000
Tempo de execução (milissegundos)
Figura 31 - Tempo para executar cada funcionalidade da lâmpada inteligente. Fonte: Compilado pelo
autor.
Pode-se observar que, apesar das restrições de processamento comum em
microcontroladores, todas as funcionalidades foram desempenhadas em tempos aceitáveis, não
havendo delays que afetam a experiência do usuário.
As funcionalidades para exibir hora, data e temperatura foram as que necessitaram de
maior tempo para executar, cerca de 5 segundos para as duas primeiras e 4 segundos para a
última. Estes valores já eram esperados, já que tais informações precisam ser exibidas no
display LED por um certo período de tempo, para serem perceptíveis ao usuário.
As quatro primeiras funcionalidades que consistem em controlar a luz remotamente e
por comandos de voz, twittar, e enviar temperatura e umidade para o servidor, que fazem uso
de requisições HTTP sejam elas para envio ou recebimento de informações, foram
desempenhadas em tempos aceitáveis.
51
5 CONCLUSÕES
Este trabalho teve como objetivo desenvolver uma aplicação Web para a Web das
Coisas, como também um objeto inteligente conectado à Internet, para integração do mesmo à
Web, a fim de permitir o acesso de suas funcionalidades como recursos Web.
O alcance destes objetivos contribuem com a ideia da Internet das Coisas que visa
conectar qualquer objeto do dia a dia à Internet, assim como, com o paradigma da Web das
Coisas, sendo este, o próximo passo da IoT. Onde, uma vez conectado objetos à Internet podese agora ter uma representação na Web do mesmo. Com o intuito de acessar seus recursos
através de páginas Web.
Portanto, primeiramente foi desenvolvido um objeto físico, que consiste em uma
lâmpada inteligente construída com hardware Arduino. A lâmpada responde à comandos de
voz, possui sensores e está conectada à Internet.
Em seguida, desenvolveu-se uma aplicação Web para a Web das Coisas. Através desta
aplicação o usuário pode criar uma representação na Web do objeto físico, para que em seguida,
possa controlar e visualizar, gerenciar e armazenar os dados gerados em tempo real pelo objeto
inteligente.
Para o desenvolvimento de ambos, foram aplicados os princípios REST juntamente
como a Arquitetura Orientada a Recursos, em que utiliza-se protocolos e padrões já em uso na
Web, tais como HTTP e URIs, para a integração na Web da lâmpada inteligente. Atendendo
desta forma, ao objetivo da WoT, que consiste em proporcionar a conexão dos diversos objetos
inteligentes do cotidiano à Web, tornando-os parte da mesma.
Sendo assim, a aplicação Web foi desenvolvida com o framework Rails, uma vez que,
implementa os princípios REST nos conceitos da ROA na camada controller. Assim como, a
lâmpada inteligente utiliza HTTP e URI para dispor acesso as suas funcionalidades e também
fornecer os dados gerados pelos sensores.
Devido a simplicidade do REST como também da larga disponibilização de bibliotecas
e clientes HTTP, os resultados obtidos na avaliação de desempenho das funcionalidades em
tempo de execução na plataforma Arduino, demonstraram baixo consumo de memória e tempo
para desempenhar cada tarefa (fatores críticos quando se trata de microcontroladores)
evidenciando assim, os benefícios do uso de REST nos conceitos ROA, em dispositivos
embarcados presentes no ambiente da Web das Coisas.
52
5.1 Trabalhos futuros
A plataforma para a Web das Coisas desenvolvida neste trabalho poderá contribuir com
os demais trabalhos nesta área, permitindo que objetos físicos sejam disponibilizados na Web.
Apesar da aplicação desenvolvida atender aos objetivos esperados, que consistem na criação de
uma representação na Web de objetos físicos, permitindo seu controle, e armazenamento,
gerenciamento e exibição das informações oferecidas pelo mesmo ao usuário. Sugere-se a
implementação de mecanismos de segurança que impeçam que requisições HTTP não
autorizadas sejam processadas tanto pelo Arduino, como pela aplicação Web.
Ainda em relação a aplicação Web, seria interessante a realização de testes de
escalabilidade, a fim de verificar seu desempenho ao integrar diversos objetos inteligentes
enviando requisições HTTP para o servidor da aplicação.
Neste trabalho, realizou-se separadamente uma avaliação de desempenho no que referese à quantidade de memória consumida e o tempo necessário para execução de todas as
atividades implementadas para a lâmpada inteligente. Sendo deixado para trabalhos futuros, a
avaliação do consumo de energia necessária para executar cada uma destas sete funcionalidades
disponíveis. A fim de estimar e otimizar, o tempo de vida útil da bateria.
Também seria interessante o desenvolvimento da funcionalidade que permita que o
Arduino realize automaticamente tarefas agendadas previamente pelo usuário. Como por
exemplo, acender e apagar a lâmpada em dias ou horários específicos determinados pelo
usuário. Sendo o agendamento destas tarefas feita através da aplicação Web e gerenciadas pelo
Arduino através do módulo RTC.
53
REFERÊNCIAS BIBLIOGRÁFICAS
ABOUT SQLite. Disponível em: < http://www.sqlite.org/about.html >. Acesso em: 23 de
Janeiro de 2014.
Arduino, 2005. Disponível em: <http://arduino.cc/>. Acesso em: 06 de Novembro de 2013.
B2CQSHOP. Arduino Mega 2560 Crazy kit Manual. China: 30 de Outubro de 2011.
BANZI, Massimo. Getting Started with Arduino. 2. ed. California: O´Reilly, 2011.
BRADLEY, J. et al. (2013a) Embracing the Internet of Everything To Capture Your Share
of $14.4 Trillion. White Paper. Cisco Systems, San Jose - CA. Disponível em: <
http://www.cisco.com/web/about/ac79/docs/innov/IoE_Economy.pdf >. Acesso em: 20 de
Janeiro de 2014.
BRADLEY, J. et al. (2013b) Internet of Everything (IoE) Value Index. White Paper. Cisco
Systems,
San
Jose
CA.
Disponível
em:
<
http://www.cisco.com/web/about/ac79/docs/innov/IoE-Value_Index_White-Paper.pdf
>.
Acesso em: 23 de Janeiro de 2014.
D-ROBOTICS. DHT11 Humidity & Temperature Sensor, Reino Unido, 30 de Julho de
2010. Disponível em: < http://www.micro4you.com/files/sensor/DHT11.pdf >. Acesso em: 30
de Março de 2014.
EVANS, Dave. The Internet of Things: How the Next Evolution of the Internet Is
Changing Everything. Abril de 2011.
EVRYTHNG. How Web Object Technology Is Putting Every Physical Thing On The Web.
White Paper, 2012.
FIELDING, R. T. (2000) “Architectural Styles and the Design of Network-based Software
Architectures”, Doctoral dissertation, University of California, Irvine.
FRANÇA, Thiago Cruz de. Infraestrutura de Software Baseada na Web das Coisas para
Integração de Redes de Sensores Sem Fio à Web. Universidade Federal do Rio de Janeiro,
2011.
GAMBLE, Adam; JUNIOR, Cloves; BARAZI, Rida. Beginning Rails 4. 3 Third Edition.
United States of America: Apress, 2013.
GONZÁLEZ, Laureano. Nuevas Oportunidades de Negocio en la Internet de las Cosas.
Madrid, 09 de Maio de 2013. Palestra Cisco Connect. Disponível em: <
https://www.youtube.com/watch?v=k30qqIkqiQI >. Acesso em: 05 de Fevereiro de 2014.
GUINARD, Dominique; TRIFA, Vlad; MATTERN, Friedemann; WILDE, Erik. From the
Internet of Things to the Web of Things: Resource Oriented Architecture and Best
Practices. Institute for Pervasive Computing, ETH Zurich. SAP Research, Zurich. School of
Information, UC Berkeley. 2010.
54
KARIMI, Kaivan; ATKINSON, Gary. What the Internet of Things (IoT) Needs to Become
a Reality. Estados Unidos, Junho de 2013.
KING, Terry. Sensor Shield, 07 de Março de 2014. Disponível em: <http://arduinoinfo.wikispaces.com/page/diff/SensorShield/494320008>. Acesso em: 29 de Março de 2014.
KRINGEN, Erik. Embedding an Arduino on Prototyping Board, 6 de jul. 2013. Disponível
em: <http://www.mycontraption.com/embedding-an-arduino-on-prototyping-board/>. Acesso
em: 24 de Março de 2014.
MARGOLIS, Michael. Arduino Cookbook. 2. ed. Califórnia: O’Reilly Media, 2011.
MAXIM. DS1302 Trickle-Charge Timekeeping Chip. Estados Unidos: Califórnia, 2 de dez.
de 2008. Disponível em: < http://datasheets.maximintegrated.com/en/ds/DS1302.pdf >. Acesso
em: 30 de Março de 2014.
MILROY, Andrew. Ubiquitous Connectivity and the Internet of Things. 12 de Novembro
de 2013. Disponível em: < http://www.frost.com/reg/blog-display.do?id=3161648 >. Acesso
em: 19 de Fevereiro de 2014.
MITCHELL, Shane; VILLA, Nicola; STEWART-WEEKS, Martin; LANGE, Anne. The
Internet of Everything for Cities. White Paper. Cisco Systems, San Jose - CA, 2013.
Disponível
em:
<
http://www.cisco.com/web/about/ac79/docs/ps/motm/IoE-SmartCity_PoV.pdf >. Acesso em: 17 de Janeiro de 2014.
Nabaztag, 2009. Disponível em: <http://www.nabaztag.com/brasil/index.html>. Acesso em: 5
de Novembro de 2013.
OLSSON, Tony. Arduino Wearables. 1. ed. New York, Apress, 2012.
O´SULLIVAN, Dan e IGOE, Tom. Physical Computing. Physical Computing: Sensing and
Controlling the Physical World with Computers. 1. ed. Estados Unidos: Thomson, 2004.
Poken, 2010. Disponível em: <http://www.poken.com/>. Acesso em: 5 de Novembro de 2013.
RFC
2616. Hypertext Transfer Protocol - HTTP/1.1. 1999. Disponível em <
http://tools.ietf.org/html/rfc2616 >. Acesso em: Março de 2014.
RICHARDSON, Roberto Jarry. Pesquisa social: métodos e técnicas. et al. São Paulo: Atlas,
1985.
RILEY, Mike. Programming Your Home. United States of America: Pragmatic
Programmers, 2012.
RUBY, Sam; THOMAS, Dave; HANSSON, David. Agile Web Development with Rails.
Fourth Edition. United States of America: Pragmatic Programmers, 2012.
SANDOVAL, J. (2009) “RESTful Java Web Services, Master core REST concepts and
create RESTful web services in Java”, Packt Publishing BIRMINGHAM – MUMBAI,
páginas. 20-81.
55
SCHMIDT, Maik. Arduino: A Quick-Start Guide. United States of America: Pragmatic
Programmers, 2011.
SEEED. Electronic Brick Shield, 1 de Agosto de 2011. Disponível em: <
http://www.seeedstudio.com/wiki/index.php?title=Electronic_Brick_Shield>. Acesso em: 29
de Março de 2014.
SHEN, Wilson. Voice Recognition Module V2, Hong Kong, 4 de Março de 2013. Disponível
em:
<http://www.elechouse.com/elechouse/images/product/Voice%20Recognition
%20Module/Manual.pdf >. Acesso em: 29 de Março de 2014.
Sun SPOT World, Disponível em: <http://www.sunspotworld.com/>. Acesso em: 5 de
Novembro de 2013.
TILKOV, Stefan. A Brief Introduction to REST. InfoQ, 10 de Dezembro de 2007. Disponível
em: < http://www.infoq.com/articles/rest-introduction >. Acesso em: 28 de Janeiro de 2014.
WITCHALLS, Clint. The Internet of Things business index: A quiet revolution gathers
pace. Report. The Economist Intelligence Unit Limited, Junho de 2013. Disponível em: <
http://www.arm.com/files/pdf/eiu_internet_business_index_web.pdf >. Acesso em: 15 de
Fevereiro de 2014.
WIZNET. W5100 Datasheet Version 1.2.4, Coréia, 20 de Setembro de 2011. Disponível em:
< http://www.wiznet.co.kr/UpLoad_Files/ReferenceFiles/W5100_Datasheet_v1.2.4.pdf >.
Acesso em: 25 de Março de 2014.