Os painéis de controle podem se autorreparar? Engenharia de sistemas tolerantes a falhas mais inteligentes
Painéis de controle com autorreparo não conseguem reparar fisicamente componentes de hardware com falha, mas diagnósticos modernos, design modular, redundância e inteligência de borda podem detecta...
O que acontece quando um painel de controle industrial detecta uma falha em desenvolvimento antes que o operador reconheça um problema visível?
Um inversor pode começar a consumir corrente de forma irregular. Um módulo de potência pode começar a operar mais quente que o normal. Erros de comunicação podem aparecer de forma intermitente entre dispositivos de controle.
Em um sistema convencional, essas condições muitas vezes só se tornam problemas de manutenção depois que ocorre um alarme, disparo ou desligamento.
Arquiteturas de controle mais inteligentes podem responder mais cedo.
Eles podem detectar condições anormais, isolar determinadas falhas, transferir funções para equipamentos redundantes e fornecer à equipe de manutenção informações detalhadas de diagnóstico.
Esse conceito às vezes é descrito como um painel de controle autorregenerável.
O termo não deve ser interpretado literalmente. Um painel de controle não pode reparar sozinho um contator danificado, um terminal queimado ou um inversor com defeito.
O que ele pode fazer é reconhecer determinadas falhas e usar estratégias de recuperação predefinidas para limitar seu efeito na produção.
Figura 1. Painéis de controle industriais modulares fornecem a base para diagnósticos, isolamento e substituição estruturada de componentes.
O ponto fraco muitas vezes não é a máquina
Os painéis de controle coordenam grande parte dos equipamentos industriais modernos.
PLCs, fontes de alimentação, relés, inversores, módulos de comunicação e dispositivos de E/S trabalham juntos para manter uma sequência operacional previsível.
Uma falha em um pequeno componente pode, portanto, afetar um processo muito maior.
Um relé danificado pode impedir a partida de um motor. Uma fonte de alimentação com defeito pode desativar vários circuitos de controle simultaneamente. Um problema de comunicação pode tornar equipamentos que, de outra forma, estariam funcionando indisponíveis para o controlador.
As estratégias tradicionais de manutenção lidam com esses riscos por meio de inspeções, peças sobressalentes, substituição preventiva e intervenção do operador.
Essas práticas continuam sendo necessárias.
A limitação é o tempo de resposta.
Quando a detecção de falhas depende principalmente da parada de uma máquina ou de um operador que vê um alarme, o processo já entrou em um estado operacional anormal.
O projeto de sistemas de controle modernos tenta cada vez mais detectar a deterioração antes desse ponto.
O que a autorrecuperação realmente significa
Em termos de engenharia, a autorrecuperação é mais bem compreendida como uma combinação de detecção de falhas, isolamento de falhas e recuperação automatizada.
Uma arquitetura prática pode executar várias funções.
Primeiro, o sistema detecta um sinal ou condição operacional anormal.
Em segundo lugar, a lógica de diagnóstico determina qual dispositivo, circuito ou área do processo foi afetado.
Em terceiro lugar, o sistema isola a função afetada quando a arquitetura permite isso.
Por fim, um hardware redundante ou uma rota de controle alternativa pode manter parte do processo até que a manutenção possa intervir.
O operador ainda recebe alarmes, registros e informações de diagnóstico.
O objetivo não é eliminar as falhas. É impedir que cada falha individual se transforme automaticamente em uma interrupção de toda a planta.
A arquitetura modular torna prático o isolamento de falhas
O comportamento tolerante a falhas começa no projeto físico.
Um painel construído como um único conjunto elétrico firmemente interconectado é difícil de isolar quando um componente falha.
Uma arquitetura modular cria limites funcionais mais claros.
A distribuição de energia, o controle, a comunicação, os acionamentos e as E/S podem ser divididos em seções identificáveis, com proteção adequada e acesso a diagnósticos.
Isso oferece várias vantagens operacionais.
Muitas vezes, uma falha pode ser associada a uma área funcional menor. A equipe de manutenção pode identificar o hardware afetado mais rapidamente, e a substituição se torna mais estruturada.
A modularidade também dá suporte a estratégias padronizadas de peças sobressalentes.
Em vez de diagnosticar cada componente até o nível da placa, os técnicos podem substituir módulos definidos e restaurar o serviço de acordo com um procedimento de manutenção estabelecido.
O hardware com troca a quente pode aprimorar essa abordagem quando a plataforma de controle específica e a aplicação oferecem suporte à substituição sob tensão.
No entanto, nunca se deve presumir que a troca a quente seja possível simplesmente porque um sistema é modular.
O controlador, a plataforma de E/S, o projeto elétrico e o procedimento de segurança devem oferecer suporte explícito a isso.
Para sistemas desenvolvidos em torno de hardware de controle substituível, módulos de E/S claramente categorizados também podem simplificar a manutenção do ciclo de vida e o planejamento de peças sobressalentes.
O monitoramento preditivo busca mudanças antes da falha
Uma estratégia de controle autogerenciada precisa de informações sobre a condição do equipamento.
É nesse ponto que o sensoriamento de IIoT e a manutenção preditiva se tornam importantes.
Os sistemas modernos de monitoramento podem observar carga elétrica, temperatura, vibração, qualidade da comunicação e outras variáveis operacionais.
Uma única medição pode não indicar um problema.
A tendência costuma ser mais útil.
Uma conexão de terminal cuja temperatura aumenta gradualmente pode indicar uma condição elétrica que requer inspeção.
Um motor que apresenta uma tendência crescente de vibração pode precisar de atenção mecânica antes que a condição resulte em uma parada não planejada.
O desequilíbrio recorrente de corrente também pode fornecer evidências diagnósticas úteis quando avaliado no contexto elétrico e mecânico correto.
A computação de borda permite que parte dessa análise ocorra perto da máquina.
Em vez de transmitir todas as medições brutas para um servidor remoto, um dispositivo de borda pode avaliar sinais selecionados localmente e gerar eventos quando condições definidas forem detectadas.
Isso pode reduzir a latência de resposta e limitar o tráfego de dados desnecessário.
Os diagnósticos devem explicar mais do que “falha”
Um indicador geral de falha oferece valor limitado quando a produção já foi interrompida.
Diagnósticos eficazes devem identificar onde o problema ocorreu e fornecer contexto suficiente para que a equipe de manutenção possa investigá-lo.
Controladores modernos e dispositivos inteligentes podem disponibilizar informações de diagnóstico no nível dos componentes por meio da rede de controle.
A camada de IHM ou SCADA pode então apresentar informações de alarme mais específicas.
Em vez de relatar apenas uma falha genérica do acionamento, o sistema pode identificar qual acionamento gerou o alarme e registrar os valores operacionais relacionados.
Os eventos históricos também ajudam os engenheiros a determinar o que ocorreu imediatamente antes do disparo.
Isso se torna especialmente importante quando uma falha inicial produz vários alarmes secundários.
O primeiro alarme visível na tela pode não ser a causa raiz.
Sequências de eventos com marcação de tempo correta ajudam os engenheiros a reconstruir o que aconteceu.
O isolamento de falhas impede que um problema se espalhe
A detecção, por si só, não cria tolerância a falhas.
A arquitetura também deve definir o que acontece depois que uma falha é reconhecida.
Em algumas aplicações, o módulo afetado pode ser removido logicamente da sequência operacional.
Em outros casos, o processo pode ser transferido para equipamentos redundantes.
Fontes de alimentação, caminhos de rede, controladores, interfaces de comunicação e equipamentos de processo podem utilizar redundância quando a aplicação justificar a complexidade adicional.
A redundância não é automaticamente benéfica.
Um sistema redundante mal projetado pode introduzir modos de falha adicionais e dificultar a investigação de problemas.
Portanto, a estratégia de recuperação precisa ser projetada em conjunto com a estratégia de detecção de falhas.
Figura 2. Uma sequência tolerante a falhas detecta a condição anormal, isola a função afetada e transfere a operação quando há redundância disponível.
Uma falha no acionamento mostra como o conceito funciona
Considere uma linha de engarrafamento que utiliza acionamentos de frequência variável para regular a velocidade do transportador.
Um acionamento começa a apresentar comportamento irregular da corrente e aumento da temperatura.
Em uma arquitetura convencional, o acionamento pode continuar funcionando até que suas funções de proteção gerem um disparo.
O transportador para.
A manutenção então começa a investigar a seção com falha enquanto a produção permanece interrompida.
Uma arquitetura mais tolerante a falhas poderia responder de forma diferente.
O monitoramento de condições detecta primeiro o padrão elétrico e térmico anormal.
O sistema de controle gera um aviso de manutenção antes que o processo atinja a condição de disparo.
Se a aplicação incluir um acionamento de reserva projetado ou um caminho mecânico redundante, a função afetada poderá então ser transferida de acordo com uma lógica predefinida.
O acionamento original é isolado, e a manutenção recebe informações detalhadas sobre a falha.
A produção pode continuar em capacidade total ou reduzida, dependendo do projeto do processo.
Este exemplo ilustra uma limitação importante.
O sistema de controle não pode criar redundância que nunca foi projetada na máquina.
A recuperação automatizada só é possível quando a arquitetura elétrica, mecânica e de software fornece um caminho alternativo.
Quando há controle de velocidade variável envolvido, arquiteturas apropriadas de inversores de frequência e acionamentos CA podem fazer parte de uma estratégia mais ampla de manutenção e redundância.
A comunicação faz parte da arquitetura de recuperação
Os diagnósticos modernos dependem muito das redes de comunicação industriais.
Os controladores precisam de informações de status de acionamentos, E/S remotas, dispositivos de proteção e outros componentes inteligentes.
EtherNet/IP, PROFINET e outros protocolos industriais podem fornecer essa visibilidade de diagnóstico quando há suporte do equipamento.
No entanto, usar um protocolo Ethernet industrial não torna automaticamente uma rede tolerante a falhas.
A resiliência depende da arquitetura da rede.
Switches gerenciáveis, caminhos redundantes, recursos dos controladores, topologia e mecanismos de recuperação influenciam o que acontece após uma falha de comunicação.
Portanto, os engenheiros devem separar duas questões.
O dispositivo pode relatar a falha?
A rede pode continuar operando após a falha?
Essas são capacidades relacionadas, mas tecnicamente diferentes.
Segurança e recuperação automática precisam de limites claros
A recuperação automática nunca deve substituir a função de segurança de uma máquina ou processo.
Algumas falhas devem resultar em uma parada controlada, em vez de uma continuidade automática.
Um desligamento de emergência, um intertravamento de segurança ou uma condição elétrica perigosa não pode simplesmente ser ignorado porque manter a produção é desejável.
A lógica de recuperação deve distinguir entre falhas que permitem a continuidade da operação e falhas que exigem que o equipamento entre em um estado seguro.
Isso é especialmente importante quando há caminhos de controle redundantes envolvidos.
Os engenheiros precisam saber quais sinais pertencem à automação padrão e quais pertencem à arquitetura relacionada à segurança.
Portanto, um conceito de autorrecuperação funciona melhor quando a contenção de falhas é projetada em torno de zonas funcionais e de segurança definidas.
Gêmeos digitais adicionam uma camada de testes
Os gêmeos digitais podem ampliar o projeto tolerante a falhas para além do painel físico.
Uma representação virtual do sistema de controle permite que os engenheiros estudem as sequências de operação antes de implementar alterações em equipamentos em operação.
Condições de falha podem ser introduzidas no modelo para examinar como a lógica de controle responde.
Os engenheiros podem avaliar se os alarmes corretos aparecem, se a redundância é transferida corretamente e se ocorrem interações não intencionais no processo.
Isso é particularmente útil quando a lógica de recuperação se torna complexa.
Testar todas as possíveis falhas em equipamentos de produção em operação pode ser impraticável ou inseguro.
Um ambiente de simulação oferece outra forma de validar o comportamento antes da implementação.
\Figura 3.\ A simulação digital pode ajudar os engenheiros a avaliar sequências de falhas e lógicas de recuperação antes que as alterações cheguem aos equipamentos em operação.
A inteligência de edge está ampliando a tomada de decisões locais
Outro desenvolvimento é a quantidade crescente de processamento disponível diretamente na máquina.
As arquiteturas de controle tradicionais geralmente enviam tarefas analíticas de nível superior para servidores centralizados.
As plataformas de edge permitem que determinados diagnósticos permaneçam locais.
Isso pode ser útil para aplicações em que as decisões sobre falhas precisam ocorrer rapidamente ou em que não se pode presumir uma conectividade contínua com a nuvem.
As análises locais podem identificar padrões anormais e enviar apenas eventos relevantes para sistemas supervisórios ou corporativos.
O PLC ainda executa o controle determinístico.
A camada analítica fornece informações adicionais que podem influenciar decisões de manutenção ou a lógica de recuperação predefinida.
É importante manter essas funções claramente separadas.
O controle da máquina não deve se tornar dependente de um modelo analítico opaco cujo comportamento não possa ser validado.
Perguntas que os engenheiros devem fazer durante o projeto do painel
Um painel tolerante a falhas começa com questões de projeto, e não com um recurso de software.
Os engenheiros devem determinar se as zonas de falha individuais estão claramente definidas dentro da arquitetura elétrica.
Eles devem identificar quais falhas podem ser isoladas sem desligar a máquina completa.
Os dispositivos devem fornecer feedback de diagnóstico suficiente para a estratégia de manutenção.
As funções críticas devem ser avaliadas para determinar se a redundância é tecnicamente e economicamente justificável.
A equipe de projeto também deve decidir quais variáveis de condição precisam de monitoramento contínuo além das simples horas de operação.
O diagnóstico remoto pode ser útil, mas a segurança da rede e a autoridade operacional devem ser consideradas desde o início.
A lógica de recuperação também deve ser testada com cenários de falha realistas, e não apenas com sequências normais de operação.
O objetivo é a degradação controlada, não um painel indestrutível
Os equipamentos industriais continuarão a falhar.
Os componentes envelhecem. As conexões se deterioram. As redes perdem comunicação. Os inversores desarmam. As fontes de alimentação chegam ao fim de sua vida útil.
Portanto, o objetivo de engenharia não é um painel de controle impossível que nunca falha.
Um objetivo melhor é a degradação gradual.
O sistema deve identificar a deterioração o quanto antes, quando possível.
Quando ocorre uma falha, seu efeito deve permanecer contido sempre que a arquitetura permitir.
Os operadores devem receber informações úteis de diagnóstico, em vez de alarmes genéricos.
Os processos críticos devem ser transferidos para funções de backup projetadas quando apropriado.
A equipe de manutenção deve então ter informações suficientes para reparar o hardware afetado sem investigação desnecessária.
Esse é o significado prático de um painel de controle autocicatrizante.
Ele não se conserta sozinho.
Ele foi projetado para compreender melhor sua própria condição, reagir de forma inteligente a falhas previsíveis e preservar o máximo possível de operação segura até que as pessoas possam concluir o reparo físico.