BITBUS (IEEE 1118) ist ein offener und nicht proprietärer Feldbus. Ursprünglich wurde BITBUS 1984 von Intel spezifiziert und 1991 unter der Bezeichnung IEEE 1118 als internationaler Standard angenommen. Er baut auf zwei verbreiteten Standards als Grundlage auf. Die RS-485 Schnittstelle wird als physikalische Verbindung zwischen den einzelnen Geräten verwendet. Auf der Softwareseite wird Synchronous Data Link Control (SDLC) verwendet.

Die folgenden Eigenschaften werden BITBUS zugesprochen:

• Eine geringe Total Cost of Ownership (TCO)
• Zuverlässigkeit
• Deterministisches Verhalten
• Die Echtzeitkontrolle wird ins Feld delegiert
• Sehr gutes Verhältnis von Entfernung zu Übertragungsgeschwindigkeit
• Unterstützung auf vielen Betriebssystemen

Je nachdem, zu welcher Länge der Bus ausgebaut wird, können unterschiedliche Datenübertragungsgeschwindigkeiten realisiert werden. Bei einer Buslänge von 300 Metern ist eine maximale Geschwindigkeit von 375 kBit/s möglich. Erstreckt sich die Feldbusstrecke über eine Entfernung von 1200 Metern, so sind noch Übertragungsraten von 62,5 kBit/s möglich.

Die Verkabelung erfolgt nach den Vorgaben der Spezifikation RS-485. Diese legt jedoch nicht die Steckerbelegung fest, welche nach Vorgabe in der Tabelle Pinbelegung zu erfolgen hat.

Es werden Twisted Pair Kabel zum Anschluss der einzelnen Geräte verwendet. Dabei bilden die Leitungen Data A und Data B ein verdrilltes Adernpaar und die optionalen Verbindungen RTS A und RTS B. Diese werden aber bloß in Segmenten benötigt, die jenseits eines Repeaters liegen, wenn ein solcher zum Einsatz kommt. Durch Signalerde werden die Leitungen geschirmt.

Als Steckverbinder findet ein 9-poliger D-Sub-Stecker Verwendung.

Pro Datenpaket können maximal 248 Bytes an Nutzdaten übertragen werden.

Beim BITBUS unterscheidet man zwei Daten-Kodierungstechniken, den „Synchron Mode“ und den „Self Clock Mode“.

Beim „Synchron Mode“ wird noch ein weiteres Leitungspaar zur Übertragung des Synchronimpulses benötigt.

Beim „Self Clock Mode“ werden die Bits nicht nach dem Standard NRZ, sondern nach NRZI mit „Zero Bit Insertion“ übertragen. Deshalb können die meisten Repeater oder LWL-Konverter nicht verwendet werden. (Quelle: (c) Intel Corporation 1988, THE BITBUS(TM) INTERCONNECT SERIAL CONTROL BUS SPECIFICATION, Order Number: 280645-001)

Innerhalb der Bus-Topologie können in einem Bus-Segment maximal 28 Teilnehmer miteinander verbunden sein. Beim Einsatz von Repeatern kann die Anzahl der angeschlossenen Geräte auf bis zu 250 erhöht werden. Falls mehr als zwei Repeater in Serie geschaltet sind, beträgt die Datenrate nur noch 62,5 kBit/s. Wird diese Geschwindigkeit verwendet, so können bis zu zehn Repeater hintereinander geschaltet sein. Jeder Repeater kann ein Bus-Segment mit einer Länge von 300 m bzw. 1200 m treiben, abhängig von der gewünschten Übertragungsgeschwindigkeit (siehe oben). Ein Repeater belastet den Bus wie ein gewöhnlicher Teilnehmer.

Der Bus muss an beiden Enden der Leitung mit einem 120 Ohm Abschlusswiderstand versehen sein.

Der Adressraum beim BITBUS reicht von 0 bis 255 (hexadezimal: 0x00 bis 0xff). Jedem Teilnehmer ist eine eigene Adresse in Form einer Zahl von 1 bis 249 zugeordnet. Die Adressen 0 und 250 bis 255 sind reserviert und dürfen keinem Bus-Teilnehmer zugeordnet werden. 255 spricht in der alten BITBUS-Spezifikation die lokale Netzwerkkarte an. In der neueren IEEE 1118 Norm wird 255 als Broadcast-Adresse verwendet.

Das in BITBUS Interconnect verwendete Data Link Protokoll ist eine Untermenge des von IBM entwickelten SDLC Standards, erhebt aber keinen Anspruch auf vollständige SDLC-Kompatibilität. Ausgehend von diesem, definiert die Spezifikation die Verbindung eines Masters mit mehreren Slaves auf der Bus-Topologie. Das Data Link Protokoll ist dabei im Wesentlichen für das Framing von Nachrichten und deren Kontrolle im Transport zuständig. Erreicht wird dies durch die Definition eines Systemstatus, eines einheitlichen Frame-Formats, Kontrollfelder und Bus-Operationen.^[1]

Da es sich bei dem aufgebauten System um ein hierarchisches System handelt, ist der Systemstatus aus Sicht des Masters definiert. Die hierarchische Struktur kann dabei aus einer einfachen, flachen oder einer komplexen, mehrstufigen Hierarchie bestehen. Die Knoten des Systems können dabei hierin nicht nur aus einfachen, sondern auch aus intelligenten Knoten bestehen, die vor allem im mehrstufigen Betrieb in der Lage sind, unterschiedliche Betriebsgeschwindigkeiten zu realisieren.^[1]

Der Master hat volle Kenntnis und Kontrolle über seinen internen Zustand. Da die Funktionsfähigkeit der Slaves allerdings nicht von seinem Zustand anhängig ist, wird sein Zustand nie übertragen und verbleibt undefiniert.^[1]

Anders hingegen ist der interne Zustand eines Slaves unerlässlich für das korrekte Funktionieren des Master. Weil eine präzise Erfassung schon durch die physikalische Trennung der Knoten nicht zu jeder Zeit gegeben ist, definiert der Standard einen Zustandsübertragungsmechanismus, der es dem Master ermöglicht, über den internen Zustand jedes Slaves Buch zu führen. Der erfasste Zustand wird für die nächste Kommunikation mit einem Slave als gegeben angenommen. Besteht eine Diskrepanz zwischen dem angenommenen und dem tatsächlichen Zustand des kontaktierten Slaves, greift eine Folge von Aktionen, die zu einer Resynchronisation der beiden Kommunikationspartner führt.^[1]

Der Zustand eines Slaves besteht dabei aus zwei Teilinformationen:

Der „Slave Device Mode“ bezeichnet die Betriebsart des Slaves. Im Standard sind die Betriebsarten „Normal Disconnect Mode“ und „Normal Response Mode“ definiert. Der Slave befindet sich zu jeder Zeit in einem der beiden Modi.

Ein Gerät befindet sich im „Normal Disconnect Mode (NDM)“, falls ein lokaler Reset oder ein nicht behebbarer Fehler beim Nachrichtenaustausch aufgetreten ist. In diesem Zustand wartet der Slave auf ein spezifisches Signal vom Master, welches ihm einen Übergang in den Normal Response Mode gestattet. Weiterer Nachrichtenaustausch mit dem Master findet in diesem Zustand nicht mehr statt.

Ein Gerät befindet sich im „Normal Response Mode (NRM)“, falls der Slave im NDM das spezifische Signal für den Zustandswechsel erhalten hat. Nach dem Übergang in den NRM erfolgt eine Synchronisation des Zustands mit dem Master-Knoten. Dabei werden alle Zähler mit 0 initialisiert. Nachrichtenaustausch mit dem Master ist in diesem Zustand gestattet, sofern Synchronisation besteht.^[1]

Zur Vermeidung von Paketverlusten und zur Duplikaterkennung wird im NRM ein Sequenzzähler eingesetzt. Jeder Slave verwaltet dabei intern ein Tupel (N_r, N_s), bestehend aus dem Zählerstand N_r der nächsten erwarteten Nachricht und dem Zählerstand N_s der Nachricht, für die noch eine Bestätigung erwartet wird. Der Master speichert für jeden Slave ebenfalls ein solches Tupel ab. Es repräsentiert den für den Master als letzten bekannten Zustand des Slaves. Jede Nachricht, die über BITBUS Interconnect ausgetauscht wird, enthält das Tupel, sodass beim Empfang ein Abgleich stattfinden kann. Dabei ergeben sich drei mögliche Szenarien:

1. Korrekte Sequenzierung
2. Behebbarer Sequenzierungsfehler
3. Nicht behebbarer Sequenzierungesfehler

Im Falle des nicht behebbaren Sequenzierungsfehlers muss der Slave neu mit dem Master synchronisiert werden und geht in den NDM über.^[1]

Commons: BITBUS – Sammlung von Bildern, Videos und Audiodateien

• Homepage des BITBUS European Users Group e.V. (BEUG) (englisch)
• BITBUS-Grundlagen

1. ↑ ^{a b c d e f} Intel Corporation: THE BITBUS™️ INTERCONNECT SERIAL CONTROL BUS SPECIFICATION. Intel Corporation, 1988, abgerufen am 17. Mai 2018 (englisch).