CITENEL2015-D390

43 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
43
No SlideShare
0
A partir de incorporações
0
Número de incorporações
4
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

CITENEL2015-D390

  1. 1.  Resumo – Este projeto introduz um processamento de alar- me sem usar qualquer informação de conectividade da rede elétrica de uma subestação. Para fazer tal feito, apenas tempo e localização dos alarmes definem padrões de agrupamento. Nes- se sentido, o algoritmo proposto tenta imitar o procedimento típico adotado por operadores experientes. Esse algoritmo es- pecializado permite um reconhecimento rápido dos padrões mais comuns em uma subestação: tipicamente, mais de 70% dos alarmes pertencem aos 3 grupos abordados neste projeto. Testes em um notebook mostram que é possível processar 1.025 alarmes por segundo com uma máquina de estados que modela o comportamento específico de cada grupo, enquanto que uma densidade máxima de alarmes típica é de 1.000 alarmes por minuto. Palavras-chave – Processamento de alarme, sistemas especia- listas, detecção de padrão, conectividade. I. INTRODUÇÃO A CEMIG-D é responsável por operar mais de 400 subes- tações em sua área de concessão. Um único centro de opera- ção centralizado monitora remotamente toda a malha de subtransmissão e distribuição da empresa, constituindo o maior centro de operação da América Latina. Em números, significa a supervisão e controle de aproximadamente 1.000.000 de pontos, entre físicos, virtuais e calculados, Em um sistema de tal magnitude, muitos eventos de falta podem ocorrer simultaneamente e, em um curto período de tempo, a equipe de operação deve analisar todos eles e tomar as me- didas cabíveis para corrigir as causas das faltas. Além disso, é muito comum que um único evento gere uma série de alarmes em cascata, tornando difícil a identificação do even- to causador. Nesse contexto, um processamento automático de alarmes é muito conveniente para dar suporte à minera- ção de dados em tempo real dos operadores. Este trabalho se insere nesse esforço através do projeto de P&D ANEEL “Funções avançadas de EMS II”, código D- Este trabalho foi desenvolvido no âmbito do Programa de Pesquisa e Desenvolvimento Tecnológico do Setor de Energia Elétrica regulado pela ANEEL e consta dos Anais do VIII Congresso de Inovação Tecnológica em Energia Elétrica (VIII CITENEL), realizado na Costa do Sauípe/BA, no período de 17 a 19 de agosto de 2015. Este trabalho foi apoiado parcialmente pelo CNPq, CAPES e FAPEMIG. E. C. Pereira trabalha na CEMIG-D (e-mail: ezequi- el.pereira@cemig.com.br). A. C. Lisboa e D. A. G. Vieira trabalham na ENACOM (adria- no.lisboa@enacom.com.br; douglas.vieira@enacom.com.br). S. R. R. Magalhães trabalha na Concert (sirlene@concert.com.br). 390, proposto pela CEMIG-D e executado pela ENACOM, Asotech e Concert Technologies S/A. O projeto modelou 3 agrupamentos específicos de alar- mes e definiu máquinas de estado para cada um deles. Os grupos são relativos a religamento automático de religadores de subestações (SEs) e de distribuição, operação em modo local e falta em transformadores. Apesar de ser uma aborda- gem especialista, ela permite atingir velocidades relativa- mente altas de processamento. Discussões e testes sobre o processamento de alarmes em subestações sem usar conectividade será apresentado no ERIAC 2015 [1] e no CIRED 2015 [2]. II. COLOCAÇÃO DO PROBLEMA A tecnologia presente nos equipamentos atualmente utili- zados nas subestações permite a captura de um grande vo- lume de informações sobre o estado corrente dos mesmos e, por conseguinte, do sistema que compõem. Com meios de comunicação relativamente de baixo custo, esses dados sempre são enviados para o centro de operação através do sistema SCADA. Tais dados são trabalhados e transforma- dos em uma série de informações disponibilizadas para a operação, incluindo alarmes indicativos de anomalias ou estados de atenção. Por outro lado, a abundância de informações hoje dispo- níveis implica que, mesmo na operação do processo em es- tado estacionário, o sistema de alarmes seja ativado quase que continuamente, criando muito mais ocorrências de alarmes que podem ser possivelmente entendida individu- almente e atuada pelo operador. Ademais, observa-se que muitos dos dados gerados são em decorrência de uma causa única, ou seja, é comum a existência de um conjunto de in- formações que indicam um único problema a ser tratado. O gráfico da Figura 1 ilustra o volume de dados de alarmes gerados no centro de operações da distribuição (COD) da CEMIG-D em um dia típico, onde ocorreram 40.181 alar- mes na alta e média tensão. Figura 1 – Alarmes ocorridos em um dia típico. Processamento automático de alarmes sem uso de informações de conectividade Adriano C. Lisboa, Douglas A. G. Vieira, Ezequiel C. Pereira, Sirlene R. R. Magalhães
  2. 2. A situação se agrava durante ocorrências no sistema elé- trico, visto que há um aumento substancial na magnitude do número e da velocidade de gerações de alarme, tornando o sistema de alarmes um obstáculo a mais para a capacidade do operador para lidar com a situação e identificar a causa raiz dos problemas a serem tratados. Relatórios de investi- gação após grandes ocorrências têm demonstrado que siste- mas de alarmes ignorados ou sobrecarregados desempenham um papel significativo no agravamento da ocorrência, fa- zendo com que incidentes simples durem e custem mais do que o normal. A Figura 2 ilustra o volume de dados de alarmes gerados no COD da CEMIG-D em um dia atípico, com ocorrência de 36.161 alarmes no sistema elétrico da alta e média ten- são. Nesse dia ocorreu corte de carga pela ONS, e no inter- valo de 13:00 às 19:00 foram gerados um total de 14.261 alarmes. Comparando-se com o dia típico apresentado, para aquele, no mesmo intervalo de horário, foram gerados 9.827 alarmes. Figura 2 – Alarmes ocorridos em um dia atípico. O problema da gestão de alarmes começou a ser identifi- cado e estudado no início da década de 90. Em 2009, o pa- drão ANSI/ISA-18.2 Alarm Management [19] foi disponibi- lizado. Atualmente, a gestão de alarmes é um tópico farta- mente documentado. Uma gestão de alarmes apropriada resulta em aumento da segurança e confiabilidade do processo e, por conseguin- te, na redução de custos. O sistema de alarmes deve ter por objetivo mitigar riscos e garantir que situações de anormali- dade cheguem ao conhecimento dos operadores de forma que eles possam atuar devidamente na sua solução. Para tanto, o sistema de alarmes tem que ser uma ferramenta que sempre e efetivamente ajude o operador a realizar a ação devida no tempo devido. Isso apenas será verdade se: - os alarmes foram devidamente escolhidos e implemen- tados; - os alarmes são relevantes, claros e fáceis de entender; - os alarmes são configurados de forma consistente e em conformidade com as melhores práticas de sua área de atuação; - os alarmes são gerados em uma taxa que o operador pode tratar efetivamente; - os operadores podem identificar rapidamente a locali- zação e importância relativa de todos os alarmes gera- dos; - os operadores podem processar as informações de alarmes durante eventuais avalanches; - o sistema de alarmes pode ser devidamente controlado, monitorado e mantido. Se essas premissas não são aplicadas no sistema de alarmes, pode ocorrer uma perda da capacidade de atuação nas situações de contingência. O sistema de alarmes ideal não pode produzir mais alarmes do que operador é capaz de tratar. Baseado no volume de dados tratados, no desempenho que você precisa que seu sistema de alarmes atinja e na na- tureza do seu processo, pode ser necessário implementar soluções de manipulação de alarmes mais avançadas, tais como: - Alarm shelving: dispor de um modo seguro de desabili- tar temporariamente a geração de alarmes até que o problema por trás do mesmo seja corrigido. Para a im- plementação segura desse recurso, o sistema de alar- mes deve contar com recursos de listagem de alarmes inibidos, lembretes da existência de alarmes nessa con- dição, e até mesmo auto reativação dos pontos inibi- dos, se necessário. Deve ser impossível inibir um alar- me e esquecê-lo nesse estado. - Alarmes baseados em estado do sistema elétrico: dis- por de algoritmos que detectem quando o sistema elé- trico muda seu estado operativo e alterem dinamica- mente as configurações de alarme para atender aos re- quisitos de cada estado do cenário operativo atual. - Funções de supressão de avalanches: dispor de funções voltadas para o tratamento de avalanches, como por exemplo: - Tempo morto: tempo mínimo, configurável por ponto, em que o ponto deve permanecer em um fai- xa de valor ou estado para que o alarme seja efeti- vamente gerado. - Banda morta: variação mínima em valor absoluto e percentual, configurável por ponto, para que o sis- tema reconheça o novo valor. - Tratamento inteligente de alarmes: apesar da relevân- cia de saber e registrar em log todos os alarmes dispa- rados, ações que contribuam para agilizar a atuação do operador, tais como agrupamento de alarmes relacio- nados a uma mesma causa é muito conveniente, como mostrado nas Figuras 3, 4 e 5. Com tal automação, o operador pode prontamente distinguir eventos de falta concorrentes. Esse trabalho descreve uma abordagem simplificada, po- rém eficaz, de tratamento inteligente de alarmes que realiza o agrupamento de alarmes ocasionados por uma mesma cau- sa raiz, sem a necessidade de utilização de informações de conectividade. A. Estado da arte Processamento de alarme tipicamente procura por infor- mações chave que indicam a causa do alarme de forma a
  3. 3. agrupar alarmes relacionados. Para uma inferência exata, tipicamente toda a subestação é modelada (i.e. componentes e a conectividade entre eles) [3][4] de forma que uma for- mulação exata de otimização possa determinar a localização da falta [5][6]. Essa localização exata de falta herda um alto custo computacional e pode não ser adequada para operação em tempo real em sistemas de grande escala. A aplicabilidade do uso de dados provenientes de disposi- tivos elétricos inteligentes já foi abordada [11], onde os da- dos devem ser acumulados em um centro para serem proces- sados. Nesse sentido, o uso de inferência nebulosa com re- des de Petri foi bem estudado para estimar o vão em falta [12][13][14]. Um projeto ótimo desse tipo de rede está dis- ponível na literatura [15]. Dados lógicos operacionais de relés digitais de proteção podem ser usados como entradas para melhorar a interpretação de alarmes [16]. Em proteção por digital, a informação de elementos de proteção é usual- mente na forma de lógica operacional [17]. De forma a melhorar o desempenho computacional mas sem perder em acurácia, estratégias de reconhecimento de padrões foram propostas [7][8][9]. Nessa estratégia, um mo- delo acurado da subestação é usualmente não necessário, o que inclui a conectividade de componentes. Ao invés disso, dados de alarmes coletados de uma subestação são usados para treinar e extrair padrões associados a faltas. Uma vez identificados os padrões, eles podem também ser processa- dos usando algoritmos padrões [10]. Esse processamento de alarme é mais geral e mais fácil de implementar e manter, mas é apenas uma aproximação. Este projeto deu um passo adiante na estratégia de reco- nhecimento de padrões: foram considerados apenas 3 pa- drões que respondem por mais de 70% das faltas, foi utiliza- do um processamento especializado e foi utilizada apenas a informação de tempo e localização do alarme para acelerar o processo. Como resultado, tipicamente cerca de mil alarmes podem ser processados por segundo em um computador padrão. As origens dessa estratégia estão na tentativa de imitar o procedimento dos próprios operadores mais experi- entes do sistema. III. METODOLOGIA A. Agrupamento De forma a processar exatamente cada alarme e associá-lo com o correto evento causador, é necessário saber todos os componentes da subestação e a conectividade entre eles. Entretanto, é possível processar os eventos de falta mais frequentes sem informação de conectividade e ainda atingir resultados satisfatórios: saber onde está cada componente e o tempo em que cada alarme foi gerado já são suficientes. Essa estratégia para processamento de alarme simplifica enormemente os algoritmos de processamento e reduz signi- ficativamente o esforço de manter o banco de dados de en- trada. Além disso, essa é normalmente a estratégia utilizada pelo operador quando não está disponível um processador automático de alarmes. Este projeto considera os tipos de agrupamento mais co- muns no cenário das ocorrências de subestações: religamen- to automático de religadores (Figura 3), operação em modo local (Figura ) e falta em transformador (Figura 5). Esses três grupos respondem tipicamente por mais de 70% dos eventos em uma subestação. 1) Religamento automático Quando um religador abre para proteger o sistema, ele dispara muitos alarmes no mesmo vão, os quais podem ser agrupados por um mesmo evento causador, como mostrado na Figura 3. Além disso, religadores tipicamente tentam religar automaticamente depois de algum tempo de forma a reestabelecer o sistema e, depois de três tentativas, eles pa- ram de tentar. Essa fonte muito comum de alarme pode ser rapidamente e precisamente identificada se tratada de uma forma especializada. Figura 3 – Grupo de religamento automático. 2) Operação em modo local Quando um vão está operando em modo local, usualmen- te para execução de testes, todos os alarmes gerados nele não precisam de qualquer atuação do operador. Nesse caso, cada alarme gerado naquele vão pode ser agrupado em um único grupo de alarmes que indica o modo local de opera- ção, conforme mostrado na Figura 4. Figura 4 – Grupo de operação em modo local. 3) Falta em transformador Quando um transformador entra no estado de falta, ele ti- picamente afeta toda a subestação de forma que qualquer alarme gerado naquela subestação perto daquele momento pode ser agrupado. Esse tipo de falta é tipicamente identifi- cada pela atuação do relé 86, conforme mostrado na Figura 5. Figura 5 – Grupo de falta em transformador. B. Máquina de estados Uma máquina de estados é mantida para cada área da su- bestação relacionada a um tipo de agrupamento de alarmes. Essa máquina de estados é implementada eficientemente mantendo apenas dados de alarmes ativos, de forma que máquinas de estado em estado inicial não são armazenadas. Foram definidas três máquinas de estado, uma para cada tipo de agrupamento. Essas máquinas de estado são agrupa- das em uma máquina de estado global e cada estado induz uma forma distinta de consumir um novo alarme.
  4. 4. 1) Máquina de estados para religamento automático Quando um religador abre devido a uma falta na rede, ele automaticamente tenta religar depois de algum tempo. Se ele fecha e a falta persiste, ele abre novamente. Ele tentará reli- gar até três vezes. A máquina de estados para o religamento automático, mostrada na Figura 6, captura esse comporta- mento: 0, 1, 2 e 3 são estados relacionados ao número de aberturas do religador e 1AR, 2AR e 3AR são estados rela- cionados aos religamentos automáticos. Se um religamento automático é bem-sucedido (i.e. a falta não persiste), a má- quina de estado retorna ao estado inicial depois de esperar um tempo para abrir to (tipicamente 30 segundos). De forma similar, se o religamento não ocorre depois de esperar um tempo tc (tipicamente 3 minutos), a máquina de estados re- torna ao estado inicial. Figura 6 – Máquina de estados para o religamento automático. 2) Máquina de estados para operação em modo local A máquina de estados para operação em modo local é a mais simples. Ela é composta de dois estados: estados remo- to e local, como mostrado na Figura 7. A máquina de esta- dos é dada pelos respectivos disparos. Note que não tem tempo de espera, de forma que se a notificação de mudança de modo de operação não chegar, a máquina fica travada no estado incorreto. Apesar de indesejado, é inevitável esse comportamento. Figura 7 – Máquina de estados para a operação em modo local. 3) Máquina de estados para transformador em falta A máquina de estados para um transformador em falta é também bem simples: estados normal e de falta, como mos- trado na Figura 8. A máquina de estados entra em estado de falta depois da atuação do respectivo relé 86. Cada evento na mesma subestação dentro de um tempo tf (tipicamente 1 segundo) pode ser associado à falta no transformador como uma aproximação. Portanto, depois de passar esse tempo, a máquina de estados volta ao seu estado inicial, mesmo que o transformador permaneça em falta. Figura 8 – Máquina de estados para o transformador em falta. 4) Máquina de estados global As três máquinas de estado apresentadas anteriormente rodam concorrentemente para cada área em uma máquina de estados global única. Portanto, prioridades devem ser esta- belecidas entre elas. Uma prioridade natural para entrega de alarmes para uma máquina de estados específica é, da mais alta para mais baixa prioridade, modo local de operação, transformador em falta e religamento automático. Essa or- dem de prioridade é considerada mesmo se uma máquina de estado de menor prioridade não está em estado inicial. Por exemplo, se o religador está esperando para seu segundo religamento automático e seu vão entra em modo de opera- ção local, então o grupo de religamento automático é finali- zado e um grupo de operação em modo local é iniciado. 5) Ordenação de alarmes Alarmes podem chegar fora de ordem no processador de alarmes, de forma que eles devem ser reordenados e repro- cessados. Isso pode ser eficientemente implementado man- tendo o estado da máquina de estados no tempo t - t, de forma que os alarmes processados para o tempo t são dados pela ordenação e reprocessamento de todos os alarmes de t - t até t toda vez que um novo alarme chega no tempo t. Nesse algoritmo, t é o máximo atraso esperado para um alarme chegar no processador. Alarmes que chegam com atraso maior que t são simplesmente desprezados. O pro- cedimento de ordenação de alarmes está ilustrado na Figura 9. Figura 9 - Ordenamento de alarmes: um novo alarme é ordenado no buf- fer e processado para gerar grupos G começando dos grupos já processados G’. 6) Processamento de alarmes Depois de atualizar a máquina de estados global do pro- cessador de alarmes, o alarme que chega é possivelmente associado a um grupo de alarmes. Essa associação é direta considerando o tempo, lugar e tipo do alarme que chega dado o estado corrente da máquina de estados global. Por exemplo, cada alarme gerado em uma subestação onde um 0 1 1RA 2 2RA 3 3RA aberto fechado aberto aberto tototo tc tc tc fechado fechado remoto local disparo localdisparo remote ok falta relé 86tf novo alarme } alarmes nos últimos a serem processados até a partir de Dt G G’ } alarmes já processados em G’ 1 2 3 4 5 6 7 8 9 10 12 11
  5. 5. transformador se encontra em falta é agrupado. Com estrutu- ra de dados apropriadas para comparar lugar e tempo entre novos alarmes e grupos ativos (e.g. tipicamente tabelas hash), esse processador de alarmes pode atingir taxas de processamento altas, mesmo para várias subestações e dis- positivos. O tempo para processar cada alarme é função do número n de grupos ativos e o número m de alarmes do buf- fer, de modo que o tempo esperado com tabelas hash é O(m), mas O(nm) no pior caso. O tempo de ordenação do buffer é mantido fora do pro- cessamento de alarmes em si: o buffer é atualizado e repro- cessado cada vez que chega um novo alarme. Seria mais rápido tratar essa ordenação dentro da máquina de estados, mas muito mais complexo de implementar e manter o códi- go. O pseudocódigo do buffer de alarmes é dado a seguir: 1. atualiza tempo atual 2. remove alarmes do buffer mais antigos que t 3. if o novo alarme está na ordem cronológica then 4. adiciona novo alarme ao buffer 5. processa novo alarme 6. else 7. reordena buffer de alarme 8. reprocessa alarme por alarme de todo o buffer 9. endif Já o pseudocódigo simplificado do processador de alar- mes em si é dado a seguir: 1. identifica grupo ativo na mesma subestação 2. identifica grupo ativo no mesmo vão 3. if alarme pertence a algum grupo ativo then 4. adiciona alarme ao grupo 5. if alarme é chave de grupo then 6. atualiza máquina de estados 7. atualiza grupo no histórico 8. endif 9. else 10. adiciona alarme ao histórico 11. endif A interface do processador de alarmes é dada por alarm = alarmprocessing(event,alarm,options) onde event contém toda a informação relativa ao novo alarme (e.g. etiqueta, subestação, vão, descrição), alarme contém toda a máquina de estados e alarmes processados, e options contém as opções do processador de alarmes (e.g. tempo máximo de espera para tentativa de religamento do religador, tempo de buffer para reordenação de alarmes). 7) Entrada e saída de dados O processador de alarmes trabalha com uma estrutura de dados padrão, tanto para os alarmes que chegam, quanto para os alarmes processados. Conversores devem ser utili- zados tanto para colocar no padrão as informações do alar- me que chega, como também para colocar as informações dos alarmes processados no padrão desejado. No projeto, o processador de alarmes foi integrado ao SCADA xOMNI SG, produzido pela Concert Technologies S/A e em uso no Centro de Operação da Distribuição (COD) da CEMIG-D, mas poderia ter sido adicionado a qualquer sistema de moni- toramento de alarmes em subestações. IV. INTEGRAÇÃO NO SISTEMA O resultado do módulo de processamento inteligente de alarmes foi incorporado ao sistema SCADA xOMNI SG através da disponibilização de um novo aplicativo de visua- lização de alarmes e eventos. A. O Sistema xOMNI SG Um dos grandes desafios lançados ao Sistema xOMNI, que culminou na evolução xOMNI SG, foi o de capacitá-lo para o atendimento de um centro de operação de distribuição centralizado, responsável por toda a malha de concessão da CEMIG-D: o que antes era atendido por sete centros de ope- ração deveria passar a ser operado a partir de apenas um. Essa mudança de arquitetura de implantação implicava dire- tamente em necessidade de aumento significativo da capaci- dade de processamento do sistema e de atendimento de um número igualmente elevado de clientes e IHMs. Tudo isso mantendo os parâmetros de confiabilidade, disponibilidade e tempo de resposta dentro dos padrões exigidos para sistemas SCADA voltados para operação do sistema elétrico. A necessidade da CEMIG-D, juntamente com as novas demandas associadas à era Smart Grid e a evolução tecnoló- gica que ela encerra, elevou os requisitos associados com capacidade de processamento, flexibilidade e facilidade de expansão e integração corporativa, robustez, confiabilidade e disponibilidade a um novo patamar. Foram essas exigências que nortearam a completa reestru- turação do Sistema xOMNI. Novas tecnologias e conceitos foram adotados para que esses objetivos pudessem ser ple- namente atendidos. Entre esses, dois se destacam na compo- sição da solução e são apresentados nas subseções seguintes: cluster funcional e modelo de arquitetura produtor- distribuidor-consumidor. 1) Cluster funcional O conceito de “kernel”, usualmente adotado em sistemas SCADA, encerra um acoplamento existencial entre as tare- fas essenciais do sistema. Essa condição implica negativa- mente na disponibilidade desses sistemas. Nesse sentido, o xOMNI SG adotou o conceito de “clus- ter funcional” em substituição ao antigo conceito de “ker- nel”. No que tange ao xOMNI SG, um cluster funcional é composto por tarefas produtoras (ou gerenciadoras) e tarefas distribuidoras (ou servidoras) que agrupam funções interli- gadas aos serviços prestados por aquele cluster. Os clusters funcionais, por construção, são independentes entre si, sen- do que a ausência de um determinado cluster implica apenas na indisponibilidade dos dados e serviços prestados pelo mesmo. O xOMNI SG, em sua versão de lançamento, é composto por nove diferentes clusters funcionais que, em conjunto, englobam todas as funções SCADA: recepção e disponibili- zação de dados de tempo real e processados, manipulação da base de dados de persistência, gerência de dados históricos, de logs e planos operacionais, funções E.M.S, ICCP e IHM. A Figura 10 ilustra um dos clusters funcionais do xOMNI SG, seus gerenciadores, servidores e clientes.
  6. 6. Figura 10 - Cluster DTR do xOMNI SG. Ao conjunto de tarefas que compõem um certo cluster funcional que se encontra em execução denomina-se nó da- quele cluster. Ressalta-se que nós de clusters funcionais dis- tintos podem compartilhar uma mesma máquina servidora. Todo cluster funcional do xOMNI SG possui um nó ou principal (master), que é o responsável por atender às solici- tações dos clientes dos serviços por ele prestados, e permi- tem a existência simultânea de diversos nós reservas (sla- ves), aptos a assumir a condição de principal quando neces- sário. A implementação do software garante que todos os nós de cada cluster sejam mantidos atualizados com todas as in- formações que lhe são pertinentes. Dessa forma, se uma máquina onde nós de clusters ou a sua rede local falhar, ou- tros nós daqueles clusters assumem o controle automatica- mente, sem necessidade de nenhuma intervenção do usuário ou dos administradores do sistema. Cabe ainda ressaltar que a instanciação de um nó de um cluster não interfere no fun- cionamento dos demais nós daquele cluster ou de outros clusters que estejam em execução. Essa característica permi- te que os nós dos clusters possam ser instanciados automati- camente, pois a operação do sistema não sofre nenhum tipo de interferência. A adoção do conceito de cluster funcional permite ainda que a necessidade operacional do cliente defina a arquitetura de implantação de cada cluster de forma independente, in- clusive em questões relacionadas à quantidade de nós de cada cluster que devem ser instanciados: o xOMNI SG pode ser implantado tanto para atendimento de um site centraliza- do quanto de uma IHM local de uma subestação. 2) O modelo produtor-distribuidor-consumidor O modelo PDC [20] foi criado para modelar o tráfego pe- riódico e de tempo real de variáveis em barramentos de alta velocidade. Esse modelo define que, em um sistema que tal, sempre existirá um único produtor de uma informação/valor e um ou mais consumidores interessados nessa informa- ção/valor. A partir dessa constatação, introduz-se um tercei- ro agente: o distribuidor. Assim, o distribuidor é uma aplica- ção cuja responsabilidade é transferir os dados das variáveis de seu produtor para os seus consumidores. O modelo PDC possui algumas semelhanças com o mo- delo de memória compartilhada distribuída, porém inclui a existência de um buffer de dados por variável, do lado do produtor e do lado do consumidor. Nesse arranjo, cada nova informação inserida no buffer do produtor é transferida pe- los distribuidores para o buffer do consumidor. Comparativamente ao modelo convencional cliente- servidor, o modelo PDC oferece várias vantagens, entre as quais cabe destacar [20]: a) produtor e consumidores não precisam ser sincronizados; (No modelo cliente-servidor, um consumidor deve so- licitar explicitamente o objeto e esperar até que o servi- dor o atenda. Esse atraso é claramente prejudicial à aplicação cliente. O modelo cliente-servidor permite a solicitação de agendamento pelos clientes, mas essa funcionalidade é difícil de ser implementada porque precisa levar em consideração o comportamento desse cliente. Já no modelo PDC, o agendamento pode ser fa- cilmente realizado, bastando para tanto, incluir infor- mações adicionais ao valor da variável no buffer.) b) o controle de fluxo não é necessário em função da existência do buffer; c) o modelo PDC provê mecanismos simples para identificação e recuperação de falhas eventuais no processo de transferência dos dados, sendo essa responsabilidade atribuída ao consumidor. O xOMNI SG incorpora algumas características do mode- lo PDC, definindo única e inequivocamente a tarefa “produ- tora” para cada cluster funcional, estabelecendo o buffer de dados por variável e instituindo a camada de tarefas distri- buidoras, as quais atenderão as demandas dos consumidores dos serviços providos por aquele cluster. Essas propriedades permitem garantir a integridade dos dados disponibilizados e deixa o produtor “livre” para exercer a sua atividade fim, que é a de produzir as informações de sua responsabilidade. Tal arranjo traduz-se diretamente em flexibilidade para ex- pansão bem como em aumento significativo da capacidade de processamento dos produtores e do número de clientes passíveis de serem atendidos. Salienta-se que não há limitação quanto ao número de dis- tribuidores que um nó de um cluster pode possuir. É possí- vel definir a instanciação de distribuidores de forma a per- mitir atendimento dedicado para cada cliente daquele cluster (peer to peer), para um conjunto de clientes específicos, para cada máquina ou conjunto de máquinas onde seus cli- entes estejam em execução. B. Visualizador de alarmes e eventos O visualizador de alarmes e eventos foi desenvolvido com tecnologia web de última geração (em especial HTML5 e Java Script) e incorpora várias funções associadas com a gestão de alarmes, incluindo o algoritmo de inteligência de tratamento de alarmes, fruto do trabalho de pesquisa desse projeto e que foi descrito anteriormente. O visualizador de alarmes e eventos se integra ao sistema xOMNI SG como qualquer outra aplicação cliente que faz parte de seu conjunto de aplicativos. Nesse sentido, o visua- lizador de alarmes e eventos também é um cliente dos clus- ters funcionais que compõem o sistema. Os dados de alarmes e eventos são recebidos a partir do cluster de log. Dados de acesso de usuários são recebidos do cluster DTR e dados de eventos de usuários são recebidos a
  7. 7. partir do cluster SQL. As ações de operação de reconheci- mento de alarmes realizadas no visualizador de alarmes e eventos são repassadas para o cluster de log e as ações de silenciar de buzina e seleção de alarme para carregamento de sinótico são repassadas ao cluster SQL para que seja ge- rado o evento de usuário. A Figura 11 apresenta o visualizador de alarmes e eventos e os clusters funcionais do xOMNI SG com os quais intera- ge. Figura 11 – Integração entre visualizador de alarmes e eventos e o xO- MNI SG. Funcionalmente, o visualizador de alarmes e eventos possui as mesmas características existentes no visualizador de alarmes e eventos padrão do sistema. Contudo, tais funcio- nalidades foram organizadas de forma mais intuitiva, com o objetivo de facilitar a operação a partir do aplicativo e au- mentar a eficiência de operação por parte dos seus usuários. Além das funções habituais de aplicações de visualização de alarmes, tais como silenciamento de buzina, reconheci- mento e inibição de alarmes e configuração de perfis de usuário, o visualizador de alarmes e eventos desenvolvido incorpora várias outras funções associadas com o seu aspec- to visual e usabilidade como, por exemplo, a possibilidade de seleção da área de atuação no momento do login e altera- ção da mesma em tempo de execução, alteração do esquema de cores em uso e interface dedicada à listagem de pontos inibidos para geração de alarme, para e pelo o usuário. Em especial, com relação ao tratamento inteligente de alarmes, a aplicação permite que o usuário habilite ou não a sua atuação. Em sendo habilitada essa função, as ocorrên- cias de alarmes de religamento automático, operação local das subestações e de atuação do relé 86 (proteção do trans- formador) são agrupadas em uma única ocorrência, que sin- tetiza o fato causador dos alarmes. Ressalta-se que os alar- mes agrupados sob uma ocorrência permanecem disponíveis para visualização, caso o operador deseje averiguar algum detalhe desses alarmes, mas a atualização do mesmo no vi- sualizador não gera o som da buzina. A utilização do novo visualizador de alarmes e eventos no ambiente de operação traduz-se em eficiência operacional, uma vez que atua no sentido de reduzir o número de alarmes tratados pelo operador. 1) Interface com usuário A interface principal do visualizador de alarmes e eventos é apresentada na Figura 12. Já na tela principal é possível identificar algumas inovações, tais como mecanismo de pa- ginação de alarmes, configuração de ordem de apresentação das colunas através de drag and drop, possibilidade de or- denação ascendente/descendente e de aplicação de filtro de visualização a partir de cada coluna exibida. Outra inovação é a indicação visual do alarme que está tocando a buzina, tanto na barra de notificações quanto por ícone indicativo de buzina na linha da ocorrência. Figura 12 – Tela principal do visualizador de alarmes e eventos. A forma de visualização dos alarmes pendentes e dos alarmes não reconhecidos foi redesenhada e ganhou interfa- ces dedicadas, facilitando a identificação das ocorrências nestas condições. A partir da interface principal o usuário pode identificar, a partir de números indicativos localizados sobre os botões de acesso às interfaces dedicadas, quantos alarmes se encontram nessas condições. Já a partir das inter- faces dedicadas, além de visualizar as ocorrências, os opera- dores podem silenciar e reconhecer os alarmes, conforme mostrado na Figura 13. Figura 13 – Interface dedicada aos alarmes pendentes. As interfaces dedicadas aos alarmes pendentes e não re- conhecidos também contam com os mesmos recursos da interface principal associados com ordenação de colunas e ocorrências, paginação e filtros. A ação de inibição de alarme (alarm shelving) foi simpli- ficada no novo visualizador de alarmes e eventos. Agora, para se inibir alarme de algum ponto que esteja gerando alarmes em demasia devido a problemas físicos no equipa- mento associado, basta que se selecione uma ocorrência de alarme desse ponto e, em seguida, acione-se o botão de ini- bição do alarme presente na barra de botões do aplicativo. Adicionalmente, o novo visualizador de alarmes foi acrescido de interface dedicada à visualização de pontos inibidos, a partir da qual a ação de restaurar os pontos inibi- dos é realizada. A Figura 14 apresenta a interface de visuali- zação de alarmes inibidos.
  8. 8. Figura 14 – Lista de alarmes inibidos pelo usuário. O visualizador de alarmes e eventos também disponibiliza várias ações de customização de uso. Entre elas, existem opções de configurações gerais, esquemas de cores e perfis de usuário. Dentre as configurações gerais, é facultada ao usuário a definição do número de ocorrências que deseja visualizar em cada página da interface principal e nas interfaces de pop-up: alarmes pendentes, não reconhecidos e inibidos. A interface da Figura 15 apresenta as opções de configuração geral da aplicação. Figura 15 – Configurações gerais do visualizador de alarmes e eventos. A interface da Figura 16 apresenta as opções de customi- zação dos esquemas de cores utilizados na aplicação. O usu- ário pode escolher o tema geral de cores a ser aplicado den- tre o conjunto disponibilizado. Ademais, pode configurar os padrões de cores das próprias ocorrências em função de seu status, prioridade e origem. A alternação de visualização dos esquemas de cores das ocorrências se dá a partir de botões presentes na barra de botões do aplicativo. Também é possí- vel a definição das cores utilizadas para os eventos comuns, sonoros e comentários de operadores. Figura 16 – Configurações de esquemas de cores do visualizador de alarmes e eventos. A interface da Figura 17 apresenta as opções de ativação do tratamento inteligente de alarmes. Os usuários podem escolher, entre as opções existentes, aquelas que desejam que o visualizador de alarmes e eventos processe. Em sendo ativado algum dos critérios, os alarmes que atendam ao tipo de ocorrência selecionado passam a ser apresentados agru- pados na interface principal. Figura 17 – Configurações de ativação de tratamento inteligente de alarmes. A interface da Figura 18 apresenta a atuação do tratamen- to inteligente de alarmes na interface principal. Figura 18 – Exemplo de aplicação do tratamento inteligente.
  9. 9. Pode-se observar o agrupamento de alarmes de religa- mento automático não satisfatórios (RANS), onde o religa- dor não consegue permanecer fechado, com destaque para a lista contendo os alarmes que foram categorizados como consequentes do alarme tratado. V. RESULTADOS Um protótipo do processador de alarmes codificado em 695 linhas de programação na linguagem MATLAB (inclu- indo linhas de comentários e formatação) usando uma im- plementação da máquina de estados global descrita neste artigo foi capaz de processar 1.025 alarmes por segundo em um notebook padrão sobre uma base de dados real da CEMIG-D com 36.182 alarmes de um dia chuvoso, como estimado na Figura 19. Isso é mais do que necessário para fornecer uma resposta em tempo real para o operador, con- siderando a densidade máxima típica de 1.000 alarmes por minuto mostrada na Figura 20. Figura 19 – Histograma do tempo médio de processamento de cada alarme dentro de uma janela de tempo de tamanho 50 alarmes. Figura 20 – Número de alarmes em cada minuto em um dia chuvoso típico. Nesse estudo de caso, 55 grupos foram identificados, to- dos eles relacionados a religamentos automáticos. A Figura 21 mostra o número de agrupamentos de alarmes por minu- to, que não foi maior que três. Figura 21 – Número de agrupamentos de alarmes em cada minuto para o caso estudado. Devido à granularidade do algoritmo de processamento de alarmes, a performance apresentada nesta seção foi melho- rada significativamente na solução desenvolvida e incorpo- rada ao sistema xOMNI SG, visto que a máquina de estados foi implementada na linguagem compilada C. VI. CONCLUSÕES O projeto de P&D ANEEL proposto pela CEMIG-D pro- porcionou o estudo e o desenvolvimento de um processador de alarmes rápido e específico para alguns padrões mais comuns. Ele tem suas origens na observação cuidadosa do sistema, acumulada diariamente pelos operadores, e resulta em uma complexa máquina de estados. Todo esse trabalho foi recompensado por um processador de alarme rápido com acurácia aceitável. De fato, no caso apresentado neste traba- lho, os resultados foram 100% corretos relativamente ao que era esperado dele. Esse um típico balanço em engenharia: generalidade e velocidade. Uma estratégia híbrida pode ser considerada, desde que estratégias têm vantagens específicas entre si. Por exemplo, para o tempo real, uma estratégia como desenvolvida neste projeto é mais adequada. Para uma análise pós-evento, uma abordagem exata é mais adequada. A busca por padrões pode ajudar a identificar grupos de alarmes para fazer futu- ras especializações em máquinas de estados. A abordagem usada neste projeto vai na direção de mode- lar o sistema. Se mais informação é adicionada ao modelo, até mesmo conectividade, máquinas de estado mais acuradas e complexas serão obtidas. A complexidade da máquina de estados vai dizer o limite de aplicação dessa estratégia. De qualquer forma, nós acreditamos que é necessário modelar apenas um pequeno número de agrupamentos para cobrir a maior parte dos eventos que acontecem no mundo real. De fato, o religamento automático já responde sozinho pela maioria dos agrupamentos desejados. VII. AGRADECIMENTOS Gostaríamos de agradecer ao engenheiro Euler Henriques Teixeira e também ao operador Anderson Siqueira Nogueira por suas contribuições por meio da experiência valiosa em processamento de alarmes acumulada em suas vidas, que ajudaram em muito a definir e inspirar o processador de alarmes deste projeto. VIII. REFERÊNCIAS BIBLIOGRÁFICAS [1] A. C. Lisboa, D. A. G. Vieira, R. M. Aquini, E. C. Pereira, “Alarm processing of substations without connectivity information,” a ser pu- blicado nos Proceedings of XVI ERIAC, 2015. [2] A. C. Lisboa, E. C. Pereira, D. A. G. Vieira, “Fast alarm processing without connectivity information,” a ser publicado nos Proceedings of 23rd CIRED, 2015. [3] A. Bauer, A. Botea, A. Grastien, P. Haslum, J. Rintanen, “Alarm processing with model-based diagnosis of event discrete systems,” Proceedings of the AI for an Intelligent Planet, 2011. [4] W. Guo, F. Wen, Z. Liao, L. Wei, J. Xin, “An analytic model-based approach for power system alarm processing employing temporal constraint network,” IEEE Transactions on Power Delivery, vol. 25, nº 4, pp. 2435-2447, 2010. [5] P. C. Fritzen, J. M. Zauk, G. Cardoso Jr., A. L. Oliveira, O. C. B. Araújo, “Hybrid system based on constructive heuristic and integer programming for the solution of problems of fault section estimation and alarm processing in power systems,” Electric Power Systems Re- search, vol. 90, pp. 55-66, 2012. [6] F. B. Leão, R. A. F. Pereira, J. R. S. Mantovani, “Fault section estima- tion in electric power systems using an optimization immune algo- rithm,” Electric Power Systems Research, vol. 80, pp. 1341-1352, 2010. 0 0.001 0.002 0.003 0.004 0.005 0.006 0.007 0.008 0.009 0.01 0 0.5 1 1.5 2 2.5 3 x 10 4 processing time (seconds) count 0 500 1000 1500 0 0.5 1 1.5 2 2.5 3 day minute groupedalarms
  10. 10. [7] J. Meléndez, O. Quiroga, S. Herraiz, “Analysis of sequences of events for the characterisation of faults in power systems,” Electric Power Systems Research, vol. 87, pp. 2-30, 2012. [8] L. Wei, W. Guo, F. Wen, G. Ledwich, Z. Liao, J. Xin, “An online intelligent alarm-processing system for digital substations”, IEEE Transactions on Power Delivery, vol. 26, nº 3, pp. 1615-164, 2011. [9] Z. A. Vale, A. M. Moura, “An expert system with temporal reasoning for alarm processing in power system control centers,” IEEE Transac- tions on Power Systems, vol. 8 no. 3, pp. 1307-1314, 1993. [10] J. Pei, J. Han, B. Mortazavi-Asl, J. Wang, H. Pinto, Q. Chen, U. Dayal, M.-C. Hsu, “Mining Sequential Patterns by Pattern-Growth: The PrefixSpan Approach,” IEEE Transactions on Knowledge and Data Engineering, vol. 16, no. 11, pp. 1424-1440, 2004. [11] P. Dutta, Y. Guan, M. Kezunovic, “Use of substation IED data for improved processing and fault location,” Proceedings of the 40th Pow- er Symposium, 2008. [12] S. M. Chen, J. S. Ke, J. F. Chang, “Knowledge representation using fuzzy Petri nets,” IEEE Transactions on Knowledge and Data Engi- neering, vol. 2, no. 3, pp. 311-319, 1990. [13] T. V. Manoj, J. Leena, R. B. Soney, “Knowledge representation using fuzzy Petri nets revisited,” IEEE Transactions on Knowledge and Da- ta Engineering, vol. 4, no. 10, pp. 666-667, 1998. [14] M. M. Gao, M. C. Zhou, X. G. Huang, Z. M. Wu, “Fuzzy reasoning Petri nets,” IEEE Transactions on Systems, Management and Cyber- netics, vol. 33, no. 3, pp. 314-324, 2003. [15] J. Sun, S. Y. Qin, Y. H. Song, “Fault diagnosis of electric power sustems based on fuzzy Petri nets,” IEEE Transaction on Power Sytems, vol. 19, no. 4, pp. 2053-2059, 2004. [16] X. Luo, K. Kezunovic, “Implementing fuzzy reasoning Petri nets for fault section estimation,” IEEE Transactions on Power Delivery, vol. 23, no. 2, pp. 676-685, 2008. [17] General Electric, “Instruction Manual for D60 Line Distance Relay”, 2004. [18] M. Kezunovic, J. Domaszewicz, V. Skendzic, M. Aganagic, J. K. Bladow, S. M. McKenna, D. M. Hamai, “Design, implementation and validation of a real-time digital simulator for protection relay testing,” IEEE Transactions on Power Delivery, vol. 11, no. 1, pp. 158-164, 1996. [19] ANSI/ISA-18.2-2009. Management of Alarm Systems for the Process Industries. International Society of Automation. USA 2009. [20] RAJA, P., RUIZ, L., DECOTIGNIE, J. D., “On the Necessary Real- Time Conditions for the Producer- Distributor-Consumer Model”, in Proc. of the 1st IEEE Workshop on Factory Communication Systems (WFCS’95), Leysin, Switzerland, 1995, p 125-133.

×