UNIVERSIDADE FEDERAL DO PARANÁ DEPARTAMENTO DE ENGENHARIA ELÉTRICA CURSO DE ENGENHARIA ELÉTRICA. Maruan de Borba Mendes Thiago Mincoff Marcengo

Transcrição

1 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

2 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

3 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.

4 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.

5 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.

6 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.

7 LISTA DE FIGURAS FIGURA 1: FATIA DE MERCADO DOS SISTEMAS FIGURA 2: ESQUEMÁTICO DO PROJETO FIGURA 3: DIAGRAMA DE BLOCOS DE UMA CONEXÃO SOCKET FIGURA 4 - CONFIGURAÇÕES DOS DOIS COMPONENTES FIGURA 5 - CONFIGURAÇÕES E EVENTOS DO COMPONENTE FIGURA 6 - DIAGRAMA OPERACIONAL DO APLICATIVO MÓVEL FIGURA 7 - EMULADOR DISPONÍVEL NO ANDROID SDK (PLUGIN ADT) FIGURA 8 - FUNCIONAMENTO DA BIBLIOTECA FATFS FIGURA 9: ROTINA DO SERVIDOR DE GERENCIAMENTO FIGURA 10: ROTINA DO APLICATIVO MÓVEL FIGURA 11 - PAINEL DEMONSTRATIVO FIGURA 12 - FLUXOGRAMA DO MICROCONTROLADOR COM OS PERIFÉRICOS FIGURA 13 - INTERFACE DE ACIONAMENTO FIGURA 14 - FLUXOGRAMA DO FIRMWARE DO MICROCONTROLADOR FIGURA 15: CONTEXTO GERAL DAS TROCAS DE MENSAGENS ENTRE SERVIDOR DE DOMO FIGURA 16: CONTEXTO GERAL DAS TROCAS DE MENSAGEM ENTRE FIGURA 17: INTERFACE INICIAL DO SOFTWARE DE GERENCIAMENTO. SISTEMA DE AUTENTICAÇÃO FONTE: o autor (2011) FIGURA 18: INTERFACE DE ATUAÇÃO E VISUALIZAÇÃO DO SISTEMA FIGURA 19: INTERFACE DE ADMINISTRAÇÃO DOS DOMOS. ADIÇÃO, REMOÇÃO E EDIÇÃO FIGURA 20: INTERFACE DE ADMINISTRAÇÃO DOS USUÁRIOS. ADIÇÃO, REMOÇÃO E EDIÇÃO FIGURA 21: INTERFACE DE ADMINISTRAÇÃO DOS AGENDAMENTOS. ADIÇÃO, REMOÇÃO E EDIÇÃO FIGURA 22 - APLICATIVO MÓVEL... 59

8 FIGURA 23 - APLICATIVO MÓVEL FIGURA 24 - ARQUIVOS - IMPORTADOS OU EXPORTADOS PELO PROCESSADOR - DO CARTÃO SD FIGURA 25 - NOME DO DOMO NA LISTA DE CLIENTES DHCP DO ROTEADOR61 FIGURA 26 - ACIONAMENTO A PARTIR DO SENSOR FIGURA 27 - DE COMUNICAÇÃO TCP/IP ATRAVÉS DO PROGRAMA NINJA FIGURA 28 - MONITORAMENTO DA COMUNICAÇÃO TCP/IP ATRAVÉS DO WIRESHARK... 63

9 LISTA DE TABELAS TABELA 1 COMPARATIVO ENTRE FATIAS DE MERCADO DAS VERSÕES DO ANDROID TABELA 2 - LETRAS PARA IDENTIFICAÇÃO DO TIPO DE DOMO TABELA 3 - AÇÕES E ESTADOS DISPONÍVEIS PARA CADA TIPO DE DOMO TABELA 4 - MENSAGES UTILIZADAS NA COMUNICAÇÃO ENTRE SERVIDOR E DOMO TABELA 5 - EXEMPLO DE TROCA DE MENSAGES ENTRE SERVIDOR E DOMO TABELA 6 - MENSAGENS UTILIZADAS NA COMUNICAÇÃO ENTRE SERVIDOR E MÓVEL... 52

10 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.

11 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.

12 SUMÁRIO 1 INTRODUÇÃO CONTEXTUALIZAÇÃO DO PROBLEMA MOTIVAÇÃO E JUSTIFICATIVA OBJETIVOS Geral Específicos Software de Gerenciamento Aplicativo Móvel Hardware FUNDAMENTAÇÃO TEÓRICA SOCKETS SOFTWARE DE GERENCIAMENTO APLICATIVO MÓVEL Android e sua SDK Java e o Eclipse HARDWARE LPC LPCXPRSSO COMUNICAÇÃO SPI BIBLIOTECA LWIP BIBLIOTECA FATFS MATERIAIS E MÉTODOS EQUIPAMENTOS NECESSÁRIOS SOFTWARE DE GERENCIAMENTO APLICATIVO MÓVEL HARDWARE MENSAGENS, CÓDIGOS E NUMERAÇÃO... 48

13 Comunicação servidor com o DOMO Comunicação servidor com o móvel ANÁLISE DOS RESULTADOS SOFTWARE DE GERENCIAMENTO APLICATIVO MÓVEL HARDWARE CONCLUSÃO TRABALHOS FUTUROS REFERÊNCIAS... 66

14

15 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 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, mostramse 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 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 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 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 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 19 FIGURA 1: FATIA DE MERCADO DOS SISTEMAS OPERACIONAIS DE SMARTPHONES NOS ESTADOS UNIDOS NO ACUMULADO TRIMESTRAL ATÉ AGOSTO DE 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 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 ,0% Android ,7% Android ,3% Android ,7% Android 2.3 1,7% Android ,4% Android 3.0 0,2% Android 3.0 1,9% FONTE: modificação feita pelo autor (2011) 1.3. OBJETIVOS 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 21 FIGURA 2: ESQUEMÁTICO DO PROJETO FONTE: o autor (2011) Específicos 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 HARDWARE 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 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 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 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 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 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 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 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) 40

41 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) 42

43 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 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 microcontrolador, 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 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 microcontrolador 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 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) 47

48 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 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 l a s m Descrição Iluminação ("l" de lâmpada) Acessos ("a" de acessos) Segurança ("s" de segurança) Áudio e Vídeo ("m" de mídias) FONTE: o autor (2011)

49 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 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 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 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 A tabela 6 apresenta as

52 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 Servidor->Móvel DOMO 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) 53

54 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 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. a) b) Todos os DOMOs c) DOMOs d) Usuários e) Logs de comunicaçã 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.

56 56 b) Adição a) Listagem dos DOMOs c) Edição 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.

57 57 b) Adição a) Listagem dos usuários c) Edição 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.

58 58 a) Listagem dos agendamentos b) Adição 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 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