Auditoria e Certificação · 6 min de leitura
Uma cervejaria de médio-grande porte no interior de São Paulo estava a duas semanas do startup de uma expansão de linha. Os painéis Rockwell tinham sido entregues por um integrador Gold Partner, testados e aprovados. Entramos 15 dias antes da data para certificar cabos, mapear a topologia real e auditar a rede em bancada, e encontramos três defeitos que teriam parado a linha em momentos diferentes.
O cenário: painéis aprovados e cronograma apertado
O cenário é comum em expansão de planta. O integrador entrega os painéis, faz os testes de funcionamento previstos no contrato, a comunicação sobe e o cronograma segue. Ninguém fez nada errado do ponto de vista do processo de entrega. O problema é que "comunicou" e "está dentro de norma" são afirmações diferentes, e só a segunda diz alguma coisa sobre o comportamento da rede em produção.
O escopo que executamos teve três frentes. Primeiro, certificação dos cabos de cobre e fibra com instrumento, parâmetro por parâmetro. Segundo, mapeamento da topologia como ela existe fisicamente, e não como está no desenho. Terceiro, auditoria da configuração dos switches e do comportamento da rede em bancada de comissionamento, antes de a linha ser energizada.
Os três achados que descrevo abaixo têm uma característica em comum: nenhum deles impedia a rede de funcionar no dia do teste. Cada um tinha um gatilho diferente, e cada gatilho ia aparecer em um momento diferente da vida da linha.
Achado 1: quatro lances Cat6 crimpados em T568A
A planta inteira usa o padrão T568B de terminação. Quatro lances Cat6 da expansão estavam crimpados em T568A. Os cabos passaram no teste do integrador, que verifica continuidade e mapa de fios. No Fluke DSX, os mesmos quatro lances reprovaram no critério NEXT.
NEXT (Near-End Crosstalk) é a interferência que um par induz no par vizinho, medida na mesma ponta em que o sinal é injetado. Ele é muito sensível à qualidade da terminação: quanto mais o par é destrançado no conector, pior o resultado. Um testador de continuidade não mede isso. Ele confirma que o fio 1 chega no pino 1, e para aí.
Em produção, esse tipo de enlace não cai de vez. Ele opera com margem negativa e passa a descartar frames conforme as condições pioram. Neste caso, a previsão era de dropped frames em EtherNet/IP à medida que a temperatura da sala subisse ao longo do dia. É o tipo de falha que chega à manutenção como "comunicação instável" e raramente é associada a quatro conectores.
Achado 2: TX e RX invertidos no anel MRP
Dois uplinks de fibra entre switches do anel MRP estavam com transmissão e recepção invertidas. O link estabelecia e os LEDs ficavam verdes. Na inspeção visual, nada chamava atenção.
O MRP (Media Redundancy Protocol) funciona com um gerenciador que envia quadros de teste pelas duas portas do anel e mantém uma delas bloqueada enquanto o anel está íntegro. Quando os quadros de teste não completam o caminho dentro do tempo esperado, o gerenciador conclui que o anel abriu e reconfigura. Com a inversão encontrada, na primeira retransmissão dentro de uma janela específica do MRP o pacote não completava o caminho e o anel reconfigurava.
O efeito previsto era uma reconfiguração por dia, sem padrão aparente para quem olha de fora, e sempre no pior momento. Esse é o defeito que gera meses de investigação em CLP, drive e remota, porque a rede "está de pé" quando alguém vai conferir.
Achado 3: firmware com bug conhecido de IGMP
Três switches do backbone estavam com firmware desatualizado, em uma versão com bug conhecido de multicast IGMP. IGMP snooping é o mecanismo que permite ao switch entregar tráfego multicast apenas às portas que pediram aquele grupo. EtherNet/IP depende muito de multicast, e quando o snooping falha o switch passa a inundar todas as portas.
O gatilho, neste caso, era a entrada de um device novo no anel: o bug provocava broadcast storm. Com a linha nova, nada aconteceria no startup. A rede travaria seis meses depois, na próxima expansão, quando alguém conectasse um equipamento e ninguém mais lembrasse desta obra.
Firmware não aparece em teste funcional. Ele aparece em inventário: fabricante, modelo, versão e cruzamento com os problemas conhecidos daquela versão. Sem essa tabela, o defeito fica dormindo até alguém acordá-lo.
Por que o teste de funcionamento não enxerga isso
Teste de funcionamento responde se a rede comunica hoje, nas condições do teste. Certificação e auditoria respondem se ela está dentro dos parâmetros que garantem comunicação nas condições reais: temperatura de sala em pleno turno, reconfiguração de anel, entrada de novos equipamentos. São perguntas diferentes, com instrumentos diferentes.
Não se trata de culpar o integrador. Ele entregou o que foi contratado, e o teste que fez é o teste que o mercado costuma pedir. A lacuna está no escopo, que raramente inclui uma verificação independente antes de energizar.
Há também uma questão de momento. Em bancada, com a linha parada, corrigir um conector, inverter um par de fibras ou atualizar um firmware leva minutos. Depois do startup, cada uma dessas intervenções exige janela de parada, autorização e alguém disposto a mexer numa rede que está produzindo.
Na prática, o que verificamos em uma auditoria pré-startup cabe em poucos itens objetivos, listados abaixo. Nenhum deles exige parar a obra, só instrumento adequado, método e alguém independente olhando para a rede antes de ela produzir.
- Certificação de cada enlace de cobre e fibra com instrumento e norma, resultado por link.
- Topologia física comparada ao projeto, incluindo polaridade das fibras e fechamento real do anel.
- Inventário de firmware de cada switch, com cruzamento de bugs conhecidos.
- Comportamento do anel e do multicast em bancada, antes de a linha produzir.
O que muda para a gestão do projeto
Os três achados foram corrigidos antes de energizar a linha. O startup aconteceu sem incidente, a expansão ficou no cronograma e o cliente recebeu o dossiê técnico assinado, com a rede documentada como ela realmente é.
Para quem gerencia o projeto, a conta é simples. Cada um desses defeitos, descoberto em produção, viraria uma investigação longa, com parada, peça trocada sem necessidade e desgaste entre cliente e fornecedor. Descoberto em bancada, virou uma lista de correções com dia e hora para acontecer.
Auditoria pré-startup não é custo extra do projeto. É o que evita que o projeto vire manchete três meses depois.
Artigo desenvolvido a partir das publicações de Darwin Anastacio Junior no LinkedIn.