BACnet in öffentlichen Gebäuden

Transcription

BACnet in öffentlichen Gebäuden
BACnet in öffentlichen Gebäuden
(BACnet 2007)
lfd. Nr. 099
Aufgestellt und herausgegeben vom Arbeitskreis
Maschinen- und Elektrotechnik staatlicher
und kommunaler Verwaltungen (AMEV)
Berlin 2007
Geschäftsstelle des AMEV im Bundesministerium
für Verkehr, Bau und Stadtentwicklung (BMVBS), Ref. B 12
Krausenstrasse 17-20, 10117 Berlin,
Telefon (030) 2008-7321
[evtl. auch unter (033234) 81488 telefonisch erreichbar]
Computerfax: (030) 2008-807-7126
e-mail: [email protected]
Der Inhalt dieser Broschüre darf nur nach vorheriger Zustimmung
der AMEV-Geschäftsstelle auszugsweise vervielfältigt werden.
Die Bedingungen für die elektronische Nutzung der AMEV-Empfehlungen
sind zu beachten (siehe www.amev-online.de)
Informationen über Neuerscheinungen erhalten Sie unter
www.amev-online.de
oder bei der AMEV-Geschäftsstelle
BACnet 2007
Inhaltsverzeichnis
Vorwort..................................................................................................... 6
Geleitwort................................................................................................. 8
1
Geltungsbereich und Anwendungshinweise.........................................10
2
2.1
2.2
2.3
Einleitung................................................................................................12
Normung..................................................................................................... 12
Grundidee des BACnet-Protokolls............................................................. 13
Aufbau von BACnet-Systemen................................................................... 14
3
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
Grundlagen.............................................................................................16
BACnet®..................................................................................................... 16
Objekte........................................................................................................ 16
Properties.................................................................................................... 16
Dienste........................................................................................................ 18
Client-Server-Prinzip................................................................................... 19
Interoperabilitätsbereiche........................................................................... 20
BIBBs.......................................................................................................... 20
Standard-Gerätprofile................................................................................. 21
PICS............................................................................................................ 22
Konformitätstests........................................................................................ 23
EDE-Listen.................................................................................................. 24
4
4.1
4.2
4.3
4.4
Realisierung von BACnet-Systemen......................................................25
Planung und Ausführung............................................................................ 25
Empfohlene BACnet-Funktionen................................................................ 28
Zuordung von GA-Funktionen zu BACnet-Objekttypen............................. 33
Reaktionszeiten........................................................................................... 36
BACnet 2007
5
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
Automationsstationen (AS)....................................................................38
Allgemeines................................................................................................ 38
Einrichten und Anzeigen von Informationen.............................................. 39
Melden von Informationen, Ereignissen und Alarmen............................... 40
Meldungsklasse.......................................................................................... 43
E/A-Objekte................................................................................................. 44
Betriebsstundenerfassung.......................................................................... 46
Zeitabhängiges Schalten mit Zeitplan und Kalender................................. 47
Zeitsynchronisation..................................................................................... 48
Trendaufzeichnung..................................................................................... 49
Regler.......................................................................................................... 50
Handeingriff................................................................................................. 50
Systemstörungen........................................................................................ 51
6
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
Management- und Bedieneinrichtung (MBE)........................................53
Allgemeines................................................................................................ 53
Hardware..................................................................................................... 55
Betriebssystem........................................................................................... 55
Beobachten und Bedienen......................................................................... 55
Störungsmanagement................................................................................ 56
Zeitabhängiges Schalten............................................................................ 56
Trenddaten und historische Daten............................................................. 56
Medienverbrauchserfassung...................................................................... 56
7
7.1
7.2
7.3
7.4
7.5
7.6
7.7
7.8
Anforderungen an Netzwerke................................................................57
Netzwerkprotokolle..................................................................................... 57
BACnet/IP.................................................................................................... 58
BACnet MS/TP............................................................................................ 59
BACnet LONTalk......................................................................................... 60
BACnet PTP................................................................................................ 61
BACnet-Adressierung................................................................................. 61
Anschluss an universelle Datennetze......................................................... 62
Datenschutz gegen Fremdeinwirkungen................................................... 63
8
8.1
8.2
8.3
8.4
Umsetzungskonzepte.............................................................................64
Planmäßiges Vorgehen............................................................................... 64
Empfehlungen für BACnet-Anschlussbedingungen.................................. 65
Kriterien für BACnet-basierte Migrationskonzepte..................................... 67
Anwendungsprobleme und Verbesserungsvorschläge............................. 69
Anhang
Anh. 1 Objekttypen: Übersicht..........................................................................71
Anh. 2 Objekttypen und GA-Funktionen (Zuordnungsbeispiele)....................74
Anh. 3 Objekttypen: Anwendungsbeispiel RLT-Anlage...................................78
Anh. 3.1 Anlagenschema RLT-Anlage (Beispiel)....................................................... 78
Anh. 3.2 Zuordnung der GA-Funktionen und Objekttypen (RLT-Anlage)................. 79
Anh. 4 Empfohlene Objekttypen, Properties und Zugriffsrechte.....................82
Anh. 4.1 Objekttyp Gerät . ........................................................................................ 82
Anh. 4.2 E/A-Objekttypen.......................................................................................... 85
Anh. 4.3 Komplexe Objekttypen............................................................................... 88
Anh. 5 BIBBs: Übersicht mit Empfehlungen....................................................92
Anh. 6 PICS (Muster mit deutschen Begriffen)................................................98
Anh. 7 EDE-Liste.................................................................................................100
Anh. 7.1 Erläuterung der Angaben........................................................................... 100
Anh. 7.2 EDE-Tabelle (Muster).................................................................................. 104
Anh. 7.3 BACnet Objekttyp (mit Object Type Code)................................................ 105
Anh. 7.4 Zustandstext (Beispiele)............................................................................. 106
Anh. 7.5 Physikalische Einheiten.............................................................................. 108
Anh. 7.6 Meldungsklasse (Beispiele)........................................................................ 112
Anh. 8 Glossar....................................................................................................113
Anh. 9 Literaturhinweise....................................................................................117
Mitarbeiterinnen und Mitarbeiter..........................................................................118
BACnet 2007
Vorwort
Der Arbeitskreis Maschinen und Elektrotechnik staatlicher und kommunaler Verwaltungen (AMEV) hat die Grundsätze und unterschiedlichen Verfahren für die Planung,
Errichtung und den Betrieb einer systemübergreifenden Gebäudeautomation (GA) in
öffentlichen Gebäuden in der Empfehlung „Gebäudeautomation 2005“ zusammengefasst.
Bei Neubauten und GA-Sanierungen entscheidet sich eine zunehmende Anzahl von
Bauherren für offene GA-Systeme und nutzt dabei u. a. das Kommunikationsprotokoll
BACnet (Building Automation and Control Networks).
Das BACnet-Protokoll wurde Ende der 80er Jahre durch den amerikanischen Ingenieurverein ASHRAE entwickelt. Durch die Aufnahme als ISO-Norm verfügt das
BACnet-Protokoll über die Vorteile einer breiten Unterstützung und langfristigen Zukunftssicherheit. BACnet bildet eine Vielzahl möglicher GA-Funktionen mit Hilfe eines
universellen, IT-orientierten Baukastensystems ab und bietet gute Perspektiven für
zukünftige Entwicklungen.
Allerdings fällt die praktische Anwendung der umfangreichen, englischsprachig verfassten BACnet-Norm schwer. Vielfältige Optionen innerhalb der Normfestlegungen,
mögliche proprietäre Erweiterungen und teilweise auch fehlende Kompatibilität zwischen Norm-Versionen führen nicht selten zu erhöhtem Aufwand bei Planung und
Ausführung sowie Einschränkungen der beabsichtigten Interoperabilität und Investitionssicherheit.
Zur Unterstützung der Planer und Anwender hat der AMEV die Erfahrungen bei bereits ausgeführten BACnet-Projekten in der Empfehlung „BACnet 2007“ zusammengefasst. Dabei wurden Anforderungen an BACnet-Systeme formuliert, mit denen die
Interoperabilität dieser Systeme in öffentlichen Gebäuden verbessert werden kann.
TGA-Fachleuten ohne vertieftes GA-Fachwissen bietet die Empfehlung – aufbauend
auf der „Gebäudeautomation 2005“ – eine kurze und verständlich formulierte Einführung in die Grundlagen und Begriffe des BACnet-Protokolls mit kompakten Darstellungen und Erläuterungen der wichtigsten Funktionalitäten.
Die darüber hinaus gehenden Informationen richten sich an GA-Fachleute und Betreiber von BACnet-Systemen. Diese sollten über fundiertes GA-Fachwissen und
einschlägige Erfahrungen verfügen. Die Hinweise vertiefen die Einblicke in das Leistungsspektrum des BACnet-Protokolls und empfehlen praxisorientierte Schritte u. a.
für eine herstellerneutrale Realisierung von interoperablen BACnet-Projekten.
Um die effiziente Nutzung des BACnet-Protokolls in den öffentlichen Liegenschaften
zu fördern, wird eine Grundausstattung für die BACnet-Funktionalität in öffentlichen
Gebäuden definiert, die die Grundanforderungen an BACnet-Systeme vereinheitlicht
und den projektspezifischen Abstimmungsaufwand reduziert. Wirtschaftliche Kopplungen unterschiedlicher BACnet-Geräte mit herstellerübergreifender Interoperabilität
werden damit deutlich vereinfacht.
Die „BACnet 2007“ wurde mit der BACnet-Interest Group Europe (BIG-EU) abgestimmt.
MR Dipl.-Ing. Jürgen Hardkop
Vorsitzender des AMEV
und Obmann der Empfehlung
BACnet 2007
Geleitwort
Nach der ersten Veröffentlichung des BACnet Standards im Jahr 1995 dauerte es
nicht lange, bis auch in Europa der Nutzen und die zukünftigen Möglichkeiten, die
sich aus seiner Anwendung ergeben, bei Herstellern, Planern und Gebäudebetreibern gleichermaßen erkannt wurden.
Schnell wurde aber auch klar, dass die erfolgreiche Markteinführung und Anwendung
eines solchen Standards begleitender Maßnahmen bedarf, um Anwender über Möglichkeiten und Nutzen zu informieren und Planung, Ausschreibung und Ausführung
der BACnet-Projekte zu unterstützen.
All diese Punkte hat sich seit ihrer Gründung im Jahr 1997 die BACnet-Interest Group
Europe (BIG-EU) zur Aufgabe gemacht.
In diesem Sinne betrachtet die BIG-EU die vorliegende AMEV-Empfehlung als weiteren wichtigen Beitrag zur Realisierung von BACnet insbesondere in öffentlichen
Gebäuden.
Die neue Empfehlung ergänzt die wichtigen Grundsätze für Gebäudeautomation, die
der AMEV vor wenigen Jahren in der „Gebäudeautomation 2005“ formuliert hat. Damit sendet die öffentliche Hand erneut ein klares Signal, dass der Gebäudeautomation eine hohe Bedeutung beizumessen ist, und dies insbesondere auf der Basis
der allgemein anerkannten Standards für Kommunikation in Gebäuden.
Die BACnet-Empfehlung kommt gerade zur rechten Zeit. Nachdem praktische Erfahrungen aus zahlreichen BACnet-Projekten vorliegen, mittlerweile eine große Palette unterschiedlicher BACnet-Produkte bei vielen Herstellern angeboten wird, ist
nun auch ein automatisierter und vollständiger Konformitätstest verfügbar. Zur Light
& Building 2008 werden die ersten Automationsstationen mit Zertifikat zur Verfügung
stehen.
Die vorliegende Empfehlung berücksichtigt die aktuellen Entwicklungen. Die Erläuterungen des BACnet-Protokolls sind klar und erschöpfend. Dabei wurde besonders
auf eine durchgängige Verwendung deutscher Begriffe geachtet, wodurch das Verständnis deutlich vereinfacht und vielen Anwendern der Einstieg in BACnet erheblich
erleichtert wird.
Die empfohlenen BACnet-Ausstattungen entsprechen der derzeitigen Marktsituation,
wobei Abstufungen bedarfsgerechte Anpassungen an Nutzerforderungen ermöglichen.
Zur hohen Qualität der Empfehlung haben auch Fachleute der BIG-EU beitragen dürfen. BIG-EU sichert dem AMEV bei der Umsetzung der Empfehlung die volle Unterstützung zu.
Der AMEV eröffnet mit der „BACnet 2007“ den Weg zur erfolgreichen Anwendung
von BACnet in öffentlichen Gebäuden. Die BIG-EU rechnet mit hoher Akzeptanz der
BACnet-Anwender.
Dipl.-Inform. Volker Röhl
Präsident der BIG-EU
Deutsche Telekom
Immobilien und Service GmbH
BACnet 2007
1
Geltungsbereich und Anwendungshinweise
Die nachfolgenden Hinweise gelten für die Planung, Ausführung und den Betrieb der Gebäudeautomation in öffentlichen Gebäuden unter Verwendung
des BACnet-Protokolls.
Grundsatzthemen, die unabhängig vom BACnet-Einsatz zu betrachten sind
(z. B. Wirtschaftlichkeit, Energieeinsparung, Systemintegration, GA-Konzepte,
Nutzerforderungen, Wettbewerb, Kostenplanung, Abnahme, Betriebsunterlagen, Betriebspersonal und Instandhaltung), sind nicht Gegenstand dieser
Empfehlung. Hierzu sind die entsprechenden Hinweise in der AMEV-Empfehlung „Gebäudeautomation 2005“ zu beachten.
Der Vollständigkeit halber enthält die „BACnet 2007“ einige Aussagen, die
nicht nur für BACnet-Systeme gelten (z. B. Reaktionszeiten, Umsetzungskonzepte). Diese in der „Gebäudeautomation 2005“ nicht enthaltenen Aspekte
sind auch bei anderen GA-Systemen sinngemäß zu beachten.
GA-Fachleute sollten bei der Durchsicht der vorliegenden Empfehlung die
darin enthaltenen logischen Blöcke beachten:
• Kapitel 2 und 3 • Kapitel 4
• Kapitel 5 bis 7 • Kapitel 8
• Anhang 1
• Anh. 2 und 3
• Anh. 4 und 5
• Anh. 6 bis 9 Einführung in BACnet (Einleitung, Grundlagen),
Realisierung von BACnet-Systemen
(Planung, Funktionalität),
BACnet-Komponenten
(Automationsstationen, Management- und
Bedieneinrichtungen, Netzwerke),
Umsetzungskonzepte
(Anschlussbedingungen, Migrationskonzepte),
Übersicht der BACnet-Objekttypen,
Beispiele
(Zuordnung von GA-Funktionen zu BACnet-Objekttypen),
Empfohlene BACnet-Funktionen
(Objekttypen, Properties, BIBBs),
Weitere Arbeitshilfen
(PICS-Muster, EDE-Liste, Glossar, Literatur).
TGA-Fachleute, die selbst keine GA-Systeme planen und nur Grundkenntnisse des BACnet-Protokolls benötigen, sollten sich auf folgende Bereiche
konzentrieren:
10
• Kapitel 2 und 3 • Kapitel 4
• Kapitel 8 • Anh. 2 und 3
Einführung in BACnet (Einleitung, Grundlagen),
Realisierung von BACnet-Systemen
(Planung, Funktionalität),
Umsetzungskonzepte
(Anschlussbedingungen, Migrationskonzepte),
Beispiele
(Zuordnung von GA-Funktionen zu BACnet-Objekttypen).
Zum leichteren Verständnis werden nachfolgend deutsche Fachbegriffe verwendet. Ausnahmen sind gängige Kurzbegriffe der Norm (z. B. BIBBs, PICS,
Properties). Bei der ersten Erwähnung des deutschen Fachbegriffes wird in
Klammern auch der Originalbegriff genannt. Tabellen enthalten wegen der
notwendigen Verständlichkeit und Eindeutigkeit sowohl deutsche Fachbegriffe
als auch die englischsprachigen genormten Begriffe.
Die BACnet-Norm und die Erfahrungen des AMEV mit BACnet unterliegen
einem laufenden Prozess. Die Erkenntnisse wachsen mit neuen Projekten und
werden im AMEV-Arbeitskreis Gebäudeautomation regelmäßig diskutiert. Aktuelle Ergänzungen zu dieser Empfehlung werden auf der AMEV-Webseite veröffentlicht (http://www.amev-online.de/bacnet_2007_mit.html).
Diese Empfehlung bietet nachfolgend auch Adressen zu fremden Webseiten
an. Der AMEV hat keinen Einfluss auf die Inhalte dieser Link-Adressen und
kann diese auch nicht verantworten.
Im Text oder in Abbildungen werden bestimmte Warenzeichen und Produkte
erwähnt, um Produkte eindeutig zu beschreiben. Das bedeutet keinesfalls,
dass es sich dabei um eine Empfehlung des AMEV handelt. Es bedeutet auch
nicht, dass es sich um die am besten geeigneten Produkte für eine bestimmte
Anwendung handelt.
Der AMEV erhebt auch keinen Anspruch auf die Namen von Dritten:
• BACnet® ist Schutzmarke der American Society of Heating, Refrigeration
and Air-Conditioning Engineers (ASHRAE).
• Das BTL-Logo (BACnet Testing Laboratory) ist Schutzmarke der BACnet International (BI), früher BACnet Manufacturers Association (BMA).
• Das KNX-Logo ist Schutzmarke der KNX Association.
• Echelon, Lon, LonWorks, LonTalk, LonUsers und Neuron sind Schutzmarken der Echelon Corporation.
BACnet 2007
11
2
Einleitung
Das Kapitel gibt einen Einblick in die Normung und Grundidee des BACnetProtokolls und erläutert den prinzipiellen Aufbau von BACnet-Systemen.
2.1
Normung
BACnet® (Building Automation and Control Network) ist eine internationale
und europäische Norm für die Datenkommunikation in der Gebäudeautomation. Als DIN EN ist sie gleichzeitig eine deutsche Norm, die Mitte 2007 folgenden Stand hat:
DIN EN ISO 16484-5: 2004-08 Systeme der Gebäudeautomation Teil 5: Datenkommunikationsprotokoll (ISO 16484-5: 2003);
Englische Fassung EN ISO 16484-5: 2003.
Die Norm basiert auf dem Standard ANSI/ASHRAE 135, der in Form von Ergänzungen (Addenda) ständig weiter entwickelt wird. Die aktuelle Fassung
des ANSI/ASHRAE-Standards ist zu erwerben unter
http://resourcecenter.ashrae.org/store/ashrae/newstore.cgi
Da die ISO- und DIN EN-Fassungen mit einiger Zeitverzögerung erscheinen,
können sich Unterschiede in den normativen Anforderungen an BACnet-Produkte ergeben. Dieser AMEV-Empfehlung liegen die Festlegungen der DIN
EN ISO 16484-5: 2004-08 zugrunde. Allein in Fällen mit absehbar hoher Anwendungs- und Marktrelevanz wurden Festlegungen übernommen, die zwar
bereits im aktuellen ASHRAE-Standard enthalten, jedoch noch nicht in die europäische Normung eingeflossen sind.
In gedruckter Fassung umfasst der ASHRAE-Standard von 2006 einschließlich
aller Addenda mehr als 700 Seiten. Hinzu kommen weitere ca. 450 Seiten für
die dazu gehörende Prüfnorm (DIN EN ISO 16484-6). Die Norm wurde – bis
auf den allgemeinen Teil – nicht in Nationalsprachen übersetzt.
In deutscher Sprache stellen die BACnet Interest Group Europe (BIG-EU)
und die VDI-Gesellschaft TGA (VDI-TGA) den „Leitfaden zur Ausschreibung
interoperabler Gebäudeautomation auf Basis von DIN EN ISO 16484-5 ...“
zur Verfügung. Er enthält Empfehlungen für die Planung, Ausschreibung und
Ausführung von interoperablen BACnet-Systemen. Eine ergänzende Ausarbeitung „Begriffe und Definitionen für den Leitfaden“ erläutert die im Leitfaden
verwendeten englischen Fachbegriffe.
12
Diese und andere Informationen stehen zum Download zur Verfügung auf folgenden Internet-Seiten:
www.bacnet.org
www.big-eu.org
www.bacnetinternational.org
(Offizielle BACnet Website mit Informationen über Stand der Normung)
(Website der BIG-EU mit Service /
Publikationen)
(Website der BACnet International)
Eine Auswahl weiterer, allgemeiner Arbeitshilfen für die Gebäudeautomation
(z. B. VDI 3814, GAEB StLB-Bau 070, DIN ATV 18386) benennt der Anhang
6 der AMEV-Empfehlung „Hinweise für Planung, Ausführung und Betrieb der
Gebäudeautomation in öffentlichen Gebäuden (Gebäudeautomation 2005)“.
2.2 Grundidee des BACnet-Protokolls
BACnet ist das erste von der ISO genormte Kommunikationsprotokoll für die
GA und soll – wie auch andere GA-Protokolle – die herstellerneutrale Kommunikation zwischen GA-Komponenten ermöglichen. Dazu wurden die benötigten Elemente der GA (z. B. Messeingang, Schaltausgang, Regler) bestimmt,
für die jeweils ein Satz von Informationen festgelegt wurde, der ihre Eigenschaften beschreibt. Damit wurde die Grundlage für eine einheitliche Sichtweise aller Beteiligten auf die GA geschaffen.
Darüber hinaus legt die Norm fest, mit welchen Verfahren (Diensten) die o. g.
Informationen der GA-Elemente gelesen und geschrieben werden, Alarm- und
Ereignismeldungen erzeugt, verteilt und verarbeitet werden oder Zeitschaltprogramme erstellt und bearbeitet werden.
Zur Beschreibung der Datenelemente und Verfahren bedient sich BACnet
des in der Informationstechnik bewährten objektorientierten Ansatzes. Dabei
wird jedes GA-Element als ein geschlossenes Objekt betrachtet, dessen Eigenschaften und Zustand durch einen Satz von zugeordneten Informationen
beschrieben werden. Die Abfrage seiner Eigenschaften oder Änderung des
Zustands des Objekts erfolgt durch die Anwendung des entsprechenden
Dienstes auf das Objekt.
Zusammen mit der Definition der für BACnet zugelassenen Übertragungsverfahren stehen alle notwendigen Bestandteile für eine herstellerneutrale Kommunikation zur Verfügung. Mit der herstellerneutralen Kommunikation und
einheitlichen Sichtweise aller Beteiligten auf die GA schafft das BACnet-Protokoll eine wesentliche Voraussetzung für transparente und kostensparende
Planungs- und Engineering-Verfahren in der Gebäudeautomation.
BACnet 2007
13
Eine praxisorientierte Evaluierung des BACnet-Protokolls, seiner Chancen und
Risiken enthält der Endbericht des Forschungsprojektes: „Standardisierung
von Busprotokollen für die Gebäudeautomation in öffentlichen Gebäuden“
des Bundesamtes für Bauwesen und Raumordnung (BBR) vom Juli 2007 (Aktenzeichen 10.08.17.7-06.23). Die Ergebnisse des Forschungsprojektes sind
in die vorliegende Empfehlung eingeflossen.
2.3 Aufbau von BACnet-Systemen
Ein BACnet-System ist ein Gebäudeautomationssystem, bei dem die Kommunikation zwischen den angeschlossenen Einrichtungen mit Hilfe des Datenprotokolls BACnet durchgeführt wird.
Der grundsätzliche Aufbau eines BACnet-Systems mit den Komponenten
Automationssystem(e), Netzwerk und Managementsystem wird in Abbildung 1
gezeigt.
Abbildung 1: Grundsätzlicher Aufbau eines BACnet-Systems
Das Managementsystem besteht in der Regel aus einer oder mehreren vernetzten Einheiten (Management- und Bedieneinrichtungen - MBE), über die
sowohl Bedienfunktionen als auch Managementfunktionen ausgeführt werden
können.
Auch die Automationssysteme können verschiedene, miteinander über BACnet vernetzte Stationen (Automationsstationen - AS) enthalten, die für unterschiedliche technische Anlagen zusammengefasst sein können. Unterhalb
der Automationssysteme können Subsysteme angeordnet sein (z. B. Raumautomation, Pumpensysteme), die ebenfalls über BACnet kommunizieren.
14
Die Systemgrenzen der Automationssysteme werden oft auch als Grenzen für
Ausschreibungen verwendet (z. B. bei unterschiedlichen Ausbaustufen) und
jeweils von einem Anbieter angeboten und aufgebaut. In diesen Fällen kann
die Kommunikation innerhalb dieser Automationssysteme (GA-Inseln) ebenso
wie die Kommunikation zwischen AS und Sensoren oder Subsystemen auch
mit vorhandenen herstellerspezifischen Lösungen umgesetzt sein.
BACnet 2007
15
3
Grundlagen
Nachfolgend werden die grundlegenden Begriffe und Strukturen von BACnet
erläutert.
3.1 BACnet®
BACnet ist ein objektorientiertes Datenprotokoll für alle Funktionsebenen der
Gebäudeautomation. Hauptelemente des Protokolls sind die Festlegungen
für Objekttypen (Object Types), Dienste (Services) und Netzwerke. BACnet
ermöglicht systemübergreifende Zusammenarbeit (Interoperabilität) von Geräten oder Systemen unterschiedlicher Hersteller, wenn die eingerichteten Funktionen aufeinander abgestimmt sind.
3.2 Objekte
Objekte (Objects) entstehen, wenn man die Eigenschaften von Funktionen
der Gebäudeautomation als Ganzes betrachtet. Zum Beispiel besteht die
Gesamtinformation über eine Eingabefunktion „Raumtemperatur“ nicht nur
aus dem aktuellen Zahlenwert der Raumtemperatur, sondern noch aus weiteren Informationen wie physikalische Einheit, Name und Beschreibung des
Messpunkts, Einbauort und Art des Messwertgebers oder Grenzwerten. Alle
diese Informationen zusammen bilden ein BACnet-Objekt vom Typ „Analogeingabe“, in dessen Objekteigenschaften (Properties) alle vorgenannten Informationen hinterlegt sind.
Bis Mitte 2007 waren 38 Standard-Objekttypen bekannt, von denen 23 in DIN
EN ISO 16484-5:2004 und 3 vom American National Standards Institut (ANSI)
genormt waren. Die anderen 12 Objekttypen waren zu diesem Zeitpunkt im
Revisionsprozess bei ASHRAE bzw. noch im Stadium eines Vorentwurfs.
Anhang 1 führt alle 38 Objekttypen in alphabetischer Sortierung auf und enthält zusätzlich die Abkürzungen nach Norm, deutsche Bezeichnungen und
kurze Erläuterungen.
Mit den BACnet-Objekttypen lassen sich alle physikalischen und kommunikativen Ein- und Ausgabefunktionen, viele Verarbeitungsfunktionen wie zeitabhängiges Schalten, PI-/PID-Regelung und Trendspeicherung/Historisierung
sowie Management- und Bedienfunktionen wie Grafik/Anlagenbild und dynamische Einblendung der GA-Funktionsliste nach DIN EN ISO 16484-3 bzw.
VDI 3814-1:05-2005 abbilden.
Anhang 2 enthält eine nach Anlagenteilen orientierte Tabelle mit Beispielen
gebräuchlicher GA-Funktionen und deren Umsetzung mit Hilfe von BACnetObjekttypen.
16
Anhang 3 enthält ein anlagenorientiertes Beispiel für die Auswahl von Standard-Objekttypen bei einer RLT-Anlage.
Die vorhandenen Objekttypen sind für eine leistungsfähige, interoperable Gebäudeautomation mehr als ausreichend. Die Norm erlaubt den Herstellern, zusätzlich eigene Objekttypen zu entwickeln. Ein Ersatz von Norm-Objekttypen
durch herstellerspezifische ist jedoch normwidrig.
3.3 Properties
Bei den Properties (Objekteigenschaften) handelt es sich um einen objektspezifisch festgelegten Datensatz, dessen Felder alle für die Funktionalität
des Objektes benötigten Informationen enthalten. Standard-Objekttypen haben Pflichteigenschaften (Mandatory Properties), die entweder nur lesbar „R“
(Readable) oder lesbar und schreibbar „W“ (Writeable) sind.
Beispiel:
Eine MBE kann die aktuelle Einstellung der lesbaren Eigenschaft „Physikalische Einheit“ (Units) in einem Analogeingabe-Objekt (Analog Input Object)
in der AS lesen (R), aber nicht ändern.
Wenn der Bediener an der MBE einen neuen Sollwert einstellt, muss die
MBE diesen Sollwert – z. B. die schreibbare Eigenschaft „Sollwert“ (Setpoint) des Reglerobjekts (Loop) in der AS – nicht nur lesen können (R),
sondern auch überschreiben dürfen (W).
Zusätzlich sind in der Norm optionale Properties „O“ (Optional) festgelegt,
deren Anwendung von der Aufgabenstellung (Funktion) der realen Anlage abhängt und die in vielen Fällen benötigt werden. Sie müssen normkonform und
interoperabel im System eingerichtet werden.
Die Norm erlaubt den Herstellern, eigene Properties zu definieren, ohne diese
offen zu legen. Geräte anderer Hersteller können diese Eigenschaften nicht
interpretieren. Dies führt in der Praxis zu erhöhtem Aufwand bei der Kopplung
von BACnet-Geräten unterschiedlicher Hersteller.
Anhang 4 fasst die für öffentliche Gebäude empfohlenen Objekttypen und Properties sowie ihre Lese- und Schreib-Rechte in einer Übersicht zusammen.
Die Norm-Bezeichnung der Properties wird geschrieben als Trennzeichentyp
ohne Leerzeichen z. B. das Property „Aktueller Wert“ (Present_Value).
BACnet 2007
17
3.4 Dienste
Dienste (Services) beschreiben die Verfahren, die den Teilnehmern in BACnetSystemen für die Kommunikation zur Verfügung stehen (z. B. zum Lesen und
Schreiben der Properties anderer BACnet-Objekte).
Zum Beispiel kennt BACnet mehrere Dienste zur Erzeugung von Meldungen:
• Meldungserzeugung bei analogen und binären Wertänderungen (COV
Reporting)
• Objektinterne Meldungserzeugung (Intrinsic Reporting)
• Regelbasierte Meldungserzeugung (Algorithmic Change Reporting)
COV Reporting dient dazu, bei einer Wertänderung (Change Of Value) im Feld
oder in der AS den neuen Wert automatisch an die vorher festgelegten Empfänger zu übertragen. COV umfasst auch sog. COS Reporting bei Zustandsänderungen (Change Of State). Nachfolgend werden COV und COS zusammengefasst als COV bezeichnet.
Bei analogen Objekten oder Reglerobjekten wird ein Schwellenwert für die
Wertänderung (z. B. Temperaturänderung um 0,3 K) als Eigenschaft festgelegt
(COV_Increment).
Bei binären Objekten wird die Änderung des Zustands von 0 auf 1 oder von 1
auf 0 gemeldet.
Objektinternes Melden (Intrinsic Reporting) unterstützt weitergehende Funktionen wie die Überwachung von unteren und oberen Grenzwerten (Low_Limit
und High_Limit) bei analogen Objekten. Die Meldung wird innerhalb des Objekts erzeugt.
Regelbasiertes Melden (Algorithmic Change Reporting) kann eingesetzt werden zur Erzeugung von Meldungen nach einem vorzugebenden Algorithmus
aus den Properties eines oder mehrerer Objekte. Die Meldungserzeugung erfolgt in einem eigenen Objekt vom Typ Ereigniskategorie (Event Enrollment).
Die früher gebräuchliche Methode der zyklischen Abfrage (Polling) durch die
MBE erhöht die Netzbelastung, verlängert die Reaktionszeiten und ist nach
Möglichkeit zu vermeiden. Bei Systemstarts oder nach Kommunikationsunterbrechungen wird diese Methode jedoch weiter benötigt.
18
Dienste können nur auf die Objekttypen und Properties angewendet werden,
die eingerichtet sind. Zum Beispiel wird COV Reporting nur ausgeführt, wenn
der Dienst für COV-Meldungen in AS eingerichtet und von MBE abonniert ist
und in den zugehörigen analogen Objekten jeweils das Property „COV-Änderungsschwellenwert“ (COV_Increment) eingerichtet wurde.
Das BACnet-Protokoll verfügte Mitte 2007 über 42 Dienste, die fünf Kategorien
zugeordnet werden:
• Dienste für den Zugriff auf Objekte • Dienste für den Zugriff auf Geräte
und das Netzwerk • Dienste für die Verarbeitung von
Alarmen und Ereignissen
• Dienste für den Zugriff auf Dateien
• Dienste für Konfiguration und
Diagnose von Geräten
(Object Access Services)
(Device and Network Management
Services)
(Alarm and Event Services)
(File Access Services)
(Virtual Terminal Services)
Um die technische Weiterentwicklung zu fördern, erlaubt die Norm zusätzlich
die Entwicklung proprietärer Dienste auf Basis normativer „PrivateTransfer“Dienste. Eine Anwendung von nicht genormten anstatt der genormten Dienste
ist jedoch nicht zulässig.
3.5 Client-Server-Prinzip
Der Datenaustausch mittels der BACnet-Dienste erfolgt nach dem Client-Server-Prinzip. Der Client fordert einen Dienst beim Server an. Der Server antwortet auf diese Anforderung, indem er den Dienst bereitstellt bzw. die gewünschte Aktion durchführt. Die Kommunikation kann auch durch ein Ereignis
im Server ausgelöst werden. Ein Beispiel dafür ist der Dienst Event-Notification, der den Server veranlasst, z. B. nach einer Grenzwertverletzung eine Meldung an einen oder mehrere Clients abzusetzen.
Ein typischer BACnet-Client ist eine MBE. Als BACnet-Server handelt im Allgemeinen eine AS, wenn sie die Informationen bereitstellt, die eine MBE angefordert hat.
BACnet-Teilnehmer können auch Client und Server gleichzeitig sein. Zum
Beispiel können AS sowohl über Daten anfordernde als auch bereitstellende
Dienste verfügen.
Die Rollenverteilung der Teilnehmer an der BACnet-Kommunikation wird bei
der Planung und Ausführung des BACnet-Systems festgelegt.
BACnet 2007
19
3.6
Interoperabilitätsbereiche
Interoperabilitätsbereiche (IOB = Interoperability Area - IA) beschreiben die
betriebswichtigen Funktionsbereiche von BACnet-Systemen. Die BACnetNorm benennt fünf Interoperabilitätsbereiche:
• Gemeinsame Datennutzung (Data sharing - DS)
• Alarm- und Ereignisverarbeitung (Alarm and event management - AE)
• Zeitplan (Schedule - SCHED)
• Trendaufzeichnung (Trending - T)
• Device- und Netzwerkmanagement (Device and network management - DM)
Jedem IOB sind die zur Funktionserfüllung im jeweiligen Aufgabenbereich benötigten BACnet-Dienste (BIBBs) zugeordnet.
3.7
BIBBs
Die BIBBs (BACnet Interoperability Building Blocks = Interoperabilitätsbausteine) beschreiben die funktionalen Voraussetzungen, die BACnet-Geräte für
eine interoperable Kommunikation erfüllen müssen. Korrespondierende BIBBs
von Clients und Servern sind eine der notwendigen Voraussetzungen für die
Interoperabilität dieser Geräte.
Die Norm nennt für jeden BIBB die damit verbundene Funktionalität wie „Das
Gerät verarbeitet Nachrichten über Alarme und andere Ereignisse“ und die
Dienste, die der BIBB für diese Funktionalität benötigt.
Außerdem gibt die Norm an, ob ein BIBB den Dienst anfordert (initiate) oder
ausführen (execute) können muss. Durch eine Kennung (Buchstabe A oder
B) wird unterschieden zwischen den BIBBs für Geräte, die als Anforderer von
Daten oder Diensten (Client oder „A-Device“) und solchen, die als Bereitsteller
von Daten oder Diensten (Server oder „B-Device“) arbeiten.
Zusätzlich ist bei einigen BIBBs vorgeschrieben, dass bestimmte Objekte bzw.
Eigenschaften unterstützt werden müssen. Darüber hinaus können die Wertebereiche von Properties oder Service-Parametern eingeschränkt sein.
Die Bezeichnung von BIBBs setzt sich aus der Kurzbezeichnung des Interoperabilitätsbereiches, einer Kurzbezeichnung der Funktion und dem Kennbuchstaben A oder B entsprechend der Rolle im Datenaustausch zusammen.
20
Beispiel:
Ein Gerät, das laut Herstellerangabe den BIBB „DS-RP-B“ enthält, ist ein
B-Device und muss als solches Daten für ein anderes Gerät (A-Device)
bereit stellen können. Dafür muss der BACnet-Dienst „ReadProperty“ (RP)
vorhanden sein und ausgeführt werden können. DS steht für den Interoperabilitätsbereich „Data Sharing“ (siehe Abschnitt 3.7).
In Annex K der DIN EN ISO 16484-5: 2004-08 sind 67 BIBBs beschrieben.
Anhang 5 enthält eine Übersicht aller derzeit genormten BIBBs mit einer Kurzbeschreibung der jeweiligen Funktion und Empfehlungen für den Einsatz von
BIBBs in öffentlichen Gebäuden.
3.8 Standard-Geräteprofile
Annex L der Norm beschreibt sechs standardisierte Typen (Profile) von BACnet-Geräten (Standardized BACnet Devices).
Jedes Profil legt die BIBBs fest, die Geräte mindestens beherrschen müssen,
wenn sie als standardisierte BACnet-Geräte gelten sollen. Die Norm unterscheidet sechs Standard-Geräteprofile:
• Managementstation, Bedienstation • Programmierbare Automationsstation • Automationsgerät mit geringerem
Leistungsumfang als BC1 • Automationsgerät mit geringerem
Leistungsumfang als AAC2 • Schalt- oder Stellgerät • Geber (OWS - Operator Workstation)
(BC - Building Controller)
(AAC - Advanced Application
Controller)
(ASC - Application Specific
Controller)
(SA - Smart Actuator)
(SS - Smart Sensor)
In der Praxis hat sich die Vorgabe von Standard-Geräteprofilen nicht bewährt,
da die marktüblichen Geräteausführungen nicht 1:1 mit den Norm-Profilen
übereinstimmen. Hersteller dürfen ihre BACnet-Geräte zum Beispiel auch mit
eigenen Funktionen ausstatten, müssen diese jedoch in dem jeweiligen PICS
angeben. Daher ist grundsätzlich an Hand von PICS zu überprüfen, ob die
gewünschten BIBBs tatsächlich enthalten sind.
Das von der BIG-EU im Leitfaden vorgeschlagenen Profil eines Gateways
(GW) wird nicht in der Norm spezifiziert, sondern stellt nur eine Empfehlung
zur Anbindung von Altsystemen dar.
1 z. B. ein Gerät mit mehreren unveränderbaren Programmen, die zur Auswahl stehen.
2 z. B. ein Gerät mit einem unveränderbaren Programm, z. B. Einzelraumregler.
BACnet 2007
21
Anhang 5 gibt u. a. an, welche BIBBs den Geräteprofilen B-BC (BACnet-BC)
und B-OWS (BACnet-OWS) zugeordnet sind.
3.9 PICS
Ein PICS (Protocol Implementation Conformance Statement = Konformitätserklärung) ist die Erklärung des Herstellers nach Annex A der Norm zur Konformität seines BACnet-Gerätes.
Nach Norm muss ein PICS Angaben zu folgenden Themen enthalten:
• Produktbeschreibung
• Standard-Geräteprofil
• Unterstützte BIBBs
• Unterstützte Segmentierung
• Unterstützte Standard-Objekttypen • Netzwerkoptionen • Einbindung der Geräteadresse • Routeroptionen • Unterstützte Zeichensätze • Weitere Angaben, falls es sich
um ein Gateway handelt
(Product Description)
(Standardized Device Profile)
(BACnet Interoperability Building
Blocks supported)
(Segmentation Capability)
(Standard Object Types Supported)
(Data Link Layer Options)
(Device Address Binding)
(Networking Options)
(Character Sets Supported)
Für die unterstützten Objekttypen ist zusätzlich folgendes anzugeben:
• Angabe, ob das Objekt dynamisch erzeugt/gelöscht werden kann,
• Liste aller unterstützten optionalen Properties,
• Liste aller beschreibbaren Properties, sofern nicht ohnehin von der Norm
gefordert,
• Liste aller proprietären Properties jeweils mit Identifier, Datentyp und Bedeutung,
• Liste evtl. existierender proprietärer Bereichsbeschränkungen.
Anhang 6 enthält ein PICS-Muster, das zusätzlich zu den Normbegriffen auch
deutsche Begriffe enthält.
22
3.10 Konformitätstests
Hersteller von BACnet-Produkten weisen mit Konformitätstests nach, dass ihre
Geräte mit der Norm DIN EN ISO 16484-5 übereinstimmen. Die Geräte werden
durch ein BACnet Test Labor (BTL) nach der jeweils aktuellen Norm getestet:
DIN EN ISO 16484-6 „Systeme der Gebäudeautomation Teil 6: Datenübertragungsprotokoll - Konformitätsprüfung“
Bei positivem Prüfergebnis darf das Produkt mit dem BACnet-Prüfzeichen
(BTL-Logo) gekennzeichnet werden. Das Testlabor stellt die tatsächlich geprüften BIBBs, Objekttypen und anderen Leistungsmerkmale des Gerätes in
einer Bescheinigung („Product Listing“) zusammen.
Eine automatische Testsoftware löst die manuellen Tests ab und ermöglicht
auch vollständigere und komplexere Tests, auf die bisher aus Kostengründen
in der Regel verzichtet wurde.
Die unterschiedlichen Begriffe und Bedeutungen der Listen und Prüfungen
von Produkten sind in der nachfolgenden Übersicht zusammengestellt:
Begriff
Erläuterung
Marktverfügbarkeit
Liste von Produkten,
Produktkatalog
Aufzählung von Produkten,
ohne Hinweis auf Listung oder
Zertifizierung
Alle Produkte von BACnetHerstellern im Besitz einer
Vendor-ID
Gelistetes Produkt
(Listing),
Liste getesteter Produkte
Erfolgreich (vorläufig oder
abschließend) von einem
Testlabor geprüftes Produkt,
berechtigt zum Führen des
BTL Logo
Nicht alle, aber sehr viele
BACnet Produkte.
Zertifiziertes Produkt
Erfolgreich durch eine nationale Akkreditierungsstelle
nach EN ISO/IEC 17025
(General Requirements for the
Competence of Calibration
and Testing Laboratories)
geprüftes Produkt.Voraussetzung ist ein vorheriges Listing
(BTL Logo).
Bis Mitte 2007 noch keine
BACnet Produkte
BACnet 2007
23
Eine nach Herstellern geordnete Produktliste der nach den bisherigen Prüfmethoden geprüften BACnet-Geräte befindet sich auf der Website der BIG-EU
(siehe http://www.big-eu.org/conformance/listeu.php). Eine entsprechende
Liste des BACnet Testing Laboratory (BTL) USA befindet sich auf der Website
der BI/BTL (siehe http://www.bacnetinternational.org/btl/). Das Product Listing und ein technisches Datenblatt stehen auf beiden Webseiten für jedes
Gerät zum Download zur Verfügung.
Das Ergebnis von Konformitätstests hat nur begrenzte Aussagekraft für die
Interoperabilität von BACnet-Geräten, denn es bescheinigt den Geräten lediglich die grundsätzliche Befähigung zu den getesteten BACnet-Funktionen.
Um die verfügbaren Funktionen für den praktischen Einsatz zu aktivieren, ist
bei jedem BACnet-Projekt zunächst die Umsetzung der geforderten GA-Funktionen in BACnet-Objekte und Dienste zwischen Planer und Nutzer abzustimmen als gemeinsamer „Wortschatz“ für die BACnet-Kommunikation. Auf dieser Grundlage muss jeder Lieferant in seinen BACnet-Geräten die benötigten
Objekte, Properties und Dienste einrichten.
3.11 EDE-Listen
EDE-Listen (Engineering Data Exchange) werden benötigt, um den Austausch
von projektspezifischen BACnet-Informationen zwischen den Projektpartnern
in standardisierter Form zu dokumentieren. EDE-Listen sind nicht normativ
festgelegt, sondern eine Empfehlung der BIG-EU aus dem Jahre 2004. Sie
bestehen aus einer Tabellenkalkulation mit der EDE-Liste als Übersicht und
ergänzenden Tabellen für standardisierte Eingaben.
In einer EDE-Liste müssen alle Ein- und Ausgabeobjekte mit ihren in der Liste
vorgegebenen Properties vollständig dokumentiert werden, d. h. Einheit, Beschreibungstext, Grenzwerte usw. müssen sinnvoll eingetragen sein.
Alle BACnet-Objekte in EDE-Listen müssen auch in den Automationsschemata
eingetragen sein, damit bei den zugehörigen Grafikbildern in der Bedienoberfläche der Zusammenhang zwischen BACnet-Objekten und GA-Funktionen
erkennbar wird.
Anhang 7 erläutert die EDE-Listen an Hand eines Musters und empfiehlt
standardisierte Angaben für Zustandstexte, physikalische Einheiten und Meldungsklassen.
24
4
Realisierung von BACnet-Systemen
Hier werden die übergeordneten Anforderungen an die Teilnehmer in BACnetSystemen beschrieben.
4.1 Planung und Ausführung
Es ist Aufgabe der GA-Planung, aus den zu erfüllenden Anforderungen und
dem ermittelten Bedarf geeignete Konzepte zu erarbeiten und Lösungen vorzuschlagen (siehe Gebäudeautomation 2005).
Die Planung von BACnet-Systemen soll sich an folgende grundsätzliche Regeln halten:
• Die im Projekt notwendigen GA-Funktionen werden sowohl qualitativ als
auch quantitativ beschrieben.
• Es wird festgelegt, welche GA-Funktionen in AS und welche in MBE ausgeführt werden.
• Die GA-Funktionen werden mit den im BACnet-Standard dafür vorgesehenen Objekten, Properties und Diensten realisiert. Die Verwendung von
Hilfskonstrukten mit zusätzlichen Objekten, Properties und Diensten ist nicht
zulässig.
• Erweiterungen müssen kompatibel zum vorgegebenen herstellerneutralen
BACnet-Konzept sein.
BACnet-Systeme werden in der Regel als modulare EDV-Systeme mit einer
Client-Server-Architektur unter Verwendung von standardisierten Betriebssystemen, Netzwerken und Protokollen aufgebaut. Die Systeme müssen im
gesamten Netzwerk verteilte Funktionen zulassen (z. B. Überwachung und
Steuerung der TGA, grafische Bedienung, Parametrierung, Datensicherung,
Datenwiederherstellung und Programmierung), um auch zukünftigen Anforderungen an Flexibilität und Leistung gerecht zu werden. Erweiterungen müssen
möglich sein. Hardware und Software sind so zu wählen, dass die geforderten
Reaktionszeiten eingehalten werden (siehe Abschnitt 4.4).
Aus der Anwendung des BACnet-Protokolls selbst ergeben sich keine speziellen Anforderungen an die Leistungsmerkmale oder spezifischen Eigenschaften eines GA-Systems und dessen Hardware (z. B. Prozessoren und
Speicherchips) und Software (z. B. Betriebssystem). Vielmehr müssen sich
Ausstattung und Leistungsfähigkeit nach dem erwarteten Daten- und Funktionsumfang, den Anforderungen an Datensicherheit und Speicherkapazität
sowie den örtlich benötigten Schnittstellen richten.
BACnet 2007
25
Die notwendige Leistungsfähigkeit der BACnet-Systeme in Bezug auf die
Verarbeitung von BACnet-Objekten ergibt sich aus der Gesamtheit der GAFunktionslisten im Projekt und den daraus abgeleiteten Aufgabenstellungen
für MBE, AS und Netzwerkkomponenten. Es ist zu klären, ob und für welche
GA-Funktionen die AS im BACnet-System Peer-to-Peer-Kommunikation ausführen sollen.
Bei der Planung sind u. a. die benötigten Objekttypen, Properties und BIBBs
für die jeweiligen Teilanlagen festzulegen (siehe Abschnitt 4.2 und 4.3).
Sollen Anlagenkomponenten und Überwachungsfunktionen über FeldbusSysteme (z. B. LON, KNX) in BACnet eingebunden werden, müssen auch
die BACnet-Objekte und Properties für diesen Informationsaustausch und
zur Überwachung des Subsystems (z. B. Zeitüberwachung durch WatchdogFunktion) bestimmt werden.
Alle BACnet-Geräte und -Objekte erhalten Benutzeradressen nach einer vom
Betreiber vorzugebenden einheitlichen Systematik.
Für BACnet-Geräte wird der Zeichensatz nach ISO 8859-1 empfohlen (siehe
Anhang 8: Zeichensatz). Innerhalb eines BACnet-Systems ist zur Sicherstellung der Interoperabilität ein einheitlicher Zeichensatz zu verwenden.
In BACnet-Ausschreibungen sind die technischen Beschreibungen, die PICS
und die Nachweise der Konformität zum BACnet-Standard für alle angebotenen BACnet-Systemkomponenten zu verlangen. Die Konformitätsnachweise
(Product Listings und Zertifikate) sind durch Konformitätstests gemäß der Prüfnorm DIN EN ISO 16484-6 bei dafür anerkannten Testinstituten (z. B. WSPLab,
Stuttgart) zu erbringen.
Neu zu errichtende BACnet-AS müssen direkt – ohne zusätzliche Hardware
und Software (Gateways) oder Dienstleistungen – in das BACnet-System einfügbar sein.
BACnet-MBE müssen neue AS mit den vorgegebenen Funktionalitäten aufschalten können. Bei bestehenden AS kann die verfügbare Funktionalität eingeschränkt sein.
BACnet-MBE müssen alle Objekte und Geräte in einem BACnet-Netz(abschnitt)
überwachen können, d. h. die MBE muss den aktuellen Zustand aller Eigenschaften lesen können.
26
Auftragnehmer in BACnet-Projekten müssen ihre Fachkunde, Leistungsfähigkeit und Zuverlässigkeit durch Referenzen von vergleichbaren BACnet-Projekten nachweisen.
Bei der erstmaligen Kopplung von BACnet-Geräten unterschiedlicher Hersteller wird empfohlen, vor der Auftragserteilung eine Testinstallation mit den geforderten Funktionen durchführen zu lassen (siehe Gebäudeautomation 2005
Seite 63).
Bei der Ausführung von BACnet-Projekten müssen die geforderten Objekte,
Properties, Dienste bzw. BIBBs von allen Teilnehmern eingerichtet werden, um
Interoperabilität in dem BACnet-GA-System sicherzustellen.
Zur dezentralen Aufgabenerledigung entsprechend der BACnet-Systemphilosophie sind die GA-Funktionen vorrangig in den AS einzurichten und dort
autark auszuführen (aktives front end processing).
Wichtige Elemente der projektspezifischen Dokumentationen und Nachweise
für die geplante BACnet-Kommunikation sind die EDE-Tabellen nach Anhang 7.
Sie sind von jedem Auftragnehmer für sein System zu erstellen. Zur Kontrolle
müssen die Inhalte der EDE-Datei aus den BACnet-Komponenten ausgelesen
werden können.
Die EDE-Tabellen sind auf der Basis der Planungsvorgaben von den Auftragnehmern für die Automationsebene im Rahmen der Montageplanung zu erstellen. Alle Objekte, auch die proprietären Objekte von Herstellern, sind anzugeben. Die EDE-Dateien sind von den Auftragnehmern vollständig zu erstellen
und entsprechend dem Projektverlauf zu aktualisieren. Eine Aktualisierung (mit
neuer Versions-Kennzeichnung) muss allen Beteiligten mitgeteilt werden, um
betriebsrelevante oder kostenintensive Störungen im Vorfeld zu vermeiden.
Falls erforderlich, sind vor dem Zusammenschalten der unterschiedlichen
Systeme die EDE-Dateien von den Auftragnehmern untereinander abzustimmen. Alle EDE-Dateien sind wie Montage- und Werkstattunterlagen auf Vollständigkeit (einschließlich aller optionalen Spalten) und auf Plausibilität (z. B.
identische Interpretationen der notwendigen Objekt-Properties) zu prüfen.
Wenn AS und MBE ordnungsgemäß eingerichtet sind, beginnen sie unverzüglich nach dem Zusammenschalten mit der Datenkommunikation. Art und
Umfang des Datenverkehrs sind bei der Inbetriebnahme zu kontrollieren und
zu dokumentieren (z. B. mittels Protokoll-Analysator).
BACnet 2007
27
Für die Inbetriebnahme-Prüfungen, zum Nachweis der BACnet-Funktionalität
und für die Störungserkennung im laufenden Betrieb müssen geeignete Werkzeuge wie BACnet-Tools oder Protokoll-Analysatoren zur Verfügung stehen.
Diese Werkzeuge müssen alle im Projekt eingesetzten BACnet-Objekte und
BACnet-Dienste unterstützen und die Bedingungen in den genutzten Netzwerken (z. B. geswitchte IP-Netze) berücksichtigen.
Die Werkzeuge müssen Echtzeiterfassung aller Datenpakete und detaillierte
Analysen der Netzwerkaktivitäten ermöglichen, um der Forderung nach Nachweisbarkeit bei Haftungsfragen Rechnung zu tragen. Eine qualifizierte Bedienung ist sicherzustellen, um Netzwerkprobleme im Betrieb zu vermeiden und
schnelle Fehleranalysen z. B. bei Fehlfunktionen zu gewährleisten.
Bei der Abnahme erhält der Betreiber eine zeitlich und inhaltlich unbegrenzte
Lizenz für die Nutzung aller zur Systemerstellung eingesetzten und benötigten
Werkzeuge und Softwarekomponenten mit zugehöriger Dokumentation. Die
Dokumentationen und kommentierten Quellen der Anwendungsprogramme
sind in deutscher Sprache vollständig und aktuell auf Datenträger zu übergeben. Bei Fertigstellung sind dem Betreiber alle Systempasswörter für AS und
MBE – auch auf Systemadministratorebene – zu übergeben.
Durch Schulungen bis zum Level „Administrator“ sind Betreiber in die Lage
zu versetzen, übliche Änderungen oder Erweiterungen von Anwendungsprogrammen, Grafiken, Zeitplänen, Reglerparametern, Objekten, Trends, Alarmierungen sowie Hardware-Erweiterungen etc. vorzunehmen und diese in BACnet transparent zu machen.
Ergänzend sind die Hinweise der „Gebäudeautomation 2005“ für Planung,
Ausführung, Dokumentation und Betrieb zu beachten.
4.2
Empfohlene BACnet-Funktionen
Die Entscheidung für das BACnet-Protokoll und die Beschaffung von BACnetfähigen Komponenten allein reicht für eine umfassende und störungsfreie Gebäudeautomation und deren Datenkommunikation nicht aus. Die Aussage, die
Komponenten seien zueinander kompatibel, lässt auch keine Rückschlüsse
auf eine funktionierende Interoperabilität zwischen den Komponenten zu.
Die Interoperabilität der Komponenten in BACnet-Systemen muss im Planungs- und Ausführungsprozess sichergestellt werden.
28
Die Vielzahl möglicher BACnet-Objekttypen und Properties erlaubt es, die Kommunikationsaufgaben in der Gebäudeautomation auf vielfältige Weise zu lösen,
führt aber auch zu einer Fülle von Varianten mit eingeschränkter Interoperabilität und zu erhöhtem Planungs-, Koordinierungs- und Administrationsaufwand.
Je mehr Spezialfunktionen realisiert werden, desto schwieriger werden der
BACnet-Betrieb und die späteren Erweiterungen.
Die BACnet-Planung ist daher auf die tatsächlich benötigten Objekttypen, Properties und BIBBs zu beschränken. Nicht benötigte Leistungsmerkmale sollen
nicht aktiviert werden, um mögliche Fehlerquellen und unnötigen Aufwand zu
vermeiden. Bei Updates von BACnet-Geräten ist eine Abwärtskompatibilität
bezüglich der bestehenden Leistungsmerkmale zu fordern.
Die nachstehenden Empfehlungen geben Hinweise zur Auswahl der für öffentliche Gebäude empfohlenen Objekttypen, Properties und BIBBs im Sinne von
Mindeststandards.
Tabelle 1 listet die derzeit für öffentliche Gebäude empfohlenen StandardObjekttypen auf. Für jeden Objekttyp wird eine deutsche Bezeichnung vorgeschlagen und der „BACnet Object Type Code“ genannt. Außerdem werden die
Objekttypen entsprechend ihrer Funktionalität und praktischen Bedeutung in
öffentlichen Gebäuden den Gruppen A und B zugeordnet.
Die Objekttypen der Gruppe A sollen in jedem BACnet-System in öffentlichen
Gebäuden im Sinne einer Grundausstattung verfügbar sein. Dazu gehören der
Objekttyp Gerät (Device), alle analogen, binären und mehrstufigen Eingabe-,
Ausgabe- und Wertobjekttypen (E/A-Objekttypen) und mehrere komplexe Objekttypen.
Die Gruppe B umfasst weitere komplexe Objekttypen, die für die örtliche
Betriebsführung wichtig, als ergänzende Ausstattung sinnvoll (z. B. Regler
(Loop), Datei (File) in Verbindung mit den Diensten Backup/Restore) oder zur
Realisierung von besonderen Anwendungen gewünscht sein können.
BACnet 2007
29
BACnet Objekttyp
(deutsch)
BACnet Object Type
(Norm)
1
2
Objekttyp
Abk.
Code Gruppe
Hinweise
3
4
5
DEV
AI
AO
AV
BI
BO
BV
MI
MO
MV
NC
8
0
1
2
3
4
5
13
14
19
15
A
A
A
A
A
A
A
A
A
A
A
Pflicht-Objekt
Schedule
SCHED
17
A
siehe Abschnitt 5.7
Kalender
Calendar
CAL
6
A
siehe Abschnitt 5.7
Datei
File
FIL
10
B
siehe Abschnitt 5.1
Ereigniskategorie
Event Enrollment
EE
9
B
siehe Abschnitt 5.3
Trendaufzeichnung
Trend Log
TLOG
20
B
siehe Abschnitt 5.9
Regler
Loop
LP
12
B
siehe Abschnitt
5.10
Gerät
Analogeingabe
Analogausgabe
Analogwert
Binäreingabe
Binärausgabe
Binärwert
Mehrstufige Eingabe
Mehrstufige Ausgabe
Mehrstufiger Wert
Meldungsklasse
Device
Analog Input
Analog Output
Analog Value
Binary Input
Binary Output
Binary Value
Multi-state Input
Multi-state Output
Multi-state Value
Notification Class
Zeitplan
6
siehe Abschnitt 5.5
siehe Abschnitt 5.4
Tabelle 1: Übersicht der empfohlenen BACnet-Objekttypen
Anhang 4 enthält die empfohlenen BACnet-Objekttypen der Gruppen A und
B und die dafür empfohlenen Properties mit Leserechten (R) und Schreibrechten (W) der BACnet-Clients. Auch die Properties werden entsprechend
ihrer Funktionalität und praktischen Bedeutung in öffentlichen Gebäuden den
Gruppen A und B zugeordnet.
Die Properties der Gruppe A sollen in jedem BACnet-System in öffentlichen
Gebäuden im Sinne einer Grundausstattung verfügbar sein. Dazu gehören
alle Pflicht-Properties nach der BACnet-Norm und eine Auswahl optionaler
Properties, die für empfohlene Funktionen benötigt werden (z. B. für Intrinsic
Reporting).
Properties der Gruppe B können für die örtliche Betriebsführung wichtig, als
ergänzende Ausstattung sinnvoll oder zur Realisierung von speziellen Anwendungen gewünscht sein.
30
Anhang 5 stellt alle derzeit genormten BIBBs in einer Tabelle zusammen,
die nach der BACnet-Norm sortiert ist und für jedes BIBB eine deutsche Bezeichnung und eine kurze Funktionsbeschreibung enhält. Dabei werden die
Kennbuchstaben „A“ und „B“ entsprechend der BACnet-Norm im Sinne von
„Client“ und „Server“ verwendet.
Anhang 5 empfieht außerdem BIBBs für den Einsatz in MBE und AS und benutzt dafür die Spalten 5 und 7 (Basis = Grundausstattung der Gruppe A)
sowie 6 und 9 (Erweiterung = Erweiterte Ausstattung der Gruppe B). Die
empfohlenen BIBBs entsprechen den in Europa marktüblichen Geräteausführungen und weichen in einigen Details von den Norm-Profilen ab.
Grundausstattungen mit Objekttypen, Properties und BIBBs der Gruppe A
schaffen die kommunikativen Grundlagen für folgende wichtige GA-Funktionen:
• Automatisierte Einbindung von BACnet-Geräten (Dynamic Device Binding),
• Meldung von Ereignis- und Alarminformationen an unterschiedliche Emfänger,
• Mitteilung aktueller Anlageninformationen an MBE und andere Clients,
• Manuelle Bedienung von Gesamtanlagen und Anlagenkomponenten von
der MBE,
• Erstellung und Änderung von Alarmgrenzen, Sollwerten und anderen Parametern,
• Erstellung und Änderung aller Zeitschaltfunktionen von der MBE,
• Trenddaten und historische Daten in MBE erfassen (z. B. zur Visualisierung,
Archivierung),
• Funktionsüberwachung aller angeschlossenen BACnet-Geräte,
• Automatisierte Zeitsynchronisation (Time Synchronisation).
Durch erweiterte Ausstattungen mit Objekttypen, Properties und BIBBs der
Gruppe B werden je nach Bedarf folgende zusätzliche GA-Funktionen ermöglicht:
•
•
•
•
Anwendungsprogramme sichern und erneut laden
(Backup/Restore mittels File Object),
Meldung komplexer Ereignis- und Alarminformationen
(Algorithmic Change Reporting),
Trenddaten in der AS erfassen und gebündelt an MBE übertragen
(Trend Log Object),
Änderung von Sollwerten und Parametern der Reglerobjekte
(Loop Object).
BACnet 2007
31
Objekttypen, Properties und BIBBs der Gruppen B werden Mitte 2007 erst
von wenigen Herstellern angeboten. Während einer Übergangsphase muss
mit eingeschränkten Produkteigenschaften, Wettbewerbsangeboten und Praxiserfahrungen von Projektbeteiligten gerechnet werden.
Alle übrigen Objekttypen, Properties und BIBBs verfügen derzeit nicht über
eine ausreichende Marktpräsenz und Anwendungsrelevanz. Bei entsprechender Anwendungsrelevanz und Marktdurchdringung beabsichtigt der
AMEV, eine Neubewertung vorzunehmen.
Weitere Objekttypen, Properties und BIBBs können im Einzelfall sinnvoll sein,
erhöhen aber den Aufwand für Beschaffung, Ingenieurleistungen, Bedienung
und Administration und können die Zahl möglicher Wettbewerbsteilnehmer
gravierend einschränken. Diesen Nachteilen müssen entsprechende Vorteile
gegenüber stehen (z. B. Vereinfachungen bei der Projektrealisierung).
Stets ist darauf zu achten, dass keine Abhängigkeit von einzelnen Herstellern,
Lieferanten oder Dienstleistern entsteht (z. B. infolge Vorgabe spezieller Funktionen, Erwerb unzureichender Lizenzen oder Übernahme unvollständiger Dokumentationen).
Fremdleistungen für GA-Systeme, die im Betrieb wiederholt benötigt werden
(z. B. Aufschaltung neuer AS auf MBE, Updates von MBE und AS), sind bei
der Errichtung mit auszuschreiben (ggfs. mit Gleitklausel für die Personal- und
Materialkostenanteile).
In BACnet-Ausschreibungen muss der vorgesehene Informationsaustausch
vollständig benannt werden. Art und Umfang der Datenkommunikation sind
herstellerneutral an Hand der geforderten BACnet-Objekttypen, Properties
und Dienste zu beschreiben. Soweit verfügbar soll das GAEB StLBau 070 zu
Grunde gelegt werden, das derzeit an die BACnet-Anforderungen angepasst
wird.
Im Leistungsverzeichnis ist zu fordern, dass für alle angebotenen BACnetProdukte PICS abzugeben und herstellerspezifische Objekttypen, Properties,
Dienste etc. darin transparent zu machen sind.
Bei der Angebotsprüfung sind die PICS auf Verfügbarkeit der geforderten
BACnet-Objekttypen, Properties, BIBBs und anderen Merkmale zu prüfen.
32
4.3
Zuordnung von GA-Funktionen zu BACnet-Objekttypen
Die Zuordnung von GA-Funktionen zu BACnet-Objekttypen erfolgt prinzipbedingt nicht 1:1.
Die GA-Funktionen nach DIN EN ISO 16484-3 bzw. VDI 3814 beschreiben die
Automationsaufgaben. Diese umfassen sowohl die Ein-/Ausgabe- und Verarbeitungsfunktionen in den örtlichen AS als auch die Management- und Bedienfunktionen in den zugeordneten MBE und verwenden dabei physikalische und
virtuelle (abgeleitete) Informationen.
Die BACnet-Objekte nach DIN EN ISO 16484-5 dagegen ermöglichen den
Transport der Informationsinhalte zwischen MBE, AS und anderen BACnetGeräten.
Bei der Ausführung sind die Objekte, Properties und Dienste entsprechend
dem in den GA-Funktionslisten beschriebenen Funktionsumfang einzurichten.
Vorrangig sind die leistungsfähigeren Objekttypen, Properties und BIBBs in
Anhang 4 und 5 zu verwenden. Zum Beispiel muss die Änderung der Zeitschaltprogramme in den AS durch die MBE mit Hilfe der Objekttypen Zeitplan
(Schedule) oder Kalender (Calendar) erfolgen und nicht über eine Ansammlung von einfachen Objekttypen.
Das Prinzip der Zuordnung von GA-Funktionen zu BACnet-Objekttypen verdeutlicht Tabelle 2. Sie enthält Beispiele für die Zuordnung einfacher GAFunktionen zu gängigen E/A-Objekten (AI, BI, AO, BO und MO) und komplexen
BACnet-Objekten (SCHED, CAL).
Für jede GA-Funktion wird ein geeigneter BACnet-Objekttyp mit seiner Abkürzung angegeben (siehe Tabelle 1). Werden mehrere BACnet-Objekte eines
Typs benötigt, wird die erforderliche Anzahl genannt. Die Rechte (R/W) sind
mit „R” gekennzeichnet, falls MBE oder andere Clients für die Objekte und
ihre Properties nur Leserechte benötigen. Falls bestimmte Properties auch
Schreibrechte benötigen, so sind die Rechte mit „W” gekennzeichnet.
BACnet 2007
33
GA-Aufgabe (DIN EN ISO 16484-3, VDI
3814-1)
BACnet-Objekttyp
Anlagenteil
Anz.
Art
3
4
5
1
AI
R
ohne Grenzwert
GA-Funktion
1
2
Hinweise
R/W
6
Temperaturfühler
Messen (Analogeingabe)
Temperaturfühler
mit Grenzwert
Messen (Analogeingabe)
1
AI
R
Istwert nur lesbar
Oberer Grenzwert
Teil von AI
W
Grenzwert beschreibbar
Unterer Grenzwert
Teil von AI
W
Grenzwert beschreibbar
Kontaktgeber
Melden (Binäreingabe)
1
BI
R
z. B. Betriebsmeldung
Wächter
Melden (Binäreingabe)
1
BI
R
z. B. Frostschutz
Schalter
Rückmeldung (Binäreing.)
1
BI
R
z. B. Reparaturschalter
Stellventil stetig
ohne Rückmeldung
Stellen (Analogausgabe)
1
AO
W
Stellventil stetig
Stellen (Analogausgabe)
mit Rückmeldung Rückmeldung Stellung
1
AO
W
1
AI
R
Motor 1-stufig
1
BO
W
z. B. Pumpe, Ventilator
Teil von BO
W
muss rücksetzbar sein
Schalten (Binärausgabe)
Betriebsstundenerfassung
Melden (Betrieb)
1
Melden (Störung)
1
BI
R
Schalten
1
MO
W
Melden (Betrieb)
1
MI
R
Betriebsstunden (gesamt)
1
BV
W
Melden (Störung)
1
BI
R
Schalten (Aus/Stufen 1 - n)
1
MO
W
Rückmeldung (je Stufe)
1
MI
R
Betriebsstunden (gesamt)
1
BV
W
Melden (Störung)
1
BI
R
Wochenschaltplan Zeitabhängiges Schalten
1
SCHED
W
z. B. 3x täglich Ein/Aus
Jahresschaltplan
Feiertage
Zeitabhängiges Schalten
1
CAL
W
z. B. jährlich
12 Feiertage
Jahresschaltplan
Ferien
Zeitabhängiges Schalten
Teil von CAL
W
z. B. jährlich
2x Semesterferien
Motor 2-stufig
(Aus/St.1/St.2)
Schaltbefehl
n-stufig
(Aus, Stufe 1-n)
BI
R
z. B. Pumpe, Ventilator
muss rücksetzbar sein
muss rücksetzbar sein
Tabelle 2: Zuordnung von GA-Funktionen zu BACnet-Objekttypen (Prinzip)
34
Anhang 2 enthält eine nach Anlagenteilen sortierte Auswahl von gebräuchlichen GA-Funktionen in der technischen Gebäudeausrüstung. Die Tabelle
zeigt auf, wie die Datenkommunikation der gängigsten GA-Funktionen mit
Hilfe von BACnet-Objekttypen umzusetzen ist. Zusätzlich benennt sie die
Normbezeichnungen der GA-Funktionen nach VDI 3814-4.
Anhang 3 erläutert am Beispiel einer RLT-Anlage die Zuordnung der GAFunktionen zu BACnet-Objekttypen. Das RLT-Anlagenschema in Anhang 3.1
entspricht dem Beispiel in DIN EN ISO 16484-3 und wurde gewählt, weil es
besonders umfassende und vielseitige GA-Funktionen enthält. Die Tabelle in
Anhang 3.2 ordnet den in der Norm genannten GA-Funktionen die empfohlenen BACnet-Objekten zu.
Bei der Planung technischer Anlagen können geeignete Funktionen aus dem
Beispiel übernommen werden. Bei RLT-Anlagen sind die GA-Funktionen nicht
1:1 vom Beispiel zu übernehmen, sondern projektspezifisch festzulegen (z.
B. mit Klärung der Notwendigkeit von lokalen Vorrangbedienungen und von
Rückmeldungen der Klappenstellungen).
Entsprechend den Zuordnungsbeispielen in Anhang 2 und 3 sind auch andere geforderte GA-Funktionen mit möglichst leistungsfähigen Objekttypen
in den AS einzurichten und nicht über Hilfsobjekte nachzubilden oder in MBE
parallel einzurichten.
Das Einrichten von geforderten BACnet-Funktionen für den laufenden GA-Betrieb mit nicht geforderten herstellerspezifischen Objekttypen, Properties oder
Diensten sowie Einschränkungen oder Erweiterungen ist nicht zugelassen.
Im Bestand können auf Grund vorhandener, älterer BACnet-Systeme in abgegrenzten Bereichen Abweichungen und Sonderlösungen mit Hilfsobjekten
notwendig sein. Diese sind bei der BACnet-Planung im Einzelfall abzustimmen.
Alle verwendeten Properties sind mit anlagenspezifischen und im Projekt einheitlich abgestimmten Werten zu belegen.
BACnet 2007
35
4.4 Reaktionszeiten
Erheblichen Einfluss auf die Nutzbarkeit von GA-Systemen haben die Reaktionszeiten zwischen den Anwendungen (z. B. Feldgeräte und MBE). Darin
enthalten sind auch die Übertragungszeiten bei der Datenkommunikation.
Bei den Systemzeiten sind folgende Einzelzeiten zu unterscheiden:
• Eingabezeit (EZ) ist die Zeitspanne von der internen oder externen Initiierung
eines Eingabevorganges bis zum Bereitstellen der Daten im Prozessor.
• Bearbeitungszeit (BZ) ist die Zeitspanne, die eine Instanz zur Bearbeitung
eines initiierten Auftrages benötigt.
• Übertragungszeit (ÜZ) ist die Zeitspanne der Signalübertragung; sie besteht
aus Aufbereitungszeit im Sender, Transportzeit und Aufbereitungszeit im
Empfänger.
• Ausführungszeit (AZ) ist die Zeitspanne, die eine Instanz zur Ausführung
eines initiierten Auftrages benötigt z. B. der Schaltzeit im Prozess.
• Reaktionszeit (RZ) ist die Zeitspanne von der Initiierung des Eingabevorganges bis zu dem Zeitpunkt, an dem ein Auftrag (ohne Rückmeldung) ausgeführt wurde oder eine geforderte Rückmeldung über die Ausführung beim
anfordernden Gerät eingeht.
Eingabezeit
(EZ)
Bearbeitungszeit
(BZ)
Übertragungszeit
(ÜZ)
Ausführungszeit
(AZ)
Reaktionszeit
(RZ)
Abbildung 2: Einzelzeiten bei Schaltbefehlen (ohne Rückmeldung)
Zum Beispiel setzt sich bei dem Schaltbefehl „Schalten Gesamtanlage“ die
Reaktionszeit zusammen aus den Einzelzeiten für das Auslösen des Schaltbefehls in der Anlagengrafik der MBE, für die Bearbeitung des Ereignisses in
der MBE, für die Datenübertragung im Netzwerk und für die Bearbeitungszeit
in der AS bis zum Start der Anlagensteuerung (Klappen öffnen bzw. Ventilator
beginnt zu laufen).
Bei einem Befehl mit Rückmeldung setzt sich die gesamte Reaktionszeit zusammen aus den Einzelzeiten für die Meldung von der Bedieneinheit bis zum
Empfänger im Feld und für die Rückmeldung vom Empfänger im Feld bis zu
der Bedieneinheit.
36
Bei bestätigten Meldungen können sich die Gesamtzeiten gegenüber unbestätigten Meldungen verdoppeln.
Da aus Nutzersicht die Summen und nicht die Einzelzeiten entscheidend sind,
werden in der Praxis nur die Reaktionszeiten der Ein- und Ausgabefunktionen
betrachtet. Diese sollten den drei Kategorien „wichtig“, „weniger wichtig“ und
„zeitunkritisch“ zugeordnet und mit entsprechend abgestuften Reaktionszeiten
projektspezifisch vorgegeben werden. Dabei sind die verfügbaren Kapazitäten
der örtlichen Kommunikationsnetze zu beachten.
Bei mehreren Systemen mit verschiedenen Lieferanten sind auch die unterschiedlichen Verantwortungsbereiche zu berücksichtigen. Beim Einsatz von
Gateways sind längere Reaktionszeiten zu beachten.
Empfehlungen für Reaktionszeiten:
• wichtig ≤ 3 s
z. B. Alarme, Störungsmeldungen,
• weniger wichtig ≤ 5 s
z. B. Messwerte, Betriebsmeldungen,
Rückmeldungen,
≤ 10 s
• zeitunkritisch
z. B. Betriebsstunden, Verbrauchsdaten,
Archivwerte.
Bei unbefriedigenden Reaktionszeiten müssen die Verantwortlichkeiten der
Lieferanten mittels eines Protokollanalysators geklärt werden.
BACnet 2007
37
5
Automationsstationen (AS)
In diesem Kapitel werden die BACnet-spezifischen Anforderungen an AS erläutert. Die Empfehlungen ergänzen die übergeordneten Hinweise zur Realisierung von BACnet-Systemen in Kapitel 4 und die systemunabhängigen
Empfehlungen in der „Gebäudeautomation 2005“.
5.1 Allgemeines
Automationsstationen (AS) sind vernetzte, aber ansonsten eigenständige Geräte zur Automatisierung von Prozessen in gebäudetechnischen Anlagen mit
den Merkmalen und Funktionen gemäß DIN EN ISO 16484. Die Geräte müssen so konzipiert und programmiert sein, dass sie auch ohne ein übergeordnetes Netzwerk alle geforderten Regelungs-, Steuerungs- und Optimierungsaufgaben autark ausführen können.
AS müssen über die in Anhang 4 und 5 beschriebene Grundausstattung an
Objekttypen, Properties und BIBBs verfügen (Gruppe A für AS).
Bei Bedarf können AS mit geringerem Leistungsumfang eingesetzt werden
(z. B. Raumbediengeräte, Displays, Steuerungen und Regelungen für Kältemaschinen, Pumpen, Frequenzumrichter), wenn ihre Automationsaufgaben
(Trends, Zeitpläne, Alarme etc.) anderen AS mit vollständigem Leistungsumfang übertragen werden.
Als ergänzende Ausstattung mit Objekttypen der Gruppe B kommen bevorzugt das Trendaufzeichnungsobjekt (Trend Log Object) für Betriebsanalysen
und bei entsprechendem Bedarf das Reglerobjekt (Loop Object) mit Einstellparametern für Eingriffe in die Regelfunktionen in Frage. Für Änderungen, Datensicherung und Neuladen der Anwendungsprogramme kann das Dateiobjekt (File) eingesetzt werden.
Projektspezifisch können auch Ergänzungen durch Properties der Gruppe B
sinnvoll sein, z. B. „Minimale Aus-Zeit“ (Minimum_Off_Time) und „Minimale
Ein-Zeit“ (Minimum_On_Time).
AS müssen in der Lage sein, für vorgegebene GA-Funktionen Peer-to-PeerKommunikation auszuführen (siehe Anhang 8). Bei der Planung ist auf eindeutig definierte Systemverantwortung und Haftungsgrenzen zu achten.
Auf der Grundlage von Anhang 4 und 5 sind die zu verwendenden Objekte,
Properties und BIBBs festzulegen, die systemübergreifend zugänglich (lesbar,
überschreibbar) bzw. verfügbar sein sollen.
38
Die Systemgenerierung der AS muss als Online-Generierung mittels leicht
verständlicher und einfach handhabbarer Programmiersysteme (EngineeringTools) sowohl vor Ort als auch über das verwendete BACnet-Netzwerk möglich sein.
Das Engineeringtool muss die BACnet-Objekte mit den zugehörigen Properties und Diensten vollständig und in einer Einheit generieren. Eine Programmierung in mehreren Schritten oder mit mehreren Tools je System ist nicht
zulässig.
Alle Programme und Konfigurationsdaten sind in der AS unverlierbar zu speichern.
Der Anlagenbetreiber muss im Betrieb Änderungen an den Programmen
durchführen, neue Programme erstellen, testen und in die AS laden können.
Ein Laden geänderter Programme darf den laufenden Betrieb nicht unterbrechen oder stören. Das Hinzufügen und Entfernen von Objekten muss im laufenden Betrieb ebenfalls möglich sein.
Zum Schutz vor unberechtigten Zugriffen ist das Engineering-Tool mit Passworten zu schützen.
Nach Fertigstellung ist das Engineering Tool für die AS dem Anlagenbetreiber zusammen mit einer zeitlich und inhaltlich unbegrenzten Lizenz und allen
Systempasswörtern zu übergeben.
Anlagenersteller und programmierende Betreiber haben im Zuge der Neugenerierung bzw. Änderung das BACnet-Netzwerk auf Doppelbelegungen und
Doppelbezeichnungen zu prüfen und zum Nachweis eine Prüfliste zu übergeben.
5.2 Einrichten und Anzeigen von Informationen
Adressen der Systemteilnehmer sind nach einem selbsterklärenden Adressierungsschlüssel einzurichten und für die Bediener übersichtlich und logisch
nachvollziehbar darzustellen.
Für jedes BACnet-Objekt ist ein Property „Objektbezeichnung“ (Object_Name)
entsprechend dem vorgegebenen Kennzeichnungssystem des Nutzers vorzusehen. Eine herstellerseitig vorgeschriebene Syntax wird nicht zugelassen.
Das Property muss über eine Kapazität von mindestens 32 Zeichen (Bytes)
verfügen.
BACnet 2007
39
Jedes BACnet-Objekt muss über das Property „Objektbeschreibung“ (Description) verfügen. Das Property muss über eine Kapazität von mindestens
64 Zeichen (Bytes) verfügen und ist für alle BACnet-Objekte mit einem aussagekräftigen Klartext nach Nutzervorgabe einzurichten.
Alle BACnet-Informationen und Parameter müssen in jeder Ebene im Klartext
verfügbar sein.
Ein Bediener muss über die MBE jederzeit Informationen im Netz abrufen und
anzeigen können über den Betriebszustand:
• eines jeden BACnet-Gerätes (MBE, AS etc.),
• eines jeden BACnet-Objektes,
• eines jeden Properties (normativ und optional).
Es sind alle Objekte aufzulisten, deren Adressen den Suchkriterien entsprechen, die ein Bediener einzeln oder in Kombinationen vorgibt. Die Kriterien
müssen sich aus der Systematik des Adressierungsschlüssels (z. B. Liegenschaft, Gebäude, Bauteil, Ebene, Gewerk, Anlagennummer, Zonennummer,
Funktionsbezeichnung, Objektart etc.) ableiten lassen. Die Ergebnisliste muss
sich mindestens nach BACnet Objekttyp und nach Adresse sortieren lassen.
Außerdem muss es möglich sein, alle Eigenschaften eines Objekts mit einer
einzigen Bedienhandlung sichtbar zu machen (z. B. einem Mausklick).
5.3 Melden von Informationen, Ereignissen und Alarmen
Meldungen dienen zur Übermittlung von Informationen über Zustände und
Ereignisse in der GA. Jede AS muss das Melden von Wert- und Zustandsänderungen (COV Reporting) und das objektinterne Melden (Intrinsic Reporting)
unterstützen. Die Meldungserzeugung in AS darf nicht auf die Managementebene verlagert werden.
Die das Meldeverhalten eines Objekts bestimmenden Parameter müssen von
MBE und anderen berechtigten Clients über das BACnet-Netzwerk verändert
werden können (z. B. oberer Grenzwert (High_Limit), unterer Grenzwert (Low_
Limit) und Totband (Deadband) bei Analog-Objekten).
Melden von Wert- und Zustandsänderungen (COV Reporting)
Die Übertragung von Informationen (z. B. Außentemperatur) erfolgt grundsätzlich ereignisorientiert durch Mitteilung von Zustands- und Wertänderungen (z. B.
neuer Wert der Außentemperatur).
40
Dafür muss jede AS COV Reporting unterstützen. Bei der Planung ist die im
Server begrenzte Zahl von möglichen Abonnenten zu berücksichtigen. AS
müssen eine ausreichende Anzahl von COV-Kanälen zu Verfügung stellen.
MBE und andere Clients müssen den Wert oder Zustand der E/A-Objekte bei
AS abonnieren (Subscription Request), damit sie COV-Meldungen von AS erhalten.
Die E/A-Objekttypen müssen COV Reporting unterstützen, um Zustands- und
Wertänderungen zu melden. Die Änderungsschwellenwerte (COV_Increment)
müssen über das BACnet-Netzwerk durch die MBE verändert werden können.
Objektinternes Melden (Intrinsic Reporting)
Objektinternes Melden wird vor allem eingesetzt, um die oberen und unteren
Grenzwerte von analogen E/A-Objekten zu überwachen. Die Meldung wird
im jeweiligen Objekt erzeugt. Dessen Properties beinhalten die Parameter
zur Festlegung des Meldeverhaltens oder zusätzliche zu meldende Informationen.
Beim objektinternen Melden von Objekten wird das Property „Ereignis-Zustand“ (Event_State) mit folgenden Statusbits verwendet:
• Normalzustand
• Fehler
• Abnormaler Zustand
(Normal)
(Fault)
(Offnormal)
Wenn das Property „Ereignismeldungen aktiv“ (Event_Enable) in den E/A-Objekten aktiviert ist, führen folgende Änderungen der Statusbits zu Meldungen:
• To Offnormal
• To Fault
• To Normal
Beim geräteinternen Melden ist mit Meldungsklassenobjekten (Notification
Class) festzulegen, welche Empfänger die Meldung erhalten und welche Priorität der Meldung zugeordnet wird.
BACnet 2007
41
Regelbasiertes Melden (Algorithmic Change Reporting)
Bei entsprechendem Bedarf kann regelbasiertes Melden in AS eingesetzt werden, um Meldungen zu erzeugen für Einzelraumregler oder andere anwendungsspezifische Einheiten, die Intrinsic Reporting nicht unterstützen, sowie
für ein komplexes Alarmrouting.
Beim regelbasierten Melden muss das Ereigniskategorieobjekt (Event Enrollment) eingerichtet werden, das die Meldungen nach einem vorzugebenden
Algorithmus aus einzelnen oder mehreren Properties erzeugt. Die Empfänger
werden im Meldungsklassenobjekt festgelegt.
Unterscheidung von Meldungskategorien
Im Rahmen des Engineering ist festzulegen, welche der Ereignisse quittiert
werden müssen. Die Meldungsklassenobjekte dieser Meldungen sind quittierfähig einzurichten. Entsprechend der Bedeutung der auslösenden Ereignisse
und ihrer unterschiedlichen Bewertung und Quittierung werden 3 Meldungskategorien unterschieden:
• Wartungsmeldung (Ereignis) - WM
Wartungsmeldungen sind einfache, nicht zeitkritische Störungsmeldungen.
Eine Quittierung nach Beseitigung der Störungsursache ist nicht zwingend
erforderlich; sie kann automatisch mit Verlöschen des Ereignisses erfolgen.
• Störungsmeldung (Einfacher Alarm) - SM
Mit Störungsmeldungen werden Informationen über Ereignisse übermittelt
(einfache Alarmmeldungen), deren Auftreten keine unmittelbare Gefahr darstellen (z. B. Unterschreitung eines Temperaturgrenzwertes). Eine Quittierung nach Beseitigung der Störungsursache ist nicht zwingend erforderlich;
sie kann automatisch mit Verlöschen des Alarms erfolgen.
• Gefahrenmeldung (Alarm) - GM
Mit Gefahrenmeldungen werden Informationen über Ereignisse übermittelt,
deren Auftreten eine unmittelbare Gefahr für Personen, Sachwerte oder die
Anlage selbst darstellen und in den meisten Fällen eine Abschaltung der
Anlage zur Folge haben (z. B. Frostschutz). Nach Beseitigung der Störungsursache/Fehlfunktion ist eine Quittierung durch einen berechtigten
Bediener zwingend erforderlich, damit die Anlage wieder in Betrieb gehen
kann.
Alarmmeldungen besitzen die höchste Meldungspriorität.
42
Für jede Anlagenstörung (GM, SM) wird ein Alarm entsprechend der vorgegebenen Klassifizierung eingerichtet (siehe Vorschlag für die Alarmkategorie in
Anhang 7.6).
Zusätzlich werden bei Bedarf Alarme eingerichtet für:
• Nicht korrekt durchgeführte Schalthandlungen,
• Handeingriffe an AS oder am Schaltschrank,
• Systemstörungen der AS (z. B. Ausfall von AS oder AS-Komponenten),
• Andere Systemstörungen (z. B. Kommunikationsunterbrechung).
Für jede Sollwertverletzung ist ein Alarm einzurichten, bei Bedarf auch mit
gleitendem Sollwert. Durch Anlagenstillstand bedingte Sollwertverletzungen
sind zu unterdrücken.
Die Alarme werden mittels Intrinsic Reporting oder Algorithmic Change Reporting erzeugt z. B. durch Überwachung von Grenzwerten (Low_Limit oder
High_Limit) oder Zustandsangaben (Status_Flags). Die Quittierung durch
einen Empfänger ist im Property „Bestätigte Zustandsänderungen“ (Acked_
Transitions) in der AS zu speichern. Wenn die Notwendigkeit besteht, dass die
Meldung von einem bestimmten Empfänger quittiert werden muss, ist dafür
ein eigenes Meldungsobjekt einzurichten.
In Alarmübersichten muss zwischen aktuellen Alarmen und bereits quittierten
Alarmen unterschieden werden. In Abhängigkeit von den eingegebenen Benutzerpassworten müssen Filterfunktionen wirksam werden (z. B. auf Fachgruppen bezogene Alarmübersichten).
5.4 Meldungsklasse
Für jedes BACnet-Objekt, das Meldungen mittels Intrinsic Reporting oder Algorithmic Change Reporting erzeugen soll, ist ein Meldungsklassenobjekt
(Notification Class) mit folgenden Properties einzurichten:
• Prioritätsstufe (Priority),
• Quittierungspflicht (Ack_Required),
• Empfängerliste (Recipient_List) der vom Auftreten der Meldung zu informierenden Stellen,
• Objektbeschreibung (Description) als Klartextanweisung für Bediener.
BACnet 2007
43
Anhang 7.6 enthält Vorschläge für die Festlegung von 7 Meldungsklassen
und für die Prioritätenbildung (bis zu 256 Stufen). Die Störungsmeldematrix
empfiehlt Alarmkategorien mit Kurzbeschreibungen und typischen Beispielen.
Die Kategorien können bei Bedarf gebündelt oder weiter unterteilt werden.
Für jede Meldungsart ist ein eigenes Meldungsklassenobjekt anzulegen.
Die Meldung wird den Empfängern zugestellt, die für die jeweilige Meldungsklasse im Property „Empfängerliste“ (Recipient_List) im Meldungsklassenobjekt eingetragen sind.
Empfängerliste
Alle Meldungsklassenobjekte verfügen über das Property „Empfängerliste“
(Recipient_Liste). Bei BACnet-Servern ist dort einzutragen, welche BACnetClients als Empfänger für die jeweiligen Meldungen vorgesehen sind. Die Informationen können je nach Art, Wochentag oder Uhrzeit unterschiedlichen
Zielen zugeleitet werden.
Die Empfängerliste wird beim Engineering in der AS eingetragen und dort unverlierbar gespeichert. Die AS muss die Bearbeitung der Empfängerliste mit
den Diensten „AddListElement“, „RemoveListElement“ und „WriteProperty“
unterstützen.
Wenn eine neue MBE in das Netzwerk integriert wird, ist ein automatischer
Eintrag in die vorhandenen Empfängerlisten der im Netzwerk verfügbaren AS
zu vermeiden. In solchen Sonderfällen wird ein automatischer Eintrag in zusätzliche, projektspezifisch festgelegte Empfängerlisten empfohlen.
Weitere Hinweise für die Properties der Meldungsklassenobjekte enthält
Anhang 4.3.
5.5 E/A-Objekte
E/A-Objekte (Ein- und Ausgabe-Objekte) sind die analogen, binären und
mehrstufigen Eingabe-, Ausgabe- und Wertobjekte (Analog, Binary und Multistate Input, Output und Value Objects).
Bei allen E/A-Objekten müssen die Properties „Objektfunktion außer Betrieb“
(Out_Of_Service) und „Meldungsverzögerung“ (Time_Delay) beschreibbar
sein. Die Festlegung erfolgt gemäß GA-Funktionsliste.
44
Physikalische Eingänge sind je nach Datentyp analogen oder binären Eingabeobjekten zuzuordnen. Physikalische Ausgänge sind je nach Datentyp
analogen oder binären Ausgabeobjekten zuzuordnen. Die Werte von physikalischen Ein- und Ausgängen sind direkt mit ihren physikalischen Einheiten
gemäß Spalte 4 in Anhang 7.5 darzustellen.
Zusätzliche, nicht geforderte BACnet-Objekte dürfen nicht eingerichtet werden (z. B. Objekte für die vorgelagerte Signalaufbereitung zur Kompensation
von Nichtlinaritäten eines Sensors).
Zustandstexte und physikalische Einheiten sind für alle E/A-Objekte vollständig einzurichten.
Mehrstufige Ein- und Ausgabeobjekte müssen mindestens zwölf Schaltzustände darstellen können. Die Schaltstufen sind automatisch gegeneinander
verriegelt. Mehrstufige Objekttypen verfügen (im Gegensatz zu binären Objekttypen) nicht über eigene Properties für die Betriebsstundenerfassung je
Stufe.
Bei analogen, binären und mehrstufigen Ausgabe- und Wertobjekten können
mehrere Eingriffe gleichzeitig erfolgen (z. B. Zeitschalten mit Zeitschaltobjekt
und Handschalten mit Binäreingabe). Die Prioritäten der unterschiedlichen
Eingriffe (z. B. Handschalten vor Zeitschalten) werden durch Eintragung des
jeweils gewünschten Wertes in einer von 16 verfügbaren Prioritätenspalten im
Property „Kommando-Prioritäten“ (Priority_Array) festgelegt.
Zustandsangaben
Gemäß Norm müssen Ein- und Ausgabeobjekte in der Lage sein, im Property
„Zustandsangaben“ (Status_Flags) folgende vorgegebenen Zustände zu unterscheiden:
• Alarmzustand • Systemfehler (z. B. Geberstörung) • Wert/Zustand überschrieben (Handeingriff) • Außer Funktion gesetzt (Systembedienung) (In Alarm)
(Fault)
(Overridden)
(Out Of Service)
Dabei sind die Zustände „Alarm“ und „Systemfehler“ als Störungsmeldungen
weiterzuleiten. Die Störungsmeldungen müssen entsprechend ihrer Wichtigkeit priorisiert werden.
BACnet 2007
45
Zustandstexte
Die Zustände der binären Ein- und Ausgabobjekte (z. B. Ein / Aus, Normal /
Störung, Hand / Automatik) werden projektspezifisch beschrieben mit Hilfe der
beiden Properties „Aktiv-Zustandstext“ (Active_Text) und „Inaktiv-Zustandstext“ (Inactive_Text). Die Properties müssen Zustandstexte mit mindestens 20
Zeichen zulassen.
Die Zustände von mehrstufigen Ein- und Ausgabeobjekten werden beschrieben im Property „Zustandstext“ (State_Text), das über eine Liste mit allen
möglichen Schaltzustände verfügt. Jeder Listeneintrag muss mindestens 20
Zeichen umfassen können.
Die Zustandstexte sind beim Engineering vollständig zu konfigurieren. Bei
Neuinstallationen werden die Zustandstexte vom Planer gemeinsam mit dem
Betreiber abgestimmt und festgelegt. Bei Erweiterungen erfolgt dies in Anlehnung an den Bestand.
Zur Vereinfachung wird empfohlen, die Zustandstexte in Anhang 7.4 zu verwenden. Die beiden ersten Ziffern der Referenznummer entsprechen der Anzahl der unterschiedlichen Zustände (z. B. 02 bei binären Zuständen). Die
beiden nachfolgenden Ziffern ermöglichen weitere Unterscheidungen von Betriebszuständen. Die Tabelle kann bei Bedarf ergänzt werden.
Befehlsausführkontrolle
Bei binären und mehrstufigen Ausgabeobjekten muss das Property „Rückmeldungswert“ (Feedback_Value) die automatische Überwachung des Sollzustandes mittels Intrinsic Reporting ermöglichen. Weichen Soll- und Ist-Zustand
voneinander ab, ist nach einer einstellbaren Zeit eine Störmeldung auszugeben.
Weitere Hinweise für Properties der E/A-Objekte enthält Anhang 4.2.
5.6
Betriebsstundenerfassung
Betriebsstunden werden in binären Objekten mit Hilfe der Properties „Betriebsstundenzähler“ (Elapsed_Active_Time) und „Betriebsstundenzähler-Rücksetzzeitpunkt“ (Time_Of_Active_Time_Reset) erfasst.
Die Betriebsstunden sind in Sekunden zu übergeben.
Rückstellen bzw. Überschreiben des Wertes durch den Client muss möglich
sein und ist zu protokollieren. Auch das Einstellen einer Obergrenze zur Auslösung einer Wartungsmeldung muss möglich sein.
46
Das automatische Übermitteln einer Wartungsmeldung bei Überschreitung der
Obergrenze durch einen Betriebsstundenzähler wird mit Hilfe des regelbasierten Meldens (Algorithmic Change Reporting) oder im Anwendungsprogramm
realisiert.
Beispiele für die Betriebsstundenerfassung von Anlagen und Anlagenteilen
enthalten Tabelle 2, Anhang 2 und Anhang 3.2. Bei mehrstufigen Antrieben
können die Betriebszeiten der einzelnen Stufen mittels Trendaufzeichnung erfasst und ausgewertet werden (siehe Abschnitt 5.9).
5.7 Zeitabhängiges Schalten mit Zeitplan und Kalender
Zeitschaltfunktionen sind grundsätzlich in den AS zu realisieren.
Das Zeitplanobjekt (Schedule Object) wird eingesetzt, um Zustände oder
Werte in Abhängigkeit von Datum und Uhrzeit zu verändern. Dabei wird z. B.
auf physikalische Ausgabefunktionen, Betriebsparameter (z. B. Sollwerte) oder
virtuelle Objekte wie „Betriebsart Gesamtanlage“ eingewirkt.
Das Property „Wochenzeitplan“ (Weekly_Schedule) enthält einen Zeitplan für
sieben Wochentage mit mindestens 6 Schaltzeiten und -werten je Tag. Der
Zeitbereich, in dem das Zeitplanobjekt aktiv ist, wird im Property „Gültigkeitszeitraum“ (Effektive_Period) festgelegt.
Ein Zeitplan kann mehreren Objekten vom gleichen Typ zugeordnet werden,
wobei alle diese Objekte zu der vorgegebenen Zeit auf den gleichen Wert gesetzt werden.
Ausnahmen vom Zeitschaltplan sind – auch wenn sie nur einmalig auftreten
– mit dem Property „Ausnahmezeitplan“ (Exception_Schedule) des Zeitplanobjekts zu erfassen. Die von den Ausnahmen betroffenen Zeiträume werden
mit dem Kalenderobjekt festgelegt.
Jede AS muss mindestens 10 Zeitplanobjekte mit jeweils mindestens 6 Zeiteinträgen pro Wochentag (Weekly_Schedule) und mindestens 6 Verweise auf
Kalenderobjekte pro Property „Ausnahmezeitplan“ (Exception_Schedule) zur
Verfügung stellen.
In Ausschreibungen sind die Anzahl der vom angebotenen BACnet-System
unterstützten Zeitplanobjekte und die Anzahl Zeiteinträge je Objekt abzufragen. Die erforderliche Mindestanzahl ergibt sich aus der GA-Funktionsliste.
BACnet 2007
47
Das Kalenderobjekt (Calendar Object) dient dazu, eine Liste mit Zeitangaben
anzulegen. Die Zeitangaben werden im Property „Datumsliste“ (Date_List) als
Datum, Zeitspanne oder Kombinationen aus Monat, Woche und Wochentag
eingetragen. Eine typische Anwendung des Kalenderobjektes ist das Festlegen der Feiertage, Betriebsferien oder anderer Zeiträume innerhalb eines
Jahres, an denen jeweils ein Ausnahmezeitplan gültig ist.
Pro AS muss die Systemsoftware mindestens 10 Kalenderobjekte erlauben.
Im Property „Auftragsprioritäten“ (Priority_For_Writing) wird die Priorität des
Eingriffs des Zeitplanobjekts festgelegt. Diese hat Auswirkungen auf die Position des Eintrags im Property „Kommando-Prioritäten“ (Priority_Array) des
vom Eingriff betroffenen Objekts.
Von jeder MBE im Netzwerk muss lesender und schreibender Zugriff auf die
Zeitplanobjekte und Kalenderobjekte möglich sein.
Die Veränderung von Zeitplan- und Kalenderobjekten kann über die MBE und
vor Ort mittels AS-eigener Bediengeräte erfolgen. Sofern im Projekt nicht anders spezifiziert, sind beide Bedienmöglichkeiten gleichberechtigt. Der letzte
Eintrag hat somit Gültigkeit. Änderungen vor Ort sind als Betriebsmeldung an
die MBE zu melden.
Weitere Hinweise für die Properties der Zeitplan- und Kalenderobjekte enthält
Anhang 4.3.
5.8 Zeitsynchronisation
Jede AS muss über eine Systemuhr verfügen. Ein BACnet-Gerät (in der Regel
eine MBE) fungiert als systemweiter Zeitgeber (Time Master). Die übrigen Geräte übernehmen diese Zeitvorgaben und synchronisieren sich danach.
Die Zeitsynchronisation verwendet die BACnet-Dienste:
• DM - TS - A/B • DM - UTC - A/B
(Synchronisation über die Ortszeit)
(Synchronisation über die Weltzeit)
Der Time Master soll beide Synchronisationsdienste unterstützen. Die zu synchronisierenden Geräte müssen mindestens einen Synchronisationsdienst
beherrschen.
48
Im Betrieb ist die Ortszeit (lokale Uhrzeit) zu verwenden. Es wird empfohlen,
Langzeitarchivierung mit der Weltzeit vorzunehmen.
5.9 Trendaufzeichnung
Trendaufzeichnungen dienen zur Dokumentation des zeitlichen Verlaufs von
Betriebszuständen und Prozessgrößen. Sie können auch für die Managementfunktionen „Langzeitspeicherung“ und „Historisierung in Datenbank“ nach
DIN EN ISO 16484-3 herangezogen werden.
Werden Trendaufzeichungsobjekte (Trend Log Objects) eingesetzt, so müssen
ihre Parameter von der MBE verändert werden können. Die Objekte müssen
dynamisch erzeugbar sein.
Langzeit-Trend
Die Aufzeichnung von Trends in MBE und anderen Clients kann ohne Nutzung
der Trendaufzeichnungsobjekte (Trend Log Object) erfolgen. Dazu werden die
aufzuzeichnenden Daten mittels Read Property (RP) oder COV Reporting zum
Client übertragen, wo sie z. B. in einer Datenbank abgespeichert werden.
Mit Hilfe von Trendaufzeichnungsobjekten können Daten zusätzlich auch innerhalb von BACnet-Geräten (z. B. AS) aufgezeichnet werden. Die Daten stehen dort für die spätere Übertragung zu einem Client (z. B. MBE) und eine
Auswertung oder Langzeitspeicherung zur Verfügung.
Diese Fähigkeit kann dann vorteilhaft sein, wenn keine dauerhafte Netzwerkverbindung zwischen AS und MBE besteht, z. B. bei kleineren Liegenschaften
mit Standalone-GA-Lösungen und Modem-Anbindung zur Fernauslesung. Die
Zwischenspeicherung vermeidet Betriebskosten durch häufiges Herstellen
von Verbindungen.
Kurzzeit-Trend
Zur Vereinfachung der Inbetriebnahme und Fehlersuche kann in AS für jeden
analogen Eingang und Ausgang sowie für wichtige virtuelle Objekte das Trendaufzeichungsobjekt mit ausreichender Speicherkapazität (z. B. 100 Einträge)
eingerichtet werden. Dabei sollte die Bezeichnung der Trendaufzeichungsobjekte mit den geloggten Objekten korrespondieren, so dass die Bedeutung
ohne zusätzliche Referenzen erkennbar ist.
Online-Trend
Der Online-Trend ist die Darstellung des aktuellen Verlaufs einer physikalischen Größe über einen begrenzten Zeitraum auf der MBE.
BACnet 2007
49
Diese Funktion kann zusätzlich auch mittels Trendaufzeichnungsobjekt realisiert werden. Damit der Betreiber im laufenden Betrieb von einer MBE aus
einen Online-Trend generieren und für eine bestimmte Zeit aktivieren kann,
müssen die Trendaufzeichnungsobjekte dynamisch erzeugbar und von der
MBE parametrierbar sein.
Weitere Hinweise für die Properties der Trendaufzeichnungsobjekte enthält
Anhang 4.3.
5.10 Regler
Bei einfachen Regelkreisen kann die Übertragung des Sollwertparameters von
der AS zur MBE mit Hilfe von Wertobjekten (Value Object) ausreichen. Diese
Festlegung ist den Projektpartnern mittels EDE-Datei zugänglich zu machen.
Das Reglerobjekt (Loop Object) wird benutzt, um höherwertige Regelkreise
mit PID-Regler über das BACnet-Netzwerk bedienbar zu machen (z. B. Sollwert, P-, I-, D-Anteil und Ausgabe-Voreinstellung). Die projektspezifischen Anforderungen sind in der GA-Funktionsliste zu spezifizieren.
Für die in der TGA üblichen Reglermodelle wie Heizkreisregler oder P-PI-Kaskaden stehen keine eigenen BACnet-Objekttypen zur Verfügung. Die Übertragung dieser Lösungen mittels BACnet-Kommunikation kann durch Kombination mehrerer Reglerobjekte ermöglicht werden.
Weitere Hinweise für die Properties der Reglerobjekte enthält Anhang 4.3.
5.11 Handeingriff
In besonderen Betriebsfällen müssen Eingabe- und Ausgabewerte manuell
geändert werden können. Dazu wird im zugehörigen Objekt das Property „Objektfunktion außer Betrieb“ (Out_Of_Service) gesetzt. Nach dessen Aktivierung
kann das Property „Aktueller Wert“ (Present_Value) von der MBE beliebig geändert werden. Bis zum Rücksetzen wird der geänderte Wert von allen anderen Anwendungen benutzt.
Beim Rücksetzen des Property „Objektfunktion außer Betrieb“ muss automatisch und sofort der aktuelle Wert übernommen werden.
Die Übersteuerung der Automatikfunktion der AS durch eine MBE oder ASBedieneinrichtung muss im Property „Zustandsangaben“ (Status_Flags) der
E/A-Objekte angezeigt und der MBE durch eine Meldung der AS mitgeteilt
werden. Die Übersteuerung durch eine lokale Vorrangbedienung (LVB) wird in
der Regel durch ein binäres Eingabeobjekt erfasst und der MBE gemeldet.
50
Handeingriffe über eine LVB und mit dem Property „Objektfunktion außer Betrieb“ müssen im Anlagenbild unterschiedlich dargestellt werden.
Handeingriffe erhalten im Beispiel nach Anhang 7.6 die Meldungsklasse 7.
Bei bestimmten Anlagenteilen müssen Handeingriffe gemäß Funktionsbeschreibung bzw. GA-Funktionsliste als Störung bewertet und somit als Alarm
gemeldet werden.
Werden mehrere MBE eingesetzt, ist das Überschreiben eines Wertes durch
eine MBE automatisch an alle anderen MBEs zu melden.
5.12 Systemstörungen
Jede AS muss eine Selbstüberwachung durchführen. Fehlfunktionen einer AS
oder eines Sensors müssen gemeldet werden. Die AS muss auch Systemstörungen aus der Gebäudeautomation melden, die keinen Einfluss auf den Anlagenzustand haben. Bei modular aufgebauten AS sollen die gestörten Module
angezeigt werden.
Systemstörungsmeldungen sind in die GA-Funktionsliste mit aufzunehmen.
Sie müssen visualisiert und protokolliert werden.
Systemstörungsmeldungen in AS (z. B. Watchdogs für Kommunikation, Aktorik/Sensorik und Software sowie Ladezustand der Pufferbatterie) sind in Form
von Wertobjekten einzurichten. Sie sollen einer von drei Meldungskategorien
zugeordnet werden (siehe Abschnitt 5.3).
Eine mögliche Methode zur Erkennung von Systemstörungen ist die zyklische
Abfrage des Servers durch den Client mit dem Dienst »Who-Is“, die der Server
mit dem Dienst „I-Am“ beantwortet. Das Ausbleiben der Antwort eines Servers
wird als Störung ausgewertet.
Eine weitere Methode ist die zyklische, systemweite Abfrage der Properties
„Ereignis-Zustand“ (Event_State).
Wenn ein Sensor oder eine AS eine Fehlfunktion meldet, muss ein Bediener
in der Lage sein, die Kommunikation der entsprechenden Einrichtung bis zur
Reparatur zu deaktivieren. Über eine Bedieneinrichtung im BACnet-Netzwerk
muss die für Alarm- und Ereignismeldungen zuständige Einrichtung kommunikativ abgeschaltet werden können, bis die Wiederaufnahme der Kommunikation befohlen wird.
BACnet 2007
51
Alle kommunikativ abgeschalteten Einrichtungen müssen mit Zeitstempel abrufbar sein und mittels Protokollfunktionen dargestellt werden können.
Bei Spannungsausfall sind die dynamisch veränderlichen Eigenschaften in
der AS über mindestens 72 h zu puffern. Dies gilt z. B. für die Trendaufzeichnungsobjekte (Trend Log), Zeitplan- und Kalenderobjekte (Schedule, Calendar) und für die Properties „Empfängerliste“ (Recipient_List) in den Meldungsklassenobjekten.
Falls in besonderen Fällen USV-gepufferte AS gefordert sind, müssen bei
Netzausfall alle daraus resultierenden Störungen bis zur Netzwiederkehr unterdrückt und nur die Meldung Netzausfall an die Managementebene übermittelt werden (Vermeidung von Meldeschauern).
Bei Netzwiederkehr muss ein Wiederanlauf mit Hilfe der in der AS dauerhaft
gespeicherten Programme und Parameter erfolgen. Netzwiederkehr nach GAFunktionsliste ist eine Programmfunktion in der AS.
In AS ist der kontrollierte Wiederanlauf nach Netzausfall bzw. Umschaltung
von Normalnetz auf Notnetz und umgekehrt programmierbar. Zur MBE wird
der Wiederanlauf unter Verwendung folgender Dienste übertragen:
• AS:
DM-R-B (Restart-B) Information an A über jeden Neustart von B
• MBE: DM-R-A (Restart-A) Verarbeitung von Wiederanlauf-Meldungen
von B mit Interpretation der Gründe
Nach Wiederanlauf werden mit Hilfe der beiden Dienste GetAlarmSummery
oder GetEventInformation nur noch die Meldungen weitergegeben, die
nach wie vor anstehen.
52
6
Management- und Bedieneinrichtung (MBE)
Nachfolgend werden die BACnet-spezifischen Anforderungen an Management- und Bedieneinrichtungen (MBE) beschrieben.
6.1
Allgemeines
Für den Nutzen eines GA-Systems ist die Funktionalität einer MBE von erheblicher Bedeutung. Sie beeinflusst die Akzeptanz durch Betreiber maßgeblich
und ermöglicht erst einen sinnvollen Gebäudebetrieb.
Die Anzahl der Ein-/Ausgabefunktionen und Verarbeitungsfunktionen wird
generell durch die Anforderungen der Anlagen der TGA bestimmt. Welche
Informationen für die Managementaufgaben und für die Anlagenbedienung
bereitgestellt werden, muss bei der Planung unter Berücksichtigung aller betrieblichen Aufgaben festgelegt werden.
Nach der Vergabe wird im Rahmen der Montage- und Werkstattplanung von
den Auftragnehmern eines BACnet-Systems die EDE-Liste erstellt und allen Beteiligten zur Verfügung gestellt. Die Aufgaben von BACnet-MBE werden unterteilt
in folgende Grund- und Zusatzfunktionen (siehe auch GAEB StLB-Bau 070):
Grundfunktionen:
• Darstellung von Ereignis- und Alarm-Informationen (einschließlich deren
Quittierung und Protokollierung),
• Grafische Visualisierung der Anlageninformationen,
• Manuelle Bedienung von Gesamtanlagen,
• Erstellung und Änderung von Zeitschaltfunktionen,
• Darstellung von Trenddaten in der MBE,
• Funktionsüberwachung aller angeschlossenen BACnet-Geräte.
Zusatzfunktionen:
• Detaillierte manuelle Bedienung von einzelnen Anlagenkomponenten,
• Anpassen von Alarmgrenzen,
• Verändern von Sollwerten und anderen Parametern,
• Umprogrammierung der Verarbeitungsfunktionen zur Anpassung von Regelstrategien und Steuerungsfunktionen der technischen Anlagen,
• Erfassung von Daten (z. B. Medienverbrauchsdaten) für die Historisierung
und deren Auswertung durch Analysesoftware (die eigentlichen Managementfunktionen),
• Archivierung (Backup/Restore der Konfigurationsdaten, Auslagern der
historisierten Daten),
• Verändern z. B. von Meldungstexten, Alarmziel-Zuordnungen, Anlagenbildern.
BACnet 2007
53
Bedieneingriffe dürfen erst nach Authentifizierung des Bedieners (z. B. durch
Eingabe von Benutzerkennung und Passwort) möglich sein und müssen in
einer revisionssicheren Log-Datei aufgezeichnet werden. Bei der Errichtung
von GA-Anlagen mit mehreren verteilten MBE ist ein umfassendes Konzept zur
Verwaltung aller Passworte und Log-Dateien zu erarbeiten und umzusetzen.
Der übergeordneten Managementebene kommt eine strategische Schlüsselrolle zu. Es ist wichtig, bei Errichtung einer MBE die technischen, organisatorischen und personellen Voraussetzungen für eine dauerhafte Unabhängigkeit
von einzelnen Herstellern, Lieferanten oder Dienstleistern zu schaffen.
Bei der Neuerrichtung eines BACnet-Systems empfiehlt sich im ersten Schritt
die Beschaffung einer neutralen BACnet-MBE, die als technologische Grundlage für die im BACnet-System geforderte BACnet-Funktionalität fungiert. Sie
muss über das BACnet-Protokoll mit AS unterschiedlicher Hersteller kommunizieren können und die interoperable Kopplung aller neu zu beschaffenden
AS ermöglichen (siehe BACnet-Anschlussbedingungen in Kapitel 8).
MBE müssen über die in Anhang 4 und 5 definierte Grundausstattung an Objekttypen, Properties und BIBBs (Gruppe A für MBE) verfügen. Als ergänzende Ausstattung kommen Objekttypen, Properties, Zugriffsrechte und BIBBs der Gruppe
B für MBE in Frage (z. B. regelbasierte Meldungserzeugung - Algorithmic Change
Reporting).
GA-Betreiber sollten die wichtigen Positionen in der GA mit qualifizierten eigenen Fachleuten besetzen. Diese benötigen vollständigen Zugriff auf alle Funktionen der Management-Ebene. Bereits geringfügige Einschränkungen (z. B.
normenkonforme, aber herstellerspezifische BACnet-Funktionen, fehlende
Passwörter für einzelne Zugriffs-Ebenen) bedeuten häufig dauerhafte Abhängigkeit z. B. bei Erweiterungen und betrieblichen Optimierungen.
Sollen Planung, Ausführung oder Instandhaltung an Externe vergeben werden,
so sind auch hierfür konkrete Vorgaben zu erarbeiten (siehe Kapitel 8).
Soweit nachstehend keine anderslautenden Hinweise gegeben werden, sind
die Empfehlungen für BACnet-AS in Kapitel 5 sinngemäß auch bei BACnetMBE zu beachten.
54
6.2
Hardware
Das Managementsystem wird in der Regel als modulares Rechnernetzwerk
mit standardisierten Komponenten der EDV wie Server, Arbeitsplatz-PC und
Backup-Laufwerken aufgebaut.
In „Gebäudeautomation 2005“, DIN EN ISO 16484-2 und im GAEB StLB-Bau
070 sind die Anforderungen an die Hardware beschrieben. BACnet stellt in
diesem Zusammenhang keine besonderen Anforderungen mit Ausnahme
des Netzwerks (siehe Kapitel 7).
Zubehör wie Modem, Router usw. sind aus handelsüblichen Produkten zu
wählen. Die Anforderungen sind in der Planung vorzugeben.
6.3
Betriebssystem
BACnet stellt keine besonderen Anforderungen an das Computer-Betriebssystem.
6.4
Beobachten und Bedienen
Eine Grundfunktion der MBE ist das Beobachten und Bedienen der aufgeschalteten technischen Anlagen. Der Bediener kann zum Aufrechterhalten des
sicheren Anlagenbetriebs auch den automatischen Betrieb durch Handeingriffe übersteuern.
Handeingriffe von der MBE in AS dienen z. B. folgenden Zwecken:
• Übersteuern von berechneten Sollwerten,
• Verändern von berechneten Grenzwerten,
• Übersteuern von Ein- oder Ausgabeobjekten.
Damit manuell eingestellte Betriebszustände nicht unnötig lange aufrecht erhalten werden, sind diese Eingriffe in der MBE deutlich sichtbar zu kennzeichnen und in Listenform aufrufbar zur Verfügung zu stellen. Dies gilt auch für
Eingriffe über lokale Vorrangbedieneinrichtungen.
BACnet 2007
55
6.5 Störungsmanagement
Das Störungsmanagement dient dem Melden, der Verwaltung und Dokumentation aller Störungen im verbundenen Gesamtsystem.
Die MBE unterstützt für die Alarm- und Ereignisbehandlung die Dienste melden von Wert- und Zustandsänderungen (COV Reporting), Objektinternes
Melden (Intrinsic Reporting) und ggfs. Regelbasiertes Melden (Algorithmic
Change Reporting).
Die Bildung von Alarmen und Ereignismeldungen in der MBE wird nicht zugelassen.
Mit Hilfe der Meldungsklassenobjekte (Notification Class Objects) können die
Informationen über Ereignisse/Alarme in Abhängigkeit der Meldungsklasse
auch zeitgesteuert an unterschiedliche Empfänger wie E-Mail, Drucker, Fax
oder SMS oder entfernte Bedienstationen weitergegeben werden.
Empfehlungen für die Definition von Meldungsklassen mit Alarmkategorien,
Kurzbeschreibungen und typischen Beispielen enthält Anhang 7.6.
6.6 Zeitabhängiges Schalten
Die Bedienung der Funktionen für zeitabhängiges Schalten ist eine wesentliche Grundfunktion der BACnet-MBE.
Für zeitabhängiges Schalten wird das Zeitplanobjekt (Schedule) in Verbindung mit dem Kalenderobjekt (Calendar) benutzt.
6.7 Trenddaten und historische Daten
Trenddiagramme und historisierte Daten des GA-Systems sind unverzichtbare
Grundlagen für die Fehlersuche, Betriebsanalyse und Anlagenoptimierung.
Die benötigten Informationen (z. B. Temperaturverläufe oder Betriebszustände)
müssen in einer Datenbank der MBE gespeichert und je nach Bedarf dargestellt und mit statistischen Methoden ausgewertet werden können.
Die Datenbank muss Abfragen mittels einer standardisierten Abfragesprache
(SQL) und den Datenexport unterstützen.
6.8 Medienverbrauchserfassung
Die Verarbeitung der Medienerfassung ist als eine Zusatzfunktion für MBE vorgesehen. Sie muss projektspezifisch vorgegeben werden.
Ergänzend wird auf die Empfehlungen in „Gebäudeautomation 2005“ verwiesen.
56
7
Anforderungen an Netzwerke
Dieses Kapitel beschreibt die BACnet-spezifischen Anforderungen an Netzwerke.
7.1 Netzwerkprotokolle
Da der BACnet-Standard auf dem ISO-Schichten-Modell für Kommunikationssysteme basiert, können BACnet-Nachrichten über mehrere Medien mit unterschiedlichen Zugriffsverfahren ausgetauscht werden.
Am häufigsten in Europa angewendete Netzwerke sind:
• BACnet/IP Netzwerk,
• BACnet MS/TP Netzwerk,
• BACnet LonTalk Netzwerk,
• BACnet PTP Netzwerk.
In den nachfolgenden Strukturübersichten werden die verwendeten Layer und
Protokolle der Netzwerke mit Anwendungsbereichen und Beispielen dargestellt.
BACnet 2007
57
7.2
BACnet/IP
Das Netzwerkprotokoll BACnet/IP (BACnet over IP) nach Annex J der Norm ist
in den öffentlichen Liegenschaften am weitesten verbreitet. Die IP-Lösung gilt
als leistungsfähig und zukunftssicher, setzt allerdings ausreichende Netzwerkkapazitäten, geeignete aktive Netzwerkkomponenten sowie eine Abstimmung
der Zuständigkeiten und Leistungsgrenzen mit der IT-Administration voraus,
die in der Regel die Betreuung der Netzwerkkomponenten übernimmt.
In gerouteten BACnet/IP-Netzen wird ein BBMD-Gerät (BACnet Broadcast Management Device) benötigt, um die Übertragung von Broadcast-Meldungen
sicherzustellen (siehe Anhang 8).
Layer
1
Protokoll
2
Anwendungsbereich, Beispiel
3
Application
Layer
BACnet Application
Protocol
BACnet-Object,
BACnet-Service
Network Layer
BACnet Network
Protocol
Netzwerknummer (max.
65.535 Teilnetze) + DeviceAdresse
Data Link Layer
BACnet Virtual Link
Protocol
verteilt BACnet-Broadcast über
IP-Router
User Datagram Protocol
(UDP)
Zugriff über Ports
0xBAC0…0xBACF
Internet Protocol (IP)
IP-Adresse
(z. B. 192.168.000.001)
Logical Link Control
ISO8802-2 / IEEE802.2
Medium Access Control (MAC)
(z. B. 00-11-22-33-00-00)
ISO 8802-3
(IEEE 802.3)
10Base-T, 100Base-Tx,
1000Base-Tx etc.
Physical Layer
Tabelle 3: Strukturübersicht BACnet/IP
58
Standard
4
BACnet
Standard
TCP/IP
Protocol
Suite
IEEE 802.3
Protocol
Suite
7.3
BACnet MS/TP
Mit BACnet MS/TP (BACnet over Master-Slave/Token-Passing-Protokoll) steht
ein leistungsfähiger Feldbus zur Verfügung, der von mehreren Herstellern
unterstützt wird. Ein BACnet-Feldbus benötigt im Gegensatz zu proprietären
oder anderen Feldbussen mit offenem Protokoll keine Gateways, sondern nur
Router zu BACnet/IP.
BACnet MS/TP verfügt über eine gute Skalierbarkeit und ermöglicht den wirtschaftlichen Einsatz von AS mit fest eingerichteten GA-Funktionen (z. B. Einzelraumregler, Raumbediengeräte, Frequenzumrichter) ohne Notwendigkeit
weiterer Engineering Tools.
Layer
Protokoll
Anwendungsbereich, Beispiel
1
2
3
4
BACnet
Standard
BACnet MS/TP
Application
Layer
BACnet Application
Protocol
BACnet-Object, BACnet-Service
Network Layer
BACnet Network
Protocol
Netzwerknummer (max. 65.535
Teilnetze) + Device-Adresse
Data Link Layer
BACnet MS/TP
Medium Access Control (MAC),
Bereich 0-254
Physical Layer
EIA-RS485
Zweidrahtleitung, verdrillt,
geschirmt
Standard
ANSI/TIA/EIA485-A-98
Tabelle 4: Strukturübersicht BACnet MS/TP
In MS/TP-Netzwerken werden MAC-Adressen im Bereich von 0 - 254 (255 für
Broadcast-Meldungen) verwendet. Die Adresse 0 ist für den MS/TP-Router reserviert. Der Bereich 1-127 kann für Master- und Slave-Devices verwendet werden. Für Slave-Devices sind die Adressen 128-254 reserviert.
BACnet 2007
59
7.4
BACnet LONTalk
Mit BACnet LONTalk (BACnet over LonTalk) ist die Verbindung mehrerer BACnet-Geräte untereinander über ein vorhandenes LON-Netzwerk möglich. Die
Verbindung eines LON-GA-Netzwerks und eines BACnet-Geräts erfordert ein
Gateway.
Der Neuron-Chip besitzt eine feste und eindeutige MAC-Adresse, die Neuron_ID.
Für die BACnet-Adressierung kann alternativ die Subnet/Node-Struktur der
LON-Domäne verwendet werden, wobei dann der Anwender für die eindeutige
Kennung der Knoten verantwortlich ist.
Layer
Protokoll
Anwendungsbereich, Beispiel
1
2
3
Application
Layer
BACnet Application
Protocol
BACnet-Object, BACnet-Service
Network Layer
BACnet Network
Protocol
Netzwerknummer (max. 65.535
Teilnetze) + Device-Adresse
Data Link Layer
Lon-Link Layer
Domain: Subnet/Node
Media Access Control Sublayer
Neuron-ID:
z. B. 00-11-22-33-44-55
Transceiver
Interface
z. B. TP/FTT10
Physical Layer
Tabelle 5: Strukturübersicht BACnet LonTalk
60
Standard
4
BACnet
Standard
LonTalk
7.5 BACnet PTP
Das Punkt-zu-Punkt-Protokoll BACnet PTP (BACnet Point-to-Point-Protokoll)
wird in Verbindung mit EIA/RS-232C (z. B. serielle Schnittstelle am PC) hauptsächlich für Modem-Wählverbindungen verwendet. Die Aufschaltung mehrerer
Modems wird durch den BACnet-Standard nicht abgedeckt und erfordert den
Einsatz einer Software zur Rufnummernverwaltung.
Layer
Protokoll
Anwendungsbereich, Beispiel
1
2
3
Application
Layer
BACnet Application
Protocol
BACnet-Object, BACnet-Service
Network Layer
BACnet Network
Protocol
Netzwerknummer (max. 65.535
Teilnetze) + Device-Adresse
Data Link
Layer
Point-to-Point
(PTP)
Rufnummern, Passwörter,
automatischer Rückruf
Physical Layer
EIA-RS232c
Serielle Verbindung
z. B. zum Wählmodem
Standard
4
BACnet
Standard
Point-to-PointProtokoll
Tabelle 6: Strukturübersicht BACnet PTP
7.6 BACnet-Adressierung
BACnet kann bis zu 65.535 Teilnetzwerke verwalten. Die strukturierte Teilnetzwerknummerierung wird zentral geplant und dokumentiert. Ordnungen nach
Gebäude, Geschoss und/oder Gewerk sind möglich.
Wird ein größerer Adressraum benötigt, erfolgt die Aufteilung in Domänen.
BACnet-Devices können Verbindungen nicht direkt über Domänengrenzen
aufnehmen. Dies muss bei der Planung beachtet werden und kann auch zur
Trennung von Systemen (z. B. Gefahrenmeldeanlagen) genutzt werden. Die
Managementebene führt die Domänen im einheitlichen Bedienkonzept zusammen.
Hinweise für herstellerübergreifende BACnet-Adressierungen und deren
Dokumentation enthält das Dokument B-PAT (BACnet - Project Address
Table) der BIG-EU für das Engineering bei Multi-Vendor-Anlagen.
BACnet 2007
61
7.7
Anschluss an universelle Datennetze
Um zusätzlichen Aufwand für die Errichtung und Unterhaltung paralleler Übertragungsnetze für die Datenkommunikation zwischen den MBE und AS zu
vermeiden, sollen GA-Systeme nach Möglichkeit die vorhandenen Datennetze
(LAN) mitnutzen.
In Sonderfällen (z. B. mangelnde Leistungsreserve oder Verfügbarkeit der Datennetze) ist in Abstimmung mit der nutzenden Verwaltung zu prüfen, ob verfügbare Kapazitäten von Fernmeldeleitungen genutzt werden können.
In gemeinsam genutzten Netzwerken sind die Liefer-, Nachweis- und Haftungsgrenzen sowie die Systemverantwortung der beteiligten Auftraggeber,
Auftragnehmer und Netzwerkbetreiber möglichst klar und eindeutig festzulegen. In Einzelfällen können auch physikalisch getrennte Netzwerke Vorteile
bieten.
Eine möglichst frühzeitige und einvernehmliche Entscheidungsfindung über
die Protokolle und gemeinsamen Übertragungswege wird empfohlen. Bei der
Grundlagenermittlung sollen auch die Abstimmungen mit der IT-Administration beginnen und vor allem folgende Aspekte geklärt werden:
• Benötigte Bandbreite und zulässige Verzögerungen für die GA-Datenübertragung,
• Verfügbarkeit des GA-Subnetzes (auch an Wochenenden und Feiertagen),
• Verfahren und Dauer bei Störungsbeseitigungen,
• Verfahren bei IT-Softwarewartung und GA-Updates,
• Maßnahmen für Netzwerksicherheit und Datenschutz,
• Erforderliches Datenübertragungsprotokoll,
• Erforderliche Netzwerkkomponenten und Leitungen,
• Schnittstellen der Daten- und GA-Netze,
• Zuständigkeitsabgrenzung IT-Administration und GA-Betreiber,
• Vorgaben für die Netzwerk-Nummerierung,
• Vorgaben für die IP-Adressierung, falls nicht automatisch bzw. dynamisch.
62
7.8 Datenschutz gegen Fremdeinwirkungen
Das offene BACnet-Konzept ermöglicht an beliebiger Stelle Zugriffe auf das
GA-Netzwerk. Das BACnet-Protokoll beinhaltet derzeit noch keine geeigneten
Elemente für eine wirksame Sicherheitsarchitektur.
Die gängigen Schutzmechanismen für Datennetze sind bedarfsbezogen zu
nutzen.
Zusätzlicher Schutz vor unberechtigten Anwendungen gilt als Aufgabe der
GA-Programme.
BACnet 2007
63
8
Umsetzungskonzepte
Die wichtigsten Aspekte bei der Umsetzung von BACnet-Systemen werden
hier in Form von Übersichten zusammengefasst.
8.1
Planmäßiges Vorgehen
Einheitliche technische und administrative Vorgaben für GA-Systeme vereinfachen Neubauten, Sanierungen und Ausbauten von Gebäuden, technischen
Anlagen und GA-Systemen erheblich. Der Abstimmungsbedarf der Planer,
Errichter und Betreiber sowie mögliche Kommunikationsprobleme werden
auf ein Minimum reduziert. Die Vorgabe eindeutiger Anschlussbedingungen
ermöglicht auch schrittweise Kopplungen von GA-Geräten unterschiedlicher
Hersteller.
Für BACnet-basierte GA-Systeme sind die Anschlussbedingungen für BACnet-Kopplungen herstellerneutral festzulegen. Sie sollen alle Kennzeichnungssyteme, die grundlegenden GA- und BACnet-Funktionalitäten und die Dokumentationen im Gesamtsystem vereinheitlichen.
Abschnitt 8.2 enthält Empfehlungen für BACnet-Anschlussbedingungen. Sie
müssen bei allen BACnet-Projekten durchgängig vorgegeben, eingerichtet,
dokumentiert und kontrolliert werden.
Auftraggeber sollten an Hand der Empfehlungen ein Lastenheft für die Ausschreibungen von Neubauten oder Sanierungen mit BACnet-Aufschaltungen
erstellen (siehe VDI/VDE 3694).
Verwaltungen mit umfangreichem Bestand an Gebäuden und proprietären
GA-Systemen wird dringend empfohlen, vor weiteren Investitionen ein umfassendes Migrationskonzept zu erstellen (siehe Gebäudeautomation 2005).
Migrationskonzepte ermitteln die Rahmenbedingungen für den Umbau bestehender GA-Systeme in bedarfsgerechte, wirtschaftliche und zukunftssichere
GA-Systeme. Sie ermöglichen Sanierungen und Ausbauten auf der Grundlage
genormter GA-Protokolle und herstellerneutraler Anschlussbedingungen.
Dafür wird der Bestand an Gebäuden, technischen Anlagen, GA-Systemen
und Kommunikationsnetzen erfasst und ausgewertet. Wesentliche Aspekte
des GA-Betriebes und der Personalsituation sowie absehbare Erweiterungen
und Änderungen sind zu berücksichtigen.
64
Auf der Grundlage der Bestandserhebungen werden Konzepte für die Auslegung der GA-Systeme, notwendige Umbauten und spätere Erweiterungen
entwickelt. Die Ergebnisse der Bestandsanalysen, die empfohlenen GA-Maßnahmen und die BACnet-Anschlussbedingungen werden in dem Migrationskonzept zusammenfassend dargestellt.
Abschnitt 8.3 stellt die Kriterien für BACnet-basierte Migrationskonzepte zusammen.
Es ist wichtig, dass das Erarbeiten von Anschlussbedingungen und Migrationskonzepten durch qualifizierte GA-Planer erfolgt, die über einschlägige
Fachkenntnisse und Erfahrungen mit der Realisierung heterogener BACnetSysteme (Multi-Vendor-Anlagen) verfügen. Dies gilt auch für die Planung, Ausschreibung und Abnahme von neuen BACnet-Systemen und für alle BACnetAufschaltungen bei Neubauten, Sanierungen oder Erweiterungen.
8.2
Empfehlungen für BACnet-Anschlussbedingungen
Allgemeine Grundregeln
•Definition einheitlicher, systemweiter Vorgaben für alle GA-Projekte und den
GA-Betrieb,
•Vermeiden von projekt-, produkt- oder firmenspezifischen Festlegungen,
Einschränkungen oder Erweiterungen,
•Vorgaben für die Funktionsbeschreibungen, Automationsschemata und GAFunktionslisten (z. B. Muster nach DIN EN ISO 16484-3 bzw. VDI 3814-1),
•Konformitätsnachweis der BACnet-Komponenten durch ein anerkanntes
Testinstitut,
•Forderung der Abwärtskompatibilität bei Updates von BACnet-Einrichtungen,
•Organisatorische Vorgaben für das Engineering der MBE und der AS bei
Nachrüstungen oder Änderungen der Gebäudeautomation.
Einheitliche Kennzeichnungen
•Einheitlicher Zeichensatz (bei neuen BACnet-Systemen: ISO 8859-1),
•Einheitlicher Adressierungsschlüssel (z. B. nach Gebäudeautomation
2005),
•Einheitliche Zustandstexte und physikalische Einheiten für alle Ein-/Ausgabefunktionen (z. B. nach Anhang 7.4 und 7.5),
•Festlegen der Meldungsklassen und ihrer Zuordnungssystematik (z. B. nach
Anhang 7.6),
BACnet 2007
65
• Beschilderung der Sensoren, Aktoren, Klemmen etc. in Übereinstimmung
mit Adressierungsschlüssel, Funktionsbeschreibung und Automationsschema.
GA-Funktionen
• Angabe der für die herstellerneutrale BACnet-Kommunikation ausgewählten
Daten in GA-Funktionslisten (z. B. nach DIN EN ISO 16484-3 bzw. VDI 3814-1)
und Benennung der für die Gesamtfunktion systemweit erforderlichen Informationen,
• Vorgaben für die Betriebsarten der automatisierten Anlagen,
• Vorgaben für die Abbildung der Informationsinhalte in BACnet-Objekten je
Bauteil-Typ (Pumpen, Ventilatoren, Stellgeräte etc.),
• Vorgaben für wesentliche GA-Funktionen im Gesamtsystem (z. B. Zugriffsberechtigungen, Störungsweitermeldungen, Trendaufzeichnungen, Verbrauchsmessungen, Übersichten, Protokollierung, Archivierung und Datensicherung),
• Verhalten bei Störungen (z. B. Datennetzwerke, GA-Komponenten, technische Anlagen).
BACnet-Funktionen
• Einheitliche Grundausstattung der MBE und AS mit Objekttypen, Properties
und Zugriffsrechten der Gruppe A nach Anhang 4 und BIBBs der Gruppe A
nach Anhang 5,
• Bei Bedarf Vorgabe weiterer Objekttypen, Properties und Zugriffsrechte (z. B.
aus Gruppe B nach Anhang 4) und weiterer BIBBs (z. B. aus Gruppe B nach
Anhang 5) für MBE und AS,
• Generelle und vollständige Unterstützung der BACnet-Funktionen Dynamic
Device Binding, COV Reporting für Wert- und Zustandsänderungen, objektinterne Meldungserzeugung (Intrinsic Reporting) und Zeitsynchronisation,
• Vorgabe, dass die MBE zusätzliche Funktionen wie Algorithmic Reporting
unterstützt,
• Vorgabe, dass nur die geforderten Objekte, Properties und BIBBs bei den
Teilnehmern im BACnet-System eingerichtet werden (keine Hilfsobjekte,
propietäre Objekte oder Properties),
• Angabe, ob und in welchem Umfang der Zugriff von AS zu AS (peer-to-peer)
gefordert oder untersagt wird (z. B. zwecks klarer Systemverantwortung und
eindeutiger Haftungsgrenzen),
• Testinstallation bei erstmaliger Kopplung von BACnet-Geräten unterschiedlicher Hersteller, um die geforderten Funktionen vor Auftragserteilung nachweisen lassen.
66
BACnet-Netzwerk
• Frühzeitige Abstimmung mit der IT-Administration,
• Verwendung von BACnet/IP gemäß Annex J der BACnet-Spezifikation,
• Netzwerkstruktur mit 24h Verfügbarkeit für GA und eigenen, geschützten
Netzsegmenten bei Integration in Datennetzwerken (VLAN),
• Segmentierungsvorgaben bei unterschiedlichen Netzsegmenten,
• Einbau und Bedienung eines BACnet-Protokoll-Analysators.
Dokumentation und Lizenzen
• Vorgaben für den systemweit einheitlichen Aufbau und Inhalt der Dokumentationen der GA-Systeme (z. B. nach „Gebäudeautomation 2005“),
• Vollständige und aktuelle Dokumentation der GA-Anlagen in deutscher Sprache (z. B. alle GA-Funktionslisten, EDE-Dateien, Listen der verwendeten
Objekte und Properties, Lizenzen, Passworte, Schulungen, Bedienungs-,
Wartungs- und Instandhaltungsanleitungen) bei jeder Neubaumaßnahme,
Sanierung oder Erweiterung,
• Übergabe uneingeschränkter Nutzungsrechte an allen zur Systemerstellung
benötigten Software-Tools und allen projektspezifischen Programmen (einschließlich der kommentierten Quellprogramme),
• Fortschreibung der Dokumentation im laufenden Betrieb (z. B. bei Nutzungsänderungen, Betriebsoptimierungen, Software-Updates).
8.3 Kriterien für BACnet-basierte Migrationskonzepte
Gebäude
• Gebäudebestand
• Eingeleitete und künftig beabsichtigte Bauvorhaben
• TGA- und GA-Relevanz der Gebäude (z. B. 3 Stufen: hoch, mittel, gering)
• Übersichten mit Bezeichnungen, Nutzungen, Flächen
• Lagepläne
Technische Gebäudeausrüstung (TGA)
• Vorhandene TGA
• Anlagenschemata der TGA
• Restnutzungsdauer, Wirtschaftlichkeit der Altanlagen
• Vorhandene und fehlende GA-Anschlüsse
GA-Systeme
• Übersichtsschemata vorhandener GA-Systeme
• Verwendbare MSR- / GA-Ausstattung
• Verwendbare AS und MBE (Fabrikate, Schnittstellen)
BACnet 2007
67
• Anlagenbilddarstellungen in der MBE (Beispiele und Muster)
• Vorhandene technische Anschlussbedingungen
• Vorhandene Adressierungs- und Bezeichnungssysteme
• Verwendbare Kommunikationsverbindungen
GA-Ausbau
• Grundanforderungen / Grundstruktur / Offene Kommunikation
• Leistungsfähigkeit und Kapazität
• Listen der physikalischen Ein- und Ausgänge
• Anzahl und Ausstattungsmerkmale verwendbarer Feldgeräte
• Anzahl und Ausstattungsmerkmale neuer Feldgeräte
• Schnittstellen zu nutzerspezifischen Anlagen und anderen Gewerken
• Schnittstellen zu IT-Systemen (CAFM, Nebenkostenabrechnungen etc.)
• Festlegung der Kommunikations- und Übertragungsprotokolle
Management- und Bedieneinrichtungen (MBE)
• Mindestanforderung der Hardware
• Bediensoftware / Visualisierung
• Datenbank
• Fernbedienung der AS (Vollbedienung, Teilbedienung)
• Störungsmanagement
• Verbrauchsdatenerfassung
• Instandhaltungsmanagement
• Projektierung
• Inbetriebnahme
Automationsstationen (AS)
• Anforderungen an BACnet-AS
• Integration/Bereitstellung vorhandener GA-Funktionen
• Engineering
• Inbetriebnahme
BACnet-Anschlussbedingungen
• Einheitliche Kennzeichnungen
• Liste wesentlicher GA- und BACnet-Funktionen (PICS, EDE-Listen, B-PAT)
• Liste geforderter BACnet-Objekte, Properties und Lese-/Schreibrechte
• Liste geforderter Dienste / BIBBs (nach Funktionsgruppen)
• Sonstige geforderte Dokumente (z. B. PICS für neue AS)
• Zertifizierung neuer BACnet-Geräte
• Testinstallation bei erstmaliger Geräte-Kopplung unterschiedlicher Hersteller
• BACnet-Protokoll-Analysator
• Dokumentation (Aufbau, Pflege bei Neubauten und im Betrieb)
68
Datenübertragungsnetze
• Verwendbare Datenübertragungssysteme
• Leitungsnetze, Trassenführungen, aktive Netzwerkkomponenten
• Netzwerktopologie, Netzwerksegmentierung, Addressierung
• Netzwerkprotokolle
• Netzwerksicherheit (Firewall)
• Anschlussbedingungen, Port-Freischaltungen (z. B. IT-Administration)
• Besonderheiten beim Einsatz von BACnet
Personalplanung und Dienstleistungen
• Anforderungen an den Betrieb von BACnet-basierten GA-Systemen
• Vorhandenes und künftiges GA-Betriebspersonal (Anzahl, Qualifikation)
• Schulung des GA-Betriebspersonals (Hersteller, VDI etc.)
• Instandhaltung GA, Wartung MSR
• Softwarepflege
• GA- und TGA-Dokumentation
Zeitplanung
• Sofortmaßnahmen (z. B. herstellerneutrale MBE bei Neubau oder Sanierung)
• Mittelfristige GA-Sanierungen (z. B. neue AS, Integration vorhandener TGA),
• Ziele für langfristige GA-Sanierungen (z. B. bei TGA-Sanierungen)
Finanzplanung
• Benötigter Kostenrahmen
• Sofortmaßnahmen
• mittelfristige Finanzplanung
Zusammenfassende Handlungsempfehlung
8.4 Anwendungsprobleme und Verbesserungsvorschläge
Wenn in Ausschreibungen nur gefordert wird, dass bestimmte GA-Funktionen
möglich sein müssen, führt das nicht in jedem Fall dazu, dass diese GA-Funktionen im aktuellen Projekt ausgeführt werden. Es ist vorzugeben, dass die
geforderten GA-Funktionen eingerichtet werden und bei der Abnahme funktionsfähig und prüfbar sein müssen. Alternativ kann für bestimmte GA-Funktionen eine Nachrüstbarkeit oder spätere Ausbaufähigkeit gefordert werden.
BACnet 2007
69
Die nachfolgende Auswahl praktischer Beispiele soll die Aufmerksamkeit für
mögliche weitere Anwendungsprobleme und ihre Folgewirkungen erhöhen:
• Die Prioritätensteuerung eines physikalischen Ausganges erfolgt durch Einsatz eines oder mehrerer BACnet-Objekte anstatt mit dem Property „Kommando-Prioritäten“ (Priority_Array). Die Lösung ist nicht zu akzeptieren, da
sie keine Standardlösung darstellt und zur Erhöhung der Anzahl von BACnet-Objekten mit entsprechenden Mehrkosten führt.
• Das Property „Einheiten“ (Unit) existiert, wird jedoch nicht eingerichtet oder
kann nicht eingerichtet werden. Dies ist nicht zu akzeptieren, da die GAFunktion eingeschränkt ist und Mehraufwand bei der nachträglichen Aktivierung entsteht.
• Die Properties für Zustandstexte sind nicht oder unvollständig eingerichtet,
so dass bei der Anzeige des Properties „Aktueller Wert“ (Present_Value)
kein Wert angezeigt wird. Dies ist nicht zu akzeptieren, da die GA-Funktion
eingeschränkt ist und Mehraufwand bei der nachträglichen Aktivierung entsteht.
• Es ist nur eine Instanz des Meldungsklassenobjektes (Notification Class Object) in der AS möglich oder es wird nur eine oder keine eingerichtet. Dies
ist nicht zu akzeptieren, da die GA-Funktion eingeschränkt ist und Mehraufwand bei der späteren Nachbearbeitung entsteht.
• Physikalische Ausgänge werden als BACnet Eingabeobjekte dargestellt und
sind so nicht übersteuerbar. Dies ist nicht zu akzeptieren, da die Zuordnung
nicht normkonform erfolgt und die geforderte Übersteuerung nicht möglich
ist.
• Bei der erstmaligen Kopplung von BACnet-Geräten unterschiedlicher Hersteller ist die Interoperabilität trotz Normenkonformität im Einzelfall gestört
(z. B. infolge von Missverständnissen, mehrdeutigen Aussagen oder Lücken
der BACnet-Norm). Solche Störungen sind mit Hilfe einer Testinstallation vor
Auftragserteilung zu klären.
Hinweise auf Grundsatzprobleme (z. B. Interoperabilitäts-Störungen bei BACnet-Kopplungen) oder Verbesserungsvorschläge für die vorliegende Empfehlung (z. B. Ergänzung der Anhänge) können der AMEV-Geschäftsstelle mitgeteilt werden ([email protected]). Diese wird die Information weiterleiten
an den Arbeitskreis Gebäudeautomation des AMEV.
70
Anhang 1
BACnet
Object Type
(Norm)
1
BACnet-Objekttypen: Übersicht
BACnetObjekttyp
(deutsch)
2
Erläuterung
3
Object
Type
Code
4
Access
Credential
Authentifikationsdaten für
Zutritt
Objekt für Zutrittskontrollsysteme:
Beschreibt die Authentifikationsdaten wie PIN, Karte,
biometrische Merkmale
Access
Door
Zugangstür
Objekt für Zutrittskontrollsysteme:
Repräsentiert eine Tür oder ein Tor
Access
Point
Zutrittskontrollpunkt
Objekt für Zutrittskontrollsysteme:
Zugang bzw. Eingang, an dem Authentifizierung und
Autorisierung stattfinden
33
(Vorentwurf)
Access
Rights
Zutrittsberechtigungen
Objekt für Zutrittskontrollsysteme:
Beschreibt Zutrittsrechte (z.B. Zeitfenster, Bedingungen)
34
(Vorentwurf)
Access
User
Zutrittsberechtigte
Objekt für Zutrittskontrollsysteme:
Beschreibt Einzelpersonen, Gruppen etc., denen Berechtigungen zugeordnet sind
35
(Vorentwurf)
Access
Zone
Zugangsbereich
Objekt für Zutrittskontrollsysteme:
Beschreibt die gesicherte Zone mit ihren Ein- und Austrittspunkten (z. B. in einem Gebäude)
36
(Vorentwurf)
Accumulator
(ACC)
Zählwerteingabe
Aufsummieren von Impulsdaten von Messgeräten über
die Zeit. Geeignet für Bilanzierung, Abrechnung und
Energie-Lastmanagement (für Intervall-Mengenzählung
siehe Pulse Converter)
23
(ANSI)
Analog
Input
(AI)
Analogeingabe
Messen
(z. B. Messwert aus Temperaturmessung)
0
Analog
Output
(AO)
Analogausgabe
Stellen
(z. B. Stellbefehl für Regelventil)
1
Analog
Value
(AV)
Analogwert
Analogwert
(z. B als Ergebnis einer Rechenoperation)
2
Authentication Factor
Input
Authentifizierungseingaben
Objekt für Zutrittskontrollsysteme:
Eingabegeräte für Authentifikationsdaten (z. B. Kartenleser, PIN-Eingabegeräte, biometrische Systeme)
37
(Vorentwurf)
Averaging
(AVG)
Mittelwert
Objekt mit den Statistikfunktionen Minimum, Maximum,
Mittelwert und Varianz
18
BACnet 2007
32
(Vorentwurf)
30
(ASHRAE
Revision)
71
BACnet
Object Type
(Norm)
1
BACnetObjekttyp
(deutsch)
Erläuterung
2
3
Object
Type
Code
4
Binary Input
(BI)
Binäreingabe
Melden binärer Zustände
(z. B. Betriebs-, Störungs- oder Alarmmeldung)
3
Binary
Output
(BO)
Binärausgabe
Schalten, Stellen
(z. B. Schaltbefehl Ein/Aus, Stellbefehl Auf/Zu)
4
Binary
Value (BV)
Binärwert
Binärer Wert
(z. B. aus logischer Verknüpfung errechnet)
5
Calendar
(CAL)
Kalender
Betriebskalender
(z. B. Feiertags- und Ferienliste)
6
Command
(CMD)
Gruppenauftrag
Auftrag (Kommando) zur Ausführung (mehrerer) vordefinierter Aktivitäten durch andere Objekte
7
Device
(DEV)
Gerät
System-Grundparameter zur Beschreibung des BACnetTeilnehmers (AS, MBE oder andere Einrichtung)
8
Event Enrollment
(EE)
Ereigniskategorie
System-Grundparameter zur Festlegung der Kriterien
für die Ereignismeldung mittels Algorithmic Change
Reporting
9
Event Log
(ELOG)
Ereignisaufzeichnung
Objekt zum Übertragen einer Liste mit ereignisbezogenen Werten und Zeitstempeln
25
(ASHRAE
Revision
File (FIL)
Datei
Objekt für Datei-Übertragung
(z. B. Programm, Datensicherung, Archivierung)
10
Global
Group
(GGRP)
Globale
Gruppeneingabe
Objekt zur Gruppierung von lesbaren Properties beliebiger Objekte im gesamten GA-Netzwerk
26
Group
(GRP)
Gruppeneingabe
Objekt zur Gruppierung von lesbaren Properties beliebiger Objekte im selben Device
11
Life Safety
Point (LSP)
Gefahrenmelder
Objekt, das Informationen über die Properties für Gefahrenmelde-Anwendungen im Netzwerk enthält
21
Life Safety
Zone (LSZ)
Sicherheitsbereich
Objekt zur Zusammenfassung von Gefahrenmelderobjekten (z. B. für Brandmeldelinien, Brandabschnitte,
Nebenmeldezentralen)
22
Lighting
Control
Beleuchtungssteuerung
Objekt zur Ansteuerung von Beleuchtungsanlagen
Load
Control
Laststeuerung
Funktion zur Steuerung des Lastmanagements
Loop(LP)
Regler
Objekt für Reglerfunktionen
(z. B. PID-Regler)
72
31
(Vorentwurf)
28
(ASHRAE
Revision)
12
BACnet
Object Type
(Norm)
1
BACnetObjekttyp
(deutsch)
Erläuterung
2
3
Object
Type
Code
4
Multi-state
Input (MI)
Mehrstufige
Eingabe
Melden mehrstufiger Zustände
Meldezustände sind als Zahl kodiert
(z. B. Meldung: Aus, Stufe 1, Stufe 2, … )
13
Multi-state
Output
(MO)
Mehrstufige
Ausgabe
Schalten, Stellen
Ausgabezustände sind als Zahl kodiert
(z. B. Schaltbefehl: Aus, Stufe 1, Stufe 2, ... )
14
Multi-state
Value
(MV)
Mehrstufiger
Wert
Mehrstufiger Wert
(z. B. als berechneter Wert)
19
Notification
Class
(NC)
Meldungsklasse
Objekt für die zeitbezogene Zuordnung von Alarm- und
Ereignismeldungen
15
Program
(PR)
Programm
Objekt zur Steuerung von Programmen in einem
BACnet-Device
(z. B. Laden und Starten)
16
Pulse Converter
(PC)
Impulskonverter
Objekt zur Umsetzung von lmpulsen für die Mengenzählung in festgelegten Zeitintervallen (nicht geeignet
für Abrechnungszwecke, siehe Akkumulatorobjekt)
Schedule
(SCHED)
Zeitplan
Objekt zur Ausführung wiederkehrender Aktivitäten und
Festlegung einmaliger Ausnahmen
17
Structured
View
Objektstrukturansicht
Objekt zur Unterstützung der Darstellung von Objektbeziehungen untereinander (z. B. zur Erleichterung der
Festlegung von Geräteprofilen)
29
(ANSI)
Trend Log
(TLOG)
Trendaufzeichnung
Objekt zur Trendaufzeichnung in einem BACnet-Gerät
(z. B. AS)
20
Trend Log
Multiple
(TLOGM)
Mehrfachtrendaufzeichnung
Objekt zur Trendaufzeichnung für mehrere Werte
auch geräte- und netzwerkübergreifend
BACnet 2007
24
(ANSI)
27
(ANSI)
73
74
Schaltbefehl 1-stufig
Schaltbefehl n-stufig
Kontaktgeber
Messwertgeber
mit Grenzwert
Klappenantrieb Auf/Zu
Klappenantrieb Auf/Zu
(z. B. motorische
Entrauchungsklappe)
2
3
4
5
6
7
Unterer Grenzwert
3
Auf-/Zufahren
Rückmeldung Auf/Zu
1
2
Auf-/Zufahren
Oberer Grenzwert
2
1
Istwert erfassen
Zustandsänderungen
zählen
1
Zustand erfassen
2
Betriebsstunden (gesamt)
3
1
Rückmeldung n-stufig
2
Betriebsstunden erfassen
3
Ein-/Ausschalten (n Stufen)
Rückmeldung Ein/Aus
2
1
Ein-/Ausschalten
Betriebsstunden erfassen
3
1
Betriebszustand melden
2
4
Ein-/Ausschalten
GA-Funktion
1
3
Nr.
Binäre Eingabe Melden
Binäre Ausgabe Schalten
Binäre Ausgabe Schalten
Grenzwert fest
Grenzwert fest
Analoge Eingabe Messen
Anzahl Zustandsänderungen
Binäre Eingabe Melden
Betriebsstundenerfassung
Binäre Eingabe Melden
Binäre Ausgabe Schalten
Betriebsstundenerfassung
Binäre Eingabe Melden
Binäre Ausgabe Schalten
Betriebsstundenerfassung
Binäre Eingabe Melden
Binäre Ausgabe Schalten
5
Bezeichnung (VDI 3814-1)
GA-Aufgabe (DIN EN ISO 16484-3 bzw. VDI 3814-1)
Gesamtanlage
2
Anlagenteil
Objekttypen und GA-Funktionen (Zuordnungsbeispiele)
1
1
Nr.
Anhang 2
6
7
BV
BV
BI
BO
BI
BV
MI
MO
AI
2
1
1
BI
BO
BO
Teil von AI
Teil von AI
1
Teil von BI
1
1
1
1
Teil von BO
1
1
Teil von BV
1
1
Art
R
W
W
W
W
R
W
R
W
R
W
W
R
W
W
R
W
8
R/W
BACnet-Objekttyp
Anz.
9
Rückmeldung Auf/Zu
Auf/Zu
ohne Rückmeldung
Change_of_State_
Count
z. B. Niveauschalter
z. B. Aus/St.1/St.2
z. B. Ein/Aus
virtuell
virtuell
Hinweise
BACnet 2007
75
Regelventil/Klappenantrieb stetig
Regelventil/Klappenantrieb stetig
Regelventil/Klappenantrieb stetig
Pumpe/Ventilator
1-stufig
(z. B. HZG, KLT, RLT,
SAN)
Pumpe/Ventilator
2-stufig
(z. B. HZG, KLT, RLT,
SAN)
Frequenzumformer
8
9
10
11
12
13
Ein-/Ausschalten
Betriebsstunden erfassen
Betriebsbereitschaft melden
Sollwertvorgabe
Istwert anzeigen
Störungsmeldung
3
4
5
6
Motorstörung melden
4
2
Betriebsstunden (gesamt)
3
1
Betriebsmeldung (je Stufe)
Motorstörung melden
4
Ein-/Ausschalten (2 Stufen)
Betriebsmeldung
3
2
Betriebsstunden erfassen
2
1
Ein-/Ausschalten
Rückmeldung Stellung
2
1
Stellbefehl
Rückmeldung Auf/Zu
2
1
Stellbefehl
Stellbefehl
1
1
Binäre Eingabe Melden
Analoge Eingabe Messen
Analoge Ausgabe Stellen
Binäre Eingabe Melden
Betriebsstundenerfassung
Binäre Ausgabe Schalten
Binäre Eingabe Melden
Betriebsstundenerfassung
Binäre Eingabe Melden
Binäre Ausgabe Schalten
Binäre Eingabe Melden
Binäre Eingabe Melden
Betriebsstundenerfassung
Binäre Ausgabe Schalten
Analoge Eingabe Messen
Analoge Ausgabe Stellen
Binäre Eingabe Melden
Analoge Ausgabe Stellen
Analoge Ausgabe Stellen
BO
AI
AO
BI
AO
AO
BO
BI
BV
MI
MO
BI
BI
1
1
1
1
BI
AI
AO
BI
Teil von BO
1
1
1
1
1
1
1
Teil von BO
1
1
1
2
1
1
R
R
W
R
W
W
R
W
R
W
R
R
W
W
R
W
R
W
W
Rückmeldung 0-100%
0 - 100%
Rückmeldung Auf/Zu
0 - 100%
0 - 100%,
ohne Rückmeldung
76
2
Kaltwassersatz
1-stufig
(Kleinanlagen, einfache
Ausführung)
Kaltwassersatz
n-stufig
Pumpe Hebeanlage
Lokale Vorrangbedienung
Allgemein
Allgemein
Allgemein
Allgemein
Allgemein
Zähler
(mit Buskopplung)
15
16
17
18
19
20
21
22
23
1
1
1
1
1
1
Zählwert erfassen
Betriebsstunden erfassen
Sammelstörmeldung
Rückmeldung analog
Rückmeldung binär
Stellbefehl
Umschaltung Auto/Hand
Niveau überschritten
3
1
Motorstörung melden
2
Störung melden
4
Betriebsbereitschaft melden
Betriebsstunden (gesamt)
1
Betriebszustände melden
3
Sammelstörmeldung
5
2
Betriebsmeldung
4
Ein-/Ausschalten (n Stufen)
Betriebsbereitschaft melden
3
1
Betriebsstunden erfassen
2
4
Ein-/Ausschalten
GA-Funktion
1
3
Nr.
Eingabe Zählwert
Betriebsstundenerfassung
Binäre Eingabe Melden
Analoge Eingabe Messen
Binäre Eingabe Melden
Analoge Ausgabe Stellen
Binäre Eingabe Melden
Binäre Eingabe Melden
Binäre Eingabe Melden
Binäre Eingabe Melden
Binäre Eingabe Melden
Betriebsstundenerfassung
Binäre Eingabe Melden
Binäre Ausgabe Schalten
Binäre Eingabe Melden
Binäre Eingabe Melden
Binäre Eingabe Melden
Betriebsstundenerfassung
Binäre Ausgabe Schalten
5
Bezeichnung (VDI 3814-1)
GA-Aufgabe (DIN EN ISO 16484-3 bzw. VDI 3814-1)
1
Anlagenteil
14
Nr.
6
7
BO
BI
AI
BI
AO
BI
BI
BI
BI
BI
BV
MI
MO
BI
BI
BI
1
AV
Teil von
BI/BO/BV
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
Teil von BO
1
Art
R
W
R
R
R
W
R
R
R
R
R
W
R
W
R
R
R
W
W
8
R/W
BACnet-Objekttyp
Anz.
kommunikative
E/A-Funktion
Umschaltung melden
Max-Alarm
9
Hinweise
BACnet 2007
77
Zähler (mit Impulszählung und Verknüpfung
über Anw.Prog.)
Wochenschaltplan
Jahresschaltplan
Feiertage
Jahresschaltplan
Ferien
Regler mit Sollwertverstellung
24
25
26
27
28
PI/PID-Regelung
Sollwertverstellung
Parametereinstellung
Grenzwert gleitend
(Regelabweichung)
2
3
4
Liste der Ferienzeiten
Liste der Feiertage
1
1
1
Schalt-/Stellbefehle je Tag
Zählwert erfassen
2
1
Impulseingang zählen
1
Grenzwert gleitend
PI/PID-Regelung
Zeitabhängiges Schalten
Zeitabhängiges Schalten
Zeitabhängiges Schalten
Eingabe Zählwert
Binäre Eingabe Zählen
BI
LP
CAL
CAL
SCHED
BV
Teil von LP
Teil von LP
Teil von LP
1
1
1
1
1
1
W
W
W
W
W
W
W
R
R
in Verbindung mit
SCHED
in Verbindung mit
SCHED
z. B. 3x Ein/Aus je Tag
Anhang 3
Objekttypen: Anwendungsbeispiel RLT-Anlage
Anhang 3.1
Anlagenschema RLT-Anlage (Beispiel)
78
BACnet 2007
79
Außentemperatur
FO-Klappe
AU-/UM-Klappe
ZU-Filter
2
3
4
5
Gleitendes Ein-/Ausschalten
Nachtkühlbetrieb
Netzwiederkehrprogramm
Höchstlastbegrenzung
8
9
10
11
Melden (Binäreingabe)
Meldungsbearbeitung
2
Lokale Vorrangbedienung
3
1
Melden (Binäreingabe)
2
Lokale Vorrangbedienung
3
Stellen (Analogausgabe)
Melden (Binäreingabe)
2
1
Stellen (Analogausgabe)
1
Grenzwert fest
Zeitabhängiges Schalten
7
2
Zeitabhängiges Schalten
6
Messen (Analogeingabe)
Anw.Prog.
Anlagensteuerung
5
1
Anw.Prog.
Melden (Binäreingabe)
4
BV
AI
Anw.Prog.
Anw.Prog.
CAL
SCHED
Anw.Prog.
1
1
2
1
1
2
1
Anw.Prog.
BI
BI
BI
AO
BI
BI
AO
Teil von AI
1
1
1
1
Teil von BV
BV
Betriebsstundenerfassung
1
Melden (Binäreingabe)
6
MV
3
5
1
Art
Objekttyp
2
4
Anz.
Schalten mehrstufig
3
GA-Funktion (VDI 3814-1)
1
2
Gesamtanlage
Nr.
Anlagenteil
GA-Aufgabe (DIN EN ISO 16484-3, VDI 3814-1)
R
R
R
W
R
R
W
W
R
W
W
R
W
R
W
7
R/W
Zeitverzögerung
Umschaltung Auto/Hand melden
Endlagen Auf-Zu
0 - 100 %
Umschaltung Auto/Hand melden
Endlagen Auf-Zu
0 - 100 %
z. B. 6 °C: Schalten VE-Pumpe
Virtuelle Adresse AS …
div. Kalendertage
2 Zeitplaneinträge: Ein, Aus
Ausschalten durch 9,11,12,14,15,17,18,20
Störmeldung
Betriebsmeldung
8
Hinweise
Auto/Aus/Stufe 1/Stufe 2
Zuordnung der GA-Funktionen und Objekttypen (RLT-Anlage)
1
1
Nr.
Anhang 3.2
80
VE-Regelventil
VE-Rücklauftemperatur
VE-Frostschutzwächter
ZU-Ventilator 2-stufig
Rep.-Schalter ZU-Vent.
Laufüberwachung
ZU-Ventilator
7
8
9
10
11
12
Betriebsstundenerfassung
Störmeldung
Befehlsausführkontrolle 2x
Lokale Vorrangbedienung
Motorsteuerung
3
4
5
6
7
Melden
Meldungsbearbeitung
1
2
Melden
Betriebsmeldungen
1
Schalten 2x
2
Frostschutzsteuerung
1
Melden (Binäreingabe)
2
Messen (Analogeingabe)
1
1
Lokale Vorrangbedienung
Motorsteuerung
7
3
Lokale Vorrangbedienung
6
Unterer Grenzwert fest
Betriebsmeldung
5
2
Störmeldung
4
Stellen (Analogausgabe)
Befehlsausführkontrolle
3
1
Betriebsstundenerfassung
2
4
Schalten (Binärausgabe)
3
GA-Funktion (VDI 3814-1)
1
2
VE-Pumpe
Nr.
Anlagenteil
GA-Aufgabe (DIN EN ISO 16484-3, VDI 3814-1)
6
1
Nr.
BO
6
Art
Objekttyp
AO
Anw.Prog.
BI
BI
BI
1
1
1
1
1
1
1
1
1
1
Anw.Prog.
BI
BI
Anw.Prog.
BI
Anw.Prog.
BI
BI
MI
MO
Anw.Prog.
BI
AI
BI
Teil von AO
1
1
1
1
Teil von BO
Teil von BO
1
5
Anz.
R
R
R
R
W
R
W
R
R
R
W
W
R
R
R
R
W
W
7
R/W
Zeitverzögerung
Abschaltung Gesamtanlage
Abschaltung Gesamtanlage
Umschaltung Auto/Hand melden
Vergleich MO mit MI
Summe Stufe 1 + Stufe 2
Umschaltung Auto/Hand melden
< 3% Abschaltung VE-Pumpe
Stellung Ventil
Blockierschutz enthalten
Umschaltung Auto/Hand melden
Ein/Aus
Vergleich BO mit BI
8
Hinweise
BACnet 2007
81
AB-Ventilator 2-stufig
Rep.-Schalter AB-Vent.
Laufüberwachung
AB-Ventilator
Zulufttemperatur
Brandschutzklappe ZU
Brandschutzklappe AB
Raumtemperatur
Handschalter im Raum
Max-Auswahl
Regler
VE-Rücklauftemperatur
Sollwert
Zulufttemperatur
Regler
Zulufttemperatur
Regler
Raumlufttemperatur
13
14
15
16
17
18
19
20
R1
R2
R3
R4
R5
Betriebsstundenerfassung
Störmeldung
Befehlsausführkontrolle 2x
Lokale Vorrangbedienung
Motorsteuerung
3
4
5
6
7
Sollwert
3
Sequenz Klappen-Lufterw.
3
PI/PID-Regelung
Begrenzung Stellgröße
2
1
PI/PID-Regelung
1
Sollwertführung/-kennlinie
Stellausgabe stetig
2
1
P-Regelung
Arithmetische Berechnung
1
1
Mehrstufige Eingabe (Melden)
Grenzwert gleitend
2
1
Messen
Melden (Klappe ausgelöst)
1
1
Melden (Klappe ausgelöst)
Grenzwert fest
2
1
Messen
Meldungsbearbeitung
2
1
Melden
1
Melden
Betriebsmeldungen
2
1
Schalten 2x
1
AI
Anw.Prog.
BI
BI
Anw.Prog.
BI
Anw.Prog.
BI
BI
MI
MO
AI
BI
BI
LP
Anw.Prog.
MI
1
1
1
1
LP
Anw.Prog.
Anw.Prog.
LP
LP
AV
Teil von LP
1
1
Teil von AI
1
1
1
Teil von A0
1
1
1
1
1
1
1
1
W
W
W
W
W
W
R
W
R
R
R
W
R
R
R
R
R
W
R
W
Istwert: 19.1, Sollwert: R3.1,
Stellgröße: Sollwert für R4.1
Norm: Zeile 16 (ZU-Temperatur)
Norm : Zeile 4 (AU-/UM-Klappe)
Istwert: 16.1, Sollwert: R5.1, Stellgröße: 3.1 + 4.1
Eingangswert: 2.1
Frostschutz RL; Istwert: 8.1
Maximalwert von R2.1 u. R4.1
Lokal: Auto/Aus/Stufe 1/Stufe 2
Abschaltung Gesamtanlage
Abschaltung Gesamtanlage
<12 °C; > 28 °C: Störmeldung
Zeitverzögerung
Abschaltung Gesamtanlage
Abschaltung Gesamtanlage
Umschaltung Auto/Hand melden
Vergleich MO mit MI
Summe Stufe 1 + Stufe 2
Objektname
Objekttyp
Systemstatus
Gerätehersteller Name
Gerätehersteller Nummer
Modellbezeichnung BACnet-Gerät
Firmware-Revisions-Stand
Anwendungsprogramm Version
Einbauort
Objektbeschreibung
Protokoll-Version
Protokoll-Revison
Unterstützte BACnet-Dienste
Unterstützte BACnet-Objekttypen
Object_Name
Object_Type
System_Status
Vendor_Name
Vendor_Identifier
Model_Name
Firmware_Revision
Application_Software_Version
Location
Description
Protocol_Version
Protocol_Revision
Protocol_Services_Supported
Protocol_Object_Types_Supported
2
Bezeichnung der Objektinstanz
Object_Identifier
1
Property
(deutsche Bezeichnung)
Objekttyp Gerät
Anhang 4.1
Property Identifier
(Norm)
Empfohlene Objekttypen, Properties und Zugriffsrechte
Anhang 4
3
R/W (Norm)
R
R
R
R
O
O
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
4
R/W (AMEV)
82
5
Gruppe MBE (AMEV)
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
6
Gruppe AS (AMEV)
Beschreibung des Objekts muss
konfiguriert und lesbar sein
Einsatzort des Devices muss konfiguriert und lesbar sein
siehe Anhang 7.3
7
Weitere Hinweise
Legende für Spalte 5 und 6:
A: Grundausstattung
B: Ergänzungsausstattung
0: Property nicht gefordert
BACnet 2007
83
Objekt-Liste
Maximal verarbeitbare APDU-Länge
Segmentierungsunterstützung
Maximale Zahl angenommener Segmente
Unterstützte VT-Klassen (Virtual
Terminal)
Aktive VT-Sitzungen
Lokale Zeit
Lokales Datum
Zeitverschiebung gegen UTC
Sommerzeit-Status
APDU-Segment-Zeitüberschreitung
APDU-Zeitüberschreitung
Anzahl der APDU-Übertragungsversuche
Liste der Sitzungskennzeichen
Empfänger der Zeitsynchronisation
Maximale Anzahl von Master-Knoten
Maximale Anzahl von Datenpaketen
Geräteadressen-Verknüpfung
Datenbank-Revisionsnummer
Object_List
Max_APDU_Length_Accepted
Segmentation_Supported
Max_Segments_Accepted
VT_Classes_Supported
Active_VT_Sessions
Local_Time
Local_Date
UTC_Offset
Daylight_Savings_Status
APDU_Segment_Timeout
APDU_Timeout
Number_Of_APDU_Retries
List_Of_Session_Keys
Time_Synchronization_Recipients
Max_Master
Max_Info_Frames
Device_Address_Binding
Database_Revision
R
R
O
O
O
O
R
R
O
O
O
O
O
O
O
O
R
R
R
R
R
R
R
R
R
R
R
R
W
R
W
W
R
R
R
R
R
R
A
A
B
B
A
0
A
A
A
A
A
A
A
0
0
A
A
A
A
A
A
B
B
A
0
A
A
A
A
A
A
A
0
0
A
A
A
A
nur notwendig bei Nutzung von
MS/TP
nur notwendig bei Nutzung von
MS/TP
notwendig für Zeitsynchronisation
Nutzung von Virtual Terminal Diensten nicht vorgesehen
notwendig für Segmentierung
Sommerzeitstatus muss vorhanden
und synchronisierbar sein
notwendig für Nutzung von UTC
Uhrzeit muss vorhanden und synchronisierbar sein
Uhrzeit muss vorhanden und synchronisierbar sein
Nutzung von Virtual Terminal Diensten nicht vorgesehen
Nutzung von Virtual Terminal Diensten nicht vorgesehen
notwendig für Segmentierung
84
Konfigurationsdateien
Letzter Rückspeicher-Zeitpunkt
Backup-Fehler-Zeitüberschreitung
Aktive COV-Abonnements
Slave-Proxy-Fähigkeit
Manuelle MS/TP-Slave-Adressverknüpfung
Autom. Slave-Erkennung am MS/TPPort
MS/TP-Slave-Adressverknüpfung
Profil-Name
Last_Restore_Time
Backup_Failure_Timeout
Active_COV_Subscriptions
Slave_Proxy_Enable
Manual_Slave_Address_Binding
Auto_Slave_Discovery
Slave_Address_Binding
Profile_Name
2
Property
(deutsche Bezeichnung)
Configuration_Files
1
Property Identifier
(Norm)
3
R/W (Norm)
O
O
O
O
O
O
O
O
O
4
R/W (AMEV)
R
R
R
R
R
W
R
R
R
5
Gruppe MBE (AMEV)
0
B
B
B
B
A
A
A
A
0
B
B
B
B
A
A
A
A
6
Gruppe AS (AMEV)
soll nicht genutzt werden
nur notwendig bei Nutzung von
MS/TP
nur notwendig bei Nutzung von
MS/TP
nur notwendig bei Nutzung von
MS/TP
nur notwendig bei Nutzung von
MS/TP
notwendig für COV-Fähigkeit
notwendig für Backup/Recovery
notwendig für Backup/Recovery
notwendig für Backup/Recovery
7
Weitere Hinweise
Legende für Spalte 5 und 6:
A: Grundausstattung
B: Ergänzungsausstattung
0: Property nicht gefordert
Bez. der Objektinstanz
Objekttyp
Objektname
Aktueller Wert
Objektbeschreibung
Bezeichnung der phys.
Ein/Ausgabeeinheit
Zustandsangaben
Ereignis-Zustand
Verlässlichkeit
Objektfunktion außer
Betrieb
Aktualisierungszeit
Physikalische Einheit
Obere Bereichsgrenze
Untere Bereichsgrenze
Auflösung
Object_Type
Object_Name
Present_Value
Description
Device_Type
Status_Flags
Event_State
Reliability
Out_Of_Service
Update_Interval
Units
Max_Pres_Value
Min_Pres_Value
Resolution
2
Property
(deutsche Bezeichnung)
Object_Identifier
1
Property Identifier
(Norm)
3
R/W (Norm)
O
O
O
R
O
R
O
R
R
O
O
R
R
R
R
4
Analog Input
5
Analog Output
R
R
R
6
Analog Value
R
R
R
7
R
R
R
8
R
R
R
9
R
R
R
Multi-State Input
R
R
R
10
Multi-State Output
R
R
R
11
R
R
R
12
Multi-State Value
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
W W W W W W W W W
R
R
R
R
R
W W W W W W W W W
R
R
R
R/W (AMEV)
Binary Input
E/A-Objekttypen
Binary Output
Anhang 4.2
Binary Value
BACnet 2007
85
Gruppe MBE (AMEV)
A
B
B
A
0
A
B
A
A
A
A
A
A
A
A
13
A
B
B
A
0
A
0
A
A
A
A
A
A
A
A
14
Gruppe AS (AMEV)
Die Auflösung des Feldgeräts/analogen Eingangs muss lesbar sein
siehe Anhang 7.5
Außerbetriebsetzung und Übersteuerung müssen möglich sein
Verzicht bei AS, um hohe Hardwarekosten zu vermeiden
Angeschlossene Feldgeräte dürfen
nicht veränderbar sein
Beschreibung muss vorhanden sein
muss bei Außerbetriebsetzung
(Out_of_Service) beschreibbar sein
siehe Anhang 7.3
15
Weitere Hinweise
Legende für Spalte 13 und 14:
A: Grundausstattung
B:Ergänzungsausstattung
0: Property nicht gefordert
Polarität
Inaktiv-Zustandstext
Aktiv-Zustandstext
Zustandswechselzeitpunkt
Zustandswechselzähler
ZustandswechselzählerRücksetzzeitpunkt
Betriebsstundenzähler
BetriebsstundenzählerRücksetzzeitpunkt
Minimale Aus-Zeit
Minimale Ein-Zeit
Anzahl der Zustände
Zustandstext
Inactive_Text
Active_Text
Change_Of_State_Time
Change_Of_State_Count
Time_Of_State_Count_
Reset
Elapsed_Active_Time
Time_Of_Active_Time_Reset
Minimum_Off_Time
Minimum_On_Time
Number_Of_States
State_Text
2
Property
(deutsche Bezeichnung)
Polarity
1
Property Identifier
(Norm)
3
R/W (Norm)
O
R
O
O
O
O
O
O
O
O
O
R
Analog Input
4
Analog Output
5
Analog Value
6
7
Binary Input
8
R
R
R
R
R
R
R
9
W W
W W
W W W
W W W
W W W
W W W
R
R
R
R
Binary Output
R/W (AMEV)
Binary Value
86
Multi-State Input
R
R
10
Multi-State Output
R
R
11
Multi-State Value
R
R
12
Gruppe MBE (AMEV)
A
A
B
B
A
A
B
B
B
A
A
A
13
Aktiv-Zustand muss definiert sein
(siehe Anhang 7.4)
Inaktiv-Zustand muss definiert sein
(siehe Anhang 7.4)
15
Weitere Hinweise
Legende für Spalte 13 und 14:
A: Grundausstattung
B:Ergänzungsausstattung
0: Property nicht gefordert
A
A
0
0
A
A
Zustände müssen definiert sein
(siehe Anhang 7.4)
Empfehlung für zukünftige
Anwendung in MBE
Empfehlung für zukünftige
Anwendung in MBE
Beschreiben notwendig für
Betriebsstundenzählung
Betriebsstundenzählung muss
möglich sein
B nur notwendig bei Zustandswechselzählung
B nur notwendig bei Zustandswechselzählung
B nur notwendig bei Zustandswechselzählung
A
A
A
14
Gruppe AS (AMEV)
BACnet 2007
87
Kommando-Prioritäten
Vorgabewert
COV-Änderungsschwellenwert
Meldungsverzögerung
Meldungsklasse
Oberer Grenzwert
Unterer Grenzwert
Totzone
Grenzwertüberwachung
aktiv
Alarmwert
Rückmeldungswert
Alarmwerte
Fehlerwerte
Ereignismeldungen aktiv
Bestätigte Zustandsänderungen
Alarmkennzeichnung
Ereignis-Zeitstempel
Profil-Name
Priority_Array
Relinquish_Default
COV_Increment
Time_Delay
Notification_Class
High_Limit
Low_Limit
Deadband
Limit_Enable
Alarm_Value
Feedback_Value
Alarm_Values
Fault_Values
Event_Enable
Acked_Transitions
Notify_Type
Event_Time_Stamps
Profile_Name
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
W W
W W
W W
W W
R
R
R
R
W
R
R
R
R
R
R
W
R
R
R
R
O
R
R
R
O
R
R
R
O
R
R
R
O
R
R
R
O
R
R
R
O
R
R
R
O
R
R
R
O
R
R
R
O
R
R
R
W W W W W W W W W
W W W
W W W
W W W
W W W
R
W W W W W W W W W
W W W
W W
W W
0
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
0
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
soll nicht genutzt werden
notwendig für Intrinsic Reporting
notwendig für Intrinsic Reporting
notwendig für Intrinsic Reporting
notwendig für Intrinsic Reporting
notwendig für Intrinsic Reporting
notwendig für Intrinsic Reporting
notwendig für Intrinsic Reporting
notwendig für Intrinsic Reporting
notwendig für Intrinsic Reporting
Totzone muss veränderbar sein
(wie Grenzwerte)
Grenzwerte müssen veränderbar
sein
Grenzwerte müssen veränderbar
sein
notwendig für Intrinsic Reporting
(siehe Anhang 7.6)
notwendig für Intrinsic Reporting
Änderungsschwellenwert muss
veränderbar sein
Vorgabewert muss durch MBE
beschreibbar sein
Kommandoprioritäten müssen unterstützt werden
R
R
Objektbeschreibung
Zeitbereich der Gültigkeit
Wochenzeitplan
Ausnahmezeitplan
Vorgabewert für Zeitplan
Referenzliste der zu beschreibenden Properties
Kommandopriorität
Datumsliste
Meldungsklasse
Priorität
Bestätigung notwendig
Empfängerliste
Description
Effective_Period
Weekly_Schedule
Exception_Schedule
Schedule_Default
List_Of_Object_Property_
References
Priority_For_Writing
Date_List
Notification_Class
Priority
Ack_Required
Recipient_List
R
R
R
R
O
R
R
R
R
O
O
R
Objekttyp
Aktueller Wert
Object_Type
Present_Value
R
Objektname
Object_Name
3
R
Bez. der Objektinstanz
2
Property
(deutsche Bezeichnung)
R/W (Norm)
Object_Identifier
1
Property Identifier
(Norm)
4
Notification Class
R
R
R
R
R
R
R
R
5
Schedule
6
R
R
R
R
W
R
W
W
R
W
W W
R
R
W W
R
R/W (AMEV)
Calendar
Komplexe Objekttypen
R
R
R
R
7
File
Anhang 4.3
R
R
R
R
R
8
Event Enrollment
88
9
Trend Log
R
W
R
W
R
Loop
R
R
R
W
R
R
R
10
Gruppe MBE (AMEV)
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
11
Weitere Hinweise
13
Legende für Spalte 11 und 12:
A: Grundausstattung
B: Ergänzungsausstattung
0: Property nicht gefordert
siehe Anhang 7.3
muss bei Außerbetriebsetzung
(Out_of_Service) beschreibbar sein
A
A
A
A
A
A
A
A
A
A
A
notwendig für Intrinsic Reporting
Datumsliste muss bearbeitbar sein
Die Liste der zu den Schaltzeiten beeinflussten BACnet-Objekte muss änderbar sein
Zeitplan muss beschreibbar sein
Zeitplan muss beschreibbar sein
B bei der dynamischen Erzeugung von Objekten müssen Namen frei vergebbar sein
A
A
B bei der dynamischen Erzeugung von Objekten müssen Namen frei vergebbar sein
A
12
Gruppe AS (AMEV)
BACnet 2007
89
Empfängerliste
Dateityp
Dateigröße
Änderungsdatum
Datei ist archiviert
Schreibgeschützt
Dateizugriffsmethode
Aufzeichnung aktiv
Startzeit Aufzeichnung
Stopzeit Aufzeichnung
Adresse des aufzuzeichnenden Properties
Aufzeichnungs-Intervall
Erneuerungsintervall für
COV-Abonnement
Änderungsschwellenwert
für COV-Aufzeichnung
Stop wenn Speicher voll
Speichergröße
Aufzeichnungsspeicher
Anzahl Datenblöcke
Summe erfasster Datensätze
Schwellenwert für Meldungen
Anzahl Datensätze
seit Meldung
Recipient_List
File_Type
File_Size
Modification_Date
Archive
Read_Only
File_Access_Method
Log_Enable
Start_Time
Stop_Time
Log_DeviceObjectProperty
Log_Interval
COV_Resubscription_Interval
Client_COV_Increment
Stop_When_Full
Buffer_Size
Log_Buffer
Record_Count
Total_Record_Count
Notification_Threshold
Records_Since_Notification
O
O
R
W
R
R
R
O
O
O
O
O
O
R
R
R
R
R
R
R
R
W
W
R
R
W
R
R
R
R
R
R
W
R
R
R
W
W
W
W
W
W
W
B
B
A
A
A
A
A
B
B
A
A
A
A
A
A
A
A
A
A
A
A
notwendig für Trendaufzeichung eines
Property
notwendig für Trendaufzeichung eines
Property
notwendig für Trendaufzeichung eines
Property
notwendig für Trendaufzeichung eines
Property
B einsetzbar bei Intrinsic Reporting
B einsetzbar bei Intrinsic Reporting
A
A
A
A
A
B Änderungsschwellenwert soll veränderbar
sein
B
A
A
A
A
A
A
A
A
A
A
A
B MBE muss Empfängerliste ändern können
(ev. auch AS)
Physikalische Einheit der
Regelgröße
Controlled_Variable_Value
Controlled_Variable_Units
Wirkungsrichtung Regler
Proportional-Beiwert
Physikalische Einheit des
Proportional-Beiwerts
Action
Proportional_Constant
Proportional_Constant_
Units
Adresse des Sollwerts
Wert der Regelgröße
Controlled_Variable_ Reference
Wert des Sollwerts
Adresse der Regelgröße
Manipulated_Variable_
Reference
Setpoint
Adresse der Stellgröße
Output_Units
Setpoint_Reference
Aktualisierungszeit
Physikalische Einheit der
Stellgröße
Update_Interval
Verlässlichkeit
Objektfunktion außer
Betrieb
Out_Of_Service
Event_State
Reliability
Zustandsangaben
Ereignis-Zustand
Status_Flags
Letzter Datensatz nach
Ereignismeldung
2
Property
(deutsche Bezeichnung)
Last_Notify_Record
1
Property Identifier
(Norm)
3
R/W (Norm)
O
O
R
R
R
R
R
R
R
R
O
R
O
R
R
O
Notification Class
4
Schedule
W
R
R
5
Calendar
6
7
File
R/W (AMEV)
R
8
Event Enrollment
90
9
Trend Log
R
R
Loop
R
W
R
R
R
R
R
R
R
R
R
W
R
R
R
10
Gruppe MBE (AMEV)
A
A
A
A
A
A
A
A
A
A
0
A
B
A
A
A
11
13
notwendig für Intrinsic Reporting
Weitere Hinweise
Legende für Spalte 11 und 12:
A: Grundausstattung
B: Ergänzungsausstattung
0: Property nicht gefordert
A
A
A
A
A
A
A
A
A
A
0
A
Einheit des P-Anteils muss vorhanden sein
Regler-P-Anteil muss veränderbar sein
Außerbetriebsetzung und Übersteuerung müssen möglich sein
B Unplausible Werte sollen erkennbar sein
A
A
A
12
Gruppe AS (AMEV)
BACnet 2007
91
COV-Änderungsschwellenwert
COV_Increment
Profil-Name
Profile_Name
O
Alarmkennzeichnung
Ereignis-Zeitstempel
Bestätigte
Zustandsänderungen
Acked_Transitions
Notify_Type
Freigabe der
Ereignismeldungen
Event_Enable
Event_Time_Stamps
O
Property-Adresse
Object_Property_Reference
R
O
O
O
R
R
Ereignistyp
Ereignisparameter
Event_Parameters
O
O
O
O
O
O
Event_Type
Meldungsverzögerung
Untergrenze Stellgröße
Minimum_Output
Maximale
Regelabweichung
Obergrenze Stellgröße
Bias
Maximum_Output
Time_Delay
O
Ausgabe-Voreinstellung
Derivative_Constant_Units
Error_Limit
O
Differential-Beiwert
Physikalische Einheit des
Differential-Beiwerts
Derivative_Constant
O
Integral_Constant_Units
O
Integral-Beiwert
Physikalische Einheit des
Integral-Beiwerts
Integral_Constant
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
W W
W
W
W
W
W
W
R
W
R
W
0
A
A
A
A
A
A
A
A
A
A
A
A
B
A
A
A
A
A
Einheit des D-Anteils muss vorhanden sein
Regler-D-Anteil muss veränderbar sein
Einheit des I-Anteils muss vorhanden sein
Regler-I-Anteil muss veränderbar sein
0
A
A
A
A
B
B
B
A
A
A
A
A
soll nicht genutzt werden
notwendig für Intrinsic Reporting
notwendig für Intrinsic Reporting
notwendig für Intrinsic Reporting
notwendig für Intrinsic Reporting
zulässige Regelabweichung muss verändert
werden können
notwendig für Intrinsic Reporting
Änderungsschwellenwert muss veränderbar
sein
Schwellenwert muss veränderbar sein
Begrenzung muss veränderbar sein
B Begrenzung muss veränderbar sein
A
A
A
92
DS-RP-B
DS-RPM-A
DS-RPM-B
DS-RPC-A
DS-RPC-B
DS-WP-A
DS-WP-B
DS-WPM-A
DS-WPM-B
DS-COV-A
DS-COV-B
DS-COVP-A
DS-COVP-B
2
3
4
5
6
7
8
9
10
11
12
13
14
2
DS-RP-A
1
1
Lfd. Kurzform
Nr. (Norm)
Anhang 5
COV-Property-B
COV-Property-A
COV-Support-B
COV-Support-A
WriteProperty
Multiple-B
WriteProperty
Multiple-A
WriteProperty-B
WriteProperty-A
ReadProperty
Conditional-B
ReadProperty
Conditional-A
ReadProperty
Multiple-B
ReadProperty
Multiple-A
ReadProperty-B
ReadProperty-A
3
Bezeichnung
(Norm)
X
X
X
X
X
X
4
Norm
B-OWS
X
X
X
X
X
5
Bas.1)
X
X
6
Erw.2)
AMEV
MBE
X
X
X
X
X
X
X
7
Norm
B-BC
BIBBs: Übersicht mit Empfehlungen
X
X
X
X
X
X
8
Bas.1)
X
X
X
X
X
X
9
Erw.2)
AMEV
AS
alle
Objekte
alle
Objekte
alle
Objekte
alle
Objekte
alle
Objekte
alle
Objekte
alle
Objekte
10
betroff.
Objekttypen
B stellt abonnierte Informationen eines
Properties für A bereit
A abonniert Informationen über Wertänderungen eines Properties von B
B stellt abonnierte Informationen für A
bereit
A abonniert Informationen über bestimmte
Wertänderungen von B
B lässt Beschreiben mehrere Eigenschaften durch A zu
A beschreibt mehrere Eigenschaften
gleichzeitig auf B
B lässt Beschreiben durch A zu
A beschreibt eine Eigenschaft auf B
B lässt Eigenschaft durch A unter
bestimmten Kriterien lesen
A liest Eigenschaft von B unter bestimmten
Kriterien
B lässt mehrere Eigenschaften durch A
lesen
A liest mehrere Eigenschaften von B
gleichzeitig
B lässt Eigenschaft durch A lesen
A liest Eigenschaft von B
11
Beschreibung der Funktion
BACnet 2007
93
DS-COVU-B COV-Unsolicited-B
AE-N-A
AE-N-I-B
AE-N-E-B
AE-ACK-A
AE-ACK-B
AE-ASUM-A Alarm and EventAlarm-Summary-A
AE-ASUM-B Alarm and EventAlarm-Summary-B
AE-ESUM-A Alarm and EventEnroll-Summary-A
AE-ESUM-B Alarm and EventEnroll-Summary-B
16
17
18
19
20
21
22
23
24
25
Alarm and EventACK-B
Alarm and EventACK-A
Alarm and EventNotification
External B
Alarm and EventNotification
Internal B
Alarm and EventNotification-A
DS-COVU-A COV-Unsolicited-A
15
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
E/AObjekte,
NC, EE,
TLOG,
LP
E/AObjekte,
NC, EE,
TLOG,
LP
E/AObjekte,
NC, EE,
TLOG,
LP
E/AObjekte,
NC, EE,
TLOG,
LP
alle
Objekte
B stellt Empfängerlisten für Ereignisse
bereit für A
A fordert bei B Empfängerlisten für
Ereignisse an (unabhängig vom aktuellen
Zustand)
B stellt Alarmübersichten für A bereit
A fordert Alarmübersichten bei B an
(BIBB soll durch AE-INFO abgelöst werden)
B bearbeitet Bestätigungen (Quittierungen)
übertragener Meldungen
A quittiert Alarme und Ereignisse
B erzeugt Meldungen aus Informationen
anderer BACnet-Geräte und nutzt dabei
regelbasiertes Melden
B erzeugt geräteintern Meldungen und
unterstützt objektinternes sowie regelbasiertes Melden
A verarbeitet von B mitgeteilte Meldungen
und Ereignisse
B übermittelt A unaufgefordert Wertänderungen
A verarbeitet unaufgefordert übersandte
Wertänderungen von B
94
AE-LS-A
AE-LS-B
SCHED-A
SCHED-I-B
SCHED-E-B SchedulingExternal-B
T-VMT-A
T-VMT-I-B
T-VMT-E-B
28
29
30
31
32
33
34
35
Viewing and
Modifying TrendsExternal-B
Viewing and
Modifying TrendsInternal-B
Viewing and
Modifying Trends-A
SchedulingInternal-B
Scheduling-A
Alarm and EventLifesafety-B
Alarm and EventLifesafety-A
Alarm and EventInformation-B
AE-INFO-B
27
3
Alarm and EventInformation-A
AE-INFO-A
2
Bezeichnung
(Norm)
26
1
Lfd. Kurzform
Nr. (Norm)
X
X
X
4
Norm
B-OWS
X
X
X
5
Bas.1)
6
Erw.2)
AMEV
MBE
X
X
X
7
Norm
B-BC
X
X
8
Bas.1)
X
X
X
9
Erw.2)
AMEV
AS
B stellt Listen der anstehenden Alarme und
Ereignisse mit den ausstehenden Quittierungen und mit Zeitstempel bereit für A
A fordert bei B Listen aller anstehenden
Alarme und Ereignisse an einschließlich
der ausstehenden Quittierungen und mit
Zeitstempel (Erweiterung und Ablösung
des AE-SUM)
11
Beschreibung der Funktion
TLOG
CAL,
SCHED
B sammelt für A die Trenddaten von Datenpunkten im GA-Netzwerk in einem internen
Speicher
B sammelt für A die Trenddaten geräteinterner Datenpunkte in einem internen
Speicher
A zeigt Trenddaten von B an und bearbeitet Einstellungen für die Trendwerterfassung in B
B führt zeitabhängiges Schalten bei Datenpunkten anderer BACnet-Geräte aus
B führt zeitabhängiges Schalten bei eigenen Datenpunkten aus
A bearbeitet Zeitpläne und Kalendereinträge für B und zeigt sie an
B stellt Informationen über Alarmzustände
bereit für A
LSP, LSZ A fragt Alarmzustand bei der Gefahrmeldeeinrichtung B ab und quittiert Alarm; A
verteilt Zustandsänderung
E/AObjekte,
NC, EE,
TLOG,
LP
10
betroff.
Objekttypen
BACnet 2007
95
T-ATR-A
T-ATR-B
DM-DDB-A
DM-DDB-B
DM-DOB-A
DM-DOB-B
DM-DCC-A
DM-DCC-B
DM-PT-A
DM-PT-B
36
37
38
39
40
41
42
43
44
45
Private Transfer-B
Private Transfer-A
Device
Communication
Control-B
Device
Communiction
Control-A
Dynamic-ObjectBinding-B
Dynamic-ObjectBinding-A
Dynamic-DeviceBinding-B
Dynamic-DeviceBinding-A
Automated Trend
Retrieval-B
Automated Trend
Retrieval-A
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
herstelllerspezif.
DEV
alle
Objekte
DEV
alle
Objekte
TLOG
B verarbeitet proprietäre Daten und stellt
sie für A bereit
A veranlasst B zur Übertragung von
proprietären Daten mittels eines BACnetDienstes
B schaltet seine Kommunikation im Auftrag
von A ein oder aus
A schaltet die BACnet-Kommunikation von
B ein oder aus
B stellt A auf Anfrage Adressinformationen
über seine Objekte zur Verfügung
A sucht im GA-Netzwerk nach Adressinformationen von BACnet-Objekten (Identifikation von Objekten mit Who-Has, I-Have)
B stellt A Informationen über seine eigenen
Device-Properties zur Verfügung und
reagiert auf die Anforderungen, sich zu
identifizieren
A sucht im GA-Netzwerk nach Informationen von Device-Properties anderer
Devices (Identifikation von Geräten mit
Who-Is, I-Am)
B informiert A, dass sich in einem Trendaufzeichnungs-Speicher eine festgelegte
Anzahl von Einträgen angesammelt hat
A reagiert auf die Meldung von B, dass
gesammelte Trendwerte zur Abholung
bereitstehen
96
DM-TM-B
DM-TS-A
DM-TS-B
DM-UTC-A
DM-UTC-B
DM-RD-A
DM-RD-B
DM-BR-A
DM-BR-B
DM-R-A
DM-R-B
DM-LM-A
DM-LM-B
47
48
49
50
51
52
53
54
55
56
57
58
59
2
DM-TM-A
46
1
Lfd. Kurzform
Nr. (Norm)
List Manipulation-B
List Manipulation-A
Restart-B
Restart-A
Backup and
Restore-B
Backup and
Restore-A
Reinitialize Device-B
Reinitialize Device-A
UTCTime
Synchronization-B
UTCTime
Synchronization-A
Time
Synchronization-B
Time
Synchronization-A
Text Message-B
Text Message-A
3
Bezeichnung
(Norm)
X
X
X
X
4
Norm
B-OWS
X
X
X
X
5
Bas.1)
X
6
Erw.2)
AMEV
MBE
X
X
X3)
X3)
7
Norm
B-BC
X
X
X
8
Bas.1)
X
X
9
Erw.2)
AMEV
AS
B führt das Programm-Start-Kommando
von A aus
A veranlasst B zu einem Programm-Neustart
B übernimmt die Zeitsynchronisation nach
Greenwich-Zeit von A
A veranlassst Zeitsynchronisation nach
Greenwich-Zeit
B übernimmt die Zeitsynchronisation nach
regionaler Zeit von A
A veranlassst Zeitsynchronisation nach
regionaler Zeit
B verarbeitet von A gemeldeten freien Text
A überträgt freien Text an B (Interpretation,
Verarbeitung proprietär)
11
Beschreibung der Funktion
B informiert A über einen Neustart
A verarbeitet Neustart-Meldungen von B
und interpretiert die Gründe
NC, CAL, A veranlasst B zum Erstellen oder Löschen
SCHED, von Listenelementen in Properties
u.a.
B erstellt oder löscht Listenelemente in
Properties
DEV
B stellt A Konfigurationsdaten zur Verfügung und erlaubt A, die Daten neu zu
laden (z. B. nach Ausfall von B)
FIL, DEV A sichert Konfigurationsdaten von B und
lädt sie erneut
DEV
DEV
DEV
DEV
10
betroff.
Objekttypen
BACnet 2007
97
DM-OCD-B
DM-VT-A
DM-VT-B
NM-CE-A
NM-CE-B
NM-RC-A
NM-RC-B
61
62
63
64
65
66
67
Router
Configuration-B
Router
Configuration-A
Connection
Establishment-B
Connection
Establishment-A
Virtual Terminal-B
Virtual Terminal-A
Object Creation and
Deletion-B
Object Creation and
Deletion-A
X
X
X
3) Norm: AS muss DM-TS-B oder DM-UTC-B unterstützen.
2) Erw. = Erweiterte Ausstattung der Gruppe B (siehe Abschnitt 4.2)
1) Bas. = Grundausstattung der Gruppe A (siehe Abschnitt 4.2)
DM-OCD-A
60
X
X
X
X
projektspezif.
projektspezif.
Sonderfälle
alle
Objekte
außer
DEV
B erfragt und ändert die Konfigurationsdaten von Routern und Halbroutern
A veranlasst B zur Abfrage und Änderung
der Konfigurationsdaten von Routern und
Halbroutern
B baut Remote-Verbindungen über Halbrouter auf oder ab
A veranlasst B zum Auf- oder Abbau von
Remote-Verbindungen über Halbrouter
(Achtung: nicht lokales Modem)
B führt Kommandos von A über Terminalschnittstelle aus
A greift über Terminalschnittstelle auf Gerät
B zu
B erstellt und löscht unterstützte Objekte
auf Anforderung von A
A veranlasst B zum Erstellen und Löschen
von Objekten
Anhang 6
PICS (Muster mit deutschen Begriffen)
Annex A
Protocol Implementation Conformance Statement (PICS)
(mit deutschen Begriffen)
Date (Datum): .………………….……………………………………………….....................
Vendor Name (Hersteller): …….………………………………………………….................
Product Name (Produktname): .……….………………………………………....................
Product Model Number (Typ Nummer): .………………….…………………...............…..
Applications Software Version (Anwendungssoftware Version): ……….........................
Firmware Revision (Systemsoftware Version): ………….….......……………...................
BACnet Protocol Revision (BACnet Protokoll Stand): ……………..……….....................
1. Product Description (Produktbeschreibung): …………….………………..................
2. BACnet Standardized Device Profile (Annex L) (Standard-Geräteprofil):
BACnet Operator Workstation (B-OWS)
BACnet Building Controller (B-BC)
BACnet Advanced Application Controller (B-AAC)
BACnet Application Specific Controller (B-ASC)
BACnet Smart Sensor (B-SS)
BACnet Smart Actuator (B-SA)
3. List of all BACnet Interoperability Building Blocks Supported (Annex K)
(Liste aller unterstützter BIBBs):
4. Segmentation Capability (Unterstützte Segmentierung):
Segmented requests supported Windows Size …….................................
(Segmentierte Anfragen werden unterstützt)
Segmented responses supported Windows Size ……….............................
(Segmentierte Antworten werden unterstützt)
5. Standard Object Types Supported (Unterstützte Standard-Objekttypen):
The following object types are supported and present in the device. Each standard
object type is supported with following data
(Nachfolgende Objektypen werden unterstützt und sind Bestandteil des Gerätes.
Jeder Standard-Objekttyp wird mit folgenden Daten unterstützt):
98
6. Data Link Layer Options (Netzwerkoptionen):
BACnet IP, (Annex J)
BACnet IP, (Annex J), Foreign Device
ISO 8802-3, Ethernet (Clause 7)
ANSI/ATA 878.1,2.5 Mb. ARCNET (Clause 8)
ANSI/ATA 878.1, RS-485 ARCNET (Clause 8), baud rate(s)
MS/TP master (Clause 9), baud rate(s):
MS/TP slave (Clause 9), baud rate(s):
Point-To-Point, EIA 232 (Clause 10), baud rate(s):
Point-To-Point, modem, (Clause 10), baud rate(s):
LonTalk, (Clause 11), medium: ........................TP/FT-10
Other:.................................................................
7. Device Address Binding (Einbindung der Geräteadresse):
Is static device binding supported? (This is currently necessary for two-way communication with MS/TP slaves and certain other devices.)
(Wird statische Geräteeinbindung unterstützt? Dies ist derzeit notwendig für bidirektionale Verbindungen mit MS/TP Slaves und bestimmten anderen Geräten.)
Yes
No
8. Networking Options (Routeroptionen):
Router, Clause 6 - List all routing configurations, e.g. ARCNET-Ethernet, Ethernet-MS/TP
Annex H, BACnet Tunneling Router over IP
BACnet/IP Broadcast Management Device (BBMD)
Does the BBMD support registrations by Foreign Devices? Yes
No
(Unterstützt das BBMD-Gerät die Registrierung durch externe Geräte?)
9. Character Sets Supported (Unterstützte Zeichensätze):
Indicating support for multiple character sets does not imply that they can all be supported simultaneously. (Der Verweis auf mehrere Zeichensätze bedeutet nicht deren
gleichzeitige Nutzung.)
ANSI X3.4
IBM™/Microsoft™ DBCS
ISO 8859-1
ISO 10646 (UCS-2)
ISO 10646 (UCS-4)
JIS C 6226
If this product is a communication gateway, describe the types of non-BACnet equipment/networks(s) that the gateway supports
(Falls das Produkt ein Gateway ist, werden die unterstützten, nicht BACnet-spezifischen Netzwerk- und Geräteeigenschaften nachfolgend beschrieben):
BACnet 2007
99
Anhang 7
EDE-Liste
Anhang 7.1
Erläuterung der Angaben
In der EDE-Liste müssen alle E/A-Objekte und die dafür abgefragten Properties vollständig dokumentiert werden. Die Angaben zu Adressen, Einheiten, Wertebereichen,
Beschreibungstexten, Alarmgrenzwerten usw. müssen sinnvoll vergeben sein.
Alle BACnet-Objekte in der EDE-Liste müssen auch in den Automationsschemata eingetragen sein, damit bei den zugehörigen Grafikbildern in der Bedienoberfläche der
Zusammenhang zwischen BACnet-Objekten und GA-Funktionen erkennbar wird.
Anhang 7.2 enthält ein aktualisiertes Blankett einer EDE-Liste. Grundlage ist ein Muster der BIG-EU aus dem Jahr 2004, das um die Spalte „supports COV“ gekürzt und
um Kopfdaten, die Spalte „notification class“ und eine erläuternde Zeile mit deutschem Text erweitert wurde. In den Kopfzeilen wurde aus Platzgründen auf Trennzeichen verzichtet. In den Spalten 4, 13, 14 und 16 sind standardisierte Informationen
mit Hilfe der nachfolgenden Tabellen einzutragen.
Anhang 7.3 enthält die Tabelle der BACnet-Objekttypen (object type) mit Klartextbezeichnungen aller verwendeten Objekttypen und Zuordnung einer Code-Nr. (object
type code) mit bis zu 3 Stellen (z. B. Analog Input, Analog Output, Analog Value,
Binary Input).
Anhang 7.4 enthält eine Tabelle mit Beispielen für Zustandstexte und Referenznummern (state text reference) der binären und mehrstufigen Ein- und Ausgabeobjekte.
Anhang 7.5 enthält die Tabelle der physikalischen Einheiten mit einer aktuellen
Übersicht der in öffentlichen Gebäuden relevanten Standard-Einheiten (units) und
ihrer Codenummern (unit codes). Die Übersicht enthält neben der Norm-Bezeichnung
auch deutsche Bezeichnungen, Zeichen und Größen.
Anhang 7.6 enthält eine Tabelle der Meldungsklassen (notification class) mit Vorschlägen für eine einheitliche Kodierung der Alarmkategorie, ihrer Bedeutung, Priorität und Meldungsklasse sowie einigen typischen Beispielen.
100
Kopfzeile
Im Kopf der EDE-Listen sollen zusätzlich die nachfolgenden Kopfdaten angegeben
werden, um eine eindeutige Zuordnung der EDE-Listen bei mehreren Teilnehmern
oder unterschiedlichen Sachständen zu ermöglichen:
• Projektname
• Erstellername
• Freigabevermerk
• Erstelldatum
• Datum 1. Änderung
• Datum 2. Änderung
• Datum 3. Änderung
• Dateiname
Das Ausfüllen der 16 Spalten der EDE-Liste wird nachfolgend erläutert:
Spalte 1 Benutzeradresse (keyname):
Die Bezeichnung ist dem vorgegebenen Adressierungsschlüssel des Nutzers zu entnehmen. Dieser soll so strukturiert sein, dass die GA-Funktionen der Systemteilnehmer
in der EDE-Tabelle übersichtlich und in logisch nachvollziehbarem Zusammenhang
dargestellt werden. Für die Darstellung darf nur ein Trennzeichentyp (ohne Leerzeilen)
verwendet werden. Die Benutzeradresse (keyname) sollte mit dem Objektnamen (object name) übereinstimmen.
Spalte 2 Geräteadresse (device):
Diese Spalte enthält die technische BACnet-Adresse des Gerätes, von dem die BACnet-Objekte stammen. Die maximale Länge ist durch die verwendeten Data Link Layer
Protokolle begrenzt und soll in Anschlussbedingungen nach Abschnitt 8.2 festgelegt
sein (z. B. max. 4 Zeichen).
Spalte 3 Objektname (object name):
Diese Spalte enthält die eindeutigen BACnet-Objektnamen für die BACnet-Kommunikation und erscheint im „Object viewer“ der Bedienoberfläche. Die Bedingungen für Anzahl und Darstellung der Zeichen sollen in Anschlussbedingungen nach Abschnitt 8.2
festgelegt sein (z. B. Darstellung als Trennzeichentyp mit maximal 32 Zeichen).
Spalte 4 Objekttyp (object type):
Hier wird die Schlüsselzahl (Code-Nummer) des BACnet-Objekts eingetragen, die
Anhang 7.3 zu entnehmen ist.
BACnet 2007
101
Spalte 5 Instanznummer (object instance):
Diese Spalte enthält die Instanznummer des BACnet-Objektes. Zusammen mit dem
Objekttyp ergibt sich eine innerhalb des Geräts (Device) eindeutige Adresse.
Spalte 6 Objektbeschreibung (description):
Diese Spalte enthält eine Klartextbeschreibung und ev. projektspezifische Informationen zum Objekt. Vorgaben und Einschränkungen der Informationen, der Darstellungsart und der Anzahl der Zeichen sollen in Anschlussbedingungen nach Abschnitt 8.2
festgelegt sein (z. B. insgesamt maximal 64 Zeichen).
Spalte 7 Vorgabewert (relinquish default):
Diese Spalte gibt den Vorgabewert des BACnet-Objektes an (bei Initialisierung).
Spalte 8 Untere Bereichsgrenze (min present value):
Diese Spalte enthält die untere Bereichsgrenze (z. B. Messbereich, Stellbereich).
Spalte 9 Obere Bereichsgrenze (max present value):
Diese Spalte enthält die obere Bereichsgrenze (z. B. Messbereich, Stellbereich).
Spalte 10 Veränderbar (settable; früher: commandable):
In dieser Spalte trägt der Errichter der AS ein, ob der Wert des BACnet-Objektes durch
einen Client beschreibbar sein soll (Yes) oder nicht (No).
Spalte 11 Oberer Grenzwert (high limit):
Diese Spalte enthält den oberen Grenzwert, der vom BACnet-Objekt durch objektinternes Melden (Intrinsic Reporting) überwacht wird.
Spalte 12 Unterer Grenzwert (low limit)
Diese Spalte enthält den unteren Grenzwert, der vom BACnet-Objekt durch objektinternes Melden (Intrinsic Reporting) überwacht wird.
Spalte 13 Zustandstext (state text reference):
Diese Spalte enthält die Referenznummer aus der Zustandstext-Tabelle in Anhang 7.4.
Die beiden ersten Ziffern entsprechen der Anzahl der unterschiedlichen Zustände
(z. B. 02 bei binären Zuständen). Die beiden anderen Ziffern ermöglichen weitere
Unterscheidungen unter betrieblichen Aspekten. Bei Bedarf kann die Tabelle ergänzt
werden.
Spalte 14 Physikalische Einheit (unit code):
Diese Spalte enthält die Codenummer der physikalischen Einheit in Anhang 7.5. Die
fehlenden Codes werden in Europa nicht angewendet. Bei Bedarf kann die Tabelle
um weitere Codenummern ergänzt werden (größer als 255).
102
Spalte 15 Firmenspezifische Adresse (vendor specific address):
Hier können die systemeigenen Adressen der Subsysteme eingetragen werden. Der
Eintrag stellt den Zusammenhang zwischen einem BACnet-Objekt und dem damit
realisierten physikalischen Eingang oder Ausgang her. Die systemeigene Adresse ist
nicht Bestandteil eines BACnet-Objektes und ist somit als Referenz unerlässlich.
Spalte 16 Meldungsklasse (notification class):
Hier ist anzugeben, bei welchem Zustandswechsel eine Meldung erzeugt wird und
welche Priorität sie besitzt. Die Meldungsklasse bezieht sich auf den Ereignis-Zustand
(Event_State) des Objekts und dessen Quittierungsbedarf (Acked_Transitions). Die
Hinweise in Abschnitt 5.4 und die Beispiele in Anhang 7.6 sind zu beachten. Meldungsklassen sollen in Anschlussbedingungen nach Abschnitt 8.2 festgelegt sein.
Die vorgenannten Informationen enthalten neben den wichtigsten Eigenschaften eines
BACnet-Objektes auch zwei unverzichtbare Angaben für das Projekt-Engineering:
• „Settable“ (Spalte 10) kennzeichnet, ob ein Sollwert durch einen Operator oder
durch eine automatische Berechnung gesetzt wird (in früheren Versionen: „cmd“).
• „Vendor_Specific_Address“ (Spalte 15) dient als Information über die HardwareAdresse eines BACnet-Objektes.
BACnet 2007
103
104
object
name
device
object
instance
2
keyname
1
3
Objektname
Benutzer- Geräteadresse Adresse
4
object
type
Objekttyp
5
object
instance
InstanzNr.
6
description
7
relinquish
default
8
min
present
value
9
max
present
value
Untere
Obere
Bereichs- Bereichsgrenze
grenze
Klartext
Beschreibung
Vorgabewert
Erstellername
BACnet-Projekt
EDE-Tabelle (Muster)
EDE-Tabelle
Anhang 7.2
10
settable
Veränderbar
Freigabe
11
high
limit
Oberer
Grenzwert
Erstelldatum
Datum
2. Änd.
Datum
3. Änd.
12
low
limit
13
state
text
refer.
14
unit
code
Unterer Zustands- Phys.
Grenztext
Einheit
wert
Ref.-Nr. (Code)
Datum
1. Änd.
15
vendor
specific
address
Firmenspezif.
Adresse
16
notification
class
Meldungsklasse
Dateiname
Anhang 7.3
Object
Type
Code
Objekttyp (mit Object Type Code)
Object
Type
Code
Objekttyp
(nach Code sortiert)
Objekttyp
(alphabetisch sortiert)
0
Analog Input
Access Door
30
1
Analog Output
Access-Credential
32
2
Analog Value
Access-Point
33
3
Binary Input
Access-Rights
34
4
Binary Output
Access-User
35
5
Binary Value
Access-Zone
36
6
Calendar
Accumulator
23
7
Command
Analog Input
0
8
Device
Analog Output
1
9
Event Enrollment
Analog Value
2
10
File
Authentication-Input-Factor
37
11
Group
Averaging
18
12
Loop
Binary Input
3
13
Multi-state Input
Binary Output
4
14
Multi-state Output
Binary Value
5
15
Notification Class
Calendar
6
16
Program
Command
7
17
Schedule
Device
8
18
Averaging
Event Enrollment
9
19
Multi-state Value
Event Log
25
20
Trend Log
File
10
21
Life Safety Point
Global Group
26
22
Life Safety Zone
Group
11
23
Accumulator
Life Safety Point
21
24
Pulse Converter
Life Safety Zone
22
25
Event Log
Lighting Output
31
26
Global Group
Load Control
28
27
Trend Log Multiple
Loop
12
28
Load Control
Multi-state Input
13
29
Structured View
Multi-state Output
14
30
Access Door
Multi-state Value
19
31
Lighting Output
Notification Class
15
32
Access-Credential
Program
16
33
Access-Point
Pulse Converter
24
34
Access-Rights
Schedule
17
35
Access-User
Structured View
29
36
Access-Zone
Trend Log
20
37
Authentication-Input-Factor
Trend Log Multiple
27
BACnet 2007
105
106
Nr.
0201
0202
0203
0204
0205
0206
0211
0212
0221
0222
0231
0232
0233
0234
0235
0241
0242
0243
0244
0251
0252
0253
0254
0255
0261
0262
1
Nein
Aus
Geschlossen
Zu
Stop
Ausgangsstellung
Passiv
Hand
Rücksetzen
Zurück
Ab
Unten
Links
Gleichläufig
Langsam
Nachtbetrieb
Heizen
Winter
Gas
Normal
Normal
Normal
Normal
Normal
Normalbetrieb
Normalbetrieb
2
Ja
Ein
Offen
Auf
Start
Endstellung
Aktiv
Automatik
Setzen
Vor
Auf
Oben
Rechts
Gegenläufig
Schnell
Tagbetrieb
Kühlen
Sommer
Öl
Gefahr
Alarm
Störung
Wartung
Anormal
Initialisierung
Optimierung
AktivZustandstext
3
Zustandstext (Beispiele)
State
InaktivText ReZustandstext
ference
Anhang 7.4
4
5
6
7
8
9
10
BACnet 2007
107
Nr.
0301
0302
0303
0304
0311
0321
0322
0323
0324
0331
0341
0351
0361
0401
0411
0501
0511
0601
0701
0801
0901
1001
1
Aus
Zu
Ausgangsstellung
Zurück
Unten
Links
Links
Links
Links
Heizen
Normal
Langsam
Aus
Aus
Not-Aus
Aus
Aus
Aus
Aus
Aus
Aus
Aus
State
InaktivText ReZustandstext
ference
2
3
4
5
Hand
Automatik
Mittelstellung
Auf
Mittelstellung
Endstellung
Mittelstellung
Vor
Mittelstellung
Oben
Mitte
Rechts
Ausgangsstellung Rechts
Ruhestellung
Rechts
Aus
Rechts
Nullenergie
Kühlen
Wartung
Alarm
Mittel
Schnell
Stufe 1
Stufe 2
Stufe 1
Stufe 2
Stufe 3
Aus
Ein
Frostschutz
Stufe 1
Stufe 2
Stufe 3
Stufe 4
Ein
Regler
Min.Begr. Max.Begr.
Stufe 1
Stufe 2
Stufe 3
Stufe 4
Stufe 1
Stufe 2
Stufe 3
Stufe 4
Stufe 1
Stufe 2
Stufe 3
Stufe 4
Stufe 1
Stufe 2
Stufe 3
Stufe 4
Stufe 1
Stufe 2
Stufe 3
Stufe 4
AktivZustandstext
Stufe 5
Stufe 5
Stufe 5
Stufe 5
Stufe 5
6
Stufe 6
Stufe 6
Stufe 6
Stufe 6
7
Stufe 7
Stufe 7
Stufe 7
8
Stufe 8
Stufe 8
9
Stufe 9
10
Anhang 7.5
Physikalische Einheiten (mit Unit Code)
Unit Unit
Code (Norm)
1
Einheit
(deutsch)
2
Zeichen Größe
(deutsch) (deutsch)
3
4
5
0
SQ_METERS
Quadratmeter
m²
Fläche
2
MILLIAMPERES
Milli-Ampere
mA
Stromstärke
3
AMPERES
Ampere
A
Stromstärke
4
OHMS
Ohm
Ohm
Elektr. Widerstand
5
VOLTS
Volt
V
Elektr. Spannung
6
KILOVOLTS
Kilo-Volt
kV
Elektr. Spannung
7
MEGAVOLTS
Mega-Volt
MV
Elektr. Spannung
8
VOLT_AMPERES
Volt-Ampere
VA
Elektr. Scheinleistung
9
KILOVOLT_AMPERES
Kilo-Volt-Ampere
kVA
Elektr. Scheinleistung
10
MEGAVOLT_AMPERES
Mega-Volt-Ampere
MVA
Elektr. Scheinleistung
11
VOLT_AMPERES_REACTIVE
Volt-Ampere-reaktiv
var
Elektr. Blindleistung
12
KILOVOLT_AMPERES_REACTIVE
Kilo-Volt-Ampere- reaktiv
kvar
Elektr. Blindleistung
13
MEGAVOLT_AMPERES_REACTIVE
Mega-Volt-Ampere-reaktiv
Mvar
Elektr. Blindleistung
15
POWER_FACTOR
Leistungsfaktor cos φ
16
JOULES
Joule
J
Energie
17
KILOJOULES
Kilo-Joule
kJ
Energie
18
WATT_HOURS
Watt-Stunden
Wh
Energie
19
KILOWATT_HOURS
Kilo-Watt-Stunden
kWh
Energie
23
JOULES_PER_KG_DRY_AIR
Joule pro Kg trockene Luft
J/kg
Energieinhalt
25
CYCLES_PER_HOUR
Umdrehungen pro Stunde
1/h
Drehzahl
26
CYCLES_PER_MINUTE
Umdrehungen pro Minute
1/min
Drehzahl
27
HERTZ
Hertz
Hz
Frequenz
28
GRAMS_OF_WATER_PER_KG
Gramm Wasser pro kg Luft
g/kg
Absolute Feuchte
29
RELATIVE_HUMIDITY
Relative Feuchte
% r.F.
Relative Feuchte
30
MILLIMETERS
Millimeter
mm
Länge
31
METERS
Meter
m
Länge
35
WATTS_PER_SQ_METER
Watt pro Quadratmeter
W/m²
Flächenspez. Leistung
36
LUMENS
Lumen
lm
Lichtstrom
37
LUXES
Lux
lx
Beleuchtungsstärke
39
KILOGRAMS
Kilogramm
kg
Gewicht
41
TONS
Tonnen
t
Gewicht
42
KGS_PER_SECOND
Kilogramm pro Sekunde
kg/s
Massenstrom
108
Leistungsfaktor
Unit Unit
Code (Norm)
1
Einheit
(deutsch)
2
Zeichen Größe
(deutsch) (deutsch)
3
4
5
43
KGS_PER_MINUTE
Kilogramm pro Minute
kg/min
Massenstrom
44
KGS_PER_HOUR
Kilogramm pro Stunde
kg/h
Massenstrom
47
WATTS
Watt
W
Leistung
48
KILOWATTS
Kilo-Watt
kW
Leistung
49
MEGAWATTS
Mega-Watt
MW
Leistung
51
HORSEPOWER
Pferdestärke
PS
Leistung
53
PASCALS
Pascal
Pa
Druck
54
KILOPASCALS
Kilo-Pascal
kPa
Druck
55
BARS
Bar
bar
Druck
62
DEGREES_C
Grad Celsius
°C
Temperatur
63
DEGREES_K
Kelvin
K
Temperatur
67
YEARS
Jahre
a
Zeit
68
MONTHS
Monate
Mon
Zeit
69
WEEKS
Wochen
Wo
Zeit
70
DAYS
Tage
d
Zeit
71
HOURS
Stunden
h
Zeit
72
MINUTES
Minuten
min
Zeit
73
SECONDS
Sekunden
s
Zeit
74
METERS_PER_SECOND
Meter pro Sekunde
m/s
Geschwindigkeit
75
KILOMETERS_PER_HOUR
Kilometer pro Stunde
km/h
Geschwindigkeit
80
CUBIC_METERS
Kubikmeter
m³
Volumen
82
LITERS
Liter
l
Volumen
85
CUBIC_METERS_PER_SECOND
Kubikmeter pro Sekunde
m³/s
Volumenstrom
87
LITERS_PER_SECOND
Liter pro Sekunde
l/s
Volumenstrom
88
LITERS_PER_MINUTE
Liter pro Minute
l/min
Volumenstrom
90
DEGREES_ANGULAR
Gradmaß
°
Raumwinkel
91
DEGREES_C_PER_HOUR
Grad Celsius pro Stunde
°C/h
Temperatur­gradient
92
DEGREES_C_PER_MINUTE
Grad Celsius pro Minute
°C/min
Temperatur­gradient
95
NO_UNITS
(ohne Einheit)
96
PARTS_PER_MILLION
Teile pro Million
ppm
Konzentration
97
PARTS_PER_BILLION
Teile pro Milliarde
ppb
Konzentration
98
PERCENT
Prozent
%
Anteil
99
PERCENT_PER_SECOND
Prozent pro Sekunde
%/s
Änderungsgeschw.
RADIANS
Bogenmaß
rad
Winkel
103
BACnet 2007
109
Unit Unit
Code (Norm)
1
Einheit
(deutsch)
2
Zeichen Größe
(deutsch) (deutsch)
3
4
5
105
CURRENCY1
Euro
EUR
Währung
106
CURRENCY2
Deutsche Mark
DM
Währung
116
SQARE_CENTIMETERS
Quadratzentimeter
cm²
Fläche
118
CENTIMETERS
Zentimeter
cm
Länge
122
KILOHMS
Kilo-Ohm
kOhm
Elektr. Widerstand
123
MEGOHMS
Mega-Ohm
MOhm
Elektr. Widerstand
124
MILLIVOLTS
Milli-Volt
mV
Elektrische Spannung
125
KILOJOULES_PER_KG
Kilo-Joule pro Kilogramm
kJ/kg
Spez. Energieinhalt
126
MEGAJOULES
Mega-Joule
MJ
Energie
127
JOULES_PER_DEGREE_K
Joule pro Kelvin
J/K
128
JOULES_PER_KG_DEGREE_K
Joule pro kg und Kelvin
J/(kg*K)
Wärmekapazität
129
KILOHERTZ
Kilo-Hertz
kHz
Frequenz
130
MEGAHERTZ
Mega-Hertz
MHz
Frequenz
132
MILLIWATTS
Milli-Watt
mW
Leistung
133
HECTOPASCALS
Hekto-Pascal
hPa
Druck
134
MILLIBARS
Milli-Bar
mbar
Druck
135
CUBIC_METERS_PER_HOUR
Kubikmeter pro Stunde
m³/h
Durchsatz
136
LITERS_PER_HOUR
Liter pro Stunde
l/h
Durchsatz
137
KWATT_HOURS_PER_SQ_METER
Kilo-Watt-Stunden pro m²
kWh/m²
Flächenbezogener
Energiekennwert
139
MEGAJOULES_PER_SQ_METER
Mega-Joule pro m²
MJ/m²
Spez. Gebäudewert
141
WATTS_PER_SQ_M_DEGREE_K
Watt pro m² und Kelvin
W/(m²*K)
Wärmedurchgangskoeffizient
144
PERCENT_OBSCURATION_PER_
METER
% Verdunkelung pro m
%/m
% Verdunkelung
145
MILLIOHMS
Milli-Ohm
mOhm
Elektr. Widerstand
146
MEGAWATT_HOURS
Mega-Watt-Stunden
MWh
Elektr. Arbeit
149
KILOJOULES_PER_KG_DRY_AIR
Kilo-Joule pro Kilogramm
kJ/kg tr.
Luft
Enthalpie
150
MEGAJOULES_PER_KG_DRY_AIR
Mega-Joule pro Kilogramm
MJ/kg tr.
Luft
Enthalpie
151
KILOJOULES_PER_DEGREE_KELVIN
Kilo-Joule pro Kelvin
kJ/K
Entropie
152
MEGAJOULES_PER_DEGREE_KELVIN
Mega-Joule pro Kelvin
MJ/K
Entropie
153
NEWTON
Newton
N
Kraft
154
GRAMS_PER_SECOND
Gramm pro Sekunde
g/s
Massenstrom
110
Unit Unit
Code (Norm)
1
Einheit
(deutsch)
2
Zeichen Größe
(deutsch) (deutsch)
3
4
5
155
GRAMS_PER_MINUTE
Gramm pro Minute
g/min
Massenstrom
158
HUNDREDTHS_SECONDS
Hundertstel-Sekunden
10-2 s
Zeit
159
MILLISECONDS
Milli-Sekunden
ms
Zeit
160
NEWTON_METERS
Newton-Meter
Nm
Drehmoment
161
MILLIMETERS_PER_SECOND
Millimeter pro Sekunde
mm/s
Geschwindigkeit
162
MILLIMETERS_PER_MINUTE
Millimeter pro Minute
mm/min
Geschwindigkeit
163
METERS_PER_MINUTE
Meter pro Minute
m/min
Geschwindigkeit
164
METERS_PER_HOUR
Meter pro Stunde
m/h
Geschwindigkeit
165
CUBIC_METERS_PER_MINUTE
Kubikmeter pro Minute
m³/min
Volumenstrom
166
METERS_PER_SECOND_
PER_SECOND
Meter pro Sekunde²
m/s²
Beschleunigung
170
FARADS
Farad
F
Elektr. Kapazität
171
HENRYS
Henry
H
Induktivität
172
OHM_METERS
Ohm-Meter
Wm
Spez. elektr. Widerstand
173
SIEMENS
Siemens
S
Elektr. Leitwert
174
SIEMENS_PER_METER
Siemens pro Meter
S/m
Elektr. Leitfähigkeit
175
TESLAS
Tesla
T
Magnetische Flussdichte
176
VOLTS_PER_DEGREE_KELVIN
Volt pro Kelvin
V/K
Spannung pro Kelvin
177
VOLTS_PER_METER
Volt pro Meter
V/m
Elektrische Feldstärke
178
WEBERS
Weber
Wb
Magnetischer Fluss
179
CANDELAS
Candela
cd
Lichtstärke
180
CANDELAS_PER_SQUARE_METER
Candela pro Quadratmeter
cd/m²
Leuchtdichte
181
DEGREES_KELVIN_PER_HOUR
Kelvin pro Stunde
K/h
Temperaturgradient
182
DEGREES_KELVIN_PER_MINUTE
Kelvin pro Minute
K/min
Temperaturgradient
183
JOULE_SECONDS
Joule-Sekunde
Js
Drehimpuls
184
RADIANS_PER_SECOND
Radiant pro Sekunde
rad/s
Winkelgeschwindigkeit
185
SQUARE_METERS_PER_NEWTON
Quadratmeter pro Newton
m²/N
Kraftverteilung
186
KILOGRAMS_PER_CUBIC_METER
Kilogramm pro Kubikmeter
kg/m³
Dichte
187
NEWTON_SECONDS
Newton-Sekunde
Ns
Impuls
188
NEWTONS_PER_METER
Newton pro Meter
N/m
Oberflächenspannung
189
WATTS_PER_METER_PER_
DEGREE_KELVIN
Watt pro m und Kelvin
W/m K
Wärmeleitfähigkeit
BACnet 2007
111
112
90 - 119
120 -149
150 - 219
Sicherheitsmeldung
Meldungen, die Anlagenausfall signalisieren oder
sofortigen Eingriff erfordern
Meldungen, die auf einen
nicht normalen Betriebszustand hinweisen
Hinweis auf eine erforderliche Wartungsaktivität o.ä.
Störungsmeldungen aus
dem GA-System
Sonstige Meldungen
Alarmmeldung
Störungsmeldung
Wartungs­meldung
System­meldung
Freibleibend
220 - 255
60 - 89
30 - 59
00 - 29
3
Gefahrenmeldung
(Property Safety)
2
Gefahr für Leben
1
Gefahrenmeldung
(Life Safety)
Priorität
Bedeutung
Meldungsklasse (Beispiele)
Alarmkategorie
Anhang 7.6
7
6
5
4
3
2
1
4
Meldungsklasse
5
Betriebszustandswechsel,
Betriebsarten usw.
Gerätestörung, Batteriemeldung,
Kommunikationsunterbrechung usw.
Filterende erreicht, Filter verschmutzt,
Betriebsstunden, Behälterstand usw.
Temperaturwächter (TW), Druckwächter (DW), Temperaturüberwachung von Wärmetauscher (WT) und WWB, Motorschutz, Aufzug-Sammelstörmeldung, Netzdrücke, Reparaturschalter usw.
Sicherheitstemperaturbegrenzer (STB), Sicherheitsdruckbegrenzer (SDB), Übertemperatur der Warmwasserbereitung (WWB),
Sicherheitsventile, Hauptpumpen, Keilriemenwächter, Frequenzumformer, Kälteanlagen, Spannungsausfall usw.
Einbruch, unberechtigter Zutritt
Brandalarm, Überfall
Beispiel
Anhang 8
Glossar
BBMD
Ein BBMD-Gerät (BACnet Broadcast Management Device) ermöglicht die Übertragung von Broadcast-Meldungen in gerouteten IP-Netzen, indem es die BroadcastMeldungen zu den BBMD anderer IP-Subnetze tunnelt. Eine falsche Einstellung oder
Fehlfunktion des BBMD-Gerätes kann zu Netzstörungen durch inflationären Anstieg
der Broadcast-Meldungen führen.
Broadcast
Broadcast-Meldungen sind „Rundschreiben ohne speziellen Adressaten“. In IP-Netzen lassen IP-Router die Broadcast-Meldungen nicht passieren.
Ethernet
Ethernet ist ein gängiges Zugriffsverfahren in lokalen Netzwerken (Local area network-LAN)
und ermöglicht schnelle Netzwerkverbindungen. Es spezifiziert aus Sicht des OSI-Modells sowohl die physikalische Schicht (OSI Layer 1) als auch die Data-Link-Schicht
(OSI Layer 2). Ethernet ist weitestgehend in der IEEE-Norm 802.3 standardisiert.
Firewall
Eine Firewall wird an den Verbindungsstellen zwischen Netzen installiert. Sie lässt nur
zugelassene Kommunikation passieren, weist unzulässige Aktionen ab und protokolliert Missbrauchsversuche.
Paketfilter filtern die IP-Pakete auf Transportebene nach vorgegebenen Regeln zum
Weiterleiten oder Abblocken. Application-Gateways filtern auf Anwendungsebene.
Beim Aufbau von BACnet-Netzwerken prüft ein Zugangsrechner auf der Anwendungsebene die Pakete und erlaubt oder verbietet Verbindungen nach vorgegebenen Regeln. Für Datei-Übertragung (Filetransfer) oder Fernbedienung werden Bedingungen
und Regeln für den Zugriff auf die Dienste eingeführt. Dadurch besteht die Möglichkeit der benutzerbezogenen Authentisierung und der Protokollierung der Dienste.
Gateway
Gateways (Protokollumsetzer) verbinden Netzwerke mit unterschiedlichen, untereinander nicht kompatiblen Protokollen. In BACnet-Systemen dienen Gateways z. B. zur
Umsetzung von Daten aus LON-Anwendungen oder für OPC-Systeme.
BACnet 2007
113
IP (Internet-Protokoll)
Die Aufgabe des Internet-Protokolls besteht darin, Datenpakete über mehrere Netze
hinweg von einem Sender zu einem Empfänger zu transportieren. Die Übertragung
erfolgt paketorientiert, verbindungslos und nicht in Echtzeit. IP garantiert weder eine
Ablieferung beim Empfänger noch das Eintreffen der Pakete in der richtigen Reihenfolge. Diese Aufgaben sind durch höhere Protokollschichten oder das Anwendungsprogramm zu erledigen.
IP-Adressierung
Die IP-Adresse besteht aus zwei Teilen, dem Netzwerk-Teil und dem Host-Teil. Die
Größe der Adressbereiche des Netzwerk- und Host-Teiles der IP-Adresse wird durch
die Klassifizierung A, B, C definiert. IP-Adressen bestehen aus 4 Dezimalzahlen im
Bereich von 0 bis 255, die durch Punkte getrennt werden (z. B. 194.62.15.2).
MAC-Adresse (Media Access Control-Adresse)
Die MAC-Adresse ist zur eindeutigen Identifizierung jeder Einrichtung (Device, Router)
im Netzwerk notwendig. Die MAC-Adresse ist entweder fest im Kommunikationschip
(z. B. Ethernet) oder muss koordiniert vergeben und dokumentiert werden (MS/TP).
MBE
Als Management- und Bedieneinrichtungen (MBE) werden GA-Einrichtungen bezeichnet, die über Bedien- und Managementfunktionen verfügen.
Natives BACnet (Native BACnet)
Der Begriff ist nicht genormt. Er beschreibt die aus Anwendersicht gewünschte Fähigkeit von BACnet-Geräten zur Kommunikation nach DIN EN ISO 16484-5 als einprogrammierte und immer verfügbare Grundeigenschaft (ohne zusätzliche Hardware,
Software und Dienstleistungen).
Peer-to-Peer
In Peer-to-Peer-Netzen sind alle Netzteilnehmer gleichberechtigt. Jeder Rechner (Peer)
kann gleichzeitig Client und Server sein und sowohl Dienste in Anspruch nehmen als
auch Dienste zur Verfügung stellen. Bei Peer-to-Peer fehlt die eindeutig festgelegte
Rollenverteilung, die dem Client-Server-Prinzip zu Grunde liegt.
114
Ports (Anschlüsse)
Ports sind Adresskomponenten, die in Netzwerkprotokollen eingesetzt werden, um Datenpakete den richtigen Diensten (Protokollen) zuzuordnen. Dieses Konzept ist z. B. in
TCP und UDP verwendet. Werte von 0 bis 65535 sind möglich.
Bestimmte Anwendungen (z. B. http, smtp) verwenden Portnummern, die ihnen fest
zugeordnet und allgemein bekannt sind. Sie liegen üblicherweise zwischen 0 und
1023, und werden als Well Known Ports bezeichnet.
Zwischen Port 1024 und 49151 befinden sich die Registered Ports. Anwendungshersteller können bei Bedarf Ports für eigene Protokolle registrieren lassen, ähnlich wie
Domainnamen. Die Registrierung hat den Vorteil, dass eine Anwendung anhand der
Portnummer identifiziert werden kann, allerdings nur wenn die Anwendung auch den
Port verwendet.
Für BACnet-Ports ist bei TCP und UDP folgende Nummer registriert: 47808 (0xBAC0)
Die restlichen Ports von Portnummer 49152 bis 65535 sind so genannte Dynamic
und/oder Private Ports. Diese lassen sich variabel einsetzen, da sie nicht registriert
und damit keiner Anwendung zugehörig sind.
Repeater
Um Längenbeschränkungen von Kabeln infolge Dämpfung zu überwinden, werden
Repeater eingesetzt. Repeater werden in der Gebäudeautomation z. B. bei RS485
und LON-Netzwerken eingesetzt.
Router
Ein Router verbindet Netzwerke auf der Schicht 3 des ISO-OSI-Modells (z. B. IP-Niveau).
Router optimieren die paketvermittelte Kommunikation zwischen den Netzwerken. Sie
führen Tabellen mit Informationen über Netzwerke, Netzwerkteilnehmer und andere
Router und ihre IP-Adressen. Datenpakete werden nur an betroffene Netzwerkteilnehmer oder Netzwerke weitergeleitet.
Switch
Ein Switch teilt ein Netzwerk zur besseren Lasttrennung in Netzsegmente (Teilnetze)
ein. Die Daten eines Netzsegments gelangen nicht in andere Segmente und belasten
nicht das Gesamtnetz. Ein Switch verfügt über physikalische Anschlüsse zur Anschaltung der Netzsegmente. Kommende Daten werden nur an die Anschlüsse mit der angegebenen Zieladresse weitergeleitet. Der Switch verbindet den Empfangs- und den
Ausgangsport kollisionsfrei mit der vollen Kanal-Bandbreite. Ein Switch ist lernfähig
hinsichtlich der angeschlossenen Stationen.
BACnet 2007
115
TCP (Transmission Control Protocol)
TCP dient zur Sicherung der Datenübertragung und erbringt verbindungsorientierte
Dienste auf der Transportschicht. Im Gegensatz zu UDP (siehe unten) werden Datenverluste erkannt und durch erneute Datenübertragung behoben. TCP ist in Kombination mit dem Internet Protokoll (IP) als TCP/IP eines der am häufigsten weltweit
genutzten Protokolle.
Tunneling
Tunneling bezeichnet das Kapseln eines Kommunikationsprotokolls innerhalb eines
anderen Protokolls, z. B. BACnet-Broadcasts über geroutete IP-Netzwerke.
UDP (User Datagram Protocol)
UDP ist wie TCP ein auf IP basierendes Protokoll. Da auf Flusskontrolle und Fehlerkorrektur verzichtet wird, ist UDP schneller, aber unsicherer als TCP.
Zeichensatz
ANSI X3.4 ist ein 1986 vom American National Standards Institute genormter ASCIIZeichensatz (American Standard Code for Information Interchange). Er benutzt 7 Binärziffern mit einem Dezimalzahlenraum von 0 bis 127 und ermöglicht lateinische
Buchstaben und Zahlen, aber z. B. keine Umlaute.
ISO 8859-1 ist ein 8-Bit-Zeichensatz, der fast alle Zeichen für Deutsch, Englisch und
andere westeuropäische Sprachen enthält (Latin-1). Es fehlen z. B. das Euro-Zeichen
(€) und die deutschen Anführungszeichen („ “).
116
Anhang 9
Literaturhinweise
• AMEV-Empfehlung Gebäudeautomation 2005
• DIN EN ISO 16484 Gebäudeautomation,
Teil 1: Hardware;
Teil 3: Funktionen;
Teil 5: Protokoll;
Teil 6: Konformitätsprüfung.
• VDI 3814 Gebäudeautomation, Blatt 1 bis 6
• VDI/BIG-EU BACnet Leitfaden und Begriffe für den Leitfaden
• Fachbuch Hans Kranz: „BACnet Gebäudeautomation 1.4“,
2. Auflage, Promotor Verlag, Karlsruhe, ISBN 3-922420-09-5
• Endbericht des Forschungsprojektes: „Standardisierung von Busprotokollen für die
Gebäudeautomation in öffentlichen Gebäuden“ des Bundesamtes für Bauwesen
und Raumordnung (BBR) vom Juli 2007 (Aktenzeichen 10.08.17.7-06.23)
Weitere Literatur ist erhältlich unter:
• Offizielle BACnet Website: • Website der BIG-EU:
• Website der BACnet International: BACnet 2007
www.bacnet.org
www.big-eu.org
www.bacnetinternational.org
117
Mitarbeiterinnen und Mitarbeiter
Hardkop
Ministerium für Bauen und Verkehr (MBV) des Landes
Nordrhein-Westfalen, Düsseldorf (Obmann)
Frau Assaouci Universität zu Köln, Köln
Birlo Fachhochschule Gelsenkirchen, Gelsenkirchen
Brinkmann
Wehrbereichsverwaltung (WBV) West Arbeitskreis GA, Wiesbaden
Prof. Büchel
Fachhochschule Gelsenkirchen, Gelsenkirchen
Crecelius
Energie- und Umweltbüro e. V., Berlin
Didjurgeit
Landeshauptstadt München, München
Fries
Büro für technische Datenverarbeitung, Dachau
Gerhard
Handwerkskammer des Saarlandes, Saarbrücken
Hadré
Hadré + Partner Beratende Ingenieure, Rösrath
Dr. Haeseler
Axima GmbH, Berlin
Dr. Hall
Vermögen und Bau Baden-Württemberg, Stuttgart
Harrach
Universitätsklinikum Essen, Essen
Hasselbach
Technische Universität Dresden, Dresden
Herrmann
ARUP Ingenieurgesellschaft, Berlin
Janetschek
Bayer Immobilien Service (BIS), Leverkusen
Kaps
Landeshauptstadt München, München
König
CAESAR Ingenieure GmbH, Berlin
Klose
Ingenieurbüro Theurich + Klose, Hannover
118
Köster
Bundesverteidigungsministerium (BMVg), Bonn
Koser
Wehrbereichsverwaltung (WBV) Nord Arbeitskreis GA, Hannover
Koster Oberfinanzdirektion (OFD) Hannover, Hannover
Kroll
Ministerium für Bauen und Verkehr (MBV) des Landes
Nordrhein-Westfalen, Düsseldorf
Lambert
Ingenieurbüro Scholz, Regensburg
Lützke
Bundesbaugesellschaft Berlin mbH, Berlin
Maurer
Energie- und Umweltbüro e. V., Berlin
Frau Müller
Leibniz-Universität Hannover, Hannover
Naturski
Oberste Baubehörde im Bayerischen Staatsministerium des
Innern, München
Person
Hochschul-Informations-System (HIS) GmbH, Hannover
Pütz
Rheinische Friedrich-Wilhelms-Universität Bonn, Bonn
Seibt
Deutsche Bahn, DB Station & Service AG, Berlin
Speelmanns
Bundesamt für Bauwesen und Raumordnung (BBR), Bonn
Zwischenberger Ingenieurbüro Inplan, Eichenau
Dank für Beiträge
Prof. Fischer
Fachhochschule Dortmund, Dortmund
Kranz
Ingenieurbüro HAK, Forst
Schubert
Firma MBS, Krefeld
BACnet 2007
119
Notizen
...........................................................................................................................................
...........................................................................................................................................
...........................................................................................................................................
...........................................................................................................................................
...........................................................................................................................................
...........................................................................................................................................
...........................................................................................................................................
...........................................................................................................................................
...........................................................................................................................................
...........................................................................................................................................
...........................................................................................................................................
...........................................................................................................................................
...........................................................................................................................................
...........................................................................................................................................
...........................................................................................................................................
...........................................................................................................................................
...........................................................................................................................................
...........................................................................................................................................
...........................................................................................................................................
...........................................................................................................................................
120
Bestellungen unter:
[email protected] · Fax (030) 44 03 33 99
Satz, Druck und Vertrieb:
Elch Graphics · Digitale- und Printmedien GmbH & Co. KG
Immanuelkirchstraße 3/4 · 10405 Berlin
BACnet
in öffentlichen Gebäuden
(BACnet 2007)
Aufgestellt und herausgegeben vom Arbeitskreis Maschinen- und Elektrotechnik
staatlicher und kommunaler Verwaltungen (AMEV) Berlin 2007

Documents pareils