Introdução
A concepção de uma "Subestação Digital" na energia elétrica requer sincronização com precisão de 1 μs. Para a realização de transações financeiras, também é necessária precisão em microssegundos. Nessas aplicações, a precisão do tempo NTP já não é suficiente.
O protocolo de sincronização PTPv2, descrito na norma IEEE 1588v2, permite alcançar precisão de sincronização na casa de dezenas de nanossegundos. O PTPv2 possibilita o envio de pacotes de sincronização através de redes L2 e L3.
As principais áreas em que o PTPv2 é aplicado incluem:
- energia;
- equipamento de medição e controle;
- complexo industrial de defesa;
- telecomunicações;
- setor financeiro.
Neste post, discutimos como funciona o protocolo de sincronização PTPv2.
Temos mais experiência na indústria e frequentemente nos deparamos com esse protocolo em aplicações energéticas. Portanto, também faremos uma revisão com foco .
Por que é necessário?
Atualmente, nas normas 34.01-21-004-2019 da PJSC "Rosseti" e 56947007-29.240.10.302-2020 da PJSC "FSK EES", existem requisitos para a organização do barramento de processo com garantia de sincronização de tempo via PTPv2.
Isso se deve ao fato de que ao barramento de processo são conectados terminais de proteção por relé e dispositivos de medição, que, através do barramento de processo, por meio dos chamados fluxos SV (fluxos multicast), transmitem valores instantâneos de corrente e tensão.
Os terminais de proteção por relé utilizam esses valores para implementar as proteções de conexão. Se a precisão das medições de tempo for baixa, algumas proteções podem operar de forma incorreta.
Por exemplo, a proteção de seletividade absoluta pode ser uma vítima de uma "sincronização fraca" de tempo. Muitas vezes, a lógica de tais proteções é baseada na comparação de duas grandezas. Se as grandezas divergem em um valor suficientemente grande, a proteção é ativada. Se essas grandezas forem medidas com precisão de tempo de 1 ms, pode-se obter uma grande diferença onde os valores na verdade estão normais, se medidos com precisão de 1 μs.
Versões do PTP
O protocolo PTP foi inicialmente descrito em 2002 no padrão IEEE 1588-2002, denominado "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems". Em 2008, foi lançado o padrão atualizado IEEE 1588-2008, que descreve a versão 2 do PTP. Nesta versão do protocolo, a precisão e a estabilidade foram aprimoradas, mas a compatibilidade retroativa com a primeira versão do protocolo não foi mantida. Além disso, em 2019, foi lançada a versão do padrão IEEE 1588-2019, que descreve o PTP v2.1. Esta versão adiciona pequenas melhorias ao PTPv2 e é retrocompatível com o PTPv2.
Em outras palavras, temos a seguinte representação das versões:
PTPv1
(IEEE 1588-2002)
PTPv2
(IEEE 1588-2008)
PTPv2.1
(IEEE 1588-2019)
PTPv1 (IEEE 1588-2002)
—
Incompatíveis
Incompatíveis
PTPv2 (IEEE 1588-2008)
Incompatíveis
—
Compatíveis
PTPv2.1 (IEEE 1588-2019)
Incompatíveis
Compatíveis
—
Mas, como sempre, existem nuances.
A incompatibilidade entre PTPv1 e PTPv2 implica que um dispositivo que suporta PTPv1 não poderá sincronizar com relógios precisos operando em PTPv2. Para a sincronização, eles utilizam diferentes formatos de mensagens.
No entanto, é possível combinar dispositivos com PTPv1 e dispositivos com PTPv2 em uma mesma rede. Para isso, alguns fabricantes permitem escolher a versão do protocolo nas portas dos relógios de borda. Ou seja, os relógios de borda podem sincronizar-se via PTPv2 e, ao mesmo tempo, sincronizar outros relógios conectados a eles, tanto via PTPv1 quanto via PTPv2.
Dispositivos PTP. Quais são e como diferem?
O padrão IEEE 1588v2 descreve vários tipos de dispositivos. Todos eles estão listados na tabela.
Os dispositivos interagem entre si através de redes locais, utilizando PTP.
Os dispositivos PTP são chamados de relógios. Todos os relógios obtêm o tempo preciso a partir de relógios mestre.
Existem 5 tipos de relógios:
Grandmaster clock (Relógio Mestre)
Fonte principal de tempo preciso. Frequentemente equipado com uma interface para conexão GPS.
Ordinary Clock (Relógio Comum)
Dispositivo com uma porta, que pode ser mestre (relógio líder) ou escravo (relógio subordinado)
Relógios mestres (mestre)
São a fonte de tempo preciso, a partir da qual outros relógios se sincronizam
Relógios escravos (escravo)
Dispositivo final, que se sincroniza a partir dos relógios mestres
Boundary Clock (Relógio de Borda)
Dispositivo com várias portas, que pode ser mestre ou escravo.
Ou seja, esses relógios podem se sincronizar com relógios mestres superiores e sincronizar relógios escravos inferiores.
Relógio Transparente End-to-End
Dispositivo com várias portas que não é nem relógio mestre nem escravo. Ele transmite dados PTP entre dois relógios.
Durante a transmissão de dados, os relógios transparentes corrigem todas as mensagens PTP.
A correção é realizada adicionando um atraso de tempo neste dispositivo no campo de correção no cabeçalho da mensagem transmitida.
Relógio Transparente Peer-to-Peer
Dispositivo com várias portas que não é nem relógio mestre nem escravo.
Ele transmite dados PTP entre dois relógios.
Durante a transmissão de dados, os relógios transparentes corrigem todas as mensagens PTP Sync e Follow_Up (mais detalhes a seguir).
A correção é conseguida adicionando um atraso ao campo de correção do pacote transmitido com o atraso no dispositivo transmissor e no canal de transmissão de dados.
Nó de Gerenciamento
Dispositivo que configura e diagnostica outros relógios
Relógios mestres e escravos são sincronizados usando marcas de tempo nas mensagens PTP. Existem dois tipos de mensagens no protocolo PTP:
- Mensagens de Evento – são mensagens sincronizadas que pressupõem a geração de uma marca de tempo no momento do envio da mensagem e no momento da recepção
- Mensagens Gerais – estas mensagens não exigem marcas de tempo, mas podem conter marcas de tempo para mensagens relacionadas
Mensagens de Evento
Mensagens Gerais
Sync
Delay_Req
Pdelay_Req
Pdelay_Resp
Anunciar
Follow_Up
Delay_Resp
Pdelay_Resp_Follow_Up
Gerenciamento
Sinalização
A seguir, todos os tipos de mensagens serão examinados com mais detalhes.
Principais problemas de sincronização
Ao transmitir um pacote de sincronização pela rede local, ele sofre um atraso no switch e no canal de transmissão de dados. Qualquer switch irá proporcionar um atraso de cerca de 10 μs, o que não é aceitável para PTPv2. Para o dispositivo final, precisamos alcançar uma precisão de 1 μs. (Isso se estamos falando do setor de energia. Outros aplicativos podem exigir ainda mais precisão.)
No IEEE 1588v2, são descritos vários algoritmos de operação que permitem medir o atraso de tempo e corrigi-lo.
Algoritmo de operação
Em operação normal, o protocolo funciona em duas fases.
- Fase 1 — estabelecimento da hierarquia 'Relógios Mestres - Relógios Escravos'.
- Fase 2 — sincronização dos relógios usando o mecanismo End-to-End ou Peer-to-Peer.
Fase 1 — Estabelecimento da hierarquia 'Mestre-Escravo'
Cada porta de relógios comuns ou de fronteira possui um número específico de estados (relógios escravos e relógios mestres). O padrão descreve o algoritmo de transição entre esses estados. Na programação, tal algoritmo é chamado de autômato finito ou máquina de estados (mais detalhes na Wiki).
Este autômato finito utiliza o algoritmo Best Master Clock Algorithm (BMCA) para estabelecer o mestre ao conectar dois relógios.
Este algoritmo permite que os relógios assumam as responsabilidades de relógios grandmasters quando os relógios grandmasters superiores perdem o sinal de GPS, se desligam da rede, etc.
As transições entre estados de acordo com o BMCA estão brevemente ilustradas no esquema a seguir:
As informações sobre os relógios na outra extremidade do 'fio' são enviadas em uma mensagem especial (mensagem Announce). Quando essa informação é recebida, o algoritmo da máquina de estados é acionado e ocorre a comparação de quais relógios são melhores. A porta nos melhores relógios torna-se o relógio mestre.
A hierarquia simples é apresentada no esquema abaixo. Os caminhos 1, 2, 3, 4, 5 podem conter relógios transparentes (Transparent clock), mas eles não participam do estabelecimento da hierarquia 'Relógios Mestres – Relógios Escravos'.
Fase 2 — Sincronização de relógios comuns e de fronteira
Logo após o estabelecimento da hierarquia 'Relógios Mestres – Relógios Escravos', inicia-se a fase de sincronização dos relógios comuns e de fronteira.
Para sincronização, os relógios mestres enviam aos relógios escravos uma mensagem que contém um carimbo de data/hora.
Os relógios mestres podem ser:
- de um estágio;
- de dois estágios.
Relógios de um estágio para sincronização enviam uma única mensagem Sync.
Relógios de dois estágios para sincronização utilizam duas mensagens – Sync e Follow_Up.
Para a fase de sincronização, podem ser utilizados dois mecanismos:
- Mecanismo de solicitação-resposta de atraso (Delay request-response mechanism).
- Mecanismo de medição de atraso de nó vizinho (Peer delay measurement mechanism).
Vamos começar analisando esses mecanismos no caso mais simples — quando relógios transparentes não são utilizados.
Mecanismo de solicitação-resposta de atraso (Delay request-response mechanism)
O mecanismo prevê duas etapas:
- Medição do atraso na transmissão da mensagem entre os relógios mestres e escravos. Isso é realizado através do mecanismo de solicitação-resposta de atraso.
- Realiza-se a correção do desvio do tempo preciso.
Medição do atraso
t1 – Tempo de envio da mensagem Sync pelos relógios mestres; t2 – Tempo de recebimento da mensagem Sync pelos relógios escravos; t3 – Tempo de envio da solicitação de atraso (Delay_Req) pelos relógios escravos; t4 – Tempo de recebimento da Delay_Req pelos relógios mestres.
Quando os relógios escravos conhecem os tempos t1, t2, t3 e t4, eles podem calcular a média de atraso durante a transmissão da mensagem de sincronização (tmpd). Isso é calculado da seguinte forma:
Durante a transmissão da mensagem Sync e Follow_Up, é calculado o atraso de tempo do mestre para o escravo – t-ms.
Durante a transmissão das mensagens Delay_Req e Delay_Resp, é calculado o atraso de tempo do escravo para o mestre – t-sm.
Se entre esses dois valores surgir alguma assimetria, ocorrerá um erro na correção do tempo exato. O erro é determinado pelo fato de que o atraso calculado é a média dos atrasos t-ms e t-sm. Se os atrasos não forem iguais, ajustaremos o tempo de forma imprecisa.
Correção do deslocamento do tempo exato
Depois que o atraso entre os relógios mestres e escravos é conhecido, os relógios escravos realizam a correção do tempo.
Os relógios escravos utilizam a mensagem Sync e a mensagem opcional Follow_Up para calcular o deslocamento do tempo exato ao transmitir pacotes dos relógios mestres para os escravos. O deslocamento é calculado pela seguinte fórmula:
Mecanismo de medição de atraso entre nós vizinhos (Peer delay measurement mechanism)
Este mecanismo também utiliza duas etapas para sincronização:
- Os dispositivos medem o atraso de tempo até todos os vizinhos através de todas as portas. Para isso, eles usam o mecanismo de atraso entre pares (peer delay mechanism).
- Correção do deslocamento do tempo exato.
Medição do atraso entre dispositivos que suportam o modo Peer-to-Peer
O atraso entre as portas que suportam o mecanismo peer-to-peer é medido usando as seguintes mensagens:
Quando a porta 1 conhece os tempos t1, t2, t3 e t4, ela pode calcular o atraso médio (tmld). Isso é calculado pela seguinte fórmula:
Em seguida, a porta usa este valor ao calcular o campo de correção para cada mensagem Sync ou mensagem opcional Follow_Up que passa por este dispositivo.
O atraso final será igual à soma do atraso durante a transmissão através deste dispositivo, do atraso médio durante a transmissão pelo canal de dados e do atraso já contido nesta mensagem, incluída em dispositivos superiores.
As mensagens Pdelay_Req, Pdelay_Resp e o opcional Pdelay_Resp_Follow_Up permitem obter a latência do mestre para o escravo e do escravo para o mestre (circular).
Qualquer assimetria entre esses dois valores introduzirá um erro na correção do desvio do tempo preciso.
Correção do desvio do tempo preciso
Os relógios escravos utilizam a mensagem Sync e a mensagem opcional Follow_Up para calcular o desvio do tempo preciso ao transmitir pacotes dos relógios mestres para os escravos. O desvio é calculado pela seguinte fórmula:
As vantagens do mecanismo de correção peer-to-peer – o tempo de latência de cada mensagem Sync ou Follow_Up é calculado ao longo de sua transmissão pela rede. Assim, mudanças na rota de transmissão não afetarão de forma alguma a precisão da correção.
Ao usar esse mecanismo, a sincronização do tempo não requer o cálculo da latência do caminho percorrido pelo pacote de sincronização, como é feito no intercâmbio básico. Ou seja, as mensagens Delay_Req e Delay_Resp não são enviadas. Nesse método, a latência entre os relógios mestres e escravos é simplesmente somada no campo de correção de cada mensagem Sync ou Follow_Up.
Outra vantagem – os relógios mestres são descarregados da necessidade de processar mensagens Delay_Req.
Modos de operação dos relógios transparentes
Consequentemente, foram analisados exemplos simples. Agora, suponha que switches apareçam no caminho da sincronização.
Se forem utilizados switches sem suporte a PTPv2, o pacote de sincronização será atrasado no switch por cerca de 10 μs.
Switches com suporte a PTPv2 na terminologia IEEE 1588v2 são chamados de relógios transparentes. Os relógios transparentes não são sincronizados com os relógios mestres e não participam da hierarquia 'Relógios Mestres – Relógios Escravos', mas ao transmitir mensagens de sincronização, lembram-se de quanto tempo a mensagem foi atrasada neles. Isso permite corrigir a latência do tempo.
Os relógios transparentes podem operar em dois modos:
- End-to-End.
- Peer-to-Peer.
End-to-End (E2E)
Os relógios transparentes E2E transmitem mensagens Sync e mensagens associadas Follow_Up para todas as portas. Mesmo para aquelas bloqueadas por protocolos (como RSTP).
O comutador registra o carimbo de data/hora quando o pacote Sync (Follow_Up) foi recebido na porta e quando foi enviado da porta. Com base nessas duas marcas de tempo, calcula-se o tempo de processamento da mensagem pelo comutador. No padrão, esse tempo é chamado de tempo de residência.
O tempo de processamento é adicionado ao campo correctionField da mensagem Sync (relógios de uma etapa) ou Follow_Up (relógios de duas etapas).
Os relógios transparentes E2E medem o tempo de processamento para mensagens Sync e Delay_Req que passam pelo comutador. No entanto, é importante entender que a latência entre os relógios mestres e escravos é calculada usando um mecanismo de solicitação-resposta de atraso. Se os relógios mestres mudarem ou se o caminho entre os relógios mestres e escravos mudar, a latência é medida novamente. Isso aumenta o tempo de transição em caso de mudanças na rede.
Os relógios transparentes P2P, além de medir o tempo de processamento da mensagem pelo comutador, medem a latência no canal de comunicação até o vizinho mais próximo, usando o mecanismo de medição de latência do nó vizinho.
A latência é medida em cada canal em ambas as direções, incluindo canais que estão bloqueados por algum protocolo (por exemplo, RSTP). Isso permite calcular imediatamente a nova latência no caminho de sincronização, caso os relógios mestres ou a topologia da rede sejam alterados.
O tempo de processamento das mensagens pelos comutadores e o tempo de latência são acumulados durante a transferência das mensagens Sync ou Follow_Up.
Tipos de suporte PTPv2 pelos comutadores
Os comutadores podem suportar PTPv2:
- por software;
- por hardware.
Na implementação do protocolo PTPv2 por software, o comutador solicita o carimbo de data/hora do firmware. O problema é que o firmware opera ciclicamente, e será necessário esperar até que ele termine o ciclo atual, processe a solicitação e, após o próximo ciclo, forneça o carimbo de data/hora. Isso também levará tempo, resultando em latência, embora não tão significativa quanto a falta de suporte por software para PTPv2.
Apenas o suporte por hardware para PTPv2 permite cumprir a precisão necessária. Nesse caso, a emissão do carimbo de data/hora é realizada por um ASIC especial, que está instalado na porta.
Formato da mensagem
Todas as mensagens PTP consistem nos seguintes campos:
- Header – 34 bytes.
- Body – o tamanho depende do tipo de mensagem.
- Suffix – opcional.
Header
O campo Header é o mesmo para todas as mensagens PTP. Seu tamanho é de 34 bytes.
Formato do campo Header:
messageType – contém o tipo de mensagem transmitida, como Sync, Delay_Req, PDelay_Req, etc.
messageLength – contém o tamanho total da mensagem PTP, incluindo header, body e suffix (mas excluindo os bytes de preenchimento).
domainNumber – define a que domínio PTP pertence a mensagem.
Domínio – é um conjunto de diferentes relógios reunidos em um único grupo lógico e sincronizados a partir de um relógio mestre, mas não necessariamente sincronizados com relógios pertencentes a outro domínio.
flags – este campo contém vários flags para identificar o status da mensagem.
correctionField – contém o tempo de atraso em nanosegundos. O tempo de atraso inclui o atraso na transmissão através de relógios transparentes, bem como o atraso na transmissão através do canal no modo Peer-to-Peer.
sourcePortIdentity – este campo contém informações sobre de qual porta a mensagem foi originalmente enviada.
sequenceID – contém um número de identificação para mensagens individuais.
controlField – campo de artefato =) Ele permanece da primeira versão do padrão e contém informações sobre o tipo desta mensagem. Essencialmente, é o mesmo que messageType, mas com menos opções.
logMessageInterval – este campo é determinado pelo tipo de mensagem.
Corpo
Como discutido acima, existem vários tipos de mensagens. Esses tipos são descritos abaixo:
Mensagem Announce
A mensagem Announce é utilizada para "informar" outros relógios dentro de um mesmo domínio sobre seus parâmetros. Esta mensagem permite estabelecer a hierarquia "Relógio Mestre – Relógios Escravos".
Mensagem Sync
A mensagem de sincronização (Sync) é enviada pelos relógios mestres e contém a hora do relógio mestre no momento em que a mensagem Sync foi criada. Se os relógios mestres forem de dois estágios, o timestamp na mensagem Sync será definido para 0, e o timestamp real será enviado na mensagem associada Follow_Up. A mensagem Sync é utilizada para ambos os mecanismos de medição de atraso.
A mensagem é transmitida usando Multicast. Opcionalmente, pode-se usar Unicast.
Mensagem Delay_Req
O formato da mensagem Delay_Req é idêntico ao da mensagem Sync. Os relógios escravos enviam Delay_Req. Ela contém a hora do envio do Delay_Req pelos relógios escravos. Esta mensagem é usada apenas para o mecanismo de pedido-resposta de atraso.
A mensagem é transmitida usando Multicast. Opcionalmente, pode-se usar Unicast.
Mensagem Follow_Up
A mensagem Follow_Up pode ser enviada opcionalmente por relógios mestres e contém o horário de envio mensagens Sync mestre. A mensagem Follow_Up é enviada apenas por relógios mestres de duas etapas.
A mensagem Follow_Up é utilizada para ambos os mecanismos de medição de latência.
A mensagem é transmitida usando Multicast. Opcionalmente, pode-se usar Unicast.
Mensagem Delay_Resp
A mensagem Delay_Resp é enviada pelos relógios mestres. Ela contém o horário de recebimento do Delay_Req pelos relógios mestres. Esta mensagem é usada apenas para o mecanismo de solicitação-resposta de latência.
A mensagem é transmitida usando Multicast. Opcionalmente, pode-se usar Unicast.
Mensagem Pdelay_Req
A mensagem Pdelay_Req é enviada pelo dispositivo que solicita a latência. Ela contém o horário de envio da mensagem a partir da porta deste dispositivo. Pdelay_Req é usada apenas para o mecanismo de medição de latência do nó vizinho.
Mensagem Pdelay_Resp
A mensagem Pdelay_Resp é enviada pelo dispositivo que recebeu a solicitação de latência. Ela contém o horário de recebimento da mensagem Pdelay_Req por este dispositivo. As mensagens Pdelay_Resp são usadas apenas para o mecanismo de medição de latência do nó vizinho.
Mensagem Pdelay_Resp_Follow_Up
A mensagem Pdelay_Resp_Follow_Up é enviada opcionalmente pelo dispositivo que recebeu a solicitação de latência. Ela contém o horário de recebimento da mensagem Pdelay_Req por este dispositivo. A mensagem Pdelay_Resp_Follow_Up é enviada apenas por relógios mestres de duas etapas.
Além disso, esta mensagem pode ser usada para o tempo de execução em vez de um carimbo de data/hora. O tempo de execução é o período entre o recebimento do Pdelay-Req e o envio do Pdelay_Resp.
Pdelay_Resp_Follow_Up é usado apenas para o mecanismo de medição de latência do nó vizinho.
Mensagens de Controle (Mensagem Management)
Mensagens de controle PTP são necessárias para transmitir informações entre um ou mais relógios e o nó de controle.
Transmissão em LV
A mensagem PTP pode ser transmitida em dois níveis:
- De rede – dentro de dados IP.
- De enlace – dentro de um quadro Ethernet.
Transmissão da mensagem PTP via UDP através de IP via Ethernet
PTP via UDP através de 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 anteriormente termos dito que os dispositivos PTPv2 são compatíveis entre si, na verdade isso não é bem assim. Os dispositivos devem ter as mesmas configurações para interagir.
Assim, existem os chamados perfis PTPv2. Os perfis são grupos de configurações configuradas e restrições definidas do protocolo, permitindo a implementação da sincronização de tempo para uma aplicação específica.
O padrão IEEE 1588v2 descreve apenas um perfil – o “Perfil Padrão”. Todos os outros perfis foram criados e descritos por várias organizações e associações.
Por exemplo, o perfil para energia elétrica ou PTPv2 Power Profile foi criado pelo comitê Power Systems Relaying Committee e pelo comitê Substation Committee da sociedade IEEE Power and Energy Society. O perfil é 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 multicast.
- Como mecanismo de medição de latência, utiliza-se o mecanismo de medição de atraso entre pares.
O domínio padrão é 0, e o domínio recomendado é 93.
A filosofia por trás da criação do C37.238-2011 é a redução do número de características opcionais, deixando apenas as funções necessárias para uma interação confiável entre dispositivos e aumentando a estabilidade do sistema.
Além disso, foi definida a frequência de transmissão de mensagens:
Na verdade, apenas um parâmetro está disponível para escolha – o tipo de relógios mestre (monofásicos ou bifásicos).
A precisão deve ser de no máximo 1 µs. Em outras palavras, em um único caminho de sincronização, podem estar contidos no máximo 15 relógios transparentes ou três relógios de fronteira.
Fonte: habr.com
