Dissertação Bacnet e OPC PDF

INSTITUTO
LISBOA
SUPERIOR
DE
ENGENHARIA
DE
Departamento de Engenharia de Electrnica e Telecomunicaes e

de Computadores
ISEL
Building Intelligence Open System (BIOS)
Fbio Ruivo Ferreira

(Licenciado)
Dissertao de natureza cientfica realizada para obteno do grau de

Mestre em Engenharia Informtica e de Computadores
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.
Palavras chave: BAS, interoperabilidade, subsistemas de um edifcio, SOA
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
Notao utilizada ............................................................................................... 7
1.5
Estrutura da dissertao ..................................................................................... 7
Estado da Arte .......................................................................................................... 9

2.1
2.1.1
Subsistemas de um edifcio inteligente ...................................................... 9
2.1.2
Tipos de sistemas de controlo................................................................... 17
2.2
3.
Enquadramento do problema ............................................................................. 9
Tecnologias em edifcios ................................................................................. 27
2.2.1
BACnet ..................................................................................................... 27
2.2.2
LonWorks ................................................................................................. 34
2.2.3
KNX ......................................................................................................... 42
2.2.4
Comparao LonWorks, BACnet e KNX ................................................ 47
2.2.5
Open Building Information eXchange (oBIX) ......................................... 50
2.2.6
OPC-UA ................................................................................................... 54
Arquitectura proposta ............................................................................................. 59

3.1
Bus cooperativo................................................................................................ 61
3.1.1
Servio de descoberta ............................................................................... 61
3.1.2
Servio de partilha de informao ............................................................ 62
3.2
Servio de Comunicao ................................................................................. 62

ix
ndice
4.
3.3
Servio de Subsistema ..................................................................................... 63
3.4
Sistema de gesto integrada ............................................................................. 64
3.5
Sistema de gesto energtica ........................................................................... 65
3.6
Sistema de coordenao ................................................................................... 67
3.7
Adaptao mudana ...................................................................................... 69
Detalhes de implementao .................................................................................... 71

4.1
Demonstrador................................................................................................... 71
4.1.1
Sistema de automao OMRON............................................................... 71
4.1.2
Sistema de automao Schneider ............................................................. 75
4.1.3
Desenvolvimento ...................................................................................... 76
4.2
Desenvolvimento da arquitectura .................................................................... 78
4.2.1
Bus cooperativo ........................................................................................ 79
4.2.2
Servios de comunicao.......................................................................... 80
4.2.3
Servios de Subsistema ............................................................................ 88
4.2.4
Servio de coordenao ............................................................................ 93
4.2.5
Servio de gesto energtica..................................................................... 97
4.2.6
Interface Grfica ....................................................................................... 97
5.
Concluses e Trabalho Futuro ................................................................................ 99
6.
Bibliografia e referncias...................................................................................... 101
Anexo 1: Sistema de automao OMRON - Descrio dos equipamentos .................. 105

Anexo 2: Sistema de automao Schneider - Descrio dos equipamentos................. 107
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
Building Automation System
BIOS
Building Intelligence Open System
oBIX
Open Building Information Exchange
PLC
Programmable Logical Controlers
DDC
Direct/Distributed Digital Controls
SDK
Software Development Kit
API
Application Programming Interface
SOA
Service Oriented Achitecture
OPC
OLE for Process Control
OPC UA
Open Process Control Unified Architecture
OPC DA
OLE for Process Control Data Access
AVAC
Aquecimento, Ventilao e Ar Condicionado
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.
Figura 1 - Edifcio e os seus diversos subsistemas
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
Figura 2 - Fases de um projecto e suas dificuldades
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
Ao tema actual da preservao do meio ambiente, manifesta-se num conjunto de

iniciativas que visam reduzir a emisso de gases com efeito de estufa, sendo as mais
relevantes o protocolo de Quioto em vigor desde 2005 e a cimeira de Copenhaga em
2009. Por um lado, a eficincia energtica cada vez mais valorizada e, por outro, os
edifcios (residenciais e servios) so responsveis por 38,7% de todo o consumo
energtico da Europa a 27 [1], tal como se pode verificar no grfico presente na Figura
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.
Figura 3 - Consumo energtico da UE-27 por sector [1]
As actuais solues que garantem a gesto integrada de um conjunto de subsistemas

num edifcio resultam de processos de integrao especializados e geram solues "one
of a kind", de difcil reutilizao em situaes idnticas. Tais solues fazem subir os
custos de implementao e criam limitaes ao nvel do fabricante, fornecedor e/ou
protocolo.
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
Figura 4 - Building Intelligence Open Service Bus (BIOSBus)
Todavia, o esquema na Figura 4 d origem a uma questo fundamental, ou seja, como

ir ser estabelecido um padro para a infra-estrutura tecnolgica de um edifcio de modo
a que processos de gesto, manuteno, administrao e anlise (business intelligence
BI), entre outros, possam ser desenvolvidos e associados de forma dinmica de forma a
que cada uma destas componentes de valor acrescentado consiga dialogar com qualquer
outro sistema j instalado. A hiptese da necessidade de estabelecimento de uma
linguagem de cooperao aberta, a ser implementada por uma diversidade de sistemas
tecnolgicos baseados em protocolos e linguagens especializadas, necessita de ser
desenvolvida e validada atravs da experimentao sobre prottipos (demonstradores),
envolvendo a diversidade de standards e tecnologias existentes. A proposta de um
Building Intelligence Open Service Bus (BIOSBus) pretende incorporar uma associao
gil e flexvel entre os processos associados a uma viso integrada de um edifcio e a
sua infra-estrutura tecnolgica de suporte.
Este Bus dever incorporar o padro emergente SOA (service oriented architecture)
como estratgia para o desenvolvimento e adopo de sistemas cooperativos em
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
Esta dissertao inicia-se com a anlise do Estado da Arte. No captulo 2 efectuado o

enquadramento do problema e so analisadas as tecnologias emergentes mais relevantes
para a soluo do problema.
Na segunda parte desta dissertao proposta uma soluo para o problema
identificado. No captulo 3 est descrita a arquitectura proposta, onde efectuada uma
primeira abordagem ao sistema BIOS. No captulo 4 so apresentados os detalhes de
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
De forma a ter conscincia do que envolve a gesto integrada de um edifcio de

servios, so levantadas neste captulo as caractersticas mais relevantes, nomeadamente
atravs da identificao e caracterizao de cada um dos seus subsistemas e sempre que
for relevante so apresentados exemplos onde existe mais valia na adopo de
subsistemas cooperantes.
Para efectuar o controlo e monitorizao de um edifcio pode-se recorrer a dois tipos de
sistemas de controlo, proprietrio e aberto, estes sero analisados neste captulo. No
caso dos sistemas abertos so analisadas as mais valias, bem como a identificao de
alguns protocolos abertos.
2.1.1
Subsistemas de um edifcio inteligente
Neste subcaptulo so descritos os subsistemas mais relevantes e comuns num edifcio.

Os subsistemas abordados consideram a segurana (incluindo CCTV, alarmes de
intruso, alarmes internos e controlo de acessos), o controlo de iluminao, o controlo
de climatizao, os sistemas de controlo para interaco humana, elevadores e a gesto
de energia elctrica.
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.
Figura 5 - Sistema completo de CCTV[3]
2.1.1.1.2 Alarmes de intruso

Existem inmeros sensores cuja utilizao visa a deteco de entrada de intrusos num
determinado edifcio, tais como sensores de abertura de janelas, vibrao do cho, ou o
mais comum, sensores de movimento, entre outros.
Existem diversas hipteses de aces a desencadear em funo dos sinais gerados pelos
sensores acima mencionados, as quais dependem de configurao especfica efectuada
caso a caso. Se o intruso ainda se encontra no exterior do edifcio, poder acender-se
toda a iluminao exterior, tanto para potenciar a gravao do sistema CCTV, como
para tentar intimidar o intruso numa tentativa de o afugentar. Estando o intruso j dentro
do edifcio pode-se accionar um alarme silencioso, que faz imediatamente uma chamada
para o proprietrio/autoridades, alertando sobre o acontecimento. Durante essa
chamada, tambm pode ser emitido o udio da diviso em que o intruso se encontra [4].
2.1.1 Subsistemas de um edifcio inteligente 11

No entanto, podem ser tomadas aces mais complexas, como por exemplo, tentativa de
isolamento do intruso atravs do fecho automtico de portas, corte de energia a
elevadores, etc.
2.1.1.1.3 Alarmes internos (Incndio, Inundao, Gs)

Cada edifcio tem as suas necessidades, existindo inmeros tipos de sensores
possibilitando configurar um sistema para satisfazer determinado tipo de requisitos
especficos, sendo os mais comuns dos sistemas de alarme, os de deteco de incndios.
Existem outros sistemas que tm por objectivo assegurar outras funcionalidades, como
por exemplo, deteco de inundaes e deteco de fugas de gs. [5]
J existe tecnologia para detectar diferentes tipos de gs, podendo estes ser o comum
gs da cozinha (Butano/Propano), CO2, ou mesmo um outro tipo de gs pouco comum
no dia-a-dia mas importante para uma empresa que lide com esse tipo de produtos,
sendo assim possvel detectar uma fuga atempadamente.
A Figura 6 ilustra um hipottico sistema de deteco de incndios.
Figura 6 - Sistema de deteco de incndio, Sinteso Siemens[6]
2.1.1.1.4 Controlo de acessos

Um sistema de controlo de acessos um tipo de segurana fsica que permite o acesso a
um edifcio, diviso ou zona, apenas por pessoas autorizadas. O controlo feito atravs
de meios tecnolgicos. Por exemplo, atravs de um carto, cdigo ou impresso digital
pode ser identificado o ocupante que pretende aceder a determinada zona privada e
conceder-lhe, ou no, a autorizao.
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.
2.1.1.2 Controlo de Iluminao

Um sistema de controlo de iluminao no geral caracterizado por um mdulo central
de processamento que comunica com os diversos interruptores, directamente com a
prpria iluminao ou com outra central, possibilitando uma gesto distribuda.
Este sistema permite controlar a iluminao de variadas formas, por exemplo atravs
dos convencionais interruptores, ou a partir de um sistema central que possibilita o
controlo por diviso ou mesmo de todo o edifcio. abstrada a forma convencional
onde apenas os interruptores faziam o controlo de uma srie de lmpadas. Com um
sistema de controlo de iluminao, esta pode ser controlada de qualquer interface. Essas
interfaces so definidas no mdulo central de processamento, podendo ser do mais
variado tipo: interruptores, dimmers 1, controlo remoto, sensores, internet, etc. Com este
subsistema automatizado proporciona ao ocupante economia e conforto, podendo ainda
ser acedido pelo sistema de segurana, por exemplo, na resposta ao alarme de intruso.
Atravs de sensores de presena evita-se consumos desnecessrios de energia elctrica,
proporcionando ainda conforto. Atravs desses sensores pode-se activar a iluminao
apenas quando existe pelo menos um ocupante presente. [7]
2.1.1.2.1 Controlo em tempo real

Ter a noo em tempo real dos consumos de energia elctrica de um edifcio de
fundamental importncia para alcanar uma gesto racional de energia. Atravs do
sistema de superviso e controlo (onde podem estar includas aces como deslastre de
cargas) podem ser verificadas informaes desde o consumo de energia elctrica de uma
lmpada at ao conjunto do edifcio. Posto isto, fica facilitada a verificao se existem
sectores do edifcio com maiores consumos que outros, podendo ser detectadas
possveis anomalias.
Com o sistema de superviso e controlo do consumo de energia elctrica, ser possvel
detectar e diagnosticar avarias de uma forma automtica, facilitando e centralizando a
gesto do edifcio.
Dimmer um tipo de dispositivos utilizado para variar a intensidade de uma luz.
14
2 Estado da Arte
2.1.1.3 Controlo de Climatizao

Um sistema AVAC (Aquecimento, Ventilao e Ar Condicionado) seja por
necessidades funcionais do edifcio, seja apenas para assegurar o conforto dos
ocupantes, hoje em dia valorizado e indispensvel na concepo de um edifcio.
A opo por um sistema com gesto centralizada, oferece um conjunto de
potencialidades semelhantes ao controlo de iluminao. Por exemplo, atravs da
identificao de rotinas efectuadas geralmente por determinado ocupante podem passar
a serem executadas de forma automtica. Deste subsistema resulta melhorias no
conforto dos ocupantes e ainda a nvel da gesto de energia (economia).
Em relao gesto energtica importante fazer uma gesto ocupacional partindo da
quantidade de pessoas presentes na diviso/edifcio obtida atravs de sensores ou pelos
identificadores de cada ocupante para uma melhor gesto dos recursos [8], ou
considerando o cruzamento de informao da agenda de reunies de determinada sala
ou mesmo do sistema de controlo de acessos. Desta forma, o sistema de climatizao
ser automaticamente ajustado ou antecipadamente accionado de modo a serem criadas
as condies de conforto trmico desejadas pelos ocupantes.
2.1.1.4 Sistemas de Controlo

O controlo dos diversos subsistemas de um edifcio pode ser efectuado de forma
centralizada ou distribuda . A facilidade de interaco com o sistema de controlo
poder traduzir-se em conforto para os ocupantes. De seguida so enumeradas vrias
filosofias de controlo.
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.

Para um controlo mais focado, nomeadamente de determinado piso ou seco, existem
sistemas mais compactos normalmente embutidos na parede onde, atravs de um ecr
tctil, possvel efectuar o controlo.
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.
2.1.1.6 Gesto Energtica

Verificar as necessidades energticas da diviso/edifcio dependendo se esto presentes
ocupantes ou at quantos esto presentes d-se o nome de gesto ocupacional que um
tipo de gesto energtica.
O sistema pode monitorizar toda a energia elctrica que est a ser consumida em tempo
real, ou ainda prever o que se vai consumir at ao final do ms/ano podendo ser
detectadas
atempadamente
eventuais
anomalias
evitando
assim
consumos
desnecessrios de energia elctrica.

A gesto de energia pode ser condicionada pela sazonalidade, pois as necessidades nos
perodos de inverno no so as mesma que num perodo de vero. Por exemplo, em
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 Tipos de sistemas de controlo 17
2.1.2
Tipos de sistemas de controlo
Os sistemas de controlo podem ser divididos em dois tipos: os proprietrios que so

desenvolvidos pelos fornecedores/fabricantes e so geralmente fechados cooperao; e
os abertos que so na sua maioria baseados em normas promovidas por associaes de
empresas do ramo e so desenvolvidos com o intuito principal de possibilitar a
cooperao, independncia de fornecedor e a sustentabilidade evoluo do sistema.
2.1.2.1 Sistemas proprietrios

Em geral, os sistemas proprietrios exibem desempenhos aceitveis para o fim que
foram concebidos. Contudo, a empresa proprietria do sistema tem geralmente o
monoplio dos algoritmos utilizados no controlo do sistema e do correspondente
software, bem como, frequentemente exigida a utilizao de hardware de determinado
fabricante especfico.
Ao investir num sistema deste tipo no se est apenas a comprar um produto mas sim a
criar uma parceria, que geralmente apenas favorece o fornecedor. Assim, torna-se
impraticvel, ou mesmo financeiramente difcil, depois de realizado um investimento
inicial num sistema proprietrio de determinado fornecedor, mudar para outro. Para
alm dos aspectos econmico/financeiros,
os sistemas proprietrios revelam-se
tendencialmente incompatveis com softwares e hardwares de outros fornecedores.
18
2 Estado da Arte
2.1.2.2 Sistemas Abertos (SA)

A utilizao de tecnologias baseadas em SA vem alterar o paradigma de negcio da
indstria de automao de edifcios, nomeadamente na relao entre o proprietrio, o
integrador de sistemas e o fabricante. Os proprietrios tm a oportunidade de escolher
produtos, tecnologias ou aplicaes de fornecedores diferentes. Os integradores de
sistemas e fabricantes podem utilizar produtos de terceiros ou tecnologias e aplicaes
desenvolvidas por si nos seus sistemas devendo seguir um conjunto de normas que
caracterizam um sistema aberto. No mbito do novo paradigma, o foco deixa de ser a
tecnologia de suporte a determinado sistema e passa para as solues, servios e
funcionalidades que os clientes necessitam. Ou seja, na implementao de determinado
sistema/soluo integrada, a preocupao dever deixar de ser a tecnologia utilizada,
passando esta para os processos a que esse sistema responde.
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
(interchangeability / Plug-and-play). [9]

Oferta competitiva
Com sistemas proprietrios s existe uma oferta competitiva no incio de um projecto.

Uma vez tomada a deciso inicial relativamente a determinada soluo especfica, passa
a ser o fornecedor a ditar as regras do jogo. Por outro lado, quando se utilizam
solues abertas, que asseguram interoperabilidade entre hardware e software de
diferentes fabricantes e uma integrao do tipo Plug-and-play, verificamos a existncia

de uma oferta competitiva no incio do projecto, durante a sua explorao e at numa
possvel expanso.
Instalao consistente
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
Uma instalao consistente resulta numa manuteno consistente, traduzindo-se numa

reduo de custos de explorao, dado que quem realiza a manuteno apenas necessita
de conhecer a arquitectura e funcionalidades do SA, no estando as operaes de
manuteno na dependncia de fabricantes ou produtos.
Integrao de sistemas e interoperabilidade
As solues abertas de gesto tcnica de um edifcio envolvem todos os subsistemas

necessrios para assegurar os requisitos de projecto no que se refere ao controlo da
instalao, assegurando que os referidos subsistemas so capazes de comunicar entre si,
sendo a sua explorao efectuada a partir de um ponto central, proporcionando-se assim
as condies necessrias para assegurar a dita interoperabilidade.
Aquisio de informao
Atravs de um SA totalmente integrado no edifcio consegue-se todo o tipo de

informao em tempo real relativamente ao funcionamento da instalao. Essa
informao pode ser utilizada por exemplo para o sistema de gesto de energia elctrica,
conseguindo-se assim um edifcio energeticamente mais eficiente.
Permutabilidade entre produtos
Produzindo produtos de acordo com os standards/requisitos do SA, resulta em produtos

estruturados para facilitar a permutabilidade entre produtos com funes semelhantes
mas de fabricantes diferentes. Embora, mesmo nos sistemas ditos abertos esta seja uma
matria de elevada complexidade, constitui um paradigma difcil de abordar quando
consideramos sistemas proprietrios.
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.

Multi-fornecedor
As solues de gesto tcnica centralizada de edifcios inteligentes, tm que ter a

possibilidade de ser produzidas incorporando produtos de vrios fornecedores, sem que
seja necessrio recorrer a gateways 2, ou a software ou ferramentas de rede, especficos
do fabricante.
Interopervel
Capacidade de cooperar de forma transparente com outro sistema heterogneo podendo

dessa forma partilhar informao ou mesmo fazer pedidos sobre componentes dos
vrios subsistemas. Desta forma, uma rede de subsistemas heterogneos transformada
num s sistema mais robusto e com maior capacidade de resposta aos diversos pedidos
dos utilizadores.
Soluo total
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
Gateway um dispositivo dedicado ou um software que faz a traduo entre protocolos

permitindo que protocolos totalmente independentes comuniquem entre si. Mas desta forma cria-se
dependncias, pois se algum dos protocolos for alterado o gateway tambm tem que ser adaptado.
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.
2.1.2.2.3 Anlise de requisitos para um Building Automation System

(BAS) sustentvel
Os requisitos para um sistema de gesto tcnica centralizada que assegure a automao
de edifcios sustentvel, so [10]:
Continua disponibilidade da maioria dos componentes do sistema, seja hardware ou
software, compatvel com o sistema original
Idealmente, este requisito passa pela possibilidade de utilizao de produtos de

diferentes fabricantes. Um exemplo simples, a obsolescncia de determinada interface
grfica que tem que ser substituda ou simplesmente adoptada uma verso mais
actualizada. Essa substituio tem que ser garantida, possivelmente necessitando
tambm de um PC novo, sem que haja uma necessidade de reestruturao do sistema de
gesto tcnica centralizada.
Disponibilidade da informao
Para garantir a sustentabilidade do BAS importante que os tcnicos tenham acesso

facilitado informao e formao, seja para fazer uma implementao de raiz, ou
mesmo num futuro em que seja necessrio expandir ou fazer manuteno do sistema.

Ou seja, no caso de um sistema proprietrio o nmero de tcnicos formados nessa
tecnologia reduzido e verifica-se a existncia de retraco das empresas em
disponibilizar informaes sobre os seus sistemas proprietrios. Num sistema aberto
existem entidades independentes que do formao e disponibilizam informao sobre a
arquitectura de forma facilitada. Desta forma, o sistema aberto d mais garantia de uma
contnua disponibilidade de informao.
Expanso do BAS
Os componentes mais recentes do BAS tm que ser compatveis com os antigos

(sistemas legados), de modo a que o sistema seja facilmente mantido e/ou expandido.
Apesar de se poder utilizar gateways, esta no a melhor soluo j que requer um
conhecimento especializado o que pode limitar a assistncia tcnica. A soluo ideal
utilizar produtos cujos fornecedores/fabricantes asseguram que na sua evoluo se
mantm compatveis para que a expanso do BAS acompanhe facilmente a evoluo do
edifcio.
BAS evolutivo
O BAS tem que estar preparado para acompanhar os desenvolvimentos tecnolgicos.

Um exemplo pode ser a substituio de uma interface grfica em aplicao PC, para
uma em aplicao Web.
A soluo: Sistema aberto
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
Como j existe garantia de interoperabilidade assegurada pelo SA, torna-se simples e

directa a expanso do BAS. Assim, a rede e a interface grfica antiga so usadas para
comunicar e controlar os componentes novos.
Pode-se concluir que se consegue atingir um BAS sustentvel atravs de uma escolha
inicial cuidada e estudada, que tenha em conta as necessidades e que inclua o uso de
protocolos e redes estandardizadas e um acesso facilitado aos produtos e informao
(Sistema Aberto).
2.1.2.3 Protocolos Abertos

Um BAS tem como objectivo melhorar a eficincia e eficcia da gesto tcnica
centralizada de todo o equipamento que proporciona um conjunto de funcionalidades
executadas de forma automtica, que permitem classificar determinada instalao de
inteligente. Estas funcionalidades so divididas em 3 nveis conforme representado na
Figura 7. Nvel de campo, onde a informao recolhida (e.g. sensores) e so
executadas as aces de controlo (e.g. actuadores). Nvel de automao onde so
implementados e executados, por exemplo, os algoritmos de controlo, tolerncia a
falhas, instrumentao de software, etc. Nvel de gesto ser responsvel pela
configurao e gesto do sistema, bem como, pela sua explorao (e.g. monitorizao).
De acordo com o Estado da Arte neste domnio do conhecimento, os Protocolos Abertos
mais relevantes so BACnet, LonWorks e o KNX. So estes os protocolos que
permitem a integrao das funcionalidades intrnsecas aos trs nveis de funcionalidades
acima referidas. Todavia, existem outros que se especificam apenas para responder a um
conjunto restrito de requisitos. Na Tabela 1 encontra-se uma lista com alguns protocolos
utilizados na automao de edifcios. Como se pode verificar na Figura 7, o KNX e
LonWorks so mais predominantes nos nveis de campo e de automao, enquanto o
BACnet prevalece nos nveis de automao e gesto [11].
Figura 7 Nveis de funcionalidades [11]
Neste relatrio so analisados os trs protocolos referidos anteriormente, KNX,

LonWorks e BACnet, considerados os protocolos abertos com maior sucesso e
visibilidade.
26
2 Estado da Arte
Protocolo
Patrocinador
BACnet
Building Automation Industry
LonTalk.
Echelon Corp.
KNX
Konnex
Modbus
Modicon
ZigBee
ZigBee Aliance
IBIbus
Intelligent Building Institute
CAB
Canada
X-10
X-10 Corp.
Smart House
Smart House L.P.
CEBus
EIA
Michigan Parallel Standard
University of Michigan
Integrated Smart-Sensor Bus Delft
University of Technology
Time-triggered protocol
University of Wien, Austria (Automotive)
Tabela 1 Protocolos de automao [12]
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
desenvolvimento ficado concludo apenas em 1995, quando a ASHRAE promoveu a

publicao do BACnet como um standard ANSI (American National Standards
Institute). Em 2003 foi adoptado pelo CEN (European Committee for Standardization) e
pela ISO (International Organization for Standardization) o que implicou uma maior
expanso na sua utilizao, nomeadamente na Europa e sia. A verso mais recente do
standard o BACnetA Data Communication Protocol for Building Automation and
Control Networks, ANSI/ASHRAE Std. 135, 2004 [13].
2.2.1.1 Entidades de desenvolvimento e suporte

2.2.1.1.1 Standing Standard Project Commitee (SSPC)
A evoluo do BACnet constante sendo mantida atravs do ASHRAE Standing
Standard Project Commitee (SSPC), em cujo grupo esto representados sectores da
indstria relacionada com a construo de edifcios. O processo de desenvolvimento
totalmente aberto, estando o grupo formado no mbito do SSPC receptivo a comentrios
e sugestes.
27
28
2 Estado da Arte
2.2.1.1.2 BACnet Interest Groups (BIGs)

Os chamados BIGs so grupos interessados no BACnet, podendo ser empresas ou
universidades. J existe o BIG-EU (Europa), BIG-NA (Amrica do norte), BIG-AA
(Austrlia e sia), entre outros. Estes grupos tm como objectivo divulgar e apoiar a
utilizao do BACnet, atravs de actividades promocionais, formao e trocas de
experincias.
2.2.1.1.3 BACnet Testing Laboratories (BTL)

Um elemento muito importante para a manuteno da coerncia dos produtos BACnet
no mercado o BTL, operado pela BMA (BACnet Manufacturers Association). o
BTL que testa e certifica os produtos, assegurando a coerncia e consistncia entre os
produtos e as normas indicadas no standard.
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]
2.2.1.3 BACnet e Modelo OSI

O modelo OSI descreve por camadas a comunicao entre dois dispositivos de rede. Na
sua forma original este modelo tem sete camadas, mas o BACnet apenas adaptou quatro
delas, Fsica, Ligao, Rede e Aplicao, como se pode verificar na Tabela 2.
A camada mais baixa, a Fsica a responsvel por enviar a representao binria da
informao, sendo esta normalmente implementada sobre hardware dedicado. A
camada de Ligao define como os componentes so endereados e de que forma a
informao vai ser enviada entre eles. A camada de Rede alm de fazer o Routing das
mensagens permitindo que dois tipos diferentes da camada de Ligao (e.g. Ethernet e
MS/TP) possam comunicar. A camada de Aplicao onde se d significado
informao, definindo os objectos, suas propriedades e servios por eles
disponibilizados (Captulo 2.2.1.4).
29
30
2 Estado da Arte
Camadas Equivalentes
Camadas BACnet
OSI
Camada de Aplicao BACnet
Aplicao
Camada de Rede BACnet BACnet/IP
Rede
Ethernet
MS/TP
PTP
EIA-485
EIA-232
Ligao
LonTalk
Ethernet
ARCNET
Fsica
Tabela 2 - Modelo de 4 camadas do BACnet [15]
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
Figura 9 - Exemplo de uma ligao IP [16]
2.2.1.3.4 BACnet/WS (Web Services)

Atravs de uma srie de servios (Captulo 2.2.1.4.3) disponibilizados sobre a rede e
com o acesso por um browser de internet, possvel evitar assim a necessidade de uma
aplicao especfica para a gesto tcnica centralizada de um edifcio inteligente. Desta
forma, as tarefas inerentes gesto tcnica centralizada de um edifcio inteligente,
podem ser efectuadas atravs dos Web Services a partir de qualquer posto de trabalho da
rede (internet ou intranet).
2.2.1.4 Representao e gesto dos dispositivos

2.2.1.4.1 Objectos
O BACnet disponibiliza 18 tipos de objectos Standard para representao e gesto de
dispositivos,
Tabela 3. Toda a informao no BACnet representada atravs de objectos. Um objecto
pode representar um input/output fsico, ou um grupo lgico de pontos que representam
algum tipo de funcionalidade. Todos os objectos so identificados e contm
determinadas propriedades associadas, sendo apenas atravs destas que o objecto
gerido e controlado [17].
Por exemplo um objecto correspondente a um sensor de temperatura de um sistema
AVAC, alm da temperatura actual, pode tambm conter outras informaes teis, por
exemplo em que unidade est a ser medida a temperatura (e.g. Celsius), ou a descrio
do local em que est a ser realizada a medida.
31
32
2 Estado da Arte
Tabela 3 - Objectos BACnet [18]
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
Tabela 4 - Propriedades obrigatrias de um Device Object [18]
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.
2.2.2.2.1 LonTalk e o Modelo OSI

O LonTalk baseia-se no Modelo OSI (tal como acontece com o BACnet). Na Tabela 5
possvel identificar a correspondncia entre as vrias camadas.
Event-triggered A execuo de tarefas disparada por intermdio de um sinal de
controlo.
34
2.2.3 KNX
Camada
OSI
Objectivo
Servios prestados
CPU*
Aplicao
Compatibilidade
a nvel das
aplicaes
Objectos LonMark, propriedades de

configurao, SNVTs, transferncia de
ficheiros
APP
6 Apresentao
Interpretao da
informao
Variveis de rede, interface de rede
NET
Sesso
Aces remotas
Pedidos/Respostas, autenticao, servios

de rede
NET
Transporte
Fiabilidade entre Sinais de mensagem recebida, deteco de

extremidades
mensagens duplicadas
NET
Rede
Endereamento
de destino
Informao do caminho da mensagem,

endereamento unicast e multicast
NET
MAC
MAC
XCVR
Ligao
Meios de acesso
Framing, codificao de dados,

verificao de erros CRC, CSMA,
controlo e deteco de colises,
prioridades
Fsica
Meios fsicos
Meios de comunicao e esquemas de

modelao
*Ver Captulo 2.2.2.3

Tabela 5 - LonTalk e Modelo OSI[21]
2.2.2.2.2 Meios de comunicao

O LonTalk suporta vrios meios de comunicao: rede elctrica, par entrelaado, rdio
frequncia, infravermelhos, cabo coaxial, fibra ptica. O mais comum neste tipo de
sistema par entrelaado com velocidade de 78,1kbps (FT-10), permitindo segmentos
de 500 metros com um cabo de baixo custo. Existe a variante usando a rede elctrica, a
qual tambm bastante utilizada (LP-10). comum usar-se um bus em par entrelaado
com uma velocidade de 1,25Mbps (TP-1250) para fazer a interligao entre os
subsistemas baseados em FT-10. A fibra ptica aparece tambm como uma variante
para implementar este bus.
Mais recentemente os Bus TP-1250 comeam a ser substitudos por mecanismos de IP
tunneling, LonWorks/IP. Atravs deste mecanismo possvel integrar dispositivos
LonWorks em redes IP e internet [13].
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
Figura 10 - Hierarquia/Segmentao da rede [13]
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
Domnio, Subnet, Neuron ID*
N fsico especfico
*O domnio e subnet so apenas necessrios para facilitar o encaminhamento (routing)
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.
Figura 11 - Arquitectura tpica de um n [13]
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].
2.2.2.2.5 Servio de mensagens

Existem 4 tipos bsicos de servios de mensagens. Os primeiros dois so servios dos
quais se espera uma resposta (acknowledged):
Acknowledged (ACKD), uma mensagem enviada para um n ou para um grupo de
ns, e espera-se acknowledge de cada um desses ns. No caso de no se receber o
acknowledge de todos os receptores, o emissor reenvia a mensagem. O nmero de
tentativas e o tempo de espera de resposta pode ser configurado. O acknowledge
gerado automaticamente pelo controlador de rede no necessitando da interveno de
uma aplicao. O acknowledge alm de servir para garantir que o receptor recebeu a
mensagem serve tambm para evitar o envio de mensagens duplicadas.
Pedido/Resposta (REQUEST), uma mensagem enviada para um n ou para um grupo
de ns, e espera-se uma resposta de cada um desses ns. A mensagem recebida
processada pela aplicao do receptor e s posteriormente ser enviada a resposta.
Existem as mesmas caractersticas de reenvio e tempo de espera como no ACKD.
Os outros dois tipos so servios em que no expectvel a existncia de resposta:
Repeated (UNACKD_RPT), uma mensagem enviada para um n ou para um grupo de
ns repetidas vezes e no se espera uma resposta. Este servio tipicamente para envio
de mensagens multicast (envio para vrios ns) para grupos de ns que, no caso desses
ns terem que confirmar a recepo, haveria uma elevada probabilidade de ocorrer uma
sobrecarga na rede.
Unacknowledged (UNACKD), uma mensagem enviada para um n ou para um grupo
de ns sendo que no esperada uma resposta. Este tipo de servio utilizado quando
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.2.2.6 Variveis de rede

A ligao lgica entre os sensores e os actuadores realizada atravs de
variveis de rede. atravs de uma ferramenta de configurao (LonMaker) que se
ligam as variveis compatveis dos diferentes dispositivos LonWorks.
O grupo LonMark definiu uma lista normalizada de variveis, denominada
SNVT, uma das quais a SNVT_occupancy, para definir variveis do mesmo tipo. Este
atributo desempenha um papel fundamental na interoperabilidade dos dispositivos. O
SNVT permite, assim, efectuar a associao das variveis de entrada e de sada.
Existe tambm uma lista normalizada de variveis de configurao, denominada
SCPTs (Standard Configuration Parameter Types) e uma lista de perfis para os
dispositivos comuns, chamada FPs (Functional Profiles) [22].
2.2.2.3 Neuron Chip

O Neuron Chip um dispositivo fabricado e distribudo pela Motorola e pela Toshiba,
que implementa o protocolo LonTalk. Especialmente concebido para a tecnologia
LonWorks, permite controlar todos os dispositivos utilizados naquela tecnologia. o
dispositivo preferencial do protocolo LonTalk porque foi criado especificamente para o
efeito. No entanto, aquele protocolo tambm pode ser implementado numa arquitectura
de processador genrica. O Neuron Chip possui (Figura 12):
Trs processadores de 8 bits (NET, MAC e APP) - dois deles especialmente

vocacionados para a execuo do protocolo LonTalk, cabendo ao terceiro as
2.2.3 KNX
aplicaes do n. Esta separao permite salvaguardar qualquer impacto
negativo da aplicao na rede e vice-versa;
Memrias EEPROM, RAM e ROM, variveis de acordo com o modelo do

Neuron Chip (todas as verses incluem, pelo menos, 0.5K de EEPROM e 1K
de RAM);
Um transdutor para conexo ao meio fsico de comunicao;
Hardware e software para construir dispositivos de controlo;
11 pinos de I/O;
Firmware 4LonWorks, incluindo o protocolo LonTalk, um sistema operativo de

tempo real, device drivers 5, etc.
No caso de insuficincia do Neuron Chip (aplicaes demasiado complexas), poder-se-

utilizar um processador externo, desde que o firmware do Neuron Chip seja alterado
[22].
Figura 12 - Diagrama de blocos do processador Neuron 5000[23]
Firmware o conjunto de instrues operacionais programadas directamente no hardware de um

equipamento electrnico.
5
Device driver o comando de um dispositivo ou programa. Faz a interface entre dispositivos
diferentes (e.g. Impressora e PC)
41
42
2 Estado da Arte
2.2.3
KNX
O KNX (Konnex) um sistema distribudo dedicado s necessidades de um edifcio.

Em 2002, o KNX foi definido atravs da combinao de 3 sistemas de gesto de
edifcios j existentes EIB (European Installation Bus), Batibus e EHS (European
Home System). Em 2004, foi publicado como standard europeu (EN 50090). Finalmente
em 2006, tornou-se standard internacional (ISO/IEC 14543). O KNX especificado e
gerido pela Konnex Association (Captulo 2.2.3.1) [24].
Este sistema designado como o standard nico europeu one-single-standard e vem
responder aos dois principais Standards Americanos (BACnet e LonWorks) [25]. As
redes de dispositivos KNX so sempre desenhadas de forma a criar aplicaes
distribudas, de forma a potenciar a interaco entre elas.
2.2.3.1 Konnex Association

Em 1999, a Konnex Association criada atravs da cooperao entre o BatiBUS Club
International (BCI), o European Installation Bus Association (EIBA) e o European
Home Systems Association (EHSA).
A actualizao, promoo, certificao e formao do standard o objectivo principal
desta associao [25].
2.2.3.2 Modos de configurao

2.2.3.2.1 S-mode (System mode)
Este modo de configurao direccionado para instaladores especialistas, possibilitando
a definio de funes de controlo do edifcio mais sofisticadas. As componentes de um
S-mode podem ser planeadas atravs do software ETS Professional (captulo 2.2.3.4.2),
atravs do qual possvel interligar os componentes e configura-los atravs de uma
srie de parmetros disponibilizados pelo fabricante. Assim consegue-se uma maior
flexibilidade nas funes de controlo do edifcio.
2.2.3 KNX
2.2.3.2.2 E-mode (Easy mode)

Este modo de configurao direccionado para instaladores com a formao bsica em
KNX. Os produtos E-mode compatveis oferecem um nmero limitado de funes em
comparao com S-mode.
Os componentes E-mode j vm de fbrica programados e carregados com os
parmetros por omisso. Com uma verso mais bsica do ETS (ETS Starter) possvel
reconfigurar parcialmente o componente.
2.2.3.2.3 A-mode (Automatic mode)

Este modo de configurao direccionado para o cliente final, tendo a filosofia Plugand-Play [24], em que o instalador no necessita de conhecimentos de KNX para o
configurar. Este modo ser especialmente indicado para ser usado, por exemplo, em
electrodomsticos.
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.
2.2.3.3.1 Meios de comunicao

O KNX fornece uma sria de meios de comunicao. Um meio de comunicao pode
ser usado em combinao com um ou diversos modos de configurao. Permitindo
assim ao fabricante uma melhor escolha das combinaes para determinado produto ou
mercado.
As redes KNX so tipicamente implementadas seguindo um modelo de duas camadas.
No nvel de campo pode-se encontrar os sensores, actuadores e controladores que
interagem com o ambiente. Estes componentes do nvel de campo esto interligados por
uma espinha dorsal com capacidades de gesto (e.g. estao de trabalho) que tm uma
viso global de toda a rede. Na Figura 13 pode-se verificar um exemplo tpico desta
topologia [26].
43
44
2 Estado da Arte
Figura 13 - Exemplo de uma rede KNX[26]
TP-0, (Twisted pair, type 0)
Este meio de comunicao uma reutilizao de um dos meios de comunicao

definidos no protocolo BatiBus. Atinge uma velocidade de transferncia de 4,8kbps.
Apesar de ser possvel operar na mesma rede do protocolo BatiBus no permite trocar
informao com o KNX.
TP-1, (Twisted pair, type 1)

definidos no protocolo EIB. Atinge uma velocidade de transferncia de 9,6kbps. Os
produtos que sejam certificados para operar numa rede TP-1, sejam do protocolo KNX
ou EIB, conseguem cooperar sobre a mesma rede.
PL-110, (Power-line, 110 kHz)
Este meio de comunicao igualmente uma reutilizao de um dos meios de

comunicao definidos no protocolo EIB. Atinge uma velocidade de transferncia de
1,2kbps. Os produtos que sejam certificados para operar numa rede PL-110, sejam do
protocolo KNX ou EIB, conseguem cooperar sobre a mesma rede.
PL-132, (Power-line, 132 kHz)

definidos no protocolo EHS. Atinge uma velocidade de transferncia de 2,4kbps. Os
produtos dos dois tipos apenas conseguem cooperar atravs de um conversor de
protocolo.
2.2.3 KNX
RF, (Radio frequency, 868 MHz)
No existindo nenhuma implementao deste meio de comunicao em algum dos

protocolos que deram origem ao KNX, esta implementao teve que ser desenvolvida
directamente para o KNX. Atinge uma velocidade de transferncia de 38,4kbps. um
meio sem fios utilizando a tecnologia de rdio frequncia.
Ethernet
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
O endereamento fsico dos componentes do sistema feito recorrendo a conjuntos de 3

octetos. Num mesmo sistema podem ser suportados at 65536 componentes. Uma linha
(line) permite 256 componentes, que podem ser agrupadas em linhas mestras (main
lines), que por sua vez podem ser agrupadas em reas. Um domnio formado por 15
reas interligadas pela espinha dorsal da rede (backbone line), Figura 14.
Figura 14 - Topologia lgica [24]
45
46
2 Estado da Arte
2.2.3.4 Representao e gesto dos dispositivos

2.2.3.4.1 Data-points
Os data-points so usados por um sistema KNX para dar e receber ordens,
enquanto interligados formando uma rede lgica distribuda. Esta interligao lgica
entre componentes tem como nome binding.
Existem 3 tipos de esquemas para interligar data-points [24]:
Free binding: Apenas necessita de seguir algumas regras, nomeadamente

os tipos de data-points (e.g. booleano);
Structured binding: Estipula de forma precisa o padro para a ligao

com todos os data-points;
Tagged binding: semelhante ao anterior, mas tem sempre associado a

informao de destino.
2.2.3.4.2 Engineering-Tool-Software (ETS)

Um Engineering-Tool-Software (ETS) a ferramenta base de todo o sistema KNX, que
permite planear, projectar e parametrizar os componentes e rede KNX. Encontra-se na
verso 3 desde 2004 e, a verso 4 j foi apresentada mas ainda no foi libertada.
2.2.4 Comparao LonWorks, BACnet e KNX
2.2.4
Comparao LonWorks, BACnet e KNX
A Tabela 7 resume a comparao entre as 3 tecnologias, LonWorks, BACnet e KNX.

Posteriormente ser efectuada uma comparao mais detalhada de algumas das
caractersticas apresentadas na tabela.
LonWorks
BACnet
KNX
1988 Desenvolvido pela

Echelon
1987 Incio do desenvolvimento

pela ASHRAE
1988 Formao da EIB pela

Siemens
1994 Criada a LonMark
1995 ASHRAE-135
1999 Formao do KNX
1995 1 Dispositivo certificado

pela LonMark
2000 Criada a BTL
2004 EN 50090
2001 ANSI standard
2006 ISO/IEC 14543
Histria
1999 ANSI 709

2003 ISO 16484-5
2002 Actualizao ANSI 709
2003 ASHRAE-135.1
2005 600 Dispositivo
certificado pela LonMark
2004 Actualizao do ANSI

2005 100 Dispositivo
certificado pela BTL
Arquitectura de rede
Bottom Up
Top Down
Bottom Up
Protocolo de comunicao
nico
Topologia de rede por camadas
Topologia livre de baixa

velocidade
Ferramentas de gesto de rede

disponveis atravs de
aproximadamente 30 fontes
Ferramentas de gesto de rede

disponveis atravs de apenas 5
fontes
ETS 3 que independente do

fabricante
Ferramenta nica para aceder a

todos meios de comunicao
No existe ferramenta nica

para aceder aos protocolos
suportados
Peer-to-Peer
Gesto de rede
Ferramentas de gesto
geralmente fornecidas pelo
fabricante
47
48
2 Estado da Arte
Arquitectura dos dispositivos

Neuron Chip
Independente do processador
Neuron C (Linguagem)
Independente da linguagem
Inicialmente foi utilizado um

processador 68HC05
Implementao do modelo OSI

Todas as 7 camadas
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
Vrios protocolos suportados:

Ethernet, ARCNET, MS/TP,
LonTalk, PTP
Par entranado - 9.6kbps
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 - 1.2kbps at 2.4kbps

Wireless - 38.4kbps
Powerline - 4.8kbps
Wireless, fibra ptica,
infravermelhos esto publicados
mas pouco utilizados
Internet
LonWorks/ IP
BACnet/IP
i.LON Dispositivo que

disponibiliza Web Services
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
2.2.4 Comparao LonWorks, BACnet e KNX
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.2 Arquitectura dos dispositivos

Uma desvantagem que o LonWorks apresenta o facto da implementao dos seus
dispositivos ter como base um processador especfico, Neuron Chip. Este facto tem a
vantagem de facilitar a criao de novos dispositivos, mas o facto de este ser produzido
apenas pela Toshiba e pela Cypress Semiconductor constitui naturalmente uma
desvantagem [28].
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
Open Building Information eXchange (oBIX)
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 Open Building Information eXchange (oBIX)
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.
So tambm definidos objectos de forma a abranger uma srie de aplicabilidades
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:
About, fornece informaes acerca do servidor;
Batch, recebe uma sequncia de operaes a realizar;
Watch, regista objectos num servio de notificao.
Atravs destes dois ltimos possvel reduzir o overhead do protocolo.

A interaco e representao dos dados primitivos provenientes do sistema de
automao, efectuada atravs da classe Points, que permite operaes de leitura e
escrita.
O histrico pode ser representado atravs da classe oBIX History Record, que rene
pares Point e Time Stamp. O objecto History define uma lista de registos histricos e
uma srie de mtodos que permitem a pesquisa desse histrico.
O oBIX define um modelo normalizado de gesto e utilizao de alarmes. Um servidor
oBIX fornece formas de registo e alerta dos objectos de alarme (feeds). Sempre que um
servidor detecta que o valor de um objecto corresponde a um condio de alarme
definida, um objecto alarme adicionado ao feed, de tal forma que esse objecto contm
uma timestamp e a referncia para a sua origem.
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>
2.2.5 Open Building Information eXchange (oBIX)
Pode-se observar o uso de contractos derivados de Point (o contracto WriteablePoint

adiciona uma operao de escrita) e que o valor por defeito do setTemp 50. Um
objecto que aplica o contracto anterior:
<obj name="furnace" href="myhouse/heating/furnace" is="def:furnace">

<bool name="burnerOn" val="true"/>
<real name="curTemp" val="45.3"/>
</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.
2.2.6.1 OPC Classic

O OPC Classic a base/incio do OPC UA. Baseia-se numa tecnologia cliente/servidor,
tendo sido projectado com base no Microsoft Active X (OLE), COM e tecnologia
DCOM. Resumidamente, o OPC Classic define um conjunto de interfaces, mtodos e
propriedades que permite a transferncia de dados entre um servidor e um cliente. Um
servidor OPC fornece as informaes a pedido de um cliente OPC.
As caractersticas chave do OPC Classic e do OPC UA so colocadas em forma de
comparao na Tabela 8.
OPC Classic
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.
Tabela 8 - Caractersticas chave OPC Classic e OPC UA [31]
2.2.6 OPC-UA
2.2.6.2 Especificao OPC UA

A especificao OPC UA est dividida em 12 partes, tal como se pode ver na Figura 15,
existindo as core specifications que definem a base de todo o OPC UA e as access type
specifications que servem para definir os information models. Apenas a parte 1 desta
especificao pblica a pessoas que no sejam membros da OPC Foundation [32].
Abaixo so introduzidas cada uma destas partes, que para maior detalhe requer a
consulta de cada uma das partes na especificao. De qualquer forma o livro [33] pode
ser consultado em substituio da especificao propriamente dita.
Figura 15 - Especificao OPC UA [32]
As duas primeiras partes da especificao no so normativas. A parte Overview &

Concepts (UA Parte 1) d uma viso geral sobre OPC UA e a UA Parte 2 descreve os
requisitos e o modelo de segurana para as interaces entre OPC UA Clients e OPC
UA Servers.
As partes 3 e 4 da especificao descrevem como modelar e aceder informao,
constituindo as especificaes chave para desenvolver aplicaes OPC UA.
A parte Address Space Model (UA Parte 3) descreve o contedo e estrutura da
informao que o servidor disponibiliza para os clientes (Address Space).
55
56
2 Estado da Arte
A parte Services especifica as vrias possibilidades de interaco entre clientes e

servidores. Um cliente usa um servio para aceder informao disponibilizada pelo
servidor. Os servios so abstractos pois definem a informao que vai ser trocada mas
no como vai ser trocada, tanto ao nvel fsico como da API utilizada pelas aplicaes.
A Figura 16 mostra as camadas de abstraco associada arquitectura de comunicao.
Figura 16 - Arquitectura de comunicao [33]
Na parte 6 so especificados os mapeamentos dos UA Services para mensagens, os

mecanismos de segurana aplicados a essas mensagens, bem como as codificaes
suportadas.
O modelo de informao especificado na parte 5, sendo definidos os tipos e as suas
relaes, suportados por um OPC UA Server.
A parte 7 (Profiles) especifica os perfis que esto disponveis para clientes e servidores.
Estes perfis definem grupos de servios ou de funcionalidades, sendo desta forma
simplificada a verificao de compatibilidade entre servidor e cliente.
Nas partes 8 11 so especificados os modelos de informao para acesso aos diversos
tipos de dados, divididos tal como no OPC Classic. A Data Access (DA) (parte 8) lida
com a representao e uso dos dados de automao de um servidor OPC UA. A Alarm
and Conditions (AC) (parte 9) especifica o processo de alarme e monitorizao de
mquinas de estado e eventos. Em Programs (parte 10) definida uma mquina de
estados base cujo objectivo executar, manipular e monitorizar os programas/mtodos
definidos no OPC UA que so como uma forma de suporte aos servios
disponibilizados, conseguindo assim uma mais fcil interoperabilidade e gesto da
automao. A Historical Access (parte 11) especifica o uso do histrico de acesso aos
2.2.6 OPC-UA
servios e como apresentar a informao de configurao dos dados e eventos de

histrico.
A parte 12 (Discovery) define a forma de encontrar servidores numa rede e como um
cliente obtm a informao necessria para estabelecer uma ligao com determinado
servidor.
Por fim, a parte 13 (Aggregates) especifica a forma como se processa e retorna
agregados como mnimo, mximo, mdia, etc. Estes podem ser calculados tendo por
base informao em tempo real ou mesmo proveniente do histrico.
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.
Figura 17 - Nveis de funcionalidades
59
60
3 Arquitectura proposta
Na Figura 18 encontra-se esquematizada a arquitectura proposta: os servios de

subsistema esto representados a verde; A laranja esto os servios disponibilizados
pelo bus cooperativo; a azul esto os servios de comunicao, que esto encapsulados
nos respectivos servios subsistema; a vermelho esto os servios consumidores, gesto
integrada, energtica e coordenao.
Figura 18 - 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,
os servios de comunicao cooperam sobre um bus com funcionalidades idnticas ao

BIOSbus mas internos a cada subsistema.
3.1
Bus cooperativo
Um bus cooperativo vem facilitar a diviso de responsabilidades entre os diversos

sistemas, dado que o controlo e comunicaes so separados por diversas entidades,
simplificando-se assim a integrao para o objectivo comum, a criao de condies
que garantam a cooperao.
O uso da palavra bus advm da analogia ao barramento fsico existente nos
computadores para a comunicao entre os diversos dispositivos. Neste caso, o bus
encontra-se num nvel de abstraco mais elevado, tendo como vantagem principal a
reduo das comunicaes ponto a ponto, pois cada entidade do bus no tem de
conhecer todas as restantes. Desta forma fica simplificada a adaptao mudana por
parte do sistema, em que idealmente a adio ou remoo de entidades ao bus pode ser
feita de forma automtica.
O bus cooperativo o concentrador de todas as entidades da arquitectura, este
disponibiliza servios que permitem simplificar a sua utilizao, bem como potenciar a
integrao das entidades. Estas entidades so o servio de descoberta e o servio de
partilha de informao, descritas de seguida.
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.1.2
Servio de partilha de informao
Um servio de partilha de informao um repositrio que permite armazenar

informao e disponibiliz-la aos interessados. Este servio oferece as seguintes
funcionalidades: escrever, ler e registar notificao sobre alteraes de estado.
Esta forma de partilhar informao oferece um desacoplamento temporal, pois a troca
de informao efectuada atravs de um repositrio com acesso comum. Um cliente
interessado em determinada informao, apenas tem que se registar como seu subscritor
dela e desta forma o cliente notificado sobre alteraes no estado da informao.
Este tipo de abordagem reduz as necessidades de comunicao entre servios, veja-se
como exemplo o servio de gesto energtica, este no vai estar, constante e
directamente, a monitorizar as alteraes dos demais servios por ele utilizados, apenas
subscreve no servio de partilha de informao os servios sobre os quais quer ser
informado e espera pelas notificaes de alterao de estado.
3.2
Servio de Comunicao
O servio de comunicao, tal como o nome indica, o servio que abstrai as

comunicaes com os componentes fsicos e/ou lgicos utilizados na automao das
diversas funcionalidades do edifcio.
As operaes possveis sobre as entidades envolvidas na automao so definidas numa
interface, neste caso so apenas operaes de leitura e de escrita. Assim sendo, os
servios que recorram ao servio de comunicao apenas tm de conhecer esta
interface, sendo desnecessrio saber qual o tipo de automao, protocolo ou mesmo
detalhes de implementao do servio.
Sabendo que a interface do servio de comunicao independente do hardware que
este virtualiza e sendo as implementaes necessrias da responsabilidade de cada
servio de comunicao, consegue-se garantir que as implementaes de outros servios
ou clientes no ficam dependentes do hardware mas sim do servio de comunicao,
mais concretamente da interface por este implementada.
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
Este servio disponibiliza as funcionalidades necessrios para o controlo e

monitorizao de um determinado subsistema. Este tipo de servio j usufrui da
abstraco em relao ao hardware oferecido pelo servio de comunicao e acresce a
abstraco ao nvel do subsistema, que inclui a abstraco de como se obtm um valor
de determinado componente do subsistema ou que operaes de controlo esto
acessveis num determinado subsistema.
As operaes de monitorizao e controlo possveis de efectuar por parte de
determinado subsistema so definidas numa interface. A cooperao entre os diversos
subsistemas no implica que se tenha conhecimento sobre a implementao do servio
de determinado subsistema. Por exemplo, o subsistema "Elevadores", virtualizado por
um servio com o mesmo nome e implementa uma interface que descrimina uma verso
simplificada das operaes de monitorizao e controlo possveis [34]:
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
Os clientes do servio de "Elevadores" apenas tm o conhecimento da interface do

servio que descrimina as operaes possveis, podendo afirmar que para o cliente o
subsistema de elevadores uma "caixa preta" onde a interaco ocorre atravs das
operaes implementadas. Apesar de transparente ao cliente, estas operaes tm que
ser implementadas pelo servio, e para o caso do subsistema "Elevadores" existe a
necessidade de comunicar com o hardware responsvel pela automao. Esta
comunicao, tal como referido no captulo anterior, depende do hardware que se
encontra implementado, mas recorrendo aos servios de comunicao esta
implementao fica simplificada, pois, para alm de no existir a necessidade de
conhecer detalhes de hardware, a sua implementao do subsistema no fica
dependente deste.
3.4
Sistema de gesto integrada
O sistema de gesto integrada usufrui da facilidade de cooperao oferecida pelos

servios acima descritos. Estes so todos concentrados como um nico sistema
auxiliando dessa forma o controlo e a monitorizao do edifcio.
Este sistema pode ser apresentado atravs de uma interface grfica, sendo que dessa
forma a gesto em tempo real do edifcio fica facilitada, pois numa nica interface esto
centralizados os elementos existentes no edifcio.
A gesto integrada alm de agilizar a monitorizao e controlo do edifcio atravs da
centralizao dessas operaes numa nica interface, potencia tambm a identificao
de alguma anomalia em determinado subsistema, fazendo chegar os devidos alarmes s
entidades competentes, por exemplo, enviando um pedido de manuteno directamente
para o piquete responsvel. Utilizando o exemplo dos "Elevadores" abordado
anteriormente, se o servio de "Elevadores" informar que tem uma anomalia, ou mesmo
que esta seja detectada atravs da anlise dos dados deste subsistema, podem ser
accionadas de imediato e de forma automtica operaes de segurana e/ou de
manuteno.
3.5
Sistema de gesto energtica
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
Figura 19 - Exemplo gesto energtica
Concretizando o exemplo, o sistema de gesto energtica previamente configurado

com a hora de ponta do edifcio, e 60 minutos antes dessa hora ligado o sistema de
climatizao (AVAC), desta forma no momento da hora de ponta j estar a
climatizao num estado onde o seu consumo energtico menor que na fase de
arranque. Chegada a hora de ponta alterado o estado dos elevadores para "hora de
ponta", este estado coloca todos os elevadores com prioridade nas subidas. Todo este
processo encontra-se demonstrado na Figura 20. Este exemplo poderia ser mais
complexo, podia-se, por exemplo, integrar o subsistema "Energia" responsvel pelos
dados energticos em tempo real de forma a verificar a necessidade de desligar o
sistema de climatizao.
Figura 20 - Sequncia exemplo gesto energtica
3.6
Sistema de coordenao
O objectivo do sistema de coordenao promover a interoperabilidade entre

subsistemas, pois existem situaes em que o estado de determinado componente de um
subsistema pode ser importante para uma melhoria da gesto de um outro subsistema.
Torna-se como exemplo a coordenao conseguida entre os subsistemas "Controlo de
Acessos", "Elevadores" e "Base de Dados Utilizadores", os intervenientes deste
exemplo encontram-se representados na Figura 21.
Figura 21 - Exemplo coordenao
67
68
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.
Figura 22 - Sequncia exemplo coordenao
Atravs do sistema de coordenao possvel que a dependncia entre os subsistemas

seja garantida pelo BIOS. No existindo a necessidade que estes tenham conhecimento
da implementao dos demais subsistemas ou mesmo do hardware ou protocolo
utilizado. Para este exemplo em concreto, o facto de ter o sistema "Base de Dados de
Utilizadores", possvel centralizar toda a informao dos utilizadores do edifcio,
evitando redundncia e possveis inconsistncias, podendo ser integrado um sistema j
existente na empresa. Alm de que com este tipo de abordagem potencia-se a criao de
valor acrescentado ao edifcio, como o caso de chamar o elevador com o destino do

utilizador identificado.
Apesar do exemplo aqui apresentado demonstrar a cooperao entre diversos
subsistemas atravs do servio "Coordenao", existe a possibilidade de que este seja
feito dentro de um nico subsistema. O caso implementado e descrito em pormenor no
captulo 4.2.3.5 o subsistema "Alarme de CO2", neste caso o servio "Coordenao"
utilizado de forma a conseguir cooperao de hardware, pois o sensor e os actuadores
so controlados por hardwares de fabricantes diferentes.
A arquitectura permite que a coordenao seja feita internamente ao subsistema, mas
isso comprometeria o desacoplamento existente entre subsistemas, pois teriam de
cooperar com outros directamente. Da forma proposta um subsistema no tem que ter
conhecimento sobre quais so os subsistemas que se encontram ligados no BIOS.
3.7
Adaptao mudana
A arquitectura proposta foi desenhada de forma a facilitar a adaptao mudana . Por

exemplo, na necessidade de adicionar um novo subsistema, sabendo que no existe uma
dependncia directa entre eles, pois todos os subsistemas cooperam atravs de um bus,
este novo subsistema seria adicionado ao bus como um servio subsistema, estando
automaticamente disponvel para que outros servios cooperassem com ele. Esta
automatizao na adio de novos servios advm das potencialidades do bus j
descritas no captulo 3.1. Idealmente, ao adicionar o novo subsistema, este ficaria
dinamicamente disponvel no sistema de gesto integrada, mais propriamente na
interface grfica.
No caso da mudana ser ao nvel do hardware, a arquitectura proposta tambm vem
facilitar a adaptao. Neste caso pretende-se que o subsistema se mantenha o mesmo,
apenas existindo alterao do hardware responsvel pelo seu controlo. Esta alterao
totalmente transparente para os restantes servios, pois a esta mudana interna ao
servio subsistema. Para os utilizadores dos servio de comunicao, que o caso do
servio subsistema, desconhecida a implementao do servio, tendo apenas a
informao da interface. Neste caso apenas seria necessrio alterar no servio
subsistema o novo servio de comunicao responsvel pelo hardware. Visto que a
69
70
interface do servio de comunicao se mantm entre implementaes, a

implementao do servio subsistema no sofre alteraes, apenas necessrio que no
seu relanamento seja indicado o novo servio de comunicao responsvel pela
abstraco do novo hardware.
4.
Detalhes de implementao
4.1
Demonstrador
A demonstrao prtica atravs da implementao de um demonstrador laboratorial

crucial para a avaliao do sucesso e estabilidade da soluo proposta no captulo
anterior. Para um teste mais robusto soluo criou-se um cenrio com diversos
subsistemas envolvendo mltiplos protocolos e mltiplos fornecedores. Desta forma
conseguiu-se criar um cenrio laboratorial mais prximo da situao real.
Esta parte da dissertao teve o apoio da OMRON e da Schneider, empresas que
cederam material para a montagem do demonstrador. O objectivo foi conseguir um
cenrio em que fosse demonstrado a cooperao entre os diversos componentes.
Antes de qualquer implementao da soluo proposta, foi necessrio estudar e
programar todos os sistemas de forma isolada, em conformidade com as especificaes
do respectivo fabricante. Esse estudo e montagem est descrito nos captulos seguintes.
4.1.1
Sistema de automao OMRON
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
grfica e anloga a um esquema elctrico, encontra-se na Figura 23 um print screen do

software de desenvolvimento.
Figura 23 - CX-Programmer
Um exemplo da linguagem ladder que se mostra na Figura 23, simula o controlo do

subsistema de elevadores, para o caso em que existe apenas um elevador, sendo possvel
atravs de uma varivel de entrada fazer o seu bloqueio.
Outro subsistema que foi simulado utilizando o PLC da OMRON, foi um hipottico
sistema de alarme de CO2 num parque de estacionamento. A programao deste
subsistema pode ser consultada na Figura 24. A programao foi realizada no
pressuposto de que o sistema de controlo recebe, atravs de duas entradas, o valor do
sensor de CO2 e, dependendo desse valor, so executadas aces de controlo, que
passam por aumentar a velocidade do motor do extractor de gases e/ou accionar o
alarme de perigo.
73
74
Figura 24 - Sistema de alarme de CO2
4.1.2
Sistema de automao Schneider
A Schneider alm de solues de automao industrial, tem, atravs da sua subsidiria

TAC, solues especficas para a gesto tcnica de edifcios. Estas solues utilizam
Direct/Distributed Digital Controls (DDC) que, ao contrrio do PLC que centra o
processamento num nico ponto, esta abordagem subdivide o processamento pelos
vrios componentes utilizados na automao das diversas funcionalidades do edifcio.
Por exemplo, em vez de um nico processador estar responsvel pelo controlo de um
edifcio, este controlo pode ser efectuado recorrendo, por exemplo, a um processador
por diviso e um processador "mestre" por piso para comunicao e controlo extra piso.
Tem a vantagem de se minimizar a quantidade de cabos sados de um ponto central e,
no caso de avaria de um dos processadores, os outros no ficam comprometidos.
Os componentes utilizados no demonstrador laboratorial acima mencionado encontramse descritos no Anexo 2.
A programao destes componentes foi efectuada atravs de um software proprietrio
da TAC Schneider. Todavia, como estes componentes esto desenvolvidos para a rea
de automao de edifcios, existe programao desenvolvida para os casos mais
comuns. De qualquer forma, para uma soluo mais personalizada possvel recorrer
programao ladder. Os diversos componentes, mesmo que j pr-programados, tm
que ser associados, para que se reconheam entre eles. Esta associao efectuada
recorrendo ao software proprietrio TAC Vista Workstation (Figura 25).
Estes componentes implementam o protocolo LonWorks, apesar de neste protocolo no
existir noo de mestre e escravo, neste caso o Xenta 731 o componente que tem a
interface IP e que faz a gesto das comunicaes e controlo dos componentes com o
exterior, ligados via MS/TP, tal como se pode verificar na arquitectura fsica presente
na Figura 26.
75
76
Figura 25 - TAC Vista Workstation
4.1.3
Desenvolvimento
O desenvolvimento do demonstrador laboratorial foi efectuado de forma independente

entre subsistemas. Toda a comunicao de cooperao efectuada atravs de Ethernet e
controlada pelo BIOS. Na Figura 26 apresentada a arquitectura fsica dos
componentes do prottipo.
Na Figura 27 encontra-se uma fotografia da bancada de testes, em que alm do material
listado acima, foi tambm utilizado um hub para fazer a ligao entre os dois sistemas e
o computador, uma breadboard para fazer alguns testes e duas fontes de alimentao,
uma DC e outra AC.
Figura 26 - Arquitectura Fsica
OMRON
Schneider
Figura 27 - Bancada de testes
77
78
4.2
Desenvolvimento da arquitectura
O desenvolvimento da arquitectura foi efectuado recorrendo plataforma Java, podendo

dessa forma tirar o partido de algumas iniciativas open source, nomeadamente o Jini e o
JavaSpaces.
O desenvolvimento da arquitectura, tal como na arquitectura proposta, est dividido em
quatro partes: bus cooperativo, servios de comunicao, servios de subsistema e
clientes. Na Figura 28 apresenta-se a arquitectura implementada, a qual inclui todas
estas partes: o bus cooperativo a laranja; os servios de comunicao a azul; os servios
de subsistema a verde, incluindo todos os parmetros que cada subsistema permite
monitorizar e/ou controlar; e os clientes a vermelho.
Figura 28 - Arquitectura implementada
4.2.1
Bus cooperativo
Para a implementao do bus cooperativo recorreu-se a duas tecnologias open source,

Jini e JavaSpaces.
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
O JavaSpaces um sistema distribudo baseada na linguagem de coordenao Linda

[38], e a sua implementao recorre a diversas tecnologias da Sun. Alm de fazer parte
do sistema Jini faz extenso API Jini. O suporte da rede fornecido pelo protocolo
Java RMI (Remote Method Invocation). A distribuio das classes para os diversos
clientes feita atravs de Hypertext Transfer Protocol (HTTP) atravs de mecanismos
de Code Base [38].
Os tuplos podem ser criados pelo programador desde que a classe implemente a
interface Entry do Jini. A pesquisa de tuplos no TS, j prevista no projecto Linda, feita
tendo apenas em considerao os campos pblicos dessa implementao. Para fazer a
pesquisa criam-se anti-tuplos (em JavaSpaces so templates) para posteriormente ser
feita a correspondncia com os tuplos no TS [38].
O JavaSpaces oferece ainda um mecanismo de registo e subscrio de eventos, em que
o objecto registado notificado sempre que exista uma escrita que corresponda Entry
para a qual pretende ser notificado.
4.2.2
Servios de comunicao
O servio de comunicao disponibilizado implementa a interface ICommunication

descrita na Figura 29. A comunicao tem uma interface simples em que as interaces
com os componentes so efectuadas atravs de mtodos setTag e getTag, em que
apenas alteram ou obtm o valor de determinado endereo. Para o caso do componente
a interagir ser do tipo booleano existe a necessidade, em alguns sistemas,
nomeadamente nos PLCs, de ter a informao de qual o endereo do bit a interagir, da
existir um dos mtodos getTag e setTag especfico para responder a esta necessidade.
possvel registar um listner para ser notificado cada vez que exista alteraes em
determinado componente. O mtodo criado para esse efeito o monitorDataChange.
Com esta funcionalidade possvel evitar que as aplicaes tenham que implementar
um sistema de polling para verificao das alteraes.
Figura 29 - ICommunication
Cada hardware tem as suas necessidades e especificao para o seu controlo e

monitorizao por parte de uma entidade externa, no caso dos implementados tem-se os
protocolos OPC-UA e FINS para a comunicao entre a aplicao e o hardware.
O cdigo responsvel pelo lanamento dos servios de comunicao pode ser
visualizado na Listagem 1. O cdigo utilizado para o lanamento de servios
semelhante entre os restantes implementados, as diferenas residem no tipo de servio a
ser lanado, neste caso o tipo ICommunication onde so lanados os servios de
comunicao da OMRON e da Schneider.
public static void main(String[] args) throws RemoteException {
LinkedList<ICommunication> communications=new
LinkedList<ICommunication>();
communications.add(new CommunicationOMRON());
communications.add(new CommunicationSchneider());
new CommunicationService(communications);
Object keepAlive = new Object();

synchronized (keepAlive) {
try {
keepAlive.wait();
}
catch (InterruptedException e) { e.printStackTrace();}
}
public CommunicationService(LinkedList<ICommunication> communications) throws

RemoteException {
System.out.println("Em Construtor de CommunicationService...");
if ( System.getSecurityManager()==null ) {
System.setSecurityManager(new RMISecurityManager());
}
LookupDiscovery lookupDiscovery=null;
try {
for(ICommunication communication : communications){
serviceProxySimpleCommunication.add(communication);
81
82
lookupDiscovery = new LookupDiscovery(

new String[]{"Communications"});
joinManagers.add(new JoinManager(communication.getProxy(),
new Entry[]{new Name(communication.getName())},
this,lookupDiscovery,leaseRenewalManager));
}
} catch (RemoteException e1) {
e1.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
System.out.println("Servios lanados");
Listagem 1 - Lanamento servios de comunicao
4.2.2.1 Servio de comunicao Schneider

Os componentes instalados tm autonomia na sua gesto e controlo. Todavia, para a
monitorizao e controlo do sistema por parte de uma entidade externa, estas operaes
tm que ser realizadas atravs do componente Xenta 731, que alm de ser um
controlador, tambm um webserver que de forma proprietria disponibiliza aces
sobre os componentes.
Visto que o webserver apenas permite monitorizao do valor das variveis envolvidas
no sistema de controlo, disponibilizando apenas pginas de internet previamente
programadas pelo instalador, foi necessrio encontrar outra soluo, para interagir com
o sistema. A soluo encontrada foi o OPC UA, em que o servidor o Xenta 731 e
atravs de um SDK (Software Development Kit) de cliente OPC UA em Java facilita a
implementao do servio de comunicao.
A Schneider apenas disponibiliza um servidor OPC clssico (OPC DA), e isso implica
recorrer a um Wrapper (Figura 30), j previsto na migrao para o novo OPC UA [33],
que encapsulasse o servidor DA num servidor UA. Recorreu-se verso de avaliao de
um Wrapper disponibilizado online pela empresa Unified Automation, de nome
UaGateway [39]. Desta forma fica resolvida a parte do servidor OPC UA, pois a
estrutura e informao de todos os componentes j existente no Xenta 731 mantm-se.
Figura 30 - UA wrapper que permite o acesso a servidores OPC DA [33]
O cliente OPC UA foi desenvolvido recorrendo ao SDK disponibilizado pela empresa

Prosys, de nome Prosys OPC UA Java SDK [40] e este cliente que vai assegurar a
implementao do servio de comunicao Schneider.
No lanamento do servio de comunicao o cliente liga-se ao servidor OPC UA, e as
implementaes dos mtodos getTag e setTag utilizam directamente os mtodos
disponibilizados pelo SDK readValue e writeValue. Estes mtodos recebem um
NodeId, que o identificador de cada componente no servidor OPC UA. A
implementao destes mtodos encontram-se na Listagem 2.

@Override
public Object getTag(String urlStr, String description) throws
RemoteException{
try {
return
client.readValue(getNodeId(urlStr,description)).getValue().getValue();
} catch (ServiceException e) {
throw new RemoteException("ServiceException",e.getCause());
} catch (StatusException e) {
throw new RemoteException("StatusException",e.getCause());
}
}
@Override
public void setTag(String urlStr, String description, String tagValue) throws
RemoteException{
try {
client.writeValue(getNodeId(urlStr,description), tagValue);
}
}
Listagem 2 - Mtodos getTag e setTag - Schneider
83
84
Para a notificao de alterao de estado de determinado elemento necessrio no

registo, identificar o Node que se quer acompanhar e o ListnerID a ser notificado
quando
existirem
alteraes.
Recorre-se
uma
funcionalidade
semelhante
disponibilizada pelo servidor OPC UA que permite a subscrio de notificao de

alteraes
em
determinado
Node.
Essas
notificaes
so
feitas
para
um
MonitoredDataItemListener, classe disponibilizada pelo SDK. Quando existem
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.
Figura 31 - Sequncia de notificao de alteraes - Schneider
public void monitorDataChanges(String urlStr, String description,

String idx, String listnerID) throws RemoteException {
MonitoredDataItem item;
try {
NodeId nodeId=getNodeId(urlStr, description);
item = new MonitoredDataItem(nodeId, Attributes.Value,
MonitoringMode.Reporting);
subscription.addItem(item);
item.addChangeListener(dataChangeListener);
listnersList.put(nodeId,listnerID);
}
}
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) {
} catch (TransactionException e) {
}
}
};
Listagem 3 - Mtodo monitorDataChanges - Schneider
4.2.2.2 Servio de comunicao OMRON

A OMRON disponibiliza uma forma simplificada para a interaco e monitorizao do
PLC por parte de uma entidade externa, sendo as correspondentes operaes
asseguradas atravs de um protocolo proprietrio, de nome FINS, atravs da porta
Ethernet. Este protocolo tem comandos pr estabelecidos representados atravs de
cdigos em hexadecimal, estando todos esses cdigos na documentao [41]. Os
comandos utilizados so construdos dependendo das necessidades: leitura ou escrita,
85
86
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
Como o PLC no fornece nenhum mecanismo de subscrio para notificao de

alteraes de estado de algum espao de memria sem que seja necessria uma
interveno na programao do prprio autmato, o mtodo monitorDataChanges no
foi implementado da mesma forma que para o equipamento da Schneider. Neste caso
necessrio que seja o prprio servio de comunicao a fazer a verificao de alteraes
atravs de polling. Todo o restante processo semelhante ao acima descrito, tal como se
pode verificar na Figura 32. O cdigo desenvolvido para efectuar o processo indicado
encontra-se na Listagem 5.
@Override
public void monitorDataChanges(String memoryType, String address,
String idx, String listnerID) throws RemoteException {
State state=new State(memoryType,address,idx,listnerID,null);
prevState.add(state);
}
public void startJavaSpaces(){
new Thread(){
public void run(){
javaSpace = (JavaSpace) FindService.lookup(JavaSpace.class);
while(true){
try{
verifyChanges();
System.err.println("ERROR: RemoteException in "+name+"
verifyChanges ("+e.getMessage()+")");
return;
}
try {
Thread.sleep(500);
} catch (InterruptedException e) {e.printStackTrace(); }
}
}
}.start();
}
private void verifyChanges() throws RemoteException {
for(State state:prevState)
{
String currState=(state.idx.equals(""))?
getTag(state.memoryType, state.address):
String.valueOf(getTag(state.memoryType, state.address,
state.idx, 1));
if(state.state==null || !currState.equals(state.state))
{
try {
javaSpace.write(new DataChangedEntry(state.listnerID), null,
1000*60);
} catch (RemoteException e) {e.printStackTrace();
<restante cdigo no relevante>
}
Listagem 5 - Mtodo monitorDataChanges - OMRON
87
88
Figura 32 - Sequncia de notificao de alteraes - OMRON
4.2.3
Servios de Subsistema
Os servios de subsistema que esto implementados so o AVAC, iluminao, energia,

elevadores e sistema de alarme de CO2 do parque de estacionamento. Todos estes
subsistemas so apenas de teste, em que todas as operaes so efectuadas atravs do
hardware embora tendo um formato simplificado do que seria a implementao real,
no a nvel das aces de controlo implementadas, mas sim na quantidade de variveis
controladas.
Os subsistemas so constitudos por diversos componentes, desde sensores, actuadores,
etc. As funcionalidades bsicas (getState, setState, monitorComponentChanges)
dos componentes esto encapsuladas nas classes Component, simplificando assim a sua
utilizao nas implementaes dos subsistemas. Existem implementados dois tipos de
componentes, os que representam componentes do tipo bit (boolean) e os do tipo word
(Object) Ainda nestes dois tipos faz-se a distino entre componentes que so apenas
de leitura ou se so tambm de escrita. Como por exemplo um sensor, que apenas um
componente de leitura, s existindo a necessidade de ficar disponvel a operao de

leitura (getState). nas classes Component que efectuada a procura do servio de
comunicao, sendo passado no construtor todas as informaes necessrias para a
procura do servio e respectivos endereos do componente, desta forma abstrai a
implementao do servio de subsistema dessa procura bem como da utilizao directa
dos endereos do componente.
Em qualquer um dos servios de subsistema so monitorizadas as alteraes de estado
dos componentes, sendo o registo dessas notificaes oferecido pelos servios de
comunicao, tal como descrito no captulo anterior, sendo utilizado o nome do servio
como listnerID. Sempre que detectada uma alterao criado uma Entry especfica
para cada subsistema que posteriormente colocada no JavaSpace, dando suporte a
funcionalidade do bus que permitir que clientes se registem em determinado subsistema
para ser notificados de alteraes.
4.2.3.1 Servio de subsistema AVAC

Este servio disponibiliza o controlo e monitorizao do subsistema de AVAC do
edifcio, permitindo monitorizar temperatura real (spaceTemp), velocidade da
ventilao actual (em percentagem)(fanSpeed), a temperatura pretendida (setpoint).
Este subsistema permite ainda a monitorizao e controlo da ocupao do espao
(occupancyRoomUnit), tendo os seguintes estados possveis: ocupado, desocupado e
em espera. Este servio implementa a interface IAvac (Figura 33) que oferece os
mtodos necessrios para todas as interaces descritas acima.
Figura 33 - IAvac
Na Listagem 6 encontra-se a implementao do servio do subsistema AVAC,

possvel verificar os diversos componentes que fazem abstraco das funcionalidades
acima
descritas,
registo
no
servio
de
notificao
de
alteraes
(monitorComponentChanges) e as implementaes do mtodos presentes na interface
89
90
descrita anteriormente. As implementaes dos mtodos tornam-se programaticamente

simples a este nvel, sendo em alguns casos apenas necessrio invocar o mtodo
getState do componente, pois tudo o restante j se encontra abstrado pelo
componente mas principalmente pelo servio de comunicao.

As implementaes dos restantes servios de subsistema so assemelham-se a esta
estrutura aqui apresentada.
public class Avac extends AbstractSubsystem implements IAvac,
RemoteEventListener{
ComponentWordReadOnly spaceTemp;
ComponentWordReadOnly setpoint;
ComponentWordReadOnly fanSpeed;
ComponentWordReadOnly occupancyRoomUnit;
ComponentWord occupancyManual;
AvacEntry previousState;
<...>
public void startJavaSpaces(){
new Thread(){
public void run(){
try {
spaceTemp.monitorComponentChanges(name);
setpoint.monitorComponentChanges(name);
fanSpeed.monitorComponentChanges(name);
occupancyRoomUnit.monitorComponentChanges(name);
occupancyManual.monitorComponentChanges(name);
javaSpace.notify(new DataChangedEntry(name), null,
(RemoteEventListener) proxy, Lease.FOREVER, null);
} catch (...) { <...> }

try {
creatAndAddEntryOnJS();
} catch (...) { <...> }
}.start();
@Override
public String getFanSpeed() throws RemoteException {
return fanSpeed.getState().toString();
}
@Override
public String getSetpoint() throws RemoteException {
return setpoint.getState().toString();
}
@Override
public String getSpaceTemp() throws RemoteException {

return spaceTemp.getState().toString();
}
@Override
public Integer getOccupancy() throws RemoteException {
int occMan=(Integer)occupancyManual.getState();
if (occMan<=3 && occMan>=0)
return occMan;
return (Integer)occupancyRoomUnit.getState();
}
@Override
public void setOccupancy(String state) throws RemoteException {
occupancyManual.setState(state);
}
<...>
}
Listagem 6 - Implementao AVAC
4.2.3.2 Servio de subsistema Iluminao

Este servio disponibiliza o controlo e monitorizao do subsistema de iluminao do
edifcio, permitindo que, a cada ponto de iluminao, esteja associado um identificador.
Isto possibilita que a cada identificador seja associada uma diviso ou uma zona da
diviso, ou mesmo um piso inteiro. Este servio implementa a interface ILighting
(Figura 34) a qual oferece os mtodos necessrios para todas as interaces descritas
acima.
Figura 34 - ILighting
4.2.3.3 Servio de subsistema Energia

Este servio disponibiliza a monitorizao do subsistema de energia do edifcio, este
subsistema importante para posteriormente ser utilizado em algoritmos de gesto
racional de energia elctrica. semelhana do subsistema de iluminao este oferece a
possibilidade de que a monitorizao seja efectuada a diversos pontos consumidores de
energia elctrica. As grandezas que so medidas neste subsistema so a corrente, tenso
e potncia activa. Este servio implementa a interface IEnergy (Figura 35) que oferece
os mtodos necessrios para todas as interaces descritas acima.
91
92
Figura 35 - IEnergy
4.2.3.4 Servio de subsistema Elevadores

O servio elevadores implementado, constitui uma verso simplificada uma vez que
apenas permite o controlo se determinado elevador se encontra em funcionamento ou
no. Isto til para efectuar o deslastre de cargas quando o algoritmo de gesto racional
de energia elctrica assim o exigir. A cada elevador est associado um identificador,
podendo por isso efectuar-se operaes sobre um elevador especfico. Este servio
implementa a interface IElevators (Figura 36) que oferece os mtodos necessrios
para todas as interaces descritas acima.
Figura 36 - IElevators
4.2.3.5 Servio de subsistema Alarme de CO2 de um parque de

estacionamento
O sistema de alarme de CO2 um subsistema comum nos parques de estacionamento.
Dependendo dos nveis de CO2 obtidos atravs do correspondente sensor, poder
eventualmente ser accionado o motor do extractor de gases e dependendo do nvel de
perigo, accionar um hipottico alarme. O servio que representa este subsistema faz
monitorizao destes trs componentes: sensor CO2, velocidade do extractor (em
percentagem) e alarme, mas tal como mencionado no Captulo 4.1.1 este subsistema
prev a possibilidade de o sensor de CO2 seja externo, logo possibilita que o valor do
sensor seja introduzido por parte de uma entidade externa atravs do mtodo
setExternalCO2Level. Este servio implementa a interface IParkingCO2 (Figura 37)
que oferece os mtodos necessrios para todas as interaces descritas acima.
Figura 37 - IParkingCO2
O sensor simulado no hardware atravs de dois interruptores, simulando trs nveis de

perigo (normal, aviso e perigo). Esta simulao do sensor efectuada no hardware
Schneider e os restantes componentes esto no hardware da OMRON, permitindo assim
comprovar
interoperabilidade
conseguida
atravs
desta
arquitectura.
Esta
interoperabilidade conseguida recorrendo ao servio de coordenao descrito no

captulo seguinte (captulo 4.2.4).
4.2.4
Servio de coordenao
A entidade de coordenao garante a interoperabilidade do sistema, esta regista-se para

ser notificada de alteraes de determinado componente, o cdigo necessrio para este
registo encontra-se na Listagem 7. O exemplo implementado a coordenao do
subsistema de alarme de CO2 em que quando se verifica alteraes no sensor de CO2
controlado pelo hardware da Schneider, essas alteraes so encaminhadas para o
hardware da OMRON, para que atravs do algoritmo de automao j implementado no
PLC, sejam executadas as correspondentes aces de controlo e alarme. Os
intervenientes do exemplo implementado encontram-se representados na Figura 38.
public Coordinator(){
if (System.getSecurityManager() == null) {
System.setSecurityManager(new RMISecurityManager());
}
Exporter exporter = new BasicJeriExporter(
TcpServerEndpoint.getInstance(0),new BasicILFactory());
try {
proxy = (RemoteEventListener) exporter.export(this);
} catch (ExportException e) {
}
93
94

parkingCO2=(IParkingCO2)FindService.lookup(new Name("ParkingCO2"));
prevLevel=0;
try {
parkingCO2EventID = javaSpace.notify(new ParkingCO2Entry(),
null, proxy,
Lease.FOREVER, null).getID();
} catch (TransactionException e) {
}
}
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
O subsistema ParkingCO2 notificado, atravs dos respectivos servios de

comunicao, sempre que existe alguma alterao de estado dos seus componentes.
Visto que o servio Coordinator est registado no JavaSpaces para ser notificado
sempre que existe alteraes no subsistema ParkingCO2, este servio ao receber uma
notificao de alterao verifica se essa foi no sensor de CO2 e em caso afirmativo
utiliza o mtodo do subsistema ParkingCO2 que permite colocar o valor do sensor por
parte de uma entidade externa, neste caso essa alterao propagada at ao hardware da
OMRON e atravs das rotinas j implementadas no PLC vai colocar o extractor a
velocidade correspondente e activar ou no o alarme. O diagrama de sequncia presente
na Figura 39 resume o processo descrito acima.
Figura 38 - Exemplo implementado
Figura 39 - Diagrama sequncia exemplo implementado
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
enviado o valor 0 (normal) para o hardware OMRON em que do algoritmo de

automao implementado resulta em parar o motor do extractor de fumos e desligar o
alarme; com um interruptor ligado enviado o valor 1 (aviso) que resulta em colocar o
motor do extractor a 50% da sua velocidade mxima; com dois interruptores ligados
enviado o valor 2 (perigo) que resulta em colocar o motor do extractor na sua
velocidade mxima e accionar o alarme de perigo (Listagem 8). No confundir o que
responsabilidade do nvel de automao, todas as decises que dizem respeito
velocidade do extractor ou alarme de perigo so da responsabilidade do nvel de
automao. No nvel de gesto, onde o BIOS se insere, onde conseguida esta
cooperao, pois atravs do sistema de Coordenao consegue-se que um subsistema
seja controlado por hardwares de fabricantes distintos ou mesmo integrar diferentes
subsistemas tal como foi exemplificado no captulo 3.
private void getAndRefreshFromJSParkingCO2() throws RemoteException,
UnusableEntryException, TransactionException, InterruptedException
{
ParkingCO2Entry parkingCO2Entry = null;
parkingCO2Entry = (ParkingCO2Entry)javaSpace.readIfExists(
new ParkingCO2Entry(),null,1000*60*30);
if(parkingCO2Entry!=null)
{
int level=parkingCO2Entry.co2Level;
if(level!=prevLevel){
switch(level){
case 2:
parkingCO2.setExternalCO2Level(2);
break;
case 1:
if(prevLevel==0)
if(prevLevel==2)
break;
case 0:
break;
}
prevLevel=level;
}
}
}
Listagem 8 - Algoritmo de coordenao
4.2.5
Servio de gesto energtica
A gesto energtica um servio que possibilita, por exemplo, atravs da interface

grfica, a activao de algoritmos de gesto racional de energia elctrica. O algoritmo
implementado apenas verifica se o consumo de energia elctrica (power) corresponde a
5%
(maxContractedEnergyInUse)
de
se
ultrapassar
potncia
contratada
(contractedEnergy) e em caso afirmativo faz o deslastre de cargas. Neste caso coloca

os elevadores (elevators) a garantir apenas os servios mnimos, em que apenas um
elevador fica em funcionamento. Na Listagem 9 encontra-se a implementao deste
algoritmo.
Esta arquitectura potencia a criao de outros algoritmos, pois o acesso a determinado
subsistema est facilitado, sendo apenas necessrio recorrer ao servio subsistema em
causa para obter a sua informao e controlo.
float power = energyEntry.energyPoints.get(energyMainPointID).power;
if(power>=contractedEnergy*maxContractedEnergyInUse){
String[] ids;
try {
ids = elevators.getAllIDs();
for(String id:ids){
if(!id.equals(mainsElevatorID)){
if(!elevators.isLocked(id))
elevators.Lock(id, true);
}
} catch (RemoteException e) {e.printStackTrace();}
}
Listagem 9 - Algoritmo de gesto energtica
4.2.6
Interface Grfica
A interface grfica integra todos os subsistemas mencionados acima e ainda o servio

de gesto energtica. Apesar do demonstrador ser composto por dois sistemas de
controlo diferente, atravs do BIOS possvel integrar com facilidade todos os
subsistemas numa nica aplicao grfica.
A aplicao implementada apenas tem conhecimento das interfaces dos servios de
subsistema, obtendo os servios atravs do servio de Lookup do Jini, e registando-se no
servio JavaSpaces para que seja notificada de alteraes de estado para posterior
actualizao da interface grfica. Estas notificaes esto esquematizadas na Figura 31 e
Figura 32.
97
98
Na Figura 40 encontra-se uma primeira verso da interface grfica, no sendo o

grafismo um elemento importante para esta dissertao, tentou-se que o aspecto fosse o
melhor possvel.
Figura 40 - Interface grfica
5.
Concluses e Trabalho Futuro

O objectivo desta dissertao de Mestrado era o de estudar solues que permitissem
facilitar o desenvolvimento da integrao de subsistemas utilizados na automao de um
edifcio inteligente. O ciclo de vida de um edifcio est dividido em trs partes, a
elaborao do projecto, a sua implementao e ainda, a que fica at ao fim da vida do
edifico, a sua explorao/gesto. Atravs da cooperao possvel facilitar as decises e
desenvolvimentos em todos os momentos do ciclo de vida do edifcio, pois possvel
reduzir redundncias de hardware, optimizar os algoritmos de gesto racional de
energia elctrica e at maximizar o controlo sobre um edifcio, conseguindo fazer a
monitorizao de todo o edifcio atravs de uma nica aplicao grfica.
O estudo desenvolvido passou pela avaliao do Estado da Arte neste domnio do
conhecimento. Numa primeira parte so descritas as mais valias de optar por um sistema
aberto em vez de sistemas proprietrios. Juntamente com esta comparao foram
estudados e comparados trs protocolos abertos BACnet, LonWorks e KNX. Na
segunda parte so descritas iniciativas que tendem a resolver alguns dos factores crticos
que dizem respeito a interoperabilidade. Nesta descrio foi dado nfase ao oBIX,
projecto cujos objectivos se aproximam do BIOS e ao OPC UA cujos conceitos vieram
a ser utilizados para assegurar a comunicao com os componentes Schneider.
Posteriormente foi proposta uma arquitectura cujo objectivo era resolver o problema
descrito. A soluo adoptada foi uma arquitectura orientada a servios. As vrias
responsabilidades, seja de comunicao entre hardware e arquitectura, ou abstraco de
determinado subsistema fsico,
foram divididas pelos diversos servios propostos.
Todos estes servios comunicam e interagem atravs de um bus, aproximando esta

arquitectura da lgica plug-and-play, podendo facilmente ser adicionados novos
servios e os existentes os reconhecerem.
Foi construdo um demonstrador recorrendo ao hardware cedido pelas empresas
OMRON e Schneider. Esse demonstrador tenta que os testes da arquitectura proposta se
aproximem ao mximo de um caso real. Analisado o material disponvel foi
desenvolvido um caso de estudo, em que foram criados subsistemas controlados por
esse hardware e posteriormente integrados na arquitectura proposta. Esta arquitectura
99
100
5 Concluses e Trabalho Futuro
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:
Carregamento dinmico dos diversos subsistemas, tanto ao nvel de servios,

como posteriormente o carregamento da interface grfica;
Dinamismo na interface grfica, de forma a facilitar e melhorar a sua usabilidade

para o utilizador;
Autenticao do utilizador, recorrendo a um servidor Lightweight Directory

Access Protocol (LDAP) de forma a restringir o acesso do utilizador a
determinadas funcionalidades da interface grfica;
Teste da arquitectura num ambiente real, atravs da implementao da soluo

num edifcio;
Desenvolver algoritmos de gesto racional de energia elctrica mais complexos,

podendo por exemplo envolver agentes ou sistemas de apoio deciso.
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.
6 Bibliografia e referncias 103
[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.
Anexo 1: Sistema de automao OMRON - Descrio

dos equipamentos
Os equipamentos disponibilizado pela OMRON so dotados de um bus que permite
agregar outros mdulos ao mdulo central de processamento. A soluo disponibilizada
pela OMRON e aplicada no demonstrador laboratorial tem um nico processador que
sobre o mesmo bus controla os demais equipamentos, todos equipamentos da OMRON
envolvidos nesta soluo encontram-se descritos na tabela seguinte:
PA 202
Fonte de alimentao
CJ1M CPU11 ETN
Processador com comunicao Ethernet integrada
ID 201
Entradas digitais
OD 201
Sadas digitais
105
106
Anexo 1
MAD 42
Entradas e sadas analgicas
SCU41-V1
Mdulo de comunicao RS232/485
Anexo 2: Sistema de automao Schneider - Descrio

dos equipamentos
Os equipamentos disponibilizado pela Schneider comunicam sobre o protocolo
LonWorks e ao contrrio da soluo da Schneider estes so descentralizados, o que
significa que o controlo se divide pelos diversos equipamentos. Todos os equipamentos
disponibilizados pela Schneider e envolvidos no demonstrador laboratorial encontramse descritos na tabela seguinte:
Xenta 731
Controlador central, ponto de acesso da rede exterior
Xenta 121
Controlador de AVAC pr-programado
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
Mdulo de extenso de entradas e sadas digitais
107
108
Anexo 2
PM9C
Contador de energia em tempo real

Dissertação Bacnet e OPC PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Dissertação Bacnet e OPC PDF

Enviado por

Direitos autorais:

Formatos disponíveis

INSTITUTO

Departamento de Engenharia de Electrnica e Telecomunicaes e

Building Intelligence Open System (BIOS)

Fbio Ruivo Ferreira

Dissertao de natureza cientfica realizada para obteno do grau de

Palavras chave: BAS, interoperabilidade, subsistemas de um edifcio, SOA

Notao utilizada ............................................................................................... 7

Estrutura da dissertao ..................................................................................... 7

Estado da Arte .......................................................................................................... 9

Subsistemas de um edifcio inteligente ...................................................... 9

Tipos de sistemas de controlo................................................................... 17

Enquadramento do problema ............................................................................. 9

Tecnologias em edifcios ................................................................................. 27

Comparao LonWorks, BACnet e KNX ................................................ 47

Open Building Information eXchange (oBIX) ......................................... 50

Arquitectura proposta ............................................................................................. 59

Servio de descoberta ............................................................................... 61

Servio de partilha de informao ............................................................ 62

Servio de Comunicao ................................................................................. 62

Servio de Subsistema ..................................................................................... 63

Sistema de gesto integrada ............................................................................. 64

Sistema de gesto energtica ........................................................................... 65

Sistema de coordenao ................................................................................... 67

Adaptao mudana ...................................................................................... 69

Detalhes de implementao .................................................................................... 71

Sistema de automao OMRON............................................................... 71

Sistema de automao Schneider ............................................................. 75

Desenvolvimento da arquitectura .................................................................... 78

Bus cooperativo ........................................................................................ 79

Servios de Subsistema ............................................................................ 88

Servio de coordenao ............................................................................ 93

Servio de gesto energtica..................................................................... 97

Interface Grfica ....................................................................................... 97

Concluses e Trabalho Futuro ................................................................................ 99

Bibliografia e referncias...................................................................................... 101

Anexo 1: Sistema de automao OMRON - Descrio dos equipamentos .................. 105

Building Automation System

Building Intelligence Open System

Open Building Information Exchange

Programmable Logical Controlers

Direct/Distributed Digital Controls

Software Development Kit

Application Programming Interface

Service Oriented Achitecture

OLE for Process Control

Open Process Control Unified Architecture

OLE for Process Control Data Access

Aquecimento, Ventilao e Ar Condicionado

Figura 1 - Edifcio e os seus diversos subsistemas

Figura 2 - Fases de um projecto e suas dificuldades

Ao tema actual da preservao do meio ambiente, manifesta-se num conjunto de

Figura 3 - Consumo energtico da UE-27 por sector [1]

As actuais solues que garantem a gesto integrada de um conjunto de subsistemas

Figura 4 - Building Intelligence Open Service Bus (BIOSBus)

Todavia, o esquema na Figura 4 d origem a uma questo fundamental, ou seja, como

Esta dissertao inicia-se com a anlise do Estado da Arte. No captulo 2 efectuado o

De forma a ter conscincia do que envolve a gesto integrada de um edifcio de

Subsistemas de um edifcio inteligente

Neste subcaptulo so descritos os subsistemas mais relevantes e comuns num edifcio.

Figura 5 - Sistema completo de CCTV[3]

2.1.1.1.2 Alarmes de intruso

2.1.1 Subsistemas de um edifcio inteligente 11

2.1.1.1.3 Alarmes internos (Incndio, Inundao, Gs)