Embed Size (px)
Citation preview
MINISTÉRIO DA DEFESA EXÉRCITO BRASILEIRO
DEPARTAMENTO DE CIÊNCIA E TECNOLOGIA INSTITUTO MILITAR DE ENGENHARIA
SEÇÕES DE ENGENHARIA ELÉTRICA, ELETRÔNICA E DE COMPUTAÇÃO
BRUNO NARDI DE CARVALHO DANTAS
JEFFERSON COSTA DE MATOS
VICTOR LAURINDO HORTA FERREIRA
SISTEMA MODULAR DE AUTOMAÇÃO RESIDENCIAL SOBRE CAN BUS
Rio de Janeiro
2014
INSTITUTO MILITAR DE ENGENHARIA
BRUNO NARDI DE CARVALHO DANTAS
JEFFERSON COSTA DE MATOS
VICTOR LAURINDO HORTA FERREIRA
SISTEMA MODULAR DE AUTOMAÇÃO RESIDENCIAL SOBRE CAN BUS
Projeto Final de Curso apresentado aos Cursos de Graduação em Engenharia Elétrica, Engenharia Eletrônica e Engenharia de Computação do Instituto Militar de Engenharia, como requisito parcial para obtenção de graduação.
Orientador: Prof. Amarildo Teodoro da Costa, D.Sc.
Rio de Janeiro
2014
INSTITUTO MILITAR DE ENGENHARIA Praça General Tibúrcio, 80, Praia Vermelha Rio de Janeiro-RJ CEP 22290-270
Este exemplar é de propriedade do Instituto Militar de Engenharia, que poderá
incluí-lo em base de dados, armazenar em computador, microfilmar ou adotar qualquer forma de arquivamento.
É permitida a menção, reprodução parcial ou integral e a transmissão entre
bibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que esteja ou venha a ser fixado, para pesquisa acadêmica, comentários e citações, desde que sem finalidade comercial e que seja feita a referência bibliográfica e completa.
Os conceitos expressos neste trabalho são de responsabilidade dos autores e
dos orientadores.
xxx.xx Dantas, B. N. C.; Matos, J. C; Ferreira, V. L. H. xxxxx
Sistema modular de automação residencial sobre CAN BUS / Bruno Nardi de Carvalho Dantas; Jefferson Costa de Matos; Victor Laurindo Horta Ferreira – Rio de Janeiro: Instituto Militar de Engenharia, 2014. 67p.
Projeto Final de Curso (graduação) – Instituto Militar
de Engenharia – Rio de Janeiro, 2014. 1. Domótica (Robótica). 2. Casa Inteligente (Robótica). I. Dantas, Bruno Nardi de Carvalho; Matos, Jefferson Costa de; Ferreira, Victor Laurindo Horta. II. Instituto Militar de Engenharia
CDD xxx.xx
2
INSTITUTO MILITAR DE ENGENHARIA
BRUNO NARDI DE CARVALHO DANTAS JEFFERSON COSTA DE MATOS
VICTOR LAURINDO HORTA FERREIRA
SISTEMA MODULAR DE AUTOMAÇÃO RESIDENCIAL SOBRE CAN BUS
Projeto Final de Curso apresentado aos Cursos de Graduação em Engenharia Elétrica, Engenharia Eletrônica e Engenharia de Computação do Instituto Militar de Engenharia, como requisito parcial para obtenção de graduação.
Orientador: Prof. Amarildo Teodoro da Costa, D.Sc. Aprovado em 2014 pela seguinte Banca Examinadora:
_____________________________________________ Prof. Amarildo Teodoro da Costa, D.Sc., do IME
_____________________________________________ Prof. Ricardo Choren Noya, D.Sc., do IME
_____________________________________________ Prof. Santos Sandro de Lima, M.C., do IME
Rio de Janeiro
2014
3
SUMÁRIO LISTA DE ILUSTRAÇÕES ......................................................................................... 4 LISTA DE TABELAS .................................................................................................. 5 LISTA DE ABREVIATURAS ....................................................................................... 6 1 INTRODUÇÃO ...................................................................................................... 9 1.1 Objetivo ................................................................................................................. 9 1.2 Justificativa .......................................................................................................... 10 1.3 Metodologia ......................................................................................................... 11 1.4 Estrutura da Monografia ...................................................................................... 11 2 ARQUITETURA DO SISTEMA ........................................................................... 13 2.1 Visão geral do sistema ........................................................................................ 13 2.2 Abstração em camadas ....................................................................................... 14 2.3 Protocolos de comunicação ................................................................................ 15 2.3.1 Gramática Slave - Android ............................................................................... 15 2.3.2 Gramática Android - Slave ............................................................................... 16 2.4 Arquitetura da rede Uni-multicast via filtragem e mascaramento CAN ............... 17 2.5 Funcionalidades e limitações .............................................................................. 19 3 SOFTWARE ........................................................................................................ 21 3.1 O Cliente Android ................................................................................................ 21 3.2 Interface de controle e identificação de módulos ................................................ 21 3.3 Interfaceamento Android – Master via Service .................................................... 22 3.4 Diagrama de classes e heranças ........................................................................ 23 4 HARDWARE ....................................................................................................... 26 4.1 Estrutura física de um nó ..................................................................................... 26 4.1.1 Nó Master ......................................................................................................... 27 4.1.2 Nó Slave 1 - Lâmpada LED IR ......................................................................... 32 4.1.3 Nó Slave 2 - Climatizador ................................................................................. 36 4.2 Firmware .............................................................................................................. 40 5 ROTEIRO DA PRÁTICA REALIZADA ............................................................... 45 6 CONCLUSÃO ..................................................................................................... 48 7 REFERÊNCIAS BIBLIOGRÁFICAS ................................................................... 51 8 APÊNDICE .......................................................................................................... 55 8.1 Figuras da prática realizada ................................................................................ 55
4
LISTA DE ILUSTRAÇÕES
FIG 2.1 – Abstração em camadas dos protocolos empregados............................. 14
FIG 3.1 – Diagrama de classes e heranças geral................................................... 24
FIG 3.2 – Detalhe da construção de diferentes tipos de nós.................................. 25
FIG 4.1 – Esquema da geral da prática realizada................................................... 26
FIG 4.2 – Diagrama simplificado do Nó Master....................................................... 28
FIG 4.3 – Diagrama de pinos do microcontrolador. (MICROCHIP, 2007, p.2)........ 29
FIG 4.4 – Diagrama de blocos RN42N. (ROVING, 2013, p.1)................................ 30
FIG 4.5 – Esquemas de osciladores. (ARNEROBOTICS, 2014)............................ 30
FIG 4.6 – Esquema de ligação capacitor. (MICROCHIP, 2007, p. 23)................... 31
FIG 4.7 – Diagrama de pinos do transceiver. (MICROCHIP, 2010, p.1)................. 32
FIG 4.8 – Diagrama de blocos do transceiver. (MICROCHIP, 2010, p.1)............... 32
FIG 4.9 – Diagrama do nó Slave 1.......................................................................... 33
FIG 4.10 – Interface do transceiver CAN com o barramento e o PIC. (MIKROELEKTRONIKA, 2010)..............................................................
34
FIG 4.11 – Esquemático do Fotoacoplador 4n25. (FAIRCHILD , 2002, p.1).......... 35
FIG 4.12 – Conjunto Lâmpada e controle remoto. (MERCADO LIVRE, 2014)....... 36
FIG 4.13 – Diagrama do nó Slave 2........................................................................ 37
FIG 4.14 – Diagrama de Pinos e de Lógica do Fotoacionador. (TEXAS INSTRUMENTS, 1995 p.1)....................................................................
38
FIG 4.15 – Diagrama de Pinos do TRIAC empregado. (SNUBBERLESS & STANDARD, 2002, p.1).........................................................................
39
FIG 4.16 – Esquemático para acionamento de cargas indutivas. (TEXAS INSTRUMENTS, 1995, P.4)..................................................................
40
FIG 5.1 – Esquema inicial da prática 45
FIG 5.2 – Comando Refresh................................................................................... 45
FIG 5.3 – Estado da lâmpada.................................................................................. 46
FIG 5.4 – Estado do climatizador............................................................................ 46
FIG 5.5 – Comando para ligar luz........................................................................... 46
FIG 5.6 – Comando para acionar ventilador........................................................... 47
5
LISTA DE TABELAS
TAB 2.1 – Gramática Android – Slave…………………………………………………… 16
TAB 2.2 – Gramática Slave – Android…………………………………………………… 17
TAB 2.3 – Máscaras e comportamentos………………………………………………...
18
TAB 4.1 – Seleção de capacitores (MICROCHIP, 2007, p. 23)………………………
31
6
LISTA DE ABREVIATURAS
ACK - Acknowledge ADC - Analogic Digital Converter API - Application Programming Interface CAN BUS - Controller Area Network Bus CPU - Central Processing Unit GUI - Graphical User Interface IDE - Integrated Development Environment I/O - Input/Output KWh - KiloWatt-hora LDR - Light Dependant Resistor MACA - Multiple Access Colision Avoidance MVC - Model-View-Controller OSI - Open Systems Interconnection PLC - Power Line Carrier RAM - Random Access Memory ROM - Read-only Memory SMD - Surface-Mount Device TC - Transformador de Corrente TRIAC - Triode for Alternating Current UART - Universal Asynchronous Receiver/Transmitter USART
-
Universal Synchronous-Asynchronous Receiver/Transmitter
USB - Universal Serial Bus UML - Unified Modeling Language UUID - Universally Unique Identifier
7
RESUMO
A confiabilidade e a facilidade de emprego do protocolo CAN BUS são
amplamente consagradas na eletrônica embarcada presente na comunicação de
dispositivos, em especial na indústria automotiva, mas ainda pouco exploradas no
campo da automação residencial. Neste trabalho, é proposto um modelo modular
que se baseia no protocolo CAN BUS para implementação de um sistema domótico,
tendo como base o protocolo Bluetooth e um aplicativo Android para o
interfaceamento com o usuário final. O sistema é capaz de detectar mudanças na
rede dinamicamente, enviando comandos e alterando o estado da rede domótica
conforme as ações do usuário.
Com o objetivo de demonstrar a empregabilidade do sistema, o presente
trabalho conclui a proposta através da implementação de uma rede domótica,
ratificando os conceitos apresentados.
Palavras-chave: automação residencial, domótica, CAN BUS.
8
ABSTRACT
The trustiness and reliability of the CAN BUS protocol are widely consecrated
among modern embedded systems, mainly on the automotive industry, but yet not
fully explored by the domotics field. The following work proposes a domotic modular
model based on the CAN BUS, supported by a Bluetooth interface provided by an
Android device. The system is capable of detecting changes dynamically on the
domotic net by sending commands autonomously, according to the previous user
settings and preferences. It also responds and updates the user screen according to
the number of connected devices, providing updated information about the whole
network.
This work concludes the proposal by implementing a domotic network, showing
its vast usability and ratifying the presented concepts.
Keywords: home automation, domotics, CAN BUS.
9
1 INTRODUÇÃO
A domótica consiste em um sistema integrado de hardware e software capaz de
controlar todos os ambientes de uma residência através de um só equipamento,
incluindo temperatura, luminosidade, som, segurança, entre outros (BOLZANI,
2004). O termo casa inteligente relaciona-se a uma residência que apresenta um
sistema de automação baseado na tecnologia domótica. Conforme CARVALHO
afirma (2008, p. 20), a casa inteligente pode ser definida como uma “[residência]
equipada com objetos inteligentes interligados por uma rede doméstica, capaz de
transmitir informações entre objetos e um mecanismo para conectar o ambiente com
meios de comunicação externos”.
MOLINA (2008) definiu o conceito de domótica como o conjunto de sistemas
capazes de automatizar e controlar diferentes instalações de uma residência. As
definições referentes à automação e controle se cruzam ao se acender uma
lâmpada, ao se agir em algum motor, ao colher informações do meio, entre outras
inúmeras interações possíveis do usuário final com o meio. Dessa forma, pode-se
definir domótica como a integração da tecnologia com a concepção de um projeto de
engenharia, de maneira que seja possível transformar e facilitar a convivência em
um recinto.
Iniciativas relacionadas a práticas em tecnologias assistivas têm ganhado maior
ênfase no meio acadêmico. Com o objetivo de prover segurança, comodidade,
facilidade na execução das tarefas do dia-a-dia em casas e acessibilidade a pessoas
portadoras de alguma deficiência, a automação residencial vem sendo desenvolvida
e aplicada em muitas partes do mundo, inclusive no Brasil.
A crescente demanda por tecnologias mais acessíveis, e que sejam capazes de
fomentar a indústria nacional, sinalizam uma grande oportunidade para o
desenvolvimento de sistemas domóticos que atendam às demandas listadas.
1.1 Objetivo
O presente trabalho tem como objetivo geral a prototipagem e implementação de
uma rede de automação residencial modular baseada no protocolo CAN BUS. Como
10
objetivos específicos, lista-se: projetar uma rede que permita a inserção e remoção
de nós dinamicamente, implementar um software para a plataforma Android capaz
de interfacear os comandos do usuário final e o estado dos sensores; projetar um
conjunto de nós capaz de se comportar de maneira modularizável, possibilitando o
intercambeamento de funções com mínima ou nenhuma alteração nos barramentos
físicos pré-estabelecidos.
Como metas, o projeto deverá implementar um aplicativo Android funcional e
desenvolver uma rede CAN BUS contendo, no mínimo, um nó de interfaceamento
Bluetooth, um nó com controle de infra-vermelho e um nó para climatização de um
ambiente.
1.2 Justificativa
Dados os objetivos previamente atingindos em DANTAS et al., 2013, na qual
verificou-se a total adaptação do protocolo CAN BUS ao projeto de um ambiente
doméstico, surge a necessidade de se planejar como seria possível extrair o
potencial prometido por tal protocolo, incluindo a modularização de dispositivos e a
vasta possibilidade de interfaceamentos. Isso posto, o trabalho justifica-se como
exemplificação e assertiva concreta de que é factível a implementação com nós
diversificados, com funcionalidades específicas, com interfaceamento prático por
parte do usuário final.
A crescente demanda por equipamentos modernos e práticos, que possam
servir como parte integrante de uma estrutura domótica de baixo custo, vem
crescendo dentre as empresas de tecnologia da informação (STARTUPI, 2014), e a
aquisição dessa tecnologia tem se mostrado cada vez mais acessível (SAPOTECH,
2014).
Os resultados alcançados por esse trabalho servirão como apoio a novas
implementações para sistemas domóticos de baixo custo, principalmente pela
indústria nacional, permitindo que sejam desenvolvidos serviços de apoio para
diversos usuários, incluindo pessoas que demandem algum tipo de tecnologia
assistiva.
11
1.3 Metodologia
A montagem dos nós foi feita de modo simples, aproveitando ao máximo os
conhecimentos levantados anteriormente em nosso projeto de iniciação à pesquisa.
Após definirmos as funcionalidades a serem implementadas, iniciou-se o
desenvolvimento da estrutura física. Os microcontroladores receberam códigos mais
simples no início, com comandos simples, e foram ganhando complexidade a cada
meta atingida. Em paralelo, o desenvolvimento do aplicativo Android seguiu a
padronização dos protocolos de alto nível estabelecidos. Era possível a realização
de testes independentes ao isolarmos o módulo Bluetooth dos demais componentes,
deixando somente uma alimentação simples de 5 volts e conectando em curto os
pinos de RX e TX do módulo.
Por fim, houve a integração de todos os sistemas, quando os nós, barramentos
e interface final com o usuário foram testadas e aprimoradas, a fim de garantir o
correto funcionamento de todo o sistema prototipado. A última modificação incluiu a
extensão dos cabos CAN_HIGH e CAN_LOW entre os nós, replicando as distâncias
comumente aplicadas em uma residência. A inserção e remoção dinâmicas de nós
da rede CAN também foi testada com sucesso.
1.4 Estrutura da Monografia
Este projeto final de curso está dividido nos seguintes capítulos: Introdução,
Arquitetura do Sistema, Software, Hardware e Conclusão.
O segundo capítulo aborda uma visão geral do sistema, introduzindo termos
utilizados, bem como as estratégias de implementação. Em seguida, aborda-se de
forma detalhada a abstração em camadas, que explica o caminho percorrido entre o
usuário final e os nós que executarão o comando desejado, bem como enviarão de
volta informações colhidas por sensores atrelados aos nós, ou ainda informações
sobre os estados dos nós. Finalizando o capítulo, formalizam-se os protocolos de
alto nível criados para realizar a comunicação entre os dispositivos da rede,
explicitando as gramáticas que definem o significado de cada símbolo terminal
transmitido. A arquitetura que permite a modularização da rede através da filtragem
12
e mascaramento de endereços via CAN também é mostrada. Por fim, são
destacadas as funcionalidades e limitações impostas pela arquitetura adotada.
O terceiro capítulo comenta a estrutura do cliente Android implementado. A
interface de controle é abordada, citando também como funciona o sistema de
identificação de módulos e o esquema de criação de novos tipos de nós no client-
side. A identificação dos módulos é detalhada e, finalizando o capítulo, o
interfaceamento entre Android e Master é comentado, explicando suas vantagens e
possibilidades.
Por sua vez, o quarto capítulo detalha as características dos circuitos
implementados nos nós, abordando componentes utilizados, bem como dados
trazidos pelos fabricantes e demais dados necessários para se replicar os circuitos.
A pinagem e a arquitetura de baixo nível também é indicada, inclusive sendo
mostrada a diferença entre os nós Master e Slave. Comenta-se a estrutura do
firmware e suas partes principais ao final do capítulo.
Ao concluirmos o trabalho, os códigos implementados são apresentados,
sintetizando as experiências vivenciadas, e sugestões para trabalhos futuros são
formalizadas.
13
2 ARQUITETURA DO SISTEMA
Nesse capítulo, serão discutidas as principais decisões de projeto que definiram
a arquitetura do sistema domótico. Será feita uma revisão geral do funcionamento do
sistema, bem como uma análise dos protocolos de comunicação em um esquema
em camadas. As gramáticas que formalizam a linguagem de mais alto nível entre os
dispositivos finais e o controlador serão esmiuçados e, em seguida, o emprego do
mascaramento e filtragem de mensagens CAN será detalhada, mostrando de que
forma foi possível a implementação de uma rede unicast-multicast entre os nós. Por
fim, as funcionalidades e limitações do sistema serão abordadas.
2.1 Visão geral do sistema
O sistema projetado tem como meta permitir que a rede domótica possa ser
modularizada e comandada remotamente, partindo de um dispositivo Android
portando capacidade para Bluetooth. A interação de um usuário ocorre da seguinte
forma:
ü Ao abrir o aplicativo, o usuário conecta seu dispositivo Android ao
endereço Bluetooth da rede domótica.
ü Logo após se conectar, ele receberá uma atualização do status da rede, e
poderá então visualizar quais sensores/atuadores estarão disponíveis
naquele momento na rede.
ü Ao selecionar um dos sensores/atuadores da rede, haverá uma lista de
comandos disponível, conforme a finalidade do sensor/atuador.
ü O usuário, então, poderá enviar comandos para o sensor/atuador,
recebendo o feedback do novo estado da rede assim que seu comando
for processado.
ü Caso algum sensor/atuador seja acrescentado ou removido do sistema, o
usuário será notificado em seu dispositivo móvel, recebendo a nova
configuração via Bluetooth.
14
Para tornar possível essa interação, é necessário introduzirmos os conceitos que
definem as partes componentes do projeto. São eles:
ü Cliente Android - aplicativo desenvolvido para permitir a interação do usuário
final com a rede domótica. Será abordado de forma mais contundente no
Capítulo 3.
ü Nós - circuitos modulares, interligados pelos barramentos CAN, que são
capazes de receber um acoplamento externo. Esse acoplamento externo
poderá conter sensores, atuadores ou ainda um módulo de interface
Bluetooth. Caso receba um módulo de interface Bluetooth, esse nó é
chamado de Master. Caso receba outro tipo de acoplamento, esse nó é
chamado de Slave. Entretanto, ambos os nós possuirão o mesmo firmware,
sendo que a região do código que será acessada é definida apenas pelo
acoplamento externo. Mais detalhes serão disponibilizados no Capítulo 4.
2.2 Abstração em camadas
A fim de tornar mais didática e mais clara a arquitetura de comunicação de
nosso sistema, foi adotado um esquema de abstração em camadas representando a
forma com que as partes componentes se comunicam, conforme apresentado na
FIG 2.1.
FIG 2.1 – Abstração em camadas dos protocolos empregados
15
2.3 Protocolos de comunicação
Os protocolos-padrão de comunicação usados para comunicação entre
camadas são basicamente o protocolo Bluetooth e o CAN BUS. Entretanto, para
otimizar a quantidade de bits a ser transmitida, bem como padronizar a alocação das
informações nas streams de bits, foi criada uma gramática que condensa e formaliza
a transmissão de informações, abstraindo os detalhes de mais baixo nível para os
protocolos já citados anteriormente. Ratificando os fatores levantados anteriormente
no Trabalho de Iniciação à Pesquisa (DANTAS et al., 2013), o protocolo CAN foi o
escolhido, dentre diversos fatores, por apresentar baixo custo.
Suas principais propriedades compreendem (CAN, 2014):
ü priorização de mensagens
ü garantia de tempos de latência
ü configuração altamente flexível e adaptável
ü recepção multicast com sincronização de tempo
ü consistência de dados por todo o sistema
ü possibilita implementação de redes multimaster
ü sinalização e detecção de erros
ü retransmissão automática de mensagens corrompidas sempre que o
barramento tornar-se ocioso
ü distinção entre erros temporários e falhas permanentes de nós, anulando
automaticamente os nós defeituosos dentro da rede
2.3.1 Gramática Slave - Android
Um nó do tipo Slave será capaz de enviar apenas um tipo de mensagem,
chamada de "Update". Essa mensagem consiste em uma concatenação de bits que
identificam, primeiramente, o tipo de módulo que está acoplado àquele nó; em
seguida, o código identificador daquele nó na rede de automação e, por fim, uma
cadeia de bits que sinalizam o estado daquele nó. Como simplificação, adotou-se
apenas três bytes para identificar esses estados. Entretanto, essa quantidade
poderá ser tão grande quanto desejarmos. Cada nó Slave poderá ter seu estado
16
definido por esse array de bytes, que recebeu o nome de de NODE_STATUS. Como
exemplo, a posição 0 do array sinaliza se o módulo está ligado ou desligado. As
demais posições detalham as configurações daquele módulo. Como exemplo, é
possível citar uma lâmpada multicolorida de LED. A posição 0 indica luz ligada ou
desligada; a posição 1 indica a cor da lâmpada, e a posição 3, a intensidade do
brilho. Da mesma forma, um ar condicionado poderá adotar outras padronizações,
desde que coerentes com o cliente Android. Vale ressaltar que, no futuro, caso
venham a ser desenvolvidos novos nós, basta subirmos uma atualização ao cliente
Android que ele será capaz de identificar e enviar comandos personalizados àquele
módulo.
Regras: M -‐> Update Update -‐> UPDATE + NodeType + NodeId + Status0 + Status1 + Status2 Símbolos terminais: UPDATE -‐> 0x01 ;Instrução NodeType -‐> 0x## ;Tipo de nó (Ex.: 0x01 – lâmpada) NodeId -‐> 0x## ;Id do nó Status0 -‐> 0x## ;NODE_STATUS[0] Status1 -‐> 0x## ;NODE_STATUS[1] Status2 -‐> 0x## ;NODE_STATUS[2]
TAB 2.1 – Gramática Slave – Android.
2.3.2 Gramática Android - Slave
As mensagens que partem do Android, com destino a algum Slave, podem ser de
dois tipos. A mensagem "RequestUpdate" sinaliza um pedido de atualização do estado
dos nós da rede CAN. Ao receber uma mensagem desse tipo, os nós respondem uma
mensagem contendo informações sobre seu estado, bem como suas características
(qual é o tipo de módulo que está acoplado, entre outros), ou seja, uma mensagem
Update.
Por sua vez, a mensagem "Set" tem a finalidade de alterar o estado de um dos
Slaves. Dessa forma, o Slave entenderá que deverá modificar seu estado para
corresponder à solicitação realizada. Cada Slave é identificado por um conjunto de bits.
Para simplificação, como já foi citado, adotou-se oito bits para identificar o dispositivo,
mas vale ressaltar que esse número poderá ser tão grande quanto nós desejarmos.
Continuando o exemplo anterior, da lâmpada de LED, caso o Slave receba uma
mensagem SET 0xZZ 0x00 0x01, a mensagem tem como destino o nó de identificador
17
ZZ, e seu status de índice 0 receberá o valor 1. O firmware irá atualizar seu estado local
e, em seguida, o comando acenderá a lâmpada. Como forma de demonstrar a execução
do comando, o slave envia uma mensagem Update de volta ao cliente, de modo a
alertá-lo sobre seu novo estado.
Regras: M -‐> RequestUpdate | SetMessage RequestUpdate -‐> REQ_UPDATE SetMessage -‐> SET + NodeId + StatusNumber + Value Símbolos terminais: REQ_UPDATE -‐> 0x02 ;Instrução SET -‐> 0x03 ;Instrução NodeId -‐> 0x## ;Id do nó de destino StatusNumber -‐> 0x## ;Posição do NODE_STATUS Value -‐> 0x## ;Valor
TAB 2.2 – Gramática Slave – Android
2.4 Arquitetura da rede Uni-multicast via filtragem e mascaramento CAN
Por definição, as redes CAN são redes broadcast – todas as mensagens
enviadas são recebidas por todos os demais nós. Entretanto, não é interessante que
todos os nós aceitem todas as mensagens que correm pela rede. Para
implementarmos esse tipo de comunicação, o protocolo CAN nos oferece
ferramentas de grande utilidade: são as máscaras e filtros. Semelhante a uma rede
IP, as máscaras e filtros possibilitam que se defina a aceitação e a rejeição de um
conjunto de endereços de remetentes de forma simples e direta.
Inicialmente, é importante destacarmos a diferença entre aceitação e
recebimento de uma mensagem. Por ser uma rede broadcast, todos os nós
receberão as mensagens válidas. As mensagens, ao chegarem a um nó, possuem
um identificador em seu cabeçalho, que corresponde a um conjunto de 29 bits (ou
11 bits, caso seja empregada a versão A do protocolo CAN). A máscara define quais
desses bits serão utilizados para verificação do aceite da mensagem. Os bits do filtro
correspondentes às posições dos bits setados em 1 na máscara serão então
comparados, um a um, aos bits do identificador do nó, também nas mesmas
posições. Se o resultado de todas as comparações (entre bits do filtro e bits do
18
identificador) for positivo, a mensagem é aceita. Caso contrario, a mensagem não é
aceita pelo nó. Como exemplo, foram listadas as situações possíveis descritas na
TAB 2.3.
Suponha um nó com ID 0x0012ff88.
Máscara Comportamento
0x1FFFFFFF Só serão aceitas mensagens cujos IDs sejam exatamente 0x0012ff88
0x1FFFFFF0 Não serão comparados os 4 bits menos significativos. Logo, serão aceitas mensagens com IDs entre 0x0012ff80 e 0x0012ff88
0x00000000 Serão aceitas todas as mensagens, independentemente do identificador (broadcast) TAB 2.3 – Máscaras e comportamentos.
Seguindo esse princípio, modelou-se a rede CAN do sistema domótico em um
sistema Unicast/Multicast. Os nós que desempenharem papel de Master (ou seja,
terão conexão com o mundo exterior através de um módulo Bluetooth acoplado)
serão nós setados em modo Broadcast, ou seja, apresentarão máscara CAN
0x00000000, recebendo e aceitando todas as mensagens que trafegarem pelo
barramento. Entretanto, os nós desempenhando papel de Slave têm necessidade de
se comunicarem somente com o Master e, portanto, apresentarão uma máscara
mais restritiva. Tal restrição permite que os nós Slave aceitem somente as
mensagens oriundas de um ou mais nós Master e, portanto, passe a ignorar
mensagens dos demais nós Slave. Sendo assim, o nó Slave terá uma máscara CAN
0x1FFFFFFF, no caso de haver somente um nó mestre, ou 0x1FFFFFFE, caso haja dois
mestres, e assim sucessivamente, restringindo sempre o tráfego de mensagens.
Os recursos de mascaramento e filtragem oferecidos pela rede CAN servem
como uma abstração intermediária, sendo possível, dessa forma, implementar uma
rede unicast/multicast. A comunicação entre um nó Slave e o Master será uma rede
Unicast (para o caso em que houver somente um mestre) e a comunicação do
Master para os Slaves será uma rede Multicast (considerando o caso em que haja
mais de um mestre, e as mensagens entre mestres sejam ignoradas para se manter
a consistência na rede).
19
2.5 Funcionalidades e limitações
As principais funcionalidades apresentadas pelo sistema projetado são listadas a
seguir:
ü O sistema responde dinamicamente à inserção e remoção de nós no
barramento, sem que haja necessidade de reboot de nenhum componente.
ü O sistema é capaz de aceitar a criação de novos módulos, inclusive de
tecnologias que ainda estejam por ser criadas, bastando apenas a
adaptação de um novo módulo, garantindo a conexão física, e uma
atualização simples do software Android, incluindo novas implementações
dos tipos de nós adicionados e seus estados.
ü O sistema é capaz de receber múltiplos usuários, ou seja, é possível que
haja mais de um usuário enviando comandos à rede CAN. Todo comando é
aceito, e o comando que será mantido deverá ser sempre o último a ser
enviado, ou seja, o mais recente.
ü O tempo de resposta dos dispositivos é bastante satisfatório (menos de 1
segundo), visto que o barramento CAN consegue atingir, em nosso sistema,
velocidades de até 1Mb/s.
ü Limite de funcionalidades que um nó pode apresentar é definido,
previamente, pela memória interna de um microcontrolador (32KB). O
programa ocupa menos de 2KB, restando mais de 30.000 posições de
configurações para cada nó. Foi utilizado um máximo de 3 posições no
sistema desenvolvido, e resultados suficientemente adequados foram
alcançados.
ü Quantidade teórica máxima de nós que uma rede pode possuir também é
definida pela rede CAN-B, cujos endereços podem ter o máximo de
1FFFFFFF bits, ou seja, 31 bits, o que corresponde a dois bilhões de nós.
Entretanto, sem que haja repetidoras para intensificar a potência do sinal, a
rede atual comporta cerca de 80 nós, mantendo a mesma velocidade de
transmissão. A necessidade de inserção de repetidoras depende da
capacitância, velocidade máxima requerida, comprimento dos nós e
topologia da rede demandados.
20
Entretanto, tal arquitetura está limitada pelas seguintes características:
ü Baixa taxa de transferência Bluetooth impede que haja streaming de grandes
quantidades de dados, como vídeo.
ü Caso haja mais de um usuário conectado ao sistema, não há nenhum
esquema de preempção de comandos, nem hierarquia de usuários. Basta
que o usuário saiba a senha de acesso do Bluetooth para poder inserir
comandos na rede, alterando seu estado.
ü Arquitetura CAN ainda requer o emprego de um barramento físico entre os
nós da rede (fios CAN_HIGH e CAN_LOW). O barramento, entretanto, é
minimizado, visto que a rede CAN, broadcast por definição, não requer
nenhuma conexão entre nós especificamente, basta que um nó se acople à
rede em qualquer ponto. Por outro lado, já existem trabalhos em que se usa
a Arquiterura CAN com outros meios sem ser o par trançado, como foi visto
em nossa Iniciação à Pesquisa. Por simplicidade, escolheu-se adotar este
esquema para explorar as funcionalidades de modularização e adequação
ao Android dentro da proposta.
21
3 SOFTWARE
3.1 O Cliente Android
A função do cliente Android é servir de interface entre o usuário final e o sistema
domótico, interpretando os dados e os protocolos que percorrem a rede. Além disso,
permite que o usuário envie comandos, setando e alterando o estado dos nós e
módulos acoplados. O aplicativo foi batizado como "AutomaHome", e programado
através da IDE Eclipse, com os add-ons fornecidos pelo Android Software
Development Kit e pelo Android Development Tools.
O projeto foi dividido em quatro pacotes:
ü canbus, que contém as representações das Views do Android;
ü canbus.btmanager, que controla o Service e a comunicação via Bluetooth;
ü canbus.mvc, que contém classes que definem as representações dos nós
(modelo, na forma de CanNode), e do controlador (EngineController);
ü canbus.types, que contém a representação dos diversos tipos de nós, bem
como os comandos correspondentes.
3.2 Interface de controle e identificação de módulos
Os Intents são controlados por uma classe instanciada no Service, chamada de
EngineController. Essa classe trata as Strings recebidas e as interpreta através do
método "handleIncomingDataFromMaster". Por sua vez, esse método verifica os
campos da mensagem recebida. Ele verifica se a mensagem é válida (ou seja, uma
mensagem de Update), e atualiza o ArrayList de nós que representa a rede CAN. Os
nós foram modelados através de uma classe chamada "CanNode". Os CanNodes
possuem um tipo pré-definido, que deve herdar da classe abstrata "NodeType".
Como exemplo, um nó que tenha o identificador de uma lâmpada, e que ainda não
esteja instanciado no ArrayList de nós, será representado por um CanNode do tipo
NodeTypeLampada. As classes NodeTypeXXX definem a interpretação dos bytes,
tanto quanto à posição correspondente ao NODE_STATUS do firmware quanto ao
significado e aos valores correspondentes ao status que se deseja definir. Além
22
disso, também contém informações a serem usadas pela View, ou seja, um logo que
ilustre aquele tipo, bem como um nome (ex.: um ícone dentro da pasta de
Resources que represente uma lâmpada, bem como o nome "Lâmpada"). O código
a seguir detalha a instanciação do tipo NodeTypeLampada:
public NodeTypeLampada() { this.iconResource = R.drawable.ic_lightbulb; this.typeCode = Values.TYPE_LAMP; this.typeName = "Lâmpada"; this.comandos = new ArrayList<Comando>(); comandos.add(new Comando("ON", (byte)0x00, (byte)0x01)); comandos.add(new Comando("OFF", (byte)0x00, (byte)0x02)); comandos.add(new Comando("R", (byte)0x01, (byte)0x01)); comandos.add(new Comando("G", (byte)0x01, (byte)0x02)); comandos.add(new Comando("B", (byte)0x01, (byte)0x03)); comandos.add(new Comando("W", (byte)0x01, (byte)0x04)); }
3.3 Interfaceamento Android – Master via Service
A comunicação entre Android e Master é feita de modo persistente através de
um Service. Os Services são classes que compreendem tarefas que rodam no
background do aplicativo, e a comunicação entre Service e Activity é realizado
através de LocalBroadcasts. Dessa forma, foi possível desacoplar completamente o
esquema de comunicação com a arquitetura de visualização (ViewTree) do Android.
Caso fosse mantida a lógica de comunicação Bluetooth atrelada a Activity, não seria
possível manter o estado da comunicação continuamente, ou seja, caso o usuário
abrisse temporariamente outro aplicativo, ou até mesmo se a tela mudasse de
orientação, a Activity anterior seria terminada, a conexão Bluetooth atrelada seria
perdida, e todo o processo de pareamento e comunicação deveria ser reinicializado.
Os principais Intents que servem de comunicação entre Service e Activity estão
declarados a seguir:
public static final String INTENT_CONNECT_SUCCESS = "connect_success"; public static final String INTENT_CONNECT_ERROR = "connect_error"; public static final String INTENT_DATA_ARRIVED_FROM_SENSOR = "data_arrived_from_sensor"; public static final String EXTRA_DATA_ARRIVED_LABELS = "extra_data_arrived_labels"; public static final String EXTRA_DATA_ARRIVED_VALUES = "extra_data_arrived_values";
23
Segundo MAZIDI (2008), microprocessadores usuais (tais como a família Intel
x86 ou a família Motorola PowerPC), não contêm RAM, ROM, nem portas de
entrada e saída de dados (I/O ports) no próprio chip. Por essa razão, são
normalmente chamados de “general-purpose microprocessors”, ou de emprego
geral.
Dessa forma, um projeto de sistema que pretenda empregar um
microprocessador de uso geral deve prever a inclusão de RAM, ROM, portas de
entrada/saída de dados e timers a fim de tornar tal sistema funcional. Embora a
necessária inserção de componentes possa trazer acréscimo no tamanho físico e no
custo total do projeto, os sistemas com microprocessadores contam com uma maior
versatilidade no dimensionamento da memória e dos componentes necessários, pois
são particularizados para cada projeto. O mesmo não ocorre em projetos
envolvendo microcontroladores: esses componentes contam com uma quantidade
pré-fixada de memória RAM, ROM, portas I/O, todos embutidos em um mesmo chip,
junto de um microprocessador (CPU). Segundo MAZIDI (2008, p. 24), essa
quantidade limitada de memória, aliada ao pequeno espaço ocupado, torna os
microcontroladores “ideais para diversas aplicações em que custo e espaço devem
ser otimizados”. Nessas aplicações, o espaço físico necessário, a potência
necessária e o preço por unidade são muito mais críticos que o poder de
processamento, e não deve se superdimensionar sua estrutura.
Visto que o presente projeto visa montar uma rede de domótica de tamanho
reduzido, na qual não há, em geral, necessidade para grande capacidade de
processamento (apenas acionamento de servo-motores, processamento de sinais
de sensores, conversões simples de sinais analógicos e digitais), e o baixo custo é
crucial, deve-se então empregar microcontroladores em cada nó de nosso
barramento CAN.
3.4 Diagrama de classes e heranças
A fim de ilustrarmos a organização de nossa arquitetura Android, foram criados
dois diagramas de classes, baseados em UML, conforme a FIG 3.1. O primeiro
deles, mais geral, inclui o nome das classes, o pacote nas quais elas estão
incluídas, mas omite parâmetros e métodos para facilitar a visualização. Perceba
24
que, dentro de nosso MVC, a classe EngineController controla a conexão Bluetooth,
através do BTService, que a mantém funcional mesmo que o usuário saia do
aplicativo temporariamente (jogando-o no background do sistema operacional) e
volte a se comunicar mais tarde sem que haja queda na conexão. Nosso modelo é
representado pela classe CanNode, que replica as configurações dos nós
encontrados na rede. A cada novo nó inserido e detectado na rede, um nó é
adicionado ao "canNodeList". A Main é nossa Activity, que no Android corresponde
ao View do MVC. A classe Values possui alguns valores constantes para referência,
e a classe Comando indica quais são os possíveis comandos que podem ser
executados por determinado tipo de nó, incluindo ali os valores dos respectivos
bytes que simbolizam tais ações nos microcontroladores.
FIG 3.1 – Diagrama de classes e heranças geral.
O segundo diagrama, exibido na FIG 3.2, tem o objetivo de detalhar a relação
entre a classe abstrata de tipos de nós, os tipos de nós implementados que
estendem dessa classe abstrata (no caso, NodeTypeLampada e NodeTypeClima, e
sua relação com a classe CanNode, que é possuidora de um dos tipos disponíveis.
25
FIG 3.2 – Detalhe da construção de diferentes tipos de nós.
26
4 HARDWARE
4.1 Estrutura física de um nó
O nó é definido como um conjunto de hardware que possui como componentes:
microcontroladores, sensores e atuadores, e possui uma função específica dentro da
rede no qual está inserido.
Dentro do escopo deste trabalho, os nós se comunicam via CAN BUS entre os
nós da mesma rede. Além disso, o nó poderá utilizar outro protocolo de
comunicação caso haja necessidade de comunicação com algum dispositivo que
esteja fora da rede física CAN. Como exemplo, um nó pode receber mensagens de
outro nó na rede via CAN BUS e retransmiti-lo para um dispositivo móvel (Celular)
através de um módulo Bluetooth.
FIG 4.1 – Esquema da geral da prática realizada.
Dependendo da complexidade da tarefa a ser realizada pelo nó, o
microcontrolador terá, além de sensores ou atuadores acoplados, componentes
eletrônicos com a finalidade de compatibilizar eletronicamente o microcontrolador e
seus atuadores/sensores e outros componetes para o funcionamento tanto do
27
microcontrolador como dos sensores/atuadores, como, por exemplo, o oscilador que
fornece o clock preciso para o microcontrolador.
Desta forma, tendo em vista o grande número de funcionalidades possíveis e a
complexidade que cada nó pode gerar, este trabalho irá apresentar dois nós, que
foram nomeados de acordo com sua funcionalidade dentro do escopo do trabalho.
O presente trabalho, em seu experimento, tem como meta a automação de
uma rede composta por três nós, sendo dois nós Slave com uma lâmpada colorida
de LED em um e um motor elétrico no outro (ventilador); e um Nó Master, que
contém o Bluetooth, conforme a FIG 4.1.
O nós Slave executam as tarefas para as quais eles são especificados e
retornam dados pertinentes à rede e ao usuário. O nó Master é responsável por
receber as mensagens vindas da rede CAN e transmiti-las ao usuário por Bluetooth,
além de receber os dados do celular e repassá-las à rede CAN.
4.1.1 Nó Master
De acordo com o proposto na seção 4.1, o nó Master terá como função receber
e enviar mensagens através do protocolo CAN-BUS e comunicar-se com mundo
exterior à rede CAN. Foi resolvido que o nó Master tivesse como conexão com um
celular (Smartphone) através do protocolo Bluetooth (conforme digrama na FIG 4.2).
Para que essa conexão seja viável, foi necessário o seguinte material:
ü 1 Microcontrolador
ü 1 Módulo Bluetooth
ü 1 Oscilador
ü 2 Capacitores
ü 1 Transceiver
28
FIG 4.2 – Diagrama simplificado do Nó Master.
4.1.1.1 Microcontrolador
O Microcontrolador é o grande gerenciador ou cérebro deste nó, controlando
todos os procedimentos de acordo com o seu firmware. Este dispositivo se comunica
principalmente com o Bluetooth pela sua porta USART e com a rede CAN com os
pinos CAN Tx e CAN Rx, que se ligarão ao transceiver. Dentre os diversos
microcontroladores disponíveis no mercado, decidiu-se estudar e implementar em
nossa pesquisa, devido ao seu baixo custo, à vasta variedade de chips compatíveis
e à versatilidade proporcionada durante a inclusão ou exclusão de nós em um
circuito, o modelo PIC 18F2580, da Microchip, ilustrado na FIG 4.3. Além de ter seu
custo reduzido, a família 18Fxx8 já possui vasta biblioteca de métodos adaptados
para o protocolo CAN, possibilitando empregarmos a máxima capacidade que o
protocolo CAN BUS nos oferece. A série de microcontroladores 18F foi desenvolvida
pela Microchip Inc. para uso em aplicações complexas, tais como a comunicação via
protocolos TCP/IP, CAN, USB e Zigbee, entre outros. Além disso, este
microcontrolador foi utilizado no IP deste mesmo assunto e tem sido o
microcontrolador de estudo nas cadeiras da sessão de engenharia elétrica no
Instituto Militar de Engenharia.
29
FIG 4.3 – Diagrama de pinos do microcontrolador. (MICROCHIP, 2007, p.2)
4.1.1.2 Bluetooth
O módulo Bluetooth faz a interface entre o microcontrolador o celular por meio das
ondas de rádio. Este dispositivo se comunica por porta serial com o microcontrolador e
por ondas eletromagnéticas moduladas conforme o protocolo de comunicação
Bluetooth. Além disso, tem os pinos auxiliares de RTS (request to send) e CTS (clear to
send) para controle do fluxo de informação. O dispositivo escolhido pra executar esta tarefa foi o chip RN 42 da microchip. Esse
módulo, de classe 2, permite a comunicação entre dispositivos Bluetooth versão 2.1 em
um raio de 20 metros sem obstáculos (apresenta antena que permite conexões em
taxas de até 3Mbps, com saída de +4dBm e sensibilidade de recepção de -80dBm);
possui criptografia interna padrão de 128bits e funções de correção de erros em pacotes
(ROVING, 2013). O módulo RN42 ainda possui perfis de baixo consumo de corrente (como o modo
“deepsleep”, que consome 26µA em um circuito de 3.3V, podendo mesmo assim ser
descoberto e pareado, passando então a consumir 30mA ao se conectar), adaptando-se
perfeitamente ao circuito a ser utilizado. Dessa forma, ao integrarmos o RN42 ao circuito
do microcontrolador, o sistema CAN tornou-se apto a receber e transmitir mensagens
via Bluetooth mediante interfaceamento serial, o que foi essencial para a comunicação
com o celular. Uma visão geral de seu digrama pode ser vista na FIG 4.4.
30
FIG 4.4 – Diagrama de blocos RN42N. (ROVING, 2013, p.1)
4.1.1.3 Oscilador
O oscilador tem como principal funcão selecionar a correta frequência de
funcionamento dos ciclos de instrução do PIC. Existem diversas formas de seleção
do esquema do oscilador, tais como RC (com resistores e capacitores), XT (com
cristais de baixa potencia), XT (com cristais comuns), HS (com cristais de alta
frequência) e com oscilador externo, de acordo com a FIG 4.5. Foi utilizado um
cristal de clock que fornece uma frequência de 8.000 KHz, suficientemente pequena
para atingirmos a precisão necessária aos componentes e aos comandos.
FIG 4.5 – Esquemas de osciladores. (ARNEROBOTICS, 2014)
31
4.1.1.4 Capacitor
Os capacitores atuam juntamente com o oscilador para a seleção da frequência de
oscilação. Eles se ligam em uma extremidade ao cristal externo e com o outro terminal
nos pinos OSC 1 e OSC 2 do PIC18F2580, conforme esquema da FIG 4.6. Foi utilizada
a estrutura XT de oscilação do Microcontrolador PIC, pois é confiável e não depende de
circuitos alheios ao sistema. Para a correta seleção do valor de capacitância, é
necessário ver a indicação do fabricante do PIC, conforme a TAB 4.1.
FIG 4.6 – Esquema de ligação capacitor. (MICROCHIP, 2007, p. 23)
TAB 4.1 – Seleção de capacitores (MICROCHIP, 2007, p. 23)
4.1.1.5 Transceiver
O transceiver é o responsável por compatibilizar o nível de sinal do barramento
CAN para o trabalhado no microcontrolador. Foi escolhido o chip MCP2551 para
executar tal tarefa, pois, além de ser do mesmo fabricante do Microcontrolador,
existe extensa bibliografia para apoiar a prática. Sua configuração pode ser
realizada através da chamada de funções previamente oferecidas pela biblioteca
CAN, incluída na IDE mikroC para PIC
32
A estrutura interna do MCP2551 é mostrada na FIG 4.7. Esse chip suporta até 1
Mbps e pode operar com até 24V no barramento CAN. Inclui uma proteção contra
curto-circuito e desligamento automático térmico, o que lhe dá uma robustez maior
perante as falhas típicas deste modelo, detalhado na FIG 4.8. Além disso, possui
proteção contra picos de tensão e operação com baixa energia para aplicações onde
a economia de energia é requerida, ou quando se quer aumentar a confiabilidade.
FIG 4.7 – Diagrama de pinos do transceiver. (MICROCHIP, 2010, p.1)
FIG 4.8 – Diagrama de blocos do transceiver. (MICROCHIP, 2010, p.1)
4.1.2 Nó Slave 1 - Lâmpada LED IR
O nó Slave, através das mensagens vindas do nó Master, possui um
microcontrolador que irá gerar sinais que atuarão sobre um módulo infravermelho de
acordo com a ordem recebida. Com o intuito de isolar o circuito do microcontrolador,
33
foi confeccionado também um módulo fotoacoplador. Para que essa conexão seja
viável, foi necessário o seguinte material:
ü 1 Microcontrolador
ü 1 Transceiver
ü 1 Oscilador
ü 2 Capacitores
ü 1 Módulo fotoacoplador
ü 1 Módulo IR
A FIG 4.9 mostra a disposição do circuito Slave 1 – Lâmpada LED IR.
FIG 4.9 – Diagrama do nó Slave 1.
34
4.1.2.1 Microcontrolador
O Microcontrolador empregado é o PIC 18F2580, o mesmo empregado em
todos os nós. Nas suas portas de I/O de RC0 a RC5, ele se comunica com o módulo
fotoacoplador. Além disso, este módulo foi construído com três LEDs de
identificação de operação. Quando o circuito recebe uma informação via CAN, ele
acende o LED ligado à porta RB4; quando transmite algum dado para o transceiver,
ele liga RB5; e o LED à porta RB6 é um indicador de status do PIC. Esta
padronização foi particurlarmente útil na identificação e mapeamento de falhas. 4.1.2.2 Oscilador
Seguem a mesma configuração do nó mestre (estrutura base). 4.1.2.3 Capacitores
Seguem a mesma configuração do nó mestre (estrutura base). 4.1.2.4 Transceiver
Tem configuração semelhante ao nó Master. Vale resaltar na FIG 4.10 o modo
de se conectar esse dispositivo com os demais elementos do nó.
FIG 4.10 – Interface do transceiver CAN com o barramento e o PIC.
(MIKROELEKTRONIKA, 2010)
35
4.1.2.5 Módulo Fotoacoplador
O módulo fotoacoplador é utilizado neste nó para isolar o circuito do
Microcontrolador com o módulo IR. Desta maneira, uma pane em qualquer um
destes circuitos não se expande ao demais. Um diagrama simplificado do dispositivo
selecionado para este fim é mostrado a seguir.
FIG 4.11 – Esquemático do Fotoacoplador 4n25. (FAIRCHILD , 2002, p.1)
O 4n25 é um fotoacoplador de uso geral que já está bastante consolidado no
mercado. Ele é confeccionado com um diodo emissor de Gálio-Arsênio acoplado a
um fototransistor que é excitado pela base do transistor.
Este conjunto sera empregado como chave, isto é, quando o diodo conduzir,
uma luz infravermelha será emitida dentro do chip; esta luz, por sua vez, irá saturar
a base do fototransistor que fechará o contato. Por outro lado, enquanto o diodo não
conduzir, a base do fototransitor não estará polarizada e este entrará em corte
(chave aberta).
4.1.2.6 Módulo IR
O módulo Infravermelho foi empregado para acionar uma lâmpada colorida feita
com LED. Este conjunto foi escolhido por possuir diversas funções, e por poder
representar também uma diversidade de dispositivos que poderia ser controlada a
partir de um controle remoto comum. Este módulo foi tratado como caixa preta, de
onde se aproveitou o controle para implementar os contatos que fariam os
comandos para a lâmpada.
36
Seria possível, da mesma forma, implementar um módulo IR próprio. Entretanto,
como esta é uma tecnologia consolidada e o foco da pesquisa se dá na utilização da
Rede CAN, preferiu-seutilizar o módulo pronto projetando apenas a interface.
FIG 4.12 – Conjunto Lâmpada e controle remoto. (MERCADO LIVRE, 2014)
O modelo aquirido possui as seguintes características: lâmpada de um LED
RGB com soquete padrão de lâmpadas E27; controle remoto que permite a troca
das cores (até 16 cores), aplicação de efeitos (Flash, Strobe, Fade, Smooth),
aumento/diminuição da intensidade da luz, bem como ligar e desligar a lâmpada.
Apresenta potência de 3 watts bivolt (110V~220V). É fabricado em fibra de alumínio,
com tempo de uso estimado em 50 mil horas, provendo economia de até 90% em
relação as lâmpadas comuns. Não emite luz ultravioleta. Suas dimensões são 6 cm
de comprimento x 4,9 cm de diâmetro, e pode ser empregada como luz Spot (Spot
Light). 4.1.3 Nó Slave 2 - Climatizador
O nó Slave 2, através das mensagens vindas do nó Master, possui um
microcontrolador que irá gerar sinais que atuarão sobre um módulo de acionamento
de um ventilador. Apesar de ser uma carga única, a ideia aqui era simular o
acionamento de qualquer carga tipo indutiva (motor, ar-condicionado, etc).
Além disso, nosso intuito foi montar um sensor de temperatura que poderia
comandar o ligamento do ventilador de acordo com um parâmetro de temperarura à
escolha do usuário. Entretanto, este último objetivo não foi alcançado, pois atingiu-
se o limite do firmware na versão gratuita da IDE utilizada. Apesar disso, em nossas
37
experiências, foi possível ler temperaturas individualmente e acionar o motor de
forma separada. A FIG 4.13 ilustra os principais componentes deste nó.
FIG 4.13 – Diagrama do nó Slave 2.
Os componentes essenciais para a realização da tarefa delineada acima foram:
ü 1 Microcontrolador
ü 1 Transceiver
ü 1 Oscilador
ü 2 Capacitores
ü 1 Módulo fotoacionador
ü 1 Módulo de Potência
4.1.3.1 Microcontrolador
O Microcontrolador usado é o PIC 18F2580, o mesmo empregado nos demais
nós. Na sua porta de I/O RC5, o microcontrolador se comunica com o módulo
38
fotoacionador. Do mesmo modo que o nó Slave 1, o nó “climatizador” possui LEDs
de identificação de operação.
4.1.3.2 Oscilador
Seguem a mesma configuração do nó mestre (estrutura base).
4.1.3.3 Capacitores
Seguem a mesma configuração do nó mestre (estrutura base).
4.1.3.4 Transceiver
Tem configuração semelhante ao nó Master. Por outro lado, como este nó foi
empregado no meio na linha, não possui o resistor de terminação entre os fios CAN
High e CAN Low do barramento.
4.1.3.5 Módulo Fotoacionador
Este módulo tem bastante semelhança com o módulo fotoacionador do nó Slave
1. Sua principal função é receber o sinal vindo do microcontrolador e acionar o
dispositivo que permitirá o acionamento da carga.
A partir de uma corrente no foto-diodo (polarização direta), o componente ativará
o interruptor bilateral do TRIAC interno, conforme FIG 4.14. Isso permitirá comutar a
tensão de corrente alternada, liberando corrente suficiente para acionar o dispositivo
de potência.
FIG 4.14 – Diagrama de Pinos e de Lógica do Fotoacionador. (TEXAS
INSTRUMENTS, 1995 p.1)
O dispositivo selecionado para este fim foi o MOC3020, da Texas Instruments.
Consolidado no mercado há mais de três décadas, o dispositivo é uma referência
quando se fala na classe de optoacopladores/optoisoladores. Possui a robustez de
39
poder trabalhar até temperaturas de mais de 100 graus celcius, além de oferecer
uma elevada tensão de isolação (7.5 KV). Possui, de igual modo, corrente de
polarização direta compatível com as características do PIC18F2580.
4.1.3.6 Módulo de Potência
O módulo de Potência é assim denominado por possuir o conjuto de
dispositivos que acionarão a carga principal, que é a mais potente do circuito
(160W). Umas das possíveis soluções para este acionamento seria usar relés de
baixa tensão. Entretanto, devido à sua baixa confiabilidade, associada à redução de
sua vida conforme o número de manobras, preferiu-se usar o dispositivo eletrônico
do estado sólido chamado TRIAC.
O TRIAC é o equivalente a dois SCR ligados em antiparalelo. Tal configuração
permite que ele conduza em ambos os sentidos, conforme corrente passante pelo
Gate. O TRIAC é usado para chavear corrente alternada (AC). O gate pode ser
disparado com tensão positiva ou negativa. Após o disparo no gate, o TRIAC passa
a conduzir até que a corrente alternada mude de sentido, isto é, no próximo
semiciclo da senóide. Quando isto ocorre, é necessário um outro pulso no gate.
Geralmente, o gate do TRIAC é disparado por um diodo chamado DIAC, que em
nosso caso é o MOC2021. Este diodo conduz quando a tensão passa de um certo
nível, geralmente 20 ou 30V (BURGOS ELETRÔNICA).
O dispositivo usado para este fim foi o BTA/TO 220. Considere as FIG 4.15 e
4.16, que ilustram não só a pinagem do dispositivo, como também a disposição
deste em nosso circuito. O BTA alia velocidade de comutação à capacidade de
condução considerável em regime nominal (10A). Assim, ele pode ser usado em
atividades diversas de chaveamento, desde uma operação liga e desliga como
também estratégias de controle de velocidade, dimerização e outras.
40
FIG 4.15 – Diagrama de Pinos do TRIAC empregado. (SNUBBERLESS &
STANDARD, 2002, p.1)
FIG 4.16 – Esquemático para acionamento de cargas indutivas. (TEXAS
INSTRUMENTS, 1995, P.4)
4.2 Firmware
O firmware foi desenvolvido na linguagem C através da versão gratuita da IDE
"mikroC PIC". Uma limitação imposta pelo sistema se deve ao fato de que o
firmware, após ter sido compilado, não poder contar com mais de 2.000 palavras de
instrução. Dessa forma, programas que contam com o auxílio de muitas bibliotecas
externas – tais como as bibliotecas para comunicação CAN, comunicação USART,
conversores ADC, entre outros – passam a não ser compiláveis pela versão gratuita,
limitando a possível exploração das funcionalidades do dispositivo. Especialmente
no nó climatizador, foi possível executar operações de controle de temperatura
mediante sensoreamento remoto, acionando automaticamente o ventilador. Todavia,
ao integrarmos a funcionalidade do CAN, o firmware passou a não ser mais
41
compilável. O preço de uma licença professional, – por volta de US$ 300 – mostrou-
se, portanto, impeditivo ao nosso trabalho.
O firmware foi organizado em três grandes blocos: o primeiro bloco definia
parâmetros comuns a todos os sensores e ao sistema como um todo, bem como as
máscaras CAN e valores de identificação dos diversos tipos, oferecendo maior
clareza ao código. Já o segundo bloco era constituído por um conjunto de funções
que eram usadas com grande frequência, incluindo e agrupando diversos métodos
de configuração de parâmetros CAN, USART, setup de LEDs para debug e métodos
de funcionalidade. Dois desses métodos merecem maior destaque: são os métodos
refresh_node() e configurar_node_status(). Por fim, o terceiro bloco inclui a rotina
main(), definindo a ordem de execução das funções exercidas e o loop principal que
chama os métodos de apoio.
A modularidade de nosso firmware foi conquistada mediante o uso dos métodos
configurar_node_status() e refresh_node(). Esses métodos definem a configuração
inicial de um nó ao ser ligado e como um nó deve reagir para cada mudança de
estado detectada. Como fora citado na gramática, cada nó possui um array com
capacidade para três bytes chamado de "NODE_STATUS". Para fins de
simplificação, foi adotado um array pequeno, mas poderiam ter sido adotados arrays
ainda menores. Esse array reproduz o estado de um nó. Cada posição do array
corresponde a um estado do nó. Por exemplo, no nó lâmpada, a primeira posição
(posição zero) corresponde ao estado ligado/desligado; e a segunda posição, à cor
ativada naquele momento (R, G, B ou W). A terceira posição não tinha nenhum
significado nesse nó. O método configurar_node_status() definia quais seriam os
valores iniciais a serem adotados por esse nó assim que ele ligasse pela primeira
vez, ou seja, se aquele nó começaria ligado/desligado, e, caso ligado, qual cor seria
a cor default. O método refresh_node() atualiza o estado real do nó baseado na
configuração em memória do array NODE_STATUS. Portanto, ao receber alguma
mensagem requisitando alguma mudança em seu atual estado, o método
refresh_node() era invocado e, ao interpretar os bytes que representavam seu novo
estado, tomava as medidas correspondentes (ou seja, se seu NODE_STATUS[0]
fosse modificado para 0x02, que correspondia ao estado "desligado", esse nó
executaria os comandos para que o controle IR fosse acionado na posição que
desligasse a lâmpada).
42
O conjunto de bytes que correspondiam a cada possível estado de um nó era
replicado no Android. Dessa forma, caso se desenvolva um novo nó, de um novo
tipo, basta que o aplicativo seja atualizado, de maneira que fosse capaz de enviar
novos comandos de mudança de estado e também pudesse interpretar os bytes que
viriam em caso de uma mensagem de requisição de update de estado dos nós.
Veja a seguir alguns trechos do código que exemplificam os três blocos. O
primeiro bloco, também podendo ser incluído como um header file externo,
declarava as constantes comuns: // PARAMETROS PADRAO const unsigned int NODE_QTD_STATUS = 3; const unsigned int NODE_TOTAL_BITS_STAT = NODE_QTD_STATUS + 3; const unsigned char TYPE_LAMP = 0x01; const unsigned char TYPE_IR = 0x02; const unsigned char INSTRUCT_UPDATE = 0x01; const unsigned char INSTRUCT_REQ_UPDATE = 0x02; const unsigned char INSTRUCT_SET = 0x03; const char END_CHAR = 13; // VARIAVEIS CAN unsigned char sdata[8], read_flag, rdata[8]; unsigned short config_flag, send_flag, len; char SJW, BRP, Phase_Seg1, Phase_Seg2, Prop_Seg; long MASTER_ID = 0x00007777, mask, id;
Já o segundo bloco incluía inúmeros helper methods, dentre os quais se destaca
o método que configurava o sentido das portas para o uso dos LEDs, e outro método
que configurava os parâmetros de temporização do CAN, bem como o método
configurar_node_status() para o nó lâmpada. /* * Configura as portas especificas (TRIS, etc) para o LED de RX e LED de TX */ void configurar_LED(void){ TRISC = 0x00; // o TRISB esta sendo setado no metodo CAN Delay_ms(10); PORTB.B4 = 0; Delay_ms(10); PORTB.B5 = 0; Delay_ms(10); PORTB.B6 = 0; Delay_ms(10); PORTC.B6 = 0; Delay_ms(10); } void configurar_CAN(void) { // Parametros CAN TRISB = 0x08;
43
// canbus timing parameters SJW = 3; BRP = 8; Phase_Seg1 = 3; Phase_Seg2 = 3; Prop_Seg = 1; // Configuracao config_flag = _CAN_CONFIG_SAMPLE_THRICE & _CAN_CONFIG_PHSEG2_PRG_ON & _CAN_CONFIG_STD_MSG & _CAN_CONFIG_DBL_BUFFER_ON & _CAN_CONFIG_VALID_STD_MSG & _CAN_CONFIG_LINE_FILTER_OFF; read_flag = 0; send_flag = _CAN_TX_PRIORITY_0 & _CAN_TX_STD_FRAME & _CAN_TX_NO_RTR_FRAME; // Inicializar modulo CAN CANInitialize(SJW, BRP, Phase_Seg1, Phase_Seg2, Prop_Seg, config_flag); // Setar modo config CANSetOperationMode(_CAN_MODE_CONFIG, 0xFF); mask = 0; // QUEREMOS QUE O MESTRE RECEBA MENSAGEM DE TODOS! // Setando todas as MASK1 para FFFFFF... CANSetMask(_CAN_MASK_B1, mask, _CAN_CONFIG_STD_MSG); // Setando todas as MASK2 para FFFFFF... CANSetMask(_CAN_MASK_B2, mask, _CAN_CONFIG_STD_MSG); // Setando id do filtro B2_F3 para 0 (RECEBE DE TODOS) CANSetFilter(_CAN_FILTER_B2_F3, 0, _CAN_CONFIG_STD_MSG); // Setando CAN para modo normal CANSetOperationMode(_CAN_MODE_NORMAL, 0xFF); Delay_ms(100); } /* * Configuracao inicial do modulo (luz) */ void configurar_node_status(void) { NODE_STATUS[0] = 0x01; NODE_STATUS[1] = 0x04; NODE_STATUS[2] = 0x00; PORTC.B0 = 0; Delay_ms(100); PORTC.B1 = 0; Delay_ms(100); PORTC.B2 = 0; Delay_ms(100); PORTC.B3 = 0; Delay_ms(100);
44
PORTC.B4 = 0; Delay_ms(100); PORTC.B5 = 0; Delay_ms(100); }
Por fim, o terceiro bloco inclui a rotina main(), responsável por chamar os demais
métodos na ordem correta, bem como parsear as mensagens que chegavam e
montar as mensagens de REQ_UPDATE. A função main era comum a todos os
firmwares de todos os nós Slave. Os nós Master possuíam algumas rotinas para
recepção de mensagens seriais via USART, pois é o interfaceamento empregado
pelo módulo Bluetooth ao microcontrolador – algo que não fora empregado nos
demais nós (embora possa muito bem ser empregado, sem restrições).
45
5 ROTEIRO DA PRÁTICA REALIZADA
Com o objetivo de demonstrar a viabilidade do presente trabalho, foi realizado
um experimento prático. A prática foi demonstrada através da requisição de
comandos, mediante o aplicativo desenvolvido, e as respectivas ações do sistema.
Os passos demonstrados a seguir levam em consideração todo o hardware
descrito no capítulo 4 deste trabalho, o qual está implementado em uma rede CAN
funcional, além do uso do aplicativo descrito no capítulo 3 do presente trabalho, que
está instalado em um celular com sistema Android 4.4.
1º Passo: Considere o esquema inicial descrito na FIG 5.1:
FIG 5.1 – Esquema inicial da prática
Iremos executar o comando refresh (FIG 5.2):
FIG 5.2 – Comando Refresh
46
Com isso, o software irá enviar uma mensagem à rede para verificar quais nós
estão ativos. Com o esquema atual, serão recebidas duas mensagens.
A mensagem vinda do nó Slave 1 (FIG 5.3):
FIG 5.3 – Estado da lâmpada
E a mensagem do nó Slave 2 (FIG 5.4):
FIG 5.4 – Estado do climatizador
2º passo: Após reconhecida a rede, iremos acionar os nós na rede.
Para a lâmpada led (Slave 1) será enviado o comando da FIG 5.5.
FIG 5.5 – Comando para ligar luz
47
Com a mensagem enviada através do celular pelo protocolo Bluetooth, o nó
Master irá enviar o comando para ligar a lâmpada led através da rede CAN para o
nó Slave 2 que irá acionar o módulo IR, o qual ligará a lâmpada led.
O mesmo raciocínio pode ser aplicado para o acionamento do Climatizador
(Slave 2) com o comando da FIG 5.6.
FIG 5.6 – Comando para acionar ventilador
Pode-se concluir através da demonstração que, com o software instalado no
aparelho celular, é possível acionar quaquer carga indutiva, como foi feito no
acionamento do ventilador, e qualquer aparelho que opere através de um comando
por Infra-vermelho, como foi demosnntrado atráves do acionamento da lâmpada led
com a tecnologia IR. Mais ilustrações da prática realizada podem ser observadas no
capítulo 8.
48
6 CONCLUSÃO
A presente pesquisa teve por objetivo a prototipagem e implementação de uma
rede de automação residencial modular baseada no protocolo CAN BUS. As redes
CAN apresentam ótima confiabiliadade, sendo normalmente empregadas em
ambientes com ruídos mecânicos e elétricos, como, por exemplo, em automóveis.
Para isso, foi projetada uma rede que permite a inserção e remoção de nós
dinamicamente, implementado um software para a plataforma Android capaz de
interfacear os comandos do usuário final e o estado dos sensores. A flexibilidade do
acréscimo e retirada de nós é particurlarmente importante em uma residência devido
às constantes mudanças que ocorrem no perfil da família e no tipo de
eletrodomésticos: um apartamento de idosos tem, por exemplo, um conjunto de
equipamentos que difere de uma moradia de jovens universitários. Além disso, dado
o ciclo de vida médio de aparelhos eletrônicos modernos, que é de cinco anos, é
comum que haja grande quantidade de eletrodomésticos sendo renovados a cada
ano, salientando a necessidade de se desenvolver um sistema que apresente alta
adaptabilidade.
Isso posto, foi implementado um conjunto de nós capaz de se comportar de
maneira modularizável. Primeiramente, dois módulos foram confeccionados. O
primeiro a ser projetado foi o nó Slave 1, ou “Lâmpada LED IR”, que possui um
microcontrolador que gera sinais que atuam sobre um módulo infravermelho de
acordo com a ordem recebida da rede CAN, tudo com o intuito de controlar a
luminosidade de um local através de um lampada led que, por sua vez, é operada
via infravermelho. Em seguida, foi construído o nó Master, que tem como função
receber e enviar mensagens através do protocolo CAN BUS e comunicar-se com
mundo exterior à rede CAN. Decidiu-se que o nó Master tivesse como conexão com
um celular (smartphone) através do protocolo Bluetooth.
Os tipos de nós desenvolvidos representam boa parte das cargas que podem
ser empregadas nas casas modernas. O módulo Slave 1 atua em um controle
remoto IR: desta maneira poderíamos controlar qualquer equipamento que possui
esse tipo de controle, tais como televisores, aparelhos de ar-condicionado, DVDs,
entre outros. O módulo Slave 2 age em um ventilador (que é uma carga tipo
49
motor/indutiva). Sendo assim, podemos enquadrar nessa categoria outros tipos de
carga, tais como geladeiras, máquinas de lavar, bem como qualquer motor auxiliar
empregado na automação residencial.
Com o objetivo de introduzir escalabilidade na implementação dessa rede, foi
adotado, no client side, um modelo de software baseado no MVC, no qual o Model
era materializado por uma classe CanNode, possuidora, por sua vez, de alguma
instância de implementação da classe abstrata NodeType, definindo qual era o tipo
de nó que se tratava. Portanto, ao serem criados novos tipos de nós (hardware),
basta ao desenvolvedor do programa Android implementar novas classes que
herdem da classe abstrata NodeType, inserindo ali os bytes descritores do novo nó.
Com a padronização da comunicação entre os módulos, foi possível criar um
ambiente capaz de receber um novo módulo sem que se altere o firmware dos
demais nós existentes. Para fins de comprovação da escalabilidade do sistema, foi
projetado um novo módulo. O novo nó, denominado Slave 2, ou “Climatizador”, atua
através das mensagens vindas do nó Master e possui um microcontrolador que gera
sinais que atuam sobre um módulo de acionamento de um ventilador (carga
indutiva). Esse módulo foi conectado diretamente à rede física do par trançado, já
pertencente à rede CAN dos outros dois módulos previamente projetados. Para que
o novo módulo fosse descoberto na rede, foi necessária apenas a atualização do
software do Android, mantendo-se, desta forma, intactos a rede física pré-existente e
os firmwares anteriores.
A partir da construção conceitual, da escrita do firmware, da implantação dos
módulos em protoboards e da implementação do software de controle no sistema
Android, foi possível observar a aplicabilidade efetiva dos conceitos anteriormente
mencionados, além da escalabilidade obtida a partir da correta aplicação da
modularização.
Para trabalho futuros, pode-se verificar a viabilidade da implantação da rede
aqui desenvolvida em um local que já possua uma infra-estrutura de cabos de pares
trançados, com o objetivo de verificar uma possível queda na taxa de transmissão
devido às distâncias entre os nós. Também se sugere realizar um estudo para a
colocação das terminações resistivas características da rede CAN. Uma sugestão
nessa direção seria a criação de um dispositivo que fosse conectado à extremidades
dos cabos de rede já existentes (anteriormente ligados a um backbone ou ao
50
roteador local). Esse dispositivo poderia incluir em sua composição as terminações
resistivas adequadas para o sistema, de modo a obedecer a exigência do protocolo
CAN. Existe grande relevância nesse estudo, visto que há grande incidência de
cabos de rede que anteriormente eram usados para o acesso à internet, mas que,
devido à conjuntura atual, não são mais utilizados dado o crescimento das redes
sem fio, compondo assim uma potêncial infra-estrutura que pode abrigar o sistema
do presente trabalho.
Quanto ao software desenvolvido para Android, destacam-se como possíveis
melhorias para trabalhos futuros: aperfeiçoar a interface gráfica do cliente Android
(ampliando a experiência do usuário e adaptando melhores Views para o sistema) e
permitir o controle e gerenciamento de usuários, definindo prioridade de comandos
caso mais de um cliente se comunique com um Master.
Diante do exposto, foi visto que é perfeitamente viável utilizar o CAN BUS como
protocolo de automação residencial. Além disso, vive-se um momento em que as
pessoas e empresas buscam soluções velozes e confiáveis para a chamada “casa
inteligente”. Assim sendo, esse projeto vai ao encontro dos anseios de
consumidores e grandes desenvolvedores.
51
7 REFERÊNCIAS BIBLIOGRÁFICAS
ALIEVE, César Adriano. Automação Residencial com Utilização de Controlador Lógico Programável. Novo Hamburgo-RS: Centro Universitário Feevale, 2008. Monografia (Graduação em Ciência da Computação).
ANDROID. Developer Reference Documentation: Bluetooth Adapter. Disponível
em <developer.android.com/reference/android/bluetooth/BluetoothAdapter.html>. Acesso em 28 fev. 2013.
ARNEROBOTICS. Microcontroladores PIC- Teoria Parte 2. Disponível em:
<http://www.arnerobotics.com.br/eletronica/Microcontrolador_PIC_teoria_2.htm>. Acesso em 03 Out. 2014.
BARBOSA, Roberto Luiz Guimaraes. Rede CAN. Belo Horizonte-MG: UFMG, 2003.
Disponível em <http://www.cpdee.ufmg.br/~elt/docs/DSP/Resumo_CAN.pdf>. Acesso em 02 jun 2013.
BEIKIRCH,Helmut. CAN-Transceiver for field bus powerline communications.
Disponível em <http://www.isplc.org/docsearch/Proceedings/2000>. Acesso em 31 mai. 2013.
BOSCH do Brasil. Disponível em:
<http://www.bosch.com.br/br/autopecas/produtos>. Acesso em 15 out. 2012. BRAGA, Newton C. O uso de microcontroladores para acionamento de
tiristores. Disponivel em: <http://www.newtoncbraga.com.br/index.php/artigos/54-dicas/5393-col088.html>. Acesso em 23 mai. 2013.
BURGOSELETRÔNICA. Tiristores. 2010. Disponível em:
<http://www.burgoseletronica.net/tiristores_triac.html>. Acesso em 02 out. 2014. CAN Specification, Version 2.0. Robert Bosch GmbH. Stuttgard, 1991. Disponível em
<http://www.bosch-semiconductors.de/media/pdf_1/canliteratur/can2spec.pdf>. Acesso em 02 out. 2014.
CARVALHO, Rafael Lima de. Sistema de identificação para a casa inteligente
utilizando som. 146 p. Rio de Janeiro-RJ: Instituto Militar de Engenharia, 2008. Dissertação (Mestrado em Sistemas de Computação).
CENSI, Angela. Sistema para Automacao e Controle Residencial Via e-mail.
Blumenal; Universidade Regional de Blumenal, 2001 Monografia (Graduação em Ciência da Computação) . Disponível em: <campeche.inf.furb.br_tccs_2001-I_2001-1angelacensivf>. Acesso em: 13 out. 2012.
52
CHERMONT, Marlon Gripp; CUGNASCA, Carlos Eduardo et al. Sistema Supervisório para Redes LonWorks. São Paulo-SP: USP. Disponivel em <http://www.p2s.com.br/team/scanovas/files/sist_superv_lonworks.pdf>. Acesso em 01 jun. 2013.
DANTAS, Bruno; FERREIRA, Victor; MATOS, Jefferson. Estudos de Dispositivos
utilizados para a automação residencial – Domótica. Iniciação à Pesquisa. Rio de Janeiro: IME, 2013.
FAIRCHILD SEMICONDUTOR. General Purpose 6-PIN Phototransistor
optocoupler. 2002. Disponível em: <http://teslabs.com/meteotek08/fitxers/ datasheets/4N28.pdf>. Acesso em: 01 out. 2014.
FERNANDES, Pedro Miguel de Miranda. Aplicações Domóticas para Cidadãos
com Paralisia Cerebral. Aveiro-Portugal: Universidade de Aveiro, 2001. Dissertação (Mestrado em Tecnologia Domótica). Disponível em: <http://portal.ua.pt/thesaurus/default1.asp?OP2=0&Serie=0&Obra=28&H1=1&H2=0>. Acesso em 01 jun. 2013.
GUIMARÃES, Alexandre. CAN BUS: Barramento Controller Area Network –
implementação. São Paulo: PUC, 2012. IBRAHIM, Dogan. Controller Area Network Projects. Londres, Reino Unido:
Elektor International, 2011. LECHETA, Leandro Pires. Sistema de Iluminação Residencial: uma análise
sobre alternativas para redução do consumo de energia elétrica. 86 p. Cascavel-RS: Faculdade Assis Gurgacz, 2006. Monografia (Graduação em Engenharia de Controle e Automação). Disponível em: <http://www.aureside.org.br/temastec/ilum_resid_TCC.pdf>. Acesso em 22 ago. 2012.
LIMA, Sandro Santos de. Análise e Desenvolvimento de um Ambiente de
Simulação para Apli-cações Domóticas. Rio de Janeiro-RJ; Instituto Militar de Engenharia, 2005. Dissertação (Mestrado em Sistemas e Computação).
LINS, Vitor; MOURA, Waldson. DOMÓTICA: AUTOMAÇÃO RESIDENCIAL. Recife-
PE, UNIBRATEC. Disponível em: <http://www.unibratec.edu.br/tecnologus/wp-content/uploads/2010/12/lins_moura.pdf>. Acesso em 12 mar. 2013.
MANTOVANI, Eduardo. Aplicações e Limitações da Tecnologia LonWorks na
Automação. São Paulo-SP: Escola Politécnica da USP,1998. Disponível em: <www.conceitotecnologia.com.br__artigos_lonworks_aplicacoes_e_limitacoes> Acesso em 12 mar. 2013.
MAZIDI, Muhammad Ali; McKINLAY, Rolin. CAUSEY, Danny. PIC Microcontroller
and Embedded System: using Assembly and C for PIC18. EUA: Pearson, 2008.
53
MERCADO LIVRE. Spot Led Rgb Gu 10 com Controle Remoto Colorido. 2014. <http://produto.mercadolivre.com.br/MLB-583172724-spot-led-rgb-gu10-com-controle-remoto-colorido-_JM>. Acesso em 05 out. 2014.
MICHAELIS. Dicionário da Língua Portuguesa. Disponível em
<michaelis.uol.com.br>. Acesso em 13 mar. 2013. MICROCHIP. MCP2551 High-Speed CAN Tranceiver. 2010. Disponível em:
<https://www.sparkfun.com/datasheets/DevTools/Arduino/MCP2551.pdf> Acesso em 29 set. 2014.
_______. PIC 18F2480/2580/4480/4580 Data Sheet. 2007. Disponível em:
<http://ww1.microchip.com/downloads/en/DeviceDoc/39637d.pdf> Acesso em 30 set. 2014.
MOLINA, Pablo Fernández. Diseño de nodos inteligentes para instalaciones
domóticas basadas en bus. 89 p. Espanha: Universitat Politecnica Superior de Casteldefels, 2008. Trabajo de Fin de Carrera (Ingeniería Técnica de Telecomunicaciones, especialidad en Sistemas de Telecomunicación).
PATTERSON, David A.; HENNESSY, John L. Computer Organization and Design:
The hardware/software interface. 3. ed. EUA: Morgan Kaufmann, 2009. QUINDERÉ, Patrick Romero Frota. Casa Inteligente: um protótipo de sistema de
automação residencial de baixo custo. Fortaleza-CE: Faculdade Farias Brito, 2009. Monografia (Graduação em Ciência da Computação).
ROVING. Roving Networks – Bluetooth modules. RN42Class 2 Bluetooth module
description. Disponível em <http://www.rovingnetworks.com/products/RN42>. Acesso em 2 mar. 2013.
SENSORES, Mecatrônica. Diponível em:
<http://mecattec.blogspot.com.br/2011/07/sensores.html>. Acesso em 15 out. 2012.
SNUBBERLESS & STANDARD. BTA/BTB10 Series - 10A TRIACs. 2002.
Disponível em: <http://www.st.com/web/en/resource/technical/document/ datasheet/CD00004894.pdf>. Acesso em 02 out. 2014.
SAPOTECH. Google volta a investir na domótica com compra de empresa de
videovigilância. Disponível em <http://tek.sapo.pt/noticias/telecomunicacoes/ google_volta_a_investir_na_domotica_com_compr_1387069.html>. Acesso em 02 out. 2014.
SÓ ALARME, 2012. Disponível em <http://www.soalarmes.com>. Acesso em 15 out.
2012.
54
STARTUPI. Microsoft abre aceleradora focada em domótica nos EUA. Disponível em <http://startupi.com.br/2014/06/microsoft-abre-aceleradora-focada-em-domotica-nos-eua/ >. Acesso em 02 out. 2014.
TEXAS INSTRUMENTS. MOC3020 Thru MOC3023 optocouplers / optoisolators.
1998. Disponível em: <http://www.ti.com/lit/ds/symlink/moc3022.pdf>. Acesso em 01 out. 2014.
THOMAZINI, Daniel; ALBUQUERQUE, Pedro. Sensores Industriais: Fundamentos
e Aplicações. 4. ed. São Paulo: Érica, 2005. VARGAS, Alessandra. Estudo sobre Comunicação de Dados via Rede Elétrica
para Aplicações de Automação Residencial/Predial. 65 p. Porto Alegre-RS: Universidade Federal do Rio Grande do Sul, 2004. Monografia (Graduação em Engenharia de Computação).
VARGASP. Acopladores Ópticos. Disponível em: <http://www.vargasp.com/download/livros/Automac4.pdf>. Acesso em 02 out. 2014.
XILINX. Powerline Technologies in Home Networking. Disponivel
em:<http://www.xilinx.com/esp/consumer/home_networking/pdf_files/ch_7_plc/complete.pdf>. Acesso em 05 abr. 2013.
55
8 APÊNDICE
8.1 Figuras da prática realizada
Figuras da apresentação prévia da prática realizada.
