Münchener "Avenio"-Bahnen stillgelegt
-
- [Presseschau]
- tunnelklick
-
-
....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.... -
Mit den Variobahnen gibt/gab es auch Probleme.
-
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.
-
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?
-
Momentan fahren die P-Wagen wohl auf zwei Kursen der Linie 28, aktuelle Infos dazu und zu München allgemein gibt es immer auf: http://www.tramreport.de/
-
....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...
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...
-
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.
-
>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.
-
[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/SoftwarekriseOder 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. -
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:
Zitat
Notknopf wurde nicht gedrücktFahrer soll Kölner U-Bahn-Unglück mitverursacht haben
Köln - Der schwere U-Bahn-Unfall in Köln, bei dem Anfang vergangener Woche 70 Menschen verletzt wurden, hätte offenbar doch vom Fahrer verhindert werden können. Das berichtete die Kölner Staatsanwaltschaft am Donnerstag nach Auswertung eines Sachverständigen-Gutachtens. Demnach versagte bei dem "City Sprinter"-Testzug am 23. August die zentrale Steuerung. Dadurch sei die Bremse nicht ausgelöst worden. Der Fahrer hätte aber laut Gutachten über einen Notausschalter eine Notbremsung auslösen können. Der Schalter sei funktionstüchtig gewesen.
Der Fahrer, der bisher nicht vernommen wurde, habe diese Notbremsung offenbar nicht oder zu spät veranlasst, sagte Oberstaatsanwältin Regine Appenrodt. Die Ermittlungen wegen fahrlässiger Körperverletzung gegen unbekannt seien auf den Fahrer ausgeweitet worden.
Der Verband Deutscher Verkehrsunternehmen (VDV) in Köln sprach deutlicher von menschlichem Versagen als eine der möglichen Ursachen. Der Fahrer habe es versäumt, den roten Nothalteknopf rechtzeitig zu betätigen. In einem Bericht der vorab veröffentlichten "VDI Nachrichten" erklärte VDV-Hauptgeschäftsführer Adolf Müller- Hellmann, bei dem Prototyp sei zunächst die elektronische Fahrzeugsteuerung ausgefallen. Unabhängig von dieser Steuerung hätte der Fahrer, der selbst schwer verletzt wurde, dann noch über den Knopf abbremsen können. Nach dem nun vorliegenden Sachverständigenbericht sei das elektro-mechanische Bremssystem in Ordnung gewesen.
-
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:
-
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 gezogenGerade 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.
-
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.
-
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.