Warning: mysql_fetch_array() expects parameter 1 to be resource, boolean given in /homepages/18/d506720601/htdocs/_aero_de/pages/forum_posts.php on line 236

Warning: mysql_fetch_array() expects parameter 1 to be resource, boolean given in /homepages/18/d506720601/htdocs/_aero_de/pages/forum_posts.php on line 236

Community / Kommentare zu aktuellen Nachrichten / Boeing meldet neuen Softwarefehler

Beitrag 1 - 15 von 21
1 | 2 | « zurück | weiter »
Beitrag vom 06.02.2020 - 22:51 Uhr
UserPropeller45
User (342 Beiträge)
Habe mir mal dazu den aktuellen Artikel der Seattle Times durchgelesen. Geschrieben wird von neuer Software bzw. aktualisierter Steuerung per Software.
z.B.
"The new software problem complicates Boeing’s efforts to return the Max to service by mid-2020, even if it doesn’t derail the recently extended timetable."
usw., einfach mal lesen.
Meine Frage, ist es wirklich nach wie vor ein ausschließlich per Software-Update zu lösendes Problem?
Mir kommt es immer noch so vor, als wenn auf Teufel komm raus jedwede Hardwareänderung ausgeschlossen wird.
Kann das für eine Rezertifizierung reichen? Auch erinnere ich an den inhaltsschweren JATR-Bericht.

 https://www.seattletimes.com/business/boeing-fixing-new-software-bug-on-737-maxkey-test-flight-nears/
Beitrag vom 07.02.2020 - 08:47 Uhr
UserEricM
User (5455 Beiträge)
Meine Frage, ist es wirklich nach wie vor ein ausschließlich per Software-Update zu lösendes Problem?

Wenn FAA und EASA zustimmen, dass 2 AoA Sensoren und eine darauf aufbauende Vergleichslogik mit Verbindung zu beiden FMS A) ausreichen, um die Ergebnisse zum aktiven Steuern des Flugzeugs um die Querachse zu nutzen und B) im Rahmen der Zulassung der MAX bleiben, dann ja.

Ob jetzt eine Warnlampe etwas zu lange leuchtet oder nicht klingt ja erst mal unkritisch.
Die eigentlich interessante Frage ist aber, was beim Zustand "AoA unreliable", den die Warnlampe wohl anzeigt, außer dem Einschalten der Warnlampe noch passiert.
ZB dass MCAS eigentlich in dem Fall inaktiv sein müsste.
Und dann geht es halt um mehr als eine Warnlampe, nämlich um eine nicht mehr vorhandene Hilfestellung um die Querachse, unerwartet andere Kräfte auf dem Stick gerade in schwierigen Fluglagen, etc.

Da AoA Sensoren, wenn, dann idR final ausfallen, frage ich mich allerdings, wie praxisrelevant die Dauer der Warnung bzw MCAS Abschaltung ist, da sie meist bis zur Landung und Austausch des Sensors Dauer-An zeigen wird...
Denn ein Erkennen eines defekten Sensors ist mit nur 2 Sensoren prinzipiell nicht möglich.

Dieser Beitrag wurde am 07.02.2020 09:48 Uhr bearbeitet.
Beitrag vom 07.02.2020 - 10:26 Uhr
UserNicci72
User (570 Beiträge)
...und täglich grüßt das Murmeltier. Das Gefühl bekommt man, wenn man eine derartige News liest.
Beitrag vom 07.02.2020 - 11:46 Uhr
Usertriangolum
User (273 Beiträge)
Die Frage ist, was zeigt die Lampe an. Es wird ja einen Grund haben.
Beitrag vom 07.02.2020 - 12:35 Uhr
Usersystemchef
User (215 Beiträge)
das Problem ist meiner Ansicht nach immer noch die Flugrechner Hardware. Wenn AoA Werte erst mit 20-30sek Verzögerung eingelesen werden (wegen CPU Überlastung) sind sie halt unreliable. Das wird keine Software der Welt ändern können, die Hardware Architektur ist 30 Jahre alt (286er Generation), für Echtzeit Korrekturen ist das meiner Meinung nach nicht realisierbar. Also entweder die Kiste ist ohne MCAS zertifizierbar und flugtauglich, oder halt nicht.
Beitrag vom 07.02.2020 - 13:30 Uhr
UserMHalblaub
User (750 Beiträge)
Das wird keine Software der Welt ändern können, die Hardware Architektur ist 30 Jahre alt (286er Generation), für Echtzeit Korrekturen ist das meiner Meinung nach nicht realisierbar.

Es ist schon ein Hardware-Problem aber auf den Computer möchte ich dabei nicht zeigen. Die Saturn V hatte einen ziemlich lahmen Computer im LVDC-Ring. Der war aber voll auf die Hardware geeicht. Es gibt da ein gutes Video von Curios Droid. U.a. wird eine Funktion zur Prüfung der Eingangsdaten erwähnt. Weicht der Wert zu stark vom letzten Messwert ab, dann wird dieser verworfen.
Beitrag vom 07.02.2020 - 16:15 Uhr
UserKate Austen
User (549 Beiträge)
wenn das so weiter geht, wird die MAX das wohl best geprüfte und sicherster Flugzeug ever ;-)
Beitrag vom 07.02.2020 - 17:25 Uhr
UserWeideblitz
Moderator
Das wird keine Software der Welt ändern können, die Hardware Architektur ist 30 Jahre alt (286er Generation), für Echtzeit Korrekturen ist das meiner Meinung nach nicht realisierbar.

Es ist schon ein Hardware-Problem aber auf den Computer möchte ich dabei nicht zeigen. Die Saturn V hatte einen ziemlich lahmen Computer im LVDC-Ring. Der war aber voll auf die Hardware geeicht. Es gibt da ein gutes Video von Curios Droid. U.a. wird eine Funktion zur Prüfung der Eingangsdaten erwähnt. Weicht der Wert zu stark vom letzten Messwert ab, dann wird dieser verworfen.

Der Vergleich hinkt stark, da die Systemauslegung zwischen einer Saturn V und der 737 eine völlig andere ist.

Der Flight Computer der 737 wurde erst mit den Classic-Varianten eingeführt. Die Elektronik wurde redundant ausgelegt, indem der Flight Control Computer (FCC) doppelt existiert. Dabei gibt es eine gegenseitige Ausfallüberwachung, sprich fällt der eine FCC aus, übernimmt der andere. Um den Einfluss von Systemfehlern nicht zu verdoppeln, sollten HW+SW verschieden implementiert worden sein. Keine Ahnung, ob dies bei der 737 auch der Fall gewesen ist. Vor jedem Start wird aber jeweils der aktive FCC gewechselt.

Diese Auslegung beruht darauf, dass der Pilot jederzeit die Kontrolle innehat und der FCC lediglich assistiert, aber nicht selbst die Kontrolle übernimmt. Der Speed Trim der 737 NG geht aber schon darüberhinaus, und das MCAS ist mit anderthalb Beinen schon in der Situation, die Verantwortung zu übernehmen und den Piloten ins zweiten Glied zu rücken (ähnlich der Airbus Flight Computer). So etwas kann man machen, bedarf aber weit mehr Rechenleistung, da die FCCs die Eingangsdaten mehrerer Sensoren des gleichen Typs auf Plausibilität überprüfen müssen, als auch eine deutlich aufwendigere gegenseitige Prüfung der FCCs untereinander stattfinden muss.

Das Elektronik-Design der 737-FCCs sind aber dafür nicht ausgelegt. Dass die CPUs dabei auf 80286-Derivaten basieren ist dabei gar nicht das Hauptproblem, wenn halt genügend davon vorhanden wären, was wohl allerdings nicht der Fall ist. Und genau das war auch der Grund, warum die Daten nur eines einzigen AoA-Sensores ausgewertet worden sind. Der FAA wurde ja zunächst ein MCAS basierend auf den 2 vorhandenen AoA Sensoren zur Zulassung vorgelegt, aber dies wurde später wieder auf einen einzigen reduziert als Ergebnis aus den Testflügen- ohne erneute Sicherheitsanalyse unter Einbindung der FAA. Es ist stark zu vermuten, das MCAS deutlich zu langsam reagiert hatte und Boeing ohne größere Eingriffe nicht mehr Performance aus dieser 30 Jahre alten Elektronik herauskitzeln konnte, auch unter Nutzung von Assembler anstatt Hochsprache und unter Aufweichung jeglicher HW-Abstraktion in der SW, was heute selbstredend bei allen moderenen Embedded-Systemen ist.

Nur zum Vergleich: der A320-Flight Computer verwendet wohl einen Mix aus 68000, 80186 und 80386 (zumindest ab A340), sind also auch heute absolut veraltete Halbleiter, aber das ist in der Avionik üblich. Es gibt halt nur mehr Rechenknechte, die den erhöhten Rechenaufwand für die FBW-Realisierung mit deren Flight Control Laws erforderlich sind. Leider kann Boeing auch nicht eine höhergetaktete CPU nehmen, denn es dürfen nur Avionik-zertifizierte CPUs eingesetzt werden. Beim 80286, Ersteinsatz im IBm PC/AT 1984, war bei 16 MHz Ende. Es gab da wohl von Harris noch Avionik-Varianten, die bis 25 MHz gingen, aber das war‘s. Daher könnte Boeings Problem wesentlich größer sein, wenn da nicht noch jemand ein superintelligenten Geistesblitz hatte...und/oder die FAA drückt wieder anderthalb Augen zu. Denn nur so würde ich Dicksons Aussagen deuten, dass eine Rezertifizierung der MAX Mitte des Jahres nicht ausgeschlossen ist.

Mehr Details zu den Hintergründen:
 https://www.moonofalabama.org/2019/06/boeings-software-fix-for-the-737-max-problem-overwhelms-the-planes-computer.html


Dieser Beitrag wurde am 07.02.2020 22:08 Uhr bearbeitet.
Beitrag vom 07.02.2020 - 22:17 Uhr
UserWeideblitz
Moderator
Habe mir mal dazu den aktuellen Artikel der Seattle Times durchgelesen. Geschrieben wird von neuer Software bzw. aktualisierter Steuerung per Software.
z.B.
"The new software problem complicates Boeing’s efforts to return the Max to service by mid-2020, even if it doesn’t derail the recently extended timetable."
usw., einfach mal lesen.
Meine Frage, ist es wirklich nach wie vor ein ausschließlich per Software-Update zu lösendes Problem?
Mir kommt es immer noch so vor, als wenn auf Teufel komm raus jedwede Hardwareänderung ausgeschlossen wird.
Kann das für eine Rezertifizierung reichen? Auch erinnere ich an den inhaltsschweren JATR-Bericht.

 https://www.seattletimes.com/business/boeing-fixing-new-software-bug-on-737-maxkey-test-flight-nears/

Eine größere HW-Änderung würde fast unweigerlich in einer kompletten Neuvalidierung und Zertifizierung der 737 münden, und das wollte und will Boeing unter allen Umständen vermeiden.

Eine solche Nachricht über einen SW-Bug zu einem für das betroffene Unternehmen höchst kritischen Zeitpunkt ist erfahrungsgemäß nur die Spitze des Eisberg, Wenn es wirklich rein um die Ansteuerung einer Lampe gingen würde, dann könnte man den Fix nebst erstem Test innerhalb weniger Stunden durchführen und würde niemals in den Medien so breit getreten. Diese Meldung wurde von Boeings Kommunikationsabteilung weichgespült und damit verharmlost, denn genau das liegt in Boeings Interesse. Als Beobachter von aussen für mich nur noch mehr ein Hinweis (kien Beweis), dass die Problem größer sein könnten. Aber wie gesagt, Dickson hat ja schon Signale der Entspannung ausgesendet - hoffen wir, dass da technisch bereits irgendwo ein Grundkonsens über die Fehlerbehebung zwischen Boeing und der FAA getroffen worden ist und die EASA dem auch zugestimmt hat, sonst...
Beitrag vom 08.02.2020 - 02:22 Uhr
User
User ( Beiträge)
Das wird keine Software der Welt ändern können, die Hardware Architektur ist 30 Jahre alt (286er Generation), für Echtzeit Korrekturen ist das meiner Meinung nach nicht realisierbar.

Es ist schon ein Hardware-Problem aber auf den Computer möchte ich dabei nicht zeigen. Die Saturn V hatte einen ziemlich lahmen Computer im LVDC-Ring. Der war aber voll auf die Hardware geeicht. Es gibt da ein gutes Video von Curios Droid. U.a. wird eine Funktion zur Prüfung der Eingangsdaten erwähnt. Weicht der Wert zu stark vom letzten Messwert ab, dann wird dieser verworfen.

Der Vergleich hinkt stark, da die Systemauslegung zwischen einer Saturn V und der 737 eine völlig andere ist.

Der Flight Computer der 737 wurde erst mit den Classic-Varianten eingeführt. Die Elektronik wurde redundant ausgelegt, indem der Flight Control Computer (FCC) doppelt existiert. Dabei gibt es eine gegenseitige Ausfallüberwachung, sprich fällt der eine FCC aus, übernimmt der andere. Um den Einfluss von Systemfehlern nicht zu verdoppeln, sollten HW+SW verschieden implementiert worden sein. Keine Ahnung, ob dies bei der 737 auch der Fall gewesen ist. Vor jedem Start wird aber jeweils der aktive FCC gewechselt.

Diese Auslegung beruht darauf, dass der Pilot jederzeit die Kontrolle innehat und der FCC lediglich assistiert, aber nicht selbst die Kontrolle übernimmt. Der Speed Trim der 737 NG geht aber schon darüberhinaus, und das MCAS ist mit anderthalb Beinen schon in der Situation, die Verantwortung zu übernehmen und den Piloten ins zweiten Glied zu rücken (ähnlich der Airbus Flight Computer). So etwas kann man machen, bedarf aber weit mehr Rechenleistung, da die FCCs die Eingangsdaten mehrerer Sensoren des gleichen Typs auf Plausibilität überprüfen müssen, als auch eine deutlich aufwendigere gegenseitige Prüfung der FCCs untereinander stattfinden muss.

Das Elektronik-Design der 737-FCCs sind aber dafür nicht ausgelegt. Dass die CPUs dabei auf 80286-Derivaten basieren ist dabei gar nicht das Hauptproblem, wenn halt genügend davon vorhanden wären, was wohl allerdings nicht der Fall ist. Und genau das war auch der Grund, warum die Daten nur eines einzigen AoA-Sensores ausgewertet worden sind. Der FAA wurde ja zunächst ein MCAS basierend auf den 2 vorhandenen AoA Sensoren zur Zulassung vorgelegt, aber dies wurde später wieder auf einen einzigen reduziert als Ergebnis aus den Testflügen- ohne erneute Sicherheitsanalyse unter Einbindung der FAA. Es ist stark zu vermuten, das MCAS deutlich zu langsam reagiert hatte und Boeing ohne größere Eingriffe nicht mehr Performance aus dieser 30 Jahre alten Elektronik herauskitzeln konnte, auch unter Nutzung von Assembler anstatt Hochsprache und unter Aufweichung jeglicher HW-Abstraktion in der SW, was heute selbstredend bei allen moderenen Embedded-Systemen ist.

Nur zum Vergleich: der A320-Flight Computer verwendet wohl einen Mix aus 68000, 80186 und 80386 (zumindest ab A340), sind also auch heute absolut veraltete Halbleiter, aber das ist in der Avionik üblich. Es gibt halt nur mehr Rechenknechte, die den erhöhten Rechenaufwand für die FBW-Realisierung mit deren Flight Control Laws erforderlich sind. Leider kann Boeing auch nicht eine höhergetaktete CPU nehmen, denn es dürfen nur Avionik-zertifizierte CPUs eingesetzt werden. Beim 80286, Ersteinsatz im IBm PC/AT 1984, war bei 16 MHz Ende. Es gab da wohl von Harris noch Avionik-Varianten, die bis 25 MHz gingen, aber das war‘s. Daher könnte Boeings Problem wesentlich größer sein, wenn da nicht noch jemand ein superintelligenten Geistesblitz hatte...und/oder die FAA drückt wieder anderthalb Augen zu. Denn nur so würde ich Dicksons Aussagen deuten, dass eine Rezertifizierung der MAX Mitte des Jahres nicht ausgeschlossen ist.

Mehr Details zu den Hintergründen:
 https://www.moonofalabama.org/2019/06/boeings-software-fix-for-the-737-max-problem-overwhelms-the-planes-computer.html

erstmal vielen Dank für diesen sehr Informativen beitrag.

Rückfrage: Warum sind z.b. Pentium Prozessoren (aller Generationen) nicht zertifiziert bzw. wo ist da der Grund?
Welche Chips nutzen B787 und A350?

Es war ja ein Grund von Elon Musk bei SpaceX das man als Laie immer der Meinung ist in den Fluggeräten sei high tech verbaut, in Wahrheit war z.b. das Space Shuttel technik aus den 60gern ohne großem Elektronik, mit Drehschaltern etc.

Ich verstehe das gesamte Setup nicht, denn es kann heutzutage nicht wirklich an der Rechenleistung scheitern, ein simpler wertevergleich ist egal ob im Assambler selbst oder in einer hochsprache eine ziemlich einfache Operation.
Und bzgl. des 286, das ist ein Design aus den späten 70gern frühen 80gern, heutige Prozessoren liefern zigfaches an rechenleistung. Das muss ja einen vernünftigen Grund haben, warum man da 50 jahre alte Elektronik verbaut.
Beitrag vom 08.02.2020 - 02:33 Uhr
User
User ( Beiträge)
Habe mir mal dazu den aktuellen Artikel der Seattle Times durchgelesen. Geschrieben wird von neuer Software bzw. aktualisierter Steuerung per Software.
z.B.
"The new software problem complicates Boeing’s efforts to return the Max to service by mid-2020, even if it doesn’t derail the recently extended timetable."
usw., einfach mal lesen.
Meine Frage, ist es wirklich nach wie vor ein ausschließlich per Software-Update zu lösendes Problem?
Mir kommt es immer noch so vor, als wenn auf Teufel komm raus jedwede Hardwareänderung ausgeschlossen wird.
Kann das für eine Rezertifizierung reichen? Auch erinnere ich an den inhaltsschweren JATR-Bericht.

 https://www.seattletimes.com/business/boeing-fixing-new-software-bug-on-737-maxkey-test-flight-nears/

Eine größere HW-Änderung würde fast unweigerlich in einer kompletten Neuvalidierung und Zertifizierung der 737 münden, und das wollte und will Boeing unter allen Umständen vermeiden.

Eine solche Nachricht über einen SW-Bug zu einem für das betroffene Unternehmen höchst kritischen Zeitpunkt ist erfahrungsgemäß nur die Spitze des Eisberg, Wenn es wirklich rein um die Ansteuerung einer Lampe gingen würde, dann könnte man den Fix nebst erstem Test innerhalb weniger Stunden durchführen und würde niemals in den Medien so breit getreten. Diese Meldung wurde von Boeings Kommunikationsabteilung weichgespült und damit verharmlost, denn genau das liegt in Boeings Interesse. Als Beobachter von aussen für mich nur noch mehr ein Hinweis (kien Beweis), dass die Problem größer sein könnten. Aber wie gesagt, Dickson hat ja schon Signale der Entspannung ausgesendet - hoffen wir, dass da technisch bereits irgendwo ein Grundkonsens über die Fehlerbehebung zwischen Boeing und der FAA getroffen worden ist und die EASA dem auch zugestimmt hat, sonst...

Je länger das geht desto mehr wird klar wie eng und auf kante genäht die Max eigentlich ist und war.

Boeing muss halt den Balance Akt hinbekommen die Max Flugtauglich zu bekommen ohne eine weitreichende Neuzertifizierung.
Das ist glaube ich auch das Grundproblem mit MCAS - die Max wäre wohl schon sicher, auch ohne MCAS. Aber sie reagiert halt im Überziehverhalten gänzlich anders als eine NG und damit wäre das selbe Type rating einfach nicht mehr zu begründen.
Die Piloten müssten in den Sim und neu gerated werden.
Wobei das auch nur Spekulation ist, denn eine klare Aussage ob die Max ohne MCAS ein sicheres Flugzeug ist gibt es seitens Boeing nicht.
Es ist auch nicht klar warum der Regelbereich von MCAS so erweitert wurde,
das hat Boeing in meinen Augen 0 aufgearbeitet.
Die MCAS Auslegung und das Design muss ja irgendeinen Grund haben, zum Spass werden sie es hoffentlich nicht so radikal ausgelegt haben.

Und das ist auch das verstörrende an der Geschichte - wie groß sind die Auswirkungen der neuen Triebwerke wirklich?
Boeing hat am Ende 0 klaren Tisch gemacht, was darauf vermuten lässt das sich weitere Leichen im Keller befinden.
Denn ab einem gewissen Punkt muss die FAA halt sagen, sorry, geht nicht. Und wenn es die FAA nicht tut, dann eine andere Behörde.
Aber man nehme mal an da sKatastrophenszenario wird wahr, die Max geht nicht mehr in Betrieb, weil das Design einfach überreizt ist.
Was dann?
Dann steht Boeing vor der Wahl, den SA Markt erstmal Airbus zu überlassen, oder die NG wieder zu produzieren, oder eben schnellstmöglich ein NSA zu bringen - das dauert aber min. 5-7 Jahre. Airbus wartet dann gemütlich den Design freeze ab, und setzt 2-3 Jahre später einen Gegner hinten nach.
Boeing muss die Max einfach in die Luft bekommen, sonst ist die Company hin.
Beitrag vom 08.02.2020 - 08:43 Uhr
UserEricM
User (5455 Beiträge)
Und bzgl. des 286, das ist ein Design aus den späten 70gern frühen 80gern, heutige Prozessoren liefern zigfaches an rechenleistung. Das muss ja einen vernünftigen Grund haben, warum man da 50 jahre alte Elektronik verbaut.

Typischerweise Robustheit. Moderne Prozessoren und noch mehr die zugehörigen Speicher sind aufgrund kleinerer Strukturbreiten deutlich anfälliger für Störungen durch Strahlung oder Spannungsschwankungen. Und je höher man fliegt, desto härter wird die einfallende kosmische Strahlung.

Dazu kommt, dass ein typischer FMC wenig Anspruch an die Rechenleistung einer CPU haben sollte. Ich bin daher etwas überrascht von dem Problem mit der angeblichen Rechner-Überlastung, über das ja auch sehr wenig bekannt ist.
Ein paar Sensoren auslesen und Bilschirme anzusteuern ist an sich nichts, was eine alte 286-er CPU überfordern sollte - Inklusive der Plausibilitätschecks mehrerer Sensoren.

Die meisten NASA und ESA Sonden fliegen mit dem Äquivalent von Waschmaschinen-CPUs. Darauf läuft dann nicht nur deren FMC sondern auch das gesamte wissenschaftliche Forschungsprogramm...
Beitrag vom 10.02.2020 - 14:38 Uhr
Usersystemchef
User (215 Beiträge)
Der A320ceo nutzt z.B. eine Honeywell 29KII CPU mit 169 MHz:
 https://aerospace.honeywell.com/content/dam/aero/en-us/documents/learn/platforms/brochures/C61-1647-000-000_ATR_TechnicalSummary_PegasusFMS_Airbus_A330_A320.pdf

die 737NG und 777 eine Motorola 68040 mit 60 MHz:
 http://www.b737.org.uk/fmc.htm



Beitrag vom 10.02.2020 - 16:27 Uhr
UserNur_ein_Y_PAX
User (672 Beiträge)
Rückfrage: Warum sind z.b. Pentium Prozessoren (aller Generationen) nicht zertifiziert bzw. wo ist da der Grund?

Das könnte an der Strukturdichte der Transistoren liegen.
Unterhalb einer gewissen "Grösse" steigt die Empfindlichkeit gegenüber Strahlung deutlich an
was zu falschen Rechenergebnissen oder der Zerstörung des Prozzesors führen kann.

Die Nasa hat z.b. über viele Jahre die Restbestand an 386ern aufgekauft da die Shuttle diesen Prozessor brauchten.

Welche Chips nutzen B787 und A350?


"The avionics will be a further development of the integrated modular avionics (IMA) concept found on the A380. The A350's IMA will manage up to 40 functions (versus 23 functions for the A380) such as undercarriage, fuel, pneumatics, cabin environmental systems, and fire detection. Airbus says benefits will include reduced maintenance and lower weight because IMA replaces multiple processors and LRUs with around 50% fewer standard computer modules known as line-replaceable modules. The IMA runs on a 100-Mbit/s network based on the avionics full-duplex (AFDX) standard, already employed in the A380 instead of the Arinc 429 system on the A330/A340."
 http://www.airbus-a350.com/the-aircraft/cockpit-and-avionics.html


Integrated Modular Avionics (IMA)

Thales’s Integrated Modular Avionics (IMA) solution represents a real-time airborne computer network system. This network consists of a number of computing modules capable of supporting numerous applications of differing criticality levels. The IMA is a major technical evolution of global importance for airlines and operators.

Using new technologies, Thales has standardized and reduced by half the number of CPIOMs (Core Processing Inputs/Outputs Module) and CRDCs (Common Remote Data Concentrator) – both of which are the main building blocks of the IMA suite – meaning that the components are easier to maintain, repair and stock.

The IMA represents a substantial leap along the path to standardization and simplification, and the whole aircraft is set to benefits.
"
 http://www.airbus-a350.com/the-aircraft/cockpit-and-avionics.html

Zum Einsatz kommen MPC755
Siehe Seite 27; Graphik CPU Board.
 http://www.artist-embedded.org/docs/Events/2007/IMA/Slides/ARTIST2_IMA_Itier.pdf


Es war ja ein Grund von Elon Musk bei SpaceX das man als Laie immer der Meinung ist in den Fluggeräten sei high tech verbaut, in Wahrheit war z.b. das Space Shuttel technik aus den 60gern ohne großem Elektronik, mit Drehschaltern etc.

Ich verstehe das gesamte Setup nicht, denn es kann heutzutage nicht wirklich an der Rechenleistung scheitern, ein simpler wertevergleich ist egal ob im Assambler selbst oder in einer hochsprache eine ziemlich einfache Operation.
Und bzgl. des 286, das ist ein Design aus den späten 70gern frühen 80gern, heutige Prozessoren liefern zigfaches an rechenleistung. Das muss ja einen vernünftigen Grund haben, warum man da 50 jahre alte Elektronik verbaut.

Das Problem ist die Struckturgrösse der Dies. Die sind in der Höhe anderen Strahlenbelastungen als auf der Oberfläche ausgesetzt und müssen dennoch ausfallsicherer sein als die PC Kollegen.

Dieser Beitrag wurde am 10.02.2020 16:31 Uhr bearbeitet.
Beitrag vom 10.02.2020 - 20:33 Uhr
Userfbwlaie
User (4870 Beiträge)
Der Softwarefehler bedeutet, dass Boeing nicht ordendlich getestet hat.
Das kann passieren.
Aber worin bestand der Fehler? Gab es ein uunvollständiges Testszenarium oder war die Testhardware ungenügend?
Die FAA dürfte nicht erfreut sein.


1 | 2 | « zurück | weiter »