Connect with us

Künstliche Intelligenz

Aus Softwarefehlern lernen – Teil 3: Eine Marssonde gerät außer Kontrolle


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

In der modernen Softwareentwicklung ist Nebenläufigkeit allgegenwärtig. Selbst kleine Anwendungen laufen oft auf Systemen mit mehreren Kernen, interagieren mit Datenbanken, warten auf Netzwerkantworten oder teilen sich Ressourcen wie Dateien und Speicherbereiche. In verteilten Systemen und Embedded-Software kommt noch hinzu, dass verschiedene Prozesse aufeinander reagieren müssen, oft unter Echtzeitbedingungen. Die Praxis zeigt: Sobald mehrere Dinge gleichzeitig passieren können, entstehen neue Fehlerklassen, die sich in seriellen Programmen nie gezeigt hätten.


Golo Roden

Golo Roden

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Die Teile der Serie „Aus Softwarefehlern lernen“:

Ein berühmtes Beispiel ist der Mars Pathfinder, eine NASA-Mission aus dem Jahr 1997. Die Landung selbst war ein spektakulärer Erfolg – die Sonde setzte sanft auf dem Mars auf und begann, Daten zu senden. Doch kurz darauf kam es zu sporadischen Systemabstürzen und automatischen Resets, die das Team am Boden in Alarmbereitschaft versetzten.

Die Ursache war eine Priority Inversion, ein klassisches Concurrency-Problem. In einem Echtzeitbetriebssystem gibt es Aufgaben mit unterschiedlicher Priorität. Hohe Priorität bedeutet: Diese Aufgabe soll möglichst sofort laufen, sobald sie bereit ist. Niedrige Priorität darf sie nicht blockieren.

Auf dem Pathfinder lief eine solche hochpriorisierte Aufgabe, die Daten vom Wettersensor verarbeitete. Sie benötigte jedoch Zugriff auf eine gemeinsame Ressource – in diesem Fall einen Mutex, der von einer niedrig priorisierten Aufgabe gehalten wurde. Diese niedrig priorisierte Aufgabe wurde wiederum von einer mittel priorisierten Aufgabe ständig verdrängt. Das Ergebnis: Die hochpriorisierte Aufgabe wartete indirekt auf eine niedrige, die nie zum Zuge kam.

Dieses Phänomen der „Umkehrung der Prioritäten“ führte dazu, dass das System in bestimmten Lastsituationen hängen blieb und schließlich neu startete. Die Lösung war im Prinzip einfach: Die Entwicklerinnen und Entwickler aktivierten Priority-Inheritance im Echtzeitbetriebssystem VxWorks. Dadurch erbte die blockierende, niedrig priorisierte Aufgabe vorübergehend die hohe Priorität, sobald eine höherwertige Aufgabe auf sie wartete. Der Knoten löste sich, und die Abstürze verschwanden.

Dieses Beispiel ist lehrreich, weil es gleich mehrere typische Muster verdeutlicht:

  • Nebenläufigkeitsfehler sind schwer zu reproduzieren: Sie treten oft nur unter bestimmten Lastprofilen auf.
  • Redundanz oder Wiederholungen helfen nicht automatisch: Wenn der Fehler im Design liegt, trifft er alle Instanzen gleichermaßen.
  • Kleinste Details im Scheduling können den Unterschied machen: Die Software kann tausendmal korrekt laufen und beim tausend-und-ersten Mal ausfallen.

In modernen Anwendungen können ähnliche Probleme in Form von Deadlocks, Race Conditions oder Livelocks auftreten. Diese zeigen sich meist nicht im lokalen Testlauf, sondern erst in der Produktion, wenn reale Last und reale Parallelität wirken. Doch wie lassen sich solche Fehler vermeiden?

  1. Klare Lock-Hierarchien: Wenn mehrere Ressourcen gesperrt werden, sollte immer in derselben Reihenfolge gelockt werden.
  2. Prioritätsprotokolle nutzen: Mechanismen wie Priority Inheritance oder Priority Ceiling sind in vielen Echtzeitbetriebssystemen und sogar in modernen Frameworks verfügbar.
  3. Nebenläufigkeit entkoppeln: Statt gemeinsame Zustände direkt zu sperren, können Architekturen mit Message Passing oder Actor-Modellen Race Conditions vermeiden.
  4. Deterministische Tests und Simulationen: Spezielle Testframeworks können Prozesse gezielt verzögern oder Scheduler manipulieren, um seltene Konflikte reproduzierbar zu machen.
  5. Telemetrie und Monitoring: Auch im Betrieb sollte sichtbar sein, wenn Locks ungewöhnlich lange gehalten werden.

Für Teams, die Web-Backends oder Cloud-Services entwickeln, zeigt sich übrigens dieselbe Gefahr, nur in geringfügig anderer Form: Datenbanktransaktionen, verteilte Caches oder konkurrierende API-Requests können ähnliche Effekte haben. Ein langsamer Hintergrundprozess blockiert einen Lock, während eine Flut von parallelen Requests diesen Zustand eskalieren lässt.

Die Lehre aus dem Pathfinder-Vorfall ist daher zeitlos: Nebenläufigkeit ist kein kostenloser Performance-Booster, sondern ein komplexes System, das Entwicklerinnen und Entwickler explizit entwerfen und überwachen müssen. Wer Concurrency als Randthema behandelt, wird früher oder später auf schwer reproduzierbare und potenziell katastrophale Fehler stoßen.

Diese Artikelserie stellt neun typische Fehlerklassen vor, die in der Praxis immer wieder auftauchen – unabhängig von Branche oder Technologie. In jeder Kategorie wird die Serie ein konkretes Beispiel vorstellen, dessen Ursachen analysieren und daraus ableiten, was Softwareentwicklerinnen und Softwareentwickler langfristig lernen können.

Im nächsten Teil lesen Sie: Zeit, Kalender und Geografie: Wenn die Uhr nicht das misst, was man denkt.


(who)



Source link

Künstliche Intelligenz

Radioaktives Radon: Warum es ein unterschätztes Risiko ist


Auf der Maker Faire 2024 sprach mich Make-Chefredakteur Daniel Bachfeld über einen Ergänzungsartikel zum Taupunktlüfter an. Dieser sollte beschreiben, wie man dem Edelgas Radon auf die Spur kommt und wie ein Taupunktlüfter es aus dem Haus entfernen kann. Aus dieser einfachen Frage ist eines meiner umfangreichsten Projekte entstanden, für das ich auch Informationen bei Fachfirmen, Universitäten und dem Bundesamt für Strahlenschutz einholen musste. Und, ohne zu übertreiben: Es geht bei diesem Thema um Leben und Tod!

Meine Erkenntnisse sind in einem weiteren Artikel aufsplittet.

  • Was ist Radon?
  • Welche Gefahr geht davon aus?
  • Wie können wir es mit Maker-Mitteln detektieren?

Checkliste

Zeitaufwand:

4 Stunden (Ballonexperiment)

Kosten:

etwa 60 Euro (Geigerzähler für Ballonexperiment)

Mehr zum Thema

Material

Werkzeug

  • Geigerzähler etwa Bosean FS-5000 (50 Euro)

Bei Radon handelt es sich um ein radioaktives Edelgas, das in der Erdkruste natürlicherweise vorkommt. Es entsteht durch den Zerfall von Uran und Thorium, die in sehr vielen Gesteinen und Böden vorkommen. Radon selbst ist farb-, geruchs- und geschmackslos, was bedeutet, dass es weder mit bloßem Auge noch mit anderen Sinnen wahrgenommen werden kann. Zudem ist es schwerer als Luft, was später noch eine wichtige Rolle spielen wird.


Das war die Leseprobe unseres heise-Plus-Artikels „Radioaktives Radon: Warum es ein unterschätztes Risiko ist“.
Mit einem heise-Plus-Abo können Sie den ganzen Artikel lesen.



Source link

Weiterlesen

Künstliche Intelligenz

TDWI München 2026: Vorträge für die Konferenz zu Data, Analytics und KI gesucht


Vom 23. bis 25. Juni 2026 findet die TDWI München statt. Die Konferenz hat sich als Wissensdrehscheibe und Netzwerkplattform für die Daten-Community etabliert.

Weiterlesen nach der Anzeige

Bis Ende Januar 2026 sucht der Veranstalter heise conferences nach Vorträgen für die TDWI München zu Themen von Datenarchitektur und Strategie über Data Science und KI bis zur Datenkultur.

Ein Programmbeirat aus Fachexpertinnen und -experten kuratiert das Programm und sucht aus den Einreichungen etwa 120 Vorträge für die TDWI München aus.

Der Call for Contributions ist bis zum 26. Januar 2026 geöffnet. Die Konferenz bietet zwölf thematische Tracks. Als neue Schwerpunkte kommt 2026 Industrial Data & AI hinzu. Daneben gibt es unter anderem folgende Tracks:

  • Data Architecture
  • Data Management
  • Data Culture
  • Data Science & AI
  • Data Strategy & Data Governance
  • Self-Service BI & Analytics
  • Branchentrack Finanzindustrie

Projekterfahrungen und -berichte sind ebenso gewünscht wie Trends und Ausblicke zu den Themen der TDWI München. Wer mit einem Vortrag auf der Konferenz dabei sein möchte, aber noch keine Speaker-Erfahrung hat, hat die Chance, auf einen Mentor aus der Community zurückzugreifen.

Anwenderstorys sind besonders gern gesehen. Die Programmgestalter freuen sich zudem über Vorträge zu innovativen Formaten. So gab es in den letzten Jahren beispielsweise eine Chess Clock Debate und ein Dashboard-Karaoke.

Weiterlesen nach der Anzeige


(rme)



Source link

Weiterlesen

Künstliche Intelligenz

Missing Link: Hubble Deep Field – ein Foto und seine Geschichte


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Das Bild war eine Sensation: Fast sechs Tage lang hatte das Hubble Space Telescope aus der Milchstraße in einen Bereich des Sternenhimmels außerhalb der Milchstraße gespäht. Von der Erde aus betrachtet, galt dieser Himmelsbereich als leer.

Weiterlesen nach der Anzeige

Die US-Raumfahrtbehörde NASA musste liefern. Das damals neue Weltraumteleskop drohte zu einem Millionen US-Dollar teuren Flop zu werden: Der Bau hatte sich verzögert, der Start nach der Explosion des Space Shuttle Challenger 1986 ebenfalls. Als es 1990 endlich im All war, kam die große Enttäuschung: Die Optik hatte einen gravierenden Fehler, die Bilder, die das Teleskop lieferte, waren unbrauchbar.




Was fehlt: In der rapiden Technikwelt häufig die Zeit, die vielen News und Hintergründe neu zu sortieren. Am Wochenende wollen wir sie uns nehmen, die Seitenwege abseits des Aktuellen verfolgen, andere Blickwinkel probieren und Zwischentöne hörbar machen.

Um das Hubble-Teleskop trotzdem nutzen zu können, ließ die NASA eine Korrekturlinse anfertigen, die ein Space Shuttle Ende 1993 zu dem Teleskop brachte, das zu dem Zeitpunkt schon mehr als drei Jahre in Orbit herumdümpelte. In mehreren Außeneinsätzen setzten die Thomas Akers, Jeffrey Hoffman, Story Musgrave und Kathryn C. Thornton Hubble eine neue Brille auf.

Endlich funktionierte das Teleskop – und jetzt musste es liefern. Und es lieferte: Das Bild des vermeintlich leeren Himmelsbereichs zeigte Millionen von Sternen in tausenden Galaxien, von denen einige noch aus der Frühzeit des Universums stammen. Das „Hubble Deep Field“ ist heute eines der ikonischsten Fotos der Weltraumforschung, das unseren Blick auf das Universum verändert hat und zu dem mehrere hundert Fachartikel veröffentlicht wurden.


Das Hubble Deep Field aus dem Jahr 1995

Das Hubble Deep Field aus dem Jahr 1995

Das Hubble Deep Field aus dem Jahr 1995

(Bild: NASA)

Genauso interessant wie das Foto selbst und die wissenschaftlichen Erkenntnisse daraus ist allerdings seine Entstehungsgeschichte. Hier war weniger die Wissenschaft als vielmehr mangelndes Qualitätsmanagement in einem US-Raumfahrtunternehmen sowie die US-Finanzpolitik in Person eines späteren Friedensnobelpreisträgers involviert. Und diese Geschichte ist mindestens so spannend wie die wissenschaftlichen Entdeckungen, die später aus dem Foto folgten.

Weiterlesen nach der Anzeige

Rückblick: Es ist das Jahr 1975. Nachdem die Idee eines weltraumgestützten Teleskops seit fast drei Jahrzehnten diskutiert wird und auch bereits Satelliten mit kleineren Teleskopen in der Umlaufbahn operieren, legt die NASA dem US-Haushaltsausschuss eine Budgetanfrage von 400 Millionen US-Dollar vor, heute wären das über 2 Milliarden US-Dollar. Damit wollte die US-Raumfahrtbehörde den Bau eines „Large Space Telescopes“ mit einem Spiegel von 3 Metern Durchmesser finanzieren. Das Projekt wurde jedoch als „zu teuer“ abgelehnt.

Die NASA überarbeitete die Pläne und verkleinerte den Durchmesser des Hauptspiegels (und damit die Größe des Teleskops) auf 2,4 Meter. So konnte das benötigte Budget halbiert werden. Das Geld wurde 1977 bewilligt, sodass die NASA in den folgenden Monaten die einzelnen Komponenten beauftragen konnte.

1978 wurde dann der Auftrag für den Hauptspiegel des Teleskops an das US-Unternehmen PerkinElmer vergeben. Beim Bau kam ein neues, lasergestütztes Schleifverfahren zum Einsatz. PerkinElmer setzte dabei auch ein für das neue Verfahren angepasstes Messgerät, einen sogenannten „Null-Korrektor“, ein. Bedingt durch Zeit- und Kostendruck wurde der neue Korrektor vor dem Einsatz nicht getestet und validiert. So bemerkte niemand, dass durch eine fehlerhafte Konstruktion eine Linse des Messsystems um 1,3 mm versetzt saß. Da es bei PerkinElmer zu einer Reihe von Versäumnissen in der Qualitätssicherung kam, blieb der Fehler zunächst unbemerkt. Neben der fehlenden Validierung wurden später noch eine ganze Reihe weiterer Versäumnisse entdeckt.



Source link

Weiterlesen

Beliebt