Wie vermeiden Starts Schaltsekunden? Wieso den?

Ein kurzer Kommentar in der BBC Crowd Science Audiosendung Does Time real Exist? Die Diskussion über die langsame Divergenz zwischen UTC und TAI ( IAT ) (koordinierte Zeit und internationale Atomzeit) besagt, dass NASA und ESA beispielsweise Starts um Schaltsekunden herum vermeiden .

Ist das wahr? Wird es aus Vorsicht oder sogar aus Überfluss gemacht, oder gibt es gemischte Uhren, einige laufen mit UTC und andere mit IAT und Offsets, die für jeden Start fest einprogrammiert sind? Derzeit beträgt der Unterschied 37 Sekunden und seit 1970 gab es 27 Schaltsekunden.

In der Vergangenheit wäre es keine große Belastung gewesen, sie zu vermeiden, wenn ein Start als ein Ereignis von wenigen Minuten oder wenigen Stunden angesehen wird, aber die Dauer einer Mission beträgt oft Jahre oder Jahrzehnte, sodass eine ganze Mission fast nie vollständig vermieden werden kann Schaltsekunde.

Wie also vermeiden Starts Schaltsekunden? Und warum?

Mein Verstand ist verwirrt. Die Raumfahrt verwendet normalerweise TAI, das keine Schaltsekunden hat.
Denn egal wie gut Sie Ihr System debuggt haben, insbesondere bei einmaligen Bedingungen wie Schaltsekunden, die Dinge gehen irgendwann kaputt ( Beispiel ). Wenn es sich um eine Website handelt, ist es letztendlich keine große Sache, aber wenn eine nicht unerhebliche Menge an explosivem Treibstoff auf dem Spiel steht, wie bereit sind Sie dann, dass ein zufälliger Fehler tatsächlich Dinge in Brand setzt?
@Joshua - Wenn das nur der Fall wäre. Leider ist es nicht.
Da sie bereits Probleme mit der Umrechnung zwischen metrischen und imperialen Einheiten hatten, warum also noch einen Umrechnungsfehler hinzufügen?
New Horizons wird sein erweitertes Missionsziel am 1. Januar 2019 erreichen . . Ich frage mich, ob der Zeitunterschied diese Mission auch beeinflussen wird.
Dies ist ein später Kommentar, der sich auf die Klammer (IAT) bezieht. Das Akronym ist TAI, Punkt. In englischsprachigen Ländern ist es TAI (nicht IAT). Es ist sogar TAI in Russland, China und anderen Ländern, die normalerweise keine lateinischen Schriftzeichen verwenden.
@DavidHammen Ich habe eine Anpassung vorgenommen, geht das jetzt oder soll ich komplett löschen. Ich kann mich nicht erinnern, ob ich vor vier Jahren das Akronym IAT selbst erfunden habe oder ob ich es irgendwo gesehen habe, aber sicherlich ist TAI alles, was ich jetzt sehe.

Antworten (4)

Schaltsekunden zu vermeiden ist einfach, starten Sie nicht am 30. Juni oder 31. Dezember, wenn eine Schaltsekunde angekündigt wird, siehe https://en.wikipedia.org/wiki/Leap_second

Es ist schwierig zu testen, ob Schaltsekunden beim Start Probleme verursachen können: Schaltsekunden treten nur einmal oder selten zweimal im Jahr auf, aber es gab viele Jahre ohne Schaltsekunde.

In diesem Jahrhundert wurden Schaltsekunden nur in den Jahren 2005, 2008, 2012, 2015 und 2016 eingefügt. Nur 2012 und 2015 gab es Schaltsekunden im Juni. Seit der Einführung der Schaltsekunde werden nur noch die Zeitpunkte im Juni und Dezember verwendet.

In den Jahren 2017, 2018, 2019, 2020 wurden keine Schaltsekunden und für 2021 auch keine angekündigt.

Vielleicht ist „geradeaus“ ein besseres Wort als „einfach“. Die Planung von Veranstaltungen im Wert von 10 bis 100 Millionen US-Dollar ist ein komplizierter Prozess, der alle Arten von teuren Kompromissen beinhaltet. Auch die Startfenster selbst können anspruchsvoll sein. Bist du sicher, dass es bei jedem der letzten 27 Male, in denen es passiert ist, immer einfach war?
Ich denke, Starts, die in einem Jahr beginnen und im nächsten Jahr enden, werden sowieso vermieden. Auf diese Weise wurden ohnehin die meisten Schaltsekunden der Vergangenheit vermieden. Gibt es ein Beispiel für einen Start, der in den letzten Dezembertagen begonnen hat?
Das ist eine wirklich interessante Idee! Es wäre toll herauszufinden, ob bestimmte wiederkehrende Termine immer vermieden werden. Eventuell ist eine SatCat-Suche möglich.
Das Testen ist einfach, im Grunde ist es ein bestimmtes Szenario, das Sie vor Ort testen. Alles Wichtige könnte am Boden getestet werden, was man sucht, ist eine Art Instabilität, die nach der Zeitumstellung auftritt, was leicht mit einer Hardware-in-the-Loop-Simulation getestet werden kann.
Du auch? ;) Vielleicht ist "geradeaus" ein besseres Wort als "einfach"!
@PearsonArtPhoto: Zeit ist wirklich schwer zu testen. Sie müssen sicherstellen, dass jede Uhr, die möglicherweise das Ergebnis beeinflusst, auf die von Ihnen verwendete fiktive Zeit synchronisiert wird, oder Sie müssen den Test während einer Schaltsekunde durchführen. Dann müssen Sie jede mögliche Permutation der Uhrendrift an einer Uhr testen, aber nicht an einer anderen.
... und selbst wenn Sie Ihren Test während einer echten Schaltsekunde durchführen, besteht immer die Gefahr, dass sich irgendwo im System eine vermeintlich "unkritische" Box befindet, die von öffentlichen NTP-Servern Zeit erhält ... und alles funktioniert der Test, aber an dem tatsächlichen Tag, an dem der NTP-Server, an dem er sich versklavt hat, keine Schaltsekunde deklariert. Oder der öffentliche NTP-Server kann fälschlicherweise eine Schaltsekunde deklarieren, die nicht tatsächlich auftritt (ich habe dies in freier Wildbahn mit ansonsten Truechiming-NTP-Pool-Servern an mindestens einem 30. Juni gesehen).
und selbst an diesen Tagen sollten Sie es einfach vermeiden, um oder gegen Mitternacht zu starten :)

Es sind nicht nur Starts. Es ist, nun ja, alles. Es macht mich wahnsinnig!

Flugsoftware für Raumfahrzeuge hat fast immer die Fähigkeit, Uplink-Befehle basierend auf Zeit auszuführen. Aber welcher Zeitraum? Die Betriebssteuersysteme für Raumfahrzeuge haben fast immer die Fähigkeit, zeitgesteuerte Befehle an Raumfahrzeuge auszugeben. Aber welcher Zeitraum? Die verschiedenen Missionsplanungs- und Analysesysteme sind auch zeitabhängig. Aber noch einmal, in welcher Zeitskala?

Einige Systeme unterstützen sowohl TAI als auch UTC. Andere unterstützen GPS-Zeit sowie UTC. Wieder andere unterstützen nur GMT (Greenwich Mean Time), die es seit 1973 nicht mehr gibt. Einige wenige unterstützen relativistisch korrekte Zeitskalen sowie UTC. Die allgegenwärtige Antwort ist UTC (oder GMT im Fall von Legacy-Systemen aus einem früheren Jahrtausend). Leider ist dies die eine Zeitskala, die fast immer verwendet wird.

Dies bedeutet leider, dass Raumfahrzeuge in der Nähe einer Schaltsekundengrenze nichts Kritisches tun sollten.

Der Weltraum ist hart, das klingt aber so, als würde es ihn unnötig erschweren. Ich frage mich, ob die GPS-Zeit im Allgemeinen zumindest sehr nahe an der TAI liegt, selbst wenn sie nicht gekoppelt ist? Ist eine separate Frage besser? Warten Sie, es ist ... voila! die Frage du TAI .
@uhoh - Die GPS-Zeit ist durch einen konstanten Offset von der TAI getrennt.
@David Hammen Der Versatz zwischen GPS- und TAI-Zeit ändert sich mit jeder Schaltsekunde. Aber die meiste Zeit des Jahres ist es tatsächlich konstant.
@Uwe und DH lasst uns diese Frage mit der Frage oder Antwort dort weiter diskutieren, nicht hier!
@Uwe und uhoh: Besser gesagt, die GPS-Zeit ist von der TAI durch einen Offset getrennt, der mit der Zeit sehr leicht variiert.
„GMT (Greenwich Mean Time), die es seit 1973 nicht mehr gibt“ Beachten Sie, dass die in Großbritannien verwendete lokale Zeitskala verwirrenderweise immer noch als „GMT“ bezeichnet wird, obwohl es sich tatsächlich um UTC handelt. GMT "existiert" also immer noch, nur nicht in seiner ursprünglichen Form ;)
Sogar eine Zeitskala für ein Raumfahrzeug, die auf Sekunden seit dem Start-Countdown Null basiert, kann Probleme verursachen, wenn es eine Countdown-Verzögerung gab. Eventuell ist eine Umrechnung dieser Zeitskala auf GPS, TAI oder UTC erforderlich. Wenn sich das Raumfahrzeug jahrelang schnell bewegt, was ist dann mit relativistischen Effekten auf die Uhr des Raumfahrzeugs?
@Uwe: Für jedes vernünftige Raumschiff weniger als die Taktdrift deines Oszillators. Andererseits liegt die Differenz zwischen den Gravitationsbrunneneinstellungen innerhalb der Messschwelle.
Es ist sehr schwer herauszufinden, welche Rolle das Royal Observatory weiterhin bei der UTC-Kalibrierung spielt, da es eine Schule namens "Royal Greenwich UTC" gab :(
Soweit ich das beurteilen kann, „existiert“ GMT seit 1935 nicht mehr, als sie in Universal Time (jetzt UT1) umbenannt wurde. Ich glaube, UTC basiert immer noch auf mittleren Beobachtungen in Greenwich, mit Schaltsekunden, um es in der Nähe von TAI zu halten.
@Joshua Bei einem GPS-Satelliten ist die Uhrendrift der Atomuhren kleiner als die relativistischen Effekte. Es wird eine Korrektur der relativistischen Effekte verwendet, um ein Driften der geschätzten Position zu vermeiden. Die Genauigkeit der Atomuhren ist zwei bis drei Größenordnungen besser als die der relativistischen Effekte.
@Uwe: Zumindest bei den ersten GPS-Satelliten ist die Atomuhr am Boden. Die GPS-Satelliten sind gebogene Rohre.
@Joshua - Das ist nicht der Fall. Jeder GPS-Satellit trägt eine Atomuhr, mehrere Atomuhren mit neueren GPS-Satelliten. Diese sind zwar aufgrund von Massenbeschränkungen nicht so genau wie bodengestützte Atomuhren, aber dennoch sehr genau.

Die meisten Satelliten, mit denen ich vertraut bin, arbeiten intern in GPS-Zeit, korrigieren die Zeit jedoch durch eine Art Konstante, die regelmäßig für Schaltsekunden auf UTC aktualisiert wird.

Für den speziellen Fall eines Starts wäre es mit ziemlicher Sicherheit entweder eine Missionsuhr oder eine GPS-Zeit, die intern verwendet wird. Die meisten Raketen haben eine Art GPS-Uhr, die es ihnen ermöglicht, ihre Position zu finden und extrem genaue Zeitmessungen durchzuführen.

Bei Systemen, die möglicherweise jederzeit gestartet werden müssen (und die gibt es), werden sie speziell nach positiven und negativen Schaltsekunden suchen, um zu sehen, wie das System darauf reagiert. Aber im Allgemeinen verwenden sie intern entweder die Zeit seit dem Start oder die GPS-Zeit, um den Überblick zu behalten, und nicht die UTC-Zeit.

Jedes Mal, wenn der Internationale Erdrotationsdienst , auch bekannt als „die Schaltsekundenmenschen“, über eine neue Schaltsekunde entscheidet, müssen Hunderte, wenn nicht Tausende von Satelliten benachrichtigt werden? Dann müssen alle diese Aktualisierungen bestätigt werden, um sicherzustellen, dass der Satellit die neueste Schaltsekunden-Aktualisierung bestätigt?
GPS enthält tatsächlich einen Offset in seinem Feld. Wenn Sie also ein GPS haben, können Sie Ihre Zeit darüber aktualisieren. Außerdem gehen Sie davon aus, dass Zeit kritisch ist, nicht für viele Satelliten. Aber im Allgemeinen ja, das ist etwas, was getan werden sollte. Und ja, es kann ein bisschen Kopfschmerzen bereiten, aber wenn es schwierig ist, wird jemand einen Weg finden, es zu automatisieren.
@PearsonArtPhoto - Es ist schlimmer als das. cFE/CFS, hauptsächlich vom Goddard Space Flight Center, ermöglicht es den Betreibern von Raumfahrzeugen, gespeicherte absolute Befehle entweder in TAI oder UTC fest codiert anzugeben, wobei die Standardeinstellung UTC ist (GPS-Zeit ist keine Option). GMAT, ebenfalls vom Goddard Space Flight Center, kennt anscheinend UTC und TAI, aber keine GPS-Zeit. Cosmos von Ball Aerospace kennt UTC. SPICE von JPL kennt UTC und TT, aber keine GPS-Zeit oder TAI-Zeit. Beachten Sie den kleinsten gemeinsamen Nenner.
@uhoh: Grundsätzlich ja. Es wird auf ziemlich robuste Weise durchgeführt, aber jede Technologie, die sich auf GPS als primäre Referenz stützt (und das sind nicht nur Raumfahrzeuge: das ist Ihre Banken-/Handelsbranche, Ihre Telekommunikationsinfrastruktur, Ihre analoge und digitale Radio-/Fernsehübertragungsbranche ... im Grunde alles, was sich darauf verlässt on sync) muss sich der Schaltsekunden bewusst sein. Und sie sind. Sie wollen nur nicht riskieren, dass es zu einem kritischen Zeitpunkt schief geht, wenn es leicht zu vermeiden ist. Idealerweise würden Sie überhaupt keine betroffene Zeitbasis verwenden, aber die Realität schreibt vor, dass Menschen irgendwann Zeitstempel in UTC lesen möchten. & Fehler.
@LightnessRacesinOrbit Schaltsekunden scheinen plötzlich böse zu sein, genau dort oben mit Chronovores ; aus Das Zeitmonster .
@uhoh: Es ist wahr
@uhoh: Und für die Verwaltungssystemseite (vorausgesetzt, dies würde nicht für sicherheitskritische Arbeiten verwendet werden) hilft es nicht, dass einige Betriebssysteme keine Schaltsekunden unterstützen. Unter Linux gibt es niemals 23:59:60. Sein NTP-Client (vorausgesetzt, einer läuft) dreht die Uhr nur etwa eine Minute lang besonders langsam. Wie magst du die Äpfel? :) Timing ist schwer genug, aber Zeit ist eine echte Nervensäge.

Ich vermute, dass einer der Gründe in der Synchronisation des Referenzrahmens liegt. Bei der statistischen Orbitalbestimmung kann sogar eine Fehlersekunde Ihre Zustandsschätzung für kurze Zeit um einen erheblichen Betrag verfälschen.

Jede Abweichung, die größer als ein paar Sekunden ist, hat auch erhebliche Auswirkungen auf Simulationen. Zum Beispiel arbeite ich derzeit an einem Projekt, bei dem der Wechsel zum True-of-Date-Frame vom J2000 erhebliche orbitale Driftfehler korrigierte, wenn alle anderen Variablen der High-Fidelity-Simulation identisch blieben.