10.03.19 Ethiopian AL B737-MAX8 abgestürzt

[Michael aus G.]

Ich gehe daher weiterhin davon aus, dass zumindest die Architektur der Software nicht ausgelagert wird, sondern eher nahe bei den anderen Luftfahrt-Entwicklern von Boeing entsteht.

Da gehts du von falschen Annahmen aus. Früher haben die das so gemacht, seit 2004 sieht das wohl anders aus...

The typical jetliner has millions of parts -- and millions of lines of code -- and Boeing has long turned over large portions of the work to suppliers who follow its detailed design blueprints.

Starting with the 787 Dreamliner, launched in 2004, it sought to increase profits by instead providing high-level specifications and then asking suppliers to design more parts themselves. The thinking was “they’re the experts, you see, and they will take care of all of this stuff for us,” said Frank McCormick, a former Boeing flight-controls software engineer who later worked as a consultant to regulators and manufacturers. “This was just nonsense.”

 

[LFeldTom]

Da gehts du von falschen Annahmen aus.

Danke für die Korrektur. Immerhin gehen der Zitierte und ich gedanklich den gleichen Weg.

 

[_Michael]

Da die Menge an Software-Code, der in einem Flugzeug steckt, beständig und deutlich wächst, haben die Flugzeug-Hersteller gar keine andere Wahl als auch Teile der Software-Entwicklung an externe Partner zu vergeben. Und sie geben auch den Kostendruck mit, was dann dazu führt, dass der Outsourcing-Anteil steigen muss, weil es vor Ort keiner mehr für da Geld produzieren kann, selbst wenn denn Ressourcen vorhanden wären, was meist nicht der Fall ist.

Ich glaube nicht, dass das stimmt. Die grossen Namen im Software-Bereich haben riesige Entwicklungszentren an extrem teuren Standorten, z.B. im Silicon Valley oder hier in Zürich. Auch die Firma für die ich gerade arbeite entwickelt grösstenteils in Kalifornien, sowie an einigen (teuren) Aussenstandorten wie Zürich. Von kostengetriebenem Outsourcing ist da nichts zu spüren. Das funktioniert, weil der wirtschaftliche Druck nicht bei den Entwicklungskosten liegt, sondern z.B. bei den Marktanteilen oder den Betriebskosten der Rechenzentren. Wenn man sich da nur um Zehntelprozent verbessert sind die Entwicklungskosten dafür praktisch irrelevant. Ähnlich sehe ich es auch bei Systemen wie einem MCAS. Das aufwendige hier ist Forschung (wie das Ding überhaupt funktionieren muss), dann Spezifikation, Integration, Tests, Zertifizierung. Das eigentliche, outsourcbare technische Entwickeln des Geräts bzw. der Softwarekomponente ist dann schon fast der kleinste Teil.

Ich glaube absolut, dass Inder oder Chinesen so ein Gerät genau so 1A bauen können wie amerikanische oder europäische Ingenieure, aber ich frage mich, ob es aus Sicht der Gesamtfirma überhaupt relevante Kosteneinsparungen gibt oder ob sowas eher ein Stunt eines mittleren Managers ist, der in seinem Sub-Bereich spektakuläre Kosteneinsparungen aufweisen will, und dabei eine grosse Portion Risiko und Zusatzkosten in andere Firmenteile "outsourct".

 

[Schorsch]

Europäische und US-amerikanische Software-Entwickler sind zwar noch in ein paar Bereichen besser, besonders bei Produkten, die in eher alten Programmiersprachen geschrieben sind, aber wer noch glaubt, dass die Software in der Luft- und Raumfahrt höherwertig ist, als die Software mit denen täglich zig-Milliarden an Börsen oder in der Produktion bewegt werden, der sollte vielleicht mal aus seinen schillernden Blubberblase rauskommen und sich umschauen.

Die Software der Luftfahrt-Branche ist das Plattdeutsch der IT, geschrieben in Fraktur-Schrift.
Welche "App" wird heute wohl in Ada geschrieben sein?
Ada (Programmiersprache) – Wikipedia

 

[Stovebolt]

Ich glaube absolut, dass Inder oder Chinesen so ein Gerät genau so 1A bauen können wie amerikanische oder europäische Ingenieure, aber ich frage mich, ob es aus Sicht der Gesamtfirma überhaupt relevante Kosteneinsparungen gibt oder ob sowas eher ein Stunt eines mittleren Managers ist, der in seinem Sub-Bereich spektakuläre Kosteneinsparungen aufweisen will, und dabei eine grosse Portion Risiko und Zusatzkosten in andere Firmenteile "outsourct".

Meine Erfahrung mit chinesischen und indischen Lieferanten:
Wenn man die Lieferanten von diesen Märkten wählt, die die gleiche Qualität liefern sollen wie ein europäischer Lieferant z.b. aus Polen, dann hat man kein signifikantes Einsparpotential mehr.
Inder und Chinesen können auch Flugzeuge und Flugzeugträger bauen.Ich bin mir aber recht sicher, dass die Fachleute, die diese Dinge bauen, sich lohntechnisch nicht auf dem Niveau der Hinterhofbuden bewegen.
Bei unseren Indern sind auch unter 10 Dollar/h angekommen und 2/3 der Arbeitsleistung konnte man dafür in die Tonne kloppen.
Gruß!

 

[mcnoch]

Es gibt natürlich eine Vielzahl von Gründen, warum soetwas gut oder schlecht laufen kann, aber meist sind die Ursachen beim Auftraggeber in Europa oder den USA zu suchen. Die Nachlässigkeit mit dem z.B. der Personalbeschaffungsprozess bei vielen Firmen abläuft ist echt überraschend und schlechte Erfahrungen dann nicht verwunderlich.
Aber am Ende ist es auch gar nicht so wichtig, wo es programmiert wurde, denn für die Qualitätssicherung viel wichtiger sind die anschließenden Funktions- und Abnahmetests. Unzureichende Tests gehen ja auf meist Ursachen zurück: a) Man wollte (meist Zeit) sparen oder b) man hat die Komplexität dessen, was die SOftware dort leisten soll nicht vollständig durchstiegen. Zeitdruck mag hier ein Grund gewesen sein, aber ich werde irgendwie nicht das Gefühl los, dass gerade letzteres bei Boeing auch der Fall war, so man nicht von Vorsatz ausgehen will, was ich dann doch nicht glaube.

 

[LFeldTom]

Vielleicht sollten wir noch kurz für die, die nicht so nahe an der Materie dran sind kurz hinzufügen, dass Entwicklung und Programmierung keine Identitäten sind.
Ich würde immer noch vermuten, dass die Funktionalität des MCAS bei Boeing entwickelt und nur die anschließende Implementierung nach Indien vergeben wurde.

PS:
Da es angesprochen wurde: Wird jenseits der militärischen Ebene ADA intensiv verwendet ? Ich hab Avionik immer in C++ realisieren dürfen ( was für die Jüngeren aber auch gefühlte Steinzeit ist ).

 

[_Michael]

Wenn ich es richtig verstanden habe, so lag die Fehlfunktion ja nicht bei MCAS an sich, sondern an fatalem Zusammenspiel mit dem Gesamtsystem. Da können wir so lange über gutes und schlechtes Outsourcing diskutieren, doch der Hund ist gar nicht dort begraben, sondern im nicht zu Ende gedachten Gesamtsystem.

Ich denke, hier zeigt sich auch ein Problem des Outsourcing, das man erst dann versteht, wenn man selbst mal als ausführender Entwickler gearbeitet hat: Man kann noch so lange konzeptieren und spezifizieren, noch so viele weise Sätze aus dem IT-Management kennen, ABER um ein System wirklich tiefgehend zu verstehen, muss man es eigentlich selbst implementiert und zum Laufen gebracht haben. Oft zeigen sich erst dann die Lücken und Probleme des Konzepts. Auf Firmenebene heisst das, dass eine enge Verzahnung zwischen Spezifikation und Implementierung das Risiko deutlich verringert, ein nicht taugliches Gesamtkonzept zu entwickeln.

 

[Sens]

Die Software der Luftfahrt-Branche ist das Plattdeutsch der IT, geschrieben in Fraktur-Schrift.
Welche "App" wird heute wohl in Ada geschrieben sein?
Ada (Programmiersprache) – Wikipedia

Das kriegen die in Asien problemlos hin, wenn sie die Compiler-Fehler ausmerzen. Eine ganz andere Sache ist das mit den Logik-Fehlern, da zählt dann die Berufserfahrung im Fachgebiet. Fallen die bei der Zertifizierung in den USA nicht auf, dann hat man ein Problem.

 

[_Michael]

Das kriegen die in Asien problemlos hin, wenn sie die Compiler-Fehler ausmerzen. Eine ganz andere Sache ist das mit den Logik-Fehlern, da zählt dann die Berufserfahrung im Fachgebiet.

Kannst du das etwas ausführen?

 

[Del Sönkos]

Kannst du das etwas ausführen?

Bitte nicht...

 

[Lime]

Junge Junge...was hier so an Fachwissen vertreten ist...

Wer den Code schreibt ist doch eigentlich erstmal zweitrangig, solange ein definierter Coding-Standard eingehalten wird. Potentielle Fehler/Bugs werden üblicherweise in Rahmen von V&V-Tests entdeckt. Fraglich wäre für mich eher, wer denn die Testspec bzw. Testcases definiert und geschrieben hat. Das könnte sowohl bei Boeing als auch bei einem Supplier (Honeywell?) gemacht worden sein.

 

[macfly]

Laut Bloomberg beziehen sich die Probleme, die kürzlich im Simulator entdeckt wurden, auf die manuelle elektrische Trimmung: in Notfällen kann diese nur verzögert reagieren, wenn ein Computer überlastet ist:
Bloomberg - Are you a robot?
"A pilot attempted that maneuver during the recent simulator test and found that because of the computer issue, the manual electric trim switches didn’t immediately respond."

Bei der 737MAX ist es wohl tatsächlich so, dass die manuelle, elektrische (!) Ansteuerung der Trimmung nicht funktioniert, so lange der Computer noch automatisch trimmt - und so lange der Computer nicht "bemerkt" hat, dass ein Pilot eine manuelle Trimmtaste gedrückt hat. Auf pprune gibt es einige Posts von Schaltbildern. Nicht ganz einfach zu durchblicken. Offensichtlich ist aber auch die elektrische Ansteuerung der Trimmung bei 737MAX in Vergleich zu 737NG und Classic deutlich verändert.

(Natürlich bleibt den Piloten die Option, die Cutout-Switches zu betätigen und komplett manuell (ohne Elektrik) zu trimmen. Aber, naja, dass ist ja bekanntlich auch nicht so einfach bei der 737...)

Nach den Abstürzen und Veröffentlichung der FDR Daten gab es ja teilweise Kritik an den Piloten, dass sie, bevor die Cutout Switches benutzt wurden, jeweils nur relativ kurze elektrische Trimm-Eingaben gemacht haben, während die Trimmeingaben des MCAS deutlich länger waren. Wenn die aktuellen Berichte stimmen, muss das auch in ganz anderem Licht betrachtet werden...

Zudem soll die EASA eine Liste an FAA und Boeing geschickt haben, deren Punkte vor einer Wiederzulassung durch EASA behoben sein müssen. Dort soll zumindest ein neues Problem enthalten sein: angeblich soll sich der Autopilot in manchen Notfällen nicht abschalten:
Bloomberg - Are you a robot?

Das wird wohl dauern, bis die MAX wieder fliegt...

 

[AMeyer76]

EASA entdeckt Fehlfunktion im Autopiloten
Ich bleibe dabei. Ein neues Flugzeug als B737 Max Nachfolger zu entwickeln, dürfte schneller gehen. Man muss ja keine Revolution entwerfen.

 

[lutz_manne]

EASA entdeckt Fehlfunktion im Autopiloten
Ich bleibe dabei. Ein neues Flugzeug als B737 Max Nachfolger zu entwickeln, dürfte schneller gehen. Man muss ja keine Revolution entwerfen.

Definiere bitte "schneller gehen" in Jahren.

 

[Ta152]

EASA entdeckt Fehlfunktion im Autopiloten
Ich bleibe dabei. Ein neues Flugzeug als B737 Max Nachfolger zu entwickeln, dürfte schneller gehen. Man muss ja keine Revolution entwerfen.

hmm, nach 737 MAX eine 737 Revolution, arbeitest du im Marketing?

Schneller würde es wohl eher nicht werden, denn auch da würden die Zulassungsbehörden genau hinschauen.

Aber Boeing wird wohl langsamm darüber nachdenken zu versuchen die NG Produktionslinien länger laufen zu lassen und zu versuchen MAX Bestellungen auf NG umzuswitchen (mit deutlichem Preisnachlass)

 

[Rhönlerche]

Es gibt keine NG-Produktionslinien mehr. Die P-8 ist auch nicht dasselbe.

 

[Lime]

EASA entdeckt Fehlfunktion im Autopiloten
Ich bleibe dabei. Ein neues Flugzeug als B737 Max Nachfolger zu entwickeln, dürfte schneller gehen. Man muss ja keine Revolution entwerfen.

...schon mal in der Luftfahrtentwicklung gearbeitet...?

 

[Whisky Papa]

Es gibt keine NG-Produktionslinien mehr. Die P-8 ist auch nicht dasselbe.

Aber wenn Airbus es schafft, aus A380-Linien A320-Linien zu machen, dann sollte es (bei aller nationalstischer Häme) Boeing doch gelingen, die alten NG-Linien wieder aufzubauen. Oder wurde alles dem Erdboden gleichgemacht?

 

[_Michael]

Aber wenn Airbus es schafft, aus A380-Linien A320-Linien zu machen, dann sollte es (bei aller nationalstischer Häme) Boeing doch gelingen, die alten NG-Linien wieder aufzubauen. Oder wurde alles dem Erdboden gleichgemacht?

Warum sollte man das? Die Probleme betreffen ja nicht die Struktur und Mechanik des Flugzeugs, sondern Teile der Avionik. Selbst wenn man diese von A bis Z neu entwickeln müsste, würde sich in der Produktion kaum etwas ändern. Auf jeden Fall gäbe es null Grund, das Modell und seine Produktionslinie einzustampfen.