Escolar Documentos
Profissional Documentos
Cultura Documentos
Dissertação Bacnet e OPC
Dissertação Bacnet e OPC
LISBOA
SUPERIOR
DE
ENGENHARIA
DE
Orientadores:
Professor Coordenador A. Lus Osrio, ISEL - DEETC
Professor Coordenador Joo Calado, ISEL - DEM
Jri:
Presidente: Professor Coordenador Manuel Martins Barata, ISEL - DEETC
Vogais: Professor Coordenador Jos Manuel Igreja, ISEL - DEEA
Dezembro de 2010
Agradecimentos
Um agradecimento aos Professores A. Lus Osrio e Joo Manuel Calado pela orientao,
disponibilidade e apoio na realizao desta dissertao.
Ao Grupo Sousa Pedro, pelas reunies onde foram discutidas muitas ideias sobre o tema
desta dissertao.
OMRON e Schneider, pelo hardware disponibilizado e tambm aos Engenheiros
Nuno Verssimo e Joo Neto, da OMRON e aos Engenheiros Joo Rodrigues e
Fernando Ferreira, da Schneider pelo apoio na criao do demonstrador.
Ao ISEL Instituto Superior de Engenharia de Lisboa. Em especial, ao DEETC
Departamento de Engenharia de Electrnica e Telecomunicaes e de Computadores e
ao DEM Departamento de Engenharia Mecnica pela disponibilizao do espao e
dos meios electrnicos e informticos necessrios realizao desta dissertao.
Aos meus colegas do ISEL, pelo apoio e companheirismo demonstrado ao longo de
todo o meu percurso acadmico e pelas longas horas passadas nos laboratrios a discutir
solues, foram sem dvida de grande valor para o meu sucesso acadmico.
Aos meus amigos da Residncia de Estudantes Maria Beatriz, pelos longos anos de
amizade, companheirismo e convvio, pelos bons momentos vividos que para sempre
marcaro a minha vida e a minha forma de ser.
minha famlia, por todo o apoio dado ao longo destes anos. Em especial minha me,
um agradecimento do fundo do corao, porque sem o seu apoio incondicional no seria
possvel chegar onde cheguei.
A todos, que de uma forma directa ou indirecta, me ajudaram a concretizar esta dissertao
e me ajudaram nos momentos mais difceis do meu percurso acadmico.
iii
Resumo
Os edifcios esto a ser construdos com um nmero crescente de sistemas de
automao e controlo no integrados entre si. Esta falta de integrao resulta num caos
tecnolgico, o que cria dificuldades nas trs fases da vida de um edifcio, a fase de
estudo, a de implementao e a de explorao.
O desenvolvimento de Building Automation System (BAS) tem como objectivo
assegurar condies de conforto, segurana e economia de energia. Em edifcios de
grandes dimenses a energia pode representar uma percentagem significativa da factura
energtica anual. Um BAS integrado dever contribuir para uma diminuio
significativa dos custos de desenvolvimento, instalao e gesto do edifcio, o que pode
tambm contribuir para a reduo de CO2.
O objectivo da arquitectura proposta contribuir para uma estratgia de integrao que
permita a gesto integrada dos diversos subsistemas do edifcio (e.g. aquecimento,
ventilao e ar condicionado (AVAC), iluminao, segurana, etc.). Para realizar este
controlo integrado necessrio estabelecer uma estratgia de cooperao entre os
subsistemas envolvidos. Um dos desafios para desenvolver um BAS com estas
caractersticas consistir em estabelecer a interoperabilidade entre os subsistemas como
um dos principais objectivos a alcanar, dado que o fornecimento dos referidos
subsistemas assenta normalmente numa filosofia multi-fornecedor, sendo desenvolvidos
usando tecnologias heterogneas.
Desta forma, o presente trabalho consistiu no desenvolvimento de uma plataforma que
se designou por Building Intelligence Open System (BIOS). Na implementao desta
plataforma adoptou-se uma arquitectura orientada a servios ou Service Oriented
Achitecture (SOA) constituda por quatro elementos fundamentais: um bus cooperativo,
denominado BIOSbus, implementado usando Jini e JavaSpaces, onde todos os servios
sero ligados, disponibilizando um mecanismo de descoberta e um mecanismo que
notifica as entidades interessadas sobre alteraes do estado de determinado
componente; servios de comunicao que asseguram a abstraco do hardware
utilizado da automatizao das diversas funcionalidades do edifcio; servios de
abstraco de subsistemas no acesso ao bus; clientes, este podem ser nomeadamente
uma interface grfica onde possvel fazer a gesto integrada do edifcio, cliente de
vi
Resumo
coordenao que oferece a interoperabilidade entre subsistemas e os servios de gesto
energtica que possibilita a activao de algoritmos de gesto racional de energia
elctrica.
Abstract
Buildings are being constructed with a growing number of automatisms that are not
integrated between them. This miss of integration results in a technological chaos,
which creates difficulties in the three phases of a building life cycle, which are study,
assembling and management of a building.
The development of building automation systems (BAS) is strategic to answer comfort,
security and energy saving requirements. In large buildings energy can represent a
significant percentage of the years energetic bill. An integrated BAS is expected to
contribute for a significant decreased of costs, development, assembling and
management cost, and it might contribute to a reduction of CO2.
The goal of the proposed architecture is to create an integration strategy aiming to
establish an integrated control strategy of the building sub-systems (e.g. heating,
ventilation and air-conditioning (HVAC), lightning, security, etc.). To accomplish this
integrated control is needed the establishment of a communication strategy among the
involved sub-systems. One of the challenges to develop such a BAS is on how to
establish interoperability between sub-systems as a main goal, since the suppliers of the
referred subsystems are normally based on multi-vendors philosophy, being developed
using heterogeneous technologies.
Thus, the present work consisted in the development of a platform that was designated
as Building Intelligence Open System (BIOS). In the implementation of such platform
is adopted a Service Oriented Architecture (SOA) that is composed by four main
elements: a cooperative bus, named BIOSbus, implemented using Jini and JavaSpaces,
where all the services will be connected, providing a mechanism of discovery and a
mechanism that notifies the interested entities about changes in certain component;
communication services ensure the abstraction of the hardware used in the automation
of the several functionalities of the building; sub-system services that abstracts each
sub-system and make it usable in the bus; clients, this can be coordination services that
offers the interoperability between sub-systems, energy management services or userinterface.
Keywords: BAS, interoperability, building sub-systems, SOA
vii
ndice
1.
2.
Introduo ................................................................................................................. 1
1.1
Problema ............................................................................................................ 2
1.2
Motivao .......................................................................................................... 4
1.3
Estratgia ........................................................................................................... 5
1.4
1.5
2.1.1
2.1.2
2.2
3.
2.2.1
BACnet ..................................................................................................... 27
2.2.2
LonWorks ................................................................................................. 34
2.2.3
KNX ......................................................................................................... 42
2.2.4
2.2.5
2.2.6
OPC-UA ................................................................................................... 54
Bus cooperativo................................................................................................ 61
3.1.1
3.1.2
3.2
ndice
4.
3.3
3.4
3.5
3.6
3.7
Demonstrador................................................................................................... 71
4.1.1
4.1.2
4.1.3
Desenvolvimento ...................................................................................... 76
4.2
4.2.1
4.2.2
Servios de comunicao.......................................................................... 80
4.2.3
4.2.4
4.2.5
4.2.6
5.
6.
ndice de Figuras
Figura 1 - Edifcio e os seus diversos subsistemas ........................................................... 1
Figura 2 - Fases de um projecto e suas dificuldades ........................................................ 2
Figura 3 - Consumo energtico da UE-27 por sector [1] ................................................. 5
Figura 4 - Building Intelligence Open Service Bus (BIOSBus)....................................... 6
Figura 5 - Sistema completo de CCTV[3] ...................................................................... 10
Figura 6 - Sistema de deteco de incndio, Sinteso Siemens[6] .................................. 11
Figura 7 Nveis de funcionalidades [11]...................................................................... 25
Figura 8 - Exemplo de trs tipos diferentes de tecnologias LAN interligadas atravs de
routers [14] ..................................................................................................................... 29
Figura 9 - Exemplo de uma ligao IP [16].................................................................... 31
Figura 10 - Hierarquia/Segmentao da rede [13].......................................................... 37
Figura 11 - Arquitectura tpica de um n [13] ................................................................ 38
Figura 12 - Diagrama de blocos do processador Neuron 5000[23]................................ 41
Figura 13 - Exemplo de uma rede KNX[26] .................................................................. 44
Figura 14 - Topologia lgica [24]................................................................................... 45
Figura 15 - Especificao OPC UA [32] ........................................................................ 55
Figura 16 - Arquitectura de comunicao [33]............................................................... 56
Figura 17 - Nveis de funcionalidades ............................................................................ 59
Figura 18 - Arquitectura proposta .................................................................................. 60
Figura 19 - Exemplo gesto energtica .......................................................................... 66
Figura 20 - Sequncia exemplo gesto energtica.......................................................... 67
Figura 21 - Exemplo coordenao .................................................................................. 67
xi
xii
ndice de Figuras
Figura 22 - Sequncia exemplo coordenao ................................................................. 68
Figura 23 - CX-Programmer........................................................................................... 72
Figura 24 - Sistema de alarme de CO2 ........................................................................... 74
Figura 25 - TAC Vista Workstation ............................................................................... 76
Figura 26 - Arquitectura Fsica....................................................................................... 77
Figura 27 - Bancada de testes ......................................................................................... 77
Figura 28 - Arquitectura implementada.......................................................................... 78
Figura 29 - ICommunication .......................................................................................... 81
Figura 30 - UA wrapper que permite o acesso a servidores OPC DA [33].................... 83
Figura 31 - Sequncia de notificao de alteraes - Schneider .................................... 84
Figura 32 - Sequncia de notificao de alteraes - OMRON ..................................... 88
Figura 33 - IAvac............................................................................................................ 89
Figura 34 - ILighting ...................................................................................................... 91
Figura 35 - IEnergy ........................................................................................................ 92
Figura 36 - IElevators ..................................................................................................... 92
Figura 37 - IParkingCO2 ................................................................................................ 93
Figura 38 - Exemplo implementado ............................................................................... 95
Figura 39 - Diagrama sequncia exemplo implementado .............................................. 95
Figura 40 - Interface grfica ........................................................................................... 98
ndice de Tabelas
Tabela 1 Protocolos de automao [12] ...................................................................... 26
Tabela 2 - Modelo de 4 camadas do BACnet [15] ......................................................... 30
Tabela 3 - Objectos BACnet [18] ................................................................................... 32
Tabela 4 - Propriedades obrigatrias de um Device Object [18] ................................... 33
Tabela 5 - LonTalk e Modelo OSI[21] ........................................................................... 35
Tabela 6 - Formatos de enderear um n [21] ................................................................ 38
Tabela 7 - Comparao entre LonWorks, BACnet e KNX [9] [27] ............................... 48
Tabela 8 - Caractersticas chave OPC Classic e OPC UA [31] ...................................... 54
xiii
Lista de Acrnimos
BAS
BIOS
oBIX
PLC
DDC
SDK
API
SOA
OPC
OPC UA
OPC DA
AVAC
xv
1.
Introduo
Os edifcios de servios de grandes dimenses, como por exemplo hospitais, centro
comerciais ou aeroportos, requerem uma gesto contnua das suas instalaes. A
presso sobre a eficincia energtica e a evoluo tecnolgica levou a que a gesto deste
tipo de edifcios evolusse para sistemas de gesto centralizada, visando assegurar uma
gesto integrada dos seus subsistemas (iluminao, climatizao, etc.) que conduza a
redues nos custos de desenvolvimento, de operao e evoluo (Figura 1). Estes
custos podem ser, por exemplo, redundncia de hardware, energtico, manuteno ou
com pessoal para assegurar a superviso da infra-estrutura.
Neste captulo sero identificados os problemas que a gesto integrada de edifcios
oferece, bem como a estratgia adoptada para os resolver.
1 Introduo
1.1
Problema
Grande parte dos produtos existentes no mercado, para a gesto e controlo dos diversos
subsistemas, no disponibiliza um protocolo aberto que permita a cooperao, tornandose assim difcil a concepo de sistemas que permitam uma operao/gesto integrada
de subsistemas provenientes de diferentes fabricantes. Torna-se assim difcil a
implementao de arquitecturas cuja concepo seja suportada por sistemas
cooperativos, onde a interoperabilidade entre diferentes produtos, eventualmente
oriundos de diferentes fabricantes, um requisito que dever ser satisfeito. possvel
encontrar no mercado solues completas que prometem a gesto integrada de todos os
subsistemas do edifcio, ou outras que so dedicadas apenas a alguma rea especfica,
como por exemplo iluminao ou climatizao. Todavia, quando se verifica a
necessidade de dotar o edifcio de uma nova funcionalidade, nomeadamente com
recurso a equipamento de um fornecedor diferente daquele que se encontra instalado,
deparamo-nos com uma tarefa de difcil execuo ou mesmo impossvel, dado que
produtos de diferentes fornecedores usando tecnologia proprietria no conseguem
inter-operar. frequente encontrarmos associado a determinado subsistema informao
que seria de fundamental importncia para outro subsistemas, mas a dificuldade de
integrao resulta por exemplo na redundncia de hardware ou no desperdcio
energtico, o que se traduz em maiores custos de instalao, de gesto e de manuteno
da globalidade da infra-estrutura.
O desenvolvimento de um BAS apresenta uma srie de dificuldades, as quais podem ser
subdivididas nas 3 fases da vida de um projecto: estudo, implementao e explorao.
Na Figura 2 apresentado um resumo dessas dificuldades.
Estudo
Implementao
Escolha de fornecedores
Escolha de protocolos
Integrao de diferentes
subsistemas
Explorao
Inefecincia na
cooperao
Uso de vrias consolas de
controlo/monitorizao
1 Introduo
Na fase de estudo de um projecto necessrio efectuar a escolha dos fornecedores do
equipamento que permite dotar o edifcio de vrias funcionalidades automatizadas.
Todavia, esta escolha tem consequncias que se reflectem durante toda vida til do
edifcio, mesmo que os fabricantes afirmem que utilizam tecnologia aberta. Hoje em dia
existem vrias opes disponveis no mercado e a sua escolha depende da aplicao e da
topologia do edifcio, o que dificulta a tarefa de seleco dos fabricantes.
Na fase de implementao de um projecto, h necessidade de interligar subsistemas de
fabricantes diferentes. No entanto, se a escolha efectuada na fase anterior no foi bem
ponderada, a opo tomada pode inviabilizar ou dificultar a cooperao entre dois
subsistemas, nomeadamente se estiver em causa a utilizao de protocolos distintos.
A fase de explorao de um projecto corresponde sua implementao e
funcionamento. nesta fase que, como consequncia de opes erradas em fases
anteriores, se podem identificar eventuais ineficincias ao nvel da cooperao entre
subsistemas. Esta ineficincia poder influenciar negativamente os custos de explorao
da infra-estrutura, bem como a sua eficincia energtica. Alm que existem situaes de
falta de interoperabilidade que obriga ao uso de vrias consolas de controlo. No menos
grave a dificuldade de expanso de um sistema, pois fica dependente de muitos
factores caractersticos do equipamento utilizado e no comuns a equipamento idntico
de outro fabricante, o que torna por vezes a expanso difcil ou eventualmente
impossvel.
Os protocolos abertos tm como objectivo dar resposta a este tipo de problema, mas
estes ainda assentam em especificaes de baixo nvel. A definio destes protocolos
tem origem em comunidades cientficas e empresariais com culturas diversas, o que
origina dificuldades acrescidas em todas as fases previamente mencionadas.
Este projecto visa a procura de uma estratgia tecnolgica que permita assegurar a
desejada interoperabilidade entre a diversidade de subsistemas utilizados na
automatizao de um edifcio, tornando-o independente de fornecedores ou protocolos
utilizados. Cada um destes subsistemas visa dotar o edifcio de um conjunto de
funcionalidades que pode ser potenciada atravs de uma gesto integrada.
Um exemplo do valor acrescentado associado a um edifcio inteligente, o facto de
estarem reunidas as condies para alcanar uma eficiente gesto de energia. comum
1 Introduo
que edifcios de grandes dimenses tenham uma potncia elctrica contratada com o
fornecedor de energia elctrica, de tal forma que, se o valor contratado for ultrapassado
(p. e. em apenas um nico intervalo de 15m), o mximo valor atingido constituir o
novo valor de potncia elctrica contratada, provocando uma indexao do tarifrio a
um escalo superior. Um dos momentos mais crticos o incio da manh, com o
arranque simultneo de diversos equipamentos (elevadores, climatizao, equipamentos
industriais, etc.), verificando-se valores elevados na potncia tomada pelo edifcio e
consequentemente valores elevados no consumo de energia elctrica. Recorrendo
gesto integrada do edifico inteligente ser possvel fazer uma gesto de energia por
prioridades, atravs do cruzamento de dados dos diversos subsistemas. Desta forma
possvel garantir que a potncia elctrica contratada no ultrapassada. Uma possvel
estratgia para o conseguir seria, usar o sistema de CCTV, o sistema de controlo de
acessos ou atravs de identificao de horas de ponta, como forma de identificar a
chegada de um elevado nmero de pessoas ao edifcio. Esta prioridade de escoamento
rpido das pessoas, dever resultar numa prioridade de fornecimento de energia ao
sistema de elevadores e escadas rolantes enquanto reduzida as necessidades
energticas do sistema de climatizao. Esta tcnica denominada de deslastre de
cargas.
Um sistema de gesto integrada em que os subsistemas do edifcio inteligente
colaborem e comuniquem de forma eficiente vital para ter acesso a toda a informao
do edifcio, para por exemplo poder inclui-la no algoritmo de balanceamento de carga
elctrica. A interoperabilidade aqui chave sendo que s desta forma se consegue uma
gesto eficiente da energia elctrica e de todos os demais recursos do edifcio.
1.2
Motivao
1 Introduo
3. Atravs da optimizao da gesto integrada do edifcio ser possvel alcanar uma
reduo significativa dos correspondentes consumos de energia elctrica.
O nvel de automao nos edifcios tem aumentado constantemente ao longo dos anos
[2]. Tal como abordado no captulo anterior, tem que existir cooperao entre os
diversos subsistemas de forma a potenciar a eficincia energtica. A automao de
determinado subsistema tem que estar preparada para a interagir de forma automtica
com os demais intervenientes de um edifcio.
1.3
Estratgia
Para a resoluo deste problema prope-se uma soluo de alto nvel que se abstraia das
camadas de automao. Adoptou-se uma filosofia SOA (Service Oriented
Architectures), em que se prev um bus lgico atravs do qual os diversos servios
comunicam. Esses servios podem ser representantes de cada um dos subsistemas ou
mesmo servios proporcionando funcionalidades de gesto e controlo. Na Figura 4
encontra-se uma abordagem introdutria ao que ser no futuro a lgica do sistema.
1 Introduo
1 Introduo
edifcios, este tipo de sistema possibilita que, os recursos distribudos pelos diversos
subsistemas sejam livremente acedidos beneficiando a eficincia de todos os
intervenientes do sistema. No essencial os sistemas cooperativos so desenvolvidos de
raiz (ou adaptados) para a cooperao, sendo que o desenvolvimento de novos
servios (ou automatizao de novos processos) no dever requerer o envolvimento
dos fornecedores dos sistemas existentes, com os quais o novo sistema/servio ter que
integrar. Esta perspectiva evolutiva para um edifcio integrado, requer o
desenvolvimento de uma infra-estrutura aberta, inteligente e capaz de associar, numa
lgica Plug-and-play, novos servios (sistemas/aplicaes) na automatizao de
novos processos.
1.4
Notao utilizada
Ao longo do texto desta dissertao surgem termos em ingls em situaes em que sua
traduo para portugus no reflecte o seu real significado, ou por serem termos que j
so universalmente aceites. Tal situao acontece porque a documentao existente
sobre este tema , na sua maioria, publicada em lngua inglesa e, sempre que possvel,
so utilizadas tradues que se consideram apropriadas ou que j se encontram
enraizadas na lngua portuguesa. Estes termos so apresentados em caracteres itlicos.
Para evitar a repetio de expresses tcnicas longas, que poderiam tornar fastidiosa a
leitura desta dissertao, so utilizados acrnimos ao longo do texto. A correspondncia
entre os termos tcnicos e os seus respectivos acrnimos feita no incio deste documento,
sendo explicado o seu significado na primeira ocorrncia do respectivo acrnimo no texto.
Todas as referncias bibliogrficas utilizadas ao longo da dissertao so evocadas entre
parntesis recto e so apresentadas no final desta dissertao.
1.5
Estrutura da dissertao
1 Introduo
implementao, incluindo o desenvolvimento do demonstrador e concretizao da
arquitectura proposta.
2.
Estado da Arte
Neste captulo so reunidas as caractersticas e aspectos relevantes de inovao na rea
da gesto integrada de edifcios inteligente. Comea-se por enquadrar o problema
descrevendo as caractersticas que definem um edifcio e o que implica a sua gesto,
identificando-se depois os desenvolvimentos tecnolgicos para a rea em questo.
2.1
Enquadramento do problema
2.1.1
2.1.1.1 Segurana
2.1.1.1.1 CCTV
Um sistema de segurana de pessoas e bens baseado num circuito fechado ou circuito
interno de televiso (CCTV do ingls Closed-circuit Television), um sistema de
televiso que distribui sinais provenientes de cmaras localizadas em locais especficos,
10
2 Estado da Arte
para um ou mais pontos de visualizao cujo objectivo mais comum fornecer
segurana atravs da vigilncia.
Os sistemas CCTV encontram-se em evoluo, quer em termos de tecnologia, quer em
termos aplicacionais. Em termos tecnolgicos, hoje possvel dispor o sistema em
formato digital, usufruindo das mais-valias da era digital, como por exemplo a
facilidade de armazenamento, bem como a qualidade de imagem. Em termos
aplicacionais o circuito interno de televiso j no apenas um sistema simples de
monitorizao visando apenas a segurana, tendo evoludo para reas como o
reconhecimento facial, reconhecimento de matrculas, entre outros. Na Figura 5 pode
ser observado algum equipamento especfico de sistemas CCTV.
12
2 Estado da Arte
importante que este subsistema seja cooperante pois, por exemplo em caso de
incndio e dependendo de algumas excepes de segurana, o sistema deve permitir
livre acesso para que o edifcio ou zona possa ser evacuada com maior facilidade.
14
2 Estado da Arte
2.1.1.4.1 PC
Para edifcios com alguma dimenso comum existir uma sala de controlo que tem
geralmente mais que uma consola (PC) para monitorizar o edifcio. Essas consolas
podem utilizar software prprio ou basear-se em aplicaes Web, por exemplo
aplicaes acessveis atravs de um Web browser. Este controlo pode ser efectuado
atravs da intranet ou mesmo internet.
2.1.1.4.2 PDA
Pode-se ter o melhor de dois mundos com o PDA, pois este pode ter uma aplicao que
se liga directamente ao sistema de superviso e controlo do edifcio simulando as
funcionalidades do LCD, ou ter acesso a diversos sistemas de controlo atravs da
internet.
2.1.1.5 Elevadores
Para um edifcio que tenha uma rede de elevadores com alguma dimenso torna-se
relevante controla-la a partir de um ponto central. Desta forma, ser possvel realizar
remotamente um conjunto de operaes como por exemplo bloquear um elevador,
enviar um elevador para determinado piso, identificar em tempo real o estado de um
elevador (e.g. em que piso se encontra, se existe avaria).
Este subsistema pode cooperar com outros subsistemas de diversas formas. Por
exemplo, podemos ter interaco com o sistema de controlo de iluminao de tal forma
que um pouco antes de serem abertas as portas do elevador podem ser ligadas as luzes
do piso de chegada. Outro possvel cooperao com o sistema de controlo de acessos,
podendo este dar ou no acesso a determinado piso.
atempadamente
eventuais
anomalias
evitando
assim
consumos
16
2 Estado da Arte
certas empresas no existe a necessidade de ter guas quentes sanitrias durante a poca
de vero.
Na rea dos edifcios a eficincia energtica , hoje em dia, uma das preocupaes
principais , da que seja usual os seus componentes terem objectivos de superviso dos
consumos de energia conducente sua reduo.
2.1.2
18
2 Estado da Arte
2.1.2.2.1 Porqu um SA
Quais as razes que levam a escolher um sistema aberto em vez de um proprietrio? No
que aos edifcios diz respeito, ser o sistema aberto mais eficiente, proporcionando um
melhor desempenho no controlo da instalao ou um melhor nvel de conforto aos
ocupantes? No necessariamente, um sistema proprietrio poder apresentar nveis de
desempenho to bons ou melhores que uma soluo aberta equivalente. Isso leva as
pessoas a fazerem juzos errados tentando encontrar nas solues abertas
funcionalidades e desempenhos no disponveis na soluo proprietria equivalente.
Todavia, existem inmeras razes para que se escolha um sistema aberto em vez de um
proprietrio: oferta competitiva, instalao e manuteno consistente, integrao de
sistemas
interoperabilidade,
aquisio
de
informao
permutabilidade
Cada sistema proprietrio tem as suas normas de instalao, bem como requisitos de
expanso e fornecimento de produtos. Um SA tem normas de instalao consistentes,
ou seja, utiliza normas bem conhecidos e documentados, sem que exista dependncia do
tipo de edifcio ou dos fabricantes dos equipamentos que proporcionam uma gesto
tcnica centralizada do edifcio dito inteligente.
Manuteno consistente
20
2 Estado da Arte
Uma outra abordagem relativamente ao porqu de escolher um sistema aberto ser
apresentada mais frente no Captulo 2.1.2.2.3, onde ser efectuada uma anlise de
requisitos para um Building Automation System (BAS) sustentvel.
As arquitecturas dos sistemas de gesto tcnica centralizada de edifcios baseadas em
solues abertas parecem ser a soluo para ultrapassar as dificuldades da automao de
edifcios, conduzindo a solues economicamente mais vantajosas quer do ponto de
vista do investimento inicial, quer do ponto de vista dos custos de explorao (total cost
of ownership TCO). Todavia, embora existam tecnologias e solues declaradamente
abertas que no entanto so implementadas de forma proprietria. Por isso ao escolher
uma tecnologia ou soluo aberta, h que assegurar que ela suporta todos o requisitos
referidos no Captulo 2.1.2.2.2.
2.1.2.2.2 Requisitos
As solues abertas so economicamente/financeiramente mais vantajosas que as
solues proprietrias. Mesmo nas situaes em que o investimento inicial
semelhante, as solues abertas apresentam custos de explorao e manuteno
tendencialmente mais baixos. No domnio da gesto tcnica centralizada de um edifcio
dito inteligente, a opo por uma soluo baseada em tecnologias abertas, cria a
expectativa de um sistema que fao o controlo total do edifcio (End-to-End) e no uma
soluo que apenas assegura o controlo de alguns subsistemas. Para responder a estes
requisitos, o sistema aberto tem que responder s necessidades funcionais dos edifcios,
combinar sistemas de fabricantes diferentes, proporcionando opes de escolha sobre os
produtos e induzindo requisitos para a competitividade ao nvel do preo. So estes os
objectivos a alcanar com a implementao de uma soluo aberta, os quais se podem
enumerar da seguinte forma: aberto, interopervel, multi-fornecedor e soluo total [9].
Aberto
A tecnologia tem que estar disponvel a qualquer fabricante para que este desenvolva
produtos (hardware ou software) independentes ou para fazerem parte de uma soluo
completa, assegurando de uma forma relativamente fcil a interoperabilidade com
produtos de outros fornecedores.
Uma abordagem que tenha aplicao em todos os nveis de um edifcio, desde sensores
a software e em todos os subsistemas. Pretende-se assim, uma soluo global e
integrada para o sistema da gesto tcnica do edifcio, centralizada do ponto de vista de
operao, que para alm de assegurar todas as funcionalidades inerentes s
especificaes da automao do edifcio, possuindo ainda funcionalidades de gesto e
manuteno do prprio sistema, como por exemplo metodologias de tolerncia a falhas
da infra-estrutura fsica e eventualmente instrumentao de software.
Uma tecnologia para ser considerar aberta tem que responder a todos os requisitos
enumerados anteriormente. Existem algumas tecnologias ditas abertas mas que no
conseguem responder a todos os objectivos, sendo exemplo:
Empresas que indicam que a sua tecnologia proprietria aberta. Estas
empresas fornecem o protocolo e a definio da arquitectura a terceiros, e at
podem oferecer certificao. E assim sendo, a sua tecnologia est disponvel a
qualquer fabricante para que se possa desenvolver produtos compatveis com
essa tecnologia especfica. No entanto, esta tecnologia no pode ser
22
2 Estado da Arte
considerada aberta, dado que apenas a prpria empresa controla a definio
do protocolo.
Seleccionar uma soluo proprietria que garanta interoperabilidade entre
AVAC e o sistema de segurana ou AVAC e o controlo de iluminao, no
considerado um sistema aberto, pois a sua interoperabilidade est limitada.
Por exemplo a utilizao do protocolo Modbus. Os fabricantes podem aplicar
Modbus para vrios produtos, e possvel utilizar produtos Modbus de vrios
fabricantes, mas isso no suficiente para ser considerado sistema aberto,
pois no garante uma soluo completa.
Praticamente todas as solues proprietrias so solues completas, mas
como so especficas de um fabricante no podem ser consideradas solues
abertas.
Resumindo os pontos-chave, um sistema aberto tem que ser uma soluo completa
oferecida por vrios fornecedores, que usa um tipo de comunicao que possibilite a
interaco dos diversos dispositivos envolvidos.
Uma soluo que se considera vivel e economicamente mais vantajosa, o BAS ser
um sistema concebido no mbito deste paradigma emergente, ou seja, ser concebido
com base em tecnologia aberta. Tendo em conta os vrios factores j enumerados faz-se
agora uma abordagem focando os requisitos de sustentabilidade a que estes conseguem
responder:
Continua disponibilidade da maioria dos componentes do sistema
A nica forma de assegurar que o sistema cumpre este requisito, passa pela
possibilidade de no depender de apenas um fabricante. Todavia, para poder recorrer a
vrios fabricantes existe a necessidade de o sistema ser definido sobre standards de
comunicao, aplicao e gesto. Para garantir coerncia na definio e utilizao
desses standards necessrio criar uma associao, de modo a, por exemplo, certificar
os produtos, garantido que o fabricante produz produtos que vo ser interoperveis com
24
2 Estado da Arte
os restantes. Dois exemplos que sero abordados mais frente so o LonWorks que
certificado pela LonMark International Association e o BACnet que certificado pelos
BACnet Testing Laboratories.
Disponibilidade da informao
Toda a informao relacionada com os standards dos BAS, protocolos, rede, algoritmos
de controlo, documentao, etc., necessita estar disponvel para todos. Depende da
abordagem de cada associao, mas existem certificaes ou mesmo formao em
escolas, relativamente a estes standards (Sistemas Abertos).
Expanso do BAS
26
2 Estado da Arte
Protocolo
Patrocinador
BACnet
LonTalk.
Echelon Corp.
KNX
Konnex
Modbus
Modicon
ZigBee
ZigBee Aliance
IBIbus
CAB
Canada
X-10
X-10 Corp.
Smart House
CEBus
EIA
University of Michigan
University of Technology
Time-triggered protocol
2.2.1 BACnet
2.2
Tecnologias em edifcios
Na primeira parte deste captulo apresentado o estudo sobre os trs principais sistemas
abertos usados pela indstria, BACnet, LonWorks e KNX, sendo enumeradas as
caractersticas chave de cada um destes sistemas, permitindo efectuar a sua comparao.
Deste estudo resultou um artigo cientfico que foi apresentado na edio de 2010 da
International Conference on Theoretical, Experimental and Applied Signal and Image
Processing Techniques and Systems (IWSSIP'10), realizada no Rio de Janeiro, Brasil.
Alm deste estudo, so ainda analisados dois projectos com interesse para esta
dissertao o Open Building Information eXchange (oBIX), e o Open Process Control
Unified Architecture (OPC-UA).
2.2.1
BACnet
O BACnet (Building Automation and Control Networking Protocol) foi pensado para
responder s necessidades de automao de um edifcio, fosse ele de pequenas ou
grandes dimenses.
O seu desenvolvimento iniciou-se em 1987 por parte da American Society of Heating,
Refrigerating
and
Air-Conditioning
Engenieers
(ASHRAE),
tendo
este
27
28
2 Estado da Arte
2.2.1.2 Comunicao
Para que dois subsistemas de um edifcio inteligente comuniquem entre si, existe a
necessidade de uma troca de mensagens entre eles, em que para alm do contedo da
mensagem ser necessrio ter em conta a forma como enviada. De modo a que dois
tipos de subsistemas comuniquem entre si, foram definidos no standard seis protocolos
que tratam essa comunicao, onde se inclui o Ethernet, o ARCNET, o MasterSlave/Token-Passing (MS/TP), o LonTalk, o Point-To-Point (PTP) e mais recentemente
o Internet Protocol (IP). Cada um destes protocolos tem as suas caractersticas e
utilidades especficas como podemos verificar a seguir.
Numa instalao que utiliza o standard BACnet, so utilizados vrios protocolos de
comunicao, estabelecendo-se diversas camadas no sistema. assim possvel efectuar
a distino, por exemplo, entre uma comunicao entre controladores de diferentes
subsistemas e uma comunicao entre os componentes de campo, como os sensores e os
actuadores. Consegue-se assim efectuar a distino entre comunicaes consideradas
crticas e no crticas, ou seja, as primeiras necessitam de uma maior eficincia de
comunicao enquanto as segundas apresentam requisitos de comunicao mais
flexveis. assim possvel reduzir custos sem comprometer desempenhos. Na Figura 8
encontra-se um exemplo de 3 tipos diferentes de tecnologias LAN interligadas atravs
de routers.
2.2.1 BACnet
Figura 8 - Exemplo de trs tipos diferentes de tecnologias LAN interligadas atravs de routers [14]
29
30
2 Estado da Arte
Camadas Equivalentes
Camadas BACnet
OSI
Aplicao
Rede
Ethernet
MS/TP
PTP
EIA-485
EIA-232
Ligao
LonTalk
Ethernet
ARCNET
Fsica
2.2.1.3.1 Ethernet
A Ethernet uma tecnologia de ligao para redes locais (LAN), estando definida como
um standard internacional (ISO 8802-3), sendo das tecnologias LAN a mais utilizada
hoje em dia. Esta tecnologia suporta vrios tipos de meios fsicos, nomeadamente cabos
UTP, fibra ptica e tecnologia wireless. Consegue velocidades mais elevadas
actualmente 10 Gbps mas podendo ir a velocidades superiores, o que a torna
especialmente adaptada para ser utilizada na comunicao entre sistemas ou interfaces
de controlo.
2.2.1.3.2 MS/TP
MS/TP uma tecnologia de muito baixo custo, mas tambm de baixa velocidade, entre
os 9.6Kbps e os 76Kbps. Esta tecnologia um standard ANSI e est especificada na
norma EIA-485, utilizando como meio fsico o RS-485. Pode ser implementada num s
chip, o que aliado ao seu baixo custo faz desta tecnologia um protocolo de eleio para
efectuar a comunicao entre componentes de campo.
2.2.1.3.3 BACnet/IP
Devido ao uso em massa das redes IP foi necessrio redefinir em 1999 o Standard de
modo a que este suportasse o IP. Este est totalmente integrado na camada de Rede, o
que permite que a comunicao entre componentes BACnet seja efectuada sobre IP.
Posto isto, sabendo o endereo IP do componente com quem se quer comunicar,
possvel utilizar a internet como meio de comunicao entre componentes, como se
pode verificar na Figura 9.
2.2.1 BACnet
31
32
2 Estado da Arte
2.2.1.4.2 Propriedades
O standard BACnet identifica 123 propriedades para caracterizao dos objectos,
existindo 3 propriedades que tm de ser definidas em todos os objectos; Objectidentifier, Object-name, e Object-type. Um subgrupo de propriedades especfico para
cada tipo de objecto, sendo algumas de especificao obrigatria e outras opcionais
[19]. Na Tabela 4, esto presentes as propriedades obrigatrias de um Device Object.
Algumas propriedades so necessariamente implementadas seguindo as especificaes,
mas outras podem ser definidas pelo fabricante. Todas estas propriedades podem ser
lidas na rede, podendo ou no ser escritas, dependendo da definio da propriedade.
BACnet permite que os fabricantes adicionem propriedades ou eventualmente objectos.
Todavia, propriedades proprietrias podem resultar em falhas na interoperabilidade.
2.2.1 BACnet
2.2.1.4.3 Servios
Os servios so o mecanismo que o BAS usa para aceder s propriedades e efectuar
aces sobre os objectos BACnet. a forma como: um dispositivo BACnet pede
informao a outro dispositivo; executa aces sobre outros dispositivos, atravs das
propriedades; comunica eventos para outros objectos. O nico servio obrigatrio para
qualquer dispositivo o Read-property. Existem no total 32 servios Standard.
Para o utilizador ou instalador, a implementao do servio -lhe completamente
transparente, dizendo apenas respeito aos fabricantes. Para implementar um BAS ser
necessrio conhecer que objectos e servios so suportados e quais os dispositivos. Essa
informao poder ser encontrada no protocolo de conformidade de cada dispositivo
(Protocol Implementation Conformance Statement - PICS) [19].
2.2.1.5 PICS
O PICS basicamente uma lista de funcionalidades que um dispositivo suporta. Esta
lista de objectos est presente no dispositivo, bem como, os pedidos de servios que este
pode receber e enviar. til comparar os requisitos do BAS com o PICS de modo a
averiguar se este responde s necessidades [19].
33
2.2.2
LonWorks
O sistema LonWorks foi desenvolvido pela Echelon Corp. em 1990. Mais tarde, em
1999, o seu protocolo de comunicao LonTalk torna-se um ANSI/EIA standard 709,
que posteriormente actualizado em 2002, sendo esta a verso mais actualizada [9].
O sistema LonWorks um sistema de rede do tipo event-triggered. 3 Sendo composto
pelo protocolo de comunicao, LonTalk, por um controlador dedicado, Neuron Chip, e
por ferramentas de gesto da rede [13].
2.2.2.1 LonMark
Em 1994 foi criada a LonMark, entidade autorizada para certificar, formar e fazer a
promoo da interoperabilidade entre os diversos fabricantes. Em 2005, LonMark, j
tinha certificado 600 dispositivos [20].
2.2.2.2 LonTalk
O LonTalk o nico protocolo suportado pelo sistema LonWorks, que permite a
comunicao, entre os vrios dispositivos existentes na rede LonWorks. Trata-se de um
protocolo completo que implementa as sete camadas do modelo OSI.
controlo.
34
2.2.3 KNX
Camada
OSI
Objectivo
Servios prestados
CPU*
Aplicao
Compatibilidade
a nvel das
aplicaes
APP
6 Apresentao
Interpretao da
informao
NET
Sesso
Aces remotas
NET
Transporte
NET
Rede
Endereamento
de destino
NET
MAC
MAC
XCVR
Ligao
Meios de acesso
Fsica
Meios fsicos
35
36
2 Estado da Arte
2.2.2.2.3 Endereamento
O endereamento feito de forma hierrquica. No topo dessa hierarquia encontra-se o
domnio (Domain). Por exemplo, se so implementadas duas aplicaes diferentes sobre
o mesmo meio comunicao, podem ser usados dois domnios para manter essas
aplicaes completamente separadas. O tamanho da identificao (ID) destes domnios
pode ir desde 0 a 48 bits, sendo que o dado mais pequeno pode ser includo em qualquer
das partes (frames) das mensagens, mas tem que ser suficientemente grande para que
no existam interferncias. Existe a possibilidade de um n (Node) (Captulo 2.2.2.2.4)
ser membro de dois domnios.
No segundo nvel da hierarquia encontra-se a subnet. Podem existir at 255 subnets por
domnio. Uma subnet um grupo lgico de ns. Um router inteligente opera ao nvel da
subnet, determinando de forma mais precisa o encaminhamento das mensagens.
O terceiro nvel de endereamento o n. Podem existir 127 ns por subnet. O que
perfaz 255 x 127 = 32.385 ns que podem estar num determinado domnio. Um n pode
servir mais que um domnio, permitindo, por exemplo, que um sensor transmita os seus
outputs para vrios domnios.
Os ns, podem tambm ser agrupados, podendo existir 256 grupos num determinado
domnio. Um grupo pode ter ns pertencentes a mltiplas subnets desde que dentro do
mesmo domnio. So permitidos no mximo 64 ns que usem servios do tipo
acknowledged (Captulo 2.2.2.2.5) e um nmero ilimitado de ns que utilizem servios
apenas informativos. Um n pode pertencer a 15 grupos. O endereamento ao nvel do
grupo reduz o tamanho do endereo que tem que ser transmitido com cada mensagem e
subdividindo a rede consegue-se aliviar o trfego de rede [21]. Toda esta hierarquia
apresentada na Figura 10.
2.2.3 KNX
Cada n possui um ID nico de 48 bits (Neuron ID) que lhe atribudo no momento da
sua fabricao. Este endereo geralmente apenas utilizado na instalao e
configurao da rede, mas pode ser utilizado por aplicaes que pretendam saber o
nmero de srie de determinado produto.
O meio de comunicao utilizado pelo n no afecta a sua forma de endereamento. Tal
como um domnio pode ter na sua composio, vrios meios de comunicao.
Na Tabela 6 esto presentes os 5 formatos de endereamento de um n.
Endereamento
Ns endereados
Domnio, Subnet = 0
Todos os ns do domnio
Domnio, Subnet
Todos os ns da subnet
Domnio, Subnet, N
N lgico especfico
Domnio, Grupo
Todos os ns do grupo
N fsico especfico
37
38
2 Estado da Arte
Tabela 6 - Formatos de enderear um n [21]
2.2.2.2.4 N
As redes LonWorks so constitudas por dispositivos de controlo inteligente, os ns,
que se servem do protocolo comum, LonTalk, para comunicar entre si. A "inteligncia"
dos referidos ns providenciada pelos Neuron Chips (Captulo 2.2.2.3), os quais
permitem a implementao do protocolo LonTalk e a execuo das funes de controlo.
Os ns (sensores inteligentes - de temperatura, de presso, etc. -, actuadores, interfaces
para o operador - PCs, displays, etc.) possuem uma interface fsica que permite a sua
ligao ao meio de transmisso e incluem processamento local e recursos de rede,
podendo ser ligados a dispositivos locais (I/O). Estes ltimos permitem que cada n
processe os dados de entrada, recebidos dos sensores, e os dados de sada para os
actuadores. Na Figura 11 encontra-se a arquitectura tpica de um n.
2.2.3 KNX
Os recursos computacionais permitem que cada n processe os dados, enquanto os
recursos de rede possibilitam a sua interaco com outros ns existentes na rede. Os ns
so programados para enviar mensagens a outros ns, de acordo com os eventos
(mudanas de estado) detectados. Os endereos dos destinatrios das mensagens de
notificao so codificados numa tabela interna do Neuron Chip, atravs de uma
ferramenta de configurao. Os dados enviados so formatados em variveis de rede,
denominadas por SNVTs (Standard Network Variable Types) (Captulo 2.2.2.2.6) [22].
39
40
2 Estado da Arte
se necessita de uma maior velocidade de transmisso ou para o envio de uma grande
quantidade de dados.
O LonTalk fornece um servio de deteco de mensagens duplicadas, pelo que
normalmente apenas entregue uma mensagem, mesmo que sejam enviados duplicados.
As duplicaes ocorrem, por exemplo, quando um acknowlege ou uma resposta se
perde. Apenas para o servio REQUEST, dado que a resposta incluiu informao, que
a mensagem entregue mais que uma vez. A capacidade de deteco de mensagens
duplicadas conseguida atravs da memorizao das transaces recebidas em cada n
[21].
2.2.3 KNX
aplicaes do n. Esta separao permite salvaguardar qualquer impacto
negativo da aplicao na rede e vice-versa;
11 pinos de I/O;
41
42
2 Estado da Arte
2.2.3
KNX
2.2.3 KNX
2.2.3.3 Comunicao
Os componentes dividem-se basicamente em 3 classes; alimentadores, sensores (os que
emitem ordens) e actuadores (os que executam ordens). Apenas os sensores e
actuadores so elementos activos. A comunicao entre os actuadores e sensores feita
directamente entre os mesmos.
43
44
2 Estado da Arte
2.2.3 KNX
RF, (Radio frequency, 868 MHz)
Este meio de comunicao existente em praticamente todos os edifcios pode ser usado
em conjunto com o KNX/IP, que permite fazer tunnelling das mensagens KNX
encapsulando-as em mensagens IP.
Endereamento
45
46
2 Estado da Arte
2.2.4
BACnet
KNX
1995 ASHRAE-135
2004 EN 50090
Histria
Arquitectura de rede
Bottom Up
Top Down
Bottom Up
Protocolo de comunicao
nico
Peer-to-Peer
Gesto de rede
Ferramentas de gesto
geralmente fornecidas pelo
fabricante
47
48
2 Estado da Arte
Independente do processador
Neuron C (Linguagem)
Independente da linguagem
Apenas 1,2,3 e 7
Apenas 1,2,3,4 e 7
BTL
KNX
Routers, dispositivos de
superviso, gateways, AVAC e
no-AVAC
Maioritariamente dispositivos
de controlo de instalaes mais
reduzidas; Fraca oferta em
produtos AVAC
Certificao
LonMark
Dispositivos
Routers, web servers, gateways,
NICs, AVAC e no-AVAC
Meios de comunicao
nico protocolo: LonTalk
Par entranado - 78.1kbps ou
1.25Mbps
Powerline - 4.8kbps
Wireless, fibra ptica,
infravermelhos esto publicados
mas pouco utilizados
Internet
LonWorks/ IP
BACnet/IP
BACnet/WS
KNX/IP
XML
Tabela 7 - Comparao entre LonWorks, BACnet e KNX [9] [27]
2.2.4.1 Rede
Uma diferena bastante significativa o facto de o LonWorks utilizar apenas um
protocolo de comunicao, LonTalk, enquanto o BACnet permite a utilizao de 6 tipos
diferentes de protocolos. Existem vantagens e desvantagens, uma vez que desta forma o
BACnet consegue responder melhor s necessidades especficas do edifcio, mas o facto
de existirem vrios protocolos tambm pode ser gerador de confuso, dado que
dispositivos que implementam protocolos distintos no conseguem comunicar
directamente. Dai surge a vantagem do LonWorks pois, criando uma srie de regras que
se aplicam a todos os dispositivos, torna-se mais simples a interoperabilidade.
Como se pode verificar na Figura 7, tanto o LonWorks como o KNX direccionam-se
mais para o nvel de campo, respondendo a necessidades de controlo, bottom up,
enquanto o BACnet tem como nfase o sistema de gesto, top down. O que acontece
em algumas situaes que o sistema de gesto entre os diversos subsistemas
implementado atravs de BACnet e os nveis de campo so tratados por protocolos
como o LonWorks, KNX, ModBus, etc.
2.2.4.3 Mercado
Tanto o LonWorks como o BACnet apresentam uma desvantagem de mercado em
relao ao KNX, pois ambos tm um nmero muito baixo de tcnicos certificados. Para
esta situao contribui o facto dos protocolos referidos apenas serem utilizados em
edifcios de grandes dimenses com recurso a tcnicos com elevada formao.
O KNX tem como vantagem, em relao aos outros dois protocolos, o preo, pois tanto
BACnet como LonWorks tm custos de implementao mais elevados [27].
49
50
2 Estado da Arte
2.2.5
O Open Building Information eXchange (oBIX) [29] foi desenvolvido para possibilitar a
comunicao entre as vrias componentes mecnicas e elctricas de um edifcio, bem como
com as prprias aplicaes empresarias.
2.2.5.1 Modelo
oBIX fornece um modelo flexvel para descrever os dados e as operaes disponveis no
servidor, sendo tudo representado atravs de objectos. Esses objectos tambm so
usados para descrever os tipos de dados (classes) e operaes (assinaturas dos mtodos).
A flexibilidade do oBIX baseia-se na possibilidade de definir qualquer tipo de objecto e
suporte de subtipos (is-a) e composio (has-a).
oBIX segue uma abordagem RESTful (Representational State Transfer). Este tipo de
abordagem baseia-se em recursos que compartilham uma interface uniforme e um
conjunto muito restrito de operaes sobre esses recursos. Esta abordagem considera o
protocolo HTTP (World Wide Web), onde apenas os comandos GET, PUT e POST so
usados para aceder aos recursos. Isto tambm verdade para os servios oBIX, pois
apenas trs tipos de pedidos de rede so definidos no nvel dos WebService (WS). Os
dois primeiros tipos so de leitura (read - aplicvel a qualquer objecto) e de escrita
(write - para objectos writable). Para operaes mais complexas, alm das bsicas "get"
e "set", existe a possibilidade de definir operaes prprias, em que estas podem ser
definidas ao nvel do oBIX. Para invocar essas operaes um terceiro tipo de pedido
fornecido (invoke). A abordagem RESTful do oBIX permite suportar dois tipos de
protocolo de binding, um simples HTTP REST binding e um SOAP binding.
O Naming em oBIX realizado de duas formas complementares. Primeiro, cada
objecto pode ter um nome (name). Segundo, pode ser atribudo um URI (href) a cada
objecto, sendo isto necessrio para que um objecto possa ser referenciado a partir do
exterior, como forma de se poder candidatar a qualquer pedido de rede (read, write ou
invoke).
2.2.5.2 Objectos
O objecto raiz especifica uma srie de atributos obrigatrios (e.g. name), que so
herdadas por todos os objectos filho. No modelo de dados esto definidos vrios tipos
primitivos, os quais so boolean, integer, float, enumeration, string, points in time e time
spans.
genricas, sendo estes contentores (lists e feeds), erros, referncias para outros objectos,
operaes.
O objecto Lobby tem uma localizao bem conhecida no servidor e serve como ponto de
entrada. Este tem trs sub-objectos:
2.2.5.3 Representao
Os tipos de objecto base so directamente mapeados para elementos individuais XML.
Por exemplo, se um objecto um nmero inteiro ou derivado de um nmero inteiro,
ele representado como <int/>. Quaisquer outros objectos que no so derivados de um
51
52
2 Estado da Arte
tipo de objecto base, so representados usando o elemento <obj/>, em que neste caso o
atributo is especifica a classe (contracto) de um objecto.
Uma distino semelhante existe a respeito de como os atributos de um objecto so
representados. Os atributos base, por exemplo, o nome, so mapeados para atributos
XML, estes so chamados de facets. Os atributos adicionados so representados como
sub-objectos.
Os mtodos correspondem, por um lado, aos pedidos de rede abordados acima (read,
write e invoke) e, por outro, as operaes acrescentadas ao nvel do oBIX, representadas
como sub-objectos.
Os sub-objectos podem ser includos no XML completo ou atravs de uma referncia. A
incluso no XML ou o uso de referncia deve ser definida no momento em que se
define a hierarquia da classe. Por exemplo, um objecto de alarme oBIX codificado
como:
<obj name="somealarm" is="obix:Alarm">
<ref name="source" href="/myhouse/somewhere"/>
<abstime name="timestamp" val="2006-10-12_12:11:02"/>
</obj>
O objecto referenciado pelo atributo is, em que se d o nome de contrato. Actua como
um template para o objecto que o referencia. Todos os sub-objectos deste objecto de
referncia so herdados, ainda assim, o objecto que o referencia pode fazer override
desses sub-objectos, tal como na lgica orientada a objectos. Os objectos podem herdar
mltiplos contratos. Os contratos tambm podem ser vazios, apenas descrevendo a
semntica de um objecto - um exemplo o read-only oBIX Point.
O exemplo de um contrato que descreve um modelo genrico de uma caldeira (classe ou
template):
<obj href="def:furnace">
<bool name="burnerOn"/>
<real name="curTemp" is="obix:Point"/>
<real name="setTemp" val="50.0" is="obix:WriteablePoint"/>
</obj>
Esta seria uma instncia da classe caldeira. herdado o valor por omisso de 50 para
setTemp. Ao especificar o sub-objecto curTemp, qualquer valor por defeito
possivelmente herdado substitudo, no entanto, o contrato Point mantm-se. Um href
especificado para permitir o acesso por parte dos clientes oBIX.
2.2.5.4 Concluso
A abordagem do oBIX tem como vantagem o facto de ser implementado recorrendo a
Web Services, uma das formas mais populares de implementar arquitecturas do tipo
SOA, estes so independentes da plataforma, podendo ser implementados utilizando
qualquer linguagem de programao e serem executados em qualquer plataforma de
hardware ou sistema operativo. Este tipo de abordagem permite ainda o uso de tcnicas
como descoberta, segurana, transaces, eventos, etc.
Esta abordagem muito semelhante abordagem BIOS, pois ambas se baseiam em
arquitecturas do tipo SOA, usufruindo das vantagens enumeradas acima, e ambas
pretendem promover a cooperao entre os diversos subsistemas do edifcio. Uma das
principais diferenas o facto da soluo BIOS implementar um bus de servios, este
contm servios prprios de descoberta e troca de informao simplificando a
cooperao entre os demais servios. Este tema ser abordado nos captulos seguintes.
53
54
2 Estado da Arte
2.2.6
OPC-UA
A verso mais recente do OLE for Process Control (OPC) sofreu uma evoluo para
Open Process Control Unified Architecture (OPC UA) que um standard que tem
como objectivo o transporte de dados desde da camada de automao (e.g. PLCs ou
DDCs) at ao nvel de gesto, que inclui por exemplo SCADA (Supervisory Control
And Data Acquisition) ou mesmo um ERP (Entrepise Resource Planning) [30].
OPC Unified Architecture baseia-se em XML, WebServices e SOA e assenta sobre as
normas j existentes do OPC Classic, reutilizando as componentes j definidas nessas
normas, como por exemplo os trs tipos de dados suportados - dados actuais (OPC DA),
dados de histrico (OPC HDA) e alarmes e eventos (OPC A&E).
O standard OPC UA independente de fabricante ou qualquer protocolo especfico,
pois este foi desenvolvido recorrendo a tecnologias web standard.
OPC UA
Comunicao
Plataforma
Desenvolvimento
Servidores locais
Espao de
endereamento
DCOM
Microsoft
C/C++
COM
Estrutura
hierrquica
Funcionalidades
Real-time, Histrico
ou Eventos
UA TCP SOAP/HTTP
Multi-plataforma
C/C++, .NET, C#, Java, outras
UA stack based on Binary TCP
Estrutura hierrquica por defeito. Fornece um modelo de
informao muito rico que permite a modelao de
qualquer sistema atravs de referncias diferentes.
Real-time, Historical data, Historical Events, Events,
Programas e modelos especficos industria.
2.2.6 OPC-UA
55
56
2 Estado da Arte
2.2.6 OPC-UA
2.2.6.3 Concluso
O OPC-UA uma iniciativa que promove a uniformizao da comunicao e controlo,
entre hardwares, geralmente autmatos, e entre hardware e cliente, tais como
aplicaes grficas, sistema de gesto integrada, etc.
O OPC-UA resolve nesta dissertao, alguns problemas ao nvel da comunicao e
controlo entre a arquitectura BIOS, mais concretamente na implementao dos servios
de subsistema, e o hardware. Atravs desta iniciativa possvel virtualizar o hardware
num servidor OPC-UA, desta forma os interessados, chamados de clientes OPC-UA,
tm acesso monitorizao e/ou ao controlo dos demais componentes de hardware
presentes na configurao do servidor OPC-UA. Este tema ser abordado nos captulos
seguintes.
57
3.
Arquitectura proposta
Na arquitectura proposta necessria a interaco de diversos servios que fazem a
representao e abstraco de hardware e software (Service-oriented architecture SOA). Esses servios so descritos neste captulo em maior detalhe. A arquitectura
proposta implementa um bus lgico cooperativo (BIOSbus) de forma a que a interaco
entre os diversos servios possa ser efectuada de forma independente.
Prope-se uma arquitectura que promova a cooperao entre os diversos servios:
subsistemas do edifcio, gesto energtica, gesto integrada, monitorizao, etc. Cada
um destes servios oferece as funcionalidades que permitem manipular e monitorizar a
informao da qual so responsveis, de uma forma transparente em relao ao que
intrinsecamente necessrio para efectuar o seu controlo.
A Figura 17, baseada na Figura 7 presente no captulo 2, resume os diversos nveis de
funcionalidades de um edifcio, estes, tal como descrito anteriormente, so nvel de
campo, de automao e de gesto. No nvel de gesto encontram-se os elementos
responsveis pela configurao e gesto do edifcio, onde efectuada a manipulao da
informao gerada no nvel inferior, o nvel de automao, mas no feita qualquer
interveno que afecte de alguma forma os algoritmos de automao. O mesmo se
aplica arquitectura BIOS, pois esta opera ao nvel de gesto, garantindo que no h
interveno directa nos nveis inferiores, permitindo apenas, atravs da utilizao de
variveis de entrada e sada, fazer uma interaco com o controlador/algoritmo de
automao. Com esta separao, possvel garantir que a arquitectura proposta consiga
enquadrar os compromissos de cooperao entre os diversos sistemas sem que isso
comprometa a integridade de cada um, pois o algoritmo de controlo no afectado.
59
60
3 Arquitectura proposta
Tal como mencionado acima, o objectivo operar apenas no nvel de gesto, mas visto
que cada subsistema tem uma representao em hardware, necessrio que a
implementao dos subsistemas recorra a servios cuja responsabilidade seja a de
efectuar a abstraco do hardware. Estes servios denominam-se por servios de
comunicao. Um subsistema pode recorrer a mais que um hardware, podendo esses
hardwares serem distintos ao nvel do fornecedor ou protocolo. Isto de forma a facilitar
a implementao do subsistema, tanto a nvel de facilidade de adaptao mudana ou
mesmo da transparncia em relao ao tipo de hardware que automatiza o subsistema,
3 Arquitectura proposta
3.1
Bus cooperativo
3.1.1
Servio de descoberta
Para adicionar um servio ao bus, este tem que se registar na base de dados de servios,
ficando deste modo disponvel para o servio de descoberta o encontrar. O pedido de
descoberta pode ser efectuado por qualquer outro cliente ou servio do bus, sendo
fornecido ao servio cliente um proxy para o servio procurado. Atravs do servio de
descoberta possvel obter um servio sem que, partida, se conhea a sua
implementao ou mesmo quem o disponibiliza. Apenas atravs de um proxy para o
servio e da sua interface consegue-se executar as funcionalidades por ele
disponibilizadas. O servio de descoberta e de registo vem facilitar a integrao e
aumentar a tolerncia mudana.
61
62
3 Arquitectura proposta
3.1.2
3.2
Servio de Comunicao
3 Arquitectura proposta
Actualmente este servio no funciona sem que haja um adaptador do sistema original
para o BIOS. Para que essa converso no fosse necessria, o hardware teria que
disponibilizar o servio com uma interface tal como especificado pelo sistema BIOS (no
futuro pode vir a acontecer). Assim sendo, as diversas implementaes do servio de
comunicao tm que recorrer a um adaptador para efectuar a comunicao entre o
hardware e o servio de comunicao em causa, pois cada hardware tem as suas
necessidades e especificaes para o seu controlo e monitorizao por parte de uma
entidade externa, especificaes essas que so definidas atravs de protocolos.
3.3
Servio de Subsistema
Monitorizao:
o Ocupado/Livre
o Bloqueado/Desbloqueado
o Piso actual
o Pisos de destino
o Sentido (sobe/desce)
Controlo:
o Marcar como Ocupado/Livre
o Bloquear/ Desbloquear
o Enviar para piso
63
64
3 Arquitectura proposta
3.4
3 Arquitectura proposta
3.5
O sistema de gesto energtica tem como objectivo efectuar uma gesto racional dos
consumos de energia elctrica do edifcio, tendo disponvel para isso a informao de
todos os outros subsistemas.
A gesto dos consumos de energia pode ser conseguida de duas formas diferentes:
atravs de algoritmos que previnem picos de consumo de energia, atravs de deslastre
de carga, sendo esta tcnica abordada de forma mais detalhada no captulo 4; atravs da
anlise da informao dos diversos subsistemas de forma a serem detectadas
antecipadamente anomalias que possam estar a resultar em consumos desnecessrios de
energia.
A possibilidade de efectuar uma gesto de energia por prioridades, um exemplo de
uma potencialidade do sistema de gesto energtica. Tomando como exemplo o incio
da manh de um edifcio, em que a chegada de um elevado nmero de pessoas provoca
um aumento do uso dos elevadores e da climatizao e se for o caso o arranque de
mquinas industriais. Nestes primeiros momentos da manh o consumo energtico pode
exceder a energia contratada. As prioridades energticas esto dependentes do negcio
em que o edifcio se insere. Para este exemplo as prioridades so as seguintes: o
escoamento das pessoas; s depois a climatizao. O domnio da hora de chegada de
muitas pessoas ao edifcio pode ser identificada ou, como no caso deste exemplo,
configurada. Desta forma o sistema de gesto energtica acciona o sistema de
climatizao antes da hora de ponta correspondente s entradas no edifcio, de forma a
que aquando da chegada das pessoas seja possvel dar prioridade aos elevadores, sem
que a climatizao do edifcio seja afectada, podendo, como ltimo recurso, ser
desligado o sistema de climatizao durante a hora de ponta.
Este exemplo encontra-se simplificado, pois o objectivo demonstrar a integrao dos
vrios subsistemas para o objectivo comum de gesto energtica. Os elementos
intervenientes encontram-se na Figura 19. O subsistema "Elevadores" disponibiliza as
funcionalidades "Activar estado hora de ponta" e "Activar estado normal", o subsistema
AVAC disponibiliza as funcionalidades "Ligar" e "Desligar", existe uma simplificao
das funcionalidades pois, seria tambm relevante por exemplo identificar a temperatura,
as preferncias do utilizador etc.
65
66
3 Arquitectura proposta
3 Arquitectura proposta
3.6
Sistema de coordenao
67
68
3 Arquitectura proposta
Para este exemplo os trs subsistemas so isolados sendo toda a cooperao conseguida
atravs do servio "Coordenao". Este caso inicia-se com a identificao de um
utilizador no sistema de controlo de acessos, visto que para este exemplo o sistema no
tem a informao dos utilizadores, esse pedido reencaminhado para o servio
"Coordenao". Este, por sua vez, valida o utilizador junto do sistema "BD
Utilizadores" cuja resposta reencaminhada para o sistema "Controlo de Acessos". De
forma a exemplificar melhor as potencialidades desta arquitectura pode-se tornar este
exemplo mais complexo. Depois de validado o utilizador, verifica-se qual o piso que
este tem acesso e com essa informao o servio "Coordenao" pode automaticamente
chamar o elevador, cujo destino o piso em causa, atravs do sistema "Elevadores".
Todo este processo encontra-se demonstrado na Figura 22.
3 Arquitectura proposta
3.7
Adaptao mudana
69
70
3 Arquitectura proposta
4.
Detalhes de implementao
4.1
Demonstrador
4.1.1
A OMRON uma empresa cujo seu core bussiness a automao industrial (e.g. linha
de montagem). A automao dos processos fundamentalmente efectuada recorrendo a
Programmable Logical Controlers (PLC). Estes so, na prtica, microprocessadores
que foram estruturados para serem programados e configurados sem que seja necessrio
programar o microprocessador directamente, no sendo necessrio ter o conhecimento
da linguagem de programao do microprocessador mas sim de uma linguagem
simplificada que permite a programao do autmato. Isto trs vantagens pois o intuito
que pessoas sem formao em informtica ou em electrnica consigam construir
solues de automao (e.g. electricistas).
A lista e respectiva descrio dos equipamentos disponibilizados pela OMRON para
esta dissertao encontram-se no Anexo 1.
A programao destes PLC's efectuada atravs de software proprietrio, o CXProgrammer, e recorrendo a linguagem ladder. Esta linguagem de representao
71
72
4 Detalhes de implementao
Figura 23 - CX-Programmer
4 Detalhes de implementao
73
74
4 Detalhes de implementao
4 Detalhes de implementao
4.1.2
75
76
4 Detalhes de implementao
4.1.3
Desenvolvimento
4 Detalhes de implementao
OMRON
Schneider
77
78
4 Detalhes de implementao
4.2
Desenvolvimento da arquitectura
4 Detalhes de implementao
4.2.1
Bus cooperativo
4.2.1.1 Jini
Jini o nome de um ambiente de computao distribuda que potncia a lgica plugand-play, o que significa que um servio pode-se conectar rede e anunciar a sua
presena, e os clientes que pretendem usar esse servio podem localiz-lo e executar as
funcionalidades por ele oferecidas [35]. Isto possvel pois o Jini suporta mecanismos
de registo e descoberta automticos.
Um sistema Jini uma coleco de clientes e servios que comunicam atravs de
protocolos Jini. Isto possvel atravs da especificao de uma infra-estrutura
(middleware) que inclu um Application Programming Interface (API) para que um
programador possa desenvolver servios e componentes que faam uso deste
middleware.
O Jini est a ser desenvolvido no mbito do programa Apache River[36], tendo sido
lanada em Maro de 2010 a verso 2.1.2.
4.2.1.2 JavaSpaces
A linguagem de coordenao Linda foi proposta por David Gelernter em 1985. Uma
implementao Linda basicamente uma coleco de tuplos, alguns desses incorporam
cdigo a executar e outros, que so os que tm interesse para esta dissertao, apenas
tm informao passiva. Esta coleco de tuplos conhecida como tuple space ou TS
[37]. A linguagem Linda prope um conjunto de operaes simples, existindo dois
tipos, um utilizado para colocar tuplos no TS (out) e outro para obter os tuplos do TS
(in - alm de ler remove o tuplo do TS; read - apenas retorna uma copia do tuplo).
A linguagem de coordenao Linda tem mais valias para o objectivo desta dissertao
quando comparada com outros tipos de sistemas distribudos. Esta permite um
desacoplamento temporal [37], podendo um recurso ser colocado no TS sem que o seu
consumidor j esteja pronto para o consumir. O facto de toda a comunicao passar pelo
TS permite que os intervenientes do sistema no sejam conhecidos entre eles.
79
80
4 Detalhes de implementao
4.2.2
Servios de comunicao
4 Detalhes de implementao
Figura 29 - ICommunication
81
82
4 Detalhes de implementao
}
} catch (RemoteException e1) {
e1.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
System.out.println("Servios lanados");
4 Detalhes de implementao
83
84
4 Detalhes de implementao
existirem
alteraes.
Recorre-se
uma
funcionalidade
semelhante
em
determinado
Node.
Essas
notificaes
so
feitas
para
um
alteraes dos valores do Node chamado o evento onDataChange. Foi feita uma reimplementao deste evento para que seja identificado o listenerID associado ao
Node que sofreu a alterao. A implementao do mtodo monitorDataChange
encontra-se na Listagem 3.
Identificado qual o NodeId e ListnerID associado criado um DataChangeEntry com
o listnerID e colocado no JavaSpace, terminando aqui a interveno do servio de
comunicao. Desta forma no necessrio ter conhecimento de que entidade fez o
registo, apenas o seu listnerID, pois esta estar registada no JavaSpace para ser
notificada quando for introduzida um DataChangeEntry com o seu listnerID. Todo
este processo est esquematizado na Figura 31, incluindo a posterior notificao do
cliente por parte do subsistema.
4 Detalhes de implementao
}
private MonitoredDataItemListener dataChangeListener =
new MonitoredDataItemListener() {
@Override
public void onDataChange(MonitoredDataItem sender,
DataValue prevValue,
DataValue value)
{
MonitoredItem i = sender;
String listnerID=listnersList.get(i.getNodeId());
try {
javaSpace.write(new DataChangedEntry(
listnerID),
null,
1000*60);
} catch (RemoteException e) {
e.printStackTrace();
} catch (TransactionException e) {
e.printStackTrace();
}
}
};
85
86
4 Detalhes de implementao
espao de memria pretendido, bit ou word, endereo e dados. Para o envio destes
comandos utilizando o protocolo UDP.
O envio de comandos resulta sempre numa resposta, essa tambm em cdigo
hexadecimal e com necessidade de ser tratada para interpretao de mais alto nvel.
Os mtodos getTag e setTag apenas necessitam de construir o comando pretendido e
envia-lo via UDP e, para o caso do getTag, a resposta tem de ser interpretada para
poder ser devolvida. A implementao destes mtodos encontram-se na Listagem 4.
@Override
public String getTag(String memoryType, String address) throws
RemoteException{
String finsCmd=
FinsProtocolInfo.getCommandHeader()+
FinsProtocolInfo.read_mem+
((memoryType.equals("CIO"))?FinsProtocolInfo.cio_bit:"82")+
address+
"00"+
FinsProtocolInfo.NUM_ITEMS_1;
String answer;
try {
answer = CommunicationManager.executeCmd(finsCmd);
} catch (SocketException e) {
throw new RemoteException("SocketException",e);
} catch (IOException e) {
throw new RemoteException("IOException",e);
}
String state = ResponseManager.decryptFinsResponse(answer);
Integer stateValue=Integer.parseInt(state,16);
return stateValue.toString();
}
@Override
public void setTag(String memoryType, String address, String tagValue)
throws RemoteException {
String finsCmd=
FinsProtocolInfo.getCommandHeader()+
FinsProtocolInfo.write_mem+
FinsProtocolInfo.cio_word+
address+
"00"+
FinsProtocolInfo.NUM_ITEMS_1+
tagValue;
try {
CommunicationManager.executeCmd(finsCmd);
} catch (SocketException e) {
throw new RemoteException("SocketException",e);
} catch (IOException e) { throw new RemoteException("IOException",e);}
}
Listagem 4 - Mtodo getTag e setTag - OMRON
4 Detalhes de implementao
87
88
4 Detalhes de implementao
4.2.3
Servios de Subsistema
4 Detalhes de implementao
Figura 33 - IAvac
descritas,
registo
no
servio
de
notificao
de
alteraes
89
90
4 Detalhes de implementao
@Override
public String getFanSpeed() throws RemoteException {
return fanSpeed.getState().toString();
}
@Override
public String getSetpoint() throws RemoteException {
return setpoint.getState().toString();
}
@Override
4 Detalhes de implementao
Figura 34 - ILighting
91
92
4 Detalhes de implementao
Figura 35 - IEnergy
Figura 36 - IElevators
4 Detalhes de implementao
Figura 37 - IParkingCO2
interoperabilidade
conseguida
atravs
desta
arquitectura.
Esta
4.2.4
Servio de coordenao
93
94
4 Detalhes de implementao
}
public void notify(RemoteEvent event) throws UnknownEventException,
RemoteException {
long eventID=event.getID();
if(eventID==parkingCO2EventID){
try {
getAndRefreshFromJSParkingCO2();
}
<restante cdigo no relevante>
}
Listagem 7 - Registo de notificao para coordenao
4 Detalhes de implementao
Tal como descrito no captulo anterior o sensor de CO2 simulado atravs de dois
interruptores no hardware Schneider: quando no existe nenhum interruptor ligado
95
96
4 Detalhes de implementao
4 Detalhes de implementao
4.2.5
(maxContractedEnergyInUse)
de
se
ultrapassar
potncia
contratada
4.2.6
Interface Grfica
97
98
4 Detalhes de implementao
5.
99
100
foi concretizada para estes casos especficos, em que os subsistemas considerados foram
o AVAC, a iluminao, a gesto racional de energia elctrica, elevadores e sistema de
monitorizao de CO2. Todos estes subsistemas tm representao no hardware.
Podendo concluir que aps a implementao da arquitectura proposta esta responde s
necessidades e consegue atingir os objectivos inicialmente propostos, nomeadamente o
factor mais relevante o da interoperabilidade.
No que diz respeito a propostas de trabalho futuro, esta dissertao poderia ser
melhorada atravs da incluso de:
6.
Bibliografia e referncias
[1] European Comission. Statistical Pocketbook 2009 - EU energy and transport in figures.
s.l. : European Communities, 2009.
[2] Merz, Hermann, Hbner, Christof e Hansemann, Thomas. Building Automation Communication Systems with EIB/KNX, LON and BACnet. s.l. : Springer, 2009.
[3]
2M
CCTV.
2M
CCTV.
[Online]
[Citao:
de
Setembro
de
2010.]
http://www.2mcctv.com/.
[4] Briere, Danny e Hurley, Pat. Smart Houses for dummies. s.l. : Wiley Publishing, 2007.
[5] Elsenpeter, Robert C. e Velte, Toby J. Build Your Own Smart Home. s.l. : McGraw-Hill,
2003.
[6]
Siemens.
Siemens.
[Online]
[Citao:
de
Setembro
de
2010.]
http://www.siemens.com.
[7] Electronic House. Systems - Lighting Control. [Online] [Citao: 1 de Novembro de
2009.] http://www1.electronichouse.com/info/systems/lighting.html.
[8] Hordeski, Michael F. HVAC Control in the new millennium. s.l. : The Fairmont Press,
2001.
[9] Inc., Strata Resource. Investigating Open Systems - Comparing LonWorks and BACnet.
2006.
[10] Winkelman, Patrick. Sustainable BAS. Automated Buildings. [Online] 2009. [Citao: 1
de
Dezembro
de
2009.]
http://www.automatedbuildings.com/news/mar09/articles/distech/090219023638distech.ht
m.
[11] Granzer, Wolfgang, Kastner, Wolfgang e Reinisch, Christian. Gateway-free
Integration of BACnet and KNX using Multi-Protocol Devices. s.l. : Vienna University of
Technology, Automation Systems Group, 2008.
[12] Frank, Randy. Understanding Smart Sensors. s.l. : ARTECH HOUSE, INC, 2000.
101
102
6 Bibliografia e referncias
[13] Kastner, WOLFGANG, et al. Communication Systems for Building Automation and
Control. s.l. : IEEE, 2005.
[14] Newman, H.M. BACnet - The New Standard Protocol. BACnet. [Online] 1997.
http://www.bacnet.org/Bibliography/EC-9-97/EC-9-97.html.
[15] Thomas, George. Connecting BACnet Devices to an IP Infrastructure. Automated
Buildings.
[Online]
2009.
[Citao:
de
Maro
de
2010.]
http://www.automatedbuildings.com/news/mar09/articles/cctrls/090220020828cctrls.htm.
[16] Bender, Joel e Newman, Mike. BACnet/IP. BACnet Tutorial. [Online] [Citao: 1 de
Maro de 2010.] http://www.bacnet.org/Tutorial/BACnetIP/.
[17] Swan, Bill. The Language of BACnet - Objects, Properties and Services. PolarSoft.
[Online] 2003. [Citao: 1 de Maro de 2010.] http://www.polarsoft.biz/langbac.html.
[18] Thomas, George. Object Modeling a Physical BACnet Device. Automated Buildings.
[Online]
2008.
[Citao:
de
Maro
de
2010.]
http://www.automatedbuildings.com/news/aug08/articles/cctrls1/080724032404cctrls.htm.
[19] Real Time Automation. BACnet Overview - An Application Layer Protocol for Building
Automation.
Real
Time
Automation.
[Online]
[Citao:
de
Abril
de
2010.]
http://www.rtaautomation.com/bacnet/.
[20] LonMark International. Overview Handbook. 2009.
[21] Toshiba Corporation. Neuron Chip. 2006.
[22] Fernandes, Pedro Miguel de Miranda. Aplicaes Domticas para Cidados com
Paralisia Cerebral. Biblioteca digital da Universidade de Aveiro. [Online] [Citao: 1 de
Dezembro
de
2009.]
http://portal.ua.pt/bibliotecad/default1.asp?OP2=0&Serie=0&Obra=28&H1=2&H2=4.
[23] Echelon. Neuron 5000 Processor. Echelon. [Online] [Citao: 1 de Maro de 2010.]
http://www.echelon.com/products/neuron/default.htm.
[24] Konnex. KNX System-architecture. 2004.
[25] Konnex Association. Introduction to KNX. 2004.
[26] Lechner, Daniel, Granzer, Wolfgang e Kastner, Wolfgang. Security for KNXnet/IP.
2008.
[27] Kell, Alan e Colerbrook, Peter. Open Systems for Homes and Buildings: Comparing
LonWorks and KNX. s.l. : 2003.
[28] Echelon. Neuron Chips. Echelon - Developers. [Online] [Citao: 1 de Maro de 2010.]
http://www.echelon.com/developers/lonworks/neuron.htm.
[29] OASIS Open. oBIX 1.0 - Committee Specification 01. 2006.
[30] Tan, Vu Van, Yoo, Dae-Seung e Yi, Myeong-Jae. Device Integration Approach to OPC
UA-Based Process Automation Systems with FDT_DTM and EDDL. 2009.
[31] Mandrusiak, Manny. OPC UA Education hits the road. Automated Buildings. [Online]
Janeiro
de
2010.
[Citao:
de
Junho
de
2010.]
http://www.automatedbuildings.com/news/jan10/columns/091229120909mandrusiak.htm.
[32] OPC Foundation. OPC Unified Architecture - Specification - Part 1: Overview and
Concepts. 2009.
[33] Mahnke, Wolfgang, Leitner, Stefan-Helmut e Damm, Matthias. OPC Unified
Architecture. s.l. : Springer, 2009.
[34] Karg, Steve. Elevator Simulator Design. [Online] [Citao: 2010 de 10 de 30.]
http://kargs.net/elevator.html.
[35] Newmarch, Jan. Foundations of Jini 2 Programming. s.l. : Apress, 2006.
[36] Apache River. Apache River. [Online] [Citao: 1 de Setembro de 2010.]
http://incubator.apache.org/river/RIVER/index.html.
[37] Gelernter, Davic. Generativa Communication in Linda. s.l. : Yale University, 1985.
[38] Wells, G. C., Chalmers, A. G. e Clayton, P. G. Linda implementations in Java for
concurrent systems. s.l. : John Wiley & Sons, Ltd, 2003.
[39] Unified Automation. Unified Automation. [Online] [Citao: 1 de Setembro de 2010.]
http://www.unified-automation.com.
104
6 Bibliografia e referncias
[40] Prosys. Prosys OPC UA Java SDK. [Online] [Citao: 1 de Setembro de 2010.]
https://www.prosysopc.com/opc-ua-sdk.php.
[41] OMRON. FINS Commands. 2001.
Fonte de alimentao
ID 201
Entradas digitais
OD 201
Sadas digitais
105
106
Anexo 1
MAD 42
SCU41-V1
Xenta 121
STR 106
Mdulo de parede para controlo de AVAC (Sensor de
temperatura, velocidade da ventilao, estado da
presena (ocupado, desocupado ou em pausa) , etc.);
Xenta 422A
107
108
Anexo 2
PM9C