Zum Inhalt springen
airliners.de

737 MAX Grounding Thread


BÄHM!

Empfohlene Beiträge

vor 3 Stunden schrieb Tschentelmän:

Allerdings würde ich das nicht nur auf Boeing beschränken -  nochmal genau hinschauen sollte auch für Airbus, Embraer usw. gelten. Also alle. 

bezieht sich auf meinen letzten Post.

Bearbeitet von FKB
Link zu diesem Kommentar
Auf anderen Seiten teilen

Komplett am Thema vorbei. Es geht hier nicht um irgendeine Art der Bestrafung oder Haftung sondern darum ergebnisoffen zu überprüfen ob es sich um einen Einzelfall handelt oder nicht.

Ein ganz normaler Vorgang, den es in jedem Bereich gibt, und der soll ausgerechnet bei sicherheitsrelevanten Problemen nicht stattfinden?

Link zu diesem Kommentar
Auf anderen Seiten teilen

Exakt!

Die Behörden haben offensichtlich geschlafen... Boeing hat den technischen Bogen überspannt und zudem die Schwäche der Behörden ausgenutzt... Das Vertrauen ist erstmal dahin - sowohl zu Boeing als auch in die frühere Arbeit der Behörden. Nun MUSS geprüft werden, ob weitere Fälle vorhanden sind..  die Behörden können es auf Anhieb nicht sagen - weil sie offenbar selbst nicht genau wissen, was sie womöglich alles übersehen haben... 

 

Keine Sippenhaft - dafür Safety First!

Bearbeitet von Tschentelmän
Link zu diesem Kommentar
Auf anderen Seiten teilen

Am 30.6.2019 um 17:36 schrieb Tschentelmän:

Ein weiterer Bericht... 

 

Demzufolge soll Boeing einen Indischen Dienstleister beauftragt haben, Teile der Software-Progammierung durchzuführen. Einschließlich niedriger Personalkosten... 

 

Wenn der Bericht im Kern stimmen sollte (ja - steht offenbar auch einiges an Bullshit drin - und alles vom hören-sagen...) - Indische Programmierer haben sicherlich einiges auf dem Kasten... Aber ein dermaßen komplexes Software-Thema extern und tausende Kilometer entfernt in einem anderen Land bearbeiten zu lassen - inklusive einer fremden Muttersprache (auch wenn vermutlich jeder Englisch kann) plus Zeitdruck - das zeigt einmal mehr wie mangelhaft Boeing die Sache damals angegangen ist - Profit vor Sicherheit...

 

Also als jemand, der seit 13 Jahren mit indischen Softwareentwicklern zusammen arbeitet kann ich sagen, dass Vermutungen in dieser Richtung nicht standhaft sind. 

 

Der Focus-Artikel ist ja schon in der Form falsch, dass von einer fehlerhaften Software gesprochen wird. Das klingt so, als ob die Software nicht das gemacht hätte, was sie hätte tun sollen und dafür ev. unfähige Inder verantwortlich seien. 

 

In Wirklichkeit hat die MCAS-Software aber exakt das gemacht, was sie machen sollte, nur war das nicht sinnvoll. D.h. das Problem waren die Leute, welche die Anforderungen an die Software geschrieben und abgenickt haben (USA?) und nicht diejenigen, die diese Anforderungen in Software umgesetzt haben. 

 

Bearbeitet von JeZe
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 5 Stunden schrieb JeZe:

Der Focus-Artikel ist ja schon in der Form falsch, dass von einer fehlerhaften Software gesprochen wird. Das klingt so, als ob die Software nicht das gemacht hätte, was sie hätte tun sollen und dafür ev. unfähige Inder verantwortlich seien. 

 

Das haben wir neulich bereits intensiv diskutiert... Auch Airliners.de hatte etwas dazu geschrieben - anderer Wortlaut aber im Kern sonst identisch. Niemand hat die indischen Programmierer direkt angegriffen - aus meiner Sicht auch Focus nicht. Im Mittelpunkt steht einzig und allein die damalige Geiz-ist-Geil-Mentalität von Boeing. Teure Spezialisten in der eigenen Firma rauswerfen und stattdessen in Billiglohnländer verlagern. Mit der rosaroten Brille - alles kein Problem, sind ja nur ein paar Tastendrücke....

 

vor 5 Stunden schrieb JeZe:

In Wirklichkeit hat die MCAS-Software aber exakt das gemacht, was sie machen sollte, nur war das nicht sinnvoll. D.h. das Problem waren die Leute, welche die Anforderungen an die Software geschrieben und abgenickt haben (USA?) und nicht diejenigen, die diese Anforderungen in Software umgesetzt haben.

 

Genau das war das Problem. Wurde in der Presse auch hervorgehoben. Sogenanntes Shit-in-Shit-out-Prinzip. Wenn Boeing ein paar Papierfetzen mit gekritzelten Anforderungen nach Indien schickt, brauchen sie sich nicht wundern, dass die Programmierer genau das geliefert haben. Ich habe selbst auch schon erlebt, wie schwierig und fehleranfällig es werden kann, komplexe Sachverhalte von externen IT-Dienstleistern anfertigen zu lassen. Es steht und fällt hauptsächlich mit der Qualität des Pflichtenheftes. Wenn ich mich arrogant und selbstverliebt hinstelle mit der Erwartungshaltung hinstelle, die IT-Firma muss doch verstehen, was ich will, bin ich völlig auf den falschen Gleis. Selbst wenn der IT-Fachmann beim Dienstleister sein Schlafzimmer mit Siegerurkunden von Programmier-Wettbewerben tapeziert hat - Trotzdem! Scheiss-Vorgaben = Scheiss-Ergebnis!

Bearbeitet von Tschentelmän
Link zu diesem Kommentar
Auf anderen Seiten teilen

Schwer zu sagen...

 

Ein langjährig erfahrener direkt bei Boeing beschäftigter Programmierer hätte vielleicht etwas tiefer in der fachlichen Materie gesteckt und hätte gewisse Logiken aufgrund seiner bestehenden Expertise selbst erkannt - oder er hätte mal eben per Haustelefon den Johnny aus der Entwicklung angerufen und die Unklarheiten direkt mit ihm diskutiert... Natürlich wäre das auch nicht so ganz free & easy gewesen, aber wenn die Fachleute im gleichen Unternehmen und im selben Land sitzen, kann das schon vieles vereinfachen...

 

Problematisch wird es tendenziell, sobald externe Dienstleister im Spiel sind. Jede zusätzliche Stunde Zeitverschiebung und unterschiedliche Muttersprachen vergrößern das Risiko für Komplikationen...

Link zu diesem Kommentar
Auf anderen Seiten teilen

32 minutes ago, Tschentelmän said:

Problematisch wird es tendenziell, sobald externe Dienstleister im Spiel sind. Jede zusätzliche Stunde Zeitverschiebung und unterschiedliche Muttersprachen vergrößern das Risiko für Komplikationen...

 

Entschuldigung, so etwas ist in vielen multinationalen/globalen Konzernen seit Jahren/Jahrzehnten Standard, sogar inhouse. ich kann keine Neuigkeit erkennen. Dann würde es Airbus gar nicht geben; okay, die Zeitverschiebung hielt sich vor dem USA- und China-Engagement in Grenzen...

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 40 Minuten schrieb Tschentelmän:

Ein langjährig erfahrener direkt bei Boeing beschäftigter Programmierer hätte vielleicht etwas tiefer in der fachlichen Materie gesteckt und hätte gewisse Logiken aufgrund seiner bestehenden Expertise selbst erkannt - oder er hätte mal eben per Haustelefon den Johnny aus der Entwicklung angerufen und die Unklarheiten direkt mit ihm diskutiert... Natürlich wäre das auch nicht so ganz free & easy gewesen, aber wenn die Fachleute im gleichen Unternehmen und im selben Land sitzen, kann das schon vieles vereinfachen...

 

Theoretisch sollte auch das Anforderungsprofil / Lastenheft so genau festgelegt sein, dass es egal ist, wo und von wem die Software im Endeffekt programmiert wird.

Und später sollte bei Tests auffallen, dass das Programm nicht auf jede Situation adäquat reagiert.

 

Hätte nur einer von beiden Punkten funktioniert, wäre die Programmierung außer Haus gar kein Problem gewesen.

 

 

vor 1 Minute schrieb medion:

Entschuldigung, so etwas ist in vielen multinationalen/globalen Konzernen seit Jahren/Jahrzehnten Standard, sogar inhouse. ich kann keine Neuigkeit erkennen. Dann würde es Airbus gar nicht geben; okay, die Zeitverschiebung hielt sich vor dem USA- und China-Engagement in Grenzen...

 

Und auch hier knallt es ab und an. Ich erinnere an die Verkabelungsprobleme bei der A380, die daran lagen, dass an unterschiedlichen Standorten unterschiedliche Softfwareversionen verwendet wurden und daher die Kabellängen variierten...

 

 

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Schon klar - Globalisierung in allen Facetten. Ich bezog die Aussage jedoch auf ungünstige Begleitumstände wie Zeitdruck und stümperhaft erstellte Detail-Vorgaben... Je mehr räumliche Distanz und Zeitdifferenz - umso schwieriger sind dann nachträgliche Klärungen - inklusive Zeitdruck nochmals eine blödere Situation.

 

Wenn das System gut eingespielt ist, kann die IT-Abteilung auch auf dem Mond sitzen.... Setzt jedoch immer voraus, dass die gesamte Organisation gut aufgestellt ist und jeder genau weiß, was zu tun ist...

Bearbeitet von Tschentelmän
Link zu diesem Kommentar
Auf anderen Seiten teilen

Am 9.7.2019 um 21:38 schrieb Tschentelmän:

 

Genau das war das Problem. Wurde in der Presse auch hervorgehoben. Sogenanntes Shit-in-Shit-out-Prinzip. Wenn Boeing ein paar Papierfetzen mit gekritzelten Anforderungen nach Indien schickt, brauchen sie sich nicht wundern, dass die Programmierer genau das geliefert haben. Ich habe selbst auch schon erlebt, wie schwierig und fehleranfällig es werden kann, komplexe Sachverhalte von externen IT-Dienstleistern anfertigen zu lassen. Es steht und fällt hauptsächlich mit der Qualität des Pflichtenheftes. Wenn ich mich arrogant und selbstverliebt hinstelle mit der Erwartungshaltung hinstelle, die IT-Firma muss doch verstehen, was ich will, bin ich völlig auf den falschen Gleis. Selbst wenn der IT-Fachmann beim Dienstleister sein Schlafzimmer mit Siegerurkunden von Programmier-Wettbewerben tapeziert hat - Trotzdem! Scheiss-Vorgaben = Scheiss-Ergebnis!

 

Du argumentierst aber immer noch so, als ob die Anforderungen durch Zufall bzw. schlechte Kommunikation entstanden wären. Das ist völlig ausgeschlossen. 

 

Die Tatsache, dass 

 

-für MCAS nur ein Sensor ausgewertet wurde

-das System in für den Piloten tückischen Zeitintervallen agierte

-es extreme Winkel erreichen konnte 

-es generell nicht ohne weiteres deaktiviert werden konnte

-etc.

 

müssen willentlich und aktiv getroffen worden sein und genau so sind sie auch umgesetzt worden. D.h. Boeing war nicht überrascht, dass das Flugzeug sich verhalten hat, wie es sich verhalten hat, sondern vielmehr darüber, dass dieses geplante Verhalten nicht geeignet dazu war, die Maschine bei falschen Sensor-Inputs problemlos in der Luft zu halten. 

 

BTW: es ist auch nicht so, dass die Software in irgendwelchen Wellblechhütten in Indien zusammengeklöppelt werden würde. Das sind hochmoderne Rechenzentren, siehe z.B. hier:

https://farm4.static.flickr.com/3558/3350061741_c47bce3dc7_o.jpg

 

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 10 Minuten schrieb JeZe:

Du argumentierst aber immer noch so, als ob die Anforderungen durch Zufall bzw. schlechte Kommunikation entstanden wären. Das ist völlig ausgeschlossen. 

 

In den Presseberichten kam es zumindest so rüber als hätte es hierbei einige Probleme gegeben.

 

Ist aber auch eher zweitrangig - weil es war eben hauptsächlich wichtig hervorzuheben, dass die indischen Programmierer offenbar genau das umsetzten, was vorgegebenen war und die Verantwortung für das gesamte Produkt einzig und alleine bei Boeing lag und liegt... 

.... Plus natürlich den Zertifizierungsbehörden..

 

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 57 Minuten schrieb BobbyFan:

Nein, es kann "ohne weiteres" durch manuelles (elektrisches) trimmen gestoppt und durch einen der zwei CutOut Switche "ohne weiteres" deaktiviert werden.

War das den Crews bewusst?

Anscheinend ja nicht, sonst gäbe es 346 Tote weniger und die ganzen Pilotenverbände würden auch "stillhalten" oder sogar aktives Bashing betreiben nach dem Motto "Typisch asiatischer Billigheimer" bzw. "Typisch Afrika".

Stattdessen stärken alle Verbände weltweit den Crews den Rücken und zeigen mit dem Finger seit dem Ethiopian-Crash auf Boeing, nicht ganz unbegründet wie inzwischen klar ist!

 

Ich würde mal sagen, was für dich als Techniker logisch und einfach ist war für Crews "die große Unbekannte" nicht nur bei Lion und Ethiopian sondern allgemein!

Bearbeitet von ATN340
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 19 Stunden schrieb BobbyFan:

Nein, es kann "ohne weiteres" durch manuelles (elektrisches) trimmen gestoppt und durch einen der zwei CutOut Switche "ohne weiteres" deaktiviert werden.

 

Das ist aber nicht "ohne weiteres". "Ohne weiteres" wäre eine Deaktivierung von MCAS ohne dafür andere Funktionalität deaktivieren zu müssen. 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Erstelle ein Benutzerkonto oder melde Dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde Dich hier an.

Jetzt anmelden
×
×
  • Neu erstellen...