DerMoba - Benutzerbeiträge [de]

Digitalzentralen - aktuelle Systeme

2009-04-02T19:09:32Z

Michael Oppenauer: /* Vollsysteme */ ECos

[[Kategorie:Digitalbetrieb]]

'''Übersicht der aktuell verfügbaren Digitalzentralen.'''

{{Zentralverweise}}

 

Dieser Artikel ist nach einfachen, mittleren und vollen Systemen unterteilt.
Diese Gliederung dient dazu, die Dinge einigermaßen übersichtlich zu halten.
Innerhalb der einzelnen Abschnitte sind die Systeme alphabetisch nach dem Namen des Herstellers sortiert.

== Einsteiger-Zentralen ==

Einfache Zentralen, mit reduziertem Funktionsumfang.

<div style="font-size:0.8em">
{{Zentraltipps}}

{| {{Zentraltabelle}}
{{Zentralheader}}

|-
| Fleischmann '''LokBoss'''
| DCC
| 0 / 1 (max. 4)
| 4 LEDs, Adr. 1–4
| 1,8A, 20,3V (-) || -
| [[LocoNet]] / -
| Adr. 1-4 / nein
| nein
| - / [[LocoNet]]
| nein
| Einfachst-Regler am LocoNet (Adr. 1–4). Zusatzregler = LokBoss oder FMZ–Regler (seit 2003/4)

|-
| Piko '''Digi-1'''
| DCC
| 0 / 1 (max. 4)
| nein
| 1,8A, 20,3V (-) || Gleissignal
| Iris (Infrarot) / nein
| Adr. 1-127, 28 Fahrst. / nein
| nein
| - / -
| nein
| Digi-Fern = Uhlenbrock Iris, max. 12 Loks aktiv (seit 2004/5)

{{Zentralheader}}

|}
</div>

 

== Zentralen mit Einschränkungen ==

Zentralen, die einen Großteil des Funktionsumfanges der jeweiligen Protokolle unterstützen, aber aufgrund bestimmter Einschränkungen nicht für den Betrieb großer Anlagen geeignet sind.

<div style="font-size:0.8em">
{{Zentraltipps}}

{| {{Zentraltabelle}}
{{Zentralheader}}

|-
| Bachmann '''EZ Command Dynamis'''
| DCC
| 0 / 1 (IR)
| LCD Display Beleuchtet
| 2.5A, 15.5V (+) || ja (über Pro-Box)
| {{r}}, IR / {{r}}
| POM / {{r}}
| 40 á 5 Loks
| - / ja
| {{r}}
| JoyStick BiDi vorbereitet, Erweiterung über Pro–Box (seit Dez. 2007)

|-
| Digitrax '''Zephyr'''
| DCC
| 1 / 0 {{A1}}
| 4–stellig
| 2.5A, 12.8V (+) || [[LocoNet]]
| [[LocoNet]] / [[LocoNet]]
| POM+Prog, bis 255 / Prog-Gleis
| Zentrale, Decoder
| - / ja
| nein
| max. 10 Loks aktiv, Fahrregler / Booster am [[LocoNet]]. (seit 2002/3)

|-
| Fleischmann '''Profi-Boss'''
| DCC
| 0 / 1
| LCD Display Beleuchtet
| 1.8A, 18V (+) || [[LocoNet]]
| [[LocoNet]] / [[LocoNet]]
| POM+Prog / Prog-Gleis
| nein
| nein / ja
| Twin Center
| max. 16 Loks aktiv, Handregler am [[LocoNet]]. (seit Mitte 2008)

|-
| Hornby '''Select'''
| DCC
| 1 / 0
| 2 Ziffern
| 1/3A, 15V ({{r}}) || ja (RJ12)
| X–Bus / -
| ja / {{r}}
| Doppel Traktion
| - / ja
| {{r}}
| bis 10 Loks aktiv, Adr. 1-59 (Loks), 60-99 (Weichen) (seit Dez. 2007)

|-
| Hornby '''Elite'''
| DCC
| 2 / 0
| LCD Display
| 3A, 15V ({{r}}) || 5-polig, Gleis-Signal, (RJ12)
| X–Bus / -
| POM+Prog / Prog-Gleis
| Doppel Traktion
| USB / ja
| PC
| BiDi (RailCom) vorbereitet, 254 Lok + 255 Weichen Adressen (seit Dez. 2007)

|-
| LGB '''MZS II'''
| DCC (Basic)
| 0 / 0
| LEDs
| 5A, {{r}}V ({{r}}) || ja, max. 4
| LGB-Bus / LGB-Bus {{A2}}
| nur Adresse / -
| nur mit Universal Handy
| - / ja
| nein
| Großbahn, 23 Adr. 14 Fahrst., max. 8 Loks aktiv ''(Nachfolge: MZS III)'' (seit 200?)

|-
| Littfinski Datentechnik '''DiCoStation'''
| DCC, MM
| 0 / 0
| 2 LED
| - || 5-polig
| - / 3x [[S88-Rückmeldebus|S88]]
| {{r}} / {{r}}
| {{r}}
| USB / -
| PC
| '''kein BiDi''', Prog-Gleis nur über Erweiterung, braucht PC–Steuerung (seit Mitte 2007)

|-
| MärklinSystems '''MobileStation'''
| mfx, MM
| 0 / 1
| LCD Screen
| 1.2A/1.9A, {{r}}V ({{r}}) || nein
| {{r}} / {{r}}
| ja / ja
| kein
| - / -
| {{r}}
| max. 10 Loks aktiv, MM: nur 80 Adr., 14 Fahrst. (seit 2004)

|-
| Roco '''MultiMaus''' ((+Verstärker))
| DCC
| 0 / 1
| LCD Display Beleuchtet
| ((3/3.2A, {{r}}V ({{r}}))) || ja
| X–Bus / {{r}}
| POM+Prog, bis 255 / nein*
| nein
| - / ja
| Rocomotion + PC
| Handregler am X–Bus, *Verstärker ungeeignet. (seit 2006)

|-
| Trix Systems '''MobileStation'''
| DCC, SX
| 0 / 1
| LCD Screen
| 1.9A, {{r}}V ({{r}}) || nein
| {{r}} / kein
| bis 999 / bis 999
| {{r}}
| - / -
| Central Station+PC / zweite MS
| max. 16 Loks aktiv (seit 2006)

{{Zentralheader}}

|}
'''Anmerkungen:'''
# Am JumpPort des Digitrax Zephyr können 1 oder 2 Analog-Fahrregler angeschlossen werden, die je eine zugewiesen Digital-Lok steuern.
# Der LGB-Bus basiert wahrscheinlich auf einer älteren X–Bus Version.
</div>

 

== Vollsysteme ==

Zentralen, die den vollen Funktionsumfang der jeweiligen Protokolle unterstützen und zur Steuerung großer bis sehr großer Anlagen geeignet sind.

<div style="font-size:0.8em">
{{Zentraltipps}}

{| {{Zentraltabelle}}
{{Zentralheader}}

|-
| CT-Elektronik '''ZF5 + HR3'''
| DCC, MM
| 0 / 1
| LED (ZF5), LCD 128x64 (HR3)
| 1-5A, 10-21V (+) || 3-polig
| X–Bus / {{r}}
| POM+Prog/ Prog-Gleis
| ja, 100x6 Loks
| RS232 / -
| PC
| HR3 steuert 2 Loks, BiDi und Selectrix geplant. (seit 2006/7)

|-
| Digitrax  '''SuperChief''' (DCS100/200 + DT400)
| DCC, (MM1)
| 0 / 1
| LED (DCS...), LCD 2 Zeilen (DT400)
| 5/8A, 12/15/20V (+) || [[LocoNet]]
| [[LocoNet]] / [[LocoNet]]
| POM+Prog/ Prog-Gleis
| Dekoder, Zentrale
| - / ja
| Prozessor tauschen
| Für extreme Anforderungen: 120 aktive Loks/Fahrregler, DT400=2 Loks, DCS200=8A (seit 1995/6)

|-
| ESU '''ECoS'''
| DCC, BiDi, MM, SX, mfx (M4)
| 2 / 0 {{A1}}
| Touch Screen, 320x240
| 2-4A, {{r}}V ({{r}}) || 3/5-polig, ECoSLink {{A2}}
| ECoSLink, ECoSniffer / [[S88-Rückmeldebus|S88]]
| POM+Prog/ POM+Prog
| Zentrale, 32x16 Loks
| Ethernet / -
| PC
| '''BiDi''' (seit 11/2007). '''Version 3''' +mfx, +Gleisbild (seit 04/2009). (seit Mitte 2006)

|-
| Fleischmann '''Twin Center'''
| DCC, FMZ, SX
| 2 / 0
| LCD, 2x16 Zeichen
| 3A, N=18V, H0~21V (-) || 3+5-polig, FMZ
| [[LocoNet]], I2C, Lokmaus1 / [[LocoNet]], [[S88-Rückmeldebus|S88]]
| POM+Prog/ Prog-Gleis
| Zentrale, 8x4 Loks
| RS232 / ja
| PC
| auch für FMZ Decoder, Hardware basiert auf Intellibox von Uhlenbrock (seit Ende 2000)

|-
| Lenz '''LZV100'''
| DCC, BiDi
| 0 / 0
| LED (Status)
| 5A, 11-22V ({{r}}) || 3-polig
| X–Bus / RS–Bus
| POM+Prog/ POM+Prog
| Decoder
| - / ja
| EPROM Austausch
| '''BiDi''' (RailCom) ab Version 3.5 (seit ca. 2003)

|-
| Massoth '''DiMAX 800Z'''
| DCC
| 0 / 0
| LCD, 4 Zeilen
| 2/4/8A, 16-24V (+) || ja
| Control–Bus/ Control–Bus {{A3}}
| Prog-Gleis/ Prog-Gleis
| Zentrale, 16x4 Loks
| RS232
| PC
| für Großbahnen und kleinere Baugrößen (seit ca. 2005)

|-
| Massoth '''DiMAX 1200Z'''
| DCC
| 0 / 0
| LCD, 4 Zeilen
| 4/7/12A, 22-24V (+) || Massoth, LGB, 3-polig
| Control–Bus/ Control–Bus {{A3}}
| Prog-Gleis/ Prog-Gleis
| Zentrale, 16x4 Loks
| RS232
| PC
| nur für Grossbahn, Trafo eingebaut (seit 2003/4)

|-
| Märklin '''Central Station 2'''
| mfx, MM, ''DCC''
| 2 / 0
| Touch Screen, Farbe, 800x480
| 3A, {{r}}V ({{r}}) || 5-polig, Märklin-Bus
| Märklin-Bus {{A4}} / [[S88-Rückmeldebus|S88]]
| ja / mfx Decoder
| Zentrale
| Ethernet
| PC, USB-Stick, Internet
| Gleisbild, Lokkarten, mehrere CS2 koppelbar, USB-Maus/-Tastatur, ''DCC ab Version 1.0.7 (11/2008)'' (seit 10/2008)

|-
| Müt Digirail '''multi control 2004'''
| SX
| 1 / 0
| LCD Matrix
| 2.7A, {{r}}V ({{r}}) || ja
| SX–Bus (2x) / SX–Bus
| ja / ja
| Zentrale, 20x5 Loks
| RS232
| PC
| (seit ca. 2000/1)

|-
| Piko '''Digi Power Box'''
| DCC
| 2 / 0
| LCD, 2x16 Zeichen
| 3A, N=18V, H0~21V (-) || 3-polig
| [[LocoNet]], Iris / [[LocoNet]]
| ja / ja
| bis zu 4 Loks
| RS232 / ja
| PC
| Hardware basiert auf Intellibox IR von Uhlenbrock (seit ca. 2005)

|-
| Rautenhaus Digital '''SLX850'''
| SX, DCC
| 0 / 0
| -
| 1.5A, {{r}}V ({{r}}) || ja
| SX–Bus / SX–Bus
| ja / ja
| ja
| -/ja
| Processor Update möglich
| DCC: nur 8 Adr., 28 Fahrst., 4 Funkt. ''Nachfolger: SLX850AD'' (seit {{r}})

|-
| Tams '''EasyControl'''
| DCC, BiDi, MM
| 1 / 0
| LCD, 2x16 Zeichen
| - || 3+5-polig
| EasyNet / [[S88-Rückmeldebus|S88]]
| POM+Prog/ Prog-Gleis
| Doppel Traktion
| USB und RS232 / -
| PC
| MM 14/27 Fahrst. 255 Adr., 2ter Booster Ausgang, '''BiDi''' (RailCom) ab V1.45 (seit 2005/6)

|-
| Uhlenbrock '''Intellibox IR''' {{A5}}
| DCC, MM, SX
| 2 / 0
| LCD, 2x16 Zeichen
| 3A, N=18V, H0~21V (-) || 3/5-polig, [[LocoNet]]
| [[LocoNet]], I2C, LM1, IRIS / [[LocoNet]], [[S88-Rückmeldebus|S88]]
| POM+Prog/ Prog-Gleis
| Zentrale, 8x4 Loks
| RS232 / ja
| PC
| MM bis 255 Adressen, LM1: Lokmaus1 (seit 1998, IB-IR 2005)

|-
| Uhlenbrock '''Intellibox Basic''' {{A5}}
| DCC, MM
| 2 / 0
| LCD, 2x16 Zeichen
| 3A, N=18V, H0~21V (-) || 3-polig, [[LocoNet]]
| [[LocoNet]] / [[LocoNet]]
| POM+Prog/ Prog-Gleis
| Doppel Traktion
| USB / ja
| PC
| Max. 32 Loks aktiv, DCC 9999 Funkt., MM 255 Adr. / 14 Fahrst. ''Ohne IR, I2C, [[S88-Rückmeldebus|S88]], Selectrix, Fahrstraßen, Multitraktion''. (seit 12/2008)

|-
| Viessmann '''Commander'''
| DCC, MM
| 2 / 0
| Touch Screen, Farbe, 800x480
| 3A, {{r}}V ({{r}}) || 3+5-polig
| HSB+LSB {{A6}} / [[S88-Rückmeldebus|S88]], LSB
| ja / ja
| ja
| USB
| PC
| Automatik, Gleisbild, Stellpult, mehrere Com. koppelbar, BIDi ab 2009 (seit 12/2007)

|-
| Zimo '''MX31ZL'''
| DCC, BiDi
| 1 / 0
| LCD Display
| 1-3A {{A7}}, 12-19V (+) || ja
| CAN Bus / CAN Bus
| POM+Prog/ POM+Prog
| ja
| USB / ja
| PC oder USB-Stick
| USB–Interface für MX1*, Decoder Updates, '''BiDi''' eingebaut (seit 10/2007)

|-
| Zimo '''MX1, MX1EC, MX1HS''' (Modell 2000)
| DCC, MM
| 0 / 0
| LCD 2 Zeilen
| 8A, 12-24V (+) || 3-polig, CAN Bus
| CAN Bus / CAN Bus
| POM+Prog/ Prog-Gleis
| ja
| RS232 / ja
| PC
| HS: Hochstrom (2x8A), EC: Economy (ohne LCD), BiDi ab 2009 (seit 2000/1)

{{Zentralheader}}

|}
'''Anmerkungen:'''
# Die Märklin MobilStation kann als Handregler an die ECoS-Zentrale von ESU angeschlossen werden. Die Trix MobileStation ist weder zur Märklin CentralStation1 noch zu ECoS kompatibel.
# Nur mit ECoS Boostern können das SX-Protokoll verstärkt und Rückmeldungen (BiDi/mfx) an die Zentrale (ECoS oder CentralStation1) weiter gereicht werden.
# Der Massoth Control-Bus basiert wahrscheinlich auf einer X–Bus Version. Massoth-Protokoll (=DCC) ab 2005, davor LGB-kompatibel (MZS II).
# Der Märklin-Bus der CentralStation2 (CS2) verwendet (wie ESU, Zimo, ...) CAN als Hardware-/Protokoll-Basís. Der Bus der CentralStation1 (CS1) hatte Gemeinsamkeiten mit ESUs ECoSLink (z.B. Booster-Anschluss). Ob und wie weit das auch für den Märklin-Bus der CS2 gilt, ist zur Zeit unklar.
# Intellibox Basic und Intellibox II können als Fahrregler + Keyboard + Booster am LocoNet verwendet werden. Mit dem Software Upgrade 2.0 erhält auch die bewährte Intellibox (IB/IB–IR) diese Funktionalität (+9999 Funktionen, +Fahrstraßensteuerung).
# Der Viessmann LowSpeedBus (LSB) unterstützt X–Bus Geräte wie Roco Rückmelder/Lokmaus2/MultiMaus oder Lenz Handregler.
# Mit dem stabilisierten, einstellbaren 120W Netzteil kann das MX31ZL bis zu 4A liefern.
</div>

SRCP-Erweiterungen

2009-02-24T13:06:38Z

Michael Oppenauer: /* Erweiterung des bisherigen Befehlsvorrats */ Attribute für rekursive Aufrufe hinzugefügt

==Das initiale Posting==

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 [[Digitalprojekt|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:

# 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.
# 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.

Es gab eine rege Beteiligung an der Diskussion, beide Ideen wurden darin ausführlich diskutiert.

==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.

{| border="1" align="center" width="50%"
|+
! SRCP-Interessierter
! Wohnort

|-
| Sven Schlender
| Karlsruhe

|-
| Stefan Bormann
| Bremen

|-
| Guido Scholz
| Burgkirchen

|-
| ...
| ...
|}

==SRCP-Server-Suchdienst==
Sehr schnell kam der Vorschlag, für diesen Bedarf einen [http://www.zeroconf.org/ 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:

* [http://www.apple.com/macosx/features/bonjour/ Bonjour], von Apple für Mac, UNIXoide-Systeme und Windows.
* [http://avahi.org/ 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 [http://www.iana.org/ 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_0.2.0|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===
[[Bild:Crcf-old.png|framed|Nachrichtenfluß gemäß der CRCF-Spezifikation Version 0.2.0. CS: COMAND-Sitzung]]
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====
[[Bild:srcp-crcf-client.png|framed|Nachrichtenfluß bei einem Betrieb mit einem als CRCF-Server arbeitenden SRCP-Client. CS: COMAND-Sitzung, IS: INFO-Sitzung]]
Ü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====
[[Bild:srcp-crcf-server.png|framed|Nachrichtenfluß bei einem Betrieb mit getrennten SRCP- und CRCF-Servern. CS: COMAND-Sitzung, IS: INFO-Sitzung, ...: nicht geklärt]]
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====
[[Bild:Crcf-client-server.png|framed|Nachrichtenfluß bei einem Betrieb mit als CRCF-Servern und -Clients arbeitenden SRCP-Clients. CS: COMAND-Sitzung, IS: INFO-Sitzung]]
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 [http://en.wikipedia.org/wiki/UUID UUID] gemäß [http://tools.ietf.org/rfc/rfc4122.txt 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 ([http://www.ietf.org/rfc/rfc2396.txt 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)

==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:

# Der Wert ist 0: Rundruf (Broadcast)
# 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 ....

[[Bild:SRCP_GM.png|framed|Nachrichtenfluß über Generic Messages. CS: COMMAND-Sitzung, IS: INFO-Sitzung]]
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.

* <del>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.</del>
Anmerkung: Es gibt bereits genügend SRCP-Kommandos, um Informationen direkt beim Server zu erfragen. Dieser Punkt ist daher irrelevant.

* <del>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.</del>
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.

[[Kategorie:SRCP]]

Gattungszeichen

2009-02-21T17:21:20Z

Michael Oppenauer: Erweiterung auf Güterwagen

=Güterwagen=

Eine umfassende Liste der verschiedenen Gattungszeichen findet man unter: http://home.wtal.de/gueterwagen/gzde.htm

=Reisezugwagen=

Eine umfassende Liste der verschiedenen Gattungszeichen findet man unter: http://www.leo.org/information/freizeit/bahn/gattungszeichen.html

A = 1. Kl.

Ap = Wagen der Bauart "Rheingold" mit Pullmannbestuhlung und Klimaanlage

Av = Wagen Bauart "Rheingold" mit Abteilen, größere Abteillänge und Klimaanlage

B = 2. Kl.

Bc = Liegewagen 2. Kl.

C = 3. Kl.

Cl = Liegewagen 3. Klasse

Diese mit 2. Zeichen "R" = Halbspeisewagen oder Barwagen

Pw (bis 1961) = Gepäckwagen

D = ab 1961 Gepäckwagen, mit A oder B oder C Gepäckabteil

DD = Doppelstock-Autotransportwagen für "Auto im Reisezug"

WR = Vollspeisewagen

WL = Schlafwagen

WG = Gesellschaftswagen für Sonderverkehr

Kein Nebengattungszeichen = Abteilwagen ohne Übergangsmöglichkeit

i = Wagen mit offenem Übergang und Seiten- oder Mittelgang

ü = Wagen mit Faltenbalg und Seitengang

üm = Wagen mit Faltenbalg und Seitengang mit Länge ab 26m (nicht 26,4!), das g entfiel ab 1965 bei allen m-Wagen

g = Wagen mit geschlossenem Übergang als Gummiwulst (ergänzt jeweils ü, üp, üm und y, entfiel bei m ab 1965)

y = (um 1951 noch üp) Wagen mit Mittelgang und geschlossenem Übergang

t = Spezialeinrichtung für Reisebüroverkehr (nur bei Bc und WR)

e = elektrische Heizung

h = Klimatisierung

w = in Verbindung mit ü Polstersitze in der 3. Klasse

s = nur bei WL "Spezial-1-Bett-Abteil)

f = Befehlsstand für geschobene Züge

b = Befehlssteuerleitung (bei 3yge, 4ymg, 4n, i und v)

v = als Nebengattunsgzeichen Beiwagen zu Verbrennungstriebwagen (nicht zu verwechseln mit dem Hauptgattungszeichen Av)

el = Beiwagen zu Elektrotriebwagen (selten, auslaufend, bei den B4yge nicht mehr benutzt)

[[Kategorie:Vorbild]]

Gattungszeichen Reisezugwagen

2009-02-21T17:19:47Z

Michael Oppenauer: Gattungszeichen Reisezugwagen wurde nach Gattungszeichen verschoben

#redirect [[Gattungszeichen]]

Gattungszeichen

2009-02-21T17:19:45Z

Michael Oppenauer: Gattungszeichen Reisezugwagen wurde nach Gattungszeichen verschoben

Eine umfassende Liste der verschiedenen Gattungszeichen findet man auch unter: http://www.leo.org/information/freizeit/bahn/gattungszeichen.html

A = 1. Kl.

Ap = Wagen der Bauart "Rheingold" mit Pullmannbestuhlung und Klimaanlage

Av = Wagen Bauart "Rheingold" mit Abteilen, größere Abteillänge und Klimaanlage

B = 2. Kl.

Bc = Liegewagen 2. Kl.

C = 3. Kl.

Cl = Liegewagen 3. Klasse

Diese mit 2. Zeichen "R" = Halbspeisewagen oder Barwagen

Pw (bis 1961) = Gepäckwagen

D = ab 1961 Gepäckwagen, mit A oder B oder C Gepäckabteil

DD = Doppelstock-Autotransportwagen für "Auto im Reisezug"

WR = Vollspeisewagen

WL = Schlafwagen

WG = Gesellschaftswagen für Sonderverkehr

Kein Nebengattungszeichen = Abteilwagen ohne Übergangsmöglichkeit

i = Wagen mit offenem Übergang und Seiten- oder Mittelgang

ü = Wagen mit Faltenbalg und Seitengang

üm = Wagen mit Faltenbalg und Seitengang mit Länge ab 26m (nicht 26,4!), das g entfiel ab 1965 bei allen m-Wagen

g = Wagen mit geschlossenem Übergang als Gummiwulst (ergänzt jeweils ü, üp, üm und y, entfiel bei m ab 1965)

y = (um 1951 noch üp) Wagen mit Mittelgang und geschlossenem Übergang

t = Spezialeinrichtung für Reisebüroverkehr (nur bei Bc und WR)

e = elektrische Heizung

h = Klimatisierung

w = in Verbindung mit ü Polstersitze in der 3. Klasse

s = nur bei WL "Spezial-1-Bett-Abteil)

f = Befehlsstand für geschobene Züge

b = Befehlssteuerleitung (bei 3yge, 4ymg, 4n, i und v)

v = als Nebengattunsgzeichen Beiwagen zu Verbrennungstriebwagen (nicht zu verwechseln mit dem Hauptgattungszeichen Av)

el = Beiwagen zu Elektrotriebwagen (selten, auslaufend, bei den B4yge nicht mehr benutzt)

[[Kategorie:Vorbild]]

Digitalprojekt

2009-02-12T13:19:55Z

Michael Oppenauer: /* SRCP-Clients */ Downloadlink zu nmra-programmer

= Einleitung =

Am '''DER_MOBA''' Digitalprojekt arbeiten derzeit viele Entwickler, die sich über die Newsgroup '''de.rec.modelle.bahn''' koordinieren. Ziel ist die Schaffung eines modularen und skalierbaren - d.h. an die jeweiligen Anforderungen anpassbaren - Digitalsystems zur [[Modellbahnsteuerung]]. Einzelne Komponenten dieses nach dem Client-Server-Prinzip aufgebauten Systems können
ausgetauscht bzw. je nach Anforderung bausteinartig zusammengestellt werden.
Der Informationsaustausch der einzelnen Programme untereinander erfolgt über ein speziell für
diesen Zweck erfundenes Protokoll (SRCP = [[SRCP-Grundlagen | Simple Railroad Command Protocol]]). Mit den Details
dieser Sprachdefinition muß sich ein Anwender allerdings genausowenig auseinander setzen,
wie ein E-Mail-Verfasser mit SMTP (Simple Mail Transfer Protocol). Wichtig ist lediglich,
dass die eingesetzten Programme die gleiche Sprache sprechen.

Ein Vorteil des hier eingesetzten Client-Server-Prinzips ist, dass die SRCP-Programme
grundsätzlich netzwerkfähig sind. Der Anwender ist damit nicht an einen einzelnen
Steuerungsrechner gebunden, wie das bei herkömmlichen Modellbahnsteuerungsprogrammen
in der Regel der Fall ist.

[[Bild:Srcp-clients.png|framed|Nachrichtenfluß zwischen der Modellbahn, einem SRCP-Server und verschiedenen SRCP-Clients]]
Ein funktionsfähiges SRCP-Digitalsystem besteht von der Software-Seite her aus mindestens zwei Programmen:

* Einem SRCP-Server und
* einem SRCP-Client

Der ''Server'' stellt die eigentliche Schnittstelle zur Hardware der Modellbahnanlage dar und kommuniziert entweder mit einer per [[Interface]] angeschlossenen [[Digitalzentrale]] oder - im Falle eines DigitalDirekt-Systems - direkt mit den [[Booster|Boostern]]. Er nimmt Steuerbefehle von SRCP-Clients entgegen und leitet diese an die Modellbahn weiter. Zusätzlich hält er die Clients über Statusänderungen der Modellbahn informiert.

Der ''Client'' kommuniziert mit Hilfe von SRCP-Kommandos nur mit dem Server und stellt in der Regel ein Steuerungs- oder Bedienprogramm dar. Das Konzept schließt ausdrücklich die gleichzeitige Verwendung mehrerer SRCP-Clients ein, die z.B. auf verschiedene Funktionalitäten (Lokomotivsteuerung, Stellwerk, Ablaufsteuerung etc.) spezialisiert sein können (siehe nebenstehende Abbildung).

Obwohl sehr viele, der derzeit verfügbaren SRCP-Programme, für das Betriebssystem Linux entwickelt wurden, ist das '''DER_MOBA''' Digitalprojekt grundsätzlich unabhängig von einem bestimmten Betriebssystem und der dafür notwendigen Hardware. Einige Programme laufen bereits jetzt auch unter anderen Betriebssystemen, andere können mit wenig Aufwand portiert werden.

Das '''DER_MOBA''' Digitalprojekt wird dezentral durchgeführt. Informationen zu den einzelnen Programmen werden üblicherweise vom jeweiligen Autor über dessen WWW-Seite angeboten. Diese Seite ist deshalb im wesentlichen eine Link-Liste, die einen Überblick über die verfügbare Soft- und Hardware bietet. Weitere Detailinformationen zum Protokoll z.B. für Programmentwickler befinden sich im Artikel [[SRCP-Grundlagen]].

 

= SRCP-Server =
== Projekte für den praktischen Einsatz ==

* '''DDW Server''' - DigitalDirekt-SRCP-Server (0.7.x und 0.8.x) für Windows. Dieser Server macht den Computer zur Softwarezentrale und ermöglicht einen Digitalbetrieb ohne separate [[Digitalzentrale | Zentraleinheit]] und [[Interface | Computerinterface]]. Kontakt: [mailto:mgrafe@snafu.de Michael Gräfe] Weitere Informationen zu diesem Programm gibt es auf den [http://home.snafu.de/mgrafe/ WWW-Seiten] des Autors.

* '''erddcd''' - DigitalDirekt-SRCP-Server (0.7.x) für Linux (DDL) Dieser Server macht den Computer zur Softwarezentrale und ermöglicht einen Digitalbetrieb ohne separate [[Digitalzentrale | Zentraleinheit]] und [[Interface | Computerinterface]] (für Linux Kernel 2.4 und 2.6). Kontakt: [http://vogt-it.com/MailForm/index.php Torsten Vogt] Weitere Informationen zu diesem Programm gibt es auf den Seiten des [http://www.vogt-it.com/OpenSource/DDL/ DDL-Projektes].

* '''TrackONE SRCP-Server''' - SRCP-Server (0.7.x) für Windows und die Intellibox. Server zur Ansteuerung einer per serieller Schnittstelle angeschlossenen Intellibox. Kontakt: [mailto:Michael@Reukauff.de Michael Reukauff] Weitere Informationen zu diesem Programm gibt es auf den [http://www.reukauff.de/TrackONE/ WWW-Seiten] des Autors.

* '''DCC-Signaler''' - SRCP-Server (0.7.x) für Windows und Linux. Dieser Server arbeitet in Verbindung mit einem externen, über die serielle Schnittstelle angeschlossenen DCC-Signalgenerator. Kontakt: [mailto:markus@gietzen.de Markus Gietzen] Weitere Informationen zu diesem Programm gibt es auf den WWW-Seiten des [http://dccsignaler.sourceforge.net/ Projektes].

* '''srcpd''' - SRCP-Server (0.8.x) für Linux/FreeBSD/Windows (Cygwin)/Mac OS X »srcpd« kann zur Steuerung von Anlagen sowohl über verschiedene [[Digitalzentralen]], wie z.B. Intellibox, Märklin Interface 6051, Lenz LI100, Selectrix, Zimo MX1, OpenDCC, als auch über direkt an der seriellen Schnittstelle (RS232) angeschlossene [[Booster]] (DDL-Betrieb) genutzt werden. Möglichkeiten zum Anschluß von Rückmeldungen, wie Littfinski HSI-S88 oder S88-Module am Parallelport, sowie weitere Module für seltener vorkommende Schnittstellen (CAN-Bus, I2C) sind ebenfalls vorhanden. Es können auch mehrere Geräte gleichzeitig (z.B. zwei Intelliboxen) eingesetzt werden. Kontakt: [mailto:srcpd-devel@lists.sourceforge.net srcpd-devel@lists.sourceforge.net] Weitere Infos zu diesem Programm gibt es auf den [http://srcpd.sourceforge.net/ Projekt-Seiten] bei SourceForge.

* '''ejsrcpd''' - Extended Java SRCP-Daemon (0.8.x) In Java implementierter SRCP-Server mit Plugin-Konzept zur Unterstützung unterschiedlicher Hardware-Schnittstellen. Kontakt: [mailto:kurtharders@users.sourceforge.net Kurt Harders] Weitere Informationen zu diesem Programm gibt es auf den [http://sourceforge.net/projects/ejsrcpd WWW-Seiten] des Projektes.

== Technologiestudien ==

Diese SRCP-Server sind entstanden, um Funktionen nicht nur am grünen Tisch testen zu können. Sie
können auch als Anregung für Weiterentwicklungen dienen.

* '''jsrcpd''' - Referenzimplementierung von SRCP 0.8.x. Dieses Programm ist eine erste Implementierung von SRCP 0.8.x ohne weitere Funktionalität. Derzeit ist es nicht für den Einsatz in der Modellbahnpraxis geeignet. Es dient in erster Linie den Entwicklern, die noch vorhandenen Fehler und Schwächen von SRCP 0.8.x zu erkennen und zu beheben. Es ist auch als Hilfe für die Entwicklung von SRCP 0.8.x Clients gedacht. Wer einen einsatzfähigen SRCP-Server sucht, sollte sich die weiter oben angeführten Produkte ansehen. Kontakt: [mailto:olaf.schlachter@web.de Olaf Schlachter] Weitere Infos zu diesem Programm und die Möglichkeit die Software zu beziehen, gibt es auf den Seiten des [http://srcpd.sourceforge.net/jsrcpd/ Autors].

== Kommerzielle Produkte ==

* '''Mini SRCP Server''' - Auf SRCP 0.8.2 basierende Firmware für Atmel Mikrocontroller; ist nur in Form eines fertig programmierten ATMega32 erhältlich. Kontakt: [mailto:r.barnstorf@online.de Reimar Barnstorf] Weitere Infos zu diesem Programm und die Möglichkeit die Software zu beziehen, gibt es auf den Seiten des [http://www.7soft.de/de/mini_srcp_server/index.html Autors].

= SRCP-Clients =

* '''J-Man''' - Java-Programm zur manuellen Steuerung von Lokomotiven und Magnetartikeln unter einer grafischen Benutzeroberfläche. Die Weiterentwicklung dieses Programms findet unter einer eigenen [http://sourceforge.net/projects/j-man/ Projektseite] statt. 

* '''loco-panel''' - Monitor zur Überwachung aller aktiven Loks. 

* '''uhl-programmer''' - Programmieren von Uhlenbrock-Decodern 

* '''nmra-programmer''' - Programmieren von NMRA-DCC-Decodern. Die Möglichkeit die Software zu beziehen, gibt es im Downloadbereich von [http://sourceforge.net/project/showfiles.php?group_id=29376 srcpd].

* '''phpTrainCtrl für SRCP 0.8 (alpha)''' - u.a. phpTamsProgrammer Kontakt: [http://vogt-it.com/MailForm/index.php Torsten Vogt] Weitere Infos zu diesen Programmen und die Möglichkeit die Software zu beziehen, gibt es auf den Seiten des [http://www.vogt-it.com/OpenSource/DDL/ DDL-Projektes].

* '''phpDDLTerminal''' - PHP basiertes Web-Interface zur Steuerung und Decoder-Programmierung Kontakt: [mailto:tt@borrmanns.de Thomas Borrmann] Weitere Informationen zu diesem Programm gibt es auf den Seiten des [http://tt.borrmanns.de/index.php?nav=0;0&cont=software Projektes].

* '''dtcltiny''' - manuelle Steuerung von Lokomotiven mit besonders kompakter und übersichtlicher Bedienoberfläche. Kontakt: [mailto:dtcltiny@markus-pfeiffer.de Markus Pfeiffer] Weitere Infos zu diesem Programm und die Möglichkeit die Software zu beziehen, gibt es auf den veralteten [http://www.markus-pfeiffer.de/ WWW-Seiten] des Autors, sowie der aktuellen [http://dtcltiny.sourceforge.net/ Projektseite] des Programms.

* '''spdrs60''' - grafisches Gleisbildstellpult nach Bundesbahnvorlage mit vorbildgerechter Fahrstraßensicherungslogik. Kontakt: [mailto:guido.scholz@bayernline.de Guido Scholz] Weitere Infos zu diesem Programm und die Möglichkeit, die Software zu beziehen, gibt es auf den veralteten [http://www.linux-modellbahn.de/ WWW-Seiten] von Stefan Preis sowie der aktuellen [http://spdrs60.sourceforge.net/ Projektseite] des Programms.

* '''M6051emu''' - Emulation des Märklin Interfaces 6051 für '''erddcd'''. Wird benötigt, wenn Nicht-SRCP-Clients (z.B. Railroad&Co) mit '''erddcd''' betrieben werden sollen. Kontakt: [mailto:dschaef@neon.rif.fuedo.de Dieter Schaefer] Weitere Infos zu diesem Programm und die Möglichkeit die Software zu beziehen, gibt es auf den Seiten des [http://www.vogt-it.com/OpenSource/DDL/ DDL-Projektes].

* '''rcsh''' und '''rcman''' - Programmiersprache (Railroad Command Shell) und textuelle Bedienoberfläche (rcman) Kontakt: [mailto:peer.griebel@gmx.de Dr. Peer Griebel] Weitere Infos zu diesen Programmen und die Möglichkeit die Software zu beziehen, gibt es auf den [http://www.griebel-net.de/peer/rcsh/rcsh.html WWW-Seiten] des Autors.

* Programmbibliothken für '''TCL/Tk''' und '''Python''' - Sammlung nützlicher Routinen und Prozesse für den Selbstprogrammierer: [http://srcpd.sourceforge.net/clients/ Client-Seiten des srcpd]

* '''SRCP Recorder''' - Zeichnet SRCP-Befehle einer laufenden Session auf und spielt sie später wieder ab. Kontakt: [mailto:mtrute@web.de Matthias Trute] Weitere Infos zu diesen Programmen und die Möglichkeit die Software zu beziehen, gibt es auf den [http://srcpd.sourceforge.net/ WWW-Seiten] des Autors.

* '''SRCP Tester''' - SRCP-Befehle mit einem Web-Server und PHP generieren. Kontakt: [mailto:martin@familiewolf.de Martin Wolf] Weitere Infos zu diesen Programmen und die Möglichkeit die Software zu beziehen, gibt es auf den <nowiki>[http://www.stud.mw.tu-muenchen.de/~mw7/familie/martin/hobby/modellbahn/srcptest.html WWW-Seiten (link defekt)]</nowiki> des Autors.

* '''Gplan''' - Gleispläne erstellen und Magnetartikel steuern (für Windows und Linux). Kontakt: [mailto:mgrafe@snafu.de Michael Gräfe] Weitere Infos zu diesem Programm und die Möglichkeit die Software zu beziehen, gibt es auf den [http://home.snafu.de/mgrafe/ WWW-Seiten] des Autors.

* '''TrackONE SRCP-Keyboard, Gleisplan-Editor und Steuersoftware''' (für Windows) Kontakt: [mailto:Michael@Reukauff.de Michael Reukauff] Weitere Infos zu diesen Programmen und die Möglichkeit die Software zu beziehen, gibt es auf den [http://www.reukauff.de/TrackONE/ WWW-Seiten] des Autors.

* '''JTrain''' - In Java geschriebener grafischer SRCP-Client zur Steuerung von Lokomotiven und Schaltdecodern mit grafischem Stellpult (für Windows und Linux). Die ursprünglich von Werner Kunkel betreute Original-Internetseite (www.jtrain.de) dieses Programms existiert nicht mehr. Es bestehen noch eine von [http://www.lug-burghausen.org/dienste/rpm.html Guido Scholz] weiterentwickelte Version dieses Programms sowie eine darauf aufbauende, von [mailto:ibruell@users.berlios.de Ingo Bruell] betreute [http://developer.berlios.de/projects/jtrain/ Projektseite].

* '''Java DCC Network Client (ab Version 2.1)''' - SRCP-Client zur Steuerung einer Gartenbahn mit einem Sharp Zaurus PDA mit einem WLAN Kontakt: [mailto:H.Karoska@t-online.de Helge Karoska] Java-SRCP-Client für den PDA Zaurus unter Linux. Das Programms wurde entwickelt zur Steuerung von Loks, Weichen und Zubehör einer Gartenbahn mit einem WLAN. Es kann aber auch universell eingesetzt werden. Weitere Infos zu diesem Programm und die Möglichkeit die Software zu beziehen, gibt es auf den [http://www.karkoska.de/DCC/DCCSET.htm WWW-Seiten] des Autors.

* '''LD-X-Programmer''' - Programm zur Programmierung von Decodern der Firma Tams Elektronik (für Windows) Kontakt: [mailto:geramb@aon.de Michael Geramb] SRCP-Client (SRCP 0.7.3) für Windows zur Programmierung von Tams-Decodern. Weitere Infos zu diesem Programm und die Möglichkeit die Software zu beziehen, gibt es auf den [http://members.aon.at/geramb/ld-x-programmer.htm WWW-Seiten] des Autors.

* '''TRAINer''' - SRCP-Client mit Fahrstrassensteuerung, Lokomotiv-Bibliothek, Automatik-Betrieb (für Windows) Kontakt: [mailto:tainer@keintzel.at Peter Keintzel] Weitere Infos zu diesem Programm und die Möglichkeit die Software zu beziehen, gibt es auf den [http://www.keintzel.at/html/at/hobby/TRAINer/trainer.htm WWW-Seiten] des Autors.

* '''SRCP-Pakete für verschiedene Linux-Distributionen''' - Guido Scholz hat einige der hier gelisteten Linux-Programme weiterentwickelt und diese in einfach zu installierende Pakete (SuSE, Fedora, Debian) verpackt. Kontakt: [mailto:guido.scholz@bayernline.de Guido Scholz] Weitere Infos zu diesem Angebot und die Möglichkeit die Software zu beziehen, gibt es auf den [http://www.lug-burghausen.org/dienste/rpm.html WWW-Seiten] des Autors (hier Linux User Group Burghausen).

* '''Traindrive''' - SRCP-Client zum Steuern von Lokomotiven (Linux- und Windows-Version) Kontakt: [mailto:ganter@ganter.at Fritz Ganter] Weitere Infos zu diesem Programm und die Möglichkeit die Software zu beziehen, gibt es auf den [http://traindrive.gpsdrive.cc/ WWW-Seiten] des Autors.

* '''RocRail''' - Programm zum Steuern von Lokomotiven und Gleisbildstellpult (Linux- und Windows-Version vorhanden) Kontakt: [mailto:support@rocrail.net Rob Versluis] Weitere Infos zu diesem Programm und die Möglichkeit die Software zu beziehen, gibt es auf den [http://www.rocrail.net/ WWW-Seiten] des Autors.

* '''MOBA-Package''' - Hilfsprogramme für die Entwicklung von SRCP-Clients und -Servern (Windows-Version) Kontakt: [mailto:selandro@users.sourceforge.net Roman Lauer] Weitere Infos zu diesem Programm und die Möglichkeit die Software zu beziehen, gibt es auf den [http://mobapackage.sourceforge.net/ WWW-Seiten] des Autors.

* '''EnjoyTheTime''' - SRCP-Client zum Steuern von Lokomotiven (Windows-Version) Kontakt: [mailto:mgeramb@users.sourceforge.net Michael Geramb] Weitere Infos zu diesem Programm und die Möglichkeit, die Software zu beziehen, gibt es auf den [http://members.aon.at/geramb/enjoythetime.htm WWW-Seiten] des Autors.

* '''Railroad Express''' - SRCP-Client zum Steuern von Modellbahnanlagen (Windows-Version) Kontakt: [mailto:support@miniware.nl Fred Stevens] Weitere Infos zu diesem Programm und die Möglichkeit, die Software zu beziehen, gibt es auf den [http://www.moba-digitaal.nl/de/main/index.html WWW-Seiten] des Autors.

* '''dras/Kdigirail''' - SRCP-Client zum Steuern von Modellbahnanlagen (Linux-Version) Kontakt: [mailto:schmischi@users.sourceforge.net Frank Schmischke] Weitere Infos zu diesem Programm und die Möglichkeit, die Software zu beziehen, gibt es auf den [http://srcpd.sourceforge.net/clients/dras/ WWW-Seiten] des Autors.

* '''AdHoc-Railway''' - Java-SRCP-Client zum Steuern von Modellbahnanlagen Kontakt: [mailto:fork_ch@users.sourceforge.net Benjamin Mueller] Weitere Infos zu diesem Programm und die Möglichkeit, die Software zu beziehen, gibt es auf der [http://sourceforge.net/projects/adhocrailway/ Projektseite] des Programms.

* '''jsrcpc''' - Java-SRCP-Bibliothek zur Entwicklung von SRCP-Clients Kontakt: [mailto:fork_ch@users.sourceforge.net Benjamin Mueller] Weitere Infos zu dieser Software und die Möglichkeit, diese zu beziehen, gibt es auf der [http://sourceforge.net/projects/jsrcpc/ Projektseite] der Bibliothek.

* '''nsrcp''' - .NET basierte SRCP-Bibliothek zur Entwicklung von SRCP-Clients Kontakt: [mailto:mgeramb@users.sourceforge.net Michael Geramb] Weitere Infos zu dieser Software und die Möglichkeit, diese zu beziehen, gibt es auf der [http://sourceforge.net/projects/nsrcp/ Projektseite] der Bibliothek.

* '''JMRI''' - Java basierte Programmsammlung zur Steuerung von Modellbahnen Kontakt: [mailto:jmri-developers@users.sourceforge.net Entwickler Mailingliste] Weitere Infos zu dieser Software und die Möglichkeit, diese zu beziehen, gibt es auf der [http://jmri.sourceforge.net/ Projektseite] der Programmsammlung.

* '''PPC SRCP Client''' - .Net basierter PocketPC-Client zur Steuerung von Lokomotiven Kontakt: [mailto:r.barnstorf@online.de Reimar Barnstorf] Weitere Infos zu dieser Software und die Möglichkeit, diese zu beziehen, gibt es auf den [http://http://www.7soft.de/de/ppc_srcp_client/index.html WWW-Seiten] des Programms.

= Hardware =
[[Bild:Srcp-moba-interface.png|framed|Mögliche Hardware-Schnittstellen zwischen SRCP-Server und Modellbahn]]
Ein SRCP-Server kann unterschiedliche Hardwareschnittstellen eines Computers ansprechen und über diese mit der Modellbahn kommunizieren. Die größte Verbreitung für diesen Zweck hat die serielle Schnittstelle ([http://de.wikipedia.org/wiki/EIA-232 RS232/EIA-232]), die in neueren Rechnern zunehmend durch die [http://de.wikipedia.org/wiki/USB USB-Schnittstelle] ersetzt wird. Weitere Verwendung findet die parallele Schnittstelle ([http://de.wikipedia.org/wiki/IEEE_1284 IEEE 1284]) oder auch weniger geläufige, wie der [http://de.wikipedia.org/wiki/I2C I2C-Bus] oder diverse IO-Karten. Welche Art Hardware-Anbindung von den einzelnen SRCP-Servern unterstützt wird, ist der jeweiligen Programmdokumentation zu entnehmen.

 

== DDL-Betrieb ==
Im Rahmens des [http://www.vogt-it.com/OpenSource/DDL/ DDL-Projektes] wurde eine Technik entwickelt, mit der ein PC einfach und kostengünstig an die Hardware der Modellbahnanlage angeschlossen werden kann. Der Computer kann nach diesem System als [[Digitalzentrale]] genutzt werden. Prinzipiell benötigt man hierfür zwei Informationskanäle, die jedoch auch einzeln betrieben werden können:
* Ein Kanal zum Senden von Steuerbefehlen an die Anlage
* Ein Kanal zum Empfang von Rückmeldungen von der Anlage

Das ''Senden'' von Befehlen läuft über die serielle Schnittstelle ([http://de.wikipedia.org/wiki/EIA-232 RS232/EIA-232]), die im einfachsten Fall über zwei Kabel elektrisch mit einem [[Booster]] verbunden ist. Programmtechnisch wird die serielle Schnittstelle hierbei als Signalgenerator für das gewählte [[Digitalprotokoll]] genutzt. Beim praktischen Einsatz ist zu beachten, dass Notebooks in der Regel ein anderes Spannungsniveau an der RS232 liefern (ca. 5-8 V), als Desktop-Rechner (ca. 12 V). Manche Hardware-Kombinationen funktionieren daher an dem einen oder anderen Notebook nicht.

Zum ''Empfang'' von Rückmeldungen der Anlage benötigt man ein [[S88-R%C3%BCckmeldebus | S88-Bus-System]], das über Kabelverbindungen und eine 5 V-Spannungsversorgung an die parallele Schnittstelle ([http://de.wikipedia.org/wiki/IEEE_1284 IEEE 1284]) angeschlossen wird.

Ein übersichtliche Zusammenstellung der für diese Anbindungen notwendigen elektischen Verbindungen gibt es von Holger Seider: http://home.snafu.de/mgrafe/Anleitung_Server.htm

[[Kategorie:Digitalbetrieb]]
[[Kategorie:SRCP]]

SRCP-Erweiterungen

2009-02-09T17:22:02Z

Michael Oppenauer: /* Abfrage der CRCF-Daten via Generic Messages */ actor_id

==Das initiale Posting==

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 [[Digitalprojekt|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:

# 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.
# 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.

Es gab eine rege Beteiligung an der Diskussion, beide Ideen wurden darin ausführlich diskutiert.

==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.

{| border="1" align="center" width="50%"
|+
! SRCP-Interessierter
! Wohnort

|-
| Sven Schlender
| Karlsruhe

|-
| Stefan Bormann
| Bremen

|-
| Guido Scholz
| Burgkirchen

|-
| ...
| ...
|}

==SRCP-Server-Suchdienst==
Sehr schnell kam der Vorschlag, für diesen Bedarf einen [http://www.zeroconf.org/ 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:

* [http://www.apple.com/macosx/features/bonjour/ Bonjour], von Apple für Mac, UNIXoide-Systeme und Windows.
* [http://avahi.org/ 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 [http://www.iana.org/ 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_0.2.0|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===
[[Bild:Crcf-old.png|framed|Nachrichtenfluß gemäß der CRCF-Spezifikation Version 0.2.0. CS: COMAND-Sitzung]]
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====
[[Bild:srcp-crcf-client.png|framed|Nachrichtenfluß bei einem Betrieb mit einem als CRCF-Server arbeitenden SRCP-Client. CS: COMAND-Sitzung, IS: INFO-Sitzung]]
Ü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====
[[Bild:srcp-crcf-server.png|framed|Nachrichtenfluß bei einem Betrieb mit getrennten SRCP- und CRCF-Servern. CS: COMAND-Sitzung, IS: INFO-Sitzung, ...: nicht geklärt]]
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====
[[Bild:Crcf-client-server.png|framed|Nachrichtenfluß bei einem Betrieb mit als CRCF-Servern und -Clients arbeitenden SRCP-Clients. CS: COMAND-Sitzung, IS: INFO-Sitzung]]
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 [http://en.wikipedia.org/wiki/UUID UUID] gemäß [http://tools.ietf.org/rfc/rfc4122.txt 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 ([http://www.ietf.org/rfc/rfc2396.txt 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
::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
::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
::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)

==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:

# Der Wert ist 0: Rundruf (Broadcast)
# 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 ....

[[Bild:SRCP_GM.png|framed|Nachrichtenfluß über Generic Messages. CS: COMMAND-Sitzung, IS: INFO-Sitzung]]
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.

* <del>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.</del>
Anmerkung: Es gibt bereits genügend SRCP-Kommandos, um Informationen direkt beim Server zu erfragen. Dieser Punkt ist daher irrelevant.

* <del>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.</del>
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.

[[Kategorie:SRCP]]

SRCP-Erweiterungen

2009-02-07T16:20:04Z

Michael Oppenauer: /* Abfrage der CRCF-Daten via Generic Messages */ GET

==Das initiale Posting==

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 [[Digitalprojekt|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:

# 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.
# 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.

Es gab eine rege Beteiligung an der Diskussion, beide Ideen wurden darin ausführlich diskutiert.

==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.

{| border="1" align="center" width="50%"
|+
! SRCP-Interessierter
! Wohnort

|-
| Sven Schlender
| Karlsruhe

|-
| Stefan Bormann
| Bremen

|-
| Guido Scholz
| Burgkirchen

|-
| ...
| ...
|}

==SRCP-Server-Suchdienst==
Sehr schnell kam der Vorschlag, für diesen Bedarf einen [http://www.zeroconf.org/ 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:

* [http://www.apple.com/macosx/features/bonjour/ Bonjour], von Apple für Mac, UNIXoide-Systeme und Windows.
* [http://avahi.org/ 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 [http://www.iana.org/ 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_0.2.0|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===
[[Bild:Crcf-old.png|framed|Nachrichtenfluß gemäß der CRCF-Spezifikation Version 0.2.0. CS: COMAND-Sitzung]]
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====
[[Bild:srcp-crcf-client.png|framed|Nachrichtenfluß bei einem Betrieb mit einem als CRCF-Server arbeitenden SRCP-Client. CS: COMAND-Sitzung, IS: INFO-Sitzung]]
Ü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====
[[Bild:srcp-crcf-server.png|framed|Nachrichtenfluß bei einem Betrieb mit getrennten SRCP- und CRCF-Servern. CS: COMAND-Sitzung, IS: INFO-Sitzung, ...: nicht geklärt]]
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====
[[Bild:Crcf-client-server.png|framed|Nachrichtenfluß bei einem Betrieb mit als CRCF-Servern und -Clients arbeitenden SRCP-Clients. CS: COMAND-Sitzung, IS: INFO-Sitzung]]
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 [http://en.wikipedia.org/wiki/UUID UUID] gemäß [http://tools.ietf.org/rfc/rfc4122.txt RFC4122]. Die Frage ist, ob diese URL-kodiert werden soll oder nicht. Aus Gründen der Einheitlichkeit wäre dieses zu bevorzugen.

;<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 ([http://www.ietf.org/rfc/rfc2396.txt 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
::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
::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
::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)

==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:

# Der Wert ist 0: Rundruf (Broadcast)
# 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 ....

[[Bild:SRCP_GM.png|framed|Nachrichtenfluß über Generic Messages. CS: COMMAND-Sitzung, IS: INFO-Sitzung]]
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.

* <del>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.</del>
Anmerkung: Es gibt bereits genügend SRCP-Kommandos, um Informationen direkt beim Server zu erfragen. Dieser Punkt ist daher irrelevant.

* <del>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.</del>
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.

[[Kategorie:SRCP]]

SRCP-Erweiterungen

2009-02-07T16:12:37Z

Michael Oppenauer: /* Erweiterung des bisherigen Befehlsvorrats */ IMAGE

==Das initiale Posting==

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 [[Digitalprojekt|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:

# 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.
# 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.

Es gab eine rege Beteiligung an der Diskussion, beide Ideen wurden darin ausführlich diskutiert.

==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.

{| border="1" align="center" width="50%"
|+
! SRCP-Interessierter
! Wohnort

|-
| Sven Schlender
| Karlsruhe

|-
| Stefan Bormann
| Bremen

|-
| Guido Scholz
| Burgkirchen

|-
| ...
| ...
|}

==SRCP-Server-Suchdienst==
Sehr schnell kam der Vorschlag, für diesen Bedarf einen [http://www.zeroconf.org/ 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:

* [http://www.apple.com/macosx/features/bonjour/ Bonjour], von Apple für Mac, UNIXoide-Systeme und Windows.
* [http://avahi.org/ 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 [http://www.iana.org/ 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_0.2.0|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===
[[Bild:Crcf-old.png|framed|Nachrichtenfluß gemäß der CRCF-Spezifikation Version 0.2.0. CS: COMAND-Sitzung]]
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====
[[Bild:srcp-crcf-client.png|framed|Nachrichtenfluß bei einem Betrieb mit einem als CRCF-Server arbeitenden SRCP-Client. CS: COMAND-Sitzung, IS: INFO-Sitzung]]
Ü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====
[[Bild:srcp-crcf-server.png|framed|Nachrichtenfluß bei einem Betrieb mit getrennten SRCP- und CRCF-Servern. CS: COMAND-Sitzung, IS: INFO-Sitzung, ...: nicht geklärt]]
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====
[[Bild:Crcf-client-server.png|framed|Nachrichtenfluß bei einem Betrieb mit als CRCF-Servern und -Clients arbeitenden SRCP-Clients. CS: COMAND-Sitzung, IS: INFO-Sitzung]]
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 [http://en.wikipedia.org/wiki/UUID UUID] gemäß [http://tools.ietf.org/rfc/rfc4122.txt RFC4122]. Die Frage ist, ob diese URL-kodiert werden soll oder nicht. Aus Gründen der Einheitlichkeit wäre dieses zu bevorzugen.

;<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> wird nicht verwendet. 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. Bei der Methoden GET und LIST findet er keine Verwendung. 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 ([http://www.ietf.org/rfc/rfc2396.txt 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
::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
::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
::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)

==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:

# Der Wert ist 0: Rundruf (Broadcast)
# 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 ....

[[Bild:SRCP_GM.png|framed|Nachrichtenfluß über Generic Messages. CS: COMMAND-Sitzung, IS: INFO-Sitzung]]
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.

* <del>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.</del>
Anmerkung: Es gibt bereits genügend SRCP-Kommandos, um Informationen direkt beim Server zu erfragen. Dieser Punkt ist daher irrelevant.

* <del>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.</del>
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.

[[Kategorie:SRCP]]

SRCP-Erweiterungen

2009-02-07T14:43:49Z

Michael Oppenauer: /* Abfrage der CRCF-Daten via Generic Messages */ Formatierung

==Das initiale Posting==

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 [[Digitalprojekt|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:

# 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.
# 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.

Es gab eine rege Beteiligung an der Diskussion, beide Ideen wurden darin ausführlich diskutiert.

==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.

{| border="1" align="center" width="50%"
|+
! SRCP-Interessierter
! Wohnort

|-
| Sven Schlender
| Karlsruhe

|-
| Stefan Bormann
| Bremen

|-
| Guido Scholz
| Burgkirchen

|-
| ...
| ...
|}

==SRCP-Server-Suchdienst==
Sehr schnell kam der Vorschlag, für diesen Bedarf einen [http://www.zeroconf.org/ 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:

* [http://www.apple.com/macosx/features/bonjour/ Bonjour], von Apple für Mac, UNIXoide-Systeme und Windows.
* [http://avahi.org/ 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 [http://www.iana.org/ 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_0.2.0|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===
[[Bild:Crcf-old.png|framed|Nachrichtenfluß gemäß der CRCF-Spezifikation Version 0.2.0. CS: COMAND-Sitzung]]
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====
[[Bild:srcp-crcf-client.png|framed|Nachrichtenfluß bei einem Betrieb mit einem als CRCF-Server arbeitenden SRCP-Client. CS: COMAND-Sitzung, IS: INFO-Sitzung]]
Ü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====
[[Bild:srcp-crcf-server.png|framed|Nachrichtenfluß bei einem Betrieb mit getrennten SRCP- und CRCF-Servern. CS: COMAND-Sitzung, IS: INFO-Sitzung, ...: nicht geklärt]]
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====
[[Bild:Crcf-client-server.png|framed|Nachrichtenfluß bei einem Betrieb mit als CRCF-Servern und -Clients arbeitenden SRCP-Clients. CS: COMAND-Sitzung, IS: INFO-Sitzung]]
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 [http://en.wikipedia.org/wiki/UUID UUID] gemäß [http://tools.ietf.org/rfc/rfc4122.txt RFC4122]. Die Frage ist, ob diese URL-kodiert werden soll oder nicht. Aus Gründen der Einheitlichkeit wäre dieses zu bevorzugen.

;<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> wird nicht verwendet. 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. Bei der Methoden GET und LIST findet er keine Verwendung. 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 ([http://www.ietf.org/rfc/rfc2396.txt 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) - Byte Strom - statisch
::Bildformate (IMAGEFORMAT) - Liste - 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
::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
::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
::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.

(TODO: weitere ergänzen)

==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:

# Der Wert ist 0: Rundruf (Broadcast)
# 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 ....

[[Bild:SRCP_GM.png|framed|Nachrichtenfluß über Generic Messages. CS: COMMAND-Sitzung, IS: INFO-Sitzung]]
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.

* <del>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.</del>
Anmerkung: Es gibt bereits genügend SRCP-Kommandos, um Informationen direkt beim Server zu erfragen. Dieser Punkt ist daher irrelevant.

* <del>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.</del>
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.

[[Kategorie:SRCP]]

SRCP-Erweiterungen

2009-02-07T14:37:14Z

Michael Oppenauer: /* Abfrage der CRCF-Daten via Generic Messages */ Formatierung

==Das initiale Posting==

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 [[Digitalprojekt|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:

# 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.
# 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.

Es gab eine rege Beteiligung an der Diskussion, beide Ideen wurden darin ausführlich diskutiert.

==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.

{| border="1" align="center" width="50%"
|+
! SRCP-Interessierter
! Wohnort

|-
| Sven Schlender
| Karlsruhe

|-
| Stefan Bormann
| Bremen

|-
| Guido Scholz
| Burgkirchen

|-
| ...
| ...
|}

==SRCP-Server-Suchdienst==
Sehr schnell kam der Vorschlag, für diesen Bedarf einen [http://www.zeroconf.org/ 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:

* [http://www.apple.com/macosx/features/bonjour/ Bonjour], von Apple für Mac, UNIXoide-Systeme und Windows.
* [http://avahi.org/ 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 [http://www.iana.org/ 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_0.2.0|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===
[[Bild:Crcf-old.png|framed|Nachrichtenfluß gemäß der CRCF-Spezifikation Version 0.2.0. CS: COMAND-Sitzung]]
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====
[[Bild:srcp-crcf-client.png|framed|Nachrichtenfluß bei einem Betrieb mit einem als CRCF-Server arbeitenden SRCP-Client. CS: COMAND-Sitzung, IS: INFO-Sitzung]]
Ü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====
[[Bild:srcp-crcf-server.png|framed|Nachrichtenfluß bei einem Betrieb mit getrennten SRCP- und CRCF-Servern. CS: COMAND-Sitzung, IS: INFO-Sitzung, ...: nicht geklärt]]
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====
[[Bild:Crcf-client-server.png|framed|Nachrichtenfluß bei einem Betrieb mit als CRCF-Servern und -Clients arbeitenden SRCP-Clients. CS: COMAND-Sitzung, IS: INFO-Sitzung]]
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 [http://en.wikipedia.org/wiki/UUID UUID] gemäß [http://tools.ietf.org/rfc/rfc4122.txt RFC4122]. Die Frage ist, ob diese URL-kodiert werden soll oder nicht. Aus Gründen der Einheitlichkeit wäre dieses zu bevorzugen.

;<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> wird nicht verwendet. 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. Bei der Methoden GET und LIST findet er keine Verwendung. 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 ([http://www.ietf.org/rfc/rfc2396.txt 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) - Byte Strom - statisch
::Bildformate (IMAGEFORMAT) - Liste - 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
::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
::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
::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.

(TODO: weitere ergänzen)

==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:

# Der Wert ist 0: Rundruf (Broadcast)
# 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 ....

[[Bild:SRCP_GM.png|framed|Nachrichtenfluß über Generic Messages. CS: COMMAND-Sitzung, IS: INFO-Sitzung]]
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.

* <del>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.</del>
Anmerkung: Es gibt bereits genügend SRCP-Kommandos, um Informationen direkt beim Server zu erfragen. Dieser Punkt ist daher irrelevant.

* <del>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.</del>
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.

[[Kategorie:SRCP]]

SRCP-Erweiterungen

2009-02-07T14:35:52Z

Michael Oppenauer: /* Erweiterung des bisherigen Befehlsvorrats */ Aktoren und Attribute für Lokverwerwaltung

==Das initiale Posting==

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 [[Digitalprojekt|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:

# 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.
# 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.

Es gab eine rege Beteiligung an der Diskussion, beide Ideen wurden darin ausführlich diskutiert.

==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.

{| border="1" align="center" width="50%"
|+
! SRCP-Interessierter
! Wohnort

|-
| Sven Schlender
| Karlsruhe

|-
| Stefan Bormann
| Bremen

|-
| Guido Scholz
| Burgkirchen

|-
| ...
| ...
|}

==SRCP-Server-Suchdienst==
Sehr schnell kam der Vorschlag, für diesen Bedarf einen [http://www.zeroconf.org/ 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:

* [http://www.apple.com/macosx/features/bonjour/ Bonjour], von Apple für Mac, UNIXoide-Systeme und Windows.
* [http://avahi.org/ 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 [http://www.iana.org/ 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_0.2.0|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===
[[Bild:Crcf-old.png|framed|Nachrichtenfluß gemäß der CRCF-Spezifikation Version 0.2.0. CS: COMAND-Sitzung]]
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====
[[Bild:srcp-crcf-client.png|framed|Nachrichtenfluß bei einem Betrieb mit einem als CRCF-Server arbeitenden SRCP-Client. CS: COMAND-Sitzung, IS: INFO-Sitzung]]
Ü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====
[[Bild:srcp-crcf-server.png|framed|Nachrichtenfluß bei einem Betrieb mit getrennten SRCP- und CRCF-Servern. CS: COMAND-Sitzung, IS: INFO-Sitzung, ...: nicht geklärt]]
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====
[[Bild:Crcf-client-server.png|framed|Nachrichtenfluß bei einem Betrieb mit als CRCF-Servern und -Clients arbeitenden SRCP-Clients. CS: COMAND-Sitzung, IS: INFO-Sitzung]]
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 [http://en.wikipedia.org/wiki/UUID UUID] gemäß [http://tools.ietf.org/rfc/rfc4122.txt RFC4122]. Die Frage ist, ob diese URL-kodiert werden soll oder nicht. Aus Gründen der Einheitlichkeit wäre dieses zu bevorzugen.

;<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> wird nicht verwendet. 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. Bei der Methoden GET und LIST findet er keine Verwendung. 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 ([http://www.ietf.org/rfc/rfc2396.txt 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) - Byte Strom - statisch
::Bildformate (IMAGEFORMAT) - Liste - 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
::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
::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
::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.

(TODO: weitere ergänzen)

==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:

# Der Wert ist 0: Rundruf (Broadcast)
# 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 ....

[[Bild:SRCP_GM.png|framed|Nachrichtenfluß über Generic Messages. CS: COMMAND-Sitzung, IS: INFO-Sitzung]]
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.

* <del>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.</del>
Anmerkung: Es gibt bereits genügend SRCP-Kommandos, um Informationen direkt beim Server zu erfragen. Dieser Punkt ist daher irrelevant.

* <del>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.</del>
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.

[[Kategorie:SRCP]]

SRCP-Erweiterungen

2009-02-07T14:09:43Z

Michael Oppenauer: /* Erweiterung des bisherigen Befehlsvorrats */ Formatierung

==Das initiale Posting==

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 [[Digitalprojekt|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:

# 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.
# 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.

Es gab eine rege Beteiligung an der Diskussion, beide Ideen wurden darin ausführlich diskutiert.

==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.

{| border="1" align="center" width="50%"
|+
! SRCP-Interessierter
! Wohnort

|-
| Sven Schlender
| Karlsruhe

|-
| Stefan Bormann
| Bremen

|-
| Guido Scholz
| Burgkirchen

|-
| ...
| ...
|}

==SRCP-Server-Suchdienst==
Sehr schnell kam der Vorschlag, für diesen Bedarf einen [http://www.zeroconf.org/ 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:

* [http://www.apple.com/macosx/features/bonjour/ Bonjour], von Apple für Mac, UNIXoide-Systeme und Windows.
* [http://avahi.org/ 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 [http://www.iana.org/ 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_0.2.0|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===
[[Bild:Crcf-old.png|framed|Nachrichtenfluß gemäß der CRCF-Spezifikation Version 0.2.0. CS: COMAND-Sitzung]]
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====
[[Bild:srcp-crcf-client.png|framed|Nachrichtenfluß bei einem Betrieb mit einem als CRCF-Server arbeitenden SRCP-Client. CS: COMAND-Sitzung, IS: INFO-Sitzung]]
Ü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====
[[Bild:srcp-crcf-server.png|framed|Nachrichtenfluß bei einem Betrieb mit getrennten SRCP- und CRCF-Servern. CS: COMAND-Sitzung, IS: INFO-Sitzung, ...: nicht geklärt]]
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====
[[Bild:Crcf-client-server.png|framed|Nachrichtenfluß bei einem Betrieb mit als CRCF-Servern und -Clients arbeitenden SRCP-Clients. CS: COMAND-Sitzung, IS: INFO-Sitzung]]
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 [http://en.wikipedia.org/wiki/UUID UUID] gemäß [http://tools.ietf.org/rfc/rfc4122.txt RFC4122]. Die Frage ist, ob diese URL-kodiert werden soll oder nicht. Aus Gründen der Einheitlichkeit wäre dieses zu bevorzugen.

;<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> wird nicht verwendet. 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. Bei der Methoden GET und LIST findet er keine Verwendung. 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 ([http://www.ietf.org/rfc/rfc2396.txt 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).

(TODO: weitere ergänzen)

==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:

# Der Wert ist 0: Rundruf (Broadcast)
# 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 ....

[[Bild:SRCP_GM.png|framed|Nachrichtenfluß über Generic Messages. CS: COMMAND-Sitzung, IS: INFO-Sitzung]]
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.

* <del>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.</del>
Anmerkung: Es gibt bereits genügend SRCP-Kommandos, um Informationen direkt beim Server zu erfragen. Dieser Punkt ist daher irrelevant.

* <del>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.</del>
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.

[[Kategorie:SRCP]]

SRCP-Erweiterungen

2009-02-07T14:04:48Z

Michael Oppenauer: /* Erweiterung des bisherigen Befehlsvorrats */ Aktoren und Attribute aus spdrs60

==Das initiale Posting==

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 [[Digitalprojekt|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:

# 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.
# 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.

Es gab eine rege Beteiligung an der Diskussion, beide Ideen wurden darin ausführlich diskutiert.

==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.

{| border="1" align="center" width="50%"
|+
! SRCP-Interessierter
! Wohnort

|-
| Sven Schlender
| Karlsruhe

|-
| Stefan Bormann
| Bremen

|-
| Guido Scholz
| Burgkirchen

|-
| ...
| ...
|}

==SRCP-Server-Suchdienst==
Sehr schnell kam der Vorschlag, für diesen Bedarf einen [http://www.zeroconf.org/ 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:

* [http://www.apple.com/macosx/features/bonjour/ Bonjour], von Apple für Mac, UNIXoide-Systeme und Windows.
* [http://avahi.org/ 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 [http://www.iana.org/ 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_0.2.0|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===
[[Bild:Crcf-old.png|framed|Nachrichtenfluß gemäß der CRCF-Spezifikation Version 0.2.0. CS: COMAND-Sitzung]]
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====
[[Bild:srcp-crcf-client.png|framed|Nachrichtenfluß bei einem Betrieb mit einem als CRCF-Server arbeitenden SRCP-Client. CS: COMAND-Sitzung, IS: INFO-Sitzung]]
Ü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====
[[Bild:srcp-crcf-server.png|framed|Nachrichtenfluß bei einem Betrieb mit getrennten SRCP- und CRCF-Servern. CS: COMAND-Sitzung, IS: INFO-Sitzung, ...: nicht geklärt]]
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====
[[Bild:Crcf-client-server.png|framed|Nachrichtenfluß bei einem Betrieb mit als CRCF-Servern und -Clients arbeitenden SRCP-Clients. CS: COMAND-Sitzung, IS: INFO-Sitzung]]
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 [http://en.wikipedia.org/wiki/UUID UUID] gemäß [http://tools.ietf.org/rfc/rfc4122.txt RFC4122]. Die Frage ist, ob diese URL-kodiert werden soll oder nicht. Aus Gründen der Einheitlichkeit wäre dieses zu bevorzugen.

;<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> wird nicht verwendet. 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. Bei der Methoden GET und LIST findet er keine Verwendung. 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 ([http://www.ietf.org/rfc/rfc2396.txt 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).
(TODO: weitere ergänzen)

==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:

# Der Wert ist 0: Rundruf (Broadcast)
# 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 ....

[[Bild:SRCP_GM.png|framed|Nachrichtenfluß über Generic Messages. CS: COMMAND-Sitzung, IS: INFO-Sitzung]]
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.

* <del>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.</del>
Anmerkung: Es gibt bereits genügend SRCP-Kommandos, um Informationen direkt beim Server zu erfragen. Dieser Punkt ist daher irrelevant.

* <del>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.</del>
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.

[[Kategorie:SRCP]]

SRCP-Erweiterungen

2009-02-07T13:48:18Z

Michael Oppenauer: /* Implementierungsvorschläge */ Abfrage der CRCF-Daten via Generic Messages

==Das initiale Posting==

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 [[Digitalprojekt|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:

# 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.
# 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.

Es gab eine rege Beteiligung an der Diskussion, beide Ideen wurden darin ausführlich diskutiert.

==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.

{| border="1" align="center" width="50%"
|+
! SRCP-Interessierter
! Wohnort

|-
| Sven Schlender
| Karlsruhe

|-
| Stefan Bormann
| Bremen

|-
| Guido Scholz
| Burgkirchen

|-
| ...
| ...
|}

==SRCP-Server-Suchdienst==
Sehr schnell kam der Vorschlag, für diesen Bedarf einen [http://www.zeroconf.org/ 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:

* [http://www.apple.com/macosx/features/bonjour/ Bonjour], von Apple für Mac, UNIXoide-Systeme und Windows.
* [http://avahi.org/ 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 [http://www.iana.org/ 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_0.2.0|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===
[[Bild:Crcf-old.png|framed|Nachrichtenfluß gemäß der CRCF-Spezifikation Version 0.2.0. CS: COMAND-Sitzung]]
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====
[[Bild:srcp-crcf-client.png|framed|Nachrichtenfluß bei einem Betrieb mit einem als CRCF-Server arbeitenden SRCP-Client. CS: COMAND-Sitzung, IS: INFO-Sitzung]]
Ü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====
[[Bild:srcp-crcf-server.png|framed|Nachrichtenfluß bei einem Betrieb mit getrennten SRCP- und CRCF-Servern. CS: COMAND-Sitzung, IS: INFO-Sitzung, ...: nicht geklärt]]
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====
[[Bild:Crcf-client-server.png|framed|Nachrichtenfluß bei einem Betrieb mit als CRCF-Servern und -Clients arbeitenden SRCP-Clients. CS: COMAND-Sitzung, IS: INFO-Sitzung]]
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 [http://en.wikipedia.org/wiki/UUID UUID] gemäß [http://tools.ietf.org/rfc/rfc4122.txt RFC4122]. Die Frage ist, ob diese URL-kodiert werden soll oder nicht. Aus Gründen der Einheitlichkeit wäre dieses zu bevorzugen.

;<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> wird nicht verwendet. 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. Bei der Methoden GET und LIST findet er keine Verwendung. 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 ([http://www.ietf.org/rfc/rfc2396.txt 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. Für das Schreiben von Daten in den CRCF-Datenbestand existiert bisher ebenfalls noch kein Befehl. Der Bedarf für folgende Begriffe ist vorhanden:

; Daten schreiben (CONFSET)
:: Befehl zum Schreiben von CRCF-Daten in eine CRCF-Datenbank (Warum reicht hier nicht SET und GET analog zum SRCP-Namensraum? Antwort: Der Befehl CONFGET ist bisher Bestandteil des SRCP-Namensraumes).
; 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.
; Gleisbild (LAYOUT)
:: Streckennetzbeschreibung eines Stellwerkbezirks, enthält Angaben zur Dimension, Position einzelner Gleisbildelemente, automatischer Streckenblöcke, Fahrstraßen, etc.
; 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.
; 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).
(TODO: weitere ergänzen)

==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:

# Der Wert ist 0: Rundruf (Broadcast)
# 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 ....

[[Bild:SRCP_GM.png|framed|Nachrichtenfluß über Generic Messages. CS: COMMAND-Sitzung, IS: INFO-Sitzung]]
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.

* <del>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.</del>
Anmerkung: Es gibt bereits genügend SRCP-Kommandos, um Informationen direkt beim Server zu erfragen. Dieser Punkt ist daher irrelevant.

* <del>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.</del>
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.

[[Kategorie:SRCP]]

SRCP-Erweiterungen

2009-02-07T12:48:06Z

Michael Oppenauer: /* CRCF-Erweiterungen */ Namensgebung

==Das initiale Posting==

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 [[Digitalprojekt|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:

# 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.
# 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.

Es gab eine rege Beteiligung an der Diskussion, beide Ideen wurden darin ausführlich diskutiert.

==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.

{| border="1" align="center" width="50%"
|+
! SRCP-Interessierter
! Wohnort

|-
| Sven Schlender
| Karlsruhe

|-
| Stefan Bormann
| Bremen

|-
| Guido Scholz
| Burgkirchen

|-
| ...
| ...
|}

==SRCP-Server-Suchdienst==
Sehr schnell kam der Vorschlag, für diesen Bedarf einen [http://www.zeroconf.org/ 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:

* [http://www.apple.com/macosx/features/bonjour/ Bonjour], von Apple für Mac, UNIXoide-Systeme und Windows.
* [http://avahi.org/ 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 [http://www.iana.org/ 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_0.2.0|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===
[[Bild:Crcf-old.png|framed|Nachrichtenfluß gemäß der CRCF-Spezifikation Version 0.2.0. CS: COMAND-Sitzung]]
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====
[[Bild:srcp-crcf-client.png|framed|Nachrichtenfluß bei einem Betrieb mit einem als CRCF-Server arbeitenden SRCP-Client. CS: COMAND-Sitzung, IS: INFO-Sitzung]]
Ü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====
[[Bild:srcp-crcf-server.png|framed|Nachrichtenfluß bei einem Betrieb mit getrennten SRCP- und CRCF-Servern. CS: COMAND-Sitzung, IS: INFO-Sitzung, ...: nicht geklärt]]
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====
[[Bild:Crcf-client-server.png|framed|Nachrichtenfluß bei einem Betrieb mit als CRCF-Servern und -Clients arbeitenden SRCP-Clients. CS: COMAND-Sitzung, IS: INFO-Sitzung]]
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.

===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. Für das Schreiben von Daten in den CRCF-Datenbestand existiert bisher ebenfalls noch kein Befehl. Der Bedarf für folgende Begriffe ist vorhanden:

; Daten schreiben (CONFSET)
:: Befehl zum Schreiben von CRCF-Daten in eine CRCF-Datenbank (Warum reicht hier nicht SET und GET analog zum SRCP-Namensraum? Antwort: Der Befehl CONFGET ist bisher Bestandteil des SRCP-Namensraumes).
; 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.
; Gleisbild (LAYOUT)
:: Streckennetzbeschreibung eines Stellwerkbezirks, enthält Angaben zur Dimension, Position einzelner Gleisbildelemente, automatischer Streckenblöcke, Fahrstraßen, etc.
; 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.
; 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).
(TODO: weitere ergänzen)

==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:

# Der Wert ist 0: Rundruf (Broadcast)
# 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 ....

[[Bild:SRCP_GM.png|framed|Nachrichtenfluß über Generic Messages. CS: COMMAND-Sitzung, IS: INFO-Sitzung]]
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.

* <del>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.</del>
Anmerkung: Es gibt bereits genügend SRCP-Kommandos, um Informationen direkt beim Server zu erfragen. Dieser Punkt ist daher irrelevant.

* <del>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.</del>
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.

[[Kategorie:SRCP]]

Gattungszeichen

2009-02-05T19:09:56Z

Michael Oppenauer: Link auf LEO hinzugefügt

Decoder

2009-01-10T12:47:30Z

Michael Oppenauer: /* Lokdecoder */ Link zur Seite von Reinhard Müller eingefügt

Digitalsysteme übertragen neben der elektrischen Antriebsenergie für Fahrzeuge und Magnetartikel noch digital kodierte Informationen über die Spannungsversorgung, die von einem Elektronikbaustein, dem Decoder, entschlüsselt und in Steuervorgänge umgesetzt werden. Man unterscheidet zwei verschiedene Varianten, den Lokdecoder und den Schaltdecoder.

Lokdecoder setzen die für sie über eine digitale Adresse gekennzeichneten Informationen für Fahrtrichtungs- und Geschwindigkeitsänderungen um und ermöglichen so einen Mehrzugbetrieb. In jedem Triebfahrzeug verarbeitet ein Lokdecoder die ihn betreffenden Informationen und steuert den Lokmotor sowie weitere Funktionsausgänge entsprechend an. Der Decoder ist quasi der mitfahrende "Lokführer".

Schaltdecoder schalten einzelne Ausgänge über binäre Signale ein oder aus. Sie dienen im allgemeinen zum Ansteuern von Magnetartikeln, wie Weichen, Signalen etc.

__TOC__

= Funktionsweise =

Mit einem Digitalsystem können mehrere Züge unabhängig voneinander auf demselben Gleis betrieben werden. Dazu werden die Fahrbefehle für die verschiedenen Züge und die Schaltbefehle in einer digitalen Form von der [[Digitalzentrale]] erzeugt. Dieses Digitalsignal entspricht einem definierten [[Digitalprotokoll]] und wird vom [[Booster]] dem Fahrstrom aufgeprägt.

Jede Lok muß im Digitalbetrieb mit einem »Lokdecoder« ausgerüstet sein. Diese Elektronik dekodiert die im Fahrstrom enthaltenen Informationen, die aus einer Adresse und einem Befehl bestehen. Wenn die empfangene Adresse mit der eigenen Decoderadresse übereinstimmt, wertet der Decoder den Befehl aus:

* Fahrstufe und Fahrtrichtung ändern
* Funktionsausgang schalten

Die Motoransteuerung geschieht im allgemeinen über [[PWM|Pulsweitenmodulation]], da dies die im Decoder entstehende Verlustleistung minimiert.

In ähnlicher Weise reagieren ''Schaltdecoder'' auf entsprechende Schaltbefehle, um Weichen, Signale oder anderes Funktionszubehör anzusteuern.

= Lokdecoder =

Eine gute Übersicht über DCC Decoder und deren Eigenschaften bietet die Seite von [http://www.dcc-mueller.de/decoder/dectab_d.htm Reinhard Müller].

== Auswahlkriterien==

Bei der Auswahl eines Lokdecoders spielen neben dem verwendeten Digitalsystem vor allem die gewünschten Zusatzfunktionen eine Rolle:

* Digitalsystem
: Der Decoder muß das auf der Anlage verwendete [[Digitalprotokoll]] verstehen und insoweit zu der eingesetzten [[Digitalzentrale]] passen.
* Baugröße
: Der Decoder muß klein genug sein, damit er in das vorgesehene Lokomotivmodell hineinpaßt.
* Belastbarkeit
: Der Decoder muß den vom Motor und von den Sonderfunktionen benötigten Strombedarf schalten können. Bei Überlastung besteht die Gefahr, den Decoder und möglicherweise auch das Lokmodell (wegen zu großer Wärmeentwicklung) zu beschädigen.
* Normschnittstelle
: Zum einfacheren Nachrüsten und Austauschen sind viele Lokomotiven und Lokdecoder mit einer einheitlichen [[NEM]]-Schnittstelle (einem Vielfachsteckverbinder) ausgestattet.
* Fahrstufenanzahl
: Je mehr Fahrstufen ein Lokdecoder unterstützt, desto feinfühliger läßt sich das Fahrzeug steuern.
* Funktionsausgänge
: In vielen Digitalsystemen sind neben dem Lokmotor verschiedene Zusatzfunktionen (z. B. Licht, Rauch, Sound, ferngesteuerte Kupplungen) schaltbar. Z. T. sind diese Ausgänge auch dimmbar.
* SUSI-Schnittstelle
: Über die SUSI-Schnittstelle gibt ein Lokdecoder Informationen über den Betriebszustand (Geschwindigkeit, Fahrtrichtung, Anfahren, Abbremsen etc.) über ein serielles Format an andere Elektronikbausteine weiter. Dadurch können z. B. dort angeschlossene Soundbausteine die korrekten Klänge erzeugen.
* [[Lastregelung]]
: Moderne Lokdecoder sind häufig mit einer Lastregelung ausgestattet, die die Zuggeschwindigkeit unabhängig von Steigung oder Gefälle konstant hält.
* Spezielle Features
: In einigen Lokdecodern sind spezielle Features wie eine Anfahr- und Bremssteuerung (z. B. Lenz ABC, Zimo HLU) enthalten, die ein vorbildgerechtes Fahrverhalten in einer Blocksteuerung ermöglichen.
* »Normaler« Motor oder Glockenankermotor
: Aufgrund der besonderen Eigenschaften von [[Glockenankermotor]]en muß die Pulsweitenmodulation angepaßt werden (höhere Frequenzen: 10-30 kHz).

== Einstellparameter ==

In Lokdecodern sind zahlreiche Parameter einstellbar, wie z.B.:

* Mindest- und Höchstgeschwindigkeit
* Anfahr- und Bremsbeschleunigung
* Geschwindigkeitskennlinie
* P- und I-Faktoren für Lastregelung ([[Wie_arbeitet_die_Lastregelung%3F#Einstellung_der_P-_und_I-Faktoren|Einstellhinweise]])

Diese Parameter sind über die Digitalzentrale oder spezielle Computersoftware programmierbar. Einzelheiten sind den Handbüchern zu den Decodern und Digitalzentralen zu entnehmen.

Im [[DCC]]-System werden diese Parameter ''Konfigurationsvariablen'' (Configuration Variables, CVs) genannt.

== Funktionsdecoder ==

Funktionsdecoder reagieren auf Lokbefehle, enthalten selbst jedoch keinen Motorausgang.
Sie dienen dazu zusätzliche Funktionen in ein Lokmodell zu bringen oder Funktionen in einem
nicht angetriebenen Modell zur Verfügung zu stellen (Licht, Spitzenbeleuchtung, ...)

== Sounddecoder ==

Sounddecoder bringen Betriebsgeräusche des Vorbilds auf die Modellbahn.
Sie werden wie Lokdecoder angesprochen und über die Funktionen geschaltet. 
Es gibt mehrere Bauformen:

* Einfacher Sounddecoder
: Dieser liefert nur den Sound und hat keine eigene Motorsteuerung. Dafür kann er aber z.B. auch in einen Geisterwagen eingebaut werden. Oft die einzige Lösung bei schwierigen Platzverhältnissen.
* Als Zusatzmodul zu einem Lokdecoder
: Dies dient a) zur Nachrüstung und b) zum einfacheren Einbau durch zwei kleinere Teile. Durch die Anbindung an einen Lokdecoder können teils die Geräusche lastabhängig verändert werden. Für diese Bauform wird oft die SUSI-Schnittstelle verwendet.
* Integrierter Lok- und Sounddecoder
: Hier ist die akustische Integration in das Fahrverhalten am einfachsten möglich. Integrierte Decoder sind in der Regel größer als vergleichbare Lokdecoder jedoch meist in Summe kleiner als ein Lokdecoder + Sound-Zusatzmodul.

Sounddecoder brauchen zusätzlichen Platz und Strom sowie eine Einbaumöglichkeit für den notwendigen Lautsprecher. Loks / Baugrößen mit viel Platz sind hier klar im Vorteil.

Die Qualität der Sounds hängt von den Fähigkeiten des Sounddecoders, der Qualität der Sounddateien und der Qualität des Lautsprechers ab. Allerdings sind auch bei besten Lautsprechern besonders bei kleinen Modellen Einbußen in der Tonqualität unvermeidbar. Dies ist bedingt durch die akustischen Wellengesetze (Wellenlänge bezogen auf Größe des Erregers).

= Schaltdecoder =

Schaltdecoder arbeiten prinzipiell ähnlich wie ein Lokdecoder ohne Motorausgang. Je nach Einsatzzweck unterscheidet man

* Schaltdecoder mit geschalteten Kurzzeitausgängen
* Schaltdecoder dauerhaft geschalteten (Relais-)Ausgängen
* Lichtsignaldecoder, die für eine vorbildgetreue Ansteuerung der Signalbilder (z. B. mit langsamen Bildwechsel) sorgen
* Weichendecoder zur Ansteuerung von motorisch angetriebenen Weichen
* Servodecoder, die die Ansteuerung von Modellbauservos z. B. als Weichenantrieb ermöglichen
* Sonderdecoder für z. B. Kranmodelle, Drehscheiben, Lichtsteuerung etc.

Die Baugröße von Schaltdecoder ist häufig nicht so kritisch wie bei Lokdecodern, da sie häufig unterhalb der Anlage montiert werden. Aus diesem Grund gibt es auch einige Bausätze und Selbstbaudecoder.

Schaltdekoder müssen die Energie für die auszuführende Aktion nicht zwingend dem Digitalsignal entnehmen, sondern sind oft mit einer zusätzlichen Einspeisemöglichkeit ausgerüstet. Dies erleichtert
bei größeren Anlagen die Energieverteilung.

Eine Ausnahme bilden spezielle Weichendecoder, die bei Gleisen mit integrierter Bettung innerhalb des Bettungskörpers installiert werden.

[[Kategorie:Digitalbetrieb]]

Schattenbahnhof

2008-11-26T18:57:39Z

Michael Oppenauer: /* Fiddle Yard */ Link hinzugefügt

{{Glossar}} Ein Schattenbahnhof ist ein (nicht sichtbarer) Abstellbahnhof. Er dient dazu, komplette Züge abzustellen und dadurch die sichtbare Zugfolge auf der Modellbahn abwechslungsreicher zu gestalten. Schattenbahnhöfe können manuell oder automatisch gesteuert werden.

Weil Schattenbahnhöfe im allgemeinen verdeckt angeordnet sind, ist ein handwerklich sauberer Aufbau für einen sicheren Betrieb unabdingbar. Außerdem sollten alle Gleise mit [[Besetztmelder|Besetztmeldern]] ausgestattet sein, damit der Bediener weiß, in welchen Gleisen Züge stehen.

Eine besondere Form des Schattenbahnhofs ist der sogenannte "Fiddle Yard", der zum manuellen Bilden und Umstellen von Zügen genutzt werden kann. Er ist daher gut zugänglich außerhalb der landschaftlich gestalteten Anlage angeordnet.

== Wozu braucht eine Modellbahnanlage so was eigentlich? ==

Oft werden auf einer Modellbahn mehr Züge eingesetzt, als im sichtbaren
Teil der Anlage untergebracht werden können. Im Schattenbahnhof können
diese abgestellt werden.

== Wie groß muss ein Schattenbahnhof sein? ==

Je mehr Gleise ein Schattenbahnhof hat, um so mehr Züge können dort
abgestellt werden. Auch wenn der Schattenbahnhof beim Bau der Anlage "zu
groß" ist, so füllt sich der übliche Schattenbahnhof meist schnell und
erscheint später "zu klein".

== Wie lang müssen die Gleise im Schattenbahnhof sein? ==

Das längste Abstellgleis im Schattenbahnhof definiert die maximale
Zuglänge. Längere Züge müssen entweder bei der Einfahrt geteilt werden
oder "draußen bleiben".

== Kann ein Schattenbahnhof komplett umbaut werden? ==

In jedem Schattenbahnhof wird irgendwann einmal ein Zug entgleisen oder
eine Weiche beschädigt. Ist der Schattenbahnhof nicht zugänglich, so
kann das sehr frustrierend werden. Deshalb sollte jeder Punkt des
Schattenbahnhofs "erreichbar" sein. Im Idealfall kann der
Schattenbahnhof (oder ein Teil davon) für Wartungsarbeiten demontiert
werden.

== Wie kommen die Züge in den Schattenbahnhof? ==

Die Phantasie des Erbauers ist gefragt - den sichtbaren Teil der Anlage
verlässt ein Zug z.B. durch einen [[Tunnel]] oder "hinter" einer Brücke bzw.
einem Gebäude. Je nach Anordnung des Schattenbahnhofs reicht eine
Durchfahrt, eine einfache Rampe oder es bedarf der Konstruktion einer
[[Gleiswendel]].

Weitere interessante Möglichkeiten für die Zufahrt zum Schattenbahnhof
wären:
- eine Eisenbahnfähre
- ein "Eisenbahn-Lift"
- ...

== Welche Elemente braucht ein Schattenbahnhof? ==

Je nach vorhandenem Platz und gewünschtem Betrieb der Anlage werden
folgende Elemente benötigt:
- Wendeschleife
- Abstellgleise
- Rangiergleise
- Schiebebühne
- Gleis zum Einsetzen der Wagen
- Anschluss für ein Zug-Aufbewahrungs-System

== Welche Gestaltungsmöglichkeiten gibt es? ==

=== Fiddle Yard ===
Ein Fiddle Yard ist häufig nur ein gerades Stück Gleis, auf dem die
Waggons und Loks nach Bedarf aufgegleist werden. Er kann aus mehreren
Gleisen bestehen und durch eine Schiebebühne oder eine Drehscheibe
ergänzt werden.

Verschieden Möglichkeiten, wie man ein Fiddle Yard gestalten kann findet man auf der englischsprachigem [http://rail.felgall.com/fyd.htm Seite von Stephen Chapman].

=== Stumpfgleise ===
Das Zufahrts-Gleis mündet über Weichen in mehrere
Abstellgleise. Der Schattenbahnhof verfügt meist nur über eine Zufahrt.

<pre>
___________________
/___________________
____/____________________
\_____________________
\____________________
</pre>

=== Hintereinander-Parker ===
Ein sehr langes Gleis wird in Abschnitte
eingeteilt, in denen mehrere Züge hintereinander parken. Häufig werden
Gleiswendeln zu diesem Zweck verwendet, wobei zu beachten ist, dass nur
Züge auf die Anlage können, die direkt am Ausfahrgleis stehen. Will man
einen Zug ausfahren lassen, der "in der Mitte" steht, so müssen mehrere Züge umgeparkt
werden.

=== [[Kehrschleife]] ===
Meist ein Bestandteil von Schattenbahnhöfen, ein
Gleis dass von den Zügen durchfahren werden kann, um "umzudrehen". Eine
solche [[Kehrschleife]] ist oft im Betriebs-Konzept einer Anlage vorgesehen
und kann als solche nicht zum Abstellen von Zügen verwendet werden
(dafür müssen extra Abstellgleise vorgesehen werden).

<pre>
______
/ \
/ \
_____/ |
\ |
\ /
\________/
</pre>

=== Gleisharfe ===
Eine Reihe von Abstellgleisen, die an beiden Enden
angebunden sind (im Gegensatz zu Stumpfgleisen). Bei einer Gleisharfe
ist im Allgemeinen darauf zu achten, dass ein Gleis als Durchfahrtsgleis
reserviert wird und nicht zum Abstellen von Zügen verwendet wird.

Um möglichst gleichmäßige Gleislängen zu erhalten ist bei der Anordnung der Weichen die Variante A der Variante B vorzuziehen.

'''Variante A:'''
<pre>
___________________________
/______________________/
/______________________/
____/______________________/
</pre>

'''Variante B:'''
<pre>
__________________
/__________________\
/____________________\
____/______________________\______
</pre>

=== Gleis zum Einsetzen von Wagen ===
Auch dem vorsichtigsten Modellbahner
wird hin und wieder ein Wagen (oder ein Zug) entgleisen. Dann ist es
hilfreich, wenn an einer gut zugänglichen Stelle des Schattenbahnhofs
ein gerades Gleis zur Verfügung steht, um die Wagen gleich wieder
einzusetzen. An Stelle eines Prellbocks kann hier gleich das
Eingleiswerkzeug befestigt werden (dann ist es immer zur Hand). Dieses
Gleis kann auch bei Bedarf zum Rangieren von Zügen (wenn die Wagen mal
vertauscht werden sollen) oder als "Fiddle Yard" dienen.

=== Anschluss für ein Aufbewahrungs-System ===
Gerade bei kleinen Anlagen
ist oft nicht genug Platz, um alle Züge im Schattenbahnhof
unterzubringen. Eine Möglichkeit ist die Aufbewahrung der Züge in
"Röhren" (Vitrinen). Bei Bedarf wird eine solche Vitrine an ein freies
Gleis angesetzt und der Zug kann gleich auf die Anlage auffahren.

== Wie bekomme ich das alles auf meiner Anlage unter? ==

Nicht alle erläuterten Teile müssen realisiert werden. Vielmehr sollte
man sich für eine sinnvolle Mischung entscheiden, die sowohl räumlich
als auch betrieblich sinnvoll ist.

== Beispiele ==

++ Raum für Beispiele ++

[[Kategorie:FAQ]]
[[Kategorie:Grundlagen]]

Digitalzentralen - aktuelle Systeme

2008-11-16T15:36:01Z

Michael Oppenauer: Formatierung unbekannter Spannungen

[[Kategorie:Digitalbetrieb]]

'''Übersicht der aktuell verfügbaren Digitalzentralen.'''

{{Zentralverweise}}

 

Dieser Artikel ist nach einfachen, mittleren und vollen Systemen unterteilt.
Diese Gliederung dient dazu, die Dinge einigermaßen übersichtlich zu halten.
Innerhalb der einzelnen Abschnitte sind die Systeme alphabetisch nach dem Namen des Herstellers sortiert.

== Einsteiger-Zentralen ==

Einfache Zentralen, mit reduziertem Funktionsumfang.

<div style="font-size:0.8em">
{{Zentraltipps}}

{| {{Zentraltabelle}}
{{Zentralheader}}

|-
| Fleischmann '''LokBoss'''
| DCC
| 0 / 1 (max. 4)
| 4 LEDs, Adr. 1–4
| 1,8A, {{r}}V (-) || -
| [[LocoNet]] / -
| Adr. 1-4 / nein
| nein
| - / [[LocoNet]]
| nein
| Einfachst-Regler am LocoNet (Adr. 1–4). Zusatzregler = LokBoss oder FMZ–Regler (seit 2003/4)

|-
| Piko '''Digi-1'''
| DCC
| 0 / 1 (max. 4)
| nein
| 1,8A, {{r}}V (-) || Gleissignal
| Iris (Infrarot) / nein
| Adr. 1-127, 28 Fahrst. / nein
| nein
| - / -
| nein
| Digi-Fern = Uhlenbrock Iris, max. 12 Loks aktiv (seit 2004/5)

{{Zentralheader}}

|}
</div>

 

== Zentralen mit Einschränkungen ==

Zentralen, die einen Großteil des Funktionsumfanges der jeweiligen Protokolle unterstützen, aber aufgrund bestimmter Einschränkungen nicht für den Betrieb großer Anlagen geeignet sind.

<div style="font-size:0.8em">
{{Zentraltipps}}

{| {{Zentraltabelle}}
{{Zentralheader}}

|-
| Bachmann '''EZ Command Dynamis'''
| DCC
| 0 / 1 (IR)
| LCD Display Beleuchtet
| 2.5A, 15.5V (+) || ja (über Pro-Box)
| {{r}}, IR / {{r}}
| POM / {{r}}
| 40 á 5 Loks
| - / ja
| {{r}}
| JoyStick BiDi vorbereitet, Erweiterung über Pro–Box (seit Dez. 2007)

|-
| Digitrax '''Zephyr'''
| DCC
| 1 / 0 '''(1)'''
| 4–stellig
| 2.5A, 12.8V (+) || [[LocoNet]]
| [[LocoNet]] / [[LocoNet]]
| POM+Prog, bis 255 / Prog-Gleis
| Zentrale, Decoder
| - / ja
| nein
| max. 10 Loks aktiv, Fahrregler / Booster am [[LocoNet]]. (seit 2002/3)

|-
| Fleischmann '''Profi-Boss'''
| DCC
| 0 / 1
| LCD Display Beleuchtet
| 1.8A, 18V (+) || [[LocoNet]]
| [[LocoNet]] / [[LocoNet]]
| POM+Prog / Prog-Gleis
| nein
| nein / ja
| Twin Center
| max. 16 Loks aktiv, Handregler am [[LocoNet]]. (seit Mitte 2008)

|-
| Hornby '''Select'''
| DCC
| 1 / 0
| 2 Ziffern
| 1/3A, 15V ({{r}}) || ja (RJ12)
| X–Bus / -
| ja / {{r}}
| Doppel Traktion
| - / ja
| {{r}}
| bis 10 Loks aktiv, Adr. 1-59 (Loks), 60-99 (Weichen) (seit Dez. 2007)

|-
| Hornby '''Elite'''
| DCC
| 2 / 0
| LCD Display
| 3A, 15V ({{r}}) || 5-polig, Gleis-Signal, (RJ12)
| X–Bus / -
| POM+Prog / Prog-Gleis
| Doppel Traktion
| USB / ja
| PC
| BiDi (RailCom) vorbereitet, 254 Lok + 255 Weichen Adressen (seit Dez. 2007)

|-
| LGB '''(2)''' '''MZS II'''
| DCC (Basic)
| 0 / 0
| LEDs
| 5A, {{r}}V ({{r}}) || ja, max. 4
| LGB-Bus / LGB-Bus
| nur Adresse / -
| nur mit Universal Handy
| - / ja
| nein
| Großbahn, 23 Adr. 14 Fahrst., max. 8 Loks aktiv ''(Nachfolge: MZS III)'' (seit 200?)

|-
| Littfinski Datentechnik '''DiCoStation'''
| DCC, MM
| 0 / 0
| 2 LED
| - || 5-polig
| - / 3x [[S88-Rückmeldebus|S88]]
| {{r}} / {{r}}
| {{r}}
| USB / -
| PC
| '''kein BiDi''', Prog-Gleis nur über Erweiterung, braucht PC–Steuerung (seit Mitte 2007)

|-
| MärklinSystems '''MobileStation'''
| mfx, MM
| 0 / 1
| LCD Screen
| 1.2A/1.9A, {{r}}V ({{r}}) || nein
| {{r}} / {{r}}
| ja / ja
| kein
| - / -
| {{r}}
| max. 10 Loks aktiv, MM: nur 80 Adr., 14 Fahrst. (seit 2004)

|-
| Roco '''MultiMaus''' ((+Verstärker))
| DCC
| 0 / 1
| LCD Display Beleuchtet
| ((3/3.2A, {{r}}V ({{r}}))) || ja
| X–Bus / {{r}}
| POM+Prog, bis 255 / nein*
| nein
| - / ja
| Rocomotion + PC
| Handregler am X–Bus, *Verstärker ungeeignet. (seit 2006)

|-
| Trix Systems '''MobileStation'''
| DCC, SX
| 0 / 1
| LCD Screen
| 1.9A, {{r}}V ({{r}}) || nein
| {{r}} / kein
| bis 999 / bis 999
| {{r}}
| - / -
| Central Station+PC / zweite MS
| max. 16 Loks aktiv (seit 2006)

{{Zentralheader}}

|}
'''Anmerkungen:'''
# Am JumpPort des Digitrax Zephyr können 1 oder 2 Analog-Fahrregler angeschlossen werden, die je eine zugewiesen Digital-Lok steuern.
# Der LGB-Bus basiert wahrscheinlich auf einer älteren X–Bus Version.
</div>

 

== Vollsysteme ==

Zentralen, die den vollen Funktionsumfang der jeweiligen Protokolle unterstützen und zur Steuerung großer bis sehr großer Anlagen geeignet sind.

<div style="font-size:0.8em">
{{Zentraltipps}}

{| {{Zentraltabelle}}
{{Zentralheader}}

|-
| CT-Elektronik '''ZF5 + HR3'''
| DCC, MM
| 0 / 1
| LED (ZF5), LCD 128x64 (HR3)
| 1-5A, 10-21V (+) || 3-polig
| X–Bus / {{r}}
| POM+Prog/ Prog-Gleis
| ja, 100x6 Loks
| RS232 / -
| PC
| HR3 steuert 2 Loks, BiDi und Selectrix geplant. (seit 2006/7)

|-
| Digitrax  '''SuperChief''' (DCS100/200 + DT400)
| DCC, (MM1)
| 0 / 1
| LED (DCS...), LCD 2 Zeilen (DT400)
| 5/8A, 12/15/20V (+) || [[LocoNet]]
| [[LocoNet]] / [[LocoNet]]
| POM+Prog/ Prog-Gleis
| Dekoder, Zentrale
| - / ja
| Prozessor tauschen
| Für extreme Anforderungen: 120 aktive Loks/Fahrregler, DT400=2 Loks, DCS200=8A (seit 1995/6)

|-
| ESU '''ECoS'''
| DCC, BiDi, MM, SX, ''mfx''
| 2 / 0 '''(1)'''
| Touch Screen, 320x240
| 2-4A, {{r}}V ({{r}}) || 3/5-polig, ECoSLink '''(2)'''
| ECoSLink, ECoSniffer / [[S88-Rückmeldebus|S88]]
| POM+Prog/ POM+Prog
| Zentrale, 32x16 Loks
| Ethernet / -
| PC
| '''BiDi''' seit 11/2007. ''Version 3: +mfx, +Gleisbild (Frühjahr 2009)'' (seit Mitte 2006)

|-
| Fleischmann '''Twin Center'''
| DCC, FMZ, SX
| 2 / 0
| LCD, 2x16 Zeichen
| 3A, N=18V, H0~21V (-) || 3+5-polig, FMZ
| [[LocoNet]], I2C, Lokmaus1 / [[LocoNet]], [[S88-Rückmeldebus|S88]]
| POM+Prog/ Prog-Gleis
| Zentrale, 8x4 Loks
| RS232 / ja
| PC
| auch für FMZ Decoder, Hardware basiert auf Intellibox von Uhlenbrock (seit Ende 2000)

|-
| Lenz '''LZV100'''
| DCC, BiDi
| 0 / 0
| LED (Status)
| 5A, 11-22V ({{r}}) || 3-polig
| X–Bus / RS–Bus
| POM+Prog/ POM+Prog
| Decoder
| - / ja
| EPROM Austausch
| '''BiDi''' (RailCom) ab Version 3.5 (seit ca. 2003)

|-
| Massoth '''DiMAX 800Z'''
| DCC
| 0 / 0
| LCD, 4 Zeilen
| 2/4/8A, 16-24V (+) || ja
| Control–Bus/ Control–Bus '''(3)'''
| Prog-Gleis/ Prog-Gleis
| Zentrale, 16x4 Loks
| RS232
| PC
| für Großbahnen und kleinere Baugrößen (seit ca. 2005)

|-
| Massoth '''DiMAX 1200Z'''
| DCC
| 0 / 0
| LCD, 4 Zeilen
| 4/7/12A, 22-24V (+) || Massoth, LGB, 3-polig
| Control–Bus/ Control–Bus '''(3)'''
| Prog-Gleis/ Prog-Gleis
| Zentrale, 16x4 Loks
| RS232
| PC
| nur für Grossbahn, Trafo eingebaut (seit 2003/4)

|-
| Märklin '''Central Station 2'''
| mfx, MM, ''DCC''
| 2 / 0
| Touch Screen, Farbe, 800x480
| 3A, {{r}}V ({{r}}) || 5-polig, Märklin-Bus
| Märklin-Bus '''(4)''' / [[S88-Rückmeldebus|S88]]
| ja / mfx Decoder
| Zentrale
| Ethernet
| PC, USB-Stick, Internet
| Gleisbild, Lokkarten, mehrere CS2 koppelbar, USB-Maus/-Tastatur, ''DCC ab Version 1.0.7 (11/2008)'' (seit 10/2008)

|-
| Müt Digirail '''multi control 2004'''
| SX
| 1 / 0
| LCD Matrix
| 2.7A, {{r}}V ({{r}}) || ja
| SX–Bus (2x) / SX–Bus
| ja / ja
| Zentrale, 20x5 Loks
| RS232
| PC
| (seit ca. 2000/1)

|-
| Piko '''Digi Power Box'''
| DCC
| 2 / 0
| LCD, 2x16 Zeichen
| 3A, {{r}}V (-) || 3-polig
| [[LocoNet]], Iris / [[LocoNet]]
| ja / ja
| bis zu 4 Loks
| RS232 / ja
| PC
| Hardware basiert auf Intellibox IR von Uhlenbrock (seit ca. 2005)

|-
| Rautenhaus Digital '''SLX850'''
| SX, DCC
| 0 / 0
| -
| 1.5A, {{r}}V ({{r}}) || ja
| SX–Bus / SX–Bus
| ja / ja
| ja
| -/ja
| Processor Update möglich
| DCC: nur 8 Adr., 28 Fahrst., 4 Funkt. ''Nachfolger: SLX850AD'' (seit {{r}})

|-
| Tams '''EasyControl'''
| DCC, BiDi, MM
| 1 / 0
| LCD, 2x16 Zeichen
| - || 3+5-polig
| EasyNet / [[S88-Rückmeldebus|S88]]
| POM+Prog/ Prog-Gleis
| Doppel Traktion
| USB und RS232 / -
| PC
| MM 14/27 Fahrst. 255 Adr., 2ter Booster Ausgang, '''BiDi''' (RailCom) ab V1.45 (seit 2005/6)

|-
| Uhlenbrock '''Intellibox IR'''
| DCC, MM, SX
| 2 / 0
| LCD, 2x16 Zeichen
| 3A, N=18V, H0~21V (-) || 3+5-polig, [[LocoNet]]
| [[LocoNet]], I2C, LM1, IRIS / [[LocoNet]], [[S88-Rückmeldebus|S88]]
| POM+Prog/ Prog-Gleis
| Zentrale, 8x4 Loks
| RS232 / ja
| PC
| MM bis 255 Adressen, LM1: Lokmaus1 (seit 1998, IB-IR 2005)

|-
| Viessmann '''Commander'''
| DCC, MM
| 2 / 0
| Touch Screen, Farbe, 800x480
| 3A, {{r}}V ({{r}}) || 3+5-polig
| HSB+LSB '''(5)''' / [[S88-Rückmeldebus|S88]], LSB
| ja / ja
| ja
| USB
| PC
| Automatik, Gleisbild, Stellpult, mehrere Com. koppelbar, BIDi ab 2009 (seit 12/2007)

|-
| Zimo '''MX31ZL'''
| DCC, BiDi
| 1 / 0
| LCD Display
| 1-3A '''(6)''', 12-19V (+) || ja
| CAN Bus / CAN Bus
| POM+Prog/ POM+Prog
| ja
| USB / ja
| PC oder USB-Stick
| USB–Interface für MX1*, Decoder Updates, '''BiDi''' eingebaut (seit 10/2007)

|-
| Zimo '''MX1, MX1EC, MX1HS''' (Modell 2000)
| DCC, MM
| 0 / 0
| LCD 2 Zeilen
| 8A, 12-24V (+) || 3-polig, CAN Bus
| CAN Bus / CAN Bus
| POM+Prog/ Prog-Gleis
| ja
| RS232 / ja
| PC
| HS: Hochstrom (2x8A), EC: Economy (ohne LCD), BiDi ab 2009 (seit 2000/1)

{{Zentralheader}}

|}
'''Anmerkungen:'''
# Die Märklin MobilStation kann als Handregler an die ECoS-Zentrale von ESU angeschlossen werden. Die Trix MobileStation ist weder zur Märklin CentralStation1 noch zu ECoS kompatibel.
# Nur mit ECoS Boostern können das SX-Protokoll verstärkt und Rückmeldungen (BiDi/mfx) an die Zentrale (ECoS oder CentralStation1) weiter gereicht werden.
# Der Massoth Control-Bus basiert wahrscheinlich auf einer X–Bus Version. Massoth-Protokoll (=DCC) ab 2005, davor LGB-kompatibel (MZS II).
# Der Märklin-Bus der CentralStation2 (CS2) verwendet (wie ESU, Zimo, ...) CAN als Hardware-/Protokoll-Basís. Der Bus der CentralStation1 (CS1) hatte Gemeinsamkeiten mit ESUs ECoSLink (z.B. Booster-Anschluss). Ob und wie weit das auch für den Märklin-Bus der CS2 gilt, ist zur Zeit unklar.
# Der Viessmann LowSpeedBus (LSB) unterstützt X–Bus Geräte wie Roco Rückmelder/Lokmaus2/MultiMaus oder Lenz Handregler.
# Mit dem stabilisierten, einstellbaren 120W Netzteil kann das MX31ZL bis zu 4A liefern.
</div>

Digitalzentralen - Neuvorstellungen

2008-11-16T15:34:16Z

Michael Oppenauer: Formatierung unbekannter Spannungen

[[Kategorie:Digitalbetrieb]]

{{Zentralverweise}}

In diesem Artikel sind diejenigen Digitalzentralen aufgeführt,
die vom Hersteller angekündigt aber noch nicht lieferbar sind. 
Vom Hersteller angegebene Liefertermine sind mit der gebotenen Toleranz zu betrachten.

<div style="font-size:0.8em">
{{Zentraltipps}}

{| {{Zentraltabelle}}
{{Zentralheader}}

|-
| Bachmann '''EZ Command Dynamis Pro'''
| DCC
| 0 / 1
| LCD Display
| {{r}}A, {{r}}V ({{r}}) || ECoSlink
| ECoSlink, IR / ECoSlink?
| POM+Prog / Prog-Gleis
| 40 á 5 Loks
| ja / ja
| {{r}}
| JoyStick statt Drehknopf, BiDi vorbereitet, Pro-Box enthalten (Anfang 2008)

|-
| Märklin/ESU '''CentralStation''' '''Reloaded'''
| mfx, MM, '''DCC, SX'''
| 2 / 0
| Touch Screen, 320x240
| '''4A (+), 15-21V''' || 5-polig, '''ECosLink'''
| '''ECosLink''', Sniffer MM+'''DCC''' / '''ECosLink''', [[S88-Rückmeldebus|S88]]
| ja / mfx- und DCC-Decoder
| Zentrale
| Ethernet
| PC
| Weiterentwicklung durch ESU '''Update 3.0.0''' (Frühjahr 2009) MM: 255 Adr., +DCC, +SX (Loks), +Gleisbild, +Netzteil =>4A, +ECOSLink, +Funk/IR

|-
| Roco  '''(1)''' '''MultiZentralePRO''' mit MultiMausPRO
| DCC
| 0 / 1
| LCD Display Beleuchtet
| 3,2A, {{r}}V (+) || ja
| X–Bus, Funk / Roco (X-Bus)
| POM+Prog / Prog-Gleis
| Doppel Traktion
| USB / ja
| PC
| Steuersoftware im Set enthalten. BiDi vorbereitet. (Ende 2008)

|-
| Trix Systems '''Central Station'''
| DCC, SX
| 2 / 0
| Touch Screen, 320x240
| {{r}} ({{r}}) || ja
| {{r}} / {{r}}
| {{r}} / {{r}}
| {{r}}
| Ethernet / {{r}}
| {{r}}
| noch kein Liefertermin ''Vermutlich wird es keine Lösung auf Basis der ersten CentralStation (CS1) geben.''

|-
| Uhlenbrock '''Intellibox Basic'''
| DCC, MM
| 2 / 0
| LCD, 2x16 Zeichen
| 3A, N=18V, H0~21V (-) || 5-polig, [[LocoNet]]
| [[LocoNet]] / [[LocoNet]]
| POM+Prog / Prog-Gleis
| Doppel Traktion
| - / ja
| PC + LocoNet Interface
| Ohne I2C, [[S88-Rückmeldebus|S88]], Selectrix, Interface. MM bis 255 Adr. (Herbst 2008)

|-
| Uhlenbrock '''Intellibox II'''
| DCC, MM
| 2 / 0
| LCD Display
| {{r}}A, {{r}}V, ({{r}}) || 3+5-polig, [[LocoNet]]
| [[LocoNet]], IR / [[LocoNet]]
| POM+Prog / Prog-Gleis
| ja
| USB / ja
| PC
| Viele neue Funktionen geplant (Projekt 2009)

{{Zentralheader}}

|}
'''Anmerkungen:'''
# Die MultiZentralePRO und die MultiMausPRO verwenden IEEE 802.15.4 als Funkstandard
</div>

Digitalzentralen - Produktion ausgelaufen

2008-11-16T15:31:09Z

Michael Oppenauer: Formatierung unbekannter Spannungen

[[Kategorie:Digitalbetrieb]]

{{Zentralverweise}}

 

In diesem Artikel sind die Digitalzentralen aufgeführt, deren Produktion herstellerseitig ausgelaufen ist. Der Artikel ist aufgeteilt in:
* '''Alte Systeme'''               Die Produktion ist innerhalb der letzten 5 Jahre ausgelaufen.
* '''Historische Systeme'''   Die Produktion ist vor mehr als 5 Jahren ausgelaufen.

== Alte Systeme ==

Alte Zentralen, deren Produktion in den letzen ca. 5 Jahren ausgelaufen ist und
die einen gewisse Markbedeutung hatten und daher häufig/gelegentlich gebraucht
angeboten werden.

Es sei darauf hingewiesen, dass diese Systeme in der Regel dem Stand der
Digital-Entwicklung zum Zeitpunkt ihres Erscheinens entsprechen.
Bei den erst in letzter Zeit ausgelaufenen Systemen ist aber manches dabei,
das für einen Neueinstieg in die digitale Steuerung geeignet ist.
Mit zunehmender Zeit kann eine Reparatur-Möglichkeit ggfs. schwer zu finden sein.

<div style="font-size:0.8em">
{{Zentraltipps}}

{| {{Zentraltabelle}}
{{Zentralheader}}

|-
| Lenz  '''(1)''' '''Compact'''
| DCC
| 1 / 0
| 3–stellig
| 2,5A, {{r}}V (-) || 3-polig
| X–Bus (max. 5) / -
| Prog, bis 255 / Prog-Gleis
| Decoder
| - / ja
| nein
| nur 99 Adr., keine Rückmelder, kein Programmieren über Interface. (ca. 2000 bis 2008)

|-
| Lenz '''LZ100'''
| DCC, BiDi
| 0 / 0
| 1 LED
| - (-) || 3-polig
| X–Bus / RS–Bus
| ja / ja
| ja
| - / ja
| Platine / EPROM-Tausch
| Weiterhin Firmware Updates, '''BiDi''' (RailCom) ab V3.5 [mit LV102] (1992 bis 2004)

|-
| Märklin '''Control Unit (6021)'''
| MM2
| 1 / 0
| 2–stellig
| 2,5A, {{r}}V (-) || 5-polig
| I2C / [[S88-Rückmeldebus|S88]] über Extragerät
| ja / nein
| nein
| - / ja
| nein
| 14 Fahrst., 80 Adr. (1994 bis 2005)

|-
| MärklinSystems '''CentralStation''' 
| mfx, MM
| 2 / 0
| Touch Screen, 320x240
| 3A, {{r}}V ({{r}}) || ja, '''5-polig''', '''(3)'''
| {{r}}, '''Sniffer''' / {{r}}, '''[[S88-Rückmeldebus|S88]]'''
| ja / mfx Decoder
| Zentrale
| Ethernet
| PC
| MM: nur 80 Adr./14 Fahrst., '''Upgrade 06/2007 (2)''' (2005 bis 2008)

|-
| Roco '''Lokmaus 2/3''' ((+Verstärker))
| DCC
| 0 / 1
| 2–stellig
| ((3/3,2A, {{r}}V ({{r}}) )) || ja
| X–Bus / {{r}}
| bis 99 / nein
| nein
| - / ja
| nein
| Werte nur bis 99, Handregler am X–Bus, (2000 bis 2005)

|-
| Trix '''Central Control 2000'''
| SX + DCC
| 1 / 0
| ja {{r}}
| 2,5A, {{r}}V (-) || PX–Bus
| SX–Bus / SX–Bus
| ja / {{r}}
| {{r}}
| - / ja
| {{r}}
| (1995/6 bis 2005)

|-
| Uhlenbrock '''Daisy''' ((+Power2))
| DCC, MM
| 0 / 1
| 4–stellig
| ((2A, 15-20V ({{r}}) )) || 5-polig, [[LocoNet]]
| [[LocoNet]] / [[LocoNet]]
| ja / nein
|  
| - / ja
| PC + Intellibox
| Walk-Around nicht beim ersten Daisy, da Zentrale (2003 bis 2008)

{{Zentralheader}}

|}
'''Anmerkungen:'''
# Das Lenz Compact gab es auch unter dem Namen Tillig und Atlas (USA).
# Das Upgrade der Märklin CentralStation1 enthält Hardware für den Anschluss von S88-Rückmeldern, alte Märklin-Booster (6017 + Kompatible) und alte Märklin Zentralen (6021 via Sniffer).
# An die Märklin CentralStation1 können Booster von ESU angeschlossen werden. Dabei werden mfx-Meldungen erkannt und an die Zentrale geleitet.
</div>

 

== Historische Systeme ==

Alte Zentralen, deren Produktion vor mehr als 5 Jahren ausgelaufen ist. 
Diese Zentralen unterstützen oft nicht mehr die aktuelle Version ihrer Digitalprotokolle
oder die aktuellen Versionen der Busprotokolle für Eingaben/Rückmeldungen.
Aus diesem Grund sind sie für einen Neueinstieg in die digitale Steuerung
trotz ihrer oft günstigen Gebrauchtpreise weniger geeignet.
Eine Reparatur-Möglichkeit dürfte es in vielen Fällen nicht mehr gegeben.

<div style="font-size:0.8em">
{{Zentraltipps}}

{| {{Zentraltabelle}}
{{Zentralheader}}

|-
| Arnold '''Central Unit (86028)'''
| DCC
| 0 / 0
| 1 LED
| 2,5A, {{r}}V (-) || ja
| I2C / [[S88-Rückmeldebus|S88]] über Extragerät
| Extragerät / Extragerät
| nein
| - / ja
| nein
| 14 Fahrst., 99 Adr., Märklin Geräte nutzbar, (1988 bis 1996)

|-
| Arnold '''CentralControl (86200/202)'''
| DCC (86202 +MM)
| 1 / 0
| LCD, 2x16 Zeichen
| 3A, {{r}}V (-) || 3-polig
| I2C, X–Bus (V2.3) / -
| ja / -
| Zentrale, 10x4 Loks
| - / ja
| nein
| 14/28 Fahrst., 119 Adr., Märklin/X–Bus Geräte nutzbar, (1997 bis ~2000)

|-
| Fleischmann '''DigitalControl (6803/-C)'''
| FMZ
| 1 / 0
| 3–stellig
| 1,5A, {{r}}V (-) || -
| 1 Hand-Regler / -
| –C: Adresse, Vmin/max, Kennlinie, Verzögerung / -
| 1x2 Loks
| - / -
| -
| bis 5 Loks, keine Weichen, (ab 1995(?), –C 2007 noch Restbestände)
|-
| Fleischmann '''FMZ Zentrale'''
| FMZ
| 0 / 0
| 3+1 Stelle, LEDs
| 3A, {{r}}V (-) || ja
| 8 Hand-Regler, RS232 / RS232
| Extragerät / Extragerät
| -
| RS232 / -
| -
| bis 32 Loks, (ab 1987, 2007 noch Restbestände)

|-
| Märklin '''Central Unit (6020)'''
| MM1
| 0 / 0
| -
| 2,5A, {{r}}V (-) || 5-polig
| I2C / [[S88-Rückmeldebus|S88]] über Extragerät
| ja / nein
| nein
| - / ja
| nein
| 14 Fahrst., 80 Adr. (vor 1995)

|-
| Märklin '''Delta Control (6604)'''
| MM1
| 1 / 0
| -
| {{r}}A, {{r}}V (-) || -
| 1 Hand-Regler / -
| - / -
| nein
| - / -
| nein
| 14 Fahrst., 4+1 Adr., keine Funktion, als Booster verwendbar. (1992(?) bis 2002)

{{Zentralheader}}

|}

Digitalzentralen - Selbstbausysteme

2008-11-16T15:28:48Z

Michael Oppenauer: Formatierung unbekannter Spannungen

[[Kategorie:Digitalbetrieb]]

{{Zentralverweise}}

 

In diesem Artikel werden Selbstbau-Projekte beschrieben:
* Verwendung eines PCs als Zentrale
* Elektronik-Projekte zum selber löten
Gegebenenfalls wird dieser Artikel noch um den Bereich Selbstbau-Booster erweitert.

== Selbstbauprojekte ==

Hier geht es um den Selbstbau von Hardware und die Programmierung der darin enthaltenen Prozessoren.

<div style="font-size:0.8em">
{{Zentraltipps}}

{| {{Zentraltabelle}}
{{Zentralheader-2}}

|-
| '''[http://www.tinet.org/~fmco/dccgen_en.html DDC_Gen]'''
| DCC / -
| 1 / 1
| LCD
| - || Gleissignal
| Infrarot / [[S88-Rückmeldebus|S88]]
| ja / ja, mit ACK-Detector
| {{r}}
| RS232 / -
| -
| max. 16 Loks aktiv. Nur Adressen bis 99.

|-
| '''[http://merg.org.uk/resources/dcc.htm MERG BC1A]'''
| DCC / -
| - / 8
| LED
| 5A, {{r}}V ({{r}}) || Gleissignal
| [[LocoNet]]{{r}} / -
| {{r}} / {{r}}
| {{r}}
| RS232 / -
| -
| Bausätze für Mitglieder verfügbar.

|-
| '''[http://home.no.net/paolsen/mj/minibox/minibox_de.html MiniBOX]'''
| DCC / -
| - / ja
| 4-stellig
| 0,6A, {{r}}V ({{r}}) || Gleissignal
| [[LocoNet]] / [[LocoNet]]
| ja / ja, mit ACK-Detector
| -
| - / ja
| -
| max. 8 Loks aktiv. Nur 14 bzw. 28 Fahrstufen.

|-
| '''[http://www.minidcc.com/ MiniDCC]'''
| DCC / -
| 4 / -
| LCD
| - || Gleissignal
| - / -
| - / -
| -
| - / -
| -
| Verkauf von programmierten Controller und Platinen

|-
| '''[http://www.mobasbs.de/Eisenbahn/MoBaSbS/MoBaSbS.htm MoBaSbs]'''
| DCC, MM / -
| - / ja
| LCD
| - || Gleissignal
| RS485 / RS485
| - / -
| {{r}}
| - / ja
| prog. Schnitt-stelle
|

|-
| '''[http://www.tinet.org/~fmco/nanox_en.html#nanox_orig NanoX]'''
| DCC / -
| - / -
| 1 LED
| 1,2A, {{r}}V ({{r}}) || Gleissignal
| X-Bus / -
| ja / ja
| {{r}}
| - / ja
| PIC '''(1)'''
| max. 16 Loks aktiv. Mit ihr kann die MultiMaus Dekoder auslesen.

|-
| '''[http://www.tinet.org/~fmco/nanox_en.html NanoX-S88]'''
| DCC / CutOut
| - / -
| 1 LED
| 2,9A, 13-22V ({{r}}) || Gleissignal
| X-Bus / [[S88-Rückmeldebus|S88]]
| ja / ja
| {{r}}
| - '''(2)''' / ja
| PIC '''(1)'''
| max. 16 Loks aktiv. Mit ihr kann die MultiMaus Dekoder auslesen.

|-
| '''[http://www.opendcc.de/elektronik/opendcc/opendcc.html OpenDCC]'''
| DCC / vorber.
| - / -
| 4 LEDs
| 1,2A , {{r}}V ({{r}}) || Gleissignal
| X-Bus / 3x[[S88-Rückmeldebus|S88]]
| ja / ja
| nein
| USB, RS232 / -
| prog. Schnitt-stelle
| max. 64 Loks aktiv. Intelligente "Interface Zentrale". Echte Weichen Rückmeldung. Open Source. Benötigt PC mit Steuer Software.

|-
| '''[http://www.microsyl.com/dcccontrol/dcccontrol.html Train Modelling Digital Control]'''
| DCC / -
| 4 / -
| -
| - || Gleissignal
| - / -
| ja / {{r}}
| {{r}}
| - / -
| ja
| max. 4 Loks und 30 Weichen aktiv

{{Zentralheader-2}}

|}

'''Anmerkungen:'''
# PIC muss in extra Schaltung programmiert werden.
# Es ist auch eine [http://www.tinet.org/~fmco/colab_en.html Platinenvariante] mit integriertem Interface (GenLi, RS232) verfügbar.
</div>

 

== Software-Zentralen ==

Software-Zentrale erzeugen mit einem PC das Gleissignal für ein oder mehrere
Digital-Protokolle, typischerweise DCC und/oder Märklin-Motorola (MM).
Dieses Gleissignal wird über eine Schnittstelle einem Booster zur Verstärkung
zugeleitet, der seinerseits die Modellbahn-Anlage mit Strom und den aufgeprägten
Steuerinformationen versorgt.

<div style="font-size:0.8em">
{{Zentraltipps}}

{| {{Zentraltabelle}}
{{Zentralheader-2}}

|-
| '''[http://www.vogt-it.com/OpenSource/DDL/ DDL]'''
| DCC, MM / -
| - / -
| -
| - || ja
| [[SRCP-Grundlagen|SRCP]] / [[S88-Rückmeldebus|S88]], [[SRCP-Grundlagen|SRCP]]
| ja / ja, mit ACK-Detector
| -
| RS232, Parallel / -
| PC
| Vorläufer von srcpd.

|-
| '''[http://home.snafu.de/mgrafe/index.htm DDW]'''
| DCC, MM / -
| - / -
| -
| - || ja
| [[SRCP-Grundlagen|SRCP]] / [[S88-Rückmeldebus|S88]], [[SRCP-Grundlagen|SRCP]]
| ja / ja, mit ACK-Detector
| -
| RS232, Parallel / -
| PC
|

|-
| '''[http://www.mrdirect.nl/ MR direkt]'''
| DCC, MM / -
| - / ja
| -
| - || Gleissignal
| ja / [[S88-Rückmeldebus|S88]]
| - / -
| {{r}}
| RS232, Parallel / -
| PC
|

|-
| '''[http://www.rocrail.net/ Rocrail]'''
| DCC, MM / -
| - / -
| -
| 2,5A, {{r}}V ({{r}}) '''(1)''' || ja
| - / 4x[[S88-Rückmeldebus|S88]]
| ja / ja
| -
| RS232, Parallel / -
| PC
| OpenSource Steuer Software mit DDL/DDW Support. Auch für klassische Digital Zentralen verwendbar.

|-
| '''[http://srcpd.sourceforge.net/ srcpd]'''
| DCC, MM '''(2)''' / -
| - / -
| -
| - || ja '''(2)'''
| [[SRCP-Grundlagen|SRCP]] / [[S88-Rückmeldebus|S88]], [[SRCP-Grundlagen|SRCP]] '''(2)'''
| ja / ja, mit ACK-Detector
| -
| RS232, Parallel / ja '''(2)'''
| PC
| Weiterentwicklung von DDL. Auch für klassische Digital Zentralen verwendbar.

{{Zentralheader-2}}

|}
'''Anmerkungen:'''
# Anschluss Platine mit Booster im gleichen Projekt verfügbar.
# Über zusätzliche Interfaces, lassen sich die Protokolle und Bussystem der daran angeschlossen Zentralen mitnutzen. Eine Übersicht findet sich unter: [http://bonus.dyndns.org/mediawiki/index.php/SRCPD-Devices]
</div>

Digitalzentralen - Selbstbausysteme

2008-11-16T15:25:54Z

Michael Oppenauer: /* Software-Zentralen */ Formatierung unbekannter Spannungen

[[Kategorie:Digitalbetrieb]]

{{Zentralverweise}}

 

In diesem Artikel werden Selbstbau-Projekte beschrieben:
* Verwendung eines PCs als Zentrale
* Elektronik-Projekte zum selber löten
Gegebenenfalls wird dieser Artikel noch um den Bereich Selbstbau-Booster erweitert.

== Selbstbauprojekte ==

Hier geht es um den Selbstbau von Hardware und die Programmierung der darin enthaltenen Prozessoren.

<div style="font-size:0.8em">
{{Zentraltipps}}

{| {{Zentraltabelle}}
{{Zentralheader-2}}

|-
| '''[http://www.tinet.org/~fmco/dccgen_en.html DDC_Gen]'''
| DCC / -
| 1 / 1
| LCD
| - || Gleissignal
| Infrarot / [[S88-Rückmeldebus|S88]]
| ja / ja, mit ACK-Detector
| {{r}}
| RS232 / -
| -
| max. 16 Loks aktiv. Nur Adressen bis 99.

|-
| '''[http://merg.org.uk/resources/dcc.htm MERG BC1A]'''
| DCC / -
| - / 8
| LED
| 5A, {{r}}V || Gleissignal
| [[LocoNet]]{{r}} / -
| {{r}} / {{r}}
| {{r}}
| RS232 / -
| -
| Bausätze für Mitglieder verfügbar.

|-
| '''[http://home.no.net/paolsen/mj/minibox/minibox_de.html MiniBOX]'''
| DCC / -
| - / ja
| 4-stellig
| 0,6A, {{r}}V || Gleissignal
| [[LocoNet]] / [[LocoNet]]
| ja / ja, mit ACK-Detector
| -
| - / ja
| -
| max. 8 Loks aktiv. Nur 14 bzw. 28 Fahrstufen.

|-
| '''[http://www.minidcc.com/ MiniDCC]'''
| DCC / -
| 4 / -
| LCD
| - || Gleissignal
| - / -
| - / -
| -
| - / -
| -
| Verkauf von programmierten Controller und Platinen

|-
| '''[http://www.mobasbs.de/Eisenbahn/MoBaSbS/MoBaSbS.htm MoBaSbs]'''
| DCC, MM / -
| - / ja
| LCD
| - || Gleissignal
| RS485 / RS485
| - / -
| {{r}}
| - / ja
| prog. Schnitt-stelle
|

|-
| '''[http://www.tinet.org/~fmco/nanox_en.html#nanox_orig NanoX]'''
| DCC / -
| - / -
| 1 LED
| 1,2A, {{r}}V || Gleissignal
| X-Bus / -
| ja / ja
| {{r}}
| - / ja
| PIC '''(1)'''
| max. 16 Loks aktiv. Mit ihr kann die MultiMaus Dekoder auslesen.

|-
| '''[http://www.tinet.org/~fmco/nanox_en.html NanoX-S88]'''
| DCC / CutOut
| - / -
| 1 LED
| 2,9A, 13-22V ({{r}}) || Gleissignal
| X-Bus / [[S88-Rückmeldebus|S88]]
| ja / ja
| {{r}}
| - '''(2)''' / ja
| PIC '''(1)'''
| max. 16 Loks aktiv. Mit ihr kann die MultiMaus Dekoder auslesen.

|-
| '''[http://www.opendcc.de/elektronik/opendcc/opendcc.html OpenDCC]'''
| DCC / vorber.
| - / -
| 4 LEDs
| 1,2A , {{r}}V || Gleissignal
| X-Bus / 3x[[S88-Rückmeldebus|S88]]
| ja / ja
| nein
| USB, RS232 / -
| prog. Schnitt-stelle
| max. 64 Loks aktiv. Intelligente "Interface Zentrale". Echte Weichen Rückmeldung. Open Source. Benötigt PC mit Steuer Software.

|-
| '''[http://www.microsyl.com/dcccontrol/dcccontrol.html Train Modelling Digital Control]'''
| DCC / -
| 4 / -
| -
| - || Gleissignal
| - / -
| ja / {{r}}
| {{r}}
| - / -
| ja
| max. 4 Loks und 30 Weichen aktiv

{{Zentralheader-2}}

|}

'''Anmerkungen:'''
# PIC muss in extra Schaltung programmiert werden.
# Es ist auch eine [http://www.tinet.org/~fmco/colab_en.html Platinenvariante] mit integriertem Interface (GenLi, RS232) verfügbar.
</div>

 

== Software-Zentralen ==

Software-Zentrale erzeugen mit einem PC das Gleissignal für ein oder mehrere
Digital-Protokolle, typischerweise DCC und/oder Märklin-Motorola (MM).
Dieses Gleissignal wird über eine Schnittstelle einem Booster zur Verstärkung
zugeleitet, der seinerseits die Modellbahn-Anlage mit Strom und den aufgeprägten
Steuerinformationen versorgt.

<div style="font-size:0.8em">
{{Zentraltipps}}

{| {{Zentraltabelle}}
{{Zentralheader-2}}

|-
| '''[http://www.vogt-it.com/OpenSource/DDL/ DDL]'''
| DCC, MM / -
| - / -
| -
| - || ja
| [[SRCP-Grundlagen|SRCP]] / [[S88-Rückmeldebus|S88]], [[SRCP-Grundlagen|SRCP]]
| ja / ja, mit ACK-Detector
| -
| RS232, Parallel / -
| PC
| Vorläufer von srcpd.

|-
| '''[http://home.snafu.de/mgrafe/index.htm DDW]'''
| DCC, MM / -
| - / -
| -
| - || ja
| [[SRCP-Grundlagen|SRCP]] / [[S88-Rückmeldebus|S88]], [[SRCP-Grundlagen|SRCP]]
| ja / ja, mit ACK-Detector
| -
| RS232, Parallel / -
| PC
|

|-
| '''[http://www.mrdirect.nl/ MR direkt]'''
| DCC, MM / -
| - / ja
| -
| - || Gleissignal
| ja / [[S88-Rückmeldebus|S88]]
| - / -
| {{r}}
| RS232, Parallel / -
| PC
|

|-
| '''[http://www.rocrail.net/ Rocrail]'''
| DCC, MM / -
| - / -
| -
| 2,5A, {{r}}V '''(1)''' || ja
| - / 4x[[S88-Rückmeldebus|S88]]
| ja / ja
| -
| RS232, Parallel / -
| PC
| OpenSource Steuer Software mit DDL/DDW Support. Auch für klassische Digital Zentralen verwendbar.

|-
| '''[http://srcpd.sourceforge.net/ srcpd]'''
| DCC, MM '''(2)''' / -
| - / -
| -
| - || ja '''(2)'''
| [[SRCP-Grundlagen|SRCP]] / [[S88-Rückmeldebus|S88]], [[SRCP-Grundlagen|SRCP]] '''(2)'''
| ja / ja, mit ACK-Detector
| -
| RS232, Parallel / ja '''(2)'''
| PC
| Weiterentwicklung von DDL. Auch für klassische Digital Zentralen verwendbar.

{{Zentralheader-2}}

|}
'''Anmerkungen:'''
# Anschluss Platine mit Booster im gleichen Projekt verfügbar.
# Über zusätzliche Interfaces, lassen sich die Protokolle und Bussystem der daran angeschlossen Zentralen mitnutzen. Eine Übersicht findet sich unter: [http://bonus.dyndns.org/mediawiki/index.php/SRCPD-Devices]
</div>

Digitalzentralen - Selbstbausysteme

2008-11-16T15:25:08Z

Michael Oppenauer: /* Selbstbauprojekte */ Formatierung unbekannter Spannungen

[[Kategorie:Digitalbetrieb]]

{{Zentralverweise}}

 

In diesem Artikel werden Selbstbau-Projekte beschrieben:
* Verwendung eines PCs als Zentrale
* Elektronik-Projekte zum selber löten
Gegebenenfalls wird dieser Artikel noch um den Bereich Selbstbau-Booster erweitert.

== Selbstbauprojekte ==

Hier geht es um den Selbstbau von Hardware und die Programmierung der darin enthaltenen Prozessoren.

<div style="font-size:0.8em">
{{Zentraltipps}}

{| {{Zentraltabelle}}
{{Zentralheader-2}}

|-
| '''[http://www.tinet.org/~fmco/dccgen_en.html DDC_Gen]'''
| DCC / -
| 1 / 1
| LCD
| - || Gleissignal
| Infrarot / [[S88-Rückmeldebus|S88]]
| ja / ja, mit ACK-Detector
| {{r}}
| RS232 / -
| -
| max. 16 Loks aktiv. Nur Adressen bis 99.

|-
| '''[http://merg.org.uk/resources/dcc.htm MERG BC1A]'''
| DCC / -
| - / 8
| LED
| 5A, {{r}}V || Gleissignal
| [[LocoNet]]{{r}} / -
| {{r}} / {{r}}
| {{r}}
| RS232 / -
| -
| Bausätze für Mitglieder verfügbar.

|-
| '''[http://home.no.net/paolsen/mj/minibox/minibox_de.html MiniBOX]'''
| DCC / -
| - / ja
| 4-stellig
| 0,6A, {{r}}V || Gleissignal
| [[LocoNet]] / [[LocoNet]]
| ja / ja, mit ACK-Detector
| -
| - / ja
| -
| max. 8 Loks aktiv. Nur 14 bzw. 28 Fahrstufen.

|-
| '''[http://www.minidcc.com/ MiniDCC]'''
| DCC / -
| 4 / -
| LCD
| - || Gleissignal
| - / -
| - / -
| -
| - / -
| -
| Verkauf von programmierten Controller und Platinen

|-
| '''[http://www.mobasbs.de/Eisenbahn/MoBaSbS/MoBaSbS.htm MoBaSbs]'''
| DCC, MM / -
| - / ja
| LCD
| - || Gleissignal
| RS485 / RS485
| - / -
| {{r}}
| - / ja
| prog. Schnitt-stelle
|

|-
| '''[http://www.tinet.org/~fmco/nanox_en.html#nanox_orig NanoX]'''
| DCC / -
| - / -
| 1 LED
| 1,2A, {{r}}V || Gleissignal
| X-Bus / -
| ja / ja
| {{r}}
| - / ja
| PIC '''(1)'''
| max. 16 Loks aktiv. Mit ihr kann die MultiMaus Dekoder auslesen.

|-
| '''[http://www.tinet.org/~fmco/nanox_en.html NanoX-S88]'''
| DCC / CutOut
| - / -
| 1 LED
| 2,9A, 13-22V ({{r}}) || Gleissignal
| X-Bus / [[S88-Rückmeldebus|S88]]
| ja / ja
| {{r}}
| - '''(2)''' / ja
| PIC '''(1)'''
| max. 16 Loks aktiv. Mit ihr kann die MultiMaus Dekoder auslesen.

|-
| '''[http://www.opendcc.de/elektronik/opendcc/opendcc.html OpenDCC]'''
| DCC / vorber.
| - / -
| 4 LEDs
| 1,2A , {{r}}V || Gleissignal
| X-Bus / 3x[[S88-Rückmeldebus|S88]]
| ja / ja
| nein
| USB, RS232 / -
| prog. Schnitt-stelle
| max. 64 Loks aktiv. Intelligente "Interface Zentrale". Echte Weichen Rückmeldung. Open Source. Benötigt PC mit Steuer Software.

|-
| '''[http://www.microsyl.com/dcccontrol/dcccontrol.html Train Modelling Digital Control]'''
| DCC / -
| 4 / -
| -
| - || Gleissignal
| - / -
| ja / {{r}}
| {{r}}
| - / -
| ja
| max. 4 Loks und 30 Weichen aktiv

{{Zentralheader-2}}

|}

'''Anmerkungen:'''
# PIC muss in extra Schaltung programmiert werden.
# Es ist auch eine [http://www.tinet.org/~fmco/colab_en.html Platinenvariante] mit integriertem Interface (GenLi, RS232) verfügbar.
</div>

 

== Software-Zentralen ==

Software-Zentrale erzeugen mit einem PC das Gleissignal für ein oder mehrere
Digital-Protokolle, typischerweise DCC und/oder Märklin-Motorola (MM).
Dieses Gleissignal wird über eine Schnittstelle einem Booster zur Verstärkung
zugeleitet, der seinerseits die Modellbahn-Anlage mit Strom und den aufgeprägten
Steuerinformationen versorgt.

<div style="font-size:0.8em">
{{Zentraltipps}}

{| {{Zentraltabelle}}
{{Zentralheader-2}}

|-
| '''[http://www.vogt-it.com/OpenSource/DDL/ DDL]'''
| DCC, MM / -
| - / -
| -
| - || ja
| [[SRCP-Grundlagen|SRCP]] / [[S88-Rückmeldebus|S88]], [[SRCP-Grundlagen|SRCP]]
| ja / ja, mit ACK-Detector
| -
| RS232, Parallel / -
| PC
| Vorläufer von srcpd.

|-
| '''[http://home.snafu.de/mgrafe/index.htm DDW]'''
| DCC, MM / -
| - / -
| -
| - || ja
| [[SRCP-Grundlagen|SRCP]] / [[S88-Rückmeldebus|S88]], [[SRCP-Grundlagen|SRCP]]
| ja / ja, mit ACK-Detector
| -
| RS232, Parallel / -
| PC
|

|-
| '''[http://www.mrdirect.nl/ MR direkt]'''
| DCC, MM / -
| - / ja
| -
| - || Gleissignal
| ja / [[S88-Rückmeldebus|S88]]
| - / -
| {{r}}
| RS232, Parallel / -
| PC
|

|-
| '''[http://www.rocrail.net/ Rocrail]'''
| DCC, MM / -
| - / -
| -
| 2,5A, ?V ({{r}}) '''(1)''' || ja
| - / 4x[[S88-Rückmeldebus|S88]]
| ja / ja
| -
| RS232, Parallel / -
| PC
| OpenSource Steuer Software mit DDL/DDW Support. Auch für klassische Digital Zentralen verwendbar.

|-
| '''[http://srcpd.sourceforge.net/ srcpd]'''
| DCC, MM '''(2)''' / -
| - / -
| -
| - || ja '''(2)'''
| [[SRCP-Grundlagen|SRCP]] / [[S88-Rückmeldebus|S88]], [[SRCP-Grundlagen|SRCP]] '''(2)'''
| ja / ja, mit ACK-Detector
| -
| RS232, Parallel / ja '''(2)'''
| PC
| Weiterentwicklung von DDL. Auch für klassische Digital Zentralen verwendbar.

{{Zentralheader-2}}

|}
'''Anmerkungen:'''
# Anschluss Platine mit Booster im gleichen Projekt verfügbar.
# Über zusätzliche Interfaces, lassen sich die Protokolle und Bussystem der daran angeschlossen Zentralen mitnutzen. Eine Übersicht findet sich unter: [http://bonus.dyndns.org/mediawiki/index.php/SRCPD-Devices]
</div>

Vorlage:R

2008-11-16T15:17:00Z

Michael Oppenauer: Leerzeichen durch   ersetzt

?

Digitalzentralen - Selbstbausysteme

2008-11-16T15:15:37Z

Michael Oppenauer: /* Software-Zentralen */ Umbruch an Fußnote angepasst

[[Kategorie:Digitalbetrieb]]

{{Zentralverweise}}

 

In diesem Artikel werden Selbstbau-Projekte beschrieben:
* Verwendung eines PCs als Zentrale
* Elektronik-Projekte zum selber löten
Gegebenenfalls wird dieser Artikel noch um den Bereich Selbstbau-Booster erweitert.

== Selbstbauprojekte ==

Hier geht es um den Selbstbau von Hardware und die Programmierung der darin enthaltenen Prozessoren.

<div style="font-size:0.8em">
{{Zentraltipps}}

{| {{Zentraltabelle}}
{{Zentralheader-2}}

|-
| '''[http://www.tinet.org/~fmco/dccgen_en.html DDC_Gen]'''
| DCC / -
| 1 / 1
| LCD
| - || Gleissignal
| Infrarot / [[S88-Rückmeldebus|S88]]
| ja / ja, mit ACK-Detector
| {{r}}
| RS232 / -
| -
| max. 16 Loks aktiv. Nur Adressen bis 99.

|-
| '''[http://merg.org.uk/resources/dcc.htm MERG BC1A]'''
| DCC / -
| - / 8
| LED
| 5A, ?V ({{r}}) || Gleissignal
| [[LocoNet]]{{r}} / -
| {{r}} / {{r}}
| {{r}}
| RS232 / -
| -
| Bausätze für Mitglieder verfügbar.

|-
| '''[http://home.no.net/paolsen/mj/minibox/minibox_de.html MiniBOX]'''
| DCC / -
| - / ja
| 4-stellig
| 0,6A, ?V ({{r}}) || Gleissignal
| [[LocoNet]] / [[LocoNet]]
| ja / ja, mit ACK-Detector
| -
| - / ja
| -
| max. 8 Loks aktiv. Nur 14 bzw. 28 Fahrstufen.

|-
| '''[http://www.minidcc.com/ MiniDCC]'''
| DCC / -
| 4 / -
| LCD
| - || Gleissignal
| - / -
| - / -
| -
| - / -
| -
| Verkauf von programmierten Controller und Platinen

|-
| '''[http://www.mobasbs.de/Eisenbahn/MoBaSbS/MoBaSbS.htm MoBaSbs]'''
| DCC, MM / -
| - / ja
| LCD
| - || Gleissignal
| RS485 / RS485
| - / -
| {{r}}
| - / ja
| prog. Schnitt-stelle
|

|-
| '''[http://www.tinet.org/~fmco/nanox_en.html#nanox_orig NanoX]'''
| DCC / -
| - / -
| 1 LED
| 1,2A, ?V ({{r}}) || Gleissignal
| X-Bus / -
| ja / ja
| {{r}}
| - / ja
| PIC '''(1)'''
| max. 16 Loks aktiv. Mit ihr kann die MultiMaus Dekoder auslesen.

|-
| '''[http://www.tinet.org/~fmco/nanox_en.html NanoX-S88]'''
| DCC / CutOut
| - / -
| 1 LED
| 2,9A, 13-22V ({{r}}) || Gleissignal
| X-Bus / [[S88-Rückmeldebus|S88]]
| ja / ja
| {{r}}
| - '''(2)''' / ja
| PIC '''(1)'''
| max. 16 Loks aktiv. Mit ihr kann die MultiMaus Dekoder auslesen.

|-
| '''[http://www.opendcc.de/elektronik/opendcc/opendcc.html OpenDCC]'''
| DCC / vorber.
| - / -
| 4 LEDs
| 1,2A , ?V ({{r}}) || Gleissignal
| X-Bus / 3x[[S88-Rückmeldebus|S88]]
| ja / ja
| nein
| USB, RS232 / -
| prog. Schnitt-stelle
| max. 64 Loks aktiv. Intelligente "Interface Zentrale". Echte Weichen Rückmeldung. Open Source. Benötigt PC mit Steuer Software.

|-
| '''[http://www.microsyl.com/dcccontrol/dcccontrol.html Train Modelling Digital Control]'''
| DCC / -
| 4 / -
| -
| - || Gleissignal
| - / -
| ja / {{r}}
| {{r}}
| - / -
| ja
| max. 4 Loks und 30 Weichen aktiv

{{Zentralheader-2}}

|}

'''Anmerkungen:'''
# PIC muss in extra Schaltung programmiert werden.
# Es ist auch eine [http://www.tinet.org/~fmco/colab_en.html Platinenvariante] mit integriertem Interface (GenLi, RS232) verfügbar.
</div>

 

== Software-Zentralen ==

Software-Zentrale erzeugen mit einem PC das Gleissignal für ein oder mehrere
Digital-Protokolle, typischerweise DCC und/oder Märklin-Motorola (MM).
Dieses Gleissignal wird über eine Schnittstelle einem Booster zur Verstärkung
zugeleitet, der seinerseits die Modellbahn-Anlage mit Strom und den aufgeprägten
Steuerinformationen versorgt.

<div style="font-size:0.8em">
{{Zentraltipps}}

{| {{Zentraltabelle}}
{{Zentralheader-2}}

|-
| '''[http://www.vogt-it.com/OpenSource/DDL/ DDL]'''
| DCC, MM / -
| - / -
| -
| - || ja
| [[SRCP-Grundlagen|SRCP]] / [[S88-Rückmeldebus|S88]], [[SRCP-Grundlagen|SRCP]]
| ja / ja, mit ACK-Detector
| -
| RS232, Parallel / -
| PC
| Vorläufer von srcpd.

|-
| '''[http://home.snafu.de/mgrafe/index.htm DDW]'''
| DCC, MM / -
| - / -
| -
| - || ja
| [[SRCP-Grundlagen|SRCP]] / [[S88-Rückmeldebus|S88]], [[SRCP-Grundlagen|SRCP]]
| ja / ja, mit ACK-Detector
| -
| RS232, Parallel / -
| PC
|

|-
| '''[http://www.mrdirect.nl/ MR direkt]'''
| DCC, MM / -
| - / ja
| -
| - || Gleissignal
| ja / [[S88-Rückmeldebus|S88]]
| - / -
| {{r}}
| RS232, Parallel / -
| PC
|

|-
| '''[http://www.rocrail.net/ Rocrail]'''
| DCC, MM / -
| - / -
| -
| 2,5A, ?V ({{r}}) '''(1)''' || ja
| - / 4x[[S88-Rückmeldebus|S88]]
| ja / ja
| -
| RS232, Parallel / -
| PC
| OpenSource Steuer Software mit DDL/DDW Support. Auch für klassische Digital Zentralen verwendbar.

|-
| '''[http://srcpd.sourceforge.net/ srcpd]'''
| DCC, MM '''(2)''' / -
| - / -
| -
| - || ja '''(2)'''
| [[SRCP-Grundlagen|SRCP]] / [[S88-Rückmeldebus|S88]], [[SRCP-Grundlagen|SRCP]] '''(2)'''
| ja / ja, mit ACK-Detector
| -
| RS232, Parallel / ja '''(2)'''
| PC
| Weiterentwicklung von DDL. Auch für klassische Digital Zentralen verwendbar.

{{Zentralheader-2}}

|}
'''Anmerkungen:'''
# Anschluss Platine mit Booster im gleichen Projekt verfügbar.
# Über zusätzliche Interfaces, lassen sich die Protokolle und Bussystem der daran angeschlossen Zentralen mitnutzen. Eine Übersicht findet sich unter: [http://bonus.dyndns.org/mediawiki/index.php/SRCPD-Devices]
</div>

Digitalzentralen - Selbstbausysteme

2008-11-16T13:51:02Z

Michael Oppenauer: /* Software-Zentralen */ Redundante Informationen in Bemerkungen angpasst.

[[Kategorie:Digitalbetrieb]]

{{Zentralverweise}}

 

In diesem Artikel werden Selbstbau-Projekte beschrieben:
* Verwendung eines PCs als Zentrale
* Elektronik-Projekte zum selber löten
Gegebenenfalls wird dieser Artikel noch um den Bereich Selbstbau-Booster erweitert.

== Selbstbauprojekte ==

Hier geht es um den Selbstbau von Hardware und die Programmierung der darin enthaltenen Prozessoren.

<div style="font-size:0.8em">
{{Zentraltipps}}

{| {{Zentraltabelle}}
{{Zentralheader-2}}

|-
| '''[http://www.tinet.org/~fmco/dccgen_en.html DDC_Gen]'''
| DCC / -
| 1 / 1
| LCD
| - || Gleissignal
| Infrarot / [[S88-Rückmeldebus|S88]]
| ja / ja, mit ACK-Detector
| {{r}}
| RS232 / -
| -
| max. 16 Loks aktiv. Nur Adressen bis 99.

|-
| '''[http://merg.org.uk/resources/dcc.htm MERG BC1A]'''
| DCC / -
| - / 8
| LED
| 5A, ?V ({{r}}) || Gleissignal
| [[LocoNet]]{{r}} / -
| {{r}} / {{r}}
| {{r}}
| RS232 / -
| -
| Bausätze für Mitglieder verfügbar.

|-
| '''[http://home.no.net/paolsen/mj/minibox/minibox_de.html MiniBOX]'''
| DCC / -
| - / ja
| 4-stellig
| 0,6A, ?V ({{r}}) || Gleissignal
| [[LocoNet]] / [[LocoNet]]
| ja / ja, mit ACK-Detector
| -
| - / ja
| -
| max. 8 Loks aktiv. Nur 14 bzw. 28 Fahrstufen.

|-
| '''[http://www.minidcc.com/ MiniDCC]'''
| DCC / -
| 4 / -
| LCD
| - || Gleissignal
| - / -
| - / -
| -
| - / -
| -
| Verkauf von programmierten Controller und Platinen

|-
| '''[http://www.mobasbs.de/Eisenbahn/MoBaSbS/MoBaSbS.htm MoBaSbs]'''
| DCC, MM / -
| - / ja
| LCD
| - || Gleissignal
| RS485 / RS485
| - / -
| {{r}}
| - / ja
| prog. Schnitt-stelle
|

|-
| '''[http://www.tinet.org/~fmco/nanox_en.html#nanox_orig NanoX]'''
| DCC / -
| - / -
| 1 LED
| 1,2A, ?V ({{r}}) || Gleissignal
| X-Bus / -
| ja / ja
| {{r}}
| - / ja
| PIC '''(1)'''
| max. 16 Loks aktiv. Mit ihr kann die MultiMaus Dekoder auslesen.

|-
| '''[http://www.tinet.org/~fmco/nanox_en.html NanoX-S88]'''
| DCC / CutOut
| - / -
| 1 LED
| 2,9A, 13-22V ({{r}}) || Gleissignal
| X-Bus / [[S88-Rückmeldebus|S88]]
| ja / ja
| {{r}}
| - '''(2)''' / ja
| PIC '''(1)'''
| max. 16 Loks aktiv. Mit ihr kann die MultiMaus Dekoder auslesen.

|-
| '''[http://www.opendcc.de/elektronik/opendcc/opendcc.html OpenDCC]'''
| DCC / vorber.
| - / -
| 4 LEDs
| 1,2A , ?V ({{r}}) || Gleissignal
| X-Bus / 3x[[S88-Rückmeldebus|S88]]
| ja / ja
| nein
| USB, RS232 / -
| prog. Schnitt-stelle
| max. 64 Loks aktiv. Intelligente "Interface Zentrale". Echte Weichen Rückmeldung. Open Source. Benötigt PC mit Steuer Software.

|-
| '''[http://www.microsyl.com/dcccontrol/dcccontrol.html Train Modelling Digital Control]'''
| DCC / -
| 4 / -
| -
| - || Gleissignal
| - / -
| ja / {{r}}
| {{r}}
| - / -
| ja
| max. 4 Loks und 30 Weichen aktiv

{{Zentralheader-2}}

|}

'''Anmerkungen:'''
# PIC muss in extra Schaltung programmiert werden.
# Es ist auch eine [http://www.tinet.org/~fmco/colab_en.html Platinenvariante] mit integriertem Interface (GenLi, RS232) verfügbar.
</div>

 

== Software-Zentralen ==

Software-Zentrale erzeugen mit einem PC das Gleissignal für ein oder mehrere
Digital-Protokolle, typischerweise DCC und/oder Märklin-Motorola (MM).
Dieses Gleissignal wird über eine Schnittstelle einem Booster zur Verstärkung
zugeleitet, der seinerseits die Modellbahn-Anlage mit Strom und den aufgeprägten
Steuerinformationen versorgt.

<div style="font-size:0.8em">
{{Zentraltipps}}

{| {{Zentraltabelle}}
{{Zentralheader-2}}

|-
| '''[http://www.vogt-it.com/OpenSource/DDL/ DDL]'''
| DCC, MM / -
| - / -
| -
| - || ja
| [[SRCP-Grundlagen|SRCP]] / [[S88-Rückmeldebus|S88]], [[SRCP-Grundlagen|SRCP]]
| ja / ja, mit ACK-Detector
| -
| RS232, Parallel / -
| PC
| Vorläufer von srcpd.

|-
| '''[http://home.snafu.de/mgrafe/index.htm DDW]'''
| DCC, MM / -
| - / -
| -
| - || ja
| [[SRCP-Grundlagen|SRCP]] / [[S88-Rückmeldebus|S88]], [[SRCP-Grundlagen|SRCP]]
| ja / ja, mit ACK-Detector
| -
| RS232, Parallel / -
| PC
|

|-
| '''[http://www.mrdirect.nl/ MR direkt]'''
| DCC, MM / -
| - / ja
| -
| - || Gleissignal
| ja / [[S88-Rückmeldebus|S88]]
| - / -
| {{r}}
| RS232, Parallel / -
| PC
|

|-
| '''[http://www.rocrail.net/ Rocrail]'''
| DCC, MM / -
| - / -
| -
| 2,5A, ?V ({{r}})'''(1)''' || ja
| - / 4x[[S88-Rückmeldebus|S88]]
| ja / ja
| -
| RS232, Parallel / -
| PC
| OpenSource Steuer Software mit DDL/DDW Support. Auch für klassische Digital Zentralen verwendbar.

|-
| '''[http://srcpd.sourceforge.net/ srcpd]'''
| DCC, MM '''(2)''' / -
| - / -
| -
| - || ja '''(2)'''
| [[SRCP-Grundlagen|SRCP]] / [[S88-Rückmeldebus|S88]], [[SRCP-Grundlagen|SRCP]] '''(2)'''
| ja / ja, mit ACK-Detector
| -
| RS232, Parallel / ja '''(2)'''
| PC
| Weiterentwicklung von DDL. Auch für klassische Digital Zentralen verwendbar.

{{Zentralheader-2}}

|}
'''Anmerkungen:'''
# Anschluss Platine mit Booster im gleichen Projekt verfügbar.
# Über zusätzliche Interfaces, lassen sich die Protokolle und Bussystem der daran angeschlossen Zentralen mitnutzen. Eine Übersicht findet sich unter: [http://bonus.dyndns.org/mediawiki/index.php/SRCPD-Devices]
</div>

Benutzer:Michael Oppenauer/Test-Digitalzentrale

2008-11-14T13:44:53Z

Michael Oppenauer: Beschreibung "Aktuelle Zentralen"

[[Bild:Arrowright.gif]]    
Gerät, das als zentrale Einheit die Signale der Steuergeräte empfängt und gemäß eines festgelegten [[Digitalprotokoll|Digitalprotokolls]] daraus die zum Gleis (bzw. dem jeweiligen [[Decoder]]) hin laufenden Digitalsignale erzeugt. Üblicherweise sind in den Digitalzentralen auch ein [[Booster]] und mehrere Eingabegeräte (z.B. Geschwindigkeitsregler, Funktionstasten) integriert, so dass für ein minimales System bis auf eine digitalisierte Lok keine weiteren Geräte benötigt werden.

In den unten verlinkten Tabellen findet sich eine Übersicht über verschiedenen Digitalzentralen.
* [[Neuvorstellungen]]
: Zentralen, die vorgestellt aber noch nicht im Handel verfügbar sind.
* [[Benutzer:Edbert_van_Eimeren/Test-Vollsysteme | Aktuelle Zentralen]]
: Zentralen, die bei den Herstellern lieferbar sind.
* [[Historische Zentralen]]
: Zentralen, die von den Herstellern nicht mehr produziert werden.
* [[Selbsbauzentralen]]
: Anleitungen zum selber Löten einer Zentrale oder zur Nutzung eines PC zur Erzeugung der Digitalsignale.

Zum besseren Verständnis gibt es noch eine separate Seite mit [[Benutzer:Michael_Oppenauer/Test-Erläuterungen_zu_Digitalzentralen-Tabellen | Erläuterungen]] zu den Tabellen.

Benutzer:Michael Oppenauer/Test-Digitalzentrale

2008-11-14T09:51:50Z

Michael Oppenauer:

[[Bild:Arrowright.gif]]    
Gerät, das als zentrale Einheit die Signale der Steuergeräte empfängt und gemäß eines festgelegten [[Digitalprotokoll|Digitalprotokolls]] daraus die zum Gleis (bzw. dem jeweiligen [[Decoder]]) hin laufenden Digitalsignale erzeugt. Üblicherweise sind in den Digitalzentralen auch ein [[Booster]] und mehrere Eingabegeräte (z.B. Geschwindigkeitsregler, Funktionstasten) integriert, so dass für ein minimales System bis auf eine digitalisierte Lok keine weiteren Geräte benötigt werden.

In den unten verlinkten Tabellen findet sich eine Übersicht über verschiedenen Digitalzentralen.
* [[Neuvorstellungen]]
: Zentralen, die vorgestellt aber noch nicht im Handel verfügbar sind.
* [[Benutzer:Edbert_van_Eimeren/Test-Vollsysteme | Aktuelle Zentralen]]
: Zentralen, die im Handel zu kaufen sind.
* [[Historische Zentralen]]
: Zentralen, die von den Herstellern nicht mehr produziert werden.
* [[Selbsbauzentralen]]
: Anleitungen zum selber Löten einer Zentrale oder zur Nutzung eines PC zur Erzeugung der Digitalsignale.

Zum besseren Verständnis gibt es noch eine separate Seite mit [[Benutzer:Michael_Oppenauer/Test-Erläuterungen_zu_Digitalzentralen-Tabellen | Erläuterungen]] zu den Tabellen.

Benutzer:Michael Oppenauer/Test-Erläuterungen zu Digitalzentralen-Tabellen

2008-11-14T09:32:55Z

Michael Oppenauer:

Da die Tabellen mit den Digitalzentralen ziemlich umfangreich sind, muss darauf geachtet werden, die Informationen möglichst kompakt darzustellen.
Dazu wurden teilweise mehrere Informationen in einer Spalte zusammengefasst und mit zahlreichen Abkürzungen gearbeitet.
Hier wird erklärt, welche Informationen in den einzelnen Spalten zu finden sind und ggfs. wie sie zu interpretieren ist.

Es ist zu berücksichtigen, dass in den Tabellen nur Eigenschaften von Digitalzentralen beschrieben werden.
Notwendige Voraussetzungen bei anderen Komponenten werden in der Regel nicht erwähnt.

__TOC__

==Tabellen nach diesem Schema==
[[Benutzer:Edbert_van_Eimeren/Test-Vollsysteme]]
...

==Spaltenbeschreibung==

===Hersteller Gerät===
: Name des Herstellers in Kurzform. Nach diesem Namen sind die Tabellen zeilenweise sortiert.
: Name des Gerätes unter dem es bekannt ist. Bestellnummer werden nur in Ausnahmenfällen (z.B. zur Eindeutigkeit) in Klammern hinzugefügt.

===Protokoll===
: Die Digital-Protokolle auf der Gleisseite, die von diesem Gerät unterstützt werden.
: Im Abschnitt [[#Abkürzungen| Abkürzungen]] findet sich eine Liste der Protokolle.

===Protokoll/BiDi===
: (Nur bei Selbstbauzentralen) Zusätzlich zu den Digital-Protokollen wird aufgeführt, ob die Zentrale bidirektionale Kommunikation nach NMRA unterstützt, siehe auch [[#Abkürzungen| Abkürzungen]].
: Wenn die Zentrale über einen globalen Detektor verfügt, so steht in der Spalte "ja". Kann sie nur die notwendig Austastlücke erzeugen, so steht in der Spalte "CutOut".

===Regler Fest / Hand===
: Anzahl der eingebauten Fahrregler resp. Anzahl der im Lieferumfang enthaltenen Handregler

===Display===
: Von einer Status-LED über wenige Ziffern/Zeilen bis hin zum farbigen Vollgrafik-Display ist alles vertreten.

===Booster intern===
: Ist ein Booster eingebaut, gibt es hier die Angaben zu Strom und Spannung und ob diese stabilisiert sind. Wenn ein Hersteller nicht angibt, ob der interne Booster stabilisiert ist, kann man vermuten, dass er das nicht ist.

===Anschluss Booster extern===
: Es gibt mehrere Varianten einen externen Booster anzuschliessen:
:# 3-polig (Daten, Masse, Kurzschluss) (DCC Norm)
:# 5-polig (Daten, Masse, Booster ein, -, Kurzschluss) (Märklin Art)
:# Über das eigene Bussystem wie bei LocoNet, ECosLink und dem Zimo CAN-Bus.
:#: Dies erlaubt einen Informationsaustausch zwischen Boostern und Zentrale.
:# Über einen spezifischen Stecker, dessen Belegung/Arbeitsweise nicht bekannt ist.
:#: Dies ist bei LGB, Roco, Tams und etlichen anderen der Fall.
:# Gleissignal (Zweidraht-Anbindung)
:#: Das Gleissignal kann als Eingangssignal für einen Booster verwendet werden. Allerdings werden alle Störungen, die in das Gleissignal eingekoppelt werden, automatisch mit verstärkt. Weiter ist damit keine Kurzschluss-Meldung an die Zentrale möglich.
: Ein Anschluss nach Punkt 1 und/oder 2 ist an vielen Systemen vorhanden (ggfs. zusätzlich zum eigenen System-Anschluss) um möglichst viele Booster verwenden zu können.
: Ein Anschluss nach Punkt 3 wird mit dem Namen des Bussystems bezeichnet.
: Eine Zentrale kann mehrere Anschluss-Arten parallel oder umschaltbar anbieten.
: Ist die Anschluss-Art nicht eindeutig klar steht in der Spalte "ja" / "?" / "-" (was auch immer passt).

===Eingabe/Rückmelde-Bus===
: Zentralen können keinen, einen oder mehrere Busse für Eingabe (Fahrregler, Keyboards, Interface, ...) und/oder Rückmeldung anbieten. Nicht genannt werden Busse, die nur über Adapter zugänglich sind.
: Siehe hierzu die Liste der Busse im Abschnitt [[#Abkürzungen| Abkürzungen]]

===Decoder einstellen/auslesen===
: Decoder können auf einem Programmiergleis ("Prog") oder im laufenden Betrieb auf dem Hauptgleis ("POM", Programming On Main) eingestellt werden.
: Decoder konnten bis ca. 2005/2006 nur auf einem Programmiergleis ausgelesen werden.
: Neue Entwicklung wie die '''BiDi'''rektionale Kommunikation bei DCC oder das '''mfx'''-Protokoll von Märklin erlauben den Decodern Informationen an die Zentrale zu senden (Quittung, Wert, Zustand, ...).
: Zur Zeit stehen in dieser Spalte meist "ja", "-" oder bekannte Einschränkungen. In Zukunft wird das etwas detaillierter angegeben werden.

===Mehrfachtraktion===
: Angaben ob Mehrfachtraktionen über die Zentrale (jede Lok einzeln angesteuert) und/oder durch die Verbund-Adresse im Decoder (alle Loks mit einem Befehl angesteuert, nur bei DCC) gebildet werden.
: Ggfs. Anzahl der Mehrfachtraktionen und wieviele Loks enthalten sein können.

===Interface eingebaut/anschließbar===
: Bei einem eingebauten Interface wird die Art des Computeranschlusses (RS232 / USB / Ethernet, ...) angegeben.
: Für externe Interface steht nur "ja" oder "-", da die Entwicklung fliessend ist und oft auch '' 'systemfremde' '' Interfaces funktionieren.

===Software Update via===
: Digitalzentralen enthalten ein Programm, das festlegt, was diese Zentrale im Einzelnen macht.
: Um das Verhalten einer Zentrale zu ändern/erweitern, muss das Programm ausgetauscht werden.
: Dazu gibt es mehrere Möglichkeiten:
:* Hardware (Platine) inkl. Prozessor und Programm austauschen.
:* Programmspeicher (PROM, EPROM, EEPROM) auf der Platine wechseln.
:* Inhalt des Programmspeicher über Interface + PC + Ladeprogramm aktualisieren.
:* Inhalt des Programmspeicher über einen USB-Stick oder einen Direktanschluss an das Internet aktualisieren.

===Bemerkungen===
: -   "Max. xxx Loks aktiv" bedeutet, das maximal xxx Loks gleichzeitig gesteuert werden können.
:: Die Zahl der Loks für die eine Zentrale Einstellungen speichern kann, ist davon unabhängig.
: -   Alles was wichtig ist, aber in die anderen Spalten nicht reinpasst.
:: Einschränkungen, Besonderheiten, Querverbindungen, Planungen, Updates, Erweiterungen, ...

 

== Abkürzungen ==

Übersicht über in den Tabellen verwendete Abkürzungen.

===Protokolle===
====DCC====
'''D'''igital '''C'''ommand '''C'''ontrol    von der '''NMRA''' genormtes Digital-Protokoll
* Wird wegen der klaren Definition und der damit verbundenen Austauschbarkeit von vielen Herstellern eingesetzt. Es sind keine Lizenzabgaben notwendig. Aus historischen Gründen wird es meist bei Zweileiter-Systemen verwendet.
* 9999+ Lokadressen, 1024 Weichenadressen
====BiDi====
'''Bi'''-'''Di'''rectional Communication
* von der '''NMRA''' empfohlenes Protokoll für die Zwei-Wege Kommunikation bei DCC.
* Liefert Informationen zu Adresse, CV-Werten, Zustand, Verbrauch, ...
====FMZ====
'''F'''leischmann '''M'''ehr'''z'''ug Steuerung
* 119 Adressen für Lok- und Weichen-Decoder (je 4 Weichen/Signale)
====MM====
'''M'''ärklin '''M'''otorola    altes Märklin Protokoll
* Soweit notwendig wird nach MM1 (nur Licht, relative Richtung) und MM2 (Licht, 4 Funktionen, absolute Richtung) unterschieden.
* 80 Lokadressen, 256 Weichenadressen. Fremd-Decoder ermöglichen teilweise auch 255 Adressen.
====mfx====
'''m'''ulti'''f'''unktion e'''x'''tra    Protokoll von Märklin Systems
* 16000+ Adressen, Rückkanal Dekoder -> Zentrale
====SX====
'''S'''electri'''x'''    Protokoll von Trix
* 112 Adressen für Lok- und Weichen-Decoder (je 8 Weichen/Signale)

===Busse===
====CAN====
'''C'''ontroller '''A'''rea '''N'''etwork    Bus nach einem Industriestandard
* Wird von mehreren Herstellern unter verschiedenen Namen mit unterschiedlichen Protokollen / Geschwindigkeiten verwendet.
====I2C====
'''I'''nter '''I'''ntegrated '''C'''ircuit    Eingabebus der Märklin Control Unit
* Wird von Uhlenbrock/Fleischmann/Arnold zum Anschluss von Märklin Komponenten verwendet.
====S88====
[[S88-Rückmeldebus|Rückmeldebus]] von Märklin.
* Wird wegen seiner Einfachheit / Verbreitung von mehreren Herstellern verwendet / unterstützt.
====X–Bus====
e'''X'''change / e'''X'''treme / e'''X'''press / ... {{r}}    Eingabebus von Lenz (heute XpressNet)
* Varianten des X–Bus werden von verschiedenen Herstellern eingesetzt.
====RS-Bus====
[[RS-Rückmeldebus|Rückmeldebus]] von Lenz
====LocoNet====
'''Loco'''motion '''Net'''work {{r}}
* Bussystem von Digitrax für Eingaben '''und''' Rückmeldungen.
* Wird auch von Uhlenbrock / Fleischmann / Piko benutzt.
====Speedbus====
Viessmann-Bussysteme mit
* V-Bus (HighSpeedBus HSB) für Fahrregler / Adapter und
* Schaltbus (LowSpeedBus LSB) für Rückmelder / Decoder / Gleisbildstellpult.
* Der LSB unterstützt X–Bus Geräte wie Rückmelder von Roco und Handregler von Lenz/Roco/...
====SRCP====
'''S'''imple'''R'''ailroad'''C'''ommand'''P'''rotokol   
* Protokoll zur Kommunikation von Modellbahn-Steuerungen und Software über TCP/IP (z.B. Ethernet)
* Wurde im Rahmen des [[Digitalprojekt|Digitalprojektes auf DER_MOBA]] entwickelt.

===Digitalbegriffe===
====POM====
'''P'''rogramming '''O'''n '''M'''ain (track)
* DCC-Empfehlung (Programmieren auf dem Hauptgleis)
====BiDi====
'''Bi'''-'''Di'''rectional Communication
* DCC-Empfehlung zur Zwei-Wege Kommunikation, auch unter dem Markennamen '''RailCom''' bekannt.
* '''Decoder''' können '''über das Gleis''' Informationen '''senden'''. Geräte (lokaler Detektor, Zentrale, PC, ...) können die Informationen empfangen und auswerten.
====NMRA====
'''N'''ational '''M'''odel '''R'''ailroad '''A'''ssociation
* Amerikanische Modellbahn Vereinigung. Legt über einen demokratischen Prozess die Normen und Empfehlungen in allen Bereichen der Modellbahn fest.
====NEM====
'''N'''ormen '''E'''ropäischer '''M'''odellbahner
* Die NEM ist das europäische Gegenstück zu den "Standards and Recommandation" der NMRA. Aufgrund der Unterschiede bei den Vorbildern und dem Umfeld für Modellbahnen (Platz, ...) unterscheiden sie sich teils erheblich. Im Bereich der Digital-Protokolle übernimmt die NEM in der Regel die DCC-Empfehlungen der NMRA bzw. bei anderen Protokollen die Vorgaben der Hersteller.

===Computer/Hardware===
====Ethernet====
Lokales Netzwerk mit Kabel (LAN, 10-1000 MBit) oder mit Funk (WLAN, 11-54 MBit)
====USB====
'''U'''niversal '''S'''erial '''B'''us, ''moderne'', schnelle serielle Schnittstelle
====RS232====
''alte'' serielle Schnittstelle (auch V.24 genannt)
====LED====
'''L'''ight '''E'''mitting '''D'''iode
====LCD====
'''L'''iquid '''C'''ristal '''D'''isplay
====OLED====
'''O'''rganic '''L'''ight '''E'''mitting '''D'''iode (wird bei Digitalzentralen zur Zeit noch nicht verwendet.)

Modellbahnanlagenbau

2008-11-14T08:02:40Z

Michael Oppenauer: /* Spezialgebiete */ Link angepasst

= Modellbahnanlagenbau =

Hinweis: Diese Gliederung ist ein Vorschlag und soll zum einen die Anzahl der Themen reduzieren, zum anderen eine komplette Übersicht über die beim Bau einer Modellbahnanlage wesentlichen Aspekte bieten.

== Modellbahnraum ==
:[[Modellbahn-Raum]]
:[[Raumbeleuchtung]]

== Unterbau ==
:[[Einmaleins des Anlagenbaus]]
:[[Module und Segmente]]
:[[Geräuschdämmung]]

== Landschaftsbau ==
:[[Landschaftsbau]]
:[[Zubehör]]

==Kunstbauten==
:[[Tunnel]]
:[[Brücken]]

==Gebäudebau==
:[[Gebäude-Selbstbau]]
:[[Selbstbau Gebäude(FAQ)|FAQ Gebäude-Selbstbau]]
:[[Gebäudebau|Gebäudebau mit Industriebausätzen]]

==Elektrik und Elektronik==
:[[Fahrstromverdrahtung]]
:[[Blockstreckensteuerung]]
:[[Kontaktstrecke]]

== Spezialgebiete ==
:[[Bau einer Gleiswendel]]

{{Baustelle}}

Bau einer Gleiswendel

2008-11-13T17:41:40Z

Michael Oppenauer: /* Eine Gleiswendel für "Bad Knüsselsdorf" */ Link gesetzt

__TOC__

= Eine Gleiswendel für "Bad Knüsselsdorf" =

Bei meiner ehemaligen Anlage "Bad Knüsselsdorf" mußte ein Höhenunterschied von 30cm zwischen Bahnhof und [[Schattenbahnhof]] überwunden werden. Dazu kam nur eine [[Gleiswendel]] in Frage, deren Konstruktion ich im folgenden beschreiben möchte.

= Abmessungen =

Der Platz für die Wendel war vorgegeben, mehr als ein Radius von 50cm war nicht unterzubringen. Obwohl ich sonst Flexgleise einsetze, wählte ich hier fertig vorgebogenes Gleis und entschied mich für den ROCO-LINE R4 (48,1cm). Die lichte Höhe zwischen zwei Gängen der Wendel sollte inklusive Gleis ca. 7cm betragen. Bei einer Trassendicke von 1,6cm ergab sich damit eine Höhendifferenz von gut 9cm pro Umlauf, insgesamt also eine Steigung von ungefähr 3%. Die Trassenbretter waren 10cm breit, damit rechts und links neben dem Gleis genügend Platz für die Gewindestangen blieb.

Ein paar Hinweise für die Ermittlung der Abmessungen beim Nachbau:

7cm lichte Höhe reichen bei der Verwendung von Kunststoffgleis sogar für Oberleitungsbetrieb. Natürlich können keine Masten gesetzt werden, aber ein Gleisprofil unter der Trassenunterseite sollte für den sicheren Betrieb genügen. Andererseits sollten 7cm tunlichst nicht unterschritten werden. Es lassen sich zwar beim Dampf- und Dieselbetrieb noch 10-15mm "herauskitzeln", aber dann wird es sehr eng, falls man eines Tages entgleiste Fahrzeuge wieder auf die Schienen setzen möchte. Bei der Dicke der Trassenbretter sind vielleicht noch 5mm drin.

Hier ein paar Beispiele für die resultierenden Steigungen bei unterschiedlichen Abmessungen, die Radien entsprechen dabei dem ROCO-LINE Programm.

{| border="1"
! Lichte Höhe
! Trassendicke
! R2=35,8cm
! R3=42,0cm
! R4=48,1cm
! R5=54,3cm
! R6=60,4cm
|-
|7cm
| 1,6cm
| 3,8%
| 3,3%
| 2,8%
| 2,5%
| 2,3%
|-
|6cm
| 1,6cm
| 3,4%
| 2,9%
| 2,5%
| 2,2%
| 2,0%
|-
|6cm
| 1,0cm
| 3,1%
| 2,7%
| 2,3%
| 2,1%
| 1,8%
|}

Man sollte stets versuchen, die Steigung so gering wie möglich zu halten, also einen möglichst großen Radius zu wählen. Die Steigung sollte 3 % nicht überschreiten, um einen sicheren Betrieb zu gewährleisten. Bei einer 2gleisigen Wendel sollte das nach oben führende Gleis nach Möglichkeit außen liegen (größerer Radius, geringere Steigung).

= Ein solides Fundament =

[[Bild:Gleiswendel helix4.gif|thumb|292px|Die Befestigung mit Gewindestangen geschieht alle 45°.]]
Eine große Platte aus 1,6cm Tischlerplatte diente als Grundplatte für die Gleiswendel. Ich zeichnete die Innen- und Außenkante der Trassenbretter mit einem Schnurzirkel an und legte probehalber einen Schienenkreis aus. Der Kreis wurde in 45 Grad-Segmente unterteilt (und weil ich dann Hunger auf Pizza bekam, machte ich erstmal eine Pause)

Danach wurden die Kanten entlang der Markierungen mit einer Stichsäge ausgesägt. Eine Kante blieb gerade, dort wurde die Wendel später an der Zimmerwand befestigt .

Entlang der 45-Grad Markierungen bohrte ich dann 6mm Paß-Löcher für die Gewindestangen, jeweils 1,5cm von der Außen- bzw. Innenkante entfernt. HINWEIS: An dieser Stelle sollte man die Gewindestangen nach dem ersten Paar Löcher probehalber einfügen und mit dem längsten verfügbaren Fahrzeug Testfahrten durchführen. Ich benutzte dazu einen 26,4m Personenwagen im Längenmaßstab 1/87.

 
= Das Trassenbrett =

[[Bild:Gleiswendel helix2.jpg|framed|Die Preßspanbretter und Sperrholzbretter überlappen an den Stoßstellen, damit keine Knicke entstehen.]]
Das Trassenbrett entstand aus zwei 8mm dicken Holzstreifen. Auf der Unterseite nahm ich Preßspann, nach oben zum Gleis hingegen Sperrholz, da dort die Gleise festgeschraubt werden sollten. Mit Hilfe der fertig geschnittenen Grundplatte machte ich eine Pappschablone und sägte einige Stücke aus den Holzplatten aus. Schließlich baute ich daraus ¾-Kreise zusammen und achtete darauf, daß die Fugen immer versetzt blieben, ähnlich einem Ziegelmauerwerk. Damit vermeidete ich Knicke zwischen den Übergängen. Bei jedem der Teilkreise achtete ich darauf, daß am "unteren" Ende die obere Holzlage hervorschaute und am "oberen" Ende die untere Lage überstand. Beim späteren Zusammenbau (von unten nach oben) überlappt der neue Abschnitt den vorherigen. Schließlich wurden die Teile später immer von oben eingesetzt!. Wenn ein Teilkreis fertig war, befestigte ich das erste Stück des nächsten Abschnittes mit Schraubzwingen daran, um den richtigen Versatz zu bekommen. Genauigkeit ist nicht so wichtig (das ist wiederum wichtig für mich), kleine Lücken von 1-2mm zwischen benachbarten Abschnitten sind nicht problematisch. Nachdem alles fertig war, klemmte ich alles mit Schraubzwingen auf die Grundplatte und bohrte 6mm Löcher durch das ganze Paket, dabei benutzte ich die Löcher in der Grundplatte als Führung. Danach nahm ich wieder alles auseinander und bohrte die Löcher in den Trassenbretter (nicht die in der Grundplatte!) auf 8mm auf, um später genug Spiel für die Feinjustage zu haben. HINWEIS: Vor dem Bohren sollten die Teilstücke sorgfältig ausgerichtet werden!

 
= Aufwärts bitte! =

[[Bild:Gleiswendel helix3.gif|thumb|365px|Die Trassenbretter werden mit Muttern in der Höhe exakt ausgerichtet und befestigt.]]

Ich befestigte die M6-Gewindestangen mit Unterlegscheiben und M6-Muttern an der Grundplatte. Dann fügte ich das erste Teilstück hinzu (dabei sollte man nicht vergessen, zuvor die nötige Anzahl Muttern und Scheiben einzulegen!) und schraubte die Gleise auf die Trasse. Das nächste Trassenbrett nebst nötigen Kleineisen wurde eingesetzt und am vorherigen festgeklebt. SEHR WICHTIG: Das Gleis wurde sorgfältig verlegt und Gleisstöße genau an den Segmentenden vermieden, ggfs. unter Einsatz von ½ Gleisstücken. Nachdem alles montiert war, befestigte ich die Wendel am Anlagenunterbau. Dann war die Feinjustage an der Reihe. Mit Hilfe der Muttern war es einfach, die richtigen Höhen von unten nach oben einzustellen. Ich nutzte die Grundplatte als Referenz, notierte mir die richtigen Höhenmasse und stellte sie mit einem Lineal und Schraubenschlüssel ein. Neben dem sauber verlegtem Gleis ist auch eine gleichmäßige Steigung sehr wichtig für die Betriebssicherheit. Daher kontrollierte ich mehrmals, ob alle Abstände nun wirklich richtig waren..

Vorsichtige Modellbahner können die Muttern jeweils noch mit einer Kontermutter versehen.

 
= Der Abschluß =

[[Bild:Gleiswendel helix1.jpg|framed|Die Gleiswendel wird mit einem abnehmbaren Landschaftsteil überbaut.]]

Bei der Gleisverlegung muß (wie in allen verdeckten Abschnitten) mit besonderer Sorgfalt gearbeitet werden. Vor dem Weiterbau der Anlage müssen umfangreiche Testfahrten stattfinden. Nach dem Überbau mit Landschaft ist die Gleiswendel nur schwerer zu erreichen, um Fehler zu beheben.

Natürlich blieb ein großes Loch in der Mitte der Wendel. Aus den Überresten der Grundplatte baute ich eine abnehmbare Abdeckplatte. Als Ummantelung plante ich Hartfaserplatten, welche sich genügend biegen lassen. Bevor ich jedoch dazu kam, wurde "Bad Knüsselsdorf" wegen Umzug abgebaut. Mittlerweile deutet es sich ab, daß auch "Bad Knüsselsdorf II" mit einer Wendel ausgestattet werden wird. Die alte Gleiswendel läßt sich in Grenzen anpassen: Zusätzliche "Umdrehungen" lassen sich durch Verlängerungen der Gewindestangen ansetzen. Geringe Abweichungen in den Höhenlagen können durch die Muttern eingestellt werden. Das alte Bauteil wird also wahrscheinlich weiter verwendet werden ...

 
----

Der ursprüngliche Autor Frank Forsten pflegt seine Version auf seiner Homepage http://www.forsten-online.de

[[Kategorie:Anlagenbau]]

Gleiswendel

2008-11-13T16:18:27Z

Michael Oppenauer: Bild eingefügt

Gleiswendel

2008-11-12T15:11:45Z

Michael Oppenauer: Rechtschreibung

{{Glossar}} Unter einer Gleiswendel versteht man eine schraubenförmige Gleisfigur. Mit ihr lässt sich kompakt an Höhe gewinnen, um z. B. von der sichtbaren Ebene in einen unter der Anlage angeordneten [[Schattenbahnhof]] zu kommen. Dieser Artikel beschreibt, wie man eine Gleiswendel aufbauen kann.

__TOC__

= Eine Gleiswendel für "Bad Knüsselsdorf" =

Bei meiner ehemaligen Anlage "Bad Knüsselsdorf" mußte ein Höhenunterschied von 30cm zwischen Bahnhof und [[Schattenbahnhof]] überwunden werden. Dazu kam nur eine Wendel in Frage, deren Konstruktion ich im folgenden beschreiben möchte.

= Abmessungen =

Der Platz für die Wendel war vorgegeben, mehr als ein Radius von 50cm war nicht unterzubringen. Obwohl ich sonst Flexgleise einsetze, wählte ich hier fertig vorgebogenes Gleis und entschied mich für den ROCO-LINE R4 (48,1cm). Die lichte Höhe zwischen zwei Gängen der Wendel sollte inklusive Gleis ca. 7cm betragen. Bei einer Trassendicke von 1,6cm ergab sich damit eine Höhendifferenz von gut 9cm pro Umlauf, insgesamt also eine Steigung von ungefähr 3%. Die Trassenbretter waren 10cm breit, damit rechts und links neben dem Gleis genügend Platz für die Gewindestangen blieb.

Ein paar Hinweise für die Ermittlung der Abmessungen beim Nachbau:

7cm lichte Höhe reichen bei der Verwendung von Kunststoffgleis sogar für Oberleitungsbetrieb. Natürlich können keine Masten gesetzt werden, aber ein Gleisprofil unter der Trassenunterseite sollte für den sicheren Betrieb genügen. Andererseits sollten 7cm tunlichst nicht unterschritten werden. Es lassen sich zwar beim Dampf- und Dieselbetrieb noch 10-15mm "herauskitzeln", aber dann wird es sehr eng, falls man eines Tages entgleiste Fahrzeuge wieder auf die Schienen setzen möchte. Bei der Dicke der Trassenbretter sind vielleicht noch 5mm drin.

Hier ein paar Beispiele für die resultierenden Steigungen bei unterschiedlichen Abmessungen, die Radien entsprechen dabei dem ROCO-LINE Programm.

{| border="1"
! Lichte Höhe
! Trassendicke
! R2=35,8cm
! R3=42,0cm
! R4=48,1cm
! R5=54,3cm
! R6=60,4cm
|-
|7cm
| 1,6cm
| 3,8%
| 3,3%
| 2,8%
| 2,5%
| 2,3%
|-
|6cm
| 1,6cm
| 3,4%
| 2,9%
| 2,5%
| 2,2%
| 2,0%
|-
|6cm
| 1,0cm
| 3,1%
| 2,7%
| 2,3%
| 2,1%
| 1,8%
|}

Man sollte stets versuchen, die Steigung so gering wie möglich zu halten, also einen möglichst großen Radius zu wählen. Die Steigung sollte 3 % nicht überschreiten, um einen sicheren Betrieb zu gewährleisten. Bei einer 2gleisigen Wendel sollte das nach oben führende Gleis nach Möglichkeit außen liegen (größerer Radius, geringere Steigung).

= Ein solides Fundament =

[[Bild:Gleiswendel helix4.gif|thumb|292px|Die Befestigung mit Gewindestangen geschieht alle 45°.]]
Eine große Platte aus 1,6cm Tischlerplatte diente als Grundplatte für die Gleiswendel. Ich zeichnete die Innen- und Außenkante der Trassenbretter mit einem Schnurzirkel an und legte probehalber einen Schienenkreis aus. Der Kreis wurde in 45 Grad-Segmente unterteilt (und weil ich dann Hunger auf Pizza bekam, machte ich erstmal eine Pause)

Danach wurden die Kanten entlang der Markierungen mit einer Stichsäge ausgesägt. Eine Kante blieb gerade, dort wurde die Wendel später an der Zimmerwand befestigt .

Entlang der 45-Grad Markierungen bohrte ich dann 6mm Paß-Löcher für die Gewindestangen, jeweils 1,5cm von der Außen- bzw. Innenkante entfernt. HINWEIS: An dieser Stelle sollte man die Gewindestangen nach dem ersten Paar Löcher probehalber einfügen und mit dem längsten verfügbaren Fahrzeug Testfahrten durchführen. Ich benutzte dazu einen 26,4m Personenwagen im Längenmaßstab 1/87.

 
= Das Trassenbrett =

[[Bild:Gleiswendel helix2.jpg|framed|Die Preßspanbretter und Sperrholzbretter überlappen an den Stoßstellen, damit keine Knicke entstehen.]]
Das Trassenbrett entstand aus zwei 8mm dicken Holzstreifen. Auf der Unterseite nahm ich Preßspann, nach oben zum Gleis hingegen Sperrholz, da dort die Gleise festgeschraubt werden sollten. Mit Hilfe der fertig geschnittenen Grundplatte machte ich eine Pappschablone und sägte einige Stücke aus den Holzplatten aus. Schließlich baute ich daraus ¾-Kreise zusammen und achtete darauf, daß die Fugen immer versetzt blieben, ähnlich einem Ziegelmauerwerk. Damit vermeidete ich Knicke zwischen den Übergängen. Bei jedem der Teilkreise achtete ich darauf, daß am "unteren" Ende die obere Holzlage hervorschaute und am "oberen" Ende die untere Lage überstand. Beim späteren Zusammenbau (von unten nach oben) überlappt der neue Abschnitt den vorherigen. Schließlich wurden die Teile später immer von oben eingesetzt!. Wenn ein Teilkreis fertig war, befestigte ich das erste Stück des nächsten Abschnittes mit Schraubzwingen daran, um den richtigen Versatz zu bekommen. Genauigkeit ist nicht so wichtig (das ist wiederum wichtig für mich), kleine Lücken von 1-2mm zwischen benachbarten Abschnitten sind nicht problematisch. Nachdem alles fertig war, klemmte ich alles mit Schraubzwingen auf die Grundplatte und bohrte 6mm Löcher durch das ganze Paket, dabei benutzte ich die Löcher in der Grundplatte als Führung. Danach nahm ich wieder alles auseinander und bohrte die Löcher in den Trassenbretter (nicht die in der Grundplatte!) auf 8mm auf, um später genug Spiel für die Feinjustage zu haben. HINWEIS: Vor dem Bohren sollten die Teilstücke sorgfältig ausgerichtet werden!

 
= Aufwärts bitte! =

[[Bild:Gleiswendel helix3.gif|thumb|365px|Die Trassenbretter werden mit Muttern in der Höhe exakt ausgerichtet und befestigt.]]

Ich befestigte die M6-Gewindestangen mit Unterlegscheiben und M6-Muttern an der Grundplatte. Dann fügte ich das erste Teilstück hinzu (dabei sollte man nicht vergessen, zuvor die nötige Anzahl Muttern und Scheiben einzulegen!) und schraubte die Gleise auf die Trasse. Das nächste Trassenbrett nebst nötigen Kleineisen wurde eingesetzt und am vorherigen festgeklebt. SEHR WICHTIG: Das Gleis wurde sorgfältig verlegt und Gleisstöße genau an den Segmentenden vermieden, ggfs. unter Einsatz von ½ Gleisstücken. Nachdem alles montiert war, befestigte ich die Wendel am Anlagenunterbau. Dann war die Feinjustage an der Reihe. Mit Hilfe der Muttern war es einfach, die richtigen Höhen von unten nach oben einzustellen. Ich nutzte die Grundplatte als Referenz, notierte mir die richtigen Höhenmasse und stellte sie mit einem Lineal und Schraubenschlüssel ein. Neben dem sauber verlegtem Gleis ist auch eine gleichmäßige Steigung sehr wichtig für die Betriebssicherheit. Daher kontrollierte ich mehrmals, ob alle Abstände nun wirklich richtig waren..

Vorsichtige Modellbahner können die Muttern jeweils noch mit einer Kontermutter versehen.

 
= Der Abschluß =

[[Bild:Gleiswendel helix1.jpg|framed|Die Gleiswendel wird mit einem abnehmbaren Landschaftsteil überbaut.]]

Bei der Gleisverlegung muß (wie in allen verdeckten Abschnitten) mit besonderer Sorgfalt gearbeitet werden. Vor dem Weiterbau der Anlage müssen umfangreiche Testfahrten stattfinden. Nach dem Überbau mit Landschaft ist die Gleiswendel nur schwerer zu erreichen, um Fehler zu beheben.

Natürlich blieb ein großes Loch in der Mitte der Wendel. Aus den Überresten der Grundplatte baute ich eine abnehmbare Abdeckplatte. Als Ummantelung plante ich Hartfaserplatten, welche sich genügend biegen lassen. Bevor ich jedoch dazu kam, wurde "Bad Knüsselsdorf" wegen Umzug abgebaut. Mittlerweile deutet es sich ab, daß auch "Bad Knüsselsdorf II" mit einer Wendel ausgestattet werden wird. Die alte Gleiswendel läßt sich in Grenzen anpassen: Zusätzliche "Umdrehungen" lassen sich durch Verlängerungen der Gewindestangen ansetzen. Geringe Abweichungen in den Höhenlagen können durch die Muttern eingestellt werden. Das alte Bauteil wird also wahrscheinlich weiter verwendet werden ...

 
----

Der ursprüngliche Autor Frank Forsten pflegt seine Version auf seiner Homepage http://www.forsten-online.de

[[Kategorie:Anlagenbau]]

S88-Rückmeldebus

2008-11-11T14:02:39Z

Michael Oppenauer: Vorlage Glossar verwendet

{{Glossar}} Ein preiswerter Rückmeldebus für die Modellbahn.

==Allgemeines==

Der Bus beruht auf einem einfachen Prinzip: er S88-Bus ist ein serielles Schiebe-Register mit parallelem Load-Eingang.

Weitere Teilnehmer dieses Busses werden durch einfaches Kaskadieren angeschlossen, so entsteht ein langes Schieberegister, in dem alle auszulesenden Bits in einer langen Kette liegen. Diesem Vorteil des einfachen Aufbaus stehen allerdings Nachteile gegenüber: Es ist keine Adressvorgabe der Rückmelder möglich und die Übertragung erfolgt vollkommen ungeschützt, d.h. es gibt weder Parity, Prüfsumme oder CRC.

==Steckerbelegung==

{| class=tabtyp1 cellpadding=0 cellspacing=0

|- valign=top 
! width=100 |PIN
! width=180 |Signal

|- valign=top 
! |1
| |Data

|- valign=top 
! |2
| |Ground

|- valign=top 
! |3
| |Clock

|- valign=top 
! |4
| |PS

|- valign=top 
! |5
| |Reset

|- valign=top 
! |6
| |5V

|}

==Datenübertragung==

Diese Leitungen sind in dieser Reihenfolge auf Pins im Raster 2.54mm angeschlossen.

Die LOAD-Leitung geht auf 1, darauf erfolgt ein Schiebtakt; alle Register in der Scheibekette übernehmen bei diesem Takt die Information an ihren Paralleleingängen. Als nächstes erfolgt ein RESET-Puls (auch aktiv high), dieser löscht die den Paralleleingang vorgeschalteten Latches, welche damit wieder bereit für die Übernahme neuer Information sind. Die Latches speichern auch kurze Signale bis zur nächsten Abfrage.

Nun wird das Schieberegister (mit LOAD = 0) mittels eines CLK-Pulses geschoben. Dadurch dass jeweils der Datenausgang eines S88-Moduls mit dem Dateneingang des nächsten verbunden ist, kommen so die beim ersten Takt geladenen Zustände der Latches nach und nach zur Zentrale.

==Probleme==

Oft wird der S88 als langsam und unsicher bezeichnet. Der Ruf 'langsam' rührt von der ersten Implementierung der Fa. Märklin her, die den Bus sehr langsam betrieb und auch das Interface hierzu nur mit 2400 Baud einstellte. Mittlerweile gibt es schnellere Implementierungen, die mit dem Datenaufkommen einer Modellbahnanlage mühelos zurechtkommen.

Die Unsicherheit hat drei wesentliche Ursachen:
* Einkopplungen (wegen ungeschirmten Leitungen)
* Masseströme aus der Anlage über den S88-Bus (besonders bei 3-Leiter Anlagen, da hier oft der Gleisrückstrom über den S88-Bus abfließt)
* keine Sicherung gegen Übertragungsfehler

==S88 über Netzwerkkabel==

Zur Reduzierung der Einkopplung können Netzwerkkabel (CAT5) verwendet werden, wobei folgende Normung (s88-N) verwendet werden soll:
{| border=1 align="center"
|+s88-N Norm
!Signal
!Pin

|-
|12V/5V
|align="center" | 1

|-
|DATA
|align="center" | 2

|-
|GND
|align="center" | 3

|-
|CLK
|align="center" | 4

|-
|GND
|align="center" | 5

|-
|PS (=LOAD)
|align="center" | 6

|-
|RESET
|align="center" | 7

|-
|RAILDATA
|align="center" | 8
|}

Eine Zentrale soll wahlfrei 5V oder 12V einstellbar haben. die Schaltschwelle ist Versorgungsspannung * 0.5. Wenn alle angeschlossenen Module 12V vertragen, so kann die höhere Spannung gewählt werden. Gegenüber der ursprüglichen Belegung wurde GND verdoppelt und RAILDATA (das Gleissignal) hinzugefügt, um eine einfache Parametrisierung der Module zu erlauben.

Da Netzwerkabel geschirmt sind, sinkt die Einkoppelung. Diese Belegung sorgt dafür, dass empfindliche Leitungen wie z.B. CLK oder RESET jeweils mit einer statischen Leitung (z.B. GND) verdrillt sind und minimiert daher die Einkopplung zusätzlich. Auf ebay werden oft s88 Module angeboten, deren Pinbelegung scheinbar willkürlich vergeben wurde, ohne auf die Leitungskopplung zu achten.

[[Bild:S88-n_logo.svg|100px|right|Logo]]In einer Abstimmung der Anbieter von s88 Modulen wurde diese Norm akzeptiert - es wird sukzessive umgestellt, um eine freie Kombination der Module zu ermöglichen. Komponenten nach dieser Norm sollen mit dem nebenstehenden Logo gekennzeichnet werden.
[http://www.opendcc.de/s88/s88_n/s88-n.html Lizenzbedingungen]

 

== Weblinks ==

[http://www.opendcc.de/s88/s88_n/s88-n.html www.opendcc.de] Erläuterungen, Oszillogramm, Adapterplatine

[[Kategorie:Digitalbetrieb]]

RS-Bus

2008-11-11T13:59:08Z

Michael Oppenauer: Verlinkung mit RS-Rückmeldebus

{{Glossar}} Rückmeldebus der Firma Lenz

Da dieser Bus offiziell nicht dokumentiert ist, sind die durch Experimentieren festgestellten technischen Grundlagen [[RS-Rückmeldebus | hier]] dokumentiert.

==Steckerbelegung==

{| class=tabtyp1 cellpadding=0 cellspacing=0

|- valign=top 
! width=100 |PIN
! width=180 |Signal Port A
! width=180 |Signal Port B

|- valign=top 
! |1
| |"C" Control Bus Connection
| |No Connection

|- valign=top 
! |2
| |Ground "M"
| |Ground "M"

|- valign=top 
! |3
| |- RS-485 "B"
| |- RS-485 "B"

|- valign=top 
! |4
| |+ RS-485 "A"
| |+ RS-485 "A"

|- valign=top 
! |5
| |+12 volts "L"
| |+12 volts "L"

|- valign=top 
! |6
| |"D" Control Bus Connection
| |No Connection

|}

FREMO

2008-11-11T13:48:35Z

Michael Oppenauer: Vorlage Glossar verwendet

[[Bild:Fremo JT2003.jpg|thumb|350px|FREMO Jahrestagung 2003 in Calw - verschiedene Modulanlagen in einer Dreifeldturnhalle]]
{{Glossar}} Freundeskreis Eurpäischer Modellbahner e.V.

Der '''Freundeskreis Europäischer Modellbahner e.V.''', abgekürzt '''FREMO''' ist ein Verein nach deutschem Vereinsrecht. Der Verein wurde 1981 gegründet und hat etwa 1000 Mitglieder in 15 europäischen Ländern. Der Vereins legt in seiner Satzung fest: ''"Zweck des Vereins ist es, das Modellbahnerhobby, insbesondere dessen kreativitäts- und aktivitätsbezogenen Aspekte sowie den persönlichen Kontakt unter den Modellbahnern auf überregionaler und internationaler Ebene zu fördern."''

Inhaltliche Schwerpunkte des Vereinslebens sind Bau und [[Normung]] von [[Modularer Modelleisenbahnbau|Modelleisenbahn-Modulen]] sowie die Veranstaltung von Treffen auf denen die einzelnen Module zu vorab geplanten Modularrangements [[Epoche |epochengerecht]] zusammengestellt werden. Das bedeutet, dass nur in der Realität zeitlich zueinander passende Fahrzeuge, dargestellte Bauten und technische Einrichtungen dargestellt und eingesetzt werden. Auf diesem Arrangement wird dann nach der Eisenbahnbetrieb nach [[Fahrplan]] durchgeführt. Jeder Zug hat einen [[Zugführer]], der zumeist auch die Aufgabe des [[Triebfahrzeugführer|Lokführers]] übernimmt und viele Betriebsstellen haben einen [[Fahrdienstleiter]]. Daher werden Modularrangements von mehreren Personen betrieben. Teilweise wird im [[Zugleitbetrieb]] gefahren, so dass ein [[Zugleiter]] notwendig wird.

Weitere Schwerpunkte sind die Entwicklung einer unter dem Namen ''[http://fremodcc.sourceforge.net/dcc_d.html Fremo-DCC]'' bekannten [[Steuerung der Modelleisenbahn#Digitalsteuerung|digitalen Steuerung]], die Umsetzung möglichst maßstabsgetreuer Bauweisen sowie die Herausgabe der Zeitschrift ''[[Hp1 Modellbahn]]''.

==Module (FreModule)==
Um auf den Fremotreffen die Module der einzelnen Mitglieder miteinander verbinden zu können, sind entsprechende Normen geschaffen worden. Die Modulsysteme werden nach ihrer [[Maßstäbe der Modelleisenbahn|Baugröße]] und bedarfsweise nach einem Thema bezeichnet. Die wichtigsten Systeme sind: 0, 0m, 0e, H0-Europa, H0-USA, H0PS, H0m, H0m-Rhätische Bahn, H0e, H0f, N. Innerhalb dieser Systeme gibt es wiederum Gruppen, die sich auf einzelne Themen festlegen.

Hauptvoraussetzung ist ein definierter Übergang zwischen den einzelnen Modulen, um die jeweils durchgehenden [[Gleis]]e miteinander verbinden zu können.

Ein weiterer Gesichtspunkt (neben Epoche und Vorbildregion) stellt auch das verwendete Gleismaterial dar: Die Geometrie von Gleisen aus Großserienfertigung unterscheidet sich deutlich vom Vorbild; häufig ist auch die Höhe des Schienenprofils der Modellgleise größer als eine genaue [[Maßstab (Verhältnis)|Maßstab]]sumrechnung ergibt. Am Gleismaterial orientiert sich die Geometrie der Fahrzeugräder. Die Umsetzung eines möglichst vorbildnahen Rad-Schiene-Systems gehört zu den wichtigsten Themen des FREMO.

Die Modulsysteme des FREMO legen neben dem genormten Modulübergang keine weiteren Abmaße der Module fest. Die Modulsysteme H0-Europa und N kennen ein- und zweigleisige Modulübergänge, alle anderen Systeme haben eine eingleisige Schnittstelle.

FreModule unterscheiden Strecken- und Betriebsstellenmodule. Streckenmodule enthalten keine [[Eisenbahnweichen]] und können elektrisch einfach ausgeführt werden; sie werden von den Zügen zwischen den Betriebsstellen durchfahren. Unter den Betriebsstellenmodulen versteht man neben [[Eisenbahnsicherungs-_und_-signaltechnik#Bahnhof|Bahnhöfen]] auch die [[Bahnanlage der freien Strecke]], wie [[Eisenbahnsicherungs-_und_-signaltechnik#Anschlußstellen_(Anst)_und_Ausweichanschlußstellen_(Awanst)|Anschlussstellen]], [[Eisenbahnsicherungs-_und_-signaltechnik#Abzweigstellen|Abzweigstellen]], [[Eisenbahnsicherungs-_und_-signaltechnik#Blockstellen|Blockstellen]] und [[Eisenbahnsicherungs-_und_-signaltechnik#Haltepunkte|Haltepunkte]].

==Weblinks==
[http://www.fremo.org Homepage des Vereins]

[[Kategorie:Verein]]

RS-Bus

2008-11-11T13:42:29Z

Michael Oppenauer: Vorlage Glossar verwendet

{{Glossar}} Rückmeldebus der Firma Lenz

==Steckerbelegung==

{| class=tabtyp1 cellpadding=0 cellspacing=0

|- valign=top 
! width=100 |PIN
! width=180 |Signal Port A
! width=180 |Signal Port B

|- valign=top 
! |1
| |"C" Control Bus Connection
| |No Connection

|- valign=top 
! |2
| |Ground "M"
| |Ground "M"

|- valign=top 
! |3
| |- RS-485 "B"
| |- RS-485 "B"

|- valign=top 
! |4
| |+ RS-485 "A"
| |+ RS-485 "A"

|- valign=top 
! |5
| |+12 volts "L"
| |+12 volts "L"

|- valign=top 
! |6
| |"D" Control Bus Connection
| |No Connection

|}

LocoNet

2008-11-11T13:38:36Z

Michael Oppenauer: Vorlage Glossar verwendet

{{Glossar}} LocoNet ist ein Peer-to-Peer Netzwerk, dass von der Firma [http://www.digitrax.com Digitrax] für Modellbahnanlagen konzipiert wurde. Das LocoNet dient sozusagen als Transportmedium innerhalb der Modellbahn, das einen gleichberechtigten Zugriff aller LocoNet-kompatiblen Komponenten in beiden Richtungen zulässt. Darüber kommunizieren die Zentrale, die Handregler; ebenso Schaltdecoder, Belegtmelder, Booster und angeschlossene Computer. Die Regler sind über LocoNet mit der Zentrale verbunden, diese wiederum steuert über dasselbe Netz die Booster, über die letztendlich die Decoder in der Lok ihre Steuersignale erhalten. Die in LocoNet enthaltenen Strukturen (Protokolle) sind ähnlich in der Datenkommunikation zu finden; LocoNet arbeitet nach dem [http://de.wikipedia.org/wiki/CSMA/CD CSMA/CD] bzw. [http://de.wikipedia.org/wiki/CSMA/CA CSMA/CA] Zugriffsverfahren. Die genaue technische Spezifikation von LocoNet gibt es bei Digitrax unter:
http://www.digitrax.com/ftp/loconetpersonaledition.pdf

==Vorteile==
* Verbindung aller Komponenten über ein einfaches, preiswertes Steckersystem (RJ12-Würfelstecker)
* Die Kabel können ausreichende Längen haben und auf der Anlage in Stern- oder Busform verteilt sein.
* Flexibles Design: Jedes Gerät darf senden, was er will, solange es nicht mit bestehendem Traffik kollidiert - somit auch Inhalte und sogar Formate (ggf. mit variabler Nutzdatenlänge), die sich der Erfinder des LN nicht ausgedacht hat.
* Die Buslast hängt von der Anzahl der Änderungen ab, nicht von der Anzahl der Geräte, die ggf. nichts tun
* Keine niedrige harte Grenze in der Adressierung

==Nachteile/Einschränkungen==
* Kein '''echtes''' Echtzeitsystem
* Begrenzung auf 119 verwaltete Lokadressen

==Steckerbelegung==

{| class=tabtyp1 cellpadding=0 cellspacing=0

|- valign=top 
! width=100 |PIN
! width=180 |Signal

|- valign=top 
! |1
| |DCC für Booster

|- valign=top 
! |2
| |Ground

|- valign=top 
! |3
| |LocoNet Data

|- valign=top 
! |4
| |LocoNet Data

|- valign=top 
! |5
| |Ground

|- valign=top 
! |6
| |DCC für Booster
|}

[[Kategorie:Digitalbetrieb]]

Kupplung

2008-11-11T13:37:52Z

Michael Oppenauer: Vorlage Glossar verwendet

{{Glossar}} Kupplungen dienen zum Verbinden von Loks und Wagen untereinander. Neben der vor allem bei größeren Spurweiten Verwendung von Originalkupplungen gibt es verschiedene Kupplungssystem die auf die Kompromiss behaftete Verkleinerung bei der Modellbahn Rücksicht nehmen. Hierbei dominiert die Funktion vor dem vorbildgerechten Aussehen.

= Kupplungstypen =

Grob gesagt gibt es zwei Sorten, nämlich Standardkupplungen sowie Kurzkupplungen. Kurzkupplungen zeichnen sich jedoch nur in 2. Linie dadurch aus, daß der Kuppelabstand den Raum zwischen den Puffern minimiert. Vielmehr bieten diese Kupplungen eine starre Verbindung untereinander, diese benötigen daher eine sogenannte Kurzkupplungskinematik am Wagenkasten oder zumindest eine beweglich ausgeführte Aufhängung. Diese Kinematik erweitert den Fahrzeugabstand im Bogen, um ein Verhaken/Verkeilen der Puffer zu verhindern.

{| border=1 | align="center"
!Typ
!Bezeichnung
!vorentkuppelbar
!Pufferabstand
|-
|rowspan="2"|Standardkupplungen (beweglich)
|[[Kupplung#Bügelkupplung|Bügelkupplung]]
|align="center"| -
|align="center"|5-7mm
|-
|[[Kupplung#Kadee-Kupplung|Kadee-Kupplung]]
|align="center"| x
|align="center"|5-7mm
|-
|rowspan="2"|Echte Kurzkupplungen (starr)
|[[Kupplung#ROCO-Kurzkupplung alt/neu|ROCO-Kurzkupplung]]
|align="center"| x
|align="center"|1-2mm
|-
|[[Kupplung#Fleischmann-Profi-Kupplung|Fleischmann-Profi-Kupplung]]
|align="center"| x
|align="center"|1-3mm
|-
|rowspan="2"|Universalkupplungen (eingeschränkt beweglich)
|[[Kupplung#ROCO-Universalkupplung|ROCO-Universalkupplung]]
|align="center"| x
|align="center"| 3-5mm
|-
|[[Kupplung#Märklin-Kurzkupplung|Märklin-Kurzkupplung]]
|align="center"| x
|align="center"| 3-5mm
|}

Die Angabe des Pufferabstands ist mit Vorsicht zu geniessen, sie hängt davon ab, mit welchen Toleranzen die Abstände Pufferebene-Vorderkante Normschacht ausgelegt sind. Bei den ersten Kurzkupplungsfahrzeugen von Roco ist dieser Abstand sehr knapp gehalten, was bei Verwendung von echten Kurzkupplungen zu Problemen beim Ankupplen führen konnte. Bei Loks, die in aller Regel nicht genügend Platz für eine ausreichend dimenionierte Kurzkupplungskinematik bieten, ist der Abstand Pufferebene-Vorderkante Normschacht höher, hier entsteht meist auch bei Verwendung von echten Kurzkupplungen ein Pufferabstand von 5mm oder höher.

Eine ausführlichere Tabelle mit Fotos und auch Angaben zu älteren, nicht mehr so gebräuchlichen Kupplungen findet sich unter [http://www.modellbahnfrokler.de/grundlagen/kupplungen.html Modellbahnfrokler: Grundlagen: Die Kupplungsfrage] von Erik Meltzer. Ausserdem findet sich dort eine Fülle von Frokelanleitungen nicht nur für Kupplungsumbauten.

= Normschacht/Kinematik =

Um verschiedene Kupplungsfabrikate freizügig verwenden zu können, wurde in den Normen Europäischer Modellbahner (NEM) auf Blatt 362 (H0) sowie 355 (N) eine einheitliche Kupplungsaufnahme für Kupplungsköpfe vereinbart, welche für Modellbahnhersteller als verbindlich zu betrachten ist. Damit im Zusammenhang steht NEM 352, welche die Führungen für Kupplungsaufnahmen (die sogenannte Kurzkupplungs-Kinematik) vorschreibt. (Siehe [http://miba.de/morop/nem352-d.pdf NEM 352] (PDF 28 KB), [http://miba.de/morop/nem355-d.pdf NEM 355] (PDF 28 KB) sowie [http://miba.de/morop/nem362-d.pdf NEM 362] (PDF 60 KB).) Darin ist auch die Lage des Normschachtes bezüglich Schienenoberkante und der Pufferebene festgelegt. Leider ist bei manchen älteren Fahrzeugen der Abstand Pufferebene-Normschacht-Vorderkante zu gering, wodurch sich Verhakungen/Überpufferungen) bei ungünstiger Gleisführungen (S-Kurven ohne Ausgleichsgerade oder zu enge Radien) ergeben können.

= Vorentkupplung =

Ermöglicht die Entkupplung am Entkuppelgleis oder mit dem Handentkuppler und das Schieben und Abstellen von Fahrzeugen an beliebige Positionen. Nach dem Abziehen des Wagenverbands fallen die Kupplungen zurück und sind bereit für den nächsten Kuppelvorgang.

= Bewegliche Kupplungsverbindungen =

== Bügelkupplung ==

Die Standardkupplung für den Modellbahner, nachteilig ist der große Pufferabstand und die schwergängige Entkupplung bei bestimmten Kupplungskombinationen. Es gibt von der Kopfform her sehr viele verschiedene Ausführungen, generell gilt: Je größer der Kupplungsbügel, desto schlechter die Kuppel-/Entkuppelbarkeit mit anderen Fabrikaten (z.B. ROCO-Standardkupplung). Pufferabstand: ca. 5-10 mm. Bewährt hat sich u. a. die Bügelkupplung von Klein Modellbahn (in Deutschland Vertrieb durch M+D), die sehr zierlich ist und sich leicht entkuppeln läßt, da die Zapfen an der Unterseite beispielsweise im Gegensatz zur Roco-Bügelkupplung nahe beieinander liegen sowie der Bügel nicht durch ein Federelement niedergedrückt wird und so das Entkuppeln auch mit einem schmalen Entkuppler leicht von der Hand geht.

== Kadee-Kupplung ==

Diese der US-amerikanischen Eisenbahn abgeschaute Kupplung ist sehr sanft kuppel- und magnetisch entkuppelbar, nachteilig ist, daß sie relativ teuer ist und die Kurzkupplungskinematik zur Vermeidung von Störungen festgelegt werden muß. Näheres zu Vor- und Nachteilen siehe unter [[Vergleich_Kadee-Kupplung_und_Roco-Kupplung]].

= Starre Kupplungsverbindungen (Kurzkupplungen) =

Hierbei gibt es zwei Unterklassen, nämlich echte Kurzkupplungen und kompatible Kurzkupplungen, die Kombination mit Bügelkupplungen erlauben sollen. Erstere ermöglichen echtes Puffer- an Puffer-Fahren (Pufferabstand 0-1 mm), während zweitere, um Kompatibilität mit Bügelkupplungen zu bewahren, einen Pufferabstand von 2-4 mm einstellen. Bei ausschließlicher Verwendung der kompatiblen Kupplungen ist aber der Wagenabstand auch optisch einwandfrei, sodaß im Zweifelsfalle am ehesten zu dieser Kupplungssorte zu raten ist. Allerdings benötigen die Fahrzeuge in diesem Fall eine Kurzkupplungskinematik oder eine bewegliche Kupplungsaufnahme. Starre Aufnahmen sind dazu nicht geeignet. Verläßliche Kuppelbarkeit erfordert Gleisbögen von 2m oder darüber, ansonsten muß händisch ein wenig nachgeholfen werden.

== ROCO-Kurzkupplung alt/neu ==

Der Klassiker unter den Kurzkupplungen. Die alte Variante (ohne Vorentkupplung, schwarz) wird nicht mehr produziert und wurde durch die neue Version mit Vorentkupplung (dunkelgrau) ersetzt. Vorteile: leicht kuppel- und entkuppelbar, allerdings nicht im Gleisbogen, was uebrigens fuer so gut wie alle Kurzkupplungen gilt. Fahrzeuge lassen sich leicht nach oben aus dem Zugverband herausnehmen. Reagiert sehr empfindlich durch Zugtrennung auf falsche Höhenlage der Kupplungen zueinander. Vorentkuppelbar.

== Fleischmann-Profi-Kupplung ==

Eher zierlicher Kopf, Nachteil: recht schwergängig beim Kuppeln/Entkuppeln. Vorentkuppelbar.

= Universalkupplungen =

== ROCO-Universalkupplung ==

Neuentwicklung, um langfristig Bügelkupplungen abzulösen. Nachteil: Bei unpassender Höhenlage der Kupplungen zueinander schlechte Entkuppel-/Kuppelbarkeit. Gefahr der Zugtrennung im Bogen bei Kupplung mit Loks ohne Bügel am Kupplungshaken. Ansonsten IMHO die brauchbarste Kupplung am Markt. Vorentkuppelbar.

Nach der Pleite von Roco und Übernahme durch die "Modelleisenbahn GmbH" wurde die Universalkupplung vermutlich aus patentrechtlichen Gründen eine zeitlang nicht mehr hergestellt. Seit Anfang 2007 ist sie, außer in Italien, wieder verfügbar.

== Märklin-Kurzkupplung ==

Im Mischbetrieb mit anderen Bügelkupplungen etwas schwerer kuppel-/enkuppelbar als ROCO-Universal. Bügel verhakt im Bogen gerne am Puffer. Vorentkuppelbar. (?)

= Justierung der Kupplungsabstimmung =

Vor allem bei Wagen aus der Anfangszeit des NEM-Schachtes sind nicht optimal auf die Dimensionen des Schaftes mit Schwalbenschwanz angepaßt, was oft dazu führt, daß die Kupplung schief/nicht stramm im Schacht sitzt, wodurch der Kuppelvorgang unzuverlässig wird.

Abhilfe kann durch Anpassen mit kleinen aufgeklebten Polystyrol- oder Blechstückchen geschaffen werden, die mit Sekundenkleber o. ä. an der Kupplung befestigt werden. Oft reicht auch ein wenig Selbstklebeband oder das Einlegen eines Blech- oder Plastikstückchens.

[[Bild:Kuppeltuning.gif]]

Auf dieselbe Art und Weise kann auch die Kinematik-Deichsel geringfügig verkürzt werden, falls einem der Pufferabstand nicht passen sollte.

Wichtig ist es auch, die seitliche Beweglichkeit der Kurzkupplungsdeichsel zu gewährleisten, da sonst im Extremfall ein Wagen mit festsitzender Deichsel bei Bogenfahrten hinausgedrückt werden kann.

= Fernbedienbare Kupplungen =

== TELEX-Kupplung ==

Fernbedienbare Entkupplung von Märklin. Infos dazu beispielsweise unter [http://home.arcor.de/dr.koenig/digital/digital.htm Dr. Königs Digitalseiten].

== Roco-Digitalkupplung ==

Seit 1999 am Markt, wird nur komplett mit Lok und dafür ausgelegten Dekoder verkauft (z.Z. DB BR 365 (V60), Ep V, DB BR 332 (Köf III), Ep. IV). Roco begründet diese Restriktion damit, dass die verwendete Magnetspule nicht für Dauerstrom ausgelegt sei und daher einen Dekoder mit "Impulsbetrieb" erfordere. Der Maximalstrom wird nur für die anfängliche Bewegung der Spule benötigt, anschliessend wird die Kupplung mit reduziertem Strom offen gehalten. Ein Einsatz in anderen Loks wird daher vorerst experimentierfreudigen Bastlern offenbleiben, die eines der o.g. Modelle samt Dekoder ausschlachten wollen. Noch ist nicht geklärt (?), ob ein M*-Motorola-Dekodertyp einen geeigneten Ansteuermodus besitzt. Für NMRA-DCC besitzt der ZIMO MX61 Model2000 eine Ansteuerung für die ROCO-Digitalkupplung.

== Krois-Digitalkupplung ==

Die Krois-Digitalkupplung ähnelt von der Funktion her der Roco-Kupplung, ist aber einzeln erhältlich. Auch sie darf nicht mit Dauerstrom betrieben werden, es muss also ein geeigneter Dekoder verwendet werden. Aktuelle Dekoder von Zimo, Tran und AMW bieten beispielsweise einen Modus, in dem die Lok sich selbst vom Zug abkuppelt. Auch die Decoder von Kühn steuern die Krois-Kupplung korrekt an. Damit wird Dauerbetrieb zuverlässig vermieden. Für andere Decoderfabrikate wird von Herrn Krois ein Zeitsteuerbaustein angeboten, der die Digitalkupplung nach etwa vier Sekunden wieder ausschaltet und damit das Durchbrennen der Spule verhindert.

= Handentkuppler =

== Entkuppler für Bügelkupplungen ==

Als verblüffend effektiver Handentkuppler für Bügelkupplungen hat sich eine gewöhnliche Nadelfeile herauskristallisiert. Der Feinhieb der Feile bietet einen hervorragenden "Grip" an den Kupplungsbügeln, die problemlos und ohne seitlich zu verrutschen hochgehoben werden können. Der Schraubenziehergriff mit Stahldraht ist schon fast zu kompliziert, um die Nadelfeile verdrängen zu können. Die Platte von unten (siehe Entkuppler für Kurzkupplungen) ist nicht so effizient, da insbesondere die Haltefeder der ROCO-Bügelkupplungen Widerstand entgegensetzt; manchmal sind die Bügel ineinander verhakt. Die Feile schafft auch hier schnell Ordnung.

== Entkuppler für Kurz- und Universalkupplungen ==

Hier liegt die Sache anders, da diese Kupplungen sich am besten von unten entkuppeln lassen. Bei der ROCO-Universalkupplung ist dies sogar die einzige Möglichkeit. Einerseits kommt hier der ROCO-Handentkuppler in Frage, der jeder Grosspackung ROCO-Kupplungen beiliegt. Ich persönlich benutze ihn nicht, da die Platte an der Unterseite ziemlich klobig ist. Ausserdem reicht die Platte nicht weit genug in die Gleismitte hinein, was manchmal ein ziemliches Geduldsspiel beim Entkuppeln erfordert. Darum kommen selbstgebaute Entkupplerhaken zum Einsatz, mein persönlicher Favorit ist ein zurechtgebogener Kunsstoffstreifen. Dazu wird ein Streifen Astralon (schlagzäher Kunststoff aus dem Modellbau) von ca. 7-12 cm Länge und 7-8 mm Breite zugeschnitten, Dicke 1,5 mm. Ein Ende wird mit Heissluft erwärmt und ein ca. 2 cm langes Stück rechtwinkelig abgebogen. Dieser Entkuppler liegt gut in der Hand und lässt sich leicht in Position bringen. Eine andere Variante besteht aus einem 10 cm langen Rundholz (8 mm Durchmesser) und einem angeklebten, 2-3 cm langen Kunsstoffstreifen mit einer Breite von 8 mm.

[[Bild:Entkuppler-1.jpg]]

== Ein weiterer Handentkuppler von Peter Popp ==

Roco- Universalkupplungen sind nicht umsonst sehr beliebt: sie kuppeln zwar nicht so kurz wie "richtige" Kurzkupplungen, sind aber gerade daher sehr zuverlässig. Schwierig wird es jedoch, wenn man versucht, gekuppelte UK's zu trennen: während es die traditionellen Bügelkupplungen nicht übelnehmen, wenn man einen Wagen mit der Hand aufhebt und etwas verdreht, um die Kupplung zu trennen, ist das bei der UK nicht möglich. Aus diesem Grunde liegt der Familienpackung der Roco-UK ein Handentkuppler bei, der allerdings nicht optimal zu handhaben ist.

Nach einigen Versuchen habe ich nun einen Entkuppler gefunden, der recht gut funktioniert: Das Ende eines Stahldrahts wird mehrfach abgewinkelt und ein Stück eines Nylon-Kabelbinders aufgeklebt.

[[Bild:Entkuppler-2.jpg]]

Vor dem linken Wagen sehen Sie den Entkuppler: auf dem Abschnitt des Kabelbinders sind schwach die Rippen zu erkennen, die das Abrutschen der Nasen der Kupplung verhindern. Ein Trick dabei: der Stahldraht wurde so gebogen, dass er genau unter der Kupplung liegt, wenn der Draht zwischen den Puffern nach oben läuft. Eine einfache, aber wichtige "Zieleinrichtung".

[[Bild:Entkuppler-3.gif]]

Auf obiger Skizze ist dargestellt, wie der Draht zu biegen ist. Einziges Problem ist die Verklebung von Drahtbügel und Nylon-Streifen (besonders Nylon ist schlecht zu verkleben). Ich habe Heißkleber verwendet, alternativ wäre es auch möglich, den Draht zu erhitzen und in den Nylonstreifen einzudrücken - Vorsicht, damit sich das Nylon nicht ganz auflöst!

= Noch geplante Themen =

*Einbau von Normschächten

*Stomführende Kupplungen

*Kupplungs-Knowhow

[[Kategorie:Fahrzeuge]]

Gleiswendel

2008-11-11T13:30:51Z

Michael Oppenauer: Vorlage Glossar verwendet

{{Glossar}} Unter einer Gleiswendel versteht man eine schraubenförmige Gleisfigur. Mit ihnen lässt sich kompakt an Höhe gewinnen, um z. B. von der sichtbaren Ebene in einen unter der Anlage angeordneten [[Schattenbahnhof]] zu kommen. Dieser Artikel beschreibt, wie man eine Gleiswendel aufbauen kann.

__TOC__

= Eine Gleiswendel für "Bad Knüsselsdorf" =

Bei meiner ehemaligen Anlage "Bad Knüsselsdorf" mußte ein Höhenunterschied von 30cm zwischen Bahnhof und [[Schattenbahnhof]] überwunden werden. Dazu kam nur eine Wendel in Frage, deren Konstruktion ich im folgenden beschreiben möchte.

= Abmessungen =

Der Platz für die Wendel war vorgegeben, mehr als ein Radius von 50cm war nicht unterzubringen. Obwohl ich sonst Flexgleise einsetze, wählte ich hier fertig vorgebogenes Gleis und entschied mich für den ROCO-LINE R4 (48,1cm). Die lichte Höhe zwischen zwei Gängen der Wendel sollte inklusive Gleis ca. 7cm betragen. Bei einer Trassendicke von 1,6cm ergab sich damit eine Höhendifferenz von gut 9cm pro Umlauf, insgesamt also eine Steigung von ungefähr 3%. Die Trassenbretter waren 10cm breit, damit rechts und links neben dem Gleis genügend Platz für die Gewindestangen blieb.

Ein paar Hinweise für die Ermittlung der Abmessungen beim Nachbau:

7cm lichte Höhe reichen bei der Verwendung von Kunststoffgleis sogar für Oberleitungsbetrieb. Natürlich können keine Masten gesetzt werden, aber ein Gleisprofil unter der Trassenunterseite sollte für den sicheren Betrieb genügen. Andererseits sollten 7cm tunlichst nicht unterschritten werden. Es lassen sich zwar beim Dampf- und Dieselbetrieb noch 10-15mm "herauskitzeln", aber dann wird es sehr eng, falls man eines Tages entgleiste Fahrzeuge wieder auf die Schienen setzen möchte. Bei der Dicke der Trassenbretter sind vielleicht noch 5mm drin.

Hier ein paar Beispiele für die resultierenden Steigungen bei unterschiedlichen Abmessungen, die Radien entsprechen dabei dem ROCO-LINE Programm.

{| border="1"
! Lichte Höhe
! Trassendicke
! R2=35,8cm
! R3=42,0cm
! R4=48,1cm
! R5=54,3cm
! R6=60,4cm
|-
|7cm
| 1,6cm
| 3,8%
| 3,3%
| 2,8%
| 2,5%
| 2,3%
|-
|6cm
| 1,6cm
| 3,4%
| 2,9%
| 2,5%
| 2,2%
| 2,0%
|-
|6cm
| 1,0cm
| 3,1%
| 2,7%
| 2,3%
| 2,1%
| 1,8%
|}

Man sollte stets versuchen, die Steigung so gering wie möglich zu halten, also einen möglichst großen Radius zu wählen. Die Steigung sollte 3 % nicht überschreiten, um einen sicheren Betrieb zu gewährleisten. Bei einer 2gleisigen Wendel sollte das nach oben führende Gleis nach Möglichkeit außen liegen (größerer Radius, geringere Steigung).

= Ein solides Fundament =

[[Bild:Gleiswendel helix4.gif|thumb|292px|Die Befestigung mit Gewindestangen geschieht alle 45°.]]
Eine große Platte aus 1,6cm Tischlerplatte diente als Grundplatte für die Gleiswendel. Ich zeichnete die Innen- und Außenkante der Trassenbretter mit einem Schnurzirkel an und legte probehalber einen Schienenkreis aus. Der Kreis wurde in 45 Grad-Segmente unterteilt (und weil ich dann Hunger auf Pizza bekam, machte ich erstmal eine Pause)

Danach wurden die Kanten entlang der Markierungen mit einer Stichsäge ausgesägt. Eine Kante blieb gerade, dort wurde die Wendel später an der Zimmerwand befestigt .

Entlang der 45-Grad Markierungen bohrte ich dann 6mm Paß-Löcher für die Gewindestangen, jeweils 1,5cm von der Außen- bzw. Innenkante entfernt. HINWEIS: An dieser Stelle sollte man die Gewindestangen nach dem ersten Paar Löcher probehalber einfügen und mit dem längsten verfügbaren Fahrzeug Testfahrten durchführen. Ich benutzte dazu einen 26,4m Personenwagen im Längenmaßstab 1/87.

 
= Das Trassenbrett =

[[Bild:Gleiswendel helix2.jpg|framed|Die Preßspanbretter und Sperrholzbretter überlappen an den Stoßstellen, damit keine Knicke entstehen.]]
Das Trassenbrett entstand aus zwei 8mm dicken Holzstreifen. Auf der Unterseite nahm ich Preßspann, nach oben zum Gleis hingegen Sperrholz, da dort die Gleise festgeschraubt werden sollten. Mit Hilfe der fertig geschnittenen Grundplatte machte ich eine Pappschablone und sägte einige Stücke aus den Holzplatten aus. Schließlich baute ich daraus ¾-Kreise zusammen und achtete darauf, daß die Fugen immer versetzt blieben, ähnlich einem Ziegelmauerwerk. Damit vermeidete ich Knicke zwischen den Übergängen. Bei jedem der Teilkreise achtete ich darauf, daß am "unteren" Ende die obere Holzlage hervorschaute und am "oberen" Ende die untere Lage überstand. Beim späteren Zusammenbau (von unten nach oben) überlappt der neue Abschnitt den vorherigen. Schließlich wurden die Teile später immer von oben eingesetzt!. Wenn ein Teilkreis fertig war, befestigte ich das erste Stück des nächsten Abschnittes mit Schraubzwingen daran, um den richtigen Versatz zu bekommen. Genauigkeit ist nicht so wichtig (das ist wiederum wichtig für mich), kleine Lücken von 1-2mm zwischen benachbarten Abschnitten sind nicht problematisch. Nachdem alles fertig war, klemmte ich alles mit Schraubzwingen auf die Grundplatte und bohrte 6mm Löcher durch das ganze Paket, dabei benutzte ich die Löcher in der Grundplatte als Führung. Danach nahm ich wieder alles auseinander und bohrte die Löcher in den Trassenbretter (nicht die in der Grundplatte!) auf 8mm auf, um später genug Spiel für die Feinjustage zu haben. HINWEIS: Vor dem Bohren sollten die Teilstücke sorgfältig ausgerichtet werden!

 
= Aufwärts bitte! =

[[Bild:Gleiswendel helix3.gif|thumb|365px|Die Trassenbretter werden mit Muttern in der Höhe exakt ausgerichtet und befestigt.]]

Ich befestigte die M6-Gewindestangen mit Unterlegscheiben und M6-Muttern an der Grundplatte. Dann fügte ich das erste Teilstück hinzu (dabei sollte man nicht vergessen, zuvor die nötige Anzahl Muttern und Scheiben einzulegen!) und schraubte die Gleise auf die Trasse. Das nächste Trassenbrett nebst nötigen Kleineisen wurde eingesetzt und am vorherigen festgeklebt. SEHR WICHTIG: Das Gleis wurde sorgfältig verlegt und Gleisstöße genau an den Segmentenden vermieden, ggfs. unter Einsatz von ½ Gleisstücken. Nachdem alles montiert war, befestigte ich die Wendel am Anlagenunterbau. Dann war die Feinjustage an der Reihe. Mit Hilfe der Muttern war es einfach, die richtigen Höhen von unten nach oben einzustellen. Ich nutzte die Grundplatte als Referenz, notierte mir die richtigen Höhenmasse und stellte sie mit einem Lineal und Schraubenschlüssel ein. Neben dem sauber verlegtem Gleis ist auch eine gleichmäßige Steigung sehr wichtig für die Betriebssicherheit. Daher kontrollierte ich mehrmals, ob alle Abstände nun wirklich richtig waren..

Vorsichtige Modellbahner können die Muttern jeweils noch mit einer Kontermutter versehen.

 
= Der Abschluß =

[[Bild:Gleiswendel helix1.jpg|framed|Die Gleiswendel wird mit einem abnehmbaren Landschaftsteil überbaut.]]

Bei der Gleisverlegung muß (wie in allen verdeckten Abschnitten) mit besonderer Sorgfalt gearbeitet werden. Vor dem Weiterbau der Anlage müssen umfangreiche Testfahrten stattfinden. Nach dem Überbau mit Landschaft ist die Gleiswendel nur schwerer zu erreichen, um Fehler zu beheben.

Natürlich blieb ein großes Loch in der Mitte der Wendel. Aus den Überresten der Grundplatte baute ich eine abnehmbare Abdeckplatte. Als Ummantelung plante ich Hartfaserplatten, welche sich genügend biegen lassen. Bevor ich jedoch dazu kam, wurde "Bad Knüsselsdorf" wegen Umzug abgebaut. Mittlerweile deutet es sich ab, daß auch "Bad Knüsselsdorf II" mit einer Wendel ausgestattet werden wird. Die alte Gleiswendel läßt sich in Grenzen anpassen: Zusätzliche "Umdrehungen" lassen sich durch Verlängerungen der Gewindestangen ansetzen. Geringe Abweichungen in den Höhenlagen können durch die Muttern eingestellt werden. Das alte Bauteil wird also wahrscheinlich weiter verwendet werden ...

 
----

Der ursprüngliche Autor Frank Forsten pflegt seine Version auf seiner Homepage http://www.forsten-online.de

[[Kategorie:Anlagenbau]]

Lissy

2008-11-11T13:08:05Z

Michael Oppenauer: Vorlage Glossar verwendet

{{Glossar}} Lissy steht für „Lok individuelles Steuerungs-System“

Lissy ist ein multifunktionales Steuerungssystem. Mittels Infrarot-Datenübertragung werden Lokadresse und Zugkategorie von einem Sender unter der Lok bzw. Wagen an einen Sensor im Gleis übertragen. Die Sensoren sind mit einem Empfänger verbunden, der programmierbare Fahr- oder Schaltbefehle, oder auch Belegtzustände über das [[LocoNet|LocoNet]] an die Zentrale und weitere LocoNet Teilnehmer überträgt. In Verbindung mit LocoNet Zentralen, wie etwa die [[Digitalzentralen|Intellibox]] oder das [[Digitalzentralen|Twin Center]], können komplexe Funktionen gesteuert werden. Dazu zählt die automatische Steuerung eines [[Schattenbahnhof|Schattenbahnhofs]], oder die [[Blockstreckensteuerung|Blocksteuerung]] einer durch [[Blockstreckensteuerung|Blöcke]] gesicherte Fahrstrecke. Auch ein Pendelverkehr mit wechselnden Zügen, kann halbautomatisch oder auch vollautomatisch gesteuert werden. Einfache Funktionen, wie etwa ein einzelner [[Pendelzug|Pendelzug]] ist auch schon mit dem [[Digitalzentralen|LokBoss]] von Fleischmann möglich.

Lissy wurde in Zusammenarbeit von [[Hersteller|Fleischmann]] und [[Links_Hersteller_Zubehör|Uhlenbrock]] entwickelt.

Uhlenbrock führt das System unter dem Namen Lissy.

Fleischmann führt das System unter dem Namen Train-Navigation

Weitergehende Informationen sind im Handbuch von Uhlenbrock zu finden.
http://www.uhlenbrock.de/3/9/0/I280CEBF-045.apd/Bes68000-02.pdf

[[Kategorie:Digitalbetrieb]]

POM

2008-11-11T13:05:05Z

Michael Oppenauer: Vorlage Glossar verwendet

{{Glossar}} Programming On Main.

Das Einstellen der Konfigurationsvariablen (CV) während des Betriebs auf dem Hauptgleis. Die Werte der Variblen können i.d.R. nicht gelesen, sondern nur eingestellt werden.

Im Englischen findet man dafür häufiger den Begriff »Operations Mode Programming« als Gegensatz zum »Service Mode Programming«.

MM2

2008-11-11T13:00:23Z

Michael Oppenauer: Redirekt auf MM

#REDIRECT [[MM]]

DCC-friendly

2008-11-11T12:55:03Z

Michael Oppenauer: /* DCC-friendly */ Optik

[[Kategorie:Gleise]]
[[Kategorie:Glossar]]

Dieser genaugenommen fehlbesetzte Begriff bezeichnet den Umbau einer Weiche, bei der das polarisierte Herzstück vollständig von den Zungen getrennt wird.
In vielen Fällen soll herstellerseitig das Herzstück über die Zungen mit Spannung versorgt werden, was verschiedene Nachteile hat.
<ul>
<li>der Kontakt ist schmutzanfällig</li>
<li>der Anpreßdruck der Zungen muß sehr hoch sein, um einigermaßen Kontakt zu haben, das erfordert unverhältnismäßig starke Weichenstelleinrichtungen</li>
<li>bei ungünstiger Konstellation können Radsätze Kurzschlüsse zwischen Herzstück und abliegender Zunge verursachen</li>
</ul>

[[Bild:DCC_Weiche_abzweigend.png|framed|left|Die gestrichelten Linien stellen die beweglichen Zungen dar, über die der Herzstückbereich mit Strom versorgt wird.]]

 

Abhilfe schafft ein schmerzloser Schnitt durch die Zungen kurz vor dem Herzstück. Die Zungen werden fest mit den Backenschienen verdrahtet, das Herzstück wird über einen Schalter versorgt, der mit dem Weichenatrieb verbunden ist.

[[Bild:DCC_Weiche_Umbau_abzweig.png|framed|left|Der grün dargestellte Bereich wird je nach Weichenlage mit der rechten oder linken Außenschiene verbunden. Der Umschalter befindet sich am [[Weichenantriebe|Weichenantrieb]].]]

 

Beispiele für einen solchen Umbau:
* [[Digitalumbau Tillig Elite Weichen|Tillig H0 Elite Weiche]]
* [http://cygbert.franken.de/anlage/weichenumbau/ Peco N Code 55 Weiche]
* [http://www.tt-digital.de.vu/tt-bahn/digi_tipps/weiche/index.html Schaltung mit 2 Wechselkontakten], bei der die Weichenzungen in Abhängigkeit der Weichenlage stromlos geschaltet werden.

Märklin H0 : Das Märklin-System

2008-11-04T16:29:13Z

Michael Oppenauer: /* Kunststoff-Gleise */ Link gesetzt

=Das Märklin-System=

==Das Märklin-Gleissystem==

===Allgemeines zum Gleissystem===

====Welche Gleise kann ich benutzen?====

Nicht alle Modelle, die von anderen Firmen für das Märklinsystem produziert wurden, einschließlich umgerüsteter Modelle, können ohne Probleme auf Märklingleisen betrieben werden. Innerhalb der Produktpalette von Märklin sind mit wenigen Ausnahmen (siehe unten) alle Gleise für alle Modelle geeignet

====Welche Radien gibt es?====

Im Metallgleissortiment (seit 2001 nicht mehr im Programm"!) gab es 5 Radien: Industriekreis/R0 (R = 286 mm) mit 5120 Normalkreis/R1 (R = 360 mm) mit 5100 Parallelkreis/R2 (R = 437,4 mm) mit 5200 Großkreis I/R3 (R = 535 mm) mit 3800, (nur von 1953 bis 1957 im Programm!) Großkreis II/R4 (R = 585 mm) mit 3900, (nur von 1953 bis 1957 im Programm!) Nähere Informationen finden sich im Unterabschnitt [[#Metall-Gleise | Metall-Gleise]]

Das Kunststoffgleissortiment hat ebenfalls 5 Radien (die K-Gleise der 21xx-Serie sind nicht mehr im Programm!) Industriekreis/R0 (R = 295 mm) mit 2110 oder 2210 Normalkreis/R1 (R = 360 mm) mit 2121 oder 2221 Parallelkreis/R2 (R = 424,6 mm) mit 2131 oder 2231 Großkreis I/R3,5 (R = 553,9 mm) mit 2141 oder 2241 Großkreis II/R4,5 (R = 618,5 mm) mit 2151 oder 2251 beliebige Radien (erst ab 360mm Radius empfehlenswert) können mit dem Flexgleis 2205 individuell zugeschnitten werden. Nähere Informationen finden sich im Unterabschnitt [[Märklin_H0_:_Das_Märklin-System#Kunststoff-Gleise | Kunststoff-Gleise]]

Das C-Gleissortiment hat zur Zeit folgende Radien (ACHTUNG: C-Gleise haben kein Industrieradius mehr!) Normalkreis/R1 (R = 360 mm) mit 24130 Parallelkreis/R2 (R = 437,5 mm) mit 24620 Großkreis I//R3 (R= 515mm) mit 24330 Großkreis II/R4 (R=579,3mm) mit 24430 Großkreis III/R5 (R=643,6mm) mit 24530 Riesenkreis III/R9 (R=1114,6mm) mit 24912 (ACHTUNG: bislang nur in Form von Weichen und Gegenbögen vorhanden!) Nähere Informationen finden sich im Unterabschnitt [[Märklin_H0_:_Das_Märklin-System#C-Gleise| C-Gleise]]

Zwischenradien können bei allen Gleistypen aus einem kleineren Radius mit kleinen, geraden Gleisstücken erzeugt werden.

====Welche Gleise kann ich im DC-Betrieb benutzen?====

Für den 2-Leiter-DC-Betrieb und den 3-Leiter-Betrieb '''nicht''' geeignet sind die M-Gleise der 3600, 5100 und 5200-Reihe. Weichen der Kunststoffgleise haben verbundene Außenleiter (22xx-Serien), sodaß hier Umbaumaßnahmen zum (Außenleiter-)DC-Betrieb notwendig sind. Alle anderen Gleise von Märklin sind DC-tauglich.

====Welche Fahrzeuge kann ich auf den Gleisen betreiben?====

Bei historischen Modellen, die mit "Pilzschleifern" (diese Schleifer sehen von der Seite aus wie umgedrehte Pilze) ausgestattet sind, sind zum Betrieb mit Punktkontaktgleisen nicht zu empfehlen. Gleiches gilt teilweise auch für "Löffelschleifer". Für den Betrieb auf den heutigen Märklingleisen sind die "Skischleifer" betriebssicher. Fremdfabrikate mit diesen Schleifertypen (z.B. Trix-Express) sind ebenfalls NICHT betriebssicher. Diese Schleifertypen können sich bei Weichen in den Herzstücken verhaken und die Lok bzw. den Zug zum Entgleisen bringen. Mit den ehemaligen Mittelschienengleisen können alle Schleifertypen betrieben werden.

====Welche Radien können befahren werden?====

* Der derzeitige Standardradius beträgt 360mm. Alle Märklinfahrzeuge können diesen Radius ohne Probleme im Normalfall befahren.
* Angesetzte Details (Kolbenstangenschutzrohre, Schürzen, etc.) vergrößern den Mindestradius (siehe auch die Bedienungsanleitung zum Modell)

** Nicht betriebssicher sind:
*** 2-achsige Personen- und Güterwagen mit einem Achsstand >10cm auf R0
*** 4-achsige Personenwagen mit einem Drehgestellabstand >20cm auf R0
*** Wagenverbände mit Kurzkupplung im Schiebebetrieb in Radien <= R1
*** neuere Schnellzugdampfloks ab Baujahr 1973, und alle Varianten der BR 41 auf R0
*** Güterzugdampfloks neuerer Produktion ohne Knickrahmen auf R0
*** Schienenzeppeline aller Varianten auf R0 und in Gegen (d.h. S-)Kurven
*** 1:100 und 1:87-Modelle von anderen Herstellern in R0
*** 1:100 und 1:87 bei M-Gleisweichen mit großen (d.h. quadratischen) Laternenköpfen
** Problematisch sind außerdem:
*** Alle Varianten der BR 41 können auf Weichen des Normalkreises, vor allem beim M-Gleis, entgleisen.
*** Alle Varianten der BR 18.1 mit kurzem Tender neigen bei großen Zuglasten zum Entgleisen bei Radien < R5.
*** 1:100-Schnellzugwagenmodelle von Märklin in R0 (bedingt)
*** Schienenzeppelin 3077 bei hoher Geschwindigkeit in Radien <R2
** Empfehlungen:
*** wirklich nur kurze Industriegleise für kleine, zweiachsige Wagen und kurze Loks mit max. 3 Achsen verlegen.
*** S-Kurven vermeiden.
*** keine Hauptstrecken mit Industrieradius versehen.
*** besondere Vorsicht mit Modellen bei hoher Geschwindigkeit

====Welche Steigungen können befahren werden?====

Generell für Steigungen gilt, daß '''vor allem''' der Übergang zwischen Ebene und Steigung nicht zu abrupt geschehen darf (längere Fahrzeuge bleiben sonst im Knick hängen). Der maximale, störungsfrei zu bewältigende Übergang aus der Ebene für alle bisher produzierte Märklinmodelle in H0 ist von 0 auf 1:20 (von 0 auf 5%). Sind Wagenmodelle mit 30,3cm (1:87 Schnellzugwagen) vorhanden, so sollte der maximale Übergang von 0 auf 1:50 (2%) nicht überschreiten. 

* Bei Clubanlagen und ausreichend Platz sollte die allgemeine Empfehlung von 3% nicht überschritten werden
* Alle Märklin-H0-Modelle können 5% problemlos bewältigen, lediglich Modelle mit Märklin-Faulhabermotor werden deutlich langsamer
* Falls der Platz nicht ausreicht, können bis 15% Steigung bewältigt werden. Ab 10% haben einige Modelle Probleme die Steigung in Solofahrt zu bewältigen
* In Spezialfällen sind Steigungen bis 20% und mehr möglich. '''Derartige Steigungen sollten wirklich nur die Ausnahme bleiben.'''

Wenn man große Steigungen schon einrichtet, dann sollte die Rampe auch gut gegen ein Durchhängen gesichert sein, sonst sind die Modelle durch noch größere Steigungen überlastet. 

'''Folgende Auflistungen basieren auf Erfahrungswerten von Modellbahnern. Sie erheben keinen Anspruch auf generelle Anwendbarkeit!''' Viele betriebliche Probleme können durch Pflege des Rollmaterials behoben bzw. durch intensive Schieneninstandhaltung '''(ÖL!)''' vermieden bzw. beseitigt werden.

Modelle, die 10% Steigung in Solofahrt unter Umständen nicht bewältigen können sind:

* 3015/CCS800/30159/36159 (schweizer Krokodil Ce 6/8 II mit SLFCM)
* 33591 (schweizer Doppellokomotive Typ Ae 8/14 mit DELTA und DCM2)

Betriebsprobleme bei Zugfahrten mit mehr als 5 Wagen vom Typ C4i Wü 01 (Nr. 4211) ab 3% Steigung können mit Modellen, die den Faulhabermotor 1717 oder den Sinus-Motor haben auftreten. Falls der Zug an Hp0 stehen soll, rollt der Zug ggf. rückwärts den Hang hinunter. Dies gilt für alle Betriebsarten (analog/digital). Davon betroffen sind bislang:

* (3311, 3411, 3511, 3513, 3514, 3611, 3613, 3614, 3711, 34112, 34113, 37112, 37113 als Varianten der BR 18.1, 34059,37059 als Varianten der BR 59)
* alle Modelle mit der Katalognummer 39xxx, die einen Sinus-Motor enthalten können bei Zughalt in Steigungen bergab rollen

Dieses Problem läßt sich durch geeigneten Anlagenaufbau vermeiden (keine Halteabschnitte in Steigungen). Bei noch höheren Zuglasten (8 Wagen) kann es ab 5% zum Stillstand auf der Steigung kommen.

===Compound-Gleise===

====Alpha-Gleise====

Im Jahre 1988 wurde das bisherige Gleis-System aus K- bzw. M-Gleisen durch das "Alpha-Gleis" mit der Bezeichnung "Gleis 2000" erweitert. Diese Gleise waren eine Kombination Kunststoff-Böschungskörper und Metall-Gleisen und stellten mit ihrem neuen Stecksystem die Vorläufer der C-Gleise dar. Diese Gleise waren nur von 1988 bis 1996 im Programm. Die angebotenen Gleisstücke orientierten sich in ihrem Raster am M-Gleis (180mm, R1, R2):

* 2001 Gerade 1/1 (180mm)
* 2006 6 gerade Gleise 2001 1/1 mit Verpackung als Brücke
* 2019 Prellbock (70mm)
* 2021 Gebogenes Gleis 1/1 R1 (r=360mm, 30°)
* 2026 6 gebogene Gleise 2021 1/1 mit Verpackung als Brücke
* 2031 Gebogenes Gleis 1/1 R2 (r=456,4mm, 30°)
* 2062 Weiche R1 links (180mm/30°)
* 2063 Weiche R1 rechts (180mm/30°)
* 2090 Anschluß gerade 1/1 (180mm)
* 2091 Übergangsgleis Alpha-M-Gleis, gerade 1/1 (180mm)

 Dieses Gleissystem wurde ohne Ausgleichsgleise angeboten.

====C-Gleise====

'''Vorbemerkungen'''

Umfangreiche Informationen zum C-Gleis erhält man zunächst auf den Produktseiten der Firma Märklin. Folgende Hinweise mögen als praxisbezogene und kostensparende Ergänzung dienen. [[Image:märklin-c-gleis.jpg | framed|left]] '''Gleisanschlüsse''' Für den Anschluß der C-Gleise gibt es die Anschlußgarnitur 74040 mit Flachsteckhülsen zum Anstecken an das Gleis. Die Anschlüsse lassen sich auch sehr leicht löten (roter Pfeil).

'''Mittelleiter-Trennstellen''' Für die Trennung des Mittelleiters der C-Gleise gibt es die Mittelleiter-Isolierung 74030. Diese, in Form kleiner, roter Hütchen produzierten Isolationen werden über die inneren Kontaktlaschen geschoben und unterbrechen damit die Verbindung. Pro Packung (74030) sind acht Hütchen für vier Trennstellen enthalten. Flexibler läßt sich der Mittelleiter an der Unterseite des Gleises (zwischen den Pukos!) mit der Minitrennscheibe unterbrechen (grüner Pfeil). Diese Trennung läßt sich später gegebenenfalls durch eine Kabelbrücke zwischen den beiden B-Anschlüssen des Gleises wieder schließen.

'''Kontaktstrecken''' Das Prinzip des Kontaktgleises auf zwei elektrisch getrennten Gleisen, wobei nur eine Seite an Masse angeschlossen ist. Das andere Gleis wird dann durch die Radsätze mit Masse verbunden. Beim C-Gleis haben die beiden Gleise jeweils ihre eigenen Kontakte und sind nur an beiden Enden durch eine Brücke miteinander verbunden.Durchtrennt man diese beiden Brücken (gelbe Pfeile), so hat man bereits ein Kontaktgleis. Diese Trennung läßt sich später gegebenenfalls durch eine Kabelbrücke zwischen den beiden 0-Anschlüssen des Gleises wieder schließen. Am Anfang und Ende der Kontaktstrecke muß nun allerdings noch jeweils eine Gleistrennung erfolgen. Bequemste (leider auch teuerste und unflexibelste) Lösung ist der Kontaktgleis-Satz 24995. Die einfachste Lösung - aber später nicht mehr rückgängig zu machen - wäre auch hier wieder die Trennscheibe. Da die Gleise aber konstruktionsbedingt keine Schienenverbinder besitzen, reicht eines der oben erwähnten Isolierungs-Hütchen auf der äußeren Kontaktzunge zur Trennung der Gleise (solange diese sich nicht durch unebenen Untergrund oder Fertigungstoleranzen berühren sollten - ist bei mir ''(B.N. Anm. des Autors)'' bisher aber nicht vorgekommen).

'''Anwendungsbeispiel''' Ein Anlagenbau nach diesen Regeln wird unter [http://www.noethlich.net/modellbahn http://www.noethlich.net/modellbahn] dokumentiert.

===Kunststoff-Gleise===

'''K-Gleise''' bestehen - genau wie die C-Gleise - aus zwei gegeneinander isolierten Aussenschienen sowie einem verdeckt in den Schwellen angeordnetem Mittelleiter. Es gibt zwei grundsätzlich unterschiedliche Gleistypen:

[[Image:märklin-k-gleis.jpg|framed|left]]

* Serie 21xx von 1969 - 1980 gefertigt, mit Hohlprofilschienen (gefalzten Schienen) und breiten Kontaktlaschen (im Bild links)
* Serie 22xx seit 1980 gefertigt mit Vollprofilschienen (massiv, vorbildgetreuer) und engen Kontaktlaschen. (Bild rechts)

Die K-Gleise sind systembedingt empfindlicher als C- und M-Gleise und eignen sich damit nur bedingt für den Aufbau fliegender Anlagen. Allerdings hat ein Tritt auf ein solches Gleisstück nicht die verheerenden Folgen wie das z. B. bei M-Gleisen der Fall ist. Kritisch ist vor allem das Zusammenstecken der Gleise, insbesondere im Bereich von Weichenstraßen. Nur allzu schnell bricht das außenliegende Stück der Schwelle ab und muß dann durch entsprechende Landschaftsgestaltung kaschiert werden, sofern das Bruchstück nicht wieder anzukleben ist. Beim Übergang von 21xx auf 22xx Gleise müssen die engeren, weil höher ausgeführten Schienenverbindungslaschen der 22xx-Gleise mit recht großem Druck zusammgefügt werden; dies kann insbesondere bei kurzen Gleisstücken zu Verschiebungen bis hin zum Ausbrechen der Schienen führen. Daher sollte in solchen Bereichen nur 'sortenrein' verlegt werden.

'''Anschlußgleise''' [[Image:märklin-kgleisunten.jpg|framed|right]] Neben dem Standardanschlußgleis 2290 (2292 mit Entstörkondensator) von Märklin besteht die Möglichkeit, jedes beliebige Gleisstück mit einer Anschlußleitung zu versehen. Dazu muß nur auf der Unterseite ein Kabel an das in der Schwellenmitte freiliegende Kupferblech gelötet werden (gelber Pfeil). Vorsichtig und schnell (=heiß) arbeiten, damit der darüberliegende Kunststoff keinen Schaden nimmt. Bei Bedarf kann auch an die Edelstahlprofile der Außenschienen ein Massekabel angelötet werden. Eine weitere Möglichkeit besteht darin, ein leicht V-förmig gebogenes (Feder-) Blech zwischen Schienenprofil und Schwellenunterbau zu schieben. Selbstverständlich ist vorher das Anschlußkabel an dieses Blech zu löten (Ähnlich dem Masseanschluß 7500 von Märklin).

'''Mittelleiter-Trennstellen''' Zur Trennung der Mittelleiter müssen jeweils die beiden kupfernen Kontaktzungen unter den Schienenverbindern gegeneinander isoliert werden. Dazu gibt es von Märklin unter der Nummer 7522 passende Kunststoffeinsätze. Mit etwas Feingefühl läßt sich aber auch eine Isolierung aus Papier, dünner Pappe oder sogar Tesafilm verwirklichen. Dies ist aber nur bei fester Verlegung der Gleise verläßlich. Falls die Gleise 'mit absoluter Sicherheit und nie wieder' ausgebaut werden sollen, ist es auch denkbar, die Kontakzungen einfach abzutrennen. Die Mittelleitertrennungen sollten zur Erleichterung einer späteren Fehlersuche vor Ort gekennzeichnet werden.

'''Kontaktstrecken''' werden z. B. vor Bahnübergängen oder in [[Schattenbahnhof | Schattenbahnhöfen]] benötigt. Kontaktstrecken detektieren alle Fahrzeuge, die sich in ihrem Bereich befinden. Dies geschieht durch Überbrücken der von einander isolierten Außenschienen durch die Achsen der darauf befindlichen Fahrzeuge. Dies kann durch den Kontaktgleissatz 2295 von Märklin oder durch einfaches Auftrennen einer Außenschiene jeweils am Anfang und Ende der zu überwachenden Strecke erfolgen; da die Schienen gegeneinander isoliert sind, kann der Zwischenraum mit normalen Gleisen bestückt werden. Anwendungsbeispiele für Kontaktgleise/Kontaktstrecken finden sich im Artikel [[Gleiskontakte#Kontaktgleise | Gleiskontakte]]

'''Schaltgleise''' werden zur kurzzeitigen Kontaktgabe, z. B. zum Schalten von Signalen und Weichen, eingesetzt. Mit den Märklin-Kontaktgleisen 2229, 2239 und 2299 ist zusätzlich eine richtungsabhängige Kontaktabgabe möglich. Dies geschieht durch einen Schaltnocken, der vom Schleifer der Lok (und natürlich auch entsprechend ausgerüsteter Waggons) in der Fahrtrichtung betätigt wird und für die Dauer dieser Betätigung den entsprechenden Kontakt schließt. Prinzipbedingt darf kein Fahrzeug mit Schleifer auf einem Schaltgleisstück zu stehen kommen (direkt angeschlossene Magnetartikel würden sonst in kurzer Zeit durchbrennen). Im Laufe der Jahre erlahmen die Federbleche, die den Schaltnocken in die Mittelstellung bringen. Im Gegensatz zu den Schaltgleisen der M-Serie lassen sich die K-Gleise kaum noch nachjustieren. Anwendungsbeispiele für Schaltgleise finden sich im Artikel [[Gleiskontakte#Schaltgleise | Gleiskontakte]]

===Metall-Gleise===

'''M-Gleise''' mit Punktkontakten lösten ab 1957 Jahren die Mittelleiterschienen ab und wurden bis zum Jahr 2001 gefertigt und sind "werkseitig nicht mehr verfügbar". Wer also eine Anlage mit M-Gleisen bauen oder erweitern will, ist auf die Restbestände im Handel oder auf Modellbahnbörsen und (Online-)Auktionen angewiesen.

'''Anschlußgleise''' Hier ist die Auswahl etwas vielfältiger als bei den K-Gleisen, es gibt gerade (5111 bzw. 5130/31 mit Kondensator) und gebogene (5103) Gleise sowie ein Kabel mit einem Kontaktschuh, der wie bei den Signalen einfach an beliebiger Stelle zwischen die Mittelleiterlaschen gesteckt wird. Auch ist es möglich, sich selbst aus beliebigen normalen Gleisstücken ein Anschlußgleis zu bauen. Vorsicht beim Löten! Bei neueren Gleisen bestehen die Isolatoren nicht mehr aus Preßpappe, sondern aus recht hitzeempfindlichen Kunststoff!! Das rote Kabel wird am einfachsten an der Basis der Kontaktzunge angelötet - je nach Zustand diese vorher etwas anrauhen, einen Lötkolben mit hoher Leistung (60-100W) benutzen und vor allem bei Kunststoffisolatoren extrem schnell arbeiten! Das braune Kabel kann bei Bedarf an einer beliebigen Stelle des Unterbaus, möglichst weit weg von jedem hitzeempfindlichen Fremdmaterial angelötet werden. Aber auch hier ein Hinweis an die Dauerlöter: irgendwann schmilzt auch die beste Kabelisolierung, das Gleis wird schneller heiß als man es erwartet und letztlich könnte es zu Verfärbungen der Oberseite kommen.

'''Mittelleiter-Trennstellen''' [[Image:märklin-5015.jpg|framed|left]] Die braunen Pappplättchen, die Märklin jedem Signal beilegt, können ohne Probleme als Vorlage für eigene Kreationen aus Papier oder dünner Pappe dienen. Diese werden dann einfach zwischen die Kontakzungen geschoben, fertig ist die Trennstelle. Sinnvoll ist die Kennzeichnung dieser Stellen z. B. mit dem Trennzeichnen 5015/5016 (?), damit bei späterer Suche die gewollten von ungewollten Unterbrechungen unterschieden werden können.

'''Kontaktstrecken''' Hier gab es zwei verschiedene Gleistypen:

* Das Anschlußset, bestehend aus zwei halben Gleisstücken, bei denen jeweils eine Außenschiene getrennt und isoliert montiert ist und dem isolierten Gleisstück, welches den Fahrbahnübergang sowie die elektrische Verbindung darstellt sowie die Gleise 5115 und 5116 zur Verlängerung dieser Trennstrecke. Sie werden fast ausschließlich für den vollautomatischen Bahnübergänge 7192 genutzt.
* Kontaktgleise 5104/5105 (1/1 gerade bzw. gebogen, bis 1972 produziert) und 5127 (1/2 gerade, bis 1961 produziert). Hier ist ein Teil der Außenschiene isoliert montiert und mit einer seitlich angebrachten Buchse verbunden. Urspünglich zum Schalten von Magnetartikel vorgesehen, sollten diese Gleise dafür nicht genutzt werden - die Kontaktgabe ist zu lang und die Gefahr des Durchbrennens der Spulen zu hoch. Ein sinnvolles Einsatzgebiet ist z.B. die Gleisbesetztmeldung. 

Diese beiden Typen sind untereinander nicht kombinierbar. Anwendungsbeispiele für Kontaktgleise/Kontaktstrecken finden sich im Artikel [[Gleiskontakte#Kontaktgleise | Gleiskontakte]]

'''Schaltgleise''' werden zur kurzzeitigen Kontaktgabe, z. B. zum Schalten von Signalen und Weichen, eingesetzt. Mit den Märklin-Kontaktgleisen 5146, 5147 und 5213 ist zusätzlich eine richtungsabhängige Kontaktabgabe möglich. Dies geschieht durch einen Schaltnocken, der vom Schleifer der Lok (und natürlich auch entsprechend ausgerüsteter Waggons) in der Fahrtrichtung betätigt wird und für die Dauer dieser Betätigung den entsprechenden Kontakt schließt. Prinzipbedingt darf kein Fahrzeug mit Schleifer auf einem Schaltgleisstück zu stehen kommen (direkt angeschlossene Magnetartikel würden sonst in kurzer Zeit durchbrennen). Im Laufe der Jahre erlahmen die Federbleche, die den Schaltnocken in die Mittelstellung bringen. Sie können - eventuell nach vorsichtigem Ausbau des Schaltnockens - mit einer kleinen Spitzzange nachgespannt werden. Gleichzeitig sollten die Kontaktflächen mit einem Kontaktpflegespray gereinigt werden. Anwendungsbeispiele für Schaltgleise im Artikel [[Gleiskontakte#Schaltgleise | Gleiskontakte]]

===Sonstige Gleise===

====Übergangsgleise====

Sie ermöglichen den Übergang zwischen Anlagenteilen, die mit unterschiedlichen Gleissystemen gebaut worden sind. Häufig anzutreffen ist zum Beispiel der [[Schattenbahnhof]] mit den alten M-Gleisen und der sichtbare Teil der Anlage mit K-Gleisen. Märklin bietet dazu drei Gleistypen an:

* 2291 - Übergang M nach K
* 24922 - Übergang K nach C
* 24951 - Übergang M nach C

====Entkupplungsgleis====

Ermöglicht das fernstgesteuerte Abkuppeln bzw. Trennen von Zugverbänden. Wird das Gleis auf der Kuppe eines Ablaufberges montiert und steht dann auch noch das Abdrücksignal 7043 daneben, so ist ein sehr realitätsnahes Rangieren und Zusammenstellen neuer Züge möglich. Ersatzweise kann bei M- und C-Gleisen ein Lichtmast 5113 angesteckt werden. Probleme gibt es, wenn die Kupplungen unter mechanischer Spannung stehen (zu starkes oder zu schwaches Gefälle), verbogen sind, verschiedene Kupplungstypen gemischt werden oder stromführende Kurzkupplungen - sofern überhaupt trennbar - angewandt werden.

====Bahnübergang====

Ein nettes Ausstattungdetail, die angebotene Märklinpalette reicht vom mechanisch betätigten (d.h. vom Fahrzeuggewicht betätigten), eingleisigen Übergang bis hin zum vollautomatischen ein- oder zweigleisigen Übergang mit Halb- und Vollschranken, letztere gibt es für alle drei Gleissysteme. Gesteuert werden diese Übergänge durch Kontaktstrecken (s. o.). Der ambitionierte Modellbahner sollte sich allerdings aufgrund der im Laufe der Zeit sicher auftretenden Kontaktprobleme überlegen, ob er die Ansteuerung nicht über Schaltgleise und Universalfernschalter durchführen sollte - dann ist auch eine Einbindung in ein Signal- und Sicherheitskonzept möglich (siehe [[Modellbahnsteuerung_-_Beispiele_Analogbetrieb#Automatische Fahrwegsteuerung | Automatische Fahrwegsteuerung]])

====Drehscheibe====

Für jedes Dampflok-BW unerläßlich, leider auch nicht sehr Platzsparend. Konventionell betriebene Drehscheiben können grundsätzlich nur von Gleis zu Gleis fahren, ein Vorwählen eines bestimmten Anschlusses oder auch nur ein automatisiertes Wenden ist nicht vorgesehen. Eine Abhilfe wurde an anderer Stelle veröffentlicht, hier hilft Herr Ortwein (siehe [[#Danksagung]]) gerne weiter. Der Einbau erfordert keine Grube, ist jedoch aufgrund der Geräuschentwicklung im Betrieb zu empfehlen. Weitere Dämmungsmaßnahmen sind ebenfalls ratsam. Die Steuerung erfolgt über ein Stellpult mit zwei Tasten. Es können zwei dreiständige Lokschuppen bedient werden.

====Schiebebühne====

Für ein modernes Bw bietet sich die Schiebebühne an, da die Anlagen kompakter gestaltet werden können als bei einer Drehscheibe. Auch ist eine Elektrifizierung der Bühne einfacher und betriebssicherer möglich.

====Prellbock====

So unscheinbar dieses Gleisstück aussieht, so wichtig ist es im regulären Ablauf des Großbetriebes. Dabei spielt die Schutzfunktion am Gleisende nur eine untergeordnete Rolle. Zur Sicherung emfiehlt es sich, die Prellböcke entweder zu befestigen um größere Unfälle zu vermeiden falls ein Treibwagen ungebremst auffährt. Oder ausreichend Platz hinter dem Prellbock beim Aufstellen vorzusehen. Wesentlicher ist die - von Märklin nur durch ein rotes Band angedeutete - Signaltafel SH2 (Schutzhalt). Zur Bedeutung von Prellböcken siehe [./grundlag.html Grundlagen der Eisenbahnsicherungs- und Signaltechnik]. Die Prellböcke gibt es - je nach Gleissystem mit fester oder aufgesprengter Bohlenkonstruktion sowie mit zusätzlicher roter Laterne (Nachtzeichen zu SH2)

===Gleissysteme im Vergleich===

<div align=center>

{| width="80%" border="1" cellspacing="1"
! width="10%" |  
! width="30%" align="middle" | M-Gleis
! width="30%" align="middle" | K-Gleis
! width="30%" align="middle" | C-Gleis
|-
| valign="TOP" | '''Vorbildtreue'''
| valign="TOP" | '''gering bis mäßig''' Mit Ausnahme der 38xx/39xx-Gleise sind die Punktkontakte deutlich zu sehen.
| valign="TOP" | '''sehr hoch''' Böschungskörper und Gleise können beliebig gestaltet werden.
| valign="TOP" | '''hoch''' Böschungskörper stellt guten Kompromiß dar.
|-
| valign="TOP" | '''Trittsicherheit'''
| valign="TOP" | '''nicht gegeben''' Schiene und Böschung sind i.d.R. irreparabel geknickt.
| valign="TOP" | '''hoch''' solange kein Drehmoment auf die Gleise einwirkt.
| valign="TOP" | '''mittel''' Die ersten Gleise verloren den Weichmacher zu schnell und zerbrechen heute schon bei normalem Gebrauch. Neuere Gleise sollen das Problem nicht mehr haben.
|-
| valign="TOP" | '''Robustheit'''
| valign="TOP" | '''hoch''' geeignet für fliegende Anlagen, auch für Kinderhände einfach zusammensetzbar.
| valign="TOP" | '''mittel''' Schienenverbindungen erfordern ruhige Hand und gutes Augenmaß.
| valign="TOP" | '''hoch''' wurde aus einem Spielbahnsystem entwickelt, paßt aufgrund mech. Führung, benötigt keine Schienenlaschen. Für Kinder weniger Verletzungsmöglichkeiten als bei M-Gleisen
|-
| '''Radien'''
| colspan="3" align="MIDDLE" | '''siehe [[#Welche Radien gibt es? | Welche Radien gibt es?]]'''
|-
| valign="TOP" | '''Geräusch- entwicklung'''
| valign="TOP" | '''hoch/niedrig''' Böschungskörper leitet die Rollgeräusche sehr gut (Serien 51xx/52xx), eingelassene Kunststoffschwellen dämmen die Fahrgeräusche gut (Serie 38xx/39xx), Räder an Schienenstößen erzeugen ein rhythmisches Klappern
| valign="TOP" | '''gering''' natürlich wirkendes Rollgeräusch, kaum Probleme mit den Schienenstößen
| valign="TOP" | '''gering''' etwas lauter als K-Gleise
|-
| valign="TOP" | '''Fahr- eigenschaften'''
| valign="TOP" | '''gut/sehr gut''' jede Schiene 'guckt' etwas anders, dadurch entstehen mehr oder weniger hohe Kanten oder seitliche Verwerfungen. Verlangen große Aufmerksamkeit beim Verlegen.
| valign="TOP" | '''sehr gut''' durch Maßhaltigkeit der Schienen sehr zuverlässig; eventuell Probleme mit übergroßen Radsätzen älterer Waggons/Loks
| valign="TOP" | '''sehr gut''' Ähnlich den K-Gleisen, es fehlen allerdings die Langzeiterfahrungen.
|-
| valign="TOP" | '''Kosten'''
| valign="TOP" | '''mittel/sehr hoch''' nicht mehr lieferbar, Börsenpreise bis zu 1,50EUR für neuwertige Ware (Serien 51xx/52xx) bzw. 4EUR (Serien 38xx/39xx)
| valign="TOP" | '''hoch''' lt. Märklin: 2,40EUR für ein Standardgleis
| valign="TOP" | '''hoch''' lt. Märklin: 2,40EUR für ein Standardgleis
|}

</div>

==Signale==
===Formsignale===

Formsignale haben im Märklin H0-System die längste Tradition. Eine Rekonstruktion ist aufgrund ihrer Robustheit und sicheren Funktion nicht notwendig. Allen Signalen gemeinsam ist der graue Schaltkasten (d.h. dessen Abdeckung), welcher anfangs mit Handschalthebel war, später ohne versehen ist. Mit Ausnahme der Vorsignale ohne Zugbeeinflussung (läßt sich allerdings von geschickten Bastlern nachrüsten), haben alle Signale zwei Umschalter welche ohne nennenswerten Aufwand umgebaut werden können.

<div align=center>

{| width="90%" border="1"
! width="5%" | Kat.-Nr.
! width="40%" | Beschreibung
! width="15%" | Abbildung
! width="30%" | Bemerkungen
|-
| align="MIDDLE" | 7036
| Vorsignal mit beweglicher Scheibe, ohne Zusatzflügel, Vo0/Vo1
|  
| keine Zugbeeinflussung möglich!
|-
| align="MIDDLE" | 7037
| Vorsignal mit starrer Scheibe und beweglichem Zusatzflügel, Vz1/Vz2
|
[[Image:märklin-7037.jpg]]
| seit 1975 nicht mehr im Programm keine Zugbeeinflussung möglich!
|-
| align="MIDDLE" | 7038
| Vorsignal mit beweglicher Scheibe und Zusatzflügel, Vz1/Vz2/Vz3
|  
[[Image:märklin-7038.jpg]]
| keine Zugbeeinflussung möglich!
|-
| align="MIDDLE" | 7039
| Hauptsignal mit einem beweglichem Flügel, Hp0/Hp1
|  
[[Image:märklin-7039.jpg]]
|  
|-
| align="MIDDLE" | 7040
| Hauptsignal mit zwei gekoppelten Flügel, Hp0/Hp2
|  
[[Image:märklin-7040.jpg]]
|-
| align="MIDDLE" | 7041
| Hauptsignal mit zwei ungekoppeltem Flügeln, Hp0/Hp1/Hp2
|  
[[Image:märklin-7041.jpg]]
|  
|-
| align="MIDDLE" | 7042
| Gleissperrsignal, Ve3/Ve4
|  
[[Image:märklin-7042.jpg]]
|  
|-
| align="MIDDLE" | 7043
| Abdrücksignal, Ra6/Ra7/Ra8
|  
[[Image:märklin-7043.jpg]]
| seit 1961 nicht mehr im Programm
|}

</div>

===Lichtsignale===

Lichtsignale der Serie 70xx haben mechanisch die selben Eigenschaften wie die Formsignale der Serie 70xx. Signale der Baureihe 7187/7188 sind vereinfachte Signale zum Einstieg, wobei das Vorsignal 7187 ohne Hauptsignal 7188 nicht sinvoll betrieben werden kann. Signale der Serie 72xx haben einen abnehmbaren Signalantrieb und (wieder mit Ausnahme der Vorsignale) Möglichkeiten zur Zugbeeinflussung, wobei Standard ein Umschalter und zwei einpolige Schalter sind. Letztere können zum zweiten Umschalter umgebaut werden.

<div align=center>

{| width="90%" border="1"
! width="5%" | Kat.-Nr.
! width="40%" | Beschreibung
! width="15%" | Abbildung
! width="30%" | Bemerkungen
|-
| align="MIDDLE" | 7044
| Lichthauptsignal, Hp0/Hp1
|  
[[Image:märklin-7044.jpg]]
| seit 1958 nicht mehr im Programm
|-
| align="MIDDLE" | 7236
| Vorsignal
|  
| seit 2003 nicht mehr im Programm
|-
| align="MIDDLE" | 7237
| Vorsignal
|  
| seit 2003 nicht mehr im Programm
|-
| align="MIDDLE" | 7238
| Vorsignal
|  
| seit 2003 nicht mehr im Programm
|-
| align="MIDDLE" | 7239
| Hauptsignal, Hp0/Hp1
|  
| seit 2003 nicht mehr im Programm
|-
| align="MIDDLE" | 7240
| Hauptsignal, Hp0/Hp2
|  
| seit 2003 nicht mehr im Programm
|-
| align="MIDDLE" | 7241
| Hauptsignal, Hp0/Hp1/Hp2
|  
| seit 2003 nicht mehr im Programm
|-
| align="MIDDLE" | 7242
| Gleissperrsignal, Sh0/Sh1
|  
[[Image:märklin-7242.jpg]]
| seit 2003 nicht mehr im Programm
|-
| align="MIDDLE" | 76383
| Vorsignal, Vr0/Vr1/Vr2
|  
| mit intergrierter Elektronik, ohne Zugbeeinflussung
|-
| align="MIDDLE" | 76391
| Hauptsignal, Hp0/Hp1
|  
| mit intergrierter Elektronik
|-
| align="MIDDLE" | 76393
| Hauptsignal, Hp0/Hp1/Hp2
|  
| mit intergrierter Elektronik
|-
| align="MIDDLE" | 76394
| Hauptsignal mit Gleissperrsignal, Hp00/Hp1/Hp2/Hp0/Sh1
|  
| mit intergrierter Elektronik
|-
| align="MIDDLE" | 76395
| Hauptsignal mit Vorsignal, Hp0/Hp1
|  
| mit intergrierter Elektronik, Kombination aus 76391 und 76383
|-
| align="MIDDLE" | 76397
| Hauptsignal mit Vorsignal, Hp0/Hp1/Hp2
|  
| mit intergrierter Elektronik, Kombination aus 76393 und 76383
|-
| align="MIDDLE" | 76371
| Gleissperrsignal,. Sh0/Sh1
|  
| mit intergrierter Elektronik
|-
| align="MIDDLE" | 76372
| Gleissperrsignal mit Mast, Sh0/Sh1
|  
| mit intergrierter Elektronik
|}

</div>

==Oberleitung im Märklinsystem==

<hr>

Dieser Artikel ist auf der Basis dem Abschnitte 2 der alten "FAQ H0 AC" von Stephan-Alexander Heyn entstanden. Mehr über die Artikel "Märklin H0" unter [[Märklin H0 : Allgemeines]]

[[Kategorie:Gleise]]
[[Kategorie:Zubehör]]

Märklin H0 : Das Märklin-System

2008-11-04T16:27:50Z

Michael Oppenauer: /* Übergangsgleise */ Link gesetzt

=Das Märklin-System=

==Das Märklin-Gleissystem==

===Allgemeines zum Gleissystem===

====Welche Gleise kann ich benutzen?====

Nicht alle Modelle, die von anderen Firmen für das Märklinsystem produziert wurden, einschließlich umgerüsteter Modelle, können ohne Probleme auf Märklingleisen betrieben werden. Innerhalb der Produktpalette von Märklin sind mit wenigen Ausnahmen (siehe unten) alle Gleise für alle Modelle geeignet

====Welche Radien gibt es?====

Im Metallgleissortiment (seit 2001 nicht mehr im Programm"!) gab es 5 Radien: Industriekreis/R0 (R = 286 mm) mit 5120 Normalkreis/R1 (R = 360 mm) mit 5100 Parallelkreis/R2 (R = 437,4 mm) mit 5200 Großkreis I/R3 (R = 535 mm) mit 3800, (nur von 1953 bis 1957 im Programm!) Großkreis II/R4 (R = 585 mm) mit 3900, (nur von 1953 bis 1957 im Programm!) Nähere Informationen finden sich im Unterabschnitt [[#Metall-Gleise | Metall-Gleise]]

Das Kunststoffgleissortiment hat ebenfalls 5 Radien (die K-Gleise der 21xx-Serie sind nicht mehr im Programm!) Industriekreis/R0 (R = 295 mm) mit 2110 oder 2210 Normalkreis/R1 (R = 360 mm) mit 2121 oder 2221 Parallelkreis/R2 (R = 424,6 mm) mit 2131 oder 2231 Großkreis I/R3,5 (R = 553,9 mm) mit 2141 oder 2241 Großkreis II/R4,5 (R = 618,5 mm) mit 2151 oder 2251 beliebige Radien (erst ab 360mm Radius empfehlenswert) können mit dem Flexgleis 2205 individuell zugeschnitten werden. Nähere Informationen finden sich im Unterabschnitt [[Märklin_H0_:_Das_Märklin-System#Kunststoff-Gleise | Kunststoff-Gleise]]

Das C-Gleissortiment hat zur Zeit folgende Radien (ACHTUNG: C-Gleise haben kein Industrieradius mehr!) Normalkreis/R1 (R = 360 mm) mit 24130 Parallelkreis/R2 (R = 437,5 mm) mit 24620 Großkreis I//R3 (R= 515mm) mit 24330 Großkreis II/R4 (R=579,3mm) mit 24430 Großkreis III/R5 (R=643,6mm) mit 24530 Riesenkreis III/R9 (R=1114,6mm) mit 24912 (ACHTUNG: bislang nur in Form von Weichen und Gegenbögen vorhanden!) Nähere Informationen finden sich im Unterabschnitt [[Märklin_H0_:_Das_Märklin-System#C-Gleise| C-Gleise]]

Zwischenradien können bei allen Gleistypen aus einem kleineren Radius mit kleinen, geraden Gleisstücken erzeugt werden.

====Welche Gleise kann ich im DC-Betrieb benutzen?====

Für den 2-Leiter-DC-Betrieb und den 3-Leiter-Betrieb '''nicht''' geeignet sind die M-Gleise der 3600, 5100 und 5200-Reihe. Weichen der Kunststoffgleise haben verbundene Außenleiter (22xx-Serien), sodaß hier Umbaumaßnahmen zum (Außenleiter-)DC-Betrieb notwendig sind. Alle anderen Gleise von Märklin sind DC-tauglich.

====Welche Fahrzeuge kann ich auf den Gleisen betreiben?====

Bei historischen Modellen, die mit "Pilzschleifern" (diese Schleifer sehen von der Seite aus wie umgedrehte Pilze) ausgestattet sind, sind zum Betrieb mit Punktkontaktgleisen nicht zu empfehlen. Gleiches gilt teilweise auch für "Löffelschleifer". Für den Betrieb auf den heutigen Märklingleisen sind die "Skischleifer" betriebssicher. Fremdfabrikate mit diesen Schleifertypen (z.B. Trix-Express) sind ebenfalls NICHT betriebssicher. Diese Schleifertypen können sich bei Weichen in den Herzstücken verhaken und die Lok bzw. den Zug zum Entgleisen bringen. Mit den ehemaligen Mittelschienengleisen können alle Schleifertypen betrieben werden.

====Welche Radien können befahren werden?====

* Der derzeitige Standardradius beträgt 360mm. Alle Märklinfahrzeuge können diesen Radius ohne Probleme im Normalfall befahren.
* Angesetzte Details (Kolbenstangenschutzrohre, Schürzen, etc.) vergrößern den Mindestradius (siehe auch die Bedienungsanleitung zum Modell)

** Nicht betriebssicher sind:
*** 2-achsige Personen- und Güterwagen mit einem Achsstand >10cm auf R0
*** 4-achsige Personenwagen mit einem Drehgestellabstand >20cm auf R0
*** Wagenverbände mit Kurzkupplung im Schiebebetrieb in Radien <= R1
*** neuere Schnellzugdampfloks ab Baujahr 1973, und alle Varianten der BR 41 auf R0
*** Güterzugdampfloks neuerer Produktion ohne Knickrahmen auf R0
*** Schienenzeppeline aller Varianten auf R0 und in Gegen (d.h. S-)Kurven
*** 1:100 und 1:87-Modelle von anderen Herstellern in R0
*** 1:100 und 1:87 bei M-Gleisweichen mit großen (d.h. quadratischen) Laternenköpfen
** Problematisch sind außerdem:
*** Alle Varianten der BR 41 können auf Weichen des Normalkreises, vor allem beim M-Gleis, entgleisen.
*** Alle Varianten der BR 18.1 mit kurzem Tender neigen bei großen Zuglasten zum Entgleisen bei Radien < R5.
*** 1:100-Schnellzugwagenmodelle von Märklin in R0 (bedingt)
*** Schienenzeppelin 3077 bei hoher Geschwindigkeit in Radien <R2
** Empfehlungen:
*** wirklich nur kurze Industriegleise für kleine, zweiachsige Wagen und kurze Loks mit max. 3 Achsen verlegen.
*** S-Kurven vermeiden.
*** keine Hauptstrecken mit Industrieradius versehen.
*** besondere Vorsicht mit Modellen bei hoher Geschwindigkeit

====Welche Steigungen können befahren werden?====

Generell für Steigungen gilt, daß '''vor allem''' der Übergang zwischen Ebene und Steigung nicht zu abrupt geschehen darf (längere Fahrzeuge bleiben sonst im Knick hängen). Der maximale, störungsfrei zu bewältigende Übergang aus der Ebene für alle bisher produzierte Märklinmodelle in H0 ist von 0 auf 1:20 (von 0 auf 5%). Sind Wagenmodelle mit 30,3cm (1:87 Schnellzugwagen) vorhanden, so sollte der maximale Übergang von 0 auf 1:50 (2%) nicht überschreiten. 

* Bei Clubanlagen und ausreichend Platz sollte die allgemeine Empfehlung von 3% nicht überschritten werden
* Alle Märklin-H0-Modelle können 5% problemlos bewältigen, lediglich Modelle mit Märklin-Faulhabermotor werden deutlich langsamer
* Falls der Platz nicht ausreicht, können bis 15% Steigung bewältigt werden. Ab 10% haben einige Modelle Probleme die Steigung in Solofahrt zu bewältigen
* In Spezialfällen sind Steigungen bis 20% und mehr möglich. '''Derartige Steigungen sollten wirklich nur die Ausnahme bleiben.'''

Wenn man große Steigungen schon einrichtet, dann sollte die Rampe auch gut gegen ein Durchhängen gesichert sein, sonst sind die Modelle durch noch größere Steigungen überlastet. 

'''Folgende Auflistungen basieren auf Erfahrungswerten von Modellbahnern. Sie erheben keinen Anspruch auf generelle Anwendbarkeit!''' Viele betriebliche Probleme können durch Pflege des Rollmaterials behoben bzw. durch intensive Schieneninstandhaltung '''(ÖL!)''' vermieden bzw. beseitigt werden.

Modelle, die 10% Steigung in Solofahrt unter Umständen nicht bewältigen können sind:

* 3015/CCS800/30159/36159 (schweizer Krokodil Ce 6/8 II mit SLFCM)
* 33591 (schweizer Doppellokomotive Typ Ae 8/14 mit DELTA und DCM2)

Betriebsprobleme bei Zugfahrten mit mehr als 5 Wagen vom Typ C4i Wü 01 (Nr. 4211) ab 3% Steigung können mit Modellen, die den Faulhabermotor 1717 oder den Sinus-Motor haben auftreten. Falls der Zug an Hp0 stehen soll, rollt der Zug ggf. rückwärts den Hang hinunter. Dies gilt für alle Betriebsarten (analog/digital). Davon betroffen sind bislang:

* (3311, 3411, 3511, 3513, 3514, 3611, 3613, 3614, 3711, 34112, 34113, 37112, 37113 als Varianten der BR 18.1, 34059,37059 als Varianten der BR 59)
* alle Modelle mit der Katalognummer 39xxx, die einen Sinus-Motor enthalten können bei Zughalt in Steigungen bergab rollen

Dieses Problem läßt sich durch geeigneten Anlagenaufbau vermeiden (keine Halteabschnitte in Steigungen). Bei noch höheren Zuglasten (8 Wagen) kann es ab 5% zum Stillstand auf der Steigung kommen.

===Compound-Gleise===

====Alpha-Gleise====

Im Jahre 1988 wurde das bisherige Gleis-System aus K- bzw. M-Gleisen durch das "Alpha-Gleis" mit der Bezeichnung "Gleis 2000" erweitert. Diese Gleise waren eine Kombination Kunststoff-Böschungskörper und Metall-Gleisen und stellten mit ihrem neuen Stecksystem die Vorläufer der C-Gleise dar. Diese Gleise waren nur von 1988 bis 1996 im Programm. Die angebotenen Gleisstücke orientierten sich in ihrem Raster am M-Gleis (180mm, R1, R2):

* 2001 Gerade 1/1 (180mm)
* 2006 6 gerade Gleise 2001 1/1 mit Verpackung als Brücke
* 2019 Prellbock (70mm)
* 2021 Gebogenes Gleis 1/1 R1 (r=360mm, 30°)
* 2026 6 gebogene Gleise 2021 1/1 mit Verpackung als Brücke
* 2031 Gebogenes Gleis 1/1 R2 (r=456,4mm, 30°)
* 2062 Weiche R1 links (180mm/30°)
* 2063 Weiche R1 rechts (180mm/30°)
* 2090 Anschluß gerade 1/1 (180mm)
* 2091 Übergangsgleis Alpha-M-Gleis, gerade 1/1 (180mm)

 Dieses Gleissystem wurde ohne Ausgleichsgleise angeboten.

====C-Gleise====

'''Vorbemerkungen'''

Umfangreiche Informationen zum C-Gleis erhält man zunächst auf den Produktseiten der Firma Märklin. Folgende Hinweise mögen als praxisbezogene und kostensparende Ergänzung dienen. [[Image:märklin-c-gleis.jpg | framed|left]] '''Gleisanschlüsse''' Für den Anschluß der C-Gleise gibt es die Anschlußgarnitur 74040 mit Flachsteckhülsen zum Anstecken an das Gleis. Die Anschlüsse lassen sich auch sehr leicht löten (roter Pfeil).

'''Mittelleiter-Trennstellen''' Für die Trennung des Mittelleiters der C-Gleise gibt es die Mittelleiter-Isolierung 74030. Diese, in Form kleiner, roter Hütchen produzierten Isolationen werden über die inneren Kontaktlaschen geschoben und unterbrechen damit die Verbindung. Pro Packung (74030) sind acht Hütchen für vier Trennstellen enthalten. Flexibler läßt sich der Mittelleiter an der Unterseite des Gleises (zwischen den Pukos!) mit der Minitrennscheibe unterbrechen (grüner Pfeil). Diese Trennung läßt sich später gegebenenfalls durch eine Kabelbrücke zwischen den beiden B-Anschlüssen des Gleises wieder schließen.

'''Kontaktstrecken''' Das Prinzip des Kontaktgleises auf zwei elektrisch getrennten Gleisen, wobei nur eine Seite an Masse angeschlossen ist. Das andere Gleis wird dann durch die Radsätze mit Masse verbunden. Beim C-Gleis haben die beiden Gleise jeweils ihre eigenen Kontakte und sind nur an beiden Enden durch eine Brücke miteinander verbunden.Durchtrennt man diese beiden Brücken (gelbe Pfeile), so hat man bereits ein Kontaktgleis. Diese Trennung läßt sich später gegebenenfalls durch eine Kabelbrücke zwischen den beiden 0-Anschlüssen des Gleises wieder schließen. Am Anfang und Ende der Kontaktstrecke muß nun allerdings noch jeweils eine Gleistrennung erfolgen. Bequemste (leider auch teuerste und unflexibelste) Lösung ist der Kontaktgleis-Satz 24995. Die einfachste Lösung - aber später nicht mehr rückgängig zu machen - wäre auch hier wieder die Trennscheibe. Da die Gleise aber konstruktionsbedingt keine Schienenverbinder besitzen, reicht eines der oben erwähnten Isolierungs-Hütchen auf der äußeren Kontaktzunge zur Trennung der Gleise (solange diese sich nicht durch unebenen Untergrund oder Fertigungstoleranzen berühren sollten - ist bei mir ''(B.N. Anm. des Autors)'' bisher aber nicht vorgekommen).

'''Anwendungsbeispiel''' Ein Anlagenbau nach diesen Regeln wird unter [http://www.noethlich.net/modellbahn http://www.noethlich.net/modellbahn] dokumentiert.

===Kunststoff-Gleise===

'''K-Gleise''' bestehen - genau wie die C-Gleise - aus zwei gegeneinander isolierten Aussenschienen sowie einem verdeckt in den Schwellen angeordnetem Mittelleiter. Es gibt zwei grundsätzlich unterschiedliche Gleistypen:

[[Image:märklin-k-gleis.jpg|framed|left]]

* Serie 21xx von 1969 - 1980 gefertigt, mit Hohlprofilschienen (gefalzten Schienen) und breiten Kontaktlaschen (im Bild links)
* Serie 22xx seit 1980 gefertigt mit Vollprofilschienen (massiv, vorbildgetreuer) und engen Kontaktlaschen. (Bild rechts)

Die K-Gleise sind systembedingt empfindlicher als C- und M-Gleise und eignen sich damit nur bedingt für den Aufbau fliegender Anlagen. Allerdings hat ein Tritt auf ein solches Gleisstück nicht die verheerenden Folgen wie das z. B. bei M-Gleisen der Fall ist. Kritisch ist vor allem das Zusammenstecken der Gleise, insbesondere im Bereich von Weichenstraßen. Nur allzu schnell bricht das außenliegende Stück der Schwelle ab und muß dann durch entsprechende Landschaftsgestaltung kaschiert werden, sofern das Bruchstück nicht wieder anzukleben ist. Beim Übergang von 21xx auf 22xx Gleise müssen die engeren, weil höher ausgeführten Schienenverbindungslaschen der 22xx-Gleise mit recht großem Druck zusammgefügt werden; dies kann insbesondere bei kurzen Gleisstücken zu Verschiebungen bis hin zum Ausbrechen der Schienen führen. Daher sollte in solchen Bereichen nur 'sortenrein' verlegt werden.

'''Anschlußgleise''' [[Image:märklin-kgleisunten.jpg|framed|right]] Neben dem Standardanschlußgleis 2290 (2292 mit Entstörkondensator) von Märklin besteht die Möglichkeit, jedes beliebige Gleisstück mit einer Anschlußleitung zu versehen. Dazu muß nur auf der Unterseite ein Kabel an das in der Schwellenmitte freiliegende Kupferblech gelötet werden (gelber Pfeil). Vorsichtig und schnell (=heiß) arbeiten, damit der darüberliegende Kunststoff keinen Schaden nimmt. Bei Bedarf kann auch an die Edelstahlprofile der Außenschienen ein Massekabel angelötet werden. Eine weitere Möglichkeit besteht darin, ein leicht V-förmig gebogenes (Feder-) Blech zwischen Schienenprofil und Schwellenunterbau zu schieben. Selbstverständlich ist vorher das Anschlußkabel an dieses Blech zu löten (Ähnlich dem Masseanschluß 7500 von Märklin).

'''Mittelleiter-Trennstellen''' Zur Trennung der Mittelleiter müssen jeweils die beiden kupfernen Kontaktzungen unter den Schienenverbindern gegeneinander isoliert werden. Dazu gibt es von Märklin unter der Nummer 7522 passende Kunststoffeinsätze. Mit etwas Feingefühl läßt sich aber auch eine Isolierung aus Papier, dünner Pappe oder sogar Tesafilm verwirklichen. Dies ist aber nur bei fester Verlegung der Gleise verläßlich. Falls die Gleise 'mit absoluter Sicherheit und nie wieder' ausgebaut werden sollen, ist es auch denkbar, die Kontakzungen einfach abzutrennen. Die Mittelleitertrennungen sollten zur Erleichterung einer späteren Fehlersuche vor Ort gekennzeichnet werden.

'''Kontaktstrecken''' werden z. B. vor Bahnübergängen oder in Schattenbahnhöfen benötigt. Kontaktstrecken detektieren alle Fahrzeuge, die sich in ihrem Bereich befinden. Dies geschieht durch Überbrücken der von einander isolierten Außenschienen durch die Achsen der darauf befindlichen Fahrzeuge. Dies kann durch den Kontaktgleissatz 2295 von Märklin oder durch einfaches Auftrennen einer Außenschiene jeweils am Anfang und Ende der zu überwachenden Strecke erfolgen; da die Schienen gegeneinander isoliert sind, kann der Zwischenraum mit normalen Gleisen bestückt werden. Anwendungsbeispiele für Kontaktgleise/Kontaktstrecken finden sich im Artikel [[Gleiskontakte#Kontaktgleise | Gleiskontakte]]

'''Schaltgleise''' werden zur kurzzeitigen Kontaktgabe, z. B. zum Schalten von Signalen und Weichen, eingesetzt. Mit den Märklin-Kontaktgleisen 2229, 2239 und 2299 ist zusätzlich eine richtungsabhängige Kontaktabgabe möglich. Dies geschieht durch einen Schaltnocken, der vom Schleifer der Lok (und natürlich auch entsprechend ausgerüsteter Waggons) in der Fahrtrichtung betätigt wird und für die Dauer dieser Betätigung den entsprechenden Kontakt schließt. Prinzipbedingt darf kein Fahrzeug mit Schleifer auf einem Schaltgleisstück zu stehen kommen (direkt angeschlossene Magnetartikel würden sonst in kurzer Zeit durchbrennen). Im Laufe der Jahre erlahmen die Federbleche, die den Schaltnocken in die Mittelstellung bringen. Im Gegensatz zu den Schaltgleisen der M-Serie lassen sich die K-Gleise kaum noch nachjustieren. Anwendungsbeispiele für Schaltgleise finden sich im Artikel [[Gleiskontakte#Schaltgleise | Gleiskontakte]]

===Metall-Gleise===

'''M-Gleise''' mit Punktkontakten lösten ab 1957 Jahren die Mittelleiterschienen ab und wurden bis zum Jahr 2001 gefertigt und sind "werkseitig nicht mehr verfügbar". Wer also eine Anlage mit M-Gleisen bauen oder erweitern will, ist auf die Restbestände im Handel oder auf Modellbahnbörsen und (Online-)Auktionen angewiesen.

'''Anschlußgleise''' Hier ist die Auswahl etwas vielfältiger als bei den K-Gleisen, es gibt gerade (5111 bzw. 5130/31 mit Kondensator) und gebogene (5103) Gleise sowie ein Kabel mit einem Kontaktschuh, der wie bei den Signalen einfach an beliebiger Stelle zwischen die Mittelleiterlaschen gesteckt wird. Auch ist es möglich, sich selbst aus beliebigen normalen Gleisstücken ein Anschlußgleis zu bauen. Vorsicht beim Löten! Bei neueren Gleisen bestehen die Isolatoren nicht mehr aus Preßpappe, sondern aus recht hitzeempfindlichen Kunststoff!! Das rote Kabel wird am einfachsten an der Basis der Kontaktzunge angelötet - je nach Zustand diese vorher etwas anrauhen, einen Lötkolben mit hoher Leistung (60-100W) benutzen und vor allem bei Kunststoffisolatoren extrem schnell arbeiten! Das braune Kabel kann bei Bedarf an einer beliebigen Stelle des Unterbaus, möglichst weit weg von jedem hitzeempfindlichen Fremdmaterial angelötet werden. Aber auch hier ein Hinweis an die Dauerlöter: irgendwann schmilzt auch die beste Kabelisolierung, das Gleis wird schneller heiß als man es erwartet und letztlich könnte es zu Verfärbungen der Oberseite kommen.

'''Mittelleiter-Trennstellen''' [[Image:märklin-5015.jpg|framed|left]] Die braunen Pappplättchen, die Märklin jedem Signal beilegt, können ohne Probleme als Vorlage für eigene Kreationen aus Papier oder dünner Pappe dienen. Diese werden dann einfach zwischen die Kontakzungen geschoben, fertig ist die Trennstelle. Sinnvoll ist die Kennzeichnung dieser Stellen z. B. mit dem Trennzeichnen 5015/5016 (?), damit bei späterer Suche die gewollten von ungewollten Unterbrechungen unterschieden werden können.

'''Kontaktstrecken''' Hier gab es zwei verschiedene Gleistypen:

* Das Anschlußset, bestehend aus zwei halben Gleisstücken, bei denen jeweils eine Außenschiene getrennt und isoliert montiert ist und dem isolierten Gleisstück, welches den Fahrbahnübergang sowie die elektrische Verbindung darstellt sowie die Gleise 5115 und 5116 zur Verlängerung dieser Trennstrecke. Sie werden fast ausschließlich für den vollautomatischen Bahnübergänge 7192 genutzt.
* Kontaktgleise 5104/5105 (1/1 gerade bzw. gebogen, bis 1972 produziert) und 5127 (1/2 gerade, bis 1961 produziert). Hier ist ein Teil der Außenschiene isoliert montiert und mit einer seitlich angebrachten Buchse verbunden. Urspünglich zum Schalten von Magnetartikel vorgesehen, sollten diese Gleise dafür nicht genutzt werden - die Kontaktgabe ist zu lang und die Gefahr des Durchbrennens der Spulen zu hoch. Ein sinnvolles Einsatzgebiet ist z.B. die Gleisbesetztmeldung. 

Diese beiden Typen sind untereinander nicht kombinierbar. Anwendungsbeispiele für Kontaktgleise/Kontaktstrecken finden sich im Artikel [[Gleiskontakte#Kontaktgleise | Gleiskontakte]]

'''Schaltgleise''' werden zur kurzzeitigen Kontaktgabe, z. B. zum Schalten von Signalen und Weichen, eingesetzt. Mit den Märklin-Kontaktgleisen 5146, 5147 und 5213 ist zusätzlich eine richtungsabhängige Kontaktabgabe möglich. Dies geschieht durch einen Schaltnocken, der vom Schleifer der Lok (und natürlich auch entsprechend ausgerüsteter Waggons) in der Fahrtrichtung betätigt wird und für die Dauer dieser Betätigung den entsprechenden Kontakt schließt. Prinzipbedingt darf kein Fahrzeug mit Schleifer auf einem Schaltgleisstück zu stehen kommen (direkt angeschlossene Magnetartikel würden sonst in kurzer Zeit durchbrennen). Im Laufe der Jahre erlahmen die Federbleche, die den Schaltnocken in die Mittelstellung bringen. Sie können - eventuell nach vorsichtigem Ausbau des Schaltnockens - mit einer kleinen Spitzzange nachgespannt werden. Gleichzeitig sollten die Kontaktflächen mit einem Kontaktpflegespray gereinigt werden. Anwendungsbeispiele für Schaltgleise im Artikel [[Gleiskontakte#Schaltgleise | Gleiskontakte]]

===Sonstige Gleise===

====Übergangsgleise====

Sie ermöglichen den Übergang zwischen Anlagenteilen, die mit unterschiedlichen Gleissystemen gebaut worden sind. Häufig anzutreffen ist zum Beispiel der [[Schattenbahnhof]] mit den alten M-Gleisen und der sichtbare Teil der Anlage mit K-Gleisen. Märklin bietet dazu drei Gleistypen an:

* 2291 - Übergang M nach K
* 24922 - Übergang K nach C
* 24951 - Übergang M nach C

====Entkupplungsgleis====

Ermöglicht das fernstgesteuerte Abkuppeln bzw. Trennen von Zugverbänden. Wird das Gleis auf der Kuppe eines Ablaufberges montiert und steht dann auch noch das Abdrücksignal 7043 daneben, so ist ein sehr realitätsnahes Rangieren und Zusammenstellen neuer Züge möglich. Ersatzweise kann bei M- und C-Gleisen ein Lichtmast 5113 angesteckt werden. Probleme gibt es, wenn die Kupplungen unter mechanischer Spannung stehen (zu starkes oder zu schwaches Gefälle), verbogen sind, verschiedene Kupplungstypen gemischt werden oder stromführende Kurzkupplungen - sofern überhaupt trennbar - angewandt werden.

====Bahnübergang====

Ein nettes Ausstattungdetail, die angebotene Märklinpalette reicht vom mechanisch betätigten (d.h. vom Fahrzeuggewicht betätigten), eingleisigen Übergang bis hin zum vollautomatischen ein- oder zweigleisigen Übergang mit Halb- und Vollschranken, letztere gibt es für alle drei Gleissysteme. Gesteuert werden diese Übergänge durch Kontaktstrecken (s. o.). Der ambitionierte Modellbahner sollte sich allerdings aufgrund der im Laufe der Zeit sicher auftretenden Kontaktprobleme überlegen, ob er die Ansteuerung nicht über Schaltgleise und Universalfernschalter durchführen sollte - dann ist auch eine Einbindung in ein Signal- und Sicherheitskonzept möglich (siehe [[Modellbahnsteuerung_-_Beispiele_Analogbetrieb#Automatische Fahrwegsteuerung | Automatische Fahrwegsteuerung]])

====Drehscheibe====

Für jedes Dampflok-BW unerläßlich, leider auch nicht sehr Platzsparend. Konventionell betriebene Drehscheiben können grundsätzlich nur von Gleis zu Gleis fahren, ein Vorwählen eines bestimmten Anschlusses oder auch nur ein automatisiertes Wenden ist nicht vorgesehen. Eine Abhilfe wurde an anderer Stelle veröffentlicht, hier hilft Herr Ortwein (siehe [[#Danksagung]]) gerne weiter. Der Einbau erfordert keine Grube, ist jedoch aufgrund der Geräuschentwicklung im Betrieb zu empfehlen. Weitere Dämmungsmaßnahmen sind ebenfalls ratsam. Die Steuerung erfolgt über ein Stellpult mit zwei Tasten. Es können zwei dreiständige Lokschuppen bedient werden.

====Schiebebühne====

Für ein modernes Bw bietet sich die Schiebebühne an, da die Anlagen kompakter gestaltet werden können als bei einer Drehscheibe. Auch ist eine Elektrifizierung der Bühne einfacher und betriebssicherer möglich.

====Prellbock====

So unscheinbar dieses Gleisstück aussieht, so wichtig ist es im regulären Ablauf des Großbetriebes. Dabei spielt die Schutzfunktion am Gleisende nur eine untergeordnete Rolle. Zur Sicherung emfiehlt es sich, die Prellböcke entweder zu befestigen um größere Unfälle zu vermeiden falls ein Treibwagen ungebremst auffährt. Oder ausreichend Platz hinter dem Prellbock beim Aufstellen vorzusehen. Wesentlicher ist die - von Märklin nur durch ein rotes Band angedeutete - Signaltafel SH2 (Schutzhalt). Zur Bedeutung von Prellböcken siehe [./grundlag.html Grundlagen der Eisenbahnsicherungs- und Signaltechnik]. Die Prellböcke gibt es - je nach Gleissystem mit fester oder aufgesprengter Bohlenkonstruktion sowie mit zusätzlicher roter Laterne (Nachtzeichen zu SH2)

===Gleissysteme im Vergleich===

<div align=center>

{| width="80%" border="1" cellspacing="1"
! width="10%" |  
! width="30%" align="middle" | M-Gleis
! width="30%" align="middle" | K-Gleis
! width="30%" align="middle" | C-Gleis
|-
| valign="TOP" | '''Vorbildtreue'''
| valign="TOP" | '''gering bis mäßig''' Mit Ausnahme der 38xx/39xx-Gleise sind die Punktkontakte deutlich zu sehen.
| valign="TOP" | '''sehr hoch''' Böschungskörper und Gleise können beliebig gestaltet werden.
| valign="TOP" | '''hoch''' Böschungskörper stellt guten Kompromiß dar.
|-
| valign="TOP" | '''Trittsicherheit'''
| valign="TOP" | '''nicht gegeben''' Schiene und Böschung sind i.d.R. irreparabel geknickt.
| valign="TOP" | '''hoch''' solange kein Drehmoment auf die Gleise einwirkt.
| valign="TOP" | '''mittel''' Die ersten Gleise verloren den Weichmacher zu schnell und zerbrechen heute schon bei normalem Gebrauch. Neuere Gleise sollen das Problem nicht mehr haben.
|-
| valign="TOP" | '''Robustheit'''
| valign="TOP" | '''hoch''' geeignet für fliegende Anlagen, auch für Kinderhände einfach zusammensetzbar.
| valign="TOP" | '''mittel''' Schienenverbindungen erfordern ruhige Hand und gutes Augenmaß.
| valign="TOP" | '''hoch''' wurde aus einem Spielbahnsystem entwickelt, paßt aufgrund mech. Führung, benötigt keine Schienenlaschen. Für Kinder weniger Verletzungsmöglichkeiten als bei M-Gleisen
|-
| '''Radien'''
| colspan="3" align="MIDDLE" | '''siehe [[#Welche Radien gibt es? | Welche Radien gibt es?]]'''
|-
| valign="TOP" | '''Geräusch- entwicklung'''
| valign="TOP" | '''hoch/niedrig''' Böschungskörper leitet die Rollgeräusche sehr gut (Serien 51xx/52xx), eingelassene Kunststoffschwellen dämmen die Fahrgeräusche gut (Serie 38xx/39xx), Räder an Schienenstößen erzeugen ein rhythmisches Klappern
| valign="TOP" | '''gering''' natürlich wirkendes Rollgeräusch, kaum Probleme mit den Schienenstößen
| valign="TOP" | '''gering''' etwas lauter als K-Gleise
|-
| valign="TOP" | '''Fahr- eigenschaften'''
| valign="TOP" | '''gut/sehr gut''' jede Schiene 'guckt' etwas anders, dadurch entstehen mehr oder weniger hohe Kanten oder seitliche Verwerfungen. Verlangen große Aufmerksamkeit beim Verlegen.
| valign="TOP" | '''sehr gut''' durch Maßhaltigkeit der Schienen sehr zuverlässig; eventuell Probleme mit übergroßen Radsätzen älterer Waggons/Loks
| valign="TOP" | '''sehr gut''' Ähnlich den K-Gleisen, es fehlen allerdings die Langzeiterfahrungen.
|-
| valign="TOP" | '''Kosten'''
| valign="TOP" | '''mittel/sehr hoch''' nicht mehr lieferbar, Börsenpreise bis zu 1,50EUR für neuwertige Ware (Serien 51xx/52xx) bzw. 4EUR (Serien 38xx/39xx)
| valign="TOP" | '''hoch''' lt. Märklin: 2,40EUR für ein Standardgleis
| valign="TOP" | '''hoch''' lt. Märklin: 2,40EUR für ein Standardgleis
|}

</div>

==Signale==
===Formsignale===

Formsignale haben im Märklin H0-System die längste Tradition. Eine Rekonstruktion ist aufgrund ihrer Robustheit und sicheren Funktion nicht notwendig. Allen Signalen gemeinsam ist der graue Schaltkasten (d.h. dessen Abdeckung), welcher anfangs mit Handschalthebel war, später ohne versehen ist. Mit Ausnahme der Vorsignale ohne Zugbeeinflussung (läßt sich allerdings von geschickten Bastlern nachrüsten), haben alle Signale zwei Umschalter welche ohne nennenswerten Aufwand umgebaut werden können.

<div align=center>

{| width="90%" border="1"
! width="5%" | Kat.-Nr.
! width="40%" | Beschreibung
! width="15%" | Abbildung
! width="30%" | Bemerkungen
|-
| align="MIDDLE" | 7036
| Vorsignal mit beweglicher Scheibe, ohne Zusatzflügel, Vo0/Vo1
|  
| keine Zugbeeinflussung möglich!
|-
| align="MIDDLE" | 7037
| Vorsignal mit starrer Scheibe und beweglichem Zusatzflügel, Vz1/Vz2
|
[[Image:märklin-7037.jpg]]
| seit 1975 nicht mehr im Programm keine Zugbeeinflussung möglich!
|-
| align="MIDDLE" | 7038
| Vorsignal mit beweglicher Scheibe und Zusatzflügel, Vz1/Vz2/Vz3
|  
[[Image:märklin-7038.jpg]]
| keine Zugbeeinflussung möglich!
|-
| align="MIDDLE" | 7039
| Hauptsignal mit einem beweglichem Flügel, Hp0/Hp1
|  
[[Image:märklin-7039.jpg]]
|  
|-
| align="MIDDLE" | 7040
| Hauptsignal mit zwei gekoppelten Flügel, Hp0/Hp2
|  
[[Image:märklin-7040.jpg]]
|-
| align="MIDDLE" | 7041
| Hauptsignal mit zwei ungekoppeltem Flügeln, Hp0/Hp1/Hp2
|  
[[Image:märklin-7041.jpg]]
|  
|-
| align="MIDDLE" | 7042
| Gleissperrsignal, Ve3/Ve4
|  
[[Image:märklin-7042.jpg]]
|  
|-
| align="MIDDLE" | 7043
| Abdrücksignal, Ra6/Ra7/Ra8
|  
[[Image:märklin-7043.jpg]]
| seit 1961 nicht mehr im Programm
|}

</div>

===Lichtsignale===

Lichtsignale der Serie 70xx haben mechanisch die selben Eigenschaften wie die Formsignale der Serie 70xx. Signale der Baureihe 7187/7188 sind vereinfachte Signale zum Einstieg, wobei das Vorsignal 7187 ohne Hauptsignal 7188 nicht sinvoll betrieben werden kann. Signale der Serie 72xx haben einen abnehmbaren Signalantrieb und (wieder mit Ausnahme der Vorsignale) Möglichkeiten zur Zugbeeinflussung, wobei Standard ein Umschalter und zwei einpolige Schalter sind. Letztere können zum zweiten Umschalter umgebaut werden.

<div align=center>

{| width="90%" border="1"
! width="5%" | Kat.-Nr.
! width="40%" | Beschreibung
! width="15%" | Abbildung
! width="30%" | Bemerkungen
|-
| align="MIDDLE" | 7044
| Lichthauptsignal, Hp0/Hp1
|  
[[Image:märklin-7044.jpg]]
| seit 1958 nicht mehr im Programm
|-
| align="MIDDLE" | 7236
| Vorsignal
|  
| seit 2003 nicht mehr im Programm
|-
| align="MIDDLE" | 7237
| Vorsignal
|  
| seit 2003 nicht mehr im Programm
|-
| align="MIDDLE" | 7238
| Vorsignal
|  
| seit 2003 nicht mehr im Programm
|-
| align="MIDDLE" | 7239
| Hauptsignal, Hp0/Hp1
|  
| seit 2003 nicht mehr im Programm
|-
| align="MIDDLE" | 7240
| Hauptsignal, Hp0/Hp2
|  
| seit 2003 nicht mehr im Programm
|-
| align="MIDDLE" | 7241
| Hauptsignal, Hp0/Hp1/Hp2
|  
| seit 2003 nicht mehr im Programm
|-
| align="MIDDLE" | 7242
| Gleissperrsignal, Sh0/Sh1
|  
[[Image:märklin-7242.jpg]]
| seit 2003 nicht mehr im Programm
|-
| align="MIDDLE" | 76383
| Vorsignal, Vr0/Vr1/Vr2
|  
| mit intergrierter Elektronik, ohne Zugbeeinflussung
|-
| align="MIDDLE" | 76391
| Hauptsignal, Hp0/Hp1
|  
| mit intergrierter Elektronik
|-
| align="MIDDLE" | 76393
| Hauptsignal, Hp0/Hp1/Hp2
|  
| mit intergrierter Elektronik
|-
| align="MIDDLE" | 76394
| Hauptsignal mit Gleissperrsignal, Hp00/Hp1/Hp2/Hp0/Sh1
|  
| mit intergrierter Elektronik
|-
| align="MIDDLE" | 76395
| Hauptsignal mit Vorsignal, Hp0/Hp1
|  
| mit intergrierter Elektronik, Kombination aus 76391 und 76383
|-
| align="MIDDLE" | 76397
| Hauptsignal mit Vorsignal, Hp0/Hp1/Hp2
|  
| mit intergrierter Elektronik, Kombination aus 76393 und 76383
|-
| align="MIDDLE" | 76371
| Gleissperrsignal,. Sh0/Sh1
|  
| mit intergrierter Elektronik
|-
| align="MIDDLE" | 76372
| Gleissperrsignal mit Mast, Sh0/Sh1
|  
| mit intergrierter Elektronik
|}

</div>

==Oberleitung im Märklinsystem==

<hr>

Dieser Artikel ist auf der Basis dem Abschnitte 2 der alten "FAQ H0 AC" von Stephan-Alexander Heyn entstanden. Mehr über die Artikel "Märklin H0" unter [[Märklin H0 : Allgemeines]]

[[Kategorie:Gleise]]
[[Kategorie:Zubehör]]

Der Einstieg ins Hobby - analog oder Digital?

2008-11-04T16:25:47Z

Michael Oppenauer: /* Computer Steuerung */ Link gesetzt

== Analog vs. Digital ==
Diese Übersicht ist bewusst allgemein gehalten. Es sollen nur grundlegende Eigenschaften der Systemwelten aufgezeigt werden. Insbesondere ist fast alles, was als fehlend bezeichnet ist, durch Zusatzaufwand in jedem System realisierbar. Weiter sind viele Eigenschaften je nach System/Lieferant unterschiedlich stark ausgeprägt.

=== Welche Systeme gibt es? ===

In Analog gibt es im wesentlichen zwei Systeme: Mittelleiter mit Wechselstrom (H0 und teilweise Spur 0) und 2-Leiter Gleichstrom (alle Baugrößen). In Spur 1 gab es auch mal 2-Leiter Wechselstrom (von Märklin)

In Digital gibt es zwei große und einige weniger verbreitete Systeme:

* '''Märklin/Motorola''' hauptsächlich für die beiden hauseigenen Systeme Mittelleiter-H0 und Spur 1. Es gab davon auch eine Gleichstrom Variante, die von Arnold vertrieben wurde. Es gibt im wesentlichen nur Märklin als Komplettlieferant. Für Lokdekoder, Schaltempfänger und Rückmeldebausteine gibt es jedoch weitere Lieferanten.
* '''NMRA-DCC''' ('''N'''ational '''M'''odell '''R'''ailroader '''A'''ssociation '''- D'''igital '''C'''ommand '''C'''ontrol) hauptsächlich für 2-Leiter mit Gleichstrom Motoren. Es lässt sich jedoch auch im Mittelleiter Gleissystem einsetzen, sofern Gleichstrom Motoren verwendet werden. Es gibt eine Vielzahl von Lieferanten sowohl für Komplettsysteme, als auch für einzelne Komponeneten. Ein wichtiger Vorteil ist, dass dieses System einer öffentlichen Norm zu Grunde liegt.
* '''Selectrix''' von Trix (2-Leiter, Gleichstrom) hat den Vorteil, dass es in diesem System von Anfang an sehr kleine Lokdekoder gab. Daher ist es vor allem für die Baugröße N beliebt. Weiter werden die Fahreigenschaften dank 32 Fahstufen und Motorregelung gelobt. Allerdings haben die Hersteller von NMRA-DCC Lokdekodern mittlerweile ebenfalls sehr kleine Dekoder im Angebot / in der Planung. Trix scheint jedoch langsam auch auf NMR-DCC umzuschwenken. Die neueste Zentrale von Trix unterstützt sowohl das Selectrix als auch das NMRA-DCC Protokoll. Einziger Systemlieferant ist Trix. Die Firmen MÜT und MTTM liefern/entwickeln jedoch eine Palette von einzelnen Komponenten.
* '''FMZ''' von Fleischmann (2-Leiter, Gleichstrom) wird im wesentlichen nur bei Lokmodellen von Fleischmann verwendet. Fleischmann hat mittlerweile die Konsequenz aus dem Nischendasein seines Digitalsystems gezogen und bietet seit 2000 Twin-Dekoder und Twin-Zentraleinheiten an, die neben dem FMZ Protokoll auch das NMRA-DCC Protokoll beherschen.
* '''ZIMO''' war der Pionier der Digitalisierung. Neben dem (alten) hauseigenem System gibt es seit einiger Zeit NMRA-DCC Dekoder. Die neueren ZIMO Zentraleinheiten unterstützen beide Protokolle. 
* Alle bisher erwähnten System steuern die Lokomotiven. Daneben gibt es jedoch auch Systeme, die die Spannung an Gleisabschnitten steuern. Dadurch entfällt der Umbau von Lokomotiven. Jedoch funktioniert diese Art der Steuerung nur in Verbindung mit einem Computerprogramm. Anbieter solcher Systeme sind: Gahler & Ringstmeier (erfordert zusätzliche Baugruppen im Computer, hoher Verdrahtungsaufwand), CTI und RCI (einzelne Baugruppe auf der Anlage, die über eine Steuerleitung miteinander und mit dem Computer verbunden sind). Das System von G&A entspricht dabei eher einer konventionellen Anlagensteuerung, die auf den Computer verlagert wurde. Die Systeme von CTI und RCI hingegen entsprechen eher einem Digitalsystem, nur dass statt der Loks die Gleisabschnitte gesteuert werden. Schalten und Erfassen erfolgen dabei wie in einem Digitalsystem. Diese Art von Systemen ist jedoch (zumindest in Europa) nicht sehr verbreitet.

Wie aus den Darstellungen oben hervorgeht scheint es mittlerweile auf zwei Systeme hinauszulaufen. - Mittelleiter Gleissystem mit Märklin/Motorola Protokoll. - 2-Leiter Gleissystem mit NMRA-DCC Protokoll Für beide Protokolle gilt, dass diese über einen längeren Zeitraum weiterentwickelt wurden, so dass es heute mehrere Protokoll Varianten mit unterschiedlichen Fähigkeiten bzgl. Anzahl der Fahrstufen, Adressen und Funktionen gibt. Aktuelle Zentralen in beiden Systemen unterstützen jedoch weiterhin die älteren Protokoll Varianten.

Eine aktuelle Entwicklung sind die Multi Protokoll Zentralen, die zwei oder mehr verschiedene Protokolle anbieten. Neben den Geräten von Trix, Fleischmann und ZIMO, die das eigene System um das NMRA-DCC Protokoll erweitern, gibt es die Intellibox von Uhlenbrock, die drei Systemwelten miteinander verbindet: Selectrix, Märklin/Motorola und NMRA-DCC. Bei letzterer werden auch mehrere Systeme für Eingabegeräte und Rückmeldung unterstützt.

=== Welche Komponenten gehören zu einem Digital- oder Analogsystem? ===

Zu einem Digitalsystem gehören folgende Konponenten:

* '''[[Digitalzentrale|Zentraleinheit]]''' (Control Unit, Central Control, ...) erzeugt aus den Eingaben die notwendigen Digitalsignale
* '''Verstärker''' ([[Booster]]) liefert die notwendige Leistung für das Digitalsignal am Gleis
* '''Transformator''' zur Spannungs/Stromversorgung
* '''Eingabegeräte''' zum Steuern von Loks und Schaltelementen (Weichen, Signale, Relais, Stellmotoren)
* '''[[Decoder#Lokdecoder|Lokdekoder]]''' zum Steuern der Lokmodelle
* '''[[Decoder#Schaltdecoder|Schaltdekoder]]''' zum Steuern von Weichen, Signale, Relais, ...
* '''Rückmeldeeinheiten''' zum Erfassen von Istzuständen auf der Anlage ([[Besetztmelder|Gleisbesetztmeldung]], ...) Der Bus für die Rückmeldung ist leider nicht standardisiert. Jeder Systemhersteller baut sein eigenens System.
* '''Computerinterface''' zur Verbindung mit einem Steuerprogramm auf einem Computer

Notwendig sind die Komponenten Zentraleinheit, Verstärker, Transformator, Eingabegerät und Lok-/Schaltdekoder. Die Komponenten Zentraleinheit, Verstärker und Eingabegerät sind oft in einem Gerät zusammengefasst.

In einem Analogsystem braucht man die Komponenten '''Transformator''', '''Regler''' und einfache '''Schalter'''. Transformator und Regler sind meist in einem Gerät vereint. Bei endabgeschalteten Antrieben ist eine Rückmeldung der Schalterstellung meist mit eingebaut.

=== Loksteuerung und Fahrverhalten ===

In den Analogsystemen kann man mehrere Loks nur dadurch unabhängig voneinander steuern, indem jede Lok auf einem eigenen Stromabschnitt fährt. Dies bedeutet einen entsprechenden Aufwand für Trennstellen, Verkabelung und Regler/Trafo.

In den Digitalsystemen stellt jeder Lokdekoder einen eigenen Regler für genau diese eine Lok dar. Am Gleis liegt immer die selbe Spannung an (sofern die Leistungsfähigkeit des Verstärkrs nicht überschritten wird). Dadurch entfällt die Notwendigkeit von abschaltbaren Abschnitten z.B. für das Abstellen von Loks. Der Verkabelungsaufwand reduziert sich damit theoretisch auf einen einzigen Anschluss an das Gleis. Dies gilt jedoch nur in der Theorie. Bei großen Anlagen, bzw. vielen Loks oder Wagenbeleuchtung müssen doch wieder mehrere Verstärker und damit Stromabschnitte eingesetzt werden. Weiter ist es in beiden Systemwelten sinnvoll in regelmässigen Abständen Stromeinspeisungen vorzunehmen (min. alle 3 Meter). Sollen funktionsfähige Signale benutzt werden sind in beiden Systemwelten Trennabschnitte mit eigener, allerdings örtlicher, Behandlung vorzusehen.

Das Fahrverhalten eines Lokmodells wird von fünf Kriterien beeinflusst. - '''Stromabnahme''' (Kontaktsicherheit) - '''Mechanik''' (Kraftübertragung, Getriebe, Achsdruck) - '''Schwungmasse''' (ohne/mit, Dimension) - '''Motoreigenschaften''' - '''Spannungsregelung''' Die Stromabnahme kann ggfs. durch zusätzliche Kontaktpunkte verbessert werden. Regelmässige Reinigung der Räder und Schienen ist sicherlich hilfreich. Die Mechanik ist weitgehend durch die Konstruktion festgelegt (Zahl und Art der angetriebenen Achsen, Getriebeauslegung, Haftreifen, ...). Hier kann man nur wenig ändern. Lediglich durch Säubern und Schmieren der Getriebeteile und ggfs. Entgraten der Zahnräder kann man hier eine Verbesserung erzielen. Eine Änderung des Getriebes ist meistens schwierig und aufwendig. Der Achsdruck kann vielleicht noch durch Erhöhung des Ballastgewichtes verbessert werden. Eine (größere) Schwungmasse nachzurüsten ist in den meisten Fällen eine umfangreiche Arbeit und erfordert oft das Ausarbeiten des Ballastgewichtes. Die Motoreigenschaften kann man nur durch Tausch verändern. Allerdings ist ein Umbau auf z.B. Faulhaber Motoren nicht billig. Ist ein Rundmotor, wie er z.B. von Fleischmann oder Märklin oft verwendet wird, zu ersetzen, sind meistens umfangreiche Änderungsarbeiten notwendig.

Lediglich bei der Spannungssteuerung unterscheiden sich Analog und Digital Systeme. Im Analogsystem wird ein Gleisabschnitt geregelt, unabhängig von den Fahreigenschaften der verschiedenen Lokmodelle. Eine Anpassung an unterschiedliche Lokmodelle ist daher nicht möglich. In einem Digitalsystem hat jede Lok durch den Dekoder ihren eigenen Regler eingebaut. Hier kann man die Regeleigenschaften an die Motoreigenschaften und das Fahrverhalten einer einzelnen Lok gezielt anpassen (sofern der Dekoder das zulässt). Eingestellt werden können meistens die Anfahrspannung, die maximale Geschwindigkeit sowie die Verzögerung beim Beschleunigen und Bremsen. Bei vielen Dekodern nach NMRA-DCC Standard kann zudem die Geschwindigkeitstabelle, das heisst die Zuordnung von Fahrstufe zu Motorspannung, programmiert werden. Man soll sich jedoch nicht täuschen. Man kann zwar das Fahrverhalten varieren, aber unzureichende Stromabnahme, schlechte Mechanik und fehlende Schwungmasse kann man damit nur zum Teil ausgleichen. Stehen diese drei Punkte jedoch auf der positiven Seite, kann man durch die Einstellungen im Dekoder das Fahrverhalten wirklich optimieren.

=== Schalten und Verkabeln ===

Schalten bedeuten in diesem Zusammenhang das Stellen von Weichen und Signalen, das Ein- und Ausschalten von Motoren und anderen elektrischen Verbrauchern (z.B. Licht, Blinker, ...).

Dies ist in Analogsystemen klar und einfach. Einfach die Kabel vom Verbraucher zu einem passenden Schalter ziehen und ggfs. diesen mit einer gemeinsamen Stromquelle verbinden. Geschaltet werden drei verschiedene Arten. - 1.) Weichen, Signale, ... also im Prinzip Relais. - 2.) Allgemeine Verbraucher wie Licht, Motoren oder Pumpen - 3.) Fahrstrom für abschaltbare Gleisabschnitte Der Aufwand bei der Verkabelung entsteht dadurch, dass die Schalter üblicherweise am Anlagenrand untergebracht werden (müssen). Dadurch ergeben sich recht lange Kabelwege. Will/muss man nun mehr als ein Dutzend Elemente schalten, so muss man schon deutlichen Aufwand betreiben, um die Verkabelung übersichtlich zu halten. Die Kabelwege werden dann, durch das meistens angewandte rechtwinklige Verlegen, nochmals deutlich länger.

In einem Digitalsystem werden '''Schaltdekoder''' verwendet. Die häufiste Art kann vier Elemente schalten. Der Schaltdekoder kann nun in der Nähe der zu schaltenden Elemente plaziert werden. Dadurch bleiben die Kabelwege kurz und übersichtlich. Die Schaltdekoder selbst werden über eine Leitung mit einem Booster und dadurch mit dem Digitalsignal verbunden. Bei kleinen Anlagen kann der Einfachheit halber der Digitalstrom aus dem Gleis entnommen werden. Bei größeren Anlagen wid man dafür einen eigenen Boosterkreis verwenden. Die Stellbefehle kommen dann über die Zentraleinheit von einem entsprechendem Eingabegerät (z.B. Keyboard).

Will man nun ein '''[[Modellbahnsteuerung#Gleisbildstellpulte|Gleisbildstellpult]]''' statt der einfachen Schalter bzw. des Keybords verwenden stellt sich die Situation anders dar. In einem Analogsystem ersetzen die Schalter im Stellpult einfach die normalen Schalter. Die Kabel müssen dazu in der Regel nur verlängert werden. Rückmeldungen von Weichen- und Signalstellungen sind bei endabgeschalteten Antrieben in der Regel integriert. In einem Digitalsystem müssen hingegen über entsprechende Eingabedekoder von jedem Schalter im Stellpult die Adresse des zugehörigen Ports des Schaltdekoders erzeugt werden. Für Rückmeldungen müssen zusätzliche Anzeigedekoder benutzt werden.

=== Sicherungstechnik ===

Sicherungstechnik heisst das Erzwingen von Sicherheits relevanten Betriebszuständen. Das schliesst insbesondere ein: - '''Automatischer Halt''' vor roten Signalen - '''Automatische Langsamfahrt''' bei entsprechendem Signalbild - '''Automatische Blocksteuerung''' (Einfahrt in einen Block nur wenn der nächste Block frei ist) - '''Fahrstrassen''' mit Flankenschutz und Sicherungssignalen

In Analogsystemen sind die Punkte 1 - 3 relativ einfach zu realisieren. Automatischer Halt kann durch Abschalten des Fahrstroms sehr einfach erfolgen. Signale haben oft einen zusätzlichen Schalter für diesen Zweck. Langsamfahrt kann durch Schalten eines Fahrstroms mit geringerer Fahrspannung erfolgen (Relais). Für beide Zwecke kann auch ein Anfahr/Bremsbaustein verwendet werden. Einige Anfahr/Bremsbaustein können auch so miteinander verbunden werden, dass sich daraus eine automatische Blocksteuerung ergibt. Für diesen Zweck sind jedoch auch spezialisierte Bausteine verfügbar. Das Schalten von Fahrstrassen (also das gemeinsame, nicht notwendig zeitgleiche Schalten mehrer Elemente [Weichen, Signale]) ist im Analogsystem nicht auf einfachem Weg möglich. Natürlich gibt es Lösungen wie Relaisketten oder Diodenmatrix, jedoch gibt es kaum fertige Bausteine für diesen Zweck.

In Digitalsystemen ist das automatische (langsame) Anhalten oder automatische Langsamfahrt für eine beliebige Lok nicht standardisiert. Demzufolge haben einige Dekoder keinerlei Vorkehrung dafür, andere reagieren auf Bremsdioden (z.B. Selectrix), wieder andere benötigen dafür Bremsgeneratoren. Will man also diese Funktionalität haben, so ist man bei der Auswahl seiner Lokdekoder eingeschränkt. Eine automatische Blocksteuerung benötigt den gezielten Halt vor Signalen und unterliegt daher denselben Einschränkugen. Das Definieren und Schalten von Fahrstrassen ist in Digitalsystemen prinzipiell möglich, es benötigt jedoch in der Regel entsprechende Zusatzkomponenten. Daher wird es in den meisten Fällen eher über eine Computer Steuerung realisiert.

Es bleibt festzuhalten, dass es weder im Analog- noch im Digitalsystem ein einheitliches, tragfähiges (= für alle Loks gültiges) Konzept für die Sicherungstechnik gibt. Während im Analogsystem eine automatische Blocksteuerung relativ einfach zu realisieren ist, erfordert eine Fahrstrassen Sicherung einiges an Aufwand. Umgekehrt hängt in einem Digitalsystem der automatische Halt vor einem Signal von den Eigenschaften der Lokdekoder ab. Dies gilt insbesondere, wenn mit Multiprotokoll Zentralen Dekoder aus verschiedenen Digitalsystemen eingesetzt werden. Damit ist eine automatische Blocksteuerung ebensowenig gewährleistet, wie eine Fahrstrassen Sicherung. Abschaltung des Digitalstroms wäre zwar möglich, führt jedoch zum Nothalt vor jedem roten Signal und ist damit sicherlich nicht im Sinne einer Digitalsteuerung. Leider ist bei der Entwicklung der verschiedenen Digitalsysteme der Punkt Sicherungstechnik konzeptionell nicht berücksichtigt worden.

Beispiele, wie das im im Analogbetrieb geht, kann man in den Artikeln [[Gleiskontakte]] und [[Modellbahnsteuerung_-_Beispiele_Analogbetrieb]] sehen.

=== Halt vor Signal ===

In einer Diskussion zum Thema "Digitaler Halt vor Signal" wurden verschiedene Methoden diskutiert einen Zug vor einem rot zeigenden Signal (langsam) anzuhalten.

Die einfachste Methode ist natürlich einfach den Strom auszuschalten. Das geht immer und funktioniert für alle Loks, aber man verliert die Vorteile eines Digitalsystems wie langsames Anhalten, Licht, Funktionen, ... Als zusätzliche Sicherung ist es jedoch sinnvoll. Eigentlich ist diese Methode auch für Analog nicht akzeptabel. Man verwendet dort Anfahr-Brems-Bausteine, um ein langsames Anhalten vor dem Signal zu erreichen.

Alle nachfolgenden Methoden verwenden eine andere Stromart oder ein anderes Digitalsignal im Signalabschnitt. Daher müssen entsprechende Vorkehrungen gegen Kurzschluss zwischen Signalabschnitt und der Strecke mit dem normalen Digitalsignal getroffen werden. Dazu verwendet man zumeist einen umschaltbaren Gleisabschnitt vor dem Signalabschnitt. Die Umschaltung erfolgt unmittelbar vor der Einfahrt in den Signalabschnitt. Dieser umschaltbare Gleisabschnitt muss auf den längsten Zug ausgelegt sein. Der Signalabschnitt kann dadurch ggfs. kürzer ausfallen.

{| cellpadding="3" align="Center" bgcolor="#CCCCCC"
! width="20%" bgcolor="#DDDDDD" |
! width="35%" | Märklin/Motorola Digital ----
! width="45%" | NMRA-DCC Digitalsystem ----
|- valign="Top"
! bgcolor="#DDDDDD" | Strom aus plus Abschnitt mit Langsamfahrt
| Die Dekoder sollen unterhalb von 5V nicht mehr ordnungsgemäß arbeiten. Mit einem kleinen Sicherheitsaufschlag sollte das für die Einrichtung eines Abschnitt mit reduzierter Geschwindigkeit ausreichen. ''Erfahrungen ???''
| Nach der Spezifikation müssen NMRA-DCC Dekoder bis hinunter zu +/- 7V arbeiten. Das sollte reichen um einen Abschnitt mit reduzierter Geschwindigkeit einzurichten. Wie Loks und ihre Dekoder auf eine Reduktion der Spannung tatsächlich reagieren ist jedoch noch zu erproben. Insbesondere geregelte Dekoder könnten für Überraschungen sorgen.
|- valign="Top"
! bgcolor="#DDDDDD" | Umschalten auf Analog
| '''???''' Loks mit Dekodern, die den Analogbetrieb unterstützen, fahren vermutlich mit einer Geschwindigkeit relativ zur Spannung weiter. Die digitalen Funktionen gehen wahrscheinlich verloren. Frage: Unterstützen alle Dekoder den Analogbetrieb?
| Loks mit Dekodern, die den Analogbetrieb unterstützen, halten mit der eingestellten Verzögerung an, wenn die Gleichspannung entgegen der Fahrtrichtung gepolt ist. Sie wechseln jedoch nicht die Fahrtrichtung! Frage: Unterstützen alle Dekoder den Analogbetrieb? Frage: Was passiert, wenn der Analogbetrieb abgeschaltet ist?
|- valign="Top"
! bgcolor="#DDDDDD" | Broadcast Adresse: Halt an alle
| '''???''' Frage: Gibt es im M/M Digitalsystem eine Broadcast Adresse?
| In der erweiterten NMRA-DCC Spezifikation ist die Adresse 0 als Broadcast Adresse definiert. Alle Dekoder müssen auf Befehle an diese Adresse reagieren. Ein Haltebefehl an diese Adresse setzt nur die Geschwindigkeit. Die digitalen Funktionen sind davon nicht betroffen. Im NMRA-DCC Basis Standard (99 Adressen, 14 Fahrstufen) ist das Paket mit Adresse 0 und Geschwindigkeit 0 als Dekoder Reset definiert. Dies erfordert ein unmittelbares Anhalten. Problem: Alte Dekoder können mit sofortigen Halt, statt langsamen Abbremsen reagieren.
|- valign="Top"
! bgcolor="#DDDDDD" | Bremsgenerator
| Bremsgeneratoren funktionieren nur mit bestimmten Dekodern, daher sind sie nicht universell einsetzbar.
| Obwohl die Hersteller das nicht offenlegen, werden die meisten Bremsgeneratoren nach dem Prinzip der Broadcast Adresse arbeiten. Dennoch garantieren die Hersteller die Funktion nur für ihre eigenen Produkte.
|- valign="Top"
! bgcolor="#DDDDDD" |
| colspan="2" | ----
|- valign="Top"
! bgcolor="#DDDDDD" | Eigene CU+Booster sendet Halt für alle aktiven Adressen
| colspan="2" | Dies erfordert die Kommunikation zwischen zwei Zentraleinheiten. Dies ist in den Digitalsystemen nicht vorgesehen. Vermutlich kann das, abgesehen von den elektrischen Problemen, nur mit einer Steuerung per Computer gelöst werden. Vorteil wäre, das dies auch Multiprotokol fähig sein sollte.
|- valign="Top"
! bgcolor="#DDDDDD" | Bremsdioden
| colspan="2" | Bremsdioden werden im Selectrix System von Trix eingesetzt. Nur sehr wenige Dekoder in anderen Systemen benutzen diese Möglichkeit für ein Bremssignal. (Technisch gesehen reagiert der Dekoder auf das Ausbleiben einer Halbwelle.)
|- valign="Top"
! bgcolor="#DDDDDD" | ZIMO
| colspan="2" | ZIMO benutzte schon in seinem alten System eine Funktion, um Loks ein Bremssignal zu geben. Diese Funktion ist auch in den NMRA-DCC kompatiblen Dekodern von ZIMO eingebaut. Dennoch ist es eine Insellösung, da sie nur in ZIMO Dekodern implementiert ist.
|- valign="Top"
! bgcolor="#DDDDDD" | Computersteuerung plus Zugverfolgung
| colspan="2" | Diese Methode beruht darauf den Standort eines Zuges zu kennen und ihm bei Annäherung an ein rot zeigendes Signal einen Brems/Halt Befehl zu senden. Diese Methode ist unabhängig vom eingesetzten Digitalsystem, aber erfordert den Einsatz eines Computers, was nicht jeder Modellbahner will. Die Sicherheit dieser Methode hängt von der Korrektheit des Anfangszustandes und der Genauigkeit der Ortsmeldungen ab. Hinzufügen / Entfernen von Loks kann hierbei problematisch sein.
|- valign="Top"
! bgcolor="#DDDDDD" | Computersteuerung plus Zugerkennung
| colspan="2" | Die Zugerkennung eleminiert die Probleme der Zugverfolgung. Methoden sind Strichcode oder Transponder mit entsprechenden Lesegeräten. Nachteilig sind die hohen Kosten und die Notwendigkeit die Anlage über einen Computer zu steuern.
|}

=== Computer Steuerung ===

<blockquote> Prinzipiell kann man in beiden Systemwelten eine Computer Steuerung aufbauen. In einem Analogsystem bedeutet das jedoch einen erheblichen Hardware Aufwand. Im Computer sind I/O Karten zu installieren, auf der Anlage bzw. am Übergabepunkt sind Anpassungen von den bei Modellbahn Anlagen üblichen Spannungen (12-16 Volt) auf Computer verträgliche 5 Volt vorzusehen. Ist Leistung zu schalten muss ein Relais oder Treiberbaustein verwendet werden. Um den Computer vor elektrischen Problemen auf der Modellbahn Anlage zu schützen, ist eine galvanische Trennung z.B. durch Optokoppler notwendig. Dass es geht, aber auch sehr aufwendig im Sinne von Zeit und Geld ist, beweist das System [[MpC]] von [http://www.gahler.de Gahler & Ringstmeier].

In den Digitalsystem ist eine Verbindung zum Computer konzeptionell mit eingeplant. Es werden lediglich die Interface Komponente und das Verbindungskabel benötigt. Da es den Anschluss an Computer schon seit langer Zeit bei den verschiedenen Digitalsystemen gibt, sind Programme zur Computer Steuerung in einer Vielzahl von Formen und Funktionsumfang verfügbar. Mehr darüber kann man auf [[Modellbahnsteuerung_via_PC|Modellbahnsteuerung via PC]] erfahren.

Welche Vorteile bietet nun eine Steuerung mit dem Computer?

* '''Kostenbegrenzung:''' Durch eine Computer Steuerung können viele Teile, die sonst als Hardware Komponenten auszuführen sind, durch Software realisiert werden. Dies betrifft vor allen zusätzliche Lokregler und ein Gleisbild Stellpult.
* '''Überwachung von Istzuständen:''' Dies ist die Voraussetzung für jede Form der Sicherung und Automatisierung. (Stellung von Weichen und Signalen, Gleisbelegung, Zugposition, ...)
* '''Sicherungslogik:''' Erzwingung sicherer Zustände durch Ausführung von Aktionen erst, wenn dies ohne Risiko möglich ist. (z.B. Blocksignal kann erst auf grün geschaltet werden, wenn der Blockabschnitt davor nicht belegt ist.)
* '''Fahrstrassen & Sicherung:''' Definition aller Weichen und Signalstellungen für eine Fahrstrasse. Zur Sicherung können zusätzliche Elemente definiert werden (Schutzweichen, Signale, ...). Freigabe der Fahrstrasse erst, wenn alle Bedingungen erfüllt sind.
* '''Automatikbetrieb:''' Fahren von Zügen nach Ereignissen. (Zugkreuzung, Überhohlung, Aufenthalt, [[Schattenbahnhof]], ...). In der Regel ist eine entsprechende Sicherungslogik Voraussetzung.
* '''Fahrplanbetrieb:''' Dies ist eigentlich auch ohne Computer gut möglich. Allerdings kann der Computer durch Bereitstellung von Informationen und Überwachung der Zeit gute Unterstützung leisten (Computer als Fahrdienstleiter). Besonders interessant, wenn mit verkürzter Modellzeit gefahren wird.
* '''Gleisbild Stellpult:''' Viele Leute werden durch den Aufwand, den es bedeutet ein reales Gleisbild Stellpult zu bauen, (Zeit, Kosten, Konzeption, Aufbau, Verkabelung, ...) davon abgehalten, jemals eines zu bauen. Mit einem Computer Programm vereinfacht sich das Ganze erheblich. Alles kann ausprobiert werden bis es funktioniert. Die Anlage kann Stück für Stück in das Gleisbild Stellpult übernommen werden bis alles stimmt. Und das Ganze ohne finanzielle Verluste befürchten zu müssen.

Alle oben erwähnten Punkte können letztendlich auch ohne Computer Steuerung erfolgen - für einen Fahrplanbetrieb z.B. bedarf es eigentlich nur einer (Modell-)Uhr und eines Buchfahrplans - aber mit Hilfe von Computer Programmen ist es oft einfacher und/oder kostengünstiger zu erreichen.

Aus finanziellen Gründen kann es interessant sein, auch die Zentraleinheit als ein Programm auszuführen. Der Computer erzeugt das Digitalsignal und gibt es direkt an den Booster, der die notwendige Leistung zur Verfügung stellt. An Hardware braucht man dann nur noch einen Booster, einen Transformator und die Verbindung zum Computer. Ein Beispiel für diese Art von Programmen sind '''DDL''' (Digital Direct for Linux) von Torsten Vogt und '''Lok''' (für MS-DOS) von Dr. M. König.

=== Sonstiges ===

* In Digitalsystemen verschwinden die Unterschiede zwischen Wechsel- und Gleichstrom. Alle Systeme verwenden Rechteckspannungen um Strom und Daten gleichzeitig auf einem Leiterpaar zu übertragen. Die Motoren werden nicht mehr durch Änderung der Spannung gesteuert, sondern durch Änderung des Taktverhältnisses einer gepulsten Spannung (PWM == Puls Wide Modulation).
* Der Trend wird zu immer mehr Lokmodellen gehen, die von vorne herein einen Dekoder eingebaut haben. Bei Märklin H0 ist das schon sehr verbreitet, da dort durch den Dekoder, der sonst für den Analogbetieb notwendige, Umschalter für die Fahrtrichtung eingespart wird.
* Ausser bei dem System von ZIMO ist in keinem Digitalsystem eine Lokerkennung vorgesehen. Damit wurde leider eine Chance für den Automatikbetrieb vertan. In Programmen zur Steuerung wir versucht, dies durch eine Zugverfolgung zu ersetzen. Das bietet aber nicht die gleiche Sicherheit wie die Lokerkennung. Insbesondere ist man von der korrekten Angabe des Anfangzustandes abhängig. Das Hinzufügen oder Entfernen von Loks/Zügen erfordert dann Eingriffe am Computer.
* Startsets bieten die Möglichkeit zu einem preisgünstigen Einstieg in ein Digitalsystem. Genauso wie die Lok- und Wagenmodelle in Startsets häufig vereinfachte Varianten sind, müssen bei digitalen Startsets oft Einschränkungen im Funktionsumfang hingenommen werden. Ob dieser geringere Funktionsumfang für die eigenen Zwecke ausreichend ist, sollte man vor einem Kauf sorgfältig überlegen.
* Wirklich faszinierend sind funktionsfähige Modelle von Eisenbahnkränen, wie sie von Roco und Märklin angeboten werden. Diese Modelle sind nur in einem Digitalsystem denkbar. In einem Analogsystem gibt es keine Möglichkeit, sie unabhängig von der Fahrspannung zu steuern.
* Die Nachrüstung vorhanderner Analogloks mit einem Digitaldekoder ist im Prinzip möglich. Bei aktuellen oder relativ neuen Lokmodellen sollte das mit einem geringen bis vertretbaren Aufwand möglich sein. Lediglich bei alten oder sehr kleinen Lokmodellen kann es kritisch werden. Da ist dann manchmal ein größerer Umbau mit Fräsarbeiten notwendig, um Platz für den Digitaldekoder und seine Kabel zu schaffen. In den kleinen Baugrößen N und TT ist hier natürlich stärker mit Problemen zu rechnen.

=== Fazit ===

Eigentlich kann man keinen allgemeinen Rat geben, ob Mann oder Frau ein Digitalsystem einsetzen soll. Zu unterschiedlich sind die Bedürfnisse, zu groß ist die Zahl der Varianten, zu zahlreich sind die Faktoren, die Zeit, Kosten oder Aufwand beeinflussen. Auch kann nur jeder für sich selbst entscheiden, was ihm/ihr Freude bereitet und wofür man Zeit und/oder Geld investieren will. Dennoch wollen wir versuchen, im Folgenden einige Anhaltspunkte für eine Entscheidung zu geben.

* Ein Analogsystem ist einfacher aufgebaut. Strom an und die Lok fährt, Spannung höher und die Lok fährt schneller. Es entfallen eine Vielzahl von elektronischen Komponenten, die die Komplexität erhöhen. Falls man seine Verkabelung übersichtlich angelegt hat, ist dadurch die allfällige Fehlersuche sicherlich einfacher. In der Regel genügt ein einfaches Messgerät für Strom, Spannung und Widerstand.
* Eine digitale Modellbahn ist durch die zusätzlich notwendigen Komponenten teuerer in der Anschaffung als eine analoge Modellbahn. Preisgünstige Startsets bieten oft nur einen eingeschränkten Funktionsumfang. Ob das für die eigenen Zwecke ausreichend ist, kann nur jeder für sich selbst entscheiden.
* Bei Digital ist das gemeinsame Spielen mit mehreren Lokführern - z.B. mit den eigenen Kindern - problemlos möglich. Wenn das ihr Ziel ist, sollten sie ein Digitalsystem ernsthaft ins Auge fassen.
* Bei Digital können die Schalter ferngesteuert werden. Sie können daher in der Nähe der zu schaltenden Elemente untergebracht werden. Dadurch verringert sich der Aufwand für die Verkabelung erheblich. Positiver Nebeneffekt ist, dass die Verkabelung dadurch übersichtlicher bleibt.
* Bei Digital ist eine Steuerung per Computer einfacher und preiswerter zu realisieren. Der Anschluss eines Computers ist bei der Konzeption der verschiedenen Digitalsysteme einfach mit vorgesehen worden.
* Ein Automatikbetrieb erfordert in beiden Systemwelten einigen Aufwand. In den verschiedenen Digitalsystemen gibt es keine einheitliche Lösung um eine Lok vor einem Signal anhalten zu lassen (das simple Strom aus ist bei einem Digitalsystem sicher keine angemessene Lösung). Jede Lösung die man wählt führt zu Einschränkungen an einer anderen Stelle (meist bei der Auswahl von Lokdekodern). Je größer die Anlage ist, die man steuern will, umso mehr kommen die Vorteile einer Steuerung mit dem Computer zum Zuge. Und damit hat ein Digitalsystem irgendwann die Nase vorne.

Autoren: Torsten Vogt, Mario Graul, Edbert van Eimeren 
Für die Bereitstellung von Daten bedanken wir uns bei Michael Weiss 

[[Kategorie:Digitalbetrieb]]
[[Kategorie:Einsteiger]]
[[Kategorie:Analogbetrieb]]

Gleiswendel

2008-11-04T16:25:06Z

Michael Oppenauer: /* Eine Gleiswendel für "Bad Knüsselsdorf" */ Link gesetzt

Mit Gleiswendeln läßt sich kompakt an Höhe gewinnen, um z. B. von der sichtbaren Ebene in einen unter der Anlage angeordneten [[Schattenbahnhof]] zu kommen. Dieser Artikel beschreibt, wie man eine Gleiswendel aufbauen kann.

__TOC__

= Eine Gleiswendel für "Bad Knüsselsdorf" =

Bei meiner ehemaligen Anlage "Bad Knüsselsdorf" mußte ein Höhenunterschied von 30cm zwischen Bahnhof und [[Schattenbahnhof]] überwunden werden. Dazu kam nur eine Wendel in Frage, deren Konstruktion ich im folgenden beschreiben möchte.

= Abmessungen =

Der Platz für die Wendel war vorgegeben, mehr als ein Radius von 50cm war nicht unterzubringen. Obwohl ich sonst Flexgleise einsetze, wählte ich hier fertig vorgebogenes Gleis und entschied mich für den ROCO-LINE R4 (48,1cm). Die lichte Höhe zwischen zwei Gängen der Wendel sollte inklusive Gleis ca. 7cm betragen. Bei einer Trassendicke von 1,6cm ergab sich damit eine Höhendifferenz von gut 9cm pro Umlauf, insgesamt also eine Steigung von ungefähr 3%. Die Trassenbretter waren 10cm breit, damit rechts und links neben dem Gleis genügend Platz für die Gewindestangen blieb.

Ein paar Hinweise für die Ermittlung der Abmessungen beim Nachbau:

7cm lichte Höhe reichen bei der Verwendung von Kunststoffgleis sogar für Oberleitungsbetrieb. Natürlich können keine Masten gesetzt werden, aber ein Gleisprofil unter der Trassenunterseite sollte für den sicheren Betrieb genügen. Andererseits sollten 7cm tunlichst nicht unterschritten werden. Es lassen sich zwar beim Dampf- und Dieselbetrieb noch 10-15mm "herauskitzeln", aber dann wird es sehr eng, falls man eines Tages entgleiste Fahrzeuge wieder auf die Schienen setzen möchte. Bei der Dicke der Trassenbretter sind vielleicht noch 5mm drin.

Hier ein paar Beispiele für die resultierenden Steigungen bei unterschiedlichen Abmessungen, die Radien entsprechen dabei dem ROCO-LINE Programm.

{| border="1"
! Lichte Höhe
! Trassendicke
! R2=35,8cm
! R3=42,0cm
! R4=48,1cm
! R5=54,3cm
! R6=60,4cm
|-
|7cm
| 1,6cm
| 3,8%
| 3,3%
| 2,8%
| 2,5%
| 2,3%
|-
|6cm
| 1,6cm
| 3,4%
| 2,9%
| 2,5%
| 2,2%
| 2,0%
|-
|6cm
| 1,0cm
| 3,1%
| 2,7%
| 2,3%
| 2,1%
| 1,8%
|}

Man sollte stets versuchen, die Steigung so gering wie möglich zu halten, also einen möglichst großen Radius zu wählen. Die Steigung sollte 3 % nicht überschreiten, um einen sicheren Betrieb zu gewährleisten. Bei einer 2gleisigen Wendel sollte das nach oben führende Gleis nach Möglichkeit außen liegen (größerer Radius, geringere Steigung).

= Ein solides Fundament =

[[Bild:Gleiswendel helix4.gif|thumb|292px|Die Befestigung mit Gewindestangen geschieht alle 45°.]]
Eine große Platte aus 1,6cm Tischlerplatte diente als Grundplatte für die Gleiswendel. Ich zeichnete die Innen- und Außenkante der Trassenbretter mit einem Schnurzirkel an und legte probehalber einen Schienenkreis aus. Der Kreis wurde in 45 Grad-Segmente unterteilt (und weil ich dann Hunger auf Pizza bekam, machte ich erstmal eine Pause)

Danach wurden die Kanten entlang der Markierungen mit einer Stichsäge ausgesägt. Eine Kante blieb gerade, dort wurde die Wendel später an der Zimmerwand befestigt .

Entlang der 45-Grad Markierungen bohrte ich dann 6mm Paß-Löcher für die Gewindestangen, jeweils 1,5cm von der Außen- bzw. Innenkante entfernt. HINWEIS: An dieser Stelle sollte man die Gewindestangen nach dem ersten Paar Löcher probehalber einfügen und mit dem längsten verfügbaren Fahrzeug Testfahrten durchführen. Ich benutzte dazu einen 26,4m Personenwagen im Längenmaßstab 1/87.

 
= Das Trassenbrett =

[[Bild:Gleiswendel helix2.jpg|framed|Die Preßspanbretter und Sperrholzbretter überlappen an den Stoßstellen, damit keine Knicke entstehen.]]
Das Trassenbrett entstand aus zwei 8mm dicken Holzstreifen. Auf der Unterseite nahm ich Preßspann, nach oben zum Gleis hingegen Sperrholz, da dort die Gleise festgeschraubt werden sollten. Mit Hilfe der fertig geschnittenen Grundplatte machte ich eine Pappschablone und sägte einige Stücke aus den Holzplatten aus. Schließlich baute ich daraus ¾-Kreise zusammen und achtete darauf, daß die Fugen immer versetzt blieben, ähnlich einem Ziegelmauerwerk. Damit vermeidete ich Knicke zwischen den Übergängen. Bei jedem der Teilkreise achtete ich darauf, daß am "unteren" Ende die obere Holzlage hervorschaute und am "oberen" Ende die untere Lage überstand. Beim späteren Zusammenbau (von unten nach oben) überlappt der neue Abschnitt den vorherigen. Schließlich wurden die Teile später immer von oben eingesetzt!. Wenn ein Teilkreis fertig war, befestigte ich das erste Stück des nächsten Abschnittes mit Schraubzwingen daran, um den richtigen Versatz zu bekommen. Genauigkeit ist nicht so wichtig (das ist wiederum wichtig für mich), kleine Lücken von 1-2mm zwischen benachbarten Abschnitten sind nicht problematisch. Nachdem alles fertig war, klemmte ich alles mit Schraubzwingen auf die Grundplatte und bohrte 6mm Löcher durch das ganze Paket, dabei benutzte ich die Löcher in der Grundplatte als Führung. Danach nahm ich wieder alles auseinander und bohrte die Löcher in den Trassenbretter (nicht die in der Grundplatte!) auf 8mm auf, um später genug Spiel für die Feinjustage zu haben. HINWEIS: Vor dem Bohren sollten die Teilstücke sorgfältig ausgerichtet werden!

 
= Aufwärts bitte! =

[[Bild:Gleiswendel helix3.gif|thumb|365px|Die Trassenbretter werden mit Muttern in der Höhe exakt ausgerichtet und befestigt.]]

Ich befestigte die M6-Gewindestangen mit Unterlegscheiben und M6-Muttern an der Grundplatte. Dann fügte ich das erste Teilstück hinzu (dabei sollte man nicht vergessen, zuvor die nötige Anzahl Muttern und Scheiben einzulegen!) und schraubte die Gleise auf die Trasse. Das nächste Trassenbrett nebst nötigen Kleineisen wurde eingesetzt und am vorherigen festgeklebt. SEHR WICHTIG: Das Gleis wurde sorgfältig verlegt und Gleisstöße genau an den Segmentenden vermieden, ggfs. unter Einsatz von ½ Gleisstücken. Nachdem alles montiert war, befestigte ich die Wendel am Anlagenunterbau. Dann war die Feinjustage an der Reihe. Mit Hilfe der Muttern war es einfach, die richtigen Höhen von unten nach oben einzustellen. Ich nutzte die Grundplatte als Referenz, notierte mir die richtigen Höhenmasse und stellte sie mit einem Lineal und Schraubenschlüssel ein. Neben dem sauber verlegtem Gleis ist auch eine gleichmäßige Steigung sehr wichtig für die Betriebssicherheit. Daher kontrollierte ich mehrmals, ob alle Abstände nun wirklich richtig waren..

Vorsichtige Modellbahner können die Muttern jeweils noch mit einer Kontermutter versehen.

 
= Der Abschluß =

[[Bild:Gleiswendel helix1.jpg|framed|Die Gleiswendel wird mit einem abnehmbaren Landschaftsteil überbaut.]]

Bei der Gleisverlegung muß (wie in allen verdeckten Abschnitten) mit besonderer Sorgfalt gearbeitet werden. Vor dem Weiterbau der Anlage müssen umfangreiche Testfahrten stattfinden. Nach dem Überbau mit Landschaft ist die Gleiswendel nur schwerer zu erreichen, um Fehler zu beheben.

Natürlich blieb ein großes Loch in der Mitte der Wendel. Aus den Überresten der Grundplatte baute ich eine abnehmbare Abdeckplatte. Als Ummantelung plante ich Hartfaserplatten, welche sich genügend biegen lassen. Bevor ich jedoch dazu kam, wurde "Bad Knüsselsdorf" wegen Umzug abgebaut. Mittlerweile deutet es sich ab, daß auch "Bad Knüsselsdorf II" mit einer Wendel ausgestattet werden wird. Die alte Gleiswendel läßt sich in Grenzen anpassen: Zusätzliche "Umdrehungen" lassen sich durch Verlängerungen der Gewindestangen ansetzen. Geringe Abweichungen in den Höhenlagen können durch die Muttern eingestellt werden. Das alte Bauteil wird also wahrscheinlich weiter verwendet werden ...

 
----

Der ursprüngliche Autor Frank Forsten pflegt seine Version auf seiner Homepage http://www.forsten-online.de

[[Kategorie:Anlagenbau]]