Confiabilidade e Manutenção · 6 min de leitura
Um switch gerenciado de porte médio expõe milhares de contadores. Multiplique por trinta switches, some os contadores de protocolo, e a planta tem mais dado de rede do que qualquer equipe consegue ler. Coletar esse dado deixou de ser o problema há muito tempo; o problema é saber o que ele significa.
Coletar é o primeiro dia
Os contadores estão lá: erros de CRC, colisões tardias, frames descartados, ocupação de fila, temperatura, estado de porta, reconfigurações de anel. Em cima disso vêm os contadores de protocolo, do PROFINET, do EtherNet/IP, dos gateways para redes de campo. O SNMP existe há décadas e qualquer ferramenta de mercado sabe consultá-lo.
Por isso a discussão sobre visibilidade de rede industrial costuma parar no lugar errado. Montar a coleta é trabalho de dias. O que vem depois, transformar milhares de séries numéricas em uma decisão de manutenção, é trabalho de meses, e é onde a maioria das iniciativas trava.
A frase que uso para resumir isso é curta: coletar é o primeiro dia, entender é o primeiro ano. Em 20 anos de campo, vi muito mais projetos de visibilidade morrerem na interpretação do que na coleta.
Nenhum número significa algo sozinho
Pegue um valor concreto: 200 retransmissões por hora em um enlace. Isso é bom ou ruim? Pode ser o comportamento normal daquele trecho, ou pode ser o início de uma falha. A resposta depende do enlace, do que está conectado nele, do que a linha está produzindo e até do dia da semana.
Uma terça-feira com três linhas rodando não se parece com um domingo à noite. Um trecho de I/O remoto tem um perfil de tráfego diferente de um trecho de drives. Uma célula nova que entra em operação muda o que é normal para os switches que a atendem, e esse novo normal passa a valer a partir daquele dia.
O mesmo contador, com o mesmo valor, pode ser irrelevante em um ponto da planta e urgente em outro. Quem lê o número sem o contexto está adivinhando.
Por isso uma leitura de contadores sem histórico raramente fecha diagnóstico. Ela mostra que existe erro, mas não mostra se o erro é novo, se está crescendo ou se sempre esteve ali. Essas três situações pedem ações completamente diferentes da manutenção.
Por que o alarme de limiar fixo falha sempre do mesmo jeito
A resposta mais comum a esse problema é o limiar fixo: acima de X erros por hora, alarma. Ele falha de duas formas, sempre as mesmas. Se o limiar é frouxo, nunca dispara, e a degradação passa despercebida até virar parada. Se é apertado, dispara tanto que alguém o desativa em duas semanas.
É a mesma doença que a gestão de alarmes conhece bem no processo. Um alarme que dispara sem consequência ensina o operador a ignorá-lo, e o dia em que ele está certo passa como mais um falso. Na rede, o efeito é o mesmo: a equipe perde a confiança no indicador e volta a trabalhar no escuro.
O limiar fixo trata todos os enlaces como se fossem iguais. Eles não são, e a planta não é a mesma de segunda a domingo.
Anomalia se define contra um normal, e o normal é da planta
A alternativa é definir anomalia como desvio de um comportamento conhecido. Qualquer engenheiro de confiabilidade já faz isso com motores: a curva de vibração de um motor específico é a referência para ele, e não um número de catálogo. A rede pede a mesma abordagem, enlace por enlace, em condições de produção.
Essa referência é a linha de base. Ela registra como cada trecho se comporta em carga real, por faixa de horário e por regime de operação. A partir dela, a pergunta deixa de ser "o número está alto?" e passa a ser "o número mudou em relação ao que este enlace costuma fazer?".
Na prática, construir uma linha de base útil envolve alguns cuidados mínimos. Sem eles, a referência nasce distorcida e todas as comparações seguintes herdam o erro.
- Medir em produção plena, e não em janela de manutenção com equipamentos desligados.
- Separar por segmento: I/O remoto, drives, supervisório e backbone têm perfis diferentes.
- Registrar o contexto junto com o número: linhas ativas, turno, mudanças recentes.
- Refazer a referência quando a planta muda, como na entrada de uma célula nova.
O mesmo princípio vale para segurança de OT
Em 19 de agosto de 2026, NSA, CISA, FBI, DOE e EPA publicaram um alerta conjunto sobre ataques a controladores Siemens S7. Uma das recomendações é observar escritas em blocos de dados que aconteçam fora das janelas de mudança programadas. Isso não é detecção por assinatura. É critério de desvio do normal.
Para aplicar essa recomendação, a planta precisa saber quando as mudanças legítimas acontecem e como é o tráfego de engenharia em dia comum. Sem essa linha de base, uma escrita fora de hora é indistinguível de uma escrita qualquer. Sem linha de base, não existe detecção, seja de falha, seja de ataque.
Há um ganho adicional nessa convergência. A mesma linha de base que ajuda a manutenção a separar degradação de comportamento normal ajuda a segurança a separar mudança autorizada de mudança suspeita. Um trabalho de medição bem feito atende as duas frentes, e a planta não precisa construir duas referências diferentes para a mesma rede.
O que muda para a gestão
Para quem decide investimento, a lição é deslocar a pergunta. Antes de perguntar quantos contadores a ferramenta coleta, pergunte como ela sabe o que é normal para cada enlace da sua planta e quanto tempo leva para aprender isso. Coleta sem interpretação é armazenamento, e armazenamento não evita parada.
O primeiro passo concreto é ter uma linha de base medida em produção, documentada por segmento, que sirva de referência para as leituras seguintes. É ela que transforma o dado que já existe nos switches em informação para a manutenção e para a segurança.
Também vale rever o que se espera da equipe interna. Ninguém interpreta contadores de trinta switches de cabeça, e ninguém deveria precisar. O papel da equipe é saber quais enlaces são críticos para a produção, registrar as mudanças que alteram o normal e tratar o desvio como hipótese a investigar, e não como ruído a silenciar.
Artigo desenvolvido a partir das publicações de Darwin Anastacio Junior no LinkedIn.