DE102016004095B4 - Automatisches Eingrenzen eines physikalischen Netzwerkfehlers zur Laufzeit - Google Patents

Automatisches Eingrenzen eines physikalischen Netzwerkfehlers zur Laufzeit Download PDF

Info

Publication number
DE102016004095B4
DE102016004095B4 DE102016004095.5A DE102016004095A DE102016004095B4 DE 102016004095 B4 DE102016004095 B4 DE 102016004095B4 DE 102016004095 A DE102016004095 A DE 102016004095A DE 102016004095 B4 DE102016004095 B4 DE 102016004095B4
Authority
DE
Germany
Prior art keywords
network
participant
bus
participants
network participant
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE102016004095.5A
Other languages
English (en)
Other versions
DE102016004095A1 (de
Inventor
Georg Westerkamp
Lars Friedrich
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Wago Verwaltungs GmbH
Original Assignee
Wago Verwaltungs GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Wago Verwaltungs GmbH filed Critical Wago Verwaltungs GmbH
Priority to DE102016004095.5A priority Critical patent/DE102016004095B4/de
Priority to US15/479,625 priority patent/US10411952B2/en
Publication of DE102016004095A1 publication Critical patent/DE102016004095A1/de
Application granted granted Critical
Publication of DE102016004095B4 publication Critical patent/DE102016004095B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0677Localisation of faults
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0631Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
    • H04L41/0645Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis by additionally acting on or stimulating the network after receiving notifications

Abstract

Verfahren zum Eingrenzen eines physikalischen Netzwerkfehlers in einem eine Vielzahl an Netzwerkteilnehmern aufweisenden drahtgebundenen Netzwerk (30), umfassend:Detektieren, durch einen ersten Netzwerkteilnehmer (28), ob eine Kommunikation mit einem zweiten Netzwerkteilnehmer (32) und einem dritten Netzwerkteilnehmer (34) gestört ist;Detektieren, durch den zweiten Netzwerkteilnehmer (32), ob eine Kommunikation mit dem ersten Netzwerkteilnehmer (28) und dem dritten Netzwerkteilnehmer (34) gestört ist;in Abhängigkeit von dem Detektieren, automatisches Reduzieren (82) einer Baudrate mit der der erste Netzwerkteilnehmer (28) Daten an den zweiten und dritten Netzwerkteilnehmer (32, 34) sendet und mit der der zweite Netzwerkteilnehmer (32) Daten an den ersten und den dritten Netzwerkteilnehmer (28, 34) sendet;Aufbauen einer Verbindung zwischen dem ersten Netzwerkteilnehmer (28) und dem zweiten Netzwerkteilnehmer (32), unter Verwendung der reduzierten Baudrate;Detektieren, durch den ersten Netzwerkteilnehmer (28) und/oder den zweiten Netzwerkteilnehmer (32), dass eine Kommunikation mit dem dritten Netzwerkteilnehmer (34) unter Verwendung der reduzierten Baudrate nicht möglich ist; undSpeichern (86) einer Information hinsichtlich der nicht möglichen Kommunikation mit dem dritten Netzwerkteilnehmer (34); wobei das Verfahren gekennzeichnet ist durchSenden eines Signals von einem des ersten und zweiten Netzwerkteilnehmers (28, 32) an den dritten Netzwerkteilnehmer (34); undMessen einer Zeitspanne bis zum Empfangen einer Reflexion des Signals.

Description

  • GEBIET
  • Die vorliegende Erfindung betrifft das Gebiet der Netzwerke. Insbesondere betrifft die vorliegende Erfindung das Gebiet des automatischen Eingrenzens eines physikalischen Netzwerkfehlers zur Laufzeit.
  • STAND DER TECHNIK
  • Aus der CN 1 04 009 856 A ist eine Vorrichtung zur Bestimmung der Position eines Fehlers in einem Feldbusnetzwerk bekannt. Die Vorrichtung umfasst ein Schaltmodul, das zum Umschalten einer aktuell verwendeten Baudrate des Feldbusnetzwerks auf eine voreingestellte Baudrate verwendet wird, wenn erkannt wird, dass ein Fehler im Feldbusnetzwerk auftritt, wobei die voreingestellte Baudrate niedriger ist als die aktuell verwendete Baudrate des Feldbusnetzwerks. Die Vorrichtung umfasst ferner ein Erkennungsmodul, das dazu dient, anhand der voreingestellten Baudrate Slaves zu erkennen, die normal im Feldbusnetzwerk arbeiten, und ein Bestimmungsmodul zum Bestimmen der Position, die einen Fehler aufweist, und einen Slave, der sich am entferntesten Ende der Slaves befindet, die normal arbeiten.
  • ZUSAMMENFASSUNG
  • Die vorliegende Erfindung schlägt ein Verfahren zum automatischen Eingrenzen eines physikalischen (d. h. auf der untersten Schicht des OSI-Modells angesiedelten) Netzwerkfehlers (bspw. eine unterbrochene elektrische Leitung oder ein Kurzschluss) zur Laufzeit in einem eine Vielzahl an Netzwerkteilnehmern aufweisenden drahtgebundenen Netzwerk, zur Durchführung des Verfahrens eingerichtete Vorrichtungen (Netzwerkteilnehmer), sowie ein zur Durchführung des Verfahrens eingerichtetes Netzwerk vor.
  • Das erfindungsgemäße Verfahren zum Eingrenzen eines physikalischen Netzwerkfehlers in einem, eine Vielzahl an Netzwerkteilnehmern aufweisenden drahtgebundenen Netzwerk umfasst ein Detektieren, durch einen ersten Netzwerkteilnehmer, ob eine Kommunikation mit einem zweiten Netzwerkteilnehmer und einem dritten Netzwerkteilnehmer gestört ist, ein Detektieren, durch den zweiten Netzwerkteilnehmer, ob eine Kommunikation mit dem ersten Netzwerkteilnehmer und dem dritten Netzwerkteilnehmer gestört ist, und in Abhängigkeit von dem Detektieren, ein automatisches Reduzieren einer Baudrate mit der der erste Netzwerkteilnehmer Daten an den zweiten und dritten Netzwerkteilnehmer sendet und mit der der zweite Netzwerkteilnehmer Daten an den ersten und den dritten Netzwerkteilnehmer sendet, ein Aufbauen einer Verbindung zwischen dem ersten Netzwerkteilnehmer und dem zweiten Netzwerkteilnehmer, unter Verwendung der reduzierten Baudrate, ein Detektieren, durch den ersten Netzwerkteilnehmer und/oder den zweiten Netzwerkteilnehmer, dass eine Kommunikation mit dem dritten Netzwerkteilnehmer unter Verwendung der reduzierten Baudrate nicht möglich ist und ein Speichern einer Information hinsichtlich der nicht möglichen Kommunikation mit dem dritten Netzwerkteilnehmer.
  • Das erfindungsgemäße Verfahren ermöglicht es, durch Reduzieren der Baudrate eine Kommunikation mit Netzwerkteilnehmern wiederherzustellen, die durch den physikalischen Netzwerkfehler beeinträchtigt werden. Dabei kann in vielen Fällen unterschieden werden zwischen Netzwerkverbindungen, die von dem physikalischen Netzwerkfehler unmittelbar betroffen sind (bspw. durch einen Verbindungsabbruch als Folge einer unterbrochenen elektrischen Leitung), und Netzwerkverbindungen, die von dem physikalischen Netzwerkfehler nur mittelbar betroffenen sind (bspw. durch Reflexionen am Ort der Leitungsunterbrechung). Durch die Unterscheidung zwischen unmittelbar und mittelbar betroffenen Netzwerkverbindungen kann die Lokalisierung des physikalischen Netzwerkfehlers eingegrenzt werden, da hinsichtlich des physikalischen Netzwerkfehlers primär die unmittelbar betroffenen Netzwerkverbindungen in Frage kommen. Dadurch kann der physikalische Netzwerkfehler lokal (auf die unmittelbar betroffenen Netzwerkverbindungen) eingegrenzt werden. Ferner kann bei Vorliegen eines Fehlers durch Ermittlung gemeinsamer Teilstücke aller unmittelbar betroffenen Netzwerkverbindungen der physikalische Netzwerkfehler weiter (lokal) eingegrenzt werden.
  • Das Verfahren umfasst ferner ein Senden eines Signals von einem des ersten und zweiten Netzwerkteilnehmers an den dritten Netzwerkteilnehmer und ein Messen einer Zeitspanne bis zum Empfangen einer Reflexion des Signals.
  • Durch ein Bestimmen der Signallaufzeit kann der Abstand zwischen dem das Signal aussendenden Netzwerkteilnehmer und dem physikalischen Netzwerkfehler berechnet werden, so dass der physikalische Netzwerkfehler noch weiter (lokal) eingegrenzt werden kann.
  • Vorzugsweise umfasst das automatische Reduzieren der Baudrate ein Reduzieren der Baudrate des ersten Netzwerkteilnehmers und des zweiten Netzwerkteilnehmers um einen vorbestimmten ersten Faktor, ein Detektieren, durch den ersten Netzwerkteilnehmer und den zweiten Netzwerkteilnehmer, dass eine Kommunikation mit dem dritten Netzwerkteilnehmer und dem jeweils anderen des ersten und des zweiten Netzwerkteilnehmers weiterhin gestört ist und, in Reaktion auf das Detektieren, ein Reduzieren der Baudrate des ersten Netzwerkteilnehmers und des zweiten Netzwerkteilnehmers um einen zweiten vorbestimmten Faktor.
  • Durch das schrittweise Reduzieren der Baudrate kann ein Grad der Betroffenheit der mittelbar betroffenen Netzwerkverbindungen bestimmt werden, wodurch der physikalische Netzwerkfehler noch weiter (lokal) eingegrenzt werden kann, da davon auszugehen ist, dass der Grad der Betroffenheit mit der Nähe zum physikalischen Netzwerkfehler korreliert.
  • Vorzugsweise umfasst das Verfahren ferner ein Aufbauen einer Verbindung zwischen dem ersten Netzwerkteilnehmer und einem vierten Netzwerkteilnehmer, unter Verwendung der, um den vorbestimmten ersten Faktor reduzierten Baudrate, und ein Speichern einer Information hinsichtlich der erzeugten Verbindung mit dem vierten Netzwerkteilnehmer, unter Verwendung der um den vorbestimmten ersten Faktor reduzierten Baudrate.
  • Durch das schrittweise Reduzieren der Baudrate kann ferner vermieden werden, dass mittelbar betroffene Netzwerkverbindungen mit unmittelbar betroffenen Netzwerkverbindungen verwechselt werden, wodurch Fehlinterpretationen vermieden werden können.
  • Vorzugsweise umfasst das Verfahren ferner ein Speichern, für jede einer Vielzahl reduzierter Baudraten, einer Information hinsichtlich unter Verwendung der reduzierten Baudrate möglicher Kommunikation mit Netzwerkteilnehmern und ein Anzeigen einer Erreichbarkeit der Netzwerkteilnehmer in einer topologischen Netzwerkansicht basierend auf den gespeicherten Informationen.
  • Unter der Formulierung „Anzeigen einer Erreichbarkeit der Netzwerkteilnehmer in einer topologischen Netzwerkansicht“ wird dabei insbesondere eine grafische Darstellung verstanden, in der unmittelbar betroffene Netzwerkverbindungen und mittelbar betroffene Netzwerkverbindungen unterschiedlich dargestellt werden. Das Anzeigen der Erreichbarkeit der Netzwerkteilnehmer in der topologischen Netzwerkansicht erlaubt damit insbesondere den physikalischen Netzwerkfehler in der Netzwerkansicht zu lokalisieren.
  • Die erfindungsgemäße Vorrichtung zum Eingrenzen eines physikalischen Netzwerkfehlers in einem, eine Vielzahl an Netzwerkteilnehmern aufweisenden Netzwerk, umfasst ein Kommunikationsmodul, wobei das Kommunikationsmodul dazu eingerichtet ist zu detektieren, ob eine Kommunikation mit zumindest einem einer Vielzahl an Netzwerkteilnehmern gestört ist und, wenn die Kommunikation mit zumindest einem der Vielzahl an Netzwerkteilnehmern gestört ist, eine Erreichbarkeit der Netzwerkteilnehmer unter Verwendung einer reduzierten Baudrate zu überprüfen, wobei die Vorrichtung dazu eingerichtet ist, eine Information hinsichtlich der Erreichbarkeit der Netzwerkteilnehmer unter Verwendung der reduzierten Baudrate einer Analyseeinheit bereitzustellen.
  • Wie oben ausgeführt, ermöglicht das Reduzieren der Baudrate eine Kommunikation mit durch den physikalischen Netzwerkfehler (bspw. eine unterbrochene elektrische Leitung oder ein Kurzschluss) beeinträchtigten (bspw. durch Reflexionen) Netzwerkteilnehmern wiederherzustellen, wodurch zwischen von dem physikalischen Netzwerkfehler unmittelbar und mittelbar betroffenen Netzwerkverbindungen unterschieden und damit der physikalische Netzwerkfehler (lokal) eingegrenzt werden kann. In diesem Zusammenhang ist unter dem Begriff „Erreichbarkeit“ das Vermögen eine Verbindung herzustellen allgemein und insbesondere das Vermögen eine Verbindung herzustellen über die Daten ohne Datenverlust oder im Wesentlichen ohne Datenverlust übermittelt werden können
  • Das Kommunikationsmodul ist ferner dazu eingerichtet, ein Signal an einen nicht erreichbaren Netzwerkteilnehmer zu senden und eine Zeitspanne bis zum Empfangen einer Reflexion des Signals zu messen.
  • Wie oben ausgeführt kann durch Messen der Signallaufzeit der Abstand zwischen dem das Signal aussendenden Netzwerkteilnehmer und dem physikalischen Netzwerkfehler berechnet werden, so dass der physikalische Netzwerkfehler weiter (lokal) eingegrenzt werden kann.
  • Vorzugsweise ist das Kommunikationsmodul ferner dazu eingerichtet, die Baudrate in Stufen zu verringern und die Erreichbarkeit der Netzwerkteilnehmer unter Verwendung verschiedener reduzierter Baudraten zu überprüfen.
  • Wie oben ausgeführt, kann durch das stufenweise Reduzieren der Baudrate ferner die Gefahr reduziert werden, dass mittelbar betroffene Netzwerkverbindungen für unmittelbar betroffene Netzwerkverbindungen gehalten werden, wodurch Fehlinterpretationen vermieden werden können.
  • Vorzugsweise ist das Kommunikationsmodul ferner dazu eingerichtet, für jede der verschiedenen reduzierten Baudraten, eine Information hinsichtlich der Erreichbarkeit der Netzwerkteilnehmer an die Analyseeinheit zu senden.
  • Dies ermöglicht eine zentrale Auswertung der Indikationen.
  • Das erfindungsgemäße Netzwerk umfasst eine Vielzahl an erfindungsgemäßen Vorrichtungen und eine Analyseeinheit, wobei die Analyseeinheit dazu eingerichtet ist Informationen hinsichtlich der Erreichbarkeit der Vorrichtungen von jeder der Vielzahl an Vorrichtungen zu empfangen und basierend auf den Informationen, einen physikalischen Netzwerkfehler einzugrenzen.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • Die Erfindung wird nachfolgend in der detaillierten Beschreibung anhand von Ausführungsbeispielen erläutert, wobei auf Zeichnungen Bezug genommen wird, in denen:
    • 1 eine schematische Ansicht einer Netzwerkumgebung zeigt, die ein BACnet-MS/TP-Bussystem umfasst;
    • 2 eine schematische Ansicht eines Busteilnehmers in dem BACnet-MS/TP-Bussystem zeigt;
    • 3 ein Flussdiagramm eines Prozesses zur automatischen Vergabe von Master-Adressen in dem BACnet MS/TP-Bussystem zeigt;
    • 4 ein Flussdiagramm eines Prozesses zum automatischen Anpassen der maximalen Token-Haltezeit eines Busteilnehmers in dem BACnet MS/TP-Bussystem zeigt;
    • 5 eine schematische Ansicht eines weiteren Busteilnehmers in dem BACnet-MS/TP-Bussystem zeigt;
    • 6 ein Flussdiagramm eines Prozesses zum automatischen Anpassen des Datenverkehrs in dem BACnet-MS/TP-Bussystem zeigt; und
    • 7 ein Flussdiagramm eines Prozesses zum automatischen Eingrenzen eines physikalischen Netzwerkfehlers zeigt.
  • Dabei sind in den Zeichnungen gleiche oder analoge Elemente durch identische Bezugszeichen gekennzeichnet.
  • DETAILLIERTE BESCHREIBUNG
  • 1 zeigt eine schematische Ansicht einer Netzwerkumgebung 10, die ein BACnet-MS/TP-Bussystem 12 umfasst. Das BACnet-MS/TP-Bussystem 12 umfasst eine Busleitung 14 (Zweidrahtbus), an die mehrere Busteilnehmer 16-28 angeschlossen sind. Die Busteilnehmer 16-28 sind im Betrieb unterteilt in Master-Busteilnehmer 16, 22 und 28 und Slave-Busteilnehmer 18 und 26. Ferner können ein oder mehrere Busteilnehmer 20 und 24 (physikalisch) an die Busleitung angeschlossen sein, die dazu vorgesehen sind, als Master-Busteilnehmer in den zwischen den Master-Busteilnehmern 16, 22 und 28 stattfindenden Token-Umlauf integriert zu werden. Bevor die Busteilnehmer 20 und 24 als Master-Busteilnehmer in den Token-Umlauf integriert werden, sind diese jedoch nur dazu berechtigt sind, auf Anfragen der Master-Busteilnehmer 16, 22 und 28 zu reagieren. Sie sind hingegen nicht dazu berechtigt, ohne auf eine Anfrage eines Master-Busteilnehmers 16, 22 oder 28 zu reagieren, Nachrichten an die anderen Busteilnehmer 16, 18, 22, 26 und 28 über den Bus, d. h. unter Benutzung der Busleitung 14 zu übertragen. Die in den Token-Umlauf zu integrierenden Busteilnehmer 20 und 24 stehen insofern den Slave-Busteilnehmern 18 und 26 gleich; unterscheiden sich jedoch von diesen, da sie dazu eingerichtet sind, zur Laufzeit als Master-Busteilnehmer in den Token-Umlauf des BACnet-MS/TP-Bussystems 12 integriert zu werden.
  • Die Busteilnehmer 16-28 können frei programmierbar sein und insbesondere dazu eingerichtet sein, eine oder mehrere Gebäudeautomatisierungsanwendungen zu implementieren, d. h. Anweisungen zu speichern, durch deren Ausführung zur Laufzeit eine oder mehrere Automatisierungsanwendungen in einem oder mehreren Gebäuden bzw. in einem oder mehreren Räumen eines Gebäudes bereitgestellt bzw. unterstützt werden. Bspw. kann der Master-Busteilnehmer 16 eine erste Gebäudeautomatisierungssteuerung und der Master-Busteilnehmer 22 eine zweite Gebäudeautomatisierungssteuerung implementieren. Die erste Gebäudeautomatisierungssteuerung kann bspw. eine Heizungs- und Belüftungssteuerung sein, die Heiz- und Kühlelemente in einem Raum eines Gebäudes und einen Zweig einer Belüftungsanlage des Gebäudes, der den Raum mit Frischluft versorgt und Abluft abführt, steuert. Die zweite Gebäudeautomatisierungssteuerung kann bspw. eine Lichtsteuerung sein, die Beleuchtungselemente in dem Raum steuert.
  • Der Master-Busteilnehmer 28 kann ferner einen Router implementieren, der das BACnet-MS/TP-Bussystem 12 mit einem Netzwerk 30 verbindet. Das Netzwerk 30 kann bspw. ein weiteres Gebäudeautomatisierungsnetzwerk sein, insbesondere ein weiteres BACnet-MS/TP-Netzwerk, ein BACnet-PTP-Netzwerk, ein BACnet-ARCNET-Netzwerk, ein BACnet-LonTalk-Netzwerk, ein BACnet-ZigBee-Netzwerk, ein BACnet-Ethernet-Netzwerk oder ein BACnet/IP-Netzwerk. Das Netzwerk 30 kann des Weiteren ein (zentrales) Gebäudesteuerungsgerät 32 umfassen, welches eine Überwachung und/oder Konfiguration der Busteilnehmer 16-28 ermöglicht. Das Gebäudesteuerungsgerät 32 kann insbesondere eine oder mehrere (dynamische) HTML-Seiten speichern und/oder aufrufen, über die Parameter der Busteilnehmer 16-28 abgerufen und gegebenenfalls eingestellt werden können. Des Weiteren kann das Gebäudesteuerungsgerät 32 ein tragbarer Rechner sein, der temporär über den Router mit dem BACnet-MS/TP-Bussystem 12 verbunden ist, bspw. zu Konfigurations- oder Wartungszwecken. Ferner kann das weitere Netzwerk 30 einen weiteren Router 34 umfassen, der dazu eingerichtet ist, das zentrale Gebäudesteuerungsgerät 32 mit einem LAN (Local Area Network), einem WAN (Wide Area Network), oder dem Internet zu verbinden. Insbesondere in dem Fall, dass das Gebäudesteuerungsgerät 32 ein tragbarer Rechner ist, kann der weitere Router 34 über eine Funkschnittstelle erreichbar sein.
  • Die Slave-Busteilnehmer 18 und 26 können dazu eingerichtet sein, Daten für die Master-Busteilnehmer 16, 22 und 28 bereitzustellen. Bspw. können die Slave-Busteilnehmer 18 und 26 Messgeräte implementieren, deren Messwerte von den Master-Busteilnehmern 16, 22 und 28 zyklisch oder azyklisch abgefragt werden können. Bspw. kann der Slave-Busteilnehmer 18 ein Temperaturmessgerät implementieren, welches Temperaturdaten bezüglich eines Raumes mittels eines mit dem Temperaturmessgerät gekoppelten Temperatursensors 36, der in dem Raum angeordnet ist, misst und diese der ersten Gebäudeautomatisierungssteuerung zur Verfügung stellt. Der Slave-Busteilnehmer 26 kann zudem ein Empfangsmodul umfassen, das dazu eingerichtet ist, drahtlos Signale von einem Sensor 38 zu empfangen. Der Sensor 38 kann bspw. ein Bewegungssensor sein, der detektiert, ob sich Personen in dem Raum aufhalten. Alternativ kann der Sensor 38 bspw. ein Sensor sein, der detektiert, ob ein Fenster oder eine Tür des Raumes geöffnet ist. Die von dem Slave-Busteilnehmer 26 gesammelten Daten können der ersten Gebäudeautomatisierungssteuerung und gegebenenfalls der zweiten Gebäudeautomatisierungssteuerung zur Verfügung gestellt werden.
  • Der als Master-Busteilnehmer in den zwischen den Master-Busteilnehmern 16, 22 und 28 stattfindenden Token-Umlauf integriert zu werdende Busteilnehmer 20 kann dazu eingerichtet sein, eine von den Master-Busteilnehmern 16 und 22 implementierte Gebäudeautomatisierungssteuerung zu unterstützen oder eine dritte Gebäudeautomatisierungssteuerung zu implementieren. Bspw. kann der Busteilnehmer 20 eine weitere Lichtsteuerung implementieren, die dazu vorgesehen ist, weitere Beleuchtungselemente in dem Raum zu steuern. Der als Master-Busteilnehmer in den zwischen den Master-Busteilnehmern 16, 22 und 28 stattfindenden Token-Umlauf integriert zu werdende Busteilnehmer 24 kann ebenfalls dazu eingerichtet sein, eine von den Master-Busteilnehmern 16 und 22 implementierte Gebäudeautomatisierungssteuerung zu unterstützen oder eine vierte Gebäudeautomatisierungssteuerung zu implementieren. Bspw. kann der Busteilnehmer 24 eine Steuerung implementieren, welche dazu eingerichtet ist, Verschattungselemente zu steuern. Die Verschattungselemente können insbesondere dazu vorgesehen sein, den Einfall von Tageslicht in den Raum zu begrenzen.
  • Wie in 2 gezeigt, umfasst der Busteilnehmer 24 einen Prozessor 40, einen mit dem Prozessor 40 gekoppelten nichtflüchtigen Speicher 42, der dazu eingerichtet ist, Daten und maschinenlesbare Anweisungen zu speichern, und ein Kommunikationsmodul 44, welches dazu eingerichtet ist, auf eine Schnittstelle 46 zuzugreifen, die in elektrischem Kontakt mit der Busleitung 14 steht. Die Schnittstelle 46 kann bspw. eine RS-485-Schnittstelle sein. Das Kommunikationsmodul 44 kann ein Empfangsmodul 48a und ein Sendemodul 48b umfassen. Das Empfangsmodul 48a kann dazu eingerichtet sein, über die Busleitung 14 übertragene Signale zu empfangen und dem Prozessor 40 zur Verfügung zu stellen. Das Sendemodul 48b kann dazu eingerichtet sein, Signale über die Busleitung 14 an (an die Busleitung angeschlossene) Busteilnehmer 16-22, 26 und 28 zu senden.
  • Das Empfangsmodul 48a und das Sendemodul 48b können dazu eingerichtet sein, ein paralleles Schreiben von Daten auf den Bus und Lesen von Daten von dem Bus zu ermöglichen. Insbesondere kann das Empfangsmodul 48a dazu eingerichtet sein, einen Spannungspegel auf der Busleitung 14 zu detektieren, während das Sendemodul 48b den Spannungspegel auf der Busleitung 14 ändert bzw. den Versuch unternimmt, den Spannungspegel aktiv zu beeinflussen. Das Vorhandensein parallel betreibbarer Empfangs- und Sendemodule 44 und 46 ermöglicht es dem Busteilnehmer 24 insbesondere zu überprüfen, ob von ihm über den Bus übertragene Daten gestört werden bzw. ob mehrere Busteilnehmer 16-28 gleichzeitig unterschiedliche Daten über den Bus übertragen.
  • Der Busteilnehmer 20 kann, wie der Busteilnehmer 24, ein Kommunikationsmodul 44 mit parallel betreibbarem Empfangs- und Sendemodulen 48a und 48b umfassen und dadurch in der Lage sein, Daten auf den Bus zu schreiben und gleichzeitig Daten von dem Bus zu lesen. Ferner können die Master-Busteilnehmer 16, 22 und 28 ebenfalls dazu eingerichtet sein, parallel Daten auf den Bus zu schreiben und gleichzeitig Daten von dem Bus zu lesen. Alternativ kann der Busteilnehmer 20 ein Kommunikationsmodul mit konsekutiv betreibbaren Empfangs- und Sendemodulen umfassen, welche dazu eingerichtet sein, abwechselnd entweder Daten auf den Bus zu schreiben oder Daten von dem Bus zu lesen. Ferner können die Master-Busteilnehmer 16, 22 und 28 ebenfalls dazu eingerichtet sein, abwechselnd entweder Daten auf den Bus zu schreiben oder Daten von dem Bus zu lesen.
  • Der Speicher 42 des Busteilnehmers 24 kann des Weiteren Anweisungen umfassen, die den Busteilnehmer 24 bei Ausführung der Anweisungen dazu programmieren, automatisch eine Master-Adresse zu wählen und eine Aufnahme in den Bus als Master-Busteilnehmer anzustreben. Der durch die in dem Speicher 42 gespeicherten Anweisungen initiierte Prozess 50 zum automatischen Einstellen einer Master-Adresse ist in 3 in Form eines Flussdiagramms dargestellt. Der Prozess 50 beginnt mit Prozessschritt 52, welcher das Analysieren des Datenverkehrs auf der Busleitung 14 umfasst. Bspw. kann der abgehörte Datenverkehr fortlaufend hinsichtlich belegter Master-Adressen analysiert werden. Die Analyse kann sich dabei über eine oder mehrere Kommunikations-Runden erstrecken, wobei eine Kommunikations-Runde einen kompletten Umlauf des Tokens über alle zu diesem Zeitpunkt vergebenen Master-Adressen umfasst (hierin auch als Token-Umlauf bezeichnet). Die Analyse ermöglicht es dem, eine Integration in den Token-Umlauf anstrebenden Busteilnehmer 24 zu bestimmen, welche Master-Adressen vergeben sind und welche Master-Adressen noch frei sind.
  • In Prozessschritt 54 wählt der, eine Integration in den Token-Umlauf anstrebende Busteilnehmer 24 eine nicht belegte vorläufige Master-Adresse, um diese in der nächsten entsprechenden Master-Such-Sequenz zu beanspruchen und als Master-Busteilnehmer in den Bus integriert zu werden. Um zu verhindern, dass die gewählte Master-Adresse zwar frei ist, aber in einem nicht verwendeten Adressbereich liegt, kann der Busteilnehmer 24 dazu programmiert sein, eine nicht belegte Master-Adresse zu wählen, die kleiner ist, als die (numerisch) größte verwendete Master-Adresse oder um eins größer ist, als die (numerisch) größte verwendete Master-Adresse. Stehen mehrere nicht belegte Master-Adressen zur Verfügung, die kleiner als die (numerisch) größte verwendete Master-Adresse sind, kann die vorläufige Master-Adresse mittels einer Zufallsfunktion ausgewählt werden. Die Zufallsfunktion kann als Parameter eine eindeutige Geräteadresse des Busteilnehmers 24 oder einen Zeitpunkt der Aktivierung des Busteilnehmers 24 verwenden.
  • In Prozessschritt 56 wird der Beginn der nächsten relevanten Master-Such-Sequenz abgewartet, d. h. der Master-Such-Sequenz, welche die von dem eine Integration in den Token-Umlauf anstrebenden Busteilnehmer 24 gewählte Master-Adresse hinsichtlich Bussystembeitritt wünschender Busteilnehmer abfragt. Eine relevante Master-Such-Sequenz ist somit eine Master-Such-Sequenz, die von einem Master-Busteilnehmer initiiert wird, dessen Master-Adresse aus der Menge der vergebenen Master-Adressen der gewählten Master-Adresse in absteigender Richtung (numerisch) am nächsten ist, bspw. dem Master-Busteilnehmer 28, und in der nach Busteilnehmern gefragt wird, die die gewählte Master-Adresse für sich beanspruchen. Im Falle, dass zwischen der vergebenen Master-Adresse, die der gewählten Master-Adresse in absteigender Richtung (numerisch) am nächsten ist, und der vergebenen Master-Adresse, die der gewählten Master-Adresse in aufsteigender Richtung (numerisch) am nächsten ist, mehrere freie Master-Adressen liegen, kann die Master-Such-Sequenz in mehrere Abschnitte unterteilt sein, nämlich dann, wenn kein Busteilnehmer die erste abgefragte Master-Adresse für sich beansprucht und der die Master-Such-Sequenz initiierende Master-Busteilnehmer sukzessive eine oder mehrere weitere Master-Adressen absucht, bis eine freie Master-Adresse von einem Busteilnehmer (erfolgreich) beansprucht wird, oder der abzusuchende Adressraum erfolglos abgesucht wurde, und die Master-Such-Sequenz beendet ist.
  • Der Prozess 50 wird nach dem Bestimmen des Beginns der nächsten relevanten Master-Such-Sequenz mit Prozessschritt 58 fortgesetzt, welcher das Abhören des Datenverkehrs während einer Beantwortungsphase der Master-Such-Sequenz hinsichtlich auf die Master-Such-Sequenz antwortender Busteilnehmer umfasst. Dabei können mehrere unterschiedliche Konstellationen auftreten. Ist der Busteilnehmer 24 der einzige Busteilnehmer, der in der Beantwortungsphase die gewählte Master-Adresse für sich beansprucht, so werden beim Abhören des Datenverkehrs während der Beantwortungsphase keine (Beantwortungs-) Aktivitäten anderer Busteilnehmer, bspw. der Busteilnehmer 16-22 und 26, registriert und dementsprechend von einer konfliktfreien Vergabe der gewählten Master-Adresse ausgegangen. Da die somit erfolgreich vergebene Master-Adresse von nun an in keiner Master-Such-Sequenz mehr abgefragt wird, kann auch kein weiterer Busteilnehmer diese erfolgreich für sich beanspruchen.
  • Gibt es neben dem Busteilnehmer 24 noch einen oder mehrere andere Busteilnehmer, wie bspw. den Busteilnehmer 20, der in der Beantwortungsphase die gewählte Master-Adresse für sich beansprucht, kann der Busteilnehmer 24 dazu eingerichtet sein, den daraus entstehenden latenten Adressen-Konfliktfall zu erkennen und, wenn möglich, aufzulösen. Beispielsweise kann der Busteilnehmer 24 dazu eingerichtet sein, eine geplante Beantwortung der Master-Such-Sequenz zu stornieren, wenn beim Abhören des Datenverkehrs während der Beantwortungsphase durch Analysieren des Datenverkehrs bestimmt wird, dass ein weiterer Busteilnehmer, bspw. der Busteilnehmer 20, die gewählte Master-Adresse für sich beansprucht.
  • Ferner kann der eine Integration in den Token-Umlauf anstrebende Busteilnehmer 24 dazu eingerichtet sein, eine bereits begonnene Beantwortung der Master-Such-Sequenz abzubrechen, wenn beim Abhören des Datenverkehrs während des Beantwortens der Master-Such-Sequenz durch Analysieren des Datenverkehrs bestimmt wird, dass ein weiterer Busteilnehmer, wie bspw. der Busteilnehmer 20, die gewählte Master-Adresse für sich beansprucht. Wenn der weitere Busteilnehmer 20 dazu in der Lage ist, Daten auf den Bus zu schreiben und gleichzeitig Daten von dem Bus zu lesen, kann der weitere Busteilnehmer 20 ferner ebenfalls dazu eingerichtet sein, eine bereits begonnene Beantwortung der Master-Such-Sequenz abzubrechen, wenn beim Abhören des Datenverkehrs während des Beantwortens der Master-Such-Sequenz durch Analysieren des Datenverkehrs bestimmt wird, dass der Busteilnehmer 24 die gewählte Master-Adresse für sich beansprucht. Da in diesem Fall beide, oder im Fall mehrerer analog programmierter und agierender Busteilnehmer diese die begonnene Beantwortung der Master-Such-Sequenz abbrechen, kann es vorkommen, dass die Master-Adresse in der aktuellen Master-Such-Sequenz nicht vergeben wird.
  • Um zu verhindern, dass sich die analog programmierten und agierenden Busteilnehmer weiterhin bzw. in folgenden Master-Such-Sequenzen stören, können einige oder alle der Busteilnehmer dazu eingerichtet sein, unterschiedliche Zeitspannen zu wählen, nach denen sie das Beantworten der Master-Such-Sequenz wiederholen. Beispielsweise kann der eine Integration in den Token-Umlauf anstrebende Busteilnehmer 24 dazu eingerichtet sein, eine Zeitspanne, nach der ein Beantworten der Master-Such-Sequenz oder folgender Master-Such-Sequenzen erfolgen kann, mittels eines Zufallsverfahrens oder eines dem Busteilnehmer 24 statisch zugeordneten Indikators zu bestimmen. Das Zufallsverfahren kann bspw. auf Parametern basieren, die zur Laufzeit ermittelt werden und deren Granularität groß genug ist, um mit hoher Wahrscheinlichkeit, bspw. in mehr als 99,99% der auftretenden Fälle, zu unterschiedlichen Zeitspannen zu führen. Analog können der weitere Busteilnehmer 20 oder im Falle einer Vielzahl an weiteren Busteilnehmern alle weiteren Busteilnehmer dazu eingerichtet sein, eine Zeitspanne, nach der ein Beantworten der Master-Such-Sequenz oder folgender Master-Such-Sequenzen erfolgen kann, mittels eines Zufallsverfahrens oder eines dem weiteren Busteilnehmer 20 bzw. der Vielzahl an weiteren Busteilnehmern statisch zugeordneten Indikators bzw. Indikatoren zu bestimmen, wobei vorzugsweise alle statisch zugeordneten Indikatoren unterschiedlich und somit eindeutig sind.
  • Ferner kann der Busteilnehmer 24 dazu eingerichtet sein, die gewählte Master-Adresse nicht einzustellen und stattdessen eine alternative Master-Adresse zu wählen, wenn beim Abhören des Datenverkehrs während der Beantwortungsphase der Master-Such-Sequenz durch Analysieren des Datenverkehrs bestimmt wird, dass der weitere Busteilnehmer 20 ebenfalls besagte Master-Adresse für sich beansprucht, obwohl der Busteilnehmer 24 die Master-Adresse bereits für sich beansprucht hat, d. h. die Beantwortung der Abfrage abgeschlossen hat. Ferner kann der eine Integration in den Token-Umlauf anstrebende Busteilnehmer 24 dazu eingerichtet sein, eine eingestellte Master-Adresse nicht zu verwenden und stattdessen eine alternative Master-Adresse zu wählen, wenn beim (fortlaufenden) Abhören des Datenverkehrs nach dem Ende Beantwortungsphase der Master-Such-Sequenz durch Analysieren des Datenverkehrs bestimmt wird, dass der weitere Busteilnehmer 20 die Master-Adresse des Busteilnehmers 24 verwendet. Dadurch wird es ermöglicht, Adress-Konflikte zu vermeiden bzw. aufzulösen, auch wenn der weitere Busteilnehmer 20 nicht dazu in der Lage ist, Daten auf den Bus zu schreiben und gleichzeitig Daten von dem Bus zu lesen und somit den latenten Adresskonflikt nicht erkennen kann.
  • Der Speicher 42 des Busteilnehmers 24 kann des Weiteren Anweisungen umfassen, die den Busteilnehmer 24 bei Ausführung der Anweisungen dazu programmieren, eine automatische Anpassung der maximalen Token-Haltezeit vorzunehmen. Der durch die in dem Speicher 42 gespeicherten Anweisungen initiierte Prozess 60 der automatischen Anpassung der maximalen Token-Haltezeit ist in 4 in Form eines Flussdiagramms dargestellt. Der Prozess 60 beginnt mit Prozessschritt 62, welcher das Analysieren des Datenverkehrs in dem BACnet-MS/TP-Bussystem 12 umfasst. Bspw. kann der Datenverkehr während zwei, drei, vier, fünf oder n (mit n größer 5) Token-Umläufen analysiert werden. Die Analyse kann darauf gerichtet sein zu bestimmen, ob die Master-Busteilnehmer 16, 22 und 28 in jedem Token-Umlauf (Nutz-) Daten, d. h. über durch das BACnet-MS/TP-Protokoll vorgeschriebene Buskommunikation hinausgehende Daten senden, oder ob es einen oder mehrere Token-Umläufe gibt, in denen ein Busteilnehmer keine (Nutz-) Daten sendet. Ferner kann die Analyse darauf gerichtet sein zu bestimmen, ob einer, mehrere oder alle der Master-Busteilnehmer 16, 22 und 28 in jedem Token-Umlauf (nahezu) gleichviel (Nutz-) Daten über den Bus senden, oder ob die Menge der (Nutz-) Daten in den Token-Umläufen (um mehr als einen vorbestimmten Abweichungsfaktor) um einen Mittelwert schwankt.
  • Des Weiteren kann die Analyse darauf gerichtet sein zu bestimmen, welche Gebäudeautomatisierungsanwendung(en) bzw. welche(n) Typ(en) von Gebäudeautomatisierungsanwendung(en) die Master-Busteilnehmer 16, 22 und 28 implementieren. Dazu kann beispielsweise der Busteilnehmer 24 dazu eingerichtet sein, die Master-Busteilnehmer 16, 22 und 28 hinsichtlich der von ihnen implementierten Gebäudeautomatisierungsanwendung(en) abzufragen. Zudem kann die Analyse darauf gerichtet sein zu bestimmen, wie zeitkritisch die von den Master-Busteilnehmern 16, 22 und 28 implementierte(n) Gebäudeautomatisierungsanwendung(en) ist/sind. Dabei kann diese Information direkt von den Master-Busteilnehmern 16, 22 und 28 abgefragt werden, oder in Hinblick auf den/die Typ(en) der implementierten Gebäudeautomatisierungsanwendung(en) abgeschätzt werden. Bspw. kann der der Busteilnehmer 24 Informationen speichern, die es erlauben, einer Vielzahl an Gebäudeautomatisierungsanwendungs-Typen maximale Token-Umlaufzeiten zuzuordnen.
  • In Prozessschritt 64 wird die Analyse mit dem Bestimmen eines Daten-Sende-Musters zumindest eines der Master-Busteilnehmer 16, 22 und 28 fortgesetzt. Als Daten-Sende-Muster wird in diesem Zusammenhang insbesondere ein Daten-Sende-Verhalten angesehen, aus dem sich Rückschlüsse über zukünftiges Daten-Sende-Verhalten gewinnen lässt. Umfasst das Daten-Sende-Verhalten eine zyklische Komponente, bspw. ein Senden der gleichen Datenmenge in jedem zweiten, dritten, vierten, fünften oder n-ten (mit n größer 5) Token-Umlauf, lässt sich dies als Teil eines Daten-Sende-Musters so interpretieren, dass auch zukünftig in jedem zweiten, dritten, vierten, fünften oder n-ten Token-Umlauf die gleiche Datenmenge gesendet wird. Das Daten-Sende-Muster basiert somit auf durch Analysieren des Datenverkehrs gewonnenen Regeln, aus denen auf ein zukünftiges Daten-Sende-Verhalten geschlossen werden kann. Ein zyklisches Verhalten des Master-Busteilnehmers 16 kann bspw. durch eine Fourier-Analyse des nach dem Master-Busteilnehmer 16 gefilterten Datenverkehrs bestimmen werden.
  • In Prozessschritt 66 wird die maximale Token-Haltezeit des Busteilnehmers 24 basierend auf dem Analysieren des Datenverkehrs angepasst. Senden beispielsweise alle oder eine Mehrzahl der Master-Busteilnehmer 16, 22 und 28 (Nutz-) Daten nur in jedem zweiten, dritten, vierten, fünften oder n-ten (mit n größer 5) Token-Umlauf, kann daraus geschlossen werden, dass eine Vergrößerung der Token-Umlaufzeit diese Master-Busteilnehmer 16, 22 und 28 nicht oder allenfalls gering beeinträchtigen wird. Senden hingegen alle oder die Mehrzahl der Master-Busteilnehmer 16, 22 und 28 in jedem Token-Umlauf, kann daraus geschlossen werden, dass eine Vergrößerung der Token-Umlaufzeit diese Master-Busteilnehmer 16, 22 und 28 unmittelbar beeinträchtigen wird. Der Busteilenehmer 24 kann ferner dazu eingerichtet sein, in diesem Fall eine Vergrößerung der maximalen Token-Haltezeit des Busteilnehmers 24 insbesondere nur dann vorzunehmen, wenn die maximale (d. h. die maximal gemessene) Sende-Puffer-Auslastung des Sendemoduls 48b in den hinsichtlich Datenverkehrs analysierten Token-Umläufen einen vorbestimmten Schwellenwert überschreitet.
  • Ferner kann festgelegt sein, dass im ersten Fall eine größere Erhöhung der maximalen Token-Haltezeit vorgenommen werden kann, als im zweiten Fall. Beispielsweise kann festgelegt sein, dass die Erhöhung im ersten Fall weniger als 10% oder weniger als 5% der maximalen Token-Haltezeit und im zweiten Fall mehr als 10% oder mehr als 20% der maximalen Token-Haltezeit beträgt. Des Weiteren kann der Busteilenehmer 24 dazu eingerichtet sein, in dem Fall, in dem die maximale Sende-Puffer-Auslastung des Sendemoduls 48b in den hinsichtlich Datenverkehrs analysierten Token-Umläufen einen vorbestimmten Schwellenwert nicht überschreitet bzw. einen weiteren Schwellenwert unterschreitet, die maximale Token-Haltezeit des Busteilnehmers 24 zu verringern. Der Busteilenehmer 24 kann ferner dazu eingerichtet sein, in diesem Fall eine Verringerung der maximalen Token-Haltezeit des Busteilnehmers 24 insbesondere nur dann vorzunehmen, wenn eine Mehrzahl oder alle der Master-Busteilnehmer 16, 22 und 28 in allen Token-Umläufen (Nutz-) Daten senden.
  • Der Prozess 60 kann ferner iterativ wiederholt werden, wenn das Analysieren des Datenverkehrs ergibt, dass sich das Daten-Sende-Muster eines oder mehrerer der Master-Busteilnehmer 16, 22 und 28 strukturell verändert, bspw. wenn der eine oder die mehreren Master-Busteilnehmer 16, 22 und 28 in zusätzlichen Token-Umläufen senden bzw. wenn der eine oder die mehreren Master-Busteilnehmer 16, 22 und 28 in weniger Token-Umläufen senden, wobei eine Vergrößerung oder Verringerung der maximalen Token-Haltezeit des Busteilnehmers 24 von Wiederholung zu Wiederholung betragsmäßig kleiner ausfallen kann, um eine Konvergenz der maximalen Token-Haltezeit auf einen bestimmten Wert zu erreichen. Ferner kann eine Wiederholung des Prozesses 60 daran anknüpfen, dass Master-Busteilnehmer 16, 22 und 28 aus dem Bus entfernt oder in den Bus integriert werden. Zudem kann das Anpassen der maximalen Token-Haltezeit des Busteilnehmers 24 nach Fairness-Gesichtspunkten erfolgen, wobei ein Sendeanteil des Busteilnehmers 24 und optional Sendeanteile der Master-Busteilnehmer 16, 22 und 28 bestimmt werden und die maximale Token-Haltezeit des Busteilnehmers 24 reduziert wird, wenn der Sendeanteil des Busteilnehmers 24 einen vorbestimmten Schwellenwert übersteigt und der Sendeanteil des Busteilnehmers 24 vergrößert wird, wenn der Sendeanteil des Busteilnehmers 24 einen vorbestimmten Schwellenwert unterschreitet, bzw. wenn ein Vergleich der Sendeanteile des Busteilnehmers 24 und der Master-Busteilnehmer 16, 22 und 28 ergibt, dass die maximale Token-Haltezeit des Busteilnehmers 24 von den maximalen Token-Haltezeiten der Master-Busteilnehmer16, 22 und 28 um jeweils mehr als einen vorgegebenen Schwellenwert abweicht.
  • Der Grad der Anpassung kann ferner auf der Sende-Puffer-Auslastung des Sendemoduls 48b in den hinsichtlich Datenverkehrs analysierten Token-Umläufen basieren. Übersteigt bspw. die maximale Sende-Puffer-Auslastung des Sendemoduls 48b einen vorbestimmten Schwellenwert, wie z. B. 80% oder 90% der maximalen (d. h. der maximal möglichen) Sende-Puffer-Auslastung, so kann der Busteilnehmer 24 dazu eingerichtet sein, eine Vergrößerung der maximalen Token-Haltezeit des Busteilnehmers 24 anzustreben, wobei festgelegt sein kann, dass die Vergrößerung desto stärker ausfällt, je stärker die maximale Sende-Puffer-Auslastung des Sendemoduls 48b den vorbestimmten Schwellenwert übersteigt. Unterschreitet hingegen die maximale Sende-Puffer-Auslastung des Sendemoduls 48b einen vorbestimmten Schwellenwert, wie z. B. 20% oder 10% der maximalen Sende-Puffer-Auslastung, so kann der Busteilnehmer 24 dazu eingerichtet sein, eine Verringerung der maximalen Token-Haltezeit des Busteilnehmers 24 anzustreben, wobei festgelegt sein kann, dass die Verringerung desto stärker ausfällt, je stärker die maximale Sende-Puffer-Auslastung des Sendemoduls 48b den vorbestimmten Schwellenwert unterschreitet.
  • 5 zeigt eine schematische Ansicht des Master-Busteilnehmers 28 in einem Ausführungsbeispiel, in dem der Master-Busteilnehmer 28 einen Router implementiert. Wie in 5 gezeigt, umfasst der Master-Busteilnehmer 28 einen Prozessor 40 und einen mit dem Prozessor 40 gekoppelten nichtflüchtigen Speicher 42, der dazu eingerichtet ist, Daten und maschinenlesbare Anweisungen zu speichern. Der nichtflüchtige Speicher 42 kann insbesondere Anweisungen speichern, die den Busteilnehmer 28 bei Ausführung der Anweisungen dazu programmieren, die in Zusammenhang mit 3 und 4 beschriebenen Prozesse 50 und 60 zu implementieren. Der Master-Busteilnehmer 28 umfasst ferner ein Kommunikationsmodul 44, welches dazu eingerichtet ist, auf eine (physikalische) Schnittstelle 46 zuzugreifen, die in elektrischem Kontakt mit der Busleitung 14 steht. Die Schnittstelle 46 kann bspw. eine RS-485-Schnittstelle sein. Das Kommunikationsmodul 44 kann ferner das in Zusammenhang mit 2 beschriebene Empfangsmodul 48a und das in Zusammenhang mit 2 beschriebene Sendemodul 48b umfassen.
  • Der Master-Busteilnehmer 28 kann zudem ein weiteres Kommunikationsmodul 68 umfassen, welches dazu eingerichtet ist, auf eine weitere (physikalische) Schnittstelle zuzugreifen, die in elektrischem Kontakt mit einem Kommunikationskanal 70 steht. Das weitere Kommunikationsmodul 68 kann dazu eingerichtet sein, über den Kommunikationskanal 70 übertragene Signale zu empfangen (und dem Prozessor 40 zur Verfügung zu stellen) und Signale über den Kommunikationskanal 70 zu versenden. Ferner kann das weitere Kommunikationsmodul 68 dazu eingerichtet sein, über den mit der weiteren Schnittstelle verbundenen Kommunikationskanal 70 empfangene Daten an das Kommunikationsmodul 44 weiterzureichen, welches dazu eingerichtet sein kann, die von dem weiteren Kommunikationsmodul 68 empfangenen Daten über die Schnittstelle 46 zu versenden. Des Weiteren kann das Kommunikationsmodul 44 dazu eingerichtet sein, über die Schnittstelle 46 empfangene Daten an das weitere Kommunikationsmodul 68 weiterzureichen, welches dazu eingerichtet sein kann, die von dem Kommunikationsmodul 44 empfangenen Daten über die weitere Schnittstelle zu versenden. In diesem Fall ermöglicht der Router eine Datenkommunikation zwischen dem BACnet-MS/TP-Bussystem 12 und dem Netzwerk 30.
  • Der Speicher 42 des Master-Busteilnehmers 28 kann des Weiteren Anweisungen umfassen, die den Master-Busteilnehmer 28 bei Ausführung der Anweisungen dazu programmieren, eine automatische Anpassung des Datenverkehrs in dem BACnet-MS/TP-Bussystem 12 zu initiieren. Der durch die in dem Speicher 42 gespeicherten Anweisungen initiierte Prozess 72 der automatischen Anpassung des Datenverkehrs ist in 6 in Form eines Flussdiagramms dargestellt. Der Prozess 72 beginnt mit Prozessschritt 74, in welchem der Master-Busteilnehmer 28 während der Laufzeit bestimmt, dass eine Auslastung des Sendepuffers des in dem Master-Busteilnehmer 28 implementierten Routers einen vorbestimmten Schwellenwert überschreitet. Nach dem Bestimmen, dass die Auslastung des Sendepuffers einen vorbestimmten Schwellenwert überschreitet, wird der Prozess 72 mit Prozessschritt 76 fortgeführt, in dem von dem Master-Busteilnehmer 28 eine Nachricht an mindestens einen weiteren der Master-Busteilnehmer 16 und 22 gesendet wird, wobei die Nachricht eine Aufforderung enthält, die Menge der über das BACnet-MS/TP-Bussystem 12 gesendeten Daten zu verringern. Bspw. kann der Master-Busteilnehmer 28 eine erste Nachricht an die Adresse des Master-Busteilnehmers 16 und eine zweite Nachricht an die Adresse des Master-Busteilnehmers 22 senden. Alternativ kann einer der Master-Busteilnehmer 16 und 28 oder können die Master-Busteilnehmer 16 und 28 dazu eingerichtet sein, über den Bus gesendete Nachrichten, auch wenn sie nicht explizit an die Master-Busteilnehmer 16 und 28 adressiert sind, daraufhin zu untersuchen, ob sie eine Aufforderung enthalten, die Menge der über das BACnet-MS/TP-Bussystem 12 gesendeten Daten zu verringern. Bspw. kann einer der Master-Busteilnehmer 16 und 28 oder können die Master-Busteilnehmer 16 und 28 dazu eingerichtet sein, über den Bus gesendete Nachrichten daraufhin zu untersuchen, ob sie eine Aufforderung enthalten, die Menge der über das BACnet-MS/TP-Bussystem 12 gesendeten Daten zu verringern, wenn die Nachrichten an eine vorbestimmte Adresse adressiert sind.
  • Die Nachricht kann einen Indikator unterschiedlicher Dringlichkeitsstufen umfassen. Ist der Indikator bspw. einer ersten Dringlichkeitsstufe zugeordnet, unterteilen die Master-Busteilnehmer 16 und 22 die von ihnen zu sendenden Daten hinsichtlich ihrer Priorität und verzögern den Versand von Daten geringerer Priorität. Ist der Indikator bspw. einer zweiten höheren Dringlichkeitsstufe zugeordnet, setzen die Master-Busteilnehmer 16 und 22 den Versand von Daten geringerer Priorität aus. Ist der Indikator ferner bspw. einer dritten, noch höheren Dringlichkeitsstufe zugeordnet, setzen die die Master-Busteilnehmer 16 und 22 zudem den Versand von Nutzdaten für eine bestimmte Zeitdauer gänzlich aus. Ist in der Nachricht ein Token-Haltezeit-Flag gesetzt, verringern die Master-Busteilnehmer 16 und 22 ihre maximale Token-Haltezeit. Ist in der Nachricht ein Baudraten-Erhöhungs-Flag gesetzt, erhöhen die Master-Busteilnehmer 16 und 22 ihre Baudrate. Ist der Indikator hingegen bspw. einer vierten Dringlichkeitsstufe zugeordnet, kehren die Master-Busteilnehmer 16 und 22 zu ihrem normalen (ursprünglichen) Sendezustand zurück. Alternativ kann das Zurückkehren in den normalen Sendezustand durch den Ablauf einer Zeitdauer ausgelöst werden, wobei jeder Dringlichkeitsstufe eine vorbestimmte Zeitdauer zugeordnet sein kann oder eine jeweilige Zeitdauer in der Nachricht enthalten sein kann. Die Zeitdauer kann dabei mit dem Empfang der Nachricht beginnen und enden, wenn die durch die Zeitdauer repräsentierte Zeit verstrichen ist. Ferner können die Master-Busteilnehmer 16 und 22 dazu eingerichtet sein, wenn die Auslastung ihrer Sendepuffer einen vorbestimmten Schwellenwert überschreitet, den Versand von Nutzdaten von sich aus wiederaufzunehmen. Ferner kann der Master-Busteilnehmer 28 des Weiteren dazu eingerichtet sein, seine maximale Token-Haltezeit zu verlängern. Dies ist insbesondere dann angezeigt, wenn durch die im Vorhergehen beschriebene automatische Anpassung des Datenverkehrs in dem BACnet-MS/TP-Bussystem 12 die Sendepuffer-Auslastung des Master-Busteilnehmers 28 nicht (dauerhaft) unter einen vorbestimmten Schwellenwert reduziert werden kann.
  • Der Speicher 42 des Master-Busteilnehmers 28 kann des Weiteren Anweisungen umfassen, die den Master-Busteilnehmer 28 bei Ausführung der Anweisungen dazu programmieren, einen Prozess 78 zur Eingrenzung eines physikalischen Netzwerkfehlers in dem Netzwerk 30 zu unterstützen. Der durch die in dem Speicher 42 gespeicherten Anweisungen initiierte Prozess 78 zum Eingrenzen eines physikalischen Netzwerkfehlers ist in 7 in Form eines Flussdiagramms dargestellt. Der Prozess 78 beginnt mit Prozessschritt 80, in welchem der Master-Busteilnehmer 28 detektiert, dass eine Kommunikation mit dem Gebäudesteuerungsgerät 32 und dem Router 34 gestört ist. In Prozessschritt 82 reduziert der Master-Busteilnehmer 28 daraufhin automatisch seine Baudrate. Durch das Reduzieren der Baudrate wird die Störanfälligkeit der Kommunikation verringert. In Prozessschritt 84 detektiert der Master-Busteilnehmer 28, dass zu einem Teil der Netzwerkteilnehmer, nämlich dem Gebäudesteuerungsgerät 32, eine Verbindung aufgebaut werden kann. In Prozessschritt 86 speichert der Master-Busteilnehmer 28 eine Information hinsichtlich bei der reduzierten Baudrate nicht erreichbarer Netzwerkteilnehmer, nämlich des weiteren Routers 34.
  • Der Master-Busteilnehmer 28 kann ferner dazu eingerichtet sein, die Baudrate stufenweise zu reduzieren und für jede Baudratenstufe zu versuchen, eine Verbindung mit den weiteren Netzwerkteilnehmern 32 und 34 aufzubauen, und zu jeder Baudrate eine Information hinsichtlich der erreichbaren Netzwerkteilnehmer zu speichern. Dabei kann jeder Netzwerkteilnehmer ausgehend von einem Störungsbeginn seien Baudrate stufenweise verringern, wobei jeder Netzwerkteilnehmer auf jeder Stufe eine vorbestimmte Zeit verharrt und einen verbindungsaufbau mit allen Netzwerkteilnehmern versucht, bspw. durch Senden einer Broadcast-Nachricht. Alternativ kann anstatt einer stufenweisen Reduktion die Baudrate auf einen Minimalwert gesetzt werden und, wenn mit zumindest einigen der Netzwerkteilnehmer eine Kommunikation wieder möglich ist, an diese Netzwerkteilnehmer eine Aufforderung übersandt werden, die Baudrate stufenweise zu erhöhen, wobei jeder Netzwerkteilnehmer dazu eingerichtet ist, Informationen darüber zu speichern, bei welcher Baudrate die Kommunikation mit Netzwerkteilnehmern, zu denen bei einer geringeren Baudrate noch eine Verbindung möglich war, abreißt. Des Weiteren oder alternativ können die Informationen eine Fehlerraten enthalten aus denen der Grad der Kommunikationsstörung zu jedem Netzwerkteilnehmer ersichtlich ist.
  • Analog dazu kann das Gebäudesteuerungsgerät 32 dazu eingerichtet sein, ebenfalls den Prozess 78 zu implementieren. Ferner kann das Gebäudesteuerungsgerät 32 dazu eingerichtet sein, die Information des Master-Busteilnehmers 28 hinsichtlich des nicht erreichbaren Routers 34 unter Verwendung der reduzierten Baudrate zu empfangen. Ferner kann das Gebäudesteuerungsgerät 32 dazu eingerichtet sein, eine Erreichbarkeitskarte basierend auf den empfangenen und gespeicherten Informationen zu erstellen. Die Erreichbarkeitskarte kann insbesondere grafisch anzeigen, über welche Netzwerkverbindungen bei welcher Baudrate eine Verbindung zwischen Netzwerkteilnehmern möglich war und unterstützt dadurch das Eingrenzen des physikalischen Netzwerkfehlers. Bspw. kann das Gebäudesteuerungsgerät 32 eine Analyseeinheit umfassen, welche dazu eingerichtet ist, Informationen hinsichtlich nicht erreichbarer Netzwerkteilnehmer von allen am Prozess beteiligten Netzwerkteilnehmern zu empfangen und bspw. in Form einer Erreichbarkeitskarte für jede Baudrate grafisch darzustellen.
  • BEZUGSZEICHENLISTE
  • 10
    Netzwerkumgebung
    12
    Bussystem
    14
    Busleitung
    16
    Busteilnehmer
    18
    Busteilnehmer
    20
    Busteilnehmer
    22
    Busteilnehmer
    24
    Busteilnehmer
    26
    Busteilnehmer
    28
    Busteilnehmer
    30
    Netzwerk
    32
    Gebäudesteuerungssystem
    34
    Router
    36
    Temperatursensor
    38
    Sensor
    40
    Prozessor
    42
    Speicher
    44
    Kommunikationsmodul
    46
    Schnittstelle
    48a
    Empfangsmodul
    48b
    Sendemodul
    50
    Prozess
    52-58
    Prozessschritte
    60
    Prozess
    62-66
    Prozessschritte
    68
    Kommunikationsmodul
    70
    Kommunikationskanal
    72
    Prozess
    74-76
    Prozessschritte
    78
    Prozess
    80-84
    Prozessschritte

Claims (7)

  1. Verfahren zum Eingrenzen eines physikalischen Netzwerkfehlers in einem eine Vielzahl an Netzwerkteilnehmern aufweisenden drahtgebundenen Netzwerk (30), umfassend: Detektieren, durch einen ersten Netzwerkteilnehmer (28), ob eine Kommunikation mit einem zweiten Netzwerkteilnehmer (32) und einem dritten Netzwerkteilnehmer (34) gestört ist; Detektieren, durch den zweiten Netzwerkteilnehmer (32), ob eine Kommunikation mit dem ersten Netzwerkteilnehmer (28) und dem dritten Netzwerkteilnehmer (34) gestört ist; in Abhängigkeit von dem Detektieren, automatisches Reduzieren (82) einer Baudrate mit der der erste Netzwerkteilnehmer (28) Daten an den zweiten und dritten Netzwerkteilnehmer (32, 34) sendet und mit der der zweite Netzwerkteilnehmer (32) Daten an den ersten und den dritten Netzwerkteilnehmer (28, 34) sendet; Aufbauen einer Verbindung zwischen dem ersten Netzwerkteilnehmer (28) und dem zweiten Netzwerkteilnehmer (32), unter Verwendung der reduzierten Baudrate; Detektieren, durch den ersten Netzwerkteilnehmer (28) und/oder den zweiten Netzwerkteilnehmer (32), dass eine Kommunikation mit dem dritten Netzwerkteilnehmer (34) unter Verwendung der reduzierten Baudrate nicht möglich ist; und Speichern (86) einer Information hinsichtlich der nicht möglichen Kommunikation mit dem dritten Netzwerkteilnehmer (34); wobei das Verfahren gekennzeichnet ist durch Senden eines Signals von einem des ersten und zweiten Netzwerkteilnehmers (28, 32) an den dritten Netzwerkteilnehmer (34); und Messen einer Zeitspanne bis zum Empfangen einer Reflexion des Signals.
  2. Verfahren nach Anspruch 1, wobei das automatische Reduzieren (82) der Baudrate umfasst: Reduzieren der Baudrate des ersten Netzwerkteilnehmers (28) und des zweiten Netzwerkteilnehmers (32) um einen vorbestimmten ersten Faktor; Detektieren, durch den ersten Netzwerkteilnehmer (28) und den zweiten Netzwerkteilnehmer (32), dass eine Kommunikation mit dem dritten Netzwerkteilnehmer (34) und dem jeweils anderen des ersten und des zweiten Netzwerkteilnehmers (28, 32) weiterhin gestört ist; und in Reaktion auf das Detektieren, Reduzieren der Baudrate des ersten Netzwerkteilnehmers (28) und des zweiten Netzwerkteilnehmers (32) um einen zweiten vorbestimmten Faktor.
  3. Verfahren nach Anspruch 2, ferner umfassend: Speichern, für jede Baudrate einer Vielzahl reduzierter Baudraten, einer Information hinsichtlich einer möglichen Kommunikation mit Netzwerkteilnehmern (28, 32, 34) unter Verwendung der reduzierten Baudrate; und Anzeigen einer Erreichbarkeit der Netzwerkteilnehmer (28, 32, 34) in einer topologischen Netzwerkansicht basierend auf den gespeicherten Informationen.
  4. Vorrichtung (32) zum Eingrenzen eines physikalischen Netzwerkfehlers in einem eine Vielzahl an Netzwerkteilnehmern aufweisenden Netzwerk (30), umfassend: ein Kommunikationsmodul, wobei das Kommunikationsmodul dazu eingerichtet ist: zu detektieren, ob eine Kommunikation mit zumindest einem einer Vielzahl an Netzwerkteilnehmern (28, 34) gestört ist; und wenn eine Kommunikation mit zumindest einem der Vielzahl an Netzwerkteilnehmern (28, 34) gestört ist, eine Erreichbarkeit der Netzwerkteilnehmer (28, 34) unter Verwendung einer reduzierten Baudrate zu überprüfen; wobei das Kommunikationsmodul dazu eingerichtet ist, eine Information hinsichtlich der Erreichbarkeit der Netzwerkteilnehmer (28, 34) unter Verwendung der reduzierten Baudrate einer Analyseeinheit bereitzustellen; wobei die Vorrichtung dadurch gekennzeichnet ist, dass das Kommunikationsmodul ferner dazu eingerichtet ist: ein Signal an einen nicht erreichbaren Netzwerkteilnehmer (34) zu senden; und eine Zeitspanne bis zum Empfangen einer Reflexion des Signals zu messen.
  5. Vorrichtung (32) nach Anspruch 4 wobei das Kommunikationsmodul ferner dazu eingerichtet ist, die Baudrate in Stufen zu verringern und die Erreichbarkeit der Netzwerkteilnehmer (28, 32) unter Verwendung verschiedener reduzierter Baudraten zu überprüfen.
  6. Vorrichtung (32) nach Anspruch 5, wobei das Kommunikationsmodul ferner dazu eingerichtet ist, für jede der verschiedenen reduzierten Baudraten, eine Information hinsichtlich der Erreichbarkeit der Netzwerkteilnehmer an die Analyseeinheit zu senden.
  7. Netzwerk (30), umfassend: eine Vielzahl an Vorrichtungen (28, 32, 34) nach einem der Ansprüche 4 bis 6; und die Analyseeinheit, wobei die Analyseeinheit dazu eingerichtet ist: Informationen hinsichtlich der Erreichbarkeit der Vorrichtungen (28, 32, 34) von jeder der Vielzahl an Vorrichtungen (28, 32, 34) zu empfangen; und basierend auf den Informationen, einen physikalischen Netzwerkfehler einzugrenzen.
DE102016004095.5A 2016-04-05 2016-04-05 Automatisches Eingrenzen eines physikalischen Netzwerkfehlers zur Laufzeit Active DE102016004095B4 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE102016004095.5A DE102016004095B4 (de) 2016-04-05 2016-04-05 Automatisches Eingrenzen eines physikalischen Netzwerkfehlers zur Laufzeit
US15/479,625 US10411952B2 (en) 2016-04-05 2017-04-05 Automatic localization of a physical network fault at runtime

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102016004095.5A DE102016004095B4 (de) 2016-04-05 2016-04-05 Automatisches Eingrenzen eines physikalischen Netzwerkfehlers zur Laufzeit

Publications (2)

Publication Number Publication Date
DE102016004095A1 DE102016004095A1 (de) 2017-10-05
DE102016004095B4 true DE102016004095B4 (de) 2024-02-08

Family

ID=59886103

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102016004095.5A Active DE102016004095B4 (de) 2016-04-05 2016-04-05 Automatisches Eingrenzen eines physikalischen Netzwerkfehlers zur Laufzeit

Country Status (2)

Country Link
US (1) US10411952B2 (de)
DE (1) DE102016004095B4 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
NL2032856B1 (en) * 2022-08-25 2024-03-05 Chk Dev B V Method for operating lighting system, a motion sensor, and a lighting system including the same

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4390947A (en) 1979-02-27 1983-06-28 Phillips Petroleum Company Serial line communication system
DE102012000185A1 (de) 2012-01-09 2013-07-11 Siemens Aktiengesellschaft Verfahren zum Betreiben eines Kommunikationsnetzwerkes und Netzwerkanordnung
CN104009856A (zh) 2013-02-22 2014-08-27 西门子公司 确定现场总线网络中故障的位置的装置和方法

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5157667A (en) * 1990-04-30 1992-10-20 International Business Machines Corporation Methods and apparatus for performing fault isolation and failure analysis in link-connected systems
US5390351A (en) * 1992-03-06 1995-02-14 Pitney Bowes Inc. System for communicating with plural nodes in predetermined intervals depended on integers assigned and changed based upon configuration thereof
US6385203B2 (en) * 1996-03-29 2002-05-07 Cisco Technology, Inc. Communication server apparatus and method
US6631520B1 (en) * 1999-05-14 2003-10-07 Xilinx, Inc. Method and apparatus for changing execution code for a microcontroller on an FPGA interface device
US7283583B2 (en) * 2001-01-11 2007-10-16 Tioga Technologies, Inc. Adaptive rate transmission with dual noise margins
US7031346B2 (en) * 2001-07-20 2006-04-18 Adtran, Inc. System for providing extended range ADSL service with auxiliary pots channel over single-line digital subscriber link
US20040218591A1 (en) * 2003-04-29 2004-11-04 Craig Ogawa Bridge apparatus and methods of operation
US7614555B2 (en) * 2004-09-09 2009-11-10 The Gillette Company RFID sensor array
US7489626B2 (en) * 2005-02-16 2009-02-10 Dell Products L.P. Method of using cable test to modify teaming failover algorithm
US10541833B2 (en) * 2013-12-30 2020-01-21 Schneider Electric It Corporation System and method for automatically selecting baud rate in a CAN network

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4390947A (en) 1979-02-27 1983-06-28 Phillips Petroleum Company Serial line communication system
DE102012000185A1 (de) 2012-01-09 2013-07-11 Siemens Aktiengesellschaft Verfahren zum Betreiben eines Kommunikationsnetzwerkes und Netzwerkanordnung
CN104009856A (zh) 2013-02-22 2014-08-27 西门子公司 确定现场总线网络中故障的位置的装置和方法

Also Published As

Publication number Publication date
US20170288954A1 (en) 2017-10-05
US10411952B2 (en) 2019-09-10
DE102016004095A1 (de) 2017-10-05

Similar Documents

Publication Publication Date Title
EP2622826B1 (de) Verfahren zur automatischen adressvergabe an gleichartige busteilnehmer
DE102009045055B4 (de) Verfahren zum Konfigurieren einer Feldbusschnittstelle
EP1309920B1 (de) Adressvergabeverfahren für mindestens einen neu an ein bussystem angeschlossenen busteilnehmer
EP2266297B1 (de) Automatische busadressvergabe mittels kollisionsprüfung
DE102014101338A1 (de) Kommunikationsnetz und Verfahren zum Kommunizieren in einem Kommunikationsnetz
EP2586162B1 (de) Priorisierte übertragung von datentelegrammen
EP2733910B1 (de) BUS-System, Verfahren zum Betrieb eines BUS-Systems und fluidisches System mit einem BUS-System
EP3427467A1 (de) Verfahren zur konfiguration von kommunikationsgeräten eines industriellen automatisierungssystems und konfigurationsdatenverteilereinheit
EP3854028B1 (de) Verfahren zum erfassen von netzwerkteilnehmern in einem automatisierungsnetzwerk und automatisierungsnetzwerk
EP1320979A1 (de) Verfahren und vorrichtung zur ermittlung der netztopologie eines bussystems
CN106411995A (zh) 建立通信连接的方法和控制设备
DE102016004095B4 (de) Automatisches Eingrenzen eines physikalischen Netzwerkfehlers zur Laufzeit
EP2484058B1 (de) Adressierungsverfahren und kommunikationsnetzwerk mit einem solchen adressierungsverfahren
EP3092748B1 (de) Verfahren und system zur diagnose von übertragungs-störungen in einem netzwerk gemäss opc ua standard
DE60221566T2 (de) Verfahren und einrichtung zum datentransfer in einem telekommunikationssystem
CN101170470B (zh) 用于操作现场总线的方法
WO2013087432A1 (de) Verfahren zur übertragung von daten in einem kommunikationsnetz
EP1540897A2 (de) Verfahren und system zur bestimmung der topologie eines modularen analyse-systems
DE102016004105B3 (de) Automatisches Anpassen der maximalen Token-Haltezeit in BACNET-MS/TP-Bussystemen zur Laufzeit
WO2011072958A1 (de) Verfahren zum zuweisen einer polling-adresse an ein feldgerät
DE102016004127B3 (de) Automatische Begrenzung des Datenverkehrs in, einen Router umfassenden BACNET-MS/TP-Bussystemen zur Laufzeit
DE102016004109A1 (de) Automatisches Vergeben vom Master-Adressen in BACNET-MS/TP-Bussystemen zur Laufzeit
DE102005047986B4 (de) Verfahren und Anordnung zur Identifikation einer Netzwerkstation
EP2232782B1 (de) Verfahren zur konfiguration von adressen in einem kommunikationsnetzwerk
EP1885100B1 (de) Verfahren zur automatischen Adressvergabe an einen Kommunikationsteilnehmer und Kommunikationsteilnehmer

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0012260000

Ipc: H04L0043000000

R082 Change of representative

Representative=s name: KOPLIN PATENTANWALTSGESELLSCHAFT MBH, DE

Representative=s name: KOPLIN, MORITZ, DR., DE

R016 Response to examination communication
R018 Grant decision by examination section/examining division
R082 Change of representative

Representative=s name: KOPLIN PATENTANWALTSGESELLSCHAFT MBH, DE