Münchener "Avenio"-Bahnen stillgelegt

  • Die SZ berichtet, dass die Technische Aufsichtsbehörde die 8 neuen Siemens-Züge der MVG vom Typ AVENIO stillgelegt hat. Eine vorläufige Betriebserlaubnis, die Ende Juli 2015 auslief, sei nicht erneuert worden. Und wieder trifft es Siemens.


    Aber lest selbst: klick

  • ....wenn man nicht Softwarebomben bauen würde wäre es viel einfacher mit der
    Zulassung.....feste Verdrahtung lässt sich leichter prüfen...
    ...und dann wird auch am Simulationsrechner der Aufbau so knapp wie es geht
    berechnet, damit man ja kein Gramm zu viel an Metall verbaut....

    In god (an invention by mankind) we trust - on earth we don't


    Sincerly yours, NSA
    powered by US government

  • http://www.br.de/nachrichten/o…etriebserlaubnis-100.html


    Der Grund sind wohl fehlende Handbücher. Langsam merkt wohl auch die Politik, dass die dortige TAB unverhältnismäßig streng agiert. Bei allen Projekten der letzten Jahre gab/gibt es massive Probleme mit der Zulassung: Variobahn, C2 und Avenio. Wenn unsere Aufsichtsbehörde so streng wäre, wären die U5-Wagen mit der aktuellen Türproblematik wohl längst aus dem Verkehr gezogen worden.

    Gebenedeit sei dieses Forum.

    Einmal editiert, zuletzt von Don Bosco ()

  • Irgendwie hat München kein Glück mit neuen Bahnen. Probleme gab es ja schon mit der Variobahn. Wenn allerdings die Aufsichtsbehörde unverhältnismäßig streng agiert, kann man den Herstellern allein keinen Vorwurf machen.


    Bin mal gespannt, wie es weitergeht. Auf lange Sicht jedenfalls dürfte die MVG allmählich die Lust verlieren, neue Schienenfahrzeuge zu kaufen. Also müssen die Fahrgäste sich dann eben langfristig mit den R- und den A- und B-Wagen begnügen.


    Da das Ganze ja wahrscheinlich bis nach den Sommerferien andauert, kommen dann wieder (mehr) P3/p3-Kurse zum Einsatz?

    Viele Grüße, vöv2000


  • ....wenn man nicht Softwarebomben bauen würde wäre es viel einfacher mit der Zulassung.....feste Verdrahtung lässt sich leichter prüfen......und dann wird auch am Simulationsrechner der Aufbau so knapp wie es geht berechnet, damit man ja kein Gramm zu viel an Metall verbaut....


    Klar, du würdest wohl auch noch mit einer Pferdekutsche Fahrgäste befördern oder dich mit deinem festverdrahteten Rechner ins Internet einwählen... 8o :rolleyes:



    Irgendwie hat München kein Glück mit neuen Bahnen. Probleme gab es ja schon mit der Variobahn. Wenn allerdings die Aufsichtsbehörde unverhältnismäßig streng agiert, kann man den Herstellern allein keinen Vorwurf machen.


    Abgesehen vom Sorgenkind Variobahn hat man in München nur die Probleme mit der Technischen Aufsichtsbehörde der Regierung von Oberbayern und das ist an Absurditäten gar nicht mehr zu überbieten! Die C2-Züge können beispielsweise nicht zugelassen werden, weil der praktische Nachweis mit unversehrten Styropor-Klötzchen für die Profilfreiheit nicht ausreichend ist. Die TAB fordert Gutachten, die auf Grundlage von Berechnungen bestätigen, dass der Zug im ganzen U-Bahnnetz bedenkenlos einsetzbar ist.




    Bin mal gespannt, wie es weitergeht. Auf lange Sicht jedenfalls dürfte die MVG allmählich die Lust verlieren, neue Schienenfahrzeuge zu kaufen. Also müssen die Fahrgäste sich dann eben langfristig mit den R- und den A- und B-Wagen begnügen.


    Du hast die C-Züge vergessen... ;)

    X
    X
    X

  • Langsam merkt wohl auch die Politik, dass die dortige TAB unverhältnismäßig streng agiert. Bei allen Projekten der letzten Jahre gab/gibt es massive Probleme mit der Zulassung:

    Diese Behörde ist doch der Regierung unterstellt. Es erscheint mir sehr unwahrscheinlich, dass man erst nach Jahren ständiger Probleme in München darauf aufmerksam geworden sei.


    Außerdem kann ich mir nicht vorstellen, dass das, was man nach außen vielleicht als "Strenge" verkauft, intern einfach so aufgegriffen wurde. Das muss doch von jemandem vorgegeben worden sein.

    Der Grund sind wohl fehlende Handbücher.

    In dem Artikel steht, dass die Behörde auf gedruckten Unterlagen bestand. Da gibt es doch nur zwei Möglichkeiten: Entweder die Behörde arbeitet noch genau so analog wie vor vierzig Jahren oder es ist pure Absicht.


    Bei diesen ganzen Dingen, die hier in Deutschland als "Zulassung" verkauft werden, frage ich mich zumindest schon seit sehr langer Zeit, was damit eigentlich bezweckt werden soll. Würde man sich bei anderen Bereichen so anstellen wie bei den Schienenfahrzeugen, gäbe es bestimmt weniger Autos auf den Straßen und Flugzeuge am Himmel. Vermutlich ist dort einfach die Lobby größer und es besteht daher nicht so viel politischer Einfluss.


    Dieser Unsinn ist ja nicht nur auf die Fahrzeuge selbst beschränkt. Bei allen Aspekten, die zum Bahnbetrieb dazu gehören, gibt es diese Auswüchse.


    Vor Allem frage ich mich, wie sich die Beteiligten bei den Herstellern der Fahrzeuge vorkommen müssen. Deren Fahrzeuge fahren auf der ganzen Welt und ausgerechnet für München (im Speziellen) oder Deutschland (im Allgemeinen) sollen sie nicht sicher genug sein?


    Bei den neuen U-Bahnen heißt hingegen es, dass man nicht wisse, ob sie in die Tunnel passen. Wo anders probiert man die Profilfreiheit einfach aus. Hier scheint es eine Mammutaufgabe zu sein hochwissenschaftliche Berechnungen dafür anzustellen. Komisch ist nur, dass in Berlin damals angeklebte Abstandshalter gereicht hatten.


    Wenn man eingreifen würde bevor etwas passiert weil man von einer für die Sicherheit kritischen Sachlage erfährt, hätte sicherlich jeder Verständnis. Hier wird aber permanent zu Beginn eingegriffen und dies wird mit Sicherheitsbedenken zu begründen versucht - und zwar meist bevor der Betrieb überhaupt aufgenommen wurde, ober aber wie in diesem Fall nach bereits monatelangem Betrieb. Dies ist in jedem Falle absurd.


    Dabei ist die Überlegung doch eigentlich ganz einfach: Der Hersteller hat doch das ureigene Interesse sichere Fahrzeuge zu bauen. Er will schließlich nicht für Unfälle haften, die auf mangelnde Produkte zurückzuführen sind.

  • Ahm....ja....naja....


    https://de.wikipedia.org/wiki/CitySprinter
    (man muß es aber auch hinbekommen)


    Ich habe das Gefühl, dass du die Probleme mit der TAB in München nicht richtig verstehst und einfach nur hartnäckig versuchst, moderne Schienenfahrzeuge in ein schlechtes Licht zu rücken. Hast du den von dir verlinkten Artikel überhaupt selbst durchgelesen? Da ist die Rede von menschlichem Versagen, das letzten Endes zu diesem Unfall geführt hat.

    X
    X
    X

  • [In dem] von dir verlinkten Artikel […] ist die Rede von menschlichem Versagen, das letzten Endes zu diesem Unfall geführt hat.


    Das ist, entschuldigung, Unsinn. In dem Artikel steht:


    Während der Fahrt fiel die elektronische Fahrzeugsteuerung aus. Wegen der Notbremsüberbrückung funktionierte auch die Notbremse im Fahrgastraum nicht, die ein Techniker gezogen hatte.

    Da steht dann auch, dass der Fahrer dieses technische Versagen durch eine bestimmte Handlung hätte auffangen können, aber das menschliche Versagen in dieser durch das technische Versagen ausgelösten Notsituation hat nicht zu dem Unfall geführt.


    Ansonsten könntest du bei jedem Unfall den Fahrer verantwortlich machen; hätte der Tf schon einen Km vorher gebremst, wäre er nicht in den LKW reingefahren auf dem BÜ (nur um das klar zu machen: es geht hier um eine Handlung, mit der der Tf den Unfall verhindert hatte. Wie im CitySprinter-Fall klammere ich hier völlig aus, ob der Fahrer das hätte tun sollen / dürfen / müssen - darüber steht nämlich nix im Wiki-Artikel. Falls du andere Infos hast, her damit). Ich glaube nicht, dass wir dahin kommen sollten.

  • Man sollte auch mal sehen wieviel Zeit bei einem Totalausfall einem bleibt überhaupt alles durchzuprobieren:
    S-Bahn-Tunnel - fällt dort an einem "Halt Erwarten" die Bremssteuerung aus, dann hängt man nach etwa 15-20
    Sekunden im Heck der Zuges vorweg (wenn deiser ein Langzug ist).
    Wenn eine Kiste nicht bremst ist man richtig in Panik und unter Streß (da wird es mit dem strukturierten
    Denken schwierig)....da sind 15 Sekunden schnell durch!


    >einfach nur hartnäckig versuchst, moderne Schienenfahrzeuge in ein schlechtes Licht zu rücken


    Ich verstehe aber etwas über die Komplexität von Hardware/Software/Netzwerken
    Schau dir mal diesen Artikel an:
    https://de.wikipedia.org/wiki/Softwarekrise


    Oder mal als Beispiel - der 80386 ist 1985 auf den Markt gekommen (vor 30 Jahren!).
    Hier kannst Du sehen wieviele Fehler alleine in diesem Prozessor stecken:
    http://ps-2.kev009.com/madmax/…iles/cpudata/27287401.pdf
    Und dieser hatte "nur" 275000 Transistoren.
    Der FDIV-Bug sollte auch bekannt sein - dieser wurde erst 18 Monate nach Verkaufsstart
    entdeckt.
    Ich habe nichts gegen neue Fahrzeuge - nur etwas gegen die Art wie diese aufgebaut sind.

    In god (an invention by mankind) we trust - on earth we don't


    Sincerly yours, NSA
    powered by US government

  • Letzten Endes hat das zu dem Unfall geführt, weil der Fahrer nicht alle ihm zur Verfügung stehenden Möglichkeiten genutzt hat, um das Fahrzeug zum Stillstand zu bringen. Der Unfall hätte in ausreichender Zeit durch eine einfache Handlung verhindert werden können. Aus diesem Grund sind nach BOStrab Schienenfahrzeuge mit drei unterschiedlichen Bremssystemen ausgerüstet. Wenn durch den technischen Defekt keine Zeit mehr zum Reagieren oder keine Möglichkeit zum Bremsen geblieben wäre, würde ich deiner Argumentation des "Unsinns" folgen, aber der Zug ist ja erst im zweiten Bahnhof auf einen anderen Zug aufgefahren.


    Dass im Eingang ein technischer Defekt als Ursache gilt, ist unbestreitbar. Im Ausgang ist es meiner Meinung nach aber menschliches Versagen, so wie es auch der Verband Deutscher Verkehrsunternehmen (VDV) sieht:



    http://archiv.rhein-zeitung.de…09/02/topnews/fahrer.html

    X
    X
    X

  • Der FDIV-Bug sollte auch bekannt sein - dieser wurde erst 18 Monate nach Verkaufsstart
    entdeckt.

    Das ist aber ein völlig unkritischer Fehler gewesen.


    Kein Entwickler würde für eine wichtige Funktion Gleitkommaarithmetik nutzen. Und gerade im Embeddedbereich, wo ich beispielsweise tätig bin, ist die Anwendung von Festkommaarithmetik eigentlich an der Tagesordnung.


    Für die Bremssteuerung eines Schienenfahrzeuges würde sicherlich auch keine Gleitkommaarithmetik genutzt werden, wodurch dieser Fehler in dem Bereich, um den es hier geht, völlig zu ignorieren ist.


    Und bei den Anwendungen, wo es tatsächlich um die Nachkommastellen geht, wie bei Finanzsoftware, wäre dieser Befehl ebenfalls niemals in Frage gekommen.


    Ob sich nun ein Computerspiel, der Taschenrechner oder auch Excel verrechnet sollte niemals zu ernsthaften Folgen führen und falls doch, dann ist nicht die Software daran schuld, sondern der Anwender, der es eigentlich besser wissen müsste und auf Consumer-Technik in sicherheitskritischen Bereichen verzichten muss.


    Bei der "großen" Eisenbahn ist es doch auch nicht anders: Im EBuLa steckt normale PC-Technik, der Sollwertgeber ist hingegen direkt mit einer autarken Steuerung verbunden (ohne PC-Technik versteht sich).

    Ich habe nichts gegen neue Fahrzeuge - nur etwas gegen die Art wie diese aufgebaut sind.

    Die 143er haben eine elektronische Steuerung und sind mit diskreter Technik aufgebaut, vermutlich waren geeignete Mikrocomputer für die Steuerung eines Schienenfahrzeuges in der DDR damals noch nicht verfügbar. Wenn man aber sieht wie oft schon die 143er gebrannt haben und wie oft neue Straßenbahnfahrzeuge brennen, würde ich die größere Sicherheit erst einmal bei den neueren Straßenbahnen verorten (obwohl diese Software besitzen, gegen die du offenbar etwas hast).

  • Hinterher hat man Zeit und kann dann schlau daherreden - nur in der Panik nimmt man den
    falschen Ausgang. Es ist ja nicht so, daß es keine Versuche gab das Fahrzeug anzuhalten:
    -Notbremse im Fahrgastraum wurde gezogen [das Versagen des Bremscomputers
    -Ansprechend der PZB erzeugte auch keine Bremsung [eigentlich ein zweites Versagen....?]
    ...nur irgendwann ist die Zeit abgelaufen (=man hängt im Heck des Fahrzeuges voraus)
    [die Frage die sich mir stellt: wieviel Zeit verging eigentlich zwischen Ausfall des Computers bzw Bemerken dessen und dem Unfall?]


    ...und ein weiterer Punkt....wieso führte nicht der Ausfalls des Steuerung selbst zu eine Bremsung?!
    Bei einem ESTW sendet der Computer ständig "Signal grün" nach aussen. Entfällt diese Nachricht, dann
    fällt das Signal nach Ablauf einer kurzen Zeit von alleine auf rot. (Watchdogtimer)
    Entsprechend hätte man auch die Steuerung aufbauen können.....entfällt die Meldung "[Federspeicher]Bremsen lösen" dann
    klatschen diese zu und das Fahrzeug steht.


    >Kein Entwickler würde für eine wichtige Funktion Gleitkommaarithmetik nutzen.


    Wer sagt, daß der Mikroprozesser in den anderen Dingen fehlerfrei ist?
    Gibt es eine Garantie? Dieser Code nutzt keine Floatingpoint und sorgt
    trotzdem beim 80386 für einen Fehler:


    MOV EDX,4
    POPAD
    MOV EBX, [EDX + EBX*4]


    Bei der Ariane wird anscheinend Gleitkommazahlen zur Berechnung genutzt:


    https://de.wikipedia.org/wiki/Ariane_V88

    In god (an invention by mankind) we trust - on earth we don't


    Sincerly yours, NSA
    powered by US government

    Einmal editiert, zuletzt von Darkside ()

  • Combino: Danke für die Quelle. Das ist schon wesentlich anders als das, was im Wiki-Artikel steht.


    zip-drive: Ich habe Darkside nicht so verstanden, dass der den FDIV-Bug als Ursächlich für alles Übel in der (Computer-)Welt ansieht, aber es illustriert doch, das sich grobe Fehler lange unbemerkt halten können.


    Ich bezweifle, dass moderne Systeme wie die neue Kollisionswarnanlage in den Straßenbahnen der VGF ohne Fließkommaberechnungen auskommen; wird Entfernungsberechnung und Bewegungsabschätzung wirklich nur mit Ganzzahlen gemacht (Festkomma ist ja nix anderes)? Dann frage ich mich, warum dafür essentielle Funktionen (sqrt, sin, cos, tan, exp, log) in den meisten Programmiersprachen nur für floating point values verfügbar sind - um ohne FP zu rechnen, müsste man ja alle diese Funktionen neu implementieren. Wird das wirklich gemacht? Analoges gilt natürlich für Autonom fahrende Autos. Und schon haben wir sehr wichtige Felder und Schaltungen, die nicht auf Floating Point Arithmetrik verzichten können.


    Aber, und so habe ich auch Darkside verstanden, auch mit Fixed Point Artithmetrik gibt es genügend Fallen, genügend Komplexitäten, die ein System instabil und versteckt fehlerhaft machen können. (Abgesehen von meiner Befürchtung, dass Business-Programmierer wahrscheinlich sowieso alles mit strings machen.) So ist die Notbremse eben nicht mehr mit der Bremse verbunden, sondern mit einem komplexen Programm, das erst überprüft, ob die Bremsung jetzt eingeleitet werden darf oder nicht. Das hat viele Vorteile, aber eben auch Nachteile, wie zum Beispiel eine viel umfangreichere Typenprüfung.


    Zurück zum Thema "ist die TAB in München zu streng" möchte ich die Frage aufwerfen, ob die TAB in Frankfurt nicht viel zu lasch ist. Die U5-Wagen hatten durchaus nicht erst ein Software-Problem; wir hatten hier schon öfters über Bremsprobleme (Softwarebedingt) gesprochen, jetzt reden wir von (softwarebedingter) Türöffnung auf der falschen Seite; ich wäre mir nicht so sicher, ob der (softwaregesteuerte) Tempomat immer so funktioniert hatte, wie er sollte (wird der eigentlich noch benutzt?). Wer schonmal in einem U5-Zug gesessen hat, in dem der erste und der zweite Wagen (softwareseitig) nicht miteinander harmoniert haben, wird danach in seinem Kreuz gespürt haben, wie gut die Software funktioniert (schon selbst miterlebt: Zug ruckelt ohne Ende, bleibt auf Strecke liegen, Neustart (der Software), Zug schnurrt wie ein Kätzchen. Das lag sicher nicht am Fahrpersonal, denn das war ja dasselbe. Oder an den Motoren, denn die waren ja die gleichen. Oder an unterschiedlich abgefahrenen Rädern, denn das war ja (bis auf einige µm) auch das gleiche).

  • Hinterher hat man Zeit und kann dann schlau daherreden - nur in der Panik nimmt man den
    falschen Ausgang. Es ist ja nicht so, daß es keine Versuche gab das Fahrzeug anzuhalten:
    -Notbremse im Fahrgastraum wurde gezogen


    Gerade dir sollte doch die Funktionsweise der Notbremsüberbrückung bekannt sein, oder?


    [die Frage die sich mir stellt: wieviel Zeit verging eigentlich zwischen Ausfall des Computers bzw Bemerken dessen und dem Unfall?]


    Das kann man sich doch einfach ausrechnen: Spätestens bei der Anfahrt der Station Hansaring muss der Ausfall aufgefallen sein, vielleicht noch früher. Bis zum Aufprall in der Station Christophstraße wird im ungünstigsten Fall noch eine Strecke von 1 km zurückgelegt. Bei einer konstanten Geschwindigkeit von 50 km/h dauert die Fahrt dann 72 Sekunden. Die Presse sprach sogar von einer 1,5 km langen "Horrorfahrt", auf der der Zug erst am Ende auf 50 km/h aufgrund eines Gefälles beschleunigte. In diesem Fall fuhr der Zug mindestens 108 Sekunden ungebremst, womöglich aber etwas länger.

    X
    X
    X

  • Bei den neuen U-Bahnen heißt hingegen es, dass man nicht wisse, ob sie in die Tunnel passen.


    Ich hatte den C2 letztes Jahr auf der InnoTrans gesehen und habe eigentlich gedacht, dass der von den Abmessungen her (zumindest was Breite und Höhe angehen) vom Lichtraumprofil mit dem C identisch ist. :huh:

    Viele Grüße, vöv2000

  • Ich hatte den C2 letztes Jahr auf der InnoTrans gesehen und habe eigentlich gedacht, dass der von den Abmessungen her (zumindest was Breite und Höhe angehen) vom Lichtraumprofil mit dem C identisch ist.

    Das dachte ich auch. Aber die TAB sieht das offenbar etwas anders. Wenn die den neuen bombierten IK in Berlin zulassen müssten, käme der wohl nie in Betrieb.

    Ich habe Darkside nicht so verstanden, dass der den FDIV-Bug als Ursächlich für alles Übel in der (Computer-)Welt ansieht, aber es illustriert doch, das sich grobe Fehler lange unbemerkt halten können.

    Natürlich können sich Fehler, auch grobe, lange unbemerkt halten. Das ist aber bei anderen Fehlern auch nicht anders. Es sind auch schon Bauwerke erst nach Jahren aus statischen Gründen eingestürzt. (Da war doch mal eine Hotellobby herunter gekommen?!)


    Die Qualität der Software steht und fällt mit der Qualität, die in den ganzen Entwicklungsprozess gesteckt wird. Die eigentliche Programmierung ist nur ein Bestandteil: Vorausschauende Planung, ordnungsgemäße Dokumentation und gewissenhafte Tests sind genau so wichtig und gehören untrennbar zum Entwicklungsprozess dazu.

    Ich bezweifle, dass moderne Systeme wie die neue Kollisionswarnanlage in den Straßenbahnen der VGF ohne Fließkommaberechnungen auskommen; wird Entfernungsberechnung und Bewegungsabschätzung wirklich nur mit Ganzzahlen gemacht (Festkomma ist ja nix anderes)?

    Ich kenne mich zwar nicht mit Kollisionswarnanlagen aus, würde dies aber nicht als für die Sicherheit essentiell betrachten. Das ist doch nur eine zusätzliche Technik um es sicherer zu machen, nicht um die Grundsicherheit herzustellen.

    Dann frage ich mich, warum dafür essentielle Funktionen (sqrt, sin, cos, tan, exp, log) in den meisten Programmiersprachen nur für floating point values verfügbar sind - um ohne FP zu rechnen, müsste man ja alle diese Funktionen neu implementieren. Wird das wirklich gemacht?

    Ohne jetzt zu sehr ins Detail gehen zu wollen: Ich arbeite auf allen möglichen Plattformen (8, 16, 32 und 64 Bit vom Intel 8051-Derivat bis zur ARM-Cortex-Reihe) mit fixed point. Entsprechende Bibliotheken sind völlig problemlos zu beschaffen, mittlerweile gehören diese teilweise auch schon zum Funktionsumfang des Compilers. Bei C++ ist beispielsweise die Template-Programmierung ein elegantes Mittel, diese Techniken effizient einzusetzen.


    Bei der sicherheitskritischen Entwicklung von Software für die Avionik gibt es eigens spezielle Programmiersprachen (wie Ada), die genau für solche Bereiche geschaffen wurden.

    wir hatten hier schon öfters über Bremsprobleme (Softwarebedingt) gesprochen

    Das war aber doch eher so zu verstehen, dass die Bremsen erst verzögert reagiert haben. Es war doch nicht so, dass die Bremsen komplett versagt haben, oder erinnere ich mich hierbei falsch?


    Und selbst wenn der Sollwertgeber keine Bremsung mehr zulässt gibt es doch immer noch andere Möglichkeiten wie Hauptschalter aus und Federspeicher manuell anlegen. Bei U-Bahnen, die mit Stromschiene fahren, gibt es als letzte Möglichkeit auch noch den Kurzschließer.

  • >Natürlich können sich Fehler, auch grobe, lange unbemerkt halten. Das ist aber bei anderen Fehlern auch nicht anders.


    Fragt sich, ob man sich das für Dinge an denen Menschenleben hängen sich leisten darf....


    >Es sind auch schon Bauwerke erst nach Jahren aus statischen Gründen eingestürzt. (Da war doch mal eine Hotellobby herunter gekommen?!)


    Das?! https://de.wikipedia.org/wiki/…atastrophe_in_Kansas_City


    >(8, 16, 32 und 64 Bit vom Intel 8051-Derivat bis zur ARM-Cortex-Reihe)


    Die 8-Bitter MCS-51 dürften keine internen Verschaltungsfehler haben - aber bei den ganzen 32/64-Bitter wie ARM
    muß man die Fehlerfreiheit anzweifeln.


    >Entsprechende Bibliotheken sind völlig problemlos zu beschaffen, mittlerweile gehören diese teilweise auch schon zum Funktionsumfang des Compilers.


    ...und da kommen wir an den nächsten Punkt gekoppelt mit deiner Aussage:


    /*Die Qualität der Software steht und fällt mit der Qualität, die in den ganzen Entwicklungsprozess gesteckt wird.
    Die eigentliche Programmierung ist nur ein Bestandteil: Vorausschauende Planung, ordnungsgemäße Dokumentation
    und gewissenhafte Tests sind genau so wichtig und gehören untrennbar zum Entwicklungsprozess dazu.*/


    einige Zeilen drüber:


    Garantierte Fehlerfreiheit der Bibliotheken? Bekommt man die Dokumentation des Entwicklungsprozesses dieser
    mitgeliefert, damit man nachvollziehen kann, daß diese ordentlich erstellt wurden?


    > gewissenhafte Tests sind genau so wichtig und gehören untrennbar zum Entwicklungsprozess dazu.


    Zu den Tests - um mal den Bug der Floating-Point-Divisions-Einheit zu betrachten - dieser tritt nur bei bestimmten
    Zahlen auf - und zwar dann wenn diese bei der Division dafür sorgen, daß auf einen fehlerhaften Eintrag in einer
    in der CPU eingebauten Lookuptabelle zugreifen. Dies betriff nur ein kleiner Bereich der möglichen Eingangswerten.
    Wenn man jetzt testet während der Entwicklung wird man wohl kaum alle theoretisch möglichen Eingangswerte
    durchprüfen - bei 32 bit sind das alleine über 4 Milliarden Möglichkeiten. Man macht das ja nach Wahrscheinlichkeit.
    Es werden einige gewählte Werte benutzt und geschaut, ob das Ergebnis stimmt und damit verringert man die rechnerische
    Wahrscheinlichkeit, daß das System bei aderen Werten versagt.
    Aber auszuschliessen ist es nicht.


    Ich kenne noch zu gut die Wahrscheinlichkeiten für das Versagen eines AKWs die vorgerechnet wurden.....
    (das ist jetzt nicht 1:1 zu nehmen - es geht um die prinzipielle Beschreibung)
    Ein Kühlsystem versgat in 1/100 der Fälle, 4 somit in (1/100)^4, was somit seltener ist als die mehrfache Lebenszeit
    eines Reaktors....aber wie wie bisher gesehen haben stimmt diese Rechnung - es gab ja noch keine schwerwiegenden
    Reaktorunfälle....


    Nichts für ungut...aber je komplexer die Software/Hardware, um so weniger gehört die in Sicherheitsbereiche.

    In god (an invention by mankind) we trust - on earth we don't


    Sincerly yours, NSA
    powered by US government