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

Voraussetzungen

    Grundlage jedlicher automatischen Zuordnung sind eineindeutige Kennungen der Teilnehmer. Diese gibt in allen entsprechenden Systemen (z.B. MAC-Adresse), hier wird diese Kennung mit UniqueID bezeichnet. Die UniqueID der Zentrale ermöglicht es dem Dekoder, die Zentrale zu erkennen unter welcher er betrieben wird. Im Gegenzug bietet eine UniqueID der 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 übernehmen.

    Des weiteren braucht man Nachrichtencodes, um diese UniqueIDs sowie die entsprechenden Antworten übertragen zu können. Für DCC bietet sich da der bisher recht ungenutzte Codebereich der 'Idle'-Nachrichten an, bei BiDiB sind entsprechende Meldungen vorgesehen.

Prinzipieller Anmeldevorgang

  1. "Hausnummer": 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 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.