Stellwerk

Hier geht es um die Entwicklung eines zukünftigen Stellwerks mit Zusi-Anschluss.
Nachricht
Autor
Glatzy
Beiträge: 22
Registriert: 05.11.2005 09:44:58
Wohnort: Berlin

Stellwerk

#1 Beitrag von Glatzy »

Hallo Zusammen,was ist eigentlich aus dem Stellwerksprogramm für Zusi geworden?Man hat schon lange nichts mehr davon gehört.Gibt es das Programm noch oder ist es eingestellt worden?
Mit freundlichen Grüßen Glatzy ?(

Benutzeravatar
Daniel Rüscher aka Merlin
Beiträge: 2294
Registriert: 23.01.2003 02:25:50
Aktuelle Projekte: Aktuell keine
Wohnort: Traunreut
Kontaktdaten:

#2 Beitrag von Daniel Rüscher aka Merlin »

Jetz dauerts ne Woche länger....
How to waste bits in a My SQL Database?

Like this.....

Benutzeravatar
Roland Ziegler
Beiträge: 5508
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

#3 Beitrag von Roland Ziegler »

Das geht alles seinen geregelten Gang. :D

Im Moment könnte ich schreiben über Umarbeitung und Verschlankung am Kommunikationsserver. Gestern Abend habe ich mich mit Ko- und Kontravarianz beim Delegate beschäftigt. Ich befürchte aber, das interessiert den Endanwender wenig. Wenn's was Wesentliches zu berichten gibt, wird man das hier erfahren.

Benutzeravatar
Daniel Rüscher aka Merlin
Beiträge: 2294
Registriert: 23.01.2003 02:25:50
Aktuelle Projekte: Aktuell keine
Wohnort: Traunreut
Kontaktdaten:

#4 Beitrag von Daniel Rüscher aka Merlin »

Ko was???? IS das was zum Essen?
How to waste bits in a My SQL Database?

Like this.....


Benutzeravatar
Daniel Rüscher aka Merlin
Beiträge: 2294
Registriert: 23.01.2003 02:25:50
Aktuelle Projekte: Aktuell keine
Wohnort: Traunreut
Kontaktdaten:

#6 Beitrag von Daniel Rüscher aka Merlin »

Ahaaaa...... Schwerer Name für ne eigentlich logische Sache....
How to waste bits in a My SQL Database?

Like this.....

Benutzeravatar
Roland Ziegler
Beiträge: 5508
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

Re: Stellwerk

#7 Beitrag von Roland Ziegler »

An anderer Stelle wurde es nachgefragt:

Ich hoffe, jetzt über längere Zeit wieder intensiver am Stellwerk arbeiten zu können.
Im Moment beschäftige ich mich gerade mit der Vermittlung von Blockmeldungen. Es geht immer noch um die ganze Kommunikationsabwicklung. Gleichzeitig noch einiges an Refactoring, das auch etliches an Vereinfachung bringt.

Benutzeravatar
Frank Wenzel
Beiträge: 5118
Registriert: 06.11.2001 01:13:47
Wohnort: Trier
Kontaktdaten:

Re: Stellwerk

#8 Beitrag von Frank Wenzel »

Roland Ziegler hat geschrieben:... Ich hoffe, jetzt über längere Zeit wieder intensiver am Stellwerk arbeiten zu können...
Cool :) ! Das wird die anderen Hobby-FDL, Stellwerkfreaks und sonstige Chaosgenerierer genauso freuen wie mich, dass du jetzt deine Tätigkeiten am Stellwerk wieder aufnimmst. Ich hoffe nur, dass dir die üblichen, nervigen Fragen erspart bleiben :dösen

Viel Erfolg wünscht
Frank
Gruß ins Forum, Frank - www.zusi-sk.eu - Youtube

Benutzeravatar
Michael_Poschmann
Beiträge: 19877
Registriert: 05.11.2001 15:11:18
Aktuelle Projekte: Modul Menden (Sauerland)
Wohnort: Str.Km "1,6" der Oberen Ruhrtalbahn (DB-Str. 2550)

Re: Stellwerk

#9 Beitrag von Michael_Poschmann »

Frank Wenzel hat geschrieben:Ich hoffe nur, dass dir die üblichen, nervigen Fragen erspart bleiben
Keine Chance, dafür ist das Dorf Aachen zu klein, als daß man sich aus dem Wege gehen könnte.

Gruß in BällemitdemFußschubsvorbereitender Laune
Michael

Benutzeravatar
(Ar-) T-Rex
Beiträge: 4795
Registriert: 19.02.2003 21:07:56
Aktuelle Projekte: Seit 65 Millionen Jahren die Entwicklung der Eisenbahn beobachten
Wohnort: Österreich
Kontaktdaten:

Re: Stellwerk

#10 Beitrag von (Ar-) T-Rex »

Na, die Freude mit dem Fußballschubsinvorfreudeaufdensieg ist Dir wohl inzwischen vergangen, oder? Dem Vernehmen nach hat wohl wer anderer gewonnen, wie die Vöglein von den Bäumen gezwitschert haben ...

Nichteineminutederganzenfußballmeisterschaftgesehenhabend -
Arthur
ZPA-Bereich Österreich

E-mail:
oesterreich@zpa.zusi.de

Benutzeravatar
Michael_Poschmann
Beiträge: 19877
Registriert: 05.11.2001 15:11:18
Aktuelle Projekte: Modul Menden (Sauerland)
Wohnort: Str.Km "1,6" der Oberen Ruhrtalbahn (DB-Str. 2550)

Re: Stellwerk

#11 Beitrag von Michael_Poschmann »

Hallo Arthur,

stimmt, ich hörte davon, daß eine Mannschaft aus dem alpinen Raum den begehrten Pokal nachhause gebracht haben soll. Es können aber auch die Eidgenossen gewesen sein, leider gab's im passenden Moment einen Bildausfall. :hat2

Weiterhin eher dem Volleyball zugetan, aber die spielerischen Fähigkeiten der Spanier neidlos anerkennend

Michael

p.s.: Um das Thema Stellwerk aufzugreifen und nicht ganz abzugleiten: Ich komme gerade mit "+50" aus dem Süden retour, da mir ein Stellwerksausfall in Köln eine Extrarunde mit dem Brüsseler ICE über die Kölner Südbrücke beschert hat. Dann noch Zugfolgeprobleme und ein Böschungsbrand, und das Chaos war mal wieder komplett. An Roland daher die dringende Bitte, der Implementierung einer Random-Funktion für die Systemverfügbarkeit erhöhte Aufmerksamkeit zu widmen. Zumindest sofern es nicht um die Nachbildung mechanischer Anlagen geht.

andy81
Beiträge: 89
Registriert: 16.10.2003 15:59:03
Wohnort: Königstein

Re: Stellwerk

#12 Beitrag von andy81 »

Jo, nur das die Wert für die Aufallwahrscheinlichkeit am höchsten bei ESTW zu setzen ist. Siehe Frankfurt-Stadion gestern nachmittag.... Bei elektromechanisch und Drucktasten fallen ja nur höchstens mal kleine Teilbereiche aus (Fernsteuerung Spur 60 mal abgesehen). Bei mechanisch sollte auch die Umstellzeit von Weichen etwas höher sein....

Gruß André

Benutzeravatar
Roland Ziegler
Beiträge: 5508
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

Re: Stellwerk

#13 Beitrag von Roland Ziegler »

Kleiner Zwischenbericht:

Die Kommunikationstechnik steht immer noch im Zentrum der momentanen Arbeit. Also ganz tief unten. Direkte Stellwerksfunktionalität wird man da vielleicht noch gar nicht erkennnen, aber die Kommunikationsplattform ist essentiell fürs Ganze.

Wie ja schon mehrfach geschrieben, soll es möglich sein, Stellwerke zur Laufzeit der Simulation an- und abzumelden. Auch nicht ordnungsgemäße Abmeldung (Verbindungsabbruch) soll abgefangen werden. Für die Kommunikation ist besonders die Anmeldung spannend, müssen doch alle ein Stellwerk betreffenden Zustände an dieses übermittelt werden. Die verwendete Technik dazu ist eine Kombination aus synchron und asynchron. Die Schnittstellen sind entsprechend ausgelegt, nach außen hin werden Methoden (synchron) und Ereignisse (asynchron) bereit gestellt.

Der innere Ablauf ist multi-threaded. Dies ist zum einen durch .Net-Remoting intern vorgegeben, aber auch sonst sinnvoll, will man dich weitgehende Entkopplung der einzelnen Kommunikationsvorgänge, um gegenseitige Blockade zu verhindern.

Ein Stellwerk selbst wird zum Benutzer hin aber im wesentlichen single-threaded sein, das ist technisch bedingt. Fensteroberflächen arbeiten nach einem ereignisgesteuerten Paradigma (auch X-Windows), und alle Ereignisse, ab Maus, Tastatur oder oder eine Gleiskontaktmeldung, müssen in denselben Thread eingeschleift werden. Softwaretheoretisch läuft das darauf hinaus, eine Methode eines Objektes unter einem anderen Thread als dem eigenen auszuführen. Dies geht prinzipiell sowohl synchron als auch asynchron. Es gibt verschiedene Begriffe dafür, "Active Object" (Doug Schmidt) oder "Future" (aus der Java-Welt). Die Bibliotheken der Fensteroberflächen haben solche Techniken implementiert. Die moderne Softwarewelt, die alles Verhalten als Schnittstellen ausbildet, zeigt uns die Systematik in nachvollziehbarer Form. Das Einschleifen in einem fremden Thread heißt bei .Net: ISynchronizeInvoke. Die gleiche Technik wird höchstwahrscheinlich in der COM-Ausprägung von Delphi realisiert sein, muss ich demnächst noch mal verifizieren.

Hat man diesen Synchronisationsmechanismus einmal verstanden, kann man ihn baukastenmäßig auch anderes zusammenstellen. Das ist für die Testerei wichtig. Die relative Komplexität der Kommunikation einerseits, aber ihre klare Systematik andererseits schreit nach entsprechend systematischen Testverfahren: Unit-Tests. Entsprechende Testsoftware, ursprünglich für Java entwickelt (JUnit), gibt es heute für fast jede gängige Programmiersprache (u.a. auch für C++: CppUnit oder für Delphi: DUnit). Für .Net heißt sie NUnit. Besonders hübsch bei NUnit ist die Nutzung der Klassenattribute von .Net. Damit kann man Klassen bestimmte Aspekte mitgeben, z.B. Vorgaben zur Serialsierung oder zur Darstellung in Eigenschaftsdialogen. Oder eben zum Testverhalten. Gewisse Kompromisse muss man für systematisches Testen leider dennoch machen. Graphische Benutzeroberflächen sollten hierfür nämlich außen vor bleiben. Aber ein gutes Design trennt bekanntlich Form und Funktion. Bleibt nur die Sache mit dem Ereignis-Thread der Windows-Oberfläche. Auch dass lässt sich lösen, wenn man ISynchronizeInvoke mit einer eigenen Klasse implementiert.

Warum muss das eigentlich so "kompliziert" sein? Dazu vielleicht als Beispiel nochmal die grundsätzlichen Kommuikationswege, so wie sich für unser Stellwerkskonzept darstellen (der Leser wird sich an die Analyse zu beginn des Projekts erinnern):
  • Weichen und Signale werden vom Stellwerk gestellt, von Zusi rückgemeldet. Zusi selbst stellt auch Weichen und Signale, aber nur dann wenn das Stellwerk nicht angemeldet ist. Signalrückmeldungen können auch an ein Nachbarstellwerk gehen, Stichwort "Signalmelder". Der Stellvorgang ist synchron, SIgnalrückmeldungen an ein anderes Stellwerk aber asynchron.
  • Gleiskontakte werden von Zusi an ein Stellwerk gesendet, sofern angemeldet. Asynchron. Gleiches Verhalten für Gleisfreimeldeabschnitte, auch wenn die im mech. Stellwerk nicht vorkommen. Hier kann es aber mehr als einen Abonnenten geben.
  • Blockfeldmeldungen werden zwischen je genau zwei Stellwerken ausgetauscht (Bahnhofsblock eingeschlossen). Die Stellwerke können auch durch Zusi emuliert sein.
  • Zugmeldungen und sonstige bei Vorbild fernmündliche oder -schriftliche Meldungen haben einen im Prinzip transienten Charakter, d.h. sie beinhalten keinen wirklichen Zustand. Neben bilateraler Kommunikation gibt es auch Rundsprüche, "Chat" in moderner Lingua.
  • Fahrstraßen (Zugstraßen) haben für die Stellwerkskommunikation etwas ambivalentes. Fahrstraßen sind Funktionselemente des Stellwerks und unterliegen dessen alleiniger Verantwortung. Sie haben keine Entsprechung in Außenanlagen (Zusi). Jedoch ist Zusi im Stellwerkemulationsbetrieb (Normalbetrieb bei Zusi) seinerseits für die Fahrstraßen verantwortlich. Beim Anmelden eines Stellwerks und der Übernahme des Betriebs von Zusi muss das Stellwerk über den aktuellen Zustand der Fahrstraßen informiert werden. Denn das Stellwerk ist nicht notwendigerweise in Grundstellung, wenn die Anmeldung erfolgt. Eine Abmeldung des Stellwerks kann jederzeit und abrupt erfolgen, ohne die Chance, den Zustand der Fahrstraßen wieder an Zusi zurückzumelden. Deshalb wird das Zusi-Stellwerk Fahrstraßenzustandsänderungen laufend an Zusi melden. Eine logische Funktion ist damit aber während der Betriebszeit des Stellwerks nicht verbunden.
Mehrfach war von synchronen und asynchronen Meldungen die Rede. So kann man den Zustand eines Gleiskontaktes synchron abfragen, aber fast gleichzeitig mag sich dessen Zustand ändern, und eine asynchrone Meldung ausgelöst werden. Die Wege zum Stellwerk sind für synchrone Rückmeldung und asynchrone Ereignismeldung unterschiedlich. Die asynchrone Meldung kann verzögert werden. Wie aktuell ist sie noch, wenn sie beim Stellwerk ankommt? Die Funktionslemente des Stellwerks habe häufig binäre Zustände: gestellt oder nicht gestellt, geblockt oder nicht geblockt. Da macht es schon einen wesentlichen Unterschied, ob der gerade empfangene Zustand auch der letzte ist. Wie stellt man das fest? Zeitstempel scheinen eine Möglichkeit, aber ist ihre Granularität ausreichend? Die Auflösung beträgt "nur" 10 ms. Zudem ist die Zeit bei Zusi ja eigentlich Schall und Rauch, denn sie unterliegt der fast beliebigen Manipulation durch Fahrplan und Benutzer. Die Zeit kann daher nur Attribut sein, nicht Schlüssel. Die Lösung heißt Sequenznummer. Jeder Meldevorgang an der Zusi-Schnittstelle, gleich ob synchron oder asynchron, wird je Element mit einer fortlaufenden und eindeutigen Sequenznummer versehen. Diese Schnittstelle gibt es nur einmal, und hier kann die Ordnung garantiert werden. Trifft also eine Meldung mit einer niedrigeren Sequenznummer beim Stellwerk ein, als bereits vorhanden, so kann man diese Meldung als veraltet verwerfen.

Soweit mein Zwischenbericht, jetzt heißt es leider wieder Unterbrechung zugunsten aktueller AR- und GF-Problemchen.

PS: Als .Net 2.0 auf den Markt kam und Generics(Templates) einführte, hatte ich gehofft, die von mir innig geliebten Collection-Klassen würden gründlich verbessert und systematisiert. Das erfolgte auch zum Teil, der Umfang blieb aber relativ bescheiden. Es gibt jedoch Abhilfe, die "C5"-Bibliothek, von Kopenhagener Wissenschaftlern, sogar ohne Lizenzrestriktionen: http://www.itu.dk/research/c5/" target="_blank Damit fühlt man sich als langjähriger C++-Anwender der STL auch in .Net zu Hause. Hier findet man Lösungen, wenn es komplizierter wird. Die Stellwerkstechnik allerdings kommt bisher noch mit den einfachen Collection-Klassen des .Net-Frameworks aus.

Benutzeravatar
(Ar-) T-Rex
Beiträge: 4795
Registriert: 19.02.2003 21:07:56
Aktuelle Projekte: Seit 65 Millionen Jahren die Entwicklung der Eisenbahn beobachten
Wohnort: Österreich
Kontaktdaten:

Re:

#14 Beitrag von (Ar-) T-Rex »

Daniel Rüscher hat geschrieben:Jetz dauerts ne Woche länger....
Eine Woche? Ein Jahrzehnt! (Wenn ich Rolands Ausführungen so überfliege ...)

Arthur :hat2
ZPA-Bereich Österreich

E-mail:
oesterreich@zpa.zusi.de

Christopher Spies
Beiträge: 775
Registriert: 26.01.2005 16:10:18
Wohnort: Darmstadt

Re: Stellwerk

#15 Beitrag von Christopher Spies »

Roland Ziegler hat geschrieben:Fahrstraßen (Zugstraßen) haben für die Stellwerkskommunikation etwas ambivalentes. Fahrstraßen sind Funktionselemente des Stellwerks und unterliegen dessen alleiniger Verantwortung. Sie haben keine Entsprechung in Außenanlagen (Zusi). Jedoch ist Zusi im Stellwerkemulationsbetrieb (Normalbetrieb bei Zusi) seinerseits für die Fahrstraßen verantwortlich. Beim Anmelden eines Stellwerks und der Übernahme des Betriebs von Zusi muss das Stellwerk über den aktuellen Zustand der Fahrstraßen informiert werden. Denn das Stellwerk ist nicht notwendigerweise in Grundstellung, wenn die Anmeldung erfolgt. Eine Abmeldung des Stellwerks kann jederzeit und abrupt erfolgen, ohne die Chance, den Zustand der Fahrstraßen wieder an Zusi zurückzumelden. Deshalb wird das Zusi-Stellwerk Fahrstraßenzustandsänderungen laufend an Zusi melden. Eine logische Funktion ist damit aber während der Betriebszeit des Stellwerks nicht verbunden.
Ich lese da einen gewissen Widerspruch heraus:
Einerseits stellt Roland korrekterweise fest, dass Fahrstraßen allein Sache des Stellwerks sind.
Andererseits sollen die Stellwerke aber Fahrstraßenzustandsänderungen an Zusi zurückmelden. Betrifft das nur den Emulationsbetrieb oder gilt das für jeden Client?

Anders ausgedrückt: Was ist z.B. mit Stellwerken, die keine Fahrstraßen kennen? Können diese einfach die von Zusi gemeldeten Fahrstraßen nach der Anmeldung verwerfen und auf die Meldung von Zustandsänderungen verzichten?

Wird die Verwaltung der Fahrstraßen schon (quasi automatisch) von der vorgesehenen Kommunikationsschnittstelle übernommen werden oder wird jeder Client das selbst implementieren müssen?

Gruß,
- Christopher

Michael_Oppenauer
Beiträge: 182
Registriert: 29.06.2006 16:53:54
Wohnort: KBS 786 (Remsbahn) km 14,4

Re: Stellwerk

#16 Beitrag von Michael_Oppenauer »

So wie ich das verstanden habe geht es hierbei ja hauptsächlich um die Initialisierung von Clients.
Die Zustände von Weichen, Signalen, Gleisbelegungen hat Zusi und kann sie einem Client zur Initialisierung übergeben. Den Zustand der Fahrstraßen bräuchte Zusi aus funktionellen Gründen nicht verwalten. Wenn das Stellwerk nun aber diese Informationen zur Initialisierung braucht, wo soll es die herbekommen? Bei einem Wechsel von Emulator zu Stellwerkclient könnte ich den Emulator fragen. Doch was ist, wenn die Verbindung zum Stellwerkclient abreißt und z.B. der Emulator übernehmen muss? Woher sollen dann die Informationen kommen. Aus diesem Grund der Pufferplatz.

Was du als Client mit den Initialisierungsinformationen machst bleibt dir überlassen, natürlich kannst du sie auch verwerfen oder halt zur Initialisierung deiner internen Logik und Bedienoberfläche verwenden.

Was das Rückmelden angeht, so würde ich sagen: wo es keine Fahrstraßen gibt kann der Client auch keinen Status zurückmelden. Ansonsten meldet der Client halt die entsprechenden Zustände (Eingestellt, Verschlossen, Belegt, Freigefahren...) Schwierig wird dann allerdings der Wechsel von einem Client ohne Fahrstraßen auf einen Client mit Fahrstraßen, da diesem die Initialisierungswerte fehlen. Wenn der Zusi-Stellwerk-Emulator nun auf diese Informationen angewiesen ist, so wären in der Tat keine Stellwerke ohne Fahrstraßen möglich oder der entsprechende Client muss selber im Hintergrund diese Fahrstraßen emulieren.

Gruß
Michael
In der Hoffnung durch vorhandene Rechtschreibfehler nicht die Diskussion vom eigentlichen Thema abzulenken.

Benutzeravatar
Roland Ziegler
Beiträge: 5508
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

Re: Stellwerk

#17 Beitrag von Roland Ziegler »

So wie Michael es beschreibt ist es auch gedacht, mit einem kleinen Unterschied: In Zusi 3 gibt es explizite Fahrstraßen von Hause aus: http://www.zusi.de/zusi3/zusi3signale.htm" target="_blank

Um die Schnittstellen einfach zu halten, soll auf die Übertragung "transienter" Zustände verzichtet werden. Somit haben Fahrstraßen in Form von Datenaustausch auch nur zwei Zustände. Das ist zumindest die Wunschvorstellung.

Eine der Überlegungen zu Anfang war, wenn ein Stellwerk-Client aktiv ist, dann ist er auch allein verantwortlich. Sinn oder Unsinn von Stellwerkshandlungen wird von Zusi nicht mehr gegengeprüft. Bei aktivem Stellwerks-Client hat der Zusi-Fahrdienstleiter Pause. Das Konzept verlangt, dass der Stellwerks-Client Zusi über die Fahrstraßen auf dem laufenden hält, selbst dann, wenn der das spezifische Stellwerk ohne Fahrstraßen auskommt. Möglicherweise lässt ein solches Stellwerk die von Zusi gemeldeten Fahrstraßenzustände einfach komplett unverändert, wobei ich mir allerdings vorstellen könnte, dass Zusi einen solchen Zustand mit zur Fahrstraßenlage abweichenden Weichen- und Signalstellungen nachher nicht mehr ohne weiteres aufgelöst bekommt. Warten wir das einmal ab. Vordringlich geht es Moment darum, alle Zustände jederzeit vollständig und synchron austauschen und mitführen zu können. Stellwerks-An- und -Abmeldung sind hierbei singuläre dedizierte Ereignisse, die eine konkrete, aber durchaus flexible Handlungskette nach sich ziehen.

Das An- und Abmelden ist simulationsspezifisch. Es entspricht nicht dem, was beim Vorbild mit dem Durchschalten eines Stellwerks oder Übergang von Fern- auf Ortsbedienung verbunden ist.

Die Module der Kommunikationsschnittstelle sind momentan weitgehend zustandsfrei, d.h. es wird der aktuelle Zustand der Stw-Komponenten nicht vorgehalten. Was gespeichert wird, sind die aktuellen Abonnements der einzelnen Clients. Man kann aber durchaus über einen Cache nachdenken, um Zusi zu entlasten. Hängt nicht nur von mir ab.

Christopher Spies
Beiträge: 775
Registriert: 26.01.2005 16:10:18
Wohnort: Darmstadt

Re: Stellwerk

#18 Beitrag von Christopher Spies »

Roland Ziegler hat geschrieben:Eine der Überlegungen zu Anfang war, wenn ein Stellwerk-Client aktiv ist, dann ist er auch allein verantwortlich. Sinn oder Unsinn von Stellwerkshandlungen wird von Zusi nicht mehr gegengeprüft. Bei aktivem Stellwerks-Client hat der Zusi-Fahrdienstleiter Pause.
Genau das hatte ich auch in Erinnerung, deshalb fragte ich ja :) .
Roland Ziegler hat geschrieben:Möglicherweise lässt ein solches Stellwerk die von Zusi gemeldeten Fahrstraßenzustände einfach komplett unverändert
Das muss wohl so sein, wie sollte ein Stellwerk, welches die Fahrstraßenphilosophie von Zusi nicht teilt, diese sonst verwalten?
Roland Ziegler hat geschrieben:wobei ich mir allerdings vorstellen könnte, dass Zusi einen solchen Zustand mit zur Fahrstraßenlage abweichenden Weichen- und Signalstellungen nachher nicht mehr ohne weiteres aufgelöst bekommt. Warten wir das einmal ab.
Das Zusi-Stellwerk könnte bei Abmeldung eines Clients über alle eingerichteten Fahrstraßen oder "Fahrt" zeigenden Hauptsignale iterieren und prüfen, ob die Bedingungen zum Einstellen dieser Fahrstraße erfüllt sind. Sind sie es nicht, wird die Fahrstraße eben nicht eingestellt und das Hauptsignal auf "Halt" zurückgenommen. Alternativ könnte Zusi alle Elemente erst einmal in ihrer Lage belassen und sie erst nach und nach umstellen, soweit sie zur Einstellung weiterer von Zügen angeforderten Fahrstraßen benötigt werden
(oder nachdem es gekracht hat :hat2 ).

Diese Problemstellung betrifft ja nicht nur fahrstraßenlose Stellwerke, sondern z.B. auch die Anschaltung des Ersatzsignals ohne Fahrstraßensicherung, was ja erlaubt und möglich ist, vom Zusi-Fahrdienstleiter aber vermutlich nie gemacht wird.
Roland Ziegler hat geschrieben:In Zusi 3 gibt es explizite Fahrstraßen von Hause aus: http://www.zusi.de/zusi3/zusi3signale.htm" target="_blank [...] Somit haben Fahrstraßen in Form von Datenaustausch auch nur zwei Zustände. Das ist zumindest die Wunschvorstellung.
Es bleibt zu hoffen, dass man sich auf diese Weise nicht zu sehr auf das deutsche Signal- und Sicherungswesen versteift!

Gruß,
- Christopher

Benutzeravatar
Frank Wenzel
Beiträge: 5118
Registriert: 06.11.2001 01:13:47
Wohnort: Trier
Kontaktdaten:

Re: Stellwerk

#19 Beitrag von Frank Wenzel »

Christopher Spies hat geschrieben:...Diese Problemstellung betrifft ja nicht nur fahrstraßenlose Stellwerke, sondern z.B. auch die Anschaltung des Ersatzsignals ohne Fahrstraßensicherung, was ja erlaubt und möglich ist, vom Zusi-Fahrdienstleiter aber vermutlich nie gemacht wird...
Wenn ich das richtig verstehe, dann bedeutet das, dass der Stellwerk-Client Signalstörungen "generieren" können muss, so wie Zusi das bisher auch schon macht. Im Prinzip finde ich das ganz gut, aber es gibt bestimmt den einen oder anderen FDL, der es mit der Ethik des Berufs nicht so genau nehmen könnte und absichtlich ein Ersatzsignal stellen würde, um es richtig krachen zu lassen... :( Um böswillige Eingriffe zu verhindern, sollte eine Ersatzsignalschaltung nur zugelassen werden, wenn auch eine Störung vorliegt.

Über ähnliches sollte auch im Zusammenhang mit Rangierfahrstraßen nachgedacht werden.
Gruß ins Forum, Frank - www.zusi-sk.eu - Youtube

Jannis
Beiträge: 40
Registriert: 20.09.2007 20:20:30
Kontaktdaten:

Re: Stellwerk

#20 Beitrag von Jannis »

Frank Wenzel hat geschrieben: Um böswillige Eingriffe zu verhindern, sollte eine Ersatzsignalschaltung nur zugelassen werden, wenn auch eine Störung vorliegt.
Das kommt ja so etwa auf das was ich hier mal zusammengeschrieben habe raus. Es wird ja wohl nicht wirklich schwer sein, herauszufinden, wer dieser chaos FDL ist. Der FDL müsste sich einfach mit seinem ZuSi Lizenzkey oder ähnlichem anmelden, man müsste sich nurnoch ein "Bestrafungssystem" ausdenken :elk

Jannis
Zuletzt geändert von Jannis am 23.07.2008 20:07:36, insgesamt 1-mal geändert.

Antworten