¿Cómo evitan los lanzamientos los segundos intercalares? ¿Por qué?

Un breve comentario en el programa de audio de BBC Crowd Science ¿Realmente existe el tiempo? La discusión de la lenta divergencia entre UTC y TAI ( IAT ) (tiempo coordinado y tiempo atómico internacional) dice que la NASA y la ESA, por ejemplo, evitan los lanzamientos alrededor de los segundos intercalares .

¿Es esto cierto? ¿Se hace por precaución, o incluso por exceso, o hay relojes mixtos, algunos con UTC y otros con IAT y compensaciones codificadas para cada lanzamiento? Actualmente la diferencia es de 37 segundos y ha habido 27 segundos bisiestos desde 1970.

En el pasado, no hubiera sido una gran carga evitarlos si un lanzamiento se consideraba un evento de unos pocos minutos o unas pocas horas, pero la duración de una misión suele ser de años o décadas, por lo que una misión completa casi nunca puede evitar completamente un evento. segundo intercalar.

Entonces, ¿cómo evitan los lanzamientos los segundos intercalares? ¿Y por qué?

Mi mente está aturdida. El vuelo espacial normalmente usa TAI que no tiene segundos bisiestos.
Porque por muy bien que crea que ha depurado su sistema, particularmente con condiciones únicas como segundos bisiestos, las cosas eventualmente se rompen ( ejemplo ). Si se trata de algún sitio web, entonces en última instancia no es un gran problema, pero si hay una cantidad no trivial de combustible explosivo en la línea, entonces, ¿qué tan dispuesto estás a tener un error aleatorio que realmente incendie las cosas?
@Joshua - Ojalá ese fuera el caso. Lamentablemente, no lo es.
Debido a que ya han tenido problemas con la conversión entre unidades métricas e imperiales , ¿por qué agregar otro error de conversión a la mezcla?
New Horizons alcanzará su objetivo de misión extendida el 1 de enero de 2019. . Me pregunto si la diferencia de tiempos también afectará a esa misión.
Este es un comentario tardío que pertenece al paréntesis (IAT). El acrónimo es TAI, punto. Es TAI (no IAT) en países de habla inglesa. Incluso es TAI en Rusia, China y otros países que normalmente no usan caracteres latinos.
@DavidHammen He hecho un ajuste, ¿está bien ahora o debería eliminarlo por completo? No recuerdo si hace cuatro años inventé yo mismo el acrónimo IAT o si lo había visto en alguna parte, pero ciertamente TAI es todo lo que veo ahora.

Respuestas (4)

Evitar los segundos bisiestos es fácil, no la lance el 30 de junio o el 31 de diciembre cuando se anuncia un segundo bisiesto, consulte https://en.wikipedia.org/wiki/Leap_second

Es difícil probar si los segundos intercalares durante un lanzamiento pueden causar problemas: los segundos intercalares ocurren solo una o rara vez dos veces al año, pero ha habido muchos años sin segundos intercalares.

En este siglo, se insertaron segundos intercalares solo en 2005, 2008, 2012, 2015 y 2016. Solo en 2012 y 2015 hubo segundos intercalares en junio. Desde la introducción de los segundos intercalares, solo se han utilizado los puntos de tiempo de junio y diciembre.

No hubo segundos bisiestos en los años 2017, 2018, 2019, 2020 y ninguno anunciado para 2021.

Tal vez "directo" sea una mejor palabra que "fácil". La programación de eventos de $ 10 a 100 millones es un proceso complicado que involucra todo tipo de compensaciones costosas, las ventanas de lanzamiento en sí mismas también pueden ser exigentes. ¿Seguro que siempre fue fácil en todas y cada una de las últimas 27 veces que se ha producido?
Creo que los lanzamientos que comienzan en un año y terminan en el próximo año se evitan de todos modos. De esta manera, la mayoría de los segundos bisiestos del pasado se evitaron de todos modos. ¿Hay algún ejemplo de un lanzamiento iniciado en los últimos días de diciembre?
¡Es una idea realmente interesante! Sería genial averiguar si siempre se evitan ciertas fechas recurrentes. Tal vez sea posible una búsqueda SatCat.
La prueba es fácil, básicamente es un escenario específico que se prueba en el terreno. Cualquier cosa importante podría probarse en el terreno, lo que uno busca es algún tipo de inestabilidad que ocurre después del cambio de tiempo, que puede probarse fácilmente con una simulación de Hardware-In-The-Loop.
¿Tú también? ;) ¡Tal vez "directo" es una mejor palabra que "fácil"!
@PearsonArtPhoto: El tiempo es realmente muy difícil de probar. Debe asegurarse de que cada reloj que pueda afectar el resultado esté sincronizado con el tiempo ficticio que está utilizando, o debe realizar la prueba durante un segundo bisiesto. Luego, debe probar todas las permutaciones posibles de la deriva del reloj en un reloj pero no en otro.
... e incluso si realiza su prueba durante un segundo bisiesto real, siempre existe el riesgo de que en algún lugar del sistema haya un supuesto cuadro "no crítico" que está recibiendo tiempo de los servidores NTP públicos... y todo funciona bien en la prueba, pero en el día real, el servidor NTP al que se ha esclavizado no puede declarar un segundo intercalar. O el servidor NTP público puede declarar falsamente un segundo bisiesto que en realidad no ocurrirá (he visto que esto sucede en la naturaleza con servidores NTP Pool de otro modo truechiming al menos un 30 de junio).
e incluso en esos días, simplemente evite el lanzamiento alrededor de la medianoche :)

No son solo lanzamientos. Es, bueno, todo. ¡Me vuelve loco!

El software de vuelo de naves espaciales casi siempre tiene la capacidad de ejecutar comandos de enlace ascendente en función del tiempo. ¿Pero qué escala de tiempo? Los sistemas de control operacional para naves espaciales casi siempre tienen la capacidad de emitir comandos cronometrados a las naves espaciales. ¿Pero qué escala de tiempo? Los diversos sistemas de análisis y planificación de misiones también dependen del tiempo. Pero una vez más, ¿qué escala de tiempo?

Algunos sistemas admiten TAI y UTC. Otros admiten la hora de GPS y UTC. Sin embargo, otros solo admiten GMT (hora del meridiano de Greenwich), que no existe desde 1973. Unos pocos admiten escalas de tiempo relativistamente correctas, así como UTC. La respuesta omnipresente es UTC (o GMT en el caso de sistemas heredados de algún milenio anterior). Entonces, lamentablemente, esta es la escala de tiempo única que casi siempre se usa.

Lamentablemente, esto significa que la nave espacial no debería estar haciendo nada crítico cerca de un límite de segundo bisiesto.

El espacio es difícil, aunque parece que lo hace innecesariamente más difícil. Me pregunto si el tiempo de GPS es generalmente al menos muy cercano a TAI, incluso si está desacoplado. ¿Es mejor una pregunta separada? Espera, es... ¡voilá! la pregunta del TAI .
@uhoh: el tiempo del GPS está separado del TAI por un desplazamiento constante.
@David Hammen, el desplazamiento entre el tiempo de GPS y TAI cambia con cada segundo bisiesto. Pero la mayor parte del año es constante.
@Uwe y DH sigamos discutiendo esa pregunta con la pregunta o la respuesta allí, ¡no aquí!
@Uwe y uhoh: mejor dicho, el tiempo del GPS está separado del TAI por un desplazamiento que varía muy poco con el tiempo.
"GMT (hora del meridiano de Greenwich), que no existe desde 1973" Tenga en cuenta que, de manera confusa, la escala de tiempo local utilizada en el Reino Unido todavía se conoce como "GMT", aunque en realidad es UTC. Entonces, GMT todavía "existe", solo que no en su forma original;)
Incluso una escala de tiempo para una nave espacial basada en segundos desde el inicio de la cuenta regresiva cero puede causar problemas si hubo un retraso en la cuenta regresiva. Podría ser necesaria una conversión de esta escala de tiempo a GPS, TAI o UTC. Si la nave espacial se mueve rápido durante años, ¿qué pasa con los efectos relativistas en el reloj de la nave espacial?
@Uwe: para cualquier nave espacial razonable menos que la deriva del reloj de su oscilador. Por otro lado, la diferencia entre los ajustes del pozo de gravedad está dentro del umbral de medición.
Es muy difícil averiguar sobre el papel continuo del Observatorio Real en la calibración UTC, porque había una escuela llamada "Royal Greenwich UTC" :(
Por lo que puedo decir, GMT no ha "existido" desde 1935, cuando pasó a llamarse Universal Time (ahora UT1). Creo que UTC todavía se basa en observaciones medias en Greenwich, con segundos intercalares para mantenerlo cerca de TAI.
@Joshua En un satélite GPS, la deriva del reloj de los relojes atómicos es más pequeña que los efectos relativistas. Se utiliza una corrección de los efectos relativistas para evitar una deriva de la posición estimada. La precisión de los relojes atómicos es de dos a tres órdenes de magnitud mejor que los efectos relativistas.
@Uwe: Al menos en los primeros satélites GPS, el reloj atómico está en el suelo. Los satélites GPS son tubos doblados.
@Joshua - Ese no es el caso. Cada satélite GPS lleva un reloj atómico, múltiples relojes atómicos con satélites GPS más recientes. Si bien los límites de masa significan que estos no son tan precisos como los relojes atómicos terrestres, sin embargo, son muy precisos.

La mayoría de los satélites con los que estoy familiarizado funcionan internamente en el tiempo del GPS, pero corrigen el tiempo mediante algún tipo de constante que se actualiza periódicamente para los segundos intercalares a UTC.

Para la instancia específica de un lanzamiento, es casi seguro que sea un reloj de misión o un tiempo de GPS, que se usa internamente. La mayoría de los cohetes tienen algún tipo de reloj GPS, que les permitirá encontrar su posición y mantener mediciones de tiempo extremadamente precisas.

Para los sistemas que pueden requerir un lanzamiento en cualquier momento (y esos existen), verificarán específicamente los segundos intercalares positivos y negativos para ver cómo reacciona el sistema ante ellos. Pero, en general, internamente usan el tiempo desde el lanzamiento o el tiempo del GPS para realizar un seguimiento, y no el tiempo UTC.

Entonces, cada vez que el Servicio Internacional de Rotación de la Tierra , también conocido como "la gente del segundo intercalar", decide un nuevo segundo intercalar, ¿cientos, si no miles, de satélites deben ser notificados? Entonces, ¿todas estas actualizaciones deben confirmarse para asegurarse de que el satélite reconozca la actualización de segundo bisiesto más reciente?
El GPS en realidad incluye una compensación en su campo, por lo que si tiene un GPS, puede actualizar su tiempo a través de eso. Además, supone que el tiempo es crítico, no lo es para muchos satélites. Pero en general sí, eso es algo que se debe hacer. Y sí, puede ser un dolor de cabeza, pero si es difícil, alguien encontrará una manera de automatizarlo.
@PearsonArtPhoto - Es peor que eso. cFE/CFS, principalmente del Goddard Space Flight Center, permite a los operadores de naves espaciales especificar comandos absolutos almacenados en TAI o UTC, codificados, con el valor predeterminado UTC (la hora GPS no es una opción). GMAT, también del Centro de Vuelo Espacial Goddard, aparentemente conoce UTC y TAI, pero no el tiempo de GPS. Cosmos, de Ball Aerospace, conoce UTC. SPICE, de JPL, conoce UTC y TT, pero no la hora GPS ni la hora TAI. Fíjate en el mínimo común denominador.
@uhoh: Básicamente, sí. Se hace de una manera bastante sólida, pero cualquier tecnología que dependa del GPS como referencia principal (y no se trata solo de naves espaciales: es su industria bancaria/comercial, su infraestructura de telecomunicaciones, su industria de transmisión de radio/televisión analógica y digital... básicamente cualquier cosa que dependa de en sincronización) necesita tener en cuenta los segundos bisiestos. Y estan. Simplemente no quiere arriesgarse a que salga mal en un momento crítico cuando se puede evitar fácilmente. Idealmente, no usaría una base de tiempo afectada en absoluto, pero la realidad dicta que los humanos quieren leer las marcas de tiempo en UTC en algún momento. & insectos.
Los segundos bisiestos de @LightnessRacesinOrbit de repente parecen malvados, justo a la altura de Chronovores ; de El monstruo del tiempo .
@uhoh: es verdad
@uhoh: Y para el lado del sistema de gestión de las cosas (concedido que esto no se usaría en trabajos críticos para la seguridad) no ayuda que algunos sistemas operativos en realidad no admitan segundos bisiestos; no hay 23:59:60 en Linux, nunca. Su cliente NTP (suponiendo que uno se esté ejecutando) simplemente hace girar el reloj más lentamente durante un minuto más o menos. ¿Cómo te gustan las manzanas? :) El tiempo es bastante difícil, pero el tiempo es un verdadero dolor en el culo.

Sospecho que una de las razones es la sincronización del marco de referencia. De hecho, si realiza una determinación orbital estadística, incluso un error de un segundo podría alterar su estimación de estado en una cantidad significativa durante un corto período de tiempo.

Cualquier desviación superior a unos pocos segundos también tendrá efectos significativos en las simulaciones. Por ejemplo, actualmente estoy trabajando en un proyecto en el que el cambio al marco True of Date del J2000 corrigió errores de deriva orbital significativos cuando todas las demás variables de la simulación de alta fidelidad se mantuvieron idénticas.

¿Cómo evitan los lanzamientos los segundos intercalares? ¿Por qué?
RespuestasAquíPolítica de privacidad1y, 0v