Confiabilidade e Manutenção · 6 min de leitura
Antes de um incidente grave, a rede industrial costuma dar três sinais. Nenhum deles parece um problema de rede: parecem problemas de IHM, de CLP ou de equipamento de campo. Todos podem ser mapeados em cerca de 30 minutos com a instrumentação correta, e a maioria das plantas não tem nem o instrumento nem a rotina de medição.
Sintoma 1: lentidão intermitente na IHM em horário de pico
A queixa chega como "hoje tá lento". A tela demora a atualizar, os comandos respondem com atraso e, algumas horas depois, tudo volta ao normal. A primeira suspeita recai sobre a IHM, o computador ou o software de supervisão.
Raramente é a IHM. O que costumamos encontrar é um switch operando acima de 70% de utilização no horário de pico, combinado com o Spanning Tree recalculando a topologia sem que ninguém perceba. Cada convergência interrompe o tráfego por alguns segundos enquanto as portas passam pelos estados de transição e as tabelas são reaprendidas.
Um recálculo isolado passa despercebido. Quarenta recálculos por dia, somados a um switch já carregado, são exatamente a experiência que o operador descreve como lentidão. A IHM está apenas mostrando o que a rede entrega.
O detalhe importante é que nada disso gera alarme. O switch não está fora do ar, as portas continuam up e o supervisório não registra falha de comunicação. Sem a leitura dos contadores de utilização e das mudanças de topologia, a lentidão fica sem explicação e acaba aceita como característica da planta.
Sintoma 2: célula ou CLP que trava e resolve sozinho
O segundo sintoma é o travamento recorrente de uma célula ou de um CLP. A comunicação cai, alguém faz um reset e tudo volta. Como o problema "resolve sozinho", ele raramente é investigado a fundo, e o reset vira parte da rotina do turno.
Por trás do mesmo sintoma externo, há pelo menos três causas técnicas diferentes. Cada uma exige uma medição diferente para ser confirmada, e trocar o CLP não resolve nenhuma delas.
IGMP snooping é o recurso que permite ao switch entregar multicast apenas às portas interessadas. Desabilitado, ele faz o multicast do EtherNet/IP se comportar como broadcast e chegar a todos os dispositivos. Já o limite de conexões CIP do scanner é um teto rígido: quando a expansão adiciona dispositivos sem que alguém revise essa conta, o scanner satura.
O ponto comum entre as três causas é que nenhuma delas aparece em uma verificação de estado. O CLP responde, o scanner está online, o link está up. Só a leitura de contadores, da configuração dos switches e do número de conexões ativas mostra onde o problema está.
- Erros de CRC acumulando em um trecho de fibra degradada.
- IGMP snooping desabilitado, transformando multicast em broadcast.
- Conexões CIP saturando um scanner que não foi redimensionado na expansão.
Sintoma 3: reset recorrente de equipamento de campo
O terceiro sintoma aparece nos equipamentos de campo: drives, I/O remotos e instrumentos que reiniciam sem explicação. A suspeita natural é de falha de hardware, e é comum ver o mesmo equipamento trocado mais de uma vez sem que o problema desapareça.
Duas causas de rede aparecem com frequência. A primeira é um link óptico com power budget fora de especificação: o sinal chega, mas com margem insuficiente, e pequenas variações bastam para derrubar o enlace. A segunda é um segmento sujeito a loop sem broadcast storm control configurado, em que um evento de loop inunda a rede e os dispositivos mais sensíveis perdem a comunicação.
Nos dois casos, o equipamento de campo é a vítima, não a causa. Trocá-lo alivia o sintoma por um tempo e mantém a causa ativa.
Esse sintoma costuma ser o mais caro dos três em peças. Placas, fontes e até equipamentos inteiros são substituídos em sequência, cada troca aliviando o problema por alguns dias. Uma medição de potência óptica ou a verificação da configuração de storm control teria encerrado a investigação muito antes.
Monitorar não é diagnosticar
Muitas plantas acreditam que já cuidam desses sintomas porque têm monitoramento. Mas monitorar, na forma mais comum, é ver verde no painel: o ping responde, a porta está up. Esse tipo de verificação diz se a rede está no ar, e nada sobre a saúde dela.
Diagnosticar é outra coisa. É ler CRC, retransmissões, jitter, duplex mismatch, perda óptica em dB e NEXT, e acompanhar esses valores ao longo do tempo. Uma rede pode estar 100% no ar e doente ao mesmo tempo, e só o diagnóstico mostra a diferença.
Uma especialista em saneamento resumiu isso num comentário: redes distribuídas precisam ser lidas, não apenas monitoradas. A diferença prática cabe numa frase. Monitoramento avisa quando já parou; diagnóstico avisa antes.
Como mapear os três sintomas em 30 minutos
Com a instrumentação correta, os três sintomas podem ser mapeados em cerca de 30 minutos por segmento. O ponto é saber onde olhar e ter um instrumento que mostre o valor, e não apenas o estado verde ou vermelho. A sequência abaixo cobre o essencial.
O difícil não é a medição em si. É ter o instrumento disponível e uma rotina que garanta que a medição aconteça antes da próxima parada, e não depois dela.
- Utilização por porta e por switch no horário de pico, não em janela de manutenção.
- Contagem de mudanças de topologia do Spanning Tree nas últimas 24 horas.
- Erros de CRC por enlace, com atenção especial aos trechos de fibra.
- Estado do IGMP snooping e do broadcast storm control em cada switch.
- Número de conexões CIP ativas comparado com a capacidade do scanner.
- Potência óptica recebida comparada com o budget de cada link.
O que muda para a gestão
Para a gestão, esses três sintomas são uma oportunidade. Eles aparecem antes do incidente grave, e são tratados como incômodo de rotina. Cada reset que resolve sozinho é um aviso gratuito de que algo está degradando.
A decisão que muda o jogo é incluir a rede na rotina de manutenção, com instrumento e com uma medição periódica que registre valores. É a diferença entre descobrir o problema pelo operador reclamando da tela e descobri-lo pelo contador subindo semanas antes.
Artigo desenvolvido a partir das publicações de Darwin Anastacio Junior no LinkedIn.