Ein paar Informationen zum Airbus-Sonnen-Software-Problem des A320

So langsam sickern ein paar Informationen durch.

Allerdings schwer zu verifizieren.

Ich hatte mich ja darüber gewundert, warum der Airbus A320, den es seit 1987 gibt, urplötzlich anfällig gegen Sonnenerruptionen sein soll, und warum ein Software-Downgrade auf die letzte Softwareversion dabei helfen soll.

Ich hatte ja schon vermutet, dass die möglicherweise Sensoren verwenden, die sie vorher nicht verwendet haben, oder sie anders verwenden als zu vor, oder aber irgendwelche Sensoren oder Elektronik schon immer anfällig war, man das bisher aber mit Plausibilitätschecks abgefangen hat, die nun aus irgendwelchen Gründen nicht mehr funktionieren.

Gerüchten zufolge soll genau das der Fall sein, nämlich dass Plausibilitätsprüfungen nicht mehr funktionierten. Airbus nämlich habe für diese Softwareversion einen anderen Compiler verwendet als zuvor, und der haben diese Plausibilitätsprüfungen „wegoptimiert“.

Einige Leser verweisen dazu auf einen Kommentar im Heise-Forum, der sich wiederum auf ein Video eines (A320-)Piloten bezieht, der das bespricht:

Und der sagt, das in der anfälligen Softwareversion L104 genau der Code fehle, der die Software gegen die Auswirkungen der Sonneneinstrahlung schütze, er sich aber nicht so gut mit Computerkram auskenne. Irgendwie sei es da zu einem Bitflip gekommen, und deshalb der ELAC-Computer in einen Fehlerzustand geraten.

Das an sich sei noch nicht schlimm, weil sie ja aus Redundanz-Gründen zwei dieser Computer an Bord hätten. Das System habe automatisch auf den zweiten umgeschaltet – dafür ist der ja da. Das Umschalten allerdings sei nicht fehlerfrei verlaufen, sondern dabei sei es zu dieser fehlerhaften Absackbewegung gekommen. Man hatte ja berichtet, dass der Airbus urplötzlich abgesackt, dann aber völlig normal weitergeflogen sei. Das scheint also nicht durch den Sonnenfehler selbst verursacht worden zu sein, sondern der Sonnenfehler hat zu einem Fehlerzustand geführt, der wiederum die Umschaltung auf den Reservercomputer auslöste. Und der Reservecomputer habe zwar einwandfrei funktioniert, aber dieser Umschaltprozess eben nicht.

Also müsste man eigentlich von zwei Fehlern sprechen: Nämlich dem Ausfall eines ELAC durch die Sonneneinstrahlung, und das Absacken beim Umschalten. Wobei die Frage wäre, ob man das überhaupt vermeiden kann, wenn man umschaltet, weil der gerade aktive Computer „spinnt“.

Es ist aber, wie der im Video sehr schön erklärt, nicht einfach so, dass man da von einer Platine auf die andere umschaltet, sondern der Airbus hat drei Hydrauliksysteme, von denen je eines von je einem Triebwerk, und das dritte über eine elektrische Pumpe angetrieben wird. Und demnach sei ELAC1 für das erste, mächtigere Hydraukliksystem zuständig, während ELAC2 für die anderen beiden zuständig sei, weshalb es beim Ausfall des ersten Systems – Linkes Triebwerk, ELAC1, Haupthydrauliksystem – erforderlich werden kann, die Notfallturbine anzuwerfen, obwohl jedes Hydrauliksystem alleine das Flugzeug zumindest notfallmäßig fliegen kann.

Es ist also nicht so, dass da einfach zwei gleichwertige Systeme nebeneinander stehen, sondern schon so, dass das eine das Hauptsystem ist, und das Ersatzsystem selbst wieder redundant aus zwei Untersystemen besteht. Und da kann es beim Umschalten wohl unschön rumpeln.

Und in diesem Softwareupdate fehlte angeblich ein Stückchen Software, das diesen ELAC-Rechner gegen den Einfluss der Umwelt, wie Sonnenstürme, schützte. Und wir wissen ja, etwa vom Polarlicht, dass Sonnenstürme ionisierend wirken können, und das ist etwas, womit Computer so ihre Probleme haben.

Hardwarenahe Programmierung

In besagten Heise-Kommentar finden sich noch einige weitere Hinweise, auch auf Videos mit einem anderen Vorfall oder zu der Frage, was man in einem Airbus eigentlich macht, wenn das alles ausfällt. Aber anscheinend auch eher von einem Piloten als von einem Informatiker.

Nun bin ich zwar nicht der große Hardware-Programmierer, das kommt bei mir eher selten vor, aber mir erscheint die Vermutung, dass der Compiler nach einem Compilerwechsel diese Sicherungen gegen Einstrahlung wegoptimiert habe, durchaus plausibel.

Es ist nämlich so, dass wenn man sich bei einem System nicht sicher ist, ob es richtig funktioniert und richtige Messwerte liefert, man es einfach mehrfach hintereinander ausliest, und schaut, ob sich die Werte ähneln oder sprunghaft verändern. Compiler dagegen sind darauf ausgelegt, überflüssige Zugriffe wegzuoptimieren: Das müssen wir nicht auslesen, das haben wir gerade eben schon ausgelesen, das haben wir noch im Prozessorregister – und zack, ist ein Lesezugriff einfach weg.

Normalerweise braucht man für so etwas eine Sprache oder einen Compiler, die erlauben, das explizit zu kennzeichnen. Beispielsweise kann man einen Speicherbereich als „volatil“ markieren, damit der Compiler weiß, dass das kein gewöhnlicher Speicher ist, sondern sich die Inhalte von selbst ändern können, deshalb erneute Zugriffe nicht wegoptimiert werden können und dürfen. Oder es gibt Pragma-Anweisungen, die sagen, dass das folgende Stück Code vielleicht aus Compiler-Sicht dämlich aussieht, aber „ich will das so haben, als mache es auch genau so!“. Das ist nämlich ein altbekanntes Problem, dass Hardwareprogrammierung und Compileroptimierung nicht gut zusammengehen.

Es kann aber auch ein CPU-Problem sein:

In der Leserzuschrift ist dazu die Rede von „Single-Event-Upsets“:

Aus meiner Erfahrung mit dem Thema Single-Event-Upsets in Raumsonden und Satelliten kann ich folgende, bisher nicht direkt in der Diskussion aufgetauchte Nischen-Issues beitragen:

• Single-Event-Upsets sind ultra-häßlich, wenn sie in der CPU auftauchen. Im Speicher sind normalerweise ECC-artige Algorithmen, die Bitfehler entdecken und je nach Auslegung auch garantieren können, dass sie Single-Bit-Fehler auch korrigieren können, und damit sind Single-Event-Upsets im RAM und im Flash eher nicht das Thema. (Für moderne Standard-Mainboards gilt: SECDED-ECC, also 72 Bit breite Speicherwörter für 64 Bit auf ganz normalen Mainboard-Speicherinterfaces stellen die meisten 2-Bit-Fehler fest und korrigieren alle 1-Bit-Fehler)
• In den moderneren CPUs sind Single-Event-Upsets durch kosmische Strahlung wesentlich häufiger durch die kleinen Struktur-Breiten. In CPU-Generationen mit Strukturbreiten von über 80nm (also aus heutiger Sicht quasi Bronzezeit) sind einzelne Single-Event-Upsets nicht so kritisch, weil nahezu nicht aus kosmischer Strahlung zu triggern (da muss man schon in direkte Jupiter- oder Sonnen-Nähe, um so etwas zu triggern).
• Der Begriff Single-Event-Upset kann transiente Bit-Kipper oder bleibende Effekte bezeichnen.

  Richtig problematisch werden bleibende Effekte, die als Single-Event-Latchup bezeichnet werden, das sind Situationen, in denen ein Gate, also ein FlipFlop, dauerhaft offen bleibt, also quasi ein Mini-Kurzschluss auf dem CPU-Die (bei einigen Systemen kann man das tatsächlich aus dem Stromverbrauch raus überwachen).

  D.h. da kann es passieren, dass in einem CPU-Register ein Bit dauerhaft auf 1 bleibt, auch wenn der Code das Register mit einem Inhalt lädt, der das betreffende Bit 0 setzen will (bzw. evtl. auch umgekehrt). Zur Detektion von so etwas sind die angesprochenen Read/Compare-After-Write-Makros hilfreich, zur Erkennung von dem Effekt ist es meistens auch ausreichend, einmal in einem Rechen-Zyklus die Register auf hängende Bits zu testen. (Und im Fehlerfall dann die CPU bzw. diesen Computer hoffentlich noch korrekt als “faulty” an die Fault-Protection zu melden.)

  Workaround für solche Single-Event-Latchups ist ein Power-Cycle, der sollte das im Normalfall wieder lösen, das ist auch das in den Airbus-Fehlerbehebungsprozeduren angedachte Fixing-Verfahren.

Ja. Das ist haarig. Wenn in der CPU Bits kippen, kann man sehr wenig dagegen tun, im Grunde genommen gar nichts. Wenn aber der Compiler Zugriffe oder Vergleiche wegoptimiert, die zumindest manche dieser Fehler erkennen oder kompensieren, dann kann das natürlich bitter werden. Deshalb verwendet man in der Raumfahrt übrigens gerne uralte, steinzeitliche Prozessoren, weil die noch so richtig große, derbe Strukturen haben, und nicht gleich bei jedem Alphateilchen, das vorbeikommt, eine Krise bekommen.

Politik? Sabotage?

Die Sache bekommt aber noch einen anderen Drall. Ein anderer Leser schreibt nämlich

wirtschaftskrieg, industriespionage, airbus

moin,

auf reddit bin ich über ne merkwürdige sache gestolpert

https://www.reddit.com/r/wallstreetbetsGER/comments/1p79b50/short_airbus/

tage bevor die pressemeldung rausging, kamen unspezifische andeutungen über einen kurssturz bei airbus (der ja dann auch kam, aber später als “prophezeit”)

wenn zum zeitpunkt x genug short-positionen aufgebaut wurden, multipliziert sich der kursverfall, der normalerweise eh gekommen wäre.

haben da amerikanische geheimdienste infos durchgestochen? und hat airbus reagiert und die mitteilung verzögert, um so viele shortseller wie möglich vorher zu verunsichern?

den psychokrieg hat imho airbus gewonnen, der kurs ist bereits wieder am steigen…viele werden ihre shorts nach der zweiten verstrichenen ankündigung verkauft haben…

Vielleicht einfach ein Insider.

Vielleicht aber auch ein inszeniertes Theater? Airbus schaden, um Käufer abspenstig zu machen? Oder der Versuch einer feindlichen Übernahme?