introducción
El concepto de construcción de una “Subestación Digital” en la industria de la energía eléctrica requiere una sincronización con una precisión de 1 μs. Las transacciones financieras también requieren una precisión de microsegundos. En estas aplicaciones, la precisión del tiempo NTP ya no es suficiente.
El protocolo de sincronización PTPv2, descrito por el estándar IEEE 1588v2, permite una precisión de sincronización de varias decenas de nanosegundos. PTPv2 le permite enviar paquetes de sincronización a través de redes L2 y L3.
Las principales áreas donde se utiliza PTPv2 son:
- energía;
- equipos de control y medición;
- complejo militar-industrial;
- telecomunicaciones;
- sector financiero.
Esta publicación explica cómo funciona el protocolo de sincronización PTPv2.
Tenemos más experiencia en la industria y a menudo vemos este protocolo en aplicaciones energéticas. En consecuencia, haremos la revisión con precaución. .
¿Por qué es necesario?
Actualmente, STO 34.01-21-004-2019 de PJSC Rosseti y STO 56947007-29.240.10.302-2020 de PJSC FGC UES contienen requisitos para organizar un bus de proceso con sincronización horaria mediante PTPv2.
Esto se debe al hecho de que al bus de proceso están conectados terminales de protección de relés y dispositivos de medición, que transmiten valores instantáneos de corriente y voltaje a través del bus de proceso, utilizando los llamados flujos SV (flujos de multidifusión).
Los terminales de protección de relé utilizan estos valores para implementar la protección de la bahía. Si la precisión de las mediciones de tiempo es pequeña, algunas protecciones pueden funcionar incorrectamente.
Por ejemplo, las defensas de la selectividad absoluta pueden ser víctimas de una sincronización horaria "débil". A menudo, la lógica de tales defensas se basa en una comparación de dos cantidades. Si los valores difieren en un valor suficientemente grande, se activa la protección. Si estos valores se miden con una precisión de tiempo de 1 ms, entonces puede obtener una gran diferencia donde los valores son realmente normales si se miden con una precisión de 1 μs.
Versiones PTP
El protocolo PTP se describió originalmente en 2002 en el estándar IEEE 1588-2002 y se denominó "Estándar para un protocolo de sincronización de reloj de precisión para sistemas de control y medición en red". En 2008, se publicó el estándar IEEE 1588-2008 actualizado, que describe la versión 2 de PTP. Esta versión del protocolo mejoró la precisión y la estabilidad, pero no mantuvo la compatibilidad con versiones anteriores de la primera versión del protocolo. Además, en 2019, se lanzó una versión del estándar IEEE 1588-2019, que describe PTP v2.1. Esta versión agrega mejoras menores a PTPv2 y es compatible con versiones anteriores de PTPv2.
Es decir, tenemos la siguiente imagen con versiones:
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, como siempre, hay matices.
La incompatibilidad entre PTPv1 y PTPv2 significa que un dispositivo habilitado para PTPv1 no podrá sincronizarse con un reloj preciso que se ejecute en PTPv2. Utilizan diferentes formatos de mensajes para sincronizar.
Pero aún es posible combinar dispositivos con PTPv1 y dispositivos con PTPv2 en la misma red. Para lograr esto, algunos fabricantes le permiten seleccionar la versión del protocolo en los puertos de reloj perimetrales. Es decir, un reloj límite puede sincronizarse mediante PTPv2 y aún así sincronizar otros relojes conectados a él mediante PTPv1 y PTPv2.
Dispositivos PTP. ¿Qué son y en qué se diferencian?
El estándar IEEE 1588v2 describe varios tipos de dispositivos. Todos ellos se muestran en la tabla.
Los dispositivos se comunican entre sí a través de una LAN mediante PTP.
Los dispositivos PTP se llaman relojes. Todos los relojes toman la hora exacta del reloj del gran maestro.
Hay 5 tipos de relojes:
reloj gran maestro
La principal fuente de hora exacta. A menudo está equipado con una interfaz para conectar GPS.
Reloj ordinario
Un dispositivo de un solo puerto que puede ser maestro (reloj maestro) o esclavo (reloj esclavo)
Reloj maestro (maestro)
Son la fuente de la hora exacta con la que se sincronizan otros relojes.
reloj esclavo
Dispositivo final que está sincronizado desde el reloj maestro.
Reloj de límites
Un dispositivo con múltiples puertos que puede ser maestro o esclavo.
Es decir, estos relojes pueden sincronizarse desde el reloj maestro superior y sincronizar los relojes esclavos inferiores.
Reloj transparente de extremo a extremo
Un dispositivo con múltiples puertos que no es ni reloj maestro ni esclavo. Transmite datos PTP entre dos relojes.
Al transmitir datos, el reloj transparente corrige todos los mensajes PTP.
La corrección se produce agregando el tiempo de retraso en este dispositivo al campo de corrección en el encabezado del mensaje transmitido.
Reloj transparente punto a punto
Un dispositivo con múltiples puertos que no es ni reloj maestro ni esclavo.
Transmite datos PTP entre dos relojes.
Al transmitir datos, el reloj transparente corrige todos los mensajes PTP Sync y Follow_Up (más sobre ellos a continuación).
La corrección se logra añadiendo al campo de corrección del paquete transmitido el retraso en el dispositivo transmisor y el retraso en el canal de transmisión de datos.
Nodo de gestión
Un dispositivo que configura y diagnostica otros relojes
Los relojes maestro y esclavo se sincronizan mediante marcas de tiempo en mensajes PTP. Hay dos tipos de mensajes en el protocolo PTP:
- Los mensajes de eventos son mensajes sincronizados que implican generar una marca de tiempo en el momento en que se envía el mensaje y en el momento en que se recibe.
- Mensajes generales: estos mensajes no requieren marcas de tiempo, pero pueden contener marcas de tiempo para mensajes relacionados.
Mensajes de eventos
Mensajes generales
Sincronizar
Retraso_Req
Pdelay_Req
Pdelay_Resp
Anunciar
Hacer un seguimiento
Retraso_Resp
Pdelay_Resp_Follow_Up
Administración
Señalización
Todos los tipos de mensajes se analizarán con más detalle a continuación.
Problemas básicos de sincronización
Cuando un paquete de sincronización se transmite a través de una red local, se retrasa en el conmutador y en el enlace de datos. Cualquier cambio producirá un retraso de aproximadamente 10 microsegundos, lo cual es inaceptable para PTPv2. Después de todo, necesitamos lograr una precisión de 1 μs en el dispositivo final. (Esto es si hablamos de energía. Otras aplicaciones pueden requerir mayor precisión).
IEEE 1588v2 describe varios algoritmos operativos que le permiten registrar el retraso de tiempo y corregirlo.
Algoritmo de trabajo
Durante el funcionamiento normal, el protocolo opera en dos fases.
- Fase 1: establecimiento de la jerarquía “Reloj maestro – Reloj esclavo”.
- Fase 2: sincronización del reloj mediante un mecanismo de extremo a extremo o de igual a igual.
Fase 1: Establecimiento de la jerarquía maestro-esclavo
Cada puerto de un reloj regular o de borde tiene una cierta cantidad de estados (reloj esclavo y reloj maestro). El estándar describe el algoritmo de transición entre estos estados. En programación, dicho algoritmo se denomina máquina de estados finitos o máquina de estados (más detalles en Wiki).
Esta máquina de estado utiliza el algoritmo de mejor reloj maestro (BMCA) para configurar el maestro al conectar dos relojes.
Este algoritmo permite que el reloj asuma las responsabilidades del reloj Grandmaster cuando el reloj Grandmaster ascendente pierde la señal GPS, se desconecta, etc.
Las transiciones de estado según la BMCA se resumen en el siguiente diagrama:
La información sobre el reloj al otro extremo del “cable” se envía en un mensaje especial (mensaje de anuncio). Una vez recibida esta información, se ejecuta el algoritmo de la máquina de estados y se realiza una comparación para ver qué reloj es mejor. El puerto del mejor reloj se convierte en el reloj maestro.
En el siguiente diagrama se muestra una jerarquía simple. Las rutas 1, 2, 3, 4, 5 pueden contener un reloj transparente, pero no participan en el establecimiento de la jerarquía Reloj maestro - Reloj esclavo.
Fase 2: sincronizar los relojes regulares y perimetrales
Inmediatamente después de establecer la jerarquía “Reloj maestro – Reloj esclavo”, comienza la fase de sincronización de los relojes regular y límite.
Para sincronizar, el reloj maestro envía un mensaje que contiene una marca de tiempo a los relojes esclavos.
El reloj maestro puede ser:
- escenario único;
- dos etapas.
Los relojes de una sola etapa envían un mensaje de sincronización para sincronizar.
Un reloj de dos etapas utiliza dos mensajes para la sincronización: Sync y Follow_Up.
Se pueden utilizar dos mecanismos para la fase de sincronización:
- Mecanismo de solicitud-respuesta de retraso.
- Mecanismo de medición del retraso entre pares.
Primero, veamos estos mecanismos en el caso más simple: cuando no se utilizan relojes transparentes.
Mecanismo de solicitud-respuesta de retraso
El mecanismo implica dos pasos:
- Medición del retraso en la transmisión de un mensaje entre el reloj maestro y el reloj esclavo. Realizado mediante un mecanismo de solicitud-respuesta de retraso.
- Se realiza la corrección del cambio de hora exacto.
Medición de latencia
t1 – Hora de envío del mensaje de sincronización por el reloj maestro; t2 – Hora de recepción del mensaje Sync por el reloj esclavo; t3 – Hora de envío de la solicitud de retraso (Delay_Req) por el reloj esclavo; t4 – Tiempo de recepción de Delay_Req por el reloj maestro.
Cuando el reloj esclavo conoce los tiempos t1, t2, t3 y t4, puede calcular el retraso promedio al transmitir el mensaje de sincronización (tmpd). Se calcula de la siguiente manera:
Al transmitir un mensaje Sync y Follow_Up, se calcula el retraso de tiempo del maestro al esclavo: t-ms.
Al transmitir mensajes Delay_Req y Delay_Resp, se calcula el retardo de tiempo del esclavo al maestro: t-sm.
Si se produce alguna asimetría entre estos dos valores, entonces aparece un error al corregir la desviación de la hora exacta. El error se debe al hecho de que el retraso calculado es el promedio de los retrasos t-ms y t-sm. Si los retrasos no son iguales entre sí, no ajustaremos el tiempo con precisión.
Corrección del cambio de hora.
Una vez que se conoce el retraso entre el reloj maestro y el reloj esclavo, el reloj esclavo realiza la corrección de hora.
Los relojes esclavos utilizan el mensaje Sync y un mensaje Follow_Up opcional para calcular el desplazamiento de tiempo exacto al transmitir un paquete desde el reloj maestro al esclavo. El desplazamiento se calcula mediante la siguiente fórmula:
Mecanismo de medición del retraso entre pares
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 ello utilizan un mecanismo de retardo entre pares.
- Corrección del desfase horario exacto.
Medición de latencia entre dispositivos que admiten el modo Peer-to-Peer
La latencia entre los puertos que admiten el mecanismo de igual a igual se mide mediante los siguientes mensajes:
Cuando el puerto 1 conoce los tiempos t1, t2, t3 y t4, puede calcular el retraso promedio (tmld). Se calcula mediante la siguiente fórmula:
Luego, el puerto usa este valor al calcular el campo de ajuste para cada mensaje de sincronización o mensaje de seguimiento opcional que pasa a través del dispositivo.
El retraso total será igual a la suma del retraso durante la transmisión a través de este dispositivo, el retraso medio durante la transmisión a través del canal de datos y el retraso ya contenido en este mensaje, habilitado en los dispositivos upstream.
Los mensajes Pdelay_Req, Pdelay_Resp y opcionales Pdelay_Resp_Follow_Up le permiten obtener el retraso de maestro a esclavo y de esclavo a maestro (circular).
Cualquier asimetría entre estos dos valores introducirá un error de corrección de compensación horaria.
Ajustar el cambio de hora exacto
Los relojes esclavos utilizan un mensaje de sincronización y un mensaje Follow_Up opcional para calcular el desplazamiento de tiempo exacto al transmitir un paquete desde el reloj maestro al esclavo. El desplazamiento se calcula mediante la siguiente fórmula:
Ventajas del ajuste del mecanismo peer-to-peer: el retraso de tiempo de cada mensaje Sync o Follow_Up se calcula a medida que se transmite en la red. En consecuencia, cambiar la ruta de transmisión no afectará de ninguna manera la precisión del ajuste.
Cuando se utiliza este mecanismo, la sincronización horaria no requiere calcular el retardo a lo largo del camino recorrido por el paquete de sincronización, como se hace en el intercambio básico. Aquellos. Los mensajes Delay_Req y Delay_Resp no se envían. En este método, el retraso entre los relojes maestro y esclavo simplemente se suma en el campo de ajuste de cada mensaje Sync o Follow_Up.
Otra ventaja es que el reloj maestro no necesita procesar mensajes Delay_Req.
Modos de funcionamiento de relojes transparentes.
En consecuencia, estos fueron ejemplos simples. Ahora supongamos que aparecen interruptores en la ruta de sincronización.
Si utiliza conmutadores sin compatibilidad con PTPv2, el paquete de sincronización se retrasará en el conmutador aproximadamente 10 μs.
Los conmutadores que admiten PTPv2 se denominan relojes transparentes en la terminología IEEE 1588v2. Los relojes transparentes no se sincronizan desde el reloj maestro y no participan en la jerarquía “Reloj Maestro - Reloj Esclavo”, pero al transmitir mensajes de sincronización recuerdan cuánto tiempo retrasaron el mensaje. Esto le permite ajustar el retraso de tiempo.
Los relojes transparentes pueden funcionar en dos modos:
- De extremo a extremo.
- De igual a igual.
De extremo a extremo (E2E)
El reloj transparente E2E transmite mensajes de sincronización y los mensajes de seguimiento que los acompañan en todos los puertos. Incluso aquellos que están bloqueados por algunos protocolos (por ejemplo, RSTP).
El conmutador recuerda la marca de tiempo cuando se recibió un paquete de sincronización (Follow_Up) en el puerto y cuando se envió desde el puerto. En función de estas dos marcas de tiempo, se calcula el tiempo que tarda el conmutador en procesar el mensaje. En la norma, este tiempo se denomina tiempo de residencia.
El tiempo de procesamiento se agrega al campo CorrectionField del mensaje Sync (reloj de un paso) o Follow_Up (reloj de dos pasos).
El reloj transparente E2E mide el tiempo de procesamiento de los mensajes Sync y Delay_Req que pasan por el conmutador. Pero es importante comprender que el retraso de tiempo entre el reloj maestro y el reloj esclavo se calcula utilizando el mecanismo de solicitud-respuesta de retraso. Si el reloj maestro cambia o la ruta desde el reloj maestro al reloj esclavo cambia, el retraso se mide nuevamente. Esto aumenta el tiempo de transición en caso de cambios de red.
El reloj transparente P2P, además de medir el tiempo que tarda un conmutador en procesar un mensaje, mide el retraso en el enlace de datos con su vecino más cercano utilizando un mecanismo de latencia de vecino.
La latencia se mide en cada enlace en ambas direcciones, incluidos los enlaces que están bloqueados por algún protocolo (como RSTP). Esto le permite calcular inmediatamente el nuevo retraso en la ruta de sincronización si cambia el reloj del gran maestro o la topología de la red.
El tiempo de procesamiento de mensajes por conmutadores y la latencia se acumulan al enviar mensajes Sync o Follow_Up.
Tipos de soporte PTPv2 por parte de los conmutadores
Los conmutadores pueden admitir PTPv2:
- programáticamente;
- hardware.
Al implementar el protocolo PTPv2 en el software, el conmutador solicita una marca de tiempo del firmware. El problema es que el firmware funciona cíclicamente y tendrá que esperar hasta que finalice el ciclo actual, acepte la solicitud para procesarla y emita una marca de tiempo después del siguiente ciclo. Esto también llevará tiempo y tendremos un retraso, aunque no tan significativo como sin soporte de software para PTPv2.
Sólo el soporte de hardware para PTPv2 le permite mantener la precisión requerida. En este caso, la marca de tiempo la emite un ASIC especial, que está instalado en el puerto.
Formato de mensaje
Todos los mensajes PTP constan de los siguientes campos:
- Encabezado: 34 bytes.
- Cuerpo: el tamaño depende del tipo de mensaje.
- El sufijo es opcional.
Encabezamiento
El campo Encabezado es el mismo para todos los mensajes PTP. Su tamaño es de 34 bytes.
Formato del campo de encabezado:
Tipo de mensaje – contiene el tipo de mensaje que se transmite, por ejemplo Sync, Delay_Req, PDelay_Req, etc.
longitud del mensaje – contiene el tamaño completo del mensaje PTP, incluido el encabezado, el cuerpo y el sufijo (pero excluyendo los bytes de relleno).
número de dominio – determina a qué dominio PTP pertenece el mensaje.
Nombre de dominio - Se trata de varios relojes diferentes reunidos en un grupo lógico y sincronizados desde un reloj maestro, pero no necesariamente sincronizados con relojes que pertenecen a un dominio diferente.
banderas – Este campo contiene varias banderas para identificar el estado del mensaje.
campo de corrección – contiene el tiempo de retraso en nanosegundos. El tiempo de retraso incluye el retraso al transmitir a través del reloj transparente, así como el retraso al transmitir a través del canal cuando se usa el modo Peer-to-Peer.
fuentePuertoIdentidad – este campo contiene información sobre desde qué puerto se envió originalmente este mensaje.
ID de secuencia – contiene un número de identificación para mensajes individuales.
campo de control – campo de artefacto =) Permanece de la primera versión del estándar y contiene información sobre el tipo de este mensaje. Básicamente lo mismo que messageType, pero con menos opciones.
logMessageInterval – este campo está determinado por el tipo de mensaje.
Cuerpo
Como se mencionó anteriormente, existen varios tipos de mensajes. Estos tipos se describen a continuación:
Mensaje de anuncio
El mensaje Anuncio se utiliza para "informar" a otros relojes dentro del mismo dominio sobre sus parámetros. Este mensaje le permite configurar una jerarquía de reloj maestro - reloj esclavo.
Sincronización de mensajes
El mensaje de sincronización es enviado por el reloj maestro y contiene la hora del reloj maestro en el momento en que se generó el mensaje de sincronización. Si el reloj maestro tiene dos etapas, la marca de tiempo en el mensaje de sincronización se establecerá en 0 y la marca de tiempo actual se enviará en el mensaje Follow_Up asociado. El mensaje Sync se utiliza para ambos mecanismos de medición de latencia.
El mensaje se transmite mediante multidifusión. Opcionalmente puedes usar Unicast.
Mensaje Delay_Req
El formato del mensaje Delay_Req es idéntico al del mensaje Sync. El reloj esclavo envía Delay_Req. Contiene la hora en que el reloj esclavo envió Delay_Req. Este mensaje se utiliza únicamente para el mecanismo de solicitud-respuesta de retraso.
El mensaje se transmite mediante multidifusión. Opcionalmente puedes usar Unicast.
Mensaje de seguimiento
El mensaje Follow_Up es enviado opcionalmente por el reloj maestro y contiene la hora de envío. Sincronizar mensajes maestro. Sólo los relojes maestros de dos etapas envían el mensaje Follow_Up.
El mensaje Follow_Up se utiliza para ambos mecanismos de medición de latencia.
El mensaje se transmite mediante multidifusión. Opcionalmente puedes usar Unicast.
Mensaje Delay_Resp
El mensaje Delay_Resp lo envía el reloj maestro. Contiene la hora en que el reloj maestro recibió Delay_Req. Este mensaje se utiliza únicamente para el mecanismo de solicitud-respuesta de retraso.
El mensaje se transmite mediante multidifusión. Opcionalmente puedes usar Unicast.
Mensaje Pdelay_Req
El mensaje Pdelay_Req es enviado por un dispositivo que solicita un retraso. Contiene la hora en que se envió el mensaje desde el puerto de este dispositivo. Pdelay_Req solo se utiliza para el mecanismo de medición del retardo del vecino.
Mensaje Pdelay_Resp
El mensaje Pdelay_Resp lo envía un dispositivo que ha recibido una solicitud de retraso. Contiene la hora a la que este dispositivo recibió el mensaje Pdelay_Req. El mensaje Pdelay_Resp se utiliza sólo para el mecanismo de medición del retardo del vecino.
Mensaje Pdelay_Resp_Follow_Up
El mensaje Pdelay_Resp_Follow_Up lo envía opcionalmente el dispositivo que ha recibido la solicitud de retraso. Contiene la hora a la que este dispositivo recibió el mensaje Pdelay_Req. El mensaje Pdelay_Resp_Follow_Up lo envían únicamente relojes maestros de dos etapas.
Este mensaje también se puede utilizar para el tiempo de ejecución en lugar de una marca de tiempo. El tiempo de ejecución es el tiempo desde el momento en que se recibe Pdelay-Req hasta que se envía Pdelay_Resp.
Pdelay_Resp_Follow_Up se utilizan solo para el mecanismo de medición del retardo del vecino.
Mensajes de gestión
Se requieren mensajes de control PTP para transferir información entre uno o más relojes y el nodo de control.
Traslado a LV
Un mensaje PTP se puede transmitir en dos niveles:
- Red: como parte de los datos IP.
- Canal: como parte de una trama Ethernet.
Transmisión de mensajes PTP a través de UDP a través de IP a través de Ethernet
PTP sobre UDP sobre Ethernet
Perfiles
PTP tiene bastantes parámetros flexibles que deben configurarse. Por ejemplo:
- Opciones BMCA.
- Mecanismo de medición de latencia.
- Intervalos y valores iniciales de todos los parámetros configurables, etc.
Y a pesar de que anteriormente dijimos que los dispositivos PTPv2 son compatibles entre sí, esto no es cierto. Los dispositivos deben tener la misma configuración para poder comunicarse.
Por eso existen los llamados perfiles PTPv2. Los perfiles son grupos de ajustes configurados y restricciones de protocolo definidas para que se pueda implementar la sincronización horaria para una aplicación específica.
El propio estándar IEEE 1588v2 describe sólo un perfil: "Perfil predeterminado". Todos los demás perfiles son creados y descritos por diversas organizaciones y asociaciones.
Por ejemplo, el Power Profile, o PTPv2 Power Profile, fue creado por el Power Systems Relaying Committee y el Substation Committee de IEEE Power and Energy Society. El perfil en sí se llama IEEE C37.238-2011.
El perfil describe que PTP se puede transferir:
- Solo a través de redes L2 (es decir, Ethernet, HSR, PRP, no IP).
- Los mensajes se transmiten únicamente mediante difusión multidifusión.
- El mecanismo de medición del retraso entre pares se utiliza como mecanismo de medición del retraso.
El dominio predeterminado es 0, el dominio recomendado es 93.
La filosofía de diseño de C37.238-2011 era reducir la cantidad de características opcionales y conservar solo las funciones necesarias para una interacción confiable entre dispositivos y una mayor estabilidad del sistema.
Además, se determina la frecuencia de transmisión del mensaje:
De hecho, sólo está disponible un parámetro para seleccionar: el tipo de reloj maestro (de una o dos etapas).
La precisión no debe ser superior a 1 μs. En otras palabras, una ruta de sincronización puede contener como máximo 15 relojes transparentes o tres relojes límite.
Fuente: habr.com