DE102016004109A1 - Automatisches Vergeben vom Master-Adressen in BACNET-MS/TP-Bussystemen zur Laufzeit - Google Patents

Automatisches Vergeben vom Master-Adressen in BACNET-MS/TP-Bussystemen zur Laufzeit Download PDF

Info

Publication number
DE102016004109A1
DE102016004109A1 DE102016004109.9A DE102016004109A DE102016004109A1 DE 102016004109 A1 DE102016004109 A1 DE 102016004109A1 DE 102016004109 A DE102016004109 A DE 102016004109A DE 102016004109 A1 DE102016004109 A1 DE 102016004109A1
Authority
DE
Germany
Prior art keywords
master
bus
address
search sequence
addresses
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102016004109.9A
Other languages
English (en)
Inventor
Georg Westerkamp
Lars Friedrich
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Wago Verwaltungs GmbH
Original Assignee
Wago Verwaltungs GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Wago Verwaltungs GmbH filed Critical Wago Verwaltungs GmbH
Priority to DE102016004109.9A priority Critical patent/DE102016004109A1/de
Publication of DE102016004109A1 publication Critical patent/DE102016004109A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/403Bus networks with centralised control, e.g. polling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/50Address allocation
    • H04L61/5038Address allocation for local use, e.g. in LAN or USB networks, or in a controller area network [CAN]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L2012/4026Bus for use in automation systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Small-Scale Networks (AREA)

Abstract

Beansprucht wird ein Verfahren zum automatischen Einstellen von Master-Adressen in einem BACnet MS/TP-Bussystem. Das Verfahren umfasst das Bestimmen, durch einen ersten Busteilnehmer, einer oder mehrerer belegter Master-Adressen mittels Analysieren, durch den ersten Busteilnehmer, eines Datenverkehrs in dem BACnet MS/TP-Bussystem hinsichtlich im Datenverkehr verwendeter Master-Adressen, das Wählen, durch den ersten Busteilnehmer, einer vorläufigen Master-Adresse aus einer Gruppe von Master-Adressen, wobei die Gruppe von Master-Adressen Master-Adressen in einem vorbestimmten Adressraum, aber nicht die eine oder die mehreren belegten Master-Adressen umfasst, das Bestimmen eines Beginns einer durch einen zweiten Busteilnehmer initiierten Master-Such-Sequenz, welche zumindest die durch den ersten Busteilnehmer gewählte vorläufige Master-Adresse hinsichtlich Bussystembeitritt wünschender Busteilnehmer abfragt, das Abhören, durch den ersten Busteilnehmer, des Datenverkehrs in dem BACnet MS/TP-Bussystem während einer Beantwortungsphase der Master-Such-Sequenz, und, wenn kein dritter Busteilnehmer auf die Master-Such-Sequenz antwortet und die vorläufige Master-Adresse für sich beansprucht, das Übernehmen der vorläufigen Master-Adresse als eingestellte Master-Adresse des ersten Busteilnehmers.

Description

  • GEBIET
  • Die vorliegende Erfindung betrifft das Gebiet der Bussysteme. Insbesondere betrifft die vorliegende Erfindung das Gebiet des Vergebens von Master-Adressen 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 der „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.
  • Zur Integration neuer Master kann ein Master, der in Besitz des Tokens ist, ausgehend von seiner Adresse in einer Master-Such-Sequenz („poll for master”-Sequenz) den benachbarten Adressraum bis zur nächsten ihm als vergeben bekannten Master-Adresse „absuchen” und, wenn ein zu integrierender Master antwortet, das Token an diesen weiterreichen, wodurch dieser die Möglichkeit erhält, aktiv (d. h. ohne auf eine empfangene Nachricht zu antworten) Nachrichten über den Bus zu senden.
  • Wird in einem BACnet-MS/TP-Bussystem ein neuer Master hinzugefügt, so ist es aus dem Stand der Technik bekannt, diesem „per Hand” eine Master-Adresse zuzuordnen, d. h. ihn so zu programmieren, dass er bei Integration in das Bussystem bereits eine als nicht vergeben angenommene (freie) Master-Adresse gespeichert hat, die er im Netzwerk während der entsprechenden Master-Such-Sequenz beansprucht und damit den bereits im Netzwerk vorhandenen Mastern als verwendete Master-Adresse bekannt macht. Ist diese Adresse jedoch bereits an einen anderen Busteilnehmer vergeben oder wird sie parallel von einem (oder mehreren) weiteren neuen Busteilnehmer beansprucht, kann das Problem auftreten, dass der neue Busteilnehmer vergebens auf die entsprechende Master-Such-Sequenz wartet, weil bereits vergebene Master-Adressen in der Master-Such-Sequenz nicht angesprochen werden, oder dass zwei (oder mehr) Busteilnehmer in der gleichen Master-Such-Sequenz die gleiche Master-Adresse für sich beanspruchen und infolge dessen sich in ihrer Kommunikation über den Bus stören.
  • ZUSAMMENFASSUNG
  • Zur Vermeidung von Konflikten bei der Adressvergabe in BACnet-MS/TP-Bussystemen schlägt die vorliegende Erfindung ein Verfahren zum automatischen Vergeben von Master-Adressen in einem BACnet MS/TP-Bussystem und eine zur Durchführung des Verfahrens eingerichtete Vorrichtung (Busteilnehmer) vor.
  • Das erfindungsgemäße Verfahren zum automatischen Einstellen von Master-Adressen in einem BACnet MS/TP-Bussystem umfasst ein Bestimmen, durch einen ersten Busteilnehmer, einer oder mehrerer belegter Master-Adressen mittels Analysieren, durch den ersten Busteilnehmer, eines Datenverkehrs in dem BACnet MS/TP-Bussystem hinsichtlich im Datenverkehr verwendeter Master-Adressen, ein Wählen, durch den ersten Busteilnehmer, einer vorläufigen Master-Adresse aus einer Gruppe von Master-Adressen, wobei die Gruppe von Master-Adressen Master-Adressen in einem vorbestimmten Adressraum, aber nicht die eine oder die mehreren belegten Master-Adressen umfasst, ein Bestimmen eines Beginns einer durch einen zweiten Busteilnehmer initiierten Master-Such-Sequenz, welche zumindest die durch den ersten Busteilnehmer gewählte vorläufige Master-Adresse hinsichtlich Bussystembeitritt wünschender Busteilnehmer abfragt, ein Abhören, durch den ersten Busteilnehmer, des Datenverkehrs in dem BACnet MS/TP-Bussystem während einer Beantwortungsphase der Master-Such-Sequenz und, wenn kein dritter Busteilnehmer auf die Master-Such-Sequenz antwortet und die vorläufige Master-Adresse für sich beansprucht, ein Übernehmen der vorläufigen Master-Adresse als eingestellte Master-Adresse des ersten Busteilnehmers.
  • Als belegte Master-Adresse wird dabei insbesondere eine Master-Adresse angesehen, die von einem der Busteilnehmer im Datenverkehr, d. h. beim Senden und Empfangen von Daten über den Bus benutzt wird. Das Analysieren des Datenverkehrs umfasst dabei in zeitlicher Hinsicht vorzugsweise einen oder mehrere Token-Umläufe, wobei im Fall, dass einzelne Master-Adressen nicht in jedem Token-Umlauf angesprochen werden, sondern bspw. nur in jedem zweiten, dritten, vierten oder allgemein n-ten Token-Umlauf angesprochen werden, das Analysieren des Datenverkehrs in zeitlicher Hinsicht dementsprechend zwei, drei, vier oder allgemein „n” Token-Umläufe umfasst. Als vorläufige Master-Adresse wird ferner eine Master-Adresse angesehen, die in einem vorbestimmten Master-Adressraum liegt und von einem einen Beitritt in den Token-Umlauf wünschenden Busteilnehmer gewählt wird, um diese in einer folgenden Master-Such-Sequenz für sich zu beanspruchen, wobei die Master-Adresse insofern vorläufig ist, als die gewählte Master-Adresse hinsichtlich Kollisionsfreiheit validiert und möglichst in einer Master-Such-Sequenz in den Token-Umlauf aufgenommen werden soll, um als eingestellte Master-Adresse fortlaufend Verwendung finden zu können. Der vorbestimmte Adressraum umfasst dabei insbesondere die für Master-Adressen reservierten MAC-Adressen von 0 bis 127. Ferner kann der vorbestimmte Adressraum auch nur einen Teilraum der für Master-Adressen reservierten MAC-Adressen von 0 bis 127 umfassen, bspw. MAC-Adressen von 0 bis 100 oder MAC-Adressen von 0 bis 50. Umfasst der vorbestimmte Adressraum bspw. die MAC-Adressen von 0 bis 100 und sind die MAC-Adressen 0 bis 20 belegt, kann als vorläufige MAC-Adresse eine der MAC-Adressen 21 bis 100 gewählt werden, bspw. die nächsthöhere „freie” MAC-Adresse 21. Die Master-Such-Sequenz kann dann bspw. durch den Master mit der MAC-Adresse 20 initiiert werden, welcher die MAC-Adresse 21 hinsichtlich Bussystembeitritt wünschender Busteilnehmer abfragt. Ist als vorläufige MAC-Adresse die MAC-Adresse 22 gewählt worden, kann die Master-Such-Sequenz bspw. durch den Master mit der MAC-Adresse 20 initiiert werden, der zuerst die MAC-Adresse 21 abfragt und, falls kein Busteilnehmer auf die Abfrage antwortet, dann die MAC-Adresse 22 anfragt. Insofern beginnt eine in diesem Zusammenhang relevante Master-Such-Sequenz mit einer Abfrage einer Master-Adresse und endet mit der Abfrage einer Master-Adresse, auf die ein Busteilnehmer antwortet. Die Beantwortungsphase bzw. im Falle mehrere abgefragter MAC-Adressen die Beantwortungsphasen, schließen sich jeweils an die Abfrage einer MAC-Adresse an und enden spätestens mit der Abfrage der nächsten Master-Adresse oder nach dem Ablauf einer vorbestimmten Zeitdauer.
  • Die Beantwortungsphase umfasst somit insbesondere einen Zeitabschnitt, während dem ein Master, der die Master-Such-Sequenz initiiert hat, den Bus hinsichtlich auf die Master-Such-Sequenz antwortende Busteilnehmer abhört. Dabei kann die Master-Such-Sequenz und die Beantwortungsphase im Falle einer abzusuchenden Adresse blockartig aufeinander folgen oder im Falle mehrerer abzusuchender Adressen jeweils in Teilphasen unterteilt sein, die wechselseitig aufeinander folgen. Die Anzahl der in einer Master-Such-Sequenz abzusuchenden Adressen kann bekannt sein, bspw., wenn zwischen zwei vergebenen Master-Adressen nur eine freie Master-Adresse liegt. Ferner kann sich die Anzahl der in einer Master-Such-Sequenz abzusuchenden Adressen erst während der Abfrage manifestieren, wenn sich herausstellt, auf welche Adressabfragen ein oder mehrere Busteilnehmer antworten, wobei die Master-Such-Sequenz endet, wenn ein Busteilnehmer eine freie Master-Adresse erfolgreich beansprucht hat.
  • Im Falle mehrerer abgesuchter Adressen und somit einer Unterteilung der Beantwortungsphase in Teilphasen kann sich das Abhören insbesondere auf eine Teilphase beschränken, in der eine Beantwortung hinsichtlich der Adresse, die der Busteilnehmer beansprucht, erwartet wird, bspw., weil der Master, der die Master-Such-Sequenz initiiert hat, in der die Beantwortungsphase einleitenden Teilphase der Master-Such-Sequenz nach Busteilnehmern sucht, die genau diese Master-Adresse beanspruchen. Das Abhören des Datenverkehrs in dem BACnet MS/TP-Bussystem hinsichtlich auf die Master-Such-Sequenz während der Beantwortungsphase antwortende Busteilnehmer ermöglicht es dabei, das Auftreten potenzieller Konflikte frühzeitig zu erkennen und entsprechende Gegenmaßnahmen einzuleiten. Beispielsweise kann ein latenter Adress-Konflikt mittels einer akustischen oder optischen Ausgabe angezeigt werden und/oder ein einen potenziellen Adress-Konflikt erkennender Busteilnehmer in einen passiven Zustand versetzt werden, in dem er nicht unaufgefordert auf den Bus zugreift.
  • Vorzugsweise umfasst das Verfahren ferner, wenn ein dritter Busteilnehmer auf die Master-Such-Sequenz antwortet und die vorläufige Master-Adresse für sich beansprucht, ein Abbrechen eines Beantwortens der Master-Such-Sequenz durch den ersten Busteilnehmer.
  • Durch das Abbrechen des Beantwortens der Master-Such-Sequenz wird erreicht, dass der (potenzielle) Konflikt, welcher sich in dem gleichzeitigen Zugreifen zweier Busteilnehmer auf den Bus manifestiert, unterbunden bzw. vermieden wird und somit eine ungestörte Buskommunikation wiederhergestellt bzw. gesichert wird. Durch ein Abbrechen des Beantwortens der Master-Such-Sequenz durch parallel antwortende Busteilnehmer, die analog dem ersten Busteilnehmer eingerichtet sind, kann dabei die Situation entstehen, dass die gewählte Master-Adresse vorerst nicht vergeben werden kann und somit weiterhin zu vergeben ist.
  • Um diesen Zustand aufzufangen, umfasst das erfindungsgemäße Verfahren vorzugsweise, wenn das Beantworten der Master-Such-Sequenz abgebrochen wurde, ein Wiederholen des Beantwortens der Master-Such-Sequenz durch den ersten Busteilnehmer nach einer Zeitspanne.
  • Die Zeitspanne umfasst dabei insbesondere einen Beginn, der sich bspw. an das Abbrechen des Beantwortens anschließt, eine Dauer und ein Ende, wobei die Dauer die zwischen Beginn und Ende vergehende Zeit wiederspiegelt. Durch das Wiederholen des Beantwortens der Master-Such-Sequenz nach der Zeitspanne kann, wenn nicht erneut ein weiterer Busteilnehmer die Master-Such-Sequenz gleichzeitig beantwortet, die freie Master-Adresse an den die Master-Such-Sequenz beantwortenden Busteilnehmer konfliktfrei vergeben werden, insbesondere dann, wenn alle oder zumindest einige Busteilnehmer analog programmiert sind bzw. agieren.
  • Um die Wahrscheinlichkeit eines erneuten gleichzeitigen Beantwortens der Master-Such-Sequenz durch den weiteren Busteilnehmer zu verringern, kann die Zeitspanne mittels eines Zufallsverfahrens bestimmt werden. Alternativ kann die Zeitspanne mittels eines dem ersten Busteilnehmer statisch zugeordneten Indikators bestimmt werden. Vorzugsweise sind dabei jegliche, Busteilnehmern zugeordnete Indikatoren eindeutig, d. h. unterschiedlich, wobei die unterschiedlichen Indikatoren auf unterschiedliche Zeitspannen abgebildet werden.
  • Vorzugsweise ist die Zeitspanne (bzw. sind die Zeitspannen) kleiner als eine Dauer der Beantwortungsphase der Master-Such-Sequenz. Dadurch kann erreicht werden, dass das Hinzufügen eines neuen Masters während der ersten dafür vorgesehenen Master-Such-Sequenz erfolgen kann. Alternativ kann die Zeitspanne (bzw. können die Zeitspannen) größer als die Dauer der Beantwortungsphase der Master-Such-Sequenz sein. Dies ist insbesondere dann vorteilhaft, wenn eine größere Anzahl an Busteilnehmern die gewählte Master-Adresse beansprucht und die Beantwortungsphase der Master-Such-Sequenz zu klein erscheint, um in Anbetracht der Anzahl an Busteilnehmern, die die gewählte Master-Adresse beanspruchen, von einem mit hoher Wahrscheinlichkeit konfliktfreien Wiederholen des Beantwortens der Master-Such-Sequenz ausgehen zu können.
  • Vorzugsweise umfasst das Verfahren ein Bestimmen, in Abhängigkeit von der Anzahl der Busteilnehmer, die während der Beantwortungsphase der Master-Such-Sequenz die gewählte vorläufige Master-Adresse beanspruchen, dass die Zeitspanne (bzw. die Zeitspannen) kleiner oder größer als eine Dauer der Beantwortungsphase der Master-Such-Sequenz gewählt wird. Dadurch kann erreicht werden, dass, bspw. bei einem Neustart eines Systems, bei dem potenziell viele Busteilnehmer gleichzeitig Master-Adressen beanspruchen, der Integrationsvorgang der Busteilnehmer „entzerrt” wird, während bei dem Hinzufügen einzelner oder einer geringen Anzahl neuer Busteilnehmer, diese schnell in den Bus integriert werden können.
  • Die erfindungsgemäße Vorrichtung ist dazu eingerichtet einen Datenverkehr in einem BACnet MS/TP-Bussystem, mit dem die Vorrichtung im Betrieb verknüpft ist, hinsichtlich im Datenverkehr verwendeter Master-Adressen zu analysieren und daraus eine oder mehrere belegte Master-Adressen zu bestimmen, eine vorläufige Master-Adresse aus einer Gruppe von Master-Adressen zu wählen, wobei die Gruppe von Master-Adressen Master-Adressen in einem vorbestimmten Adressraum, aber nicht die eine oder die mehreren belegten Master-Adressen umfasst, einen Beginn einer Master-Such-Sequenz zu bestimmen, welche zumindest die durch die Vorrichtung gewählte vorläufige Master-Adresse hinsichtlich Bussystembeitritt wünschender Busteilnehmer abfragt, den Datenverkehr in dem BACnet MS/TP-Bussystem während einer Beantwortungsphase der Master-Such-Sequenz abzuhören, und wenn kein anderer Busteilnehmer als die Vorrichtung auf die Master-Such-Sequenz antwortet und die vorläufige Master-Adresse für sich beansprucht, die vorläufige Master-Adresse als eingestellte Master-Adresse der Vorrichtung zu übernehmen.
  • Vorzugsweise ist die erfindungsgemäße Vorrichtung in Übereinstimmung mit oben beschriebenen vorteilhaften Ausprägungen des erfindungsgemäßen Verfahrens ferner dazu eingerichtet, wenn ein anderer Busteilnehmer als die Vorrichtung auf die Master-Such-Sequenz antwortet und die vorläufige Master-Adresse für sich beansprucht, ein Beantworten der Master-Such-Sequenz abzubrechen.
  • Ferner ist die Vorrichtung vorzugsweise dazu eingerichtet, gleichzeitig Signale auf eine im Betrieb an die Vorrichtung angeschlossene Busleitung zu übertragen und auf der Busleitung übertragene Signale auszulesen. Dadurch wird die Vorrichtung in die Lage versetzt, ein gleichzeitiges Beanspruchen der gewählten Master-Adresse durch einen weiteren Busteilnehmer zu erkennen und die oben beschriebenen Maßnahmen zu ergreifen, um eine Vermeidung bzw. Auflösung von Adresskonflikten in BACnet MS/TP zu ermöglichen.
  • 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 1628 angeschlossen sind. Die Busteilnehmer 1628 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 1628 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 1628 ermöglicht. Das Gebäudesteuerungsgerät 32 kann insbesondere eine oder mehrere (dynamische) HTML-Seiten speichern und/oder aufrufen, über die Parameter der Busteilnehmer 1628 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 1622, 26 und 28 zu senden.
  • Das Empfangsmodul 48a und das Sendemodul 48b können dazu eingerichtet sein, ein paralleles Schreiben von Daten auf den Bus und Lesen von Daten von dem Bus zu ermöglichen. Insbesondere kann das Empfangsmodul 48a dazu eingerichtet sein, einen Spannungspegel auf der Busleitung 14 zu detektieren, während das Sendemodul 48b den Spannungspegel auf der Busleitung 14 ändert bzw. den Versuch unternimmt, den Spannungspegel aktiv zu beeinflussen. Das Vorhandensein parallel betreibbarer Empfangs- und Sendemodule 44 und 46 ermöglicht es dem Busteilnehmer 24 insbesondere zu überprüfen, ob von ihm über den Bus übertragene Daten gestört werden bzw. ob mehrere Busteilnehmer 16-28 gleichzeitig unterschiedliche Daten über den Bus übertragen.
  • Der Busteilnehmer 20 kann, wie der Busteilnehmer 24, ein Kommunikationsmodul 44 mit parallel betreibbarem Empfangs- und Sendemodulen 48a und 48b umfassen und dadurch in der Lage sein, Daten auf den Bus zu schreiben und gleichzeitig Daten von dem Bus zu lesen. Ferner können die Master-Busteilnehmer 16, 22 und 28 ebenfalls dazu eingerichtet sein, parallel Daten auf den Bus zu schreiben und gleichzeitig Daten von dem Bus zu lesen. Alternativ kann der Busteilnehmer 20 ein Kommunikationsmodul mit konsekutiv betreibbaren Empfangs- und Sendemodulen umfassen, welche dazu eingerichtet sein, abwechselnd entweder Daten auf den Bus zu schreiben oder Daten von dem Bus zu lesen. Ferner können die Master-Busteilnehmer 16, 22 und 28 ebenfalls dazu eingerichtet sein, abwechselnd entweder Daten auf den Bus zu schreiben oder Daten von dem Bus zu lesen.
  • Der Speicher 42 des Busteilnehmers 24 kann des Weiteren Anweisungen umfassen, die den Busteilnehmer 24 bei Ausführung der Anweisungen dazu programmieren, automatisch eine Master-Adresse zu wählen und eine Aufnahme in den Bus als Master-Busteilnehmer anzustreben. Der durch die in dem Speicher 42 gespeicherten Anweisungen initiierte Prozess 50 zum automatischen Einstellen einer Master-Adresse ist in 3 in Form eines Flussdiagramms dargestellt. Der Prozess 50 beginnt mit Prozessschritt 52, welcher das Analysieren des Datenverkehrs auf der Busleitung 14 umfasst. Bspw. kann der abgehörte Datenverkehr fortlaufend hinsichtlich belegter Master-Adressen analysiert werden. Die Analyse kann sich dabei über eine oder mehrere Kommunikations-Runden erstrecken, wobei eine Kommunikations-Runde einen kompletten Umlauf des Tokens über alle zu diesem Zeitpunkt vergebenen Master-Adressen umfasst (hierin auch als Token-Umlauf bezeichnet). Die Analyse ermöglicht es dem, eine Integration in den Token-Umlauf anstrebenden Busteilnehmer 24 zu bestimmen, welche Master-Adressen vergeben sind und welche Master-Adressen noch frei sind.
  • In Prozessschritt 54 wählt der, eine Integration in den Token-Umlauf anstrebende Busteilnehmer 24 eine nicht belegte vorläufige Master-Adresse, um diese in der nächsten entsprechenden Master-Such-Sequenz zu beanspruchen und als Master-Busteilnehmer in den Bus integriert zu werden. Um zu verhindern, dass die gewählte Master-Adresse zwar frei ist, aber in einem nicht verwendeten Adressbereich liegt, kann der Busteilnehmer 24 dazu programmiert sein, eine nicht belegte Master-Adresse zu wählen, die kleiner ist, als die (numerisch) größte verwendete Master-Adresse oder um eins größer ist, als die (numerisch) größte verwendete Master-Adresse. Stehen mehrere nicht belegte Master-Adressen zur Verfügung, die kleiner als die (numerisch) größte verwendete Master-Adresse sind, kann die vorläufige Master-Adresse mittels einer Zufallsfunktion ausgewählt werden. Die Zufallsfunktion kann als Parameter eine eindeutige Geräteadresse des Busteilnehmers 24 oder einen Zeitpunkt der Aktivierung des Busteilnehmers 24 verwenden.
  • In Prozessschritt 56 wird der Beginn der nächsten relevanten Master-Such-Sequenz abgewartet, d. h. der Master-Such-Sequenz, welche die von dem eine Integration in den Token-Umlauf anstrebenden Busteilnehmer 24 gewählte Master-Adresse hinsichtlich Bussystembeitritt wünschender Busteilnehmer abfragt. Eine relevante Master-Such-Sequenz ist somit eine Master-Such-Sequenz, die von einem Master-Busteilnehmer initiiert wird, dessen Master-Adresse aus der Menge der vergebenen Master-Adressen der gewählten Master-Adresse in absteigender Richtung (numerisch) am nächsten ist, bspw. dem Master-Busteilnehmer 28, und in der nach Busteilnehmern gefragt wird, die die gewählte Master-Adresse für sich beanspruchen. Im Falle, dass zwischen der vergebenen Master-Adresse, die der gewählten Master-Adresse in absteigender Richtung (numerisch) am nächsten ist, und der vergebenen Master-Adresse, die der gewählten Master-Adresse in aufsteigender Richtung (numerisch) am nächsten ist, mehrere freie Master-Adressen liegen, kann die Master-Such-Sequenz in mehrere Abschnitte unterteilt sein, nämlich dann, wenn kein Busteilnehmer die erste abgefragte Master-Adresse für sich beansprucht und der die Master-Such-Sequenz initiierende Master-Busteilnehmer sukzessive eine oder mehrere weitere Master-Adressen absucht, bis eine freie Master-Adresse von einem Busteilnehmer (erfolgreich) beansprucht wird, oder der abzusuchende Adressraum erfolglos abgesucht wurde, und die Master-Such-Sequenz beendet ist.
  • Der Prozess 50 wird nach dem Bestimmen des Beginns der nächsten relevanten Master-Such-Sequenz mit Prozessschritt 58 fortgesetzt, welcher das Abhören des Datenverkehrs während einer Beantwortungsphase der Master-Such-Sequenz hinsichtlich auf die Master-Such-Sequenz antwortender Busteilnehmer umfasst. Dabei können mehrere unterschiedliche Konstellationen auftreten. Ist der Busteilnehmer 24 der einzige Busteilnehmer, der in der Beantwortungsphase die gewählte Master-Adresse für sich beansprucht, so werden beim Abhören des Datenverkehrs während der Beantwortungsphase keine (Beantwortungs-)Aktivitäten anderer Busteilnehmer, bspw. der Busteilnehmer 1622 und 26, registriert und dementsprechend von einer konfliktfreien Vergabe der gewählten Master-Adresse ausgegangen. Da die somit erfolgreich vergebene Master-Adresse von nun an in keiner Master-Such-Sequenz mehr abgefragt wird, kann auch kein weiterer Busteilnehmer diese erfolgreich für sich beanspruchen.
  • Gibt es neben dem Busteilnehmer 24 noch einen oder mehrere andere Busteilnehmer, wie bspw. den Busteilnehmer 20, der in der Beantwortungsphase die gewählte Master-Adresse für sich beansprucht, kann der Busteilnehmer 24 dazu eingerichtet sein, den daraus entstehenden latenten Adressen-Konfliktfall zu erkennen und, wenn möglich, aufzulösen. Beispielsweise kann der Busteilnehmer 24 dazu eingerichtet sein, eine geplante Beantwortung der Master-Such-Sequenz zu stornieren, wenn beim Abhören des Datenverkehrs während der Beantwortungsphase durch Analysieren des Datenverkehrs bestimmt wird, dass ein weiterer Busteilnehmer, bspw. der Busteilnehmer 20, die gewählte Master-Adresse für sich beansprucht.
  • Ferner kann der eine Integration in den Token-Umlauf anstrebende Busteilnehmer 24 dazu eingerichtet sein, eine bereits begonnene Beantwortung der Master-Such-Sequenz abzubrechen, wenn beim Abhören des Datenverkehrs während des Beantwortens der Master-Such-Sequenz durch Analysieren des Datenverkehrs bestimmt wird, dass ein weiterer Busteilnehmer, wie bspw. der Busteilnehmer 20, die gewählte Master-Adresse für sich beansprucht. Wenn der weitere Busteilnehmer 20 dazu in der Lage ist, Daten auf den Bus zu schreiben und gleichzeitig Daten von dem Bus zu lesen, kann der weitere Busteilnehmer 20 ferner ebenfalls dazu eingerichtet sein, eine bereits begonnene Beantwortung der Master-Such-Sequenz abzubrechen, wenn beim Abhören des Datenverkehrs während des Beantwortens der Master-Such-Sequenz durch Analysieren des Datenverkehrs bestimmt wird, dass der Busteilnehmer 24 die gewählte Master-Adresse für sich beansprucht. Da in diesem Fall beide, oder im Fall mehrerer analog programmierter und agierender Busteilnehmer diese die begonnene Beantwortung der Master-Such-Sequenz abbrechen, kann es vorkommen, dass die Master-Adresse in der aktuellen Master-Such-Sequenz nicht vergeben wird.
  • Um zu verhindern, dass sich die analog programmierten und agierenden Busteilnehmer weiterhin bzw. in folgenden Master-Such-Sequenzen stören, können einige oder alle der Busteilnehmer dazu eingerichtet sein, unterschiedliche Zeitspannen zu wählen, nach denen sie das Beantworten der Master-Such-Sequenz wiederholen. Beispielsweise kann der eine Integration in den Token-Umlauf anstrebende Busteilnehmer 24 dazu eingerichtet sein, eine Zeitspanne, nach der ein Beantworten der Master-Such-Sequenz oder folgender Master-Such-Sequenzen erfolgen kann, mittels eines Zufallsverfahrens oder eines dem Busteilnehmer 24 statisch zugeordneten Indikators zu bestimmen. Das Zufallsverfahren kann bspw. auf Parametern basieren, die zur Laufzeit ermittelt werden und deren Granularität groß genug ist, um mit hoher Wahrscheinlichkeit, bspw. in mehr als 99,99% der auftretenden Fälle, zu unterschiedlichen Zeitspannen zu führen. Analog können der weitere Busteilnehmer 20 oder im Falle einer Vielzahl an weiteren Busteilnehmern alle weiteren Busteilnehmer dazu eingerichtet sein, eine Zeitspanne, nach der ein Beantworten der Master-Such-Sequenz oder folgender Master-Such-Sequenzen erfolgen kann, mittels eines Zufallsverfahrens oder eines dem weiteren Busteilnehmer 20 bzw. der Vielzahl an weiteren Busteilnehmern statisch zugeordneten Indikators bzw. Indikatoren zu bestimmen, wobei vorzugsweise alle statisch zugeordneten Indikatoren unterschiedlich und somit eindeutig sind.
  • Ferner kann der Busteilnehmer 24 dazu eingerichtet sein, die gewählte Master-Adresse nicht einzustellen und stattdessen eine alternative Master-Adresse zu wählen, wenn beim Abhören des Datenverkehrs während der Beantwortungsphase der Master-Such-Sequenz durch Analysieren des Datenverkehrs bestimmt wird, dass der weitere Busteilnehmer 20 ebenfalls besagte Master-Adresse für sich beansprucht, obwohl der Busteilnehmer 24 die Master-Adresse bereits für sich beansprucht hat, d. h. die Beantwortung der Abfrage abgeschlossen hat. Ferner kann der eine Integration in den Token-Umlauf anstrebende Busteilnehmer 24 dazu eingerichtet sein, eine eingestellte Master-Adresse nicht zu verwenden und stattdessen eine alternative Master-Adresse zu wählen, wenn beim (fortlaufenden) Abhören des Datenverkehrs nach dem Ende Beantwortungsphase der Master-Such-Sequenz durch Analysieren des Datenverkehrs bestimmt wird, dass der weitere Busteilnehmer 20 die Master-Adresse des Busteilnehmers 24 verwendet. Dadurch wird es ermöglicht, Adress-Konflikte zu vermeiden bzw. aufzulösen, auch wenn der weitere Busteilnehmer 20 nicht dazu in der Lage ist, Daten auf den Bus zu schreiben und gleichzeitig Daten von dem Bus zu lesen und somit den latenten Adresskonflikt nicht erkennen kann.
  • Der Speicher 42 des Busteilnehmers 24 kann des Weiteren Anweisungen umfassen, die den Busteilnehmer 24 bei Ausführung der Anweisungen dazu programmieren, eine automatische Anpassung der maximalen Token-Haltezeit vorzunehmen. Der durch die in dem Speicher 42 gespeicherten Anweisungen initiierte Prozess 60 der automatischen Anpassung der maximalen Token-Haltezeit ist in 4 in Form eines Flussdiagramms dargestellt. Der Prozess 60 beginnt mit Prozessschritt 62, welcher das Analysieren des Datenverkehrs in dem BACnet-MS/TP-Bussystem 12 umfasst. Bspw. kann der Datenverkehr während zwei, drei, vier, fünf oder n (mit n größer 5) Token-Umläufen analysiert werden. Die Analyse kann darauf gerichtet sein zu bestimmen, ob die Master-Busteilnehmer 16, 22 und 28 in jedem Token-Umlauf (Nutz-)Daten, d. h. über durch das BACnet-MS/TP-Protokoll vorgeschriebene Buskommunikation hinausgehende Daten senden, oder ob es einen oder mehrere Token-Umläufe gibt, in denen ein Busteilnehmer keine (Nutz-)Daten sendet. Ferner kann die Analyse darauf gerichtet sein zu bestimmen, ob einer, mehrere oder alle der Master-Busteilnehmer 16, 22 und 28 in jedem Token-Umlauf (nahezu) gleichviel (Nutz-)Daten über den Bus senden, oder ob die Menge der (Nutz-)Daten in den Token-Umläufen (um mehr als einen vorbestimmten Abweichungsfaktor) um einen Mittelwert schwankt.
  • Des Weiteren kann die Analyse darauf gerichtet sein zu bestimmen, welche Gebäudeautomatisierungsanwendung(en) bzw. welche(n) Typ(en) von Gebäudeautomatisierungsanwendung(en) die Master-Busteilnehmer 16, 22 und 28 implementieren. Dazu kann beispielsweise der Busteilnehmer 24 dazu eingerichtet sein, die Master-Busteilnehmer 16, 22 und 28 hinsichtlich der von ihnen implementierten Gebäudeautomatisierungsanwendung(en) abzufragen. Zudem kann die Analyse darauf gerichtet sein zu bestimmen, wie zeitkritisch die von den Master-Busteilnehmern 16, 22 und 28 implementierte(n) Gebäudeautomatisierungsanwendung(en) ist/sind. Dabei kann diese Information direkt von den Master-Busteilnehmern 16, 22 und 28 abgefragt werden, oder in Hinblick auf den/die Typ(en) der implementierten Gebäudeautomatisierungsanwendung(en) abgeschätzt werden. Bspw. kann der der Busteilnehmer 24 Informationen speichern, die es erlauben, einer Vielzahl an Gebäudeautomatisierungsanwendungs-Typen maximale Token-Umlaufzeiten zuzuordnen.
  • In Prozessschritt 64 wird die Analyse mit dem Bestimmen eines Daten-Sende-Musters zumindest eines der Master-Busteilnehmer 16, 22 und 28 fortgesetzt. Als Daten-Sende-Muster wird in diesem Zusammenhang insbesondere ein Daten-Sende-Verhalten angesehen, aus dem sich Rückschlüsse über zukünftiges Daten-Sende-Verhalten gewinnen lässt. Umfasst das Daten-Sende-Verhalten eine zyklische Komponente, bspw. ein Senden der gleichen Datenmenge in jedem zweiten, dritten, vierten, fünften oder n-ten (mit n größer 5) Token-Umlauf, lässt sich dies als Teil eines Daten-Sende-Musters so interpretieren, dass auch zukünftig in jedem zweiten, dritten, vierten, fünften oder n-ten Token-Umlauf die gleiche Datenmenge gesendet wird. Das Daten-Sende-Muster basiert somit auf durch Analysieren des Datenverkehrs gewonnenen Regeln, aus denen auf ein zukünftiges Daten-Sende-Verhalten geschlossen werden kann. Ein zyklisches Verhalten des Master-Busteilnehmers 16 kann bspw. durch eine Fourier-Analyse des nach dem Master-Busteilnehmer 16 gefilterten Datenverkehrs bestimmen werden.
  • In Prozessschritt 66 wird die maximale Token-Haltezeit des Busteilnehmers 24 basierend auf dem Analysieren des Datenverkehrs angepasst. Senden beispielsweise alle oder eine Mehrzahl der Master-Busteilnehmer 16, 22 und 28 (Nutz-)Daten nur in jedem zweiten, dritten, vierten, fünften oder n-ten (mit n größer 5) Token-Umlauf, kann daraus geschlossen werden, dass eine Vergrößerung der Token-Umlaufzeit diese Master-Busteilnehmer 16, 22 und 28 nicht oder allenfalls gering beeinträchtigen wird. Senden hingegen alle oder die Mehrzahl der Master-Busteilnehmer 16, 22 und 28 in jedem Token-Umlauf, kann daraus geschlossen werden, dass eine Vergrößerung der Token-Umlaufzeit diese Master-Busteilnehmer 16, 22 und 28 unmittelbar beeinträchtigen wird. Der Busteilenehmer 24 kann ferner dazu eingerichtet sein, in diesem Fall eine Vergrößerung der maximalen Token-Haltezeit des Busteilnehmers 24 insbesondere nur dann vorzunehmen, wenn die maximale (d. h. die maximal gemessene) Sende-Puffer-Auslastung des Sendemoduls 48b in den hinsichtlich Datenverkehrs analysierten Token-Umläufen einen vorbestimmten Schwellenwert überschreitet.
  • Ferner kann festgelegt sein, dass im ersten Fall eine größere Erhöhung der maximalen Token-Haltezeit vorgenommen werden kann, als im zweiten Fall. Beispielsweise kann festgelegt sein, dass die Erhöhung im ersten Fall weniger als 10% oder weniger als 5% der maximalen Token-Haltezeit und im zweiten Fall mehr als 10% oder mehr als 20% der maximalen Token-Haltezeit beträgt. Des Weiteren kann der Busteilenehmer 24 dazu eingerichtet sein, in dem Fall, in dem die maximale Sende-Puffer-Auslastung des Sendemoduls 48b in den hinsichtlich Datenverkehrs analysierten Token-Umläufen einen vorbestimmten Schwellenwert nicht überschreitet bzw. einen weiteren Schwellenwert unterschreitet, die maximale Token-Haltezeit des Busteilnehmers 24 zu verringern. Der Busteilenehmer 24 kann ferner dazu eingerichtet sein, in diesem Fall eine Verringerung der maximalen Token-Haltezeit des Busteilnehmers 24 insbesondere nur dann vorzunehmen, wenn eine Mehrzahl oder alle der Master-Busteilnehmer 16, 22 und 28 in allen Token-Umläufen (Nutz-)Daten senden.
  • Der Prozess 60 kann ferner iterativ wiederholt werden, wenn das Analysieren des Datenverkehrs ergibt, dass sich das Daten-Sende-Muster eines oder mehrerer der Master-Busteilnehmer 16, 22 und 28 strukturell verändert, bspw. wenn der eine oder die mehreren Master-Busteilnehmer 16, 22 und 28 in zusätzlichen Token-Umläufen senden bzw. wenn der eine oder die mehreren Master-Busteilnehmer 16, 22 und 28 in weniger Token-Umläufen senden, wobei eine Vergrößerung oder Verringerung der maximalen Token-Haltezeit des Busteilnehmers 24 von Wiederholung zu Wiederholung betragsmäßig kleiner ausfallen kann, um eine Konvergenz der maximalen Token-Haltezeit auf einen bestimmten Wert zu erreichen. Ferner kann eine Wiederholung des Prozesses 60 daran anknüpfen, dass Master-Busteilnehmer 16, 22 und 28 aus dem Bus entfernt oder in den Bus integriert werden. Zudem kann das Anpassen der maximalen Token-Haltezeit des Busteilnehmers 24 nach Fairness-Gesichtspunkten erfolgen, wobei ein Sendeanteil des Busteilnehmers 24 und optional Sendeanteile der Master-Busteilnehmer 16, 22 und 28 bestimmt werden und die maximale Token-Haltezeit des Busteilnehmers 24 reduziert wird, wenn der Sendeanteil des Busteilnehmers 24 einen vorbestimmten Schwellenwert übersteigt und der Sendeanteil des Busteilnehmers 24 vergrößert wird, wenn der Sendeanteil des Busteilnehmers 24 einen vorbestimmten Schwellenwert unterschreitet, bzw. wenn ein Vergleich der Sendeanteile des Busteilnehmers 24 und der Master-Busteilnehmer 16, 22 und 28 ergibt, dass die maximale Token-Haltezeit des Busteilnehmers 24 von den maximalen Token-Haltezeiten der Master-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 seien Baudrate stufenweise verringern, wobei jeder Netzwerkteilnehmer auf jeder Stufe eine vorbestimmte Zeit verharrt und einen verbindungsaufbau mit allen Netzwerkteilnehmern versucht, bspw. durch Senden einer Broadcast-Nachricht. Alternativ kann anstatt einer stufenweisen Reduktion die Baudrate auf einen Minimalwert gesetzt werden und, wenn mit zumindest einigen der Netzwerkteilnehmer eine Kommunikation wieder möglich ist, an diese Netzwerkteilnehmer eine Aufforderung übersandt werden, die Baudrate stufenweise zu erhöhen, wobei jeder Netzwerkteilnehmer dazu eingerichtet ist, Informationen darüber zu speichern, bei welcher Baudrate die Kommunikation mit Netzwerkteilnehmern, zu denen bei einer geringeren Baudrate noch eine Verbindung möglich war, abreißt. Des Weiteren oder alternativ können die Informationen eine Fehlerraten enthalten aus denen der Grad der Kommunikationsstörung zu jedem Netzwerkteilnehmer ersichtlich ist.
  • Analog dazu kann das Gebäudesteuerungsgerät 32 dazu eingerichtet sein, ebenfalls den Prozess 78 zu implementieren. Ferner kann das Gebäudesteuerungsgerät 32 dazu eingerichtet sein, die Information des Master-Busteilnehmers 28 hinsichtlich des nicht erreichbaren Routers 34 unter Verwendung der reduzierten Baudrate zu empfangen. Ferner kann das Gebäudesteuerungsgerät 32 dazu eingerichtet sein, eine Erreichbarkeitskarte basierend auf den empfangenen und gespeicherten Informationen zu erstellen. Die Erreichbarkeitskarte kann insbesondere grafisch anzeigen, über welche Netzwerkverbindungen bei welcher Baudrate eine Verbindung zwischen Netzwerkteilnehmern möglich war und unterstützt dadurch das Eingrenzen des physikalischen Netzwerkfehlers. Bspw. kann das Gebäudesteuerungsgerät 32 eine Analyseeinheit umfassen, welche dazu eingerichtet ist, Informationen hinsichtlich nicht erreichbarer Netzwerkteilnehmer von allen am Prozess beteiligten Netzwerkteilnehmern zu empfangen und bspw. in Form einer Erreichbarkeitskarte für jede Baudrate grafisch darzustellen.
  • Bezugszeichenliste
  • 10
    Netzwerkumgebung
    12
    Bussystem
    14
    Busleitung
    16
    Busteilnehmer
    18
    Busteilnehmer
    20
    Busteilnehmer
    22
    Busteilnehmer
    24
    Busteilnehmer
    26
    Busteilnehmer
    28
    Busteilnehmer
    30
    Netzwerk
    32
    Gebäudesteuerungssystem
    34
    Router
    36
    Temperatursensor
    38
    Sensor
    40
    Prozessor
    42
    Speicher
    44
    Kommunikationsmodul
    46
    Schnittstelle
    48a
    Empfangsmodul
    48b
    Sendemodul
    50
    Prozess
    52–58
    Prozessschritte
    60
    Prozess
    62–66
    Prozessschritte
    68
    Kommunikationsmodul
    70
    Kommunikationskanal
    72
    Prozess
    74–76
    Prozessschritte
    78
    Prozess
    80–84
    Prozessschritte

Claims (10)

  1. Verfahren (50) zum automatischen Einstellen von Master-Adressen in einem BACnet MS/TP-Bussystem (12), umfassend: Bestimmen, durch einen ersten Busteilnehmer (24), einer oder mehrerer belegter Master-Adressen mittels Analysieren (52), durch den ersten Busteilnehmer (24), eines Datenverkehrs in dem BACnet MS/TP-Bussystem (12) hinsichtlich im Datenverkehr verwendeter Master-Adressen; Wählen (54), durch den ersten Busteilnehmer (24), einer vorläufigen Master-Adresse aus einer Gruppe von Master-Adressen, wobei die Gruppe von Master-Adressen Master-Adressen in einem vorbestimmten Adressraum, aber nicht die eine oder die mehreren belegten Master-Adressen umfasst; Bestimmen (56) eines Beginns einer durch einen zweiten Busteilnehmer (28) initiierten Master-Such-Sequenz, welche zumindest die durch den ersten Busteilnehmer gewählte vorläufige Master-Adresse hinsichtlich Bussystembeitritt wünschender Busteilnehmer abfragt; dadurch gekennzeichnet, dass das Verfahren (50) des Weiteren umfasst: Abhören (58), durch den ersten Busteilnehmer (24), des Datenverkehrs in dem BACnet MS/TP-Bussystem (12) während einer Beantwortungsphase der Master-Such-Sequenz; und wenn kein dritter Busteilnehmer (1622, 26) auf die Master-Such-Sequenz antwortet und die vorläufige Master-Adresse für sich beansprucht, Übernehmen der vorläufigen Master-Adresse als eingestellte Master-Adresse des ersten Busteilnehmers (24).
  2. Verfahren (50) nach Anspruch 1, ferner umfassend: wenn ein dritter Busteilnehmer (20) auf die Master-Such-Sequenz antwortet und die vorläufige Master-Adresse für sich beansprucht, Abbrechen eines Beantwortens der Master-Such-Sequenz durch den ersten Busteilnehmer (24).
  3. Verfahren (50) nach Anspruch 2, ferner umfassend: wenn das Beantworten der Master-Such-Sequenz abgebrochen wurde, Wiederholen des Beantwortens der Master-Such-Sequenz durch den ersten Busteilnehmer (24) nach einer Zeitspanne.
  4. Verfahren (50) nach Anspruch 3, wobei die Zeitspanne mittels eines Zufallsverfahrens bestimmt wird.
  5. Verfahren (50) nach Anspruch 3, wobei die Zeitspanne mittels eines dem ersten Busteilnehmer (24) statisch zugeordneten Indikators bestimmt wird.
  6. Verfahren (50) nach Anspruch 4 oder 5, wobei die Zeitspanne kleiner als eine Dauer der Beantwortungsphase der Master-Such-Sequenz ist.
  7. Verfahren (50) nach Anspruch 2, ferner umfassend: wenn das Beantworten der Master-Such-Sequenz abgebrochen wurde, Beantworten einer weiteren Master-Such-Sequenz nach einer Zeitspanne, wobei die Zeitspanne größer als eine Dauer der Beantwortungsphase der Master-Such-Sequenz ist.
  8. Vorrichtung (24), welche dazu eingerichtet ist: einen Datenverkehr in einem BACnet MS/TP-Bussystem (12), mit dem die Vorrichtung (24) im Betrieb verknüpft ist, hinsichtlich im Datenverkehr verwendeter Master-Adressen zu analysieren und daraus eine oder mehrere belegte Master-Adressen zu bestimmen; eine vorläufige Master-Adresse aus einer Gruppe von Master-Adressen zu wählen, wobei die Gruppe von Master-Adressen Master-Adressen in einem vorbestimmten Adressraum, aber nicht die eine oder die mehreren belegten Master-Adressen umfasst; und einen Beginn einer Master-Such-Sequenz zu bestimmen, welche zumindest die durch die Vorrichtung (24) gewählte vorläufige Master-Adresse hinsichtlich Bussystembeitritt wünschender Busteilnehmer abfragt; dadurch gekennzeichnet, dass die Vorrichtung (24) ferner dazu eingerichtet ist: den Datenverkehr in dem BACnet MS/TP-Bussystem (12) während einer Beantwortungsphase der Master-Such-Sequenz abzuhören; und wenn kein anderer Busteilnehmer (1622, 26) als die Vorrichtung (24) auf die Master-Such-Sequenz antwortet und die vorläufige Master-Adresse für sich beansprucht, die vorläufige Master-Adresse als eingestellte Master-Adresse der Vorrichtung (24) zu übernehmen.
  9. Vorrichtung (24) nach Anspruch 8, wobei die Vorrichtung (24) ferner dazu eingerichtet ist, wenn ein anderer Busteilnehmer (1622, 26) als die Vorrichtung (24) auf die Master-Such-Sequenz antwortet und die vorläufige Master-Adresse für sich beansprucht, ein Beantworten der Master-Such-Sequenz abzubrechen.
  10. Vorrichtung (24) nach Anspruch 9, wobei die Vorrichtung (24) ferner dazu eingerichtet ist, gleichzeitig Signale auf eine im Betrieb an die Vorrichtung (24) angeschlossene Busleitung (14) zu übertragen und auf der Busleitung (14) übertragene Signale auszulesen.
DE102016004109.9A 2016-04-05 2016-04-05 Automatisches Vergeben vom Master-Adressen in BACNET-MS/TP-Bussystemen zur Laufzeit Pending DE102016004109A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE102016004109.9A DE102016004109A1 (de) 2016-04-05 2016-04-05 Automatisches Vergeben vom Master-Adressen in BACNET-MS/TP-Bussystemen zur Laufzeit

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102016004109.9A DE102016004109A1 (de) 2016-04-05 2016-04-05 Automatisches Vergeben vom Master-Adressen in BACNET-MS/TP-Bussystemen zur Laufzeit

Publications (1)

Publication Number Publication Date
DE102016004109A1 true DE102016004109A1 (de) 2017-10-05

Family

ID=59885471

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102016004109.9A Pending DE102016004109A1 (de) 2016-04-05 2016-04-05 Automatisches Vergeben vom Master-Adressen in BACNET-MS/TP-Bussystemen zur Laufzeit

Country Status (1)

Country Link
DE (1) DE102016004109A1 (de)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120254475A1 (en) * 2011-03-29 2012-10-04 Panduit Corp. Intelligent Building Automation Node
DE102013225706A1 (de) * 2013-12-12 2015-06-18 Bayerische Motoren Werke Aktiengesellschaft Adressierung von Steuergeräten

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120254475A1 (en) * 2011-03-29 2012-10-04 Panduit Corp. Intelligent Building Automation Node
DE102013225706A1 (de) * 2013-12-12 2015-06-18 Bayerische Motoren Werke Aktiengesellschaft Adressierung von Steuergeräten

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ASHRAE: Proposed Addendum bb to Standard 135-2012, BACnet - A Data communication Protocol for Building Automation and Control Networks, First Public Review (January 2015), URL: http://www.bacnet.org/Addenda/Add-135-2012am.pdf [abgerufen im Internet am 18.01.2017] *

Similar Documents

Publication Publication Date Title
EP2622826B1 (de) Verfahren zur automatischen adressvergabe an gleichartige busteilnehmer
DE602005004047T2 (de) Methode zur Zuordnung von Adressen zu einer Vielzahl von Geräten in einem Netzwerk und entsprechendes System
DE19713240C2 (de) Verfahren zur automatischen Adressenvergabe in einem CAN-Netz
EP2266297B1 (de) Automatische busadressvergabe mittels kollisionsprüfung
DE102019114303B3 (de) Verfahren zum Erfassen von Netzwerkteilnehmer in einem Automatisierungsnetzwerk und Automatisierungsnetzwerk
DE112013004976T5 (de) Adaptive Präfixdelegierung
EP2733910B1 (de) BUS-System, Verfahren zum Betrieb eines BUS-Systems und fluidisches System mit einem BUS-System
DE69434976T2 (de) Rangadressenzuweiseung in einem modulsystem
DE102014105037A1 (de) Verfahren und System zum Bedienen von Haushaltsgeräten mittels Sprachsteuerung
DE60206780T2 (de) Netzwerkverbindungsvorrichtung, verbindungssystem und netzwerkverbindungsverfahren
EP2587772B1 (de) Verfahren zum herstellen einer kommunikativen verbindung zwischen einem programmiergerät und einem automatisierungstechnischen feldgerät
DE10300281B4 (de) Verfahren zur Bestimmung eines Netzwerk-Managers im Haus-Netzwerk
DE102013225706A1 (de) Adressierung von Steuergeräten
DE102016004095B4 (de) Automatisches Eingrenzen eines physikalischen Netzwerkfehlers zur Laufzeit
DE102016004105B3 (de) Automatisches Anpassen der maximalen Token-Haltezeit in BACNET-MS/TP-Bussystemen zur Laufzeit
DE102016004109A1 (de) Automatisches Vergeben vom Master-Adressen in BACNET-MS/TP-Bussystemen zur Laufzeit
DE102016004127B3 (de) Automatische Begrenzung des Datenverkehrs in, einen Router umfassenden BACNET-MS/TP-Bussystemen zur Laufzeit
DE102012204536A1 (de) Netzwerk und Verfahren zur Übertragung von Daten über ein gemeinsames Übertragungsmedium
DE102015107478A1 (de) Sensornetzwerk und Verfahren zu seinem Betrieb
DE102009054904A1 (de) Verfahren zum Zuweisen einer Polling-Adresse an ein Feldgerät
DE10329682B4 (de) Busadressvergabe mittels Kollisionsprüfung
DE102004040069B3 (de) Aufbau eines drahtungebundenen Kommunikationsnetzes unter Ermittlung lokaler Topologieinformation aus den Kennungen der Kommunikationsgeräte
EP2232782B1 (de) Verfahren zur konfiguration von adressen in einem kommunikationsnetzwerk
DE102007034794B4 (de) Verfahren zur Inbetriebnahme und zum Betrieb eines Funksystems
DE102005047986B4 (de) Verfahren und Anordnung zur Identifikation einer Netzwerkstation

Legal Events

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

Free format text: PREVIOUS MAIN CLASS: H04L0012240000

Ipc: H04L0041000000