BiDiB

• Zusammenfassung
• Beispiele

Protokoll

• Allgemein
• Generelle Nachrichten
• Firmware Update
• Gleissignal
• Zubehör – Schalten
• Zubehör – Konfiguration
• Melden
• Booster
• Verteilte Steuerung

• Druckversion

BiDiB, ein universelles Steuerprotokoll für Modellbahnen

Inhaltsverzeichnis

• 4.9. Verteilte Steuerung
  • 4.9.1. Kommunikation mit anderen Bediengeräten
  • 4.9.2. Kontrolle und Adressierung
  • 4.9.3. Request: Nachrichten von Gästen an Gastgeber
  • 4.9.4. Response: Nachrichten von Gastgebern an Gäste

Allgemeines

Das Protokoll BiDiB dient zur Kontrolle einer Modellbahnanlage. Es ermöglicht die Ansteuerung von Loks, Zubehör und sichere Übertragung von Rückmelderinformationen aus der Modellbahnanlage an den steuernden Rechner.

BiDiB kann über verschiedene Übertragungsmedien transportiert werden, dabei wird das Framing und die Sicherung der Nachrichten gewährleistet.

Eine Erläuterung der hier verwendeten Begriffe und der Protokollgrundzüge findet sich im allgemeinen Teil der Protokollbeschreibung, gleiches gilt auch für die Hinweise zur Benutzung und zur Lizenz.

Dieser Abschnitt der Protokollbeschreibung erläutert nur einen Teil der Nachrichten.

Revisionsstand

Dieses Dokument beschreibt Revision 1.29 von BiDiB, Stand 21.07.2023.

Die Revisionsgeschichte ist dem allgemeinen Teil zu entnehmen.

4.9. Verteilte Steuerung

4.9.1. Kommunikation mit anderen Bediengeräten

Eine Modelleisenbahnsteuerung besteht fallweise aus mehreren mehr oder minder autonomen Komponenten. Der Anwender trifft Eingaben durch sie oder möchte Rückmeldung durch Statusanzeigen und -meldungen bekommen. All diese Systeme müssen in die Steuerung und Absicherung einbezogen werden und benötigen dazu Zugriff auf das BiDiB-System in verschiedener Tiefe. Zu ihnen gehören unter anderem:

• Handregler für Fahrzeuge
• Stellpulte für Fahrwege
• Besetztmeldungsanzeigen und Zugnummernfelder
• Nothalttaster
• Schalttafeln für Zubehör und Licht
• Monitoring-Anwendungen
• Steuerungsprogramme
• Konfigurationsprogramme

Auf technischer Seite werden auch Anwendungen ermöglicht wie:

• Bus-Logger
• Netzbrücken
• Bus-Umschalter
• Verteilerdienste

Das Konzept eines zentralen Hosts, der alleine für den sicheren Betrieb verantwortlich ist und die volle Kontrolle über sein BiDiB-Netz ausübt, wird dabei nicht aufgegeben. Er sitzt an der Wurzel des Adressbaumes, empfängt alle Upstream-Nachrichten von den ihm untergebenen Knoten und sendet alle Downstream-Nachrichten.

Ein Host kann als Gastgeber einen Gastzugang bereitstellen, auf dem er verschiedene Dienste zum Zugriff auf sein Netz anbietet. Andere Bediengeräte können sich als Gast mit diesem Gastgeber verbinden und verschiedene Anfragen (Requests) schicken.

Ein Host ist nicht verpflichtet, irgendwelche Dienste bereitzustellen. Spontannachrichten mit Anfragen von Gästen kann er durch MSG_SYS_DISABLE unterbinden. Ein Gastgeber ist jederzeit dazu berechtigt, Anfragen abzuweisen.

Empfängt ein Gastgeber eine Anfrage oder will er von sich aus etwas mitteilen, kann er dem Gast auf dem jeweiligen Weg eine Antwort (Response) zukommen lassen.

Gast-Knoten können unterschiedlich ausgeprägt sein: Es kann sich um eine in Hardware ausgeführte Baugruppe handeln, die eine physische Benutzerschnittstelle enthält. Der Knoten kann aber auch rein der Kommunikation zwischen autonomen Geräten dienen und etwa als Programmierschnittstelle (API) oder Netzwerkschnittstelle ausgeführt sein. Eine solche Software-Instanz zeichnet sich unter anderem dadurch aus, dass sie eine zufällig erzeugte Unique-ID verwenden kann (vgl. netBiDiB). Zum Ausgleich dafür sind die MSG_STRING_*-Nachrichten für Produktname und Username verpflichtend, der Username soll auch direkt beim Start oder in den Einstellungen der Software vergeben werden können.

4.9.2. Kontrolle und Adressierung

Ein Gast, der die Kontrolle über einen Teil des BiDiB-System übernehmen möchte, kommuniziert ausschließlich mit dem Gastgeber, der seinerseits die volle Verantwortung über das System hat. Für den Zugriff auf Knoten kapselt der Gast die üblichen BiDiB-Downstream-Nachrichten (konkret deren Typ und Datenteil) in REQ_SEND-Nachrichten ein und sendet das Gesamtpaket an den Gastgeber. Der Gastgeber dient dabei als Stellvertreter des Zielknotens (Proxy) und leitet die eingekapselten Nachrichten nach erfolgreicher Prüfung der Zugriffsrechte an den vom Gast adressierten Knoten weiter. In Gegenrichtung werden Antworten sowie die abonnierte Kommunikation mit dem Zielknoten vom Gastgeber in RESP_NOTIFY-Nachrichten eingekapselt und an den Gast gesendet.

Ein Gast-Knoten erfährt per MSG_SYS_ENABLE, ob der Host Gast-Nachrichten unterstützt. Er darf nicht einfach spontan Nachrichten senden (ohne je eine Antwort zu bekommen). Bekommt er eine MSG_SYS_ENABLE ohne dass Gast-Nachrichten erlaubt werden, soll er eine Fehlermeldung zeigen.

Um Anfragen zu den von ihm kontrollierten Knoten entsprechend beantworten zu können, verwaltet ein Gastgeber eine Struktur in der gespeichert ist, welche Nachrichtenarten von welchen Knoten an welche Gäste weitergeleitet werden sollen. Bekommt er eine Anfrage eines Gastes, an einen bestimmten Knoten eine bestimmte Nachrichten zu senden, und lässt er dies zu (führt das Senden des Downstream-Befehls aus), so trägt er die erwarteten Antwortmöglichkeiten ein um beim Eintreffen der Upstream-Antwort diese an den Gast weiterleiten zu können.

Sämtliche Anfragen und Antworten beziehen sich auf einen bestimmten Knoten im System des Gastgebers. Dabei kann es sich sowohl um physische Baugruppen handeln, die über ein Bussystem an den Gastgeber angeschlossen sind, als auch um virtuelle Knoten (typischerweise mit VID=0), die vom Gastgeber simuliert werden. Der Gastgeber kann so auch beliebige interne Objekte abbilden (etwa Fahrstraßen, Blöcke, Berechtigungen, Fahrtaufträge, Zubehörabläufe etc) oder Legacy-Systeme ohne BiDiB-Unterstützung in das System integrieren. Der Gastgeber kann für diese Knoten ausgesuchte Nachrichtentypen implementieren und dem Gast so die Ausführung bestimmter Befehle ermöglichen, nicht implementierte Nachrichtentypen werden einfach immer abgelehnt.

Ein Knoten kann vom Gast auf verschiedene Weisen adressiert werden, die Zielangabe besteht aus einem Byte mit dem Modus und davon abhängigen weiteren Parametern. Der Gastgeber löst die Zielangabe in der Nachricht zu einer Knotenreferenz auf und diese weiter zu einer Session-Adresse. Mit dem TARGET_MODE wird die Art der gewünschten Zieladressierung beschrieben:

Kodierung der Zieladressierung

Wert	Name	Bedeutung
0x00	BIDIB_TARGET_MODE_UID	Es folgen 5 Bytes mit der VID und PID eines Knotens, also dessen Unique-ID ohne die Klassenbits. Der Gastgeber löst die UID anhand seiner Knotenliste zu einer Session-Adresse auf. Dieser Adressierungsmodus ist zu verwenden, wenn der Gast einen bestimmten, bereits bekannten Zielknoten ansprechen will. Durch die Identifikation über die UID statt der Verwendung einer Session-Adresse kann der Gast darauf verzichten, den Knotenbaum zu laden und aktuell zu halten. Dies ist insbesondere für Bediengeräte wie beispielsweise Stellpullte geeignet, bei denen der Nutzer einen bestimmten Zielknoten in die Konfiguration von Elementen oder Aktionen eingetragen hat. Dazu zählen etwa auch Teilnehmer, die DCC-Befehle bestimmten Knoten zuordnen.
0x01	BIDIB_TARGET_MODE_ALL	Es folgen keine Parameter. Dieser Adressierungsmodus hat eine besondere Bedeutung in Abonnement-Nachrichten: er repräsentiert ein globales Abonnement auf allen Knoten im System. Bei Verwendung in REQ_SEND soll der Zielknoten wie bei BIDIB_TARGET_MODE_TOP aufgelöst werden. Dieser Adressierungsmodus ist inbesondere für Logger (zum passiven Monitoring) oder für Konfigurationsprogramme geeignet, die selbst den gesamten Knotenbaum einlesen ohne ein bestimmtes Ziel zu haben.
0x02	BIDIB_TARGET_MODE_TOP	Es folgen keine Parameter. Der Gastgeber wählt selbstständig den von ihm kontrollierten Knoten aus. Dieser bildet die Wurzel des Knotenbaums des für den Gast sichtbaren BiDiB-Systems und ist typischerweise ein Hub-Knoten. Ein Hostprogramm wählt typischerweise den "obersten" Knoten des Systems, d.h. den direkt mit dem Host verbundenen Knoten dafür aus. Es kann sich aber auch um einen virtuellen Knoten handeln, der den Host selbst repräsentiert, und als Hub mehrere verbundene BiDiB-Systeme einbindet. Dieser Adressierungsmodus ist inbesondere für das Einlesen der verfügbaren Knoten durch den Gast geeignet, etwa für eine Auswahlliste in einer graphischen Bedienoberfläche. Über das Einlesen der Knotentabellen an über BIDIB_TARGET_MODE_UID gewählte Knoten kann der Gast rekursiv den Knotenbaum einlesen, der Start erfolgt dabei mit BIDIB_TARGET_MODE_TOP wenn noch keine Unique-ID bekannt ist.
0x08	BIDIB_TARGET_MODE_SWITCH	Es folgen keine Parameter. Der Gastgeber wählt selbständig die von ihm kontrollierten Schaltzubehör-Knoten aus. Dieser Adressierungsmodus ist bevorzugt zu verwenden, wenn der Gast nur einen minimalen spezifischen Funktionsumfang für Konfiguration und direkten Portzugang hat, die Zuordnung zum konkreten Knoten jedoch im Hostprogramm vorgenommen werden soll. Kann eine Ausführungsanfrage (MSG_GUEST_REQ_SEND) nicht eindeutig auf einen Knoten aufgelöst werden, wird die Anfrage abgelehnt.
0x09	BIDIB_TARGET_MODE_BOOSTER	Es folgen keine Parameter. Der Gastgeber wählt selbständig die von ihm kontrollierten Booster-Knoten aus. Dieser Adressierungsmodus ist bevorzugt zu verwenden, wenn der Gast nur einen minimalen spezifischen Funktionsumfang für Boostersteuerung hat, die Zuordnung zu konkreten Aktionen jedoch im Hostprogramm vorgenommen werden soll. Kann eine Ausführungsanfrage (MSG_GUEST_REQ_SEND) nicht eindeutig auf einen Knoten aufgelöst werden, wird die Anfrage abgelehnt.
0x0A	BIDIB_TARGET_MODE_ACCESSORY	Es folgen keine Parameter. Der Gastgeber wählt selbständig die von ihm kontrollierten Accessory-Knoten aus. Dieser Adressierungsmodus ist bevorzugt zu verwenden, wenn der Gast nur einen minimalen spezifischen Funktionsumfang für Schaltaufgaben hat, beispielsweise Taster und Zustandsanzeige für zweibegriffige Accessorys, während die Zuordnung zur konkreten Aktion im Hostprogramm vorgenommen werden soll. Kann eine Ausführungsanfrage (MSG_GUEST_REQ_SEND) nicht eindeutig auf einen Knoten aufgelöst werden, wird die Anfrage abgelehnt.
0x0C	BIDIB_TARGET_MODE_DCCGEN	Es folgen keine Parameter. Der Gastgeber wählt selbständig die von ihm kontrollierten Gleissignalgenerator-Knoten aus. Dieser Adressierungsmodus ist von Bediengeräten mit DCC-Geschwindigkeits- u. Funktionssteuerung (Handregler, Stellpult, ...) bevorzugt zu verwenden, diese müssen sich so nicht mit der Busverwaltung auseinandersetzen und keine Möglichkeit zur Auswahl eines individuellen Zielknoten anbieten. Stattdessen verteilt das Steuerungsprogramm die von verschiedenen Gästen kommenden Fahrbefehle an die jeweils passende Gleisausgabe. Die dazu nötige Konfiguration kann komfortabel zentral (z.B. via DCC-Mapping im PC-Programm erfolgen. Kann eine Ausführungsanfrage (MSG_GUEST_REQ_SEND) nicht eindeutig auf einen Knoten aufgelöst werden, wird die Anfrage abgelehnt.
0x0F	BIDIB_TARGET_MODE_HUB	Es folgen keine Parameter. Der Gastgeber wählt selbständig die von ihm kontrollierten Knoten mit Hub-/Subknotenfunktionalität aus. Dieser Adressierungsmodus ist bevorzugt zu verwenden, wenn der Gast an Veränderungen der Baumstruktur (NODE_NEW/NODE_LOST) interessiert ist, um ggf. seine Subscriptions zu erweitern.

Das Format der Zielangabe TARGET in vom Gast gesendeten Nachrichten ist dabei durch den TARGET_MODE wie folgt unterteilt:

Zielangabe durch den Gast

TARGET_MODE	Parameter
0x00	Es folgt eine UniqueID ohne Klassenbits, 5 Byte
0x01…0x0F	Es folgen keine Bytes, der Host sendet direkt an einen bestimmten Knoten
0x10…0xFF	reserviert. Nachrichten mit einem solchen Modus werden vom Gastgeber ignoriert und nicht beantwortet.

Ein Gastgeber muss nicht alle Arten der Zieladressierung unterstützen. Er muss jedoch die verschiedenen Formate verstehen und alle Nachrichten mit TARGET_MODE ≤ 0x10 beantworten, bei Nichtunterstützung mit RESULT=0xFF.

4.9.3. Request: Nachrichten von Gästen an Gastgeber

• MSG_GUEST_REQ_SUBSCRIBE:

  Der Gast bittet den Gastgeber, bestimmte Nachrichten an und von dem ausgewählten Knoten an den Gast weiterzumelden. Der Gastgeber merkt sich diese Abonnements, kann sie aber auch jederzeit auslaufen lassen.

  Der Gastgeber speichert dazu jede Gast-Zielknoten-Kombination. Ein Bitfeld zur groben Filterung, über welche Nachrichten von welchen Knoten der Gast informiert werden will, reicht dazu aus.

  Unterschieden wird zwischen Upstream und Downstream sowie dem Bereich, zu welchem der Nachrichtentyp gehört.

  Die definierten Nachrichtentypen im SUBSCRIPTION sind unabhängig vom verwendeten TARGET_MODE in der REQ_(UN)SUBSCRIBE Nachricht.

  REQ_(UN)SUBSCRIBE Parameter

  Parameter	Beschreibung
  TARGET[1;6]	Bestimmung des Zielknotens, bestehend aus TARGET_MODE und dessen Parametern — beim BIDIB_TARGET_MODE_UID folgen 5 Byte.
  SUBSCRIPTION[2]	Bitfeld mit der Auswahl, welche Nachrichen abonniert werden sollen: Bit Bedeutung 0 Downstream ⋮ Systemnachrichten (inkl. Hubnachrichten) 1 Feature- und Usernachrichten 2 Rückmeldernachrichten 3 Boosternachrichten 4 Port- und Makronachrichten 5 Gast- & Hubnachrichten 6 Gleissignalnachrichten (inkl. Prog) 7 Accessorynachrichten 8…15 Upstream Jeweils wie Downstream (8: System etc.) Ein Wert von 0xFFFF abonniert alle Nachrichten.

  Der Gastgeber antwortet mit RESP_SUBSCRIPTION_COUNT und beginnt danach automatisch mit dem Versand von RESP_SUBSCRIPTION für jeden aufgelösten Knoten.

  Hinweise:

  Falls das Ziel des Abonnements der anfragende Knoten selbst oder einer seiner Unterknoten ist, sollte das Abonnement mit entsprechendem RESULT-Code abgelehnt werden.

  Der Gastgeber akzeptiert auch Abonnements für Zielknoten, die (noch) nicht mit dem System verbunden sind, um reibungsloses Plug-and-Play zu ermöglichen. Der Gast wird vom Gastgeber über Änderungen des Verbindungsstatus mit einer Nachricht RESP_NOTIFY[TARGET=…, SUB_MSG_NUM=0, SUB_MSG_TYPE=MSG_LOCAL_LOGON/LOGOFF] unterrichtet.

  Verschiedene Targetmodes (insbesondere 0x08…0x0F) können zum selben Knoten aufgelöst werden. Dies ist an der TARGET_UID in der Antwort erkennbar.

  Mehrere verschiedene REQ_SUBSCRIBE auf den gleichen Knoten erweitern bestehende Abonnements.

  Zum Löschen von bestimmten Abonnements ist REQ_UNSUBSCRIBE zu verwenden.

  Abonnements mit BIDIB_TARGET_MODE_SWITCH, BIDIB_TARGET_MODE_BOOSTER, BIDIB_TARGET_MODE_ACCESSORY, BIDIB_TARGET_MODE_DDCGEN sowie BIDIB_TARGET_MODE_HUB werden auf alle betreffenden Knoten anhand ihrer Classbits aufgelöst.
  Der Gastgeber antwortet mit RESP_SUBSCRIPTION pro aufgelösten Knoten.

  Das Abonnement mit dem BIDIB_TARGET_MODE_ALL wird auf alle aktuell verbundenen Knoten außer dem Gastknoten selbst und seiner Unterknoten aufgelöst.
  Der Gastgeber antwortet mit RESP_SUBSCRIPTION pro aufgelösten Knoten.

  SUBSCRIPTION Bit 5 ist bevorzugt zu verwenden, wenn der Gast lediglich an Veränderungen der Baumstruktur (NODE_NEW/NODE_LOST) interessiert ist.

  MSG_SYS_ERROR Nachrichten eines Knotens werden immer an den Gast weitergeleitet, sobald eine Gast-Zielknoten-Kombination - unabhängig vom Abonnementumfang - besteht.

  Mit der Abmeldung des Gastes vom System (MSG_NODE_LOST) verfallen alle Abonnements. Ebenso sollte der Gastgeber bei Reinitialisierung (MSG_SYS_GET_MAGIC, MSG_SYS_DISABLE) oder Neustart (MSG_SYS_RESET) des Gastknotens alle bestehenden Abonnements löschen und dies dem Gast mittels RESP_SUBSCRIPTION[TARGET=…, RESULT=0x80, SUBSCRIPTION=0x0000] mitteilen.

  Dem Gastgeber steht es frei virtuelle Knoten zu implementieren die mehrere Knoten für einen TARGET zusammenfassen. Dem Gast gegenüber erscheint so die Einrichtung des Abonnements auf einen einzigen Knoten.

• MSG_GUEST_REQ_UNSUBSCRIBE:

  Der Gast bittet den Gastgeber, das Weiterleiten bestimmter Nachrichten an und von dem ausgewählten Knoten an den Gast zu beenden.

  Der Gastgeber antwortet mit RESP_SUBSCRIPTION_COUNT und beginnt danach automatisch mit dem Versand von RESP_SUBSCRIPTION für jeden aufgelösten Knoten, welcher den aktuellen Stand der ggf. weiterhin bestehenden Abonnements beinhaltet.

  Es werden die gleichen Parameter wie für REQ_SUBSCRIBE verwendet.

• MSG_GUEST_REQ_SEND:

  Der Gast fordert den Gastgeber auf, die verpackte Nachricht an den ausgewählten Knoten zu senden.

  REQ_SEND Parameter

  Parameter	Beschreibung
  TARGET[1;6]	Bestimmung des Zielknotens, bestehend aus TARGET_MODE und dessen Parametern — beim BIDIB_TARGET_MODE_UID folgen 5 Byte.
  REQ_MSG_TYPE	Nachrichtentyp der zu sendenden Nachricht
  REQ_DATA[0…N]	Weitere Parameter der zu sendenden Nachricht

  Der Gastgeber prüft, ob die Nachricht gesendet werden kann, und schickt sie fallweise an den Zielknoten. Die Sequenznummer (MSG_NUM) wird dazu vom Gastgeber generiert. Er antwortet in jedem Fall mit RESP_SENT als Empfangsbestätigung der Anfrage (solange TARGET_MODE ≤ 0x10).

  Hinweise:

  Erhält der Gastgeber die Antwort auf die gesendete Nachricht vom Zielknoten, leitet er sie per RESP_NOTIFY an den Gast weiter, sofern dieser zuvor ein Abonnement für den entsprechenden Nachrichtentyp eingerichtet hat.

  Bei Nachrichten zur Abfrage des Knotens, dessen Ergebnisse bereits lokal im Gastgeber vorliegen, darf und soll der Gastgeber das Senden überspringen und direkt die entsprechende Antwort generieren. Dies gilt insbesondere für Systemnachrichten zur Busverwaltung (Knotentabelle), Feature-Einstellungen und String-Variablen, Zustände von Gleisausgaben oder Boostern, Belegtmeldungen und Accessory-Zustände.

4.9.4. Response: Nachrichten von Gastgebern an Gäste

Unabhängig vom Targetmode folgt in den Antworten vom Gastgeber an den Gast auf TARGET_MODE (1 Byte) immer TARGET_UID (5 Byte).

• MSG_GUEST_RESP_NOTIFY:

  Der Gastgeber benachrichtigt den Gast über eine abonnierte Nachricht.

  RESP_NOTIFY Parameter

  Parameter	Beschreibung
  TARGET_MODE	Der TARGET_MODE des Abonnements. Der aktuelle Wert ist immer BIDIB_TARGET_MODE_UID.
  TARGET_UID[5]	Bestimmung des Knotens, der die Upstream-Nachricht gesendet hat bzw. an den die Downstream-Nachricht addressiert ist. Bestehend aus 5 Bytes mit der VID und PID, also der Unique-ID ohne die Klassenbits.
  SUB_MSG_NUM	Nachrichtennummer der vom Gastgeber empfangenen bzw. gesendeten Nachricht, oder 0 wenn die Nachricht lokal vom Gastgeber erzeugt wurde.
  SUB_MSG_TYPE	Nachrichtentyp der vom Gastgeber empfangenen bzw. gesendeten Nachricht. Das MSB des Typs kodiert, ob es eine Nachricht vom Gastgeber an das Ziel oder eine Nachricht vom Ziel an den Gastgeber ist.
  SUB_DATA[0…N]	Weitere Parameter der vom Gastgeber empfangenen bzw. gesendeten Nachricht

  Hinweise:

  Voraussetzung für jegliche RESP_NOTIFY Nachrichten ist in jedem Fall ein bestehendes Abonnement für den entsprechenden Nachrichtentyp und die Richtung.

  Der Gastgeber sendet RESP_NOTIFY, wenn er vom Zielknoten eine Nachricht empfängt oder wenn er selbst eine Nachricht an den Zielknoten sendet.
  Dies kann insbesondere die Reaktion auf REQ_SEND mit einer Zustandsabfrage sein, wenn der Gastgeber die angefragte Information lokal vorrätig hat.

  RESP_NOTIFY wird maximal einmal pro Nachricht gesendet, auch wenn der Gast sowohl ein globales als auch ein knotenspezifisches Abonnement eingerichtet hat.

  Der Host sorgt wie üblich für Quittungen (NODE_CHANGED_ACK, SecureACK, SecureSwitch) gegenüber dem Zielknoten. Der Gast sollte ebenso Quittungen via REQ_SEND senden, es ist empfohlen (aber nicht verpflichtend) dass der Host die Quittungen pro Gast überprüft (zum Beispiel wenn ein Gast die Bestätigung sendet aber ein zweiter Gast nicht).

• MSG_GUEST_RESP_SENT:

  Der Gastgeber bestätigt dem Gast, dass er eine REQ_SEND-Nachricht bekommen hat und was damit geschehen ist.

  RESP_SENT Parameter

  Parameter	Beschreibung
  TARGET_MODE	Der TARGET_MODE aus der REQ_SEND-Nachricht.
  TARGET_UID[5]	Bestimmung des Zielknotens, zu dem das TARGET der REQ_SEND-Nachricht aufgelöst wurde. Bestehend aus 5 Bytes mit der VID und PID, also der Unique-ID ohne die Klassenbits. Mit dieser UID werden später eventuelle Antworten des Zielknotens via RESP_NOTIFY übertragen.
  ACK_SEQ	Die Sequence-Number der bestätigten bzw. abgelehnten REQ_SEND-Nachricht.
  RESULT	Bestätigung, dass die angeforderte Nachricht gesendet wurde (MSB=0), oder warum dies nicht geschah (MSB=1). Bit 7 Bit 6…0 Bedeutung 0 OK 0 Der Anfrage des Gastes wurde entsprochen. In den DETAILS folgt ein Byte, welches die Zuordnung von Host-Nachrichten zu Gast-Wünschen erlaubt. Die Antwort des Zielknotens wird noch erwartet und dann über RESP_NOTIFY gemeldet. 1 Der Gastgeber konnte der Anfrage des Gasts entsprechen, die Antwort vom Zielknoten ist bereits eingetroffen oder lag lokal vor. Sie wird dem Gast direkt im Anschluss über RESP_NOTIFY mitgeteilt. Es folgen keine Daten in den DETAILS. Der Gastgeber kann den Request auch "akzeptieren" während die Antwort vom Zielknoten noch aussteht, und einfach die zu erwartende Antwort liefern (mit SUB_MSG_NUM=0). Der Gastgeber kümmert sich dann um die Umsetzung der Anfrage inklusive Fehlerbehandlung und Nachrichtenwiederholung. 2 Der Gastgeber konnte der Anfrage des Gasts entsprechen, die Antwort wird noch erwartet. In den DETAILS folgen drei Byte, eine SEQ_NUM welche die Zuordnung von Host-Nachrichten zu Gast-Wünschen erlaubt sowie ein Bitfeld zur Beschreibung des aktuell gültigen Filters (wie bei RESP_SUBSCRIPTION). Der Gastgeber ist nicht für eine Wiederholung der Nachricht zuständig 1 Grund für die Ablehnung. Der Anfrage des Gastes konnte nicht entsprochen werden. 125 Der Zielknoten konnte nicht eindeutig aufgelöst werden. 126 Der als Ziel angegebene Knoten ist nicht mit dem System verbunden. Äquivalent zu NODE_NA auf TARGET_MODE-Ebene 127 Der angefragte TARGET_MODE wird nicht unterstüzt. Der TARGET_UID-Parameter wird als 0 übertragen.
  DETAILS[0…N]	Abhängig von RESULT werden hier verschiedene Daten übertragen. Im Gutfall wird die Sequence-Number der vom Host an den Zielknoten gesendeten Nachricht angegeben, sofern die Antwort nicht bereits im Host vorlag. Im Falle einer Ablehnung (0x80) wird optional ein Präfix der zu sendenden Nachricht angegeben, für welche die Einschränkung gilt. Kein Präfix bedeutet, dass sämtliche Nachrichten mit diesem Grund abgelehnt werden. Ein Präfix von einem Byte bedeutet, dass nur dieser Nachrichtentyp abgelehnt wurde. Ein Präfix von mehreren Byte bedeutet, dass nur dieser Nachrichtentyp bezogen auf den bestimmten Teil des Knotens abgelehnt wurde. Beispiel: RESULT=0x80, DETAILS=[MSG_CS_DRIVE, 15, 0] bedeutet, dass das Fahrzeug mit der Adresse 15 nicht vom Gast gesteuert werden darf. Für andere Adressen oder Nachrichtentypen liegt möglicherweise keine Einschränkung vor.

• MSG_GUEST_RESP_SUBSCRIPTION_COUNT

  Diese Nachricht wird zu Beginn der Übertragung gesendet, wenn der Gast mit MSG_GUEST_REQ_SUBSCRIBE/UNSUBSCRIBE angefragt hat.

  RESP_SUBSCRIPTION_COUNT Parameter

  Parameter	Beschreibung
  TARGET_MODE	Der TARGET_MODE aus der REQ_SUBSCRIBE/REQ_UNSUBSCRIBE-Nachricht.
  TARGET_UID[5]	Bestimmung des Zielknotens, zu dem das TARGET der REQ_SUBSCRIBE/REQ_UNSUBSCRIBE-Nachricht aufgelöst wurde. Bestehend aus 5 Bytes mit der VID und PID, also der Unique-ID ohne die Klassenbits. Die abonnierten Nachrichten später mit dieser UID in RESP_NOTIFY übertragen.
  ACK_SEQ	Die Sequence-Number der REQ_SUBSCRIBE/REQ_UNSUBSCRIBE-Nachricht.
  RESULT	Quittung Wert Bedeutung 0 OK, Abonnement eingerichtet 0x80 Abonnements werden (für den Zielknoten) nicht unterstützt 0x81 Abonnement konnte nicht eingerichtet werden: das Ziel ist der Abonnent selbst oder ein Unterknoten. 0xFE Abonnement konnte nicht eingerichtet werden, weil der Nachrichtentyp vom Knoten nicht unterstützt wird 0xFF Der verwendete TARGET_MODE wird nicht unterstüzt, vgl. RESP_SENT.
  COUNT[2]	Zwei Bytes mit der Anzahl der entsprechend des TARGET aufgelösten Knoten.

• MSG_GUEST_RESP_SUBSCRIPTION:

  Der Gastgeber bestätigt ein Nachrichtenabonnement des Gasts oder teilt eine Änderung mit.

  RESP_SUBSCRIPTION Parameter

  Parameter	Beschreibung
  TARGET_MODE	Der TARGET_MODE aus der REQ_SUBSCRIBE/REQ_UNSUBSCRIBE-Nachricht.
  TARGET_UID[5]	Bestimmung des Zielknotens, zu dem das TARGET der REQ_SUBSCRIBE/REQ_UNSUBSCRIBE-Nachricht aufgelöst wurde. Bestehend aus 5 Bytes mit der VID und PID, also der Unique-ID ohne die Klassenbits. Die abonnierten Nachrichten später mit dieser UID in RESP_NOTIFY übertragen.
  ACK_SEQ	Die Sequence-Number der REQ_SUBSCRIBE/REQ_UNSUBSCRIBE-Nachricht.
  RESULT	Quittung Wert Bedeutung 0 OK, Abonnement eingerichtet 0x80 Abonnements werden (für den Zielknoten) nicht unterstützt 0x81 Abonnement konnte nicht eingerichtet werden: das Ziel ist der Abonnent selbst oder ein Unterknoten. 0xFE Abonnement konnte nicht eingerichtet werden, weil der Nachrichtentyp vom Knoten nicht unterstützt wird 0xFF Der verwendete TARGET_MODE wird nicht unterstüzt, vgl. RESP_SENT.
  SUBSCRIPTION[2]	Aktive Nachrichtenauswahl, als Bitfeld wie bei REQ_SUBSCRIBE/REQ_UNSUBSCRIBE