10. März 2019: Ethiopian 737 MAX crash

ANZEIGE

ollifast

Erfahrenes Mitglied
04.07.2018
842
0
ANZEIGE
Noch etwas dazu: Es ist m.E. ohnehin keine gute Idee, Funktionen zur Steuerung der Fluglage auf einem Rechner (FCC) laufen zu lassen, der unmittelbar irgendwelche interaktiven Funktionen für Bediener bereitstellt, aber genau das scheint hier der Fall zu sein.

Es ist wie beim Auto: Es gibt z.B. ein ESP Steuergerät, das macht nur ESP. Sonst bitte nichts! Es gibt ein Motorsteuergerät, das macht nur Motor. Und dann gibt es von mir aus ganz viele Prozessoren fürs Kino, die nur alle draußen vor sind, wenn es darauf ankommt, das Fahrzeug sauber zu lenken und zu bremsen. Und auch beim Motor kommt es nicht so gut, wenn die Zündung sporadisch statt vorm Arbeitstakt mitten in den Auslasstakt bei halb geöffnetem Ventil erfolgt, weil der Kunde am Navi rumspielt :D
 

longhaulgiant

Erfahrenes Mitglied
22.02.2015
10.217
9.697
NEIN, das ist nicht zuviel verlangt. Aber es zeigt, wo die Schwächen bei Boeing in der Entwicklung sind.

Warum:
Grundsätzlich gibt es folgende Möglichkeiten, um auch so einen Flugrechner in der Zeitebene in den Griff zu bekommen:

a) Man hat, wie hier schon diskutiert, ein großes Programm, das arbeitet Aufgaben A B C in dieser Reihenfolge ab, dann wieder A B C usw.
Also einfach eine große Schleife drumdrum. Kann man machen, dann muss man allerdings sicherstellen, dass keine dieser Aufgaben übermäßig viel Zeit in Anspruch nimmt, was im Normalfall recht unproblematisch ist, wenn einfach nur ein Sensor Eingangssignal in bestimmten zeitlichen Abständen ausgewertet werden braucht. Beispiel: wenn Eingangsport Trimmschalter gesetzt, schalte Trimmotor ein, sonst aus. Das ist keine weitere innere Schleife, das Zeitverhalten der äußeren Schleife ist damit sicher definiert. Nachteil: Es braucht immer einen Schleifendurchgang, bis reagiert wird, wenn der aber z.B. auf 10 Millisekunden ausgelegt ist, dann ist das bei dem Trimmschalter völlig unproblematisch, so schnell ist der Pilot nun auch nicht.

Eine Sondervariante, die gemäß o.g. Paper von Airbus man dort wohl gerne nimmt: Man hat einen Systemkern, der A, B, C immer zu bestimmten Zeiten fix startet, eine feste Zeitscheibe.

b) Man nimmt das Modell a), hat aber zusätzlich einen sogenannten "Interrupt", wenn irgendetwas ganz zeitkritisches reinkommt. Der unterbricht die A B C Schleife und schiebt D rein. Wird gerne gamacht, aber, dann tut man gut daran, D für eine bestimmte Zeit davon fernzuhalten, nochmal zu unterbrechen. Hardware regelt das. Weil sonst A B C nicht mehr abgearbeitet werden und dann sind wir bei dem Trimmschalter-Thema (btw.: die könnte man auch auf einen Interrupt legen).

c) Man nimmt ein RTOS, ein Real Time Operating System. Das ist im Gegensatz zum normalen PC Betriebssystem eben "real time", d.h. wenn der Interrupt reinkommt, kann man Prioritäten definieren und sagen, so, jetzt C, vor A, weil es etwas neues gibt, hoppla, da war D noch wichtiger, aber jetzt musss auch A zu seinem Recht kommen (ganz vereinfacht).

Der Punkt bei c) ist: Das ist eine tolle Lösung, wenn es auf kurze Latenzen, also Reaktionszeiten, auf Sensoreingaben ankommt. Aber auch da ist sicherzustellen: Kein Sensor darf durch "Wackeln" den ganzen Rechner für sich in Anspruch nehmen (das macht man z.B. mit einer Holdoff Zeit) und natürlich muss der Rechner *insgesamt* genügend Rechenkapazität haben, um alle A B C D in der maximal vorkommenden Rate mit den definierten Holdoff-Zeiten zu erledigen.

Das kann man alles sehr gut ausrechnen und da ist es völlig schnurz, welche Manöver der FAA Pilot fliegt, auch der kann nur Sensor-Input erzeugen. Wenn man es aber - übertrieben gesagt - so programmtechnisch hintrickst, dass die Rechnerleistung gerade mal für eine D Aufgabe jede Minute reicht, und ansonsten bei einem anderen Manöver, bei dem ein paar mehr D anfallen, plötzlich Aufgabe A wie Trimmschalter nicht mehr zeitig erledigt werden, dann ist das Systemdesign schlecht. Entweder ist es notwendig, dass viele D-Aufgaben anfallen können, dann braucht es einen schnelleren Rechner, oder man sagt nach einem D Sensor Input: Ist ok, System hat adäquat sofort reagiert, aber nächste Abfrage erst in 10ms, egal was er meint.

Das ist es, was ich meine, dass da offensichtlich Boeing keinen Überblick über die eigenen Systeme hat, weil wenn man sowas sauber berechnet, dann passiert es einfach nicht, dass der FAA Pilot irgendein irgendwie geartetes Manöver fliegen kann und es zu Problemen kommt.

Ich rede hier ja nicht von komplett formaler Verifikation der Software per Prädikatenlogik etc., alleine, wahrscheinlich wäre man schon mal froh, wenn da einer bei Boeing per Excel-Sheet einfach zu den Aufgaben A B C D die Produkte aus Zeitbedarf und der Rate des maximalen Auftretens je Zeitzyklus addiert hätte und z.B. per Holdoff sicherstellt, dass dem dann in der Praxis auch so ist, und vor allem: Dass die Gesamtrechenzeit für diese Summe ausreicht. Und nicht "das müssen wir irgendwie noch auf den Rechner quetschen, wird schon gutgehen".

Dann kommt es nicht zu so peinlichen Fehlern wie bei dem FAA Piloten.

Wenn es so einfach wäre das auszurechnen hätte es jemand getan. Die Leute bei Boeing sind sicherlich nicht auf den Kopf gefallen.
Viel wahrscheinlicher ist, dass das System sehr viel komplexer ist als wir uns das hier vorstellen. Bei deiner Betrachtung hast du nämlich bspw. völlig außen vor gelassen auf welchen Wegen die Interrupts rein kommen, wie der Prozessor aufgebaut ist, wie lange es dauert den Cache neu zu füllen, wie ist die Ausgangsqueue, etc.
Kommt ein Bus System zum Einsatz kann es sich z.B. am Ausgang stauen. Wird alle Millisekunde umpriorisiert muss der Prozessor ständig neue Daten rein laden. Das dauert für Real Time Anwendungen unter Umständen extrem lange.
Fehler in komplexen Systemen im Vorfeld zu finden ist extrem schwer. Mit einfachen Berechnungen kommt man da nicht weit.
 

ollifast

Erfahrenes Mitglied
04.07.2018
842
0
Wenn es so einfach wäre das auszurechnen hätte es jemand getan. Die Leute bei Boeing sind sicherlich nicht auf den Kopf gefallen.
Abwarten, s.u. :D

Zu den Leuten: Ja, es gibt sicher auch Leute bei Boeing, die derlei sehen. Aber die haben offenbar nix zu melden. Alleine schon die Konstruktion der MAX spricht Bände, und dass es keinen Plan B gibt.

Viel wahrscheinlicher ist, dass das System sehr viel komplexer ist als wir uns das hier vorstellen. Bei deiner Betrachtung hast du nämlich bspw. völlig außen vor gelassen auf welchen Wegen die Interrupts rein kommen, wie der Prozessor aufgebaut ist, wie lange es dauert den Cache neu zu füllen, wie ist die Ausgangsqueue, etc.
Kommt ein Bus System zum Einsatz kann es sich z.B. am Ausgang stauen. Wird alle Millisekunde umpriorisiert muss der Prozessor ständig neue Daten rein laden. Das dauert für Real Time Anwendungen unter Umständen extrem lange.
Fehler in komplexen Systemen im Vorfeld zu finden ist extrem schwer. Mit einfachen Berechnungen kommt man da nicht weit.

Einfach: Mit der Beschreibung von all dem, inkl. Unterschiede preemptive/kooperatives Multitasking usw. wäre mein Posting ja noch länger geworden und keiner hätte es mehr gelesen. Man kann aber überschlagsmäßig die Zeiten berechnen und Reserven einbauen.

Für Dich, da Du offenbar etwas davon verstehst:
- Ich hab mir gerade mal etwas die Mühe gemacht, zu dem Rockwell Collins FCC Tante Google anzustoßen, einige Infos wurden zurückgezogen, aber man findet doch was, z.B. zur NG. Ich hoffe, Dein Stuhl hält:
- Cache: Kannste vergessen, weil:
- Hier das Diagramm des FCC, etwas nach unten scrollen:
https://www.satcom.guru/2018/11/stabilizer-trim.html
Hier eine Info, was der alles machen darf, schon Navigation mit usw.:
Automatics - An illustrated guide to the different MCP's & autopilots used on the 737

Lustigerweise gibt es die gleichen Softwarerevisionen für die NG und MAX, könnte also wirklich der gleiche FCC Typ mit den gleichen Prozessoren sein.

Aus dem Diagramm nachgeschaut, Prozessoren sind:
a) SDP-185 Honeywell, Stand ungefähr um 1990.
b) Zilog (jetzt Littlefuse) Z16C02, dto. letztes Jahrtausend 80/90er.
c) Die Daten kommen offenbar per Direct Memory Access Hardware rein und raus.

Ganz ehrlich: Meine Nase sagt mir, dass das ein Assemblergrab ist. Ich will gar nicht wissen, wie die Software aussieht.

Das Teil war mal dazu da, irgendwelche Nebenfunktionen wahrzunehmen, und jetzt legen sie absolut sicherheitkritische Funktionen darauf.
Man ahnt jetzt auch, warum MCAS so einfach programmiert wurde und wieso so ein Rechner überhaupt mit den paar simplen Sensoraktionen überlastet werden kann. Normal wäre das mit einem auch nur halbwegs aktuellen Controller gar nicht möglich, und da rede ich noch nicht mal von Power PC & Co.

Mir wird da echt ganz anders :eek:

P.s.: Und jetzt wird auch klar, warum da um jede noch so kleine Plausibilitätskontrolle so rumgezerft wird, jede Änderung auch abseits der Zertifizierung offenkundig ein Drama ist: Da tut jeder einzelne zusätzliche Maschinenbefehl weh. Wie man jetzt gesehen hat. Dieser Flight Control Computer ist einfach für das, was man jetzt von ihm verlangt, nicht gebaut und war es auch nie. Das ist die immer-noch-eins-drauf bloß-nix-neu-entwickeln Uralt-Sparlösung.
 
Zuletzt bearbeitet:

thorfdbg

Erfahrenes Mitglied
14.10.2010
3.397
645
Aus dem Diagramm nachgeschaut, Prozessoren sind:
a) SDP-185 Honeywell, Stand ungefähr um 1990.
b) Zilog (jetzt Littlefuse) Z16C02, dto. letztes Jahrtausend 80/90er.
c) Die Daten kommen offenbar per Direct Memory Access Hardware rein und raus.
Steinzeit. Autsch. Wird mit den langen Zertifizierungszyklen in der Luftfahrt zu tun haben. Offenbar hat man vergessen, sich zeitig um eine Neuzertifizierung eines etwas moderneren Systems zu kümmern.

Ich glaube kaum, dass es für die obigen Dampfrechner gute Hochsprachenunterstützung gibt. Wer klöppelt die Software dafür zusammen? Assembler geht so lange gut, so lange die Programme reichlich klein, kompakt und übersichtlich sind, aber die Chancen, da Fehler einzubauen, sind reichlich hoch. Die Leute, die damit groß geworden sind, werden mittlerweile das Rentenalter erreicht haben, und die Leute, die die Teile programmieren können, wird man an der Hand abzählen können. Das ist keine gute Grundlage für die Erweiterung eines Avionik-Systems. "Never change a running system", insbesondere wenn in die Jahre gekommen ist.

Thema Interrupts: Solange sie selten genug sind und keine große Datenabhängigkeit mit dem Rest der Software besteht, ist das keine Geheimwissenschaft. Kommt aber zuviel zusammen, oder sind die Abhängigkeiten zu komplex, sind IRQs eine 1A-Chance, sich ins Knie zu schießen. In Systemen mit kritischem Zeitverhalten sollte man da sehr sparsam von Gebrauch machen.
 

Luftikus

Megaposter
08.01.2010
25.275
11.140
irdisch
Das Flugzeug basiert auf einer alten Zulassung. Es MUSS die Ähnlichkeit zur Original-737 wahren, wie auch schon die NG das musste.
Es hat deshalb keinen Sinn, sich darüber zu echauffieren, dass genau deshalb alte Rechnerhardware mit verbaut ist.
Ob die Software okay ist, steht auf einem anderen Blatt. Gar nicht schön ist, dass nun erst die FAA diesen neuen Fehler entdeckt hat.
 

Langstrecke

Erfahrenes Mitglied
31.08.2013
11.024
10.005
LEJ
Nettes Video. Autsch :rolleyes: Und dass da jeder Dödel auf den Parkplatz zwischen den Flugzeugen rumkurven kann, finde ich schon heftig. Das weckt nicht unbedingt Vertrauen ...

Ich erinnere mich trotzdem gerne an die (friedlichen) Zeiten, an denen es keine Siko gegeben hat, beim ein- oder aussteigen man über das ungesicherte Flugfeld laufen konnte, kein bewaffnete Polizei im Flughafengebäude herum lief (außer wenn ElAl geflogen ist) und es keine verbotene Gegenstände gab. Leider haben sich die Zeiten geändert, weil es ei paar Idioten gibt.

Die Spätgeborenen sehen die Welt halt anders als die Alten und vermuten hinter jedem Vollbart mit Oneway-Ticket einen bösen Menschen (als Synonym).
 
  • Like
Reaktionen: airwalker

ollifast

Erfahrenes Mitglied
04.07.2018
842
0
Das Flugzeug basiert auf einer alten Zulassung. Es MUSS die Ähnlichkeit zur Original-737 wahren, wie auch schon die NG das musste.
Es hat deshalb keinen Sinn, sich darüber zu echauffieren, dass genau deshalb alte Rechnerhardware mit verbaut ist.
Ob die Software okay ist, steht auf einem anderen Blatt. Gar nicht schön ist, dass nun erst die FAA diesen neuen Fehler entdeckt hat.
Der Punkt ist ja nicht, dass alte Rechnerhardware verbaut ist, wenn diese Hardware nur die alten Aufgaben von damals erledigen soll.

Nur haben sie jetzt diese alte Hardware für zusätzliche Aufgaben (MCAS) hergenommen, für die sie weder entwickelt wurde noch jemals von den damaligen Entwicklern je vorgesehen war und für die sie schlicht wegen zu geringer Rechenleistung - wenn man die Plausibilitätstests ordentlich macht - nicht geeignet ist, von anderen dafür fehlenden Sicherheitsfunktionen ähnlich "fly by wire" mal ganz abgesehen.

Erst wird dafür die Software "gekürzt", mit den dramatischen Folgen dieses Threads, dann versuchen sie jetzt wieder, das irgendwie da reinzuquetschen, woraufhin es dem FAA Piloten (und gottseidank erstmal nur dem) Schwierigkeiten macht. Entweder sind die bei Boeing echt nicht besonders lernfähig oder es hat wieder einer aus dem Management mit "schnell schnell schnurzegal" Druck gemacht ?!
 
  • Like
Reaktionen: airwalker

ollifast

Erfahrenes Mitglied
04.07.2018
842
0
Das ist doch einfach nur Wahnsinn, dass das Leben von 200 Menschen da an so einem Codegrab hängt, mit für die Aufgabe völlig unterdimensionierten Uralt-Prozessoren, nur weil die irgendwelche Urgroßvaterrrechte in Anspruch nehmen wollen.

Da sollte man an jedem Flugzeug dieses Musters ein Schild am Eingang anbringen:
"Dieses Fluggerät basiert auf den Sicherheitsstandards von 1970. Wünschen Sie Fortschrittlicheres, dann warten Sie bitte, bis ein Airbus vorbeikommt." :eek: :p
 

ollifast

Erfahrenes Mitglied
04.07.2018
842
0

Krass. Viel Spass mit denen und der Uralt-Hardware, das passt wie die Faust aufs Auge, das ist ja die Traumkombi schlechthin, der Garant für eine schnelle Wiederinbetriebnahme ... :p :sick::censored:

Soso, das sind also die superkompetenten Spezialisten von Boeing, die ja auch nicht auf den Kopf gefallen sind usw. Sind sie auch nicht, wenn sie schon so mies bezahlt werden, dann machen sie genau das, was es braucht, um die AUD $12,80 zu bekommen, und kein Stück mehr. Es ist nicht so, dass es in Indien nicht auch gute Software-Leute gibt, aber nicht für AUD $12,80 (aktuell € 7,94) die Stunde. (n)

Offenbar lernen manche Manager nur durch Schmerzen, bei der FAA hat man offenbar dazugelernt und prüft jetzt gründlicher, bei Boeing muss es wohl noch ein paar Mal das Geräusch des Firmennamens in der Chefetage geben, damit die was kapieren.

P.s.: AUD angepasst, Info Mindestlohn DE: € 9,19/h, Geile Wertschätzung für 737MAX Airline-Kunden, die wieviel gerade noch mal für so eine Mühle zahlen ?
 
Zuletzt bearbeitet:

pfeilstern

Aktives Mitglied
17.09.2016
117
7
  • Like
Reaktionen: ollifast

longhaulgiant

Erfahrenes Mitglied
22.02.2015
10.217
9.697

Sollte das stimmen ist das Management noch viel dümmer als ich bisher angenommen habe. Die im Artikel genannten Erfahrungen (mehrere Runden drehen) decken sich exakt mit meinen Erfahrungen mit gewissen Softwareentwicklern vom indischen Subkontinent. Das liegt einfach an einer völlig anderen Kultur dort. Das wurde mir von einem indischen Bekannten auch mal erklärt woran das liegt. War sehr aufschlussreich. Tatsächlich hatten wir genau einen Entwickler von vieren bzw. später gar von 6 der einen relativ guten Job machte. Und der wurde intern abgestraft weil er die anderen Teammitglieder hat schlecht aussehen lassen. In Deutschland hätte man für außerordentliche Leistung befördert. So krass unterscheidet sich das.
Nun arbeite ich in einer Branche in der keine Menschenleben am Code hängen. Da kann man sowas eine Zeit lang machen - bis man bemerkt, dass es nix taugt (die große indische Firma ist mittlerweile konzernweit auf dem Weg nach draußen).
Bei Boeing hätte man da schon nach kurzer Zeit die Reißleine ziehen müssen. Wenn eine Anforderung nicht nach zwei, spätestens drei Runden formal korrekt implementiert wurde und immer noch offensichtlich(st)e Bugs drin sind dann kann man das in einem sicherheitskritischen Bereich einfach nicht verantworten.
Übrigens ging unsere Performance und Qualität damals auch erst mal steil nach unten als die Kollegen eingestiegen sind. Am Ende eines Entwicklungszyklus konnte oft nicht einmal das System gestartet werden nach erfolgter Integration des neuen Codes. Nur mit einem Kraftakt konnten wir einen Prozess aufsetzen welcher dies unterbunden hat. Danach hat man zwar immer noch sehr viele Runden gedreht aber wenigstens hat einem der Prozess die gröbsten Dinge vom Leib gehalten. Der Schmerz wurde zu den Kollegen nach vorne verlagert was dann das Endergebnis verbessert hat.

Boeing beweist gerade sehr eindrucksvoll warum ein tolles Unternehmen alleine keine gute Investition ist. Wenn das Management nichts taugt wird aus einem tollen Unternehmen ganz schnell ein mittelmäßiges bis schlechtes.
 
T

Txx

Guest

Also langsam schlägt es dem Fass echt den Boden aus, mit so einem Gurkenflugzeug würde ich nicht einen Flug mehr machen Stand jetzt.

Und dass der FAA und nicht Boeing ein Fehler auffällt, zeigt doch nur was für ein Totalausfall da momentan herrscht. Die merken es wohl echt erst auf die Audi-Art, nämlich wenn das Top-Management einwandert. Und genau das ist hier imho fällig, wer augenscheinlich Menschenleben so verachtet...

Ich schreib mal besser nicht weiter, selten so fassungslos gewesen.
 

ollifast

Erfahrenes Mitglied
04.07.2018
842
0
Gar nicht schön ist, dass nun erst die FAA diesen neuen Fehler entdeckt hat.
Was ich halt wirklich nicht verstehe:

Wenn es zu derlei Katastrophe kommt, die alleine schon hunderte Millionen bis vielleicht sogar Milliarden Dollar kostet, dann nimmt man doch zur technischen Lösung die besten technischen Fachleute, die sich überhaupt finden lassen. Und wenn so einer dann eine Millionen Dollar Jahresgehalt einstreicht: Egal, geschenkt. Ist billiger als alles andere. Wird aber eher nicht. Und dann reaktiviere ich die Leute, die damals an der Steuerung gearbeitet haben und setze parallel als Plan B eine Neuentwicklung auf. Kostet Geld: Auch geschenkt. Da kann man den Rentnern zehn Kreuzfahrten hinterherwerfen, es ist alles billiger.

Gute Leute hätten das vor dem FAA Piloten gemerkt.

Aber nein, selbst in so einer Lage: Kaizen durch Gaizen, nur der eigene Bonus des Managers ist wichtig :mad:
 

Luftikus

Megaposter
08.01.2010
25.275
11.140
irdisch
Man müsste erstmal wissen, was genau passiert ist und was der FAA-Mensch im Simulator anders gemacht hat als Boeing zuvor? Ich bezweifle nicht, dass das ein schwerwiegendes, neues Problem sein kann.
 

Brainpool

Erfahrenes Mitglied
15.03.2014
2.801
126
Man müsste erstmal wissen, was genau passiert ist und was der FAA-Mensch im Simulator anders gemacht hat als Boeing zuvor? Ich bezweifle nicht, dass das ein schwerwiegendes, neues Problem sein kann.

Ist doch völlig Schnuppe was da aufgelaufen ist.
Der Vogel soll Fehlerfrei sein
 

ollifast

Erfahrenes Mitglied
04.07.2018
842
0
Man müsste erstmal wissen, was genau passiert ist und was der FAA-Mensch im Simulator anders gemacht hat als Boeing zuvor? Ich bezweifle nicht, dass das ein schwerwiegendes, neues Problem sein kann.

Soweit ich das aus den dürren Infos bisher verstanden habe:

Offenbar wurde die neue Flight Control Computer Software getestet, per Emulation oder sogar realem Rechner. Das neue Programm hat dann wohl die Trimmbefehle über die Schalter am Steuerhorn nicht zeitig übernommen, wenn es von dem FAA Piloten auf irgendeine Art und Weise etwas mehr belastet wurde.

Technisch gibt sich für mich zu den Prozessoren folgendes Bild:
Zum SDP-185 habe ich gefunden:
"is a custom Honeywell-developed 2901-based processor circuit"
( https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19920023534.pdf )
Der 2901 war ein bipolarer 4 Bit Bitslice, das SDP-185 Design soll 16 Bit haben, ergo 4 Slices. Wenn das stimmt mit 2901: Das Ding ist offenbar auf Leiterkartenebene handgebaut, richtig schön mit Mikrocode usw.
Zum Z16C02 gibt es ein Kurzdatenblatt, 10 MHz Takt, 64kByte direkt adressierbarer Speicher, etwas darüber hinaus mit Tricks, Load/Store-Architektur (etwas RISC, kam zu der Zeit auf).

Wenn man das mit einem PC vergleicht: Leistungsmäßig ungefähr Stand 1980 bis 1985.
D.h. bei den Dingern zählt jeder Maschinenbefehl, das Programm dürfte absolut handgestrickt sein.

Vermutlich haben sie deshalb MCAS zunächst *sehr* einfach gestrickt implementiert, halt von Hand ein paar Befehle reingebaut, die den einen AoA abfragen und dann die berüchtigten Timer starten. Geregelt wird da rein garnichts. Wenn Klappen eingefahren und AoA Analogwert größer Konstante, dann setze Zeitgeber-Zähler für x Sekunden und danach Pausenzähler für y Sekunden. Dekrementiere die Zähler und setze den Port für den Motor. Fertig.

So, und nun verlangt die neue Software einiges mehr an Rechnerei, also nicht mehr wenn AoA ADC Wert größer Limit, dann Zählervariable für Timer setzen, sondern einen Vergleich, wozu Daten vom anderen FCC geholt und synchronisiert werden müssen usw. Und jetzt gehen dem Bitslice-Schätzchen halt die Befehle pro Zeitabschnitt aus, weswegen die Eingaben nicht mehr zeitnah verarbeitet werden, so auch die Trimmeingaben.

Der Knackpunkt ist, dass sowas wie MCAS mit Plausibilitätschecks schlagartig mehr Rechenleistung braucht, Filter, Vergleich, Synchronisation, Holdoffs usw. Und wenn man da dann die Truppe vom Subkontinent ranläßt, dann braucht das noch viel viel mehr Rechenleistung, weil die wohl die Tricks nicht kennen werden, wie man den Bitslice ausquetscht.

Hilft nur eines, wenn man nicht mehr riskieren will: Ab damit auf die Isarinsel, ins Deutsche Museum, und Ersatz durch zwei zeitgemäße Mikrocontroller.

Und dann könnte man auch gleich eine saubere Regelung als Flight Envelope Protection implementieren, mit zeitgemäßer Redundanz.
 
Zuletzt bearbeitet:

concordeuser

Erfahrenes Mitglied
01.11.2011
5.755
1.814
Hamburg
Zuletzt bearbeitet:

airwalker

Aktives Mitglied
13.03.2019
240
0
Bereits vor paar Wochen schrieb ich (in meinem ersten forumpost), dass zuviel Zeit vergeht, um die Max wiederzuzulassen.
Alleine die Ankündigung von Boeing bereits Ende 2018 (nach dem Max/Lionabsturz) ohne jegliche Folgehandlung, offenbarte deren „Schachmatt“. Bei einem update hätte die FAA evtl. hingeguckt, was finden können und ein update wäre ohnehin nicht die Heilung gewesen, die Boeing nämlich erklären hätte brauchen.
Also hoffte Boeing auf keinen weiteren Absturz, der jedoch im März erneut mit MCAS im Spiel erfolgte.
Wie ihr hier sehr schön aufzeigt, ist die 737max mit den Triebwerken real so nicht zulassungsfähig und Softwaresteuerungsmankos/Details kommen immer mehr zutage. Was jetzt läuft, ist den Tod von der 737max hinauszuzögern und Verantwortliche versuchen sich noch aus der Schußlinie zu bringen. Da gibt es keinen Neustart mehr, die Boeingmanager haben sich "bewusst" unendlich verzockt.
 
Zuletzt bearbeitet:

ollifast

Erfahrenes Mitglied
04.07.2018
842
0
Wie ihr hier sehr schön aufzeigt, ist die 737max mit den Triebwerken real so nicht zulassungsfähig und Softwaresteuerungsmankos/Details kommen immer mehr zutage.

Die müssten halt die Probleme sauber bereinigen, dann geht das schon. Man kann heute mit moderner Regelungstechnik und genügend Triebwerksleistung sogar ein Scheunentor sicher und stabil zum Fliegen bringen :D

Sie müssten halt den Uralt Flight Control Computer durch was Modernes ersetzen, das auch die Umrechnung der AoA Winkel und Verrechnung mit dem INS bei einer nicht trivialen Anströmung infolge z.B. einer Rolllbewegung problemlos erledigen kann. Dazu können weitere Aktoren nötig sein (Reserve für den Trim usw.). Ceterum Censeo: Flight Envelope Protection. Die Umrechnerei muss man eh machen, wenn man MCAS sauber implementieren will, dazu eine echte Regelung. Der bisherige Ansatz ist und bleibt einfach Schrott.

Man kann heutzutage tatsächlich Leiterkarten designen, auf denen sich, oh großes Wunder, Controller befinden, die millionenfach bewährt sind und bei denen man von Fehlerfreiheit bzw. ganz exakt bekannter Fehlerliste ausgehen kann. Die werden z.B. in Autos im sicherheitskritischen ESP verbaut. Infineon z.B. hat Aurix Tricore mit Lockstep, die sind genau für sowas gemacht. Oder bestimmte ARM Controller (ST, NXP), und auch die TI DSP sind gut. Gibt es. Der für heutige Verhältnisse popelige ARINC 429 Bus läßt sich 1:1 auf SPI auflegen, wenn man weiß, wie man es macht. Und es soll sogar Leute geben, die schnell und sauber derlei programmieren. Mit Autosar und guter Hardware dürfte sich auch die FAA überzeugen lassen.

Der Knackpunkt ist: Boeing macht offenbar immer nur genau soviel, wie sie meinen, minimal machen zu müssen. Da wird jetzt erst MCAS2 in den alten Rechnercode reingemurkst, zuvor haben sie das Uralt-737-Design mit Großvaterrechten hergenommen, dazwischen wird lustig über irgendwelche Subkontinent Truppen entwickelt, die vor allem eines sein müssen, nämlich billig usw.

Das hat jetzt halt auch die FAA gecheckt und die wollen sich halt nicht für Boeing verheizen lassen.

Machbar: Alles. Lösung: Halt nicht Inder unter DE-Mindestlohn bezahlen, sondern "Fussballergehälter" ausrufen, nach Erfahrung. :D

Nur lernen die offenkundig, wenn die Schlamperei so weiter geht, nur mit Schmerzen und als Airline-Kunde täte ich die jeden Tag jeden Morgen und jeden Abend und jeden Mittag und vormittags dazwischen und nachmittags sowieso und vielleicht auch mal nachts beständig kicken :-( und pushen :-( und mindestens drei Dauernervrechtsanwälte direkt am Eingang der Konzernzentrale plazieren, die jeden reingehenden Manager täglich an die Sachlage erinnern :-(, so dass alles vorbei ist. Weil anders funktioniert das offenbar nicht bei den Fürsten derer von Boni zu Shareholder Value. Denen muss man mal klar machen :-(, dass jetzt Stakeholder "Kunde" Value angesagt ist. Und wenn sie das nicht kapieren wollen: Rückabwicklung.
 
  • Like
Reaktionen: globetrotter11

Volume

Erfahrenes Mitglied
01.06.2018
12.713
10.661
c) Man nimmt ein RTOS, ein Real Time Operating System. Das ist im Gegensatz zum normalen PC Betriebssystem eben "real time", d.h. wenn der Interrupt reinkommt, kann man Prioritäten definieren und sagen, so, jetzt C, vor A, weil es etwas neues gibt, hoppla, da war D noch wichtiger, aber jetzt musss auch A zu seinem Recht kommen (ganz vereinfacht).
Wie schon gesagt, in der Luftfahrt nimmt man überhaupt kein Betriebssystem, man schreibt den Code 100% für den Prozessor, denn nur so hat man 100% Kontrolle darüber.
Auch Interrupts vermeided man wegen der Unvorhersagbarkeit. Es ist zwar viel ineffizienter zu pollen, aber selbst ein 68000 oder 80268 ist mit den Berechnungen die er in einem Flugsteuerungscomputer erledigen muss nicht ansatzweise ausgelastet, da kann man sich Ineffizienz als Preis für Verlässlichkeit leisten.
Inwieweit Boeing hier davon abgewichen ist wird man sehen, es wäre jedenfalls zutiefst verwunderlich, wenn sie damit bei der Zulassung durchgekommen wären.

Die moderne Computertechnik mit "smarten" Prozessoren stellt die Luftfahrtindustrie derzeit vor enorme Probleme! Denn der Programmierer hat nicht mehr 100% die Kontrolle über das was der Prozessor so tut.

Es ist wie beim Auto: Es gibt z.B. ein ESP Steuergerät, das macht nur ESP. Sonst bitte nichts! Es gibt ein Motorsteuergerät, das macht nur Motor.

Exakt so macht man es auch in der Luftfahrt, zumindest für die sicherheitskritischen Funktionen. Deshalb hat man ja ein Electronic Compartment in einer Größe wie es sich jede Frau als begehbaren Kleiderschrank wünscht, obwohl die benötigte Rechenpower auch in einen Laptop passen würde...

 

ollifast

Erfahrenes Mitglied
04.07.2018
842
0
Wie schon gesagt, in der Luftfahrt nimmt man überhaupt kein Betriebssystem, man schreibt den Code 100% für den Prozessor, denn nur so hat man 100% Kontrolle darüber.
Es gibt durchaus zertifizierte OS wie SafeRTOS, also Free RTOS mit TÜV Segen:
https://www.highintegritysystems.com/safertos/
Den Quellcode hat man in dem Fall ohnehin.

Das kann durchaus deutlich sicherer sein als das eine große Programm, das in Embedded Systemen gerne genommen wird.
Beispiel: Wenn ein unwichtiger Prozess zuviel Zeit wegnimmt, z.B. wegen eines Programmierproblems oder anderer unvorhergesehener Dinge, geht er auf Hold.

Und Interrupt für Zeitscheibe sollte ok sein (so habe ich auch den Airbus Artikel verstanden).

Die moderne Computertechnik mit "smarten" Prozessoren stellt die Luftfahrtindustrie derzeit vor enorme Probleme! Denn der Programmierer hat nicht mehr 100% die Kontrolle über das was der Prozessor so tut.
Zertifiziert (wie z.B. Infineon) oder selber in VHDL definieren und in Silizium gießen.
Geht aber nicht per Inder, liebe Kinder :D
 
M

Mcflyham

Guest
Ich versteh nicht viel von den technischen Systemem aber TÜV-Segen nützt in der Luftfahrt nichts.