Softwarebug im F-22 Kampfjet!

[Sandswind]

Da ging es doch ganz speziell um das neue Jahrtausend.
Der Wechsel des Wochentages ist eigentlich sowas von normal - an diese Möglichkeit denkt man schlicht nicht.

Man dürfte aber bei den Softwareschmieden dahingehend sensibilisiert sein. Immerhin war das damals eine große Nummer, die einem im Gedächtnis bleibt. Daher müsste man sich generell bei solchen Datums- und Zeitwechseln der möglichen Problematik bewusst sein. Zumindest stelle ich mir das als Laie so vor.

[Nighthawk_]

Man dürfte aber bei den Softwareschmieden dahingehend sensibilisiert sein.

Ich verstehe deine Logik nicht ganz.
Wie schlägst du denn die Brücke vom Millenniumbug zu dem Softwarebug der F-22A? Schön, es hat beides oberflächlich mit der Datumsangabe zu tun - soweit man das beurteilen kann liegen die Fehlerquellen aber wo vollkommen anders. Ich als informierter Laie () verstehe schon, das man das bei derartig umfangreichen und brandneuen Programmcodes übersehen kann.
Womöglich wurde dahingehen ja getestet - der Fehler trat halt aus irgendwelchen Gründen nicht auf. Durchaus möglich, aber das können wir mangels Information schlecht beurteilen.
So bleibt eigentlich nur darauf hinzuweisen, dass Kinderkrankheiten bei einem Kampfjet normal sind und das Problem in Rekordzeit behoben wurde.

[Sandswind]

Schön, es hat beides oberflächlich mit der Datumsangabe zu tun - soweit man das beurteilen kann liegen die Fehlerquellen aber wo vollkommen anders.

Soweit ich das überblicken kann, liegen die Fehlerquellen eben nicht woanders. Sobald die Software einen Datumswechsel ausführen muss, stürzt sie ab. Nichts anderes war der Milleniums-Bug. Wie gesagt kenne ich mich damit beim besten Willen nicht aus, aber hochbezahlte Spitzenkräfte schon. Die müssten doch einen populären Fehler wie den erwarten können.

[Nighthawk_]

Soweit ich das überblicken kann, liegen die Fehlerquellen eben nicht woanders. Sobald die Software einen Datumswechsel ausführen muss, stürzt sie ab. Nichts anderes war der .

Wie gesagt, an der Oberfläche mag das schon so aussehen.
Aber jetzt frag doch mal weiter.
Warum die Navigationssoftware abgestürzt ist und warum es einen Milleniums-Bug geben könnte.
Und schon hast und zwei ganz unterschiedliche Fehlerquellen.
Einmal gab es halt nur zwei Stellen für die Jahreszahlen und bei anderen gibt es irgendeinen Programmierfehler im Programmcode.
Vielleicht was ganz harmloses, Zahlendreher oder so.
Und deshalb: Das eine hat mit dem anderen wenig bis gar nichts zu tun.
So halt meine Auffassung dazu.
Ist schwer das abschließend zu beurteilen, schließlich wissen wir so gut wie nichts darüber.

[Sandswind]

Einmal gab es halt nur zwei Stellen für die Jahreszahlen und bei anderen gibt es irgendeinen Programmierfehler im Programmcode.

Beides sind Programmierfehler, denn die fehlenden Stellen erscheinend ja nicht per Zufall. Sie sind ebenso ins Programm eingegeben worden, wie der hier vorliegende Fehler.

[Nighthawk_]

Aber der Fehler lag eben nicht in der Nähe des Milleniumbugs (den man in der Software von vorne herein wohl nie drin hatte).
Was hilft es dir denn, wenn du an einer Stelle im Programmcode weißt, da hätte leicht ein Fehler sein können?
Der Fehler einige Tausend Zeilen darunter oder darüber hat damit nichts zu tun.
Gehört zwar beides im weitesten Sinne zu den Datumsangaben, aber sonst gibt es da keine logische Verbindung.

[blueflash]

Das war ein Programmierfehler in der Navigationssoftware, was interessieren da Echtzeitsysteme.

Wenn man schon nichts weiss, dann kann man sich auch mal erklären lassen, wie sich die Sachen verhalten. Aber manchmal bleibt man lieber auf seinem Unwissen sitzen, nicht?

@alle die es interessiert:
Wie kann die Datumsgrenze die Nav-Software abstürzen lassen?

Natürlich gibt es eine Menge Möglichkeiten, aber um dem Durchschnittscomputernutzer mal klar zu machen, worum es hier geht, nehme ich mal eine Möglichkeit aus dem Betriebssystembereich.

1. Was ist ein Echtzeitsystem?
Bei dynamischen Systemen mit Computersteuerung kommt es, im Gegensatz zum Desktop PC, darauf an, bestimmte Eingabewerte möglichst zeitnah mit Ausgaben zu verknüpfen. Nach einer gewissen Zeit verliert die Ausgabe ihren Wert. Mal ganz allgemein gesprochen. Paradebeispiel ist hier der Airbag, wenn der Chip nicht noch vor dem Aufprall des Kopfes auf dem Lenkrad entscheidet, ob der Airbag geöffnet werden soll, dann kann er es auch lassen. Es gilt also Zeitgrenzen einzuhalten. Wenn diese Zeitgrenzen zwischen Anfang der Berechnung und Ende nicht eingehalten werden und der Ausgabewert daraufhin sofort völlig wertlos ist, spricht man von harten Echtzeitsystemen (bei kontinuierlichem Wertverlust von weichen).

2. Wo ist das Problem?
Früher hatte man relativ einfache Systeme, die ein Programmierer relativ leicht überblicken konnte. Einfach gesprochen: Es gab einen Chip und ein Programm. Die Ausführungszeit konnte man dann einfach anhand Chiptaktung und Befehlszahl ausrechnen. Heutzutage sieht die Sache komplizierter aus: Es gibt meist wenige Ressourcen (Prozessoren, Bus, etc.), um die einige Prozesse konkurrieren. Um die Prozesse nun auf die Ressourcen zu verteilen und die Echtzeitanforderungen zu erfüllen, werden die Prozesse verwaltet (scheduling). Das kann durch einen priviligierten Prozess oder ein Abstimmungsprotokoll der beteiligten Prozesse erfolgen. Insbesondere wenn verschiedene Geräte über einen Bus miteinander kommunizieren, verwendet man gerne entsprechende Protokolle. Ein gutes und interessantes Beispiel ist der Canbus aus der Automobiltechnologie. Hier stimmen sich die Geräte über eingebaute Uhren über ihre Zugriffszeiten auf den Bus ab um z.B. dafür zu sorgen, dass die Ergebnisse des Navigationscomputers rechtzeitig mit den Daten des GPS Systems versorgt werden.

3. Was kann passiert sein?
Angenommen, der Navigationscomputer beteiligt sich an dem Busprotokoll. Dazu teilt er in regelmäßigen Abständen seine Systemzeit den anderen Geräten mit, damit die untereinander die natürlichen Abweichungen ihrer Quarztkristalle ausgleichen können (sie einigen sich quasi auf eine durchschnittliche Uhrzeit). Diese Differenzen werden normalerweise in Form von Offsets gespeichert, die auf die eigene Uhrzeit addiert werden. Wenn der Navigationscomputer aber seine Uhrzeit durch den Überflug der Datumsgrenze ändert, ergibt sich ein riesiger Unterschied zu den anderen Geräten am Bus. Jetzt kann, je nach Protokoll, alles mögliche passieren. Denkbar ist zum Beispiel, dass jetzt der Navigationscomputer den Bus für 24h anforderte und somit alle anderen Geräte von der Kommunikation abhielt. Auf jeden Fall ist der normale Gang der Dinge plötzlich gestört.

Noch Fragen ?