Übertragung
Serielle Verbindung
BiDiBus
Netzwerk

Hintergrund-Informationen zu BiDiBus

Auf dieser Seite sind Erläuterungen zum Standard zu finden, diese Informationen sollen die Funktionalität von BiDiB näher beleuchten.

Kann man mit BiDiB manuell, ohne Computer fahren?

Dieser Punkt wurde intensiv diskutiert.

Zuerst mal muss man klären, was man unter 'manuell fahren' versteht: das sind auch zwei verschiedene Aspekte: was heißt 'manuell', was heißt 'fahren'?

Hier stellt sich die Frage, welches Steuerungsmodell man im Hinterkopf hat und welche Rolle der Bediener darin spielt: ist er Disponent, Fahrdienstleiter, Lokführer oder Rangierer? Je nach gewählter Rolle wird man die Begriffe 'manuell' und 'fahren' anders interpretieren.

Damit einher geht die Frage, wie man das Steuerungsmodell festlegt: gibt es einen zentralen Punkt, der alle Informationen hält oder ist die Zustandsinformation 'verteilt'?

Des weiteren muss man sich überlegen, welche Auswirkungen das Steuerungsmodell und die Informationsverteilung auf das Bussystem hat: wenn man die Rolle des Bedieners nicht festlegen will, so muss man in einem Bussystem entweder alle Nachrichten global kommunizieren oder jeweils Abonnements einführen, die bei Änderungen des Zustands eines Knotens die Abonnenten benachrichtigt. Parallel dazu braucht man eine Abfragemethode, um bei Wechsel des Bediener-Fokus die neu darzustellenden Zustände erfragen zu können. Beides sorgt bei großen Anlagen für ziemlichen Bandbreitenbedarf, ungelöst bleibt die Frage nach der logischen Verknüpfung der Zustände (Fahrweg, Blocksicherung).

Darüber hinaus gibt es die Frage der Absicherung zu klären: nach welchen Regeln 'darf' ein Handregler oder Stellpult in den Fahrbetrieb eingreifen? Hier gibt es ziemlich unterschiedliche Anforderungen von Privatanlagen mit einem einzelnen Bediener (der alle Funktionen in einer Person vereint und entsprechend schnell seine Rolle ändert) und Vereins- oder Ausstellungsanlagen, wo Regeln für einen unfallfreien Betrieb erforderlich sind. Dies kann entweder komplett zentral oder mit verschiedenen Rollen (z. B. fest zugeordneter Lokführer oder Fahrdienstleiter) erfolgen.

BiDiB ist primär als effizientes Transportmedium von und zu einer zentralen Kontrollinstanz entwickelt worden, in dieser Kontrollinstanz wird damit auch das Steuerungsmodell und die entsprechende Verteilung der Information (was wird auf welchem Stellpult angezeigt und wo werden welche Eingaben vorgenommen) definiert. Anders ist eine halbwegs komplexe Modellbahnanlage nicht zu beherrschen bzw. ist im Betrieb stark eingeschränkt und starren Regeln unterworfen.

Jetzt gibt es aber Situationen, deren Auflösung in der Kontrollinstanz nicht vorgesehen ist (z. B. Entgleisung, verlorene Wagen). Zur Lösung solcher Betriebsfälle ist ein direkter Eingriff in die Steuerung ohne jegliche logische Absicherung hilfreich.

Für einen solchen Havariebetrieb sollen in BiDiB Mechanismen eingebaut werden, die einen direkten Zugriff auf die Gleissignalgeneratoren erlauben, um 'low level' ohne jegliche Absicherung eingreifen zu können.

Eine abschließende Bemerkung hierzu: 'manuell fahren' wird oft auch deswegen gefordert, weil der Computer einfach zu lange braucht, bis er betriebsbereit zum Bedienen der Anlage ist. Und es spricht nichts dagegen, dass der erste Busmaster eine gut ausgestattete Zentrale konventioneller Bauart ist (was auch nichts anderes als ein kleiner Computer ist), der dann diesen Rollenwechsel bei abgekoppelter PC-Steuerung ermöglicht.

Warum basiert BiDiBus auf RS485 und nicht auf CAN?

Wir haben CAN als mögliche physikalische Grundlage auch angesehen. CAN bietet ein auf den ersten Blick bestechendes Arbitrierungssystem mit dominanten und rezessiven Bits. CAN wird verwendet von OpenLCB, CBUS und von S-9.5.1 (waren Kandidaten für nmranet, Sommer 2010).

Dieses Schema passt sehr gut zu rein event-basierten Bussen und Producer-Consumer-Modellen, ist aber von der Logik her nicht für adressierbare Systeme geeignet, dafür reicht die Wortlänge der CAN-Header nicht. Adressierbarkeit möchte man aber gerne haben, um Konfiguration und Überwachung (und damit Betriebssicherheit) zu realisieren.

Wo man Adressierbarkeit (also mit langer Unique-ID) fordert, muss man das in CAN hineinquetschen: hierzu gibt es verschiedene Vorschläge, um aus der Unique-ID die jeweilige CAN-ID für die Session zu generieren. (z. B. jeder Knoten berechnet die CAN-ID durch Hashen seiner Unique-ID, sendet das raus und testet, ob ein anderer Knoten dagegen protestiert) Aber auf diese Weise hat man:

  1. die Vorteile von CAN ausgehebelt
  2. die Möglichkeit weggegeben, die Busverteilung lastspezifisch steuern zu können.

Damit bleibt von CAN eigentlich nichts mehr außer dem Phy mit seinem schnellen Zugriff (speziell bei schwacher Auslastung des Bussystems) auf das Busmedium übrig.

Bei starker Last kann ein CAN-System Knoten und Nachrichten mit einer niedrigen Priorität komplett aussperren, es gibt keinen 'Master' und damit auch niemand, der entsprechend die Priorität 'fair' vergibt.

RS485-Systeme benutzen ein "Single-Master, Multiple-Slaves" Prinzip mit einem zyklischen Pollen der Slaves. Dadurch entsteht eine kleine Mindestlatenz auch bei schwacher Last, diese Latenz kann man durch etwas Intelligenz bei der Pollreihenfolge auf Zeiten im einstelligen ms-Bereich drücken und damit unerheblich machen. Bei großer Last oder gar zeitlich begrenzter Überlast kann ein Single-Mastersystem alle Busteilnehmer gleichermaßen drosseln und so das prinzipielle Funktionieren des Busses aufrecht erhalten.

Dadurch, dass ein RS485-System (bedingt durch das Single-Master-Prinzip) keine ständige Kollisionsprüfung fahren muss, kann man die Busgeschwindigkeit erhöhen: Bei CAN muss innerhalb eines Bits geklärt werden, ob es zu einer Kollision kam: bei angenommen 16cm/ns (bei e(r)=4) ergeben sich 2,4µs für eine hin- und rücklaufende Welle auf einer 200m langen Leitung. Bei RS485 muss diese Zeit nicht je Bit berücksichtigt werden, sondern nur dann, wenn ein Poll an einen Knoten abgesandt wurde und geprüft wird, ob der Knoten antwortet. Man kann daher die Baudrate höher setzen, bis andere Grenzen (z. B. bedingt durch die bei der Modellbahn oft nicht perfekte Verdrahtung) eine Beschränkung sinnvoll erscheinen lassen.

Wenn man die Implementierungsseite betrachtet, dann haben speziell kleinere Prozessoren im unteren Preissegment keinen CAN-Controller an Bord, ein UART (für RS485) ist jedoch immer an Bord. Auch bei den Chips haben wir Vorteile für RS485 gesehen: RS485 ist industriell breit erprobt und es gibt sehr viele, preiswerte Bausteine von vielen verschiedenen Herstellern, darunter auch komplett potentialgetrennte Bausteine. Dies ist ein Argument bei Rückmeldern, deren Bezugspunkt ja auf Gleispotential zu liegen kommt und die daher immer an irgendeiner Stelle eine Potentialtrennung brauchen. Hier ist die Potentialtrennung am Bus preisgünstiger als die Trennung jedes Meldeabschnittes mit Optokoppler.

Warum ist die Knotenzahl in einem BiDiBus-Segment auf 32 beschränkt?

Aus Sicht des BiDiB-Protokolls wird die Adresse hierarchisch zusammengesetzt, jedes Bussegment wird mit einer 8-Bit Adresse verwaltet, daher sind 255 Adressen innerhalb einer Strukturebene (Bussegment) möglich. Die Übertragungstechnik innerhalb eines Bussegmentes ist frei wählbar, die RS485-basierte Übertragung ist eine mögliche Realisierung.

Bei der Knotenzahl auf einer Strukturebene muss man verschiedene Kompromisse eingehen:

  • Leistungsbeschränkung:
    Jeder Knoten, der seine Stromversorgung vom Bus bezieht, belastet das Buskabel. CAT5-Kabel haben 0,4mm Aderndurchmesser, das ergibt einen Widerstand von 3,5 Ohm je 100m.
    Sinnvoll kann man den zulässig zu entnehmenden Strom eines Knotens auf 30mA beschränken, damit kann man einen Mikrocontroller mit etwas Zubehör gut betreiben. Mit einem zulässigen Spannungsfall von 4V am Bus und dem Knotenstrom ergibt sich 1A und damit 32 Knoten.
  • Geschwindigkeit:
    BiDiB ist auf hohe Geschwindigkeit ausgelegt, dazu gehört eine geringe Buslatenz: Bei 32 Knoten und einem Pollkommando mit gesamt 11 Bit (Start, 9N1) ergibt sich eine Turnaroundzeit von 1,7ms, d.h. Nachrichten des übergeordneten Knotens werden durch die Beschränkung auf 32 mit sehr geringer Latenz weitergeleitet. Und selbst wenn alle Knoten parallel mit maximaler Wortlänge (das ist ein extrem unwahrscheinlicher Fall, bis dato gibt es keine Nachrichten, welche die Grenze von 64Byte auch nur annähernd ausreizen) senden, so ist die Turnaroundzeit 43ms.
  • Verdrahtung:
    Modellbahnverdrahtung ist oft nicht ganz 'einwandfrei' (in Sinne einer durchgängig korrekt angepassten Impedanz und ungünstiger Verteilung der Anschlussstellen (kapazitive Buslast)), so dass die Beschränkung auf 32 Knoten hier eine Sicherheitsreserve bei der elektrischen Ausführung bietet.

Eine Beschränkung innerhalb einer Strukturebene ist für BiDiB problemlos möglich: Ebenen lassen sich (ähnlich wie bei USB mit Hubs) einfach erweitern und selbst mit der Beschränkung auf 32 Mitglieder in einer Ebene und 3 Ebenen lassen sich dann 31776 Knoten adressieren.

Überlegung zur Wahl der Geschwindigkeit am BiDiBus

BiDiBus ist auf 500kBaud definiert. Es gibt Argumente pro und contra einer schnelleren oder langsameren Auslegung:

  • Verdrahtungsfreiheit:
    Wenn man bei der Verdrahtung ein verzweigtes Netz zulassen will, so hat man mit nicht abgeschlossenen Stichleitungen zu tun. Speziell bei Handreglern sind diese nicht vermeidbar.
    Stichleitungen sind relativ harmlos, wenn die doppelte elektrische Länge deutlich kleiner als die Anstiegszeit des Signals sind. Man kann also Übertragungsgeschwindigkeit gegen zulässige Stichleitungslänge tauschen. Nimmt man εr mit 4 an, so ergeben sich ca. 16cm/ns und damit für 5m-Stichleitung eine elektrische Länge von 5/0,16*2 = 62ns. Bei den für BiDiBus vorgeschriebenen Transceivern mit einem Slewrate-Limit von 200ns ergeben sich stabile Übertragungsverhältnisse. Erläuterungen hierzu finden sich auch in "Ten Ways To Bulletproof RS-485 Interfaces".
  • Verfügbarkeit von Transceivern:
    Diese Art von Transceivern sind von verschiedenen Herstellern sowohl in 5V als auch 3,3V lieferbar.

Zur Erläuterung hier mal zwei Kurvenformen: simuliert wurde jeweils der gleiche Bus: 280m lang, mit mehreren Abzweigen mit je 5m und mit Fehlpassungen, zusätzlichen Last-Kondensatoren und Übergangswiderständen, also ein durchaus realistisches Szenario:

Anstiegszeit 15ns
Man kann hier Reflexionen bis zur Schaltschwelle sehen – instabil!		 Anstiegszeit 200ns
Hier sieht man schwache Reflexionen durch die eingebauten Verdrahtungsfehler, aber es bleibt unter der Schwelle.

Vorgaben für das Mikrotiming

  • Es wurde eine möglichst kleine Mindestwartezeit von 2µs nach der Aussendung des Tokens gewählt. Nachdem der Treiber des Busmasters abschaltet, wirken nur die Bias-Widerstände zusammen mit der Leitungskapazität des Busses. Der Bus ist dabei für sehr kurze Zeit elektrisch nicht aktiv getrieben und schwingt ein. Das Einschwingen kann bei einem aktivierten Receiverbaustein zu einer empfangenen 0 führen.
    Das kann zur Folge haben, dass bei einer Umschaltzeit von 0µs und sofortiger Aktivierung des Receivers im Master irrtümlich ein Startbit erkannt wird. Der Busmaster soll also seinen Receiver erst 1-2µs nach Abschalten von TX-Enable aktivieren, der Node darf nicht früher als 2µs nach dem Stopbit mit der Antwort beginnen.
  • Parallel zur Vorgabe des Minimaltiming wurde eine strenge, aber doch auch von 8-bit Prozessoren erfüllbare Maximalzeit definiert, um die Leerlaufzeiten bei Buszuteilung minimal zu halten.

Warum ist der ACK eine separate Leitung?

ACK dient dem Gleissignalerzeuger (also der Zentrale) als beschleunigte Befehlsbestätigung und ist zeitlich eng mit dem DCC-Signal verknüpft. Diese Befehlsbestätigung hat folgende wesentliche Eigenschaften an Anforderungen:

  • Sie hat sehr geringe Bandbreite, nur max. 200 Baud, es wird ja nur ein Bit je DCC-Befehl übertragen.
  • Sie benötigt keine Buszuteilung. Diese ist ja durch die zeitliche Zuordnung zum DCC-Befehl klar vorgegeben, nur der angesprochene Dekoder sorgt für das ACK.
  • Sie muss sehr schnell erfolgen. Grund hierfür ist der Wunsch, die Gleisausgabe zu optimieren. Typischerweise wird eine Zentrale DCC-Befehle mehrfach wiederholen, und später dann in einem allgemeinen Refresh-Zyklus einbauen. Die Wiederholungen zu Beginn müssen mindestens ein anderes Paket dazwischen haben. Will man nun in der Lage sein, bei erfolgter Quittung bereits die erste Wiederholung weglassen zu können, so muss die Quittung innerhalb des zwischenliegenden Befehls eingetroffen sein.
    Beispiel: Lok LX wird neu angesprochen.
    Befehlsfolge ohne ACK: L1L2L3LXL4LXL5LXL6L7 L8L1L2usw.
     
    Befehlsfolge mit ACK: L1L2L3LXL4L5L6L7 L8L1L2L3usw.
    ACK für LX:     ⇑         
    Es ist zudem zu beachten, dass der ACK auch in der Softwareschicht der DCC-Ausgabe angekommen sein muss, die ACK-Nachricht darf also nicht mehr in Protokoll-Fifos o.ä. verzögert sein.

Diese geringe Latenz ist mit einem Busprotokoll nur schwer zu erreichen, insbesondere wenn da auch Busbrücken (Bridges + Gateway) im Spiel sind. Und weil die zu übertragende Datenmenge sehr gering ist (nur. ca 200 Baud), wurde ein zugriffsfreier Open-Collector-Ring eingeführt.