Introducción
La concepción de la «Subestación Digital» en energía eléctrica requiere sincronización con una precisión de 1 µs. También se requiere precisión en microsegundos para realizar transacciones financieras. En estas aplicaciones, la precisión del tiempo NTP ya no es suficiente.
El protocolo de sincronización PTPv2, descrito en el estándar IEEE 1588v2, permite lograr una precisión de sincronización en decenas de nanosegundos. PTPv2 permite enviar paquetes de sincronización a través de redes L2 y L3.
Las principales áreas donde se aplica PTPv2 son:
- energía;
- equipos de control y medición;
- complejo militar-industrial;
- telecomunicaciones;
- sector financiero.
En este post se analiza cómo funciona el protocolo de sincronización PTPv2.
Tenemos más experiencia en la industria y a menudo nos encontramos con este protocolo en aplicaciones energéticas. En consecuencia, haremos una revisión con respecto a .
¿Por qué es necesario?
Actualmente, en la CTO 34.01-21-004-2019 de PJSC «Rosseti» y en la CTO 56947007-29.240.10.302-2020 de PJSC «FSK EES» hay requisitos para la organización del bus de proceso asegurando la sincronización de tiempo a través de PTPv2.
Esto se relaciona con el hecho de que a la bus de proceso se conectan terminales de protección por relés y dispositivos de medición, que a través del bus de proceso, mediante los llamados flujos SV (flujos multicast), transmiten los valores instantáneos de corriente y voltaje.
Los terminales de protección por relés utilizan estos valores para implementar las protecciones de las conexiones. Si la precisión de las mediciones de tiempo es baja, algunas protecciones pueden activarse erróneamente.
Por ejemplo, una víctima de una «síncrona debil» de tiempo pueden ser las protecciones de selectividad absoluta. A menudo, la lógica de estas protecciones se construye comparando dos magnitudes. Si las magnitudes difieren en un valor suficientemente grande, se activa la protección. Si estas magnitudes se miden con una precisión de tiempo de 1 ms, puede resultar en una gran diferencia donde los valores en realidad están en norma, si se miden con una precisión de 1 µs.
Versiones de PTP
El protocolo PTP fue descrito originalmente en 2002 en la norma IEEE 1588-2002 y se denominó "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems". En 2008, se lanzó la norma actualizada IEEE 1588-2008, que describe PTP Versión 2. En esta versión del protocolo se mejoró la precisión y estabilidad, pero no se mantuvo la compatibilidad hacia atrás con la primera versión del protocolo. También, en 2019 se publicó la versión del estándar IEEE 1588-2019, que describe PTP v2.1. Esta versión añade algunas mejoras menores a PTPv2 y es compatible hacia atrás con PTPv2.
En otras palabras, tenemos la siguiente imagen con las versiones:
PTPv1
(IEEE 1588-2002)
PTPv2
(IEEE 1588-2008)
PTPv2.1
(IEEE 1588-2019)
PTPv1 (IEEE 1588-2002)
—
Incompatibles
Incompatibles
PTPv2 (IEEE 1588-2008)
Incompatibles
—
Compatibles
PTPv2.1 (IEEE 1588-2019)
Incompatibles
Compatibles
—
Pero, como siempre, hay matices.
La incompatibilidad entre PTPv1 y PTPv2 implica que un dispositivo que soporte PTPv1 no podrá sincronizarse con relojes precisos que operen en PTPv2. Para la sincronización utilizan diferentes formatos de mensaje.
Sin embargo, es posible combinar dispositivos con PTPv1 y dispositivos con PTPv2 en una misma red. Para ello, algunos fabricantes permiten seleccionar la versión del protocolo en los puertos de las relojes de frontera. Es decir, los relojes de frontera pueden sincronizarse mediante PTPv2 y al mismo tiempo sincronizar otros relojes conectados, tanto por PTPv1 como por PTPv2.
Dispositivos PTP. ¿Qué tipos existen y en qué se diferencian?
El estándar IEEE 1588v2 describe varios tipos de dispositivos. Todos ellos se enumeran en la tabla.
Los dispositivos interactúan entre sí a través de LAN, utilizando PTP.
Los dispositivos PTP se denominan relojes. Todos los relojes toman la hora precisa de los relojes maestros.
Hay 5 tipos de relojes:
Grandmaster clock (Relojes maestros)
Fuente principal de tiempo preciso. A menudo vienen equipados con una interfaz para conexión GPS.
Ordinary Clock (Relojes ordinarios)
Dispositivo con un puerto que puede ser maestro (reloj conductor) o esclavo (reloj dependiente)
Relojes maestros
Son la fuente de tiempo preciso, a partir de la cual otros relojes se sincronizan
Relojes esclavos
Dispositivo final que se sincroniza desde los relojes maestros
Boundary Clock (Relojes de frontera)
Dispositivo con múltiples puertos que puede ser maestro o esclavo.
Esto significa que estos relojes pueden sincronizarse desde relojes maestros superiores y sincronizar relojes esclavos inferiores.
Reloj Transparente de Extremo a Extremo
Dispositivo con múltiples puertos que no es un reloj maestro ni esclavo. Transfiere datos PTP entre dos relojes.
Al transferir datos, los relojes transparentes corrigen todos los mensajes PTP.
La corrección se logra añadiendo tiempo de retardo en este dispositivo en el campo de corrección del encabezado del mensaje transmitido.
Reloj Transparente Peer-to-Peer
Dispositivo con múltiples puertos que no es un reloj maestro ni esclavo.
Transfiere datos PTP entre dos relojes.
Al transferir datos, los relojes transparentes corrigen todos los mensajes PTP Sync y Follow_Up.
La corrección se logra añadiendo el retardo del dispositivo transmisor y el retardo del canal de transmisión al campo de corrección del paquete transmitido.
Nodo de Gestión
Dispositivo que configura y diagnostica otros relojes.
Los relojes maestros y esclavos se sincronizan mediante marcas de tiempo en los mensajes PTP. Hay dos tipos de mensajes en el protocolo PTP:
- Mensajes de Evento: son mensajes sincronizados que implican la generación de una marca de tiempo en el momento del envío del mensaje y en el momento de su recepción.
- Mensajes Generales: estos mensajes no requieren marcas de tiempo, pero pueden contener marcas de tiempo para mensajes relacionados.
Mensajes de Evento
Mensajes Generales
Sync
Delay_Req
Pdelay_Req
Pdelay_Resp
Anunciar
Follow_Up
Delay_Resp
Pdelay_Resp_Follow_Up
Gestión
Señalización
A continuación, se revisarán todos los tipos de mensajes con más detalle.
Principales problemas de sincronización
Al enviar un paquete de sincronización a través de una red local, se retrasa en el conmutador y en el canal de transmisión de datos. Cualquier conmutador proporcionará un retraso de alrededor de 10 microsegundos, lo cual es inaceptable para PTPv2. Necesitamos obtener una precisión de 1 microsegundo en el dispositivo final. (Esto es si se trata de energía. Otras aplicaciones pueden requerir aún más precisión.)
En IEEE 1588v2 se describen varios algoritmos de operación que permiten medir y corregir el retardo de tiempo.
Algoritmo de funcionamiento
En operación normal, el protocolo trabaja en dos fases.
- Fase 1: Establecimiento de la jerarquía 'Relojes Maestros - Relojes Esclavos'.
- Fase 2: Sincronización de los relojes mediante el mecanismo de Extremo a Extremo o Peer-to-Peer.
Fase 1 — Instalación de la jerarquía 'Maestro-Esclavo'
Cada puerto de relojes comunes o de borde tiene un número específico de estados (reloj esclavo y reloj maestro). El estándar describe el algoritmo de transición entre estos estados. En programación, tal algoritmo se llama autómata finito o máquina de estados (más detalles en Wiki).
Este autómata finito utiliza el algoritmo Best Master Clock Algorithm (BMCA) para establecer el maestro al conectar dos relojes.
Este algoritmo permite que los relojes asuman las responsabilidades de los relojes grandmasters cuando los relojes grandmasters superiores pierden la señal GPS, se desconectan de la red, etc.
Las transiciones entre estados según el BMCA se representan brevemente en el siguiente esquema:
La información sobre el reloj en el otro extremo del 'cable' se envía en un mensaje especial (mensaje Anuncio). Cuando se recibe esta información, el algoritmo de la máquina de estados trabaja y se compara cuál reloj es mejor. El puerto en los mejores relojes se convierte en el reloj maestro.
La jerarquía simple se presenta en el esquema a continuación. Las rutas 1, 2, 3, 4, 5 pueden contener relojes transparentes (Reloj transparente), pero no participan en el establecimiento de la jerarquía 'Relojes Maestros – Relojes Esclavos'.
Fase 2 — Sincronización de relojes comunes y de borde
Justo después de establecer la jerarquía 'Relojes Maestros – Relojes Esclavos' comienza la fase de sincronización de los relojes comunes y de borde.
Para sincronizar, los relojes maestros envían a los relojes esclavos un mensaje que contiene una marca de tiempo.
Los relojes maestros pueden ser:
- monofásicos;
- bifásicos.
Los relojes monofásicos envían un solo mensaje Sync para la sincronización.
Los relojes bifásicos utilizan dos mensajes para la sincronización: Sync y Follow_Up.
Para la fase de sincronización se pueden utilizar dos mecanismos:
- Mecanismo de solicitud-respuesta de retraso (Delay request-response mechanism).
- Mecanismo de medición de retraso del nodo vecino (Peer delay measurement mechanism).
Comencemos considerando estos mecanismos en el caso más sencillo: cuando no se utilizan relojes transparentes.
Mecanismo de solicitud-respuesta de retraso (Delay request-response mechanism)
El mecanismo implica dos pasos:
- Medición del retraso en la transmisión del mensaje entre los relojes maestros y esclavos. Se realiza mediante el mecanismo de solicitud-respuesta de retraso.
- Se realiza la corrección del desplazamiento del tiempo exacto.
Medición del retraso
t1 – Hora de envío del mensaje Sync de los relojes principales; t2 – Hora de recepción del mensaje Sync por los relojes secundarios; t3 – Hora de envío de la solicitud de retraso (Delay_Req) por los relojes secundarios; t4 – Hora de recepción de Delay_Req por los relojes principales.
Cuando los relojes secundarios conocen los tiempos t1, t2, t3 y t4, pueden calcular el retraso medio en la transmisión del mensaje de sincronización (tmpd). Se calcula de la siguiente manera:
Al enviar los mensajes Sync y Follow_Up, se calcula el retraso de tiempo desde el maestro al esclavo – t-ms.
Al enviar los mensajes Delay_Req y Delay_Resp, se calcula el retraso de tiempo desde el esclavo al maestro – t-sm.
Si hay alguna asimetría entre estos dos valores, aparece un error de corrección del tiempo exacto. El error se debe a que el retraso calculado es el promedio de los retrasos t-ms y t-sm. Si los retrasos no son iguales, corregiremos el tiempo de manera inexacta.
Corrección del deslizamiento del tiempo exacto
Después de que se conoce el retraso entre los relojes principales y los relojes secundarios, los relojes secundarios realizan la corrección del tiempo.
Los relojes secundarios utilizan el mensaje Sync y el mensaje opcional Follow_Up para calcular el deslizamiento del tiempo exacto al transmitir el paquete de los relojes principales a los relojes secundarios. El deslizamiento se calcula según la siguiente fórmula:
Mecanismo de medición de retraso de nodo vecino (Peer delay measurement mechanism)
Este mecanismo también utiliza dos pasos para la sincronización:
- Los dispositivos miden el retraso de tiempo hacia todos los vecinos a través de todos los puertos. Para esto, utilizan el mecanismo de retraso de par.
- Corrección del deslizamiento del tiempo exacto.
Medición del retraso entre dispositivos que soportan el modo Par-a-Par
El retraso entre los puertos que soportan el mecanismo de par-a-par se mide utilizando los siguientes mensajes:
Cuando al puerto 1 se le conoce el tiempo t1, t2, t3 y t4, puede calcular el retraso medio (tmld). Se calcula según la siguiente fórmula:
Luego, el puerto utiliza este valor al calcular el campo de corrección para cada mensaje Sync o el mensaje opcional Follow_Up que pasa por este dispositivo.
El retraso total será igual a la suma del retraso al pasar por este dispositivo, el retraso medio al pasar por el canal de datos y el retraso ya contenido en este mensaje, incluido en los dispositivos ascendentes.
Los mensajes Pdelay_Req, Pdelay_Resp y el opcional Pdelay_Resp_Follow_Up permiten obtener la latencia del maestro al esclavo y del esclavo al maestro (circular).
Cualquier asimetría entre estos dos valores introducirá un error en la corrección del desfase de tiempo preciso.
Corrección del desfase de tiempo preciso
Los relojes esclavos utilizan el mensaje Sync y el mensaje opcional Follow_Up para calcular el desfase de tiempo preciso durante la transmisión del paquete desde los relojes maestros a los esclavos. El desfase se calcula con la siguiente fórmula:
Una de las ventajas del mecanismo de corrección peer-to-peer es que la latencia de cada mensaje Sync o Follow_Up se calcula a medida que se transmite en la red. Por consiguiente, el cambio en la ruta de transmisión no afectará en absoluto la precisión de la corrección.
Al utilizar este mecanismo, la sincronización del tiempo no requiere calcular la latencia del tiempo en la ruta que ha seguido el paquete de sincronización, como se hace en el intercambio básico. Es decir, los mensajes Delay_Req y Delay_Resp no se envían. En este método, la latencia entre los relojes maestros y esclavos simplemente se suma en el campo de corrección de cada mensaje Sync o Follow_Up.
Otra ventaja es que los relojes maestros se liberan de la necesidad de procesar los mensajes Delay_Req.
Modos de operación de los relojes transparentes
Por lo tanto, se han analizado ejemplos simples. Ahora supongamos que en el camino de sincronización aparecen conmutadores.
Si se utilizan conmutadores sin soporte para PTPv2, el paquete de sincronización se retrasará en el conmutador aproximadamente 10 µs.
Los conmutadores con soporte para PTPv2, en la terminología IEEE 1588v2, se denominan relojes transparentes (Transparent clock). Los relojes transparentes no se sincronizan con los relojes maestros y no participan en la jerarquía 'Relojes maestros - Relojes esclavos', pero al transmitir mensajes de sincronización recuerdan cuánto tiempo se retrasó el mensaje en ellos. Esto permite corregir la latencia de tiempo.
Los relojes transparentes pueden operar en dos modos:
- End-to-End.
- Peer-to-Peer.
End-to-End (E2E)
Los relojes transparentes E2E transmiten mensajes Sync y mensajes asociados Follow_Up a todos los puertos. Incluso a aquellos que están bloqueados por algún protocolo (por ejemplo, RSTP).
El conmutador recuerda la marca de tiempo cuando el paquete Sync (Follow_Up) fue recibido en el puerto y cuando fue enviado desde el puerto. Con base en estas dos marcas de tiempo, se calcula el tiempo de procesamiento del mensaje por parte del conmutador. En el estándar, este tiempo se llama tiempo de residencia.
El tiempo de procesamiento se añade al campo correctionField del mensaje Sync (reloj de una etapa) o Follow_Up (reloj de dos etapas).
Los relojes E2E transparentes miden el tiempo de procesamiento para los mensajes Sync y Delay_Req que pasan a través del conmutador. Sin embargo, es importante entender que la demora entre los relojes maestros y los relojes esclavos se calcula mediante un mecanismo de solicitud-respuesta de demora. Si los relojes maestros cambian o si cambia el camino entre los relojes maestros y esclavos, la demora se mide de nuevo. Esto aumenta el tiempo de transición en caso de cambios en la red.
Los relojes P2P transparentes, además de medir el tiempo de procesamiento del mensaje por parte del conmutador, miden la demora en el canal de transmisión hasta el vecino más cercano, utilizando un mecanismo de medición de demora del nodo adyacente.
La demora se mide en cada canal en ambas direcciones, incluyendo los canales que están bloqueados por algún protocolo (por ejemplo, RSTP). Esto permite calcular de inmediato la nueva demora en el camino de sincronización si cambian los relojes de gran maestro o la topología de la red.
El tiempo de procesamiento de los mensajes por los conmutadores y el tiempo de demora se acumulan al enviar mensajes Sync o Follow_Up.
Tipos de soporte de PTPv2 por parte de los conmutadores
Los conmutadores pueden soportar PTPv2:
- por software;
- por hardware.
En la implementación por software del protocolo PTPv2, el conmutador solicita la marca de tiempo al firmware. El problema es que el firmware opera cíclicamente, y habrá que esperar a que termine su ciclo actual, procese la solicitud y, al final del siguiente ciclo, emita la marca de tiempo. Todo esto también tomará tiempo, y obtendremos una demora, aunque no tan significativa como sin soporte de PTPv2 por software.
Solo el soporte por hardware de PTPv2 permite mantener la precisión necesaria. En este caso, la emisión de la marca de tiempo es realizada por un ASIC especializado instalado en el puerto.
Formato del mensaje
Todos los mensajes PTP consisten en los siguientes campos:
- Header – 34 bytes.
- Body – el tamaño depende del tipo de mensaje.
- Suffix – opcional.
Header
El campo Header es el mismo para todos los mensajes PTP. Su tamaño es de 34 bytes.
Formato del campo Header:
messageType – contiene el tipo de mensaje transmitido, como Sync, Delay_Req, PDelay_Req, etc.
messageLength – contiene el tamaño total del mensaje PTP, incluyendo el header, body y suffix (pero excluyendo los bytes de relleno).
domainNumber – define a qué el dominio PTP pertenece el mensaje.
Dominio – es un conjunto de relojes diferentes, agrupados en una sola lógica y sincronizados a partir de un reloj maestro, pero no necesariamente sincronizados con los relojes de otro dominio.
flags – este campo contiene varios flags para identificar el estado del mensaje.
correctionField – contiene el tiempo de retraso en nanosegundos. El tiempo de retraso incluye la latencia al transmitirse a través de relojes transparentes, así como la latencia de transmisión a través del canal en modo Peer-to-Peer.
sourcePortIdentity – este campo contiene información sobre el puerto desde el que se envió originalmente este mensaje.
sequenceID – contiene el número de identificación para mensajes individuales.
controlField – campo-artefacto =) Se ha mantenido desde la primera versión del estándar y contiene información sobre el tipo de mensaje. Esencialmente, es lo mismo que messageType, pero con menos opciones.
logMessageInterval – este campo se determina por el tipo de mensaje.
Cuerpo
Como se mencionó anteriormente, hay varios tipos de mensajes. Estos tipos se describen a continuación:
Mensaje Announce
El mensaje Announce se utiliza para "informar" a otros relojes dentro de un mismo dominio sobre sus parámetros. Este mensaje permite establecer una jerarquía de "Relojes Maestros - Relojes Esclavos".
Mensaje Sync
El mensaje de sincronización (Sync) es enviado por los relojes maestros y contiene el tiempo del reloj maestro en el momento en que se creó el mensaje Sync. Si los relojes maestros son de dos niveles, la marca de tiempo en el mensaje Sync se igualará a 0, y la marca de tiempo actual se enviará en el mensaje asociado Follow_Up. El mensaje Sync se utiliza para ambos mecanismos de medición de retraso.
El mensaje se transmite mediante Multicast. Opcionalmente, se puede usar Unicast.
Mensaje Delay_Req
El formato del mensaje Delay_Req es idéntico al del mensaje Sync. Los relojes esclavos envían Delay_Req. Contiene el tiempo de envío del Delay_Req por los relojes esclavos. Este mensaje se utiliza únicamente para el mecanismo de solicitud-respuesta de retraso.
El mensaje se transmite mediante Multicast. Opcionalmente, se puede usar Unicast.
Mensaje Follow_Up
El mensaje Follow_Up se envía opcionalmente mediante relojes maestros y contiene la hora de envío mensajes Sync maestro. El mensaje Follow_Up solo lo envían relojes maestros de dos pasos.
El mensaje Follow_Up se utiliza para ambos mecanismos de medición de retardos.
El mensaje se transmite mediante Multicast. Opcionalmente, se puede usar Unicast.
Mensaje Delay_Resp
El mensaje Delay_Resp es enviado por relojes maestros. Contiene la hora de recepción de Delay_Req por parte de los relojes maestros. Este mensaje se utiliza únicamente para el mecanismo de solicitud-respuesta de retardos.
El mensaje se transmite mediante Multicast. Opcionalmente, se puede usar Unicast.
Mensaje Pdelay_Req
El mensaje Pdelay_Req es enviado por el dispositivo que solicita el retardo. Contiene la hora de envío del mensaje desde el puerto de este dispositivo. Pdelay_Req se utiliza solo para el mecanismo de medición de retardo del nodo vecino.
Mensaje Pdelay_Resp
El mensaje Pdelay_Resp es enviado por el dispositivo que recibió la solicitud de retardo. Contiene la hora de recepción del mensaje Pdelay_Req por parte de este dispositivo. Los mensajes Pdelay_Resp se utilizan exclusivamente para el mecanismo de medición de retardo del nodo vecino.
Mensaje Pdelay_Resp_Follow_Up
El mensaje Pdelay_Resp_Follow_Up se envía opcionalmente por el dispositivo que recibió la solicitud de retardo. Contiene la hora de recepción del mensaje Pdelay_Req por este dispositivo. El mensaje Pdelay_Resp_Follow_Up es enviado únicamente por relojes maestros de dos pasos.
Este mensaje también puede utilizarse para el tiempo de ejecución en lugar de la marca de tiempo. El tiempo de ejecución es el tiempo desde que se recibe Pdelay-Req hasta que se envía Pdelay_Resp.
Pdelay_Resp_Follow_Up se utilizan únicamente para el mecanismo de medición de retardo del nodo vecino.
Mensajes de Control (Mensaje Management)
Los mensajes de control PTP son necesarios para transmitir información entre uno o varios relojes y el nodo de control.
Transmisión en LV
El mensaje PTP puede transmitirse en dos niveles:
- Red – como parte de datos IP.
- Enlace – como parte de un marco Ethernet.
Transmisión de mensajes PTP a través de UDP a través de IP a través de Ethernet
PTP a través de UDP a través de Ethernet
Perfiles
PTP tiene bastantes parámetros "flexibles" que necesitan ser configurados. Por ejemplo:
- Opciones BMCA.
- Mecanismo de medición de retardo.
- Intervalos y valores iniciales de todos los parámetros configurables, etc.
Y a pesar de que antes mencionamos que los dispositivos PTPv2 son compatibles entre sí, en realidad no es así. Los dispositivos deben tener configuraciones idénticas para interactuar.
Por lo tanto, existen lo que se llaman perfiles PTPv2. Los perfiles son grupos de configuraciones y restricciones específicas del protocolo, para permitir la sincronización de tiempo para una aplicación particular.
El estándar IEEE 1588v2 describe solo un perfil: el 'Default Profile'. Todos los demás perfiles han sido creados y descritos por diversas organizaciones y asociaciones.
Por ejemplo, el perfil para energía eléctrica o PTPv2 Power Profile fue creado por el comité Power Systems Relaying Committee y el comité Substation Committee de la sociedad IEEE Power and Energy Society. El perfil se llama IEEE C37.238-2011.
El perfil describe que PTP puede ser transmitido:
- Solo a través de redes L2 (es decir, Ethernet, HSR, PRP, no IP).
- Los mensajes se transmiten únicamente por envío Multicast.
- Se utiliza el mecanismo de medición de retardo Peer delay measurement mechanism.
El dominio por defecto es 0, el dominio recomendado es 93.
La filosofía detrás de la creación de C37.238-2011 era reducir el número de características opcionales y mantener solo las funciones necesarias para una interacción confiable entre dispositivos y aumentar la estabilidad del sistema.
Además, se ha definido la frecuencia de transmisión de mensajes:
En esencia, solo hay un parámetro disponible para la selección: tipo de reloj maestro (de un nivel o de dos niveles).
La precisión no debe ser superior a 1 μs. En otras palabras, en un camino de sincronización, pueden incluirse como máximo 15 relojes transparentes o tres relojes límite.
Fuente: habr.com
