PLC do Rascunho ao Software - 34

Depois que entendemos um pouco da norma ISA18.2 "Management of Alarm System for the Process Industries", temos que entender que em um primeiro momento ela foi pensada para processos contínuos o que não é o caso do nosso Magazine de Paletes, que é o nosso objeto de estudos dessa série, porém baseado nessa norma, foi feito um relatório técnico (TR - Technical Report), para orientar e adaptar essa filosofia para sistemas de batelada e discretos (caso do nosso Magazine), esse relatório técnico chama-se : ISA-TR18.2.6-2012 – Alarm Systems for Batch and Discrete Processes. Esse relatório técnico vai adaptar não somente a filosofia de alarmes, mas monitoramento e gestão dos alarmes para esses processos.

Como já vimos sistemas de alarmes, informam, alertam e guiam operadores sobre funcionamentos anormais, e que esses sistemas de alarmes também incluem mecanismos de comunicação com operador através de Interfaces Homem-Máquina (IHM), ou painéis de anúncio por exemplo, esses sistemas também irão conter um histórico de alarmes, que registram alarmes ativos, e alarmes já reconhecidos.

🏭 Processos Contínuos vs. Batch e Discretos

Processos Contínuos: Caracterizam-se por operações ininterruptas, onde as variáveis de processo permanecem relativamente estáveis ao longo do tempo.
Processos Batch e Discretos: Apresentam operações em etapas ou ciclos, com transições frequentes entre diferentes estados operacionais.

Essa natureza cíclica dos processos batch e discretos implica que os alarmes devem ser sensíveis ao contexto operacional, ativando-se apenas quando relevantes para a fase ou etapa específica do processo.

Importância do Contexto Operacional

Em processos batch e discretos, um alarme pode ser apropriado em uma fase e irrelevante ou enganoso em outra. Por exemplo:

Um alarme de "válvula aberta" pode ser crítico durante a fase de enchimento, mas desnecessário durante a fase de mistura.

Portanto, analisar os estados do processo, é fundamental para programar as lógicas que irão ativar e desativar os alarmes do sistema, evitando falsos alarmes ou mesmo a ausência de alarmes.

Integração com Modelos de Controle

A norma sugere a integração do sistema de alarmes com modelos de controle, como o ISA-88, que estrutura os processos em unidades, módulos de equipamento e fases. Essa integração permite uma gestão de alarmes mais eficaz, alinhada com a lógica operacional do processo.

Cálculo e Registro de Tempo

Alguns conceitos são importantes, para registrar corretamente os alarmes, como:

Tempo de Ativação: Momento em que o alarme foi acionado.
Tempo de Reconhecimento: Momento em que o operador reconheceu o alarme.
Tempo de Retorno ao Normal: Momento em que a condição que causou o alarme foi resolvida.

A coleta e análise desses dados permitem:

Avaliação da Resposta Operacional: Identificar a rapidez e eficácia com que os operadores respondem aos alarmes.
Identificação de Tendências: Detectar padrões recorrentes que possam indicar falhas sistêmicas ou necessidades de treinamento adicional.
Melhoria Contínua: Implementar ações corretivas e preventivas baseadas em dados objetivos, aprimorando continuamente o sistema de alarmes.

Gerenciamento de Alarmes (Alarm Management)

A ISA-TR18.2.6-2012 aborda as práticas fundamentais para o gerenciamento eficaz de alarmes, afinal um sistema de alarmes mal gerenciado pode comprometer tanto a segurança operacional quanto a eficiência da planta.

Em processos batch e discretos, o desafio do gerenciamento de alarmes é ainda mais complexo, pois os alarmes precisam estar contextualizados de acordo com as diferentes fases ou estados operacionais. Alarmes ativados fora de contexto podem causar fadiga do operador, dificultar diagnósticos e reduzir a confiança no sistema.

A norma recomenda as seguintes práticas essenciais:

Priorização de Alarmes

A classificação de alarmes por criticidade garante que situações mais graves recebam atenção imediata, enquanto condições de menor impacto operacional possam ter prioridade reduzida.

Alarmes críticos: exigem ação imediata para proteger pessoas, meio ambiente ou equipamento.
Alarmes de prioridade média: precisam de resposta oportuna, mas sem risco imediato.
Alarmes de baixa prioridade: podem ser monitorados sem ação imediata.

Sem priorização adequada, o operador pode se perder em um volume excessivo de alarmes simultâneos, perdendo alertas realmente críticos.

Racionalização de Alarmes

A racionalização consiste em revisar cada alarme configurado no sistema para confirmar:

Necessidade real do alarme
Relevância operacional (é útil na tomada de decisão?)
Evitar redundâncias (mesma condição sinalizada por múltiplos alarmes)

O objetivo é eliminar alarmes que são desnecessários, diminuindo assim o número de alarmes.

A racionalização deve seguir uma metodologia estruturada, envolvendo equipe multidisciplinar (automação, operação, engenharia de processo, segurança).

🔹 Documentação e Procedimentos

Manter documentação atualizada e acessível é um pilar do gerenciamento de alarmes. A norma recomenda:

Registros de filosofia de alarmes (políticas e diretrizes para configuração)
Lista mestre de alarmes contendo:
- Descrição
- Criticidade
- Estado/fase relevante
- Ação esperada do operador
Procedimentos operacionais que definam respostas padrão a cada alarme

A documentação fortalece o treinamento de operadores, padroniza ações e facilita auditorias e revisões futuras.

🔹 Revisões Periódicas

O sistema de alarmes não é estático: deve ser reavaliado periodicamente para refletir mudanças no processo, equipamentos ou operações.

As revisões periódicas envolvem:

Analisar métricas de performance de alarmes (ex.: número de alarmes por hora, alarmes chattering, alarmes suprimidos)
Revisar alarmes não reconhecidos ou ignorados
Ajustar parâmetros, prioridades ou suprimir alarmes que perderam relevância

Essas revisões garantem a manutenção da eficácia do sistema ao longo do tempo, prevenindo degradação da qualidade do gerenciamento de alarmes.

Então basicamente, podemos interpretar que essa TR vai apenas resumir nossos alarmes, de uma forma mais simples quando tratar de uma automação discreta, por exemplo, em um processo seja ele de batelada ou contínuo, uma variável analógica vai ter alarmes de diversos níveis baixos e altos, em diferentes categorias, já para um sistema discreto que são basicamente sinais digitais, teremos apenas a falha conforme o feedback.

Vamos pensar na válvula e nos cilindros dos garfos dos magazines, eu tenho uma saída e espero um retorno, que deve acontecer dentro de X tempo aceitável, o retorno esperado é a movimentação do cilindro até o sensor da posição atuada, e não haverá diferentes níveis de alarmes apenas um, e todos os alarmes referentes ao cilindro serão únicos (racionalização).

Vamos então ao exemplo:

Válvula na posição de avanço quais os alarmes possíveis?

1 - Sensor de avanço não atuou após x segundos - falha de avanço do cilindro

Existe um outro alarme possível, mas que podemos considerar auto excludente - sensor de recuo continua acionado

Válvula na posição de recuo quais os alarmes possíveis?

1 - Sensor de recuo não atuou após x segundos - falha de recuo do cilindro

Existe um outro alarme possível, mas que podemos considerar auto excludente - sensor de avanço continua acionado

E mais alarme possível a ser considerado:

Ambos sensores ligados ao mesmo tempo, o que indica um problema um outro problema no qual não é possível determinar a posição física do cilindro

Então para cada cilindro temos 3 possíveis alarmes, esses alarmes trazem risco imediato a segurança, uma vez que a movimentação do magazine com essas falhas pode causar riscos como derrubar paletes ou colisão, assim são alarmes de prioridade Alta.

Podemos ver a nossa tabela de prioridade:

Prioridade	Impacto	Tempo de Resposta
Alta	Risco imediato à segurança, ambiente ou parada catastrófica	Minutos
Média	Impacto na produção, qualidade ou equipamentos	Horas
Baixa	Manutenção preventiva ou eventos informativos	Dias

Agora é necessário definir uma classe para os nossos alarmes

Classe	Responsável
Classe A	Operador de Campo
Classe B	Operador de Controle
Classe C	Engenharia / Manutenção

Conforme a tabela acima, idealmente será classe C (mesmo que em alguns lugares a realidade é que o operador tente resolver o problema e seja tratado como classe A)

E agora temos que definir seu tipo, nesse caso em especifico eu classificaria como Segurança, pelo simples fato do risco de um palete cair do magazine), não aplicaria o tipo Segurança por exemplo na falha de sobre carga do motor onde iria afetar somente o processo e não a segurança

Tipo	Descrição	Ação Típica
Segurança	Risco a Vida, ambiente ou Ativo	Evacuar área, desligar equipamento
Operacional	Impacta na Eficiência ou Qualidade do Processo	Ajuste de parâmetros, ou manutenção pouco invasiva
Diagnóstico	Indica Falhas em Instrumentos ou Equipamentos	Manutenção corretiva
Informativo	Dados para registro (sem ação imediata)	nenhuma apenas registro

Importante:

Alarmes informativos não devem competir com alarmes críticos (podem ser convertidos em "eventos"), ou apenas mensagens ou indicadores de status.

Assim vamos ver como ficou nosso alarme de cilindro?

Alarme	Prioridade	Classe	Tipo
Falha de Avanço de Cilindro	Alto	Classe C	Segurança

No próximo artigo vamos ver as lógicas de falhas no CLP para finalizar a nossa série no escopo do software do CLP e iniciar nossas conversas sobre IHM.

Até o próximo artigo,