jonysberg peixoto quintino‡… · de gestão e supervisão para planejar e controlar a geração,...

Middleware Sensível a Contexto para Integração deSistemas de Gerenciamento de Energia Elétrica

Por

Jonysberg Peixoto Quintino

Dissertação de Mestrado

Universidade Federal de Pernambuco

[email protected]

www.cin.ufpe.br/~posgraduacao

Recife, Fevereiro/2014

www.cin.ufpe.br/~posgraduacao

Universidade Federal de Pernambuco

Centro de InformáticaPós-graduação em Ciência da Computação

Jonysberg Peixoto Quintino

Middleware Sensível a Contexto para Integração deSistemas 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

Recife, Fevereiro/2014

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, Carlos André Guimarães (orientador). II. Título.

004.36 (22. ed.) MEI 2014-71

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


_______________________________________________

Prof. Carlos André Guimarães Ferraz


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;

A todos que me deram todo o apoio necessário para chegar

nesta importante conquista.

Agradecimentos

A Deus, por permitir que eu tenha saúde, força e coragem para enfrentar todas asdiversidades e conquistar tudo que desejo;

A minha amada mãe, Maria Cenilda, que mesmo diante de todas as dificuldadesencontradas e que não foram poucas, conseguiu nos educar com valores sólidos, quemoldaram 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 nossossonhos, e que permitiu minha dedicação ao mestrado e especialmente, que me deu omaior dos presentes da vida, o nosso filho Caio, que tanto amo e com quem aprendotodos 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 detodas as caminhadas;

Ao grande amigo, Ismar Kaufman, pela confiança e motivação que me encorajaram aconquistar um antigo sonho de fazer um mestrado;

Ao meu orientador, Carlos Ferraz, que só me conheceu no primeiro dia de aula masque 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é eque me serviram de terapia intelectual, educacional, motivacional e psicológica. Comoeu 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 CarlosNascimento;

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 JuliermeAraújo que enfrentaram todos os desafios sem nunca desanimar;

Aos professores Abel Guilhermino Filho, Patrícia Tedesco e Renata Souza peladisponibilidade e paciência nos momentos em que precisei tirar dúvidas;

Aos amigos Gláucia Campos, Ioram Sette e Marcelo Fernandes pela valiosa ajuda emtodos os desafios enfrentados juntos ao longo das disciplinas, seminários e projetos.

Enfim, agradeço a todas as pessoas que direta ou indiretamente tornaram possível aelaboração deste trabalho, muito obrigado.

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

da minha vida;

e habitarei na casa do Senhor por longos dias.

—LIVRO DOS SALMOS (Salmos 23:1-6)

Resumo

Há décadas, os concessionários em todo o mundo contam com sistemas informatizadosde gestão e supervisão para planejar e controlar a geração, transmissão e distribuição deenergia. Tais sistemas fazem, entre outras coisas, o controle em tempo real de todos osequipamentos, ajudando os operadores destes sistemas a assimilar o que está acontecendona 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çãode informações que são exibidas por diferentes sistemas. Foram encontrados trabalhos naliteratura que tratam de várias formas, com aspectos relacionados à integração de dadosentre sistemas do setor elétrico porém, até o momento da escrita desta dissertação, nãoforam encontrados trabalhos que utilizassem um middleware sensível ao contexto paraintegrar sistemas deste setor.

Este trabalho apresenta um modelo de arquitetura de middleware para integraçãosensível ao contexto de sistemas de gerenciamento de energia elétrica, provendo para osusuários informações relevantes, considerando que relevância depende das tarefas que ousuário está executando.

Um protótipo foi desenvolvido para integrar um sistema de controle de supervisão eaquisição de dados (SCADA), que monitora a rede de energia em tempo real, e outrasaplicaçõ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 manualmentepelos operadores, foi alcançado um percentual de acerto significativo (100%) na inferênciados contextos para as ocorrências forçadas (sem planejamento) e não forçadas (complanejamento). Com base nestes resultados, pode-se afirmar que o modelo proposto nestetrabalho, permite utilizar um middleware sensível ao contexto que possibilite integraralguns dos sistemas utilizados nos modernos centros de controle das empresas de energiaelétrica, aumentando a eficácia e incrementando a segurança dos procedimentos deplanejamento e execução das manutenções operativas.

Palavras-chave: Middleware. Sensibilidade a Contexto. SCADA. Sistemas de Gerenci-amento de Energia. Transmissão de Energia Elétrica

Abstract

For decades now, utilities throughout the World rely on energy-management systemsand supervisory computer systems to plan and control the generation, transmission, anddistribution of power. Such systems, among other things, control in real time all power-generating equipment, and monitor the performance of the transmission system, helpingsystem operators assimilate what is happening in the power network. In general, thesesystems are not automatically integrated, making harder the work of the control centeroperators.

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 relevantinformation, considering that relevance depends on the task the user is performing.

A prototype was developed to integrate a supervisory system (SCADA – supervisorycontrol and data acquisition) and other systems that are used to plan, manage, andanalyze electric-power events. It was possible to simulate the operational routine of acontrol center to test the prototype. Comparing the middleware test results with whathas been done manually by operators, a significant percentage of accuracy in the contextinferences for forced and not forced occurrences has been reached. The evidence fromthis study suggests that the proposed model allows integrating the systems used in moderncontrol centers of power companies, increasing the effectiveness, and enhancing safetyprocedures for planning and execution of operational maintenance.

Keywords: Middleware. Context-Awareness. SCADA. Energy-Management System.Electric Power Transmission

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

OMS Outage Management System

SIN Sistema Interligado Nacional

CTEEP Companhia de Transmissão de Energia Elétrica Paulista

Lista de Códigos Fonte

3.1 Exemplo do WSDL do Context Notification Service . . . . . . . . . . . 46

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.2 Diagrama de componentes do middleware . . . . . . . . . . . . . . . . 59

4.3 Cenário 1 sem middleware . . . . . . . . . . . . . . . . . . . . . . . . 60

4.4 Exemplo de um Log de alarmes do SCADA . . . . . . . . . . . . . . . 60

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.11 Desligamentos de um período no simulador (S_SL2) . . . . . . . . . . 65



4.14 Normalizações (a) e eventos relacionados (b) de um período no simuladorS_SL2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67


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 simuladorS_SL2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70


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 nosimulador S_SL2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.1 Diagrama de implantação: Ambiente utilizado na execução dos serviçose 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.10 Regra - Ocorrência não forçada e com desligamento . . . . . . . . . . . 101

A.11 Regra - Ocorrência não forçada e sem desligamento . . . . . . . . . . . 102A.12 Regra - Liberação realizada após normalização . . . . . . . . . . . . . 102A.13 Regra - Liberação sem registro de TAG no SAGE . . . . . . . . . . . . 102A.14 Grafo - Informando normalização programada . . . . . . . . . . . . . . 103A.15 Regra - Liberação sem registro de TAG no SAGE . . . . . . . . . . . . 103

Lista de Tabelas

2.1 Técnicas para modelagem de contexto. Adaptado de (Raychoudhuryet al., 2013) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.2 Comparativo entre os trabalhos relacionados . . . . . . . . . . . . . . . 37

3.1 Regras utilizadas para inferência de contextos . . . . . . . . . . . . . . 493.2 Comparativo entre os trabalhos relacionados e o middleware proposto . 54

5.1 Quantidade de eventos registrados no LOG do SCADA . . . . . . . . . 795.2 Ocorrências forçadas: Campos preenchidos automaticamente pelo mid-

dleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825.3 Ocorrências não forçadas: Campos preenchidos automaticamente pelo

middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Sumário

1 Introdução 171.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 393.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

3.4.4 Real Time Event Monitor Service . . . . . . . . . . . . . . . . 52

3.5 Comparação com Trabalhos Relacionados . . . . . . . . . . . . . . . . 54


4 Cenários de Implementação 574.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


5 Resultados e Análises 755.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ãoForçadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84


6 Conclusão e Trabalhos Futuros 876.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 97A.1 Foco: Identificando Bloqueio de Equipamento . . . . . . . . . . . . . . 97

A.2 Foco: Notificando Desligamentos . . . . . . . . . . . . . . . . . . . . 97

A.3 Foco: Finalizando Desligamentos . . . . . . . . . . . . . . . . . . . . 99

A.4 Foco: Informando Liberação Programada . . . . . . . . . . . . . . . . 101

A.5 Foco: Informando Normalização Programada . . . . . . . . . . . . . . 101

1Introduçã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çãode energia (Masiello, 1985). Tais sistemas fazem, entre outras coisas, o controle emtempo real de todos os equipamentos de geração, transmissão de energia e monitoramentodo desempenho do sistema como um todo, ajudando os operadores do sistema a assimilaro que está acontecendo na rede de energia.

No Brasil, a resolução Normativa Aneel 270/2007 (ANEEL, 2007), estabelece asdisposiçõ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 serviços, exigindo-se um esforço dos sistemas de informaçãodas empresas de transmissão de energia, quanto à necessidade de integração de seusdiversos e sofisticados processos de gestão, que atualmente não são integrados.

Tais sistemas, quando utilizados de forma integrada, aumentam potencialmente osseus benefícios. No entanto, a falta deste tipo de integração, automática, torna mais difícilo 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

Em Yan et al. (2013) é apresentada uma visão, originalmente proposta por Zhang et al.

(2010), de centros de controle do futuro, também chamados de smart control centers, onde

17

CAPÍTULO 1. INTRODUÇÃO

uma de suas características-chave é o monitoramento online centrado no ser humano. Paratanto, as funções de monitoramento da próxima geração devem fornecer aos operadoresinformações úteis em vez de apenas dados não processados. Estas funções devemempregar técnicas de visualização com o objetivo de ajudar cada operador a digeririnformaçã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/relevantesquanto a um dado contexto para serem apresentadas aos operadores.

Por exemplo, os dados sobre o identificador de um equipamento programado paramanutenção e a data desta manutenção, ambos oriundos do sistema de programaçãode intervenções, e o registro (naquela data) do desligamento do mesmo equipamentomonitorado 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, osatuais centros de controle das empresas de energia, possuem um funcionamento reativo.Ou seja, exige-se dos operadores um constante acompanhamento de telas de diferentessistemas, que monitoram o estado operativo dos equipamentos e suas funções, para quepossam tomar decisões acerca de um grande conjunto de eventos que acontecem aomesmo tempo.

Nos centros de controle de gerenciamento de energia existem sistemas especializa-dos como o SCADA, categoria de sistemas que permitem o monitoramento do estadooperativo de um equipamento em tempo real. Há também sistemas responsáveis peloplanejamento 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 verificações e intervençõesmanuais 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 otempo de parada. Também é necessário que os operadores redigitem dados de um sistemapara outro, a fim de consolidar informações sobre o estado operativo de um equipamento,

18

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 podeacarretar em falhas devido a complexidade e quantidade de eventos diários em um centrode controle.

Ao analisar dados de 2011 e 2012 de uma grande empresa de transmissão de energiaelétrica, com mais de 12 mil Km de linhas de transmissão, descobriu-se um númerosignificativo de solicitações de manutenção canceladas devido a erros de digitação ouinconsistências causadas pela falta de informação adequada que caracterizasse o contexto.A análise mostrou ainda, que muitos conjuntos de dados provenientes de diferentessistemas 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 tecnologiasdistintas, constituem um grande desafio. Sem alterar suas lógicas de negócio, será possívelutilizar informações contextuais relevantes para os operadores e que possam incrementara 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 aintegração sensível a contexto de sistemas de gerenciamento de energia. Pretende-sepermitir que o operadores possuam informações mais relevantes acerca do contexto doseventos e seus relacionamentos, para que, baseados em informações contextuais, possamser 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 permitasimular a rotina operacional de um centro de controle através da integração sensívelao contexto entre sistemas legados ou de novos sistemas que são comuns ao setorde energia elétrica;

2. Realizar uma integração entre os sistemas comuns às empresas deste setor e quesão utilizados no monitoramento dos equipamentos, assim como, no planejamento

19

CAPÍTULO 1. INTRODUÇÃO

das manutenções. Entre os exemplos deste sistemas estão um sistema SCADA, umsistema 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çõescontextuais relacionadas aos eventos monitorados, permitindo assim, uma possíveldiminuiçã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 quesã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 atuamnas áreas de geração, transmissão, distribuição e consumo de energia. Dentro de cadauma 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 consumode energia.

1.5 Contribuições Esperadas

Como resultado do trabalho apresentado por esta dissertação, destaca-se a criação de ummodelo de arquitetura de middleware para integração sensível ao contexto de sistemas degerenciamento 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 degerenciamento legados ou de novos sistemas, a exemplo dos sistemas de gerenciamentode energia das empresas deste setor, provendo informações mais relevantes aos seususuários.

1.6 Estrutura da Dissertação

A continuação desta dissertação está organizada em mais cinco capítulos. O Capítulo 2apresenta o referencial teórico encontrado na literatura com os principais conceitosrelacionados à pesquisa deste trabalho. O Capítulo 3 apresenta a proposta deste trabalho,

20

1.6. ESTRUTURA DA DISSERTAÇÃO

um modelo de arquitetura de um middleware para integração sensível a contexto desistemas de gerenciamento de energia elétrica. O Capítulo 4 apresenta uma prova deconceito do modelo proposto, através da implementação de um protótipo do middleware.O Capítulo 5 apresentada uma análise de resultados referentes aos testes executados noprotótipo. Por fim, o Capítulo 6 apresenta a conclusão e os trabalhos futuros que podemsurgir a partir desta pesquisa.

21

2Revisã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 principaisconceitos relacionados à aplicação de computação nos Sistemas Elétricos, Sensibilidade aContexto e Middleware, como também, trabalhos já propostos que utilizam alguns dessesconceitos 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érmicaconvencional). As dimensões continentais do Brasil exigem das concessionárias umesforço para suprir a crescente demanda por energia elétrica em todas as regiões. Emuma pesquisa publicada pela Empresa de Pesquisa Energética (EPE, 2013), vinculadaao 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(Figura 2.1).

Segundo Masiello (1985), há décadas empresas do setor de energia elétrica em todo omundo 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 informatizadosse torna imprescindível para gerenciar e supervisionar esta infraestrutura.

23

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

Para Varga et al. (2011), existem diversos sistemas especialistas para o setor elétrico eque podem estar interligados através de softwares e serviços que permitam algum tipo deinteroperaçã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 (Figura 2.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 setorelétrico de geração, transmissão e distribuição de energia. Dentre os principais, estão os

24

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 emcampo 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 detransmissão, transformadores, etc.), permitindo entre outras coisas, obter informaçõessobre 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 sobreo modelo da rede de distribuição, por exemplo, e assim, melhorar o gerenciamento defalhas, 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ãopossuindo 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 emmomentos 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êsdiferentes áreas de atuação: pré-operação, tempo real e pós-operação (Figura 2.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 paraviabilizar 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

25


(ex. tensão, carga e controle de frequência) da rede de energia elétrica, permitindoassim, manobras e ações quando mudanças nesses parâmetros ocorrem, ao passo quea pós-operação é responsável pela análise e registro de ocorrências, tais como falha deequipamento ou desligamentos de linhas de transmissão para que, em outras situaçõessemelhantes, os processos possam ser ajustados com as lições aprendidas com os eventosanteriores já registrados.

De acordo com Masiello (1985), existem sistemas que fazem, entre outras coisas, ocontrole em tempo real de todos os equipamentos de geração de energia e monitoramentodo desempenho do sistema de transmissão, ajudando os operadores do sistema de assimilaro que está acontecendo na rede de energia. Há também sistemas responsáveis pelasolicitação, liberação e normalização de impedimentos (com ou sem desligamento), comotambém pelo registro de fatos de inicialização, ocorrências e finalização para uma análisemais profunda dos acontecimentos. Grande parte destas atividades compreendem osprocedimentos de rede que normatizam a atuação das empresas do setor no Brasil e quesão estabelecidas pelo ONS (Operador Nacional do Sistema).

Ao longo das últimas décadas, muitos destes programas de computador e aplicaçõesde software foram desenvolvidos para exercer o controle da supervisão e aquisição dedados, registrar eventos, realizar análises estatísticas, prever o efeito das interrupçõespara melhorar a segurança do sistema, entre outras funções.

Atualmente, em consequência, as concessionárias usam uma grande variedade desistemas para monitorar e gerenciar seus equipamentos. Tais sistemas na maioria dasvezes, foram desenvolvidos em épocas e tecnologias distintas e que, em geral, nãopossuem algum tipo integração.

Entretanto, Zhang et al. (2010) afirma que a operação dos centros de controle temum funcionamento reativo, ou seja, os operadores precisam estar atentos aos eventosnormalmente registrados em telas com LOG dos sistemas de alarme, que demandam umintenso estado de atenção (Figura 2.4). Geralmente baseados na experiência profissionale 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 oseventos, descobrir se existe algum tipo de relacionamento entre eles e tomar decisõesbaseadas nesta interpretação, o que pode acarretar em falhas devido a complexidade equantidade de eventos diários em um centro de controle.

1http://www.ons.org.br/procedimentos/index.aspx

26

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ção 2.1 e Seção 2.1.2, a variedade e a he-terogeneidade de aplicações do setor elétrico demandam desafios comuns, inclusive parasistemas computacionais deste setor, ou seja, o desejo e a necessidade do compartilha-mento de dados e informações comuns que detalham o funcionamento dos equipamentose seus estados operativos (Khare et al., 2011).

Contudo, tal diversidade implica em muito esforço para integrar e utilizar uma grandequantidade de dados, que geralmente possuem formatos diferentes para a representaçãode 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 aintercomunicaçã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 empresasdo 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 domodelo 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 doscentros de controle, utilizando os sistemas EMS através de uma API (EMS-API) (IEC,

27


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 umalinguagem para descrevê-los, definindo uma terminologia, além de outras funcionalidades,que auxiliam o entendimento de seu uso. A Figura 2.5 apresenta um diagrama de pacotesdo modelo de referência com a representação das partes que compõem o domínio que opadrã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 pararepresentaçã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 deContexto, Sensibilidade a Contexto (do Inglês, Context Awareness) e Middleware Sensívela Contexto. Fundamenta-se as principais características que permitem a adaptação desistemas computacionais a contextos (situações) estabelecidos dinamicamente.

28

2.2. SENSIBILIDADE A CONTEXTO

2.2.1 Contexto

Diversas definições relacionadas a contexto são encontradas na literatura, entre as maisclássicas, Dey et al. (2001), definindo contexto como qualquer informação que caracterizeuma situação de uma entidade, podendo a entidade ser representada por uma pessoa, umlugar 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 certassituações, ações ou eventos.

A utilização de contexto, na computação, investiga o uso das informações presentesna interação entre pessoas e computadores, com o objetivo de ampliar a qualidade dacomunicação entre o ser humano e sistemas computacionais. Tais informações, por vezesdesconsideradas do processo de interação, são denominadas de informações contextuais,que contêm elementos contextuais (do Inglês, Contextual Element). Estas informaçõescontextuais podem ser utilizadas como fontes de conhecimento pelos sistemas (Vieiraet al., 2009). A Figura 2.6 ilustra um exemplo de um modelo contextual, suas entidades eelementos.

Figura 2.6 Modelo contextual e elementos contextuais

Estas entidades devem ser consideradas importantes para o usuário e para os sistemasque 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

29


sequência de ações, interações e o tipo de informações fornecidas ao usuários sem queseja explicitamente solicitado.

2.2.2 Sistemas Sensíveis ao Contexto

Um sistema é considerado sensível ao contexto (do Inglês, Context-aware System) se eleutiliza contexto para fornecer informações ou serviços relevantes, sendo que a relevânciadepende 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çõesditas tradicionais, ou seja, sem suporte ao contexto, está o fato de que as aplicaçõestradicionais levam em consideração apenas as informações e solicitações fornecidas pelosusuá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 acontexto.

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 (quetambém podem ser contexto) fornecidas pelos usuários, também são utilizadas aquelas in-formações armazenadas em bases de conhecimento contextuais, as informações inferidaspor meio de raciocínio (ex. lógica de primeira ordem) e, também, aquelas percebidas apartir do monitoramento do ambiente (ex. sensores). Estas informações obtidas de formanã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

30


necessidades e sem que o usuário perceba, adaptar suas interações e funcionalidades paramelhorar 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, quevão de simples modelos a complexos e sofisticados (Raychoudhury et al., 2013). ATabela 2.1 ilustra 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 emconjunto através de suas funcionalidades para produzir um resultado em comum. Ogrande desafio está em integrar tais aplicações, que foram desenvolvidas por empresasdiferentes, tecnologias e épocas distintas (Hohpe and Woolf, 2004). Existem diversasabordagens tecnológicas na literatura e no mercado, para possibilitar uma integraçãode sistemas computacionais, entre elas, o uso de um middleware. Para Coulouris et al.

(2011), middleware se aplica a uma camada de software que fornece uma abstração deprogramação, escondendo a heterogeneidade das redes, hardware, sistema operacionale linguagens de programação. A Figura 2.8 ilusta um exemplo da localização de ummiddleware.

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

31


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 osmuitos 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 secomunicam 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 decomunicaçã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 tecnologiase 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 umambiente inteligente com dispositivos embutidos de computação em rede, proporcionandoaos 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. Entrealgumas das clássicas referencias estão CORTEX (Veríssimo et al., 2002), Aura (Garlanet al., 2002), Gaia (Román et al., 2002) entre muitas outras, que apresentam diferentes

32


paradigmas na utilização desta abordagem, porém, nenhuma delas relacionadas ao setorde energia elétrica.

Raychoudhury et al. (2013) apresenta um modelo de referência com as principaiscaracterísticas básicas que devem ser implementas para o desenvolvimento de um mid-

dleware sensível a contexto (Figura 2.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 conjuntode serviços padrão e requisitos de suporte essenciais, que devem ser prestados por ummiddleware com esta característica. A organização de tais características e dos serviçossugeridos pelo modelo, não implicam sua total implementação, ou seja, é possívelcombinar os serviços para que melhor se adequem aos requisitos a serem atendidos nodesenvolvimento de um novo middleware sensível a contexto.

33


Ainda segundo Raychoudhury 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çãode contextos a partir de várias fontes (ex. sensores, atuadores, dispositivos virtuais,sistemas,etc.). O armazenamento de contextos se depara com o desafio de gerenciargrandes volumes de dados, como também, gerenciar o relacionamento contextual entreeles. A modelagem contextual permite utilizar diversas abordagens para a representaçãocontextual 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). Ainferência contextual refere-se a um processo de inferência de alto nível de informaçõesde 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 de Raychoudhury et al. (2013), servirá como base para a concepção de umaarquitetura-modelo do middleware proposto nesta dissertação e que será oportunamenteapresentada no Capítulo 3.

2.3 Trabalhos Relacionados

São encontradas na literatura diversas propostas e abordagens para utilização de mid-

dleware sensível a contexto, em diversas áreas da computação ubíqua e pervasiva, comoem Raychoudhury 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 andChuang (2003), entre diversos outros.

Entretanto, até o momento da escrita desta dissertação, não foram encontradas naliteratura propostas que tratassem exatamente do assunto relacionado a utilização deum middleware para integração sensível a contexto de sistemas de gerenciamento deenergia elétrica.

Porém, foram encontrados trabalhos que tratam de alguma forma, com aspectosrelacionados à 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çãopara a integração de dados de aplicações, utilizando o modelo CIM (do Inglês,Common

Information Model), através do uso de conectores (Figura 2.11).

A proposta de Penin et al. (2012) definiu uma arquitetura de barramento de comunica-ção (middleware), que implementa o modelo CIM, para padronizar a integração de dados

34

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 empresaEletropaulo.

Foram desenvolvidos conectores para viabilizar a comunicação entre estes aplicativose o barramento de serviços proposto. O barramento funciona como um redirecionadorde demandas de cálculos, delegado aos conectores de cada sistema especialista. Atransformação dos modelos de dados dos sistemas para o modelo CIM, se deu através douso de XSLT(EXtensible Stylesheet Language), que permite converter um determinadomodelo, 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, comotambém, alterações nos sistemas integrados para que tenham conhecimento um dosoutros. Delega-se aos conectores, uma custosa função de transformação, podendo tornaro processo lento. Webservices foram usados para permitir o acesso às funcionalidades dossistemas, porém, esta proposta requer que tanto do lado dos conectores, quanto do lado dobarramento, tenham servidores de aplicação para atender/fornecer estas funcionalidades.O barramento também possui a tarefa de manter os endereços dos Webservices dosconectores, para permitir o biding e a chamada remota quando demandado.

Lendak et al. (2010) e Varga 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

35


ou banco de dados) ou sistema, sem qualquer conhecimento da lógica ou do esquemautilizado para o armazenamento de dados internos para quem utiliza o modelo IEC61970 (IEC, 2008). A Figura 2.12 ilustra um exemplo de aplicação do RESTful WS-GDA

no fluxo de integração entre os sistemas que gerenciamento de falha, comuns ao setorelétrico.

Figura 2.12 Fault solving use case’s integration line (Varga et al., 2011)

As propostas de Lendak et al. (2010) e Varga et al. (2011), tratam de uma outra formade estender o modelo CIM, utilizando um ESB (do Inglês, Enterprise Service Bus), parapermitir a integração de dados, exclusivamente neste formato (CIM) para os sistemasenvolvidos. Demonstra-se assim, uma outra maneira de permitir a integração de dados desistemas de gerenciamento de energia.

Por fim, Junior (2006) propõe um modelo de integração de dados entre os modelosIEC 61850 e 61970, para possibilitar a troca de dados entre os sistemas de controleda 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 peloEMS/SCADA. A Figura 2.13 ilustra um protótipo que foi desenvolvido por Junior (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 efetivapara 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 quetratam, de maneira geral, da integração de dados entre sistemas do setor elétrico, atravésde uma representação única. A Tabela 2.2, ilustra outros pontos em comum e diferençasentre estes trabalhos relacionados, que servirão de comparativo com a proposta destadissertação a ser apresentada no Capítulo 3.

36

2.4. DISCUSSÕES

Figura 2.13 Protótipo implementado para integração (Junior, 2006)

Tabela 2.2 Comparativo entre os trabalhos relacionados

37


A solução proposta nesta dissertação, Capítulo 3, apresentará um conjunto de serviçossensíveis a contexto que possibilitarão a troca de informações relevantes (negócio) entreos sistemas, sem o uso integral do modelo CIM, como em Junior (2006); Lendak et al.

(2010); Varga et al. (2011). Também não será necessário a implementação individual deconectores para cada sistema envolvido, como em Penin 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. Amaioria não é middleware, porém utilizam serviços e infraestrutura que podem serclassificados 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çouum comparativo entre as propostas. Neste comparativo, observou-se que algumas daspropostas possuem pontos em comum. Entretanto, nenhum dos trabalhos utiliza asensibilidade a contexto e nem propõem uma integração de sistemas do setor elétrico comvistas à eficiência e à segurança da operação do negócio que estes os sistemas controlam.O Capítulo 3 a seguir, apresenta a proposta de uma arquitetura-modelo de um middleware

sensível a contexto para integrar sistemas de gerenciamento de energia elétrica.

38

3Modelo 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çãosensível a contexto de sistemas de gerenciamento de energia elétrica, organizado de formaa prover serviços relativos a contexto, além de outros serviços comuns. Na Seção 3.1 sãoapresentados os requisitos e o escopo do projeto, que estão relacionados aos problemas jácitados na Seção 1.2. Na Seção 3.2 é apresentada a modelagem utilizada para definir asinformações contextuais. A Seção 3.3 apresenta a arquitetura do middleware. Por fim, aSeção 3.4 explica 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 sistemadeverá desempenhar para atender determinadas necessidades, como também, descreveras 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 doprojeto atendido pelo middleware para integração sensível a contexto. São identificadosos atores envolvidos e os casos de uso que possibilitam a especificação dos requisitosfuncionais.

39

CAPÍTULO 3. MODELO DE MIDDLEWARE PARA INTEGRAÇÃO SENSÍVEL ACONTEXTO

Figura 3.1 Diagrama de casos de uso utilizados no escopo do projeto

Os atores apresentados na Figura 3.1 representam sistemas legados que fazem partedo escopo da integração sensível a contexto proposta.

O System A, representa um sistema responsável pelo planejamento das intervençõesoperativas, exercido pelas equipes da pré-operação de uma empresa do setor de elétrico. Osistema SCADA, é responsável pelo monitoramento, em tempo real, do estado operativodos 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 umdesligamento ter ocorrido) que é exercido pelas equipes de pós-operação. Os requisitosfuncionais abaixo, apresentam suas funções essenciais e qual tipo de informação é obtidaa partir de sua utilização.

• RF001 - Obter Bloqueios : permite saber se um equipamento está bloqueado;

• RF002 - Informar Desligamento : notificar quais equipamentos sofreram umdesligamento;

• RF003 - Finalizar Desligamento : notificar quais equipamentos foram normaliza-dos;

• RF004 - Informar Liberação Programada : notificar uma liberação programadapara um equipamento;

40

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 Nacionaldo 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 manualmentepelos usuários, através de consultas em arquivos de LOG, de formulários impressos ouconsultas às telas dos sistemas envolvidos, para reunir informações que serão utilizadasna identificação de um contexto, neste caso, inferência baseada na experiência do usuárioe relativo aos eventos detectados (ex. desligamento, normalização de equipamentos).

Portanto, esta dissertação propõe uma arquitetura de middleware que poderá servirde modelo de referência para a maioria das empresas do setor, provendo uma integraçãosensí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 contextosrelacionados aos eventos diários, comuns às empresas deste setor.

Segue-se a modelagem contextual utilizada para definir as entidades e elementoscontextuais, que serão utilizados na definição dos contextos oferecidos pelos serviços domiddleware.

3.2 Modelagem Contextual

Segundo Vieira 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çõesse relacionam ao comportamento do sistema. Modelos de contexto, na maioria das vezes,enumeram os conceitos de um domínio considerados como contexto. Estes contextosestruturam entidades de um domínio e indicam suas características. Entretanto, apenasesta 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 comportamentodo middleware proposto (Vieira et al., 2009). A Figura 3.2, apresenta um grafo contextualque ilustra o raciocínio utilizado na identificação de um contexto (ex. tipo de umdesligamento). O nó CE1 (“equipamento.instalação2”) possui uma condição associada

1http://www.ons.org.gr/procedimentos/index.aspx

41


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 paraa ação “É um desligamento parcial lado 1” e encerra o grafo no nó de recombinaçãoR1. 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çãodo equipamento foi informada. Caso a primeira instalação tenha sido fornecida, o grafosegue para a ação “É um desligamento total lados 1 e 2” e finaliza o grafo no nó derecombinaçã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. NoApêndice A, estão ilustrados todos os grafos contextuais que modelam o comportamentodo 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 Figura 3.2,adotou-se o uso de regras de produção para a inferência de contextos (Amaral, 2011). AFigura 3.3 apresenta o modelo de contexto, baseado em UML, que define as entidades eelementos 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 (Estruturasfísicas onde ficam os equipamentos);

42

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;

43


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 Figura 3.3, resultaramna identificação de (05) cinco focos apresentados abaixo. Desta maneira, quando o focomuda 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 funcionaisapresentados na seção 3.1 é apresentada a seguir.

44

3.3. ARQUITETURA

3.3 Arquitetura

Na Seção 2.2.3 foi apresentado um modelo de referência de arquitetura de middleware

para computação pervasiva proposto por Raychoudhury et al. (2013). Esta propostafoi utilizada como base para a organização e definição da arquitetura, como também, aimplementação dos principais serviços desenvolvidos para o middleware proposto nestadissertação. A Figura 3.4 apresenta o modelo da arquitetura do middleware, para atenderaos requisitos e o escopo do projeto, apresentados na seção 3.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çosresponsáveis pelo gerenciamento (Context Management Service - aquisição, modelageme raciocínio) e notificação de contexto ( Context Notification Service), além de serviçosauxiliares (Real Time Event Monitor e UUID Service).

Todos os serviços do middleware são especificados como Web Services (WS) nopadrão SOAP (Simple Object Access Protocol). Para Belqasmi et al. (2012), a utilizaçãodas duas abordagens mais comuns para implementação de Web Services, ou seja, SOAPou RESTful, oferecem as mesmas funcionalidades. A decisão de uso está estritamenterelacionada 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 funcionalidadede Web Services. Desta forma, utilizando-se uma tecnologia já bastante difundida nomercado, garante-se a simples e minimamente invasiva maneira de utilizar os serviços

45


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 fpe . 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 fpe . 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 ">

<complexType>< s e q u e n c e >

< e l e m e n t name=" msgLibe racao " t y p e =" x s d : s t r i n g " / >< / s e q u e n c e >

< / complexType>< / 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 ">

<complexType / >< / e l e m e n t >

. . .

A adoção de Web services é motivada, principalmente, pela capacidade de publicaros 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, aintegração destes sistemas legados deve ser feita através de Wrappers, que são pequenaspeças de software desenvolvidas para serem acopladas a tais sistemas, permitindo queacessem 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 deuso, como também, estão relacionados a um determinado foco. Sendo assim, existem osserviços principais Context Management Service e Context Notification Service respon-sáveis, respectivamente, pelo gerenciamento e notificação de contextos, como tambémos 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 equipamentos dos sistemasenvolvidos.

46

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 doconhecimento (Bettini et al., 2010). Para permitir uma maior flexibilidade, foi adotadoo processamento de eventos complexos (do Inglês, Complex Event Processing - CEP),como motor de regras de contexto (Amaral, 2011). Assim sendo, regras de produçãopodem ser criadas, inclusive em tempo real, com suporte a execução de eventos (Badiiet al., 2010). Foi utilizada a engine JBoss Drools2 para a criação das regras de contextoque são inferidos (Figura 3.5). Isto possibilita a manutenção e criação de novas regrassem que seja necessário recompilar o código fonte do projeto, desde que estejam deacordo 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 ocontexto 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 ainferência de contextos relacionados aos eventos mapeados. As regras estão organizadasem arquivos com extensão (.drl) e são lidas e interpretadas a cada vez que um contextofor 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 deregras (rules), que será utilizado para inferir o contexto (Figura 3.6). A engine Drools

procura o padrão correspondente (when) e executa as ações que estão definidas (actions)

(Figura 3.5). A Tabela 3.1 apresenta 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

2http://www.jboss.org/drools/

47


Figura 3.6 Exemplo de uma regra de contexto utilizando Drools

no Apêndice A.

3.4.2 Context Notification Service

O serviço Context Notification Service (Figura 3.7) é responsável por gerenciar e publicarmensagens com as informações contextuais processadas pelo Context Management

Service. Qualquer informação contextual é trocada entre as partes por meio de umatecnologia 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 (Figura 3.8). Istopermite que seu conteúdo possa ser utilizado para o registro automático de ocorrênciasem outros sistemas, ou apenas sua exibição para os interessados na informação. Tambémexiste 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 mensa-

48


Tabela 3.1 Regras utilizadas para inferência de contextos

49


Figura 3.8 Exemplo de mensagem XML

50


gens gratuito, Apache ActiveMQ3, configurado para garantir a entrega e persistência detodas as mensagens contextuais geradas pelo serviço de gerenciamento de contexto paraos 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 utilizarqualquer outro gerenciador padrão de mercado (ex. JBoss, IBM Websphere MQ), queatenda à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 diferentesID de um mesmo equipamento encontrados nos sistemas a serem integrados (ex. umdisjuntor 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, poiseste trata da troca de dados do estado operativo dos equipamentos, sem possuir até opresente momento, uma extensão que permita o uso dos dados de negócio para integração.A Figura 3.9 exemplifica como ocorre codificação e decodificação de um ID local de umsistema 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 codificaro ID local do equipamento utilizado para o formato único (UUID), usando o métodoencode(idLocal, sistema) do UUID Service. Quando o System B demonstra interessenessa informação enviada pelo System A, a rotina inversa é executada, desta vez por meiodo uso do método decode(UUID, Sistema). Desta forma o UUID Service devolverá o ID

3http://activemq.apache.org/4http://www.oracle.com/technetwork/java/docs-136352.html

51


Figura 3.10 Exemplo de um mapeamento de ID distintos para UUID

local do sistema que solicitou. A Figura 3.10 demonstra um exemplo do mapeamentoentre os ID dos sistemas envolvidos para o código único (UUID).

Ressalta-se que a utilização do UUID como solução do mapeamento “de-para” entreos sistemas torna os dados utilizados aderentes ao inevitável trabalho de conversão que asempresas do setor terão que fazer.

Através da utilização de Wrappers para os sistemas legados já existentes, é possívelutilizar as funções já encapsuladas de encode/decode deste serviço para todos as funci-onalidades que enviam ou recebem informações (mensagens) do middleware. Para osnovos sistemas, a estratégia adotada (WS-API) também viabiliza o uso destes métodos.

3.4.4 Real Time Event Monitor Service

O serviço Real Time Event Monitor Service monitora os eventos em tempo real captadospor um sistema SCADA, a fim de identificar bloqueios, desligamentos e normalizaçõesde um equipamento ou função de transmissão (ex. transformação, linhas, compensadorsíncrono)(Figura 3.11). Não havendo acesso à API do sistema SCADA utilizado, servemcomo fonte de informações os arquivos de LOG de alarmes com os registros de todosos eventos. Utilizar os arquivos de LOG para este serviço é válido como fonte deinformações, pois todos os eventos dos equipamentos monitorados são registrados.

Nos arquivos de LOG são registrados diversos tipos de eventos relacionados aoestado operativo dos equipamentos, por exemplo, quando ocorre um desligamento de umequipamento (ex. às 00:02:13 o equipamento SPBOT-1TIE-1 DESLIGOU ), quando atensão de um transformador sofre variação ou quando um equipamento é normalizado(ex. às 00:03:39 o equipamento SPSAA-4RT2 LIGOU).

Acompanhar estes eventos exige dos operadores um constante monitoramento doLOG e telas de consulta (ex. diagrama unifilar), como também, conhecimento técnico

52


Figura 3.11 Arquitetura do serviço Real Time Event Monitor Service

acerca da nomenclatura e configuração dos equipamentos nas instalações da empresa deenergia elétrica. A Figura 3.12 apresenta um exemplo do funcionamento do serviço Real

Time Event Monitor Service e sua integração com os demais serviços do middleware jáapresentados.

Figura 3.12 Funcionamento do Real Time Event Monitor Service

Através de um wrapper (1) um sistema pode assinar o Context Notification Service

demonstrando interesse nos eventos. O serviço Real Time Event Monitor Service (2),identifica os eventos de interesse (ex. bloqueio, desligamento ou normalização de equipa-

53


mento). Estes eventos são registrados pelo SCADA em um arquivo de LOG (3). Paranotificar os eventos ao serviço Context Notification Service (4), são acionados os métodosinformarBloqueio, informarDesligamento e informarNormalização pelo Real Time Event

Monitor Service. Antes da publicação dos eventos aos interessados, o Context Notification

Service solicita ao Context Management Service para processar, inferir e armazenar ocontexto dos eventos (5). Por fim, os eventos e seus contextos são publicados para osinteressados (6).

Ressalta-se ainda, que para as situações de falha do monitoramento dos arquivosde LOG ou falha na publicação dos eventos, mecanismos de buffer foram criados paraarmazenar a última linha do arquivo que foi processada. As mensagens dos eventosnão entregues são persistidas, o que garante a posterior publicação destes eventos. Orestabelecimento do monitoramento do arquivo de LOG do SCADA, pelo Real Time

Event Monitor Service, continua o processamento exatamente do último ponto de leitura.Desta forma, dispensa-se a obrigatoriedade de acompanhamento contínuo dos eventosno sistema SCADA e permite-se notificar o contexto dos eventos a qualquer usuário ousistema interessado nas informações contextuais destes eventos.

3.5 Comparação com Trabalhos Relacionados

A Tabela 3.2 complementa a Tabela 2.2 (Seção 2.4), permitindo comparar os trabalhosrelacionados com o middleware proposto nesta dissertação.

Tabela 3.2 Comparativo entre os trabalhos relacionados e o middleware proposto

Na comparação do middleware proposto com os trabalhos relacionados, dentre asprincipais características apenas a integração de dados conforme o modelo CIM nãoé plenamente atendida. Os dados utilizados na integração sensível a contexto, dizemrespeito à informações de negócio entre os sistemas e não sobre a estrutura dos equipa-mentos. Porém, ao utilizar um formato único de identificação do equipamento (UUID),preconizado pelo modelo CIM, a utilização do middleware proposto permitirá aproveitar

54

3.6. CONSIDERAÇÕES FINAIS

os dados deste mapeamento já realizado, minimizando o esforço das empresas numafutura representação das bases dos sistemas legados no modelo CIM. Como principaiscaracterísticas do middleware neste comparativo, destacam-se a integração do negóciodos sistemas e a utilização da sensibilidade a contexto que não são utilizadas por todos ostrabalhos relacionados.


Este capítulo apresentou a especificação da arquitetura-modelo de um middleware paraintegração sensível a contexto de sistemas de gerenciamento de energia elétrica.

Diferentemente das propostas apresentadas na seção 2.3, o diferencial deste trabalhoé utilizar a sensibilidade a contexto para integrar as informações de negócio dos sistemasespecialistas. Desta forma, é possível automatizar o processo de notificação de eventoscomo bloqueios, desligamentos, normalizações, liberações e normalizações programadasde equipamentos que compõem a infraestrutura de uma empresa de transmissão deenergia.

São utilizadas informações contextuais relevantes para os processos e sistemas inte-grados. Será permitido compartilhar dados e inferir o contexto dos eventos dos diferentessistemas, sem a necessidade de redigitação dos dados ou acessos a diversas telas.

O Capítulo 4 a seguir, apresenta os resultados obtidos da implementação de um protó-tipo do middleware, que foi instanciado para validar os requisitos levantados, utilizandosimuladores das aplicações reais de gerenciamento de energia elétrica de uma grandeempresa deste setor no País.

55

4Cenários de Implementação

Nossas dúvidas são traidoras e nos fazem perder o que, com

frequência, poderíamos ganhar, por simples medo de arriscar.

—WILLIAM SHAKESPEARE (Poeta)

Como prova de conceito, este Capítulo apresenta a implementação de um protótipodo middleware que foi instanciado para integrar versões simuladas dos sistemas degerenciamento de transmissão de energia elétrica, em produção na empresa CTEEP -Companhia de Transmissão de Energia Elétrica Paulista, que em parceria com a In FormaSoftware e o CIn/UFPE, viabilizaram esta pesquisa e desenvolvimento.

4.1 Protótipo

A Figura 4.1 apresenta uma instância do modelo do middleware proposto no Capítulo 3,para integrar, através de um middleware sensível a contexto, os sistemas simuladosda empresa CTEEP. São aplicações responsáveis pela programação de impedimentosoperativos (S_LS1) e registro de ocorrências (S_LS2). Para simulação do sistema SCADA,utilizou-se cópias de arquivos de LOG de produção, gerados pelo sistema SCADA,durante o primeiro semestre de 2013, com os eventos reais registrados neste período. Aotodo foram registrados mais de 4 milhões de eventos diversos durante este período.

Para garantir a independência de plataforma e a viabilidade do uso dos serviços domiddleware, todos os serviços foram implementados na plataforma Java (versão 1.7.0_25).Os simuladores dos sistemas da CTEEP foram desenvolvidos na mesma tecnologia queos aplicativos reais. O sistema simulado S_LS1 foi desenvolvido em PHP (versão 5), queroda na plataforma XAMPP1(versão 1.8.3). Já o sistema simulado S_SL2, foi construído

1http://www.apachefriends.org/pt_br/xampp.html

57

CAPÍTULO 4. CENÁRIOS DE IMPLEMENTAÇÃO

em ASP.NET (Code-Behind C#) rodando no Framework.NET (versão 4.0). Adotou-seo PostgreSQL (versão 9.2) como o sistema gerenciador de banco de dados, que possuitabelas para a persistência dos dados dos eventos, dados históricos e contextos inferidospelos serviços do middleware.

Figura 4.1 Arquitetura da prova de conceito

O diagrama de componentes da Figura 4.2 apresenta como os principais componentesdos serviços do middleware estão relacionados e suas principais dependências. Atravésdesta integração simulada, pretende-se avaliar com cinco cenários a integração sensívela contexto dos sistemas envolvidos e sua aderência aos requisitos já apresentados naSeção 3.1.

Para fins de organização deste capítulo, no Apêndice A estão descritos todos osgrafos contextuais utilizados nestes cenários, como também as regras Drools que osimplementam e que são utilizadas pelo serviço Context Management Service para ainferência dos contextos.

4.2 Cenários

Baseando-se no escopo dos requisitos já apresentados na Seção 3.1, cinco cenários foramcriados para simular a rotina operacional dos usuários, utilizando os sistemas envolvidos,sem o uso dos serviços do middleware e, posteriormente, com o uso dos serviços deintegração sensível a contexto do middleware.

Com esta abordagem, permitiu-se simular os cenários: (1) identificar bloqueios, (2)notificar desligamentos, (3) notificar normalizações, (4) notificar liberações programadas

58

4.2. CENÁRIOS

Figura 4.2 Diagrama de componentes do middleware

e (5) notificar normalizações programadas. Todos estes cenários fazem parte da rotinadiária, não só da CTEEP, em particular, como em geral, de um centro de controle degeração e transmissão de energia elétrica regido pelas normas e procedimentos de rededo Operador Nacional do Sistema Elétrico (ONS).

4.2.1 Cenário 1 - Identificando Bloqueios de Equipamentos

Este cenário apresenta o caso de uso onde o usuário (operador da pré-operação) desejasaber se os equipamentos contidos na previsão de impedimento operativo estão bloquea-dos. Esta verificação ocorre durante a elaboração de uma solicitação de intervenção, aquisimulada através do simulador S_LS1. As informações de bloqueio de equipamentos sãoregistradas pelo sistema SCADA (ex. “TAG de impedimento operativo”).

Antes da utilização do middlewarePara que o usuário da pré-operação possa planejar a criação de uma solicitação de

impedimento operativo (SIS), é preciso saber se os equipamentos contidos na previsãode impedimento, durante a elaboração desta SIS, possuem registros que restrinjam aoperação (ex. um bloqueio). Para isto, o usuário precisa consultar uma tela do sistemaSCADA (ex. no diagrama unifilar, LOG de alarme) ou utilizar um formulário em papel,

59


com os registros de manutenção de um determinado período, para confirmar a existênciaou não de um bloqueio no equipamento (Figura 4.3). Ressalta-se que as condições desegurança são importantes para evitar acidentes no campo durante as manutenções.

Figura 4.3 Cenário 1 sem middleware

Depois da utilização do middlewareCom o advento do serviço Real Time Event Monitor Service, que monitora o arquivo

de alarmes do SCADA, identifica-se, em tempo real, quando uma nova anotação de TAGde impedimento é registrada. A Figura 4.4 ilustra, nas linhas em destaque, o momento emque o LOG de alarmes do SCADA registra um bloqueio de um determinado equipamento.

Figura 4.4 Exemplo de um Log de alarmes do SCADA

Sempre que este evento for registrado (Tag anotação nova/alterada), o Context Ma-

nagement Service é acionado pelo Real Time Event Monitor Service para armazenar ocontexto do equipamento bloqueado. Ressalta-se que quando a informação de bloqueio éalterada ou retirada, o Real Time Event Monitor Service solicita ao Context Management

Service para alterar ou retirar o contexto do equipamento.

Uma adaptação foi implementada no simulador do sistema de Programação de Im-pedimentos Operativos (S_SL1), através do uso de um wrapper, que possui a lógica dechamada ao método obterContextoEquipamento do serviço Context Management Service

60

4.2. CENÁRIOS

(Figura 4.5). É necessário lembrar que wrappers encapsulam sistemas legados, a fim deintegrá-los a sistemas novos, como middleware e novas aplicações.

Figura 4.5 Cenário 1 com middleware

Portanto, na criação de uma solicitação de intervenção, quando o usuário informaros equipamentos contidos na previsão de impedimento, será notificado automaticamente(Figura 4.6), que um ou mais equipamentos estão bloqueados. Caso não exista umbloqueio, o fluxo de execução do simulador segue sem alterações.

O grafo contextual ilustrado na Figura 4.7 apresenta como está modelado o comporta-mento do middleware na inferência deste contexto, baseado nas informações da entidadecontextual “Equipamento” e do elemento contextual “status”.

A Figura 4.8 apresenta uma implementação da regra de contexto, representada nografo anterior (Figura 4.7), utilizando Drools e que é processada pelo middleware toda asvezes que um equipamento for utilizado neste cenário. O nó CE1 (“equipamento.status”)possui uma condição associada que verifica o status do equipamento. Há dois caminhospossíveis para o status, nesse caso: “TAG igual a anotação nova/alterada” ou “TAGdiferente de anotação nova/alterada”. Se a TAG for igual ao valor esperado, o grafo seguepara a ação “Equipamento está bloqueado” e encerra o grafo no nó de recombinação R1.No caso de ter sido diferente do valor esperado, o grafo segue para a ação “Equipamentonão está bloqueado” e encerra o grafo no nó de recombinação R1.

Ressalta-se que nesta simulação utilizou-se um ID de equipamento do sistema simu-lado S_SL1 (ex. 9910) e o mesmo equipamento, possui um outro ID no sistema SCADA(ex. PREG_0E.SE_OP.EST). Neste caso, o serviço UUID Service efetuou a codificaçãoe decodificação do ID local de cada um dos sistemas para o formato único (UUID) deacordo com o padrão IEC 61970 (IEC, 2011), tanto na interface do usuário do simulador

61


Figura 4.6 Notificação do contexto do equipamento com bloqueio no simulador S_SL1

Figura 4.7 Grafo contextual - Foco: Obter Bloqueio de um equipamento

62

4.2. CENÁRIOS

Figura 4.8 Regra Drools para o foco obter bloqueio de um equipamento

(S_SL1), como através do serviço Real Time Event Monitor Service. Com a utilizaçãodo middleware, evitou-se a necessidade do usuário, obrigatoriamente, acessar o sistemaSCADA para verificar se o equipamento informado está bloqueado e, através de umaanálise e inferência manual, decidir qual o contexto do equipamento.

4.2.2 Cenário 2 - Notificando Desligamentos de Equipamentos

Este cenário apresenta o caso de uso onde o usuário (operador de tempo real) deseja saberinformações de desligamentos, encontradas no SCADA, para auxiliar na elaboração deocorrências no simulador (S_SL2).

Antes da utilização do middlewareO evento de desligamento de um equipamento deve ser registrado pelos operadores

para análise de indicadores relacionados a este tipo de evento, por parte da equipe depós-operação. São exemplos de indicadores de indisponibilidade do ONS: taxa de falha,taxa de desligamento forçado (não planejado), tempo médio de reparo, entre outros.

Normalmente ao final de um dia, o operador faz um levantamento de informaçõesacerca destes eventos e os registra no sistema de registro de ocorrências (simuladopor S_SL2), ou seja, é necessário acessar diversos dados dos sistemas responsáveispela pré-operação (S_SL1) para verificar se existe uma autorização de desligamento deum equipamento, e também o sistema responsável pelo monitoramento do tempo real(SCADA) com os eventos registrados no LOG de alarmes (Figura 4.9).

O registro de um desligamento também deve ser classificado como ocorrência “for-çada” ou “não forçada”. As ocorrências forçadas dizem respeito aos eventos de des-ligamento que aconteceram sem planejamento prévio. Já as ocorrências não forçadas,possuem a devida autorização da pré-operação (planejamento) para que o evento ocorra.

63



A decisão sobre o registro (digitação) de cada tipo de ocorrência no simulador(S_SL2) está relacionada à habilidade do usuário de analisar, através dos dados obtidosnos sistemas envolvidos, quais são as informações e se existe um relacionamento entreelas.

Depois da utilização do middlewareO Real Time Event Monitor Service captura o evento de desligamento que também

é registrado no arquivo de LOG do sistema SCADA. Os dados do desligamento sãorepassados ao Context Notification Service que, por sua vez, solicita o processamento docontexto ao Context Management Service. Neste caso, o contexto é inferido automati-camente, determinando para o usuário se o desligamento em questão é total ou parcial.Ainda não é possível inferir se a ocorrência é forçada ou não forçada (Figura 4.10), dadoque a liberação programada (Seção 4.2.3) ainda não foi executada.


64

4.2. CENÁRIOS

A Figura 4.11 apresenta um exemplo do simulador S_SL2, que permite ao usuáriolistar todos os desligamentos ocorridos em um período, permitindo-se detalhar os dadosde cada evento e se já possuem algum relacionamento com outro evento (ex. liberaçãoprogramada, normalização).

Figura 4.11 Desligamentos de um período no simulador (S_SL2)

Ressalta-se que os dados e o contexto inferidos neste cenário, são recebidos pelosimulador (S_SL2), via wrapper, que é assinante da publicação do evento de desligamento.Desta maneira, as ocorrências (forçadas) são criadas de maneira automática.

Com o uso dos serviços do middleware, o conjunto de informações e os contextosinferidos dispensam a necessidade de consultar todas as informações nos sistemas envol-vidos. Os usuários interessados no evento desligamento são notificados, em tempo real,sempre que o evento ocorrer.

4.2.3 Cenário 3 - Finalizando Desligamentos

Este cenário apresenta o caso de uso onde o usuário (operador de tempo real) deseja saberinformações de finalização dos desligamentos (normalização), registradas no SCADApara auxiliar na elaboração de ocorrências no simulador S_SL2.

Antes da utilização do middlewareO evento de normalização de um equipamento deve ser registrado pelos operadores

para análise de indicadores, por parte da equipe de pós-operação relacionada a este tipode evento, a exemplo de um desligamento. Este evento está relacionado ao retorno dofuncionamento de um mesmo equipamento ora desligado. Portanto, faz-se necessárioobter os dados do desligamento já registrado.

65



Para anotação no simulador de registro de ocorrências (S_SL2), da mesma maneiraque um desligamento, a normalização também pode ser classificada como “total” ou“parcial”, como também, “forçada” ou “não forçada”. Neste caso, o operador precisaencontrar, nos sistemas envolvidos, os dados da normalização, registradas no LOG dosistema SCADA, os dados relativos ao desligamento do equipamento, como também, osdados de uma possível autorização prévia no simulador S_SL1 (Figura 4.12).

Uma normalização pode ocorrer segundos depois de um desligamento, como tambémsemanas após este evento, e isto depende do tipo do evento de desligamento (forçado ounão forçado).

Depois da utilização do middlewareO Real Time Event Monitor Service captura o evento de uma normalização, que

também é registrado no arquivo de LOG do sistema SCADA. Os dados da normalizaçãosão repassados ao Context Notification Service que, por sua vez, solicita o processamentodo contexto ao Context Management Service. Neste caso, o contexto é inferido automati-camente, determinando para o usuário se a normalização do equipamento em questão étotal ou parcial.

Ainda não é possível inferir se a ocorrência é forçada ou não forçada, dado que anormalização programada (Seção 4.2.5) ainda não foi executada. A Figura 4.13, apresentaeste cenário com o uso dos serviços do middleware.

Para que o contexto da normalização seja inferido corretamente, também é neces-sário verificar se o equipamento normalizado já possui um desligamento, ou seja, se anormalização é do mesmo equipamento e das mesmas instalações.

Da mesma forma que no cenário 2, o usuário poderá visualizar no simulador S_SL2(Figura 4.14), todos os eventos de normalização que foram recebidos via wrapper (a)e que já permitem uma visualização do seus eventos relacionados (b), no caso, umdesligamento.

66

4.2. CENÁRIOS


Figura 4.14 Normalizações (a) e eventos relacionados (b) de um período no simulador S_SL2

67


Com o uso dos serviços do middleware neste cenário, não é mais necessário queos operadores verifiquem, obrigatoriamente, as telas dos sistemas envolvidos, pois anotificação dos eventos e seus contextos é feita, em tempo real, no momento em queocorrem.

4.2.4 Cenário 4 - Informando uma Liberação Programada

Este cenário apresenta o caso de uso onde o usuário (operador de tempo real) informaatravés do sistema simulado S_SL1 a liberação programada de uma autorização de impe-dimento operativo. Neste caso, o operador de tempo real deseja que esta liberação sejainformada ao sistema simulado S_SL2, para que seja possível cadastrar uma ocorrêncianão forçada.

Antes da utilização do middlewareA liberação programada de um impedimento operativo é um procedimento que indica

para os operadores de tempo real, que uma determinada manutenção em um equipamentoé planejada, portanto, uma ocorrência não forçada. Esta manutenção pode acontecercom o equipamento em funcionamento (sem desligamento), como também, com esteequipamento desligado (com desligamento).

Para isto, o usuário precisa reunir todos os dados relativos ao impedimento. Em geral,quando o operador de tempo real vai registrar uma ocorrência (Seção 4.2.3), ele precisaconsultar o sistema S_SL1 para verificar se existe uma autorização de impedimento comtodos os dados relacionados a este procedimento (ex. se possui algum desligamento).Caso exista um desligamento, o sistema SCADA precisa ser consultado para reunir osdados do desligamento.

Para o caso de existir uma autorização de impedimento, a inferência feita pelo usuáriodetermina o registro de ocorrência não forçada (Figura 4.15) no sistema S_SL2.


68

4.2. CENÁRIOS

Depois da utilização do middlewareUtilizando o simular S_SL1, toda vez que uma liberação programada for registrada,

as informações desta liberação são enviadas para o Context Notification Service, atra-vés do método informarLiberaçãoProgramada(), que em seguida solicita ao Context

Management Service para processar o contexto deste evento.

Caso a liberação programada possua um ou mais equipamentos com desligamento,os registros equivalentes aos desligamentos e que já foram enviados para o middleware

pelo Real Time Event Monitor Service (Seção 4.2.2), são recuperados e relacionados àliberação programada.

Desta maneira, a publicação deste evento já possui o contexto inferido pelo mid-

dleware informando que os desligamentos associados à liberação se tratam de umaocorrência não forçada, podendo ser com desligamento ou sem desligamento, pois umaliberação programada também pode ser feita sem desligamentos.

Neste caso, o operador de tempo real não mais precisa reunir as informações daliberação ou dos desligamentos para o registro da ocorrência. Todos os dados e contex-tos inferidos são recebidos no formato XML (Figura 4.16), via wrapper, pelo sistemasimulado S_SL2, o que permite a criação automática do registro de uma ocorrência nãoforçada, como ilustrado na Figura 4.17.

Figura 4.16 Extrato de um XML enviado na liberação programada

Observa-se que os dados que estão no extrato do XML apresentado têm origensdistintas. Existem dados provenientes do relacionamento entre os eventos (a) e queforam determinados pelo middleware. Há também as informações acerca da liberação

69


programada (b), feita no sistema S_SL1, como também os contextos inferidos peloContext Management Service após o processamento das regras estabelecidas para oevento “liberação programada” (c).

Figura 4.17 Registro de ocorrência não forçada e com desligamento no simulador S_SL2

Com o advento da integração sensível a contexto do middleware, o registro de umaocorrência não forçada foi automatizado, permitindo aos operadores uma melhor análisedos dados restantes (ex. impacto e motivo da ocorrência, tipo do evento,etc.) e que nãoestão no escopo da integração dos sistemas envolvidos ou que dependem de análisesmanuais dos operadores.

4.2.5 Cenário 5 - Informando uma Normalização Programada

Este cenário apresenta o caso de uso onde o usuário (operador de tempo real) informa,através do sistema S_SL1, a normalização programada de uma autorização de impedi-mento. Neste caso, o operador de tempo real deseja que esta normalização seja informadaao sistema S_SL2 para que possa finalizar uma ocorrência não forçada.

Antes da utilização do middlewareA exemplo da liberação programada (Seção 4.2.4), a normalização programada é o

procedimento feito pelos operadores de tempo real, no sistema S_SL1, para finalizaruma ocorrência não forçada, ou seja, aquela que a normalização de um equipamento foiplanejada (Figura 4.18).

Após o cadastro da normalização programada no sistema S_SL1, o operador detempo real precisa obter todos os dados relativos aos demais eventos relacionados. Ou

70

4.2. CENÁRIOS


seja, se houve desligamentos e normalizações no sistema SCADA, juntamente com osdados da liberação programada no sistema S_SL1. Isto permitirá encerrar o processoe restabelecer as funções dos equipamentos que estejam relacionados à normalizaçãoprogramada. Também será registrado no sistema S_SL2 uma ocorrência não forçada,com ou sem desligamento .

Depois da utilização do middlewareAtravés de uma adaptação realizada no sistema S_SL1, para a utilização de um

wrapper, toda vez que uma normalização programada for registrada, as informaçõesdesta normalização são enviadas para o Context Notification Service através do métodoinformarNormalizaçãoProgramada(), que em seguida solicita ao Context Management

Service para processar o contexto deste evento.Caso a normalização programada possua um ou mais equipamentos com desligamento,

os registros equivalentes aos desligamentos e que já foram enviados pelo Real Time

Event Monitor Service (Seção 4.2.2), são recuperados automaticamente e relacionados ànormalização programada.

Neste caso, o operador de tempo real não mais precisa reunir as informações danormalização ou dos eventos relacionados para o registro da ocorrência. Todos osdados da integração e os contextos inferidos também são recebidos no formato XML(Figura 4.19), via wrapper, pelo sistema simulado S_SL2.

Desta maneira, a publicação deste evento já possui o contexto inferido pelo mid-

dleware, como também os eventos associados à normalização, configurando assim umaocorrência não forçada. Dependendo dos dados relativos aos equipamentos impedidos,a ocorrência poderá ser com desligamento ou sem desligamento. Com isto, é possí-vel o registro automático da finalização de uma ocorrência não forçada, com todas asinformações necessárias agrupadas e relacionadas, como ilustrado na Figura 4.20.

71


Figura 4.19 Extrato de um XML enviado na normalização programada

Figura 4.20 Exemplo de ocorrência não forçada após normalização programada no simuladorS_SL2

72



Este capítulo apresentou um protótipo instanciado do modelo de middleware apresentadono Capítulo 3. Cinco cenários foram apresentados sem o uso do middleware, comotambém, com o advento dos serviços de integração sensível a contexto propostos pelomiddleware.

Demonstrou-se que com o uso do middleware e seus serviços, foi possível integrar ossistemas simulados das aplicações reais da empresa CTEEP, de maneira minimamenteinvasiva, utilizando as informações contextuais dos sistemas relativos ao escopo dosrequisitos com a inferência e notificação automática dos contextos.

Desta forma, espera-se diminuir o acesso obrigatório, por parte dos usuários, aossistemas envolvidos, para obter os dados e informações contextuais, que permitem oregistro das ocorrências forçadas e não forçadas, relacionadas aos eventos de bloqueio,desligamento, normalização, liberação e normalização programada de impedimentosoperativos. Sendo assim, será possível minimizar os problemas relatados na Seção 1.2,como também agilizar o registro destas ocorrências para análise do setor da pós-operaçãoda empresa.

No Capítulo 5 são apresentados os resultados dos testes executados para validar aacurácia dos contextos inferidos, o percentual de preenchimento automático dos camposdo sistema de registro de ocorrências, como também, uma análise dos dados e informaçõescontextuais resultantes dos eventos tratados no escopo deste projeto.

73

5Resultados e Análises

Se A é o sucesso, então A é igual a X mais Y mais Z. O trabalho é X; Y

é o lazer; e Z é manter a boca fechada.

—ALBERT EINSTEIN (Físico)

Neste capítulo é apresentada uma análise de resultados referentes aos testes executadosno protótipo apresentado na Capítulo 4. Utilizou-se arquivos de LOG registrados peloSCADA, em produção na CTEEP, no primeiro semestre do ano de 2013, como fontede dados reais de um funcionamento de um moderno centro de operações. As seçõesseguintes deste capítulo, discorrem com maiores detalhes os resultados obtidos.

5.1 Ambiente de Execução

Para tornar as simulações dos cenários apresentados no Capítulo 4 mais próximas doambiente real da empresa CTEEP (Companhia de Transmissão de Energia Elétrica Pau-lista), foi criado um ambiente distribuído com serviços e aplicativos básicos necessários.Utilizou-se as mesmas ferramentas e tecnologias, adotadas pela empresa para o uso dosaplicativos simulados. A Figura 5.1 apresenta o ambiente utilizado e como os serviçosforam organizados.

Neste capítulo os simuladores desenvolvidos representam os sistemas reais da CTEEP,no caso S_SL1 = S_PIO e S_SL2 = S_SIGO. O sistema PIO (Programa de ImpedimentoOperativo) é utilizado pela pré-operação para registrar a programações dos futurosimpedimentos. O sistema SIGO (Sistema de Informação para Gestão Operativa) éutilizado pela operação de tempo real para registrar ocorrências forçadas ou não forçadas.

Um servidor Windows 2008 Server serviu como host dos serviços para viabilizaro uso do middleware e dos simuladores. No servidor Apache Tomcat 7.x, distribuiu-

75

CAPÍTULO 5. RESULTADOS E ANÁLISES

Figura 5.1 Diagrama de implantação: Ambiente utilizado na execução dos serviços e aplicativos

76

5.2. EXECUÇÃO DOS TESTES

se o os serviços do middleware responsáveis pelo gerenciamento e notificação doscontextos (artefato: ws_mw_gctx), o serviço UUID Service (artefato: ws_ceu) e osserviços auxiliares (artefatos: ws_scada, ws_sigo).

O simulador S_SL1, responsável pelo gerenciamento de intervenções operativas,foi desenvolvido em PHP e instalado em um servidor XAMPP. Já o simulador S_SL2responsável pelo registro de ocorrências, foi implementado em .NET (code-behind C#) einstalado em um servidor IIS 8.0 com .NET Framework 4.0. Utilizou-se estes ambientese tecnologias, similares aos ambientes e sistemas reais utilizados na CTEEP, para provara independência de plataforma do protótipo utilizado.

Instalou-se como serviço um servidor de mensagens JMS, Apache Active MQ, paraviabilizar a infraestrutura de troca de informações entre os participantes. O serviço Real

Time Event Monitor Service (monitor_tr.jar), rodou em uma instância Shell no servidorWindows, para monitorar as cópias dos arquivos de LOG do SCADA, com dados reais eque foram disponibilizados em uma pasta local no mesmo servidor.

O banco de dados PostgreSql 9.2, possui bases de dados organizadas em esquemaspara possibilitar o armazenamento dos dados e informações contextuais. A base bd_scadaé utilizada pelo serviço Real Time Event Monitor para persistência dos dados monitoradosnos arquivos de LOG do SCADA. A base bd_mw é utilizada pelo serviço de geren-ciamento e notificação de contextos, respectivamente, Context Management Service eContext Notification Service.

Já a base bd_ceu, é utilizada pelo UUID Service para a consulta aos dados domapeamento UUID entre os ID dos sistemas envolvidos. Por fim, a base bd_sigo, possuios registros de ocorrências pré-cadastradas que foram armazenadas por um Wrapper,assinante dos eventos do middleware, com os contextos já definidos pelos serviços domiddleware e que são utilizados pelo simulador S_SL2.

5.2 Execução dos Testes

Os cenários apresentados na prova de conceito na Seção 4.2, em geral acontecem si-multaneamente e dependem tanto dos operadores para a execução das liberações enormalizações programadas, como também, antes do uso dos serviços do middleware, docontínuo monitoramento dos arquivos de LOG. Com o advento do middleware, depende-se dos usuários apenas nos cenários de liberação e normalização programada. As demaisatividades de monitoramento dos eventos são garantidas pelo serviço Real Time Event

Monitor Service.

77


Desta forma, para viabilizar uma simulação próxima ao dia-a-dia do centro de opera-ções da CTEEP, o serviço Real Time Event Monitor monitorou cópias de arquivos de LOGde produção dos seis (06) primeiros meses de 2013, com todos os eventos registradospelo monitoramento do sistema SCADA.

Para viabilizar a execução de liberações programadas com desligamento, utilizou-seuma amostra de 30 registros de ocorrências não forçadas, de um total de 78 registradaspelos operadores durante o mês de Janeiro do mesmo ano, em produção, para simular asocorrências não forçadas com desligamento de equipamentos.

A Seção 5.3 apresenta uma análise dos resultados relacionados a todos os eventosoriginados na simulação do SCADA (via LOG).Também são apresentadas as quantidadesidentificadas de eventos (desligamentos, normalizações e bloqueios), a quantidade debloqueios e a quantidade de ocorrências geradas, automaticamente pelo middleware,durante o monitoramento dos arquivos de LOG. A partir destes eventos, avaliou-sequantas destas ocorrências foram inferidas corretamente como não forçadas.

Ainda baseando-se nos dados provenientes da integração entre os sistemas envolvidosno escopo deste projeto e utilizadas pelos serviços do middleware, apresenta-se o per-centual de campos que são preenchidos automaticamente ou que o contexto auxiliará nopreenchimento, no aplicativo de produção para o registro de ocorrências da CTEEP.

Por fim, é apresentado o percentual de acertos na inferência dos contextos de ocorrên-cias não forçadas com desligamento, feita pelo middleware na simulação, em comparaçãocom as mesmas ocorrências registradas pelos operadores da CTEEP, utilizando-se osdados dos registros destas mesmas ocorrências, cedidas pela empresa e efetivadas emprodução no mês de Janeiro de 2013.

5.3 Análise dos Resultados

Para permitir as análises a respeito da acurácia dos serviços que o middleware oferece,monitorou-se todos os arquivos de LOG, cedidos pela CTEEP, que foram gerados peloSCADA durante o primeiro semestre do ano de 2013. A Tabela 5.1 apresenta a quantidademensal de eventos diversos registrados nos arquivos de LOG do SCADA e que forammonitorados pelo serviço Real Time Event Monitor.

A quantidade de eventos monitorados pelo middleware, exemplifica o grande volumede dados e informações que são utilizadas pelos operadores, no controle e supervisão dosmais de 12.000 Km de linhas de transmissão da empresa.

78

5.3. ANÁLISE DOS RESULTADOS

Tabela 5.1 Quantidade de eventos registrados no LOG do SCADAMês do LOG Qtd. de registrosJAN/2013 625.609FEV/2013 680.276MAR/2013 622.549ABR/2013 644.627MAI/2013 932.756JUN/2013 781.876

5.3.1 Eventos Identificados a partir do Monitoramento do LOG

Dentro do período monitorado, foram identificados todos os eventos de desligamentoe normalização dos equipamentos principais e secundários, registrados nos arquivos deLOG pelo monitoramento do sistema SCADA. A Figura 5.2 apresenta a quantidade deeventos de desligamentos e normalizações identificadas e notificadas aos interessados.

Figura 5.2 Eventos identificados e notificados pelo middleware

Observa-se no gráfico que o middleware identificou e notificou todos os eventos(desligamento e normalização), encontrados no LOG, destacando-se o mês de Janei-ro/2013, com valores maiores que os demais meses analisados. Devido ao planejamentodas intervenções, algumas normalizações podem ocorrer em minutos ou até meses, apóso evento de desligamento, por isso a maioria dos meses monitorados apresentam estecomportamento, uma maior quantidade de normalizações em relação aos desligamentos.

79


5.3.2 Bloqueios Identificados a partir do Monitoramento do LOG

Dentro do período monitorado, foram identificados todos os bloqueios de equipamentosprincipais e secundários que foram registrados no LOG do SCADA. Através destes contex-tos dos equipamentos, garante-se a segurança durante os procedimentos de planejamentode impedimento, liberação e normalização programada, necessárias às manutenções dosequipamentos.

Sendo assim, através do uso de um Wrapper, adaptando o funcionamento do sistemade planejamento de manutenção, o contexto de um equipamento de um planejamento oudas condições de segurança sempre será informado, sem que os operadores precisem estarcientes do seu uso. Desta forma, incrementa-se a segurança e evita-se cancelamentos deprocedimentos, com equipamentos já bloqueados por outros procedimentos, entre outrosproblemas, já citados no Capítulo 1.

Figura 5.3 Bloqueios de equipamentos identificados pelo middleware

A Figura 5.3 apresenta a quantidade de bloqueios monitorados e identificados pelomiddleware. Observa-se no gráfico que apenas o mês de Janeiro/2013 apresentou umaquantidade de bloqueios incompatível com os demais meses. Isto se deve ao fato destemês ser tipicamente de férias e com poucas manutenções. A notificação destes contextospara os operadores no momento em que eles fazem o planejamento ou execução dasmanobras de manutenção, evitam cancelamentos indesejáveis e, principalmente, acidentescom as equipes de campo.

80


5.3.3 Ocorrências Geradas a partir dos Eventos Identificados

Com a utilização do middleware, todos os contextos dos eventos de desligamento enormalização foram relacionados entre si, quando existia uma relação entre eles, egeraram, automaticamente, ocorrências forçadas pré-cadastradas na base do simuladorS_SL2. A Figura 5.4 apresenta a quantidade de ocorrências geradas a partir desteseventos.

Figura 5.4 Ocorrências geradas automaticamente pelo middleware

Observa-se no gráfico que todas as ocorrências geradas, automaticamente, tiveramseu contexto inferido como ocorrências forçadas, já que ainda não existem as informa-ções de liberação ou normalização programada. Em um cenário real, estas liberaçõesnormalmente são lançadas no sistema de programação de impedimento operativo, nestetrabalho simulador S_SL1, antes dos procedimentos de desligamento propriamente ditoacontecerem.

A quantidade de ocorrências geradas é menor que a quantidade de eventos, devidoao fato de um desligamento de uma linha de transmissão, por exemplo, ser compostode diversos desligamentos de equipamentos secundários, que compõem uma função detransmissão. Desta forma, os operadores só precisarão complementar os dados que não

81


foram preenchidos automaticamente pela integração sensível a contexto viabilizadas pelomiddleware.

5.3.4 Campos Preenchidos Automaticamente para o Registro de Ocor-rências

Os dados que compõem as ocorrências apresentadas na Seção 5.3.3, são oriundos tanto daintegração entre os sistemas envolvidos no escopo deste projeto, como também, fruto dainferência de contextos do middleware. Como já relatado na seção anterior, o middleware

fez um pré-cadastro das ocorrências para diminuir o trabalho de digitação e inferênciamanual de contexto pelo operadores no registro destas ocorrências.

Os arquivos XML entregues ao simulador S_SL2, via Wrapper, possuem diversoscampos que preenchem ou auxiliam no preenchimento, dos campos no sistema real deregistro de ocorrências. A Tabela 5.2 e a Tabela 5.3, apresentam um levantamento feitosobre quantos campos do sistema real da CTEEP para registro ocorrências, terão seuconteúdo preenchido automaticamente ou que o middleware infere seu conteúdo, atravésdo contexto, para acelerar o registro destas ocorrências, sem a necessidade de redigitaçãode dados.

Tabela 5.2 Ocorrências forçadas: Campos preenchidos automaticamente pelo middleware

A Tabela 5.2 ilustra dois grupos de campos do sistema SIGO. Os que foram preenchi-dos, automaticamente, pelos dados publicados pela integração sensível a contexto (05campos) e os que não foram preenchidos pela integração (04 campos) por precisarem deinformações não contempladas no escopo do projeto. Verifica-se que aproximadamente55% dos campos (5 campos dos 9) que são necessários para o registro de uma ocorrênciaforçada no sistema especialista, tiveram seus dados preenchidos, automaticamente, pelosserviços do middleware.

82


Tabela 5.3 Ocorrências não forçadas: Campos preenchidos automaticamente pelo middleware

83


Na Tabela 5.3 ilustra dois grupos de campos do sistema SIGO. Os que foram preen-chidos, automaticamente, pelos dados publicados pela integração sensível a contexto (22campos) e os que não foram preenchidos pela integração (07 campos) por precisaremde informações não contempladas no escopo do projeto. Demonstra-se que aproxi-madamente 76% dos campos (22 campos dos 29) que são necessários para o registrode uma ocorrência não forçada no sistema especialista, também foram preenchidos,automaticamente, pelos serviços middleware.

Os campos que não foram preenchidos em ambas as tabelas, dependem de análisese de cálculos dos operadores. Estas informações não podem ser obtidas de maneiraautomática. Os cálculos e análises para o preenchimento destas informações são exercidosno momento do registro das ocorrências, como também, com o acesso a dados de outrossistemas que não estão no escopo deste projeto.

5.3.5 Taxa de Acerto do Middleware na Inferência de Ocorrênciasnão Forçadas

Uma avaliação da taxa de acerto na inferência dos contextos para as ocorrências nãoforçadas foi executada para se obter um indicativo da assertividade dos serviços oferecidospelo middleware.

Para determinar se uma ocorrência não é forçada, é necessário informar as liberaçõesprogramadas que tiveram desligamento em um determinado período. Para viabilizareste comparativo entre os contextos inferidos pelo middleware e o que foi registradomanualmente pelos operadores, solicitou-se da CTEEP uma lista das liberações concluídase que geraram ocorrências não forçadas, em produção, durante o mês de janeiro/2013.

De um total de setenta e oito (78) liberações com desligamento, uma amostra aleatóriade trinta (30) liberações foi extraída. Foram simuladas as mesmas liberações no simulador(S_SL1), informando os mesmos dados registrados à época, ou seja, o número da AIO(número da autorização de impedimento operativo), natureza, instalações, equipamento,datas da liberação (início das manobras, indisponibilidade da função, entrega da AIO).Os dados dos desligamentos e normalizações já foram processados anteriormente eapresentados na Seção 5.3.1.

A taxa de acerto do middleware na inferência de ocorrências não forçadas, emcomparação com o que foi inferido e registrado manualmente pelos operadores, foi de100% (30 em 30). O resultado apresentado sugere um forte indício de que os serviços domiddleware estão corretos na inferência dos contextos avaliados. Portanto, as ocorrênciasgeradas e pré-cadastradas, decorrentes destes eventos e contextos, poderão ser utilizadas

84


de forma confiável durante o registro das ocorrências, quando do uso do middleware emum ambiente real.


Este capítulo apresentou a análise de resultados do uso dos serviços do middleware, base-ados no processamento de arquivos de LOG do SCADA, do primeiro semestre de 2013,cedidos pela empresa parceira no projeto. Foram apresentados a quantidade de eventosregistrados pelo SCADA, a quantidade de desligamentos, normalizações e bloqueiosidentificados, como também, a quantidade de ocorrências geradas, automaticamente, apartir destes eventos.

Ilustrou-se que com os dados do XML utilizados para a notificação dos eventos,aproximadamente 55% dos campos necessários para o registro de uma ocorrência forçada,no sistema em produção da CTEEP, foram pré-cadastrados pelo middleware, assim como,aproximadamente 76% dos campos necessários para o registro de uma ocorrência nãoforçada.

A taxa de acerto do middleware, na amostra utilizada, para a inferência dos contextosde ocorrências não forçadas, em comparação com as mesmas inferências e registrosmanuais destas ocorrências, exercidas pelos usuários, foi de 100%, indicando uma boaassertividade dos contextos inferidos pelo middleware.

Desta maneira, existe um forte indício de que o processo de registro de ocorrênciaspelos operadores poderá ser agilizado, uma vez que a maioria dos campos já estarãopreenchidos ou que o contexto para seleção de opções já estará sugerido, evitando-seentre outras coisas, problemas como solicitações de manutenção canceladas, erros dedigitação e inconsistências de dados relatados no Capítulo 1.

Não se pode afirmar que o tempo médio gasto no registro destas ocorrências seráde fato reduzido, pois, demanda-se um processo de aferição controlada no ambientede produção da empresa, para medir o tempo gasto para a execução de registros destasmesmas ocorrências, com o uso dos serviços sensíveis a contexto do middleware. Oscampos que dependem de uma análise ou de cálculos que só os operadores podem realizar,não foram preenchidos pelo middleware.

No Capítulo 6 é apresentada a conclusão e sugestões de trabalhos futuros para acontinuidade desta pesquisa.

85

6Conclusão e Trabalhos Futuros

O planejamento e execução de manutenções, como também, o monitoramento do estadooperativo dos equipamentos são fatores importantes para a continuidade da operação e docontínuo fornecimento dos serviços prestados à população. Este trabalho apresentou ummodelo de arquitetura de middleware para integração sensível ao contexto de sistemasde 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.

Através de dados e informações contextuais inferidas, as aplicações simuladas eintegradas pelo middleware sensível a contexto, puderam notificar os interessados emeventos diários como bloqueios, desligamentos, normalizações, liberações e normaliza-ções programadas. Esta integração permitiu aos usuários a correta inferência do contextodos eventos e o aumento da eficácia de suas atividades, como também, incrementar asegurança dos procedimentos de planejamento e execução das manutenções operativasatravés do uso da sensibilidade a contexto.

O modelo proposto por esta dissertação difere dos trabalhos relacionados por utilizara sensibilidade a contexto para integração entre os sistemas de gerenciamento de energia.Até o momento da escrita desta dissertação, não foram encontrados na literatura trabalhosque utilizem a sensibilidade a contexto para integrar os sistemas desta área e que fizeramparte do escopo desta pesquisa.

Foi possível simular a rotina operacional de um centro de controle para testar oprotótipo. Comparando-se os resultados dos testes do middleware, com o que foi feitomanualmente pelos operadores, foi alcançado um percentual de acerto significativo(100%) na inferência dos contextos para as ocorrências forçadas e não forçadas.

Também se constatou que aproximadamente 55% dos campos das ocorrências força-das e 76% das não forçadas foram preenchidos automaticamente pelos dados oriundos daintegração e da inferência dos contextos. Desta maneira, existe um forte indício de que o

87

CAPÍTULO 6. CONCLUSÃO E TRABALHOS FUTUROS

processo de registro de ocorrências, pelos operadores, poderá ser acelerado, uma vez quea maioria dos campos estará preenchida e os contextos já inferidos, permitirão minimizaros cancelamentos, como também, eliminar o trabalho de redigitação de dados entre ossistemas envolvidos.

Com base nestes resultados, pode-se afirmar que o modelo de arquitetura propostoneste trabalho permite integrar os sistemas utilizados nos modernos centros de controledas empresas de transmissão de energia, aumentando a eficácia e incrementando asegurança dos procedimentos de planejamento e execução das manutenções operativasatravés do uso da sensibilidade a contexto. Também poderá ser aplicado, com as devidasadaptações, a outros sistemas de gerenciamento como água, geração de energia ou outrossetores.

6.1 Contribuições

As contribuições resultantes deste trabalho de pesquisa e desenvolvimento foram asseguintes:

1. Criação de um modelo de middleware para possibilitar a integração sensível acontexto de sistemas de gerenciamento de energia elétrica.

2. Notificação, em tempo real, dos dados e informações contextuais, para os interessa-dos nos eventos diários de um centro de controle como: bloqueios, desligamentos,normalizações, liberações e normalizações programadas de equipamentos.

3. Automatização do cadastramento de parte dos dados utilizados no registro deocorrências forçadas e não forçadas, através da integração sensível a contexto entreos sistemas dentro do escopo da pesquisa, agilizando o trabalho dos operadores eevitando erros de cadastramento.

6.2 Limitações

Devido à grande quantidade de equipamentos da empresa parceira, não houve tempopara viabilizar o cadastramento do mapeamento de todos os equipamentos dos sistemasenvolvidos, apesar de todos os esforços dispendidos pelas equipes da CTEEP e In FormaSoftware.

88

6.3. TRABALHOS FUTUROS

Desta maneira, limitou-se a um (01) mês a avaliação da taxa de acerto do middleware

na inferência dos contextos para as ocorrências não forçadas, apesar da monitoração doLOG ter sido feita para o primeiro semestre do ano de 2013.

Vislumbrou-se a possibilidade de integrar ao escopo da pesquisa, um sistema demonitoramento de incidência de raios (SISRAIOS). Isto enriqueceria o contexto dosdesligamentos com informações de descargas elétricas na região de um equipamento comdesligamento. Porém, o sistema em questão não disponibilizou uma API externa queviabilizasse tal integração, ficando assim fora do escopo. Ressalta-se que a solução deintegração via Wrapper não seria possível para o SISRAIOS, em virtude da naturezatécnica dos dados que são registrados por este sistema, por exemplo, localização dasinstalações (latitude/longitude), a geometria que se deseja consultar a incidência de raios,entre outras informações.

6.3 Trabalhos Futuros

A empresa CTEEP, que viabilizou este projeto de pesquisa e desenvolvimento, juntamentecom a In Forma Software, já iniciou o processo de utilização do protótipo do middleware

desenvolvido. Primeiramente em seu ambiente de testes/homologação da produção eposteriormente, no seu ambiente de produção. Diante do exposto, dentre os trabalhosfuturos destacam-se:

1. Integrar novos sistemas ao escopo do projeto, a exemplo do sistema de monito-ramento de incidência de raios, citado anteriormente, para enriquecer o contextorelacionado aos desligamentos dos equipamentos.

2. Incrementar o gerenciador de contexto, com a adição de novas regras que permitaminferir novos contextos acerca dos eventos que fazem parte do escopo do projeto.

3. Acompanhar e aferir o ganho com a utilização do middleware, após sua adoçãono ambiente de produção, para constatar efetivamente, a celeridade do registrode ocorrências e a melhoria da segurança nos procedimentos de planejamento emanutenção operativa.

4. Utilizar uma interface mais apropriada, como por exemplo Webservice, na inte-gração com o sistema SCADA utilizado na empresa. Desta forma, minimizam-seos riscos relacionados a mudanças no layout dos arquivos de LOG, entre outrosproblemas.

89

Referências

Amaral, L. A. (2011). Elevando a capacidade de integração de sistemas de middlewareRFID através do processamento de eventos complexos distribuídos entre diferentesorganizações e negócio. Doutorado, Pontificia Universidade Católica do Rio Grande doSul.

ANEEL, A. N. d. E. E. (2007). Resolução normativa n° 270 de 26 de junho de 2007.

Badii, A., Crouch, M., and Lallah, C. (2010). A Context-Awareness Framework forIntelligent Networked Embedded Systems. 2010 Third International Conference onAdvances in Human-Oriented and Personalized Mechanisms, Technologies and Services,pages 105–110.

Belqasmi, F., Singh, J., Bani Melhem, S. Y., and Glitho, R. H. (2012). SOAP-Basedvs. RESTful Web Services: A Case Study for Multimedia Conferencing. IEEE InternetComputing, 16(4), 54–63.

Bettini, C., Brdiczka, O., Henricksen, K., Indulska, J., Nicklas, D., Ranganathan, A., andRiboni, D. (2010). A survey of context modelling and reasoning techniques. Pervasiveand Mobile Computing, 6(2), 161–180.

Capra, L., Emmerich, W., and Mascolo, C. (2003). Carisma: context-aware reflectivemiddleware system for mobile applications. Software Engineering, IEEE Transactionson, 29(10), 929 – 945.

Chan, A. T. and Chuang, S.-N. (2003). Mobipads: A reflective middleware for context-aware mobile computing. IEEE Transactions on Software Engineering, 29, 1072–1085.

Coulouris, G., Dollimore, J., Kindberg, T., and Blair, G. (2011). Distributed Systems:Concepts and Design, volume 5 of International computer science series. Addison-Wesley.

Dey, A. K., Anind, Salber, D., and Abowd, G. D. (2001). A conceptual frameworkand a toolkit for supporting the rapid prototyping of context-aware application. Human-Computer Interaction, 16(2-4), 91–166.

EPE, E. d. P. E. (2013). Anuário Estatístico de Energia Elétrica 2013. EPE, Empresa dePesquisa Energética.

Garlan, D., Siewiorek, D. P., and Steenkiste, P. (2002). Project aura: Toward distraction-free pervasive computing. IEEE Pervasive Computing, 1, 22–31.

Hohpe, G. and Woolf, B. (2004). Enterprise integration patterns: Designing, building,and deploying messaging solutions. Addison-Wesley Longman Publishing Co., Inc.,Boston, MA, USA.

IEC, I. (2008). Energy management system application program interface (EMS-API) -Part 403: Generid data access. Technical report.

91

REFERÊNCIAS BIBLIOGRÁFICAS

IEC, I. (2009). Energy management system application program interface (EMS-API) -Part 1: Guidelines And General Requirements. Technical report.

IEC, I. (2011). Energy management system application program interface (EMS-API)- Part 301: Common information model (CIM) base (iec 61970-301:2011). Technicalreport.

Junior, O. R. (2006). Um modelo de integração entre os padrões IEC 61850 e IEC 61970(CIM/XML). Mestrado, Universidade de São Paulo- USP, Escola Politécnica.

Khare, R., Khadem, M., Moorty, S., Methaprayoon, K., and Zhu, J. (2011). Patternsand practices for cim applications. In Power and Energy Society General Meeting, 2011IEEE, pages 1 –8.

Lendak, I., Varga, E., Erdeljan, A., and Gavric, M. (2010). RESTful web services andthe Common Information Model (CIM). 2010 IEEE International Energy Conference,(Cim), 716–721.

Masiello, R. D. (1985). Computers in power: A welcome invader: Supervisory computersystems cut utility costs by scheduling generating units, planning against outages, andcoordinating the sale of power. IEEE Spectrum, 22(2), 51–59.

Penin, C., Sybine, W., Matayoshi, C., and Cerdan, F. (2012). Common InformationModel: A Bus Service for Electric Calculations in AES Eletropaulo. Journal of Energyand Power Engineering, 6, 965–971.

Pessoa, R. M. (2006). INFRAWARE: Um middleware de Suporte a Aplicações Sensíveisao Contexto. Master’s thesis, Universidade Federal do Espírito Santo.

Raychoudhury, V., Caob, J., Kumarc, M., and Zhangd, D. (2013). Middleware forpervasive computing: A survey. Pervasive and Mobile Computing, 9(2), 177–200.

Romero, D. (2008). Context-Aware Middleware: An overview. Paradigma, 2(3), 1–11.

Román, M., Hess, C., Cerqueira, R., Campbell, R. H., and Nahrstedt, K. (2002). Gaia: Amiddleware infrastructure to enable active spaces. IEEE Pervasive Computing, 1, 74–83.

Sacramento, V., Endler, M., Rubinsztejn, H. K., Gonçalves, L. S. L., Nascimento, F. N.,and Bueno, G. A. (2004). Moca: A middleware for developing collaborative applicationsfor mobile users. IEEE DISTRIBUTED SYSTEMS ONLINE 1541-4922, 5, 1–14.

Sommerville, I. (2007). Software Engineering. Addison-Wesley Publishing Company,USA, 9th edition.

Varga, E., Lendak, I., Gavric, M., and Erdeljan, A. (2011). Applicability of RESTful webservices in control center software integrations. In 2011 International Conference onInnovations in Information Technology, pages 282–286. IEEE.

92

REFERÊNCIAS BIBLIOGRÁFICAS

Veríssimo, P., Cahill, V., Casimiro, A., Cheverst, K., Friday, A., and Kaiser, J. (2002).Cortex: Towards supporting autonomous and cooperating sentient entities. In Proceedingsof European Wireless 2002, pages 595–601, Florence, Italy.

Vieira, V., Tedesco, P., and Salgado, A. C. (2009). Modelos e processo para o desenvol-vimento de sistemas sensíveis ao contexto. In SBC, editor, André Ponce de Leon F. deCarvalho, Tomasz Kowaltowski. (Org. ). Jornadas de Atualização em Informática 2009(JAI’09)., volume 1, pages 381–431. SBC.

Yan, Y., Qian, Y., Sharif, H., and Tipper, D. (2013). A survey on smart grid communicationinfrastructures: Motivations, requirements and challenges. Communications SurveysTutorials, IEEE, 15(1), 5–20.

Zhang, P., Li, F., and Bhatt, N. (2010). Next-generation monitoring, analysis, and controlfor the future smart control center. Smart Grid, IEEE Transactions on, 1(2), 186–192.

93

Apêndice

95

AGrafos e regras drools

Este apêndice apresenta todos os grafos contextuais modelados para representar a inferên-cia dos contextos que são utilizados pelo Context Management Service e suas respectivasregras escritas em Drools.

A.1 Foco: Identificando Bloqueio de Equipamento

Grafo Contextual e regras Drools que modelam e implementam a inferência do contextoquando um equipamento é bloqueado.

Figura A.1 Grafo - Obter bloqueio de equipamento

A.2 Foco: Notificando Desligamentos

Grafo Contextual e regras Drools que modelam e implementam a inferência do contextoquando um equipamento é Desligado. Neste caso, o desligamento pode ser parcial outotal.

97

APÊNDICE A. GRAFOS E REGRAS DROOLS

Figura A.2 Regra - Obter Bloqueio de Equipamento

Figura A.3 Grafo - Notificando desligamentos

Figura A.4 Regra - Desligamento total de uma LT

98

A.3. FOCO: FINALIZANDO DESLIGAMENTOS

Figura A.5 Regra - Desligamento parcial de uma LT

A.3 Foco: Finalizando Desligamentos

Grafo Contextual e regras Drools que modelam e implementam a inferência do contextoquando um equipamento é normalizado. Neste caso, a normalização pode ser parcial outotal.

Figura A.6 Grafo - Finalizando desligamento

99


Figura A.7 Regra - Normalização total de uma LT

Figura A.8 Regra - Normalização parcial de uma LT

100

A.4. FOCO: INFORMANDO LIBERAÇÃO PROGRAMADA

A.4 Foco: Informando Liberação Programada

Grafo Contextual e regras Drools que modelam e implementam a inferência do contextode uma liberação programada. Neste caso, uma liberação programada caracteriza umaocorrência não forçada e que poderá ser com desligamento ou sem desligamento. Tambémexiste uma regra que valida a situação hipotética da liberação ocorrer após a normalizaçãoter acontecido, como também, uma regra que informa ao usuário a necessidade de inserirum TAG de informação do SCADA para uma liberação com desligamento.

Figura A.9 Grafo - Informando liberação programada

Figura A.10 Regra - Ocorrência não forçada e com desligamento

A.5 Foco: Informando Normalização Programada

Grafo Contextual e regra Drools que modelam e implementam a inferência do contextode uma normalização programada. Neste caso, no momento da normalização programadanão deve haver TAG de impedimento operativo no SCADA.

101


Figura A.11 Regra - Ocorrência não forçada e sem desligamento

Figura A.12 Regra - Liberação realizada após normalização

Figura A.13 Regra - Liberação sem registro de TAG no SAGE

102

A.5. FOCO: INFORMANDO NORMALIZAÇÃO PROGRAMADA

Figura A.14 Grafo - Informando normalização programada

Figura A.15 Regra - Liberação sem registro de TAG no SAGE

103

jonysberg peixoto quintino‡… · de gestão e supervisão para planejar e controlar a geração,...

Documents