Zusi und Stellwerke

[Daniel Rüscher aka Merlin]

Richtig Roland,

Das war genau mein Gedankengang zum Thema Architektur.

Als weiteres Stichwort würde ich noch die Skalierbarkeit / Verteilbarkeit auf mehrere Rechner mit reinnehmen.

Desweiteren würde ich wagerecht abzweigend von der Stellwerkslogik noch ein weiteres Interface hinzufügen. Sinn hinter dem Gedanken: Man soll noch Zusätzlich zu projektierende Subsysteme (LZB, Rottenwarnanlage, Windwarnanlage udgl. Gibt ja da einiges) anschließen können.

Weiterhin kann man noch ein DokumentationsSubsystem andenken. Liegt auf der Ebene des Cliens, die Ausgabe kann über das Visualisierungsmodul erfolgen. Dieses System könnte z.B. Zugmeldungen, Zählpflichtige Bedienhandlungen oder Störungen der Anlage dokumentieren. Clou an dem Ganzen: Es dokumentiert sowohl gewollte d.h. simulierte Fehler (Weichenstörung, Signalstörung usw.) wie auch typische Softwarefehler wie Kommunikationsfehler, Modulabstürze usw. Das würde auch das Debuging extrem vereinfachen. Also die Dokumentation realer Fehler ist also Quasi eine zentrale "Fehlermeldungsauflaufstelle." Eventuell kann das Modul auch mit Bidirektionaler Kommunikation arbeiten um auch als Elektronisches Notitzbuch Fernsprechbuch und so weiter benutzt werden zu können. Auch ein Abwandern der Bewertung (Wie die Bewertung bei Fahrtende in Zusi) könnte in dieses Modul abwabdern.

Nochmal zum Visualisierungsmodul: Damit meinst du die Visualisierung der Bfo und so weiter?

So, das waren nochmal n paar konzeptionelle Gedanken zum Aufbau von meiner Seite aus.

Gruß Daniel

Edit: DokumentationsSubsystem etwas genauer erklärt und Seite 10 eröffnet *g*

[Michael_Poschmann]

Als weiteres Stichwort würde ich noch die Skalierbarkeit / Verteilbarkeit auf mehrere Rechner mit reinnehmen.

Desweiteren würde ich wagerecht abzweigend von der Stellwerkslogik noch ein weiteres Interface hinzufügen. Sinn hinter dem Gedanken: Man soll noch Zusätzlich zu projektierende Subsysteme (LZB, Rottenwarnanlage, Windwarnanlage udgl. Gibt ja da einiges) anschließen können.

Ich bitte wieder um Maßhalten (nicht im bayrischen Sinne!) - wir sollten unseren Enkeln und den Firmen, die diese Probleme mit umfangreichem Personalstamm in der Realität zu lösen trachten, ihre Aufgaben belassen. Anders formuliert: Ich möchte eine reelle Chance haben, die Umsetzung der Stellwerkerei noch zu erleben.

...DokumentationsSubsystem ...
Clou an dem Ganzen: Es dokumentiert sowohl gewollte d.h. simulierte Fehler (Weichenstörung, Signalstörung usw.) wie auch typische Softwarefehler wie Kommunikationsfehler, Modulabstürze usw. Das würde auch das Debuging extrem vereinfachen. Also die Dokumentation realer Fehler ist also Quasi eine zentrale "Fehlermeldungsauflaufstelle."

Bitte genau das nicht so umsetzen, sondern sauber zwischen Bedienung der Stellwerkerei und Debugging-Infos trennen. Mit den Konsequenzen der Vermischung dieser Ansätze darf ich mich bisweilen herumplagen. Das geht regelmäßig in die Hose.

Michael

[Daniel Rüscher aka Merlin]

Als weiteres Stichwort würde ich noch die Skalierbarkeit / Verteilbarkeit auf mehrere Rechner mit reinnehmen.

Desweiteren würde ich wagerecht abzweigend von der Stellwerkslogik noch ein weiteres Interface hinzufügen. Sinn hinter dem Gedanken: Man soll noch Zusätzlich zu projektierende Subsysteme (LZB, Rottenwarnanlage, Windwarnanlage udgl. Gibt ja da einiges) anschließen können.

Ich bitte wieder um Maßhalten (nicht im bayrischen Sinne!) - wir sollten unseren Enkeln und den Firmen, die diese Probleme mit umfangreichem Personalstamm in der Realität zu lösen trachten, ihre Aufgaben belassen. Anders formuliert: Ich möchte eine reelle Chance haben, die Umsetzung der Stellwerkerei noch zu erleben.

Hmm... da hast du mich etwas Missverstanden oder ich hab ins Terminusklo gegriffen:

Mit Skalieren meinte ich eigentlich, von vorneherein das Konzept so auszulegen das die einzelnen Programmkomponenten in eigene Dateien (*.exe o.ä.) Abwandern und über TCP/IP (z.B.) komunizieren. Bietet sich bei dem Konzept ja geradezu an. Der Gedanke zielt dadrauf ab das man z.B. auf einer LAN mit mehreren Clients auf eine Stellwerkslogik zugreifen kann, wie im richtigen Leben halt auch. Damit kann man auch ohne Probleme LeiBit nachbilden, indem man sowohl einen normalen Client mit dem Kern verbindet und auch einen noch "Dummeren" Client der nur anzeigewn kann.

Und die Geschichte mit LZB und Co. entpuppt sich bei näherem hinschauen bloß als eine Schnittstelle die auf die Stellwerkslogik zugreifen kann.

Übrigens wird auch bayrisches Maßhalten immer mehr zum Luxus.

...DokumentationsSubsystem ...
Clou an dem Ganzen: Es dokumentiert sowohl gewollte d.h. simulierte Fehler (Weichenstörung, Signalstörung usw.) wie auch typische Softwarefehler wie Kommunikationsfehler, Modulabstürze usw. Das würde auch das Debuging extrem vereinfachen. Also die Dokumentation realer Fehler ist also Quasi eine zentrale "Fehlermeldungsauflaufstelle."

Bitte genau das nicht so umsetzen, sondern sauber zwischen Bedienung der Stellwerkerei und Debugging-Infos trennen. Mit den Konsequenzen der Vermischung dieser Ansätze darf ich mich bisweilen herumplagen. Das geht regelmäßig in die Hose.

Michael

Durch ein Dokumentationsmodul wird ja sauber getrennt. Das Modul macht eigentlich nix anderes als aufzuschreiben was ihm gesagt wird. Die normalen Fehlermeldungen laufen dann nur an einer zentralen Stelle auf, und werden von dieser dokumentiert, anstatt als Fehlermeldung auf dem Bildschirm zu erscheinen.

Mei und die normalen Handlungen der Software kann man ja gleich mitdokumentieren. Man kann ja sagen den Gewollten fehlern wird ein Störung als Prefix vorangestellt, und was diesen Prefix trägt wird in eine eine Datei gespeichert, der Rest in einer andere. Und schon hat man Debuginfos vom Rest getrennt.

Oder versteh ich dich da irgendwie ganz verkehrt.

Gruß Daniel

[Roland Ziegler]

Bzgl Logging: ein einfacher Log-File bzw dessen Kopie in ein Meldungsfenster tut's sicher auch.

Verteilbarkeit des Systems: Klar, schwebt mir auch vor. Nur möchte ich das ungern selbst programmieren, sondern durch Middleware erschlagen lasssen. .Net Remoting böte sich geradezu an.

[Michael_Poschmann]

Ok, das Mistverständnis lag auf meiner Seite, ich hatte den Wunsch nach mehr Rechenpower durch den Einsatz von Mehrprozessorsystemen befürchtet.

Michael

[Daniel Rüscher aka Merlin]

Bzgl Logging: ein einfacher Log-File bzw dessen Kopie in ein Meldungsfenster tut's sicher auch.

Verteilbarkeit des Systems: Klar, schwebt mir auch vor. Nur möchte ich das ungern selbst programmieren, sondern durch Middleware erschlagen lasssen. .Net Remoting böte sich geradezu an.

Sicher, nur mit eigenem Programm ließe sich das wesentlich schöner gestalten und auch Leichter Warten. Und es ließe dann irgendwann auch so nette Spielereien zu die der DokuAdmin auf einem Echten Stellwerk machen kann.
Desweiteren kann man dann Später auch solche Sachen machen wie Stellwerkssitzung aufzeichnen und zu einem Späteren Zeitpunkt wiederabspielen (in Verbindung mit dem Zusatzinterface der Stellwerkslogik die ich in Verbindung mit der LZB erwähnt hatte).

Das mit der Middleware musst du mir nochmal genauer erklären... .Net Remoting ist Routingfähig?

Ok, das Mistverständnis lag auf meiner Seite, ich hatte den Wunsch nach mehr Rechenpower durch den Einsatz von Mehrprozessorsystemen befürchtet.

Näääää... Das wäre wie mit Katzen auf Spatzen schießen. Soooo Rechenhungrig sind Stellwerke nun wohl auch nicht. Und wenn man doch irgendwann mal mehr Power braucht ruft man Tim Tailor oder nimmt nen 2ten Rechner und teilt die Stellwerkslogik auf beide auf, oder gliedert (wenn alles auf einem Rechner läuft) einzelne Programme (Doku, LZB, Visualisierung, Client und so aus). Engpässe umgehen impliziert mein Vorschlag, die gesamte Kommunikation (Zwischen den Programmen) über TCP/IP laufen zu lassen, schon.

Gruß Daniel

[Roland Ziegler]

.Net Remoting ist Routingfähig?

Aber selbstverständlich. .Net Remoting bietet "out of the box" zwei verschiedene Protokolle ("Channels"), entweder SOAP oder ein binäres, ebenfalls auf TCP aufsetzendes. Und alles, was IP heißt, lässt sich natürlich routen. Es ist eine echte, zudem ausgesprochen flexible Lösung für verteilte Objekte, und deutlich einfacher zu nutzen als etwa CORBA oder auch DCOM (CORBA verwendet IIOP, DCOM verwendet DCE/RPC, beides ebenfalls TCP/IP basiert und genauso routeable).

[Daniel Schuhmann]

Näääää... Das wäre wie mit Katzen auf Spatzen schießen.

Die armen Katzen, sollten es nicht doch eher die Kanonen sein? Siehe auch...

SCNR,
Daniel

[Daniel Rüscher aka Merlin]

Waren in meinem Fall, weil ich einfach mal Lust hatte, wirklich die Katzen, auch wegen der Reime. Aber den Artikel hatte ich vlt. ne Stunde davor erst gelesen.

@ .net Remoting: Seeehrgut.

[Christopher Spies]

Ich denke, wir kommen voran. Das Modul-Diagramm findet meine Zustimmung !
Man muss ja auch mal positives Feedback geben, und nicht immer nur 'rummeckern...

Wobei ich gleich schon wieder fragen muss, wo denn eigentlich der Unterschied zwischen Blockfeld und Register ist? OK, im realen Stellwerk sind das zwei völlig verschiedene Dinge, aber wo ist der Zusi-technische Unterschied?

Die Systemarchtitektur weist im wesentlichen eine vertikale Gliederung auf. Diese Gliederung ist im Paket-Diagramm "Module" angedeutet. Module heißt für die spätere Ausprägung auch selbständige, austauschbare Einheiten: "DLLs"

Hier habe ich noch kleinere Verständnisschwierigkeiten. Soll das nun bedeuten, dass für ein Rumänisches Stellwerk eine andere "Stellwerkslogik-DLL" hermuss als für ein deutsches Stellwerk? Oder bedeutet dass nur, dass die Stellwerkslogik ein eigenes Modul für sich darstellt?

Konsequent OO heißt, ich spreche mit der Zusi-Weiche oder dem Zusi-Signal direkt (bzw mit dessen Proxy), aber nicht mit einem Objekt "Gateway".

Sehr sinnvoll! Ich schlussfolgere daraus allerdings auch, dass wir uns nicht zu sehr an realen Stellwerken orientieren, sondern unsere Aufmerksamkeit auf zusi-intern tatsächlich abbildbare Objekte konzentrieren sollten. Um zu meiner obigen Frage zurückzukehren: Wenn Blockfelder und Register für Zusi dasselbe sind, braucht man sie auch nicht getrennt voneinander zu modellieren.

Man könnte ja AndiKs Idee - die auf Carstens Punkt 1 wohl zutrifft - anpacken und den Wortschatz der Makrosprache so aufbauen, dass ein Urstw entstehen kann!?

Denn irgendwie find ich die Idee, das ganze (teilweise) auf Deutschland/Schweiz/Österreich einzugrenzen, um dann später wieder ein Modulhickhack für ausländische Stws anzufangen, nicht so toll.

Der Punkt ist: Wenn man die Grundbausteine (= einzelne Skript-/Makrobefehle) allgemein genug hält kann man auch internationale Spezialitäten damit umsetzen, weil man das Verhalten der Anlage in einer Situation komplett neu programmieren kann.

Ich muss sagen, die in diesen Aussagen entwickelte Idee finde ich sehr attraktiv. Dieser Ansatz böte maximale Freiheit!
Allerdings änderte sich dann die Zielsetzung; vom Stellwerk bliebe nur noch untere und mittlere Ebene, darauf setzten dann Makros auf.
Überspitzt ausgedrückt: Vom Stellwerks-Simulator zum Makro-Interpreter !

- Christopher

[Daniel Rüscher aka Merlin]

Ich denke, wir kommen voran. Das Modul-Diagramm findet meine Zustimmung !
Man muss ja auch mal positives Feedback geben, und nicht immer nur 'rummeckern...

Wobei ich gleich schon wieder fragen muss, wo denn eigentlich der Unterschied zwischen Blockfeld und Register ist? OK, im realen Stellwerk sind das zwei völlig verschiedene Dinge, aber wo ist der Zusi-technische Unterschied?

Die Systemarchtitektur weist im wesentlichen eine vertikale Gliederung auf. Diese Gliederung ist im Paket-Diagramm "Module" angedeutet. Module heißt für die spätere Ausprägung auch selbständige, austauschbare Einheiten: "DLLs"

Hier habe ich noch kleinere Verständnisschwierigkeiten. Soll das nun bedeuten, dass für ein Rumänisches Stellwerk eine andere "Stellwerkslogik-DLL" hermuss als für ein deutsches Stellwerk? Oder bedeutet dass nur, dass die Stellwerkslogik ein eigenes Modul für sich darstellt?

Sowohl als auch. Man kann natürlich alles irgendwie in eine Monsterlogik packen, das würde aber das Konzept der strikten Modularisierung torpedieren. Kleines Beispiel: während man bei einem mechanischen oder elektromechanischen Stellwerk auf das Interface für die LZB, oder auf Rangierfahrstraßen (die kennt ein Mech/EMech nicht) eigentlich Verzichten kann (Modulvereinfachung, leichtere Wartbarkeit, Geringere Bug Gefahr, da weniger Code), braucht man in einem Elekrtonischen Stellwerk wieder keinen Bahnhofsblock (Um Missverständnissen vorzubeugen: Bahnhofsblock braucht man schon, nur muss man ihn nicht wirklich fein und realitätsnah modellieren. Da reicht eine einfache Umsetzung, z.B. mit einer Variablen) oder GWB Ansätze vorsehen. Das russische wird wieder ganz anders aussehen.

Konsequent OO heißt, ich spreche mit der Zusi-Weiche oder dem Zusi-Signal direkt (bzw mit dessen Proxy), aber nicht mit einem Objekt "Gateway".

Sehr sinnvoll! Ich schlussfolgere daraus allerdings auch, dass wir uns nicht zu sehr an realen Stellwerken orientieren, sondern unsere Aufmerksamkeit auf zusi-intern tatsächlich abbildbare Objekte konzentrieren sollten. Um zu meiner obigen Frage zurückzukehren: Wenn Blockfelder und Register für Zusi dasselbe sind, braucht man sie auch nicht getrennt voneinander zu modellieren.

Eigentlich eine falsche Schlussvolgerung: Durch einfachen Gatewayaustausch kann mit dem Ansatz von Aushebelung des Zusifahrdienstleiters auf Steuerung einer Modellbahnanlage umgestellt werden, Wenn die Vorbedingungen erfüllt sind.Mit Vorbedingungen mein ich genauer: Die Modellbahn muss dafür ausgerüstet sein (vlt. Isolierte Gleise, Elektrische Signale, elektrische Weichen usw.) Jemand muss eine Steuerelektronik entwickeln und jemand muss natürlich auch den passenden Gateway programmieren. Diese Sachen können und werden wir (also das eigentliche Entwicklerteam) wohl nicht machen.

Nochmal zum Verständniss: Die Unterste Schicht aka Gateway wird ZUsi nurnoch sagen: Signal A werd grün, Weiche2 Umstellen in Linkslage, BÜ III geh zu; und wird natürlich die dementsprechenden Rückmeldungen empfangen.

Man könnte ja AndiKs Idee - die auf Carstens Punkt 1 wohl zutrifft - anpacken und den Wortschatz der Makrosprache so aufbauen, dass ein Urstw entstehen kann!?

Denn irgendwie find ich die Idee, das ganze (teilweise) auf Deutschland/Schweiz/Österreich einzugrenzen, um dann später wieder ein Modulhickhack für ausländische Stws anzufangen, nicht so toll.

Der Punkt ist: Wenn man die Grundbausteine (= einzelne Skript-/Makrobefehle) allgemein genug hält kann man auch internationale Spezialitäten damit umsetzen, weil man das Verhalten der Anlage in einer Situation komplett neu programmieren kann.

Ich muss sagen, die in diesen Aussagen entwickelte Idee finde ich sehr attraktiv. Dieser Ansatz böte maximale Freiheit!
Allerdings änderte sich dann die Zielsetzung; vom Stellwerk bliebe nur noch untere und mittlere Ebene, darauf setzten dann Makros auf.
Überspitzt ausgedrückt: Vom Stellwerks-Simulator zum Makro-Interpreter !

Das ist allerdings auch wahr....

So wie beschrieben sehe ich die Sache jedenfalls. Roland möge mich korrigieren in den Punkten in denen ich ihn Missverstanden habe.

Gruß Daniel

[Carsten Hölscher]

Unser Blockfeld entspricht dem echten Blockfeld.

Unsere Register entsprechen dem Verschlußkasten, ist also schon ein klarer Unterschied (auch wenn es irgendwo zusammenwirkt).

Carsten

[Roland Ziegler]

Ein Register ist zunächst die abstrakte Grundform einer Verriegelung, bzw eines Verschlusses, wie sie Zusi verwendet wird. Eine Anwendung (wohl keine Ableitung) dieser Grundform im Stellwerk könnte z.B. ein Blockfeld sein, eine andere ein Tyerscher Train Tablet Apparat, wie er auf meiner Webseite vorgestellt wird. Ein Blockfeld kann aber mehrere Verschlüsse besitzen, wie von Lutz beschrieben.

Für unsere Architektur erscheint es auf unterster Ebene zunächst ideal, wenn eine vollständige Entkopplung der Sicherungsebene zwischen Zusi und Stellwerk stattfindet. Also entweder macht Zusi das, so wie bisher, oder das Stellwerk trägt die Verantwortung.

Die Register, die in Zusi intern für die Verriegelung sorgen, könnten in Betriebsart Stellwerk unberücksichtigt bleiben.

Allerdings, und das macht die Sache komplizierter, sollen Betriebsartwechsel unterstützt werden. Und da das Stellwerk zum Zeitpunkt eines solchen Betriebsartwechsels nicht unbedingt in Grundstellung liegen muss, gibt es beim Wechsel der Verantwortung so einiges an Zuständen abzugleichen.

Da man tunlichst doppelte Verantwortung vermeidet (heißt nämlich meist, dass es keiner gewesen ist) wäre z.B. ein Overwrite Mode denkbar. Liegt also die Verantwortung beim Stellwerk, werden auch alle Bedindungen nur auf Stellwerkseite geprüft, alle Verschlüsse dort ausgeführt, aber die Ergebnisse trotzdem zu Zusi übertragen, egal, was Zusi registermäßig dazu sagen würde.

Machte man es anders, ließe also zu, das Zusi Stellwerksaufträge kommentiert, dann läge ein Teil der Verantwortung eben bei Zusi und das gäbe Brüche im Modell.

Geht man von konstistenten und logisch geprüften Stellwerken aus, wird es beim Verantwortungswechsel zu Zusi dann keine Abgleichprobleme geben, weil die Zustände konstistent sind.

Umgekehrt, beim Wechsel zum Stellwerk, bleibt aber mehr zu tun, die Zahl der Element im Stellwerk ist größer als in Zusi. Hier wird die Zusi-Fahrstraße sicher mit involviert werden, und daraus abgeleitet. Es wird im Stellwerk keine Fahrstraße geben können, die es nicht auch in Zusi gibt.

[Daniel Rüscher aka Merlin]

Umgekehrt, beim Wechsel zum Stellwerk, bleibt aber mehr zu tun, die Zahl der Element im Stellwerk ist größer als in Zusi. Hier wird die Zusi-Fahrstraße sicher mit involviert werden, und daraus abgeleitet. Es wird im Stellwerk keine Fahrstraße geben können, die es nicht auch in Zusi gibt.

Ließe es sich hier nicht einfach so machen das das Stellwerk, wenn es verbinden will, zu Zusi sagt: Gib mir einen Bericht: Zusi dadraufhin sagt: Fahrstraße 1 Eingelaufen, Fahrstraße X eingelaufen, Signal X auf Zs1. Und dieser Zustand einfach im Stellwerk dargestellt wird.

Ich tätige damit folgende Aussage: Die Grundstellung der Fahrstraße ist nicht eingelaufen, der Zustand des Signals ist Haltzeigend / Aus (bei Zs6 z.B.) die Grundstellung der Weiche ist gerader Strang, der Der Grundzustand des Gleises ist frei.
Also quasi der Denkansatz, das das Stellwerk beim Verbinden nicht alle Zustände abfragt, sondern lediglich eine Berichtfunktion anstößt, die dem Stellwerk vom Grundzustand abweichende Zustände sagt.

Gruß Daniel

[(Ar-) T-Rex]

In diesem Zusammenhang:

Selbstblocksignale (ausgenommen Zentralblock, da kann es anders sein) zeigen in blockmäßig "erlaubter Fahrtrichtung" in der Grundstellung "Frei" (die "entgegen der Richtung" zeigen "Halt!"); beim Umschalten der "Richtung" springen sie jeweils um.

Ist das für Zusi angedacht?

Arthur

[Jörg Petri]

... Selbstblocksignale (ausgenommen Zentralblock, da kann es anders sein) zeigen in blockmäßig "erlaubter Fahrtrichtung" in der Grundstellung "Frei" (die "entgegen der Richtung" zeigen "Halt!"); beim Umschalten der "Richtung" springen sie jeweils um. ...

Kurze Funktionserklärung:
Selbstblocksignale zeigen in der Grundstellung "Frei". Ausnahmen können solche Signale sein, welche gleichzeitig als Deckungssignale für Bahnübergänge verwendung finden. Deren Steuertechnik werden durch den Zug in entsprechender Entfernung angestoßen. Diese Deckungstechnik gab es nicht nur bei der DR. Als Beispielstrecke kenne ich im DB-Bereich den Abschnitt Eichenberg-Bebra über Bad Sooden-Allendorf.
Zentralblocksignale haben als Grundstellung "Halt". Sie können durch mehrere Situationen angesteuert werden. 1.Zblksig nach einer Bf-Ausfahrt durch Einstellen einer Zugfahrt aus das selbige. Folgende Zblksig durch eine Art Dominoeffekt mit eventueller Stellspeicherung.

Das Umschalten der Selbstblocksignale bei Richtungs-/Erlaubniswechsel kann meines Wissen in zwei arten erfolgen. 1. Dunkelschaltung der nicht benötigten Fahrtrichtung und 2., was eigendlich das Weitverbreiteste sein dürfte, der wechsel von "Frei" in "Halt".
Die Bezeichnung "Frei" deshalb, da es ja auch Signale mit Haupt- und Vorsignalfunktion als Blocksignale gibt.

@Lutz
Sind die Ausführungen so richtig??

[Arie van Zon]

Bei uns gibt es von aussen sichtbar zwei Selbstblockbauarten:

Allgemein: Sbk mit automatischer Fahrtrichtungseinstellung: alle Signale zeigen in der Grundstellung grün bis eine Fahrstrasse nach die freie Strecke eingestellt wird. Ab dieser Augenblick zeigen die Signale in die Gegenrichtung "stop" bis der Zug das Block vor einem Signal verlassen hat.

Sonderfall: Sbk mit vom Fahrdienstleiter eingestellter Fahrtrichtung: alle Signale im Fahrtrichtung zeigen in der Grundstellung grün. Alle Signale in die Gegenrichtung zeigen "stop".

Bei dichtem Zugverkehr sieht man aber den Unterschied nicht.

Gruss, Arie

[Christopher Spies]

Eigentlich eine falsche Schlussvolgerung: Durch einfachen Gatewayaustausch kann mit dem Ansatz von Aushebelung des Zusifahrdienstleiters auf Steuerung einer Modellbahnanlage umgestellt werden [...] Die Unterste Schicht aka Gateway wird ZUsi nurnoch sagen: Signal A werd grün, Weiche2 Umstellen in Linkslage, BÜ III geh zu; und wird natürlich die dementsprechenden Rückmeldungen empfangen.

Das klingt sehr vernünftig .

Nochmals zur Erinnerung, um die Diskussion wieder in Gang zu bringen:

Man könnte ja AndiKs Idee - die auf Carstens Punkt 1 wohl zutrifft - anpacken und den Wortschatz der Makrosprache so aufbauen, dass ein Urstw entstehen kann!?

Denn irgendwie find ich die Idee, das ganze (teilweise) auf Deutschland/Schweiz/Österreich einzugrenzen, um dann später wieder ein Modulhickhack für ausländische Stws anzufangen, nicht so toll.

Der Punkt ist: Wenn man die Grundbausteine (= einzelne Skript-/Makrobefehle) allgemein genug hält kann man auch internationale Spezialitäten damit umsetzen, weil man das Verhalten der Anlage in einer Situation komplett neu programmieren kann.

Ich muss sagen, die in diesen Aussagen entwickelte Idee finde ich sehr attraktiv. Dieser Ansatz böte maximale Freiheit!
Allerdings änderte sich dann die Zielsetzung; vom Stellwerk bliebe nur noch untere und mittlere Ebene, darauf setzten dann Makros auf.
Überspitzt ausgedrückt: Vom Stellwerks-Simulator zum Makro-Interpreter !

Hat sich -- außer Max Senft und Daniel Rüscher -- noch jemand Gedanken über den Vorschlag gemacht, AndiK's Makro-Ansatz auf die Spitze zu treiben und alle bauart-spezifischen Funktionen durch Makros zu realisieren? Ich befürworte diesen Vorschlag wie gesagt .

Dazu bräuchte man, wie von Max erwähnt, ein möglichst allgemeines "Ur-Stellwerk" sowie einen entsprechend mächtigen Makro-Interpreter.
Die Frage ist, ob man das will, denn zu viel Flexibilität kann bisweilen nutzlos sein...

Gibt es dazu Meinungen?

- Christopher

[Andreas Karg]

Die Frage ist, ob man das will, denn zu viel Flexibilität kann bisweilen nutzlos sein...

Genau an der Stelle bin ich noch dabei, am Grundkonzept rumzuschrauben. Meine Ur-Idee hätte nämlich bedeutet, im Prinzip jedes Objekt einzeln bei jedem Anwendungsfall neu zu programmieren - ziemlich überflüssig, da der Code bei Objekten vom gleichen Typ logischerweise auch fast identisch sein wird. Folglich müsste die Skriptsprache es ermöglichen, sowas wie Objektprototypen zu definieren (Also ein Standardsignal meinetwegen), die dann bei jedem Anwendungsfall mit den speziell benötigten Daten weiter befüllt werden. Weiters hab ich mir noch nicht viele Gedanken gemacht, wie die Verteilung der Bildschirmelemente auf mehrere Fensterchen (So würds ich jedenfalls mit einem mechanischen Stellwerk machen, Gleisbild im einen Fenster, Stellwerk im andern, wie im DB-eigenen Simulator) elegant zu lösen wäre, aber das sollte auch machbar sein.
Ansonsten hab ich mich mal mit Max und Daniel zusammengerauft, um aus der Idee mal ein rundes Konzept zusammenzuschrauben, das auch irgendwie verständlich ist. Seitdem weiß ich, wie sich Philosophen fühlen müssen, wenn sie ihre Gedanken niederschreiben - außer anderen Philosophen versteht die nämlich keiner, weil das Geschriebene so konfus ist, dass man genauso konfus sein muss wie der Schreiberling, ums verstehen zu können.

[Roland Ziegler]

...um aus der Idee mal ein rundes Konzept zusammenzuschrauben, das auch irgendwie verständlich ist. Seitdem weiß ich, wie sich Philosophen fühlen müssen, wenn sie ihre Gedanken niederschreiben - außer anderen Philosophen versteht die nämlich keiner, weil das Geschriebene so konfus ist, dass man genauso konfus sein muss wie der Schreiberling, ums verstehen zu können.

UML? scnr.