Automatische Lokanmeldung mit DCC und BiDiB

    DCC wurde zu Beginn als 'Einwegprotokoll' definiert, d.h. Dekoder haben eine Adresse und werden unter dieser Adresse von der Zentrale angesprochen. Speziell auf Vereinsanlagen ist die Verwaltung der Adressen und die Vermeidung von Adresskonflikten eine mühsame Arbeit mit fallweise erforderlicher Umprogrammierung der Dekoder. Auch für den Heimanwender ist eine automatische Anmeldung von Vorteil - Lok auspacken und losfahren.
    Mit BiDi-Funktionalität ('railcom') ist ein Datenaustausch zwischen Zentrale und Lokdekoder möglich, damit ist es dann möglich, ein Verfahren zu installieren, dass dieses Problem löst und auch eine automatische Anmeldung ermöglicht.
    Der folgende Text befaßt sich mit den notwendigen Abläufen und der dafür notwendigen Erweiterungen des DCC Standards bzw. der Rückmelderprotokolle.
    (Hinweis: mit Railcomplus der Fa. ESU gibt es bereits ein Anmeldeverfahren, dieses ist aber proprietär und allgemein verwendbar.)

Voraussetzungen

    Grundlage jeglicher automatischen Zuordnung sind eineindeutige Kennungen der Teilnehmer. Diese gibt in allen entsprechenden Systemen (z.B. MAC-Adresse), im DCC-Umfeld wird diese Kennung mit UniqueID bezeichnet. Die UniqueID der Zentrale ermöglicht es dem Dekoder, die Zentrale zu erkennen unter welcher er betrieben wird. Umgekehrt bietet die UniqueID des Dekoder der Zentrale die Möglichkeit Dekoder zu unterscheiden, auch wenn diese gleichen Hersteller, gleiche Ausführung und gleiche Lokadresse haben. (Auch auf der Rückmelderseite im BiDiBus wird die Adressvergabe der Besetztmelder mit UniqueIDs geregelt.)

    Ausgehend von diesen UniqueIDs wird dann zu Beginn eines Betriebsablaufes (hier wird oft der Begriff 'Session' (=Sitzung) verwendet) eine Zuordnung einer kurzen Adresse vorgenommen und dann während der Sitzung über diese kurze Adresse adressiert. Die bisherige Lokadresse kann diesen Part (Sitzungsadresse) i.d.R. übernehmen.

    Vor Benutzung der Lok und der Zuweisung der Sitzungsadresse braucht man steuerungsseitig viele Information über die Eigenschaften der Lok, um das Fahrzeug möglichst optimal ansprechen zu können. Hierzu zählen Loktyp und Gattung, vorhandene Funktionen, Regelungseigenschaften und Fähigkeiten der Steuerung wie z.B. mögliche unterstützte Protokolle.

    Eine besondere Herausforderung für die Anmeldeprotokolle sind mangelnde Übertragungseigenschaften des Rad-Schiene-Übergangs, eine kurze Unterbrechung darf nicht zu einem sichtbaren Ruckeln führen.

    Notwendig sind sowohl im Downstream (Richtung Lok) als auch im Upstream (Richtung Zentrale) neue Nachrichten: einerseits um den Anmeldevorgang durchzuführen, andererseits um die bei der Anmeldung anfallenden Daten effizient über die vorhandene Kodierungstechnik zu bringen.
    Im Bereich DCC bietet sich hierfür der Bereich 254/255 an: 255 ist IDLE (bzw. wird von ESU für Railcomplus verwendet), 254 könnte alle Anmeldenachrichten einleiten.

Prinzipieller Anmeldevorgang

  1. "Anlagennummer": Die Anlage sendet periodisch ihre UniqueID. Damit kann jeder neu hinzugekommene Dekoder erkennen, ob er an einer ihm bereits bekannten Zentrale (mit dann auch bekannter Sitzungsadresse) betrieben wird oder ob das eine neue Umgebung ist. Falls er eine bis dato unbekannte UniqueID von der Anlage empfängt, kann er die Anmeldung einleiten, quasi 'anklingeln'.
  2. "Klingeln": Zum Einleiten des Anmeldevorgangs antwortet der Dekoder mit einer (railcom)-Nachricht, welche der Zentrale die Anwesenheit eines neuen Dekoders mitteilt ('Hallo-hier-bin-ich'). Diese Nachricht kann theoretisch von mehreren Dekodern parallel abgesetzt werden, man braucht also Techniken, um solche Konflikte erkennen und beheben zu können.
  3. "Türspion": Vereinzelungsphase: Mit Hilfe einer der u.g. Techniken wird nun ein Dekoder 'isoliert', diese Vereinzelung stützt sich auf die UniqueID des Dekoders ab.
  4. "Einlaß": Also letzter Schritt wird dem vereinzelten Dekoder eine Sitzungsadresse zugewiesen. Hier wird sinnvollerweise eine bereits vorhandene Lokadresse weiterverwendet, sofern dies auf der aktuellen Anlage konfliktfrei möglich ist.

Kollisionsauflösung

    Bei mehreren Dekoder, welche sich auf eine Anmeldenachricht hin melden, kommt es zu einer Kollision, diese muß aufgelöst werden. Hierzu muß zuerst der entsprechende Dekoder vereinzelt werden, d.h. durch geeignete Verfahren ist sicherzustellen daß nur ein Dekoder angesprochen wird. Hierzu gibt eine Reihe verschiedener Techniken:
  • Suchbaum: Nach der Erkennung einer Kollision wird eine DCC-Nachricht gesendet, welche nur einen Teil der Dekoder anspricht. Es wird also eine Nachricht gesendet, auf die nur die Dekoder antworten, deren UniqueID größer oder gleich der ausgesendet Test-ID ist: Bei einem binären Suchbaum terminiert die Vereinzelung im schlimmsten Fall nach der Übertragung von 'wortbreite'-Bits. Also z.B. bei einer 36 Bit ID sind als max. 36 Vereinzelungsnachrichten erforderlich.
  • Kollisionsvermeidung: Um das Zeitfenster einer möglichen Kollisionen zu verkleinern, kontrolliert eine Dekoder, ob bereits ein anderer Dekoder sendet. Das würde hier zusätzlichen Hardwareaufwand in den Dekodern bedeuten und kommt daher nicht in Betracht.
  • Dynamisches Backoff: wenn ein Dekoder nach einer Suchanfrage und seiner darauf gegeben 'Hallo-hier-bin-ich'-Antwort keine Bestätigung erhält, so sendet er (mit einer zufällig gewählten Sendepause) bei folgenden Suchanfragen keine Antwort. Dieser Algorithmus terminiert i.d.R. sehr schnell. (siehe auch BiDiB.org, Bereich Support)

Sitzungsadresse zuweisen

    Nach der Dekodervereinzelung wird mit diesem Dekoder eine Adresse vereinbart, unter welcher er auf dieser Zentrale angesteuert wird. Hierzu teilt der Dekoder seinen Wunsch (eben seine bisher gespeicherte Lokadresse) der Zentrale mit. Sofern diese Adresse noch frei ist, wird er auf diese Adresse zugeweisen und betrieben.
    Sollte die gewünschte Adresse schon belegt sein, so wird ihm eine neue Adresse zugewiesen.

    Der Dekoder sollte nun diese Sitzungsadresse zusammen mit der UniqueID der Zentrale abspeichern und weiß fortan, wie er an dieser Zentrale angesprochen wird.

Notwendige Nachrichten

    Zur Durchführung einer solchen automatisierten Anmeldung sind die jeweiligen Nachrichten sowohl auf der DCC-Seite, auf der Decoderseite (railcom) und im Rückmeldersystem (BiDiB) erforderlich.
  • Nachrichten der Lok:
    Railcom überträgt je cutout bis 8 Byte, diese sind 6/8 kodiert (auch den die Railcom Spezifikation da irrtümlich von 4-8-Coding spricht) und bieten 48 Bits Payload. Üblicherweise ist das in zwei Teile (Channel 1 und Channel 2) aufgeteilt. Für die Anmeldung könnte man das bündeln und die 48 Bits komplett verwenden.
    Anmeldenachricht: Wichtig ist hier eine möglichst atomare Nachricht.
    0..3ID15Kennzeichnung Logonnachricht
    4ParityPrüfsumme
    5..7ClassUnterklasse zu Logon, hier 000 = UniqueID
    8..47UniqueID40 Bits, Bestehend aus VendorID, ProduktID und Seriennummer

    Anmeldebestätigung.
    0..3ID15Kennzeichnung Logonnachricht
    4ParityPrüfsumme
    5..7ClassUnterklasse zu Logon, hier 001 = ACK
    8..47Capability40 Bits: zwei Teile: Quittung der erhaltenden Session-Nummer und Mitteilung über verfügbare Eigenschaften, unterstützte Protokolle, Wunschadresse

    Auskunftsnachricht: Wichtig ist hier die Bandbreite, deshalb braucht diese Nachricht die Fähigkeit zu 'streamen'. Darum ist hier auch die CV enthalten. Abgeholt wird das mit 'GET_PROPERTY(i);
    0..3ID14Kennzeichnung Property Stream
    4..15AdresseAuskunftsteil; 'CV-Adresse'
    16..47CV DataInhalt