PTP e IEC/IEEE 61850-9-3: sincronismo de precisão em subestações

Por que NTP nem sempre é suficiente

NTP é excelente para sincronizar servidores, gateways e muitos equipamentos de automação quando a precisão exigida está em milissegundos. Process Bus e aplicações que precisam alinhar amostras ou eventos de alta precisão exigem outra escala. PTP, Precision Time Protocol, mede e compensa atrasos de rede com suporte de hardware e clocks conscientes do protocolo, podendo atingir precisão muito superior quando corretamente projetado.

IEC/IEEE 61850-9-3:2016 define um perfil PTP para power utility automation baseado em IEEE 1588-2008/IEC 61588:2009 e voltado às classes mais exigentes de sincronismo da IEC 61850-5 e IEC 61869-9. Existe uma revisão de edição 2 em desenvolvimento para alinhar o perfil a IEEE 1588-2019, então projetos devem registrar qual profile e edição realmente são suportados pelos equipamentos.

• PTP não é apenas 'NTP mais rápido'.
• O profile define escolhas e parâmetros para interoperabilidade.
• Registre profile, domínio e versão em todo o projeto.

Grandmaster, ordinary, boundary e transparent clocks

O grandmaster fornece a referência principal, muitas vezes disciplinada por GNSS. Ordinary clocks são endpoints PTP. Boundary clocks participam como escravos em uma porta e mestres em outras, regenerando a distribuição de tempo em cada segmento. Transparent clocks encaminham PTP enquanto medem o residence time e contribuem para compensar o atraso introduzido pelo switch.

A escolha afeta arquitetura e desempenho. Uma cadeia de switches que apenas encaminha multicast sem função PTP pode introduzir variação de atraso difícil de compensar. Em redes redundantes, cada caminho precisa manter comportamento temporal. Verifique se o switch suporta exatamente o profile necessário; a presença de 'IEEE 1588' no datasheet não garante compatibilidade com IEC/IEEE 61850-9-3.

• Grandmaster: origem de referência.
• Boundary clock: termina e redistribui PTP.
• Transparent clock: informa/compensa tempo de residência.

Mensagens e seleção do mestre

PTP usa mensagens como Announce para divulgar qualidade e participar da seleção do mestre, Sync para distribuição temporal e, em modo two-step, Follow_Up para transportar informação precisa associada ao evento Sync. Mensagens relacionadas à medição de atraso dependem do mecanismo configurado. O Best Master Clock Algorithm seleciona a melhor fonte conforme atributos e prioridades do profile.

Durante falha de GNSS, um grandmaster pode continuar operando em holdover, mas sua qualidade deve refletir a degradação. O sistema não deve apenas permanecer 'lockado'; assinantes precisam saber se a referência continua dentro da classe necessária. Monitore clockClass, grandmaster identity, offset e mudanças de mestre. Trocas frequentes de grandmaster podem indicar prioridade conflitante, link instável ou qualidade oscilante.

• Monitore identidade do grandmaster ativo.
• Acompanhe offset e estado de lock/holdover.
• Alarme mudança de mestre quando relevante à operação.

PTP com Sampled Values

Em Process Bus, Merging Units e relés podem usar PTP para alinhar amostras de corrente e tensão. A rede precisa transportar SV e sincronismo com previsibilidade. Falha de PTP não necessariamente derruba o link ou interrompe o stream SV; o contador continua avançando enquanto a qualidade temporal se degrada. A aplicação deve responder de forma definida a essa condição.

Comissionamento deve incluir retirada de GNSS, falha do grandmaster primário, troca para backup e recuperação. Observe quanto tempo o sistema leva para selecionar nova fonte e se a aplicação mantém desempenho. Se existe PRP/HSR, teste PTP em ambos os LANs/caminhos conforme arquitetura. Redundância de dados sem redundância coerente de tempo pode deixar uma vulnerabilidade escondida.

• Teste perda de GNSS e holdover.
• Teste failover entre grandmasters.
• Correlacione qualidade PTP com qualidade de SV.

Diagnóstico com Wireshark e métricas

Uma captura PTP permite confirmar domínio, identities, sequência de Announce/Sync/Follow_Up e caminho de seleção de mestre. O timestamp de software do Wireshark não deve ser confundido com precisão do PTP; para medir offset com qualidade, use recursos do clock/equipamento ou hardware de captura apropriado. Wireshark é excelente para verificar protocolo e sequência, mas não substitui instrumento de tempo quando a exigência é submicrosegundo.

Registre topologia de clocks e prioridades em diagrama. Colete alarmes do grandmaster, switches e IEDs. Se um dispositivo não sincroniza, confirme primeiro profile, domainNumber e transporte; depois analise mensagens e qualidade. A abordagem evita trocar antena GNSS quando o problema é profile incompatível no switch ou VLAN que não encaminha PTP.

• Confirme profile e domainNumber.
• Siga Announce até identificar o mestre selecionado.
• Use métricas internas para precisão; PCAP para sequência/protocolo.

Projeto de antena GNSS e fonte de tempo

O PTP pode estar perfeito na LAN e ainda receber uma referência ruim se a antena GNSS estiver mal instalada. Visada parcial, multipath, cabo inadequado, conectores, proteção contra surtos e aterramento afetam o grandmaster. Monitore quantidade/qualidade de satélites e alarmes do receptor, e projete proteção externa sem criar caminho de surto para o rack.

Quando o risco de spoofing ou jamming for relevante, considere fontes alternativas, holdover qualificado e monitoramento de anomalias. A rede de sincronismo merece avaliação de cibersegurança e resiliência porque uma referência temporal errada pode afetar vários IEDs simultaneamente.

• Trate antena e cabo GNSS como parte do sistema de tempo.
• Monitore holdover e alarmes de referência.
• Considere falhas comuns que afetam todos os clocks.

Checklist de aceitação

Registre grandmaster primário e backup, priorities, domain, profile e topologia dos clocks. Meça offset reportado pelos endpoints em condição estável. Em seguida remova a fonte primária, confirme seleção de backup e observe transiente. Repita durante failover de rede, quando seguro.

Finalize validando alarmes no SCADA: perda de GNSS, holdover, grandmaster change e clock not synchronized devem ser visíveis conforme criticidade. Um sistema de tempo só é operacionalmente confiável se a degradação puder ser detectada antes de afetar a proteção.

Além do offset médio, acompanhe máximos, dispersão e eventos de perda de sincronismo. Um clock que apresenta média excelente pode ter excursões curtas capazes de afetar a aplicação. Alarmes, tendências e registros de mudança de grandmaster devem ser preservados para análise posterior.

• Documente topologia lógica e física.
• Teste failover de tempo e de rede.
• Leve alarmes de sincronismo para supervisão.