VATSIM Germany Forum

Zurück   VATSIM Germany Forum > Community > Luftfahrt

Luftfahrt Allgemeine Infos und Plauderei rund um die reale Luftfahrt.

Antwort
 
LinkBack Themen-Optionen Ansicht
Alt 2019-04-09, 13:56   #71 (permalink)
 
Benutzerbild von David Kirchner
 
Registriert seit: 2011-06-26
Ort: Bei Frankfurt
Beiträge: 4.950
Danke erteilt: 2.882
4.265 Danksagungen in 2.020 Beiträgen erhalten
Standard

Und wenn eben gerade der AOA-Sensor falsche Daten liefert und das Flugzeug daher denkt, es befinde sich in einem kritischen Zustand? Und unter anderem genau da setzt ja scheinbar die Problembehandlung der Ingenieure an: Es kann nicht sein, dass ein System signifikant in die Steuerung eingreift, seine Daten aber nicht mit einem zweiten oder dritten Sensor gegenprüft - und sich dann auch noch relativ schwer durch die Crew überstimmen lässt.
Zitat:
Bei diesen Geschwindigkeiten duerfte der AoA übrigens sehr gering sein und der relative Fehler IAS zu TAS auch immer kleiner werden. Insofern handelt es sich nicht um einen Stall kritischen Zustand
TAS und IAS folgen unter Einbeziehung des Luftdrucks auseinander - der "relative Fehler" ist diesbezüglich egal. Der vermeintlich nahende Stall folgte aus einem fehlerhaft bestimmten AOA.
__________________
Viele Grüße, David
VATGER ATC-TD Deputy | VATEUD ATC Department Deputy | RG Frankfurt Senior Mentor

RG Frankfurt NAV Chief | P5 Advanced IFR Pilot | Callsign: DLH133

Geändert von David Kirchner (2019-04-09 um 14:04 Uhr)
David Kirchner ist offline   Mit Zitat antworten
Alt 2019-04-09, 19:58   #72 (permalink)
 
Registriert seit: 2008-08-15
Beiträge: 197
Danke erteilt: 0
29 Danksagungen in 21 Beiträgen erhalten
Standard

Siehste, wenn die Software bei 500kts einen AoA von sagen wir … +10° ? als unplausibel eingestuft hätte, würden die Menschen noch leben...Wenn bei 500kts real ein AoA von 10° auftritt brechen die Flügel vermutlich ab, dann wäre eh alles zu spät. Und wenn nicht: Man könnte ja auch an den Holmen die Traglast messen, also per Dehnmessstreifen die Verbiegung (dürfte eh dort verbaut sein), bei +X° AoA und 500mph müsste gemittelt über 2-5Sek. eine SEHR hohe positive Biegebelastung auftreten, die kann nicht exisitiert haben im Sturzflug.
Es gibt zig Möglichkeiten aber die Entwicklung hat halt keine Phantasie oder wird vom Management kurz gehalten, man hat es halt schon immer so gemacht...
Stefan Loos ist offline   Mit Zitat antworten
Alt 2019-04-09, 22:56   #73 (permalink)
 
Benutzerbild von David Kirchner
 
Registriert seit: 2011-06-26
Ort: Bei Frankfurt
Beiträge: 4.950
Danke erteilt: 2.882
4.265 Danksagungen in 2.020 Beiträgen erhalten
Standard

Du willst also Redundanz. Aber genau das wird doch auch passieren. Airbus macht es ja genauso: Die messen alles mehrfach, bei Diskrepanzen schalten sich die entsprechenden Schutzsysteme aus (alternate law). Auch in diesem Fall hätte ein Abgleich mit einem zweiten und evtl. auch dritten AOA Sensor (die existieren glaube ich sogar, wurden nur vom MCAS nicht beachtet) geholfen - vermutlich deutlich genauer, zuverlässiger und einfacher als irgendwelche strukturellen Messungen. Niemand hier behauptet, dass Boing und die FAA da keinen rieseigen Mist gebaut haben, deine Vorschläge würden aber größtenteils nicht funktionieren, bestenfalls wären sie extrem umständlich dafür, dass sie sehr unpräzise Daten liefern würden.

Wie Dominik schon schrieb: Gäbe es auch nur minimal bessere Möglichkeiten, Fluglagen und die Bewegung relativ zu Umgebungsluft zuverlässig zu messen, wäre das schon längst in allen Flugzeugen Pflicht.
__________________
Viele Grüße, David
VATGER ATC-TD Deputy | VATEUD ATC Department Deputy | RG Frankfurt Senior Mentor

RG Frankfurt NAV Chief | P5 Advanced IFR Pilot | Callsign: DLH133
David Kirchner ist offline   Mit Zitat antworten
Alt 2019-04-10, 10:39   #74 (permalink)
 
Registriert seit: 2008-08-15
Beiträge: 197
Danke erteilt: 0
29 Danksagungen in 21 Beiträgen erhalten
Standard

Ist es jetzt eigentlich gültig für eine Zulassung nur einen, nicht redundanten Sensor für den AoA an Board zu haben? Da stimmen doch in der Tat die Vorschriften nicht??
Stefan Loos ist offline   Mit Zitat antworten
Alt 2019-04-10, 11:34   #75 (permalink)
VATSIM Germany PTD-TD Chief
 
Registriert seit: 2009-10-20
Ort: EDVE / EDDH
Alter: 25
Beiträge: 7.191
Danke erteilt: 5.443
4.964 Danksagungen in 2.569 Beiträgen erhalten
Standard

Zitat:
Zitat von Stefan Loos Beitrag anzeigen
Ist es jetzt eigentlich gültig für eine Zulassung nur einen, nicht redundanten Sensor für den AoA an Board zu haben? Da stimmen doch in der Tat die Vorschriften nicht??
Die 737MAX hat ja (laut den Berichten, die aktuell kursieren) eigentlich zwei AoA-Sensoren, von denen aber wohl nur jeweils einer vom MCAS verwendet wird (und zwar immer abwechselnd bei jedem Flug entweder der linke oder rechte Sensor). Da die Auswirkungen eines MCAS-Fehler ursprünglich als "hazardous" eingestuft wurden (unter der Annahme, das MCAS nur 0.6° trimmen darf, was aber später auf 2.5° erhöht wurde), wäre das nach CS 25.1309 theoretisch zulässig, wenn man die Fehlerwahrscheinlichkeit auf unter 10^-7 pro Flugstunde bekommt, was aber mit nur einem AoA-Sensor kaum möglich sein dürfte. Mit der Erhöhung auf eine Trimmänderung von 2.5° wurde der MCAS-Fehler aber klar als "catastrophic" eingestuft (und diese Klassifizierung wurde durch die beiden Abstürze auch eindrucksvoll bestätigt), so dass nach Cs 25.1309 die Fehlerwahrscheinlichkeit bei unter 10^-9 pro Flugstunde liegen muss und kein "Single-Point-Of-Failure" existieren darf. Also selbst, wenn man einen so zuverlässigen AoA-Sensor bauen könnte (was aber schon völlig unrealistisch ist), wäre das trotzdem nicht zulässig, ein System mit einem solchen möglichen Fehlerfall zu konstruieren. Die Vorschriften sind also soweit schon sinnvoll - nur wurden diese hier eben nicht eingehalten und das auch von den Behörden nicht ausreichend kontrolliert.

Randnotiz: Schau doch mal, ob du mit deiner "Wasserwagen-App" auch nur ansatzweise in die Nähe der oben genannten Ausfallwahrscheinlichkeiten kommst. Und zwar nicht unter Laborbedingungen, sondern unter realen Einsatzbedingungen der Flugzeugsensoren mit entsprechenden Beschleunigungen, Temperaturschwankungen (inkl. Vereisung) etc. Und dann überlege dir mal, wie vielen Tests du dein System dann unterziehen musst, um der Behörde eine Ausfallwahrscheinlichkeit von unter 10^-9 pro Flugstunde nachweisen zu können. Es ist schon richtig, dass für das MCAS zusätzliche Redundanz von Anfang an sinnvoll gewesen wäre, aber die von dir genannten einfachen Ideen funktionieren eben in der Praxis doch nicht so einfach, wie du dir das vorstellst (wurde ja von meinen Vorrednern auch schon erklärt). Und das ist kein Management-Problem - ganz im Gegenteil: Eine Vielzahl von Zwischenfällen in den vergangenen Jahren ist auf eine Kombination aus z.B. "Unreliable Airspeed" und daraus resultierendem "Pilot Error" zurückzuführen, also besteht natürlich ein sehr großes (auch wirtschaftliches) Interesse daran, die Messtechnik im Flugzeug zu verbessern. Auch hier bei uns im Institut startet demnächst wieder ein Projekt, das sich unter anderem auch mit diesem Thema beschäftigt (wo ich auch dran beteiligt sein werde). Das Interesse ist also durchaus vorhanden, das Forschungsgeld auch - aber das ist eben unter den gegebenen Randbedingungen technisch nicht so einfach umzusetzen.

Außerdem die Bitte an dich, hier mit etwas mehr Bescheidenheit und Sachlichkeit aufzutreten. Es ist völlig in Ordnung und auch ausdrücklich erwünscht, kritisch zu hinterfragen, ob etwas wirklich so gemacht werden muss. Ebenso ist es völlig in Ordnung, wenn du mit den technischen und physikalischen Hintergründen nicht so gut vertraut bist - es hat ja jeder hier einen anderen (nicht nur beruflichen) Hintergrund und kann daher auch unterschiedliche Perspektiven beisteuern. Aber auch schon an anderer Stelle sind deine physikalisch falschen, aber dennoch mit einer gewissen Arroganz dargestellten Äußerungen (nicht nur mir) sehr negativ aufgefallen. Natürlich kann man mal daneben liegen, insbesondere wenn man nicht über das entsprechende Hintergrundwissen verfügt, und dafür ist ja ein Forum auch da, um dann auf einer sachlichen Ebene darüber zu diskutieren und Fragen zu klären, so dass jeder was draus lernen kann. Aber die Art und Weise, wie du hier deine Aussagen darstellst, erschwert eine sachliche Diskussion unnötig (und setzt dich selbst nebenbei auch in ein schlechtes Licht), daher die Bitte, auch in deinem eigenen Interesse etwas mehr darauf zu achten, mit welchem Tonfall du hier unterwegs bist.
__________________
Leiter des PTD von VATSIM Germany || P5-Pilot und C1-Controller RG Bremen || vRNLAF vCVW-6 Head of Standardization, VFA-14 CO
Andre Koloschin ist offline   Mit Zitat antworten
Alt 2019-04-10, 12:35   #76 (permalink)
 
Registriert seit: 2008-08-15
Beiträge: 197
Danke erteilt: 0
29 Danksagungen in 21 Beiträgen erhalten
Standard

Danke für die Erläuterungen.
Wie wird eigentlich eine Software Funktion zugelassen bzw. In Ihrer Qualität und Robustheit bewertet? Ich meine 10^-7 pro FH klingt für mich sehr klassisch als Maßstab für mechanische und elektronische Bauteile, aber was ist mit Software?
Stefan Loos ist offline   Mit Zitat antworten
Alt 2019-04-10, 12:55   #77 (permalink)
VATSIM Germany PTD-TD Chief
 
Registriert seit: 2009-10-20
Ort: EDVE / EDDH
Alter: 25
Beiträge: 7.191
Danke erteilt: 5.443
4.964 Danksagungen in 2.569 Beiträgen erhalten
Standard

Für Software gibt es den sogenannten "Development Assurance Level" (oder auch "Design Assurance Level" genannt) - abgekürzt "DAL", wobei DAL-A angewendet wird, wenn eine Fehlfunktion als "catastrophic" klassifiziert wird, DAL-B bei "hazardous" usw.
Details dazu sind in der DO-178C definiert. Für einen groben Überlick ist der englische Wikipedia-Artikel schon ganz gut geeignet: https://en.wikipedia.org/wiki/DO-178C
__________________
Leiter des PTD von VATSIM Germany || P5-Pilot und C1-Controller RG Bremen || vRNLAF vCVW-6 Head of Standardization, VFA-14 CO
Andre Koloschin ist offline   Mit Zitat antworten
Alt 2019-04-15, 14:06   #78 (permalink)
 
Benutzerbild von Lukas Ewald
 
Registriert seit: 2006-12-07
Ort: Karlsruhe
Alter: 27
Beiträge: 4.246
Danke erteilt: 2.495
5.046 Danksagungen in 1.686 Beiträgen erhalten
Standard

Hier gibts einen recht detailierten Blick auf die Daten des FDR: http://visualapproach.io/et302-even-...nxInQiglL-A02s
__________________

Lotse RG Frankfurt - www.vatsim-germany.org | Pilot Leipzig Air - www.leipzigair.eu
Lukas Ewald ist offline   Mit Zitat antworten
Alt 2019-04-15, 20:36   #79 (permalink)
 
Benutzerbild von Johann Schuhwerk
 
Registriert seit: 2011-07-23
Beiträge: 954
Danke erteilt: 1.293
961 Danksagungen in 442 Beiträgen erhalten
Standard

Zitat:
Zitat von Stefan Loos Beitrag anzeigen
Danke für die Erläuterungen.
Wie wird eigentlich eine Software Funktion zugelassen bzw. In Ihrer Qualität und Robustheit bewertet? Ich meine 10^-7 pro FH klingt für mich sehr klassisch als Maßstab für mechanische und elektronische Bauteile, aber was ist mit Software?
Auch für Software gibt es Anforderungen an die "Funktionale Sicherheit". Aus persönlichem Erleben weiß ich jedoch, dass viele Softwareentwickler nur bessere Codehacker sind und mit so "überflüssigem Krimskrams" wie Anforderungsentwicklung, Architekturentwurf, -verifizierung und -validierung und den äquivalenten Schritten beim Design wenig zu tun haben wollen. Die testen halt den fertigen Code, und wenn es nicht klappt, dann wird nachgebessert. Aus Qualitätssicht ist das maximal die Stufe "Qualitätssicherung", sprich, testen, aussondern oder reparieren und zurück nach vorne melden. Über so was "mechanischem" wie Qualitätsmanagement, also Fehlervermeidung (statistisch nachgewiesen ist das sogar kostengünstiger!) durch vorgeschaltete Aktionen wie FMEA, FTA usw. sind sie erhaben, denn "bei Software ist das anders". Obwohl es DO-178C oder z.B. die europäische ED-153 (für Flugsicherungssoftware) gibt, mit SIL, DAL, SWAL und wie die ganzen Levels heißen.

Selbst dass man die Softwaretests eigentlich validieren müsste, um sicherzustellen, dass die Fehler auch entdeckt werden, kapieren eine ganze Menge dieser "Profis" nicht. Wenn ich das beim Audit gefragt hatte, kam oft entweder Unverständnis oder eine andere, unpassende Reaktion.

Im Gegensatz zu M$-Software kann man allerdings IMHO Software, bei der die "Funktionale Sicherheit" gewährleistet sein soll, nur dann "gegen Entgelt beim Kunden reifen lassen", wenn man ein gehöriges Maß an Rücksichtslosigkeit gegenüber dem Leben Anderer hat. Aber vielleicht ist das der Preis, den manche Teile der Gesellschaft für "Immer schneller immer mehr Neues" zu bezahlen bereit sind.

Und wer glaubt, dass die Situation bei Softwareunternehmen, die nach ISO 9001, 9100 usw zertifiziert sind, besser ist - einfach auf die andere Seite drehen und weiterträumen.

2ct
__________________
VATEUD CPT Pilot


Geändert von Johann Schuhwerk (2019-04-16 um 17:55 Uhr) Grund: Linksschreibung korrigiert
Johann Schuhwerk ist offline   Mit Zitat antworten
Alt 2019-04-16, 22:02   #80 (permalink)
 
Registriert seit: 2008-08-15
Beiträge: 197
Danke erteilt: 0
29 Danksagungen in 21 Beiträgen erhalten
Standard

Papier/Normen beschreiben halt bestenfalls Qualität, schaffen aber keine. Am Ende hängt es von dem Willen und Fähigkeiten der Menschen ab ob in sehr komplex vernetzten Systemen Fehlverhalten erkannt werden - Stichwort Phantasie, auch in Bezug auf Testscenarien , also dem Willen ein System an die Wand zu fahren. Kein Papier kann das!
Stefan Loos ist offline   Mit Zitat antworten
Danksagungen
Antwort

  VATSIM Germany Forum > Community > Luftfahrt


Themen-Optionen
Ansicht

Forumregeln
Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are an



Alle Zeitangaben in WEZ +2. Es ist jetzt 15:59 Uhr.


Powered by vBulletin® Version 3.8.4 (Deutsch)
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
Template-Modifikationen durch TMS
© 2006 - 2018 vatsim-germany.org