09.05.2015 | Airbus A400M | Sevilla | Absturz

[iwl]

 

 

Steuerungssoftware von Flugzeugtriebwerken stoppen in diesem Fall die Treibstoffzufuhr mit den entsprechend schlimmen Konsequenzen für die Besatzung.

 

Es kann irgendwie nicht derart schwierig sein so eine Turbine anzusteuern.

Wenn die einmal läuft sollte es doch ein paar Setups geben die leidlich funktionieren. Und optimieren muss man ja wohl nicht an allen gleichzeitig.

Software kann doch keine Ausrede sein jahrelang bekannte Prinzipien von Redundanz und Heterogenität zu ignorieren.

[Chipart]

Software kann doch keine Ausrede sein jahrelang bekannte Prinzipien von Redundanz und Heterogenität zu ignorieren.

 

Das hat nix mit Software oder Hardware zu tun, sondern mit der Komplexität von Systemen:

 

In einfachen Systemen sind Redundanz und Heterogenität bewährte Mechanismen zur Erhöhung der Ausfallsicherheit. Mit zunehmender Komplexität des Gesamtsystems werden Redundanz und Heterogenität aber immer mehr zum Problem, weil sie die Komplexität und damit schwierige Systemeffekte weiter erhöhen.

 

Dieser Absturz ist vermutlich ein sehr tragisches Beispiel dafür: Der Flieger ist offenbar nicht abgestürzt, weil ein einzelnes Bauteil versagt hat und es zu diesem keine Redundanz gab. Er ist wahrscheinlich abgestürzt, weil sich im komplexen Netz verschiedener Teil-Systeme ein Gesamtsystemzustand eingestellt hat, den keiner vorhergesagt hat. 

 

Florian

[sheckley666]

Genau, wahrscheinlich wurden Boxen und dazugehörige Software verwechselt. Und es ist nicht ganz klar, wer welche zu welchem Zeitpunkt verwendet hat. Dann braucht es einen einmaligen Check um herauszufinden, welche drauf war und schon darf man wieder fliegen.

 

Es wäre z.B. auch möglich, dass man neue ECUs/FADECs bekommen hat, aber die alte Software draufgeladen hat, oder umgekehrt. So was kann schnell mal passieren. Darauf würde auch hindeuten, dass der 4. Motor evtl korrekt bestückt wurde und deshalb nicht ausfiel.

 

Naja, ich bin halt geprägt von Aussagen wie z.B.  dieser hier, wo der geschätzte Kollege Ralf schrieb:

 

 

Und genau deshalb ist in der Luftfahrt der gesamte Prorammierprozess kontrolliert, nicht nur das Endprodukt. Ich habe die betreffenden Vorschriften hier bereits verlinkt. Du kannst nicht einfach einen x-Beliebigen Compiler mit optionalen Bibliotheken benutzen. Du brauchst eine streng überwachte Programmierumgebung.

 

Diese tolle Prozesssicherheit hilft natürlich viel, wenn am Ende dann (überspitzt) der Werker in seiner Hosentasche nach dem USB-Stick kramt, und hiervon eine Datei A400M_FADEC_draft.exe in das vor ihm stehende Gerät kopieren kann, ohne, dass es bemerkt wird.

 

 

So ein Flugzeug hat (wie ein modernes Auto auch) duzende, wenn nicht hunderte Komponenten, in denen eine wie auch immer geartete Art von "Software" aufgespielt ist. Viele dieser Geräte haben dabei keine besonders komfortable Schnittstelle zum Auslesen des Softwarestands - weil man es normal einfach nicht braucht. 

 

Das sollte aber gebraucht werden. Ich habe bisher erwartet, dass in der so sicherheitsbewussten Luftfahrt jeder Arbeitsschritt nach Vollendung darauf überprüft wird, ob er korrekt durchgeführt worden ist. Und dazu muss nach dem Schritt Software aufspielen ja so etwas wie eine Versionsnummer ausgelesen werden, oder besser ein aus der aufgespielten Software errechneter Hashwert.

[Danix]

Also ich nehme an das prüfen der Versionennummer macht man über den zentralen Maintenance Computer vom Cockpit aus oder von der Electronic Bay. Natürlich ist in der sicherheitsbewussten Luftfahrt jeder Arbeitsschritt geprüft, deshalb kann es eben so Fehlern kommen, wenn man es nicht macht. Und dass in Sevilla gewisse Sicherheitsstandard gefehlt haben, das wurde ja inzwischen bereits offiziell kommuniziert.

[Hunter58]

Da kann auf dem Gebäude noch lange Airbus draufstehen, das Schild steht auf vielen Gebäuden. In Sevilla ist drinnen halt immer noch CASA, wie in Toulouse halt immer noch Sud in der Werkhalle und Aerospatiale im Engineering drinnen ist.

 

Das Problem von zusammengewürfelten Grossfirmen ist immer dass die Normen nie gleich sind, gewachsene Strukturen leben weiter. Auch wenn dies nicht die eigentliche Ursache in diesem Fall ist, es bilden zumindest den Nährboden.

[iwl]

Das hat nix mit Software oder Hardware zu tun, sondern mit der Komplexität von Systemen:

 

Ich bezweifle nach wie vor, daß die Turbinensteuerung derart komplex sein muß.

 

Aber von Turbine gar nicht mehr zu reden, sondern von

 

schwierigen Systemeffekten

im komplexen Netz verschiedener Teil-Systeme ein Gesamtsystemzustand eingestellt

 

das entspricht ungefähr dem Code den ich öfters sehe und mich frage wie man auf

sowas kompliziertes für die zu lösende Problemstellung kommen konnte.

[sirdir]

Das sollte aber gebraucht werden. Ich habe bisher erwartet, dass in der so sicherheitsbewussten Luftfahrt jeder Arbeitsschritt nach Vollendung darauf überprüft wird, ob er korrekt durchgeführt worden ist. Und dazu muss nach dem Schritt Software aufspielen ja so etwas wie eine Versionsnummer ausgelesen werden, oder besser ein aus der aufgespielten Software errechneter Hashwert.

Naja, wenn das so heikel ist muss es halt ein System geben, das alle Softwarestände prüft und anmeckert, wenn etwas nicht stimmt. Und wenn ein Steuergerät einer Turbine auf den Leib geschneidert wird, muss es halt auch (per Seriennummer) damit verheiratet werden. Machen viele Autobauer ja auch so.

Meckern aber natürlich immer nur am Boden, in der Luft muss immer ein Notprogramm laufen, selbst wenn nichts mehr stimmt.

[iwl]

Bei dem Projektstatus und Budget sollte und könnte das eine Person sein oder eher mehrere

[Volume]

 

Ein CPC und eine BSCU sind m.W. nur bei A300/310/320/330/340 verbaut

deshald sage ich ja auch "in ganz modernen Flugzeugen", du listest hier Flugzeuge auf die bis in die späten 80er entwickelt wurden. Das Stichwort heute heisst IMA (integrated modular avionics), da sind die entsprechenden "Komponenten" zum Teil gar nicht mehr zum anfassen, sondern nur noch Softwarekomponenten auf Standardhardware. Zum Teil sogar zerstückelt auf verschiedenen Standardcomputern.

 

 

Ich bezweifle nach wie vor, daß die Turbinensteuerung derart komplex sein muß.

...

Flugzeuge die den heutigen Anforderungen erfüllen lassen sich mit der Technik von vor Jahrzehnten eben schlicht nicht bauen.

Genau, eine Turbinensteuerung muss deshalb so Komplex sein, weil die Ansprüche so gestiegen sind. Du kannst bis heute Turbinentriebwerke kaufen die null Elektronische Steuerung haben, und trotzdem funktionieren. Aber die Flugzeugmuster an denen die Verbaut werden, werden mangels Wirtchaftlichkeit im Moment ausgemustert. Die heute geforderten Leistungen, Verbräuche, Schadstoffausstöße, Hochlaufzeiten, Lebensdauern etc. kannst du nur noch mit aufwändiger Elektronik hinbekommen.

 

 

Software kann doch keine Ausrede sein jahrelang bekannte Prinzipien von Redundanz und Heterogenität zu ignorieren.

...

Das hat nix mit Software oder Hardware zu tun, sondern mit der Komplexität von Systemen:

Irgendwann haben auch Redundanz und Heterogenität ihre Grenzen, selbst völlig unterschiedliche Prozessoren und Programmiersprachen benutzen schlußendlich die gleichen Operationen, und werden anfällig für den selben Fehler. Sogenannte "Common Mode Fehler" sollten normalerweise ausgeschlossen werden, aber irgendwo "ticken" doch alle Programmierer gleich und ist die Anzahl anwendbarer Regelalgoritmen doch begrenzt, irgendwann kann man so in nicht vorhersehbare Fallen laufen. Normalerweise sollte das durch strenge Entwicklungsrichtlinien verhindert werden, aber wie das so im Leben ist, bei irgendeiner "last Minute Änderung" übersieht man dann doch etwas. Irgendwann wir die Komplexität so hoch, das kein systematisches Prüfprogramm mehr alle möglichen Fehler aufspüren kann, es wird dann zu einem statistischen Problem, wie viel man testen muss, um die Wahrscheinlichkeit eines versteckten Fehlers auf ein vertretbares Maß zu reduzieren. Ganz ausschließen kann man es praktisch gar nicht mehr. Aber das ist kein auf Systeme und Computer beschränktes Problem, auch in der Struktur kann man nie ausschließen, dass sich doch eine extrem unwahrscheinliche Kombination an Fehlern (Konstruktion, Fertigung, Wartung, Belastung...) ergibt, bei der es knallt. Das ist irgendwie wie bei einem chaotischen Pendel, je mehr Freiheitsgrade in einem System vorhanden sind, desto weniger kann man sein Verhalten vollständig vorhersagen.

 

Auch wenn es manche nicht wahrhaben wollen, immer phantastischere Leistungen kann man nicht bei immer weniger Gewicht für immer weniger Geld haben. 100% zuverlässig können nur derartig primitive Systeme sein, die heute keiner mehr will. Und jede weitere 9 hinter dem Komma bei der Zuverlässigkeit kostet Zeit und Geld. Irgendwann muss man mit dem Restrisiko leben.

 

Testflüge heissen nunmal so, weil sie dazu da sind, Probleme aufzuspüren. Normalerweise trifft man genügend Vorkehrungen, um damit leben zu können tatsächlich welche zu finden (das Flugzeug war z.B. todsicher sehr leicht, so dass es auch mit nur zwei Triebwerken hätte problemlos fliegen können müssen). Ein dreifacher Triebwerksausfall der nicht schon bei den umfangreichen Standläufen auftritt, ist etwas sehr, sehr unwahrscheinliches. Mal sehen, was wir für die Zukunft lernen können.

 

Gruß

Ralf

[iwl]

 Irgendwann haben auch Redundanz und Heterogenität ihre Grenzen, selbst völlig unterschiedliche Prozessoren und Programmiersprachen benutzen schlußendlich die gleichen Operationen, und werden anfällig für den selben Fehler. Sogenannte "Common Mode Fehler" sollten normalerweise ausgeschlossen werden, aber irgendwo "ticken" doch alle Programmierer gleich und ist die Anzahl anwendbarer Regelalgoritmen doch begrenzt

 

Jede Teilaussage halte ich für Stuß, "die gleichen Operationen", "alle gleich", "Anzahl begrenzt"

Prozessoren und Programmiersprachen haben nicht die gleichen Fehler.

Programmierer ticken nicht alle gleich und machen die gleichen Fehler.

Von den angeblich anzahlbegrenzten Algorithmen ist also dann keiner richtig...

[IFixPlanes]

deshald sage ich ja auch "in ganz modernen Flugzeugen", du listest hier Flugzeuge auf die bis in die späten 80er entwickelt wurden. Das Stichwort heute heisst IMA (integrated modular avionics), da sind die entsprechenden "Komponenten" zum Teil gar nicht mehr zum anfassen, sondern nur noch Softwarekomponenten auf Standardhardware. Zum Teil sogar zerstückelt auf verschiedenen Standardcomputern. ...

Bei denen ist aber dann nicht mehr die von dir explizit erwähnten Komponenten CPC und BSCU verbaut.

Aber wenn du schon IMA einbringen willst - gut.

Setzt du aber CPIOM Hardware mit CPC und BSCU gleich hast du das System nicht verstanden.

[flieger28]

Wenn ich diesen Bericht in der Aviation Week lese, scheint das Problem aber noch etwas tiefer zu gehen. Da ist auch davon die Rede, das unter Umständen zu einem bestimmten Zeitpunkt des Fluges, alle vier Triebwerke ausgefallen waren. Außerdem soll es ein Trimmungsproblem gegeben haben, welches zu einer starken Querneigung geführt haben soll, die nicht durch die Piloten zu kontrollieren war (not recocoverable).

Letzteres müsste sich ja durch die Daten des FDR entweder ausschließen lassen oder als eine Möglichkeit in Betracht gezogen worden sein. Zum Beispiel wenn die Maschine schon vor der Kollision mit dem Strommast diese Querneigung hatte und diesen erst dadurch überhaupt treffen konnte. 

In kann aber nichts zur Qualität dieser Quelle sagen
Link zum Artikel:http://aviationweek.com/defense/software-cut-fuel-supply-stricken-a400m

 

Sources have told Aviation Week that aircraft MSN23, destined for Turkey, featured new software that would trim the fuel tanks, allowing the aircraft to fly certain military maneuvers.

The sources state that the exact sequence of events is not yet clear, nor is it clear whether all four engines failed at some point. Some reports have suggested three engines failed. There also seems to have been a trimming issue leading to strong banking that was not recoverable.

The fuel supply was re-established, but not quickly enough for recovery to safe flight.

Bearbeitet 21. Mai 2015 von flieger28

[Chipart]

Jede Teilaussage halte ich für Stuß, "die gleichen Operationen", "alle gleich", "Anzahl begrenzt"

Prozessoren und Programmiersprachen haben nicht die gleichen Fehler.

Programmierer ticken nicht alle gleich und machen die gleichen Fehler.

Von den angeblich anzahlbegrenzten Algorithmen ist also dann keiner richtig...

 

Lieber Ingo,

 

keine Ahnung, ob Du Dich tatsächlich schon mal mit Design und Architektur redundanter Systeme beschäftigt hast - solltest Du vielleicht mal. Dann merkt man nämlich erst, wie schwer (bis unmöglich) echte Redundanz tatsächlich ist. 

 

Redundanz gegen zufällige Fehler (kippende Bits, EM-Einstrahlungen, ...) ist noch relativ einfach: man braucht 5(!) mal die gleiche Logik und vergleicht deren Ergebnisse um "das richtige" zu ermitteln. Es ist dabei eine Standard-Aufgabe in der technischen Informatik, sich zu überlegen, warum man 5-fache Redundanz braucht. Viele machen den Denkfehler, zu glauben, es würde dreimal die gleiche Schaltung reichen um einen einzelnen zufälligen Fehler zu eliminieren (man würde dann das Ergebnis als richtig annehmen, das zweimal vorkommt). Damit hat man dann aber im Komparator einen single point of failure geschaffen...

 

Redundanz gegen systematische Fehler ist viel schwieriger: Zunächst mal braucht man hier 3 Ende zu Ende unabhängige Designs - zwei reichen nicht, da man dann zwar feststellen könnte, dass die 2 Schaltungen zu unterschiedlichen Ergebnissen kommen, aber keinerlei Information bekommt, welches der beiden richtig sein könnte.

 

Und hier können wir nun eigentlich schon aufhören, über praktische Redundanz zu reden: Im Embedded-Bereich gibt es ARM und 8051. Zumindest alle VLSI-Bibliotheken die ich kenne sind von einer der beiden Zweige abgeleitet oder haben mit ihnen gemeinsame Vorfahren. 3-fach Design auf Hardware-Ebene geht nicht.

Für Arm gibt es gcc und RVCT als Compiler Cores (wobei ich da nicht mal sicher bin, ob die eigentlich unterschiedliche Code-Generatoren verwenden). Auch hier: 3-fach Redundanz geht nicht.

 

Das bedeutet, dass selbst wenn es überhaupt nicht um Kosten ginge und auch die unglaubliche Projektkomplexität eines echt redundanten Designs nicht mehr Fehler in so ein System bringen würde, als man mit Redundanz verhindern kann, is es schlicht heute nicht möglich, wirklich redundante Systeme zu bauen.

 

Florian 

[Volume]

 

Von den angeblich anzahlbegrenzten Algorithmen ist also dann keiner richtig...

natürlich ist jeder für sich richtig, aber durch die begrenzte Anzahl ist eine Kombination aus vielen davon anfällig für "common errors".

 

Die selben Regelphilosophien die wir auch mechanisch/elektrisch/pneumatisch etc. angewandet haben (Proportionalregler, Differentialregler...) programmieren wir heute. Dabei greifen wir alle auf die selben Operationen (Addition, Division...) zurück, die die selben numerischen Probleme (Auslöschung, Division durch Null, Überlauf...) haben können.

 

Probleme wie der (angebliche ?) Millenium Bug (ungeeignetes Datenformat für die Information die man verarbeiten will) können in gleicher Form in völlig verschiedener Software auftreten. Wenn ich einem Programmierer einen Rahmen vorgebe, wird er die Datentypen entsprechend wählen. Wenn dann plötzlich (in einem unvorhergesehenen Notfall) Zahlenwerte für Parameter auftauchen (wie z.B. 1500° Schräglage nach 5 Rollen...) an die die Programmierer nicht gedacht haben (auch weil nicht gefordert), dann steigen gleich mehrere unabhängige Programme aus. Kein hochintegriertes Cockpit für Verkehrsflugzeuge ist für Rollen programmiert, weil man eben glaubt, sowas passiert nicht. Nicht jeder Programmierer denkt daran, dass die Winkeldifferenz zwischen -180° Schräglage und 179°Schräglage eben -1° ist, nicht 359° (Vorzeichen und Größenordnung falsch...). Schon kann ein Differentalregelalgoritmus einen Überlauf haben, oder ein Proportionalregelagoritmus instabil werden.

Ein nettes Praxisbeispiel war die Navigationssoftware im A310, da hatte jemand völlig willkürlich den Koordinatenursprung mitten nach Sibirien gelegt, mit der frühen 80er Jahre Logik: Da wird garantiert nie ein Airbus fliegen. Und doch ist nach dem Fall der Sovietunion plötzlich jemand schlagartig vom (internen) -180° zum 180° Meridian geflogen, und natürlich ist der Computer abgestürzt... Und mit Karte und Kompass kommt man in Sibirien nicht sehr weit. (Finde den Fall gerade nicht im Netz, ist halt auch schon vor dem Internet passiert)

 

Wie gerade erst beim Dreamliner gesehen, können interne Zählvariablem überlaufen, wenn das Programm länger läuft als dem Programmierer im Pflichtenheft vorgegeben. Sehr viele völlig verschiedene Programme benutzen Zählvariablen, das ist ein absolut übliches "Standardwerkzeug" des Programmierers. Auch andere Werkzeuge (z.B. der Stack) werden in ihrer Größe anhand des Pflichtenhefts gewählt, wird ein Flugzeug dann darüberhinaus betrieben, kann er gleich in mehreren Programmen in verschiedenen Computern überlaufen. Vielleicht hat auch überhaupt niemand daran gedacht, dass Software eine Lebensdauer hat, einfach weil dieses Phänomen bei konventionellen Systemen so nicht existiert, die werden mit der Zeit schlechter (was Software nun wiederum nicht tut), aber versagen seltenst schlagartig ohne erkennbaren äußeren Anlass und ohne vorherige Anzeichen eines Problems.

 

Um das nochmal etwas zu verdeutlichen, stell dir vor du sollt einen Algoritmus programmieren, der im Autopilot das Flugzeug auf Kurs halten soll. Auf Nordkurs hast du nun das Problem, dass du manchmal 1° Abweichung (nach rechts) korrigieren musst, manchmal 359° (1° nach links). Also musst du entweder ständig diesen Nullpunktsdurchgang in jedem Rechenschritt und jeder Unterroutine beachten (mit dem Risiko es irgendwo mal zu übersehen), oder du sagtst einfach, ich definiere meine Nullpunkt bei 10000° Steuerkurs, und wenn der Pilot jetzt drei Kreise rechts fliegt, dann ist der Steuerkurs eben 11080°, und wenn er dann 4 Kreise links dreht ist der Steuerkurs 9640°. In dem Fall hast du nie Sprünge oder Vorzeichenwechsel im Steuerkurs, und nur bei der Anzeige für den Piloten musst du einmal MOD 360 rechnen. Dann aber musst du sicherstellen, das der Computer nach jedem Flug abgeschaltet (genullt) wird, und du must davon ausgehen, dass kein Pilot je auf einem einzigen Flug mehr als 27 Vollkreise in nach links fliegen wird (was mehreren Stunden Holding entsprechen würde). So können sich Probleme einschleichen, mit denen niemand rechnet. Vielleicht geht es für immer gut, vielleicht fliegt doch irgendwann mal jemand einen Linkskreis zuviel.

 

Wenn ich Systeme durch Software ersetze, muss ich andere Dinge beachten, als die Altvorderen für mechanische/elektrische/pneumatische/hydraulische... beachten mussten. Und da fehlt einfach noch die spezifische Erfahrung. Wir stehen immer noch am Anfang der Lernkurve, da wo wir 1905 bei der Flugmechanik, 1945 bei den Jettriebwerken, 1955 beim Überschallflug oder 1965 bei den Faserverbundwerkstoffen standen. Wir brechen gerade in eine neue Zeit auf, glauben aber die schon zu kennen (da wir ja überall auf Software vertrauen).

Bei vielen herrscht halt die Meinung vor, Luftfahrt wäre teilweise technologisch antiquiert, und z.B. die Automobiltechnik oder andere Industrieelektronik so fortschrittlich, das man sie sofort genauso auch in Flugzeuge einbauen, und davon nur Vorteile erwarten kann. 

 

In einem anderen Forum hat jemand gesagt, dieser Absturz wird in die Geschichtsbücher eingehen und die Luftfahrt ähnlich maßgeblich beeinflussen wie die Comet Crashs (Materialermüdung), 707 in Lusaka (Fail-Dafe Prinzip), JAL123 (Qualität von Reparaturen), SR111 (Verkabelung), TWA800 (Tankexplosion), Aloha (Interaktion von Korrosion und Materialermüdung, Grenzen des DamageTolerance Prinzips bei vielen Schadensstellen parallel) etc.

Als der erste Absturz der nachweislich auf Software zurückzuführen ist.

 

Ich sehe noch nicht, dass das allzuviele als Weckruf verstehen, mal sehen. Es passt einfach nicht in die Zeit an der Computertechnik auch etwas kritisch zu sehen. Zumal die allermeisten, insbesondere die Entscheidungsträger, von der Computertechnik ohehin nur alles ab der Benutzeroberfläche aufwärts kennen.

Und natürlich wachsen auch keine Experten für konventionelle Systeme mehr nach, von daher reden wir hier de-facto von einer unumkehrbaren Entwicklung.

 

Und als jemand, der dereinst den ZX81 und Atari 800 XL in Maschinensprache (Z80, 6502...) programmiert, Betriebssystem- und Treibersoftware geschrieben, und sicher schon eine Million Zeilen Code programmiert hat (mehrheitlich aerodynamische/flugmechanichsche Berechnungen, auch Echtzeitsimulationen dynamischer Flugmanöver und aeroelastischer Phänomene, aber auch Strukturrechnungen, natürlich auf leistungsfähigerer Hardware) maße ich mir schon an, ein bisschen von Software und ihren Problemen in der Luftfahrt zu verstehen. Obwohl sich sicher vieles geändert hat, so dürfte heute z.B. Speicherplatzmangel kein Grund mehr für vertrackte Algoritmen sein. (wenn man auf dem ZX81 nur 1024 Bytes hat, muss man um jedes Bit knausern und eben selbstvertändlich in jedem Byte 8 Informationen Speichern, oder 3 Bytes benutzen um 2 Zahlen mit je 12 Bit zu speichern, oder ein paar Bits eines Bytes benutzen, bei dem das Betriebssystem auch ein paar benutzt, oder ein Byte benutzen, das zeitweilig auch das Betriebssystem nutzt, aber eben nur in bestimmten vorhersehbaren Fällen...) Und auch genug Rechenpower für Echtzeitverarbeitung sollte heute vorhanden sein.

 

 

Setzt du aber CPIOM Hardware mit CPC und BSCU gleich hast du das System nicht verstanden.

Oder ich muss so abstrakt und allgemein formulieren um keine Details preiszugeben, die nicht in ein öffentliches Forum gehören...

Es ist manchmal schwierig etwas zu diskutieren, ohne konkret werden zu dürfen.

 

 

Gruß

Ralf

Bearbeitet 22. Mai 2015 von Volume

[IFixPlanes]

...

Oder ich muss so abstrakt und allgemein formulieren um keine Details preiszugeben, die nicht in ein öffentliches Forum gehören...

Es ist manchmal schwierig etwas zu diskutieren, ohne konkret werden zu dürfen.

Du hast immer noch nicht den Flieger genannt! Ich habe kein Problem damit, in einem öffentlichen Forum über Systeme zu diskutieren, deren Aufbau auch durch Inhalte von Schulungsunterlagen dargelegt sind.

Sich jetzt auf Daten zu berufen, "die nicht in ein öffentliches Forum gehören..."  bestätigt mir meine Vermutung.

[sirdir]

Redundanz gegen zufällige Fehler (kippende Bits, EM-Einstrahlungen, ...) ist noch relativ einfach: man braucht 5(!) mal die gleiche Logik und vergleicht deren Ergebnisse um "das richtige" zu ermitteln. Es ist dabei eine Standard-Aufgabe in der technischen Informatik, sich zu überlegen, warum man 5-fache Redundanz braucht. Viele machen den Denkfehler, zu glauben, es würde dreimal die gleiche Schaltung reichen um einen einzelnen zufälligen Fehler zu eliminieren (man würde dann das Ergebnis als richtig annehmen, das zweimal vorkommt). Damit hat man dann aber im Komparator einen single point of failure geschaffen...

Dann forderst du aber schon doppelte Redundanz, nicht? (Oder Redundanz gegen 2 verschiedene Probleme)

[Chipart]

Dann forderst du aber schon doppelte Redundanz, nicht? (Oder Redundanz gegen 2 verschiedene Probleme)

 

Nein, das ist aber ohne zeichnen zu können nicht ganz trivial zu beschreiben: Ich brauche ja für echte Redundanz 3 separate Komparatoren (eigentlich mehr, aber dann wird's philosophisch bzw. läuft darauf raus, dass das Zwei-Armeen-Problem nicht lösbar ist). Und worst case Fehler ist immer, dass einer der Komparatoren die Kommunikation auf dem Eingangsbus stört...

 

Florian

[Volume]

 

durch Inhalte von Schulungsunterlagen dargelegt

Auch Schulungsunterlagen sind keine Pressemeldungen, sie sind ausschließlich für Kunden bestimmt, und das ist auch zumindest auf der ersten Seite so gesagt.

 

 

Dann forderst du aber schon doppelte Redundanz, nicht?

Kommt auf die Funktion an.

Will ich eine Aktion haben (z.B. ein Überdruckschutz), genügen zwei. Selbst wenn der erste Controller bei erreichen des kritischen Drucks ein Ventil nicht öffnet, tut es der andere. Das verhindert aber schon nicht, dass ein einziger (von meinetwegen 1000) Controllern das Ventil zu früh, bei normalem Betriebsdruck öffnet.

Will ich eine Information haben (z.B. eine Fahrtanzeige) brauche ich bereits mindestens 3 Systeme, um bei Abweichungen den vermeintlich fehlerbehafteten Wert herausfiltern zu können. Je nach dem an welchen gemeinsamen Systemen (im primitivsten Fall an einer gemeinsamen Stromversorgung) sie hängen, kann aber natürlich immer noch sein, dass zwei falsch sind, und einer richtig. Also wenn 3 Systeme, dann wirklich 100% unabhängig.

 

Moderne Avionik (z.B. für den Fahrtmesser) hat aber auch nicht mehr eine Box mit Schlauchanschlüssen für Stau/Statik und ein Kabel für das Anzeigeinstrument, sondern mehrere Komponenten, die durchaus auch nur jeweils Teil einer anderen Einheit sein können. Sprich du hast einen Computer der ein bisschen Pitot, ein bisschen Beschleunigungen und ein bisschen Drehraten macht, einen anderen der ein bisschen Staudruck und ein bisschen Kabinendruck macht etc. Beide liefern eine Pitot-/Statikinformation dann weiter an einen Computer der daraus den Staudruck berechnet, das verarbeitet dann ein Computer zusammen mit der Temperaturinformation um eine Machzahlkorrektur vorzunehmen, das wird dann an einen Computer gemeldet der die Informationen für die Displays sammelt, der wiederum sendet das an einen der den Bildschirmaufbau macht (aber auch gleich noch für das FMS und die EFB...), und dann endlich geht es zum Display. Jeder der Computer bekommt natürlich irgendwo seinen Strom her und wird irgendwie gekühlt. Da zu entwirren wieviele wirklich redundante Systeme verbaut sind, ist schon nahezu unmöglich. Und führt dazu, dass manchmal mehr als 3 Redundanzen auf bestimmten Ebenen verbaut werden müssen, um bei der Funktion am Ende wenigstens eine Redundanz zu haben. Auch das war schon immer so, nur ist es eben dadurch verschärft worden, dass man heute einzelne Funktionen an immer mehr Komponenten koppelt, einfach weil es viel preiswerter ist, nicht für jedes Problem einen individuellen Computer zu bauen, sondern viele Universalcomputer (die angesprochene CPIOM Hardware) mit betreffender (Teil-)Software auszustatten um (neben Anderen) einzelne Aufgaben zu einer Gesamtfunktion zu übernehmen.

 

Bei vielen modernen Flugzeugen haben die Funktionsdiagramme und die tatsächliche Hardware kaum mehr etwas miteinander zu tun. Das was früher bei mechanischen/hydraulischen/elektrischen... Systeme anders, da hatte jede Komponente eine (und zwar nur eine) klare Funktion. Unter anderem auch aus Gründen der Verständlichkeit. Such mal als Mechaniker einen Fehler im Flieger, wenn du ihn nicht isolieren und durch Austausch von Einzelkomponenten lokalisieren und korrigieren kannst. Moderne Systeme wären ohne ihre integrierten Diagnosetools unbenutzbar. Und Fehler zu beheben, die die Diagnosetools nicht finden? Viel Spaß. (Ähnlich auch bei modernen Autos).

 

Ist beim A400M eigentlich mehr Redundanz verbaut, als bei Zivilflugzeugen? Es wird ja schließlich zusätzlich zu allen normalen Problemen auch noch manchmal drauf geschossen...

 

Gruß

Ralf

[IFixPlanes]

Auch Schulungsunterlagen sind keine Pressemeldungen, sie sind ausschließlich für Kunden bestimmt, und das ist auch zumindest auf der ersten Seite so gesagt. ...

Es ist wirklich faszinierend wie du dich um eine Antwort drückst.

 

[sirdir]

Nein, das ist aber ohne zeichnen zu können nicht ganz trivial zu beschreiben: Ich brauche ja für echte Redundanz 3 separate Komparatoren (eigentlich mehr, aber dann wird's philosophisch bzw. läuft darauf raus, dass das Zwei-Armeen-Problem nicht lösbar ist). Und worst case Fehler ist immer, dass einer der Komparatoren die Kommunikation auf dem Eingangsbus stört...

Eh ja, dachte ich hätte das Posting gar nicht mehr abgeschickt. Ich habe an 3 unterschiedliche Systeme gedacht. Bei 3 identischen hast du im Falle, dass die 'Entscheidungsfunktion' falsch funktioniert, natürlich keine Redundanz.

[PeterH]

Die (deutsche) Luftwaffe hat wohl ebenfalls einige Zweifel an einem Software-Problem als einzige Ursache für den Absturz:

 

http://www.spiegel.de/wissenschaft/technik/airbus-a400m-bundeswehr-zweifelt-an-der-absturzursache-a-1035136.html

 

... sagt zumindest SPIEGEL Online...

 

Gruß

Peter

Bearbeitet 25. Mai 2015 von PeterH

[fm70]

Gemäss neuesten Meldungen (z.B. hier) war es kein Programmierfehler, sondern es wurde schlicht bei der Endmontage die falsche Software aufgespielt (oder die richtige Software falsch aufgespielt, was auch immer das heisst). Also nix von wegen zu komplexe Software, verteilte Entwicklung und was sonst noch alles hier in die Diskussion geworfen wurde.

Bearbeitet 29. Mai 2015 von fm70

[Volume]

Wenn so ein Fehler möglich ist und unbemerkt bleibt, dann ist da mehr im argen, als der Trainingsstand einiger Mitarbeiter. Dann muss die Software so komplex sein, dass es nicht sofort auffällt. Solche Fehler müssen einfach beim Power on Self Test auffallen, sonst ist bei der Software etwas nicht korrekt programmiert.

"falsche" Software darf sich gar nicht aufspielen lassen, und nicht geprüfte und freigegebene Versionen dürfen auch gar nicht erst bis zum Flugzeug gelangen.

 

Wenn wir einen Zustand erreicht haben, in dem eine vollständige Kontrolle der Software nicht mehr möglich ist, dann ist es Zeit grundsätzlich umzudenken.

Ein Zustand wie "Zuhause" (wo auf keinen zwei Rechnern ein identisches Windows läuft...) ist in der Luftfahrt völlig inakzeptabel. Aus gutem Grund war bisher Avionik nocht "Plug and Play", sondern ein Softwarewechsel war kompliziert, und damit unter Kontrolle.

 

Gruß

Ralf

[fm70]

Wenn so ein Fehler möglich ist und unbemerkt bleibt, dann ist da mehr im argen, als der Trainingsstand einiger Mitarbeiter.

Immerhin wurde als erstes der Werksleiter entlassen. Also ortete man schon früh (aber trotzdem zu spät) ein gröberes strukturelles Problem.

 

Solche Fehler müssen einfach beim Power on Self Test auffallen, sonst ist bei der Software etwas nicht korrekt programmiert.

"falsche" Software darf sich gar nicht aufspielen lassen, und nicht geprüfte und freigegebene Versionen dürfen auch gar nicht erst bis zum Flugzeug gelangen.

Und wie, bitte, soll das gehen, wenn man die Software später weiterentwickeln will? Nein, weiterentwicklungsfähige Systeme haben es in sich, dass sich erstmal alles draufspielen lässt. Um hier Fehler zu vermeiden gibt es Arbeitsabläufe und Qualitätskontrollen. Hier hat offenbar beides versagt.

[Volume]

 

weiterentwicklungsfähige Systeme haben es in sich, dass sich erstmal alles draufspielen lässt.

Wir haben Generationen von weiterentwicklungsfähiger Avionik gehabt, bei der ein Softwareupgrade den Austausch von Eproms (oder ähnlichem) erfordert hat. Die Möglichkeit "einfacher" Softwareupgrades öffnet dem Chaos, und u.U. Hackern Tür und Tor, und war deshalb in der Luftfahrt immer absolut Tabu. Da aber vermutlich heute die Experten für Avionik nicht mehr aus der Luftfahrt, sondern aus der Computerbranche kommen, etablieren sie jetzt all das, was man Jahrzehntelang sorgfältig vermieden hat. Wenn sich "erstmal alles draufspielen lässt" steige ich in derartige Flugzeuge nicht mehr ein. Und in Kürze sind all die derzeiten Hirngespinste bezüglich Hackern dann doch plötzlich Realität.

Man kann Computersysteme nur entweder sicher, oder einfach upgradefähig konstruieren. Wenn man das eine haben will, wird man das andere verlieren. Sobald ich in einen Computersystem "Administratorenrechte" einräume, ist der Computer an sich völlig unsicher. Ab da muss ich Sicherheit über Kontrolle der Administratoren garantieren, und wir alle wissen wie zuverlässig Menschen in dieser Hinsicht sind... Und wie schnell sich Hacker diese Administratorenrechte beschaffen.

 

Gruß

Ralf