INSTITUTO DE TECNOLOGIA PARA O DESENVOLVIMENTO – LACTEC
CARLOS ANDRÉ BARBOSA DE ALMEIDA
ONTOLOGIAS APLICADAS À MODELAGEM DE SISTEMAS DE
AUTOMAÇÃO PREDIAL VISANDO RESPOSTA AUTOMÁTICA À
DEMANDA EM REDES ELÉTRICAS INTELIGENTES
Curitiba
2015
INSTITUTO DE TECNOLOGIA PARA O DESENVOLVIMENTO – LACTEC
CARLOS ANDRÉ BARBOSA DE ALMEIDA
ONTOLOGIAS APLICADAS À MODELAGEM DE SISTEMAS DE
AUTOMAÇÃO PREDIAL VISANDO RESPOSTA AUTOMÁTICA À
DEMANDA EM REDES ELÉTRICAS INTELIGENTES
Projeto de Dissertação apresentado ao
Programa
de
Pós-Graduação
em
Desenvolvimento de Tecnologia, Área de
Concentração
Sistemas
Energéticos
Convencionais e Alternativos, do Instituto de
Tecnologia para o Desenvolvimento, em
parceria com o Instituto de Engenharia do
Paraná, como parte das exigências para a
obtenção
do
título
de
Mestre
em
Desenvolvimento de Tecnologia.
Orientador: Prof. Dr. Silvio Segura Salas
Coorientador: Prof. Dr. Lúcio de Medeiros
Curitiba
2015
DEDICATÓRIA
Dedico este trabalho à minha família, fonte
inesgotável da energia mágica que nos move, o amor.
AGRADECIMENTOS
Agradeço aos professores do Mestrado do Institutos LACTEC, que direta ou
indiretamente contribuíram para este trabalho, mas particularmente ao meu orientador
Prof. Dr. Silvio Salas, que desde a graduação sempre depositou grande confiança na
minha capacidade e ao Prof. Dr. Lúcio de Medeiros, por suas contribuições sempre
assertivas.
Agradecimento especial à minha família, que me apoiou nesta trajetória, com ênfase
ao meu filho Fábio.
RESUMO
O uso eficiente da energia elétrica implica em ações de eficiência energética,
conservação de energia e programas de gerenciamento pelo lado da demanda que
geram benefícios aos consumidores. A emergente possibilidade de uso da geração
distribuída, dentro do conceito de smart grids, coloca os prossumidores como agentes
ativos, particularmente grandes consumidores como prédios comerciais. Uma das
lacunas neste processo são modelos que representem os sistemas prediais de forma
eficiente e que acompanhe a dinâmica dos referidos sistemas. A modelagem proposta
neste trabalho emprega ontologias para gerar um modelo do domínio de
conhecimento dos sistemas prediais, alcançando as redes elétricas com possibilidade
de representar, de forma simples e dinâmica, a capacidade de geração, de consumo,
dos emergentes programas de gerenciamento pelo lado da demanda (DSM) e as
estratégias de resposta à demanda (DR). Particularmente com informações gerenciais
sobre o perfil das cargas, capacidade de resposta à demanda com base no perfil de
cada sistema predial empregando modelo de comunicações openADR. Este padrão é
atualmente adotado pelas indústrias de automação predial de forma global para
possibilitar a interoperabilidade entre os sistemas prediais e as redes elétricas
inteligentes visando resposta automática à demanda (ADR). Uma aplicação web foi
desenvolvida para demonstrar a aplicabilidade prática da metodologia proposta de
modelagem de sistemas prediais e redes elétrica através de ontologias e
armazenando dados de forma persistente em um banco de dados trivial (TDB). No
estudo de caso o conceito de resposta à demanda provável (RDP) é proposto para
fins de análise do modelo. Os resultados são apresentados através de curvas de
cargas e gráficos estatísticos. Esta abordagem metodológica de sistemas prediais
possibilita o uso de máquinas de inferência para abstrair informações não explícitas,
empregando lógica descritiva de primeira ordem. A principal vantagem da metodologia
proposta é permitir que o modelo seja alterado em função de necessidades da rede
elétrica ou sistema predial sem a necessidade de alteração da estrutura do banco de
dados, possibilitando crescimento e adequação no modelo em tempo de execução de
aplicações.
Palavras chave: Ontologias. Redes Elétricas. Sistemas Prediais. Resposta à
Demanda. OpenADR. DSM. SmartGrid.
ABSTRACT
The efficient use of electric power entails energy efficiency and conservation
measures, as well as management programs from the demand side, which generate
benefits to consumers. The emerging possibility of using the distributed energy
resources within the concept of smart grids places prosumers as active agents,
particularly large consumers such as commercial buildings. One of the gaps this
process are models that represent the building systems efficiently and to follow up the
dynamics of such systems. The model proposed in this paper employs ontologies to
produce a model of the knowledge domain of building systems, reaching electric grids
with the possibility of representing in a simple and dynamic way the generation and
consumption capacities, demand side management (DSM) and demand response
(DR) strategies, particularly with management information on the profile of loads and
demand response capacity based on the profile of each building system employing
OpenADR communications. This standard is currently adopted by the building
automation globally industries to enable interoperability between building systems and
smart grids aiming automatic response to demand (ADR). A web application was
developed to demonstrate the practical applicability of the proposed methodology for
modeling building systems and electrical grids through ontologies and storing data
persistently in trivial databases (TDB). In the case study, the concept of probable
demand response (RDP) is presented in the proposed case study. The results are
displayed using load curves and statistical charts. This methodological approach to
building systems allows the use of inference engines to abstract non-explicit
information, by employing descriptive logic of first order. The major advantage of the
proposed methodology is to allow the model to be modified in accordance of the
electrical grid needs or the building system without with no need to change the
database structure, thus allowing the model to grow and adapt during runtime.
Keywords: Ontology. Electrical Networks. Building Systems. Demand Response.
OpenADR. DSM. SmartGrid.
LISTA DE FIGURAS
Figura 1 - Energias Renováveis ................................................................................ 16
Figura 2 - Geração de energia elétrica no Brasil. ...................................................... 17
Figura 3 - Níveis potenciais de conservação de energia. .......................................... 18
Figura 4 - Novos empreendimentos em geração ...................................................... 19
Figura 5 – Disciplinas de um BAS. ............................................................................ 26
Figura 6 - Curva de controle residual. ....................................................................... 33
Figura 7 - Estratégias de DSM. ................................................................................. 35
Figura 8 - Hierarquia de três níveis ........................................................................... 37
Figura 9 - – Protocolos e as respectivas camadas no padrão ISO. .......................... 38
Figura 10- Conceptualização de domínio. ................................................................. 40
Figura 11 - Taxonomia das classes de um domínio .................................................. 46
Figura 12 - Gráfico RDF. ........................................................................................... 51
Figura 13 – Níveis de Modelos de semântica na Web .............................................. 52
Figura 14- SOA e mecanismos internos. ................................................................... 53
Figura 15 - Pilha de padrões Web Services .............................................................. 54
Figura 16 - Operações e atores em Web Services.................................................... 55
Figura 17 - Pilhas de protocolos em Web Services ................................................... 56
Figura 18 - Aplicação do BIM no padrão COBie........................................................ 59
Figura 19 - Atributos estendidos de um equipamento. .............................................. 60
Figura 20 - Arquitetura do BAMie com os níveis conceituais. ................................... 62
Figura 21 - Aplicação do BAMie na integração de sistemas. .................................... 63
Figura 22 - Modelo de Objeto no oBIX. ..................................................................... 65
Figura 23 - Modelo do FSGIM. .................................................................................. 67
Figura 24- Curva de Carga típica do dia de maior consumo. .................................... 68
Figura 25 - Comparação entre perfis de consumo residencial. ................................. 68
Figura 26 - Influência dos preços na frequência da rede. ......................................... 69
Figura 27 - Arquitetura do openADR 2.0 ................................................................... 71
Figura 28 - Caso de uso do openADR. ..................................................................... 72
Figura 29 - Contexto do trabalho ............................................................................... 77
Figura 30 - Arquitetura do Jena Apache. ................................................................... 79
Figura 31 - Diagrama de componentes do servidor. ................................................. 80
Figura 32 - Ambiente de Simulação. ......................................................................... 84
Figura 33 - Caso de Uso Modelo Ontologia Predial. ................................................. 85
Figura 34 - Diagrama de Interações processo de cadastro BMS. ............................. 86
Figura 35 - Diagrama de Interações consulta DR. .................................................... 87
Figura 36 - Ontograph das superclasses da Ontologia Predial. ................................ 88
Figura 37 - Classes da Ontologia Predial. ................................................................. 89
Figura 38 - Inferências geradas pelo Hermit. ............................................................ 90
Figura 39 - Detalhe da classe “Classificação”. .......................................................... 91
Figura 40 - Data Properties. ...................................................................................... 92
Figura 41 – Object Properties.................................................................................... 92
Figura 42 - Indiviuals da Ontologia. ........................................................................... 93
Figura 43 - Ontograph da Ontologia de Demandas................................................... 95
Figura 44 - Classes da Ontologia de Demandas. ...................................................... 95
Figura 45 - Object Properties da Ontologia de Demandas. ....................................... 96
Figura 46 - Data Properties da ontologia de demandas. ........................................... 97
Figura 47 - Tela do Editor Protégé da ontologia de demandas. ................................ 98
Figura 48 - Modelo do banco de dados SQLite 3 da aplicação ................................. 99
Figura 48 - Modelo do bando de dados da aplicação .............................................. 100
Figura 50 - Fluxo de mensagens no modelo MVC .................................................. 100
Figura 51 - Curva de Demanda Ar Condicionado no Prédio_4. .............................. 103
Figura 52 - Diagrama do sistema modelado ........................................................... 106
Figura 53 - Gráfico da RDP Alimentador_1 ............................................................. 109
Figura 54 - Gráfico do DER Alimentador_1 ............................................................. 110
Figura 55 - Gráfico da participação dos recursos na demanda do Alimentador_1 .. 110
Figura 56 - Demanda total no Alimentador_1 .......................................................... 111
Figura 57 - Demandas individuais dos recursos sobre o Alimentador_1 ................. 111
Figura 58 - Curva da RDP no Alimentador_1 .......................................................... 112
Figura 59 - Detalhe dos dados do recurso .............................................................. 113
Figura 60 - Gráficos estatísticos do Shopping_Center ............................................ 115
Figura 61 - Demanda do Prédio_2 .......................................................................... 116
Figura 62 - Demandas dos recursos do sistema predial Prédio_2 .......................... 116
LISTA DE TABELAS
Tabela 1 - Comparativo Engenharia de Aplicação versus Engenharia de Domínio .. 41
Tabela 2 - Classificação das Ontologias ................................................................... 44
Tabela 3 -Exemplos de regras de inferências em OWL. ........................................... 48
Tabela 4- Evolução da World Wide Web. .................................................................. 49
Tabela 5 – Programas de DSM. ................................................................................ 67
Tabela 6 - Comparativo entre Model-Drive Design e OWL/RDF. .............................. 78
Tabela 7 – Tabelas do banco de dados da aplicação ............................................... 99
LISTA DE SIGLAS
AEE – Ações de Eficiência Energética
ANEEL – Agência Nacional de Energia Elétrica
ADR – Automated Demand Response
API - Application Programming Interface
BEMS – Building Energy Management System
BMS – Building Management System
BAS – Building Automation System
BACnet – Building Automation Control Network
DALI – Digital Addressable Lighting Interface
DR – Demand Response
DRAS – Demand Response Automated Server
DER – Distributed Energy Resources
DSM – Demand Side Management
CFTV – Circuito Fechado de TV
ECMS – Energy Control and Management System
EIBG – European Intelligent Building Group
FIPA – Foundation for Intelligent Physical Agents
IEA – International Energy Agency
IETF – Internet Engineering Task Force
IFC – Industry Foundation Classes
IRI – Indiviudual Resource Identification
EPE – Empresa de Pesquisa Energética
ERA – Entity Relationship Modeling
EAI – Enterprise Architeture Integration
EIBG - European Intelligent Buildind Group
INEE - Instituto Nacional de Eficiência Energética
HVAC – Heating, Ventilation and Air Conditioning
HTTP – Hyper Text Transfer Protocol
JIBI – Japanese Intelligent Building Institute
JVM - Java Virtual Machine
ODBC – Open Data Base Conectivity
OLE – Object Linking and Embbeding
OPC – OLE for Process Control
ORM – Object Role Model
OWL – Web Ontology Language
PIMVP – Protocolo Internacional de Medição e Verificação de Performance
PROINFA – Programa de Incentivo às Fontes Alternativas de Energia Elétrica
P&D – Pesquisa e Desenvolvimento
REI – Redes Elétricas Inteligentes
RDF – Resource Description Framework
SAI – Sistema de Alarme de Intrusão
SCA – Sistema de Controle de Acesso
SDAI – Sistema de Detecção de Alarme de Incêndio
SOA – Service Oriented Architeture
TDB – Trivial Data Base
VEN – Virtual End Node
VTN – Virtual Top Node
UML – Unified Modeling Language
URI – Uniform Resource Identification
URL – Uniforme Resource Locator
XML – Extended Markup Language
WEO – World Energy Outlook
W3C – World Wide Web Consortium
SUMÁRIO
1
2
INTRODUÇÃO .......................................................................... 16
1.1
Justificativa ................................................................................................... 21
1.2
Objetivos ...................................................................................................... 22
1.3
Organização do trabalho .............................................................................. 23
FUNDAMENTAÇÃO TEÓRICA .................................................... 24
2.1
Prédios inteligentes ...................................................................................... 24
2.2
Sistemas de Automação Predial .................................................................. 25
2.2.1
Utilidades prediais – BMS ...................................................................... 26
2.2.2
Controle ambiental - Ar condicionado (HVAC) ...................................... 27
2.2.3
Monitoramento - (CFTV) ........................................................................ 27
2.2.4
Proteção – (SDAI).................................................................................. 28
2.2.5
Segurança - (SAI e SCA) ....................................................................... 28
2.3
Redes Elétricas Inteligentes ......................................................................... 29
2.4
Controle de Demanda .................................................................................. 31
2.5
Gerenciamento pelo lado da demanda ........................................................ 34
2.6
A resposta à demanda ................................................................................. 35
2.7
Protocolos de comunicação ......................................................................... 37
2.8
Engenharia de Ontologias ............................................................................ 39
2.8.1
Conceitos Básicos ................................................................................. 39
2.8.2
A Engenharia de Domínios .................................................................... 41
2.8.3
Classificação das Ontologias ................................................................. 43
2.8.4
Elementos de uma Ontologia ................................................................ 45
2.8.5
Desenho de Ontologias ......................................................................... 47
2.8.6
Inferências em Ontologias ..................................................................... 48
2.9
A Word Wide Web e a Semântica Web........................................................ 48
2.9.1
A Semântica Web .................................................................................. 50
2.9.2
Arquitetura SOA e Web Services........................................................... 53
2.10
3
REVISÃO BIBLIOGRÁFICA ........................................................ 57
3.1
4
Considerações Finais do capítulo ............................................................. 56
MODELAGEM DE SISTEMAS PREDIAIs .................................................... 58
3.1.1
Modelo Cobie......................................................................................... 59
3.1.2
Modelo BAMie ....................................................................................... 60
3.1.3
Modelo oBIX .......................................................................................... 63
3.1.4
MODELO FSGIM – ASHRAE ................................................................ 66
3.2
Estratégias de gerenciamento pelo lado da Demanda ................................. 67
3.3
O MODELO DE COMUNICAÇÃO OpenADR .............................................. 70
3.4
ESTADO DA ARTE sobre INTEROPERABILIDADE.................................... 74
3.5
Considerações finais do capítulo ................................................................. 75
Materiais e Métodos .................................................................. 76
4.1
contextualização da solução proposta ......................................................... 76
4.2
Materiais....................................................................................................... 79
4.2.1
Web Services - Apache JENA ............................................................... 79
4.2.2
O SPARQL ............................................................................................ 81
4.2.3
O Trivial DataBase – TDB ..................................................................... 81
4.3
Métodos ....................................................................................................... 82
4.3.1
O Ambiente de Simulação ..................................................................... 83
4.3.2
Ontologia Predial ................................................................................... 87
4.3.3
A Ontologia de Demandas ..................................................................... 93
4.3.4
Preparação do Servidor JENA ............................................................... 98
4.3.5
Autenticação do usuário na aplicação ................................................. 101
4.3.6
Página de inserção de dados .............................................................. 101
4.3.7
4.4
5
6
Conceito de Resposta à Demanda Provável ....................................... 102
Considerações finais Do Capítulo .............................................................. 104
Estudo de Caso ...................................................................... 105
5.1
Dados INseridos para o Estudo de Caso ................................................... 107
5.2
Análise de dados dos Alimentadores ......................................................... 109
5.3
Análise de dados dos Sistemas Prediais (Consumidores) ......................... 112
CONCLUSÕES ....................................................................... 117
6.1
Trabalhos futuros ....................................................................................... 118
REFERÊNCIAS ............................................................................. 120
APÊNDICE A – Aplicação W eb Demandas ...................................... 125
ANEXO 1 – EDITOR DE ONTOLOGIAS PROTÉGÉ .......................... 134
16
1
INTRODUÇÃO
O atual estágio do desenvolvimento tecnológico exige que as soluções para
os problemas diários que a sociedade enfrenta sejam fruto do esforço de pesquisas
multidisciplinares, envolvendo diversas áreas do conhecimento humano. Neste
sentido, a tecnologia de informação, que é o núcleo deste trabalho, mostra-se
essencial para permitir o gerenciamento da grande quantidade de conhecimento
acumulado pela sociedade em seu caminho de constante evolução.
A área de energia, essencial para o desenvolvimento econômico e social
de uma nação, apresenta-se como um dos campos de pesquisa mais promissores,
considerando-se sua aplicação em todas as áreas das atividades humanas, sendo a
energia um insumo essencial para o bem-estar e o progresso social.
A matriz energética brasileira caracteriza-se por ser uma das mais limpas
do mundo conforme ilustra o gráfico da Figura 1, publicado no site da Empresa de
Pesquisa Energética (EPE), onde se percebe a elevada participação das fontes
renováveis na geração de energia em relação aos demais países.
Figura 1 - Energias Renováveis
Fonte: EPE (2014).
A energia elétrica, englobando as mais diversas modalidades de produção
ou geração, transmissão, distribuição, consumo e aplicação é uma das formas de
17
energia mais difundidas, presente no dia a dia das pessoas e cuja falta pode significar
grandes danos a toda cadeia produtiva e à sociedade como um todo.
Esta área de conhecimento tecnológico vem sendo objeto de diversos
estudos científicos e do desenvolvimento de equipamentos, técnicas e sistemas
visando aperfeiçoar a produção, distribuição, armazenamento e consumo desta forma
de energia.
A demanda mundial por energia deverá crescer em cerca de um terço da
capacidade atual de geração até 2035, segundo o World Energy Outlook 2012
(WEO2012), da Agencia Internacional de Energia (IEA), havendo uma grande
preocupação com o aumento das emissões de CO2. Ações de eficiência energética
podem retardar o aumento da temperatura média da terra e suas consequências
ambientais IEA (2012).
No Brasil, de acordo com o Plano Nacional de Energia 2030 (PNE2030),
há uma estimativa de um consumo de energia elétrica da ordem de 1.083 TWh até
2030, representando um aumento médio de 4,0% ao ano considerado o ano base
2005.
A estratégia para atender esta demanda, segundo o PNE2030 contempla
iniciativas induzidas de eficiência energética para suprir pelo menos 5,0% desta
demanda, o que significa cerca de 54 TWh. Do lado da oferta, o PNE2030 prevê uma
redução das perdas totais, consideradas em no máximo 13,8% EPE (2007).
A Figura 2 ilustra a participação de cada tipo de fonte primária de energia
na geração de energia elétrica no Brasil, ano base 2013, conforme Balanço Energético
Nacional – BEN de 2014, publicado pela EPE (2014a).
Figura 2 - Geração de energia elétrica no Brasil.
Fonte: EPE (2014).
18
Há que se considerar a necessidade de programas de eficiência energética
e de redução de perdas associadas tanto à geração, transmissão como à distribuição
da energia elétrica. No Brasil, a Agência Nacional de Energia Elétrica – ANEEL, com
base na Lei 9.991 de 24 de julho de 2000, regulamenta o setor de energia elétrica no
que se refere aos programas de pesquisa e desenvolvimento e programas de
eficiência energética.
Segundo o PNE2030, existem três níveis potenciais de conservação de
energia, conforme ilustra a Figura 3:
Potencial de mercado, obtido através de benefícios imediatos aos
consumidores, com redução nos custos da aquisição de produtos mais
eficientes;
Potencial econômico, reflexo do desempenho da economia ou ações
macroeconômicas governamentais;
Potencial técnico, que representa o limite teórico da tecnologia atual.
Figura 3 - Níveis potenciais de conservação de energia.
Fonte: PEN 2030 (2007).
A referência para a avaliação das ações de conservação de energia estão
definidas no Protocolo Internacional de Medição e Verificação de Performance
(PIMVP), do qual o Brasil é signatário através do Instituto Nacional de Eficiência
Energética (INEE), fornece uma visão geral das melhores práticas atualmente
disponíveis para verificar os resultados de projetos de eficiência energética, consumo
19
eficiente de água e de energia renovável, o PIMVP também pode ser utilizado por
operadores de instalações para avaliar e melhorar o desempenho delas. As Medidas
de Eficiência Energética (MEE) descritas no PIMVP incluem ações para economia de
combustível, eficiência no uso da água, deslocamento de carga e reduções de energia
através da instalação de equipamentos, retrofits ou modificação de procedimentos de
operação (PIMVP, 2011).
A conjuntura do setor elétrico, com a aprovação da medida provisória
579/2012, que entrou em vigor em janeiro de 2013, permitiu que o governo renovasse
parte das concessões das usinas, transmissoras e distribuidoras de energia que venciam
entre 2015 e 2017. Em contrapartida, as concessionárias beneficiadas foram obrigadas a
aceitar receber remuneração até 70% menor pelo serviço prestado, com consequente
redução de investimentos, tornando-se mais crítica com a crise hídrica que se estendeu
de 2014 a 2015, reduzindo a capacidade de geração de energia hidroelétrica e obrigando
o acionamento da geração por termoelétricas, a um custo maior, resultando em tarifas
mais elevadas aos consumidores.
No sentido de mitigar estes problemas, o governo federal vem desenvolvendo
políticas de incentivo à geração com fontes alternativas, por meio do PROINFA, e novos
empreendimentos entraram em operação este ano, conforme mostra o gráfico da Figura
4 totalizando 40.074MW de expansão na capacidade de geração em janeiro de 2015
(ANEEL, 2015).
Figura 4 - Novos empreendimentos em geração
Fonte: ANEEL (2015).
20
A regulamentação interna do setor, através da ANEEL, proporcionado pela
Resolução Normativa nº 482 de 2012, que estabelece as condições gerais para o
acesso de microgeração e minigeração distribuída aos sistemas de distribuição de
energia elétrica e o sistema de compensação de energia elétrica bem como a
Resolução Normativa 502 de 2012, que regulamenta sistemas de medição de energia
elétrica de unidades consumidoras do grupo B, através de medidores eletrônicos.
Além destas medidas, de acordo com a Resolução Normativa nº 626 de
2014 da ANEEL, a partir de 2015, as contas de energia estão sob nova modalidade
tarifária: o Sistema de Bandeiras Tarifárias. As bandeiras verde, amarela e vermelha
indicarão se a energia elétrica custará mais ou menos, em função das condições de
geração, agregando ao custo da energia elétrica um valor majorado em função da
natureza da sua geração, se térmica, hidroelétrica ou nuclear o que ocorre devido às
variações anuais dos regimes de chuvas que interferem na geração hidroelétrica, a
qual corresponde a 70,6% da nossa matriz energética EPE (2014b).
O sistema elétrico brasileiro, como parte importante da infraestrutura crítica
do país, e um dos maiores sistemas interligados do mundo, requer para sua gestão
um sistema integrado de informações e recursos robusto.
Segundo Amin& Wollenberg (2005), as Redes Elétricas Inteligentes (REI)
se
propõem
a
proporcionar funcionalidades
como
maior resiliência,
auto
reconfiguração, redução de perdas, através da aplicação de técnicas de inteligência
distribuída e multiagentes, onde os dispositivos da rede passam de elementos
passivos a componentes microprocessados dotados da capacidade de comunicação
e tomadas de decisões em função de ameaças ambientais ou alterações de
parâmetros elétricos da rede.
A tecnologia da informação vem fornecendo ferramentas cada vez mais
eficientes e abrangentes para a gestão dos recursos energéticos disponíveis,
modificando a forma como os diversos agentes que participam da rede de energia
elétrica interagem.
Neste
contexto,
devido
à
grande
quantidade
de
informações,
conhecimento, sistemas, recursos, agentes participantes e consequentemente
protocolos de comunicação, significados ou semânticas para o compartilhamento do
entendimento sobre todas estas coisas, há que se considerar a necessidade de uso
21
dos mais modernos recursos disponíveis para permitir a interoperabilidade de todos
os sistemas de forma harmoniosa e sem falhas.
O sistema elétrico de potência (SEP) e seus componentes compreendem
um domínio de conhecimentos que requer uma modelagem adequada às suas
necessidades intrínsecas de constantes mudanças, ampliações, novas tecnologias,
etc.
Neste trabalho se propõe o desenho e construção de ontologias como
forma de modelagem e representação do domínio do conhecimento dos sistemas
elétricos prediais. As ontologias permitem o seu reuso em aplicações diversas, bem
como possibilita interligar ontologias existentes em domínios diferentes, criar uma
nova ontologia a partir de outras, em tempo de execução, sem a necessidade de
paradas no ambiente de produção da aplicação. (Knublauch et al. 2006).
Os sistemas prediais e as redes elétricas inteligentes possuem uma
dinâmica de crescimento e alterações que precisam ser realizadas sem paradas no
sistema, bem como uma diversidade de participantes e agentes, o que requer
capacidade de interoperabilidade baseada não apenas em sintaxes, mas de
semântica.
A proposta do uso de ontologias na modelagem de sistemas elétricos de
potência, apresentados neste trabalho, desde os sistemas internos aos prédios,
passando pelos sistemas da rede de distribuição de energia constitui-se numa
abordagem nova dos SEP com base nas emergentes tecnologias da rede mundial de
computadores, aplicando os conceitos de grid network.
1.1
JUSTIFICATIVA
Os sistemas prediais participam com parcela significativa no consumo de
energia, impactando na curva de carga e na demanda. Os sistemas de automação e
controle predial possuem a capacidade de gerenciar e controlar os sistemas prediais.
A possibilidade de interoperabilidade entre os sistemas prediais com as REI
possibilita uso de estratégias de gerenciamento pelo lado da demanda, do lado das
concessionárias de energia, associadas a técnicas de resposta à demanda, do lado
dos consumidores.
22
A resposta à demanda com inclusão do uso dos recursos energéticos
distribuídos pode contribuir significativamente dentro do contexto das REI.
A palavra-chave neste processo é a interoperabilidade, de fundamental
importância como será demonstrado neste trabalho, a qual será alcançada pela
aplicação de avançadas metodologias de gerenciamento eficiente da informação.
A aplicação de Ontologias na modelagem da interoperabilidade entre os
sistemas permite resolver diversos problemas diretamente afetos ao sistema, bem
como é um novo paradigma de aplicação da engenharia de domínios em sistemas
elétricos de potência, com uso de inferências de Lógica Descritiva (DL) e possibilidade
de aplicação de avançadas ferramentas de com lógica difusa, Redes Baysianas, entre
outras.
De forma diversa do paradigma da orientação a objetos, onde os modelos,
uma vez definidos e criada a base de dados do sistema não podem mais ser alterados
em tempo de execução, com o paradigma da engenharia de ontologias é possível criar
um modelo, criar a base de dados correspondente, adicionar novos elementos no
modelo ou mesmo importar um novo modelo e adicionar à base de dados sem
necessitar parar a base e reindexar todo o conjunto de dados.
A aplicação desta metodologia em sistemas prediais ou mesmo na
modelagem de redes elétricas de distribuição possibilita o crescimento do modelo de
forma dinâmica, por exemplo, a inclusão da geração distribuída (GD), sem prejuízo da
operação das aplicações que rodam na supervisão e controle do sistema em
funcionamento, o que permitirá acelerar a interoperabilidade dos sistemas prediais
com as REI.
1.2
OBJETIVOS
O objetivo geral deste trabalho é propor uma metodologia para a
modelagem de sistemas prediais e redes elétricas inteligentes, visando a coleta de
dados para aplicações de gerenciamento pelo lado da demanda e resposta à
demanda.
Os objetivos específicos do trabalho são:
Levantar as tecnologias atuais aplicadas nos sistemas de automação
predial, técnicas e estratégias de controle de demanda;
23
Avaliar a evolução das redes elétricas inteligentes;
Realizar um estudo do estado da arte dos protocolos de comunicação
existentes para comunicação entre os sistemas de automação predial e
as redes elétricas inteligentes;
Levantar as técnicas de modelagem da informação na engenharia de
domínios – ontologias e algoritmos de inferência;
Modelagem de um sistema de automação predial genérico e de um
sistema de gerenciamento de demandas empregando ontologias;
Desenvolver uma aplicação web para manipular estas ontologias
demonstrando a sua aplicabilidade e benefícios.
1.3
ORGANIZAÇÃO DO TRABALHO
No sentido de atingir os objetivos propostos, este trabalho está organizado
em seis capítulos. O primeiro capítulo apresenta uma introdução ao tema,
contextualizando a área de pesquisa e apresentando as premissas que justificam sua
realização, bem como os benefícios para a sociedade.
No segundo capítulo é apresentada a fundamentação teórica das diversas
disciplinas que embasam o trabalho, no terceiro capítulo apresenta-se um
levantamento do estado da arte na aplicação das técnicas e metodologias propostas
na área de estudo desta pesquisa.
No quarto capítulo são apresentados os materiais, metodologias e são
apresentadas as modelagens propostas.
No capítulo quinto é realizado a simulação da aplicação em ambiente
controlado da metodologia proposta na pesquisa, os resultados obtidos e sua análise,
e o sexto capítulo apresenta as conclusões dos resultados encontrados e propostas
de trabalhos futuros.
24
2
FUNDAMENTAÇÃO TEÓRICA
A área de pesquisa deste trabalho compreende diversas disciplinas que
compõem o conhecimento na área da tecnologia da informação, o que requer um
estudo acerca do embasamento teórico, da aplicabilidade e da técnica mais adequada
de uso em cada área do conhecimento.
Neste capítulo são apresentadas as diversas áreas de conhecimento que
embasam a pesquisa, proporcionado uma argumentação científica adequada durante
o desenvolvimento dos trabalhos.
2.1
PRÉDIOS INTELIGENTES
Existem interpretações diversas sobre o que conceitua um prédio
inteligente, de acordo com a abordagem adotada na avaliação, tais como definições
baseadas em desempenho, em serviços ou em sistemas.
Definições baseadas em desempenho, como a elaborada pelo European
Intelligent Buildind Group (EIBG), consideram os aspectos que tornam o ambiente de
trabalho mais eficiente, ao mesmo tempo em que permite um gerenciamento eficaz
sobre os recursos, reduzindo custos de manutenção e operação Moghaddan (2012).
Para as definições baseadas em serviços, como a sugerida pelo Japanese
Intelligent Building Intitute (JIBI) são avaliadas a qualidade dos serviços das
facilidades de comunicações, automação de escritórios, automação predial e a sua
conveniência para atividades inteligentes Mourinho (2014).
Na abordagem baseada em sistemas, considera-se a necessidade da
existência de sistemas de automação predial, automação comercial, rede de
comunicações e uma composição otimizada de integração de infraestrutura, serviços,
sistemas e gerenciamento, proporcionando um prédio com alta eficiência, conforto,
conveniência e segurança aos usuários Wang (2010).
Para fins deste trabalho, adotando a definição de Wang (2010), considerase um prédio como sendo “inteligente” se dotado de um sistema integrado de
supervisão, controle e gerenciamento da operação, manutenção, insumos, utilidades,
segurança e que disponibilize ambientes adequados às atividades humanas com
eficiência, conforto, qualidade de vida e segurança.
25
Prédios de natureza comercial ou pública, como escritórios, salas
comerciais, shopping centers, repartições públicas, hospitais, entre outros, nos quais
existe um grande fluxo de pessoas, instalações de equipamentos com grandes cargas
tornando os sistemas de automação predial necessários, o que poderia permitir o uso
do ADR ou Automated Demand Response. No ADR a resposta da demanda ocorre
de forma automática, em resposta às requisições ou mensagens originadas pelas
concessionárias de energia em consonância com o DSM estabelecido na região de
distribuição Holmberg et al. (2012).
Os edifícios comerciais, objeto do presente trabalho, são consumidores de
energia que agregam características peculiares, com grandes demandas de energia
e alguns providos de Recursos Energéticos Distribuídos-DER, que podem estar
disponíveis para uso nas Redes Elétricas Inteligentes - REI.
2.2
SISTEMAS DE AUTOMAÇÃO PREDIAL
A automação predial compreende uma ampla gama de sistemas
especializados de supervisão e controle das diversas funcionalidades em um prédio,
reunidos sob a sigla BAS – Building Automation Systems, sendo essenciais para a
operação e manutenção segura do empreendimento.
A Figura 5 ilustra o conjunto de sistemas que compõem o BAS, organizados
em disciplinas de aplicação:
26
Figura 5 – Disciplinas de um BAS.
Fonte: O Autor (2015).
2.2.1
Utilidades prediais – BMS
O Building Management System - BMS ou Sistema de Gerenciamento
Predial é um destes sistemas especializados, compreendendo as utilidades prediais,
como sistemas elétricos, sistemas hidráulicos, controle de iluminação, sistemas de
transporte como elevadores e escadas rolantes, medição de consumos de água, gás
e energia elétrica. O BMS fornece informações e status de todos os dispositivos em
tempo real aos gerentes operacionais dos empreendimentos, proporcionando meios
de supervisão e controle principalmente para melhoria na manutenção dos sistemas,
através de históricos de eventos, relatórios gerenciais bem como a interatividade entre
os diversos sistemas que o compõem.
O BEMS, um dos módulos do BMS compreende todas as funcionalidades
de medição de energia global e individual das unidades consumidoras, controle de
iluminação, controle de demanda e acionamento de fontes de energia alternativas
27
como geradores e unidades UPS, bem como a modulação do HVAC para fins de
otimização do consumo de energia Wang (2010).
2.2.2
Controle ambiental - Ar condicionado (HVAC)
Os sistemas de controle ambiental, como o de condicionamento de ar
através do controle de temperatura, umidade, seja para conforto ambiental ou para
refrigeração de equipamentos eletrônicos são designados pela sigla HVAC de Heating
Ventilation and Air-Conditioning, incluem-se nesta disciplina os sistemas de ventilação
e exaustão, responsáveis por garantir qualidade do ar.
O HVAC é composto por uma parte mecânica com montagem de dutos de
circulação do ar, uma parte hidráulica para fornecimento do líquido refrigerante
adequado e por uma parte eletrônica composta por instrumentos de campo,
controladoras e gerenciadoras, todos estes componentes operam de forma conjunta
executando algoritmos especializados para disponibilizar no ambiente um ar de
qualidade e a uma temperatura confortável para que os ocupantes possam
desenvolver suas atividades com produtividade e qualidade de vida Sugarman (2001).
2.2.3
Monitoramento - (CFTV)
O sistema de CFTV é uma ferramenta essencial no gerenciamento predial,
por oferecer a facilidade da quase onipresença dos elementos de segurança e
operadores do BMS, ao disponibilizar informações visuais em tempo real sobre
diversos locais dentro de uma instalação predial sem a perda do tempo de
deslocamento para verificação visual. O CFTV é muitas vezes associado a eventos
de alarme dos sistemas de SCA, SAI, SDAI ou BMS visando a redução do tempo de
resposta a eventos que exigem a intervenção dos operadores, ampliando assim a
eficácia do sistema BAS.
28
2.2.4
Proteção – (SDAI)
O Sistema de Detecção e Alarme de Incêndio (SDAI) é um sistema
determinado por meio de normativas técnicas, no Brasil a ABNT estabeleceu, através
da NBR 17240:2012 as orientações para elaboração e instalação de sistemas
especializados de detecção e alarme de incêndio.
Estes sistemas são, de acordo com critérios específicos estabelecidos por
lei estaduais, interligados aos sistemas de HVAC e exaustão para o controle de
fumaça, e ao sistema BMS para fins de comando de elevadores, iluminação de
emergência e outros, no sentido de proteção às pessoas, em primeiro lugar, e ao
patrimônio em segundo lugar ABNT (2015).
2.2.5
Segurança - (SAI e SCA)
Os Sistemas de Alarme de Intrusão - SAI possuem a finalidade precípua
de proteção patrimonial, estando associado às equipes de vigilância patrimonial do
prédio, enviando eventos para os sistemas de CFTV, SCA ou mesmo BMS com a
finalidade de, através da associação de eventos, gerar informações mais consistentes
sobre os eventos em andamento. Assim, lógicas de associação e tratamento dos
eventos podem oferecer ao operador da central de segurança uma informação mais
completa acerca de um determinado evento.
O sistema de controle de acesso - SCA é especializado no controle do
bloqueio ou liberação do acesso de pessoas, veículos e ativos, com objetivos de
segurança, mas que pode ser usado para fornecer ao BEMS informações importantes
para o gerenciamento de energia, uma vez que através do SCA pode-se saber a
localização das pessoas e ocupação das áreas e desta forma, antecipar ações de
controle sobre iluminação, HVAC e do BMS, permitindo assim uma otimização dos
recursos disponíveis.
29
2.3
REDES ELÉTRICAS INTELIGENTES
Para Amin e Wollenberg (2005), adicionar inteligência a um SEP é preciso
introduzir um sistema de processamento distribuído em cada componente do grid.
Segundo Ekanayake et al. (2012), as Redes Elétricas Inteligentes – REI
compreende o conceito de agregar recursos de Tecnologia da Informação e
Comunicações – TIC com o objetivo de proporcionar funcionalidades como auto
reconfiguração, maior resiliência a falhas, maior confiabilidade, incorporação da
medição inteligente, bem como proporcionar utilização de Recursos Energéticos
Distribuídos – DER.
O sistema de distribuição de energia atual é muito extenso e quase
inteiramente pouco reativo, com poucos controles limitados às subestações e aos
grandes consumidores, como indústrias de base e de transformação com processos
eletro intensivos. Não existem quase pontos de monitoramento em tempo real das
tensões da energia elétrica fornecida aos consumidores bem como uma medição
inteligente do consumo da potência entregue no ponto de consumo.
Com a recente revolução dos sistemas de comunicação, particularmente
estimuladas pela conectividade proporcionada pela Internet, surge a possibilidade de
uma melhor monitoração e controle em tempo real do sistema de energia,
consequentemente proporcionando uma operação mais eficaz, flexível e a um custo
menor.
Conforme apresentado por Travostino, Franco e Mambretti (2006), o
conceito de Grid Network designa uma nova arquitetura que proporciona importantes
capacidades para criação de serviços avançados em tecnologia da informação. O Grid
foi desenhado para proporcionar serviços que não podem ser suportados por redes
convencionais e de forma customizada disponibiliza recursos especializados,
praticamente ilimitados serviços podem ser suportados.
Proporciona escalabilidade, confiabilidade, mecanismos de segurança para
localizar, montar, integrar, utilizar, reconfigurar e executar múltiplos e heterogêneos
recursos, desde clusters de computadores, sistemas especializados, softwares,
armazenamento em massa, repositórios de dados, instrumentos e sensores.
A arquitetura SOA – Services Oriented Architeture para recursos de rede,
baseado no mesmo padrão de Web Services permite a utilização dos recursos
30
distribuídos no Grid Network entre os diversos sistemas que compartilham estes
recursos, sendo um modelo que pode ser aplicado no conceito do Smart Grid (SG).
De acordo com Ekanayake et al. (2012) a implementação do Smart Grid
permite ainda que sejam resolvidos alguns problemas intrínsecos aos sistemas
elétricos atuais, como:
Envelhecimento dos ativos e limitações na sua ampliação;
Restrições térmicas, que podem ser monitoradas em tempo real,
permitindo melhor utilização das linhas dentro de limites de segurança;
Restrições operacionais, devido à falta de medição e controle em tempo
real de parâmetros de qualidade da energia como tensão e frequência;
Uso de recursos energéticos distribuídos (DER), que podem ser
colocados em linha de forma coordenada e segura, reduzindo perdas e
melhorando a confiabilidade da rede de distribuição;
Impossibilidade de integração de novas tecnologias, como fontes de
energia renováveis;
Segurança
no
fornecimento,
que
pode
ser
melhorada
com
sensoriamento e controle das redes de transmissão e distribuição,
adicionando a funcionalidade de auto reconFiguração ou self-healing
para superar falhas localizadas na rede;
Dispositivos DER são todos os mecanismos de geração de energia, como
painéis fotovoltaicos, geradores eólicos, geradores térmicos combinados, geradores
elétricos por biomassa, ou ainda dispositivos que permitam o armazenamento local
de energia, como veículos elétricos plugados na rede (PEV acrônimo do inglês Pluged
Electrical Vehicule), armazenamento térmico de energia ou termo acumulação,
bancos de baterias, células de combustível, entre outros, que contribuem para o
armazenamento de energia conversível em elétrica, ou utilizáveis em sua substituição.
De forma resumida, os recursos energéticos distribuídos caracterizam-se
por dispositivos de geração distribuída e armazenamento de energia que se
disponibilizados nas REI de forma coordenada podem agregar maior capacidade de
auto reconfiguração e resiliência ao sistema como um todo.
A ANEEL através das resoluções 482/2012 e 502/2012 autorizou a
utilização de microgeração distribuída e introduziu no sistema elétrico brasileiro o uso
de medidores inteligentes, ou smart meters, capazes de adicionar as funcionalidades
31
de medição remota, controle de parâmetros elétricos indicadores da qualidade da
energia, como tensão, frequência, potência real e reativa, fator de potência, correntes
e fase de forma individual em cada unidade consumidora, bem como permitem o fluxo
bidirecional de energia, o que viabiliza a utilização da geração distribuída na rede
elétrica ANEEL (2015).
O CPqD - Centro Brasileiro de Pesquisa e Desenvolvimento elabora
anualmente o Índice Brasileiro de Cidades Digitais, IBCD que mede o nível de
inovação e de digitalização, definindo o ranking das cem cidades brasileiras que
melhor utilizam as tecnologias da informação e da comunicação (TIC), que inclui
critérios como presença de equipamentos primários, acesso público à Internet,
cobertura geográfica, acessibilidade, usabilidade e inteligibilidade, banda e serviços
públicos e privados disponibilizados na rede (CPqD, 2011).
A ANEEL, através de seus programas de P&D vem estimulando a busca da melhoria
contínua dos processos de gestão da demanda.
2.4
CONTROLE DE DEMANDA
De acordo com Cruz (2014), o controle de demanda compreende um
conjunto de ações de desligamento de cargas realizadas no consumidor no sentido
de impedir que o consumo de energia ultrapasse um valor previamente definido.
Algoritmos de Controle de Demanda usados são:
Prioridade, neste algoritmo, o usuário programa a prioridade do ponto
a ser controlado, sendo o de maior prioridade o último a ser retirado,
em uma eventual tendência de ultrapassagem de demanda, e o
primeiro a ser religado quando a tendência normalizar.
Restritivo, onde os pontos serão desligados/religados conforme
programação de prioridades descrita anteriormente. Entretanto, este
algoritmo permite a programação de um tempo máximo do ponto
desligado que, quando cumprido, será religado e irá cumprir um novo
tempo, denominado tempo de restabelecimento, quando o ponto estará
ligado e fora do controle de demanda. Este tipo de algoritmo é muito
utilizado em cargas térmicas, quando uma carga pode ser desligada
32
por um determinado tempo sem perder calor e, quando religada, entra
em restabelecimento.
Prioridade com programação horária, o qual segue as mesmas regras
da prioridade, sendo que poderão ser desligados pontos que tenham
sido ligados por programação horária, permitindo assim que um mesmo
ponto acumule duas formas de atuação: programação horária e por
demanda;
Cíclico, neste tipo de algoritmo normalmente é utilizado para atuações
em pontos onde as cargas conectadas possuem o mesmo valor, em
prioridade de funcionamento, em valor da carga em KW ou em ambos,
caso em que estas cargas podem ser desligadas e religadas em forma
de rodízio. No caso de combinações no uso dos algoritmos prioridade
e cíclico, em uma tendência de ultrapassagem de demanda serão
desligados inicialmente os pontos programados como cíclico, para, só
então e não havendo ocorrido a normalização da demanda, iniciar o
desligamento dos pontos programados com prioridade. Também nos
algoritmos cíclico e prioridades, é possível a programação não só do
tempo entre desligamentos e ligamentos de pontos, como o início de
acionamento dos pontos na janela de 15 minutos. A programação
destes tempos só será possível caso, como cálculo da demanda, tenha
sido programada a forma de tendência ou janela deslizante.
Controle de gerador, na hipótese de uma tendência de ultrapassagem
de demanda, os pontos que tenham sido programados com este
algoritmo serão acionados de maneira a ligar um gerador. Este ponto
permanecerá ligado por um tempo programado pelo usuário,
independentemente do valor de demanda e, só será desligado ao final,
quando houver sido cumprido o tempo, independente da normalização
da demanda.
Controle residual, cujo cálculo é baseado no valor da demanda quando
todas as cargas controladas são retiradas. O número de cargas define
os degraus de velocidade com que podemos aumentar ou diminuir. Por
exemplo, se a demanda contratada é de 5 KW e a residual é de 1 KW
e temos cinco cargas, os degraus serão de 1 KW.
33
A curva da Figura 6 ilustra como é o comportamento do algoritmo, onde DC
é a Demanda Contratada e DR é a Demanda Residual. Ele permite que no início da
integração de 15 minutos, ditada pela concessionária de energia elétrica a demanda
média atinja valores maiores do que a contratada. À medida que o tempo vai chegando
ao final do intervalo ele começa a retirar carga com a velocidade que for necessária
para não ocorrer o estouro de demanda. Este algoritmo além de rápido diminui
sensivelmente o número de chaveamentos.
Figura 6 - Curva de controle residual.
Fonte: Adaptado de Cruz (2014).
Segundo Fernandes et al., (2011) o controle automático de demanda deve
considerar fatores de decisão antes de atuar sobre as cargas controladas, de acordo
com as seguintes variáveis:
Demanda instantânea;
Demanda máxima estabelecida (contratada);
Estrutura tarifaria em vigor;
Cargas controláveis e não controláveis;
Potência das cargas controláveis;
34
Intervalo de integralização dos medidores de energia elétrica;
Estado dos equipamentos (se ligados ou desligados).
O critério de medição da energia entregue ao consumidor no Brasil, de
acordo com a Resolução 414 de 2010, é de 15 min., devendo os medidores
disponibilizarem uma interface de saída digital para a coletas dos dados da medição
de forma a poder referenciar os sistemas de controle de demanda do consumidor
ANEEL (2015).
2.5
GERENCIAMENTO PELO LADO DA DEMANDA
Segundo Gellings (1988), o conceito de gerenciamento pelo lado da
demanda ou DSM (acrônimo do inglês Demand Side Management) surgiu na década
de 1970, com a crise do petróleo que marcou um dramático período de mudanças
também na indústria da geração, transmissão e distribuição da energia elétrica.
O DSM deve ser analisado num contexto de planejamento integrado de
recursos, sendo importante integrar os tradicionais planejamento e operação da
produção de energia com os conceitos emergentes da influência ativa da demanda
por eletricidade (CAMPOS, 2004).
Segundo Gellings (2009), DSM compreende diversas ações de incentivo
aos consumidores para que modifiquem seus hábitos de uso da energia elétrica
visando adequar de forma dinâmica o consumo à capacidade de geração do sistema,
através de estratégias como indicadas na Figura 7.
35
Figura 7 - Estratégias de DSM.
Fonte: Adaptado de Gellings (2009).
O gerenciamento pelo lado da demanda - DSM é uma sistemática
implantada pelas concessionárias de energia elétrica com o objetivo de modificar os
hábitos de consumo através de incentivos financeiros, como tarifas diferenciadas por
horário. Desta forma, os consumidores são beneficiados com tarifas menores fora do
horário do pico do consumo e penalizados quando consomem no horário de pico.
2.6
A RESPOSTA À DEMANDA
Segundo MCParland (2011), os primeiros esforços de resposta à demanda
(DR - do inglês Demand Response) eram basicamente de natureza manual, nos quais
requisições de resposta à demanda eram tipicamente feitos com um ou mais dias de
antecedência e as comunicações com o consumidor através de fax ou mensagens
telefônicas. Uma vez recebido, o gerente de energia local ajustava o sistema para
reduzir o consumo de acordo com as definições contratuais.
A partir dos anos 1990, com a maior disponibilidade de equipamentos
computacionais a preços acessíveis e com o crescimento da infraestrutura de
telecomunicação de dados com o advento das conexões de banda larga, tornou-se
36
possível o desenvolvimento de sistemas capazes de automatizar tanto a comunicação
como as atividades de resposta à demanda.
No sentido de permitir a interoperabilidade entre os sistemas BAS e as
redes REI, com o objetivo de viabilizar o ADR, foi desenvolvido o padrão openADR,
numa parceria entre o LBNL – Lawrence Berkeley National Laboratory com a ASHRE,
o qual estabelece uma estrutura de comunicação entre as REI e sistemas BAS, bem
como uma descrição do protocolo de comunicação, que se encontra atualmente na
versão 2.0, o qual se baseia no padrão EI 1.0 da OASIS (MACParland, 2011)
Vários estudos foram desenvolvidos sobre a forma de gerenciamento local
dos recursos energéticos distribuídos visando otimizar o uso destes recursos sob a
ótica do gerenciamento pelo lado da demanda – DSM, objetivando principalmente o
deslocamento das cargas em relação ao horário de pico de consumo, busca da melhor
relação entre custo e benefício, incluindo aplicações que atribuem o conceito de
penalidades e recompensas de acordo com a conveniência de uso da energia em
determinado horário.
A resposta da demanda (DR) representa a forma como os consumidores,
ou como em algumas literaturas são referidos, ou "prosumidores" (do termo em inglês
prossumers, um acrônimo de produtores e consumidores) respondem às estas
requisições originadas pelas concessionárias de energia através do DSM.
A resposta da demanda pode ocorrer na forma de mudanças de hábitos de
consumo, na qual os usuários adaptam-se às novas políticas tarifárias, buscando
obter o maior resultado na redução do custo da energia, através de sistemas
gerenciadores, quer sejam em unidades uni familiares, quer sejam em micro áreas,
ou ainda em condomínios residenciais ou comerciais (Kiliccote et al., 2008).
37
2.7
PROTOCOLOS DE COMUNICAÇÃO
Segundo Kastner et al. (2005), um sistema de automação predial é
composto por diversas camadas, cada qual com elementos especializados para
desempenhar um papel definido dentro do conjunto, visando disponibilizar as
funcionalidades que os usuários demandam nas suas atividades diárias.
A rede de comunicações em um sistema de automação predial é a espinha
dorsal que possibilita as ações de supervisão e controle do sistema sobre os
dispositivos de campo, entre as controladoras e com o sistema supervisório central,
onde reside a base de dados e os algoritmos de controle dos sistemas.
Figura 8 - Hierarquia de três níveis
Fonte: Adaptado de Kaster et.al. (2005).
A Figura 8 apresenta as diversas camadas de comunicação, onde pode-se
observar três níveis principais: nível de campo, onde residem os dispositivos de
campo como sensores e atuadores, nível de automação onde operam as
controladoras dotadas de Controle Digital Direto (DDC) e o nível de gerenciamento,
38
onde encontramos o supervisório SCADA, o sistema de banco de dados, interfaces
com outros sistemas.
Em cada um destes níveis na hierarquia do sistema opera um protocolo de
comunicação específico, desenvolvido de acordo com as necessidades funcionais do
sistema. Os protocolos mais utilizados na área de automação predial são:
Rede de campo: MODBUS-RTU, BACnet MS/TP, KNX, LonWorks,
DALI,
Rede de automação:BACNET ETHERNET, MODBUS TCP
Rede de Gerência: TCP/IP, OPC, BACnet IP
A Figura 9 mostra onde se enquadram alguns dos diversos componentes
da comunicação dos protocolos listados em relação ao modelo ISO:
CAMADA ISO:
Aplicação
Aplicação Específica
Apresentação
BACNnet IP
Sessão
Transporte
Rede
BACnet
MS/TP
Enlace
Física
TCP
MODBUS IP
BACnet TCP
IP
Ethernet
MODBUSRTU
Ethernet
RS-485
TCP
IP
Ethernet
RS-485
Figura 9 - – Protocolos e as respectivas camadas no padrão ISO.
Fonte: O autor (2015)
Durante a evolução tecnológica dos sistemas de automação predial, alguns
fabricantes desenvolveram protocolos de comunicação proprietários no nível de
automação com base no padrão elétrico RS485, como por exemplo, o Metasys N2,
da Jonhson Controls.
Na camada de rede de campo, alguns protocolos proprietários
desenvolvidos para a área industrial foram herdados na área de automação predial,
como consequência da aplicação de controladores lógicos programáveis (CLP) de
padrão industrial, citando-se como exemplos o CANopen, DeviceNet e Profibus
(KARSTEN et al., 2005).
Devido a esta diversidade de protocolos, muitos adaptados ao uso nos
sistemas de automação predial, os profissionais da área de engenharia de ar
39
condicionado, através da ASHRAE – American Society of Heating, Refrigerating and
Air-Conditioning Engineers, criaram em 1987 o protocolo aberto BACnet, desenvolvido
especialmente para controle de sistemas prediais, que vem sendo constantemente
atualizado.
O BACnet é um protocolo orientado a objeto, onde todos os dispositivos
podem atuar tanto como clientes como servidores, trocando mensagens entre si,
sendo um padrão ANSI e ISO, e permite a interoperabilidade de dispositivos e
sistemas de fabricantes diferentes, ao estabelecer o conceito de que cada dispositivo
é um objeto dotado de propriedades que podem ser lidas ou alteradas, conforme o
tipo de dispositivo e sua aplicação no sistema.
Atualmente o BACnet
possui uma versão web services denominado
BACnet/WS, que através dos protocolos HTTP e TCP/IP um serviço Web encapsulado
pode solicitar e receber eventos via formato XML, baseado no padrão SOAP, cuja
integração atualmente é dificultada pela falta de uma padronização semântica nos
sistemas web (FISHER, 2007).
2.8
ENGENHARIA DE ONTOLOGIAS
2.8.1
Conceitos Básicos
Segundo Bruijn, et al. (2008), ontologias são a compreensão comum e
partilhada de um domínio de conhecimento que pode ser transmitida entre pessoas e
sistemas heterogêneos e distribuídos, proporcionando uma forma de desenvolvimento
de bases de conhecimento.
Uma ontologia é uma coleção de dados, organizados em classes,
subclasses, entidades e suas propriedades de acordo com a natureza dos dados,
apresentando como característica comum, a sua aplicabilidade. Desta forma uma
ontologia é construída especificamente para um determinado domínio de aplicação,
tendo como objetivo principal fornecer dados organizados para atender às
necessidades específicas da sua aplicação, segundo Colomb (2007).
Uma ontologia pode ser definida como uma especificação formal e explícita
de uma conceituação compartilhada, entendendo-se por especificação formal ser
inteligível para os computadores, onde explícita significa propriedades, relações,
40
funções, restrições e axiomas explicitamente definidos; e conceptualização representa
um modelo abstrato de algum fenômeno do mundo real, e compartilhada significando
conhecimento consensual (GRUBER, 1995).
Figura 10- Conceptualização de domínio.
Fonte: O Autor (2015).
A Figura 10 ilustra uma conceptualização de espaço de domínios, uma
estrutura S é dada por < D,L,R,W > onde D representa um domínio em questão e W
representa os conceitos existentes em D, sendo R o conjunto de relações definidas
como pertinentes para a representação deste domínio.
Em termos computacionais, uma conceptualização deve ser especificada
em uma determinada linguagem L para poder ser utilizada, mapeando a estrutura S
em constantes e predicados da linguagem, seguindo uma função de interpretação
definida.
Assim, uma determinada conceituação C é definida como uma estrutura
<D,W,R> como a representação pretendida do mundo real (GUARINO apud MORAIS
e AMBROSIO, 2007).
Nestas condições, as ontologias são mecanismos de especificação parcial,
tornando-se representativas apenas em relação a um determinado domínio, definido
41
como Universo de Discurso (UD) da ontologia em questão (BORST apud MORAIS e
AMBROSIO, 2007)
Como uma representação abstrata do mundo físico, a Ontologia utiliza-se
de fatos institucionais para representar os atos verbais, ou declarações do mundo real
em um determinado contexto.
De forma similar a um modelo conceitual, que se relaciona a um sistema
de informação em particular, uma ontologia representa o mundo exterior de qualquer
sistema em particular, usualmente compartilhado por uma comunidade sistemas de
informação que interoperam (COLOMB, 2007).
2.8.2
A Engenharia de Domínios
Segundo Guizzardi (2005), o processo de engenharia de domínios
compreende as seguintes atividades: análise do domínio e desenho do domínio, esta
última decompondo-se em especificação da infraestrutura e implementação da
infraestrutura. A engenharia de domínio é similar à engenharia de software, porém
operando em um meta-nível onde o foco não é uma aplicação específica, mas uma
família de aplicações em um dado domínio.
Tabela 1 - Comparativo Engenharia de Aplicação versus Engenharia de Domínio
Engenharia de aplicação
Análise de requisitos
Desenho de aplicação
Implementação de aplicação
Fonte: Adaptado de Guizzardi (2010).
Engenharia de domínio
Análise de domínio
Especificação de infraestrutura
Implementação de Infraestrutura
A análise comparativa da tabela 1 mostra que na engenharia de domínio,
diversamente da engenharia da aplicação, ao invés de desvendar requisitos, desenhar
e implementar aplicações específicas, tem-se como objetivo toda uma família de
aplicações em um dado domínio. Em Guizzardi et al. (2009), o termo Análise de
Domínio é definida como: “Análise de domínio é uma tentativa de identificar objetos,
42
operações e relações que especialistas no domínio percebem como importantes em
dado domínio.”
O produto da fase de análise de domínio é um modelo de domínio. Um
modelo de domínio define objetos, eventos e relações que capturam similaridades e
regularidades em um dado domínio de discurso. O modelo resultante é uma
arquitetura composta por elementos conceituais que são comuns para uma família de
aplicações, permitindo o reuso. Pode ser usado para identificar, explicar e predizer
fatos em um dado domínio, o qual pode ser fortemente observado diretamente. Serve
ainda ao propósito de um modelo unificado para usar-se quando ambiguidades
surgem em discussões sobre o domínio (comunicação) e a fonte do conhecimento
pode ser usada em um processo de aprendizagem sobre o domínio GUIZZARDI et al.
(2009).
O resultado de um processo de engenharia de domínio é uma infraestrutura
reutilizável, ou um framework, que pode ser reutilizado em instâncias de processos de
engenharia de software na construção de várias aplicações de uso específico cujos
requisitos tenham sido definidos durante a fase de análise de requisitos de cada
aplicação específica Guizzardi (2005).
Segundo Noy e McGuinness (2001), as razões que podem motivar o
desenvolvimento de uma ontologia são:
Necessidade de entendimento comum compartilhado da estrutura da
informação entre as pessoas ou agentes de software;
Permitir o reuso sobre o domínio do conhecimento;
Tornar explícitas as especificações do domínio;
Separar domínio de conhecimento do conhecimento operacional;
Analisar o domínio de conhecimento.
Algumas aplicações da ontologia, como no campo da IA – Inteligência
Artificial, para modelagem do conhecimento e permitir o uso de ferramentas
conhecidas como reasoners, ou inferências lógicas, como fuzzy, DL – Description
Logic (Lisi e Straccia 2013).
43
2.8.3
Classificação das Ontologias
Segundo Guizzardi et al. (2009), as ontologias podem ser classificadas
segundo sua função em:
Ontologias genéricas empregam conceitos amplos, buscando construir
teorias básicas do mundo real, sendo de caráter abstrato e aplicáveis
a qualquer domínio;
Ontologias de domínio, que descrevem conceitos e vocabulários
relativos a um domínio em particular, com foco nestes domínios;
Ontologias de tarefas, empregadas na solução de problemas
genéricos, tendo como principal motivação facilitar a integração entre
conhecimento e processo no domínio com uma abordagem mais
uniforme e consistente;
Ontologias de aplicação, baseada em conceitos ligados a um domínio
específico e atividades específicas, podendo ser especializações das
ontologias de domínio e de tarefas do domínio em particular
considerado;
Ontologias de representação, as quais conceitualizam e fundamentam
os formalismos de representação do conhecimento, explicitando os
compromissos ontológicos intrínsecos aos formalismos.
Adicionalmente, segundo Morais e Ambrósio (2007), as ontologias podem
ser classificadas quanto ao seu grau de formalismo, aplicação, conteúdo ou função,
conforme sintetizado na tabela 2:
44
Tabela 2 - Classificação das Ontologias
Classificação
Formalismo
Tipo
Critério
Altamente formais
Expressas em linguagem natural
Semiformais
Expressas em linguagem natural de
forma estruturada e restrita
Rigorosamente
formais
Termos definidos com semântica formal,
teoremas e provas
Autoria neutra
Permite uso em várias plataformas
De especificação
Aplicação
Acesso comum a
informação
Conteúdo
Ontologia de domínio utilizada para
documentação e manutenção de
software
Na tradução de textos e informações
permitindo compartilhar termos
(semântica)
Terminológicas
Usam termos para modelar o
conhecimento de um domínio específico
Informação
Estrutura de registros de um banco de
dados
De modelagem do
conhecimento
Especificam conceptualizações do
conhecimento
De aplicação
Definições necessárias para modelar o
conhecimento em uma aplicação
De domínio
Expressam conceptualizações
específicas de um domínio
Genéricas
Definem conceitos genéricos e comuns a
várias áreas do conhecimento
De representação
Explicam as conceptualizações que estão
por trás dos formalismos de
representação do conhecimento
Fonte: Adaptado de Morais (2007).
45
2.8.4
Elementos de uma Ontologia
A construção de ontologias envolve inicialmente as definições de escopo e
domínio, estabelecimento de uma metodologia, escolha da ferramenta adequada e
sua linguagem de implementação.
Dentro de uma ontologia os elementos do domínio são organizados em
classes, que agrupam elementos com relacionamentos comuns entre si. Estas classes
são organizadas em taxonomias. As classes podem possuir subclasses que podem
possuir outras subclasses.
A Figura 11 ilustra uma taxonomia de classes, bem como os demais
elementos integrantes da ontologia, a saber:
Relações são as interações ou relacionamentos entre os elementos do
domínio ou classes;
Axiomas são declarações ou restrições que devem ser consideradas
como verdadeiras, limitando o significado ou as relações entre as
classes;
Instâncias são os dados, objetos da ontologia, os indivíduos de um
grupo ou conjunto, representados como instâncias da classe;
Funções são os eventos que podem ocorrer no contexto da ontologia.
Na Figura 11, a superclasse equipamentos elétricos possui duas
subclasses que identificam dois grandes grupos de equipamentos, os consumidores
e os geradores, e uma subclasse que atribui uma relação de prioridade relativa entre
as subclasses de equipamentos elétricos consumidores. Por sua vez, pode-se
identificar uma instância específica da subclasse bombas, representada pela entidade
“bomba drenagem #1”, aqui encontra-se o nível que representa os elementos ou
dados da ontologia, os quais possuem características comuns às demais bombas, e
que possui uma determinada prioridade, atribuída pela subclasse “prioridade de uso”.
46
Figura 11 - Taxonomia das classes de um domínio
Fonte: O autor (2015)
Através de axiomas e funções é possível então estabelecer as formas de
interatividade entre os elementos do domínio de estudo.
Este tipo de ontologia, segundo a classificação apresentada, quanto à
função, é uma ontologia de aplicação, pois está limitada a um domínio específico, no
caso dos equipamentos elétricos e apresenta regras aplicadas às entidades que
executam uma determinada tarefa específica.
47
2.8.5
Desenho de Ontologias
Segundo Noy e McGuinness (2001) não existe uma regra definida para o
desenho e construção de uma ontologia, mas algumas etapas básica podem ser
consideradas como essenciais no desenvolvimento deste trabalho.
Existem várias formas de se modelar a ontologia, sendo este um processo
necessariamente iterativo, de sucessivos refinamentos até que se obtenha a melhor
representação do domínio de acordo com a função definida para o projeto.
Como referência, são elencados os seguintes passos ou etapas:
1) Determinar o domínio e o escopo da ontologia, com perguntas objetivas
tais como qual o domínio que devemos cobrir, qual o uso terá a ontologia,
a quais perguntas a ontologia deve responder aos seus usuários, e quem
serão seus usuários?
2) Considere o reuso de ontologias existentes, já existem milhares de
ontologias sobre diversos domínios que podem ser reutilizadas,
economizando esforço, sendo este um dos objetivos conceituais das
ontologias.
3) Enumerar os termos importantes na ontologia, dentro do domínio e do
escopo definidos na etapa 1, listando a maior quantidade possível de
termos, mesmo que com sobreposição de significado ou uso, para
posteriormente refinar no processo de iteração.
4) Definir as classes e sua hierarquia, neste ponto é importante aplicar um
dos modelos possíveis, como modelo top-down, ou de cima para baixo,
onde as classes acima significam uma superclasse das abaixo, ou modelo
botton-up que significa de baixo para cima, ou seja, parte-se da definição
mais específica para a mais genérica, da entidade para a superclasse. E
por fim existe a possibilidade de combinação destas duas abordagens.
5) Definir as propriedades das classes, ou
slots, que identificam
características das entidades que pertencem à classe, por exemplo um
motor possui uma potência específica, um slot “potência” armazena a
informação da potência de cada motor, ou indivíduo da classe “motores”.
6) Definir as facetas ou tipos de dados que podem ser armazenados em cada
slot.
48
7) Criar instâncias, inserir os indivíduos atribuindo a estes os slots
adequados, na classe adequada.
2.8.6
Inferências em Ontologias
O conceito de inferências em ontologias consiste em aplicar processos
automáticos de geração de novos relacionamentos com base nos dados e um
conjunto de regras de inferência como equivalências de relações, sobre as relações
já declaradas na ontologia, como exemplo, se uma relação estabelecida de que
Bomba_de_drenagem é uma subclasse de BombasElétricas, e BombasElétrica é um
tipo de Equipamento_Utilidade, então podemos inferir que toda Bomba_de_dranagem
é um Equipamento_Utilidade, como uma aplicação da regra: se AB e B C, então
A C.
A linguagem OWL é baseada na Lógica de Descrição, sendo aplicada na
descoberta de conhecimento em ontologias, a tabela 3 ilustra um subconjunto das
regras de inferência da OWL aplicáveis em ontologias (WIEDEMANN, 2014).
Tabela 3 -Exemplos de regras de inferências em OWL.
OWL
Transitive-Property
subClassOf
subPropertyOf
disjointWith
inverseOf
Regra
(? Rdf:type owl1:TransitiveProperty) (?B ?P ?C)
( ?A ?P ?B) (?A ?P ?C)
(?a rdfs:subClassOf ?b) (?b rdf:subClassOf ?c)
(?a rdfs:subClassOf ?c)
(?a rdfs:subPropertyOf ?b) (?b
rdf:subPropertyOf ?c) (?a rdfs:subPropertyOf ?c)
(?C owl>disjoitWith ?D) (?X rdf:type ?C) (?Y
rdf:type ?D) (?X owl:differentFrom ?Y)
(?P owl:inverseOf ?Q) (?X ?P ?Y) (?Y ?Q ?X)
Fonte: Adaptado de Wiedemann (2014).
2.9
A WORD WIDE WEB E A SEMÂNTICA WEB
A Web nasceu com uma estrutura voltada para a sintática, uma vez que o
conteúdo era lido apenas por humanos, sendo basicamente composta por
49
documentos escritos em HTML – Hyper Text Markup Language, que utilizam
marcação de palavras chaves no texto que permitem a visualização e interpretação
das informações como consumo por pessoas, não permitindo, porém, que sejam
interpretadas por outros computadores ou softwares.
A tabela 4 apresenta a evolução da web, em termos de tecnologias
implementadas, métodos de criação, usuários alvo, os paradigmas quebrados em
cada fase e formas de acesso aos dados e informações.
Tabela 4- Evolução da World Wide Web.
CODIFICAÇÃO
ESTÁTICA
HTML
DINÂMICA
+ RDBMS
SINTÁTICA
+ XML
SEMÂNTICA
+ RDF/OWL
Gerado por
aplicações
baseadas em
modelos
Criação
Geradas
manualmente
Geradas no lado do
servidor
Geradas por
aplicações
baseadas em
esquemas
Usuários
Humanos
Humanos
Humanos e
aplicações
Humanos e
aplicações
Paradigmas
Navegador
Criar/Consultar/atualizar
Integrar
Interoperar
Navegadores
Integração de
processos, EIA,
BPMS,
Workflows
Agentes
inteligentes,
motores de
semântica
Aplicações
Navegadores
Período
1990
2000
2005
Fonte: Adaptado de Cardoso (2007).
Na sua primeira fase de desenvolvimento, a Web era gerada manualmente
apenas por programadores empregando basicamente HTML, com objetivo de ser lida
por humanos que visualizavam as informações de um conteúdo estático através de
um navegador, este foi o primeiro paradigma vencido pela web. Na segunda fase
podemos identificar o surgimento de ferramentas de geração de código no servidor,
como o PHP: Hypertext Preprocessor, que são aplicações presentes no lado do
servidor web que gera de forma dinâmica conteúdo para exibição em navegadores
por humanos apenas. Na terceira fase evolutiva, aplicações baseadas em esquema
por exemplo XML-schema, que geram conteúdo dinâmico usável por humanos e
50
outras aplicações baseadas em análise de sintáticas, permitindo integração de
processos como EAI – Enterprise Aplication Integration, BPMS – Business Process
Management Software e Workflows, que são sistemas de controle de processos e
fluxos de atividades em diversos campos de aplicação. Na fase atual da web
encontramos os recursos de análise semântica, em conteúdos gerados por aplicativos
baseados em modelos, como as ontologias, que permitem a interoperabilidade de
sistemas e integração de dados dispersos na rede, através de agentes inteligentes
como reasoners e motores de busca baseados nestes agentes (CARDOSO, 2007).
2.9.1
A Semântica Web
A Web na sua fase sintática possibilita funcionalidades como integração de
sistemas, através do encapsulamento de funções internas aos sistemas com
esquemas XML, empregando web services e metadados, o que poderia permitir a
interoperabilidade dos sistemas, se houvesse uma padronização dos XML.
A integração de dados, no entanto, é limitada devido a não haver um
entendimento comum do que cada informação significa em cada contexto, ou seja, a
semântica das informações. A questão central da integração de dados refere-se ao
acesso e combinação de informações dispersas em várias fontes autônomas de forma
a proporcionar ao usuário, quer seja um humano ou uma máquina, uma visão
unificada destes dados (CARDOSO, 2007).
Segundo Fensel, et al. (2008), a Semântica Web tem por objetivo tornar
esta grande massa de informações que alguns denominam como BIG DATA,
acessíveis por máquinas, usando notações do conteúdo na Web através de formatos
inteligíveis por máquinas tal como o formato RDF – Resource Description Framework,
que são modelos ou metadados que cria um modelo simples de dados com uma
semântica formal usando o URI – Uniform Resource Identifier e sintaxe especifica,
como o Turtle, o RDFa-Primer, o JSON-LD ou o TriG.
Conforme definido pelo W3C (2015), o RDF é um modelo de dados
baseados em gráfico, sendo o núcleo central da sintaxe abstrata um conjunto de
triplas, cada uma consistindo de um sujeito (subject), um atributo (predicate) e um
objeto (object), como ilustra a Figura 12.
51
Um conjunto destas triplas é denominado gráfico RDF, que pode ser
visualizado como um nó e diagrama de arco dirigido, no qual cada tripla é
representado como um link nó-seta-nó.
O gráfico possui dois nós (sujeito e o objeto) e uma tripla conectando eles
representando a propriedade ou atributo.
Podem existir três tipos de nós em gráficos RDF:
IRI que representam os recursos (resurces) dentro do domínio
representado, podendo significar um objeto físico, um documento,
conceitos abstratos, através de um identificador único;
Literais, que representam os recursos (resurces) dentro do domínio
representado, podendo significar um objeto físico, um documento,
conceitos abstratos, sendo um sinônimo de entidade como utilizado
na especificação de RDF Semântico;
Blank nodes, que diferentemente de IRI e Literais, não identificam
um recurso específico, apenas declaram que algo existe com um
dado relacionamento existe sem, no entanto, nomeá-lo.
Figura 12 - Gráfico RDF.
Fonte: Adaptado de W3C (2015).
As URI são mantidas e organizadas pela IANA – Internet Assigned
Numbers Authority, uma entidade sem fins lucrativos que administra os nomes de
domínios, identificadores de recursos e registros de protocolos.
O W3C – World Wide Web Consortium, através da IETF – Internet
Engineers Task Force, mantém disponíveis as RFC, que são Request for Comment,
52
documentos que normatizam de forma propositiva diversas funcionalidades,
protocolos, formatos e esquemas para a comunidade da internet.
A integração e interoperabilidade de sistemas na Web exige mais do que
um esquema baseado em XML, porque no XML os desenvolvedores podem criar suas
próprias tags, não sendo possível indicar um sentido para os dados, neste sentido
pesquisadores vêm desenvolvendo diversos formatos baseados em semântica, como
o RDF e o OWL – Web Ontology Language, que proporcionam novas funcionalidades,
permitindo o compartilhamento de dados e documentos que tornam a busca e reuso
da informação muito mais fácil e rápida em toda a internet (CARDOSO, 2007).
A semântica é o estudo do significado de palavras, termos, expressões; na
ciência da informação é usada para indicar o significado de sinais como termos ou
palavras, dependendo da abordagem, do modelo ou método usado para adicionar
semântica aos termos, diferentes modelos de semântica podem ser usados.
A Figura 13 ilustra os diversos níveis dos modelos atuais e como se
relacionam com o acréscimo de níveis de maior detalhamento dos metadados que
descrevem as informações e os seus relacionamentos.
Figura 13 – Níveis de Modelos de semântica na Web
Fonte: Adaptado de Cardoso (2007).
53
2.9.2
Arquitetura SOA e Web Services
O padrão SOA – Service-Oriented Architeture constitui-se na arquitetura
que estabelece o paradigma da computação orientada a serviços, cujo conceito é
prover a interoperabilidade com um fraco acoplamento entre os sistemas, pelo
encapsulamento das informações serializadas através de interfaces neutras e
empregando protocolos de transporte padronizados (SALAS, 2012).
Serviços são componentes abertos, auto descritivos que permitem a
construção de aplicações distribuídas de forma fácil e com baixo custo, utilizando um
protocolo padrão e aberto de comunicação, como por exemplo, o HTTP,
proporcionando uma infraestrutura de computação distribuída desde redes internas
(LAN) até grandes corporações. Um serviço possui uma interface de comunicação
que fornece informações sobre o serviço, como parâmetros de entrada, saída, erros
e tipos de mensagens (SOUZA, 2006).
A Figura 14 ilustra de forma simplificada a arquitetura SOA, originalmente
proposta pela equipe de desenvolvimento de serviços Web da IBM, é basicamente
uma arquitetura cliente-servidor, em um contexto mais amplo, possui três entidades
principais; o provedor de serviços que disponibiliza os serviços acessíveis na rede, o
cliente de serviços, que usa um serviço fornecido pelo provedor, consultando a
agência de registros que mantém o registro dos serviços disponíveis, descrevendo
suas funcionalidades, localização e protocolos utilizados nos serviços, métodos de
acesso, entre outros.
Figura 14- SOA e mecanismos internos.
Fonte: Souza (2006).
54
Segundo Salas apud Moorsel (2012), Web Services permitem a
interoperabilidade entre aplicações desenvolvidas em linguagens de programação
diferentes e executadas sobre qualquer plataforma na camada de transporte do
modelo ISO. Composto por um conjunto de serviços e padrões definido como Pilha
de Padrões dos Web Services (WSSP - Web Services Protocol Stack), conforme
Direto: UDDI
Publicação de serviços
WSDL
Descrição de Serviços
SOAP
Transporte XML
HTTP, FTP, etc.
QUALIDADE DE SERVIÇOS
Descoberta de serviços
ADMINISTRAÇÃO
Estático: UDDI
SEGURANÇA
ilustrado na Figura 15.
Camada de aplicações
Figura 15 - Pilha de padrões Web Services
Fonte: Adaptado de Salas (2012).
Na pilha WSSP pode-se observar onde atuam os principais padrões
empregados nos Web Services:
XML, Extensible Markup Language ou linguagem baseada em tags
desenvolvida
pela
W3C
como
padrão
de
serialização
e
encapsulamento de informações, sendo um subtipo da linguagem
SGML – Standard Generalized Markup Language;
SOAP – Simple Object Access Protocol, para acesso a informações
estruturadas em uma plataforma distribuída, usando o padrão XML;
55
WSDL – Web Services Description Language, linguagem baseada em
XML utilizada para descrever os Web Services, que além de
descrever o serviço especifica como acessá-lo e as operações ou
métodos disponíveis.
UDDI – Universal Description, Discovery and Integration, que
especifica o método usado para publicar e descobrir diretórios ou
repositórios de serviços na SOA.
A Figura 16
ilustra a interação entre os atores e as operações na
arquitetura SOA empregada em Web Services, onde se pode abstrair que o Provedor
de Serviços é o titular, ele publica o Web Service no Serviço de Registro, usando o
padrão WSDL/UDDI, enquanto o Serviço Solicitante, que é o cliente, descobre o
serviço também usando o padrão WSDL/UDDI, no Serviço de Registro ele invoca o
Web Service do provedor, que por sua vez vincula o serviço solicitado, este processo
é denominado Three-Way Handhake.
Figura 16 - Operações e atores em Web Services.
Fonte: Salas (12012)
Para tanto, os protocolos são empilhados de forma a disponibilizar as
funcionalidades necessárias, para usarem a camada padrão de transporte da pilha
ISO, conforme indicado na Figura 17, sendo o HTTP o protocolo de transporte, o XML
o de encapsulamento e serialização de dados e sobre este os protocolos responsáveis
pelas respectivas funções do Three-Way handshake (W3C, 2015).
56
Função
Formato
Transporte
UDDI
XML
HTTP
WSDL
XML
HTTP
SOAP
XML
HTTP
Figura 17 - Pilhas de protocolos em Web Services
Fonte: Adaptado de W3C (2015)
2.10
CONSIDERAÇÕES FINAIS DO CAPÍTULO
Na fundamentação teórica foram apresentados os conceitos de prédios
inteligentes, os principais sistemas que compõem uma automação predial, os
conceitos básicos de redes elétricas inteligentes no que tange ao projeto proposto,
foram apresentadas as técnicas de controle de demanda mais usualmente
empregadas, bem como o conceito de gerenciamento pelo lado da demanda e as
ações correspondentes de resposta à demanda.
Foram apresentados os protocolos de comunicação mais empregados
comercialmente em automação predial e uma visão geral dos principais fabricantes
destas soluções.
Completando a fundamentação, com base da arquitetura SOA, foram
caracterizados os webservices, a plataforma web e a introduzidos os conceitos
básicos da engenharia de domínios, aqui representadas pelas ontologias, com uma
abordagem comparativa em relação à engenharia de aplicações.
57
3
REVISÃO BIBLIOGRÁFICA
Neste capítulo são apresentados os mais atualizados conceitos, modelos e
tecnologias disponíveis de forma a situar a proposta deste trabalho no contexto das
redes elétricas inteligentes e da automação predial.
Segundo Gomes (2014), o Sistema Elétrico de Potência (SEP) encontra-se
na eminência de transformações revolucionárias, em função do advento das Redes
Elétricas Inteligentes - REI, ou Smart Grids, que juntamente com novos marcos
jurídicos no setor tornam uma realidade emergente os sistemas de geração
distribuída, como o proposto pelo autor em sua dissertação de mestrado que
descreveu o uso de sistemas de microgeração por meio de fontes renováveis.
Muitos têm sido os esforços de pesquisadores no sentido de desenvolver
modelos de sistemas e modelos de negócios voltados para esta nova realidade dos
SEP, como os trabalhos desenvolvidos por Camargo (2014), para armazenamento
de energia visando deslocamento de cargas, por Eggea (2014) sobre gerenciamento
de energia incluindo painel fotovoltaico e armazenamento de energia para REI via
aplicativo de celular, bem como o trabalho desenvolvido por Mac e Faria (2012) sobre
o impacto das REI nas tarifas das distribuidoras de energia.
As funcionalidades e vantagens que as REI proporcionam são diversas,
como as apontadas por Ekanayake et al. (2012) de permitir resposta à demanda - DR,
gerenciamento pelo lado da demanda - DSM, dispositivos inteligentes – IoT, geração
distribuída e armazenamento de energia – DER e da influência da resposta à demanda
sobre as redes de distribuição, apontadas por Levy (2013), que aponta para melhoria
significativa na rede de distribuição em função da participação efetiva dos
consumidores, principalmente dos horários de ponta no consumo.
Há que se considerar, no entanto, que existem fatores adversos, como a
dificuldade de balanceamento do fluxo de potência na rede de distribuição em função
da participação das fontes alternativas de energia como geradores eólicos, que
apresentam variações ao longo do dia e das estações do ano, o que requer novas
técnicas de controle da rede, como o controle descentralizado proposto por Schäfer
et al. (2015), onde a métrica para solicitação de DR não seria mais o preço, mas sim
a frequência da rede, este modelo será apresentado com detalhes mais adiante.
58
3.1
MODELAGEM DE SISTEMAS PREDIAIS
A automação predial é um dos elementos que compõem um conjunto amplo
de sistemas que interagem para disponibilizar aos usuários as funcionalidades e
serviços essenciais para a operação de um prédio (WANG, 2010).
Sendo um item essencial de projeto, existem várias iniciativas
desenvolvidas por entidades de padronização em nível internacional no sentido de
estabelecer
padrões
para
comunicação
visando
integração
de
sistemas,
interoperabilidade de sistemas e modelagem de informações.
O Building Information Modeling - BIM é padrão aberto e gratuito de
representação e projeto de sistemas abrange todas as disciplinas envolvidas no
planejamento e execução de um empreendimento, com conexão direta com softwares
de projeto baseados em Computer Aided Design - CAD, onde é possível virtualizar
todos os elementos físicos do prédio, uma parede se comporta como uma parede, um
motor como tal, de forma que as interferências e interações entre estes elementos são
identificadas em tempo de projeto (SABOL, 2008).
De acordo com Sinopoli et al. (2013), a modelagem de sistemas de
automação envolve o desenvolvimento de uma Industry Foundation Classes (IFC)
específico para sistemas de automação e controle. O IFC é um modelo de dados
aberto e neutro, que descreve os dados do setor de construção civil para facilitar a
interoperabilidade dos dados entre designers, empreiteiros e gestão de instalações. A
especificação do modelo IFC é registrado pela “International Organization for
Standardization” (ISO) e é um padrão internacional oficial (ISO 16739:2013).
O BIM foi desenvolvido para ser utilizado durante todo o ciclo de vida do
empreendimento, desde sua concepção, operação e manutenção, oferecendo
recursos de gerenciamento dos sistemas e ativos em tempo real, através da
modelagem dos sistemas e conexão com outros sistemas empregando uma biblioteca
padrão IFC, como sugerido na Figura 18, na integração com o padrão COBie –
Construction Operation Building Operations information exchange. O projeto
desenvolvido em CAD com o BIM gera um arquivo de exportação no padrão IFC que
59
pode ser importado por uma base de dados externa em outro aplicativo, ou num
formato planilha eletrônica.
Figura 18 - Aplicação do BIM no padrão COBie.
Fonte: Sabol (2008).
3.1.1
Modelo Cobie
O COBie é uma especificação para intercâmbio de informações para
captura e entrega de informações necessárias para os gerentes de empreendimento
durante todo o ciclo de vida. A sua versatilidade proporciona ao COBie ser empregado
em projetos independentemente do tamanho ou nível de sofisticação tecnológica.
COBie foi desenvolvido pelo NIBS - National Institute of Building Sciences
através de uma equipe multidisciplinar de projetistas, construtores, proprietários,
agentes de comissionamento e empresas de software que identificaram os requisitos
de trocas de informações necessárias desde as etapas de construção até sua
operação (NIBS, 2015).
60
Segundo East (2009), no COBie, empregando os padrões de especificação
da IFC, todos os componentes são considerados e representados no modelo COBie,
como por exemplo os equipamentos elétricos, com atributos que detalham seus
parâmetros de operação, como ilustrado na Figura 19, a representação de um motor
elétrico usando o objeto ifcElectricalExtentedProporties:
Figura 19 - Atributos estendidos de um equipamento.
Fonte: NIBS, (2015)
3.1.2
Modelo BAMie
O Building Automation Modeling information exchange (BAMie) é um
projeto em desenvolvimento pelo NIBS com participação do US Army, do Corps of
Enginners, Engineer Research and Development Center e do Contruction Engineering
Research Laboratory para estabelecer um modelo com base no COBie, mas voltado
para o domínio dos sistemas de automação e controle predial, estabelecendo padrões
abertos e compartilhados para requisitos de especificação, programação, construção,
disponibilizando as informações de forma estruturada (NIBS, 2015).
A arquitetura do modelo BAMie está organizada como ilustrado na Figura
20, onde pode-se observar as diversas camadas da especificação, composta
61
basicamente por tipos, entidades, propriedades, atributos, valores, regras e funções.
Os sistemas de controle e automação predial compreendem os domínios indicados
por “Building Control Domain”, “Electrical Domain”, “HVAC Domain”, “Plumbing
FireProtection Domain”.
As camadas ou níveis conceituais são definidos como:
Rescource layer, inclui todos as definições de recursos individuais,
e não podem ser usados sem as declarações das camadas
superiores;
Core layer, incluir o Kernel e extensões do core, contém as
definições genéricas de entidades, todas as entidades definidas
neste nível ou acima possuem um Id único e opcionalmente um dono
e histórico;
Interoperability layer, esta camada inclui schemas contendo
definições de entidades que são específicas que são próprias a um
produto genérico, processo ou recurso especializado usado ao pelas
diversas disciplinas, estas definições são tipicamente utilizadas para
compartilhamento e troca entre os domínios na construção da
informação;
Domain layer, sendo o mais alto nível conceitual inclui schemas
contendo definições de entidades que são especificações de
produtos, processos ou recursos específicos de uma certa disciplina,
sendo utilizadas para compartilhamento e troca de informações
entre os domínios.
62
Figura 20 - Arquitetura do BAMie com os níveis conceituais.
Fonte: NBIS (2015).
No trabalho desenvolvido por Bogen et al. (2012), são apresentadas
aplicações práticas do BAMie, a Figura 21 ilustra um exemplo de aplicação do modelo
na integração de sistemas prediais com base no protocolo BACnet, tendo como fonte
de dados o BAMie, exportação de dados via oBIX para uma base de dados relacional
e apresentação de dados em um dashboard.
63
Figura 21 - Aplicação do BAMie na integração de sistemas.
Fonte: Adaptado de Bogen et.al. (2012).
Todas as informações sobre o modelo BAMie, incluindo as especificações,
esquemas, escopo, métodos de serialização de dados e protocolos podem ser
encontradas no endereço: http://docs.buildingsmartalliance.org/MVD_BAMIE.
3.1.3
Modelo oBIX
Elaborado pela OASIS – Advancing Open Standards for the Information
Society, o oBIX – Open Building Information Exchange é um modelo que proporciona
que sistemas de controle predial de equipamentos eletromecânicos possam
comunicar-se com aplicações enterprise, e provê uma plataforma de desenvolvimento
de novas classes de aplicações que integram sistemas de controle com outras funções
que incluem processos internos às empresas como setor de recursos humanos,
financeiro, CRM – Costumer Relationship Management e processos industriais.
Uma aplicação enterprise abrange diversos departamentos de uma
empresa, que pode estar localizada geograficamente em vários locais através de filiais
64
que precisam trocar informações para funcionar de forma a atender seus objetivos
empresariais.
O oBIX é projetado para fornecer acesso aos sistemas com software
embarcado, para sensorizar e controlar o todos os dispositivos. Historicamente para
integrar estes sistemas eram necessários protocolos de baixo nível personalizados,
interfaces de rede, muitas vezes interfaces físicas personalizadas.
O rápido aumento das redes ubíquas e da disponibilidade de potentes
microprocessadores para dispositivos embarcados de baixo custo está tecendo esses
sistemas no próprio tecido da Internet.
A facilidade da comunicação máquina a máquina (M2M) descreve a
transformação que ocorre neste domínio, porque abre um novo capítulo no
desenvolvimento da Web - máquinas podem autonomamente comunicar-se umas
com as outras (Considine e Ehrlich, 2006).
A especificação oBIX estabelece as bases para construir este padrão Web
M2M, usando tecnologias corporativas amigáveis como XML, HTTP e URIs.
O oBIX propõe-se a atender às seguintes premissas de concepção:
XML: representando informações M2M em uma sintaxe XML padrão;
Networking: a transferência de informações M2M em XML através da
rede;
Normalização: representações padrão para características comuns: M2M
pontos, histórias e alarmes;
Fundação: fornece um kernel comum para novos padrões;
A arquitetura oBIX baseia-se nos seguintes princípios:
Object Model: um modelo de objeto conciso usado para definir todas
as informações oBIX;
Sintaxe XML: uma XML de sintaxe simples para expressar o modelo
de objeto;
URIs: URIs são usados para identificar as informações dentro do
modelo de objeto;
REST: um pequeno conjunto de verbos é usado para acessar
objetos através de seus URIs e transferir seu estado via XML.
65
Contracts: um modelo de template para expressar novos "tipos"
oBIX.
Extendibility: prevê extensibilidade consistente usando apenas
esses conceitos.
Conforme ilustra a Figura 22, todas as informações contidas oBIX são
representados usando um pequeno conjunto fixo de primitivas. A abstração base para
essas primitivas é chamada objeto. A um objeto pode ser atribuído um URI e todos os
objetos podem conter outros objetos.
Figura 22 - Modelo de Objeto no oBIX.
Fonte: (Considine e Ehrlich, 2006).
66
3.1.4
MODELO FSGIM – ASHRAE
Conforme apresentado por Bushby (2011), a NEMA – National Electrical
Manufacturers Association e a ASHRAE - Americam Society of Heating Refrigerating
and Air-Conditioning Engineers juntaram esforços para desenvolver um padrão
industrial, o FSGIM – Facility Smart Grid Information Model, com o propósito de criar
um modelo comum de informações para permitir que equipamentos, sistemas de ar
condicionado e sistemas de controle em residências, prédios e indústrias possam
gerenciar as cargas e a geração distribuída em resposta à comunicação com a rede
elétrica inteligente. O padrão inclui a capacidade de disponibilizar acesso ás
funcionalidades incluindo:
Gerenciamento da geração local;
Resposta à demanda;
Gerenciamento de armazenamento de energia local;
Gerenciamento de pico de demanda;
Estimativa de uso futuro de energia;
Estimativa de capacidade de redução de carga;
Monitoramento de cargas de consumidores;
Monitoramento da qualidade da energia;
Histórico de consumo de energia;
Controle direto de cargas.
A Figura 23 ilustra o modelo de implementação proposto pelo padrão
FSGIM, o qual prevê modificações nos atuais protocolos padrão de comunicação,
incluindo uma revisão no BACnet para compatibilidade com o padrão proposto.
67
Figura 23 - Modelo do FSGIM.
Fonte: Buschby (2011).
3.2
ESTRATÉGIAS DE GERENCIAMENTO PELO LADO DA DEMANDA
Segundo Levy (2013), existem diversos programas de gerenciamento pelo
lado da demanda, que podem ser classificados conforme demonstrado na tabela 5:
Tabela 5 – Programas de DSM.
Categoria
Programa DSM
Tarifação em tempo real (RTP)
DSM baseado em preços e
tarifas
Período de uso (TOU)
Tarifação de ponta (CPP)
Controle direto da demanda (DLC)
DSM baseada em incentivo
financeiro
Interrupção consentida da
demanda (I/C)
Redução da demanda em
emergência
Oferta de redução da demanda
Fonte: Adaptado de Levy (2013).
A importância do gerenciamento da demanda torna-se mais clara quando
se observa a curva de carga típica de consumo, indicando dois grandes picos de
68
consumo horários que superam em muito o consumo médio no mesmo período, como
Valores em MWh
ilustrado na Figura 24.
Figura 24- Curva de Carga típica do dia de maior consumo.
Fonte ANEEL (2015).
A Figura 25 ilustra a comparação dos perfis de consumo de um consumidor
sem gerenciamento de carga (gráfico da esquerda), com o de um consumidor com
forte capacidade de gerenciamento de cargas (gráfico da direita).
Figura 25 - Comparação entre perfis de consumo residencial.
Fonte: ANEEL (2015).
69
As estratégias e programas de gerenciamento pelo lado da demanda
visando resposta à demanda pelos consumidores estão focados no modelo de
centralização de informações e do gerenciamento das requisições, com objetivo de
promover um balanço adequado entre oferta e consumo, e com efeito direto sobre os
parâmetros de qualidade da energia, bem como aumentando a confiabilidade do
sistema, considerado no modelo atual de redes elétricas convencionais.
Segundo Shäfecr et al. (2015), este modelos baseados em tarifas ou
incentivo financeiro podem não ser eficientes num ambiente de smart grid, pois não
considera os fatores decorrentes da injeção da geração distribuída na rede, que por
sua vez produzem variações nos parâmetros da rede, principalmente na frequência
da rede.
Neste sentido, Shäfecr et al. (2015) propõem um modelo de controle
descentralizado de resposta à demanda, que dinamicamente atue sobre o sistema no
sentido de compensar em tempo real as flutuações da frequência da rede
pontualmente.
Figura 26 - Influência dos preços na frequência da rede.
Fonte: Shäfecr (2015).
A Figura 26 ilustra a influência dos preços ofertados no programa de
resposta à demanda sobre o parâmetro de frequência da rede, onde o gráfico (a)
70
representa as ofertas de tarifas do DSM em função da frequência no grid, no gráfico
(c1) os valores obtidos da frequência da rede quando se aplica uma relação linear
entre a oferta de preços e a frequência instantânea medida, enquanto que no gráfico
(c2) são apresentados os resultados obtidos quando se aplica uma relação não linear.
O conceito proposto por Shäfecr et al. (2015) consiste em utilizar um
equipamento de baixo custo instalado próximo ao consumidor, que possa gerar as
informações de ofertas tarifárias no sentido de manter um balanço de potência
equilibrado, aumentando o preço da energia quando a frequência da rede cai abaixo
do valor nominal e baixando o preço quando a frequência da rede eleva-se acima do
valor nominal, de forma a que controladores de carga internos ao sistema do
consumidor possam atuar sobre as cargas através de algoritmos de controle de
demanda.
3.3
O MODELO DE COMUNICAÇÃO OPENADR
Segundo Koch et al. (2007), o desenvolvimento de um protocolo que
permitisse resposta automática à demanda teve início por volta de 2002, com os
trabalhos de pesquisa realizados pelo Demand Response Research Center – DRRC,
pertencente ao Lawrence Berkeley National Laboratories – LNBL e diversas
concessionárias de energia do estado da Califórnia, nos Estados Unidos da América.
O openADR proporciona um meio de comunicação contínuo, confiável e
seguro entre os consumidores e os fornecedores de energia, para que seja possível
o recebimento de sinais de DR, empregando um padrão industrial aberto de tecnologia
de comunicação desenhado para integrar-se tanto com os sistemas de gerenciamento
e controle de demanda como com sistemas mais antigos, através de relés de contato
seco por meio de um gateway.
O openADR emprega um conceito cliente-servidor, com um VTN - Virtual
Top Node na versão 2.0 operando como um administrador das requisições originadas
nas concessionárias, aqui referenciadas como Utility ou ISO, despachando estas
mensagens de solicitação para os prédios, diretamente ao BMS ou BEMS, ou ainda
para grupos de cargas agregadas em sistemas cliente VEN – Virtual End Node, como
no caso de microrregiões das redes REI, como ilustrado na Figura 27. Uma das
71
premissas é de que uma vez recebido o evento de solicitação de DR, os sistema
ECMS poderá ativar uma das estratégias de DR previamente configuradas, podendo
o consumidor, no entanto, recusar atender ou mesmo sobrescrever um novo modo de
operação a qualquer momento (Han et al.,2008).
Figura 27 - Arquitetura do openADR 2.0
Fonte:
OpenADR Alliance (2012)
A arquitetura de nuvem do openADR é ilustrada na Figura 26, onde podese identificar os diversos agentes que atuam no sistema:
VTN, servidor do sistema openADR
VEN, clientes recebem as requisições de DR;
VTN/VEM, agregadores de carga, instituições que negociam
pacotes de DR com as ISO e com os clientes;
ISO são os geradores e fornecedores de energia
72
O fluxo de informações entre os diversos agentes que compõem o sistema
é apresentado na Figura 28, através do diagrama UML de caso de uso na notificação
de eventos:
Figura 28 - Caso de uso do openADR.
Fonte: Adaptado de Holmberg (2012).
Como ilustra a Figura 28, o planejamento das requisições é realizado no
fornecedor, que pode configurar no DRAS o perfil desejado de DR do sistema, no lado
do site participante o gerente do empreendimento pode configurar o modo de
operação e resposta às requisições de DR, o DRAS gera a notificação do evento ao
cliente DRAS que está instalado no cliente. O evento dispara então a estratégia de
controle de cargas programado no ECMS do empreendimento. Como pode ser
observado, o sistema é estático no sentido de executar um programa de DR ajustado
no ISO, acionando uma respectiva estratégia no cliente. No entanto não há nenhuma
garantia de atendimento às requisições de DR por parte dos clientes, e a programação
do tipo “dia seguinte” está sujeita a diversos fatores condicionantes imprevisíveis.
McParland (2011) apresenta um estudo de caso onde sugere um sistema
de distribuição de energia no qual o ISO necessita reduzir carga para manter a
73
estabilidade da rede, através do openADR consegue identificar quais consumidores
registrados no DRAS estariam aptos a atender a requisições de DR em um programa
em particular, e eles têm de concordar em responder dentro de limites previamente
acordados às requisições do DRAS dentro de um intervalo de tempo definido.
O não atendimento às requisições de DR no exemplo apresentado
implicaria em penalidades posteriores quando o consumidor viesse a renovar o
programa, perdendo descontos ou pagando uma taxa maior pela energia no futuro.
O openADR versão 1.0 define dois tipos de clientes para os sistemas
prediais participantes, o smart DARS client, capaz de receber todos os eventos de DR
especificados para a utilidade, e o simple DARS client, os quais recebem apenas um
conjunto menor de eventos, caracterizados por níveis simples como normal,
moderado ou alto (HOLMBERG et al., 2012).
As técnicas e estratégias de controle para DR usando openADR estão
compreendem as apresentadas por Motegi et al. (2007), que as classifica em quatro
categorias principais, de acordo com sua área de aplicação:
Sistemas HVAC;
Iluminação;
Equipamentos diversos;
Medições de uso não específico;
Estas estratégias objetivam promover redução do consumo de energia em
um determinado período de tempo, deslocando assim a demanda por energia para
fora do horário de ponta, quando o sistema se encontra mais sobrecarregado. As
estratégias consideram diversos parâmetros ambientais como temperatura externa,
ocupação do prédio, temperatura máxima de conforto, etc.
Os sistemas BMS possuem uma base de dados local que armazenam as
informações sobre os dispositivos e equipamentos como máquinas de ar
condicionado, controladores de demanda, utilidades e equipamentos de geração
como geradores a diesel, eólicos e painéis fotovoltaicos. Acima destes sistemas pode
existir ou não uma camada de gerenciamento geral, o ECMS que centraliza as
informações e possui os algoritmos de aplicação das estratégias de resposta à
demanda eventualmente solicitadas através do OpenADR. Estas informações, no
entanto, estão disponíveis e são usadas apenas no escopo interno de cada sistema
74
predial, não oferecendo um cenário mais abrangente para a concessionária de
fornecimento de energia.
A versão 2.0 do openADR apresenta uma arquitetura moderna, renomeia
o DRAS da versão 1.0 como Virtual Top Node (VTN) e o lado do consumidor é
designado como Virtual End Node (VEN). Nesta versão 2.0, o openADR prevê a
capacidade de acionar recursos como DER.
3.4
ESTADO DA ARTE SOBRE INTEROPERABILIDADE
Diversos centros de pesquisa vêm desenvolvendo trabalhos com base no
openADR, como o EPRI – Energy Power Research Institute, que disponibiliza um
projeto de servidor VTN no modelo do openADR 2.0 e um cliente VEN desenvolvido
em .NET, em código aberto para possibilitar às empresas interessadas em
implementar o padrão em seus produtos uma referência de operação do modelo de
comunicação openADR 2.0 (EPRI, 2015)
O Pacific North National Laboratory desenvolveu o projeto Volttron, um
agente inteligente para operar sobre redes elétricas inteligentes que permite controle
de cargas e geração distribuída através da comunicação entre os consumidores e
possui um plug-in para o protocolo openADR. O conceito do Volttron envolve
controladores inteligentes operando em rede, localizados próximos às cargas e à
geração distribuída, através de uma arquitetura multiagentes inteligentes (DRRC,
2015).
O Demand Response Research Center – DRRC desenvolveu algumas ferramentas
de apoio às pesquisas na área de GLD e DR, entre estas um banco de dados
denominado AutoDR Database Tool (ADRD), com objetivo de disponibilizar na nuvem
uma base de dados sobre edificações, permitindo realizar buscas com base em
padrões de consumo, capacidade de resposta à demanda em relação às condições
de carga e climáticas.
75
3.5
CONSIDERAÇÕES FINAIS DO CAPÍTULO
Neste capítulo foram apresentados as técnicas e padrões atualmente
utilizados na modelagem de sistemas prediais, bem como os modelos de
comunicação disponíveis para a integração de dados e interoperabilidade dos
sistemas com as redes elétricas.
As limitações impostas por estas técnicas não permitem uma modelagem
no nível dos metadados, essenciais para representação das informações com as
quais tecnologias como multiagentes inteligentes ou máquinas de inferência e
aprendizagem como lógica difusa, redes neurais e mesmo algoritmos heurísticos
possam operar.
Esta lacuna abre a oportunidade da proposta de uma metodologia com
base na engenharia de domínios, empregando modelos ontológicos para a
representação de conhecimentos, aqui entendido como classificação, propriedades e
relacionamentos dos elementos que compõem os sistemas de automação predial e
as redes elétricas nos SEP.
76
4 MATERIAIS E MÉTODOS
Neste capítulo serão apresentadas as ferramentas e a metodologia
aplicada no desenvolvimento da pesquisa deste projeto.
4.1
CONTEXTUALIZAÇÃO DA SOLUÇÃO PROPOSTA
A aplicação de ontologias como metodologia de modelagem do domínio de
sistemas de automação predial e sistemas de redes elétricas inteligentes justifica-se
pelas características peculiares que as ontologias apresentam em relação às demais
técnicas.
A modelagem de um sistema de automação predial através de uma
ontologia requer o emprego de uma ferramenta de criação e edição. Neste trabalho
foi escolhido o editor de ontologia baseado em frameworks Protégé Desktop, versão
4.3, pelo fato de ser um aplicativo de uso livre, compatível com os padrões W3C, com
suporte à linguagem OWL, interface gráfica de fácil utilização e diversos plug-ins que
disponibilizam funcionalidades adicionais, bem como suporte a diversos reasoners.
A proposta de uso de ontologias na modelagem do domínio dos sistemas
elétricos de potência permite, entre outras facilidades:
Uso de ferramentas open-source;
Interoperabilidade;
Alterações no modelo em tempo de execução;
Semântica Web
Uso de máquinas de aprendizagem e inferências (reasoners);
Conectividade entre ontologias;
Reuso do conhecimento e dos modelos;
A figura 29 apresenta o cenário atual onde se encontra este trabalho, como
uma metodologia de modelagem do conhecimento dos sistemas prediais, visando
preencher a lacuna entre o DSM e DR, com aplicabilidade também em redes elétricas
inteligentes.
77
Figura 29 - Contexto do trabalho
Fonte: O autor
O
padrão
openADR,
empregado
na
comunicação
visando
interoperabilidade não possibilita, atualmente, a estimação de disponibilidade de
resposta à demanda e não permite ainda previsão de uso dos DER.
A metodologia proposta complementa o openADR, agregando as
funcionalidades de estimação de DR e previsibilidade de DER, com atualizações em
tempo real de informações.
Neste contexto, a distribuidora, como gerenciadora dos programas de DSM
pode visualizar um cenário de estimação de cargas, de DR e de DER, considerados
os prédios com sistemas BAS instalados, que são o objeto deste trabalho.
A tabela 6 ilustra um comparativo entre as diferenças nas abordagens entre
as metodologias empregando linguagens orientadas a objeto e ontologias com
OWL/RDF na modelagem de sistemas.
78
Tabela 6 - Comparativo entre Model-Drive Design e OWL/RDF.
Linguagens orientadas a objeto
OWL e RDF
Funcionalidades diversas
Participação no processo de
desenho
Propriedades, atributos e valores
Classes e Instâncias
Modelos de domínios consistem de classes, propriedades e instâncias (indivíduos). Classes podem ser organizadas
em uma hierarquia de subclasses com heranças. Propriedades podem ter objetos ou literais como valores.
Classes são tipos de instâncias.
Classes são conjuntos de indivíduos.
Cada instância pertence a uma única classe.
Classes não podem compartilhas instâncias.
Cada indivíduo pode pertencer a múltiplas classes.
Instâncias não podem mudar seu tipo em tempo de
execução.
Membros de classes podem mudar em tempo de
execução.
A lista de classes é totalmente definida em tempo de
compilação e não pode mudar depois disso.
Classes podem ser criadas e alteradas em tempo de
execução
Compiladores são usados para gerar executáveis. Erros
são indicados em tempo de compilação.
Reasoners podem ser usados para classificação e
verificação de consistência em tempo de execução ou
quando da construção da ontologia.
Propriedades são definidas localmente para a classe (e
suas subclasses por herança).
Propriedades são entidades autônomas que podem
existir sem uma classe específica.
Instâncias podem ter valores apenas para as suas
propriedades. Valores devem ser do tipo correto.
Restrições de faixas são usadas para verificação do tipo.
Instâncias podem ter valores arbitrários para qualquer
propriedade. A faixa e restrição são usadas para
verificação do tipo e inferências.
As classes codificam muito do seu significado e
comportamento através de métodos e funções
imperativas.
As classes tornam seu significado explícito em termos
de declarações OWL, não é possível associar um código
imperativo.
Classes podem encapsular seus membros de acesso
privado.
Todas as partes de um arquivo OWL/RDF são públicos e
podem ser linkados para e por qualquer agente.
Mundo fechado: Se não existe informação suficiente
para provar que uma declaração seja verdadeira, então
se assume como falsa.
Mundo Aberto: Se não existe informação suficiente
para provar que uma declaração seja verdadeira, então
pode ser verdadeira ou falsa.
Algumas API´s genéricas são compartilhadas entre
aplicações. Poucos (se houver algum) diagramas UML
são compartilhados (reuso).
RDF e OWL foram desenhados com base na web, os
modelos de domínio podem se compartilhados on-line.
Modelos de domínio são desenhados como partes de
uma arquitetura de software.
Modelos de domínio são desenhados para representar
conhecimento sobre o domínio e para integração de
informações.
Semântica Web é uma tecnologia emergente com
UML, Java, C#, etc. são tecnologias maduras suportadas algumas ferramentas de open-source e muitos sistemas
por diversas ferramentas comerciais e open-source.
comerciais.
Instâncias são anônimas enquanto que elas não podem
ser facilmente endereçadas de fora do programa em
execução.
Todos os recursos RDF e OWL nomeados tem um único
URI através do qual pode ser referenciado.
Modelos UML podem ser serializados em XML, voltada
para o intercâmbio entre aplicações, mas não realmente
baseado em Web. Objetos Java podem ser serializados
em vários formatos baseados em XML ou nativos.
Objetos RDF e OWL possuem um padrão de
serialização baseado em XML, com um URI único para
cada objeto dentro do arquivo.
Fonte: Adaptado de Wallace et al. 2006.
79
4.2
MATERIAIS
O desenvolvimento do trabalho de pesquisa, compreendendo a
modelagem dos sistemas prediais e dos alimentadores requereu o emprego de
diversas ferramentas de software, apresentadas de forma geral neste item e com
detalhes no Anexo 1.
4.2.1
Web Services - Apache JENA
O Apache Jena é um framework de uso gratuito e código aberto para
construção de aplicações de link de dados e semântica web composto por diversas
Application Programming Interface – API interagindo em conjunto para processar
dados em formato RDF (APACHE JENA, 2014).
A Figura 30 ilustra a arquitetura do Apache Jena e as API de interação com
as diversas aplicações, neste projeto são utilizadas a API Ontology, a API reasoner,
bem como uma base de dados no padrão TDB (Trivial Data Base).
Figura 30 - Arquitetura do Jena Apache.
Fonte: Adaptado de Jena Apache.org (2015).
80
O servidor de aplicação web desenvolvido para demonstrar a aplicabilidade
do método proposto compõe-se de diversos sistemas que permitem disponibilizar via
web as funcionalidades do sistema proposto, como cadastro de sistemas, consultas
de informações DR. Como sistema operacional foi utilizado o Linux Ubuntu versão
14.10, com o servidor Apache disponibilizando os serviços web, o Pushion Passenger
é o módulo de interface com entre o Apache Server e o ambiente jRuby on Rails, o
qual é um framework de desenvolvimento de aplicações web do jRuby, que roda
aplicativos sobre JVM, para conexão com o Jena, este então fornece as API de
conexão com o banco de dados TDB, que suporta armazenamento das triplas RDF e
com as ontologias do projeto, conforme ilustra o diagrama UML de componentes da
Figura 31.
Figura 31 - Diagrama de componentes do servidor.
Fonte: O autor (2015).
81
4.2.2
O SPARQL
Para as consultas aos dados armazenadas nas ontologias ou nas bases de
dados TBD é utilizado o SPARQL.
SPARQL é o acrônimo para Protocol and RDF Query Language, segundo
o W3C (2015). O SPARQL é uma linguagem padrão de consulta para RDF e também
um protocolo de consultas remotas e recepção dos resultados da consulta.
O SPARQL possui uma sintaxe próxima do SQL, porém com
particularidades como namespaces ou IRI, que permitem a identificação dos recursos
inclusos nas triplas RDF.
SPARQL permite ainda as funções de INSERT DATA, para adicionar triplas
RDF na base de dados, DELETE DATA para remover triplas da base de dados, LOAD
para transformar um documento representativo de um grafo RDF em uma tripla RDF
na base de dados e CLEAR que permite remover todas as triplas na base de dados.
4.2.3
O Trivial DataBase – TDB
O TDB é o acrônimo de Trivial Data Base, sendo um componente do
Apache Jena, para armazenamento persistente de triplas RDF ou triplestores de alta
performance. O TDB pode ser acessado diretamente através scripts de linha de
comando ou através da API apropriada do Jena, denominada TDB-API, sendo
permitido o acesso de somente uma JVM de cada vez, caso contrário pode ocorrer
corrupção de dados.
Triplestores ou armazenadores de triplas são sistemas de gerenciamento
de banco de dados (SGBD) para dados modelados usando RDF. Ao contrário dos
sistemas de banco de dados relacionais (RDBMS), que armazenam dados nas
relações (ou tabelas) e são consultados usando SQL, triplestores armazenam RDF
triplos e são consultados usando SPARQL.
Uma fundamental diferença dos triplestores em relação às bases de dados
relacionais é sua a capacidade de realizar inferências através de reasoners. É
importante notar que um SGBD normalmente oferece a capacidade de lidar com a
concorrência, a segurança, geração de logs, recuperação e atualizações, além de
carga e armazenamento de dados.
82
O acesso ao TDB via API do Jena permite suporte às funções de consulta
SPARQL e atualização SPARQL. Para construir um dataset utiliza-se a classe de
interface TDBFactory, devendo ser atribuído um diretório ou um nome ao construtor –
assembler file.
Um aspecto importante no formato de armazenamento de triplas no TDB é
que os dados são armazenados em declarações, que são as triplas RDF, que não
necessitam uma indexação da mesma forma que um sistema de banco de dados
relacional. Desta forma, o TDB pode ser alterado em tempo de execução pela
aplicação em uso para inserção de campos ou objetos, neste caso representados pela
triplas RDF.
Uma base de dados no formato TDB armazena os dados em um único
diretório dentro do sistema de arquivamento, consistindo de:
Uma tabela de Nodes x NodesId, que armazena a representação
dos termos RDF, comumente chamada de dicionário;
Índices Triple e Quad, sendo o Quad usado para graphs nomeados
e Triple para graphs padrão;
Tabela de prefixos, que estabelece os índices entre os nodes e GPU
(Graph->Prefix->URI).
O TDB foi escolhido como o componente de armazenamento de RDF por
permitir suporte a todas as API do Jena e pelo alto desempenho de armazenamento
em uma única máquina, simplificando a arquitetura da simulação.
O TDB deve ser acessado diretamente por uma única JVM (Java Virtual
Machine) apenas, sob pena de ocorrer corrupção de arquivos, possuindo proteção
interna contra múltiplos acessos a partir da versão 1.1.0. (JENA APACHE, 2014).
4.3
MÉTODOS
O cerne do trabalho compreende o desenvolvimento de um modelo
ontológico de sistemas prediais, exportar este modelo para uma base de dados
persistente (armazenamento em disco) do tipo TDB em formato RDF, desenvolver um
aplicativo servidor com acesso web (via HTTP) hospedado em um servidor Apache
que permite ao usuário, ora considerado como um operador ou administrador do BMS,
83
o acesso a um serviço de cadastramento de todos os recursos energéticos do sistema
predial.
Apesar da ferramenta Protégé ser bastante intuitiva na criação do modelo
representativo do domínio em estudo, não possui uma interface amigável para a
inserção de novos indivíduos, o que precisa ser realizado através de formulários em
uma aplicação com base em uma API, no caso o JENA, empregando-se o protocolo
SPARQL.
No Protégé, inserir um novo indivíduo é simples, porém não intuitivo ao
administrador do sistema no sentido de permitir que ele possa classificar
adequadamente os recursos a serem inseridos em relação ao modelo ontológico do
domínio que foi desenvolvido.
4.3.1
O Ambiente de Simulação
O ambiente de simulação em um servidor Webserver, que disponibiliza os
serviços de consulta e atualização das informações enviadas dos sistemas BMS com
base na modelagem da ontologia predial, para adequação ao modelo de ontologia de
demandas, localizado na nuvem, conforme ilustra a Figura 32.
84
Figura 32 - Ambiente de Simulação.
Fonte: O Autor (2015).
Podem-se identificar duas ontologias, uma empregada como modelo da
base de dados a ser consultada, instalada no servidor e que representa o modelo do
lado predial, e tem por objetivo permitir a interoperabilidade do sistema BMS com a
ontologia de demandas, instalada no servidor Webserver, e uma ontologia de
demandas que representa o lado do sistema de distribuição, sendo ambas importadas
para a aplicação, criando-se um modelo unificado da interoperabilidade.
A Figura 33 ilustra o diagrama UML de caso de uso da ontologia predial e
sua interação com os serviços clientes, ambos instalados junto ao sistema de
automação predial.
85
Figura 33 - Caso de Uso Modelo Ontologia Predial.
Fonte: O autor (2015).
A Figura 34 apresenta o diagrama de interações do processo de cadastro
do sistema BMS na base de dados, através de interface web, acessando o Jena
Apache, que busca o modelo na ontologia predial, apresenta os formulários ao usuário
conectado e armazena os dados na base TDB. Este processo pode ocorrer diversas
vezes, sempre que houver alguma alteração no sistema predial, mantendo assim o
sistema devidamente atualizado.
86
Figura 34 - Diagrama de Interações processo de cadastro BMS.
Fonte: O autor (2015).
O processo de consulta à disponibilidade de resposta à demanda (DR) pelo
ISO/Utility é realizado através do processo ilustrado na Figura 35, onde são
apresentadas as interações deste processo. Neste caso, o modelo está disponível na
ontologia de demandas, que representa diversos sistemas BMS distribuídos na rede
do sistema elétrico de potência.
87
Figura 35 - Diagrama de Interações consulta DR.
Fonte: O autor (2015).
4.3.2
Ontologia Predial
Empregando a ferramenta Protégé, foi desenhado um modelo ontológico
de um sistema predial compreendendo os sistemas mais significativos em termos de
consumo de energia, de tal forma a representar os dispositivos que compõem estes
sistemas, conforme representando do diagrama do Ontograph da Figura 36.
88
Figura 36 - Ontograph das superclasses da Ontologia Predial.
Fonte: O autor (2015).
A superclasse “Sistemas_Prediais” compreende todos os equipamentos,
dispositivos e sistemas internos ao prédio, incluído consumidores, geradores e
referência a alimentadores externos. A superclasse “Classificacao” é usada para os
atributos de prioridade de uso, tipo de sistema e nível de eficiência energética,
permitindo assim estabelecer uma lógica de inferência para determinação da melhor
conFiguração possível ao sistema.
A Figura 37 ilustra a árvore de classes como organizada dentro do Protégé,
onde podem ser observadas as diversas subclasses que compõem o modelo
ontológico proposto para o sistema predial em estudo, sendo este apenas um
subconjunto do BAS, que foi limitado aqui para fins de exemplo na simulação proposta.
89
Figura 37 - Classes da Ontologia Predial.
Fonte: O autor (2015).
Foi utilizado o reasoner Hermit 1.3.8 para inferências de novos interrelacionamentos na ontologia, que gerou os relacionamentos indicados na Figura 38.
90
Figura 38 - Inferências geradas pelo Hermit.
Fonte: O autor (2015).
As inferências nos mostram que os equipamentos listados indicados no
retângulo vermelho pertencem à classe consumidora como consequência de
pertencerem a classes que são subclasses da classe considerada. Esta inferência
decorrente da propriedade transitiva da lógica descritiva empregada pelo Hermit.
De forma semelhante o Hermit verifica a consistência de toda a ontologia,
checando contraprováveis erros de referências quando da sua construção.
Os indivíduos implementados na ontologia de base referem-se às
propriedades que devem ser utilizadas nas regras da modelagem.
Para as características específicas de cada equipamento a ser incluído da
base de dados do programa são usadas as Data Properties, que permitem atribuir às
entidades ou instancias de cada classe informações como: potência de consumo,
potência de geração, tecnologia específica, localização, etc.
91
Figura 39 - Detalhe da classe “Classificação”.
Fonte: O autor (2015).
A Figura 39 ilustra o Ontograf gerado pelo Protegé com as principais
classes da ontologia predial, os relacionamentos entre estas classes e alguns
indivíduos criados para ilustrar a forma como são relacionados ás classes.
Para fins de estudo de caso estes indivíduos foram deletados e novos
foram inseridos com a aplicação web desenvolvida.
A classe Classificação possui três subclasses que permitem atribuir
propriedades como “has_prioridade_de_uso” a um determinado equipamento,
determinando assim uma forma de axioma ou regra a ser usado pela aplicação
baseada no servidor Apache Jena que gerará as informações para a base de dados
do sistema proposto.
A Figura 40 ilustra o conjunto de “Data Properties” criado para exemplificar
quais tipos de dados específicos podem ser atribuídos aos indivíduos no modelo
ontológico proposto como exemplo neste projeto.
92
Figura 40 - Data Properties.
Fonte: O autor (2015).
A Figura 41 ilustra os “Object Properties”, que estabelece os
relacionamentos entre as classes e as propriedades a elas associadas, onde se pode
observar a definição de do tipo de propriedade, neste caso sinalizada como funcional,
o que significa que é unidirecional e que se transmite aos filhos no caso de haver subpropriedades.
Figura 41 – Object Properties.
Fonte: O autor (2015).
93
Figura 42 - Indiviuals da Ontologia.
Fonte: O autor (2015).
A Figura 42 ilustra a tela com a lista de instâncias lançadas na ontologia
para fins de exercício. Neste projeto, durante a simulação são criadas novas instâncias
através da aplicação Jena, que através da modelagem da ontologia são armazenadas
na base de dados TDB para consulta pelo sistema proposto, como está demonstrado
no item 5.1.
4.3.3
A Ontologia de Demandas
Dentro do ambiente de simulação proposto para exemplificar a aplicação
de ontologias no domínio de aplicação de sistemas de automação predial e
interoperabilidade com os sistemas elétricos de potência, particularmente com as
redes elétricas inteligentes, elaborou-se uma ontologia para representar os sistemas
prediais e suas respectivas demandas.
Visando proporcionar ao gerenciador do sistema de DR, pelo lado do
ISO/Utility, uma visualização da capacidade de resposta às requisições de redução
de demanda, dentro de um cenário sensível ao contexto, como condições ambientais,
94
status atual dos consumidores, sazonalidade, bandeiras tarifárias, preços das tarifas,
etc.
As ontologias, quando aplicadas às diversas disciplinas que compreendem
as redes elétricas, como sistemas de proteção, controle térmico, controle de
demandas, coordenação, alocação de bancos de capacitores, cada qual com um
modelo adequado ao domínio de conhecimento respectivo, podem ser conectadas por
meio de agentes ontológicos, como proposto pela Fipa (2001).
Ainda, a aplicação de arquiteturas multi-agente, como proposto por Aoki
(2003), com a funcionalidade de atualização em tempo de execução, adequando-se
ao crescimento e atualização constantes a que estão sujeitos os sistemas elétricos,
particularmente com a iminente implantação gradativa dos conceitos das redes
elétricas inteligentes, formando-se assim um Smart Grid com a aplicação dos
conceitos do Grid Networking.
A ontologia de demandas proposta é tão somente um exemplo simples de
aplicação, assim definido com objetivo de limitar o escopo do trabalho e torná-lo
exequível considerada as limitações de tempo e ambiente de simulação
disponibilizado.
O auxilia do editor de ontologias Protégé 4.3 foi elaborada uma ontologia
de demandas, cujas classes principais são apresentadas pelo Ontograh ilustrado na
Figura 43, onde podem ser encontradas as classes:
Consumidores, conjunto dos consumidores em questão;
Alimentadores, conjunto dos circuitos alimentadores da rede
elétrica;
Tipos_de_consumidores, para classificar de acordo com uso do
prédio;
Prioridade_de_cargas, que identifica entre os consumidores quais
cargas são prioritárias.
95
Figura 43 - Ontograph da Ontologia de Demandas.
Fonte: O autor (2015).
A Figura 44 ilustra as classes criadas e suas subclasses, onde observa-se
que a classe “Alimentadores” possui uma subclasse “RedeBaixa”, para permitir uma
identificação de qual rede de baixa está conectado o consumidor em questão.
Figura 44 - Classes da Ontologia de Demandas.
Fonte: O autor (2015).
96
A Figura 45 ilustra os Object Properties da ontologia de demandas, com
detalhe da propriedade has_Alimentador, associando o consumidor Hospital
Pequeno Príncipe ao Alimentador_B, como exemplo de uso desta associação.
Figura 45 - Object Properties da Ontologia de Demandas.
Fonte: O autor (2015).
Entre as Object Properties encontramos:
has_Prioridade, que associa ao consumidor uma prioridade em ser
atendimento pelo sistema elétrico;
has_TipoDeConsumidor,
que
atribui
ao
consumidor
uma
classificação quanto ao uso do local;
has_Alimentador, que associa o consumidor ao alimentador de alta
tensão que atende sua área;
has_Rede, que é uma subclasse de associação à rede de baixa
tensão ao qual o consumidor está interligado, podendo haver mais
de uma.
A Figura 46 ilustra os Data Properties da ontologia de demandas, que foram
criados como exemplo da aplicação na simulação neste projeto:
97
SistemaDeControle, campo literal para informar se o consumidor
possui recurso de controle de demanda interno;
CargaDemandada, para informar a carga total demandada pelo
consumidor em questão;
Endereço, para identificar geograficamente o cliente.
Figura 46 - Data Properties da ontologia de demandas.
Fonte: O autor (2015).
A Figura 47 apresenta a tela com uma visão geral dos indivíduos criados
como exemplo de aplicação, o reasoner Hermit rodando em background, os
relacionamentos inferidos pelo Hermit para o consumidor Hospital Pequeno Príncipe
em função das lógicas internas do reasoner.
98
Figura 47 - Tela do Editor Protégé da ontologia de demandas.
Fonte: O autor (2015).
4.3.4
Preparação do Servidor JENA
O servidor Apache versão 2.4.7 foi instalado em uma máquina com sistema
operacional Linux Ubuntu versão 14.04.2 LTS (GNU/Linux 3.13.0-53-generic x86_64),
foi instalado o Java versão 1.7.0_79, OpenJDK Runtime Envoirement (IceTea 2.5.5.)
(build 7u79-2.5.5-Oubuntu 0.14.04.2), OpenJDK 64-Bit Server VM (build 24.79-b-02,
mixed mode).
Após a instalação do JVM foi instalado o jRuby versão 1.7.20 e a gema do
Ruby on Rails versão 4.2.1, sem seguida foi instalada a gema do JENA-JRUBY na
versão 1.0.6.0, com o JENA 2.12.0 que integra as bibliotecas do Apache JENA, a
interface API para Ontologias, o TDB e o SPARQL versão 1.1.
Esta instalação segue o modelo proposto na Figura 32 (item 4.3.1).
Para fins de organizar os arquivos, referências para os arquivos TDB e
OWL e cadastro dos usuários do sistema foi utilizado um banco de dados local SQLite
versão 3.
99
A estrutura deste banco é simples e possui apenas duas tabelas,
mostradas na tabela 7:
Tabela 7 – Tabelas do banco de dados da aplicação
CAMPO
TIPO
TABELA 1 - DATASETS
DataSet_name
RDF_Source
STRING
STRING
DataSet_user_id
INTEIRO
CAMPO
TIPO
TABELA 2 - USERS
Name
Senha
STRING
STRING
E-MAIL
STRING
Fonte: O autor (2015)
O modelo do banco de dados foi gerado na ferramenta Oracle
Datamodeler, estabelecendo os campos, suas propriedades, chaves primárias de
cada tabela e as chaves estrangeiras, que estabelecem as relações entre as tabelas
do banco.
Conforme ilustra a Figura 48 é um banco simples apenas para atender às
necessidades do módulo model do Ruby on Rails.
Figura 48 - Modelo do banco de dados SQLite 3 da aplicação
Fonte: O autor (2015).
100
Ruby on Rails é um framework para a arquitetura MVC – Model View
Controller, ou MVC, bastante utilizado para aplicações Web.
A parte web da aplicação do módulo de visualização, chamado de View no
modelo MVC do Ruby on Rails foi codificada usando o HAML (HTML Abstration
Markup Language), uma linguagem de pré-processamento no servidor que gera um
código HTML com Ruby embarcado de forma mais limpa e direta, facilitando a
compreensão e manutenção do código, em substituição ao padrão erb (embbeded
HTML Ruby).
O HAML é uma gema do Ruby instalada no servidor de aplicação, de código
aberto e livre, disponível no site http://haml.info, publicado sob a licença do MIT.
O módulo de descrição de objetos, ou Model da aplicação é composto por
várias classes, está escrito em linguagem Ruby e contém as tabelas do banco de
dados do SQLite3.
O módulo Controller do modelo contém a lógica de navegação da
aplicação, utilizando as chamadas da API do JENA para disponibilizar as informações
dos datasets para o módulo View apresentar navegador do usuário.
Pode-se abstrair a forma como são tratadas as requisições dentro do
modelo MVC da plataforma Ruby on Rails no servidor JENA que suporta a aplicação
no servidor Apache que disponibiliza os serviços da aplicação desenvolvida como
prova
de
conceito
e
está
disponível
na
Internet
através
http://demanda.ddns.net.
Figura 50 - Fluxo de mensagens no modelo MVC
Fonte: O autor
da
URL:
101
A Figura 50 apresenta o fluxo de requisições e respostas que ocorrem entre
o usuário que através do browser opera a aplicação desenvolvida.
4.3.5
Autenticação do usuário na aplicação
Para a autenticação do usuário no servidor de aplicação web foram
empregadas normas consolidadas pelo padrão PKCS #5 v2.0, assim como pela
especificação do IETF publicada na RFC2898, através das bibliotecas do módulo
OpenSSL, utilizando o método PKCS5::pbkdf2_hmac_sha1( password, salt,
iterations, key_length).
Este método de autenticação utiliza uma solução de proteção de senha
(Password Hashing) de alta confiabilidade e desempenho, chamado de PBKDF2, que
realiza 1000 (mil) iterações de criptografia na senha definida pelo usuário adicionada
a um Salt (valor aleatório de 32bits utilizando método de codificação Base64),
produzindo um Hash de 32bits, que por sua vez é novamente codificado usando o
método Base64, e é por fim armazenado no banco de dados.
A aplicação está disponível em um servidor Apache de uso particular e com
endereçamento de IP dinâmico empregando o site de Dynamic Domain Name Server
-DDNS gratuito dynddns.net, com a seguinte URL: http://demanda.ddns.net.
4.3.6
Página de inserção de dados
A página de inserção de dados é uma das principais, pois permite que os
usuários realizem o cadastro do sistema BMS, dos recursos energéticos, das cargas,
defina as propriedades e quantifique estes recursos.
Neste cadastro é possível definir então os parâmetros que serão utilizados
pelos reasoners na análise dos dados armazenados na TDB.
A inserção de indivíduos é um dos objetivos principais da aplicação, pois
permite ao usuário, com base no modelo ontológico importado, e com o qual criou o
dataset, popular sua base de dados com informações específicas da sua instalação
ou site.
102
O usuário cria um indivíduo que represente seu sistema predial, inserindo
neste indivíduo dados como de localização e outras características, e em seguida
poderá inserir os recursos energéticos associados ao seu site, como cargas ou
geração distribuída.
Clicando sobre o botão “Adicionar Indivíduo” o usuário acessa a tela de
inserção de dados com base no modelo ontológico importado. Este é o local onde o
usuário ou operador do sistema BMS do site a ser cadastrado deverá inserir os dados
do site, bem como os recursos energéticos como cargas e fontes de geração local.
Nesta parte da aplicação foram empregados recursos de página dinâmica
como jquery e ajax, que permitem ao usuário criar um formulário on-line de acordo
com a sua necessidade específica de inserção de dados.
O usuário insere um nome para o novo indivíduo, escolhe a classe à qual
será associado e em seguida uma propriedade de dados ou de objeto que deseja
adicionar, e então pode acrescentar mais propriedades de dados ou objetos, conforme
seja preciso para representar da melhor forma o indivíduo dentro do domínio de
conhecimento modelado pela ontologia
4.3.7
Conceito de Resposta à Demanda Provável
Neste estudo de caso, objetivando demonstrar as aplicações possível da
metodologia na capacidade de avaliação da resposta à demanda dos sistemas
prediais a um determinado programa DSM, foi definido um modelo de cálculo
conforme a equação (1):
��� =
�� .��
��
Eq. (1)
Onde:
RDP = Resposta à Demanda Provável (VA)
Pa = Potência Total Aparente do Recurso (VA)
Fd = Fator de demanda do recurso (0 a 1,0)
Pu = Prioridade de uso do recurso considerado para o sistema predial em questão (1
a 10, onde 10 representa uma prioridade maior de uso)
103
Esta equação indica que a capacidade de redução de consumo de um
determinado recurso é diretamente proporcional à sua potência demandada e
inversamente proporcional à sua prioridade de uso.
Assim, um recurso essencial, como um sistema de transporte por elevadores
ao qual é atribuído uma prioridade de uso 10 significa que apenas 1/10 da sua
potência total poderá ser considerada como resposta à demanda, enquanto que um
recurso como iluminação decorativa ao qual seja atribuída uma prioridade de uso 1,
100% desta demanda poderá ser considerada como resposta à demanda, ou seja,
este recurso pode ser desligado sem prejuízo à operação do sistema predial.
Estas propriedades podem ser atribuídas a cada recurso de forma individual
pelo administrador do sistema predial, bem como um horário previsto para entrada em
operação e uma duração de uso do recurso, resultando assim em uma curva de carga
típica de uso do recurso, conforme ilustra a Figura 51 sobre o recurso Ar Condicionado
Potência (W)
Central, pertencente ao sistema predial Prédio_4.
Horário
Figura 51 - Curva de Demanda Ar Condicionado no Prédio_4.
Fonte: O autor (2015).
104
4.4
CONSIDERAÇÕES FINAIS DO CAPÍTULO
Neste capítulo foram apresentados todos os recursos necessários e a
metodologia aplicada na simulação do caso proposto, com objetivo de situar o
ambiente de desenvolvimento.
Foram apresentados os recursos disponibilizados pelo servidor JENA
através de sua API como a linguagem de consulta SPARQL, o conceito de banco de
dados trivial (TDB) foi explanado, bem como seu uso neste trabalho.
O ambiente de simulação proposto foi detalhado e os modelos ontológicos
foram criados com o auxílio do editor de ontologias Protégé e importados para a
aplicação, sendo gerado o banco de dados em formato TDB, que reúne os modelos.
O modelo do banco de dados SQL da aplicação, para suportar a parte de
autenticação e acesso de usuários aos datasets foi apresentado.
O conceito de RDP foi apresentado como um dos elementos do modelo
para permitir demonstrar, dentro do estudo de caso proposto, a capacidade de
estimação da capacidade de resposta à demanda de acordo com o perfil das cargas
nos sistemas prediais modelados.
No Anexo 1 são apresentados com maiores detalhes o editor de ontologias
Protégé e a linguagem SPARQL, empregadas no desenvolvimento dos modelos.
No apêndice A são apresentadas as diversas funcionalidades da aplicação
e as telas, mostrando passo a passo as tarefas realizadas de inclusão de indivíduos,
edição de dados, geração de consultas, entre outras.
105
5
ESTUDO DE CASO
Para fins de avaliação do conceito proposto de utilização de Ontologias
na modelagem de sistemas elétricos de automação predial e seu emprego no contexto
do padrão de comunicação openADR, foi desenvolvida uma aplicação com acesso via
web que permite ao usuário o acesso às seguintes funcionalidades básicas de:
a) Carregar uma ontologia em formato .owl no servidor (upload);
b) Criar o dataset ou base de dados do modelo ontológico carregado em
um banco de dados padrão TDB em formato RDF/OWL;
c) Realizar consultas SPARQL sobre esta base de dados em formato
RDF;
d) Inserir novos dados (indivíduos na ontologia) na base TDB através de
declarações de triplas por meio de um formulário de inserção de
dados;
e) Rodar um reasoner sobre os dados no TDB
f) Estatísticas e curvas de cargas
O modelo proposto para os alimentadores limita-se a descrever as
características de carregamento, demanda, perfil das cargas, uma vez que objetiva,
neste momento, apresentar informações relativas ao DSM e a correspondente
capacidade de resposta dos sistemas prediais, operando em conjunto com o
openADR.
A
metodologia
em
análise
propõe-se
a
disponibilizar
aos
comercializadores de negawatts (energia não consumida ou watts negativos) e/ou
energia elétrica a partir de fontes intermitentes uma visão mais clara sobre o perfil dos
consumidores e sua capacidade estimada de aderência e participação nos programas
de DSM, inserindo-se no contexto da geração distribuída através do DER, o que ainda
não é possível ser aplicado no padrão atual de openADR (openADR 2.0).
A Figura 52 ilustra o diagrama do sistema elétrico modelado neste estudo
de caso, indicando onde a metodologia proposta se aplica, particularmente na
obtenção de informações sobre natureza das cargas, perfil dos consumidores e
associando-as aos alimentadores. Desta forma é possível aos administradores dos
106
sistemas BMS contribuir com os administradores dos programas DSM otimizando os
resultados da sua participação nestes programas.
Figura 52 - Diagrama do sistema modelado
Fonte: O autor (2015)
O diagrama apresenta os alimentadores criados na modelagem, com seus
respectivos sistemas prediais. Para cada sistema predial foram criados recursos ou
cargas, que representam os diversos sistemas elétricos prediais, como sistema de
iluminação, bombas de drenagem, bombas de incêndio, sistema de Ar Condicionado,
sistemas de elevadores.
Estes sistemas são modelados usando a metodologia proposta, criados
como indivíduos no modelo ontológico, dentro do TDB da aplicação web, permitindo
que as informações de perfil das cargas e estatísticas sejam obtidas a partir do
modelo.
107
A comunicação entre o sistema predial e o servidor de aplicação utiliza a
internet e webservices, de forma semelhante, porém independentemente do modelo
de comunicação openADR, representando na Figura como servidor VTN e como
cliente VEM.
Os DER são também modelados, com inserção de indivíduos com o perfil
de geração distribuída, a partir dos sistemas prediais, e com reflexo sobre os
alimentadores, neste caso apenas para estimação da resposta provável à demanda.
5.1
DADOS INSERIDOS PARA O ESTUDO DE CASO
Com o objetivo de exemplificar a aplicação da metodologia proposta, foram
inseridos na base de dados TDB 38 indivíduos, entre alimentadores, sistemas prediais
e recursos.
Os indivíduos denominados “Sistemas Prediais” e seus respectivos
recursos, sejam cargas, equipamentos ou geração distribuída, são inseridos no
sistema pelo respectivo gerente ou administrador do sistema predial, através da
aplicação web, tendo acesso apenas ao seu sistema predial e seus recursos.
Os alimentadores e demais indivíduos que representam o sistema elétrico
pelo lado da distribuição são inseridos e acessados pelo lado da Utility (concessionária
ou distribuidora de energia), sendo possível visualizar as informações referentes aos
seus alimentadores.
Os alimentadores inseridos foram:
Alimentador_1
Alimentador_2
Alimentador_Subestação
Os sistemas prediais inseridos foram:
a) Prédio_1, com os recursos:
Bombas2 – Sistema de bombas
UPS de Emergência – Unidade de Nobreak (DER)
AR_VRF – Ar Condicionado tipo VRF
Elevadores – Sistema de Transporte
Ventiladores de Pressurização
Elevadores de Emergência
108
Sistema de Iluminação 4
Gerador
b) Prédio_2, com os recursos:
Aquecimento Elétrico de ambientes
Bombas de Drenagem 1
Elevadores Sociais 1
Ventilação 1
c) Prédio_3, com os recursos:
Sistema de Iluminação 3
Ar Condicionado Central
Luzes Decorativas Fachada
Máquinas
d) Prédio_4, com os recursos:
Equipamentos de Produção
Sistemas de Combate a incêndio
Painel Solar (DER)
Iluminação Geral
e) Shopping_Center, com os recursos:
Gerador Cummins (DER)
Sistema de Ar Condicionado CAG (Central de Água Gelada)
Iluminação Geral do Shopping
Lojas
f) Hospital_1, com os recursos:
Gerador Emerson (DER)
Iluminação Geral Hospital
Equipamentos Elétricos
Equipamentos Médicos
Gerador de Emergência
Ar Condicionado e Ventilação hospitalar
109
5.2
ANÁLISE DE DADOS DOS ALIMENTADORES
A aplicação, com base no modelo ontológico, dos dados armazenados no
TDB disponibiliza as seguintes informações sobre os sistemas prediais que cada
alimentador possui a si associado.
Estatísticas da RDP são apresentadas sob a forma de gráficos de pizza, na
qual é apresentada a RDP em relação à demanda total sobre o alimentador, a Figura
53 ilustra o caso do Alimentador_1, calculada considerando todas os sistemas prediais
que alimenta de acordo com a equação 1.A.
Figura 53 - Gráfico da RDP Alimentador_1
Fonte: O Autor (2015)
As estatísticas dos DER são apresentadas em gráficos de pizza mostrando
a disponibilidade total de Recursos Energéticos Distribuídos (DER) em relação à
potência total demandada pelos sistemas prediais associados ao alimentador, a
Figura 54 ilustra o caso do Alimentador_1:
110
Figura 54 - Gráfico do DER Alimentador_1
Fonte: O autor (2015)
Estatísticas da participação dos recursos na demanda total indicam as
participações dos sistemas prediais na demanda total sobre o alimentador, a Figura
55 ilustra o caso do Alimentador_1;
Figura 55 - Gráfico da participação dos recursos na demanda do Alimentador_1
Fonte: O autor (2015)
A Curva de Carga Demanda Total indica o carregamento total da soma das
demandas de todos os sistemas prediais associados ao alimentador em uma curva
de carga diária estimada em função dos horários previstos de entrada em operação e
duração de uso de cada recurso e dos DER disponíveis, a Figura 56 ilustra o caso do
Alimentador_1:
Potência (W)
111
Horário
Figura 56 - Demanda total no Alimentador_1
Fonte: O Autor (2015)
Curva de Carga das demandas individuais por prédio em modo de gráfico
multisérie apresenta a participação de cada sistema predial no carregamento total do
alimentador em relação às demandas individuais de cada um, a Figura 57 ilustra o
Potência (W)
caso do Alimentador_1:
Horário
Figura 57 - Demandas individuais dos recursos sobre o Alimentador_1
Fonte: O autor (2015)
A Curva de Carga Resposta à Demanda provável (RDP) indica a
capacidade total esperada de resposta à demanda dos sistemas prediais do
alimentador em resposta à um determinado programa DSM, de acordo com o perfil de
112
consumo de cada recurso associado aos sistemas, a Figura 58 ilustra o caso do
Potência (W)
Alimentador_1:
Horário
Figura 58 - Curva da RDP no Alimentador_1
Fonte: O autor (2015)
A Curva de Cargas da Potência Ativa Total apresenta o carregamento do
alimentador computadas as potências ativas associadas aos recursos dos sistemas
prediais, apenas os recursos consumidores.
A Curva de Cargas da Potência Reativa Total apresenta o carregamento
total em termos de potências reativas associadas aos recursos dos sistemas prediais,
apenas os recursos consumidores de energia.
5.3
ANÁLISE DE DADOS DOS SISTEMAS PREDIAIS (CONSUMIDORES)
Um dos principais objetivos do trabalho é permitir a modelagem de
sistemas prediais com emprego de ontologias, disponibilizando aos usuários
informações gerenciais de acordo com o modelo desenvolvido.
Não existe uma rigidez no modelo, é possível alterar o modelo desenvolvido
e criar novas propriedades aos dados, sem a necessidade de remodelagem da base
de dados, o que permite uma grande dinâmica na metodologia proposta.
113
No estudo de caso proposto, visando exemplificar a aplicabilidade da
metodologia em sistemas prediais, foram criadas diversas classes que representam
os tipos de cargas, suas tecnologias, propriedades destes objetos e dados associados
aos recursos.
No sentido de gerar informações úteis para a aplicação desenvolvida foram
criadas as seguintes propriedades associadas a cada recurso:
a) Potência aparente (VA);
b) Potência ativa (W);
c) Potência reativa (VAr);
d) Prioridade de uso (para cargas, variando de 1 a 10);
e) Prioridade de geração (para DER, variando de 1 a 10);
f) Fator de potência (0 a 1,0);
g) Fator de demanda (0 a 1,0);
h) Entrada em operação (horário específico hh:mm);
i) Duração da operação (em horas hh:mm);
Estas propriedades permitem à aplicação calcular e disponibilizar aos usuários
as seguintes informações:
a) Potência demandada (VA);
b) Resposta à Demanda Provável (VA) e de acordo com a equação (1);
c) Estatísticas;
d) Curvas de cargas;
A Figura 59 ilustra os detalhes de um indivíduo, onde são apresentados os dados
calculados (informações derivadas) a partir das propriedades associadas ao recurso.
Figura 59 - Detalhe dos dados do recurso
Fonte: O autor (2015)
A aplicação, com base nas informações derivadas obtidas a partir do
modelo, as quais estão associadas a cada recurso, gera informações gerencias que
114
permitem uma análise do perfil de uso das cargas, bem como a capacidade de cada
sistema de responder à uma determinada estratégia de resposta à demanda, de
acordo com a natureza das cargas e geração distribuída (recursos) associados ao
sistema predial.
A Figura 60 ilustra as estatísticas do sistema predial Shopping Center, da
qual podemos obter as seguintes informações, por inspeção nos gráficos:
a) Da carga total do sistema predial, existe capacidade de resposta à
demanda provável de 15,5%;
b) Podemos esperar uma capacidade de disponibilidade de DER de 7,3%
através de um sistema gerador;
c) O sistema possui 3 sistemas principais onde o sistema de Ar
Condicionado CAG participa com 51,7% da demanda, as lojas
participam com 29,1% da demanda e o sistema de iluminação com
19,2% da demanda total.
115
Figura 60 - Gráficos estatísticos do Shopping_Center
Fonte: O autor (2015)
Para o sistema Predial_2, A curva de carga que representa o perfil de
consumo é ilustrada na Figura 61, sendo estes dados abstraídos em função das
propriedades associadas a cada recurso, como potência aparente, horário de entrada
em funcionamento e tempo de operação. O período de maior consumo situa-se entre
as 07:00 e 22:00h, o que coincide com o período normal de operação de um prédio
com natureza comercial como um Shopping Center.
Potência (W)
116
Horário
Figura 61 - Demanda do Prédio_2
Fonte: O autor (2015)
A RDP para o sistema predial Prédio_2 é ilustrado na Figura 62, indicando
qual a capacidade provável de redução de cargas com indicação por meio de códigos
de cores da participação de cada recurso (sistema) nesta RDP.
Assim, é possível ao administrador do DSM uma visão mais detalhada do
perfil de consumo de cada sistema predial participante do programa de DSM e qual
Potência (W)
sua capacidade de resposta à demanda esperada.
Horário
Figura 62 - Demandas dos recursos do sistema predial Prédio_2
Fonte: O autor (2015)
117
6
CONCLUSÕES
A modelagem de sistemas elétricos prediais bem como dos sistemas de
distribuição de energia empregando ontologias mostra-se vantajoso em relação aos
métodos tradicionais de modelagem de dados, principalmente pela possibilidade de
alteração do modelo empregado sem implicar em necessidade de alteração da
estrutura da base de dados em uso.
Enquanto que, no desenvolvimento empregando o paradigma da
modelagem com base na orientação à objetos, a cada modelo criado é preciso
adequar a estrutura dos dados que compõem a base de dados, ou dataset, obrigando
assim aos desenvolvedores, além do retrabalho nos códigos de programação dos
algoritmos nas aplicações, realizar paradas no sistema de base de dados, com
consequente impacto sobre a operação dos sistemas elétricos, o mesmo não ocorre
na modelagem empregando ontologias.
Um sistema elétrico pode assim ser inicialmente modelado em um nível
básico e abrangendo uma parte restrita e definida do sistema, sendo gradativamente
ampliado em abrangência ou complexidade sem precisar parar a base de dados da
aplicação, mesmo que sejam adicionadas novas propriedades aos dados, novas
classes de objetos, ou mesmo alterado o código da aplicação.
A modelagem por ontologias proposta na metodologia apresentada neste
projeto de pesquisa agrega outras vantagens, como importação de outras ontologias
existentes ao modelo, importação de dados de outras ontologias na Internet,
possibilidade uso de recursos disponíveis, integração com o protocolo openADR e
sistemas BMS via webservices.
A aplicação da metodologia de modelagem de sistemas elétricos prediais
permitiu, através de informações derivadas do modelo e calculadas pelos algoritmos
da aplicação exemplo abstrair informações gerencias de análise do perfil e
comportamento dos recursos de cada sistema predial e o efeito destas cargas e DER
sobre os alimentadores.
Em relação aos objetivos propostos, o trabalho apresentado demonstra que
foram realizados os levantamentos das tecnologias atualmente aplicadas nos
sistemas de automação predial, bem como as técnicas de modelagem em uso e as
estratégias de controle de demanda, foram apresentados os conceituados das redes
118
elétricas inteligentes e os diversos tipos de protocolos em desenvolvimento,
particularmente o OpenADR, atualmente na versão 2.0, como um padrão adotado pela
OASIS e que vem se tornando um padrão adotado comercialmente nos produtos das
empresas fabricantes de sistemas supervisórios para BMS como a Siemens,
Honeywell, Autogrid, Alston, entre outros, o que pode ser verificado em consulta ao
site www.openadr.org.
Dentro do estudo da engenharia de domínios foram apresentadas as
técnicas de modelagem da informação e os conceitos e usos das inferências lógicas
através da Lógica Descritiva de Primeira Ordem (FOL), representação dos dados no
formato RDF e a semântica web que predomina como forma de comunicação entre
sistemas na rede mundial de computadores.
Finalmente, foi elaborado um modelo de um sistema predial exemplo
empregando o Framework Protegé e desenvolvida uma aplicação exemplo com base
em um servidor Apache e API Jena para criação de uma base de dados TDB para uso
em uma aplicação web desenvolvida em jRuby on Rails.
A aplicação está disponível na internet para avaliação e testes no endereço
http://demanda.ddns.net.
Os modelos ontológicos desenvolvidos podem ser baixados diretamente da
aplicação no servidor no endereço acima. O código fonte da aplicação e os testes de
alteração
de
modelo
podem
ser
obtidos
no
endereço
https://www.dropbox.com/sh/w9havaf0ml93y5o/AABEEU2v6Sdab2FBQVgk2Qgya?dl
=0
O advento da Internet Industrial e o recente surgimento do conceito da
Internet das Coisas (IoT) remetem à importância do grid network como plataforma
padrão de comunicação entre sistemas, disponibilizando uma infraestrutura extensa,
que com as ferramentas adequadas de controle e segurança propiciam os meios para
aplicação dos conceitos abordados no presente trabalho.
6.1
TRABALHOS FUTUROS
O escopo do trabalho foi limitado em função do tempo disponível para o
projeto, podendo ser ampliado para aplicações mais complexas como uso de
reasoners Fuzzy que podem inferir sobre os dados (com certo grau de incerteza) da
119
base e disponibilizar por exemplo os K-recursos mais prioritários em um determinado
sistema predial.
As aplicações possíveis para a metodologia de modelagem empregando
ontologias associadas às tecnologias disponíveis de comunicação, troca de dados,
interoperabilidade de sistemas através da Internet são vastas, entre as quais podemos
citar a modelagem das redes elétricas inteligentes com uso de recursos como
MATHML que permite realizar cálculos na internet, como pode ser verificado em
www.w3.org/math.
A comunicação entre o protocolo openADR e a aplicação desenvolvida
empregando webservices permitirá uma atualização automática das informações em
tempo real da capacidade de resposta à demanda, tornando os programas de DSM
mais fácies de gerenciar.
Uma ontologia de modelagem deste cenário para gerenciamento pelo lado
da demanda não apenas baseado em valores tarifários, mas também considerando
fatores diversos, inclusive as questões da frequência da rede, como proposto por
Schäfer et al. (2015), onde através de bases de conhecimento locais torna-se possível
aplicar modelos e algoritmos descentralizados de gerenciamento da resposta à
demanda.
Tal metodologia poderia ser aplicada, por exemplo, como uma abordagem
alternativa ao trabalho desenvolvido por Prestes (2013), quando da modelagem
elétrica equivalente para o sistema industrial, sem prejuízo do uso de algoritmos
genéticos, que foi a ferramenta de otimização empregada pelo autor. Pode-se citar
ainda sua aplicação na modelagem dos sistemas de automação residencial citados
por Souza (2014), em seu trabalho de avaliação da eficiência energética de
equipamentos e seu impacto nas redes elétricas de distribuição através de
multiagentes e técnicas heurísticas.
Aplicação da modelagem de conhecimento aplicado à análise de fluxo de
potência em redes elétricas de transmissão e distribuição, funcionalidades de
Distribution Management System - DMS, tais como self-healing, controle Volt/Var e
DSM, que podem executar on-line, sendo estes trabalhos atualmente de interesse dos
autores deste trabalho.
120
REFERÊNCIAS
ABNT. ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. Disponível em:
<www.abnt.org.br>. Acesso em: 20/2/2015.
AMIN, M.; WOLLENBERG, B. F. Toward a Smart Grid. Power, , n. october, p. 34–
41, 2005.
ANEEL. AGÊNCIA NACIONAL DE ENERGIA ELÉTRICA. Disponível em:
<www.aneel.gov.br>. .
AOKI, A. R. Uma Proposta de Arquitetura Multi-Agente para Operação de
Sistemas Elétricos, 2003. Universidade Federal de Itajubá.
APACHE, J. No Title. Disponível em: <https://jena.apache.org>. .
BOGEN, C.; PH, D.; CHIPMAN, T.; et al. Building Automation and Modeling
Information Exchange ( BAMie ). , v. 2012, n. c, p. 1–14, 2012.
BUSHBY, B. S. T. Information Model Standard for Integrating Faciiities with Smart
Grid. ASHRAE Journal, , n. November, p. B18–B22, 2011.
CAMARGO, C. A. Modelagem de Baterias em Sistemas de acumulação de
energia para deslocamento de cargas, 2014. LACTEC.
CAMPOS, A. DE. Gerenciamento Pelo Lado da Demanda : Um Estudo de Caso,
2004.
CARDOSO, J. Semantic web services. 1.Ed ed. Hershey: Information Science
Reference, 2007.
CLARK W. GELLINGS, J. H. C. Demand-side management: concepts and
methods. 1o Ed. ed.Michigan: Fairmond Press, 1988.
COLOMB, R. M. Ontology and the Semantic Web. IOS Press, 2007.
CONSIDINE, T.; EHRLICH, P. oBIX 1.0. 2006.
CONSORTIUM, W. W. W. No Title. Disponível em: <www.w3c.org>. .
CRUZ, R. R. DE A. GERENCIAMENTO DE ENERGIA ELÉTRICA PARA OTIMIZAR
A QUALIDADE E JOÃO PESSOA - PB, 2014. Universidade Federal da Paraíba.
EAST, W. Construction Operation Building Information Exchange (COBIE).
2009.
121
EGGEA, R. F. Gerenciamento de Energia incluindo painel fotovoltaico e
armazenamento de energia para redes elétricas inteligentes via aplicativo
celular, 2014. LACTEC.
EKANAYAKE, J.; LIYANAGE, K.; WU, J.; YOKOYAMA, A.; JENKINS, N. Smart Grid
Technology and Applications. 2012.
EPE. Plano Nacional De Energia 2030. , 2007. Disponível em:
<http://www.epe.gov.br/PNE/20080111_1.pdf>. .
EPE. Empresa de Planejamento Energético. Disponível em: <www.epe.gov.br>.
Acesso em: 2/3/2015a.
EPE. Empresa de Planejamento Energético. .
FERNANDES, U. B.; BISPO, D.; HENRIQUE, J.; FERRAZ, S. Controle de Demanda
de Energia de um Sistema Elétrico. In: Universidade Federal de Uberlândia. (Org.);
IX CEEL. Anais... . p.5, 2011. Uberlândia.
FIPA. FIPA ACL Ontology Service Specification. , p. 58, 2001. Disponível em:
<www.fipa.org>. .
FISHER, B. D. How BACnet ® is Changing Building Automation Networking. , v. 8, n.
2, p. 1–4, 2007.
GELLINGS, C. The Smart Grid: Enabling Energy Efficiency and Demand
Response. 2009.
GOMES, A. DA S. Instalação e Integração de Sistema de Microgeração com
Fontes Renováveis para Redes Elétricas Inteligentes, 2014. LACTEC.
GRUBER, T. Toward principles for the design of ontologies used for knowledge
sharing. International Journal of Human-Computer Studies, v. 43, p. 907–928,
1995. Disponível em: <http://dx.doi.org/10.1006/ijhc.1995.1081>. .
GUIZZARDI, G. FOUNDATIONS FOR STRUCTURAL CONCEPTUAL, 2005.
GUIZZARDI, G.; ALMEIDA, J. P. A.; GUIZZARDI, R. S. S.; FALBO, R. Ontologias de
Fundamentação e Modelagem Conceitual. II Seminário de pesquisa em Ontologia
do Brasil, , n. i, p. 1–6, 2009. Disponível em:
<http://nemo.inf.ufes.br/files/ontologias_de_fundamentacao_e_modelagem_conceitu
al_2009.pdf>. .
HAN, J.; PIETTE, M. A.; KILICCOTE, S. Field Test Results of Automated Demand
Response in a Large Office Building. , , n. December, 2008.
HOLMBERG, D. G.; KOCH, E. L.; BOCH, J. OpenADR Advances. , , n. 11, 2012.
IEA. World Energy Outlook 2012. Paris., 2012.
122
JOS DE BRUIJN, DIETER FENSEL, MICK KERRIGAN, UWE KELLER, HOLGER
LAUSEN, J. S. Modeling Semantic Web Services. 2008.
KASTNER, W.; NEUGSCHWANDTNER, G.; SOUCEK, S.; NEWMANN, H. M.
Communication Systems for Building Automation and Control. Proceedings of the
IEEE, v. 93, n. 6, 2005.
KILICCOTE, S.; PIETTE, M. A.; NATIONAL, L. B. Installation and Commissioning
Automated Demand Response Systems. , 2008.
KNUBLAUCH, H.; OBERLE, D.; TETLOW, P.; et al. No Title. Disponível em:
<http://www.w3.org/2001/sw/BestPractices/SE/ODSD/20060117/>. Acesso em:
15/2/2015.
KOCH, E.; PIETTE, M. A.; KOCH, E.; PIETTE, M. A. Architecture Concepts and
Technical Issues for an Open , Interoperable Automated Demand Response
Infrastructure. , , n. October, 2007.
LEVY, B. N. Influência de Programas de Resposta da Demanda na Rede de
Distribuição, 2013. UFRJ.
LISI, F. A.; STRACCIA, U. A logic-based computational method for the automated
induction of fuzzy ontology axioms. Fundamenta Informaticae, v. 124, p. 503–519,
2013.
MAC, D.; FARIA, C. DE. O Impacto das Redes Elétricas Inteligentes no Nível
Tarifário das Distribuidoras de Energia Brasileiras O Impacto das Redes Elétricas
Inteligentes no Nível Tarifário das Distribuidoras de Energia Brasileiras. , 2012.
MCPARLAND, C. OpenADR Open Source Toolkit : Developing Open Source
Software for the Smart Grid. , 2011.
MOGHADDAN, M. F. Evaluating Intelligence in Intelligent Buildings Case Study
in Turkey, 2012. Middle East Technical University.
MORAIS, E. A. M.; AMBRÓSIO, A. P. L. Ontologias: conceitos, usos, tipos,
metodologias, ferramentas e linguagens. , p. 21, 2007.
MOTEGI, N.; PIETTE, M. A.; WATSON, D. S.; KILICCOTE, S.; XU, P. Introduction to
Commercial Building Control Strategies and Techniques for Demand Response. , , n.
May, 2007.
MOURINHO, J. M. S. PROJETO DE INSTALAÇÕES ELÉTRICAS: ESTUDO
COMPARATIVO ENTRE UMA SOLUÇÃO TRADICIONAL COM UMA SOLUÇÃO
ENERGETICAMENTE EFICIENTE, 2014. Universidade do Porto.
NIBS - National Institute of Building Sciences. .Disponível em: <www.nibs.org>.
Acesso em: 25/1/2015.
123
NOY, N.; MCGUINNESS, D. Ontology development 101: A guide to creating your
first ontology. Development, v. 32, p. 1–25, 2001. Disponível em:
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.136.5085&rep=rep1
&type=pdf\nhttp://liris.cnrs.fr/alain.mille/enseignements/Ecole_Centrale/What is
an ontology and why we need it.htm>. .
PRESTES, S. S. Metodologia para Projeto e Alocação de Filtros em Instalações
Industriais, 2013. Institutos LACTEC.
protege.standford.edu. .Disponível em: <protege.standford.edu>. Acesso em:
1/1/2014.
Protocolo Internacional de Medição e Verificação De Performance Protocolo
Internacional de Medição e Verificação De Performance. ., v. 1, 2011.
SABOL, L. Building Information Modeling & Facility Management. 2008.
SALAS, M. I. Metodologia de testes de segurança para análise de robustez de
web services por injeção de falhas, 2012.
SCHÄFER, B.; MATTHIAE, M.; TIMME, M.; WITTHAUT, D. Decentral Smart Grid
Control. New Journal of Physics, v. 17, n. 1, p. 15002, 2015. IOP Publishing.
Disponível em: <http://dx.doi.org/10.1088/1367-2630/17/1/015002>. .
SINOPOLI, J.; PRINCIPAL, M.; BUILDINGS, S. Modeling Building Automation and
Control Systems. , p. 1–5, 2013.
SOUZA, R. L. A. ANÁLISE DE EFICIÊNCIA ENERGÉTICA EM SISTEMAS
PREDIAIS DO TIPO RESIDENCIAL E SEUS IMPACTOS NA REDE DE
DISTRIBUIÇÃO MEDIANTE FERRAMENTA DE SIMULAÇÃO MULTIAGENTE,
2014. Instiitutos LACTEC.
SOUZA, V. A. S. M. Uma Arquitetura Orientada a Serviços para
Desenvolvimento, Gerenciamento e Instalação de Serviços de Rede Uma
Arquitetura Orientada a Serviços para Desenvolvimento, Gerenciamento e
Instalação de Serviços de Rede, 2006.
SUGARMAN, S. C. HVAC Fundamentals. 2o Edição ed.The Fairmont Press, Inc.,
2001.
TRAVOSTINO, F. Grid Networks Enabling Grids with. .
WANG, S. Smart Buildig and Building Automation. 1o Edição ed.2 Park Square,
Milton Park,Abingdon, OXON: Spon Press, 2010.
WIEDEMANN, T. SIMCOP: UM FRAMEWORK PARA ANÁLISE DE
SIMILARIDADES EM SEQUENCIAS DE CONTEXTO, 2014. UNISINOS.
124
WIKI. Protégé Wiki. Disponível em:
<http://protegewiki.stanford.edu/wiki/WebProtege>. Acesso em: 1/1/2015.
125
APÊNDICE A – APLICAÇÃO WEB DEMANDAS
1.1
Autenticação do usuário na aplicação
Para a autenticação do usuário no servidor de aplicação web foram
empregadas normas consolidadas pelo padrão PKCS #5 v2.0, assim como pela
especificação do IETF publicada na RFC2898, através das bibliotecas do módulo
OpenSSL, utilizando o método PKCS5::pbkdf2_hmac_sha1( password, salt,
iterations, key_length).
Este método de autenticação utiliza uma solução de proteção de senha
(Password Hashing) de alta confiabilidade e desempenho, chamado de PBKDF2, que
realiza 1000 (mil) iterações de criptografia na senha definida pelo usuário adicionada
a um Salt (valor aleatório de 32bits utilizando método de codificação Base64),
produzindo um Hash de 32bits, que por sua vez é novamente codificado usando o
método Base64, e é por fim armazenado no banco de dados.
A aplicação está disponível em um servidor Apache de uso particular e com
endereçamento de IP dinâmico empregando o site de Dynamic Domain Name Server
-DDNS gratuito dynddns.net, com a seguinte URL: http://demanda.ddns.net.
A página inicial de login para entrar na aplicação é mostrada na Figura A1.
126
Figura A1 - Página inicial da aplicação.
Fonte: O autor (2015).
1.2
Página de usuário
Nesta página é possível ao usuário escolher em um menu de opções se
deseja carregar um novo dataset, editar um dataset existente, realizar consultas,
inserir dados ou sair da aplicação, conforme Figura A2.
O usuário administrador possui a funcionalidade de cadastrar usuários e
definir um namespace para o usuário.
Figura A2 - Tela de manutenção de usuários
Fonte: O autor (2015).
127
1.3
Página de edição de datasets
Nesta página no usuário poderá realizar as operações carregar um arquivo
de modelo ontológico em formato .owl (upload), poderá ainda de um novo dataset com
este modelo, destruir em dataset existente, ver detalhes de um dataset existente. O
usuário pode definir quais outros usuários podem acessar seu namespace entre os
usuários cadastrados no site, conforme ilustrado na Figura A3.
Figura A3 - Tela de manutenção das ontologias
Fonte: O autor (2015).
Após carregar o arquivo da ontologia, em formato .owl o usuário pode criar
o dataset ou base de dados TDB clicando em “Criar Dataset”, desta forma
através da API do JENA e usando o método Jena::TDB::TDBFactory, após
a criação do dataset no TDB a lista destes RDF Triple Stores são listados
como mostra a Figura A4.
Figura A4 - Tela de lista de Datasets.
Fonte: O autor (2015)
128
1.4
Página de consultas à base de dados TDB
Nesta página o usuário poderá realizar consultas livres ou através de
templates de consultas previamente programadas. O usuário poderá criar templates
de consulta personalizados no seu namespace, conforme mostra a Figura A5.
Figura A5 Tela de consulta livre SPARQL
Fonte: O autor (2015).
1.5
Página de inserção de dados na base
A página de inserção de dados é uma das principais, pois permite que os
usuários realizem o cadastro do sistema BMS, dos recursos energéticos, das cargas,
defina as propriedades e quantifique estes recursos.
Neste cadastro é possível definir então os parâmetros que serão utilizados
pelos reasoners na análise dos dados armazenados na TDB.
A Figura A6 ilustra a tela desta página no servidor da aplicação, mostrando
o nome do Dataset, o arquivo original da ontologia, a contagem de triplas do TDB e a
contagem de triplas no modelo RDF/OWL original.
O usuário pode executar um download do arquivo da ontologia para sua
máquina caso deseje realizar alguma alteração no modelo através do Protégé.
Figura A6 - Tela com detalhes do Dataset
Fonte: O autor (2015).
129
A inserção de indivíduos é um dos objetivos principais da aplicação, pois
permite ao usuário, com base no modelo ontológico importado, e com o qual criou o
dataset, popular sua base de dados com informações específicas da sua instalação
ou site.
O usuário cria um indivíduo que represente seu sistema predial, inserindo
neste indivíduo dados como de localização e outras características, e em seguida
poderá inserir os recursos energéticos associados ao seu site, como cargas ou
geração distribuída.
Clicando sobre o botão “Adicionar Indivíduo” o usuário acessa a tela de
inserção de dados com base no modelo ontológico importado. Este é o local onde o
usuário ou operador do sistema BMS do site a ser cadastrado deverá inserir os dados
do site, bem como os recursos energéticos como cargas e fontes de geração local.
Nesta parte da aplicação foram empregados recursos de página dinâmica
como jquery e ajax, que permitem ao usuário criar um formulário on-line de acordo
com a sua necessidade específica de inserção de dados.
O usuário insere um nome para o novo indivíduo, escolhe a classe à qual
será associado e em seguida uma propriedade de dados ou de objeto que deseja
adicionar, e então pode acrescentar mais propriedades de dados ou objetos, conforme
seja preciso para representar da melhor forma o indivíduo dentro do domínio de
conhecimento modelado pela ontologia, conforme ilustram as Figuras A7 a A9.
Figura A7 - Criando um novo indivíduo
Fonte: O autor (2015)
130
Após criar o indivíduo é possível adicionar propriedades, tais como
informações de localização, composição, entre outros.
Figura A8 - Adicionando uma propriedade ao indivíduo
Fonte: O autor (2015).
As propriedades novas podem ser adicionadas quantas foram necessárias
para caracterizar o novo site, com os valores sendo inseridos e podendo ser editados
livremente enquanto o formulário estiver aberto.
A clicar sobre o botão “Aplicar” os dados são inseridos no TDB através de
triplas RDF que atendem ao modelo ontológico carregado inicialmente e em uso, que
foi selecionado na tela anterior.
131
Figura A9 - Tela de inserção de propriedades ao indivíduo
Fonte: O autor (2015)
Após aplicar as inserções no dataset, a tela de informações do dataset
mostra que foram adicionadas novas triplas no TDB enquanto o modelo RDF/OWL
continua com as triplas originais, conforme mostra a Figura A10.
Figura A10 - Detalhe das triplas adicionadas ao TDB
Fonte: O autor (2015)
A cada indivíduo criado, bem como as propriedades de dados e de objetos
a ele associados, são inseridas na base de dados TDB, no dataset, novas triplas RDF
que representam estas informações, com as relações e vínculos definidos pelo
modelo e já indexados aos demais dados.
Desta forma, as informações essenciais para a aplicação dos reasoners
são inseridas, permitindo assim seu uso como base de referência na geração de
132
informações acerca das instalações prediais do site e de um conjunto de sites, que é
um dos objetivos deste trabalho.
1.6
Aplicação dos reasoners
Dentro da aplicação é possível rodar o reasoner OWL e obter inferências
com base em DL sobre as relações não explícitas e mesmo não declaradas na
aplicação, mas sim obtidas do modelo ontológico empregado, conforme ilustra a
Figura A11.
Figura A11 – Inferências obtidas sobre o indivíduo Shopping Center
Fonte: O autor (2015).
Observe-se que o reasoner OWL, empregando DL gerou 6 informações
sobre o indivíduo Shopping Center, conforme mostra o detalhe da Figura A12:
133
Figura A12 - Detalhe inferências
Fonte: O Autor (2015)
134
ANEXO 1 – EDITOR DE ONTOLOGIAS PROTÉGÉ
O projeto Protégé é um editor de ontologias, gratuito e de código aberto,
desenvolvido pela Universidade de Stanford, com aplicação via web, baseado em
Java, que proporciona um framework de desenvolvimento de bases de conhecimento
para as mais diversas aplicações.
De acordo com as especificações do Protégé, uma ontologia descreve os
conceitos e as relações que são importantes num domínio específico, proporcionando
um vocabulário para esse domínio, bem como uma especificação computadorizada
do significado dos termos utilizados no vocabulário “protege.standford.edu” (2015).
O Protégé suporta dois modos básicos de modelagem de ontologias:
Editor de frames protege, habilita a construção e preenchimento de
ontologias baseadas em frames, de acordo com o protocolo aberto
de conectividade de bases de conhecimento (OKBC);
Editor de OWL habilita a construção de ontologias compatíveis com
a semântica da web, particularmente a W3C.
Segundo o Wiki Protégé (2015), o WebProtégé oferece os seguintes
recursos:
Suporte para edição de ontologias com OWL versão 2;
A interface de edição simples padrão, que dá acesso ao construtor
OWL;
Controle de alterações completa e histórico de revisões;
Ferramentas de colaboração, tais como, compartilhamento e
permissões, notas de rosca e discussões, relógios e notificações por
e-mail;
Interface de usuário personalizável;
Formulários da Web personalizáveis para edição específica do
domínio de aplicação;
Suporte para ontologias OBO edição;
Vários formatos para upload e download de ontologias (formatos
suportados: RDF / XML, turtle, OWL / XML, OBO e outros);
135
O aplicativo editor de ontologias Protégé baseado em frames, atualmente
funcional na versão 4.3 e na versão de testes beta 5.0 possui uma interface gráfica de
usuário com as funcionalidades apresentas a seguir.
A Figura B1 apresenta a área de trabalho do Protégé desktop versão 4.3,
onde podem ser identificados os diversos painéis funcionais.
Figura B1 - Tela do Protégé desktop
Fonte: Protégé 4.3 (2014)
A interface possui várias abas que permitem diferentes formas de
visualização da ontologia. Uma barra de identificação do URI, que é único para cada
ontologia e precede a identificação de todas as entidades internas, quer sejam classes
ou suas instâncias, como indicado na Figura B2.
136
Figura B2 - Abas e URI no Protégé
Fonte: O Autor (2015)
O editor de ontologias Protégé possui plug-ins de reasoners, que são
máquinas de inferência, como o Hermit que analisa consistências nas taxonomias da
ontologia, o FACTS++ que possibilita inferir novos relacionamentos com base na
estrutura da ontologia.
O projeto Protégé possui uma vasta documentação de consulta, tanto ao
usuário
da
ferramenta,
através
do
link
http://protegewiki.stanford.edu/wiki/Protege4UserDocs, como para desenvolvedores,
através do link http://protegewiki.stanford.edu/wiki/WebProtegeDevelopersGuide.
A Linguagem SPARQL
Em uma consulta SPARQL temos os seguintes elementos básicos:
COMANDO: por exemplo SELECT
INFORMAÇÃO DESEJADA: por exemplo ?o
CONDIÇÃO DE BUSCA: exemplo WHERE
{COMPOSIÇÃO DO RDF}: exemplo { ?s ?p ?o}
Numa tripla RDF: ?s representa o sujeito, ?p representa o predicado e ?o
representa o objeto.
Uma consulta SPARQL pode retornar um literal, uma IRI ou uma outra RDF,
dependendo da forma como é realizada, conforme o seu propósito.
137
SPARQL permite utilizar vários tipos de dados como textos, números
inteiros, decimais, de dupla precisão, positivos ou negativos, bem como empregar
variáveis, possuindo uma sintaxe apropriada para cada tipo de dados.
Em exemplo simples de consulta SQPARL seria:
SELECT ?title
WHERE
{
< http://example.org./book/book1 >
< http://pur1.org/dc/elements/1.1/title >
?title
}
Onde:
SELECT é o comando de consulta à base
?title é a informação procurada
< http://example.org./book/book1 > representa o Objeto da tripla RDF
< http://pur1.org/dc/elements/1.1/title > representa o predicado da tripla
RDF
Como resultado, esta consulta deve trazer o título do arquivo consultado.
As formas de consulta no SPARQL incluem:
Query SELECT
Usado para extrair valores brutos de um serviço SPARQL, os
resultados são retornados em um formato de tabela.
Query CONSTRUCT
Usado para extrair informações de um serviço SPARQL e transformar
os resultados em RDF válido.
Query ASK
Usado para fornecer um simples resultado Verdadeiro / Falso para uma
consulta em um terminal SPARQL.
Query DESCRIBE
Utilizado para extrair um gráfico RDF a partir da extremidade SPARQL.