UNIVERSIDADE FEDERAL DO PARANÁ DEPARTAMENTO DE...
68
UNIVERSIDADE FEDERAL DO PARANÁ DEPARTAMENTO DE ENGENHARIA ELÉTRICA CURSO DE ENGENHARIA ELÉTRICA Maruan de Borba Mendes Thiago Mincoff Marcengo DOMÓTICA VOLTADA PARA PLATAFORMAS MÓVEIS COM SISTEMA OPERACIONAL ANDROID CURITIBA 2011
Transcript of UNIVERSIDADE FEDERAL DO PARANÁ DEPARTAMENTO DE...
UNIVERSIDADE FEDERAL DO PARANÁ DEPARTAMENTO DE ENGENHARIA ELÉTRICA
CURSO DE ENGENHARIA ELÉTRICA
Maruan de Borba Mendes Thiago Mincoff Marcengo
DOMÓTICA VOLTADA PARA PLATAFORMAS MÓVEIS COM SISTEMA OPERACIONAL ANDROID
CURITIBA 2011
Maruan de Borba Mendes Thiago Mincoff Marcengo
DOMÓTICA VOLTADA PARA PLATAFORMAS MÓVEIS COM SISTEMA OPERACIONAL ANDROID
Trabalho de Conclusão de Curso de Engenharia Elétrica, Departamento de Egenharia Elétrica, Setor de Tecnologia, Universidade Federal do Paraná.
Orientadora: Profa. Dra. Giselle Lopes Ferrari Ronque
CURITIBA 2011
Maruan de Borba Mendes Thiago Mincoff Marcengo
DOMÓTICA VOLTADA PARA PLATAFORMAS MÓVEIS COM SISTEMA OPERACIONAL ANDROID
TRABALHO APRESENTADO AO CURSO DE ENGENHARIA ELÉTRICA, DA UNIVERSIDADE FEDERAL DO PARANÁ, COMO REQUISITO À OBTENÇÃO DO TÍTULO DE GRADUAÇÃO.
COMISSÃO EXAMINADORA
___________________________________________________________________ PROFA. DRA. GISELLE LOPES FERRARI RONQUE
___________________________________________________________________ PROF. DR. EDUARDO PARENTE RIBEIRO
___________________________________________________________________ PROF. PH.D. ANDRÉ AUGUSTO MARIANO
CURITIBA, DEZEMBRO DE 2011.
AGRADECIMENTOS
Os nossos agradecimentos vão para todos aqueles que contribuíram para o
sucesso não apenas deste projeto, mas também para aqueles que estiveram ao
nosso lado durante toda a graduação.
Durante esta longa jornada que simbolicamente está representada neste
projeto, alguns professores nos inspiraram e vários amigos nos ajudaram, a família
no entanto, sempre foi a nossa base sólida, em particular duas figuras que possuem
lugares especiais em nossos corações. Pai e mãe, obrigado! Não apenas por
possibilitarem o cumprimento de mais este capítulo de nossas vidas, mas por
estarem sempre ao nosso lado, entregando amor incondicional, conforto e a
segurança necessária, principalmente nos momentos difíceis.
RESUMO
O conceito de possibilitar o usuário a supervisionar e/ou controlar os dispositivos de
sua casa tem um grande potencial de desenvolvimento, uma vez que os sistemas de
automação residencial em nossa sociedade estão presentes, de maneira mais
simples, na forma de centrais de alarme ou controle de ar condicionado. Entretanto
o conceito da domótica vai além e pode ser utilizado para o uso eficaz da energia,
aumentar as facilidades e o conforto para o usuário. O projeto proposto apresenta
um sistema de domótica que permite integrar todos os dispositivos automatizados
em uma residência. Estes podem ser monitorados e controlados, inclusive em
horários agendados, através de um software para o computador e também através
de um aplicativo desenvolvido para plataformas móveis – como celulares ou tablets -
que utilizam sistema operacional Android. Como resultado o usuário passa a ter a
possibilidade de interagir com as mais diversas possibilidades de automação
residencial existentes. O software de gerenciamento foi desenvolvido através da
plataforma de desenvolvimento Borland C++ Builder 6, em seguida para o
desenvolvimento do aplicativo voltado para plataformas móveis que contenham
Android foi utilizado a linguagem Java. Já na parte de hardware, para a automação
dos dispositivos é utilizada a placa de desenvolvimento Land Rover que contém o
microcontrolador LPC1768 da NXP Semicondutores. A comunicação entre os
dispositivos é feita através do protocolo TCP/IP utilizando sockets. O projeto
demonstrou a aplicabilidade deste sistema sem levar em consideração os
parâmetros econômicos dos componentes envolvidos.
Palavras chave: domótica, supervisionar, controlar, Android.
ABSTRACT
The concept of allowing the user to monitor and/or control the devices on your home
has yet a great development potential, once the home automation systems are
present in our society, more simply, in the form of alarm centrals or air conditioning
controllers. However the concept of home automation goes beyond and can be used
for energy efficiency, increase the comfort and amenities for a user. This demotics
project introduces a system that allows the full integration of all automated devices in
a home. These can be monitored and controlled, even at scheduled times, using
software on your computer and also through an application developed for mobile
platforms - such as smartphones or tablets - using the Android platform. As a result,
the user will be able to interact with many different possibilities for existing home
automation. The management software was developed using the Borland C++
Builder 6 environment and the mobile application for mobile devices running Android
platform was developed with the Java programming language using the Android
SDK. Talking about the hardware, for the automation of the devices, it was used
Land Rover development board that contains the LPC1768 microcontroller from NXP
Semiconductors. Communication between devices was done via TCP/IP, over the
sockets library. The project demonstrated, with success, the applicability of this
system without taking account of the economic parameters of the components
involved.
Keywords: domotics, supervise, control, Android.
LISTA DE FIGURAS
FIGURA 1: FATIA DE MERCADO DOS SISTEMAS................................................ 19
FIGURA 2: ESQUEMÁTICO DO PROJETO ............................................................ 21
FIGURA 3: DIAGRAMA DE BLOCOS DE UMA CONEXÃO SOCKET..................... 25
FIGURA 4 - CONFIGURAÇÕES DOS DOIS COMPONENTES............................... 27
FIGURA 5 - CONFIGURAÇÕES E EVENTOS DO COMPONENTE........................ 29
FIGURA 6 - DIAGRAMA OPERACIONAL DO APLICATIVO MÓVEL ...................... 32
FIGURA 7 - EMULADOR DISPONÍVEL NO ANDROID SDK (PLUGIN ADT) .......... 34
FIGURA 8 - FUNCIONAMENTO DA BIBLIOTECA FATFS...................................... 37
FIGURA 9: ROTINA DO SERVIDOR DE GERENCIAMENTO ................................. 40
FIGURA 10: ROTINA DO APLICATIVO MÓVEL...................................................... 42
FIGURA 11 - PAINEL DEMONSTRATIVO............................................................... 43
FIGURA 12 - FLUXOGRAMA DO MICROCONTROLADOR COM OS PERIFÉRICOS
................................................................................................................................. 44
FIGURA 13 - INTERFACE DE ACIONAMENTO ...................................................... 45
FIGURA 14 - FLUXOGRAMA DO FIRMWARE DO MICROCONTROLADOR ......... 47
FIGURA 15: CONTEXTO GERAL DAS TROCAS DE MENSAGENS ENTRE
SERVIDOR DE DOMO............................................................................................. 50
FIGURA 16: CONTEXTO GERAL DAS TROCAS DE MENSAGEM ENTRE ........... 53
FIGURA 17: INTERFACE INICIAL DO SOFTWARE DE GERENCIAMENTO.
SISTEMA DE AUTENTICAÇÃO FONTE: o autor (2011) ......................................... 54
FIGURA 18: INTERFACE DE ATUAÇÃO E VISUALIZAÇÃO DO SISTEMA ........... 55
FIGURA 19: INTERFACE DE ADMINISTRAÇÃO DOS DOMOS. ADIÇÃO,
REMOÇÃO E EDIÇÃO............................................................................................. 56
FIGURA 20: INTERFACE DE ADMINISTRAÇÃO DOS USUÁRIOS. ADIÇÃO,
REMOÇÃO E EDIÇÃO............................................................................................. 57
FIGURA 21: INTERFACE DE ADMINISTRAÇÃO DOS AGENDAMENTOS. ADIÇÃO,
REMOÇÃO E EDIÇÃO............................................................................................. 58
FIGURA 22 - APLICATIVO MÓVEL ......................................................................... 59
FIGURA 23 - APLICATIVO MÓVEL ......................................................................... 60
FIGURA 24 - ARQUIVOS - IMPORTADOS OU EXPORTADOS PELO
PROCESSADOR - DO CARTÃO SD ....................................................................... 61
FIGURA 25 - NOME DO DOMO NA LISTA DE CLIENTES DHCP DO ROTEADOR61
FIGURA 26 - ACIONAMENTO A PARTIR DO SENSOR ......................................... 62
FIGURA 27 - DE COMUNICAÇÃO TCP/IP ATRAVÉS DO PROGRAMA NINJA ..... 63
FIGURA 28 - MONITORAMENTO DA COMUNICAÇÃO TCP/IP ATRAVÉS DO
WIRESHARK............................................................................................................ 63
LISTA DE TABELAS
TABELA 1 – COMPARATIVO ENTRE FATIAS DE MERCADO DAS VERSÕES DO
ANDROID – 2011 ..................................................................................................... 20
TABELA 2 - LETRAS PARA IDENTIFICAÇÃO DO TIPO DE DOMO....................... 48
TABELA 3 - AÇÕES E ESTADOS DISPONÍVEIS PARA CADA TIPO DE DOMO... 49
TABELA 4 - MENSAGES UTILIZADAS NA COMUNICAÇÃO ENTRE SERVIDOR E
DOMO ...................................................................................................................... 49
TABELA 5 - EXEMPLO DE TROCA DE MENSAGES ENTRE SERVIDOR E DOMO
................................................................................................................................. 49
TABELA 6 - MENSAGENS UTILIZADAS NA COMUNICAÇÃO ENTRE SERVIDOR E
MÓVEL ..................................................................................................................... 52
LISTA DE SIGLAS
ADT – Android Development Tools.
API – Application Programming Interface.
C – Linguagem de programação.
C++ – Linguagem de programação orientada a objeto.
DOMO – Termo criado pela equipe que denomina a placa de circuito impresso utilizada para automatizar um elemento da casa, bem como o elemento em si.
FAT – File Allocation System.
FATFS – File Allocation Table File System.
HTML – HyperText Markup Language.
HTTP - Hypertext Transfer Protocol.
IP – Internet Protocol.
LAN – Local Address Network.
LED – Light Emitting Diode.
lwIP - Light-Weight TCP/IP stack.
MAC – Media Access Control.
MISO – Mater In Slave Out.
MOSI – Master Out Slave In.
OSI – Open Systems Interconnection.
PC – Personal Computer.
RAM – Random Access Memory.
RJ45 – Padrão de conector utilizado para cabeamento estruturado.
RS-232 – Padrão para troca serial de dados binários.
RTC – Real Time Clock.
SCK – Serial Clock Signal.
SD – Secure Digital.
SDK – Software Development Kit.
SPI - Serial Peripheral Interface.
TCC – Trabalho de Conclusão de Curso.
TV – Televisão.
TTL – Transistor – Transistor Logic.
TCP – Transmission Control Protocol.
UART - Universal Asynchronous Receiver/Transmitter.
UDP – User Datagram Protocol.
XML – Extensible Markup Language.
X10, KNX e EIB – Padrões de comunicação via rede elétrica.
Wi-Fi – Wireless Fidelity.
SUMÁRIO
1 INTRODUÇÃO............................................................................................... 15
1.1. CONTEXTUALIZAÇÃO DO PROBLEMA ................................................... 16
1.2. MOTIVAÇÃO E JUSTIFICATIVA................................................................ 17
1.3. OBJETIVOS ............................................................................................... 20
1.3.1. Geral ....................................................................................................... 20
1.3.2. Específicos ............................................................................................. 21
1.3.2.1. Software de Gerenciamento ............................................................ 21
1.3.2.2. Aplicativo Móvel............................................................................... 22
1.3.2.3. Hardware ......................................................................................... 23
2 FUNDAMENTAÇÃO TEÓRICA..................................................................... 24
2.1. SOCKETS .................................................................................................. 24
2.2. SOFTWARE DE GERENCIAMENTO......................................................... 26
2.3. APLICATIVO MÓVEL................................................................................. 30
2.3.1. Android e sua SDK ................................................................................. 30
2.3.2. Java e o Eclipse...................................................................................... 33
2.4. HARDWARE .............................................................................................. 35
2.4.1. LPC1768 .................................................................................................... 35
2.4.2. LPCXPRSSO ............................................................................................. 35
2.4.3. COMUNICAÇÃO SPI ................................................................................. 36
2.4.4. BIBLIOTECA LWIP..................................................................................... 36
2.4.5. BIBLIOTECA FATFS .................................................................................. 37
3 MATERIAIS E MÉTODOS............................................................................. 38
3.1. EQUIPAMENTOS NECESSÁRIOS............................................................ 38
3.2. SOFTWARE DE GERENCIAMENTO......................................................... 38
3.3. APLICATIVO MÓVEL................................................................................. 41
3.4. HARDWARE .............................................................................................. 43
3.5. MENSAGENS, CÓDIGOS E NUMERAÇÃO............................................... 48
3.5.1. Comunicação servidor com o DOMO ..................................................... 48
3.5.2. Comunicação servidor com o móvel....................................................... 51
4 ANÁLISE DOS RESULTADOS..................................................................... 54
4.1. SOFTWARE DE GERENCIAMENTO......................................................... 54
4.2. APLICATIVO MÓVEL................................................................................. 58
4.3. HARDWARE .............................................................................................. 60
5 CONCLUSÃO................................................................................................ 64
5.1. TRABALHOS FUTUROS............................................................................ 64
6 REFERÊNCIAS ............................................................................................. 66
15
1 INTRODUÇÃO
Domótica é um conceito que data do início dos anos 80. Este termo foi utilizado pela
primeira vez pelo jornalista Bruno de Latour (1984), referenciando a união da palavra
“Domus”, que significa casa em latim, com “Robótica”, uma indicação de inteligência
aplicada aos elementos de uma casa.
Inicialmente a domótica tinha apenas três pilares de aplicação: iluminação,
segurança e ar condicionado. Na sua criação, entretanto, já possuía um conceito
que perdura até hoje, o foco em proporcionar maior conforto, segurança e
aprimoramento da qualidade de vida daqueles que habitam o ambiente
automatizado.
Hoje em dia, a domótica engloba além dos conceitos iniciais, novas tecnologias
foram desenvolvidas ou aprimoradas depois de sua concepção inicial, tais como a
eficiência energética através de controle de energias alternativas, smart grids,
iluminação natural, controle de áudio e vídeo, a própria robótica e mobilidade
geográfica oriunda da popularização dos aparelhos com internet móvel.
A diferença primordial entre domótica e automação predial reside na diferença
de interação do usuário com o sistema. Na domótica, é essencial que a interface
seja de fácil utilização, intuitiva e universal, a fim de garantir que todos os membros
da residência possam operar de modo simples os elementos automatizados. Este
foco não faz parte da automação predial em si, onde a operação e atuação do
sistema ficam restritas aos técnicos treinados especificamente para gerenciar este
sistema.
O mercado atual apresenta uma variedade de protocolos e arquiteturas de
comunicação, a maioria deles utilizando a rede elétrica como meio de transmissão
entre os elementos da rede. Neste segmento, existem padrões bastante difundidos,
como o X10, KNX e EIB, e já estão presentes em diversos produtos. Entretanto, com
a facilidade obtida através da popularização do padrão Wi-Fi, aliado à vasta gama
de aplicativos portáteis como smartphones, laptops e tablets, e as constantes
reduções nestes produtos. A utilização da rede local de computadores, de
16
preferência sem fio, apresenta redução do custo final do projeto e maior
interoperabilidade entre diferentes produtos. O resultado disto é o aproveitamento de
produtos já presentes no ambiente doméstico, seja para atuação ou gerenciamento
da casa inteligente.
Pensar em automação sem pensar em smartphones, tablets e computadores
pessoais é um contra senso. Estes dispositivos, cada vez mais populares, mostram-
se como uma poderosa ferramenta de pós-processamento dos dados do sistema, e
ainda, por terem interfaces gráficas completas, representa importantes interfaces
visuais para operação da residência. Por estas características, a integração da
automação com estes dispositivos é vital não apenas do aspecto operacional, mas
também para atribuir mobilidade para o usuário final, tornando a presença não mais
necessária em sua casa, deixando-o livre para acompanhar o estado de sua
residência em qualquer lugar do globo.
1.1. CONTEXTUALIZAÇÃO DO PROBLEMA
Existem diversos fatores que ainda restringem a popularização da domótica,
como por exemplo, fatores de cunho financeiro e técnicos. A falta de padronização
de protocolos e arquiteturas também limita a interoperabilidade dos sistemas de
diferentes tipos de fabricantes, deixando o consumidor atrelado a uma fabricante ou
uma empresa.
Levantamentos de custo mostram que atualmente o valor pago por um
sistema simples de automação residencial, com automatização apenas da
iluminação e sem central de controle gira em torno de R$ 2.000, (MARQUES, R.
2011). Quando estendemos a automação para fechaduras biométricas, central de
controle, equipamentos de multimídia, além da própria iluminação, o salto financeiro
chega próximo das dezenas de milhares de reais. Estes valores, sem sombra de
17
dúvidas fogem da realidade população brasileira, taxando o conceito de domótica
frequentemente como supérfluo e/ou de baixa relação custo benefício.
Parte deste alto custo reside em alguns fatores predominantes, como
protocolos e sistemas proprietários, complexidade de implantação - seja na
necessidade de mão-de-obra extremamente especializada ou no alto impacto em
estruturas já prontas - e ainda, a falta de produção nacional de componentes e
equipamentos utilizados na domótica. Este último fator onera em cerca de 60% o
custo final referente à compra de aparelhos e dispositivos para realização da
automação da residencial.
Os modelos vigentes de arquitetura de automação em geral restringem a
operação dos sistemas a controles-remotos, monitores do sistema, atuadores e
sensores específicos para a automação. Esta exclusividade de utilização dos
equipamentos infere a automação o caráter de produto de luxo, algo adicional ao
nosso lar, tornando os benefícios menos visíveis aos olhos do consumidor final.
1.2. MOTIVAÇÃO E JUSTIFICATIVA
Conhecendo alguns dos grandes obstáculos encontrados pela domótica, este
trabalho de conclusão de curso tem o objetivo de propor soluções economicamente
viáveis para os problemas destacados anteriormente. Em tudo que se foi
desenvolvido neste trabalho, sempre existiu um pensamento comum:
desenvolvimento com caráter abrangente tanto nos quesitos de infra-estrutura de
operação (equipamentos de atuação) quanto em equipamentos de monitoramento,
sempre tentando utilizar e aperfeiçoar a estrutura e os recursos já disponíveis em
uma casa de classe média brasileira.
Tratando especificamente do hardware, a característica principal para diminuir
os custos é flexibilidade. Um módulo não deve ser restrito a uma aplicação
específica, nem mesmo a apenas um elemento de mesma aplicação. Expandir a
18
utilização de um módulo de iluminação para até trinta lâmpadas, ou ainda, 20
lâmpadas, cinco portas, duas TVs e três rádios, seria a solução ideal para contornar
o alto custo dos dispositivos de atuação.
A utilização dos equipamentos de interface já disponíveis é o segundo fator
de viabilização econômica deste projeto. Atualmente um computador é um
eletrodoméstico presente em quase todas as residências brasileiras das classes A,
B, C e a nova classe D. Utilizar todo o potencial dos PCs como elemento
centralizador das informações e um dos elementos de atuação no sistema é um
aspecto balizador de um projeto de domótica economicamente viável. Pensando
nestes princípios, o desenvolvimento de um software de gerenciamento e atuação
voltado para PCs é fundamental para caracterização do projeto.
Aproveitar os mais de 230 milhões de celulares no Brasil como potenciais
ferramentas de atuação móvel, é algo imprescindível para um sistema atual de
automação residencial. A mobilidade geográfica vem como elemento diferencial em
relação a muitos outros projetos de domótica, sendo este objetivo atingido através
do desenvolvimento de um aplicativo para celulares e tablets Android,
A escolha da plataforma Google Android se fundamenta em alguns aspectos
operacionais e técnicos. O mais importante deles, é a sua presença massiva em
telefones e tablets de diferentes marcas em diferentes localidades do planeta. A
título de referência, segundo o estudo feito em Agosto deste ano (figura 1) pela
multinacional de estudos estatísticos, Nielsen, o Android representa atualmente 43%
dos sistemas operacionais dos smartphones ativos nos Estados Unidos e 56% dos
novos smartphones adquiridos nos últimos três meses.
19
FIGURA 1: FATIA DE MERCADO DOS SISTEMAS OPERACIONAIS DE SMARTPHONES NOS ESTADOS UNIDOS NO ACUMULADO TRIMESTRAL ATÉ AGOSTO DE 2011. FONTE: modificado pelo autor (2011). Original: Nielsen (2011)
Dentro das plataformas Android disponíveis, a mais popular em março de
2011, época que foi idealizado este TCC, conforme a tabela 1, era o Android 2.2
(codinome Froyo). Com uma fatia de 61,3% dos smartphones rodando o sistema
operacional em questão. Estes dados são fornecidos pelo proprietário do sistema, o
Google. Atualmente o Froyo foi passado pelo seu sucessor direto, o Android 2.3
(codinome Gingerbread), no entanto, isto não representa um problema para o
projeto, visto que o sistema operacional Android apresenta retro-compatibilidade
além do Froyo ainda representar uma fatia significativa do total de aparelhos, 40,7%.
20
TABELA 1 – COMPARATIVO ENTRE FATIAS DE MERCADO DAS VERSÕES DO ANDROID – 2011
Março de 2011 Novembro de 2011
Plataforma Distribuição Plataforma Distribuição
Android 1.5 3,0% Android 1.5 0,9%
Android 1.6 4,8% Android 1.6 1,4%
Android 2.1 29,0% Android 2.1 10,7%
Android 2.2 61,3% Android 2.2 40,7%
Android 2.3 1,7% Android 2.3 44,4%
Android 3.0 0,2% Android 3.0 1,9%
FONTE: modificação feita pelo autor (2011)
1.3. OBJETIVOS
1.3.1. Geral
O objetivo geral deste trabalho de conclusão de curso é o desenvolvimento de
um sistema de domótica, contemplando software e hardware, voltado para
plataformas móveis que operam com sistema operacional Android 2.2 ou superiores.
A figura 2 apresenta um esquemático simplificado que caracteriza o trabalho
em suas três divisões principais: o DOMO – hardware responsável pela atuação no
elemento de iluminação; o servidor – roda o software de gerenciamento que faz a
centralização das informações e também atua no sistema; dispositivo móvel – um
telefone em nosso caso, rodando em Android 2.2 que visualiza e atua no sistema de
forma remota.
21
FIGURA 2: ESQUEMÁTICO DO PROJETO FONTE: o autor (2011)
1.3.2. Específicos
1.3.2.1. Software de Gerenciamento
Desenvolver um aplicativo para PC que rode o sistema operacional Microsoft
Windows XP ou superior. Para isto foram cumpridas as seguintes etapas.
a) Desenvolver um sistema de gerenciamento dos usuários autorizados a utilizar
o sistema de domótica.
b) Desenvolver um sistema de gerenciamento dos DOMOs presentes na
residência automatizada.
c) Desenvolver um sistema de gerenciamento para acionamento automático dos
DOMOs presentes na residência (agendamento).
d) Implementar um sistema de comunicação bi-direcional entre servidor, usuário
e DOMO através da biblioteca sockets.
22
e) Desenvolver um padrão de mensagens necessárias para a troca bi-direcional
entre servidor, usuário e DOMO.
f) Desenvolver uma interface gráfica amigável e intuitiva para atuação e
visualização, sem restrições, das informações e funcionalidades disponíveis
no sistema.
g) Implementar o banco de dados MySQL responsável por armazenar todas as
informações requeridas pelas funcionalidades anteriores.
1.3.2.2. Aplicativo Móvel
Desenvolver um aplicativo para dispositivos móveis utilizando sistema
operacional Google Android 2.2 ou superior. Para isto foram cumpridas as seguintes
etapas.
a) Implementar um sistema de comunicação bi-direcional entre o usuário e o
servidor através da aplicação sockets.
b) Desenvolver um padrão de mensagens necessárias para troca bi-direcional
de mensagens entre o servidor e o usuário, seguindo as mesmas convenções
adotadas no Servidor de Gerenciamento.
c) Desenvolver uma interface gráfica amigável e intuitiva para atuação e
visualização, com restrições, das informações e funcionalidades disponíveis
no sistema.
23
1.3.2.3. Hardware
a) Escolher um kit de desenvolvimento com, no mínimo, comunicação ethernet,
serial, algum tipo de memória não volátil e portas de entrada e de saída
disponíveis.
b) Viabilizar a comunicação Ethernet contando que o micro-controlador não
contém protocolos embarcados.
c) Desenvolver um cliente sockets para comunicação com o servidor.
d) Configurar os sensores.
e) Desenvolver a interface de acionamento não só no firmware como também no
hardware.
f) Implementar o protocolo, a partir dos buffers recebidos na porta ethernet.
g) Inicializar a comunicação serial síncrona para a comunicação com o cartão
SD.
h) Integrar a biblioteca FATFS para acessar os arquivos presentes no cartão SD.
24
2 FUNDAMENTAÇÃO TEÓRICA
2.1. SOCKETS
A implementação da comunicação necessária entre os três elementos da
nossa pequena rede – DOMOs, servidor e dispositivo móvel – foi feita utilizado o
padrão sockets. Os sockets são implementados na camada de aplicação do modelo
OSI, isto quer dizer que as camadas inferiores são invisíveis para quem o utiliza. As
únicas alterações que podemos fazer em relação às camadas inferiores, são a porta
utilizada para a conexão e o tipo de protocolo escolhido para a camada de
transporte.
Sockets trabalham em geral com dois tipos de protocolo de transporte, TCP e
UDP, apesar de suportar outros. De modo bastante simplificado e analisando para a
aplicação em questão, o protocolo TCP garante o reenvio de informações, seja para
corrigir erros ou garantir que todos os pacotes cheguem ao destino. Isto trás a este
protocolo uma característica de cadeia de pacotes, onde todos os pacotes
transmitidos são necessários na recepção, ao custo de alguma redução da taxa de
transmissão quando tornam-se necessárias as retransmissão, ainda que esta função
de controle de banda fique ao encargo dos algoritmos de controle de
congestionamento. Já o protocolo UDP, chamado de datagrama, interpreta cada
pacote independentemente do pacote anterior ou do posterior, ou seja, se houver
um erro que leve o pacote a ser descartado, ou o pacote não chegue ao seu destino,
não existe retransmissão, tornando este protocolo mais recomendado para
aplicações de característica de entrega sobre demanda . A escolha do protocolo
TCP para este projeto reside basicamente na característica de retransmissão. Isto
por que, para esta aplicação é mais relevante que a informação sempre chegue ao
destino, mesmo que necessárias algumas retransmissões, do que ela chegue alguns
milissegundos antes ou alguns milissegundos mais tarde.
25
Falando especificamente dos conceitos requeridos pelo sockets, existem duas
opções de conexão, servidor e cliente. Por ser um projeto de três pontos – DOMOs,
servidor e dispositivo móvel – foi eleito o software que roda no PC como o servidor,
e este seria o responsável pela interligação entre os dois clientes, dentre outras
atribuições. A diferença prática do servidor e cliente é a definição de quem inicia a
conexão e quem fica aguardando a conexão. O servidor, como existe independente
de quantos clientes existam, tem a característica de ficar aguardando a conexão dos
clientes, já o cliente é o elemento ativo, iniciando sempre a conexão com o servidor.
As rotinas de uma conexão socket entre servidor e cliente seguem um padrão
independente da arquitetura do hardware utilizado e da linguagem de programação
escolhida para desenvolver o software. O diagrama de blocos contido na figura 3
demonstra estas rotinas de ambos os lados, já utilizando os elementos e funções
contidos na biblioteca sockets.
FIGURA 3: DIAGRAMA DE BLOCOS DE UMA CONEXÃO SOCKET ENTRE CLIENTE E SERVIDOR. FONTE: autor (2011)
26
As funções utilizadas acima estão descritas na API da biblioteca sockets e
como dito anteriormente, estão disponíveis em diversas linguagens de programação.
Por nosso projeto apresentar três linguagens diferentes – C, C++ e Java – a
descrição será das atribuições de cada etapa e não será mencionado os parâmetros
específicos utilizados em cada plataforma.
a) Socket: cria um socket conforme especificações de protocolos utilizados.
b) Bind: utilizado apenas no lado do servidor, associando ao socket uma porta e
endereço de rede.
c) Listen: utilizado apenas no lado do servidor, ele começa a esperar por uma
conexão do cliente.
d) Connect: utilizado apenas no lado do cliente, atribui ao socket uma porta local
e já inicia a tentativa de conexão com o servidor.
e) Accept: utilizado apenas no lado do servidor, atribui ao socket as informações
da conexão que fora estabelecida.
f) Send e Recv: utilizados para envio e recebimento de informações em ambos
os lados da conexão.
g) CloseSocket: finaliza o socket. O sistema libera os recursos utilizados na
conexão.
2.2. SOFTWARE DE GERENCIAMENTO
Para a concepção do Software de Gerenciamento, foi necessário grande
atenção para a compreensão da plataforma de desenvolvimento Borland C++
Builder 6. Este software possui vasta biblioteca de componentes, desde botões e
caixas de textos, até tabelas, servidores e clientes sockets, e gráficos de grande
variedade. Todos eles são customizáveis em diversos modos, incluindo
customização visual (cores, fontes, fundos e etc..) e de ações para determinados
eventos (onClick, onEdit, onRead, etc..).
27
Apesar de possuir experiência prévia a este projeto na utilização desta
plataforma, duas foram as principais fontes de conhecimento utilizadas para a
elucidação das diversas possibilidades oferecidas pelos componentes. A primeira, o
próprio help do software, onde as informações mais básicas sobre cada componente
são mostradas de maneira simples e mais direta. A segunda é mais rica em
exemplos e explicações foi o site http://www.functionx.com, em especial, a sessão
dedicada ao Builder 6.
O único componente externo ao Builder foi o utilizado para conexão ao banco
de dados MySQL. Este componente se chama ZeosDBO, é gratuito e pode ser
encontrado em http://zeos.firmos.at/. Ele é construído em C++ e possuiu uma grande
biblioteca de classes, métodos e objetos, facilitando em muito o acesso, inserção e
atualização de informações no banco de dados.
FIGURA 4 - CONFIGURAÇÕES DOS DOIS COMPONENTES UTILIZADOS DA BIBIOTECA ZEOSDBO FONTE: o autor (2011)
28
Desta biblioteca, ZeosDBO, utilizou-se dois componentes. O primeiro,
TZConnection, é responsável pela efetiva conexão com o banco de dados (FIGURA
4.a), nele foram configurados os seguintes campos.
a) Hostname: o endereço do servidor MySQL.
b) Name: o nome escolhido para o componente.
c) Password: a senha do servidor MySQL.
d) Port: a porta do servidor MySQL.
e) Protocol: o protocolo referente a versão do servidor MySQL.
f) User: o usuário do servidor MySQL.
O segundo componente utilizado, TZQuery (FIGURA 4.b), é responsável
pelas pesquisas, inserções, atualizações no banco de dados. Ela utiliza o
TZConnection para efetuar a conexão no banco e transmitir as requisições. Neste
componente foram configurados os seguintes campos.
a) Connection: o nome do componente TZConnection utilizado.
b) Name: o nome escolhido para o componente.
Para o estabelecimento das conexões socket foi utilizado duas instâncias,
uma para a conexão com os DOMOs e outra para os usuário, o componente
TServerSocket. Este componente possui além de suas configurações básicas,
importantes eventos. Os eventos tratam situações específicas na rotina do
componente, como por exemplo, o que o TServerSocket deve fazer quando uma
conexão for encerrada.
29
FIGURA 5 - CONFIGURAÇÕES E EVENTOS DO COMPONENTE TSERVERSOCKET FONTE: o autor (2011)
As principais configurações (FIGURA 5.a) e eventos (FIGURA 5.b) utilizadas
no software de gerenciamento serão descritas a seguir.
a) Name: o nome escolhido para o componente.
b) Port: a porta que o servidor escutará.
c) ServerType: o tipo de serviço escolhido para a conexão socket.
d) onClientConnect: evento que trata o primeiro passo da conexão com o
servidos.
e) onClientDisconnect: evento que trata uma desconexão programada – sem
erros.
f) onClientError: evento que trata uma com erros.
g) onClienteRead: evento utilizado para tratar as mensagens recebidas pelo
servidor.
h) onListen: evento acionado quando o servidor é inicializado.
O recurso de agendamento foi implementado em duas etapas. A primeira
consistiu na utilização do componente nativo do Borland, TMonthCalendar. Este
componente permite que o usuário altere o dia, mês e ano em um pequeno
calendário, esta facilidade aliada a algumas listas com informações sobre os
DOMOS, ações disponíveis e repetição do agendamento, estabeleceu uma forma
30
simples de indexar todas as variáveis necessárias para compor o agendamento no
banco de dados.
Do ponto de vista do banco de dados, o agendamento foi feito com a
utilização de duas tabelas. A primeira registra apenas as informações de cada
agendamento, sem repetições. A segunda registra todas as repetições necessárias.
Por exemplo, um agendamento com repetição diária apresentará um registro na
primeira tabela e cento e oitenta registros (limite imposto na programação) na
segunda tabela. Para o controle, cada agendamento apresenta um código único,
desta forma os registros na primeira e segunda tabelas estão referenciados,
possibilitando o gerenciamento simples do banco de dados.
2.3. APLICATIVO MÓVEL
O aplicativo móvel desenvolvido para o sistema operacional Android utiliza
Java como linguagem de programação, seja em sua SDK, quanto para construção
de aplicativos utilizando o kit. Um dos ambientes de programação mais populares
para desenvolvimento Android é o Eclipse (The Open Source Developer Report.
2011). Esta plataforma gratuita é o ambiente mais utilizado para concepção de
aplicativos, seja qual for o sistema operacional, na linguagem Java e por
conseqüência, aplicativos Android.
2.3.1. Android e sua SDK
O Android apresenta em sua arquitetura diversas bibliotecas, aplicações,
funções e etc. Apesar de oferecer complexas ferramentas para criação de
31
aplicativos extremamente completos, para o desenvolvimento inicial do aplicativo
concebido para este projeto, poucas delas serão utilizadas.
A pedra fundamental do aplicativo está na comunicação com o servidor para
obtenção de informações e execução de ações nos DOMOs. Para tal, como foi dito
anteriormente, utilizamos a biblioteca sockets. É necessário, entretanto, mencionar
como foi feita a implementação desta biblioteca, para isto vamos definir alguns
conceitos do sistema operacional Android.
a) Layout XML: XML é uma linguagem de marcação com diversas aplicações,
mas que no Android é aplicado com maior freqüência na construção de
layouts. No arquivo XML especificamos os elementos visuais do aplicativo,
como botões, textos, imagens e etc. Neles podemos especificar o tamanho
dos elementos, seus valores padrão, cores e todas as atribuições visuais.
b) Activity: é a interface de interação com o usuário. Nela carregamos o arquivo
XML que desejamos utilizar. Ela apresenta um ciclo de vida bastante
complexo, com vários eventos. O mais importante deles e que merece
atenção, é o onCreate. Ele abriga todo o código necessário para garantir que
todos os elementos contidos na Activity entrem em operação devidamente
carregados e configurados, para que quando a Activity esteja visível para o
usuário, tudo esteja correto.
c) AsyncTask: é um tipo de thread assíncrona implementada pelo Android. Ela
proporciona que aplicativos rodem códigos em segundo plano sem precisar
manipular o sincronismo da thread com a Activity ativa no momento. No
aplicativo desenvolvido neste projeto, isto foi utilizado para deixar a conexão
socket em segundo plano, recebendo e enviando dados, enquanto que no
primeiro plano o usuário pode visualizar as informações dos DOMOs em
caixas de texto, imagens e etc.
d) Tab: exatamente como a tradução para o português, as abas proporcionam
uma Activity que contenha em seu corpo não apenas um layout XML e sim
vários, sem a necessidade de movimentar diversas activities durante a
execução do aplicativo.
Com estes conceitos introduzidos, podemos esquematizar (FIGURA 6) um
diagrama operacional do aplicativo.
32
FIGURA 6 - DIAGRAMA OPERACIONAL DO APLICATIVO MÓVEL FONTE: o autor (2011)
1) O usuário clica no ícone do aplicativo.
2) O método onCreate carrega o layout e inicia o AsyncTask – este começa a
rodar em segundo plano.
3) A AsyncTask se encarrega da comunicação sockets, desde o
estabelecimento até a interpretação das mensagens, inclusive, efetuando
alterações na Activity.
4) A Activity mostra o layout carregado no onCreate com as alterações
correspondente aos resultados obtidos através da comunicação socket.
5) O usuário que iniciou o ciclo interage com a Activity que está visível na tela do
dispositivo móvel, podendo alterar entre três abas disponíveis.
Todos estes métodos, rotinas, elementos gráficos utilizados no layout e
diversas outras especificações são necessárias para que o usuário tenha uma
interface (Activity com tabs) para leitura das informações, enquanto a conexão com
o servidor é feito em segundo plano (AsyncTask), juntamente com a interpretação
das mensagens.
A comunicação sockets flui por três importantes métodos da AsyncTask,
sendo dois deles oriundos da própria AsyncTask e o terceiro implementado para
simplificar o código.
1) doInBackground: é o início da AsyncTask e como o próprio nome sugere,
engloba o código que deverá ser rodado em segundo plano na aplicação. No
caso deste projeto, contém os passos iniciais da comunicação socket.
2) onProgressUpdate: é neste método onde se dá o tratamento das mensagens
recebidas. Este método funciona similar a uma interrupção nos
33
microcontroladores, sendo executado quando existe alguma alteração no
estado da AsyncTask, no caso, quando é recebido alguma informação do
servidor.
3) SendDataToNetwork: este método concentra as rotinas necessárias para
enviar informações através da conexão estabelecida com o servidor. Não é
nativo do AsyncTask.
2.3.2. Java e o Eclipse
A plataforma Eclipse, atualmente, é a mais utilizada no mundo para
programação orientada a objeto, tanto Java quanto C++ (The Open Source
Developer Report. 2011). Para garantir esta flexibilidade ela dispõe de diversas
versões, cada um com o seu propósito específico. Para o desenvolvimento de
aplicativos Android a versão recomendada é a clássica que apresenta todas as
ferramentas para desenvolvimento Java sem restrições ou otimizações, isto por que,
o real trabalho computacional já foi feito e está disponível na SDK do Android.
A integração da Android SDK com o Eclipse é feito através do plugin ADT,
quê além da utilização propriamente do acervo da SDK, nos dá a possibilidade de
rodar um emulador de Android (FIGURA 7). Neste emulador é possível testar sem
restrições todos os aplicativos que o desenvolvedor quiser, como se estivesse
rodando o aplicativo em um dispositivo real. A grande vantagem disto, é a
possibilidade de se desenvolver um aplicativo sem a necessidade de possuir um
aparelho rodando Android, o que em grande parte das vezes, é um grande alívio
financeiro.
34
FIGURA 7 - EMULADOR DISPONÍVEL NO ANDROID SDK (PLUGIN ADT) FONTE: o autor (2011)
A utilização da linguagem Java foi o maior desafio em termos de software
deste projeto. Nenhum dos integrantes da dupla possuía experiência com a
linguagem, apenas com C++. O estudo desta nova linguagem se deu conforme a
necessidade foi aparecendo, sempre com o auxílio do site http://stackoverflow.com/
e da própria API desta linguagem.
O Site Stackoverflow é colaborativo e funciona com perguntas e respostas, e
não se restringe a Java ou Android, mas engloba todas as linguagens de
programação. A missão do site, traduzindo para o português diz o seguinte: “Livre
para fazer perguntas, livre para responder perguntas, livre para ler, livre para
referenciar, construído em puro HTML”, e de fato cumpre bem seu discurso. Nele
pudemos fazer e ler perguntas sobre códigos específicos de Java, sobre lógica
computacional utilizando Java, informações bastante valiosas para o contexto geral
do aplicativo.
35
A API do Java propriamente dita nos foi muito útil para as sintaxes,
parâmetros, utilização em geral dos métodos, classes e objetos disponíveis nas
bibliotecas para esta linguagem.
2.4. HARDWARE
2.4.1. LPC1768
O LPC1768 é um processador da linha ARM Cortex-M3 da NXP
semicondutores e utiliza a arquitetura Harvard, que contempla dois barramentos
sendo um para as instruções e outro para transferências de dados. Além disso
possui um terceiro barramento específico para os periféricos. Entre os periféricos do
micro-controlador LPC1768 cita-se como os principais utilizados ou que podem ser
integrados ao projeto: 512 KB de memória flash, 64KB de memória RAM, Ethernet
MAC, 4 UARTs, interface SPI, modos ultra econômicos de energia, RTC alimentado
por um bateria externa de 3,3V e 70 portas de entrada/saída de uso geral.
2.4.2. LPCXPRSSO
A plataforma de desenvolvimento utilizada foi a LPCXpresso. Esta é baseada
na plataforma Eclipse e contém bibliotecas específicas para os micro-controladores
da NXP semicondutores, que auxiliam bastante no desenvolvimento do projeto.
36
2.4.3. COMUNICAÇÃO SPI
O protocolo SPI utiliza, basicamente 3 pinos para realizar a comunicação
entre dois pontos, sendo um mestre e outro escravo. São eles:
a) Serial Clock Signal: gerado sempre pelo mestre e recebido pelo escravo. Sua
função é sincronizar a transferência de dados através da interface SPI
durante a comunicação.
b) Mater In Slave Out: Porta de sinal unidirecional do escravo para o master. Se
o dispositivo for escolhido como mestre a porta passa a ser de entrada. Caso
contrário a porta passa a ser de saída.
c) Master Out Slave In: Opera de maneira contrária ao MISO.
Para montar uma rede de comunicação SPI que contenha apenas um mestre
e diversos escravos, é necessário que cada escravo tenha um pino de slave select.
Desta forma, o mestre controla individualmente todos os pinos de seleção e somente
ativa o slave select com o qual deseja se comunicar.
2.4.4. BIBLIOTECA LWIP
LWIP é uma biblioteca com o básico para o funcionamento do protocolo
TCP/IP, desenvolvida especialmente para micro-controladores com baixa
capacidade de processamento e memória limitada.
37
2.4.5. BIBLIOTECA FATFS
A biblioteca FATFS é um módulo de sistema de arquivos FAT - que promove
o gerenciamento e organização do acesso em cartões SD, discos rígidos entre
outras mídias – desenvolvida para sistemas embarcados. A FATFS, como mostrada
na figura 8, é independente da arquitetura de hardware e faz a interface entre a
camada de baixo nível – que envolve, no caso do cartão SD, a inicialização das
portas e da comunicação SPI – e a camada de aplicação com funções muito
conhecidas para gerenciamento de arquivos como f_open, f_write, entre outras.
FIGURA 8 - FUNCIONAMENTO DA BIBLIOTECA FATFS FONTE: o autor (2011)
38
3 MATERIAIS E MÉTODOS
3.1. EQUIPAMENTOS NECESSÁRIOS
Para a implementação conceitual do projeto foram necessários alguns
equipamentos e materiais. A rede local de computadores foi composta por um
Linksys WRT54G utilizando suas capacidades de roteador para encaminhamento de
pacotes para a internet quando o dispositivo móvel estava fora da rede local, switch
ethernet para a conexão cabeada 100BASE-TX com o DOMO e bridge Wi-Fi para a
ligação com o dispositivo móvel quando este se encontrava na rede local. O
dispositivo móvel é um Motorola Milestone 2 rodando Android 2.2, codinome Froyo.
Já o computador que roda o software de gerenciamento também foi conectado sem
fio ao WRT54G, o modelo era um Acer Aspire 5740G rodando sistema operacional
Microsoft Windows 7.
3.2. SOFTWARE DE GERENCIAMENTO
O funcionamento do software de gerenciamento é bastante simples. Gira em
torno da interação de conexões sockets entre servidor e DOMO, entre servidor e
móvel e ainda, conexões com o banco de dados para gerenciamento e
armazenamento de dados dos DOMOs e usuários.
A figura 9 estabelece uma sequência lógica de funcionamento do software de
gerenciamento.
1) Usuário inicia o programa.
39
2) Rotina Inicial Banco de Dados: é feita a conexão com o banco de dados e
já inicia o carregamento de todas as informações pertinentes ao
funcionamento do programa, tais como, usuários e DOMOs registrados,
agendamentos realizados e o último estado de cada DOMO.
3) Rotina Inicial Servidor Sockets: é feita a configuração dos servidores
sockets para a conexão com os DOMOs e os usuários. Cada um roda em
uma porta específica e trata independentemente as conexões. Nesta
altura o servidor ainda não está online.
4) Servidor Sockets “Listening”: ambos os servidores sockets são colocados
em modo Listening, ou seja, aceitando conexões.
5) Conexão: esta rotina é igual para conexão com DOMOs ou usuários, no
entanto, são tratadas separadamente. Ela consiste em estabelecer a
conexão, autenticar, efetuar as trocas de mensagens, proceder com
visualizações e atuações conforme demanda e realizar a desconexão.
6) Rotina de Encerramento: quando o programa é fechado, todos os dados
atuais são salvos, evitando qualquer perda.
7) Fim. O programa é fechado.
40
FIGURA 9: ROTINA DO SERVIDOR DE GERENCIAMENTO FONTE: o autor (2011)
41
3.3. APLICATIVO MÓVEL
A rotina do aplicativo móvel difere em muito da rotina do software de
gerenciamento. O Android com o Java introduz alguns conceitos diferentes do que
temos em C/C++, sendo que a maior diferença, não reside na natureza da
linguagem de programação utilizada no aplicativo móvel, e sim nas limitações de
hardware e memória do mesmo.
Para tornar o aplicativo enxuto, por acreditar que os planos de dados hoje já
estão em preços acessíveis (quanto não em LAN), apenas salvamos os dados do
usuário, senha e host do servidor no aplicativo móvel, outras informações
necessárias são enviadas pelo servidor ao móvel quando é iniciada uma conexão e
na demanda requerida conforme a utilização é feita.
A figura 10 estabelece uma sequência lógica de funcionamento do aplicativo
móvel.
1) Usuário inicia o programa.
2) onCreate: são carregados os layouts utilizados, atribui ações aos
elementos do layout e dá início a AsyncTask.
3) AsyncTask – Início: é feita a criação e configuração do sockets deixando a
conexão com o servidor para ser realizada conforme o usuário queira.
Esta etapa não impede do próximo passo seja iniciado.
4) Inicia a Activity Principal: são mostrados na tela do usuário os layouts e
em especial, os campos de Usuário, Senha e Host, para que o usuário
realize a conexão.
5) AsyncTask – Conexão: com os dados da Activity Principal, é realizada a
conexão com o servidor e toda sua rotina de autenticação, informações
iniciais e ações sobre a demanda do usuário.
6) Rotina de Encerramento: é salvo apenas o Usuário, Senha e Host da
última conexão bem sucedida.
7) Fim.
42
FIGURA 10: ROTINA DO APLICATIVO MÓVEL FONTE: o autor (2011)
43
3.4. HARDWARE
Para a demonstração da funcionalidade do projeto foi construído um painel
que contém, na parte da frente, um kit de desenvolvimento com o papel de tornar os
equipamentos inteligentes e uma lâmpada que representa o dispositivo a ser
automatizado. O painel conta ainda, na parte traseira, com um circuito de
acionamento para a lâmpada. A figura 11 ilustra o painel demonstrativo.
FIGURA 11 - PAINEL DEMONSTRATIVO FONTE: o autor (2011)
44
O kit de desenvolvimento utilizado para a automação dos DOMOS, foi o Land
Rover que tem como base o micro-controlador LPC1768 da NXP semicondutores. A
placa conta, dentre as principais funcionalidades utilizadas no projeto, com interface
serial RS-232, interface de rede Ethernet 10/100M, interface para cartão SD e quatro
botões, sendo dois de uso geral, um para entrar em modo de programação e outro
para reset. O módulo de desenvolvimento pode ser alimentado por uma fonte
externa de 5 volts ou pela porta USB.
A figura 12 demonstra a solução utilizada no projeto considerando o micro-
controlador, os periféricos contidos na placa de desenvolvimento, a interface de
acionamento e uma lâmpada.
FIGURA 12 - FLUXOGRAMA DO MICROCONTROLADOR COM OS PERIFÉRICOS FONTE: o autor (2011)
45
Para a comunicação serial assíncrona, a placa contempla um conversor
TTL/RS-232 (MAX3232) que transforma o nível TTL (3,3V) proveniente do micro-
controlador para os níveis de tensão do protocolo RS232.
Já para a interface de rede Ethernet, o kit utiliza o transceptor DP83848 que,
considerando o modelo OSI, atua na camada física e adapta os sinais elétricos e a
pinagem do RJ45 à pinagem do micro-controlador. O DP83848 conta ainda com
controle de LEDs que indicam a velocidade e o estado da conexão.
A figura 13 ilustra o circuito de acionamento utilizado no projeto, que faz a
interface entre o sinal de 3,3 volts que sai do LPC e a alimentação da lâmpada em
corrente alternada proveniente da rede de energia elétrica.
FIGURA 13 - INTERFACE DE ACIONAMENTO FONTE: o autor (2011)
O programa gravado no micro-controlador como demonstrado na figura 14,
primeiramente realiza a inicialização de variáveis e das configurações, em seguida
entra em um laço infinito onde é feito o tratamento da comunicação TCP/IP,
tratamento do protocolo e a checagem dos sensores.
1) Rotinas de inicialização: Após realizar as configurações da da porta serial,
dos pinos onde estão localizados os sensores como entrada e inicialização no
46
relógio de tempo real, o programa busca as configurações de comunicação e
o nome do equipamento dentro de arquivos presentes no cartão SD. Caso
estes arquivos não existam, o programa carrega as configurações padrão e
cria os mesmos.
2) Tratamento da comunicação: Cria um cliente sockets caso ainda não tenha
sido criado, e, se não conseguir, tenta conectar novamente até o momento
em que consiga se conectar com o servidor.
3) Tratamento do protocolo: O DOMO envia para o servidor pedidos de conexão,
informações de mudança de estado e confirmações de que está conectado.
O DOMO recebe do servidor pedidos de mudança de estado, mudança de
hora e verificação de conectividade.
4) Checagem dos sensores: Caso algum sensor seja ativado, o DOMO atua e
informa o servidor.
47
FIGURA 14 - FLUXOGRAMA DO FIRMWARE DO MICROCONTROLADOR FONTE: o autor (2011)
48
3.5. MENSAGENS, CÓDIGOS E NUMERAÇÃO
O software que roda no PC foi escolhido como servidor do sistema, e ele é o
centralizador de todas as informações e mediador da comunicação entre aplicativo
móvel e DOMOs.Para compreender esta comunicação primeiro é preciso apresentar
as mensagens, códigos e números utilizados e seus significados no processo de
estabelecimento de conexão e troca de informações entre os elementos. Para isto
cada lado da comunicação será tratado separadamente.
3.5.1. Comunicação servidor com o DOMO
A comunicação entre servidor e DOMO apresenta mensagens de tamanho
padronizado. O cabeçalho é composto por dois caracteres seguido pela identificação
única do DOMO e uma ação a ser realizada ou estado a ser informado. Antes de
exemplificar uma mensagem, tabelas 2, 3 e 4 apresentam a codificação utilizada
para compor a mensagens.
TABELA 2 - LETRAS PARA IDENTIFICAÇÃO DO TIPO DE DOMO
Letra Descrição
l Iluminação ("l" de lâmpada)
a Acessos ("a" de acessos)
s Segurança ("s" de segurança)
m Áudio e Vídeo ("m" de mídias)
FONTE: o autor (2011)
49
TABELA 3 - AÇÕES E ESTADOS DISPONÍVEIS PARA CADA TIPO DE DOMO
Código Descrição DOMO
0001 Ligado
0002 Desligado "l" e "m"
0003 Aberto
0004 Fechado "a"
0005 Ativado
0006 Desativado "s"
FONTE: o autor (2011)
TABELA 4 - MENSAGES UTILIZADAS NA COMUNICAÇÃO ENTRE SERVIDOR E DOMO
Texto Descrição Sentido
Oi_dYYYY DOMO requer conexão DOMO->SRV
iO_dYYYY Servidor recebe o DOMO (oi ao contrário) SRV->DOMO
KA_dYYYY Mensagem de manutenção de conexão SRV<->DOMO
RQ_dYYYY Servidor requer o estado do DOMO SRV->DOMO
ST_dYYYY_BBBB DOMO informa o seu estado atual DOMO->SRV
EX_dYYYY_BBBB Servidor requer mudança de estado do DOMO SRV->DOMO
ER_dYYYY_BBBB Erro: o DOMO não conseguir executar a ação DOMO->SRV
DI_hora_data Informa o DOMO da data e hora local SRV->DOMO
OK_dYYYY Confirmação de recebimento SRV->DOMO
BY_dYYYY DOMO irá se desconectar DOMO->SRV
FONTE: o autor (2011)
Com todas as mensagens e códigos citados, a tabela 5 exemplifica uma troca
de mensagens entre servidor e DOMO.
TABELA 5 - EXEMPLO DE TROCA DE MENSAGES ENTRE SERVIDOR E DOMO Origem Mensagem Descrição
Servidor RQ_l0090 Servidor requer do DOMO de l0090 o seu estado atual.
DOMO ST_l0090_0002 O DOMO l0090 informa que está desligado.
Servidor OK_l0090 Servidor confirma.
Servidor EX_a0002_0003 Servidor informa que o DOMO a0002 deve executar a ação
0003
DOMO ST_a0002_0003 O DOMO a0002 informa que mudou seu estado para 0003
Servidor OK_l0090 Servidor confirma.
FONTE: o autor (2011)
50
As figuras 15.a e 15.b demonstram agora o contexto geral das rotinas de
autenticação, troca de informações e atuação entre o servidor e o DOMO.
FIGURA 15: CONTEXTO GERAL DAS TROCAS DE MENSAGENS ENTRE SERVIDOR DE DOMO FONTE: o autor (2011)
51
A figura 15.a demonstra todas as rotinas obrigatórias durante a conexão do
DOMO com o servidor. Com exceção da parte marcada com “Primeira Conexão” que
é um método automático de informar ao DOMO a sua identificação única e ocorre
apenas a primeira vez que ele conecta-se ao servidor, todos as outras rotinas
ocorrem toda vez em que o DOMO se conecta. O usuário só poderá efetuar atuação
sobre o DOMO uma vez que estas rotinas estiverem terminadas.
As rotinas da figura 15.b são aquelas que o usuário pode executar, seja
operando remotamente via aplicativo móvel ou software de gerenciamento, ou ainda
pelo próprio botão físico do DOMO. Existem também as mensagens de manutenção
da conexão que evitam que o link entre o servidor e DOMO caia por falta de
comunicação entre eles.
As mensagens de conexão ociosa além de evitar que a conexão caia por falta
de utilização ainda permitem que o servidor reconheça quando o DOMO parou de se
comunicar e feche a conexão com ele. A cada 15 segundos é enviado para todos os
DOMOs uma mensagem de keep alive, em português, mantém viva. Se o servidor
não receber duas respostas consecutivas do DOMO ele fecha a conexão e emite
uma mensagem de erro no software de gerenciamento.
3.5.2. Comunicação servidor com o móvel
Diferente da comunicação entre servidor e DOMO, a comunicação entre
servidor e móvel não tem tamanho fixo, apenas o seu cabeçalho é fixo. Isto por que
é preciso informar ao móvel diversas informações do DOMO, como o nome, a
localização e etc. Estes textos têm tamanho variável o que acarreta em mensagens
de tamanho variável.
As composições das mensagens, no que diz respeito aos parâmetros dos
DOMOs, identificação, estado atual ou ação a ser executada, seguem os padrões
informadas nas tabelas disponíveis no item 3.5.1. A tabela 6 apresenta as
52
mensagens utilizadas na comunicação entre servidor e móvel, bem como um
exemplo de troca de mensagens e as rotinas utilizadas nesta ponta da comunicação.
TABELA 6 - MENSAGENS UTILIZADAS NA COMUNICAÇÃO ENTRE SERVIDOR E MÓVEL
Texto Descrição Sentido
HELO_user_ Móvel requer conexão Móvel->Servidor
OPA!_ Servidor recebe o móvel Servidor->Móvel
USPS_user_senha_ Autenticação do usuário Móvel->Servidor
KEAL_user_ Mensagem de manutenção de conexão Móvel<-
>Servidor
EXEC_user_DOMO_acao
_
Móvel pede para o DOMO que execute uma ação Móvel->Servidor
RQST_user_DOMO_ Móvel requer o estado atual do DOMO Móvel->Servidor
STAL_user_ Móvel requer o estado atual de todos os DOMOs Móvel->Servidor
STAT_DOMO_estado Servidor informa o móvel do estado do DOMO. Servidor->Móvel
DMNM_user_ Confirmação de recebimento Móvel->Servidor
DCON_DOMO Servidor informa o móvel da conexão de um DOMO. Servidor->Móvel
DDES_DOMO Servidor informa o móvel da desconexão de um
DOMO
Servidor->Móvel
OK_ Servidor confirma. Servidor->Móvel
BYEE_user_ Móvel irá se desconectar Móvel->Servidor
As figuras 16.a e 16.b demonstram agora o contexto geral das rotinas de
autenticação, troca de informações e atuação entre o servidor e o móvel.
53
FIGURA 16: CONTEXTO GERAL DAS TROCAS DE MENSAGEM ENTRE SERVIDOR E MÓVEL. FONTE: o autor (2011)
54
4 ANÁLISE DOS RESULTADOS
4.1. SOFTWARE DE GERENCIAMENTO
Os resultados do software de gerenciamento foram satisfatórios. O programa
operou sem falha durante mais de 48 horas seguidas. Durante a bateria de testes foi
utilizado um software feito especialmente para este teste, que consistiu em alternar
conexões e desconexões de DOMOs e usuários, tanto programadas quanto aquelas
repentinas para simular erros. Foi feito também troca de todas as mensagens
suportadas, cobrindo uma grande quantidade de situações corriqueiras que o
usuário, DOMO e servidor enfrentariam.
FIGURA 17: INTERFACE INICIAL DO SOFTWARE DE GERENCIAMENTO. SISTEMA DE AUTENTICAÇÃO FONTE: o autor (2011)
55
A figura 17 é a tela inicial do software de gerenciamento. Ela é utilizada para
autenticação dos usuários. Desta forma foi estendido controle sobre quem acessa o
sistema. O método é bastante simples e é composto por um usuário e uma senha.
FIGURA 18: INTERFACE DE ATUAÇÃO E VISUALIZAÇÃO DO SISTEMA FONTE: o autor (2011)
A figura 18 exibe a janela Home do software de gerenciamento. Nela é feita a
visualização geral do sistema tanto para usuários como DOMOS, bem como a
atuação sobre os DOMOs conectados.
a) Atuação: é feito de maneira simples, apenas clicando com o botão direito
sobre o DOMO que deseja controlar. Cada tipo de DOMO apresenta menu
customizado.
b) Todos os DOMOs: exibe todos os domos cadastrados no sistema, bem como
seu último estado registrado. O botão atualizar pede o estado atual de todos
os DOMOs conectados.
c) DOMOs online: exibe todos os domos online e disponíveis para automação.
d) Usuários online: exibe todos os usuários conectados ao sistema.
e) Logs de comunicação: exibe todas as trocas de mensagem entre DOMOs,
usuários e servidor.
a)
c) DOMOs
b) Todos
os DOMOs
d)
Usuários
e) Logs de
comunicaçã
56
FIGURA 19: INTERFACE DE ADMINISTRAÇÃO DOS DOMOS. ADIÇÃO, REMOÇÃO E EDIÇÃO FONTE: o autor (2011)
A figura 19 exibe a janela Domos do software de gerenciamento. Nela é feita
a administração dos DOMOs registrados no sistema.
a) Listagem dos DOMOs: exibe todos os domos registrados no banco de dados
do sistema. Além da visualização é possível remover DOMOs, sincronização
forçada com o banco de dados, bem como carregar um DOMO para edição,
através de um duplo clique.
b) Adição: adiciona um novo DOMO ao sistema.
c) Edição: edita as informações de um DOMO previamente cadastrado.
a) Listagem dos DOMOs
b) Adição
c) Edição
57
FIGURA 20: INTERFACE DE ADMINISTRAÇÃO DOS USUÁRIOS. ADIÇÃO, REMOÇÃO E EDIÇÃO FONTE: o autor (2011)
A figura 20 exibe a janela Usuários do software de gerenciamento. Ela difere
da janela Domos apenas no conteúdo acessado. As rotinas, botões, informações e
etc, são todas muito similares. Nela é feita a administração dos usuários registrados
no sistema.
a) Listagem dos usuários: exibe todos os domos registrados no banco de dados
do sistema. Além da visualização é possível remover usuários, sincronização
forçada com o banco de dados, bem como carregar um usuário para edição,
através de um duplo clique.
b) Adição: adiciona um novo usuário ao sistema.
c) Edição: edita as informações de um usuário previamente cadastrado.
a) Listagem dos usuários
b) Adição
c) Edição
58
FIGURA 21: INTERFACE DE ADMINISTRAÇÃO DOS AGENDAMENTOS. ADIÇÃO, REMOÇÃO E EDIÇÃO FONTE: o autor (2011)
A figura 21 exibe a janela Agendamentos do software de gerenciamento. Nela
é feita todo o gerenciamento dos agendamentos criados para o sistema.
a) Listagem dos agendamentos: exibe todos os domos registrados no banco de
dados do sistema. Além da visualização é possível remover agendamentos e
sincronização forçada com o banco de dados.
b) Adição: adiciona um novo usuário ao sistema.
4.2. APLICATIVO MÓVEL
O aplicativo móvel atingiu as expectativas mínimas para interação confortável
com o usuário. Existem pontos de melhoria na interface visual, bem como a
a) Listagem dos agendamentos
b) Adição
59
otimização do código para reduzir processamento e uso da memória RAM do
dispositivo móvel. Estes dois pontos interferem diretamente no consumo do aparelho
e em sua velocidade de operação, sendo pontos fundamentais de melhoria.
FIGURA 22 - APLICATIVO MÓVEL FONTE: o autor (2011)
A figura 22 apresenta a tela inicial, que é mostrada quando o usuário executa
o aplicativo móvel. Ela fica visível por aproximadamente 500 ms, tempo necessário
para carregar as configurações, bibliotecas e afins. A aba de conexão é carregada
em seguida. Nela é feita a conexão com o servidor. Os valores de usuário, senha e
endereço do servidor são carregados automaticamente conforme a última utilização.
Tela inicial Aba de conexão
60
FIGURA 23 - APLICATIVO MÓVEL FONTE: o autor (2011)
A figura 23 apresenta as telas utilizadas para atuação no sistema. A aba dos
DOMOs contém todas as informações do DOMO selecionado, seu código, nome e
estado. Faz parte desta janela os botões para atuação no sistema e também o botão
para a escolha do domo.
4.3. HARDWARE
Tendo em vista que os objetivos do hardware que controla o DOMO eram de se
conectar ao servidor, responder ao sensor correspondente e de seguir o protocolo
descrito no item 3.5.1, pode-se considerar que os resultados obtidos foram conforme
Aba dos DOMOs Domos conectados
61
esperado. Primeiramente o programa busca as informações dos arquivos do cartão
SD conforme a figura 24.
FIGURA 24 - ARQUIVOS - IMPORTADOS OU EXPORTADOS PELO PROCESSADOR - DO CARTÃO SD FONTE: o autor (2011)
É possível visualizar que o DOMO conseguiu se conectar na rede com as
configurações contidas no cartão SD, analisando o Web Server do roteador da rede,
conforme a figura 25.
FIGURA 25 - NOME DO DOMO NA LISTA DE CLIENTES DHCP DO ROTEADOR FONTE: o autor (2011)
62
Apertando o botão de acionamento do sistema, a lâmpada acende – conforme
figura 26 - e envia a informação de mudança de estado para o servidor.
FIGURA 26 - ACIONAMENTO A PARTIR DO SENSOR FONTE: o autor (2011)
Para depurar os erros do programa foram utilizados os programas:
a) Tibbo I/O Ninja – Monitora a porta serial e cria conexões de cliente ou
servidor TCP.
b) Wireshark – Analisador de protocolo.
A porta de comunicação serial foi utilizada ao longo do desenvolvimento do
firmware em conjunto com um programa de monitoramento da porta serial para
depurar erros e fazer testes de funcionamento. Um exemplo da utilização deste
recurso foi o uso de transmissões seriais do micro-controlador para o computador
para cada função da comunicação TCP criada para montar o cliente sockets.
63
Utilizando este recurso em conjunto com o analisador de protocolos Wireshark, foi
possível detectar em que ponto do programa estava ocasionando algum erro.
A figura 27 demonstra uma comunicação entre o servidor e o DOMO através
do programa Ninja. Ao mesmo tempo, através do Wireshark, foi monitorado a
comunicação TCP/IP conforme a figura 28.
FIGURA 27 - DE COMUNICAÇÃO TCP/IP ATRAVÉS DO PROGRAMA NINJA FONTE: o autor (2011)
FIGURA 28 - MONITORAMENTO DA COMUNICAÇÃO TCP/IP ATRAVÉS DO WIRESHARK FONTE: o autor (2011)
64
5 CONCLUSÃO
Procurou-se com este projeto a concepção teórica e prática de um sistema de
domótica completo, contemplando hardware e software. A diferença do que foi
idealizado para o resultado final foi muito pequena. Os principais objetivos –
confecção de um DOMO de iluminação, software de gerenciamento e aplicativo
móvel – foram alcançados. As diferenças ficaram restritas basicamente a
complexidade de implantação de algumas ferramentas perante um tempo limitado
para o desenvolvimento.
Por se tratar de um projeto de baixo custo, visando à popularização da
automação residencial, o custo final do projeto era relevante. Este ponto norteou
algumas mudanças durante o decorrer do projeto, citando como exemplo a não
implementação do módulo Wi-Fi, o que dobraria o custo final de um DOMO. Ou
ainda, a utilização de uma placa para vários DOMOs. Algumas alterações foram
executadas e outras foram deixadas para futuras implementações.
Os softwares desenvolvidos tinham como objetivo uma operação simples e
intuitiva do sistema, o que foi atingido em sua totalidade. Tanto aplicativo móvel
quanto o software apresentam algo grau de confiabilidade em relação a bugs e
tratamento de erros na presença de mal-funcionamento de alguma das partes do
projeto.
5.1. TRABALHOS FUTUROS
Pensando em melhorias para o projeto, algumas idéias já fazem parte de uma
segunda geração do trabalho, sendo elas voltadas tanto para viabilização econômica
65
da idéia, quanto ampliação da gama de funcionalidades disponíveis em cada
DOMO. Algumas das idéias para trabalhos futuros são:
a) Implementação de um servidor de gerenciamento autônomo, removendo o
papel de servidor do computador e colocando em um dos DOMOs da
residência. Desta forma, o computador seria apenas mais um dispositivo de
atuação.
b) Gerar relatórios de consumo e utilização de energia elétrica de cada DOMO,
isto para inserção no conceito de eficiência energética.
c) Ampliação da gama de funcionalidades dos DOMOs. Implementar controle via
infravermelho (atuação em televisores, sistemas de som, ar-condicionado,
tudo que possua um controle remoto para operação), relés de maior potência
e integração com câmeras IP.
d) Operação de mais de um dispositivo em cada DOMO, talvez um DOMO por
cômodo, controlando vários elementos diferentes.
e) Implementação financeiramente viável de um adaptador Wi-Fi para o DOMO
(atrelado ao item anterior).
f) Desenvolvimento de uma placa compacta, removendo os itens
desnecessários que são encontrados no kit utilizado.
g) Desenvolvimento de uma interface mais rica e intuitiva para o aplicativo
móvel.
h) Migrar o código do aplicativo móvel para a plataforma Android Gingerbread,
esta otimizada para tablets.
66
6 REFERÊNCIAS
Android Reference. Disponível em:
<http://developer.android.com/reference/packages.html>. Acesso em 28/08/2011.
Beej's Guide to Network Programming Using Internet Sockets. Disponível em: <
http://lwip.wikia.com/wiki/Network_interfaces_management/>. Acesso em
08/10/2011.
BORLAND SOFTWARE CORPORATION. Borland C++ Builder Enterprise Suite
for Windows XP version 6.10.155. São Paulo, SP. 2 CD-ROM.
MARQUES, R. Conceito de automação residencial ganha espaço no mercado.
Disponível em: <http://www.aureside.org.br/imprensa/default.asp?file=10.asp>
Acesso em: 12/08/2011.
CASA do Futuro já é realidade no mercado. Revista Finestra, Rio de Janeiro,
número 68, mai/jun de 2011. Disponível em: <http://www.sinduscon-
rio.com.br/sindusletter/sindusletter_030811/n33.htm> Acesso em: 20/08/2011.
CHAN. FatFs – FAT file system module for small embedded systems R0.07e.
2009.154KB.
CODE RED. LPCXpresso's IDE for Windows 7 version 4.0.5. 2011. 372 MB.
Domótica – Introducción. Disponível em:
<http://www.casaDOMO.com/noticiasDetalle.aspx?c=14&m=21&idm=21&pat=20&n2
=20>. Acesso em: 12/08/2011
ECLIPSE FOUNDATION. Eclipse Classic for Windows 7 version 3.7.1. Ottwa,
ON, 2002. 175 MB.
Estatísticas de Celulares no Brasil. Disponível em:
<http://www.teleco.com.br/ncel.asp>. Acesso em 09/09/2011.
67
FatFs Generic FAT File System Module. Disponível em: < http://elm-
chan.org/fsw/ff/00index_e.html />. Acesso em 24/10/2011.
GERALD COMBS. Wireshark for Windows 7 version 1.6.2. 2011. 79.6MB
GOOGLE INC.. Android SDK 2.2 for Windows 7 API level 8. Mountain View, CA,
2011. 338MB.
Google’s Android becomes the world’s leading smart phone platform.
Disponível em: <http://www.canalys.com/static/press_release/2011/r2011013.pdf>.
Acesso em 12/08/2011.
Introdução às Redes de Computadores/Programação com sockets . Disponível
em:
<http://pt.wikiversity.org/wiki/Introdu%C3%A7%C3%A3o_%C3%A0s_Redes_de_Co
mputadores/Programa%C3%A7%C3%A3o_com_sockets>. Acesso em: 01/07/2011
In U.S. Market, New Smartphone Buyers Increasingly Embracing Android.
Disponível em: <http://blog.nielsen.com/nielsenwire/online_mobile/in-u-s-market-
new-smartphone-buyers-increasingly-embracing-Android/>. Acesso em: 15/09/2011.
Java API 7. Disponível em: <http://docs.oracle.com/javase/7/docs/api/index.html>
Acesso em: 28/08//2011.
LWIP WIKI – Raw/TCP. Disponível em: < http://lwip.wikia.com/wiki/Raw/TCP/>.
Acesso em 06/10/2011.
LWIP WIKI – Network interfaces management. Disponível em: <
http://lwip.wikia.com/wiki/Network_interfaces_management/>. Acesso em
06/10/2011.
NXP Semiconductors microcontroller support. Disponível em: <
http://ics.nxp.com/support/documents/microcontrollers/>. Acesso em 01/10/2011.
ORACLE CORPORATION. MySQL Community Server for Windows 7 version
5.5.18. Redwood Shores, CA.
Orientação para Normalização de Trabalhos Acadêmicos.
<http://www.portal.ufpr.br/normalizacao.html>. Acesso em 16/11/2011.
68
Small TCP/IP stacks for microcontrollers. Disponível em: <
http://www.utwente.nl/ewi/dacs/assignments/completed/bachelor/reports/B-
assignment_vanderPloeg.pdf/>. Acesso em 16/10/2011.
SWEDISH INSTITUTE OF COMPUTER SCIENCE. lwIP TCP/IP stack version
1.4.0. 2001. 3,91MB.
TIBBO TECHNOLOGY. TIBBO I/O NINJA for Windows XP version 1.5.2. 2008.
6.28MB
The Open Source Developer Report. Disponível em:
<http://www.eclipse.org/org/community_survey/Eclipse_Survey_2010_Report.pdf>.
Acesso em 21/10/2011.
ZEOSLIB. Zeos DBO Library for Windows XP version 6.6.6. 2009.1.73MB.
