Nos primórdios da automação das máquinas e processos, ainda no auge dos comandos elétricos, botoeiras e sinaleiros, já era percebida a importância em se definir alarmes para evitar acidentes.

Mas naquela época os recursos eram limitados, então quando muito, havia apenas a possibilidade de se posicionar alguns indicadores luminosos ou sirenes nas máquinas ou no posto de operação. Esta dificuldade em se representar distintas condições de alarme com tão poucos recursos, fez com que os desenvolvedores de máquinas e engenheiros escolhessem muito bem quais situações desencadeariam o acionamento daquelas preciosas lâmpadas vermelhas no console de operação.

Talvez por decorrência destes recursos tão limitados, quando ocorria um alarme, naturalmente (e culturalmente) algo tinha que ser feito. Não era admissível que a máquina continuasse trabalhando com sirene ligada ou lâmpada de falha acesa. Obviamente isso contribuía também para garantir que as condições de alarme fossem sempre legítimas.

Com o avanço da terceira revolução industrial na década de 80 e a entrada dos CLPs e IHMs na automação, o cenário mudou: passou a ser simples criar inúmeras variáveis para representar condições de falha. E ainda mais simples foi fazer com que estas variáveis desencadeassem animações “piscantes” em vermelho, laranja, amarelo ou qualquer outra cor nas estações de operação.

As novas possibilidades eram incríveis! Não havia limites para a quantidade de alarmes individuais, e estes agora podiam ser acompanhados de descrições detalhadas, nível de criticidade, recomendação de ação para o operador etc. Tudo isso ao preço de alguns cliques de mouse e teclado.

Contudo, o que se observou ao longo dos anos foi um uso inapropriado de todos estes recursos, de modo que o legado que se tem hoje em muitas indústrias são processos sem gestão de alarmes adequada que se perderam diante de tantas possibilidades, tornando-se menos eficientes que aquelas velhas lâmpadas vermelhas. Ou pior! Desvirtuaram-se tanto a ponto de mascarar riscos reais, e hoje estão atrapalhando mais do que ajudando na prevenção de acidentes.

Normas internacionais

Investigações de acidentes graves ocorridos em diversos seguimentos industriais apontaram que a ineficiência dos sistemas de alarmes tiveram contribuição importante na causa raiz destas ocorrências. Foi a partir destas conclusões que surgiu um esforço global para se criar manuais e normas internacionais a respeito da gestão de alarmes industriais.

Dentre estes manuais e normas, destacam-se:

  • EEMUA191:

Criada após o acidente da Texaco em Milford Haven – Inglaterra (1994).

É uma coleção de boas práticas de engenharia também conhecida como UK HSE.

Edição mais recente 2013

  • ISA 18.2 / IEC 62682:

Tratam-se realmente de normas que são passíveis de serem auditadas.

Isso porque as duas trazem tópicos ou condutas requeridas para garantir compatibilidade.

Ambas são muito similares, possuindo basicamente os mesmos tópicos e são equivalentes no que diz respeito a gerenciamento de alarmes.

A revisão mais recente pertence a ISA 18.2 (2016)

 

O principal “lema” de todos estes documentos é a definição do que seria um alarme. E quanto a isso todos concordam:

“Alarme é uma notificação visual e/ou sonora que indica ao operador um mal funcionamento de equipamento, desvio no processo ou condição anormal que requer uma ação num tempo limitado.”

Embora a frase seja curta e simples, garantir que todos os alarmes satisfaçam este “mandamento”, exigirá bastante trabalho e planejamento.

 

Principais problemas

Após anos, ou mesmo décadas, sem iniciativas de gestão de alarmes, os sistemas de controle costumam apresentar os problemas descritos abaixo:

  • Alarmes tagarelas (Chattering): Entram e saem da condição de alarme diversas vezes por minuto, enchendo bastante os sumários e logs nos sistemas supervisórios. Normalmente em pouco tempo o operador passa a desconsiderar as notificações.   
  • Alarmes Efêmeros (Fleeting): Entram na condição de alarme e saem automaticamente, mas tal comportamento não se repete tão frequentemente como no caso anterior.
  • Alarmes Duplicados: Devido às notificações que ocorrem em cadeia ou devido às lógicas erradas no sistema de controle.
  • Alarmes obsoletos (Stale): São alarmes que se mantem ativos por muito tempo mesmo após o operador tomar ação.
  • Alarmes que não requerem ação do operador: Na prática, são eventos que não deveriam ser considerados alarmes.
  • Inundação de alarmes (Alarm flood): Diante de um desvio no processo, uma quantidade imensa de alarmes ocorre, sendo humanamente impossível para o operador gerenciá-los e mascarando a causa raiz do problema.

 

O caminho para a solução

Para solucionar estes e outros problemas, tanto a ISA 18.2 quanto a IEC 62682 determinam uma mesma metodologia para o gerenciamento de alarmes. O modelo define um processo de melhoria contínua composto de diversas etapas bem definidas e sequenciais como apresentado abaixo. As principais etapas são descritas em seguida:

 

Filosofia

Na maioria dos projetos, o ponto de entrada é realmente a criação da Filosofia de Alarmes, onde as normas e guias de boas práticas serão consultadas e adaptadas para a realidade de cada empresa/processo. O resultado desta etapa é um documento amplo que servirá como referência primordial para todas as demais etapas. Muitas vezes a criação da Filosofia significa um projeto à parte anterior aos demais, onde uma equipe multidisciplinar irá contar com ajuda de um facilitador/especialista para criação de um documento robusto contendo todos os temas e detalhes requeridos pela norma.

Identificação

Em empresas que já adotam o gerenciamento de alarmes e, portanto, já possuem um documento de filosofia, é possível que o ponto de entrada de um novo projeto seja a etapa de Identificação. Nesta etapa análises do sistema de controle, documentação de P&ID, RAZOP, etc. serão usados para identificar os alarmes pré-existentes e potenciais do processo. A saída desta etapa é uma lista detalhada de todos os eventos a serem analisados e validados nas próximas etapas.

Racionalização

É onde todos os eventos levantados durante a fase anterior são confrontados contra os princípios definidos na Filosofia de alarmes da empresa/processo. É provável que muitos eventos considerados “alarmes” sejam descartados ou remanejados para outras formas de notificação como alertas ou informativos. Contudo, é errado assumir que a Racionalização sempre reduzirá a quantidade global de alarmes cadastrados. Na verdade, pode acontecer justamente o oposto caso o processo tenha muitos pontos não cobertos. Por outro lado, é certo que o sucesso da Racionalização resultará numa lista de alarmes bem pensados, validados e corretamente ajustados para não causar sobrecarga aos operadores.

Projeto detalhado

É a fase onde o sistema de controle e supervisão, assim como ferramentas de relatórios serão avaliadas e otimizadas para que os requisitos das normas possam ser atingidos. Por exemplo, pode ser necessário a criação de blocos de lógica padrão para os CLPs, relatórios de desempenho de alarmes, alterações no sistema supervisório, etc.

Implementação

Aqui, todas as mudanças precisam ser colocadas em prática. Ou seja, os programas de CLP, as IHMs e os sistemas supervisórios serão alterados de acordo com as etapas anteriores. Contudo, tais mudanças devem ser aplicadas previamente em ambiente de laboratório e validadas antes de serem colocadas em produção. Também é importante os operadores sejam treinados antes das mudanças serem replicadas no chão de fábrica.

 

Conclusão

Anualmente ocorrem centenas de incidentes e acidentes nas indústrias. Tragédias destroem inúmeras vidas, contaminam mares e rios ou destroem marcas consagradas (as vezes tudo num único pacote). Se olharmos apenas para o Brasil, encontraremos muitos exemplos recentes.

Se por um lado não é prudente atribuir a “culpa” destes acidentes pura e simplesmente às falhas no sistema de alarmes, por outro, é certo dizer que um sistema de alarmes robusto poderia sim ter minimizado ou até evitado tais ocorrências.

Além da segurança operacional, hoje um dos maiores desafios das indústrias é produzir com eficiência, ou seja, produzir com qualidade, no menor tempo e com o menor uso de recursos possível, e o gerenciamento de alarmes é uma peça importante nesse processo de melhoria.

Imagine sua empresa totalmente automatizada e integrada, com um banco de dados único e acesso às informações de chão de fábrica via web, em tempo real, onde você verifica e toma decisões de qualquer lugar do mundo de maneira rápida e assertiva. Agora imagine esse mesmo cenário com 60 alarmes por minuto na sua tela, sendo que 90% deles não fazem o menor sentido, ou não agregam nada para eficiência ou segurança produtiva. Como tomar decisões rápidas com tanto “nevoeiro”?

A Nordika acredita que o caminho para a Indústria 4.0 começa pela estruturação e automatização de processos fabris. A avaliação da Maturidade Tecnológica é essencial para que isso ocorra e o Gerenciamento de Alarmes é uma das ferramentas dessa estruturação. Nós estamos aptos a conduzir o planejamento e execução de todas as etapas previstas nas normas internacionais ISA 18.2 e IEC 62682, e ajudar a sua empresa a começar com o pé direito essa incrível jornada.

Egberto Nunes da Silva, ENSI Eng. Automação Automação, Nordika BR Engenharia Elétrica 15 anos de experiência

Graduado em engenharia elétrica e pós-graduado em big data e ciência de dados. Possui 15 anos de experiência em automação e soluções de software para a indústria. Familiarizado com ferramentas Rockwell, Siemens e Aveva/ Wonderware. Apto a trabalhar com projetos que envolvam soluções IIoT, big data e ciência de dados.