Embed Size (px)
Citation preview
TRABALHO DE GRADUAÇÃO
Central para Automação Residencial:
Desenvolvimento de um Software de
Monitoramento e Controle
Bruno Carbonari Pilon – RA 610054
Prof. Dr. Galdenoro Botura Jr.
SOROCABA
2011
UNIVERSIDADE ESTADUAL PAULISTA
“JÚLIO DE MESQUITA FILHO”
Campus Experimental de Sorocaba
2
BRUNO CARBONARI PILON
CENTRAL PARA AUTOMAÇÃO RESIDENCIAL: DESENVOLVIMENTO DE UM
SOFTWARE DE MONITORAMENTO E CONTROLE
Trabalho de graduação apresentado ao Conselho de Curso de Engenharia de Controle e Automação, Universidade Estadual Paulista “Júlio de Mesquita Filho”, como requisito parcial para a obtenção do grau de Engenheiro de Controle e Automação. Orientador: Prof. Dr. Galdenoro Botura Jr.
SOROCABA
2011
3
FICHA CATALOGRÁFICA
Pilon, Bruno Carbonari Central Para Automação Residencial: Desenvolvimento de um Software de Monitoramento e Controle – Sorocaba, 2011. Nº de páginas
Orientador: Prof. Dr. GaldenoroBotura Jr. Trabalho de Graduação–UNESP Universidade Estadual Paulista “Júlio de Mesquita Filho” 1.Automação Residencial; 2. Redes Wi-Fi;3. Linguagem C#
4
AGRADECIMENTOS
Aos meus companheiros de projeto e grandes amigos Danilo e Pedro, sem os
quais o desenvolvimento desse trabalho não teria sido possível.
Ao Prof. Dr. Galdenoro Botura Jr., pelas sábias orientações durante os cinco
anos de graduação.
Aos meus familiares e amigos, pela compreensão e apoio incondicional durante
o tempo que me dediquei a esse projeto.
À Deus, por me dar forças e coragem em todos os momentos de fraqueza e
desânimo.
5
“A Vida é maravilhosa se não se tem medo dela.”
(Charles Chaplin)
6
Sumário
LISTA DE ILUSTRAÇÕES ............................................................................................................................ 8 LISTA DE TABELAS .................................................................................................................................... 9 RESUMO ................................................................................................................................................ 10 ABSTRACT ............................................................................................................................................. 11 1 OBJETIVO ....................................................................................................................................... 12 2 INTRODUÇÃO ................................................................................................................................ 12 3 PROPOSTA DE PROJETO ................................................................................................................. 14
3.1 Motivação .............................................................................................................................. 14 4 REVISÃO BIBLIOGRÁFICA ................................................................................................................ 16
4.1 O Estado da Arte .................................................................................................................... 16 4.2 Sistemas Similares .................................................................................................................. 17
4.2.1 Active Home ................................................................................................................... 17 4.2.2 Cardio............................................................................................................................. 18 4.2.3 Mordomus ..................................................................................................................... 18 4.2.4 3NYX .............................................................................................................................. 19
4.3 Softwares Similares ................................................................................................................ 20 4.3.1 Visir ................................................................................................................................ 20 4.3.2 Um Mundo Virtual em 3D ............................................................................................... 20
5 REVISÃO TEÓRICA .......................................................................................................................... 20 5.1 A Tecnologia X10 .................................................................................................................... 20
5.1.1 Teoria de Transmissão de Sinais ..................................................................................... 21 5.2 Programação Orientada a Objetos.......................................................................................... 23
5.2.1 Objetos .......................................................................................................................... 24 5.2.2 Encapsulamento ............................................................................................................. 24 5.2.3 Polimorfismo .................................................................................................................. 25 5.2.4 Herança .......................................................................................................................... 25
5.3 Classes ................................................................................................................................... 25 5.4 Métodos ................................................................................................................................ 26 5.5 Bibliotecas ............................................................................................................................. 26 5.6 A Linguagem C#...................................................................................................................... 27
5.6.1 A Plataforma .NET .......................................................................................................... 27 5.6.2 Sockets ........................................................................................................................... 28
5.7 A Tecnologia Wi-Fi ................................................................................................................. 28 5.7.1 Padrões .......................................................................................................................... 29 5.7.2 Elementos de Hardware ................................................................................................. 30 5.7.3 Tipos de Rede Wi-Fi ........................................................................................................ 31
6 ESPECIFICAÇÕES ............................................................................................................................ 32 6.1 Especificações do Sistema ...................................................................................................... 32
6.1.1 O Modelo Utilizado......................................................................................................... 32 6.1.2 Representação Esquemática do Sistema ......................................................................... 33
6.2 Especificações do Software .................................................................................................... 35 6.2.1 As Classes ....................................................................................................................... 38 6.2.2 Os Métodos .................................................................................................................... 40 6.2.3 Os Eventos ..................................................................................................................... 43
7
6.2.4 Os Vetores “Frame” e “Buffer” ....................................................................................... 45 7 DESENVOLVIMENTO DO PROJETO.................................................................................................. 46
7.1 As Telas do Software .............................................................................................................. 49 7.2 O Início da Conexão................................................................................................................ 53 7.3 A Manipulação das Variáveis “frame” e ”buffer” .................................................................... 57
8 RESULTADOS E DISCUSSÕES ........................................................................................................... 59 8.1 Testes da Interface ................................................................................................................. 59 8.2 Testes Iniciais da Comunicação Wi-Fi...................................................................................... 60 8.3 Testes de Monitoramento ...................................................................................................... 61
8.3.1 Temperatura e Sistema de Ventilação ............................................................................ 62 8.3.2 Persiana ......................................................................................................................... 63 8.3.3 Os sensores indutivos ..................................................................................................... 63 8.3.4 Outros Testes Gerais com Integração do Sistema............................................................ 63
9 CONCLUSÕES ................................................................................................................................ 64 10 REFERÊNCIAS BILIOGRÁFICAS ........................................................................................................ 65 Apêndice A - CÓDIGO FONTE DA APLICAÇÃO ......................................................................................... 68 Apêndice B – INTERFACE GRÁFICA COMPLETA ....................................................................................... 68
8
LISTA DE ILUSTRAÇÕES
Figura 1 - Representação da comunicação do sistema Active Home. ...................................................... 17
Figura 2 - Tela de comando do Cardio. ................................................................................................... 18
Figura 3 - Interface do Mordomus. ......................................................................................................... 19
Figura 4 - 3NYX sendo controlado a partir de um Tablet. ....................................................................... 19
Figura 5 - Funcionamento da tecnologia X10. ........................................................................................ 21
Figura 6 - Envio de sinais via tecnologia X10 [2]. .................................................................................... 22
Figura 7 - Envio de comandos através da tecnologia X10 [2]. ................................................................. 23
Figura 8 - Planta do cômodo utilizado como modelo. ............................................................................. 33
Figure 9 - Representação do funcionamento do Sistema........................................................................ 34
Figura 10 - Ambiente de desenvolvimento utilizado - Microsoft Visual Studio 2010. .............................. 47
Figura 11 - Tela inicial do Programa. ...................................................................................................... 48
Figura 12 - Tela de Controle, supondo que o usuário tenha optado inicialmente por controlar a
Iluminação............................................................................................................................................. 49
Figura 13 - Controle da iluminação. ....................................................................................................... 50
Figura 14 – Controle de temperatura. .................................................................................................... 51
Figura 15 - Portas, Janelas e Persiana. .................................................................................................... 52
Figura 16 - Status Geral do Sistema........................................................................................................ 53
Figura 17 - Início do processo de conexão. ............................................................................................. 55
Figure 18 - Processo de construção das variáveis "frame" e "buffer". .................................................... 58
9
LISTA DE TABELAS
Tabela 1 - Padrões de Transmissão Wi-Fi. .............................................................................................. 29
Tabela 2 - Principais hardwares de uma rede Wi-Fi. ............................................................................... 30
Tabela 3 - Relação das variáveis do software. ........................................................................................ 36
Tabela 4 - Classes utilizadas no software e suas definições. ................................................................... 39
Tabela 5 - Métodos utilizados no software e suas definições. ................................................................ 40
Tabela 6 - Vetor "frame" e "buffer". ...................................................................................................... 46
10
RESUMO
Este trabalho apresenta a proposta, justificativas, especificações e desenvolvimento de
um software de monitoramento e controle para um sistema voltado à automação
residencial com interface intuitiva baseado na planta de um cômodo pré-determinado e
desenvolvido a partir da linguagem C# através da plataforma “Visual Studio 2010”. O
software proposto é capaz de atuar sobre as seguintes variáveis: temperatura,
luminosidade e presença. A partir das alterações realizadas pelo usuário, o software
atualiza todo o sistema através do envio de dados através de uma rede Wi-Fi. Toda e
qualquer alteração do sistema também é recebida pelo software através da mesma
rede Wi-Fi. O programa é capaz de desmembrar as informações recebidas e atualizá-
las de maneira a exibi-las de forma clara e prática ao usuário.
11
ABSTRACT
This job presents a proposal, justifications, specifications and development of a
monitoring and control software for a system focused on home automation with intuitive
interface based on the plan of a predetermined room and developed from the c #
language through the platform "Visual Studio 2010". *The proposed software is able to
act on the following variables: temperature, luminosity and presence. From the changes
made by the user, the software updates the whole system by sending data through a
Wi-Fi network. Every or any modification of the system is also received by the software
via the same Wi-Fi. The program is able to dismember the information received and
update them to display them clearly and practice to the user.
12
1 OBJETIVO
O intuito desse trabalho é apresentar o desenvolvimento de um software de
controle e monitoramento das variáveis físicas como temperatura, luminosidade,
presença e status de portas, janelas e persianas de um cômodo pré-determinado.
Também são apresentados sistemas semelhantes e suas tecnologias, que já são
utilizados atualmente, a fim de comparar pontos bons e ruins com o programa aqui
proposto.
2 INTRODUÇÃO
Toda tecnologia desenvolvida pelo homem tem, de uma forma geral, o objetivo de
facilitar algum processo ou tarefa. Para exemplificar, é possível citar a criação de
tecnologias como: as máquinas a vapor, os meios de geração de energia elétrica e os
veículos automotores. Através do desenvolvimento dessas inovações, atividades que
antes eram realizadas manualmente ou que demandavam muito tempo, tornaram-se
mais simples e práticas.
Ainda dentro desse contexto, que visa criar praticidade a partir da inovação
tecnológica, pode citar o surgimento do conceito de automação residencial, também
conhecido como Domótica.
A palavra Domótica é a junção da palavra latina Domus (casa) e do termo
Robótica e é utilizada na descrição de recursos tecnológicos que permitem tornar
atividades domiciliares mais seguras, práticas e confiáveis (ANGEL, 1993).
Para citar exemplos de como algumas atividades domiciliares podem se tornar
mais práticas pode-se pensar em acender ou apagar uma lâmpada através de um
dispositivo móvel, tal como celulares do tipo “Smarth Phone” ou “Tablets”, desta forma,
o usuário não precisa se deslocar até um interruptor. Quanto à questão de
confiabilidade, é possível controlar dispositivos como um sistema de ar condicionado
levando em conta se há janelas ou portas abertas, ou se a temperatura ambiente por si
só já seria agradável o suficiente ao usuário, sem a necessidade de acionar o sistema
13
de refrigeração. Todas essas variáveis – portas ou janelas abertas e temperatura
ambiente – podem ser obtidas através de sensores presentes na própria residência, o
que assegura que os desperdícios sejam minimizados ou até mesmo eliminados.
Quanto à segurança é possível fazer uso de câmeras de segurança sem fio, sensores
de movimento, dentre outros dispositivos que podem ser monitorados remotamente,
permitindo que o usuário saiba o que acontece nas proximidades de sua residência
mesmo estando dentro de casa, garantindo, dessa forma, sua própria segurança.
Este trabalho apresenta ao leitor o Estado da Arte do ramo da Automação
Residencial. Em seguida apresenta uma proposta do projeto de um sistema capaz de
monitorar e controlar variáveis físicas em uma residência, bem como as principais
motivações que levaram ao desenvolvimento do mesmo. Após dar uma visão geral,
são apresentadas todas as especificações do sistema, assim como as justificativas
técnicas para a escolha dessas especificações. Tendo descrito o sistema juntamente
com suas características, são apresentadas todas as metodologias utilizadas para o
desenvolvimento, bem como os testes realizados para validação das propostas iniciais,
presentes na Proposta de Trabalho de Graduação, e seus resultados, que são
comparados com os dos sistemas apresentados como Estado da Arte, a fim de
comprovar o diferencial do projeto proposto. Por fim, com base nos testes e resultados
obtidos, são apresentadas as conclusões e propostas de trabalhos futuros.
O projeto aqui descrito funciona de forma integrada com outros dois trabalhos de
conclusão de curso que foram desenvolvidos paralelamente e com supervisão do
mesmo orientador. São eles: “Central para Automação Residencial: Controle por
dispositivo portátil com rede de sensores e atuadores sem fio”(ESTEVES, 2011),
desenvolvido por Danilo Henrique Esteves e “Central para Automação Residencial:
Hardware de aquisição de dados e comunicação com a central”(ROSA, 2011)
desenvolvido por Pedro Henrique Bordim Rosa, a fim de compor um sistema completo
de automação residencial capaz de atender as necessidades atuais do ramo.
14
3 PROPOSTA DE PROJETO
O trabalho aqui apresentado visa o desenvolvimento de um software intuitivo e de
fácil operação, voltado para automação residencial e que permita ao usuário final –
morador – controlar as seguintes variáveis de sua residência: luminosidade,
temperatura e status de portas, janelas e persianas. Sob o ponto de vista do status, o
usuário terá acesso à informação da situação atual de portas, janelas e da persiana,
podendo visualizar através do programa se o portas e janelas encontram-se abertas ou
fechadas e, no caso da persiana, poderá visualizar em qual nível a mesma se encontra.
O software permitirá o controle direto dessas variáveis através da atuação direta do
usuário, por comandos executados através do programa, ou de forma indireta, por
exemplo, em casos em que o morador queira acionar um determinado atuador baseado
no fato de haver alguém presente no cômodo ou não.
Estruturalmente, o desenvolvimento de todo o software é proposto com base na
linguagem C#, pertencente à plataforma .Net, da Microsoft, a fim de, explorar os
recursos e facilidades que essa plataforma pode apresentar no desenvolvimento de
aplicações no campo da Domótica.
O envio dos comandos executados pelo é desenvolvido através da tecnologia Wi-
Fi - apresentada com mais detalhes na seção “Especificações”. Ao propor esse tipo de
comunicação, tem-se como principal intuito a eliminação de quaisquer tipos de cabos e
meios físicos, tais como a rede elétrica.
Dessa forma, através dos recursos de controle e monitoramento do software, os
moradores poderão, de uma forma prática e rápida, conhecer e atuar sobre as
características atuais do ambiente da maneira que mais lhes agradarem, além de poder
usufruir de recursos que permitam aumentar economia de recursos energéticos.
3.1 Motivação
Através da observação do dia-a-dia é possível notar que o desaparecimento dos
fios é algo cada vez mais comum e isso é notado pela utilização cada vez mais
15
freqüente de dispositivos móveis, como celulares do tipo “Smarth Phones”, “Tablets” ou
computadores portáteis, como “NoteBooks” e de tecnologias que também buscam
eliminar a ligação física entre dispositivos, como o Wi-Fi.
Tendo isso em vista a primeira motivação para o desenvolvimento desse projeto
foi a busca por um software capaz de operar sem depender de ligações físicas, através
de fios ou de redes elétricas, visando proporcionar ao usuário final a maior mobilidade
possível no que diz respeito à possibilidade de controlar os parâmetros de sua
residência, tais como luminosidade, temperatura e presença, de qualquer ponto
desejado, tanto de dentro ou próximo à residência quanto de fora do perímetro da
mesma – através de um celular – por exemplo.
Outro ponto importante foi o interesse em utilizar tecnologias de transmissão de
dados que, apesar de ainda não exploradas ou pouco exploradas no ramo da
Domótica, mostram-se promissoras e adequadas a tal aplicação, como o Wi-Fi. Levou-
se em conta também que o fato desses sistemas dependerem da rede elétrica faz com
que os mesmos tenham sua capacidade de transmitir informações limitada pela
freqüência da rede, o que não ocorre com o programa aqui proposto.
Além da transmissão de dados também foram utilizadas novas tecnologias de
desenvolvimento, tal como a Plataforma .NET, a fim de explorar o potencial e as
facilidades que a mesma pode proporcionar ao ramo de automação.
Do ponto de vista do usuário final a maior motivação é a economia, uma vez que,
através das novas tecnologias citadas, esse tipo de sistema também pode contribuir de
forma direta para a economia de recursos energéticos e, consequêntemente, com a
economia de financeira, uma vez que se torna possível monitorar e identificar quando o
uso de um determinado recurso é realmente necessário ou não.
16
4 REVISÃO BIBLIOGRÁFICA
4.1 O Estado da Arte
Aqui são apresentados inicialmente sistemas semelhantes ao proposto aqui.
Posteriormente apresentar-se-ão alguns desses sistemas já disponíveis no mercado e,
por fim, softwares semelhantes ao aqui sugerido, que comandam sistemas voltados
para automação residencial.
Na literatura atual podem ser encontradas diferentes abordagens sobre como
estruturar um sistema de automação residencial:
Uma primeira abordagem seria a estruturação de tal sistema composto por
produtos de diversos fabricantes, baseando-se na pluralidade como forma de
assegurar a inovação através da utilização de marcas competidoras no mercado. Essa
proposta baseia-se no desenvolvimento de um sistema aberto (não proprietário)
dividido em duas partes: uma infraestrutura de rede heterogenia - passível de
atualizações - e um método para descrição dos dispositivos que compõe o sistema. A
infraestrutura consiste em um gateway que permite a troca de dados entre diferentes
tipos de rede. Usando módulos genéricos de comunicação, que trazem embutidas
diferentes tecnologias de comunicação, é possível atualizar o hardware presente no
sistema sempre que possível. Para habilitar serviços e configurações semi-
automáticas, os dispositivos do sistema devem fornecer um método de descrição de
dispositivo escrito em uma linguagem própria de cada fabricante, que compreende uma
parte de descrição sintática e outra de descrição semântica. (Torbensen, 2008)
Outro tipo de estrutura apresentada consiste em uma aplicação que permite
monitoramento - local e remoto – além do controle residencial. Essa aplicação adota a
filosofia de programação orientada a objeto, na qual cada dispositivo é representado
através de um objeto. Essa característica permite uma visão mais integrada da
residência, onde todos os dispositivos são tratados de forma semelhante através do
uso de métodos de atualização e sensoriamento. A aplicação roda em um PC com um
servidor de Internet. A interface com o usuário é rodada em um navegador usando
17
aplicativos desenvolvidos nas linguagens HTML e Java. A integração com o restante do
sistema é feita através de um hardware específico, como uma porta serial ou USB ou
ainda através de uma conexão de rede local. O usuário é capaz de criar cenários – que
são um conjunto de estados pré-determinados dos dispositivos que pode ser ativados
diretamente pelo usuário ou por um evento ocorrido na residência. (Nunes, 2000)
4.2 Sistemas Similares
4.2.1 Active Home
Desenvolvido na França, é baseado no protocolo X-10 (EURO X10, 2010), que
dispensa outros tipos de fiação além da já existente, pois envia sinais através da rede
elétrica. Trata-se de um sistema relativamente simples, que não possui uma interface
intuitiva, uma vez que os comandos partem de um dispositivo de rádio frequência,
como ilustrado na figura 2. Sua vantagem é justamente o chamado retrofit, ou seja, a
possibilidade de utilização da estrutura de fiação já existente para a instalação da
automação (ACTIVE HOME, 2010).
Como pode ser observado na figura 2, esse sistema depende de um computador
para ser controlado, o que pode ser considerado uma desvantagem do ponto de vista
econômico, pois aumenta o preço final ao consumidor, além de ocupar mais espaço do
que um dispositivo móvel, por exemplo.
Figura 1 - Representação da comunicação do sistema Active Home.
18
4.2.2 Cardio
Desenvolvido em Portugal, esse sistema apresenta uma mobilidade maior pois,
diferentemente do Active Home, pode ser controlado a partir de um painel touch-
screen, acoplado à parede – como mostra a figura 3 - ou via celular (CARDIO, 2010). A
tela fornece uma interação maior e mais intuitiva com o usuário, uma vez que torna-se
mais fácil a visualização do status do sistema. Por outro lado o fato da tela ser fixa à
parede pode dificultar a operação do sistema se o usuário encontrar-se sem o celular
em mãos.
Figura 2 - Tela de comando do Cardio.
4.2.3 Mordomus
Também desenvolvido em Portugal, parte deste sistema utiliza a tecnologia do X-
10, porém aqui já são incorporados recursos mais sofisticados voltados à multimídia
(TV, Home-Theater e Som) e à segurança (vídeo-porteiro e alarme contra invasão),
que podem ser controlados a partir do celular do usuário. Outro diferencial é que,
apesar de possuir uma tela touch-screen, assim como o Cardio, a tela do Mordomus é
maior, como pode ser observado na figura 4, propiciando mais clareza e facilidade em
relação à utilização da interface (MORDOMUS, 2010).
19
Figura 3 - Interface do Mordomus.
4.2.4 3NYX
Este sistema foi desenvolvido por uma empresa chamada Jet Home Automation,
cujo fundador é brasileiro. É um sistema baseado em protocolo IP (protocolo
largamente utilizado em aplicações na Internet) e o controle se dá através de um
dispositivo do tipo Tablet, utilizando o protocolo Wi-Fi – como mostrado na figura 5, ou
através de uma central touch-screen fixa (3NYX, 2010). Este foi o sistema mais
completo encontrado durante o levantamento do estado da arte. Funções como
controle do sistema de iluminação com a criação de configurações pré-definidas,
controle de equipamentos de entretenimento, central multimídia integrada aos falantes
espalhados pela residência, visualização das imagens de câmeras de segurança e o
acionamento de qualquer outro equipamento com a utilização de um módulo de
controle sem fio.
Figura 4 - 3NYX sendo controlado a partir de um Tablet.
20
4.3 Softwares Similares
4.3.1 Visir
Com a principal preocupação com os custos em desenvolver e implementar um
sistema de automação como um todo, foi desenvolvido um software chamado “Visir”.
Esse software não comando periféricos ou variáveis diretamente, ao contrário, é
utilizado para simular o controle e monitoramento de sistemas de automação
residencial. Essa ferramenta é composta por três partes principais: um Editor, uma área
de projeto e desenho e, por fim, uma área destinada a simulação do que foi projetado.
Uma de suas grandes vantagens está no fato de permitir a visualização de problema de
projeto que surgiriam ao implementar um sistema e poder prevenir ou minimizá-los
previamente (GONZÁLEZ, 2002).
4.3.2 Um Mundo Virtual em 3D
O software aqui apresentado controla diretamente um sistema de automação
residencial, sendo capaz de comandar variáveis como iluminação, portas e dispositivos
eletrônicos. Sua principal característica está no fato do usuário não fazer isso
diretamente com, mas sim atrás de um personagem próprio, através de um mundo
virtual em 3D. O usuário consegue visualizar o ambiente e dessa forma controlar as
variáveis de forma a visualizar melhor o que está acontecendo no cômodo (HAN,
2009).
5 REVISÃO TEÓRICA
5.1 A Tecnologia X10
O X10 é um protocolo normalizado, ou seja, qualquer fabricante poderá
desenvolver produtos baseados nesta tecnologia. Este protocolo é utilizado para
desenvolvimento de aplicações no ramo da Domótica, através do uso da rede elétrica
existentes em uma residência para enviar e receber os comandos para os dispositivos
21
do sistema. O seu baixo preço, facilidade de uso e variedade de equipamentos
tornaram o X10 o protocolo de Domótica mais conhecido no mundo durante alguns
anos (EURO X10, 2010).
A utilização da rede elétrica tornou-se a melhor característica dessa tecnologia,
tornando-a uma tecnologia descentralizada, ou seja, que não necessita de nenhum
elemento central para seu funcionamento.
Um sistema X10 pode ser simplesmente constituído por um conjunto de
dispositivos que são comandados diretamente pelo utilizador. Por exemplo, através de
um telecomando RF (rádio-frequência), o utilizador poderá enviar um comando para o
receptor X10/RF, que é transmitido através da rede elétrica à um atuador X10 que, por
sua vez, liga ou desliga um aparelho. A seguir, na figura 1 pode-se observar o
esquema descrito acima.
Figura 5 - Funcionamento da tecnologia X10.
5.1.1 Teoria de Transmissão de Sinais
A comunicação do X10 baseia-se na injeção de sinais de alta-frequência (120
KHz) sobre a rede de 220 Volts, representando sinais binários, ou seja, 1 ou 0. O sinal
é inserido logo a seguir à passagem pela origem da onda senoidal de 60 Hz, com um
atraso máximo de 200 micro-segundos. Esta particularidade é usada pelos receptores
para saberem quando devem escutar a linha. O sinal é enviado através da rede elétrica
de energia até aos receptores X10, ligados à rede.
22
Para permitir o uso em instalações elétricas trifásicas, os sinais de 120 kHz são
emitidos três vezes em cada ciclo, em instantes que coincidem com a passagem por
zero da tensão de cada uma das fases.
Dado que o meio de distribuição de energia elétrica apresenta problemas com
ruídos, foi adotada uma política em que um bit nunca é enviado isoladamente, sendo
sempre enviado o bit e o seu complemento. Isto significa na prática que, sempre que se
pretende enviar o bit 1, isso corresponde a enviar um 1 (sinal de 120kHz na origem)
seguido de um 0 (ausência de sinal). O envio do bit 0 corresponde a enviar um 0
(ausência de sinal) seguido de um 1 (frequência de 120kHz na origem). A figura 6
ilustra os pontos em que o sinais de 120 kHz são injetados na rede.
Figura 6 - Envio de sinais via tecnologia X10 [2].
Este cuidado visa minimizar a probabilidade do ruído elétrico poder ser confundido
com um sinal válido. Contudo, tem como aspecto negativo reduzir o ritmo de
transmissão que fica assim restrito a 60 bits por segundo.
Uma transmissão completa de um comando X10 engloba a transmissão de quatro
campos que utilizam onze ciclos. O primeiro campo, com dois ciclos, representa o Start
Code – sequência de bits 1 1 1 0. Este primeiro trecho não realiza o envio dos
complementos. O campo seguinte, representado em 4 ciclos, representa o código da
casa e seus respectivos complementos. Da mesma forma, seguem-se mais quato bits,
que ocupam 4 ciclos e representam o código do aparelho ou o código da função. Para
23
distinguir este último campo é enviado um último bit (e respectivo complemento) que
identifica se o campo anterior se refere ao número de um dispositivo (bit = 0) ou ao
código de uma função (bit = 1).
Cada pacote completo deve ser enviado em dois grupos,o primeiro a indicar o
aparelho e o segundo a função a ser executada, com no máximo, três ciclos de
diferença entre eles. A figura representa o envio de um comando de acordo com o
descrito.
Figura 7 - Envio de comandos através da tecnologia X10 [2].
5.2 Programação Orientada a Objetos
De acordo com (SCHILDT, 2004), a programação orientada a objetos utiliza as
melhores idéias da programação estruturada e as combina com vários conceitos novos.
O resultado é uma maneira mais clara de organizar um programa. Em geral, um
programa pode ser organizado de duas maneiras: com base em seu código, ou seja,
com base na rotina está sendo desenvolvida; ou em seus dados, ou seja, com base
nas informações que estão sendo afetadas. Quando apenas técnicas de programação
estruturada são utilizadas, os programas são organizados com base no código. Essa
abordagem também pode ser conhecida como “código atuando sobre os dados”
(SCHILDT, 2004).
Os programas orientados a objetos funcionam de forma inversa. Eles são
organizados com base nos dados, com o fundamento principal de que “os dados
24
controlam o acesso ao código” (SCHILDT, 2004). Em uma linguagem orientada a
objeto, definem-se os dados e as rotinas que atuarão sobre eles.
5.2.1 Objetos
Baseando-se no conceito de Linguagem Orientada a Objetos, um objeto
representa uma entidade dentro do software. É uma abstração de algo que possui uma
forma definida e um significado para a aplicação (MIZHARI, 2006).
Um objeto existe a partir de um molde que define seus atributos e suas utilidades.
A vantagem do uso de objetos é que os mesmos permitem utilizar determinadas
partes do código de um programa de forma genérica, sem a necessidade de estruturar
uma nova parte. Por exemplo, para um mesmo aparelho celular pode-se utilizar
diversos chips diferentes, não há a necessidade de ter um aparelho diferente para cada
chip.
A seguir são apresentadas as principais características de uma linguagem
orientada a objeto: encapsulamento, polimorfismo e herança.
5.2.2 Encapsulamento
Trata-se do mecanismo que vincula o código aos dados que ele manipula e
mantém os dois protegidos da interferência externa. Em uma linguagem orientada a
objeto o código e os dados podem ser vinculados de forma a criar uma caixa preta.
Criado esse vínculo entre código e dados, diz-se que foi criado um objeto. Em outras
palavras, um objeto é um dispositivo que dá suporte ao encapsulamento (SCHILDT,
2004).
Pode-se, também, definir uma classe como unidade básica de encapsulamento.
Uma classe define a forma de um objeto e especifica tanto os dados quanto o código
que funcionará com esses dados. Portanto, dentro desse contexto, pode-se afirmar que
25
um objeto é uma instância de uma classe e uma classe é um conjunto de planos que
especificam como construir um objeto.
5.2.3 Polimorfismo
O polimorfismo (do grego “muitas formas”) é a qualidade que permite que uma
interface acesse uma classe geral de ações. Por exemplo: considerando uma pilha –
estrutura na qual o primeiro dado a entrar é o último a sair. Pode haver casos em que
um programa necessite de três pilhas diferentes: uma para valores inteiros, outra para
valores de ponto flutuante e outra para caracteres. Para essa situação o código que
implementará as três pilhas será o mesmo, apesar dos tipos de dados que serão
armazenados serem diferentes.
Dessa forma, o conceito de polimorfismo costuma ser expresso como “uma
interface, vários métodos” (SCHILDT, 2004).
5.2.4 Herança
É o processo pelo qual um objeto pode adquirir as propriedades de outro objeto.
Sem o uso de hierarquias, cada objeto teria que definir explicitamente todas as suas
características. Através dessa propriedade ele só tem que definir as características que
o tornam único dentro de sua classe.
5.3 Classes
Uma Classe é um modelo que define a forma de um Objeto, especificando tanto
o código quanto os dados que agem sobre o mesmo. Uma Classe é essencialmente
um conjunto de planos que especifica como construir um objeto (MIZHARI, 2006).
Uma Classe é uma abstração lógica, e é importante ressaltar que só a partir do
momento que um objeto é criado, é que passa a existir uma representação física desta
Classe.
Ao definir uma Classe, define-se os dados que ela contém e o código sobre o
qual ela operará. Os dados são armazenados nas variáveis da Classe e manipulados
26
por determinados Métodos da mesma Classe. Todo código e dados que compõe uma
classe são chamados de membros da Classe.
5.4 Métodos
Métodos são essencialmente procedimentos que podem manipular atributos de
objetos para os quais o Método foi definido. Além de atributos, Métodos podem definir e
manipular variáveis, que são chamadas de variáveis locais.
Normalmente, a fim de manter a funcionalidade dos Métodos de um programa,
desenvolvem-se Métodos para realizar apenas uma função, além de definir um nome
para o mesmo que reflita de modo adequado a tarefa a ser realizada (MIZHARI, 2006).
Uma importante característica de um Método é o fato do mesmo poder receber
informações, como o valor de uma variável, ao ser chamado em um determinado ponto
do programa. Essas informações são conhecidas como parâmetros serão utilizadas
pelo Método na realização da função para a qual o mesmo foi desenvolvido. Métodos
também podem operar sem receber parâmetros, apenas alterando valores de varáveis
locais, por exemplo.
5.5 Bibliotecas
De acordo com (MIZHARI, 2006), ao escrever um programa usando uma
linguagem de programação, existe a possibilidade de utilizar um conjunto de funções e
rotinas pré-escritas. Esses conjuntos de funções ficam normalmente armazenados em
arquivos diferentes do que contam o código-fonte do programa, sendo chamados pelo
programa principal, para que o mesmo possa fazer uso das rotinas pré-estabelecidas.
Estes arquivos são denominados bibliotecas.
As bibliotecas têm como principal objetivo eliminar a necessidade do programador
ter que desenvolver determinadas rotinas toda vez que necessitar utilizá-las. Por
exemplo, ao invés de desenvolver uma função que calcule o cosseno de um ângulo, o
programador pode utilizar uma biblioteca de funções matemáticas que já contém essa
função pronta bastando que, para isso, inclua a biblioteca em seu programa.
27
A maior parte dos programas modernos provê bibliotecas que implementam a
maioria dos serviços do sistema. Assim sendo, a maior parte do código utilizado em
aplicações modernas é fornecido por estas bibliotecas.
5.6 A Linguagem C#
A linguagem C# (pronuncia-se “C-Sharp”) foi anunciada pela Microsoft no ano de
2000 e que faz parte da Plataforma. NET – plataforma apresentada com mais detalhes
e é baseada em linguagens que a precedem: C, C++ e Java. Como tal, C# também é
uma linguagem orientada a objetos e, dessa forma possui todas as principais
características de uma linguagem desse tipo, como Encapsulamento, Polimorfismo e
Herença. Essa linguagem faz uso de uma biblioteca também criada pela Microsoft
chamada .NET Framework Class Library – uma vasta coleção de métodos e classes
pré-estabelecidos que permitem ao desenvolvedor criar aplicações de forma mais
rápida e eficiente, o que a torna ideal para desenvolver a grande maioria dos tipos de
aplicações atuais, como aplicações para Web, aplicações para dispositivos móveis e
sotwares de controle de processos, como o proposto nesse trabalho (DEITEL, 2011).
Outra importante característica presente nessa linguagem é o fato da mesma ser
Guiada a Eventos. Isso significa que a aplicação desenvolvida responde a ações do
usuário como, por exemplo, o clique do mouse, o término de um determinado intervalo
de tempo ou a alteração de um valor em uma determinada caixa de texto, etc.
5.6.1 A Plataforma .NET
Como citado na seção 4.6, a linguagem C# foi criada em 2000, pela Microsoft.
Esta linguagem faz parte de uma plataforma lançada no mesmo ano e conhecida como
Plataforma .NET. Trata-se de um conjunto de linguagens de programação (como C#,
Visual Basic, entre outras) capazes de permitir o desenvolvimento de aplicações que
funcionem tanto em computadores como Desktops e Notebooks, quando na Internet,
sem a necessidade de reestruturar todo o software para que isso seja possível. Dessa
forma, uma aplicação desenvolvida inicialmente para um computador, pode ser
28
facilmente adaptada para funcionar on-line, através da Internet. Essa característica
permite, por exemplo, acesso remoto de sistemas desenvolvidos com C#.
5.6.2 Sockets
Um Socket pode ser entendido como um canal de comunicação que precisa ser
estabelecido para que a troca de informações entre um cliente e um servidor seja
possível (MAKOFSKE, 2004). Para que tal canal possa criado é necessário que alguns
parâmetros sejam definidos, tais como endereço de IP com o qual deseja-se
comunicar, porta de comunicação, o tipo da conexão e o protocolo a ser utilizado.
Abaixo, segue uma breve descrição de cada um desses parâmetros:
Endereço IP: é um número único que identifica um computador em uma rede.
Porta de Comunicação: também identificada por um número, uma porta de
comunicação é uma abstração que representa a via através da qual a informação sai
ou entra de um computador quando o mesmo se comunica através da rede.
Protocolo de Comunicação: pode ser entendido como o conjunto de regras que
rege a comunicação entre dispositivos em uma rede. Um dos mais utilizados hoje é
o protocolo TCP/IP, que engloba o conceito de endereço IP, apresentado acima.
Tipo de Conexão: no caso do protocolo TCP/IP o tipo de conexão mais
comumente utilizado é a conexão via STREAM, mais conhecida como “Orientada a
Conexão”. Nesse tipo há uma verificação prévia das informações antes do
estabelecimento da conexão e após um envio/recebimento para verificar a
integridade dos dados.
5.7 A Tecnologia Wi-Fi
Segundo (FARIAS, 2006), as redes sem fio surgiram da mesma forma que muitas
outras tecnologias, no meio militar, devido a necessidade de implementação de um
método simples e seguro de troca de informações em um ambiente de combate. Com o
passar do tempo essa tecnologia evoluiu e deixou de ser restrita ao meio militar,
tornando-se acessível à empresas, faculdades e aos usuários domésticos. Atualmente,
29
pensa-se nesse tipo de rede como uma alternativa bastante interessante em relação às
redes cabeadas, uma vez que não há necessidades de ligações físicas, através de
cabos, o que torna sua montagem mais simples e menos trabalhosa.
5.7.1 Padrões
Atualmente existem diferentes padrões operacionais para uso dessa
tecnologia.Tais padrões são estabelecidos pelo IEEE (Institute od Eletrical and
Eletronic Engineers) (FARIAS, 2006). Cada padrão possui suas características técnicas
de funcionamento e são apresentados abaixo, na tabela 1:
Tabela 1 - Padrões de Transmissão Wi-Fi.
IEEE 802.11
Criado em 1994, foi o padrão original;
Oferecia taxas de transmissão de 2 Mbps (Megabits por
segundo);
Caiu em desuso com o surgimento de novos padrões.
IEEE 802.11b
Possui taxas de transmissão de 11 Mbps;
Primeiro padrão largamente utilizado;
Opera em 2,4 GHz;
Alcance de até 300 metros em lugares abertos;
Caiu em desuso com a popularização do padrão 802.11g.
IEEE 802.11ª
Possui taxas de transmissão de 54 Mbps;
Opera em 5GHz;
Alcance de até 100 metros em lugares abertos;
Não é compatível com dispositivos do padrão b.
IEEE 802.11g
Possui taxas de transmissão de 54 Mbps;
Opera em 2,4 GHz;
É o padrão mais utilizado atualmente.
30
IEEE 802.11n
É o padrão mais recente disponível no mercado;
Opera em 2,4 ou 5 GHz;
Possui taxas de transmissão de 65 até 300 Mbps.
IEEE 802.16ª
Criado em 2003;
Popularmente conhecido como Wi-Max;
Voltado para aplicações de longa distância;
Alcance de até 50 Km;
Possui taxas de transmissão de 280 Mbps.
5.7.2 Elementos de Hardware
Como todo tipo de redes, as redes Wi-Fi possuem hardwares específicos para
realizar a transmissão de dados. A seguir, são apresentados na tabela 2 os principais
elementos que compõe uma rede desse tipo. É importante salientar que nem toda rede
necessita de todos os componentes descritos abaixo, sendo possível estruturar redes a
partir da combinação de alguns deles, dependendo apenas do tipo de rede que se quer
obter.
Tabela 2 - Principais hardwares de uma rede Wi-Fi.
PC Card
Usado somente em Notebooks;
Serve para conectar o Notebook à rede Wi-Fi;
Possui antena interna embutida.
Placas PCI
Usadas somente em Desktops;
Servem para conectar os Desktops à rede Wi-Fi;
Possuem antena externa conectada à saída da placa.
Adaptadores USB Podem ser utilizados em Notebooks e em Desktops;
Servem para conectar ambos à rede Wi-Fi;
31
Possuem antena interna embutida.
Pontos de Acesso
Concentram todo o tráfego da rede, além das conexões
oriundas dos clientes;
Possuem um identificador para a rede chamado de SSID;
Funcionam como interface entre a rede cabeada e a rede
Wi-Fi por possuírem porta para conectores RJ45, que são
os conectores utilizados em redes cabeadas;
Possuem antena interna embutida;
Suportam a conexão de antena externa na maioria dos
casos.
Gateways
Conectam um pequeno número de dispositivo wireless à
Internet ou a outra rede;
Possuem porta WAN para conexão com a Internet e
várias portas LAN para conexão com dispositivos que
utilizam a rede cabeada.
Antenas
Podem ser conectadas a pontos de acesso ou a
máquinas clientes para aumentar o ganho do sinal e
assim melhorar a transmissão de dados;
Podem ser direcionais (irradiam o sinal em uma direção
específica) ou omni-direcionais (irradiam o sinal em todas
as direções)
5.7.3 Tipos de Rede Wi-Fi
Existem dois principais tipos de rede Wi-Fi: redes Indoor e Outdoor:
Redes Indoor: é o tipo de rede onde o sinal é transmitido em um ambiente fechado,
normalmente com a presença de vários obstáculos, por exemplo, em um escritório;
32
Redes Outdoor: é o tipo de rede onde o sinal PE transmitido ao ar livre, ou livre de
obstáculos, por exemplo , uma comunicação entre dois prédios, onde as antenas
ficam nos topos de cada uma das construções.
Uma rede Indoor ainda pode ter duas estruturas diferentes:
AD-HOC: não existem Pontos de Conexão (AP) e a comunicação é feita
diretamente entre os clientes. Dessa forma quanto mais clientes estiverem na rede,
pior será a performace da mesma quando a transmissão dos dados;
Infra-Estruturada: Necessita de um Ponto de Acesso (AP) através do qual toda
comunicação entre clientes é realizada. O AP centraliza toda e qualquer
transferência de dados da rede.
6 ESPECIFICAÇÕES
6.1 Especificações do Sistema
Nessa seção é apresenta, em detalhes, todas as especificações e estrutura do
sistema e posteriormente do software propostos.
6.1.1 O Modelo Utilizado
Inicialmente é apresentada planta do cômodo tomado como modelo para projeto
de todo o sistema de automação proposto – figura 8. Todas as variáveis a serem
controladas e utilizadas para o controle foram pensadas com base nesta planta.
33
Figura 8 - Planta do cômodo utilizado como modelo.
Ao lado direito da planta encontra-se um legenda de símbolos com a
representação de dos sensores e atuadores utilizado para o projeto do sistema. A
planta, à esquerda indica onde cada sensor e atuador foram posicionados, bem como a
posição das portas, janelas e persiana.
6.1.2 Representação Esquemática do Sistema
A figura 9 apresenta um diagrama com o funcionamento do sistema como um
todo, com seus fluxos e rotinas.
34
Figure 9 - Representação do funcionamento do Sistema.
Logo após o início do programa, a rotina de conexão é iniciada. Essa rotina
aguarda até que um cliente, nesse caso a central de comunicação, esteja apto para
conectar-se. Assim que o processo de conexão é realizado o software começa a
aguardar pela ocorrência de eventos, que são ações a serem executadas pelo usuário,
tais como alteração de uma intensidade luminosa ou acionamento de uma lâmpada,
por exemplo. Caso nenhum evento ocorra, o software passa a verificar se existem
informações recém-enviadas, vindas do sistema e, se essas informações estiverem
disponíveis, utiliza-as para atualizar as telas mostradas ao usuário. Caso ocorra um
evento, imediatamente o programa executa as rotinas responsáveis por montar e
enviar o frame com o comando determinado pelo usuário para a central de
35
comunicação. Ao receber o frame, a Central de comunicação avalia se há alguma
alteração no sistema – verificando se o status de algum dos sensores foi alterado ou
não. Caso nenhuma alteração seja identificada, o frame Wi-Fi recebido é convertido
para um frame ZigBee e enviado para ao hardware do sistema, onde ficam ligados os
módulos ZigBee. Caso o atuador que executará o comando esteja ligado diretamente
no módulo ZigBee, o próprio módulo executará a ação, do contrário o comando será
interpretado pelo micro-controlador e executado pelo mesmo.
Caso a central de comunicação identifique alterações no sistema, um frame
ZigBee será recebido pela mesma, contendo a alteração em questão. Tal frame ZigBee
será convertido para um frame Wi-Fi e enviado pela central para o software – interface
com o usuário – que, por sua vez retornará para a rotina de verificação de ocorrência
de eventos, em caso negativo, a informação recebida será interpretada e usada para,
como descrito anteriormente, atualizar as telas apresentadas ao usuário.
6.2 Especificações do Software
Pelo fato do trabalho proposto ter como intuito desenvolver uma interface simples
e prática, que permita o controle de variáveis físicas de forma rápida e tendo como
base a Proposta do Projeto, deve-se garantir o funcionamento do software de acordo
com certas especificações que assegurem a eficiência e confiabilidade na execução
dos comandos executados pelo usuário.
O primeiro ponto é a forma de criar uma conexão e manter a comunicação com o
restante do sistema, ou seja, como o programa irá enviar todos os comandos que o
morador irá executar. Nesse sentido optou-se pela utilização de rotinas nativas da
linguagem C#, que permitem a criação de uma conexão confiável a partir da
especificação de parâmetros simples, que são apresentados na seção
“Desenvolvimento do Projeto”.
Quanto à tecnologia de transmissão optou-se pelo padrão Wi-Fi, devido à sua
larga utilização atualmente nas mais diversas aplicações, pelo fato da maioria dos
36
dispositivos móveis já possuírem embutido o hardware para esse padrão e pelos
custos associados serem menores.
Outro ponto importante é possibilitar o funcionamento de mais de uma rotina em
paralelo, para que o programa seja capaz de enviar e receber informações e, ao
mesmo tempo, processar os comandos executados pelo usuário. Para tal, foi utilizada
uma rotina, que também é nativa da linguagem C#, chamada BackGroundWorker,
apresentada na seção “Desenvolvimento do Projeto”. Tal rotina permite a criação de
diferentes objetos de forma que cada um execute diferentes tarefas que podem ser
executadas simultaneamente.
Por tratar-se de um software que tem como principal intuito permitir que o usuário
opere certas variáveis físicas, não há uma ordem certa ou definida de quais ações
serão executadas. Assim, todo o projeto do sistema foi desenvolvido de forma a ser
guiado a eventos. Toda vez que o usuário executa uma ação ou comando o programa
segue um caminho diferente, de acordo com o que foi executado.
Após determinados os posicionamentos apresentados na figura 8, foi possível
estabelecer quais seriam as variáveis utilizadas para enviar comandos ao sistema, a
fim de executar o que é determinado pelo usuário, e informar o mesmo do status atual
do sistema.
A tabela 3 apresenta uma relação de tais variáveis juntamente com o tipo de cada
uma e com sua referente descrição.
Tabela 3 - Relação das variáveis do software.
Variável Tipo da
Variável Descrição
LA1 Byte Armazena a intensidade luminosa atual do
quarto.
LA2 Byte Armazena a intensidade luminosa atual do
banheiro.
37
PS1 Byte
Determina se há ou não presença do quarto
(armazena 1 se houver presença e 0 se não
houver).
PS2 Byte
Determina se há ou não presença do banheiro
(armazena 1 se houver presença e 0 se não
houver).
LSE Byte Armazena o valor da luminosidade externa.
TS1 Float Armazena o valor da temperatura do quarto.
TSE Float Armazena o valor da temperatura externa.
TA1 Byte
Determina se o sistema de ventilação será
acionado ou não (armazena 1 para acionar e 0
para não acionar).
SpS1 Byte Armazena o status da porta do quarto (1 para
fechado e 0 para aberto).
SpS2 Byte Armazena o status da porta do banheiro (1
para fechado e 0 para aberto).
SjS1 Byte Armazena o status da janela do quarto (1 para
fechado e 0 para aberto)
SpeS1 Byte
Armazena o status da persiana, instalada na
janela do quarto (3 = totalmente aberta; 2 =
25% fechada; 1 = 75% fechada e 0 =
totalmente fechada).
Temp_padrao Inteiro
Armazena a temperatura padrão determinada
pelo usuário. Esse valor é comparado com os
valores medidos para determinar se há ou não
a necessidade de ligar o sistema de ventilação.
ReadByte Inteiro
Serve para determinar se há alguma
informação chegando do restante do sistema e
portanto, se há necessidade de atualizar as
informações de status do sistema que são
38
mostradas ao usuário.
Frame ByteArray
Trata-se do vetor que é enviado ao sistema
com os valores das variáveis escolhidas pelo
usuário.
frame_comparacao ByteArray
Armazena o último valor de “frame” para fins
de comparação. Caso “frame” e
“frame_comparacao” sejam diferentes, o
usuário já realizou uma nova alteração das
variáveis e há necessidade de um novo envio
do “frame” para atualizar o sistema.
Buffer ByteArray
Armazena as informações de status que o
sistema envia ao software para atualizar as
informações que são mostradas ao usuário.
Ck Byte
Armazena a somatória de todos os valores entre a posição 3 e a posição 16 do vetor
“frame”. Essa variável é utilizada para gerar o CheckSun do vetor “frame”.
Soma_cs Byte
Armazena o valor da operação lógica “E” entre
o valor hexadecimal “0XFF” e a variável “ck”.
Essa variável é utilizada para gerar o
CheckSun do vetor “frame”.
A Inteiro Variável auxiliar utilizada para incrementar ou decrementar a posição da persiana.
Num Inteiro Utilizada para converter a temperatura do quarto lida no sistema
num1 Inteiro Utilizada para converter a temperatura externa lida no sistema.
6.2.1 As Classes
Essa seção apresenta as classes nativas da linguagem C# e que foram utilizadas
para desenvolver o software, além de explicar a função de cada uma.
39
Estas Classes são nativas da própria linguagem C# e estão presentes na
biblioteca utilizada pela mesma, a .NET Framework Class Library, citada anteriormente
na “Revisão Bibliográfica”.
As classes nativas utilizadas foram três: a “System.Net”,”BackgroundWorker” e
“System.Net.Sockets”.
A tabela 4 apresenta de forma detalhada tais classes e descreve qual a função e o
funcionamento de cada uma delas segundo (MICROSOFT, 2011).
Tabela 4 - Classes utilizadas no software e suas definições.
Classe Definições e Funcionamento
System. Net
Está Classe oferece suporte para a utilização da
maioria dos protocolos de comunicação utilizados
atualmente, inclusive o principal deles, o protocolo
TCP/IP. A Classe System.Net permite associar
endereços de IP ao programa e, dessa forma
estabelecer comunicação com outros endereços IP
externos – de outros computadores. Assim, torna-
se possível especificar com qual IP deseja-se
estabelecer e manter uma conexão.
System.Net.Sockets
Além de poder especificar um endereço de IP para
estabelecimento de uma conexão, deve haver um
meio através do qual a conexão possa ser
estabelecida. Esse meio é através da criação de
um Socket. A Classe System.Net.Sockets tem
como função permitir que um Socket seja criado
com os parâmetros estabelecidos através do auxílio
da Classe System.Net, tal como endereço de IP.
BackgroundWorker A criação de objetos dessa classe permite executar
diversas rotinas simultaneamente, de forma que a
40
execução de uma não interfira no desempenho das
demais. No programa proposto permite executar o
processo de envio de escuta de dados juntamente
com a execução dos comandos executados pelo
usuário.
6.2.2 Os Métodos
Aqui são descritos os métodos presentes no programa e suas respectivas
funções.
O programa contém quatro Métodos dos quais dois foram desenvolvidos e outros
dois são nativos da linguagem. Os métodos nativos são “RunWorkerAsync” e
“ReportProgress”, já os desenvolvidos foram “Constroi_frame” e
“AtualizarPortas_Janelas”.
O funcionamento de cada Método é explicado através da tabela 5, abaixo:
Tabela 5 - Métodos utilizados no software e suas definições.
Métodos Definições e Funcionamento
RunWorkerAsync
Este Método envia uma requisição para iniciar uma
operação assincronamente, ou seja, em paralelo a
algo que já está sendo realizado pelo programa. No
caso do software proposto isso se faz necessário,
pois todo o processo de conexão com um cliente, a
escuta por informações que chegam da rede e o
envio de comandos ao sistema, devem rodar em
paralelo com as ações executadas pelo usuário, do
contrário, cada vez que o sistema precisasse receber
uma informação, por exemplo, a tela de comando iria
travar, não permitindo que o usuário executasse
41
nenhum tipo de ação enquanto o envio do fosse
concluído. A chamado desse método ativa um
evento chamado “DoWork”. Todo o código inserido
dentro do escopo desse evento será executado
paralelamente ao resto do programa, permitindo que
mais de uma ação seja gerenciada e realizada ao
mesmo tempo, evitando travamentos. Dentro do
Evento DoWork está todo código responsável por
realizar a conexão assim que o programa é aberto, o
código que fica monitorando a rede a fim de verificar
se há informações chegando e que devem ser lidas e
interpretadas para serem apresentadas ao usuário e,
por fim, o código responsável por enviar o vetor
“frame” cada vez que um novo comando for
executado. O outro processo a ser executado é a
utilização do software pelo usuário e que roda
normalmente em primeiro plano.
ReportProgress
Como existem dois processos principais acontecendo
em paralelo, um naturalmente – que é a utilização do
software pelo usuário – e outro dentro do Evento
DoWork – que é a conexão, escuta e envio de novas
informações, há, em certos momentos, a
necessidade de permitir que o processo que roda em
segundo plano, através do evento DoWork, seja
capaz de retornar valores ao processo que roda em
primeiro plano. Por exemplo, toda vez que o código
inserido no DoWork identificar a chegada de uma
nova informação, é necessário repassar a mesma
para o processo em primeiro plano, a fim de que o
usuário possa visualizar na tela o status atual do
sistema. A função do Método ReportProgress é
42
justamente permitir a troca de informações entre o
processo realizado em segundo plano e o de primeiro
plano. Toda vez que o mesmo é chamado, o vetor
“buffer”, que é recebido através do código inserido no
evento DoWork será repassado ao primeiro plano,
interpretado e as informações atualizadas serão
apresentadas na tela para o usuário. Esse método dá
início a um evento chamado
“worker_ProgressChanged", onde está inserido o
código que decompõe o vetor “buffer”, permitindo que
ao usuário visualizar o status do sistema.
Constroi_frame
Trata-se do Método responsável por montar o vetor
“frame” assim que qualquer comando ou alteração for
realizada, por exemplo, a alteração da intensidade
luminosa do quarto. O vetor montado por esse
método é enviado ao sistema através do código
inserido dentro do evento DoWork – é importante
ressaltar que o envio só é possível devido a utilização
das classes System..Net e System.Net.Sockets,
previamente apresentadas e que, em conjunto,
agrupam as informações necessárias e estabelecem
a conexão via TCP/IP com o restante do sistema.
AtualizarPortas_Janelas
Após a identificação da chegada de novas
informações – armazenadas no vetor “buffer” – o
Método “AtualizarPortas_Janelas” trabalha somente
as variáveis relativas ao status das portas, janelas e
da persiana do quarto, a fim de determinar se as
mesmas se encontram abertas, fechadas ou em que
posição específica, no caso da persiana
43
6.2.3 Os Eventos
Como descrito anteriormente, C# é uma linguagem guiada a eventos, ou seja,
ações tomadas pelo usuário, como o ato de clicar em um botão ou mover uma barra de
rolagem, dão início à execução de uma determinada ação por parte do programa.
Dessa forma, maior parte das estruturas desenvolvidas no software proposto são
eventos. Os mesmos são apresentados abaixo na tabela 6, junto com uma breve
descrição da ação tomada por cada um deles. Todos eles estão associados a
componentes desenhados na tela do programa, como botões, barras de rolagem,
caixas de textos, etc. Elementos esses que serão apresentados na seção
“Desenvolvimento do Software”, juntamente com o layout do software.
Evento Definições e funcionamento
btnBanheiro_Click Habilita a tela para controle da iluminação do
banheiro.
btnQuarto_Click Habilita a tela para controle da iluminação do
quarto.
scrollIlBanheiro_Scroll Exibe em um label o valor da intensidade
luminosa do banheiro, escolhida pelo usuário.
scrollIlQuarto_Scroll Exibe em um label o valor da intensidade
luminosa do quarto, escolhida pelo usuário.
chkIlQuarto_CheckedChanged Habilita o controle de iluminação do quarto a
partir de um valor escolhido pelo usuário.
btnQuartoTemp_Click Habilita a tela para controle da temperatura do
quarto.
btn1_Click Exibe a tela de controle de iluminações.
btn2_Click Exibe a tela de controle de temperaturas.
btn3_Click Exibe a tela de controle de Portas, Janelas e
da Persiana.
btn4_Click Exibe a tela de visualização de status do
sistema.
44
scrollTemp1_Scroll
Exibe em um label o valor da temperatura do
quarto, escolhida pelo usuário.
chkIlBanheiro_CheckedChanged Habilita o controle de iluminação do banheiro
a partir de um valor escolhido pelo usuário.
radioAutoTemp1_CheckedChanged
Habilita o controle de temperatura do quarto a
partir de um valor de temperatura padrão
escolhido pelo usuário.
btnAbrirPers_Click Incrementa a abertura a persiana.
btnFecharPers_Click Incremente o fechamento da persiana.
chkPQuarto_CheckedChanged Habilita o controle de iluminação do quarto a
partir do monitoramento de presença.
scrollIlQuarto1_Scroll
Exibe em um label o valor da intensidade
luminosa do quarto, escolhida pelo usuário
quando o controle é feito com base no
monitoramento de presença.
scrollIlBanheiro1_Scroll
Exibe em um label o valor da intensidade
luminosa do banheiro, escolhida pelo usuário
quando o controle é feito com base no
monitoramento de presença.
chkPBanheiro_CheckedChanged Habilita o controle de iluminação do banheiro
a partir do monitoramento de presença.
radioManuTemp1_CheckedChanged
Habilita o controle de temperatura do quarto a
partir de um valor qualquer escolhido pelo
usuário.
button1_Click Aplica no sistema a temperatura padrão,
escolhida pelo usuário.
button2_Click Aplica no sistema a temperatura escolhida
pelo usuário
button3_Click Aplica no sistema intensidade luminosa do
banheiro, escolhida pelo usuário.
45
button4_Click
Aplica no sistema intensidade luminosa do
banheiro, escolhida pelo usuário, baseado no
monitoramento de presença
button5_Click Aplica no sistema intensidade luminosa do
quarto, escolhida pelo usuário
button6_Click
Aplica no sistema intensidade luminosa do
banheiro, escolhida pelo usuário, baseado no
monitoramento de presença
btnClose_Click Fecha a tela de controles do Sistema.
6.2.4 Os Vetores “Frame” e “Buffer”
Outro importante ponto a ser especificado é a construção dos vetores “frame” e
“buffer”, variáveis que enviam ao sistema as alterações realizadas pelo usuário e
recebem o status atual do sistema, respectivamente. Ambos os vetores possuem a
mesma estrutura e foram separados em duas variáveis a fim de facilitar o controle dos
dados enviados e recebidos, bem com a confiabilidade das informações enviadas e
recebidas.
Ao observar a tabela 6, que apresenta em detalhes o vetor, é possível notar que
existem duas posições reservadas para a variável “TS1” e duas posições para a
variável “TSE”. Tratam-se exatamente das variáveis que armazenam as temperaturas
lidas pelos sensores de temperatura do quarto e externo, respectivamente. Isso se
deve ao fato de não ser possível enviar essas leituras do sistema para o software
utilizando-se apenas um byte para cada uma das variáveis. Ao receber o vetor, os dois
bytes de cada variável são convertidos e por fim são armazenados em apenas uma
variável cada, chamadas pelo mesmo nome: TS1 e TSE.
46
Tabela 6 - Vetor "frame" e "buffer".
Posição Nome
Header
0 Start
1 Length
2 Tipo
Data Frame
3 LA1
4 LA2
5 PS1
6 PS2
7 LSE
8 TS1
9
10 TSE
11
12 TA1
13 SpS1
14 SpS2
15 SjS1
16 SpeS1
Checksum 17 Cksum
7 DESENVOLVIMENTO DO PROJETO
A aplicação proposta nesse trabalho foi toda desenvolvida a partir da linguagem
C#. A opção por essa linguagem deve-se a dois fatores principais: primeiramente a
característica de ser uma linguagem guiada a eventos, o que é indispensável do ponto
de vista de que todas as ações do programa devem ser tomadas com base nas ações
do usuário, seguindo a ordem que o mesmo executa as tarefas. O fato de ser guiada a
eventos permite determinar a execução da ação de programa mais adequada para
cada decisão tomada pelo usuário do sistema. Em segundo lugar, o fato da linguagem
ter sido desenvolvida visando seu aproveitamento tanto para aplicações em Desktops e
Notebooks quanto para aplicações na Internet, permitiu a utilização de recursos como
as Classes System.Net e System.Net.Socktes, que facilitaram o desenvolvimento
47
desta aplicação do ponto de vista da criação e execução da conexão com o restante do
sistema.
O software foi elaborado com o auxílio de um compilador chamado “Microsoft
Visual Studio 2010”, utilizado para desenvolver aplicações com as linguagens membro
da plataforma .NET, neste caso a linguagem C#.
A figura 10 apresenta a interface de desenvolvimento utilizada:
Figura 10 - Ambiente de desenvolvimento utilizado - Microsoft Visual Studio 2010.
A partir do Visual Studio o programa proposto foi desenvolvido com duas telas
principais: a tela inicial - através do qual o usuário pode escolher por qual tela de
controle irá iniciar o programa – e a tela de controle, através da qual o usuário pode
acessar todas as opções de controle do sistema. A figura 11 e 12 apresentam,
respectivamente, a tela inicial e a de controle.
48
Figura 11 - Tela inicial do Programa.
Deve-se observar que é possível, através da tela inicial – figura 11 - optar pela
variável que deseja-s controlar inicialmente, ou até mesmo por visualizar o status atual
do sistema. Outra opção presente nessa tela é o botão “Fechar”, caso o usuário queira
sair do programa.
Já a figura 12 mostra a tela de controle da iluminação, supondo que o usuário
tenha escolhido está tela inicialmente. Nota-se também que existem duas colunas com
opções, uma a esquerda da tela do software, com as opções de navegação entre as
variáveis que podem ser controladas. Com essa opção o usuário pode estar em
qualquer tela e ir diretamente para qualquer outra, sem a necessidade de retornar a
tela inicial. Do lado direito encontram-se as opções próprias do controle de cada uma
das variáveis, no caso da iluminação, mostrada na figura 9, pode optar entre a exibição
dos controles para a iluminação do quarto ou do banheiro.
Outra característica é que a opção da iluminação, à esquerda, aparece
desativada. Uma vez que o usuário já se encontra na tela de controle dessa variável,
49
não há necessidade de que o botão para essa opção esteja ativado. Essa metida foi
tomada com o intuito de tornar o sistema mais intuitivo durante a operação. Há também
uma botão chamado “Menu Principal”, que permite que o usuário retorne à tela inicial.
Figura 12 - Tela de Controle, supondo que o usuário tenha optado inicialmente por controlar a Iluminação.
7.1 As Telas do Software
Nessa seção são apresentadas em detalhes as telas que compõe o programa
proposto. Como a tela inicial já foi apresentada na figura 11, serão apresentadas
somente as telas de controle.
Inicialmente, na figura 13, observa-se a tela de controle de iluminação. O usuário
deve optar por controlar as luzes do quarto ou do banheiro, escolhendo entre os dois
botões localizados no lado esquerdo da tela.
50
Figura 13 - Controle da iluminação.
Após a opção, o usuário pode realizar o controle de duas formas: simplesmente
acionando as luzes - através da opção “Acionar Luzes” – e escolhendo a intensidade
desejada através da respectiva barra de rolagem, ou escolhendo o monitoramento de
presença. Com essa opção o usuário apenas determina a intensidade desejada e o
programa aciona as luzes somente se houver alguém no cômodo em questão,
contribuindo, dessa forma, para a economia de energia.
Já a tela de controle de temperatura, apresentada na figura 14, torna possível o
controle apenas da temperatura do quarto.
51
Figura 14 – Controle de temperatura.
Há um campo chamado “Temperatura Ambiente” que mostra a temperatura
medida pelo sensor do quarto. Abaixo, é possível executar o controle também de duas
formas: a partir do estabelecimento de uma temperatura padrão – caso a temperatura
ambiente ultrapasse a temperatura padrão, o sistema de ventilação será acionado - ou
simplesmente determinando a intensidade da temperatura desejada, em uma escala de
0 à 100%.
Já a tela de mostrada na figura 15 exibe os status de cada porta, janela e
persiana. Para operar a persiana foram estabelecidas quatro posições: Totalmente
aberta, 75% aberta, 25% aberta ou Totalmente fechada.
52
Figura 15 - Portas, Janelas e Persiana.
Por fim é apresentada a tela de status geral, onde é possível visualizar a situação
atual de todas as variáveis – figura 16.
53
Figura 16 - Status Geral do Sistema.
7.2 O Início da Conexão
O software inicia o processo de conexão no momento em que uma opção é
escolhida pelo usuário na tela inicial, independente de qual for essa opção. Abaixo, é
apresentada a figura 17, que representa esse processo – o código referente ao mesmo
pode ser encontrado no “Apêndice A - Código Fonte da Aplicação”. É importante
lembrar que a conexão ocorre em segundo plano e é inicializada a partir do momento
em que o Método “RunWorkerAsync” é chamado. Essa chamada inicia o evento
“DoWork”, que é onde se encontra todo o código responsável por parametrizar e iniciar
a conexão.
Esse trecho de código apresenta a classe “Controles” e o evento “DoWork”.
Inicialmente são declarados dois objetos do tipo “Socket”: “connection” e
“newclient”, que serão utilizados para estabelecer a conexão com o sistema, via Wi-Fi.
54
Dentro da Classe “Controles” são feitas as declarações as declarações e
inicializações dos objetos “bw” e “worker”, membros de uma classe chamada
“Backgroundworker”. São exatamente os objetos dessa classe que permitem a
chamada de rotinas que devem ser executadas em segundo plano, como as rotinas de
conexão e envio de informações. São ativados os recursos do Método
“ReportProgress” que, como visto anteriormente, irá transferir informações das rotinas
executadas em segundo plano, nesse caso as informações com o status do sistema,
para o programa que estará rodando normalmente em primeiro plano. Em seguida, o
objeto “bw” é utilizado para inicializar o evento “DoWork” e o método “ReportProgress”.
Por fim é chamado o método “RunWorkerAsync”, através do qual o evento “DoWork” é
iniciado.
Ao entrar no evento “DoWork” pode-se visualizar os recursos das bibliotecas
“System.Net” e “System.Net.Socktes”. É declarado um objeto do tipo “IPEndPoint”, que
recebe os parâmetros necessários para estabelecer uma conexão - a porta que deseja-
se utilizar e o endereço de IP do cliente, que nesse caso é o endereço do IP do
Notebook onde estará ligado o hardware ZigBee, responsável pela comunicação com o
restante do sistema – referente à (ESTEVES, 2011).
Na sequência o objeto “connection” utiliza um método chamado “Bind” que serve
para associar o objeto “ipe” com a conexão que será estabelecida. É uma forma indicar
que a conexão deve ser estabelecida com os parâmetros de IP e porta determinados e.
por fim, o mesmo objeto usa o método “listen” para iniciar a escuta por conexões – o
parâmetro (número inteiro) dado ao método “listen” determina quantas conexões
poderão ser gerenciadas aos mesmo tempo. A partir desse momento o programa
aguardará até que uma conexão seja recebida. Devido ao fato desse código ter sido
construído dentro do evento “DoWork” o usuário pode continuar a operar normalmente
o software, sem travamentos, pois os dois processos operam paralelamente.
Assim que uma conexão for detectada, o outro objeto do tipo “Socket” é utilizado
para aceitar a nova conexão. Desse momento em diante o sistema está apto a
55
comunicar-se com o novo cliente e uma mensagem avisando o usuário sobre a
conexão bem sucedida irá aparecer na tela.
Figura 17 - Início do processo de conexão.
Dando sequência a execução do programa, o mesmo irá entrar em um laço
infinito – “while(true)” – que tem como objetivo tornar constante a escuta por
informações que chegam do sistema. O objeto “newclient” utilizará um método
chamado “Available” para determinar se há ou não alguma informação a ser lida na
porta. Em caso afirmativo esse método retorna o valor “1”, do contrário retorna “0”. O
56
valor retornado é utilizado para determinar, através de im “if”, se a infomação pode ser
lida. Sempre que houver infomação disponível, o objeto “newclient” utilizará o método
“Receive” para armazenar na variável “buffer” o vetor de dados que chegou e em
“ReadByte” a quatidade de dados a ser lido. Como “ReadByte” é uma variável inteira o
que será armazenado nela é, na verdade, o comprimento do vetor que acabou de ser
recebido e poderá ser usado como parâmetro para outra função posteriormente.
Na sequência existe um outro “if”, responsável por determinar se o método
“ReportProgress” será chamado ou não. Caso “ReadByte” seja diferente de zero, o que
significa que houve leitura de informações que chegaram na porta, então
ReportProgress” é chamado para desmembrar o vetor “buffer” e exibir o status do
sistema para o usuário.
Após a chamada ou não de “ReportProgress”, é forçada uma saída do laço para
verificar se há necessidade ou não de envio de informações ao sistema. Isso é feito
através da comparação da posição 16, que é o CheckSun dos vetores “frame” e
“frame_comparacao”. Como “frame_comparacao” recebe o último valor de “frame” que
foi enviado ao sistema, caso os CheckSuns sejam iguais não há necessidade de um
envio de informações, do contrário o envio é realizado através do uso do método
“Send” pelo objeto “newclient”. Após o envio, a variável “frame_comparacao” recebe o
valor de “frame” que acabou de ser enviado. Essa medida foi tomada com o objetivo
de evitar o tráfego desnecessário de dados pela rede e consequêntemente evitar o
processamento desnecessário das mesmas.
Determinado se há ou não necessidade de enviar informações, é utilizado um
“goto”, para induzir o programa a voltar ao laço “while(true)” e recomeçar o processo,
que será executado continuamente.
A qualquer momento, caso ocorra algum erro de conexão, uma mensagem será
exibida indicando o erro. Esta mensagem está dentro na exceção “catch”, no final do
código apresentado.
57
7.3 A Manipulação das Variáveis “frame” e ”buffer”
Após citar os métodos e códigos que executam a conexão, o envio e o
recebimento de informações, também se faz necessário conhecer com são
manipuladas as variáveis “frame” e “buffer” – a construção de “frame”, que é o vetor
enviado ao sistema com os comandos do usuário, e a desmontagem e interpretação de
“buffer”, que é o vetor que recebe o status do sistema.
O vetor “buffer” é manipulado pela chamada do método “ReportProgress”, que dá
início ao evento “worker_ProgressChanged”. Neste evento está todo o código que
atribui a cada variável apresentada na tabela 3 uma posição correspondente do vetor,
referente à mesma variável enviada pelo sistema, menos para as variáveis de status de
portas, janelas e da persiana, que são atribuídas pela função
“AtualizarPortas_Janelas”. Esse código também pode ser visualizado no “Apêndice A –
Código Fonte da Aplicação”.
Já a variável “frame” possui um processo de construção cuja representação na
forma de diagrama é apresentada abaixo, na figura 18.
58
Figure 18 - Processo de construção das variáveis "frame" e "buffer".
Inicialmente são determinados os valores das três primeiras posições do vetor –
também chamado de cabeçalho - que são, respectivamente, o byte de start, que
identifica o início do vetor, o byte de comprimento, que determina o número de
posições do vetor e, por fim, o byte que determina o tipo de vetor – o vetor pode ser de
dois tipos diferentes, de envio ou confirmação de envio, este último com a função de
confirmar o envio de informações ao sistema. Apesar do sistema não ter sido projeto
com essa funcionalidade de confirmação de envio, o vetor “frame” já foi planejado
dessa forma pensando em melhorias futuras.
Deve-se notar que os três valores atribuídos, assim como todos os demais valores
do vetor, são do tipo byte. Isso se deve ao fato das bibliotecas utilizadas (“System.Net”
e “System.Net.Sockets” aceitarem apenas o envio de bytes).
59
Após a determinar os valores do cabeçalho do vetor, o programa entra em um
laço do tipo “for” (for (int i = 3; i <= 16; i++)) que atribui a variável que foi alterada no
sistema à sua respectiva posição no vetor “frame”, conforme já apresentado na tabela
6. As demais posições são preenchidas com o valor hexadecimal “0XFF”. Esse
processo é realizado para que o programa que receberá o vetor “frame” – no caso o
programa desenvolvido por (ESTEVES, 2011), que complementa o software aqui
proposto - seja capaz de identificar que variável sofreu alteração e atualize apenas
essa variável no sistema. Esse método de atualização foi pensado para evitar o tráfego
excessivo de informações pela rede do sistema e melhorar o tempo de processamento
do mesmo. É importante observar também, que a cada passo do laço “for” a variável
“ck” é incrementada com o valor da posição atual do vetor, de forma que ao final do
laço, essa variável contenha a soma da posição 3 à posição 16 do vetor “frame”.
Quando o laço é finalizado, a variável inteira “soma” recebe o resultado da
operação lógica “E” entre o valor hexadecimal “0XFF” e a variável “ck”. Logo após a
última posição do vetor – posição 17 – recebe o valor da diferença entre o valor
hexadecimal “0XFF” e da variável “soma_cs”, já convertido para byte, uma vez que o
vetor é um vetor de bytes. Esse processo nada mais é do que a montagem do
“CkeckSun” do vetor “frame” que, como apresentado anteriormente, serve para
determinar se houve alguma alteração feita pelo usuário e, consequêntemente, a
necessidade de atualizar o sistema com o envio desse vetor.
8 RESULTADOS E DISCUSSÕES
8.1 Testes da Interface
Inicialmente foram realizados os testes para verificar a funcionalidade da interface
desenvolvida, a fim de verificar se todas as telas e elementos, tais como barras de
rolagem, botões, recursos de habilitação e desabilitação de elementos gráficos, caixas
de seleção, dentre outros, estavam funcionando corretamente e de acordo com o
previsto.
60
Durante o teste foram testados diversos e diferentes caminhos para percorrer
todas as telas do software proposto, bem como a manipulação de todos os elementos
gráficos inseridos em cada janela. Baseado nesses testes pode-se notar que a
presença de várias janelas no programa, mais especificamente uma para cada variável
(temperatura, luminosidade, Portas/Janelas/Persiana e status do sistema), além da tela
inicial - totalizando 5 janelas – dificultava a navegação e tornava a interface menos
intuitiva do que havia-se pensado inicialmente. Baseados nesses testes notou-se que
era mais simples, tanto do ponto de vista da programação quanto da utilização pelo
usuário final, reduzir o número de telas, compilando as informações e opções de
controle em apenas uma tela, para que o programa final tivesse apenas duas telas, a
inicial e a de controle.
O meio encontrado para realizar essa redução foi uma opção gráfica do “Visual
Studio” chamada “Group Box”. Trata-se de uma espécie de caixa onde podem ser
inseridos diversos outros recursos, como os botões, barras de rolagem, caixas de
seleção, etc. Dessa forma, quando o usuário optava por controlar uma determinada
variável era possível habilitar somente a “Group Box” que continha os elementos de
controle desse variável e desabilitar as demais.
Após essas alterações pode-se observar que a navegação tornou-se mais
simples, intuitiva, além de contribuir com o tempo de processamento de software que,
ao invés de gerenciar cinco telas, passou a gerenciar apenas duas.
Todas as telas de controle são apresentadas no Apêndice B – “Interface Gráfica”.
8.2 Testes Iniciais da Comunicação Wi-Fi
Alguns testes foram feitos entre o programa aqui desenvolvido e o software
desenvolvido por (ESTEVES, 2011). Primeiro foi formada uma rede Ad-Hoc entre o
computador com esta aplicação e outro notebook o qual continha o lado do servidor da
comunicação via socket, além de possui toda IHM para variação das grandezas
automatizadas.
61
A conexão foi realizada com sucesso e a aplicação seguiu sem problemas para o
laço que verificaria constantemente se existem dados no buffer de saída. O próximo
passo foi o envio de uma mensagem de um computador a outro. A palavra escolhida,
“TCC”, foi enviada com sucesso e ao recebê-la na outra ponta a mesma foi exibida
num dos campos de dados da IHM desenvolvida. O caminho contrário também foi
testado, e a aplicação aqui desenvolvida recebeu o dado com sucesso e o exibiu na
tela de registro de logs.
Para que fosse simulada uma ação em paralelo à rotina de recebimento de dados
para assegurar que as aplicações iriam rodar simultaneamente, sem prejuízo do resto
do programa, uma rotina foi inserida com um laço do tipo for para que a cada iteração
um número fosse escrito na tela. A aplicação rodou em paralelo e não prejudicou o
recebimento de nenhum dado que vinha do Wi-fi. Entretanto, o programa ficou travado
por um breve momento até que o laço fizesse todas as iterações necessárias.
Caso fosse necessária a presença de duas tarefas que demandam muito tempo
de execução neste programa, o caso ideal seria isolar a ação que executa e atualiza o
software aqui proposto das duas tarefas que demandam tempo e travariam a
manipulação da interface. Isso seria possível com a implementação de mais um objeto
da classe BackgroundWorker para rodas a outra aplicação, assim a ação principal só
se preocuparia com o programa (interface com o usuário). Como só a rotina de
verificação constante do buffer de entrada do Wi-fi – variável “buffer” - que trava o
programa, todas as outras ações do programa rodaram no mesmo plano da interface –
programa principal - sem prejuízo de desempenho.
8.3 Testes de Monitoramento
Após a realização das melhorias realizadas no software a partir dos testes da
interface e de comprovar o funcionamento adequado da conexão Wi-Fi, foram
realizados os testes para verificar se o programa era capaz de enviar e receber
informações do sistema desenvolvido em (ESTEVES, 2011). As seguintes variáveis
foram testadas: a temperatura e consequênte acionamento do sistema de ventilação, a
62
abertura e fechamento da persiana, os sensores de temperatura e os sensores
indutivos.
A seguir são apresentados os resultados e comentários de cada um dos testes
realizados.
8.3.1 Temperatura e Sistema de Ventilação
Para realização desses testes, o sistema de temperatura adotado foi um
ventilador, devido à impossibilidade financeira de aquisição de um sistema de
resfriamento mais completo.
Em primeiro lugar foi realizada a leitura da temperatura através do sensor ligado
diretamente no sistema desenvolvido por (ESTEVES, 2011). Essa informação foi
enviada ao programa aqui proposto e recebida através do vetor “buffer” e mostrada ao
usuário na interface através do código contido no evento “worker_ProgressChanged”,
que é disparado pelo método “ReportProgress”. A temperatura lida foi apresentada na
interface da forma esperada.
Também foi realizado o teste para acionar o dispositivo de ventilação. Devido à
limitação técnica apresentada pelo ventilador, foi estabelecido o seguinte parâmetro:
valores de temperatura acima de um valor pré-estabelecido foram considerados como
indicação para ligar o ventilador e valores abaixo desse foram considerados como
indicação para desligar o mesmo. O teste foi realizado levando em conta os dois tipos
de acionamento possíveis para temperatura: acionamento com base na temperatura
padrão – neste caso o valor da temperatura lida era comparado com o valor padrão
escolhida pelo usuário, se a temperatura padrão fosse menor que a lida o ventilador
era acionado, do contrário não; e com base no monitoramento de presença – neste
caso, valores maiores ou iguais a 50%, em uma escala de 0% a 100%, faziam com que
a ventilação fosse acionada. Todos os testes obtiveram os resultados esperados,
acionando o ventilador de acordo com as situações descritas logo acima.
63
8.3.2 Persiana
O teste da persiana foi realizado através da do parâmetro escolhido pelo usuário,
que podia escolher entre quatro estados: totalmente aberto, 25% aberto, 75% aberto ou
totalmente fechado.
O sistema respondeu satisfatoriamente ao envio do comando do software aqui
proposto, porém o motor escolhido para realizar o deslocamento da persiana mostrou-
se adequada até certo ponto, uma vez que, a partir da metade da subida da persiana, o
mesmo apresentou dificuldades para continuar o processo de subida. De acordo com
os testes realizados esse problema pode ser resolvido facilmente através da troca do
motor atual por um com um torque maior.
8.3.3 Os sensores indutivos
Tais sensores foram acoplados as portas e janelas para indicar se as mesmas
encontravam-se abertas ou fechadas. O programa proposto recebia um valor booleano
para indicar esse status: “0” para janela ou porta aberta e “1” para janela ou porta
fechada. A partir desse valor, uma lógica construída a partir de um “if”, contida do
método “AtualizarPortas_Janelas”, atribuía ao campo adequado os textos “ABERTO”
ou “FECHADO”.
Todos os valores recebidos foram interpretados de forma correta e indicados
corretamente no software.
8.3.4 Outros Testes Gerais com Integração do Sistema
Devido à dificuldade de alinhamento de cronogramas deste projeto com os
(ESTEVES, 2011) e (ROSA, 2011), não foi possível a conclusão dos testes envolvendo
todas as variáveis monitoradas e controladas. Os testes descritos acima foram
realizados e obtiveram sucesso em sua execução.
64
9 CONCLUSÕES
A proposta inicial era o desenvolvimento de um sistema intuitivo e de fácil
utilização por parte do usuário final, um sistema que permitisse a qualquer pessoa
controlar de forma rápida e prática as variáveis propostas nesse trabalho. No que diz
respeito à esse ponto, pode-se afirmar que a interface desenvolvida atendeu
satisfatoriamente à essa proposta, uma vez que apenas as informações finais do status
do sistema são apresentadas ao usuário e de forma clara e objetiva. Quanto ao
comandos, todo layout mostrou-se simples e ao mesmo tempo eficiente. Um ponto de
melhoria identificado seria o melhor aproveitamento do espaço das telas do software,
visando o aumento do tamanho dos recursos gráficos, facilitando a utilização por parte
do usuário final, principalmente se o software for utilizado a partir de um dispositivo
móvel, como celulares do tipo “Smarth Phone” ou “Tablets”, conforme as intenções
futuras desse projeto.
Do ponto de vista da linguagem escolhida para o desenvolvimento, a mesma
mostrou-se totalmente adequada à aplicação, uma vez que contém nativamente
recursos para desenvolvimento de aplicações em rede, tais como as bibliotecas
“System.Net” e “System.Net.Sockets”, além da biblioteca “BackGroundWorker”, que
permite o desenvolvimento de aplicações com diferentes rotinas rodando em paralelo.
As bibliotecas “System.Net” e “System.Net.Sockets” mostraram-se adequadas
pois os recursos disponibilizados pelas mesmas supriram a necessidade do
estabelecimento de uma conexão confiável e estável a partir de uma fácil
parametrização. Por outro lado, um ponto a ser melhorado é a questão da segurança
ao se transmitir dados usando os recursos disponibilizados por essas duas classes. As
mesmas não garantem que as informações enviadas não sejam desviadas ou até
mesmo lidas e alteradas por qualquer tipo de agente malicioso. No caso do sistema de
automação proposto pelo presente trabalho, juntamente com (ESTEVES, 2011) e
(ROSA, 2011), essa situação não é adequada e precisa ser melhorada, visando a
segurança e confiabilidade do sistema.
65
Já a biblioteca “BackGroundWorker”, apresentou resultados satisfatórios durante
todos os testes de conexão, permitindo que uma rotina de teste fosse realizada
paralelamente com o processo de conexão. Durante os testes de monitoramento, a
conexão, envio e recebimento de informações foi mantida em funcionamento durante
todo o tempo em que o usuário utilizou o programa, não havendo nenhum travamento
ou atraso.
Do ponto de vista comparativo com os sistemas apresentados como Estado da
Arte, o software proposto aqui, juntamente com o sistema proposto pela integração
desse trabalho com (ESTEVES, 2011) e (ROSA, 2011), mostra-se mais interessante
em diversos aspectos. Primeiramente a velocidade com que o programa proposto pode
trabalhar é maior do que a dos sistemas citados, uma vez que utiliza-se da tecnologia
Wi-Fi, que pode alcançar 54 Mbps, ao contrário da tecnologia X10, que trabalha com
transmissões de 60 bits por segundo, limitada pela freqüência da rede elétrica.
Também é importante ressaltar que a rede elétrica é muito mais suscetível à ruídos que
podem prejudicar ou até mesmo comprometer a transmissão de dados via tecnologia
X10 em comparação com o Wi-Fi. Além do mais, a interface intuitiva e de boa
visualização, enquanto os demais sistema, com exceção do 3NYX, possuem telas de
difícil visualização devido ao tamanho reduzido.
Baseado nessas observações e conclusões pode-se afirmar que o sistema
desenvolvido permite melhorias, como as citadas, porém atende de forma satisfatória a
proposta inicial, sendo capaz de monitorar e alterar variáveis em uma residência de
forma rápida e prática, facilitando a rotina do usuário e contribuindo para a economia
de recursos energéticos.
10 REFERÊNCIAS BILIOGRÁFICAS
ANGEL, P. M. Introducción a la Domótica. Escuela Brasileño-Argentina de Informática.
EBAI, 1993.
66
EURO X10 Distribuidor Europeu de produtos para Domótica. Disponível em <
http://www.eurox10.com/Content/X10Information.htm >. Acessado em 13 de dezembro
de 2010.
ACTIVE HOME. Disponível em < http://www.activehometechnologies.com >. Acessado
em 19 de Abril de 2010.
CARDIO: Casa Inteligentes. Disponível em < http://www.cardio.pt >. Acessado em 23
de Abril de 2010.
MORDOMUS: Intelligent House Management. Disponível em <
http://www.mordomus.com >. Acessado em 22 de Abril de 2010.
3NYX Home Automation. Disponível em < http://www.3nyx.com >. Acessado em 13 de
Dezembro de 2010.
SCHILDT, H. C++, Fundamentos e Prática. 1ª Ed. Alta Books, Rio de Janeiro, Brasil,
2004.
MIZHARI, V. V. Treinamento em Linguagem C++ - Módulos 1 e 2. 2ª Ed. Prentice Hall,
Brasil, 2006.
DEITEL, P.; DEITEL, H. C# 2010 for Programmers – 4ª Ed. Pearson Education, EUA,
2011
FOXALL, J. Visual C# 2008 - 1ª Ed. Pearson Education, EUA, 2008
MAKOFSKE, D. B. ; DONAHOO, M. J. ; CALVERT, K. L. TCP/IP Sockets in C# -
Practical Guide for Programmers – 1ª Ed. Morgan Kaufmann. EUA, 2004.
FARIAS, P. C. B.. Treinamento Profissional em Redes Wireless – 1ª Ed. Digerati
Books, Brasil, 2006
MICROSOFT. Disponível em < http://msdn.microsoft.com/en-us/library/gg145045.aspx
>. Acessado em 4 de Abril de 2011.
67
ESTEVES, D. H. Central para Automação Residencial: Controle por dispositivo portátil
com rede de sensores e atuadores sem fio. 2011. Trabalho de graduação (Graduação
em Engenharia de Controle e Automação) – Universidade Estadual Paulista, Sorocaba,
2011.
ROSA, P. H. B. Central para automação residencial: Hardware de aquisição de dados e
comunicação com a central.2011. Trabalho de graduação (Graduação em Engenharia
de Controle e Automação) – Universidade Estadual Paulista, Sorocaba, 2011.
TORBENSEN, R. Ohas: Open Home Automation System. Dept. of Electronics Systens.
Aalborh University, Denmark. 2008.
NUNES, R. J. C. An Internet Application for Home Automation. IEEE. 2000.
HAN, J. User-Friendly Home Automation Based on 3D Virtual Word. Universitu of Seul.
2008.
GONZÁLEZ, V. M. Visir, A Simulation Software for Domotics Installations to Improve a
Laboratory Training
68
APÊNDICE A - CÓDIGO FONTE DA APLICAÇÃO
Encontra-se em arquivo separado na mídia entregue.
APÊNDICE B – INTERFACE GRÁFICA COMPLETA
Encontra-se em arquivo separado na mídia entregue.
