Willkommen! Einloggen Ein neues Profil erzeugen

erweitert
Ausschreibung für neue U-Bahnen droht zu scheitern
geschrieben von nicolaas 
Zitat
Mariosch
Zitat
Wutzkman
Kurzum: Am Dilemma der 737 MAX ist nicht ursprünglich die Software Schuld.
Doch, auch - denn mitverantwortlich für die Abstürze war die Tatsache, dass von zwei Angle Of Attach-Sensoren immer nur einer ausgewertet wurde.
Zumindest in einem der beiden Fälle lieferte der von der Software verwendete Sensor leider durch einen Fehler zu hohe Werte, weswegen diese versuchte den angeblich furchtbar steilen Anstellwinkel der Maschine zu korrigieren, der leider gar nicht da war.

Da muss man sich doch die Frage stellen, warum die Piloten das System nicht einfach deaktiviert haben? Sie werden doch sicher bemerkt haben, dass es ungewöhnlich steil nach unten ging ;)

Nun, dass überhaupt nur einer von zwei Angle Of Attach-Sensoren ausgewertet wurde, war einer Weiterentwicklung von Boeing des MCAS geschuldet. Diese Weiterentwicklung wurde durch die FAA mit wesentlich anderen Parametern genehmigt, als sie später im Realbetrieb anzutreffen war. Das allein ist quasi schon kriminell. Aber Boeing hat das MCAS und seine Funktionsweise auch noch den Piloten gegenüber komplett verschwiegen. Wenn du als Pilot von einer Funktion nichts weißt, weißt du natürlich auch nicht, wie man sie deaktiviert. Sie haben also vermutlich durch konventionelles Handeln zu korrigieren versucht, was die Lage möglicherweise noch verschlimmerte.

Durch offene Kommunikation, dass das Flugverhalten sich wesentlich geändert hat, einem ausgiebigen praktischen Pilotentraining und vor allem auch den Hinweis auf die neue Funktionalität hätten die Unglücke möglicherweise verhindert werden können.
Zitat
Wutzkman
Wenn du als Pilot von einer Funktion nichts weißt, weißt du natürlich auch nicht, wie man sie deaktiviert. Sie haben also vermutlich durch konventionelles Handeln zu korrigieren versucht, was die Lage möglicherweise noch verschlimmerte.
Genau und ja - soweit ich weiß, wurde zumindest in einem der beiden Fälle versucht, die Steuerbewegungen des MCAS mit der elektrischen Trimmung zu korrigieren. Und genau das triggert das MCAS erneut. Hätten die Piloten stattdessen auf die manuelle Trimmung zurückgegriffen, wäre es wohl nicht zum Absturz gekommen.
Nur hat denen halt niemand was vom MCAS erzählt, womit ihnen nicht klar war, was los war als das ganze anfing - und dann hat es sich augeschaukelt bis auch die manuelle Trimmung wegen der auftretenden Kräfte nicht mehr benutzbar war.

Zitat
Wutzkman
Durch offene Kommunikation, dass das Flugverhalten sich wesentlich geändert hat, einem ausgiebigen praktischen Pilotentraining und vor allem auch den Hinweis auf die neue Funktionalität hätten die Unglücke möglicherweise verhindert werden können.
Mit Sicherheit.
Aber das hätte vermutlich das Common Type Rating gefährdet, oder zumindest dachte man das wohl. Und das ist eine Menge Wert:wenn die Piloten eh ein komplett neues Type Rating für die MAX bräuchten ist Aufwand für einen Wechsel zu Airbus auch nicht mehr soo viel größer.

Wie immer ist es nicht eine Sache alleine, die für eine Katastrophe ausschlaggebend ist, sondern das unglückliche Zusammenfallen mehrerer Aspekte, die so niemand vorhergesehen hat (im Falle der MAX hätten aber zumindest einige dieser Aspekte vorhergesehen werden müssen).

~ Mariosch
Hab ich schonmal gesagt, dass ich OT-Konversationen liebe? ich habe zig Artikel zu dem Thema gelesen, aber so genau verstanden wie jetzt, hab ich das nie.
Zitat
Henning
Zitat
md95129
Meinst Du sowas?
Henner

Was willst du damit ausdrücken?

Das war nur ein Witz (ein ziemlich guter!)

Der Y2KReady-Aufkleber bezieht sich auf den"Millenium Bug" am Jahreswechsel 1999/2000 (Y2K ist eine modische, nicht ganz korrekte Kurzform von Year 2000, K für "kilo"= mal tausend). Der Millenium Bug konnte auftreten (oder so wurde es befürchtet) an alten Rechneranlagen, die das Datum aus Sparsamkeit nur sechsstellig statt wie heute üblich achtstellig abspeicherten, vom Jahr also nur die letzen zwei Zeichen. "23.02.'99" zum Beispiel. Nach "99" käme wieder "00", und es bestand die Gefahr - oder die Befürchtung - dass einige Rechner dies fälschlich als "1900" anstatt also korrekt "2000" interpretierten. Das hätte zu weitreichenden Problemen führen können, befürchtet wurden Ausfälle ganzer Datenzentren oder sogar der Energieversorgung.

Es wurde eine große Kampagne rund um die Welt gefahren, die Firmen ermutigte, ihre Rechner auf die "Y2K"-Tauglichkeit ("Compliance") zu prüfen, und Aufmerksamkeit für das Thema zu schaffen. Den AUfkleber konnte man sich dann stolz vor die Tür hängen und damit angeben "ja, ich habe mich um meine IT-Sicherheit gekümmert!"

Der Witz ist nun, dass irgendein Scherzkeks diesen Aufkleber an eine Dampflok gepappt hat. Diese stammt der Bauform nach aus dem 19. Jahrhundert, hat also
a) schon einen Jahrhundertwechsel (1899/1900) hinter sich und
b) garantiert keine, aber auch gar keine Informationstechnik oder Elektronik an Bord.

Henner liefert uns damit ein Beispiel einer Maschine, die vollkommen unanfällig gegenüber fehlerhafter Software ist. Das ist logisch und total offensichtlich und deswegen lustig.
Zitat
Mariosch
Software-Tests hätten da auch nicht viel geholfen, wenn das Grundproblem (Ausfall / Defekt des AoA Sensors) erst gar nicht als signifikantes Risiko auf dem Schirm der Ingenieure war.

Software-Tests sollten aber genau sowas abdecken. Und man bekommt das kontrollierten Systemumgebungen auch hin, wenn man Hard- und Software vollumfänglich in der Hand hat.

Die meisten Bugs, die bei uns von Kundenseite her aufschlagen, sind eher darauf zurückzuführen, dass wir nicht jede x-beliebige Hard- und Softwarekombination und erst recht nicht Millionen von Konfigurationsmöglichkeiten und das Zusammenspiel mit einer schier endlosen Anzahl an Drittanbietersoftware durchtesten können.

In einem Flugzeug oder einer U-Bahn hat man solche Probleme erst gar nicht. Da gibt es entweder reine Inselsysteme oder nur eine begrenzte Menge an klar vorgegebenen Drittsystemen, mit denen man kommunizieren muss.
Meiner Meinung nach können hier Probleme nur dann auftauchen, wenn man übermäßig Kosten reduzieren will und daher nicht genug Ressourcen in Konzeption und Tests steckt.

Um vielleicht mal eine Größenordnung zu nennen: Bei uns (Unternehmenssoftware für große Organisationen) kommt auf 2 Entwickler ein QA-Ingenieur. Wir haben mittlerweile auch mehr Zeilen an Software-Tests als an Quellcode (auf eine Zeile Programmcode kommen ca. 5 Zeilen Testcode)
Meine 2 off-topic cents: Die 737 MAX ist im Grunde eine Fehlkonstruktion, da aus Kostengruenden ein nicht passendes Triebwerk an die bestehende 737 angepfriemelt wurde, das die Flugeigenschaften so veraenderte, dass die Software-Hilfskruecke MCAS eingebaut werden musste. Dass die dann noch unzulaenglich getestet/dokumentiert wurde, steht auf einem anderen Blatt.
Zurueck zur U-Bahn: Wie einfach waere es, wenn man die Rahmen-Risse in einigen Fxx Spielarten mit ein paar Zeilen Software wieder zukleistern koennte ;-).
Henner
Zitat
schallundrausch
Hab ich schonmal gesagt, dass ich OT-Konversationen liebe? ich habe zig Artikel zu dem Thema gelesen, aber so genau verstanden wie jetzt, hab ich das nie.

Ich empfehle dir dazu auch diesen Beitrag: [www.youtube.com]

Absolut sehenswert für jeden, der verstehen will, was bei Boeing alles schief gelaufen ist.

EDIT: irgendwie schickt einen der Link immer zu der Stelle, an der ich das Video aus Zeitgründen pausieren musste. Wie kann man das umgehen? Das ganze Video ist sehenswert, nicht erst ab Minute 31.



2 mal bearbeitet. Zuletzt am 06.01.2020 19:15 von hansaplatz.
Bei mir startet es am Anfang.
Zitat
hansaplatz
EDIT: irgendwie schickt einen der Link immer zu der Stelle, an der ich das Video aus Zeitgründen pausieren musste.

Wenn Du das jetzt nicht geändert hast, liegt das vielleicht an den viel zitierten Cookies, die sich merken, bis wann Du das Video schon gesehen hast. Wir anderen bekommen das von Anfang an zu sehen.

Es MUSS ein Hobby sein - leisten kann ich mir das nicht... :)
Zitat
Philipp Borchert
Wenn Du das jetzt nicht geändert hast, liegt das vielleicht an den viel zitierten Cookies, die sich merken, bis wann Du das Video schon gesehen hast. Wir anderen bekommen das von Anfang an zu sehen.

Richtig, wenn Du dagegen unbedingt zu einer bestimmten Stelle verlinken möchtest, einfach hinter den Link noch #t=xmys eingeben, wobei x für die Minuten und y für die Sekunden des gewünschten Zeitpunkts steht...;-)

Gruß
Salzfisch

---
Berlins Straßen sind zu eng, um sie mit Gelenkbussen zu verstopfen!
Hallo zusammen,

solange es zum eigentlichen Thema nichts neues gibt ... warum nicht?

Datumsfunktionen gehören zu den tückischsten Dingen in Software, da der Kalender nicht regelmäßig ist. Das geht schon mit unterschiedlich langen Monaten los, Schaltjahre, usw.

Man braucht Datumsfunktionen aber für die verschiedensten Dinge; sehr häufig, um Zeitspannen zu berechnen. Beispielsweise um aus dem aktuellen Datum und einem zurückliegenden Datum die Einsatzzeit eines Fahrzeugs seit der letzten Untersuchung, das Alter einer Person usw. zu berechnen. Schallundrausch hatte richtig angemerkt, dass man früher oft das Jahr nur zweistellig abgelegt hat, auch um Speicherplatz und Rechenleistung zu sparen. In vielen rechnergesteuerten Systemen wird heute noch Software verwendet, die teils Jahrzehnte alt ist und den damaligen Möglichkeiten entspricht.

Es geht schon allein mit dem Jahreswechsel los. Eine Uhr und einen Kalender zu programmieren, gehört zu den typischen Übungen, mit denen man das Programmieren und das Entwickeln von Algorithmen lernt.

Typischerweise wird nach Ablauf des 31. Dezember 1 (eins) zur Jahreszahl addiert. Aus 1998 wird beispielsweise 1999. Wenn nun aber nur zwei Stellen vorgesehen sind, ist hier ein Jahr später das erste Problem: Das Ergebnis der Addition 99 plus 1 ist 100. Es ist aber bei zwei Stellen nur ein Wertebereich von 0-99 für die Jahreszahl vorgesehen. Es ist keineswegs so, dass dann nach der Addition "00" drinsteht und die 1 automatisch verworfen wird. 100 kann nicht in zwei Dezimalstellen geschrieben werden. So entsteht ein Fehler, der das Programm zum Absturz bringt oder zumindest die weitere Programmausführung verhindert.

Soll nach "99" die "0" folgen, muss man das schon eigens programmieren. Der Algorithmus muss die Jahreszahl vor jeder anstehenden Erhöhung prüfen - ist sie kleiner als 99, addiert man 1, ansonsten schreibt man den Wert 0 hinein. Damit kommt man überhaupt erst mit zwei Stellen über den Jahrhundertwechsel.

Damit ist das Problem aber noch nicht zuende:

Nehmen wir den Fall, man will das Alter einer Person ermitteln. Tag und Monat lassen wir der Einfachheit halber mal weg. Die Person wurde im Jahr (19)74 geboren. Aktuell haben wir (19)99. Wir ermitteln das Alter, indem wir die Jahreszahl des Geburtsjahrs vom der aktuellen Jahreszahl abziehen: 99 minus 74 = 25. Den Tag und Monat außer Acht gelassen, ist die Person also 25 Jahre alt.

So, jetzt haben wir das Jahr 2000, und der Programmierer hat zumindest mal daran gedacht, die Jahreszahl auf "0" zu setzen (siehe oben). Bis hierher funktioniert das Programm also noch. Wir ermitteln nun wieder das Alter. Es müsste jetzt 26 betragen. Tatsächlich rechnet das Programm aber 0 minus 74 = -74. Entweder stürzt es hier ab, weil für das Alter kein negativer Wert zugelassen ist, oder es rechnet mit -74 weiter, was entsprechend zu falschen und unsinnigen Ergebnissen führt.

In diesem Beispiel ist das Problem noch sehr leicht nachvollziehbar. Bei komplexer Software kann es sein, dass sie nicht abstürzt, sondern in der Folge auf Basis des falschen Werts unerwartete Dinge tut und die Fehler in den Ergebnissen möglicherweise auch nur schwer zu erkennen sind.

Weitere Probleme können sich bei der Umrechnung von Dezimalzahlen in das Binärsystem ergeben.

Spannend könnte zum Beispiel das Jahr 2048 werden: Zur Abbildung der Jahreszahlen bis einschließlich 2047 werden im Binärsystem 11 Stellen benötigt, für 2048 dann 12 Stellen.

Viele Grüße
Manuel


Zitat
schallundrausch
Der Millenium Bug konnte auftreten (oder so wurde es befürchtet) an alten Rechneranlagen, die das Datum aus Sparsamkeit nur sechsstellig statt wie heute üblich achtstellig abspeicherten, vom Jahr also nur die letzen zwei Zeichen. "23.02.'99" zum Beispiel. Nach "99" käme wieder "00", und es bestand die Gefahr - oder die Befürchtung - dass einige Rechner dies fälschlich als "1900" anstatt also korrekt "2000" interpretierten. Das hätte zu weitreichenden Problemen führen können, befürchtet wurden Ausfälle ganzer Datenzentren oder sogar der Energieversorgung.
Allerdings wurde auch schon 1975 die Unixzeit eingeführt, die einfach die Sekunden ab dem 1.1.1970 0:00 UTC zählt. Mit einem 32bit signed Integer kommt man damit bis 2038 (und bis 1901 zurück). In moderneren Systemen werden bereits seit langem 64bit-Werte für die Unixzeit verwendet, womit ein paar hundert Milliarden Jahre abgebildet werden können.
Zitat
Mariosch
Zitat
Wutzkman
Wenn du als Pilot von einer Funktion nichts weißt, weißt du natürlich auch nicht, wie man sie deaktiviert. Sie haben also vermutlich durch konventionelles Handeln zu korrigieren versucht, was die Lage möglicherweise noch verschlimmerte.
Genau und ja - soweit ich weiß, wurde zumindest in einem der beiden Fälle versucht, die Steuerbewegungen des MCAS mit der elektrischen Trimmung zu korrigieren. Und genau das triggert das MCAS erneut. Hätten die Piloten stattdessen auf die manuelle Trimmung zurückgegriffen, wäre es wohl nicht zum Absturz gekommen.
Nur hat denen halt niemand was vom MCAS erzählt, womit ihnen nicht klar war, was los war als das ganze anfing - und dann hat es sich augeschaukelt bis auch die manuelle Trimmung wegen der auftretenden Kräfte nicht mehr benutzbar war.

Zitat
Wutzkman
Durch offene Kommunikation, dass das Flugverhalten sich wesentlich geändert hat, einem ausgiebigen praktischen Pilotentraining und vor allem auch den Hinweis auf die neue Funktionalität hätten die Unglücke möglicherweise verhindert werden können.
Mit Sicherheit.
Aber das hätte vermutlich das Common Type Rating gefährdet, oder zumindest dachte man das wohl. Und das ist eine Menge Wert:wenn die Piloten eh ein komplett neues Type Rating für die MAX bräuchten ist Aufwand für einen Wechsel zu Airbus auch nicht mehr soo viel größer.

Wie immer ist es nicht eine Sache alleine, die für eine Katastrophe ausschlaggebend ist, sondern das unglückliche Zusammenfallen mehrerer Aspekte, die so niemand vorhergesehen hat (im Falle der MAX hätten aber zumindest einige dieser Aspekte vorhergesehen werden müssen).

Volle Zustimmung zum gesamten Beitrag! Ich wollte nur anmerken, dass die 737 MAX nicht wegen eines Software"fehlers", oder gar der bösen Digitaltechnik, abgestürzt ist.


Zitat
schallundrausch
Hab ich schonmal gesagt, dass ich OT-Konversationen liebe?

Ich auch! Folglich brauchen wir eine Sparte für Sonstiges. Gibt's da nicht was von ratiopharm?
Das Gericht hat mitgeteilt, dass es sich zu einem Punkt mit den Beteiligten noch einmal mündlich austauschen möchte. Die Verhandlung findet am 17. Februar statt. Insofern werden wir auf eine Entscheidung noch ein wenig warten müssen. Um welchen Punkt es sich handelt wurde nicht mitgeteilt.
Ist die Wahrscheinlichkeit größer, dass Stadler den Auftrag beibehält oder dass die Ausschreibung neu vergeben wird?
Zitat
Henning
Ist die Wahrscheinlichkeit größer, dass Stadler den Auftrag beibehält oder dass die Ausschreibung neu vergeben wird?

Ich schätze, dass Stadler den Auftrag wahrscheinlich bekommt. Würde ich wetten, dann wäre ich bei 8:1...

Aber ich wette nicht!

Gruß Nemo
---

Eine Straßenbahn ist besser als keine U-Bahn!!
Zitat
Nemo
Zitat
Henning
Ist die Wahrscheinlichkeit größer, dass Stadler den Auftrag beibehält oder dass die Ausschreibung neu vergeben wird?

Ich schätze, dass Stadler den Auftrag wahrscheinlich bekommt. Würde ich wetten, dann wäre ich bei 8:1...

Aber ich wette nicht!

Geh hin, finde es raus!

Zitat

Fortsetzungstermin ... bestimmt auf den 17. Februar 2020 um 10:30 Uhr im Saal 265a im Kammergericht
Sicher, dass der Termin öffentlich ist?



1 mal bearbeitet. Zuletzt am 15.01.2020 17:14 von T6.
Zitat
T6
Sicher, dass der Termin öffentlich ist?

Davon ging ich aus, als ich den veröffentlichten Termin las. Aber wissen tu ich wie so oft nix.
Hier steht der Termin: [www.berlin.de]

Von einer öffentlichen Verhandlung steht da nichts. Da steht nur da, dass für Pressevertreter genügend Plätze frei gehalten werden. Makaber finde ich dann den Hinweis dass man sich bitte per Fax voranmelden möchte, da E-Mail nicht möglich ist. Willkommen im Jahr vor der Erfindung des Internets. Fax-Geräte sind ja auch noch so zahlreich verbreitet.



2 mal bearbeitet. Zuletzt am 15.01.2020 23:05 von schenkcs.
Sorry, in diesem Forum dürfen nur registrierte Benutzer schreiben.

Hier klicken, um sich einzuloggen