Skip to main content

Operations & Maintenance

Domando o sistema de alarmes selvagens, Parte 5

Coisas horríveis identificadas durante a racionalização de alarmes


31 de outubro de 2022
Bill Hollifield


 

Engenheiro jovem e entusiasmado: “Estou fazendo algumas pesquisas e examinado nosso sistema de controle. Acho que precisamos fazer algo chamado racionalização de alarmes.”

Chefe do departamento de produção: “Verdade? Conte me mais sobre isso”. Engenheiro:    <Fornece uma explicação detalhada.>

Chefe de departamento: “Hum, parece interessante. Talvez possamos fazer isso em um ou dois anos. Isso me lembra que preciso agendar minha colonoscopia”.

OK, a racionalização de alarmes não é (tão) ruim assim. Há algumas semelhanças, pois ela é altamente recomendada, comprovada na prática e pode identificar e corrigir problemas menores antes que se tornem problemas grandes, caros e perigosos (e alguma boa tecnologia torna isso muito simples e fácil de fazer).

Se você não for racionalizado...

Um sistema de alarme que nunca foi racionalizado também será provavelmente aquele que foi criado sem o benefício de uma filosofia de alarmes consistente. Muitas vezes ele é uma coleção de ideias de muitas pessoas diferentes sobre o que deveria ser um alarme, implementadas ao longo de muitos anos e alteradas ao capricho de outras pessoas para refletir as suas preferências pessoais. Haverá grandes inconsistências nesse sistema.

Os sistemas de alarme não racionalizados terão centenas de alarmes sem sentido e que distraem e fazem pouco sentido para o operador. Eles são muitas vezes ignorados (com razão) e os operadores terão pouca confiança no sistema global. Isso pode fazer com que outros alarmes realmente importantes também sejam ignorados, uma vez que – como você pode saber a diferença? Os métodos de supressão de alarmes podem ser utilizados de uma maneira descontrolada, com alguns alarmes sendo suprimidos por dias, meses ou mais tempo. São contratempos e acidentes esperando para acontecer.

O sistema de alarme deve informar os operadores de maneira confiável sobre as condições do processo que necessitam da sua atenção. Um sistema não racionalizado não fará isso.

Como fazer isso

A racionalização de alarmes é uma metodologia comprovada para alinhar seu sistema de alarme com sua filosofia de alarmes e fazer isso funcionar como deveria. A Hexagon realizou milhares de racionalizações de alarmes bem-sucedidas em fábricas de todos os tipos em dezenas de países. Sabemos exatamente como fazer isso de uma maneira correta e econômica. No The Alarm Management Handbook – Second Edition, escrevemos um capítulo muito detalhado sobre como exatamente proceder com a racionalização.

Isso inclui muitas dicas, bem como armadilhas a serem evitadas. Se você nunca fez uma racionalização, aconselhamos que procure ajuda experiente. Fazer isso economizará muito mais tempo e dinheiro do que você gastaria sozinho. Sabemos como minimizar o impacto nos recursos da sua fábrica – mas você deve participar! Não acredite em ninguém que diga que pode racionalizar o seu sistema de alarme sem o seu envolvimento.

Para este blog, achamos mais interessante escrever sobre algumas das coisas estranhas e perturbadoras que descobrimos ao realizar tantos projetos de racionalização bem-sucedidos!

Antes e depois

Antes de começar a racionalização, você normalmente descobrirá que:

  • A frustração do operador é alta
  • Os alarmes ocorrem constantemente
  • A exibição do resumo do alarme sempre tem muitas páginas
  • A maioria dos alarmes são incômodos, e alguns até ocorrem com base em temporizadores
  • Os operadores estão constantemente apertando o botão de reconhecimento (o que não significa que o alarme foi lido ou entendido!)

Quando você terminar a racionalização, qual será o resultado? Aqui estão algumas citações e reações

Dos operadores:

“Finalmente o sistema de alarme faz sentido”.
“O sistema de alarme é útil agora. Com certeza não era antes”.
“Agora você pode entender os alarmes – eles têm um significado real”. “Não estou mais lidando constantemente com um monte de alarmes incompreensíveis”.
“Esta é a melhor coisa que já fizemos”.

Citação de um Supervisor de Operações: “…este projeto de racionalização nos trouxe muito mais benefícios do que apenas melhorar o sistema de alarme. Na verdade, ele nos ajudou a descobrir erros em nossos desenhos de tubulações e instrumentos (P&IDs), procedimentos incorretos, descritores de pontos errados e, em geral, mal-entendidos que tínhamos sobre como nossa fábrica funciona. Ele também identificou uma série de 'pegadinhas' que devem contribuir para melhorar a segurança e a operabilidade do processo”.

Observe que a racionalização não é “apenas se livrar dos alarmes”. Você sempre ficará surpreso ao descobrir que existem alarmes de que precisa urgentemente e que não estão configurados!

O que descobrimos

Aqui estão algumas das coisas que aprendemos ao realizar tantos projetos.

De uma apresentação em uma conferência do setor de energia: “A contribuição do tratamento de alarmes para problemas, emergências e incidentes nem sempre é reconhecida. A equipe de operações e manutenção geralmente aceita as inundações de alarmes e alarmes incômodos como o status quo”.

Esses números não estão apenas “um pouco fora” das diretrizes recomendadas, eles são horríveis!

O MOC e documentação deficientes são excessivos

Práticas inadequadas de gerenciamento de mudanças e documentação desatualizada ou “simplesmente errada” são comuns! Em muitos casos, a racionalização de alarmes é a primeira vez que algo que se parece vagamente com uma revisão de processo é realizado desde o início da operação da fábrica. É raro encontrar qualquer esforço envolvendo comparar o que está realmente configurado no sistema de controle com o que está detalhado em um P&ID ou em diagramas de loop!

Aqui estão algumas descobertas típicas. Elas resultam em mudanças extremamente necessárias na documentação dos processos, nas exibições operacionais, na lógica de programação, nos procedimentos e, algumas vezes, nos próprios equipamentos. Até que ponto uma fábrica com os problemas a seguir é segura?

  • Descritores de tags incorretos ou
  • faltantes Alarmes errados
  • configurados em um gráfico Alarmes importantes ausentes nos gráficos
  • Existem loops de instrumentos que não estão incluídos no P&ID
  • Loops de instrumentos são mostrados no P&ID que não existem no DCS
  • Equipamentos demolidos ainda são mostrado nos P&IDs
  • Há equipamentos que não são mostrados nos P&IDs
  • Faixas de instrumentos configuradas incorretamente (de onde vieram todos aqueles alarmes de PV ruim?)
  • Instrumentos redundantes com diferentes faixas configuradas e outras características
  • Chaves (pouco confiáveis) são usadas para fornecer alarmes críticos onde um transmissor está disponível. (Isso quase sempre será encontrado em fábricas mais antigas que passaram por uma atualização.)

Aqui estão alguns itens encontrados ao fazer uma grande racionalização em uma refinaria “famosa”. Ser grande não o torna preciso!

  • Muita documentação estava faltando e precisava ser atualizada
  • O “procedimento” de gerenciamento de mudanças e o processo de trabalho eram muito complexos, e erros na documentação mostravam que não eram confiáveis. P&IDs, manuais de equipamentos e manuais de treinamento de operações não foram atualizados após mudanças no projeto
  • Houve muitos conclusões incorretas ou contraditórias nos limites operacionais e nos envelopes operacionais em uso
  • Havia muitas etiquetas relacionadas a sistemas de segurança e intertravamento que não continham alarmes, mas deveriam. Isso foi muito surpreendente para os operadores. A manutenção ignora instrumentos com defeito e, portanto, os alarmes de diagnóstico são simplesmente desativados e ignorados


Agora, uma racionalização não entra nesses elementos sem razão. Ao preparar uma racionalização, a Hexagon utiliza um software que realmente importa as configurações de cada alarme, diretamente do sistema de controle. Dessa forma, nas discussões de alarme, às vezes ocorrem coisas como este exemplo:

Hexagon: “OK, para este alarme de pré-desligamento do reator, 350 graus é o ponto de ajuste correto?”

Cliente: “Sim. O alarme de DCS avisa o operador que o sistema de segurança está prestes a desligar o reator”.

Hexagon, posteriormente: “Então, o sistema de segurança emite um alarme quando ele desliga o reator. Hum – este desligamento está definido para 350 graus. Espere – como o alarme de DCS em 350 pode ser um ‘pré-alarme’ para o operador reagir e evitar o desligamento?”

Cliente: “Uau, parece que não pode”.

Hexagon: “E veja – o outro reator está ajustado em 360 graus? Não deveria ser a mesma coisa?

Cliente: “Hum, vamos pegar mais alguns documentos. Acho que houve um projeto que poderia ter feito isso…”

Aqui estão mais alguns de uma importante racionalização de uma fábrica de produtos químicos “famosa”:

  • A base do projeto da própria fábrica passou por algumas revisões nos últimos anos, mas a documentação nunca foi totalmente atualizada antes que a equipe do projeto fosse transferida para outro projeto. Os P&IDs resultantes eram uma colcha de retalhos de processos e melhorias abandonados há muito tempo.
  • Comentários do operador durante a racionalização:
    • “Ok, então eu sei que é assim que é desenhado, mas não é assim que realmente é”. “Isso não funciona há anos”.
    • “Esse sistema foi removido há cerca de uma década”.
    • “Este era para o processo antigo, ele precisa ser retirado”.
    • “Isso foi ignorado há muito tempo, precisamos que alguém faça uma ligação para saber se vamos mantê-lo”.
  • Os projetos nunca alteraram as etiquetas existentes no DCS, apenas criaram novas e deixaram as antigas ociosas no sistema: “Tivemos que eliminar diversos blocos lógicos e cálculos há muito obsoletos”.

Muitas usinas de energia com mais de 40 anos não têm P&IDs ou os P&IDs não são atualizados há anos. Uma declaração surpreendente, mas não incomum: “Sabemos que nossos P&IDs não são nada confiáveis, preferimos que você não os utilize”.

Histórias horríveis do campo

“No projeto de Petróleo e Gás, há um grande número de tags de DCS mapeadas através do MODBUS de vários sistemas empacotados. Essas tags não têm absolutamente nenhuma rastreabilidade com os desenhos de P&ID ou gráficos de DCS dos respectivos sistemas. Estes incluem entradas, saídas, blocos lógicos (sequências), diagnósticos, e assim por diante. Quase todos possuem alarmes configurados. As descrições em muitas dessas etiquetas eram idênticas e às vezes nem faziam sentido. A maioria desses alarmes representava eventos normais e foram removidos”.

“Eu estava fazendo racionalização em **** para a refinaria ****. Eles têm um sistema Foxboro lá. Havia cerca de 25.000 pontos no sistema. Os alarmes foram configurados como se fosse um banco de dados de teste para as pessoas que controlavam o trabalho de engenharia lógica durante a configuração do banco de dados. Basta nomeá-lo e você encontrará alarmes configurados nele. Quando terminamos, eles não apenas obtiveram um sistema de alarme racionalizado, mas também uma lista de grandes melhorias de processos e documentação que os ajudariam a sair do modo constante de ‘combate a incêndios’ e a se concentrar em melhorias duradouras e de longo prazo”.

Alarmes e segurança pessoal

Aqui estão algumas discussões interessantes:

Cliente: “Esse alarme ocorre antes da válvula de segurança do vapor explodir. Esta tem que ser a maior prioridade”.

Hexagon: “Por quê?”

Cliente: “Porque a válvula de segurança está apontada para a passarela”. (Segue-se uma conversa sobre como a prioridade do alarme não desvia o vapor vivo, mas um pedaço de tubulação de ventilação faz isso.)

Houve um alarme no transportador de carvão para indicar que a mão ou o corpo de uma pessoa poderia ficar preso nele.

Cliente: “Defina isso como sendo de baixa prioridade”. Hexagon (horrorizada): “POR QUE??!!”

Cliente: “Na maioria das vezes, este é um alarme falso devido a mau funcionamento do equipamento”.

(Segue uma conversa sobre alarmes relacionados à segurança pessoal, advogados e à necessidade de manter sensores importantes!)

Sumário

A racionalização não é apenas uma ideia extremamente boa; ela também é um requisito dos padrões de gerenciamento de alarmes ISA 18.2 e IEC 62682. O que se deseja é uma racionalização produtiva e eficiente com o melhor resultado possível. Para conseguir isso, você deve ler o Manual para saber como fazer isso, seguir as práticas comprovadas, obter ajuda se for novo no assunto e usar as ferramentas certas. Um pouco de esforço é preciso, mas os benefícios são enormes. Nós nunca tivemos um cliente dizendo: “Isso foi uma grande perda de tempo!” Muito pelo contrário – muitas vezes temos operadores (um grupo muito cético!) que começam a fazer lobby para ajudar outras unidades que ainda não foram racionalizadas. Portanto, não fique adiando a racionalização dos alarmes (ou aquela colonoscopia…)!

Entre em contato conosco para obter mais informações ou se você tiver dúvidas

About the Author

Bill Hollifield is the Hexagon Principal Alarm Management and High Performance HMI consultant, with more than 25 years of experience in the process industry in engineering, operations, and control systems, and an additional 20 years in alarm management consulting and services for the petrochemical, power generation, pipeline, mining, and other industries. He is a member of the ISA-18.2 Alarm Management committee, the ISA SP101 HMI committee, the American Petroleum Institute’s API RP-1167 Alarm Management Recommended Practice committee, and the Engineering Equipment and Materials Users Association (EEMUA) Industry Review Group. In 2014, Bill was named an ISA Fellow for industry contributions in these areas. Bill is also the co-author of The Alarm Management Handbook, First and Second Editions, © PAS 2010 The High Performance HMI Handbook, © PAS 2008, The ISA book: Alarm Management: A Comprehensive Guide, Second Edition, © ISA 2011 and The Electric Power Research Institute (EPRI) guideline on Alarm Management for Power Generation (2008) and Power Transmission (2016). He has authored several papers, articles and ISA technical reports on Alarm Management and High Performance HMI and is a regular presenter on such topics at API, ISA, and Electric Power symposiums. He has a BSME from Louisiana Tech University, an MBA from the University of Houston, and has built his own plane (an RV-12) with a High Performance HMI.

Profile Photo of Bill Hollifield