Stellwerk-API Zwischenbericht

Hier geht es um die Entwicklung eines zukünftigen Stellwerks mit Zusi-Anschluss.
Nachricht
Autor
Benutzeravatar
Roland Ziegler
Beiträge: 5508
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

Stellwerk-API Zwischenbericht

#1 Beitrag von Roland Ziegler »

Carsten hatte mich gebeten, mal einen Zwischenstand zum Stellwerk-API (Application Programming Interface) zu berichten. Ich bin da ein wenig zurückhaltend, weil vieles vom Notwendigen noch nicht implementiert ist, und manches davon, obwohl prinzipiell erforscht und für lauffähig befunden, später noch bei der Umsetzung Überraschungen birgt. Selbst, wenn im folgenden durchgehend der Indikativ benutzt wird, sind es zum Teil noch Anwenderanforderungen, die entweder der Umsetzung weiterhin harren, oder bisher nur rudimentär getestet sind.

Wer die Berichterstattung hier verfolgt hat, wird feststellen, dass das meiste dessen, was im folgenden aufgeführt wird, in diversen Beiträgen in diesem Unterforum bereits einmal beschrieben worden ist.

Das Stellwerk-API dient der Anbindung einer externen Stellwerk-Software an Zusi3.

Das API folgt einem objektorientierten typsicheren Konzept. Es präsentiert sich als Klassenbibliothek.

Stellwerke über dieses API werden als sogenannte „verteilte Systeme“ konzipiert; es sind Client/Server-Lösungen. Der Server-Teil wird fest in Zusi3 integriert, der Client-Teil in eine zu erstellende Stellwerks-Anwendung. An einer Zusi3-Simulator-Instanz können mehr als ein Stellwerk gleichzeitig betrieben werden. Die Lösung ist netzwerkfähig. Ganz tief unten wird das TCP/IP-Protokoll benutzt.

Stellwerke werden zur Laufzeit an Zusi3 angebunden. Sie müssen nicht von vorneherein Bestandteil einer Strecke sein, sondern können nachträglich hinzugefügt werden. Ein aktives Stellwerk übernimmt für seinen Stellbezirk die Aufgaben des Zusi3-internen Stellwerks.

Das API umfasst im Wesentlichen folgende Funktionalität:
  • Anmelden und Abmelden einer Stellwerks-Sitzung = Aktivieren/Deaktivieren eines Stellwerks. (Die laufende Überwachung der Verbindung wird durch die Client- und Server-Klassen automatisch erledigt.)
  • Abfrage des Anfangszustands von Außenanlagen zum Aktivierungszeitpunkt.
  • Stellen der Außenanlagen, im Wesentlichen Weichen und Signale, mit integrierter synchroner Rückmeldung.
  • Asynchrone Meldungen von Zusi3 an das Stellwerk über besetzte Gleisfreimeldeabschnitte und ausgelöste Gleiskontakte.
  • Austausch von Zustandsänderungen der Blockelektrik, bidirektional, asynchron.
  • Rückmeldung von eingestellten Fahrstraßen (Zugstraßen) an Zusi3, für Übernahme durch Zusi3 nach Sitzungsende.
  • Austausch von Zug- und sonstigen Kommunikationsmeldungen, teils formal, teils Freitext, auch als Chat-Funktion zu gebrauchen.
Die Zuordnung der stellwerksrelevanten Zusi3-Objekte zu deren Gegenpart im Stellwerk erfolgt über Schlüssel, sogenannte Referenz-IDs. Diese Schlüssel sind konstante ein- oder mehrstufige numerische Werte, und fester Bestandteil der Zusi3-Strecke.

Keine Aufgabe des API und seiner Klassen ist die gesamte Stellwerkslogik. Die Schnittstelle ist in dieser Hinsicht „dumm“. Sie führt stupide all das aus, was die Anwendung vorgibt.


Die Klassenbibliothek des API besteht aus einer oder mehreren .Net-Assemblies (DLLs). Die Objekt-Kommunikation basiert auf .Net-Remoting – für den Anwender fast vollständig gekapselt.
  • Der Zugriff erfolgt typsicher über Objekte mittels des Aufrufs von Methoden oder Eigenschaften (Properties).
  • Der wesentliche Ansprechpartner des Stellwerks ist das Sitzungsobjekt, das je Anmeldung individuell erzeugt wird. Über das Sitzungsobjekt werden allgemeine Verwaltungsaufgaben sowie das Meldungswesen abgehandelt.
  • Bestimmte Typen von Außenanlagen verfügen über eigene (statische) Objekte.

    Ein Signal wird beispielsweise so geschaltet:

    Code: Alles auswählen

    meineStellwerksSitzung.Signal[4711] = 2;
    (4711 stehe für die Ref-ID, und 2 sei das zu schaltende Signalbild, z.B. Hp2)
  • Asynchrone Meldungen werden über Ereignisse empfangen (Events). Zu deren Verarbeitung ist ein Client immer auch gleichzeitig Server; er verfügt dazu über ein Callback-Objekt. Der notwendige Unterbau dafür wird durch die Client-Klassen in der Bibliothek bereitgestellt.
  • Fehlgeschlagene Aufrufe oder Kommunikationsstörungen werden über Ausnahmen (Exceptions) signalisiert.
  • Das API unterstützt Single-Thread und Multi-Thread-Anwendungen, die Schnittstelle selbst ist immer multi-threaded.

Benutzeravatar
Carsten Hölscher
Administrator
Beiträge: 33384
Registriert: 04.07.2002 00:14:42
Wohnort: Braunschweig
Kontaktdaten:

#2 Beitrag von Carsten Hölscher »

danke erstmal.

Um vielleicht noch den Hintergrund meiner Anregung etwa zu erläutern. Es gab ja mal vor einige Zeit eine Initiative zum Bau eines Stwellwerks als Gruppenarbeit (im Stw-Forum nachzulesen). Das Thema war zunächst am Thema Schnittstelle hängengeblieben und von Roland (und mir) verkündet worden, wir werden da zunächst die Grundlagen schaffen und als eine Art Grundgerüst zur Verfügung stellen. Wenn das fertig ist, kann man Sims für verschiedene Stw-Bauarten oben drauf setzen.
Roland macht im Moment also hinsichtlich Stw zwei Jobs:
1.) Programmierung einer allg. Schnittstelle
2.) Als ersten Anwendungsfall/Testobjekt ein mech. Stw.

Da ich nicht sicher war, ob das allg. klargeworden war, hatte ich dieses Thema bei Roland angeregt.
Also erst wen 1.) fertig ist, hat es Sinn, das seinerzeit diskutierte Gruppenprojekt in Angriff zu nehmen. Dafür braucht man sich dann um viele grundlegende Dinge keine Gedanken mehr zu machen.

Carsten

Plokky
Beiträge: 184
Registriert: 12.09.2005 12:48:07
Aktuelle Projekte: Simulationssoftware
Wohnort: Lucan, Canada
Kontaktdaten:

"Interlocking" ebene bei einer Schnittstelle

#3 Beitrag von Plokky »

Mal nachgedacht über euer Stellwerkschnittstelle:

Es kann technisch sehr schwierig sein, die "Interlocking-Ebene" (Fahrstrassenfestlegung und -freigabe) aus Zusi raus zu holen. Wenn eine TCP/IP Verbindung über das Internet laufen soll, wird das kritisch.

Also m.E. sollte die Interlocking-Ebene in Zusi sein. Die Stellwerksschnittstelle leitet dann nur "Nachrichten" über an die Stellwerksdarstellung:
- Gleisfreimeldung
- Fahrstrassenfestlegung
- Signalfahrtstellung
- Fahrtrichtungs-Erlaubnis

Die Stellwerksebene übergibt nur "Nachrichten" bezüglich:
- Start-Ziel Eingabe für eine Fahrstrasse
- Weichenstellauftrag
usw.

Die Zusi Anwendung ist aber verantwortlich für die "Sicherheit" im Eisenbahnbetrieb.

Wenn jetzt plötzlich eine Stellwerksbediener "wegfällt" über das Internet, übernimmt einfach Zusi wieder die Fahrstrasseneinstellung.

Und damit ist das Stellwerk SEHR EINFACH zu erstellen! Die Schnittstelle todessicher. Und Zusi braucht kaum eine änderung!.

Ist das was?
grüsse,

Richard Plokhaar

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 »

Nene, die Sicherungsebene soll schon ins Stellwerk wandern.
Aber warum solls per Internet unsicher werden?
Und das mit den Änderungen in Zusi ist eh wurscht, da in erster Linie für Zusi3 Gedacht
How to waste bits in a My SQL Database?

Like this.....

Benutzeravatar
Carsten Hölscher
Administrator
Beiträge: 33384
Registriert: 04.07.2002 00:14:42
Wohnort: Braunschweig
Kontaktdaten:

#5 Beitrag von Carsten Hölscher »

es wird beides gehen, also die einfache Lösung (das interne Zusi-Stw wird nur von außen bedient) oder auch die große Lösung, Zusi stellt nur noch das um, was das Stw sagt, egal was es ist.

Carsten

Plokky
Beiträge: 184
Registriert: 12.09.2005 12:48:07
Aktuelle Projekte: Simulationssoftware
Wohnort: Lucan, Canada
Kontaktdaten:

stellwerksicherheit

#6 Beitrag von Plokky »

Daniel Rüscher aka Merlin hat geschrieben:Nene, die Sicherungsebene soll schon ins Stellwerk wandern.
Aber warum solls per Internet unsicher werden?
Und das mit den Änderungen in Zusi ist eh wurscht, da in erster Linie für Zusi3 Gedacht
Unsicher "signaltechnisch" gesehen, weil ein Stellwerk - Zusi Verbindung über TCP/IP plötzlich weg sein kann. Stromausfall, schlechte verbindung, packages die verloren gehen, Katze nagt am schnürchen, sohnemann zieht stecker raus. Und wie in Wirklichkeit würde es dann heikel werden wenn die Interlockingebene irgendwo anders ist, als dort wo die Züge fahren.
In der Realität wird mit der Fernbedienung die SICHERHEIT (sag interlocking) an Ort und Stelle durchgeführt. Die Fernbedienungseinheit zeigt nur an.

In wieweit würdet Ihr denn gerne Zusi-spieler und Stellwerke zusammensetzen? wäre ein interessante option eigentllich.
ähnlich wie http://www.vatsim.net?
In genau solch ein fall, brauchst du ein server auf der welt, der die Interlocking regelt. jetzt wird's interessant :-)
grüsse,

Richard Plokhaar

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

#7 Beitrag von Roland Ziegler »

Die von der Schnittstelle implementierte .Net-Remoting-Verbindung, die einen TCP-Socket verwendet, ist im Rahmen der für die Simulation geltenden Ansprüche als übertragungstechnisch sicher zu betrachten. Ein TCP-Socket ist bekanntlich verbindungsorientiert, und verfügt über eine eigene OSI2-Sicherungsschicht.

Auf OSI7 ist die Schnittstelle synchron ausgebildet. Sie ist damit auf der Ebene jedes einzelnen Funktionsaufrufes mit einer automatischen Rückmeldung verbunden. Das gilt auch für "void"-Funktionen oder für Events, die von Anwendungsentwickler vielleicht als asynchron/unidirektional betrachtet werden, es aber nicht sind.

Bliebe der Fall des Verbindungsabbruchs. Dieser wird auf Server- und Client-Ebene erkannt, über unmittelbare Kommunikationsfehler oder über Timeout. Hilfsmittel dazu ist ein eigenes Pinging auf OSI7-Ebene. .Net-Remoting bietet zwar selbst Mechanismen; diese schienen mir aber für unserer Aufgabenstellung nicht zu passen. Und auf Default TCP-Pinging mochte ich nicht zurückgreifen.

Der Server benachrichtigt bei Verbindungsausfall seinen Arbiter, also Zusi, und der Client den seinen, das Stellwerk.

Das Stellwerk stellt die Außenanlagen, z.B. Weichen und Signale, unter Verantwortungshoheit des Stellwerks. Zusi ist, wie von Carsten betont, bei aktivem externen Stellwerk nur ausführendes Organ. Macht das Stellwerk Unsinn, z.B. aufgrund interner Logik-Fehler, macht auch Zusi Unsinn. This behavior is by design.

Zusi verfügt verfügt für den autonomen Betrieb über eigene Stellwerkslogik. Die von Zusi intern verwendete Fahrstraßensicherung ist etwas abstrakter als die tatsächliche Ausprägung in einer bestimmten Stellwerksbauform.

Sichtbar von dieser abstrakteren Ebene ist eine allgemeine Form der Fahrstraße. Das externe Stellwerk meldet Änderungen bei Fahrstraßenzuständen ebenfalls an Zusi, an dessen sichtbare Fahrstraßen.

Strecken- und Bahnhofsblock oder Erlaubniswechsel habe ich bislang nicht erwähnt. Hier gilt eine ähnliche Abbildungsweise wie bei Fahrstraßen, mit der Ergänzung, dass die Gegenstelle Zusi sein kann, oder auch ein weiteres Stellwerk. Der Partner ist hier ein Peer, der entweder durch Zusi emuliert oder durch ein weiteres angeschlossenes Stellwerk implementiert wird. Bei aktivem externen Peer wird der Stw-Server die Weiterleitung der Befehle und Meldungen selbst übernehmen. Zustandsänderungen bei durch Strecken- oder Bahnhofsblock ausgebildeten Fahrstraßen werden zusätzlich immer auch an Zusi gemeldet. (Der Stw-Server hat Dispatcher/Distributor-Funktionalität im IT-Sinn.)

Damit sind Zusi zu jedem Zeitpunkt alle Komponentenzustände bekannt. Zusi kann also jederzeit selbst wieder übernehmen.

Spontifixus
Beiträge: 4
Registriert: 03.10.2006 11:59:13

#8 Beitrag von Spontifixus »

Moin Carsten,

Nach einer Fragestellung im einem Thread im TSSF-Forum hier mal meine Meinung zum Thema "Stellwerksanbindung an den ZuSi":

Den Gedanken mit einer Stellwerkssoftware einen Simulator zu Steuern ist mir bei meiner Tätigkeit als Admin im (mittlerweile stillgelegten) Onlineflug-Netzwerk FLIGHTPROJECT international (FPI) auch schon gekommen. Damals scheiterte das daran, dass der MSTS über keine Multiplayer-Schnittstelle verfügt.

Zum Thema "Stellwerkseinbindung im ZuSi3" stellt sich mir da die Frage: Gibt es eine solche Multiplayer-Schnittstelle? Es wäre für mich als FDL langweilig, wenn ich mir zum einen meine Fahrstrasse selber stellen müsste (denn entweder spiele ich einen Lokführer oder einen FDL aber nicht beides gleichzeitig) oder wenn ich mich mit nur einem "Freund" verbinden kann und daher nur einen einzigen Zug sehe.

Die Software die ich im Augenblick (basierend auf dem .NET 2.0 Framework) entwickle hat zunächst einen ganz anderen Hintergrund: Sie will ein kurzweiliges Spiel für zwischendurch werden. Der Benutzer soll damit ohne große Einarbeitungszeit mit umgehen können. Die Darstellung des Gleisbildes soll einigermaßen realitätsgetreu werden, die Bedienung allerdings stark vereinfacht. Will sagen: In der von mir entwickelten Software wirds nur zwei Befehlegeben: "Fahrstrasse stellen (Syntax: Start.Ziel)" und "Fahrstrasse auflösen (Syntax FHA,Ziel bzw. FA,Ziel)". Rudimentäre Sicherheitsmechanismen beim Fahrstrassenstellen wie etwa Flankenschutzweichen sollen ebenfalls umgesetzt werden.

Eine multiplayertaugliche Stellwerkssimulation muss aber noch eine ganze Menge mehr können. So müssen z.B. Hand-Offs zwischen einzelnen FDL möglich sein, es muss ein generelles, systemweites Zugmeldesystem geben, und die Stellwerkssoftware muss ZuSi-Strecken lesen und in brauchbare Gleispläne umrechnen können.

Dann stellt sich die Frage ob in der ZuSi-Community genug Potential für ein "Online-Netzwerk" vorhanden ist. Um hier den Benutzern einigermaßen Spaß zu bringen wäre meine Idee, dass wer in diesem Netzwerk fahren will sich einen Zug aus einem in der Streckendefinition vorgegebenen Fahrplan aussucht und diesen steuert, während alle anderen Züge dieses Fahrplan vom ZuSi simuliert werden. Der FDL wäre dann für alle Züge dieses Fahrplans verantwortlich.

Soweit meine Meinung dazu.

Viele Grüße,
Markus :)

Benutzeravatar
Carsten Hölscher
Administrator
Beiträge: 33384
Registriert: 04.07.2002 00:14:42
Wohnort: Braunschweig
Kontaktdaten:

#9 Beitrag von Carsten Hölscher »

Also Zusi kann automatisch beliebig viele Züge fahren lassen, so daß auch im Ein-Mann-Betrieb keine Langeweile aufkommen sollte Schnittstellen zu anderen Stw wären aber nötig, wobei Zusi sich da um die wichtigsten Dnige selbst kümmern wird - der Aufwand also wohl für die Stw-Programmierung überschaubar wäre.

Automatische Generierung von Stellpulten würde ich nicht anstreben, ein Editor sollte bessere Ergebnisse liefern. Das brauchst Du aber auch ohne Zusi-Anbindung.

Carsten

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

#10 Beitrag von Christopher Spies »

Hallo,
Carsten Hölscher hat geschrieben:Automatische Generierung von Stellpulten würde ich nicht anstreben
Warum nicht? Die Generierung eines Stellpults ist ja eine recht geradlinige* Angelegenheit. In der Streckendatei sind ja alle befahrbaren Gleiselemente, alle Signale, Weichen usw. enthalten. Daraus kann man ein Stellwerk konstruieren.
Im Prinzip braucht man dazu sogar weder die Fahrstraszendefinition noch die Verschlusstafel, da sich aus der Strecke selbst ergibt, welche Fahrstraszen möglich sind und welche sich gegenseitig ausschlieszen.
Carsten Hölscher hat geschrieben:ein Editor sollte bessere Ergebnisse liefern
Ja, "besser" im Sinne von "schöner" bzw. auch "besser dem Vorbild entsprechend". Es bürdet einem Streckenbauer aber gleichzeitig auch noch die Arbeit auf, für die gesamte Strecke Stellwerke entwerfen zu müssen.
Eine automatische Generierung könnte in kurzer Zeit ein möglicherweise nicht realistisches, aber funktionstüchtiges Stellwerk ausspucken. Dieses könnte dann ja auch die Grundlage für manuelle Nachbearbeitung in einem Editor bilden.

Grusz,
- Christopher

P.S.: *) hier wollte ich erst "straightforward" schreiben, aber das wäre ja denglisch :evil: . http://dict.leo.org sagt: "straightforward" = "geradlinig" ;D .

Miri
Beiträge: 1940
Registriert: 04.11.2001 15:35:05
Wohnort: Neubeckum (ENBM)

#11 Beitrag von Miri »

Warum nicht? Die Generierung eines Stellpults ist ja eine recht geradlinige* Angelegenheit. In der Streckendatei sind ja alle befahrbaren Gleiselemente, alle Signale, Weichen usw. enthalten. Daraus kann man ein Stellwerk konstruieren.
Ein einfaches "Zug fahr dahin"-Stw sicher. Das Umsetzen in reale Bauformen wird schwieriger. Beim SpDrS60 gibts i.d.S. keine festen Regeln zur Stelltischgestaltung, an die man sich sklavisch hielt. Je nach Planer variert der Stelltischaufbau von "gut mitgedacht" bis "ein Gruppentastenblock für 3m Stelltisch".
Beim mech und emech gibt es zwar auch Regeln, die sich teilw. aus technischen Notwendigkeiten ergeben, aber auch hier blieb vieles dem Gusto des jew. Planers überlassen.
Es bürdet einem Streckenbauer aber gleichzeitig auch noch die Arbeit auf, für die gesamte Strecke Stellwerke entwerfen zu müssen.
Nö. Funktionieren tut die Strecke auch ohne Stws. Wenn halt ein paar Verrückte (zu denen ich mich auch zähle) sich dazu noch Stws bauen müssen ist das deren Bier.

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)

#12 Beitrag von Michael_Poschmann »

Christopher Spies hat geschrieben:Hallo,
Carsten Hölscher hat geschrieben:Automatische Generierung von Stellpulten würde ich nicht anstreben
Warum nicht?
Zur Komplexität siehe umfassender Beitrag zur automatischen Ableitung "linearisierter" Gleispläne im "Eisenbahn-Ingenieur", Ausgabe zur Innotrans. Die Aufgabe wird offenbar seit Ewigkeiten bearbeitet und ist alles andere als trivial. Ob bei Zusi ein sündhaft teures Profi-Tool "mal eben" abfällt, wage ich trotz Rolands bisweilen genialer Einfälle leicht zu bezweifeln...

Michael

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

#13 Beitrag von Roland Ziegler »

Nach einem größeren Projekt, bei dem eine schematische Visualisierung der Telematik-Infrastruktur von Streckenbeeinflussungsanlagen an Autobahnen auf generischen Wege, d.h. allein aus Konfigurationsdaten, erzeugt wurde, fühle ich mich in meiner Skepsis bestätigt, dergleichen ohne einen Wahnsinnsaufwand für realisierbar zu halten - von trivialen Sonderfällen einmal abgesehen.

Benutzeravatar
Carsten Hölscher
Administrator
Beiträge: 33384
Registriert: 04.07.2002 00:14:42
Wohnort: Braunschweig
Kontaktdaten:

#14 Beitrag von Carsten Hölscher »

Auch meine Aussage war nicht aus dem Bauch heraus, sondern beruht auf derartigen Überlegungen u.a. im Zusammenhang mit dem Eisenbahnlabor des DLR.
Also sind sich wohl alle einig ;)

Carsten

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)

#15 Beitrag von Michael_Poschmann »

OT:
Roland Ziegler hat geschrieben:... bei dem eine schematische Visualisierung der Telematik-Infrastruktur von Streckenbeeinflussungsanlagen an Autobahnen auf generischen Wege, d.h. allein aus Konfigurationsdaten, erzeugt wurde ...
Das habt Ihr tatsächlich hinbekommen? Hut ab!

Oder handelt es sich um den "Ostfriesenspieß"? - "Nächste Kurve: Helsinki!" :mua

Michael

Spontifixus
Beiträge: 4
Registriert: 03.10.2006 11:59:13

#16 Beitrag von Spontifixus »

Okeeh...

nachdem ich Gestern ne Menge nachgedacht habe, habe ich erstmal die komplette interne Struktur meines Stellwerks über den Haufen geschmissen - und bin gerade dabei, das neu zu bauen.

Allerdings werde ich die Software zunächst *nicht* auf eine kommunikation mit dem ZuSi auslegen - sondern sie als das gestalten für das sie ursprünglich geplant war: Eine simple Simulation. Über eine eventuelle erweitereung lasse ich dann gerne mit mir Reden, wenn das Ding irgendwann mal fertig sein sollte ;)

Gruß,
Markus :)

Benutzeravatar
Carsten Hölscher
Administrator
Beiträge: 33384
Registriert: 04.07.2002 00:14:42
Wohnort: Braunschweig
Kontaktdaten:

#17 Beitrag von Carsten Hölscher »

Über eine eventuelle erweitereung lasse ich dann gerne mit mir Reden, wenn das Ding irgendwann mal fertig sein sollte
Diese Reihenfolge kann natürlich bedeuten, daß man dann weitgehend von vorne anfangen muß.

Carsten

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

#18 Beitrag von Christopher Spies »

Carsten Hölscher hat geschrieben:Also sind sich wohl alle einig ;)
I see...

Spontifixus
Beiträge: 4
Registriert: 03.10.2006 11:59:13

#19 Beitrag von Spontifixus »

@Carsten: Jein. Bis jetzt ist das Stellwerk so aufgebaut, dass alle zu einem Stellwerksbereich gehörenden Dinge (Gleispläne, Fahrstrassen und Fahrpläne) in einem Objekt gespeichert werden.

Die grafische Darstellung dsowie die gesamte Stellwerkslogik übernimmt nachher das Stellwerksprogramm. Und da der ZuSi ja so wie ich das bisher verstanden habe keinerlei Stellwerkslogik (für den "manuellen" Betrieb) beinhalten wird sollte es nicht allzuschwierig sein, dem Programm eine TCP/IP Schnittstelle zur Kommunikation mit einem ZuSi-Server zu verpassen...

Benutzeravatar
Carsten Hölscher
Administrator
Beiträge: 33384
Registriert: 04.07.2002 00:14:42
Wohnort: Braunschweig
Kontaktdaten:

#20 Beitrag von Carsten Hölscher »

Wir haben da eine etwas fortgeschrittenere Schnittstelle als TCP im Auge. Mit .NET hättest Du aber gute Voraussetzungen zur Anbindung. Nur wenn Dein Modell der Weichen, Signale, Fahrstraßen usw. völlig anders ist, dann würde bei einer Anbindung wohl einiges an Anpassungen nötig.

Carsten

Antworten