Forum: Wirtschaft
Medienbericht zu Crash-Flieger 737 Max: Boeing ließ Software in Indien programmieren
AP

Der Flugzeugbauer Boeing kommt nicht zur Ruhe: Laut dem Bericht einer US-Nachrichtenagentur hat der Konzern bei der Entwicklung des Problem-Jets 737 Max massiv ausgelagert, um Kosten zu sparen.

Seite 11 von 16
hman2 02.07.2019, 15:41
100.

Zitat von mundi
Dem Sparstift ist nicht die Software zum Opfer gefallen, es war die Fehlkonstruktion der 737Max. Hier wollte man mit wenig Aufwand, ein sparsames Flugzeug konstruieren. Entstanden ist eine zusammengeflickte Fehlkonstruktion.
Unfug. Die 737 Max ist flugtauglich.

Beitrag melden
yvowald@freenet.de 02.07.2019, 21:47
101. sicherheit immer an erster Stelle

Kosten sparen ist immer falsch, wenn es um die Sicherheit der Passagiere geht.
Hoffentlich folgt der europäische Flugzeugbauer Airbus nicht ebenfalls dem Trend, Software-Entwicklungen zu verlagern, um "Kosten zu sparen".
Wenn schon Aufträge weltweit vergeben werden, müssen die Ergebnisse dieser "Produkte" strengstens geprüft werden, um die Flugsicherheit zu gewährleisten.
Wieso haben die Boing-Vorstände dies noch immer nicht begriffen? Haben es die Airbus-Verantwortlichen wenigstens erkannt?

Beitrag melden
Besserwissser 02.07.2019, 22:04
102. Wo nehmen sie ihr "Halbwissen" her ?

Zitat von zweiblum66
oder was soll diese Berichterstattung uns sagen? Anders als viele "Unwissende" hier kommentieren, ist die Erstellung von Code ein Handwerk und das Konzept und die Planung Aufgabe von Software Architekten, Produktmanagement und Ingenieuren. Dieses Team prüft dann auch den erstellten Code und die Funtionalität. Ob die UI oder einzelne Code Fragmente aus Indoien, der Ukraine oder Deutschland kommen, spielt keine Rolle - das ist Standard wie bei Bauteilen auch... Das ein Großteil der elektronischen Bauelemete aus China kommen wird ist ja auch kein Problem.
Das mag schon so sein, das es bestimmte Programmieraufgaben als handwerkliche Tätigkeit angesehen werden, kann. Allerdings sind dies "Handwerker" oft Ingenieure wenn es nicht gerade um 100 Zeilen Programme geht, Insbesondere wenn es um Embedded- oder Echtzeit-SW geht, ist das was Software Architekten bereitstellen maximal ein Gerüst welches dann von den SW-Entwicklern mit fehlerfreien Code gefüllt wird (oder gefüllt werden soll), da vieles selbst von den Architekten so gar nicht vorhergesehen wird. Das ein Produktmanagement irgendetwas von SW Architektur versteht habe ich bisher noch nicht erlebt, da wird eher mit Terminen und Featurelisten jongliert. Und die 8 $ Handwerker sind wohl eher ein Lockvogelangebot, wenn klar ist das die Spezifikation unvollständig ist und dann mit Change Request teuer nachgearbeitet werden muss.

Beitrag melden
Xiang3025 03.07.2019, 00:17
103. Keine Fachleute hier?

Seltsam, dass es hier keine Fachleute zu geben scheint. Die Annahmen zur Softwareentwicklung hier im Forum gehen von falschen Prämissen aus. Als ob hier mit halbgaren Spezifikationen einfach mal eine kleine Butze in Indien beauftragt wird, dann spielt man das auf den Avionikcomputer ein und fertig ist der Lack. Das ist Bullshit. Da in der Luft bei einem Softwarefehler nicht einfach rechts rangefahren werden kann, ist hier das Zauberwort Redundanz. Ich habe vor über 10 Jahren nach DO178B programmiert - nicht avionics, aber schon hier war das Setup doppelte Redundanz im nichtkritischen Bereich - also zwei Computer, die sich gegenseitig überwachen und wo z.B. ein Computer übernimmt, wenn der andere hängen bleibt. Das funktioniert natürlich nur, wenn dieselbe Spezifikation von unterschiedlichen Teams entwickelt wird (sonst hängen ja beide Computer bei gleichen Eingabedaten mit demselben Problem). Die Software muss komplett vom high-Level Requirement bis zur letzten Zeile tracebar sein. Bei flugkritischen Systemen wird sicher mehr Redundanz verwendet. Das Ganze wird von FAA und EASA geprüft und zertifiziert. Kurz: Wer hier falsch spezifiziert, bekommt sein System zunächst gar nicht zum Laufen und schon gar nicht zertifiziert.
Der Kardinalfehler hier ist vielmehr dass ein immer weiter aufgeblähtes Produkt rein für Menschen nicht mehr handhabbar wird und deswegen Software zur Sicherheit eingesetzt wird. Generell kein großes Problem, nur das Ganze an nur einen Sensor zu hängen - keine Redundanz und auch keine Prüfmöglichkeit. Dazu noch - und das hält mich davon ab, freiwillig in eine 737 MAX zu steigen - selbst wenn jetzt alles by the Book umgesetzt wird, besteht immer noch das Problemchen, dass das Modell mit seinem verdrehten Schwerpunkt so instabil ist, dass der Pilot nicht mehr selbst übernehmen kann, wenn die Computer z.B. bei widersprüchlichen Daten das MCAS abschalten und dem Piloten die Kontrolle zurück geben. War bei dem über dem Atlantik abgestürzten Air France Flug ja ähnlich: Der Autopilot hat sich aufgrund der sich widersprechenden Sensordaten abgeschaltet und die Piloten wußten nicht, wie richtig zu reagieren ist. Bei der 737 ist es nur so, dass es echt dumm ist, wenn ein System, das Menschenunbeherrschbare Zustände verhindern soll, in eben so einem Moment die Kontrolle an den übergibt, den er gerade ersetzen soll.

Beitrag melden
Konstruktor 04.07.2019, 19:03
104. (1/2)

Zitat von Xiang3025
Seltsam, dass es hier keine Fachleute zu geben scheint. Die Annahmen zur Softwareentwicklung hier im Forum gehen von falschen Prämissen aus. Als ob hier mit halbgaren Spezifikationen einfach mal eine kleine Butze in Indien beauftragt wird, dann spielt man das auf den Avionikcomputer ein und fertig ist der Lack. Das ist Bullshit.
Darum geht's dabei auch gar nicht, denn da ist gar nicht MCAS das Thema, sondern offenbar andere Software-Entwicklungen.

Zitat von Xiang3025
Da in der Luft bei einem Softwarefehler nicht einfach rechts rangefahren werden kann, ist hier das Zauberwort Redundanz. Ich habe vor über 10 Jahren nach DO178B programmiert - nicht avionics, aber schon hier war das Setup doppelte Redundanz im nichtkritischen Bereich - also zwei Computer, die sich gegenseitig überwachen und wo z.B. ein Computer übernimmt, wenn der andere hängen bleibt. Das funktioniert natürlich nur, wenn dieselbe Spezifikation von unterschiedlichen Teams entwickelt wird (sonst hängen ja beide Computer bei gleichen Eingabedaten mit demselben Problem).
Wenn zwei nicht hinreichend kompetente Teams Mist programmieren, der es gerade noch so durch die Spec-Review schafft, aber eben doch nicht wirklich korrekt funktioniert, weil kaum eine Spec wirklich alle Programmierfehler verhindern kann, solange die Spec nicht bereits die komplette Implementierung enthält (und hoffentlich immer noch konsistent und korrekt ist!), dann nützt einem Redundanz auch nur wenig, wenn überhaupt.

Zitat von Xiang3025
Die Software muss komplett vom high-Level Requirement bis zur letzten Zeile tracebar sein. Bei flugkritischen Systemen wird sicher mehr Redundanz verwendet. Das Ganze wird von FAA und EASA geprüft und zertifiziert. Kurz: Wer hier falsch spezifiziert, bekommt sein System zunächst gar nicht zum Laufen und schon gar nicht zertifiziert.
Nur ist eine Spezifikation, die von der Aufsicht durchgewunken wird, noch lange keine Garantie für eine wirklich gut funktionierende Implemeniterung. Eine gute Spezifikation ist notwendig, aber alleine noch lange nicht hinreichend!

Beitrag melden
Konstruktor 04.07.2019, 19:04
105. (2/2)

Zitat von Xiang3025
Der Kardinalfehler hier ist vielmehr dass ein immer weiter aufgeblähtes Produkt rein für Menschen nicht mehr handhabbar wird und deswegen Software zur Sicherheit eingesetzt wird. Generell kein großes Problem, nur das Ganze an nur einen Sensor zu hängen - keine Redundanz und auch keine Prüfmöglichkeit. Dazu noch - und das hält mich davon ab, freiwillig in eine 737 MAX zu steigen - selbst wenn jetzt alles by the Book umgesetzt wird, besteht immer noch das Problemchen, dass das Modell mit seinem verdrehten Schwerpunkt so instabil ist, dass der Pilot nicht mehr selbst übernehmen kann, wenn die Computer z.B. bei widersprüchlichen Daten das MCAS abschalten und dem Piloten die Kontrolle zurück geben.
Grundsätzlich können die Piloten auch die 737MAX schon noch selbst beherrschen, aber in bestimmten kritischen Situationen haben sie dafür so wenig Sicherheitsspielraum, daß MCAS dort korrigierend eingreifen sollte, um das Risiko zu verringern.

Und gefährlich wird's eben dann, wenn MCAS bei nicht redundant gecheckten Sensordaten das Gegenteil tut und das Risiko massiv erhöht – dann sinken die Chancen der Piloten rapide.

Und das Hauptproblem war ja gerade, daß im Zuge der "Hauptsache billig"-Prioritäten aus dem Management 1. schlampig entwickelt wurde, 2. die FAA beide Augen zudrückte bzw. gleich die Kontolle Boeing überlassen hat und 3. die Priorität darauf lag, den Piloten MCAS effektiv zu verheimlichen, damit die Airlines keine zusätzliche Schulungskosten haben sollten und die Einführung der 737MAX für die Airlines damit besonder billig sein sollte (da sie deutlich weniger effizient ist als die A320neo, sollte die 737MAX über niedrige Preise und niedrige Kosten den Unterschied wieder aufholen).

Hat jetzt nicht so richtig toll geklappt, würde ich mal sagen...

Zitat von Xiang3025
War bei dem über dem Atlantik abgestürzten Air France Flug ja ähnlich: Der Autopilot hat sich aufgrund der sich widersprechenden Sensordaten abgeschaltet und die Piloten wußten nicht, wie richtig zu reagieren ist. Bei der 737 ist es nur so, dass es echt dumm ist, wenn ein System, das Menschenunbeherrschbare Zustände verhindern soll, in eben so einem Moment die Kontrolle an den übergibt, den er gerade ersetzen soll.
Nein, komplett anderer Fall.

Die A330 bei AF447 hat korrekt auf die unzuverlässig gewordenen Geschwindigkeitsinformationen reagiert (eben gerade auch getriggert durch die Erkennung unterschiedlicher, aber auch insgesamt unplausibler Meßwerte aus den 3 redundant eingesetzten Pitot-Sonden!), die Piloten hätten aber nach ganz normaler Vorschrift das Flugzeug trotzdem noch problemlos beherrschen können, indem sie einfach den für diesen Fall ganz normal vorgesehenen und auswendig gelernten Standard-Prozeduren gefolgt wären, haben aber stattdessen selbst durch eigene massive Fehlhandlungen das Flugzeug aktiv in die Katastrophe gesteuert.

Das ist beinahe das entgegengesetzte Szenario zu den 737MAX-Abstürzen!

Beitrag melden
Thomas Schröter 05.07.2019, 08:15
106. 9 Dollar ist schon Oberklasse

9 Dollar pro Stunde ist heute in Deutschland für ausländische Auftragsarbeiten eher schwer vermittelbar.
In Südamerika oder Afrika geht es deutlich günstiger.

Also hat Boeing da eigentlich schon noch Geld in die Hand genommen.

Ich würd mich an Stelle der Europäer in Sachen Boeing eher bedeckt halten.
Fly by Wire ist ja eher Spezialität von Airbus. Und Steuern von Airbus-Fliegern dank der dort verbauten Uralt-Prozessoren mit bekannten Hintertüren und Schatten-CPU'S vom Laptop des Fluggastes aus dem Passagierraum heraus gehört eher dort zu den Spezialitäten. Dazu gibt es einschlägige Studien.

Bodengebundene Oldtimer aus den 80igern ohne viel Elektronik drin ist was feines.

Beitrag melden
Spiegel-Wolfgang 05.07.2019, 09:33
107. Sparzwang? Ja, aber ....

Schlecht programmierte Software oder doch ein Fehler in der Systematik, aber wohl weniger in der Schulung der Piloten (?)! Letztere müssen zwar mit vielen Szenarien von Strömungsabrissen klar kommen, aber nicht damit rechnen dass sich ihr Flieger plötzlich völlig "konfus" verhält, ohne ersichtlichen Grund, die Systeme "normal" zu arbeiten scheinen. Das andere Piloten in selbiger Situation anders (besser) reagierten, mag auch etwas anderen Umständen geschuldet sein. Fakt ist aber dass ein ansich "normal" funktionierendes Flugzeug, technisch intaktes, niemals in so eine prekäre Situation kommen dürfte. Wer setzt sich noch freiwillig in so eine Bruchmaschine, auch wenn man die Piloten nun auf den Fehler und die richtige Reaktion darauf vorbereiten kann?

Beitrag melden
Spiegel-Wolfgang 05.07.2019, 09:39
108.

Zitat von mundi
Ein strömungstechnisch missglücktes Modell kann man nicht mit Computerprogrammen flugfähig machen. Egal ob das Programm in den USA, Indien oder sonst wo geschrieben wird.
Doch, die Vögel bleiben ohne computerunterstütze Eingriffe (Avionik) gar nicht mehr in der Luft, wären praktisch so flugfähig wie Hühner ;-))

Beitrag melden
Spiegel-Wolfgang 05.07.2019, 09:54
109.

Zitat von labellen
in erster Linie die Software, sondern die Tatsache, das bei einer speziellen Automatikfunktion nicht mehr händisch gegenzusteuern war und die Piloten nicht unterrichtet waren, wie diese Funktion abzuschalten gewesen wäre. Zudem konnte schon ein einzelner defekter Strömungsmesser (von denen mehrere an Bord sind) diese Automatik auslösen.
Eben, diese "Automatikfunktion" ist das eigentliche Problem, nur warum? Und da muss eigentlich der Fehler in der Software liegen, die bei Fehlwerten das nicht anzeigt und die falschen Rückschlüsse zieht, obwohl alle Systeme sonst technisch in Ordnung sind. Die Cockpit-Crew bekommt wohl nicht den Hinweis deswegen auf "manuell" umzuschalten und wird dann schnell mit einem möglichen Strömungsabriss konfrontiert, hat wohl wenig Zeit die richtigen Maßnahmen zu ergreifen. Mal gespannt was da von der FAA, zu den Abstürzen, noch ans Tageslicht kommt.

Beitrag melden
Seite 11 von 16
Diskussion geschlossen - lesen Sie die Beiträge!