O ORPAON
SCADA e sistemas supervisórios

Alarme demais e ninguém lê: como desenhar classificação, inibição e arquivo de reset no SCADA

A lista de alarmes rola sem parar, milhares de ocorrências por turno, o som já foi silenciado há tempo, e a manutenção só volta ao histórico depois que a máquina parou — essa situação é comum. A causa em geral não é a quantidade de pontos de alarme, e sim a falta de classificação, de inibição e de regra de fechamento, de modo que a lista não deixa escolher a ocorrência que de fato precisa de ação. Este artigo organiza as causas do transbordamento e as ações de governança que se consegue implantar: classificação, inibição, arquivo de reset e fechamento pelo responsável.

Cinco causas do transbordamento de alarmes

  • Sem classificação: falha que para a máquina e informação de referência saltam com a mesma cor e o mesmo som, e o operador não sabe qual tratar primeiro
  • Alarme repetido por oscilação: o valor cruza o limiar de um lado a outro, a mesma ocorrência dispara dezenas de vezes em poucos minutos e enche a lista
  • Uma falha dispara cadeia: uma máquina a montante para, os postos a jusante geram dezenas de alarmes derivados, e a causa primeiro-out fica enterrada no meio
  • Sem estratégia de inibição: durante parada, manutenção ou comissionamento, as condições de operação normal continuam valendo e produzem alarmes irrelevantes para o momento
  • Ninguém fecha: depois que o alarme ocorre, ninguém confirma nem registra o resultado do tratamento; os não fechados se acumulam e a lista nunca limpa

O ponto comum das cinco não é “a lista está longa”: é “na lista não se escolhe a que precisa ser vista”. A governança de alarme trata disto.

Cinco ações de governança que se consegue implantar

Governar alarme não é apagar ponto de alarme. Apagou, o campo continua falhando — só que ninguém sabe. O que se faz é dar a cada alarme classe, condição de disparo, regra de inibição e responsável, para ele aparecer só quando precisa ser visto.

  • Definição de classes: cor, som, destinatário da notificação e prazo de resposta por classe, com o mesmo modo de exibição em toda a planta
  • Deadband e inibição por atraso: faixa morta no limiar, duração distinta para ocorrência e retorno, para o sinal oscilante ser filtrado antes de entrar na lista
  • Primeiro-out e inibição em cadeia: definir relação pai-filho entre alarmes; enquanto o montante está parado, inibir os derivados a jusante; a lista fica só com o primeiro-out
  • Regras de reset e arquivo: registrar ocorrência, confirmação, retorno e fechamento, gravar no histórico e formar um evento de alarme consultável
  • Fechamento pelo responsável: nomear o respondente de primeira linha por classe e olhar, todo dia, a quantidade de não fechados e o tempo de permanência — não só o total de ocorrências

Como definir o padrão de classes

Três a quatro classes são mais fáceis de manter. Quanto mais classes, mais difícil o critério se sustentar no campo, e o resultado degenera para todo mundo preencher a mesma classe.

O critério de corte pode usar três eixos: se o equipamento parou, se afeta qualidade, se envolve segurança. Se duas classes pedem exatamente a mesma ação da equipe, não deveriam ser duas classes.

ClasseCritérioExigência de resposta
Emergência (classe 1)Envolve segurança ou meio ambiente, ou o equipamento já parou de imediatoTratar na hora; o plantonista do turno recebe na hora; o tratamento precisa deixar registro
Importante (classe 2)Pode gerar defeito de qualidade ou parar a linha, mas ainda não parouTratar no turno; avisar o responsável da manutenção; confirmar o estado na passagem de turno
Atenção (classe 3)Sinal de tendência de degradação, proximidade do limite e outros precursoresConfirmar no dia; entra na estatística do relatório diário; olhar a tendência por semana
Registro (classe 4)Mudança de estado, histórico de operação e outras informações de referênciaNão empurrar, não soar; só gravar no histórico para rastreio

A tabela acima é um template de partida, não um padrão universal. O critério precisa ser cruzado, alarme a alarme, com o equipamento e o processo concretos do campo.

Inibição e push precisam ser desenhados juntos

Inibição e push são as duas faces da mesma coisa. Acrescentar canal de push sem inibir faz o celular tocar junto — e no fim vai para mudo. Quanto mais canal, mais completo o ignorar.

  • Inibir por modo de operação: em parada, manutenção ou comissionamento, mascarar o grupo inteiro de alarmes e mostrar com clareza na tela que está mascarado
  • Camadas de canal de push: a tela cobre todas as classes; o som só as duas primeiras; e-mail e móvel só a emergência — cada camada estreita
  • Regra de escalonamento pelo tempo de permanência: só sobe de nível o alarme que passou do prazo combinado sem fechar, não o disparo por quantidade de ocorrências
  • Máscara com validade: inibição temporária sempre tem data de término e restaura sozinha, para não deixar máscara permanente que ninguém lembra

Usar o arquivo histórico para revisitar o evento

No histórico de alarmes, três coisas valem olhar todo mês: as ocorrências que mais disparam, o tempo médio de fechamento e as repetições suspeitas de oscilação. Na maior parte dos campos, tratar as dez primeiras já muda de forma visível o comprimento da lista.

A revisão não é de uma vez. Limiar e classe precisam de ajuste trimestral; essa regra de operação convém entrar no acordo técnico já na aceitação. Participamos da engenharia de governança de alarmes num projeto concreto da ordem de 30.000 pontos de alarme. Esses números descrevem um trabalho específico; não são o tamanho típico de todo campo, nem a promessa de quantidade de pontos da propaganda de software copiada para cada contrato. O escopo cobriu classificação, arquivo de reset, gestão de eventos e push em vários canais; em projetos de SCADA de grupo de estações de bombeamento, classificação de alarmes e gestão de eventos também correm do mesmo modo.

Em resumo

Alarme demais e ninguém lê é, na essência, problema de desenho, não de quantidade. Definição de classes, deadband e atraso, primeiro-out e inibição em cadeia, regras de reset e arquivo, fechamento pelo responsável — feitas essas cinco, a lista vira ferramenta em que o turno consegue se apoiar.

Se ainda não está claro como os alarmes do campo se distribuem, exporte um trecho de histórico e faça uma estatística: primeiro veja quantidade de ocorrências e fechamento, depois decida o escopo da governança.

Organizar a lista de alarmes do campo

Envie a lista atual de pontos de alarme e um trecho de histórico. Podemos rascunhar uma proposta de classificação e de estratégia de inibição.

Fale conosco