T Ese Alvaro MB Tibi Rica

lvaro Messias Bigonha Tibiri
UMA ARQUITETURA DE SOFTWARE

NEURO-REATIVA PARA
SISTEMAS DE AUTOMAO DO
AMBIENTE CONSTRUDO
Tese apresentada Escola de Engenharia de
So Carlos da Universidade de So Paulo,
como parte dos requisitos para obteno do
Ttulo de Doutor em Engenharia Mecnica.
Orientador: Prof. Titular Mrio Pinotti Jr.
So Carlos, 25 de outubro de 2008.

Cntia, aos meus pais e ao meu irmo,

Agradecimentos
So inmeras as pessoas com quem contamos no dia-a-dia, sem as quais a
execuo de qualquer trabalho seria muito mais difcil. Deixo aqui, meus agradeci-
mentos a todas elas, e especialmente:
ao Prof. Mrio Pinotti Jr., por sua inestimvel amizade, confiana, conselhos
e sugestes;
ao Prof. Lus Carlos Passarini, pela amizade e colaborao para que este
trabalho pudesse ser realizado;
ao Prof. Rafael Vieira de Sousa, pelas conversas e sugestes sobre arquite-
tura reativas;
ao Cristiano, pela amizade, pelo companheirismo e pela parceira em muitos
momentos desse trabalho;
Cntia, pelo apoio, carinho e compreenso durante todo esse trabalho;
aos meus pais, pelo incentivo e apoio ao longo de toda minha caminhada;
aos inmeros professores e autores de livros e de artigos que nos acompa-
nham durante nossa jornada, muito obrigado.

"Nunca ande apenas pelos caminhos traados, pois eles
conduzem somente at aonde os outros j foram."
Alexander Graham Bell

Resumo
Tibiri, A. M. T. Uma Arquitetura de Software Neuro-Reativa para Sistemas de
Automao do Ambiente Construdo. 2008, 133p. Tese (Doutorado em Engenha-
ria Mecnica) Escola de Engenharia de So Carlos, Universidade de So Paulo,
So Carlos, SP, 2008.
Esta tese prope uma arquitetura de software neuro-reativa para sistemas de
Automao do Ambiente Construdo. O objetivo facilitar o desenvolvimento, a ma-
nuteno e a expanso desses sistemas, atravs de trs requisitos norteadores:
modularidade, flexibilidade e capacidade de integrao das partes. Um modelo ba-
seado em unidades chamadas de neurnios e de glndulas proposto. Esses
elementos fundamentais tm caractersticas reativas e podem ser combinados for-
mando diferentes sistemas de automao. Uma verso da arquitetura proposta
programada na linguagem Java utilizando tecnologias como CORBA e MySQL. Por
fim, uma casa fictcia utilizada como exemplo para demonstrar a aplicao da ar-
quitetura proposta.
Palavras chaves: arquitetura de software, automao, sistemas de controle, auto-
mao predial, automao residencial.

Abstract
This thesis presents a neuro-reactive software architecture applied to building
automation systems. The objective is to make development, maintenance and ex-
pansion of these systems easier through three main requirements: modularity, flex-
ibility and parts integration capability. A model with units called neurons and
glands is proposed. These fundamental elements have reactive characteristics and
are combined to constitute automation systems. A version of proposed architecture is
programmed in Java language using technologies like CORBA and MySQL. In the
end, a fictitious home automation system is used as example.
Keywords: software architecture, automation, control systems, building automation,
home automation.

Sumrio

1. INTRODUO .............................................................................................................................. 11
1.1. OBJETIVOS .............................................................................................................................. 14
1.2. CONTRIBUIES ...................................................................................................................... 15
1.3. ORGANIZAO DA TESE ............................................................................................................ 15
2. PARADIGMAS E TECNOLOGIAS PARA SISTEMAS DE AUTOMAO DO AMBIENTE
CONSTRUDO ...................................................................................................................................... 17
2.1. PARADIGMAS PARA SISTEMAS DE AUTOMAO DO AMBIENTE CONSTRUDO ............................... 17
2.1.1. Arquitetura Reativa ........................................................................................................ 17
2.1.2. Redes Neurais Artificiais ............................................................................................... 20
2.1.3. Lgica Difusa ................................................................................................................. 22
2.2. TECNOLOGIAS PARA SISTEMAS DE AUTOMAO DO AMBIENTE CONSTRUDO ............................. 27
2.2.1. Redes de Comunicao ................................................................................................ 27
2.2.1.1. Redes de Computadores ........................................................................................................ 32
2.2.1.1.1. Ethernet .............................................................................................................................. 33
2.2.1.1.2. Internet (TCP/IP) ................................................................................................................. 34
2.2.1.2. Redes de Campo .................................................................................................................... 35
2.2.1.3. Redes de Sensores ................................................................................................................. 36
2.2.2. Middleware .................................................................................................................... 38
2.2.2.1. Orientao a Objetos .............................................................................................................. 38
2.2.2.1.1. CORBA ............................................................................................................................... 39
2.2.2.2. Banco de Dados ...................................................................................................................... 40
3. AUTOMAO DO AMBIENTE CONSTRUDO ........................................................................... 42
3.1. MAVHOME ............................................................................................................................... 43
3.1.1. Reconhecimento de Contexto ....................................................................................... 44
3.1.2. Aes de Controle ......................................................................................................... 46
3.1.3. Arquitetura Fsica .......................................................................................................... 47
3.1.4. Arquitetura Lgica ......................................................................................................... 48
3.1.5. Arquitetura de Software ................................................................................................. 49
3.2. GATOR TECH SMART HOUSE .................................................................................................... 51
3.2.2. Aes de Controle ......................................................................................................... 54
3.2.5. Arquitetura Software ...................................................................................................... 56
3.3. EDIFICIO SISTEMA DE CONTROLE INTEGRADO E ADAPTVEL S VONTADES DOS USURIOS ...... 57
3.3.2. Aes de Controle ......................................................................................................... 59
3.3.5. Arquitetura Software ...................................................................................................... 64
3.4. CONSIDERAES FINAIS ........................................................................................................... 65
4. UMA ARQUITETURA DE SOFTWARE NEURO REATIVA PARA SISTEMAS DE AUTOMAO
DO AMBIENTE CONSTRUDO ............................................................................................................ 67
4.1. REQUISITOS ............................................................................................................................ 67
4.1.1. Particularidades dos Ambientes Construdos ............................................................... 67
4.1.2. Modularidade ................................................................................................................. 68
4.1.3. Flexibilidade ................................................................................................................... 69
4.1.4. Capacidade de Integrao das Partes .......................................................................... 70
4.2. PROPOSTA .............................................................................................................................. 70
4.2.1. Camada Fsica .............................................................................................................. 72
4.2.2. Camada Reativa ............................................................................................................ 72
4.2.2.1. Neurnios ................................................................................................................................ 75

4.2.2.2. Glndulas ................................................................................................................................ 76
4.2.2.3. Domnio ................................................................................................................................... 77
4.2.3. Camada Ontolgica ....................................................................................................... 77
4.2.4. Camada de Aplicao .................................................................................................... 78
5. IMPLEMENTAO DA ARQUITETURA PROPOSTA ................................................................ 81
5.1. CAMADA ONTOLGICA ............................................................................................................. 81
5.1.1. A tabela de entidades: entities....................................................................................... 82
5.1.2. A tabela de conexes: neurotransmiters ....................................................................... 83
5.1.3. Tabelas de comportamento ........................................................................................... 84
5.1.4. Tabelas de parmetro .................................................................................................... 85
5.2. CAMADA REATIVA .................................................................................................................... 85
5.2.1. Comunicao CORBA ................................................................................................... 86
5.2.2. Gerenciamento das funcionalidades de neurnios e de glndulas ............................... 88
5.2.3. Classes de Neurnios e de Glndulas .......................................................................... 94
6. APLICAO DA ARQUITETURA PROPOSTA........................................................................... 97
6.1. CONSTRUINDO O SISTEMA DE AUTOMAO DE UMA CASA .......................................................... 97
6.1.1. Etapa 1 Sistema de Iluminao do Quarto ................................................................. 97
6.1.2. Etapa 2 Sistema de HVAC do Quarto ...................................................................... 103
6.1.3. Etapa 3 Deteco de Ausncia no Quarto ............................................................... 104
6.1.4. Etapa 4 Sistema de Setpoint Personalizado ........................................................... 106
6.1.5. Etapa 5 Sistema para Aproveitamento da Luz Solar ............................................... 107
6.1.6. Etapa 6 Sistema de Controle para o Chuveiro ......................................................... 109
6.1.7. Etapa 7 Mais comportamentos para o quarto .......................................................... 110
6.1.8. Etapa 8 Mais Comportamentos para a Casa ........................................................... 112
6.2. COMUNICAO COM DISPOSITIVOS FSICOS ............................................................................ 112
6.3. CONSIDERAES FINAIS ......................................................................................................... 115
7. CONCLUSO .............................................................................................................................. 118
7.1. PRINCIPAIS CONTRIBUIES ................................................................................................... 119
7.2. TRABALHOS FUTUROS ............................................................................................................ 120
REFERNCIAS ................................................................................................................................... 123
GLOSSRIO ....................................................................................................................................... 128

ndice de Figuras
FIGURA 1 - SISTEMA DE CONTROLE POR DECOMPOSIO: (A) VERTICAL (ARQUITETURA
DELIBERATIVA) E (B) HORIZONTAL (ARQUITETURA REATIVA). ADAPTADO DE BROOKS (1986).
..................................................................................................................................... 18
FIGURA 2 - MODELO DE NEURNIO ARTIFICIAL DE MCCULLOCH E PITTS. ADAPTADO DE BRAGA,
CARVALHO E LUDERMIR (2007). ...................................................................................... 21
FIGURA 3 EXEMPLO DE UM CONTROLADOR DIFUSO COM DUAS VARIVEIS REAIS DE ENTRADA (X1
E X2) E UMA VARIVEL DE SADA (S). H DUAS VARIVEIS LINGSTICAS (CLASSES)
RELACIONADAS A X1 (A E C) E DUAS RELACIONADAS X2 (B E D) - FUZZIFICAO. A BASE DE
REGRAS CONTM DUAS REGRAS. H DUAS VARIVEIS LINGSTICAS (CLASSES)
RELACIONADAS SADA DO SISTEMA (S1 E S2) QUE SO COMBINADAS PELO MTODO DO
CENTRO DE GRAVIDADE (COG) E RESULTAM NA VARIVEL REAL S DEFUZZIFICAO.
ADAPTADO DE OLIVEIRA JUNIOR (1999). .......................................................................... 24
FIGURA 4 - MODELO DE REFERNCIA OSI/ISO. FONTE: SOARES, LEMOS E COLCHER (1995). .... 29
FIGURA 5 - CLASSIFICAO DAS REDES PELA DISTNCIA DE ABRANGNCIA. ADAPTADO DE COOK E
DAS (2005). ................................................................................................................... 31
FIGURA 6 - TOPOLOGIAS USUAIS DE REDES DE COMUNICAO. ADAPTADO DE COOK E DAS (2005).
..................................................................................................................................... 32
FIGURA 7 REDE ETHERNET 10BASET. FONTE: PETERSON E DAVIE (2003). ............................ 33
FIGURA 8 - INTERLIGAO DE DIFERENTES TIPOS DE REDE (INTERNET). HN = ESTAO; RN =
ROTEADOR. FDDI = FIBER DISTRIBUTED DATA DISTRIBUTED. FONTE: PETERSON E DAVIE.
(2003). .......................................................................................................................... 34
FIGURA 9 - ENDEREOS IP: (A) CLASSE A; (B) CLASSE B; (C) CLASSE C. FONTE: PETERSON E
DAVIE (2003) ................................................................................................................. 35
FIGURA 10 - REDE DE CAMPO (REDE DE CONTROLE): TOPOLOGIA EM BARRA. ADAPTADO DE
MAHALIK E LEE (2003). ................................................................................................... 36
FIGURA 11 - EXEMPLOS DE NS DE REDES DE SENSORES COMERCIAIS E ACADMICAS. FONTE:
TIBIRI (2007). ............................................................................................................. 37
FIGURA 12 - EXEMPLO DE MODELO COMPUTACIONAL ORIENTADO A OBJETOS. FONTE: COLEMAN
ET AL. (1996). ................................................................................................................ 39
FIGURA 13 INVOCAO DE OPERAES EM OBJETOS CORBA. ADAPTADO DE BOLTON (2002).
..................................................................................................................................... 40
FIGURA 14 PLANTA BAIXA DA MAVHOME. FONTE: ROY ET AL. (2003). .................................... 44
FIGURA 15 PLANTA DA MAVHOME E MODELO GRFICO DA DISPOSIO DOS SETORES. FONTE:
DAS ET AL. (2002). ......................................................................................................... 45
FIGURA 16 GATOR TECH SMART HOUSE. FONTE: HELAL ET AL. (2005). ................................. 51
FIGURA 17 MAPEAMENTO DO PISO INTELIGENTE E PLACA DE PISO. ADAPTADO DE HELAL ET AL.
(2005). .......................................................................................................................... 53
FIGURA 18 ARQUITETURA LGICA DA GTSH. FONTE: HELAL ET AL. (2005). ........................... 56
FIGURA 19 ESCRITRIO TPICO DO LESO-PB. FONTE: GUILLEMIN (2003). ............................ 58
FIGURA 20 PR-PROCESSAMENTO DOS DADOS. FONTE: GUILLEMIN (2003). ........................... 60
FIGURA 21 DIAGRAMA DO CONTROLADOR DE POSIO DO DISPOSITIVO DE SOMBREAMENTO
QUANDO H PRESENA DE USURIOS. FONTE: GUILLEMIN (2003). ..................................... 61
FIGURA 22 ARQUITETURA DO SISTEMA DE CONTROLE DO LESO-PB. FONTE: GUILLEMIN (2003).
..................................................................................................................................... 62
FIGURA 23 REDE EIB E ATUADORES E SENSORES. FONTE: GUILLEMIN (2003). ....................... 63
FIGURA 24 ARQUITETURA DE CONTROLE DE TRS NVEIS DO LESO-PB. FONTE: GUILLEMIN
(2003). .......................................................................................................................... 64
FIGURA 25 - CAMADAS DA ARQUITETURA PROPOSTA. ............................................................... 72
FIGURA 26 MODELO DE NEURNIO. AS ENTRADAS POSSUEM VALORES (V
E
) E PESOS (W
E
)
DISTINTOS. A SADA PROPAGA O MESMO VALOR (V
S
) PARA DIFERENTES NEURNIOS ATRAVS

DE CONEXES COM PESOS (W
S
) DISTINTOS. H TAMBM RECEPTORES PARA AS MENSAGENS
ENVIADAS POR GLNDULAS (EM VERMELHO). .................................................................... 76
FIGURA 27 MODELO DE GLNDULA. AS ENTRADAS POSSUEM VALORES (V
E
) E PESOS (W
E
)
DISTINTOS. A SADA PROPAGA O MESMO STATUS (S) E TIPO (T) PARA TODOS OS NEURNIOS E
AS GLNDULAS PERTENCENTES AO SEU DOMNIO. H TAMBM RECEPTORES PARA AS
MENSAGENS ENVIADAS POR OUTRAS GLNDULAS. ............................................................ 76
FIGURA 28 - DIAGRAMA DA CLASSE NEURONCORBA. ............................................................. 88
FIGURA 29 - DIAGRAMA DA CLASSE GLANDCORBA. ................................................................ 88
FIGURA 30 - DIAGRAMA DA CLASSE NEURONCLASS COM OS MTODOS ABSTRATOS. .................. 92
FIGURA 31 - DIAGRAMA DA CLASSE GLANDCLASS COM OS MTODOS ABSTRATOS. .................... 92
FIGURA 32 - DIAGRAMA DA CLASSE NEURONCLASS COM OS MTODOS UTILITRIOS. .................. 93
FIGURA 33 - DIAGRAMA DA CLASSE GLANDCLASS COM OS MTODOS UTILITRIOS. .................... 94
FIGURA 34 - MALHA DE CONTROLE DA ILUMINAO DO QUARTO. ............................................... 98
FIGURA 35 - DETECO DE AUSNCIA ..................................................................................... 99
FIGURA 36 ETAPA 1: DIAGRAMA DE RELACIONAMENTO DO SISTEMA DE ILUMINAO DO
QUARTO....................................................................................................................... 100
FIGURA 37 - PARMETROS DE CONFIGURAO: REATRDO DE TEMPO E PID ILUMINAO. ........ 101
FIGURA 38 - ETAPA 2: DIAGRAMA DE RELACIONAMENTO DO SISTEMA DE HVAC DO QUARTO. .. 104
FIGURA 39 ETAPA 3: DIAGRAMA DE RELACIONAMENTO DO SISTEMA DE DETECO DE
AUSNCIA. ................................................................................................................... 105
FIGURA 40 ETAPA 3: DIAGRAMA DE RELACIONAMENTO DO SISTEMA DE DETECO DE AUSNCIA
COM ACRSCIMO DE MAIS DOIS SENSORES DE VARIAO DE PRESSO. ............................ 105
FIGURA 41 ETAPA 4: DIAGRAMA DE RELACIONAMENTO DO SISTEMA DE SETPOINT
PERSONALIZADO. ......................................................................................................... 107
FIGURA 42 ETAPA 5: DIAGRAMA DE RELACIONAMENTO DO SISTEMA PARA APROVEITAMENTO DA
LUZ SOLAR................................................................................................................... 108
FIGURA 43 ETAPA 6: DIAGRAMA DE RELACIONAMENTO DO SISTEMA DE CONTROLE PARA O
CHUVEIRO. ................................................................................................................... 110
FIGURA 44 ETAPA 7: DIAGRAMA DE RELACIONAMENTO DE MAIS COMPORTAMENTOS PARA O
QUARTO....................................................................................................................... 111
FIGURA 45 ETAPA 8: DIAGRAMA DE RELACIONAMENTO DE MAIS COMPORTAMENTOS PARA A
CASA. .......................................................................................................................... 112
FIGURA 46 PLANTA DOS QUARTOS COM A POSIO DOS SENSORES INSTALADOS. ................. 114

11

1. Introduo
O homem passa mais tempo em casa do que em qualquer outro lugar
(INTILLE, 2002). Segundo Kolokotsa et al. (2001), as pessoas permanecem 80% de
suas vidas dentro das edificaes. Promover condies de conforto e eficincia e-
nergtica nos ambientes construdos tem se tornado mais importante a cada dia.
Neste sentido, os avanos tecnolgicos vm permitindo que os computadores go-
vernem os ambientes buscando melhorar o conforto dos usurios, o consumo de
energia e a segurana (CAYCI; CALLAGHAN; CLARKE, 2000).
Uma casa como uma mquina para se viver dentro (SHARPLES;
CALLAGHAN; CLARKE, 1999). As construes modernas tm fortes similaridades
com uma mquina no sentido de conterem uma mirade de dispositivos mecnicos,
eltricos, eletrnicos e computacionais (CALLAGHAN et al., 2000). Esses dispositi-
vos microprocessados podem se comunicar uns com os outros e se comportar inte-
ligentemente (MOZER, 1998). Esse comportamento inteligente dos ambientes
uma meta que envolve uma variedade de disciplinas (COOK; DAS, 2007).
A literatura aponta pelo menos duas grandes vertentes preocupadas com a a-
plicao de sistemas computacionais nos ambientes construdos, tambm chama-
dos de Ambientes Inteligentes quando so embarcados com diversos dispositivos
computacionais. A primeira vertente tem como foco o controle do ambiente, isto ,
sistemas que atravs de sensores monitoram variveis ambientais (como luz, tempe-
ratura, movimentao, etc.) e atuam no ambiente atravs de atuadores (como aque-
cedores, luminrias, janelas operadas eletronicamente, etc.) (HAGRAS et al., 2003).
Algoritmos de controle visando eficincia so propostos por diversos autores: Guil-
lemin (2003), Kolokotsa et al. (2006) e Dounis (2007). Busca-se aproveitar melhor os
12

recursos materiais e energticos disponveis como o calor e a luz solares, os ventos,
etc., e garantir o conforto e a segurana aos usurios. Essa vertente est relaciona-
da com as reas conhecidas como Automao Predial e Automao Residencial,
aqui tratada como Automao do Ambiente Construdo.
Cabe neste momento, conceituar o termo Automao do Ambiente Construdo
que ser utilizado ao longo de todo este trabalho. Automao refere-se idia de
no interveno humana; ou de sistemas capazes de executar tarefas com certo
grau de autonomia. Ambiente Construdo refere-se ao espao fsico artificial provido
pelo homem, tais como edifcios, casas, dormitrios, cozinhas, banheiros, espaos
pblicos, etc. onde o homem passa a maior parte da sua existncia. Conceitua-se, a
partir dessas idias, Automao do Ambiente Construdo como os sistemas que
possuem certo grau de autonomia para operao do Ambiente Construdo atravs
do controle automtico de seus subsistemas. Como conseqncia da automao
desses ambientes, novos servios e novas facilidades so oferecidos aos usurios,
provendo conforto, economia e segurana.
A segunda vertente se preocupa em criar ambientes saturados com dispositi-
vos computacionais e com grande habilidade de comunicao
(SATYANARAYANAN, 2001). Estes dispositivos devem interagir de forma transpa-
rente com as pessoas, isto , sem sobrecarregar seus sentidos, atravs de uma inte-
rao suave (WEISER; BROWN, 1996). O objetivo permitir que os computadores
participem de atividades que tradicionalmente no envolvem computao, com as
quais a interao com sistemas computacionais ocorrer de forma imperceptvel,
como se estivesse interagindo com outras pessoas (COEN, 1998). Ao invs de colo-
car as pessoas no mundo virtual do computador, busca-se colocar o computador no
13

mundo real das pessoas (BROOKS, 1997). Esta rea conhecida como Computa-
o Ubqua ou Computao Pervasiva.
Enquanto a Automao do Ambiente Construdo tem como preocupao fun-
damental o ambiente, a Computao Pervasiva preocupa-se fundamentalmente com
as interaes entre os diversos dispositivos computacionais dispersos no ambiente e
as pessoas. No primeiro caso, a computao um meio, isto , utiliza-se o software
para automatizar o ambiente. No segundo caso a computao o fim, isto , utiliza
o ambiente como interface de comunicao do software.
As duas reas se entrelaam e possuem caractersticas comuns. Entre elas es-
t a importncia do reconhecimento de contexto (GUILLEMIN; MOREL, 2001;
HAGRAS et al., 2003; HELAL et al., 2005; COOK et al., 2003). Dey (2001) define
contexto como qualquer informao que pode ser usada para caracterizar a situao
de uma entidade. Uma entidade uma pessoa, um lugar ou um objeto que consi-
derado relevante para a aplicao. Reconhecer contexto significa poder reconhecer
situaes importantes para o funcionamento do sistema.
Nas duas reas, a arquitetura de software desempenha um papel crucial, j
que ela que define a estrutura central do sistema, o software. A arquitetura de
software engloba duas caractersticas importantes de um programa de computador:
a estrutura hierrquica de componentes (mdulos) procedimentais, e a estrutura de
dados (PRESSMAN, 1995). A facilidade de programao, de reutilizao e de ex-
panso do software est intimamente ligada arquitetura de software utilizada.
Apesar da importncia da arquitetura de software nas duas reas de pesquisa,
os trabalhos ligados a Automao do Ambiente Construdo praticamente no abor-
dam esse tema. Provavelmente, isso ocorre porque a computao um meio e no
14

um fim na Automao do Ambiente Construdo, o que tambm reflete nos perfis dos
pesquisadores desta rea que na sua grande maioria no so ligados rea de
computao. No entanto, a no preocupao com a arquitetura de software um
fator limitante na organizao e na integrao de sistemas em solues de Automa-
o do Ambiente Construdo que se tornam cada vez mais complexas.
Os sistemas de Automao do Ambiente Construdo esto sujeitos a constan-
tes expanses e reconfiguraes (COEN, 1997). Mudanas nos gostos, hbitos e
vontades dos usurios, e a evoluo tecnolgica contnua so alguns dos fatores
que devem ser levados em conta no projeto de um sistema de Automao do Ambi-
ente Construdo. Cada soluo deve contemplar especificidades dos usurios e do
ambiente, o que torna uma soluo geral quase impraticvel para estes sistemas
(MOZER, 1998; DOUNIS et al., 1995). Vale ressaltar ainda o carter multi-objetivo,
baseado em contexto e integrado dessas aplicaes, as quais buscam satisfazer os
usurios, ser eficientes energeticamente, garantir a segurana, entre outros, de for-
ma integrada e de acordo com contexto (DOUNIS et al., 1995; GUILLEMIN;
MOLTENI, 2002; KOLOKOTSA et al., 2002; HAGRAS et al., 2003; HELAL et al.,
2005; DEY; ABOWD; SALBER, 1999; GUILLEMIN; MOREL, 2001). Uma arquitetura
de software para estes sistemas deve ser capaz de lidar com todos esses aspectos.
1.1. Objetivos
O objetivo central deste trabalho propor uma arquitetura de software para Au-
tomao do Ambiente Construdo que facilite o desenvolvimento de sistemas de Au-
tomao do Ambiente Construdo. Ao objetivo central se associam os seguintes ob-
jetivos:
15

investigar solues de software nas reas de Automao do Ambiente Cons-
trudo e Computao Pervasiva;
investigar os sistemas de Automao do Ambiente Construdo;
implementar em software a arquitetura proposta; e
exemplificar o uso da arquitetura proposta.
1.2. Contribuies
Duas contribuies principais se destacam:
Proposio de uma Arquitetura de Software para Automao do Ambiente
Construdo.
Programao da arquitetura proposta em software.
1.3. Organizao da tese
Esta tese est organizada da seguinte maneira:
Captulo 2. So apresentados os principais paradigmas e tecnologias utili-
zados em sistemas de Automao do Ambiente Construdo. As tecnologias
apresentadas neste captulo so fundamentais para a construo de siste-
mas de Automao de Ambiente Construdo.
Captulo 3. Atravs de trs estudos bibliogrficos, descreve exemplos de
arquiteturas de software relacionadas a sistemas de Automao do Ambien-
te Construdo.
16

Captulo 4. Prope uma Arquitetura de Software para Automao do Ambi-
ente Construdo baseada em unidades com caractersticas reativas chama-
das neurnios e glndulas.
Captulo 5. Descreve a programao de uma verso da arquitetura proposta
no captulo 4.
Captulo 6. Ilustra a aplicao da arquitetura proposta numa casa fictcia.
Captulo 7. So apresentadas concluses e consideraes sobre as princi-
pais contribuies, e sugestes para trabalhos futuros.
17

2. Paradigmas e Tecnologias para
Sistemas de Automao do
Ambiente Construdo
A literatura relacionada Automao do Ambiente Construdo possui uma vari-
edade de solues para sistemas de Automao do Ambiente Construdo baseadas
em diferentes paradigmas e tecnologias. Busca-se neste captulo descrever os pa-
radigmas e as tecnologias usuais nesta rea do conhecimento. importante ressal-
tar que estes no so concorrentes e sim complementares.
2.1. Paradigmas para Sistemas de Automa-
o do Ambiente Construdo
Nesta seo so tratados trs paradigmas (Arquitetura Reativa, Redes Neurais
Artificiais e Lgica Difusa) utilizados em aplicaes de Automao do Ambiente
Construdos. As Arquiteturas Reativas e as Redes Neurais Artificiais so base para a
arquitetura proposta no captulo 4. Controladores Difusos so utilizados cada vez
mais em sistemas de controle no Ambiente Construdo e precisam ser levados em
considerao no desenvolvimento de solues de automao para o ambiente cons-
trudo.
2.1.1. Arquitetura Reativa
A Arquitetura Reativa foi proposta por Brooks (1986) como uma abordagem al-
ternativa para sistemas de controle em robs mveis. Nessa abordagem, no h um
modelo abstrato interno do ambiente a atuao uma resposta direta a um est-
mulo ambiental contrapondo-se Arquitetura Deliberativa ou Clssica, mais anti-
ga. Os mapeamentos entre estmulos e atuao so chamados de comportamentos.
18

da combinao dos comportamentos que emerge o comportamento geral do sis-
tema. A construo de sistemas reativos freqentemente conhecida como progra-
mao por comportamentos, j que o componente fundamental neste tipo de arqui-
tetura um comportamento (MURPHY, 2000).
Na Arquitetura Deliberativa h um mdulo de planejamento que possui um mo-
delo abstrato interno do ambiente. Este mdulo processa os estmulos segundo esse
modelo interno de ambiente e determina qual ao tomar. O comportamento geral
do sistema determinado por um ciclo contnuo e seqencial de sensoriar, planejar
e atuar (Sense, Plan, Act) (MURPHY, 2000). Brooks (1986) classificou esta arquite-
tura como decomposio vertical, na qual todo o processamento ocorre de maneira
seqencial e linear, em contraposio decomposio horizontal (sistemas reati-
vos), na qual cada comportamento uma unidade independe e paralela de proces-
samento. A Figura 1 ilustra esses dois conceitos.

Figura 1 - Sistema de controle por decomposio: (a) vertical (arquitetura deliberativa) e (b)
horizontal (arquitetura reativa). Adaptado de Brooks (1986).
A robtica mvel e os sistemas de automao do ambiente construdo possu-
em similaridades. Ambos se relacionam diretamente com o mundo fsico (HAGRAS
et al., 2003), ambos devem reagir a influncias externas as quais esto sujeitos
19

(KULKARNI, 2002), ambos necessitam processar mltiplos eventos simultaneamen-
te e reagir a mudanas rpidas de contexto (COEN, 1997), ambos capturam infor-
maes de uma variedade de sensores e usam inteligncia embarcada para deter-
minar as aes de controle (HAGRAS et al., 2003). O ambiente construdo como
um rob no qual vivemos dentro (HAGRAS et al., 2003). A principal vantagem no
uso de sistemas reativos que estes descartam a necessidade de um modelo abs-
trato, substituindo-o pelo prprio ambiente (CALLAGHAN et al., 2004). Este princpio
sumarizado por Brooks (1991): o mundo ele prprio o melhor modelo.
Murphy (2000) cita algumas vantagens na utilizao da Arquitetura Reativa: a
modularidade dos comportamentos e a facilidade de test-los isoladamente; a facili-
dade de expanso do sistema aumentando sua capacidade; a possibilidade de sur-
gimento de comportamentos complexos a partir da combinao de comportamentos
mais simples; e o suporte s boas prticas de programao como decomposio,
modularidade e testes incrementais. Essas caractersticas tornam o uso dessa arqui-
tetura interessante para aplicaes de Automao do Ambiente Construdo.
Hagras et al. (2003) e Callaghan et al. (2004) utilizam a Arquitetura Reativa
como base para construo de um sistema computacional para automao de um
quarto, chamado de i.Dorm. Para lidar com o grande nmero e a diversidade de da-
dos de entrada e de sada, assim como a presena de fatores de impreciso e de
imprevisibilidade (como as pessoas), os autores propem a diviso do problema em
mltiplos comportamentos. Cada um responde a uma situao especfica. No siste-
ma proposto, duas variveis so controladas: a temperatura de aquecimento e o n-
vel de iluminncia. Para control-las quatro tipos de comportamentos foram propos-
tos: segurana (garante que as condies do ambiente sempre ficaro num patamar
seguro), emergncia (no caso de alarmes de emergncia, como incndio, as portas
20

so abertas, e a iluminao e o aquecimento so desligados), economia (garante
que energia no ser desperdiada quando o ambiente estiver desocupado) e con-
forto (conjunto de comportamentos que adaptam o ambiente s preferncias de ca-
da usurio). Cada comportamento um controlador independente para temperatura
e para iluminncia. De acordo com o contexto, um conjunto de pesos atrelados a
cada comportamento determinado dinamicamente. O comportamento geral do sis-
tema resultado da resposta de cada comportamento ponderado por seus pesos.
Kulkarni (2002) prope um sistema baseado em comportamentos reativos para
automao de ambientes inteligentes. Conjuntos de reaes so agrupadas em
comportamentos que correspondem determinada atividade, como uma reunio,
uma apresentao de filme ou a ausncia de atividade em uma sala vazia. Um com-
portamento ativado quando detectada a ocorrncia da atividade relacionada a
ele. Existe um grau de hierarquia entre os comportamentos. Assim quando mais de
um comportamento ativado ao mesmo tempo, o de maior peso na hierarquia su-
prime aes conflitantes nos comportamentos de menor peso. Um mecanismo de
dependncia tambm permite que certos comportamentos sejam atrelados a outros
comportamentos hierarquicamente inferiores, e s possam se ativar aps a ativao
desses ltimos.
2.1.2. Redes Neurais Artificiais
Uma rede neural artificial um sistema paralelo distribudo composto por neu-
rnios artificiais (unidades de processamento simples) dispostos em camadas e in-
terligados por conexes. Na maioria dos casos, essas conexes so associadas a
pesos que armazenam o conhecimento adquirido pela rede neural atravs de um
processo de aprendizagem. As capacidades de aprender e generalizar so os prin-
21

cipais atrativos desses sistemas (BRAGA; CARVALHO; LUDERMIR, 2007; HAYKIN,
1999).
O primeiro modelo artificial de um neurnio foi fruto dos trabalhos de McCulloch
e Pitts (BRAGA; CARVALHO; LUDERMIR, 2007). Foi uma simplificao do conhe-
cimento da poca sobre o neurnio biolgico. Em conjunto, esses neurnios possu-
em alto poder computacional e podem resolver problemas de elevada complexidade.
Matematicamente, o neurnio de McCulloch e Pitts uma entidade com m entradas
(x
1
,...,x
m
) e uma sada y
k
. Pesos (w
k1
,...,w
km
) so acoplados s conexes de entrada
e ponderam os valores das mesmas. A sada do neurnio, y
k
, resultado da aplica-
o de uma funo de ativao, f(.), sobre a soma ponderada das entradas pelos
seus pesos. A Figura 2 ilustra o modelo de neurnio artificial de McCulloch e Pitts
(BRAGA; CARVALHO; LUDERMIR, 2007).

Figura 2 - Modelo de neurnio artificial de McCulloch e Pitts.
Adaptado de Braga, Carvalho e Ludermir (2007).
Mais tarde, Frank Rosenblat (BRAGA; CARVALHO; LUDERMIR, 2007) apre-
sentou o perceptron, um modelo de rede neural com pesos ajustveis que atravs
de um algoritmo de aprendizado poderia ser treinado para classificar certos tipos de
padres. O aprendizado uma das caractersticas mais importantes das redes neu-
rais artificiais. Segundo Braga, Carvalho e Ludermir (2007), aprendizado o pro-
cesso pelo qual parmetros livres de uma rede neural so ajustados por meio de
22

uma forma continuada de estmulo pelo ambiente externo, sendo o tipo especfico de
aprendizado definido pela maneira particular como ocorrem os ajustes dos parme-
tros livres. Neurnios individuais possuem capacidade computacional limitada. O
poder de uma rede neural artificial est na capacidade de associao e de co-
nexo dos neurnios.
As aplicaes das redes neurais artificiais em problemas de automao do am-
biente construdo concentram-se em fazer predies. Mozer (1998) props um sis-
tema neural para predizer o comportamento e a vontade de habitantes em uma ca-
sa, The Neural Network House. Uma rede neural com trs camadas, 107 entradas,
50 neurnios intermedirios e 8 sadas, foi utilizada para predizer a ocupao de
(oito) zonas da casa com dois segundos de antecedncia. As entradas so alimen-
tadas com sinais de reed switches, sensores de movimento e de nvel sonoro, e a
data. As predies de ocupao das oito zonas da casa so utilizadas para controlar
bancos de lmpadas, aquecimento (ar/gua), ventiladores e alto-falantes. Rivera-
illingworth, Callaghan e Hagras (2005) utilizaram uma rede neural adaptativa para
reconhecer atividades, como dormir, trabalhar no computador ou comer. Guillemin e
Morel (2001) usaram uma rede neural artificial para prever radiao solar com seis
horas de antecedncia em escritrios.
2.1.3. Lgica Difusa
A Lgica Difusa ou Lgica Nebulosa foi inicialmente descrita por Lofti A. Zadeh
em um artigo intitulado Fuzzy Sets (ZADEH, 1965). O autor props uma teoria para
o tratamento de conjuntos chamados difusos (fuzzy). Os conjuntos difusos ou clas-
ses podem conter elementos com graus de pertinncia (membership) variando de 0
a 1, em contraposio aos conjuntos da teoria clssica de conjuntos que possuem
23

grau de pertinncia 0 ou 1. A possibilidade de trabalhar com graus de pertinncia
contnuos de 0 a 1 permite modelar aspectos encontrados comumente no mundo
real e de difcil modelagem na teoria de conjuntos tradicional. Como exemplo, em
uma classe copo cheio, um copo com gua at a metade pode facilmente ser mode-
lado como cheio com pertinncia de 50% (0,5), e como vazio com pertinncia 50%
(0,5) (OLIVEIRA JNIOR, 1999). A Lgica Difusa oferece um arcabouo para repre-
sentar conhecimento impreciso e incerto, o que permite lidar com informaes vagas
e incompletas (HAGRAS et al., 2003), como conforto (DOUNIS et al., 1995;
KOLOKOTSA et al., 2001), tpicas em aplicaes de Automao do Ambiente Cons-
trudo.
Em aplicaes de engenharia de controle, os controladores lgicos difusos
(FLC Fuzzy Logic Controller) possibilitam o controle de processos complexos utili-
zando a experincia humana (ZIMMERMANN, 2001). A idia bsica incorporar a
experincia humana no projeto do controlador. De um conjunto de regras lingsticas
que descrevem a estratgia de controle do operador humano, um algoritmo de con-
trole construdo utilizando palavras (classes) que so definidas como conjuntos
difusos (ZIMMERMANN, 2001).
A Figura 3 ilustra um controlador lgico difuso com duas entradas (x1 e x2) e
uma sada (s). Duas variveis reais de entrada (x1 e x2) so relacionadas a quatro
classes ou conjuntos difusos ou variveis lingsticas (A e C; B e D) atravs de fun-
es de pertinncia (no exemplo, com formato triangulares) etapa chamada de
fuzzificao. De acordo com o valor da varivel de entrada e a funo de pertinn-
cia, um grau de pertinncia atribudo. Comumente as funes de pertinncia tm
formatos triangular, trapezoidal, gaussiana e sigmoidal (OLIVEIRA JNIOR, 1999).
24

Figura 3 Exemplo de um controlador difuso com duas variveis reais de entrada (x1 e x2)
e uma varivel de sada (s). H duas variveis lingsticas (classes) relacionadas a x1 (A e
C) e duas relacionadas x2 (B e D) - fuzzificao. A base de regras contm duas regras. H
duas variveis lingsticas (classes) relacionadas sada do sistema (S1 e S2) que so
combinadas pelo mtodo do centro de gravidade (COG) e resultam na varivel real s
defuzzificao. Adaptado de Oliveira Junior (1999).
Uma base de regras com duas regras relaciona as classes A e B, e C e D, utili-
zando o operador lgico E (mnimo), o que resultar em um valor de pertinncia para
os conjuntos difusos de sada (S1 e S2) etapa chamada de inferncia difusa. Os
operadores lgicos E e OU so utilizados para combinar conjuntos difusos. O opera-
dor E, de interseo, retorna o valor mnimo entre seus operandos. O operador OU,
de unio, retorna o valor mximo entre seus operandos. Cada regra formada por
uma estrutura condicional do tipo SE...ENTO que estabelece a dependncia entre
uma preposio e uma conseqncia. Assim se uma preposio avaliada com
grau de pertinncia de 0,6 (60% verdadeira), a conseqncia ter grau de pertinn-
cia 0,6 (60%).
Controladores que relacionam uma preposio com uma conseqncia repre-
sentada por conjuntos difusos so conhecidos como controladores do tipo Mam-
25

dani. Quando as conseqncias so representadas por funes reais que relacio-
nam a sada diretamente com valores reais das entradas, tem-se controladores do
tipo Sugeno.
A ltima etapa do processo transformar o resultado da inferncia difusa em
valores reais, etapa conhecida como defuzzificao. Alguns mtodos so comumen-
te utilizados neste momento: centro de gravidade (COG Center Of Gravity), mdia
dos mximos (MOM Mean Of Maxima), centro de rea (COA Center Of Area),
esquerda do mximo (LOM Left Of Maximum), direita do mximo (ROM Right Of
Maximum) e centro do mximo (COM Center Of Maximum). Todos esses mtodos
buscam encontrar um valor real a partir do resultado da inferncia difusa, isto , so
mtodos de ponderao de regras difusa. No exemplo, foi utilizado o mtodo centro
de gravidade (COG).
Vrios trabalhos utilizam controladores lgicos difusos em sistemas de auto-
mao do ambiente construdo. Dounis, Lefas e Argiriou, (1995) apontam como difi-
culdade levantar modelos especficos para cada edificao onde se instalar siste-
mas de condicionamento de ar. Os autores destacam que controladores lgicos di-
fusos se adquam naturalmente a esse tipo de problema. Eles propem um contro-
lador lgico difuso do tipo Mamdani para controlar o ngulo de abertura da janela
(AW), a potncia de aquecimento (AH) e de refrigerao (AC) de uma sala. O contro-
lador tem como entradas a temperatura ambiente (T
amb
) e um ndice de conforto
trmico (PMV Predictive Mean Vote). Variveis lingsticas so utilizadas para mo-
delar as variveis reais do sistema. A base de regras possui 23 regras. Para defuzzi-
ficao so utilizados dois mtodos: mdia dos mximos (MOM) e centro de rea
(COA).
26

Os controladores convencionais, como PID e ON-OFF, apresentam respostas
ineficientes a distrbios e a modificaes no ambiente construdo, e dificuldade na
determinao de modelos matemticos para estes ambientes, o que torna os contro-
ladores lgicos difusos propcios para aplicaes deste tipo (LAH et al., 2006;
KOLOKOTSA et al., 2001; KOLOKOTSA et al., 2006). Lah et al. (2006) apresentam
um controlador lgico difuso do tipo Sugeno com duas entradas (setpoint de ilumi-
nncia e erro de iluminncia) e uma sada (ngulo de abertura da persiana), e fun-
es de pertinncia dos tipos triangular e trapezoidal, com objetivo de controlar o
ngulo de abertura de uma persiana para aproveitamento de luz natural. Kolokotsa
et al. (2006) propem um controlador lgico difuso do tipo Mamdani visando garantir
o conforto dos usurios. So medidos o conforto trmico (PMV), a qualidade do ar
(ppm de CO
2
no ar) e o conforto visual (iluminncia), e controlados a potncia de
aquecimento/refrigerao, o ngulo de abertura de uma janela, a abertura de um
dispositivo de sombreamento e a potncia da iluminao. Foram utilizadas funes
de pertinncia dos tipos triangular e trapezoidal, um controlador para cada varivel
controlada e o mtodo do centro de gravidade (COG) para defuzzificao.
Guillemin (2003) utilizou controladores lgicos difusos em um sistema integrado
para controle do aquecimento, da iluminao e da abertura de um dispositivo de
sombreamento. O autor utilizou um controlador do tipo Mamdani com um conjunto
de nove regras e as seguintes entradas: iluminncia horizontal externa, estao do
ano, altitude solar e azimute solar, para o controle do aquecimento. Para controlar a
porcentagem de abertura do dispositivo de sombreamento foi utilizado um controla-
dor Sugeno com um conjunto de 25 regras e as seguintes entradas: conforto atual e
conforto previsto para as prximas seis horas, onde o conforto est relacionado a
diferena entre o setpoint de temperatura e a temperatura interna.
27

Outros trabalhos tambm utilizam controladores lgicos difusos para automa-
o de sistemas no ambiente construdo. Dounis e Caraiscos (2007) desenvolveram
um sistema difuso para coordenar diferentes controladores difusos visando conforto
e eficincia energtica. Hagras et al. (2003) criaram um sistema reativo com compor-
tamentos difusos e um coordenador difuso de comportamentos. Kristl et al.(2008)
propuseram um sistema de controle difuso para um dispositivo de sombreamento
visando conforto trmico e lumnico, e eficincia energtica. Alcal et al. (2005) utili-
zaram um controlador difuso para sistemas de condicionamento de ar.
2.2. Tecnologias para Sistemas de
Automao do Ambiente Construdo
Esta seo aborda tecnologias de redes de comunicao e de middleware utili-
zadas aplicaes de automao do ambiente construdo. Essas tecnologias so fun-
damentais para a construo de sistemas de automao do ambiente construdo, e
serviro de base para a implementao da arquitetura proposta no captulo 5.
2.2.1. Redes de Comunicao
As redes de comunicao so sistemas de comunicao formados por ns com
capacidade de transmitir e receber informaes (COOK; DAS, 2005). Elas desem-
penham um papel de destaque na automao do ambiente construdo, permitindo
que dispositivos como sensores, atuadores, controladores e computadores possam
se comunicar. Devido a sua usual complexidade, o projeto, a construo e a descri-
o de uma rede de comunicao so feitos utilizando como referncia uma estrutu-
ra de camadas padronizada pela ISO (International Organization for Standardization)
o modelo de referncia OSI (Open Systems Interconnection) que possui sete
28

camadas descritas a seguir (ZHENG; AKHTAR, 2002; SOARES; LEMOS;
COLCHER, 1995):
Fsica. Responsvel pelo formato do canal e sinal de comunicao sem a
preocupao com significado ou com a forma de agrupamento dos dados.
Incluem-se caractersticas mecnicas, eltricas, funcionais e de procedimen-
tos de transmisso de dados pelo meio fsico.
Enlace. Responsvel pelo acesso e controle do canal de comunicao. In-
cluem-se protocolos de acesso ao meio, de deteco de erros, de delimita-
o de quadros, etc..
Rede. Responsvel pelo formato individual dos pacotes de dados. Controla
o chaveamento e estabelece a rota para conexo e a troca de informao
entre ns.
Transporte. Responsvel pela entrega de seqncias de pacotes.
Sesso. Responsvel pela organizao, sincronia e gerncia de conexo
entre programas.
Apresentao. Responsvel por converses para representao de dados.
Incluem-se a compresso de texto, a criptografia, etc..
Aplicao. Responsvel por detalhes e caractersticas especficas das in-
formaes trocadas entre os aplicativos. a interface entre a rede comuni-
cao e o aplicativo.
Neste modelo, cada nvel (camada) deve ser pensado como um programa ou
processo, implementado em hardware ou software, que se comunica com o proces-
29

so correspondente em outro n. As regras que governam a conversao de um nvel
N qualquer so chamadas de protocolo de comunicao de nvel N (SOARES;
LEMOS; COLCHER, 1995). A Figura 4 ilustra o modelo de referncia OSI/ISO.

Figura 4 - Modelo de referncia OSI/ISO. Fonte: Soares, Lemos e Colcher (1995).
O tamanho (distncia de abrangncia) da rede de comunicao repercute, em
geral, nas tecnologias utilizadas (PETERSON; DAVIE, 2003). Segundo o tamanho,
as redes podem ser classificadas em:
WAN (Wide Area Networks). Redes de grande abrangncia, at mesmo
mundial. Cabos, rdio, microondas e satlites so meios fsicos utilizados
para sistemas de comunicao tipicamente ponto-a-ponto
1
(ZHENG;
AKHTAR, 2002).

1
Transmisso feita atravs de conexes estabelecidas entre pares de ns.
30

MAN (Metropolitan Area Networks). Interligam dispositivos com abrangn-
cia metropolitana. As conexes so tanto ponto-a-ponto como broadcasting
2

ou multcasting
3
(ZHENG; AKHTAR, 2002).
LAN (Local Area Networks). Englobam distncias que no costumam ultra-
passar as dimenses do prdio onde a rede instalada. As conexes so
quase sempre multicasting ou broadcasting (ZHENG; AKHTAR, 2002).
PAN (Personal Area Networks) Terminologia nova para redes de curta dis-
tncia usadas para interligar dispositivos como PDAs, laptops, computado-
res, perifricos e sensores dentro de ambientes. Costumam se restringir a
um ambiente como uma sala. Foi popularizada com tecnologia sem fio Blue-
tooth (COOK; DAS, 2005).
SAN (System Area Networks). So redes, usualmente, confinadas em uma
nica sala e usadas para conectar dispositivos de grandes sistemas compu-
tacionais como processadores paralelos e servidores de dados. Por essa l-
tima aplicao, essas redes tambm so referidas como Storage Area Net-
works (PETERSON; DAVIE, 2003).
BAN (Body Area Networks). Redes de comunicao utilizadas para conec-
tar dispositivos atrelados ao corpo humano. Relacionam-se com as tecnolo-
gias wearable devices, nas quais dispositivos computacionais so embarca-
dos na vestimenta e comunicam-se entre si (COOK; DAS, 2005).
A Figura 5 mostra a distncia de abrangncia tpica para cada tipo de rede
descrita acima, de acordo com Cook e Das (2005).

2
Transmisso feita de um n para vrios ns que compartilham o mesmo canal de comunicao.
3
Transmisso feita de um n para todos os ns que compartilham o mesmo canal de comunicao.
31

Figura 5 - Classificao das redes pela distncia de abrangncia.
Adaptado de Cook e Das (2005).
A topologia da rede de comunicao, isto , a maneira como os ns da rede se
conectam fisicamente uns aos outros, um fator importante na escolha da rede para
determinada aplicao. A topologia da rede influncia na estrutura fsica de monta-
gem da rede, na maneira como as mensagens so transmitidas, na robustez do ca-
nal de comunicao, entre outros. So topologias usuais (Figura 6): estrela (todos os
ns se conectam a um n central), anel (cada n se interliga a dois vizinhos, forma-
do ao final um anel), em barra (todos os ns se interligam a um canal de comunica-
o), em rvore (os ns so conectados de forma hierrquica, contendo pais e fi-
lhos, como numa rvore), totalmente conectada (todos os ns esto interligados dois
a dois) e malha (os ns so interligados em forma de matriz).
32

Figura 6 - Topologias usuais de redes de comunicao. Adaptado de Cook e Das (2005).
No contexto da automao do ambiente construdo, e de acordo com o objetivo
da rede de comunicao, distinguem-se trs grupos de redes de comunicao: de
computadores, de campo e de sensores. importante ressaltar que cada grupo na
verdade uma especializao de um grupo mais abrangente. Assim uma rede de
sensores uma especializao de uma rede de campo que uma especializao de
uma rede de computadores que uma especializao de uma rede de comunica-
o.
2.2.1.1. Redes de Computadores
Uma Rede de Computadores uma interconexo de dispositivos (hardware)
programveis de propsito geral (no so otimizadas para uma aplicao particular)
com software relacionado que executa funes de comunicao para diferentes ti-
pos de dados (ZHENG; AKHTAR, 2002; PETERSON; DAVIE, 2003). Entre os proto-
colos de comunicao existentes para redes de computadores, dois se destacam
por serem amplamente utilizados: Ethernet e Internet (TCP/IP).

33

2.2.1.1.1. Ethernet
A Ethernet considerada a tecnologia de rede local (LAN) mais amigvel e
com preo mais acessvel disponvel atualmente (ZHENG; AKHTAR, 2002). um
subconjunto do padro IEEE 802.3 que define servios para as camadas fsica e de
enlace para redes de 10 Mbps (SOARES; LEMOS; COLCHER, 1995). A estrutura
fsica de uma rede Ethernet composta por cabos, transceptores e adaptadores. O
cabeamento mais comumente utilizado o 10BaseT (par-tranado categoria 5 com
segmento mximo de 100 metros). Mltiplos segmentos 10BaseT podem ser interli-
gados por hubs (ver Figura 7) (PETERSON; DAVIE, 2003; SOARES; LEMOS;
COLCHER, 1995).

Figura 7 Rede Ethernet 10BaseT. Fonte: Peterson e Davie (2003).
O protocolo de acesso ao meio nas redes Ethernet da famlia CSMA/CD
(Carrier-Sense Multiple Access with Collision Detection). Cada estao monitora o
canal de comunicao e transmite mensagens somente quando no h transmisso
pelo canal. Caso duas estaes comecem a transmitir ao mesmo tempo, a coliso
detectada e a transmisso abortada, as estaes tentaro retransmitir aps um
tempo aleatrio. Os pacotes Ethernet podem transmitir at 1500 bytes de dados e
utilizam um endereamento nico de seis bytes (PETERSON; DAVIE, 2003;
SOARES; LEMOS; COLCHER, 1995).

34

2.2.1.1.2. Internet (TCP/IP)
Os protocolos TCP (Transmission Control Protocol) e IP (Internet Protocol)
permitem a interligao de diferentes tecnologias de rede. As diferentes redes so
interligadas atravs de roteadores (ver Figura 8). A idia baseia-se na seguinte
constatao: no existe nenhuma tecnologia de rede que atenda aos anseios de
toda a comunidade de usurios (SOARES; LEMOS; COLCHER, 1995). A capacida-
de de interligar diferentes redes de computadores tornou o TCP e o IP blocos prim-
rios da Internet (ZHENG; AKHTAR, 2002).

Figura 8 - Interligao de diferentes tipos de rede (internet).
Hn = estao; Rn = roteador. FDDI = Fiber Distributed Data Distributed.
Fonte: Peterson e Davie. (2003).
O protocolo IP um protocolo de rede, sem conexes, com a funo de trans-
ferir pacotes de dados denominados datagramas de um n origem para um n des-
tino. Os ns so identificados por endereos IP. Tambm oferecido um servio de
fragmentao e remontagem de datagramas longos. Os endereos IP so nmeros
de 32 bits, geralmente, escritos na forma de quatro octetos (em notao decimal),
exemplo 128.6.2.1. Uma parte do endereo identifica a rede, e outra parte uma esta-
35

o dentro da rede. H trs classes de endereo IP (A, B e C) com quantidades dife-
rentes de bits reservados para o endereo da rede e da estao, como ilustra a Fi-
gura 9. H ainda uma classe D para comunicao multcasting e uma classe E reser-
vada para uso futuro. Para comunicao broadcasting, todos os bits do endereo
devem receber valor 1 (um) (SOARES; LEMOS; COLCHER, 1995; ZHENG;
AKHTAR, 2002).

Figura 9 - Endereos IP: (a) classe A; (b) classe B; (c) classe C.
Fonte: Peterson e Davie (2003)
O protocolo TCP um protocolo de transporte, orientado a conexo que forne-
ce um servio confivel de transferncia de dados fim a fim, utilizando como base o
protocolo IP. Utiliza-se o conceito de porta associado a cada processo TCP em uma
estao. A concatenao de um endereo IP e uma porta TCP definida como so-
quete (socket). Uma conexo identificada pelo par de soquetes de suas extremi-
dades.
2.2.1.2. Redes de Campo
Uma Rede de Campo um sistema de comunicao em tempo real que conec-
ta dispositivos de campo como sensores, atuadores e controladores (THOMESSE,
1999). Utilizam, em geral, a topologia em barra (ver Figura 10) e distribuem a tarefa
36

de controle entre vrios ns da rede. Por esta razo so tambm denominadas Re-
des de Controle (SCHICKHUBER; MCCARTHY, 1997) ou Sistemas de Controle Dis-
tribudo (MAHALIK et al., 2006). Como a tarefa de controle distribuda entre os v-
rios ns cooperantes, a possibilidade de falha geral dos sistemas de controle distri-
budo se torna mais remota quando comparado aos sistemas de controle centraliza-
do (MAHALIK; LEE, 2003).

Figura 10 - Rede de campo (rede de controle): topologia em barra.
Adaptado de Mahalik e Lee (2003).
Algumas tecnologias de redes de campo so consagradas para aplicaes de
automao do ambiente construdo, entre elas: Lonworks, EIB (European Instalation
Bus), BACNet
4
(Building Automation and Control Networks) e X-10
5
.
2.2.1.3. Redes de Sensores
Uma Rede de Sensores uma rede especializada na aquisio e na distribui-
o de dados de sensores (com capacidade de processamento e comunicao) mo-
nitorada e controlada por um centro de gerenciamento (COOK; DAS, 2005;
AKYILDIZ et al., 2002). Algumas redes de sensores comerciais e acadmicas so
utilizadas em problemas na rea de automao do ambiente construdo. A Figura 11

4
Bacnet no propriamente uma rede de campo, mas uma especificao de camada de aplicao para redes
de campo.
5
X-10 uma tecnologia para comunicao pela rede eltrica da dcada de 1970. extremamente limitada em
comparao com as outras.
37

ilustra ns de algumas dessas redes de sensores e seus respectivos desenvolvedo-
res. O Quadro 1 mostra a evoluo das redes de sensores.

Quadro 1 - Evoluo das redes de sensores. Adaptado de Chong e Kumar (2003).

Figura 11 - Exemplos de ns de redes de sensores comerciais e acadmicas.
Fonte: Tibiri (2007).
38

2.2.2. Middleware
Middleware um conceito atrelado idia de software de conectividade que
associa aplicaes por meio de mecanismos de comunicao, criando transparn-
cia
6
, escalabilidade
7
e interoperabilidade
8
. Oferece servios que tornam transparente
a comunicao entre aplicativos, inclusive situados em diferentes computadores. Em
geral, uma camada de software situada entre o sistema operacional e os aplicati-
vos que se utilizam do middleware (COOK; DAS, 2005). Entre os formatos de mid-
dleware disponveis, destacam-se dois por sua ampla utilizao: os orientados a ob-
jetos e os bancos de dados.
2.2.2.1. Orientao a Objetos
No enfoque orientado a objetos, os tomos do processo de computao so os
objetos. Os objetos trocam mensagens entre si ativando os mtodos uns dos outros.
Cada objeto possui atributos que representam seu estado e so modificados por a-
es realizadas atravs dos mtodos. Objetos que compartilham a mesma interface
(mesmos atributos e mtodos) so agrupados em classes. O sistema computacional
final resultado da combinao e interao dos vrios objetos que o compe
(COLEMAN et al., 1996). A Figura 12 ilustra um modelo computacional orientado a
objetos.
Middleware orientado a objetos ou ORB (Object-Request Brokers) estende o
paradigma orientado a objetos s tecnologias de middleware. Esses sistemas permi-
tem o desenvolvimento de aplicativos orientados a objetos distribudos, isto , obje-
tos pertencentes a diferentes processos e em diferentes computadores comunicam-

6
Qualidade de tornar um sistema computacional mais amigvel, poupando o usurio de detalhes tcnicos.
7
Facilidade de expanso.
8
Capacidade de operar em conjunto.
39

se de forma transparente (como se pertencessem ao mesmo processo na mesma
mquina). O ORB responsvel pela comunicao entre os objetos. So exemplos
de ORB: COM/DCOM
9
, Java RMI
10
da Sun e CORBA da OMG (COOK; DAS, 2005).

Figura 12 - Exemplo de modelo computacional orientado a objetos.
Fonte: Coleman et al. (1996).
2.2.2.1.1. CORBA
CORBA (Common Object Request Broker Architecture) um middleware pa-
dronizado pelo OMG (Object Management Group) com o objetivo produzir uma infra-
estrutura completa para computao distribuda, reunindo duas tecnologias: a orien-
tao a objetos (OO) e a chamada de procedimento remota
11
(RPC Remote Pro-
cedure Call). Essa associao permite que objetos distribudos em diferentes com-
putadores possam se comunicar de forma transparente, como se estivessem na
mesma mquina. Operaes remotas so agrupadas em interfaces cujas instncias

9
DCOM (Distributed Component Object Model) uma tecnologia de middleware da Microsoft para comunica-
o entre objetos em sistemas distribudos, por meio de redes de computadores de abrangncia local at
mundial. uma extenso do COM (Component Object Model), tecnologia que permite que componentes de
software (objetos) se comuniquem (COOK; DAS, 2005).
10
Java RMI (Remote Method Invocation) um middleware que permite a comunicao entre objetos progra-
mados na linguagem Java em diferentes computadores com mquinas virtuais Java (COOK; DAS, 2005).
11
Tecnologia que permite a chamada de funes remotas de forma transparente, como se a chamada fosse
local.
40

so os objetos CORBA (BOLTON, 2002; BROSE; VOGEL; DUDDY, 2001). A Figura
13 ilustra a invocao de operaes em objetos CORBA.

Figura 13 Invocao de operaes em objetos CORBA. Adaptado de Bolton (2002).
H uma separao clara entre a implementao dos objetos CORBA e suas in-
terfaces que so definidas atravs de uma Linguagem para Definio de Interface
(IDL Interface Definition Language). Um compilador IDL mapeia a interface IDL
para uma linguagem de programao como Java, C, C++, COBOL, Ada, Smaltak ou
Lisp, na qual a implementao ser escrita (BOLTON, 2002).
Toda comunicao entre objetos CORBA transcorre mediante um ORB que
age como um canal de comunicao entre objetos que podem estar locados em
qualquer computador de uma rede, ser implementados em diferentes linguagens de
programao e ser executados em diferentes plataformas de sistema operacional e
de hardware. Vrios fabricantes disponibilizam ORBs para CORBA. Um protocolo,
IIOP (Internet Inter-ORB Protocol), define a comunicao entre diferentes ORBs so-
bre a camada de transporte TCP/IP (BROSE; VOGEL; DUDDY, 2001).
2.2.2.2. Banco de Dados
Bancos de dados so colees de dados relacionados. Permitem o armazena-
mento e a consulta de informaes atravs de uma linguagem padro, SQL (Structu-
red Query Language). Interfaces padres (API Application Programming Interface),
41

como ODBC (Open DataBase Connectivity) e JDBC (Java DataBase Connectivity),
permitem a conexo entre aplicativos e bancos de dados, tornando os bancos de
dados canais de comunicao entre diversos aplicativos (COOK; DAS, 2005;
ELMASRI; NAVATHE, 2005).
Um sistema de gerenciamento de banco de dados (SGBD) um conjunto de
programas que permitem aos usurios criar e manter banco de dados. Entre os
SGBD, o MySQL se destaca por ser um software de licena livre, portvel e compa-
tvel com diversas linguagens de programao que utiliza a linguagem SQL como
interface. Sua interface permite manipular dados atravs de funes como de recu-
perao de dados especficos, criao e atualizao de tabelas, entre outras. O
compartilhamento permite aos mltiplos usurios e programas acessar, de forma
concorrente, o banco de dados (ELMASRI; NAVATHE, 2005).
42

3. Automao do Ambiente Construdo
Este captulo descreve, atravs de trs estudos bibliogrficos, exemplos de ar-
quiteturas de software relacionadas a sistemas de Automao do Ambiente Constru-
do. Estes trs projetos abrangem o tema de forma geral, sistmica e integrada, pois
relatam aspectos de comunicao, de controle e de software. Os dois primeiros es-
to relacionados a grupos de pesquisa em Computao Pervasiva e tem como pon-
tos fortes o reconhecimento de contexto e a arquitetura de software. O ltimo est
relacionado a um grupo de pesquisa em Automao do Ambiente Construdo, resu-
me como o assunto Automao do Ambiente Construdo tem sido abordado pelos
pesquisadores da rea e como esses sistemas tm sido construdos. Em cada um
dos trabalhos, cinco aspectos de cada projeto so abordados:
Reconhecimento de Contexto. Um ponto importante na Automao do
Ambiente Construdo a capacidade do sistema em reconhecer contextos.
Este item aborda algoritmos para reconhecimento de contexto e contextos
reconhecidos em cada projeto.
Aes de Controle. Os sistemas de automao tm como base malhas de
controle que objetivam fazer com que o ponto de operao de um sistema fi-
que num patamar determinado (setpoint). Este item descreve as malhas de
controle de cada projeto.
Arquitetura Fsica. Um sistema de Automao do Ambiente Construdo
possui elementos fsicos como sensores, atuadores, computadores, redes
de comunicao, entre outros. Este item descreve quais elementos fsicos
compem cada projeto e como se interligam fisicamente.
43

Arquitetura Lgica. Um mesmo problema pode ser resolvido de diversas
formas, isto , usando diferentes formas de organizao lgica. Este item
descreve a concepo lgica de cada projeto.
Arquitetura de Software. A partir da concepo lgica, um problema com-
putacional precisa ser programado. Este item aborda a estrutura de software
utilizada.
3.1. MavHome
Mavhome (Managing and Adaptive Versatile Home) uma casa utilizada para
estudar as caractersticas de Ambientes Inteligentes criados na Universidade do Te-
xas em Arlington. Estes ambientes so definidos como aqueles capazes de adquirir
e aplicar conhecimento sobre o ambiente e seus habitantes, visando a melhorar su-
as experincias no ambiente. A operao do ambiente feita atravs de um ciclo
onde se percebe o estado do ambiente, infere-se a respeito do estado, metas e re-
sultados de possveis aes, e age-se sobre o ambiente mudando seu estado
(COOK; DAS, 2007). O objetivo criar uma casa que atue como um agente racional
com percepo atravs de sensores e aes atravs de atuadores. Procura-se ma-
ximizar o conforto e a produtividade dos habitantes, e minimizar custos de operao
(DAS et al., 2002). A planta baixa da casa pode ser vista na Figura 14.
A predio de mobilidade e de atividades so caractersticas apontadas como
fundamentais na MavHome. O roteamento de mensagens e de informao multim-
dia e a automatizao de aes antes efetuadas de forma manual so feitos a partir
das predies. Tcnicas de aprendizagem de mquina so propostas para predizer
padres de movimentao, tarefas e interaes tpicas com os ambientes. Essas
informaes so posteriormente utilizadas na tomada de deciso (DAS et al.; 2002).
44

Busca-se desenvolver e integrar componentes que tornaro possvel a inteligncia
dos ambientes no futuro (YOUNGBLOOD; HOLDER; COOK, 2005).

Figura 14 Planta baixa da Mavhome. Fonte: Roy et al. (2003).
3.1.1. Reconhecimento de Contexto
Localizao de pessoas e reconhecimento de atividades fazem parte do siste-
ma de reconhecimento de contexto da Mavhome. A movimentao do habitante
considerada meramente um reflexo de padres de aes cotidianas do usurio que
podem ser aprendidos. Divide-se a casa em zonas ou setores, que so representa-
dos por caracteres distintos (ver Figura 15). A partir do monitoramento de movimen-
tao do usurio, modelos de mobilidade so obtidos. Esses modelos so trajetrias
do usurio atravs dos cmodos, representadas por cadeias de caracteres (strings).
Utiliza-se o algoritmo LeZi-Update, baseado no algoritmo de compresso de dados
LZ78 para codificao dos dados em um dicionrio. De acordo com a freqncia de
cada palavra no dicionrio, feita a predio de movimentos. importante ressal-
tar que o sistema proposto somente para o acompanhamento de um usurio por
vez (COOK; DAS, 2007; DAS et al., 2002; ROY et al.; 2003).
45

Figura 15 Planta da MavHome e modelo grfico da disposio
dos setores. Fonte: Das et al. (2002).
O reconhecimento de atividades utiliza o histrico de eventos dos usurios para
predio de atividades e diferentes algoritmos para anlise dos dados. O primeiro
algoritmo, SHIP (Smart Home Inhabitant Prediction), combina a seqncia mais re-
cente de eventos com seqncias histricas. Exemplos de eventos incluem ligar lu-
zes, tocar msica, ligar o irrigador, etc. Para fazer predies, o SHIP procura a se-
qncia histria mais adequada ltima ao do usurio. considerado o tamanho
das seqncias que terminam com a mesma ao e suas freqncias histricas.
Podem-se aplicar fatores de decaimento para diminuir pesos de seqncias muito
antigas, e thresholds de inexatido para a comparao entre seqncias com ligei-
ras diferenas. Acertos da ordem de 53% em mdia e de 80% com as melhores trs
combinaes foram obtidos com dados reais pelo SHIP (COOK et al., 2003; DAS et
al.; 2002).
46

ALZ (Active LeZi) um algoritmo para predio de atividades na MavHome ba-
seado na tcnica de compresso de dados LZ78 e com caractersticas funcionais
semelhantes ao LeZi-Update descrito anteriormente. As interaes usurios-
dispositivos so representadas por caracteres e um conjunto de interaes mode-
lado como uma seqncia de caracteres (COOK et al., 2003; YOUNGBLOOD;
HOLDER; COOK, 2005).
Um terceiro algoritmo, ED Episode Discovery, baseado em tcnicas de data
mining tambm utilizado. Ele objetiva reduzir a quantidade de estados possveis
por meio de um conjunto de episdios centrados em tarefas de habitantes. Procura-
se descobrir grupamentos de interaes estreitamente relacionadas no tempo, os
episdios. A freqncia de ocorrncia, o tamanho e a regularidade dos grupamentos
de interaes so levados em considerao na busca de episdios, sendo estes di-
retamente relacionados a tarefas dos habitantes. So exemplos de episdios detec-
tados na MavHome: Ligar/Desligar Aquecedor, Ligar/Desligar Despertador, Ligar
Luzes do Quarto, Ligar Cafeteira, Ligar Luzes do Banheiro, Ligar Vdeo do Banheiro
e Ligar Chuveiro com freqncias dirias; e Ligar Irrigador com freqncia semanal
(COOK et al., 2003; DAS et al., 2002; YOUNGBLOOD; HOLDER; COOK, 2005).
3.1.2. Aes de Controle
A MavHome possui interfaces padres e remotas para que seus usurio pos-
sam comandar diretamente os atuadores e sistemas de controle simples como o de
um motor de passo para ajustar quatro mini-persianas. Sensores de movimento, u-
midade, temperatura, fumaa e luz so utilizados (YOUNGBLOOD; HOLDER;
COOK, 2005). No entanto, nenhuma ao de controle relacionada diretamente a es-
ses sensores foi descrita nos trabalhos revisados sobre a MavHome. As aes de
47

controle relacionam-se principalmente s aes de atuao ordenadas em funo do
reconhecimento de contexto (COOK et al., 2003; COOK; DAS, 2007; DAS et al.,
2002; ROY et al.,2003; YOUNGBLOOD; HOLDER; COOK, 2005).
3.1.3. Arquitetura Fsica
Sensores de movimento, umidade, temperatura, fumaa e luz, e controladores
de lmpadas, persianas, aquecedores, cafeteira, irrigadores e chuveiros so os ele-
mentos de interface entre o mundo fsico e o sistema de automao da Mavhome.
Os sensores de movimento destacam-se por sua importncia no sistema de rastre-
amento de pessoas. Utilizam tecnologia de infravermelho passivo e um tubo para
sombreamento do campo de viso, que visa a diminuir a rea de cobertura de cada
sensor.
Uma rede Argus, baseada em microcontroladores PIC16F877 interliga os sen-
sores. H um n mestre conectado a um computador atravs da porta serial. At
cem ns escravos podem ser interligados a um mestre, e at sessenta e quatro sen-
sores podem ser conectados a cada n escravo. Mestres para aplicaes especiais
tambm foram desenvolvidos, como um para o controle de quatro mini-persianas.
Dispositivos baseados na tecnologia X-10 so utilizados para acionar lmpadas. H
tambm sensores, atuadores e PDAs (usados como interface com os usurios) que
utilizam a tecnologia Bluetooth para comunicao. Todo processamento feito por
aplicativos instalados em computadores interligados por uma rede local (ROY et al.,
2003; YOUNGBLOOD; HOLDER; COOK, 2005).

48

3.1.4. Arquitetura Lgica
Os componentes fsicos e de software so estruturados em quatro camadas
abstratas na MavHome (COOK et al., 2003; COOK; DAS, 2007; DAS et al., 2002;
YOUNGBLOOD; HOLDER; COOK, 2005), a saber:
Fsica. Monitora o ambiente atravs dos sensores e muda o estado do am-
biente atravs dos atuadores (COOK; DAS, 2007). Contm o hardware es-
palhado pela casa, o que inclui sensores, atuadores, computadores e equi-
pamentos de rede (COOK et al., 2003; DAS et al., 2002; YOUNGBLOOD;
HOLDER; COOK, 2005).
Comunicao. Facilita a comunicao entre componentes de todas as ca-
madas, a mobilidade de processos e o descobrimento de servios. Inclui o
sistema operacional, drivers de dispositivos, interfaces com dispositivos de
baixo nvel e middleware (YOUNGBLOOD; HOLDER; COOK, 2005). tam-
bm a interface de comunicao entre a casa e os usurios (DAS et al.,
2002).
Informao. Colhe, guarda e gera conhecimento til para camada de deci-
so (COOK et al., 2003; DAS et al., 2002). Inclui componentes de predio,
bancos de dados, interfaces para usurios, componentes de data mining,
sintetizador de voz e componentes de reconhecimento (YOUNGBLOOD;
HOLDER; COOK, 2005). Transforma dados em informaes teis, como
modelos de ao, padres, etc. (COOK; DAS, 2007).
Deciso. Seleciona as aes a serem executadas baseando-se nos dados
das outras camadas enviados pela camada de Informao (COOK et al.,
49

2003; DAS et al., 2002). Trabalha a informao, aprende com informaes
armazenadas, toma decises atravs de aes, visando a automatizar o
ambiente, e monitora e desenvolve polticas para manter a segurana dos
usurios (YOUNGBLOOD; HOLDER; COOK, 2005).
A percepo um processo visto de baixo para cima (bottom-up process).
Sensores monitoram o ambiente e, se necessrio, transmitem informao atravs da
camada de Comunicao. Bancos de dados armazenam a informao na camada
de Informao, transformam-na em informao til, atualizam abstraes e predi-
es aprendidas e alertam a camada de Deciso sobre novos dados. A camada de
Deciso seleciona uma ao, verifica sua segurana e relata sua deciso camada
de Informao para armazenamento, e camada de Comunicao para o envio do
comando de ao ao atuador correto. A camada Fsica executa a ao (COOK et al.,
2003; COOK; DAS, 2007; DAS et al., 2002; YOUNGBLOOD; HOLDER; COOK,
2005).
3.1.5. Arquitetura de Software
A programao do sistema de automao da MavHome dividido em seis ca-
madas de software (YOUNGBLOOD; HOLDER; COOK, 2005):
Componentes Fsicos. Consiste de todos os dispositivos reais utilizados
pelo sistema. Inclui interfaces de comunicao via rede eltrica, telas de to-
que, dispositivos de leitura de gestos, cmeras, etc.
Interface de Computador. Contm as interfaces com os dispositivos fsicos.
Inclui interfaces PCI, USB, firewire, drivers de dispositivos, sistema opera-
cional do computador, interfaces de software, servios para acesso aos dis-
50

positivos fsicos, os computadores e a infra-estrutura de rede. So utilizados
computadores PCs com sistema operacional Linux.
Interface Lgica. Cria uma srie de servios atmicos em torno de cada
sensor e atuador do sistema, proxies lgicos. Os proxies para componentes
das redes Argus e X-10 so programados em C++ e utilizam memria com-
partilhada para comunicao local e soquetes para comunicao remota. E-
les mantm o estado atual de cada dispositivo e mecanismos de leitura e
escrita (quando aplicvel). A interligao entre os dispositivos feita atravs
da tecnologia ZeroConf.
Middleware. Sua funo facilitar a comunicao, a mobilidade de proces-
sos e o descobrimento de servios/nomes. Atravs da tecnologia ZeroConf,
os proxies dos dispositivos fsicos nas redes Argus e X-10 so encontrados
pelos demais componentes do sistema. Os componentes de alto nvel po-
dem ser programados em C++ e Java e se comunicam atravs do middlewa-
re CORBA (OmniORB).
Servios. Disponibiliza uma srie de funes de suporte como armazena-
mento de informaes (banco de dados PostgreSQL), gerao de conheci-
mento, agregao de componentes dos nveis inferiores e interfaces para os
usurios atravs de controles remotos, PDAs, pginas de internet, reconhe-
cimento e sntese de voz. Utiliza o middleware para capturar dados nas ca-
madas inferiores e fornecer informaes aos aplicativos.
Aplicativos. Utilizam as demais camadas para desenvolver funes de a-
prendizado e tomada de deciso.
51

3.2. Gator Tech Smart House
A Gator Tech Smart Home (GTSH) uma iniciativa do Laboratrio de Compu-
tao Pervasiva e Mvel da Universidade da Flrida. Trata-se de uma casa-
laboratrio onde so desenvolvidas tecnologias para Espaos Pervasivos Progra-
mveis. Estes espaos se monitoram e monitoram seus usurios continuamente,
interligando o mundo fsico aos sistemas de monitoramento remoto e aos servios
(software) que podem intervir diretamente no funcionamento da GTSH. O objetivo
a criao de uma plataforma para programao destes espaos atravs de aplicati-
vos formados por composio de servios (HELAL et al.; 2005). A Figura 16 mostra
a planta da casa.

Figura 16 Gator Tech Smart House. Fonte: Helal et al. (2005).
52

A plataforma proposta programada em um conjunto de computadores e de
microcontroladores. Sensores, atuadores e outros dispositivos de automao da ca-
sa so acoplados aos microcontroladores. Estes ltimos comunicam entre si e com
os computadores atravs de diferentes redes de comunicao (KING et al., 2006;
HELAL et al., 2005).
O reconhecimento de contexto e a localizao de pessoas e objetos so algu-
mas das aplicaes encontradas na GTSH. H tambm uma srie de dispositivos e
tecnologias que fazem parte da GTSH, como: uma caixa de correio inteligente que
detecta a chegada de correspondncia e notifica o ocupante; uma porta de entrada
inteligente que possui identificao por RFID (Radio Frequency Identification) usado
para o acesso de pessoas autorizadas, um microfone, uma cmera, um display de
texto, um sistema automtico para abertura de porta, uma fechadura eltrica e alto-
falantes para comunicao entre os ocupantes e os visitantes; uma cama inteligente
que permite o monitoramento dos padres de sono dos ocupantes; lavanderia inteli-
gente que utiliza tecnologia RFID para identificao de roupas e avisa os residentes
quando e como separar as roupas para lavar; entre outros (HELAL et al., 2005).
O monitoramento de variveis dos ambientes e a localizao, a movimentao
e a orientao de pessoas compem o sistema de reconhecimento de contexto da
GTSH. A localizao, a movimentao e a orientao de pessoas so feitas por
meio de um sistema ultra-snico. Emissores so colocados nos ombros das pessoas
e receptores so instalados nos ambientes. Atravs de tcnicas de triangulao so
detectadas a localizao, o movimento e a orientao da pessoa portadora dos e-
missores (HELAL et al., 2005). Um segundo sistema, menos intrusivo, para detectar
53

localizao e movimentao atravs de sensores de presso instalados abaixo do
piso tambm foi proposto. H um sensor de presso para cada placa de piso. Assim,
faz-se um mapeamento entre cada placa e sua posio relativa a uma origem
(Figura 17). O movimento e a localizao so percebidos atravs das mudanas de
presso causadas nos diferentes blocos de piso (KADDOURA; KING; HELAL, 2005;
HELAL et al., 2005).

Figura 17 Mapeamento do piso inteligente e placa de piso.
Adaptado de Helal et al. (2005).
A GTSH transforma dados brutos, como valores de temperatura, umidade e
iluminncia, em estados como quente, frio, mido, claro, escuro, etc. que so classi-
ficados em estados desejveis, transitrios e no-permitidos. A partir destes, so
construdos grafos de contexto contendo todos os possveis estados de interesse. O
54

objetivo promover aes que coloquem o ambiente sempre em estados desejveis
e que evitem os estados no-permitidos (HELAL et al., 2005; HELAL et al., 2007).
Nenhuma descrio especfica de malhas de controle existentes na GTSH foi
encontrada nos trabalhos revisados. As aes de controle baseiam-se em mapea-
mentos entre estados e aes. Cada atuador associado a um efeito intencional.
Por exemplo: o aquecedor tem como efeito intencional aquecer. Se o ambiente est
frio, um gerenciador de contextos liga o aquecedor e verifica se o ambiente no en-
trar em estados no-permitidos (HELAL et al., 2005; HELAL et al., 2007).
Sensores, atuadores, dispositivos domsticos inteligentes (descritos anterior-
mente), microcontroladores, computadores e redes de comunicao so componen-
tes fsicos da GTSH. Uma plataforma de comunicao e programao, Atlas, foi de-
senvolvida para interconectar os diversos componentes fsicos e lgicos na GTSH.
Sensores e atuadores so conectados a microcontroladores Atmel ATmega128L.
Diversos tipos de redes de comunicao so utilizados para interligar microcontrola-
dores e computadores: 10BaseT Ethernet, 802.11b WiFi, Bluetooth, USB e ZigBee
(KING et al., 2006).

55

O sistema de automao da GTSH dividido em seis camadas lgicas, ilustra-
das na Figura 18, com particularidades funcionais e estruturais (HELAL et al., 2005):
Fsica. So os componentes fsicos existentes na casa: sensores, atuadores
e dispositivos inteligentes. Envia e recebe sinais representando grandezas
fsicas como temperatura, umidade, ligar, desligar, porcentagem de atuao,
etc..
Plataforma de Sensores. Representa os sensores/atuadores da camada f-
sica atravs de servios (software). Desacopla particularidades dos compo-
nentes fsicos das camadas superiores.
Servio. Conjunto de servios (software) com funcionalidades do sistema.
Permite a criao de novas funcionalidades atravs da composio de servi-
os.
Conhecimento. Contm a ontologia de servios, aplicativos e dispositivos
que compem o sistema.
Gerncia de contextos. Conjunto de contextos de interesse representados
por grafos que interligam sensores e estados. Um contexto pode definir ou
restringir a ativao de servios.
Aplicao. Consiste de um gerente de aplicaes que ativa e desativa ser-
vios e um ambiente de desenvolvimento integrado (IDE Inegrated Deve-
lopment Environment) grfico para o gerenciamento das camadas anterio-
res.
56

Figura 18 Arquitetura lgica da GTSH. Fonte: Helal et al. (2005).
3.2.5. Arquitetura Software
A arquitetura de software orientada a servios (SOA Service-Oriented Ar-
chitecture), baseada na plataforma OSGi e associada arquitetura lgica descrita na
seo 0. Os componentes de software, chamados de OSGi bundles (ou simples-
mente bundles) na plataforma OSGi, podem dinamicamente descobrir uns aos ou-
tros e colaborarem. Os componentes fsicos (Plataforma de Sensores), os servios e
as aplicaes so representados por bundles (ver seo 0 e Figura 18) (HELAL et
al., 2007; KING et al., 2006).
H uma srie de aplicaes utilizadas para administrar a plataforma de softwa-
re utilizada na GTSH como: Gerenciador de Rede, Gerenciador de Configurao,
Bunddle Repository, Gerenciador de Contextos e Monitor de Segurana e Mdulos
de Comunicao (HELAL et al., 2007).
57

3.3. EDIFICIO sistema de controle integrado
e adaptvel s vontades dos usurios
EDIFICIO (Efficient Design Incorporating Fundamental Improvements for Con-
trol and Integrated Optimization) um projeto de pesquisa com objetivo de desen-
volver um sistema integrado de controle para aquecimento, sombreamento e ilumi-
nao artificial visando o desempenho energtico e o conforto dos usurios. Um
controlador foi proposto para escritrios do LESO-PB (Solar Energy and Building
Physics Laboratory) da Escola Politcnica Federal de Lausanne, na Sua (Figura
19). A descrio apresentada nesta seo se baseia no trabalho de doutorado de
Antoine Guillemin (GUILLEMIN, 2003).
Guillemin e Morel (2001) propem um controlador para regular a abertura de
um dispositivo de sombreamento externo, a iluminao artificial e o sistema de a-
quecimento em ambientes do tipo escritrio para um nico usurio visando a melho-
rar a eficincia energtica. Valores padres de conforto para temperatura e ilumi-
nncia so adotados como setpoints iniciais do sistema. A posio do dispositivo de
sombreamento tambm controlada de modo a no causar ofuscamento. Algorit-
mos baseados em lgica difusa, redes neurais artificiais e algoritmos genticos fa-
zem predies e controlam o ambiente de forma eficiente (energeticamente) e, ao
mesmo tempo, satisfazem as vontades do usurio de cada escritrio investigado
(GUILLEMIN, 2003).
58

Figura 19 Escritrio tpico do LESO-PB.
Fonte: Guillemin (2003).
O controlador desenvolvido trabalha com dois contextos principais detectados
atravs de sensores de movimento: ausncia de usurio e presena de usurio. Es-
ses contextos so utilizados para mudar os modos de operar do controlador entre
modo de otimizao energtica e modo de otimizao visual. Um terceiro contexto,
chamado de sleep mode, permite o ajuste dos setpoints para tarefas no corriquei-
ras (ex. um apresentao de slides), desativando o controle automtico e tornando
manual a operao do sistema at que seja detectada ausncia novamente
(GUILLEMIN, 2003; GUILLEMIN; MOREL, 2001).
Quando o usurio do escritrio est presente (modo de otimizao visual), al-
goritmos de aprendizagem adaptam os pontos de funcionamento do sistema (setpo-
ints) aos desejos reportados pelo usurio atravs de interfaces de comandos insta-
ladas em cada escritrio. H trs algoritmos especficos, que procuram equilibrar a
vontade do usurio e a eficincia energtica, para adaptao de cada um dos trs
59

parmetros do sistema (temperatura interna, iluminncia interna e posio do dispo-
sitivo de sombreamento) aos desejos do usurio, diminuindo, desse modo, as possi-
bilidades de rejeio ao sistema (GUILLEMIN, 2003; GUILLEMIN; MOLTENI, 2002).
As aes de controle visam, de forma integrada, garantir o setpoint de tempera-
tura e iluminncia do ambiente, aproveitando ao mximo a iluminao e o calor pro-
venientes dos raios solares e tomando o cuidado de evitar o ofuscamento. So vari-
veis controladas a intensidade da iluminao artificial e do sistema de aquecimento,
e a abertura do dispositivo de sombreamento instalado exteriormente janela
(GUILLEMIN, 2003).
So monitoradas duas variveis externas ao prdio dos escritrios: a irradin-
cia global horizontal e a temperatura, a partir das quais, e de acordo com a data, a
hora e a posio de cada escritrio so calculadas as seguintes variveis: estao
(mdia de temperatura das ltimas 24 horas), azimute solar, altitude solar, iluminn-
cia vertical direta, iluminncia global vertical e irradincia global vertical. A iluminn-
cia interna, utilizada para o controle da iluminao artificial, calculada com base na
iluminncia vertical externa e a abertura do dispositivo de sombreamento. A medio
de iluminncia na rea de trabalho utilizada para calibrar o modelo que relaciona a
iluminncia vertical externa com a iluminncia interna. Detalhes sobre o tratamento
matemtico dessas variveis podem ser encontrados em Guillemin (GUILLEMIN,
2003). A Figura 20 ilustra o esquema do pr-processamento de dados.
Trs controladores trabalham em conjunto: um para dispositivo de sombrea-
mento, um para iluminao artificial e um para o sistema de aquecimento. Cabe res-
60

saltar que o segundo opera como suplemento do primeiro em momentos onde a luz
solar insuficiente.

Figura 20 Pr-processamento dos dados. Fonte: Guillemin (2003).
O controlador do dispositivo de sombreamento difuso e possui dois modos de
operao: ausncia de usurio e presena de usurio. No primeiro modo (ausncia
de usurio), o controlador regula a abertura do dispositivo de sombreamento e tem
como variveis de entrada: a estao (mdia de temperatura externa das ltimas 24
horas), a irradincia solar global horizontal e a diferena entre as temperaturas inter-
na e externa (GUILLEMIN, 2003).
No segundo modo (presena de usurio) so utilizados dois grupos de regras
para controlar o dispositivo de sombreamento. O primeiro grupo determina a abertu-
ra mxima do dispositivo de sombreamento para evitar o ofuscamento, e tem como
variveis de entrada: a iluminncia vertical direta, a altitude solar e o azimute solar.
O segundo determina a abertura do dispositivo de sombreamento para o aproveita-
mento da luz solar, baseando-se na iluminncia global vertical e na estao (mdia
de temperatura externa das ltimas 24 horas). O mnimo entre os dois valores de
61

abertura do dispositivo de sombreamento ser o valor final do controlador. Posteri-
ormente, um filtro de movimento evita que o novo valor de abertura seja propagado
ao atuador caso a variao seja pequena, ou em um intervalo curto de tempo em
relao ltima movimentao (GUILLEMIN, 2003).

Figura 21 Diagrama do controlador de posio do dispositivo de sombreamento
quando h presena de usurios. Fonte: Guillemin (2003).
O controlador do sistema de aquecimento controla a frao de potncia do sis-
tema de aquecimento a partir das seguintes variveis de entrada: setpoint especifi-
cado, temperatura interna, irradincia solar mdia prevista para as prximas seis
horas e mxima irradincia teoricamente possvel para as prximas seis horas. A
previso de irradincia solar mdia prevista para as prximas seis horas feita por
uma rede neural artificial que recebe como dados de entrada as irradincias corren-
te, de uma hora atrs, de dezoito horas atrs e a mxima j computada para as pr-
ximas seis horas. O controlador assume uma previso de ocupao das 8h s 18h
horas durante os dias da semana (GUILLEMIN, 2003).
O sistema de controle utilizado no LESO-PB utiliza trs computadores interliga-
dos por uma rede Ethernet: um executa os algoritmos de controle, um faz interface
com uma rede EIB (European Installation Bus), onde esto ligados sensores e atua-
62

dores, e um ltimo faz a aquisio de dados atravs de um sistema legado, VNR,
existente no prdio desde a dcada de 1980 (ver Figura 22).

Figura 22 Arquitetura do sistema de controle do LESO-PB. Fonte: Guillemin (2003).
Os atuadores de cada escritrio (iluminao artificial, sistema de aquecimento
e dispositivo de sombreamento) esto conectados rede EIB (ver Figura 23). Os
sensores esto interligados rede EIB ou ao sistema de aquisio de dados VNR,
alguns so comuns a todo o prdio (globais) e outros so individuais por escritrio.
O Quadro 2 descreve os sensores instalados no LESO-PB, seu tipo e a qual rede de
comunicao (EIB/VNR) o sensor est conectado (GUILLEMIN, 2003).
Sensor (grandeza) Tipo de sensor EIB / VNR
I
n
d
i
v
i
d
u
a
l

(
e
s
c
r
i
t
r
i
o
)

Temperatura do ar (controle) PT-100 EIB
Temperatura do ar (monitoramento) PT-100 VNR
Presena (movimento) Infravermelho passivo EIB
Iluminncia na rea de trabalho Luxmetro EIB
Abertura da janela (0/1) Magntico EIB
G
l
o
b
a
l

(
p
r
d
i
o
)

Temperatura do ar externa PT-100 VNR
Irradincia horizontal global Piranmetro VNR
Velocidade do vento Anemmetro VNR
Direo do vento Biruta VNR
Quadro 2 Sensores disponveis no LESO-PB. Fonte: Guillemin (2003).
63

Figura 23 Rede EIB e atuadores e sensores. Fonte: Guillemin (2003).
H dois mdulos de interface para ajuste dos parmetros do sistema em cada
escritrio. Um est relacionado iluminao artificial e ao sistema de aquecimento.
O outro est relacionado ao ajuste da posio do dispositivo de sombreamento ex-
terno.
O sistema de automao no LESO-PB dividido em trs nveis de controle (ver
Figura 24). O primeiro nvel transforma grandezas fsicas em sinais eltricos e vice-
versa. Possui a malha de controle primria do sistema. totalmente dependente do
ambiente onde o sistema instalado. O segundo nvel possui o conhecimento, na
forma de regras difusas, que gera os parmetros de controle (setpoints) para o pri-
meiro nvel. O terceiro nvel responsvel pela adaptao de longa durao do se-
gundo nvel e leva em considerao mudanas nas caractersticas do prdio, dos
dispositivos, dos desejos dos usurios e da eficincia energtica. Os dois ltimos
nveis so facilmente ajustveis para diferentes situaes (GUILLEMIN, 2003).
64

Figura 24 Arquitetura de controle de trs nveis do LESO-PB. Fonte: Guillemin (2003).
3.3.5. Arquitetura Software
Dois computadores so responsveis pela aquisio de dados da rede. O pri-
meiro est conectado ao sistema legado VNR (PC-VNR). A cada dois segundos so
lidos dados gerados no sistema VNR e gravados em um arquivo texto. Este arquivo
usado como interface para comunicao de dados. O segundo computador est
conectado rede EIB atravs da sua porta serial. Um servidor EIB encarregado de
ler e escrever dados na rede EIB e disponibiliz-los atravs de protocolos tipo RMI
12

(GUILLEMIN, 2003).
Um terceiro computador responsvel pela execuo dos algoritmos de con-
trole e utiliza para tal tarefa quatro aplicativos principais (GUILLEMIN, 2003):
MATLAB. a parte central do sistema. Comunica-se com os outros mdu-
los do sistema via protocolo DDE, calcula as sadas dos controladores e
propaga seus valores ao servidor EIB via protocolo DDE. Tambm o soft-
ware responsvel pelos algoritmos de adaptao.
EIB Java Server. Comunica-se com o servidor EIB no PC-EIB via RMI. For-
nece dados da rede EIB atravs do protocolo DDE. Dados podem ser requi-

12
Remote Method Invocation. Chamada de mtodo remota.
65

sitados pelo cliente (cold link) ou propagados automaticamente a cada atua-
lizao de dados (hot link).
VNR Datalog Server. L a cada segundo o arquivo texto gerado no PC-
VNR. Disponibiliza os dados via protocolo DDE.
EDITIME. Servidor DDE responsvel por gerar base tempo (data e horrio)
do sistema. Envia a cada minuto o horrio e a data correntes.
3.4. Consideraes finais
Os trs trabalhos descritos resumem, de forma geral, as solues encontradas
na bibliografia para arquiteturas de software aplicadas a sistemas computacionais
em ambientes construdos. consenso a necessidade de uma camada fsica res-
ponsvel pela comunicao com dispositivos fsicos. O processamento dos dados
organizado de modo particular em cada soluo, o que implica em diferentes abor-
dagens de programao.
A arquitetura de software proposta para a Mavhome baseia-se em um modelo
de fluxo de dados, no qual a comunicao com os dispositivos fsicos ocorre atravs
de um processo visto de baixo para cima (bottom-up process). Informaes prove-
nientes de dispositivos so processadas atravs de camadas com diferentes fun-
es: comunicao, tratamento de informao e deciso. No h uma separao
clara de partes responsveis por tarefas como reconhecimento de contexto e/ou e-
xecuo de algoritmos de controle. Nenhum tipo de abstrao descrito, diferente-
mente do que ocorre na Gator Tech Smart House. Nesta ltima, abstraes como a
representao de dispositivos fsicos e de funcionalidades em forma de servios, e a
66

representao de contextos atravs de grafos interligando sensores e estados, ori-
entam o desenvolvimento de aplicativos.
A Gator Tech Smart House apresenta uma arquitetura de software com cama-
das especficas para lidar com os diferentes aspectos de um software pervasivo. Os
aplicativos so construdos a partir de um conjunto de mdulos que so abstraes
de diferentes aspectos sistema. Contextos so programados atravs de grafos em
uma camada especfica, as funcionalidades do sistema atravs servios em outra
camada, a ontologia do sistema em uma camada de conhecimento, e os dispositivos
fsicos so associados aos servios atravs de uma plataforma de sensores. As in-
formaes provenientes dos dispositivos fsicos so representadas por servios b-
sicos que interagem com outros servios responsveis por processar as informa-
es. Estes ltimos interagem com as camadas de contexto, de conhecimento e de
aplicao, executando funcionalidades programadas nestas camadas.
O ltimo trabalho, EDIFICIO, um exemplo tpico de sistema de automao do
ambiente construdo. Como em outros trabalhos da rea de automao do ambiente
construdo, no se observa preocupao com a estruturao do software usado para
automao. Em comum, esses aplicativos se comunicam com dispositivos fsicos e
processam a informao utilizando um software mais conveniente ao programador.
No raro encontrar solues nas quais a comunicao entre aplicativos ocorre a-
travs da leitura e da gravao de dados em um arquivo texto. Essa falta de preocu-
pao com a estruturao do software dificulta a expanso, a reutilizao e a manu-
teno desses sistemas. Em geral, essas solues so restritas ao ambiente de la-
boratrio e a problemas especficos.
67

4. Uma Arquitetura de Software Neuro
Reativa para Sistemas de Automao
do Ambiente Construdo
Este captulo prope e descreve uma arquitetura de software para Automao
do Ambiente Construdo baseada em unidade funcionais bsicas chamadas neur-
nios e glndulas. A primeira parte coloca os requisitos necessrios a um sistema de
Automao do Ambiente Construdo. Em seguida descrita uma proposta de Arqui-
tetura de Software para Automao do Ambiente Construdo. Por fim, so feitas
consideraes sobre a arquitetura proposta e os requisitos do sistema.
4.1. Requisitos
Nesta seo so identificadas particularidades dos ambientes construdos e
trs requisitos principais que uma arquitetura de software para automao do ambi-
ente construdo deve atender: modularidade, flexibilidade e capacidade de integra-
o das partes. O objetivo uma arquitetura de software que torne fcil o desenvol-
vimento, a manuteno e a expanso de sistemas de Automao do Ambiente
Construdo.
4.1.1. Particularidades dos Ambientes Construdos
Um sistema de automao do ambiente construdo um espao fsico, onde
um sistema computacional interage com trs entidades relevantes: usurios, senso-
res e atuadores (JANSEN et al., 2005). Os usurios interagem com o ambiente bus-
cando satisfazer suas necessidades e desejos. Os sensores capturam informaes
sobre o ambiente. Os atuadores agem sobre o ambiente, modificando-o.
68

O ambiente construdo uma entidade dinmica sujeito a variaes relaciona-
das a diversas variveis. Cabe ao projetista do sistema de automao determinar
quais variveis, contextos e comportamentos so relevantes ao sistema projetado.
Os contextos so as informaes, em geral, colhidas pelos sensores que caracteri-
zam a situao do ambiente ou da entidade em questo (DEY, 2001). Os compor-
tamentos so conjuntos de aes executadas, em geral, pelos atuadores visando a
manter o ambiente em um estado desejado (HAGRAS et al., 2003; MURPHY, 2000).
Tradicionalmente, os ambientes construdos so divididos em ambientes meno-
res, como uma casa que dividida em quartos, banheiros, sala e cozinha, onde so
desenvolvidas diferentes atividades ou tarefas (RUTISHAUSER; SCHFER, 2002).
natural que a granularidade de um sistema computacional para automao do
ambiente construdo seja baseada nessas unidades onde so desenvolvidas fun-
es especficas (HAGRAS et al., 2003). Desse modo, pode-se tratar cada uma
dessas unidades como uma entidade autnoma. Essas, por sua vez, podem se
combinar formando unidades maiores e mais complexas. possvel, assim, construir
o sistema de automao de uma casa, por exemplo, tratando-a como um conjunto
de unidades autnomas menores como quartos, banheiros, sala e cozinha. Estas
ltimas ainda podem ser dividas em partes menores como, por exemplo, a pia da
cozinha onde tarefas especficas so desenvolvidas. Cada uma dessas unidades
(gro) possui setpoints, contextos e comportamentos especficos.
4.1.2. Modularidade
A modularidade o nico atributo de software que permite que um programa
seja intelectualmente administrvel (PRESSMAN, 1995). Uma caracterstica interes-
sante, descoberta por meio da experimentao relativa soluo de problemas hu-
69

manos, que a complexidade para soluo de um problema que seja combinao
de outros problemas maior que a soma das complexidades individuais para solu-
o de cada problema combinado (PRESSMAN, 1995), isto ,

onde C(p) uma funo que define a complexidade de um problema p. Vale ressal-
tar que o aumento indiscriminado do nmero de mdulos pode gerar um novo pro-
blema associado ao gerenciamento dos mdulos (PRESSMAN, 1995).
Em aplicaes de automao do ambiente construdo, um controlador monolti-
co torna difcil a reconfigurao dinmica do ambiente ou a utilizao de partes do
sistema independentemente das outras (COEN, 1997). Sistemas modulares facilitam
a manuteno e a realocao quando comparados a sistemas monolticos
(YOUNGBLOOD; HOLDER; COOK, 2005). Vale ainda ressaltar as facilidades de
teste, de expanso e de combinao que arquiteturas modulares possuem
(MURPHY, 2000).
Uma arquitetura de software para Automao do Ambiente Construdo deve ser
modular o suficiente para permitir que mdulos possam ser combinados de maneira
particular em cada aplicao, e para facilitar testes, manutenes e expanses.
4.1.3. Flexibilidade
Flexibilidade a caracterstica relacionada inversamente ao esforo exigido pa-
ra modificao do software, isto , a facilidade de alterao do software para sua
adequao a um novo modo de operao (PRESSMAN, 1995). Dentro do contexto
da Automao do Ambiente Construdo, a flexibilidade de um sistema relaciona-se
facilidade de modificao do software para sua adaptao a uma nova soluo parti-
70

cular. O primeiro passo para tornar uma arquitetura de software flexvel a modula-
ridade. No entanto, a modularidade no garante que os mdulos tero flexibilidade
suficiente para se associarem de maneira particular de acordo com a necessidade
de cada novo problema.
Visando flexibilidade, uma arquitetura de software para Automao do Ambi-
ente Construdo deve definir uma interface de comunicao para os mdulos, facili-
tando combinaes diferentes em cada soluo particular. Cada ambiente constru-
do possui particularidades que o tornam nico, o que implica em solues nicas.
4.1.4. Capacidade de Integrao das Partes
As aplicaes de Automao do Ambiente Construdo podem contemplar v-
rios subsistemas, como iluminao, condicionamento de ar, controle de acesso, in-
cndio e segurana. Guillemin e Morel. (2001) e Kolokotsa et al. (2002) apontam a
importncia de uma abordagem integrada. importante que todas as partes do sis-
tema possam responder de forma cooperativa e coordenada aos diferentes contex-
tos de uma aplicao.
Uma arquitetura de software para Automao do Ambiente Construdo deve
possuir mecanismos que torne possvel a integrao entre as partes, isto , as par-
tes componentes devem responder de forma cooperativa e coordenada aos diferen-
tes contextos da aplicao.
4.2. Proposta
Visando a satisfazer os requisitos expostos anteriormente, proposta aqui,
uma arquitetura de software para Automao do Ambiente Construdo baseada em
unidades bsicas chamadas neurnios e glndulas, e composta por duas camadas
71

de software: camada Reativa e camada Ontolgica. Essas duas camadas possuem
interface com mais duas camadas, Fsica e de Aplicao, formando um modelo de
quatro camadas (ver Figura 25):
Fsica. a interface entre o mundo fsico e o sistema de automao. Senso-
res, atuadores e redes de campo so componentes bsicos desta camada.
Reativa. a camada responsvel por processar toda informao enviada
pelos sensores e reagir comandando os atuadores. Toda ao do sistema
o resultado da reao dos dois elementos constituintes desta camada: os
neurnios e as glndulas.
Ontolgica. a camada que guarda informaes sobre a configurao e a
estrutura da camada Reativa. formada por um conjunto de tabelas inter-
relacionadas contendo os parmetros de configurao da camada Reativa.
de Aplicao. a camada entre o sistema de Automao do Ambiente
Construdo e os aplicativos que o utilizam.
As camadas Fsica e de Aplicao so, respectivamente, camadas de interface
com o mundo fsico e com os aplicativos que se comunicam com as camadas Reati-
va e Ontolgica, ncleo da arquitetura proposta. Conjuntos de neurnios e glndu-
las, na camada Reativa, representam as malhas de controle, os contextos e os com-
portamentos do sistema de automao do ambiente construdo.
72

Figura 25 - Camadas da arquitetura proposta.
4.2.1. Camada Fsica
A camada Fsica engloba sensores, atuadores e toda a infra-estrutura de rede
de campo e hardware necessrios para a leitura de dados dos sensores e para co-
mandar aes no ambiente atravs dos atuadores. Sua funo fazer a interface
entre o mundo fsico e a camada Reativa, onde todo o processamento de controle
feito. A infra-estrutura de rede de computadores tambm compe esta camada
quando computadores interligados em rede so utilizados.
4.2.2. Camada Reativa
A camada Reativa responsvel por toda ao do sistema de automao. Ela
monitora continuamente os sensores e reage comandando os atuadores. Para atin-
gir os requisitos de modularidade, flexibilidade e capacidade de integrao entre as
73

partes, esta camada deve ser formada por elementos modulares e flexveis, e ao
mesmo tempo capazes de se integrarem com os objetivos gerais do sistema. A
questo fundamental : quais tipos de elementos podem ser utilizados para essa
tarefa?
Para solucionar esta questo, buscou-se inspirao em um sistema capaz de
executar tarefas extremamente complexas e integradas: o sistema de controle do
corpo humano. O homem capaz de executar ao mesmo tempo inmeras tarefas de
controle com objetivos diferentes: manter sua temperatura corprea, digerir, ficar
alerta a sons e movimentos, movimentar pernas e braos, dentre outras. Todo con-
trole resultado de associaes de unidades funcionalmente simples, como os neu-
rnios e as glndulas que compem os dois sistemas de controle fundamentais do
ser humano: o sistema nervoso e o sistema endcrino (GUYTON; HALL, 2006).
O sistema nervoso humano responsvel pela execuo de funes sensrio-
motoras e autnomas. Ele possui em torno de 100 bilhes de neurnios (sua clula
fundamental) que processam e se comunicam continuamente e paralelamente
(BRAGA; CARVALHO; LUDERMIR, 2007). A cada minuto milhes de bits de infor-
mao de diferentes nervos e rgos sensoriais so recebidos e processados, resul-
tando em ordens executadas pelo corpo humano (GUYTON; HALL, 2006).
Pode-se dividir o sistema nervoso em trs grandes camadas com caractersti-
cas funcionais especficas: a corda espinhal, o baixo crebro e o alto crebro. A cor-
da espinhal possui vrios centros de controle para controlar movimentos e reflexos
de rgos espalhados por todo o corpo. Os nveis superiores do crebro enviam si-
nais aos centros de controle da corda espinhal para que estes desempenhem suas
funes. O baixo crebro controla funes inconscientes e vitais como a respirao,
74

a presso arterial, entre outras. O alto crebro onde reside a conscincia, o pro-
cesso de pensamento e a memria. Seu funcionamento sempre combinado com
centros de controle dos nveis inferiores (GUYTON; HALL, 2006).
Alm do sistema nervoso, o sistema endcrino desempenha papel importante
nas funes de controle do ser humano. Mltiplas atividades do corpo humano so
coordenadas por diversos tipos de mensageiros qumicos, entre os quais se desta-
cam os hormnios. Esses ltimos so secretados por glndulas na corrente sangu-
nea em resposta a estmulos neurais ou de outros hormnios, e influenciam o fun-
cionamento de clulas em outras partes do corpo. Alguns afetam clulas em todo o
corpo, outros afetam apenas tecidos especficos (GUYTON; HALL, 2006). Boa parte
do comportamento humano resultado dos nveis de hormnio na corrente sangu-
nea.
A camada Reativa inspira-se no funcionamento dessas unidades de controle
fundamentais do corpo humano. Analogamente ao sistema de controle do corpo
humano, neurnios e glndulas artificiais so os elementos bsicos desta camada.
Os neurnios em conjunto formam malhas de controle e associam-se transformando
a informao como, por exemplo, combinando informaes de diferentes sensores
para caracterizar um contexto. As glndulas representam comportamentos e estados
(setpoints) do sistema. Enviam mensagens (secretam hormnios) que alteram o
modo de operar de diversas partes do sistema. A abrangncia de ao de uma
glndula determinada pelo domnio a que ela pertence, isto , somente neurnios
e glndulas pertencentes a este domnio que recebem suas mensagens (horm-
nios).
75

Os neurnios da camada Reativa realizam funes anlogas s exercidas na
corda espinhal e no baixo crebro. So especializadas, possuem caracterstica for-
temente reativa, no possuem conscincia do todo, no possuem qualquer processo
de deciso ou de aprendizagem. As caractersticas no encontradas nos neurnios
aqui propostos podem ser fornecidas por aplicativos desenvolvidos para a camada
de aplicao. Nas prximas sees descrevem-se os elementos fundamentais da
camada Reativa: neurnios, glndulas e domnios.
4.2.2.1. Neurnios
O neurnio formado por um conjunto de entradas contnuas, uma nica sada
contnua, que representa seu estado e um algoritmo que mapeia as entradas e a
sada. Ele representa uma pequena funo do sistema, como o sinal de um sensor,
a transformao de um sinal em outro tipo de sinal, um controlador, um atuador,
uma funo lgica ou uma funo combinatria que combina sinais provenientes de
vrios neurnios. O neurnio tem seu comportamento influenciado pelas mensagens
enviadas (hormnios secretados) pelas glndulas que podem desativ-lo ou ativ-
lo ou ainda deix-lo em um estado de funcionamento intermedirio.
A associao de neurnios feita atravs da interconexo deles. A sada de
um neurnio pode ser conectada s entradas de vrios neurnios. Cada conexo
propaga um valor numrico real (v) e um peso (ou prioridade - w). Os pesos podem
ser utilizados ou desprezados pelo neurnio receptor. Eles ponderam (ou priorizam)
os valores das entradas. Enquanto o valor reflete o estado do neurnio, os pesos
so caractersticas de cada conexo. A Figura 26 ilustra o modelo de neurnio pro-
posto para a camada Reativa.
76

Figura 26 Modelo de neurnio. As entradas possuem valores (ve) e pesos (we) distintos. A
sada propaga o mesmo valor (vs) para diferentes neurnios atravs de
conexes com pesos (ws) distintos. H tambm receptores para as
mensagens enviadas por glndulas (em vermelho).
4.2.2.2. Glndulas
As glndulas so responsveis por enviar mensagens (secretar hormnios)
que representam estados (setpoints) ou comportamentos dos domnios aos quais
elas pertencem, de acordo com o contexto. Cada mensagem (hormnio) possui um
status (s) (ou valor) e um tipo (t). O tipo caracteriza a mensagem, o que permite que
o receptor diferencie mensagens (hormnios) provenientes de diferentes glndulas.
J o status representa o nvel ou valor que determinada mensagem (hormnio) car-
rega. As glndulas so capazes de detectar contextos atravs de suas conexes
com neurnios e atravs do recebimento de mensagens (hormnios) de outras
glndulas. Como os neurnios, as mensagens recebidas (hormnios secretados)
por outras glndulas podem ativar, desativar ou deixar em nvel intermedirio o es-
tado de funcionamento de uma glndula. A Figura 27 ilustra o modelo de glndula
proposto para camada Reativa.

Figura 27 Modelo de glndula. As entradas possuem valores (ve) e pesos (we) distintos. A
sada propaga o mesmo status (S) e tipo (t) para todos os neurnios e as glndulas
pertencentes ao seu domnio. H tambm receptores para as mensagens enviadas
por outras glndulas.
77

4.2.2.3. Domnio
O domnio representa a zona de ao das glndulas pertencentes a ele. uma
entidade abstrata da camada Reativa: no executa nenhum tipo de tarefa. Mas de
fundamental importncia, pois determina para quais entidades uma glndula deve
enviar uma mensagem (secretar hormnio). Os domnios podem se relacionar hie-
rarquicamente: um domnio pode pertencer a outro. Desse modo, as mensagens
enviadas (hormnios secretados) por glndulas de um domnio pai so recebidas
por todas as unidades de domnios filhos.
Um domnio caracterizar, em geral, um espao dentro do ambiente construdo
com comportamentos e estados (setpoints) particulares. As glndulas caracterizaro
os estados e os comportamentos destes domnios. E os neurnios caracterizaro
sensores, atuadores, controladores, etc.
Os domnios desempenham outro papel importante de organizao da camada
Reativa. Eles podem ser utilizados para agrupar neurnios e glndulas pertencentes
a determinado sistema ou que possuam caractersticas comuns, tornando mais fcil
a localizao de grupamentos com funcionalidades especficas.
4.2.3. Camada Ontolgica
A camada Ontolgica descreve em forma de tabelas relacionais os componen-
tes da camada Reativa e suas relaes. Ela guarda todas as informaes de confi-
gurao da camada Reativa, o que engloba quais neurnios, glndulas e domnios
compem o sistema, os parmetros de configurao de neurnios e de glndulas, as
conexes entre neurnios e seus parmetros de configurao.
78

H uma ntima relao entre as camadas Reativa e Ontolgica. Os elementos
bsicos da camada Reativa, neurnios e glndulas, utilizam a camada Ontolgica
para obter os parmetros necessrios para comunicao com outros neurnios e
glndulas, e para sua prpria configurao. Isto desacopla a configurao da pro-
gramao. Programam-se os tipos bsicos ou as classes de neurnios e glndulas,
e todo o resto do sistema torna-se uma especificao de parmetros na camada On-
tolgica.
4.2.4. Camada de Aplicao
A camada de Aplicao oferece aos aplicativos uma interface de comunicao
com as camadas Reativa e Ontolgica. Algoritmos de aprendizagem, de IHM (Inter-
face Homem-Mquina) e programas de computao pervasiva so exemplos de a-
plicativos que podem ser desenvolvidos para a camada de Aplicao.
A arquitetura proposta possui caractersticas reativas, isto , um sistema que
monitora o ambiente e reage aos seus estmulos atravs de unidades fundamentais
chamadas de neurnios e de glndulas. Os neurnios representam informaes de
controle relevantes, enquanto que as glndulas representam estados (setpoints) e
comportamentos esperados. O sistema final o resultado da associao dessas u-
nidades fundamentais simples, ou mdulos bsicos, o que torna o sistema modular.
Os neurnios e as glndulas se associam atravs de conexes que possuem
caractersticas comuns, isto , um neurnio ou uma glndula pode propagar infor-
mao para qualquer outro neurnio ou glndula. Cada neurnio ou glndula recep-
tor interpreta a mensagem recebida segundo os parmetros da conexo. Desse mo-
do um neurnio pode, a qualquer momento, receber novas conexes de novos neu-
79

rnios, criando uma nova conexo (externa ao neurnio), ou pode receber mensa-
gens (hormnios) de novas glndulas criando um receptor para o novo tipo de
mensagem (hormnio, tambm externo ao neurnio). O mesmo vale para as gln-
dulas. Todas essas modificaes de associao entre neurnios e glndulas no
requerem modificao na programao dessas unidades bsicas, o que permite que
os mesmos mdulos bsicos se associem de inmeras maneiras diferentes, tornado
a arquitetura proposta flexvel.
As glndulas propagam mensagens (hormnios) que representam estados e
comportamentos de um domnio. Todas as entidades do domnio recebem essas
mensagens (hormnios), e algumas (aquelas com receptores) reagem mudando
seu ponto ou modo de operao. Dessa forma, estados e comportamentos so
compartilhados entre unidades pertencentes ao mesmo domnio, o que permite que
o sistema final responda a diferentes contextos de forma integrada.
Os domnios permitem agrupar neurnios e glndulas. Eles tambm podem
guardar relaes de hierarquia entre si, isto , um domnio pode pertencer a outro.
Usualmente, um domnio representa um espao fsico com determinada funcionali-
dade ou onde realizada determinada tarefa, o que permite associar ambientes
construdos reais com um conjunto de domnios programados na arquitetura propos-
ta. Uma casa, por exemplo, ser um domnio contendo outros domnios menores da
casa como quartos, banheiros, salas, etc..
A arquitetura proposta trata diretamente de problemas ligados a automao do
Ambiente Construdo. A camada Reativa reage aos estmulos do ambiente, e prati-
camente todas as variveis de controle importantes no sistema so representadas
por neurnios e glndulas nesta camada. A camada Ontolgica guarda os parme-
80

tros de configurao do sistema de forma relacionada e estruturada. Essas caracte-
rsticas (das camadas Reativa e Ontolgica) resultam em um sistema modular e fle-
xvel, e facilitam a programao, a manuteno e a expanso. O desenvolvedor po-
de manter o foco na aplicao, preocupando-se pouco com detalhes de cdigo. Da-
dos publicados na camada Reativa e parmetros de configurao guardados na ca-
mada Ontolgica podem ser acessados facilmente. Os parmetros de configurao
podem ainda ser modificados, assim como novos neurnios e glndulas tambm
podem ser instanciados por aplicativos da camada de Aplicao, o que facilita a pro-
gramao de aplicativos pervasivos e de aprendizado na camada de Aplicao.
As informaes provenientes da camada Fsica so processadas na camada
Reativa de acordo com configurao da camada Ontolgica. A forma como neur-
nios e glndulas so associados determina a resposta do sistema aos estmulos do
ambiente. Malhas de controle so programadas como associao de neurnios que
representam elementos de um sistema controle como sensores, controladores, atu-
adores ou partes de controladores mais complexos, como funes de pertinncia ou
regras difusas em um controlador difuso. Neurnios tambm so associados para
formar grafos para o reconhecimento de contexto. Comportamentos desejados para
o sistema so representados por glndulas que liberam hormnios. Estes ltimos
influenciam o comportamento particular de cada neurnio ou glndula, segundo con-
figurao dos mesmos.
81

5. Implementao da
Arquitetura Proposta
Para tornar a arquitetura proposta factvel apresentada aqui uma implemen-
tao das camadas Ontolgica e Reativa desenvolvida na linguagem de programa-
o Java, baseada no middleware CORBA e no sistema de banco de dados MySQL.
A camada Fsica deve comandar e coletar informaes de dispositivos fsicos no
ambiente atravs de um sistema de comunicao. Diversas redes de campo e de
sensores (como Lonworks, Pyxos, EIB, BACnet, X-10) esto disponveis para essa
tarefa. Para sistemas com mais de um computador, redes locais como a Ethernet e
redes de grande abrangncia como Internet (TCP/IP) so opes usuais de redes de
computadores.
5.1. Camada Ontolgica
A camada Ontolgica da arquitetura proposta formada por um conjunto de
tabelas (um banco de dados) contendo as informaes de configurao necessrias
para o funcionamento da camada Reativa. Duas tabelas formam o ncleo da cama-
da Ontolgica. A primeira armazena as caractersticas de cada entidade (neurnios,
glndulas, setpoints e comportamentos) que compe a camada Reativa. A segunda
lista todas as conexes entre neurnios e seus respectivos parmetros de configu-
rao como o peso e o tipo. Tabelas contendo parmetros de configurao e lista de
comportamentos (hormnios) que afetam determinado neurnio ou glndula tambm
compem esta camada. Cada neurnio ou glndula que possui parmetros de confi-
gurao so relacionados a uma tabela de parmetros com uma lista de parmetros
especfica para cada classe de neurnio ou glndula. Da mesma, forma cada neur-
82

nio ou glndula que afetado por hormnios (comportamentos) do domnio a que
pertencem relacionado a uma tabela de comportamentos.
O Sistema de Gerenciamento de Banco de Dados (SGBD) MySQL foi utilizado
para gerenciamento das tabelas da camada Ontolgica. A comunicao entre o
SGBD e a camada Reativa feita atravs da interface JDBC (Java Database Con-
nectivity) que permite a comunicao entre aplicativos escritos em Java com o
MySQL. A linguagem SQL utilizada para programao das tabelas da camada On-
tolgica.
5.1.1. A tabela de entidades: entities
A tabela de entidades (entities) lista as entidades que compem a camada Re-
ativa e possui os seguintes campos:
nome (name): o nome da entidade. O nome da entidade uma composio
entre um nome de identificao e a hierarquia de domnios qual a entidade
pertence. Desse modo um sensor de movimento localizado no quarto de
uma casa ter o seguinte nome: casa.quarto.sensorDeMovimento, isto , a
entidade sensor de movimento pertence ao domnio quarto que pertence ao
domnio casa;
entidade (entity): o tipo de entidade, neurnio (neuron), glndula (gland),
setpoint ou comportamento (behavior);
classe (class): classe especfica do neurnio ou da glndula. Quando a en-
tidade um setpoint ou um comportamento (behavior), este campo deve
conter o nome da glndula associada a este setpoint ou comportamento
(behavior);
83

tabela de comportamentos (behaviorTable): nome da tabela com lista de
comportamentos a que o neurnio ou a glndula respondem. Caso o neur-
nio ou a glndula no responda a nenhum comportamento, este campo deve
ser configurado como null;
tabela de parmetros (parameterTable): nome da tabela com lista de pa-
rmetros do neurnio ou da glndula. Caso o neurnio ou a glndula no uti-
lize parmetros de configurao especficos este campo deve ser configura-
do como null;
mtodo (method): mtodo utilizado para combinar o comportamento do
neurnio ou da glndula quando mais de um hormnio com a mesma priori-
dade est ativo.
5.1.2. A tabela de conexes: neurotransmiters
A tabela de conexes contm as conexes neurnio-neurnio e neurnio-
glndula e suas caractersticas. Como a comunicao entre neurnios feita por
intermdio de neurotransmissores (GUYTON; HALL, 2006), esta tabela chamada
aqui de neurotransmissores (neurotransmiters). Ela segue a descrio dos campos
da tabela:
identificador de conexo (bindingID): nmero nico gerado automatica-
mente que identifica cada conexo existente na camada Reativa;
fonte (source): nome do neurnio fonte (que propaga a informao) da co-
nexo;
84

destino (destination): nome do neurnio ou da glndula destino (que rece-
be a informao) da conexo;
peso (weight): peso da conexo (parmetro de uso opcional);
valor padro (defaultValue): valor padro utilizado pela entidade destinado
caso a entidade fonte esteja inativa.
5.1.3. Tabelas de comportamento
As tabelas de comportamentos so associadas a neurnios e glndulas espec-
ficos, e descrevem como o neurnio ou a glndula deve responder aos comporta-
mentos listados. Os seguintes campos compem as tabelas de comportamento:
hormnio (hormone): nome do hormnio (comportamento);
tipo (type): binrio (binary) ou linear. O tipo linear interpreta valores cont-
nuos entre 0 e 1 (unsigned) ou -1 e 1 (signed). O tipo binrio interpreta ape-
nas dois valores 0 e 1 (unsigned) ou -1 e 1 (signed). Neste ltimo caso, o va-
lor zero tambm pode ocorrer, e como nos demais casos significa ausncia
do hormnio (comportamento desativado);
sinal (signal): sem sinal (unsigned) ou com sinal (signed). Os valores de-
vem ser limitados entre 0 e 1 (unsigned) ou entre -1 e 1 (signed);
inverso (inversion): inverso (inverse) ou direto (direct). No primeiro caso, o
valor recebido invertido, multiplicado por -1 (unsigned) ou calculado o
complemento 1 (signed).
85

prioridade (priority): prioridade do comportamento. A prioridade 1 a maior
e a prioridade decresce com o aumento da numerao. Comportamentos
sem prioridade so representados pela prioridade 0.
5.1.4. Tabelas de parmetro
As tabelas de parmetro so associadas a neurnios e a glndulas especficos
e descrevem parmetros de configurao do neurnio ou da glndula. Os setpoints
utilizados pelo neurnio ou pela glndula so configurados nesta tabela. Os seguin-
tes campos compem as tabelas de parmetro:
identificador (ID): nmero nico gerado automaticamente que identifica o
parmetro dentro da tabela;
parmetro (parameter): nome do parmetro. Este nome conhecido no c-
digo de programao da classe do neurnio ou da glndula;
tipo (type): tipo de parmetro (setpoint, nmero, texto ou valor booleano).
Este campo especifica como o valor do parmetro deve ser interpretado;
valor (value): valor do parmetro. No caso de setpoint, o valor o nome
do(s) setpoint(s) ao(s) qual(is) o neurnio ou a glndula responde.
5.2. Camada Reativa
A camada Reativa da arquitetura proposta deve ter dois tipos de unidades b-
sicas, os neurnios e as glndulas, que so unidades de processamento paralelo de
informao e autnomas. Autonomia, neste contexto, relaciona-se independncia
de cdigo de cada unidade, isto , as diferentes unidades so processos computa-
cionais independentes que podem ser processados, inclusive, em diferentes unida-
86

des computacionais (computadores). Essas caractersticas possibilitam a distribuio
da tarefa de processamento e facilitam a programao do paralelismo necessrio
aos neurnios e s glndulas.
A programao da camada Reativa baseada em CORBA e na linguagem Ja-
va. Esta linguagem orientada a objetos e possui recursos para programao de
aplicativos em rede, para acesso a banco de dados, para programao de threads
13

e um pacote para programao de aplicativos CORBA (bibliotecas, compilador IDL e
ORB). O objetivo a construo de uma plataforma que facilite a criao de classes
de neurnios e de glndulas, deixando transparente ao desenvolvedor os detalhes
de implementao da camada Reativa. O foco do desenvolvedor deve ser a aplica-
o e no a programao dos mecanismos de comunicao e gerenciamento de
neurnios e de glndulas.
Nas prximas sees descrito o arcabouo utilizado para a programao da
camada Reativa.
5.2.1. Comunicao CORBA
Neurnios e glndulas se comunicam atravs de uma interface bem definida
composta por dois mtodos: neurotransmiter e hormone. O primeiro recebe mensa-
gens de neurnios enquanto o segundo recebe mensagens de glndulas.
O mtodo neurotransmiter possui trs parmetros:
ID, nmero de identificao da conexo na tabela neurotransmiters (na ca-
mada Ontolgica);

13
Thread uma seo de cdigo executada independentemente de outras partes de cdigo dentro um mesmo
programa (OAKS; WONG, 1997). Permite a criao em um mesmo programa de processos independentes e
paralelos.
87

value, valor da conexo;
weight, peso da conexo;
Em geral, o parmetro peso (weight) propagado por um neurnio est especifi-
cado na tabela neurotransmiters da camada Ontolgica.
O mtodo hormone possui dois parmetros:
type, tipo ou nome do comportamento ou setpoint (hormnio);
value, nvel ou valor do comportamento ou setpoint (hormnio).
Um compilador IDL-Java transforma o cdigo IDL da interface CORBA em uma
srie de arquivos (classes) Java utilizados como base para a comunicao entre ob-
jetos CORBA (nesse caso os objetos Neuron e Gland). Para tornar transparentes os
mecanismos especficos do CORBA, duas classes, uma relacionada aos neurnios
e outra relacionada s glndulas, foram criadas: NeuronCORBA e GlandCORBA.
Essas duas classes foram programadas como threads, isto , processos indepen-
dentes. Quando um objeto dessas classes instanciado, eles se tornam uma nova
unidade processamento. A Figura 28 e a Figura 29 mostram diagramas com os prin-
cipais mtodos das classes NeuronCORBA e GlandCORBA, respectivamente. As
duas classes possuem um construtor no qual o nome do neurnio ou da glndula
deve ser passado, assim como argumentos de inicializao CORBA (como nome do
servidor ORB e nmero da porta de comunicao). As classes NeuronCORBA e
GlandCORBA possuem mtodos (propagate e secrete, respectivamente) para enviar
dados a outros neurnios e glndulas.
88

Figura 28 - Diagrama da classe NeuronCORBA.

Figura 29 - Diagrama da classe GlandCORBA.
As classes acima so responsveis pela comunicao, utilizando CORBA, en-
tre as entidades da camada reativa. Dessa forma, as funcionalidades de comunica-
o so separadas das demais funcionalidades do software, o que permite, no futu-
ro, a mudana dos mecanismos de comunicao sem a alterao do restante do
sistema.
5.2.2. Gerenciamento das funcionalidades
de neurnios e de glndulas
A utilizao direta dos mtodos propagate e secrete (das classes NeuronCOR-
BA e GlandCORBA) necessita que sejam passados como parmetros, informaes
como nome do destino, tipo de entidade (glndula ou neurnio) e identificador de
conexo (somente o mtodo propagate). Para que essas informaes fiquem trans-
parentes ao desenvolvedor, duas classes, uma para os neurnios (NeuronClass) e
outra para as glndulas (GlandClass), foram criadas. O objetivo dessas classes
gerenciar todos os aspectos envolvidos com o processamento e com a troca de in-
formaes entre as entidades da camada Reativa, assim como carregar todos os
parmetros armazenados na camada Ontolgica necessrios para o correto funcio-
89

namento do neurnio ou da glndula. Essas classes so filhas das classes Neuron-
CORBA e GlandCORBA, e por isso herdam todas suas funcionalidades.
Cada neurnio e cada glndula recebe informaes de outros neurnios e
glndulas, seja atravs de conexes (neurotransmissores) de entrada ou atravs de
comportamentos e setpoints (hormnios), aos quais o neurnio ou a glndula res-
ponde. A partir das informaes recebidas, o estado do neurnio ou da glndula
determinado em funo dos dados de entrada. A cada novo valor de entrada, o neu-
rnio ou a glndula recalcula seu estado e propaga-o, o que torna a comunicao na
camada Reativa assncrona.
Para que o estado do neurnio ou da glndula possa ser calculado a qualquer
momento, listas contendo os valores de cada conexo (neurotransmissores) de en-
trada, setpoints e comportamentos (hormnios), e parmetros de configurao de-
vem estar disponveis. As seguintes classes utilitrias foram construdas para arma-
zenar e gerenciar esses dados:
InBindings. Armazena lista com parmetros e valores de cada conexo de
entrada.
InHormones. Armazena lista de comportamentos aos quais o neurnio ou a
glndula responde. Calcula um fator de ponderao, baseado nos valores
recebidos pelos comportamentos ativos (com valores diferentes de zero) e
suas prioridades, que pode ser usado pelo neurnio ou pela glndula para
ponderar seu estado. Cinco mtodos foram implementados para combinar
comportamentos ativos com o mesmo grau de prioridade: last (utiliza o lti-
mo valor recebido), first (utiliza o primeiro valor recebido), mean (utiliza a
mdia de valores recebidos), higher (utiliza o maior valor recebido) e smaller
90

(utiliza o menor valor recebido). A maneira como cada comportamento deve
ser interpretado determinada pelos parmetros de configurao contidos
na tabela de comportamento, do neurnio ou da glndula, localizada na ca-
mada Ontolgica.
Parameters. Armazena lista de parmetros de configurao e a lista de set-
points aos quais o neurnio ou a glndula responde.
A cada atualizao do estado do neurnio ou da glndula, o novo valor deve
ser propagado. Para gerenciar as conexes (neurotransmissor) de sada dos neur-
nios e a sada (hormnio) das glndulas, foram criadas respectivamente duas clas-
ses utilitrias:
OutBindings. Armazena lista com parmetros, valor e entidade destino de
cada conexo de sada. Esta classe utilizada somente por neurnios.
OutHormones. Armazena lista com nome de todas as entidades pertencen-
tes ao mesmo domnio que a glndula. Esta classe utilizada somente por
glndulas.
As classes NeuronClass e GlandClass, utilizando as classes descritas acima,
so responsveis por todo processo de comunicao da camada Reativa em conso-
nncia com os parmetros contidos na Camada Ontolgica. Essas duas classes so
abstratas, isto , no podem ser utilizadas diretamente ou no podem ter objetos
instanciados. Elas so as bases para que classes especficas de neurnios e de
glndulas possam ser criadas atravs do processo de herana. Quatro mtodos abs-
tratos devem ser implementados nas classes filhas:
91

value( ). Este mtodo deve retornar o valor que ser propagado pelo neur-
nio ou pela glndula. O desenvolvedor deve utilizar os dados de entrada pa-
ra calcular o valor que ser propagado. Toda vez que um novo valor for re-
cebido, este mtodo chamado e o valor calculado propagado.
neurotransmiter( ). Este mtodo executado toda vez que o neurnio ou a
glndula recebe valores em suas conexes de entrada. Pode ser utilizado
para determinar a execuo de alguma tarefa quando o neurnio ou glndu-
la recebe valores pelas conexes de entrada.
hormone( ). Este mtodo chamado toda vez que o neurnio ou a glndula
recebe hormnios (comportamentos ou setpoints). Pode ser utilizado para
determinar a execuo de alguma tarefa quando o neurnio ou glndula re-
cebe hormnios (comportamentos ou setpoints).
sent( ). Este mtodo chamado toda vez que o neurnio ou a glndula pro-
pagou alguma informao. Pode ser utilizado para determinar a execuo de
alguma tarefa quando o neurnio ou glndula propaga alguma informao.
A Figura 30 e a Figura 31 mostram diagramas com os mtodos das classes
NeuronClass e GlandClass, respectivamente descritos acima. As duas classes pos-
suem um construtor no qual o nome do neurnio ou da glndula deve ser passado,
assim como argumentos de inicializao CORBA (como nome do servidor ORB e
nmero da porta de comunicao) e de acesso a camada Ontolgica.
92

Figura 30 - Diagrama da classe NeuronClass com os mtodos abstratos.

Figura 31 - Diagrama da classe GlandClass com os mtodos abstratos.
Alm dos mtodos abstratos j descritos, as classes NeuronClass e Gland-
Class possuem um conjunto de mtodos utilitrios que podem ser utilizados pelo
desenvolvedor para criao de novas classes de neurnios ou de glndulas:
getInBindings( ). Retorna a lista com as conexes de entrada.
getInHormones( ). Retorna a lista com os hormnios recebidos.
getParameters( ). Retorna a lista com os parmetros.
getInBindingLastValue( ). Retorna o ltimo valor recebido pelo neurnio ou
pela glndula atravs das conexes (neurotransmissores) de entrada.
getInBindingLastWeight( ). Retorna o ltimo peso recebido pelo neurnio
ou pela glndula atravs das conexes (neurotransmissores) de entrada.
getInBindingHigherValue( ). Retorna o maior valor entre as conexes (neu-
rotransmissores) de entrada.
93

getInBindingSmallerValue( ). Retorna o menor valor entre as conexes
(neurotransmissores) de entrada.
getWeight( ). Retorna o fator de ponderao dos hormnios ativados.
getSetpoint(setpointName). Retorna o ltimo valor de setpoint recebido.
getDoubleParameter(parameterName). Retorna valor numrico do par-
metro de configurao com o nome parameterName.
getStringParameter(parameterName). Retorna valor tipo texto do parme-
tro de configurao com o nome parameterName.
canNotPropagate( ). Impede que o prximo valor seja propagado.
A Figura 32 e a Figura 33 mostram diagramas com os mtodos utilitrios des-
critos acima das classes NeuronClass e GlandClass, respectivamente.

Figura 32 - Diagrama da classe NeuronClass com os mtodos utilitrios.
94

Figura 33 - Diagrama da classe GlandClass com os mtodos utilitrios.
5.2.3. Classes de Neurnios e de Glndulas
Todo o arcabouo descrito nas sees anteriores tem por objetivo simplificar o
desenvolvimento de novas classes de neurnios e de glndulas. Os mecanismos
relacionados com a comunicao e consulta camada Ontolgica foram programa-
dos nas classes descritas anteriormente. Dois templates (modelos), um de neurnio
e outro de glndula, foram criados. Os dois so bastante similares e por isso ser
descrito aqui o template de neurnio. Segue abaixo o cdigo Java inicial do template
de neurnio.
public class Neuron extends NeuronClass implements NeuronInterface {

public Neuron(String name,
String args[],
OntologyParameters op) throws SQLException {

super(name, args, op);
}
@Override
public double value() {
// calculate the state value of neuron and return it
return (getInBindingLastValue()*getInBindingLastWeight()*getWeight());
}
95

@Override
public void neurotransmiter() {
// insert here the code to be executed
// when a neurotransmiter is received
}
@Override
public void hormone() {
// when a hormone is received
}
@Override
public void sent() {
// when a value is propagated
}
}
A classe de neurnio criada acima tem o nome Neuron e filha da classe Neu-
ronClass, isto , herda todas as suas funcionalidades. Quatro mtodos da classe
NeuronClass devem obrigatoriamente fazer parte da nova classe de neurnio. Um
deles fundamental, o mtodo value( ). O valor calculado neste mtodo ser aquele
propagado pelo neurnio. No exemplo, o neurnio propagar o produto entre o lti-
mo valor recebido (getInBindingLastValue( )), o ltimo peso recebido (getInBindin-
gLastWeight( )) e o fator de ponderao dos hormnios ativados (getWeight( )).
Os demais mtodos devem ser utilizados em casos especiais onde necess-
rio que o neurnio execute aes no recebimento de um novo valor em uma cone-
xo de entrada (neurotransmiter( )) ou um novo valor de hormnio (hormone( )) ou
aps a propagao de um novo valor (sent( )).
Um neurnio, instncia da classe Neuron exemplificada acima, propagar o va-
lor calculado em value( ) sempre que um novo valor (neurotransmissor) ou hormnio
(setpoint ou comportamento) for recebido.

96

A implementao da arquitetura proposta descrita neste captulo buscou cons-
truir um arcabouo que permitisse o desenvolvimento de sistemas de automao do
ambiente construdo baseados em neurnios e em glndulas. Estes ltimos foram
programados na linguagem Java como threads (processos computacionais indepen-
dentes) e utilizam o middleware CORBA como plataforma de comunicao. Eles so
os componentes bsicos da camada Reativa na arquitetura proposta.
A forma de comunicao, os parmetros de configurao e as relaes entre
os comportamentos de neurnios e de glndulas e o comportamento geral do siste-
ma so descritas em forma de tabelas relacionais partes de um banco de dados. O
Sistema de Gerenciamento de Banco de Dados (SGBD) MySQL foi utilizado na im-
plementao apresentada. Esse conjunto de tabelas forma a camada Ontolgica da
arquitetura proposta.
Classes de neurnios e de glndulas so criadas a partir de templates (mode-
los) Java (descrito na seo 5.2.3). A partir de um conjunto de classes, um aplicativo
de automao do ambiente construdo programado atravs da configurao de um
conjunto de tabelas na camada Ontolgica que descrevem a estrutura, as conexes
e o comportamento das unidades bsicas da arquitetura, neurnios e glndulas. O
desenvolvedor mantm o foco na aplicao, pois os mecanismos de funcionamento
interno e de comunicao de neurnios e de glndulas ficam transparentes durante
a programao do sistema.
97

6. Aplicao da Arquitetura Proposta
Este captulo ilustra o desenvolvimento de um aplicativo para automao do
ambiente construdo orientado a neurnios e a glndulas. Um sistema de automao
de uma casa fictcia desenvolvido em oito etapas. A comunicao com dispositivos
fsicos em um ambiente construdo real tambm descrita. O captulo encerrado
com consideraes sobre a aplicao da arquitetura proposta.
6.1. Construindo o Sistema de Automao de
uma Casa
Para ilustrar a aplicao da arquitetura proposta na automao de um ambiente
construdo, o sistema de automao de uma casa fictcia modelado como um con-
junto de neurnios e de glndulas. O objetivo demonstrar como as caractersticas
de modularidade, de flexibilidade e de capacidade de integrao entre partes so
alcanadas com a utilizao da arquitetura proposta. So exemplificados sistemas
de controle e de reconhecimento de contexto de um quarto (foco principal) e de um
banheiro da casa. A modelagem do sistema feita em partes, simulando a implanta-
o de um sistema de automao construdo em etapas distintas, e que dever tra-
balhar de forma integrada. So oito etapas independentes de implantao descritas
a seguir.
6.1.1. Etapa 1 Sistema de Iluminao do Quarto
O sistema de iluminao do quarto deve regular a intensidade da iluminao
fornecida pela luminria de acordo com o setpoint escolhido pelo usurio atravs de
um controle manual deslizante. O usurio deve ser capaz de desligar a iluminao
quando desejar atravs de um interruptor. Na ausncia de pessoas, a iluminao
98

deve ser desativada para evitar desperdcio de energia eltrica. Cinco elementos de
interface entre o sistema e o mundo fsico so identificados na descrio anterior:
Um controle manual deslizante. Informa ao sistema o valor do setpoint de-
sejado.
Um sensor de movimento. Informa ao sistema a ausncia de movimento.
Um interruptor de luz. Informa ao sistema quando o usurio deseja que a
iluminao seja desligada ou ligada.
Um sensor de luz. Captura a iluminncia do quarto.
Uma luminria com intensidade regulvel. Ilumina o quarto com intensi-
dade de luz controlada entre 0 e 100%.
Uma malha de controle com um controlador PID (Proporcional-Integral-
Derivaitvo) escolhida para regular a iluminncia do quarto (ver Figura 34).

Figura 34 - Malha de controle da iluminao do quarto.
Dois comportamentos so identificados a partir da descrio inicial:
Ausncia. Comportamento ativado quando h ausncia de pessoas no
quarto.
Desativao da Iluminao. Comportamento ativado quando o usurio
desativa a iluminao.
99

Cada um dos comportamentos deve ser ativado de acordo com contexto. O
passo seguinte determinar quais contextos esto relacionados a quais comporta-
mentos e como estes contextos so detectados:
Ausncia. A ausncia de pessoas no quarto detectada atravs de um
sensor de movimento. Habitualmente necessria a utilizao de um tempo
de retardo. Esse tempo medido entre a deteco de um sinal de no mo-
vimento e a propagao de um sinal de ausncia, j que a no movimenta-
o de uma pessoa por um perodo curto de tempo no significa a sua au-
sncia (ver Figura 35).

Figura 35 - Deteco de ausncia
Desativao da Iluminao. A desativao da iluminao detectada
quando o usurio aciona o interruptor de luz na posio desligado.
A partir da descrio e da anlise anteriores, possvel modelar o sistema co-
mo um conjunto de neurnios e de glndulas. Os elementos funcionais (sensores,
controladores, atuadores, etc.) so modelados como neurnios. Os comportamentos
e os setpoints so modelados como glndulas. A Figura 36 mostra o diagrama de
relacionamento com os neurnios e as glndulas que compem o sistema. O setpo-
int de Luz foi modelado como uma glndula que recebe informao diretamente do
controle manual deslizante de iluminao. importante notar que o neurnio PID
Iluminao foi modelado com trs receptores de hormnio que recebem hormnios
secretados pelas glndulas Setpoint de Luz, Ausncia e Desativao da Iluminao.
100

Desta forma este neurnio responde aos comportamentos Ausncia e Desativa-
o da Iluminao.

Figura 36 Etapa 1: Diagrama de Relacionamento do Sistema de Iluminao do Quarto.
Neste momento cabe definir como sero configurados os parmetros de confi-
gurao de cada neurnio/glndula, os pesos de cada ligao e o mecanismo de
combinao de comportamentos em cada neurnio/glndula. No sistema modelado,
no h necessidade de ponderao ou de prioridade nas ligaes entre neur-
nio/glndulas, portanto todos os pesos so configurados com valor 1 (um). O meca-
nismo de combinao de comportamentos que define como o neurnio/glndula de-
ve reagir quando comportamentos com mesma prioridade esto ativos ser configu-
rado, para todos os neurnios/glndulas do sistema, de tal maneira que a prioridade
ser dada ao comportamento com maior prioridade ativado por ltimo. Os nicos
dois neurnios que possuem parmetros de configurao so os neurnios Retardo
de Tempo e PID Iluminao. A Figura 37 mostra os parmetros de configurao pa-
ra estes dois neurnios.
101

Figura 37 - Parmetros de configurao: Reatrdo de Tempo e PID Iluminao.
O passo final a programao do sistema modelado em software utilizando a
implementao da arquitetura proposta descrita no captulo anterior. Tal tarefa re-
quer que todos os neurnios e todas as glndulas, seus parmetros de configurao
e as ligaes entre neurnios/glndulas sejam descritos nas tabelas da camada On-
tolgica. Abaixo seguem as tabelas da camada Ontolgica preenchidas com os pa-
rmetros descritos anteriormente. Todos os neurnios e as glndulas do sistema
pertencem ao domnio Quarto que por sua vez pertence ao domnio Casa. Os no-
mes de neurnios/glndulas utilizados nas tabelas so os mesmos utilizados nos
diagramas anteriores com justaposio sem preposies para os nomes compostos
e sem acentuao. O Quadro 3 ilustra a tabela entities com os neurnios, as gln-
dulas, os setpoints e os comportamentos do sistema. O Quadro 4 contm a lista de
ligaes entre neurnios/glndulas, a tabela neurotransmiters. Os Quadro 5 e
Quadro 7 contm as tabelas com os parmetros de configurao dos neurnios PID
de Iluminao e Retardo de Tempo, respectivamente. O Quadro 6 contm a tabela
de comportamentos do neurnio PID de Iluminao.
Na implementao descrita no captulo anterior, as tabelas da camada Ontol-
gica fazem parte do banco de dados MySQL. Elas devem ser criadas e preenchidas
utilizando a linguagem SQL ou alguma ferramenta equivalente. Assume-se que as
classes de neurnios/glndulas utilizadas para esta aplicao j esto programadas.
102

Caso novas classes de neurnios/glndulas necessitem ser criadas, um template
(modelo) de neurnio/glndula em Java deve ser utilizado (descrito na seo 5.2.3).

Quadro 3- Tabela "entities"

Quadro 4 Tabela neurotransmiters
103

Quadro 5 Tabela ParamPIDIlum

Quadro 6 Tabela CompPIDIlum

Quadro 7 - Tabela ParamRetardoTempo
6.1.2. Etapa 2 Sistema de HVAC do Quarto
O sistema de HVAC (Heating, Ventilation and Air Conditioning Aquecimento,
Ventilao e Ar-condicionado) do quarto deve regular a temperatura do quarto de
acordo com o setpoint escolhido pelo usurio atravs de um controle manual desli-
zante. O usurio deve ser capaz de desligar o sistema de HVAC quando desejar a-
travs de um interruptor. Na ausncia de pessoas, o sistema tambm dever ser
desligado para evitar desperdcio de energia eltrica.
O novo sistema tem requisitos similares ao do sistema de iluminao descrito
na etapa anterior. A diferena est na varivel controlada, temperatura ao invs de
iluminncia. O mesmo sistema de deteco de ausncia ser utilizado pelos dois
sistemas. Os mesmos tipos de neurnios/glndulas utilizados na etapa anterior po-
dem agora ser adaptados para o sistema de HVAC. A Figura 38 ilustra um diagrama
104

com neurnios/glndulas do sistema de HVAC do quarto. Os neurnios/glndulas do
sistema de deteco de ausncia da Figura 37 foram repetidos na Figura 38.

Figura 38 - Etapa 2: Diagrama de Relacionamento do Sistema de HVAC do Quarto.
A programao dos novos neurnios/glndulas deve ser feita acrescentando-se
s tabelas da camada Ontolgica descritas na etapa anterior, os novos neur-
nios/glndulas, seus parmetros de configurao e as ligaes entre neur-
nios/glndulas.
6.1.3. Etapa 3 Deteco de Ausncia no Quarto
O sistema de deteco de ausncia usado anteriormente utiliza um sensor de
movimento para detectar a ausncia. Para melhorar a qualidade da deteco de au-
sncia, um novo sensor acrescentado ao sistema. Os dois sensores so combina-
dos atravs de um neurnio do tipo OU que propagar o sinal do sensor com maior
valor, isto , o do sensor que estiver detectando movimento dentro do intervalo de-
terminado pelo neurnio Retardo de tempo. A Figura 39 ilustra o acrscimo do
sensor ao sistema de deteco de ausncia.
105

Outros dois sensores tambm podem colaborar para melhorar a deteco de
ausncia no quarto: um sensor de variao de presso instalado na cama e outro
instalado em um tapete localizado em regies onde h pouca movimentao como
numa escrivaninha ou numa cmoda. O acrscimo de mais dois sensores feito
com a insero de mais dois neurnios que representam os sensores, e mais dois
neurnios Retardo de Tempo como no caso anterior. A Figura 40 ilustra o acrsci-
mo dos novos sensores ao sistema de deteco de ausncia.

Figura 39 Etapa 3: Diagrama de Relacionamento do Sistema de Deteco de Ausncia.

Figura 40 Etapa 3: Diagrama de Relacionamento do Sistema de Deteco de Ausncia
com acrscimo de mais dois sensores de variao de presso.
106

6.1.4. Etapa 4 Sistema de Setpoint Personalizado
O sistema de reconhecimento de usurios deve reconhecer atravs de um re-
ceptor de RFID (Radio Frequency Identification) o usurio A e o usurio B no quarto.
Os usurios devem portar um transmissor (tag) RFID para serem identificados. A
identificao do usurio deve ser usada para personalizar os setpoints de temperatu-
ra e de luz.
Um receptor de RFID e um neurnio representando o sensor so acrescenta-
dos ao sistema. Para detectar o usurio A e o usurio B, dois neurnios que compa-
ram o nmero de identificao enviado pelo receptor com o peso da conexo (neuro-
transmissor) so utilizados. A entrada do Usurio A e do Usurio B no quarto deve
alterar o comportamento de alguns subsistemas do quarto, por isso so modelados
como glndulas.
Um neurnio Setpoint de Iluminao acrescentado entre o neurnio Con-
trole Deslizante de Iluminao e a glndula Setpoint de Luz. Este ltimo possui
receptores para os hormnios Usurio A, Usurio B e Ausncia. Na tabela de
tabela de parmetros devem ser registrados hormnios Usurios A e Usurio B
com seus respectivos valores de setpoint. O valor propagado pelo Controle Desli-
zante de Iluminao possui prioridade maior que os parmetros tabelados, uma vez
modificado o primeiro, ele tem precedncia sobre os ltimos at que seja detectada
Ausncia. Este ltimo hormnio deve ser configurado para tal na tabela de par-
metros. O mesmo acrscimo deve ser feito com o setpoint de temperatura. A Figura
41 ilustra um diagrama do Sistema de Setpoint Personalizado.
107

Figura 41 Etapa 4: Diagrama de Relacionamento do Sistema de Setpoint Personalizado.
6.1.5. Etapa 5 Sistema para Aproveitamento da Luz Solar
Para melhorar a utilizao da luz solar atravs da janela, um aparato de luz de-
ve ser instalado externamente a janela. A abertura do aparato deve ser constante-
mente ajustada procurando aproveitar a luz solar sem deixar que a carga trmica
aumente demasiadamente. Para tal tarefa recomenda-se a adaptao do controla-
dor difuso usado por Guillemin (2003). O controlador necessita de dados ambientais
externos casa: a iluminncia vertical e a mdia das temperaturas das ltimas 24
horas. O ngulo de abertura do aparato de luz calculado em funo calculado em
funo destas variveis. A temperatura mdia fuzzificada em dois conjuntos difu-
sos: vero e inverno. E a iluminncia vertical em quatro conjuntos difusos: noite, bai-
xa, mdia, alta. Oito regras difusas combinam a temperatura mdia e a iluminncia
vertical. Para cada regra h um valor particular de abertura. As oito regras so com-
binadas ao final atravs do mtodo centro de gravidade (COG Center Of Gravity).
Trs elementos fsicos so necessrios para implantao do sistema descrito
acima: um sensor de iluminncia vertical externa, um sensor de temperatura externa
e um aparato de luz controlado eletronicamente. Trs neurnios representam cada
108

um destes trs elementos na camada Reativa. Como a temperatura e a iluminncia
no so grandezas particulares do quarto, os neurnios relacionados a estas gran-
dezas pertencem ao domnio casa. A temperatura mdia das ltimas 24 horas
calculada por um neurnio (especfico para clculo de mdias). Dois domnios espe-
ciais foram criados para agrupar os conjuntos difusos relacionados mdia de tem-
peratura e a iluminncia, Estao e Iluminncia, respectivamente. A Figura 42 ilustra
um diagrama do Sistema para Aproveitamento da Luz Solar.

Figura 42 Etapa 5: Diagrama de Relacionamento do
Sistema para Aproveitamento da Luz Solar.
109

Para o controlador difuso foi tambm criado um terceiro domnio. Este domnio
contm um conjunto de oito neurnios representando as oito regras difusas, um se-
gundo conjunto difuso de oito neurnios defuzificam a sada de cada regra usando o
mtodo COG (o peso corresponde a rea abaixo do grau de pertinncia recebido da
regra difusa) e um neurnio que calcula a mdia ponderada pelos pesos das oito
sadas defuzzificadas. Este ltimo neurnio propaga o valor de abertura para o apa-
rato de luz.
6.1.6. Etapa 6 Sistema de Controle para o Chuveiro
O sistema de controle para o chuveiro deve ajustar a temperatura da gua do
banho de acordo com a poca do ano ou de acordo com o desejo do usurio repor-
tado atravs de um controle deslizante.
Para ajustar a temperatura de acordo com a estao do ano, os conjuntos difu-
sos Estao (Inverno e Vero) utilizados na etapa anterior (Sistema para Aprovei-
tamento da Luz Solar) sero reutilizados. Os neurnios Inverno e Vero alimenta-
ro duas glndulas Inverno e Vero.
Um controle deslizante para o chuveiro, um sensor de temperatura da gua e
um chuveiro com controle de temperatura so instalados no banheiro e so repre-
sentados por trs neurnios na camada Reativa: Controle Deslizante Chuveiro,
Sensor de Temperatura da gua e Chuveiro, respectivamente.
Um neurnio Setpoint de Temperatura da gua calcula o setpoint para a gua
do banho e propaga-o para a glndula Setpoint de Temperatura da gua. O neur-
nio possui receptores para os hormnios Inverno, Vero e Ausncia. Na tabela
de parmetros devem ser registrados os hormnios Inverno e Vero com seus
110

respectivos valores de setpoint. O valor propagado pelo Controle Deslizante Chu-
veiro possui prioridade sobre os parmetros tabelados; uma vez modificado o pri-
meiro tem precedncia sobre os ltimos at que seja detectada Ausncia. Este l-
timo hormnio deve ser configurado para tal na tabela de parmetros.
Similarmente aos sistemas de Iluminao e de HVAC, o sistema de controle do
chuveiro utiliza um neurnio PID para controlar a temperatura da gua. A Figura 43
ilustra um diagrama do Sistema de Controle para o Chuveiro.

Figura 43 Etapa 6: Diagrama de Relacionamento do Sistema de Controle para o Chuveiro.
6.1.7. Etapa 7 Mais comportamentos para o quarto
Duas novas funcionalidades devero ser acrescentadas ao sistema de auto-
mao do quarto: a televiso deve ser programada para que seu volume seja dimi-
nudo quando o telefone estiver em uso, evitando assim que o som da televiso in-
terfira na conversa ao telefone; o telefone no dever tocar e a televiso dever ser
desligada quando o usurio estiver dormindo durante a noite.
Para que as duas funcionalidades acima possam ser desenvolvidas necess-
rio que a televiso e o telefone troquem informaes atravs da camada Reativa. A
111

televiso um aplicativo que contm um neurnio, TV, que recebe informaes
trocadas na camada Reativa. O mesmo acontece com o telefone. Esses dois neur-
nios propagam o estado da televiso (ligada ou no) e o estado do telefone (em uso
ou no) para duas glndulas, TV Ligada e Telefone em Uso, respectivamente.
O comportamento Dormindo ser a composio de duas informaes, est
escuro ( noite) e h pessoas na cama. Esses dados so capturados por um sensor
de luz (o mesmo utilizado no controle de iluminncia do quarto) e um sensor de vari-
ao de presso na cama (o mesmo utilizado para detectar ausncia). Um neurnio,
Escuro, determina se est escuro ou no (funo difusa trapezoidal). Essas duas
informaes so combinadas atravs de um neurnio E, que propaga o maior valor
recebido em suas conexes de entrada para a glndula Dormindo.
O aplicativo TV responder aos hormnios Telefone em Uso e Dormindo
diminuindo o som da televiso e desligando-a respectivamente. O aplicativo Telefo-
ne responder ao hormnio Dormindo no permitindo que o telefone toque. A Fi-
gura 45 ilustra um diagrama dos comportamentos descritos acima.

Figura 44 Etapa 7: Diagrama de Relacionamento de mais Comportamentos para o Quarto.
112

6.1.8. Etapa 8 Mais Comportamentos para a Casa
Comportamentos mais genricos que afetam a casa inteira tambm podem ser
acrescentados, como por exemplo:
Bloqueio por senha de acesso. O comportamento bloqueio ativado quando
um teclado de acesso no desativado atravs de uma senha de acesso.
Vazamento de gs. Este comportamento ativado quando detectado va-
zamento de gs na cozinha.
Correspondncia. Este comportamento ativado quando h correspondn-
cia na caixa de correio.
A Figura 45 ilustra um diagrama dos comportamentos descritos acima.

Figura 45 Etapa 8: Diagrama de Relacionamento de mais Comportamentos para a Casa.
6.2. Comunicao com Dispositivos Fsicos
Durante um ms, um aplicativo baseado na implementao da arquitetura pro-
posta foi posto para funcionar em conjunto com uma rede de sensores existente.
Esta ltima interliga sensores localizados em dois quartos em um ambiente residen-
cial. Um conjunto de dispositivos fsicos como sensores de movimento, de tempera-
tura, de luz (iluminncia) e de presso, reed switches (chaves magnticas), um re-
113

ceptor de RFID, uma barreira tica, conjuntos de LEDs para iluminao, entre outros
esto interligados em rede. A rede de sensores utilizada foi desenvolvida por Tibiri
(2007), especialmente para ser um meio de comunicao de baixo custo entre dis-
positivos fsicos utilizados em ambientes construdos. Um aplicativo permite o aces-
so aos dados da rede atravs de uma conexo TCP/IP tipo soquete. O Quadro 8
resume algumas caractersticas da rede de sensores.

Quadro 8 Caractersticas da rede de sensores. Fonte: Tibiri (2007).
A Figura 46 mostra a planta dos dois quartos e o posicionamento dos sensores
(descritos no Quadro 9). Durante o perodo de observao o sistema ficou em fun-
cionamento no perodo diurno, cinco dias por semana. Os neurnios de interface
(localizados no computador do Quarto 2) se comunicam com o aplicativo da rede de
sensores (localizado no computador do Quarto 1) atravs de uma conexo TCP/IP
tipo soquete. A movimentao dos usurios durante a execuo de atividades di-
rias estimulava os sensores instalados nos dois quartos. LEDs para iluminao fo-
ram programados para responder diferentemente s diferentes aes dos usurios.
Durante o perodo de observao no foram notados atrasos perceptveis (maiores
114

que um segundo) entre a mudana de estado provocada em um sensor, o recebi-
mento do sinal pelos neurnios e a atuao do sistema atravs dos atuadores.

Figura 46 Planta dos quartos com a posio dos sensores instalados.
115

Quadro 9 Descrio dos sensores apontados na Figura 46.
O sistema de automao descrito na seo 6.1 resultado da associao de
mdulos simples e bem determinados. Com poucas classes de neurnios e de gln-
dulas foi possvel criar uma diversidade de sistemas automticos para o ambiente
construdo. Com praticamente os mesmos mdulos bsicos, diferentes sistemas de
automao foram programados. Os sistemas de Iluminncia e de HVAC no quarto, e
o sistema de Controle do Chuveiro no banheiro utilizam a mesma estrutura bsica
de mdulos. Os neurnios Vero e Inverno compem tanto o sistema de Aproveita-
mento de Luz Solar no quarto quanto o sistema de Controle do Chuveiro no banhei-
116

ro. Um conjunto de mdulos bsicos foi combinado para formar diferentes sistemas
de automao, em etapas distintas de programao da casa descrita anteriormente.
Cumpre-se assim um dos requisitos colocados inicialmente para a arquitetura pro-
posta, a modularidade.
A associao de novos mdulos aos j existentes facilitada pela interface de
comunicao comum de neurnios e de glndulas. Na casa fictcia, o sistema de
Deteco de Ausncia era inicialmente baseado em um sensor de movimento. Ou-
tros sensores foram acrescidos formando novas associaes de neurnios e trazen-
do novas funcionalidades ao sistema. O mesmo observado na implantao do sis-
tema de Setpoint Personalizado. Os neurnios Setpoint de Iluminao e Setpoint
de Temperatura se associaram s glndulas Setpoint de Luz e Setpoint de Tem-
peratura, respectivamente, aumentando as funcionalidades anteriores. A interface
comum entre os mdulos bsicos, neurnios e glndulas, permite que estes sejam
combinados de inmeras maneiras, tornado a arquitetura proposta flexvel.
O mecanismo de funcionamento das glndulas permite que os comportamen-
tos de neurnios/glndulas pertencentes a diferentes sistemas sejam integrados. A
configurao de um novo receptor de hormnio em um neurnio/glndula, o deixa
suscetvel a ao de uma glndula. Na casa fictcia, a glndula Ausncia afeta dire-
tamente comportamentos dos sistemas de Iluminao, de HVAC e de Aproveitamen-
to de Luz Solar no quarto. Neurnios em toda a casa tambm poderiam ser configu-
rados a se comportarem de maneira particular quando a glndula Bloqueio ou a
glndula Vazamento estivessem ativas. Este ltimo exemplo demonstra como a
insero de um novo comportamento pode ser configurada para afetar vrias partes
do sistema. O sistema final , desta forma, capaz de integrar as diversas partes que
o compe.
117

A expanso do sistema acontece de forma natural. possvel desenvolver uma
soluo de automao em etapas distintas. Funcionalidades no precisam ser pre-
vistas desde o incio do processo de desenvolvimento. A interface simples e comum
entre as diferentes classes de neurnios e de glndulas facilita a associao de no-
vos neurnios e novas glndulas aos j existentes.
Um sistema completo de automao pode ser desenvolvido a partir de classes
de neurnios e de glndulas pr-existentes. Todo o sistema se torna fruto da confi-
gurao de parmetros da camada Ontolgica. Essas caractersticas tornam a arqui-
tetura proposta modular, flexvel e capaz de integrar de forma simples os diversos
sistemas automticos que coexistem nos ambientes construdos.
118

7. Concluso
Arquitetura de software para Automao do Ambiente Construdo um tema
ainda pouco explorado. Na literatura, extensa a lista de trabalhos voltados apri-
morao de sistemas automticos aplicados aos ambientes construdos, mas muito
pouco encontrado sobre temas relacionados ao desenvolvimento e estruturao
do software utilizado nestes sistemas. No entanto, a arquitetura de software a base
para construo desses sistemas. medida que a complexidade do sistema de au-
tomao aumenta, maior a importncia da estruturao do software.
Como inicialmente estabelecido, este trabalho de pesquisa consistiu na propo-
sio de uma arquitetura de software neuro-reativa para sistemas de Automao do
Ambiente Construdo. Estes ltimos so construdos a partir de associaes de neu-
rnios e de glndulas artificiais, elementos bsicos da arquitetura com caractersti-
cas fortemente reativas. Um modelo de quatro camadas norteia o desenvolvimento
de aplicaes. A camada Fsica responsvel por capturar informaes e enviar
comandos aos componentes fsicos do sistema, como sensores e atuadores. Duas
camadas, Reativa e Ontolgica, compem o ncleo da arquitetura. Toda a dinmica
do sistema resultado das interaes entre neurnios e glndulas na camada Rea-
tiva. Por outro lado, o modo de interao e de ao de cada componente descrito
na camada Ontolgica. As trs camadas anteriores servem como plataforma para o
desenvolvimento de aplicativos na camada de Aplicao. Esses aplicativos podem
modificar dinamicamente os parmetros de configurao e as conexes descritas na
camada Ontolgica, e instanciar novos neurnios e glndulas na camada Reativa.
O projeto de software pode ser desenvolvido em etapas distintas com utilizao
de modelos com neurnios, glndulas e domnios que representaro os diversos
119

elementos de automao do sistema. Diagramas de Relacionamento ajudam a visu-
alizar o sistema em desenvolvimento. Conjuntos de tabelas descrevem as caracte-
rsticas funcionais de cada neurnio e glndula. Esses diagramas e tabelas so ele-
mentos importantes de documentao no projeto, e a sua traduo para um software
ocorre de maneira natural com o uso da arquitetura proposta.
Requisitos como modularidade, flexibilidade e capacidade de integrao das
partes foram obtidos. Os elementos bsicos da arquitetura proposta, neurnios e
glndulas, so estruturalmente simples e com interface tambm simples, o que torna
a soluo final modular e flexvel. As glndulas representam comportamentos e set-
points, e propagam essas informaes a todas as entidades de um domnio, inte-
grando dessa forma comportamentos individuais em um domnio. O resultado foi
uma estrutura final que facilita o desenvolvimento, a manuteno e a expanso do
software para Automao do Ambiente Construdo.
7.1. Principais contribuies
As principais contribuies alcanadas com esta tese foram:
Proposio de uma arquitetura de software para Automao do Ambi-
ente Construdo. A arquitetura proposta coloca-se como uma opo para o
desenvolvimento de software para sistemas de Automao do Ambiente
Construdo. A literatura ainda trata de forma incipiente este assunto e prati-
camente so inexistentes referncias especficas para estruturao de soft-
ware para construo de sistemas de Automao do Ambiente Construdo.
Nesse contexto, a arquitetura proposta uma base de referncia para futu-
ros trabalhos nesta rea.
120

Implementao do arcabouo da arquitetura proposta. O arcabouo da
arquitetura proposta foi programado na linguagem Java utilizando como pla-
taforma as tecnologias CORBA e MySQL. Foram tomados cuidados para
que o arcabouo deixasse detalhes de funcionamento da arquitetura trans-
parente aos usurios. A estrutura utilizada para implementao da arquitetu-
ra proposta foi descrita. Futuros trabalhos podero utiliz-la como referncia.
Modelos baseados em neurnios e em glndulas. Os neurnios e as
glndulas podem ser utilizados para descrever o funcionamento de elemen-
tos bsicos de sistemas de Automao do Ambiente Construdo. Desta for-
ma um sistema de Automao do Ambiente Construdo pode ser modelado
como uma associao de neurnios e de glndulas. Independentemente da
implementao em software, o modelo construdo colabora para a visualiza-
o e o entendimento da dinmica de funcionamento do sistema.
7.2. Trabalhos futuros
A seguir so apresentadas sugestes para futuros trabalhos:
Desenvolvimento de ferramentas visuais para configurao de neur-
nios e de glndulas. A configurao de neurnios e de glndulas na imple-
mentao apresentada feita atravs de cdigos SQL. Um ambiente de de-
senvolvimento com recursos visuais, no qual o usurio trabalhe de maneira
mais intuitiva, facilitar bastante o desenvolvimento de novas aplicaes de
Automao do Ambiente Construdo.
Mtodos para combinao de comportamentos. Um neurnio ou uma
glndula pode estar sujeito a ao de vrios hormnios (comportamentos).
121

Na implementao apresentada, uma hierarquia de prioridades determina
qual hormnio ativo tem maior prioridade. Hormnios ativos com a mesma
prioridade podem ser combinados atravs de cinco mtodos: last, first, me-
an, higher e smaller. No entanto, o gerenciamento de comportamentos um
campo importante dentro das arquiteturas reativas; outros mtodos de com-
binao de comportamento devem merecem ser estudados e adaptados
arquitetura proposta.
Implementao da arquitetura proposta em hardware. A arquitetura
proposta foi implementada completamente na linguagem Java em computa-
dores PC. Parte da arquitetura poderia ser implementada em ns de redes
de campo ou de sensores, distribuindo o processamento do sistema.
Criao de verses do arcabouo proposto em outras linguagens de
programao. O arcabouo da arquitetura proposta foi programado na lin-
guagem Java. Implementaes em outras linguagens tambm poderiam ser
feitas. Outras opes de middleware de comunicao e de banco de dados
tambm devem ser exploradas.
Estudo e otimizao dos mecanismos de comunicao de neurnios e
de glndulas. Neurnios e glndulas foram implementados como processos
de software independentes, que se comunicam de forma assncrona e sem
preocupao com reconhecimento de mensagens. Futuras verses poderi-
am ter mecanismos de reconhecimento de mensagem e mecanismos de
comunicao sncrona.
Programao de classes de neurnios. Novas classes de neurnios e de
glndulas poderiam ser programadas com funcionalidades teis aos siste-
122

mas de Automao do Ambiente Construdo. Bibliotecas de classes facilita-
ro a construo desses sistemas.
Mdulos de aprendizagem. Mdulos de aprendizagem com diferentes algo-
ritmos poderiam ser criados para a camada de Aplicao. Eles poderiam fa-
zer configurao dinmica de parmetros na camada Ontolgica e instancia-
es de novas entidades na camada Reativa.
123

Referncias

AKYILDIZ, I. F.; SU, W.; SANKARASUBRAMANIAM, Y.; CAYRICI, E. A survey on
Sensor Networks. IEEE Communications Magazine, pp. 102-114, 2002.
ALCAL, R.; CASILLAS, J.; CORDN, O.; GONZLEZ, A.; HERRERA, F. A genetic
rule weighting and selection process for fuzzy control of heating, ventilating
and air conditioning systems. Engineering Applications of Artificial Intelligence, 18,
pp. 279-296, 2005.
BOLTON, F. Pure CORBA. Sams Publishing, 2002.
BRAGA, A.; CARVALHO, A. C.; LUDERMIR, T. B. Redes Neurais Artificiais: teoria
e aplicaes. Rio de Janeiro: LTC, 2007.
BROOKS, R. A. A robust layered control system for a mobile robot. IEEE Journal
of Robotics and Automation, 1 (1), pp. 1-10, 1986.
BROOKS, R. A. Intelligence without representation. Artificial Inteligence, 47, pp.
139-159, 1991.
BROOKS, R. A. The Intelligent Room Project. Proceedings of the 2nd International
Conference on Cognitive Technology, 1997.
BROSE, G.; VOGEL, A.; DUDDY, K. Java Programming with CORBA: Advanced
Techniques for Building Distributed Applications. John Wiley & Sons, 2001.
CALLAGHAN, V.; CLARKE, G.; COLLEY, M.; HAGRAS, H.; CHIN, J. S.; DOCTOR,
F. Inhabited intelligent environments. BT Technology Journal, 22 (3), 2004.
CALLAGHAN, V.; CLARKE, G.; POUNDS-CORNISH, A.; SHARPLES, S. Buildings
as Intelligent Autonomous Systems: A Model for Integrating Personal and
Buildings Agents. 6th International Conference on Intelligent Autonomous Systems,
2000.
CAYCI, F.; CALLAGHAN, V.; CLARKE, G. A Distributed Intelligent Building Agent
Language (DIBAL). 6th International Conference on Information System Analysis
and Synthesis, 2000.
CHONG, C.-Y.; KUMAR, S. P. Sensor networks: evolution, opportunities and
challenges. 1247-1256, Ed. Proceedings of the IEEE, 91 (8), 2003.
COEN, M. H. Building brains for rooms: designing distributed software agents.
Nineth Conference on Innovative Applications of Artificial Inteligence (IAA' 99), 1997.
COEN, M. H. Design Principles for Intelligent Environments. Proceedings of the
fifteenth national/tenth conference on Artificial intelligence/Innovative applications of
artificial intelligence, 1998.
124

COLEMAN, D.; ARNOLD, P.; BODOFF, S.; DOLLIN, C.; GILCHRIST, H.; HAYES, F.;
JEREMAES, P. Desenvolvimento orientado a objetos: o mtodo Fusion. Rio de
Janeiro: Campus, 1996.
COOK, D. J.; DAS, S. K. How smart are our environments? An updated look at
the state of the art. Pervasive and Mobile Computing, 3, pp. 53-73, 2007.
COOK, D. J.; DAS, S. K. Smart Environments - Technology, Protocols and
Applications. New Jersey: John Wiley & Sons, 2005.
COOK, D. J.; YOUNGBLOOD, M.; HEIERMAN III, E. O.; GOPALRATNAM, K.; RAO,
S.; LITVIN, A.; KHAWAJA, F. MavHome: An Agent-Based Smart Home.
Proceedings of the First IEEE International Conference on Pervasive Computing and
Communications, 2003.
DAS, S. K.; COOK, D. J.; BHATTACHARYA, A.; HEIERMAN III, E. O.; LIN, T.-Y. The
role of prediction algorithms in the Mavhome Smart Home Architecture. IEEE
Wireless Communications, December, 2002.
DEY, A. K. Understanding and using context. Personal and Ubiquitous Computing,
5, pp. 4-7, 2001.
DEY, A. K.; ABOWD, G. D.; SALBER, D. A context-based indrastructure for
Smart Environments. Proceedings of the 1st International Workshop on Managing
Interactions in Smart Environments (MANSE 99), pp. 114-128, 1999.
DOUNIS, A. I.; CARAISCOS, C. Intelligent Coordinator of Fuzzy Controller-Agent
for Indoor Environment Control in Buildings using 3-D Fuzzy Comfort Set. IEEE
International Fuzzy Systems Conference, pp. 1-6, 2007.
DOUNIS, A. I.; LEFAS, C. C.; ARGIRIOU, A. Knowledge-based versus classical
control for solar-building designs. Applied Energy, 50, pp. 281-292, 1995.
DOUNIS, A. I.; SANTAMOURIS, M. J.; LEFAS, C. C.; ARGIRIOU, A. Design of a
fuzzy set environment comfort system. Energy and Buildings, 22, pp. 81-87, 1995.
ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. So Paulo: Pearson
Addison Wesley, 2005.
GUILLEMIN, A. Using Genetic Algorithms to into Account User Wishes in an
Advanced Building Control System. Lausanne, Suia: Tese de doutorado da
Escola Politcnica de Lausanne, 2003.
GUILLEMIN, A.; MOLTENI, S. An energy-efficient controller for shading devices
self-adapting to the user wishes. Building and Environment, pp. 1091-1097, 2002.
GUILLEMIN, A.; MOREL, N. An innovative lighting controller integrated in a self-
adaptive building control system. Energy and Buildings, 33, pp. 477-487, 2001.
GUILLEMIN, A.; MOREL, N. Experimental results of a self-adaptive integrated
control system in buildings: a pilot study. Solar Energy, 72, pp. 397-403, 2002.
125

GUYTON, C. A.; HALL, J. E. Textbook of Medical Physiology. 11th edition ed.,
Elsevier Saunders, 2006.
HAGRAS, H.; CALLAGHAN, V.; COLLEY, M.; CLARKE, G. A hierarchical fuzzy-
genetic multi-agent architecture for intelligent buildings online learning,
adaptation and control. Information Sciences, 150, pp. 33-57, 2003.
HAYKIN, S. Neural networks: a comprehensive foundation. Upper Saddle River:
Prentice-Hall, 1999.
HELAL, A. S.; YANG, H.-I.; KING, J.; BOSE, R. Atlas - Architecture for Sensor
Network Based Intelligent Environments. ACM Transactions on Sensor Networks,
2007.
HELAL, S.; MANN, W.; EL-ZABADANI, H.; KING, J.; KADDOURA, Y.; JANSEN, E.
The Gator Tech Smart House: A Programmable Pervasive Space. IEEE
Computer magazine, pp. 64-74, 2005.
HELAL, S.; WINKLER, B.; LEE, C.; KADDOURAH, Y.; RAN, L.; GIRALDO, C.;
MANN, W. Enabling location-aware pervasive computing applications for the
eldery. Proceedings of the First IEEE Pervasive Computing Conference, 2003.
INTILLE, S. S. Design a home of the future. Pervasive Computing , April-June,
2002.
JANSEN, E.; ABDULRAZAK, B.; YANG, H.; KING, J.; HELAL, S. A Programming
Model for Pervasive Spaces. Submitted to the 3rd International Conference on
Service Oriented Computing, 2005.
KADDOURA, Y.; KING, J.; HELAL, A. S. Cost-precision tradeoffs in
unencumbered floor-based indoor location tracking. Proceedings of third
International Conference on Smart Homes and Health Telematic (ICOST), 2005.
KASTNER, W.; NEUGSCHWANDTNER, G.; SOUCEK, S.; NEWMANN, H. M.
Communication Systems for Building Automation Control. Proceedings of IEEE,
93 (6), pp. 1178-1203, 2005.
KING, J.; BOSE, R.; YANG, H.-I.; PICKLES, S.; HELAL, A. Atlas: A Service-
Oriented Sensor Platform. Proceedings of the first IEEE International Workshop on
Practical Issues in Building Sensor Network Applications (SenseApp 2006), 2006.
KOLOKOTSA, D.; SARIDAKIS, G.; POULIEZOS, A.; STAVRAKAKIS, G. S. Design
and installation of an advanced EIB fuzzy indoor comfort controller using
Matlab. Energy and Buildings, 38, pp. 1084-1092, 2006.
KOLOKOTSA, D.; STAVRAKAKIS, G. S.; KALAITZAKIS, K.; AGORIS, D. Genetic
algorithms optimized fuzzy controller for the indoor environmental
management in buildings implemented using PLC and local operating
networks. Engineering Applications of Artificial Intelligence , 15, pp. 417-428, 2002.
KOLOKOTSA, D.; TSIAVOS, D.; STAVRAKAKIS, G. S.; KALAITZAKIS, K.;
ANTONIDAKIS, E. Advanced fuzzy logic controllers design and evaluation for
126

buildings' occupants thermal-visual comfort and indoor air quality satisfaction.
Energy and Buildings, 33, pp. 531-543, 2001.
KRISTL, Z.; KOSIR, M.; LAH, M. T.; KRAINER, A. Fuzzy control system for
thermal and visual comfort in building. Renewable Energy, 33, pp. 694-702, 2008.
KULKARNI, A. A. A reactive behavioral system for the Intelligent Room. Master
Engineering of Electrical Engineering and Computer Science Thesis, 2002.
LAH, M. T.; ZUPANCIC, B.; PETERNELJ, J.; KRAINER, A. Daylight illuminance
control with fuzzy logic. Solar Energy, 80, pp. 307-321, 2006.
MAHALIK, N. G.; LEE, S. K. Design and development of system level software
tool for DCS simulation. Advances in Engineering Software, 34, pp. 451-465, 2003.
MAHALIK, N.; XIE, C.; PU, J.; MOORE, P. R. Virtual distributed control systems:
a components-based design method for mechatronic systems. Assembly
Automation, 26 (1), pp. 44-53, 2006.
MINSKY, M. The society of mind. New York: Simon & Schuster, 1986.
MOZER, M. C. The Neural Network House: an environment that adapts to its
inhabitants. Proceedings of the American Association for Artificial Inteligence Spring
Symposium on Intelligent Environments, pp. 110-114, 1998.
MURPHY, R. R. Introduction to AI Robotics. Cambridge, Massachusetts: A
Bradford Book, 2000.
OAKS, S.; WONG, H. Java threads. O 'Reilly, 1997.
OLIVEIRA JNIOR, H. A. Lgica Difusa: aspectos prticos e aplicaes. Rio de
Janeiro: Intercincia, 1999.
PETERSON, L. L.; DAVIE, B. S. Computer Networks - A Systems Approach. 3a
Edio ed., San Francisco: Morgan Kaufmann Publishers, 2003.
PRESSMAN, R. S. Engenharia de Software. So Paulo: Pearson Makron Books,
1995.
RIVERA-ILLINGWORTH, F.; CALLAGHAN, V.; HAGRAS, H. A Neural Agent Based
Approach to Activity Detection in AmI Environments. Proceedings of IEE
International Workshop on Intelligent Environments, 2005.
ROY, A.; BHAUMIK, S. K.; BHATTACHARYA, A.; BASU, K.; COOK, D. J.; DAS, S.
K. Location Aware Resource Management in Smart Homes. Proceedings of the
First IEEE International Conference on Pervasive Computing and Communications
(PerCom 2003), pp. 481- 488, 2003.
RUTISHAUSER, U.; SCHFER, A. Adaptive Building Automation - A multi-Agent
approach. Projeto de Pesquisa, Universidade de Cincias Aplicadas de Rapperswil
e Instituto de Neuroinformtica da Universidade de Zurique, Departamento de
Cincia da Computao, 2002.
127

SATYANARAYANAN, M. Pervasive Computing: vision and challenges. IEEE
Personal Communications, 2001.
SCHICKHUBER, G.; MCCARTHY, O. Distributed fieldbus and control network
systems. IEEE Computing & Control Engineering Journal, 8 (1), pp. 21-32, 1997.
SHARPLES, S.; CALLAGHAN, V.; CLARKE, G. A multi-agent architecture for
intelligent building sensing and control. International Sensor Review Journal,
1999.
SOARES, L. F.; LEMOS, G.; COLCHER, S. Redes de computadores - das LANs,
MANs e WANs s Redes ATM. Rio de Janeiro: Campus, 1995.
TANDLER, P.; STREITZ, N.; PRANTE, T. Roomware - Moving toward Ubiquitous
Computers. IEEE Micro, pp. 36-47, 2002.
THOMESSE, J. P. Fieldbuses and interoperability. Control Engineering Practice,
7, pp. 81-94, 1999.
TIBIRI, A. M. B. Um estudo sobre os sistemas de iluminao automticos e
os sistemas de controle distribudo para automao predial. So Carlos, SP:
Dissertao de Mestrado, EESC-USP, 2004.
TIBIRI, C. B. Deteco de usurios e suas interaes com o ambiente
utilizando rede de sensores. So Carlos: Dissetao de mestrado da EScola de
Engenharia de So Carlos da Universidade de So Paulo, 2007.
TOSHIBA. Neuron chip data book.
WEISER, M.; BROWN, J. S. The coming age of calm technology. Disponvel em:
<http://www.ubiq.com/hypertext/weiser/acmfuture2endnote.htm>. Acessado em 23
de outubro de 2008.
YOUNGBLOOD, G. M.; HOLDER, L. B.; COOK, D. J. Managing Adaptive Versatile
Environments. Proceedings of the 3rd IEEE International Conference on Pervasive
Computing and Communications, 2005.
ZADEH, L. A. Fuzzy Sets. Information and Control, 8, pp. 338-353, 1965.
ZHENG, Y.; AKHTAR, S. Networks for computers scientists and engineers. New
York: Oxford University Press, 2002.
ZIMMERMANN, H.-J. Fuzzy set theory and its applications. 4a Edio ed., Kluwer
Academic Publishers, 2001.

128

Glossrio
Bluetooth. Protocolo de comunicao sem-fio para transmisso de dados em
curtas distncias entre dispositivos fixos e mveis, criando uma rede de comunica-
o pessoal (PAN).
Cluster. Conjunto de computadores que trabalham em conjunto.
Data Mining. Processo de explorar grandes quantidades de dados procura
de padres consistentes, como regras de associao ou seqncias temporais.
Firewire. Interface serial para computadores pessoais e aparelhos digitais de
udio e vdeo que oferece comunicaes de alta velocidade e servios de dados em
tempo real.
Grafo. Representao grfica das relaes existentes entre elementos de da-
dos. Pode ser descrito num espao euclidiano de n dimenses como sendo um con-
junto V de vrtices e um conjunto A de curvas contnuas (arestas).
OmniORB. ORB CORBA de cdigo aberto para as linguagens C++ e Python.
Ontologia. Modelo de dados que representa um conjunto de conceitos dentro
de um domnio e os relacionamentos entre estes.
OSGI (Open Services Gateway Initiative). Plataforma de servios Java que
especifica um modelo de gerenciamento de ciclo de vida de aplicativos, um registro
de servios, um ambiente de execuo e mdulos.
129

PCI (Peripheral Component Interconnect - Interconector de Componentes
Perifricos). Barramento para conectar perifricos em computadores baseados na
arquitetura IBM PC.
PDA (Personal Digital Assistant Assistente Pessoal Digital). Computador
de dimenses reduzidas da ordem de grandeza da mo ou de um papel A6.
PostgreSQL. Sistema gerenciador de banco de dados objeto relacional desen-
volvido como projeto de software livre.
Proxy. Tipo de servidor que atende a requisies repassando os dados a ou-
tros servidores.
SOA (Service-Oriented Architecture) ou Arquitetura Orientada a Servio.
Arquitetura de software cujo princpio fundamental disponibilizao, na forma de
servios, as funcionalidades implementadas pelas aplicaes.
USB (Universal Serial Bus). Barramento serial de conexo rpida para aco-
plamento de perifricos ao computador.
Wi-Fi. Tecnologia de redes sem fios (WLAN) baseada no padro IEEE 802.11.
Zeroconf (Zero Configuration Networking). Conjunto de tcnicas que criam
de forma automtica uma rede IP sem necessitar de configurao ou servidores.
ZigBee. Tecnologia de redes sem fios baseada no padro IEEE 802.15.4 que
realiza a interligao de pequenas unidades de comunicaes de dados em peque-
nas reas.
(Sharples, Callaghan, & Clarke, 1999)

T Ese Alvaro MB Tibi Rica

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

T Ese Alvaro MB Tibi Rica

Transféré par

Droits d'auteur :

Formats disponibles

lvaro Messias Bigonha Tibiri

UMA ARQUITETURA DE SOFTWARE

Vous aimerez peut-être aussi