Protocolos e Arquitetura · 6 min de leitura
Topologia em anel com MRP virou resposta padrão para redundância em PROFINET. Na maioria das aplicações ela resolve bem. O erro está em assumir que resolve sempre, sem fazer a pergunta que decide o projeto: o que acontece na sua linha durante os 200 ms de uma reconvergência?
Como o MRP funciona e de onde vêm os 200 ms
O MRP (Media Redundancy Protocol) é o mecanismo de redundância de anel usado em PROFINET. Um dos switches assume o papel de gerenciador do anel e mantém uma de suas portas de anel bloqueada enquanto tudo está íntegro, o que evita o loop. Ele envia quadros de teste pelas duas portas continuamente; enquanto os quadros completam a volta, o anel está fechado.
Quando um enlace ou um switch do anel falha, os quadros de teste deixam de voltar. O gerenciador conclui que o anel abriu, desbloqueia a porta reserva e os switches limpam suas tabelas de endereços para reaprender o novo caminho. Durante esse intervalo, parte do tráfego não chega ao destino.
Pela especificação, o tempo máximo de convergência do MRP padrão é de 200 ms. É um número de pior caso, e é com ele que o projeto deve ser avaliado, porque é justamente o pior caso que aparece no dia em que o anel precisa funcionar.
Quando 200 ms são toleráveis
Na maioria das aplicações, 200 ms passam sem consequência. Com um cycle time de 16 ms, por exemplo, alguns ciclos de comunicação se perdem, o CLP mantém o controle e a linha segue. Esse é o cenário para o qual o MRP padrão foi pensado, e nele ele cumpre bem o papel.
O problema começa quando esse raciocínio vira regra. O projeto copia o anel com MRP padrão de uma linha para outra, de uma planta para outra, sem avaliar se a aplicação nova tem a mesma tolerância. A topologia é a mesma; o processo que ela sustenta não é.
Há ainda um efeito de percepção. Como a reconvergência é rara e rápida, ela quase nunca aparece como evento de rede para a operação. O que aparece é a consequência: um eixo que perdeu sincronia, um drive que desarmou, um lote de embalagens rejeitado. O chamado é aberto contra o equipamento, e a relação com o anel se perde.
Três cenários em que 200 ms quebram a linha
Em campo, há três situações recorrentes em que uma reconvergência de 200 ms deixa de ser detalhe e passa a ser parada. Em todas elas, a rede cumpre exatamente o que a especificação promete, e ainda assim a linha para. O problema não é defeito do MRP, é escolha do mecanismo errado para a aplicação.
No caso do IRT, a comunicação isócrona do PROFINET é usada quando o controle depende de sincronia fina entre dispositivos, como em motion control com vários eixos. Um blackout de comunicação nessa escala de tempo não é compensado pelo controlador. Nos outros dois casos, o limite vem do próprio equipamento ou do processo, que não têm como esperar a rede se recompor.
- IRT com exigência de jitter sub-milissegundo: o blackout vira falha de sincronia, parada de eixo e perda de coordenação entre eixos.
- Drives em produção contínua que abrem proteção ou perdem referência quando ficam mais de 100 ms sem comunicação.
- Envase e packaging, onde qualquer reconvergência vira refugo.
As alternativas: Fast MRP, PRP e HSR
Quando a aplicação não tolera 200 ms, existem mecanismos com tempos menores. O Fast MRP converge abaixo de 30 ms, e menos ainda em topologias pequenas. Para muitas linhas de drives e de packaging, essa diferença já tira a reconvergência da faixa que provoca parada.
Para motion control puro ou PROFIsafe crítico, a resposta costuma ser redundância paralela, com PRP ou HSR. No PRP (Parallel Redundancy Protocol), o dispositivo está ligado a duas redes independentes e envia cada quadro pelas duas ao mesmo tempo; o receptor aceita a primeira cópia e descarta a segunda. No HSR (High-availability Seamless Redundancy), o mesmo princípio é aplicado em anel, com cada quadro circulando nos dois sentidos.
Essas alternativas não se aplicam por decreto. Todos os participantes do anel precisam suportar o mecanismo escolhido, a configuração precisa ser coerente em todos os switches e o tempo real precisa ser verificado depois da instalação. Um anel projetado para Fast MRP com um switch configurado de outra forma se comporta pelo elo mais lento.
Nos dois casos, a falha de um caminho não exige reconvergência, porque o outro caminho já estava entregando o mesmo quadro. A convergência é zero aparente. O custo é outro: mais infraestrutura, dispositivos compatíveis e um projeto mais cuidadoso.
O que verificar antes de aceitar a topologia em anel
A decisão entre MRP padrão, Fast MRP e redundância paralela começa na aplicação, e não no catálogo do switch. Antes de aprovar um projeto em anel, a engenharia precisa ter respostas objetivas para algumas perguntas simples. Sem elas, a escolha do mecanismo de redundância é feita por hábito.
Também vale verificar em campo o que foi aprovado no papel. Um anel só oferece redundância se estiver fisicamente fechado em switches diferentes, e o tempo de convergência real só é conhecido quando alguém derruba cada perna e mede.
- Qual é o cycle time e qual é a tolerância real de cada dispositivo a perda de comunicação?
- Há eixos em IRT, drives que desarmam por falta de comunicação ou máquinas que geram refugo em qualquer interrupção?
- O mecanismo escolhido tem tempo de convergência compatível com o pior desses casos?
- O teste de convergência foi feito com cada perna do anel derrubada individualmente?
O que muda para a gestão
Para quem aprova projeto, o ponto é não tratar redundância como item de lista. "Tem anel" não responde se a linha sobrevive a uma falha de enlace. A resposta depende do tempo de convergência do mecanismo e da tolerância do processo, e as duas coisas precisam estar escritas no projeto.
O erro mais comum que encontramos não é técnico, é de premissa: assumir que o MRP padrão sempre resolve. Antes de aceitar a topologia, faça a pergunta que decide tudo. Qual é o pior caso de uma reconvergência de 200 ms na sua linha?
Artigo desenvolvido a partir das publicações de Darwin Anastacio Junior no LinkedIn.