Ein paar Sekunden Stromausfall...
Ulf Kutzner
eine (halbe?) Stunde dauerte. Das Sortieren der Züge dauerte dem
Vernehmen nach länger.
Gruß, ULF
--
_______________________________________________________________________________
Ulf Kutzner
Backhaushohl 46
D-55128 Mainz
_______________________________________________________________________________
Thomas Reich
> ... führten in Ffm dazu, daß das erforderliche Hochfahren des Stellwerks
> eine (halbe?) Stunde dauerte. Das Sortieren der Züge dauerte dem
> Vernehmen nach länger.
Habe ich einen Teil des Threads verpasst? Ansonsten...
Welches Stellwerk? Wo wurde sortiert?
Gruss,
--
****************************Thomas Reich*******************************
thre...@stud.uni-sb.de Standard-disclaim-lall:
thr...@jurix.jura.uni-sb.de Alles Meins!! Auch die Meinung!
http://jurix.jura.uni-sb.de/~threich irc: tomtulpe
***********************************************************************
Holger Metschulat
> ... führten in Ffm dazu, daß das erforderliche Hochfahren des Stellwerks
> eine (halbe?) Stunde dauerte. Das Sortieren der Züge dauerte dem
> Vernehmen nach länger.
Ich denke, daß das das neue ESTW der Zulaufstrecken war. Das Booten aller
Rechner dauert eben seine Zeit. Wir wurden um 16.00 Uhr noch mit dem Eilzug
von Höchst über die S-Bahn-Gleise zum Hbf. geschickt.
--
Gruss * Holger Metschulat
Holger * e-mail: ho...@sgs.wh.tu-darmstadt.de
* http://www.sgs.wh.tu-darmstadt.de/homer
** "Verstaerker schwingen immer, Oszillatoren nie!" (Murphy) **
Michael Kauffmann
> > ... führten in Ffm dazu, daß das erforderliche Hochfahren des
> > Stellwerks eine (halbe?) Stunde dauerte.
> Das Booten aller Rechner dauert eben seine Zeit.
Die in Relaisstellwerken selbstverstaendlichen
Ueberbrueckungseinrichtungen spart man sich bei ESTWen?
Michael Kauffmann
Holger Metschulat
> Die in Relaisstellwerken selbstverstaendlichen
> Ueberbrueckungseinrichtungen spart man sich bei ESTWen?
Nach Radioberichten sind die Notdiesel nicht angesprungen. Da nix näheres
genannt wurde (und auch in den News nix anderes stand), weiß ich nicht, ob
jetzt das Relaisstellwerk im Hauptbahnhof oder die ESTW gemeint waren. Bei
den ESTW kann dann ja auch 'ne ganze Menge ausfallen, z.B. die
Bereichsstellrechner vor Ort oder die Bedienplätze in der Zentrale.
Übrigens hat FFH in seiner Senderanzeige (Radiotext ist das ja nicht) noch
um 13.00 vor dem Stellwerksausfall gewarnt.
Michael Kauffmann
>
> Michael Kauffmann <Michael....@GMX.NET> schrieb:
> > Die in Relaisstellwerken selbstverstaendlichen
> > Ueberbrueckungseinrichtungen spart man sich bei ESTWen?
>
> Nach Radioberichten sind die Notdiesel nicht angesprungen.
Fuer ein paar Sekunden sind die ja auch wenig nuetzlich.
Da waeren eher die Akkumulatoren gefragt.
Michael Kauffmann
Bertram Wlasak
>
> ... führten in Ffm dazu, daß das erforderliche Hochfahren des Stellwerks
> Vernehmen nach länger.
Haben die noch nichts von einer unterbrechungsfreien Stromversorgung
(USV) gehoert?
Gruss
Bertram
--
Bertram Wlasak
E-Mail: Bertram...@stud.uni-karlsruhe.de
Homepage: http://www.uni-karlsruhe.de/~Bertram.Wlasak
Hans Mueller
> ... führten in Ffm dazu, daß das erforderliche Hochfahren des Stellwerks
> eine (halbe?) Stunde dauerte. Das Sortieren der Züge dauerte dem
> Vernehmen nach länger.
Durch einen Kurzschluß in der Umspannstation Hattersheim sei _"für den
Bruchteil einer Sekunde"_ die Spannung abgefallen, berichtete eine
Sprecherin der Mainkraftwerke laut FR. In den Haushalten sei z.B. nur ein
Flackern des Lichts bemerkbar gewesen.
Bei der Bahn meldeten zehn angeschlossene Stellwerke den Spannungsverlust
an den "Zentralcomputer" des ESTW im Gallus. "Der hat sich wegen der
plötzlichen Datenflut aus Sicherheitsgründen abgeschaltet" (Bahnsprecher
Lange). Ohne die Intervention des Rechners hätten Notstromaggregate den
Bahnbetrieb aufrechterhalten.
Laut FR dauerte die Betriebsstörung etwa von 10.10 Uhr (Kurzschluß) bis
11.30 Uhr (Hbf konnte wieder angefahren werden).
Mit Gruß, Hans
--
URL: http://www.rz.uni-frankfurt.de/~hmvff/
Jürgen Burberg
Das lernt jeder EDV-Administrator in den ersten 2 Stunden seiner Ausbildung.
Gruß
Jürgen
Frank Spreer
Hans Mueller schrieb in Nachricht ...
.......
>Bei der Bahn meldeten zehn angeschlossene Stellwerke den
Spannungsverlust
>an den "Zentralcomputer" des ESTW im Gallus. "Der hat sich wegen der
>plötzlichen Datenflut aus Sicherheitsgründen abgeschaltet"
(Bahnsprecher
>Lange). Ohne die Intervention des Rechners hätten Notstromaggregate den
>Bahnbetrieb aufrechterhalten.
Dort möchte ich nicht der Sysad sein ;-)
Wird sowas nicht mal in Echtzeit getestet ? Wenn ich das in meiner Firma
machen würde... :(
MfG Frank
Tim Landscheidt
> ... führten in Ffm dazu, daß das erforderliche Hochfahren des Stellwerks
> eine (halbe?) Stunde dauerte. Das Sortieren der Züge dauerte dem
> Vernehmen nach länger.
Ist da keine Notstromversorgung vorgesehen?
Tim
Manfred Vogt 63791 Karlstein Germany
<hm...@dax-atm.rz.uni-frankfurt.de> wrote:
> Bei der Bahn meldeten zehn angeschlossene Stellwerke den Spannungsverlust
> an den "Zentralcomputer" des ESTW im Gallus. "Der hat sich wegen der
> plötzlichen Datenflut aus Sicherheitsgründen abgeschaltet" (Bahnsprecher
> Lange). Ohne die Intervention des Rechners hätten Notstromaggregate den
> Bahnbetrieb aufrechterhalten.
Schöne Umschreibung von Absturz. Könnte von Wilhelm Tor persönlich
sein ;-)
bye
Manfred Vogt
Wolfgang Schürmann
> Durch einen Kurzschluß in der Umspannstation Hattersheim sei _"für den
> Bruchteil einer Sekunde"_ die Spannung abgefallen, ...
> Bei der Bahn meldeten zehn angeschlossene Stellwerke den Spannungsverlust
> an den "Zentralcomputer" des ESTW im Gallus. "Der hat sich wegen der
> plötzlichen Datenflut aus Sicherheitsgründen abgeschaltet" (Bahnsprecher
> Lange).
Hi,
Das muß ja ein "gewaltiger" Meldungsschauer gewesen sein. Wie sowas zu
beherrschen ist, :-) vielleicht sollte man, ...., ach nein... nicht
heute:-)
> Ohne die Intervention des Rechners hätten Notstromaggregate den
> Bahnbetrieb aufrechterhalten.
Was soll denn der Quatsch, Leittechnik spielt verrückt, und son blöder
InselDiesel hält den Bahnbetrieb aufrecht??, Fragen über Fragen an den
Hr Lange, der noch lange nicht alles zu wissen scheint.
> Laut FR dauerte die Betriebsstörung etwa von 10.10 Uhr (Kurzschluß) bis
> 11.30 Uhr (Hbf konnte wieder angefahren werden).
Wenn jede fehlende Halbwelle den Betrieb zum Erliegen bringt, vielleicht
sollte man da mal ne mechanische Rückfallebene in Betracht ziehen, oder
ein parallel
laufendes, unabhängiges System.
mfg
WolfgangSch.
---KBS824---,
Andreas Barth
> Ich denke, daß das das neue ESTW der Zulaufstrecken war.
Für derlei wichtige Einrichtungen sollte man
Hochverfügbarkeitssysteme nehmen, die derartige Probleme nicht
haben.
Außerdem: Eine halbe Stunde ist schon mächtig viel, durch Einsatz
moderner Technik (z.B. Journailing File-Systems, mehrfach
zugreifbare Raids) kann man das auf wenige Minuten verkürzen.
Alles andere ist doch peinlich.
Andi
--
Andreas Barth <a...@muenchen.pro-bahn.org> PGP-Key auf Anforderung
======PGP-Fingerabdruck DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C======
Konfuzius sagt: "In jeder Pipe ist Platz für ein Perl-Script" Sven Paulus
Thomas Reincke
>
> ... führten in Ffm dazu, daß das erforderliche Hochfahren des Stellwerks
> eine (halbe?) Stunde dauerte. Das Sortieren der Züge dauerte dem
> Vernehmen nach länger.
Für ein paar Hundert Märker könnte ich meinen PC mit einer
unterbrechungsfreien Stromversorgung ausstatten. Weiß die DB nicht, das
es so etwas gibt, oder glauben sie nicht, so etwas zu brauchen?
Holger Metschulat
> moderner Technik (z.B. Journailing File-Systems, mehrfach
> zugreifbare Raids) kann man das auf wenige Minuten verkürzen.
... dann brauchst Du nur jemanden, der Dir diese Techniken für
Anforderungsklasse 7 prüft. Und zwar im Assemblercode!
Bei der Bahn gilt momentan noch: Sicherheit geht vor Verfügbarkeit. Deshalb
diese Sicherheitsabschaltung, ähnlich wie in Altona damals.
Holger Metschulat
> Schenken wir der Bahn eine USV!! :-)
Das Problem war offensichtlich nicht die USV, sondern die Anzahl der
Meldungen, die durch die USV verursacht wurden!
Holger Metschulat
> Laut FR dauerte die Betriebsst+rung etwa von 10.10 Uhr (Kurzschlu+) bis
Ausführlicher Artikel unter
http://www.frankfurter-rundschau.de/archiv/fr30t/19990315142.htm
Hans Sutter
Ist es möglich dass aufgrund eines kurzen Stromausfalles auf Fahrt stehende
Hauptsignale auf Halt zurückgestellt werden. Jedenfalls kann das bei uns in
der Schweiz ohne weiteres vorkommen. Dies hat natürlich zur Folge, dass Züge
über Blockabschnitte geleitet werden müssen die aufgrund der Haltstellung
nun "Strecke belegt" zeigen. Das hat unweigerlich längere "Arbeitszeiten"
pro Zug zur Folge. Damit liesse sich auch erklären weshalb der
Stromunterbruch während rund 1,5 Stunden Folgen zeigte.
Ich muss anmerken, dass ich die Sicherungstechnik der deutschen Bahn nicht
kenne. Es mag sein, dass dort andere Sicherheitsmassnahmen zu treffen sind.
Hans Sutter
Ulf Kutzner schrieb in Nachricht <36ECDF...@mail.uni-mainz.de>...
>... führten in Ffm dazu, daß das erforderliche Hochfahren des Stellwerks
>eine (halbe?) Stunde dauerte. Das Sortieren der Züge dauerte dem
>Vernehmen nach länger.
>
>Gruß, ULF
>--
>___________________________________________________________________________
Hans Sutter
Unsere Stellwerke sind normalerweise wie folgt gespeist: Ortnetz
(öffentliche Stromversorgung) - Speisegerät - Batterie. Sobald das Ortsnetz
ausfällt wird einfach mit dem Batteriestrom weitergearbeitet. Totzdem kann
es vorkommen, dass die Strommessschlaufe der Fahrtlampe einen kurzen
Spannungsabfall registriert und deshalb das auf Fahrt stehende Signal auf
Halt zurückstellt. Damit entsteht eine Signalstörung, die
Sicherheitsmassnahmen nach sich zieht, welche vor allem auf dicht befahrenen
Strecken zu zeitlichen Verzögerungen führt. Unser Batterie-Stromversorgung
lässt auch das Umlegen von Weichen zu, allerdings muss jede Weiche einzeln
umgelegt (Maximalstrom) werden. Allein dieser Vorgang kann in grösseren
Anlagen Verspätungen verursachen
Hans Sutter
Jürgen Burberg schrieb in Nachricht
<36ed4...@juno.wiesbaden.netsurf.de>...
>Schenken wir der Bahn eine USV!! :-)
Thomas Reincke
> Wenn jede fehlende Halbwelle den Betrieb zum Erliegen bringt, vielleicht
> sollte man da mal ne mechanische Rückfallebene in Betracht ziehen, oder
> ein parallel
> laufendes, unabhängiges System.
<bg>
sind die Halbwellen vom VT 611 nicht mechanisch?
</bg>
Armin Muehl
>
> Ob eine USV was nützt wage ich zu bezweifeln.
> Unsere Stellwerke sind normalerweise wie folgt gespeist: Ortnetz
> (öffentliche Stromversorgung) - Speisegerät - Batterie. Sobald das Ortsnetz
> ausfällt wird einfach mit dem Batteriestrom weitergearbeitet.
Du meinst ein Dr-Stellwerk?
> Totzdem kann
> es vorkommen, dass die Strommessschlaufe der Fahrtlampe einen kurzen
> Spannungsabfall registriert und deshalb das auf Fahrt stehende Signal auf
> Halt zurückstellt. Damit entsteht eine Signalstörung,[...]
Ein ESTW hat Computer und keine stromfressende Klappertechnik, die man daher
problemlos ueber eine ausreichend dimensionierte USV mit Batterien versorgen
kann. Da gibt es auch keinen kurzzeitigen Ausfall, der zum Komplettabsturz von
Rechnern fuehrt, wenn mal der Strom aus dem oeffentlichen Netz wegbleibt.
Es ist klar, dass bei grossen Stromverbrauchern, wie Weichen natuerlich
eine eigene leistungsfaehige USV notwendig ist, damit nicht beim ersten
Umstellversuch einer Weiche die Versorgung fuer die Computer zusammenbricht...
Mein Arbeitgeber (privater Telekommunikationsanbieter) hat fuer die
Vermittlungsanlage eine batteriegestuetzte USV, die 4h Vollastbetrieb der
Vermittlungsanlage sicher gewaehrleistet. Als letztens wegen Bauarbeiten fuer
eine Stunde der Strom abgeschaltet wurde, war ausser der USV-Meldung nichts los.
Keine Stoerung, gar nichts. Wirklich eine unterbrechungsfreie Stromversorgung
:-)
Und das schafft das Unternehmen Zukunft beim ESTW nicht?
So langsam werde ich nachdenklich...
Armin
--
http://www.muenster.de/~amuehl (Muehl privat)
http://home.t-online.de/home/muehl.armin/mfm.htm
(Muensterlaendisches Feldbahnmuseum e.V.)
Wolfgang Evers
Armin Muehl <amu...@muenster.de> writes:
> Ein ESTW hat Computer und keine stromfressende Klappertechnik, die man daher
> problemlos ueber eine ausreichend dimensionierte USV mit Batterien versorgen
> kann.
Hallo Armin,
ich meine mal gelesen zu haben, daß digitale Orstvermittlungsstellen der Telekom
wesentlich mehr Energiebedarf haben, als die alten Relaisvermittlungen. Ich
vermute, daß dies bei der Bahn dann auch zutrifft.
Gruß Wolfgang
Marko Lorentz
>
> Mein Arbeitgeber (privater Telekommunikationsanbieter) hat fuer die
> Vermittlungsanlage eine batteriegestuetzte USV, die 4h Vollastbetrieb der
> Vermittlungsanlage sicher gewaehrleistet. Als letztens wegen Bauarbeiten fuer
> eine Stunde der Strom abgeschaltet wurde, war ausser der USV-Meldung nichts los.
> Keine Stoerung, gar nichts. Wirklich eine unterbrechungsfreie Stromversorgung
> :-)
>
> Und das schafft das Unternehmen Zukunft beim ESTW nicht?
> So langsam werde ich nachdenklich...
>
> Armin
Bitte lies den Thread sorgfältiger,
Strommangel war in Frankfurt nicht das Problem.
ml
Holger Metschulat
> ich meine mal gelesen zu haben, daß digitale Orstvermittlungsstellen der Telekom
> wesentlich mehr Energiebedarf haben, als die alten Relaisvermittlungen. Ich
> vermute, daß dies bei der Bahn dann auch zutrifft.
Bei der Telekom ist das richtig - die Drehwähler zogen nur während des
Wählens Strom, während die Digitaltechnik immer Strom zieht, auch wenn der
Anschluß gar nicht abgehoben hat.
Bei der Bahn ist das aber etwas anders. Dort gibt es viele Relais, die auch
in Grundstellung angezogen sind, außerdem frißt die Stelltischausleuchtung
eine Menge Strom, mal ganz abgesehen von den Signalen in der Außenanlage.
Diese müssen bei einem Stromausfall ja auch weiterhin leuchten.
Michael Kauffmann
>
> Hans Sutter schrieb:
> >
> > Totzdem kann
> > es vorkommen, dass die Strommessschlaufe der Fahrtlampe einen kurzen
> > Spannungsabfall registriert und deshalb das auf Fahrt stehende Signal
> > auf Halt zurückstellt. Damit entsteht eine Signalstörung,[...]
>
Auch keine Signallampen mehr?
Michael Kauffmann
Jürgen Burberg
das stimmt mich ebenfalls sehr nachdenklich. Zumal "normale" Rechenzentren
häufig überhaupt nur mit Batterien gespeist werden. Das allgemeine Ortsnetz
wiederum dient nur dazu, die Batterien ständig in einem entsprechenden
Ladezustand zu halten. Somit "merkt" das Rechnersystem noch nicht einmal,
daß das Ortsnetz zusammengebrochen ist. Sollte das Ortsnetz dann mal
ausfallen, sollten Notstromdiesel einspringen. Dieser Vorgang ist also nicht
besonders zeitkritisch. Somit kann locker die Zeit überbrückt werden, die
für Synchronisierung, Stabilisierung usw. benötigt wird. Wenn ein
Unternehmen wie die DBAG das nicht auf die Rolle kriegt, kann man nur noch
sein äußerstes Bedauern ausdrücken. Dann wundert mich bei der Bahn mit ihren
zunehmenden Unfallserien überhaupt nichts mehr.
Hier scheint es einen erheblichen Beratungs- und Optimierungsbedarf zu
geben.
Mit "Unternehmen Zukunft" hat so etwas aber wirklich nichts mehr zu tun.
Beste Grüße aus Wiesbaden
Jürgen Burberg
e-Mail: bur...@burberg.de
Internet: http://www.burberg.de
Armin Muehl
wrote:
>Armin Muehl schrieb:
>Bitte lies den Thread sorgfältiger,
>Strommangel war in Frankfurt nicht das Problem.
Ich habe sorgfaeltig gelesen.
Es kann doch wohl nicht sein, dass mehrere Stoerungsmeldungen dieser
Art fuer eine derartige Stoerung sorgen, oder?
Vor allem frage ich mich, warum ueberhaupt grossartige Meldungen
kommen.
Wenn bei uns der Strom wegbleibt, dann gibt es eine *Warnung* und
nicht mehr. Trotzdem laueft alles weiter. Mehr als die Warnung, das
auf USV geschaltet wurde, braucht man auch erstmal nicht.
Diese Warnung kommt uebrigens nicht von der Vst, sondern von der USV.
Das sind zwei getrennte Systeme.
Wenn bei jeder Netzstoerung gleich so ein Theater bei uns losginge,
dann waere bald nicht mehr viel mit telefonieren...
Armin
--
Armin Muehl
Ulf Kutzner
> > Vermittlungsanlage sicher gewaehrleistet. Als letztens wegen Bauarbeiten fuer
> > eine Stunde der Strom abgeschaltet wurde, war ausser der USV-Meldung nichts los.
> > Keine Stoerung, gar nichts. Wirklich eine unterbrechungsfreie Stromversorgung
> > :-)
> >
> > Und das schafft das Unternehmen Zukunft beim ESTW nicht?
> > So langsam werde ich nachdenklich...
> >
> > Armin
>
> Bitte lies den Thread sorgfältiger,
> Strommangel war in Frankfurt nicht das Problem.
Dann war es die Konfiguration der Anlage oder was auch immer. Armin
schrieb zum unterbrechungs- und störungsfreien Weiterbetrieb, den er
vermisse, ich vermisse ihn auch.
Gruß, ULF
--
_______________________________________________________________________________
Michael Kauffmann
>
> Marko Lorentz wrote:
>
> > Bitte lies den Thread sorgfältiger,
> > Strommangel war in Frankfurt nicht das Problem.
>
> Dann war es die Konfiguration der Anlage oder was auch immer. Armin
> schrieb zum unterbrechungs- und störungsfreien Weiterbetrieb, den er
> vermisse, ich vermisse ihn auch.
Hans vermutete, dasz das kurzzeitige Verloeschen der Signallampen als
Stoerung an denselben interpretiert worden sei (was auch ein ESTW mit
Notrot beantworten sollte). Armin antwortete darauf, dasz ESTW keine
"stromfressende Klappertechnik" haetten. Das ist eindeutig nicht richtig
gelesen, auch wenn seine grundsaetzliche Aussage Zustimmung findet.
Michael Kauffmann
Holger Metschulat
> Vor allem frage ich mich, warum ueberhaupt grossartige Meldungen
> kommen.
Der Stellwerker muß ja wissen, ob seine Bereichsstellrechner noch arbeiten
und wie sie versorgt werden.
> Wenn bei uns der Strom wegbleibt, dann gibt es eine *Warnung* und
> nicht mehr. Trotzdem laueft alles weiter. Mehr als die Warnung, das
Diese Warnungen liefen am Zentralrechner wohl auch auf. Ich denke mal, daß
dort eine Nachrichtenwarteschlange existiert, die diese Meldungen aufnimmt,
und die nacheinander abgearbeitet werden. Läuft diese Warteschlange über, so
schaltet sich der Zentralrechner ab, denn es könnte dann ja eine
sicherheitsrelevante Meldung unter den Tisch fallen.
Armin Muehl
<ho...@sgs.wh.tu-darmstadt.de> wrote:
>Armin Muehl <muehl...@t-online.de> schrieb:
>> Vor allem frage ich mich, warum ueberhaupt grossartige Meldungen
>> kommen.
>
>Der Stellwerker muß ja wissen, ob seine Bereichsstellrechner noch arbeiten
>und wie sie versorgt werden.
Wenn es *ohne* Unterbrechung weiter geht, dann ist das eine eher
unwichtigere Meldung.
>Diese Warnungen liefen am Zentralrechner wohl auch auf. Ich denke mal, daß
>dort eine Nachrichtenwarteschlange existiert, die diese Meldungen aufnimmt,
>und die nacheinander abgearbeitet werden. Läuft diese Warteschlange über, so
>schaltet sich der Zentralrechner ab, denn es könnte dann ja eine
>sicherheitsrelevante Meldung unter den Tisch fallen.
Bei uns kommen die Meldungen sofort auf den Bildschirm in der
Reihenfolge, wie sie auflaufen. Da gibt es auch eine manchmal etwas
laengere Liste, wenn viel Murks auf einen Schlag passiert. Bis da aber
die Warteschlange ueberlaeuft, dauert es.
Da fragt man sich doch, wie gross dimensioniert man eine
Warteschlange...
Holger Metschulat
> Wenn es *ohne* Unterbrechung weiter geht, dann ist das eine eher
> unwichtigere Meldung.
Naja, dann ist z.B. der Weichenselbstlauf langsamer, da immer nur eine
Weiche gleichzeitig umläuft. Außerdem ist dies eine Störungsmeldung, die für
den weiteren Betrieb nicht unerheblich sein kann.
Wolfgang Evers
Holger Metschulat <ho...@sgs.wh.tu-darmstadt.de> writes:
> Bei der Bahn ist das aber etwas anders. Dort gibt es viele Relais, die auch
> in Grundstellung angezogen sind, außerdem frißt die Stelltischausleuchtung
> eine Menge Strom, mal ganz abgesehen von den Signalen in der Außenanlage.
> Diese müssen bei einem Stromausfall ja auch weiterhin leuchten.
Hallo Holger,
und beim ESTW gibt es keine Lichtsignale mehr? ;-)
Gruß Wolfgang
Holger Metschulat
> und beim ESTW gibt es keine Lichtsignale mehr? ;-)
... Haupt- und Vorsignale haben aber bei den Ks-Signalen einen Leuchtpunkt,
während es bei Hp00 und Vr0 jeweils zwei waren -> Ks-Signalsystem trägt zum
Energiesparen bei ;-)
Gerd Bretschneider
> > ... führten in Ffm dazu, daß das erforderliche Hochfahren des
> > Stellwerks
> > eine (halbe?) Stunde dauerte. Das Sortieren der Züge dauerte dem
> > Vernehmen nach länger.
>
> Ich denke, daß das das neue ESTW der Zulaufstrecken war. Das Booten aller
> Rechner dauert eben seine Zeit. Wir wurden um 16.00 Uhr noch mit dem Eilzug
> von Höchst über die S-Bahn-Gleise zum Hbf. geschickt.
Das Booten kostet m.W. auch nicht mehr Zeit als beim heimischen PC. Das
Problem liegt mehr bei der Datenneueingabe, da (aus Sicherheitsgründen)
keine aktuellen Daten gespeichert werden. Gibt es hier zufällig einen
Fdl, der sich mit der Technik auskennt?
Tschüß
GERD
--
Forth (F-PC) für Anfänger, VGA-Grafikprogrammierung: "Brettis Forth Ecke"
und auch Eisenbahn/Modellbahn in: BBS Chat Noir, 030/382 26 99
G.Brets...@TMB.in-berlin.de
Tel. 030-6734583
## CrossPoint v3.11 R ##
Gerd Bretschneider
<ESTW-Rechentechnik>
> Für derlei wichtige Einrichtungen sollte man
> Hochverfügbarkeitssysteme nehmen, die derartige Probleme nicht
> haben.
Nach Standard-PC sah mir die Technik nicht aus......
(Allerdings kann ich nur aus der Besichtigung mehrere ESTW's
schlußfolgern.)
> Außerdem: Eine halbe Stunde ist schon mächtig viel, durch Einsatz
> moderner Technik (z.B. Journailing File-Systems, mehrfach
> zugreifbare Raids) kann man das auf wenige Minuten verkürzen.
> Alles andere ist doch peinlich.
Fragt sich, ob diese Technik die erforderliche Sicherheit garantieren
(G A R A N T I E R E N nicht gewährleisten!!!!!) kann. Es kommt hier
weniger auf das Hantieren mit Daten als auf das Steuern komplexer
Systheme an.
Da ich mich auf die ESTW-Technik verlassen MUSS, ist es mir lieber,
im Störungsfalle mal eine Weile zu warten.
Manfred Vogt 63791 Karlstein Germany
<ho...@sgs.wh.tu-darmstadt.de> wrote:
> Diese Warnungen liefen am Zentralrechner wohl auch auf. Ich denke mal, daß
> dort eine Nachrichtenwarteschlange existiert, die diese Meldungen aufnimmt,
> und die nacheinander abgearbeitet werden. Läuft diese Warteschlange über, so
> schaltet sich der Zentralrechner ab, denn es könnte dann ja eine
> sicherheitsrelevante Meldung unter den Tisch fallen.
Dann möchte ich mal wissen, wie das der Heise Web-Server macht, der
pro Tag bis zu 3,5 MIO Requests bearbeitet (das sind ca. 40/Sekunde),
ohne "aus Sicherheitsgründen abzuschalten". Kann man in der aktuellen
c't nachlesen.
Aber mal im Ernst, das wegen so was sich ein Rechner abschaltet ist ja
wohl ein Witz. Normalerweise wird wohl bei so einem Vorfall in eine
andere Betriebsart umgeschaltet und da braucht man wohl nicht neu
booten. Anders sieht es natürlich aus, wenn die Kiste abstürzt, wie
ich bereits angedeuted hatte. Und außerdem: eine Technik, die mit so
was nicht fertig wird, ist fürs Klo. Wahrscheinlich ist da wieder
Siemens mit im Spiel und die haben ja damals in Hamburg schon
bewiesen, was für Stümper die sind.
bye
Manfred Vogt
Holger Paulsen
> Nach Standard-PC sah mir die Technik nicht aus......
> (Allerdings kann ich nur aus der Besichtigung mehrere ESTW's
> schlußfolgern.)
Standard-PC sicher nicht. Aber fuer ESTW werden m.W.
Standard-Intel-286 oder -386 eingesetzt. Nicht die neueren
Modelle, denn die sind zu komplex, um die Fehlerfreiheit zu
dokumentieren.
Holger
Holger Paulsen
> Es kann doch wohl nicht sein, dass mehrere Stoerungsmeldungen dieser
> Art fuer eine derartige Stoerung sorgen, oder?
> Vor allem frage ich mich, warum ueberhaupt grossartige Meldungen
> kommen.
Sicherheitsrelevanz. Wenn in einer Aussenstelle die USV
anspricht, dann wird sicher das auch der Zentrale gemeldet.
Und die Zentrale wird Zugfahrten in den Bereich dieser
Aussenstelle nicht zulassen, bis die Aussenstelle kurz
darauf meldet, dass sie trotzdem einsatzfaehig ist.
Und wenn die Zentrale mit solchen Stoerungs- und
OK-Meldungen von *vielen* Aussenstellen ueberhaeuft wird,
dann sehe ich durchaus die Moeglichkeit, dass die Zentrale
ausser Tritt geraet und eventuell die OK-Meldungen von
einigen Aussenstellen *vor* den USV-Stoerungsmeldungen
abarbeitet. Und dann haben wir den Salat, oder dass einige
Meldungen gar nicht mehr aufgenommen werden koennen, weil
die Ressourcen erschoepft sind: und da die
Stoerungsmeldungen sicherheitsrelevanter als die
OK-Meldungen sind, ist es auch klar, welche als erstes unter
den Tisch fallen.
Offensichtlich hat in diesem Fall der Hersteller des Systems
ein moegliches Problem unterschaetzt, und die Bahntechnik
hat getan, was sie soll: zur sicheren Seite hin reagiert.
Holger
Michael Suda
Armin Muehl schrieb in Nachricht
<36ee3df4...@news.btx.dtag.de>...
>>Strommangel war in Frankfurt nicht das Problem.
>
>
>Es kann doch wohl nicht sein, dass mehrere
Stoerungsmeldungen dieser
>Art fuer eine derartige Stoerung sorgen, oder?
Na, was glaubst denn du? Stell dir vor, du wärst ein EStW
und es gibt eine *klitzekleine* Spannungsschwankung.....
Und dann ist der Teufel los!
6 Achszähler melden: "Nanu, *hicks*, war'n das jetzt 25 oder
26, muß nochmal zählen..." 27 Signale könne dir gleichzeitig
nicht mehr sagen, ob sie jetzt grün, rot, gelb oder blau
leuchten. 14 Weichen können sich nicht an ihre Endlage
erinnern usw. Wenn du ein EStW wärst, wäre deine Antwort
darauf auch: "Megashit! Was iss'n da schon wieder in die
Hose gegangen?" Und wenn dein Programmierer die richtigen
Befehlen getippt hat, tätest du auch fürs erste alles
abdrehn und drauf warten, daß ein Mensch, der Signale eben
auch optisch ablesen kann, überprüft, ob eh noch alles seine
Ordnung hat.
----------------------------------------------
Michael Suda
Promenadegasse 11-13/1/5, 1170 Wien
michae...@blackbox.at (privat)
michae...@bka.gv.at (Büro)
michae...@magnet.at (WWW- & Usenet-Replies)
----------------------------------------------
KaiLudwig
>Hans Sutter schrieb:
>>
>> Ob eine USV was nützt wage ich zu bezweifeln.
>> Unsere Stellwerke sind normalerweise wie folgt gespeist: Ortnetz
>> (öffentliche Stromversorgung) - Speisegerät - Batterie. Sobald das Ortsnetz
>> ausfällt wird einfach mit dem Batteriestrom weitergearbeitet.
>
>Du meinst ein Dr-Stellwerk?
Oder überhaupt elektrisch funktionierende Stellwerke, also auch
elektromechanisch oder Mischbauten mechanisch/Gleisbild. Bei Stromausfall wird
die Anlage aus Batterien über einen Umformer gespeist, in aller Regel gibt es
auch ein Notstromaggregat.
>Es ist klar, dass bei grossen Stromverbrauchern, wie Weichen natuerlich
>eine eigene leistungsfaehige USV notwendig ist, damit nicht beim ersten
>Umstellversuch einer Weiche die Versorgung fuer die Computer
>zusammenbricht...
Wo Notstromaggregate vorhanden sind, hat man die Batterieanlage meist recht
bescheiden ausgeführt; sollte der Diesel nicht anspringen ist es dringend
geraten, die Finger von den Weichen zu lassen. Aber das ist hier nicht der
Punkt, da es lediglich um die Stellrechner des ESTW ging, nicht um die
Bedienbarkeit von Weichen.
>Mein Arbeitgeber (privater Telekommunikationsanbieter) hat fuer die
>Vermittlungsanlage eine batteriegestuetzte USV, die 4h Vollastbetrieb der
>Vermittlungsanlage sicher gewaehrleistet.
Bei der DR wurden die Batterien bei Stellwerken ohne Notstromaggregat für acht
Stunden Betrieb dimensioniert. Ist ein Diesel vorhanden, sollten sie zwei
Stunden halten, aber das ist Theorie, siehe oben.
>Als letztens wegen Bauarbeiten fuer
>eine Stunde der Strom abgeschaltet wurde, war ausser der USV-Meldung nichts
>los.
>Keine Stoerung, gar nichts.
Der Fdl auf einem klassischen Stellwerk kennt es nicht anders. Bei Stromausfall
gibt es zwar ggf. Probleme, aber die haben (vom Störungsfall des Notdiesels
abgesehen) nichts mit den Sicherungsanlagen zu tun, sondern beziehen sich auf
stockfinstere Reiseverkehrsanlagen u.dgl.
-kl
Till Kinstler
>
> On Tue, 16 Mar 1999 11:40:12, Holger Metschulat
> <ho...@sgs.wh.tu-darmstadt.de> wrote:
>
> > Diese Warnungen liefen am Zentralrechner wohl auch auf. Ich denke mal, daß
> > dort eine Nachrichtenwarteschlange existiert, die diese Meldungen aufnimmt,
> > und die nacheinander abgearbeitet werden. Läuft diese Warteschlange über, so
> > schaltet sich der Zentralrechner ab, denn es könnte dann ja eine
> > sicherheitsrelevante Meldung unter den Tisch fallen.
>
> Dann möchte ich mal wissen, wie das der Heise Web-Server macht, der
> pro Tag bis zu 3,5 MIO Requests bearbeitet (das sind ca. 40/Sekunde),
> ohne "aus Sicherheitsgründen abzuschalten". Kann man in der aktuellen
> c't nachlesen.
Der c't-Webserver MUSS eingehende Requests nicht beantworten und schon
garnicht in definierter Zeit. Er KANN Requests beantworten und wenn's
ihm zuviel wird, bleiben einfach Anfragen unbeantwortet oder es passiert
im schlimmsten Fall irgendwas undefiniertes. Das ist der Unterschied.
Dieser "Zentralrechner" bei der Bahn, der da ausgefallen ist, MUSS
sicher definiert auf alle Arten von Meldungen und Requests in
definierter Zeit antworten koennen. Wenn das nicht mehr gewaehrleistet
ist, dann ist es besser, dass er sich abschaltet...
Leider werden auch bei solchen sicherheitskritischen Systemen Fehler
gemacht... So soll bei dem AKW-Stoerfall in Harrisburg ein Problem
gewesen sein, dass mehr Stoerungsmeldungen auftraten, als das System
anzeigen konnte. Angeblich war in dem System keine Moeglichkeit
vorgesehen, Meldungen nochmals anzeigen zu lassen. So sollen wichtige
und kritische Stoermeldungen, die eine Entscheidung beeinflusst haetten,
einfach verloren gegangen sein. Ich weiss nicht, ob das eine "urban
legend" ist (hatten die keine Protokolldrucker oder Logfiles?), aber
letztes Jahr erzaehlte Prof. Stieber von der FH Nuernberg die Geschichte
noch in einem Vortrag ueber "Softwaresicherheit"... Wenn ein
sicherheitskritisches System also Aufgaben nicht mehr verarbeiten kann,
schaltet es also besser auf "Notaus"... Der c't-Webserver faellt sicher
nicht in die Kategorie "sicherheitskritisch".
> Und außerdem: eine Technik, die mit so
> was nicht fertig wird, ist fürs Klo.
Leider werden oft Fehler in der Definitionsphase solcher Systeme
gemacht. Es gibt einfach Dinge, an die keiner denkt. Immerhin hat sich
der Rechner der Bahn abgeschaltet und hat nicht irgendeinen anderen
Unsinn gemacht, das ist schon viel wert...
Gruss
Till
--
Till Kinstler ti...@fs.is.uni-sb.de
http://www.phil.uni-sb.de/~till/ ti...@phil.uni-sb.de
student of information science ti...@stud.uni-sb.de
Dringendes im SUBJECT (80 Zeichen) an: 5742651 (a) skyper.de (a)=@
Armin Muehl
<michae...@magnet.at> wrote:
>>Es kann doch wohl nicht sein, dass mehrere
>Stoerungsmeldungen dieser
>>Art fuer eine derartige Stoerung sorgen, oder?
>
>Na, was glaubst denn du? Stell dir vor, du wärst ein EStW
>und es gibt eine *klitzekleine* Spannungsschwankung.....
>Und dann ist der Teufel los!
Bei einer vernuenftigen Stromversorgung kommt es erst gar nicht so
weit...
Frank Spreer
Michael Kauffmann schrieb in Nachricht <36EF8...@GMX.NET>...
>Till Kinstler wrote:
>
>> Leider werden auch bei solchen sicherheitskritischen Systemen Fehler
>> gemacht... So soll bei dem AKW-Stoerfall in Harrisburg ein Problem
>> gewesen sein, dass mehr Stoerungsmeldungen auftraten, als das System
>> anzeigen konnte. Angeblich war in dem System keine Moeglichkeit
>> vorgesehen, Meldungen nochmals anzeigen zu lassen. So sollen wichtige
>> und kritische Stoermeldungen, die eine Entscheidung beeinflusst
haetten,
>> einfach verloren gegangen sein. Ich weiss nicht, ob das eine "urban
>> legend" ist (hatten die keine Protokolldrucker oder Logfiles?),
>
>heute für selbstverständlich halten, noch unbekannt gewesen sein.
>Vielleicht war dieses "System" nicht mal ein Computer im heutigen
Sinne?
>
Wird zwar jetzt endgültig O, aber damals gabs noch keine
Rechnersteuerung im heutigen Sinne, da gabs auch noch keine
Prozeßsteuerung a'la SIMATIC & Co. Das waren noch klassische
Einzelregelkreise, was aber die nichtwiederholbaren Störungsmeldungen
nicht ausschließt. Wenn die einmal bestätigt sind, sind sie zwar
statisch da, erregen aber keine Aufmerksamkeit mehr.
MfG Frank
Frank Spreer
Holger Metschulat schrieb in Nachricht
<7co26r$mde$1...@sun27.hrz.tu-darmstadt.de>...
>Ulf Kutzner <kutz...@mail.uni-mainz.de> schrieb:
>
>> Bei einigen der genannten Anlagen ist es mit einem schlichten
>> "Abschalten" nicht getan, sondern ein mehrstündiges kontrolliertes
>> Herunterfahren ist gefragt.
>
>Gut, aber der Rechner versucht nicht, mit den vielleicht kaputten
>Eingabewerten den Prozeß weiterzubetreiben.
>
Hm, mein Leitsystem (Kraftwerk) _muß_ den Prozeß weiterbetreiben, sonst
betreibt der Prozeß uns ;-), insofern ist das wohl nicht vergleichbar
mit einem ESTW, da kann man alle Signale auf Halt setzen.
MfG Frank
Martin Ebert
> >Ist das nicht schon Jahrzehnte her? Da dürfte wohl Manches, was wir
> >heute für selbstverständlich halten, noch unbekannt gewesen sein.
> >Vielleicht war dieses "System" nicht mal ein Computer im heutigen
> Sinne?
> >
> Wird zwar jetzt endgültig O, aber damals gabs noch keine
> Rechnersteuerung im heutigen Sinne, da gabs auch noch keine
> Prozeßsteuerung a'la SIMATIC & Co. Das waren noch klassische
Moment. Wann "damals"?
Harrisburg???
Ab anfang der 70ger Jahre gab es z.B. Honeywell.
> Einzelregelkreise, was aber die nichtwiederholbaren Störungsmeldungen
> nicht ausschließt. Wenn die einmal bestätigt sind, sind sie zwar
> statisch da, erregen aber keine Aufmerksamkeit mehr.
Ab anfang der 70ger Jahre waere diese Aussage flasch.
Martin Ebert
Manfred Vogt 63791 Karlstein Germany
wrote:
> einlesen" einfach terminieren konnte. Naja, die Amis hatten angeblich
> schon ein minutenlang totes Kriegsschiff, weil sich der NT-Rechner
> aufgehängt hatte ...
Es waren fast 3 Stunden und das Schiff, die USS Yorktown mußte dann in
den Hafen geschleppt werden. Das dollste aber ist, das auf diesem sog.
Smart Ship die Rechnertechnik NICHT redundant ist. Aber wer für so was
eNTe nimmt, hat sowieso ein Rad ab.
bye
Manfred Vogt
Manfred Vogt 63791 Karlstein Germany
<ho...@sgs.wh.tu-darmstadt.de> wrote:
> Manfred Vogt 63791 Karlstein Germany <Ma...@t-online.de> schrieb:
> > Dann möchte ich mal wissen, wie das der Heise Web-Server macht, der
> > pro Tag bis zu 3,5 MIO Requests bearbeitet (das sind ca. 40/Sekunde),
>
> An der korrekten Funktion des Heise-Webservers hängen auch keine
> Menschenleben.
Der ist allerdings auch nicht redundant ausgeführt und hat wohl auch
wesentlich mehr zu tun als der genannte Zentralrechner mit gerade mal
10 Meldungen.
> Ich bin froh, daß der Rechner sich abgeschaltet hat und nicht versucht hat,
> mit möglicherweise verfälschten Daten weiterzuarbeiten. Einige Leute haben
> hier von der Sicherheitsrelevanz von Stellwerksanlagen wohl falsche
> Vorstellungen. Schon bei mechanischen Stellwerken muß _nachgewiesen_ werden,
> daß diese fehlerfrei arbeiten. Dort ging das noch ganz einfach, weil man
> sich das vorstellen konnte. Bei den ESTW muß man nachweisen, daß die
> Hardware fehlerfrei ist und daß die Software fehlerfrei ist (letztere
> entweder am Maschinencode bzw. am Quellcode mit geprüftem Compiler), und das
> ist nicht mehr ganz so trivial. Wie schon geschrieben, Sicherheit geht vor
> Verfügbarkeit.
Sehe ich auch so, aber: siehe oben. Mich wundert nur, daß es satte 80
Minuten dauert, bis überhaupt irgend etwas wieder geht. Wenn die
Verfügbarkeit gegen NULL geht, ist das System unbrauchbar. IMHO war da
noch was anderes im Spiel. Da würde mich schon mal genau
interressieren, was für eine Technik da eingesetzt wird?
bye
Manfred Vogt
Andreas Barth
> Jedenfalls hat da jemand beim Systementwurf
> gepennt, und offenbar war dann auch niemand da, der den Task "USV-Meldung
> einlesen" einfach terminieren konnte. Naja, die Amis hatten angeblich
> schon ein minutenlang totes Kriegsschiff, weil sich der NT-Rechner
> aufgehängt hatte ...
Der NT-Rechner hatte sich aufgehängt, weil jemand in ein
netzwerkweites Steuerungsfeld den Wert 0 eingegeben und das dann
auf allen Systemen zu einem "Divison by zero"-Fehler geführt hat.
In comp.risks stand das relativ ausführlich.
Andi
--
Andreas Barth <a...@muenchen.pro-bahn.org> PGP-Key auf Anforderung
======PGP-Fingerabdruck DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C======
Konfuzius sagt: "In jeder Pipe ist Platz für ein Perl-Script" Sven Paulus
Andreas Barth
> "Kontrolliert" heißt beim ESTW (und bei anderen sicherheitskritischen
> Techniken, z.B. Atomkraftwerk oder Chemie-Prozeßanlage) "Abschalten", weil
> der Rechner (bzw. der Programmierer) nicht garantieren kann, daß der Zustand
> nach der Ausnahmesituation konsistent ist. So kann z.B. durch den
> Pufferüberlauf die Meldung einer Gleisbesetzung verloren gegangen sein.
> Dadurch fällt das Startsignal nicht auf Halt, d.h., der Zug kann weiter auf
> ein besetztes Gleis fahren.
Sobald der Verlust von Meldungen nicht ausgeschlossen werden
kann, muß natürlich "Abschalten" die Devise sein. Aber wenn die
Kapazität eines Meldungspuffers so niedrig angelegt ist, das es
nicht mal eine simple Stromschwankung geben darf, dann hat
irgendjemand bei der Auslegung etwas sehr falsch gemacht.
Till Kinstler
[ AKW-Unfall in Harrisburg, total O.T., aber vielleicht haben die ja
Strom an eine amerikanische Bahngesellschaft geliefert ;-) ]
> Ist das nicht schon Jahrzehnte her?
Ich glaube 1978, auf jeden Fall 70er Jahre, eher zweite Haelfte als
erste... Genaues Datum muesste ich suchen gehen... Es handelte sich aber
wohl durchaus schon um Computer im heutigen Sinne, also keine
Lochkartenrechner oder so. Die Maschinen muessen immerhin so fit gewesen
sein, um in einem AKW kritische Aufgaben zu uebernehmen...
Laut Prof. Stieber (dessen Spezialgebiet uebrigens
"Softwarezuverlaessigkeit" ist, den duerfte das Ereignis in Frankfurt
also auch interessieren) hat man aber bereits beim Entwurf der Software
Fehler gemacht, Software im heutigen Sinne gab's also auch schon...
Hans-Joachim Zierke
Martin Ebert schrieb:
> Dieses Verhalten (und mir scheint genau DIES die Ursache zu sein!)
> wird sehr schoen an Hand eines aehnlichen Falls im Kommunikationsnetz
> USA beschieben in "Digitales Verhaengnis", S.119 ff.
> ISBN: 3-89319-672-2
Du meinst diesen Vorfall?
-------------------------------------------------------------------------
As an example of this, I have a report in front of me on the Iraqi network.
This was from long before the Gulf War had occurred, so it's totally
coincidental. I was studying the communication network that links together
the radars in the Iraqi network. I was thinking to myself, "this damn
thing is hard to bring down." We postulated where you would have to bomb,
what nodes would have to be taken out, and what special forces would have
to be put in to cut links. The diversity of the network made it very, very
hard to do anything with.
Coincidentally, January 15, 1990, the unthinkable happened in the United
States. The AT&T network went down. You could not make a telephone call
across the country January 15, 1990. It was unthinkable. AT&T had never
prepared for such a contingency because they hadn't thought of it.
We have a network control center in Bedminster, New Jersey. Most of us
have been to the Cheyenne-like, NORAD center there. It looks a little like
that on a somewhat smaller scale (Most would say the opposite. Most have
been to the Bedminster Center, but Cheyenne looks like that, only bigger.
On this crowd I have to use the reverse). The difference is, at the AT&T
center there are no generals sitting around because they never envisioned
the need to make a decision based on what might happen. As the map went
red, as every link went down across the country, there was no one to make a
decision, chaos reigned, and it was many hours--only through luck and
chaos--the network was put back on its feet. In fact, there were many wild
ideas being considered.
One I particularly liked. One young supervisor suggested that we reboot
the network. Now semantically that's very interesting, because "reboot"
implies that it has once been "booted." You can imagine in your mind,
there's a big knife switch on the wall that says "network - on/off." So no
one had ever turned the network on, every in history, and it was not known
how it could be done.
Of course, AT&T has generals sitting around and emergency measures. They
learned a lot that day. But in 1990, I was on a committee which looked at
what went wrong; why the AT&T network went down. So on one day I'd be
working for AT&T and figuring out how to keep a network up; the next day
I'd be working for Air Force on how to take a network down.
The juxtaposition was very interesting. On the days I was working with the
Air Force, we worried about what to bomb. I envisioned weapons filling the
air and explosions. But what took the AT&T network down was one line of
code. One line of code, weighing nothing, occupying no space, at almost no
cost, took down the entire United States network. You could bomb this
country all you wanted to and still make calls across the country, the
network is that robust. But one line of information, one bit of knowledge,
took the network down. The juxtaposition of these two examples made it
very clear to me the power of information in this world.
Andreas Barth
> Ein ressourcenverteilender Rechner findet (da blockiert-Meldung)
> nicht genuegend freie Ressourcen. Und blockiert selbst.
Also ein klassischer Deadlock.
Ich möchte hier nur anmerken, das beispielsweise beim
Linux-Dateisystem eine gewisse Menge an Speicherplatz
für eben solche Fälle freigehalten wird.
Ich weiß, das hält keiner Sicherheitsüberprüfung stand.
Trotzdem sind Reserven für absolute Ressourcenknappheit
vorgesehen. Und das sollte ein Rechner an kritischer
Stelle erst recht schaffen.
> Dieses Verhalten (und mir scheint genau DIES die Ursache zu sein!)
> wird sehr schoen an Hand eines aehnlichen Falls im Kommunikationsnetz
> USA beschieben in "Digitales Verhaengnis", S.119 ff.
Du meinst den Vorfall mit der aktualisierten Software,
die bei lokaler Überlastung automatisch Ferngespräche
vorbeirouten sollte und am Ende dazu geführt hat, das
gar nichts mehr geroutet wurde?
Stephan Hellwig
hmvff schrieb hier:
> > ... führten in Ffm dazu, daß das erforderliche Hochfahren des Stellwerks
> > eine (halbe?) Stunde dauerte. Das Sortieren der Züge dauerte dem
> > Vernehmen nach länger.
> Durch einen Kurzschluß in der Umspannstation Hattersheim sei _"für den
> Bruchteil einer Sekunde"_ die Spannung abgefallen, berichtete eine
> Sprecherin der Mainkraftwerke laut FR.
Verstehe ich das richtig, daß bei der DBAG selbst sicherheitsrelevante
Rechner ohne USV betrieben werden?
Steven
--
"Laß das, ich möchte jetzt deprimiert sein!"
[Sandra Bullock in "Speed 2"]
Stephan Hellwig
aba schrieb hier:
> > Das Booten aller Rechner dauert eben seine Zeit.
> Außerdem: Eine halbe Stunde ist schon mächtig viel, durch Einsatz
> moderner Technik (z.B. Journailing File-Systems, mehrfach
> zugreifbare Raids) kann man das auf wenige Minuten verkürzen.
Welches System benutzt die Bahn denn?
> Alles andere ist doch peinlich.
Meine AS/400 benötigen für einen IPL nach Stromausfall locker jeweils eine
halbe Stunde. Ein KAltstart unserer ehemaligen MVS/ESA ES9000 war nicht
unter einer Stunde zu schaffen.
Stephan Hellwig
Burberg schrieb hier:
> das stimmt mich ebenfalls sehr nachdenklich. Zumal "normale" Rechenzentren
> häufig überhaupt nur mit Batterien gespeist werden. Das allgemeine Ortsnetz
> wiederum dient nur dazu, die Batterien ständig in einem entsprechenden
> Ladezustand zu halten.
Sorry, aber das nenne ich "blühende Phantasie".
Die USV ist vorrangig dafür da, das _System_ am Laufen zu halten, nicht
aber unbedingt die Anwender.
Im übrigen müssen gerade Akkumulatoren laufend ge- und entladen werden, um
den berüchtigten "Memory-Effekt" zu verhindern.
> Somit "merkt" das Rechnersystem noch nicht einmal,
> daß das Ortsnetz zusammengebrochen ist.
Selbstverständlich muß das OS den Zusammenbruch "merken". Allein schon um
per Hinweis den jeweiligen Operator zu entsprechenden Maßnahmen
aufzufordern.
Andreas Barth
> Es waren fast 3 Stunden und das Schiff, die USS Yorktown mußte dann in
> den Hafen geschleppt werden. Das dollste aber ist, das auf diesem sog.
> Smart Ship die Rechnertechnik NICHT redundant ist. Aber wer für so was
Bist Du sicher? Bisher kannte ich noch keine Aussage über die
Redundanz.
Aber auch Redundanz hätte nicht weitergeholfen, da alle Rechner
im internen Netzwerk aufgrund eines Bedienfehlers abgestürzt sind
(in ein Datenfeld wurde 0 eingegeben, das hat zu einem Division
by zero-Fehler geführt.)
Holger Metschulat
> Hm, mein Leitsystem (Kraftwerk) _muß_ den Prozeß weiterbetreiben, sonst
> betreibt der Prozeß uns ;-), insofern ist das wohl nicht vergleichbar
> mit einem ESTW, da kann man alle Signale auf Halt setzen.
Aber das Leitsystem versucht nicht, die Prozeßausbeute zu maximieren,
sondern das System herunterzufahren. Beim ESTW werden ja auch erst die
Signale auf Halt gestellt, bevor das System sich abschaltet.
Übrigens ist mir dieses Verhalten gestern auch an Geldautomaten aufgefallen:
Nach der Eingabe von Geheimzahl und Betrag gab der Automat mir meine Karte
wieder und schaltete sich dann einfach ab und behielt das Geld :-(. Beim
Booten gab es dann: "Microsoft Operation System/2 (c) 1991".
Michael Kauffmann
>
> On 16 Mar 1999 20:13:40 +0100, Sven Herzfeld <herz...@maschsee.han.de>
> wrote:
> > Naja, die Amis hatten angeblich
> > schon ein minutenlang totes Kriegsschiff, weil sich der NT-Rechner
> > aufgehängt hatte ...
>
> Der NT-Rechner hatte sich aufgehängt, weil jemand in ein
> netzwerkweites Steuerungsfeld den Wert 0 eingegeben und das dann
> auf allen Systemen zu einem "Divison by zero"-Fehler geführt hat.
> In comp.risks stand das relativ ausführlich.
Dann hat sowohl der, der die 0 eingegeben hat, als auch der, der diese
Eingabemoeglichkeit zugelassen hat, "etwas sehr falsch gemacht", wie Du
Dich auszudruecken beliebst.
Und das mit viel gefaehrlicheren Folgen als der, der das ESTW so
eingerichtet hat, dasz es viel zu oft gefahrlos abschaltet.
Michael Kauffmann
Christian Luginbuehl
>Mein Arbeitgeber (privater Telekommunikationsanbieter) hat fuer die
>Vermittlungsanlage eine batteriegestuetzte USV, die 4h Vollastbetrieb der
>Keine Stoerung, gar nichts. Wirklich eine unterbrechungsfreie Stromversorgung
>Und das schafft das Unternehmen Zukunft beim ESTW nicht?
Man möge mir folgende Frage verzeihen:
Sind es denn nicht die führenden Telekommunikationsgesellschaften,
welche ESTW bauen?
>So langsam werde ich nachdenklich...
Ich auch. :-)
Gruss, Christian.
--
Christian Luginbuehl
c...@gmx.ch
Frank Spreer
Holger Metschulat schrieb in Nachricht
>Übrigens ist mir dieses Verhalten gestern auch an Geldautomaten
aufgefallen:
>Nach der Eingabe von Geheimzahl und Betrag gab der Automat mir meine
Karte
>wieder und schaltete sich dann einfach ab und behielt das Geld :-(.
Beim
>Booten gab es dann: "Microsoft Operation System/2 (c) 1991".
>
Sei froh, das es keine Zugriffsverletzung ausgespuckt hat, da wären
wenige Minuten später die Jungs im grünen Auto dagewesen ;-)
MfG Frank
Manfred Vogt 63791 Karlstein Germany
Barth) wrote:
> On 17 Mar 1999 22:31:12 +0100, Manfred Vogt 63791 Karlstein Germany <Ma...@t-online.de> wrote:
> > Es waren fast 3 Stunden und das Schiff, die USS Yorktown mußte dann in
> > den Hafen geschleppt werden. Das dollste aber ist, das auf diesem sog.
> > Smart Ship die Rechnertechnik NICHT redundant ist. Aber wer für so was
>
> Bist Du sicher? Bisher kannte ich noch keine Aussage über die
> Redundanz.
Aus dem Web habe ich eine Seite, da steht es so drin:
"Although the Yorktown did not have backup systems, Redman said that
future Smart Ships will have systems redundancy to ensure
that ships can continue to operate."
bye
Manfred Vogt
Sven Herzfeld
>> einlesen" einfach terminieren konnte. Naja, die Amis hatten angeblich
>> schon ein minutenlang totes Kriegsschiff, weil sich der NT-Rechner
>> aufgehängt hatte ...
> Es waren fast 3 Stunden und das Schiff, die USS Yorktown mußte dann in
> den Hafen geschleppt werden. Das dollste aber ist, das auf diesem sog.
> Smart Ship die Rechnertechnik NICHT redundant ist. Aber wer für so was
> eNTe nimmt, hat sowieso ein Rad ab.
Früher hat das DoD für alle Projekte ADA verlangt, heute reicht
NT ... was bestimmt nicht in ADA geschrieben ist.
Sven
Andreas Barth
>> Der NT-Rechner hatte sich aufgehängt, weil jemand in ein
>> netzwerkweites Steuerungsfeld den Wert 0 eingegeben und das dann
>> auf allen Systemen zu einem "Divison by zero"-Fehler geführt hat.
>> In comp.risks stand das relativ ausführlich.
> Dann hat sowohl der, der die 0 eingegeben hat, als auch der, der diese
> Eingabemoeglichkeit zugelassen hat, "etwas sehr falsch gemacht", wie Du
> Dich auszudruecken beliebst.
Der, der 0 eingegeben hat, nicht, denn er konnte die Folge nicht
wissen.
Der, der das zugelassen hat, ist AFAIR ein international
bekanntes Softwareunternehmen mit Sitz in den USA und Hersteller
von Betriebssystemsoftware.
Das ganze hatte innerhalb der Navy deutliche Folge, seitdem
wurde auch eine Linux-Variante getestet.
> Und das mit viel gefaehrlicheren Folgen als der, der das ESTW so
> eingerichtet hat, dasz es viel zu oft gefahrlos abschaltet.
Ja. Aber nur weil es noch schlimmeres gibt, wird doch etwas
falsches nicht gut. (Sonst könnte man bei der Bahn ziemlich
komplett auf Sicherheitstechnik verzichten, sicherer als die
Straße wäre sie immer noch.)
Martin Ebert
> On Wed, 17 Mar 1999 18:34:21 +0100, Martin Ebert <m...@kdg.de> wrote:
> > Ein ressourcenverteilender Rechner findet (da blockiert-Meldung)
> > nicht genuegend freie Ressourcen. Und blockiert selbst.
> Also ein klassischer Deadlock.
Yep.
> Ich möchte hier nur anmerken, das beispielsweise beim
> Linux-Dateisystem eine gewisse Menge an Speicherplatz
> für eben solche Fälle freigehalten wird.
Nicht vergleichbar. Echtzeitsysteme laufen anders.
Aber klar: Ein Design-Fehler ist es schon.
Martin Ebert
Martin Ebert
> Verstehe ich das richtig, daß bei der DBAG selbst sicherheitsrelevante
> Rechner ohne USV betrieben werden?
Nein.
Ich schrieb den (wahrscheinlichen) hintergrund in einem anderen
Posting.
Martin Ebert
Martin Ebert
>
> Martin Ebert schrieb:
>
> > Dieses Verhalten (und mir scheint genau DIES die Ursache zu sein!)
> > wird sehr schoen an Hand eines aehnlichen Falls im Kommunikationsnetz
> > USA beschieben in "Digitales Verhaengnis", S.119 ff.
>
> Du meinst diesen Vorfall?
> what went wrong; why the AT&T network went down. So on one day I'd be
Ja.
Martin Ebert
Michael Kauffmann
>
> <Michael....@GMX.NET> wrote:
> >> Der NT-Rechner hatte sich aufgehängt, weil jemand in ein
> >> netzwerkweites Steuerungsfeld den Wert 0 eingegeben und das dann
> >> auf allen Systemen zu einem "Divison by zero"-Fehler geführt hat.
>
> > Eingabemoeglichkeit zugelassen hat, "etwas sehr falsch gemacht", wie Du
> > Dich auszudruecken beliebst.
>
> Der, der 0 eingegeben hat, nicht, denn er konnte die Folge nicht
> wissen.
Dran rummachen, ohne zu wissen, was passiert, ist nicht falsch?
> Das ganze hatte innerhalb der Navy deutliche Folge, seitdem
> wurde auch eine Linux-Variante getestet.
Da kann amn nicht mehr in Eingabefelder Mist eintragen, sondern in
Konfigurationsdateien. Ist das besser?
Michael Kauffmann
roman kawe
> Da kann amn nicht mehr in Eingabefelder Mist eintragen, sondern in
> Konfigurationsdateien. Ist das besser?
Es ist zumindest schwieriger. Und insofern besser, um Missbrauch zu
verhindern.
--
roman kawe
Bitte keine 'courtesy copies' - wenn ich irgendwo schreibe, lese ich
da auch.
Wolfgang Broeker
> Dieser "Zentralrechner" bei der Bahn, der da ausgefallen ist,
> MUSS sicher definiert auf alle Arten von Meldungen und Requests
> in definierter Zeit antworten koennen. Wenn das nicht mehr
> gewaehrleistet ist, dann ist es besser, dass er sich abschaltet...
Völlig richtig. Insbesondere kann ein solches System auch nicht
einfach eine Konsolmeldung ausgeben in der Hoffnung, daß sich
irgendein Bediener nach Rückkehr aus der Frühstückspause der
Sache schon annehmen wird.
Vielleicht war das Verhalten des Rechners durchaus auch so
beabsichtigt. Wenn man beim Entwurf eines solchen Systems
entscheiden muß, wie zu reagieren ist, wenn innerhalb einer
Sekunde die gleiche Störungsmeldung von allen angeschlossenen
Satellitensystemen kommt, liegt die Annahme eines GAU-ähnlichen
Ereignisses (Erdbeben, Meteoriteneinschlag, Biblis A o.ä.) nicht
so sehr fern, und darauf ist das kontrollierte Abschalten des
Systems möglicherweise eine ausgesprochen adäquate Antwort.
Wenn man im übrigen die meisten Beiträge dieses Threads kritisch
würdigt, wo offenbar jeder, der einen PC nebst Newsreader einiger-
maßen bedienen kann, bereits meint, abschließende Urteile über
die Eigenschaften von Real-Time-Systemen abgeben zu können, werde
ich nachdenklich im Hinblick auf die - sachlich berechtigte -
Kritik, die wir hier oft an der Arbeit von Journalisten üben.
Gruß - Wolfgang
--
*** Don't Call Us, We'll Call You ***
*** Fri, 19 Mar 1999 16:02 +0100 ***
roman kawe
> Im übrigen müssen gerade Akkumulatoren laufend ge- und entladen werden, um
> den berüchtigten "Memory-Effekt" zu verhindern.
Wer wird sich NiCd-Akkus als USV hinstellen?
Manfred Vogt 63791 Karlstein Germany
wrote:
Wo Wilhelm Tor einen Besuch abstattet, ist alles möglich. Er war auch
AFAIK schon mal bei der Deutschen Bahn.
bye
Manfred Vogt
Sven Herzfeld
> Sind es denn nicht die führenden Telekommunikationsgesellschaften,
> welche ESTW bauen?
Siemens.
>>So langsam werde ich nachdenklich...
> Ich auch. :-)
Wieso, es kann doch nur besser werden: Immerhin haben sie schon
gelernt, daß ein ESTW genügend Stack braucht, und nun wissen sie,
daß ausreichend Kapazität für Meldungen sein muß. Wenn so nach
und nach mehr Know-How in die Software fließt, sind die ESTW
rechtzeitig zur Einstellung des Bahnbetriebes perfekt.
Sven
Andreas Barth
>> Der, der 0 eingegeben hat, nicht, denn er konnte die Folge nicht
>> wissen.
> Dran rummachen, ohne zu wissen, was passiert, ist nicht falsch?
Er _konnte_ es nicht wissen, das war ein Dokumentationsfehler.
>> Das ganze hatte innerhalb der Navy deutliche Folge, seitdem
>> wurde auch eine Linux-Variante getestet.
> Da kann amn nicht mehr in Eingabefelder Mist eintragen, sondern in
> Konfigurationsdateien. Ist das besser?
Kennst Du Linux? Dort kann man -- dank Verfügbarkeit der
Quelltexte -- die Benutzer besser vor Fehlern abschirmen
bzw. es ist einfacher möglich, Folgen von Eingaben zu
erkennen.
Martin Ebert
> Burberg schrieb hier:
>
> > das stimmt mich ebenfalls sehr nachdenklich. Zumal "normale" Rechenzentren
> > häufig überhaupt nur mit Batterien gespeist werden. Das allgemeine Ortsnetz
> > wiederum dient nur dazu, die Batterien ständig in einem entsprechenden
> > Ladezustand zu halten.
>
> Sorry, aber das nenne ich "blühende Phantasie".
Die bluehende Phantasie kostet 200 KiloMark und steht bei mir im
Keller.
Martin Ebert
--
http://www.kdg.de/
Andreas Krey
>
> Zu Christian Luginbuehl <c...@gmx.ch>:
>
> > Sind es denn nicht die führenden Telekommunikationsgesellschaften,
> > welche ESTW bauen?
>
> Siemens.
>
unschlagbar." Dass die Anlagen das gleichen Firmenlogo tragen, heisst
dass noch nicht, dass die entsprechenden Abteilungen (personell oder
know-how-weise) enger zusammenliegen, als es zwischen verschiedenen
Firmen vorkommmt.
Andreas
--
Andreas Krey, Ulm, Germany a.k...@computer.org
Tel: +49 (731) 931 62 53 Fax: +49 (731) 931 62 54
-- Don't attach Word Documents or other proprietary formats --
-- A boot a day keeps Dr. Watson away
Spammer of the day: sa...@aimasia.com -- Visit: http://spam.abuse.net/
Sven Herzfeld
> Im übrigen müssen gerade Akkumulatoren laufend ge- und entladen werden, um
> den berüchtigten "Memory-Effekt" zu verhindern.
Damit sie gerade dann leer sind, wenn sie gebraucht werden? ;-)
Sven
Stephan Hellwig
me schrieb hier:
> > > das stimmt mich ebenfalls sehr nachdenklich. Zumal "normale"
> > > Rechenzentren häufig überhaupt nur mit Batterien gespeist werden. Das
> > > allgemeine Ortsnetz wiederum dient nur dazu, die Batterien ständig in
> > > einem entsprechenden Ladezustand zu halten.
> >
> > Sorry, aber das nenne ich "blühende Phantasie".
>
> Die bluehende Phantasie kostet 200 KiloMark und steht bei mir im
> Keller.
Womit also festgestellt wäre, daß ich in einem 'unnormalen Rechenzentrum'
arbeite?
Da hier off topic: FUp.
Stephan Hellwig
Roman.Kawe schrieb hier:
> > Im übrigen müssen gerade Akkumulatoren laufend ge- und entladen werden, um
> > den berüchtigten "Memory-Effekt" zu verhindern.
> Wer wird sich NiCd-Akkus als USV hinstellen?
Das Zeugs, das wir hatten, nannte sich "Gel-Akkumulator". Davon hatten wir
2x144 Stück, weil eine Reihe halt immer am 'Entladen' war. Keine Ahnung,
ob die mit NiCd funktionierten.
Stephan Hellwig
Michael.Kauffmann schrieb hier:
> > Leider werden auch bei solchen sicherheitskritischen Systemen Fehler
> > gemacht... So soll bei dem AKW-Stoerfall in Harrisburg ein Problem
> > gewesen sein, dass mehr Stoerungsmeldungen auftraten, als das System
> > anzeigen konnte. Angeblich war in dem System keine Moeglichkeit
> > vorgesehen, Meldungen nochmals anzeigen zu lassen. So sollen wichtige
> > und kritische Stoermeldungen, die eine Entscheidung beeinflusst haetten,
> > einfach verloren gegangen sein. Ich weiss nicht, ob das eine "urban
> > legend" ist (hatten die keine Protokolldrucker oder Logfiles?),
So etwas in der Art gibt es tatsächlich.
> Ist das nicht schon Jahrzehnte her? Da dürfte wohl Manches, was wir
> heute für selbstverständlich halten, noch unbekannt gewesen sein.
Reicht Dir 1995?
> Vielleicht war dieses "System" nicht mal ein Computer im heutigen Sinne?
MVS/ESA ES9000. Das ist eine IBM-Großrechenanlage - mit leider etlichen
konzeptionellen Schwächen.
Ich versuche, das Problem mal kurz zu umreißen: Der Systemmonitor erfaßt
sämliche das System betreffenden Aktivitäten. So eine Bildschirmseite kann
ca. 40 Zeilen darstellen. Müssen mehr Zeilen dargestellt werden, scrollen
die ältesten Zeilen nach oben weg. Das ist auch kein Problem, solange das
System stabil bleibt. Stellt das System nun aber einen Fehler fest, wird
die entsprechende Zeile farbig hervorgehoben und bis zum oberen
Bildschirmende verschoben. Und dort bleibt sie solange, bis der Operator
den Fehler behoben hat, sei es durch Systemaktionen, sei es durch das
manuelle "Löschen" der Fehlernachricht.
Die besagte "konzeptionelle Schwäche" besteht nun darin, daß eine Eingabe
am Systemmonitor erst dann wirksam wird, wenn sie auch auf dem Bildschirm
erscheint. Und das ist genau das fatale: Wenn deutlich mehr
Fehlermeldungen über den Bildschirm hereinbrechen als der Operator
beantworten kann, ist irgendwann der Bildschirm voll - und er kann die
manuellen Eingaben nicht mehr darstellen. Diese werden nicht mehr
abgearbeitet => MAschine steht. Einzige Maßnahme: Kaltstart.
Anmerkung: Die Grundlagen auch heutiger MVS-Anlagen entstanden 1978.
[Bevor jetzt die MVS-Spezialisten aufschreien: Ich habe den Vorgang
möglichst einfach beschrieben, also z.B. nicht zwischen "requests" und
"warnings" unterschieden. Das grundlegende Prinzip sollte allerdings zwar
verkürzt, aber in diesem Zusammenhang korrekt dargestellt sein.]
Stephan Hellwig
Michael.Kauffmann schrieb hier:
> > Der, der 0 eingegeben hat, nicht, denn er konnte die Folge nicht
> > wissen.
> Dran rummachen, ohne zu wissen, was passiert, ist nicht falsch?
Sicher ist es falsch - aber eben auch üblich. Zumeist wegen fehlender oder
zumindest mangelhafter Schulungen ("In dieses Feld soll nichts eingetragen
werden." - "Also eine null?" - "JA klar, null ist ja 'nichts'." Original
so gehört!)
Christian Gruber
> ... Haupt- und Vorsignale haben aber bei den Ks-Signalen einen Leuchtpunkt,
> während es bei Hp00 und Vr0 jeweils zwei waren -> Ks-Signalsystem trägt zum
> Energiesparen bei ;-)
Und wenn dieser Lichtpunkt dann auch noch blinkt, braucht er wiederum
nur noch halb so viel Strom ;-)
chg
Christian Gruber
> > Wenn man sich mal die Schaltpläne von Drucktastenstellwerken anschaut, so
> > wird man feststellen, daß diese einen Stromausfall einfach überleben, d.h.,
> > nach abstellen und wieder anstellen der Stromversorgung ist das Stellwerk
> > (fast) wieder im selben Zustand, so eine Art APM eben.
>
> Und wenn sich in der Zwischenzeit der Besetzungszustand der Gleise
> geändert hat?
Zumindest wenn die Gleisfreimeldung ueber Gleisstromkreise erfolgt,
muesste ein Zug auch dann vom Stellwerk erkannt werden, wenn er "vom
Himmel gefallen" sein sollte.
chg
Jürgen Burberg
übrigens: Wer hatte schon mal mit dem Memory-Effekt bei seiner Autobatterie
zu tun??
Es git durchaus Methoden, Akksu ohne Memory-Effekt zu bauen. Und diese sind
gar nicht mal so neu.
Das zum Thema Memory-Effekt bei Groß-USVs.
Gruß aus Wiesbaden
Jürgen Burberg
--
Sven Herzfeld schrieb in Nachricht <7d03qi$cg$1...@maschsee.han.de>...
>Zu Stephan Hellwig <ste...@bullock.bonbit.org>:
>
>> Im übrigen müssen gerade Akkumulatoren laufend ge- und entladen werden,
um
>> den berüchtigten "Memory-Effekt" zu verhindern.
>
Mathias Boelckow
>On 17 Mar 1999 01:58:45 GMT, Holger Metschulat <ho...@sgs.wh.tu-darmstadt.de> wrote:
>> "Kontrolliert" heißt beim ESTW (und bei anderen sicherheitskritischen
>> Techniken, z.B. Atomkraftwerk oder Chemie-Prozeßanlage) "Abschalten", weil
>> der Rechner (bzw. der Programmierer) nicht garantieren kann, daß der Zustand
>> nach der Ausnahmesituation konsistent ist.
>
>Sobald der Verlust von Meldungen nicht ausgeschlossen werden
>kann, muß natürlich "Abschalten" die Devise sein. Aber wenn die
>Kapazität eines Meldungspuffers so niedrig angelegt ist, das es
>nicht mal eine simple Stromschwankung geben darf, dann hat
>irgendjemand bei der Auslegung etwas sehr falsch gemacht.
Wobei mir noch der Gedanke gekommen ist, dass das Stellwerk
möglicherweise bei einem üblichen Stromausfall sofort wieder
einsatzbereit ist, aber genau dieser sehr kurze Stromausfall nicht
bedacht worden ist.
Bei einem längeren Stromausfall kann das Stellwerk ersteinmal alles
auf rot stellt, was ohne Strom nicht sicher arbeitet und dann in Ruhe
berechnen kann, wie ein geeigneter Wiederanfahrprozeß auszusehen hat,
also z.B. welche Fahrstraßen vom Menschen überprüft werden müssen.
Dieser Prozeß verlangt offensichtlich vor allem kurz nach dem
Stromausfall sehr viel Rechnenaufwand der sehr kurzfristig zu
erledigen ist.
Nun kommt just in dieser Phase von allen angeschlossenen Stellwerken
die Meldung, dass der Strom wieder da ist. Bei Unterstellwerken
geleicher Bauart dürfte diese Meldung nur mit dem Versatz der
Signallaufzeit eintreffen. Der Hauptrechner hat aber noch alle
Priorität mit sicherheitsrelevanten Reaktionen für den Stromausfall.
Dann kann es viel eher zur Abschaltung durch Überlastung kommen.
Gruß, Mathias Bölckow
Stephan Hellwig
herzfeld schrieb hier:
> > Im übrigen müssen gerade Akkumulatoren laufend ge- und entladen werden, um
> > den berüchtigten "Memory-Effekt" zu verhindern.
> Damit sie gerade dann leer sind, wenn sie gebraucht werden? ;-)
:-)))
Ich denke, ich hatte das bereits erklärt. Wobei ich nicht bestreiten
möchte, daß die besagte Anlage bei uns nicht ganz dem derzeit üblichen
Standard zu entsprechen scheint.
Was mich abschließend aber noch interessiert - und was IMHO bislang nicht
geklärt wurde: Was für Rechner mit welchem OS sind denn nun in Ffm
ausgefallen?
Andreas Krey
>
...
> Bei einem längeren Stromausfall kann das Stellwerk ersteinmal alles
> auf rot stellt, was ohne Strom nicht sicher arbeitet und dann in Ruhe
> berechnen kann, wie ein geeigneter Wiederanfahrprozeß auszusehen hat,
> also z.B. welche Fahrstraßen vom Menschen überprüft werden müssen.
> Dieser Prozeß verlangt offensichtlich vor allem kurz nach dem
> Stromausfall sehr viel Rechnenaufwand der sehr kurzfristig zu
> erledigen ist.
Andere Frage: Vergisst ein ESTW mit Achszaehlkreisen eigentlich den
Zaehlstand, wenn der Strom weg ist? Muss man dann ins Feld laufen und
nachsehen, bevor die Zaehler wieder als gueltig angesehen werden?
Irgendwie ist mir der Gleisstromkreis sympathischer.
Michael Kauffmann
>
> Michael Kauffmann wrote:
>
> [ AKW-Unfall in Harrisburg, total O.T. ]
>
>> Vielleicht war dieses "System" nicht mal ein Computer im heutigen Sinne?
> Es handelte sich aber wohl durchaus schon um Computer im heutigen Sinne,
> also keine Lochkartenrechner oder so.
Die waeren ja auch schon ziemlich Computer. Ich dachte an verdrahtete
Logik.
> Laut Prof. Stieber [...] hat man aber bereits beim Entwurf der Software
> Fehler gemacht, Software im heutigen Sinne gab's also auch schon...
Gut, dann nicht.
Michael Kauffmann
Michael Kauffmann
>
> Michael Kauffmann <Michael....@GMX.NET> schrieb:
> > Und wenn sich in der Zwischenzeit der Besetzungszustand der Gleise
> > geändert hat?
>
> Relaisstellwerk alle Signale parallel anliegen und auch direkt auf die
> Schaltung wirken,
Bei Gleisstromkreisen schon, aber bei Achszaehlern?
Michael Kauffmann
Holger Kötting
cbi...@gmx.de (Christoph Biedl) writes:
|> Da aber Vor- und Hauptsignal synchron blinken, wäre hier noch ein
|> Optimierungspotential gegeben...
Nur wenn am Hauptsignal eine weitere Geschwindigkeitsbeschraenkung zu erwarten
ist. Ansonsten blinkt am Hauptsignal nichts.
OT: Man koennte allerdings von der Hauptsignallampe einen Lichtwellenleiter zum
Vorsignal legen. Das koennte vielleicht was sparen... :-)
Gruss,
Holger K. aus D.
--
Streckenstillegung? Nein, es wird nur nichts bestellt!
E-Mail: koetting @ rbg.informatik.tu-darmstadt.de
Homepage: http://www.student.informatik.tu-darmstadt.de/~koetting
Mathias Boelckow
>> Bei einem längeren Stromausfall kann das Stellwerk ersteinmal alles
>> auf rot stellt, was ohne Strom nicht sicher arbeitet und dann in Ruhe
>> berechnen kann, wie ein geeigneter Wiederanfahrprozeß auszusehen hat,
>> also z.B. welche Fahrstraßen vom Menschen überprüft werden müssen.
>
>Andere Frage: Vergisst ein ESTW mit Achszaehlkreisen eigentlich den
>Zaehlstand, wenn der Strom weg ist?
Nein, soweit ich das hier verfolgen konnte dürfte das ESTW am besten
gegen den Stromausfall geschützt sein und damit als letztes
irgendetwas vergessen. Die Frage ist, ob der Achszähler selbst die
ganze Zeit mit Strom versorgt war. Wenn es daran Zweifel gibt, kann
nicht ausgeschlossen werden, dass eine Achse in einen Abschnitt
eingefahren ist, ohne wieder herausgefahren zu sein.
M.E. konnte hier noch niemand genau sagen, wie Signale, Aktuatoren
(z.B. Weichenantriebe) und Aufnehmer (z.B. Achszähler,
Gleisstromkreiese) gegen Stromausfall geschützt sind.
>Muss man dann ins Feld laufen und
>nachsehen, bevor die Zaehler wieder als gueltig angesehen werden?
Jedenfalls kann dann nicht von einem freien Abschnitt ausgegangen
werden.
>Irgendwie ist mir der Gleisstromkreis sympathischer.
Wenn die nicht gepuffert sind, werden sie alle für eine Sekunde ein
besetztes Gleis (immer zur sicheren Seite) gemeldet haben. Dann werden
dem Stellwerkrechner erst recht die Drähte zu Berge gestanden haben,
weil lauter Züge freie Einfahrt in besetzte Gleise hatten. Das dürfte
dann sogar zu einem begründeten 'alles auf rot' Befehl führen, bis die
Folgen dieser Operation die kontrollierte Systemabschaltung aus
Überlastung nach sich ziehen.
Ich vermute zwar, dass die wesentlichen Teile der ganzen Signaltechnik
auch gepuffert sind, aber gerade dieser ganze Thread zeigt deutlich,
wie leicht vergessen werden kann, dass vielleicht gerade in diesem
Moment jemand den Computer noch mit der Frage nach einer Tasse Tee so
heftig in Anspruch nimmt, dass er überlastet ist.
Gruß, Mathias Bölckow