desenvolvimento de produto para automação residencial com sistema droidlar
DESCRIPTION
Neste trabalho é apresentada de criação dos protótipos funcionais de dois produtos, o SAR (Servidor de Automação Residencial) e Controlador, utilizados em conjunto com o sistema DroidLar em uma solução de automação residencial. São descritas as etapas de definição dos gabinetes, hardwares e firmwares além dos resultados obtidos em uma demonstração de ambiente real. Para projetos de freelancer e/ou duvidas sobre o trabalho, entre em contato comigo por email ([email protected])TRANSCRIPT
BRUNO RODRIGUES SILVA
DESENVOLVIMENTO DE PRODUTO PARA
AUTOMAÇÃO RESIDENCIAL COM SISTEMA DROIDLAR
FLORIANÓPOLIS, 2013
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE SANTA CATARINA
CAMPUS FLORIANÓPOLIS DEPARTAMENTO ACADÊMICO DE ELETRÔNICA
CURSO DE PÓS-GRADUAÇÃO LATO SENSU – ESPECIALIZAÇÃO EM DESENVOLVIMENTO DE PRODUTOS
ELETRÔNICOS
BRUNO RODRIGUES SILVA
DESENVOLVIMENTO DE PRODUTO PARA AUTOMAÇÃO RESIDENCIAL COM SISTEMA
DROIDLAR
Monografia submetida ao Instituto Federal de Educação, Ciência e Tecnologia de Santa Catarina, como parte dos requisitos de obtenção do título de Especialista em Desenvolvimento de Produtos Eletrônicos. Professor Orientador: Clóvis Antônio Petry, Dr. Eng.
FLORIANÓPOLIS, 2013
CDD 629.895 S586d Silva, Bruno Rodrigues Desenvolvimento de produto para automação residencial
com sistema DroidLar. [Monografia] / Bruno Rodrigues Silva; orientação de Clóvis Antônio Petry. – Florianópolis, 2013.
1 v.: il. Monografia de especialização (Desenvolvimento de
Produtos Eletrônicos) – Instituto Federal de Educação, Ciência e Tecnologia de Santa Catarina. Curso de Pós-graduação Lato Sensu em Desenvolvimento de Produtos Eletrônicos.
Inclui referências. 1. Automação residencial. 2. Sistema embarcado. 3.
Android. I. Petry, Clóvis Antônio. II. Título.
Sistema de Bibliotecas Integradas do IFSC Biblioteca Dr. Hercílio Luz – Campus Florianópolis Catalogado por: Edinei Antonio Moreno CRB 14/1065
DESENVOLVIMENTO DE PRODUTO PARA AUTOMAÇÃO RESIDENCIAL COM SISTEMA
DROIDLAR
BRUNO RODRIGUES SILVA
Este trabalho foi julgado adequado para obtenção do Título de Especialista em Desenvolvimento de Produtos Eletrônicos e aprovado na sua forma final pela banca examinadora do Curso de Pós-Graduação Lato Sensu – Especialização Em Desenvolvimento De Produtos Eletrônicos do Instituto Federal de Educação, Ciência e Tecnologia de Santa Catarina.
Florianópolis, 17 de dezembro de 2013. Banca Examinadora:
_________________________________ Clóvis Antônio Petry, Dr. Eng.
Orientador
_________________________________ Joel Lacerda, Dr.Eng.
_________________________________ Everton Luiz Ferret dos Santos, Me. Eng.
DEDICATÓRIA
Ao meu pai, Walter Zelindro da Silva Filho, que é minha maior referência de profissional e pessoa. Por seu inigualável
senso de responsabilidade, que moldaram o meu caráter, e sua incomparável dedicação em tornar meus sonhos realidade.
À minha mãe, Sandra Rodrigues da Silva, que é a melhor
mãe e a pessoa mais querida desse mundo. Por seu amor e constante preocupação com minha felicidade.
À minha irmã, Débora Rodrigues Silva dos Santos, que é a
minha melhor amiga. Por acreditar que tudo o que faço é incrível.
À minha esposa, Daniela Vargas de Oliveira Silva, que é o amor da minha vida. Pela paciência, compreensão e apoio
incondicional durante toda essa jornada.
AGRADECIMENTOS Principalmente ao meu pai, Walter Zelindro da Silva Filho,
que, novamente, investiu tempo e recurso em minha formação, possibilitando a realização desse trabalho.
Ao professor Clóvis Antônio Petry, pela orientação
prestada nos assuntos técnicos, pelo respeito recíproco para comigo e, principalmente, pela fundamental ajuda nos momentos
em que mais precisei.
“Se o dinheiro for a sua esperança de independência, você jamais a terá. A única segurança verdadeira consiste numa
reserva de sabedoria, de experiência e de competência.”
Henry Ford
RESUMO Desde os primeiros anos do século XXI, a automação
residencial vem deixando de ser futuro para tornar-se cada vez mais presente. Em 2011, José Roberto Muratori, diretor executivo da Aureside (Associação Brasileira de Automação Residencial), afirmou que o número de projetos em automação residencial cresceu em média 35% nos últimos anos, citando como os principais motivos: a redução do custo de projeto e o perfil das pessoas mais jovens já adeptas as tecnologias que compram imóveis atualmente. Nesta linha, está contido o DroidLar, um sistema de automação residencial que permite controlar diferentes equipamentos de uma residência utilizando celulares Android como interface de controle, desenvolvido e aplicado em ambiente acadêmico. Como forma de aproximar o sistema de laboratório ao usuário final, este trabalho apresenta o desenvolvimento dos produtos SAR e Controlador, elementos do sistema DroidLar, descrevendo as etapas de definição do gabinete, hardware e firmware dos produtos de modo que sejam implantados em um ambiente real, tornando o sistema mais próximo de uma solução destinada ao usuário final.
Palavras-Chave: Automação Residencial, Android, Sistema Embarcado, Hardware.
ABSTRACT Since the early years of this century, home automation is
leaving to be a future to be increasingly present. In 2011 , José Roberto Muratori , CEO of Aureside (Brazilian Association of Residential Automation), said the number of projects in home automation grew on average by 35% in recent years , citing as the main reasons : reduction of cost of design and the profile of younger's people and fans of technologies who buy real estate today. In this line is included the DroidLar, a home automation system that lets you control different devices of a residence using Android phones as control interface, developed and applied in academic environment. As a way of approaching the laboratory system to the end users, this work presents the development of the SAR and the Controller of DroidLar system, describing the steps of definition of the enclosure, hardware and firmware of the products so that they are deployed in a real environment, making the system closer to a solution for the end user.
Key-Words: Home Automation, Android, Embedded System, Hardware.
LISTA DE ILUSTRAÇÕES Figura 1 – Hardware Global Caché para Domótica .................... 24 Figura 2 – Hardware Loxone (Miniserver) .................................. 24 Figura 3 – Protótipo do controlador com kit Arduino .................. 25 Figura 4 – Infraestrutura de iluminação tradicional ..................... 29 Figura 5 – infraestrutura de iluminação automatizada ................ 30 Figura 6 – Módulo ZigBee ........................................................... 32 Figura 7 – Rede de dados ZigBee .............................................. 32 Figura 8 – OSI x CAN .................................................................. 33 Figura 9 – Cabo par trançado para barramento CAN ................. 34 Figura 10 – Interpretação de bit em um barramento CAN ......... 34 Figura 11 – Balanceamento da rede CAN .................................. 35 Figura 12 – CAN Frame tipo Standard ....................................... 36 Figura 13 – CAN Frame tipo Extended ....................................... 36 Figura 14 – Exemplo de hardware compatível com CAN ........... 37 Figura 15 – Arquitetura do sistema DroidLar .............................. 38 Figura 16 – Telas do software DroidLar ...................................... 39 Figura 17 – Encaminhamento de mensagens ao SAR............... 40 Figura 18 – Controlador de lâmpadas de Euzébio ..................... 41 Figura 19 – Mensagem padrão Cliente Android x SAR .............. 42 Figura 20 – Mensagem de autenticação Cliente x SAR ............. 42 Figura 21 – Visão geral infraestrutura com DroidLar .................. 45 Figura 22 – Modelos de gabinete para o SAR ............................ 47 Figura 23 – Gabinete do SAR ..................................................... 48 Figura 24 – Parte traseira do gabinete do SAR .......................... 48 Figura 25 – Dimensões da PCI do SAR ..................................... 49 Figura 26 – Arquitetura de hardware do SAR ............................. 50 Figura 27 – Conexões entre conectores CAN ............................ 54 Figura 28 – Padrão de conectividade CAN ................................. 55 Figura 29 – Estrutura do modelo de Interruptor .......................... 57 Figura 30 – Visão geral de instalação do Controlador ................ 57 Figura 31 – Dimensões do suporte plástico de fixação .............. 58 Figura 32 – Vista frontal da placa Interface ................................ 59 Figura 33 – Vista posterior da placa Interface ............................ 59 Figura 34 – Arquitetura da placa Controle .................................. 60 Figura 35 – Arquitetura da placa Analog .................................... 61 Figura 36 – Visão Geral do firmware do Controlador ................. 63 Figura 37 – Laço principal do firmware do Controlador .............. 64 Figura 38 – Visão Geral do firmware do SAR ............................. 66
Figura 39 – Máquina de estados Device .................................... 67 Figura 40 – Máquina de estados Server ..................................... 68 Figura 41 – Configuração do canal de depuração ...................... 72 Figura 42 – Exemplo de evento de mudança de estado ............ 72 Figura 43 – Exemplo de evento de comunicação ....................... 72 Figura 44 – Ambiente de teste do sistema DroidLar .................. 73 Figura 45 – Resultado da inicialização do SAR .......................... 74 Figura 46 – Envio de pacote ping ao SAR .................................. 75 Figura 47 – Resultado da inicialização do Controlador .............. 75 Figura 48 – Resultado da varredura periódica............................ 76 Figura 49 – Resultado de acender via Controlador .................... 77 Figura 50 – Corrente aplicada na lâmpada em 100% ................ 77 Figura 51 – Corrente aplicada na lâmpada ao acendê-la .......... 78 Figura 52 – Resultado de apagar via Controlador ...................... 79 Figura 53 – Corrente aplicada na lâmpada ao apagá-la ............ 79 Figura 54 – Tela de Configurações do DroidLar ......................... 80 Figura 55 – Resultado da autenticação admin ........................... 80 Figura 56 – Resultado da autenticação normal .......................... 81 Figura 57 – Resultado do erro na autenticação .......................... 81 Figura 58 – Resultado do controle de intensidade admin .......... 82 Figura 59 – Resultado do controle de intensidade normal ......... 83 Figura 60 – Resultado de erro no controle de intensidade ......... 83 Figura 61 – Formas de onda no controle de intensidade ........... 84 Figura 62 – Controle da intensidade via Controlador ................. 85 Figura 63 – Resultado da varredura via DroidLad admin ........... 86 Figura 64 – Resultado da varredura via DroidLad normal .......... 86 Figura 65 – Resultado de erro na varredura via DroidLad ......... 87 Figura 66 – Resultado de configurar nomes admin .................... 87 Figura 67 – Resultado de configurar nomes normal ................... 88 Figura 68 – Resultado de configurar varredura admin ............... 89 Figura 69 – Resultado de configurar varredura normal .............. 89
LISTA DE ABREVIATURAS AR Automação Residencial CAN Controller Area Networks CANH CAN High CANL CAN Low CS Chip Select EEPROM Memória Não Volátil Programável e Eletricamente
Apagável (Electrically-Erasable Programmable Read-Only Memory)
EMI Interferência Eletromagnética (Electromagnetic Interference)
HTTP Protocolo de Transferência de Hipertexto (Hypertext Transfer Protocol)
ICSP Programação Serial Em Circuito (In Circuit Serial Programming)
I2C Circuito Inter-integrado (Inter-Integrated Circuit) IP Protocolo de Internet (Internet Protocol) I/O Entrada/Saída (In/Out) MCLR Master Clear MCU Microcontrolador OSI Interconexão de Sistemas Abertos (Open
Systems Interconnection) PC Computador Pessoal (Personal Computer) PCI Placas de Circuito Impresso PGC Programming Clock PGD Programming Data RTCC Relógio e Calendário de Tempo Real (Real-Time
Clock and Calendar) SAR Servidor de Automação Residencial SCL Serial Clock SDA Serial Data UART Transmissor/Receptor Universal Assíncrono
(Universal Asynchronous Receiver/Transmitter) UTP Par Trançado sem Blindagem (Unshielded
Twisted Pair) TTL Lógica Transistor-Transistor (Transistor-
Transistor Logic) SPI Serial Peripheral Interface SCK Serial Clock
SDI Serial Data In SDO Serial Data Out
SUMÁRIO
1 INTRODUÇÃO ....................................................................... 23
1.1 PROBLEMATIZAÇÃO ....................................................... 25
1.1.1 Formulação do Problema ............................................. 25
1.1.2 Solução Proposta ......................................................... 26
1.2 OBJETIVOS ....................................................................... 27
1.2.1 Objetivo Geral ............................................................... 27
1.2.2 Objetivos Específicos ................................................... 27
1.3 METODOLOGIA ................................................................ 27
2 REVISÃO BIBLIOGRÁFICA .................................................. 29
2.1 AUTOMAÇÃO RESIDENCIAL .......................................... 29
2.2 PROTOCOLOS DE COMUNICAÇÃO .............................. 30
2.2.1 X-10 .............................................................................. 30
2.2.2 ZigBee ........................................................................... 31
2.2.3 CAN .............................................................................. 32
2.3 DROIDLAR ........................................................................ 38
2.3.1 Arquitetura .................................................................... 38
2.3.2 Cliente Android ............................................................. 39
2.3.3 SAR ............................................................................... 40
2.3.4 Controlador ................................................................... 41
2.3.5 Protocolo Cliente Android x SAR ................................. 42
2.3.6 Protocolo SAR x Controlador ....................................... 43
2.3.7 DroidLar versão 1.0 ...................................................... 44
3 DESENVOLVIMENTO ........................................................... 45
3.1 VISÃO GERAL ................................................................... 45
3.2 GABINETE DO SAR .......................................................... 46
3.3 HARDWARE DO SAR ....................................................... 49
3.3.1 Conector de Gravação ................................................. 50
3.3.2 Botão Reset .................................................................. 51
3.3.3 LEDs de sinalização ..................................................... 51
3.3.4 Módulo Serial ................................................................ 51
3.3.5 Módulo RTCC ............................................................... 52
3.3.6 Módulo EEPROM ......................................................... 52
3.3.7 Módulo IP ...................................................................... 53
3.3.8 Módulo CAN ................................................................. 53
3.4 CONECTIVIDADE DA REDE CAN ................................... 55
3.5 GABINETE DO CONTROLADOR ..................................... 56
3.6 HARDWARE DO CONTROLADOR .................................. 58
3.6.1 Placa Interface .............................................................. 58
3.6.2 Placa Controle .............................................................. 59
3.6.3 Placa Analog ................................................................. 61
3.7 FIRMWARE DO CONTROLADOR ................................... 62
3.8 FIRMWARE DO SAR ........................................................ 65
4 RESULTADOS ....................................................................... 71
4.1 CANAL DE DEPURAÇÂO ................................................. 71
4.2 AMBIENTE DE TESTE ...................................................... 73
4.3 TESTES DE FUNCIONALIDADE ...................................... 73
4.3.1 Inicialização do SAR ..................................................... 74
4.3.2 Inicialização do Controlador ......................................... 75
4.3.3 Varredura Periódica ...................................................... 76
4.3.4 Acender Lâmpada via Controlador ............................... 77
4.3.5 Apagar Lâmpada via Controlador ................................ 78
4.3.6 Autenticação do Usuário .............................................. 80
4.3.7 Controle de Intensidade da Lâmpada .......................... 82
4.3.8 Requisição de Varredura via Cliente Android .............. 85
4.3.9 Configurar Nomes das Lâmpadas ................................ 87
4.3.10 Configurar Varredura Periódica .................................... 88
5 CONCLUSÃO ........................................................................ 90
5.1 TRABALHOS FUTUROS .................................................. 92
6 REFERÊNCIAS BIBLIOGRÁFICAS ..................................... 93
23
1 INTRODUÇÃO Toda a tarefa que deixa de ser realizada manualmente por
um usuário em uma residência, e passa a ser realizada de forma automática, faz parte do conceito de automatização residencial. A automação de uma residência visa, principalmente, proporcionar conforto, segurança e praticidade para as tarefas do dia a dia (AUTOMATIC HOUSE, 2013).
Desde os primeiros anos do século XXI, a automação residencial vem deixando de ser futuro para tornar-se cada vez mais presente. Em 2005, especialistas apontavam um crescimento em torno de 20% ao ano no setor (VEJA SP, 2005). Seis anos mais tarde, José Roberto Muratori, diretor executivo da Aureside (Associação Brasileira de Automação Residencial), afirmou que o número de projetos em automação residencial cresceu em média 35% ao ano, citando como principais motivos: a redução do custo de projeto de automação residencial, em torno de 50% mais barato, e o perfil das pessoas que compram imóveis atualmente, mais jovens e já adeptos as tecnologias (TERRA, 2012).
Pode-se citar como outro motivo desse aumento, a popularização dos smartphones e tablets que rodam sistemas operacionais, como Android e iOS, cada vez mais amigáveis, servindo como interface de automação residencial aos usuários. Além disso, tecnologias sem fio permitem que os equipamentos de automação residencial sejam instalados com menos adaptações do imóvel com custo e segurança semelhantes às soluções cabeadas (TECPAR, 2011).
Seguindo a tendência dos últimos anos, empresas como: IHC Tecnologies
1, Home Manager
2 e Loxone
3 comercializam
soluções de hardware e software para o controle de iluminação, equipamentos de áudio & vídeo, ar condicionado, cortinas e persianas motorizadas, sistema de alarmes, entre outros proporcionando praticidade, conforto, economia e segurança em uma residência. A Figura 1 apresenta algumas opções de
1 http://www.ihclub.com.br
2 http://homemanager.com.br
3 http://www.loxone.com
24
hardware fabricadas pela empresa Global Caché4, utilizados nas
soluções das empresas IHC Tecnologies e Home Manager. Esses dispositivos têm como principal função converter as informações enviadas pela rede IP (Internet Protocol – Protocolo de Internet), para comandos de controle (a) serial, (b) contato seco e/ou (c) infravermelho.
(a) .......................(b) ....................... (c)
Figura 1 – Hardware Global Caché para Domótica Fonte: (GLOBAL CACHÉ, 2013).
Por sua vez, a Loxone comercializa em sua solução de
automação residencial hardware produzido pela mesma. A Figura 2 apresenta o hardware mínimo necessário para o sistema, o Miniserver Loxone. O dispositivo possui uma conexão para rede IP, onde recebe os comandos do usuário, e conta com entradas analógicas e digitais e mais saídas também analógicas e digitais para realizar o controle dos equipamentos de uma casa como, por exemplo, iluminação.
Figura 2 – Hardware Loxone (Miniserver)
Fonte: (LOXONE, 2013).
Além do hardware, as empresas disponibilizam aplicações
que podem ser instaladas em PC (Personal Computer – Computador Pessoal) ou smartphone, permitindo criar cenários, agendar tarefas e definir ações de acordo com os sensores e atuadores disponíveis no equipamento.
4 http://www.globalcache.com/
25
Os sistemas de automação residencial podem ser descentralizados, ou seja, a interface de controle do usuário envia comandos para os controladores de equipamentos residenciais diretamente, ou centralizados, ou seja, todo o controle da automação é realizado por um Servidor de Automação Residencial (SAR). Em geral, nesse segundo tipo, o usuário pode planejar um roteiro de tarefas automatizadas, criar diferentes perfis de usuários, realizar gravações de monitoramento, entre outras atividades sem necessidade de estar conectado diretamente ao sistema ou presente na residência.
Nessa mesma linha, o sistema DroidLar foi desenvolvido por Euzébio (2011) para ser uma opção de sistema de automação residencial centralizada, possibilitando o controle de equipamentos domésticos e eletroeletrônicos de uma residência, utilizando como interface de controle o celular com sistema operacional Android. Em seu trabalho, foram utilizados kits Arduino para prototipagem dos controladores de iluminação, Figura 3, e um computador de propósito geral para atuar como servidor de automação residencial.
Figura 3 – Protótipo do controlador com kit Arduino
Fonte: (EUZÉBIO, 2011).
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do Problema
Na época, os protótipos de hardwares desenvolvidos em
laboratório atenderam aos objetivos de validação do sistema
26
DroidLar, sendo citado por Euzébio (2011, p. 54) como “o ponto de partida para a criação de um sistema de automação residencial tão sofisticado quanto os presentes no mercado”, porém foram criados sem a perspectiva de utilização por um usuário final, devido a inviabilidade de implantação em ambientes reais, limitando-se ao uso em experimentos didáticos e em laboratório.
Pensando em um ambiente real, por exemplo, uma casa, o sistema servidor do DroidLar necessitaria ser instalado no PC do usuário, que por sua vez, necessitaria permanecer ligado constantemente para que os agendamentos e os perfis cadastrados fossem acionados conforme programado, acarretando em um consumo elevado e desnecessário de energia. Além disso, no caso de notebook, o usuário perderia a mobilidade do equipamento, pois o sistema precisa manter-se conectado aos controladores para realizar as tarefas agendadas.
Com foco no mesmo ambiente, o controlador de iluminação, prototipado com Arduino e matriz de contatos, encontra-se incompleto para ser aplicado em uma residência, pois necessita de um circuito adicional para realizar o controle de lâmpadas de uma casa.
1.1.2 Solução Proposta
Como forma de agregar valor a solução proposta, este
trabalho está focado na criação do hardware e firmware do controlador de iluminação e do SAR de modo que sejam implantados em um ambiente real, tornando a solução mais próxima do usuário final.
A solução proposta pelo DroidLar é composta por três elementos: cliente Android, controlador de iluminação e servidor de automação residencial. Este trabalho foca apenas no desenvolvimento dos dois últimos, de modo que seja utilizado o mesmo cliente Android já desenvolvido anteriormente.
Não faz parte do escopo do trabalho utilizar os mesmos circuitos prototipados por Euzébio (2011), tornando o desenvolvimento livre para ser implementado de acordo com o levantamento dos requisitos do sistema, a fim de tornar os dispositivos compatíveis com o Cliente Android.
27
1.2 OBJETIVOS
1.2.1 Objetivo Geral
O objetivo geral deste trabalho é desenvolver os produtos
de controle de iluminação e do servidor de automação residencial para que sejam utilizados em conjunto com o sistema DroidLar em uma solução de automação residencial.
1.2.2 Objetivos Específicos
Os objetivos específicos deste trabalho são: Levantar os requisitos de desenvolvimento do
hardware do servidor de automação residencial e do controlador de iluminação;
Definir os gabinetes dos produtos; Desenvolver o hardware do servidor de automação
residencial e do controlador de iluminação; Desenvolver os firmwares; Testar os dispositivos desenvolvidos; e Documentar os resultados obtidos nos testes.
1.3 METODOLOGIA
Foram considerados quatro etapas a fim de executar este
trabalho, sendo elas: estudo, desenvolvimento, teste e documentação.
Na etapa de estudo, foi realizado um levantamento bibliográfico com o objetivo de acumular informações suficientes para desenvolver os hardwares e firmwares do controlador de iluminação e do servidor de automação residencial. Este levantamento bibliográfico foi baseado principalmente na documentação de Euzébio (2011), além de livros e artigos sobre as tecnologias envolvidas.
Na etapa de desenvolvimento, foram especificados os gabinetes e desenvolvidas as arquiteturas de hardware e
28
firmware dos produtos. A arquitetura de hardware levou em conta principalmente os requisitos de comunicação entre o SAR, o cliente Android e controlador de iluminação. A arquitetura de firmware levou em conta principalmente os protocolos de comunicação entre os dispositivos. Foram criados os circuitos esquemáticos e os layouts das placas de circuito impresso (PCI), sendo confeccionados industrialmente a partir da geração dos arquivos Gerber, e os firmwares desenvolvidos em C.
Na etapa de teste, os dispositivos desenvolvidos na etapa anterior foram testados em um ambiente controlado simulando uma residência, tendo como objetivo realizar os mesmos testes de funcionalidades, com o cliente Android, realizadas por Euzébio (2011), porém em ambiente mais próximo do real.
A etapa de documentação foi realizada ao longo de todo trabalho, procurando-se registrar a execução das etapas descritas anteriormente para elaboração do produto proposto neste TCC. As informações levantadas na revisão bibliográfica estão registradas no Capítulo 2, enquanto que as informações relativas ao desenvolvimento do projeto estão no Capítulo 3.
29
2 REVISÃO BIBLIOGRÁFICA
2.1 AUTOMAÇÃO RESIDENCIAL
Pode-se definir automação residencial, ou Domótica, como
o conjunto de tecnologias que permitem automatizar uma série de tarefas realizadas em um imóvel (PRUDENTE, 2011). Bolzani (2004) complementa que “tudo pode ser resumido em uma só palavra: conforto”. De forma pragmática, além do conforto proporcionado pela praticidade e conveniência de automatizar persianas, por exemplo, podem ser citados, dentre outros benefícios, a segurança e a economia, como sistemas de vigilância eletrônica e controle de iluminação, respectivamente (AURESIDE, 2013).
Para automatizar uma casa é necessária uma infraestrutura diferente da tradicional. Sabe-se que quanto antes for percebida essa necessidade (ainda na fase do projeto), mais barato tornar-se-á a automação da residência (AURESIDE, 2013).
A Figura 4 mostra um diagrama da infraestrutura de iluminação tradicional de uma residência, onde o controle da iluminação é feita apenas pelo usuário através do interruptor. Ainda na imagem, pode-se entender como corrente alternada as linhas de neutro e fase da rede elétrica (PRUDENTE, 2011).
Figura 4 – Infraestrutura de iluminação tradicional
A Figura 5 apresenta um diagrama da infraestrutura da
iluminação de uma residência com um sistema de automação residencial, onde a ação do usuário no interruptor é interpretada por um hardware que realiza o controle da iluminação através da
30
sua eletrônica interna. Nesse caso, além da corrente alternada, tem-se mais a corrente contínua, linhas de terra e tensão contínua fornecida pela fonte de alimentação. A comunicação entre os controladores e o servidor é realizada através da rede de dados (PRUDENTE, 2011).
Figura 5 – infraestrutura de iluminação automatizada
Para que a comunicação entre os controladores e o
servidor seja estabelecida é necessário que ambos os dispositivos se comuniquem através de um protocolo comum entre eles.
2.2 PROTOCOLOS DE COMUNICAÇÃO
Existem diferentes protocolos de comunicação para
diferentes meios físicos de transmissão. No site da Aureside (2013), são listados alguns dos principais protocolos de comunicação utilizados em projetos de automação residencial.
2.2.1 X-10
O protocolo X-10 utiliza a fiação da rede elétrica como
meio de transmissão (powerline). Ele foi estabelecido em 1978 pela Sears Home Control System e pela Radio Shack Plug and Power System, sendo adotado por outras empresas como a
31
General Electric, Philips, RCA e Leviton. O protocolo é difundido principalmente nos Estados Unidos, tendo como principais vantagens o baixo custo e a simplicidade de gestão do sistema (PRUDENTE, 2011).
O sistema X-10 é formado por um dispositivo que envia comandos do tipo turn on, turn off e dim para pequenos módulos lógicos conectados à rede elétrica. Cada módulo é identificado por um endereço único na rede, restringida em até 256 dispositivos por rede (BOLZANI, 2004).
A taxa de transmissão é bem limitada, chegando no máximo a 60 bits por segundo (bps). Prudente (2011) alerta que “a rede elétrica, por sua vez, pode ocasionar algum comportamento errádico dos componentes, seja por duplicidade da fase, falta de energia ou descarga eletromagnética”. Esse protocolo deve ser utilizado apenas em operações que não representem um risco significativo em caso de falhas (BOLZANI, 2004).
2.2.2 ZigBee
O ZigBee utiliza os meios físicos de transmissão
especificados pelo padrão IEEE802.15.4 (IEEE, 2006). As principais características deste padrão são transmissão em ambiente sem fio, baixo custo e baixo consumo de energia. O ZigBee possui uma baixa taxa de transmissão, máximo 250 Kbps, se comparado a tecnologias, como Bluetooth (BOLZANI, 2004).
O alcance do ZigBee pode chegar, em média, a 50 metros, podendo ser estendido de acordo com à topologia da rede adotada. Na rede ZigBee deve haver um coordenador, elemento que gerencia a rede, enquanto que os outros membros da rede podem atuar como roteadores, podendo encaminhar mensagens para outros elementos da rede, ou pontos finais, apenas enviam e recebem mensagens (EUZÉBIO, 2011).
Bolzani (2004) cita que “devido ao baixo consumo, os módulos ZigBee têm uma duração estimada de funcionamento entre seis meses a dois anos, alimentados através de um par de pilhas AA”. A Figura 6 apresenta um exemplo de módulo ZigBee comercializado.
32
Figura 6 – Módulo ZigBee Fonte: XBeeStore, (2013).
Em seu trabalho, Euzébio (2011) utilizou dois módulos
ZigBee, um conectado no protótipo do controlador de iluminação e outro conectado ao computador, utilizando-o na aplicação do servidor. Desta forma, a rede de dados era proveniente do enlace entre os módulos ZigBee, como mostra a Figura 7.
Figura 7 – Rede de dados ZigBee
Fonte: Adaptado de Euzébio (2011).
2.2.3 CAN
O CAN (Controller Area Networks) é um protocolo de
comunicação síncrono desenvolvido nos anos oitenta pela Bosch, destinado principalmente para indústria automotiva. A Daimler Chrysler foi pioneira na utilização desse protocolo no controle de motores. Atualmente, além da indústria automobilística, o CAN é utilizado em diferentes segmentos, como: automação industrial, automação predial, equipamentos médicos, simuladores de voo, telescópios, entre outros (BOLZANI, 2004).
33
A arquitetura CAN especifica apenas duas camadas do modelo OSI
5 (Open Systems Interconnection – Interconexão de
Sistemas Abertos), camada física e de enlace representado na Figura 8 (BOLZANI, 2004). Guimarães e Saraiva (2002) apontam como principais características da arquitetura:
Multi-mestre: todos os elementos da rede podem tornar-se mestre ou escravos do barramento;
Multicast: quando um elemento da rede envia uma mensagem, todos os outros recebem.
CSMA/CD with NDA (Carrier Sense Multiple Access/ Collision Detection with Non-Destructive Arbitration): antes de enviarem uma mensagem, os elementos da rede verificam se existe alguma mensagem sendo enviada no barramento. Caso dois elementos enviem a mensagem simultaneamente, a mensagem de menor prioridade é interrompida para que seja transmitida a de maior prioridade.
NRZ (Non Return to Zero): cada bit transmitido representa efetivamente um dado.
A taxa de transmissão de dados pode chegar à 1 Mbps, dependendo do comprimento do barramento;
Robustez em detecção de falhas. Alta imunidade a EMI (Electromagnetic Interference–
Interferência Eletromagnética).
Figura 8 – OSI x CAN
5 Modelo conceitual de referência com padrões bem definidos
para construção de redes de dados.
34
2.2.3.1 Barramento CAN
Em geral, o barramento CAN é implantado a partir de um
par de fios de sinal, denominados CANH (CAN High) e CANL (CAN Low). Pode conter ainda mais um par de fios, VCC e GND, para alimentação dos dispositivos conectados ao barramento. A Figura 9 representa o cabo utilizado em um barramento CAN (GUIMARÃES e SARAIVA, 2002).
Figura 9 – Cabo par trançado para barramento CAN
Fonte: Adaptado de (2013)
No barramento CAN o bit é interpretado a partir da
diferença de potencial entre os fios de sinal, Figura 10. O bit 0 (zero) é denominado como “Dominante”, caracterizado pela diferença de tensão entre CANH e CANL, enquanto que o bit 1 (um) é denominado como “Recessivo”, caracterizado pela variação praticamente nula entre os fios (BOLZANI, 2004).
Figura 10 – Interpretação de bit em um barramento CAN
Fonte: Guimarães e Saraiva (2002)
35
Devem estar presentes nas extremidades do barramento CAN dois resistores de 120 Ω, um em cada ponta da rede, como mostra a Figura 11. Esse resistor é chamado de “Terminador CAN”. Eles servem para garantir a propagação dos sinais elétricos pelos fios da rede, ou seja, balancear a rede CAN. O balanceamento da rede gera uma resistência de 60 Ω entre os fios CANH e CANL. Na prática, aplica-se um Terminador CAN no primeiro elemento da rede e outro no último (GUIMARÃES e SARAIVA, 2002).
Figura 11 – Balanceamento da rede CAN
2.2.3.2 Frame CAN
O frame CAN pode ser de dois tipos: Standard (Figura 12)
ou Extended (Figura 13). Os campos do frame Standard podem ser descritos como:
SOF (Start Of Frame): Indica o início de um frame. Formado por 1 bit recessivo;
Identifier Standard: indica o identificador da mensagem. Formado por 11 bits;
RTR (Remote Transmission Request): Se dominante, o frame é um dado, se recessivo, o frame é uma requisição de envio de outro nó no barramento;
IDE (Identifier Extension): indica se a mensagem é do tipo Standard ou Extended. Formado por 1 bit;
R0: campo reservado 0. Formado por 1 bit; DLC (Data Length Code): indica o número de bytes no
campo Data. Formado por 4 bits; Data: indica o conteúdo do dado transmitido. Varia de 0
a 8 bytes;
36
CRC (Cyclic Redundancy Check): indica um valor calculado a partir dos bits do frame, usado na detecção de falhas na transmissão. Formado por 16 bits, 15 com o valor mais 1 delimitador recessivo;
ACK (Acknowledge): indica que a mensagem foi recebida com sucesso, preenchido pelo receptor do frame. Formado por 2 bits, 1 com o ACK mais 1 delimitador recessivo;
EOF (End Of Frame): indica fim do frame. Formado por 7 bits recessivos; e
IFS (Intermission Frame Space): indica que os dispositivos podem se preparar para o próximo frame. Formado por 3 bits recessivos.
Figura 12 – CAN Frame tipo Standard
Fonte: Adaptado de Guimarães e Saraiva (2002)
O frame Extended contém os mesmos campos do
Standard, porém após o bit RTR, é enviado um bit recessivo. Além disso, são acrescidos 3 campos que elevam o número de bits do campo Identifier:
SRR (Substitute Remote Request): Formado por 1 bit transmitido como recessivo para garantir a prioridade do frame Standard;
Identifier Extended: indica o restante dos bits do identificador da mensagem. Formado por 18 bits; e
R1: campo reservado 1. Formado por 1 bit. Ao todo, na versão Extended, o frame pode ter até 29 bits
no identificador da mensagem, possibilitando ter até 5,3 milhões de tipos de mensagens distintas.
Figura 13 – CAN Frame tipo Extended
Fonte: Adaptado de Guimarães e Saraiva (2002)
37
2.2.3.3 Hardware CAN
Em um projeto eletrônico de um dispositivo compatível
coma rede de dados CAN, deve-se considerar a utilização de um controlador e um transceptor CAN. Alguns microcontroladores já apresentam, em sua arquitetura interna, um módulo de hardware controlador CAN, necessitando apenas do transceptor (GUIMARÃES e SARAIVA, 2002).
A Figura 14 apresenta um exemplo de implementaçãodo barramento CAN com dois dispositivos. Em ambos, está presente o transceptor, porém o microcontrolador do “Dispositivo CAN 1” não possui o módulo controlador interno, necessitando de um CI (Circuito Integrado) externo, enquanto que o “Dispositivo CAN 2” já possui esse módulo de hardware interno. Entre outras empresas, a Microchip, fabricante de semicondutores, comercializa o MCP2515 e o MCP2551, exemplo de controlador e transceptor CAN, respectivamente (MICROCHIP, 2005).
Figura 14 – Exemplo de hardware compatível com CAN
Fonte: Adaptado de Microchip, (2005).
Devido as características apresentadas, o protocolo CAN
foi escolhido como a rede de dados a ser utilizada na
38
comunicação entre o hardware do servidor de automação residencial e o hardware do controlador de iluminação, propostos nesse projeto. Todos eles farão parte de um sistema maior, chamado de DroidLar.
2.3 DROIDLAR
O DroidLar é sistema de automação residencial, que
permite controlar diferentes equipamentos de uma residência utilizando celulares Android como interface de controle (EUZÉBIO, 2011).
2.3.1 Arquitetura
A arquitetura do sistema é do tipo centralizada,
representada na Figura 15, onde o Cliente Android estabelece uma conexão IP via rede sem fio (wifi) com o SAR (servidor de automação residencial). Este, por sua vez, se conecta ao Controlador através do barramento da rede de dados (EUZÉBIO, 2011).
Figura 15 – Arquitetura do sistema DroidLar
Fonte: Adaptado de Euzébio (2011).
39
A arquitetura prevê apenas um elemento cliente e um servidor, porém podem ser inseridos um ou mais controladores à rede de dados. Cada elemento presente na arquitetura tem sua função bem definida.
2.3.2 Cliente Android
O Cliente Android consiste em uma aplicação, disponível
para smartphone com sistema operacional Android embarcado. Quando conectado à rede IP, o software realizar a interface do usuário com os controladores presentes na rede de dados. A Figura 16.a apresenta a tela do software ao ser executado. Ao clicar no botão com o símbolo da lâmpada, o usuário é encaminhado para a tela de controle dos dispositivos, Figura 16.b (EUZÉBIO, 2011).
.......... ............... (a) Tela inicial ......................... (b) Controle dos dispositivos
Figura 16 – Telas do software DroidLar Fonte: Euzébio (2011).
A aplicação estabelece conexão com o servidor e envia
comandos utilizando o protocolo HTTP (Hypertext Transfer Protocol – Protocolo de Transferência de Hipertexto), com
40
informações de controle para o servidor. Essa interface permite abstrair do usuário os outros elementos do sistema, dando-lhe a noção de estar conectado diretamente ao equipamento da residência. O software não necessita estar constantemente ligado ao servidor, apenas quando for enviar algum comando (EUZÉBIO, 2011).
2.3.3 SAR
O SAR é um software, desenvolvido para rodar em um
computador de propósito geral, que deve permanecer constantemente em operação e conectado à rede IP.
Como mostra a Figura 17, sua principal função no sistema é interpretar os comandos do cliente, provenientes da rede IP, converte-las para o protocolo da rede de dados e enviá-las para os controladores dos equipamentos da casa. O caminho inverso também é verdade, pois os controladores respondem à solicitação do servidor, que por sua vez repassa-a ao cliente.
Figura 17 – Encaminhamento de mensagens ao SAR
Outra função do servidor é manter-se atualizado quanto
aos dispositivos da rede de dados. Para isso, de tempos em tempos, o servidor envia uma mensagem de varredura em broadcast
6 aos controladores. O controlador que a receber,
deverá responder ao servidor com uma mensagem contendo informações sobre o estado dos equipamentos controlados pelo
6 Termo utilizado em rede de computadores para mensagens
que são enviadas por um elemento da rede e recebidas por todos os outros conectados à mesma. Neste caso, ocorre a inundação da rede com a mesma informação (UNDER-LINUX.ORG, 2009).
41
mesmo. O período de varredura do servidor pode ser configurado pelo usuário através do cliente (EUZÉBIO, 2011).
Também é função do SAR autenticar o usuário no sistema. Apenas após estar autenticado, o servidor poderá aceitar comandos de controle do cliente e repassá-los adequadamente ao dispositivo específico (EUZÉBIO, 2011).
2.3.4 Controlador
O Controlador é formado por um microcontrolador (MCU) e
um conjunto de periféricos capazes de controlar os equipamentos de uma casa. A Figura 18, apresenta o protótipo desenvolvido por Euzébio (2011), construído com um kit Arduino
7
e uma matriz de contatos. Nele estão presentes três led e três botões, fazendo a representação de lâmpadas e interruptores de uma residência, respectivamente. Cada interruptor está diretamente relacionado a uma única lâmpada.
Figura 18 – Controlador de lâmpadas de Euzébio
Fonte: Euzébio (2011).
Ao receber uma mensagem de controle do servidor, o
MCU ajusta a intensidade da lâmpada, de acordo o parâmetro enviado. Além do sistema, o usuário pode gerenciar a intensidade pressionando o botão. O microcontrolador verifica se a lâmpada está apagada e, caso afirmativo, altera a intensidade
7 Plataforma de desenvolvimento de protótipos eletrônicos
(ARDUINO, 2013).
42
para o nível máximo (100%), caso contrário, altera para o nível mínimo (0%) (EUZÉBIO, 2011).
Qualquer alteração realizada na lâmpada, sendo proveniente do sistema ou do interruptor, deve ser armazenada pelo controlador. Desta forma, sempre que receber uma mensagem de varredura, o controlador deve enviar ao servidor uma mensagem atualizada da intensidade atual de cada uma das lâmpadas controladas pelo mesmo (EUZÉBIO, 2011).
2.3.5 Protocolo Cliente Android x SAR
As mensagens trocadas entre Cliente Android e SAR
apresentam os parâmetros representados na Figura 19, sendo: “Tipo”, valor numérico indicando a operação a ser realizada; “Endereço”, valor numérico referente ao controlador presente na rede de dados; “Conteúdo”, valor numérico ou conjunto de caracteres contendo o dado da operação; e “Opcional”, valor numérico com o identificador da lâmpada presente no controlador do determinado endereço (EUZÉBIO, 2011).
Figura 19 – Mensagem padrão Cliente Android x SAR
Fonte: Euzébio (2011).
A mensagem de autenticação difere-se das demais nos
campos endereço e conteúdo. Como mestra a Figura 20, em seu lugar, são enviados os parâmetros: “Usuário”, conjunto de caracteres formado pelo nome do usuário; e “Senha”, conjunto de caracteres formado pela senha do usuário (EUZÉBIO, 2011).
Figura 20 – Mensagem de autenticação Cliente x SAR
Fonte: Euzébio (2011).
Para toda mensagem enviada pelo cliente, o servidor deve
enviar uma resposta. Em alguns casos, o SAR envia apenas o valor numérico “0”, mensagem de confirmação indicando
43
sucesso, ou “1”, mensagem de erro, para a requisição solicitada. Dentre as mensagens trocadas entre Cliente Android e servidor, estão (EUZÉBIO, 2011):
Autenticação: o cliente envia o nome de usuário e senha e o servidor responde com uma confirmação ou erro;
Requisição de Dispositivo: o cliente solicita a lista completa de dispositivos e o servidor retorna com as informações dos estados das lâmpadas conectadas aos controladores;
Configurar Nomes: o cliente envia os nomes das lâmpadas dos controladores, alterados na interface pelo usuário, e o servidor retorna com uma confirmação ou erro;
Configurar Varredura Periódica: o cliente envia um valor com o intervalo de tempo, em minutos, de cada varredura e o servidor retorna com uma confirmação ou erro;
Varredura: o cliente envia uma mensagem de varredura imediata e o servidor retorna uma confirmação ou erro;
Controle de Intensidade: o cliente envia um valor com a intensidade desejada para uma determinada lâmpada e o servidor retorna com uma confirmação ou erro.
2.3.6 Protocolo SAR x Controlador
Sempre que um controlador é conectado à rede de dados,
ele envia ao SAR uma mensagem de “Informações Iniciais”. Nessa mensagem estão contidas informações sobre o endereço do controlador na rede, o estado e o identificador das lâmpadas que ele controla. Essa mensagem também é enviada como resposta a requisição de varredura proveniente do servidor (EUZÉBIO, 2011).
Quando o usuário altera o estado da lâmpada através do interruptor, além de armazenar a informação, o controlador envia uma mensagem de “Atualização de Estado” ao servidor, mantendo-o sempre atualizado de qualquer alteração realizada (EUZÉBIO, 2011).
44
2.3.7 DroidLar versão 1.0
Conceitualmente, o DroidLar permite o controle de
diferentes equipamentos de uma residência, mas em sua versão atual (1.0), o sistema suporta apenas o controle de lâmpadas. Porém, em seu trabalho, Euzébio (2011, p. 54) afirma que “Por se tratar de um projeto de código aberto e que utiliza tecnologias abertas, são inúmeras as possibilidades de adaptação, modificação e inserção de novos recursos”.
Neste projeto, o sistema permanecerá restrito ao controle de iluminação, pretendendo-se realizar modificações no Controlador e no SAR tornando-os aplicáveis em um ambiente residencial real.
45
3 DESENVOLVIMENTO Neste capítulo é apresentada a documentação do
desenvolvimento deste projeto. Inicialmente é demonstrada a visão geral do sistema, com o SAR e o Controlador representados em blocos. Em seguida, são apresentados os gabinetes e os hardwares propostos para dos blocos citados. Por fim, é apresentada a modelagem dos firmwares desenvolvidos para os dispositivos.
3.1 VISÃO GERAL
A Figura 21 ilustra um a visão geral da infraestrutura de
rede de uma residência em que o sistema DroidLar está presente. O DroidLar é formado por três módulos distintos: Cliente, SAR (servidor) e Controlador.
Figura 21 – Visão geral infraestrutura com DroidLar
46
O cliente atua como interface do usuário no sistema, via
celular com sistema operacional Android, sendo essa inalterada nesse trabalho. O Controlador controla a intensidade da lâmpada através de comandos do sistema ou pela ação do usuário no interruptor. O servidor age principalmente como uma ponte entre ambos os módulos anteriores.
Para o cliente estabelecer conexão com o servidor é necessário que ambos estejam conectados na mesma rede IP, sendo necessária uma rede sem fio para conexão do celular Android, enquanto que a conexão do SAR é via cabo UTP (Unshielded Twisted Pair – Par Trançado sem Blindagem) Cat5e
8.
O servidor e os controladores são alimentados pela fonte de forma direta e indireta, respectivamente. A fonte de alimentação é conectada ao SAR que alimenta os controladores com corrente contínua através do barramento CAN. O barramento CAN é formado por 4 fios: VCC (tensão positiva da fonte), GND (terra da fonte), CANH e CANL.
Nos controladores, são conectados um par de fios, neutro e fase, proveniente da rede elétrica. O neutro é conectado diretamente nas lâmpadas, enquanto que o acesso a fase é controlado pela eletrônica interna do controlador.
A internet não precisa estar presente, pois o sistema necessita apenas de uma rede local para operar. O PC e o notebook representam equipamentos eletrônicos que podem também estar conectados à rede IP da residência, sendo essa não restrita ao sistema DroidLar.
Estabelecido o modelo geral do sistema, partiu-se para a criação dos blocos SAR e Controlador.
3.2 GABINETE DO SAR
O processo de criação foi iniciado pela definição do
gabinete do SAR. Para determinar como será o gabinete utilizado no servidor, foram pesquisados alguns modelos de dispositivos
8 Categoria de cabo UTP recomendada pela norma EIA/TIA-
568-B.
47
que possuem ao menos um conector de rede IP e um conector de fonte de alimentação externa. Essa pesquisa teve como objetivo levantar características estéticas e ergonômicas do dispositivo. Foram desconsiderados na pesquisa os modelos de gabinetes para instalação em quadro de comando, como o exemplo na Figura 2. Também não foi considerada relevante a identificação do fabricante do dispositivo, e sim, apenas o design do produto comercial. A Figura 22, apresenta alguns modelos de gabinetes dentre os pesquisados, são eles: (a) um roteador, (b) um modem e (c) um servidor de automação residencial.
........(a) Roteador.......... (b) Modem.................. (c) Servidor
Figura 22 – Modelos de gabinete para o SAR
Entre as características ergonômicas apresentadas pelos
gabinetes observa-se que os equipamentos têm pouca interação com o usuário, estando restrito à conexão de cabos e sinalização de estados internos através de LEDs.
Quanto à estética, a característica mais forte é o formato retangular, comunicando ao usuário de que é um dispositivo eletrônico que pode ser instalado em um escritório, sala ou quarto.
Como forma de reduzir o custo do projeto, optou-se por utilizar o gabinete de outro produto, que apresentasse as características ergonômicas e estéticas citadas ou que necessitasse de poucas adaptações. Desta forma, o modelo escolhido foi o apresentado na Figura 23, adquirida a partir de doações de terceiros. O gabinete de formato retangular já apresenta o corte do conetor designado para a fonte de alimentação externa, na parte traseira, e o espaço reservado para aplicação das luzes indicativas, na parte frontal. Mesmo não sendo explicito no produto, o conector da rede IP, RJ45, é de fácil adaptação, se posicionado no local do conector DB25. Além
48
disso, o gabinete já apresenta dois conectores RJ12 agrupados, número e tipo de conector adequado para o barramento CAN.
..........(a) Parte frontal .............................. (b) Parte traseira
Figura 23 – Gabinete do SAR
Para facilitar a tarefa de manutenção ao produto, optou-se
por adicionar um conector DB9 para comunicação serial como meio de monitoramento de pacotes e estados de aplicação do firmware. Nesta mesma linha, pensou-se em um conector para gravação do firmware do dispositivo, tornando desnecessária a abertura do gabinete para realizar a sua atualização, e um botão de reset, para reiniciar o dispositivo manualmente. A Figura 24 apresenta o resultado das mudanças aplicadas na parte traseira do gabinete para atender aos requisitos levantados. Na parte frontal não houve alterações.
Figura 24 – Parte traseira do gabinete do SAR
A placa de circuito impresso do SAR foi desenvolvida para
encaixar-se no gabinete reaproveitado. A Figura 25 apresenta as cotas da placa, em milímetros, esboçando o posicionamento dos conectores definidos na parte traseira, e dos LEDs de sinalização com o usuário definidos na parte frontal.
49
Figura 25 – Dimensões da PCI do SAR
A partir dessas definições da PCI, deu-se início ao
desenvolvimento da mesma.
3.3 HARDWARE DO SAR
A Figura 26 ilustra a arquitetura de hardware do SAR. Sua
função é representar os módulos internos necessários para que o servidor embarcado seja empregado no sistema DroidLar, de modo que atenda aos requisitos de conectividade do sistema e de dimensionamento e interação definidos no gabinete.
50
Figura 26 – Arquitetura de hardware do SAR
O bloco regulador de tensão tem função de regular a
alimentação da fonte externa, fornecida pelo conector Jack P4, no nível de tensão de operação dos módulos e do outros elementos do hardware. O LED Power não é microcontrolado, servindo apenas para indicar que o servidor está energizado. Todos os outros elementos do hardware são controlados por um microcontrolador central.
3.3.1 Conector de Gravação
O conector de gravação possibilita que o firmware seja
gravado/atualizado sem necessidade de remover o MCU da placa de circuito impresso. Para isso, os pinos do conector são ligados diretamente ao microcontrolador, nos pinos ICSP (In Circuit Serial Programming – Programação Serial Em Circuito): PGD (Programming Data) e PGC (Programming Clock). Para
51
fazer a gravação do microcontrolador, é necessário um hardware externo específico para tal. O gravador varia de acordo com o fabricante do MCU.
3.3.2 Botão Reset
O botão Reset é utilizado para reinicializar o firmware
manualmente. Possibilita, por exemplo, que o usuário retorne às configurações iniciais do hardware caso seja identificado algum problema. O Reset está ligado diretamente ao pino MCLR (Master Clear) do MCU.
3.3.3 LEDs de sinalização
Os LEDs de sinalização servem para sinalizar ao usuário
algumas atividades da aplicação. Eles são ligados aos pinos com função de I/O (In/Out – Entrada/Saída) do microcontrolador. Fica a cargo do programador do firmware definir quando e como devem ser acionados na aplicação. Ao todo, foram utilizados no hardware sete LEDs, devido às especificações do gabinete.
3.3.4 Módulo Serial
O módulo serial atua como um canal de depuração do
firmware. Utilizando um software terminal, como Putty9, o usuário
pode monitorar os pacotes que são recebidos e enviados pelo servidor, tanto pela rede IP quanto pela rede CAN.
O módulo faz conexão com o microcontrolador, através dos pinos TX e RX da UART (Universal Asynchronous Receiver/Transmitter – Transmissor/Receptor Universal Assíncrono), e com o conector DB9 definido como a porta serial do SAR. Estão contidos no módulo:
9Software gratuito para emulação de terminal. Suporta
diferentes protocolos de comunicação, entre eles o RS-232 através da porta serial do computador (www.putty.org).
52
Um LED indicando que um dado está sendo enviado ao microcontrolador;
Um LED indicando que um dado está sendo enviado à porta serial;
Um conversor de nível de tensão TTL (Transistor-Transistor Logic – Lógica Transistor-Transistor) para protocolo de comunicação serial RS-232.
3.3.5 Módulo RTCC
O módulo RTCC (Real-Time Clockand Calendar – Relógio
e Calendário de Tempo Real) trabalha como um relógio externo do microcontrolador. Quando um pacote IP ou um frame CAN é recebido/enviado pelo servidor, o MCU consulta o relógio e registra o evento enviando os dados e o horário ocorrido para o canal de depuração.
A conexão entre o módulo e o microcontrolador é realizada através dos pinos de comunicação I2C (Inter-Integrated Circuit – Circuito Inter-integrado): SCL (Serial Clock) e SDA (Serial Data). Estão contidos no módulo:
Um CI com função RTCC; Uma bateria ligada ao RTCC, para manter a contagem
do tempo mesmo quando o SAR estiver desligado.
3.3.6 Módulo EEPROM
O módulo EEPROM (Electrically-Erasable Programmable
Read-Only Memory – Memória Não Volátil Programável e Eletricamente Apagável) é utilizado para armazenamento de informações de inicialização do sistema. Nele são armazenados dados como: versão do firmware, configurações da rede IP do servidor, entre outras.
A conexão entre o módulo e o microcontrolador é realizada através dos pinos de comunicação I2C: SCL e SDA.
53
3.3.7 Módulo IP
O módulo IP é responsável pela conexão do servidor à
rede IP, retirando do microcontrolador e, consequentemente, do firmware, toda complexidade envolvida nas camadas física, de enlace e rede do protocolo IP, permitindo-lhe trabalhar diretamente na camada de transporte com os protocolos TCP e UDP. Ao MCU, fica apenas a responsabilidade de comandar o módulo na abertura/fechamento de socket
10 e envio/recebimento
de pacotes. A conexão entre o módulo e a rede IP é realizada através
do conector RJ45, com transformador magnético embutido, enquanto que com o microcontrolador é realizada através dos pinos de comunicação SPI (Serial Peripheral Interface): SCK (Serial Clock), SDI (Serial Data In), SDO (Serial Data Out) e CS (Chip Select). Estão contidos no módulo:
Um LED indicando envio de pacote para rede IP; Um LED indicando recebimento de pacote da rede IP; Um LED indicando colisão de pacotes na rede IP; Um LED indicando se a conexão física é full-duplex
11;
Um LED indicando se a velocidade de conexão é de 100 Mbps (Fast Ethernet);
Um LED indicando atividade na conexão física; Um CI controlador de rede IP.
3.3.8 Módulo CAN
O módulo CAN atua como interface de comunicação do
microcontrolador com a rede CAN, tornando-o compatível com o barramento. Além disso, o módulo permite que até dois frames sejam armazenados em buffer, enquanto o MCU não realizar a leitura dos mesmos.
10
Interface de comunicação entre aplicações em uma rede de computadores. Normalmente associada a um conjunto IP/Porta.
11 Trafego de dados nos dois sentidos da comunicação, ao
mesmo tempo.
54
Caso o SAR seja uma das pontas do barramento CAN, o usuário pode adicionar um jumper no módulo, aplicando-lhe um Terminador CAN na extremidade do barramento.
A comunicação entre o módulo e o microcontrolador é realizada através dos pinos de comunicação SPI: SCK, SDI, SDO e CS, enquanto que a comunicação com o barramento CAN é realizada pelos conectores RJ12. Os dois conectores têm seus pinos diretamente ligados, representado na Figura 27, onde o pino 1 do Conector A está em curto-circuito com o pino 1 do Conector B, o pino 2 do Conector A está em curto-circuito com o pino 2 do Conector B, e assim por diante. Estão contidos no módulo:
Um LED indicando que o buffer RX0 está cheio; Um LED indicando que o buffer RX1 está cheio; Um transceptor CAN; Um controlador CAN; Uma barra de pino de duas vias, possibilitando a
inclusão do Terminador CAN no barramento;
Figura 27 – Conexões entre conectores CAN
Os dois conectores formam o barramento CAN, que pode
ser estendido aos demais elementos da rede. Para que isso seja possível, é necessário estabelecer um padrão de conectividade do barramento CAN.
55
3.4 CONECTIVIDADE DA REDE CAN
A Figura 28 apresenta o padrão de conectividade
estabelecido para a rede CAN deste projeto. Ao todo, são 3 pares trançados de conexão no RJ12.
O par central, pinos 3-4, são os pinos de sinal do barramento, CANH e CANL, respectivamente.
O primeiro par, pinos 1-2, correspondem aos pinos de alimentação da fonte externa, VCC e GND respectivamente, conectada ao servidor.
O terceiro par, pinos 5-6, são os mesmos do primeiro, servindo como redundância da fonte de alimentação.
Figura 28 – Padrão de conectividade CAN
O padrão de conectividade CAN deve ser obedecido por
todos os elementos da rede, entre eles, o Servidor e o Controlador. Caso contrário, o dispositivo pode não conseguir
56
interpretar os frames CAN trafegados, ou até causar danos ao mesmo.
O cabo utilizado para conexão é o cabo UTP Cat5e. Esse cabo será conectado ao Servidor, passará por um eletroduto e será conectado ao Controlador, que deve compartilhar dos mesmos padrões de conectividade estabelecido neste.
Após as definições de conectividade da rede de dados, partiu-se para a definição do gabinete do Controlador, de acordo com o local em que ele será instalado.
3.5 GABINETE DO CONTROLADOR
O Controlador deverá substituir um interruptor tradicional
de uma casa, estando este instalado em uma caixa de energia elétrica 4x2’’ de embutir em parede de alvenaria. Não está previsto neste projeto, variações de instalação do Controlador, como em caixas de sobrepor, porém não está descartada a possibilidade de instalação do dispositivo no mesmo.
Como referência de gabinete do Controlador foi um tipo de interruptor modular, apresentado na Figura 29, formado por um conjunto de três estruturas: suporte, chaves e espelho. Esse tipo de interruptor permite que as estruturas sejam facilmente separadas e modificadas por outros elementos do projeto.
Para o gabinete do Controlador, foram utilizadas as estruturas de suporte e espelho, sendo as chaves descartadas. Em seu lugar, foi acoplada ao suporte uma placa de interface contendo o mecanismo de interação com o usuário. Além dessa, será utilizada mais duas placas de funcionalidade distinta. A Figura 30 ilustra a visão geral de instalação do Controlador, onde a placa de interface é posicionada na área interna do suporte plástico, conectando-se a segunda placa, que por sua fez, conecta-se a terceira. Com exceção da primeira, as placas ficam embutidas na caixa padrão de 10x15 cm. Sobre o suporte e a primeira placa, é posicionado o espelho do gabinete mantendo a primeira fixa no suporte, expondo apenas os mecanismos presentes na área de interação da mesma.
57
... (a) Visão real da estrutura ......... (b) Visão modular da estrutura
Figura 29 – Estrutura do modelo de Interruptor
Figura 30 – Visão geral de instalação do Controlador
A Figura 31 apresenta as dimensões em milímetros do suporte plástico. A primeira placa foi dimensionada levando-se em consideração que a mesma irá permanecer fixada no suporte, não podendo transcorrer para a área embutida, diferente da segunda e terceira placas. Assim, a placa de interface deve ter a dimensão máxima de 45x71 mm e deve ser ligeiramente superior às outras duas, com dimensão máxima de 39x71 mm.
58
Figura 31 – Dimensões do suporte plástico de fixação
Com as definições das dimensões, partiu-se para o
desenvolvimento das PCIs do Controlador.
3.6 HARDWARE DO CONTROLADOR
O Controlador é composto por três placas distintas,
denominadas como: Interface (primeira), Controle (segunda) e Analog (terceira). A arquitetura de cada uma delas e como elas se interligam, formando a eletrônica do dispositivo, é descrito a seguir.
3.6.1 Placa Interface
Como especificado anteriormente, a placa interface tem
como principal função permitir a interação do usuário com o dispositivo. Por ela, o usuário poderá ligar e desligar a lâmpada manualmente.
Diferente do mecanismo de chaves original, substituído por esta no gabinete, a placa Interface utiliza chaves tácteis, apresentado na Figura 32, como mecanismo de interação com o usuário. Ao todo, são expostas três chaves de controle. Cada chave corresponde ao acionamento de uma lâmpada, tendo em vista o controle de três lâmpadas pelo Controlador.
59
Figura 32 – Vista frontal da placa Interface
Para conectar-se a placa Controle são utilizados barras de
pinos, demonstrados na Figura 33. As barras de pinos tem a função de sustentar a segunda placa e enviar os sinais digitais de acionamento dos botões da Interface. Ao todo, são três barras de pinos de sinais, um de cada chave, e um de alimentação do driver das chaves.
Figura 33 – Vista posterior da placa Interface
3.6.2 Placa Controle
A segunda placa (Controle) tem a função de realizar o
controle digital do acionamento das lâmpadas a partir de comandos provenientes do barramento CAN ou através da
60
interação do usuário com o dispositivo. A Figura 34, apresenta a arquitetura de hardware da placa Controle.
O bloco módulo CAN é idêntico ao bloco do SAR, apresentado na secção 3.3.8, ligado ao conector com padrão de conectividade do barramento CAN. É a partir dele que o Controlador é energizado. A alimentação fornecida pelo barramento é regulada no bloco regulador de tensão para o nível de operação dos módulos contidos nesta e nas outras placas. Também estão presentes no dispositivo: o LED Power, botão Reset e conector de gravação (neste caso como barra de pino de seis vias), exercendo as mesmas funções já citadas no hardware do SAR, apresentada na secção 3.3.
Os pinos contendo os sinais digitais das três chaves, provenientes da Interface, estão conectados em pinos com função de I/O do microcontrolador. Assim, o MCU pode realizar a leitura do pino identificando se o botão foi pressionado.
A placa Analog é conectada ao Controle através de outro conjunto de quatro barras de pinos. Além de sustentar a terceira placa do dispositivo, estão ligados a pinos com função de I/O do MCU para controle digital da intensidade das lâmpadas.
Figura 34 – Arquitetura da placa Controle
61
3.6.3 Placa Analog
A Figura 35 apresenta a arquitetura de hardware da placa
Analog. Sua função é realizar a leitura do ponto de inflexão da curva senoidal da tensão alternada e liberar a corrente na lâmpada a partir do acionamento digital do microcontrolador.
Os fios da rede elétrica são ligados no conector Borne In, onde o neutro é encaminhado para os outros conectores bornes. O fase atua como elemento de entrada para o módulo Cross e os módulos Gate.
O módulo Cross é constituído por um circuito eletrônico capaz de manter o sinal digital de saída em nível lógico alto, enquanto a corrente alternada de entrada for diferente de zero. No momento em que a corrente for é igual (ou próxima) de zero, o módulo altera o sinal de saída para nível lógico baixo, indicando digitalmente o momento em que a tensão alternada está em 0 Vac.
Figura 35 – Arquitetura da placa Analog
62
O módulo Gate é constituído por um circuito eletrônico capaz de liberar a corrente alternada da entrada (fase) na saída do módulo (Retorno), mediante um disparador digital. Desta forma, o microcontrolador pode controlar a passagem de corrente alternada na lâmpada através dos pinos de I/O.
Após finalizar as definições de hardware do Controlador, as placas dos dispositivos foram confeccionadas. Assim que entregues pelo fornecedor, foram montadas dando início ao desenvolvimento dos firmwares.
3.7 FIRMWARE DO CONTROLADOR
Para o firmware do Controlador, ao todo, foram criados
quatro drivers distintos: Cross, Gate, Chave e CAN. A aplicação possui até três instancias dos drivers Gate e Chave, referentes ao número de lâmpadas e chaves contidas no hardware, respectivamente.
A Figura 36 apresenta um diagrama de visão geral do firmware desenvolvido para o Controlador. Ao ser inicializado, ou seja, o dispositivo ser energizado, é atribuído o valor zero para a variável de controle (CTRL). Esta variável é utilizada para controlar se uma determinada operação deve ser executada na iteração do laço principal.
Em seguida, os drivers dos módulos periféricos são inicializados. Nesse processo, os pinos do microcontrolador são configurados de acordo com a função exercida em cada módulo. Também são habilitadas as interrupções dos drivers CAN e Cross. As interrupções do Gate1Timer, Gate2Timer e Gate3Timer estão relacionadas à interrupção do timer interno do MCU vinculado ao driver do Gate correspondente, porém não são habilitadas neste momento. A função de tratamento das interrupções (Figura 36.b) apenas modifica o valor da variável CTRL, alterando o bit da operação.
Ao fim do processo de inicialização, o Controlador envia dois frames, um contendo a versão do firmware do controlador e outro contendo o comando de varredura para o SAR com o estado inicial das lâmpadas.
63
................. ...... (a) Aplicação Principal ......... (b) Tratamento de Interrupções
Figura 36 – Visão Geral do firmware do Controlador
No laço principal, apresentado na Figura 37, podem ser
executadas até nove operações diferentes, de acordo com os bits da variável de controle:
CTRL.Can = 1:realiza a leitura do frame contido no buffer módulo CAN;
CTRL.Cross = 1: indica, através dos bits da variável de controle, que deve ser executada as operações de Gate1Start, Gate2Start e Gate3Start;
CTRL.Gate1Start = 1: altera para nível lógico baixo o pino de disparo do Gate1, carrega o tempo de contagem e habilita a contador do timer do Gate1;
CTRL.Gate1Timer = 1: altera para nível lógico alto o pino de disparo do Gate1 e desabilita o contador do timer do Gate1;
64
Figura 37 – Laço principal do firmware do Controlador
CTRL.Gate2Start = 1: altera para nível lógico baixo o
pino de disparo do Gate2, carrega o tempo de contagem e habilita a contador do timer do Gate2;
CTRL.Gate2Timer = 1: altera para nível lógico alto o pino de disparo do Gate2 e desabilita o contador do timer do Gate2;
CTRL.Gate3Start = 1: altera para nível lógico baixo o pino de disparo do Gate3, carrega o tempo de contagem e habilita a contador do timer do Gate3;
CTRL.Gate3Timer = 1: altera para nível lógico alto o pino de disparo do Gate3 e desabilita o contador do timer do Gate3;
CTRL = 0: verifica se tem algum frame para ser tratado, caso seja confirmado, executa o comando do frame recebido e envia uma resposta ao SAR. Também verifica se alguma chave foi pressionada pelo usuário, em caso afirmativo, altera o valor a ser carregado pelo contador do timer do respectivo Gate, relativo à chave
65
pressionada, e envia um comando de Atualização de Estado da lâmpada ao servidor;
Sempre que executada uma determinada operação, seu bit na variável CTRL é limpado.
Finalizado o dispositivo Controlador, foi iniciado o desenvolvimento do firmware do SAR, integrando ambos dispositivos no sistema DroidLar.
3.8 FIRMWARE DO SAR
O desenvolvimento do firmware do SAR foi baseado na
lógica de controle de duas máquinas de estados independentes entre si, chamadas de Server e Device. O Server atua na comunicação entre o SAR e o cliente Android através do módulo IP, enquanto que o Device trabalha na comunicação com os controladores do barramento CAN.
A Figura 38 ilustra o diagrama de visão geral do firmware do SAR. Basicamente, são executados quatro processos antes do controle das máquinas de estados.
Os dois primeiros processos da etapa de inicialização do servidor, após a energização do dispositivo, são caracterizados pela configuração dos pinos do microcontrolador relativos aos drivers dos módulos, de acordo com as definições de hardware apresentadas na secção 3.3, e atribuição dos valores iniciais dos mesmos, entre eles, o endereço da rede IP do dispositivo.
Ainda na etapa de inicialização, são executados mais dois processos para atribuir um estado inicial para as máquinas de estados Server e Device.
O controle de execução da máquina de estados Device é apresenta na Figura 39. Em cada estado, é realizada uma determinada operação:
IDLE: estado inicial da máquina Device. Nesse estado o dispositivo verifica se há algum frame no buffer do módulo CAN, caso haja, faz sua leitura e altera o estado da máquina para REQUEST. Também é nesse estado que é verificado se o tempo de varredura periódica foi atingido, caso confirmado, prepara um frame de varredura e altera o estado da máquina para SEND_DEV;
66
Figura 38 – Visão Geral do firmware do SAR
REQUEST: nesse estado é realizado o tratamento do
frame obtido em outro estado. Caso seja um comando de Atualização de Estado da lâmpada, o SAR apenas responde ao Controlador adequadamente e altera o estado da máquina para IDLE. Caso o frame seja uma resposta ao comando de Varredura ou Controle de Intensidade, o servidor atualiza sua lista de controladores da rede CAN e altera o estado da máquina para SEND_SAR;
SEND_SAR: nesse estado o dispositivo prepara um pacote IP com a resposta do Controlador à solicitação do Cliente Android e, em seguida, altera o estado da máquina para IDLE;
SEND_DEV: nesse estado o dispositivo apenas envia o frame preparado em outro estado qualquer. Após isso, altera o estado da máquina para WAITING;
67
WAITING: nesse estado o dispositivo aguarda a resposta a um comando enviado anteriormente. Passado um determinado tempo, caso o dispositivo não tenha recebido o frame, o estado é modificado para NO_ANSWER, caso contrário, é modificado para REQUEST;
NO_ANSWER: nesse estado o dispositivo prepara um pacote IP com uma resposta de erro e altera o estado da máquina para SEND_SAR.
Figura 39 – Máquina de estados Device
O estado da máquina Device pode ser alterado para
SEND_DEV pela ação da máquina Server. Isso ocorre quando uma solicitação do Cliente Android deve ser repassada ao Controlador. Em contra partida, o estado da máquina Server é alterado pelo Device quando este necessita enviar uma resposta do controlador ao cliente, após a preparação do pacote IP no estado SEND_SAR.
68
O controle de execução da máquina de estados Server é apresenta na Figura 40. Também para cada estado, é realizada uma operação especifica:
IDLE: estado inicial da máquina Server. Nesse estado o dispositivo fica escutando a rede IP até que seja estabelecida uma conexão. Estando essa realizada, o SAR faz a leitura do pacote enviado pelo cliente Android e altera o estado da máquina para REQUEST;
Figura 40 – Máquina de estados Server
REQUEST: nesse estado o dispositivo verifica o tipo do
pacote recebido. Caso seja uma autenticação, o estado da máquina é alterado para AUTHENTICATION. Caso contrário, verifica-se na variável do controlador da máquina se um usuário foi autenticado anteriormente, preparando um pacote de erro e modificando o estado para RESPONSE_CLIENT quando negativo. Se condições anteriores forem atendidas, o estado da máquina é alterado para OPERATION_ADMIN ou
69
OPERATION_NORMAL, dependendo do tipo de usuário autenticado;
AUTHENTICATION: nesse estado o dispositivo compara as informações do usuário com sua lista permissões. Caso o usuário não seja encontrado, é preparado um pacote de erro. Caso contrário, a variável de controle é atualizada com o tipo de permissão do usuário, administrador ou normal, e um pacote de sucesso é preparado. Em seguida, o estado da máquina é alterado para RESPONSE_CLIENT;
RESPONSE_CLIENT: nesse estado o dispositivo apenas envia o pacote IP, preparado anteriormente em outro estado, para o cliente. O estado da máquina é modificado de acordo com o tipo de autenticação contida na variável de controle, podendo ser IDLE, LOGGED_ADMIN ou LOGGED_NORMAL;
LOGGED_ADMIN e LOGGED_NORMAL: nesses dois estados o dispositivo realiza a mesma operação do estado IDLE, porém um contador marca o tempo em que o usuário de permanecer ativo. O contador é atualizado sempre que um pacote é recebido pelo SAR. Caso o limite de tempo seja excedido, o estado é alterado para IDLE;
OPERATION_ADMIN e OPERATION_NORMAL: nesses dois estados o dispositivo realiza a mesma operação, trata o comando contido no pacote IP enviado pelo cliente. De acordo com o tipo de comando, o estado da máquina pode ser alterado para DEVICE_LIST (comando de Requisição de Dispositivo), DEVICE_CHANGE (comando de Controle de Intensidade), DEVICE_SCAN (comando de Varredura) ou DEVICE_NAME_CHANGE (comando de Configurar Nomes). A diferenciação entre usuário administrador e normal ocorre apenas nos comandos de Configurar Nomes e Configurar Varredura Periódica, onde o usuário normal não tem permissão para executá-lo. Nesse caso, é preparado um pacote de erro e modificado o estado para RESPONSE_CLIENT, caso contrário, é preparado um pacote de sucesso.
70
DEVICE_LIST: nesse estado o dispositivo prepara um pacote IP com a lista de controladores da rede CAN. Após, o estado é alterado para RESPONSE_CLIENT;
DEVICE_CHANGE: nesse estado o dispositivo prepara um frame de Controle de Intensidade para ser enviado ao controlador. Após, o estado é modificado para WAITING;
DEVICE_SCAN: nesse estado o dispositivo prepara um frame de Varredura para ser enviado aos controladores. Após, o estado é modificado para WAITING;
DEVICE_NAME_CHANGE: nesse estado o dispositivo atualiza os nomes das lâmpadas dos controladores de sua lista e prepara um pacote IP de sucesso. Após, o estado é modificado para RESPONSE_CLIENT;
WAITING: nesse estado o dispositivo aguarda a resposta do Controlador ao comando enviado na rede CAN. Passado um determinado tempo, caso o dispositivo não tenha recebido o frame, é preparado um pacote IP de erro e alterado o estado para RESPONSE_CLIENT.
O estado da máquina Server pode ser alterado para RESPONSE_CLIENT pela operação SEND_SAR da máquina Device. Por outro lado, o Device é alterado para o estado SERV_DEV quando são realizadas as operações os estados DEVICE_CHANGE e DEVICE_SAN da máquina Server.
Com o firmware do SAR desenvolvido, os dispositivos puderam ser aplicados e testados em um ambiente controlado. Os resultados dos testes são apresentados a seguir.
71
4 RESULTADOS Os resultados apresentados a seguir foram obtidos
principalmente através do canal de depuração do SAR e da utilização de osciloscópio, para obtenção da forma de onda da corrente alternada aplicada na lâmpada pelo Controlador.
Inicialmente, são descritos os parâmetros de configuração do canal de depuração e os registros de eventos que serão apresentados no mesmo. Em seguida, é demonstrado o ambiente de teste empregado para obtenção dos resultados com o osciloscópio. Por fim, são apresentados os testes de funcionalidade do sistema.
4.1 CANAL DE DEPURAÇÂO
O canal de depuração do SAR foi utilizado, em conjunto
com um software terminal, para monitorar as mudanças de estado das máquinas lógicas implementadas no SAR e os pacotes IP e frames CAN na comunicação do dispositivo com os outros elementos do sistema.
Para isso, o servidor foi conectado à porta de comunicação serial do PC, através do conector DB9. No software terminal foi necessário configurar apenas a porta serial do PC, utilizada na comunicação com o SAR, e o baud rate
12, com o valor de 115200
bps. A Figura 41 apresenta a configuração realizada no software terminal Putty.
As linhas contendo com o registro dos eventos do sistema são sempre precedidas de uma data e hora, referente ao relógio interno do dispositivo.
Os eventos de mudanças de estado das máquinas Device e Server do SAR são identificadas pelo registro “Maquina”, seguido do nome da máquina de estado, seguido do estado assumido. Um exemplo destes eventos é apresentado na Figura 42, onde a mensagem “Maquina DEVICE: IDLE” significa que a máquina de estados Device entrou para o estado IDLE e a mensagem “Maquina SERVER: IDLE” significa que a máquina de estados Server entrou para o estado IDLE.
12
Taxa de transmissão na comunicação serial.
72
Figura 41 – Configuração do canal de depuração
Figura 42 – Exemplo de evento de mudança de estado
A Figura 43 apresenta alguns exemplos de registro de
eventos de comunicação na troca de pacote IP ou frame CAN entre os dispositivos. O registro é composto pelos parâmetros:
Tipo de mensagem: “CAN” para frames trocados com os controladores e “IP” para pacotes trocados com o cliente Android;
Sentido da mensagem: “>>” indicando que a mensagem está sendo enviada pelo SAR e “<<” identificando que a mensagem está sendo recebida pelo SAR;
Descrição da mensagem: conteúdo do pacote IP ou frame CAN transmitido.
Figura 43 – Exemplo de evento de comunicação
73
4.2 AMBIENTE DE TESTE
A Figura 44 apresenta uma foto do ambiente DroidLar
montado para demonstrar a funcionalidade do sistema. O celular Android não está presente na imagem, pois foi utilizado para tirar a fotografia. A rede IP é representada pelo cabo UTP que liga o roteador wifi ao SAR. Por sua vez, a rede CAN é representada pelo cabo UTP que liga o SAR ao Controlador, já embutido na caixa de energia elétrica 4x2. O cabo de continuidade da rede CAN demonstra que é possível conectar mais um elemento ao barramento, através do segundo conector CAN presente no dispositivo da ponta da rede. No controlador, estão ligadas as lâmpadas e a rede elétrica através dos seus respectivos fios.
Figura 44 – Ambiente de teste do sistema DroidLar
4.3 TESTES DE FUNCIONALIDADE
Os testes de funcionalidade do sistema são apresentados
a seguir. Foram realizados os teste de: Inicialização do SAR, Inicialização do Controlador, Varredura Periódica, Acender Lâmpada via Controlador, Apagar Lâmpada via Controlador e Controle de Intensidade via Cliente Android.
74
4.3.1 Inicialização do SAR
Os resultados da inicialização do SAR são demonstrados
na Figura 45. Ao ser energizado, o servidor apresenta suas configurações iniciais:
Firmware versão V.1.0.0 Varredura periódica habilitada para 15 minutos; Endereço MAC: 5C-86-4A-00-00-DF; Endereço de rede IP: 10.0.0.10; Mascara: 255.255.255.0; Endereço de Gateway: 10.0.0.1. Também é possível identificar na Figura 45 a execução do
processo de inicialização das máquinas de estados Device e Server, pois foram registrados os eventos de mudança de estado.
Figura 45 – Resultado da inicialização do SAR
O endereço de rede IP configurado para o servidor é
aplicado no software DroidLar do Cliente Android. Para verificar se o dispositivo está realmente conectado na
rede IP, foi utilizado o Processador de comando do Windows, enviando um pacote ping para o IP atribuído ao dispositivo.
Os resultados obtidos nas Figura 45 e Figura 46 validam com sucesso à etapa de inicialização do SAR, especificada na secção 3.8.
75
Figura 46 – Envio de pacote ping ao SAR
4.3.2 Inicialização do Controlador
O resultado da inicialização do Controlador é demonstrado
na Figura 47. Ao ser conectado na rede CAN já energizada, o Controlador envia ao SAR dois frames, um contendo a versão do seu firmware e outro com a intensidade inicial das lâmpadas.
O primeiro frame, de versão do firmware, é identificado pelo valor 56h no primeiro byte do campo “data”. O segundo frame consiste no comando de varredura, identificado pelo valor 10h no primeiro byte do campo “data”. Também está demonstrado no comando que as lâmpadas 0Ah, 0Bh e 0Ch, iniciam com intensidade de 0% (00h).
Pode-se confirmar que o frame de varredura enviado pelo Controlador corresponde ao frame da inicialização, pois não houve requisição de varredura proveniente do SAR.
Figura 47 – Resultado da inicialização do Controlador
76
O resultado obtido na Figura 47 valida com sucesso à etapa de inicialização do Controlador, especificada na secção 3.7.
4.3.3 Varredura Periódica
O resultado da funcionalidade de varredura periódica do
SAR é demonstrado na Figura 48. Logo após a inicialização, o servidor envia um frame de varredura em broadcast
6 para os
controladores conectados na rede CAN. O Controlador que estiver presente envia uma resposta ao SAR. O frame de resposta do Controlador é idêntico ao frame enviado pelo mesmo em seu processo de inicialização.
Pode-se confirmar que o frame de varredura enviado pelo SAR pertence ao processo de varredura periódica, pois não houve requisição de varredura proveniente do Cliente Android, o que alteraria o estado da máquina Server. Além disso, o intervalo de tempo entre os frames enviados confirma o valor atribuído à varredura periódica no processo de inicialização do SAR.
Figura 48 – Resultado da varredura periódica
O resultado obtido na Figura 48 valida com sucesso a
funcionalidade de Varredura Periódica do SAR, citada na secção 2.3.
77
4.3.4 Acender Lâmpada via Controlador
O resultado da funcionalidade de acender a lâmpada via
Controlador é demonstrado na Figura 49. Logo após usuário pressionar a chave, o Controlador envia um frame de Atualização de Estado da lâmpada para o SAR.
O frame da Atualização de Estado é identificado pelo valor 30h no primeiro byte do campo “data”. Também está demonstrado no comando a alteração da intensidade da lâmpada 0Ah para 100%, indicada pelo quarto byte (FFh) do campo “data”.
Pode-se confirmar que o frame enviado pelo Controlador consiste no comando de Atualização de Estado, pois não houve alteração no estado da máquina Server.
Figura 49 – Resultado de acender via Controlador
O resultado da mudança efetiva da intensidade da
lâmpada para o valor máximo está representado na Figura 50, onde o canal 2 do osciloscópio representa a corrente alternada aplicada.
Figura 50 – Corrente aplicada na lâmpada em 100%
Pode-se confirmar, na Figura 51, que a mudança da
intensidade da lâmpada para o valor máximo foi gerada a partir
78
do Controlador, onde o canal 1 do osciloscópio representa o buffer do módulo do CAN do servidor sendo preenchido com o frame de Atualização de Estado enviado pelo Controlador (nível lógico alto quando o buffer está cheio), enquanto que o canal 2 representa o momento da mudança da forma de onda da corrente alternada.
Figura 51 – Corrente aplicada na lâmpada ao acendê-la
O atraso entre o envio do frame e a mudança da forma de
onda é proposital, pois o Controlador altera o valor da variável de intensidade logo após o envio do comando, porém a mudança é aplicada apenas após a identificação do fim do ciclo da corrente, a partir do driver Cross.
Os resultados obtidos nas Figura 49, Figura 50 e Figura 51 validam com sucesso a funcionalidade do Controlador em acender a lâmpada através das chaves, citada na secção 3.6.
4.3.5 Apagar Lâmpada via Controlador
O resultado da funcionalidade de apagar a lâmpada via
Controlador é demonstrado na Figura 52. Também para esta funcionalidade, logo após usuário pressionar a chave, o Controlador envia um frame de Atualização de Estado da lâmpada para o SAR.
79
Neste caso, o frame da Atualização de Estado apresenta o valor de alteração da intensidade da lâmpada 0Ah em 0% (00h). Também não há alteração no estado da máquina Server, confirmando sua veracidade.
Figura 52 – Resultado de apagar via Controlador
Pode-se confirmar o resultado da mudança efetiva da
intensidade da lâmpada para o valor mínimo na Figura 53, sendo o canal 1 do osciloscópio a representação do buffer do módulo do CAN do servidor, enquanto o canal 2 representa o momento da mudança da forma de onda da corrente alternada.
Figura 53 – Corrente aplicada na lâmpada ao apagá-la
Os resultados obtidos nas Figura 52 e Figura 53 validam
com sucesso a funcionalidade do Controlador em apagar a lâmpada através das chaves, citada na secção 3.6.
80
4.3.6 Autenticação do Usuário
O servidor possui apenas dois tipos de usuário,
administrador e normal. Para autenticar-se como usuário administrador, na tela de Configurações do DroidLar apresentada na, deve-se preencher os campos “Nome” e “Senha” com os valores “admin” e “admin”, respectivamente. Para autenticar-se como usuário normal, deve-se preencher os campos com os valores “android” e “android”, respectivamente. O campo “Endereço do Servidor” deve ser preenchido com o IP do SAR, citado na secção 4.3.1.
Figura 54 – Tela de Configurações do DroidLar
O resultado da funcionalidade de autenticação do usuário
administrador no SAR é demonstrado na Figura 55. Após o preenchimento dos campos com os dados de administrador, um pacote IP é enviado para o SAR. As Informações são processadas e é enviado um pacote com a resposta de sucesso (caractere 0) ao Cliente Android.
Figura 55 – Resultado da autenticação admin
81
O resultado da funcionalidade de autenticação do usuário normal no SAR é demonstrado na Figura 56. Os campos são preenchidos com os dados de usuário normal e enviados para o SAR. Após o processamento, também é enviada uma resposta de sucesso (caractere 0) ao Cliente Android.
Figura 56 – Resultado da autenticação normal
Pode-se confirmar o resultado da autenticação com a
permanência da máquina Server no estado LOGGED_ADMIN, quando administrador, e LOGGED_NORMAL, quando usuário normal. Também observa-se que o usuário fica autenticado no sistema por um curto período de tempo, em torno de 1 minuto e meio. Se durante esse tempo não forem enviados mais pacotes IP ao servidor, a máquina Server retorna ao estado IDLE.
O resultado da funcionalidade de autenticação do usuário
inexistente no SAR é demonstrado na Figura 57, onde os campos são preenchidos com os dados de que não conferem com o do usuário administrador ou normal. Assim, o SAR envia uma resposta de erro (caractere 1) ao Cliente Android.
Figura 57 – Resultado do erro na autenticação
Os resultados obtidos nas Figura 55, Figura 56 e Figura 57
validam com sucesso a funcionalidade de Autenticação de Usuário do SAR, citada na secção 2.3.
82
4.3.7 Controle de Intensidade da Lâmpada
O resultado da funcionalidade de controle de intensidade
da lâmpada, via Cliente Android, é demonstrado nas Figura 58 e Figura 59. O pacote IP de controle de intensidade, identificado pelo valor 3 da variável “tipo”, é enviado ao SAR. Por sua vez, o servidor converte o comando do pacote em um frame, repassando-o ao Controlador.
Enquanto o SAR não recebe uma resposta do Controlador, ele mantem as duas máquinas, Server e Device, em estado WAITING. Ao receber a resposta do Controlador, a máquina Device é alterada para o estado REQUEST, onde o frame é processado. Em seguida, a máquina Device entra no estado SEND_SAR, preparando um pacote IP de resposta. Neste momento, a máquina Server é alterada para RESPONSE_CLIENT para que seja enviado o pacote ao Cliente Android.
Ao terminar seu trabalho, a máquina Device retorna ao estado IDLE, enquanto que a máquina Server, após o envio do pacote IP, retorna para o estado em que estava antes de receber a requisição.
Figura 58 – Resultado do controle de intensidade admin
Pode-se confirmar o resultado do controle de intensidade
com o fluxo dos dados transmitidos e com o conteúdo dos pacotes e frame. No primeiro pacote IP, a variável “modulo” contém o identificado do Controlador que é utilizado no campo “id” do frame CAN (66404 = 10364h [id] = 64,03,01,00). Também estão presentes no pacote a variável “mensagem”
83
contendo o valor da intensidade requisitada (255 = FFh) e a variável “opcao” contendo o identificador da lâmpada presente no Controlador (11 = 0Bh). O segundo pacote IP, representa uma resposta de sucesso, indicando que o comando foi realizado pelo Controlador.
Figura 59 – Resultado do controle de intensidade normal
Ao comparar os fluxos das Figura 58 e Figura 59, pode-se
afirmar que o controle de intensidade pode ser realizado tanto por usuário normal quanto por administrador, diferentemente do apresentado na Figura 60. Nesta, o usuário perdeu ou não foi autenticado, sendo no segundo pacote IP uma resposta de erro.
Figura 60 – Resultado de erro no controle de intensidade
Como forma de comprovar a veracidade da execução do
controle de intensidade pelo Controlador, a Figura 61 apresenta o resultado da mudança de intensidade da lâmpada para valores intermediários, como por exemplo, enviado o enviado pelo usuário normal na Figura 59. O canal 2 do osciloscópio representa a corrente alternada aplicada na lâmpada após o comando ser processado pelo Controlador.
84
(a) Exemplo de valor intermediário 1
(b) Exemplo de valor intermediário 2
Figura 61 – Formas de onda no controle de intensidade
Complementando as demonstrações da Figura 61, a
Figura 62 apresenta como é realizado o controle da intensidade da lâmpada no Controlador, a partir do disparo da corrente alternada pelos drivers Gate. O canal 1 do osciloscópio representa o sinal do pino de I/O do microcontrolador ligado à entrada do módulo Gate, enquanto que o canal 2 representa a injeção da corrente alternada na lâmpada, a partir da saída do módulo (Retorno).
85
(a) Exemplo de controle da intensidade 1
(b) Exemplo de controle da intensidade 2
Figura 62 – Controle da intensidade via Controlador
Os resultados obtidos nas Figura 58, Figura 59, Figura 60,
Figura 61 e Figura 62 validam com sucesso a funcionalidade de Controle de Intensidade, citada na secção 3.6.
4.3.8 Requisição de Varredura via Cliente Android
O resultado da funcionalidade de Requisição de Varredura
via Cliente Android é demonstrado nas Figura 63 e Figura 64. O
86
pacote IP de varredura, identificado pelo valor 5 da variável “tipo”, é enviado ao SAR. Por sua vez, o servidor prepara um frame de varredura em broadcast
6 e envia aos controladores na
rede CAN. O Controlador que estiver presente envia uma resposta ao SAR. O frame de resposta do Controlador é idêntico ao frame enviado pelo mesmo em resposta a uma varredura periódica.
Caso o SAR receba alguma resposta de qualquer controlador, ele envia ao Cliente Android um pacote IP contendo a resposta de sucesso na operação.
Figura 63 – Resultado da varredura via DroidLad admin
Comparando os fluxos das Figura 63 e Figura 64, pode-se
afirmar que a requisição de varredura pode ser realizado tanto por usuário normal quanto por administrador, diferentemente do apresentado na Figura 65. Nesta, o usuário perdeu ou não foi autenticado, sendo no segundo pacote IP uma resposta de erro.
Figura 64 – Resultado da varredura via DroidLad normal
87
Figura 65 – Resultado de erro na varredura via DroidLad
O resultado obtido nas Figura 63, Figura 64 e Figura 65
validam com sucesso a funcionalidade de Requisição de Varredura, citada na secção 2.3.
4.3.9 Configurar Nomes das Lâmpadas
O resultado da funcionalidade de configuração dos nomes
das lâmpadas é demonstrado na Figura 66. O pacote IP de Configurar Nomes, identificado pelo valor 11 da variável “tipo”, é enviado ao SAR. Os nomes contidos na variável “mensagem” são atualizados na lista de lâmpadas dos dispositivos armazenada na memória do servidor. Após o processo, é enviado um pacote com a resposta de sucesso ao Cliente Android.
Figura 66 – Resultado de configurar nomes admin
Pode-se confirmar o resultado da autenticação com a
resposta do SAR ao primeiro e segundo pacotes IP de Atualizar Lista, identificado pelo valor 7 da variável “tipo”. Na resposta do primeiro, o servidor informa que os nomes das lâmpadas 10, 11 e 12 do Controlador 66404 são “sala”, “quarto” e “banheiro”,
88
respectivamente. No pacote de Configurar Nomes, observa-se que o nome da primeira lâmpada do Controlador 66404 foi alterado para “NOVO”. Na resposta do segundo pacote IP de Atualizar Lista, o nome da lâmpada 10 já foi alterado.
Nota-se, na Figura 67, que o comando de Configurar Nomes só pode ser executado por usuário autenticado como administrador. Como resposta a solicitação do usuário normal, o SAR envia um pacote contendo uma resposta de erro, negando a permissão de configuração.
Figura 67 – Resultado de configurar nomes normal
Os resultados obtido nas Figura 66 e Figura 67 valida com
sucesso a funcionalidade de Configurar Nomes das Lâmpadas, citada na secção 2.3.
4.3.10 Configurar Varredura Periódica
O resultado da funcionalidade de configuração do tempo
da varredura periódica é demonstrado na Figura 68 e Figura 69. O pacote IP de Configurar Varredura Periódica, identificado pelo valor 14 da variável “tipo”, é enviado ao SAR. O valor da varredura periódica contida na variável “mensagem” é atribuído à variável interna do servidor para contagem. Imediatamente após a configuração, o SAR inicia a contagem do tempo de varredura periódica realizando uma varredura inicial.
Pode-se confirmar que os dois primeiros frames de varredura enviados pelo SAR estão em intervalo de 15 minutos. Após a configuração do tempo de varredura periódica, o intervalo entre os frames reduziu para 5 minutos.
Nota-se, na Figura 69, que o comando de Configurar Varredura Periódica só pode ser executado por usuário autenticado como administrador. Como resposta a solicitação do
89
usuário normal, o SAR envia um pacote contendo uma resposta de erro, negando a permissão de alteração.
Figura 68 – Resultado de configurar varredura admin
Figura 69 – Resultado de configurar varredura normal
O resultado obtido nas figuras Figura 68 e Figura 69 valida
com sucesso a funcionalidade de Configurar Varredura Periódica, citada na secção 2.3.
90
5 CONCLUSÃO Esse trabalho apresentou e discutiu o projeto e a execução
de dois produtos voltados para automação residencial, aplicáveis em um ambiente real, agregando valor a uma solução de código aberto desenvolvido academicamente por terceiros, denominado DroidLar. Na Revisão bibliográfica, Capítulo 2, foram apresentadas as tecnologias envolvidas no desenvolvimento, desde o protocolo de comunicação entre os dispositivos até o sistema já constituído para plataforma Android. Essa revisão foi de vital importância no levantamento das informações necessárias para introduzir os produtos criados no sistema DroidLar.
Um dos principais agentes externos que influenciaram negativamente no desenvolvimento deste trabalho ficou a cargo dos fornecedores de placas de circuito impresso e componentes eletrônicos. Alguns dos circuitos integrados utilizados no SAR não são comercializados no varejo brasileiro, necessitando que os mesmos fossem importados. Isso acarretou um aumento significativo no custo e no prazo de desenvolvimento do projeto.
Outro ponto importante foi a necessidade de recriar o layout da PCI devido a falhas no desenho do componente presente no hardware do SAR. Mais uma vez, o prazo de criação do dispositivo foi afetado, pois foi necessário aplicar mais esforços sobre a nova versão da placa, fazer orçamento e contratar uma empresa para confeccioná-la. Observou-se uma variação de mais de 100% entre os preços dos serviços realizados por diferentes empresas. Além disso, algumas empresas não trabalhavam com o grau de precisão das trilhas e vias aplicadas no hardware devido ao espaçamento entre pinos do integrado. Isso dificultou a seleção entre os fornecedores de PCI.
Quanto ao desenvolvimento do SAR, os pontos negativos ficaram em torno da opção adotada na definição do gabinete não ter sido uma boa estratégia, pois foi obtida apenas uma amostra do gabinete utilizado no dispositivo, onde em pouco tempo, mas já com o hardware pronto, as hastes de sustentação interna da placa se romperam. Mesmo assim, não foram observadas grandes avarias no design externo do produto. O ponto positivo do servidor foi a abordagem empregada para o conector de
91
gravação do microcontrolador mostrando-se ser boa, se não essencial, durante o processo de desenvolvimento do firmware, reduzindo significativamente a necessidade de abrir e fechar o gabinete, o que poderia causar ainda mais danos no mesmo.
Quanto ao desenvolvimento do Controlador, as principais considerações estão em torno do hardware. Os pontos negativos estão principalmente na utilização de barras de pinos para a sustentação das placas e o posicionamento dos conectores da rede CAN nas laterais do dispositivo. Se considerado que não será realizada manutenção no Controlador com frequência, o inconveniente das barras de pino torna-se insignificante, pois no momento em que é realizada a manutenção, e o dispositivo é retirado e colocado na caixa de energia elétrica 4x2, as placas Controle e Analog se soltam com facilidade. Estima-se que aplicando um suporte plástico entre as placas, reduziria a possibilidade das placas se desprenderem na manutenção. Avalia-se que os conectores CAN seriam melhor posicionados, para manutenção do dispositivo, se aplicados de forma a ficarem com os conectores direcionados para a área embutida ao fundo da caixa, diferente da direção lateral assumida no hardware. Os pontos positivos no dispositivo estão nas estratégias aplicadas para o hardware e o firmware. O hardware modular permitiu que as placas fossem modularizadas de acordo com sua funcionalidade. No caso de substituição de uma placa as outras poderiam continuar sendo aproveitadas. Quanto ao firmware, o tratamento das interrupções mostrou-se mais eficiente quando aplicado da forma como foi apresentado no trabalho, se comparado ao tratamento da interrupção realizada na própria função de interrupção.
Outro detalhe que poderia ser melhorado no projeto é a utilização de conectores RJ12 para o padrão de conectividade CAN. Estima-se que a instalação do sistema em uma residência seria mais intuitiva, principalmente para técnicos experientes, se fossem utilizados conectores RJ45, seguindo o padrão de conectividade da rede IP. Porém, propositalmente, não foi utilizado esse padrão para a rede CAN, pois poderia induzir ao erro na conexão do dispositivo com a rede CAN, possibilitando que o mesmo fosse danificado.
Em geral, os dispositivos comportaram-se muito bem nos testes realizados. Algumas melhorias podem ser implementadas
92
nos detalhes dos dispositivos, porém as funcionalidades principais do sistema DroidLar já estão bem atendidas.
5.1 TRABALHOS FUTUROS
As sugestões de trabalhos futuros no tema são: Desenvolver novas funcionalidades no SAR, como
controle de persianas, e controle de acesso e programação de tarefas;
Desenvolver novos Controladores para o sistema DroidLar;
Desenvolver um novo software para plataforma Android.
Migrar o sistema DroidLar para outras plataformas, como iPhone.
93
6 REFERÊNCIAS BIBLIOGRÁFICAS
ARDUINO. Disponível em <http://www.arduino.cc>. Acesso em 22 nov. 2013. AURESIDE. Conceitos Básicos, 2013. Disponível em <http:// www.aureside.org.br/temastec/default.asp?file=concbasicos.asp&menu=temas>. Acesso em 15 nov. 2013. _________. Protocolos e Grupos de Trabalho, 2013. Disponível em <www.aureside.org.br/temastec/default.asp?file= protocolos.asp&menu=temas>. Acesso em 15 nov. 2013. AUTOMATIC HOUSE. O que é automação residencial, 2013. Disponível em <http://www.automatichouse.com.br/AutomaticHo use/WebSite/Automacao/Residencial.aspx>. Acesso em 4 mar. 2013. BOLZANI, C. A. M. Residências Inteligentes. 1ª. ed. São Paulo: Livraria da Física, 2004. EUZÉBIO, M. V. D. M. DroidLar - Automação residencial através de um celular Android. IFSC. São José, p. 58. 2011. GLOBAL CACHÉ. Global Caché IP. WiFi. PoE. IR. Serial. Contact Closure, 2013. Disponível em <http://www.globalcache. com>. Acesso em 22 abr. 2013. GUIMARÃES, A. D. A.; SARAIVA, A. M. O Protocolo CAN: Entendendo e Implementando uma Rede de Comunicação Serial de Dados baseada no Barramento “Controller Area Network”. Universidade de São Paulo. São Paulo, p. 10. 2002. IEEE. Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs). IEEE Computer Society. New York, p. 323. 2006.
94
LOXONE. Automação residencial, casa inteligente, controle de iluminação, temperatura e cortina - Loxone, 2013. Disponível em <http://www.loxone.com.br>. Acesso em 21 abr. 2013. MICROCHIP. MCP2551 Datasheet. Microchip Technology Inc. Chandler. 2003. __________. MCP2515 datasheet. Microchip Technology Inc. Chandler. 2005. PRUDENTE, F. Automação Predial e Residencial - Uma Introdução. Rio de Janeiro: LTC, 2011. SHOWSEG. Caixa de Cabo Par Trançado 4 vias. ShowSeg, 2013. Disponível em <http://www.showseg.com.br>. Acesso em 10 nov. 2013. TECPAR. Mercado de automação residencial dá sinais de crescimento. Instituto de Tecnologia do Paraná, 2011. Disponível em <http://portal.tecpar.br/index.php/pt/noticias/1781-mercado-de-automacao-residencial-da-sinais-de-crescimento>. Acesso em 21 abr. 2013. TERRA. Automação residencial traz conforto, segurança e economia. Casa e Decoração, 2012. Disponível em <http://vida eestilo.terra.com.br/casa-e-decoracao/automacao-residencial-traz-conforto-seguranca-e-economia,3f3c317062597310VgnVCM 20000099cceb0aRCRD.html>. Acesso em 21 abr. 2013. UNDER-LINUX.ORG. Tecnologia de Redes, Mobilidade e Inovação, 2009. Disponível em <https://under-linux.org/entry. php?b=1134>. Acesso em 21 nov. 2013. VEJA SP. Casas Inteligentes são a Ultima Tendência. Decoração, São Paulo, 31 ago. 2005.
XBEESTORE. ZigBee, Módulo XBee : XBeeStore, 2013. Disponível em <http://www.xbeestore.com.br >. Acesso em 10 nov. 2013.