DE102016004127B3

DE102016004127B3 - Automatische Begrenzung des Datenverkehrs in, einen Router umfassenden BACNET-MS/TP-Bussystemen zur Laufzeit

Info

Publication number: DE102016004127B3
Application number: DE102016004127.7A
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

Abstract

Bereitgestellt wird ein Verfahren Verfahren zum automatischen Anpassen eines Datenverkehrs in einem, einen Router umfassenden BACnet-MS/TP-Bussystem. Das Verfahren umfasst ein Bestimmen, ob eine Auslastung eines Sendepuffers eines ersten Busteilnehmers des BACnet-MS/TP-Bussystems, welcher den Router implementiert, einen vorbestimmten Schwellenwert überschreitet, und wenn die Auslastung des Sendepuffers des ersten Busteilnehmers einen vorbestimmten Schwellenwert überschreitet, ein Senden mindestens einer Nachricht an mindestens einen zweiten Busteilnehmer des BACnet-MS/TP-Bussystems, wobei die mindestens eine Nachricht eine Aufforderung enthält, die Menge der in dem BACnet-MS/TP-Bussystem gesendeten Daten zu verringern und der mindestens eine zweite Busteilnehmer in Reaktion auf die Aufforderung die Menge der von ihm in dem BACnet-MS/TP-Bussystem gesendeten Daten verringert.

Description

GEBIET
Die vorliegende Erfindung betrifft das Gebiet der Bussysteme. Insbesondere betrifft die vorliegende Erfindung das Gebiet des automatischen Anpassens des Datenverkehrs in, einen Router umfassenden 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 (im Folgenden als maximale Token-Haltezeit bezeichnet) darf, bevor er es weiterreichen muss. Das geschickte Wählen der maximalen Token-Haltezeit stellt für den Inbetriebnehmer jedoch oftmals eine Herausforderung dar, wenn die über den Bus übertragene (Nutz-)Datenmenge während der Laufzeit großen Schwankungen unterworfen ist.
Router in einem BACnet Bussystem sind aus dem Stad der Technik bekannt. So lehrt die Druckschrift US 2015/0 106 447 A1 einen BACnet Router in einem BACnet MS/TP Netzwerk. Ferner lehrt die Druckschrift AT 500 351 A1 ein Netzwerk mit einem Router zwischen LonTalk und BACnet. Zudem sind aus dem Stand der Technik Systeme mit einem gemeinsam genutzten Übertragungsmedium bekannt, in denen einem Übertragungsstau entgegengewirkt wird. So lehrt die Druckschrift US 5,381,413 A eine Drossel in einem „token bus”, die das Übertragen von Datenpaketen verzögert. Ferner lehrt die Druckschrift US 4,667,322 A , dass Busteilnehmer eines lokalen Busses bei Besitz des Tokens typischerweise ihren Sendepuffer vollständig lehren, aber von diesem Prozedere abweichen, wenn dies länger als eine maximale Zeitspanne in Anspruch nehmen würde. 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 2003/0 156 542 A1 , dass ein Sender in einem Netzwerk bei Volllaufen seines Sendepuffers einen Sender, der den Netzwerkstau verursacht, diesbezüglich informiert.
ZUSAMMENFASSUNG
Die vorliegende Erfindung schlägt ein Verfahren zum automatischen Anpassen eines Datenverkehrs in einem, einen Router umfassenden BACnet-MS/TP-Bussystem, einen zur Durchführung des Verfahrens eingerichteten Router, sowie ein zur Durchführung des Verfahrens eingerichtetes BACnet-MS/TP-Bussystem vor.
Das erfindungsgemäße Verfahren zum automatischen Anpassen des Datenverkehrs in einem, einen Router umfassenden BACnet-MS/TP-Bussystem, umfasst ein Bestimmen, ob eine Auslastung eines Sendepuffers eines ersten Busteilnehmers des BACnet-MS/TP-Bussystems, welcher den Router implementiert, einen vorbestimmten Schwellenwert überschreitet und, wenn die Auslastung des Sendepuffers des ersten Busteilnehmers einen vorbestimmten Schwellenwert überschreitet, ein Senden mindestens einer Nachricht an mindestens einen zweiten Busteilnehmer des BACnet-MS/TP-Bussystems, wobei die mindestens eine Nachricht eine Aufforderung enthält, die Menge der in dem BACnet-MS/TP-Bussystem gesendeten Daten zu verringern und der mindestens eine zweite Busteilnehmer in Reaktion auf die Aufforderung die Menge der von ihm in dem BACnet-MS/TP-Bussystem gesendeten Daten verringert.
Der Erfindung liegt dabei die Erkenntnis zu Grunde, dass ein Router in einem BACnet-MS/TP-Bussystem oftmals eine Verbindung zu Netzwerken herstellt, die einen höhere Bandbreite aufweisen als das BACnet-MS/TP-Bussystem. Als Router wird in diesem Zusammenhang dabei insbesondere eine solche Vorrichtung angesehen, die mindestens zwei separate (physikalische bzw. elektrische) Schnittstellen (Anschlüsse für Drahtleitungen oder Funkantennen) umfasst und dazu eingerichtet ist, die an einer der Schnittstellen empfangenen Daten an einer anderen der Schnittstellen auszugeben, wodurch ein Datenweitertransport von einem Netzwerk, das mit der einen der Schnittstellen verbunden ist (bspw. dem BACnet-MS/TP-Bussystem), in ein anderes Netzwerk, das mit der anderen der Schnittstellen verbunden ist, ermöglicht wird. Ist ferner eine (weitere) automatische Erhöhung der Baudrate, die dem erfindungsgemäßen Verfahren vorangehen kann, in dem BACnet-MS/TP-Bussystem nicht (mehr) möglich, so kann es vorkommen, dass der Router mehr Daten empfängt, als er auf Grund der beschränkten Bandbreite tatsächlich über das BACnet-MS/TP-Bussystem versenden kann, wodurch die Auslastung des Sendepuffers (in BACnet-MS/TP-Bussystem-Richtung) des Routers ansteigt. Ist der am Router ankommende Datenstrom nicht kontinuierlich, sondern handelt es sich vielmehr um eine vorübergehende Phase hohen Datenaufkommens, kann der Router einem Überlaufen seines Sendepuffers und damit einem Verlust von Daten dadurch entgegenwirken, dass er den oder die zweiten Busteilnehmer dazu veranlasst (vorübergehend) ihre Busnutzung einzuschränken, so dass zusätzliche Senderessourcen für den Router zur Verfügung stehen. Um den Router davon zu entlasten, entscheiden zu müssen, welcher Busteilnehmer seine Busnutzung (ohne Einbußen hinsichtlich einer Funktionalität der durch den Busteilnehmer implementierten Gebäudeautomatisierungssteuerung) einschränken kann, kann diese Entscheidung, in Reaktion auf eine Aufforderung des Routers hin, lokal von jedem Busteilnehmer getroffen werden.
Vorzugsweise unterteilt der mindestens eine zweite Busteilnehmer in Reaktion auf die Aufforderung von ihm zu sendende Daten hinsichtlich ihrer Priorität verzögert oder setzt den Versand von Daten geringerer Priorität aus.
Dadurch, dass der Versand von Daten geringerer Priorität verzögert oder ausgesetzt wird, können kurzfristig zusätzliche Senderessourcen für den Router bereitgestellt werden, ohne die Funktionalität der durch den mindestens einen zweiten Busteilnehmer implementierten Gebäudeautomatisierungssteuerung (langfristig) zu behindern. Wenn die Auslastung des Sendepuffers des Routers den oder einen weiteren vorbestimmten Schwellenwert unterschreitet, kann der Router eine weitere Nachricht an den mindestens einen zweiten Busteilnehmer senden, wobei die weitere Nachricht die Aufforderung, die Menge der über das BACnet-MS/TP-Bussystem gesendeten (Nutz-)Daten zu verringern, widerruft. In Reaktion auf die weitere Nachricht kann der mindestens eine zweite Teilnehmer des BACnet-MS/TP-Bussystems den Versand der Daten geringerer Priorität nachholen und/oder zum normalen Daten-Sendebetrieb zurückkehren. Alternativ kann die Aufforderung, die Menge der über das BACnet-MS/TP-Bussystem gesendeten (Nutz-)Daten zu verringern eine Zeitdauer vorgeben oder auf Seiten des mindestens einen zweiten Busteilnehmers mit einer Zeitdauer assoziiert sein, nach der der mindestens eine zweite Busteilnehmer den Versand der Daten geringerer Priorität nachholen und/oder zum normalen Daten-Sendebetrieb zurückkehren kann, sofern er keine weitere Aufforderung, die Menge der über das BACnet-MS/TP-Bussystem gesendeten (Nutz-)Daten zu verringern, vor dem Ablauf der Zeitdauer, welche sich an das Empfangen der entsprechende Nachricht anschließen kann, erhält.
Ferner kann vorgesehen sein, dass der mindestens eine zweite Busteilnehmer in Reaktion auf die Aufforderung seine maximale Token-Haltezeit verringert.
Durch das Verringern der maximalen Token-Haltezeit kann bspw. ein kurzfristig auftretender erhöhter Daten-Sendebedarf, welcher bspw. mit der erhöhten Daten-Sendeaktivität des Routers korreliert, auf eine größere Anzahl an Token-Umläufe verteilt werden, um zu verhindern, dass der erhöhte Daten-Sendebedarf des mindestens einen zweiten Busteilnehmers einen Sende-Rückstau verursacht.
Ferner kann vorgesehen sein, dass der mindestens eine zweite Busteilnehmer in Reaktion auf die Aufforderung für eine Zeitdauer das Versenden von Nutzdaten aussetzt.
Durch das Aussetzen des Sendens von Nutzdaten sendet der mindestens eine zweite Busteilnehmer nur noch Daten, die durch das Bussystem-Protokoll vorgegeben sind, wie bspw. Daten, die im Zusammenhang mit dem Weiterreichen des Tokens stehen, aber keine darüber hinausgehenden Daten. Durch das Aussetzen des Sendens von Nutzdaten, an das sich bspw. das Priorisieren von Daten anschließen kann, können kurzfristig zusätzliche Senderessourcen für den Router bereitgestellt werden, insbesondere wenn der mindestens eine zweite Busteilnehmer keine zeitkritischen Nutzdaten zu versenden hat, bzw. keine Nutzdaten, die die Funktionalität der durch den mindestens einen zweiten Busteilnehmer implementierten Gebäudeautomatisierungssteuerung unmittelbar stützen.
Vorzugsweise setzt der mindestens eine zweite Busteilnehmer in Reaktion auf die Aufforderung das Versenden der Nutzdaten aus bis eine Auslastung eines Sendepuffers des mindestens einen zweiten Busteilnehmers einen vorbestimmten Schwellenwert überschreitet.
Dadurch kann vermieden werden, dass Datenverlust auftritt. Übermittelt der mindestens eine zweite Teilnehmer bspw. Zustandsänderungsinformationen und liegen zu diesem Zeitpunkt keine Zustandsänderungen vor oder nur Zustandsänderungen, die einen vorbestimmten Schwellenwert nicht überschreiten, können diese im Sendepuffer des mindestens einen zweiten Teilnehmers zwischengespeichert und zeitverzögert übertragen werden, bevor der Sendepuffer überläuft.
Der erfindungsgemäße Router umfasst eine BACnet-MS/TP-kompatible erste Schnittstelle, eine zweite Schnittstelle, ein erstes Kommunikationsmodul, eingerichtet zum Senden und Empfangen von Daten über die BACnet-MS/TP-kompatible erste Schnittstelle und ein zweites Kommunikationsmodul, eingerichtet zum Senden und Empfangen von Daten über die zweite Schnittstelle. Das erste Kommunikationsmodul ist ferner dazu eingerichtet zu bestimmen, ob eine Auslastung eines Sendepuffers des ersten Kommunikationsmoduls einen vorbestimmten Schwellenwert überschreitet und eine Nachricht an mindestens einen weiteren Busteilnehmer des BACnet-MS/TP-Bussystems in Reaktion auf das Bestimmen, dass die Auslastung des Sendepuffers des ersten Kommunikationsmoduls den vorbestimmten Schwellenwert überschreitet, zu senden, wobei der Router dadurch gekennzeichnet ist, dass die Nachricht eine Aufforderung enthält, die Menge der in dem BACnet-MS/TP-Bussystem gesendeten Daten zu verringern.
Wie oben ausgeführt, kann der Router dadurch einem Überlaufen seines Sendepuffers und damit einem Verlust von Daten entgegenwirken, indem er durch Versenden der Nachricht den mindestens einen zweiten Busteilnehmer dazu veranlasst (vorübergehend) ihre Busnutzung einzuschränken, so dass zusätzliche Senderessourcen für den Router frei werden. Um den Router davon zu entlasten, entscheiden zu müssen, welcher Busteilnehmer seine Busnutzung (ohne Einbußen hinsichtlich einer Funktionalität der durch den Busteilnehmer implementierten Gebäudeautomatisierungssteuerung) einschränken kann, kann diese Entscheidung lokal von jedem zweiten Busteilnehmer getroffen werden, so dass der Router die zweiten Busteilnehmer nur auffordern muss, die Menge der von ihnen über das BACnet-MS/TP-Bussystem gesendeten Daten zu verringern.
Vorzugsweise umfasst ein BACnet-MS/TP-Bussystem den erfindungsgemäßen Router und den mindestens einen zweiten Busteilnehmer, wobei der mindestens eine zweite Busteilnehmer dazu eingerichtet ist, in Reaktion auf die Nachricht von ihm zu sendende Daten hinsichtlich ihrer Priorität zu unterteilen und den Versand von Daten geringerer Priorität zu verzögern oder auszusetzen.
Wie oben ausgeführt, können dadurch kurzfristig zusätzliche Senderessourcen für den Router bereitgestellt werden, ohne die Funktionalität der durch den mindestens einen zweiten Busteilnehmer implementierten Gebäudeautomatisierungssteuerung (langfristig) zu behindern. Wenn die Auslastung des Sendepuffers des Routers den oder einen weiteren vorbestimmten Schwellenwert unterschreitet, kann der Router dazu eingerichtet sein, eine weitere Nachricht an den mindestens einen zweiten Teilnehmer des BACnet-MS/TP-Bussystems zu senden, wobei die weitere Nachricht die Aufforderung, die Menge der über das BACnet-MS/TP-Bussystem gesendeten (Nutz-)Daten zu verringern, widerruft. Der mindestens eine zweite Teilnehmer des BACnet-MS/TP-Bussystems kann ferner dazu eingerichtet sein, in Antwort auf die weitere Nachricht, den Versand der Daten geringerer Priorität nachholen und/oder zum normalen Daten-Sendebetrieb zurückkehren. Alternativ kann die Aufforderung, die Menge der über das BACnet-MS/TP-Bussystem gesendeten (Nutz-)Daten zu verringern eine Zeitdauer vorgeben oder auf Seiten des mindestens einen zweiten Busteilnehmers mit einer Zeitdauer assoziiert sein, wobei der mindestens eine zweite Busteilnehmer dazu eingerichtet ist, nach der Zeitdauer den Versand der Daten geringerer Priorität nachholen und/oder zum normalen Daten-Sendebetrieb zurückzukehren, sofern der mindestens eine zweite Busteilnehmer keine weitere Aufforderung, die Menge der über das BACnet-MS/TP-Bussystem gesendeten (Nutz-)Daten zu verringern, vor dem Ablauf der Zeitdauer, welche sich an das Empfangen der entsprechende Nachricht anschließen kann, erhält.
Vorzugsweise umfasst ein BACnet-MS/TP-Bussystem den erfindungsgemäßen Router und den mindestens einen zweiten Busteilnehmer, wobei der mindestens eine zweite Busteilnehmer dazu eingerichtet ist, seine maximale Token-Haltezeit in Reaktion auf die Nachricht zu verringern.
Wie oben ausgeführt kann durch das Verringern der maximalen Token-Haltezeit ein kurzfristig auftretender erhöhter Daten-Sendebedarf, welcher bspw. mit der erhöhten Daten-Sendeaktivität des Routers korreliert, auf eine größere Anzahl an Token-Umläufe verteilt werden, um zu verhindern, dass der erhöhte Daten-Sendebedarf des mindestens einen zweiten Busteilnehmers einen Sende-Rückstau verursacht.
Vorzugsweise umfasst ein BACnet-MS/TP-Bussystem den erfindungsgemäßen Router und den mindestens einen zweiten Busteilnehmer, wobei der mindestens eine zweite Busteilnehmer dazu eingerichtet ist, in Reaktion auf die Nachricht für eine Zeitdauer das Versenden von Nutzdaten gänzlich auszusetzen.
Wie oben ausgeführt können durch das Aussetzen des Sendens von Nutzdaten, an das sich bspw. das Priorisieren von Daten anschließen kann, kurzfristig zusätzliche Senderessourcen für den Router bereitgestellt werden, insbesondere, wenn der mindestens eine zweite Busteilnehmer keine zeitkritischen Nutzdaten zu versenden hat, bzw. keine Nutzdaten, die die Funktionalität der durch den mindestens einen zweiten Busteilnehmer implementierten Gebäudeautomatisierungssteuerung unmittelbar stützen.
Vorzugsweise ist der mindestens eine zweite Busteilnehmer dazu eingerichtet, in Reaktion auf die Nachricht das Versenden der Nutzdaten auszusetzen bis eine Auslastung eines Sendepuffers des mindestens einen weiteren Busteilnehmers einen vorbestimmten Schwellenwert überschreitet.
Wie oben ausgeführt, kann dadurch vermieden werden, dass der mindestens eine zweite Busteilnehmer einen Datenverlust erleidet.
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 Gebäudeautomatisierungsanwendung(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 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

Verfahren (72) zum automatischen Anpassen eines Datenverkehrs in einem, einen Router umfassenden BACnet-MS/TP-Bussystem (12), umfassend: Bestimmen (74), ob eine Auslastung eines Sendepuffers eines ersten Busteilnehmers (28) des BACnet-MS/TP-Bussystems (12), welcher den Router implementiert, einen vorbestimmten Schwellenwert überschreitet; und wenn die Auslastung des Sendepuffers des ersten Busteilnehmers (28) den vorbestimmten Schwellenwert überschreitet, Senden (76) mindestens einer Nachricht an mindestens einen zweiten Busteilnehmer (16, 22, 24) des BACnet-MS/TP-Bussystems (12); wobei die mindestens eine Nachricht eine Aufforderung enthält, die Menge der in dem BACnet-MS/TP-Bussystem (12) gesendeten Daten zu verringern; und der mindestens eine zweite Busteilnehmer (16, 22, 24) in Reaktion auf die Aufforderung die Menge der von ihm in dem BACnet-MS/TP-Bussystem (12) gesendeten Daten verringert.
Verfahren (72) nach Anspruch 1, wobei der mindestens eine zweite Busteilnehmer (16, 22, 24) in Reaktion auf die Aufforderung von ihm zu sendende Daten priorisiert und den Versand von Daten geringerer Priorität verzögert oder aussetzt.
Verfahren (72) nach Anspruch 1 oder 2, wobei der mindestens eine zweite Busteilnehmer (16, 22, 24) in Reaktion auf die Aufforderung seine maximale Token-Haltezeit verringert.
Verfahren (72) nach einem der Ansprüche 1 bis 3, wobei der mindestens eine zweite Busteilnehmer (16, 22, 24) in Reaktion auf die Aufforderung für eine Zeitdauer das Versenden von Nutzdaten aussetzt.
Verfahren (72) nach Anspruch 4, wobei der mindestens eine zweite Busteilnehmer (18, 22, 24) in Reaktion auf die Aufforderung das Versenden der Nutzdaten aussetzt bis eine Auslastung eines Sendepuffers des mindestens einen zweiten Busteilnehmers (16, 22, 24) einen vorbestimmten weiteren Schwellenwert überschreitet.
Router, umfassend: eine BACnet-MS/TP-kompatible erste Schnittstelle (46); eine zweite Schnittstelle; ein erstes Kommunikationsmodul (44), eingerichtet zum Senden und Empfangen von Daten über die BACnet-MS/TP-kompatible erste Schnittstelle (46); und ein zweites Kommunikationsmodul (68), eingerichtet zum Senden und Empfangen von Daten über die zweite Schnittstelle; wobei das erste Kommunikationsmodul (44) ferner dazu eingerichtet ist: zu bestimmen, ob eine Auslastung eines Sendepuffers des ersten Kommunikationsmoduls (44) einen vorbestimmten Schwellenwert überschreitet; und eine Nachricht an mindestens einen weiteren Busteilnehmer (16, 22, 24) des BACnet-MS/TP-Bussystems (12) in Reaktion auf das Bestimmen, dass die Auslastung des Sendepuffers des ersten Kommunikationsmoduls (44) den vorbestimmten Schwellenwert überschreitet, zu senden; wobei die Nachricht eine Aufforderung enthält, die Menge der in dem BACnet-MS/TP-Bussystem (12) gesendeten Daten zu verringern.
BACnet-MS/TP-Bussystem (12), umfassend: den Router nach Anspruch 6; und mindestens einen zweiten Busteilnehmer (16, 22, 24); wobei der mindestens eine zweite Busteilnehmer dazu eingerichtet ist, in Reaktion auf die Nachricht von ihm zu sendende Daten zu priorisieren und den Versand von Daten geringerer Priorität zu verzögern oder auszusetzen.
BACnet-MS/TP-Bussystem (12), umfassend: den Router nach Anspruch 6; und mindestens einen zweiten Busteilnehmer (16, 22, 24); wobei der mindestens eine zweite Busteilnehmer (16, 22, 24) dazu eingerichtet ist, seine maximale Token-Haltezeit in Reaktion auf die Nachricht zu verringern.
BACnet-MS/TP-Bussystem (12), umfassend: den Router nach Anspruch 6; und mindestens einen zweiten Busteilnehmer (16, 22, 24); wobei der mindestens eine zweite Busteilnehmer (16, 22, 24) dazu eingerichtet ist, in Reaktion auf die Nachricht für eine Zeitdauer das Versenden von Nutzdaten auszusetzen.
BACnet-MS/TP-Bussystem (12) nach Anspruch 9, wobei der mindestens eine zweite Busteilnehmer (16, 22, 24) dazu eingerichtet ist, in Reaktion auf die Nachricht das Versenden der Nutzdaten auszusetzen bis eine Auslastung eines Sendepuffers des mindestens einen zweiten Busteilnehmers (16, 22, 24) einen vorbestimmten weiteren Schwellenwert überschreitet.