Sin duda, el IEEE1588 (también conocido como Protocolo de Precisión Temporal o PTP) es una de las características más interesantes del estándar LXI. Ignorado en la industria de medida y prueba antes de la aparición del LXI, el Protocolo de Precisión Temporal presenta un enfoque fundamentalmente nuevo para un aspecto importante de las pruebas: la sincronización de los componentes de sistemas.

Las capacidades del PTP podrían cambiar la forma en la que nos ocuparemos de muchos requisitos de prueba comunes en el futuro. Este artículo describe cómo funciona y cómo podemos beneficiarnos de esta tecnología. El PTP sincroniza de forma precisa los relojes en tiempo real incorporados en muchos componentes de sistemas modernos. Al igual que el Protocolo de Temporización de Red (NTP), el PTP funciona por Ethernet y TCP/IP. Sin embargo, es mucho más preciso: puede conseguirse fácilmente una sincronización de hasta 100 ns o incluso mejor. Podría pensarse que dichos sistemas serán frágiles y difíciles de configurar, pero en realidad no lo son. Como veremos a continuación, la configuración del sistema es fácil y en su mayor parte automática. Pero veamos en primer lugar algunas nociones básicas de IEEE1588.

El PTP se basa en una arquitectura maestro-esclavo. Los relojes esclavos están sincronizados con el reloj maestro (normalmente, aquél con la base de tiempo más estable y precisa). La clave de la precisión del PTP es la forma en que tiene en cuenta el tiempo de transmisión de mensajes a través de la LAN cuando se evalúa la desviación del reloj esclavo (ver la Figura 1).
Tal como se muestra, el reloj maestro envía un mensaje de sincronización “Sync” al esclavo a intervalos regulares. El esclavo responde con un mensaje de petición de retardo “Delay_Req”. Tanto el envío como la recepción de estos mensajes son registrados en función del tiempo por los relojes. Los cuatro registros en función del tiempo resultantes se utilizan a continuación para calcular el tiempo de transmisión (el tiempo que el mensaje se está transmitiendo realmente en la capa física de red). Observe que el cálculo mostrado en la Figura 1 se basa en la idea de que el tiempo de transmisión es simétrico (con Ethernet, ésta es una suposición perfectamente razonable). Con el tiempo de transmisión y los registros en función del tiempo del mensaje Sync, el cálculo de la desviación del reloj esclavo es sencillo.

El hardware es mejor que el software
Aunque no es un requisito obligatorio, para un rendimiento óptimo, los registros en función del tiempo se toman en el hardware, en la capa de red física. ¿Por qué? La clave de una sincronización perfecta son unos registros en función del tiempo estables y repetibles con una variación reducida. Y la mejor forma de conseguirlo es mediante un diseño de hardware (ver el diagrama de bloques conceptuales en la Figura 2).
Con un diseño de Ethernet que presenta un chip físico independiente (implementación de capa física), es relativamente fácil captar el flujo de bits de las tramas Ethernet. El hardware de adecuación de patrones buscará a continuación un patrón de mensaje Delay_Req entrante o Sync saliente. Observe que la especificación del estándar IEEE1588 indica claramente qué registros en función del tiempo de transición de bits deben tomarse.
En el diseño descrito anteriormente, el registro en función del tiempo se toma como si la trama Ethernet estuviera realmente saliendo hacia la capa física de red. Por consiguiente, el registro en función del tiempo no puede enviarse como parte del mismo mensaje. El mensaje de seguimiento Follow-Up (ver Figura 1) se utiliza para comunicar el registro en función del tiempo (“tiempo de envío preciso”) por separado del mensaje Sync original.
En algunas situaciones, puede ser suficiente y perfectamente razonable utilizar una aplicación de software para tomar el registro en función del tiempo. Sin embargo, la precisión de sincronización resultante será, como mínimo, mucho menor debido a la fluctuación de temporización asociada al software de apilamiento de protocolos de red.

La fluctuación de retardo de red es el enemigo
Tal como se ha mencionado anteriormente, el algoritmo de corrección de reloj se basa en la suposición de tiempos de transmisión simétricos. Así pues, las fluctuaciones en los tiempos de transmisión (una vía) originarán una degradación en la precisión de la sincronización. Para un rendimiento óptimo, escoja una infraestructura de red con una fluctuación de retardo mínima.

Un hub Ethernet mostrará un retardo relativamente bajo y estable por diseño. Un hub es un repetidor de señal simple y las tramas Ethernet no se guardan ni se interpretan de ninguna forma. Un conmutador Ethernet mostrará unos retardos mayores y, aún más importante, una fluctuación de retardo mucho más elevada. El conmutador analiza las tramas entrantes y las pone en cola para la salida en el puerto de destino adecuado. Un enrutador presenta un nivel aún más alto de fluctuación de retardo porque inspecciona paquetes en la capa IP y los guarda y envía utilizando mecanismos de software.
Si desea utilizar un conmutador o un enrutador por sus capacidades adicionales en las capas de red 2 ó 3, respectivamente, no será necesario dar soporte a su mayor fluctuación de retardo y la reducción resultante en la precisión de la sincronización. El PTP utiliza un mecanismo denominado reloj periférico para neutralizar el efecto negativo de los elementos de red que presentan una fluctuación de retardo elevada (ver la Figura 3).

Un reloj periférico es un conmutador o enrutador que tiene su propio reloj en tiempo real incorporado y cumple el estándar IEEE1588. Exceptuando los mensajes de temporización del PTP como Sync y Delay_Req, se comporta como un conmutador o enrutador normal. Sin embargo, con respecto al PTP, el reloj periférico termina la “ruta de sincronización” detrás de cada puerto individual. El puerto que esté conectado al mejor reloj (reloj gran maestro) asumirá la función de un reloj esclavo. En consecuencia, el reloj interno en el conmutador o enrutador se sincronizará con el reloj gran maestro mediante este puerto. Los demás puertos asumirán la función de un reloj maestro. Como resultado, todos los relojes esclavos en su respectiva ruta de sincronización se sincronizarán con el reloj interno del reloj periférico.
El mecanismo del reloj periférico aumenta espectacularmente la precisión de la sincronización (hasta el nivel de un hub Ethernet simple o incluso mejor) porque los mensajes de temporización de IEEE1588 no se conmutan ni dirigen a través del elemento de red (a diferencia de los otros paquetes IP o tramas Ethernet). Consiguientemente, se elimina de la ecuación una importante fuente de fluctuación de retardo (almacenamiento y procesamiento en el elemento de red).
¿Hasta dónde se puede llegar?
Tal como hemos visto, un sistema diseñado para obtener el máximo rendimiento debería seguir dos importantes normas. En primer lugar, utilizaría una implementación asistida por hardware del estándar IEEE1588 en los relojes maestro y esclavo. En segundo lugar, utilizaría una infraestructura de red apropiada: un hub Ethernet simple o un elemento de red más complejo (conmutador o enrutador) con un reloj periférico. Si seguimos estas normas, ¿hasta dónde podemos llegar en términos de precisión de sincronización?
Con las técnicas asistidas por hardware, la precisión está limitada por dos elementos: la captura de reloj de la implementación física y la estabilidad del propio oscilador o reloj local. Al implementar Fast Ethernet, la fluctuación de captura de reloj normalmente está en un rango bajo de menos de diez nanosegundos. El efecto de este jitter puede reducirse de forma bastante eficaz mediante métodos estadísticos. La variación del oscilador local depende en gran medida del diseño del sistema y podría fácilmente minimizar los problemas de captura de reloj. Debe observarse que el intervalo del mensaje Sync puede reducirse a 1 s, pero no a menos. Un diseño de estabilidad elevada tendría que mostrar una variación limitada que se adaptara a la estabilidad de la captura de reloj (rango ns pequeño). Esto podría requerir una solución relativamente costosa basada en un oscilador termorresistente.

Los mejores diseños incluirán métodos estadísticos apropiados para reducir el efecto de la fluctuación de retardo. E estándar IEEE1588 no especifica el uso de un algoritmo promedial, por lo tanto ésta es otra área en la que los fabricantes pueden realizar una contribución única en sus soluciones.

¿Son difíciles de instalar estos sistemas?
Uno de los aspectos más interesantes del estándar IEEE1588 es que la configuración del sistema es en su mayor parte automática (a no ser que prefiera controlar el proceso de configuración). Veamos cómo es posible.
Todos y cada uno de los relojes mantienen determinados juegos de datos que describen sus capacidades inherentes (por ejemplo, su estabilidad) y su configuración real (por ejemplo, una estimación de la desviación del tiempo real respecto al maestro, así como la identificación del reloj maestro). Estos (y otros) parámetros describen la calidad de un reloj y se “publican” como parte de todos los mensajes Sync enviados por el reloj.
Cuando un reloj pasa a estar online, asumirá la función de maestro y empezará a enviar mensajes Sync (conteniendo sus especificaciones). Otros relojes recibirán los parámetros de calidad y los compararán con sus propias especificaciones (mediante el algoritmo de “Mejor reloj maestro”). Si perciben que hay un reloj maestro mejor, asumirán la función de esclavo.
¿Cuáles son los criterios para un “buen” reloj? Un parámetro importante es el “estrato del reloj”. Este valor indica si el reloj presenta trazabilidad directa o indirecta hacia una fuente de tiempo estándar “oficial”, por ejemplo mediante un receptor GPS. Los relojes que presentan un enlace directo con dicha fuente de tiempo absoluta son los preferidos. Otro parámetro importante es la “variación de reloj”, una indicación de la estabilidad inherente del reloj.
Tal como se ha mencionado anteriormente, se puede modificar la configuración automática o por defecto si se desea. Para ello, el estándar IEEE1588 también define múltiples mensajes de gestión. Éstos le permiten consultar los juegos de datos del reloj, ajustar el tiempo real y cambiar el estado del reloj u otros parámetros de funcionamiento a través de la LAN.

Y entonces, ¿para qué sirve esta tecnología?
La adquisición de datos es una aplicación obvia del estándar IEEE1588. Muchas aplicaciones de adquisición de datos requieren la distribución de sensores por una gran área (por ejemplo, en instalaciones industriales o de comunicaciones inalámbricas o por cable). Pero incluso en aplicaciones centralizadas, es necesario sincronizar diferentes instrumentos o unidades de adquisición de datos. En todas las aplicaciones excepto las más triviales, es muy importante saber cuándo se realizaron las medidas individuales. La elevada precisión de temporización ofrecida por el IEEE1588 genera más posibilidades en el postprocesamiento y el análisis, lo cual a su vez permite una mejor comprensión. Sin el IEEE1588, sería necesario sincronizar los instrumentos mediante receptores de GPS independientes o utilizar una señal de disparo generada centralmente para la sincronización. La primera opción es cara y la segunda no resulta sencilla debido al efecto de retardo de propagación y al ruido de jitter de disparo.
Las pruebas funcionales son otra área que se beneficiará al máximo del IEEE1588. Con frecuencia es necesario aplicar estímulos en una secuencia predefinida y con una temporización exacta. Asimismo, es necesario medir o registrar la reacción de un dispositivo bajo prueba (DUT) en un punto predefinido en el tiempo. Hasta los escenarios más complejos resultan fáciles de implementar utilizando el disparo basado en tiempo que permite el estándar IEEE1588. Sin él, puede ser necesario generar una o varias señales de disparo de hardware y dirigirlas hacia los diversos instrumentos de una forma apropiada. El disparo basado en tiempo proporciona mucha más flexibilidad porque no está limitado por cableado físico y no experimenta problemas de calidad de la señal.

Resumen
El estándar IEEE1588 constituye una tecnología fascinante. Si está trabajando en aplicaciones de sistemas, téngalo en cuenta. Esta tecnología y las características que incorpora podrían hacer su vida más fácil. El PTP permite el registro en función del tiempo en todo el sistema, así como el disparo preciso basado en tiempo sin necesidad de un cableado sofisticado. Por consiguiente, presenta un nivel de flexibilidad sin precedentes en esta área.

Más información

El autor
Stefan Kopp está titulado en Informática por la Universidad de Educación Cooperativa en Stuttgart, Alemania. Ha trabajado con Agilent (antes HP) desde 1989 en diversos puestos, incluyendo el de director de proyecto para soluciones de pruebas personalizadas y representante de ventas. Su cargo actual es la de asesor en el área de automatización de pruebas y componentes de sistemas de prueba.