10. März 2019: Ethiopian 737 MAX crash
- Starter*in HDH Aviation
- Datum Start
ANZEIGE
Es ist die Aufgabe von Aufsichtsrat/Vorstand/GF Schaden vom Unternehmen abzuwenden. Je nachdem wie ungeschickt man sich anstellt, haften sie mit ihrem persönlichen Vermögen dafür. Bevor sich also jemand vor die Kameras stellt und etwas zugibt, muss intern erst die Tragweite und die Verantwortung für das Geschehene geklärt (oder festgelegt) werden... das dauert. Ich glaube schon, dass Boing an dem Thema dran war aber versucht hat, dass ganze möglichst "nachhaltig" und geräuschlos zu lösen. Das dies bisher nicht geschehen ist, weist m.M. darauf hin, das dieses Problem nicht so (ohne Hardwareänderungen) einfach zu lösen ist.
Die Toten macht man leider auch mit juristischen Konsequenzen nicht wieder lebendig.
Richtig ist natürlich der Vergleich mit VW. Boeing sollte jetzt diskussionslos und großzügig entschädigen, wenn sie noch einen Funken Glaubwürdigkeit behalten wollen. VW USA taugt als Beispiel, VW Deutschland nicht.
Meiner bescheidenen Meinung nach ist es zudem vor allem notwendig, die notwendigen Sicherheitsverbesserungen in Hard- und (!) Software konsequent und ohne jede Rücksicht auf wirtschaftliche Vorgaben knallhart durchzuziehen und rigorios zu prüfen, und zwar auch bezüglich kritischer Flugzustände mit entsprechenden Testflügen.
Damit wird den Toten am meisten gedient, nämlich indem es sicher keine weiteren Toten mehr gibt.
Und wenn das viel Geld kostet und lange dauert, dann ist das halt so.
Erstklassige Leute nützen nichts, wenn Projekt-/Unternehmensstruktur nicht passt.
Das ist jetzt meine persönliche, zynische Bitterkeit, aber evtl hat dies etwas damit zu tun https://conferences.computer.org/stc/2013/papers/0001a001.pdf
Wahrscheinlich waren die Sicherheitsmechanismen noch im Wasserfallmodell....
Das ist jetzt meine persönliche, zynische Bitterkeit, aber evtl hat dies etwas damit zu tun https://conferences.computer.org/stc/2013/papers/0001a001.pdf
Wahrscheinlich waren die Sicherheitsmechanismen noch im Wasserfallmodell....
Zuletzt bearbeitet:
Im Automobilsektor nennt man sowas FMEA und muss entwicklungsbegleitend bei allen Gate Reviews ebenfalls einen gewissen Reifegrad aufweisen. Diese Methodik ist eigentlich auch in der Luftfahrtbranche selbstverständlich. Zumal Systemfehler im Flugzeug deutlich kritischer sind als im KFZ. Es geht im weitesten Sinne um die Einstufungen in die Kritikalität/Entdeckungswahrscheinlichkeit und Auftretenswahrscheinlichkeit gewisser Fehler. Das ganze wird dann miteinander multipliziert zu einer sogenannten RPN. Je höher der RPN-Wert, desto höher die Notwendigkeit zu handeln.
Nun war hier schon vor geraumer Zeit zu lesen, dass Boeing (und oder FAA) MCAS-Fehler als kritisch aber nicht katastrophal eingestuft wurden. Dadurch verringert sich die RPN eines solchen Fehlers signifikant und u. U. fällt er dann aus den Top 10 raus.
Wenn dann auch noch die FAA Leute eigentlich Boeing-Leute sind, fehlt genau die kritische Fremdsicht, die zur Bewertung einer FMEA unumgänglich ist.
Zuletzt bearbeitet:
M
Mcflyham
Guest
Ich glaube auch bei Boeing ist mittlerweile jedem klar, dass der Kosntruktions-/Zulassungsprozess hätte besser/anders laufen müssen.
Ich hab eher das Gefühl, bei Boeing wurde und wird zum Thema MCAS in agiler Projektform entwickelt. Alle Sprints wurden/werden sehr kundennah getestet...
Nach einem "erfolgreichen" (Pfusch?) Sprint ist man in der Folge in 2 gescheiterte Sprints gelaufen und versucht nun mit einem gepfuschten 4. Sprint die anderen Sprints wieder vergessen zu machen um zu Sprint 1 zurück zu kehren...
Sorry, wenn ich es so knallhart sage: Selbst die hätten erkannt, dass man nicht nur die Daten von einem Sensor in eine sehr zentrale Steuerungsfunktion einfließen läßt, und vor allem nicht ohne brauchbaren Plausibilitätscheck. Selbst der (gute) Praktikant hätte das erkannt. Kann natürlich sein, dass Sales soviel Stress gemacht hat, dass es durchging, oder sie haben die Programmierung in Fernost beauftragt, oder so:
Oh no. Sorry, aber derlei agiles Modell hat in der Luftfahrt nicht viel verloren.
"Agil" ist bis zu einem gewissen Grad immer auch Try and Error bzw. unklare Verantwortung, auch wenn die Proponenten das massiv bestreiten
Glaubst die Jungs bei VW oder Bosch hatten da eine "Gehe aus dem Gefängniss frei" Karte?
Die gibts in jedem Unternehmen dieser grösse mehr als du dir vorstellen kannst in jedlicher Position.
Aber selbstverständlich. Vielleicht keine offensichtlichen Idioten oder komplett Unqualifizierte. Aber je größer ein Unternehmen und je durchlässiger die verschiedenen Abteilungen, desto größer ist der Anteil derer, die aus verschiedensten Gründen für ihr aktuelles Aufgabenfeld nur eingeschränkt geeignet sind.
Dazu kommen dann noch die eigentlich guten Leute, denen es aber mitunter an beruflicher Ethik, Gewissenhaftigkeit und Verantwortungsgefühl fehlt. D. h. erstklassige Leute, die aber bewusst oder unbewusst unterklassige Arbeit abliefern.
Tut mir leid, aber bei diesen Plattitüden zuvor muss man mal drauf hinweisen dürfen, was da abgesondert wurde. Es wird doch der ernsten Sache nicht gerecht, wenn hier wie beim Starkbieranstich palavert wird?
Das scheint mir hier vorallem das Problem zu sein
Zumal es Hinweise nach dem ersten Crash auf eine Fehlfunktion gab, dann nicht gehandelt wurde, dann der zweite Crash kam, woraufhin wieder rumgeeiert wurde und dann erst internationale Stellen das Ding grounden mussten, damit Ruhe ist.
Gegenfrage: Beruflich schonmal mit Boeing oder Airbus jenseits vom Consulting zu tun gehabt? Also so rein "technische" eben? Oder anderen sensiblen Firmen? Oder einfach nur der Gedanke das die HR Abteilung schon sich was bei gedacht hat die Leute einzustellen?
LOL, Agile und SCRUM löst sicherlich nicht sicherheitskritische Daten in ein Projekt einfließen zu lassen. Es vermittelt nur "scheinbare" Sicherheit, dadurch dass Probleme aufgeschoben werden bis in den St. Nimmerleins Sprint und ständig um Probleme herumgodoktort wird. Sorry, aber das klassische Wasserfall Modell verschiebt keine Probleme da es klare Strukturen und Ebenen bietet und daraus resultierend Checkpoints für definierte Ebenenwechsel. Aber das ist heute nicht mehr opportun, Agile ist hip, weil man darf offiziell ständig seine Meinung ändern (aka angepasstes Anforderungs Management
) und muss sich nicht vorher über alle Konsequenzen Gedanken machen. Ja, Wasserfall dauert länger, aber es entspricht mehr einem Ingenieursmäßigem Vorgehen.Ich bin sicherlich kein Luftfahrtexperte oder Luftfahrtkonstrukdinger...aber ich bilde mir ein etwas von mechanischen Fertigungsverfahren und deren Umsetzbarkeit zu verstehen. Und da bekommt man nunmal so manchen Schenkelklopfer aus genau diesen Häussern auf den Tisch nach dem Motto "Warum soll das nicht gehen?". Und viele Sachen gehen nunmal so nicht. Das fängt bei Teilen an die sich halt bei der Bearbeitung verziehen und halt entweder gerichtet werden müssen (was ja in der Regel ausfällt) oder halt anders bearbeitet werden müssen. Und hört nunmal bei absolut an der Realität vorbei gegebenen Toleranzen auf. Von daher kann ich durchaus sagen das es da in vielen Positionen Unterklassiges Personnal gibt.
Aber trotz allem muss man sich eben die Frage erlauben WIE um alles in der Welt sowas den auf die Welt losgelassen werden kann. Entweder wurde nunmal bei diesem Problem durch Unwissenheit einfach geschlampt über alle Instanzen oder es wurde bewust in Kauf genommen aufgrund der Wirtschaftlichkeit. Beide Punkte beruhigen zuminderst MICH nicht.
Aber trotz allem muss man sich eben die Frage erlauben WIE um alles in der Welt sowas den auf die Welt losgelassen werden kann. Entweder wurde nunmal bei diesem Problem durch Unwissenheit einfach geschlampt über alle Instanzen oder es wurde bewust in Kauf genommen aufgrund der Wirtschaftlichkeit. Beide Punkte beruhigen zuminderst MICH nicht.
Danke, danke, danke! Genau das meinte ich - falls das nicht so rezipiert wurde.LOL, Agile und SCRUM löst sicherlich nicht sicherheitskritische Daten in ein Projekt einfließen zu lassen. Es vermittelt nur "scheinbare" Sicherheit, dadurch dass Probleme aufgeschoben werden bis in den St. Nimmerleins Sprint und ständig um Probleme herumgodoktort wird. Sorry, aber das klassische Wasserfall Modell verschiebt keine Probleme da es klare Strukturen und Ebenen bietet und daraus resultierend Checkpoints für definierte Ebenenwechsel. Aber das ist heute nicht mehr opportun, Agile ist hip, weil man darf offiziell ständig seine Meinung ändern (aka angepasstes Anforderungs Management
Man muss SCRUM ja nur rückwärts lesen.
Und warum ist es so angesagt? Neben dem "hippem" agilen Vorgehen entbindet es die Führungsebene von lästigen strategischen Entscheidungen und deren Überwachung. Projekttermine gibt es ja keine mehr und ansonsten haben die Gilden versagt - sorry "ihre Abhängigkeiten nicht ausreichend kommuniziert".
Zuletzt bearbeitet:
Ich finde das ziemlich engstirnig. War selbst mal auf einem recht komplexen, agilen Projekt - wenn es gut gesteuert und moderiert wird, ist das Vorgehen mindestens ebenbürtig.