TCC de Redes Servidos Web

UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR

CURSO DE ENGENHARIA DE COMPUTAÇÃO
DESENVOLVIMENTO DE UMA APLICAÇÃO DE AUTOMAÇÃO

RESIDENCIAL CONTROLADA VIA WEB
USANDO O PADRÃO DECT
Guilherme Souza
Walter Gontijo, M. Eng.

Orientador
São José, Novembro / 2013

ii
UNIVERSIDADE DO VALE DO ITAJAÍ

CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE ENGENHARIA DE COMPUTAÇÃO
DESENVOLVIMENTO DE UMA APLICAÇÃO DE AUTOMAÇÃO

RESIDENCIAL CONTROLADA VIA WEB
USANDO O PADRÃO DECT
Guilherme Souza
São José, Novembro / 2013
Orientador: Walter Gontijo, M. Eng.

Co-orientador: Fernando Barboza da Costa, Eng.
Área de Concentração: Automação Residencial / Domótica.
Linha de Pesquisa: Automação residencial utilizando tecnologia sem fio.
Palavras-chave: Automação residencial, Domótica, WEB Server, Sistema Embarcado, DECT.
Número de páginas: 97
iii
Dedico este trabalho à minha família, que junto comigo

sofreram e comemoraram, sorriram e choraram em
cada obstáculo e suas respectivas conquistas durante
essa caminhada.
iv
AGRADECIMENTOS
Gostaria de agradecer primeiramente ao Senhor DEUS, que em resposta às minhas preces deu-
me forças para finalizar este trabalho.
À minha esposa Raquel Maura Goulart, por sua incrível compreensão nos meus momentos em
que tive ausente e também pelas diversas vezes que me incentivou a persistir na continuidade e na
melhoria deste trabalho. Obrigado Amor!
Aos meus pais Marilene Souza e Evaldo Luiz de Souza, que assim como minha esposa, tiveram
grande compreensão com minha ausência durante o período deste TCC e, como sempre, não mediram
esforços para me auxiliar durante toda minha jornada acadêmica. Muito obrigado Pai e Mãe!
Ao amigo Fernando Barboza da Costa pelas horas de dedicação, atenção, incentivo e paciência,
tirando dúvidas e me orientando durante todo o desenvolvimento deste TCC. Muito obrigado!
Ao amigo Helton Luiz Marques por ter compartilhando seu conhecimento com minha pessoa.
Isto tornou possível a concepção deste TCC. Muito Obrigado!
Ao professor e orientador Walter Gontijo por suas correções e orientações durante o

desenvolvimento deste TCC. O meu muito obrigado!
À professora Anita da Rocha Fernandes por sua dedicação e paciência durante as correções
deste TCC. Muito Obrigado!
À empresa Intelbras, representada pelo Sr. Diego José Serra, que permitiu a abordagem de um
produto de seu portfólio neste trabalho.
v
RESUMO
A automação residencial, também conhecida como Domótica, é uma área da tecnologia cujo
objetivo é o controle de sistemas e equipamentos residenciais através do uso de uma rede de dados. Em
plena fase de expansão no Brasil, o mercado de automação residencial possui um crescimento cerca de
35% ao ano, porém, as soluções de automação disponíveis no mercado hoje são de alto custo e
possuem alta complexidade de instalação, o que eleva a dificuldade de disseminação desses sistemas
na sociedade. Este trabalho apresenta uma aplicação do padrão DECT em sistemas de automação
residencial controlada por uma interface WEB. O padrão DECT é um sistema de comunicação sem fio
digital capaz de transportar dados em distâncias de até 500 metros e é largamente utilizado em
comunicação sem fio residencial atualmente. O intuito de se utilizar esse padrão para automação de
uma residência é fazer uso do alcance de seu rádio comunicador para tornar mais fácil e centralizada a
instalação dos sistemas de automação em residências já consolidadas sem que haja grandes adaptações,
possibilitando assim, a difusão da automação residencial para a sociedade. O sistema proposto neste
trabalho é composto por uma estação base e até cinco estações móveis. A estação base possui acesso à
rede de dados local (Ethernet) por onde será disponibilizado ao usuário o acesso à interface WEB de
controle. Através desta interface, é possível controlar o comportamento das estações móveis, que estão
conectadas com a estação base através do uso do protocolo DECT e executam os comandos recebidos
pela estação base a fim de se obter o controle de equipamentos e/ou sistemas residenciais. Para
desenvolver esta aplicação foi realizada nesse trabalho uma revisão bibliográfica do padrão DECT,
servidores WEB, sistemas embarcados, protocolos de comunicação, bem como, um detalhamento da
estrutura e aplicações das estações base e móveis. Posteriormente, foi criada a interface de controle
WEB, o protocolo de comunicação entre as estações, adaptações no servidor WEB, bem como nas
bibliotecas utilizadas, e por fim, foram realizados testes de verificação de funcionamento e a
documentação de todo o desenvolvimento.
vi
ABSTRACT
Home automation, also known as Domotics, is an area of technology with aims to control
residential systems and equipment by using a data network. The home automation market is outgrowth
in a rate of 35% per year, however, the solutions available in the market nowadays are expensive and it
has a high complexity level of installation hampering dissemination of these systems to the society.
This academic work objectives the application of the DECT standard in home automation systems
controlled by the WEB. The DECT standard is a wireless communication system able to transport data
within distances of 500 meter and it is mainly used as a solution of a wireless residential
telecommunications sets. The intention of use this standard in a home automation system is to turn
easier and centered the installation to ever built residences without big modifications necessity in tis
structures, making possible the diffusion of the home automation system to the society. The system
proposed by this work is composed by a base station and till five mobile stations. The base station has
access the local network (Ethernet), which provides to the user the access to the WEB control
interface. By using this interface is possible to control the behavior of the mobile stations that are
connected to the base station through the DECT standard protocol and it performs the commands
received by the base station to obtain the control of the residential systems or equipment`s. To develop
this application was used in this work a literature review of DECT standard, WEB servers,
communications protocols, and also a detailing of the structures and applications of the base and
mobile stations. Afterwards, it was created the WEB control interface and also the communication
protocol between the stations, the adaptation of the WEB server functions to reach the home
automation proposal, and at the end, was performed tests and operation checking as well as the
documentation of whole development.
vii
LISTA DE FIGURAS
Figura 1 - Esquema de conexão entre as estações EB e EM’s. .......................................................... 11

Figura 2 - Topologia de ligação automação residencial .................................................................... 17
Figura 3 - Arquitetura e dispositivos do sistema Habeetat ................................................................ 19
Figura 4 - Arquitetura e dispositivos da Cybertronics ....................................................................... 20
Figura 5 - Exemplo de um sistema DECT ......................................................................................... 21
Figura 6 - Distribuição das camadas do protocolo DECT ................................................................. 22
Figura 7 - Comparativo das camadas do modelo OSI e do padrão DECT. ....................................... 22
Figura 8 - Camada física. ................................................................................................................... 24
Figura 9 – Canalização do padrão DECT utilizada no Brasil. ........................................................... 24
Figura 10 – Canalização do padrão DECT. ....................................................................................... 25
Figura 11 – Sequência de processamento da camada DLC ............................................................... 26
Figura 12 - A sinalização entre as camadas do padrão DECT. .......................................................... 27
Figura 13 - Hardware componente da EB.......................................................................................... 29
Figura 14 - Detalhamento de aplicações da EB ................................................................................. 30
Figura 15 – Hardware componente da EM. ....................................................................................... 33
Figura 16 – Detalhamento das aplicações da EM. ............................................................................. 33
Figura 17 - Arquitetura do sistema de automação. ............................................................................ 38
Figura 18 – Arquitetura do sistema de automação............................................................................. 39
Figura 19 - Arquitetura do sistema de automação ............................................................................. 40
Figura 20 - Visão geral do sistema de automação residencial. .......................................................... 43
Figura 21 - Diagrama de casos de uso ............................................................................................... 46
Figura 22 - Detalhamento da EM....................................................................................................... 53
Figura 23 – Foto do hardware da EM. ............................................................................................... 53
Figura 24 - Foto da EM para emular as funções de abertura e fechamento. ...................................... 54
Figura 25 - EM atuador. ..................................................................................................................... 55
Figura 26 - Circuito de interface de acionamento.............................................................................. 55
Figura 27 - Foto hardware da EB....................................................................................................... 56
Figura 28 - Detalhamento da EB........................................................................................................ 57
Figura 29 - Esquema de Interligação do Kernel. ............................................................................... 58
Figura 30 – Página de autenticação.................................................................................................... 59
Figura 31 – Página principal de configuração das EMs (1 a 5). ........................................................ 60
Figura 32 - Página de controle EM1 .................................................................................................. 61
Figura 33 – Página de configurações do sistema ............................................................................... 63
Figura 34 - Fluxo principal do servidor WEB. .................................................................................. 65
Figura 35 - Exemplo requisição AJAX GET ..................................................................................... 66
Figura 36 - Exemplo de requisição AJAX POST .............................................................................. 66
Figura 37- Fluxo de acesso à AJAX_APP através de in_set_ST. ...................................................... 68
Figura 38 - Fluxo de acesso à AJAX_APP através de out_get_ST. .................................................. 68
Figura 39 - Arquivo XML de configuração das EMs ........................................................................ 70
Figura 40 - Arquivo XML de agendamento das EMs........................................................................ 71
Figura 41 - Estrutura has_comm_orig_e............................................................................................ 72
Figura 42 - Estrutura has_station_index_e ........................................................................................ 73
Figura 43 - Estrutura has_event_type_e............................................................................................. 73
Figura 44 - Estrutura has_event_inf_e ............................................................................................... 73
viii
Figura 45 - Estrutura has_event_code_e ............................................................................................ 74

Figura 46 - Estrutura has_info_t. ....................................................................................................... 74
Figura 47- Fluxo da aplicação AARLL. ............................................................................................ 75
Figura 48 - Fluxo da aplicação AARLD_EB..................................................................................... 76
Figura 49 - Fluxo da aplicação AARLD_EM .................................................................................... 77
Figura 50 – Fluxo de envio de comando EB > EM ........................................................................... 79
Figura 51 - Fluxo de atualização de mensagem de status EM > EB. ................................................. 79
Figura 52 - Cenário de testes.............................................................................................................. 81
Figura 53- Tela número IP ................................................................................................................. 82
Figura 54 - Confirmação de envio. .................................................................................................... 82
Figura 55 – Acionamento da carga na EM 1. .................................................................................... 83
Figura 56 - Mensagem de status “Ligar”. .......................................................................................... 83
Figura 57 - Mensagem de status "Desligar"....................................................................................... 83
Figura 58 - Botões com eventos simulados. ...................................................................................... 84
Figura 59 - Status monitoramento "Bateria Baixa" ........................................................................... 84
Figura 60 - Status monitoramento "Abertura" ................................................................................... 84
Figura 61 - Status monitoramento "Fechado". ................................................................................... 85
Figura 62 - Configuração data e hora................................................................................................. 85
Figura 63 – Confirmação de envio..................................................................................................... 85
Figura 64 - Configurações "Agendamento de Controles" ................................................................. 86
Figura 65 - EM1 Status de Controles Agendados.............................................................................. 86
Figura 67 - Configurações “Dados da EM". ...................................................................................... 86
Figura 68 - Informações parâmetros. ................................................................................................. 87
Figura 69- Serviços Disponíveis. ....................................................................................................... 87
Figura 70 - Configurações "Trocar Senha". ....................................................................................... 87
Figura 71 – Confirmação de envio de nova senha. ............................................................................ 88
ix
LISTA DE TABELAS
Tabela 1 - Eventos do protocolo Contact ID referentes ao campo XYZ. .......................................... 37

Tabela 2 - Requisitos Funcionais do Sistema de Automação ............................................................ 44
Tabela 3 - Requisitos Não Funcionais do Sistema de Automação .................................................... 45
Tabela 4 - Regras de Negócio do Sistema de Automação ................................................................. 45
Tabela 5 - Descrição do Case de uso USC 01 ................................................................................... 47
Tabela 10 - Descrição do Case de uso USC 06 ................................................................................. 48
Tabela 16 - Detalhamento do Caso de uso USC 12. .......................................................................... 50
Tabela 17 - Detalhamento do Caso de uso USC 13 ........................................................................... 51
Tabela 18 - Descrição dos eventos simulados a EM.......................................................................... 54
x
LISTA DE ABREVIATURAS E SIGLAS
AARLD Aplicação Automação Residencial Lado DECT

AARLL Aplicação Automação Residencial Lado Linux
ADSL Asymmetric Digital Subscriber Line
ARM Acorn Risc Machine
C- PLANE Control Plane
CAN Controller Area Network
CEBus Consumer Electronics Bus
CRC Cyclic Redundancy Check
DLC Data Link Control Layer
DTMF Dual Tone Multi Frequency
EB Estação Base
ECTEL European Conference on Technology Enhanced Learning
EEPROM Electrically-Erasable Programmable Read-Only Memory
EM Estação Móvel
EMs Estações Móveis
ETSI European Telecommunications Standards Institute
GFSK Gaussian Frequency Shift Keying
GSM Global System for Mobile Communications
HANDSET Unidade móvel do telefone
HTML Hypertext Mark-up Language
HTTP Hyper Text Transfer Protocol
I²C Inter-Integrated Circuit
IP Internet Protocol
IWU Interworking Unit
LLME Lower Layer Management Entity
MAC Medium Access Control Layer
NWK Network
PHL Physical Layer
SDRAM Synchronous Dynamic Random Access Memory
SIA Security Industry Association
TCC Trabalho de Conclusão de Curso
TCP Transmission Control Protocol
TDD Time Division Duplexing
TDMA Time Division Multiple Access
UNIVALI Universidade do Vale do Itajaí
U-PLANE User Plane
WAN Wide Area Network
8
SUMÁRIO
1. INTRODUÇÃO ........................................................................................ 10
1.1 PROBLEMA DE PESQUISA .................................................................... 10
1.1.1 Solução Proposta ...................................................................................... 11
1.1.2 Delimitação de Escopo .............................................................................. 11
1.1.3 Justificativa .............................................................................................. 12
1.2 OBJETIVOS .............................................................................................. 12
1.2.1 Objetivo Geral .......................................................................................... 12
1.2.2 Objetivos Específicos ................................................................................ 12
1.3 METODOLOGIA .................................................................................. 13
1.3.1 Metodologia da Pesquisa .......................................................................... 13
1.3.2 Procedimentos Metodológicos .................................................................. 14
2 FUNDAMENTAÇÃO TEÓRICA ........................................................ 15
2.1 AUTOMAÇÃO RESIDENCIAL................................................................ 15
2.1.1 Topologia do Sistema de Automação Residencial...................................... 16
2.1.2 Sistemas de Automação Residencial .......................................................... 18
2.2 O PADRÃO DECT..................................................................................... 20
2.2.1 Características do padrão DECT ............................................................. 21
2.2.2 A Camada Física (PHL – Physical layer) ................................................. 23
2.2.3 A Camada de Acesso à Mídia (MAC - Medium Access Control) ............... 25
2.2.4 A Camada Link de Dados (DLC - Data Link Control)............................. 26
2.2.5 A Camada de rede (NWK - Networking) ................................................. 27
2.2.6 Código De Identificação............................................................................ 28
2.2.7 Registros De Dispositivos Dect .................................................................. 28
2.3 ESTAÇÃO BASE (EB)............................................................................... 29
2.3.1 Detalhamento Da Estação Base (EB) ......................................................... 30
2.3.2 Servidor WEB .......................................................................................... 31
2.3.3 AARLL e AARLD .................................................................................... 32
2.4 ESTAÇÃO MÓVEL (EM) ......................................................................... 32
2.4.1 Detalhamento Da Estação Móvel (EM) .................................................... 33
2.5 PROTOCOLO DE COMUNICAÇÃO DAS ESTAÇÕES............. 34
2.5.1 O Protocolo Contact ID ............................................................................. 35
2.5.2 Classificação Dos Eventos ......................................................................... 37
2.5.3 Considerações ............................................................................................ 37
3 TRABALHOS RELACIONADOS ....................................................... 38
3.1 IMPLEMENTAÇÃO DE UM SISTEMA DE AUTOMAÇÃO RESIDENCIAL
MODULAR........................................................................................................ 38
3.2 SISTEMA PARA CONTROLE E SUPERVISÃO REMOTA PARA
AUTOMAÇÃO RESIDENCIAL ....................................................................... 39
9
3.3 INTERFACE HOMEM-MÁQUINA PARA A DOMÓTICA BASEADA EM

TECNOLOGIAS WEB EM UM SERVIDOR EMBARCADO ......................... 40
3.4 ANÁLISE COMPARATIVA ..................................................................... 41
4 Desenvolvimento ....................................................................................... 43
4.1 VISÃO GERAL DO SISTEMA ................................................................. 43
4.2 ANÁLISE DE REQUISITOS..................................................................... 44
4.3 MODELAGEM DO SISTEMA.................................................................. 45
4.3.1 Casos De Uso.............................................................................................. 45
4.3.2 Descrição Dos Casos De Uso ...................................................................... 46
4.4 DETALHAMENTO DO DESENVOLVIMENTO ..................................... 52
4.4.1 Visão Geral Da Plataforma........................................................................ 52
4.4.1.1 EM .......................................................................................................... 52
4.4.1.2 EB ........................................................................................................... 56
4.4.2 Interface De Controle WEB....................................................................... 59
4.4.2.1 Página De Login ..................................................................................... 59
4.4.2.2 Página Principal De Controle ................................................................. 60
4.4.3 Servidor Web E Ajax................................................................................. 64
4.4.4 Implementação Das Funções Auxiliares AJAX APP ................................. 68
4.4.5 XML Database ........................................................................................... 69
4.5 IMPLEMENTAÇÃO DO PROTOCOLO.................................................. 72
4.5.1 A Estrutura HAS_INFO_T........................................................................ 72
4.6 IMPLEMENTAÇÃO DAS FUNÇÕES AARLL E AARLD....................... 74
4.7 DIAGRAMA DE SEQUENCIA DO SISTEMA DE AUTOMAÇÃO......... 78
5 DESCRIÇÃO DOS EXPERIMENTOS............................................... 81
5.1.1 Execução Dos Testes .................................................................................. 81
5. CONCLUSÕES ........................................................................................ 89
5.1. TRABALHOS FUTUROS.................................................................... 91
REFERÊNCIAS BIBLIOGRÁFICAS ...................................................... 92
10
1. INTRODUÇÃO
Automação pode ser definida como a operação ou controle automático de um equipamento,
processo ou sistema (OXFORD, 2013). A automação pode ser utilizada tanto para equipamentos e
sistemas industriais, bem como, para equipamentos e sistemas de uma residência. Quando aplicada em
uma residência denomina-se automação residencial.
As primeiras aplicações de automação residencial ocorreram na década de 20 nos Estados
Unidos com o surgimento dos primeiros eletrodomésticos (AURESIDE, 2007). Quase cem anos depois
surge a possibilidade de controle e monitoramento destes equipamentos através de uma rede de dados.
Nos anos de 2008 a 2011, o mercado de automação residencial vem crescendo a uma média de
35% ao ano em número de projetos no Brasil (MINORU, 2011). Segundo pesquisa feita pela CISCO
(2011), existe uma estimativa que até 2015 haverá mais de 1,5 bilhões de conexões máquina-máquina,
isto mostra o crescimento de dispositivos interconectados a outros dispositivos (Internet of things),
dispositivos que se assemelham aos utilizados na automação residencial.
Segundo Minoru (2011), a solução utilizada na automação residencial ainda é bastante
concentrada em soluções por cabo, dificultando sua difusão e instalação. Com a tendência de
crescimento deste mercado, as soluções precisam ser cada vez mais funcionais para que seja possível a
instalação na maioria dos ambientes (MINORU, 2011).
Tendo conhecimento da tendência de crescimento deste mercado e a dificuldade de instalação
por cabos dos sistemas atuais, fica clara a oportunidade de desenvolvimento de um sistema de
automação residencial sem fio em que não exija a necessidade de adaptação da residência para a
interligação dos sensores e atuadores, aliado a facilidade da residência ser controlada via interface
WEB, local ou remotamente, dependendo da disposição da rede de dados em que o sistema de
automação estiver submetido, cujo tema é o objetivo deste trabalho.
1.1 PROBLEMA DE PESQUISA

O crescimento previsto para o ramo de automação residencial está diretamente relacionado ao
custo e a facilidade de instalação que o sistema oferece, ou seja, quanto menor for o custo e mais fácil
for a instalação, maior será o número de usuários do sistema.
Um dos fatores que inibe a utilização dos sistemas atuais de automação residencial é a
dificuldade de modificar a infraestrutura das residências para a instalação desse sistema de automação.
Segundo Minoru (2011), é necessário que as soluções atuais sejam simplificadas quanto a sua
11
instalação, dificuldade está que será o problema principal a ser tratado neste TCC (Trabalho de
Conclusão de Curso).
1.1.1 Solução Proposta
Este trabalho apresenta o desenvolvimento de um sistema de automação residencial utilizando

tecnologia sem fio DECT, que contém módulos atuadores e de controle que se comunicam sem a
necessidade de interconexão por cabos, facilitando a instalação de tal sistema.
1.1.2 Delimitação de Escopo
O sistema de automação residencial proposto neste trabalho é composto por uma estação
mestre, chamada de Estação Base (EB), e por duas estações escravas, chamadas de Estações Móveis
(EM), que se comunicam utilizando o padrão DECT.
A EB é responsável pelo gerenciamento das unidades EMs, bem como, pelo armazenamento de
dados coletados por elas. As EMs por sua vez, são responsáveis pela aquisição dos dados e execução
dos comandos recebidos da EB. Para que seja possível o controle das unidades será necessária a
definição de um protocolo de comunicação entre a EB e as EMs.
A EB é controlada pelo sistema operacional Linux e possui um servidor WEB embarcado para
disponibilizar acesso através de navegadores de internet. O acesso à EB é realizado por uma porta de
acesso do padrão Ethernet, denominada WAN (Wide Area Network). Esta porta quando conectada a
um modem roteador recebe um endereço IP (Internet Protocol) para identificação da EB dentro de
uma rede de computadores, conforme mostrado na Figura 1. Através deste endereço IP é possível
acessar a EB para monitorar e executar o controle das operações das EMs.
Figura 1 - Esquema de conexão entre as estações EB e EM’s.

12
O sistema mostrado na Figura 1 contém uma estação EB, identificada pelo IP 10.0.0.2, e uma
estação móvel EM1, que faz a interface com os eletrodomésticos. A EB pode ser acessada através de
navegadores de internet disponíveis no mercado (tais como: Mozilla Firefox ou Google Chrome)
através do endereço IP a ela associado.
1.1.3 Justificativa
A evolução da tecnologia trouxe mudanças irreversíveis na vida, no cotidiano, no trabalho e nas
casas das pessoas tornando onipresente a tecnologia e a informação na sociedade como um todo. A
automação residencial, seguindo essa linha de evolução, torna possível a automatização das residências
através do uso da tecnologia, porém, o custo e as dificuldades de instalação nas residências ainda são
elevados, o que dificulta a difusão da automação residencial na sociedade.
Para aumentar a difusão do sistema de automação residencial, é necessário que sua instalação
seja realizada sem a necessidade de adaptação das residências, tornando-o mais fácil e mais acessível.
Dessa forma, o projeto proposto por este trabalho visa facilitar a instalação do sistema de
automação residencial, através do uso da tecnologia sem fio, eximindo-o da obrigatoriedade de
adaptação da residência para realizar interconexões de atuadores ou controladores à central de controle
principal.
1.2 OBJETIVOS
Esta seção formaliza os objetivos do trabalho, conforme descrito a seguir.
1.2.1 Objetivo Geral

Desenvolver uma aplicação de automação residencial controlada via interface WEB utilizando
o padrão DECT.
1.2.2 Objetivos Específicos

Para atender o objetivo geral proposto neste trabalho os seguintes objetivos específicos foram
definidos:
13
1. Apresentar o padrão DECT;

2. Definir o protocolo de comunicação entre a EB a as EMs;
3. Desenvolver a interface de controle WEB da EB;
4. Implementar o protocolo de troca de mensagens entre a EB e a EM;
5. Integrar sensores / atuadores nas EMs;
6. Testar o sistema desenvolvido; e
7. Documentar o desenvolvimento.
1.3 METODOLOGIA
Todo conteúdo deste trabalho está dividido em duas etapas, são elas: fundamentação teórica e
revisão de bibliografia na primeira etapa, e o desenvolvimento deste trabalho na segunda etapa.
1.3.1 Metodologia da Pesquisa

Método científico é o conjunto de processos ou operações mentais que se devem empregar a
investigação, ou seja, a linha de raciocínio adotada no processo de pesquisa. Os métodos que fornecem
a base lógica à investigação são: dedutivo, indutivo, hipotético-dedutivo, dialético e fenomenológico
(SILVA; MENEZES, 2005).
De acordo com Silva e Menezes (2005), o método hipotético-dedutivo é observado quando o

conhecimento disponível sobre determinado assunto é insuficiente para explicar um fenômeno, dando
surgimento então para o problema e suas dificuldades. Para as dificuldades encontradas no problema
são levantadas as hipóteses, partindo-se de uma teoria mais abrangente para um problema específico.
Com base nesse conceito, pode-se afirmar que neste trabalho será utilizado o método hipotético-
dedutivo, pois seu desenvolvimento está baseado em uma teoria geral abordando um problema
específico da automação residencial.
Quanto à natureza da pesquisa, este trabalho classifica-se como pesquisa aplicada, já que seu
objetivo é gerar conhecimento a partir de problemas específicos destinados à aplicação prática.
A forma de abordagem do problema adotada neste trabalho pode ser caracterizada como
pesquisa qualitativa, pois de acordo com Silva e Menezes (2005), a pesquisa qualitativa considera que
o processo e seu significado são os focos principais de abordagem e não requerem o uso de métodos e
técnicas estatísticas. Os resultados a serem apresentados deste trabalho expõem uma análise descritiva
de acordo com uma proposta pré-definida.
14
Os objetivos desta pesquisa podem ser classificados em Exploratório e Explicativo.

Exploratório, pois essa pesquisa envolve levantamento bibliográfico e o estudo de artigos técnicos. O
resultado desta pesquisa será obtido através de métodos e técnicas exploratórias visando elucidar uma
situação problemática previamente conhecida. Explicativo, pelo fato de que serão necessárias
modelagens e simulações a serem expostos futuramente.
1.3.2 Procedimentos Metodológicos

De acordo com Gil (2008), uma pesquisa bibliográfica é baseada em material já publicado
constituído principalmente de livros, artigos de periódicos e atualmente com material disponibilizado
na Internet.
Visando o cumprimento dos objetivos específicos de 1 a 3 deste TCC, foi realizada uma
pesquisa bibliográfica para fundamentação teórica. Já para os objetivos de 4 a 6 foi utilizada a pesquisa
experimental, dado que, nestas etapas foi confeccionado um protótipo funcional com as características
levantadas pela pesquisa bibliográfica exposta na fundamentação teórica deste trabalho.
15
2 FUNDAMENTAÇÃO TEÓRICA
Neste Capítulo será apresentada uma revisão bibliográfica que aborda o padrão DECT,
conceitos sobre a estação base e estação móvel, protocolos de comunicação, servidor WEB e
classificações de automação residencial.
Inicialmente é apresenta a definição de automação residencial, suas classificações, topologia
dos sistemas de automação e posteriormente alguns sistemas comerciais de automação residencial são
detalhados.
Na sequência são apresentados o padrão DECT e sua estrutura de funcionamento básico
Detalhamento da Estação Base (EB), uma breve revisão no conceito de sistemas embarcados e o
conceito de servidor WEB, além do conceito de Estação Móvel (EM) e das aplicações específicas para
o contexto de automação residencial.
Uma revisão conceitual de protocolos de comunicação, bem como a apresentação do protocolo
Contact ID, sua estrutura e classificação dos eventos voltados para automação residencial são
apresentadas na sequência.
2.1 AUTOMAÇÃO RESIDENCIAL
A automação residencial, também conhecida como Domótica, é o uso da tecnologia para o

controle de equipamentos e sistemas de uma residência, interligados por uma rede de dados
(MURATORI; DAL BÓ, 2007). Inicialmente, a automação residencial é percebida pelo usuário como
um símbolo de status e modernidade. No momento seguinte, o conforto e a conveniência por ela
proporcionados passam a ser decisivos. E, no decorrer dos anos a automação se tornará uma
necessidade e um fator de economia (AURESIDE, 2013). Seu principal objetivo é facilitar o controle
dos equipamentos e sistemas residenciais, tais como: sistemas de segurança, equipamentos de
comunicação, equipamentos de áudio e vídeo, ou ainda, o controle de ligar e desligar equipamentos
e/ou eletrodomésticos.
A falta de padronização na comunicação dos equipamentos e sistemas residenciais existentes
torna difícil a integração entre sistemas distintos, não permitindo um controle total e centralizado. A
automação residencial vem com o propósito de interligação desses equipamentos por uma rede de
dados a um concentrador de informações, tornando possível ao usuário realizar programações
personalizadas voltadas para seu cotidiano, bem como o controle destes sistemas em uma interface
unificada.
16
Segundo AURESIDE (2013) existem três níveis de integração para um sistema de automação
residencial que os classificam de acordo com sua capacidade de integração, são eles:
a) Sistemas Autônomos:
Classificam-se neste nível os sistemas de automação que realizam um controle (através de uma
pré-programação) mais básico como, por exemplo, ligar ou desligar um equipamento ou subsistema
residencial. Porem, este tipo de sistema não mantém nenhuma integração com outros dispositivos ou
módulos de automação.
b) Sistemas Integrados:
Nessa classificação o sistema de automação é capaz de controlar múltiplos subsistemas a partir
de um único controlador central. O principal foco desse nível é garantir a integração com os diversos
equipamentos através de uma interface única de controle, oferecendo usabilidade ao usuário e uma
grande e utilização dos recursos oferecidos pelos equipamentos.
c) Residência Inteligente:
Os sistemas de automação são personalizados de acordo com a necessidade do proprietário, que
juntamente com o profissional da área da automação residencial, irá modificar o sistema de automação
tornando-o um gerenciador ao invés de um controlador remoto. Esses sistemas contam ainda com uma
comunicação de duplo sentido e feedback de status entre todos os módulos.
2.1.1 Topologia do Sistema De Automação Residencial
Com a necessidade de utilização de uma rede de dados para interação e comunicação com os
sistemas de automação residencial, surge também a necessidade de se utilizar uma topologia entre eles.
A mais utilizada em sistemas de automação hoje é a topologia estrela conforme mostra a Figura 2 (a).
Esta topologia é também a mais utilizada pelas redes de computadores (MARIN, 2002).
17
Figura 2 - Topologia de ligação automação residencial

Fonte: Adaptado de Marin (2002).
Anel:
A Figura 2 (c) mostra a topologia em anel possui um desenho lógico antigo, utilizada
geralmente em redes locais de longa distância. A comunicação proporcionada pela rede na topologia
anel é considerada um conjunto de estações conectadas umas-as-outras formando um círculo e não
propriamente uma rede de difusão. Isto se deve ao fato de que a informação inserida na rede é copiada
para um buffer presente em cada interface de rede e depois essa informação é devolvida à rede
novamente (CERUTTI, 2000). Um dos maiores problemas da topologia em anel está relacionado com
a pouca tolerância a falhas proporcionada por esta, como por exemplo, a queda de toda a rede caso um
dos nós venha a deixar de funcionar, além de loops infinitos de mensagens que circulam na rede caso
haja um erro no processamento ou de transmissão (FOROUZAN, 2004).
Barramento:
Neste tipo de conexão todas as estações da rede estão interligadas a um mesmo cabo formando
um barramento conforme mostra a Figura 2 (b). A topologia em barramento tem uma configuração
multiponto, onde cada nó conectado à rede pode receber a informação transmitida, já que a informação
é enviada para todos nós (CERUTTI, 2000). A grande vantagem desta topologia é a facilidade de
instalação, já que é necessário apenas um cabo central compartilhado para todas as estações e para as
demais conexões é possível realiza-las através de pequenos segmentos. Porém, esse mesmo fato
ocasiona outros problemas presentes nesta topologia, como por exemplo, a interrupção da
comunicação de toda rede em caso de falhas em somente um nó (FOROUZAN, 2004).
18
Estrela:
As redes com topologia estrela são caracterizadas pela existência de um dispositivo central que
interconecta todos os nós presentes na rede, conforme mostra a Figura 2 (a). Em redes com topologia
em estrela é possível enviar e receber dados para qualquer outra estação da rede através do dispositivo
concentrador. O dispositivo concentrador, neste caso, age como elemento intermediador, pois o dado
será enviado a ele e posteriormente será replicado para a estação destino.
As vantagens de utilização desta topologia giram em torno da robustez e da flexibilidade que o
sistema oferece, pois caso um nó falhar ou for desconectado, os demais não serão comprometidos,
diferentemente das anteriores (FOROUZAN, 2004).
A topologia barramento (b) e anel (c) também são bastante utilizadas em arquiteturas de
sistemas de automação, porém, a topologia estrela é a mais utilizada por ser a mais flexível permitindo
a implementação de uma sub-rede no formato anel ou barramento dentro de uma rede estrela, caso seja
necessário.
2.1.2 Sistemas de Automação Residencial

Nesta seção serão apresentados alguns sistemas de automação residencial disponíveis no
mercado, similares ao proposto neste trabalho, bem como suas características e meios de acesso. Por se
tratar de sistemas com propriedade intelectual privada, o acesso a informações e documentações
funcionais do sistema é restrito.
O sistema de automação residencial Habeetat da empresa Solidmation é uma solução sem fio
que utiliza como base o padrão ZigBee (IEEE802.15.4). O sistema proporciona o acesso de diferentes
plataformas, através de dispositivos que suportam navegadores WEB, além de aplicativos específicos
para os sistemas operacionais Android e IOS. Ele é dividido em módulos específicos para cada
aplicação tais como o controle de iluminação, motores, jardins, câmeras, além de medidores de
consumo, entre outros, conforme mostra a Figura 3. (SOLIDMATION, 2013).
19
Figura 3 - Arquitetura e dispositivos do sistema Habeetat

Fonte: Solidmation (2013).
A Figura 3 mostra a arquitetura do sistema Habeetat interligada através de um centralizador

denominado Habeetat Planner. O sistema está disposto na topologia estrela e pode ser classificado
como um “Sistema integrado”.
Outra solução interessante para automação de uma residência é o UPB (Universal Power Line
Bus), da empresa Cybertronics. Uma solução modular é utiliza pelo o sistema UPB, onde, assim como
a anterior, módulos específicos executam um conjunto de tarefas (CYBERTRONICS, 2013).
A solução utilizada pela empresa Cybertronics é uma derivação da técnica de comunicação via
rede elétrica conhecida como PLC (Power Line Communications). Está técnica estabelece
comunicação entre os módulos através do envio da informação em uma faixa frequência (1 a 30 MHz)
muito superior ao utilizado pela rede elétrica (TEIXEIRA, 2005). Neste tipo de solução exime-se a
necessidade de passagem de cabos para se interligar aos demais módulos
A interface com o usuário é realizado através de módulos com botões, de computadores ou
tablets, porém não existe de forma clara a informação de como é realizado o controle do sistema
(CYBERTRONICS, 2013). Um esboço dos dispositivos disponíveis para este sistema pode ser visto na
Figura 4.
20
Figura 4 - Arquitetura e dispositivos da Cybertronics

Fonte: Cybertronics (2013)
A Figura 4 mostra a arquitetura do sistema de automação da Cybertronics disposta na topologia

barramento e pode ser classificado como um “Sistema Integrado”.
O sistema proposto por este trabalho é baseado na topologia estrela, pois possui uma unidade
principal que fará a comunicação com as demais unidades (sensores e atuadores) utilizando o
protocolo DECT e, quanto ao nível de integração, ele pode ser classificado como um “Sistema
Integrado”, por permitir interação e o controle dos equipamentos residenciais a partir de um
controlador central.
2.2 O PADRÃO DECT

Nesta subseção será mostrado o padrão de comunicação sem fio DECT sendo utilizada como
principal referência a bibliografia escrita por John Phillips e Gerard Mac Namee, reconhecida pela
ETSI e lançada em 1998.
O DECT é um padrão de comunicação sem fio digital de baixa potência utilizado para
transportar voz e dados em distâncias de até 500 metros em ambientes abertos (outdoor). As
especificações do padrão DECT muito se assemelham com a tecnologia GSM (Global System for
Mobile Communication) pelo método que a canalização que é realizada em ambas (ETSI, 2013).
21
O padrão DECT surgiu por volta de 1987, sendo inicialmente desenvolvido pela ECTEL
(European Conference on Technology Enhanced Learning) com a intenção de se tornar um padrão de
comunicação digital somente europeu, mas devido ao sucesso da tecnologia, foi posteriormente
adotado por muitos outros países do mundo (PHILLIPS; NAMEE, 1998 p.17). Hoje está presente em
73% dos telefones sem fio digital em todo mercado mundial (ETSI, 2013).
No Brasil o espectro de frequência deste padrão é de 1910 a 1920 MHz e é regulamentado pela
ANATEL (Agência Nacional de Telecomunicações) (ANATEL, 2013).
2.2.1 Características do padrão DECT

O sistema que utiliza o padrão DECT é dividido em duas partes, uma estação base e uma
estação móvel, conforme mostrado na Figura 5.
Figura 5 - Exemplo de um sistema DECT

Fonte: Adaptado de Philips e Namee (1998)
A Figura 5 mostra o exemplo de um sistema DECT, onde a EB está diretamente ligada à rede
local de dados através da interface de rede e também está conectada à EM através do padrão DECT.
Apesar do uso do padrão DECT ser principalmente difundido na rede de telefonia analógica
para a transmissão de voz, ele pode também ser utilizado para transmitir dados. Mas para isso, são
necessários diferentes tipos de camadas de interconexão que servirão de interface entre o padrão
DECT e a rede de dados desejada (PHILIPS; NAMEE, 1998).
A camada de interconexão não faz parte do padrão DECT, pois sua construção e operação
variam de acordo com a rede de dados a que esta conectada. Sua função principal é interpretar as
mensagens de controle recebidas da rede de dados e enviá-las para interface DECT, como por
exemplo, no uso de um telefone fixo residencial com o padrão DECT, a sinalização de desconexão de
linha será interpretada pela camada de interconexão e posteriormente transmitida para a interface
DECT.
22
Como descrito por Philips e Namee (1998, p.63), “a sinalização entre a estação base e a estação
móvel é muito complexa, e por esta razão está definida em termos de módulos ou camadas, que são
mais facilmente controláveis”, deixando as camadas de mais baixo nível responsáveis pelo o envio das
informações bit-a-bit e as camadas de mais alto nível ficam responsáveis pelo envio e controle da
informação sem erros. A Figura 6 a seguir mostra a distribuição das camadas do padrão DECT.
Figura 6 - Distribuição das camadas do protocolo DECT

A distribuição de camadas do protocolo DECT é baseada no modelo OSI (Open System

Interconnections) conforme mostra a Figura 7.
OSI
DECT
Figura 7 - Comparativo das camadas do modelo OSI e do padrão DECT.

Fonte: Adaptado de Zieher (2006).
23
No comparativo entre as camadas dos modelos, mostrado na Figura 7, a camada física do

padrão DECT é equivalente a do modelo OSI. Já a camada DLC (Data Link Control) e a camada MAC
(Medium Access Control) do padrão DECT são equivalentes somente a uma camada do modelo OSI, a
camada enlace. Esta subdivisão é baseada na padronização da IEEE 802 para LAN (Local Area
Network), que determina que a camada MAC seja utilizada unicamente para fornecer acesso a mídia
para diferente LANs, enquanto a camada DLC fornece exclusivamente o serviço de enlace para as
camadas superiores (ZIEHER, 2006).
No padrão DECT a distribuição das camadas também é conhecida como pilha ou stack do
protocolo, na qual cada camada prepara as informações que serão transmitidas a camada
imediatamente superior além de fornecer uma abstração das funções utilizadas.
Conforme mostrado na Figura 6, existem dois planos de comunicação no padrão DECT, o C-

plane e o U-plane. O primeiro é responsável pelas trocas de mensagens de controle do protocolo,
enquanto o segundo é responsável pelas trocas de mensagem da aplicação, ou seja, caso uma
informação da camada de aplicação tenha que ser enviado da EB para a EM será realizado através do
U-plane, enquanto uma sinalização de sistema DECT, como por exemplo, saber qual canal está livre
para transmissão, será realizado através do C-plane e gerenciado pela entidade LLME (Low Layer
Management Entity) (GESSLER, 2000).
A entidade LLME, é responsável por gerenciar o funcionamento do sistema DECT. Ela faz o
uso do C-plane de forma autônoma no intuito de manter o link entre EM e EB sempre ativo.
2.2.2 A Camada Física (PHL – Physical layer)

A camada física é responsável por manter o sincronismo entre a EB e as EMs possibilitando o
envio e recebimento dos pacotes repassados pela camada MAC, conforme mostra a Figura 8. A
camada física também especifica os parâmetros de rádio como: frequência, tempos, potência,
modulação e desempenho requeridas ao transmissor e ao receptor.
24
Figura 8 - Camada física.

Para compartilhar o espectro de frequência entre várias EMs, a camada física utiliza o método
FDMA (Frequency Division Multiple Access) para dividir uma largura de banda em canais menores
distantes em 1.728 MHz um dos outros. No Brasil são somente cinco canais regulamentados pela
ANATEL e alocados na banda de 1910 MHz a 1920 MHz, conforme mostrado na Figura 9. Entretanto,
essa faixa de frequência e canalização pode variar de acordo com cada país (GESSLER, 2000).
Figura 9 – Canalização do padrão DECT utilizada no Brasil.

A canalização padrão da ETSI é compreendida nas bandas de 1.880 MHz a 1.978 MHz e de
2012 MHz a 2025 MHz, e possui uma identificação de canal variando de 0 a 64, conforme norma EM
300 175-2 (ETSI, 2005). No Brasil os cinco canais disponíveis para o padrão DECT foram extraídos
da canalização padrão da ETSI, iniciando pelo canal número 17 até o canal de número 21, conforme
mostra a Figura 9, formando um pequeno subgrupo de canais. É possível observar ainda na Figura 9
que cada rajada de transmissão em um determinado canal possui uma potência máxima de 24 dBm ou
250 mW e uma sensibilidade de recepção -86 dBm resultando em um range dinâmico de 110 dBm.
25
No intuito de comportar um maior número de usuários a camada física faz uma divisão lógica
dos canais DECT baseando-se na técnica TDMA (Time Division Multiple Access). Cada canal é divido
em 24 slots de tempo (timeslots) e cada slot possui uma capacidade de transmissão de 480 bits,
conforme mostrado na Figura 10. O tempo total de transmissão possui duração de 10 ms por quadro.
Figura 10 – Canalização do padrão DECT.

Usualmente os timeslots de 0 a 11 são utilizados para transmissão no sentido EB para a EM e

os timeslots de 12 a 23 são utilizados para o caminho oposto. Cada timeslot de transmissão possui um
timeslot correspondente de recepção, ou seja, se o slot 0 é utilizado para transmissão na direção EB
para EM, o slot 12 é seu correspondente na direção EM para EB. Esse processo de utilização de um
par de slots para transmissão e recepção de dados é chamado de dupla multiplexação dividida por
tempo ou TDD (Time-Division Duplexing), pois permite que tanto a EB quanto a EM comuniquem-se
entre si aparentemente ao mesmo tempo através mesmo canal físico (PHILLIPS; NAMEE, 1998).
2.2.3 A Camada de Acesso à Mídia (MAC - Medium Access Control)
A camada MAC cria os canais de sinalização e tráfego provido pela camada física para o envio
dos pacotes de dados. Além de instruir a camada física os momentos exatos de transmissão e recepção
26
e os canais que serão utilizados, a camada MAC ainda é responsável pelos sinais de “beacons”, ou
sinalizadores, enviados em broadcast (para todas EMs) do sistema. Este sinal provê todas as
informações necessárias às EMs, para que seja possível a configuração de uma transmissão de dados
por um determinado canal.
A camada MAC é responsável também por estabelecer, manter a conexão e realizar o controle
da largura de banda dos canais (PHILLIPS; NAMEE, 1998).
2.2.4 A Camada Link de Dados (DLC - Data Link Control)
A camada DLC é responsável pela confiabilidade na transmissão dos dados ou sinalizações

através dos links, mantendo a informação na sequência correta e íntegra. Esta camada recebe as
mensagens da camada de rede e as divide em blocos menores para que seja possível o envio para
camadas inferiores, adicionando ainda o controle de erros (PHILLIPS; NAMEE, 1998).
A Figura 11 mostra a sequência no processamento dos dados realizado pela camada DLC. Ao
receber um dado da camada de rede (NWK), a DLC divide as mensagens longas através do processo
chamado de segmentação. Em seguida, cria um quadro para cada segmento onde são adicionadas
informações de controle de erro e um cabeçalho de identificação. Tal cabeçalho permite que seja
requisitada uma retransmissão de um pacote caso tenha ocorrido algum erro. Quando o dado alcança a
parte mais baixa da camada DLC, o dado é enviado à camada MAC onde é fragmentado para que
possa ser transmitido posteriormente em único pacote pela camada PHL.
Figura 11 – Sequência de processamento da camada DLC

Fonte: Adaptado de Philips e Namee (1998).
27
Ao receber um dado da camada MAC, a camada DLC inicia o caminho inverso. O dado é
recombinado, retirado cabeçalho e controle de erros, montado e finalmente entregue à camada NWK.
2.2.5 A Camada de rede (NWK - Networking)
Phillips e Namee (1998) definem a camada de rede como executiva por ser a que está mais
próxima da aplicação, interagindo diretamente com o mundo exterior. Porém, a camada de rede,
também interage com o mundo interior, solicitando as camadas inferiores alocação do caminho de
transmissão. Enquanto a camada de rede provê uma interface exclusiva para serviços à stack DECT, a
camada IWU traduz as informações recebidas desta interface para alguma aplicação específica,
compatibilizando a aplicação com protocolo DECT.
Um exemplo do processo de troca de mensagens entre as camadas do padrão DECT é mostrado

na Figura 12. A camada de aplicação da EB dá inicio ao processo de transmissão recebendo ou
coletando os dados da rede em que esta conectada e enviando à camada IWU a mensagem a ser
transmitida. Então a mensagem é repassada entre as camadas até que chegue a de nível mais baixo
(PHL). Da camada física da EB a mensagem é transmitida via RF (Radio Frequency) para a camada
física da EM que a repassará para as camadas superiores até que os dados cheguem à camada de
aplicação da EM, completando a transmissão.
Figura 12 - A sinalização entre as camadas do padrão DECT.

Fonte: Philips e Namee (1998)
28
2.2.6 Código de Identificação

Cada dispositivo DECT possui um código único mundial utilizado para sua identificação. Em
teoria, não é possível a existência de dois códigos de identificação iguais, ou mesmo possuir um
dispositivo DECT sem um código de identificação.
Esses códigos são chamados de IPEI (International Portable Equipment Identity) para as EMs
e RFPI (Radio Fixed Parts Identity) para a EB. A ETSI é responsável por gerenciar e fornecer estes
códigos aos fabricantes. Estes por sua vez, são responsáveis por grava-los na memória dos dispositivos
e garantir que não haja duplicidade (PHILIPS; NAMEE, 1998).
Ambos os códigos possuem tamanho de 40 bits, sendo que os 16 bits mais significativos
representam o nome do fabricante e os demais a numeração serial de produtos DECT.
Exemplo:
IPEI: 01 27 03 02 03 (hexadecimal)
RFPI: 01 27 03 02 00 (hexadecimal)
Neste exemplo o valor 01 27 corresponde ao código do fabricante INTELBRAS.
A principal função destes códigos é identificar os dispositivos em uma rede para que o padrão
DECT possa endereçar o pacote à estação destino correta.
2.2.7 Registros de dispositivos DECT

Para que seja possível a troca de mensagens entre duas estações DECT é necessário que seja
realizado o registro ou ”subscription” dessas estações previamente. O processo de registro consiste na
troca e o armazenamento de seus códigos RFPI e/ou IPEI na memória estação destino.
O processo de registro é realizado pelo padrão DECT de forma transparente ao usuário. O

usuário inicia o processo de registro nas duas estações, tipicamente através de um botão presente nas
estações. Este botão informa às estações que iniciem uma varredura nos canais lógicos e físicos
disponíveis em busca de outra estação também em modo de registro, e, quando encontrada, uma
estação envia seu código de identificação RFPI/IPEI para que a outra estação o armazene em sua
memória, e vice-versa, tornando possível a troca de mensagens entre elas posteriormente. Caso
nenhuma estação seja encontrada em processo de registro durante aproximadamente um minuto, este
processo será encerrado e um novo deve ser iniciado caso haja necessidade. Este registro é que garante
29
a entrega correta de uma mensagem à estação destino dentre outras estações do ambiente (PHILIPS;
NAMEE, 1998).
2.3 ESTAÇÃO BASE (EB)
No sistema de automação residencial baseado na tecnologia DECT a estação mestre é a EB.

Suas principais funções são: gerenciamento, processamento e armazenamento dos dados adquiridos
pelas EMs. A EB é composta pelas seguintes unidades: processamento, controle de rede de dados
(Ethernet), interface para o padrão DECT e duas unidades de armazenamento, conforme mostra a
Figura 13.
Figura 13 - Hardware componente da EB.
Segundo Axelson (2003), um sistema embarcado possui a inteligência de um computador e é

destinado a executar um grupo de tarefas específicas. Esses sistemas possuem uma grande integração
entre hardware e software e geralmente estão munidos com quantidades limitadas de memória
(HALLINAN, 2006). Em outras palavras um dispositivo embarcado é um computador com recursos
reduzidos o suficiente para aplicações específicas ao contexto que está inserido. Atualmente existem
algumas soluções de hardware para dispositivos embarcados, tais como, família x86 da Intel, ARM,
POWER PC, etc. e de software, tais como, Linux Embedded, Windows CE, Windows 8, Android, etc.
A solução de hardware da EB é composta por um processador ARM geração nove, um
controlador de rede Ethernet (Ethernet Switch Controller 10/100MB), uma interface DECT e
memórias FLASH e SDRAM (Synchronous Dynamic Random Access Memory) e como solução de
30
software a EB utiliza o sistema operacional Linux Embedded. Tais qualidades caracterizam a EB como
um sistema embarcado. O hardware e as partes integrantes da EB foram cedidos pela empresa
INTELBRAS S/A para o desenvolvimento deste trabalho. Na sequência é detalhada a estação base
(EB).
2.3.1 Detalhamento da Estação Base (EB)

Como apresentado na seção anterior, a EB possui o sistema operacional Linux Embedded
responsável por todo gerenciamento de hardware e de software. Para disponibilizar o acesso à interface
WEB de controle bem como a leitura dos dados, a EB contará com um servidor WEB, além de duas
aplicações AARLL (Aplicação Automação Residencial Lado Linux) e a AARLD (Aplicação
Automação Residencial Lado DECT), que farão o papel de interface entre o DECT e o sistema
operacional. A aplicação AARLD é responsável por tratar os dados recebidos das EMs para que sejam
processados ou armazenados no lado LINUX. Já a aplicação AARLL é responsável por tratar os dados
recebidos da ARRLD que serão exibidos na interface WEB de controle no lado Linux. A interface
WEB de controle, por sua vez, será responsável por exibir ao usuário o status das EMs e as opções de
controle. A interface WEB de controle, a AARLD e AARLL estão em destaque na Figura 14, pois
serão desenvolvidas no Capítulo 3 deste trabalho.
Figura 14 - Detalhamento de aplicações da EB

31
O controlador Ethernet exibido na Figura 14 é responsável pelo tráfego de dados entre a rede
local e a EB. Ele está diretamente conectado ao processador através de um barramento RMII (Reduced
Media Independent Interface) possibilitando o envio e recebimento de dados da rede local.
A memória volátil SDRAM e a memória não volátil FLASH, também estão conectadas
diretamente ao processador e ambas dão suporte ao funcionamento do sistema operacional Linux. A
SDRAM, com maior velocidade de barramento, opera a 100 MHz e é utilizada para guardar as
informações que serão processadas em momento de execução, enquanto a memória FLASH, por ser
não volátil do tipo NAND (Not AND), é utilizada para manter os dados salvos enquanto o sistema de
automação está desligado (MORIMOTO, 2007). Na sequência serão apresentadas as descrições de
cada módulo.
2.3.2 Servidor WEB
Um servidor WEB é uma aplicação designada a atender as solicitações de clientes através de

conexões TCP (Transmission Control Protocol). Utilizando uma porta específica para acesso,
geralmente a porta 80, os dados são transmitidos com o auxílio do protocolo HTTP (Hypertext
Transfer Protocol). Alguns servidores podem trabalhar com outros tipos de protocolos
(TANEMBAUM, 2003). Em outras palavras, ao digitar um endereço no navegador de internet, é
estabelecido uma conexão TCP entre cliente-servidor. O servidor munido do endereço de localização
do arquivo inicia sua busca na memoria e retorna com os dados ao navegador solicitante. Este por sua
vez, exibe ao usuário o conteúdo que foi requisitado.
Para que a interface WEB não necessite ser totalmente recarregada em uma iteração com o
usuário, por exemplo, a técnica de criação de páginas AJAX (Asynchronous JavaScript and XML) é
utilizada. Esta técnica permite que pequenas quantidades de dados sejam trocados entre o navegador
de internet e o servidor WEB, eximindo a necessidade de recarregar a interface WEB de controle
totalmente. O que acaba sendo uma grande vantagem para utilização em sistemas embarcados
(W3SCHOOLS, 2013).
No caso da automação residencial, o servidor WEB exibirá a interface WEB de controle ao
usuário contendo as informações de status de sensores e atuadores que compreendem o sistema.
A interface WEB de controle é uma página WEB feita com a linguagem de programação
HTML (Hypertext Mark-up Language) e complementada com codificação baseada em Java para
32
WEB, conhecido também como Java Script, responsável por oferecer dinamismo ao conteúdo que
variam de acordo com os comandos recebidos (TECHTERMS, 2013).
2.3.3 AARLL e AARLD
A aplicação AARLL será utilizada para consultar o status dos atuadores e sensores presentes
nas EMs. Esta aplicação é executada no sistema operacional Linux e serve de interface entre o servidor
WEB e a interface DECT, ou seja, sempre que o usuário requisitar uma informação de status em
alguma EM, a interface de controle WEB enviará esse pedido ao servidor WEB, que por sua vez,
enviará uma mensagem à aplicação AARLL contendo a identificação da EM e o dado que se deseja
obter. Ao receber a requisição com os dados, a AARLL encapsulará as variáveis recebidas através do
protocolo Contact ID e enviará uma mensagem de requisição à interface DECT através da aplicação
AARLD. O protocolo Contact ID será detalhado na subseção 2.5.1.
A aplicação AARLD tem comportamento semelhante à AARLL. A diferença entre elas é que
enquanto a primeira é executada como parte integrante da Interface DECT a segunda é executada em
ambiente Linux. A troca de mensagens entre estas aplicações possibilita a troca de informações entre a
EB e as EMs.
Quando a requisição é recebida pela AARLD, a mensagem é preparada para ser enviada à
camada imediatamente inferior da interface DECT e, a partir daí, a informação será encapsulada
sucessivamente até que chegue a camada de menor nível da interface DECT, a camada física.
A camada PHL, recebendo da camada MAC a requisição para envio da mensagem, iniciará o
envio desta informação até a EM destino via RF (Rádio Frequência).
2.4 ESTAÇÃO MÓVEL (EM)
A EM assim como a EB, também é um dispositivo embarcado, porém de menor complexidade.

Na EM não existe um sistema operacional propriamente dito, ao invés disso, se utiliza um software
proprietário de gerenciamento de estados.
As principais funções das EMs estão relacionadas com o acionamento e o fornecimento de

dados oriundos de monitoramento de eletrodomésticos e equipamentos residenciais à EB.
Como solução de hardware, a EM possui um processador ARM geração nove, uma interface
DECT, além de sensores, atuadores, displays e LEDs, conforme mostra a Figura 15.
33
Figura 15 – Hardware componente da EM.
A Figura 15 mostra a interface DECT interligada ao processador através de um barramento de

dados. Já os sensores e atuadores estão ligados diretamente às portas de propósito gerais de entrada e
saída do processador. O funcionamento da EM é descrito na sequência.
2.4.1 Detalhamento da Estação Móvel (EM)

Na EM, o software de gerenciamento proprietário faz o controle da interface DECT da EM,
conforme pode ser visto na Figura 16.
Figura 16 – Detalhamento das aplicações da EM.

34
A Figura 16 mostra a estrutura da interface DECT da EM e sua conexão com a aplicação

AARLD. Nesta figura a AARLD está em destaque, pois foi desenvolvida neste trabalho. Para todas as
estações do sistema de automação residencial, a interface DECT é exatamente igual, com a camada
física (PHL) em uma extremidade e a camada IWU na outra. Por não possuir um sistema operacional
embarcado, na EM só é necessário o uso da aplicação AARLD, pois esta fará a conexão direta com a
camada IWU e servirá de interface na comunicação com os sensores e atuadores presentes na EB.
Ao receber um dado da EB, a camada física decodificará os bits recebidos e os encaminhará a
camada imediatamente superior. Este processo irá se repetir até que o dado chegue à camada IWU, e
por fim, seja entregue a aplicação AARLD.
Com o dado presente na aplicação AARLD, as ações podem ser executadas pela EM. Caso o
comando recebido seja um comando de mudança de estado, por exemplo, a aplicação aciona o
hardware apropriado da EM e realiza a alteração de seu estado. Da mesma forma funciona o comando
de leitura de estado dos sensores, por exemplo, para executar esse comando, a aplicação faz a leitura
do estado do hardware e passa essa informação para a camada IWU. A informação será encapsulada
sucessivamente nas demais camadas, até que chegue à camada física (PHL), que por fim, fará o envio
dos dados à EB.
2.5 PROTOCOLO DE COMUNICAÇÃO DAS ESTAÇÕES

Para que a comunicação entre a EB e as EMs ocorra de forma controlada e para que seja
possível a escalabilidade das estações, é necessário que elas sigam um padrão descrito por um
protocolo.
Um protocolo é um conjunto de regras que padronizam a comunicação entre dois processos,
sistema, estações, etc. Geralmente implementado através de software, é o protocolo que define a
forma, a ordem das mensagens e as ações a serem realizadas garantindo a comunicação entre duas
partes. Desta forma, é possível assegurar a compatibilidade do sistema de automação residencial
mesmo com o aumento do número de estações (CERUTTI, 2000).
Existem alguns protocolos de comunicação disponíveis no mercado, tais como, CAN
(Controller Area Network), CEBus (Consumer Electronics Bus), Contact ID, entre outros. Neste
trabalho será considerado somente o protocolo Contact ID por se tratar de um protocolo simples e já
utilizado no ramo de segurança e centrais de monitoramento (SIA, 1999).
35
2.5.1 O Protocolo Contact ID
O protocolo Contact ID foi originalmente desenvolvido pela empresa Ademco ® a fim de

padronizar as comunicações entre os seus sistemas de alarme. Posteriormente em 1999 esse protocolo
foi cedido pela Ademco e padronizado pela SIA (Security Industry Association) tornando-se de um
protocolo de domínio público. A SIA incentiva o uso deste protocolo em comunicação de
equipamentos digitais visando à compatibilidade entre os mais variados sistemas (SIA, 1999).
No Contact ID a comunicação do transmissor para o receptor é composta por três elementos
básicos: Cumprimento (Handshake), mensagem (Messages), e confirmações de recebimento das
mensagens (Acknowledgements) ou ainda somente (Acks).
Originalmente a comunicação protocolo Contact ID é realizada através da técnica DTMF
(Dual-Tone Multi-Frequency) pelo fato dos sistemas de monitoramento e alarmes utilizarem a linha
telefônica analógica para trafegar sua comunicação. Neste projeto não será necessário utilizar o DTMF
para transmissão dos dados nem a técnica de Handshaking, para inicio da sessão de transmissão, pois a
comunicação será realizada através de um meio digital, o que descarta a implementação dos padrões
físicos do protocolo Contact ID. Já as padronizações de estrutura das mensagens propostas pelo
protocolo serão utilizadas na íntegra, conforme disposto a seguir.
Ao ser transmitida uma mensagem entre EB e a EM, deve ser seguida uma estrutura padrão
conforme disposto a seguir.
ACCT MT QXYZ GG FCC S
Onde:
A: indica a estação originária da informação;
1 = indica que a sinalização tem origem da EM;

0 = indica que a sinalização tem origem da EB;
CCT: indica o número de identificação do dispositivo (três dígitos hexadecimais).
MT: identificam a prioridade da mensagem para o receptor.
18 = mensagem preferencial, ou prioritária;

98 = mensagem opcional.
36
Q: traz informações especificas do evento.
1 = Novo evento ou abertura de evento;

3 = Nova restauração ou fechamento de evento;
6 = Condição anteriormente reportada continua acontecendo.
XYZ: É o código do evento descritos na Tabela 1 (três dígitos hexadecimais).
GG: indica o numero da repartição (dois dígitos hexadecimais).
Este campo não será utilizado nesta aplicação.
F: indica em qual andar da residência em que o evento ocorreu.
CC: indica o número da zona do usuário.
S: indica o checksum para a mensagem em questão.
Caso seja realizado um acesso na EB a fim de se saber se a janela da sala encontra-se aberta ou
fechada é feito uma consulta na EM1, que esta responsável por este monitoramento. A EM1 faz a
leitura do estado do sensor (aberto ou fechado) e encaminha a seguinte mensagem para a EB.
1001 18 1400 00 000 0
Onde,
1: Identificação quanto ao tipo da estação, neste caso, 1 = EM.

001: Identificação quanto ao índice da estação, neste caso, o dado veio da EM1.
18: Identificador de prioridade de mensagem, neste caso, a mensagem é de alta prioridade.
1400: Qualificador de evento, neste caso é um Novo evento (1), seguido pelo código de
significado do evento (400 - Aberto);
00: Não utilizado; e
000 0: Não utilizado;
37
2.5.2 Classificação dos Eventos

O protocolo Contact ID, traz uma lista de eventos cadastrados e padronizados pela SIA que
torna possível o uso do protocolo nos equipamentos digitais em diversas aplicações. A Tabela 1
descreve os eventos pertinentes ao sistema automação residencial, proposto por este trabalho (SIA,
1999).
Tabela 1 - Eventos do protocolo Contact ID referentes ao campo XYZ.

Código XYZ Evento Descrição
302 Bateria baixa Indicação de bateria baixa nas EMs
400 Aberto Indicação de abertura na região monitorada
407 Acionamento Aciona o atuador da região monitorada.
408 Desligamento Desliga o atuador da região monitorada.
459 Fechado Indicação de fechamento na região monitorada
2.5.3 Considerações
Neste capítulo foi apresentado o conceito de automação residencial (Subseção 2.1), a topologia
do sistema residencial (Subseção 2.1.1), além de alguns exemplos de sistemas comerciais de
automação residencial (Subseção 2.1.2) e uma apresentação detalhada sobre o padrão DECT a ser
utilizado no sistema de automação proposto (Subseção 2.2).
Também fizeram parte da fundamentação teórica o conceito e a definição de sistemas
embarcados, a apresentação detalhada da EB (Subseção 2.3), conceito de servidor WEB e das
aplicações AARLL e AARLD (Subseção 2.3.2 e 2.3.332), além de um detalhamento sobre as EMs
(Subseção 2.4) e a definição do protocolo de comunicação a ser utilizado no sistema de automação
deste TCC (Subseção 2.5.1). Foram apresentados também a estrutura do protocolo Contact ID e uma
lista com eventos padronizados do protocolo que serão utilizados (Subseção 2.5.2).
No Capitulo 3 é apresentada uma comparação entre as soluções elegidas para compor este
trabalho de conclusão de curso com soluções utilizadas em outros trabalhos de automação residencial,
abordando-se as vantagens e desvantagens de cada técnica utilizadas.
38
3 TRABALHOS RELACIONADOS
Neste capítulo são mostradas as características de três trabalhos de automação residencial

similares ao apresentado neste TCC. Estes trabalhos são de domínio público e foram escolhidos pelo
grau de similaridade com os objetivos propostos neste TCC.
3.1 IMPLEMENTAÇÃO DE UM SISTEMA DE AUTOMAÇÃO

RESIDENCIAL MODULAR
O trabalho de automação residencial de Almeida (2009) é composto por um computador, um
módulo central, e cinco módulos atuadores. O módulo central utiliza um microcontrolador PIC
16F877A, já os módulos atuadores utilizam um microcontrolador PIC16F873A, ambos da empresa
Microchip.
Através de um software específico instalado no computador, o usuário seleciona os comandos
de controle disponíveis e os envia para o módulo central, que por sua vez, repassará as programações
para os respectivos módulos atuadores. A Figura 17 mostra a arquitetura do sistema de automação
residencial.
Figura 17 - Arquitetura do sistema de automação.

Fonte: Almeida (2009)
A comunicação entre o computador e o módulo central é realizada através de uma porta serial
do padrão RS232, já a comunicação entre a central e os módulos de controle é realizada através de
comunicação sem fio na frequência de 433,92 MHz.
Um ponto positivo desse sistema é a comunicação entre o módulo central e os módulos de
controle ser implementados sem a utilização de condutores, torna o sistema flexível quanto a sua
39
instalação. Porém, um ponto negativo identificado, é a necessidade de possuir um computador com um

programa específico instalado para que seja possível executar os comandos de controle.
3.2 SISTEMA PARA CONTROLE E SUPERVISÃO REMOTA PARA

AUTOMAÇÃO RESIDENCIAL
Neste trabalho de automação residencial Pereira (2009) utiliza um computador para realizar o
processamento central, um módulo CLP (Controlador Lógico Programável) para acionamento dos
equipamentos residenciais e um celular servidor para o recebimento dos comandos. O computador faz
interface entre o celular servidor e o módulo CLP através de um aplicativo específico e um sistema
supervisório. O aplicativo específico é utilizado para interpretar os comandos recebidos do celular
servidor, já para trocar informações com o módulo CLP é utilizado o software supervisório. A Figura
18 mostra a arquitetura do sistema.
Figura 18 – Arquitetura do sistema de automação.

Fonte: Adaptado de Pereira (2009).
O usuário através de um celular denominado “Cliente” envia uma mensagem de texto contendo
os comandos desejados para o celular servidor utilizando a comunicação GSM (Global System for
Mobile Communications). Ao receber esses comandos, o celular servidor os envia para o computador
através de comunicação serial RS232. O software que faz interface com o celular servidor,
denominado “Aplicativo”, interpretará os comandos recebidos pelo celular servidor e os enviará para o
40
software supervisório, também presente no computador. O software supervisório, por sua vez,
interpretará os comandos recebidos e os enviará para o CLP via RS232, que irá acionar saída
correspondente ligando ou desligando o equipamento dentro da residência.
A utilização da tecnologia GSM no sistema de automação traz flexibilidade no que diz respeito
à troca de informações entre o usuário e sua residência. Porém, limita a interação do usuário com a
interface de controle o fato dos comandos serem realizados a partir de mensagens de texto.
3.3 INTERFACE HOMEM-MÁQUINA PARA A DOMÓTICA BASEADA EM

TECNOLOGIAS WEB EM UM SERVIDOR EMBARCADO
O trabalho de automação residencial de Zandoná (2012) utiliza a plataforma Arduino Mega256
para realizar o processamento central do sistema de automação, um módulo para acesso a rede de
dados (Ethernet) e um módulo de driver para acionamento dos equipamentos residenciais. A
plataforma Arduino está conectada diretamente a um switch de rede e também um roteador wireless,
conforme pode ser visto Figura 19.
Figura 19 - Arquitetura do sistema de automação

Fonte: Zandoná (2012).
Para acessar a interface de controle o usuário pode utilizar qualquer dispositivo que tenha
suporte a navegador de páginas WEB. Nesta interface é possível selecionar os as opções de controles
41
(ligar e/ou desligar) dos equipamentos da residência. Esta interface é disponibilizada ao usuário através
de um servidor WEB embarcado na própria plataforma do Arduino. O comando de controle de um
determinado equipamento da residência é selecionado pelo usuário através da interface de controle
WEB, e posteriormente enviado à central de processamentos. Esta, por sua vez, aciona o um driver de
acionamento onde o equipamento desejado está sendo energizado.
Esta solução traz muita flexibilidade ao usuário, pois permite o controle remoto dos
equipamentos de sua residência, já que a arquitetura Arduino possui uma conexão de rede de dados
(Ethernet) que está conectado diretamente a um switch e a um roteador wireless com acesso a Internet.
Porém, a necessidade de conexão por fio dos equipamentos residenciais (equipamentos a serem
controlados) à unidade de processamento central dificulta a instalação do sistema, já que diversos
equipamentos da residência estão distantes da central de controle. Este fato faz com que seja grande a
necessidade de se realizar a adaptação das estruturas das residências para comportar tal sistema.
3.4 ANÁLISE COMPARATIVA

Conforme descrito anteriormente, o trabalho acadêmico de Almeida (2009) utiliza
comunicação sem fio entre a unidade central e os atuadores do sistema de automação residencial. Esta
característica torna a instalação desse sistema de automação muito mais simplificada, haja vista, que é
possível instalá-lo sem grandes alterações nas residenciais já existentes. Essa facilidade é um dos
pontos que Minoru (2011) havia identificado com oportunidade de melhoria nos sistemas de
automações existentes para uma melhor aderência no mercado.
Já no trabalho de Pereira (2009), o controle do sistema de automação é realizado através do

envio de mensagens de texto ao módulo de processamento central, utilizando comunicação GSM. O
fato de a informação ser trocada através do padrão GSM proporciona ao sistema de automação muita
mobilidade, podendo o usuário controlá-lo remotamente, porém, o fato da interface entre o usuário e o
sistema ser realizada através de trocas de mensagens de texto deixa a utilização do sistema complexa,
já que o usuário terá que redigir o texto de comando. Outro ponto que pode ser citado é a necessidade
de se manter um número ativo na operadora GSM para que seja possível a comunicação entre as
partes, mesmo que o usuário opte por utilizar o sistema somente dentro da residência. Em uma solução
WEB essa necessidade não existiria.
O trabalho de Zandoná (2012) assemelha-se aos objetivos deste trabalho, porém as soluções e
arquiteturas utilizadas em ambos se diferem. Zandoná utiliza como principal solução do sistema de
42
automação, um microcontrolador Arduino, que através de um servidor WEB embarcado, disponibiliza

ao usuário uma interface WEB para controle dos equipamentos de uma residência. Compreendido em
um único módulo, os equipamentos residenciais necessitam ser conectados, através de fios, a este
módulo para que haja o controle. Isto faz com que haja a necessidade de instalações e modificações na
estrutura de uma residência já existente para a instalação deste sistema. O controle via interface WEB,
traz mobilidade e maiores possibilidades de iteração com o usuário no sistema desenvolvido por
Zandoná. Uma comparação entre os sistemas pode ser visto no Quadro 1.
Trabalho de Trabalho de Trabalho de

Característica Este Trabalho
ALMEIDA (3.1) PEREIRA (3.2) ZANDONÁ (3.3)
Disponibiliza acesso
à interface de
Permite o controle Disponibiliza controle via
Comunicação
do sistema de acesso à interface navegador
sem fios entre a
Vantagens automação através de controle via de páginas WEB.
unidade central e
de comunicação navegador de Realiza comunicação
os atuadores.
sem fio GSM. páginas WEB. sem fios entre a
unidade central e os
atuadores / sensores.
Os comandos são
enviados via
Necessidade de
mensagem de Conexão por fio
instalação de um Necessidade de uma
texto diminui a entre os
programa para infraestrutura de rede
Desvantagens usabilidade do equipamentos
execução da local e um roteador
sistema. residenciais à
programação da wireless.
Necessita manter unidade central.
unidade central.
conta junto à
operadora GSM.
Necessário manter Necessita manter
Necessidade de
um computador um computador e Alcance máximo
passagem de cabos
ativo para realizar uma conta GSM entre a EB e as EM`s
Limitações para instalação do
as programações ativa para manter de 500 metros
sistema na
na unidade o sistema outdoor.
residência.
central. operando
Referência Almeida (2009) Pereira (2009) Zandoná (2012) Autor
Quadro 1 - Análise Comparativa dos Sistemas de Automação Residencial
43
4 DESENVOLVIMENTO
Neste capítulo são apresentadas as etapas para o desenvolvimento deste trabalho. Inicialmente,
é realizada a análise dos requisitos do sistema, definição dos diagramas de casos de uso e a modelagem
de software do sistema. Na sequência é apresentado o detalhamento do desenvolvimento, uma visão
geral da plataforma, um detalhamento sobre as estações EM e EB, além do servidor WEB, das
aplicações AJAX_APP, da gravação dos dados em arquivos XML, da interface de controle WEB e da
implementação do protocolo de comunicação entre as estações. Finalmente será apresentada a
descrição dos experimentos e os resultados dos testes.
4.1 VISÃO GERAL DO SISTEMA

O sistema de automação residencial proposto neste trabalho foi denominado HAS (Home
Automation System). O HAS possui uma interface de controle WEB baseado em linguagem de
programação HTML, Java Script e XML, além de possuir um servidor embarcado que disponibiliza
uma interface WEB em resposta às requisições HTTP dos navegadores de internet. Para sua operação,
é necessária uma infraestrutura mínima de rede, típica de uma residência conforme mostra a Figura 20.
Figura 20 - Visão geral do sistema de automação residencial.
Conforme apresentado na Figura 20, a EB está diretamente conectada à rede de dados através
de um switch, que por sua vez, esta conectada a um roteador wireless. Um endereço IP é atribuído
dinamicamente pelo roteador à EB, e através deste, o usuário tem acesso à interface de controle WEB
44
do sistema de automação residencial. Através da interface WEB, o usuário pode enviar comandos de
acionamento ou de status à EB. Ao receber estes comandos, a EB os enviará via protocolo DECT para
a EM, que por sua vez, executa o comando recebido. Apesar de ser mostrada somente uma EM na
Figura 20, é importante ressaltar que o sistema tem capacidade de controlar até cinco EM’s.
No desenvolvimento da interface WEB tanto para a linguagem HTML quanto para o Java
Script foi utilizado o editor de textos Sublime-Text. Já para testes e debugs foi utilizado o navegador
Mozilla Firefox® com o add-ons Fire-Bug, ferramenta gratuita para desenvolvimento de interface
WEB. Já no desenvolvimento dos códigos em C foi utilizada a IDE Eclipse C/C++.
4.2 ANÁLISE DE REQUISITOS

A análise de requisitos de um sistema pode ser dividida em requisitos funcionais (REF),
requisitos não funcionais (RNF) e regras de negócio (RNE). Juntos, eles descrevem como um sistema
deve se comportar. Na Tabela 2 são descritos os requisitos funcionais, na Tabela 3 os requisitos não
funcionais e na Tabela 4 são descritas as regras de negócio do sistema proposto.
Tabela 2 - Requisitos Funcionais do Sistema de Automação
REF Descrição do requisito

01 O sistema deve permitir o usuário registrar pelo menos uma estação móvel (EM).
O sistema deve permitir o usuário excluir o registro de todas as estações móveis
02
(EM) do sistema.
O sistema deve permitir o usuário atribuir um nome ao eletrodoméstico a ser
03
controlado.
O sistema deve permitir o usuário programar um eletrodoméstico ligar/desligar em
04
determinado horário.
05 O sistema deve permitir o usuário trocar a senha de login.
O sistema deve permitir o usuário ligar um eletrodoméstico através da interface de
06
controle WEB.
O sistema deve permitir o usuário desligar um eletrodoméstico através da interface
07
de controle WEB.
O sistema deve mostrar ao usuário em qual ambiente encontra-se uma determinada
08
EM.
09 O sistema deve informar ao usuário o número IP que foi associado à EB.
O sistema deve mostrar ao usuário o status do sensor conectado a uma determinada
10
EM.
45
Tabela 3 - Requisitos Não Funcionais do Sistema de Automação

RNF Descrição do requisito
01 O sistema deve possuir interface implementada em linguagem para WEB.
O sistema deve permitir acesso à interface através dos navegadores Mozilla
02
Firefox e Google Chrome.
03 O sistema deve possuir um servidor WEB embarcado.
O sistema deve permitir o controle de eletrodomésticos através de comunicação
04
sem fio (Rádio Frequência).
05 O sistema deve armazenar as configurações quando não estiver energizado.
06 O sistema deve armazenar as configurações em arquivos XML.
Tabela 4 - Regras de Negócio do Sistema de Automação

RNE Descrição do requisito
O sistema deve permitir o acesso às informações somente após que o usuário
01
efetue login na interface WEB.
02 O sistema deve permitir o registro de até cinco estações móveis EM1 .
4.3 MODELAGEM DO SISTEMA

Nesta Seção serão apresentados os diagramas e descrições detalhadas dos casos de uso
aplicáveis ao sistema de automação proposto neste TCC.
4.3.1 Casos de Uso

Casos de uso é uma descrição narrativa de uma sequência que descrevem os eventos que
ocorrem quando um ator usa um sistema para realizar uma tarefa. A Figura 21 mostra o diagrama de
casos de uso que contemplam o projeto proposto feito com o software Enterprise Architect.
1
Cinco estações EMs é o número limite para a plataforma de trabalho escolhida para este TCC, no caso o TS60IP da
empresa Intelbras. Tecnicamente o que limita o número de estações que o DECT pode operar é a quantidade de links de RF
simultâneos entre a EM e a EB. Esse número obtém-se através da multiplicação da quantidade de slots de tempo
disponíveis, no caso 12 (transmissão), versus o número de canais de RF, no caso 5, o que resulta em 60 estações
simultâneas. A Figura 10 mostra a canalização DECT disponível no Brasil.
46
Figura 21 - Diagrama de casos de uso
4.3.2 Descrição dos Casos de Uso

Nesta subseção serão detalhados os casos de uso presentes no diagrama da Figura 21.
47
Tabela 5 - Descrição do Case de uso USC 01

USC 01 – Registro de estação EM
Descrição: O usuário registra uma estação EM no sistema.
Pré-condição: O usuário deve estar de posse da estação EM energizada.
Resultado esperado: O usuário obtém sucesso no registro da estação EM.
1. O usuário pressiona uma tecla na EM.
2. A estação EM exibe uma mensagem “registrando”.
3. O usuário pressiona uma tecla na EB.
Fluxo de informações: 4. A estação EB pisca um LED informando que o sistema entrou em
modo de registro.
5. As estações trocam seus RFPI`s e IPEI`s (números identificadores) e
armazenam em memória
Fluxos alternativos de Exceção 1 - Limite de registro atingido: Caso a EB tenha atingido sua
exceções: limitação máxima de registro ela não entrará em modo de registro.
USC 02 – Exclusão de estação EM

Descrição: O usuário exclui um registro de uma estação EM no sistema.
Pré-condição: O usuário deve ter pelo menos uma estação EM registrada no sistema.
Resultado esperado: O usuário obtém sucesso na exclusão do registro da estação EM.
1. O usuário pressiona uma tecla na EM.
2. A estação EM pisca um LED informando que seu registro será
Fluxo de informações: excluído.
3. As estações excluem seus RFPI`s e IPEI`s (números identificadores)
de suas memórias.
Fluxos alternativos de
Não há.
exceções:

USC03 – Conhecer o número IP da EB
Descrição: O usuário toma conhecimento do número IP atribuído a EB pelo roteador.
O usuário deve estar com a EB conectada a uma rede com um roteador em
Pré-condição:
modo DHCP.
Resultado esperado: A EM mostra ao usuário o número IP atribuído a EM.
1. O usuário pressiona um botão na EB;
Fluxo de informações:
2. A estação EM mostra o número IP atribuído a EM.
Fluxos alternativos de Exceção 2 – Sem endereço IP: Caso a rede não seja capaz de atribuir um
exceções: endereço IP à EM, não será mostrado o número ao usuário.
48

USC 04 – Efetuar login no sistema
Descrição: O usuário efetua login no sistema de automação.
1. O usuário deve ter conhecimento do numero IP da EM.
Pré-condição:
2. O usuário deve conhecer o usuário e a senha de acesso.
Resultado esperado: O usuário tem acesso às configurações da EB.
1. O usuário digita o número IP da EB em um navegador web
suportado;
Fluxo de informações: 2. O sistema mostra a tela de login;
3. O usuário digita o login e a senha;
4. O sistema redireciona o usuário para tela de configurações;
Fluxos alternativos de Exceção 3 - Senha inválida: Caso a senha seja inválida, o sistema bloqueará
exceções: o acesso do usuário as configurações disponíveis.

USC 05– Programar horário para ligar/desligar um eletrodoméstico
O usuário programa um horário para ligar ou desligar um eletrodoméstico de
Descrição:
determinada EM.
Possuir uma EM cadastrada na EB.
Pré-condição:
Estar com a hora do sistema ajustada.
O sistema informa ao usuário que a programação foi efetuada com sucesso e
Resultado esperado:
no horário programado o sistema executará a programação.
1. O usuário acessa a aba da estação que quer programar;
2. Marca a caixa “Ativo”;
3. Escolhe o comando (ligar/desligar);
Fluxo de informações: 4. Entra com a hora que deseja salvar
5. Clica no botão “Salvar”;
6. O sistema informa que as programações foram realizadas com
sucesso.
Fluxos alternativos de Exceção 4 - Hora do sistema não cadastrada: Caso a hora do sistema não
exceções: tenha sido ajustada não será possível realizar a programação.

USC 06 – Ajuste de hora do sistema
Descrição: O usuário ajusta a hora do sistema com a hora local.
Pré-condição: Sem pré-condição.
Resultado esperado: Hora do sistema ajustada.
1. O usuário acessa a aba de configurações do sistema;
2. Entra com a data e a hora atual;
Fluxo de informações: 3. A interface coleta as informações e as armazena;
4. O sistema informa ao usuário que a hora do sistema foi ajustada com
sucesso.
Fluxos alternativos de Exceção 5 – Inserção de dados inválidos: Caso o usuário insira a hora com
exceções: números inválidos o sistema não permitirá o ajuste da hora.
49

USC 07– Ligar um eletrodoméstico
Descrição: O sistema liga um eletrodoméstico através da interface de controle WEB.
1. Possuir um eletrodoméstico conectado a uma EM
Pré-condição:
2. Estar com a EM cadastrada no sistema
Resultado esperado: O sistema irá ligar determinado eletrodoméstico.
1. O usuário acessa a interface de controle WEB;
2. Clica na estação móvel desejada;
3. No campo “Controles Diretos” ele clica em um dos botões
(ligar/desligar);
4. O usuário clica no botão enviar;
O sistema executa a ação de ligar o equipamento.

USC 08 – Desligar um eletrodoméstico
Descrição: O sistema desliga um eletrodoméstico através da interface de controle WEB.
Pré-condição: 2. Estar com a EM cadastrada no sistema
3. O eletrodoméstico deve estar ligado
Resultado esperado: O sistema irá desligar determinado eletrodoméstico.
2. Clica na estação móvel desejada;
3. No campo “Controles Diretos” ele clica em um dos botões
(ligar/desligar);
4. O usuário clica no botão enviar;
O sistema executa a ação de ligar o equipamento..

USC 09 – Atribuir um ambiente a um eletrodoméstico
Descrição: O sistema atribui um ambiente a uma EM
Pré-condição:
O sistema irá atribuir um ambiente a determinada EM que contem o
Resultado esperado:
eletrodoméstico.
2. O usuário clica na aba da EM desejada;
3. O usuário clica no campo ambiente;
4. O usuário entra com o nome do ambiente que deseja atribuir;
5. O usuário clica no botão “Salvar”;
6. O sistema armazena os dados.
Não há.
exceções:
50

USC 10 – Mostrar status de um sensor
O sistema mostrará o status de um determinado sensor conectado em uma
Descrição:
EM.
1. Possuir um sensor conectado a uma EM
Pré-condição:
Resultado esperado: O sistema irá mostrar o status de um determinado sensor.
2. Clica no EM desejada;
3. Clica no botão “status”;
O sistema informa o status do sensor ao usuário.

USC 11 – Atribuir nome a um eletrodoméstico
O usuário atribui um nome a um eletrodoméstico controlado por uma EM do
Descrição:
sistema.
1. O usuário deve ter um eletrodoméstico conectado a uma EM.
Pré-condição:
2. O usuário deve conhecer o número IP da EB.
Resultado esperado: O usuário atribui o nome ao eletrodoméstico a determinada EM do sistema.
2. O usuário clica na EM desejada;
Fluxo de informações: 3. O usuário insere o nome que deseja atribuir no campo
“eletrodoméstico a ser controlado”
4. O sistema armazena as informações.
Não há.
exceções:
Tabela 16 - Detalhamento do Caso de uso USC 12.

USC 12 – Trocar da senha de login
Descrição: O usuário altera a senha de acesso à interface de controle WEB.
Pré-condição: O usuário deve ter acesso à interface de controle WEB.
Resultado esperado: O usuário atribui o nome ao eletrodoméstico a determinada EM do sistema.
2. O usuário clica em Configurações do sistema;
Fluxo de informações: 3. O usuário insere a senha antiga e a nova senha;
4. O usuário clica em salvar.
5. O sistema armazena as informações.
Não há.
exceções:
51
Tabela 17 - Detalhamento do Caso de uso USC 13

USC 13 – Atribuir tipo de serviço à EM
Descrição: O usuário atribui à EM o tipo de serviço que utilizará.
Pré-condição: Estar com a EM cadastrada no sistema
Resultado esperado: O sistema irá mostrar o status de um determinado sensor.
2. Clica no EM desejada;
3. O usuário seleciona a caixa de controle e monitoramento;
4. O usuário clica em “Salvar”.
Não há.
exceções:
52
4.4 DETALHAMENTO DO DESENVOLVIMENTO

Esta seção aborda as etapas de desenvolvimento da interface de controle WEB, do servidor
WEB e do protocolo de troca de mensagens. A interface de controle WEB permite que o usuário
controle o sistema de automação residencial. O servidor WEB é responsável por atender as requisições
que o usuário fará ao navegar pela interface WEB e é também responsável por salvar as modificações
feitas pelo usuário utilizando a linguagem de marcação XML. Já o protocolo de troca de mensagens é
o meio de comunicação entre as estações móveis com a estação base.
Nesta seção serão apresentados diagramas de sequência, fluxogramas, bem como parte da
codificação utilizada no sistema de automação residencial proposto. No decorrer desta seção estão
destacadas em vermelho os blocos e códigos que sofreram alterações ou foram acrescidos devido às
necessidades deste TCC.
4.4.1 Visão Geral Da Plataforma

A solução de hardware utilizada neste TCC, tanto para a EM quanto para a EB, foi o modelo
TS60IP do fabricante Intelbras SA. Originalmente o produto TS60IP é um telefone VoIP, que para este
TCC, foram aproveitados seu hardware e substituídos o software da aplicação, adaptando o handset
(portátil) do produto transformando-o na EM e a base do produto foi transformada na EB.
4.4.1.1 EM
Entre as principais características da EM estão o processador ARM geração nove, ARM968E-S
da família Vega One do fabricante DSPG®, a interface de comunicação sem fio DECT, além de 30
portas de I/Os (GPIO) possibilitando a conexão de sensores e atuadores. As memórias utilizadas pela
EM são do tipo FLASH e EEPROM. A memória FLASH é utilizada para guardar informações do
software controle e possui capacidade de 1MB, já EEPROM é utilizada para guardar informações
enquanto a EM permanece desligada. A memória Flash está integrada no mesmo encapsulamento do
processador juntamente com hardware utilizado na interface DECT. Já a memória EEPROM é externa
e possui uma capacidade de armazenamento de 32 KBytes. Sua comunicação com o processador é
realizada através do barramento I²C (Inter Integrated Circuit). Para a EM destacam-se a solução one-
chip, que com exceção da memória EEPROM, disponibiliza todos demais itens necessários integrados
em um único encapsulamento, além do sistema operacional proprietário que é disponibilizado pelo
próprio fabricante.
53
Conforme apresentado na Seção 2.4, a EM possui um sistema operacional proprietário que faz
o controle da interface DECT, conforme detalhamento da Figura 22.
Figura 22 - Detalhamento da EM.
Para inserir a EM no contexto da automação residencial, foi necessário a inserção da aplicação

AARLD para interpretar os comandos recebidos da EB bem como realizar a leitura dos estados dos
sensores conectados na EM. Um maior detalhamento desta aplicação está descrito na Subseção 4.4.4.
Uma EM pode ser utilizada para acionamento e monitoramento de um ambiente acumulando as
duas funções em uma única estação, porém, para facilitar os testes cada EM executará somente uma
das funções, ou seja, uma EM preparada para acionamento não será capaz de realizar o
monitoramento. Na prática todas as EM’s podem ser utilizadas para as duas funções, já que todas
EM’s utilizam o mesmo hardware e software. A Figura 23 mostra a foto do hardware utilizado nas
EM’s.
1
2
Figura 23 – Foto do hardware da EM.

54
Na Figura 23 é possível identificar os principais componentes da EM. No item “1”, tem-se o

processador encapsulado juntamente com a o hardware DECT. Em “2” é possível ver a memória
EEPROM. Já no item “3” é possível observar a antena de RF, porta de comunicação entre as estações.
No item “4” é possível observar a entrada de alimentação da EM, que pode ser feita por bateria de
2.4V ou por fonte de alimentação externa.
A EM utilizada para simular a ativação dos sensores de barreira e demais eventos previstos na
Seção 2.5, pode ser vista na Figura 24.
Figura 24 - Foto da EM para emular as funções de abertura e fechamento.
A Figura 24 mostra um handset, que teve seu software alterado para atuar como uma unidade
do sistema de automação residencial. Nesta EM, poderão ser simulados os 3 eventos relativos a
unidade de monitoramento descritos na Seção 2.5, conforme pode ser visto na :
Item Código Evento
1 302 Bateria baixa
2 400 Aberto
3 459 Fechado
Tabela 18 - Descrição dos eventos simulados a EM.
Quando cada tecla é pressionada, é simulado seu respectivo evento e enviado à EB. O evento
de “Bateria Baixa” indica que a bateria da estação necessita recarga ou substituição. Esse evento será
utilizado para o caso da EM seja alimentada por bateria ao invés de uma fonte de alimentação. Já o
evento “Aberto” indica que houve abertura do sensor na região monitorada, enquanto o “Fechado”
indica o oposto.
Para realizar o acionamento de cargas foi utilizado o mesmo hardware da EM mostrado na

Figura 23, porém num invólucro diferente, conforme pode ser visto na Figura 25.
55
Figura 25 - EM atuador.
Na Figura 25 o item número “1” mostra a entrada de alimentação 220 V. Esta entrada é
utilizada para alimentar a carga que será conectada no local indicado pelo item “2”. No item “3” se
tem a fonte de alimentação da estação móvel, e por último, no item “4”, está o invólucro que comporta
o hardware mostrado na Figura 23, bem como a interface de acionamento mostrado na Figura 26.
Para que fosse possível acionar uma carga de maior potência, como por exemplo, uma
lâmpada, foi necessária uma interface para compatibilizar o nível da saída do processador com o da
carga, para isso, foi adicionado o circuito de interface mostrado na Figura 26.
Figura 26 - Circuito de interface de acionamento.

56
Quando o comando “ligar” é recebido pela EM atuadora, a porta 11 do processador é ativada

em nível lógico alto (3.3 V) acionando o relê e fornecendo 220 V à carga através da interface mostrada
na Figura 26.
4.4.1.2 EB
Entre as principais características da EB estão: o processador ARM geração nove, modelo
ARM926J da família Vega Firebird, também do fabricante DSPG®. Este processador é do tipo RISC
(Reduced Instruction Set Computing), opera com 32 bits de instruções e frequência de 220 MHz. Em
conjunto com o processador estão as memórias SDRAM e FLASH. A memória volátil SDRAM possui
16MB de capacidade e opera com um clock de 110 MHz fornecido pelo processador. A memória não
volátil FLASH possui 64MB de capacidade e é utilizada para armazenar os dados enquanto o produto
não está energizado. Para realizar a comunicação entre a rede local de dados e a EB foi utilizado o
switch KSZ8863 do fabricante MICREL, chamado de controlador Ethernet. Este switch possui três
portas de comunicação, sendo duas delas no padrão Ethernet e outra no padrão RMII para conexão
com o processador. Para a EB destaca-se o sistema operacional utilizado Linux Embedded e o sistema
operacional proprietário disponibilizado pelo fabricante.
A Figura 27 mostra a foto do hardware da EB.
Figura 27 - Foto hardware da EB.

57
Na Figura 27 estão destacados os principais componentes da EB. Em “1”, tem-se a entrada

de alimentação da EB, que é de 5.5 V por 900 mA. Em “2” estão as conexões Ethernet, por estas
conexões é que serão trocados os dados com a rede local. No item “3”, está o controlador Ethernet
(switch). Sua principal atribuição é receber os dados das portas Ethernet e encaminhá-los ao
processador, visto em “4”. Já no item, “5” tem-se a memória FLASH, é nela que os dados serão
armazenado durante a não energização do sistema. Em “6” tem-se a memória SDRAM. A SDRAM
está diretamente conectada ao processador dando suporte ao funcionamento do sistema operacional.
No item “7” está à interface de hardware do padrão DECT. Ela é responsável por receber os dados
captados pelas antenas, visto em “8” e enviá-los para o processador, visto em “4”.
A Figura 28 mostra em detalhes os blocos que representam os componentes de hardware e de

software da EB e como eles estão interconectados uns aos outros.
2
Figura 28 - Detalhamento da EB
É importante ressaltar que a DSPG®, fabricante dos chipsets utilizados em ambas as estações,
oferece uma solução completa, porém proprietária, para comunicação entre dispositivos DECT
cumprindo os requisitos especificados em norma pela ETSI.
2
Blocos destacados em vermelho representam as aplicações que serão desenvolvidas ou adaptadas neste TCC
58
Para que o sistema operacional Linux (“SO LINUX”) seja inicializado, é necessária a utilização
de um programa auxiliar chamado Bootloader ou (inicializador).
O Bootloader é um programa que é executado assim que a EB é energizada. O Bootloader
provê a inicialização de alguns dispositivos de hardware presentes no sistema, tais como: controladores
de Ethernet, portas seriais, memórias e até mesmo do próprio processador. Após a inicialização dos
recursos de hardware, o Bootloader carrega os arquivos necessários para a inicialização do sistema
operacional. Seu funcionamento é análogo ao de uma BIOS (Basic Input/Output System) utilizada em
placa mãe de computador. Porém ao invés de ser um chip dedicado, é um software que compartilha a
mesma memória do SO LINUX. O bootloader utilizado para esta solução é o U-BOOT (Universal
Bootloader).
Após execução do Bootloader, ocorre a inicialização do Kernel e, na sequência, serão
inicializados os softwares de aplicação do sistema de automação, tais como, servidor WEB, sistema
controlador DECT, sistema controlador de Ethernet, etc.
O Kernel é o programa responsável por gerenciar as requisições de acesso das aplicações aos
dispositivos de entrada/saída disponíveis servindo como interface entre o software e o hardware,
conforme mostra a Figura 29.
Aplicações/Comandos
KERNEL
Processador Memória Dispositivos
Figura 29 - Esquema de Interligação do Kernel.
O Kernel garante a todas as aplicações o acesso aos dispositivos disponíveis de maneira

organizada e íntegra, proporcionando o acesso simultâneo através da concorrência de processos.
(LINFO, 2005).
59
4.4.2 Interface de Controle Web
Para que seja possível o controle e interação do usuário com o sistema de automação
residencial, é necessária uma interface que interprete os comandos do usuário e os converta em
instruções para tal sistema.
A interface do sistema de automação foi construída com a linguagem HTML e complementada
com Java Script, JQuery e AJAX. O posicionamento e o formato são definidos pela estruturação da
linguagem HTML e o dinamismo das páginas é realizado através do uso da linguagem Java Script, da
API JQuery e da técnica de troca de dados AJAX.
Na interface de controle WEB foi utilizado um bootstrap open-source disponibilizado pelo
Twitter. Um bootstrap é uma página padrão, também conhecido como template, e traz consigo uma
disposição padrão, bem como, uma coleção de efeitos para aumentar o dinamismo das páginas. O
bootstrap utilizado é baseado em HTML, Java Script e JQuery podendo ser utilizado para diversas
aplicações que possuam a WEB como interface (BOOTSTRAP, 2013).
A partir do boostrap foram inseridos os objetos de controle necessários ao contexto da

automação residencial, tais como botões de acionamento e de exibição, campos de edição, além do
tratamento do comportamento para os botões adicionados. Na sequencia serão mostradas todas as
páginas que compreendem o sistema de automação residencial proposto.
4.4.2.1 Página de Login

Para obter acesso ao sistema de automação é necessário realizar a autenticação de usuário,
inserindo um login e uma senha válidos, conforme mostra a Figura 30.
Figura 30 – Página de autenticação.

60
4.4.2.2 Página Principal de Controle

Após o usuário entrar com os dados válidos de “User Name” e “Password” e pressionar o
botão Log In, o sistema automaticamente redirecionará para a página principal de controle do sistema
de automação. Para realizar a troca de valores de todas as EMs (EM 1 a EM 5), são requisitados ao
servidor somente os valores dos campos correspondente à EM que foi selecionada pelo usuário,
dispensando-se a necessidade de se realizar um outro pedido de arquivos HTML ao servidor devido ao
uso da técnica AJAX e JQuery detalhada na sequência.
Após o arquivo HTML ser totalmente carregado, é exibida ao usuário a página de controle
principal do sistema. Nesta página todo o conteúdo do arquivo index.htm é ocultado exceto o painel de
controle, que será utilizado para se navegar entre as opções disponíveis, conforme mostra a Figura 31.
Figura 31 – Página principal de configuração das EMs (1 a 5).
A Figura 31 mostra o painel de controle com as estações EM e opções disponíveis no sistema.

Conforme o usuário seleciona a EM que deseja operar, as informações ocultadas anteriormente são
exibidas de acordo com o contexto. Por exemplo, ao clicar no botão referente à “EM1”, o navegador
exibe os campos referentes EM1 e realiza uma nova requisição ao servidor WEB solicitando apenas os
valores dos campos específicos ao contexto da EM selecionada. Isso exime o navegador da
necessidade de requisitar o arquivo HTML novamente. Esses valores são atualizados na página
61
correspondente a EM1 antes de sua exibição ao usuário dando a impressão que é uma página
totalmente nova, conforme mostra a Figura 32.
Caso o usuário clique no botão referente à “EM2” uma nova requisição de dados ao servidor
WEB é realiza agora com os valores referente à “EM2” e a mesma estrutura HTML é atualizada com
esses dados e exibida ao usuário.
Figura 32 - Página de controle EM1

As opções de controle e informações disponíveis referentes à “EM1” são mostradas na Figura
32. No campo “Serviços disponíveis” exibe qual a finalidade de determinada EM, ou seja, estas opções
selecionam o tipo de atividade que a EM será submetida. Quando a opção de “Controle” está marcada,
diz ao usuário que esta estação tem a possibilidade de realizar o controle de algum equipamento.
Analogamente acontece com o campo “Monitoramento” quando é selecionado.
Para realizar um comando de acionamento ou desligamento de determinado dispositivo de
forma imediata, é utilizado o campo “Controles Diretos”. Através dos botões disponíveis “Ligar” ou
62
“Desligar” exibidos na Figura 32, o comando escolhido será executado no equipamento que está
conectado na EM1.
Além dos controles diretos, é possível realizar uma programação para ligar ou desligar
determinado equipamento em determinado horário do dia, para isso, o campo “Controles
Programados” deve ser utilizado. Neste campo o usuário escolhe entre ligar ou desligar um
equipamento na data e a hora programada.
No campo “Monitoramento” exibido na Figura 32, é possível realizar a leitura de um sensor
conectado a determinada EM, para isso, é necessário pressionar o botão “Atualizar” dentro da aba
correspondente à EM desejada. Ao ser pressionado, uma mensagem de status será exibida com o
estado atual do sensor.
Ainda é possível atribuir o nome do eletrodoméstico que está sendo controlado, ou ainda,
atribuir o nome do ambiente e o andar em que a EM está instalada.
Para configurar a data e hora, trocar a senha de acesso do sistema de automação além das
programações disponíveis deve ser realizada através do botão “Configurações do Sistema” conforme
mostra a Figura 33.
63
Figura 33 – Página de configurações do sistema
Na Figura 33 é possível realizar todas as configurações necessárias ao sistema de automação

residencial.
O campo “Ajuste de Data e Hora” é responsável por atualizar o horário que será utilizado pelo
sistema de automação.
64
O campo “Agendamento de Controles” é responsável pelos agendamentos de controles

programados disponíveis para cada EM. Para fazer uso do agendamento o usuário deve preencher as
informações necessárias.
No campo “Ativo” marca se a programação será executada ou não.
No campo “Aplicar à Estação” deve ser escolhida a EM que se deseja executar o comando.
No campo data e hora deve ser inserida a hora e a data que se deseja que a programação ocorra.
No campo “Ação” o usuário deve escolher o comportamento de seu interesse, são eles: ligar,
desligar e simular ocupação. Quando escolhido ligar ou desligar, o sistema simplesmente acionará ou
desligará o equipamento controlado pela EM em questão.
No campo “Dados da EM” é possível identificar o ambiente de sua residência onde será
instalada uma EM para monitoramento ou controle. As informações deste cadastro serão utilizadas
posteriormente na seleção do campo “Parâmetros” na Figura 32.
No campo “Trocar Senha” é possível trocar a senha de usuário de acesso ao sistema de

automação.
4.4.3 Servidor Web e Ajax
Após a inicialização completa do Kernel e das aplicações, o sistema está pronto para operação.
A partir deste momento o servidor WEB permanece monitorando a porta 80 aguardando requisições
HTTP enviadas pelo navegador de internet, conforme apresentado na Seção 2.3.
O servidor WEB utilizado neste TCC foi o Mongoose WEB Server. Este servidor WEB é open-
source, ou seja, de código aberto, com foco para aplicações em sistemas embarcados, pois o tamanho
total do código compilado é cerca de 400 KB. Sua API (Application Programming Interface)
(MONGOOSE, 2013).
No código original do servidor WEB mongoose foram realizadas alterações a fim inseri-lo no
contexto da automação residencial. Essas alterações estão em destaque na Figura 28. As funções de
gravação, leitura e execução foram inseridas no código do servidor WEB para que, quando for
recebido um comando da interface WEB, o servidor execute respectiva função, acessando o arquivo
65
XML para leitura ou gravação, ou ainda encaminhando o comando de acionamento para determinada
EM. A Figura 34 mostra o fluxo com as principais funções do servidor WEB.
Figura 34 - Fluxo principal do servidor WEB.
Ao receber uma requisição na porta 80, o servidor WEB verifica se esta é do tipo AJAX. Caso
não seja, ele retornará o arquivo index.html ou o arquivo HTML que estiver armazenado no endereço
da requisição. Caso a requisição seja do tipo AJAX é possível classifica-las em dois diferentes
métodos: GET, para requisitar um dado, ou POST, para enviar um dado ao servidor. Caso seja um
método GET o servidor web chama a função responsável por realizar a leitura na base de dados XML,
que irá ler os dados e retornar os valores requisitados ao navegador. Caso seja um método POST,
66
poderá ser uma instrução de gravação de alguma informação na base de dados XML ou poderá ser
uma instrução de execução de um comando. Em ambos os casos o servidor WEB irá executar a função
relacionada a uri recebida e retornará a informação “TRUE” ou “FALSE” em caso de sucesso ou não,
respectivamente ao navegador de internet.
Uma requisição deve seguir um padrão devendo conter, por exemplo, método de acesso,
endereço IP de origem (host), caminho de localização do arquivo uri (Uniform Resource Identifier,),
além de algumas informações do navegador (user-agent) e autorização conforme pode ser visto nas
Figura 35 e Figura 36.
GET /ajax/get_data?func_name=out_get_ST&parameter=0&param=0 HTTP/1.1
Host: 10.0.0.6 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101
Firefox/24.0 Accept: application/json, text/javascript, */*; q=0.01 Accept-Language: en-
US,en;q=0.5 Accept-Encoding: gzip, deflate X-Requested-With: XMLHttpRequest
Referer: http://10.0.0.6/ Authorization: Digest username="admin", realm="TS60IP", nonce="68",
uri="/ajax/get_data?func_name=out_get_ST&parameter=0&param=0", response="
e0745bda90f950dafbc27d05a3521023", qop=auth, nc=00000022, cnonce="3e189c37e916a8dc
Figura 35 - Exemplo requisição AJAX GET
POST /ajax/set_data HTTP/1.1

Host: 10.0.0.6 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101
Firefox/24.0 Accept: application/json, text/javascript, */*; q=0.01 Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest Referer: http://10.0.0.6/ Content-Length: 94
Authorization: Digest username="admin", realm="TS60IP", nonce="68", uri="/ajax/set_data",
response="2bcb3a81de8921f81e77bfe67bda231e", qop=auth, nc=0000002b,
cnonce="b89a9ecb411e6946"func_name=in_set_DM&parameter=&sys_hour=00&sys_minute=16&
sys_day=21&sys_month=10&sys_year=2013
Figura 36 - Exemplo de requisição AJAX POST

A principal diferença entre a requisição GET e POST é que uma requisição POST contém no
caminho de localização de arquivo (uri) o endereço para uma função do tipo ajax/set_data enquanto a
do tipo GET contém o caminho ajax/get_data. Através destes caminhos é que o servidor WEB irá
identificar e executar a função equivalente ao comando que o usuário requisitou na interface de
controle, por exemplo, na Figura 35 a uri recebida foi:
67
uri="/ajax/get_data?func_name=out_get_ST&parameter=0&param=0"
Através deste uri é possível saber que esta requisição HTTP refere-se ao método de acesso
GET e a função que será chamada pelo servidor WEB é a “out_get_ST”. Além disso, são passados
dois parâmetros, o “parameter” e o “param” ambos com o valor “0”.
Já no exemplo mostrado na Figura 36 a uri recebida foi:
uri="/ajax/set_data?func_name=in_set_DM&parameter=&sys_hour=00&
sys_minute=16&sys_day=21&sys_month=10&sys_year=2013”
Através deste uri é possível saber que esta requisição refere-se ao método de acesso POST
(set_data) e a função que será chamada pelo servidor WEB é a “in_set_DM”. Além disso, são passados
os parâmetros “parameter”, “sys_hour”, “sys_minute”, “sys_days”, “sys_month” e “sys_year” com
seus respectivos dados.
A função “in_set_DM é responsável por atualizar a data e hora do sistema de automação

residencial. Os valores referentes aos parâmetros recebidos são enviados ao sistema operacional Linux,
que atualiza a data e hora do sistema.
Além da função “in_set_DM”, existem outras que compõe o sistema de automação residencial.
As funções com o prefixo “in_set”, são executadas sempre que o usuário na interface WEB realizar
alguma alteração nos dados. Já as funções com o prefixo “out_get”, são executadas sempre que é
necessário carregar as informações gravadas no arquivo XML e transferi-los para a interface WEB. As
possíveis funções de acesso acrescidas no servidor WEB são:
B) A função “in_set_password”: altera a senha de acesso ao usuário;
C) A função “in_set_DM”: altera a data e a hora do sistema;
D) A função “in_set_AC”: altera os dados dos campos parâmetros e serviços disponíveis
das EMs.
E) A função “in_set_ST”: altera as programações de agendamentos das EMs,
F) A função “out_get_DM”: refere-se a leitura das informações de data e hora do sistema,
G) A função “out_get_ST”: refere-se a leitura das informações de agendamentos das EMs,
H) A função “out_get_AC”: refere-se a leitura das informações dos campos parâmetros e
serviços disponíveis das EMs ; e
I) A função “out_get_MU”: refere-se a leitura das informações do campo status de
monitoramento das EMs.
68
4.4.4 Implementação das Funções Auxiliares Ajax App

AJAX_APP são funções auxiliares inseridas no código do servidor WEB servindo de interface
entre o servidor WEB e as bibliotecas utilizadas para leitura, gravação e acesso aos dados. Todas
funções de acesso ao servidor WEB descritas na Subseção 4.4.3 utilizam uma função auxiliar
AJAX_APP específica, seja para gravação ou para acesso dos dados, por exemplo, a função in_set_ST
é uma função de gravação de dados e utiliza a função AJAX_APP para atualizar a variável local e
acessar biblioteca para gravação em arquivo XML, conforme mostra o fluxo na Figura 37.
Figura 37- Fluxo de acesso à AJAX_APP através de in_set_ST.
A Figura 37 mostra um exemplo de execução da função in_set_ST. Essa função é utilizada

quando o usuário realiza uma gravação no agendamento de tarefas na interface WEB. Ao pressionar o
botão salvar na interface WEB, o navegador faz uma requisição através do método POST contendo nos
argumentos o nome da função “in_set_ST”. Quando a função “in_set_ST” for executada irá também
executar uma das funções auxiliares da AJAX_APP a “ajax_set_task”. A ajax_set_task além de
armazenar os dados recebidos em memória RAM, também acessará a biblioteca XML e realizará o
salvamento dos dados em arquivo XML, retornando TRUE caso o processo ocorra com sucesso. Outro
exemplo de acesso às funções de AJAX_APP pode ser visto na Figura 38.
Figura 38 - Fluxo de acesso à AJAX_APP através de out_get_ST.

69
Neste outro exemplo mostrado na Figura 38, a função de acesso é a “out_get_ST”. Essa função
é executada quando o usuário acessa na interface WEB os campos referentes às informações de
agendamento de tarefas. Quando esses campos são acessados, o navegador faz uma requisição do
método GET ao servidor WEB contendo nos argumentos o nome da função que deseja acessar a
(out_get_ST). Quando a função “out_get_ST” for executada, fará o acesso à biblioteca XML através
das funções auxiliares AJAX_APP, neste caso a função “ajax_get_task” que, além de acessar a
biblioteca XML, atualizará a variável local e retornará os dados lidos para navegador de internet exibir
ao usuário.
Todas as funções do servidor WEB utilizam uma função auxiliar AJAX_APP específica,
variando conforme a ação que a função irá executar.
4.4.5 XML Database

Para o armazenamento dos dados passíveis de modificação pelo usuário foi utilizado a
linguagem de marcação XML (eXtensible Markup Language), conforme exposto na Seção 2.3. Para a
manipulação de arquivos XML foi utilizada a biblioteca Mini-XML open-source permitindo-se
customizações caso necessário. Seu código fonte pode ser encontrado em minixml.org.
No padrão XML os dados são gravados em um simples arquivo com a extensão “xml” onde a
variável de interesse é armazenada entre dois campos iguais seguidas do símbolo de “<” menor e “>”
maior para marcar o início, e finalizada pela mesma sequência, porém acrescido do caractere barra “/”,
similarmente a linguagem HTML, conforme o exemplo:
<campo> VALOR </campo>
A marcação “<campo>”, é uma TAG (etiqueta) que identifica o valor que está sendo
armazenado. Para marcar a finalização outra TAG, porem acrescida do caractere barra, é inserida na
sequencia “</campo>”, sendo armazenado o valor de interesse o conteúdo presente entre as TAGS.
Os dados são armazenados de forma idêntica para as cinco possíveis EM’s do sistema de
automação. Para cada EM é necessário guardar seu id, o tipo de serviço que ela oferece ao usuário e
informações do ambiente, conforme mostra a Figura 39.
70
<?xml version="1.0" encoding="UTF-8" ?>

<em0>
<id>0</id>
<services_control>1</services_control>
<services_monitoring>0</services_monitoring>
<monitoring_message >Comando desligar OK</monitoring_message >
<parameters_equipament >Lâmpa da</parameters_equipament >
<parameters_ambient >Cozinha</parameters_ambient >
<parameters_f loor>Prime iro andar</parameters_floor>
</em0>
<em1>
<id>1</id>
<services_control>1</services_control>
<services_monitoring>1</services_monitoring>
<monitoring_message >Rompimento de barreira</monitoring_message >
<parameters_equipament >Sensor porta </parameters_equipament >
<parameters_ambient >Sa la </parameters_ambient >
<parameters_f loor>Prime iro andar</parameters_floor>
</em1>
…
Figura 39 - Arquivo XML de configuração das EMs
O campo <emX> identifica a estação móvel pertence as informações que estão na sequência. O
“X” pode variar seu valor de 0 a 4 correspondendo as 5 estações móveis possíveis no sistema de
automação.
No campo <id> está armazenado o índice da estação, sua numeração acompanha a sequência
do campo anterior. Porém este valor será utilizado para identificação da EM na execução do sistema.
Os campos <services_control> e <services_monitoring> armazenam a informação dos serviços

que a EM está apta a realizar, por exemplo, se services_control estiver com o valor “1” significa que
esta EM é capaz de realizar o controle de determinado equipamento e o painel de controle respectivo é
habilitado na interface WEB de controle. Dessa maneira, o campo “services_monioring” define a
possibilidade de operar com serviços de monitoramento.
Os campos “<parameters_equipament>”, “<parameters_ambient>” e “<parameters_floor>”

servem para identificação quanto à localização da EM. Como o próprio nome já diz o primeiro campo
armazena o equipamento que está sob o monitoramento desta EM, o segundo campo guarda o
ambiente em que ela está operando e, por fim, o terceiro campo, armazena o andar em que o
equipamento esta presente, caso possua.
71
Essas informações existem para as cinco estações móveis e são armazenadas na memória
FLASH, através dos arquivos XML.
Além das informações cadastrais das estações, são armazenadas também as informações de
agendamento de tarefas visando o cumprimento do requisito funcional 04 na Subseção 4.2 em que é
possível para cada estação móvel realizar um agendamento para ligar/desligar um equipamento em um
horário pré-determinado. Estes dados são armazenados no padrão XML conforme mostra a Figura 40.
<unit0> <unit1>
<id>0</id> <id>1</id>
<active>1</active > <active>1</active >
<day>1</day > <day>1</day>
<month>8</month> <month>9</month>
<year>2013</year> <year>2013</year>
<hour>14</hour> <hour>11</hour>
<minut >00</minut > <minut >30</minut >
<action>0</action> <action>2</action>
<repeat>0</repeat > <repeat>2</repeat >
</unit0> </unit1>
Figura 40 - Arquivo XML de agendamento das EMs
O campo “<unit0>” marca o inicio das configurações referentes à EM 1, finalizados pelo

campo “</unit0>.
Similarmente a Figura 39 o campo “<id>” é utilizado para identificar a qual estação pertence os
dados que virão na sequencia.
O campo “<active>” marca se o agendamento para esta estação está ativo ou não, utilizando os
valor 1 e 0 respectivamente.
Os campos: “<day>”, “<month>”, “<year>”, “<hour>” e “<minut>” armazenam a data do

agendamento escolhido pelo usuário.
Em “<action>” é armazenado o tipo de ação que o usuário deseja que aconteça no momento
programado, por exemplo, “Desligar” ou “Ligar” representeados pelos valores 0 e 1 respectivamente.
Este último é utilizado principalmente em lâmpadas e mantém um comportamento similar ao de um
ambiente ocupado por pessoa, onde as lâmpadas do ambiente ligam e desligam em momentos
aleatórios.
72
Os dados referente à configuração das estações e variáveis estão concentradas em um único

arquivo XML chamado “hasmanager.xml”.
4.5 IMPLEMENTAÇÃO DO PROTOCOLO

Para que a comunicação entre a EB e as EMs ocorra de forma controlada e para que seja
possível a escalabilidade das estações, é necessário a implementação de um protocolo de comunicação
entre elas. Conforme descrito na Seção 2.5, foi escolhido o protocolo o Contact ID, pois este já dispõe
de uma série de mensagens padrões, facilitando a comunicação entre sistemas no ramo de segurança e
monitoramento.
Para o sistema de automação residencial foram selecionadas as mensagens que se enquadram

no contexto e criado um arquivo de biblioteca denominado de HAS.h. Nesta biblioteca estão as
mensagens que foram selecionadas e que estão listadas na Tabela 1, na Seção 2.5.
Para a criação desta biblioteca foram utilizadas as instruções typedef e enum da linguagem C.
4.5.1 A Estrutura Has_Info_T

A biblioteca HAS.h é o arquivo base para o preenchimento dos campos previstos no protocolo
Contact ID. Ao ser transmitida uma mensagem entre dispositivos, deve ser seguida uma estrutura
padrão do protocolo Contact ID, conforme disposto a seguir.
ACCT MT QXYZ GG FCC S

Onde:
O campo “A” refere-se ao número de identificação estação que originou a mensagem. O valor
“0” indica que a mensagem tem origem da EB e “1” para EM. Esse campo é definido no enum
“has_comm_orig_e” mostrada na Figura 41.
typedef enum
{
HAS_COMMAND_ORIGIN_BASE = 0,
HAS_COMMAND_ORIGIN_MOBILE,
} has_comm_orig_e;
Figura 41 - Estrutura has_comm_orig_e

73
Já o campo “CCT” do protocolo indica o número de identificação do dispositivo que receberá a

informação. Esse campo é definido no enum “has_station_index_e” mostrada na Figura 42.
typedef enum{
HAS_MOBILE_STATION_0 = 0,
HAS_MOBILE_STATION_1,
} has_station_index_e;
Figura 42 - Estrutura has_station_index_e

O campo “MT” indica a prioridade da mensagem para o receptor e assume o valor “18” para
mensagem preferencial e “98” para mensagem opcional. Esse campo foi definido no enum
“has_event_type_e” mostrada na Figura 43.
typedef enum{
HAS_PREFERENTIAL_MSG = 18,
HAS_OPTIONAL_MSG = 98,
} has_event_type_e;
Figura 43 - Estrutura has_event_type_e
O campo “Q” identifica as informações específicas do evento ocorrido. Os possíveis valores

para esse campo são: “1’ para evento novo, “3” para fechamento do evento e “6” nova informação do
evento anteriormente informado. Esse campo é definido no enum “has_event_inf_e” mostrada na
Figura 44.
typedef enum{
HAS_NEW_STATUS_EVENT= 1,
HAS_CLOSING_STATUS_EVENT = 3,
HAS_REINFORMING_STATUS_EVENT = 6,
} has_event_inf_e;
Figura 44 - Estrutura has_event_inf_e
No campo XYZ tem-se a informação de qual tipo de evento foi ocorrido, seguindo a lista de
eventos eleitos na Tabela 1 na Seção 2.5. Esse campo é definido no enum “has_event_code_e”
mostrada na Figura 45.
74
typedef enum{
HAS_LOW_BAT = 302,
HAS_COMMUN_FAIL = 354,
HAS_OPENED = 400,
HAS_TURN_ON = 407,
HAS_TURN_OFF = 408,
HAS_CLOSED = 459,
} has_event_code_e;
Figura 45 - Estrutura has_event_code_e
O campo “GG” indica o número da repartição do ambiente. Este campo esta previsto pelo
protocolo Contact ID, mas não foi utilizado pelo sistema de automação.
O campo “FCC” indica o andar e zona em que está localizado a EM. Este campo também não
foi utilizado pelo sistema de automação.
O campo “S” que indica o checksum também não foi utilizado.
Com a definição dessas novas estruturas foi possível agrupá-las em uma única nova estrutura
de dados denominada has_info_t, conforme mostra a Figura 46.
typedef struct {
has_comm_orig_e command_origin; //Origem
has_station_index_e station_id; //Destino
has_event_type_e event_type; //Prioridade
has_event_inf_e event_info; //Tipo do evento
has_event_code_e event_code; //Evento (on/off)
}has_info_t;
Figura 46 - Estrutura has_info_t.

É através da estrutura has_info_t que as informações são encapsuladas e transmitidas pelas
estações EMs e EB.
4.6 IMPLEMENTAÇÃO DAS FUNÇÕES AARLL E AARLD
As funções AARLL e AARLD são responsáveis pelo tratamento das informações no lado
Linux e DECT, respectivamente. Essas funções têm como objetivo a inicialização da estrutura de
dados has_info_t e sua transmissão para a estação destino.
Para transferir dados entre processos foi utilizada a comunicação por socket.
Sockets são utilizados para implementar protocolos e serviços de redes por proporcionarem
uma interação entre processos. Os sockets, no sistema operacional Linux são representados através de
75
arquivos, assim como outros dispositivos, tais como CD-ROM, interface de rede, entre outros. E isto
permite que os dados sejam manipulados através do sistema de arquivos, possibilitando sua escrita e
leitura (ALVES, 2008). É através da troca de dados entre processos que se baseia o uso de socket
utilizado no HAS.
A aplicação AARLL, operando no lado Linux, fica aguardando o recebimento de dados via
socket, conforme mostra o fluxo na Figura 47. Esta aplicação provê uma interface entre o sistema
Linux e o sistema proprietário do fabricante.
Figura 47- Fluxo da aplicação AARLL.
Ao receber um socket a aplicação AARLL consulta na estrutura has_info_t se os dados têm

como destino a EB. Caso seja verdadeiro, significa que os dados foram enviados de uma EM e que
devem ser armazenados localmente para serem exibidos pela interface de controle WEB. Caso o
destino não seja a EB, significa que o sentido da comunicação é o oposto, ou seja, partindo da EB para
uma das EMs. Dessa maneira, os dados são inseridos na estrutura has_info_t e enviados via socket
para a aplicação AARLD ainda na EB.
76
A aplicação AARLD está presente tanto na EM quanto na EB, mas executam rotinas diferentes
dependendo da estação que está operando. Para facilitar a compreensão pode-se dividir a AARLD em
duas funções distintas e denominadas AARLD_EB e AARLD_EM.
A AARLD_EB é a aplicação que receberá os dados no sistema operacional proprietário. Sua
principal função é receber os dados da AARLL e encaminha-los para a aplicação DECT, que por sua
vez, irá transferir os dados para a estação destino. O fluxograma que descreve o comportamento da
AARLD_EB é mostrado na Figura 48.
Figura 48 - Fluxo da aplicação AARLD_EB
A Figura 48 mostra que a aplicação AARLD_EB fica à espera do recebimento de um socket.

Caso o tenha recebido, é feito uma verificação para saber se os dados são destinados à EB. Caso seja
falso significa que os dados são destinados à EM. Dessa maneira, os dados na estrutura has_info_t
recebidos da aplicação AARLL são enviados para a aplicação DECT, que os transmitirá para a EM.
Caso os dados sejam destinados à EB, então a AARLD_EB transmitirá um socket para a aplicação
AARLL, contendo os dados na estrutura has_info_t recebidos da aplicação DECT.
77
Já aplicação AARLD_EM, presente na EM, faz uma interface entre a aplicação DECT e a
interface de hardware presente EM. O fluxo desta aplicação é mostrado na Figura 49.
Figura 49 - Fluxo da aplicação AARLD_EM
A Figura 49 mostra o fluxo de execução da aplicação AARLD_EM, que além de ficar

monitorando se um comando foi recebido da EB pela aplicação DECT, faz a leitura de todos os
sensores disponíveis na EM. Caso seja recebido um comando da EB, é feita a verificação se o
comando é para “ligar” o equipamento. Caso verdadeiro, o pino GPIO11 da EM é levado a nível
lógico alto, fazendo assim com que a carga seja acionada. Caso a verificação seja falsa, significa que o
comando foi de “desligar” e o pino GPIO11 é levado a nível lógico baixo.
Sempre que AARLD_EM é executada, uma verificação nos sensores é realizada, porém não é
realizada uma verificação contínua, pois os sensores são detectados por interrupção.
78
Os sensores disponíveis para o sistema de automação residencial proposto são: sensor de nível
de bateria, sensor de abertura e o sensor de fechamento. Caso um desses sensores seja acionado, a
AARLD_EM será executada e, em sua execução, será identificado qual sensor ocasionou a
interrupção. Cada sensor possui um código descrito na biblioteca HAS.h, conforme mostra a Figura
45. Após este código ser identificado, a estrutura has_info_t é preenchida e entregue a aplicação DECT
que fará o envio da estrutura à estação destino. Neste caso a EB.
4.7 DIAGRAMA DE SEQUENCIA DO SISTEMA DE AUTOMAÇÃO

Na Figura 51 é possível visualizar o diagrama de sequência de execução de comando no
sentido EB para EM, enquanto na Figura 50 é possível visualizar o diagrama de sequência de leitura de
status no sentido contrário, EM para EB.
79
Figura 51 - Fluxo de atualização de mensagem de status EM > EB.

Figura 50 – Fluxo de envio de comando EB > EM
80
O exemplo utilizado na Figura 49 é de fluxo completo de um exemplo de consulta de status do

sensor de monitoramento em uma EM. Esse fluxo ocorre quando o usuário acessa a interface WEB
aciona o botão status do campo monitoramento. O princípio é similar ao exemplo anterior, com
exceção do método de acesso. Quando o usuário clica no botão status na interface WEB o navegador
de internet envia uma requisição do tipo GET para o servidor WEB contendo o nome da função que
deseja acessar, neste caso “out_get_MU”. A função out_get_MU invoca a função de acesso
AJAX_APP “ajax_get_EM_status” levando como argumento o número de identificação da estação
que deseja a informação. Esta por sua vez irá consultar os dados salvos na variável local “has_info_t”
se há algum evento pertinente ao número igual ao da estação a que está consultando. Caso haja a
informação é retornada ao navegador e exibida ao usuário. Caso contrário a mensagem “Sem
ocorrência” é exibida ao usuário.
Já a Figura 50 refere-se ao fluxo de acionamento completo da EB para a EM que realiza um

acionamento da carga, através da interface WEB. Quando o usuário aciona o botão “ligar” ou
“desligar” na interface WEB, o navegador envia uma requisição do método POST contendo no
argumento no nome da função que deseja acessar, neste caso a “in_set_has”. Essa função ao ser
executada pelo servidor WEB executará também uma função auxiliar AJAX_APP, e esta por sua vez,
invocará uma terceira função, a AARLL. Ao chegar à AJAX_APP um retorno do tipo bool (boolean
TRUE) é enviado ao navegador caso o fluxo até aqui tenha ocorrido com sucesso, caso contrário
retornará (FALSE). A AARLL munida do número da estação que lhe enviou a requisição irá popular a
estrutura has_info, com os campos do protocolo Contact ID e o enviará utilizando socket para a
aplicação AARLD_EB. A AARLD_EB, por sua vez, enviará os dados recebidos para a aplicação
DECT. A aplicação DECT se encarregará em fazer a transmissão dos dados da EB para EM. Após
transmitido, o dado será recuperado novamente pela aplicação DECT , mas agora presente na EM.
Esses dados repassados a aplicação AARLD_EM, que fará uma decodificação da estrutura has_info
em busca do comando que deve ser executado. Neste exemplo o comando enviado foi o de “ligar”
código 407. Este código fará com que a AARLD_EM envie o comando de ligar para interface de
hardware, que por sua vez, irá elevar o pino GPIO11 acionando a carga presente nesta EM.
A variável local has_info é atualizada sempre que há um evento novo ocorrido em qualquer
uma das EMs cadastradas no sistema de automação. Quando um sensor é ativado, a interface de
hardware gera uma interrupção de hardware e chamará a função AARLD_EM. A AARLD_EM irá
preencher a estrutura has_info com os dados coletados pelo sensor acrescidos dos dados de
81
identificação e os enviará a aplicação DECT. Esta é responsável por enviar os dados para a aplicação
DECT na outra estação, a EB. Com os dados na EB, recepcionados pela aplicação DECT, eles são
enviados para a aplicação AARLD_EB que, por sua vez, repassará esses dados à aplicação AARLL. A
AARLL fará a decodificação dos dados recebidos e os salvará em uma variável local permitindo um
futuro acesso. Assim, quando o usuário clicar no botão status atualizará a interface WEB com o valor
presente na variável local recentemente captado pelo sensor na EM.
5 DESCRIÇÃO DOS EXPERIMENTOS

Nesta etapa serão apresentados os testes e os resultados alcançados do sistema de automação
residencial.
5.1.1 Execução dos Testes

A fim de se testar o sistema de automação residencial, foi montado um cenário hipotético,
O intuito deste teste é verificar se o sistema está funcionando de acordo com o projetado, para
isso, foi utilizado como saída o acionamento um LED, presente na própria EM, representando o
acionamento de uma carga. Com o resultado esperado tem-se então testado o caminho EB  EM. Para
testar-se o monitoramento dos sensores da EM foi utilizado uma simulação dos eventos através do
teclado da EM, com conforme comportamento descrito na Seção 4.4.
Figura 52 - Cenário de testes

82
No cenário mostrado na Figura 52, o roteador R1 está ligado diretamente a um switch. O

roteador foi configurado para distribuir endereços IP dinamicamente a qualquer dispositivo que esteja
conectado na mesma rede que a sua. A EB, por estar conectada na mesma rede do roteador, através do
switch recebe um endereço IP do roteador. Para saber qual IP foi designado a EB é necessário acessar
o menu da EM Menu > Numero IP. Uma tela com o endereço IP da EB será mostrada, conforme a
Figura 53.
Figura 53- Tela número IP

Através deste endereço (10.0.0.8) é que será possível acessar a interface de controle da EB.
Com o auxílio de um computador e um smartphone, foi acessado o endereço da EB através do
navegador de internet Google Chrome.
Ao acessar o da EB, uma autenticação é requerida as informações de acesso padrão são: admin
para usuário e admin para senha.
Com o acesso liberado, o primeiro teste executado foi o acionamento da estação EM1, que
neste teste está 30 metros distantes da EB. Para isso, foi pressionado o botão EM1 no painel de
controle e também o botão “Ligar” referente à EM1. O navegador de internet exibiu uma confirmação,
conforme pode ser visto na Figura 54.
Figura 54 - Confirmação de envio.

Além da confirmação exibida pelo navegador, foi observado também que a carga (lâmpada),
presente na EM1 foi acionada de acordo com o que havia sido projetado. A saída deste comando pode
ser vista na Figura 55.
83
Figura 55 – Acionamento da carga na EM 1.

Ainda no navegador, a mensagem de status “Acionado” passou a ser exibido depois de
pressionado o botão “Ligar”, conforme mostra a Figura 56.
Figura 56 - Mensagem de status “Ligar”.
Na sequência foi pressionado o botão “Desligar”, e a EM 1 voltou ao estado inicial, ou seja,

com a carga desacionada. Novamente a mensagem de status foi atualizada para “Desacionado”,
Figura 57 - Mensagem de status "Desligar"
O mesmo comportamento ocorre nas duas EM disponíveis no sistema de teste, EM1 e EM2.
Para testar-se a operação dos sensores, foram acionadas as teclas conforme mostrado na Figura
58. Cada tecla pressionada envia um evento para a EB com o código do evento ocorrido, simulando
um sensor que foi ativado.
84
Figura 58 - Botões com eventos simulados.
O botão destacado no item “1” quando pressionado, simula o status de bateria baixa e envia a
essa informação para a EM. Após ter sido pressionado o botão “1”, foi pressionado o botão de status
na interface de controle WEB para que seja atualizado o status na tela, conforme mostra a Figura 59.
Figura 59 - Status monitoramento "Bateria Baixa"
Já no botão destacado no item “2” quando pressionado indica que houve uma abertura do
sensor de barreira monitorado, simulando uma porta ou janela que se abre e possua um sensor de
barreira instalado. A mensagem de status é mostrada conforme mostra a Figura 60.
Figura 60 - Status monitoramento "Abertura"
O botão destacado no item “3” quando pressionado indica que houve um fechamento do sensor
de barreira monitorado, simulando uma porta ou janela que se fecha e possua um sensor de barreira
85
instalado, ou ainda o fechamento da mesma porta ou janela que se acusou o status de aberto
anteriormente. A mensagem de status é mostrada conforme mostra a Figura 61.
Figura 61 - Status monitoramento "Fechado".
Ao final deste teste é possível dizer que os sensores e atuadores estão funcionando conforme
previsto.
Na página de “Configurações”, foram primeiramente testados os ajustes de data e hora do

sistema. Para isso, foram preenchidas as informações de data e hora atuais e pressionado o botão
“Salvar” referente a este campo, conforme mostra a Figura 62.
Figura 62 - Configuração data e hora.

O navegador de internet mostra a confirmação de envio, conforme pode ser vista na Figura 63.
Figura 63 – Confirmação de envio

Ainda na página de configurações foi testado o item controles agendados. Para isso, foi
programada para que a EM1 executasse o comando de “Ligar” em determinado horário, conforme
pode ser visto Figura 64.
86
Figura 64 - Configurações "Agendamento de Controles"

Ao clicar no botão salvar, o navegador envia os dados para a EB e a página de status da EM1 é
atualizada com a nova programação conforme mostra a Figura 65.
Figura 65 - EM1 Status de Controles Agendados
Como saída deste agendamento obteve-se o acionamento da carga presente na EM1.
No campo “Dados da EM”, são inseridos os dados que se deseja que atribuir a uma das EMs,
para isso, foi preenchido os dados conforme mostra Figura 66.
Figura 66 - Configurações “Dados da EM".

87
Ao clicar pressionar o botão salvar, as informações da EM1 são atualizadas de acordo com os
novos dados inseridos, conforme mostram a Figura 67 e a Figura 68.
Figura 67 - Informações parâmetros.
Figura 68- Serviços Disponíveis.
No campo “Trocar Senha” foi preenchido a senha atual e uma nova senha para testar a troca de
senha de acesso à interface WEB, conforme mostra a Figura 69.
Figura 69 - Configurações "Trocar Senha".
Ao clicar no botão salvar o navegador exibe uma mensagem de confirmação de envio,

88
Figura 70 – Confirmação de envio de nova senha.

Após todos os itens de controles disponíveis na EB terem sido executados é possível concluir
que o sistema de automação residencial está operando de acordo com que foi projetado.
89
5. CONCLUSÕES
A automação residencial é um mercado em constante crescimento e evoluções, seguindo os

passos da evolução tecnológica de telecomunicações no que se refere à isenção da necessidade de fios
para a comunicação entre dois pontos. Nas pesquisas bibliográficas realizadas no decorrer deste
trabalho, ficou bastante evidenciado a necessidade de criação de um equipamento capaz de executar as
tarefas programadas pelo usuário e que dispense a necessidade de modificações das residências para
sua instalação. Foi percebido também que tal dificuldade é tratada como limitante de expansão do
mercado de automação.
Atualmente já existem sistemas de automação residencial que fazem uso de comunicação sem
fio em suas soluções, porém nenhum sistema comercial encontrado na pesquisa realizada faz uso do
protocolo DECT, cujo tema é a proposta deste trabalho.
O protocolo DECT se caracteriza como uma boa opção para aplicação em sistemas de
automação residencial devido a sua capacidade de alcançar grandes distâncias e também devido a sua
difusão no mercado de telefonia residencial, tornando a solução competitiva. Nos testes realizados com
o sistema de automação, em uma distância de 30 metros entre a EB e a EM, foi obtido o
comportamento esperado, ligando ou desligando uma carga experimental através dos controles diretos
e também através do agendamento de tarefas. No que diz respeito à leitura do estado dos sensores, o
sistema se comportou conforme o planejado, informando o status correto de acordo com o evento
ocorrido.
Na classificação quanto ao nível de integração de sistemas de atuação residencial, o HAS

manteve-se na categoria de “sistemas integrados”, devido à sua capacidade de controlar múltiplos
subsistemas a partir de um controlador central, no caso a EB. Além de oferecer uma interface de
controle baseada em tecnologia WEB, o que provê ao usuário uma mobilidade e uma capacidade de
interação com os recursos oferecidos pelo sistema de automação.
Neste trabalho foram abordados conhecimentos na área de automação residencial desde seu
surgimento até suas evoluções, além de ter sido possível identificar algumas necessidades do mercado
de automação residencial presente nos dias atuais. Foram apresentados também os conceitos de
sistemas embarcados, servidor WEB, o funcionamento básico do padrão DECT e protocolos de
comunicação, proporcionando um envolvimento com conhecimentos multidisciplinares como, por
90
exemplo, integração e desenvolvimento de software e hardware. Além disto, este TCC poderá servir
como artefato para prova de conceito com a tecnologia DECT aplicada na automação residencial,
tornando possível a realização de experimentos e validações no protótipo confeccionado e fazendo jus
a um trabalho de conclusão de curso na área de engenharia da computação.
91
5.1. TRABALHOS FUTUROS
Neste tópico serão apresentadas algumas sugestões para trabalhos futuros que utilizam as
tecnologias propostas neste trabalho visando seu aperfeiçoamento.
Incluir um maior número de agendamento de tarefas através, permitindo assim que usuário
faça mais de uma programação por EB.
Expandir o número de EM por EB, maximizando o aproveitamento do sistema de

automação residencial. Atualmente são possíveis cinco EMs em cada EB.
Realizar atualização da hora através de protocolos de rede já disponíveis, tais como NTP.
Implementar um feed back no acionamento de uma carga, onde a EM enviaria uma resposta
a confirmação de acionamento à EB.
Implementar relatórios de uso e consumo de energia afim de saber o eletrodoméstico mais

utilizado da residência e/ou com maior consumo de energia.
Realizar a integração com outros sistemas de monitoramentos com a possibilidade de

interação e controle entre eles.
Implementar um controle remoto universal utilizando infravermelho., onde seja possível

controlar diversos equipamentos da residência utilizando o HAS.
Integrar o sistema com outras tecnologias de comunicação sem fio, tais como ZigBee e Wi-
Fi.
92
REFERÊNCIAS BIBLIOGRÁFICAS
ALMEIDA, Alexandre Vaz de. Implementação de um sistema de automação residencial modular

sem fio: Modulo periférico. 2009. Trabalho de conclusão de curso – USP
ALVES, Maicon Melo. Socket Linux. Rio de Janeiro: SP: Brasport Livros, 2008.
ANATEL. Agência Nacional de Telecomunicações. Faixa de Frequência, 2013. Disponível em:

<http://sistemas.anatel.gov.br/pdff/Consulta/Consulta.Asp?intPagina=3&intLivro=0>. Acesso em: 14
Abr. 2013.
AURESIDE. Automação Residencial. Desmistificando a Domótica, 2007. Disponível em:

<http://www.aureside.org.br/artigos/default.asp?file=01.asp&id=74>. Acesso em: 19 Nov. 2012.
AURESIDE. Automação Residencial. Benefícios da Automação, 2013. Disponível em:

<http://www.aureside.org.br/temastec/default.asp?file=concbasicos.asp>. Acesso em: 13 Abr. 2013.
AURESIDE. Automação Residencial. Níveis de Integração, 2013. Disponível em:

<http://www.aureside.org.br/quemsomos/default.asp?file=objetivos.asp>. Acesso em: 02 Jun. 2013.
AXELSON, Jan. Embedded Ethernet and Internet Complete. Madison: Lakeview, 2003.
BOOTSTRAP. Bootstrap, 2013. Disponível em: < http://getbootstrap.com/>. Acesso em: 02 Nov.
2013.
CISCO. Instituto Telecom. Tráfego de dados móveis terá crescimento de 92% ao ano, diz Cisco,
2011. Disponível em:
<http://www.institutotelecom.com.br/index.php?option=com_content&view=article&id=1703%3Atraf
ego-de-dados-moveis-tera-crescimento-de-92-ao-ano-diz-cisco&catid=1%3Alatest-news&lang=pt >.
Acesso em: 06 Mar. 2013.
CERUTTI, Fernando. Comunicação de Dados e Redes de Computadores, 2000. Disponível em:

<http://inf.unisul.br/~cerutti/disciplinas/redes1/comp letas.pdf>. Acesso em: 14 Abr. 2013.
CYBERTRONICS. Sistemas de Automação Residencial, 2013. Disponível em: <

http://www.cybert.com.br/>. Acesso em: 02 Jun 2013.
ETSI. European Telecommunications Standard Institute. DECT History and Success, 2013.
Disponível em < http://www.etsi.org/index.php/technologies-clusters/technologies/dect >. Acesso em:
06 Mar. 2013.
ETSI. European Telecommunications Standard Institute. DECT Physical Layer(PHL), 2005.

Disponível em : <
http://www.etsi.org/deliver/etsi_en/300100_300199/30017502/02.04.00_40/en_30017502v020400o.pd
f >. Acesso em: 14 Abr. 2013.
93
FOROUZAN, Behrouz A. Comunicação de Dados e Redes de Computadores. São Paulo: SP:

Artmed Editora, 2004.
GIL, Antônio Carlos. Métodos e Técnicas de Pesquisa Social. São Paulo: Editora, 2008.
GESSLER, Fredrik. The Development of the DECT standard, 2000. Disponível em:
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.26.9980&rep=rep1&type=pdf>.Acesso
em: 14 Abr.2013.
HALLINAN, Christopher. Embedded Linux Primer: A Pratical, Real-Work Aproach.US: Prentice

Hall, 2007.
LINFO. The Linux Information Project, 2005. Disponível em: <http://www.linfo.org/kernel.html>.

Acesso em: 02 Nov. 2013.
MARIN, Paulo Sergio. Automação Residencial: Visão Geral e Aplicações, 2002. Disponível em:
<http://www.paulomarin.com/Files/home_automation_article.pdf>. Acesso em 02 Jun 2013.
MINORU, Milton. Mercado de automação residencial dá sinais de crescimento, 2011. Disponível

em: <http://portal.tecpar.br/index.php/pt/noticias/1781-mercado-de-automacao-residencial-da-sinais-
de-crescimento>. Acesso em: 02 Dez. 2012.
MORIMOTO, Carlos E. Hardware o Guia Definitivo. Porto Alegre: Editora Meridional, 2007.
MONGOOSE. The Mongoose WEB Server, 2013. Disponível em:

<https://code.google.com/p/mongoose/>. Aceso em: 02 Nov. 2013.
MURATORI. José Roberto; DAL BÓ, Paulo Henrique. Soluções em automação residencial, 2007.
Disponível em: <http://www.instalacoeseletricas.com/download/Automacao_residencial4.pdf>.
Acesso em: 19 Nov. 2012.
OXFORD, Dictionary. Dicionário de Oxford 2013. Disponível em:

<http://oxforddictionaries.com/definition/american_english/automation?region=us&q=automation>.
Acesso em: 02 Jun. 2013.
PEREIRA, Kalinne Rayana Cavalcanti. Sistema para Controle e Supervisão Remota para
Automação Residencial. 2009. Trabalho de conclusão de curso - UFRN
PHILLIPS, John.; NAMEE Mac, Gerard. Personal Wireless Communication With DECT and
PWT. Norwood: MA: Arthec House INC, 1998.
94
SIA. Contact ID protocol, 1999. Disponível em: <http://www.palmettosecurity.org/wp-

content/uploads/2012/03/DC-05_Contact_ID.pdf>. Acesso em: 24 Mar. 2013.
SILVA, E. L. da; MENEZES, E. M. Metodologia da pesquisa e elaboração de dissertação. 4. ed.

Florianópolis: UFSC, 2005. Disponível em: <
http://www.portaldeconhecimentos.org.br/index.php/por/content/download/12566/125574/file/024_Me
todologia%20de%20pesquisa%20e%20elaboracao%20de%20teses%20e%20dissertacoes.pdf> Acesso
em: 09 Jul. 2013.
SOLIDMATION. Sistemas de Automação Residencial, 2013. Disponível em: <

http://www.solidmation.com/pt/index.shtml>. Acesso em: 02 Jun 2013.
TANNENBAUM, Andrew S. Redes de Computadores. 4. ed. São Paulo: Elsevier, 2003.
TECHTERMS. Query Thechical Therms, 2013. Disponível em: <

http://www.techterms.com/definition/webpage>. Acesso em: 7 Abr. 2013.
TEIXEIRA, Edson Rodrigues Duffles. PLC – Power Line Communications, 2005. Disponível em:
<http://www.teleco.com.br/tutoriais/tutorialplc/pagina_1.asp>. Acesso em: 02 Jun 2013.
ZIEHER, Martin. Information Technology Module: Computer Networks, 2006. Disponível em: <
http://www.it.fht-
esslingen.de/~zieher/vorlesungen/ComputerNetworks/lectures_CN/C2.LANs_IT1.pdf>. Acesso em: 7
Abr. 2013.
ZANDONÁ, Pablo Tirloni. Interface homem maquina para domótica baseada em tecnologias web
em um servidor embarcado. 2012. Trabalho de conclusão de curso – UNIVALI.
W3SCHOOLS. AJAX Introduction, 2013. Disponível em:

<http://www.w3schools.com/ajax/ajax_intro.asp>. Acesso em: 14 Abr. 2013.

TCC de Redes Servidos Web

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TCC de Redes Servidos Web

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE DO VALE DO ITAJAÍ

CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR

DESENVOLVIMENTO DE UMA APLICAÇÃO DE AUTOMAÇÃO

Walter Gontijo, M. Eng.

São José, Novembro / 2013

UNIVERSIDADE DO VALE DO ITAJAÍ

DESENVOLVIMENTO DE UMA APLICAÇÃO DE AUTOMAÇÃO

Orientador: Walter Gontijo, M. Eng.

Dedico este trabalho à minha família, que junto comigo

Ao professor e orientador Walter Gontijo por suas correções e orientações durante o

Figura 1 - Esquema de conexão entre as estações EB e EM’s. .......................................................... 11

Figura 45 - Estrutura has_event_code_e ............................................................................................ 74

Tabela 1 - Eventos do protocolo Contact ID referentes ao campo XYZ. .......................................... 37

LISTA DE ABREVIATURAS E SIGLAS

AARLD Aplicação Automação Residencial Lado DECT

3.3 INTERFACE HOMEM-MÁQUINA PARA A DOMÓTICA BASEADA EM

1.1 PROBLEMA DE PESQUISA

1.1.1 Solução Proposta

Este trabalho apresenta o desenvolvimento de um sistema de automação residencial utilizando

1.1.2 Delimitação de Escopo

Figura 1 - Esquema de conexão entre as estações EB e EM’s.

Esta seção formaliza os objetivos do trabalho, conforme descrito a seguir.

1.2.1 Objetivo Geral

1.2.2 Objetivos Específicos

1. Apresentar o padrão DECT;

1.3.1 Metodologia da Pesquisa

De acordo com Silva e Menezes (2005), o método hipotético-dedutivo é observado quando o

Os objetivos desta pesquisa podem ser classificados em Exploratório e Explicativo.

1.3.2 Procedimentos Metodológicos

2.1 AUTOMAÇÃO RESIDENCIAL

A automação residencial, também conhecida como Domótica, é o uso da tecnologia para o

2.1.1 Topologia do Sistema De Automação Residencial

Figura 2 - Topologia de ligação automação residencial

2.1.2 Sistemas de Automação Residencial

Figura 3 - Arquitetura e dispositivos do sistema Habeetat

A Figura 3 mostra a arquitetura do sistema Habeetat interligada através de um centralizador

Figura 4 - Arquitetura e dispositivos da Cybertronics

A Figura 4 mostra a arquitetura do sistema de automação da Cybertronics disposta na topologia

2.2 O PADRÃO DECT

2.2.1 Características do padrão DECT

Figura 5 - Exemplo de um sistema DECT

Figura 6 - Distribuição das camadas do protocolo DECT

A distribuição de camadas do protocolo DECT é baseada no modelo OSI (Open System

Figura 7 - Comparativo das camadas do modelo OSI e do padrão DECT.

No comparativo entre as camadas dos modelos, mostrado na Figura 7, a camada física do

Conforme mostrado na Figura 6, existem dois planos de comunicação no padrão DECT, o C-

2.2.2 A Camada Física (PHL – Physical layer)

Figura 8 - Camada física.

Figura 9 – Canalização do padrão DECT utilizada no Brasil.

Figura 10 – Canalização do padrão DECT.

Usualmente os timeslots de 0 a 11 são utilizados para transmissão no sentido EB para a EM e

2.2.3 A Camada de Acesso à Mídia (MAC - Medium Access Control)

2.2.4 A Camada Link de Dados (DLC - Data Link Control)

A camada DLC é responsável pela confiabilidade na transmissão dos dados ou sinalizações

Figura 11 – Sequência de processamento da camada DLC

2.2.5 A Camada de rede (NWK - Networking)

Um exemplo do processo de troca de mensagens entre as camadas do padrão DECT é mostrado

Figura 12 - A sinalização entre as camadas do padrão DECT.

2.2.6 Código de Identificação

2.2.7 Registros de dispositivos DECT

O processo de registro é realizado pelo padrão DECT de forma transparente ao usuário. O

2.3 ESTAÇÃO BASE (EB)

No sistema de automação residencial baseado na tecnologia DECT a estação mestre é a EB.