Community / / 737 MAX setzt Piloteneingaben verzö...

Beitrag 46 - 60 von 60
1 | 2 | 3 | 4 | « zurück | weiter »
Beitrag vom 01.07.2019 - 13:09 Uhr
Userdlehmann66
User (421 Beiträge)
Ja so funktioniert aber IT nicht.
- also wenn der AoA Sensor ein 16 bit Wert liefert, dann muss ja ein embeded Chip aus der Winkel Drehung des AoA Sensors so ein 16 bit Wert erzeugen. Dann muss er noch ein Timestamp, ein Namen dazu tun, damit der Computer weiss, von welchen Sensor es kommt und eine Codierung, damit der Computer weiss, dass ist ein AoA Sensor Wert. Mit 16 bit, kann man grob 65.000 verschiedene Werte beschreiben. Das reicht nicht für den Messwert + Timestamp + Sensorname + Code für AoA Sensor Wert.
Es braucht dann schon mehr als 16 bit.
- Nehmen wir an der AoA Sensor kriegt ein Vogelschlag und der der Microprozessor im Sensor spinnt dann und meldet dann nur noch Nullen und flutet das System immer mit Nullen
- Das kann dann zu einem Speicherüberlauf führen, zu den oben beschriebenen Folgen, bei einem Selbstmonitoring, kann das zu einem ständigen Recovern des Systems und damit zu einer Nichtmehrnutzbarkeit führen und und und....
- die Möglichlichkeiten sind vielfältig, warum eine Programm mit einem Fehlwert abstürzt oder ein anderes System in die Knie zwingt und man kann nicht alles beschreiben und abfangen
- der Sensor hätte ja dann auch nix mehr liefern können
- oder weil er verklemmt ist einen falschen Wert aus der verklemmten Stellung
- oder vollkommen Datenmüll
- ein Timestamp aus dem Jahre 1988
Die Möglichkeiten sind so vielfältig, dass man einfach nicht alle abfangen kann

Dieser Beitrag wurde am 01.07.2019 13:12 Uhr bearbeitet.
Beitrag vom 01.07.2019 - 13:43 Uhr
UserNCC1701
User (287 Beiträge)
- Nehmen wir an der AoA Sensor kriegt ein Vogelschlag und der der Microprozessor im Sensor spinnt dann und meldet dann nur noch Nullen und flutet das System immer mit Nullen
- Das kann dann zu einem Speicherüberlauf führen,

Woher weißt du das? In deinem ersten Beitrag hast du das anders geschrieben.

Ist der Sensor passiv und wird durch den MP abgefragt oder ist er aktiv, d.h. der Sensor sendet die Daten zum MP? Wenn er aktiv seien sollte, kann ich mir in diesem Fall schwer vorstellen, dass da noch eine Queue vor der Verarbeitung ist - sehe den Sinn nicht.

...NCC1701

Dieser Beitrag wurde am 01.07.2019 13:44 Uhr bearbeitet.
Beitrag vom 01.07.2019 - 14:08 Uhr
UserA320Fam
User (1359 Beiträge)
So genau kenn ich mich mit Elektronik nicht aus. Ob das jetzt 16bit oder 32bit sind oder sonst was weiss ich gar nicht, ob es überhaupt bit sind.
Aber ein AOA Sensor hat meines Wissens nach keinen MP, der gibt einfach seine Stellung als Gradzahl weiter zur Bearbeitung. Daher meinte ich auch der sendet immer ein Signal in gleicher Grösse zum Flightcomputer.
Beitrag vom 01.07.2019 - 14:52 Uhr
Usermenschmeier
User (620 Beiträge)
Ja so funktioniert aber IT nicht.
- also wenn der AoA Sensor ein 16 bit Wert liefert, dann muss ja ein embeded Chip aus der Winkel Drehung des AoA Sensors so ein 16 bit Wert erzeugen. Dann muss er noch ein Timestamp, ein Namen dazu tun, damit der Computer weiss, von welchen Sensor es kommt und eine Codierung, damit der Computer weiss, dass ist ein AoA Sensor Wert. Mit 16 bit, kann man grob 65.000 verschiedene Werte beschreiben. Das reicht nicht für den Messwert + Timestamp + Sensorname + Code für AoA Sensor Wert.
Es braucht dann schon mehr als 16 bit.
- Nehmen wir an der AoA Sensor kriegt ein Vogelschlag und der der Microprozessor im Sensor spinnt dann und meldet dann nur noch Nullen und flutet das System immer mit Nullen
- Das kann dann zu einem Speicherüberlauf führen, zu den oben beschriebenen Folgen, bei einem Selbstmonitoring, kann das zu einem ständigen Recovern des Systems und damit zu einer Nichtmehrnutzbarkeit führen und und und....
- die Möglichlichkeiten sind vielfältig, warum eine Programm mit einem Fehlwert abstürzt oder ein anderes System in die Knie zwingt und man kann nicht alles beschreiben und abfangen
- der Sensor hätte ja dann auch nix mehr liefern können
- oder weil er verklemmt ist einen falschen Wert aus der verklemmten Stellung
- oder vollkommen Datenmüll
- ein Timestamp aus dem Jahre 1988
Die Möglichkeiten sind so vielfältig, dass man einfach nicht alle abfangen kann

Ihre Computerkenntnisse in allen Ehren, aber von IT im Flugzeug haben sie noch nie etwas gehört vielicht aber auch noch nie hören können.

Der AoA ist genau an einen Computer angeschlossen, und zwar in eine nur für ihn bestimmte Datenleitung. Im Falle Airbus ist dieser Computer die ADIRU, diese fragt den AoA Eingang, der nur für den AoA zuständig ist, alle x Millisekunden ab und erzeugt daraus ein ARINC 429/AFDX (bei A380 und A350) Datenwort. Dieses Datenwort sendet sie zu genau festgelegten Zeiten auf ihren Ausgangsbus. Alle von diesem Datenwort betroffenen Computer (Das können auch mehrere gleichzeitig sein, der Desitination Identifier kann auch eine Gruppe beinhalten) lesen dieses Datenwort zu den definierten Zeiten und auch nur dann. Und so passiert das mit allen Werten.

So kann die ADIRU rein hypotethisch gesagt immer in einer Reihenfolge
Airspeed, Altitude, Vertical Speed, .... wiederholend senden. Dabei kann ein bestimmtes Datenwort in der Reihenfolge auch häufiger vorkommen, während andere seltener sind.

Somit kann es keinen Speicherüberlauf geben. Auch ein falscher Timestamp ist nich möglich, denn das ARINC Wort hat keinen Timestamp.
 https://www.kunbus.de/arinc-429.html

All die Probleme, die sie beschreiben, sind nur ein Problem in unausgegorenen und unzulänglich programmierten Systemen wie dem der Personalcomputer und dem Internet.

Es fällt leider immer wieder auf, das Foristen, aus ihren Beruflichen udn privaten Erfahrungen aus anderen technischen Bereichen auf den Flugzeugbau bzw dessen Technik schließen.

Ein Flugzeug ist aber nicht im Geringsten mit einem Auto, Bus, LKW, Schiff, einem Computer oder dem Aluminiumgußgrill auf der Terrasse vergleichbar.

Dieser Beitrag wurde am 01.07.2019 15:17 Uhr bearbeitet.
Beitrag vom 01.07.2019 - 15:13 Uhr
UserA320Fam
User (1359 Beiträge)
Ja so funktioniert aber IT nicht.
- also wenn der AoA Sensor ein 16 bit Wert liefert, dann muss ja ein embeded Chip aus der Winkel Drehung des AoA Sensors so ein 16 bit Wert erzeugen. Dann muss er noch ein Timestamp, ein Namen dazu tun, damit der Computer weiss, von welchen Sensor es kommt und eine Codierung, damit der Computer weiss, dass ist ein AoA Sensor Wert. Mit 16 bit, kann man grob 65.000 verschiedene Werte beschreiben. Das reicht nicht für den Messwert + Timestamp + Sensorname + Code für AoA Sensor Wert.
Es braucht dann schon mehr als 16 bit.
- Nehmen wir an der AoA Sensor kriegt ein Vogelschlag und der der Microprozessor im Sensor spinnt dann und meldet dann nur noch Nullen und flutet das System immer mit Nullen
- Das kann dann zu einem Speicherüberlauf führen, zu den oben beschriebenen Folgen, bei einem Selbstmonitoring, kann das zu einem ständigen Recovern des Systems und damit zu einer Nichtmehrnutzbarkeit führen und und und....
- die Möglichlichkeiten sind vielfältig, warum eine Programm mit einem Fehlwert abstürzt oder ein anderes System in die Knie zwingt und man kann nicht alles beschreiben und abfangen
- der Sensor hätte ja dann auch nix mehr liefern können
- oder weil er verklemmt ist einen falschen Wert aus der verklemmten Stellung
- oder vollkommen Datenmüll
- ein Timestamp aus dem Jahre 1988
Die Möglichkeiten sind so vielfältig, dass man einfach nicht alle abfangen kann

Ihre Computerkenntnisse in allen Ehren, aber von IT im Flugzeug haben sie noch nie etwas gehört.

Der AoA ist genau an einen Computer angeschlossen, und zwar in eine nur für ihn bestimmte Datenleitung. Im Falle Airbus ist dieser Computer die ADIRU, diese fragt den AoA Eingang, der nur für den AoA zuständig ist, alle x Millisekunden ab und erzeugt daraus ein ARINC 429/AFDX (bei A380 und A350) Datenwort. Dieses Datenwort sendet sie zu genau festgelegten Zeiten auf ihren Ausgangsbus. Alle von diesem Datenwort betroffenen Computer (Das können auch mehrere gleichzeitig sein, der Desitination Identifier kann auch eine Gruppe beinhalten) lesen dieses Datenwort zu den definierten Zeiten und auch nur dann. Und so passiert das mit allen Werten.

So kann die ADIRU rein hypotethisch gesagt immer in einer Reihenfolge
Airspeed, Altitude, Vertical Speed, .... wiederholend senden. Dabei kann ein bestimmtes Datenwort in der Reihenfolge auch häufiger vorkommen, während andere seltener sind.

Somit kann es keinen Speicherüberlauf geben. Auch ein falscher Timestamp ist nich möglich, denn das ARINC Wort hat keinen Timestamp.

All die Probleme, die sie beschreiben, sind nur ein Problem in unausgegorenen und unzulänglich programmierten Systemen wie dem der Personalcomputer und dem Internet.



👍👍👍
Beitrag vom 01.07.2019 - 15:42 Uhr
UserLP
User (376 Beiträge)
Ich könnte mir vorstellen, dass es im Zusammenhang mit den beiden Abstürzen noch ein, zwei andere Probleme mit der MAX gibt. Die Kollegen in Seattle bauen ja nun schon ganz paar Jahre Luftfahrtgeräte. Ich glaube einfach nicht, dass die (z.B.) das MCAS mit dem "nur" einzelnen Sensor verbinden, wenn da irgendein Risiko bestehen könnte! So ein Sensorausfall wird ja wohl mit einkalkuliert!
So doof sind die dort auch nicht!
Ich bin da noch gespannt, was wir weiterhin erfahren über die Ursachen und Abläufe.
Beitrag vom 01.07.2019 - 15:55 Uhr
Usermenschmeier
User (620 Beiträge)
Ich glaube einfach nicht, dass die (z.B.) das MCAS mit dem "nur" einzelnen Sensor verbinden, wenn da irgendein Risiko bestehen könnte! So ein Sensorausfall wird ja wohl mit einkalkuliert!

Das ist nun hinreichend nachlesbar. Das MCAS ist eine Funktion des Flight Control Computers, davon hat die B737 zwei Stück. Diese haben unter anderem beim automatisierten Flug über das Autopilot Flight Director System Kontrolle über die Flugsteuerung.

Jeder FCC hat dabei seinen eigenen (einzelen) AoA Sensor, den Wert das anderen AoA bzw FCC hat er nicht zur Verfügung.

In jedem Flug ist nur einer der beiden FCC aktiv und mit ihm auch sein MCAS. Die Umschaltung erfolgt automatisiert und kann nicht beeinflusst werden. (für den manuellen Flug)
Beitrag vom 01.07.2019 - 16:13 Uhr
UserLP
User (376 Beiträge)
Ich glaube einfach nicht, dass die (z.B.) das MCAS mit dem "nur" einzelnen Sensor verbinden, wenn da irgendein Risiko bestehen könnte! So ein Sensorausfall wird ja wohl mit einkalkuliert!

Das ist nun hinreichend nachlesbar. Das MCAS ist eine Funktion des Flight Control Computers, davon hat die B737 zwei Stück. Diese haben unter anderem beim automatisierten Flug über das Autopilot Flight Director System Kontrolle über die Flugsteuerung.

Jeder FCC hat dabei seinen eigenen (einzelen) AoA Sensor, den Wert das anderen AoA bzw FCC hat er nicht zur Verfügung.

In jedem Flug ist nur einer der beiden FCC aktiv und mit ihm auch sein MCAS. Die Umschaltung erfolgt automatisiert und kann nicht beeinflusst werden. (für den manuellen Flug)

Ja, ich habe mich falsch ausgedrückt, dass dies so konstruiert und installiert ist, weiß ich natürlich.
Dann denke ich aber: die Konstrukteure und Designer usw. haben in dieser Auslegung nach bestem Wissen und Gewissen kein Risiko gesehen. Weil wie ich schon schrieb, mit dem Ausfall solch einer Komponente rechnen die ja auch.
Deswegen glaube ich langsam, dass Problem ist ein anderes, nur natürlich hat MCAS in Verbindung mit fehlerhaften Werten dazu beigetragen.
Beitrag vom 01.07.2019 - 17:48 Uhr
Usermenschmeier
User (620 Beiträge)
Dann denke ich aber: die Konstrukteure und Designer usw. haben in dieser Auslegung nach bestem Wissen und Gewissen kein Risiko gesehen. Weil wie ich schon schrieb, mit dem Ausfall solch einer Komponente rechnen die ja auch.
Deswegen glaube ich langsam, dass Problem ist ein anderes, nur natürlich hat MCAS in Verbindung mit fehlerhaften Werten dazu beigetragen.

Das wäre sicher die für die Luftfahrtindustrie bessere Variante. Nur allein glaube ich da nicht dran.

Es gibt ein paar Indikatoren die klar dagegen sprechen.

Boeing hat das System MCAS in allen Handbüchern verschwiegen und folglich auch nicht geschult , obwohl es massiv in die Flugsteuerung eingreift.
Boeing hat das System im Fehlerfalle als Major eingestuft, es hätte aber als Catastrophic eingestuft werden müssen. Dazwischen gibt es noch die Stufe Harzardous.

Schaut man danach in die nähere Vergangenheit zum Dreamliner hat Boeing da auch schon die Freiheiten sehr großzügig genutzt und Batterien verbaut, die eigentlich nicht den Sicherheitsstandards der Luftfahrt entsprechen und wo es entsprechende Vorfälle gab, die das vermuten ließen. So ist dem Ladegeräthersteller die ganze Fabrik abgebrannt, nachdem bei einem frühen Test eine der Batterien durchgegangen war. Auch ist im Testflugprogramm ein Dreamliner nur dank der Testpiloten in Texas notgelandet, nachdem es nach einem Batteriefehler zu massiven Systemproblemen kam.

Es gibt mehrere Berichte von nationalen und Internationalen Medien über die Zustände in den Boeing Werken. Wie zum Beispiel  https://www.youtube.com/watch?v=rvkEpstd9os

Ich denke da steckt ein Mentalitätsproblem des oberen Managments dahinter. Gerade bei der MAX sind sie ganz kalt von der A320NEO Familie überrascht worden.

Nur um das klarzustellen, auch bei Airbus ist nicht alles glänzend, die PW Probleme im Service sind mMn. auch ein Problem von zu schneller Entwicklung/Zertifizierung bei den Motoren. Nur ist ein Triebwerksausfall nicht so gravierend für die Flugsicherheit, wie ein unzureichend entwickeltes Flugsteuerungssystem, welches es zudem in dieser Form bei Boeing noch nie gab. Airbus hat da mit der A320 Entwicklung einen enormen Erfahrungsvorsprung und muss das System immer nur an das neue Flugmodell anpassen, denn die gesamten Flight-Envelop-Protection reagiert immer gleich, nur ist zum Beispiel bei der A380 der AlphaMax vielleicht ein anderer als bei der A320.
Beitrag vom 01.07.2019 - 18:11 Uhr
UserLP
User (376 Beiträge)
Für mich sehr nützliche Infos, vielen Dank!
Beitrag vom 02.07.2019 - 12:13 Uhr
Usersystemchef
User (201 Beiträge)
das übergeordnete Problem ist eigentlich daß hier ein System (Kombination aus Hard- und Software) eingesetzt wird das vom Design her wohl schon einige Jahre auf dem Buckel hat. Mit MCAS wurde dieses plötzlich verwendet um aktiv in ein Steuer- und Regelsystem in Echtzeit einzugreifen.
Wer schonmal mit "harter Echtzeit" im IT Bereich zu tun hatte weiß daß dort ganz andere Anforderungen an die Systeme gelten als im IT Alltag (alle Funktionen als non blocking ausgelegt, Echtzeit Scheduler, ....).
Für MCAS hätte Boeing eigentlich eine neue Plattform entwickeln müssen.
Beitrag vom 02.07.2019 - 12:57 Uhr
UserA320Fam
User (1359 Beiträge)

Für MCAS hätte Boeing eigentlich eine neue Plattform entwickeln müssen.

Was meinen Sie damit?

MCAS ist nix anderes als eine zusätzliche "Autopilotfunktion", also ja in Echtzeit. Aber auch nicht aufwendiger als jede Autopilotfunktion. Und das Alter spielt hier auch keine Rolle. Das heißt deren eigentliche Umsetzung/Implementierung kann problemlos gestaltet werden.

Was sich hier als kritisch erwies, ist die Einstufung nicht als
Catastrophic und der daraus resultierenden vereinfachten Ausführung, also kein Vergleich von links & rechts mit automatischer Abschaltung bei ungleichen Werten und einem Crew-Alerting, keine Crew-Schulung, eventuelle zu 'scharfe' Grenzbereiche, etc.

Beitrag vom 02.07.2019 - 13:02 Uhr
Usersystemchef
User (201 Beiträge)
beim Autopilot ist das egal ob die Steueranweisung 1-2sek später kommt oder nicht. Wenn man mit TOGA Thrust in nur einigen 1000 Fuß Höhe unterwegs ist und MCAS die Nase Richtung Boden senkt ist es essentiell daß manuelle Eingaben des Piloten in Echtzeit umgesetzt werden.
Sonst endet das sehr schnell in einem Haufen Altmetall.
Beitrag vom 02.07.2019 - 13:15 Uhr
Usersystemchef
User (201 Beiträge)
der Unterschied besteht im Detail, der Autopilot ist ein "Steuerungssystem" das auf Basis von Daten bestimmte Werte setzt für Richtung, Höhe, Geschwindigkeit und dann wieder schlafen geht (bzw nur die Werte auf Änderung überwacht) solange sich daran nichts ändert. Bei manueller Steuerung schaltet sich der Autopilot ab.
Im Gegensatz dazu ist MCAS ein "Regelsystem" das permanent aktiv in die Steuerung eingreift, dazu muß das gesamte System aber verlässich aktuelle Daten liefern und auch innerhalb einer bestimmten Zeit diese Werte liefern. Wenn das MCAS die Nase so lange senkt bis der AoA Wert niedriger ist, dieser schon tatsächlich reduzierte AoA Wert aber erst nach 10 Sekunden beim MCAS Regelsystem ankommt senkt es 10 Sekunden zu lange die Nase.
Beitrag vom 02.07.2019 - 14:47 Uhr
Usermenschmeier
User (620 Beiträge)
Auch ein Autopilot regelt konstant und ich Echtzeit und geht nicht schlafen. Der gleich Kursabweichungen durch Turbulenzen, Windveränderungen, Gewichtsverlagerung im Flugzeug usw aus. Alles an sich ganz kleine Störgrößen, aber diese würden sich summieren.
Ein Mensch würde bei der Arbeit schnell ermüden, ein Autopilot nicht.

Ganz zu Schweigen von Stressreduzierenden Steuerinputs um das Flugzeugleben zu verlängern, wie Load Alleviation, Active Lift Control usw usw.
1 | 2 | 3 | 4 | « zurück | weiter »