BiDiB, ein universelles Steuerprotokoll für Modellbahnen

BiDiB - Bidirektionaler Bus - Logo

Inhaltsverzeichnis

1. Allgemeines

1.1. Zielsetzung, besondere Eigenschaften

Das Protokoll BiDiB dient zur Steuerung einer Modellbahn. Es ermöglicht die Kontrolle und Ansteuerung von Loks, Weichen und Zubehör sowie die sichere Übertragung von Rückmelderinformationen aus der Modellbahnanlage an den steuernden Rechner. BiDiB steht für BiDirektionaler Bus und bietet folgende Vorteile:

  • Automatische Hardwarezuordnung, keine Programmierung erforderlich (Plug&Play). Dadurch lassen sich bei modular und/oder veränderlich aufgebauten Anlagen Adresskonflikte sicher vermeiden. Stellwerksdateien sind einfach kopierbar.
  • Weitgehend freie Anordnung von Baugruppen (z. B. Melder, Booster oder Ausgabebausteine), auch kein Verschieben von Melderadressen durch neu hinzugekommene Melderbausteine.
  • Einfache Skalierbarkeit und Erweiterbarkeit durch die vom Protokoll vorgesehene Möglichkeit, Hub-Bausteine zu unterstützen.
  • Extrem schnelle Datenübertragung, durch CRC abgesichert.
  • Überwachung der gesamten Übertragungskette und auch der Rückmeldebausteine selbst durch die zuschaltbare Secure-ACK-Technik. Das garantiert für eine störungsfreie Rückmeldung.
  • Volle Unterstützung BiDi-fähiger Rückmelder durch Übertragung von Adressen, CV-Nachrichten und der Istgeschwindigkeit der Dekoder.
  • Meldung mehrerer Loks in einem Abschnitt.
  • Mischbetrieb normaler und BiDi-fähiger Rückmelder problemlos möglich: man kann damit an wichtigen Stellen (z. B. Eingleiser) BiDi-Melder verbauen, in der sonstigen Anlage jedoch einfachere, normale Melder.
  • Flexibles, offenes Protokoll, zukunftssicher.

Die Graphik illustriert eine typische Anordnung. Das Protokoll ist für verschiedenste Modellbahnsteuerungssysteme von der einfachen Heimanlage bis zur großen Austellungsanlage gleichermaßen geeignet und kann problemlos an die Aufgabenstellung angepasst werden. Hierzu gibt es einen verpflichtenden Satz an Abfrage- und Einstellparametern, die jedes System enthalten muss. Die im folgende verwendeten Bezeichnungen sind im Glossar erläuternd zusammengefasst.

1.2. Ursprung, Geschichte

In 2009 stellten die Firmen Lenz und Tams Rückmeldersysteme für BiDi vor, damit war die Auswertung der bidirektionalen Datenübertragung zwischen DCC-Dekodern und Steuereinheiten theoretisch möglich. Entsprechende Rückmeldersysteme waren zwar angekündigt, aber bis Ende 2010 war nur das einfache Tams RC-Talk im Markt verfügbar. Aus der Diskussion über einen zukunftsfähigen Nachfolger ist dieses Protokoll entstanden. Auf Grund der Leistungsfähigkeit und des stabilen Betriebes wurde dieser wurde dann die Grundlage für einen erweiterten Entwurf, welcher auch Zentralen, Zubehör und Bediengeräte (z. B. externe Stellpulte) umfasst.

An dieser Stelle gilt mein Dank den Diskussionspartnern Hrn. Tams, Hrn. Bluecher und Hrn. Herzog für den konstruktiven Disput.

1.3. Rechtliches, Lizenz

BiDiB® wird von einem Arbeitskreis betreut und (fort-)entwickelt (BiDiB-Implement-Group), diesem gehören neben weiteren Mitgliedern maßgebend die Herren Kersten Tams, Markus Herzog und Wolfgang Kufer an.

Rechtliches: Diese Spezifikation wird bereitgestellt 'wie sie ist', es gibt keine Zusicherung irgendeiner Eignung für irgend einen Anwendungsfall. Damit gibt es auch keine Gewähr oder Zusicherung irgendeiner Funktion oder wirtschaftlichen Verwertbarkeit, jegliche Garantie wird ausgeschlossen. Der Anwender übernimmt die volle Verantwortung bei Verwendung dieser Spezifikation. In keinem Fall kann irgendein Mitglied der BiDiB-Implement-Group für irgendwelche direkten oder indirekten Schäden haftbar gemacht werden. Neben der Möglichkeit des Lizenzentzugs entstehen für den Lizenzgeber keine Haftungsansprüche gegenüber dem Lizenznehmer.

Das Protokoll BiDiB ist für die Verwendung zusammen mit Modellbahnsteuerungssoftware vorgesehen und kann ohne Lizenzkosten sowohl auf der PC-Seite als auch auf der Hardwareseite implementiert werden. Zur Sicherstellung der Kompatibilität sind jedoch folgende Lizenz-Bedingungen einzuhalten.

  • Vor jeder Veröffentlichung oder erstmals geplanten Implementierung in einem neuen Produkt muss der Arbeitskreis BiDiB bzw. Herr Kufer informiert werden. Diese Information wird bis zur Veröffentlichung des Produkts vertraulich behandelt.
  • Der im folgenden beschriebene Funktionsumfang (sofern nicht als optional gekennzeichnet) muss vollständig implementiert sein. Es muss klar angegeben sein, welche Features und Klassen unterstützt werden. (Beispiel: Unterstützung BiDiB Protokollversion x.xx, Belegtmeldung inkl. Adressmeldung und Richtung)
    PC-Programme können Teilfunktionen bei der Implementierung auslassen (Beispiel: die Funktionalität 'Firmwareupdate' kann in Steuerungsprogrammen entfallen). Wenn jedoch eine bestimmte Funktionalität implementiert wird, ist diese allgemeingültig und spezifikationskonform zu implementieren. Ziel muss eine einheitliche Behandlung von BiDiB-Systemen sein.
  • Die verwendeten Herstellerkennungen und Produktkennungen sind zusammen mit einer Kurzbeschreibung des Produkts, der unterstützten Klassen und einem Link auf die Beschreibung des Produktes (Handbuch/Datenblatt) auf bidib.org zu veröffentlichen.
  • Jegliche Erweiterung des Protokollumfangs ist vorher einvernehmlich mit dem Arbeitskreis BiDiB abzusprechen und muss vom Protokoll und von der Referenzimplementierung her offengelegt werden. Diese Einschränkung dient primär der Sicherstellung von Kompatibilität und Eindeutigkeit, nicht zum Blocken von Wettbewerbern oder Verhindern neuer Funktionen.
  • Die Kodierung von Daten, welche über BiDiB übertragen werden, muss offengelegt und frei nutzbar sein. Ausnahmen hiervon sind nur in begündeten Ausnahmefällen zugelassen (z. B. Firmware-Update). Diese Einschränkung dient wie oben primär der Sicherstellung von Kompatibilität und Eindeutigkeit, nicht zum Blocken von Wettbewerbern oder Verhindern neuer Funktionen.
  • Jede Implementierung muss auf den originären Ursprung des Dokuments (-> BiDiB.org) verweisen. Dieser Verweis muss sowohl im Produktprospekt / Datenblatt als auch im Handbuch erfolgen (unabhängig vom Informationsträger).
  • Jede Veröffentlichung an anderer Stelle (auch auszugsweise) bedarf der vorherigen schriftlichen Zustimmung und muss auf den originären Ursprung des Dokuments (-> BiDiB.org) verweisen.
  • Geräte, die BiDiB verwenden, sind mit dem Logo zu kennzeichnen. Dies gilt insbesondere für Schnittstellenbuchsen, auf denen BiDiB implementiert ist. Das Logo und der Begriff BiDiB darf nur nach vorheriger expliziter Zustimmung des Arbeitskreises BiDiB verwendet werden. Auch diese Einschränkung dient nur der Sicherstellung von Kompatibilität, nicht zum Blocken von Wettbewerbern.
  • Geräte und/oder Software, die BiDiB implementieren, sind zur Kompatibilitätsprüfung dem Arbeitskreis auf Verlangen kostenfrei zur Verfügung zu stellen.
  • Der Lizenznehmer verpflichtet sich, die notwendigen Tests zur Interoperabilität seiner Komponenten (sowohl Hardware als auch Software) mit der gebotenen Sorgfalt durchzuführen.
    Im Falle von Kompatibilitätsproblemen sind die entsprechenden Komponenten nachzubessern und alle notwendigen Informationen und Materialien zu durchgeführten Tests und zur Lokalisierung des Problems kostenfrei bereit zu stellen.
    Der Lizenznehmer verpflichtet sich, binnen 2 Monaten die Inkompatibilität zu beheben. Diese Frist kann bei reinen Softwarekomponenten bis zur nächsten Version verlängert werden. Erfolgt keine Fehlerbehebung, so kann die Lizenz für dieses Produkt widerrufen werden.
  • Im Falle von Inkompatibilitäten ist häufig das Zusammenspiel mehrerer Komponenten betroffen. Die beteiligten Parteien sind im ersten Schritt dazu aufgefordert und verpflichtet, miteinander das Problem zu untersuchen und zu klären, warum diese Komponenten nicht miteinander funktionieren.
    Wird dabei keine Einigkeit über die Ursache erzielt, so ist das Problem dem Arbeitskreis BiDiB vorzulegen, der über das weitere Vorgehen entscheidet.
  • Bewusste Verstöße gegen die Lizenzbedingungen haben den Entzug der Lizenz für alle Produkte des Lizenznehmers zur Folge.

1.4. Revisionsstand

Dieses Dokument beschreibt Revision 1.29 von BiDiB, Stand 21.07.2023.

In diesem Dokument ist der grundlegenden Nachrichtenaufbau und die Struktur beschrieben. Nachrichten, welche speziell einem Anwendungsfall (also z. B. Schalten, Melden, Fahren, ...) zugeordnet sind, sind in weiteren Dokumenten bzw. Kapiteln beschrieben.

Revisionsgeschichte
1.292023-07-21 hinzu:
  • FEATURE_GEN_EXT_AVAILABLE für MM erweitert.
  • MAGIC am Ende nicht mehr als [MAGIC], sondern mandatory.
  • BIDIB_ERR_IDDOUBLE mit optional Unique-ID des Knoten.
  • Umlaufkurven für Servo (CONFIGX_BIDIB_PCFG_MOVE_TYPE)
  • Text-Accessories (BIDIB_ACCESSORY_PARA_USES_STRINGS, FEATURE_STRING_NAMESPACES_AVAILABLE, Namensraum 2)
  • Anpassungen Fehlerbehandlung bei MSG_VENDOR
  • DCC-Mapping
  • netBiDiB-0.2: Keepalive, Konkretisierung Logon/Logoff, neu: Anmeldeaufforderung, Statusinformationen BIDIB_LINK_NODE_(UN)AVAILABLE
  • Ergänzungen bei MSG_STRING_GET
  • Bit 6 für Booster State (DCC input)
  • Verteilte Steruerung
  • Neuer Typ "Funkzelle" (cell number) in MSG_BM_POSITION
1.282020-05-31 Protokollversion 0.7⇒0.8: Streaming für Features und Accessorys.
hinzu: Erweiterungen für DCC-Befehle (F29…F68, DCC-SDF, Analogbefehl), Vorbereitung automatische Anmeldung mit DCCA, Abfrage aktiver Loks, Lasttyp-Konfiguration für Ports, Gobale Adressmeldung, Übermittlung von Debugausgaben, Erläuterung zu lokalen Nachrichten
1.272017-04-07 hinzu: Positionsmeldungen, BiDiB-Systemzeit, Porttyp SWITCHPAIR, Konfigurations-Fingerprints, Accessory-Nothalt, Accessory-Details
1.262016-08-15 hinzu: BIDIB_ACCESSORY_PARA_STARTUP, BIDIB_ACCESSORY_PARA_OPMODE. Generelle Überarbeitung, Detaillierung, Übersetzung verbessert.
 2016-02-25 Änderung in der Zubehöransteuerung, hinzu MSG_LC_PORT_QUERY_ALL, Protokollversion 0.6⇒0.7
1.252015-11-28 Änderung der Byte-Reihenfolge von Portadressen im flachen Modell
1.242015-03-22 hinzu MSG_LC_CONFIGX_GET_ALL, flaches Portmodell (siehe Zubehöransteuerung), Protokollversion 0.5⇒0.6
1.232014-12-04 hinzu FLAG_QUERY0, Erläuterungen zu Accessory- und Lokadresse
 2014-11-11 Neue Konfigurationsnachrichten für Ports (CONFIGX*)
 2014-08-14 ergänzende Definitionen für POM (Gleisausgabe)
 2014-07-25 ergänzende Klarstellungen bei der Lizenz
V1.222014-06-26 hinzu: BIDIB_MSYS_SERVOMOVE_QUERY, längere Antworten bei Versionsabfragen
V1.222014-02-07 hinzu: MSG_ACCESSORY_NOTIFY, MSG_BM_DYN_STATE, MSG_CS_PROG, MSG_CS_PROG_STATE
V1.212013-12-16 hinzu: MSG_STRING_GET, _SET, MSG_STRING, FEATURE_STRING_SIZE
V1.202013-11-18 hinzu: Erläuterungen für Drehscheiben; Erläuterung für BIDIB_CS_STATE_GO_IGN_WD
V1.202013-10-29 hinzu: MSG_SYS_GET_UNIQUE_ID verpflichtend für Bootloader, die direkt angesprochen werden
V1.19.12013-10-21 Die Übersetzung Speed – DCC28 – DCC14 (in der Gleisausgabe) wurde auf verpflichtend geändert und eine Formel hierfür festgelegt
V1.192013-10-04 Erweiterung MSG_LC_OUTPUT_QUERY und features FEATURE_RELEVANT_PID_BITS, FEATURE_CTRL_PORT_QUERY_AVAILABLE
new: BIDIB_MSYS_ACC_OKAY_QIN1, BIDIB_MSYS_ACC_OKAY_QIN0, BIDIB_MSYS_ACC_OKAY_NF
V1.182013-07-18 Erweiterung bei SYS_MAGIC (Support für kleine Bootloader). Einführung SecureSwitch – Quittungen bei Weichenfehlern bzw. Handverstellung (Accessory)
 2013-06-29 BIDIB_ERR_OVERRUN als Fehlermeldungen hinzu.
 2013-06-29 Ergänzungen und Klarstellungen bei den Lizenzbedingungen
V1.172013-06-18 Einführung eines Watchdogs für DCC-Erzeugung, FEATURE_GEN_WATCHDOG neu dazu
V1.162013-06-02 Erläuterungen bei MSG_SYS_RESET, FEATURE_CTRL_STRETCH_DIMM neu dazu
V1.152013-04-20 Übermittlung von Fehlercodes bei Accessory
V1.142013-04-02 Einheitliche Definition von Accessory Schaltzeit
V1.132013-03-25 MSG_LOCAL_LOGON_REJECTED neu dazu; für Fehlerbehandlung bei zu vielen Teilnehmern
V1.122013-02-23 MSG_BOOST_CURRENT wird durch MSG_BOOST_DIAGNOSTIC ersetzt.
V1.112013-01-30 MSG_BOOST_ON bzw. _OFF mit einem Parameter ergänzt
V1.102013-01-23 MSG_CS_BIN_STATE ergänzt
V1.092013-01-17 FEATURE_BST_INHIBIT_AUTOSTART ergänzt
V1.092012-12-21 Erläuterungen bei MSG_CS_DRIVE_ACK; MSG_BOOST_QUERY ergänzt
V1.082012-11-13 Erläuterungen und finale Kodierung bei MSG_BM_SPEED, FEATURE_BM_ISTSPEED_INTERVAL
V1.072012-10-12 Ergänzung mit der Class Accessory, Parameter bei MSG_STALL; Erläuterungen bei MSG_CS_DRIVE
V1.062012-09-26 Class Zubehör: MSG_LC_WAIT dazu, Rechtschreibkorrekturen.
V1.052012-09-24 Class Belegtmeldung: Zusätzliche Befehle MSG_BM_GET_CONFIDENCE und MSG_BM_CONFIDENCE.
V1.042012-07-25 Zusätzliche Erläuterungen bei MSG_VENDOR*. MSG_SYS_PING / MSG_SYS_PONG haben einen Parameter erhalten
Ergänzungen bei Class Schalten: BIDIB_MACRO_RESTORE, BIDIB_MSYS_DELAY_RANDOM, MACRO_PARA jetzt 32 Bit.
V1.032012-07-25 Zusätzliche Erläuterungen bei MSG_VENDOR*.
V1.022012-06-06 Erläuterung bei MSG_NODE_LOST korrigiert.
V1.012012-03-19 MSG_FEATURE_GETALL, MSG_FEATURE_GETNEXT, MSG_NODETAB_GETALL, MSG_NODETAB_GETNEXT, Übertragungsverfahren für Features und Nodes erläutert.
V0.132012-02-21 MSG_BM_ADDRESS mit der Möglichkeit, mehrfache Belegung zu melden. Hinweis bei MSG_BM_SPEED.
V0.122011-07-20 Lokale Befehle für PING und PONG neu dazu; MSG_BM_MIRROR_OCC und _FREE neu dazu.
V0.112011-07-20 Neue feature-Parameter für Booster, Systemzeit, MSG_BOOST_STAT Meldungen erweitert. Stromeinstellung für Booster dazu.
V0.102011-04-02 Vorschläge für Dekoderanmeldung ergänzt, neue Message MSG_BM_BLOCK_CV für das blockweise Lesen von CVs.
V0.092011-02-24 Änderungen bei der NODE_TAB (falls keine Unterknoten), weitere Fehlercodes hinzu.
MSG_SYS_GET_ERROR dazu.
V0.082010-12-20 Boosterklasse ergänzt.
V0.072010-12-07 Erläuterungen bei Vendor config, V_VALUE dazu; Fehlermeldung erweitert; MSG_SYS_MAGIC mit index 0; Enable /Disable mit auto-forward auf Unterknoten. BM_MSG für Accessory dazu.
MSG_SYS_IDENTIFY_STATE dazu.
V0.062010-12-06 Erläuterungen bei NODE_CHANGE dazu
V0.052010-12-01 Unique-ID erläutert, PKT_CAPACITY neu dazu, ClassID dazu
V0.042010-11-29 Paketaufbau für Routing optimiert, Feinabgleich.
neu dazu: MSG_BM_SET_SIZE, MSG_BM_GET_SIZE
V0.032010-11-25 Erweiterung für Hubs und Sub-Knoten.
V0.022010-11-17 Erweiterung für heterogene Rückmeldermodule, Individualisierung des Featuresets auf einzelne Module
V0.012010-11-03 Initiales Dokument

1.5. Design-Grundlagen

BiDiB ist als zustandsloses Protokoll angelegt. Für Nachrichtenverluste existieren diverse Sicherungsmechanismen.

Die wichtigste Eigenschaft, um eine hohe Fehlertoleranz zu erreichen, ist die Idempotenz der Nachrichten. Im Allgemeinen übertragen Nachrichten nur Zustände, keine Kommandos oder Befehle. Ihr Empfang wird vom Knoten üblicherweise mit einer Nachricht selben Inhalts quittiert. Damit kann im Fehlerfall die Übertragung einfach wiederholt werden, ohne bei Mehrfachempfang ungewollte Aktionen auszulösen. Dies gilt insbesondere für die kritischen Modellbahn-Anwendungen Fahren, Schalten und Melden. Auch wird etwa bei sequentieller Übertragung in mehreren Nachrichten stets ein Identifier verwendet, mit dem eine verlorene Information erneut angefordert werden kann.

Kommunikationsfehler hingegen werden nur einfach gemeldet und nicht wiederholt, um die Implementierung zu vereinfachen. Ein Verlust einer Fehlermeldung ist mit dem Ausbleiben der erwarteten Antwort gleichzusetzen. Treten mehrere Fehler zugleich auf, können diese in einer Liste zum Abholen bereit gestellt werden, müssen aber nicht wiederholt werden. Bleibt ein Fehler erhalten, wird er beim nächsten Versuch das Objekt zu benutzen nochmals gemeldet. Die Behebung eines Fehlers wird in der Regel nicht gemeldet. Ausnahmen hiervon bilden Objekte, bei denen Störungen/Fehlerzustände intrinsisch sind (z. B. Booster und Accessorys), für diese kann Speicherung oder Wiederholung vorgeschrieben sein.

Ebenso verfahren wird bei spontanen Ereignissen, die nicht betriebsrelevant sind. Ein Verlust solcher Nachrichten kann nur durch die Überprüfung der Sequenznummern erkannt werden, es existiert aber keine vorgeschriebene Fehlerbehandlung und keine Wiederholmöglichkeit. Für betriebskritische Ereignisse (Belegtmeldungen, Accessory) gibt es mit Secure-ACK und Secure-Switch auch Quittungsverfahren zur Absicherung.

Die Fortentwicklung von BiDiB ist im Protokoll fest verankert. Bei neuen Revisionen der Spezifikation wird streng auf Rückwärtskompatibilität geachtet. Erweiterungen des Funktionsumfangs sind meist leicht möglich, da diese üblicherweise optional sind und ignoriert werden können. Bei nicht rückwärtskompatiblen Änderungen wird die Protokollversion angehoben, welche von jedem Knoten abgefragt werden kann. Dies erlaubt die Unterstützung veralteter Implementierungen und gewährleistet in gewissem Maße auch die Kompatibilität mit noch unbekannten Funktionen.

1.6. Glossar

In diesem Dokument werden folgende Bezeichnungen für die einzelnen Protokollteilnehmer oder Eigenschaften verwendet:

BiDiB: Der Protokollstandard, also die Art und Weise, wie Nachrichten kodiert sind.
BiDiBus: Eine mögliche physikalische Implementierung einer Busebene, speziell für die Verbindung innerhalb einer Modellbahn geeignet. BiDiBus basiert auf RS485 und verwendet RJ45 Kabel.
Bussystem: Der gesamte Aufbau, bestehend aus Interface und Knoten (z. B. Meldern) und evtl. notwendiger interner Verbindungen, auch mehrere Ebenen umfassend.
Class: Knoten sind hinsichtlich Ihrer prinzipiellen Eigenschaften in Klassen eingeteilt. Es gibt z. B. Belegtmelder, DCC-Erzeuger, Schaltausgabe, Bedienpulte.
Feature: Eine bestimmte Eigenschaft eines Knotens (wie z. B. 'Melder kann Lokrichtung erkennen'). Ein Feature kann individuell je Knoten abgefragt oder konfiguriert werden.
Host: Der steuernde Computer, i. d. R. ein PC mit entsprechender Software. Aus Sicht des BiDiB-System diejenige Instanz, von welcher das erste Interface seine Befehle erhält.
Hub: Ein Knoten auf einer Busebene, welcher zugleich Interface für eine nachgeordnete Ebene ist.
Interface: Die Stelle in einer Ebene (Struktur) des Bussystems, welche mit dem Host oder dem übergeordnetem Knoten kommuniziert.
Knoten: Ein Teilnehmer im Bussystem, also die (fallweise verteilte) Hardware. Ein Teilnehmer auf einer Ebene kann auch Interface für die nächsttiefere Ebene sein (Hub-Funktion).
Logon: Der Versuch eines Teilnehmers, eine logische Verbindung zu einen Interface aufzunehmen. Die Verbindung wird bestätigt und der Host über diesen neuen Knoten benachrichtigt.
Melder: Ein Knoten des BiDiB-Systems, welcher die Gleisbelegung erfasst und BiDi-Rückmeldung auswertet.
Node-Adresse: Die von Interface nach der automatischen Anmeldung vergebene Nummer (byte), unter welcher der Knoten (auf dieser Ebene) in dieser Sitzung angesprochen wird. (NODE_ADDR)
Magic: (System-ID) Eine (an sich bedeutungslose) Nummer, die bei Starten des Interfaces von Host abgefragt werden muss und anhand der z. B. die richtige Baudeinstellung erkannt werden kann.
Unique-ID: Die global eineindeutige Kennung eines Knotens. Sie enthält die angemeldeten Klassen, die Herstellerkennung, und eine aus der Hardware-ID abgeleitete herstellerspezifische Nummer.

1.7. Prinzipien der Knotenzuordnung, Adressierung

Ein mit BiDiB angesprochenes System ist baumartig organisiert: Der Host sieht ein Interface, mit dem er eine Kommunikationsverbindung aufbaut. Das Interface ermöglicht ihm Zugang zu einer (flachen) Anordnung aus Knoten. Jeder dieser Knoten ist in der Regel ein Baustein, der eine oder mehrere bestimmte Funktionen beinhaltet (z. B. ein Melder mit Rückmeldekontakten). Es ist aber auch möglich, dass dieser Baustein selbst auch nur ein Interface ist, hinter dem sich eine weitere Struktur befindet (so wie ein Unterordner). Dadurch erreicht man eine große Flexibilität sowohl in den Verdrahtungsmöglichkeiten als auch in der möglichen Heterogenität der angeschlossenen Busknoten.

BiDiB verfügt über eine automatische Adressvergabe der Knoten. Hierbei ist jedem Knoten herstellerseitig eine eindeutige Nummer einprogrammiert, die Teil der Unique-ID ist. Beim Einschalten des BiDiB-Systems werden vom Interface innerhalb seiner Struktur die vorhandenen Knoten gesucht und ihnen eine lokale Adresse zugewiesen, diese lokale Adresse ist ein Byte lang. Das Interface erstellt dabei eine Liste aus verfügbaren Knoten, ihrer Unique-ID und ihrer lokalen Adresse. Knoten selbst können wieder Interfaces sein, so dass insgesamt eine Baumstruktur entsteht. Jeweils eine Verzweigung hat Kenntnis über die Knoten direkt nach der Verzweigungsstelle. Die maximale Adresslänge innerhalb des Baumes ist 4 Byte.

Diese Zuordnungstabelle ist bei jedem Start unterschiedlich und wird auch automatisch erweitert, wenn ein neuer Knoten auf den Bus aufgesteckt wird. Das Interface schickt in diesem Fall eine entsprechende Nachricht an den Host. Wenn ein Interface aus dem System entfernt wird (z. B. Abstecken eines Hubs), so sind implizit auch alle Knoten hinter diesem Interface nicht mehr erreichbar.

Host-intern sind die Knoten (neben den programm-internen Dingen wie z. B. Bildschirmposition und Knotenname) auch mit ihrer jeweiligen Unique-ID abgelegt. Der Host holt sich nun beim Systemstart die Zuordnungstabelle vom Interface und bekommt daraus die für diese Sitzung gültigen lokalen Adressen, die zu diesen Unique-IDs gehören. Die Zuordnung vom Objekt auf der Bedienoberfläche zur Modellbahn-Hardware erfolgt also letztendlich über die Knotenidentität und ist damit nicht von der aktuellen Adressvergabe abhängig.

Um den Austausch eines Knotens zu ermöglichen, soll in Hostprogrammen darauf geachtet werden, dass die einem Knotenobjekt zugewiesene Unique-ID leicht durch eine andere ersetzt werden kann. Da die Unique-ID einer Baugruppe nicht vom Anwender eingestellt werden kann, kann er den Ersatzknoten nicht auf die "alte Adresse" programmieren um die im Programm konfigurierte Zuordnung weiterzuverwenden; stattdessen ist es erforderlich die Änderung in der Hostsoftware vorzunehmen. Der Tausch der Unique-ID wird etwa nötig beim Ersetzen defekter Baugruppen durch baugleiche Hardware, bei der Erweiterung um mehr Ausgänge durch Verwendung eines überlegenen Produkts, oder beim Aufspielen einer anderen Produktfirmware die mehr Funktionen anbietet.

Wie funktioniert die erstmalige Eingabe bzw. Zuordnung der Knoten?
Wenn der Host beim Einlesen der Zuordnungstabelle einen (oder mehrere) Knoten findet, die noch nicht in seinem Gleisbild enthalten sind, so kann er diese in einem Topf 'neu verfügbare Melder / Zentralen / Booster usw.' darstellen. Man kann dann z. B. auf der Knotenhardware durch Tastendruck ein Blinken der Belegtmeldung (bzw. Identify) auslösen und kann das so leicht im PC auf den richtigen Gleisabschnitt zuordnen.
Was passiert, wenn z. B. ein Knoten mit Besetztmeldefunktion ausfällt oder getauscht wurde?
Wenn der PC beim Einlesen der Zuordnungstabelle für einen bereits konfigurierten Besetztmelder die Unique-ID nicht findet, so kann er eine Fehlermeldung ausgeben. Sollte parallel ein neuer Melder erscheinen, könnte das Programm auch gleich nachfragen, ob dieser neue Melder den alten ersetzt.

2. Physikalische Implementierung

Das Protokoll BiDiB ist als Protokoll für verschiedene Übertragungsmedien wie z. B. Serielle Verbindung, USB, RS485, Ethernet oder Wireless geeignet (mit dann jeweils angepasstem Framing). Entsprechende Spezifikationen sind den jeweiligen Dokumenten zu entnehmen.

Die jeweilige Übertragungsschicht sorgt für das korrekte Framing und den byteweisen, transparenten Transport von BiDiB-Nachrichtenpaketen. Generell muss die Übertragungsschicht den Transport der Daten mit einer CRC absichern. Die Übertragungsschicht muss mindestens in der Lage sein, Nachrichten mit einer Größe von 64 Bytes zu transportieren.

CRC bezeichnet ein Prüfsummenverfahren. Bei einigen physikalischen Implementierungen wird CRC8 verwendet: Auf der Senderseite wird das gemäß Polynom x8 + x5 + x4 + 1 über das Paket gebildet, beginnend beim ersten Byte des Paketes, Init=0, nicht invertiert. Empfängerseitig wird die CRC mit dem gleichen Polynom über das gesamte Paket inkl. CRC gebildet, das Ergebnis muss 0 sein.

3. Protokollbeschreibung

3.1. Prinzipieller Nachrichtenaufbau

Eine MESSAGE hat folgenden Aufbau:

MESSAGE ::= MSG_LENGTH  MSG_ADDR  MSG_NUM  MSG_TYPE  DATA
MSG_LENGTH ::= 0x00 | … | 0x7f
MSG_ADDR ::= MSG_ADDR_STACK  0x00
MSG_ADDR_STACK ::= ε | NODE_ADDR  MSG_ADDR_STACK
NODE_ADDR ::= 0x01 | … | 0xff
MSG_NUM ::= 0x00 | … | 0xff
MSG_TYPE ::= 0x00 | … | 0xff
DATA ::= ε | ANY_BYTE  DATA
ANY_BYTE ::= 0x00 | … | 0xff

Ein Nachricht besteht als aus der Länge, einer Adressenangabe, einer (fortlaufenden) Nachrichtennummer, einer Typangabe und optionale Parameter. Diese Felder sind nachfolgend erläutert:

  • MSG_LENGTH besteht aus einem Byte und gibt die Nachrichtengröße in Bytes an. Hierbei wird die Länge ab erstem Byte der MSG_ADDR bis zum Ende des DATA-Feldes angegeben. Ein Nachricht, die nur aus Adresse 0, MSG_NUM und MSG_TYPE besteht, hat also die Länge 3. Wertebereich 0…127, MSB ist reserviert.
    Anmerkung: sollte bei einer zukünftigen Erweiterung eine Vergrößerung der Nachrichten erforderlich werden, so kann über das reservierte MSB eine Erweiterung vorgenommen werden, z. B. gemäß folgender Regel: Ist das erste Byte im MSG_LENGTH-Feld kleiner 128, dann besteht das MSG_LENGTH-Feld nur aus einem Byte. Ist das MSB im ersten Byte des MSG_LENGTH-Feldes gesetzt, so errechnet sich die Länge zu: (Erstes Byte & 0x7F) * 128 + (zweites Byte & 0x7F); Im 2. Byte darf das MSB nicht gesetzt sein.
  • MSG_ADDR bezeichnet die zugewiesene Ziel- oder Quelladresse dieser Nachricht. MSG_ADDR besteht aus 1 bis 5 Bytes, jedes Byte definiert die lokale Adresse (NODE_ADDR) auf einer Ebene. Das letzte Byte von MSG_ADDR ist immer 0. Es sind damit max. 4 Adressbytes von 0 verschieden.
    Wenn die MSG_ADDR gleich 0 (also der MSG_ADDR_STACK leer) ist, dann adressiert die Nachricht direkt das Interface bzw. den Knoten. Wenn die MSG_ADDR ungleich 0 ist, dann wird derjenige Knoten hinter dem Interface adressiert, dessen lokale Adresse der ersten NODE_ADDR entspricht. In diesem Fall schickt ein Interface die Nachricht entsprechend weiter, dabei wird der MSG_ADDR_STACK vorn um ein Byte gekürzt. Umgekehrt wird bei Nachrichten, welche von einem weiter unten liegenden Knoten erhalten wurden, dessen lokale Adresse vom Interface vorne angefügt.
  • MSG_NUM bezeichnet einen durchlaufenden Nachrichtenindex, der bei jeder Nachricht um eins hochgezählt wird. Die 0 wird dabei übersprungen (1,2,...,255,1,2,...). Der Empfänger kann die MSG_NUM prüfen und kann so feststellen, ob ihm eine Nachricht verloren gegangen ist. Für den Fall des Nachrichtenverlustes liegt es im Ermessen des Empfängers, wie er reagiert. Der Wiederanlauf erfolgt mit den Befehlen des Protokolls, ein Retransmit/Rewind einzelner Nachrichten ist nicht vorgesehen.
    Beispiel: In der Regel wird der Empfänger alle Belegtzustände erneut anfordern bzw. bei aktivierter Secure-ACK-Technik erfolgt die Wiederholung automatisch.
    Wenn die MSG_NUM mit Wert 0 übertragen wird, so erfolgt keine Überprüfung der Sequenz, eine entsprechende Fehlermeldung darf nicht erfolgen. Die 0 setzt auch gleichzeitig die Sequenz im Empfänger zurück, nach der 0 kann dann mit dem durchlaufenden Nachrichtenindex bei 1 begonnen werden.
    Bei Broadcast-Nachrichten und bei lokalen Nachrichten (MSG_LOCAL_*) wird die MSG_NUM komplett ignoriert, sie ist mit 0 zu belegen.
  • MSG_TYPE: Ein Byte, welches den Nachrichten-Typ kodiert und damit prinzipiell festlegt, welche Art von Nachricht hier vorliegt und wie die Richtung ist.
    Zur schnelleren Dekodierung sind die Nachrichtentypen in Gruppen zusammengefasst:
    0x00Offset für Downlink Nachrichten
    0x80Offset für Uplink Nachrichten
    0x00Offset für System Nachrichten
    0x10Offset für Feature und User Nachrichten
    0x20Offset für Rückmelder Nachrichten
    0x30Offset für Booster Nachrichten
    0x38Offset für Accessory, Switch, Makro Nachrichten
    0x60Offset für DCC-Generator Nachrichten
    0x70Offset für lokale Nachrichten (mit besonderen Regeln, s.u.)
    Die exakten Kodierungen der Nachrichten sind der Datei bidib_messages.h zu entnehmen, welche allen Lizenznehmern zur Verfügung steht.
  • DATA: je nach MSG_TYPE folgen hier die weiteren Parameter der Nachricht. Als DATA sind alle Bytes 0…255 zugelassen.

Die Sicherung der Daten gegen Übertragungsfehler ist Sache des jeweiligen Transportmediums (wie z. B. CRC im Fall der seriellen Übertragung). Das Protokoll selber sieht keinen Message-Retransmit vor, kritische Nachrichten werden auf höherer Ebene abgesichert (z. B. mit Secure-ACK oder entsprechender Antwort des Knotens).

Die Nachrichtenlänge (MSG_LENGTH) dient nicht nur der Begrenzung der Nachricht bei mehreren aufeinanderfolgenden, sondern gibt auch an wie viele DATA-Bytes tatsächlich in der Nachricht als Parameter zur Verfügung stehen. Dies können durchaus mehr oder weniger Bytes sein als der Nachrichtentyp vermuten lassen würde. Hiermit lassen sich optionale Parameter realisieren, die bei Nichtvorhandensein mit Vorgabewerten belegt werden. Werden weniger Parameter als nötig gesendet, antwortet der Knoten mit einer Fehlermeldung. Werden mehr Parameter als erwartet gesendet, so werden die überschüssigen Bytes ignoriert; dies garantiert Vorwärtskompatibilität.

Eine Nachricht kann bis zu 64 Bytes lang sein (MSG_LENGTH=63), alle Transportschichten müssen dies unterstützen. Längere Nachrichten im Downstream können, sofern von der jeweiligen Transportschicht und dem Knoten unterstützt, pro Knoten mittels der Nachricht MSG_PKT_CAPACITY erlaubt werden. Um eine lange Nachricht an einen Knoten zu senden, müssen auch alle Interfaces im Transportpfad dies unterstützen. Längere Nachrichten im Upstream sollen sich an der im Downstream verwendeten Länge orientieren.

3.2. Routing

BiDiB ermöglicht es, Teilnetze zu verdrahten und diese (ähnlich wie bei USB) über Hubs baumförmig aufzubauen. Dies erlaubt die Skalierbarkeit für größere Modellanlagen, für kleinere Anlagen wird man nur ein Netz aufbauen und kann daher die Ausführungen in diesem Kapitel erst mal überspringen. Wie sich die Teilnetze über die lokale Adresszuordnung einigen, wird in einem weiteren Dokument beschrieben – für die Protokollbeschreibung hier sind nur die Ergebnisse dieses Vorgangs relevant.

Zugelassen sind max. 4 kaskadierten Netze. (Diese Beschränkung soll vor allem Hostimplementierungen erleichtern, dadurch ist die jeweilige aktuelle lokale Adresse eines Endknotens auf 32 Bit beschränkt.)

Hierbei gelten folgende Regeln für das Routing der Nachrichten:

  • Downstream: Ein Knoten, der eine MESSAGE empfängt, prüft die Zieladresse der Nachricht: diese enthält seine lokale NODE_ADDR in der aktuellen Struktur, evtl. gefolgt von weiteren Subadressen. Ist das nächste Byte ungleich 0 (noch zu MSG_ADDR_STACK gehörend), so stellt es eine Subaddresse dar, und der Knoten schickt die MESSAGE an den untergeordneten Knoten weiter, jedoch um das erste Byte (nämlich seine eigene NODE_ADDR) verkürzt.
    Ist das nächste Byte hingegen gleich 0 und der MSG_ADDR_STACK leer, so ist der Knoten selbst adressiert.
    Bei Broadcast-Nachrichten ist der MSG_ADDR_STACK immer leer.
  • Upstream: Ein Knoten, welcher von einem Unterknoten eine MESSAGE empfängt, fügt zur Nachricht die lokale Adresse (NODE_ADDR) des Unterknotens hinzu, und reicht diese dann an sein Interface weiter.

Damit der überordnete Knoten respektive der Host diese Struktur erfassen kann, gibt es entsprechende Befehle:

  • MSG_NODETAB_GETALL, MSG_NODETAB_GETNEXT: Mit diesen Befehlen werden die einem Knoten zugeordnetem Unterknoten abgefragt.
    Der Knoten beantwortet diese Abfrage mit einer MSG_NODETAB_COUNT (gibt die Größe der Tabelle an), die einzelnen Tabelleneinträge werden mit einer MSG_NODETAB_GETNEXT angefordert, was jeweils mit einer Nachricht MSG_NODETAB beantwortet wird. Hat der Knoten keine Unterknoten, so ist die Länge der Knotentabelle 1 und der einzige enthaltene Eintrag ist der Knoten selbst.
    Nach dem Power-Up gesendet, wenn die Buszuteilung in der Unterknotenstruktur noch nicht abgeschlossen ist, wird die Abfrage mit MSG_NODETAB_COUNT = 0 beantwortet. Erst wenn die Unterknotenstruktur stabil geworden ist, soll die Anfrage nach der Knotentabelle beantwortet werden. Damit werden häufige Nachrichten über Zustandsänderung zu Beginn vermieden.

Ändert sich die Zuordnungstabelle im laufenden Betrieb (z. B. durch an- oder abstecken), so sendet das Interface von sich aus eine MSG_NODE_LOST oder MSG_NODE_NEW Nachricht. Diese Message muss mit MSG_NODE_CHANGED_ACK quittiert werden (oder die Knotentabelle wird komplett abgefragt). Sowohl die Nachrichten für MSG_NODE_LOST, MSG_NODE_NEW und MSG_NODE_CHANGED_ACK haben als Parameter die (durchlaufende) Versionsnummer (der Tabelle). Damit wird sichergestellt, dass keine Änderungen der Busstruktur übersehen werden.

Veränderungen der Knotentabelle während der Übertragung soll das Interface vermeiden (z. B. keine Logon-Aufforderung aussenden). Erfolgt doch eine Veränderung der Knotentabelle, während diese mit MSG_NODETAB_GETNEXT abgefragt und übertragen wird, so soll das Interface einfach die Übertragung wieder von vorne mit einer neuen MSG_NODETAB_COUNT (aber mit einer um eins inkrementierten Versionsnummer) beginnen.

3.3. Unique-ID

Jeder Knoten hat eine eindeutige Nummer, die Unique-ID. Die Unique-ID besteht aus 7 Bytes:

Aufbau der Unique-ID
1. Byte ClassID

Hierbei handelt es sich um ein Bitfeld, welches die prinzipielle Klassenzugehörigkeit eines Knotens angibt. Ein Knoten darf auch mehreren Klassen zugleich angehören.

Die Klassen dienen dem Host zur schnellen Orientierung darüber, welche Funktionen auf diesem Knoten zu finden sind. Für das Auffinden von Teilfunktionalitäten mittels Features genügt es, sich nur diejenigen Knoten ansehen welche das entsprechende Klassenbit gesetzt haben.

Wenn ein Knoten Befehle einer bestimmten Klasse implementiert hat, so muss er auch das entsprechende Class-Bit gesetzt haben. Umgekehrt muss er die entsprechenden Befehle der gemeldeten Klassen kennen und korrekt beantworten. Selbst wenn in der aktuellen Konfiguration keine Objekte verfügbar sind, soll er die Klasse anmelden und 0 als Anzahl zurückgeben.

Bit 71: Knoten enthält Sub-Knoten (ist also selbst ein Interface)
Bit 61: Knoten enthält Besetztmelderfunktionen
Bit 51: Knoten enthält Bedienfunktionen, Gast
Bit 41: Knoten enthält DCC-Signalerzeugung für Fahren, Schalten
Bit 31: Knoten enthält DCC-Signalerzeugung für Programmieren
Bit 21: Knoten enthält Accessory-Stellfunktionen
Bit 11: Knoten enthält Booster-Funktionen
Bit 01: Knoten enthält Zubehör-Schaltfunktionen, wie z. B. Lichtanimation
2. Byte ClassID-Erweiterung
Bit 7…6reserviert
Bit 01: Knoten enthält Gastgeberdienste

Reservierte Bits sind als 0 zu kodieren.

3. Byte Vendor-ID:

Hier wird die gleiche Kodierung wie bei DCC verwendet, siehe NMRA Manufacturer ID Numbers.

Virtuelle Knoten verwenden die VID 0.

4.-7. Byte Produktkennung, bestehend aus 4 Bytes

Diese 4 Byte = 32 Bit unterteilen sich in Produkttyp-Kennung und eine Seriennummer, damit Hostprogramme und Analysewerkzeuge die jeweiligen Knoten leichter identifizieren können. Die Aufteilung, wie viel Bits Produkttyp kodieren und wie viele Bits die Seriennummer kodieren, liegt im Ermessen des Herstellers und wird über das Feature FEATURE_RELEVANT_PID_BITS festlegt. Eine Aufteilung 16Bits/16Bits wird empfohlen. Die Produkttyp-Kennung beginnt immer bei ersten Byte, Bit 0 (BiDiB ist immer little-endian (low-byte first) kodiert).

Fehlt das Feature FEATURE_RELEVANT_PID_BITS, so erfolgt die Aufteilung 16 Bit / 16 Bit.

Die Eindeutigkeit der Produktkennung (und damit der Unique-ID) wird vom jeweiligen Hersteller über die fest einprogrammierten Seriennummern garantiert. Weder Unique-ID noch Produktkennung stellen dabei allerdings eine feste Hardwarekennung dar, ein und dieselbe Baugruppe kann mit verschiedenen Firmwares bespielt werden zwischen denen sich die Klassen oder gar die Produkttypen unterscheiden können. Nur die Seriennummer bleibt dabei in der Regel gleich, alleine ist diese aber nicht nötigerweise eindeutig.

Darstellung der Unique-ID in Hostprogrammen / Aufklebern / Tools:
Damit die Anwender Baugruppen im Ernstfall leichter zuordnen können, wird eine einheitlich Darstellung der Unique-ID empfohlen. Diese soll Vendor-ID abkoppeln und das 4. bis 7. Byte (in dieser Reihenfolge) als Hex darstellen.
Beispiele:
  • VID 0D PID 0278456B
  • Vendor: Public Domain & Do-It-Yourself Decoders, Product ID 0x0278456B

Zusätzlich kann es in den Knoten die Möglichkeit geben, einen benutzerspezifischen Knoten-Kurznamen (siehe MSG_STRING) zu hinterlegen. Dieser kann alternativ für die Darstellung verwendet werden und ermöglicht dem Endanwender einen leichtere Migration von Konfigurationsprogrammen zu Fahrprogrammen.

3.4. Typischer Protokollstart

Beim Verbindungsaufbau mit einen BiDiB-System kann man gemäß folgender Liste vorgehen:

  1. Verbindungsaufbau mit dem ersten Knoten (i. d. R. das Interface).
    Beispielsweise bei einem seriellen Interface schickt der Host zwei MAGIC-Zeichen, gefolgt von einer MSG_SYS_GET_MAGIC Nachricht. Dies probiert man auf den möglichen Baudraten und testet, ob eine fehlerfrei Antwort kommt. Als timeout reichen hier 200ms.
  2. Anhalten des BiDiB-Systems.
    Durch Senden von MSG_SYS_DISABLE wird das spontane Übermitteln von Nachrichten unterbunden. Dieses Anhalten dient primär dazu, dass man bei der folgenden Auslesephase nicht von Spontanmeldungen unterbrochen wird.
    Alternativ kann man das System auch mit einer MSG_SYS_RESET zu einem erneuten Start und kompletten Neuanmelden der Knoten veranlassen.
  3. Jetzt liest man die Eigenschaften des ersten Knotens ein.
    Wesentlich sind hierbei die Antworten auf MSG_GET_SYS_MAGIC, MSG_SYS_GET_P_VERSION und die Class-Bits der Unique-ID, diese geben an, welche prinzipiellen Eigenschaften der Knoten hat und welche Nachrichten er unterstützt.
    Sollte es sich beim Knoten um ein Interface handeln, lässt man sich die Knotenliste (MSG_NODETAB_GETALL) geben. Des weiteren kann man sich von diesem Knoten alle Features (MSG_FEATURE_GETALL) und alle sonstigen Informationen geben lassen.
    Dabei ist zu beachten, dass man je Knoten nur so viele Abfragen 'auf Vorrat' zugleich schicken darf, dass die zu erwartende Antwortgröße 48 Byte nicht übersteigt.
    Unterstützt ein Knoten Konfigurations-Fingerprinting, kann man mit der Antwort auf MSG_SYS_GET_UNIQUE_ID auch schnell überprüfen ob die Knoteneinstellungen noch den bereits bekannten entsprechen.
  4. Weitere Knoten.
    Wenn weitere Knoten gemeldet wurden, so wiederholt man den Schritt 3 für alle Knoten, welche man in der Knotenliste erhalten hat. Sollte bei diesen Knoten wieder ein Interface enthalten sein, so wird auch dieses Interface nach seiner Knotenliste befragt.
    Dabei kann man durchaus mehrere Knoten parallel bearbeiten und z. B. für jede MSG_FEATURE gleich ein MSG_FEATURE_GETNEXT absenden. Als timeout reichen hier 500ms.
  5. Freigabe.
    Wenn alle Daten eingelesen sind, dann schaltet man mit der Nachricht MSG_SYS_ENABLE das System für Spontanmeldungen frei.

3.5. Klassen

Knoten melden mit Ihrer Unique-ID Klassen an, z. B. Belegtmelder, Interface, Booster, usw. Wie umfangreich die Klasse implementiert ist, wird durch Features bekanntgegeben.

Innerhalb einer Klasse gibt es verpflichtende Nachrichten, die ein Knoten unbedingt implementieren muss sowie optionale Nachrichten, die nur bei bestimmten Features implementiert sind.

Klasse Interface:
Ein Interface (Hub) transportiert Nachrichten von und zu weiteren Knoten in einem Subnetz.
  • Verpflichtend:
    • Alle Systemnachrichten
    • alle Nachrichten zur Node-Verwaltung (NEW, LOST, usw.)
    • Überlastsicher: Ein Interface darf keine Nachrichten verlieren, entsprechende Puffer sind vorzuhalten.
  • Optional:
    • User Konfiguration
    • Firmware-Update
Klasse Occupancy:
Der Knoten enthält Belegtmelder.
  • Verpflichtend:
    • Alle Systemnachrichten
    • FEATURE_BM_SIZE, FEATURE_BM_ON
    • Nachrichten für Belegtmeldung (GET_RANGE, GET_CONFIDENCE, FREE, OCC, MULTIPLE, CONFIDENCE)
  • Optional:
    • SECACK, Features und MIRROR-Nachrichten
    • Strommessung
    • Adressmeldung, Features und Nachrichten (ADDR_GET_RANGE, ADDRESS)
    • BiDi-Detektion, Features und Nachrichten
    • User Konfiguration
    • Firmware-Update
Klasse DCC-Generator:
Der Knoten stellt DCC-Fahr- und Schaltbefehle bereit.
  • Verpflichtend:
    • Alle Systemnachrichten
    • FEATURE_GEN_WATCHDOG, FEATURE_GEN_POM_REPEAT, FEATURE_GEN_DRIVE_BUS
    • Nachrichten für Gleisausgabe (MSG_CS_SET_STATE, MSG_CS_DRIVE, MSG_CS_ACCESSORY, MSG_CS_BIN_STATE, MSG_CS_POM)
  • Optional:
    • lokale Bedienung, Features und Nachrichten
    • Erweiterte Quittung, Auswertung der ACK-Leitung
    • RailcomPlus, Feature und Nachrichten
    • User Konfiguration
    • Firmware-Update
Klasse DCC-Programmieren:
Der Knoten stellt DCC-Servicemode-Befehle bereit.
  • Verpflichtend:
    • Klasse DCC-Generator
    • Programmiermodus (BIDIB_CS_STATE_PROG)
    • Programmiernachrichten (MSG_CS_PROG, MSG_CS_PROG_STATE)
Klasse Accessory Control:
Der Knoten hat Stellfunktionen für Fahrwegzubehör.
  • Verpflichtend:
    • Alle Systemnachrichten
    • FEATURE_ACCESSORY_COUNT
    • Nachrichten zur Accessoryansteuerung (MSG_ACCESSORY_SET, MSG_ACCESSORY_GET)
    • SecureSwitch (MSG_ACCESSORY_STATE)
  • Optional:
    • Überwachung und Spontanmeldung (MSG_ACCESSORY_NOTIFY)
    • User Konfiguration
    • Firmware-Update
Klasse Booster:
Ein Booster verstärkt das DCC-Signal für Fahrzeuge und DCC-Dekoder, er hat keine eigene DCC-Erzeugung.
  • Verpflichtend:
    • Alle Systemnachrichten
    • FEATURE_BST_INHIBIT_AUTOSTART
    • Nachrichten für Booster
  • Optional:
    • Diagnostik, FEATURE_BST_CURMEAS_INTERVAL und MSG_BOOST_DIAGNOSTIC
    • BiDi-Detektion, Features und Nachrichten
    • User Konfiguration
    • Firmware-Update
Klasse Schaltfunktionen:
Der Knoten stellt Zubehör- und Licht-Ansteuerung sowie -Animation bereit.
  • Verpflichtend:
    • Alle Systemnachrichten
    • FEATURE_CTRL_*_COUNT oder FEATURE_CTRL_PORT_FLAT_MODEL
    • Nachrichten zur Portansteuerung und -konfiguration
  • Optional:
    • FEATURE_CTRL_PORT_QUERY_AVAILABLE und Nachrichten zur Portabfrage
    • FEATURE_CTRL_INPUT_NOTIFY und Spontanmeldung von Eingängen
    • FEATURE_CTRL_MAC_LEVEL und Nachrichten zur Makroansteuerung
    • User Konfiguration
    • Firmware-Update
Klasse Gast:
Der Knoten stellt ein Bediengerät dar, dies kann sowohl eine Benutzerschnittstelle (MMI) oder eine Maschinenschnittstelle (M2M) sein.
  • Verpflichtend:
    • Alle Systemnachrichten
    • Nachrichten zur verteilten Bedienung (als Gast)
    • String-Nachrichten zur Identifikation
  • Optional:
    • User Konfiguration
    • Firmware-Update
Klasse Gastzugang:
Der Knoten enthält eine Schnittstelle zu einem BiDiB-System, er stellt einen Gastgeber-Dienst zur Interaktion mit diesem bereit.
  • Verpflichtend:
    • Alle Systemnachrichten
    • Nachrichten zur verteilten Bedienung (als Gastgeber)
    • String-Nachrichten zur Identifikation
  • Optional:
    • User Konfiguration
    • Firmware-Update

3.6. Systemzeit

Ein BiDiB-System verfügt über eine globale Systemzeit, um bei zeitbasierten Messungen eine höhere Genauigkeit zu erreichen. Verschiedene Nachrichten können Zeitstempel für das jeweilige Ereignis enthalten, dadurch sind genaue Ergebnisse bei Fahrzeugverfolgung und -kalibrierung ("Einmessen") möglich. Die Unsicherheit bei der Latenz der Datenübertragung wird so eliminiert.

Die BiDiB-Systemzeit hat eine Auflösung von 1 Millisekunde und wird als 16-Bit Integer mit zyklischem Überlauf repräsentiert. Es wird ein Fehler von ±5 ms zwischen den Uhren aller Knoten im System angestrebt.

Um eine Zeitmessung über verschieden Knoten hinweg zu ermöglichen, müssen die Uhren der Knoten aufeinander synchronisiert werden. Diese Synchronisation erfolgt auf jeder Busebene abhängig von der Transportschicht und wird vom jeweiligen Interface übernommen. Ob ein Interface/Hub dies unterstützt oder nicht muss in der Produktbeschreibung angegeben sein.

Die Synchronisation erfolgt typischerweise über eine periodisch ausgesendete Broadcastnachricht mit einem Zeitstempel. Beim Empfang dieser Nachricht wird die lokale Knotenuhr auf die Systemzeit eingestellt. Verzögerungen auf dem Übertragungsweg oder intern beim Senden und Empfangen sind dabei zu berücksichtigen und durch entsprechende Offsets zu korrigieren, die entstehende Unsicherheit soll maximal ±1ms pro Busebene sein. Im Moment der Justage kann es mit diesem Verfahren zu einem (kleinen) Sprung der Zeitfolge kommen, ein Host muss dies berücksichtigen.

Bleibt die Synchronisation aus, muss ein Knoten auf die Verwendung von Zeitstempeln verzichten sobald die enstehende Unsicherheit größer als ±3 ms wird. Beispiel: hat ein Prozessortakt eine Abweichung von bis zu 10ppm (0,01 ‰), dann soll er etwa 100 s nach der letzten Synchronisation seine lokale Uhrzeit nicht mehr verwenden.

Ein Interface soll sich mit der darüberliegenden Struktur synchronisieren, bevor es seine untergeordneten Knoten mit der Systemzeit versorgt. Hat es bis zum SYS_ENABLE (oder einem angemessenen Timeout) keine Synchronisationsnachricht erhalten, so soll es autark seine lokale Uhrzeit benutzen und damit die Synchronisation der Unterknoten durchführen.

4. Nachrichten

Die Nachrichten, welche auf dem BiDiB-System benutzt werden, lassen sich in folgende Bereiche gliedern:

System Abfrage der Software- und Hardwareversion und der Produktkennung, Systemstart und -stop, Verbindungseinstellungen, Abfrage und Einstellen der Node-Adressen.
Feature Abfrage und Einstellen der Eigenschaften des Knotens (Features)
User-Config offene Nachrichten zur herstellerspezifischen, erweiterten Konfiguration
Nachrichten für Firmwareupdates Upload neuer Knotensoftware.
Nachrichten für Melder Belegtmeldungen und Dekoder-Rückmeldung
Nachrichten für Booster Kontrolle und Überwachung von Boostern
Nachrichten für Gleisausgaben DCC Fahr- und Schaltbefehle
Nachrichten für Schaltaufgaben Weichen, Signale, Fahrwegzubehör
Nachrichten für Konfiguration und direkten Portzugriff Beleuchtung, Animationen, Sound, Zubehör
Nachrichten für Bediengeräte und Gastzugang
Lokale Nachrichten Busverwaltung, Synchronisation, Verbindungsüberwachung

Mit Downlink wird die Richtung Host ⇒ BiDiB-System bezeichnet, mit Uplink die Richtung zum Host.

Generell erfolgen Meldungen im Uplink spontan (nach erfolgter Freigabe im Interface). Bestimmte Meldungsarten können mittels Feature-Einstellung ein- oder ausgeschaltet werden.

Lokale Nachrichten

Für die lokale Kommunikation innerhalb einer Busebene können zusätzliche Nachrichten verwendet werden, um Verbindungszustände zu erfassen, An- und Abmelden zu organisieren oder Zeitsynchronisation herzustellen. Je nach Bustopologie und verwendeter Busphysik kann ein unterschiedlicher Umfang an lokalen Nachrichten nötig sein, näheres regeln die Spezifikationen der jeweiligen Verbindungstechnik.

Für lokale Nachrichten sind die Bereiche 0x70 bis 0x7F (Downstream) und 0xF0 bis 0xFF (Upstream) reserviert. Dies ermöglicht die Abtrennung und separate Behandlung dieser Nachrichten auf Linkebene.

Lokale Nachrichten sind grundsätzlich von der Sequenznummerierng ausgenommen, um Index-Folge der übergeordneten Verbindung Host-Zielknoten nicht stören. Sie werden mit Nachrichten-Index = 0 übertragen, welcher beim Empfang auch nicht ausgewertet wird oder den Indexzähler verändert.