Como já falamos em nosso artigo sobre OPC UA, o padrão OPC foi desenvolvido pela OPC Foundation e consiste basicamente em um protocolo que permite a conectividade entre diversos dispositivos em um chão de fábrica, independente do fornecedor.

Além do OPC A&E (Alarm and events) que iremos tratar neste artigo, vale a pena destacar que em conjunto com outras duas outras especificações formam o conjunto que ficou conhecido como OPC Classic,  são eles:  OPC DA (Data Access) e OPC HDA (Historical Data Access).

Aqui você irá entender pontos importantes sobre OPC A&E, como:

1. O que é OPC A&E?
2. Funcionamento do OPC A&E;
3. Tipos de eventos e informações contidas no OPC A&E;

Continue lendo e aprenda mais sobre o protocolo.

O que são alarmes e eventos?

Antes de irmos direto ao tema, vamos retomar importantes definições: Você sabe o que são alarmes e eventos?

De acordo com a norma da ANSI/ISA 18.2, um alarme é qualquer meio auditivo ou visual que indique uma condição inesperada no processo, equipamento, sistema ou instrumento que exige uma ação corretiva em um tempo restrito.

Já um evento, ainda de acordo com a mesma norma, é uma mudança nas condições da planta, de um equipamento ou de uma variável.

Perceba que, ao contrário do alarme, o evento não necessita de uma ação corretiva. Sua finalidade é apenas de indicar a ocorrência de alguma mudança.

Caso queira ainda se aprofundar no tema, confira nosso post sobre alarmes industriais e se aprofunde no tema.

Agora que já vimos conceitos importantes, vamos voltar para o assunto principal: OPC AE.

O que é OPC AE?

Lançado em 1999, o protocolo OPC AE (ou OPC A&E) permite a recepção, rastreio e reconhecimento de alarmes e eventos em uma indústria.

Vale salientar que o OPC A&E não possui a capacidade de gerar nenhum alarme ou evento no chão de fábrica. Sua finalidade se sustenta na aquisição de dados dos equipamentos conectados ao servidor e que tiveram seus alarmes e eventos previamente configurados.

Funcionamento do OPC AE

Os alarmes e eventos ocorrem de forma aleatória, ou seja, não podemos prevê-los. Dado esta característica, não seria eficiente ter um protocolo onde o cliente necessita realizar requisições para a leitura do estado de um determinado alarme ou evento.

Além disso, o alarme/evento possui uma série de informações que só fazem sentido em conjunto, como por exemplo o instante que ocorreu, sua prioridade, mensagem descritiva, dentre outras.

Nesse contexto, o OPC AE foi projetado para lidar com essas características. Por isso, o protocolo utiliza uma comunicação assíncrona, baseada em callback. Ou seja, o cliente realiza uma assinatura para receber notificações quando qualquer alarme e evento ocorrer.

Adicionalmente, o protocolo permite configurar filtros para que o cliente posse especificar um subconjunto dos eventos de interesse.

Confira agora o fluxo do dado e os tipos de eventos mais detalhadamente.

Fluxo de comunicação

Primeiramente é importante destacar que o OPC AE é um protocolo baseado na arquitetura cliente/servidor que utiliza como base a tecnologia COM/DCOM da Microsoft.

O COM/DCOM é uma das primeiras implementações para o que ficou conhecido como “chamada remota de procedimentos” (RPC).

Assim, a comunicação, nesse caso, ocorre pela chamada de procedimentos que estão em outros processos e até sistemas operacionais distintos.

Ou seja, o OPC AE nada mais é do que uma padronização das funções dos objetos COM.

Para uma melhor compreensão, observe a seguinte figura onde resumimos a sequência de funções a serem chamadas para  o início da assinatura para o cliente receber notificações de alarmes e eventos.

Assim, por ser uma arquitetura de cliente/servidor, o cliente que tem o papel de iniciar a comunicação e para isso chama o procedimento connect.

Em seguida, o cliente solicita a criação de uma assinatura, através do procedimento CreateEventSubscription, para permitir ser notificado sempre que eventos ocorrerem.

Dessa forma, invertendo a responsabilidade da comunicação em um mecanismo conhecido como callback. Após esta chamada, o cliente passa a ser notificado sempre que alarmes e eventos ocorrerem no servidor. A comunicação pode ser encerrada pelo cliente a qualquer momento através do procedimento disconnect que tem a função de liberar os recursos.

Certamente existem várias outras opções durante esse processo simplificado. Diante destas opções é importante destacar o papel dos filtros.

Os filtros permitem que o cliente selecione o grupo de eventos que está interessado. Neste momento, é possível escolher uma categoria, uma área do processo ou até mesmo uma faixa de prioridades. Para criar um filtro o cliente deverá chamar o procedimento setFilter após a criação da assinatura.

Tipos de eventos e informações

De acordo com o protocolo OPC AE, os eventos são divididos em três categorias: simples (Simple), de rastreamento (Tracking) e de condição (Condition), este último é o que conhecemos como ‘alarmes’.

Cada categoria, possui um conjunto específico de informações que são fornecidas e padronizadas pelo  OPC AE. Listamos abaixo as principais informações que estão contidas de acordo com sua categoria.

Eventos simples

Eventos simples consistem basicamente em mensagens informativas que não necessitam de ação corretiva do operador. Exemplo disso são as mensagens do sistema, como inicialização ou desligamento de um equipamento.

Informações contidas nos eventos simples:

• • Source - referência ao objeto que gerou o evento, gerando sua identificação;
  • Time - informa quando o evento ocorreu;
  • Type - tipo do evento ocorrido, podendo ser simples, rastreamento ou condição;
  • Event Category - agrupamento de eventos semelhantes de acordo com uma determinada característica;
  • Severity - Severidade do evento. Possui como métrica uma escala de 1 a 1000, onde 1 é a menor severidade, como simples informações, e 1000 a maior severidade, como eventos de natureza catastrófica geradoras de grandes perdas;
  • Message - mensagem que descreve o evento;

Evento de rastreamento

Eventos de rastreamento são semelhantes aos simples, porém indicam que alguma ação específica foi executada por algum ator.

Assim como nos eventos simples, os eventos de rastreamento são informativos e não necessitam de alguma ação específica.

Além de apresentar as mesmas informações dos eventos simples, os eventos de rastreamento ainda contém o seguinte dado:

• ActorID - identifica o usuário que iniciou a ação resultante do evento, podendo se tratar tanto de um operador quanto de uma aplicação;

Evento de condição (Alarmes)

Eventos de condição  dizem respeito à detecção de condições que requerem algum tipo de resposta ou reconhecimento do evento pelo operador.

Dessa forma, essas condições possuem alguma informação de estado do alarme associada (ACK - Reconhecido, UNACK - Não Reconhecido, RTN - Retorno ao Normal). Um novo evento de condição é gerado sempre que houver qualquer alteração nesse estado.

Além de apresentar as mesmas informações dos eventos simples, os eventos de condição ainda contém os seguintes dados:

• ConditionName - o nome atribuído à condição. Ex: Limite;
• SubConditionName - o nome atribuído à sub-condição. Ex: HIHI/LOLO/LOW.HIGH;
• Change Mask - indica quais propriedades da condição foram alteradas;
• NewState - indica o novo estado da condição;
• Quality - qualidade e confiabilidade do dado que foi transmitido pelo evento, podendo ser good, bad, uncertain ou unknown;
• AckRequired - indica se uma confirmação (reconhecimento) é necessária ou não;
• ActiveTime - o instante de tempo que ocorreu a ativação do alarme;
• Cookie - Identificador únido definido pelo servidor associado à notificação de eventos;
• ActorID - colaborador responsável por reconhecer o evento.

Estados dos alarmes

Como vimos, os eventos de condição (alarmes) geram notificações ao cliente sempre que há qualquer transição em seu estado.  Logo, o cliente precisa interpretar o estado adequadamente para o correto entendimento da mensagem.

Neste sentido, o OPC AE padroniza todos os estados e transições possíveis em um diagrama de estado detalhado na especificação.  A figura abaixo apresenta uma simplificação destes estados e suas transições.

Filtros de eventos

Alguma vezes o cliente pode estar interessado em apenas um subconjunto específico de eventos. Para isso, como já mencionamos, existem os filtros onde o cliente pode informar qual conjunto de eventos está interessado. 

Sendo assim, o OPC A&E, disponibiliza os seguintes atributos como passíveis de filtros, são eles:

• Type of event - o tipo de evento que se deseja observar, podendo ser simples, de rastreamento ou de condição;
• Event categories - combinação de categorias, agrupando eventos semelhantes em determinada característica;
• Lowest severity - permite a seleção dos eventos com níveis de severidade acima de um determinado valor;
• Highest severity - permite a seleção dos eventos com níveis deseveridade abaixo de um determinado valor.

Através desses filtros o processo de análise dos alarmes e eventos torna-se mais simples, visto a obtenção apenas dos que são de interesse imediato.

Considerações finais

Nesse artigo pudemos compreender melhor o conceito de OPC AE e seu funcionamento, tratando de pontos importantes como sua arquitetura e o fluxo de informações.

E então, ficou tudo claro? Esperamos que esse artigo tenha te proporcionado um melhor entendimento acerca do OPC AE, bem como uma reflexão sobre o tema dentro do contexto da sua indústria.

Ainda restou alguma dúvida? Fique a vontade para entrar em contato comigo através do debora.silva@logiquesistemas.com.br, ficarei feliz em te ajudar!

Por fim, caso tenha lembrado de alguém que se interessa pelo tema, compartilhe este post em suas redes sociais e dissemine conhecimento!

Caso ainda não tenha segurança neste assunto, indicamos a leitura do nosso artigo sobre gerenciamento de alarmes. Se você já tem familiaridade, então continue lendo este texto pois vamos explicar como ocorre esse processo de implantação.

"Quero implementar um sistema de gerenciamento de alarmes na minha indústria, e agora?" Para responder esse questionamento, podemos dividir o processo em duas etapas, que são: pré-diagnóstico e implantação do sistema.

Primeiramente, deverá ser realizado um pré-diagnóstico para coletar informações sobre a infraestrutura de automação, como são coletados os dados de alarmes e eventos, testes de conectividade, além de realizar uma análise dos dados coletados.

Em seguida, com as informações coletadas do diagnóstico, é possível realizar a implantação do sistema de gerenciamento de alarmes. Dessa maneira, a implantação vai desde a instalação da ferramenta na indústria até a parte de treinamento e documentação.

Portanto, neste artigo, o nosso objetivo é explicar detalhadamente cada etapa do processo de implantação do sistema de gerenciamento de alarmes. Dessa forma, você terá um maior conhecimento sobre este processo antes mesmo de comprar alguma solução.

Pré-diagnóstico do sistema de gerenciamento de alarmes

Conforme explicado, o pré-diagnóstico consiste na etapa de coleta de informações da indústria para que seja definida a metodologia de implantação que melhor se adequa à planta.

Portanto, nesta etapa será realizado um mapeamento da infraestrutura existente. Será analisado desde o sistema de automação, aspectos de rede, bem como a infraestrutura a ser disponibilizada para implantação do sistema de gerenciamento de alarmes.

Especificamente, o que será observado no pré-diagnóstico será:

• A infraestrutura de automação existente;
• Como ocorre a geração de dados de alarmes e eventos;
• Estudo das opções para coleta dos dados de alarmes e eventos
• A integração entre as ferramentas utilizadas a partir de testes de conectividade;
• A configuração das mensagens de alarmes a partir da análise dos dados coletados;

Você pode estar se perguntando agora como funcionam esses testes de conectividade e a análise dos dados coletados. Vamos explicar agora como funciona esse processo para que se tenha um diagnóstico completo da situação atual da indústria.

No caso da Logique Sistemas, O BR-AlarmExpert utiliza uma uma arquitetura de sistema baseada em serviços, para que possa facilmente se adaptar a diversas realidades de infraestrutura de cada local.

Resumidamente, a figura abaixo ilustra os principais serviços de coleta de dados e suas interações para que fique claro como ocorre a comunicação dos dados no BR-AlarmExpert propostos para a comunicação com a infraestrutura existente na fábrica.

• Alarm-collector - É o serviço especializado em realizar a comunicação direta com o sistema de automação existente. Ele realizará a coleta em tempo real dos alarmes e eventos disponibilizados pelas interfaces do sistema de automação do cliente. Após receber os dados o alarm-collector armazena em um buffer local persistente (em disco) e em seguida envia os dados para o alarm-archiver. Diferentes tipos de protocolos podem ser utilizados para coleta dos dados. Assim, existem serviços específicos para cada protocolo/forma de coleta de dados.
• Alarm-archiver - É o serviço especializado em receber os dados do alarm-collector para armazenamento em banco de dados histórico de alarmes. Além disso, o alarm-archiver realiza a transformação dos dados de forma a extrair o máximo de informação pertinente dos dados coletados. Essa transformação será melhor explicada na parte de preparação das regras na implantação.
• Alarm-processor - Permite a consulta dos dados pelo BR-AlarmExpert. Além disso, possui a função de realizar o processamento dos dados de alarmes e eventos de forma a pré-classificar e segregar os dados, otimizando as pesquisas principalmente sobre longos períodos de tempo.

Após o armazenamento e processamento dos dados de alarmes, estes ficam completamente disponíveis para consultas e relatórios pelo sistema.

O BR-AlarmExpert utiliza arquitetura web, ou seja, é um sistema acessado através de um browser como um site. Para isso, possui um servidor central web para a disponibilização do sistema que é compatível com qualquer browser do mercado.

Portanto, a partir deste processo de análise e testes de conectividade, coletam-se várias informações importantes. As informações coletadas servirão como base para a metodologia de implementação, a qual varia de acordo com as características de cada indústria.

Implantação do sistema de gerenciamento de alarmes

Após o aceite do projeto por parte da indústria, a primeira etapa de implementação é uma reunião de kick-off. A partir dos dados extraídos do pré-diagnóstico, será apresentado o projeto, o cronograma planejado e será colhido feedbacks acerca da execução do projeto.

Depois da reunião, se dará início a implantação do sistema de gerenciamento de alarmes (BR-AlarmExpert). É importante que seja fornecido à equipe técnica de instalação todas as informações necessários para comunicação e acesso à infraestrutura local.

A implantação pode ser dividida em fases para facilitar seu gerenciamento. A seguir serão detalhados cada fase especificando sua atividade e o que se espera alcançar ao fim da fase.

Teste de comunicação

Nesta fase será realizado testes de conectividade com a planta para validar a integração entre as ferramentas. Além disso, será coletado uma amostra de aproximadamente 24h com os dados de alarmes e eventos. Assim, as mensagens de alarmes existentes são conhecidas, para subsidiar a etapa de configuração das regras de transformação dos dados.

Instalação das ferramentas

Uma vez realizado o teste de comunicação, as ferramentas podem ser então instaladas em suas respectivas máquinas. Ao final, espera-se que toda pilha de comunicação, processamento, armazenamento e visualização esteja instalada e funcional.  

Preparação das regras

Lembra-se do alarm-archiver, onde explicamos que ele faz uma transformação dos dados em informações mais fáceis de serem interpretadas? É nesta etapa, em que após todas as ferramentas terem sido instaladas é hora de iniciar a configuração das regras.

Para melhor entendimento do que se objetiva nesta etapa, imagine que exista um padrão de nomenclatura de tags como o seguinte: todos os tags com prefixo numérico 010 são correspondentes ao “Alto Forno 01” e os tags com prefixo numérico 020 são correspondentes ao “Alto Forno 02”.

Assim, a tag, FIC-010383 corresponde ao “Alto forno 01” e o tag FIC-02037 ao “Alto forno 02”. Mesmo que a informação do Alto Forno não esteja explícita em um atributo do alarme, é importante, neste momento, deixá-la explícita aos usuários do BR-AlarmExpert para facilitar a extração dos relatórios.  

Ao final desta etapa, espera-se que os dados estejam corretamente interpretados e que o máximo de informação tenha sido extraído para facilitar as futuras análises.  

Configuração dos relatórios

Após o sistema estar plenamente implantado é o momento de iniciar a configuração conforme necessidade do cliente. Neste ponto é importante a participação próxima da equipe local para detalhar os tipos de relatórios a serem acompanhados, formato e sua periodicidade.  

Com essas informações, o sistema de gerenciamento de alarmes será configurado de forma que todas as informações estejam facilmente acessíveis e de acordo com a necessidade do cliente.

Em resumo, nesta etapa serão criados relatórios periódicos a serem enviados por e-mails, dashboards de acompanhamento em tempo real, tabela de indicadores, e diversos relatórios de acompanhamento.  

Ao final desta etapa o BR-AlarmExpert já estará plenamente funcional e configurado de acordo com as necessidades da indústria.  

Comissionamento

Com o término da configuração e implantação do sistema de gerenciamento de alarmes, agora é a etapa de validação. Nesta fase, deve-se assegurar que a configuração está de acordo com o que foi requisitado pelo cliente.

É nessa etapa onde, normalmente são gerados dados de alarmes e eventos de maneira intencional. Esta é a forma de verificar se estes dados foram corretamente coletados e interpretados pela ferramenta durante todo seu ciclo de vida.

Portanto, neste momento será onde a equipe local da indústria fará testes da ferramenta para validação de suas necessidades. A manutenção da ferramenta será realizada a partir dos feedbacks entregues pela equipe do cliente.

Ao final desta etapa espera-se ter um sistema implantado e validado pelo cliente pronto para entrar em operação.

Treinamento

Após implantação e comissionamento será então realizado o treinamento dos usuários e demais colaboradores que tenham interesse em ter entendimento da solução implantada.  

O treinamento tem o objetivo de preparar os usuários da ferramenta para utilizá-la adequadamente.

Neste momento, espera-se que os usuários consigam absorver a essência de funcionamento do sistema para que possam extrair quaisquer informações que queiram sob a base de dados de alarmes e eventos.

Documentação

Por fim, nesta etapa será documentada todas atividades executadas durante o período do projeto. Dessa forma, a equipe local terá um registro para consultas futuras.

Será entregue, por parte da Logique Sistemas, o documento de “As-Built”. Este documento tem o objetivo de registrar todo o processo realizado durante a implantação, configuração e comissionamento da ferramenta.

O As-Built deve ser detalhado de tal forma que seja possível reproduzir todo o processo de implantação do sistema de gerenciamento de alarmes através desta documentação. Além disso, serão entregue os seguintes documentos complementares, como:

• Manual do BR-AlarmExpert
• Guia do usuário
• Guia de instalação dos módulos

Suporte

O processo de implantação do sistema de gerenciamento de alarmes como um todo termina na documentação. Porém, além da implantação, a Logique Sistemas, fornece todo o suporte e garantia durante todo o uso da ferramenta.

Dessa forma, a indústria pode contatar nossa equipe técnica para tirar suas dúvidas, sugerir melhorias, reportar problemas ou quaisquer outros assuntos.

Além do suporte, também será disponibilizado novas versões da ferramenta deixando à disposição da indústria para atualização, caso julgue necessário.

Pronto para implantar um sistema de gerenciamento de alarmes na sua indústria?

Conseguiu entender como funciona o processo? Esperamos que com este artigo tenha sido possível tornar muito mais claro para você como ocorre a implantação do sistema de gerenciamento de alarmes.

A ideia foi apresentar tudo que será feito a partir do momento que a sua indústria sinalizar positivamente adquirir uma nova ferramenta. Dessa forma, você terá mais conhecimento para questionar o fornecedor da solução.

Tem interesse de conhecer na prática como funciona um software de gerenciamento de alarmes? Converse com um dos nossos consultores e solicite acesso a uma demonstração gratuita da ferramenta. Temos certeza que acharemos a ferramenta adequada para o cenário da sua empresa.

Esse acidente que envolveu segurança em gerenciamento de alarmes teve prejuízos aproximados de 48 milhões de euros na reconstrução da refinaria. Por sorte, o acidente ocorreu em um domingo e apenas 26 pessoas ficaram levemente feridas.

Além disso, teve uma perda imensurável de produção enquanto a refinaria ficou parada. A explosão ainda conseguiu atingir a cidade que estava a 3km de distância, quebrando alguns vidros de lojas.

Isso aconteceu 1994, quando a refinaria da Texaco em Milford Haven explodiu, mas como em qualquer acidente, até a explosão houve uma sequência de eventos.

Nesse acidente destacam-se então os diversos problemas relacionados a ineficiência do sistema de alarmes pela falta de um gerenciamento de alarmes.

Ao sair o relatório de investigação do acidente, percebeu-se que os problemas relacionados a falta de gerenciamento de alarmes foram decisivos para a explosão. Futuramente, a comunidade percebeu que esses problemas eram comuns em várias indústrias.

Foi a partir disso que as grandes indústrias começaram a se preocupar com a prática de gerenciamento de alarmes. Hoje, já temos boas práticas e normas bem definidas através da EEMUA 191 e ISA 18.2.

Portanto, aqui neste artigo nós vamos apresentar ainda:

• Como ocorreu o incidente;
• Principais causas e falhas responsáveis;
• Lições aprendidas sobre segurança em gerenciamento de alarmes.

Como ocorreu o incidente?

Tudo começou quando raio atingiu uma unidade industrial, mas ele não foi a causa principal da explosão. O raio desencadeou uma combinação de falhas em gerenciamento, equipamentos e sistemas de controle. Tudo isso ocorreu durante as próximas cinco horas até o momento da explosão.

O raio atingiu a unidade de destilação bruta que alimentava as unidades da refinaria de petróleo Pembroke Cracking Company (PCC) e causou um incêndio. Consequentemente, a unidade de destilação bruta foi desativada e causou uma série de perturbações na planta.

A explosão foi causada pelo fluido inflamável de hidrocarbonetos que era bombeado continuamente em um reservatório. Porém, devido a um mau funcionamento da válvula, a saída do fluido estava fechada enquanto o sistema de controle indicava aberto.

O único meio de escapar desse fluido, já que o reservatório estava cheio, era através do sistema de alívio de pressão e depois ser alinhado para o flare para ser queimado.  Por sua vez, o sistema não foi ligado e devido ao avanço de líquido ocorreu um vazamento na tubulação de saída.

Um total de 20 toneladas desse fluido foi então liberado e acabou encontrando uma fonte de ignição em 110 metros que causou a explosão.

Após isso, o instituto HSE (Health and Safety Executive) investigou o acidente e concluiu que houveram duas causas principais:

• Divergência entre posição da válvula reportada pelo sistema de supervisão e sua posição real;
• O painel gráfico de supervisão não ofereceu a visão geral necessária do processo. O excesso do número de alarmes em situação de emergência reduziu a efetividade de resposta do operador.

É possível concluir então que um sistema de alarmes efetivo poderia ter mudado a história completamente. O sistema existente falhou em identificar diversas falhas que ocorreram durante cinco horas após atingimento do raio por estar sobrecarregado em estado de distúrbio.

Principais causas e falhas encontradas

Sabemos que vários acontecimentos foram responsáveis pela explosão final, mas vamos enfatizar mais a segurança em gerenciamento de alarmes. Portanto, vamos discutir agora as principais falhas encontradas no relatório de investigação.

1- Altíssima taxa de alarmes

Foi percebido que com a forma como o sistema de alarmes estava configurado no dia da explosão, as chances dos operadores restaurarem o controle por intervenção manual diminuía quanto mais a condição de distúrbio persistia.

Isso aconteceu porque os operadores foram progressivamente sobrecarregados com uma crescente sinalização de alarmes. Os registros dos alarmes indicavam que os operadores recebiam novas sinalizações de alarmes numa taxa de um a cada 2 a 3 segundos.

Essa frequência de alarmes resultou então no cancelamento desses alarmes por parte dos operadores, sem necessariamente entender o significado deles. A nível de comparação, a ISA 18.2 indica que o máximo permitido são de 2 alarmes a cada 10 minutos por operador.

O relatório apresenta que nos 10 minutos anteriores a explosão, dois operadores precisaram reconhecer e tomar a ação apropriada em 275 alarmes.

2- Priorização de alarmes deficiente

Foi possível observar no relatório de investigação que a priorização de alarmes da refinaria era deficiente. Dos alarmes configurados no DCS, 87% era de prioridade alta e 13% de prioridade baixa.

A nível de comparação a ISA 18.2 classifica como ideal dividir a prioridade em quatro categorias. A proporção é 80% como prioridade baixa, 15% média, 5% alta e 1% de prioridade crítica.

Em uma situação como essa encontrada em Milford Haven onde você tem uma avalanche de alarmes e 87% dos seus alarmes são considerados prioridade alta, o operador fica completamente confuso e não sabe qual alarme dar a devida importância.

Não existia nenhuma filosofia de alarmes que determinasse qual a prioridade de um alarme, bem como não existia um controle sobre o número de alarmes no sistema.

Lições aprendidas sobre segurança em gerenciamento de alarmes

Depois de observar todas essas falhas encontradas sobre segurança em gerenciamento de alarmes na refinaria da texaco em Milford Haven, qual foi o legado deste acidente?

Vamos agora tirar as lições aprendidas e sugerir algumas recomendações a fim de evitar novas ocorrências desse tipo.

Um dos principais problemas encontrados foi que o sistema de alarmes estava muito sobrecarregado. Sendo assim, avisos de problemas cruciais eram perdidos em meio a abundância de alarmes não-relevantes.

O outro problema, que está relacionado com o primeiro, foi a priorização de alarmes. No sistema de controle, apenas um alarme era de prioridade emergencial. O resto dos alarmes eram 87% de prioridade alta e 13% prioridade baixa.

Com alarmes sinalizando a cada três segundos, os operadores não conseguiam reagir apropriadamente para cada um. Nesse contexto, conseguimos tirar as seguintes lições:

1- Cada alarme precisa ter um propósito bem definido

Um dos pontos mais críticos diagnosticados foi a alta taxa de alarme encontrada no período de distúrbio da planta. Sendo muito desses alarmes não-relevantes e que estavam apenas confundindo o operador.

Para evitar que alarmes importantes não passem despercebidos, é necessário garantir que todos os alarmes cumprem de fato a definição de um alarme industrial.

Além disso, outra maneira de diminuir o número de alarmes não-relevantes é certificar-se de ter uma filosofia de alarmes bem definida e realizar o processo de racionalização de alarmes.

2- Categorizar os diferentes alarmes

Uma das falhas encontradas de segurança em gerenciamento de alarmes em Milford Haven foi que os alarmes apresentados no painel de controle não eram diferenciados quanto ao tipo.

É recomendado então que, na configuração dos alarmes, os alarmes críticos de segurança sejam distinguidos dos outros alarmes operacionais. Dessa forma, facilita o rápido reconhecimento do operador e mais agilidade nas ações prioritárias, como segurança.

Os alarmes precisam ser divididos em diferentes categorias. Por exemplo: alarme de segurança, falha no equipamento, condição anormal do processo ou qualidade do produto. Preferencialmente, o número de alarmes críticos de segurança precisam ser mínimos.

3- Ter uma regra de priorização bem definida

Além de categorizar os alarmes, é essencial ter uma regra de priorização bem definida. Isso facilita a identificação dos alarmes mais críticos em meio a uma abundância de alarmes não-relevantes.

Você pode ler mais sobre como priorizar seus alarmes corretamente neste artigo.

4- Limitar o número de alarmes por operador

Foi observado uma grande quantidade de alarmes registrados no sistema de controle que superava em muito a capacidade que um operador consegue suportar.

O número de alarmes precisa ser limitado para um número que o operador consiga monitorar efetivamente. Não adianta sobrecarregar a quantidade de alarmes se o operador reconhece, mas não possui tempo para realizar a ação corretiva.

5- Possuir um sistema automático de segurança

Por fim, a segurança máxima da planta não pode depender da resposta de um operador. É necessário também garantir o bom desempenho do sistema instrumentado de segurança para que possa intervir em casos onde a operação não conseguiu contornar o distúrbio a tempo.

Por isso, é necessário ter um sistema de parada automática para garantir a segurança da planta.

Conclusão

Esperamos com esse artigo que tenha ficado claro como a segurança e gerenciamento de alarmes estão totalmente interligados. Ter um processo de gerenciamento de alarmes bem definido pode trazer então um grande impacto para sua indústria.

Aqui nós vimos como uma sequência de eventos em conjunto com uma alta taxa de alarmes e uma priorização deficiente foi capaz de causar danos na ordem de milhões de euros para uma refinaria da Texaco.

É importante lembrar que apesar desse artigo ter focado na questão da segurança, a prática de gerenciamento de alarmes não só previne acidentes, como também aumenta a eficiência operacional da planta e reduz perdas financeiras por condições anormais do processo.

Como sempre gostamos de compartilhar bons conteúdos para os nossos leitores, também apresentamos as lições aprendidas e a resolução desses problemas. Se ainda ficou alguma dúvida sobre:

• Ter um alarme de propósito bem definido;
• Categorizar os diferentes alarmes;
• Ter uma regra de priorização bem definida;
• Limitar o número de alarmes por operador;
• Possuir um sistema automático de segurança.

Para se aprofundar ainda mais em gerenciamento de alarmes, preparamos um guia completo para você. Baixe então o nosso ebook gratuito O Guia Completo do Gerenciamento de Alarmes.

Pode entrar em contato comigo pelo matheus.romano@logiquesistemas.com.br. Fico completamente disponível para tirar qualquer dúvida e auxiliar a resolver esses problemas na sua indústria.

Se você acredita que esse conteúdo sobre segurança em gerenciamento de alarmes seria interessante para algum amigo, compartilhe com ele!

A lógica é simples: como você pode maximizar os resultados de algum processo se você não sabe a situação atual?

Imagine você com um filho matriculado em uma escola. Você iria acompanhar os resultados dele mensalmente ou deixaria para descobrir tudo no final do ano? Claramente, se não acompanhar, no final pode aparecer a bomba que ele reprovou.

Portanto, todo o investimento anual seria desperdiçado, mas que poderia ser evitado se houvesse um acompanhamento. Da mesma maneira isso ocorre se não houver um monitoramento do sistema de alarmes.

A diferença entre as situações é que com seu filho eventualmente você descobrirá que ele reprovou. Já na segunda situação, você pode continuar tendo perdas financeiras e nem descobrir o motivo, pois não existe algo que te alerte sobre isso.

Logo, para que você tenha total controle sob o seu sistema de alarmes e descubra onde estão os pontos críticos de alarmes da sua indústria, é necessário começar a monitorar. Para isso, a melhor forma de monitorar o sistema de alarmes é através de um sistema de gerenciamento de alarmes.

O assunto trabalhado aqui tem como finalidade oferecer os insumos necessários para que você otimize o seu processo. Caso ainda não tenha um processo definido, também será útil para que você realize um diagnóstico da sua situação atual.

Apresentaremos então os padrões internacionais de normas como ISA 18.2 e EEMUA 191 para que você faça um benchmarking e compare com os resultados obtidos no seu diagnóstico.

1. Quanto um operador consegue suportar?

Se um operador conseguisse lidar com milhares de alarmes por dia, não teria necessidade de um gerenciamento de alarmes. Como eles não conseguem, a pergunta é: até quanto eles conseguem suportar?

Por isso, foram realizadas pesquisas para entender os problemas de fatores humanos envolvidos na resposta de alarmes. A resposta de alarmes não é um processo automatizado, é um processo que envolve pensar e analisar. As etapas envolvidas são:

1- Detectar o alarme;

2- Silenciar/Reconhecer o alarme;

3- Navegar para a tela apropriada para entender o contexto do processo no qual o alarme faz parte;

4- Verificar que o alarme está válido e não com mal funcionamento;

5- Analisar a situação do processo para determinar a causa do alarme e decidir a ação corretiva apropriada. Dependendo da situação pode ser necessário consultar alguém;

6- Implementar a ação escolhida, que pode ser de diversas maneiras, como implementar por si só ou pedir para que outros realizem a ação corretiva;

7- Continuar a monitorar o sistema e garantir que a ação tomada corrija a situação.

Dessa forma, claramente percebemos que essas etapas não podem ser realizadas instantaneamente. Por isso, todos os KPI’s e métricas do desempenho do sistema de alarmes levaram em consideração a capacidade humana do operador.

Além disso, também foram realizadas pesquisas nas grandes indústrias para entender melhor qual era o comportamento padrão deste processo. 

Por fim, a melhor maneira de calcular esses KPIs a fim de maximizar o desempenho do sistema de alarmes é através de um sistema de gerenciamento de alarmes. Pois o operador terá acesso a dados mais precisos que irão facilitar o seu trabalho.

2. Key Performance Indicators (KPIs)

Falamos da capacidade humana do operador para que vocês entendessem o que foi levado em consideração na hora de formular esses indicadores. Agora vamos falar realmente sobre o que vocês devem mensurar para maximizar o desempenho.

Key Performance Indicator significa indicador chave de desempenho. Os indicadores chaves impactam diretamente no desempenho do sistema de alarmes e mostram se a sua estratégia para determinado processo está seguindo conforme o planejado.

A seguir, a tabela sintetiza os principais KPIs que devem ser monitorados no sistema de alarmes. Essa tabela foi extraída da norma ISA 18.2.

Talvez, quando você diagnosticar a situação da sua indústria, tome um susto por encontrar um número bem mais elevado que o determinado. Tome cuidado, será que todos esses alarmes são realmente alarmes?

Entender o que de fato é um alarme industrial pode ser o começo de tudo para um saneamento do sistema de alarmes.

Agora vamos explicar o que consiste cada um desses indicadores. Vale lembrar que esses valores são com base em 30 dias e por cada operador. Imagine você ter que acompanhar todos esses dados manualmente?

É um trabalho exaustivo que seria facilitado para o operador através de um sistema de gerenciamento de alarmes.

Alarmes anunciados por dia

A análise mais importante também é a mais simples da performance do sistema de alarmes. Basta saber a quantidade de alarmes que são anunciados por dia por cada operador. É um ótimo indicador para saber o quão confiável é o seu sistema de alarmes.

Muitas indústrias costumam ter mais de mil alarmes por dia. Levando em conta que o máximo gerenciável são de 288, então com certeza o operador não conseguirá operar adequadamente o processo com as informações fornecidas.

Por isso, ele irá buscar informações de outras maneiras bem menos eficientes que não foram projetadas para tal. Consequentemente, isso acaba levando a uma atuação mais frequente do sistema de segurança (trip) causando perdas financeiras.

É nessa situação que um sistema de gerenciamento de alarmes pode auxiliar fornecendo as informações precisas através de cálculos eficientes dos KPIs.

Alarmes anunciados por hora/período de 10 minutos seguem o mesmo raciocínio, são apenas bases de cálculo diferentes. Porém, a base por período de 10 minutos é a mais importante e mais utilizada, por isso os outros KPI’s seguem ela.

Se você mensurar apenas a quantidade de alarmes por dia, você pode mascarar seu real resultado. Podem existir intervalos de 10 minutos dentro de um dia que a quantidade de alarmes foi excessiva, enquanto outros intervalos praticamente não teve alarmes.

A média final do dia pode estar dentro do limite gerenciável. Porém, pode existir pelo menos um período de 10 minutos dentro desse dia que ultrapassou o limite gerenciável. Dessa forma, esse alarme perdido pode causar grandes impactos negativos na indústria.

Percentual de períodos de 10 minutos com incidência superior a 10 alarmes

Esse indicador apresenta que do total de períodos de 10 minutos em uma base de 30 dias, apenas 1% pode ter uma incidência superior a 10 alarmes.

Ou seja, como 30 dias possui 4.320 intervalos de 10 minutos, no máximo aproximadamente 43 intervalos (1%) podem ter incidência superior a 10 alarmes.

O percentual de horas com incidência superior a 30 alarmes também segue o mesmo raciocínio.

Número máximo de alarmes em um período de 10 minutos

Para ter um bom sistema de alarmes, o número máximo de alarmes em um período de 10 minutos deve ser de no máximo 10. Pelas pesquisas realizadas, esse é o máximo que um operador consegue gerenciar nas suas limitações humanas.

Este indicador procura dimensionar a carga de alarmes aos operadores em situação de distúrbio na planta. Em distúrbio o número de alarmes costuma aumentar bastante.

Por isso, esse indicador complementa a taxa média de alarmes pois, de nada adianta que a média apresente um sistema de alarmes consistente se quando a planta entra em estado de distúrbio ela se torna ingerenciável.

Percentual de tempo que o sistema de gerenciamento de alarmes permanece em condição de avalanche

É considerado que o sistema está em condição de avalanche quando, em um período de 10 minutos, mais de 10 alarmes são sinalizados e só termina quando a taxa cai para menos de 5 alarmes por 10 minutos.

O recomendado é que apenas em 1% do tempo de funcionamento o sistema de alarmes esteja em condição de avalanche.

Uma condição de avalanche pode durar por horas e pode tornar situações de processos difíceis muito piores. Você pode ler mais sobre como evitar este tipo de problema na sua indústria aqui.

Contribuição percentual dos 10 alarmes mais frequentes em relação ao total de alarmes

Esse indicador apresenta que o total de alarmes dos 10 alarmes mais frequentes tem que ser no máximo 5% em relação ao total de alarmes de todo o sistema. O ideal é que se mantenha esse percentual com planos de ação para corrigir as deficiências.

Comparando a sua situação atual com esse indicador, permite que você identifique na hora quem são os principais bad-actors (vilões). Pois, comumente eles são responsáveis por uma parcela bem expressiva do total de alarmes.

Identificando os mais frequentes e ajustando-os, permite que você otimize em grande escala seu sistema.

Quantidade de alarmes intermitentes (chattering ou fleeting alarms)

Alarme intermitente é o tipo de alarme que transita entre o estado de anunciação e o estado normal em um período curto de tempo. Um bom parâmetro para classificá-lo como chattering é de sinalizar três vezes em apenas um minuto.

O ideal é que esse indicador seja zero, pois é um dos piores contribuidores para a carga de alarmes. Qualquer ocorrência desse tipo de alarme devem ser criados planos de ação para corrigir.

Quantidade de alarmes obsoletos (stale ou long standing alarms)

Alarmes obsoletos são alarmes que permanecem ativos continuamente por longos períodos de tempo, geralmente 24h. Na maioria das vezes esse tipo de alarme nem representa uma situação anormal de fato.

O ideal nesse indicador é que se tenha menos de cinco em qualquer dia, com planos de ação para corrigir qualquer ocorrência.

Distribuição da prioridade de alarmes

É muito comum nas indústrias que não gerenciam alarmes que a maioria dos alarmes se encaixem como prioridade alta, crítica ou até mesmo nem tenha o conceito de prioridade implementado.

Isso reflete em um péssimo desempenho do sistema de alarmes. Para rever esse problema, indicamos o nosso artigo sobre priorização de alarmes para que você entenda a melhor forma de priorizar seus alarmes.

As normas indicam que se deve trabalhar com três prioridades, apenas. O ideal é que aproximadamente 80% seja prioridade baixa, 15% média e 5% alta. É exatamente o contrário do que se observa normalmente.

Supressão não autorizada de alarmes

A supressão de alarmes é o ato de desligar temporariamente um alarme. Muitas vezes é realizada pela própria operação, quando por exemplo, um equipamento precisa ser desligado para manutenção.

No entanto, é importante que essas supressões sejam gerenciadas para evitar que os alarmes sejam suprimidos sem um plano e de forma descontrolada.

Alarmes suprimidos (shelving alarms) possuem ação iniciada pelo operador para suprimir temporariamente um alarme, com mecanismos de controle para remoção desta supressão.

É preciso tomar muito cuidado com essa supressão, pois ela deve ser temporária. Pode acontecer do equipamento ou sistema monitorado pelo alarme suprimido voltar a operar e o alarme ainda continuar suprimido para o operador.

Se isso acontecer, ele não identificará qualquer situação de anormalidade, podendo causar incidentes ou perdas financeiras, perda de especificação do produto e até perdas por paradas não programadas.

O ideal é que nenhum alarme seja suprimido sem um mecanismo de autorização e controle. Um procedimento/metodologia de supressão deve ser definido e documentado na filosofia de alarmes.

Mudança não autorizada de atributos de alarmes

Segue a mesma linha de raciocínio da supressão de alarmes. O recomendado é que nenhum atributo de alarme seja modificado sem ter um procedimento padrão de autorização ou gestão de mudança. Esse procedimento também deve constar na filosofia de alarmes.

Essa mudança deve ocorrer no processo de racionalização de alarmes que deve ser aplicado periodicamente, junto da auditoria, como forma de otimizar o processo de gerenciamento de alarmes.

3. Níveis de performance do sistema de gerenciamento de alarmes

Depois de entender mais sobre os KPIs para mensurar a performance do sistema de alarmes, você pode se perguntar: “Com todos esses dados, em qual contexto minha indústria se encaixa atualmente?”.

É com base nessa pergunta que a EEMUA 191 apresenta os níveis de performance de um sistema de alarmes. A figura abaixo, da EEMUA, leva em consideração 3 KPIs para você identificar o nível de performance da sua indústria de forma qualitativa.

Os cinco níveis são descritos de acordo com o que foi mensurado nos KPIs. No topo do gráfico avalia a % de tempo que a taxa de alarmes está fora da margem aceitável. Na lateral esquerda mede-se a taxa média de alarmes. Embaixo expressa a taxa máxima de alarmes.

Através do cruzamento desses KPIs primários a EEMUA 191 propõe uma avaliação do nível de performance da sua planta.

Para entender um pouco mais do que cada nível representa vamos apresentar as principais características de cada um. Os cinco níveis do menos estável para o mais estável, são: sobrecarregado, reativo, estável, robusto e preditivo.

4.1- Sobrecarregado (Overloaded)

Esse nível é o de pior desempenho do sistema de alarmes dentre os demais. Quando o sistema de alarme está sobrecarregado, ele se torna mais um obstáculo para o operador do que uma ferramenta de ajuda.

Esse nível de performance é caracterizado pelos seguintes fatores:

• Uma contínua alta taxa de alarmes, com rápido decaimento do desempenho durante perturbações no processo;
• O sistema de alarme é difícil de utilizar durante operação normal e na prática é ignorado quando a planta está em estado de distúrbio;
• Baixa confiabilidade do operador no sistema de alarme, o qual é frequentemente ignorado por longos períodos de tempo;
• Dificuldade/impossibilidade em distinguir alarmes importantes dos menos importantes. O sistema de alarme dá pouco ou nenhum aviso avançado de perturbações na planta;
• Muitos alarmes não tem sentido ou são pouco relevantes (bad-actors);
• Alarmes são frequentemente suprimidos pelo operador por serem incômodos e frequentemente esquecidos;
• A documentação e o controle de supressão de alarmes não é confiável.

4.2- Reativo

Um sistema de alarmes reativo apresenta uma melhora comparado ao sobrecarregado, porém a taxa de pico durante situações de distúrbio ainda é ingerenciável. O sistema de alarme ainda é uma distração para o operador na maior parte do tempo.

O nível reativo é caracterizado pelos seguintes fatores:

• É mais estável e utilizável durante operação normal, porém é praticamente inútil quando a planta está em estado perturbado;
• O operador reage mais para a taxa de novos alarmes ao invés dos detalhes de cada alarme;
• A priorização de alarmes é conhecida por não ser confiável, mas tem algum uso;
• O sistema de alarmes fornece algum aviso prévio de perturbação na planta;
• Alguns alarmes ainda são sem sentido ou pouco relevante, contribuindo para o nível geral de ruído;
• A supressão de alarmes é melhorada mas ainda não está sob controle sistemático.

4.3- Estável

O estável é um sistema de alarmes bem definido para operação normal, mas ainda possui problemas quando a planta está em estado de distúrbio. Os bad-actors são resolvidos e estão sob controle sistemático. O problema continua sendo picos de alta taxa de alarme.

O nível estável é caracterizado pelos seguintes fatores:

• O sistema de alarme é confiável em operação normal, fornecendo aviso prévio de distúrbio na planta iminente, mas é menos útil quando em estado de distúrbio;
• Os operadores estão confiantes na melhoria da priorização de alarmes, reagindo rápido e consistentemente à eles;
• Todos os alarmes são relevantes e possuem resposta definida;
• Supressão de alarmes e o gerenciamento de mudanças (etapa do gerenciamento de alarmes) são completamente controlados.

4.4- Robusto

Neste nível as taxas máxima e média de alarmes estão sob controle para cenários operacionais previsíveis da planta.

São utilizadas tecnologias para acompanhamento e melhora do desempenho do sistema de alarmes em tempo real, como um sistema de gerenciamento de alarmes.

O nível robusto é caracterizado pelos seguintes fatores:

• O sistema de alarmes é confiável em qualquer estado da planta, tanto normal quanto em perturbação;
• Os operadores possuem um alto grau de confiança no sistema de alarmes e possui tempo para detectar e entender todos os alarmes;
• A configuração do sistema de alarmes não está sujeita a mudanças sem aviso prévio. Qualquer mudança deve passar por um procedimento padrão previamente definido.

4.5- Preditivo

É o nível de performance ideal do sistema de alarmes, seguindo todas as considerações explícitas na ISA 18.2 e EEMUA 191. Aqui o sistema de alarmes consegue prever o futuro estado de planta e adaptar as configurações para a necessidade do momento.

Seria ótimo para qualquer indústria, porém precisaria de tecnologias que vão além de um sistema de gerenciamento de alarmes. O nível preditivo seria caracterizado pelos seguintes fatores:

• O sistema de alarmes seria estável em todos os momentos e forneceria ao operador a informação certa no tempo certo para evitar distúrbios na planta ou minimizar qualquer impacto;
• Alarmes avisariam potenciais situações adversas muito antes delas ocorrerem utilizando análises sofisticadas e algoritmos.
• Mecanismos automáticos garantiriam que alarmes importantes não seriam perdidos pelo operador.

5. Análise do sistema de alarmes a partir de um sistema de gerenciamento de alarmes

Como já discutimos anteriormente, é humanamente impossível conseguir gerenciar todos os alarmes de uma indústria manualmente. Por isso, é altamente recomendado o uso de ferramentas que otimizem o processo de gerenciamento de alarmes.

Uma dessas ferramentas é um sistema de gerenciamento de alarmes que permite que você consiga sair de um nível sobrecarregado para um de maior estabilidade.

Além disso, fornece ao operador maior segurança nas suas tomadas de decisões, pois ele terá acesso à informações mais precisas do seu sistema.

É possível também fazer uma consulta histórica da sua indústria com um sistema de gerenciamento de alarmes. Um software de gerenciamento de alarmes permite que você tenha acesso a dados de semanas, meses e até anos atrás.

Com todos os KPIs disponibilizados em uma única ferramenta, fica mais fácil para identificar os problemas da planta e tomar as medidas corretivas necessárias.

Um dos softwares no mercado que atua como sistema de gerenciamento de alarmes é o da Logique Sistemas, compatível com todos os indicadores apresentados neste artigo, como sugerem as normas ISA 18.2 e EEMUA 191, além de uma série de outras análises.

Você pode conhecer mais sobre o BR-AlarmExpert aqui.

Conclusão

Se você leu até aqui, com certeza está mais preparado para otimizar a performance do seu sistema de alarmes. O nosso objetivo é que você tenha mais conhecimento sobre o que mensurar e possa fazer um diagnóstico atual da situação da sua indústria.

Podemos concluir que o trabalho de um operador pode ser facilmente otimizado com um sistema de gerenciamento de alarmes. Claramente, softwares realizam cálculos exaustivos com maior eficiência que a capacidade humana.

Quer se aprofundar ainda mais na prática de gerenciamento de alarmes? Não deixe de acessar o nosso ebook gratuito sobre o Guia Completo de Gerenciamento de Alarmes.

Enfim, se ficou qualquer dúvida sobre o desempenho de um sistema de alarmes pode falar comigo através do matheus.romano@logiquesistemas.com.br. Ficarei muito feliz em ajudar! Caso queiram conhecer como um sistema de gerenciamento de alarmes funciona na prática, também posso ajudá-los! 

Se você conhece algum colega que adoraria ler esse conteúdo, compartilhe com ele, pois acreditamos que conteúdo de valor deve ser compartilhado.