Detalhes de implementação do protocolo de sincronização de horário PTPv2

Introdução

O conceito de construção de uma “Subestação Digital” no setor de energia elétrica requer sincronização com precisão de 1 μs. As transações financeiras também exigem precisão de microssegundos. Nessas aplicações, a precisão do tempo NTP não é mais suficiente.

O protocolo de sincronização PTPv2, descrito pelo padrão IEEE 1588v2, permite uma precisão de sincronização de várias dezenas de nanossegundos. O PTPv2 permite enviar pacotes de sincronização através de redes L2 e L3.

As principais áreas onde o PTPv2 é usado são:

• energia;
• equipamentos de controle e medição;
• complexo militar-industrial;
• telecomunicações;
• setor financeiro.

Esta postagem explica como funciona o protocolo de sincronização PTPv2.

Temos mais experiência na indústria e vemos frequentemente este protocolo em aplicações de energia. Assim, faremos a revisão com cautela para energia.

Por que é necessário?

No momento, o STO 34.01-21-004-2019 do PJSC Rosseti e o STO 56947007-29.240.10.302-2020 do PJSC FGC UES contêm requisitos para organizar um barramento de processo com sincronização de tempo via PTPv2.

Isso se deve ao fato de que terminais de proteção de relés e dispositivos de medição estão conectados ao barramento de processo, que transmitem valores instantâneos de corrente e tensão através do barramento de processo, usando os chamados fluxos SV (fluxos multicast).

Os terminais de proteção de relé usam esses valores para implementar a proteção do bay. Se a precisão das medições de tempo for pequena, algumas proteções poderão funcionar falsamente.

Por exemplo, as defesas da seletividade absoluta podem ser vítimas de uma sincronização de tempo “fraca”. Muitas vezes a lógica de tais defesas baseia-se na comparação de duas quantidades. Se os valores divergirem em um valor suficientemente grande, a proteção será acionada. Se esses valores forem medidos com uma precisão de tempo de 1 ms, você poderá obter uma grande diferença onde os valores são realmente normais se medidos com uma precisão de 1 μs.

Versões PTP

O protocolo PTP foi originalmente descrito em 2002 no padrão IEEE 1588-2002 e foi chamado de “Padrão para um Protocolo de Sincronização de Relógio de Precisão para Sistemas de Medição e Controle em Rede”. Em 2008, foi lançado o padrão IEEE 1588-2008 atualizado, que descreve o PTP versão 2. Esta versão do protocolo melhorou a precisão e a estabilidade, mas não manteve a compatibilidade retroativa com a primeira versão do protocolo. Além disso, em 2019, foi lançada uma versão do padrão IEEE 1588-2019, descrevendo o PTP v2.1. Esta versão adiciona pequenas melhorias ao PTPv2 e é compatível com versões anteriores do PTPv2.

Ou seja, temos a seguinte imagem com versões:

PTPv1
(IEEE 1588-2002)

PTPv2
(IEEE 1588-2008)

PTPv2.1
(IEEE 1588-2019)

PTPv1 (IEEE 1588-2002)

-
Incompatível

Incompatível

PTPv2 (IEEE 1588-2008)

Incompatível

-
Compatível

PTPv2.1 (IEEE 1588-2019)

Incompatível

Compatível

-

Mas, como sempre, existem nuances.

A incompatibilidade entre PTPv1 e PTPv2 significa que um dispositivo habilitado para PTPv1 não será capaz de sincronizar com um relógio preciso executado em PTPv2. Eles usam diferentes formatos de mensagens para sincronizar.

Mas ainda é possível combinar dispositivos com PTPv1 e dispositivos com PTPv2 na mesma rede. Para conseguir isso, alguns fabricantes permitem que você selecione a versão do protocolo nas portas do edge clock. Ou seja, um relógio de limite pode sincronizar usando PTPv2 e ainda sincronizar outros relógios conectados a ele usando PTPv1 e PTPv2.

Dispositivos PTP. O que são e como são diferentes?

O padrão IEEE 1588v2 descreve vários tipos de dispositivos. Todos eles são mostrados na tabela.

Os dispositivos se comunicam entre si através de uma LAN usando PTP.

Os dispositivos PTP são chamados de relógios. Todos os relógios medem a hora exata do relógio do grande mestre.

Existem 5 tipos de relógios:

Relógio do Grande Mestre

A principal fonte de tempo preciso. Muitas vezes equipado com uma interface para conectar GPS.

Relógio comum

Um dispositivo de porta única que pode ser mestre (relógio mestre) ou escravo (relógio escravo)

Relógio mestre (mestre)

Eles são a fonte da hora exata pela qual outros relógios são sincronizados

Relógio escravo

Dispositivo final sincronizado com o relógio mestre

Relógio de limite

Um dispositivo com múltiplas portas que pode ser mestre ou escravo.

Ou seja, esses relógios podem sincronizar a partir do relógio mestre superior e sincronizar os relógios escravos inferiores.

Relógio transparente de ponta a ponta

Um dispositivo com múltiplas portas que não é nem relógio mestre nem escravo. Ele transmite dados PTP entre dois relógios.

Ao transmitir dados, o relógio transparente corrige todas as mensagens PTP.

A correção ocorre adicionando o tempo de atraso deste dispositivo ao campo de correção no cabeçalho da mensagem transmitida.

Relógio transparente ponto a ponto

Um dispositivo com múltiplas portas que não é nem relógio mestre nem escravo.
Ele transmite dados PTP entre dois relógios.

Ao transmitir dados, o relógio transparente corrige todas as mensagens PTP Sync e Follow_Up (mais sobre elas abaixo).

A correção é obtida adicionando ao campo de correção do pacote transmitido o atraso no dispositivo transmissor e o atraso no canal de transmissão de dados.

Nó de gerenciamento

Um dispositivo que configura e diagnostica outros relógios

Os relógios mestre e escravo são sincronizados usando carimbos de data/hora em mensagens PTP. Existem dois tipos de mensagens no protocolo PTP:

• Mensagens de eventos são mensagens sincronizadas que envolvem a geração de um carimbo de data/hora no momento em que a mensagem é enviada e no momento em que é recebida.
• Mensagens Gerais - Essas mensagens não exigem carimbos de data e hora, mas podem conter carimbos de data e hora para mensagens relacionadas

Mensagens de Evento

Mensagens Gerais

sincronização
Atraso_Req
Pdelay_Req
Pdelay_Resp

Anunciar
Seguir
Atraso_Resp
Pdelay_Resp_Follow_Up
Assistência Domiciliária
Sinalização

Todos os tipos de mensagens serão discutidos com mais detalhes abaixo.

Problemas básicos de sincronização

Quando um pacote de sincronização é transmitido através de uma rede local, ele é atrasado no switch e no link de dados. Qualquer mudança produzirá um atraso de cerca de 10 microssegundos, o que é inaceitável para PTPv2. Afinal, precisamos atingir uma precisão de 1 μs no dispositivo final. (Isto se estivermos falando de energia. Outras aplicações podem exigir maior precisão.)

IEEE 1588v2 descreve vários algoritmos operacionais que permitem registrar o atraso de tempo e corrigi-lo.

Algoritmo de trabalho
Durante a operação normal, o protocolo opera em duas fases.

• Fase 1 - estabelecimento da hierarquia “Master Clock – Slave Clock”.
• Fase 2 - sincronização do relógio usando mecanismo End-to-End ou Peer-to-Peer.

Fase 1 - Estabelecendo a Hierarquia Mestre-Escravo

Cada porta de um relógio regular ou de borda possui um certo número de estados (relógio escravo e relógio mestre). O padrão descreve o algoritmo de transição entre esses estados. Na programação, tal algoritmo é chamado de máquina de estados finitos ou máquina de estados (mais detalhes no Wiki).

Esta máquina de estado usa o Best Master Clock Algorithm (BMCA) para definir o mestre ao conectar dois relógios.

Este algoritmo permite que o relógio assuma as responsabilidades do relógio grande mestre quando o relógio grande mestre upstream perde o sinal GPS, fica offline, etc.

As transições de estado de acordo com o BMCA estão resumidas no diagrama a seguir:


As informações sobre o relógio do outro lado do “fio” são enviadas em uma mensagem especial (mensagem de anúncio). Uma vez recebida esta informação, o algoritmo da máquina de estados é executado e é feita uma comparação para ver qual relógio é melhor. A porta do melhor relógio torna-se o relógio mestre.

Uma hierarquia simples é mostrada no diagrama abaixo. Os caminhos 1, 2, 3, 4, 5 podem conter um relógio Transparente, mas não participam do estabelecimento da hierarquia Master Clock - Slave Clock.

Fase 2 – Sincronizar relógios regulares e de borda

Imediatamente após o estabelecimento da hierarquia “Master Clock – Slave Clock”, inicia-se a fase de sincronização dos relógios regulares e de limite.

Para sincronizar, o relógio mestre envia uma mensagem contendo um carimbo de data/hora para os relógios escravos.

O relógio mestre pode ser:

• estágio único;
• dois estágios.

Os relógios de estágio único enviam uma mensagem Sync para sincronizar.

Um relógio de dois estágios usa duas mensagens para sincronização – Sync e Follow_Up.

Dois mecanismos podem ser usados ​​para a fase de sincronização:

• Atrasar o mecanismo de solicitação-resposta.
• Mecanismo de medição de atraso de peer.

Primeiro, vejamos esses mecanismos no caso mais simples - quando relógios transparentes não são usados.

Atrasar mecanismo de solicitação-resposta

O mecanismo envolve duas etapas:

1. Medir o atraso na transmissão de uma mensagem entre o relógio mestre e o relógio escravo. Realizado usando um mecanismo de atraso de solicitação-resposta.
2. A correção da mudança de horário exata é executada.

Medição de latência


t1 – Tempo de envio da mensagem Sync pelo relógio mestre; t2 – Tempo de recepção da mensagem Sync pelo relógio escravo; t3 – Tempo de envio da solicitação de atraso (Delay_Req) ​​pelo relógio escravo; t4 – Tempo de recepção de Delay_Req pelo relógio mestre.

Quando o relógio escravo conhece os tempos t1, t2, t3 e t4, ele pode calcular o atraso médio na transmissão da mensagem de sincronização (tmpd). É calculado da seguinte forma:

Ao transmitir uma mensagem Sync and Follow_Up, é calculado o atraso de tempo do mestre para o escravo - t-ms.

Ao transmitir mensagens Delay_Req e Delay_Resp, é calculado o atraso de tempo do escravo ao mestre - t-sm.

Se ocorrer alguma assimetria entre esses dois valores, aparece um erro na correção do desvio do tempo exato. O erro é causado pelo fato do atraso calculado ser a média dos atrasos t-ms e t-sm. Se os atrasos não forem iguais, não ajustaremos o tempo com precisão.

Correção de mudança de horário

Uma vez conhecido o atraso entre o relógio mestre e o relógio escravo, o relógio escravo executa a correção de tempo.

Os relógios escravos usam a mensagem Sync e uma mensagem opcional Follow_Up para calcular o deslocamento de tempo exato ao transmitir um pacote do mestre para os relógios escravos. A mudança é calculada usando a seguinte fórmula:

Mecanismo de medição de atraso de peer

Este mecanismo também utiliza duas etapas para sincronização:

1. Os dispositivos medem o atraso de todos os vizinhos em todas as portas. Para fazer isso, eles usam um mecanismo de atraso de pares.
2. Correção da mudança de horário exata.

Medir a latência entre dispositivos compatíveis com o modo ponto a ponto

A latência entre as portas que suportam o mecanismo ponto a ponto é medida usando as seguintes mensagens:

Quando a porta 1 conhece os tempos t1, t2, t3 e t4, ela pode calcular o atraso médio (tmld). É calculado usando a seguinte fórmula:

A porta então usa esse valor ao calcular o campo de ajuste para cada mensagem Sync ou mensagem Follow_Up opcional que passa pelo dispositivo.

O atraso total será igual à soma do atraso durante a transmissão através deste dispositivo, o atraso médio durante a transmissão através do canal de dados e o atraso já contido nesta mensagem, habilitado nos dispositivos upstream.

As mensagens Pdelay_Req, Pdelay_Resp e o opcional Pdelay_Resp_Follow_Up permitem obter o atraso do mestre para o escravo e do escravo para o mestre (circular).

Qualquer assimetria entre esses dois valores introduzirá um erro de correção de deslocamento de tempo.

Ajustando a mudança de horário exata

Os relógios escravos usam uma mensagem Sync e uma mensagem opcional Follow_Up para calcular o deslocamento de tempo exato ao transmitir um pacote do mestre para os relógios escravos. A mudança é calculada usando a seguinte fórmula:

Vantagens ajuste do mecanismo peer-to-peer - o atraso de cada mensagem Sync ou Follow_Up é calculado à medida que é transmitida na rede. Conseqüentemente, a alteração do caminho de transmissão não afetará de forma alguma a precisão do ajuste.

Ao utilizar este mecanismo, a sincronização de tempo não requer o cálculo do atraso de tempo ao longo do caminho percorrido pelo pacote de sincronização, como é feito na troca básica. Aqueles. As mensagens Delay_Req e Delay_Resp não são enviadas. Neste método, o atraso entre os relógios mestre e escravo é simplesmente somado no campo de ajuste de cada mensagem Sync ou Follow_Up.

Outra vantagem é que o relógio mestre fica livre da necessidade de processar mensagens Delay_Req.

Modos de operação de relógios transparentes

Assim, estes foram exemplos simples. Agora suponha que os switches apareçam no caminho de sincronização.

Se você usar switches sem suporte a PTPv2, o pacote de sincronização será atrasado no switch em aproximadamente 10 μs.

Os switches que suportam PTPv2 são chamados de relógios transparentes na terminologia IEEE 1588v2. Os relógios transparentes não são sincronizados a partir do relógio mestre e não participam da hierarquia “Relógio Mestre - Relógio Escravo”, mas ao transmitir mensagens de sincronização lembram quanto tempo a mensagem foi atrasada por eles. Isso permite que você ajuste o atraso de tempo.

Os relógios transparentes podem operar em dois modos:

• De ponta a ponta.
• Pessoa para pessoa.

Ponta a ponta (E2E)

O relógio transparente E2E transmite mensagens de sincronização e mensagens de acompanhamento em todas as portas. Mesmo aqueles que estão bloqueados por alguns protocolos (por exemplo, RSTP).

O switch lembra o carimbo de data/hora quando um pacote de sincronização (Follow_Up) foi recebido na porta e quando foi enviado da porta. Com base nesses dois carimbos de data/hora, é calculado o tempo que o switch leva para processar a mensagem. Na norma, esse tempo é denominado tempo de residência.

O tempo de processamento é adicionado ao campo CorrectionField da mensagem Sync (relógio de um passo) ou Follow_Up (relógio de dois passos).

O relógio transparente E2E mede o tempo de processamento das mensagens Sync e Delay_Req que passam pelo switch. Mas é importante entender que o atraso entre o relógio mestre e o relógio escravo é calculado usando o mecanismo de solicitação-resposta de atraso. Se o relógio mestre mudar ou o caminho do relógio mestre para o relógio escravo mudar, o atraso será medido novamente. Isto aumenta o tempo de transição em caso de alterações na rede.

O relógio transparente P2P, além de medir o tempo que um switch leva para processar uma mensagem, mede o atraso no link de dados até seu vizinho mais próximo usando um mecanismo de latência de vizinho.

A latência é medida em cada link em ambas as direções, incluindo links bloqueados por algum protocolo (como o RSTP). Isso permite calcular imediatamente o novo atraso no caminho de sincronização se o relógio mestre ou a topologia da rede mudarem.

O tempo de processamento de mensagens pelos switches e a latência são acumulados ao enviar mensagens Sync ou Follow_Up.

Tipos de suporte PTPv2 por switches

Os switches podem suportar PTPv2:

• programaticamente;
• hardware.

Ao implementar o protocolo PTPv2 em software, o switch solicita um carimbo de data/hora do firmware. O problema é que o firmware funciona ciclicamente, e você terá que esperar até que ele termine o ciclo atual, receba a solicitação para processamento e emita um carimbo de data/hora após o próximo ciclo. Isto também levará tempo e teremos um atraso, embora não tão significativo como sem suporte de software para PTPv2.

Somente o suporte de hardware para PTPv2 permite manter a precisão necessária. Neste caso, o carimbo de data / hora é emitido por um ASIC especial instalado na porta.

Formato da mensagem

Todas as mensagens PTP consistem nos seguintes campos:

• Cabeçalho – 34 bytes.
• Corpo – o tamanho depende do tipo de mensagem.
• O sufixo é opcional.

cabeçalho

O campo Cabeçalho é o mesmo para todas as mensagens PTP. Seu tamanho é de 34 bytes.

Formato do campo de cabeçalho:

tipo de mensagem – contém o tipo de mensagem que está sendo transmitida, por exemplo Sync, Delay_Req, PDelay_Req, etc.

comprimento da mensagem – contém o tamanho total da mensagem PTP, incluindo cabeçalho, corpo e sufixo (mas excluindo bytes de preenchimento).

DomainNumber – determina a qual domínio PTP a mensagem pertence.

Nome de domínio - são vários relógios diferentes coletados em um grupo lógico e sincronizados a partir de um relógio mestre, mas não necessariamente sincronizados com relógios pertencentes a um domínio diferente.

bandeiras – Este campo contém vários sinalizadores para identificar o status da mensagem.

campo de correção – contém o tempo de atraso em nanossegundos. O tempo de atraso inclui o atraso ao transmitir através do relógio transparente, bem como o atraso ao transmitir através do canal ao usar o modo ponto a ponto.

fontePortIdentity – este campo contém informações sobre de qual porta esta mensagem foi originalmente enviada.

ID de sequência – contém um número de identificação para mensagens individuais.

campo de controle – campo artefato =) Permanece da primeira versão do padrão e contém informações sobre o tipo desta mensagem. Essencialmente igual a messageType, mas com menos opções.

logMessageInterval – este campo é determinado pelo tipo de mensagem.

Corpo

Conforme discutido acima, existem vários tipos de mensagens. Esses tipos são descritos abaixo:

Mensagem de anúncio
A mensagem de anúncio é usada para “informar” outros relógios dentro do mesmo domínio sobre seus parâmetros. Esta mensagem permite que você configure uma hierarquia Master Clock - Slave Clock.


Sincronizar mensagem
A mensagem de sincronização é enviada pelo relógio mestre e contém a hora do relógio mestre no momento em que a mensagem de sincronização foi gerada. Se o relógio mestre for de dois estágios, o carimbo de data/hora na mensagem de sincronização será definido como 0 e o carimbo de data/hora atual será enviado na mensagem Follow_Up associada. A mensagem Sync é usada para ambos os mecanismos de medição de latência.

A mensagem é transmitida usando Multicast. Opcionalmente você pode usar Unicast.

Mensagem Delay_Req

O formato da mensagem Delay_Req é idêntico ao da mensagem Sync. O relógio escravo envia Delay_Req. Contém a hora em que Delay_Req foi enviado pelo relógio escravo. Esta mensagem é usada apenas para o mecanismo de atraso de solicitação-resposta.

A mensagem é transmitida usando Multicast. Opcionalmente você pode usar Unicast.

Mensagem de acompanhamento

A mensagem Follow_Up é enviada opcionalmente pelo relógio mestre e contém o horário de envio Sincronizar mensagens mestre. Somente relógios mestres de dois estágios enviam a mensagem Follow_Up.

A mensagem Follow_Up é usada para ambos os mecanismos de medição de latência.

A mensagem é transmitida usando Multicast. Opcionalmente você pode usar Unicast.

Mensagem Delay_Resp

A mensagem Delay_Resp é enviada pelo relógio mestre. Contém a hora em que o Delay_Req foi recebido pelo relógio mestre. Esta mensagem é usada apenas para o mecanismo de atraso de solicitação-resposta.

A mensagem é transmitida usando Multicast. Opcionalmente você pode usar Unicast.

Mensagem Pdelay_Req

A mensagem Pdelay_Req é enviada por um dispositivo que solicita um atraso. Contém a hora em que a mensagem foi enviada da porta deste dispositivo. Pdelay_Req é usado apenas para o mecanismo de medição de atraso vizinho.

Mensagem Pdelay_Resp

A mensagem Pdelay_Resp é enviada por um dispositivo que recebeu uma solicitação de atraso. Contém a hora em que a mensagem Pdelay_Req foi recebida por este dispositivo. A mensagem Pdelay_Resp é usada apenas para o mecanismo de medição de atraso vizinho.

Mensagem Pdelay_Resp_Follow_Up

A mensagem Pdelay_Resp_Follow_Up é enviada opcionalmente pelo dispositivo que recebeu a solicitação de atraso. Contém a hora em que a mensagem Pdelay_Req foi recebida por este dispositivo. A mensagem Pdelay_Resp_Follow_Up é enviada apenas por relógios mestres de dois estágios.

Esta mensagem também pode ser usada para tempo de execução em vez de carimbo de data/hora. O tempo de execução é o tempo desde o momento em que Pdelay-Req é recebido até o envio de Pdelay_Resp.

Pdelay_Resp_Follow_Up são usados ​​apenas para o mecanismo de medição de atraso vizinho.

Mensagens de gerenciamento

As mensagens de controle PTP são necessárias para transferir informações entre um ou mais relógios e o nó de controle.

Transferência para LV

Uma mensagem PTP pode ser transmitida em dois níveis:

• Rede – como parte dos dados IP.
• Canal – como parte de um quadro Ethernet.

Transmissão de mensagens PTP sobre UDP sobre IP sobre Ethernet

PTP sobre UDP sobre Ethernet

Perfis

O PTP possui muitos parâmetros flexíveis que precisam ser configurados. Por exemplo:

• Opções BMCA.
• Mecanismo de medição de latência.
• Intervalos e valores iniciais de todos os parâmetros configuráveis, etc.

E apesar de termos dito anteriormente que os dispositivos PTPv2 são compatíveis entre si, isso não é verdade. Os dispositivos devem ter as mesmas configurações para se comunicarem.

É por isso que existem os chamados perfis PTPv2. Perfis são grupos de configurações configuradas e restrições de protocolo definidas para que a sincronização de horário possa ser implementada para uma aplicação específica.

O próprio padrão IEEE 1588v2 descreve apenas um perfil – “Perfil Padrão”. Todos os outros perfis são criados e descritos por diversas organizações e associações.

Por exemplo, o Power Profile, ou PTPv2 Power Profile, foi criado pelo Power Systems Relaying Committee e pelo Substation Committee da IEEE Power and Energy Society. O perfil em si é denominado IEEE C37.238-2011.

O perfil descreve que o PTP pode ser transmitido:

• Somente através de redes L2 (ou seja, Ethernet, HSR, PRP, não IP).
• As mensagens são transmitidas apenas por difusão Multicast.
• O mecanismo de medição de atraso de peer é usado como mecanismo de medição de atraso.

O domínio padrão é 0, o domínio recomendado é 93.

A filosofia de design do C37.238-2011 era reduzir o número de recursos opcionais e manter apenas as funções necessárias para uma interação confiável entre dispositivos e maior estabilidade do sistema.

Além disso, a frequência de transmissão da mensagem é determinada:

Na verdade, apenas um parâmetro está disponível para seleção - o tipo de relógio mestre (estágio único ou dois estágios).

A precisão não deve ser superior a 1 μs. Em outras palavras, um caminho de sincronização pode conter no máximo 15 relógios transparentes ou três relógios de limite.

Fonte: habr.com