DE102016004105B3

DE102016004105B3 - Automatisches Anpassen der maximalen Token-Haltezeit in BACNET-MS/TP-Bussystemen zur Laufzeit

Info

Publication number: DE102016004105B3
Application number: DE102016004105.6A
Authority: DE
Inventors: Georg Westerkamp; Lars Friedrich
Original assignee: Wago Verwaltungs GmbH
Current assignee: Wago Verwaltungs GmbH
Priority date: 2016-04-05
Filing date: 2016-04-05
Publication date: 2017-06-22
Anticipated expiration: 2036-04-06
Also published as: US10397020B2; US20170288900A1

Abstract

Bereitgestellt wird ein Verfahren zum automatischen Anpassen einer maximalen Token-Haltezeit eines ersten Busteilnehmers in einem BACnet-MS/TP-Bussystem. Das Verfahren umfasst das Analysieren eines Datenverkehrs in dem Bussystem während einer ersten Zeitspanne und das Anpassen einer maximalen Token-Haltezeit des ersten Busteilnehmers basierend auf dem Analysieren des Datenverkehrs während der ersten Zeitspanne, wobei das Analysieren des Datenverkehrs während der ersten Zeitspanne das Bestimmen eines Daten-Sende-Musters eines zweiten Busteilnehmers umfasst, wobei das Daten-Sende-Muster des zweiten Busteilnehmers definiert ist durch ein gemessenes Datenvolumen des zweiten Busteilnehmers und dessen zeitlicher Verteilung.

Description

GEBIET
Die vorliegende Erfindung betrifft das Gebiet der Bussysteme. Insbesondere betrifft die vorliegende Erfindung das Gebiet des automatischen Anpassens der maximalen Token-Haltezeit in BACnet-(Building Automation and Control Networks) MS/TP-(Master-Slave/Token-Passing)Bussystemen zur Laufzeit.
HINTERGRUND
Bei Bussystemen, wie dem BACnet-MS/TP-Bussystem, greifen alle Busteilnehmer auf die gleiche physikalische Ressource, d. h. auf die gleichen Drahtleitungen zu. Um Daten über besagte Drahtleitungen (im Folgenden auch als die „Busleitung” oder den „Bus” bezeichnet) störungsfrei und ohne komplexes Dekodieren übertragen zu können, ist es vorteilhaft, sicherzustellen, dass zu jedem Zeitpunkt nur jeweils einer der Busteilnehmer auf den Bus zugreift, d. h. den Spannungspegel der signalführenden Drahtleitung(en) verändert.
BACnet MS/TP verwendet zur Vermeidung paralleler Zugriffe auf den Bus ein sogenanntes Token, d. h. eine elektronisch über den Bus übermittelte Nachricht, die von „Master”-Busteilnehmer (Master) zu Master weitergereicht (weitergesendet) wird, wobei jeder Busteilnehmer nur dann von sich aus auf den Bus zugreifen darf, wenn er in Besitz des Tokens ist, d. h., das Token empfangen hat ohne es seinerseits weitergereicht zu haben, oder auf eine Nachricht des Tokenbesitzers antwortet. Das Weiterreichen des Tokens erfolgt Adressen-basiert (MAC-Adresse), wobei der Master, der in Besitz des Tokens ist, dieses typischerweise an den Master mit der nächsthöheren ihm als vergeben bekannten Master-Adresse (Adresse in einem für Master reservierten Adressbereich) weiterreicht, wobei nicht vergebene Adressen übersprungen werden.
Sobald ein Master alle zur Übertragung anstehenden Nachrichten versendet hat, reicht er das Token weiter. Um zu verhindern, dass ein Master das Bussystem dauerhaft blockiert, wird jeder Master bei Inbetriebnahme mit einem Parameter („MAX_INFO_FRAMES”) konfiguriert, der festlegt, wie lange der Master das Token maximal halten darf (im Folgenden als maximale Token-Haltezeit bezeichnet), bevor er es weiterreichen muss. Das geschickte Wählen der maximalen Token-Haltezeit stellt für den Inbetriebnehmer jedoch oftmals eine Herausforderung dar, als es detailliertes Wissen über den in dem Bussystem zu erwartenden (Nutz-)Datenverkehr erfordert.
In diesem Zusammenhang lehrt die Druckschrift US 4,667,322 A , dass Busteilnehmer eines lokalen Busses bei Besitz des Tokens typischerweise ihren Sendepuffer vollständig leeren, aber von diesem Prozedere abweichen, wenn dies länger als eine maximale Zeitspanne in Anspruch nehmen würde. Aus der Druckschrift US 6,678,271 B1 ist zudem ein Verfahren bekannt, bei dem die Token-Haltezeit eines Senders vergrößert wird, wenn der Sendepuffer des Senders überläuft. Ferner lehrt die Druckschrift US 5,381,413 A eine Drossel in einem „token bus”, die das Übertragen von Datenpaketen verzögert. Des Weiteren lehrt die Druckschrift US 4,930,121 A , dass in einem „token bus” Daten unterschiedlicher Priorität in unterschiedlichen Sendeschlangen vorgehalten werden, welche gemäß ihrer Priorität geleert werden. Zudem lehrt die Druckschrift US 2009/0 287 736 A1 das Weiterreichen eines Tokens in einem BACnet MS/TP Netzwerk zu überwachen, um daraus den Kommunikationszustand der anderen Busteilnehmer abzuleiten. Aus der Druckschrift US 2015/0 039 752 A1 ist außerdem ein Datenverkehrsüberwachungsgerät in einem BACnet MS/TP Netzwerk bekannt, welches es erlaubt, zeitliche Aspekte der Datenübertragung zu überwachen.
ZUSAMMENFASSUNG
Die vorliegende Erfindung schlägt ein Verfahren zum automatischen Anpassen einer maximalen Token-Haltezeit eines Busteilnehmers in einem BACnet-MS/TP-Bussystem und eine oder mehrere zur Durchführung des Verfahrens eingerichtete Vorrichtungen, d. h. einen oder mehrere zur Durchführung des Verfahrens eingerichtete Busteilnehmer vor.
Das erfindungsgemäße Verfahren zum automatischen Anpassen der maximalen Token-Haltezeit eines ersten Busteilnehmers in dem BACnet-MS/TP-Bussystem umfasst ein Analysieren, durch den ersten Busteilnehmer, eines Datenverkehrs in dem Bussystem während einer ersten Zeitspanne und ein Anpassen, durch den ersten Busteilnehmer, der maximalen Token-Haltezeit des ersten Busteilnehmers basierend auf dem Analysieren des Datenverkehrs während der ersten Zeitspanne, wobei das Analysieren des Datenverkehrs während der ersten Zeitspanne ein Bestimmen eines Daten-Sende-Musters eines zweiten Busteilnehmers umfasst, wobei das Daten-Sende-Muster des zweiten Busteilnehmers definiert ist durch ein gemessenes Daten-Sende-Volumen des zweiten Busteilnehmers und dessen zeitlicher Verteilung.
Das Analysieren des Datenverkehrs in dem Bussystem während einer ersten Zeitspanne umfasst dabei insbesondere das Bestimmen einer Senderadresse für über den Bus gesendete Nachrichten, einen oder mehrere Sendezeitpunkte und eine jeweilige Nachrichtenlänge. Ferner kann die erste Zeitspanne insbesondere einen oder mehrere Token-Umläufe oder einen Teil eines Token-Umlaufs umfassen, bspw. indem die erste Zeitspanne mit der Weitergabe des Tokens durch den ersten Busteilnehmer beginnt und endet, wenn der erste Busteilnehmer das Token wieder empfängt. Ferner kann der zweite Busteilnehmer insbesondere ein anderer Busteilnehmer sein, als der erste Busteilnehmer. Das Analysieren des Datenverkehrs in dem Bussystem zur Laufzeit ermöglicht es, ein Daten-Sende-Muster des zweiten Busteilnehmers und optional weiterer zweiter (und somit insgesamt mehrerer zweiter) Busteilnehmer zu bestimmen, bspw. durch Bestimmen einer Busteilnehmer-Funktionalität, welche ein spezifisches Daten-Sende-Muster erwarten lässt. Bspw. kann durch Analysieren des Datenverkehrs bestimmt werden, dass der zweite Busteilnehmer eine Überwachungseinheit ist, die auf Grund ihrer Funktionalität innerhalb festgelegter Intervalle Statusnachrichten versendet. Des Weiteren kann ein Daten-Sende-Musters des zweiten Busteilnehmers durch Filtern des Datenverkehrs während der ersten Zeitspanne nach Daten, die von dem zweiten Busteilnehmer gesendet wurden und Bestimmen eines zyklischen Verhaltens des zweiten Busteilnehmers, bestimmt werden. So kann bspw. für ein Steuergerät, das zyklisch Sensordaten von einem Sensor abfragt und zyklisch Steuerdaten an einen Aktuator sendet, ein Daten-Sende-Muster bestimmt werden, das die Zykluszeit des Abfragens der Sensordaten und die Zykluszeit des Sendens der Steuerdaten umfasst. Ebenso kann bestimmt werden, dass das Daten-Sende-Muster des zweiten Busteilnehmers von langen Phasen geringer oder keiner (Nutz-)Daten-Sendeaktivität geprägt ist, die durch kurze Phasen hoher Daten-Sendeaktivität unterbrochen werden, wie bspw. ein Router, der einen Konfigurations- oder Aktualisierungszugriff auf die Busteilnehmer ermöglicht.
Vorzugsweise umfasst das Analysieren des Datenverkehrs während der ersten Zeitspanne des Weiteren ein Bestimmen einer maximalen Sende-Puffer-Auslastung des ersten Busteilnehmers während der ersten Zeitspanne, ein Bestimmen, ob die bestimmte maximale Sende-Puffer-Auslastung des ersten Busteilnehmers während der ersten Zeitspanne einen vorbestimmten Schwellenwert übersteigt, und, wenn die bestimmte maximale Sende-Puffer-Auslastung des ersten Busteilnehmers einen vorbestimmten Schwellenwert übersteigt, ein Erhöhen der maximalen Token-Haltezeit des ersten Busteilnehmers, wobei der Grad des Erhöhens in Abhängigkeit vom Daten-Sende-Muster des zweiten Busteilnehmers bestimmt wird.
Wenn die maximale Sende-Puffer-Auslastung des ersten Busteilnehmers während der ersten Zeitspanne einen vorbestimmten Schwellenwert übersteigt, bspw. wenn während der ersten Zeitspanne eine Sende-Puffer-Auslastung eines Kommunikationsmoduls des ersten Busteilnehmers von mehr als 80% oder mehr als 90% auftritt, kann es wünschenswert sein, die maximale Token-Haltezeit zu erhöhen, um es dem ersten Busteilnehmer zu ermöglichen, mehr Daten über den Bus zu senden und dadurch die Menge der in dem Sende-Puffer vorhandenen Daten zu verkleinern. Um zu verhindern, dass ein Vergrößern der maximalen Token-Haltezeit des ersten Busteilnehmers die Datenübertragungsrate des zweiten Busteilnehmers unerwünscht stark reduziert, kann dazu das Daten-Sende-Muster des zweiten Busteilnehmers analysiert werden, um abzuschätzen, wie stark die Datenübertragungsrate des zweiten Busteilnehmers durch ein Vergrößern der maximalen Token-Haltezeit des ersten Busteilnehmers reduziert wird und der Grad des Vergrößerns der maximalen Token-Haltezeit des ersten Busteilnehmers basierend darauf gewählt bzw. dementsprechend angepasst werden.
Sendet der zweite Busteilnehmer bspw. nur in jedem zweiten, dritten, vierten, fünften oder n-ten (mit n größer 5) Token-Umlauf, kann davon ausgegangen werden, dass eine Verlängerung der Token-Umläufe und damit eine Verringerung der Anzahl Token-Umläufe pro Zeit die Datenübertragungsrate des zweiten Busteilnehmers ungleich weniger beeinflusst, als wenn dieser in jedem Token-Umlauf senden würde. Zudem versteht es sich, dass, auch wenn im vorhergehenden Bezug auf einen zweiten Busteilnehmer genommen wurde, das Erhöhen der maximalen Token-Haltezeit des ersten Busteilnehmers in Abhängigkeit von Daten-Sende-Mustern einer Vielzahl zweiter Busteilnehmer vorgenommen werden kann. Alternativ kann der zweite Busteilnehmer aus der Vielzahl zweiter Busteilnehmer ausgewählt werden, wobei der ausgewählte zweite Busteilnehmer der zweite Busteilnehmer der Vielzahl zweiter Busteilnehmer sein kann, der die größte Datenrate aufweist.
Vorzugsweise umfasst das Verfahren ferner zusätzlich zu dem Analysieren des Datenverkehrs während der ersten Zeitspanne und dem darauf basierenden Anpassen der maximalen Token-Haltezeit ein Bestimmen, ob ein dritter Busteilnehmer dem Bussystem hinzugefügt wurde und, wenn ein dritter Busteilnehmer dem Bussystem hinzugefügt wurde, ein Reduzieren der maximalen Token-Haltezeit des ersten Busteilnehmers, wobei der Grad des Reduzierens der maximalen Token-Haltezeit auf einem Analysieren des Datenverkehrs während einer zweiten Zeitspanne basiert, wobei das Analysieren des Datenverkehrs während der zweiten Zeitspanne ein Bestimmen eines Daten-Sende-Musters des dritten Busteilnehmers umfasst und das Daten-Sende-Muster des dritten Busteilnehmers definiert ist durch ein gemessenes Daten-Sende-Volumen des dritten Busteilnehmers und dessen zeitlicher Verteilung.
Durch das Reduzieren der maximalen Token-Haltezeit des ersten Busteilnehmers kann erreicht werden, dass die mittlere und/oder maximale Token-Umlaufzeit durch das Hinzufügen des dritten Busteilnehmers nicht übermäßig vergrößert wird. Analog dazu kann beim Ausscheiden des dritten Busteilnehmers aus dem Bussystem die maximale Token-Haltezeit des ersten Busteilnehmers wieder vergrößert werden.
Vorzugsweise umfasst das Analysieren des Datenverkehrs während der zweiten Zeitspanne ein Messen einer Token-Umlaufzeit und ein Bestimmen, ob die gemessene Token-Umlaufzeit einen Schwellenwert übersteigt, wobei der Grad des Reduzierens ferner darauf basiert, ob die gemessene Token-Umlaufzeit den Schwellenwert übersteigt.
Durch das Reduzieren der maximalen Token-Haltezeit des ersten Busteilnehmers kann dabei erreicht werden, dass die Token-Umlaufzeit den Schwellwert nicht mehr überschreitet. Dies kann insbesondere dann vorteilhaft sein, wenn Busteilnehmer regelmäßig Status- oder Steuer-Nachrichten versenden/empfangen und bei nicht rechtzeitigem Eintreffen der Status- oder Steuer-Nachrichten eine gewünschte, von einem Busteilnehmer implementierte Funktionalität nicht mehr zur Verfügung steht, bspw. wenn das nicht rechtzeitige Eintreffen der Status- oder Steuer-Nachrichten eines Busteilnehmers einen Timeout verursacht.
Vorzugsweise umfasst das Analysieren des Datenverkehrs während der zweiten Zeitspanne ein Bestimmen eines Sendeanteils des ersten Busteilnehmers an der gemessenen Token-Umlaufzeit und ein Bestimmen, ob der Sendeanteil des ersten Busteilnehmers einen vorbestimmten Schwellenwert überstiegen hat, wobei der Grad des Reduzierens ferner darauf basiert, ob der Sendeanteil des ersten Busteilnehmers den vorbestimmten Schwellenwert überstiegen hat.
Durch das Einbeziehen der Sendeanteile kann insbesondere erreicht werden, dass insbesondere Busteilnehmer mit überproportional hohen Sendeanteilen ihre Token-Haltezeit reduzieren, während Busteilnehmer mit angemessenen Sendeanteilen ihre Token-Haltezeit beibehalten können. Beispielsweise kann vorgesehen sein, dass nur der Busteilnehmer mit dem höchsten Sendeanteil seine Token-Haltezeit reduziert. Dies kann insbesondere dann sinnvoll sein, wenn der Busteilnehmer mit dem höchsten Sendeanteil unter anderem Datenpakete geringer Priorität versendet, die verzögert gesendet werden können ohne die Funktionalität der Busteilnehmer zu beeinträchtigen.
Eine erfindungsgemäße Vorrichtung, bspw. der erste Busteilnehmer, umfasst eine BACnet-MS/TP-kompatible Schnittstelle und ein Kommunikationsmodul zum Senden und Empfangen von Daten über die BACnet-MS/TP-kompatible Schnittstelle. Das Kommunikationsmodul ist zum Empfangen und Weiterreichen eines Tokens eingerichtet und ist ferner dazu eingerichtet, nur dann unaufgefordert Daten über die BACnet-MS/TP-kompatible Schnittstelle zu senden, wenn die Vorrichtung in Besitz des Tokens ist. Das Kommunikationsmodul ist des Weiteren dazu eingerichtet, das Token spätestens nach einer maximalen Haltezeit weiterzureichen; einen an der BACnet-MS/TP-kompatiblen Schnittstelle abhörbaren Datenverkehr während einer ersten Zeitspanne zu analysieren; und die maximale Token-Haltezeit basierend auf dem Analysieren des Datenverkehrs während der ersten Zeitspanne anzupassen. Das Kommunikationsmodul ist ferner dazu eingerichtet, beim Analysieren des Datenverkehrs während der ersten Zeitspanne ein Daten-Sende-Muster eines im Betrieb über die BACnet-MS/TP-kompatible Schnittstelle erreichbaren Geräts (bspw. des zweiten Busteilnehmers) zu bestimmen, wobei das Daten-Sende-Muster des über die BACnet-MS/TP-kompatible Schnittstelle erreichbaren Geräts definiert ist durch ein Volumen gesendeter Daten und dessen zeitlicher Verteilung.
Wie oben ausgeführt, ermöglicht das Analysieren des Datenverkehrs zur Laufzeit ein Daten-Sende-Muster eines oder mehrerer Geräte, die im Betrieb auf den Bus zugreifen zu bestimmen; bspw. durch Bestimmen einer Funktionalität eines Geräts, die ein spezifisches Daten-Sende-Muster erwarten lässt. Des Weiteren kann wie oben ausgeführt ein Daten-Sende-Musters des Geräts durch Filtern des Datenverkehrs während der ersten Zeitspanne nach Daten, die von dem Gerät gesendet wurden und Bestimmen eines zyklischen Verhaltens des Geräts anhand der gefilterten Daten, bestimmt werden.
Vorzugsweise ist das Kommunikationsmodul ferner dazu eingerichtet eine maximalen Sende-Puffer-Auslastung des Kommunikationsmoduls während der ersten Zeitspanne zu bestimmen und ferner zu bestimmen, ob die maximale Sende-Puffer-Auslastung des Kommunikationsmoduls einen vorbestimmten Schwellenwert übersteigt und, wenn die bestimmte maximale Sende-Puffer-Auslastung des Kommunikationsmoduls einen vorbestimmten Schwellenwert übersteigt, die maximale Token-Haltezeit des Kommunikationsmoduls zu erhöhen, wobei der Grad der Erhöhung vom Daten-Sende-Muster des im Betrieb über die BACnet-MS/TP-kompatible Schnittstelle erreichbaren Geräts abhängig ist.
Wenn die maximale Sende-Puffer-Auslastung der Vorrichtung während der ersten Zeitspanne einen vorbestimmten Schwellenwert übersteigt, bspw. wenn während der ersten Zeitspanne eine Sende-Puffer-Auslastung des Kommunikationsmoduls von mehr als 80% oder mehr als 90% auftritt, kann es wünschenswert sein, die maximale Token-Haltezeit zu erhöhen, um es der Vorrichtung zu ermöglichen mehr Daten über den Bus zu senden und dadurch die Menge der in dem Sende-Puffer des Kommunikationsmoduls vorhandenen Daten zu verkleinern. Um zu verhindern, dass ein Vergrößern der maximalen Token-Haltezeit der Vorrichtung die Datenübertragungsrate des Geräts, das im Betrieb ebenfalls auf den Bus zugreift, unerwünscht stark reduziert, kann dazu das Daten-Sende-Muster des Geräts analysiert werden, um abzuschätzen, wie stark die Datenübertragungsrate des Geräts durch ein Vergrößern der maximalen Token-Haltezeit der Vorrichtung reduziert wird.
Vorzugsweise ist das Kommunikationsmodul ferner dazu eingerichtet zusätzlich zu dem Analysieren des Datenverkehrs während der ersten Zeitspanne und dem darauf basierenden Anpassen der maximalen Token-Haltezeit durch Abhören eines an der BACnet-MS/TP-kompatiblen Schnittstelle abhörbaren Datenverkehrs im Betrieb zu bestimmen, ob über die BACnet-MS/TP-kompatible Schnittstelle ein weiteres Gerät erreichbar ist, das vormals nicht erreichbar war, und, wenn das weitere Gerät erreichbar ist, die maximale Token-Haltezeit des Kommunikationsmoduls zu reduzieren, wobei der Grad der Reduktion der maximalen Token-Haltezeit auf einer Analyse des Datenverkehrs während einer zweiten Zeitspanne basiert, wobei die Analyse des Datenverkehrs während der zweiten Zeitspanne die Bestimmung eines Daten-Sende-Musters des weiteren Geräts umfasst, wobei das Daten-Sende-Muster des weiteren Geräts definiert ist durch ein gemessenes Daten-Sende-Volumen des weiteren Geräts und dessen zeitlicher Verteilung.
Durch das Erkennen neu hinzugefügter Busteilnehmer wird somit ein Prozess eingeleitet, dessen Ziel es ist, die sich aus dem Hinzufügen neuer Busteilnehmer ergebende Verlängerung der maximalen Token-Umlaufzeit zu begrenzen, indem überprüft wird, welche Bus-Ressourcen der neue Busteilnehmer für sich beansprucht und inwiefern die Vorrichtung zumindest einen Teil dieser beanspruchten Ressourcen zur Verfügung stellen kann. Erreicht bspw. die Vorrichtung nur selten eine hohe Sendepuffer-Auslastung, kann es möglich sein, die maximale Token-Haltezeit zu verringern, ohne den Sendepuffer zum Überlauf zu bringen. Ferner kann ein Analysieren des Datenverkehrs ergeben, dass die Vorrichtung und das weitere Gerät in unterschiedlichen Token-Umläufen senden, so dass ein Reduzieren der maximalen Token-Haltezeit des Kommunikationsmoduls nur in geringem Umfang nötig ist.
Vorzugsweise ist das Kommunikationsmodul ferner dazu eingerichtet im Rahmen der Analyse des Datenverkehrs während der zweiten Zeitspanne das eine Token-Umlaufzeit zu messen und zu bestimmen, ob die gemessene Token-Umlaufzeit einen Schwellenwert übersteigt, wobei der Grad der Reduktion der maximalen Token-Haltezeit ferner darauf basiert, ob die gemessene Token-Umlaufzeit den Schwellenwert übersteigt.
In diesem Fall kann vorgesehen sein, die maximale Token-Haltezeit des Kommunikationsmoduls insbesondere dann zu reduzieren, wenn die gemessene Token-Umlaufzeit einen Schwellenwert überschreitet. Dies kann beispielsweise dann sinnvoll sein, wenn es sich bei dem Datenverkehr über den Bus um eine nicht-zeitkritische Kommunikation zwischen Bus Teilnehmern handelt, bei der eine Verlängerung der Token-Umlaufzeit eine graduelle Verschlechterung der durch die Busteilnehmer bereitgestellten Dienste bewirkt, die erst oder insbesondere dann als störend wahrgenommen wird, wenn die Token-Umlaufzeit den Schwellenwert überschreitet.
Vorzugsweise ist das Kommunikationsmodul ferner dazu eingerichtet im Rahmen der Analyse des Datenverkehrs während der zweiten Zeitspanne Sendeanteile des Kommunikationsmoduls der gemessenen Token-Umlaufzeit zu bestimmen und zu bestimmen, ob der Sendeanteil des Kommunikationsmoduls einen vorbestimmten Schwellenwert überstiegen hat, wobei der Grad der Reduktion der maximalen Token-Haltezeit ferner darauf basiert, ob der Sendeanteil des Kommunikationsmoduls den vorbestimmten Schwellenwert überstiegen hat.
Beispielsweise kann festgelegt sein, dass die Vorrichtung nicht mehr als das Zweifache der Token-Umlaufzeit geteilt durch die Zahl der Busteilnehmer für sich beanspruchen darf. Dadurch kann vermieden werden, dass die Sendeanteile zu ungleichmäßig verteilt werden.
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 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 der 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 Gebaudeautomatisierungsanwendung(en) abgeschätzt werden. Bspw. kann 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-Busteilnehmer 16, 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 seine 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 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

Verfahren (60) zum automatischen Anpassen einer maximalen Token-Haltezeit eines ersten Busteilnehmers (24) in einem BACnet-MS/TP-Bussystem (12), umfassend: Analysieren (62), durch den ersten Busteilnehmer (24), eines Datenverkehrs in dem Bussystem (12) während einer ersten Zeitspanne; Anpassen (66), durch den ersten Busteilnehmer (24), der maximalen Token-Haltezeit des ersten Busteilnehmers (24) basierend auf dem Analysieren des Datenverkehrs während der ersten Zeitspanne, wobei das Analysieren (62) des Datenverkehrs während der ersten Zeitspanne das Bestimmen (64) eines Daten-Sende-Musters eines zweiten Busteilnehmers (16, 22, 28) umfasst, wobei das Daten-Sende-Muster des zweiten Busteilnehmers (16, 22, 28) definiert ist durch ein gemessenes Daten-Sende-Volumen des zweiten Busteilnehmers (16, 22, 28) und dessen zeitliche Verteilung.
Verfahren (60) nach Anspruch 1, wobei das Analysieren (62) des Datenverkehrs während der ersten Zeitspanne des Weiteren umfasst: Bestimmen einer maximalen Sende-Puffer-Auslastung des ersten Busteilnehmers (24) während der ersten Zeitspanne; Bestimmen, ob die bestimmte maximale Sende-Puffer-Auslastung des ersten Busteilnehmers (24) einen vorbestimmten Schwellenwert übersteigt; und wenn die bestimmte maximale Sende-Puffer-Auslastung des ersten Busteilnehmers (24) den vorbestimmten Schwellenwert übersteigt, Erhöhen der maximalen Token-Haltezeit des ersten Busteilnehmers (24), wobei der Grad des Erhöhens in Abhängigkeit vom Daten-Sende-Muster des zweiten Busteilnehmers (16, 22, 28) bestimmt wird.
Verfahren (60) nach Anspruch 1 oder 2, ferner umfassend zusätzlich zu dem Analysieren (62) des Datenverkehrs während der ersten Zeitspanne und dem darauf basierenden Anpassen (66) der maximalen Token-Haltezeit: Bestimmen, ob ein dritter Busteilnehmer (16, 22, 28) dem Bussystem (12) hinzugefügt wurde; und wenn ein dritter Busteilnehmer (16, 22, 28) dem Bussystem (12) hinzugefügt wurde, Reduzieren der maximalen Token-Haltezeit des ersten Busteilnehmers (24), wobei der Grad des Reduzierens der maximalen Token-Haltezeit auf einem Analysieren des Datenverkehrs während einer zweiten Zeitspanne basiert; wobei das Analysieren des Datenverkehrs während der zweiten Zeitspanne das Bestimmen eines Daten-Sende-Musters des dritten Busteilnehmers (16, 22, 28) umfasst und das Daten-Sende-Muster des dritten Busteilnehmers (16, 22, 28) definiert ist durch ein gemessenes Daten-Sende-Volumen des dritten Busteilnehmers (16, 22, 28) und dessen zeitliche Verteilung.
Verfahren (60) nach Anspruch 3, wobei das Analysieren des Datenverkehrs während der zweiten Zeitspanne umfasst: Messen einer Token-Umlaufzeit; und Bestimmen, ob die gemessene Token-Umlaufzeit einen zweiten Schwellenwert übersteigt; wobei der Grad des Reduzierens der maximalen Token-Haltezeit ferner darauf basiert, ob die gemessene Token-Umlaufzeit den zweiten Schwellenwert übersteigt.
Verfahren (60) nach Anspruch 3 oder 4, wobei das Analysieren des Datenverkehrs während der zweiten Zeitspanne umfasst: Bestimmen eines Sendeanteils des ersten Busteilnehmers (24) an der gemessenen Token-Umlaufzeit; und Bestimmen, ob der Sendeanteil des ersten Busteilnehmers (24) einen vorbestimmten dritten Schwellenwert überstiegen hat; wobei der Grad des Reduzierens der maximalen Token-Haltezeit ferner darauf basiert, ob der Sendeanteil des ersten Busteilnehmers (24) den vorbestimmten dritten Schwellenwert überstiegen hat.
Vorrichtung (24), umfassend: eine BACnet-MS/TP-kompatible Schnittstelle (46); und ein Kommunikationsmodul (44) zum Senden und Empfangen von Daten über die BACnet-MS/TP-kompatible Schnittstelle (46); wobei das Kommunikationsmodul (44) zum Empfangen und Weiterreichen eines Tokens eingerichtet ist und ferner dazu eingerichtet ist: nur dann unaufgefordert Daten über die BACnet-MS/TP-kompatible Schnittstelle (46) zu senden, wenn die Vorrichtung (24) in Besitz des Tokens ist; das Token spätestens nach einer maximalen Haltezeit weiterzureichen; einen an der BACnet-MS/TP-kompatiblen Schnittstelle (46) abhörbaren Datenverkehr während einer ersten Zeitspanne zu analysieren; und die maximale Token-Haltezeit basierend auf dem Analysieren des Datenverkehrs während der ersten Zeitspanne anzupassen; wobei die Vorrichtung (24) dadurch gekennzeichnet ist, dass das Kommunikationsmodul (44) ferner dazu eingerichtet ist: beim Analysieren des Datenverkehrs während der ersten Zeitspanne ein Daten-Sende-Muster eines im Betrieb über die BACnet-MS/TP-kompatible Schnittstelle (46) erreichbaren Geräts (16, 22, 28) zu bestimmen, wobei das Daten-Sende-Muster des über die BACnet-MS/TP-kompatible Schnittstelle (46) erreichbaren Geräts (16, 22, 28) definiert ist durch ein Volumen gesendeter Daten und durch die zeitliche Verteilung des Volumens der gesendeten Daten.
Vorrichtung (24) nach Anspruch 6, wobei das Kommunikationsmodul (44) ferner dazu eingerichtet ist: eine maximale Sende-Puffer-Auslastung des Kommunikationsmoduls (44) während der ersten Zeitspanne zu bestimmen; zu bestimmen, ob die maximale Sende-Puffer-Auslastung des Kommunikationsmoduls (44) einen vorbestimmten Schwellenwert übersteigt; und wenn die bestimmte maximale Sende-Puffer-Auslastung des Kommunikationsmoduls (44) den vorbestimmten Schwellenwert übersteigt, die maximale Token-Haltezeit des Kommunikationsmoduls (44) zu erhöhen, wobei der Grad der Erhöhung vom Daten-Sende-Muster des im Betrieb über die BACnet-MS/TP-kompatible Schnittstelle (46) erreichbaren Geräts (16, 22, 28) abhängig ist.
Vorrichtung (24) nach Anspruch 6 oder 7, wobei das Kommunikationsmodul (46) ferner dazu eingerichtet ist, zusätzlich zu dem Analysieren des Datenverkehrs während der ersten Zeitspanne und dem darauf basierenden Anpassen der maximalen Token-Haltezeit: durch Abhören eines an der BACnet-MS/TP-kompatiblen Schnittstelle (46) abhörbaren Datenverkehrs im Betrieb zu bestimmen, ob über die BACnet-MS/TP-kompatible Schnittstelle (46) ein weiteres Gerät (16, 22, 28) erreichbar ist, das vormals nicht erreichbar war; und wenn das weitere Gerät (16, 22, 28) erreichbar ist, die maximale Token-Haltezeit des Kommunikationsmoduls (44) zu reduzieren, wobei der Grad der Reduktion der maximalen Token-Haltezeit auf einer Analyse des Datenverkehrs während einer zweiten Zeitspanne basiert, wobei die Analyse des Datenverkehrs während der zweiten Zeitspanne die Bestimmung eines Daten-Sende-Musters des weiteren Geräts (16, 22, 28) umfasst, wobei das Daten-Sende-Muster des weiteren Geräts (16, 22, 28) definiert ist durch ein gemessenes Daten-Sende-Volumen des weiteren Geräts (16, 22, 28) und dessen zeitliche Verteilung.
Vorrichtung (24) nach Anspruch 8, wobei das Kommunikationsmodul (44) ferner dazu eingerichtet ist, im Rahmen der Analyse des Datenverkehrs während der zweiten Zeitspanne: eine Token-Umlaufzeit zu messen; und zu bestimmen, ob die gemessene Token-Umlaufzeit einen zweiten Schwellenwert übersteigt, wobei der Grad der Reduktion der maximalen Token-Haltezeit ferner darauf basiert, ob die gemessene Token-Umlaufzeit den zweiten Schwellenwert übersteigt.
Vorrichtung (24) nach Anspruch 8 oder 9, wobei das Kommunikationsmodul (44) ferner dazu eingerichtet ist, im Rahmen der Analyse des Datenverkehrs während der zweiten Zeitspanne: einen Sendeanteil des Kommunikationsmoduls (44) an der gemessenen Token-Umlaufzeit zu bestimmen; und zu bestimmen, ob der Sendeanteil des Kommunikationsmoduls (44) einen vorbestimmten dritten Schwellenwert überstiegen hat; wobei der Grad der Reduktion der maximalen Token-Haltezeit darauf basiert, ob der Sendeanteil des Kommunikationsmoduls (44) den vorbestimmten dritten Schwellenwert überstiegen hat.