Protocolo de tiempo de red

El protocolo de tiempo de red, NTP, es cómo los ordenadores y dispositivos de una red coinciden en el momento. Un dispositivo pide un servidor de tiempo para el tiempo actual, corrige su propio reloj, y repite la solicitud a intervalos. SNTP es una variante más simple utilizada por dispositivos que necesitan menos precisión.

En los sistemas de energía, NTP es una de varias salidas que un servidor de tiempo proporciona, junto con PTP y IRIG-B. La hoja de datos del servidor de tiempo del fabricante da NTP/SNTP precisión de 10 milisegundos, contra la precisión PTP de 0.2 microsegundos, y afirma que PTP es preferido sobre NTP porque NTP pierde la precisión del tiempo GNSS. Esa diferencia decide qué protocolo utilizar: NTP se adapta a la tala de eventos y a la coordinación general; no se adapta a la protección o medida que necesita un acuerdo de submicrosecond.

Utilice esta guía como una explicación del protocolo cuando elija un servidor de tiempo. Los servidores públicos, los servidores gratuitos y las construcciones de aficionados no sustituyen a un servidor de tiempo por hardware en un sistema de energía. Para un sistema de energía, la fuente de tiempo debe ser un servidor local alimentado por señales de satélite, no un servidor público de internet.

Antes de ordenar un servidor de tiempo, confirme los sistemas de satélites disponibles en el sitio, los protocolos de salida que necesitan los dispositivos y los términos de entrega. Pida que la hoja de datos actual sea confirmada por escrito antes de ordenar.

Diseño de un servicio NTP para una red eléctrica

Diseñe el servicio de tiempo desde los dispositivos hacia fuera. Enumere los relés, registradores, contadores, controladores y servidores que tomarán la hora de red, y anote qué hace cada uno con ella: ordenación de eventos, registros de averías, intervalos de medida o simple visualización. Esa lista decide cuánta exactitud y resiliencia necesita el servicio, y qué dispositivos merecen la atención más cercana en la puesta en servicio. Un servicio de tiempo de red diseñado desde la página de catálogo del servidor tiende a ser elegante en el centro y erróneo en los bordes, donde realmente se hacen los registros.

Decida la jerarquía y el comportamiento ante fallos de antemano. Qué fuente siguen los servidores, qué servidor sigue cada dispositivo y qué ocurre cuando se pierde una fuente o un servidor deberían ser respuestas escritas, no descubrimientos. Acuerde la deriva que cada dispositivo puede mostrar antes de que alguien actúe, y cómo se notará la deriva: una comparación programada, una alarma o una comprobación integrada en otra rutina. El tiempo falla en silencio, así que el diseño debe incluir el darse cuenta, o el primer síntoma será un registro de evento que no puede conciliarse con su vecino.

Puesta en servicio y convivencia con el tiempo de red

Ponga en servicio por comparación. Después de la configuración, recorra la lista de dispositivos y compare la hora de cada dispositivo con la referencia acordada, registrando el resultado por dispositivo en lugar de declarar sincronizada toda la red en conjunto. Los dispositivos que no pueden alcanzarse o no pueden mantener la hora son hallazgos que deben resolverse o documentarse con sus consecuencias aceptadas abiertamente. Repita la comparación después de cambios de red, sustituciones de dispositivos y actualizaciones de firmware, porque cada uno de ellos puede devolver en silencio un dispositivo a una fuente errónea o a un desplazamiento erróneo.

Cuando se compre un servidor de tiempo para este trabajo, escriba la consulta desde la lista de dispositivos: los protocolos que hablan los dispositivos, las fuentes disponibles en el emplazamiento y el comportamiento de resiliencia requerido. Pida que el servidor ofrecido se confirme frente a esa lista por escrito, incluidas sus salidas para cualquier dispositivo que no pueda tomar la hora de red directamente. Conserve la comparación de puesta en servicio con la documentación de red, fechada y firmada, para que cuando dos registros discrepen en el futuro pueda examinarse el historial del propio servicio de tiempo antes de culpar a los dispositivos.

Incidentes de deriva de tiempo y lo que suelen significar

Cuando se encuentren dispositivos que discrepan sobre la hora, resista el impulso de simplemente corregir los relojes y seguir adelante. Un incidente de deriva es evidencia: un dispositivo que perdió su fuente, un cambio de red que rompió una ruta, una configuración restablecida en silencio o un servidor cuya propia fuente falló primero. Registre qué dispositivos derivaron, en cuánto y qué se encontró, antes de corregir nada, porque el patrón de deriva es el diagnóstico. Corrija después, compare de nuevo y archive el incidente con los registros del servicio de tiempo. Un servicio con un historial de incidentes honesto puede ser de confianza; uno con relojes misteriosamente perfectos suele tener un historial sin examinar.

Dé al servicio de tiempo una entrada en el proceso de cambio del emplazamiento, no solo en su documentación de red. Cualquier cambio en conmutadores, servidores, registradores o su configuración debe hacer una pregunta: ¿toca esto algo que hace, lleva o consume tiempo? Esa pregunta, hecha en el momento del cambio, evita la mayoría de los incidentes de deriva, que rara vez son causados por el propio servicio de tiempo y suelen serlo por un cambio vecino que nadie conectó con el tiempo. Mantenga la pregunta visible en el propio formulario de cambio, porque una regla que depende de la memoria será olvidada por exactamente el cambio que la necesitaba.

Qué confirmar antes de ordenar

Antes del pago, confirme el modelo, la especificación de la hoja de datos actual, la cantidad, el precio, el plazo de entrega y los términos de entrega, por escrito. Pida en su consulta que confirme los términos de pago, los términos de comercio y el tiempo de respuesta que debe esperar, en lugar de asumir cualquiera de ellos. Confirme el precio, el pedido mínimo y el plazo de entrega de su pedido con el proveedor por escrito antes del pago.