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.
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:
(4711 stehe für die Ref-ID, und 2 sei das zu schaltende Signalbild, z.B. Hp2)Code: Alles auswählen
meineStellwerksSitzung.Signal[4711] = 2;
- 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.