CRCF - Common Railroad Configuration Files 0.1: Unterschied zwischen den Versionen

Aktuelle Version vom 21. Februar 2006, 14:38 Uhr

Erster Entwurf zur Diskussion

von Edbert van Eimeren

1 Einleitung

Die CRCF beschreiben einen Reihe von Dateien zur Konfiguration von Serverprozessen zur Steuerung von digitalen Modelleisenbahnen. Clientprozesse können auf diese Informationen über einen entsprechenden Auskunftsbefehl zugreifen.

Die in CRCF zu speichernden Informationen ergeben sich aus dem Bedarf des SRCP (Simple Railroad Command Protocol) wie von Torsten Vogt & anderen definiert. In diesem Sinne sind die CRCF eine Ergänzung zum SRCP.

Ziel ist es eine klare, auch vom Menschen lesbare Basis für die Fähigkeiten einer konkreten Serverimplementierung einerseits und eine Beschreibung der verwendeten Dekoder mit ihren spezifischen Eigenschaften andererseits zu schaffen.

Diese Fassung basiert auf SRCP Version 0.7.0.

1.1 Konventionen

Alle Informationen werden einzeilig mit variabler Länge gespeichert. Eine Zeile wird mit dem Zeichen '\n' (line feed, LF, #10) abgeschlossen. Ein vorangestelltes '\r' (carriage return, CR, #13) wird akzeptiert. Jede Informationszeile besteht aus Worten, die durch Whitespace (Leerzeichen, Tabulatoren) getrennt sind.

Die Worte der Informationszeilen können aus der Menge der Zeichen { '0', .., '9', '-', 'A', .., 'Z', 'a', .., 'z' } gebildet werden. Der Server wertet die Informationszeilen case-sensitive aus, d.h. zwischen Groß- und Kleinbuchstaben wird unterschieden.

Kommentarzeilen beginnen mit dem Zeichen '#' und enden mit dem Zeilenende. Sie werden ebenso ignoriert wie Leerzeilen (nur White Spaces und CR, LF). Sie dürfen alle druckbaren Zeichen des ASCII Zeichensatzes enthalten. Sie dienen ausschliesslich der besseren Lesbarkeit durch einen Menschen.

Einzelne Bereiche werden durch Überschriften getrennt. Diese beginnen (Zeilenanfang) mit '= ' und enden mit ' ='. Weiterer Text in der Überschriftzeile ist Kommentar und wird ignoriert.

Alle Informationszeilen beginnen mit einer Kennung aus vier Buchstaben, die die Art der Information kennzeichnet. Die weiteren Angaben sind je nach Art der Information unterschiedlich. Informationen über Protokolle enthalten eine weitere Angabe zur genauen Identifizierung (Protokoll/Modultype). Informationen über Dekoder und Rückmelder enthalten zwei weitere Angaben zur genauen Identifizierung (Protokoll/Modultype + Adresse/Portnummer). Für jede vom Server unterstützte Funktion / Eigenschaft gibt es eine Informationszeile. Für jeden dem Server bekannten Dekoder / Rückmelder gibt es eine Informationszeile.

Informationszeilen, die unvollständig oder offensichtlich falsch sind werden vom Server ignoriert. Eine (summarische) Fehlermeldung sollte in diesem Fall vom Server beim Start ausgegeben werden. In Protokoll- oder Trace-Dateien kann ggfs. jeder Fehler einzeln aufgeführt werden.

Die Informationen sind in Bereiche aufgeteilt. Jeder Bereich hat eine Überschrift. Alle Informationen aus einem Bereich müssen hinter dieser Überschrift stehen. Stehen sie an einer anderen Stelle, so werden sie als Fehler gewertet. Innerhalb eines Bereichs ist eine angemessene Ordnung sinnvoll (Name | Protokoll | Adresse | ...). Diese Ordnung ist für die bessere Lesbarkeit und daher nicht zwingend vorgeschrieben. Es steht im Ermessen des Erstellers, welche Ordnung, wenn überhaupt, er/sie benutzt.

An einigen Stellen sind Werte reserviert, die im SRCP noch nicht festgelegt sind, da es zur Zeit noch keine Server gibt, die das unterstützen. Diese Werte sind als Platzhalter zu betrachten, sie können sich noch ändern. Solche reservierten Werte sind mit kursiver Schrift markiert.

Änderungen gegenüber der vorherigen Version werden mit einem farbigen Strich am rechten Rand markiert. Dabei bedeutet rot Neues oder wesentliche (inhaltliche) Änderungen, grün kleinere (textliche) Änderungen, und blau Weglassungen. Unveränderte Abschnitte haben eine graue Markierung. Korrekturen von Tipfehlern werden nicht markiert.
Da diese Version komplett neu ist, sind alle Abschnitte grau markiert. Die rote Markierung dieses Abschnittes, ebenso wie die grüne Markierung des Abschnitts #8 Änderungsprotokoll dient ledigich als Beispiel.

2 Servereigenschaften

Hier werden die Eigenschaften beschrieben, die eine Serverimplementierung ausmachen, das heißt, welche Möglichkeiten ein Server seinen Clients zur Verfügung stellt.

2.1 Serverversion

Überschrift: '= Version =' Es gibt genau eine Zeile mit der Information über die Version des Servers und des verwendeten SRCP.
	VERS <name> <vers> SRCP <srcp>
	<name>	Name des Servers
	<vers>	Version des Servers
	<srcp>	Version des verwendeten SRCP
	Hinweis:	Die Versionsinformation sollte als erstes in einer Konfigurationsdatei stehen.

2.2 Übertragungskanäle

Welche Kanäle werden von einer Serverimplementierung zur Kommunikation mit Clients benutzt. Dies ist durch das SRCP weitgehend festgelegt. Überschrift: '= Ports =' Für jeden Kanal gibt es eine Zeile des Formats:
	PORT <port> <direction>
Werte für <port> sind:
	COMMAND	Kommando Port Befehle des Clients an den Server, direkte Antworten des Servers darauf.
	FEEDBACK	Rückmelde Port Statusänderungen von Rückmelde Modulen.
	INFO	Info Port (Broadcast Kanal) Statusänderungen von Lok- und Schaltdekodern, Modellzeit.
Werte für <direction> sind:
	CLIENT	Unidirektional vom Client zum Server
	SERVER	Unidirektional vom Server zum Client
	BOTH	Bidirektional

2.3 Serverbefehle

Welche Befehle werden von einer Server zu seiner Steuerung akzeptiert. Dies ist durch das SRCP weitgehend festgelegt. Überschrift: '= Server Commands =' Für jeden Befehl gibt es eine Zeile des Formats:
	SCMD <command>
Werte für <command> sind:
	LOGOUT	Befehl zum Beenden der Verbindung zu einem Client.
	RESET	Befehl zur Neu-Initialisieung des Servers.
	SHUTDOWN	Befehl zum Beenden des Servers.
	VOLTAGE	Ein-/Ausschalten des Digitalstroms über STARTVOLTAGE/STOPVOLTAGE Kompatibilität zu früheren Versionen des SRCP
	POWER	Ein-/Ausschalten des Digitalstroms über SET POWER [ON/OFF] Aktueller Befehl in SRCP (ab Version 0.???)

2.4 Allgemeine Befehle

Welche Befehle werden von einer Server zu seiner Steuerung akzeptiert. Dies ist durch das SRCP weitgehend festgelegt. Überschrift: '= General Commands =' Für jeden Befehl gibt es eine Zeile des Formats:
	GCMD <command>
Werte für <command> sind:
	SET	Befehl zum Setzen eines Wertes.
	GET	Befehl zum Ermitteln eines Wertes.
	WAIT	Befehl zum Warten bis ein bestimmter Zustand erreicht wird.
	INIT	Befehl zum Initialisieren von Geräte(gruppen).
	TERM	Befehl zum Aufheben von mit INIT getroffenen Einstellungen.
	WRITE	Befehl zum Programmieren eines Wertes eines Dekoders.
	READ	Befehl zum Lesen eines Wertes eines Dekoders.
	VERIFY	Befehl zum Überprüfen eines Wertes eines Dekoders.
	CONFGET	Befehl zum Ermitteln von Konfigurationsinformationen.
Ein Befehl, der nicht eingetragen ist, wird nicht unterstützt. Lediglich der Befehl SET ist zwingend vorgeschrieben, alle anderen können implementiert werden. Der Befehl GET wird meistens unterstützt, der Befehl WAIT falls Rückmelder oder Modellzeit unterstützt werden. Die Befehle WRITE, READ, VERIFY dienen dem Programmieren von Dekodern. Sie werden nur dann unterstützt, wenn ein Server diese Funktionalität bereitstellt.

2.5 Protokolle Lokdekoder

Welche Protokolle für Lokdekoder werden von einem Server akzeptiert. Funktionsdekoder werden wie Lokdekoder behandelt. Dies ist zwar durch das SRCP festgelegt, jedoch muss ein Server nicht alle in SRCP beschriebenen Protokolle unterstützen (z.B. Ansteuerung einer systemspezifischen Zentraleinheit). Weiter sind bereits Werte für noch nicht unterstützte Protokolle reserviert. Überschrift: '= Protocols Loco & Function =' Für jedes unterstützte Protokoll gibt es eine Zeile des Formats:
	PRGL <prot> <addrmax> <speedmax> <dir> <n-func>
Werte für <prot> sind:
	M.	Protokolle nach den Märklin/Motorola Standards.
	N.	Protokolle nach den NMRA-DCC Standards.
	S.	Protokolle nach den Trix Selectrix Standards.
	F.	Protokolle nach den Fleischmann FMZ Standards.
	Z.	Protokolle nach den ZIMO Standards.
	Der Punkt ist durch geeignete Buchstaben/Ziffern zu ersetzen. Siehe dazu die aktuelle Spezifikation des SRCP. Die Werte für Selectrix, FMZ und ZIMO sind reserviert für zukünftige Entwicklungen (Intellibox, Twin-Box, ...). PS (= Protocol by Server) ist hier nicht aufgeführt, da es kein reales Protokoll ist, sondern eine Anweisung an den Server, selbständig ein geeignetes Protokoll zu wählen.
Wert für <addrmax>:
	Der Wert für <addrmax> gibt die höchste Adresse an, die von diesem Protokoll unterstützt wird. Aktuelle Werte für den Adressbereich sind 80, 99, 256, 9999. Ein Adressbereich beginnt immer bei der Adresse 0.
Wert für <speedmax>:
	Der Wert für <speedmax> gibt die höchste Fahrstufen an, die von diesem Protokoll unterstützt wird. Aktuelle Werte für die höchste Fahrstufe sind 14, 27, 28, 128. Ein Fahrstufenbereich beginnt immer bei der Fahrstufe 0.
Werte für <dir> sind:
	abs	Absolute Fahrtrichtungsangabe.
	rel	Relative Fahrtrichtungsangabe.
Wert für <n-func>:
	Der Wert für <n-func> gibt an wieviele Zusatzfunktionen von diesem Protokoll unterstützt werden. Aktuelle Dekoder untertützen 0, 2, 4, 8 Zusatzfunktionen. Es wird implizit davon ausgegeangen, dass eine Standardfunktion immer implementiert ist.

2.6 Protokolle Schaltdekoder

Welche Protokolle für Schaltdekoder werden von einem Server akzeptiert. Dies ist zwar durch das SRCP festgelegt, jedoch muss ein Server nicht alle in SRCP beschriebenen Protokolle unterstützen (z.B. Ansteuerung einer systemspezifischen Zentraleinheit). Weiter sind bereits Werte für noch nicht unterstützte Protokolle reserviert. Überschrift: '= Protocols Accessory =' Für jedes unterstützte Protokoll gibt es eine Zeile des Formats:
	PRGA <prot> <addrmax>
Werte für <prot> sind:
	N	Protokoll nach den Märklin/Motorola Standards.
	M	Protokoll nach den NMRA-DCC Standards.
	S	Protokoll nach den Trix Selectrix Standards.
	F	Protokoll nach den Fleischmann FMZ Standards.
	Z	Protokoll nach den ZIMO Standards.
Wert für <addrmax>:
	Der Wert für <addrmax> gibt die höchste Adresse an, die von diesem Protokoll unterstützt wird. Aktuelle Werte für den Adressbereich sind ???, 4096. Ein Adressbereich beginnt bei der Adresse 1.

2.7 Protokolle Rückmelde Module

Welche Rückmelde Module und Anschlussarten werden von einem Server akzeptiert. Dies ist zwar durch das SRCP festgelegt, jedoch muss ein Server nicht alle in SRCP beschriebenen Module oder Arten unterstützen. Weiter sind bereits Werte für noch nicht definierte Protokolle reserviert. Überschrift: '= Feedback Types =' Für jeden unterstützten Modultyp gibt es eine Zeile des Formats:
	PRFB <module-type> <port-max> <port-inc>
Werte für <module-type> sind:
	S88	Märklin s88-Bus am Parallelport des PC.
	I8255	i8255 Karte.
	M6051	Märklin s88-Bus via Interface 6051.
	LENZFB	Rückmelde-Module aus dem Lenz System.
	DTFB	Rückmelde-Module aus dem Digitrax System (LocoNet).
	SELFB	Rückmelde-Module aus dem Trix Selectrix System.
	FMZFB	Rückmelde-Module aus dem Fleischmann FMZ System.
	ZIMOFB	Rückmelde-Module aus dem ZIMO System.
	Hinweis:	Die letzten fünf sind reservierte Namen, die sich ggfs. noch ändern können.
Wert von <port-max>
	Der Wert von <port-max> gibt die höchste Adresse an, die für diesen Modultype zulässig ist. Ein Nummerbereich beginnt mit (0 \| 1) ???.
Wert von <port-inc>
	Der Wert von <port-inc> gibt an wieviele Ports in einem Modul dieses Typs zusammengefasst sind.

2.8 Sonstige Gerätetypen

Dies kann erst dann spezifiziert werden, wenn entsprechende Definitionen in SRCP vorliegen.

3 Geräte und ihre Eigenschaften

Hier werden die Eigenschaften beschrieben, die ein tatsächliches Gerät (Lok-, Schaltdekoder, Rückmeldemodul) hat. Das heißt, welche Funktionen von einem Dekoder oder Modul tatsächlich realisiert werden. Dies kann ggfs. weniger sein, als das Protokoll erlaubt.

3.1 Lok- und Funktionsdekoder

Überschrift: '= Locomotive & Function =' Für jeden definierten Lok- und Funktionsdekoder gibt es eine Zeile des Formats:
	DCGL <name> <prot> <addr> <speed> <dir> <n-func> <prog> [<type>]
Wert von <name>
	Der Wert von <name> ist ein eindeutiger Name für diesen Lok-/Funktions- Dekoder (z.B. die Loknummer). Der Name muss ein Wort sein. Das heisst er darf kein Leerzeichen oder Tabultorzeichen enthalten. Zur optischen Gliederung ist ggfs. das Zeichen '-' einzusetzen . Beispiele: "V188-003", "Berghexe", "Zuckersusi". Soll keine Name angegeben werden, ist stattdessen das Zeichen '-' zu verwenden.
Werte für <prot>:
	Die Werte für <prot> sind wie in #2.5 Protokolle Lokdekoder definiert.
Wert von <addr>:
	Der Wert von <addr> gibt die Adresse dieses Dekoders unter dem gewählten Protokoll an. Multiprotokolldekoder können demgemäss mehrere Einträge haben.
Wert für <speed>:
	Der Wert von <speed> gibt die höchste Fahrstufen an, die von diesem Dekoder unterstützt wird. Für Funktionsdekoder ist dieser Wert ggfs. auf 0 zu setzen.
Werte für <dir> sind:
	abs	Absolute Fahrtrichtungsangabe.
	rel	Relative Fahrtrichtungsangabe.
Wert von <n-func>:
	Der Wert für <n-func> gibt an wieviele Zusatzfunktionen von diesem Dekoder unterstützt werden. Es wird implizit davon ausgegeangen, dass eine Standardfunktion immer implementiert ist.
Der Wert von <prog> ist ein Wort mit 7 Buchstaben:
	1)	Modus (P = Programmiergleis, F = on the Fly [im Betrieb])
	2)	WRITE- Befehl (W = unterstützt)
	3)	READ- Befehl (R = unterstützt)
	4)	VERIFY-Befehl (V = unterstützt)
	5)	REGISTER (R = unterstützt)
	6)	VARIABLE (V = unterstützt)
	7)	BIT (B = unterstützt)
	Wird eine Funktion nicht unterstützt, so ist statt dessen das Zeichen N (= none) zu setzen. Beispiele: Ein Dekoder, der nur Register auf dem Programmiergleis schreiben kann, erhält die Zeichenkette "PWNNRNN". Ein Dekoder, der Register und Variablen im laufenden Betrieb lesen und schreiben kann, erhält die Zeichenkette "FWRNRVN". Ein Dekoder, der nur über Mäuseklavier und Potis eingestellt wird, erhält die Zeichenkette "NNNNNNN".
Wert von <type>:
	Der Wert von <type> ist eine Kennung für den Dekodertype. Dekoder des gleichen Typs erhalten den gleichen Wert für <type>. Der Wert von <type> muss ein Wort sein. Das heisst er darf kein Leerzeichen oder Tabultorzeichen enthalten. Zur optischen Gliederung ist ggfs. das Zeichen '-' einzusetzen. Sinnvollerweise hält man sich an die Bezeichnung des Hersteller. Die Angabe dient zur Zeit nur der Dokumentation und ist daher optional.

3.2 Schaltdekoder

Überschrift: '= Accessory =' Für jeden definierten Schaltdekoder gibt es eine Zeile des Formats:
	DCGA <name> <prot> <addrmin> <addrmax> [<type>]
Wert von <name>:
	Der Wert von <name> ist ein eindeutiger Name für diesen Lok-/Funktions- Dekoder (z.B. die Loknummer). Der Name muss ein Wort sein. Das heisst er darf kein Leerzeichen oder Tabultorzeichen enthalten. Zur optischen Gliederung ist ggfs. das Zeichen '-' einzusetzen . Beispiele: "V188-003", "Berghexe", "Zuckersusi". Soll keine Name angegeben werden, ist stattdessen das Zeichen '-' zu verwenden.
Werte für <prot> sind:
	Die Werte für <prot> sind wie in #2.6 Protokolle Schaltdekoder angegeben.
Wert von <addrmin>:
	Der Wert von <addrmin> gibt die die Adresse des ersten verwendeten Ausgang dieses Dekoders an.
Wert von <addrmax>:
	Der Wert von <addrmax> gibt die die Adresse des letzten verwendeten Ausgang dieses Dekoders an.
Wert von <type>:
	Der Wert von <type> ist eine Kennung für den Dekodertype. Dekoder des gleichen Typs erhalten den gleichen Wert für <type>. Der Wert von <type> muss ein Wort sein. Das heisst er darf kein Leerzeichen oder Tabultorzeichen enthalten. Zur optischen Gliederung ist ggfs. das Zeichen '-' einzusetzen. Sinnvollerweise hält man sich an die Bezeichnung des Hersteller. Die Angabe dient zur Zeit nur der Dokumentation und ist daher optional.
Hinweis:
	Für einen Einzeldekoder gilt <addrmin> = <addrmax> Auf diese Art kann je nach Wunsch eine Gruppendefiniton oder eine Einzeldefinition der Schaltdekoderausgänge erfolgen.

3.3 Rückmelde Module

Überschrift: '= Feedback Units =' Für jede definierte Rückmelde Modul gibt es eine Zeile des Formats:
	DCGA <name> <modul-type> <port-min> <port-max> [<type>]
Wert von <name>:
	Der Wert von <name> ist ein eindeutiger Name für dieses Rückmelde Modul. Der Name muss ein Wort sein. Das heisst er darf kein Leerzeichen oder Tabultorzeichen enthalten. Zur optischen Gliederung ist ggfs. das Zeichen '-' einzusetzen. Beispiele: "V188-003", "Berghexe", "Zuckersusi". Soll keine Name angegeben werden, ist stattdessen das Zeichen '-' zu verwenden.
Werte für <modul-type>:
	Der Wert von <modul-type> gibt Art des verwendeten Modules an. Es gelten die Werte, die in #2.7 Protokolle Rückmelde Module dafür definiert sind.
Wert von <port-min>:
	Der Wert von <port-min> gibt die Portnummer des ersten verwendeten Eingang dieses Modules an.
Wert von <port-max>:
	Der Wert von <port-max> gibt die Portnummer des letzten verwendeten Eingang dieses Modules an.
Wert von <type>:
	Der Wert von <type> ist eine Kennung für den konkreten Typ eines Rückmelde Modules. Hier dient er hauptsächlich zur Unterscheidung verschiedener Lieferanten eines Modultypes. Rückmelder des gleichen Typs erhalten den gleichen Wert für <type>. Der Wert von <type> muss ein Wort sein. Das heisst er darf kein Leerzeichen oder Tabultorzeichen enthalten. Zur optischen Gliederung ist ggfs. das Zeichen '-' einzusetzen. Sinnvollerweise hält man sich an die Bezeichnung des Hersteller. Die Angabe dient zur Zeit nur der Dokumentation und ist daher optional.
Hinweis:
	Mit <port-min> = <port-max> kann man falls gewünscht auch jeden Port einzeln definieren.

4 Sonstiges

Dies ist erst einmal ein Platzhalter für zukünftige Erweiterungen oder Festlegungen, die übergreifend sind. Beispielsweise könnte ich mir hier eine Liste von Rückgabewerten vorstellen, wenn das INFO Statement als Antwort auf einen GET Befehl keine Daten zur Verfügung stellen kann.

Beispiel: INFO <value> <lang> <Text>

Dabei ist <value> der Rückgabewert (eine Zahl, in der Regel negativ), <lang> eine Sprache (z.B. de := deutsch, en := englisch). Alle weiteren Worte in dieser Zeile sind dann der Meldungstext. Das Paar <value>, <lang> muss eindeutig sein. Werden mehrere Sprachen angeboten, so sind für jede Sprache alle möglichen Werte von <value> mit Text zu versehen.

5 Abfrage der Konfiguration

Der Befehl CONFGET dient dazu, Clients die Möglichkeit zu geben beim Server nachzufragen, welche Fähigkeiten er hat (siehe #2 Servereigenschaften). Diese Angaben sind verbindlich.

Als zweites kann mit diesem Befehl abgefragt werden, welche Lok-, Funktions-, Schalt-Dekoder und Rückmelde Module dem Server bekannt sind (siehe #3 Geräte und ihre Eigenschaften). Diese Information dient (mehreren) Clients dazu einen gleichen Informationsstand zu haben. Diese Informationen sind jedoch nicht verbindlich.

Die Informationen müssen nicht vollständig sein.
Nicht alle bekannten Loks müssen sich auf einer Anlage befinden.
Es können sich "Fremdloks" auf der Anlage befinden, die natürlich nicht in der Konfigurationsdatei beschrieben sind.

Informationen zu Schaltdekodern und Rückmeldern als ortsfeste Bauteile hingegen sollten (in der Regel) korrekt und vollständig sein.

Anmerkung:

Die Spezifikation des Befehl CONFGET gehört eigentlich in das SRCP
(Simple Railroad Command Protocol). Dies hier ist nur der erste Vorschlag.

5.1 Konfigurationstypen

Zur Zeit sind 10 verschiedene Konfigurationstypen definiert.
	VERS	<name> <vers> SRCP <srcp>
	PORT	<port> <direction>
	SCMD	<command>
	GCMD	<command>
	PRGL	<prot> <addrmax> <speedmax> <dir> <n-func>
	PRGA	<prot> <addrmax>
	PRFB	<module-type> <port-max> <port-inc>
	DCGL	<name> <prot> <addr> <spmax> <dir> <n-func> <prog> [<type>]
	DCGA	<name> <prot> <addrmin> <addrmax> [<type>]
	DCFB	<name> <module-type> <port-min> <port-max> [<type>]
Dabei haben die ersten vier keine weitere Identifikation, die nächsten drei Protokoll/Modultype als genauere Identifikation. Die letzten drei haben Protokoll/Modultype + Adresse/Portnummer als genauere Identifikation. Bei diesen ist jedoch als Besonderheit zwischen dem Konfigurationstyp und der genaueren Identifikation ein frei wählbarer - allerdings eindeutiger - Name eingefügt.

5.2 Befehl CONFGET

Das generelle Format des Befehls ist:
	CONFGET <conf-type> [<spec-1>] [<spec-2>]
Der Wert von <conf-type> ist der Typ der Information der angefordert wird (vier Zeichen Code):
	VERS, PORT, SCMD, GCMD,	Servereigenschaften
	PRGL, PRGA, PRFB,	unterstützte Protokolle [<spec-1>]
	DCGL, DCGA, DCFB,	Dekoder, Rückmelder [<spec-1>] [<spec-2>]
[<spec-1>] und [<spec-2>] sind genauere Identifikationen von Protokollen, Dekodern und Rückmeldern:
	Protokoll / Modultype	für Protokolle, (PRGL, PRGA, PRFB)
	Protokoll + Adresse	für Lokdekoder, (DCGL)
	Protokoll + Portnummer	für Schaltdekoder, (DCGA)
	Modultype + Portnummer	für Rückmelder. (DCFB)
	Für die anderen Informationenstypen sind sie ohne Belang.
Hinweis:
	Für [<spec-1>], [<spec-2>] kann ein '' als Wildcard verwendet werden. Als Beispiel liefert "CONFGET DCGL NB " alle Lokdekoder zurück, die mit dem NMRA-DCC Basic Protokoll angesprochen werden.

5.3 Antwort auf CONFGET

Das generelle Format der Antwort ist:
	*INFO CONF <conf-type> [<spec-1>] [<spec-2>] [.]** [.*] steht dabei für alle weiteren Angaben entsprechend dem Konfigurationstyp.
Wird der Befehl CONFGET nicht unterstützt, lautet die Antwort:
	INFO -1
Sind keine Daten zu <conf-type> oder [<spec-x>] vorhanden, ist die Antwort:
	INFO -2
Hinweis:
	Die Antwort auf einen Befehl CONFGET kann mehrere Zeilen "INFO CONF ..." umfassen. Ein Client muss darauf vorbereitet sein, diese sinnvoll zu verarbeiten.

6 Zukünftige Entwicklungen

Auf der Basis des SRCP sind ja schon viele Entwicklungen angedacht. Hier ist der Platz um ihr Informationsbedürfnis festzulegen. Denkbar sind z.B Beschreibung einer Anlage und ihrer logischen Struktur (Blöcke, Fahrstrassen, Besetztmelder, ...) oder Informationen für den Fahrplanbetrieb (Züge, Fahrstrecke, Fahrzeittrassen, ...) und vieles andere.

7 Einige Anmerkungen

Hier will ich kurz Erklärungen zu einigen von mir vorgeschlagenen Punkten geben.

7.1 Hintergrund

In der Diskussion um das SRCP wurde mehrfach der Wunsch nach einer zentralen Konfigurationsbasis geäussert. Dies ist für eine einzige Serverimplementierung sicher nicht zwingend. Werden jedoch unterschiedliche Serverimplementierung angeboten, so ist es für alle weiteren Programme (Clients, Middleware, ...) sinnvoll, die Eigenschaften eines Servers ermitteln zu können.

Weiter wurde angeregt eine gemeinsame Datenbasis für alle Clients bezüglich Lokdekoder, Schaltdekoder und Rückmelder zu haben.

Beiden Wünschen soll mit dieser Definition Rechnung getragen werden.

7.2 Aufteilung

Bisher ist nichts zur Aufteilung der Konfigurationsdaten auf Dateien gesagt worden. Dieser Punkt ist bewusst offengelassen, da ich dafür keinen Vorschlag machen will. Sinnvoll ist sicherlich eine Aufteilung in eine Datei für die Servereigenschaften (siehe Kapitel 2) und eine Datei für die Dekoder und Rückmelder (siehe Kapitel 3). Sollte eines Tages Informationen über das Layout definiert werden, so ist dafür sicher eine weitere Datei sinnvoll.

Ob eine weitere Aufteilung wünschenswert ist soll die Diskussion zeigen.

7.3 Namen und Typen

Für die Definition der Dekoder und Rückmelder sind Namen eingeführt worden. Dies ist ein Konzept, dass im SRCP bisher nicht existiert und dort auch nicht notwendig ist. Es dient dazu, dass alle Clients Dekoder und Rückmelder mit gleichen Namen darstellen können.
Namen wie "V188-003" oder "Abzweig-Valkenburg" sind für einen Mensch als Benutzer der Clients sicherlich einfacher zuzuordnen als M3-17 oder N-327.

Ebenso sind Typen zur Klassifizierung verschiedener Dekoder- / Rückmeldertypen eingeführt worden. Auch diese sind in SRCP weder definiert noch notwendig. Sie dienen hauptsächlich der Dokumentation. Inwieweit ein Client diese Information verwendet bleibt ihm überlassen.

7.4 Englische Begriffe

Genauso wie im SRCP werden in der formalen Definition englische Begriffe bzw. Abkürzungen davon verwendet. Dies wurde in SRCP in Hinblick auf eine mögliche internationale Verbreitung so beschlossen. Ich schliesse mich diesem Vorgehen an.

8 Änderungsprotokoll

Hier wird in späteren Versionen eine Übersicht über die wichtigsten Änderungen von Version zu Version stehen.