Detalles da implantación do protocolo de sincronización horaria PTPv2

Introdución

O concepto de construción dunha "subestación dixital" na industria da enerxía eléctrica require sincronización cunha precisión de 1 μs. As transaccións financeiras tamén requiren precisión de microsegundos. Nestas aplicacións, a precisión do tempo NTP xa non é suficiente.

O protocolo de sincronización PTPv2, descrito polo estándar IEEE 1588v2, permite unha precisión de sincronización de varias decenas de nanosegundos. PTPv2 permítelle enviar paquetes de sincronización a través de redes L2 e L3.

As principais áreas onde se utiliza PTPv2 son:

• enerxía;
• equipos de control e medida;
• complexo militar-industrial;
• telecomunicacións;
• sector financeiro.

Esta publicación explica como funciona o protocolo de sincronización PTPv2.

Temos máis experiencia na industria e moitas veces vemos este protocolo en aplicacións enerxéticas. En consecuencia, faremos a revisión con precaución para a enerxía.

Por que é necesario?

Polo momento, o STO 34.01-21-004-2019 de PJSC Rosseti e o STO 56947007-29.240.10.302-2020 de PJSC FGC UES conteñen requisitos para organizar un bus de procesos con sincronización horaria mediante PTPv2.

Isto débese ao feito de que os terminais de protección de relés e os dispositivos de medida están conectados ao bus de proceso, que transmiten valores instantáneos de corrente e tensión a través do bus de proceso, utilizando os chamados fluxos SV (fluxos multicast).

Os terminais de protección de relés usan estes valores para implementar a protección da bahía. Se a precisión das medicións do tempo é pequena, algunhas proteccións poden funcionar incorrectamente.

Por exemplo, as defensas da selectividade absoluta poden ser vítimas dunha sincronización horaria "débil". Moitas veces a lóxica de tales defensas baséase nunha comparación de dúas cantidades. Se os valores diverxen nun valor suficientemente grande, a protección activarase. Se estes valores se miden cunha precisión de tempo de 1 ms, pode obter unha gran diferenza onde os valores son realmente normais se se miden cunha precisión de 1 μs.

Versións PTP

O protocolo PTP foi descrito orixinalmente en 2002 no estándar IEEE 1588-2002 e chamábase "Estándar para un protocolo de sincronización de reloxos de precisión para sistemas de control e medición en rede". En 2008, lanzouse o estándar IEEE 1588-2008 actualizado, que describe a versión 2 de PTP. Esta versión do protocolo mellorou a precisión e a estabilidade, pero non mantivo a compatibilidade con versións anteriores coa primeira versión do protocolo. Ademais, en 2019, lanzouse unha versión do estándar IEEE 1588-2019, que describe PTP v2.1. Esta versión engade pequenas melloras a PTPv2 e é compatible con PTPv2.

Noutras palabras, temos a seguinte imaxe con versións:

PTPv1
(IEEE 1588-2002)

PTPv2
(IEEE 1588-2008)

PTPv2.1
(IEEE 1588-2019)

PTPv1 (IEEE 1588-2002)

-
Incompatible

Incompatible

PTPv2 (IEEE 1588-2008)

Incompatible

-
Compatible

PTPv2.1 (IEEE 1588-2019)

Incompatible

Compatible

-

Pero, coma sempre, hai matices.

A incompatibilidade entre PTPv1 e PTPv2 significa que un dispositivo compatible con PTPv1 non poderá sincronizarse cun reloxo preciso que se executa en PTPv2. Usan diferentes formatos de mensaxes para sincronizar.

Pero aínda é posible combinar dispositivos con PTPv1 e dispositivos con PTPv2 na mesma rede. Para conseguilo, algúns fabricantes permítenche seleccionar a versión do protocolo nos portos de reloxo de bordo. É dicir, un reloxo de límite pode sincronizarse usando PTPv2 e aínda sincronizar outros reloxos conectados a el usando tanto PTPv1 como PTPv2.

Dispositivos PTP. Que son e en que se diferencian?

O estándar IEEE 1588v2 describe varios tipos de dispositivos. Todos eles aparecen na táboa.

Os dispositivos comunícanse entre si a través dunha LAN mediante PTP.

Os dispositivos PTP chámanse reloxos. Todos os reloxos toman a hora exacta do reloxo do gran mestre.

Hai 5 tipos de reloxos:

Gran mestre reloxo

A principal fonte de tempo preciso. Moitas veces equipado cunha interface para conectar GPS.

Reloxo ordinario

Un dispositivo de porto único que pode ser mestre (reloxo mestre) ou escravo (reloxo escravo)

Reloxo mestre (mestre)

Son a fonte da hora exacta coa que se sincronizan outros reloxos

Reloxo escravo

Dispositivo final que está sincronizado desde o reloxo mestre

Reloxo de límite

Un dispositivo con varios portos que pode ser mestre ou escravo.

É dicir, estes reloxos poden sincronizarse desde o reloxo mestre superior e sincronizar os reloxos escravos inferiores.

Reloxo transparente de extremo a extremo

Un dispositivo con varios portos que non é nin un reloxo mestre nin un escravo. Transmite datos PTP entre dous reloxos.

Ao transmitir datos, o reloxo transparente corrixe todas as mensaxes PTP.

A corrección prodúcese engadindo o tempo de atraso deste dispositivo ao campo de corrección da cabeceira da mensaxe transmitida.

Reloxo transparente peer-to-peer

Un dispositivo con varios portos que non é nin un reloxo mestre nin un escravo.
Transmite datos PTP entre dous reloxos.

Ao transmitir datos, o reloxo transparente corrixe todas as mensaxes PTP Sync and Follow_Up (máis información sobre elas a continuación).

A corrección conséguese engadindo ao campo de corrección do paquete transmitido o atraso no dispositivo transmisor e o atraso na canle de transmisión de datos.

Nodo de xestión

Un dispositivo que configura e diagnostica outros reloxos

Os reloxos mestres e escravos sincronízanse mediante marcas de tempo nas mensaxes PTP. Hai dous tipos de mensaxes no protocolo PTP:

• As mensaxes de eventos son mensaxes sincronizadas que implican xerar unha marca de tempo no momento no que se envía a mensaxe e no momento en que se recibe.
• Mensaxes xerais: estas mensaxes non requiren marcas de tempo, pero poden conter marcas de tempo para mensaxes relacionadas

Mensaxes de eventos

Mensaxes xerais

Sincroniza
Delay_Req
Pdelay_Req
Pdelay_Resp

Anunciar
Seguimento
Delay_Resp
Pdelay_Resp_Follow_Up
xestión
Sinalización

Todo tipo de mensaxes comentaranse con máis detalle a continuación.

Problemas básicos de sincronización

Cando un paquete de sincronización se transmite a través dunha rede local, atrasase no switch e na ligazón de datos. Calquera cambio producirá un atraso duns 10 microsegundos, o que é inaceptable para PTPv2. Despois de todo, necesitamos acadar unha precisión de 1 μs no dispositivo final. (Isto é se estamos a falar de enerxía. Outras aplicacións poden requirir maior precisión).

IEEE 1588v2 describe varios algoritmos operativos que permiten rexistrar o atraso de tempo e corrixilo.

Algoritmo de traballo
Durante o funcionamento normal, o protocolo opera en dúas fases.

• Fase 1: establece a xerarquía "Reloxo mestre - Reloxo escravo".
• Fase 2: sincronización do reloxo mediante un mecanismo end-to-end ou peer-to-peer.

Fase 1 - Establecemento da xerarquía mestre-escravo

Cada porto dun reloxo regular ou de bordo ten un determinado número de estados (reloxo escravo e reloxo mestre). O estándar describe o algoritmo de transición entre estes estados. Na programación, tal algoritmo chámase máquina de estados finitos ou máquina de estados (máis detalles en Wiki).

Esta máquina de estado usa o mellor algoritmo de reloxo mestre (BMCA) para configurar o mestre ao conectar dous reloxos.

Este algoritmo permite que o reloxo asuma as responsabilidades do reloxo do gran mestre cando o reloxo do gran mestre perda o sinal GPS, se desconecta, etc.

As transicións de estado segundo o BMCA resúmense no seguinte diagrama:


A información sobre o reloxo no outro extremo do "fío" envíase nunha mensaxe especial (Anunciar mensaxe). Unha vez recibida esta información, execútase o algoritmo da máquina de estados e faise unha comparación para ver que reloxo é mellor. O porto do mellor reloxo convértese no reloxo mestre.

No seguinte diagrama móstrase unha xerarquía sinxela. Os camiños 1, 2, 3, 4, 5 poden conter un reloxo transparente, pero non participan no establecemento da xerarquía Reloxo mestre - Reloxo esclavo.

Fase 2 - Sincronizar reloxos regulares e de borde

Inmediatamente despois de establecer a xerarquía "Reloxo mestre - Reloxo escravo", comeza a fase de sincronización dos reloxos regulares e de límite.

Para sincronizar, o reloxo mestre envía unha mensaxe que contén unha marca de tempo aos reloxos escravos.

O reloxo mestre pode ser:

• etapa única;
• de dúas etapas.

Os reloxos dunha etapa envían unha mensaxe de sincronización para sincronizar.

Un reloxo de dúas etapas usa dúas mensaxes para a sincronización: Sincronización e Seguimento.

Pódense utilizar dous mecanismos para a fase de sincronización:

• Mecanismo de solicitude-resposta atrasada.
• Mecanismo de medición do retardo entre pares.

En primeiro lugar, vexamos estes mecanismos no caso máis sinxelo: cando non se usan reloxos transparentes.

Mecanismo de solicitude-resposta atrasada

O mecanismo implica dous pasos:

1. Medición do atraso na transmisión dunha mensaxe entre o reloxo mestre e o reloxo escravo. Realízase mediante un mecanismo de solicitude e resposta con atraso.
2. Realízase a corrección da quenda horaria exacta.

Medición de latencia


t1 – Hora de envío da mensaxe de sincronización polo reloxo mestre; t2 – Hora de recepción da mensaxe de sincronización polo reloxo escravo; t3 – Tempo de envío da solicitude de atraso (Delay_Req) ​​polo reloxo escravo; t4 – Hora de recepción Delay_Req polo reloxo mestre.

Cando o reloxo escravo coñece os tempos t1, t2, t3 e t4, pode calcular o atraso medio ao transmitir a mensaxe de sincronización (tmpd). Calcúlase do seguinte xeito:

Ao transmitir unha mensaxe de sincronización e seguimento, calcúlase o retardo do mestre ao escravo: t-ms.

Cando se transmiten mensaxes Delay_Req e Delay_Resp, calcúlase o tempo de atraso do escravo ao mestre - t-sm.

Se se produce algunha asimetría entre estes dous valores, aparece un erro ao corrixir a desviación da hora exacta. O erro é causado polo feito de que o atraso calculado é a media dos atrasos t-ms e t-sm. Se os atrasos non son iguais entre si, non axustaremos o tempo con precisión.

Corrección de quenda horaria

Unha vez que se coñece o retardo entre o reloxo mestre e o reloxo escravo, o reloxo escravo realiza a corrección do tempo.

Os reloxos escravos usan a mensaxe de sincronización e unha mensaxe de seguimento opcional para calcular a compensación horaria exacta ao transmitir un paquete do mestre aos reloxos escravos. O desprazamento calcúlase mediante a seguinte fórmula:

Mecanismo de medición do retardo entre pares

Este mecanismo tamén usa dous pasos para a sincronización:

1. Os dispositivos miden o atraso de tempo a todos os veciños a través de todos os portos. Para iso usan un mecanismo de atraso entre pares.
2. Corrección da quenda horaria exacta.

Medición da latencia entre dispositivos que admiten o modo Peer-to-Peer

A latencia entre os portos que admiten o mecanismo peer-to-peer mídese mediante as seguintes mensaxes:

Cando o porto 1 coñece os tempos t1, t2, t3 e t4, pode calcular o atraso medio (tmld). Calcúlase mediante a seguinte fórmula:

A continuación, o porto usa este valor ao calcular o campo de axuste para cada mensaxe de sincronización ou mensaxe de seguimento opcional que pasa polo dispositivo.

O atraso total será igual á suma do atraso durante a transmisión a través deste dispositivo, o atraso medio durante a transmisión a través da canle de datos e o atraso xa contido nesta mensaxe, habilitado nos dispositivos upstream.

As mensaxes Pdelay_Req, Pdelay_Resp e Pdelay_Resp_Follow_Up opcional permítenche obter o atraso de mestre a escravo e de escravo a mestre (circular).

Calquera asimetría entre estes dous valores introducirá un erro de corrección de compensación de tempo.

Axustar o cambio horario exacto

Os reloxos escravos usan unha mensaxe de sincronización e unha mensaxe de seguimento opcional para calcular a compensación horaria exacta ao transmitir un paquete do mestre aos reloxos escravos. O desprazamento calcúlase mediante a seguinte fórmula:

Vantaxes axuste do mecanismo peer-to-peer: o atraso de cada mensaxe Sync ou Follow_Up calcúlase a medida que se transmite na rede. En consecuencia, cambiar o camiño de transmisión non afectará de ningún xeito á precisión do axuste.

Cando se utiliza este mecanismo, a sincronización horaria non require calcular o retardo de tempo ao longo do camiño percorrido polo paquete de sincronización, como se fai no intercambio básico. Eses. As mensaxes Delay_Req e Delay_Resp non se envían. Neste método, o retardo entre os reloxos mestre e escravo simplemente sumase no campo de axuste de cada mensaxe de sincronización ou seguimento.

Outra vantaxe é que o reloxo mestre está aliviado da necesidade de procesar as mensaxes Delay_Req.

Modos de funcionamento dos reloxos transparentes

En consecuencia, estes foron exemplos sinxelos. Supoña agora que aparecen interruptores na ruta de sincronización.

Se usa conmutadores sen compatibilidade con PTPv2, o paquete de sincronización atrasarase no conmutador aproximadamente 10 μs.

Os interruptores que admiten PTPv2 chámanse reloxos transparentes na terminoloxía IEEE 1588v2. Os reloxos transparentes non están sincronizados co reloxo mestre e non participan na xerarquía "Reloxo mestre - Reloxo esclavo", pero ao transmitir mensaxes de sincronización lembran canto tempo foi atrasado por eles. Isto permítelle axustar o atraso de tempo.

Os reloxos transparentes poden funcionar en dous modos:

• De punta a punta.
• Entre iguais.

De extremo a extremo (E2E)

O reloxo transparente E2E emite mensaxes de sincronización e as mensaxes de seguimento acompañantes en todos os portos. Incluso aqueles que están bloqueados por algúns protocolos (por exemplo, RSTP).

O interruptor lembra a marca de tempo cando se recibiu un paquete de sincronización (Follow_Up) no porto e cando se enviou desde o porto. En base a estas dúas marcas de tempo, calcúlase o tempo que tarda o cambio en procesar a mensaxe. Na norma, este tempo chámase tempo de residencia.

O tempo de procesamento engádese ao campo correctionField da mensaxe Sync (reloxo dun paso) ou Follow_Up (reloxo de dous pasos).

O reloxo transparente E2E mide o tempo de procesamento das mensaxes Sync e Delay_Req que pasan polo interruptor. Pero é importante entender que o atraso de tempo entre o reloxo mestre e o reloxo escravo calcúlase mediante o mecanismo de solicitude-resposta de atraso. Se cambia o reloxo mestre ou cambia o camiño desde o reloxo mestre ata o reloxo escravo, o atraso volve medirse. Isto aumenta o tempo de transición en caso de cambios na rede.

O reloxo transparente P2P, ademais de medir o tempo que tarda un interruptor en procesar unha mensaxe, mide o atraso da ligazón de datos ao seu veciño máis próximo mediante un mecanismo de latencia de veciño.

A latencia mídese en cada ligazón en ambas direccións, incluídas as que están bloqueadas por algún protocolo (como RSTP). Isto permítelle calcular inmediatamente o novo atraso na ruta de sincronización se o reloxo do gran mestre ou a topoloxía da rede cambia.

O tempo de procesamento de mensaxes mediante interruptores e a latencia acumúlase ao enviar mensaxes de sincronización ou seguimento.

Tipos de compatibilidade con PTPv2 mediante switches

Os interruptores poden soportar PTPv2:

• programáticamente;
• hardware.

Ao implementar o protocolo PTPv2 no software, o interruptor solicita unha marca de tempo do firmware. O problema é que o firmware funciona cíclicamente, e terás que esperar ata que remate o ciclo actual, acepte a solicitude de procesamento e emita unha marca de tempo despois do seguinte ciclo. Isto tamén levará tempo, e teremos un atraso, aínda que non tan significativo como sen soporte de software para PTPv2.

Só o soporte de hardware para PTPv2 permite manter a precisión necesaria. Neste caso, o selo de tempo é emitido por un ASIC especial instalado no porto.

Formato da mensaxe

Todas as mensaxes PTP constan dos seguintes campos:

• Cabeceira: 34 bytes.
• O tamaño do corpo depende do tipo de mensaxe.
• O sufixo é opcional.

Cabeceira

O campo Cabeceira é o mesmo para todas as mensaxes PTP. O seu tamaño é de 34 bytes.

Formato de campo de cabeceira:

tipo de mensaxe – contén o tipo de mensaxe que se está a transmitir, por exemplo, Sync, Delay_Req, PDelay_Req, etc.

lonxitude da mensaxe – contén o tamaño completo da mensaxe PTP, incluíndo a cabeceira, o corpo e o sufixo (pero excluíndo os bytes de recheo).

número de dominio – determina a que dominio PTP pertence a mensaxe.

Домен - son varios reloxos diferentes recollidos nun grupo lóxico e sincronizados desde un reloxo mestre, pero non necesariamente sincronizados con reloxos pertencentes a un dominio diferente.

bandeiras – Este campo contén varias bandeiras para identificar o estado da mensaxe.

campo de corrección – contén o tempo de atraso en nanosegundos. O tempo de atraso inclúe o atraso cando se transmite a través do reloxo transparente, así como o atraso cando se transmite a través da canle cando se usa o modo Peer-to-Peer.

sourcePortIdentity – este campo contén información sobre o porto dende o que se enviou orixinalmente esta mensaxe.

ID de secuencia – contén un número de identificación para mensaxes individuais.

controlField – campo de artefacto =) Permanece da primeira versión do estándar e contén información sobre o tipo desta mensaxe. Esencialmente o mesmo que MessageType, pero con menos opcións.

logMessageInterval – este campo está determinado polo tipo de mensaxe.

Corpo

Como comentamos anteriormente, hai varios tipos de mensaxes. Estes tipos descríbense a continuación:

Mensaxe de anuncio
A mensaxe Anunciar úsase para "informar" a outros reloxos do mesmo dominio sobre os seus parámetros. Esta mensaxe permítelle configurar unha xerarquía Reloxo mestre - Reloxo esclavo.


Sincronizar mensaxe
A mensaxe de sincronización envía o reloxo mestre e contén a hora do reloxo mestre no momento en que se xerou a mensaxe de sincronización. Se o reloxo mestre é de dúas etapas, entón a marca de tempo da mensaxe de sincronización establecerase en 0 e a marca de tempo actual enviarase na mensaxe de seguimento asociada. A mensaxe de sincronización úsase para ambos os mecanismos de medición da latencia.

A mensaxe transmítese mediante Multicast. Opcionalmente, pode usar Unicast.

Mensaxe Delay_Req

O formato da mensaxe Delay_Req é idéntico ao da mensaxe de sincronización. O reloxo escravo envía Delay_Req. Contén a hora en que o Delay_Req foi enviado polo reloxo escravo. Esta mensaxe úsase só para o mecanismo de solicitude e resposta de atraso.

A mensaxe transmítese mediante Multicast. Opcionalmente, pode usar Unicast.

Mensaxe de seguimento

A mensaxe Follow_Up é opcionalmente enviada polo reloxo mestre e contén a hora do envío Sincronizar mensaxes mestre. Só os reloxos mestres de dúas etapas envían a mensaxe Follow_Up.

A mensaxe Follow_Up úsase para ambos os mecanismos de medición da latencia.

A mensaxe transmítese mediante Multicast. Opcionalmente, pode usar Unicast.

Mensaxe Delay_Resp

O reloxo mestre envía a mensaxe Delay_Resp. Contén a hora na que o reloxo mestre recibiu o Delay_Req. Esta mensaxe úsase só para o mecanismo de solicitude e resposta de atraso.

A mensaxe transmítese mediante Multicast. Opcionalmente, pode usar Unicast.

Mensaxe Pdelay_Req

A mensaxe Pdelay_Req é enviada por un dispositivo que solicita un atraso. Contén a hora en que se enviou a mensaxe desde o porto deste dispositivo. Pdelay_Req só se usa para o mecanismo de medición do atraso dos veciños.

Mensaxe Pdelay_Resp

A mensaxe Pdelay_Resp é enviada por un dispositivo que recibiu unha solicitude de atraso. Contén a hora en que este dispositivo recibiu a mensaxe Pdelay_Req. A mensaxe Pdelay_Resp úsase só para o mecanismo de medición do atraso dos veciños.

Mensaxe Pdelay_Resp_Follow_Up

A mensaxe Pdelay_Resp_Follow_Up envía opcionalmente o dispositivo que recibiu a solicitude de atraso. Contén a hora en que este dispositivo recibiu a mensaxe Pdelay_Req. A mensaxe Pdelay_Resp_Follow_Up só se envía mediante reloxos mestres de dúas etapas.

Esta mensaxe tamén se pode usar para o tempo de execución en lugar dunha marca de tempo. O tempo de execución é o tempo desde que se recibe Pdelay-Req ata que se envía Pdelay_Res.

Pdelay_Resp_Follow_Up úsanse só para o mecanismo de medición do atraso dos veciños.

Mensaxes de xestión

As mensaxes de control PTP son necesarias para transferir información entre un ou máis reloxos e o nodo de control.

Transferir a LV

Unha mensaxe PTP pódese transmitir a dous niveis:

• Rede: como parte dos datos IP.
• Canle: como parte dunha trama Ethernet.

Transmisión de mensaxes PTP a través de UDP a través de IP a través de Ethernet

PTP sobre UDP sobre Ethernet

Perfís

PTP ten moitos parámetros flexibles que deben configurarse. Por exemplo:

• Opcións BMCA.
• Mecanismo de medición da latencia.
• Intervalos e valores iniciais de todos os parámetros configurables, etc.

E a pesar de que anteriormente dixemos que os dispositivos PTPv2 son compatibles entre si, isto non é certo. Os dispositivos deben ter a mesma configuración para poder comunicarse.

Por iso existen os chamados perfís PTPv2. Os perfís son grupos de opcións configuradas e restricións de protocolo definidas para que se poida implementar a sincronización horaria para unha aplicación específica.

O propio estándar IEEE 1588v2 describe só un perfil: "Perfil predeterminado". Todos os demais perfís son creados e descritos por varias organizacións e asociacións.

Por exemplo, o Power Profile, ou PTPv2 Power Profile, foi creado polo Power Systems Relaying Committee e o Substation Committee da IEEE Power and Energy Society. O propio perfil chámase IEEE C37.238-2011.

O perfil describe que PTP se pode transferir:

• Só a través de redes L2 (é dicir, Ethernet, HSR, PRP, non IP).
• As mensaxes son transmitidas só por emisión de multidifusión.
• O mecanismo de medición de retardo de pares úsase como mecanismo de medición de retardo.

O dominio predeterminado é 0, o dominio recomendado é 93.

A filosofía de deseño de C37.238-2011 foi reducir o número de funcións opcionais e manter só as funcións necesarias para unha interacción fiable entre os dispositivos e unha maior estabilidade do sistema.

Ademais, determínase a frecuencia de transmisión da mensaxe:

De feito, só hai un parámetro dispoñible para a selección: o tipo de reloxo mestre (de unha ou dúas etapas).

A precisión non debe ser superior a 1 μs. Noutras palabras, un camiño de sincronización pode conter un máximo de 15 reloxos transparentes ou tres reloxos de límite.

Fonte: www.habr.com