Gestão de alarmes para engenheiros de HMI

Podes desenhar o ecrã de operador mais tranquilo e mais conforme às normas do mundo e ele continua a falhar se o sistema de alarmes por baixo estiver estragado. A disciplina de cor no ecrã e a disciplina de alarmes na lógica são o mesmo projeto visto de dois lados — e a maioria das instalações só faz a primeira metade.

Este guia é a metade dos alarmes. Está escrito para quem constrói a HMI, não para o departamento de segurança de processo: o que a gestão de alarmes te exige na prática, que decisões têm de ser tomadas antes de desenhares seja o que for, e exatamente como a prioridade de alarme deve aparecer no ecrã.

1. O modo de falha: ninguém desenhou os alarmes

Os alarmes são a única parte de um sistema de controlo que quase nunca chega a ser desenhada. Os símbolos são revistos. Os layouts dos ecrãs são revistos. Os alarmes são acrescentados — um de cada vez, ao longo de anos, por quem estivesse na instalação nessa semana, normalmente em resposta a um incidente que ninguém quer repetir.

O resultado é previsível e notavelmente consistente em todos os setores:

• Avalanches de alarmes. Uma única perturbação dispara um alarme, que dispara doze alarmes consequentes, e o operador não consegue lê-los suficientemente depressa para agir sobre nenhum deles.
• Alarmes permanentes. Alarmes que estão ativos há semanas porque a condição é real mas ninguém a consegue resolver. Ocupam a lista de resumo em permanência, e o operador aprende a passar por eles sem parar.
• Alarmes intermitentes (chattering). Um sinal encostado ao seu limiar gera centenas de transições por hora. Todas elas são ruído.
• Alarmes que não são alarmes. “A bomba 3 arrancou.” Não há nada de errado; não há nada a fazer. É um evento, registado como alarme, a competir pela mesma atenção.

A medida habitual de saúde é a taxa de alarmes por operador. O critério amplamente citado da EEMUA 191 trata cerca de 150 alarmes por operador e por dia (cerca de seis por hora) como o limite do que é gerível em operação estável, com o alvo “muito provavelmente aceitável” mais perto de um alarme a cada dez minutos e um limite máximo de cerca de dez alarmes nos dez minutos seguintes a uma perturbação. A maioria das instalações existentes que se mede pela primeira vez encontra taxas várias vezes superiores.

Trata esses números como um termómetro, não como um alvo a que desenhar. Se a tua taxa é de 2000 por dia, o problema não é precisares de apagar 1850 alarmes — é que nunca ninguém decidiu para que serve um alarme nesta instalação.

2. A única regra que resolve quase tudo

A ISA-18.2 define um alarme como um meio audível ou visível de indicar uma avaria de equipamento, um desvio de processo ou uma condição anormal que requer uma resposta. São essas últimas palavras que carregam a norma inteira.

Portanto, o teste para cada alarme candidato é uma única pergunta, e não é uma pergunta técnica:

O que é que o operador deve fazer em relação a isto, e quanto tempo tem?

Se não houver resposta — nenhuma ação, ou uma ação que ninguém conseguiria executar a tempo, ou uma ação que acontece automaticamente de qualquer maneira — então não é um alarme. Pode ser uma entrada de registo, uma tendência, uma ordem de trabalho de manutenção ou uma indicação de estado no ecrã. Tudo isso é útil. Nada disso deve fazer barulho nem ocupar o banner de alarmes.

Aplicar apenas esta regra, sem qualquer ferramenta, elimina tipicamente uma grande fração de uma lista de alarmes herdada. É também a regra que torna o design da HMI tratável: o que sobrevive é suficientemente pequeno para ser representado com honestidade num ecrã.

3. O ciclo de vida da ISA-18.2, pela ordem em que o encontras

A ISA-18.2 (também publicada como IEC 62682) enquadra a gestão de alarmes como um ciclo de vida e não como um documento. Enquanto engenheiro de HMI, vais encontrar as etapas mais ou menos por esta ordem:

Não precisas de ser dono do ciclo de vida. Precisas, sim, de te recusares a adivinhar as partes que foram saltadas: se ninguém te souber dizer a prioridade de um alarme e o que o operador faz em relação a ele, isso é uma constatação a registar, não um detalhe para preencheres por tua conta.

4. Atribuir prioridade sem discussões

A prioridade não é importância nem é gravidade. É a urgência da resposta do operador, derivada de duas coisas: quão má é a consequência se nada for feito, e quanto tempo tem o operador antes de essa consequência chegar.

Uma matriz consequência/tempo mantém a discussão objetiva. Uma atribuição típica de quatro níveis:

A distribuição importa tanto como as definições. Se um terço dos teus alarmes for P1, o esquema de prioridades não transporta informação nenhuma — o operador não consegue triar uma lista em que tudo é crítico. Aproximadamente 5 / 15 / 80 é a forma que a maioria das filosofias de alarme procura, e vale a pena confrontar a tua lista com ela antes de desenhares uma única visualização.

O P4 merece desconfiança. Na prática, a maioria dos “alarmes informativos” são eventos que pertencem a um registo ou a um campo de estado no ecrã. Se nunca requer uma resposta, questiona se deve sequer estar no sistema de alarmes.

5. Mostrar a prioridade no ecrã

Agora a parte da HMI. A paleta tranquila da ISA-101 existe precisamente para que a cor de alarme tenha onde aterrar. O mapeamento canónico:

Três regras governam a forma como estas aparecem:

A cor nunca é a única pista

Cerca de um em cada doze homens tem alguma forma de deficiência de visão de cores, e a confusão vermelho/verde é a mais comum. Toda a indicação de alarme tem de transportar uma segunda pista, não cromática: o número de prioridade no badge (P1, P2), uma forma distinta, uma posição ou texto. Um círculo vermelho e um círculo laranja que só diferem no tom são, para uma parte significativa dos teus operadores, o mesmo círculo.

O alarme vai em cima do equipamento, não ao lado dele

Um operador a percorrer um sinóptico com o olhar deve conseguir responder a “o que está mal e onde” numa única fixação. Isso significa que o badge de alarme fica sobre a bomba, a válvula, o motor — um pequeno disco preenchido num canto consistente do símbolo, com o texto da prioridade. O equipamento continua a mostrar o seu próprio estado (em marcha, parado, sem feedback) por baixo; o badge é aditivo.

É por isto que os nove estados de motor normalizados incluem “em marcha + alarme P1” e “em marcha + alarme P2” como estados distintos, em vez de substituírem a cor de marcha: o operador precisa dos dois factos ao mesmo tempo.

Piscar significa não reconhecido, e mais nada

Piscar é o sinal de atenção mais caro que tens, e é exaustivo. Reserva-o para um único significado: um alarme novo que ainda ninguém reconheceu. Uma vez reconhecido, o badge fica sólido e assim permanece até a condição desaparecer. Um ecrã onde as coisas piscam em permanência ensinou os seus operadores a ignorar o piscar.

6. As três visualizações de que um sistema de alarmes precisa

1. O banner. Sempre visível, em todos os ecrãs, a mostrar os alarmes não reconhecidos de prioridade mais alta — tipicamente a linha ou as duas linhas mais recentes. Responde a “está alguma coisa mal neste momento?” sem navegação.
2. O resumo. Uma lista ordenável e filtrável de alarmes ativos com prioridade, tag, descrição, hora e estado de reconhecimento. A ordenação por defeito deve ser primeiro por prioridade e depois por hora — e não só por hora, o que enterra um P1 debaixo de uma avalanche de P3.
3. O badge no sinóptico. No gráfico de processo, como descrito acima. É isto que converte “LSHH-104 muito muito alto” em “aquele depósito, ali”.

Uma quarta vista — a página de histórico/análise de alarmes — é para engenharia e não para operação, mas é dela que saem as tuas métricas de taxa e as listas de reincidentes, por isso não a omitas.

7. Shelving, supressão e fora de serviço — mostra-os

Toda a instalação real precisa de uma forma de silenciar temporariamente um alarme: um transmissor que se sabe avariado, uma unidade parada para manutenção, um alarme incómodo à espera de correção. A ISA-18.2 distingue estes mecanismos, e a consequência importante para a HMI é a mesma para todos eles:

Um alarme suprimido tem de estar visivelmente suprimido. Nunca deixes que o ecrã dê a entender que um alarme silencioso é um alarme saudável.

Na prática: uma tag em shelving mantém um marcador esbatido no sinóptico, aparece num filtro dedicado de “em shelving” no resumo e tem um prazo de validade. Fazer shelving sem prazo transforma-se em supressão permanente, que é como as instalações acabam com instrumentos “temporariamente” desativados há três anos.

8. Matar o ruído antes de chegar ao ecrã

A maior parte do ruído de alarmes resolve-se na lógica, e sai mais barato aí do que na HMI:

• Banda morta. O alarme desaparece a um valor significativamente dentro do limiar, e não no próprio limiar. Uma pequena percentagem da gama elimina a maior parte do ruído por oscilação.
• Atraso à ativação. A condição tem de persistir durante um tempo definido antes de o alarme ser levantado. Os transitórios que se resolvem sozinhos em dois segundos nunca precisaram de um operador.
• Atraso à desativação. Evita a tremulação à saída.
• Supressão baseada no estado. Um alarme de caudal baixo numa bomba parada não é informação; é ruído. Suprime os alarmes que não têm significado no estado atual do equipamento — e faz com que essa lógica seja explícita e documentada, e não um truque escondido.
• Agrupamento por primeiro evento / causa-efeito. Quando um evento raiz produz necessariamente dez alarmes consequentes, apresenta a causa raiz e recolhe os restantes.

Estas são as alterações com maior alavancagem disponíveis. Só a banda morta e o atraso à ativação cortam rotineiramente mais de metade da taxa de alarmes de uma instalação, e não custam nada além de tempo de revisão.

9. O que medir

Não se discute qualidade de alarmes sem números. O conjunto mínimo:

• Média de alarmes por operador, por hora e por dia — o número de saúde principal.
• Taxa de pico numa janela de dez minutos — deteta avalanches que as médias escondem.
• Os dez principais reincidentes — na maioria das instalações, um punhado de tags gera uma grande fatia de todos os alarmes. Corrigir dez deles muda mais a experiência do dia a dia do que qualquer redesenho.
• Contagem e idade dos alarmes permanentes — alarmes ativos há mais tempo do que um turno.
• Distribuição de prioridades — compara com a forma 5 / 15 / 80.
• Contagem de alarmes em shelving e cumprimento dos prazos.

10. Uma checklist que podes aplicar esta semana

1. Exporta a lista de alarmes. Conta-a. Calcula a taxa diária por operador.
2. Para cada alarme, preenche três colunas: consequência, ação do operador, tempo de resposta. Tudo o que tiver a coluna da ação em branco é candidato a eliminação ou a despromoção.
3. Ordena os dez principais reincidentes por contagem e corrige-os com banda morta, atraso à ativação ou supressão baseada no estado.
4. Verifica a distribuição de prioridades. Se o P1 ultrapassar ~10 %, volta a racionalizar.
5. Confirma que cada prioridade tem uma cor distinta e uma pista não cromática distinta no ecrã.
6. Confirma que o piscar significa exatamente uma coisa na tua HMI.
7. Confirma que os alarmes suprimidos e em shelving estão visíveis como tal.
8. Põe um banner em todos os ecrãs, se ainda não houver um.

Perguntas frequentes

A ISA-18.2 é o mesmo que a IEC 62682?

Na prática, sim — a IEC 62682 é a adoção internacional da ANSI/ISA-18.2, por isso uma instalação que se certifique por qualquer uma delas está a trabalhar a partir do mesmo ciclo de vida. A EEMUA 191 é um guia distinto, mais antigo e mais prescritivo, muito usado pelos seus critérios de desempenho.

Quantas prioridades devemos ter?

Três ou quatro. Três (crítico / alto / baixo) chega para a maioria das instalações e é mais fácil de atribuir de forma consistente. Acima de quatro, as fronteiras deixam de ser defensáveis, o que empurra tudo para o topo.

Os alarmes devem ser audíveis?

Sim para os P1 e normalmente para os P2, com som distinto por prioridade e silenciáveis de forma independente do reconhecimento. Um sinal sonoro que não se pode silenciar sem reconhecer ensina os operadores a reconhecer às cegas.

Onde é que isto deixa o designer de HMI se a instalação não tiver filosofia de alarmes?

Escreve as duas páginas que importam: as definições de prioridade com os respetivos tempos de resposta, e o mapeamento cor/forma. Fá-las assinar. Não é um documento de filosofia completo, mas torna o teu ecrã defensável e costuma ser a semente de que a instalação precisava.