EASA Emergency Airworthiness Directive für alle A320-Varianten: Möglichkeit der ungewollten Bewegung des Höhenruders durch Fehler im ELAC, ausgelöst durch kosmische Strahlung

[conaly]

Die EASA hat nach Info von Airbus soeben eine Emergency Airworthiness Directive für die komplette A320-Reihe rausgegeben:

https://ad.easa.europa.eu/ad/2025-0268-E

 

Diese gilt ab morgen und betrifft ALLE A320-Varianten, unabhängig der Seriennummer. Hintergrund:

 

Zitat

An Airbus A320 aeroplane recently experienced an uncommanded and limited pitch down event. The autopilot remained engaged throughout the event, with a brief and limited loss of altitude, and the rest of the flight was uneventful.
Preliminary technical assessment done by Airbus identified a malfunction of the affected ELAC as possible contributing factor.

This condition, if not corrected, could lead in the worst-case scenario to an uncommanded elevator movement that may result in exceeding the aircraft’s structural capability.

To address this potential unsafe condition, Airbus issued the AOT, providing instructions to install a serviceable ELAC.

For the reason described above, this AD requires installation of a serviceable ELAC and prohibits installation of an affected ELAC.

 

Der ELAC ist der Elevator Aileron Computer, welcher wohl Anfällig für kosmische Strahlung der Sonne ist, muss also vor dem nächsten Flug bei allen betroffenen Maschinen ausgetauscht werden. Airbus selbst hat das Problem in einer Pressemeldung bestätigt: https://www.airbus.com/en/newsroom/press-releases/2025-11-airbus-update-on-a320-family-precautionary-fleet-action

 

Auslöser der Geschichte war wohl dieser Vorfall eines Jetblue A320 am 30. Oktober: 

https://avherald.com/h?article=52f1ffc3&opt=0

 

Bin mal gespannt, was das für Auswirkungen haben wird. Es sind momentan etwa 11.000 A320-Maschinen im Dienst. Selbst wenn nur ein Viertel betroffen wäre, wäre das wohl das größte technisch bedingte Grounding aller Zeiten. Die EAD tritt ab morgen, 23:59 UTC (damit also ab Sonntag) in Kraft und gilt für alle Maschinen mit betroffenem ELAC. Ohne Austausch dürften betroffene Maschinen maximal zu drei Ferry-Legs abheben, ein kommerzieller Betrieb ist nicht mehr erlaubt.

Bearbeitet 28. November 2025 von conaly

[Urs Wildermuth]

Nach einem Vorfall mit einem A320 von Jetblue nahe Tampa vom 30. Oktober hat die EASA eine Emergency AD erlassen, die am 29. 11. Um 2359 in Kraft tritt. 

 

Bei allen betroffenen Flugzeugen müssen danach vor weiteren Flügen einer der Computer des FBW Systems entweder ausgetauscht oder eine Softwaremodifikation durchgeführt werden.

 

Dies kann potentiell massive Auswirkungen auf die betroffenen Flotten haben.

 

https://ad.easa.europa.eu/ad/2025-0268-E

 

Airbus Press Release

 

https://www.airbus.com/en/newsroom/press-releases/2025-11-airbus-update-on-a320-family-precautionary-fleet-action

 

Der Vorfall:

 

https://avherald.com/h?article=52f1ffc3

 

 

[landinglight]

Puh, da wird was los sein.

 

Aber gut. MCAS hat die Nase auch runtergedrückt, wenn auch nicht ganz vergleichbar. Nicht ganz vergleichbar war dann auch der Umgang mit dem Thema seitens Hersteller. Dann lieber so wie hier - vorbildlich!

[conaly]

Aerotelegraph berichtet, dass wohl mehr 6500 Maschinen betroffen sind, wobei ein Teil davon mit einem Software-Update gefixt werden kann. Andere brauchen wohl zusätzlich einen Hardware-Tausch des ELACs.

 

https://www.aerotelegraph.com/sicherheit/airbus-warnt-vor-gefahr-durch-kosmische-sonnenstrahlung-mehr-als-6000-jets-der-a320/vsvy4r4

[FalconJockey]

Themen zusammengeführt.

 

Da machen sich mal wieder ein paar Leute in die Hose! Das hat mit den ELACs jetzt 40 Jahre lang geklappt und jetzt muss es gaaaaaaaaaaanz dringend und ohne Aufschub repariert werden. Unglaublich.

[conaly]

Was ich inzwischen aus diversen Quellen erfahren habe, ist dass es wohl kein Software-Upgrade, sondern ein Downgrade braucht. Es soll wohl eine vorherige Version eingespielt werden. 

 

Das würde auch die Dringlichkeit erklären, wenn der Fehler erst mit der neuen Version überhaupt auftreten kann.

[Urs Wildermuth]

vor 5 Stunden schrieb FalconJockey:

Da machen sich mal wieder ein paar Leute in die Hose! Das hat mit den ELACs jetzt 40 Jahre lang geklappt und jetzt muss es gaaaaaaaaaaanz dringend und ohne Aufschub repariert werden. Unglaublich.

 

Erstens ist der Vorfall, der die Aktion ausgelöst hat alles andere als harmlos. 10 Insassen wurden verletzt und man kann von Glück sagen, dass das Ganze im Reiseflug passsiert ist und nicht in Bodennähe, sonst ist die Frage da, ob man diesen Upset hätte abfangen können oder nicht. Dazu kommt das Airbus sogar von der Möglichkeit spricht, dass die Struktur überlastet werden könnte. 

 

Airbus ist offensichtlich ausreichend alarmiert und schreibt in ihrem AOT: 

 

Zitat

This identified vulnerability could lead in the worst case scenario to an uncommanded elevator movement that may result in exceeding the aircraft structural capability.

 

Da verstehe ich, dass die kein Risiko eingehen wollen und die Sache behoben werden muss. Sofort. Man hat den Airlines knapp einen Tag Zeit gegeben, die auch intensiv genutzt wird (Das EAD kam gestern Abend raus, muss bis heute 2359UTC erfüllt werden, was zusammen mit der Tatsache dass wohl diese Nacht wie auch die nächste und heute Tagsüber soviele Flieger wie möglich bereits den Downgrade erhalten werden. Dennoch erwarte ich morgen vermutlich noch heftige Auswirkungen bei den Flugzeugen, die noch nicht umgerüstet werden konnten. Offenbar ist es auch so, dass sehr viele Flieger mit einem einfachen Software Downgrade (man spricht von 2-3 Stunden pro Flieger) compliant werden, bei anderen müssen die ELAC Computer ausgetauscht werden, weil sie nicht im Flugzeug aufdatiert werden können. 

 

Man kann sich allenfalls fragen, in wie weit die Dringlichkeit mit der Voraussage von Solar Flares etwas abgemildert werden kann, denn die Solar Flares waren ja vorausgesagt worden. Denke aber dass sich Airbus und EASA das sehr wohl überlegt haben. 

 

Immerhin, ich muss sagen, die Aktion von Airbus zeigt ein deutlich höheres Verantwortungsbewusstsein wie bei anderen Herstellern, die erst nach dem 2. Crash und auf Druck der Behörden hin ihre Flieger groundeten... Hier kann man hoffentlich in den meisten Fällen ein Grounding sehr kurz halten bzw sogar vermeiden. 

[Maxrpm]

viel hängt jetzt davon ab in wievielen A320 die ELAC getauscht werden müssen. Das geht zwar theoretisch auch sehr schnell. Praktisch gibt es aber einfach keine 1000 Reserve ELAC weltweit. Wen die erst produziert werden müssen, kann das die Flugzeuge über Wochen am Boden halten.

 

wolfgang 

[stefanw]

2 hours ago, Urs Wildermuth said:

Man kann sich allenfalls fragen, in wie weit die Dringlichkeit mit der Voraussage von Solar Flares etwas abgemildert werden kann, denn die Solar Flares waren ja vorausgesagt worden. Denke aber dass sich Airbus und EASA das sehr wohl überlegt haben. 

 

Ich frage mich allgemein, inwiefern das Problem mit der im Moment (2025) erhöhten Sonnenaktivität zusammenhängt oder dringlicher wurde. Allenfalls geht Airbus hier von bereits erfolgten Schäden aus, da helfen dann Vorhersagen für künftige Flares auch nur bedingt. Just guessing...

[conaly]

vor 2 Stunden schrieb Maxrpm:

viel hängt jetzt davon ab in wievielen A320 die ELAC getauscht werden müssen. Das geht zwar theoretisch auch sehr schnell. Praktisch gibt es aber einfach keine 1000 Reserve ELAC weltweit. Wen die erst produziert werden müssen, kann das die Flugzeuge über Wochen am Boden halten.

 

Kommt wohl auf den ELAC an. Was ich inzwischen rausgefunden habe, ist dass wohl der überwiegende Teil der ELACs software loadable sind, sprich einfach neue (alte) Version drauf (2-5 Stunden Standzeit) und damit hat sichs. Die ELACs, die vor 2008 produziert wurden können aber wohl nicht einfach per Software-Load verändert werden sondern müssen im Shop neu bespielt werden. Das betrifft aber wohl nur etwa ein Fünftel der betroffenen Maschinen

[Frank Holly Lake]

So mach mal bekomme ich die Kommentare hier einfach nicht zusammen. 

Was ich darüber gelesen  haben ist folgendes: (Nur Internet keine verlässliche Quelle und ein LH Mitarbeiter) 
Für mich geht es immer um Sicherheit. 
Und wenn da so etwas raus gegeben wird, hat man was erhebliches gefunden.

Faktenlage 
Nach einem Update wurde festgestellt, das es zu einem "Glitch" kommt, der sehr gefährlich werden kann.
ELAC (Elevator Aileron Computer) ist einer der wichtigsten FBW Computer in dem Flieger.

Es konnte in einer Simulation nachgewiesen werden, das es wegen plötzlicher unkontrollierter Ruderausschläge zu einer mechanische Überlastung an der Zelle kommen kann , ein Luftzerleger droht. 

 

Ein Glitch ist etwas was immer wieder passiert und nicht weiter schlimm ist, weil normaler weise die Software so geschrieben ist, das eine ein eimaliger (oder mehrfacher)  falscher Datenblock aussortiert wird.

Es wurde einUpdate programmiert, um  die um die Schnelligkeit zu verbessern, welcher aber diese Erkennung eingeschränkt hat, oder die Ausfilterung nicht mehr funktioniert.
  
Nun rollt man wieder zurück um die alte Glitch Erkennung wieder zu haben. 
Bei der alten SW Version trat das Problem so  nicht auf. 

 

Da sehe ich eher Airbus in der Schuld hier "Mist" programmiert zu haben und etwas, was über Jahre gut war, gegen etwas nicht ausreichend geprüftes und somit unsicheres ersetzt zu haben. 

just my cents Grüße Frank

Bearbeitet 29. November 2025 von Frank Holly Lake

[Frank Holly Lake]

@stefanw

Die höchte Sonnenaktivität gibt es im Januar, weil die Erde da der Sonne am nächsten ist .

147 M Km zu  152, M KM in July,.Ist  nicht groß der Unterschied

Aber könnte eine Rollle gespielt haben bei dem Zeitpunkt der AD 

Grüße Frank  

 

 

Bearbeitet 29. November 2025 von Frank Holly Lake

[ArminZ]

23 minutes ago, Frank Holly Lake said:

(...)
Die höchte Sonnenaktivität gibt es im Januar, weil die Erde da der Sonne am nächsten ist .

147 M Km zu  152, M KM in July,.Ist  nicht groß der Unterschied

Meines Wissens spielt der Abstand der Erde zur Sonne keine Rolle (und Sonnenaktivität ist schon gar nicht eine Funktion des Abstandes zur Erde). Und es gibt keinen bestimmten Monat, in dem die Sonnenaktivität am höchsten wäre. Stichwort Sonnenzyklus. 

Bearbeitet 29. November 2025 von ArminZ

[Frank Holly Lake]

Ja richtig. Thema Sonnesturm ist im Augenblick sehr stark. 

 

Am 28. November 2025 veröffentlichte die EASA ihre Dringlichkeitsanweisung 2025-0268-E. 
Der Text dieser Anweisung ist im Wesentlichen identisch und unterscheidet zwischen Flugzeugen der 

Gruppe 1 mit ELAC B L 104 und Flugzeugen 
Gruppe 2 ohne ELAC B L 104. Die Anweisung schreibt Folgendes vor:

Austausch:

(1) Für Flugzeuge der Gruppe 1: Vor dem nächsten Flug nach Inkrafttreten dieser Anweisung muss jeder betroffene ELAC gemäß den Anweisungen des AOT durch einen funktionsfähigen ELAC ersetzt oder modifiziert werden.

Ein Überführungsflug (bis zu 3 Flugzyklen, ohne ETOPS und ohne Passagiere) ist zulässig, um das Flugzeug an einen Ort zu bringen, an dem der Austausch oder die Modifizierung durchgeführt werden kann.

Einbau des/der Teile(s):

(2) Für Flugzeuge der Gruppe 1: Nach der Modifizierung des Flugzeugs gemäß Absatz (1) dieser Anweisung darf kein betroffener ELAC in dieses Flugzeug eingebaut werden.

(3) Für Flugzeuge der Gruppe 2: Ab dem Datum des Inkrafttretens dieser Lufttüchtigkeitsanweisung dürfen keine Flugzeuge in Flugzeuge der Gruppe 1 umgebaut werden.

 

So weit ich gelesen habe, müssen 1000 Flugzeuge mit neuen ELAC ausgestattet werden, bei 5000 soll ein SW Update  möglich, sein um das Problem zu lösen. 
Viele Überstuden im Hanger...

Grüße Frank

Bearbeitet 29. November 2025 von Frank Holly Lake

[ArminZ]

Meine Wette: der update (oder downgrade) wird bei den allermeisten europäischen Betreibern ziemlich problemlos durchgezogen. Zumindest von einer Airline ist bereits bekannt, dass sie das bei ihren 12 betroffenen Maschinen letzte Nacht gemacht hat.

Bearbeitet 29. November 2025 von ArminZ

[Lubeja]

vor 28 Minuten schrieb ArminZ:

Meines Wissens spielt der Abstand der Erde zur Sonne keine Rolle (und Sonnenaktivität ist schon gar nicht eine Funktion des Abstandes zur Erde). Und es gibt keinen bestimmten Monat, in dem die Sonnenaktivität am höchsten wäre. Stichwort Sonnenzyklus. 

Korrekt. Wenn man drauf rumreiten will, dann ist es schon so, dass die Strahlungsintensität mit dem Quadrat der Distanz abnimmt, je weiter man von der Sonne, in ihrer Eigenschaft als quasi punktförmiger Strahler, entfernt ist. Aber dieser Effekt ist allein in den "normalen" Schwankungen kaum merkbar. Die Sonnenzyklen haben allerdings auch keinen so grossen Einfluss auf die Intensität koronaler Masseauswürfe, sondern vielmehr auf deren Zahl. Sprich, es können auch in "Schwachlastzeiten" spektakuläre CME's auftreten. Statistisch gesehen spielen für die Jahresdosisleistung die Anzahl CME's die überwiegende Rolle, nicht deren Stärke. Aber genug des solaren off-topic und Klugscheisserei

[Heiri_M]

Ich verstehe nicht ganz, wieso ein SW-Update das Problem mit der kosmischen Strahlung beheben soll. "If cosmic_radiaton_detected is ON: do .....".

Weiss da jemand näheres?

[FalconJockey]

Dass dies eine Softwaregeschichte ist, kann man sich nicht ausdenken. Die Software hat ja 40 Jahre lang auch wunderbar funktioniert und dann wird mal wieder ein Update eingespielt, welches dann auf einmal zu solchen Ausschlägen führt. Wurde das von Airbus bzw. vom Zulieferer nicht ausreichend getestet? Es ist schon lange bekannt, dass hochenergetische Teilchen ein paar Bits und Bytes in unseren Avionics aus dem Takt bringen können. Das ist aber kein Problem, weil dann das jeweilige Modul im schlimmsten Fall von selbst neu booted. Auf der Falcon EASy hatten wir auch immer wieder mal den Fall, dass ein Bildschirm im Reiseflug für ein paar Sekunden schwarz wurde und dann nach maximal 10 bis 20 Sekunden wieder da war als ob nichts gewesen wäre.

 

Interessanterweise sind hochenergetische Teilchen bzw. die von ihnen ausgelösten Teilchen in Zeiten niedriger Sonnenaktivität höher, als derzeit: Der Sonnenwind wischt die nämlich einfach weg und derzeit misst man in Höhen unseres Reiseflugs bis zu 30% weniger dieser Teilchen als in Zeiten niedriger Sonnenaktivität. Der Zyklus der Sonne beträgt übrigens 11 Jahre, von Maximum zu Minimum - derzeit erleben wir ein Maximum.

[ArminZ]

1 hour ago, Heiri_M said:

Ich verstehe nicht ganz, wieso ein SW-Update das Problem mit der kosmischen Strahlung beheben soll. "If cosmic_radiaton_detected is ON: do .....".

Weiss da jemand näheres?

Mein best-guess (alles reine Vermutung). Vielleicht ein Fehler im Algorithmus des Filters, der Spannungs/Strom-Peaks dämpft, die durch solche Strahlung auftreten können.
Und/oder unvollständige Plausibilitätschecks (mit Zuhilfenahme von Input/Messwerten).

[Suricato]

Die Geschichte erinnert sehr an ...

https://en.wikipedia.org/wiki/Qantas_Flight_72

 

[mrueedi]

vor 10 Stunden schrieb Heiri_M:

Ich verstehe nicht ganz, wieso ein SW-Update das Problem mit der kosmischen Strahlung beheben soll. "If cosmic_radiaton_detected is ON: do .....".

Weiss da jemand näheres?

Standard ist, dass man solche Fehler abfängt, indem der Output nochmals validiert wird. Ein äusserer Kontrollloop um die eigentliche Berechnung quasi. Ein solcher Check würde z.B. die berechnete Höhenruder-Zielstellung auf Plausibilität prüfen und verwerfen wenn nötig. Wenn ohne nennenswerte Bewegung bei den Inputsignalen auf einmal ein Vollausschlag berechnet wurde, kann die Software mit guten Gewissen einfach die alte Stellung beibehalten.

Und nun könnte es sein, dass dieser ominöse SW Update an diesem äusseren Validierungsloop etwas verändert hat (entfernt, modifiziert, abgeschwächt), was zur Folge hat, dass solche Glitches nun durchschlüpfen könnten. Deshalb die Massnahme.

[mrbump]

Nach durchlesen dieses (und anderer) Threads ein paar Anmerkungen aus der Safety Engineering Ecke:

 

Bei Fehlereinstreuung durch ionisierende Strahlung spricht man von Single Event Upsets (SEU), nicht von Glitches. Ein Glitch ist eigentlich ein systematischer Fehler, der sich quasi-zufällig manifestiert (edge cases, race conditions etc.), also ein Bug, den man fixen kann/muss. SEUs hingegen sind wirklich zufällig und können jederzeit an jedem Ort auftreten, wo Signale übertragen oder gespeichert werden. Also z.B. RAM, Register, Cache. Das kann auch ein Zwischenergebnis in einem Algorithmus betreffen. Bei Hochsprachen hat man je nachdem nur beschränkt Kontrolle, ob eine Variable in den Registern bleibt oder ins RAM heruntergeschrieben wird. Die Aufgabe bei SEUs ist also, das System robust dagegen zu machen - keine triviale Aufgabe, wie so vieles im Safety-Engineering.

 

Bei einer Höhenrudersteuerung addieren sich die Sicherheitsanforderungen, es ist sozusagen die Königsdisziplin:
- Maximaler geforderter "safety integrity level" durch Risikobewertung.
- Es gibt keinen sicheren Zustand ("fail safe")
- Das heisst, die Steuerung muss hochverfügbar sein. Ein "Neustart von 10 Sekunden" wie bei Cockpitinstrumenten vielleicht ok, ist hier garantiert nicht akzeptabel.
- Die Verfügbarkeit selbst ist hier sicherheitsrelevant - im Gegensatz z.B. zu industriellen Steuerungen, wo Verfügbarkeit vor allem eine kommerzielle Fragestellung ist.

 

Mit einfacher Zweikanaligkeit, wie es das vorhandensein von zwei ELACs suggeriert, ist es bei weitem nicht getan. Denn welchem der beiden Kanäle ist zu vertrauen, wenn eine Diskrepanz festgestellt wird?
Typischerweise werden mehrere Ebenen von Redundanz designt, es ist also davon auszugehen, dass jeder ELAC auch intern wieder diverse Redundanzen aufweist. 
Für Prozessorkerne ist z.B. ein sog. lockstep Modus state of the art, wo zwei identische Kerne taktsynchron die gleichen Operationen ausführen und das Ergebnis verglichen wird, bei Diskrepanz nimmt sich dieser Prozessor selber aus dem Rennen (beide Kerne). Diese Massnahme deckt Prozessorinterne Fehler inkl. SEUs sehr gut und verhältnismässig einfach ab.
Für RAM wird häufig ECC angeführt, dies wird jedoch für höhere safety levels als nicht zureichend betrachtet. Typische Abhilfe ist z.B. ein sicherer Datenstore, wo jede sicherheitsrelevante Variable doppelt/komplementär abgelegt wird.

 

Wie können sich nun solche Fehler/Lücken einschleichen? Nun, Safety Engineering ist immer ein Abwägen zwischen Aufwand und Restrisiko. 100% Sicherheit gibt es nicht. Je näher man sich an das Optimum herantastet, desto mehr explodieren die Kosten. Es ist davon auszugehen, dass die Ingenieure bei Airbus kompetent und willig (wichtig!) sind, eine saubere Arbeit abzuliefern. Die Rahmenbedingungen werden aber vom Management gegeben, und denen sind die Kosten meist wichtiger. Mit dem Risiko, dass es im Nachhinein teurer (oder tödlich) wird.

 

Allgemein ist aber noch anzufügen, dass solche komplexen Fehler auch einfach durchschlüpfen können (Restrisiko), es ist nicht vergleichbar mit MCAS, wo offensichtliche Fehler in der Auslegung durch mehrere Instanzen vorsätzlich abgewunken wurden.

 

Gruss

Andi

[Tigerstift1]

Vielen Dank Andi für deine Ausführungen, sehr interessant. 

 

Ich möchte hier auch meine Bewertung hinzufügen, das meiste wurde ja schon gesagt.

Single Event Upset (SEU) / Teilcheninduzierte Bit-Flips sind eine bekannte Ursache für sporadische Korruption in losen Speicher- oder Registerinhalten (RAM, Cache, Flip-Flops). Dass Hochenergie-Teilchen (Solar Proton Events / SEPs) in Extremfällen Steuerungsdaten beeinflussen können, ist technisch plausibel. Airbus nennt ja genau diese Ursache.

Zwei Hauptwege sind denkbar

a) Ein Software-Update veränderte Verhalten/Robustheit gegen seltene, aber real existierende SEU-Events (z. B. Entfernen/Abschwächen eines zusätzlichen Plausibilitätschecks, Änderung der Filterdynamik), oder

b) Die Hardware/Firmware zeigt ein bisher seltenes Fail-Mode, der erst bei einer ausreichend starken solaren Ereignisrate sichtbar wurde.

Für hochkritische Regelkreise wie Elevator werden übliche Maßnahmen angewendet - redundante ELAC-Kanäle, lockstep-CPU(s), ECC/RAM-scrubbing, Plausibilitäts-/sanity-checks, watchdogs, TMR oder cross-checks mit anderen Sensoren/Computern. Ein einzelner Bitflip darf nicht zu einem uncommanded full-scale actuator-move führen; wenn das dennoch passieren konnte, impliziert das eine Lücke in Out-of-Bounds-Checking.

 

So sehe ich das.

• „Fehler im Algorithmus des Filters oder abgeschwächter Validierungsloop“  sehe ich als sehr plausibel an. Wenn ein Filter/limiter entfernt/abgeschwächt oder falsch parametrisiert wurde, kann ein SEU ein Zwischenwert produzieren, der dann ungeprüft weitergereicht wird. Plausibilitätskopplungen (z. B. vergleiche berechnete Stellgröße mit physikalischem Mach/α/aktueller Trimmstellung) sollten solche Ausreißer blockieren - fehlt das, passiert genau so etwas.

• „Software hat 40 Jahre funktioniert, dann Update …“  auch plausibel: komplexe SW-Änderungen haben oft Regressionen, vor allem wenn sie an Performance/Filter/Timing schrauben; SEU-spezifische Tests sind teuer/kompliziert (benötigen particle-testing, fault-injection, radiation testing) und werden manchmal nur in begrenztem Umfang durchgeführt. Das erklärt, warum eine seltene Kombination erst jetzt sichtbar wurde.

• „Nicht vergleichbar mit MCAS“  MCAS war eine Design-Konzeption/requirements-Fehler + human factors. Hier scheint es um ein sporadisches Korruptions-/robustheitsproblem zu gehen; das erfordert andere Maßnahmen (Härtung, Plausibilitätslogik, redundancy voting), nicht primär ein human factors/trim-logic redesign. Trotzdem ist das Ergebnis – uncommanded elevator movement – in der Konsequenz ähnlich gefährlich, daher die strenge Reaktion.

Airbus (zuständig für die SW) / Thales (Zuständig für die HW) werden jetzt wohl an folgenden Schritten Arbeiten:

• Kurz-/Mittel: zusätzliche Plausibilitätschecks (outer control loop) z. B. reject computed actuator command wenn Differenz zur erwarteten/gedämpften Position > X° ohne korrespondierenden Input-Änderung; implementieren eines rate-limiting + plausibility voting zwischen Kanälen.

• Hardware-level: RAM ECC + scrubbing, CPU lockstep und TMR für kritische kernels; Audit der failover-/degraded-modes (wie reagiert die SW, wenn ein lockstep-mismatch auftritt?).

• Test/Validation: Fault-injection (bit-flip injection) Tests in SW-simulatoren, plus particle-beam/radiation-testing der betroffenen ELAC-HW-Revisionen; review der DO-178C/ED-12C design Vorschriften.

Ergänzend müssen wir auch die ELAC Architektur sehen, welche einen HW Stand von mitte der 90er Jahre hat:

Der Airbus ELAC gehört zu den komplexesten Flight Control Rechnern im A320-System. Diese bestehen aus folgenden Bausteinen:

• 10 interne Leiterplatten (Boards)
  verteilt auf Rechenlogik, Interface-Module, Signalkonditionierung, Power Supply, Monitoring

• Dual-Channel Architektur (Channel A & Channel B)
  ein Channel aktiv, der andere im Monitoring/Standby; gegenseitiger Cross-Monitoring-Vergleich

• Microprocessor-Architektur: Thomson/Motorola 68000 Serie
  robuste, aber klassische CISC-Prozessoren
  sehr SEU-anfällig in ungeschützten Registern, Caches, oder lokalen RAM-Bereichen
  deshalb auf Systemebene durch externe Safety-Mechanismen (Plausibilitätschecks, Watchdogs, Härtung) ergänzt

Die 68k CPUs sind trotz ihrer Zuverlässigkeit nicht hardwareseitig SEU-resistent (kein integriertes ECC, kein Register-Scrubbing, kein interner Lockstep).
Deshalb hängt die gesamte SEU-Robustheit stark von der Softwarestruktur und den Plausibilitäts-/Voting-Ebenen ab.

Wenn ein Software-Update an genau diesen äußeren Validierungsloops etwas ändert, kann ein einzelner Bitflip (SEU) plötzlich sicherheitskritische Konsequenzen haben, obwohl die gleiche Hardwarearchitektur 40 Jahre stabil war.