Middleware Sensível a Contexto para Integração de
Sistemas de Gerenciamento de Energia Elétrica
Por
Jonysberg Peixoto Quintino
Dissertação de Mestrado
Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br
Universidade Federal de Pernambuco
Centro de Informática
Pós-graduação em Ciência da Computação
Jonysberg Peixoto Quintino
Middleware Sensível a Contexto para Integração de
Sistemas de Gerenciamento de Energia Elétrica
Trabalho apresentado ao Programa de Pós-graduação em Ciência da Computação do Centro de Informática da Univer-sidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.
Orientador: Carlos André Guimarães Ferraz
Catalogação na fonte
Bibliotecária Joana D’Arc L. Salvador, CRB 4-572
Quintino, Jonysberg Peixoto.
Middleware sensível a contexto para integração de sistemas de gerenciamento de energia elétrica /
Jonysberg Peixoto Quintino. – Recife: O Autor, 2014.
115 f.: fig., tab.
Orientador: Carlos André Guimarães Ferraz. Dissertação (Mestrado) - Universidade Federal de Pernambuco. CIN. Ciência da Computação, 2014.
Inclui referências e apêndice.
1. Sistemas operacionais distribuídos
(computadores). 2. Middleware. 3. Sensibilidade a contexto. 4. Energia elétrica – transmissão. I.Ferraz,
Dissertação de Mestrado apresentada por Jonysberg Peixoto Quintino à Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco, sob o título “Middleware Sensível a Contexto para integração de
Sistemas de Gerenciamento de Energia Elétrica” orientada pelo Prof. Carlos André Guimarães Ferraz e aprovada pela Banca Examinadora formada pelos professores:
______________________________________________ Profa. Patricia Cabral de Azevedo Restelli Tedesco Centro de Informática / UFPE
______________________________________________ Prof. Vagner José do Sacramento Rodrigues
Departamento de Estatística e Informática / UFG
_______________________________________________ Prof. Abel Guilhermino da Silva Filho
Centro de Informática / UFPE
_______________________________________________ Prof. Carlos André Guimarães Ferraz
Centro de Informática / UFPE
Visto e permitida a impressão. Recife, 25 de fevereiro de 2014.
___________________________________________________
Profa. Edna Natividade da Silva Barros
Coordenadora da Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco.
A minha esposa Mônica e a meu filho Caio, por todo amor, compreensão e apoio incondicional; A minha mãe Maria Cenilda, esta vitória também é sua; Aos meus irmãos, cunhado(a)s e a todos os meus familiares;
Agradecimentos
A Deus, por permitir que eu tenha saúde, força e coragem para enfrentar todas as diversidades e conquistar tudo que desejo;
A minha amada mãe, Maria Cenilda, que mesmo diante de todas as dificuldades encontradas e que não foram poucas, conseguiu nos educar com valores sólidos, que moldaram o meu caráter e dos meus três irmãos. ESTA VITÓRIA TAMBÉM É SUA!
Ao meu amor e esposa, Mônica Peixoto, que ao meu lado conquistou todos os nossos sonhos, e que permitiu minha dedicação ao mestrado e especialmente, que me deu o maior dos presentes da vida, o nosso filho Caio, que tanto amo e com quem aprendo todos os dias a ser um pai e uma pessoa melhor. AMO VOCÊS!
Aos meus irmãos, cunhados e cunhadas pelo carinho, apoio e incentivo ao longo de todas as caminhadas;
Ao grande amigo, Ismar Kaufman, pela confiança e motivação que me encorajaram a conquistar um antigo sonho de fazer um mestrado;
Ao meu orientador, Carlos Ferraz, que só me conheceu no primeiro dia de aula mas que me conquistou como aluno e amigo de forma definitiva, pela sua amizade, paciência, franqueza e competência. Obrigado pelas longas reuniões de orientação regadas a café e que me serviram de terapia intelectual, educacional, motivacional e psicológica. Como eu sempre disse, sou seu fã!
Aos professores Abel Guilhermino Filho, Patrícia Tedesco e Vagner Rodrigues, agradeço a participação na banca examinadora deste trabalho;
A todas as pessoas da CTEEP que viabilizaram e participaram deste projeto espe-cialmente, Antônio Campos, Maureen Fitzgibbon Pereira, Marcos Bertinotti e Carlos Nascimento;
A todas as pessoas da In Forma Software que participaram deste projeto especialmente, Virgínia Sgotti, Flávia Durans, Wellington Silva, Hugo Filho, David Ribeiro e Julierme Araújo que enfrentaram todos os desafios sem nunca desanimar;
Aos professores Abel Guilhermino Filho, Patrícia Tedesco e Renata Souza pela disponibilidade e paciência nos momentos em que precisei tirar dúvidas;
Aos amigos Gláucia Campos, Ioram Sette e Marcelo Fernandes pela valiosa ajuda em todos os desafios enfrentados juntos ao longo das disciplinas, seminários e projetos.
O Senhor é o meu pastor, nada me faltará. Deitar-me faz em verdes pastos, guia-me mansamente às águas
tranquilas. Refrigera a minha alma; guia-me pelas veredas da justiça, por amor
do seu nome. Ainda que eu andasse pelo vale da sombra da morte, não temeria mal algum, porque tu estás comigo; a tua vara e o teu cajado me consolam. Preparas uma mesa perante mim na presença dos meus inimigos, unges a minha cabeça com óleo, o meu cálice transborda. Certamente que a bondade e a misericórdia me seguirão todos os dias
Resumo
Há décadas, os concessionários em todo o mundo contam com sistemas informatizados de gestão e supervisão para planejar e controlar a geração, transmissão e distribuição de energia. Tais sistemas fazem, entre outras coisas, o controle em tempo real de todos os equipamentos, ajudando os operadores destes sistemas a assimilar o que está acontecendo na rede de energia. Em geral, estes sistemas não são integrados automaticamente, tornando mais difícil o trabalho dos operadores dos centros de controle na obtenção de informações que são exibidas por diferentes sistemas. Foram encontrados trabalhos na literatura que tratam de várias formas, com aspectos relacionados à integração de dados entre sistemas do setor elétrico porém, até o momento da escrita desta dissertação, não foram encontrados trabalhos que utilizassem um middleware sensível ao contexto para integrar sistemas deste setor.
Este trabalho apresenta um modelo de arquitetura de middleware para integração sensível ao contexto de sistemas de gerenciamento de energia elétrica, provendo para os usuários informações relevantes, considerando que relevância depende das tarefas que o usuário está executando.
Um protótipo foi desenvolvido para integrar um sistema de controle de supervisão e aquisição de dados (SCADA), que monitora a rede de energia em tempo real, e outras aplicações de software, responsáveis pelo planejamento e gerenciamento de manutenções. Foi possível simular a rotina operacional de um centro de controle para testar o protótipo. Comparando-se os resultados dos testes do middleware, com o que foi feito manualmente pelos operadores, foi alcançado um percentual de acerto significativo (100%) na inferência dos contextos para as ocorrências forçadas (sem planejamento) e não forçadas (com planejamento). Com base nestes resultados, pode-se afirmar que o modelo proposto neste trabalho, permite utilizar um middleware sensível ao contexto que possibilite integrar alguns dos sistemas utilizados nos modernos centros de controle das empresas de energia elétrica, aumentando a eficácia e incrementando a segurança dos procedimentos de planejamento e execução das manutenções operativas.
Abstract
For decades now, utilities throughout the World rely on energy-management systems and supervisory computer systems to plan and control the generation, transmission, and distribution of power. Such systems, among other things, control in real time all power-generating equipment, and monitor the performance of the transmission system, helping system operators assimilate what is happening in the power network. In general, these systems are not automatically integrated, making harder the work of the control center operators.
This work presents a context-aware middleware for the integration of systems invol-ved in the process of management of electric power, providing the user with relevant information, considering that relevance depends on the task the user is performing.
A prototype was developed to integrate a supervisory system (SCADA – supervisory control and data acquisition) and other systems that are used to plan, manage, and analyze electric-power events. It was possible to simulate the operational routine of a control center to test the prototype. Comparing the middleware test results with what has been done manually by operators, a significant percentage of accuracy in the context inferences for forced and not forced occurrences has been reached. The evidence from this study suggests that the proposed model allows integrating the systems used in modern control centers of power companies, increasing the effectiveness, and enhancing safety procedures for planning and execution of operational maintenance.
Lista de Acrônimos
XML eXtensible Markup Language
SCADA Supervisory Control And Data Acquisition
ANEEL Agência Nacional de Energia Elétrica
ONS Operador Nacional do Sistema Elétrico
DMS Distribution Management System
EMS Energy Management System
Lista de Códigos Fonte
Lista de Figuras
2.1 Intercâmbios entre subsistemas do Sistema Interligado Nacional em 2012
(MWmédio) (EPE, 2013) . . . 24
2.2 Sistemas comuns de um centro de controle (Varga et al., 2011) . . . 24
2.3 Operação do Sistema de Transmissão de Energia Elétrica . . . 25
2.4 Centro de controle e suas funcionalidades (Zhang et al., 2010) . . . 27
2.5 Modelo de referência do EMS-API IEC 61970-301 (IEC, 2011) . . . . 28
2.6 Modelo contextual e elementos contextuais . . . 29
2.7 Diferenças entre os tipos de aplicações quanto a entradas e saídas. Adap-tado de (Vieira et al., 2009) . . . 30
2.8 Exemplo da localização de um middleware. (Coulouris et al., 2011) . . 32
2.9 (a) Forte acoplamento (b) Fraco acoplamento . . . 32
2.10 Modelo de referência para um middleware sensível a contexto (Ray-choudhury et al., 2013) . . . 33
2.11 A Bus Services for Electric Calculations (Penin et al., 2012) . . . 35
2.12 Fault solving use case’s integration line (Varga et al., 2011) . . . 36
2.13 Protótipo implementado para integração (Junior, 2006) . . . 37
3.1 Diagrama de casos de uso utilizados no escopo do projeto . . . 40
3.2 Grafo contextual - Identificando o tipo de um desligamento . . . 42
3.3 Modelo de informações contextuais . . . 43
3.4 Arquitetura de referência do modelo de middleware proposto . . . 45
3.5 Arquitetura do Serviço de Gerenciamento de Contexto com Drools . . . 47
3.6 Exemplo de uma regra de contexto utilizando Drools . . . 48
3.7 Arquitetura do serviço de mensagens . . . 48
3.8 Exemplo de mensagem XML . . . 50
3.9 Funcionamento do UUID Service. . . 51
3.10 Exemplo de um mapeamento de ID distintos para UUID . . . 52
3.11 Arquitetura do serviço Real Time Event Monitor Service . . . 53
3.12 Funcionamento do Real Time Event Monitor Service . . . 53
4.1 Arquitetura da prova de conceito . . . 58
4.5 Cenário 1 com middleware . . . 61
4.6 Notificação do contexto do equipamento com bloqueio no simulador S_SL1 62 4.7 Grafo contextual - Foco: Obter Bloqueio de um equipamento . . . 62
4.8 Regra Drools para o foco obter bloqueio de um equipamento . . . 63
4.9 Cenário 2 sem middleware . . . 64
4.10 Cenário 2 com middleware . . . 64
4.11 Desligamentos de um período no simulador (S_SL2) . . . 65
4.12 Cenário 3 sem middleware . . . 66
4.13 Cenário 3 com middleware . . . 67
4.14 Normalizações (a) e eventos relacionados (b) de um período no simulador S_SL2 . . . 67
4.15 Cenário 4 sem middleware . . . 68
4.16 Extrato de um XML enviado na liberação programada . . . 69
4.17 Registro de ocorrência não forçada e com desligamento no simulador S_SL2 . . . 70
4.18 Cenário 5 sem middleware . . . 71
4.19 Extrato de um XML enviado na normalização programada . . . 72
4.20 Exemplo de ocorrência não forçada após normalização programada no simulador S_SL2 . . . 72
5.1 Diagrama de implantação: Ambiente utilizado na execução dos serviços e aplicativos . . . 76
5.2 Eventos identificados e notificados pelo middleware . . . 79
5.3 Bloqueios de equipamentos identificados pelo middleware . . . 80
5.4 Ocorrências geradas automaticamente pelo middleware . . . 81
A.1 Grafo - Obter bloqueio de equipamento . . . 97
A.2 Regra - Obter Bloqueio de Equipamento . . . 98
A.3 Grafo - Notificando desligamentos . . . 98
A.4 Regra - Desligamento total de uma LT . . . 98
A.5 Regra - Desligamento parcial de uma LT . . . 99
A.6 Grafo - Finalizando desligamento . . . 99
A.7 Regra - Normalização total de uma LT . . . 100
A.8 Regra - Normalização parcial de uma LT . . . 100
A.9 Grafo - Informando liberação programada . . . 101
A.11 Regra - Ocorrência não forçada e sem desligamento . . . 102
A.12 Regra - Liberação realizada após normalização . . . 102
A.13 Regra - Liberação sem registro de TAG no SAGE . . . 102
A.14 Grafo - Informando normalização programada . . . 103
Lista de Tabelas
2.1 Técnicas para modelagem de contexto. Adaptado de (Raychoudhury et al., 2013) . . . 31
2.2 Comparativo entre os trabalhos relacionados . . . 37
3.1 Regras utilizadas para inferência de contextos . . . 49
3.2 Comparativo entre os trabalhos relacionados e o middleware proposto . 54
5.1 Quantidade de eventos registrados no LOG do SCADA . . . 79
5.2 Ocorrências forçadas: Campos preenchidos automaticamente pelo mid-dleware . . . 82
Sumário
1 Introdução 17 1.1 Motivação . . . 17 1.2 Problema . . . 18 1.3 Solução Proposta . . . 19 1.4 Fora do Escopo . . . 20 1.5 Contribuições Esperadas . . . 20 1.6 Estrutura da Dissertação . . . 20 2 Revisão de Literatura 232.1 Sistemas Elétricos e Aplicações para Setor . . . 23
2.1.1 Sistemas Elétricos . . . 24
2.1.2 Aplicações do Setor Elétrico . . . 25
2.1.3 Computação . . . 27
2.1.4 O modelo CIM . . . 27
2.2 Sensibilidade a Contexto . . . 28
2.2.1 Contexto . . . 29
2.2.2 Sistemas Sensíveis ao Contexto . . . 30
2.2.3 Middleware Sensível a Contexto . . . 31
2.3 Trabalhos Relacionados . . . 34
2.4 Discussões. . . 36
2.5 Considerações Finais . . . 38
3 Modelo de Middleware para Integração Sensível a Contexto 39
3.1 Especificação de Requisitos. . . 39
3.2 Modelagem Contextual . . . 41
3.3 Arquitetura . . . 45
3.4 Serviços do Middleware . . . 46
3.4.1 Context Management Service . . . 47
3.4.2 Context Notification Service . . . 48
3.4.3 UUID Service. . . 51
4 Cenários de Implementação 57
4.1 Protótipo . . . 57
4.2 Cenários . . . 58
4.2.1 Cenário 1 - Identificando Bloqueios de Equipamentos. . . 59
4.2.2 Cenário 2 - Notificando Desligamentos de Equipamentos . . . . 63
4.2.3 Cenário 3 - Finalizando Desligamentos . . . 65
4.2.4 Cenário 4 - Informando uma Liberação Programada . . . 68
4.2.5 Cenário 5 - Informando uma Normalização Programada . . . . 70
4.3 Considerações Finais . . . 73
5 Resultados e Análises 75
5.1 Ambiente de Execução . . . 75
5.2 Execução dos Testes . . . 77
5.3 Análise dos Resultados . . . 78
5.3.1 Eventos Identificados a partir do Monitoramento do LOG . . . 79
5.3.2 Bloqueios Identificados a partir do Monitoramento do LOG . . 80
5.3.3 Ocorrências Geradas a partir dos Eventos Identificados . . . 81
5.3.4 Campos Preenchidos Automaticamente para o Registro de Ocor-rências . . . 82
5.3.5 Taxa de Acerto do Middleware na Inferência de Ocorrências não Forçadas . . . 84
5.4 Considerações Finais . . . 85
6 Conclusão e Trabalhos Futuros 87
6.1 Contribuições . . . 88
6.2 Limitações. . . 88
6.3 Trabalhos Futuros . . . 89
Referências Bibliográficas 93
Apêndice 94
A Grafos e regras drools 97
A.1 Foco: Identificando Bloqueio de Equipamento . . . 97
A.2 Foco: Notificando Desligamentos . . . 97
A.3 Foco: Finalizando Desligamentos . . . 99
1
Introdução
A combinação de EDUCAÇÃO e OPORTUNIDADE resulta em ESPERANÇA. —SILVIO MEIRA (Novos Negócios)
Há décadas, os concessionários em todo o mundo contam com sistemas informatiza-dos de gestão e supervisão para planejar e controlar a geração, transmissão e distribuição de energia (Masiello, 1985). Tais sistemas fazem, entre outras coisas, o controle em tempo real de todos os equipamentos de geração, transmissão de energia e monitoramento do desempenho do sistema como um todo, ajudando os operadores do sistema a assimilar o que está acontecendo na rede de energia.
No Brasil, a resolução Normativa Aneel 270/2007 (ANEEL,2007), estabelece as disposições relativas à qualidade do serviço público de transmissão de energia elétrica, associada à disponibilidade das instalações básicas da Rede Básica. Com isto, aumentou-se o nível de exigência dos aumentou-serviços, exigindo-aumentou-se um esforço dos sistemas de informação das empresas de transmissão de energia, quanto à necessidade de integração de seus diversos e sofisticados processos de gestão, que atualmente não são integrados.
Tais sistemas, quando utilizados de forma integrada, aumentam potencialmente os seus benefícios. No entanto, a falta deste tipo de integração, automática, torna mais difícil o trabalho dos operadores dos centros de controle, no cumprimento de suas atividades, exigindo cada vez mais dos usuários atenção nas rotinas diárias.
1.1
Motivação
EmYan et al.(2013) é apresentada uma visão, originalmente proposta porZhang et al.
CAPÍTULO 1. INTRODUÇÃO
uma de suas características-chave é o monitoramento online centrado no ser humano. Para tanto, as funções de monitoramento da próxima geração devem fornecer aos operadores informações úteis em vez de apenas dados não processados. Estas funções devem empregar técnicas de visualização com o objetivo de ajudar cada operador a digerir informação rapidamente.
Sabe-se que grandes volumes de dados são colhidos pelos sistemas de gestão de ener-gia e que estes dados precisam ser transformados em informações significativas/relevantes quanto a um dado contexto para serem apresentadas aos operadores.
Por exemplo, os dados sobre o identificador de um equipamento programado para manutenção e a data desta manutenção, ambos oriundos do sistema de programação de intervenções, e o registro (naquela data) do desligamento do mesmo equipamento monitorado pelo sistema SCADA (do Inglês, Supervisory Control and Data Acquisition), permitem inferir e registrar automaticamente o contexto ’O desligamento não é forçado’, entre outros.
1.2
Problema
Para Zhang et al.(2010), devido à falta de integração entre os sistemas, em geral, os atuais centros de controle das empresas de energia, possuem um funcionamento reativo. Ou seja, exige-se dos operadores um constante acompanhamento de telas de diferentes sistemas, que monitoram o estado operativo dos equipamentos e suas funções, para que possam tomar decisões acerca de um grande conjunto de eventos que acontecem ao mesmo tempo.
Nos centros de controle de gerenciamento de energia existem sistemas especializa-dos como o SCADA, categoria de sistemas que permitem o monitoramento do estado operativo de um equipamento em tempo real. Há também sistemas responsáveis pelo planejamento das manutenções, como também os responsáveis pelo registros dos fatos (inicialização/ocorrência/finalização) para uma análise mais profunda dos acontecimen-tos.
Como já dito, em geral, estes sistemas não são integrados, o que significa que solicita-ções de impedimento (SI) emitidas, por exemplo, passam por verificasolicita-ções e intervensolicita-ções manuais para validar e garantir que as informações contidas nas programações de manu-tenção, estejam corretas e que ocorram de forma a diminuir ou tornar mais eficiente o tempo de parada. Também é necessário que os operadores redigitem dados de um sistema para outro, a fim de consolidar informações sobre o estado operativo de um equipamento,
1.3. SOLUÇÃO PROPOSTA
e outras situações que são típicas de um ambiente não integrado.
Como exemplo, a fim de identificar o motivo de um desligamento de equipamento, os operadores têm que acessar informações que são exibidas por diferentes sistemas. Precisam interpretar, compreender os eventos, descobrir se existe algum tipo de relacio-namento entre estes eventos e tomar decisões baseadas nesta interpretação, o que pode acarretar em falhas devido a complexidade e quantidade de eventos diários em um centro de controle.
Ao analisar dados de 2011 e 2012 de uma grande empresa de transmissão de energia elétrica, com mais de 12 mil Km de linhas de transmissão, descobriu-se um número significativo de solicitações de manutenção canceladas devido a erros de digitação ou inconsistências causadas pela falta de informação adequada que caracterizasse o contexto. A análise mostrou ainda, que muitos conjuntos de dados provenientes de diferentes sistemas são especialmente relacionados, podendo formar um contexto (Dey et al.,2001).
Utilizar sensibilidade ao contexto para proporcionar uma integração entre estes siste-mas computacionais especializados que foram desenvolvidos em épocas e tecnologias distintas, constituem um grande desafio. Sem alterar suas lógicas de negócio, será possível utilizar informações contextuais relevantes para os operadores e que possam incrementar a segurança da operação e minimizar possível erros.
1.3
Solução Proposta
Este trabalho tem como objetivo geral criar um modelo de middleware que permita a integração sensível a contexto de sistemas de gerenciamento de energia. Pretende-se permitir que o operadores possuam informações mais relevantes acerca do contexto dos eventos e seus relacionamentos, para que, baseados em informações contextuais, possam ser auxiliados de forma automática, na condução de suas atividades diárias.
Como objetivos específicos, através do uso do modelo proposto, pretende-se:
1. Validar o modelo proposto através do desenvolvimento de um protótipo que permita simular a rotina operacional de um centro de controle através da integração sensível ao contexto entre sistemas legados ou de novos sistemas que são comuns ao setor de energia elétrica;
2. Realizar uma integração entre os sistemas comuns às empresas deste setor e que são utilizados no monitoramento dos equipamentos, assim como, no planejamento
CAPÍTULO 1. INTRODUÇÃO
das manutenções. Entre os exemplos deste sistemas estão um sistema SCADA, um sistema de solicitações de impedimento e um sistema de registro de ocorrências;
3. Notificar usuários e os sistemas envolvidos na integração, com as informações contextuais relacionadas aos eventos monitorados, permitindo assim, uma possível diminuição de acessos desnecessários as diversas telas dos sistemas integrados;
4. Automatizar o preenchimento dos campos de um sistema de registro de ocorrências, para agilizar o trabalho dos operadores na análise e registro destas informações que são cruciais para a qualidade dos serviços prestados pelas empresas do setor.
1.4
Fora do Escopo
O Sistema Interligado Nacional (SIN) é composto por diversas empresas que atuam nas áreas de geração, transmissão, distribuição e consumo de energia. Dentro de cada uma destas áreas, existe uma grande diversidade e abrangência de sistemas utilizados. Esta pesquisa foi desenvolvida em parceria com uma empresa do setor de transmissão, portanto, não estão no escopo os sistemas das áreas de geração, distribuição e consumo de energia.
1.5
Contribuições Esperadas
Como resultado do trabalho apresentado por esta dissertação, destaca-se a criação de um modelo de arquitetura de middleware para integração sensível ao contexto de sistemas de gerenciamento de energia.
Espera-se que este modelo de arquitetura sensível ao contexto possa ser utilizado, mediante devidas adaptações, por qualquer empresa que necessite integrar sistemas de gerenciamento legados ou de novos sistemas, a exemplo dos sistemas de gerenciamento de energia das empresas deste setor, provendo informações mais relevantes aos seus usuários.
1.6
Estrutura da Dissertação
A continuação desta dissertação está organizada em mais cinco capítulos. O Capítulo2
apresenta o referencial teórico encontrado na literatura com os principais conceitos relacionados à pesquisa deste trabalho. O Capítulo3apresenta a proposta deste trabalho,
1.6. ESTRUTURA DA DISSERTAÇÃO
um modelo de arquitetura de um middleware para integração sensível a contexto de sistemas de gerenciamento de energia elétrica. O Capítulo 4apresenta uma prova de conceito do modelo proposto, através da implementação de um protótipo do middleware. O Capítulo5apresentada uma análise de resultados referentes aos testes executados no protótipo. Por fim, o Capítulo6apresenta a conclusão e os trabalhos futuros que podem surgir a partir desta pesquisa.
2
Revisão de Literatura
Uma vida sem desafios não vale a pena ser vivida. —SÓCRATES (Filósofo)
Este capítulo aborda o referencial teórico encontrado na literatura com os principais conceitos relacionados à aplicação de computação nos Sistemas Elétricos, Sensibilidade a Contexto e Middleware, como também, trabalhos já propostos que utilizam alguns desses conceitos e que serviram de base para esta dissertação.
2.1
Sistemas Elétricos e Aplicações para Setor
A matriz energética brasileira é bastante diversificada (ex. nuclear, hidroelétrica e térmica convencional). As dimensões continentais do Brasil exigem das concessionárias um esforço para suprir a crescente demanda por energia elétrica em todas as regiões. Em uma pesquisa publicada pela Empresa de Pesquisa Energética (EPE,2013), vinculada ao Ministério de Minas e Energia, demonstra-se como o Sistema Interligado Nacional (SIN) promove um intercâmbio de energia entre as regiões do Brasil em MW médio (Figura2.1).
SegundoMasiello(1985), há décadas empresas do setor de energia elétrica em todo o mundo contam com sistemas informatizados de gestão e supervisão para planejar e con-trolar a geração, transmissão e distribuição de energia. O uso de sistemas informatizados se torna imprescindível para gerenciar e supervisionar esta infraestrutura.
CAPÍTULO 2. REVISÃO DE LITERATURA
Figura 2.1 Intercâmbios entre subsistemas do Sistema Interligado Nacional em 2012 (MWmédio) (EPE,2013)
2.1.1
Sistemas Elétricos
ParaVarga et al.(2011), existem diversos sistemas especialistas para o setor elétrico e que podem estar interligados através de softwares e serviços que permitam algum tipo de interoperação, como por exemplo, o uso de um barramento de comunicação. Desta forma, permite-se a integração do fluxo de dados entre determinados sistemas (Figura2.2).
Figura 2.2 Sistemas comuns de um centro de controle (Varga et al.,2011)
Na literatura e no mercado, existe uma grande diversidade de sistemas para o setor elétrico de geração, transmissão e distribuição de energia. Dentre os principais, estão os
2.1. SISTEMAS ELÉTRICOS E APLICAÇÕES PARA SETOR
responsáveis pelo Controle de Supervisão e Aquisição de Dados (do Inglês, Supervisory Controle and Data Acquisition - SCADA) que se comunicam com os equipamentos em campo para coletar as medições e o estado operativo dos equipamentos.
Existem também os sistemas de Gestão de Ativos (do Inglês, Asset Management), que possuem o detalhamento de cada equipamento existente (ex. subestações, linhas de transmissão, transformadores, etc.), permitindo entre outras coisas, obter informações sobre sua localização.
Outros sistemas são responsáveis pelo Gerenciamento da Distribuição da Energia (do Inglês, Distribution Management System - DMS) que dentre outras funcionalidades, possuem funções analíticas que permitem aos operadores realizar várias simulações sobre o modelo da rede de distribuição, por exemplo, e assim, melhorar o gerenciamento de falhas, otimizando a operação do sistema.
Os sistemas responsáveis pela Gestão de Energia (do Inglês, Energy Management System - EMS) são similares aos DMS, porém com enfoque para as redes de transmissão possuindo funcionalidades de análise de contingência para encontrar, entre outras coisas, pontos fracos, o que poderia desestabilizar a transmissão de energia.
Por fim, existem os Sistemas de Gestão de Falhas (do Inglês, Outage Management System - OMS) que são responsáveis pela recuperação, semi-automática do sistema em momentos de falha.
2.1.2
Aplicações do Setor Elétrico
Os centros de controle das empresas do setor elétrico geralmente são divididos em três diferentes áreas de atuação: pré-operação, tempo real e pós-operação (Figura2.3).
Figura 2.3 Operação do Sistema de Transmissão de Energia Elétrica
A pré-operação é responsável por analisar e aprovar solicitações de impedimento para viabilizar manutenções, com parada ou não, em equipamentos ou linhas de transmissão, por exemplo. A operação em tempo real é responsável por controlar os níveis operacionais
CAPÍTULO 2. REVISÃO DE LITERATURA
(ex. tensão, carga e controle de frequência) da rede de energia elétrica, permitindo assim, manobras e ações quando mudanças nesses parâmetros ocorrem, ao passo que a pós-operação é responsável pela análise e registro de ocorrências, tais como falha de equipamento ou desligamentos de linhas de transmissão para que, em outras situações semelhantes, os processos possam ser ajustados com as lições aprendidas com os eventos anteriores já registrados.
De acordo comMasiello(1985), existem sistemas que fazem, entre outras coisas, o controle em tempo real de todos os equipamentos de geração de energia e monitoramento do desempenho do sistema de transmissão, ajudando os operadores do sistema de assimilar o que está acontecendo na rede de energia. Há também sistemas responsáveis pela solicitação, liberação e normalização de impedimentos (com ou sem desligamento), como também pelo registro de fatos de inicialização, ocorrências e finalização para uma análise mais profunda dos acontecimentos. Grande parte destas atividades compreendem os procedimentos de rede que normatizam a atuação das empresas do setor no Brasil e que são estabelecidas pelo ONS (Operador Nacional do Sistema).
Ao longo das últimas décadas, muitos destes programas de computador e aplicações de software foram desenvolvidos para exercer o controle da supervisão e aquisição de dados, registrar eventos, realizar análises estatísticas, prever o efeito das interrupções para melhorar a segurança do sistema, entre outras funções.
Atualmente, em consequência, as concessionárias usam uma grande variedade de sistemas para monitorar e gerenciar seus equipamentos. Tais sistemas na maioria das vezes, foram desenvolvidos em épocas e tecnologias distintas e que, em geral, não possuem algum tipo integração.
Entretanto,Zhang et al.(2010) afirma que a operação dos centros de controle tem um funcionamento reativo, ou seja, os operadores precisam estar atentos aos eventos normalmente registrados em telas com LOG dos sistemas de alarme, que demandam um intenso estado de atenção (Figura2.4). Geralmente baseados na experiência profissional e na rigorosa utilização de normas e padrões adotados pelos órgãos reguladores (ex. procedimento de rede1, no Brasil), os operadores precisam interpretar, compreender os eventos, descobrir se existe algum tipo de relacionamento entre eles e tomar decisões baseadas nesta interpretação, o que pode acarretar em falhas devido a complexidade e quantidade de eventos diários em um centro de controle.
1http://www.ons.org.br/procedimentos/index.aspx
2.1. SISTEMAS ELÉTRICOS E APLICAÇÕES PARA SETOR
Figura 2.4 Centro de controle e suas funcionalidades (Zhang et al.,2010)
2.1.3
Computação
Como foi apresentado nas seções anteriores, Seção2.1e Seção2.1.2, a variedade e a he-terogeneidade de aplicações do setor elétrico demandam desafios comuns, inclusive para sistemas computacionais deste setor, ou seja, o desejo e a necessidade do compartilha-mento de dados e informações comuns que detalham o funcionacompartilha-mento dos equipacompartilha-mentos e seus estados operativos (Khare et al.,2011).
Contudo, tal diversidade implica em muito esforço para integrar e utilizar uma grande quantidade de dados, que geralmente possuem formatos diferentes para a representação de uma mesma informação.
Uma importante iniciativa de padronização do uso destes dados, se deu com a cria-ção de um modelo único, capaz de estabelecer um padrão internacional que permita a intercomunicação entre os diversos sistemas do setor.
Surgiu o CIM - Common Information Model, iniciativa liderada pelo EPRI - Electric Power Research Institute, organismo sem fins lucrativos, que reúne as principais empresas do setor elétrico do mundo. Desde então, o IEC -International Electrotechnical Commis-sion, por meio do Technical Committee 57 - (TC57), atua na padronização e evolução do modelo CIM, dentre os quais, os mais estáveis são o IEC 61970 e IEC 61850.
2.1.4
O modelo CIM
O modelo IEC 61970, foi criado para promover a interoperabilidade entre os dados dos centros de controle, utilizando os sistemas EMS através de uma API (EMS-API) (IEC,
CAPÍTULO 2. REVISÃO DE LITERATURA
2009).
Este modelo de referência é uma abstração da arquitetura física dos equipamentos. Permite visualizar os dados dos equipamentos, em um formato comum, fornecendo uma linguagem para descrevê-los, definindo uma terminologia, além de outras funcionalidades, que auxiliam o entendimento de seu uso. A Figura2.5apresenta um diagrama de pacotes do modelo de referência com a representação das partes que compõem o domínio que o padrão EMS-API engloba.
Figura 2.5 Modelo de referência do EMS-API IEC 61970-301 (IEC,2011)
Cada pacote deste modelo de referência, possui uma gama de classes específicas para representação única dos equipamentos que as compõem.
2.2
Sensibilidade a Contexto
Esta seção apresenta alguns dos conceitos encontrados na literatura relacionados ao uso de Contexto, Sensibilidade a Contexto (do Inglês, Context Awareness) e Middleware Sensível a Contexto. Fundamenta-se as principais características que permitem a adaptação de sistemas computacionais a contextos (situações) estabelecidos dinamicamente.
2.2. SENSIBILIDADE A CONTEXTO
2.2.1
Contexto
Diversas definições relacionadas a contexto são encontradas na literatura, entre as mais clássicas,Dey et al.(2001), definindo contexto como qualquer informação que caracterize uma situação de uma entidade, podendo a entidade ser representada por uma pessoa, um lugar ou um objeto.Vieira et al.(2009) define contexto como o conhecimento que está por trás da habilidade de discriminar o que é ou não importante em um dado momento, apoiando indivíduos a melhorar a qualidade da conversação e a compreender certas situações, ações ou eventos.
A utilização de contexto, na computação, investiga o uso das informações presentes na interação entre pessoas e computadores, com o objetivo de ampliar a qualidade da comunicação entre o ser humano e sistemas computacionais. Tais informações, por vezes desconsideradas do processo de interação, são denominadas de informações contextuais, que contêm elementos contextuais (do Inglês, Contextual Element). Estas informações contextuais podem ser utilizadas como fontes de conhecimento pelos sistemas (Vieira et al.,2009). A Figura2.6ilustra um exemplo de um modelo contextual, suas entidades e elementos.
Figura 2.6 Modelo contextual e elementos contextuais
Estas entidades devem ser consideradas importantes para o usuário e para os sistemas que delas tratam. Um sistema passa a ser considerado sensível a contexto quando, em diversas situações e condições, após a compreensão de um contexto, muda sua
CAPÍTULO 2. REVISÃO DE LITERATURA
sequência de ações, interações e o tipo de informações fornecidas ao usuários sem que seja explicitamente solicitado.
2.2.2
Sistemas Sensíveis ao Contexto
Um sistema é considerado sensível ao contexto (do Inglês, Context-aware System) se ele utiliza contexto para fornecer informações ou serviços relevantes, sendo que a relevância depende da tarefa do usuário (Dey et al.,2001).
Outros termos podem ser encontrados na literatura e considerados como sinônimos (ex. sistemas baseados em contexto, aplicações adaptativas, aplicações dirigidas à resposta, aplicações cientes de contexto).
Dentre as principais diferenças entre sistemas sensíveis ao contexto e as aplicações ditas tradicionais, ou seja, sem suporte ao contexto, está o fato de que as aplicações tradicionais levam em consideração apenas as informações e solicitações fornecidas pelos usuários de forma explícita e atendendo basicamente aos requisitos funcionais levantados. A Figura 2.7, ilustra a diferença entre aplicações tradicionais e aplicações sensíveis a contexto.
Figura 2.7 Diferenças entre os tipos de aplicações quanto a entradas e saídas. Adaptado de (Vieira et al.,2009)
Um sistema sensível a contexto considera não só as informações explícitas (que também podem ser contexto) fornecidas pelos usuários, também são utilizadas aquelas in-formações armazenadas em bases de conhecimento contextuais, as inin-formações inferidas por meio de raciocínio (ex. lógica de primeira ordem) e, também, aquelas percebidas a partir do monitoramento do ambiente (ex. sensores). Estas informações obtidas de forma não-explícitas são o que se chama de informações contextuais.
Com a utilização das informações contextuais, a aplicação pode enriquecer semanti-camente a solicitação explícita do usuário, executando serviços mais próximos às suas
2.2. SENSIBILIDADE A CONTEXTO
necessidades e sem que o usuário perceba, adaptar suas interações e funcionalidades para melhorar e enriquecer sua experiência no uso de uma aplicação sensível ao contexto.
Muitos modelos de contexto têm sido desenvolvidos ao longo da última década, que vão de simples modelos a complexos e sofisticados (Raychoudhury et al.,2013). A Tabela2.1ilustra algumas das principais técnicas para modelagem de contexto.
Tabela 2.1 Técnicas para modelagem de contexto. Adaptado de (Raychoudhury et al.,2013)
2.2.3
Middleware Sensível a Contexto
Integrar sistemas computacionais é fazer com que aplicações distintas trabalhem em conjunto através de suas funcionalidades para produzir um resultado em comum. O grande desafio está em integrar tais aplicações, que foram desenvolvidas por empresas diferentes, tecnologias e épocas distintas (Hohpe and Woolf,2004). Existem diversas abordagens tecnológicas na literatura e no mercado, para possibilitar uma integração de sistemas computacionais, entre elas, o uso de um middleware. ParaCoulouris et al.
(2011), middleware se aplica a uma camada de software que fornece uma abstração de programação, escondendo a heterogeneidade das redes, hardware, sistema operacional e linguagens de programação. A Figura 2.8ilusta um exemplo da localização de um middleware.
Ao utilizar um middleware, permite-se a integração de sistemas com pouca interven-ção na lógica de negócio das aplicações, através do conceito de fraco acoplamento. Fraco
CAPÍTULO 2. REVISÃO DE LITERATURA
Figura 2.8 Exemplo da localização de um middleware. (Coulouris et al.,2011)
acoplamento é um dos principais requisitos na integração de sistemas legados, como os muitos que são usados em diversos setores, tal como, no setor de energia elétrica.
A Figura 2.9 ilustra a diferença entre (a) forte acoplamento, onde os sistemas se comunicam sem intermediários, o que demanda maior intervenção nos seus códigos, e (b) fraco acoplamento, em que os sistemas se integram através de um barramento de comunicação (ex. middleware).
Figura 2.9 (a) Forte acoplamento (b) Fraco acoplamento
Unificar soluções heterogêneas utilizando middleware e sensibilidade a contexto, constituem um grande desafio, uma vez que existe uma grande diversidade de tecnologias e aplicabilidade para estes conceitos. Como exemplo, a computação ubíqua e pervasiva é uma das áreas que mais utiliza tais funcionalidades, como o objetivo principal criar um ambiente inteligente com dispositivos embutidos de computação em rede, proporcionando aos usuários um contínuo acesso aos serviços prestados (Raychoudhury et al.,2013).
Diversos trabalhos são encontrados na literatura com diferentes abordagens na uti-lização de middleware sensível a contexto para aplicações ubíquas e pervasivas. Entre algumas das clássicas referencias estão CORTEX (Veríssimo et al.,2002), Aura (Garlan et al.,2002), Gaia (Román et al.,2002) entre muitas outras, que apresentam diferentes
2.2. SENSIBILIDADE A CONTEXTO
paradigmas na utilização desta abordagem, porém, nenhuma delas relacionadas ao setor de energia elétrica.
Raychoudhury et al. (2013) apresenta um modelo de referência com as principais características básicas que devem ser implementas para o desenvolvimento de um mid-dlewaresensível a contexto (Figura2.10).
Figura 2.10 Modelo de referência para um middleware sensível a contexto (Raychoudhury et al., 2013)
Este modelo de referência apresenta uma organização que identifica um conjunto de serviços padrão e requisitos de suporte essenciais, que devem ser prestados por um middlewarecom esta característica. A organização de tais características e dos serviços sugeridos pelo modelo, não implicam sua total implementação, ou seja, é possível combinar os serviços para que melhor se adequem aos requisitos a serem atendidos no desenvolvimento de um novo middleware sensível a contexto.
CAPÍTULO 2. REVISÃO DE LITERATURA
Ainda segundoRaychoudhury et al.(2013), a sensibilidade a contexto pode ser clas-sificada em quatro áreas primárias: aquisição de contexto, armazenamento de contexto, modelagem de contexto e inferência de contexto. A aquisição de contexto é um pré-requisito para aplicações sensíveis ao contexto e refere-se a um processo de obtenção de contextos a partir de várias fontes (ex. sensores, atuadores, dispositivos virtuais, sistemas,etc.). O armazenamento de contextos se depara com o desafio de gerenciar grandes volumes de dados, como também, gerenciar o relacionamento contextual entre eles. A modelagem contextual permite utilizar diversas abordagens para a representação contextual das informações que farão parte de uma solução (ex. modelos: par-chave-valor, baseados em lógica, orientados a objeto, linguagem de marcação (XML), ontologias). A inferência contextual refere-se a um processo de inferência de alto nível de informações de contexto implícito, baseado em informações de contexto explícita de baixo nível (ex. SE “temperatura < 21” ENTÃO “desligar ar-condicionado”).
A proposta deRaychoudhury et al.(2013), servirá como base para a concepção de uma arquitetura-modelo do middleware proposto nesta dissertação e que será oportunamente apresentada no Capítulo3.
2.3
Trabalhos Relacionados
São encontradas na literatura diversas propostas e abordagens para utilização de mid-dlewaresensível a contexto, em diversas áreas da computação ubíqua e pervasiva, como emRaychoudhury et al.(2013),Amaral(2011),Badii et al.(2010),Bettini et al.(2010),
Romero(2008),Pessoa(2006),Sacramento et al.(2004),Capra et al.(2003),Chan and Chuang(2003), entre diversos outros.
Entretanto, até o momento da escrita desta dissertação, não foram encontradas na literatura propostas que tratassem exatamente do assunto relacionado a utilização de um middleware para integração sensível a contexto de sistemas de gerenciamento de energia elétrica.
Porém, foram encontrados trabalhos que tratam de alguma forma, com aspectos relacionados à integração de dados entre sistemas do setor elétrico como um todo. Em Penin et al. (2012), foi proposta a utilização de um barramento de comunicação para a integração de dados de aplicações, utilizando o modelo CIM (do Inglês,Common Information Model), através do uso de conectores (Figura2.11).
A proposta dePenin et al.(2012) definiu uma arquitetura de barramento de comunica-ção (middleware), que implementa o modelo CIM, para padronizar a integracomunica-ção de dados
2.3. TRABALHOS RELACIONADOS
Figura 2.11 A Bus Services for Electric Calculations (Penin et al.,2012)
entre sistemas envolvidos no planejamento e calculo da geração de energia da empresa Eletropaulo.
Foram desenvolvidos conectores para viabilizar a comunicação entre estes aplicativos e o barramento de serviços proposto. O barramento funciona como um redirecionador de demandas de cálculos, delegado aos conectores de cada sistema especialista. A transformação dos modelos de dados dos sistemas para o modelo CIM, se deu através do uso de XSLT(EXtensible Stylesheet Language), que permite converter um determinado modelo, no padrão XML, em outro, através de sucessivas execuções de transformação.
Apesar da utilização desta abordagem ser usual, fazer tal mapeamento e transformação é uma tarefa que demanda a conversão de cada registro, sempre que utilizado, como também, alterações nos sistemas integrados para que tenham conhecimento um dos outros. Delega-se aos conectores, uma custosa função de transformação, podendo tornar o processo lento. Webservices foram usados para permitir o acesso às funcionalidades dos sistemas, porém, esta proposta requer que tanto do lado dos conectores, quanto do lado do barramento, tenham servidores de aplicação para atender/fornecer estas funcionalidades. O barramento também possui a tarefa de manter os endereços dos Webservices dos conectores, para permitir o biding e a chamada remota quando demandado.
Lendak et al.(2010) eVarga et al.(2011) propõem a utilização de um Web Service RESTful, intitulado RESTful WS-GDA, que encapsula o padrão IEC 61970-403 Generic Data Access - GDA. Esta especificação para o modelo CIM, permite, segundo os autores, que um cliente possa acessar dados mantidos por outro componente (ex.um aplicativo
CAPÍTULO 2. REVISÃO DE LITERATURA
ou banco de dados) ou sistema, sem qualquer conhecimento da lógica ou do esquema utilizado para o armazenamento de dados internos para quem utiliza o modelo IEC 61970 (IEC,2008). A Figura2.12ilustra um exemplo de aplicação do RESTful WS-GDA no fluxo de integração entre os sistemas que gerenciamento de falha, comuns ao setor elétrico.
Figura 2.12 Fault solving use case’s integration line (Varga et al.,2011)
As propostas deLendak et al.(2010) eVarga et al.(2011), tratam de uma outra forma de estender o modelo CIM, utilizando um ESB (do Inglês, Enterprise Service Bus), para permitir a integração de dados, exclusivamente neste formato (CIM) para os sistemas envolvidos. Demonstra-se assim, uma outra maneira de permitir a integração de dados de sistemas de gerenciamento de energia.
Por fim,Junior(2006) propõe um modelo de integração de dados entre os modelos IEC 61850 e 61970, para possibilitar a troca de dados entre os sistemas de controle da subestação (SAS) e os sistemas de um centro de controle (EMS). Desta maneira, permite-se que a topologia de uma determinada subestação possa ser conhecida pelo EMS/SCADA. A Figura2.13ilustra um protótipo que foi desenvolvido porJunior(2006) para provar a integração dos modelos IEC 61850 e 61970.
Ressalta-se que os respectivos modelos do CIM da proposta de Junior (2006), já devem ser utilizados pelos aplicativos envolvidos, ou seja, a integração só pode ser efetiva para os sistemas que já usam estes padrões.
2.4
Discussões
As propostas apresentadas na Seção anterior, possuem diversos pontos em comum e que tratam, de maneira geral, da integração de dados entre sistemas do setor elétrico, através de uma representação única. A Tabela2.2, ilustra outros pontos em comum e diferenças entre estes trabalhos relacionados, que servirão de comparativo com a proposta desta dissertação a ser apresentada no Capítulo3.
2.4. DISCUSSÕES
Figura 2.13 Protótipo implementado para integração (Junior,2006)
CAPÍTULO 2. REVISÃO DE LITERATURA
A solução proposta nesta dissertação, Capítulo3, apresentará um conjunto de serviços sensíveis a contexto que possibilitarão a troca de informações relevantes (negócio) entre os sistemas, sem o uso integral do modelo CIM, como emJunior(2006);Lendak et al.
(2010);Varga et al.(2011). Também não será necessário a implementação individual de conectores para cada sistema envolvido, como emPenin et al.(2012).
Nenhum dos trabalhos relacionados apresentados utilizam sensibilidade a contexto, como também, não existem integrações de sistemas do ponto de vista de negócio. A maioria não é middleware, porém utilizam serviços e infraestrutura que podem ser classificados como tal. Um ponto em comum a quase todos os trabalhos aqui relacionados, é a utilização de Web services para viabilizar a interoperação entre os sistemas.
2.5
Considerações Finais
Este capítulo apresentou os trabalhos relacionados ao tema desta dissertação e traçou um comparativo entre as propostas. Neste comparativo, observou-se que algumas das propostas possuem pontos em comum. Entretanto, nenhum dos trabalhos utiliza a sensibilidade a contexto e nem propõem uma integração de sistemas do setor elétrico com vistas à eficiência e à segurança da operação do negócio que estes os sistemas controlam. O Capítulo3a seguir, apresenta a proposta de uma arquitetura-modelo de um middleware sensível a contexto para integrar sistemas de gerenciamento de energia elétrica.
3
Modelo de Middleware para Integração
Sensível a Contexto
Viver é isto: ficar se equilibrando o tempo todo, entre escolhas e consequências. —JEAN-PAUL SARTRE (Filósofo)
Este capítulo apresenta um modelo de arquitetura para um middleware de integração sensível a contexto de sistemas de gerenciamento de energia elétrica, organizado de forma a prover serviços relativos a contexto, além de outros serviços comuns. Na Seção3.1são apresentados os requisitos e o escopo do projeto, que estão relacionados aos problemas já citados na Seção1.2. Na Seção3.2é apresentada a modelagem utilizada para definir as informações contextuais. A Seção3.3apresenta a arquitetura do middleware. Por fim, a Seção3.4explica o funcionamento de todos os serviços que o compõem.
3.1
Especificação de Requisitos
Com a especificação de requisitos, permite-se descrever as funções que um sistema deverá desempenhar para atender determinadas necessidades, como também, descrever as restrições às quais este sistema, ou seu processo de desenvolvimento, está sujeito (Sommerville,2007).
A Figura 3.1 apresenta um diagrama de casos de uso que especifica o escopo do projeto atendido pelo middleware para integração sensível a contexto. São identificados os atores envolvidos e os casos de uso que possibilitam a especificação dos requisitos funcionais.
CAPÍTULO 3. MODELO DE MIDDLEWARE PARA INTEGRAÇÃO SENSÍVEL A CONTEXTO
Figura 3.1 Diagrama de casos de uso utilizados no escopo do projeto
Os atores apresentados na Figura3.1representam sistemas legados que fazem parte do escopo da integração sensível a contexto proposta.
O System A, representa um sistema responsável pelo planejamento das intervenções operativas, exercido pelas equipes da pré-operação de uma empresa do setor de elétrico. O sistema SCADA, é responsável pelo monitoramento, em tempo real, do estado operativo dos equipamentos e funções de transmissão e geração de energia elétrica. O System B, representa o sistema responsável pelo registro das ocorrências (ex. o motivo de um desligamento ter ocorrido) que é exercido pelas equipes de pós-operação. Os requisitos funcionais abaixo, apresentam suas funções essenciais e qual tipo de informação é obtida a partir de sua utilização.
• RF001 - Obter Bloqueios : permite saber se um equipamento está bloqueado; • RF002 - Informar Desligamento : notificar quais equipamentos sofreram um
desligamento;
• RF003 - Finalizar Desligamento : notificar quais equipamentos foram normaliza-dos;
• RF004 - Informar Liberação Programada : notificar uma liberação programada para um equipamento;
3.2. MODELAGEM CONTEXTUAL
• RF005 - Informar Normalização Programada : notificar uma normalização progra-mada para um equipamento.
Ressalta-se que todas as empresas do setor de transmissão e geração de energia elétrica, seguem as normas e procedimentos de rede estabelecidos pelo ONS1(Operador Nacional do Sistema), para exercer estas funcionalidades de cada um dos sistemas envolvidos.
Porém, estes sistemas não possuem integração automática, ou seja, as funcionalida-des/operações apresentadas no diagrama de casos de uso, são exercidas manualmente pelos usuários, através de consultas em arquivos de LOG, de formulários impressos ou consultas às telas dos sistemas envolvidos, para reunir informações que serão utilizadas na identificação de um contexto, neste caso, inferência baseada na experiência do usuário e relativo aos eventos detectados (ex. desligamento, normalização de equipamentos).
Portanto, esta dissertação propõe uma arquitetura de middleware que poderá servir de modelo de referência para a maioria das empresas do setor, provendo uma integração sensível a contexto de sistemas legados ou de novos sistemas, responsáveis pelo geren-ciamento da transmissão de energia elétrica, para inferência automática de contextos relacionados aos eventos diários, comuns às empresas deste setor.
Segue-se a modelagem contextual utilizada para definir as entidades e elementos contextuais, que serão utilizados na definição dos contextos oferecidos pelos serviços do middleware.
3.2
Modelagem Contextual
SegundoVieira et al.(2009), modelos de contexto representam quais informações con-textuais devem ser consideradas em um domínio ou aplicação e como essas informações se relacionam ao comportamento do sistema. Modelos de contexto, na maioria das vezes, enumeram os conceitos de um domínio considerados como contexto. Estes contextos estruturam entidades de um domínio e indicam suas características. Entretanto, apenas esta enumeração de elementos não fornece a noção da dinâmica do contexto.
Para modelar o comportamento dinâmico de contextos, adotou-se grafos contextuais, permitindo-se identificar a influência dos elementos contextuais sobre o comportamento do middleware proposto (Vieira et al.,2009). A Figura3.2, apresenta um grafo contextual que ilustra o raciocínio utilizado na identificação de um contexto (ex. tipo de um desligamento). O nó CE1 (“equipamento.instalação2”) possui uma condição associada
CAPÍTULO 3. MODELO DE MIDDLEWARE PARA INTEGRAÇÃO SENSÍVEL A CONTEXTO
que verifica se a segunda instalação do equipamento foi informada no desligamento. Há dois caminhos possíveis nesse caso: vazio ou não. Se estiver vazio, o grafo segue para a ação “É um desligamento parcial lado 1” e encerra o grafo no nó de recombinação R1. No caso de ter sido informada a segunda instalação, o grafo segue para o nó CE2 (“equipamento.instalação1”), que também possui uma verificação se a primeira instalação do equipamento foi informada. Caso a primeira instalação tenha sido fornecida, o grafo segue para a ação “É um desligamento total lados 1 e 2” e finaliza o grafo no nó de recombinação R1. Se não existir a primeira instalação, o grafo segue para a ação “É um desligamento parcial lado 1” e finaliza a execução no nó de recombinação R1. No ApêndiceA, estão ilustrados todos os grafos contextuais que modelam o comportamento do gerenciador de contextos do middleware e que estão relacionados aos requisitos já apresentados.
Figura 3.2 Grafo contextual - Identificando o tipo de um desligamento
Para permitir a execução e o dinamismo modelado no grafo apresentado na Figura3.2, adotou-se o uso de regras de produção para a inferência de contextos (Amaral,2011). A Figura3.3apresenta o modelo de contexto, baseado em UML, que define as entidades e elementos contextuais utilizados neste trabalho.
• Equipamento - equipamentos de uma instalação ou função de transmissão status - estado operativo do equipamento (ex. 1 - ligado, 0 - desligado); instalação 1 e instalação 2 - localização da instalação dentro do BAY (Estruturas físicas onde ficam os equipamentos);
3.2. MODELAGEM CONTEXTUAL
Figura 3.3 Modelo de informações contextuais
• SAGE - sistema SCADA que monitora o estado operativo dos equipamentos TAG - anotações relativas ao estado do equipamento (ex. DESLIGOU, DESLI-GOU LADO);
• Bloqueio- bloqueio de um equipamento quando tem sua função impedida Data - data do bloqueio;
Hora - hora do bloqueio;
Número Autorização - número de autorização do impedimento quando plane-jado;
• Desligamento - dados relativos ao desligamento de um equipamento Data - data do desligamento;
Hora - hora do desligamento;
• Normalização - dados relativos à normalização de um equipamento Data - data da normalização;
Hora - hora da normalização;
• Liberação programada - dados relativos a um desligamento planejado Equipamentos a Impedir - lista de equipamentos que serão impedidos;
CAPÍTULO 3. MODELO DE MIDDLEWARE PARA INTEGRAÇÃO SENSÍVEL A CONTEXTO
Indicador com desligamento - indicar se o impedimento vai desligar o equipa-mento;
Indicador é um disjuntor - indicar se o equipamento é um disjuntor;
• Normalização programada - dados relativos a uma normalização planejada Equipamentos a Impedir - lista de equipamentos que serão impedidos;
Indicador com desligamento - indicar se a normalização vai desligar o equipa-mento;
Indicador é um disjuntor - indicar se o equipamento é um disjuntor.
A associação entre os elementos contextuais apresentados na Figura3.3, resultaram na identificação de (05) cinco focos apresentados abaixo. Desta maneira, quando o foco muda um novo contexto é instanciado para usuários e papeis distintos.
• Foco: Identificar Bloqueio Usuário: Operador
Papel: Operador da Pré Operação
• Foco: Notificar Desligamento Usuário: Operador
Papel: Operador de Tempo Real
• Foco: Finalizar Desligamento Usuário: Operador
Papel: Operador de Tempo Real • Foco: Informar Liberação Programada
Usuário: Operador
Papel: Operador da Pós Operação
• Foco: Informar Normalização Programada Usuário: Operador
Papel: Operador da Pós Operação
A proposta de arquitetura do middleware para atender aos requisitos funcionais apresentados na seção3.1é apresentada a seguir.
3.3. ARQUITETURA
3.3
Arquitetura
Na Seção2.2.3foi apresentado um modelo de referência de arquitetura de middleware para computação pervasiva proposto por Raychoudhury et al.(2013). Esta proposta foi utilizada como base para a organização e definição da arquitetura, como também, a implementação dos principais serviços desenvolvidos para o middleware proposto nesta dissertação. A Figura3.4apresenta o modelo da arquitetura do middleware, para atender aos requisitos e o escopo do projeto, apresentados na seção3.1.
Figura 3.4 Arquitetura de referência do modelo de middleware proposto
Seguindo o modelo de referência citado, a arquitetura do middleware fornece serviços responsáveis pelo gerenciamento (Context Management Service - aquisição, modelagem e raciocínio) e notificação de contexto ( Context Notification Service), além de serviços auxiliares (Real Time Event Monitor e UUID Service).
Todos os serviços do middleware são especificados como Web Services (WS) no padrão SOAP (Simple Object Access Protocol). ParaBelqasmi et al.(2012), a utilização das duas abordagens mais comuns para implementação de Web Services, ou seja, SOAP ou RESTful, oferecem as mesmas funcionalidades. A decisão de uso está estritamente relacionada ao escopo e requisitos das aplicações envolvidas.
Adotou-se como padrão a interface de publicação dos contratos via WS-API (API - Application Programming Interfaces) descritas em WSDL (Web Services Description Language), uma linguagem baseada em XML utilizada para descrever a funcionalidade de Web Services. Desta forma, utilizando-se uma tecnologia já bastante difundida no mercado, garante-se a simples e minimamente invasiva maneira de utilizar os serviços
CAPÍTULO 3. MODELO DE MIDDLEWARE PARA INTEGRAÇÃO SENSÍVEL A CONTEXTO
oferecidos pelo middleware proposto. O trecho de código abaixo (Código Fonte 3.1, exemplifica um contrato existente para o serviço Context Notification Service.
Código Fonte 3.1 Exemplo do WSDL do Context Notification Service
< ? xml v e r s i o n = " 1 . 0 " e n c o d i n g = "UTF−8" ? > < w s d l : d e f i n i t i o n s . . . t a r g e t N a m e s p a c e = " h t t p : / / c o n t e x t . c i n . u f p e . b r " . . . < schema t a r g e t N a m e s p a c e = " h t t p : / / c o n t e x t . c i n . u f p e . b r " . . . > < e l e m e n t name= " i n f o r m a r L i b e r a c a o P r o g r a m a d a " > < c o m p l e x T y p e > < s e q u e n c e > < e l e m e n t name= " m s g L i b e r a c a o " t y p e = " x s d : s t r i n g " / > < / s e q u e n c e > < / c o m p l e x T y p e > < / e l e m e n t > < e l e m e n t name= " i n f o r m a r L i b e r a c a o P r o g r a m a d a R e s p o n s e " > < c o m p l e x T y p e / > < / e l e m e n t > . . .
A adoção de Web services é motivada, principalmente, pela capacidade de publicar os serviços do middleware de forma independente da plataforma tecnológica adotada. Devido a inexistência de um middleware antes dos sistemas de software existentes, a integração destes sistemas legados deve ser feita através de Wrappers, que são pequenas peças de software desenvolvidas para serem acopladas a tais sistemas, permitindo que acessem as API do middleware. Novos sistemas (aplicações) não precisam de Wrappers, pois podem ser programados diretamente para as API já publicadas, no caso, Web services.
3.4
Serviços do Middleware
Os serviços do middleware foram agrupados de maneira a dar maior flexibilidade de uso, como também, estão relacionados a um determinado foco. Sendo assim, existem os serviços principais Context Management Service e Context Notification Service respon-sáveis, respectivamente, pelo gerenciamento e notificação de contextos, como também os serviços auxiliares Real Time Event Monitor Service e UUID Service, responsáveis, respectivamente, pelo monitoramento dos arquivos de alarme do SCADA e pelo mapea-mento em um padrão único dos identificadores dos mesmos equipamapea-mentos dos sistemas envolvidos.
3.4. SERVIÇOS DO MIDDLEWARE
3.4.1
Context Management Service
O serviço Context Management Service processa contexto, adotando o padrão de modela-gem focada no domínio (do Inglês, Domain-focused modelling) para a representação do conhecimento (Bettini et al.,2010). Para permitir uma maior flexibilidade, foi adotado o processamento de eventos complexos (do Inglês, Complex Event Processing - CEP), como motor de regras de contexto (Amaral,2011). Assim sendo, regras de produção podem ser criadas, inclusive em tempo real, com suporte a execução de eventos (Badii et al.,2010). Foi utilizada a engine JBoss Drools2para a criação das regras de contexto que são inferidos (Figura3.5). Isto possibilita a manutenção e criação de novas regras sem que seja necessário recompilar o código fonte do projeto, desde que estejam de acordo com o escopo, entidades e elementos contextuais já definidos.
Figura 3.5 Arquitetura do Serviço de Gerenciamento de Contexto com Drools
A Figura 3.6 apresenta um exemplo de uma regra especificada para identificar o contexto de um desligamento de uma linha de transmissão. Um conjunto de doze (12) regras foram criadas para atender os requisitos já apresentados, automatizando assim a inferência de contextos relacionados aos eventos mapeados. As regras estão organizadas em arquivos com extensão (.drl) e são lidas e interpretadas a cada vez que um contexto for processado.
Quando o método para processar contexto (processarRegras) é acionado , são utili-zados como argumento o objeto a ser processado (facts), como também, o arquivo de regras (rules), que será utilizado para inferir o contexto (Figura3.6). A engine Drools procura o padrão correspondente (when) e executa as ações que estão definidas (actions) (Figura3.5). A Tabela3.1apresenta todas as regras de contexto utilizadas para a inferên-cia de contextos relacionados a cada tipo de evento e suas especificações são encontradas
CAPÍTULO 3. MODELO DE MIDDLEWARE PARA INTEGRAÇÃO SENSÍVEL A CONTEXTO
Figura 3.6 Exemplo de uma regra de contexto utilizando Drools
no ApêndiceA.
3.4.2
Context Notification Service
O serviço Context Notification Service (Figura3.7) é responsável por gerenciar e publicar mensagens com as informações contextuais processadas pelo Context Management Service. Qualquer informação contextual é trocada entre as partes por meio de uma tecnologia tipo publish/subscribe (ex. Java Message Service-JMS).
Figura 3.7 Arquitetura do serviço de mensagens
Todas as mensagens utilizam o formato XML e possuem os atributos comuns relacio-nados ao escopo do projeto, oriundos da integração entre os sistemas (Figura3.8). Isto permite que seu conteúdo possa ser utilizado para o registro automático de ocorrências em outros sistemas, ou apenas sua exibição para os interessados na informação. Também existe um campo que traz uma lista de contextos inferidos pelo Context Management Service, para cada tipo de evento tratado: bloqueios, desligamentos, normalizações, liberações e normalizações programadas.
Como parte da infraestrutura desta funcionalidade, adotou-se um servidor de
3.4. SERVIÇOS DO MIDDLEWARE
CAPÍTULO 3. MODELO DE MIDDLEWARE PARA INTEGRAÇÃO SENSÍVEL A CONTEXTO
Figura 3.8 Exemplo de mensagem XML
3.4. SERVIÇOS DO MIDDLEWARE
gens gratuito, Apache ActiveMQ3, configurado para garantir a entrega e persistência de todas as mensagens contextuais geradas pelo serviço de gerenciamento de contexto para os participantes interessados.
A utilização do serviço do middleware para a troca de mensagens não está condicio-nada ao uso exclusivo do gerenciador de mensagens adotado, ou seja, é possível utilizar qualquer outro gerenciador padrão de mercado (ex. JBoss, IBM Websphere MQ), que atenda às especificações do padrão JMS 1.14.
3.4.3
UUID Service
O serviço UUID Service converte para um formato de identificador único (UUID – Universally Unique Identifier), segundo o modelo CIM (IEC 61970-301), os diferentes ID de um mesmo equipamento encontrados nos sistemas a serem integrados (ex. um disjuntor tem ID=xxx em um sistema A e ID=yyy em um sistema B).
Adotou-se esta estratégia em detrimento do uso do modelo CIM por completo, pois este trata da troca de dados do estado operativo dos equipamentos, sem possuir até o presente momento, uma extensão que permita o uso dos dados de negócio para integração. A Figura3.9exemplifica como ocorre codificação e decodificação de um ID local de um sistema para o formato único UUID.
Figura 3.9 Funcionamento do UUID Service
Antes que o System A envie informações para o middleware, é necessário codificar o ID local do equipamento utilizado para o formato único (UUID), usando o método encode(idLocal, sistema)do UUID Service. Quando o System B demonstra interesse nessa informação enviada pelo System A, a rotina inversa é executada, desta vez por meio do uso do método decode(UUID, Sistema). Desta forma o UUID Service devolverá o ID
3http://activemq.apache.org/
