ANZEIGE
Da hilft nur Namensänderung. Darf man nach Zulassung eigentlich die Bezeichnung eines Types ändern?
10. März 2019: Ethiopian 737 MAX crash
- Starter*in HDH Aviation
- Datum Start
ANZEIGE
Da hilft nur Namensänderung. Darf man nach Zulassung eigentlich die Bezeichnung eines Types ändern?
Denke ich auch, ähnlich wie die DC10 über Jahre einen sehr schlechten Ruf hatte. Wenn jeder Passagier nur 5 EUR mehr zahlt, um einen Flug mit der MAX zu vermeiden, passt die ganze Kalkulation der Airlines nicht mehr.
Die dicken, weit vorstehenden Eier der Kiste lassen sich durch eine Namensänderung aber nicht wegdiskutieren.
Ob das reicht? Genug Nachfragen auf Twitter ob die 737-800 denn jetzt eine MAX sei oder nicht...
Ich glaube, dass sich die Mehrzahl der Passagiere nicht damit auseinandersetzt. Sieht man auch gut bei den Charterflügen, da steigen auch Leute bei zB türkischen oder ägyptischen Airlines ein, die ich meiden würde.
Die DC-10 war aufgrund des markanten Leitwerks leicht von außen zu identifizieren, ich glaube nicht, dass der Durchschnittspassagier auf die Schnelle eine MAX von einer NG unterscheiden kann.
Die DC-10 war aufgrund des markanten Leitwerks leicht von außen zu identifizieren, ich glaube nicht, dass der Durchschnittspassagier auf die Schnelle eine MAX von einer NG unterscheiden kann.
Wie ist eigentlich der Zulassungsprozess in Europa?
FAA stellt Genehmigung aus, EASA übernimmt im Falle von Boeing
EASA stellt aus und FAA übernimmt bei Airbus?
Oder prüft jede Behörde einzeln? Ich könnte mir nämlich vorstellen, dass sich hier durchaus Änderungen ergeben könnten...
FAA stellt Genehmigung aus, EASA übernimmt im Falle von Boeing
EASA stellt aus und FAA übernimmt bei Airbus?
Oder prüft jede Behörde einzeln? Ich könnte mir nämlich vorstellen, dass sich hier durchaus Änderungen ergeben könnten...
Ach nach ein paar Newszyklen wird da auch nicht mehr viel hängenbleiben... wäre doch eher ungewöhnlich, wenn die öffentliche Aufmerksamkeit ohne neuen Trigger nach ein paar Monaten noch auf dem Thema ist.
Wobei Du da nicht vergssen darfst, dass die meisten Pauschalurlauber sich ja nur darüber Gedanken machen, dass sie irgendwo ankommen, aber nicht wie. Wenn da ein bekannter Reiseanbieter dahintersteckt, dann wird vermutet, dass die dann schon wissen was sie tun.
Welche Airline dann den Flug durchführt ist dabei nicht immer bekannt - nicht einmal dem Reisebüro. Oder man achtet nicht drauf sondern schaut lieber 300 Bilder des Reiseziels an.
Wirklich vereinfacht dargestellt: Auch wenn die Grundlagendokumente nicht unbedingt identisch sind, gibt es ein bilaterales "Agreement", dass die Zulassung einer Agency von der jeweils anderen ohne großen Aufwand anerkannt wird.
Könnte es sein, dass die EASA aufgrund der Nähe der FAA zu Boeing das überdenkt? Oder ist das Naheverhältnis zwischen EASA und Airbus eh auch nicht anders...?
Nein, die NG-Versionen heißen 737-800 und 737-900
Und genau diese vereinfachte Anerkennung der Zulassung der MAX durch die FAA könnte die EASA aussetzen... dann müsste Boeing das Teil komplett durch das EU Zulassungsverfahren tragen. Und wenn dann auch noch China vergleichbar reagiert.....
Aber sowas führt, ob begründet oder nicht, natürlich zu Retourkutschen.
Deshalb auch "aussetzen" und nicht widerrufen oder zurückziehen. Eine Aussetzung kann man wieder aufheben.
Aber sowas führt, ob begründet oder nicht, natürlich zu Retourkutschen.
Deshalb auch "aussetzen" und nicht widerrufen oder zurückziehen. Eine Aussetzung kann man wieder aufheben.
T
Txx
Guest
Genau, nehmen wir mal einen Attentäter mit etwas Kampfsport Know-how an. Geht zur Toilette und dann direkt weiter, überwältigt die Piloten und drückt das Steuer (je nach Flugzeug möglich oder auch nicht mehr meine ich) massiv nach unten. Da will ich Dich mal sehen, wie Du überhaupt von Deinem Platz loskommst.
Aber die Anderen haben absolut recht, Trolle nicht füttern, habe vor kurzem die Ignorierfunktion kennengelernt, da wird das Lesen hier bestimmt angenehmer.
Prinzipiell hat Zulassung immer viel mit Vertrauen zu tun. Das sieht auch in Europa nicht anders aus, da den Zulassern in aller Regel sowohl das allumfassende technische Verständnis als auch die Zeit fehlt, sämtliche Dokumentation vollumfänglich zu prüfen. Wobei meine Erfahrung mir zeigt, dass die Zulasser schon genau wissen, wo sie hingucken müssen, damit sie genau den wunden Punkt treffen. Solange also eine gewisse Unabhängigkeit zwischen Hersteller und Zulasser besteht, ist dieses "Vertrauensprinzip" ja auch prinzipiell nicht verkehrt. Ohne würde man in dieser komplexen Welt der Zulassung wohl niemals auch nur über den ersten Schritt hinaus kommen. Da diese Unabhängigkeit in den USA scheinbar nicht mehr so gegeben scheint, könnte ich mir schon vorstellen, dass die Anerkennung seitens EASA zwar immer noch vereinfacht, allerdings etwas genauer und penibler erfolgen wird als in der Vergangenheit. Aber bitte beachten, dass dies eine Einschätzung eines äußerst komplexen und langwierigen Prozesses ist und somit wirklich nur als sehr oberflächliches Stammtisch-Statement angesehen werden kann. Würde ich ins Detail meiner Schulungsunterlagen gehen, dann würde das ganze schnell ausufern und wirklich extrem trocken werden.
Ja, es wird bei EASA diskutiert die Zulasssung der Max Versionen auf Eis zu legen und eventuell den ganzen Zertifizierungsprozess neu aufzurollen. Offensichtlich har Boeing dabei falsche Angaben gemacht. Würde das "offiziell" werden wäre zumindest die europäische ( und wohl weitere ) Zulassung ungültig.
Viel schlimmer heisst aber Super-Gau: da diskutieren die Ingineure gerade ob das Design Flaw der Max überhaupt noch zulassungsfähig ist. Das ging 1970, auch noch 1990 bei Airbus aber 2019 sollte ein Flugzeug bei Neuzertifizierung OHNE Software auskommen die bekannte Mängel im Zaum hält.
Hört sich an, wie der Fall VW, nur mit umgekehrten Vorzeichen.
Und vor allem mit Lebensgefahr für Menschen. Auch wenn am Feinstaub ja jährlich Millionen Menschen sterben
Läuft man da nicht die Gefahr, dass am Ende der Staat haften muss? Wenn man ein prinzipiell nicht zulassungsfähiges Flugzeug zugelassen hat? Da könnte sogar Boeing eine Entschädigung verlangen - die relativ schlechten Flugeigenschaften müssen der EASA vorab bekannt gewesen sein.
Und wie will man sich von älteren Flugzeugtypen abgrenzen, die heute als neue Flugzeugmodelle ebenfalls nicht mehr zulassungsfähig wären?
Das ist wirklich ein trauriger Vorfall, der vielen Menschen das Leben gekostet hat.
Nach dem Motto "safety first" emfinde ich das (vorläufige) Grounding als die richtige Entscheidung. Wichtig in diesem Punkt ist meiner Meinung nach einfach in der Statistik die Korrelation nicht ausser Acht zu lassen - mitunter der absolut häufigste Fehler in statistischen Analysen, egal ob es dadurch besser oder schlechter wird.
Es gibt starke Hinweise dafür, dass in 2 Fällen kurz hintereinander ein und dasselbe(!) System so reagiert hat, dass die Piloten die Maschine nicht mehr in der Luft halten konnten. Dazu gibt es einige anonyme Berichte, die über ein ähnliches aber glimpflich ausgegangenes Verhalten erzählt haben. Und scheinbar ist es schwierig das zu kontrollieren trotz der bekannten Maßnahmen nach dem ersten Vorfall.
Die Statistik bei diesem neuen Flugzeugtypen ist nicht sehr groß, daher sollte dies erst in Ruhe überprüft und ggfs. verbessert werden, daher meine volle Unterstützung für das Grounding. Besser einmal zu viel und das auf Grund einer falschen Vermutung aussprechen, als ein weiteres Unglück zu riskieren.
Mittlerweile bin ich u.a. für Softwareentwicklung für Anwendungen in der Industrieproduktion zuständig. Daher ist meine Sichtweise auf Software folgendermaßen:
- In der Regel sind Computerprogramme deterministisch, d.h. verhalten sich bei gleichen Eingabeparametern vollständig identisch (ich gehe vor Allem bei derart sensiblen Systemen nicht davon aus, dass man nicht deterministische Algorithmen verwendet).
- Es ist sehr schwierig während der Entwicklung alle Situationen vorauszusehen und dafür entsprechende Tests zu schreiben, bei Testlfügen zu simulieren und dann alle Verhaltensweisen korrekt abzufangen.
- Wenn bei Software ein unerwartetes Verhalten auftritt steckt meistens eine nicht bedachte Ausgangssituation dahinter, oder eine falsche Parametereingabe (z.B. Sensor kaputt / verdreckt / aus der montierten Position gerutscht).
- Man kann auch banalerweise etwas übersehen, dass in einem bestimmten (regulären!) Fall der Algorithmus ein nicht gewolltes Ergebnis rausbringt (Softwarefehler). Das kann so sein, dass es nur in seltenen Fällen passiert, und meistens eben nicht in diesen Zweig springt, da die Situation selten auftritt.
- Es kann auch durch eine nicht bedachte Handlungsweise des Bedieners ausgelöst werden. Stichwort: Ich habs entwickelt, ich weiß genau wie ich es bedienen soll. Jemand der das nicht gemacht hat, geht aber vielleicht anders an die Aufgabe dran und kann daher ein anderes Programmverhalten auslösen als gewollt. Man ist dann "betriebsblind" und sieht diese Vorgehensweise erst, wenn es jemand anders so macht.
-> Aus meiner Erfahrung heraus ist es besser, als Lösung zusätzliche Infos im Programm einzublenden und / oder diese Bedienung zu verhindern, bzw. das Programm auf diese Arbeitsweise anzupassen, als eine Schulung vorzunehmen, um diese Art der Bedienung zu verhindern... Gerade in Hektik gibt es ansonsten eine potentielle Gefahr etwas falsch zu machen.
Insbesondere wenn die unerwünschte Verhaltensweise mehrmalig auftritt ist es meiner Meinung nach Zeit sich diesen Punkt genauer anzusehen -> Daher das Grounding absolut folgerichtig. Die Vorgehensweise des Groundings an sich ist dann ein völlig anderer Aspekt. Dieser ist nicht besonders gut und koordiniert vorgenommen worden -> Dafür kann aber weder der Hersteller noch der Fehler an sich etwas und sollte daher getrennt beurteilt werden. Da sollte man hier auch nicht auf die ungefilterte und entweder nicht durchdachte / reflektierte oder absichtlich provozierende "Argumente" bestimmter Schreiblinge eingehen.
Den Unterschied den ich hier sehe, und den ich Boeing (sofern es sich als der Grund des Unfalls rausstellt!) ankreide:
In der Industrie ist es aus Kostengründen üblich auch noch Nachbesserungen in der Inbetriebnahme Phase durch Tests im realen Betrieb beim Kunden vorzunehmen.
Hier hat man aber auch einfach mal Zeit sich Gedanken über den Grund eines Fehlers zu machen und den in Ruhe zu analysieren. Andererseits stehen die Kosten eines kurzen Stillstandes (es lässt sich ja im Handbetrieb im Normalfall recht schnell lösen) plus Softwarenachbesserung in keinem Verhältnis zu den erhöhten Entwicklungskosten für eine deutlich längere Testphase.
In der Luftfahrtindustrie hat man aber ein viel klarer Umrissenes Aufgabenspektrum. Es basiert auf weniger möglichen Fällen / Inputs und bedeutet eine abgekoppelte Reaktion von anderen Bauteilen.
Es ist Lebenswichtig und im Fehlerfalle kann es katastrophal sein. Dort sollten also viel höhere Ansprüche geltend gemacht werden und "einfacher" Tests geschrieben werden können.
Insbesondere eine Plausibilitätsprüfung von Eingabewerten der Sensoren würde ich mir wünschen. Gerade die Vergangenheit hat ja einige Vorfälle verursacht durch defekte / eingefrorene / verstopfe Sensoren aufgezeigt.
Was ich hier allerdings - zugegeben mein Wissensstand ist hier aus den Medien / Berichten zusammengewürfelt - merkwürdig finde ist, dass diese Software etwas verschleiert wird.
Üblicherweise ja ein Hinweis darauf, dass man das absichtlich zum Kaschieren eines Problems macht.
Meiner Meinung nach sollte es eine klare Anzeige im Cockpit geben:
- System greift ein, ggfs. mit 2-3 Begründungen
- Hier kann ich das System overrulen / Abstellen.
-> Genau das macht ja sogar das ESP im Auto: Ich sehe, wenn es eingreift.
Mit dieser Info kann ein Pilot doch viel gezielter eingreifen, als erstmal verwundert zu sein "Fuck warum macht das Flugzeug das? Ich verstehe das nicht?" Das blockiert die Reaktion eines Menschen!
- Zudem ist meiner Meinung nach essentiell: Validierung des Sensorinputs über mindestens ein 2. System. Gerade in der Luftfahrtindustrie gibt es doch eine starke Redundanz. Dazu kann man sich das differentiell / zeitlich betrachten.
Wenn da was nicht passt -> abschalten mit Warn Meldung an den Piloten.
Vorgehensweise wie man das Flugzeug vielleicht nicht optimal aber stabil bekommt (zB wie auch anstellen und Schub geben, wenn die Sensoren ausfallen ala AF447).
Meiner Meinung nach sollte Boeing der Öffentlichkeit beantworten, ob und wie diese Punkte erfüllt wurden, und wenn Nein warum nicht.
Daraus könnte man in Zukunft lernen, um die sicherlich häufiger werden "Assistenzsysteme" besser zu entwickeln und abzusichern.
Je umfangreicher eine Software, desto höher ist die Wahrscheinlichkeit eines Fehlers ...
Ich denke in diese Richtung sollte auch die Entwicklung von Boeing gehen, bzw. wird sie auch gehen (Softwareupdate....).
Alles unter Vorbehalt, dass sich die begründeten Vermutungen als wahr aufzeigen.
Nach dem Motto "safety first" emfinde ich das (vorläufige) Grounding als die richtige Entscheidung. Wichtig in diesem Punkt ist meiner Meinung nach einfach in der Statistik die Korrelation nicht ausser Acht zu lassen - mitunter der absolut häufigste Fehler in statistischen Analysen, egal ob es dadurch besser oder schlechter wird.
Es gibt starke Hinweise dafür, dass in 2 Fällen kurz hintereinander ein und dasselbe(!) System so reagiert hat, dass die Piloten die Maschine nicht mehr in der Luft halten konnten. Dazu gibt es einige anonyme Berichte, die über ein ähnliches aber glimpflich ausgegangenes Verhalten erzählt haben. Und scheinbar ist es schwierig das zu kontrollieren trotz der bekannten Maßnahmen nach dem ersten Vorfall.
Die Statistik bei diesem neuen Flugzeugtypen ist nicht sehr groß, daher sollte dies erst in Ruhe überprüft und ggfs. verbessert werden, daher meine volle Unterstützung für das Grounding. Besser einmal zu viel und das auf Grund einer falschen Vermutung aussprechen, als ein weiteres Unglück zu riskieren.
Mittlerweile bin ich u.a. für Softwareentwicklung für Anwendungen in der Industrieproduktion zuständig. Daher ist meine Sichtweise auf Software folgendermaßen:
- In der Regel sind Computerprogramme deterministisch, d.h. verhalten sich bei gleichen Eingabeparametern vollständig identisch (ich gehe vor Allem bei derart sensiblen Systemen nicht davon aus, dass man nicht deterministische Algorithmen verwendet).
- Es ist sehr schwierig während der Entwicklung alle Situationen vorauszusehen und dafür entsprechende Tests zu schreiben, bei Testlfügen zu simulieren und dann alle Verhaltensweisen korrekt abzufangen.
- Wenn bei Software ein unerwartetes Verhalten auftritt steckt meistens eine nicht bedachte Ausgangssituation dahinter, oder eine falsche Parametereingabe (z.B. Sensor kaputt / verdreckt / aus der montierten Position gerutscht).
- Man kann auch banalerweise etwas übersehen, dass in einem bestimmten (regulären!) Fall der Algorithmus ein nicht gewolltes Ergebnis rausbringt (Softwarefehler). Das kann so sein, dass es nur in seltenen Fällen passiert, und meistens eben nicht in diesen Zweig springt, da die Situation selten auftritt.
- Es kann auch durch eine nicht bedachte Handlungsweise des Bedieners ausgelöst werden. Stichwort: Ich habs entwickelt, ich weiß genau wie ich es bedienen soll. Jemand der das nicht gemacht hat, geht aber vielleicht anders an die Aufgabe dran und kann daher ein anderes Programmverhalten auslösen als gewollt. Man ist dann "betriebsblind" und sieht diese Vorgehensweise erst, wenn es jemand anders so macht.
-> Aus meiner Erfahrung heraus ist es besser, als Lösung zusätzliche Infos im Programm einzublenden und / oder diese Bedienung zu verhindern, bzw. das Programm auf diese Arbeitsweise anzupassen, als eine Schulung vorzunehmen, um diese Art der Bedienung zu verhindern... Gerade in Hektik gibt es ansonsten eine potentielle Gefahr etwas falsch zu machen.
Insbesondere wenn die unerwünschte Verhaltensweise mehrmalig auftritt ist es meiner Meinung nach Zeit sich diesen Punkt genauer anzusehen -> Daher das Grounding absolut folgerichtig. Die Vorgehensweise des Groundings an sich ist dann ein völlig anderer Aspekt. Dieser ist nicht besonders gut und koordiniert vorgenommen worden -> Dafür kann aber weder der Hersteller noch der Fehler an sich etwas und sollte daher getrennt beurteilt werden. Da sollte man hier auch nicht auf die ungefilterte und entweder nicht durchdachte / reflektierte oder absichtlich provozierende "Argumente" bestimmter Schreiblinge eingehen.
Den Unterschied den ich hier sehe, und den ich Boeing (sofern es sich als der Grund des Unfalls rausstellt!) ankreide:
In der Industrie ist es aus Kostengründen üblich auch noch Nachbesserungen in der Inbetriebnahme Phase durch Tests im realen Betrieb beim Kunden vorzunehmen.
Hier hat man aber auch einfach mal Zeit sich Gedanken über den Grund eines Fehlers zu machen und den in Ruhe zu analysieren. Andererseits stehen die Kosten eines kurzen Stillstandes (es lässt sich ja im Handbetrieb im Normalfall recht schnell lösen) plus Softwarenachbesserung in keinem Verhältnis zu den erhöhten Entwicklungskosten für eine deutlich längere Testphase.
In der Luftfahrtindustrie hat man aber ein viel klarer Umrissenes Aufgabenspektrum. Es basiert auf weniger möglichen Fällen / Inputs und bedeutet eine abgekoppelte Reaktion von anderen Bauteilen.
Es ist Lebenswichtig und im Fehlerfalle kann es katastrophal sein. Dort sollten also viel höhere Ansprüche geltend gemacht werden und "einfacher" Tests geschrieben werden können.
Insbesondere eine Plausibilitätsprüfung von Eingabewerten der Sensoren würde ich mir wünschen. Gerade die Vergangenheit hat ja einige Vorfälle verursacht durch defekte / eingefrorene / verstopfe Sensoren aufgezeigt.
Was ich hier allerdings - zugegeben mein Wissensstand ist hier aus den Medien / Berichten zusammengewürfelt - merkwürdig finde ist, dass diese Software etwas verschleiert wird.
Üblicherweise ja ein Hinweis darauf, dass man das absichtlich zum Kaschieren eines Problems macht.
Meiner Meinung nach sollte es eine klare Anzeige im Cockpit geben:
- System greift ein, ggfs. mit 2-3 Begründungen
- Hier kann ich das System overrulen / Abstellen.
-> Genau das macht ja sogar das ESP im Auto: Ich sehe, wenn es eingreift.
Mit dieser Info kann ein Pilot doch viel gezielter eingreifen, als erstmal verwundert zu sein "Fuck warum macht das Flugzeug das? Ich verstehe das nicht?" Das blockiert die Reaktion eines Menschen!
- Zudem ist meiner Meinung nach essentiell: Validierung des Sensorinputs über mindestens ein 2. System. Gerade in der Luftfahrtindustrie gibt es doch eine starke Redundanz. Dazu kann man sich das differentiell / zeitlich betrachten.
Wenn da was nicht passt -> abschalten mit Warn Meldung an den Piloten.
Vorgehensweise wie man das Flugzeug vielleicht nicht optimal aber stabil bekommt (zB wie auch anstellen und Schub geben, wenn die Sensoren ausfallen ala AF447).
Meiner Meinung nach sollte Boeing der Öffentlichkeit beantworten, ob und wie diese Punkte erfüllt wurden, und wenn Nein warum nicht.
Daraus könnte man in Zukunft lernen, um die sicherlich häufiger werden "Assistenzsysteme" besser zu entwickeln und abzusichern.
Je umfangreicher eine Software, desto höher ist die Wahrscheinlichkeit eines Fehlers ...
Ich denke in diese Richtung sollte auch die Entwicklung von Boeing gehen, bzw. wird sie auch gehen (Softwareupdate....).
Alles unter Vorbehalt, dass sich die begründeten Vermutungen als wahr aufzeigen.
Ich will dir keinesfalls zu nahe treten aber vielleicht solltest du dich zunächst mal damit befassen wie Software in der Luftfahrt überhaupt entwickelt wird und was für ein Aufwand zur Absicherung dort getrieben wird. Die paar Tests die du und ich jeden Tag schreiben sind dagegen ein Witz.
Du darfst auch davon ausgehen, dass die Piloten in aller Regel eine grobe Anzeige haben was jetzt gerade an Hilfssystemen aktiv ist. Beschränkt auf die relevanten natürlich. Es dürfte schlicht ein Ding der Unmöglichkeit sein alle gerade aktiven/inaktiven Systeme übersichtlich für einen Menschen auf einen Blick visuell darzustellen.
In dem vorliegenden Fall kommt erschwerend hinzu, dass selbst wenn es so etwas geben würde die Zeit wahrscheinlich nicht ausgereicht hätte um den Fehler aus so einem Dashboard zu erkennen und die Gegenmaßnahmen rechtzeitig einzuleiten. Genau wissen wir das aber erst wenn die Daten ausgewertet wurden.
Boeing wird sicherlich nichts dergleichen tun, schon gar nicht öffentlich. Evtl. falls es zu Anhörungen im Kongress/Senat käme, aber davon sind wir weit weg.
Boeing kann allein schon wegen der drohenden Schadensersatzklagen keine Aussagen treffen, die auch nur den Hauch eines Schuldeingeständnisses haben. Sprich Boeing kann gar nicht anders, als durchgehend zu behaupten, dass ihr Produkt super ist und sie es nicht hätten anders Entwickeln, Bauen und Zulassen können. Daher auch die Formulierungen, dass dieses Softwareupdate dazu dienen würde, das Produkt "noch sicherer zu machen".
Ebenso würde mich es wundern, wenn die FAA zugeben würde, dass die von ihnen zugelassene MAX doch nicht ganz so gut ist. Die haben offensichtlich bei der Zulassung gepfuscht und in den USA sehe ich momentan kein Klima, was eine Aufarbeitung ermöglichen würde. Schon allein weil Trump immer nur gewinnt und nie verliert. "America first" heisst sicherlich auch, dass man den eigenen Hersteller (Boeing) nicht unnötig geisselt.
Ich denke Boeing wird die Software nachliefern und evtl. sogar was an den Sensoren machen um die Redundanz zu erhöhen. Dann fliegen die MAX wieder und alles wird gut (war ja beim Dreamliner mit den Batterien auch so).
Auf ein öffentliches "Mea culpa" oder dergleichen können wir lange warten.
Wie unterscheidet sich der vorliegende Fall von einem "Runaway Trim", den der Pilot ebenfalls erkennen und Gegenmassnahmen treffen muss?