Você já viu isso em filmes. Provavelmente dramatizado demais, mas não muito. Um grande problema em alguma sala de controle (não importa de que tipo) surgiu. Pode ser devido a um defeito, terroristas ou até mesmo alienígenas. As telas de controle do computador acendem e começam a piscar. Buzinas estão tocando e faróis giratórios são ativados. Todos estão chocados e confusos — é uma cena caótica.

Parece exagero? Não é. Nos minutos que antecederam os grandes acidentes envolvendo processo reais, os operadores muitas vezes se depararam com centenas a milhares de alarmes ocorrendo em apenas alguns minutos. Eles se deparam com listas de alarmes rolando rápido demais para serem lidas, processam gráficos de computador cobertos por símbolos brilhantes e avisos sonoros que se repetem assim que são silenciados. O sistema de alarme torna-se uma distração incômoda para o operador, em vez de uma ferramenta útil para ajudar a enfrentar com condições anormais. A probabilidade de um resultado bem-sucedido para a situação diminui e interrupções no processo ou até mesmo danos podem ocorrer. Então, como nossos sistemas de alarme ficaram tão ruins?

Como muitos problemas, isso começou com a melhor das intenções. Nos velhos tempos (digamos, antes da década de 1990), uma sala de controle típica tinha uma parede repleta de indicadores de processos individuais, luzes, interruptores e gráficos de canetas móveis. Esses itens ocupavam muito espaço, sempre escasso. O sistema de alarme era simples – um conjunto retangular com algumas dezenas (no máximo) de janelas rotuladas que se iluminavam e piscavam individualmente com base na conexão dos processos. Esta caixa de luz também incorporava uma buzina que soaria e um botão de reconhecimento para silenciá-la e mudar a luz piscante para uma luz constante. (Este botão de reconhecimento era muitas vezes modificado pelos operadores com uma cunha de papel ou moeda para segurá-lo e evitar que o ruído infernal ocorresse. Esta modificação do usuário quase certamente estaria em vigor no turno da noite, mas podia ser removida durante o dia.)

O conceito de parede de controle tinha muitas coisas positivas a seu favor. Uma considerável reflexão foi dedicada ao posicionamento e agrupamento dos instrumentos.

Os intervalos normais nos instrumentos foram marcados. As tendências eram sempre visíveis se o papel e a tinta fossem substituídos. A saúde geral do processo geralmente podia ser determinada rapidamente. A exibição de alarmes frequentemente gerava padrões reproduzíveis, dependendo do tipo de perturbação.

Esses sistemas também tinham muitas desvantagens. A conectividade entre controladores era praticamente inexistente. A criação de esquemas de controle complexos era difícil e cara. A introdução de novos controles envolvia uma realocação dispendiosa de elementos adjacentes ou o sacrifício do seu posicionamento lógico.

A comunicação de informações do sistema de controle para outros sistemas era geralmente inviável. E análise de dados? Esqueça isso.

Em relação aos alarmes na mesa de luz, a adição de um novo custava caro. Seu número total foi limitado pela disponibilidade de espaço e custo. Portanto, cada um foi avaliado e justificado individualmente (o que era algo bom!)

Esta era a situação anterior à revolução digital e à introdução de controles modernos, como Sistemas de Controle Distribuído (DCSs) e sistemas de Controle de Supervisão e Aquisição de Dados (SCADA). Esses

sistemas fornecem operações substanciais e vantagens de negócio, incluindo capacidade de expansão, facilidade de reconfiguração de estratégias de controle e histórico/análise de dados de processo. Quase tudo no sistema de controle pode ser modificado sem grandes problemas. (No entanto, todos esses atributos trazem consigo seus próprios problemas.) Para estas vantagens, os sistemas de controle mais antigos, como o mostrado na foto, foram convertidos em sistemas DCS e SCADA a partir da década de 1990.

A situação dos alarmes é muito diferente em um DCS e em um sistema mais antigo. Como os alarmes são exibidos em listas de rolagem computadorizadas e em gráficos, eles têm um espaço ilimitado. E como cada “ponto” no DCS é essencialmente uma construção de software, os alarmes tornaram-se gratuitos! A maioria dos tipos de pontos em um DCS tem vários alarmes pré-programados apenas aguardando que o engenheiro de controle ou outro usuário os configure e ative pressionando algumas teclas. Sem justificativas, sem fiação, sem tubulação, sem gravação em plástico – basta clicar, clicar, clicar e você terá um novo alarme.

E nós os criamos! Sem diretrizes consistentes disponíveis, a configuração excessiva massiva de alarmes DCS tornou-se comum. Afinal de contas, se o fabricante forneceu a funcionalidade de alarme Alto, Alto-Alto e até AAA, então eles devem estar aí por um bom motivo, de maneira que vamos usar todos eles!

Sem diretrizes ou custos para a criação de alarmes, práticas inadequadas surgiram – como todos os alarmes serem ativados por padrão, configurações feitas por regras básicas inconsistentes ou configurações de acordo com a preferência de um indivíduo. A consistência era baixa. Sistemas de processos similares implementados por equipes diferentes teriam configurações e comportamentos de alarme significativamente distintos. (Os engenheiros adoram ser criativos quando não recebemos nenhuma orientação!) Os alarmes eram frequentemente utilizados ​​como um método simples para indicar o status (algo está ligado ou desligado), em vez de indicar uma situação anormal real (algo está desligado, mas deveria estar ligado).

O resultado? Para o operador, isso significava que, embora sua antiga “parede de controle” provavelmente tivesse menos de 100 alarmes possíveis, seu novo console DCS provavelmente tinha de 2.000 a 4.000 alarmes configurados, gerando centenas a milhares de anúncios de alarmes diariamente! Mesmo na operação do processo em estado estacionário, o sistema de alarme é ativado quase constantemente, criando muito mais ocorrências de alarmes do que o operador pode entender e agir. Durante uma interrupção do processo, há um aumento de ordem de grandeza no número e na velocidade das ocorrências de alarmes, tornando o sistema de alarme inútil e criando um obstáculo ativo à capacidade do operador de enfrentar a situação. Repetidamente, relatórios investigativos após grandes acidentes industriais mostraram que sistemas de alarme sobrecarregados, desconsiderados ou ignorados desempenharam um papel significativo no agravamento da situação.

 

Acidentes graves são apenas o começo. É bem sabido que um sistema de alarme ineficaz pode fazer com que um problema em um processo normal fique pior ou dure mais tempo. Esses transtornos podem custar muito dinheiro às empresas. 

Esta situação ruim foi agravada pela facilidade de modificação de alarmes em um DCS. Não somente os engenheiros poderiam modificar a configuração dos alarmes mas também os operadores, técnicos de manutenção, subcontratados, gerentes e até mesmo estagiários. A alteração de alarmes é realizada facilmente a partir de um teclado de console e, em muitas instalações, essas mudanças tiveram pouca segurança ou supervisão durante anos.

Desde a década de 1990, os locais de produção têm políticas rigorosas de Gerenciamento de Mudanças (MOC) para gerenciar quase todas as mudanças físicas nas próprias instalações, mas estas muitas vezes não se aplicam a mudanças nos alarmes. Durante décadas, muitos sistemas de alarme tiveram configurações que mudam diariamente, pois dependem dos caprichos individuais de várias pessoas. Isso é loucura. Imagine se os pilotos que embarcam em um avião comercial não tivessem ideia de onde os pilotos anteriores deixaram as configurações dos alarmes da aeronave! Por muitos anos, a configuração, alteração e desvio de alarmes em um DCS têm sido frequentemente abordados de maneira ineficaz pelas políticas e práticas do MOC.

O resultado? Casos generalizados de sistemas de alarme sobrecarregados e ineficazes.

O problema dos alarmes começou a ser identificado e documentado no início da década de 1990. As investigações de alguns acidentes graves começaram a mencionar os sistemas de alarme DCS como fatores contribuintes significativos para os acidentes.

Um exemplo do relatório da Health and Safety Executive (HSE) do Reino Unido sobre um grande acidente em uma refinaria em 1994:

• Havia muitos alarmes e eles foram mal priorizados
• As telas da sala de controle não ajudaram os operadores a entender o que estava acontecendo
• Nos últimos 11 minutos antes da explosão, os dois operadores tiveram que reconhecer, aceitar e agir em 275 alarmes

Vários artigos foram escritos sobre gerenciamento de alarmes e diversas empresas começaram a oferecer diversos produtos e serviços para solucionar o problema, incluindo softwares desenvolvidos para analisar ocorrências de alarmes. O conceito de racionalização de alarmes foi desenvolvido para melhorar os sistemas existentes e um software de gestão de alarmes dinâmico e em tempo real foi introduzido.

O Consórcio de Abnormal Situation Management (ASM®) foi estabelecido em 1994 e começou a estudar aspectos do problema e agiu para aumentar significativamente a conscientização sobre ele. Em 1999, a Associação de Usuários de Equipamentos e Materiais de Engenharia (EEMUA) do Reino Unido elaborou um documento de referência seminal (sua Publicação 191) sobre o tema.

Em 2006, a PAS (agora parte da Hexagon) publicou a primeira edição do The Alarm Management Handbook (O Manual de Gerenciamento de Alarmes), com base em centenas de projetos bem-sucedidos de melhoria de alarmes. Esse livro tem sido amplamente considerado como tendo o conhecimento melhor e mais prático sobre como tornar os sistemas de alarme eficazes e atualmente está na sua segunda edição.

Esse livro foi seguido em 2008 pelo The High Performance HMI Handbook (O Manual de Alto Desempenho de HMI), que discutiu maneiras de tornar os gráficos de processo eficazes. Entre muitos outros temas, o livro sobre HMI detalha minuciosamente como realizar a exibição eficaz de alarmes em gráficos de processo.

Em 2008, a PAS foi coautora da prática recomendada do Electric Power Research Institute para gerenciamento de alarmes e participou da criação pelo American Petroleum Institute de uma prática recomendada similar para o setor de oleodutos. E em 2009, o PAS ajudou a escrever o ANSI/ISA-

18.2 norma de gerenciamento de alarmes, que foi um grande acontecimento com implicações regulatórias. O gerenciamento de alarmes atualmente é um tema amplamente documentado e o conhecimento para arrumar um sistema de alarme está amplamente disponível.

O ambiente regulamentar referente ao gerenciamento de alarmes é complexo. As declarações obrigatórias em normas como a ISA 18.2 (e a versão internacional IEC 62682 da 18.2) podem e são aplicadas por agências reguladoras em todo o mundo. Isso geralmente ocorre por meio de uma cláusula de “dever geral” nos regulamentos, como “O empregador DEVERÁ documentar que os equipamentos cumprem as boas práticas de engenharia reconhecidas e geralmente aceitas”, também conhecido como “RAGAGEP”.

As normas (como ISA 18.2 e IEC 62682) são desenvolvidas por um rigoroso processo de consenso. Elas são “boas práticas de engenharia reconhecidas e geralmente aceitas”. Dessa forma, tornam-se executáveis ​​devido a estas cláusulas de deveres gerais. Multas e penalidades foram aplicadas pelo não cumprimento das normas. Você pode se voluntariar para seguir um comitê de desenvolvimento e revisão de normas ISA e ajudar a moldar sua direção. Entre em contato conosco para obter mais informações ou se você tiver dúvidas

Nesta série de blogs Domando o sistema de alarmes selvagens, abordaremos várias maneiras práticas de melhorar seu sistema de alarme. Começaremos identificando e corrigindo seus piores alarmes incômodos com alguns métodos simples para obter muitas melhorias com pouco esforço.

Além desta série, recomendo também conferir o estudo Causando um grande impacto em alarmes incômodos.