29.10.2018 | Lion Air B737-800 Max | PK-LQP | Jakarta | Absturz in die Java See

[IFixPlanes]

vor 24 Minuten schrieb cosy:

..und warum vergleichen diebnicht die Airdata/AoA mit der Trägheitsnavigationsdaten? die Technologie ist heute ja so fortgeschritten, dass sie über die Zeitspanne von zig Sekunden unglaublich genau Fluglage plus dyn. Werte (VSI, CAS..) sehr genau ermittel kann. Solche Werte mūssten doch fūr die Beurteilung (des Vertrauensintervalls) der Airdata hinzugezogen werden und diese ggf ersetzen.

Mein EFIS in meiner Hobbykutsche rechnet 10x / sec. die Integrität zwischen den Daten aus

*Pitot

* AHRS

* Magn. Track

* GPS

und eliminiert phys. unmõgliche Ergebnisse aufgr. von 'Totalenergie'-Modellen

Lass die armen Idioten bei Boeing nicht dumm sterben:

Kontaktdaten

 

[cosy]

5 hours ago, IFixPlanes said:

Lass die armen Idioten bei Boeing nicht dumm sterben:

Kontaktdaten

das ist nicht mein Slang. Aber ich hab auch was für Dich:

www.spiritueller-tourismus.de/selbstfindung/Anmeldung

{ironie off}

[Hunter58]

Moment, Boeing hat ein AD publiziert? Nicht eher ein Emergency SB das dann von der FAA zum AD gemacht wird?

 

Also, soweit ich MACS verstehe geht es darum bei high speed aus einer high-AOA situation herauszukommen und das Verhalten and die NG anzupassen. Nicht mehr...

[Falconer]

1 hour ago, Hunter58 said:

Moment, Boeing hat ein AD publiziert? Nicht eher ein Emergency SB das dann von der FAA zum AD gemacht wird?

 

Also, soweit ich MACS verstehe geht es darum bei high speed aus einer high-AOA situation herauszukommen und das Verhalten and die NG anzupassen. Nicht mehr...

 

Naja..die FAA hat ein Emergency AD publiziert...kommt nicht so oft vor..wird auch nicht unbedingt aus jedem Mandatory SB ein normales AD, geschweige denn ein EAD..das entscheidet doch die Behörde..

 

http://rgl.faa.gov/Regulatory_and_Guidance_Library/rgad.nsf/0/fe8237743be9b8968625835b004fc051/$FILE/2018-23-51_Correction.pdf

 

Zum MCAS selbst?..Gute Frage, warum genau das System offenbar notwendig ist..?..weiss bis jetzt wahrscheinlich nur der Hersteller..und anzunehmen auch die FAA..

 

https://theaircurrent.com/aviation-safety/what-is-the-boeing-737-max-maneuvering-characteristics-augmentation-system-mcas-jt610/

 

warum man das neue MCAS System ganz offenbar nicht ausreichend, respektive gar nicht an die Betreiber bei Einführung des Modells kommuniziert hat, das weiss wahrscheinlich bis heute nur Boeing..da gab es ja mehrere (inoffizielle) Stellungnahmen und Begründungen von Boeing Leuten, die aber, zumindest von American und Southwest Pilotenvertretern, nicht sehr verständnisvoll aufgenommen worden sind..

 

weiters scheint es jetzt darum zu gehen das System zumindest vorläufig softwaremässig so zu modifizieren für die Zukunft, dass nicht ein einziger Sensorfehler  das System zur falschen Zeit auslösen kann..eben weil ein schnell ( in die falsche Richtung) laufender Stab Trim eher was sehr Heikles sein kann..

 

so verstehe ich die Sache bis jetzt..

 

ich nehme an Anfang des neuen Jahres wird man mehr erfahren, was jetzt wirklich Sache war und sein wird..

 

und dann kommt noch dazu, falls das System zumindest als "contributing factor" für den LION Air Unfall bei der Unfalluntersuchung gelistet werden wird, und darauf, würde ich meinen, deutet Einiges hin, ob dann noch zusätzliche Modifikationen von der FAA, als Zulassungsbehörde des Herstellerlandes, vorgeschrieben werden..? ( historisch im Rückblick war das bei ähnlich gelagerten Fällen bis jetzt aber fast immer so..)

 

Gerd

 

 

Bearbeitet 17. Dezember 2018 von Falconer

[teetwoten]

Diesem Thread zufolge muss es sich bei diesem MCAS um ein Allerweltssystem handeln: Was das alles kann, für was alles es vorgesehen wurde, wo überall es eingreift, wie es die Zulassung erst möglich machte, wie es still im Hintergrund (sozusagen incognito) ganz unauffällig seine Dienste verrichtet! Welch technologischer Wurf... 

 

Stefan

 

[cosy]

4 hours ago, teetwoten said:

MCAS um ein Allerweltssystem handeln: Was das alles kann, für was alles es vorgesehen wurde, wo überall es eingreift, wie es die Zulassung erst möglich machte, wie es still im Hintergrund (sozusagen incognito) ganz unauffällig seine Dienste verrichtet! Welch technologischer Wurf...  

 

Steuerungssysteme und damit direkt verbundene Subsysteme müssen für die Zulassung formal getestet werden, will heissen, die verschiedenen weit verbreiteten nicht formalen SW-Tests (oft automatisiert) reichen für den Nachweis der Robustheit nicht. Formale Tests basieren auf math. beweisbaren theoremen der Fehlerfreiheit und sind kostspielig.

Es wäre interessant zu wissen, wieviele Codzeilen MCAS umfasst. Ein 08-15 Programm gilt als 'fehlerfrei', wenn es die nicht-formalen Tests brstanden hat. Metriken der OSF nach ISO bezeichnen die verbleibende Fehlerhäuffigkeit als kleiner als 1Fehler pro 2000 Codezeilen.

Das Betriebssystem OS-X ist so ein Programm, wonach (theor.) im 100 Mio. Zeilen grossen Code bis zu 50'000 Fehler schlummern dürften.

Die vorgelegten Definitionen und die Results der formalen Tests für die Zulassung des  MCAS wären sehr interessant. Ausserdem sind Tests unter simulierten oder realen Umweltbedingungen erforderlich. Meist wird simuliert, und danach werden ausgewählte Parameter erflogen und die Resultate anschliessend auf den Datenraum hochgerechnet. Diese Berechnungen und besonders die selektive Wahl der in realen Tests erflogenen Szenarios wären matchentscheidend für die Beurteilung der Güte der vorgelegten formalen Verifikation des MCAS.

[Falconer]

16 hours ago, cosy said:

Steuerungssysteme und damit direkt verbundene Subsysteme müssen für die Zulassung formal getestet werden, will heissen, die verschiedenen weit verbreiteten nicht formalen SW-Tests (oft automatisiert) reichen für den Nachweis der Robustheit nicht. Formale Tests basieren auf math. beweisbaren theoremen der Fehlerfreiheit und sind kostspielig.

Es wäre interessant zu wissen, wieviele Codzeilen MCAS umfasst. Ein 08-15 Programm gilt als 'fehlerfrei', wenn es die nicht-formalen Tests brstanden hat. Metriken der OSF nach ISO bezeichnen die verbleibende Fehlerhäuffigkeit als kleiner als 1Fehler pro 2000 Codezeilen.

Das Betriebssystem OS-X ist so ein Programm, wonach (theor.) im 100 Mio. Zeilen grossen Code bis zu 50'000 Fehler schlummern dürften.

Die vorgelegten Definitionen und die Results der formalen Tests für die Zulassung des  MCAS wären sehr interessant. Ausserdem sind Tests unter simulierten oder realen Umweltbedingungen erforderlich. Meist wird simuliert, und danach werden ausgewählte Parameter erflogen und die Resultate anschliessend auf den Datenraum hochgerechnet. Diese Berechnungen und besonders die selektive Wahl der in realen Tests erflogenen Szenarios wären matchentscheidend für die Beurteilung der Güte der vorgelegten formalen Verifikation des MCAS.

 

Bitte, keine Ahnung, ich glaub aber nicht, dass hier ein grosses Software Problem vorliegt..die Trigger Logik des MCAS scheint ja relativ einfach zu sein..Konfiguration, Speed, eventuell Altitude und dann ein AOA Wert..wobei der AOA Wert wahrscheinlich overriding ist..

 

Ich glaube eher, das erste Fix wird sein, dass eine Comparator Warning für die AOAs eingebaut wird..( das sollte rein per Software zu machen sein), dann ist einmal wenn ein AOA Sensor schon am Boden spinnt, der Fall klar und es ist ein "no go"..das nimmt schon einmal viele mögliche Fehlfunktionen aus der Gleichung raus..

 

Wenn was im Flug eingeht, wird es eine neu formulierte Checklist geben, die die Comparator Warning ausdrücklich inkludiert..und es wird halt strenge Limitations geben für eine Diversion im Flug( Speed, Altitude ,whatever..)..( wenn das MCAS so wichtig ist..), eventuell machen sie auch automatisch die Funktion vom MCAS von zwei AOAs, die übereinstimmen müssen, abhängig..das kann wohl sein, dass die FAA das vorschreiben wird, das könnte aber ein Major Redesign von den ganzen Stall Warning Circuits auch bedeuten..wird man sehen..

 

Dann werden sie sich anschauen, wie gut die Zuverlässigkeit der AOA Sensors an sich ist, sind sie schlecht vom Design und/oder der Produktion her?..wird es per SB neue "bessere" geben..

 

Von MCAS wegkommen werden sie wahrscheinlich nicht, weil das muss ja einen triftigen Grund haben, warum das eingebaut ist..der Flieger wird sich wahrscheinlich unter gewissen "accelerated stall" Bedingungen aufbäumen..deswegen brauchten sie für diesen "Stick Pusher" den Stab Trim, weil der Elevator offenbar allein nicht ausreicht für das notwendige Nose Down Moment, aus einer "in trim condition heraus", um was ganz Unangenehmes zu vermeiden..( wie weit eine Stall Avoidance per Stab Trim überhaupt eine auch nur annähernd gute Design Idee ist, ist eine andere Frage..die wird sich aber kaum wer stellen jetzt noch in Seattle, weil um das zu vermeiden, hättens offenbar einen anderen Flieger bauen müssen..)

 

so schätz ich halt wird sich das in den nächsten zwei Monaten abspielen..es sei denn, da ist noch was..was Boeing und die FAA heut noch nicht genau, oder noch gar nicht wissen..

 

Gerd

 

 

 

 

Bearbeitet 18. Dezember 2018 von Falconer

[Frank Holly Lake]

vor 6 Stunden schrieb Falconer:

Bitte, keine Ahnung, ich glaub aber nicht, dass hier ein grosses Software Problem vorliegt..die Trigger Logik des MCAS scheint ja relativ einfach zu sein..Konfiguration, Speed, eventuell Altitude und dann ein AOA Wert..wobei der AOA Wert wahrscheinlich overriding ist..

Ich glaube eher, das erste Fix wird sein, dass eine Comparator Warning für die AOAs eingebaut wird..( das sollte rein per Software zu machen sein), dann ist einmal wenn ein AOA Sensor schon am Boden spinnt, der Fall klar und es ist ein "no go"..das nimmt schon einmal viele mögliche Fehlfunktionen aus der Gleichung raus..

Gerd

Aus meiner Paxis , weil ich auf Zügen ( Loks)  öfter mal neue SW  unsers Systems zur Abnahme teste.

Es gibt ein Plichtenheft , in dem klar drin steht , was die SW wann  wie regeln, oder, was geschehen muss.

 

Wir müssen die Regularien im Kopf haben, was für die Zulassung wichtig ist.

Bei diesen Zulassungsvorlagen handelt es sich aus Dokumente aus der " Steinzeit"

Meist aus den 1970 Jahren, die mit der heutigen Technologie nicht mehr viel  zu tuhn haben, aber immer noch relevant sind.

 

So kommt es, das schon bei der Programierung nicht mehr so richtig bekannt ist, wie die SW im Ausnahmefall

zu reagieren hat oder muss.

Auch muss unser  System mit den anderen Komponeten im Zug über den (MVB CAN Bus)  Komunizieren, oder .

mitteilen muss , wo es " Bauchweh" hat , Eingabedaten oder Daten fehlen.

Und da haben wir schon das Problem, das ein Hersteller des Zuges den Bus und die anderen Subsysteme verwaltet

und sich hier nicht in die Karten schauen lassen will.

Also wird im Pflichenheft festgelegt, was für Meldungen (Label) von unserem System in andere Systeme

übertragen werden müssen. Und Da sind die eingendlichen Mängel drin.

 

Ein Programmierer kennt immer nur ein Teile der SW , einen bestimmten Block oder Regelmodul des Systems.

Alles zusammen zu bringen ist das große Geheimnis, die große Kunst.  Da hackt es.

Viele Hersteller haben "outgesourced". Wissen nicht mehr exackt wie was funktioniert.

 

Und da sind wir bei den eigentlichen Problem.

-Zulassungsbehörderden, welche nicht mehr mit der Komplexität vertraut sind

-Entwickler, die nur ein Teilsystem kennen , weil ihnen nicht zu allem Informationen gegeben wird. 

"That you dont need to know " war immer wieder das , was ich auf meine Fragen an den Hersteller des Züge erhielt.

- Veraltete Vorschriften

-keinene Experten mehr, die ausreichend Zeit haben, sich eine Gesamtübersicht zu verschaffen,

Die Hersteller der Subsysteme die hier informationen behalten, nennen wir es mal moderen " Datenschutz"

Vor allen gegenüber den Zulassungsbehörden.

 

Gleiches trifft auch auf Autos oder eben auch Flugzeuge zu.

Das soll keine Entschuldigung sein, versucht aber die Situation zu beschreiben, die in der Industrie derzeit abläuft.

 

Kann ich damit leben? Nein ich nicht. Natürlich sitzt man nach Feierabend im Hotel versucht noch mal alles nachzuvollziehen  und hofft, nichts übersehen zu haben.

Denn eines musste ich in den letzten 5 jahren lernen, es gibt auch beim Zug, kein unwichtiges System mehr,

weil alles irgendwie miteinader zusammenarbeitet.

Grüße Frank

Bearbeitet 18. Dezember 2018 von Frank Holly Lake

[Falconer]

11 minutes ago, Frank Holly Lake said:

Das soll keine Entschuldigung sein, versucht aber die Situation zu beschreiben, die in der Industrie derzeit abläuft.

 

Naja, das mag schon so sein..

 

bissel off-topic aber könnte zum Thema passen..ganz neue Sache hier..

 

https://www.ainonline.com/aviation-news/business-aviation/2018-12-13/textron-seeks-new-longitude-fuel-tank-exemption

 

offenbar Auslegungsunterschiede von neueren Design- und Bauvorschriften zwischen der FAA und Cessna..man fragt sich halt in solchen Fällen, warum haben sich die offenbar nicht bei der Konzeption des neuen Modells schon zusammengesetzt und das damals ausbaldowert um zu einer sauberen, ohne "Exemptions" zulassbaren Lösung zu kommen?..da liegt die Bringschuld doch beim Hersteller..die Zulassungsbehörde kann ja nicht riechen, was sich ein Designbüro so ausdenkt, wenn der Tag lang ist..und welchen Missverständnissen es eventuell unterliegt bei der Interpretation von neuen Bauvorschriften..

 

das scheint heute oft Alltag zu sein in der Branche schon, aus welchen Gründen auch immer..

 

Gerd

 

 

[cosy]

31 minutes ago, Frank Holly Lake said:

Ein Programmierer kennt immer nur ein Teile der SW , einen bestimmten Block oder Regelmodul des Systems.

Alles zusammen zu bringen ist das große Geheimnis, die große Kunst.  Da hackt es.

Viele Hersteller haben "outgesourced". Wissen nicht mehr was exackt wir was funktioniert.

Dazu verwendet man dann sogenannte "Blackbox-Tests". Aber Du hast wirklich den Nagel auf den Kopf getroffen. Als ich noch bei einem Zulieferant von u.A. Tales arbeitete ( in einer schweizer embedded computer Firma, die dann von einem grossen Südkoreaner gekauft wurde- mit der Folge, dass die Schweizer Niederlassung komplett ausgemistet wurde bis auf ein paar Sales und ein Spediteam für Shipping und Rechnungsstellung von sensiblen Kunden wie RUAG, SBB, Schweizer Post , Schweizer Armee usw..):

Die Kernkomponenten eines bestimmten Embedded System für Hochgeschwindigkeitszüge war aufgrund von erreichten Zulassungsprüfungen und mangels Kenntnissen zur Code-Review von Vorgängern "eingefrohren": absolut verboten, den kleinsten Update oder die kitzekleinste Änderung an einem mikrigen conf-file durchzuführen. Mit dem Ergebniss, dass die Lösung in den Compliance Tests (in der Serienproduktion) regelmässig durchfielen und instabil waren im vergleich zu unseren (embedded Linux) Testreferenzen, die immer auf dem neusten Update - Stand gehalten wurden. 

Für SW-Entwickler, besonders im OS-nahen Umfeld (allg. Treiber, Videosignalaufbereitung, Busankopplung usw.) war das eine andauernde Herausforderung und ein stetiger Frust.

Das Designen von Blackbox- Tests wird so zum Spiessrutenlauf.

 

 

Bearbeitet 18. Dezember 2018 von cosy

[Falconer]

9 minutes ago, cosy said:

Das Designen von Blackbox- Tests wird so zum Spiessrutenlauf.

 

das kann ich mir schon vorstellen..

 

interessant aber, soweit sind wir Gott-sei-Dank in der Luftfahrt noch nicht...im positiven Sinne vielleicht...Software Updates, auch bei "flight critical" Software, die müssen natürlich gut getestet sein, aber die gibt es doch sehr oft..und werden erfolgreich in den Flotten eingebaut..OK, manchmal hakt es ein bissel nach einem Update..aber das wird dann sehr schnell in Ordnung gebracht..

 

Gerd

 

 

[mrueedi]

Am ‎17‎.‎12‎.‎2018 um 12:31 schrieb Hunter58:

Also, soweit ich MACS verstehe geht es darum bei high speed aus einer high-AOA situation herauszukommen und das Verhalten and die NG anzupassen. Nicht mehr.

Die Frage ist nicht, wozu MCAS im Normalfall gedacht ist. Das Problem war ja, das wegen der fehlerhaften AoA Messung das System zum falschen Zeitpunkt und bei einer viel tieferen als der vorgesehenen Geschwindigkeit aktiv wurde.

 

Die Software würde ich auch nicht als erstes verdächtigen. Die Logik ist recht simpel und hat wahrscheinlich funktioniert gemäss "works as designed". Bloss war das Design offenbar recht dilettantisch. Es ist ja so, dass das Abhandeln von Fehlerfällen normalerweise in einer Software mehr Code benötigt als der Happy Case. Offenbar wurden bei diesem MCAS nun nicht alle Fehlerfälle sauber abgedeckt. Deshalb ist Boeing ja dabei, einen Software Update nachzuliefern.

 

Einen simplen Softwarefehler (im Gegensatz zum erwähnten, fehlerhaften System Design) würde ich auch deshalb eher ausschliessen, weil Avionik nach dem DO-178C Standard entwickelt wird, welcher die sicherste Art der Softwareentwicklung darstellt, die es überhaupt gibt. Ich bin selber Softwareentwickler (auch für UAVs) allerdings nicht nach DO-178.

 

 

[teetwoten]

vor 1 Stunde schrieb mrueedi:

 Es ist ja so, dass das Abhandeln von Fehlerfällen normalerweise in einer Software mehr Code benötigt als der Happy Case.

 

Das bezeichnen wir ja mit FMEA. Wobei es hier wahrscheinlich noch auf der einfacheren Seite lag, da die möglichen (Input-) Fehlerquellen bekannt sind (sofern die Schemas stimmten). Der noch grössere Aufwand besteht doch darin, wenn nicht nur Systeme Input liefern, sondern auch Menschen. Und da muss man dann alle erdenklichen Fehleingaben (finger-troubles) abfangen und in geeigneter Weise verarbeiten, was die Komplexität dann schnell vervielfacht (und beispielsweise auch heute noch PC's zum hang-up bringen kann)...

 

Stefan

 

[Frank Holly Lake]

Von der ermittelnden Behörde:

Es war auch ein Wartungsfehler.

Auszug:

Das Verhängnis nahm offenbar bereits zwei Tage vor dem Absturz seinen Lauf -

Laut einem Bericht des "Wallstreet Journal" haben Flugunfallermittler festgestellt, dass Lion Air beim Tausch eines Anströmwinkelsensors Fehler unterlaufen sind.

Der hochgradig sicherheitsrelevante Sensor wurde demnach "nicht korrekt kalibriert".

 

Klicker Klacker

Grüße Frank

Bearbeitet 29. Dezember 2018 von Frank Holly Lake

[Frank Holly Lake]

Und aus der gleichen Quelle:

 

Boeing musste sich nach dem Absturz vorhalten lassen, Airlines und Betreiber nicht hinreichend über den mit der 737 MAX 8 eingeführten Fluglagekorrektor "MCAS" ins Bild gesetzt zu haben. Das System wertet unter anderem Daten der Anströmwinkelsensoren aus. Errechnet der Computer einen drohenden Strömungsabriss, greift das MCAS aktiv in die Trimmung ein.

 

Grüße Frank

[IFixPlanes]

vor 17 Stunden schrieb Frank Holly Lake:

Von der ermittelnden Behörde:

Es war auch ein Wartungsfehler.

Auszug:

Das Verhängnis nahm offenbar bereits zwei Tage vor dem Absturz seinen Lauf -

Laut einem Bericht des "Wallstreet Journal" haben Flugunfallermittler festgestellt, dass Lion Air beim Tausch eines Anströmwinkelsensors Fehler unterlaufen sind.

Der hochgradig sicherheitsrelevante Sensor wurde demnach "nicht korrekt kalibriert".

Ich zitiere mich mal aus dem Airliners.de:

Zitat

Am Flieger wird der Sensor weder kalibriert noch eingestellt.

Passen die Werte beim Test nach dem Einbau nicht, dann braucht man noch einen Neuen.
Die AOA-Sensoren werden mit kalibriertem Werkzeug im eingebauten Zustand auf 0° und dann nach 20° zu beiden Seiten ausgelenkt und dieser Ausschlag wird über bordeigene Systeme abgefragt. Dabei müssen die Werte auf ± 1° übereinstimmen.
Sollte dieses Werkzeug nicht zu Verfügung stehen, dann kann alternativ der Sensor an die Endanschläge gedreht werden und die Abfrage muss 0° sowie 100° ± 5° ergeben.

0° wird in diesem Fall über den "alignment pin" (stellt sicher, dass der Sensor nicht verdreht eingebaut werden kann) definiert.

(so steht es in den Wartungsunterlagen der MAX)

 

vor 17 Stunden schrieb Frank Holly Lake:

Und aus der gleichen Quelle:

 

Boeing musste sich nach dem Absturz vorhalten lassen, Airlines und Betreiber nicht hinreichend über den mit der 737 MAX 8 eingeführten Fluglagekorrektor "MCAS" ins Bild gesetzt zu haben. Das System wertet unter anderem Daten der Anströmwinkelsensoren aus. Errechnet der Computer einen drohenden Strömungsabriss, greift das MCAS aktiv in die Trimmung ein.

Das MCAS ist wie das STS eine Funktion des FCC und kein eigenständiges System.
Damit diese Funktion aktiv werden kann müssen folgende Bedingungen gegeben sein:
- MCAS is enable for airplane model by program pin selection
- Autopilot is disengaged
- Flaps are up
- Pilots are not commanding stabilizer trim (Manual mode)

Bearbeitet 30. Dezember 2018 von IFixPlanes
Quelle der Quelle...

[Frank Holly Lake]

@ ingo

Sollte die Wallstreet Journal so weit daneben liegen? Das ist ja nun keine kleine unbedeuten Zeitung?

Grüße Frank

[IFixPlanes]

Beim WsJ ist ne Bezahlmauer davor, aber es ist mir eigentlich auch egal was die schreiben, da der AOA Sensor nach AMM eingebaut wird und nicht nach einer Zeitung.
Das AMM gibt auch vor, welche Teste danach durchgeführt werden müssen. Ich habe mir extra das AMM der MAX besorgt, denn der Einbau hätte sich ja zur NG ändern können - aber das ist nicht der Fall.

[Niko]

Ingo, vielen Dank für die Arbeit die du dir machst um uns mit solchen Informationen zu versorgen! Habe gestern Nacht selber gemerkt dass das nicht mal eben eine Sache von 5 Minuten ist. Das ist nicht selbstverständlich und sollte mehr geschätzt werden!

[AustrianSimon]

Am ‎30‎.‎12‎.‎2018 um 14:15 schrieb IFixPlanes:

Beim WsJ ist ne Bezahlmauer davor, aber es ist mir eigentlich auch egal was die schreiben, da der AOA Sensor nach AMM eingebaut wird und nicht nach einer Zeitung.
Das AMM gibt auch vor, welche Teste danach durchgeführt werden müssen. Ich habe mir extra das AMM der MAX besorgt, denn der Einbau hätte sich ja zur NG ändern können - aber das ist nicht der Fall.

 

Hallo, Ingo,

 

ich habe das WSJ wie auch die NYT bereits mehrfach bei sehr schlimmen Fehlern erwischt, wo sie unter Berufung auf Quellen nahe der Unfalluntersuchung oder militärische Quellen usw. allen möglichen Unsinn von sich geben. Im speziellen erregt "Andy Pasztor" vom WSJ (der möglicherweise bis NYT ausstrahlt) meinen Unmut, er hat bei mir weniger als Null Glaubwürdigkeit.

 

Danke für die Ausführung zum Einbau des AoA Sensors.

 

Es würde sich ja auch die Frage stellen, wieso der erste AoA Sensor plötzlich ähnlich falsch angezeigt haben soll 3 Flüge vor dem Absturz und einige hundert Flüge davor nicht (der AoA war ja noch original, von Boeing eingebaut).

 

Servus, Simon

P.S.: Allen ein gesundes, erfolgreiches und fröhliches 2019!

[cosy]

On 12/30/2018 at 2:15 PM, IFixPlanes said:

Beim WsJ ist ne Bezahlmauer davor, aber es ist mir eigentlich auch egal was die schreiben, da der AOA Sensor nach AMM eingebaut wird und nicht nach einer Zeitung.
Das AMM gibt auch vor, welche Teste danach durchgeführt werden müssen. Ich habe mir extra das AMM der MAX besorgt, denn der Einbau hätte sich ja zur NG ändern können - aber das ist nicht der Fall.

Wie sieht die Änderungsgeschichte dieses Abschnitts aus?

[IFixPlanes]

Ich musste erst mal kurz überlegen was du mit "Änderungsgeschichte" meinst
Die aktuelle Revision ist 15.September 2018 (Rev.5) und die AOA Installation darin ist seit Stand 15.September 2017 (Rev.2) nicht verändert worden.
Revidiert wird alle 4 Monate so dass es zum 15.Januar die Rev.6 geben dürfte.
Es gibt auch keine Temporary Revisions.
Die oben beschriebenen Tests sind auch schon bei der NG so gefordert. (meine älteste greifbare Revision ist von Feb.2015)

[Hunter58]

Noch kurz zum ‘Streit’ zwischen Cessna und der FAA. Cessna zweifelt (wie fast die ganze Airlinewelt) die Wirkung der inzwischen Vorgeschriebenen Stickstoffanreicherungsanlagen für im Rumpfbereich liegende Tanks an. Die wurden nach der TWA 747 vorgeschrieben da der damalige Chef des NTSB seinem Steckenpferd nachging und ja kein Section 41 Problem gefunden werden durfte (auch wenn dieses alle immer noch offenen Fragen beantworten dürfte). Cessna möchte die ‘Neue’ als Derivat der bisherigen Serie ohne grosse Änderungen zulassen, aber da der Flieger grösser und schwerer ist als bisher sagt die FAA, nein, neue Flugzeugkategorie da es nach Gewichten geht und nicht Einsatzzweck...

 

Cessna möchte Logik gelten lassen, die FAA geltendes Papier mit arbiträr gesetzten Grenzen.

 

Zurück zum Fall hier: Boeing ist im ganzen Zulassingsprozess ziemlich sicher davon ausgegangen dass ein System wie eine AOA-Sensor nicht tagelang unrepariert oder ungeprüft durch die Gegend geflogen wird!

[Falconer]

3 hours ago, Hunter58 said:

Noch kurz zum ‘Streit’ zwischen Cessna und der FAA. Cessna zweifelt (wie fast die ganze Airlinewelt) die Wirkung der inzwischen Vorgeschriebenen Stickstoffanreicherungsanlagen für im Rumpfbereich liegende Tanks an. Die wurden nach der TWA 747 vorgeschrieben da der damalige Chef des NTSB seinem Steckenpferd nachging und ja kein Section 41 Problem gefunden werden durfte (auch wenn dieses alle immer noch offenen Fragen beantworten dürfte). Cessna möchte die ‘Neue’ als Derivat der bisherigen Serie ohne grosse Änderungen zulassen, aber da der Flieger grösser und schwerer ist als bisher sagt die FAA, nein, neue Flugzeugkategorie da es nach Gewichten geht und nicht Einsatzzweck...

 

Cessna möchte Logik gelten lassen, die FAA geltendes Papier mit arbiträr gesetzten Grenzen.

 

Zurück zum Fall hier: Boeing ist im ganzen Zulassingsprozess ziemlich sicher davon ausgegangen dass ein System wie eine AOA-Sensor nicht tagelang unrepariert oder ungeprüft durch die Gegend geflogen wird!

 

OK, ist zwar jetzt doch ein bissel off-topic…aber nicht ganz..wenn wir schon dabei sind..

 

1) Was Fuel Tank Safety betrifft, das ist jetzt mittlerweile ein alter Hut seit TWA 800….und es gab sehr wohl designmässig seither viele Verbesserungen..und ja, TWA 800 ist durch eine Centre Fuel Tank Explosion abgestürzt..

 

gab es die wildesten Verschwörungstheorien..ist bekannt…leider auch unter Profis..hab das damals selbst miterlebt, als Fachleute aus den USA, die ansonsten fachlich top und sehr nüchtern immer argumentiert hatten, nicht akzeptieren konnten, dass eine Mischung aus "aging aircraft" Problematik, also abgenützem Wiring und Funken schlagenden Booster (transfer)pumps sehr wohl eine ordentlichen Klescher machen können in einem fast leeren Tank mit warmen gesättigten Kerosindämpfen..

 

seither wissen auch Alle wieder, dass warme Kerosindämpfe sehr gut knallen…kaltes Jet A brennt eh nicht…muss man erst vorwärmen...

 

was Cessna da betrifft, geht da zwar um ein bissel was Anderes, aber doch, dachte man wohl, naja, same procedure as every year, und das wird schon durchgehen bei der FAA..hat man sich offenbar verschätzt..so wurde Einiges in den letzten 20 Jahren zwischen Cessna und dem Wichita ACO gehandhabt…die Zeiten sind offenbar vorbei...

 

ja, zugegeben, es gibt auch manchmal neue Bauvorschriften, die übertrieben scheinen..

 

a la longue aber trotzdem sinnvoll sind was Sicherheit betrifft…nennt sich Fortschritt..

 

2) Zur Anschauung wie das andere Hersteller so halten..sorry, man sieht jetzt wieder meinen Bias…aber ist so..

 

Als Dassault im Endstadium der Zulassung für die Falcon 7X stand kamen neue Bauvorschriften für Bleed Air Temperaturen heraus..in dem Sinne als man seither die Temperatur von der "unconditioned" Bleed Air in den Leitungen niedriger haben wollte, um Komplikationen durch zu grosse Hitze zu vermeiden..

 

Ich glaube sie hätten es damals für die 7X gar noch nicht gebraucht..aber Dassault hat dann dioch noch in einem sehr späten Stadium der 7X Entwicklung von selbst ohne Zwang Bleed Precoolers für alle drei Triebwerke eingebaut…war sicher nicht so einfach platzmässig..OK, ist auch eine zusätzliche Komplikation…aber sie haben es trotzdem gut gelöst..obwohl kein Fall bekannt war seit der ersten Falcon 20 aus dem Jahre 1963, dass der Bruch einer heissen Bleed Air Leitung jemals ein Problem gewesen wäre auf Falcons..

 

Jetzt bei der Falcon 6X…machen sie Stickstoff Inerting in die Tanks..OK, Dassault kennt sich auch damit aus aus dem militärischen Bereich..ist gebongt..obwohl wiederum seit 1963 kein in-flight fuel fire jemals bei einer Falcon zu beobachten war..eben weil das Fuel System der Falcons von Anfang an immer sehr safe designed war…die Bauvorschriften verlangens nun jetzt einmal..Tanks so sicher wie nur menschenmöglich zu machen...

 

also so kann man es auch machen..

 

nennt sich Fortschritt..

 

3) Was Boeing betrifft…keine Frage..Wartungsfehler kann man nicht immer voraussehen….

 

Nur, in dem Fall, hätte auch eine erstmalige AOA Fehlfunktion im Flug , ohne dass es auf vorangegangenen Flügen ein Problem gegeben hätte, eine Herausforderung darstellen können. die in einen Unfall mündet...

 

Die FAA hat sicher nicht leichtfertig ein EAD publiziert…mit dem Proviso, das steht auch nicht in allen ADs, dass da noch was kommen kann..je nachdem was die Analysen jetzt noch hervorbringen werden..

 

Und Boeing arbeitet nun derzeit mit Hochdruck an einem ersten Software Mod….there is a message..

 

Gerd

 

P.S.: Sind die Behörden immer konsequent?

 

Nein, sonst hätte die B787 nie mit den Li Pos zugelassen werden dürfen…zur Erinnerung die 787 hat eine chemische Mischung in den Batts, die gleich ist mit den LiPos die viele Modellfugzeugbauer kennen, und wo man ab und zu in den Medien liest, dass Häuser abbrennen, weil im Hobbykeller LIPos unbeaufsichtigt am Charger hingen..und dabei hochgegangen sind...

 

P.P.S.: Diese LiPos sind beim der 787 nur notwendig, eine Batterie braucht man um einen RTO nur auf Battery machen zu können, weil sie rein elektrische Bremsen hat, die andere braucht man um über einen grossen AC Starter Generator die APU starten zu können, weil man sich einen kleinen zusätzlichen  reinen DC Starter auf der APU erspart hat..NUR deswegen braucht die 787 die zwei Batts mit einer Discharge Rate von ca 50 Amperestunden innerhalb von 50 Sekunden…ohne diese zwei Systeme käme die 787 ganz leicht mit stinknormalen NiCads oder Lead Acids aus…je nachdem was ein Betreiber bevorzugt...

 

Die Bremsen in dem Entwicklungsstadium aber auf hydraulische Bremsen umzubauen, und den Accessory Drive der APU auf einen kleinen zusätzlichen DC Starter umzubauen, hätte eine weitere Verzögerung ( nach Grounding) von minimum 2 -3 Jahren bis Wiederindienststellung bedeutet..so und deswegen hat nicht nur die FAA, sondern auch die EASA das Bandaid Mod der Batterien auf den 787 zugelassen…waren kommerzielle Gründe, weil Boeing sonst pleite gegangen wäre…….war so...

 

Gibt es einige Top Dogs beim Engineering in Everett die jeden Tag 10 Rosenkränze heute noch beten, dass ein Batteriehersteller ihnen Batterien baut mit der selben Dischargerate wie die die jetzt eingebaut sind, aber ohne die Nachteile?…You bet….

 

weil, sollten wieder ein paar 787 ( Gott behüt) im Flug zum Rauchen anfangen, gibt es mit an Sicherheit grenzender Wahrscheinlichkeit das nächste Mal ein längeres Grounding der Flotte...

 

 

 

 

 

 

Bearbeitet 2. Januar 2019 von Falconer

[IFixPlanes]

Ich verstehe nicht was "unconditioned" Bleed Air mit dem TWA 800 Unfall zu tun hat.

Naja, Haupsache was geschrieben...