Notbremse

Ich denke, das wird weniger eine problematische Programmierung innerhalb eines Steuergeräts sein, eher eine schlecht entworfene Interaktion zwischen verschiedenen Geräten, z. B.
– Status der Notbremsknöpfe wird periodisch alle x ms auf dem Bus übertragen, aber Notbremsung wird erst nach dreifachem Nachrichtenempfang eingeleitet (um ungewollte Bremsung durch transienten Fehler zu vermeiden)
– Primäres Steuergerät leitet die Bremsung sofort ein, aber sicherheitsrelevantes Sekundärsystem muss nach Plausibilitätsprüfung die Aktoren freischalten

Wahrscheinlich wird es nicht immer, sondern im ungünstigsten Fall eine Sekunde dauern. Die Schwachstelle wird auch so in der Systemspezifikation stehen, sonst wäre es dem Gutachter gar nicht aufgefallen.

In einem normalen 700m langen Güterzug pflanzt sich das Brems-Signal nur mit Schallgeschwindigkeit fort, denn es kommt über die Hauptluftleitung von der Lok, wenn der Triebfahrzeugführer das Führerbremsventil bedient. Das ist hundert Jahre alte Technik: bewährt und ausfallsicher.

Jetzt ist natürlich die Frage, warum da beim neuen ICE unbedingt ein Computer dazwischen muß…

Bei Passagierflugzeugen gibt es doch Zulassungsregeln, dass wichtige Steuerungen (wie Steuerflächen, Fahrgestell) auf mehr als eine Weise bedienbar sein müssen, also wenn es hydraulisch nicht mehr geht, dann eben elektrisch usw. Das Fahrgestell sogar mechanisch (Auslösehebel plus Schwerkraft).

Das mag nicht direkt übertragbar sein, aber: War hier wirklich vom “Not”bremssystem die Rede? Schlimm genug, dass da anscheinend überhaupt soviel Elektronik zwischen Fahrer und Bremsbacken sitzt. Ist es dann klug, keine separate Bremsbedienung für Notfälle zu haben, sondern auch diese den Fähigkeiten akademisch ausgebildeter Entwickler zu überlassen? Programmierte Elektronik ist doch die gefährdetste Technik von allen.

Habe ich da was nicht (richtig) verstanden?

Ich weiß nicht, ob es bei Zügen überhaupt ein Notbremssystem gibt. Ich würde vermuten, dass eine Notbremsung nur bedeutet, die normale Bremse mit größter Kraft zu ziehen und bis zum Stillstand nicht mehr loszulassen.

Bei Straßenbahnen gibt es noch Sandstreuer, die Sand, Korund oder irgendsowas unter die Räder sprühen, wenn wirklich heftig gebremst werden muss (hab ich mal gesehen, ein beeindruckendes Schauspiel. Außen fliegen die Funken und innen die Fahrgäste).

Bei Zügen hätt ich von sowas aber noch nie gehört.

Lieber Hadmut!

Kein Mensch programmiert in der Praxis funktional. Bestenfalls ein paar Theorembeweiser, Computeralgebrasysteme und Expertensysteme werden in Common Lisp oder Standard ML programmiert, bei denen Reaktivität und Zeitverhalten aber sowieso keine Rolle spielen. Hadmut pflegt mal wieder seine Vorurteile, diesmal gegenüber funktionaler Programmierung. Zumindest über den Resourcenverbrauch funktional programmierter Software sind viele Gerüchte in Umlauf, die wohl noch aus der Zeit stammen, als man FORTRAN und COBOL mit LISP verglichen hat.

Viel häufiger wird aber Software in Java und C++ produziert. Und da fallen mir eine Menge möglicher Fehlerursachen ein. Zum Beispiel könnte die Software ereignisorientiert programmiert worden sein, was sehr häufig vorkommt. Das Ereignis, das die Notbremsung auslösen soll, steckt in einer Queue fest, weil das System einfach überlastet ist. Das ist wie beim Arzt, wenn der Andrang zu groß wird, dann muß man auch warten. Dabei ist eine Arztpraxis schon wie ein Echtzeitsystem eingerichtet. Da werden zwar Termine vergeben. Zu deterministischem Zeitverhalten führt das aber trotzdem nicht immer, wenn das System falsch dimensioniert ist.

Ich weiß auch nicht, inwieweit sich das Zeitverhalten gängiger Java-VMs sich verbessert hat. Das steht auch nicht in einem sehr günstigen Ruf.

@georgi: Es mag ja sein, dass in der realen Welt da draußen niemand funktional programmiert.

Aber wie programmiert dann jemand, der nichts anderes als funktionales Programmieren gelernt hat und dem man eingetrichtet hat, dass das der Stein der Weisen sei?

Der Übergang von der Schule in die Praxis ist heute doch völlig reibungslos. An der Schule lernt man für’s Abi, an der Uni für die Modulprüfungen, auf der Arbeit für den Abnahmetermin. Zielorientiertes Lernen nennt man das wohl. Die Anpassungsleistung an den Habitus der Vorgesetzten wird hier wie dort belohnt; die funktionale Programmierung ist so schnell wieder vergessen wie sie erlernt wurde.

@georgi
“Kein Mensch programmiert in der Praxis funktional.”
Ups?
Die meisten Praktiker programmieren funktional. In Maschinen und Anlagen sind Steuerungen drin, und wenn man sich das, was da geschrieben steht, mal genauer ansieht, dann steht da massenweise, Ausgang_23.1 = Eingang_4.0 oder Speicher_33.5. Das Programm arbeitet Klauseln ab. Die IT programmiert auf PCs meist prozedural, mag sein. Deshalb die lustigen Effekte, wenn ITler den Elektrikern das Programmieren neu beibringen wollen.
Das ist ein Streit um des Kaisers Bart. Man kann alles so oder so schreiben. Wie es abgearbeitet wird ist wieder eine andere Frage.
Wenn eine Steuerung laufen muß, dann muß man auf Schleifen, Entscheidungen und Zeiger verzichten.

Carsten
—
Oktoberfest
http://www.toonpool.com/user/13509/files/oktoberfest_1018705.jpg

@Carsten Thumulla: Reine Benutzung von Funktionen und Prozeduren ist nicht funktional, Rekursion bei Schaltkreisen ist ohnehin ein recht schwieriges Unterfangen. So VHDL-Zeug geht meistens eher in Richtung Logikprogrammierung.

@Hadmut: An der Uni sind ein Haufen Wirtschaftsnoobs die im akademischen Umfeld wenig taugten (und damit lieber auf eine FH gesollt hätten, in der die Praxisnähe doch stärker ist), aber in der Wirtschaft zufällig die Kurve gekriegt haben, und jetzt meinen, sie müssten den Universitäten sagen was sie zu tun haben, weil sie ja der “Beweis” dafür sind dass etwas falsch läuft – kurzum, man kriegt an der Uni oft genug von irgendwelchen Leuten gesagt wie scheiße das doch alles sei was man lernt. Wenn du also meinst beobachten zu können, dass die Leute meinen, funktionale Programmierung (was immer du dir genau darunter vorstellst, du scheinst ja ein recht verzerrtes Bild davon zu haben und alles Negative dort hinein zu interpretieren) sei das Beste, dann würde ich eher vermuten, das liegt daran, dass sie die Informationen halt nach Quellen filtern.

Ich halte das allerdings für eine Fehlinformation. Den meisten Akademikern die ich kenne sind die momentanen Grenzen der funktionalen Programmierung ziemlich klar, und Zeug wie “Real Life Haskell” ist eher der Versuch, seine eigene Irrelevanz so lange zu ignorieren bis sie überstanden ist (hat ja bei der FDP auch gut geklappt). Und die richtig Guten davon wissen auch, wie man so eine funktionale Sprache effizient implementiert, können also durchaus Lowlevel-Zeug. That being said, ich nehme an dass die Bahn sowieso eher irgendwelche Embedded Systems benutzt für die abgesehen von C/C++ und direktem Assembler sowieso nichts existiert. Überall sonst haben die meisten funktionalen Sprachen irgendwelche Anbindungen an Realtime-Bibliotheken, und eine Sekunde Wartezeit durch schlechte Programmierung hinzubekommen dürfte selbst im schlechtesten Setting eine programmiertechnische Meisterleistung sein.

Da läge dann schon eher nahe dass sie das Bremssignal per WLAN über einen mit PHP generierten RSS-Feed im Zug verteilen. Und selbst in diesem Setting kriegt man es wohl im Allgemeinen besser hin. Es wird also wohl ein seltsamer anderer Flaw im Spiel sein.

@uxul: Du gibst mein Blog offenbar gerne bewusst falsch wieder, wenn es um funktionales Programmieren geht.

Ich habe nichts gegen funktionales Programmieren, es ist sogar gut und wichtig, es zu beherrschen. Aber es ist nur eine von vielen Programmiertechniken, und sie hat nicht nur ihre Stärken, sondern auch fundamentale Schwächen. Funktionales Programmieren macht durchaus Spaß, und kann Dinge vereinfachen, ist aber auch ziemlich gefährlich und blendet wichtige Fähigkeiten, die man zum Programmieren braucht, systematisch aus.

Das Problem am Funktionalen Programmieren ist nicht das funktionale Programmieren, sondern die bescheuerte Ideologie derer, die sie lehren und vertreten. Denn die behaupten allzu oft, dass man nur noch funktional programmieren solle und gar nichts anderes mehr bräuchte. Funktionales Programmieren sei der Königsweg. Weil sie einen Tunnelblick haben und nur einen sehr kleinen Aspekt des Programmierens betrachten, und damit nur einen winzigen Ausschnitt des Programmierens betrachten, für den FP gerade geeignet erscheint.

Außerdem hat FP eben mit systematischer Faulheit zu tun, weil durch diese Tunnelblick-Mentalität natürlich der zu lehrende Stoff drastisch reduziert wird, weil man zu vieles einfach weglässt. Der größte Vorteil der FP ist, dass der Lehrende viel weniger können und lehren muss.

Mag sein, dass es den meisten Akademikern klar ist, aber das sind eben nicht die, die die Lehrpläne machen. Und nur weil’s einem klar ist, hat man noch lange nicht den Rest gelernt.

Auffällig ist aber, dass da immer Du zum stänkern vorbeikommst, schon bei einem früheren kritischen Artikel über FP und Sicherheit und über Scala.

Jedesmal, wenn man FP kritisiert kommst Du da zum Dreckwerfen und Trollen vorbei. Und jedesmal ohne nachvollziehbare Begründung oder gar mit falschen Aussagen. Und das ist genau das, was man so gar nicht gebrauchen kann.

Das ist genau das, was ich meine: Ohne jede Begründung die FP verherrlichen. Sowas kann man in der theoretischen Informatik machen, aber nicht außerhalb des Elfenbeinturms.

ich habe hier einen kommentar zum thema gelesen der sich irgendwie plausibel liest. darin heißt es:

Für den neuen ICE wurde ins Pflichtenheft geschrieben, dass er an jeder Stelle trennbar und in verkürzter Wagenreihung betreibbar sein muss.
Deswegen gibt es nicht wie beim ICE3 einen durchgehenden Signalbus, sondern jedes Modul (Waggon) kommuniziert nur mit seinen Nachbarn.
Bei einem Notstop müssen alle Wagen die Aktivierung der (Rad- oder Schienen-)Bremsen quittieren, weil ja auch alle aktiv angetrieben werden.
Das geschah früher zeitgleich, inzwischen muss jeder Waggon für die hinter ihm liegenden Proxy spielen und die Nachrichten zusätzlich zu seinem eigenen Status weiterleiten.
Auch das EZB ist in Teilen daran schuld, weil die auf einem sehr umfangreichen Datensatz (1,5kB netto) bestehen, statt nur ein paar Statusbits. Unfalldatenschreiber lässt grüßen. Die Datenrate der Verbindugen ist (wegen der Störsicherheit) auch heftig limitiert und ein Paket kann aufgrund der komplizierten Prüfsummenbildung von einem Waggonsteuerrechner erst weitergeschickt werden, wenn es komplett empfangen wurde. Elementare Physik.
Dafür werden jetzt die Specs der Kupplungsstellen noch mal über den Haufen geworfen und mehrere parallele Datenkanäle eingebaut. Bis das durch ist, kann kein Zug ausgeliefert werden, da ja sonst die Kupplung inkompatibel ist.

–
lange weile?

@euchrid: Das hört sich plausibel, aber nicht schlau an.

Dass sie in der Lage sein wollen, ihre Züge auch mit geänderter und verkürzter Wagenreihung zu betreiben ist ja nachvollziehbar. Aber man kann ja durchaus auch Bussysteme bauen, die durchgehend sind und trotzdem diese Eigenschaft erfüllen. Schon 10base2 und 10base5 Ethernet erfüllten diese Eigenschaft. Soweit ich weiß auch der CAN-Bus. Das ist eigentlich beherrschte Technik. Es leuchtet mir partout nicht ein, warum man in einem Zug nicht ein durchgehendes Bus-System einbauen können sollte, das auch bei geänderter Reihenfolge/Zahl/Ausrichtung der Wägen funktioniert.

Allerdings ist mir daran nicht ganz klar, warum bei einem solchen System der ganze Zug erst eine Sekunde später bremsen sollte.

Und fragwürdig erscheint mir das schon deshalb, weil die Zugdurchsagen (zumindest nach meinem Eindruck, mir wäre da noch nie eine Verzögerung zwischen den Wagons aufgefallen) synchron erfolgen. Etwas seltsam, dass sie einerseits irgendwelches Blabla in Echtzeit durchgeben können, andererseits aber einen einfachen Brems-Befehl nicht. Man könnte zwar die Auffassung vertreten, dass die Zugdurchsagen weniger sicherheitskritisch sind und deshalb einfacher gebaut sein können, aber selbst da hätte ich meine Zweifel.

>> Bei Straßenbahnen gibt es noch Sandstreuer <> Viel häufiger wird aber Software in Java und C++ produziert <> Das Ereignis, das die Notbremsung auslösen soll, steckt in einer Queue fest, weil das System einfach überlastet ist. Das ist wie beim Arzt… <<
Ja nur dass in diesem speziellen Wartezimmer die Leute sterben, bevor sie drankommen oder? Ist es wahr, dass Steuerungen heutzutage so gebaut werden? Eine Sekunde Latenz mag da ja in Fachkreisen als nicht zuviel gelten, aber für mich klingt das so, als sei da nicht die Ausprägung kritisch, sondern das Konstruktionsprinzip als ganzes. Sollte das so sein, sollten die Amts- und Bahnverantwortlichen schon mal "Unabweisbarkeit" googeln…

Ich hatte mal ide ehre in einem ICE vorne im führerstand mitzufahren, hab mir dort einiges erzählen lassen und durfte sogar das horn betätigen 😀
Was ich davon mitgenommen hab ist: Diese sekunde verzögerung macht in der praxis nichts aus. Ein Zug ist kein Auto, wenn ich das recht im kopf habe, hat ein ICE je nach ausgangsgeschwindigkeit einen bremsweg von irgendwas zwischen 5 und 10km.
Danaben gibt es noch einen notfallbremsung die den zug halb so schnell anhält, nur sind das immernoch mehrere kilometer. Zusätzlich meinte der zugführer, es wird schlicht für nichts unter einem LKW auf den schienen gebremst, weil man erfahrungsgemäß weniger verletzte zu beklagen hat wenn man durch das hinternis durchsaust, als wenn einem durch die bremsung etliche fahrgäste durch den zug purzeln.

Was ich damit sagen will: son ICE fährt sich eher wie ein Schiff, bremsen auf sicht mit 300 sachen ist sowieso nicht, und auch bei langsamer fahrt bremst man nicht wegen der passagiere, sondern fährt drüber. aus dem grund ist so eine Sekunde reaktionszeit in der praxis schlicht vernachlässigbar, natürlich trotzdem blöd wenn man dadurch durch die abnahme fällt 😉

@FK: Stimmt bei Vollgas auf offener Strecke.

Hin und wieder passiert es aber auch mal, dass einer mit dem Zug auf den Prellbock im Sackbahnhof auffährt und ihn in den Zeitschriftenladen reinschiebt. Da kann eine Sekunde viel ausmachen.

Und selbst wenn der Bremsweg 10 km beträgt, können es die 70 Meter trotzdem ausmachen. Denn der Zugführer bremst ja nicht nur wenn er einen LKW auf der Strecke stehen sieht, sondern auch bei einem roten Signal.

@Hadmut: Ich glaube auch nicht, daß Leute in der Praxis nicht wissen, wie man echtzeit-programmiert. Das hat alles nichts mit Uni zu tun.

Stimmt. Die universitäre Ausbildung und die Fähigkeit zur Echtzeitprogrammierung haben nichts (mehr) miteinander zu tun.

In meinem Studium gab’s im Vordiplom noch eine Maschinensprache-Übung, bei der man einem ziemlich primitiven Einplatinencomputer beibringen musste, gleichzeitig eine Stopp-Uhr darzustellen und eine Verkehrs-Ampel zu steuern. Minimal, aber immerhin.

“Bei Straßenbahnen gibt es noch Sandstreuer[…]sondern auch bei einem roten Signal”

Hallo Hadmut!

Erst einmal moechte ich erwaehnen, dass ich Deinen Blog mit grossem Interesse und einer nicht minder grossen Heiterkeit verfolge. Vieles gefaellt mir hier.

Nun zu den Zitaten. Es gibt auch bei den modernsten Loks und Triebwagen immer noch Sandstreuanlagen. Das hat, ausser bei Eis und feuchtem Gleis, auch weniger mit dem Bemsen, als mit dem Problem zu tun, die Kraft der Triebfahrzeuge ueberhaupt auf die Schiene zu bekommen. Und da ist Sand in vielen Anfahrsituationen nachwievor das Mittel der Wahl.

Was das rote Signal betrifft, so weiss jeder Triebfahrzeugfuehrer durch Vorsignale von der Stellung des an dem zu haltenden Hauptsignales. Jene Vorsignale stehen immer im Abstand des Bremsweges, der aus der auf dieser Strecke gefahrenen Hoechstgeschwindigkeit resultiert. Ein rotes Signal kommt also nie ueberraschend.

Diese Geschwindigkeiten werden entweder durch die Buchfahrplaene oder bei den an ICE-Strecken eh vorhandenen direkten Geschwindigkeitsanzeigen geregelt und teilweise sogar direkt an die Triebfahrzeuge uebermittelt. Und fuer diese Geschwindigkeitsanzeiger gibt es auch noch Geschwindigkeitsvoranzeiger.

Mit(in) freundlichen(in) Gruessen(in)

Mick(in?)!

Ich hab ja gar nichts gegen die Sandstreuer. Die sind gut. Nur hab ich sie bisher eben nur an einer Straßenbahn im Einsatz entdeckt und deshalb nicht gewusst, ob Züge sowas auch haben.

Ein rotes Signal kommt im Normalfall nicht überraschend. Im Notfall aber schon. Und gerade um den geht’s ja hier. Solange man vorher weiß, wo man bremsen muss, machen auch 30 Sekunden Verzögerung nichts. Das kritische Problem, wo es auch auf eine Sekunde ankommt, ist ja das unvorhergesehene und damit unangekündigte Bremsen.

Ich glaube mich erinnern zu können irgendwo mal was davon gehört zu haben dass die Leitstelle modernere Züge sogar ferngesteuert notbremsen lassen kann ohne noch den Lokführer einzubeziehen, weil das zu lange dauern könnte. Wenn das so ist, wäre eine Sekunde durchaus relevant.

Hallo!

Stimmt rein rechnerisch gesehen schon, dass, rechnet man Schrecksekunde, verzoegerte Reaktion des Triebfahrzeugfuehrers etc. zusammen, diese eine Sekunde schlicht zuviel ist. Aber frag mal Triebfahrzeugfuehrer, wenn dieser ein Hindernis auf den Gleisen sieht kann er, mit Ausnahme vielleicht von kurzen, leichten Triebwageneinheiten, schon bei einer Geschwindigkeit von nur 80Km/h nicht mehr vor dem Hindernis zum Stehen kommen.

Und bei den modernen KS-Signalen (Kombinationssignalen) kann ein Hauptsignal jederzeit auch als Vorsignal dienen, sprich jedes Signal kann jederzeit Haupt- oder Vorsignal sein. Das wird nur noch durch das jeweilige Signalbild festgelegt. Stellwerksgesteuert koennte man theoretisch fruehzeitig auf Gefahren reagiern. Nur bei den heute fast ausschliesslich genutzten zentralen Stellwerken, frage ich mich wie jemand von dort aus ein Hindernis auf der Strecke bemerken sollte.

Die Sinnhaftigkeit einer Notbremsung eines ICE bei 200-300 Km/h steht fuer mich eh in Frage. Evtl. noch bei einer Zugfunkmeldung “20Km vor Euch ist die Bruecke eingestuerzt”. Alles andere, was vom Zugfuehrer selbst ausgeloest wird, ist nur eine ausserplanmaessige Komplettbremsung des Zuges mit aller verfuegbaren Bremsleistung bei dem der Zug zum Stehen gebracht wird, aber eben nicht VOR der Gefahrenstelle.
Und dabei ist diese eine Sekunde rein akademischer Natur.
Ein ICE benoetigt bei einer normalen Bremsung von 250 Km/h auf 0 etwa 4800 Meter und bei einer Schnellbremsung immer noch ca. 2300 Meter.
Eine Gefahrenstelle in >2300 Meter Entfernung erkennen und dann rechtzeitig bremsen?

Bei Hoechstgeschwindigkeiten von <80Km/h wuerde ich das als Grund akzeptieren ein Fahrzeug nicht zuzulassen, aber bei einem ICE mit in der Regel mehr als 200Km/h halte ich das fuer den beruehmten Amtsschimmel.

Damit will ich aber nicht zum Ausdruck bringen, dass eine schnellere Reaktion der Software nicht besser waere…

Mick!

Ich halte Diskussion, ob eine Sekunde angemessen ist, für eher unangemessen.

Hier geht es um Sicherheit, da kann man vorher nicht sagen, ob eine Sekunde relevant sein wird oder nicht. Es kann genau auf diese Sekunde ankommen. Hat man ja schon gehabt.

Ich sehe aber überhaupt keinen Grund und auch keinen Vorteil darin, warum ein Zug eine Sekunde brauchen sollte, bis alle Waggons sich einig sind, dass sie jetzt bremsen wollen. Ich sehe nicht, warum man überhaupt eine solche Verzögerung einführen würde. Denn einen abzuwägenden Vorteil sehe ich nicht.

Übrigens ist die Diskussion auch deshalb unsinnig, weil man bei Autos bezüglich der Reaktionszeit, des Bremsweges, der Reifen usw. auch nicht fragt, ob das Auto noch zum Stehen gekommen wäre, sondern differenziert, ob man den Fußgänger etwa mit 30 oder 40 km/h treffen würde, was eben den Unterschied zwischen schwerverletzt oder tot ausmachen kann.

Die Frage ist nicht (allein), ob der Zug steht, sondern wieviel Energie er abbauen kann und ob die Restenergie beim Aufprall auf das Hindernis beispielsweise noch genügt, den Zug zum Entgleisen und Umstürzen zu bringen oder es nur ordentlich rummst, aber der Zug bleibt, wo er hingehört. Und da bin ich durchaus der Meinung, dass es auf jede Sekunde ankommt, selbst wenn der Bremsweg nicht mehr reicht um zum Stehen zu kommen.

Man sollte nicht dem Fehler unterliegen zu glauben, dass wenn der Zug das Hindernis sowieso trifft, es dann auch egal sei, wie schnell er noch ist.

Wieviel Energie baut ein ICE mit 200 km/h bei einer Vollbremsung pro Sekunde ab?

“Man sollte nicht dem Fehler unterliegen zu glauben, dass wenn der Zug das Hindernis sowieso trifft, es dann auch egal sei, wie schnell er noch ist.”

Glaub mir, oberhalb von 35Km/h ist es fuer den getroffenen (Kfz oder Personen) wirklich egal, wenn man die extreme Stabilitaet der Kupplungsebene (1.06 Meter oberhalb der Schienenoberkante)in Betracht zieht. Nicht aber fuer den Zug selber, sollte er auf ein Hindernis mit grosser Masse prallen, z.B. einen stehenden oder gar fahrenden Zug.

Im Uebrigen gebe ich Dir durchaus Recht, eine Sekunde Reaktionszeit der Software ist schlicht indiskutabel. Wer programmiert eine derartig zeitkritische Funktion so zusammen?

“Wieviel Energie baut[…]”

Laut

Heinz Kurz: ICE 3 und ICE T – Neue Triebwagengeneration für die Deutsche Bahn. In: Eisenbahntechnische Rundschau. 48, Nr. 9, 1999, S. 549–559.

Zitat uebernommen aus http://de.wikipedia.org/wiki/ICE_3:
“Die maximale Leistungsaufnahme der Wirbelstrombremsen je Halbzug liegt bei rund 800 kW. Je zwei Magnete von 1290 mm Länge an jedem Laufdrehgestell erzeugen je Halbzug eine Bremskraft von bis zu 200 kN.”

Leider fehlen in dem Wiki-Artikel die Daten zur Masse einer Zugeinheit…

Mick!

Moin moin, um mal auf die Eingangsfrage von Hadmut einzugehen, der /die Fahrsteuerungscomputer sind bei Siemens quasi aus dem Regal entnommene SPS Systeme die Bahntauglich gemacht wurden. Die Programmierung wird da sehr Hardware nah und wahrscheinlich in Assembler oder höchstens C erfolgen. Obwohl Siemens für einige SP Systeme auch schon so eine Klicki-Bunt Oberfläche hat in der man nur die Funktionsblöcke zusammen ziehen muss.
Meiner Meinung nach liegt der Hase nicht in der Art der Programmierung begraben. Vielmehr ist das Ganze mittlerweile so kompliziert geworden, das so an der einen oder anderen Stelle Phänomene auftreten wie in diesem Fall hier. Es gab in der Vergangenheit schon mehrfach Probleme mit den Fahrsteuerungscomputern von Siemens. Nicht nur bei denen, davon sind wohl alle irgendwie betroffen. Da war die Sache mit dem Taurus (https://de.wikipedia.org/wiki/Siemens_ES64U4) die das Ende einer LZB Strecke nicht mit mitbekommen hat und mit zu hoher Geschwindigkeit weiterfuhr anstatt abzubremsen. Oder die ‚Nummer‘ mit der Hamsterbacke (https://de.wikipedia.org/wiki/Bombardier_Talent_2), die bei Betätigung der Türfreigabe Linke Seite, das Licht ausschaltete….
„euchrid eucrow“ hatte es schon sehr gut angesprochen. Der Fahrsteuerungscomputer muss bei Auslösung der Bremsung eine Menge Daten verarbeiten und quasi im Zug verteilen. Hinzu kommt jetzt noch das der Rechner solche Befehle auch noch an externe Systeme weitergeben wie LZB und ETCS muss. Möglicherweise liegt hier der ‚Hase begraben‘.
Da war noch etwas mit ZITAT Notbremssystem /ZITAT. Ja so etwas gibt es. Für den Reisenden gibt es da eine „Schnittstelle“ meist in Form eines nicht zu übersehenden roten Griffs/Hebels. Bei langsamen Zügen (V Luft wird aus der Bremsleitung abgelassen -> Zug bremst mit höchster Kraft. Diese kann auch durch andere Ereignisse direkt ausgelöst werden. (https://de.wikipedia.org/wiki/Druckluftbremse_%28Eisenbahn%29)
Bei höheren Geschwindigkeiten wird die Druckluftbremse nicht eingesetzt, da die Kräfte zu groß sein würden. Deshalb bremst man zuerst nur mit der elektrischen Bremse und schaltet dann ab 160 km/h die Druckluftbremse mit dazu.

PS. auf den EBULA (Elektronischer Buchfahrplan und Langsamfahrstellen) Rechner wird MS Windows 95/98/NT verwendet….
Gruß Teasy
Moin moin, um mal auf die Eingangsfrage von Hadmunt einzugehen, der /die Fahrsteurungscomputer sind bei Siemens quasi aus dem Regal entnommene SPS Systeme die Bahntauglich gemacht wurden. DIe Programierung ist da sehr Hardware nah und wird warscheinlich in C / Assembler

Ich erlaube mir einmal ein wenig Off-Topic zu werden (auch auf die Gefahr hin, dass dieser Kommentar gar nicht erst erscheint oder auch geloescht wird, neudeutsch full ack!). Einer der Gruende warum ich hier so gerne, auch gerade in den Kommentaren lese, wird klar, wenn man die Forumsbeitraege zu dem verlinkten Spiegelartikel verfolgt. Was da fuer cerebrale Flatulenzen ausgestossen werden ist schon nicht mehr feierlich. Da wird einem sehr deutlich klar, dass entweder vermehrt die geistig nicht ganz so bemittelten schreiben, oder die allgemeine Verbloedung doch schon sehr weite Kreise gezogen hat…

Mick!

Mein Beitrag 25.11.2012 14:49 ist von der Software im 3. Waggon (oder evtl. von WordPress?) verstümmelt worden. Aufeinanderfolgende spitze Klammern sind da wohl unwillkommen. Inzwischen ist die Debatte über meine Anmerkungen weg, also seisdrum.

Wenn Euchrids Wiedergabe der Zugsoftware-Spec richtig ist, hatte ich aber immerhin richtig vermutet: Zuviel Eimerkettentechnik zwischen Auslöseknopf und Aktuator, und das gewollt.

Meiner Meinung nach weniger eine akademische Frage der Programmiertechnik, sondern falsches Design bzw falsche Prioritäten: Wirtschaftlicher Betrieb im allgemeinen vor Sicherheit im Einzelfall. Da steckt (in meinen Augen falsch verstandenes) Risikomanagement dahinter, eine Kerndisziplin aller Sicherheitsfachleute. Wenn man eine Eintrittswahrscheinlichkeit nur niedrig genug ansetzt und die potentielle Schadenshöhe allein am finanziell Quantifizierbaren misst, dann passiert sowas eben (Klimaanlagen fallen nur aus, wenn man sie braucht, Einteisungsmittel am Airport ist nur alle, wenn man es braucht etc pp, aber die Eintrittswahrscheinlichkeit war eben nicht 0,00…01%, sondern von vornherein 100%. Nur der Zeitpunkt war unsicher). Das passiert, wenn man Risikomanagement Leuten überlässt, die nur BWL gelernt haben. Machen sicher fast alle börsennotierten Unternehmen so – weil sie per Gesetz so handeln müssen. Und am Ende ist niemand persönlich verantwortlich, das ist (nach den Todesopfern und den Versehrten) das schlimmste daran.

Was diesen Einzelfall angeht: Kasten Bier ans Eisenbahnbundesamt.

Hier wird ganz schön viel über Echtzeitsoftware geschwafelt.

In der Realität läuft diese Software nicht im klimatisierten Büro, sondern muß mit den Unwägbarkeiten der Aussenwelt umgehen. Wie lange würde denn ein RJ45 Stecker an einer Zugkupplung durchhalten ?

So ein Zug ist länger als 100m ? Mit doch egal, Ethernet rulez !

Das Eisenbahn Bundesamt fordert eine Verifizierung der Software ? Was issen das ? Ich Held von die C++ und mache niemals Fehler !

Ich nehme mal an, die Zugsteuerung ist SPS basiert. Passt irgendwie zu Siemens. Wenn man dann eine Verifikation fahren will, macht man ein Taktsystem, in dem die Daten verteilt und Aktionen ausgelöst werden. Da sind dann Abfolgen, Reaktionen und Ausseneinflüsse leichter zu beschreiben. Desweiteren passt es gut zu den SPS-Zyklen. Bei 20 Wagen sind das 40 Zyklen. Sollten die auch nur 25 ms dauern, haben wir die Sekunde Verzögerung.

Ich bin jetzt nicht ganz up to date bei der Verifikation, deshalb sind mir keine Methoden bekannt, mit der man ein nicht triviales Protokoll über 20 Stationen mit vernünftigem Aufwand beweisen könnte, wenn sich Ereignisse beliebig überholen dürfen. Der feste Takt sorgt dafür, das man Erkenntnisse über einzelne Stationen aus die gesamte Kette verbreiten kann. Er sorgt aber auch für eine Mindestlaufzeit durch das System.

Schwätzer!

Es ging nie darum, in Zügen Ethernet einzusetzen, sondern um die Aussage, dass man auch Bussysteme mit variabler Konfiguration bauen kann. Es hat auch niemand von RJ45 gesprochen. Und zu Deiner Information: 10Base5 hatte eine Kabellänge von 500 Meter. Und war ein Bussystem, von denen wir hier geredet haben. RJ45 kam mit 10BaseT und das ist kein Bus, sondern ein Stern-System, weshalb das auch hier niemand gemeint haben kann. Und das war vor 20 Jahren, da sollte man mittlerweile deutlich weiter sein. Und das zählt auch unter den Begriff Ethernet. Und von C++ hat hier auch keiner geredet. Und warum eine Verifikation mit einer Gedenksekunde einfacher sein soll, ist mir auch nicht ersichtlich.

Ab in die Ecke und schämen. Gibt heute keinen Nachtisch für Dich!

[quote]
Außen fliegen die Funken und innen die Fahrgäste.
[/quote]
[quote]
Zusätzlich meinte der Zugführer, es wird schlicht für nichts unter einem LKW auf den Schienen gebremst, weil man erfahrungsgemäß weniger Verletzte zu beklagen hat wenn man durch das Hinternis durchsaust, als wenn einem durch die Bremsung etliche Fahrgäste durch den Zug purzeln.
[/quote]
Das mit den durch die Gegend fliegenden Fahrgästen hört man immer wieder. Stimmt das wirklich und warum ist dem so? Mal eine einfache Rechnung. Ich gehe mal von konstanter Bremskraft (und damit Verzögerung) aus. Das wird bei hohen Geschwindigkeiten nicht stimmen, da hier eher die umzusetzende Energie der begrenzende Faktor ist. Aber bei konstantem Abbau kinetischer Energie ergibt sich zu Beginn der Bremsung eine noch niedrigere Verzögerung, als bei meiner Rechnung.
Also Bremsweg l=2300m bei v=250km/h (Schnellbremsung, Quelle: http://www.dafkurse.de/lernwelt/ereignisse/ice/ice.htm)
Mit l=0.5*a*t² und v=a*t folgt t=66.24s und a=1.048m/s²=0.107g.
Wie kommt es, dass bei einer so moderaten Verzögerung die Fahrgäste durch die Gegend fliegen und Verletze im Zug zu erwarten sind? Das ist nur durch ruckartiges Bremsen zu erklären. Ein weiches Einsetzen der Bremswirkung (und Zurückmehmen kurz vor dem Halt) sollte aber regelungstechnisch machbar seien und den Bremsweg nur minimal vergrössern.

@Hägar: Eine Straßenbahn mit Notbremsung und Sandstreuer bremst nicht “moderat”. Die, die ich damals gesehen habe, ist aus typischer Innenstadt-Geschwindigkeit mit einem Bremsweg von vielleicht 2 Metern stehen geblieben. Der Rest ist Physik.

@Hadmut

Schäm dich selbst !

Die technischen “Scherze” hast du kommentiert, aber auf die Verifikation bist du nicht eingegangen. Einfach nur “Mir leuchtet das nicht ein” gesagt und Schluß.

War das eine Übung zur Bewerbung als Quotenfrau oder war es einfach zu spät zum Nachdenken ?

Dir sollten die Probleme beim Verlängern und Verkürzen von Bussen bekannt sein. Und natürlich wurde von C++ geredet. Du hast nicht davon geschrieben, warst aber auch nicht der einzige Adressat.

> Und warum eine Verifikation mit einer Gedenksekunde einfacher sein
> soll, ist mir auch nicht ersichtlich.

Hat er aber eigentlich ziemlich plausibel gemacht. Verifikation von seiteneffektfreien Systemen ist beispielsweise auch erheblich einfacher – übrigens ein Grund dafür, warum man an funktionaler Programmierung forscht. Und dass einem, wenn man halt Seiteneffekte und Aktoren haben muss, eine Taktung innerhalb derer Objekte sich nur lokal verändern können die Arbeit stark vereinfachen kann, klingt unter dem Gesichtspunkt erstmal plausibel.

Das Money-Quote ist aber das hier:
“Als Bahn-Chef Rüdiger Grube vor einiger Zeit bei einem japanischen Hersteller vorfühlte, winkte dieser ab: Das Zulassungshickhack mit dem Eisenbahn-Bundesamt wolle man sich für keinen noch so großen Auftrag antun.”

@Hägar:

Ja, das passiert sehr heftig 🙂

Ich habe in den 80ern mal zwei Beamte der Bahn in Preismodellierungssoftware geschult, die beide aus der Praxis kamen.

Wenn ich mich recht an das erinnere, was die mir so alles erzählten, war es zumindest damals recht einfach:
Alle Fahrzeuge werden über Druckschläuche miteinander verbunden. Druck wird aufgebaut, der die Bremsen löst. Jetzt kann man an beliebiger Stelle die Druckleitung öffnen. Eine Notbremse macht sowas. Ebenso eine reißende Leitung, wenn sich ein Waggon von den anderen verabschiedet. Oder halt das elektromagnetische Teil, was dafür sorgt, daß man Züge von außen bremsen kann.

Diese Art Druckverlust wirkt binär. Es gibt nur die Zustände “ungebremst” (voller Druck auf der Leitung) und “blockieren” (Leitung offen).
Jetzt kann man noch zwei Komponenten hinzufügen: Eines ist ein Ventil, welches gesteuert den Druck verringert (damit kann man kontrolliert bremsen); die andere Komponente ist ein Kompressor.

Hat Joe oben schon beschrieben. Macht natürlich nicht so viel Eindruck wie eine SPS-Steuerung 🙂

@Hägar, den Spruch kannte ich nocht nicht *GRINS*
Kurz zu Deinen Zahlen, lt. Siemens beträgt beim ICE/T die mittlere Bremsverzögerung bei einer Schnellbremsung aus 140 km/h beträgt ca. 1,32 m/s². Aus 230 km/h sind es noch 1,20 m/s².
Schön zu sehen, das (bei gleichbleibender Bremskraft) die Verzögerung mit sinkender Geschwindigkeit ansteigt. Speziell kurz vor dem Stillstand wird es so richtig heftig. Wie sagte doch der Lehrlokführer immer: “Bremse kurz vorm Anhalten lösen, sonst stehen die Fahrgäste die in Fahrtrichtung sitzen zu Ehren des Lokführers auf.”
Eine mögliche Erklärung für die ‘fliegenden Fahrgäste’ wäre, das im Falle eine Zwangsbremsung die “Wohlfühlautomatik” der Bremse angeschaltet wird und mit allem was geht gebremst wird. Ich hatte schon ein paar mal das ‘Vergnügen’ einer Zwangsbremsung aus über 200 km/h. Wer da nicht darauf vorbereitet ist ‘fliegt’ halt.

@Hatmut, bei Wikipedia gibt es ein schönes Bild ICE beim Sand streuen:
http://de.wikipedia.org/w/index.php?title=Datei:Sanden_ICE3.jpg&filetimestamp=20070402213045

Die, die ich damals gesehen habe, ist aus typischer Innenstadt-Geschwindigkeit mit einem Bremsweg von vielleicht 2 Metern stehen geblieben. Der Rest ist Physik.

Mir gings mehr um den ICE. Dass Straßenbahnen deutlich wirksamere Bremsen haben, war mir nicht bewußt, sonst hätte ich das Zitat nicht gebracht. Es bleibt aber die Frage, warum man beim Zug erst bei »großen Brocken« auf dem Gleis die Schnellbremsung anwendet. Bei moderen elektronisch geregelten Bremsen sollte der Ruck doch kein Problem mehr seien.
@Hadmut: Dennoch hast Du Dich bei dem Beispiel mit der Straßenbahn geirrt. Zur Physik: Nehmen wir mal v=10m/s (36km/h) an. Bei 2m Bremsweg ergibt das eine Verzögerung von 25m/s², also etwas über 2,5g. Für Straßenbahnen sind bei einer Gefahrenbremsung Mindestverzögernungen von (bis zu) 2,73m/s² vorgeschrieben. (Quelle: http://www.gesetze-im-internet.de/strabbo_1987/anlage_2_78.html) Ich habe keine Angaben finden können, was in der Realität erreicht wird, aber mehr als das 9-fache ist unrealistisch. Bei Schienenbremsen sind Reibkoeffizienten von 0,5 (unklar, ob mit der ohne »Sanden«) angegeben. Auch hier liegen die 2,5 mit Sicherheit über dem Erreichbaren.

So genau hab ich dann da auch nicht hingeguckt, ich war davon ja auch überrascht.

Aber die Formulierung „Mindestverzögerungen von (bis zu)” ist auch schräg.

Nachdem technische und physikalische Fragen ausführlich erörtert sind, fehlt mir nur noch eine Antwort auf die Ausgangsfragen:

1) Ist eine Sekunde Verzögerung in dieser Anwendung (ICE, egal wie schnell der gerade ist) fachlich akzeptabel?

2) Wenn nein oder zweifelhaft: Wie kommt es, dass so ein Fehler(?) es bis in die Endabnahme schafft? Im Sinne von: Was macht uns so sicher, dass die Organisation / “das System” ansonsten zuverlässig ist? Wenn ein Design (wovon ich ausgehe) nach dann offenbar fragwürdigen Vorgaben entstanden ist? Wenn ein technisches System im Notfall zu komplex ist: Ist es dann nicht vielleicht grundsätzlich zu komplex? Oder vereinfacht im Sinne der vorherigen Ausführungen gefragt: Warum komplexe IT, wenn es auch mit Druckluft geht?

@Teasy, “Bremse kurz vorm Anhalten lösen” … auch beim Autofahren bremst Du so. Der Kopf knallt nicht am Anfang einer (Voll-)Bremsung an die Scheibe, sondern an deren Ende, wenn der Wagen dann zum Stillstand kommt.

@Hadmut: An welcher Uni hat man denn nur funktionale Programmierung im Informatikstudium? Mein Eindruck ist momentan ist Java überall Sprache der Wahl. Klar, soweit funktionale Programmierung behandelt wird in den Grundlagenvorlesungen für irgendwelche Fingerübungen kommt als mal ML oder Haskell zu Einsatz, aber normalerweise wird das Gros der softwaretechnischen Ausbildung doch in irgendeiner imperativen objektorientierten Sprache gemacht.

Und davon ab, selbst wenn einer aus einem reinen Theoriebiotop (von dem ich erstmal anzweifle das es in der Form existiert) in die Industrie kommt, dann setzt doch nicht plötzlich der Uni-Grünschnabel die Maßstäbe in was entwickelt wird?!

Es geht weniger um bestimmte Unis als um bestimmte Lehrstühle, die dann, wenn sie mit der Ausbildung dran sind, einfach das machen, wozu sie Lust haben und was sie können. oder nicht können. Es gibt eine Menge Lehrstühle, die etwas anderes als Java gelehrt haben, und viele Studenten, die außer der Pflichtvorlesung im Vordiplom/Bachelor nie wieder programmiert haben.

Lies mal da Buch über Scala von Odersky. Der kann sich nicht entscheiden, ob er ein Buch über eine Programmiersprache schreiben will oder zum funktionalen Programmieren evangelisieren. Dabei ist Scala in der Hinsicht sogar eher schlecht und chaotisch inkonsistent.