Confiabilidade e Manutenção · 5 min de leitura
Uma falha de comunicação entre CLP, remotas, IHMs ou servidores não precisa ser permanente para parar a linha. Basta ser intermitente. E a falha intermitente de rede quase nunca é visível: ela aparece como alarme de equipamento, some quando alguém vai olhar e volta no turno seguinte.
Por que a falha de rede não se mostra
Rede industrial não tem painel de alarme próprio na maioria das plantas. O que a operação vê é a consequência: a remota caiu, o drive perdeu comunicação, a IHM congelou. O chamado é aberto contra o equipamento, o equipamento é reiniciado e volta a funcionar.
Esse ciclo esconde a causa. Um conector com mau contato, uma interface de switch com erro ou um segmento de fieldbus com ruído podem gerar dezenas de eventos antes de alguém ligar os pontos. Cada evento, isolado, parece um defeito diferente.
O troubleshooting de rede começa por inverter a pergunta. Em vez de perguntar o que aconteceu com o equipamento, perguntamos o que aconteceu com a comunicação dele naquele instante.
Essa mudança de pergunta exige dado. Sem registro de quando cada evento aconteceu, em qual dispositivo e em qual ponto da rede, a investigação vira tentativa e erro. Troca-se o cabo, troca-se o cartão de rede, troca-se o switch, e o sintoma volta porque a causa estava em outro lugar.
Como a falha aparece em campo
Os sintomas se repetem entre plantas e setores. Em linhas de envase, um caso típico é a comunicação intermitente entre o CLP da enchedora e as remotas da esteira transportadora: a esteira para, a enchedora acumula e a linha inteira perde ritmo. Nenhum dos dois equipamentos tem defeito.
O traço comum desses casos é a falta de padrão aparente. A falha não acontece sempre no mesmo dispositivo nem no mesmo horário. Quando se cruza o evento com a topologia, porém, o padrão costuma aparecer: todos os dispositivos afetados passam pelo mesmo switch, pelo mesmo segmento ou pela mesma rota de cabo.
Outros padrões recorrentes:
- Equipamentos que caem da rede ou geram erro sem causa aparente, sempre em horários diferentes.
- Queda de desempenho em linha de produção ou envase sem alarme claro associado.
- Barramento de campo com ruído ou mau contato que piora com vibração ou temperatura.
- Pacotes perdidos por cabeamento degradado ou por interface de switch com falha.
O que medimos: camada física e camada lógica
O troubleshooting sério mede as duas camadas. Na física, medimos qualidade de sinal e ruído no meio. Em Ethernet, isso inclui os contadores de erro das portas dos switches (CRC, alinhamento, descartes), que denunciam cabo, conector ou interface degradados. Em fieldbus, a forma de onda no barramento mostra níveis, reflexões e ruído que nenhum software de engenharia mostra.
Na lógica, capturamos tráfego com sniffers e analisadores dedicados. Medimos perda de pacotes, latência, retransmissões, colisões em segmentos legados e a regularidade das trocas cíclicas. Uma conexão de I/O que atrasa ou perde pacotes com frequência crescente é sinal de que alguma coisa entre produtor e consumidor está degradando.
Também mapeamos inconsistências de configuração: endereço duplicado, parâmetros de conexão incoerentes, dispositivos com firmware divergente do projeto, portas de switch com negociação de velocidade e duplex errada. Muitas falhas intermitentes nascem de uma configuração que funciona em condição normal e quebra no pico.
Cada protocolo degrada de um jeito
Validamos a conformidade com as especificações de cada protocolo: EtherNet/IP, PROFINET, ControlNet, DeviceNet, Profibus DP/PA, AS-i e DH+. O método muda porque a forma de falhar muda.
Em EtherNet/IP e PROFINET, o problema costuma estar em tráfego não controlado, multicast sem IGMP snooping, prioridade de camada 2 ignorada por algum switch ou topologia diferente da projetada. Em redes de barramento como DeviceNet e Profibus, o foco é elétrico: terminação, comprimento de segmento e derivações, aterramento da blindagem e níveis de sinal. Em ControlNet, além do sinal, a configuração do agendamento da rede pesa no comportamento sob carga.
Em AS-i e DH+, ainda comuns em plantas com base instalada longa, o diagnóstico passa por fonte, cabo e terminação, e pela coerência entre o que o mestre espera e o que está de fato no barramento. Em todos os casos, o analisador certo para o protocolo certo encurta o caminho até a causa.
Da medição ao laudo com causa
O trabalho é on-site. Coletamos os dados com a planta operando, porque falha intermitente raramente se reproduz com a linha parada. Depois correlacionamos os eventos de rede com os eventos de processo para separar o que é causa do que é consequência.
O isolamento segue lógica de engenharia: dividir a rede em trechos e testar cada um até o defeito ficar confinado. Se a falha acompanha um segmento, o foco vai para o meio físico daquele trecho. Se acompanha um dispositivo em qualquer ponto da rede, o foco vai para o dispositivo ou para a configuração dele. Se aparece só em horário de pico, o foco vai para tráfego e capacidade.
A correlação de tempo é o que fecha o diagnóstico. Quando o erro na porta do switch, a perda de pacotes na captura e o alarme no CLP aparecem no mesmo instante, a relação entre causa e sintoma deixa de ser hipótese e passa a ser evidência.
O entregável é um laudo com a causa identificada e a recomendação de correção. Troca de peça sem causa confirmada pode até fazer o sintoma sumir por alguns dias, mas não fecha o problema.
Quem se beneficia
Supervisores de manutenção e técnicos de automação ganham uma resposta objetiva para a falha que ninguém conseguiu fechar. Engenheiros de infraestrutura em novos projetos usam o troubleshooting para validar a rede antes que o defeito vire rotina.
Consultores e integradores usam o diagnóstico independente para encerrar discussões sobre responsabilidade. Gerentes industriais ganham o dado que faltava para decidir onde investir: na rede, no equipamento ou no processo.
Artigo desenvolvido a partir das publicações de Darwin Anastacio Junior no LinkedIn.