Vier Tote: Software-Fehler ließ neuen Airbus A400M abstürzen

Software-Fehler können schwerwiegende Konsequenzen nach sich ziehen. Kürzlich kosteten sie vier Menschen das Leben. Der Bug trat in der Steuerung des neuen Airbus-Militärflugzeugs A400M auf, der für Transportzwecke konzipiert ist. mehr... Flugzeug, Airbus, A400M Bildquelle: Airbus Flugzeug, Airbus, A400M Flugzeug, Airbus, A400M Airbus

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Da bekommt "software crash" eine neue Dimension
 
@8oo5: Up- und Downgrade auch.
 
Wäre das Teil von Apple käme jetzt eine Meldung: "Dann Fliegt halt anders!"

Spaß beiseite,... Softwarefehler können genau wie Hardwarefehler immer auftreten. Auch wenn hier es sicherlich 100 mal überprüft wird, KANN eine 100%tige Sicherheit nie Garantiert werden.
Mein Beileid für die Betroffenen.
 
@baeri: Es kommt auch auf die Programmiersprache an, hier wäre z.B. C oder C++ die schlechteste Wahl (manuelle Speicherbereinigung, Länge von Puffern werden nicht geprüft, Überlauf eines Wertebereichs setzt zwar ein Overflowbit im CPU, dieses wird aber nicht von der Hochsprache ausgewertet, etc.). Auch Java und .NET geht hier gar nicht, denn wenn der Garbage Collector einen kritischen Prozess nur wegen der Speicherbereinigung unterbricht ist es auch nicht gut.
 
@basti2k: Das ist in meinen Augen vollkommen unabhängig von der Programmiersprache. Jede Sprache hat ihre Vor- und Nachteile, aber eines haben sie alle gemeinsam: man muss sie verstehen!

Wenn ich sehe, wie viele Entwickler in Unternehmen haben, die nur eine vage Vorstellung von dem haben, was ihr Code macht, läuft es mir kalt den Rücken runter. Meine liebste Frage bei Einstellungsgesprächen ist z.B. "kann man in .NET ein Speicherloch programmieren?". Etwa 95% aller Bewerber antworten auf diese Frage mit einem Nein, was zeigt, dass Sie nicht verstanden haben, wie .NET wirklich funktioniert. Und so ist es bei vielen anderen Sprachen auch. Bei C/C++ z.B. werden immer noch Schweinereien mit einfachen Überbügeln von Datenstrukturen im Speicher gemacht, wohl wissend (oder auch nicht), dass das bei der Weiterentwicklung immer zu Problemen führen kann.

Und dann gibt es da noch das größte Problem: die wenigsten Entwickler testen ihren Code sauber. In vielleicht 15% aller Unternehmen, in denen ich unterwegs war, gehört Unit Testing zum Standard. Die meisten testen immer noch nur manuell oder - man höre und staune - viele Programmteile überhaupt nicht.

Übrigens: der Garbage Collector ist so geschrieben, dass er möglichst wenig invasiv ist. Je nach Konfiguration des GC können Threads sogar während der Collection weiterlaufen und werden nur für sehr, sehr kurze Zeit unterbrochen. In den meisten Fällen sollte das also überhaupt kein Problem darstellen, nicht einmal bei kritischen Prozessen. Allerdings ist .NET, genau wie jede andere managed Sprache, nicht für Echtzeitanwendungen geeignet. Da muss man dann eben doch auf nativen Code zurückgreifen oder, was in den meisten Fällen die beste Lösung ist, auf eine Mischung aus nativem und managed Code.
 
@basti2k: Airbus hat da eher eine eigene Programmiersprache. Ich hatte dort zwar keinen tiefen Einblick was das angeht, aber die ganzen Boardcomputer laufen mit speziellen Prozessoren und einer eigenen Art Betriebssystem. Somit kann ich mir eher nicht vorstellen das sie C++ oder ähnliches verwenden. Ich hatte mal nachgefragt und der meinte es geht eher in Richtung Assembler. Wenn die Aussage stimmen sollte dürfte entsprechende Fehlersuche natürlich auch kompliziert sein.
 
@basti2k:
Ich nehme an, die Steuerung ist in Ada geschrieben.

Meine "Hauptsprache" ist C (nicht C++), aber ich habe auch einige Erfahrung mit Ada, welches für solche Software normalerweise eingesetzt wird.

Um einen Ada-Compiler zu entwickeln, braucht man ca. 50 Mannjahre. Das liegt daran, daß beim Kompilieren bereits Laufzeitfragen geklärt werden. Jeder Datentyp hat strenge Wertebereiche, die nicht überschritten werden dürfen. I.A. ist also ein Ada-Compiler weitgehend auch ein semantischer Prüfkörper.

Ada wird zur Steuerung von Kernreaktoren, Kampfjets und anderen Anwendungen genutzt. Logische Fehler können sich trotzdem einschleichen.
Man kann auch sicheren Code mit C schreiben, aber es ist aufwändiger als Ada. Heute neigen die meisten Leute dazu, Probleme kompliziert statt einfach zu lösen. Da verliert man als Mensch in C schnell den Überblick, aber m.M.n. bei weitem nicht so schnell wie bei so manchen "höheren" Sprachen wie C++, Java, C# usw.

Die einzige Sprache, die mich in den letzten Jahren mehr oder weniger überzeugt hat, ist Go. Trotzdem werde ich bei C bleiben für die meisten Projekte.
 
Schon ein peinliches Schauspiel. Jahre zu spät und dann stürzt der erste von ein paar Flugzeugen schon ab, schlimmer gehts fast nicht mehr. Aber Hauptsache es werden Milliarden für so etwas verbraten und geradestehen wird dafür wohl auch wieder niemand.
 
@dodnet: Naja eher leicht reden. Der A400M ist Technisch schon ein schickes ding und Airbus hat das ding 1000de mal getestet. Nicht nur Airbus hat das ding 1000 mal testet. Aber 100% Sicherheit gibt es leider nicht. Und warum die tolle Bundeswehr immer solange warten muss liegt wohl eher an der Bundeswehr selber. Wer dauernd mit neuen Änderung kommt braucht sich nicht wundern wenn es länger dauert. Ist ja nicht das erste mal das gewissen Herren und Damen vom Bund auf einmal Änderungen haben wollten. Gutes Beispiel NH90.
 
@Fugu3102: ne ne ne das sieht hier aber ganz anders aus. da dieser flieger ein rein europäisches projekt sein soll, ohne den amerikaner, hat sich das alles mehr als unnötig verzögert. bis heute funktioniert der a400m nicht und wird immer noch erprobt, letzter test ging ordentlich schief. und von anfang an hatte der flieger probleme mit den turboprops. das deutschland da mitredet und andere sachen will versteht sich von selbst, schliesslich kriegen die dafür geld vom bund.
 
@Odi waN: Bei den Amis läuft das eh etwas anderes als hier der EU. Dennoch würde ich Airbus nicht alleine die schuld an der Verspätung geben da ja irgendwie die komplette EU plus Raumfahrt Behörden da irgendwie mit dringen hängen. Zudem kommen die Turboprops doch von Rolls Royce.
 
@Fugu3102: nicht nur rolls royce "Rolls-Royce plc, ITP, MTU Aero Engines und Snecma". allein die schuld trägt airbus nicht das ist richtig aber den größten teil, siehe a380 wann er kommen sollte und wann er gekommen ist und bis heute hat er riesige probleme.
 
@Odi waN: Naja ich kenne leider kein Flugzeug was rechtzeitig ausgeliefert wurde und auch keins ohne Probleme. Selbst die 747 von Boeing hat Jahre gebraucht.

Und naja dann gäbe es da noch unseren tollen Eurofighter *schmunzle.

Und mal ganz ehrlich wenn so vor der A380 steht wundert man sich das das ding überhaupt abhebt der Größe.
 
Der kleinste Klempner um die Ecke muss sich heute im Zuge des Qualitätsmanagement zertifizieren lassen sprich abzocken lassen wegen nichts und wieder nichts.
Und dann wird hier von Qualitätsproblemen geredet.
Wenn so was immer und immer wieder passiert, ist doch QM reine Geldmacherei und gehört abgeschafft. Es ging ja auch früher ohne.
Aber wenigstens kam das Ding aus Sevilla und es hat die Spanier getroffen und nicht irgendwen anders.
Mann stelle sich vor das Gerät wäre " made in Germany" , da ständen doch sofort wieder verschiedene Halunken von " Anwälten" vor der Tür mit Milliarden Forderungen.
 
@Trabant: Der A400M ist auch zum teil Made in Germany.
 
SOP in der IT: Wenn Probleme auftreten: Das System herunterfliegen. <_<

Daß Softwarefehler Leben kosten können, sollte bekannt sein - auch aus der Raumfahrt. Hoffen wir, daß nicht einfach an der QA gespart wurde.
 
und genau wegen sowas habe ich das geschrieben bei der anderen News mit dem Flugzeughacker. Ein Bug der bewusst oder unbewusst "aktiviert" wird kann Menschenleben kosten.

Beim Hacker halt teils unbewusst z.B. durch irgendeine änderungen im System und hier ebend durch andere unbewusste wege
 
War ja nur eine Frage der Zeit - Schlagzeile: Tot durch Software!
Aber nachdem für Software ja noch immer keine generelle "Funktionspflicht" oder umfangreiche Prüfstandarts bestehen, werden wohl noch mehr Menschen sterben, bis man endlich begreift, dass auch Software der Produkthaftung unterliegen "muß".
 
@Zonediver: In der Luftfahrt gibt es eine Pflicht zum testen von Software und Hardware. Man darf die Software von Flugzeugen nicht mit der vom Heimischen PC vergleichen. Die Luft und Raumfahrt hat eine Code Abdeckung von fast 100%. Leider weiss man Zuwenig um sagen zu können "das hätte die doch abfangen können durch Tests". Zudem nehmen ich mal an das die nicht nur einfach geradeaus geflogen sind, da werden bestimmt noch anderen Systeme mit einen Rolle gespielt haben. Und eins gilt immer, bis ein Flugzeug runter kommt sind ein menge von verschiedenen dingen schief gegangen.
 
Bugtests bei Flugzeugen kann teuer werden... in jeglicher Hinsicht. Da wäre es vielleicht mal sinnvoll, die Software in einen Simulator reinzuladen, bevor man sie real testet !?!
 
@citrix no.4: Wird es ja auch. Aber es gibt IMMER Fälle, die man in einer Simulation nicht abdecken kann, weil sie A so nicht simuliert werden können oder B schlichtweg unbekannt sind. Bis dieser Fall auftritt, weiß man einfach nicht, was da los ist. Wir hatten zB bei einem unserer Prototypen (Sportwagen) ein Problem bei der Kommunikation zwischen Getriebe und Motor. In der Simulation hat alles wunderbar funktioniert, aber das Problem lag hier dann an einem Fehler in der Vernetzung. Die Botschaft vom Getriebe ist völlig verfälscht beim Motor angekommen (hex->dez). Sowas fällt dann nur auf, wenn jemand später genau über die Messungen schaut und feststellt, dass es Unstimmigkeiten gibt. Fehler können sich immer wieder einschleichen.
 
@bigspid: Ja, ich kenne das bei uns aus der Software-Entwicklung... je komplexer eine Software wird, desto eher verstecken sich irgendwelche Bugs bei Zusammenhängen, die vorher vielleicht nicht auf dem Schirm waren.
 
Militär will es zuerst haben, Militär bekommt Beta, so einfach ist das.
 
@DerGegenlenker: Es ist ein Militärflugzeug, demnach wird es nur das Militär bekommen. Demzufolge logischerweise auch zuerst.
 
Ein Grund wieso Qualität einfach Zeit und Geld kostet, auch wenn es kaum einer wahr haben will.
 
@Fallen][Angel: Genau. Zwischen kostet und darf kosten hat des öfteren nicht nur ein Graben, sondern glatt ein halber bis dreiviertel Grand Canyon Platz.
Aber immerhin liefert die Genehmigungsstelle in solchen Fällen 3 Strickleitern und verspricht in 2,5 Jahren über weitere 1,735 Stück anzuschaffen nachzudenken :-p
 
In vielen Projekten wir SW und die QS dazu oft vom Management falsch beurteilt, auch aus Kostengründen
Hatte selbst mit Staunen festgestellt das Teile der SW-Spezifikation einschliesslich der Prüfumgebung von Unwissenden und völlig unqualifizierten in die Welt gesetzt wurden, war für das Triebwerk und die Steuereinheit
 
Gerade bei grossen Projekten bedarf es einer genauen Planung und ein definiertes Vorgehen. Der Projektleiter muss nicht jede Bit in Detail verstehen und kennen. Er sollte aber besonders die Schwächen der eingesetzten Software , besonders der Hochsprachen, auch der Compiler kennen. SW zu entwickeln ist eine Sache, sie hinreichend zu testen stellt eine andere Herausforderung dar. Gerade SW Entwickler haben ihre Eigenheiten, besonders bei engen Terminen.
In der zivilen Luftfahrt ist es üblich wesentliche Programmteile in 2 Hochsprachen zu generieren und mittels validierten Compilern. Das erhöht die Sicherheit. Das trifft auch für Sub-Routinen welche in einer Maschinensprache eingebunden sind.
Genauere Details kann ich auf Anfrage mitteilen
Kommentar abgeben Netiquette beachten!

Video-Empfehlungen

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.

Folgt uns auf Twitter

WinFuture bei Twitter

Interessante Artikel & Testberichte