Anforderungen aus der Gebäudetechnik – TGA-Protokolle in strukturierten Netzen als Herausforderung

Bereits vor einiger Zeit habe ich im Insider etwas zum Thema Netzwerkplanung in modernen Gebäuden geschrieben (siehe Ausgabe vom September 2020). Dort habe ich Probleme und Herausforderungen der Planung auf einem eher sehr abstrakten Niveau betrachtet. Natürlich bleiben die dort beschriebenen Anforderungen und Vorgehensweisen weiterhin ein wichtiger Bestandteil der Planungsgrundlage. In jenem Artikel wies ich auch bereits auf das Spannungsfeld verschiedener Technologien in der Netzplanung hin, das wir im Folgenden genauer betrachten werden.

Wichtig festzuhalten ist, dass Netzwerke, welche in der Vergangenheit häufig getrennt waren, mittlerweile immer stärker zusammenwachsen. Das liegt unter anderem daran, dass inzwischen auch in der TGA Anwendungen IP-basierte Kommunikation nutzen. Daher erscheint es logisch, dass über gemeinsame Netze nachgedacht wird.

Bei der Planung bekommt man es hier jedoch häufig mit gewachsenen Strukturen und Vorgehensweisen zu tun, die aus Sicht des IT-Planers ungewöhnlich sind. Hierbei ist darauf hinzuweisen, dass ein Netzwerk als reines Layer-2-Netz auszulegen ist, in dem jedes Gerät mit jedem anderen ohne Routing direkt kommunizieren kann. Die Planung einer Layer-3-Struktur oder von Firewall-Übergängen war im Bereich der TGA in der Vergangenheit eher selten zu finden. Wir gehen jedoch davon aus, dass sich dies aufgrund der stärkeren Verbreitung moderner Komponenten und auch des BSI-Grundschutz-Bausteins für Gebäudeinfrastrukturen (siehe Insider-Artikel von Februar 2022) ändern wird.

Im Umfeld der Gebäudetechnik gibt es einen ganzen Zoo an verschiedenen Systemen und Protokollen. Natürlich findet hier ebenfalls eine entsprechende Standardisierung statt, sodass sich einige wichtige Protokolle herausgreifen lassen. So sind konkret beispielsweise KNX, Bluetooth, Zigbee, enocean, LONTalk und SMI (Standard Motor Interface) zu nennen.

Ein besonders verbreitetes Beispiel für die Anforderungen an ein TGA-Netz ist das BACnet-Protokoll. Dieses wird vor allem wegen der Forderung nach einem flachen Layer-2-Netz häufig mit dem Argument herangezogen, dass TGA-Netze bestimmte Architektur-Annahmen mit sich bringen können.

Daher wollen wir uns in diesem Artikel einen kurzen Überblick über BACnet/IP verschaffen. Selbstverständlich betrachten wir dann auch, wie damit im Netzwerk umzugehen ist und ob es mittlerweile Alternativen gibt.

Das BACnet-Protokoll – Altlasten im TGA-Netz?

Eines der Protokolle, über die man als IT-ler stolpert, wenn man sich das erste Mal mit Netzen für TGA-Gewerke beschäftigt, ist das BACnet-Protokoll. Hierbei handelt es sich um ein offenes Protokoll, das zur Anbindung von Sensoren und Anlagen an zentrale Server genutzt wird. Dabei ist das Protokoll unabhängig von der konkreten Anwendung. Die eigentliche Anwendung wird abstrahiert, indem ganz allgemein Werte gelesen (oder gemeldet) und gesetzt werden. Somit kann einem das Protokoll sowohl bei Lüftungsanlagen als auch bei der Elektrotechnik begegnen.

BACnet wurde als „Building Automation and Control Networks“ entwickelt und ist durch ASHRAE (American Society of Heating, Refrigerating and Air-Conditioning Engineers), ANSI und als ISO 16484-5 standardisiert. Die Entwicklung von BACnet begann bereits 1987 [1], was an Teilen des Standards erkennbar ist. Vornehmlich wird es durch ASHRAE [2] vorangetrieben. Daher ist BACnet als Steuerprotokoll insbesondere im Bereich der Belüftungssteuerung anzutreffen. Dennoch stellt es eine allgemein nutzbare Kommunikationsplattform dar.

Damit das Protokoll möglichst unabhängig in verschiedensten Anwendungen genutzt werden kann, wird abstrakt von Diensten (Services) und Objekten gesprochen. Für die jeweiligen Komponenten wird anhand sogenannter BACnet Interoperability Building Blocks (BIBBs) festgelegt, welche Services und Objekte unterstützt werden. Dies ist den Protocol Implementation Conformance Statements (PICS) für das jeweilige Gerät zu entnehmen.

Objekte in einem BACnet-Netzwerk bilden die Eigenschaften der Geräte ab, die ausgelesen werden können. Somit können der aktuelle Wert, der Name des Objekts und weitere Parameter ermittelt werden. Diese Werte werden oftmals auch als Datenpunkte bezeichnet. Genaue Details der Endgeräte und Funktionen können sich je nach konkreter Anwendung deutlich unterscheiden.

Ein durchaus wünschenswertes, wenn auch manchmal lästiges Ergebnis des Alters von BACnet ist die Tatsache, dass es zu verschiedensten Kommunikationsprotokollen kompatibel ist und weiterhin zu älteren Protokollen kompatibel bleibt. Die grundsätzliche Annahme lautet, dass die darunterliegende Kommunikation (mehr oder minder) beliebig austauschbar ist. Dies wird dem einen oder anderen mit Sicherheit aus dem ISO/OSI-Schichtenmodell bekannt vorkommen.

Tatsächlich kann, wie übrigens allgemein im ISO/OSI-Modell für IT-Anwendungen vorgesehen, die BACnet-Schicht (weitestgehend) beibehalten werden, selbst wenn andere Teile der Architektur ausgetauscht werden. Es ist möglich, BACnet grob im ISO/OSI-Modell darzustellen, wie in Abbildung 1 gezeigt, wobei man allerdings anmerken muss, dass die Abbildung auf das ISO/OSI-Modell nicht immer eindeutig ist. So wird oft nicht klar definiert, ob bspw. die Transportschicht bereits zum BACnet Application Layer gehört. Die Darstellung kann also nur ein Beispiel sein. Ebenso wird die klassische Sicherungsschicht des Öfteren dem BACnet Virtual Link Layer zugeordnet. Zudem versteht BACnet die Schicht 1 nicht ausschließlich als Physik, sondern abstrahiert von der Realität, indem weitere Schichten dazugezählt werden können. Das bei BACnet/IP angewandte Modell lässt sich daher nicht wirklich dem üblichen ISO/OSI-Modell zuordnen.

Die hierbei dargestellte Schicht „BACnet Virtual Link Layer (BVLL)“ abstrahiert dabei von dem eigentlichen Kommunikationsmittel. Sie kann auf Ethernet mit IPv4 (BACnet/IP) oder IPv6 (BACnet/IPv6) sowie MS/TP (Master Slave Token Passing), PTP (Point-To-Point), ZigBee und weiteren basieren.

Hinsichtlich der Kommunikationsbeziehung wird auch bei BACnet häufig von einem Client-Server-Modell gesprochen, wobei wichtig ist, dass es keine klare Aufteilung der beteiligten Geräte in Server und Clients gibt. So werden die in der Fläche verteilten Geräte und Sensoren oft als Server angesehen, da diese Informationen oder Services anbieten. Der Steuerungsserver ist in diesem Sinne eher der Client und ist hinsichtlich des Managements als Server zu verstehen.

Das BACnet-Netz

Für uns als Netzwerkplaner ist BACnet vor allem dann relevant, wenn es auf üblicher Netzwerktechnik aufbaut. In dem Fall kommt es im Gewand von BACnet/IP daher. Deswegen wollen wir uns genau diesem Thema nähern.

Bei BACnet/IP wird der BACnet Virtual MAC Layer und der BACnet Virtual Link Layer basierend auf Ethernet- und IP-Kommunikation genutzt. Um zu den BACnet-Schichten weiter oben kompatibel zu sein, wird von BACnet/IP eine virtuelle BACnet-MAC-Adresse bereitgestellt. Diese dient der eindeutigen Bezeichnung des jeweiligen Geräts.

Hinsichtlich des Aufbaus entsprechender Netze ist in der Abstimmung und Kommunikation zwischen Netzwerkplanern und TGA-Verantwortlichen ein weiterer Aspekt wichtig. Eine Anwendung bzw. ein Gewerk muss in der Gesamtsicht nicht in jedem Teil die gleichen Kommunikationsprotokolle einsetzen. Üblicherweise unterscheidet man hier zwischen Feldebene, Automationsebene und Managementebene. Diese Ebenen sind in der DIN EN ISO 16484-2 definiert.

Die Feldebene dient der direkten Anbindung von Sensoren und Aktoren und basiert daher häufig auf einfachen Protokollen oder 2-Draht-Verbindungen. Die Automationsebene dient der Steuerung der Geräte der Feldebene und die Managementebene der Konfiguration und Überwachung durch den Menschen. Insbesondere die letztgenannte Funktion, doch auch die Automatisierung, basieren sehr häufig auf BACnet/IP. Für den TGA-Planer sind allerdings die weiteren nachgelagerten Datenpunkte ebenso relevant.

Aus IT- bzw. Netzwerksicht sind die Kommunikationsprotokolle natürlich spannend, um zu verstehen, welche Anforderungen erfüllt und in der Planung berücksichtigt werden müssen. Dann wird recht schnell deutlich, dass BACnet/IP hier besondere Anforderungen an die Struktur des Netzes hat. Am offensichtlichsten ist dabei die Tatsache, dass der Standard Kommunikationsnachrichten auf Unicast und als Broadcast definiert. Das bedeutet, Daten können anwendungsabhängig entweder direkt einem Endgerät oder eben allen BACnet-Geräten im Netzwerk mitgeteilt werden.

Daraus folgt, dass BACnet prinzipiell davon ausgeht, dass das Kommunikationsmedium Broadcast jeder-zu-allen unterstützt. Auch wenn dies mit Ethernet als Basis erfüllt ist, wissen wir doch, dass komplexere Architekturen es nicht unterstützen, wenn eine Layer-3-Strukturierung genutzt wird. An dieser Stelle fangen die Abstimmungsprobleme in Bauprojekten an, in denen der TGA-Planer und der Netzwerkplaner sich nicht ausreichend miteinander unterhalten. Im schlimmsten Fall sind die Planungen am Ende nicht aufeinander abgestimmt, da die Annahmen nicht korrekt waren.

Das offensichtlichste Beispiel für die Nutzung von Broadcast-Nachrichten im BACnet ist der „Who-Is“-Dienst. Im BACnet-Umfeld werden Geräte über Instanznummern (von 0 bis 4.194.302) identifiziert (ähnlich eines Namens oder einer IP-Adresse). Im zusammenhängenden Netzwerk ist diese eindeutig. Um bei BACnet unabhängig von der darunterliegenden Kommunikationstechnologie zu sein, hat man hier eben nicht bereits bestehende IP- oder MAC-Adressen verwendet. Für die tatsächliche Kommunikation muss bei BACnet/IP jedoch von der Instanznummer auf eine IP-Adresse übersetzt werden. Analog zu ARP im IP-Umfeld sendet bei BACnet ein Gerät eine „Who-Is“-Nachricht mittels Broadcast an alle. Der zuständige Knoten antwortet dann entsprechend mit einer „I-am“-Nachricht. Dies kann nur innerhalb einer Broadcast-Domäne funktionieren.

BACnet im gerouteten Netz

Sieht die Netzwerk-Architektur, an die BACnet/IP-Geräte angebunden werden, eine Layer-3-Strukturierung vor, so können diese Broadcast-Mechanismen nicht selbstverständlich funktionieren. In diesem Fall muss dies bei der Planung berücksichtigt und weitere Mechanismen im BACnet-Netzwerk verwendet werden.

Um BACnet in einem klassischen strukturierten Netzwerk zu nutzen, müssen entsprechende Rahmenparameter beachtet werden. Eine Option ist es, gezielt für die BACnet-Geräte ein flaches Layer-2-Netz im Sinne eines einzelnen VLANs über den gesamten Standort zu spannen. Dass dies nicht in jedem Fall eine Option ist, wird schnell klar. Einerseits will man meist solche Sonderlösungen, die von der vielleicht im jeweiligen Unternehmen üblichen Struktur abweichen, prinzipiell vermeiden. Andererseits ist auch in Zukunft zu erwarten, dass immer mehr zu steuernde Geräte angebunden werden. Damit machen eine Strukturierung und Eingrenzung der Broadcast- und Fehler-Domäne durchaus Sinn.

Zu guter Letzt spricht auch das Thema Sicherheit gegen ein willkürlich groß gewähltes Netz. Verschiedene TGA-Geräte mit BACnet-Anbindung an die gleichen Monitoring-Server stammen nicht selten von verschiedenen Herstellern und werden vor allem häufig von verschiedenen externen Dienstleistern gewartet und konfiguriert. Eine Trennung in unterschiedliche logische Netze erscheint daher sinnvoll, um das Sicherheitsrisiko zu minimieren und die Kommunikation nur über eine Firewall zu erlauben. Damit fällt ein Verzicht auf mittels Routing strukturierte Netze als Lösung für die Broadcast-Notwendigkeit meist aus.

Als Alternative bietet BACnet jedoch eine Funktion, welche genau für diesen Zweck vorgesehen ist. Es lassen sich sogenannte BACnet Broadcast Management Devices (BBMD) als Komponenten vorsehen, welche explizit dafür da sind, Broadcast-Meldungen zu empfangen und als Unicast an andere BACnet-Komponenten weiterzuleiten. Diese können die Nachrichten in ihrem Netzbereich wiederum als Broadcast aussenden. Somit lässt sich BACnet/IP ebenfalls in gerouteten Netzen einsetzen. Abbildung 3 stellt dies schematisch dar.

Wie Abbildung 4 zeigt, werden dem BBMD die zu verwendenden Unicast-Ziele mitgegeben. Dies erfolgt üblicherweise anhand einer statischen Konfiguration der IP-Adresse. Das bedeutet, dass insbesondere bei großen Netzen der Einsatz von BBMDs mit einem enormen Konfigurationsaufwand verbunden ist. Das Gesamtkonstrukt ist an dieser Stelle relativ unflexibel und statisch. Jedes BBMD muss demnach alle anderen BBMDs mitgeteilt bekommen.

Einfluss auf die Planung

In Projekten haben wir jedoch bereits mehrfach erlebt, dass Planer der TGA-Umgebung tatsächlich meist keine BBMDs vorsehen. Daher ist es im Rahmen der Planung zwingend notwendig, hier rechtzeitig ein gemeinsames Verständnis zu schaffen, damit der TGA-Planer eine geeignete Komponente oder Konfiguration berücksichtigt. Andernfalls werden die Systeme bei der Inbetriebnahme nicht funktionieren.

Soweit dies berücksichtigt wird, kann also ein Netzwerk, wie es bei der IT üblich ist, für die Gebäudesteuerung verwendet werden. Mit dem Einsatz von BBMDs lässt sich BACnet in einem Netzwerk, wie es heute vielfach vorzufinden ist, nutzen. Eine klassische Architektur mit Layer-2- und Layer-3-Mechanismen ist somit anwendbar. Wichtig ist an dieser Stelle die Abstimmung mit den beteiligten Gewerken.

TGA-Anwendungen und deren Anforderungen können ebenfalls einen Einfluss auf die Architektur des Netzes haben. Wie oben erläutert gilt dies im Hinblick auf BACnet insbesondere dann, wenn keine BBMDs genutzt werden. Doch auch sonst sollte einem bewusst sein, dass zumindest im jeweiligen Netzteil Broadcasts ein zentrales Kommunikationsmittel sind. Systeme und Protokolle, die mit entsprechenden Broadcasts nicht effizient umgehen, sind im Netzdesign folglich zu vermeiden oder zumindest mit Bedacht zu begutachten. Dies kann unter Umständen Software-Defined Networks bzw. Overlays betreffen und somit zu Einschränkungen beim Einsatz von BACnet und möglichen Netzarchitekturen führen.

Es sollte keine zu kleinschrittige Segmentierung in VLANs erfolgen, da entsprechend viele BBDMs benötigt würden. Dies würde zwangsläufig den Konfigurationsaufwand erhöhen. BACnet/IP-Geräte setzen üblicherweise eine möglichst statische Umgebung voraus, da IP-Adressen manuell konfiguriert werden.

Entsprechender Aufwand entsteht ebenso bei der Erstellung und Pflege von Firewall-Regeln. Wird eine konsequente Netztrennung umgesetzt, so müssen Firewalls die verschiedenen Netzteile abtrennen und nur der benötigte Datenverkehr zugelassen werden. Dies wäre nochmal aufwendiger, wenn entsprechende Regeln für eine Anbindung an zentrale Systeme oder sogar eine Cloud direkt mit klassischen BACnet/IP-Konzepten und BBMDs vorgesehen würde. Demzufolge sind solche Konzepte meist schwer umsetzbar oder gar nicht denkbar.

Bei komplexeren und größeren Netzen ist die direkte Kommunikation zwischen BACnet-Geräten bzw. BBMDs von jedem logischen Netzwerk (VLAN) in jedes andere VLAN notwendig. In vielen Fällen ist damit eine Kommunikation von jedem VLAN in jedes andere VLAN mit BACnet-Geräten zu ermöglichen. Um zumindest die Konfiguration in Umgebungen mit mehreren Standorten zu vereinfachen, gibt es alternativ die Möglichkeit, sogenannte Master einzusetzen, die mehrere entsprechende Zonen verbinden und Nachrichten weiterleiten. Einzelne BBMDs müssen dann nur noch ihren Master erreichen können, während dieser weiterhin alle BBMDs im Gesamtnetz kennen und erreichen können muss.

BACnet/SC als Lösung

Damit erscheint der Einsatz von BBMDs zwar durchaus machbar, doch nicht unbedingt dem entsprechend, was man mittlerweile aus anderen IT-Bereichen in Bezug auf Automatismen und Einfachheit kennt. Aus diesem Grund gibt es inzwischen eine neuere Version des BACnet-Standards. Konkret wurde mit BACnet/SC (Secure Connect) TLS und HTTP als Kommunikationsebene im Sinne eines BACnet Link Layer eingefügt. Das bedeutet, dass statt der bisherigen UDP/IP-Basis eine HTTPS-Basis auf Grundlage heute gängiger Webtechnologien verwendet wird. In Abbildung 5 ist das Schichtenmodell von BACnet und BACnet/SC entsprechend dargestellt.

Damit können alle Mechanismen verwendet werden, die bei üblicher Internetkommunikation ebenfalls infrage kommen. Zentrale Komponenten können nun mit Domain-Namen anstatt mit IP-Adressen angesprochen werden. Eine manuelle Konfiguration von IP-Adressen für zu erreichende Gegenstellen wird somit überflüssig und der Aufwand an entscheidenden Punkten in der Konfiguration und in der Einrichtung von BACnet/IP-Netzen reduziert.

Um die notwendige Einrichtung in Bezug auf Broadcasts und damit BBMDs zu minimieren, hat man mit BACnet/SC das BBMD-Konstrukt durch BACnet/SC-Hubs als zentrale Komponenten ersetzt. Ein Hub stellt in diesem Sinne eine zentrale Komponente dar, die für entsprechende Dienste wie die Namensauflösung abgefragt werden kann. Statt Broadcasts findet eine HTTPS-basierte Abfrage auf dem Hub statt. Im Gegensatz zu BACnet/IP lassen sich damit ebenso die gängigen Loadbalancing- und Redundanzmechanismen nutzen, welche in der eingesetzten Serverlandschaft üblich sind.

Ein Hub kann dabei beliebig im Netz platziert sein, da lediglich Unicast-Kommunikation auf TCP-Basis stattfindet. Somit lassen sich auch BACnet-Hubs in der Cloud denken, ohne einen großen Konfigurationsaufwand zu erzeugen. Eine Kommunikation muss hier nicht mehr paarweise zwischen allen involvierten BACnet-VLANs ermöglicht werden, sondern lediglich zwischen jedem VLAN und dem Hub.

Hierbei stellen BACnet/SC-Nodes einen Tunnel zum Hub her. Hinsichtlich der Kommunikation kann man sich dies ähnlich der Verbindung zu einem VPN-Gateway vorstellen. BACnet/IP-Kommunikation wird durch diesen Tunnel zum Hub geleitet. Dieser kann die Daten und BACnet-Nachrichten, die er empfängt, an alle verbundenen Endgeräte weiterleiten. Der Aufbau der Verbindung bzw. des Tunnels findet dabei immer vom BACnet-Gerät hin zum Hub statt.

Der Node kann hierbei im lokalen Netz die Funktion des BBMDs übernehmen und Broadcasts an den Hub weiterleiten, sodass lediglich dieses eine Gerät entsprechend konfiguriert sein muss.

Manchmal wird dies von Herstellern sogar damit beworben, dass man in der Firewall gar keine Konfiguration vornehmen müsse. Schließlich würden nur TCP-Verbindungen nach außen aufgebaut. Das mag bei einer einfachen Firewall-Konfiguration, die ausgehende TCP-Verbindungen grundsätzlich zulässt, stimmen. Bei einem restriktiveren Regelwerk oder bei Proxies, wie im Unternehmensumfeld üblich, gilt diese Behauptung nicht. Hier wird im Normalfall keine ungeregelte Kommunikation nach außen zugelassen. Dennoch vereinfacht der Einsatz von BACnet/SC im Vergleich zu BACnet/IP die Firewall-Konfiguration deutlich.

Management-PCs können auf dieselbe Art und Weise ebenfalls den Hub erreichen und über diesen Weg das BACnet-Netzwerk verwalten.

Neben der Tatsache, dass BACnet/SC sich viel stärker an dem Client/Server-Modell der Internet- und Cloud-Idee orientiert, bringt die Nutzung von HTTPS einen weiteren unter Umständen wichtigen Vorteil. BACnet/SC ist verschlüsselt. Damit lässt sich eine sichere BACnet-Steuerung über fremdverwaltete Netze ebenfalls erreichen.

Im Vergleich zwischen BACnet/IP und BACnet/SC kann man aus IT-Sicht festhalten, dass BACnet/SC durchaus einige Vorteile mitbringt. Die Lösung ist nicht nur in Bezug auf die Arbeitsweise mit Broadcasts eleganter, sondern vereinfacht in vielen Fällen ebenso die Konfiguration (z.B. in Bezug auf Firewall-Regeln). Vor allem kann der BACnet/SC-Hub auch im Internet bzw. der Cloud sein. Damit macht BACnet einen wichtigen Schritt in dieselbe Richtung wie viele andere IT-Anwendungen.

Leider sieht man auch hier, wie bei den meisten Neuentwicklungen, dass es einige Zeit dauert, bis sich eine Technologie am Markt durchsetzt. So ist BACnet/SC heute eher eine Ausnahme. Dies im Rahmen einer Ausschreibung von Gebäudetechnik zu fordern sorgt schnell für eine sehr kurze oder leere Bieterliste. Wir würden dennoch empfehlen, diese Forderung bei Beschaffungen zu berücksichtigen, sei es auch nur als Bewertungskriterium, weil damit eine deutliche Flexibilität gewonnen wird.

Zusammenfassung

Die in diesem Artikel beschriebenen Technologien BACnet/IP und BACnet/SC sind vor allem Beispiele für klassische Gebäudetechnik-Protokolle. Es gibt eine ganze Reihe weiterer Systeme, die im Netzwerk für die TGA eine wichtige Rolle spielen und berücksichtigt werden müssen.

Es wird deutlich, dass die oben beschriebenen Einschränkungen und Zusammenhänge eine wichtige Grundlage für die Planung eines Gebäudetechnik-Netzes nach aktuellem Stand darstellen. Mindestens bei gemeinsam genutzten Netzen ist zu erwarten, dass die Topologie eher dem aus dem Büro-IT-Bereich bekannten 2- oder 3-Tier-Schema entspricht. Aufgrund der hohen Anzahl an Endgeräten im TGA-Netz der Zukunft wird dies in reinen Gebäudetechnik-Umgebungen voraussichtlich zum Standardfall werden.

Damit entsteht die Notwendigkeit, die Planung der Gebäudetechnik mit der Planung der Netzwerkinfrastruktur abzugleichen. Somit wird die Planung eines Netzwerks für die TGA eine Herausforderung. Zu simple oder unstrukturierte Netzwerkumsetzungen müssen der Vergangenheit angehören.

Weiterführende Informationen

[1] BACnet Website. http://www.bacnet.org/

[2] American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE). https://www.ashrae.org/

[3] ASHRAE (2018). BACnet Secure Connect Whitepaper. https://www.ashrae.org/File%20Library/Technical%20Resources/Bookstore/BACnet-SC-Whitepaper-v10_Final_20180710.pdf

[4] H. M. Newman. Broadcasting BACnet. http://www.bacnet.org/Bibliography/BACnet-Today-10/Newman_2010.pdf

[5] BACnet International. Introduction to BACnet For Building Owners and Engineers.  https://www.ccontrols.com/pdf/BACnetIntroduction.pdf