Processamento Automático de Alarmes sem Uso de Informações de Conectividade

Processamento Automático de Alarmes sem Uso de Informações de Conectividade Adriano C. Lisboa, Douglas A. G. Vieira, Sirlene R. R. Magalhães, Ezequiel C. Pereira

Resumo – Este projeto introduz um processamento de alarme 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. Nesse sentido, o algoritmo proposto tenta imitar o procedimento típico adotado por operadores experientes. Esse algoritmo especializado 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 – Conectividade, detecção de padrão, processamento de alarme, sistemas especialistas.

I. INTRODUÇÃO A CEMIG-D é responsável por operar mais de 350 subestações em sua área de concessão. Um único centro de operação c1entralizado 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 medidas 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 evento 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 “Desenvolvimento de Funções Avançadas de EMS II”, código ANEEL PD-4950-0390/2011, proposto pela CEMIG-D e executado pela ENACOM, Asotech e Concert Technologies S/A. 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 ([email protected]). A. C. Lisboa e D. A. G. Vieira trabalham na ENACOM ([email protected]; [email protected]). S. R. R. Magalhães trabalha na Concert ([email protected]).

O projeto modelou 3 agrupamentos específicos de alarmes 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 abordagem especialista, ela permite atingir velocidades relativamente 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 utilizados nas subestações permite a captura de um grande volume 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 transformados 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 disponíveis implica que, mesmo na operação do processo em estado estacionário, o sistema de alarmes seja ativado quase que continuamente, criando muito mais ocorrências de alarmes que podem ser possivelmente entendida individualmente 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 informaçõ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 alarmes na alta e média tensão.

Figura 1 – Alarmes ocorridos em um dia típico.

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 investigação após grandes ocorrências têm demonstrado que sistemas de alarmes ignorados ou sobrecarregados desempenham um papel significativo no agravamento da ocorrência, fazendo 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 tensão. Nesse dia ocorreu corte de carga pela ONS, e no intervalo 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.

- 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 natureza 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 desabilitar temporariamente a geração de alarmes até que o problema por trás do mesmo seja corrigido. Para a implementação segura desse recurso, o sistema de alarmes deve contar com recursos de listagem de alarmes inibidos, lembretes da existência de alarmes nessa condição, e até mesmo auto reativação dos pontos inibidos, se necessário. Deve ser impossível inibir um alarme e esquecê-lo nesse estado. - Alarmes baseados em estado do sistema elétrico: dispor de algoritmos que detectem quando o sistema elétrico muda seu estado operativo e alterem dinamicamente as configurações de alarme para atender aos requisitos de cada estado do cenário operativo atual.

Figura 2 – Alarmes ocorridos em um dia atípico.

O problema da gestão de alarmes começou a ser identificado e estudado no início da década de 90. Em 2009, o padrão ANSI/ISA-18.2 Alarm Management [19] foi disponibilizado. Atualmente, a gestão de alarmes é um tópico fartamente documentado. Uma gestão de alarmes apropriada resulta em aumento da segurança e confiabilidade do processo e, por conseguinte, na redução de custos. O sistema de alarmes deve ter por objetivo mitigar riscos e garantir que situações de anormalidade 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 [21]: - os alarmes foram devidamente escolhidos e implementados; - 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 localização e importância relativa de todos os alarmes gerados;

- 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 faixa de valor ou estado para que o alarme seja efetivamente gerado. - Banda morta: variação mínima em valor absoluto e percentual, configurável por ponto, para que o sistema reconheça o novo valor. - Tratamento inteligente de alarmes: apesar da relevância de saber e registrar em log todos os alarmes disparados, ações que contribuam para agilizar a atuação do operador, tais como agrupamento de alarmes relacionados 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, porém eficaz, de tratamento inteligente de alarmes que realiza o agrupamento de alarmes ocasionados por uma mesma causa raiz, sem a necessidade de utilização de informações de conectividade. A. Estado da arte Processamento de alarme tipicamente procura por informações chave que indicam a causa do alarme de forma a 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 dispositivos elétricos inteligentes já foi abordada [11], onde os dados devem ser acumulados em um centro para serem processados. Nesse sentido, o uso de inferência nebulosa com redes de Petri foi bem estudado para estimar o vão em falta [12][13][14]. Um projeto ótimo desse tipo de rede está disponí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 é usualmente 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 modelo 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 processados 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 reconhecimento de padrões: foram considerados apenas 3 padrões que respondem por mais de 70% das faltas, foi utilizado 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 experientes 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 significativamente o esforço de manter o banco de dados de entrada. 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 comuns no cenário das ocorrências de subestações: religamento 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 param 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, usualmente 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 tipicamente 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 identificada 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 subestaçã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 agrupadas em uma máquina de estado global e cada estado induz uma forma distinta de consumir um novo alarme. 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á religar até três vezes. A máquina de estados para o religamento automático, mostrada na Figura 6, captura esse comportamento: 0, 1, 2 e 3 são estados relacionados ao número de aberturas do religador e 1AR, 2AR e 3AR são estados relacionados 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 retorna ao estado inicial.

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 estabelecidas 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 ordem 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 é finalizado e um grupo de operação em modo local é iniciado.

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 remoto e local, como mostrado na Figura 7. A máquina de estados é 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.

5) Ordenação de alarmes Alarmes podem chegar fora de ordem no processador de alarmes, de forma que eles devem ser reordenados e reprocessados. Isso pode ser eficientemente implementado mantendo 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 procedimento de ordenação de alarmes está ilustrado na Figura 9.

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 mostrado 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 9 - Ordenamento de alarmes: um novo alarme é ordenado no buffer 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 processador 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

transformador se encontra em falta é agrupado. Com estrutura 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 dispositivos. O tempo para processar cada alarme é função do número n de grupos ativos e o número m de alarmes do buffer, 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 processamento de alarmes em si: o buffer é atualizado e reprocessado 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ódigo. O pseudocódigo do buffer de alarmes é dado a seguir: 1. 2. 3. 4. 5. 6. 7. 8. 9.

atualiza tempo atual remove alarmes do buffer mais antigos que t if o novo alarme está na ordem cronológica then adiciona novo alarme ao buffer processa novo alarme else reordena buffer de alarme reprocessa alarme por alarme de todo o buffer endif

Já o pseudocódigo simplificado do processador de alarmes em si é dado a seguir: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

11.

identifica grupo ativo na mesma subestação identifica grupo ativo no mesmo vão if alarme pertence a algum grupo ativo then adiciona alarme ao grupo if alarme é chave de grupo then atualiza máquina de estados atualiza grupo no histórico endif else adiciona alarme ao histórico 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 utilizados tanto para colocar no padrão as informações do alarme 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 monitoramento 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 visualizaçã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 operação deveria passar a ser operado a partir de apenas um. Essa mudança de arquitetura de implantação implicava diretamente em necessidade de aumento significativo da capacidade 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 reestruturação do Sistema xOMNI. Novas tecnologias e conceitos foram adotados para que esses objetivos pudessem ser plenamente atendidos. Entre esses, dois se destacam na composição da solução e são apresentados nas subseções seguintes: cluster funcional e modelo de arquitetura produtordistribuidor-consumidor. 1) Cluster funcional O conceito de “kernel”, usualmente adotado em sistemas SCADA, encerra um acoplamento existencial entre as tarefas essenciais do sistema. Essa condição implica negativamente na disponibilidade desses sistemas. Nesse sentido, o xOMNI SG adotou o conceito de “cluster funcional” em substituição ao antigo conceito de “kernel”. No que tange ao xOMNI SG, um cluster funcional é composto por tarefas produtoras (ou gerenciadoras) e tarefas distribuidoras (ou servidoras) que agrupam funções interligadas aos serviços prestados por aquele cluster. Os clusters funcionais, por construção, são independentes entre si, sendo 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 disponibilizaçã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.

Comparativamente ao modelo convencional clienteservidor, o modelo PDC oferece várias vantagens, entre as quais cabe destacar [20]: a)

2) O modelo produtor-distribuidor-consumidor O modelo PDC [20] foi criado para modelar o tráfego perió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 terceiro 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 modelo 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 pelos distribuidores para o buffer do consumidor.

não

precisam

ser

(No modelo cliente-servidor, um consumidor deve solicitar explicitamente o objeto e esperar até que o servidor 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 facilmente realizado, bastando para tanto, incluir informações adicionais ao valor da variável no buffer.)

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ó daquele cluster. Ressalta-se que nós de clusters funcionais distintos podem compartilhar uma mesma máquina servidora. Todo cluster funcional do xOMNI SG possui um nó principal (master), que é o responsável por atender às solicitações dos clientes dos serviços por ele prestados, e permitem a existência simultânea de diversos nós reservas (slaves), aptos a assumir a condição de principal quando necessário. A implementação do software garante que todos os nós de cada cluster sejam mantidos atualizados com todas as informações que lhe são pertinentes. Dessa forma, se uma máquina onde nós de clusters ou a sua rede local falhar, outros nós daqueles clusters assumem o controle automaticamente, 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 funcionamento dos demais nós daquele cluster ou de outros clusters que estejam em execução. Essa característica permite que os nós dos clusters possam ser instanciados automaticamente, 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, inclusive 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 centralizado quanto de uma IHM local de uma subestação.

produtor e consumidores sincronizados;

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 modelo PDC, definindo única e inequivocamente a tarefa “produtora” para cada cluster funcional, estabelecendo o buffer de dados por variável e instituindo a camada de tarefas distribuidoras, 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 expansã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 distribuidores que um nó de um cluster pode possuir. É possível definir a instanciação de distribuidores de forma a permitir 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 clientes 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 visualizador de alarmes e eventos também é um cliente dos clusters 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 partir do cluster SQL. As ações de operação de reconhecimento 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 gerado 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 interage.

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.

Figura 11 – Integração entre visualizador de alarmes e eventos e o xOMNI 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 funcionalidades foram organizadas de forma mais intuitiva, com o objetivo de facilitar a operação a partir do aplicativo e aumentar 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, reconhecimento 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 aspecto 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ências de alarmes de religamento automático, operação local das subestações e de atuação do relé 86 (proteção do transformador) são agrupadas em uma única ocorrência, que sintetiza o fato causador dos alarmes. Ressalta-se que os alarmes 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 visualizador 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 paginação de alarmes, configuração de ordem de apresentação das colunas através de drag and drop, possibilidade de ordenaçã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,

A forma de visualização dos alarmes pendentes e dos alarmes não reconhecidos foi redesenhada e ganhou interfaces 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 interfaces dedicadas, além de visualizar as ocorrências, os operadores 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 reconhecidos 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 simplificada 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 equipamento associado, basta que se selecione uma ocorrência de alarme desse ponto e, em seguida, acione-se o botão de inibiçã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 inibidos é realizada. A Figura 14 apresenta a interface de visualização de alarmes inibidos.

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 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 agrupados na interface principal.

Figura 17 – Configurações de ativação de tratamento inteligente de alarmes. Figura 15 – Configurações gerais do visualizador de alarmes e eventos.

A interface da Figura 18 apresenta a atuação do tratamento inteligente de alarmes na interface principal.

A interface da Figura 16 apresenta as opções de customização dos esquemas de cores utilizados na aplicação. O usuário pode escolher o tema geral de cores a ser aplicado dentre 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 18 – Exemplo de aplicação do tratamento inteligente.

Pode-se observar o agrupamento de alarmes de religamento automático não satisfatórios (RANS), onde o religador 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 (incluindo linhas de comentários e formatação) usando uma implementaçã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, considerando a densidade máxima típica de 1.000 alarmes por minuto mostrada na Figura 20. 4

3

x 10

2.5

count

2 1.5 1 0.5 0 0

0.001

0.002

0.003 0.004 0.005 0.006 0.007 processing time (seconds)

0.008

0.009

0.01

Figura 19 – Histograma do tempo médio de processamento de cada alarme dentro de uma janela de tempo de tamanho 50 alarmes.

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 proporcionou 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 trabalho, 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 futuras especializações em máquinas de estados. A abordagem usada neste projeto vai na direção de modelar 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

Figura 20 – Número de alarmes em cada minuto em um dia chuvoso típico.

Nesse estudo de caso, 55 grupos foram identificados, todos eles relacionados a religamentos automáticos. A Figura 21 mostra o número de agrupamentos de alarmes por minuto, que não foi maior que três. 3

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]

[2]

grouped alarms

2.5 2

[3]

1.5 1

[4] 0.5 0

0

500

1000

1500

day minute

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 melhorada significativamente na solução desenvolvida e incorpo-

[5]

[6]

A. C. Lisboa, D. A. G. Vieira, R. M. Aquini, E. C. Pereira, “Alarm processing of substations without connectivity information,” a ser publicado nos Proceedings of XVI ERIAC, 2015. 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. 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. 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. 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 Research, vol. 90, pp. 55-66, 2012. F. B. Leão, R. A. F. Pereira, J. R. S. Mantovani, “Fault section estimation in electric power systems using an optimization immune algorithm,” Electric Power Systems Research, vol. 80, pp. 1341-1352, 2010.

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

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. 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. Z. A. Vale, A. M. Moura, “An expert system with temporal reasoning for alarm processing in power system control centers,” IEEE Transactions on Power Systems, vol. 8 no. 3, pp. 1307-1314, 1993. 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. P. Dutta, Y. Guan, M. Kezunovic, “Use of substation IED data for improved processing and fault location,” Proceedings of the 40th Power Symposium, 2008. S. M. Chen, J. S. Ke, J. F. Chang, “Knowledge representation using fuzzy Petri nets,” IEEE Transactions on Knowledge and Data Engineering, vol. 2, no. 3, pp. 311-319, 1990. T. V. Manoj, J. Leena, R. B. Soney, “Knowledge representation using fuzzy Petri nets revisited,” IEEE Transactions on Knowledge and Data Engineering, vol. 4, no. 10, pp. 666-667, 1998. M. M. Gao, M. C. Zhou, X. G. Huang, Z. M. Wu, “Fuzzy reasoning Petri nets,” IEEE Transactions on Systems, Management and Cybernetics, 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 RealTime 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. [21] Hollifield, B., Habibi, E., “The Alarm Management Handbook – A Comprehensive Guide”. 2nd Edition. Hardcover, 2010.