Der betroffene ELAC (Elevator Aileron Computer) ist zweimal vorhanden und übernimmt die Steuerung von Elevators und Trimmable Horizontal Stabilizer und Ailerons.
Hinzu kommen drei SEC'S (Spoiler Elevator Computer), die steuern die Spoiler und bei Ausfall beider ELAC's die Elevators und den THS.
Aufgebaut sind die Computers jeweils in 2 Channels, Command and Monitoring, und untereinander kommunizieren die auch noch.
Es steuert jeder Computer mit seinem Hydraulikaktuator seine Steuerfläche.
Es gibt eine relativ komplizierte Reihenfolge und Abstufung welcher Computer wann in Charge ist bzw. übernimmt.

Ist das FBW des A320 aber nicht auch softwareseitig dreifach redundant oder hat man das inzwischen geändert?

Falls das noch so ist und dieser Fehler trotzdem durch ein Softwareupdate verursacht wurde sollte hier sehr genau nachgeforscht werden.

Also anders herum: Airbus verschickt leichtfertig ein AOT an alle Kunden, dass defacto 6000 Flugzeuge stilllegt, sichert sich zusätzlich mit einer Emergency Airworthiness Directive seitens der EASA ab. Und das ganze ohne vorher genau zu untersuchen? Oder was wollen Sie mit der mit Ihrer Forderung nach einer genauen Untersuchung hier implizieren? Tut mir leid, so funktioniert vielleicht Automobilbau oder der Handymarkt, nicht aber Flugzeugbau. Und das ist auch gut so.

So eine Anweisung gibt man nur raus, wenn man sich ganz sicher ist, das Problem damit zu lösen und den Auslöser gefunden hat.

Und ja es sind drei Programmiersprachen.

ELAC1 & 2 haben eine Sprache
SEC 1,2&3 haben eine andere Sprache
Und die FAC 1&2 sind in einer dritten Sprache geschrieben.

Nur sind die SEC und FAC ja nicht betroffen

Dieser Beitrag wurde am 01.12.2025 08:22 Uhr bearbeitet.

So eine Anweisung gibt man nur raus, wenn man sich ganz sicher ist, das Problem damit zu lösen und den Auslöser gefunden hat.

Eine kühne Theorie, die durch logisches Denken unschwer widerlegt werden kann.

Oder meinen Sie vielleicht, man ignoriere eine mögliche Fehlerursache, von der man zwar weitestgehend überzeugt ist, die man aber mangels ausreichender Prüfzeit bisher noch nicht sicher verifizieren konnte? Doch wohl kaum. Im Zweifel heißt es eben grounden statt nur grummeln.



Und ja es sind drei Programmiersprachen.

ELAC1 & 2 haben eine Sprache
SEC 1,2&3 haben eine andere Sprache
Und die FAC 1&2 sind in einer dritten Sprache geschrieben.

Nur sind die SEC und FAC ja nicht betroffen

Man sollte die Sprachendiskussion nicht hoch hängen. Programmier- und Anwendungskontrollsprachen sind sowieso zweierlei. Ich fürchte, da wurde etwas vermischt:

Die Programmiersprache ist, solange sie die Anforderungen an das spätere Verhalten des Programms erfüllt, völlig egal. Mit der Programmiersprache wird lediglich die abstrakte Verhaltensregel (wie z.B. "wenn... dann...") in maschinenlesbaren Code umgewandelt. Der Benutzer kommt mit der Programmiersprache nicht in Berührung.

Und nur zur Info der geneigten Leserschaft, weil dies in einem früheren Beitrag hier behauptet wurde, die Programmiersprachen C bzw. C++ geraten heutzutage nicht deswegen in den Hintergrund, weil diese Sprachen fehleranfällig oder gar fehlerhaft wären, sondern weil sich heute Programmierer lieber auf "modernere" Sprachen verlassen, die vieles von dem erledigen, was an sich bisher der Programmierer erledigen sollte.

Anwendungskontrollsprachen dagegen sind in etwa sowas wie Skriptsprachen, mit ihnen können die Geräte "von außen" gesteuert werden. Da ist es völlig unerheblich, ob diese Kontrollsprache mit dem Nachbargerät identisch sind oder nicht.

Genau, deswegen gibt im Zweifelsfall eine Handlungsanweisung raus, die zwar Arbeit verursacht, das Problem aber nicht löst, weil die jetzt aufgespielte Software (Downgrade) das gleiche Verhalten zeigt.

Dann hätte man die Maschinen OHNE Handlungsanweisung gegroundet/grounden müssen. Also eine EAD ohne vorheriges AOT (Alert Operators Telex/Transmission).

Ich will Ihnen gern auch nochmal erklären, wie so etwas abläuft:

Der Vorfall bei Frontier ist meldepflichtig. (Es wurden Menschen verletzt und das Flugzeug war zumindest teilweise (eingeschränkt) kontrollierbar.

Die für die betroffene Airline zuständige Behörde, hier FAA, MUSS den Fall an die für das Type Certificate zuständige Behörde (hier EASA) melden, dafür gilt eine Frist von 72h nach Bekanntwerden.

Gleichzeitig kann die die FAA das NTSB mit der Untersuchung beauftragen. Nach Annex13 ist dabei die EASA in diesem Fall mit einzubeziehen. Diese würde den Fall an die BEA weitergeben. Auch ist der Hersteller zu informieren, was aber von Seiten der Airline in diesem Fall wohl eh schon passiert ist.

Sollte die untersuchende Behörde(hier die FAA vertreten durch das NTSB) oder die Typecertificate-betroffene Behörde Hinweise finden, die einen unsicheren Betrieb vermuten lassen, MÜSSEN sie tätig werden. Gibt es keine noch Abhilfe, bleibt nur das Grounding mit einer EAD (Emergency Airworthiness Directive) OHNE Handlungsanweisung zur Beseitigung (siehe MD11 im Moment)

Hier ist das nicht so passiert, hier hat Airbus den Fall untersucht, offensichtlich keine unmittelbare Gefahr gesehen, denn sonst MÜSSEN sie die EASA darüber informieren und ein AOT OHNE Anweisung an die betroffenen Kunden schicke , sondern konnte (recht zügig) eine Lösung erarbeiten (Downgrade der Software). Diese wird den Airlines dann mittels AOT INKL. Handlungsanweisung mitgeteilt. Damit dieses AOT auch umgesetzt wird tritt man dann die die EASA heran und macht es mit einer AD (Airworthiness Directive) oder hier EAD verpflichtend.

Eine AD dauert zu lange, weil dort noch diverse Unterschriften eingesammelt werden müssen. zB. auch von den nationalen Behörden in Europa. Bei einer EAD entfällt das und das ganze ist sofort gültig.

Diese verflixte Sache mit dem logischen Denken....

Und noch abschlie0end zur Software Programmiersprache: Man hat sich bewusst für drei Sprachen entschieden, den alle Sprachen ihre Vorteile, Nachteile und Schwachpunkte haben. Und da man bei einer solch Komplexen Programmierung (inkl der Ergebnissabstimmung zwischen den Computern) verhindern wollte nur wenige Programmierer zur Auswahl hatte, wollte man das auf mehrere Arten von mehreren Personen unabhängig voneinander lösen lassen.

Dieser Beitrag wurde am 01.12.2025 14:42 Uhr bearbeitet.

Ist das FBW des A320 aber nicht auch softwareseitig dreifach redundant oder hat man das inzwischen geändert?

Falls das noch so ist und dieser Fehler trotzdem durch ein Softwareupdate verursacht wurde sollte hier sehr genau nachgeforscht werden.

Also anders herum: Airbus verschickt leichtfertig ein AOT an alle Kunden, dass defacto 6000 Flugzeuge stilllegt, sichert sich zusätzlich mit einer Emergency Airworthiness Directive seitens der EASA ab. Und das ganze ohne vorher genau zu untersuchen? Oder was wollen Sie mit der mit Ihrer Forderung nach einer genauen Untersuchung hier implizieren? Tut mir leid, so funktioniert vielleicht Automobilbau oder der Handymarkt, nicht aber Flugzeugbau. Und das ist auch gut so.

So eine Anweisung gibt man nur raus, wenn man sich ganz sicher ist, das Problem damit zu lösen und den Auslöser gefunden hat.

Und ja es sind drei Programmiersprachen.

ELAC1 & 2 haben eine Sprache
SEC 1,2&3 haben eine andere Sprache
Und die FAC 1&2 sind in einer dritten Sprache geschrieben.

Nur sind die SEC und FAC ja nicht betroffen

Verstehe, ich hätte erwartet dass das FBW System als Ganzes dreifach redundant ist und nicht nur als Summe der Teilsysteme.

Soviel zu den Standarts in der Verkehrsfliegerei aber Danke für die Erklärung. Mir war nicht klar dass die alte Version das gleiche Verhalten zeigt.



@GB was ist eigentlich mit deinen Standarts?

"C bzw. C++ geraten heutzutage nicht deswegen in den Hintergrund, weil diese Sprachen fehleranfällig oder gar fehlerhaft wären"

Steht da nicht wirklich oder?

Und ja es sind drei Programmiersprachen.

ELAC1 & 2 haben eine Sprache
SEC 1,2&3 haben eine andere Sprache
Und die FAC 1&2 sind in einer dritten Sprache geschrieben.

Nur sind die SEC und FAC ja nicht betroffen

Verstehe, ich hätte erwartet dass das FBW System als Ganzes dreifach redundant ist und nicht nur als Summe der Teilsysteme.

Soviel zu den Standarts in der Verkehrsfliegerei aber Danke für die Erklärung. Mir war nicht klar dass die alte Version das gleiche Verhalten zeigt.



@GB was ist eigentlich mit deinen Standarts?

Ich pflege weder eine Standarte zu führen noch habe ich Standards eingefordert :-)




"C bzw. C++ geraten heutzutage nicht deswegen in den Hintergrund, weil diese Sprachen fehleranfällig oder gar fehlerhaft wären"

Steht da nicht wirklich oder?

Das bezog sich auf den Beitrag von IRIS v. 01.12.2025 - 00:05 Uhr:
im Web wird C wegen Problemen mit der Speicheradressierung nicht mehr verwendet da sich die leicht durch Angreifer ausnutzen lassen.

Das System ist mehr als dreifachbredundant.

Die Pitchachse wird ja vom Elevator /Höhenruder kontrolliert. Die Flächen können von den beiden ELAC und zwei der drei SEC gesteuert werden (4 fache Klntrolle.

Dir Rollachse wird von den Querrudern und dem Rollspoilern gesteuert werdrm.

Wieder beide ELACs und alle drei SEC. (5 fache Absicherung)

Ths/Höhenflossen wird von 2 FAC und mechanisch über Seilzug gesteuert. 3 fache Sicherheit.

Seitenruder Gierachse: genauso Wie THS

Also das ist so redundant ausgelegt, dass bei der XLR auf generelle dreifach Sicherung zurück gegangen wird.

Und eine mehrartige Absicherung ist immer besser, als einfach alles nur dreimal zu verbauen. Denn alle drei Computer könnten auf den gleichen Fehler laufen

Ths/Höhenflossen wird von 2 FAC und
mechanisch über Seilzug gesteuert.
3 fache Sicherheit.

Ich korrigiere @menschmeier nur ungern, aber die FAC's spielen nur beim Rudder ihre Rolle.
Beim THS sind es die 2 ELAC's mit ihrem jeweiligen elektr. Trimmotor Nr.1 und Nr.2 am THS-Actuator. Als Lösung 3 und 4 kommen SEC 1 und 2 ins Spiel über einen gemeinsamen elektr. Trimmotor Nr.3
Die elektr. Trimmotoren steuern dann die 2 hydraulik Motore, welche dann letztlich den THS bewegen.
Die "mechanische" Möglichkeit für den Piloten zur direkten Auslenkung des THS erfolgt durch drehen an den Trimrädern im Cockpit. Dadurch werden aber auch nur wieder die 2 Hydraulikmotore über Seilzug angesteuert und der THS bewegt sich mit Hydraulikkraft.
Ähnlich ist die Auslenkung des Rudders ausgelegt. Pedale im Cockpit, Seilzug nach hinten, Auslenkung durch 3 Hydraulikaktuatoren. Hier spielen die 2 FAC's ihre Rolle bei Trimmung und Yaw Damping und Beschränkung dad Auslenkwinkels.
Eine direkte Auslenkung durch menschliche Muskelkraft ist nicht vorgesehen. Ein A320 ohne Hydraulik nur mit menschlicher Muskelkraft ist nicht vorgesehen/möglich. Insofern spielen die verbauten Computer eine elementare Rolle ...

Stimmt. So war das.

Ja die Zwischenkomponente Hydraulikmotor bei den Seilzügen habe der Einfachheit halber weggelassen. Denn wenn mal den Seilzug verwendet greift der Computer doch zunächst nicht ein. (Wenn das im Envekoo passiert)

Sie dürfen mich gern korrigieren. Das Alter, das Alter....

Vg aus Braunschweig

@GB bitte richtig zitieren.

Bin mir auch nicht sicher was du mit "Anwendungskontrollsprachen" meinst denn C++ kann eigentlich beides und wird auch für beides verwendet.
Eben weil es so eine hardwareorientierte Sprache ist.

Unabhängig davon welche Rolle die Software hier gespielt hat (anscheinend garkeine) stellt sich bei der Hardware in Zukunft sicher die Frage ob die heutigen Methoden zur Härtung ausreichen oder ob man z.B. auf Glasfaserleitungen, stärker abgeschirmte LRUs usw. umsteigt nachdem ja wie bereits geschrieben wurde neben den durch den Klimawandel vermutlich zunehmenden Extremwetterereignissen in den Höhen vorallem auch die sich ändernde Sonnenaktivität zu erhöhter Strahlenbelastung führen wird.
Sicher nicht alles aber vieles könnte man an der Stelle aus der Militärtechnik übernehmen.

@IRIS
@GB bitte richtig zitieren.
Das war schon richtig zitiert, copy & paste und gekennzeichnet.


Bin mir auch nicht sicher was du mit "Anwendungskontrollsprachen" meinst denn C++ kann eigentlich beides und wird auch für beides verwendet.

Auch da habe ich wörtlich zitiert:
Und ja es sind drei Programmiersprachen.

ELAC1 & 2 haben eine Sprache
SEC 1,2&3 haben eine andere Sprache
Und die FAC 1&2 sind in einer dritten Sprache geschrieben.

Ich will das gerne erlklären und den Begriff Programmiersprache differenzieren:

Ein datenverarbeitendes Gerät enthält ein Programm. Dieses besteht aus Maschinenbefehlen, wird aber meist der besseren Verständlichkeit wegen in einer abstrakten Programmiersprache wie BASIC, FORTRAN, COBOL, C, C++ u.v.a.m.geschrieben und dann mit einem Compiler in Maschinensprache übersetzt. Welche dieser Sprachen verwendet wird ist für das Funktionieren des Programms prinzipell unerheblich, die Programmiersprache muss nur das leisten, was der spätere Maschinencode braucht.

Die Aussage, das Gerät A brauche eine andere Programmiersprache als Gerät B, ist somit nichtssagend. Aus dem Maschinencode kann nur indirekt auf die verwendete Programmiersprache zurück geschlossen werden. Maschinencode braucht keine höhere Programmiersprache, er könnte durchaus auch manuell so geschrieben werden. Hat man ganz früher auch so gemacht. Allerdings nicht lange, ist doch zu mühsam.

Weil diese Zuordnung also bedeutungslos ist sehe ich noch folgende Möglichkeit, was mit unterschiedlicher Programmiersprache hätte gemeint sein können: Ein Maschinenprogramm bekommt seine Anweisungen buw. Eingaben als Daten über angeschlossene Hardware (z.B. Sensorenmesswerte) oder über speziell dafür vorgesehene Kommandos, die in Form von Befehlszeilen zur Verfügung gestellt werden. Diese Befehlszeilen enthalten auszuführende Befehle und dazugehörige Daten. Die Befehlszeile wird dann vom Programm interperetiert und damit dann entsprechende durchaus komplexe Aufgaben ausgeführt.

Sowas nennt man bsp. Makros oder Skriptsprachen, ich habe zur besseren Verdeutlichung von Anwendungskontrollsprache geschrieben. Aber auch hier ist es völlig unerheblich, ob zwei unterschiedliche Geräte denselben Befehlssatz haben, also dieselbe Makro(programmier)sprache nutzen, oder nicht.


Ansonsten noch ein Hinweis:

Unabhängig davon welche Rolle die Software hier gespielt hat (anscheinend garkeine) stellt sich bei der Hardware in Zukunft sicher die Frage ob die heutigen Methoden zur Härtung ausreichen oder ob man z.B. auf Glasfaserleitungen, stärker abgeschirmte LRUs usw. umsteigt

Glasfaser verhindert elektromagnetische Signaleintragungen in Verbindungsleitungen. Für das hier diskutierte Problem wurde kosmische Strahlung als Ursache in Betracht gezogen. Kosmische Strahlung kann einzelne Bits einer Speichereinheit ändern, die vor oder auch nach dem Transportweg liegt, also auch genau die Speicherzelle, die gar nicht mehr transportiert werden muss, sondern direkt vor der CPU sitzt und dort das Bitmuster für die Verarbeitung zur Verfügung stellt. Speicher und Prozessor sitzen i.d.R. so nahe zusammen, dass eine Glasfaserverbndung dazwischen keine Vorteile, wohl aber Nachteile hätte.

Um kosmische Strahlung abzuwehren muss man lediglich den Programm- und Datenspeicher besser abschirmen. Das wird in Zukunft auch sicher stärker so geschehen.

Natürlich ist es bei identischem Assembler Code egal mit welcher Hochsprache dieser erstellt wurde aber es ist nunmal so dass unterschiedliche Hochsprachen bzw. Compiler aus einem identischen Anwendungsfall oder sogar aus identischem Code unterschiedlichen Assembler Code erstellen weshalb es ja auch mehr als nur eine einzige Hochsprache und einen einzigen Compiler gibt.

Allerdings würde quasi jeder Compiler "richtig Zitieren" mit "nur ganze Sätze zitieren" gleichsetzen und kosmische Strahlung hat spätestens bei der Wechselwirkung mit dem A320 eine elektromagnetische Komponente denn sonst könnte sie wohl kaum Bit Flips verursachen.
Ich hab die Glasfaserleitungen aber auch deswegen als Beispiel genannt weil die bereits in Luftfahrzeugen verwendet werden.

Noch ein Hinweis:

ich würde auf ChatGPT Pro upgraden.

Liebe(r) IRIS,

wieso sollte ausgerechnet ich Halluzinationen von ChatGPT beziehen, es reicht doch völlig, wenn andere sich damit blamieren :-) :-) :-)

and now, over & end

golf bravo

Hab ich mir schon gedacht.