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 Temperaturgradient 92 DEGREES_C_PER_MINUTE Grad Celsius pro Minute °C/min Temperaturgradient 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 Wartungsmeldung Systemmeldung 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