SRCP-Erweiterungen: Unterschied zwischen den Versionen

Version vom 10. Oktober 2009, 15:38 Uhr (Quelltext anzeigen) Sven Schlender (Diskussion | Beiträge) K (→‎Formalisierte Beschreibung mittels XML) ← Zum vorherigen Versionsunterschied		Version vom 18. Februar 2010, 13:34 Uhr (Quelltext anzeigen) Sven Schlender (Diskussion | Beiträge) K (→‎SRCP-Stammtisch) Zum nächsten Versionsunterschied →
Zeile 38:		Zeile 38:
	|-		|-
	|  Sven Schlender		|  Sven Schlender
−	|  Karlsruhe	+	|  Leipzig
	|-		|-

---

Version vom 18. Februar 2010, 13:34 Uhr

Zielsetzung dieser Seite

Dieses Dokument soll eine Zusammenfassung der Diskussion „SRCP-Erweiterungen“ (erster Eintrag war am 27.12.2006) darlegen.

Hier der initiale Eintrag:

Hallo SRCP-Fans!

ich entwickle bereits seit einiger Zeit Software für SRCP, habe mich aber nie aktiv hier an Diskussionen beteiligt (ehrlich gesagt ist das mein erster Eintrag in der Gruppe ;). Während der Entwicklung kamen einige Ideen, die ich nun hier zur Diskussion stellen möchte:

1. Ich hätte gern einen Dienst für Clients, mit dem sie den Server (bzw. dessen IP-Adresse) finden können. Da gibt es sicher mehrere Möglichkeiten, ich dachte an Broadcast oder an eine DHCP-Option.
2. Stichwort CRCF: Was ist mit der Entwicklung? Ich hätte gern dieses Feature für SRCP und würde mich ggf. an der Mitentwicklung beteiligen.

Treffen sich die SRCP-Entwickler eigentlich regelmäßig zu einer Art Stammtisch?

Gruß, Sven.

Im Fokus der hier beschriebenen Erweiterungen steht die Vereinfachung der Nutzbarkeit (neudeutsch "usability") von SRCP. Damit soll die Verbreitung von SRCP erhöht werden und der Einstieg für Neulinge erleichtert werden.

Dieser Anspruch läßt sich kurz in einem Satz zusammenfassen: "Wie kann ich die Vorteile von SRCP nutzen, ohne dass ich die Interna des Protokolls kennen muss?"

SRCP-Stammtisch

Um die aktuellen Vorhaben besser diskutieren zu können, schlage ich ein Treffen in Form eines Stammtisches vor. Vielleicht kann man sich hier zunächst über einen Ort des Treffens verständigen, der von den meisten gut erreichbar ist.

SRCP-Interessierter	Wohnort
Sven Schlender	Leipzig
Stefan Bormann	Bremen
Guido Scholz	Burgkirchen
...	...

SRCP-Server-Suchdienst

Sehr schnell kam der Vorschlag, für diesen Bedarf einen Zeroconf-Systemdienst (DNS-SD/mDNS) einzusetzen. Dieser ermöglicht die Suche bzw. das Veröffentlichen beliebiger Systemdiente durch das Versenden eines ServiceDiscovery-Multicasts. Es existieren hierfür derzeit zwei zueinander kompatible Implementierungen, die beide als OpenSource freigegeben sind:

• Bonjour, von Apple für Mac, UNIXoide-Systeme und Windows.
• Avahi, als praktisch schon etablierter Standard für Linux.

Unter anderem ist es hiermit möglich, Angaben über die Portnummer zu veröffentlichen, auf der der Server seinen Dienst anbietet. Obgleich es für SRCP mittlerweile eine offiziell über IANA/IETF reservierte Portnummer (4303) und Protokollbezeichner (srcp) gibt, hat ein SRCP-Administrator prinzipiell die Freiheit, einen von dieser Vorgabe abweichenden Wert für die Portnummer zu wählen. Auch die Anzahl der in einem Netz betriebenen SRCP-Server ist damit nicht eingeschränkt.

Dem Administrator eines SRCP-Servers bleibt es überlassen, auf dem gleichen Rechner auch einen „Zeroconf“-Systemdienst einzurichten. Er muß, wenn er auf seiner Modellbahn entsprechende SRCP-Clients benutzen möchte, das Programm installieren und so konfigurieren, dass der SRCP-Dienst veröffentlicht wird. Alternativ kann ein SRCP-Server sich auch automatisiert beim Zeroconf-Dienst anmelden. Die eigentliche Arbeit für die Nutzung des SD-Dienstes liegt beim Entwickler des „Einsteck-und-Spiel“-SRCP-Clients, denn dieser SRCP-Client muß nicht nur SRCP sprechen, sondern auch noch ein DNS-SD/mDNS-Client sein.

Beispiel für eine avahi Konfigurationsdatei. Abgelegt unter /etc/avahi/services/scrpd.service (Kubuntu Linux). Die Einträge sind natürlich nur beispielhaft.

<service-group>
   <name replace-wildcards="yes">srcpd on %h</name>
   <service protocol="any">
       <type>_srcp._tcp</type>
       <host-name>srcp.example.com</host-name>
       <port>4303</port>
       <txt-record>SRCP auf Mobaserver</txt-record>
   </service>
</service-group>

CRCF-Erweiterungen

Obwohl CRCF (Common Railroad Configuration Files) schon vor einigen Jahren zur Implementierung vorgeschlagen wurde, fand es keine Verbreitung bzw. Anwendung. Möglicherweise war damals das Interesse zu gering. Umso mehr Interessenten fanden sich nun in dieser Diskussion, bei der über die bisherigen Ideen von CRCF hinaus einige weitergehende Themen aufkamen.

Stand der Technik

Der bisherige CRCF-Spezifikationsentwurf mit der Versionsnummer 0.2.0 basiert auf SRCP und beschreibt die Fähigkeiten eines SRCP-Servers. Die dort abgelegten Informationen beziehen sich je Datei auf genau _einen_ SRCP-Server. Physikalisch liegen die CRCF-Daten beim zugehörigen SRCP-Server; Detailinformationen daraus können von SRCP-Clients über den SRCP-Befehl CONFGET abgefragt werden. Dieser Befehl erlaubt nur Lesezugriffe und damit auch nur den Umgang mit statischen Daten. Ein analoger Befehl CONFSET zum Schreiben von Daten ist erwähnt, es ist aber keine nähere Anwendung dafür definiert. Das Ablageformat wird als textbasierte Datei beschrieben, wobei die Daten in Sinne von SRCP mit entsprechend benannten Datenfeldern vorliegen. Der vorliegende Entwurf ist zur Zeit der SRCP-Spezifikation 0.7.1 entstanden und bildet die mit Version 0.8 eingeführten Erweiterungen, wie z.B. Busse, noch nicht ab.

Anforderungen an CRCF

• Die umständliche Eingabe von Informationen über Loks (z.B. Belegung der Funktionen) und Zubehör soll zur einfacheren Konfiguration von SRCP-Clients entfallen.
• Anlagenweite Anzeige von Klartextnamen anstatt von Adressen (konkretes Beispiel?)
• Als Alternative zum Zeroconf-Systemdienst könnte CRCF die Hostnamen bzw. IP-Adressen der SRCP-Server einer Anlage verwalten.
• Verwaltung statischer Informationen
• Verwaltung dynamischer Informationen
• CRCF soll für Benutzer in ausdruckbarer Form zugänglich sein.
• Die Daten sollen in CRCF strukturiert/gegliedert abgelegt sein.
• SRCP-Server sollten Zugriff auf die CRCF erhalten (Warum?).
• Der CRCF-Befehlsvorrat könnte zur Kommunikation zwischen Clients genutzt werden.
• Der bisherige Geltungsbereich einer CRCF-Datei sollte sich nicht nur auf _einen_ SRCP-Server, sondern vielmehr auf _eine_ Modellbahnanlage beziehen. Damit wäre ein geeigneter Rahmen vorhanden, den charakterisierenden Bestand an z.B. Zügen, Fahrstraßen, SRCP-Servern, dem Streckennetz etc. einer Anlage zusammenfassend abzulegen.

Fragestellungen

• Wo soll die CRCF liegen?
• Wie soll eine Datenabfrage aussehen?
• Wie sollen dynamische Informationen von CRCF verwaltet werden?
• Soll die Kommunikation zwischen SRCP-Clients mit CRCF abgebildet werden und wenn ja, wie?

Namensgebung

CRCF steht im Moment ja für Common Railroad Configuration Files, inzwischen hat es sich ja aber zu einem Protokoll zur Abfrage von Konfigurationsdaten entwickelt. Von daher passt der bisherige Name nicht mehr. Um keinen unnötigen Änderungsaufwand zu provozieren sollte die Abkürzung beibehalten werden können. Common Railroad Configuration Language - CRCL ist daher also nicht optimal. weitere Vorschläge:

• Common Railroad Configuration Format

Implementierungsvorschläge

Zentrale Datenablage bei einem spezialisierten SRCP-Client

Über die Diskussion ergab sich der Vorschlag, den CRCF-Datenbestand über einen speziellen SRCP-Client netzwerkweit zugänglich zu machen, statt diesen nur als zentral verwaltete Datei abzulegen. Dieser SRCP-Client hätte damit eine Art Datenbankserverfunktion und könnte gezielt Detailinformationen ausliefern. Interessierte Clients müßten dann nicht jeweils selbst die komplette Datei nach den für sie notwendigen Informationen durchsuchen. Auch ein SRCP-Server könnte auf diese Daten zugreifen.

Der Zugriff auf diesen als CRCF-Server arbeitenden SRCP-Client erfolgt über den SRCP-Server, der sowohl die eingehenden CRCF-Anfragen als auch die zurückgehenden Antworten weiterleitet. Das bisherige SRCP muß erweitert werden, um diese neue Abfragetechnik zu ermöglichen. Bei diesem Modell wird SRCP als Tunnel genutzt, da CRCF-Anfragen vom SRCP-Server nicht interpretiert sondern nur durchgereicht werden. Dabei entsteht gleichzeitig eine Möglichkeit zur Kommunikation zwischen SRCP-Clients.

Bei Installationen mit mehreren SRCP-Servern muß sich der SRCP-Client bei allen verfügbaren SRCP-Servern anmelden, damit Daten anlagenweit verteilt werden können. Die Programmierung solcher Clients wird wegen der erforderlichen Netzwerkverbindungen aufwändig. Alternativ müßten SRCP-Server so gekoppelt werden, das die Anmeldung bei einem Server reicht.

Der SRCP-Client mit dem CRCF-Datenbestand kann konsistent statische und dynamische Daten verwalten, wenn er diese konsequent einsammelt bzw. zugestellt bekommt. Zusätzlich wird die Verwaltung von Daten, die über die SRCP-Welt hinausgehen, wie die von Fahrstrassen und kompletten Layouts, ermöglicht.

Zentrale Datenablage bei einem separaten CRCF-Server

Als weitere Idee wurde der Vorschlag diskutiert, die Verwaltung der CRCF-Daten einem neu zuschaffenden CRCF-Server zu überlassen. Dieser würde als eigener Systemdienst laufen und müßte über ein neu zudefinierendes Protokoll angesprochen werden. Die SRCP-Spezifikation muß in diesem Fall nicht geändert werden, da das CRCF-Protokoll parallel und von SRCP weitgehend unabhängig existiert.

Der CRCF-Server bedient zunächst nur rein statische Daten, die von den CRCF-Clients abgefragt werden können. Damit sowohl SRCP-Clients als auch SRCP-Server diesen Dienst nutzen können, müssen diese zusätzlich das CRCF-Protokoll implementieren.

Um auch dynamische Daten zu verwalten, muß ein Meldedienst implementiert werden, der auch Schreibzugriffe in den Datenbestand ermöglicht. Eine Kommunikation zwischen CRCF-Clients könnte mittels einer Mailboxfunktion realisiert werden.

Verteilte Datenablage bei verschiedenen SRCP-Clients

Jeder SRCP-Client, der Daten verwaltet, die im laufenden Anlagenbetrieb einer mehr oder weniger kontinuierlichen Änderung unterliegen und über das herkömmliche SRCP nicht erfaßt werden, könnte diese zur Abfrage für interessierte Clients zur Verfügung stellen. Er würden dann sozusagen auch als CRCF-Server arbeiten, allerdings beschränkt auf die von ihm verwalteten, dynamischen Daten. Alternativ ließe sich dieses Konzept auch auf die statischen Daten ausdehnen.

CRCF-Clients, die eine Anfrage starten möchten, wüßten zu Beginn nicht, wo diese Daten abgelegt sind. Eine zentrale Verwaltungsinstanz wäre in diesem Fall ja nicht vorhanden. Der anfragende Client könnte also eine Rundrufnachricht senden und würde die Antwort von dem zuständigen SRCP-Client bekommen. Hier besteht prinzipiell die Gefahr, dass diese Daten nicht konsistent vorliegen, wenn die Zuständigkeit der abgefragten Daten nicht eindeutig z.B. auf genau _einen_ bestimmten Client festgelegt ist. Insbesondere kann das leicht bei mobilen SRCP-Clients passieren, wenn diese auf mehreren Anlagen genutzt werden und der Benutzer nicht sorgsam mit den lokal gespeicherten Daten umgeht.

Bereitstellung der CRCF-Daten via Zeroconf-Dienst

Diese Idee wurde als eine prinzipielle Möglichkeit erwähnt, aber nicht weiter ausgeführt.

Abfrage der CRCF-Daten via Generic Messages

Nachdem Generic Messages als neue Device Group in SRCP aufgenommen wurden, können CRCF-Daten darüber versendet werden.

Eine CRCF Message hat folgendes Datenformat:

GM <send_to>  <reply_to> CRCF <actor> <actor_id> <method> <attribute> [<attribute_value>]

<send_to>

Sessionid of an INFO session the message MUST BE delivered to or 0 (null) if delivery is done to all INFO sessions.

<reply_to>

Sessionid of an INFO session to which message replies SHOULD be directed (if any). Alternatively the 0 (Null) MUST be used to direct the reply to all INFO sessions.

CRCF

Message type für CRCF Messages.

<actor>

Benennung für den Akteur, dessen Daten geändert werden sollen.

<actor_id>

Identifikationsnummer, die zur eindeutigen Adressierung des Akteurs dient. Es handelt sich dabei um eine UUID gemäß RFC4122.

Wie sieht es mit einer ID für Broadcasts aus? Es würde sich 00000000-0000-0000-00000000000 anbieten, aber vielleicht gibt es da bessere Alternativen.

<method>

Methode, die auf den folgenden Attributwert angewendet werden soll. Folgende Methoden sind implementiert:

INFO

Response Message, <attribute_value> kann verwendet werden.

SET

Setting values. Wird mit einer INFO oder ERROR Messages beantwortet.

GET

Request of values. <attribute_value> muss nicht verwendet werden. Wird mit einer INFO oder ERROR Message beantwortet.

LIST

Abfrage einer Liste, wenn das Attribute mehrere Werte haben kann. Als Antwort wird als erstes die Anzahl der vorhandenen Datensätze übermittelt. Dazu wird an das Attribute die Zeichenkette COUNT gehängt und als Attribute Value die Anzahl der Datensätze. Danach wird jeweils in einer Zeile die abgefragten Attributen mit dem jeweils dazugehörigen Wert als <attribute_value>. Wenn die Abfrage nicht möglich ist, wird mit einer ERROR Message geantwortet.

Beispiel:

CRCF LOCODB <actor_id> LIST LOCO

->

CRCF LOCODB <actor_id> INFO LOCOCOUNT 2

CRCF LOCODB <actor_id> INFO LOCO <loco_id1>

CRCF LOCODB <actor_id> INFO LOCO <loco_id2>

ERROR

Wenn eine Abfrage nicht ausgeführt werden kann, wird sie mit einer entsprechenden Fehlermeldung beantwortet. Als <attribute> wird der Fehlercode übermittelt und als <attribute_value> der dazugehörige Fehlertext. Die Fehlercodes entsprechen den in SRCP definierten.

<attribute>

Attribut des Akteurs, das von der Nachricht betroffen ist. Die Attribut-Kennungen sind je nach Akteur unterschiedlich.

<attritbute_value>

Der Wert des Attributs, das von der Nachricht betroffen ist. Die Angabe dieses Wertes ist abhängig von der verwendeten Methode und des Attributes. Je nach Attribut kann es sich hierbei um einen positiven Ganzzahlwert >= 0 (z.B. Nummer eines Zuges), eine UUID oder eine alphanumerische Kennung (z.B. Name einer Fahrstraße) handeln. Handelt es sich um einen alphanumerischen Wert, wird dieser URL-kodiert (RFC 2396) über den SRCP-Server versendet und empfangen.

Erweiterung des bisherigen Befehlsvorrats

Der bisherige Namensraum von CRCF umfaßt keine Befehle, die Objekte einer höheren Abstraktionsebene beschreiben. Für die Attribute dieser makroskopischen Objekte gibt es ebenfalls noch keine Festlegung. Zum Teil sind die Werte dieser Attribute statisch zum Teil ändern sich sich während des Betriebs. Bei der Implementierung von CRCF via GM agieren diese Objekte als Aktoren, mit den jeweiligen Attributen. Der Bedarf für folgende Begriffe ist vorhanden:

Stellwerk (RWCC, Railway Control Center)

Steuerungsinstanz, die Fahrstraßen verwaltet, für ein oder mehrere Bahnhöfe zuständig ist, Zugmeldungen abwickelt, ihr zuständiges Streckennetz kennt, einzuhaltende Geschwindigkeiten überwacht und bei Überschreitungen eingreift etc.

Identifikationsnummer (ID) - UUID - statisch

Name (NAME) - alphanumerisch - statisch

Modus (MODE) - numerisch - dynamisch

Gleisbild (LAYOUT)

Streckennetzbeschreibung eines Stellwerkbezirks, enthält Angaben zur Dimension, Position einzelner Gleisbildelemente, automatischer Streckenblöcke, Fahrstraßen, etc.

Identifikationsnummer (ID) - UUID - statisch

Name (NAME) -alphanumerisch - statisch

Zeilen (ROWS) - numerisch - statisch

Spalten (COLUMNS) -numerisch - statisch

Stelltischausleuchtung (TABLELIGHT) - numerisch - dynamisch

Freimeldeabschnitt (?)

Streckenabschnitt, der mit einer Gleisfreimeldeanlage (Rückmeldung/Belegtmeldung) überwacht wird.

Automatischer Streckenblock (BLOCK)

Automatisch per Freimeldeabschnitte überwachter Streckenabschnitt zur Steuerung von Zugfahrten. Ein automatischer Streckenblock führt von einem Startgleisabschnitt in einen Zielgleisabschnitt.

Fahrstraße (ROUTE)

Sicherheitstechnisch überwachter Streckenabschnitt innerhalb eines Stellwerks, der über Informationen zur Start- und Zielsignal, Soll-Weichenstellungen, Freimeldeabschnitte, Typinformation (für anzuwendenden Regelsatz), den aktuellen Zustand (eingestellt, aufgelöst, reserviert, teilaufgelöst) etc. verfügt. Eine Fahrstraße führt von einem Startgleisabschnitt in einen Zielgleisabschnitt.

Identifikationsnummer (ID) - UUID - statisch

Name (NAME) - alphanumerisch - statisch

Typ (TYPE) - numerisch - statisch

Status (STATE) - numerisch - dynamisch

Zug (TRAIN) - numerisch - dynamisch

Weichenstraße (SLIST, Switch List)

Sammlung schaltbarer Magnetartikel und ihrer Sollstellungen ohne sicherheitstechnische Überwachung; ist nicht mit »Fahrstraße« zu verwechseln.

Zugsteuerung (TNCC, Train Control Center)

Instanz, die die Logistik eines gegebenen Vorrats an Zügen übernimmt z.B. fahrplangesteuerte Fahrten von Zügen zwischen Bahnhöfen

Zug (TRAIN)

Instanz, die über ihre Zugnummer identifizierbar ist, eine oder mehrere Lokomotiven ansteuert, Informationen zu Typ und Länge verfügt etc.

Bahnhof (STATION)

Start- und Zielpunkt von Zugfahrten.

Gleisabschnitt (SECTION)

Ein Gleisabschnitt charakterisiert den Aufenthaltsort eines Zuges, z.B. für Zugmeldungen. Streckenblöcke und Fahrstraßen überführen einen Zug von einem Gleisabschnitt (Start) in den nächsten Gleisabschnitt (Ziel).

Lokdatenbank (LOCODB)

Instanz, die eine Übersicht über vorhandene Lokomotiven und deren Konfiguration bietet.

Identifikationsnummer (ID) - UUID - statisch

Name (NAME) - alphanumerisch - statisch

Liste verwalteter Loks (LOCO) - Liste - dynamisch

Lok (LOCO)

Konfiguration einer Lok

Identifikationsnummer (ID) - UUID - statisch

Name (NAME) - alphanumerisch - statisch

Bild (IMAGE) - UUID - statisch

Höchstgeschwindigkeit im km/h (V_MAX) - numerisch - statisch

verbaute Decoder (DECODER) - Liste - statisch

Decoder (DECODER)

Konfiguration eines Decoder

Identifikationsnummer (ID) - UUID - statisch

Name (NAME) - alphanumerisch - statisch

Lok in der der Decoder verbaut ist (LOCO) - UUID - statisch

unterstützte Protokolle (PROTOCOL) - LISTE - statisch

Protokollkonfiguration eines Decoders (PROTOCOL)

Beschreibung der Konfiguration eines Decoders für das jeweilige Protokoll

Identifikationsnummer (ID) - UUID - statisch

Format des Protokolls (NAME) - alphanumerisch - statisch

Decoder zu dem diese Protokolldefinition gehört (DECODER) - UUID - statisch

Adresse (ADRESS) - numerisch - dynamisch

Bus (BUS) - numerisch - dynamisch

Fahrstufen (SPEEDSTEPS) - numerisch - statisch

abs./rel. Fahrtrichtung (DIRECTION) - numerisch - statisch

Programmiermodi (PROGMODE) - alphanumerisch - statisch

Funktionen (FUNCTION) - Liste - statisch

Funktion (FUNCTION)

Beschreibung einer Funktionbelegung eines Decoders

Identifikationsnummer (ID) - UUID - statisch

Beschreibung (NAME) - alphanumerisch - statisch

Protokollkonfiguration zu der diese Funktion gehört (PROTOCOL) - UUID - statisch

Nummer der Funktion (NUMBER) - numerisch - statisch

Auslöseart (MODE) - numerisch - statisch

Wie die Funktion betätigt wird, ob schaltend oder tastend. Dabei ist 0=schaltend und 1=tastend.

Bild (IMAGE_ON) - UUID - statisch

Bild (IMAGE_OFF) - UUID - statisch

Bild das auf der Funktionstaste angezeigt werden soll.

Bild (IMAGE)

Bild, das in mehreren Dateiformaten vorliegen kann, mit Zeitstempel, um festzustellen, wann es zuletzt verändert wurde.

Identifikationsnummer (ID) - UUID - statisch

Beschreibung (NAME) - alphanumerisch - statisch

Formate (FORMAT) - numerisch - statisch

Formate in denen das Bild vorhanden ist: 1=SVG, 2=PNG, 4=JPG Rückgabewert ist die Summe aller verfügbaren Formate.

Zeitstempel (TIMESTAMP) - numerisch - statisch

eigentliches Bild (DATA) - Byte-Strom - statisch

Über GET DATA <format>,<width>,<height> kann das Bild in der gewünschten Größe und Format abgerufen werden.

(TODO: weitere ergänzen)

Formalisierte Beschreibung mittels XML

Der aufgespannte CRCF-Namensraum wird durch ein XML Schema beschrieben (siehe Abbildung).

Aus diesem Dokument kann eine CRCF-konforme XML-Datei erstellt werden. Ein CRCF-Server (zentralisiert über SRCP oder standalone) kann eine solches File als Datenbank verwalten. Dynamische Daten können direkt in das CRCF-XML File eingepflegt werden.

Hier können CRCF Schema-Datei und eine CRCF Beispiel-Datei heruntergeladen werden.

Designentscheidungen

1. Die beschriebenen Daten entsprechen dem Ergebnis einer fertig installierten Anlage.
2. Es wurde eine 1:1 Abbildung von Lok zu Decoder vorgenommen. Als weitere Schritt könnten die Decoderdaten vollkommen in den Lokdaten aufgehen. Über diese Abbildung besteht jedoch auf jeden Fall noch Diskussionsbedarf.
3. Auf die Referenzierung des Elternelements mittels ID-Referenzierung wurde verzichtet, da darauf mit XML-Mitteln einfach zugegriffen werden kann.
4. Es wurde als weiteres Element eine (SRCP-)Serverdatenbank aufgenommen. Hierbei fehlt aber noch die Möglichkeit eine lokale Steuerung durch den CRCF-Server abzubilden (Vorschläge?!).
5. Die Lokfunktionen werden im Modell als direkte Kindelemente der Lok wahrgenommen und nicht als Kinder des Decoders. Die Abbildung entspricht eher der menschlichen Wahrnehmung (Lok = {Geschwindigkeit, Fahrtrichtung, Menge an Funktionen}). Auch hier gibt es vermutlich Diskussionsbedarf.

SRCP-Erweiterungen

Der bisherige Umfang der SRCP-Spezifikation definiert keine Möglichkeit, mit der SRCP-Clients untereinander direkt Informationen austauschen können. Ein Bedarf dafür ist jedoch durchaus gegeben, wie folgende Auflistung zeigt:

• Zugmeldungen zwischen Stellwerken
• Zuglenkung über Zuglaufverfolgung (ZLV) und Zugnummernmeldeanlage (ZNA)
• Zugbeeinflussung mit geschwindigkeitsüberwachender Instanz (Stellwerk) und Zugsteuerung
• Scripting-Schnittstelle für Stellwerk- und Zugsteuersoftware
• Austausch von statischen und dynamischen CRCF-Daten mit einer CRCF-Datenverwaltungsinstanz

Weiterhin ist es mit SRCP prinzipiell möglich, eine Modellbahnanlage über mehrere SRCP-Server zu bedienen, es gibt aber bisher kein Konzept, das einen Informationsübergang zwischen den Server-Bereichen erlaubt. Dazu gab es folgenden Lösungsvorschlag:

• Koppelung mehrerer SRCP-Server zu einer Master/Slave-Konstellation, bei der die Busse der Slave-Server auf Busse beim Master-Server abgebildet werden.

Zur Realisierung dieser neu zu implementierenden Informationswege wurden die im folgenden näher erläuterten Konzepte vorgeschlagen.

Neuer Befehl im Kommandomodus

Vorschlag

Die aktuell SRCP-Spezifikation umfaßt für den Kommandomodus einen definierten Satz an Befehlen, die in der folgenden allgemeinen Syntax an den Server gesendet werden:

<kommando> <kommandoparameter> 

Da die Befehle auf definierte Gerätegruppen wirken, die wieder bestimmten Bussen zugeordnet sind, resultiert zur weiteren Spezifizierung folgende allgemeine Befehlssyntax:

<kommando> <bus> <gerätegruppe> <parameter>

Der Bus mit Nummer 0 ist dem Server selbst vorbehalten und dient zur Adressierung von Servereinstellungen. Die Anzahl der übergebenen Parameter ist variabel.

Vom Server abgearbeitete Befehle werden gemäß der SRCP-Spezifikation an alle im INFO-Modus verbundene SRCP-Clients als eine Art „SRCP-Broadcast“ (SRCP-Rundruf) mit der folgenden allgemeinen Syntax weitergeleitet:

<codenr> INFO <bus> <gerätegruppe> <parameter>

Die angeschlossenen SRCP-Clients selbst sind anhand ihrer Session-Id identifizier- und eindeutig unterscheidbar.

Von dieser Situation ausgehend, kann ein neues Kommando ergänzt werden, dass von SRCP-Server selbst nur zum Weiterleiten einer Nachricht an die angeschlossenen SRCP-Clients genutzt wird. Den Inhalt der Nachricht muß der SRCP-Server nicht interpretieren. Die Form der Nachricht kann/soll/muß den gängigen SRCP-Konventionen bezüglich Zeichensatz, Länge etc. genügen.

Implementierungsvariante 1

Ein erster (anarchischer) Ansatz könte in SRCP 0.8-Terminologie so aussehen:

Im Kommando-Modus verbundender Client:

ECHO 0 <message>

Darauf der SRCP-Server an alle verbundenen Clients:

<timestamp> <codenr> INFO 0 ECHO <message>

Implementierungsvariante 2

Ein zweiter, mehr geordneter Ansatz, schreibt die Verwendung definierter Befehle (SRCP-Makros) vor, analog also beispielsweise so:

Im Kommando-Modus verbundender Client:

MACRO 0 <message>

Darauf der SRCP-Server an alle verbundenen Clients:

<timestamp> <codenr> INFO 0 MACRO <message>

Wobei <message> diesmal eine Folge von definierten (genormten) Befehlen inklusive deren Wert-Parametern sein muß. Diese Makros müssen natürlich den Kommunikationsbedarf der Clients (Frage/Antwort-Spiele) abdecken.

Implementierungsvariante 3

Der dritte Ansatz wäre, statt der neu zu erfindenden Makros, CRCF zu benutzen:

Im Kommando-Modus verbundender Client:

 CRCF 0 <message>

Darauf der SRCP-Server an alle verbundenen Clients:

 <timestamp> <codenr> INFO 0 CRCF <message>

Der Inhalt von <message> wäre dann eine CRCF-Befehlsfolge.

Anwendungsbeispiele

Angenommen eine Ablaufsteuerung (als eigener SRCP-Client) möchte eine Fahrstraße einstellen, dann sendet diese an das zuständige Stellwerk folgende (CRCF-)Befehlsfolge:

ROUTE <routeid> SET STATE 1

Den Erfolg bekommt er dann vom Stellwerk zurückgemeldet...

ROUTE <routeid> INFO STATE 1

... oder kann ihn auch abfragen z.B. gemäß:

ROUTE <routeid> GET STATE

Sinngemäß ließe sich so auch die Belegung einer bestimmten Fahrstraße mit einem Zug (TRAIN) setzen, abfragen oder melden. Der übermittelte Zahlenwert würde dann der Zugnummer entsprechen. Der Bedarf, dass ein SRCP-Client einem Stellwerk Daten zur Konfiguration von Fahrstraßen sendet, wäre prinzipiell auch abdeckbar:

ROUTE <routeid> ADD GA <busid> <address> <port> <state>

Oder entfernen:

ROUTE <routeid> REMOVE GA <busid> <address>

Um eine Client-Client-Verbindung zu unterhalten, müßte der Sender eines CRCF-Befehls seine SRCP-Session-ID immer mitsenden, dann könnte die Antwort zielgerichtet erfolgen:

CRCF 0 <sender-sessionid> <empfänger-sessionid> <CRCF-message>

Mit dem Inhalt von <sessionid> ließe sich ein CRCF-Broadcast einfach von einer Punkt-zu-Punkt-Verbindung unterscheiden:

1. Der Wert ist 0: Rundruf (Broadcast)
2. Der Wert ist >0: Punkt-zu-Punkt-Verbindung

Auch das Thema »Zugbeeinflussung« läßt sich hiermit darstellen. Ein Zug muß während seiner Fahrt Geschwindigkeitsregeln einhalten, die das Stellwerk überwacht. Bei Überschreitungen sendet das Stellwerk einen Abbremsbefehl:

 CRCF 0 <sender-session-id> 0 TRAIN <train-id> SET SPEED 0

Bewertung

Die Implementierung wird nicht weiterverfolgt, da der Vorschlag zur neuen Gerätegruppe besser ins bisherige SRCP paßt. Die hier andiskutierten CRCF-Nachrichten können mit dem anderen Vorschlag ebenfalls transportiert werden.

Neuer Sitzungstyp

Vorschlag

Die Implementationen von CRCF bzw. Generic Messages und den bisher definierten SRCP-Sitzungen werden komplett getrennt.

Motivation:

• Ermöglicht Kapselung von unterschiedlichen Client-Funktionalitäten: die bestehenden Sitzungen und Generic Messages sind für komplett unterschiedliche Zwecke gedacht. Die bisherigen Steuerungs-Sitzungen dienen der Kommunikation mit der Modellbahn-Hardware, Generic Messages dienen der Kommunikation der Clients untereinander.
• Dies senkt die Anforderungen an einen reinen Steuerungs-Server, er muss Generic Messages nicht unterstützen. Anmerkung von svesch: Der Server muss die GMs nur weiterleiten. CRCF macht nur Sinn, wenn es die SRCP-Server auch wirklich unterstützen. Sozusagen mandatory ab Version X.
• Es erspart mobilen Eingabegeräten z.B. einem Handregler den extremen Traffic, den intelligentere stationäre Clients untereinander haben. Anmerkung von svesch: Das ist ein wichtiger Punkt, den habe ich im Punkt "Vorschläge zur Trafficminimierung" versucht Rechnung zu tragen.

Bei der Einschätzung des Programmieraufwands gehen die Meinungen auseinander. Die einen sehen Zusatzaufwand in der dritten TCP-Verbindung, andererseits erhöht die Kapselung der Funktionalitäten die Wartbarkeit des Systems.

Eigene Sitzungen trennen sowohl den Namensraum für Steuerung und Generic Messages als auch den durch beide Kommunikationsformen entstehenden Netzwerkverkehr:

SET PROTOCOL GM 0.3
SET CONNECTIONMODE GM INFO|COMMAND

Programmiertechnisch wird sowohl für den SRCP-Server als auch den SRCP-Client die Unterhaltung einer bzw. zweier weiterer Netzwerkverbindungen notwendig. Alternativ ist ein Systemdienst möglich, der nur GM-Sitzungen, aber keine Steuerungs-Sitzungen unterstütz.

Bewertung

Die Diskussion dauert noch an, daher ist keine abschliessende Bewertung möglich

Neue Gerätegruppe

Vorschlag

Für den generalisierten Nachrichtenaustausch wird eine neue Gerätegruppe (device group) »Generic Message« (GM) auf Bus 0 eingerichtet. Die einzige (sinnvoll) anzuwendende Methode ist SET.

Beispielhafte Anwendung im Kommandomodus:

SET 0 GM <AntwortID> <EmpfängerID> <messagetype> <messagetext>

EmpfängerID ist diejenige INFO-Session-ID, die die Nachricht erhalten soll. Ist diese 0, so wird die Nachricht als Rundruf an alle INFO-Sessions gesendet. Die AntwortID ist die INFO-Session-ID (oder 0), an die eine eventuelle Antwortnachricht gesendet werden soll. Anmerkung: Die Antwort-ID ist niemals die Session-ID, die den SET Befehl ausführt.

Beispielhafte Anwendung im INFO-Modus:

INFO 0 GM <AntwortID> <EmpfängerID> <messagetype> <messagetext>

<messagetype> ist ein entweder zentral (Wo und von wem?) oder dezentral (anwendungsspezifisch) definierter Identifier, der als eindeutige Kennung für die Interpretation von <messagetext> dient.

Für <messagetext> gelten die im SRCP üblichen Einschränkungen/Formatanforderungen, z.B. dass der Zeichensatz aus 7 Bit ASCII besteht. Die Länge der gesamten Kommandozeile ist auf 1000 Zeichen begrenzt.

Anwendungsbeispiel

Ein Client fragt nach den Einzelheiten des Gerätes GA 1 auf Bus 8. Antwort an Session-ID 13 erbeten (Schritt 1).

SET 0 GM 13 0 CRCF CONFGET 8 GA 1

Wie die INFO-Nachricht aussieht, dürfte offensichtlich sein. Er geht an alle INFO-Sessions (Schritt 2).

INFO 0 GM 13 0 CRCF CONFGET 8 GA 1

Wenn ein CRCF-Service diese Nachricht erhalten hat, sendet er eine passende Antwort an den SRCP-Server (Schritt 3):

SET 0 GM 19 13 CRCF CONFINFO 8 GA 1 ....

Die Info-Session des CRCF-Services ist im Beispiel 19; die Antwort wird vom SRCP-Server direkt an die SESSION 13 weitergeleitet (Schritt 4):

INFO 0 GM 19 13 CRCF CONFINFO 8 GA 1 ....

Der Nachrichtenfluß über die Schritte 1 bis 4 ist in der nebenstehenden Grafik dargestellt. Die teilnehmenden SRCP-Clients müssen sowohl eine COMMAND- als auch eine INFO-Sitzung unterhalten. Für die Adressierung der Nachrichten spielen die Identifikationsnummern der COMMAND-Sitzungen (im Beispiel 12 und 18) keine Rolle.

Weitere Anfragen kann der Client direkt an Session 19 stellen. Er erhält die INFO-Nachricht sofort. Wenn Session 19 terminieren sollte, kann er wieder auf Empfänger 0 (= alle) umstellen.

Bewertung

Es entsteht eine allgemein nutzbare Kommunikationsstrecke mit vielfältigem Anwendungspotential. Es entsteht ein permanenter Pflegedienst für Vergabe der Nachrichtentypen (kann automatisiert werden). Der Vorschlag wurde in die SRCP-Spezifikation 0.8.4 übernommen.

Anmerkungen

Zu den Konsequenzen der Implementierung gab es einige spezielle Fragestellungen.

Müssen wir uns über Timeouts Gedanken machen?

Das ist Sache der Clients und sollte natürlich benutzerfreundlich gestaltet sein.

Wie lange soll ein anfragender Client auf Antworten warten?

Da der Client für das Timeoutverhalten verantwortlich ist, entscheidet auch er darüber. Wiederum gilt, so benutzerfreundlich, wie möglich.

Generiert der Server gegebenenfalls eine Timeout-Nachricht?

Nein, denn er hat keine Ahnung vom Inhalt der ausgetauschten Nachrichten. Er transportiert nur eine Botschaft; dass zwei (oder auch mehr) Teilnehmer zu einem Dialog gehören, ist dem Server unbekannt.

Wenn der Server schon beim Empfang einer "SET 0 GM"-Anfrage sieht, dass er damit keinen Empfänger erreichen kann, sollte er eine entsprechende Meldung an den Anfrager generieren (beispielsweise wenn der Anfragende der einzige angemeldete Client ist)?

Vorschlag: Der Server sendet in einem solchen Fall "416 ERROR no data". Dies Meldung erfolgt nur dann, wenn keine INFO Session aktiv ist. Könnte damit auch entfallen, da der Timeout zuschlagen wird.

Warum muss der Client bei "SET 0 GM"-Anfragen seine Antwort-ID mitsenden? Der Server könnte diese ID in die INFO-Nachricht eintragen, denn er kennt sie ja.

Der Server hat überhaupt keine Ahnung davon, welche beliebigen zwei Sessions zusammengehören.

Die Session-IDs übernehmen eine zentrale Rolle beim Gebrauch von GMs. In der aktuellen SRCP-Spezifikation fehlt eine Beschränkung der Session-ID auf einen definierten Wertebereich.

Der im normalen Betrieb notwendige Wertebereich ist sehr gering; ein generischer (von der Hardwareplatform abhängiger) vorzeichenloser Ganzzahlwert sollte für alle Anwendungsfälle ausreichen.

Vorschläge zur Minimierung des Netzwerkdatenverkehrs

Die Diskussion zeigte, dass größeres Unverständnis darüber herrschte, welches zusätzliche Datenaufkommen über den Nachrichtenaustausch der SRCP-Clients untereinander entstehen würde. Es bestand teilweise die Befürchtung, dass nicht an dieser Kommunikation interessierte SRCP-Clients unnötig und überfordernd belastet würden. Hier wurde insbesondere deutlich, dass das jetzt schon über den INFO-Kanal eingehende Nachrichtenvolumen SRCP-Anfängern unter Umständen nicht bewust ist und leicht unterschätzt wird.

Bei sachgemäßem Umgang mit dem neuen Nachrichtenkanal ergibt sich gegenüber dem bisherigen INFO-Kanalvolumen jedoch nur ein geringes Mehr an Daten. Insbesondere die Möglichkeit zur direkten Kommunikation zweier Teilnehmer wirkt im Bedarfsfall stark volumenbeschränkend. Ein inflationärer Gebrauch von Rundrufnachrichten sollte naturgemäß vermieden werden.

• Wenn an einen SRCP-Server eine CRCF-Broadcastanfrage gestellt wird, muss er dann eine INFO-Nachricht generieren? Es kann ja sein, dass er selber auf die Anfrage antworten kann. Gerade bei dynamischen Daten kann der Server möglicherweise am besten Auskunft geben.

Anmerkung: Es gibt bereits genügend SRCP-Kommandos, um Informationen direkt beim Server zu erfragen. Dieser Punkt ist daher irrelevant.

• CRCF-Broadcastanfragen werden vom Server per INFO-Meldung an alle angemeldeten Clients weitergeleitet. An den Anfrager selber sollte die INFO-Meldung jedoch nicht weitergeleitet werden.

Anmerkung: Durch das generelle Weiterleiten der INFO-Meldung weiß der Client, das (und wann) seine Botschaft rausgegangen ist. Deshalb wird auch dieser Punkt gestrichen.

• Ein Client sollte selber darüber entscheiden, ob er CRCF-Broadcasts empfängt. Per Voreinstellung ist diese Option nicht aktiv. Wie das Ein- oder Ausschalten funktioniert, wäre zu diskutieren.

Glossar

CRCF-Broadcast

Eine von einem SRCP-Client in Form von "SET 0 GM <AntwortID> 0 CRCF CONFGET <messagetext>" initiierte Rundrufnachricht, die der SRCP-Server über den INFO-Kanal an alle angeschlossenen SRCP-Clients weiterleitet.

CRCF-Client

Ein Client mit lokalen CRCF-Daten bzw. lokaler CRCF-Datenbank.