Precision Time Protocol (PTP) en adquisición de datos Precision Time Protocol (PTP) en adquisición de datos | HBM

Precision Time Protocol (PTP) en aplicaciones de pruebas y adquisición de datos

Durante las últimas décadas se han puesto a punto numerosos mecanismos de temporización con el objetivo de sincronizar distintos dispositivos entre sí. Uno de los primeros protocolos de sincronización temporal basado en Ethernet que se normalizó fue el Networked Time Protocol (NTP). Este protocolo, creado en 1982, se sometió a una importante actualización en 1994 que dio lugar al NTP versión 4, que permitía el uso de una fuente de temporización maestra local o pública.

Los códigos de tiempo B del Inter-Range Instrumentation Group (IRIG), basados en un trabajo que se remonta a 1956, constituyen otra opción para la sincronización de sistemas distribuidos. En este caso, se suelen utilizar receptores de satélite como fuente para una temporización de precisión. Con esta tecnología, la información de temporización se transfiere directamente en forma de señales analógicas o digitales.

La tecnología FireWire, que se remonta a 1985, se normalizó como IEEE1394b en 2002 con el fin de ofrecer un mecanismo de sincronización temporal automática de fácil manejo. Este estándar se ha adoptado ampliamente en periféricos tanto de los mercados de consumo como en aplicaciones profesionales. Por ejemplo, todos los módulos QuantumX de HBM disponen de dos puertos FireWire. 

A pesar de los estándares disponibles, como NTP, IRIG B e IEEE1494b, existía una necesidad clara de utilizar la infraestructura de Ethernet establecida para la sincronización de sistemas distribuidos. Entre otros requisitos, el nuevo enfoque debía proporcionar una mayor flexibilidad y facilidad de uso, con un coste menor. Ethernet se encuentra presente en la infraestructura de TI de la industria y en los productos de consumo de nuestros hogares. Es el estándar global de facto para las comunicaciones entre máquinas o entre personas y máquinas. Incluso los dispositivos móviles como nuestros smartphones, o muchos vehículos, se pueden conectar a redes Ethernet a través de redes de telecomunicaciones móviles como LTE, EDGE o GSM.


¿Qué precisión tiene la sincronización temporal?

Los relojes nos sirven para llegar a tiempo a reuniones u otras citas. En el mundo del deporte, las fracciones de segundo pueden determinar quién gana y quién pierde. En las transacciones bursátiles a alta velocidad, una diferencia temporal de unos pocos microsegundos puede suponer una variación de miles de dólares en los precios de compra y venta. En las aplicaciones de pruebas y medición, las distintas entradas de señal horofechadas con alta precisión que representan un mismo proceso físico capturado en un mismo instante desempeñan un papel importante en la calificación y análisis de los datos de medición, ya sea en tiempo real o durante el posprocesamiento. En cada uno de estos ejemplos, y en cualquier otros, la definición de "precisión" de los relojes depende por supuesto de la aplicación en cuestión.

¿Cuál es la diferencia entre tiempo absoluto y relativo?

El tiempo absoluto es necesario cuando es necesario asignar los datos de medición a un determinado suceso de la vida real o cuando dos o más sistemas de adquisición de datos no se encuentran en la misma red. Por ejemplo, el tiempo absoluto es relevante cuando se desea monitorizar la influencia de la carga de un tren que cruza un puente y se necesita identificar el tren para cualquier actividad posterior, como puede ser un aviso de sobrecarga. El tiempo absoluto se encuentra explícitamente disponible cuando se representa mediante un reloj.

Las fuentes de tiempo absoluto pueden ser:

  • Relojes Grandmaster de Precision Time Protocol (PTP)
    • para uso en laboratorio, de la empresa Meinberg, basados en GPS
    • para uso móvil, de la empresa OMICRON, basados en GPS
  • Sensores GPS
    • que utilizan directamente el servicio de posicionamiento de precisión (PPS) del sensor GPS
    • que adoptan el tiempo absoluto basado en el protocolo cuando se inicia la operación de adquisición de datos
  • El reloj maestro Network Time Protocol (NTP)
    • disponible para el público mediante acceso a internet a través por ejemplo de NIST
    • distribuido a escala local y basado en el GPS de las empresas Hopf o Meinberg
    • ejecutado en un PC, utilizando el tiempo absoluto del sistema operativo
  • Señales de radio terrestres transmitidas a baja frecuencia
    • un ejemplo es la DCF-77 (reloj atómico), utilizada por el PTB en Alemania 
  • Servidores temporales Simple Network Time Protocol (SNTP)

La mayoría de las aplicaciones o procesos de pruebas y medición pueden utilizar un tiempo de sistema relativo, sobre todo cuando las pruebas son reproducibles y lo que más interesa es la temporización relativa de las señales entre sí. Si es preciso, el tiempo absoluto puede formar parte de los metadatos o integrarse en el propio nombre del archivo (por ejemplo, 2015-08-03_RLDA-test_Viper_No12).

A veces la precisión del tiempo se confunde con los conceptos de reacción, latencia o tiempo real. Las funciones en tiempo real se pueden conseguir, por ejemplo, mediante buses en tiempo real como EtherCAT, ProfiNET, EtherNET/IP u otros muchos buses de campo patentados.

¿Qué hay que tener en cuenta cuando se realizan análisis en tiempo real y de alta velocidad con una solución de adquisición de datos?

Existen muchas aplicaciones distintas de pruebas y medición. Podemos clasificarlas en algunos grandes grupos. Uno de ellos serían las aplicaciones de medición y análisis de datos sincronizados en el tiempo. Algunos ejemplos: las pruebas de carga estructurales, las pruebas de vehículos, la adquisición de datos de carga en carretera (RLDA) o la auscultación de puentes. Otro grupo sería el de las pruebas de laboratorio basadas en actuadores dinámicos, de simulación, estimulación, control o “in-the-loop”. En estos casos, la adquisición de datos con fines de análisis no es lo más importante. La lista a continuación recoge algunas consideraciones fundamentales:

  • Algunas aplicaciones emplean velocidades de datos de hasta 100 kS/s por canal —y superiores— con fines de análisis de datos. La respuesta en tiempo real no es el criterio principal. Además, no es posible con los buses en tiempo real comunes. Si lo fuera, aumentaría la complejidad y se reduciría el grado de libertad.
  • Los instrumentos de alta precisión funcionan con convertidores AD de 24 bits Sigma-Delta y filtros que provocan desplazamientos de fase y retardos temporales. Las aplicaciones en tiempo real requieren un determinismo del orden de milisegundos y necesitan tiempos de respuesta cortos. Las soluciones de adquisición de datos modernas, como QuantumX de HBM, permiten dividir las entradas de sensor en dos señales con fines distintos (la primera para tiempo real, la segunda para datos filtrados y con horofechado de alta velocidad).
  • El “análisis” y el “control” son cosas distintas en cuanto a su naturaleza, flujo de trabajo, cometido y, con frecuencia, responsabilidad. La combinación de ambos conceptos en una única solución puede dar lugar a conflictos: por ejemplo, el accionamiento de un banco de pruebas dinamométricas o una carga eléctrica y la adquisición en paralelo de datos dinámicos de alta velocidad del sistema objeto del ensayo (por ejemplo, una cadena cinemática). Por lo tanto, parece lógico separar la responsabilidad del flujo de trabajo cuando se necesitan funciones de control y análisis.
  • De momento no existe ningún bus estándar en tiempo real de alto rendimiento establecido a escala global. Las soluciones como ProfiNET RT, EtherCAT y otras muchas están dominadas por agentes industriales globales que las utilizan para dar soporte a su propia tecnología, en sus mercados y, la mayoría de las veces, en aplicaciones específicas. El grupo de trabajo Time-Sensitive Networking (TSN) está trabajando en un bus Ethernet en tiempo real normalizado según IEEE, parte de IEEE802.1AS, con el objetivo de crear un estándar mundial. Las soluciones de adquisición de datos pueden conectarse a buses muy variados en tiempo real mediante pasarelas.
  • El tiempo real necesita una aplicación maestra que se ejecute en tiempo real (que no puede detenerse para reconfigurarla).

¿Qué significa "tiempo real" y qué es la latencia temporal?

El tiempo real está ligado a un comportamiento determinista: hay que tomar una “decisión” o dar una “respuesta” en un intervalo de tiempo específico. Se utiliza sobre todo en tareas de control o automatización (sensor -> algoritmo de control -> reacción/actuador).

La latencia temporal es un aspecto que hay que tener en cuenta en el diseño de los algoritmos de control o cuando se necesita una respuesta dentro de un plazo máximo concreto. Las aplicaciones de control en tiempo real normalmente requieren una latencia temporal fija y muy baja entre el sensor y el controlador. En el caso de los protocolos no deterministas, como Ethernet TCP/IP, CANbus o cualquier otra actividad basada en PC, la latencia temporal es variable. La latencia temporal también desempeña un papel importante cuando se transmiten datos a un controlador en tiempo real con fines de monitorización y no se tiene o no se puede tener en cuenta el sello de tiempo enviado con el valor de los datos. 


¿Qué es el Precision Time Protocol (IEEE1588:2008 o PTPv2) y cómo funciona?

PTP es un estándar internacional, especificado en la norma IEEE1588. Se revisó en 2008, dando lugar a la versión 2. Precision Time Protocol (PTPv2) es un protocolo de comunicaciones con sincronización temporal de red que se puede utilizar para sincronizar los relojes de distintos tipos de dispositivos. Proporciona una precisión del orden de submicrosegundos. PTPv2 se basa en Ethernet. En comparación con el protocolo NTP, PTPv2 está integrado en la capa física, por lo que hablamos de horofechado basado en hardware real para una sincronización temporal precisa de todos los participantes de la red Ethernet. 

El PTPv2 es un mecanismo de sincronización temporal relativa. Se selecciona un participante para que actúe como reloj maestro y envíe mensajes de sincronización temporal a todos los dispositivos esclavos. El proceso de sincronización comienza con un telegrama de sincronización temporal que se envía a la red. Todos los participantes (esclavos) calculan la diferencia de tiempo (retardo) entre su hora local y la del reloj maestro en cuestión y se adaptan paso a paso a una diferencia horaria inferior a 2 µs. Por ejemplo, supongamos que una fuente PTP envía un mensaje PTP en el que declara que la hora es la 1:00:00 pm. El problema es que este mensaje tarda un tiempo en llegar a su destino. Si el paquete PTP tarda 1 segundo en llegar a su fuente, cuando la fuente reciba un paquete PTP que de que es la 1:00:00 pm., ya será la 1:00:01 pm. En consecuencia, es necesario compensar la latencia de la red, cosa que se consigue intercambiando una serie de mensajes entre el reloj maestro y los esclavos, como se muestra en la figura de más abajo.

  1. El reloj maestro envía el mensaje de sincronización. La hora a la que sale el mensaje de sincronización del reloj maestro se horofecha como t1, indicación que se puede integrar en el propio mensaje Sync (operación en un paso) o enviarse en el mensaje Follow_Up (operación en dos pasos).
  2. El esclavo recibe el mensaje Sync: esto sucede a la hora t2.
  3. El esclavo envía el mensaje Delay_Req. Este mensaje se horofecha como t3 cuando sale del esclavo y como t4 cuando el maestro lo recibe.
  4. El maestro responde con un mensaje Delay_Resp que contiene un sello de tiempo t4.

Ejemplo: inicialmente el tiempo del maestro es 100 segundos y el del esclavo es 80 segundos. El diagrama describe cómo se ajustaría la hora en el esclavo.

Todos los participantes del PTP deben ser compatibles con este protocolo: esto incluye los switches Ethernet, pero no el colector de datos (es decir, el PC que ejecuta el software de adquisición de datos). El reloj del módulo de adquisición de datos se denomina reloj ordinario. El reloj del switch Ethernet se denomina reloj límite. El maestro se selecciona automáticamente si no hay ningún reloj Grandmaster que proporcione información de tiempo absoluto. Este mecanismo se denomina “algoritmo de mejor reloj maestro” (BMC).

Algunas topologías DAQ poseen una estructura de línea o anillo con múltiples switches. En estos casos los relojes límite utilizan sus propios bucles de control del tiempo. Como alternativa, el denominado reloj transparente (TC) permite implementar un control de sincronización de extremo a extremo (E2E) y el envío de mensajes de seguimiento. La introducción del TC permite ofrecer una solución mucho más sencilla para la corrección de la latencia variable del switch. La función básica del TC consiste en medir el tiempo que un mensaje de suceso PTP pasa en el conmutador (lo que se denomina “tiempo de residencia”). El tiempo de residencia se comunica al receptor a través del propio mensaje o mediante un mensaje Follow_up o Delay_Resp posterior. Para ello se ha añadido un nuevo campo de mensaje: el “campo de corrección”, que es un tipo de intervalo de tiempo que se puede utilizar para acumular el tiempo de residencia a lo largo de la ruta del mensaje, así como para otro tipo de correcciones. Sus principales ventajas son:

  • No se requiere ninguna configuración: los relojes transparentes no tienen que calcular y no es necesario tenerlos en cuenta en el cálculo del algoritmo BMC, por lo que no necesariamente tienen que enviar o recibir mensajes de gestión.
  • Reconfiguración rápida de la red en caso de fallo.
  • Tiempos de configuración más rápidos: en la fase de inicialización y después de cualquier cambio en la topología, los relojes transparentes no necesitan resincronizarse con un reloj maestro para poder considerarse parte de una ruta sincronizada válida.
  • Perfecto para configuraciones pequeñas.

Los relojes transparentes que utilizan sistemas entre iguales (P2P) se adaptan bien al número de dispositivos conectados a la subred y pueden recuperarse rápidamente en caso de que se produzcan cambios en la topología de red. Por lo tanto, este mecanismo ofrece un alto grado de escalabilidad y es idóneo para las topologías con muchos niveles en cascada (sistemas a gran escala que utilizan muchos switches organizados en una cadena de margarita).

¿Qué ventajas presenta el PTPv2?

  • Permite una sincronización temporal entre distintos tipos de dispositivos de diferentes proveedores, a través de un protocolo normalizado.
  • Permite grandes distancias entre los módulos de adquisición de datos.
  • Permite sincronizar entre sí distintas líneas de productos HBM. QuantumX, SomatXR y Genesis High Speed ofrecen PTPv2 y hacen posible la adquisición de datos en todo tipo de situaciones, incluyendo:
    • Sistemas distribuidos, móviles, en exteriores y en condiciones adversas
    • Pruebas de laboratorio o de campo con muchos cientos de canales o del orden de millones de muestras por segundo y canal
  • Precisión temporal del orden de submicrosegundos entre todos los participantes, cuando funcionan con altas velocidades de datos.
  • Uso de Ethernet como estándar:
    • Sistemas eléctricos: hasta 100 m de cable Ethernet estándar
    • Sistemas ópticos: larga distancia (varios kilómetros) entre los módulos y el aislamiento galvánico
    • No se necesitan líneas de sincronización adicionales
  • Configuración sencilla, sin administración:
    • Selección del maestro automática
    • Resistente a fallos del maestro (esclavos inteligentes)
    • Robusto en caso de cambios en la topología
    • Escala temporal continua (sin “saltos” en los sellos de tiempo ni reinicios)
  • Temporización absoluta en caso necesario:
    • Es posible integrar un reloj Grandmaster basado en GPS que proporcione el tiempo absoluto, si uno o varios sistemas de adquisición de datos no operan en la misma red pero es necesario analizar sus datos de forma rápida.

¿En qué aplicaciones de pruebas y medición es habitual el uso de la sincronización PTP?

A continuación se citan aplicaciones típicas que permite explotar las ventajas del protocolo PTP:

  • Módulos de adquisición de datos ampliamente distribuidos utilizados para:
    • Pruebas móviles de vehículos terrestres a gran escala (trenes, construcción): frenado, dinámica, estructura, etc.
    • Pruebas de laboratorio de aeronaves: mecánicas (pájaro de hierro), estructurales (resistencia).
    • Auscultación de grandes estructuras: puentes, torres o aerogeneradores mediante tiempo absoluto basado en GPS.
  • Sistemas de adquisición de datos híbridos utilizados para:
    • Pruebas dinamométricas de vehículos eléctricos o híbridos que combinan el sistema de adquisición de datos de alta velocidad Genesis High Speed para la adquisición de tensión y corriente con 2 MS/s por canal y QuantumX de velocidad media para la adquisición de datos de sensores térmicos y mecánicos.
    • Pruebas de laboratorio de aeronaves: eléctricas (pájaro de cobre).
    • Pruebas de laboratorio de maquinaria o generadores: eléctricas, mecánicas y térmicas.
    • Pruebas móviles o monitorización de vehículos mediante cámaras, transductores de fuerza de rueda u otros complementos a los datos de bus de vehículos analógicos o digitales.
    • En general, la combinación de distintos sistemas DAQ de diferentes fabricantes con cualquier fin.
  • Arquitecturas mixtas que combinan sistemas de adquisición de datos analógicos clásicos con cámaras u otras fuentes de información.

 

 

¿Cuáles son los procedimientos de parametrización del PTP en el software de adquisición de datos?

Dado que QuantumX admite distintos mecanismos de sincronización temporal, es necesario parametrizarlo la primera vez que se configura la red. El mecanismo de temporización del reloj del sistema AUTO o predeterminado es FireWire. Además, se pueden seleccionar los siguientes mecanismos o fuentes de temporización:

  • PTPv2
  • NTP
  • IRIG-B
  • EtherCAT

Puede emplear el software catmanEasy, MX Assistantperception para configurar los parámetros PTPv2. Pulse en las capturas de pantalla para agrandarlas.

¿Qué switches PTP Ethernet y relojes Grandmaster se recomiendan?

Las características básicas que se indican a continuación son necesarias para seleccionar un switch PTPv2:

  • Compatibilidad con IEEE1588:2008 (PTPv2)
  • Reloj transparente (TC)
  • Mecanismo de retardo: de extremo a extremo (E2E) o entre iguales (P2P)
  • Mecanismo de transporte: IPv4 o IPv6

Switches recomendados

  • HBM: Switch Gigabit Ethernet EX23-R con estos parámetros:
    • Diseño del sistema: variante robusta para uso en exterior con 10 puertos, alimentación 10-30 V CC, IP65/IP67, resistencia a los impactos
    • Mecanismo de retardo: E2E
    • Mecanismo de transporte: IPv4, IPv6.
  • Siemens:  Scalance XR324-12M
    • Diseño del sistema: variante de tamaño rack con hasta 16 puertos (eléctricos u ópticos)
    • Mecanismo de retardo:  E2E
    • Mecanismo de transporte:  IPv4/UDP
    • Modo: Reloj transparente
  • Hirschmann: switch Ethernet RSP
    • Diseño del sistema: instalación en carril DIN con un total de 11 puertos
    • Mecanismo de retardo: E2E
  • Oregano Systems:  Switch Gbit Ethernet syn1588®
    • Diseño del sistema: variante de sobremesa con 8 puertos
    • Mecanismo de retardo: 1 paso con E2E
    • Mecanismo de transporte: IP4 (IPv6 no se ha probado)
    • Modo: Reloj transparente (sin configuración de los parámetros)
  • B&K: Switch PTPv2 de la serie LAN-XI
    • Diseño del sistema: Sobremesa con 8 puertos eléctricos y 2 puertos ópticos

Otros switches disponibles en el mercado pero que aún no se han probado:

  • CISCO: Switch IE 3000
  • MOXA: Switch tipo rack PT-7728-PTP
  • MOXA: Serie EDS-405A-PTP

Relojes Grandmaster Ethernet recomendados

La integración de un reloj Grandmaster en la red no es obligatoria, ya que PTP ofrece un mecanismo de “mejor reloj”, pero algunas aplicaciones exigen información de reloj absoluto.

  • Meinberg: Reloj Grandmaster LANTIME M600 - IEEE 1588-2008 (basado en GPS)
    • Diseño del sistema: solución instalada en rack, alimentación 110 – 230 V CA
    • Puertos: 6 en total (RJ45)
  • Omicron: OTMC 100 (GPS integrado)
    • Diseño del sistema: pequeño, para instalaciones en exteriores (IP67, alimentación 24 V CC, -40 °C … +70 °C / -40 °F ... +158 °F)
    • Puertos: 1 en total, compatible con alimentación a través de Ethernet (PoE) según IEEE 802.3af con < 2 W.
  • También se puede utilizar un PC como reloj Grandmaster 
    • En ese caso, recomendamos utilizar un adaptador de red con chip Intel i210. 

¿PTPv2 es compatible con PTPv1?

La versión 1 del PTP estaba dirigida sobre todo al campo de los ensayos, las mediciones y la automatización industrial. Se trataba de un protocolo multidifusión para su uso en una red LAN con un rendimiento superior al de NTP.

La versión 2 del PTP o IEEE-1588-2008 es una mejora de la versión 1. Las versiones son incompatibles. Entre las características del estándar PTPv2, más reciente, cabe destacar las siguientes:

  • Mensajes multidifusión
  • Reloj en dos pasos
  • Mecanismo de retardo entre iguales (P2P) o de extremo a extremo (E2E)
  • Intervalo de sincronización: 1, 2, 4, 8, 16, 32, 64 o 128 paquetes/segundo
  • Intervalo de solicitud de retardo: 1, 2, 4, 8 o 16 segundos
  • Compatibilidad con los protocolos de transporte: IPv4 y el moderno IPv6

¿Qué precisión obtendré si utilizo PTPv2?

La precisión temporal depende en gran medida del tipo de red y de los dispositivos que formen parte de ella. Le recomendamos que configure una red LAN privada en la que todos los participantes sean totalmente compatibles con PTPv2. En una configuración de estas características, se puede alcanzar una precisión temporal de hasta 100 nanosegundos entre los dispositivos y sus canales. No obstante, debe tener en cuenta que las distintas velocidades de datos y filtros pueden provocar inestabilidad en la temporización y retardos de fase.

¿Cuál es la diferencia entre el horofechado basado en hardware y en software?

La principal diferencia radica en la precisión de la sincronización que se puede obtener. Por ejemplo, con el horofechado que se utiliza en NTP, se pueden conseguir precisiones de sincronización de los esclavos de hasta 100 microsegundos en redes pequeñas, aunque lo típico es un valor de 1 ms. Con el horofechado basado en hardware se puede lograr una precisión de la sincronización temporal de hasta 100 nanosegundos. No obstante, para conseguir este nivel de precisión, la topología de red (los switches y el hardware de los dispositivos esclavos) debe ser compatible con el horofechado basado en hardware.

¿Puedo utilizar un switch estándar? En caso afirmativo, ¿cuál sería el efecto?

El uso de switches incompatibles con PTP es arriesgado. La transferencia de los mensajes PTP, esencial para la temporización global, pasa de depender del tráfico. Si el switch es compatible con QoS, este problema se puede solucionar con una norma que eleve la prioridad de los paquetes PTP. En general no recomendamos el uso de switches incompatibles con PTPv2. En el peor de los casos, los paquetes PTP se pueden perder y la temporización y los datos requeridos dejarían de ser fiables.