Zusi und Stellwerke

[(Ar-) T-Rex]

Das kann gerne geschehen, aber es wäre mE doch eher besser, von seiten der Entwickler konkrete Fragen an die Stellwerksexperten zu stellen, als diese "drauflosreden" zu lassen.

Arthur

[(Ar-) T-Rex]

Was Lutz da schreibt und beschreibt, ist absolut richtig und technisch einwandfrei; es gilt allerdings nur für das "typische" Einheitsstellwerk ("typisch" heißt: ein Befehlsstellwerk auf der einen Bahnhofseite und ein Wärterstellwerk auf der anderen).

Im Regelstellwerk sieht die Sache wieder ganz anders aus, zumal dort der Fdl (nur) ein Befehlswerk hat und zwei oder mehrere Wärterstellwerke erforderlich sind; außerdem berücksichtigt Lutz nur den Felderstreckenblock, nicht den elektrischen.

Aber ich frage mich wirklich (zum wiederholten Male, ohne jeweils eine Antwort gewürdigt worden zu sein), was das mit dem Wärterstellwerk soll. Offensichtlich muß dann der Zusi-Anwender zuerst als Fahrdienstleiter einen blockmäßigen Auftrag geben, den er dann - in schizophrener Weise vom Fdl Dr. Jekyll zum Stww Hyde verwandelt - selbst als Stellwerkswärter ausfühen muß?!?

Ich bin - alle Roland'schen (vorbildlichen!) Anstrengungen, Darstellungen und Überlegungen respektvoll, dankbar und hoffnungsfreudig bewundernd - zum x-ten Male und immer noch der Meinung, daß man mit einem einfachen Gleisbildstellwerk beginnen sollte, und die Spielereien á la Einheitsstellwerk, Regelstellwerk 5007, E 43, EM 55, OeSK 46, 72733 und viele andere mehr (auf denen ich allen herumgeschaltet habe und für die ich auch die entsprechenden Verwendungsprüfungen habe, das wolle nicht vergessen werden!) auf später verschieben sollte.

Oder verstehe ich da bloß etwas falsch???

Wenn man meiner Ansicht nicht zustimmt, dann werde ich noch seitlich an meinem Bildschirm eine Handkurbel für den Induktor einbauen müssen ...

Arthur

Edit: Roland,
die Signalzugschlußstelle ist jene vom Zug zu passierende Stelle im Gleis, wo das Signal auf Halt fällt bzw zurückgestellt werden darf (erste oder letzte Achse etc).

Nach Befahren der Fahrstraßenzugschlußstelle darf die Zug-(oder Hilfs-)fahrstraße aufgelöst werden bzw wird selbsttätig aufgelöst; bei Gleisbildstellwerken und anderen Stellwerken mit Teilfahrstraßen kann es mehrere davon geben.

Bei einfachen mechanischen Stellwerken kleiner Bahnhofsanlagen können beide Zugschlußstellen zusammenfallen. In signaltechnischen Lageplänen sind sie in der Regel darbestellt und im Sperren-und Verschlußplan genau bezeichnet. Bei Einfahrten wird die Fahrstraßenzugschlußstelle auch oft für die Möglichkeit der Rückblockung herangezogen.

[Andreas Karg]

Roland: Deswegen sag ich ja die ganze Zeit - Scripts! Eigentlich besteht ja jedes Stellwerk dieser Welt aus einfachen Gleisen, mehr oder weniger komplizierten Weichen, Signalen und Fahrstraßen und ggf. Sonderbedienhandlungen. Bietet man diese fünf Typen gewissermaßen als Stellwerkium-Atome an, um es dem Bastler zu überlassen, die lokalen Gegebenheiten mittels passender Reihenfolge der einzelnen Bedienabläufe festzulegen, hat man schon seine Internationalisierbarkeit. Diese Internationalisierbarkeit funktioniert dann nicht nur zwischen einzelnen Ländern, sondern auch zwischen Stellwerksbauformen...
Es ist mir hier jetzt wurscht, ob dieses Ding dann so implementiert wird wie ich das in meinem tollen "UseCase" versucht hab, zu zeigen, oder nicht. Tatsache ist, dass man mit Scripts ziemlich effektiv verhindern kann, dass hinterher 5000 Leute ankommen und fragen "Kannst du XXXX einbauen?!", weil es jeder selber machen *könnte*. Ob er es auch kann ist die andere Frage, aber wir haben hier passionierte Streckenbauer, passionierte Führerstandsbauer, passionierte Fahrzeugbauer, teilweise auch alles zusammen, wieso sollte es also nicht auch passionierte Stellwerksbauern geben?

Nachtrag für Arthur:
Der Punkt ist die spätere Erweiterbarkeit. Wenn man jetzt hergeht und sagt "Och, wir machen ein Gleisbild mit fünf Knöpfen und wenn man zwei drückt machts Plop und wir haben eine Fahrstraße" mag dir das genügen. Dann kommt ein Regionaut an und fragt, wieso man keine Durchsagen auf dem Bahnsteig machen kann. Und überhaupt, was das soll, der dortige Bahnhof ist eigentlich mechanisch und geblockt wird hier per Buschtrommel und überhaupt. Sowas muss man zuvorkommen. Wenn man weiß, was das Programm später alles können sollen könnte, dann kann man sein Grundgerüst zusammenschrauben und meinetwegen mit den wichtigsten Features anfangen und den Leuten schonmal ein kleines 2 Tasten = Fahrstraße-Stellsi in die Hand drücken, während die Kinkerlitzchen noch dazukommen, aber relativ einfach einzubauen sind, da von vorn herein in der Architektur berücksichtigt.

Das ist, wie wenn du dir ein zweistöckiges Haus baust und im oberen Stock das Badezimmer weglässt. Aus finanziellen Gründen gibts auch keine Wasserleitungen nach oben. Dann stellst du fest: Immer Treppe runterlatschen, um aufs Klo zu gehen ist doof. Also gehst du zu nem Architekten und sagst: "Werter Herr, ich möchte bitteschön ein Badezimmer im oberen Stockwerk". Sagt der "Aha, soso. Dann müssen wir hier drei Wände rausschmeißen, da die Decke durchlöchern, das Rohr da muss dann quer durch Ihre Küche, dann ziehn wir hier wieder ne Mauer durch und da kommt die Einrichtung hin. Damit das Ganze nicht einstürzt kommen da noch drei Säulen hin und schon haben Sie Ihr Badezimmer im oberen Stockwerk. Bauzeit: Etwa drei Jahre."
Verstehst du jetzt?

[Roland Ziegler]

@Andi: Selbst wenn es sich auf unterster Ebene einem Simulator so verhält, wie Du das beschreibst - und wie Zusi das eben für sich auch realisiert - dann kommt die Herausforderung erst auf den Ebenen darüber. Und um diese höhere Ebenen dreht sich eigentlich die Diskussion. Denn Zusi gibt es ja schon. Software wird übrigens nicht dadurch einfacher, dass man kritische Teile ausblendet. Das gemeine an einem Ansatz mit UML kann sein, dass die tatsächliche Komplexität recht früh deutlich wird.

Ob das Zusi-Stellwerk ein Baukasten wird oder ein fertiges Stellwerk mit Moduleigenschaften, steht noch dahin. Reale und nutzbare Baukästen sind allerdings in der Regel deutlich komplizierter als fertige Lösungen.

Generik, vermutlich das, was Du unter "Skript" verstehst, kann man mit verschiedenen Technologien umsetzen. Eine davon ist MDG (Model Driven Generation), und die hängt extrem nah an UML dran. Nur wer soll denn die Templates dafür bauen?

Ich würde erst mal einen konventionellen Ansatz versuchen.

Allerdings, und das bleibt die Voraussetzung auch für meine Mitarbeit, man möge sich auf einen Katalog von Anwenderanforderungen einigen. Solange "drei" Leute hier "fünf" verschiedene Richtungen verfolgen, wird es garantiert nichts.

[Christian Gründler]

Liebe Leute,

ohne daß ich die allgemeine Begeisterung abwerten will, muß ich jetz doch mal ganz provokativ fragen: macht es wirklich Sinn, den realistischsten Fahrsimulator der Welt (wenn wir die professionelle Ausrüstung von Bahnbetreibern mal außen vor lassen) mit dem realistischsten Stellwerkssimulator der Welt (Einschränkung wie oben) zusammenzufassen? Dieses auch unter dem Gesichtspunkt, daß man sowieso bloß entweder fahren oder stellwerken kann; eine richtig komplexe Stellwerkssimulation setzt ein Netzwerk mit mehreren Teilnehmern voraus, das i.A. nicht gegeben ist.

Mir persönlich würde eine Art EStW völlig genügen. Man könnte in diese Ansicht wechseln, wie man in einen anderen Zug wechselt, und statt fahren stellt man dann die Fahrstraßen. Dies hätte drei Vorteile:

a) Das Verfahren ist ziemlich nahe an der Art dran, wie Zusi sowieso funktioniert. Es geht im wesentlichen also um eine grafische Oberfläche mit Bedienmöglichkeit und nicht um eine eigene Logik.

b) Ein solches Stellwerk kann man auch mal eben nebenbei bedienen; z.B. um festzustellen, warum ein Zug dauern blockiert wird, und um diesem Zug "Vorfahrt" zu verschaffen.

c) Ich persönlich habe eigentlich keine Lust, mich mit Vorblocken, Rückblocken, Erlaubnisfeldern, Farbscheiben, etc. zu befassen (so interessant das Thema sicherlich ist). Es genügt mir, wenn ich in etwa weiß, wie das funktioniert. Vermutlich geht das vielen anderen Zusianern ähnlich.

Im Grunde geht es hier um die gleiche Frage wie an anderer Stelle im Forum bei den BrH ("Hauptschalter einer E-Lok ... "). Dort hat Michael Poschmann geschrieben:

Dann sollte man es bei einem gesunden Kompromiß belassen, um (...) die Simulation auch ohne mehrjährige Vollzeit-Tf-Ausbildung bedienen zu können.

Ich sehe das genauso und plädiere generell für einen gewissen Abstraktionsgrad, um die Sache nicht allzu kompliziert werden zu lassen.

M.f.G. Christian

[Daniel Rüscher aka Merlin]

Hallo Christian,

Ich zitiere einfach mal Andi:

Das ist, wie wenn du dir ein zweistöckiges Haus baust und im oberen Stock das Badezimmer weglässt. Aus finanziellen Gründen gibts auch keine Wasserleitungen nach oben. Dann stellst du fest: Immer Treppe runterlatschen, um aufs Klo zu gehen ist doof. Also gehst du zu nem Architekten und sagst: "Werter Herr, ich möchte bitteschön ein Badezimmer im oberen Stockwerk". Sagt der "Aha, soso. Dann müssen wir hier drei Wände rausschmeißen, da die Decke durchlöchern, das Rohr da muss dann quer durch Ihre Küche, dann ziehn wir hier wieder ne Mauer durch und da kommt die Einrichtung hin. Damit das Ganze nicht einstürzt kommen da noch drei Säulen hin und schon haben Sie Ihr Badezimmer im oberen Stockwerk. Bauzeit: Etwa drei Jahre."

Und genau aus diesem Grund befassen wir uns eben nicht mit einem einfachen Ansatz. Vereinfachen lässt sich hinterher ohne Probleme. Es ist eben wesentlich leichter die Wasserrohre hinterher rauszurupfen als sie nachträglich einzubauen. Vom Frustfaktor, dass man den Gleichen Mist den man schonmal ersonnen hat jetz umschmeißen muss, und komplett von vorne anfangen muss, mal ganz abgesehen.

[Roland Ziegler]

Bevor wir hier auf einen Stand der Diskussion zurückfallen, der schon vor 4 oder 6 Wochen erreicht war, können wir es konkreter und konstruktiver halten?

Im UML-Modell gibt es diesen Stichwortkatalog von Anwenderanforderungen, nummeriert und vorsortiert.

Was ist nun nach Eurer individuellen Meinung nach daran zu ändern? Was fehlt, oder was ist zuviel? Welche Funktionalität wollt Ihr zusätzlich? Welche wollt Ihr nicht? Welches Schlagwort ist nicht aussagekräftig genug? Was fehlt insgesamt hier noch (z.B. Anforderungen an die Benutzeroberfläche)?

Wenn Ihr Euch damit nicht beschäftigen wollt und stattdessen eine erneute Grundsatzdebatte gewünscht wird, dann auch dieses. Aber für die Zeit werde ich mich ausklinken.

[Andreas Karg]

Falls jemand tatsächlich die Reset-Taste drückt, dann sollten aber auch alle Züge im Bahnhof analog dem bisherigen Verhalten des Autopilots schlagartig am Signal anhalten, egal, ob der Zug von einem Menschen oder vom Autopiloten kontrolliert wird. Man sollte ja nicht unbedingt dem Lokführer eine reinwürgen, wenn der Fahrdienstleiter zu deppert ist, seinen Bahnhof richtig zu bedienen. Anders natürlich, wenn der Fahrdienstleiter irgendwelche Signale auf die konventionelle Tour (HaGT) zurückstellt. Aber für den Großen Roten Knopf, den es ja in der Realität so nicht gibt, sollte man dann schon Kulanz gegenüber den Lokführern walten lassen.

[Christopher Spies]

Im UML-Modell gibt es diesen Stichwortkatalog von Anwenderanforderungen, nummeriert und vorsortiert.

Was ist nun nach Eurer individuellen Meinung nach daran zu ändern?

Das Modell finde ich gut!
Schön wäre es jedoch, wenn (beispielsweise im "Modell Glossary") zu jedem Begriff noch eine kurze Erläuterung stünde, damit wirklich jeder weiß, wovon die Rede ist.

Strategische Bemerkung zur Zusi-Stellwerk-Systemarchitektur: Ein unserer Anwenderanforderungen heißt ja : Internationalisierbarkeit. Je weiter wir jetzt hier einsteigen, um so deutlicher scheint mir, dass eine solche Internationalisierung auf Klassenebene sehr komplex werden würde und wohl besser auf Modul-Ebene unterzubringen ist.

Dies bitte näher erläutern! Was ist mit "Internationalisierung auf Klassenebene" gemeint und was mit "Internationalisierung auf Modulebene"?

Wenn [...] eine erneute Grundsatzdebatte gewünscht wird, dann auch dieses. Aber für die Zeit werde ich mich ausklinken.

Ich möchte eigentlich keine neue Grundsatzdebatte starten, aber dennoch folgendes zu bedenken geben:

Diverse meiner Vorposter haben schon auf Besonderheiten verschiedener Stellwerksbauarten und Bahnverwaltungen aufmerksam gemacht. Andererseits hat Lutz Troitzsch im Wünsche-Thread ja bereits festgestellt, dass sich an der eigentlichen Stellwerkslogik bei den deutschen Eisenbahnen seit dem mechanischen Einheitsstellwerk nichts mehr verändert hat.

Wir sollten vermeiden, die Stellwerkslogik speziell auf deutsche, österreichische oder sonstige landes- oder EVU-spezifische Konzepte auszurichten. Es müssen gemeinsame Charakteristika der verschiedensten Stellwerksbauformen herausgearbeitet werden!
Wenn sich später sonst herausstellt, dass $EXOTISCHESEVU oder auch $WENIGEREXOTISCHESEVU eine gänzlich andere Stellwerks-Philosophie verfolgt, wird es dann keine Möglichkeit geben, ein entsprechendes Stellwerk nachzuempfinden.
"Internationalisierung auf Modulebene" kann nicht heissen, ein deutsches Stellwerk zu programmieren, dann ein britisches, dann...! Es kann nur darum gehen, schlimmstenfalls die Benutzeroberfläche neu erstellen zu müssen (als eine Art "Plugin").

Generik, vermutlich das, was Du unter "Skript" verstehst, kann man mit verschiedenen Technologien umsetzen.

Ich hatte AndiK eher so verstanden, dass er eher so etwas wie Makros meinte -- also eine Zusammenfassung primitiver Operationen zu komplexeren Operationen, die dann mit einer einzigen Nutzeraktion gestartet werden können.

In oben angesprochener Internationalisierung sehe ich den Hauptvorteil von Andis Idee. Gelänge es, eine möglichst abstrakte Stellwerks-Struktur zu entwickeln, die nur die grundlegendsten und primitivsten Operationen enthält, dann könnte man daraus mit Hilfe von "Skripten" (nennen wir sie Makros) komplexere Operationen zusammensetzen. Auch Nutzer ohne jede Programmierkenntnis könnten sich so ihre eigenen Stellwerke zusammenbasteln und sie mit "selbstgemalter" Oberfläche ausstatten. Jedenfalls habe ich Andis Idee so verstanden.

- Christopher

P.S.: Uff! Dieser Beitrag war eine schwere Geburt -- habe über 45 Minuten gebraucht!

Edit: doppeltes 'eher' entfernt

[Michael_Poschmann]

@ Roland: Etwas für Dich *aufwandsarmes*.
Mir geht es zum einen darum , den Kram ausdrucken und nebeneinanderlegen zu können (bin ein Mensch des Papiers), und zum anderen möchte ich nicht ständig online sein (Modemnutzer).

Michael

[Andreas Karg]

Danke, Christopher! Ich glaube, du hast meinen Gedankengang recht treffend wiedergegeben. Inwieweit sich dann die Nutzer ohne Programmierkenntnis ihre Sachen zusammenbauen könnten müsste man sehen - Stellwerke aus bereits existierenden Makros (Danke!) zusammenzusetzen sollte jeder hinkriegen. Neue Makros hinzuzufügen wäre wohl deutlich anspruchsvoller, aber wenn man erstmal einen gewissen Grundstock angelegt hat müsste das für viele Fälle ja genügen.
Der heutige Signalumfang bei Zusi ist ja auch nicht von heute auf gestern entstanden...

[Carsten Hölscher]

ich sehe 2 Ziele:

1.) eine allgemeingültiges Gerüst auf unterster Ebene. Dieses darf nicht so speziell sein, daß irgendwelche bauart-/länderspezifischen Dinge unmöglich gemacht werden.
Das wäre also z.B. die Kommunikation mit Zusi und gewisse Grundlagen, die für jede Art von Stw geeignet sind.

2.) Eine Ebene höher ein Grundgerüst eines Stw deutscher Prägung, also quasi ein Ur-Stw, aus dem sich mech, el.mech., ESTW uns. ableiten lassen.

Carsten

[Carsten Hölscher]

@Andi: noch vergessen: Deine Scriptgeschichte wäre eher 1.)
Als Ziel der ganzen Aktion sehe ich aber schon auch 2.)

Carsten

[Max Senft]

Hi @ll!

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.

Bye
Max Senft

[Lutz Troitzsch]

Hallo

ne max das soll es ja auch nicht man muß die ganzen Daten zusammentragen,das setzt aber vorraus das die stellwerkstechnik des jeweiligen Landes genau bekannt ist ich meine damit das Innenleben der Stellwerke für Deutschland Österreich dürfte das kein Problem sein,aber wenn ich an unsere Ungarischen Freunde denke wer hat dort den Durchblick?
Für England wird sich sicher auch jemand finden.
Mit schätzwerten möchte ich in so einem Fall aber auch nict arbeiten.
Na gut für die Russischen Stellwerke (EZMG) geb ich mich auch noch her .

Mfg
Lutz

[Andreas Karg]

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.

[Daniel Rüscher aka Merlin]

Vieleicht sollten wir erstmal die verschiedenen Stellwerke anschauen wo die Gemeinsamkeiten bestehen.

Ich bin auf Folgende Objekte gekommen die JEDES Stellwerk dieser Welt hat:

Weiche
Signal
Gleis
Bahnübergang

Jedes Objekt hat recht scharf eingrenzbare Eigenschaften und Methoden.
Vieleicht wären daher taktisch Überlegungen, die Objekte als Grundlage (evtl. für das Grundgerüst) zu nehmen eine Überlegung wert.

[Lutz Troitzsch]

noch ergänzend diverse Sicherungsmechanismen für gesicherte Fahrten im Bahnhof oder Stellwerksbezirk
und weiterhin Sicherungsmechanismen für gesicherte Zugfahrten auf der Strecke.
Auch diese ließen sich bei Bedarf scharf abgrenzen.
Mit den Begriffen Frei,Besetzt,Angewählt,und Storung.

bei BÜ habe ich vorbehalt,weil in der heutigen Zeit die BÜ s meist ersetzt werden,durch Unterführung oder Brücke.

Mfg

Lutz

[(Ar-) T-Rex]

Ich bin auf Folgende Objekte gekommen die JEDES Stellwerk dieser Welt hat:

Weiche
Signal
Gleis
Bahnübergang

Jedes Objekt hat recht scharf eingrenzbare Eigenschaften und Methoden.
Vieleicht wären daher taktisch Überlegungen, die Objekte als Grundlage (evtl. für das Grundgerüst) zu nehmen eine Überlegung wert.

Also das ist mir zu schwammig.

Ein Stellwerk BEDIENT Weichen, Signale und dergleichen, aber es HAT sie nicht; schon gar nicht hat es Gleise. Ein Stellwerk hat Bedienelemente, Fahrtausschlüsse, Abhängigkeiten, Sperren, Befehlsempfangs- und -abgabemöglichkeiten für zwangsweise durchzuführende Vorgänge und dergleichen sowie Rückmelde- und Informationselemente; all dies gemäß den grundlegenden Vorschriften über das Fahren im Raumabstand und den jeweiligen Verschlußplänen.

Auch der Begriff "Signal" ist zu allgemein gefaßt; man muß schon (zumindest) zwischen Signalen für Zugfahrten, solchen für Verschubfahrten und Flankenschutzsignalen unterscheiden; außerdem gibt es Signale, die für alle Fahrten gelten. Jedenfalls sind nur Signale mit zumindest zwei Begriffen bedienbar; andere können aber auch wichtig sein (zB der erwähnte Flankenschutz, für Geschwindigkeitsanordnungen o.ä.).

Arthur

[Roland Ziegler]

Was mir aus Gründen der Flexibiltät und Erweiterbarkeit für die Systemarchitektur (der Software) wichtig erscheint, ist die "Trennung von Form und Funktion": Wir werden eine graphische Benutzeroberfläche haben wollen, aber diese sollte sich auf das Wesen eines "dummen" Clients beschränken. Wenn es dort ein Bedienelement "Blockfeld" gibt, und dieses Bedienelement bestimmte Bedienfunktionen zulässt, dann werden diese Bedienfunktionen unmittelbar an ein Objekt der Stellwerkslogik weitergereicht. Diese prüft, ob die Bedienfunktion durchführbar ist und liefert entsprechende Rückmeldung.

1. 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"
2. Die untere Ebene bildet eine gekapselte Schnittstelle zum Simulator (Zusi3). Mir schwebt hier eine konsequente OO-Ausprägung vor, was aufgrund technischer Randbedingungen dazu führen kann, dass wesentliche Teile dieser OO-Ausprägung auf Seiten des Stellwerks liegen werden. Diese untere Schnittstelle bildet die Ankopplung für alle Stellwerke, gleich welcher Ausprägung und Bauform.
   
   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".
3. Die mittlere Ebene bildet die Stellwerkslogik, ohne Bedienoberfläche. Hier würde ich durchaus pragmatisch vorgehen, und auf dem Klavier der klassischen OO-Möglichkeiten klimpern wollen. Für die Stellwerksbauformen werden die typischen Elemente modelliert - Arthur hat solche aufgezählt - und als Basisklassen ausgebildet. Die Logik würde ich zunächst auf Typebene hart verdrahten, wohlgemerkt auf Typebene, nicht auf Objektebene, denn natürlich müssen unsere Stellwerke frei konfigurierbar sein.
   
   Unsere Use-Cases werden hier die Vorgaben liefern. Die tatsächliche Ausbildung der Klassen, der Methoden, sich anbietende Abstraktion, dies wird ein iterativ inkrementeller Prozess werden.
   
   Es wird vermutlich bestimmte Ausprägungen geben, Unterschiede im Detail. Für so etwas ist gewöhnliche Vererbung im OO-Modell häufig gut geeignet, ein Tummelplatz für Polymorphie. Die Basisklassen erhalten öffentliche Bedienschnittstellen, d.h. deren Objekte können von einer Ebene darüber - also der Bedienebene - direkt angesprochen werden. Bei Wahl einer entsprechenden Implementationsplattform ist solche direkte Kommunikation auch ohne Probleme umzusetzen.
   
   Ich sehe jedoch gewisse fundamentale Unterschiede z.B. zwischen einem deutschen Streckenblock und einem englischen Tokensystem (eingleisige Strecke). Die Funktionsweise ist eine signifikant andere. Deswegen wird hier mit Vererbung/Polymorphie wohl kein Blumentopf zu gewinnen sein.
   
   Alternativ mögen sich geniale Cracks auf dieser mittleren Ebene gerne auch an der Schöpfung der eierlegende Wollmichsau versuchen.
4. Die obere Ebene ist die zu Anfangs erwähnte Benutzeroberfläche, ein "dummer" Client, natürlich ebenfalls frei konfigurierbar, und vermutlich ein echter Baukasten.
5. Parallel zum ganzen gibt es ein Modul, was ich mal mit Verwaltung bezeichnet habe. Dieses Modul klammert den Rest. Es wird möglicherweise auch bei der Initialisierung der Konfiguration eine Rolle spielen, sofern das nicht in ein Framework ausgelagert wird.
6. Außerdem angedeutet in diesem Paket-Diagramm ist der Aspekt einer direkten Visualisierung. Es scheinen mir Teile der anzuzeigenden Daten ohne die Stellwerkslogik auszukommen. Für den globalen Datenfluss aber sind andere Diagrammformen besser geeignet.

(Ich vermute mal, die im Modell skizzierte vertikale Gliederung wird sich nicht wesentlich von der von Daniel Rüscher mal angedachten unterscheiden.)